WEB問題集
Contoso は上の図の構成で、見積もりを作成するエージェントを Microsoft Foundry の Foundry Agent Service にホスト型エージェントとしてデプロイし、運用しています。図が示すとおり、エージェントの入力にも出力にもエージェント メッセージが含まれます。
別部門は、与信審査を行うエージェントを Microsoft Agent Framework で構築し、自部門の Azure Container Apps でセルフホストしています。与信審査エージェントから見積もりエージェントへ タスクを委任し、結果を受け取れるようにします。委任には A2A プロトコルを使用します。ホスト型エージェントの A2A プロトコルのエンドポイントは、v1.0 が一般提供 (GA) です。
見積もりエージェントの実装（コンテナー イメージ）を変更せずに委任を受け付けられるように するには、どうすればよいですか。
解説
【正解: A】の理由
ホスト型エージェントは、コンテナーが公開するプロトコルをエージェントのバージョン定義で宣言し、宣言したプロトコルに対応するエンドポイントだけが有効になります。A2A はエージェント間の委任を担うプロトコルとして用意されており、宣言を追加するだけで委任の受け口ができます。コンテナー イメージの中身を書き換える必要はなく、既存の応答ロジックはそのまま使えます。受信 A2A を有効にするには、エージェントの機能を説明するエージェント カードと、エンドポイントで有効にした A2A プロトコルの 2 つが必要で、呼び出し元はエージェント カードを取得して委任先を検出します。A2A のエンドポイントは v1.0 が一般提供 (GA)、v0.3 がプレビューで、バージョンを指定しないと v0.3 が使われるため、実運用の委任では一般提供の v1.0 を明示的に選びます。ホスト型エージェントは複数のプロトコルを同時に公開できるので、既存の呼び出し元が使っている Responses のエンドポイントを維持したまま A2A を追加できます。
【他選択肢が違う理由】
- B: 1 つのエージェントに統合すると責務の分離が失われ、部門をまたぐ委任という要件も満たせません。
- C: 接続済みエージェントは Foundry (classic) の機能で非推奨となっており、新しい Foundry の構成では選びません。
- D: ホスト型エージェントが公開するプロトコルは Responses、Invocations、Activity、A2A で、MCP は含まれません。MCP サーバーとして公開するにはコンテナー イメージの変更が必要です。
【参考】
Contoso は 1 つのマルチエージェント ソリューションの中で、性質の異なる 4 つの処理を扱います。それぞれの要件に最も適したオーケストレーション パターンを対応付けてください。
- マジェンティック オーケストレーション
- 並列オーケストレーション
- 順次オーケストレーション
- ハンドオフ オーケストレーション
解説
【正解マッチング】
| 要件 | オーケストレーション パターン |
|---|---|
| 前段の出力を次段が加工する | 順次オーケストレーション |
| 同じ入力を複数の観点で同時に評価 | 並列オーケストレーション |
| 適任者が実行中にしか決まらない | ハンドオフ オーケストレーション |
| 計画が未定でタスク台帳を更新する | マジェンティック オーケストレーション |
【ポイント】
順次は、あらかじめ決めた線形の並びでエージェントを連結し、各エージェントが前段の出力を受け取って加工します。段階ごとに専門化した変換が積み上がる処理に向き、パイプラインとも呼ばれます。並列は同じタスクを複数のエージェントに同時に処理させ、それぞれの観点からの独立した分析を集約します。ファンアウトとファンインの形になるため、観点の網羅と所要時間の短縮を同時に狙えます。ハンドオフは、各エージェントが自分で処理するか、より適したエージェントへ転送するかを判断します。最適な担当が最初は分からず、処理を進めるうちに要件が明確になる場面のための動的な委譲です。マジェンティックは、決まった進め方が存在しない課題のために、マネージャー エージェントがタスク台帳を作りながら目標と部分目標を組み立て、文脈の変化に応じて計画自体を更新します。4 つは前提が重ならないため、並びが固定か、観点が複数か、担当が事前に決まるか、計画が事前に描けるかを読み取れば、選ぶべきパターンが一意に決まります。
【参考】
Contoso の営業支援チームは、Microsoft Foundry 上で動く 1 つのエージェントに機能を足し続けてきました。現在このエージェントは 20 個のツールと 1 つの長大な指示を抱えており、どこか 1 か所を直すと別の責務の応答が崩れます。現在の責務と、それぞれに課された制約は次のとおりです。
| 現在の責務 | 処理の性質 | 業務側の制約 |
|---|---|---|
| 見積書の下書き作成 | 分類、積算、整形の 3 段が固定 | 途中で並びを変えない |
| 在庫残数の照会 | 同じ入力なら同じ結果 | 基幹システムが返した値だけを渡す |
| 契約条項の審査 | 法務の知識にもとづく判断 | 権限と監査の記録を他と分ける |
| 顧客への文面作成 | 表現を読み手に合わせる判断 | 文面の方針が週ごとに変わる |
チームは Microsoft Agent Framework で全体を組み直します。表の制約をすべて満たす分解として、最も適切なものはどれですか。
解説
【正解: B】の理由
並びが設計時に決まっている処理は、次にどれを呼ぶかを設計者が決められるため、エージェントの判断に委ねずワークフローの実行パスとして表現します。判断が要る処理だけをエージェントに切り出すと、指示とコードの複雑さが責務ごとに閉じ、審査だけ権限と監査の記録を分けるという制約も満たせます。同じ入力なら同じ結果が返る照会は、モデルに推論させる理由がないので関数として登録し、決まった引数で呼ばせます。関数で書けるものはエージェントにしないという指針があり、ワークフロー、エージェント、ツールのどれに置くかは、並びが決まっているか、判断が要るか、決定的かという 3 つの問いで切り分けられます。
【他選択肢が違う理由】
- A: ツールと知識源が増えるほど応答は予測しにくくなり、審査だけ権限を分けるという制約も 1 つのエージェントでは満たせません。
- C: グループ チャットは合議や相互点検のための形式で、並びが固定された処理や決定的な照会には向きません。
- D: Foundry ポータルのワークフローは 2026 年 12 月 1 日での提供終了が予告されており、新規に組む先には選びません。
【参考】
Woodgrove Bank は、法人向けの与信更新の手続きをマルチエージェント ソリューションとして設計します。手続きは次の 3 つの要素からなります。設計チームは各要素の実装先として、判断を担うエージェント、実行の並びを定めるワークフローのステップ、外部システムを呼ぶツールのいずれかを選びます。同じ実装先は 1 回だけ使います。
各要素に割り当てる実装先を選択してください。
| ステートメント | 選択 |
|---|---|
|
取引先の説明文と過去の取引履歴を読み、追加の調査が必要かどうかをその都度判断する
|
|
|
書類の確認、与信枠の算定、支店への通知を必ずこの並びで実行し、途中で並びを変えない
|
|
|
基幹システムの残高照会を決まった引数で呼び出し、返った数値をそのまま次へ渡す
|
解説
【正解マッチング】
| 業務目標の要素 | 実装先 |
|---|---|
| 取引先の説明文と過去の取引履歴を読み、追加の調査が必要かどうかをその都度判断する | エージェント |
| 書類の確認、与信枠の算定、支店への通知を必ずこの並びで実行し、途中で並びを変えない | ワークフローのステップ |
| 基幹システムの残高照会を決まった引数で呼び出し、返った数値をそのまま次へ渡す | ツール |
【ポイント】
実装先は、その要素が何を必要としているかで決まります。入力のたびに解釈が変わり、どこまで調べるかを事前に書き下せない要素は、モデルに推論させるエージェントに置きます。並びが設計時に決まっていて変える理由がない要素は、次に何を呼ぶかを設計者が決めるワークフローのステップとして表現します。決まった引数で外部システムを呼び、同じ入力なら同じ結果が返る要素は関数として書けるので、ツールに置きます。課題が開かれていて自律的なツール利用が要るならエージェント、手順が定まっていて実行の順序を明示的に制御したいならワークフロー、という使い分けが示されており、関数で処理できるものはエージェントにしません。判断のいらない部分までモデルに任せると、応答の予測しやすさと費用の両方を損ないます。
【参考】
Fabrikam は、社内の調達手続きを 1 つのエージェントで処理してきましたが、部門をまたぐ審査が増えたため、複数のエージェントへの分解を検討しています。分解には調整の負荷、待ち時間、費用が上乗せされるため、設計チームは分解を正当化できる根拠だけを採用する方針です。
分解が妥当だと言える根拠として正しいものを 3 つ選んでください。
解説
【正解: A / B / C】の理由
複数のエージェントに分ける利点は、専門化、拡張性、保守性、最適化として整理されています。エージェントが 1 つの領域や能力に専念すると、指示とコードの複雑さが下がり、試験と障害の切り分けもその単位に閉じます。エージェントの追加や変更が全体の再設計を伴わないため、業務の変化にも追従できます。境界で出力を検証できることも根拠になり、確信度の低い出力や形式の崩れた出力をそのまま後段へ渡すと誤りが連鎖するため、受け手か調整役が品質を確かめて再実行、問い合わせ、中止のいずれかを選べる構造にします。逆に、これらの根拠が示せない分割は、調整の負荷だけを増やす分割です。
【他選択肢が違う理由】
- D: 分解するとモデルの呼び出しは増え、各エージェントが指示と文脈の分のトークンを重ねるため、費用は積み上がります。
- E: 要件を確実に満たす最小の複雑さを選ぶのが原則で、水準を上げるほど調整の負荷、待ち時間、故障の型が増えます。