AI-103 · LESSON 2

生成 AI とエージェントソリューションの実装30–35% · 3項目

Foundry での生成アプリとエージェントの構築、そして生成 AI システムの最適化と運用を学びます。

2.1Foundry で生成アプリを構築する

Build generative applications by using Foundry

概念

生成アプリは、システムメッセージ・ユーザーの入力・取り出した文脈(RAG)を組み合わせてモデルに渡し、応答を返します。Chat Completions / Responses API、構造化出力(JSON スキーマ)、関数呼び出し、ストリーミングなどを使い分けます。

仕組み・手順

  1. 役割・制約・出力形式をシステムメッセージに書く
  2. 必要なら Few-shot の例を加える
  3. 社内データは AI Search などで検索し、文脈としてプロンプトに入れる(RAG)
  4. 後続の処理で使う出力は JSON スキーマの構造化出力にする
  5. temperature や最大トークン数を用途に合わせて調整する

業務での例

問い合わせの分類と要約を 1 回の呼び出しで行い、{category, summary, urgency} の JSON スキーマで返させて、チケットのシステムに直接登録する。

紛らわしい点・試験の注意

ミニクイズ

Q1. RAG(検索拡張生成)を採用する主な目的として最も適切なものはどれか。

  1. 社内文書を検索して根拠として渡し、再学習なしで最新の情報に基づき回答させる
  2. 社内文書でモデルをファインチューニングし、最新の社内情報を重みに覚えさせる
  3. 社内文書の全文をシステム メッセージに入れ、毎回の要求で同じ情報を渡す
  4. モデルのコンテキスト長を広げ、一度に扱えるトークン数を増やして回答させる
答えと解説を見る

正解:A 社内文書を検索して根拠として渡し、再学習なしで最新の情報に基づき回答させる

RAG は検索した根拠をプロンプトに含めることで回答を根拠付ける。 【他の選択肢】微調整は頻繁な更新に追従しにくく根拠も示せない。全文の投入はコストと上限の問題がある。コンテキスト長の拡大は検索の代わりにならない。

Q2. エージェントに複数のツールを持たせたところ、意図しないツールが呼ばれることがある。最初に見直すべき点はどれか。

  1. エージェントに使うモデルのバージョンと、temperature・top_p の設定値
  2. ツールの実行結果に付けるメタデータと、トレースの保存期間
  3. 各ツールの名前・説明・パラメーター定義(ツール スキーマ)の明確さ
  4. ツールの呼び出しに使うマネージド ID のロール割り当て
答えと解説を見る

正解:C 各ツールの名前・説明・パラメーター定義(ツール スキーマ)の明確さ

モデルはツールの説明とスキーマを読んで呼び分ける。曖昧だと誤選択が起きる。 【他の選択肢】モデルや temperature も影響し得るが、まず見るのはツールの定義である。メタデータやロールは呼び分けの判断材料ではない。

参考リンク

2.2Foundry でエージェントを構築する

Build agents by using Foundry

概念

Foundry Agent Service のエージェントは、モデル・指示・ツール(ファイル検索・コードインタープリター・AI Search・Bing によるグラウンディング・関数・OpenAPI・MCP など)を組み合わせ、スレッド(会話)の中で複数の手順を実行します。複数のエージェントを連携させる構成(コネクテッドエージェント・ワークフロー)も作れます。

仕組み・手順

  1. エージェントの目的と指示(何をして何をしないか)を定義する
  2. 必要なツールを最小限で追加する(ナレッジは File Search や AI Search、外部操作は関数・OpenAPI・MCP)
  3. スレッドを作り、メッセージを追加して実行(Run)する
  4. ツール呼び出しの結果とトレースを確認する
  5. 影響の大きいツールには承認や権限の制限を設ける

業務での例

出張申請のエージェントが、規程を AI Search で調べ、関数で社内の申請 API を呼び、申請の前に本人の確認を求める。

紛らわしい点・試験の注意

ミニクイズ

Q1. 社員との複数回のやり取りで、前の質問内容を踏まえて回答させたい。必要なものはどれか。

  1. temperature を下げ、同じ質問への応答を安定させる設定
  2. 会話履歴(スレッド)の管理と、保持する情報の方針
  3. 前回の質問だけをシステム メッセージに上書きで保存する
  4. 要求ごとに新しいスレッドを作り、前回の応答をキャッシュする
答えと解説を見る

正解:B 会話履歴(スレッド)の管理と、保持する情報の方針

マルチターン対応には会話の状態管理が必要。何を保持するかはプライバシーの観点でも決める。 【他の選択肢】要求ごとの新しいスレッドでは文脈が失われる。temperature は文脈の保持と関係しない。前回の質問だけでは複数回のやり取りを踏まえられない。

Q2. 受注処理を「内容抽出」「在庫確認」「例外報告」に分けて自動化したい。適切な設計はどれか。

  1. 3 つの工程を別々のモデル デプロイで並列に実行し、結果を連結する
  2. 単一のエージェントに全ツールを持たせ、工程の順序はモデルに任せる
  3. 1 つのプロンプトに全工程を記述し、1 回の呼び出しでまとめて処理させる
  4. 役割ごとのエージェントを連携させるマルチエージェント構成
答えと解説を見る

正解:D 役割ごとのエージェントを連携させるマルチエージェント構成

役割分割で各エージェントの責務が明確になり、評価・改善もしやすい。 【他の選択肢】1 回の呼び出しでは工程ごとの検証や例外処理が難しい。並列実行は順序に依存する工程に合わない。順序をモデルに任せると例外報告の扱いが不安定になる。

参考リンク

2.3生成 AI システムを最適化・運用する

Optimize and operationalize generative AI systems

概念

本番の生成 AI では、品質(評価)・コスト(トークン・モデルの選択)・性能(レイテンシ・スループット)・信頼性(再試行・冗長化)を継続的に最適化します。評価をリリースのゲートに組み込み、トレースで問題を特定します。

仕組み・手順

  1. 評価データセットと評価器で品質の基準を決める
  2. より小さいモデルで基準を満たせるか比べ、コストを下げる
  3. プロンプトのキャッシュ、出力トークンの制限、バッチの利用でコストとレイテンシを下げる
  4. 429 に備えて再試行と複数デプロイへの振り分けを実装する
  5. トレースと継続的な評価で本番の品質を監視する

業務での例

回答の品質を保ったまま、分類の処理を小さいモデルに切り替えて費用を 70% 減らし、評価の指標が下がらないことを毎週確認する。

紛らわしい点・試験の注意

ミニクイズ

Q1. 生成アプリの評価で、根拠文書にない内容を回答する問題(捏造)を検出したい。適切な評価はどれか。

  1. 根拠性(groundedness)の評価
  2. 一貫性(coherence)の評価
  3. 応答の関連性(relevance)の評価
  4. 流暢性(fluency)の評価
答えと解説を見る

正解:A 根拠性(groundedness)の評価

根拠性評価は、回答が与えられた根拠に支えられているかを測る。 【他の選択肢】流暢性と一貫性は文章の自然さや論理のつながり、関連性は質問への適合度を測るもので、根拠文書にない内容の捏造は検出しない。

Q2. 複数ステップの推論パイプラインで、途中のステップの結果を次のステップに渡す。品質を保つための設計として最も適切なものはどれか。

  1. 各ステップの出力形式を決め、次に進む前に検証する
  2. 中間結果は記録せず、最終結果だけを評価する
  3. 各ステップで温度を上げ、多様な中間結果を得る
  4. 全ステップを 1 つの長いプロンプトにまとめて実行する
答えと解説を見る

正解:A 各ステップの出力形式を決め、次に進む前に検証する

ステップごとに形式を決めて検証すると、どこで誤りが起きたかを特定しやすく、誤りが後段に伝わるのを防げる。 【他の選択肢】1 つのプロンプトでは途中の誤りを検出できない。温度を上げると中間結果が不安定になる。中間結果がないと原因を追えない。

参考リンク

レッスンは当サイトがMicrosoft Learn の公開ページをもとに独自に作成したもので、試験の内容を保証するものではありません。製品の仕様は変わることがあるため、参考リンク先の最新情報を確認してください。

ご利用上の注意(非公式・独自問題・合格保証なし)