Explanation:
展開タイプ: 標準
バージョン更新ポリシー：現在のバージョンの有効期限が切れた後
適切なデプロイ タイプは Standard です。ケース スタディでは、Project1 が EU Azure リージョンにデプロイされ、モデル処理されたデータは EU 内に留まる必要があると指定されています。また、予約されたスループット容量なしで、変動する顧客サポート トラフィックを動的に処理する、スケーラブルで高スループットの生成型 AI ワークロードも必要です。Microsoft Foundry Models では、Standard はトークンごとに課金されるデプロイ タイプで、単一の Azure リージョンでデータを処理します。一方、Global Standard はリージョンをまたいでリクエストを処理でき、Global Provisioned は予約されたプロビジョニング済みスループットを使用します。Microsoft のデプロイ タイプ ガイダンスでは、Standard は単一リージョン、トークンごとに課金されるタイプ、Global Provisioned はリージョンをまたいで予約された容量を持つタイプとして識別されています。
正しいバージョン更新ポリシーは「現在のバージョンの有効期限が切れたら」です。これにより、Agent1はサポート対象ライフサイクル期間中、選択されたモデルバージョンに維持され、安定した一貫性のある応答が保証されます。また、現在のバージョンが廃止された際には、サポート対象の代替バージョンに自動的に移行することで、継続性も維持されます。
Microsoft のモデル バージョン管理に関するガイダンスでは、このポリシーは現在のモデル バージョンが期限切れになった場合にのみ更新され、新しいデフォルトが利用可能になったときにアップグレードすると展開が早期に変更され、オプトアウトすると廃止後に展開が動作しなくなる可能性があると規定されています。参照トピック: 展開の種類、リージョン別データ処理、モデル バージョン管理、スループット容量、安定した運用展開。

Azure Storage 内の多数の画像や PDF ドキュメントからテーブルを抽出し、開発の手間を最小限に抑えて構造化データベースに格納するには、Azure AI Foundry エコシステム内の Azure AI Document Intelligence (旧称 Form Recognizer) を利用するのが最適です。レイアウト モデルは、テーブル、行、列、ヘッダーの抽出に最適です。
参照：
https://azure.microsoft.com/en-us/products/ai-foundry/tools/document-intelligence

適切なモデルタイプは、大規模言語モデル（LLM）です。このシナリオでは、取得したドキュメントに基づいて推論を行い、コンテキストを考慮した回答を合成し、詳細な自然言語応答を生成できるエージェントが必要です。Microsoft Foundry RAG のガイダンスでは、検索と大規模言語モデルを組み合わせたパターンとして、検索拡張生成（Retrieval Augmented Generation）を定義しています。これにより、応答は組織データに基づいて生成され、Azure AI Search を社内製品ドキュメントに使用する場合と直接的に一致します。
LLMは、長いコンテキストにわたる深く多段階の推論にも最適です。Azure AI Searchのエージェント検索に関するガイダンスでは、複雑なチャットやエージェントのシナリオでは、LLMを使用してユーザーのクエリをより小さな焦点を絞ったサブクエリに分割し、インデックス付きコンテンツの網羅性を向上させると説明しています。また、MicrosoftはAzure AI Searchを、エージェントやチャットボットを独自の企業データに基づいて正確かつコンテキストを認識した応答を実現する方法として説明しています。
要件はテキスト中心であり、画像、音声、動画に基づくものではないため、マルチモーダルモデルは不要です。キーワード抽出モデルは限定的なテキスト分析しか行えず、詳細な回答を生成することはできません。
SLMはコストとレイテンシを削減できる可能性があるが、深い推論と長期コンテキスト合成の必要性を考慮すると、LLMの方が適している。参考トピック：Microsoft Foundry RAG、Azure AI Searchのグラウンディング、エージェントによる検索、生成型AIエージェントのモデル選択。

最も適切なデプロイメントタイプは、サーバーレスAPIデプロイメント（標準デプロイメントまたはModels-as-a-Service / MaaSとも呼ばれる）です。
キーベース認証：サーバーレスAPIデプロイメントでは、クライアントアプリケーションを保護するために、エンドポイントURLとプライマリおよびセカンダリAPIキーがネイティブにプロビジョニングされます。
リアルタイムREST APIアクセス：モデルが正常にデプロイされると、標準化されたAzure AIモデル推論APIに準拠した、スケーラブルなリアルタイムHTTP/RESTエンドポイントが公開されます。
仮想マシンのvCPUクォータを消費しません：マネージドコンピューティングデプロイメントとは異なり、サーバーレスAPIデプロイメントは完全にMicrosoftによってホストおよび管理されます。マネージドコンピューティングデプロイメントでは、サブスクリプション内に専用の仮想マシンがプロビジョニングされ、VMのvCPUクォータが必要となります。サーバーレスAPIデプロイメントは、従量課金制のトークンベースの課金構造で動作し、AzureサブスクリプションのVMのvCPUクォータを消費しません。
参照：
https://learn.microsoft.com/en-us/azure/foundry/concepts/deployments-overview

エージェントが実行ごとにモデルコンテキストプロトコル（MCP）ツールを呼び出すように確実にするには、run_create_and_process メソッドに tool_choice="required" を渡す必要があります。
「必須」ツールの選択：このパラメーターを「必須」に設定すると、基盤となる Azure OpenAI モデルは、応答ごとに利用可能なツールのいずれかを呼び出すようになり、エージェントが基本モデルから回答を推測することがなくなります。
参照：
https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/tool-best-practice