🎓 レベル:発展 | 重要度:B(標準)
📎 前提:プロンプティングとIn-context learning | 関連:検索拡張生成
要点(BLUF)
- ツール使用とは、LLM が「どの外部ツールをどんな引数で呼ぶか」を構造化出力として示し、実行は外部に任せ、その結果を文脈に戻す仕組みです。
- エージェントとは、このツール使用を推論と行動のループとして繰り返し、複数ステップで自律的にゴールへ近づく仕組みです。代表が ReAct(Reason + Act)=「考える → 行動する → 観察する」の反復。
- ⚠️ この領域は機械学習の中でも最も動きが速く、標準が定まっていません。フレームワーク名・API・プロトコルはすぐ古びるので、本ノートは廃れにくい原理だけを扱い、具体は要最新確認とします。
なぜツールが要るのか:LLM 単体の限界
LLM は次トークン予測の塊なので、得意・不得意がはっきりしています。
| 苦手なこと | なぜ苦手か | ツールで補う |
|---|---|---|
| 厳密な計算 | 算術を「確率的に」生成するため桁が増えると崩れる | 電卓・コード実行 |
| 最新情報 | 学習時点で知識が凍結している(パラメトリックな知識) | 検索・データベース |
| 外界への作用 | テキストを出すだけで、メール送信・予約・ファイル操作はできない | API 呼び出し |
| 検証・再現 | 出力が本当に正しいか自分では確かめにくい | テスト実行・外部照合 |
要するに、LLM を「推論・判断のレイヤー」に置き、実際の作業は信頼できる外部システムにやらせるという分業です。LLM は API に直接触れず、「呼びたい」という意図だけを出します。
これは 検索拡張生成(RAG)の発想の一般化です。RAG は「検索ツールを1回呼んで結果を文脈に足す」特殊形。ツール使用は検索に限らず、計算・コード・任意の API へ拡張し、しかも何回でも・条件分岐しながら呼べるようにしたものと捉えられます。
ツール使用 / 関数呼び出し(function calling)
仕組み:LLM は「呼び方」を出す、実行はしない
中心となる誤解しやすい点を先に書きます。LLM はツールを実行しません。 LLM が出すのは「この関数を、この引数で呼んでほしい」という構造化された指示(典型的には JSON)です。実行とその結果の差し戻しは、外側のプログラム(オーケストレータ)の仕事です。
流れは4段です。
- ツール定義を渡す:使えるツールの一覧(名前・用途・引数のスキーマ)をプロンプトに与える。これは プロンプティングとIn-context learning の in-context そのもの。「こういう道具があるよ」と文脈で教えるだけで、追加学習は要りません。
- LLM が呼び出しを生成:ユーザーの要求を読み、必要なら「
search(query="…")を呼びたい」という構造化出力を返す。自然な文章ではなく、機械が確実にパースできる形である点が肝心です(実運用のプログラムは文章ではなく検証済みデータを必要とするため)。 - 外部で実行:オーケストレータがその関数を実際に走らせ、結果(検索ヒット・計算値・API レスポンス)を得る。
- 結果を文脈に戻す:得られた結果を**観測(observation)**として文脈に追記し、LLM をもう一度動かす。LLM はその観測を踏まえて、最終回答を作るか、次のツールを呼びます。
flowchart TD
U["ユーザーの要求"] --> M["LLM:推論し<br/>ツール呼び出しを生成"]
M -->|"構造化出力(例:JSON)"| O["オーケストレータ<br/>(外部プログラム)"]
O -->|"関数を実行"| T["外部ツール<br/>(検索・計算・API)"]
T -->|"実行結果"| O
O -->|"結果を観測として文脈に追記"| M
M -->|"観測で十分なら"| A["最終回答"]
M -.->|"まだ足りなければ次のツールへ"| O
ポイントは、ツール使用で in-context に「観測」という新しい種類の情報が足されることです。プロンプト(指示)と例示に加えて、「実際に外界を触って得た事実」が文脈に入る。これがエージェントの土台になります。
命名の混乱(要最新確認)
同じ仕組みでも提供元で呼び名が違います。ある社は function calling、別の社は tool use、と呼びます。概念は同じ「構造化出力でツールを呼ぶ」です。⚠️ 具体的な JSON スキーマの形・対応モデル・呼び出し方法・並列呼び出しの可否・ツール接続の標準プロトコルは頻繁に変わります。実装時は必ず最新の公式仕様を確認してください。本ノートで覚えるのは「構造化出力 → 外部実行 → 観測を戻す」という不変の骨格だけで十分です。
エージェント:推論と行動のループ
1回呼ぶだけでは足りない
「東京の明日の天気を調べて、傘が要るか判断して」程度なら、検索を1回呼べば終わります。しかし「複数サイトを調べ、矛盾を確かめ、要約してファイルに保存する」のような複数ステップのタスクは、1回の呼び出しでは無理です。途中の結果を見て次の手を決める必要があります。
そこで、ツール使用をループにします。これがエージェントです。LLM が司令塔となり、「考える → 行動する → 結果を見る → また考える」を、ゴールに達するまで繰り返します。
ReAct:Reason + Act
最も基本的で廃れにくいパターンが ReAct(Reason + Act) です。各ステップで LLM は3つを順に出します。
- Thought(思考・Reason):いまの状況をどう理解し、次に何をすべきかを言語で書き出す(推論トレース)。
- Action(行動・Act):その思考に基づいて、ツールを1つ選んで引数つきで呼ぶ。
- Observation(観測):ツールの実行結果が文脈に返る。これが次の Thought の材料になる。
この Thought → Action → Observation を、ゴール達成(または上限回数到達)まで反復します。
flowchart LR
G["ゴール"] --> THINK["Thought<br/>(考える:次の一手を推論)"]
THINK --> ACT["Action<br/>(行動:ツールを呼ぶ)"]
ACT --> OBS["Observation<br/>(観察:結果を文脈へ)"]
OBS --> CHK{"ゴール達成?"}
CHK -->|"いいえ"| THINK
CHK -->|"はい"| FIN["最終回答"]
ReAct の効きどころは、推論と行動を交互に挟むことです。考えるだけ(思考の連鎖だけ)だと事実に基づかず外しやすく、行動だけだと無計画に道具を叩いてしまう。両方を絡めると、外界からの観測で推論を補正しながら進められます。研究では、推論と行動を組み合わせると、片方だけより複数ステップ課題の成功率が明確に上がることが報告されています(具体的な数値・ベンチマークは⚠️要最新確認)。
計画・実行・観察・自己反省
ReAct を土台に、より凝った構成も使われます。これらは原理のレベルで押さえてください(実装名は古びます)。
- 計画(Planning):いきなり動かず、最初にゴールをサブタスクへ分解して手順を立てる。さらに途中で計画を見直す(plan reflection)構成もある。
- 実行(Execution):立てた手順に沿ってツールを呼ぶ。
- 観察(Observation):結果を取り込み、想定とのズレを検知する。
- 自己反省(Self-reflection):自分の出力や失敗を自分で批評し、修正方針を立てて次の試行に活かす。「批判 → 書き直し」を回すことで、コーディングや複雑な質問応答の質が上がるとされます。
要するに、外界からの観測と自分の出力への内省という2種類のフィードバックで、LLM が自分の行動を逐次補正していく構図です。
メモリ:複数ステップを支える記憶
ループが長くなると、文脈に入りきらない情報をどう保持するかが問題になります。エージェントの記憶は 書く → 管理する → 読む(write–manage–read) のループとして整理でき、内容で次のように分けられます。
| 記憶の種類 | 中身 | 例 |
|---|---|---|
| 短期(作業)記憶 | いま進行中のやり取り | 直近の Thought / Observation の履歴 |
| エピソード記憶 | 過去の具体的な経験 | 前回このタスクをどう解いたか |
| 意味記憶 | 一般的な事実知識 | ドメインの定義・ルール |
| 手続き記憶 | やり方・手順 | うまくいったツール使用の型 |
長期記憶は外部ストア(多くは 検索拡張生成 と同じ検索の仕組み)に置き、必要なときだけ読み出して文脈に足します。⚠️ 記憶の持ち方・要約圧縮・忘却の戦略は研究が活発で標準化されていません。
自律性と強化学習との近さ
エージェントが「状態(観測)を見て、行動(ツール)を選び、結果を受けてまた選ぶ」という構図は、強化学習(強化学習 目次)の枠組みとそっくりです。観測=状態、ツール呼び出し=行動、ゴール達成度=報酬、と対応づけられます。
違いは、ReAct の素朴な形では方策を学習せず、LLM が in-context の指示と観測だけを頼りに、その場の推論で行動を選んでいる点です。一方で、エージェントの行動選択そのものを試行錯誤の報酬で学習させて方策を改善する研究も進んでいます(自己反省を学習に組み込む系統など)。発想として、エージェント設計と強化学習は地続きだと押さえておくと見通しが良くなります。
⚠️ よくある誤解・落とし穴・要最新確認(最重要)
この節がこのノートで一番大事です。エージェント領域は機械学習で最も急速に動いており、安全性・信頼性の面で未解決問題が多いからです。
- 「LLM が自分でツールを実行している」は誤り。 LLM は呼び出しを提案するだけで、実行と結果の差し戻しは外部プログラムの責任です。何を実行可能にするか(権限)は人間の設計判断です。
- 信頼性が未解決。 LLM はいつ誤るかを事前に予測できません。基本的な計算や因果の取り違えで失敗することがあり、現行のどの手法でも失敗を完全には消せていません。詳しくは 評価・ハルシネーション・安全性。
- 自律性そのものがリスク。 人間の介入なしに外界へ作用するため、失敗が直接の被害につながり得ます。2025〜2026年には、ゴールの乗っ取り・ツールの悪用・権限の濫用・記憶の汚染(memory poisoning)・連鎖故障・暴走エージェントといった、エージェント固有のリスク類型が整理され始めました(具体の枠組み名・内容は⚠️要最新確認)。
- オートメーション・バイアス。 エージェントの出力を十分に吟味せず信頼してしまう傾向が指摘されています。重要な判断には人間の確認(human-in-the-loop)を挟むのが原則です。
- コストとループ暴走。 ステップごとに LLM を呼ぶため、回数がかさむと計算コスト・遅延が膨らみます。終了条件や最大ステップ数を必ず設けないと、無限ループや無駄な道具叩きに陥ります。
- 評価ギャップ。 事前テストの性能が、実運用での有用性やリスクを正しく予測しない、という指摘があります。ベンチマーク上の高スコアを鵜呑みにしないこと。
- だから原理で覚える。 個々のフレームワーク・プロトコル・API・モデルの「いま流行りの作法」は確実に古びます。本ノートで身につけるべき不変項は次の3つです:(1) ツール使用=構造化出力で呼び、外部で実行し、観測を文脈に戻す、(2) エージェント=それを推論と行動のループにしたもの、(3) 信頼性・安全・コストは未解決で人間の監督が要る。
まとめ
ツール使用は「LLM を推論レイヤーに据え、苦手な計算・最新情報・外界作用を外部ツールに分業させる」発想で、構造化出力で呼び・外部で実行し・観測を文脈に戻すのが骨格です。これをループにしたのがエージェントで、ReAct(考える→行動する→観察する)が基本形。計画・自己反省・メモリで複雑なタスクを多段で進めます。ただし標準が定まらず、信頼性・暴走・コストが未解決の最前線領域なので、具体は常に要最新確認し、原理と人間の監督を軸に据えてください。