AI-103 · LESSON 2
生成 AI とエージェントソリューションの実装30–35% · 3項目
Foundry での生成アプリとエージェントの構築、そして生成 AI システムの最適化と運用を学びます。
2.1Foundry で生成アプリを構築する
Build generative applications by using Foundry
概念
生成アプリは、システムメッセージ・ユーザーの入力・取り出した文脈(RAG)を組み合わせてモデルに渡し、応答を返します。Chat Completions / Responses API、構造化出力(JSON スキーマ)、関数呼び出し、ストリーミングなどを使い分けます。
仕組み・手順
- 役割・制約・出力形式をシステムメッセージに書く
- 必要なら Few-shot の例を加える
- 社内データは AI Search などで検索し、文脈としてプロンプトに入れる(RAG)
- 後続の処理で使う出力は JSON スキーマの構造化出力にする
- temperature や最大トークン数を用途に合わせて調整する
業務での例
問い合わせの分類と要約を 1 回の呼び出しで行い、{category, summary, urgency} の JSON スキーマで返させて、チケットのシステムに直接登録する。
紛らわしい点・試験の注意
- JSON モードは「JSON であること」だけ、構造化出力は「スキーマに合うこと」まで保証する
- temperature を下げても事実の正確さは保証されない(グラウンディングが必要)
- 長い会話は履歴を要約・削減しないとトークンの上限とコストが増える
ミニクイズ
Q1. RAG(検索拡張生成)を採用する主な目的として最も適切なものはどれか。
- 社内文書を検索して根拠として渡し、再学習なしで最新の情報に基づき回答させる
- 社内文書でモデルをファインチューニングし、最新の社内情報を重みに覚えさせる
- 社内文書の全文をシステム メッセージに入れ、毎回の要求で同じ情報を渡す
- モデルのコンテキスト長を広げ、一度に扱えるトークン数を増やして回答させる
答えと解説を見る
正解:A 社内文書を検索して根拠として渡し、再学習なしで最新の情報に基づき回答させる
RAG は検索した根拠をプロンプトに含めることで回答を根拠付ける。 【他の選択肢】微調整は頻繁な更新に追従しにくく根拠も示せない。全文の投入はコストと上限の問題がある。コンテキスト長の拡大は検索の代わりにならない。
Q2. エージェントに複数のツールを持たせたところ、意図しないツールが呼ばれることがある。最初に見直すべき点はどれか。
- エージェントに使うモデルのバージョンと、temperature・top_p の設定値
- ツールの実行結果に付けるメタデータと、トレースの保存期間
- 各ツールの名前・説明・パラメーター定義(ツール スキーマ)の明確さ
- ツールの呼び出しに使うマネージド ID のロール割り当て
答えと解説を見る
正解:C 各ツールの名前・説明・パラメーター定義(ツール スキーマ)の明確さ
モデルはツールの説明とスキーマを読んで呼び分ける。曖昧だと誤選択が起きる。 【他の選択肢】モデルや temperature も影響し得るが、まず見るのはツールの定義である。メタデータやロールは呼び分けの判断材料ではない。
参考リンク
2.2Foundry でエージェントを構築する
Build agents by using Foundry
概念
Foundry Agent Service のエージェントは、モデル・指示・ツール(ファイル検索・コードインタープリター・AI Search・Bing によるグラウンディング・関数・OpenAPI・MCP など)を組み合わせ、スレッド(会話)の中で複数の手順を実行します。複数のエージェントを連携させる構成(コネクテッドエージェント・ワークフロー)も作れます。
仕組み・手順
- エージェントの目的と指示(何をして何をしないか)を定義する
- 必要なツールを最小限で追加する(ナレッジは File Search や AI Search、外部操作は関数・OpenAPI・MCP)
- スレッドを作り、メッセージを追加して実行(Run)する
- ツール呼び出しの結果とトレースを確認する
- 影響の大きいツールには承認や権限の制限を設ける
業務での例
出張申請のエージェントが、規程を AI Search で調べ、関数で社内の申請 API を呼び、申請の前に本人の確認を求める。
紛らわしい点・試験の注意
- 関数ツールはモデルが呼び出しを「提案」し、実行はアプリ側
- ツールが多すぎるとモデルの選択の誤りが増える
- エージェントの評価には、ツール呼び出しの正確さやタスクの遵守の指標を使う
ミニクイズ
Q1. 社員との複数回のやり取りで、前の質問内容を踏まえて回答させたい。必要なものはどれか。
- temperature を下げ、同じ質問への応答を安定させる設定
- 会話履歴(スレッド)の管理と、保持する情報の方針
- 前回の質問だけをシステム メッセージに上書きで保存する
- 要求ごとに新しいスレッドを作り、前回の応答をキャッシュする
答えと解説を見る
正解:B 会話履歴(スレッド)の管理と、保持する情報の方針
マルチターン対応には会話の状態管理が必要。何を保持するかはプライバシーの観点でも決める。 【他の選択肢】要求ごとの新しいスレッドでは文脈が失われる。temperature は文脈の保持と関係しない。前回の質問だけでは複数回のやり取りを踏まえられない。
Q2. 受注処理を「内容抽出」「在庫確認」「例外報告」に分けて自動化したい。適切な設計はどれか。
- 3 つの工程を別々のモデル デプロイで並列に実行し、結果を連結する
- 単一のエージェントに全ツールを持たせ、工程の順序はモデルに任せる
- 1 つのプロンプトに全工程を記述し、1 回の呼び出しでまとめて処理させる
- 役割ごとのエージェントを連携させるマルチエージェント構成
答えと解説を見る
正解:D 役割ごとのエージェントを連携させるマルチエージェント構成
役割分割で各エージェントの責務が明確になり、評価・改善もしやすい。 【他の選択肢】1 回の呼び出しでは工程ごとの検証や例外処理が難しい。並列実行は順序に依存する工程に合わない。順序をモデルに任せると例外報告の扱いが不安定になる。
参考リンク
2.3生成 AI システムを最適化・運用する
Optimize and operationalize generative AI systems
概念
本番の生成 AI では、品質(評価)・コスト(トークン・モデルの選択)・性能(レイテンシ・スループット)・信頼性(再試行・冗長化)を継続的に最適化します。評価をリリースのゲートに組み込み、トレースで問題を特定します。
仕組み・手順
- 評価データセットと評価器で品質の基準を決める
- より小さいモデルで基準を満たせるか比べ、コストを下げる
- プロンプトのキャッシュ、出力トークンの制限、バッチの利用でコストとレイテンシを下げる
- 429 に備えて再試行と複数デプロイへの振り分けを実装する
- トレースと継続的な評価で本番の品質を監視する
業務での例
回答の品質を保ったまま、分類の処理を小さいモデルに切り替えて費用を 70% 減らし、評価の指標が下がらないことを毎週確認する。
紛らわしい点・試験の注意
- 最大のモデルが常に最適ではない。評価で比べる
- バッチは安価だが即時の応答はできない
- 品質の改善とコストの削減はトレードオフになりうるので両方を測る
ミニクイズ
Q1. 生成アプリの評価で、根拠文書にない内容を回答する問題(捏造)を検出したい。適切な評価はどれか。
- 根拠性(groundedness)の評価
- 一貫性(coherence)の評価
- 応答の関連性(relevance)の評価
- 流暢性(fluency)の評価
答えと解説を見る
正解:A 根拠性(groundedness)の評価
根拠性評価は、回答が与えられた根拠に支えられているかを測る。 【他の選択肢】流暢性と一貫性は文章の自然さや論理のつながり、関連性は質問への適合度を測るもので、根拠文書にない内容の捏造は検出しない。
Q2. 複数ステップの推論パイプラインで、途中のステップの結果を次のステップに渡す。品質を保つための設計として最も適切なものはどれか。
- 各ステップの出力形式を決め、次に進む前に検証する
- 中間結果は記録せず、最終結果だけを評価する
- 各ステップで温度を上げ、多様な中間結果を得る
- 全ステップを 1 つの長いプロンプトにまとめて実行する
答えと解説を見る
正解:A 各ステップの出力形式を決め、次に進む前に検証する
ステップごとに形式を決めて検証すると、どこで誤りが起きたかを特定しやすく、誤りが後段に伝わるのを防げる。 【他の選択肢】1 つのプロンプトでは途中の誤りを検出できない。温度を上げると中間結果が不安定になる。中間結果がないと原因を追えない。
参考リンク
レッスンは当サイトがMicrosoft Learn の公開ページをもとに独自に作成したもので、試験の内容を保証するものではありません。製品の仕様は変わることがあるため、参考リンク先の最新情報を確認してください。
ご利用上の注意(非公式・独自問題・合格保証なし)
- 本サイトの問題は、公式に公開されているスキル概要・試験ガイドをもとに当サイトが独自に作成した練習問題であり、実際の試験問題ではありません。
- Microsoft、Azure、Copilot、Microsoft 365、Dynamics 365、Power Platform は Microsoft グループの商標です。本サイトは Microsoft と提携しておらず、Microsoft による承認・推奨を受けたものではありません。
- 本コンテンツは学習の補助であり、合格を保証するものではありません。試験の内容・形式・前提条件は予告なく変更されます。受験前に必ず公式ページで最新情報を確認してください。
- 本模擬試験の正答率は、公式試験の換算(スケール)スコア(合格 700)とは換算できず、合否を予測するものではありません。
- 未ログイン時の進捗はこのブラウザ内(localStorage)に保存します。Google でログインすると学習記録をアカウントに同期します。端末内の記録とサーバー上の記録は別に削除します。詳しくは保存・同期の説明とCookie・保存設定をご確認ください。