DISPLAY SETTINGS 各種設定
Q1.ある製造企業のMicrosoft Foundryプロジェクトには、FinanceOrchestrator、InvoiceValidationAgent、PaymentApprovalAgentという3つのエージェントがあります。
これらは、VendorNegotiationAgentという外部エージェントと連携します。
各エージェントの構成は(①の表)のとおりです。
これらのエージェントに推奨すべきID(アイデンティティ)構成を、回答エリアで選択してください。

解答を見る
請求検証と支払い承認は、異なるERP権限を持つ別個の財務ロールです。
最小権限アクセスと監査の追跡性を確保するため、ロールごとに独立したエージェントIDを割り当てます。
両者は同じ財務の信頼境界内に留めつつ、IDのみを分離できます。
一方、VendorNegotiationAgentは外部サプライヤーとの境界をまたいで自律動作するため、独立したブループリント(信頼境界)が適切です。
専用のExchange Onlineメールボックスを使うことから、ユーザーオブジェクトを必要とするリソース向けに、Microsoft Entra Agent IDでエージェントのユーザーアカウントを関連付けます。
単一IDを全ロールで共有すると監査の所在が曖昧になり、侵害時の影響範囲が広がります。
Microsoft Foundry Agent Service とは
Q2.ある保険会社のMicrosoft Foundryプロジェクトには、保険金請求処理を担うコーディネーターエージェントがあります。
Foundryの外部でホストされている既存の不正分析エージェントがあり、標準規格に準拠したHTTPSエンドポイントを公開し、対応可能なスキルとメディアタイプを公開し、認証付きのリクエストを必要とします。
コーディネーターエージェントがこの不正分析エージェントを呼び出せるように構成する必要があります。
要件は、相互運用可能な呼び出しインターフェイスを使用すること、公開された機能検出コントラクトを使用すること、コーディネーターエージェントのバージョンをまたいで保存済みの認証を再利用することです。
統合の構成を回答エリアで選択してください。
解答を見る
リモートの不正分析エージェントは、標準規格準拠のHTTPSエンドポイントを公開し、スキルとメディアタイプを公開する自律エージェントです。
これは通常のツールAPIではなくAgent-to-Agent (A2A) プロトコルに合致します。
A2Aは機能検出コントラクトとしてエージェントカードを用い、リモート実装に結合せずに対応スキルや呼び出し方法を検出できます。
Foundryプロジェクトの A2A 接続は、リモートのエンドポイントと認証構成を保持するため、コーディネーターのバージョンをまたいで資格情報を再利用できます。
認証をプロンプト本文ではなくプロジェクト接続に置くことで、集中管理・監査・再利用が可能になります。
Microsoft Foundry Agent Service とは
Q3.ある企業のMicrosoft Foundryヘルプデスク トリアージ エージェントがあります。
従業員はMicrosoft Entraを使用してエージェントにサインインします。
このエージェントは、既存の従業員ごとの承認モデルを適用するチケット検索ツールと、別の本番記事リポジトリに書き込むナレッジ記事ツールを呼び出せます。
対話的なチケット検索では従業員ごとの承認を適用し、承認済みの記事更新は本番記事リポジトリに限定する必要があります。
要件は、埋め込みシークレットの使用を防ぐことと、最小権限の原則に従うことです。
各実行コンテキストに適したアクセス構成を、選択肢からドラッグして割り当ててください。
選択肢を要件のドロップ欄へドラッグ、またはタップして配置。配置済みの欄をクリックで戻せます(同じ選択肢は複数回使用可)。
チケットレコードの読み取りにスコープを限定したマネージドID
本番記事レコードの書き込みにスコープを限定したマネージドID
アプリケーション設定に保存した、チケットと記事のアクセス用の共有APIキー
記事更新を承認する上長からの委任された権限
サインイン中の従業員から委任された権限
解答を見る
チケット検索は既存の従業員ごとの承認モデルを維持する必要があるため、サインイン中の従業員の委任IDコンテキストで実行します。
これにより、チケットサービスは従来どおりユーザー単位の権限を適用できます。
一方、ナレッジ記事の更新は、アプリケーションが制御する単一の本番リポジトリへの書き込みであるため、必要な書き込み権限だけを持つマネージドIDが最小権限の選択です。
広範な共同作成者割り当てや共有APIキーは影響範囲を広げ、監査の追跡性を弱めます。
Microsoft EntraによるIDを使うことで、いずれの方式も埋め込みシークレットを排除できます。
Microsoft Foundry Agent Service とは
Q4.あるカスタマーサポート向けのMicrosoft Agent Frameworkソリューションには、トリアージエージェント、トリアージエージェントと同一プロセスで動作する返金スペシャリストエージェント、パートナーチームがリモートサービスとして公開するコンプライアンスレビューエージェントが含まれます。
トリアージエージェントが他のエージェントとのやり取りを調整するために使用する統合コンポーネントを特定する必要があります。
各エージェントに適したコンポーネントを、選択肢からドラッグして割り当ててください。
選択肢を要件のドロップ欄へドラッグ、またはタップして配置。配置済みの欄をクリックで戻せます(同じ選択肢は複数回使用可)。
Agent-to-Agent (A2A) プロトコル
組み込みの File Search ツール
コンテキストプロバイダー
グラフベースのワークフロー
解答を見る
返金スペシャリストはトリアージエージェントと同一プロセスで動作するため、ツールとして公開するagent-as-toolsパターンが軽量な構成です。
外側のトリアージエージェントがタスク全体の所有権を保ちながら、必要なときにスペシャリストを呼び出せます。
一方、コンプライアンスレビューはパートナーチームが所有するリモートサービスです。
別ランタイムや別フレームワークの独立ホスト型エージェントにはAgent-to-Agent (A2A) が相互運用プロトコルとして適し、機能検出やタスク追跡をサポートします。
したがって、同一プロセスはagent-as-tools、リモートはA2Aが正解です。
Microsoft Foundry Agent Service とは
Q5.Microsoft Foundryで、チェックポインターを使用してappとしてコンパイルされたLangGraphワークフローがあります。
各リクエストにはticket_idという値が含まれます。
ストリーミングされる各実行がOpenTelemetryトレースをFoundryのObservabilityへ送信するように計装する必要があります。
要件は、指定されたticket_idでリクエストごとにグラフステップとツール呼び出しを関連付けること、LangGraphの呼び出しでAzure AI OpenTelemetryトレーサーを使用することです。
コードを完成させるため、(①の図)の①と②で適切なオプションを選択してください。
①
import os
from langchain_azure_ai.callbacks.tracers import AzureAIOpenTelemetryTracer
from langchain_core.messages import HumanMessage
azure_tracer = AzureAIOpenTelemetryTracer(
connection_string=os.environ.get("APPLICATION_INSIGHTS_CONNECTION_STRING"),
name="Ticket Triage Orchestrator",
id="ticket_triage_orchestrator_v1",
)
input_message = HumanMessage(content=ticket_description)
config = {
"configurable": { ① },
② ,
}
for event in app.stream({"messages": [input_message]}, config, stream_mode="values"):
event["messages"][-1].pretty_print()
解答を見る
LangGraphのチェックポインターは、configurableの下にある安定したthread_idを用いて、同じ論理リクエストに実行や永続状態を関連付けます。
この値を指定のticket_idに設定することで、ストリーミング実行をまたいでグラフステップとツール呼び出しをチケットに関連付けられます。
FoundryのLangGraph統合は、LangChain/LangGraphのコールバック経由でAzureAIOpenTelemetryTracerを使用します。
トレーサーをcallbacksリストに追加すると、エージェント・モデル・ツールのスパンがOpenTelemetryで出力され、Foundryで可視化されます。
ランダムなrun_idでは状態継続に必要な安定した識別子を得られず、span_processorsは別の計装層で構成します。
生成 AI の可観測性
Q6.次の特定のドメイン要件を満たすMicrosoft Foundryマルチエージェントソリューションを推奨する必要があります。
エージェントの応答には、制裁対象の特定2社の社名を決して含めないこと。
エージェントの応答が顧客の口座番号を公開しないこと。
推奨に含めるべきガードレール戦略はどれですか。
解答を見る
いずれの要件も、エージェントが生成した応答に対する制御を求めています。
制裁対象2社の社名を禁止するには、カスタムのブロックリストをエージェント出力に適用します。
口座番号の漏えいを防ぐには、出力の介入ポイントでPII検出を構成し、生成テキストから機密情報を検出・ブロックします。
ユーザー入力側の制御では、モデルが生成した出力に含まれる社名や口座番号を捕捉できません。
組み込みブロックリストは任意の社名に対応できず、Task Adherenceはツール使用の順守であって出力内容のフィルタリングではありません。
したがって、出力側のカスタムブロックリストとPII検出の組み合わせが正解です。
Azure AI Content Safety とは
Q7.あるMicrosoft Foundryプロジェクトに、最終応答エージェントを含むマルチエージェントのカスタマーサポートソリューションがあります。
レビュー担当者がプレビューWebアプリでエージェントの応答を評価し、各応答に完了スコアを記録できるようにする必要があります。
ソリューションは最小権限の原則に従う必要があります。
レビュー担当者に割り当てるべきロールはどれですか。
解答を見る
プレビューWebアプリでの人による評価では、レビュー担当者にプロジェクトのFoundryユーザー権限と、Foundryアカウントの閲覧者アクセスの両方が必要です。
この組み合わせにより、エージェントエクスペリエンスを開いて評価フィードバックを記録できる一方で、プロジェクト管理やアカウント管理の権限は付与されません。
Application Insights閲覧者だけではテレメトリ参照に限られ、応答をスコア付けする操作権限が得られません。
Foundryユーザー単体ではアカウントレベルの可視性要件を満たさず、Foundryプロジェクトマネージャーは過剰で最小権限に反します。
したがって正解はCです。
Microsoft Foundry Agent Service とは
Q8.LangGraphで構築されたMicrosoft Foundryエージェントがあり、ベクターストアからポリシー内容を取得します。
LangGraphのオーケストレーションはAzure Container Appsで実行され、運用チームはAzure Monitorでエージェントの実行を調査します。
ベクターストアがAzureのリージョンメンテナンス中に到達不能になることが判明しました。
停止中でもエージェントがポリシーの質問に回答できるようにツールエコシステムを構成する必要があります。
要件は、主経路ではローカルの取得ノードを追加せずにプロジェクトのベクターストアを使うこと、キャッシュされたポリシー参照をLangGraphコードと同一のコンピューティング環境で実行すること、Azure Monitorで調査できるようにエージェント・モデル・ツールのスパンを出力することです。
ツールエコシステムの構成を回答エリアで選択してください。
解答を見る
主経路では、ローカルの取得ノードを追加せずにプロジェクトのベクターストアを使う必要があるため、FoundryのFileSearchToolをAgentServiceBaseToolでラップします。
テレメトリは、LangGraphのコールバック経由でAzureAIOpenTelemetryTracerを追加することで、エージェント・モデル・ツールのスパンをAzure Monitorへ出力できます。
停止中のフォールバックには、キャッシュ済みのポリシー内容を参照する構成を用います。
ただしCode InterpreterはFoundryホスト型の組み込みツールであり、LangGraphと同一コンピューティングでは実行されない点に注意が必要で、厳密にはローカル実行できるツールが望ましいとされます。
生成 AI の可観測性
Q9.あるMicrosoft Foundryマルチエージェントソリューションには、Azure AI Searchをセマンティックキャッシュとして用いてエージェントを絞り込み、最上位の一致を呼び出すオーケストレーターがあります。
キュレーション済みデータセット、期待されるルーティング、期待される応答を含むバージョン管理されたリポジトリがあります。
あるプルリクエストが、Agent1というエージェント、新しいサンプル発話、変更されたセレクタープロンプトを追加します。
このプルリクエストに対する自動のリリース前評価ゲートを構成する必要があります。
要件は、新エージェントがオーケストレーションで利用可能になった後に統合システムの応答を検証すること、セマンティックキャッシュの取得品質を期待結果に照らして検証すること、回帰テストをプルリクエストの変更に整合させることです。
評価ゲートの構成を回答エリアで選択してください。
解答を見る
セマンティックキャッシュは取得・絞り込みのコンポーネントとして機能するため、再現率と適合率が、期待する候補が提示され無関係な候補が避けられたかの指標です。
プルリクエストはセレクタープロンプトの変更と新エージェント追加を伴うため、コンポーネント単体テストでは不十分で、取得・ルーティング・新エージェント・最終応答を一体で評価するエンドツーエンド評価が必要です。
さらに、バージョン管理された回帰データセットに新機能のケースを追加して、期待ルーティングと応答をコード変更に整合させます。
これにより3層で品質ゲートを構成できます。
RAG (検索拡張生成) エバリュエーター
Q10.あるMicrosoft Foundryマルチエージェントソリューションは、Microsoft Agent FrameworkとLangGraphを使用します。
ワークロードからのテレメトリはApplication Insightsに送信されます。
次の要件を満たす可観測性のコンポーネントを実装する必要があります。
冗長な本番ログに依存せず、エージェント・モデル・ツール・関数・API境界をまたいだユーザー操作の調査を支援すること。
デプロイ済みの応答品質と安全性について、反復可能で比較可能な測定を経時的に生成すること。
使用すべきものを回答エリアで選択してください。
解答を見る
ユーザー操作を、冗長なログテキストに頼らずエージェント・モデル・ツール・API境界をまたいで再構成するには、相関IDを伴うOpenTelemetry分散トレースが適切なランタイム機構です。
FoundryはOpenTelemetry互換トレースとApplication Insightsを用い、関連するスパンを1つの実行パスへ相関付けできます。
2つ目の要件は、デプロイ済み応答の品質と安全性を反復・比較できる測定です。
安定したテストデータセットに対する定期的な評価が経時的なベンチマークを提供し、場当たり的なトレースやインフラ指標より適しています。
両者で運用診断と品質回帰監視を両立できます。
生成 AI の可観測性
