Q1.注：このセクションには、同じシナリオと問題に基づく1つ以上の問題セットが含まれています。
各問題では、その問題に対する固有の解決策が提示されます。
その解決策が、記載された目標を満たしているかどうかを判断する必要があります。
セット内の複数の解決策が問題を解決する場合もあれば、どの解決策も問題を解決しない場合もあります。
このセクションの問題に回答すると、前の問題に戻ることはできません。
そのため、これらの問題はレビュ－画面には表示されません。
画像のアップロードを受け付け、画像から抽出したテキストを使用して応答を生成する、マルチモーダル生成AIモデルがあります。
ユーザーが安全でない画像をアップロードしたり、モデルを操作するための隠された指示を画像に埋め込んだりできることが判明しました。
このリスクを軽減するための制御を実装する必要があります。
解決策：保護された素材の検出を構成します。
この解決策は目標を満たしていますか。
A. はい
B. いいえ
回答
- B. いいえ
-
保護された素材の検出は、著作権で保護された既知の文章、歌詞、記事、レシピ、コードなどと生成結果が一致するかを検出する機能であり、安全でない画像や画像内の隠し命令への対策ではありません。
危険な画像にはAzure AI Content Safetyの画像分析を使用し、画像から抽出された悪意ある指示などの間接プロンプトインジェクションにはPrompt Shieldsによるドキュメント攻撃の検出を使用します。
したがって、この解決策だけでは目標を満たしません。
現在、Azure AI Content SafetyはMicrosoft Foundryからも利用されますが、サービス名自体に変更はありません。
プロンプト シールド
Azure AI Content Safety とは?
Q2.Microsoft Foundry Agent Serviceを使用するカスタマーサポートエージェントがあります。
顧客が数日後に同じサポート案件を続けるためにセッションへ戻ることがあります。
その際、エージェントは完全な過去のコンテキストを使用して再開する必要があります。
エージェントは次の機能を提供する必要があります。
セッション内での複数ターンの継続性
同じ案件に対するセッションをまたいだ継続性
ユーザーメッセージ、エージェントメッセージ、ツール呼び出し、ツール出力を含む、やり取りの完全な履歴へのアクセス
新しい各ターンで、エージェントが完全な履歴を自動的に再読み込みするようにする必要があります。
どうすればよいですか。
A. クライアントアプリケーションに保存された最終的なモデル応答だけを永続化し、その応答を今後のプロンプトの先頭に追加します。
B. エージェント定義でメモリ要約を有効にし、コンテキストを自動的に永続化します。
C. 会話を作成して再利用するために、会話IDを保存し、後続の要求でそのIDを指定します。
回答
- C. 会話を作成して再利用するために、会話IDを保存し、後続の要求でそのIDを指定します。
-
Microsoft Foundry Agent Serviceの会話オブジェクトは、複数ターンにわたるメッセージやツール実行結果を保持する永続的な単位です。
会話IDを案件と関連付けて保存し、後続の要求で同じIDを指定すると、サービス側で既存の会話履歴を再利用できます。最終応答だけの保存では、ユーザーメッセージ、ツール呼び出し、ツール出力が失われます。
また、要約メモリは情報を圧縮するため、完全な履歴を保持する要件には適しません。
したがって、同一案件では同じ会話IDを継続して使用する方法が正解です。
旧ドキュメントでは「スレッド」という名称が使われる場合がありますが、新しいMicrosoft Foundry Agent Serviceでは、主に「会話」と「応答」という構成要素が使用されます。
エージェント、会話、応答を使用して構築する
クイック スタート: Microsoft Foundry SDK の概要
Q3.大量のチャット要求を処理するMicrosoft Foundryプロジェクトがあります。
ほとんどの要求は単純なFAQですが、一部の要求には高度な推論が必要です。
複雑な質問に対する回答品質を低下させることなく、一般的な問い合わせのコストと待機時間を削減する必要があります。
どうすればよいですか。
A. すべての要求について、max_tokensパラメーターの値を増やします。
B. すべての要求を小規模なモデルにルーティングします。
C. すべての要求を最も高性能なモデルにルーティングします。
D. 要求を異なるモデルへルーティングするモデルカスケードを使用します。
回答
- D. 要求を異なるモデルへルーティングするモデルカスケードを使用します。
-
モデルカスケードでは、単純なFAQを小規模で高速かつ低コストなモデルに送り、複雑な質問を高性能な推論モデルに振り分けられます。
これにより、複雑な質問の品質を維持しながら、全体のコストと待機時間を削減できます。
max_tokensの増加は通常、出力トークン数と処理時間を増やします。
また、すべてを小規模モデルへ送ると複雑な質問の品質が低下し、すべてを高性能モデルへ送ると単純なFAQでコストを浪費します。
現在のMicrosoft Foundryでは、この仕組みは主に「モデルルーター」と呼ばれ、プロンプトごとに品質、コスト、待機時間を考慮して適切なモデルを自動選択します。
Microsoft Foundry のモデル ルーター
Microsoft Foundry にモデル ルーターを使用する
Q4.エージェントを含むMicrosoft Foundryプロジェクトがあります。
このエージェントは、ツールを使用して内部コンテンツを取得し、外部APIを呼び出します。
エージェントは、ツールをいつ呼び出すかをモデルが決定できるように構成されています。
コンプライアンスワークフロー用にエージェントを公開する必要があります。
解決策は、次の要件を満たす必要があります。
各ワークフローの実行では、応答を生成する前に取得ステップを実行する必要があります。
ツール呼び出しでは、公開されたエージェント自身のIDを使用して認証する必要があります。
ツールへのアクセスには、他のプロジェクトリソースから分離されたIDを使用する必要があります。
ツールへのアクセスは、監査のためのトレースをサポートする必要があります。
回答領域で適切な選択肢を選択してください。
回答
- 下記画像参照
-
tool_choiceをrequiredに設定すると、モデルは応答を生成する際に少なくとも1つのツールを必ず呼び出すため、取得ステップを必須にできます。
autoではツールを呼び出さない可能性があり、noneではツール呼び出しが禁止されます。公開前のエージェントはプロジェクト内でIDを共有しますが、公開後はエージェントごとに一意のエージェントIDが割り当てられます。
個別のエージェントIDを使用すると、他のプロジェクトリソースからアクセス権を分離し、エージェント単位で認証、権限管理、監査を行えます。
APIキーをプロンプトに保存する方法は安全ではなく、共有プロジェクトIDでは必要な分離を実現できません。
Microsoft FoundryではApplication InsightsとOpenTelemetryを使用して、取得処理やツール呼び出しを含む実行トレースを記録できます。
Microsoft Foundry のエージェント ID の概念
モデルコンテキストプロトコル（MCP）ツールの認証を設定する
Q5.Microsoft Foundry Agent Serviceを使用して、カスタマーサポートエージェントを作成する計画を提案する必要があります。
エージェントは、次の要件を満たす必要があります。
複数の会話にわたってユーザーの設定を保持する。
チャット中にユーザーがドキュメントを直接アップロードし、コンテキストに基づくグラウンディングを行えるようにする。
各要件に対して、どのFoundry機能を推奨すべきですか。
回答領域で適切な選択肢を選択してください。
回答
- 下記画像参照
-
エージェントメモリは、ユーザーの設定や過去の対話から抽出した情報を永続的なメモリストアに保持し、異なるセッションや会話でも再利用できる長期記憶機能です。
会話履歴やセッションコンテキストは、主に同一会話または一時的な実行状態の継続に使用されます。
ファイル検索ツールは、チャット中にアップロードされたドキュメントをベクトルストアへ登録し、その内容を検索して回答の根拠として使用します。
Azure AI Searchは事前構築された企業検索基盤との連携に適し、コードインタープリターはファイルの計算やデータ分析を目的とします。
旧称のAzure AI Foundryは、現在Microsoft Foundryという名称で案内されています。
Microsoft Foundry Agent Service のメモリ (プレビュー)
Foundry Agent Service でのメモリの作成と使用 (プレビュー)
Q6.Microsoft Foundryプロジェクト内にチャットアプリと、Azure AI Searchのベクトル化されたインデックスがあります。
次の要件を満たすために、チャットアプリをインデックスへ接続する必要があります。
複雑な質問では、複数のチャンクから情報を取得する必要があります。
複数ターンの会話内容を取得計画に反映する必要があります。
待機時間を短縮するために、取得処理を並列実行する必要があります。
どの取得アプローチを使用すべきですか。
A. 従来型の検索拡張生成（RAG）
B. 思考の連鎖
C. エージェント型検索拡張生成（RAG）
D. 反復型取得
回答
- C. エージェント型検索拡張生成（RAG）
-
エージェント型取得は、LLMを使用して複雑な質問を複数の焦点を絞ったサブクエリへ分解し、複数のチャンクから関連情報を取得するマルチクエリ型のRAGパイプラインです。
サブクエリの生成には会話履歴も含められるため、過去のターンを考慮した取得計画を実現できます。
さらに、生成したサブクエリを並列実行した後、取得結果を統合して再ランク付けするため、精度を維持しながら待機時間を抑えられます。
従来型RAGは通常、単一の検索クエリを使用するため、この要件には不十分です。
思考の連鎖は推論手法であり、Azure AI Searchの取得方式ではありません。
したがって、複数チャンク、会話履歴を考慮した計画、並列取得という3要件をすべて満たすエージェント型RAGが正解です。
現在のMicrosoft公式ドキュメントでは、この機能は「エージェント検索」または「エージェント型取得」と表記されます。
Azure AI 検索でのエージェント主導の検索取得
Azure AI 検索 でのレトリーバル拡張生成 (RAG)
Q7.Microsoft Foundryのマルチモーダルモデルのデプロイを使用する、App1という名前のアプリがあります。
App1は、アップロードされた画像に対して光学式文字認識（OCR）を実行し、OCRの出力を追加のコンテキストとしてプロンプトに付加します。
アップロードされる画像の一部には、埋め込まれたテキストが含まれています。
悪意がある可能性のある指示がモデルによって処理されることを防ぐ必要があります。
何を使用すべきですか。
A. 保護された素材のテキスト検出
B. ユーザープロンプト向けPrompt Shields
C. 画像モデレーション
D. ドキュメント向けPrompt Shields
回答
- D. ドキュメント向けPrompt Shields
-
画像からOCRで抽出されたテキストは、ユーザーが直接入力したプロンプトではなく、外部コンテンツとしてプロンプトへ追加されるため、間接プロンプトインジェクションとして扱います。 ドキュメント向けPrompt Shieldsは、文書、電子メール、Webページ、画像から抽出したテキストなどに埋め込まれた悪意ある指示を検出します。
ユーザープロンプト向けPrompt Shieldsは、ユーザーが直接入力した攻撃の検出に使用します。
画像モデレーションは暴力や性的表現などの有害な視覚コンテンツを検出する機能であり、OCRテキスト内の命令への対策ではありません。
したがって、OCR出力をモデルへ渡す前にドキュメント向けPrompt Shieldsで検査することが適切です。
保護された素材の検出は著作権保護対象との一致を検出する機能であり、本要件には該当しません。
プロンプト シールド
Microsoft Foundry のプロンプト シールド
Q8.注：このセクションには、同じシナリオと問題に基づく1つ以上の問題セットが含まれています。
各問題では、その問題に対する固有の解決策が提示されます。
その解決策が、記載された目標を満たしているかどうかを判断する必要があります。
セット内の複数の解決策が問題を解決する場合もあれば、どの解決策も問題を解決しない場合もあります。このセクションの問題に回答すると、前の問題に戻ることはできません。
そのため、これらの問題はレビュー画面には表示されません。
エージェントを含むMicrosoft Foundryプロジェクトがあります。このエージェントは、取得したポリシードキュメントから要約を生成します。
取得されたコンテンツ内に必要な規制条項が存在する場合でも、一部の応答でその条項が欠落しているとユーザーから報告されています。
応答の完全性を向上させる必要があります。
解決策：応答の完全性を採点し、定義されたしきい値を下回る応答をブロックする評価フローを実行します。
この解決策は目標を満たしていますか。
A. はい
B. いいえ
回答
- B. いいえ
-
応答完全性の評価は、生成された回答が正解データや期待される回答に含まれる重要な情報をどの程度網羅しているかを測定する機能です。
しきい値未満の回答を検出してブロックすることはできますが、欠落した規制条項を回答へ追加したり、生成処理自体を改善したりするものではありません。
完全性を向上させるには、取得内容と生成結果を照合し、不足がある場合に再生成または修正させる検証処理を追加する必要があります。
評価フローは品質を測定する仕組みであり、それだけでは回答品質を改善する制御にはならないため、この解決策は目標を満たしません。
Retrieval-Augmented 生成 (RAG) エバリュエーター
回答完全性評価者クラス
Q9.Project1という名前のMicrosoft Foundryプロジェクトと統合する、App1という名前のPythonアプリケーションがあります。
App1が次の要件を満たすようにする必要があります。
Microsoft EntraマネージドIDを使用して認証する。
Azure OpenAI Responses APIを使用して、デプロイ済みモデルへプロンプトを送信する。
Pythonコードをどのように完成させるべきですか。回答領域で適切な選択肢を選択してください。
回答
- 下記画像参照
-
DefaultAzureCredentialは、Azure上で実行されるアプリケーションに割り当てられたマネージドIDを自動的に検出し、Microsoft Entra IDの資格情報として使用できます。 AzureKeyCredentialはAPIキーによる認証であり、ClientSecretCredentialはテナントID、クライアントID、クライアントシークレットを使用するサービスプリンシパル認証であるため、マネージドIDの要件には適合しません。
AIProjectClientのget_openai_clientメソッドで認証済みのOpenAIクライアントを取得し、responses.createメソッドを使用すると、入力プロンプトをデプロイ済みモデルへ送信して新しい応答を生成できます。 responses.retrieveは既存の応答を取得する処理であり、新しい推論要求の送信には使用しません。compactも新しい応答を生成するためのメソッドではありません。
現在、Azure AI FoundryはMicrosoft Foundryへ名称が変更されていますが、azure.ai.projectsのAIProjectClientとResponses APIを組み合わせる基本的な構成は同じです。
Microsoft Foundry SDK とエンドポイント
Azure OpenAI Responses API を使用する
Q10.Azure Blob Storageに保存されているスキャン済みのPDF請求書を取り込むMicrosoft Foundryプロジェクトがあります。
各請求書には印刷された明細項目が含まれ、表形式のレイアウトになっています。
抽出結果は構造化JSONとして保存され、検索拡張生成（RAG）ソリューション内のエージェントが使用するグラウンディングデータとして利用されます。
次の要件を満たす単一のアナライザーを作成する必要があります。
さまざまなテンプレートの請求書から、請求書番号、請求日、仕入先名、合計金額を抽出する。
信頼度が0.80未満の結果を上司によるレビューへ回せるように、信頼度スコアを返す。
何を使用すべきですか。
A. Foundry ToolsのAzure Content Understandingにある事前構築済みレイアウトアナライザー
B. 請求書フィールドと信頼度スコアを抽出するために、グラウンデッドネスのガードレールを有効にしたFoundryエージェント
C. 必要なフィールドを抽出フィールドとして定義し、ルーティングに使用する信頼度スコアを返す、Foundry ToolsのAzure Content Understandingカスタムアナライザー
D. Foundry ToolsのAzure Content Understandingにある事前構築済みdocumentSearchアナライザーと、ルーティングに使用するAzure AI Search結果のsearch.score
回答
- C. 必要なフィールドを抽出フィールドとして定義し、ルーティングに使用する信頼度スコアを返す、Foundry ToolsのAzure Content Understandingカスタムアナライザー
-
Azure Content Understandingのカスタムアナライザーでは、請求書番号、請求日、仕入先名、合計金額など、必要な業務フィールドをスキーマとして定義し、異なる帳票レイアウトから構造化JSONとして抽出できます。
また、各抽出結果には0から1の信頼度スコアを含められるため、0.80未満を人による確認へ回す処理を実装できます。
レイアウトアナライザーは文字、表、配置の抽出が中心で、請求書固有の業務項目を定義しません。
グラウンデッドネス評価は生成回答の根拠性を測るもので、帳票フィールド抽出には使用しません。
search.scoreも検索結果の関連度であり、抽出値の信頼度ではありません。
したがって、フィールド抽出と信頼度に基づくルーティングを単一構成で実現できるカスタムアナライザーが適切です。
現在の正式名称は「Azure Content Understanding in Foundry Tools」です。
Foundry Tools のドキュメント ソリューションにおける Azure Content Understanding
Content Understanding アナライザーとは
