Azure App Service
Azure Monitor
Microsoft Foundry
Foundry エージェント サービス
Azure AI Foundry SDK
この記事では、Foundry Models で Microsoft Foundry および Azure OpenAI を使用してチャット アプリケーションを実行する方法を学習するのに役立つ基本的なアーキテクチャについて説明します。 このアーキテクチャには、Azure App Serviceで実行されるクライアント ユーザー インターフェイス (UI) が含まれています。 言語モデルのグラウンド データをフェッチするために、UI は Foundry Agent Service でホストされているエージェントを使用して、受信プロンプトからデータ ストアへのワークフローを調整します。 アーキテクチャは 1 つのリージョンで実行されます。
Important
このアーキテクチャは運用環境向けではありません。 これは、学習と概念実証 (POC) を目的とした入門アーキテクチャです。 運用チャット アプリケーションを設計するときは、 Baseline Foundry チャット参照アーキテクチャを使用します。このアーキテクチャにより、運用設計の決定が追加されます。
Important
Architecture
このアーキテクチャのVisioファイルをダウンロードしてください。
Workflow
次のワークフローは、上記のダイアグラムに対応しています。
アプリケーション ユーザーは、チャット機能を含む Web アプリケーションと対話します。
azurewebsites.netで App Service の既定のドメインに HTTPS 要求を発行します。 このドメインは、App Service の組み込みパブリック IP アドレスを自動的に指します。 トランスポート層セキュリティ接続は、クライアントから App Service に直接確立されます。 Azureは証明書を完全に管理します。Easy Auth と呼ばれる App Service 機能を使用すると、Web サイトにアクセスするユーザーが Microsoft Entra ID 経由で認証されます。
App Service にデプロイされたアプリケーション コードは、要求を処理し、アプリケーション ユーザーのチャット UI をレンダリングします。 チャット UI コードは、同じ App Service インスタンスでホストされている API に接続します。 API コードは、Azure AI Persistent Agents SDK を使用してエージェント サービス内のエージェントに接続します。
エージェント サービスは、Azure AI 検索に接続するか、最新の公開ナレッジをリクエストして、クエリの基礎データを取得します。 次の手順でモデルに送信されるプロンプトに、接地データが追加されます。
エージェント サービスは、Foundry にデプロイされている Azure OpenAI モデルに接続し、関連するグラウンド データとチャット コンテキストを含むプロンプトを送信します。
Application Insights は、App Service とエージェントの対話に対する元の要求に関する情報をログに記録します。
Components
チャット UI はそのアーキテクチャに基づいているため、このアーキテクチャのコンポーネントの多くは 、基本的な App Service Web アプリケーション アーキテクチャ と同じです。 このセクションでは、データ サービス、チャット フローの構築と調整に使用できるコンポーネント、および言語モデルを公開するサービスについて説明します。
Foundry は、AI ソリューションとサービスとしてのモデル (MaaS) の構築、テスト、デプロイに使用するプラットフォームです。 このアーキテクチャでは、Foundry を使用して、Azure OpenAI モデルをデプロイします。
Foundry プロジェクトは、データ ソースへの接続を確立し、エージェントを定義し、デプロイされたモデル (Azure OpenAI モデルを含む) を呼び出します。 このアーキテクチャには、Foundry アカウント内に Foundry プロジェクトが 1 つだけ含まれます。
エージェント サービス は、Foundry でホストされている機能です。 このサービスを使用して、チャット要求を処理するエージェントを定義およびホストします。 チャット会話の履歴を管理し、ツール呼び出しを調整し、コンテンツの安全性を強制し、ID、ネットワーク、および監視システムと統合します。 このアーキテクチャでは、エージェント サービスは、AI Search やその他の接続されたツールからグラウンド データをフェッチし、デプロイされたモデルにプロンプトで渡すフローを調整します。
エージェント サービスで定義されているエージェントはコードレスであり、実質的に非決定的です。 エージェントのシステム プロンプトは、
temperatureパラメーターとtop_pパラメーターと組み合わされ、制約付きナレッジ接続によって、すべての要求に対するエージェントの動作を定義します。Foundry Models を使用すると、openAI モデルを含むフラグシップ モデルを、Microsoftホスト環境の Azure AI カタログからデプロイできます。 このアプローチは MaaS デプロイと見なされます。 このアーキテクチャでは、固定クォータで Global Standard 構成を使用してモデルをデプロイします。
AI Search は、フルテキスト検索、セマンティック検索、 ベクター検索 、ハイブリッド検索をサポートするクラウド検索サービスです。 このアーキテクチャには AI Search が含まれています。これは、チャット アプリケーションの背後にあるオーケストレーションでよく使用されるためです。 AI Search を使用して、ユーザー クエリに関連するインデックス付きデータを取得します。 AI Search は、 検索拡張生成 パターンのナレッジ ストアとして機能します。 このパターンは、プロンプトからクエリを抽出し、AI Search にクエリを実行し、その結果をモデルの接地データとして使用します。
考慮事項
これらの考慮事項は、Azure Well-Architected Framework の柱を実装します。これは、ワークロードの品質を向上させるために使用できる一連の基本原則です。 詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。
この基本的なアーキテクチャは、運用環境向けではありません。 エンド ツー エンドのチャット アプリケーションを構築する方法を学習できるように、機能よりもシンプルさとコスト効率が優先されます。 次のセクションでは、不備と推奨事項について説明します。 これらの省略は、セットアップ時間を最小限に抑えるために意図的に行われます。 運用環境ではこのトポロジを使用しないでください。各省略によってリスクが増加します。
Reliability
信頼性は、アプリケーションが顧客に対して行ったコミットメントを確実に満たすことができるのに役立ちます。 詳細については、「信頼性の設計レビュー チェックリスト」を参照してください。
次の一覧は、このアーキテクチャで省略されている重要な信頼性機能の概要を示しています。
このアーキテクチャでは、Azure可用性ゾーンサポートされていない App Service Basic レベルを使用します。 インスタンス、ラック、またはデータセンターに問題がある場合、インスタンスは使用できなくなります。 運用環境に移行するときは、 App Service インスタンスの信頼性に関するガイダンスに従ってください。
このアーキテクチャでは、クライアント UI の自動スケールは有効になりません。 容量の問題を回避するには、学習中にコンピューティングをオーバープロビジョニングします。 本番環境に入る前にオートスケールを実装します。
このアーキテクチャでは、エージェント サービスを完全にMicrosoftホストされたソリューションとしてデプロイします。 Microsoftは、依存サービス (Cosmos DB、Storage、AI Search) をユーザーに代わってホストします。 サブスクリプションにこれらのリソースが表示されません。 あなたはそれらの信頼性の特性を制御できません。 独自の依存関係の導入に関するガイダンスについては、 ベースライン アーキテクチャを参照してください。
注
コンポーネント セクションと図の AI Search インスタンスは、Agent Service の依存関係であるインスタンスとは異なります。 components セクションのインスタンスには、グラウンド データが格納されます。 この依存関係は、チャット セッション内またはエージェントの定義の一部としてアップロードされたファイルのリアルタイム チャンクを実行します。
学習には、グローバル標準モデルのデプロイの種類を使用します。 本番環境に入る前に、スループットとデータレジデンシーのニーズを見積もります。 予約済みスループットが必要な場合は、 Data Zone Provisioned または Global Provisioned デプロイの種類を選択します。 明示的な常駐要件には、プロビジョニングされたデータ ゾーンを使用します。
このアーキテクチャでは、Azure 可用性ゾーンをサポートしていない AI Search Basic レベルを使用します。 ゾーンの冗長性を確保するには、ゾーン対応リージョンで Standard レベル以上を使用し、3 つ以上のレプリカをデプロイします。
詳細については、「 ベースライン Foundry チャット参照アーキテクチャ」を参照してください。
セキュリティ
セキュリティは、意図的な攻撃や貴重なデータとシステムの誤用に対する保証を提供します。 詳細については、「セキュリティの設計レビュー チェックリスト」を参照してください。
このセクションでは、このアーキテクチャで実装される主な推奨事項について説明します。 これらの推奨事項には、コンテンツのフィルター処理と不正使用の監視、ID とアクセスの管理、ロールベースのアクセス制御が含まれます。 このアーキテクチャは運用環境のデプロイ用に設計されていないため、このセクションにはネットワーク セキュリティに関する考慮事項も含まれています。 ネットワーク セキュリティは、このアーキテクチャでは実装されていない重要なセキュリティ機能です。
コンテンツのフィルタリングと不正使用の監視
Foundry には、分類モデルの組み合わせを使用する ガードレールとコンテンツ フィルタリング システム が含まれています。 このフィルター処理では、入力プロンプトと出力完了で有害な可能性があるコンテンツの特定のカテゴリを検出してブロックします。 この潜在的に有害なコンテンツには、ヘイト、性的コンテンツ、自傷行為、暴力、不適切な表現、脱獄 (言語モデルの制限をバイパスするように設計されたコンテンツ) カテゴリが含まれます。 低、中、または高のオプションを使用して、各カテゴリのフィルターの厳密さを構成できます。 この参照アーキテクチャでは、モデルのデプロイ時に DefaultV2 コンテンツ フィルターを使用します。 要件に応じて設定を調整する必要があります。
ID およびアクセス管理
次のガイダンスでは、App Service ベースライン アーキテクチャの
Foundry プロジェクトにもマネージド ID があります。 この ID は、接続定義を介して AI Search などのサービスに対して認証されます。 このプロジェクトでは、エージェント サービスでこれらの接続を使用できるようになります。
Foundry アカウントには、複数の Foundry プロジェクトを含めることができます。 各プロジェクトでは、独自のマネージド ID を使用する必要があります。 異なるワークロード コンポーネントで接続されたデータ ソースへの分離アクセスが必要な場合は、同じアカウント内に個別の Foundry プロジェクトを作成し、それらの間で接続を共有しないようにします。 ワークロードで分離が必要ない場合は、1 つのプロジェクトを使用します。
役割に基づくアクセス権
マネージド ID に必要なロールの割り当てを作成する必要があります。 次の表は、App Service、Foundry プロジェクト、およびポータルを使用する個人に追加する必要があるロールの割り当てをまとめたものです。
| Resource | Role | Scope |
|---|---|---|
| App Service | Azure AI ユーザー | Foundry アカウント |
| Foundry プロジェクト | 検索インデックス データリーダー | AI検索 |
| ポータル ユーザー (個人ごと) | Azure AI 開発者 | Foundry アカウント |
ネットワークのセキュリティ
エンド ツー エンドのチャット ソリューションを構築するための学習エクスペリエンスを簡略化するために、このアーキテクチャではネットワーク セキュリティは実装されません。 ID を境界として使用し、パブリック クラウドコンストラクトを使用します。 インターネットから AI Search、Foundry、App Service などのサービスにアクセスできます。 この設定により、アーキテクチャの攻撃対象領域が増加します。
このアーキテクチャでは、エグレス トラフィックも制限されません。 たとえば、エージェントは、エンドポイントの OpenAPI 仕様に基づいて任意のパブリック エンドポイントに接続するように構成できます。 そのため、プライベート グラウンド データのデータ流出は、ネットワーク制御を通じて防止することはできません。
アーキテクチャの追加境界としてのネットワーク セキュリティの詳細については、 ベースライン アーキテクチャのネットワークを参照してください。
このソリューションの評価中にネットワーク セキュリティが必要な場合は、Foundry プロジェクトで ネットワーク セキュリティ境界のサポート を使用する必要があります。 この方法では、アーキテクチャに仮想ネットワーク リソースを実装する前に、イングレスとエグレスを制御できます。 エージェント サービスが標準のプライベートデプロイ用に構成されている場合、ネットワーク セキュリティ境界はPrivate Link接続に置き換えられます。
Microsoft Defender for Cloud
この基本的なアーキテクチャでは、どのサービスでもクラウド ワークロード保護プランMicrosoft Defender有効にする必要はありません。 運用環境に移行する場合は、ワークロードをカバーするために複数のプランを使用するMicrosoft Defenderのベースライン アーキテクチャの
ポリシーによるガバナンス
このアーキテクチャでは、Azure Policyによるガバナンスは実装されません。 運用環境に移行するときは、 ベースライン アーキテクチャのガバナンスに関する推奨事項に従ってください。 これらの推奨事項により、ワークロードのコンポーネント全体にAzure Policyが追加されます。
コストの最適化
コストの最適化では、不要な経費を削減し、運用効率を向上させる方法に重点を置いています。 詳細については、「コスト最適化の設計レビュー チェックリスト」を参照してください。
この基本的なアーキテクチャは、運用対応ソリューションのコストを表すわけではありません。 また、コストオーバーランから保護するコントロールも含まれません。 次の考慮事項では、このアーキテクチャに含まれていない重要な機能について説明します。 これらの機能はコストに影響します。
このアーキテクチャでは、モデル呼び出しが制限されていることを前提としています。 プロビジョニングされたスループットの代わりに、グローバル標準デプロイの種類 (従量課金制) を使用します。 運用環境に移行するときは、ベースライン アーキテクチャの コスト最適化ガイダンス に従ってください。
エージェント サービスでは、チャット操作中にアップロードされたファイルのコストが発生します。 目的のユーザー エクスペリエンスの一部でない場合は、アプリケーション ユーザーがファイルアップロード機能を使用できないようにします。 Web Search ツールなどの追加のナレッジ接続には、独自の価格構造があります。
Agent Service はコードなしのソリューションです。 各要求が呼び出すツールまたはナレッジ ソースを決定論的に制御することはできません。 コスト モデリングでは、各接続の最大使用量を想定します。
このアーキテクチャでは、1 つのインスタンスで App Service Basic 価格レベルを使用します。 可用性ゾーンの停止からの保護は提供されません。 ベースライン App Service アーキテクチャでは、高可用性のために 3 つ以上の worker インスタンスを含む Premium プランが推奨されます。
このアーキテクチャでは、レプリカが追加されていない AI Search Basic 価格レベルを使用します。 このトポロジは、ゾーン障害に耐えられません。 ベースラインのエンド ツー エンド チャット アーキテクチャでは、Standard レベル以上と 3 つ以上のレプリカが推奨されます。
このアーキテクチャには、コスト ガバナンスやコンテインメント制御は含まれません。 Azure予算とアラートを早期に設定して、予期しないトークンやツールの使用から保護します。
予算作成の場合は、シナリオに合わせて、このアーキテクチャの 料金計算ツールの見積もり を変更します。
オペレーショナル エクセレンス
オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスのデザイン レビュー チェック一覧」を参照してください。
モニタリング
このアーキテクチャでは、すべてのサービスの診断を構成します。 App Service は、 AppServiceHTTPLogs、 AppServiceConsoleLogs、 AppServiceAppLogs、および AppServicePlatformLogsをキャプチャします。 Foundry は RequestResponseをキャプチャします。 POC フェーズ中に、使用可能なログとメトリックをインベントリします。 運用環境の前に、価値を追加しないソースを削除します。
Foundry の監視機能を使用するには、 Application Insights リソースを Foundry プロジェクトに接続します。
この統合により、次の監視が可能になります。
- プロンプト、完了、トークンの合計など、トークンの使用状況をリアルタイムで監視する
- 待機時間、例外、応答品質など、要求と応答のテレメトリの詳細
分散診断に OpenTelemetry を使用してエージェントをトレース することもできます。
モデル操作
このアーキテクチャは学習用に最適化されており、運用環境向けではありません。 ワークロードを促進する前に、モデル ライフサイクル管理と モデルの廃止と廃止 を計画します。
発達
基本的なアーキテクチャでは、Foundry ポータルでブラウザー ベースのエクスペリエンスを使用してエージェントを作成できます。 運用環境に移行する場合は、ベースライン アーキテクチャの 開発とソース管理のガイダンス に従ってください。 エージェントが不要になったら、必ず削除してください。 削除するエージェントが接続を使用する最後のエージェントである場合は、接続も削除します。
Evaluation
Foundry で生成アプリケーションを評価します。 エバリュエーターの使用方法について説明します。 これにより、モデル、プロンプト、およびデータ品質が設計要件を満たすことができます。
パフォーマンス効率
パフォーマンス効率とは、ユーザーの要求を効率的に満たすためにスケーリングするワークロードの能力を指します。 詳細については、「パフォーマンス効率の設計レビュー チェックリスト」を参照してください。
このアーキテクチャは運用環境のデプロイ用に設計されていないため、重要なパフォーマンス効率機能は省略されています。
POC の結果を使用して、適切な App Service 製品を選択します。 水平スケーリング (インスタンス数の調整) を通じて需要を満たします。 定期的な需要に対応するために製品レベルを変更する必要がある設計は避けてください。
このアーキテクチャでは、従量課金制コンポーネントを使用します。 ベスト エフォート リソースの割り当てにより、ノイズの多い近隣の影響が生じる可能性があります。 容量を予約し、予測可能なパフォーマンスを実現するために プロビジョニングされたスループット が必要かどうかを決定します。
その他の設計上の推奨事項
アーキテクトは、Well-Architected AI workloads on Azureのガイダンスを念頭に置いて、このようなAIワークロードおよび機械学習ワークロードを設計する必要があります。 POC を超えて移動するときに、このアーキテクチャと広範な AI と機械学習のベスト プラクティスを使用して、POC からの分析情報を組み合わせます。
このシナリオを展開する
これらの推奨事項と考慮事項を適用する参照実装をデプロイします。