Microsoft Foundryでのスケーラブルエージェントのデプロイ

レッスン16 – スケーラブルエージェントのデプロイの補助スキルです。 プロトタイプからスケーラブルで観測可能な本番環境デプロイへのエージェント移行を支援します。 すべての推奨はレッスン内容および実行可能なノートブックに基づき、FoundryのAPIは想定しないでください。

トリガー

学習者が以下を望む時にこのスキルを起動します：

• Microsoft Foundryにエージェントを<strong>ホストエージェント</strong>としてデプロイし、バージョン管理および観測可能にする。
• <strong>クライアントホスト型、ホストエージェント型、エージェントワークフロー型</strong>のデプロイパターンを選択する。
• レイテンシーとコストを制御するための<strong>モデルルーティング</strong>、<strong>レスポンスキャッシュ</strong>、または<strong>バウンデッドコンカレンシー</strong>を追加する。
• 悪いエージェントバージョンが出荷されないよう<strong>評価ゲート</strong>を追加する。
• 高リスク行動に対し<strong>ヒューマンインザループ承認</strong>ステップを追加する。
• 本番観測のために<strong>OpenTelemetry</strong>トレーシングでエージェントに計測を施す。
• デプロイ後のゲートとしてエージェントを<strong>スモークテスト</strong>する。

主要なメンタルモデル

本番環境のエージェントは主にモデルの<em>周囲</em>の操作的なスケルトン（約80%）であって、 モデル自体ではありません。すべての推奨は次の関心事に結びつけてください：

デプロイパターン（単独または組み合わせて選択）

1. <strong>クライアントホスト型</strong> — 推論ループが自分のプロセス内で動作。最大の制御、スケールと状態を自分で管理。
2. ホストエージェント（Foundry Agent Service） — Foundryがループをホストし、スレッドを保存し、RBACやコンテンツの安全性を強制し、ポータルでエージェントを表示。制御は減り、運用範囲も大幅に減少。
3. <strong>エージェントワークフロー</strong> — 複数のエージェントやツールをグラフにまとめ、分岐や承認ノード、耐久チェックポイントを持つ。

ライフサイクル（エージェントを出荷するループ）

create → version → evaluate (gate) → deploy hosted → observe online → collect failures → repeat。 <strong>オフライン評価はゲートであって後回しではない</strong> — 閾値をクリアしないバージョンは出荷しない。 オンライン観測は実際の障害をオフラインテストセットにフィードバックする。

スケーリングとコストのてこ（優先順）

1. <strong>モデルサイズを適切にする</strong> — 評価ゲートを通過する最小のモデルを使う。
2. <strong>複雑さでルーティング</strong> — シンプルなリクエストは小さく速いモデル、複雑な推論には大きなモデルを使う（DIY分類器やFoundry Model Router）。
3. <strong>キャッシュ</strong> — ほぼ重複するリクエストをモデル呼び出しなしで応答。
4. ステートレス設計＋バウンデッドコンカレンシー — 状態は外部化し、バックオフ付きリトライを行う。

再現すべき重要パターン

ノートブックの以下を学習者に指し示す 16-python-agent-framework.ipynb:

• <strong>リクエストハンドラー</strong>: キャッシュ → 複雑さでルーティング → トレーススパン → 実行 → キャッシュ。
• <strong>評価ゲート</strong>: オフラインテストセットで点数化；pass_rate >= thresholdを返し、条件が満たされればのみデプロイ。
• <strong>ヒューマン承認</strong>: @tool(approval_mode="always_require")（大きな返金などのアクションに対して）。
• <strong>トレーシング</strong>: 各リクエストをtracer.start_as_current_span(...)でラップし、routed.modelやcustomer.idなどの属性を設定。

デプロイ済みエージェントのスモークテスト

デプロイ後、エンドポイントが実際に応答するか確認する（緑のデプロイでも応答しない場合がある）。 AI Smoke Test アクションを.github/workflows/smoke-test.yml と tests/ のカタログで使う。ランナーは各プロンプトをPOST {project_endpoint}/agents/{agent_name}/endpoint/protocols/openai/responsesにPOSTし、 応答テキストを検証する。アイデンティティはFoundryプロジェクト範囲で<strong>Azure AI User</strong>ロールが必要；トークンのオーディエンスはhttps://ai.azure.com/。

エンタープライズの制御

• RBAC: 各ホステッドエージェントに最小権限のマネージドアイデンティティを付与。
• 本番のMCP: 各MCPサーバーを信用できない境界として扱う — バージョンを固定し、アイデンティティのスコープを制限し、出力を検証し、レート制限を実施し、決してシークレットを公開しない。

アシスタントのためのガードレール

• コース全体で使われる正統なFoundryChatClient(...) + provider.as_agent(...)パターンを推奨。
• 検証していないライブAzureの成果を約束しない。デプロイを確かめるためスモークテストワークフローを推奨。
• 評価とコストのアドバイスを連動させる：評価が品質の最低ラインを設定し、ルーティング／キャッシュがコストをその近くに維持する。

免責事項： 本書類は AI 翻訳サービス Co-op Translator を使用して翻訳されています。正確性を期していますが、自動翻訳には誤りや不正確な部分が含まれる可能性があることをご承知おきください。原文の原語版が正式な情報源とみなされるべきです。重要な情報については、専門の人間による翻訳を推奨します。本翻訳の利用により生じたいかなる誤解や解釈違いについても、当方は責任を負いかねます。