Q1.注：このセクションには、同一のシナリオと課題を扱う問題セットが1つ以上含まれています。
各問題には、その課題に対する固有の解決策が示されます。
提示された解決策が、記載された目標を達成しているかどうかを判断してください。
セット内では、複数の解決策が有効な場合もあれば、いずれの解決策も目標を満たさない場合もあります。
この区分の問題に解答すると、前の問題へ戻ることはできません。
そのため、これらの問題はレビュー画面に表示されません。
ある企業では、画像のアップロードを受け付け、画像から読み取ったテキストを基に応答を生成するマルチモーダル生成AIモデルを運用しています。
利用者が危険な画像を送信したり、モデルを誘導する隠し指示を画像内へ埋め込んだりできることが判明しました。
このリスクを抑えるための制御を導入する必要があります。
解決策：保護された素材の検出を構成します。
この解決策は目標を満たしていますか。
解答を見る
保護された素材の検出は、既知の文章・歌詞・記事・レシピ・コードなど著作権で保護されたコンテンツと生成結果が一致するかを判定する機能です。
安全でない画像や、画像内に埋め込まれた隠し命令への対策ではありません。
危険な画像そのものにはAzure AI Content Safetyの画像分析を用い、画像から抽出された悪意ある指示のような間接プロンプトインジェクションにはPrompt Shieldsによるドキュメント攻撃検出を利用します。
したがって、この解決策だけでは目標を満たしません。
なお現在、Azure AI Content SafetyはMicrosoft Foundryからも利用できますが、サービス名自体に変更はありません。
プロンプト シールド
Azure AI Content Safety とは?
Q2.あるヘルプデスク部門では、Microsoft Foundry Agent Serviceを利用したカスタマーサポートエージェントを運用しています。
顧客が数日後に同じ問い合わせ案件を再開するため、セッションへ戻ってくることがあります。
その際、エージェントは過去のやり取りを完全に引き継いだ状態で応対を再開する必要があります。
エージェントには次の機能が求められます。
セッション内での複数ターンにわたる継続性
同一案件についてセッションをまたいだ継続性
ユーザーメッセージ、エージェントメッセージ、ツール呼び出し、ツール出力を含む、対話の完全な履歴へのアクセス
さらに、新しいターンごとにエージェントが完全な履歴を自動で再読み込みする必要があります。
どの方法を採用すべきですか。
解答を見る
Microsoft Foundry Agent Serviceの会話オブジェクトは、複数ターンにわたるメッセージやツール実行結果を保持する永続的な単位です。
会話IDを案件と関連付けて保存し、後続の要求で同じIDを指定すれば、サービス側に残る会話履歴をそのまま再利用できます。
最終応答だけを保存する方法では、ユーザーメッセージやツール呼び出し、ツール出力が失われます。
また、要約メモリは情報を圧縮するため、完全な履歴を保持する要件には適しません。
したがって、同一案件では同じ会話IDを継続して使用する方法が正解です。
旧ドキュメントでは「スレッド」と表記される場合もありますが、新しいサービスでは主に「会話」と「応答」という構成要素が使われます。
エージェント、会話、応答を使用して構築する
クイック スタート: Microsoft Foundry SDK の概要
Q3.大量のチャット要求を捌くMicrosoft Foundryプロジェクトを運用しています。
寄せられる要求の大半は単純なFAQですが、一部には高度な推論を要するものがあります。
複雑な質問への回答品質を落とさずに、一般的な問い合わせにかかるコストと待機時間を抑える必要があります。
どの方法が適切ですか。
解答を見る
モデルカスケードでは、単純な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のベクトル化済みインデックスがあります。
次の要件を満たすよう、チャットアプリをこのインデックスへ接続する必要があります。
複雑な質問では、複数のチャンクから情報を集める必要があります。
複数ターンの会話内容を取得計画へ反映する必要があります。
待機時間を短縮するため、取得処理を並列で実行する必要があります。
どの取得アプローチを採用すべきですか。
解答を見る
エージェント型取得は、LLMを使って複雑な質問を焦点を絞った複数のサブクエリへ分解し、複数のチャンクから関連情報を集めるマルチクエリ型のRAGパイプラインです。
サブクエリの生成に会話履歴を含められるため、過去のターンを踏まえた取得計画を実現できます。
さらに生成したサブクエリを並列実行し、取得結果を統合して再ランク付けするため、精度を保ちながら待機時間を抑えられます。
従来型RAGは通常単一の検索クエリを使うため要件を満たせず、思考の連鎖は推論手法でAzure AI Searchの取得方式ではありません。
複数チャンク、会話履歴を考慮した計画、並列取得という3要件をすべて満たすエージェント型RAGが正解です。
現在の公式ドキュメントでは、この機能は「エージェント検索」または「エージェント型取得」と表記されます。
Azure AI 検索でのエージェント主導の検索取得
Azure AI 検索 でのレトリーバル拡張生成 (RAG)
Q7.Microsoft Foundryのマルチモーダルモデルのデプロイを利用する、App1という名前のアプリがあります。
App1はアップロードされた画像に光学式文字認識（OCR）を実行し、その出力を追加のコンテキストとしてプロンプトへ付加します。
アップロードされる画像の一部には、埋め込まれたテキストが含まれています。
悪意ある可能性のある指示がモデルによって処理されるのを防ぐ必要があります。
何を使用すべきですか。
解答を見る
画像からOCRで抽出されたテキストは、ユーザーが直接入力したプロンプトではなく外部コンテンツとしてプロンプトへ追加されるため、間接プロンプトインジェクションとして扱います。
ドキュメント向けPrompt Shieldsは、文書・電子メール・Webページ・画像から抽出したテキストなどに埋め込まれた悪意ある指示を検出します。
ユーザープロンプト向けPrompt Shieldsは、ユーザーが直接入力した攻撃の検出に使います。
画像モデレーションは暴力や性的表現などの有害な視覚コンテンツを検出する機能で、OCRテキスト内の命令への対策ではありません。
したがって、OCR出力をモデルへ渡す前にドキュメント向けPrompt Shieldsで検査するのが適切です。
保護された素材の検出は著作権保護対象との一致を検出する機能であり、本要件には該当しません。
プロンプト シールド
Microsoft Foundry のプロンプト シールド
Q8.注：このセクションには、同一のシナリオと課題を扱う問題セットが1つ以上含まれています。
各問題には、その課題に対する固有の解決策が示されます。
提示された解決策が記載された目標を達成しているかどうかを判断してください。
セット内では複数の解決策が有効な場合もあれば、いずれの解決策も目標を満たさない場合もあります。
この区分の問題に解答すると、前の問題へ戻ることはできません。
そのため、これらの問題はレビュー画面に表示されません。
あるエージェントを含むMicrosoft Foundryプロジェクトがあり、このエージェントは取得したポリシードキュメントから要約を生成します。
取得したコンテンツ内に必要な規制条項が存在していても、一部の応答でその条項が欠落するとユーザーから報告されています。
応答の完全性を高める必要があります。
解決策：応答の完全性を採点し、定義したしきい値を下回る応答をブロックする評価フローを実行します。
この解決策は目標を満たしていますか。
解答を見る
応答完全性の評価は、生成された回答が正解データや期待される回答に含まれる重要な情報をどの程度網羅しているかを測定する機能です。
しきい値未満の回答を検出してブロックすることはできますが、欠落した規制条項を回答へ補ったり、生成処理そのものを改善したりするわけではありません。
完全性を高めるには、取得内容と生成結果を照合し、不足があれば再生成や修正を促す検証処理を追加する必要があります。
評価フローはあくまで品質を測る仕組みであり、それだけでは回答品質を改善する制御にはならないため、この解決策は目標を満たしません。
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へ改称されていますが、AIProjectClientとResponses APIを組み合わせる基本構成は同じです。
Microsoft Foundry SDK とエンドポイント
Azure OpenAI Responses API を使用する
Q10.Azure Blob Storageに保存されたスキャン済みPDF請求書を取り込むMicrosoft Foundryプロジェクトがあります。
各請求書には印刷された明細項目が並び、表形式のレイアウトになっています。
抽出結果は構造化JSONとして保存し、検索拡張生成（RAG）ソリューション内のエージェントが使うグラウンディングデータとして活用します。
次の要件を満たす単一のアナライザーを作成する必要があります。
さまざまなテンプレートの請求書から、請求書番号、請求日、仕入先名、合計金額を抽出する。
信頼度が0.80未満の結果を上長のレビューへ回せるよう、信頼度スコアを返す。
何を使用すべきですか。
解答を見る
Azure Content Understandingのカスタムアナライザーでは、請求書番号・請求日・仕入先名・合計金額といった業務フィールドをスキーマとして定義し、レイアウトの異なる帳票から構造化JSONとして抽出できます。
各抽出結果には0から1の信頼度スコアを付与できるため、0.80未満を人による確認へ回す処理を実装できます。
レイアウトアナライザーは文字・表・配置の抽出が中心で、請求書固有の業務項目は定義しません。
グラウンデッドネス評価は生成回答の根拠性を測るもので、帳票フィールド抽出には使えません。
search.scoreも検索結果の関連度であり、抽出値の信頼度ではありません。
フィールド抽出と信頼度に基づくルーティングを単一構成で実現できるカスタムアナライザーが適切です。
Foundry Tools のドキュメント ソリューションにおける Azure Content Understanding
Content Understanding アナライザーとは