4D 21 R2では、4D AIKitでネイティブのファイルアップロードサポートが導入され、アプリケーションがPDFなどのドキュメントを直接AIモデルに送信し、AIとの会話でファーストクラスのコンテキストとして使用できるようになりました。ユーザーは、要約を求めたり、特定の情報を抽出したり、特定のセクションを探索したりします。
その流れは意図的なほど分かりやすくなっています。ファイルのアップロードには、OpenAI.files.create を使用します。ここで、目的と有効期限(オプション)を定義します。この呼び出しはファイル識別子を返し、チャットヘルパーを呼び出すときに、ドキュメントを会話コンテキストの一部にするために、OpenAIMessage に渡すことができます。ファイルがいつ導入され、いつ再利用され、いつシステムから離れるかを決めるのはあなたです。何も不明瞭なこともありませんし、何も隠されたトリックはありません。
AIが扱うのはドキュメントそのものであるため、重複したコンテンツや、同期を保つための並列表現が存在しません。ユーザーは認識したオリジナルのファイルと対話し、応答はその資料を正しく参照しつづけます。ファイル名は保持され、サイズ制限は実際のドキュメントをサポートし、有効期限ポリシーはデータの保存期間をコントロールします。
同じAPIで、アップロードされたファイルを一覧表示したり、メタデータを取得したり、不要になったファイルを削除したりできます。インタラクションは設計からしてシンプルです。ドキュメントが入力され、AI機能がその上に直接構築され、その間のロジックは最小限のままで、わかりやすく、直感的です。
4D 21 R2では、ベクタークエリは、単にフィルタリングするだけでなく、類似性によって結果を並べ替えることができるようになりました。クエリは、一致するレコードを見つけるだけでに止まりません。どのレコードを最初に表示するかを決定するのです。なぜなら、セマンティック検索は関連性順に並べられた時に初めて機能するといえるからです。似たような結果を見つけるだけでは十分とは言えません。最も一致するレコードを見つけるまでがワンセットなのです。
その動作は queryに直接組み込まれています。ベクトル・フィールドがフィルターとorder by 節の両方で使われている場合、4Dは結果をランク付けするために同じ類似度計算を再利用します。エンティティが一致するかどうかを決定する比較は、結果セットでの位置を決定するものでもある。メンテナンスのことを考えなければいけない二次的なロジックはなく、クエリ実行後の並び替えステップもありません。関連性は一度定義されれば、一貫して適用されます。
これは既存のORDAクエリの拡張であるため、新たに学習する必要はありません。ベクターフィールドは、DataClass.query 、EntitySelection.query 、RESTリクエストのorder by 節でサポートされています。順序は、昇順または降順、古典的なフィルタとの組み合わせ、日付や数値フィールドのような従来のソートとの混合が可能です。複数のベクトル比較が存在する場合、順序付けは確実に最初のものを使用し、明示的で予測可能な評価を維持します。
クエリは完全な意図を伝えます。何を探しているのか、どのように関連性を適用すべきなのかを記述すると、データはその意味によってすでに順序付けされた状態で戻ってきます。余計なコマンドは必要ありません。追加の処理も必要ありません。クエリをするだけでどの結果が最も重要かが伝わります。
4D 21 R2では、Qodly Pagesを4D IDEから直接作成・編集することができます。Qodly Pagesは、もはやサイドからアクセスするものではありません。Qodlyページは、アプリケーションの他の部分と同じ場所に存在します。バックエンドロジック、データモデリング、Web UIが同じアプリに属している場合、1つの場所にとどまることで、勢いを保つことができます。
Qodly Pagesは、専用のフォルダを通して4Dエクスプローラーに表示されます。新しいページを作成したり、既存のページを開いたりするのは、そこから始まります。どちらかのアクションをトリガーすると、ブラウザでQodly Studioが開きます。ウェブインターフェイスで作業している間、プロジェクトに固定された状態を保つことができます。
4D 21 R2では、Windows上で4Dフォームをレンダリングする新しい方法として、Fluent UIがDeveloper Previewとして利用可能になりました。これは、MicrosoftのFluent UIデザインシステムを4Dアプリケーションに導入するもので、Windows、Office、Teamsで日常的に目にするものと同じであるため、ユーザーにとってすでに馴染みのあるモダンなビジュアル・インターフェースをもたらします。
Fluent UIは、フォームの構築方法ではなく、フォームの認識方法を変更します。既存のフォームは、その構造とロジックを維持します。違いは視覚的なものです。レイアウトの書き換えを強いることなく、スペーシングがよりバランスよく感じられ、テキストがより明確になり、ライトモードとダークモードのネイティブサポートなど、最新のWindowsの慣例に自然に沿ったインターフェイスになります。
採用はあなたのコントロール下に。流暢な UI は、プロジェクト全体で有効にすることも、フォームごとに選択的に適用することもできます。モダナイゼーションが意味を持つ部分と、クラシックな外観を残す部分を決定し、変更を段階的かつ意図的に維持します。
Fluent UIはモダンレンダリングを使用しているため、一部のビジュアル指標はクラシックスタイルとは若干異なります。テキストや、チェックボックスなどの特定のウィジェットは、少し大きく表示されたり、間隔が広くなったりします。非常にタイトでピクセルレベルのレイアウトでデザインされたフォームでは、意図した配置を維持するために微調整が必要になることがあります。
Fluent UIは4Dに直接統合されています。インストールとデプロイはプラットフォームを通じて行われ、すべてをアプリケーションにバンドルするか、クライアント環境に依存するかを選択できます。手動で管理する外部依存関係はありません。
ランタイムの動作は予測可能なままです。システム上でFluent UIを有効にできない場合、アプリケーションは自動的にクラシックレンダリングにフォールバックします。ユーザーにエラーは表示されません。アプリケーションは通常通り継続され、 可視性のための診断エントリだけが記録されます。
スタイリングはレンダリングとともに進化する。フォームは、クラシック UI モードと Fluent UI モードのどちらに表示されるかに反応することができ、アプリケーションの影響を受けない部分に影響を与えることなく、ビジュアルを徐々に洗練させることができます。
標準的なダイアログも同じ方向に従います。アラート、確認、リクエスト、システムウィンドウは、Fluent UIを有効にすると、Fluent UIルックを採用し、アプリケーション全体で一貫したエクスペリエンスを維持します。
4D 21 R2のFluent UIは、ユーザーインターフェースの近代化における大きな前進です。既存のアプリケーションを安定させながら、デザイン・システムを成熟させることができます。コードは使い慣れたまま。ワークフローはそのまま。UIはプラットフォームと共に前進します。
4D 21 R2では、シンタックスチェックとコード補完が同じ推論ロジックを共有します。エディターとコンパイラーは、もはや異なるコード解釈をしません。入力中にインテリセンスが推論する内容は、シンタックス・チェッカーとコンパイラが理解するものと全く同じであるため、フィードバックの信頼性が保たれ、コードを書く際の迷いがなくなります。
エラーが実際に発生した場所で報告されるようになりました。問題のあるトークンのみに下線が引かれ、その周りの式全体には下線が引かれません。複数行のステートメントでは、問題が発生した正確な行にマーカーが表示されます。カーソルを合わせると、問題が表示され、修正され、周囲のコードをスキャンしたり、エディターが何を言おうとしているのかを推測したりすることなく、先に進むことができます。
推論が統一されているため、補完候補とエラー検出が互いに強化されます。複雑な式は一貫して推論され、型を決定できない場合は、サイレント・デフォルトではなく、明示的にフラグが立てられます。無効なキャスト、予期しないプロパティ、宣言されていない変数、不正なパラメータ、互換性のない演算子は、コードが動いている間に早期に検出されます。
この動作は、開発者が実際に毎日使用する環境で一貫しています。4D IDEとVS Codeは、同じルールと同じエラーモデルに依存しています。何も設定することはなく、新しく学ぶこともありません。一度コードを書けば、得られるフィードバックはどこでも同じことを意味します。
4D 21 R2では、標準のアクションで作成した箇条書きリストや番号付きリストが、4D Write Proで自動的にインデントされます。これにより、手動で余白を調整することなく、リストがページ内に正しく配置されるようになりました。
箇条書きが標準アクションで適用されると、テキストは、リストが読みやすく、視覚的にバランスが保たれる程度に押されます。調整は即座に一貫して行われます。ユーザーが期待する場所に箇条書きが表示され、コードに追加のフォーマットロジックがなくても、ドキュメントはきれいなレイアウトを保ちます。
動作は予測可能なままです。標準のアクションを使用して箇条書きを削除すると、追加されたマージンも削除され、段落は以前のレイアウトに戻ります。これにより、特にリストスタイルが動的に変更されるドキュメントにおいて、微妙な位置合わせの問題を避けることができます。
インデントはドキュメントのデフォルトのタブオフセットと一致し、テキストの方向を尊重します。左から右へのテキストは左に、右から左へのテキストは右にインデントされ、余分な処理をすることなく、多言語ドキュメントでのリストレンダリングを正しく保ちます。
リストの書式設定は、もはや考えなくてもよいものになります。ドキュメントはクリーンな状態に保たれ、コードはレイアウトの修正ではなくコンテンツに集中することができます。
4D 21 R2のFind in Designは、ホストプロジェクトを越えて、アクセス可能なすべてのコンポーネントを検索します。検索は、もはや部分的な表示ではありません。これは、共有ロジックに触れ、仮定が安全でなくなった瞬間に重要になります。
検索スコープは明示的です。ホストプロジェクト、特定のコンポーネント、またはホストとすべてのコンポーネントをまとめて検索対象とすることができます。コンポーネントからの結果は明確に識別されるため、コンテキストが失われることはなく、何も推測する必要はありません。一度の検索で全体像を把握できる。
これは、リファクタリングの際に特に価値を発揮する。メソッドを更新すると、最近開いていないコンポーネントに埋もれているものも含めて、すべての参照がすぐにわかります。結果がエクスポートされるとき、そのコンテキストは保持される。各行には、所属するプロジェクトやコンポーネントが含まれるため、レビューや監査、外部分析に再作業することなく、アウトプットを使用することができます。
この機能は、プロジェクト・モード・インデックスの上に構築されています。利用可能なソースコードを持つコンポーネントは自動的に含まれ、検索範囲とメタデータは、結果とツールチップを通して伝達されます。大規模な結果セットであっても、読みやすく、曖昧さがありません。
検索は推測ツールではありません。一度見れば、すべてを把握し、確実に前進することができます。
4D 21 R2では、 コンポーネントの依存関係は、コンポーネントマネージャにカスタムアイコンを表示できます。すべてのエントリが同じように見えるのではなく、各コンポーネントが独自のビジュアルアイデンティティを持つことができます。
アイコンは自動的にピックアップされます。コンポーネントがResourcesフォルダにlogo.svg または logo.pngファイルを含んでいる場合、4Dはそれをコンポーネントマネージャのコンポーネントアイコンとして使用します。設定は不要です。両方のフォーマットがある場合、どのサイズでもシャープなレンダリングを保証するために、SVG バージョンが優先されます。
この小さな変更は、依存関係をナビゲートする方法をシフトします。公式コンポーネント、内部ツール、サードパーティパッケージが一目で見分けられるようになりました。名前を読む時間が減り、見たものに対して行動する時間が増えます。
コンポーネントの動作は何も変わりません。認識だけが変わります。そして、リストを開くたびに摩擦が減ります。
4D 21 R2では、4DビュープロはSpreadJSバージョン18.2の上に構築されており、リボンはこのリリースに完全に対応しています。4D View Proの機能は、その下にあるエンジンに追従するため、このアップデートにより、既存のドキュメントの構築方法やメンテナンス方法を変更することなく、即座にパフォーマンスが向上し、新機能を利用できるようになりました。
これらはすべて、1回のエンジンアップデートで実現します。移行手順はありません。既存のドキュメントに対する動作の変更もありません。現在の View Pro コンテンツの能力を高め、将来のユースケースの拡張を容易にする、より強力な基盤が提供されます。
