次の方法で共有

ベースライン Azure AI Foundry チャット参照アーキテクチャ

Azure OpenAI Service
Az AI サービス
Azure App Service
Azure Monitor
Azure AI Foundry

エンタープライズ チャット アプリケーションは、AI エージェントとの会話操作を通じて従業員を支援できます。 この機能は、OpenAI の GPT モデルやセマンティック カーネルなどのオーケストレーション SDK など、言語モデルの継続的な進歩により、ますます強力になっています。 これらのチャット アプリケーションは、通常、次のコンポーネントで構成されます。

  • 大規模なエンタープライズ アプリケーションに統合されたチャット ユーザー インターフェイス (UI)。 他のビジネス機能と共に会話エクスペリエンスをユーザーに提供します。

  • ユーザー クエリに関連するドメイン固有の情報を含むデータ リポジトリ。

  • 関連する応答を生成するためにドメイン固有のデータを推論する言語モデル。

  • データ ソース、言語モデル、エンド ユーザー間の相互作用を監視するオーケストレーターまたはエージェント。

この記事では、Foundry Models で Azure AI Foundry と Azure OpenAI を使用してエンタープライズ チャット アプリケーションを構築およびデプロイするのに役立つベースライン アーキテクチャについて説明します。 このアーキテクチャでは、Azure AI Foundry Agent Service でホストされている単一のエージェントを使用します。 エージェントはユーザー メッセージを受信し、データ ストアにクエリを実行して、言語モデルの基礎情報を取得します。

チャット UI は、セキュリティで保護されたゾーン冗長で高可用性の Web アプリケーションを App Service にデプロイする方法に関する ベースラインの Azure App Service Web アプリケーション ガイダンスに従います。 このアーキテクチャでは、App Service は、プライベート エンドポイント経由の仮想ネットワーク統合を通じて、サービスとしての Azure プラットフォーム (PaaS) ソリューションと通信します。 チャット UI アーキテクチャでは、App Service はプライベート エンドポイント経由でエージェントと通信します。 Azure AI Foundry ポータルとエージェントへのパブリック アクセスが無効になっています。

Important

この記事では、 ベースライン App Service Web アプリケーション アーキテクチャのコンポーネントやアーキテクチャの決定については説明しません。 チャット UI を含む Web アプリケーションをホストする方法に関するアーキテクチャ ガイダンスについては、この記事を参照してください。

このアーキテクチャでは、 Foundry Agent Service 標準エージェントのセットアップ を使用して、エンタープライズ レベルのセキュリティ、コンプライアンス、および制御を有効にします。 この構成では、独自のネットワークを使用してネットワークを分離し、独自の Azure リソースを使用してチャットとエージェントの状態を格納します。 アプリケーション コンポーネントと Azure サービス間のすべての通信はプライベート エンドポイント経由で行われるため、データ トラフィックはワークロードの仮想ネットワーク内に残ります。 エージェントからの送信トラフィックは、エグレスルールを適用する Azure Firewall を経由して厳密にルーティングされます。

Tip

Foundry Agent Service のリファレンス実装では、Azure でのエンド ツー エンドのチャットのベースライン実装が紹介されています。 これは、運用環境に移行する際にカスタム ソリューションを開発するための基盤として機能します。

Architecture

Azure AI Foundry を使用するベースラインのエンド ツー エンド チャット アーキテクチャを示す図。

このアーキテクチャの Visio ファイルをダウンロードします。

Workflow

  1. アプリケーション ユーザーがチャット UI と対話します。 要求は Azure Application Gateway 経由でルーティングされます。 Azure Web Application Firewall は、バックエンド App Service に転送する前に、これらの要求を検査します。

  2. Web アプリケーションは、ユーザークエリまたは命令を受け取ると、専用のエージェントを呼び出します。 Web アプリケーションは、Azure AI Agent SDK を介してエージェントと通信します。 Web アプリケーションは、プライベート エンドポイント経由でエージェントを呼び出し、マネージド ID を使用して Azure AI Foundry に対して認証を行います。

  3. エージェントは、システム プロンプトの指示に基づいてユーザーの要求を処理します。 ユーザーの意図を満たすために、エージェントには、構成された言語モデル、接続されたツール、接続されたナレッジ ストアがあります。

  4. エージェントは、プライベート エンドポイントを介してプライベート ネットワーク内のナレッジ ストア (Azure AI Search) に接続します。

  5. Wikipedia などのほとんどの外部ナレッジ ストアまたはツールへの要求は、検査とエグレス ポリシーの適用のために Azure Firewall を通過します。

  6. エージェントは、構成された言語モデルに接続し、関連するコンテキストを渡します。

  7. エージェントは UI に応答を返す前に、要求、生成された応答、および参照されたナレッジ ストアの一覧を専用 メモリ データベースに保持します。 このデータベースは完全な会話履歴を保持します。これにより、コンテキストに対応した対話が可能になり、ユーザーは前のコンテキストを失うことなくエージェントとの会話を再開できます。

    Azure AI Foundry API は、コンテキスト分離された複数の同時会話を管理するユーザー エクスペリエンスの開発をサポートします。

Components

このアーキテクチャは、 基本的な Azure AI Foundry チャット参照アーキテクチャに基づいています。 このアーキテクチャでは、信頼性、セキュリティ、運用制御に関するエンタープライズ要件に対応するために、より多くの Azure サービスが導入されています。 運用エンタープライズ チャット ソリューションでは、次の各コンポーネントが特定の役割を果たします。

  • Foundry Agent Service は、インテリジェント エージェントが安全かつ自律的に動作できるようにするクラウドネイティブランタイム環境です。 このアーキテクチャでは、Foundry Agent Service はチャット操作用のオーケストレーション レイヤーを提供します。 次のタスクを実行するエージェントをホストおよび管理します。

    • ユーザー要求を処理する
    • ツールとその他のエージェントへの呼び出しを調整する
    • コンテンツの安全性を強制する
    • エンタープライズ ID、ネットワーク、および可観測性との統合

    標準エージェントのセットアップにより、ネットワークの分離が保証され、データ ストレージの制御が提供されます。 エージェントの状態、チャット履歴、および Foundry Agent Service が排他的に管理するファイル ストレージ用の専用の Azure リソースを提供します。 ワークロード内の他のアプリケーション コンポーネントでは、これらの必要なリソースを使用しないでください。

    • Azure Cosmos DB for NoSQL は、グローバルに分散されたドキュメント データベース サービスです。 このアーキテクチャでは、サブスクリプション内で、 enterprise_memoryと呼ばれるワークロードのメモリ データベースをホストします。 このデータベースには、チャット スレッドやエージェント定義など、エージェントの操作状態が格納されます。 この設計により、チャット履歴とエージェントの構成が、データ ガバナンス要件に従って分離され、監査可能になり、管理されます。 Foundry Agent Service は、データベース、そのコレクション、およびデータを管理します。

    • Azure Storage は、非構造化データ用のクラウド ストレージ サービスです。 このアーキテクチャでは、チャット セッション中にアップロードされたファイルの専用ストレージを提供します。 サブスクリプションでこのアカウントをホストすると、詳細なアクセス制御、監査機能、データ所在地または保持ポリシーへの準拠が提供されます。 Foundry Agent Service は、これらのコンテナー内のコンテナーとデータ ライフ サイクルを管理します。

    • AI Search は、豊富な検索機能を提供するサービスとしての検索クラウド ソリューションです。 このアーキテクチャでは、エージェントとの会話からアップロードされたファイルの検索可能なチャンク インデックスが格納されます。 AI Search には、すべてのエージェント呼び出しで使用するためにエージェントが作成されるときにナレッジ ソースとして追加されるチャンクされた静的ファイルも格納されます。 Foundry Agent Service は、インデックス、スキーマ、およびデータを管理し、独自のチャンク戦略とクエリ ロジックを使用します。

  • Application Gateway は、Web トラフィック ロード バランサーとアプリケーション配信コントローラーです。 このアーキテクチャでは、チャット UI へのすべての HTTP および HTTPS トラフィックに対して、セキュリティで保護されたスケーラブルなエントリ ポイントとして機能します。 また、トランスポート層セキュリティ (TLS) の終了とパスベースのルーティングも提供します。 Application Gateway は、Web アプリケーション層の高可用性とパフォーマンスをサポートする可用性ゾーン間で要求を分散します。 そのバックエンドは、アプリケーション コードをホストする App Service インスタンスです。

    • Azure Web Application Firewall は、一般的な Web 悪用から Web アプリケーションを保護するクラウドネイティブ サービスです。 このアーキテクチャでは、Application Gateway と統合して、チャット UI を一般的な Web の脆弱性や攻撃から保護します。 HTTP 要求を検査およびフィルター処理します。HTTP 要求は、公開アプリケーションのセキュリティ層を提供します。

    • Azure Key Vault は、シークレット、キー、証明書を安全に格納してアクセスするためのクラウド サービスです。 このアーキテクチャでは、Application Gateway で必要な TLS 証明書を安全に格納および管理します。 Key Vault の一元化された証明書管理では、自動ローテーション、監査、組織のセキュリティ標準への準拠がサポートされます。 このアーキテクチャでは、格納されているキーやその他のシークレットは必要ありません。

  • Azure Virtual Network は、Azure 内のプライベート ネットワークの基本的な構成ブロックです。 このアーキテクチャでは、セキュリティとコンプライアンスの要件を満たすのに役立つすべてのコンポーネントのネットワーク分離を提供します。 プライベート仮想ネットワークにリソースを配置する場合は、東西トラフィックを制御し、セグメント化を適用し、トラフィックをプライベートに保ち、イングレス フローとエグレス フローの検査を有効にします。

  • Azure Private Link は、仮想ネットワークから Azure PaaS サービスへのプライベート接続を提供します。 このアーキテクチャでは、Azure Cosmos DB、Storage、AI Search、Foundry Agent Service などのすべての PaaS サービスをプライベート エンドポイント経由で仮想ネットワークに接続します。 Private Link を使用すると、すべてのデータ トラフィックが Azure バックボーンに残り、パブリック インターネットへの露出を排除し、攻撃対象領域を減らすことができます。

  • Azure Firewall は、クラウドベースのマネージド ネットワーク セキュリティ サービスです。 このアーキテクチャでは、仮想ネットワークからのすべての送信 (エグレス) トラフィックを検査および制御します。 また、完全修飾ドメイン名 (FQDN) ベースの規則も適用されます。これにより、承認された宛先のみが到達可能になります。 この構成は、データ流出を防ぎ、ネットワーク セキュリティの要件を満たすのに役立ちます。

  • Azure DNS は、仮想ネットワークにリンクされたプライベート ドメイン ネーム システム (DNS) ゾーンを提供します。 このアーキテクチャでは、プライベート エンドポイントの名前解決を有効にします。これにより、すべてのサービス間通信でプライベート IP アドレスが使用され、ネットワーク境界内に残ります。

  • Storage は、セキュリティで保護された自動化されたデプロイ ワークフローをサポートし、アプリケーション成果物をコンピューティング リソースから分離します。 このアーキテクチャでは、App Service へのデプロイ用の ZIP ファイルとして Web アプリケーション コードをホストします。

Alternatives

このアーキテクチャには、ワークロードの機能要件と非機能要件に応じて、他の Azure サービスまたはアプローチに置き換えることができる複数のコンポーネントが含まれています。 次の代替手段とトレードオフを検討してください。

チャット オーケストレーション

現在のアプローチ: このアーキテクチャでは 、Foundry Agent Service を使用して、ナレッジ ストアからのグラウンド データのフェッチや Azure OpenAI モデルの呼び出しなど、チャット フローを調整します。 Foundry Agent Service は、コードレスで非決定的なオーケストレーションを提供します。 チャット要求、スレッド管理、ツールの呼び出し、コンテンツの安全性、ID、ネットワーク、監視との統合を処理します。 ネイティブ メモリ データベース ソリューションを提供します。

別の方法:セマンティック カーネルや LangChain などのフレームワークを使用して、オーケストレーション レイヤーを自己ホストできます。 これらのフレームワークを使用して、決定論的なコードドリブン チャット フローとカスタム オーケストレーション ロジックを実装します。

ワークロードで次の機能が必要な場合は、この代替手段を検討してください。

  • Foundry Agent Service でサポートされているモデル以外のモデルの使用

  • オーケストレーション シーケンス、ツールの呼び出し、またはプロンプト エンジニアリングをきめ細かく決定論的に制御する

  • Foundry Agent Service がネイティブでサポートしていないカスタム ビジネス ロジックまたは外部システムとの統合

  • 実験または安全なデプロイプラクティスのための高度なクライアント要求ルーティング

  • ネイティブの Foundry Agent Service ソリューションとは異なるカスタム メモリ データベース ソリューション

セルフホステッド オーケストレーションにより、運用の複雑さが増し、コンピューティング、スケーリング、セキュリティを管理する必要があります。

アプリケーション層コンポーネント

現在のアプローチ: チャット UI フロントエンド Web サイトは、App Service の Web Apps 機能でホストされています。これは、Web アプリケーション用のマネージドでスケーラブルなプラットフォームを提供します。 Web Apps は、Azure のネットワーク機能とセキュリティ機能とネイティブに統合されます。

別の方法: Azure Container Apps や Azure Kubernetes Service (AKS) などの他の Azure マネージド コンピューティング プラットフォームを使用して、アプリケーション層をホストできます。

ワークロードが次のいずれかの条件を満たしている場合は、この代替手段を検討してください。

  • もう 1 つのコンピューティング プラットフォームでは、特定のユース ケースがより適切にサポートされ、そのプラットフォームにサービスを併置することで、コスト効率が向上し、運用が簡素化されます

  • アプリケーションには、より高度なスケーリング、オーケストレーション、またはカスタム ネットワークが必要です

App Service は、Web アプリケーションとその API をホストする際の簡略化のために推奨されるオプションです。

グラウンド データ (ナレッジ) ストア

現在のアプローチ: このアーキテクチャでは、知識を基礎にするための主要なデータ ストアとして AI Search を使用します。 AI Search ベクター検索とセマンティック ランク付け機能を使用します。

別の方法: Azure Cosmos DB、Azure SQL Database、その他のオンライン トランザクション処理 (OLTP) データ ストアなど、知識を基礎として他のデータ プラットフォームを使用できます。 データ プラットフォームは、既存のデータ資産、データの鮮度要件、およびクエリ要件に依存します。

ワークロードが次のいずれかの条件を満たしている場合は、この代替手段を検討してください。

  • 既存のトランザクション データベースまたは運用データベースで基礎知識を既に管理している

  • AI Search では使用できないマルチモデルまたは SDK のサポートが必要です

  • 特殊なデータ ソースまたはレガシ システムと統合する必要がある

ベクター検索は、検索拡張生成では一般的ですが、必ずしも必須であるとは限りません。 詳細については、「ベクトル検索用の Azure サービスを選択する」を参照してください。 データ ストアを選択する前に、ワークロードのデータ アクセス パターン、待機時間、スケーラビリティのニーズを評価します。

定義済みのエージェントまたは動的に作成されたエージェント

現在のアプローチ: 参照実装では、Azure AI Foundry 内のマイクロサービスとしてデプロイされる静的に定義されたエージェントを使用します。 エージェントのロジックとデータ ソースはデプロイ時に構成され、次のアプリケーション リリースまで変更されません。 このアプローチは、エージェントの動作とデータ ソースが安定していて、DevOps プロセスによって制御されている場合に適しています。

別の方法: Azure AI Agent SDK を使用して、実行時にエージェントを動的に作成または変更できます。 この方法により、アプリケーションは、必要に応じてエージェントをインスタンス化したり、システム プロンプトを調整したり、ユーザー コンテキストやビジネス ロジックに基づいて接続を再構成したりできます。

ワークロードに次の機能が必要な場合は、動的エージェントを検討してください。

  • ユーザーまたはセッションごとにカスタマイズされたエージェントの動作またはデータ ソース

  • エージェント構成に対する頻繁な変更またはプログラムによる変更

  • 高度なユーザー エクスペリエンスのためのエフェメラル、コンテキスト固有のエージェントサポート

動的エージェント管理により、柔軟性が向上しますが、ライフサイクル管理の負担も発生します。 エージェントの作成、変更、およびクリーンアップを適切に制御できることを確認します。

ワークロードのユーザー エクスペリエンス要件に合ったエージェント アプローチを選択します。

単一エージェントまたはマルチエージェントオーケストレーション

現在のアプローチ: この参照アーキテクチャでは、必要なすべてのナレッジ ソースとツールにアクセスできる単一のエージェントを使用して、ほとんどのユーザー操作を効果的に処理します。

別の方法: 複数の特殊なエージェントを調整できます。各エージェントは、特定のドメインに焦点を当てたり、異なるモデルを使用したり、個別のナレッジ ストアやツールにアクセスしたりできます。

ワークロードが次の特性を示す場合は、マルチエージェントアプローチを検討してください。

  • 要求は、財務分析、法的レビュー、技術的な実装など、複数の専門知識領域にまたがっています。 特殊なエージェントは、それぞれのドメイン内でより深く、より正確な応答を提供します。

  • 情報にはさまざまなアクセス許可レベルが必要です。 HR エージェントは従業員データにアクセスする場合があります。一方、カスタマー サービス エージェントは製品情報にのみアクセスします。 マルチエージェント アーキテクチャを使用すると、エージェント レベルで詳細なセキュリティ境界を実現できます。

  • 異なるクエリ操作は、さまざまなモデルの恩恵を受けます。 軽量モデルは単純な質問を処理し、より強力なモデルでは複雑な推論タスクを処理します。 この方法では、コストと待機時間の両方が最適化されます。

  • チャット エクスペリエンスは、さまざまな専門家を必要とする順次または並列の手順を含むビジネス プロセスのフロントエンドとして機能します。

マルチエージェントアプローチでは、エージェント間の通信により、調整の複雑さと待機時間の増加が発生します。 ユース ケースが明確に定義されていて、厳密なアクセス分離を必要とせず、適切なツール セットを使用して 1 つのモデルで効果的に処理できる場合は、1 つのエージェントを使用します。

複数の調整されたエージェントを実装する方法のガイダンスについては、 AI エージェントのオーケストレーション パターンを参照してください。 この記事では、シーケンシャル、コンカレント、グループ チャット、ハンドオフ、およびマゼンティック オーケストレーションのアプローチについて説明します。 Foundry Agent Service 内にいくつかのパターンを実装できます。 その他のパターンでは、セマンティック カーネルなどの SDK を使用して、セルフホステッド オーケストレーションが必要です。

Considerations

これらの考慮事項は、ワークロードの品質向上に使用できる一連の基本原則である Azure Well-Architected Framework の要素を組み込んでいます。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

ワークロードの設計フェーズで、このアーキテクチャと AI ワークロードを Azure の設計ガイダンス に適用します。

Reliability

信頼性は、アプリケーションが顧客に対して行ったコミットメントを確実に満たすことができるのに役立ちます。 詳細については、「信頼性の設計レビュー チェックリスト」を参照してください。

App Service Web アプリケーションのベースライン アーキテクチャでは、主要なリージョン サービスのゾーン冗長に重点を置いています。 可用性ゾーンは、複数のインスタンスをデプロイするときに冗長性を提供するリージョン内の物理的に分離された場所です。 1 つのゾーンでダウンタイムが発生した場合、リージョン内の他のゾーンは影響を受けない可能性があります。 このアーキテクチャでは、Azure サービスのインスタンスと構成も可用性ゾーンに分散されます。 詳細については、「 ベースラインの高可用性ゾーン冗長 Web アプリケーション」を参照してください。

このセクションでは、App Service ベースライン アーキテクチャ (特に Azure AI Foundry と AI Search) で説明されていないコンポーネントの信頼性について説明します。

オーケストレーションレイヤーのゾーン冗長性

エンタープライズ展開では、通常、ゾーン レベルの障害によるサービス中断のリスクを最小限に抑えるためにゾーン冗長が必要です。 Azure では、ゾーン冗長とは、 可用性ゾーン をサポートし、少なくとも 3 つのインスタンスをデプロイするリソースを使用すること、または直接インスタンス制御が使用できないプラットフォーム レベルの冗長性を実現することを意味します。

このアーキテクチャでは、Azure AI Foundry が Foundry Agent Service 機能をホストします。 エージェントの信頼性は、Foundry Agent Service の依存関係 (Azure Cosmos DB、ストレージ、AI Search) の可用性によって異なります。 Foundry Agent Service はこれらのサービス内のデータを管理しますが、サブスクリプションで信頼性を構成します。

オーケストレーション レイヤーのゾーン冗長を実現するには、次の推奨事項に従います。

カスタム ツール接続や外部ナレッジ ストアなど、他のワークロード固有の依存関係とエージェントが統合されている場合は、それらの依存関係が可用性と冗長性の要件を満たしていることを確認します。 単一ゾーンまたは非冗長の依存関係は、オーケストレーション レイヤーの全体的な信頼性を損なう可能性があります。

AI Foundry ポータル、そのデータ プレーン API、Foundry Agent Service の機能では、ゾーンの冗長性を直接制御することはできません。

Azure AI Foundry モデル ホスティングの信頼性

Azure AI Foundry では、複数のデプロイ オプションを使用してサービスとしてのモデル (MaaS) ホスティングを提供します。 これらのオプションは、主に、リージョン内の従来の高可用性ではなく、クォータとスループットの管理をサポートします。 標準モデルのデプロイは 1 つのリージョンで動作し、可用性ゾーンはサポートされていません。 マルチデータセンターの可用性を実現するには、グローバルまたはデータ ゾーン モデルのデプロイを使用する必要があります。

エンタープライズ チャット シナリオの場合は、 プロビジョニングされたデータ ゾーン と データ ゾーン標準 モデルの両方をデプロイします。 余分なトラフィックまたは障害を処理するように スピルオーバー を構成します。 ワークロードで低待機時間または厳密な地理的データ所在地と処理が必要ない場合は、回復性を最大限に高めるグローバル デプロイを使用します。

Azure AI Foundry では、モデルデプロイ用のラウンドロビン ルーティングや 回線切断などの高度な負荷分散またはフェールオーバー メカニズムはサポートされていません。 リージョン内で詳細な冗長性とフェールオーバー制御が必要な場合は、マネージド サービスの外部でモデル アクセス ロジックをホストします。 たとえば、Azure API Management を使用してカスタム ゲートウェイを構築できます。 この方法では、カスタム ルーティング、正常性チェック、フェールオーバー戦略を実装できます。 しかし、運用の複雑さが増し、そのコンポーネントの信頼性に対する責任がチームに移ります。

ゲートウェイフロント モデルは、エージェントのカスタム API ベースのツールまたはナレッジ ストアとして公開することもできます。 詳細については、「複数の Azure OpenAI デプロイまたはインスタンスの前にゲートウェイを使用する」を参照してください。

AI Search でのエンタープライズナレッジの信頼性

可用性ゾーンをサポートするリージョンで Standard 価格レベル以上を使用して AI Search をデプロイします。 サービスが個別の可用性ゾーンにインスタンスを分散するように、少なくとも 3 つのレプリカを構成します。 この構成は、ゾーン レベルの障害に対する回復性を提供し、検索操作の高可用性をサポートします。

ワークロードに最適なレプリカとパーティションの数を決定するには、次の方法を使用します。

  • 組み込みのメトリックとログを使用して AI Search を監視します。 クエリの待機時間、調整、およびリソースの使用状況を追跡します。

  • 監視メトリックとログとパフォーマンス分析を使用して、レプリカの適切な数を決定します。 この方法を使用すると、クエリの量が多い、パーティションが不十分、インデックスの制限による調整を回避できます。

  • インデックス作成の定期的なエラーやインデックス作成エラーの中断を回避することで、インデックス作成の信頼性を確保します。 データの整合性を検証した後は、オフライン インデックスにインデックスを作成し、ライブ インデックスから再構築インデックスにスワップすることを検討してください。

Azure Firewall の信頼性

Azure Firewall は、このアーキテクチャの重要なエグレス制御ポイントですが、すべての送信トラフィックの単一障害点を表します。 このリスクを軽減するには、リージョン 内のすべての可用性ゾーンに Azure Firewall をデプロイします。 この構成は、ゾーンが使用できなくなった場合に送信接続を維持するのに役立ちます。

ワークロードで大量の同時送信接続が必要な場合は、複数のパブリック IP アドレスを使用して Azure Firewall を構成します。 この方法では、ソース ネットワーク アドレス変換 (SNAT) 接続が 複数の IP アドレス プレフィックスに分散されるため、SNAT ポート枯渇のリスクが軽減されます。 SNAT の枯渇 により、エージェントやその他のワークロード コンポーネントの送信接続が断続的または完全に失われる可能性があり、これにより、機能のダウンタイムやパフォーマンスの低下が発生する可能性があります。

SNAT ポートの使用状況とファイアウォールの正常性を監視します。 接続エラーやスループットの問題が発生した場合は、ファイアウォールのメトリックとログを確認して、SNAT の枯渇やその他のボトルネックを特定して対処します。

Foundry Agent Service の依存関係を同様のワークロード コンポーネントから分離する

信頼性を最大化し、障害の爆発半径を最小限に抑えるには、Foundry Agent Service の依存関係を、同じ Azure サービスを使用する他のワークロード コンポーネントから厳密に分離します。 具体的には、エージェント サービスと他のアプリケーション コンポーネントの間で AI Search、Azure Cosmos DB、または Storage リソースを共有しないでください。 代わりに、エージェント サービスの必要な依存関係に専用インスタンスをプロビジョニングします。

この分離には、次の 2 つの主な利点があります。

  • これには、1 つのワークロード セグメントに対する障害またはパフォーマンスの低下が含まれており、関連のないアプリケーション機能全体に連鎖的な影響を与えるのを防ぎます。

  • これにより、バックアップ、復元、フェールオーバーなどの対象となる運用プロセスを適用できます。 これらのプロセスは、これらのリソースを使用するワークロード フローの特定の可用性と復旧の要件に合わせて調整されます。

たとえば、チャット UI アプリケーションで Azure Cosmos DB にトランザクション状態を格納する必要がある場合は、Foundry Agent Service が管理するアカウントまたはデータベースを再利用するのではなく、その目的のために別の Azure Cosmos DB アカウントとデータベースをプロビジョニングします。 コストや運用上のシンプルさがリソース共有の動機付けになる場合でも、信頼性イベントが関係のないワークロード機能に影響を与えるリスクは、ほとんどのエンタープライズ シナリオでの潜在的な節約を上回ります。

Important

コストや運用上の理由からワークロード固有のデータをエージェントの依存関係と併置する場合は、Foundry Agent Service によって作成されるシステム管理データ (コレクション、コンテナー、インデックスなど) と直接やり取りしないでください。 これらの内部実装の詳細は文書化されておらず、予告なしに変更されることがあります。 直接アクセスすると、エージェント サービスが中断されたり、データが失われる可能性があります。 忘れられる権利 (RTBF) 要求の実行など、データ操作には常に Foundry Agent Service データ プレーン API を使用します。 基になるデータを不透明でモニター専用として扱います。

複数リージョンの設計

このアーキテクチャでは、単一の Azure リージョン内の高可用性のために可用性ゾーンを使用します。 マルチリージョン ソリューションではありません。 リージョンの回復性とディザスター リカバリー (DR) に必要な次の重要な要素がありません。

  • グローバルイングレスとトラフィック ルーティング
  • フェールオーバーの DNS 管理
  • リージョン間でのデータ レプリケーションまたは分離戦略
  • アクティブ/アクティブ/パッシブ/アクティブ/コールドの指定
  • 復旧時間目標 (RTO) と復旧ポイント目標 (RPO) を満たすリージョンのフェールオーバーとフェールバック プロセス
  • Azure AI Foundry ポータルやデータ プレーン API など、開発者エクスペリエンスのリージョンの可用性に関する考慮事項

リージョンの停止が発生した場合にワークロードでビジネス継続性が必要な場合は、このアーキテクチャを超える追加のコンポーネントと運用プロセスを設計して実装する必要があります。 具体的には、次の領域を含め、各アーキテクチャ レイヤーでの負荷分散とフェールオーバーに対処する必要があります。

  • データの接地 (ナレッジ ストア)
  • モデルホスティングと推論エンドポイント
  • オーケストレーションまたはエージェントレイヤー
  • ユーザー向けの UI トラフィックと DNS エントリ ポイント

また、可観測性、監視、およびコンテンツの安全制御がリージョン間で動作し、一貫していることを確認する必要があります。

このベースライン アーキテクチャには複数リージョンの機能がないため、リージョンの停止によってワークロード内のサービスが失われる可能性があります。

障害復旧

チャット アーキテクチャにはステートフル コンポーネントが含まれているため、DR の計画が不可欠です。 通常、これらのワークロードには、アクティブなチャット セッションまたは一時停止されたチャット セッション用のメモリ ストアが必要です。 また、ドキュメントや画像などの補足データをチャット スレッドに追加するためのストレージも必要です。 エージェント オーケストレーション レイヤーでは、会話フローに固有の状態が維持される場合もあります。 このアーキテクチャでは、Foundry Agent Service は Azure Cosmos DB、Storage、AI Search を使用して、運用状態とトランザクション状態を保持します。 コンポーネント間でのこの状態のライフサイクルと結合によって、DR 戦略と復旧操作が決まります。

Foundry Agent Service の場合は、すべての依存関係を一貫した時点に回復できることを確認します。 このアプローチは、3 つの外部依存関係間でトランザクションの整合性を維持するのに役立ちます。

次の推奨事項は、DR の問題に対処するのに役立ちます。

  • Azure Cosmos DB: データベースのenterprise_memoryを有効にします。 このセットアップでは、ポイントインタイム リストア (PITR) と 7 日間の RPO が提供されます。これには、エージェント定義とチャット スレッドが含まれます。 復元プロセスを定期的にテストして、RTO を満たし、復元されたデータがエージェント サービスで引き続き使用できるかどうかを確認します。 常に同じアカウントとデータベースに復元します。

  • AI 検索: AI Search には組み込みの復元機能がなく、インデックスの直接操作はサポートされていません。 データの損失または破損が発生した場合は、インデックスの復元について Microsoft サポートに問い合わせる必要があります。 この制限は、RTO に大きく影響する可能性があります。 チャット UI でファイルのアップロードがサポートされておらず、静的ファイルをナレッジとして使用するエージェントがない場合は、AI Search の DR プランが必要ない可能性があります。

    企業の基礎知識に関する個別の定期的に更新された信頼のソースを維持します。 この方法により、必要に応じてインデックスを再構築できます。

  • 貯蔵： geo 冗長ストレージ アカウントがある場合は、Foundry Agent Service で使用される BLOB コンテナーに 対してカスタマー マネージド フェールオーバー を使用します。 このセットアップでは、リージョンの停止中にフェールオーバーを開始できます。 ゾーン冗長ストレージのみを使用する場合は、Microsoft サポートに問い合わせてデータを復元してください。 このプロセスによって RTO が拡張される場合があります。 AI Search と同様に、チャット UI でファイルのアップロードがサポートされておらず、静的ファイルを知識として使用するエージェントがない場合は、BLOB コンテナーの DR プランが必要ない可能性があります。

  • トランザクションの一貫性: ワークロード内の状態ストアが、スレッド ID やエージェント ID などの Azure AI エージェント識別子を参照している場合は、関連するすべてのデータ ストアの復旧を調整します。 依存関係のサブセットのみを復元すると、孤立したデータや不整合なデータが発生する可能性があります。 ワークロードとエージェント サービスの状態の間の参照整合性を維持するように DR プロセスを設計します。

  • エージェントの定義と構成: エージェント をコードとして定義します。 エージェント定義、接続、システム プロンプト、およびパラメーターをソース管理に格納します。 この方法では、オーケストレーション レイヤーを失った場合に、既知の適切な構成からエージェントを再デプロイできます。 AI Foundry ポータルまたはデータ プレーン API を使用して、エージェント構成に対して追跡されない変更を加えないようにします。 この方法により、デプロイされたエージェントを確実に再現できます。

  • AI Foundry プロジェクト: プロジェクトの ID には、ユーザー割り当てマネージド ID を使用します。 誤って削除されたときにプロジェクトを回復する必要がある場合、そのプロジェクトにユーザーマネージド ID を設定すると、プロジェクトとその機能ホストを再作成するときに既存のロールの割り当てを再利用でき、すべてのプロジェクト依存関係との変更調整を最小限に抑えることができます。

Azure AI Foundry エージェント サービスの依存関係に対する予防措置として、各サービスに 削除 リソース ロックを追加することをお勧めします。 これは、AI Search、Cosmos DB、Storage の状態の致命的な損失から保護するのに役立ちます。

運用環境に移行する前に、アプリケーション所有状態とエージェント所有状態の両方の障害に対処する復旧 Runbook を構築します。

セキュリティ

セキュリティは、意図的な攻撃や貴重なデータとシステムの誤用に対する保証を提供します。 詳細については、「セキュリティの設計レビュー チェックリスト」を参照してください。

このアーキテクチャは、 基本的な Azure AI Foundry チャット参照アーキテクチャで確立されたセキュリティ基盤を拡張します。 主な違いは、基本的なアーキテクチャからの ID 境界と共にネットワーク セキュリティ境界を追加することです。 ネットワークの観点から見ると、Application Gateway はインターネットに公開されている唯一のリソースです。 チャット UI アプリケーションをユーザーが使用できるようにします。 ID の観点から見ると、チャット UI は要求を認証し、承認する必要があります。 可能な場合はマネージド ID を使用して、Azure サービスに対してアプリケーションを認証します。

ID およびアクセス管理

このアーキテクチャでは、主にサービス間認証にシステム割り当てマネージド ID が使用されます。 ユーザー割り当てマネージド ID を使用することもできます。 どちらの場合も、次の原則を適用します。

  • リソースと関数によって ID を分離します。 次のコンポーネントの個別のマネージド ID をプロビジョニングします。

    • Azure AI Foundry アカウント
    • 各 Azure AI Foundry プロジェクト
    • Web アプリケーション
    • カスタム オーケストレーターまたは統合コード

  • Azure リソースに ID を割り当てるのは、そのリソースが別の Azure サービスに対してクライアントとして認証する必要がある場合のみです。

  • fit-for-purpose ID 型を使用します。 可能であれば、アプリケーションと自動化に ワークロード ID を 使用し、AI エージェントにはエージェント ID を 使用します。

接続

接続は、Azure AI Foundry アカウントまたは個々のプロジェクトが 外部依存関係に対して認証し、使用する方法を定義します。 可能な場合は、プロジェクト レベルで接続を作成します。 未使用の接続を削除します。 すべての接続に Microsoft Entra ID ベースの認証を使用します。

接続で Entra ID がサポートされていない場合は、シークレット (API キーなど) を指定する必要があります。 これらのシークレットは、専用のセルフホステッド Azure Key Vault に格納します。 サービスが管理するシークレットを読み書きできるように、Azure AI Foundry アカウントの Azure Key Vault 接続 を構成します。

この Key Vault は、Azure AI Foundry にのみ使用します。 他のワークロード コンポーネントと共有しないでください。 アカウント ストア内のすべてのプロジェクトで使用されるすべての非 Entra ID 接続は、そのシークレットをこの 1 つのコンテナーに格納します。 ワークロード内の追加のコンポーネントは、AI Foundry 機能を使用するためにこれらのシークレットにアクセスする必要はありません。また、明確な運用要件が存在するか、トレードオフが必要な場合を除き、このコンテナーに対する読み取りまたは書き込みのアクセス許可を付与しないでください。

このアーキテクチャには、2 つの API キー ベースの接続があります。AI Foundry テレメトリの Application Insights と、Bing Search を使用したグラウンド処理です。

暗号化にカスタマー マネージド キー (CMK) を使用する場合は、これに関するセキュリティ ガバナンス ポリシーに従って、CMK キーと接続シークレットの両方を同じ専用コンテナーでホストできます。

Azure AI Foundry ポータルの従業員アクセス

従業員を Azure AI Foundry プロジェクトにオンボードする場合は、ロールに必要な最小限のアクセス許可を割り当てます。 Microsoft Entra ID グループとロールベースのアクセス制御 (RBAC) を使用して、職務の分離を強制します。 たとえば、エージェント開発者と、微調整タスクを処理するデータ サイエンティストを区別します。 ただし、制限事項とリスクに注意してください。

Azure AI Foundry ポータルでは、従業員の ID ではなく、サービスの ID を使用して多くのアクションが実行されます。 その結果、RBAC ロールが制限されている従業員は、チャット スレッド、エージェント定義、構成などの機密データを可視化できる可能性があります。 この AI Foundry ポータルの設計では、意図したアクセス制約を誤ってバイパスし、意図したよりも多くの情報を公開する可能性があります。

不正アクセスのリスクを軽減するには、運用上の明確なニーズを持つ従業員に運用環境でのポータルの使用を制限します。 ほとんどの従業員は、運用環境で Azure AI Foundry ポータルへのアクセスを無効またはブロックします。 代わりに、自動デプロイ パイプラインとコードとしてのインフラストラクチャ (IaC) を使用して、エージェントとプロジェクトの構成を管理します。

Azure AI Foundry アカウントでの新しいプロジェクトの作成を特権アクションとして扱います。 ポータルを使用して作成されたプロジェクトは、プライベート エンドポイントやネットワーク セキュリティ グループ (NSG) などの確立されたネットワーク セキュリティ制御を自動的に継承しません。 また、これらのプロジェクトの新しいエージェントは、意図したセキュリティ境界をバイパスします。 制御された監査可能な IaC プロセスを通じてのみ、プロジェクトの作成を強制します。

Azure AI Foundry プロジェクト ロールの割り当てと接続

Foundry Agent Service を標準モードで使用するには、Foundry Agent Service の依存関係に対する管理アクセス許可がプロジェクトに必要です。 具体的には、プロジェクトのマネージド ID には、ストレージ アカウント、AI Search、Azure Cosmos DB アカウントに対する昇格されたロールの割り当てが必要です。 これらのアクセス許可は、データの読み取り、書き込み、変更、または削除の機能を含め、これらのリソースへのほぼ完全なアクセスを提供します。 最小限の特権アクセスを維持するには、Foundry Agent Service の依存関係からワークロード リソースを分離します。

1 つの AI Foundry プロジェクト内のすべてのエージェントは、同じマネージド ID を共有します。 ワークロードで、異なるリソース セットへのアクセスを必要とする複数のエージェントを使用する場合、最小特権の原則では、個別のエージェント アクセス パターンごとに個別の Azure AI Foundry プロジェクトを作成する必要があります。 この分離により、各プロジェクトのマネージド ID に最低限必要なアクセス許可のみを割り当てることが可能になり、過剰なアクセスや意図しないアクセスのリスクが軽減されます。

Azure AI Foundry 内から外部リソースへの 接続 を確立する場合は、Microsoft Entra ID ベースの認証 (使用可能な場合) を使用します。 この方法では、事前共有シークレットを維持する必要がなくなります。 所有するプロジェクトのみが使用できるように、各接続のスコープを設定します。 複数のプロジェクトが同じリソースにアクセスする必要がある場合は、プロジェクト間で 1 つの接続を共有するのではなく、各プロジェクトに個別の接続を作成します。 この方法では、厳密なアクセス境界が適用され、今後のプロジェクトが必要としないアクセスを継承できなくなります。

Azure AI Foundry アカウント レベルで接続を作成しないでください。 これらの接続は、アカウント内のすべての現在および将来のプロジェクトに適用されます。 リソースへの広範なアクセス権を誤って付与したり、最小限の特権原則に違反したり、不正なデータ漏洩のリスクを高めてしまう可能性があります。 プロジェクト レベルの接続のみを優先します。

ネットワーク

ID ベースのアクセスに加えて、このアーキテクチャにはネットワークの機密性が必要です。

ネットワーク設計には、次のセーフガードが含まれています。

  • すべてのチャット UI トラフィックに対してセキュリティで保護された単一のエントリ ポイント。攻撃対象領域を最小限に抑えます

  • NSG、Web アプリケーション ファイアウォール、ユーザー定義ルート (UDR)、および Azure Firewall 規則の組み合わせを使用してフィルター処理されたイングレスおよびエグレス ネットワーク トラフィック

  • TLS を使用した転送中のデータのエンドツーエンドの暗号化

  • すべての Azure PaaS サービス接続に Private Link を使用したネットワーク プライバシー

  • ネットワーク リソースの論理的なセグメント化と分離(詳細なセキュリティ ポリシーをサポートするための主要なコンポーネントグループごとに専用サブネットを使用)

ネットワーク フロー

ベースライン App Service Web アプリケーション アーキテクチャと Foundry Agent Service ネットワーク フローからの 2 つのネットワーク フローを示す図。

ベースライン App Service Web アプリケーション アーキテクチャでは、ユーザーからチャット UI への受信フローと、App Service から Azure PaaS サービスへのフローの概要が示されます。 このセクションでは、エージェントの対話について説明します。

チャット UI が Azure AI Foundry にデプロイされたエージェントと通信すると、次のネットワーク フローが発生します。

  1. App Service でホストされるチャット UI は、Azure AI Foundry データ プレーン API エンドポイントへのプライベート エンドポイントを介して HTTPS 要求を開始します。

  2. エージェントは、サービスの依存関係、カスタム ナレッジ ストア、カスタム ツールなどの Azure PaaS サービスにアクセスすると、委任されたサブネットからそれらのサービスのプライベート エンドポイントに HTTPS 要求を送信します。

  3. エージェントが仮想ネットワークの外部 (インターネット ベースの API や外部サービスを含む) にアクセスすると、委任されたサブネットから Azure Firewall 経由でそれらの HTTPS 要求をルーティングすることが強制されます。

プライベート エンドポイントは、ID ベースのセキュリティを補完することで、このアーキテクチャの重要なセキュリティ制御として機能します。 このアーキテクチャでは仮想ネットワーク内のプライベート エンドポイントと UDR が使用されるため、Azure AI Foundry プロジェクトの ネットワーク セキュリティ境界 機能はサポートされていません。

Azure AI Foundry へのイングレス

このアーキテクチャでは、Azure AI Foundry のプライベート リンク経由のトラフィックのみを許可することで、 Azure AI Foundry データ プレーンへのパブリック アクセスを無効にします。 Azure AI Foundry ポータルの多くは ポータル Web サイトからアクセスできますが、すべてのプロジェクト レベルの機能にはネットワーク アクセスが必要です。 ポータルは、プライベート エンドポイント経由でのみ到達可能な AI Foundry アカウントのデータ プレーン API に依存しています。 その結果、開発者とデータ サイエンティストは、ジャンプ ボックス、ピアリングされた仮想ネットワーク、ExpressRoute またはサイト間 VPN 接続を使用してポータルにアクセスする必要があります。

モデル推論を呼び出すときの Web アプリケーションや外部オーケストレーション コードなど、エージェント データ プレーンとのプログラムによる対話はすべて、これらのプライベート エンドポイントも使用する必要があります。 プライベート エンドポイントは、プロジェクト レベルではなくアカウント レベルで定義されます。 そのため、アカウント内のすべてのプロジェクトが同じエンドポイント のセットを共有します。 プロジェクト レベルでネットワーク アクセスをセグメント化することはできません。また、すべてのプロジェクトが同じネットワーク露出を共有します。

この構成をサポートするには、次の Azure AI Foundry FQDN API エンドポイントの DNS を設定します。

  • privatelink.services.ai.azure.com
  • privatelink.openai.azure.com
  • privatelink.cognitiveservices.azure.com

次の図は、AI 開発者が Azure Bastion を介して仮想マシン (VM) ジャンプ ボックスに接続する方法を示しています。 そのジャンプ ボックスから、作成者は同じネットワーク内のプライベート エンドポイントを介して Azure AI Foundry ポータルのプロジェクトにアクセスできます。

ユーザーが Azure Bastion 経由でジャンプ ボックス VM に接続する方法を示す図。

Azure AI Foundry エージェント サブネットからのトラフィックを制御する

このアーキテクチャは、Foundry Agent Service 機能から仮想ネットワーク内の委任されたサブネットを介して、すべての送信 (エグレス) ネットワーク トラフィックをルーティングします。 このサブネットは、エージェントに必要な 3 つのサービス依存関係と、エージェントが使用する外部ナレッジ ソースまたはツール接続の両方の唯一のエグレス ポイントとして機能します。 この設計は、オーケストレーション ロジック内からのデータ流出の試行を減らすのに役立ちます。

このエグレス パスを強制することで、送信トラフィックを完全に制御できます。 サービスを離れるすべてのエージェント トラフィックに、詳細な NSG ルール、カスタム ルーティング、DNS 制御を適用できます。

エージェント サービスは、仮想ネットワークの DNS 構成を使用して、プライベート エンドポイント レコードと必要な外部 FQDN を解決します。 このセットアップにより、エージェントの要求によって DNS ログが生成され、監査とトラブルシューティングがサポートされます。

エージェントエグレス サブネットにアタッチされている NSG は、正当なイングレスが発生しないため、すべての受信トラフィックをブロックします。 送信 NSG 規則では、仮想ネットワーク内のプライベート エンドポイント サブネットと、インターネットにバインドされたトラフィックの伝送制御プロトコル (TCP) ポート 443 へのアクセスのみが許可されます。 NSG は、他のすべてのトラフィックを拒否します。

インターネット トラフィックをさらに制限するために、このアーキテクチャはサブネットに UDR を適用し、すべての HTTPS トラフィックを Azure Firewall 経由で送信します。 ファイアウォールは、エージェントが HTTPS 接続を介して到達できる FQDN を制御します。 たとえば、エージェントが https://example.org/apiにのみアクセスする必要がある場合は、このサブネットからポート 443 でトラフィックを api.example.org できるように Azure Firewall を構成し、NSG でもそのトラフィックが許可されるようにします。

注

エージェントに接続されているすべてのナレッジ ツールがこのサブネットを通過するわけではありません。 たとえば、Bingパブリック API を使用した グラウンド処理 は、このサブネットからポート 443 でトラフィックを api.bing.microsoft.com できるように Azure Firewall で構成するのが理想的です。 ただし、その特定のツールは、エグレス サブネットを使用しないメカニズムを介してエージェント サービス内から呼び出されます。 ワークロードで考慮するすべての組み込みの知識とツール接続をテストして、それらがネットワーク エグレス制御ポリシーと一致しているかどうかを確認します。

仮想ネットワークのセグメント化とセキュリティ

このアーキテクチャでは、各主要コンポーネント グループを独自のサブネットに割り当てることで、仮想ネットワークをセグメント化します。 各サブネットには、受信トラフィックと送信トラフィックをコンポーネントに必要なもののみに制限する専用 NSG があります。

次の表は、各サブネットの NSG とファイアウォールの構成をまとめたものです。

使用状況またはサブネット名 受信トラフィック (NSG) 送信トラフィック (NSG) ファイアウォールへの UDR ファイアウォールエグレスルール
プライベート エンドポイント
snet-privateEndpoints		 仮想ネットワーク トラフィックは許可されていません Yes トラフィックは許可されていません
Application Gateway
snet-appGateway		 パブリック インターネットなどのチャット UI ユーザー ソース IP アドレスと、サービスに必要なソース プライベート エンドポイント サブネットとサービスに必要な項目 No -
App Service
snet-appServicePlan		 トラフィックは許可されていません プライベート エンドポイントと Azure Monitor Yes Azure Monitor へ
ファウンドリー エージェント サービス
snet-agentsEgress		 トラフィックは許可されていません プライベート エンドポイントとインターネット Yes エージェントの使用を許可するパブリック FQDN のみ
ジャンプ ボックス VM
snet-jumpBoxes		 Azure Bastion サブネット プライベート エンドポイントとインターネット Yes VM で必要に応じて
エージェントをビルドする
snet-buildAgents		 Azure Bastion サブネット プライベート エンドポイントとインターネット Yes VM で必要に応じて
Azure Bastion
AzureBastionSubnet		 NSG アクセスと Azure Bastion を参照する NSG アクセスと Azure Bastion を参照する No -
Azure Firewall
AzureFirewallSubnet
AzureFirewallManagementSubnet		 NSG なし NSG なし No -

この設計では、NSG 規則を介して、または Azure Firewall の既定で、他のすべてのトラフィックが明示的に拒否されます。

このアーキテクチャでネットワークのセグメント化とセキュリティを実装する場合は、次の推奨事項に従います。

  • ボリューム攻撃を軽減するために、Application Gateway パブリック IP アドレスに Azure DDoS Protection プランをデプロイします。

  • NSG をサポートするすべてのサブネットに アタッチ します。 必要な機能を中断することなく、可能な限り厳密な規則を適用します。

  • エグレス ファイアウォールがすべての送信トラフィックを検査できるように、サポートされているすべてのサブネットに 強制トンネリング を適用します。 エグレスが想定されないサブネットでも、強制トンネリングを使用します。 このメソッドは、サブネットの意図的または偶発的な誤用から保護する多層防御対策を追加します。

ポリシーによるガバナンス

ワークロードのセキュリティ ベースラインに合わせて調整するには、Azure Policy とネットワーク ポリシーを使用して、すべてのワークロード リソースが要件を満たしていることを確認します。 ポリシーを使用したプラットフォームの自動化により、セキュリティ構成の誤差のリスクが軽減され、手動検証アクティビティの削減に役立ちます。

アーキテクチャを強化するために、次の種類のセキュリティ ポリシーを実装することを検討してください。

  • Azure AI サービスや Key Vault などのサービスで、キーベースまたは他のローカル認証方法を無効にします。

  • ネットワーク アクセス規則、プライベート エンドポイント、NSG を明示的に構成する必要があります。

  • カスタマー マネージド キーなどの暗号化が必要です。

  • リージョンやリソースの種類の制限など、リソースの作成を制限します。

コストの最適化

コストの最適化では、不要な経費を削減し、運用効率を向上させる方法に重点を置いています。 詳細については、「コスト最適化の設計レビュー チェックリスト」を参照してください。

この Azure の価格見積もり では、このアーキテクチャの価格例を示します。 この例には、このアーキテクチャのコンポーネントのみが含まれているため、使用に合わせてカスタマイズします。 このシナリオで最もコストの高いコンポーネントは、Azure Cosmos DB、AI Search、DDoS Protection です。 その他の注目すべきコストには、チャット UI コンピューティングと Application Gateway が含まれます。 これらのリソースを最適化してコストを削減します。

ファウンドリー エージェント サービス

標準デプロイを使用する場合は、独自の Azure サブスクリプションでサービスの依存関係をプロビジョニングおよび管理する必要があります。

次の推奨事項では、これらの必要なサービスのコストを最適化する方法について説明します。

  • Foundry Agent Service は、Azure Cosmos DB での要求ユニット (RU) の割り当てを管理します。 長期的なコストを削減するには、Azure Cosmos DB の予約容量を購入します。 予約を予想される使用期間とボリュームに合わせます。 予約容量には事前のコミットメントが必要であり、ワークロードの使用パターンが大幅に変化する場合は柔軟性が欠けることに注意してください。

  • チャット シナリオでファイルのアップロードが必要ない場合は、アプリケーションでこの機能を除外します。 その場合は、次の構成変更を適用します。

    • ストレージ アカウントにはローカル冗長ストレージ (LRS) 層を使用します。
    • 推奨される 3 つのレプリカではなく、1 つのレプリカで AI Search を構成します。

  • SDK または REST API を使用して、未使用のエージェントとそれに関連付けられているスレッドを定期的に削除します。 古いエージェントとスレッドは引き続きストレージを消費するため、Azure Cosmos DB、Storage、AI Search 全体のコストが増加する可能性があります。

  • 次の機能など、ワークロードで必要としない依存リソースの機能を無効にします。

    • AI Search のセマンティック ランカー
    • Azure Cosmos DB のゲートウェイと複数リージョンの書き込み機能

  • リージョン間の帯域幅の課金を回避するには、Foundry Agent Service と同じ Azure リージョンに Azure Cosmos DB、Storage、AI Search をデプロイします。

  • Foundry Agent Service が使用するのと同じ Azure Cosmos DB または AI Search リソースにワークロード固有のデータを併置しないようにします。 場合によっては、これらのリソースを共有して RU または検索ユニットの未使用容量を削減し、コストを削減できます。 信頼性、セキュリティ、パフォーマンスのトレードオフに関する徹底的なリスク評価の後にのみ、リソース共有を検討してください。

エージェントの知識とツール

Foundry Agent Service は、非決定的な方法でエージェント ロジックを実行します。 そのリソースがユーザー クエリに関連しない場合でも、接続されているナレッジ ストア、ツール、またはその他のエージェントを要求ごとに呼び出すことができます。 この動作により、外部 API またはデータ ソースへの不要な呼び出しが発生し、各トランザクションのコストが増加し、予算予測を複雑にする予測不可能な使用パターンが発生する可能性があります。

コストを制御し、予測可能な動作を維持するには、次の戦略を適用します。

  • ほとんどのエージェント呼び出しで使用される可能性が高いナレッジ ストア、ツール、またはエージェントのみを接続します。 ほとんど必要ないリソースや、必要でない限り、呼び出しごとに高コストが発生するリソースの接続は避けてください。

  • 不要な外部呼び出しや冗長な外部呼び出しを最小限に抑えるようにエージェントに指示するように、システム プロンプトを慎重に設計して調整します。 システム プロンプトでは、各要求に最も関連性の高い接続のみを使用するようにエージェントに指示する必要があります。

  • Azure AI Foundry テレメトリを使用して、エージェントがアクセスする外部 API、ナレッジ ストア、またはツール、それらにアクセスする頻度、および関連するコストを監視します。 このテレメトリを定期的に確認して、予期しない使用パターンやコストの急増を特定し、必要に応じてシステム プロンプトを調整します。

  • 特に従量制課金 API と統合する場合は、非決定的呼び出しによってコスト予測が困難になる可能性があることに注意してください。 予測可能なコストが必要な場合は、決定論的コードを使用してオーケストレーターを自己ホストすることを検討してください。

Azure OpenAI のモデル

Azure AI Foundry のモデル デプロイでは、MaaS アプローチが使用されます。 コストは、主に使用量または事前プロビジョニングされた割り当てによって異なります。

このアーキテクチャで消費モデルのコストを制御するには、次の方法を組み合わせて使用します。

  • クライアントを制御します。 クライアント要求は従量課金モデルでほとんどのコストを消費するため、エージェントの動作を制御することが重要です。

    不要な使用を減らすには、次のアクションを実行します。

    • すべてのモデル コンシューマーを承認します。 無制限のアクセスを許可する方法でモデルを公開しないでください。

    • エージェント ロジックを使用して、 max_tokens や max_completions などのトークン制限制約を適用します。 このコントロールは、セルフホステッド オーケストレーションでのみ使用できます。 Foundry Agent Service では、この機能はサポートされていません。

    • プロンプトの入力と応答の長さを最適化します。 プロンプトが長いほど、より多くのトークンが消費されるため、コストが増加します。 十分なコンテキストがないプロンプトにより、モデルの有効性が低下します。 モデルが有用な応答を生成できるようにするのに十分なコンテキストを提供する簡潔なプロンプトを作成します。 応答の長さの制限を最適化してください。

      このレベルの制御は、セルフホステッド オーケストレーションでのみ使用できます。 Foundry Agent Service では、この機能をサポートするための十分な構成が提供されていません。

  • エージェントに適したモデルを選択します。 エージェントの要件を満たす最も安価なモデルを選択します。 必要でない限り、コストの高いモデルの使用は避けてください。 たとえば、参照実装では、より高価なモデルではなく GPT-4o が使用され、十分な結果が得られます。

  • 使用状況を監視および管理します。 Microsoft Cost Management とモデル テレメトリを使用して、トークンの使用状況を追跡し、予算を設定し、異常のアラートを作成します。 使用パターンを定期的に確認し、必要に応じてクォータまたはクライアント アクセスを調整します。 詳細については、「 Azure AI Foundry のコストの計画と管理」を参照してください。

  • 適切なデプロイ タイプを使用します。 予測できないワークロードには従量課金制の価格を使用し、使用量が安定していて予測可能な場合はプロビジョニング済みスループットに切り替えます。 信頼できるベースラインを確立するときに、両方のオプションを組み合わせます。

  • 遊び場の使用を制限します。 計画外の運用コストを防ぐには、Azure AI Foundry プレイグラウンドの使用を実稼働前環境のみに制限します。

  • 微調整とイメージ生成を慎重に計画します。 これらの機能には異なる課金モデルがあります。 これらは、1 時間ごとまたはバッチごとに課金されます。 課金間隔に合わせて使用量をスケジュールし、無駄を避けます。

ネットワーク セキュリティ リソース

このアーキテクチャでは、エグレス制御ポイントとして Azure Firewall が必要です。 コストを最適化するには、ワークロード コンポーネントの残りの部分に高度な機能が必要でない限り、Azure Firewall の Basic レベルを使用します。 上位レベルではコストが追加されるため、機能が必要な場合にのみ使用します。

組織で Azure ランディング ゾーンを使用している場合は、共有ファイアウォールと分散型サービス拒否 (DDoS) リソースを使用して、コストを延期または削減することを検討してください。 セキュリティとパフォーマンスの要件が似ているワークロードは、共有リソースの恩恵を受けることができます。 共有リソースによってセキュリティや運用上のリスクが生じないようにします。 このアーキテクチャは、 Azure ランディング ゾーンにデプロイされ、共有リソースを使用します。

Microsoft Defender for Cloud

このアーキテクチャでは、次の Cloud Workload Protection プランを有効にし、ワークロードの関連リソースをカバーする必要があります。

Plan メリット
Defender for Servers 脆弱性評価やファイル整合性の監視などの機能は、高い特権を持つジャンプ ボックスやビルド エージェントの役割が脅威ベクトルになることを防ぐのに役立ちます。
アプリサービス用ディフェンダー チャット インターフェイス コンポーネントのログ、ホスト マシン、管理インターフェイスのセキュリティ監視を提供します。
Defender for Azure Cosmos DB チャット スレッドを含むデータベースのデータベース操作の監視を提供し、ユーザーのチャット データとエージェント定義の不正使用や不規則なアクセスの兆候を探します。
Defender for AI サービス ワークロードの要求とエージェントへの応答に基づいてアラートを提供します。脱獄またはデータ漏洩の試行に関するアラート。 組織で Microsoft Purview を使用している場合、このプランでは、ライセンス付き統合と Microsoft Purview DSPM for AI も有効になります。

組織がセキュリティ情報イベント管理 (SIEM) ソリューションをホストしている場合、または Microsoft Purview を使用している場合は、データ ストアにレプリケートされるプロンプトや応答などの顧客データが、ワークロードに必要なデータ主権の制限に違反しないリージョンに存在することを確認します。

オペレーショナル エクセレンス

オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスのデザイン レビュー チェック一覧」を参照してください。

次のオペレーショナル エクセレンス ガイダンスには、ベースラインの 高可用性ゾーン冗長 Web アプリケーション アーキテクチャと同じままのフロントエンド アプリケーション要素は含まれていません。

実験、テスト、運用環境を計画するときは、依存関係を含む、個別の分離された AI Foundry リソースを確立します。

エージェント コンピューティング

Microsoft は、Azure AI エージェント REST API のサーバーレス コンピューティング プラットフォームとオーケストレーション実装ロジックを完全に管理します。 セルフホステッド オーケストレーションでは、ランタイムの特性と容量をより詳細に制御できますが、そのプラットフォームの day-2 操作を直接管理する必要があります。 オーケストレーション レイヤーをサポートするために実装する必要がある 2 日目の操作を理解するために、アプローチの制約と責任を評価します。

どちらの方法でも、チャット履歴や、持続性、バックアップ、回復のためのエージェント構成などの状態ストレージを管理する必要があります。

Monitoring

基本的なアーキテクチャと同様に、すべてのサービスの診断データがワークロードの Log Analytics ワークスペースに送信されるように構成されています。 App Service を除くすべてのサービスは、すべてのログをキャプチャします。 運用環境では、すべてのログをキャプチャする必要がない場合があります。 たとえば、チャット UI アプリケーションでは、 AppServiceHTTPLogs、 AppServiceConsoleLogs、 AppServiceAppLogs、 AppServicePlatformLogs、 AppServiceAuthenticationLogsのみが必要な場合があります。 運用上のニーズに合わせてログ ストリームを調整します。

このアーキテクチャのリソースのカスタム アラート (Azure Monitor ベースライン アラートのカスタム アラートなど) を評価します。 次のアラートについて考えてみましょう。

モデルのデプロイに対するトークンの使用状況を監視します。 このアーキテクチャでは、Azure AI Foundry は Application Insights との統合を通じて トークンの使用状況 を追跡します。

ジャンプ ボックスとビルド エージェント VM は、高い特権を持つ場所に存在します。これらの VM は、アーキテクチャ内のすべてのコンポーネントのデータ プレーンにネットワークの見通し線を提供します。 これらの VM で、使用されるタイミング、使用するユーザー、実行するアクションを把握するのに十分なログが出力されていることを確認します。

エージェントのバージョン管理とライフ サイクル

実行時にエージェントを動的に作成および削除するようにアプリケーションを特別に設計しない限り、各エージェントはチャット ワークロード内で個別にデプロイ可能な単位として扱います。 これらのエージェントには、ワークロード内の他のマイクロサービスと同様のライフサイクル管理要件があります。

サービスの中断を防ぐには、次の方法を実装して、安全で制御されたエージェントのデプロイを確保します。

  • エージェントをコードとして定義します。 エージェント定義、接続、システム プロンプト、および構成パラメーターをソース管理に常に格納します。 この方法により、トレーサビリティと再現性が確保されます。 Azure AI Foundry ポータルを使用して、追跡されていない変更を回避します。

  • エージェントのデプロイを自動化します。 ワークロードの継続的インテグレーションと継続的デプロイ (CI/CD) パイプラインを使用します。 Azure AI Agent SDK を使用して、ネットワークに接続されたビルド エージェントからエージェントの変更をビルド、テスト、デプロイします。

    小規模な増分変更のために個別にデプロイできるエージェント パイプラインを優先します。 ただし、調整された更新が必要な場合は、パイプラインがアプリケーション コードと共にデプロイするのに十分な柔軟性を提供することを確認します。 この方法をサポートするには、チャット UI コードとチャット エージェントを疎結合して、1 つのコンポーネントに対する変更で他方に同時に変更を加える必要がないようにします。

  • 運用環境の前にテストします。 実稼働前環境でのエージェントの動作、プロンプト、接続を検証します。 自動テストと手動テストの組み合わせを使用して、回帰、セキュリティの問題、およびエージェントの動作の意図しない変更をキャッチします。

    Foundry Agent Service で定義されているエージェントは非決定的に動作するため、目的の品質レベルを測定して維持する方法を決定する必要があります。 現実的なユーザーの質問やシナリオに対する理想的な回答をチェックするテスト スイートを作成して実行します。

  • エージェントのバージョン管理と追跡。 各エージェントにクリア バージョン識別子を割り当てます。 アクティブなエージェント バージョンのレコードと、その依存関係 (モデル、データ ソース、ツールなど) を保持します。 ユーザーまたはセッションの段階的なロールアウト、ロールバック、制御された移行を有効にするには、既存のエージェント バージョンと共に新しいエージェント バージョンをデプロイすることをお勧めします。

  • フェールバックを計画します。 Azure AI Foundry では、エージェントのブルー グリーンデプロイまたはカナリア デプロイに対する組み込みのサポートは提供されていません。 これらのデプロイ パターンが必要な場合は、API ゲートウェイやカスタム ルーターなどのルーティング層をエージェント API の前に実装します。 このルーティング層を使用すると、エージェントのバージョン間でトラフィックを段階的にシフトし、影響を監視し、準備ができたら完全な切り替えを実行できます。

  • エージェントの削除を調整します。 エージェントを削除するときは、アプリケーションの状態管理とユーザー エクスペリエンスの要件に合わせてプロセスを調整します。 アクティブなチャット セッションを適切に処理します。 ワークロードの機能要件に応じて、セッションの移行、古いエージェント バージョンへのユーザーのピン留め、または新しいセッションの開始をユーザーに要求することができます。

パフォーマンス効率

パフォーマンス効率とは、ユーザーの要求を効率的に満たすためにスケーリングするワークロードの能力を指します。 詳細については、「パフォーマンス効率の設計レビュー チェックリスト」を参照してください。

このセクションでは、AI Search、モデル デプロイ、Azure AI Foundry のパフォーマンス効率について説明します。

Foundry Agent Service では、エージェントはコードレスであるため、インデックスに送信される特定のクエリを制御しません。 パフォーマンスを最適化するには、インデックスで制御できる内容に焦点を当てます。 エージェントが通常インデックスに対してクエリを実行する方法を確認し、 AI Search のパフォーマンスを分析および最適化するためのガイダンスを適用します。

インデックス サーバーのチューニングだけではすべてのボトルネックが解決されない場合は、次のオプションを検討してください。

  • AI Search への直接接続を、所有する API への接続に置き換えます。 この API は、エージェントの取得パターンに合わせて最適化されたコードを実装できます。

  • 独自のオーケストレーター コードでクエリを定義および最適化できるように、 セルフホステッド代替 手段を使用するようにオーケストレーション レイヤーを再設計します。

モデルデプロイにおけるパフォーマンス効率

  • アプリケーションで プロビジョニングされたスループットが 必要か、共有 (消費) モデルを使用できるかを判断します。 プロビジョニングされたスループットにより、予約容量と予測可能な待機時間が提供されます。これは、厳密なサービス レベルの目標を持つ運用ワークロードにとって重要です。 従量課金モデルはベスト エフォート サービスを提供し、ノイズの多い近隣の影響を受ける可能性があります。

  • プロビジョニングで管理された使用状況を監視して、オーバープロビジョニングやプロビジョニング不足を回避します。

  • 推論の待機時間の要件を満たす会話型モデルを選択します。

  • ネットワーク待ち時間を最小限に抑えるために、エージェントと同じデータリージョンにモデルをデプロイします。

Azure AI エージェントのパフォーマンス

Azure AI エージェントは、カスタム パフォーマンス チューニングをサポートしていないサーバーレス コンピューティング バックエンドで実行されます。 ただし、エージェントの設計によってパフォーマンスを向上させることができます。

  • チャット エージェントに接続されているナレッジ ストアとツールの数を最小限に抑えます。 エージェントは要求ごとに構成されたすべてのリソースを呼び出す可能性があるため、追加の接続ごとにエージェント呼び出しの合計ランタイムが増加する可能性があります。

  • Azure Monitor と Application Insights を使用して、エージェントの呼び出し時間、ツールとナレッジ ストアの待機時間、エラー率を追跡します。 このテレメトリを定期的に確認して、低速な知識またはツール接続を特定します。

  • 接続を効率的に使用するようにエージェントをガイドするシステム プロンプトを設計します。 たとえば、必要な場合にのみ外部ナレッジ ストアにクエリを実行するか、冗長なツール呼び出しを回避するようにエージェントに指示します。

  • ピーク時のパフォーマンスに影響する可能性があるサービスの制限またはクォータを監視します。 サーバーレス コンピューティングが自動的にスケーリングされる場合でも、HTTP 429 や 503 応答などの調整インジケーターを監視します。

このシナリオのデプロイ

この参照実装をデプロイして実行するには、 Foundry Agent Service チャット ベースラインリファレンス実装のデプロイ ガイドに従ってください。

Contributors

Microsoft では、この記事を保持しています。 次の共同作成者がこの記事を書きました。

主要な著者:

  • Rob Bagby |プリンシパル コンテンツ開発者 - Azure パターンとプラクティス
  • チャド・キットテル |プリンシパル ソフトウェア エンジニア - Azure パターンとプラクティス

その他の共同作成者:

公開されていない LinkedIn プロフィールを見るには、LinkedIn にサインインしてください。

次のステップ