第1章 AI エージェントはどのように動くのか
本章は初稿です。
1.1 この章で学ぶこと
「社内の問い合わせに答える AI サービスを作りたい」とき、チャットの画面と、その向こう側で回答するモデルを思い浮かべるかもしれません。しかし、社内の手順を調べ、足りない情報を聞き返すには、モデル以外の仕組みも必要です。
本章では、AI 活用と AI エージェントの関係を定義したうえで、モデル、指示、ツール、文脈、実行制御の役割を学びます。読み終えたら、単発の AI 処理や固定したワークフローと、状況に応じて相談を進める AI エージェントの違いを、自分の言葉で説明できることを目指します。
1.2 AI 活用と AI エージェントの違いを定義する
AI 活用 とは、分類、予測、要約、回答生成などに AI を使い、情報処理や業務を支援・実行することです。AI をどのように役立てるかという広い概念であり、AI エージェントも含みます。
AI エージェントという言葉の範囲は資料によって異なります。本教材では LLM を使うシステムを対象に、あらかじめ定めた処理の流れと、モデルが動的に進め方を選ぶ構成を区別します。[^agent-workflows]
AI エージェント とは、与えられた目的に向けて、現在の状況や実行結果を踏まえてモデルが次の行動を選び、必要に応じて情報の確認やツールの利用を繰り返す仕組みと定義します。次の行動には、利用者へ質問する、検索する、得られた根拠から回答して終了する、といった選択が含まれます。
したがって、AI エージェントは AI 活用の一形態であり、両者は対立する概念ではありません。 違いを見る軸は「AI を使っているか」ではなく、「作業の進め方をモデルにどこまで委ねているか」です。同じ社内 IT サービス支援でも、次のように作り方を分けられます。
| 作り方 | 次の処理をどう決めるか | 社内 IT サービス支援での例 |
|---|---|---|
| 単発の AI 処理 | 人やプログラムが一回の処理を指定する | 問い合わせ文を要約する |
| 固定した AI ワークフロー | プログラムで決めた順序や分岐に沿って進む | OS の抽出、文書検索、回答生成を決めた順序で行う |
| AI エージェント | モデルが状況と実行結果から、許可された次の行動を選ぶ | 情報不足ならユーザに確認し、必要な検索や追加調査を選んでから回答する |
これらはすべて AI 活用です。固定ワークフローにも AI による分類や条件分岐を組み込めます。ツールの利用、複数回のモデル呼び出し、繰り返し処理があるだけでは、 AI エージェントとは判断できません。RAG も検索結果で回答を補う考え方であり、検索から回答までを固定した処理にも、モデルが検索の必要性を判断する AI エージェントにも組み込めます。[^rag]
AI エージェントの自律性は、無制限の操作権限ではありません。モデルが行動を選んでも、実行してよいかの検証、必要な承認、呼び出し回数の上限、強制的な停止は、実行側で制御します。人の承認を必要とする設計でも、承認の前後でモデルに行動選択を委ねる範囲があれば、 AI エージェントとして構成できます。
これらは優劣の序列ではなく、組み合わせられる設計です。文章の要約だけなら一回のモデル呼び出し、毎回同じ手順で答えるなら固定ワークフローを選び、状況に応じた進め方の選択が必要な部分でエージェントを検討します。
イラスト：AI 活用の中で、作業の委ね方を使い分ける。 人物、ロボット、道具の絵は役割をつかむためのイメージです。実際の通信経路や実行順序は、次節の基本構成図と1.5節の SVG ワークフローで確認します。ロボットの絵が、モデルだけで検索や権限検証を実行することを意味するわけではありません。
1.3 図で基本構成をつかむ
Foundry の公式資料は、モデル、指示、ツールを組み合わせて AI エージェントを定義する考え方を示しています。[^prompt-agent] アプリケーション全体を理解するために、ここでは文脈と実行制御も加え、五つの役割に分けて考えます。
サービス上の Agent という定義と、処理の進め方をどこまでモデルに委ねるかは、別の観点です。第7章ではモデルと指示で最小の応答を作り、第10章以降でツールの選択と実行を加えていきます。Agent を作成したことだけで、自律性や操作権限が決まるわけではありません。
図1-1 モデルの外側にも、エージェントを動かす仕組みがある。 矢印は情報や要求が渡る方向です。「実行側の検証」は、モデルの提案と実際の操作の間にあります。責務を理解するための概念図であり、特定の SDK のクラス構造や、Azure 上の物理配置を示してはいません。
| 役割 | 社内 IT サービス支援での例 | その役割だけではできないこと |
|---|---|---|
| モデル | 質問を解釈し、回答や検索要求を生成する | 社内手順の正しさや利用者の権限を保証する |
| 指示 | 根拠不足なら確認する、回答を短くする、と伝える | API の権限検証を実装する |
| ツール | 社内の手順書を検索する関数を提供する | 名前を定義するだけで実際の検索を完了する |
| 文脈・状態 | OS、前の回答、試した手順を引き継ぐ | 保存した全情報を毎回モデルへ入力する |
| 実行制御 | 呼び出し、入力検証、結果の返却、終了を管理する | 生成される回答の正しさを無条件に保証する |
モデルの判断を、使える道具と実行のルールにつないだ仕組みとして捉えてください。高度なモデルを選ぶことと、アプリケーションを完成させることは同じではありません。
1.4 一つの相談を五つの役割で読む
社員が「VPN につながりません」と尋ねたとします。最初の入力だけでは、OS、表示されたエラー、どの手順を試したかが分かりません。 AI エージェントは必要な情報を確認し、社員が「Windows です」と答えたら、その文脈を踏まえて検索します。
ここでモデルが返すのは、「検索関数をこの引数で使いたい」という要求です。アプリケーションは、利用可能な関数か、引数が正しいかを確認してから実行します。検索側では、その社員が読める文書だけを取り出します。得られた根拠をモデルへ返し、回答を生成します。
この相談は、次のように説明できます。
| 場面 | 主に働く役割 |
|---|---|
| OS が不明なので質問する | モデルと指示 |
| 「Windows です」を前の相談に結び付ける | 文脈と会話の管理 |
search_knowledge を要求する | モデルとツールの定義 |
| 引数と閲覧範囲を確認して検索する | 実行制御と検索プログラム |
| 取得した手順から根拠付きで答える | モデル、指示、検索結果 |
| 回答を返し、追加の操作をしない | 実行制御の終了条件 |
「モデルが検索した」と一括りにせず、要求、実行、結果の利用を分けることが、後の章の出発点です。
1.5 小さな実習：相談の流れを分解する
次のやり取りを紙やテキストへ書き、各行に「モデル」「指示」「ツール」「文脈」「実行制御」のどれが関係するかを付けてください。複数付いて構いません。
- 社員が「VPN につながらない」と相談する。
- エージェントが OS を尋ね、社員が Windows と答える。
- アプリケーションが Windows 向けの閲覧可能な手順を検索する。
- エージェントが手順の参照先を示して回答する。
- 根拠がなければ、社内の設定値を作らずに確認先を案内する。
たとえば3行目には、実行制御とツールが関係します。検索語の提案にはモデルが関係しますが、閲覧権限の決定はモデルへ任せません。成果物は、各行の担当を記入した一枚の処理表です。Azure への接続は必要ありません。
図1-2 確認の直後ではなく、検証・検索と結果の返却を終えてから回答を分ける。 上から下へ読み、実線は通常の流れ、破線は異常終了への経路です。社員とのやり取りはアプリが仲介し、モデルは質問・検索要求・回答を生成します。ツールのローカル関数を実行するのはアプリです。
A は、Windows 向けの資料に回答の根拠があり、手順と参照先を案内する場合です。B は、正常に検索しても必要な根拠が得られず、社内 IT の確認先を案内する場合です。関連資料があるだけでは A に進めません。また、検索の失敗は B と同じではなく、根拠の有無を確認できていないため、実行側で止めて失敗を伝えます。
1.6 確認課題
ここでは、前節の VPN 相談を題材に、五つの役割を取り違えずに説明できるかを確認します。表の問いに自分の言葉で答えたうえで、右欄と以下の説明を照らし合わせてください。判断の基準は、「誰が次の行動を選ぶか」と「誰が実行条件を確認するか」です。
| 問い | 理解できていれば説明できること |
|---|---|
| AI を使う処理はすべて AI エージェントか | AI 活用は上位概念であり、単発処理や固定ワークフローも含む |
| 検索ツールがあれば AI エージェントになるか | ツールの有無ではなく、状況に応じた行動選択をモデルに委ねるかを見る |
| AI エージェントなら承認を省略してよいか | 自律性と操作権限は別であり、承認が必要な操作は実行側で確認する |
| 指示に「社内規程に従う」と書けば十分か | 参照する規程の取得と、その文書の閲覧制御も必要である |
| 関数名をモデルへ教えれば検索が実行されるか | 定義とは別に実装、実行、結果の返却が必要である |
| 自律性を高めるほどよい設計か | 目的によっては固定した処理順序のほうが分かりやすい |
| 終了条件は何のためにあるか | 不要な呼び出しや終わらない処理を抑え、利用者へ状態を返すためである |
AI 活用と AI エージェントの区別 では、検索機能の有無よりも、次の行動を選ぶ主体に注目します。たとえば、OS の抽出、文書検索、回答生成をプログラムが決めた順に行うなら、AI を使う固定ワークフローとして構成できます。OS を尋ねる必要があるか、検索結果が回答に十分か、追加の調査をするかを、状況に応じてモデルへ選ばせるなら、その範囲で AI エージェントの行動選択を委ねています。
指示と実行側の検証は、同じものではありません。「社内規程に従う」と書いても、規程の取得や閲覧権限の確認が実装されるわけではありません。Windows 向けの手順を検索する際も、社員が閲覧できる文書だけを対象にする処理が必要です。更新操作を加える場合は、必要な承認を実行側で確認します。モデルの「承認済み」という出力だけを、本人の承認として扱ってはいけません。
ツールの定義と実行も分けて考えます。search_knowledge という関数の名前や引数を教えるのは、モデルが検索要求を生成するための準備です。実際には、アプリケーションが利用可能な関数か、引数が正しいかを検証し、検索を実行して結果をモデルへ返す必要があります。回答までの流れを説明するときには、この要求、検証、実行、結果の返却を省略しないでください。
自律性は高いほどよいわけではありません。 毎回同じ検索をして答える用途なら、順序を固定したほうが処理を把握しやすくなります。不足情報や検索結果によって進め方を変える必要がある部分だけをモデルへ任せ、利用できる道具と操作の範囲は実行側で定めます。
終了条件には、正常に回答できたときだけでなく、根拠不足や処理を継続できない場合も含めます。VPN の相談なら、手順が見つかれば参照先を示して回答し、根拠が得られなければ確認先を案内する、といった結末を決めます。呼び出し回数などの上限に達した場合や検索が失敗した場合には、実行側で処理を止め、未完了や失敗の状態を利用者へ伝える設計が必要です。
1.7 まとめ
AI 活用は広い概念であり、 AI エージェントは状況に応じた次の行動の選択をモデルに委ねる一つの設計です。すべての処理を AI エージェントにする必要はなく、単発処理や固定ワークフローと使い分けます。
AI エージェント開発では、モデルの出力だけでなく、その外側で情報と処理をつなぎます。五つの役割を分け、一つの相談がどこを通るかを説明できるようにしましょう。次章では、この構成を Microsoft Foundry の用語へ対応付けます。
1.8 参考情報
- Quickstart: Create a prompt agent — モデルと指示を持つ最初の AI エージェントを学ぶ入口
- Retrieval augmented generation (RAG) and indexes in Microsoft Foundry — 検索とモデルを組み合わせる考え方
[^prompt-agent]: Quickstart: Create a prompt agent — Microsoft
[^rag]: Retrieval augmented generation (RAG) and indexes in Microsoft Foundry — Microsoft
[^agent-workflows]: Building effective agents — Anthropic