Microsoft AI-500(Designing and Implementing Multi-Agent AI Solutions) 1-10

DISPLAY SETTINGS 各種設定 クリックして開くクリックして閉じる
表示モード
画像位置
文字位置
理解度の自動記録
理解度の位置
STATUS FILTER 表示する理解度を選択 読み込み中...
Q1
AI-500
InvoiceValidationAgent と PaymentApprovalAgent

VendorNegotiationAgent

解答を見る
正解:InvoiceValidationAgent と PaymentApprovalAgent→エージェントロールごとに1つのブループリントと1つのエージェントID/VendorNegotiationAgent→独立したブループリント、1つのエージェントID、および1つのエージェントのユーザーアカウント

請求検証と支払い承認は、異なるERP権限を持つ別個の財務ロールです。
最小権限アクセスと監査の追跡性を確保するため、ロールごとに独立したエージェントIDを割り当てます。
両者は同じ財務の信頼境界内に留めつつ、IDのみを分離できます。
一方、VendorNegotiationAgentは外部サプライヤーとの境界をまたいで自律動作するため、独立したブループリント(信頼境界)が適切です。
専用のExchange Onlineメールボックスを使うことから、ユーザーオブジェクトを必要とするリソース向けに、Microsoft Entra Agent IDでエージェントのユーザーアカウントを関連付けます。
単一IDを全ロールで共有すると監査の所在が曖昧になり、侵害時の影響範囲が広がります。
Microsoft Foundry Agent Service とは

Q2
AI-500
統合メカニズム

機能検出コントラクト

資格情報とエンドポイントの構成

解答を見る
正解:統合メカニズム→Agent-to-Agent (A2A) ツール/機能検出コントラクト→エージェントカード (Agent cards)/資格情報とエンドポイントの構成→Foundryプロジェクトの Agent-to-Agent (A2A) 接続

リモートの不正分析エージェントは、標準規格準拠のHTTPSエンドポイントを公開し、スキルとメディアタイプを公開する自律エージェントです。
これは通常のツールAPIではなくAgent-to-Agent (A2A) プロトコルに合致します。
A2Aは機能検出コントラクトとしてエージェントカードを用い、リモート実装に結合せずに対応スキルや呼び出し方法を検出できます。
Foundryプロジェクトの A2A 接続は、リモートのエンドポイントと認証構成を保持するため、コーディネーターのバージョンをまたいで資格情報を再利用できます。
認証をプロンプト本文ではなくプロジェクト接続に置くことで、集中管理・監査・再利用が可能になります。
Microsoft Foundry Agent Service とは

Q3
AI-500

選択肢を要件のドロップ欄へドラッグ、またはタップして配置。配置済みの欄をクリックで戻せます(同じ選択肢は複数回使用可)。

サブスクリプションスコープで共同作成者ロールを付与し、チケットと記事の両方にアクセスできるマネージドID
チケットレコードの読み取りにスコープを限定したマネージドID
本番記事レコードの書き込みにスコープを限定したマネージドID
アプリケーション設定に保存した、チケットと記事のアクセス用の共有APIキー
記事更新を承認する上長からの委任された権限
サインイン中の従業員から委任された権限
対話的なチケット検索
承認済みの記事更新
解答を見る
正解:対話的なチケット検索→サインイン中の従業員から委任された権限/承認済みの記事更新→本番記事レコードの書き込みにスコープを限定したマネージドID

チケット検索は既存の従業員ごとの承認モデルを維持する必要があるため、サインイン中の従業員の委任IDコンテキストで実行します。
これにより、チケットサービスは従来どおりユーザー単位の権限を適用できます。
一方、ナレッジ記事の更新は、アプリケーションが制御する単一の本番リポジトリへの書き込みであるため、必要な書き込み権限だけを持つマネージドIDが最小権限の選択です。
広範な共同作成者割り当てや共有APIキーは影響範囲を広げ、監査の追跡性を弱めます。
Microsoft EntraによるIDを使うことで、いずれの方式も埋め込みシークレットを排除できます。
Microsoft Foundry Agent Service とは

Q4
AI-500

選択肢を要件のドロップ欄へドラッグ、またはタップして配置。配置済みの欄をクリックで戻せます(同じ選択肢は複数回使用可)。

Agent-as-tools
Agent-to-Agent (A2A) プロトコル
組み込みの File Search ツール
コンテキストプロバイダー
グラフベースのワークフロー
返金スペシャリストエージェント
コンプライアンスレビューエージェント
解答を見る
正解:返金スペシャリストエージェント→Agent-as-tools/コンプライアンスレビューエージェント→Agent-to-Agent (A2A) プロトコル

返金スペシャリストはトリアージエージェントと同一プロセスで動作するため、ツールとして公開するagent-as-toolsパターンが軽量な構成です。
外側のトリアージエージェントがタスク全体の所有権を保ちながら、必要なときにスペシャリストを呼び出せます。
一方、コンプライアンスレビューはパートナーチームが所有するリモートサービスです。
別ランタイムや別フレームワークの独立ホスト型エージェントにはAgent-to-Agent (A2A) が相互運用プロトコルとして適し、機能検出やタスク追跡をサポートします。
したがって、同一プロセスはagent-as-tools、リモートはA2Aが正解です。
Microsoft Foundry Agent Service とは

Q5
AI-500

①

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()
①(configurable に設定する項目)

②(app.stream に渡すコールバック設定)

解答を見る
正解:①→”thread_id”: ticket_id/②→”callbacks”: [azure_tracer]

LangGraphのチェックポインターは、configurableの下にある安定したthread_idを用いて、同じ論理リクエストに実行や永続状態を関連付けます。
この値を指定のticket_idに設定することで、ストリーミング実行をまたいでグラフステップとツール呼び出しをチケットに関連付けられます。
FoundryのLangGraph統合は、LangChain/LangGraphのコールバック経由でAzureAIOpenTelemetryTracerを使用します。
トレーサーをcallbacksリストに追加すると、エージェント・モデル・ツールのスパンがOpenTelemetryで出力され、Foundryで可視化されます。
ランダムなrun_idでは状態継続に必要な安定した識別子を得られず、span_processorsは別の計装層で構成します。
生成 AI の可観測性

Q6
AI-500
解答を見る
正解:C. エージェント出力に適用するブロックリストを作成する。出力の介入ポイントで個人を特定できる情報(PII)検出を構成する。

いずれの要件も、エージェントが生成した応答に対する制御を求めています。
制裁対象2社の社名を禁止するには、カスタムのブロックリストをエージェント出力に適用します。
口座番号の漏えいを防ぐには、出力の介入ポイントでPII検出を構成し、生成テキストから機密情報を検出・ブロックします。
ユーザー入力側の制御では、モデルが生成した出力に含まれる社名や口座番号を捕捉できません。
組み込みブロックリストは任意の社名に対応できず、Task Adherenceはツール使用の順守であって出力内容のフィルタリングではありません。
したがって、出力側のカスタムブロックリストとPII検出の組み合わせが正解です。
Azure AI Content Safety とは

Q7
AI-500
解答を見る
正解:C. プロジェクトの Foundry ユーザーと、Foundryアカウントの閲覧者

プレビューWebアプリでの人による評価では、レビュー担当者にプロジェクトのFoundryユーザー権限と、Foundryアカウントの閲覧者アクセスの両方が必要です。
この組み合わせにより、エージェントエクスペリエンスを開いて評価フィードバックを記録できる一方で、プロジェクト管理やアカウント管理の権限は付与されません。
Application Insights閲覧者だけではテレメトリ参照に限られ、応答をスコア付けする操作権限が得られません。
Foundryユーザー単体ではアカウントレベルの可視性要件を満たさず、Foundryプロジェクトマネージャーは過剰で最小権限に反します。
したがって正解はCです。
Microsoft Foundry Agent Service とは

Q8
AI-500
コーパスアクセス

依存先が利用不可時の経路

テレメトリ収集

解答を見る
正解:コーパスアクセス→FileSearchToolをラップするAgentServiceBaseTool/依存先が利用不可時の経路→キャッシュ済みファイルに接続したCodeInterpreterTool/テレメトリ収集→AzureAIOpenTelemetryTracerをコールバックとして追加

主経路では、ローカルの取得ノードを追加せずにプロジェクトのベクターストアを使う必要があるため、FoundryのFileSearchToolをAgentServiceBaseToolでラップします。
テレメトリは、LangGraphのコールバック経由でAzureAIOpenTelemetryTracerを追加することで、エージェント・モデル・ツールのスパンをAzure Monitorへ出力できます。
停止中のフォールバックには、キャッシュ済みのポリシー内容を参照する構成を用います。
ただしCode InterpreterはFoundryホスト型の組み込みツールであり、LangGraphと同一コンピューティングでは実行されない点に注意が必要で、厳密にはローカル実行できるツールが望ましいとされます。
生成 AI の可観測性

Q9
AI-500
セマンティックキャッシュの指標

統合システムのチェック

回帰データセット

解答を見る
正解:セマンティックキャッシュの指標→候補セットの再現率と適合率/統合システムのチェック→キュレーション済みデータセットに対するエンドツーエンド評価/回帰データセット→新機能のケースをキュレーション済みデータセットに追加

セマンティックキャッシュは取得・絞り込みのコンポーネントとして機能するため、再現率と適合率が、期待する候補が提示され無関係な候補が避けられたかの指標です。
プルリクエストはセレクタープロンプトの変更と新エージェント追加を伴うため、コンポーネント単体テストでは不十分で、取得・ルーティング・新エージェント・最終応答を一体で評価するエンドツーエンド評価が必要です。
さらに、バージョン管理された回帰データセットに新機能のケースを追加して、期待ルーティングと応答をコード変更に整合させます。
これにより3層で品質ゲートを構成できます。
RAG (検索拡張生成) エバリュエーター

Q10
AI-500
ランタイムの計装

デプロイ後の評価

解答を見る
正解:ランタイムの計装→相関IDを伴うOpenTelemetry分散トレース/デプロイ後の評価→テストデータセットを使う定期的な評価

ユーザー操作を、冗長なログテキストに頼らずエージェント・モデル・ツール・API境界をまたいで再構成するには、相関IDを伴うOpenTelemetry分散トレースが適切なランタイム機構です。
FoundryはOpenTelemetry互換トレースとApplication Insightsを用い、関連するスパンを1つの実行パスへ相関付けできます。
2つ目の要件は、デプロイ済み応答の品質と安全性を反復・比較できる測定です。
安定したテストデータセットに対する定期的な評価が経時的なベンチマークを提供し、場当たり的なトレースやインフラ指標より適しています。
両者で運用診断と品質回帰監視を両立できます。
生成 AI の可観測性