AIの統合
ネイティブベクトルインデックスと高速化されたベクトルクエリ
4D 21 R5では、 4D.Vector フィールド向けのネイティブベクトルインデックス機能が導入され、4Dにおいて初めて、埋め込みベースのデータに対する専用のインデックス機能が実現されました。
これにより、データセットの規模が拡大しても類似性検索のパフォーマンスが向上し、セマンティック検索、おすすめシステム、RAG、その他のAI駆動型ワークフローにおいて特に有用です。インデックス化されたベクトルフィールドに対するクエリは、インデックス化されていないクエリと同じ結果を返しますが、処理速度はより高速です。
ストラクチャーエディタで直接、コサイン、ドット、ユークリッドの各インデックスを設定できますが、Null ベクトルに対しては既存の自動インデックスを引き続き利用可能です。各インデックスは個別に有効化できるため、アプリケーションで実際に使用するものだけを残しておくことができます。
インデックス化されたベクトルフィールドはソート操作でも使用できるため、新しいインデックスの利点を活用しつつ、クエリ結果をベクトルの類似度に基づいて並べ替えることが可能です。
ベクトルインデックスは、再インデックス、バックアップ、MSC検証、修復を含む標準的なデータベースのライフサイクルに統合されています。
すでに 4D.Vector フィールドに埋め込みを保存しているアプリケーションの場合、データのモデルやクエリの結果を変更することなく、ベクトル検索を高速化するための直接的な手段となります。
プログラムによるベクトルインデックスの管理
4D 21 R5 では、ベクトルインデックスのプログラムによる操作機能も追加されました。これにより、ストラクチャエディタだけに頼ることなく、コードから直接ベクトルインデックスを作成、確認、管理できるようになります。
CREATE INDEX および SET INDEX コマンドはコサイン、ドット、ユークリッドインデックス をサポートしており、DataClass.getIndexes() を使用すると、ランタイムにデータクラスで利用可能なインデックスを確認できます。これは、運用の検証や診断ツールの構築時に特に有用です。データベースストラクチャーを手動で開くことなく、期待されるインデックスが存在することを確認できるためです。
ベクトルデータの保存もより柔軟になりました。4D.Vector.new() はデフォルトで32ビット精度を使用するようになり、ストレージ要件の削減に寄与しますが、状況に応じて64ビット精度も引き続き利用可能です。
これらの変更により、ベクトル検索は開発段階を超えて運用が容易になります。データベースの設計時に視覚的にインデックスを設定し、アプリケーションのデプロイ後はプログラムで検証および管理を行うことが可能になります。
4D Embedding Studio における埋め込みの自動無効化
4D Embedding Studio を使用すれば、埋め込みとビジネスデータの同期を維持することが容易になります。ソースデータが変更された際、4Dは古い埋め込みをそのまま残すのではなく、現在のエンティティを適切に表現できなくなった可能性のあるベクトルを特定できるようになりました。
埋め込みフレーズを構築するために使用された属性が変更された場合、関連するベクトルは自動的に無効化されます。対応する「dirty」ブール型フィールドを使用すると、4Dは現在の値を利用可能なままに保ちつつ、ベクトルに再生成のフラグを立てることができます。そうでない場合、ベクトルはクリアされます。
埋め込みの設定が変更された場合にも、同様の保護機能が適用されます。フレーズの更新は、より広範な再計算ワークフローをトリガーする可能性があります。一方、埋め込みモデルを変更すると、以前のモデルで作成されたベクトルが引き続き再利用されるのを防ぐことができます。
これにより、手動での追跡作業が大幅に削減され、データやAIの設定が進化するにつれて、セマンティック検索、RAG、またはおすすめ機能が古い埋め込みデータで動作してしまうリスクを低減できます。
セキュリティ
SMTP Transporter における S/MIME 署名
送信メールに、SMTP トランスポーターを通じて直接S/MIME によるデジタル署名を付けることができるようになりました。これにより、受信者はメッセージの送信者を特定できるだけでなく、署名後に内容が改ざんされていないかどうかも確認できるようになります。
これは、請求書、承認書、報告書、通知、および真正性が重要なその他のビジネスコミュニケーションにおいて特に有用です。
署名処理は既存のSMTPワークフローにシームレスに組み込まれます。秘密鍵を含む証明書を、ファイルまたはcertificate 経由のBlobとして直接提供するか、certificateName を使用してシステムの証明書ストアから参照指定します。パスワードで保護された証明書もサポートされています。
署名処理は標準の SMTP Transporter API 内で実行されるため、別途署名ツールを導入したり、カスタム統合レイヤーを追加したりすることなく、信頼性の高いメールワークフローを強化できます。
NGTCP2 および QUIC 向けの OpenSSL 4
QUIC 、WebSocket 、およびTLS に関連する機能で使用されるネットワークスタックは、BoringSSL の代わりに OpenSSL 4 を採用する ようになりました。これにより、既存のアプリケーションの動作をほぼ変更することなく、セキュリティ基盤を最新のものにああぷデートすることができます。
ほとんどのアプリケーションにおいて、このアップグレードは透過的に行われます。確認すべき主な点は TLS 設定です。SET DATABASE PARAMETER では、最小 TLS バージョンとしてTLS 1.2 および TLS 1.3 のみをサポートするようになり、デフォルトのサーバーバージョンはTLS 1.3 となっています。
この変更は、暗号化、証明書生成、鍵生成、OpenSSL プロバイダー、ODBC ドライバーなど、OpenSSL に基づく操作にも適用されます。
特別な有効化や移行手順は必要ありませんが、依然として古いTLSバージョンに依存しているアプリケーションについては、デプロイ前に設定を見直す必要があります。
HTTP サーバー
4D Web Server に組み込まれたレート制限機能
4D Web Server では、アプリケーションの他の部分に悪影響が及ぶ前に過度なワークロードを制限できる ようになり、サーバーリソースの共有をより細かく制御できるようになりました。
リクエスト数、送受信データ量、アクティブなセッション、ゲストセッション、およびエンティティセットの制限を定義できます。これらの制限は、サーバー全体または個々のセッションに適用でき、1 つのクライアントやワークロードが不釣り合いなほど多くの容量を消費するのを防ぐのに役立ちます。
制限に達した場合、Web プロセスが作成される前に、リクエストはHTTP 429 Too Many Requests で早期に拒否されます。また、適切な場合には、クライアントにRetry-After 値が返され、再試行すべきタイミングが明確に示されます。
クォータは、起動時に設定したり、HTTPQuotas.json から読み込んだり、ランタイムに `WEB Server().quotas` を通じて更新したりできます。デフォルトでは何も変更されないため、クォータが明示的に設定されるまで、既存のアプリケーションは現在の動作を維持します。
これは、リバースプロキシ、ファイアウォール、またはWAF に代わるものではありません。むしろ、4D内部にアプリケーションを意識した保護機能を追加し、トラフィックの急増や不適切な使用時においても、本番環境のアプリケーションがより高い応答性を維持できるよう支援します。
データベース
刷新された Windows インストーラーと CI に対応したデプロイ
Windows への4D のインストールは、個人ユーザーにとってはより簡単になり、ビルドやデプロイ環境を管理するチームにとっては自動化が格段に容易になりました。
サポートされているすべての言語がデフォルトでインストールされるため、セットアップ時に言語パックを選択する必要がなく、後々言語が欠落するといった問題も回避できます。
このインストーラーは、4D 、4D Server 、4D Volume Desktop 、4D Components に対応しており、デフォルトですべてが選択されていますが、必要なものだけをインストールすることも可能です。
CI や自動デプロイメントでは、Inno Setup のオプションを使用して、コマンドラインからインストーラーをサイレントモードで実行できます。これにより、ビルドエージェント、テストマシン、またはデプロイメント環境の準備といったものが手操作の介入なしに容易になります。
インストーラーは今後x64 版のみ となり、これにより配布の対応表が簡素化され、サポートされている Windows 環境と合致するようになりました。また、そのランタイムが必要な場合は、セットアップの最後に Windows App SDK インストーラーへのリンクも用意されています。
これにより、1台のワークステーションを設定する場合でも、数十の環境を自動化する場合でも、Windows のインストールプロセスがより予測可能になります。
4Dコンポーネント
ホストプロジェクトからコンポーネントを直接コンパイル
コンポーネントをホストプロジェクトから直接コンパイルできるようになり、アプリケーションとビルドで使用されるコンポーネントのバージョンを同期させることがはるかに容易になりました。
コンパイラウィンドウには、ホストプロジェクトと互換性のあるコンポーネントが一緒に表示されるため、各コンポーネントを個別に開くことなく、コンパイル、シンタックスチェック、またはコンパイル済みコードの消去を行うことができます。また、エクスプローラーから選択したコンポーネントのコンパイラ画面に直接移動することも可能です。
コンポーネントは、そのソースがローカルで利用可能であり、.4dzとしてパッケージ化されておらず、依存関係マネージャのキャッシュから取得されたものでもなく、かつ直接型指定を使用している場合に、コンパイルの対象となります。
各コンポーネントは依然として独自のコンパイラ設定を使用しますが、コンパイルログはホストプロジェクトに一元化されます。エラーや警告にもその発生元となるコンポーネントが明示されるため、複数の再利用可能なモジュールに依存するプロジェクトでのトラブルシューティングが大幅に迅速化されます。
これにより、ビルドプロセスの信頼性が向上します。コンパイル済みコンポーネントを個別に管理する手間が省け、アプリケーションに古いバージョンのコンポーネントが含まれたままリリースされるリスクも低減されます。
4D Cornerでコンポーネントを素早く発見
再利用可能なコンポーネントの検索は、依存関係管理のワークフローそのものに組み込まれました。”4D Corner“は、”プロジェクトの依存関係”インターフェースまたは”依存関係の追加”ウィンドウから直接開くことができます。
そこから、4Dやコミュニティが共有するコンポーネントを閲覧し、必要な依存関係をコピーして、リポジトリを個別に検索することなくプロジェクトに取り込むことができます。
これにより、自分で機能を構築する前に既存のソリューションを見つけやすくなり、コンポーネントの発見からアプリケーションへの実際の追加までのプロセスがはるかに明確になります。
ユーザーインターフェース
リストフォームのFluent UIのサポート
リストフォームでは、 Windows インターフェースの他の部分と同じ Fluent UI レンダリングを使用できるようになりました。これにより、すでにモダンなWinUI の外観を採用していたアプリケーションにおいて、最も目立っていた不整合の1つが解消されます。
Fluent UI が有効になっている場合、DISPLAY SELECTION やMODIFY SELECTION などのコマンドを通じて開かれたリストフォーム、およびリストサブフォームは、モダンなレンダリングを採用しつつ、既存のレイアウトと動作を維持します。
これはまた、リストフォームが詳細フォームやダイアログと同様に、Windows のライトテーマまたはダークテーマに従うようになったことを意味します。ユーザーは、モダンなダークインターフェースから、同じアプリケーション内でありながらまるで別のアプリケーションの一部のように見えるクラシックなリストフォームへと移動することがなくなります。
再設計は不要です。既存のリストフォームは自動的に新しいレンダリングの恩恵を受けられる一方、Widget Appearance プロパティを使用することで、フォームごとに動作を制御することも可能です。
既存のリスト フォーム UI が大量にあるアプリケーションの場合、これにより Fluent UI への完全な移行がはるかに現実的になります。
ボタン、ラジオボタン、チェックボックスのスタイリングがさらに柔軟に
シンプルなインターフェースのカスタマイズにおいて、ボタンやコントロールごとに画像アセットを作成する必要がなくなりました。
カスタムスタイルのボタン、ラジオボタン、チェックボックスでは、フォームエディタ、CSS、または 4D コードから直接、背景色、枠線色、枠線の幅、角の半径を設定できるようになりました。
ボタンの場合、新しいプロパティは”カスタム境界線スタイル”を通じて利用可能であるため、新しいスタイルを使用することを選択しない限り、既存のフォームは現在の外観を維持します。ラジオボタンとチェックボックスも、同じ視覚的プロパティを直接設定できます。
背景画像と背景色を組み合わせることも引き続き可能で、角を丸くすると背景画像が自動的に適切にトリミングされます。
これにより、明るいテーマと暗いテーマの両方で一貫したビジュアルアイデンティティを自由に作成できると同時に、作成、バージョン管理、および保守が必要なグラフィックの数を減らすことができます。
新しいスタイリングオプションはプロジェクトモードに適用され、バイナリデータベースではサポートされていません。
テキストオブジェクトの垂直方向の配置とパディング
フォーム内のテキスト配置は、オブジェクトのサイズを変更したり、視覚的な回避策に頼ったりすることなく、より簡単に制御できるようになりました。
Text Area オブジェクトおよび Input オブジェクトでは、縦方向の配置として「上（top）」「中央（middle）」「下（bottom）」または「デフォルト」を選択できるほか、各辺ごとに個別にパディングを設定できます。これにより、ラベル、フィールド、および大きな入力エリアの視覚的なバランスを保つことが格段に容易になります。
値の設定は、フォームエディタ、フォームJSON、CSS、またはコードから行うことができます。新しいOBJECT SET PADDING およびOBJECT GET PADDING コマンドにより実行時の制御が可能になり、既存の垂直配置コマンドもテキストエリアおよび入力オブジェクトで利用できるようになりました。
パディングのサポートはリストボックスにも拡張され、水平および垂直方向の対称的な間隔が設定可能です。
既存のフォームは、新しいプロパティの使用を開始するまで現在の表示状態を維持するため、既存の画面を再設計することなく、段階的にレイアウトを改善していくことが可能です。
Visual Studio Code 拡張機能
4D IDE と VS Code のシームレスなワークフロー
4D IDE とVS Code の間を行き来する際、適切なメソッドやクラスを探すためにプロジェクトフォルダ内をくまなく探す必要はもうありません。
新しいコードエディタの設定により、デフォルトで4DコードエディタとVS Code のどちらでコードを開くかを指定できるようになり、必要に応じてAltキーを押すだけで、もう一方のエディタにすばやくアクセスできます。また、現在の動作を維持して、常に 4D コードエディタを使用することも可能です。
この設定は、エクスプローラー、フォームエディタ、デバッガー、ランタイムエラーダイアログ、および「定義へ移動」アクションを含む、4D IDE 全体で適用されます。VS Code が選択されている場合、4D は正確なメソッドまたはクラスファイルを開き、プロジェクトフォルダをVS Code のワークスペースとして指定します。
これは、対応するファイルを手動で探す際にテーブル番号や深くネストされたフォルダを扱う必要があるフォームやオブジェクトメソッドにおいて、特に有用です。4D は、そのパスを自動的に解決し、必要に応じてメソッドを最初に作成します。
その結果、IDE を併用するワークフローが格段にスムーズになります。フォームの作成、デバッグ、プロジェクトのナビゲーションには引き続き4D IDE を使用しつつ、Git ツール、拡張機能、またはAI を活用した開発が必要な場合は、直接VS Code に切り替えることができます。
この統合機能はプロジェクトモードに適用されます。バイナリデータベースについては、引き続き4D コードエディターが使用されます。