AI エージェントとは? Agents (Chip Huyen)
前書き
本記事では、Chip Huyen 氏の『Agents』 (原文) の和訳+解説を掲載します。
エージェント(Agents)
2025年1月7日 • Chip Huyen
知能を持つエージェントは、多くの人にとってAIの最終目標と考えられています。スチュアート・ラッセルとピーター・ノーヴィグの有名な本 Artificial Intelligence: A Modern Approach(プリンティスホール、1995年)では、AI研究の分野を「合理的なエージェントを研究・設計すること」と定義しています。
最近の基盤モデル(ファウンデーションモデル)は、これまで不可能だったエージェント技術を実現する扉を開きました。これによって、ついに自律的で賢いエージェントを作り、私たちのアシスタントや同僚、コーチとして活用できるようになったのです。たとえば、ウェブサイトの作成、データ収集、旅行計画、市場調査、顧客アカウントの管理、データ入力の自動化、面接準備、候補者の面接、取引交渉などを手伝ってくれます。その可能性は無限大で、経済的な価値も非常に大きいと考えられています。
このセクションでは、まずエージェントとは何かを説明し、次にその能力を決めるツールと計画について紹介します。また、新しい技術には新しい問題もつきものです。最後に、エージェントの失敗を見つけるための評価方法についても解説します。
本記事は AI Engineering (2025) の「エージェント」セクションをもとに、一つの記事として読めるように少し編集しています。
補足
AIエージェントはまだ発展中の分野で、開発や評価のための明確な理論は確立されていません。このセクションでは、既存の研究をもとにベストな枠組みを作ることを目指していますが、今後の技術の進歩に合わせて変わっていく可能性があります。他のセクションと比べると、少し実験的な内容になっています。初期の読者から貴重なフィードバックをもらっているので、本記事の読者からの意見も楽しみにしています。
この本の発売直前に、Anthropicが効果的なエージェントの構築という記事(2024年12月)を発表しました。Anthropicの記事と本セクションは基本的に同じ考え方ですが、使っている用語が少し違います。また、Anthropicの記事は個別のパターンに焦点を当てていますが、私の記事では「なぜ、どのように機能するのか」に重点を置いています。さらに、計画・ツールの選び方・失敗への対処について、より詳しく掘り下げています。
背景情報が多めなので、「細かすぎるな」と感じたら、適当に読み飛ばして大丈夫です!
エージェントの概要(Agent Overview)
「エージェント」という言葉は、さまざまな工学分野で使われています。例えば、ソフトウェアエージェント、知能エージェント、ユーザーエージェント、会話型エージェント、強化学習エージェントなどがあります。では、エージェントとは具体的に何なのでしょうか?
エージェントとは、環境を認識し、その環境に対して行動できるもののことです。
スチュアート・ラッセルとピーター・ノーヴィグの Artificial Intelligence: A Modern Approach(1995年)では、「エージェントとは、センサーを通じて環境を認識し、アクチュエーターを通じて環境に対して行動を起こすもの」と定義されています。
つまり、エージェントはどの環境で動作するかとどんな行動ができるかによって特徴づけられます。
エージェントの環境とは?
エージェントが動作する環境は、そのユースケースによって決まります。
- ゲームをプレイするエージェント → 環境はそのゲーム(例:Minecraft、囲碁、Dota)
- インターネット上の文書を収集するエージェント → 環境はインターネット
- 自動運転車のエージェント → 環境は道路システムやその周辺
エージェントの行動(アクション)とは?
エージェントができる行動は、利用できるツールによって拡張されます。
例えば、私たちが日常的に使う生成AIの多くは、ツールを持つエージェントです。
- ChatGPT → Web検索、Pythonコードの実行、画像生成ができる
- RAG(検索拡張生成)システム → テキスト検索、画像検索、SQL実行ができる
環境とツールの関係
エージェントがどんなツールを使えるかは、その環境によって決まります。
例えば:
- 環境が「チェス」なら、可能な行動はチェスの合法手のみ
- エージェントのツールが「水泳」しかできないロボットなら、その環境は水中に限定される
エージェントの例:SWE-agent
2024年にYangらが開発した SWE-agent(GPT-4を基盤にしたエージェント)を例に見てみましょう。
- 環境 → コンピュータ(ターミナルとファイルシステム)
- 行動(ツール) → リポジトリのナビゲート、ファイル検索、ファイル閲覧、コード編集
SWE-agentは、ソフトウェア開発を支援するコーディングエージェントです。
AIエージェントのタスクの流れ
AIエージェントは、ユーザーが与えたタスクを達成することを目的としています。
AIがタスクを処理し、どのように進めるか計画を立て、完了したかどうかを判断します。
例えば、RAGシステム(検索拡張生成)を使ったデータ分析エージェントの例を考えます。
タスク:「Fruity Fedoraの今後3か月の売上予測を作成せよ」
このエージェントは以下のような流れで動作します:
-
タスクの計画
- 「売上を予測するには、過去5年分の売上データが必要だ」と判断
- 途中経過として、推論の結果を出力する
-
SQLクエリを生成して、売上データを取得
- SQL生成ツールを使い、適切なクエリを作成
- クエリを実行し、データを取得
-
データを分析し、次のステップを判断
- 取得した売上データを分析し、「データが不十分」と判断
- 過去のマーケティングキャンペーンの情報も必要だと結論付ける
-
追加データを取得
- SQLクエリを生成し、マーケティングデータを取得
- データを統合し、売上予測を作成
-
タスクの完了を判断
- 予測結果が十分な情報を含んでいるかを評価
- タスクが完了したと判断し、ユーザーに結果を提示
なぜエージェントには強力なモデルが必要なのか?
エージェントが非エージェント型のAI(単発のタスクを実行するAI)よりも強力なモデルを必要とする理由は2つあります。
-
複数のステップを踏むため、ミスが積み重なる
- エージェントは1回で終わる単純なタスクではなく、複数のステップを踏みます。
- もし1ステップの精度が95%だったとしても、10ステップ後には精度が60%、100ステップ後には0.6%になってしまいます。
-
影響が大きい(リスクが高い)
- ツールを使えるエージェントは、より影響力のある作業を行えます。
- しかし、その分、エラーが発生すると深刻な影響を及ぼす可能性があります。
コストと時間の問題
- タスクのステップが多いと、処理に時間もコストもかかる
- 一部の人は「エージェントはAPIクレジットを消費するだけ」と批判する
- しかし、エージェントが完全自律化できれば、人間の作業時間を大幅に削減し、コスト以上の価値を生み出せる
エージェントの成功は何で決まるのか?
エージェントが環境内で成功するかどうかは、利用できるツールとAIの計画能力にかかっています。
次に、エージェントが使うツールの種類について詳しく見ていきます。その後、プランニングについても分析します。
ツール(Tools)
エージェントは外部ツールなしでも機能しますが、ツールがなければ能力は大幅に制限されてしまいます。
例えば、大規模言語モデル(LLM)はテキスト生成、画像生成モデルは画像作成が単独でできますが、それ以上のことはできません。しかし、外部ツールを組み合わせることで、エージェントの可能性は大きく広がります。
ツールは、エージェントが**環境を認識する(知覚)**のにも、**環境に働きかける(行動)**のにも役立ちます。
- 環境を知覚するためのアクション → 読み取り専用の「リードアクション」
- 環境に影響を与えるアクション → 変更可能な「ライトアクション」
エージェントのツールインベントリとは?
エージェントが使えるツールのセットを「ツールインベントリ」と呼びます。
エージェントがどんなことをできるかは、ツールインベントリの中身によって決まります。
- ツールが多いほど、エージェントの能力は増す
- ただし、ツールが多すぎると、適切に使いこなすのが難しくなる
そのため、どのツールを、どれくらい与えるのが最適かを慎重に考えることが重要です。この試行錯誤については、後の**「ツール選択」**のセクションで詳しく説明します。
エージェントのツールの種類
エージェントが使えるツールは、環境によって異なります。大きく分けて次の3つのカテゴリがあります。
- 知識の補強(Knowledge Augmentation) → モデルに不足している情報を補う
- 能力の拡張(Capability Extension) → モデル単独ではできないことを可能にする
- 環境に働きかけるツール(Action on Environment) → 直接操作できる機能
知識の補強(Knowledge Augmentation)
AIモデルが良い回答をするには**適切なコンテキスト(背景情報)**が必要です。
このカテゴリーのツールは、エージェントの知識を補強するのに役立ちます。
すでに紹介したツールの例:
- テキスト検索ツール(Text Retriever)
- 画像検索ツール(Image Retriever)
- SQL実行ツール(SQL Executor)
その他のツールの例:
- 社内検索ツール(内部の専門家を探す)
- 在庫API(商品の在庫状況を取得する)
- Slackメッセージ検索(過去のチャット履歴を取得する)
- メールリーダー(特定の内容を探して抽出する)
これらのツールは、企業内の情報をエージェントに提供するために使われることが多いですが、インターネットを活用して外部情報を取得することも可能です。
WebブラウジングとインターネットAPI
インターネットを活用するツールの代表例が「Webブラウジング機能」です。
これは、AIモデルの**情報の鮮度(アップデート頻度)**を保つのに重要な役割を果たします。
モデルの問題点として、学習データが古くなる(stale data)と、最新の情報が反映されなくなることが挙げられます。
例えば、AIの学習データが1週間前で止まっている場合、それ以降の情報は知らないため、最新ニュースや天気、株価、フライトの状況などを答えられません。
この問題を解決するために、Webブラウジング機能が導入されました。
ChatGPTでも、早い段階からWeb検索機能が追加されましたね。
Webブラウジングの例
- Web検索API(Google Search API、Bing Search API)
- ニュースAPI(NewsAPI、Google News API)
- GitHub API(リポジトリの検索やコード解析)
- SNS API(Twitter/X API、Reddit API)
Webブラウジングのメリット
✅ 最新の情報を取得できる(データの陳腐化を防ぐ)
✅ 誤情報(ハルシネーション)を減らす(外部情報を根拠として利用できる)
Webブラウジングのリスク
⚠ インターネットには誤情報が多い(信頼できるAPIを慎重に選ぶ必要がある)
⚠ 悪意のあるサイトやフィッシングサイトにアクセスする危険
能力の拡張(Capability Extension)
AIモデルには本質的な限界があります。そのため、こうした限界を補うツールを活用することで、エージェントのパフォーマンスを大幅に向上させることができます。
例えば、AIモデルは数学が苦手なことで知られています。
「199,999 ÷ 292 はいくつ?」と質問すると、モデルは間違った答えを返す可能性が高いでしょう。しかし、電卓ツールを使えば、この計算は瞬時に解決できます。AIモデルに計算力を持たせるために膨大なデータを使って訓練するよりも、シンプルにツールを使わせるほうがはるかに効率的です。
他にも、簡単にAIモデルの能力を向上させるツールとして、以下のようなものがあります。
- カレンダー(日付の計算やスケジュール管理)
- タイムゾーン変換ツール(異なる国の時間変換)
- 単位変換ツール(ポンド⇔キログラム、摂氏⇔華氏 など)
- 翻訳ツール(対応できない言語の翻訳)
より高度なツール:コードインタープリター
コードインタープリターは、さらに強力なツールの一例です。
AIに「プログラムコードの理解力」を持たせるのは難しいですが、コードを実行できる環境を与えれば、問題解決能力を大幅に強化できます。
コードインタープリターを活用することで、エージェントは次のような役割を果たせます。
- コーディングアシスタント(コードの作成・修正・実行)
- データ分析アシスタント(データ処理や可視化)
- 研究アシスタント(実験用のコードを書き、結果を報告)
ただし、自動コード実行にはセキュリティリスクが伴うため、慎重な設計が必要です。
例えば、コードインジェクション攻撃(悪意のあるコードの実行)を防ぐ対策が求められます。この点については、**第5章「防御的プロンプトエンジニアリング」**で詳しく解説されています。
ツールでAIをマルチモーダル化する
本来テキスト生成しかできないモデルでも、適切なツールを追加すればマルチモーダル(複数のデータ形式を扱える)になります。
例えば:
-
ChatGPT が画像生成できるのは、DALL-E をツールとして活用しているから
- テキストの入力に応じて、テキストを生成するか、画像を生成するか、または両方を組み合わせるかをAIプランナーが判断する
他にも:
- コードインタープリター → グラフやチャートを作成
- LaTeX コンパイラー → 数式を美しくレンダリング
- Webレンダラー → HTMLコードを解析し、ウェブページを表示
逆に、テキスト入力しか処理できないモデルでも、ツールを追加すれば画像や音声を扱えるようになります。
- 画像キャプションツール → 画像をテキストに変換(視覚情報を理解)
- 音声書き起こしツール → 音声をテキスト化(音声データを分析)
- OCR(光学文字認識) → PDFなどの画像からテキストを抽出
ツールの活用は、プロンプトやファインチューニングよりも強力
ツールを活用すれば、プロンプト設計(Prompt Engineering)やモデルのファインチューニングよりも効果的に性能を向上させられます。
例えば、**Chameleon(Luら, 2023)**の研究では、GPT-4 に13種類のツールを組み合わせることで、GPT-4単独よりも優れた成果を達成しました。
このエージェントが使用したツールの例:
✅ 知識検索(Knowledge Retrieval)
✅ クエリ生成(Query Generator)
✅ 画像キャプション(Image Captioner)
✅ テキスト検出(Text Detector)
✅ Bing検索(Web Search)
実際の成果:
- ScienceQA(科学分野の質問応答ベンチマーク) → 既存のベストスコアを +11.37% 改善
- TabMWP(表データを使った数学問題) → 精度を +17% 改善
この結果からも分かるように、ツールを適切に活用すれば、AIの能力を大幅に強化できることが証明されています。
書き込みアクション(Write Actions)
これまで、モデルがデータソースを読み取るための「リードアクション(Read-Only Actions)」について説明してきました。しかし、ツールには**データソースを変更する「書き込みアクション(Write Actions)」**を実行できるものもあります。
例えば:
-
SQL実行ツール(SQL Executor)
- データテーブルを取得(読み取り)できるだけでなく、変更や削除(書き込み)も可能
-
メールAPI
- メールを読む(読み取り)だけでなく、返信する(書き込み)ことも可能
-
銀行API
- 残高を取得(読み取り)できるだけでなく、送金(書き込み)も可能
書き込みアクションができると、システムの自動化範囲が大幅に広がります。
例えば、顧客対応のワークフロー全体を自動化できます。
- 潜在的な顧客をリサーチする
- 連絡先を取得する
- メールの下書きを作成する
- 最初のメールを送信する
- 返信を読み取る
- フォローアップを送る
- 注文内容を抽出する
- データベースを更新する
しかし、AIに「自律的に私たちの生活を変える力」を持たせることには、危険な側面もあります。
例えば、新人のインターンに本番環境のデータベースを削除する権限を与えるべきではないのと同じように、信頼できないAIに銀行送金を許可するべきではありません。
したがって、システムの能力やセキュリティ対策への信頼性が非常に重要になります。
また、悪意のある攻撃者がAIを操り、危険なアクションを実行させる可能性もあるため、適切な防御策が求められます。
エージェントとセキュリティ
自律型AIエージェントについて話すと、よく「自動運転車」の話題が出てきます。
「もし誰かがハッキングして車を乗っ取ったらどうする?」
自動運転車のリスクは、物理的な存在があるため直感的に理解しやすいですが、AIシステムは物理世界に関与せずとも大きな被害を引き起こす可能性があります。
例えば:
- 株式市場を操作する
- 著作権を侵害する
- プライバシーを侵害する
- バイアスを強化する
- 誤情報やプロパガンダを拡散する
これらの問題については、**第5章「防御的プロンプトエンジニアリング」**で詳しく説明されています。
これらは確かに重要な懸念事項ですが、それを理由にAIシステムが現実世界で行動する能力を完全に排除するべきではないと考えています。
宇宙に人を運ぶ機械を信頼できるなら、いつかはAIエージェントにも十分なセキュリティ対策が施され、信頼できる日が来るはずです。
それに、人間も失敗します。
正直なところ、見知らぬ人に乗せてもらうより、自動運転車のほうが安全だと私は思います。
ツールの力と今後の展望
適切なツールを使うことで、人間の生産性は飛躍的に向上します。
Excelなしでビジネスをすることを想像できますか?クレーンなしで高層ビルを建てることは?
それと同じように、ツールを活用することでAIモデルの能力は大きく広がります。
現在、多くのAIモデルがFunction Callingという形でツールを利用できるようになっています。
今後、さまざまなツールと連携する「関数呼び出し」が、ほとんどのAIモデルで標準機能になっていくと考えられます。
計画(Planning)
基盤モデルエージェントの中心にあるのは、ユーザーから与えられたタスクを解決するためのモデルです。タスクは「目標」と「制約」によって定義されます。 例えば、「サンフランシスコからインドへの2週間の旅行を、5,000ドルの予算で計画する」というタスクがあるとします。この場合、**目標は「2週間の旅行」**であり、**制約は「予算5,000ドル」**です。
複雑なタスクには計画が必要です。計画プロセスの出力は「計画(プラン)」であり、タスクを達成するためのステップを示すロードマップとなります。 効果的な計画を立てるには、モデルがタスクを理解し、達成するための複数の方法を検討し、最も有望な方法を選択することが求められます。
計画を立てたことがある人なら誰でも分かるように、計画は簡単ではありません。計画は計算上の重要な課題であり、膨大な研究がなされています。本記事ではその表面をなぞる程度にとどめますが、基本的な考え方を紹介します。
計画の概要(Planning Overview)
タスクが与えられると、それを解決する方法は数多くあります。しかし、そのすべてが成功するとは限りません。また、成功する方法の中にも、より効率的なものと非効率なものがあります。
例えば、次のようなクエリを考えます。
「売上ゼロの企業のうち、少なくとも10億ドルを調達した企業はいくつあるか?」
このクエリに対する解決策として、次の2つの方法が考えられます。
- すべての売上ゼロの企業を探し、その中から資金調達額が10億ドル以上のものをフィルタリングする。
- 資金調達額が10億ドル以上の企業を探し、その中から売上ゼロのものをフィルタリングする。
2番目の方法のほうが効率的です。なぜなら、売上ゼロの企業は非常に多いのに対し、10億ドル以上の資金調達をした企業は比較的少ないため、先に後者を絞り込む方が計算コストを削減できるからです。したがって、賢いエージェントは2番目の方法を選択するべきです。
計画と実行を分離するべき理由
計画と実行を同じプロンプト内で行うことも可能です。
例えば、「一歩ずつ考える(Chain-of-Thought)」 というプロンプトを使えば、タスクを段階的に処理できます。しかし、問題もあります。
例えば、AIが1,000ステップの計画を立てたが、それが目標を達成しないとしたらどうでしょう?
監視なしにエージェントが何時間もAPIを呼び出し続け、無駄なコストを発生させてしまう可能性があります。
このような無駄な処理を防ぐために、計画と実行は分離するべきです。
- まずエージェントに計画を生成させる。
- その計画が正しいか検証する。
- 検証に合格した計画だけを実行する。
計画の検証方法
計画を検証するための方法はいくつかあります。
-
ヒューリスティック(経験則)を用いた検証
- 無効なアクションを含む計画を排除する。
- 例:「Google検索が必要な計画なのに、エージェントがGoogle検索ツールを持っていない」→ この計画は無効。
- 例:「ステップ数がXを超える計画は無効にする。」
-
AIを使った検証
- モデルに計画を評価させ、「合理的かどうか」を判断させる。
- 計画が不十分なら、新しい計画を生成する。
計画が適切なら実行し、不適切なら再計画を行います。
外部ツールが必要な場合、エージェントは**関数呼び出し(Function Calling)**を使ってツールを実行し、その結果を評価します。
エージェントの3つの主要コンポーネント
このプロセスを踏むことで、エージェントには以下の3つの主要なコンポーネントが存在することになります。
- 計画を生成するエージェント
- 計画を検証するエージェント
- 計画を実行するエージェント
それぞれが独立して機能するため、これは**マルチエージェントシステム(Multi-Agent System)**と考えることもできます。
ほとんどのエージェントは複雑なワークフローを扱うため、実際には複数のエージェントが連携して動作するのが一般的です。
さらに、複数の計画を並列に生成し、一番良いものを選ぶことで処理速度を向上させることもできます。
ただし、並列処理には追加のコストがかかるため、処理速度とコストのトレードオフを考慮する必要があります。
意図の理解と適切なツールの選択
エージェントが適切な計画を立てるには、タスクの意図(Intent)を理解することが重要です。
意図を分類するために、**意図分類器(Intent Classifier)**を使用することがあります。
例えば:
- 問い合わせが「請求」に関するものであれば → 最近の支払い履歴を取得するツールが必要
- 問い合わせが「パスワードリセット」に関するものであれば → ドキュメント検索ツールが必要
また、エージェントが対応できない問い合わせ(IRRELEVANT)を判別し、丁寧に拒否することも重要です。
無理に解決しようとせず、不可能な問題には対応しないようにすることで、計算リソースの無駄遣いを防ぐことができます。
計画の自動化と人間の関与
これまでの説明では、エージェントがすべて自動で計画を作成・検証・実行する前提でした。
しかし、実際には人間が介入することも可能です。
- 人間の専門家が計画の作成を手助けする。
- リスクの高い操作(データベースの更新やコードのマージなど)は、人間が承認する。
- どのアクションまで自動化するかを明確に定義する。
基盤モデル(Foundation Models)をプランナーとして使う
基盤モデル(Foundation Models)がどの程度うまく計画を立てられるのかは、まだはっきりしていません。
少なくとも、自己回帰型(autoregressive)言語モデルを基盤とする場合、計画は苦手だと考える研究者は多いです。
MetaのチーフAIサイエンティストである**ヤン・ルカン(Yann LeCun)**は、自己回帰型LLM(大規模言語モデル)は計画を立てられないと明言しています(2023年)。
LLMが計画を苦手とするという経験的な証拠は数多くあります。
しかし、それは**「LLMの使い方が間違っているから」なのか、それとも「そもそもLLMが計画に向かないから」なのか**は、まだはっきりしていません。
計画とは「探索問題(Search Problem)」である
**計画の本質は「探索問題(Search Problem)」**です。
つまり、
- 異なる経路(行動パターン)を探索する
- 各経路の結果(報酬)を予測する
-
最も良い結果をもたらす経路を選択する
というステップを繰り返します。
しかし、場合によってはどの経路を選んでも目標にたどり着けないこともあります。
探索では**「バックトラッキング(Backtracking)」**が必要になることが多いです。
例えば、ある時点で次の2つの選択肢があったとします。
- アクションAを選択する
- アクションBを選択する
アクションAを選んだ結果、良い状態に進めなかった場合、一つ前の状態に戻ってアクションBを試す必要があります。
自己回帰型モデルはバックトラッキングができない?
自己回帰型モデルは、基本的に「一方向(未来に向かって)」しかテキストを生成できません。
そのため、バックトラッキング(途中でやり直すこと)ができないので、計画には向かないという意見があります。
しかし、これは必ずしも正しくありません。
- アクションAを実行し、その経路が良くないと判断した場合、モデルはアクションBを使った新しい計画を作成し直すことができる。
- そもそも最初から別の経路を試すことも可能。
つまり、直接的なバックトラッキングはできなくても、結果を見ながら修正することは可能です。
LLMが計画を苦手とする理由:ツール不足の可能性
LLMが計画を苦手とするもう一つの理由は、計画に必要なツールが与えられていないからかもしれません。
計画をするためには、どの行動が可能かだけでなく、その行動の結果がどうなるかを知る必要があります。
例えば、登山をしているとします。
- 取れる行動:右へ進む、左へ進む、後ろを向く、前へ進む
- しかし、「右へ進むと崖から落ちる」ことを知っていれば、そもそも右へ進もうとは思わない
つまり、計画をするには
- ある行動を取ると「どの状態に移るのか」を理解する
- その状態が良いのか悪いのかを判断する
という能力が必要です。
「Chain-of-Thought(CoT)」のような、単なるステップ生成では不十分かもしれません。
世界モデルを用いた計画
最近の研究**「Reasoning with Language Model is Planning with World Model(Haoら, 2023)」**では、LLMは世界に関する膨大な情報を持っているため、各行動の結果を予測できると主張しています。
この予測を活用すれば、より整合性のある計画を立てられる可能性があります。
また、仮にAIが単独で計画を立てられないとしても、
- 探索ツール(Search Tool)
-
状態追跡システム(State Tracking System)
を組み合わせることで、LLMをプランナーの一部として活用できる可能性があります。
基盤モデルは計画を立てられるのか?(Foundation Models as Planners)
基盤モデル(Foundation Model)がどれほど計画を立てられるのかは、現在も議論が続いている問題です。
多くの研究者は、少なくとも自己回帰型(Autoregressive)言語モデルを基盤とするモデルは計画ができないと考えています。
Metaの最高AI科学者である**ヤン・ルカン(Yann LeCun)は、2023年に「自己回帰型LLM(大規模言語モデル)は計画を立てることができない」**と明言しています。
LLMは本当に計画が苦手なのか?
確かに、多くの経験的な証拠からLLMは計画が苦手だとされています。
しかし、それが (1) LLMの使い方が間違っているのか? それとも (2) LLMが本質的に計画を立てられないのか? はまだはっきりしていません。
計画(Planning)とは、本質的に「探索問題(Search Problem)」です。
- さまざまなルートを試し、目標への到達可能性を予測し、最も良い結果を出せるルートを選ぶ。
- しかし、どのルートも目標にたどり着けないこともある。
探索には「バックトラッキング(Backtracking:後戻り)」が必要になることが多いです。
例えば、ある状態で「アクションA」と「アクションB」の2つの選択肢があるとします。
- アクションAを選んだ結果、良い状態に進めなかった場合、前の状態に戻り、アクションBを試す必要があります。
自己回帰型モデルではバックトラッキングができない?
ある人々は、自己回帰型モデルは「前向きのアクション」しか生成できず、後戻りして別のアクションを試せないと主張しています。
このため、「自己回帰型モデルは計画を立てるのに向いていない」という結論を出しています。
しかし、これは必ずしも正しくありません。
- 一度アクションAのルートを試した後に、「このルートは不適切だ」と判断すれば、アクションBのルートに切り替えることは可能です。
- また、モデルは最初からやり直し、別のルートを選び直すこともできます。
LLMが計画を苦手とするのは、ツールが不足しているから?
もう一つの可能性として、LLMは「計画に必要なツール」が与えられていないために計画が苦手なのではないか? という考え方があります。
計画を立てるためには、「利用可能なアクション」だけでなく「各アクションの結果」も知らなければなりません。
山登りの例
- ある人が山を登ろうとしている。
- 取れる行動は 「右へ行く」「左へ行く」「振り返る」「まっすぐ進む」の4つ。
- しかし、もし「右に進むと崖から落ちる」と分かっていれば、普通はその行動を選択肢に入れません。
技術的に言えば、「アクションAが状態Sを状態S'に変化させる」ことを知ることが、計画には必要なのです。
したがって、「連鎖思考プロンプト(Chain-of-Thought Prompting)」のように、単にアクションの列を生成するだけでは不十分である可能性があります。
LLMは世界モデルを活用して計画を立てられるか?
Haoら(2023)の論文 「Reasoning with Language Model is Planning with World Model」 では、
LLMは世界に関する膨大な情報を持っており、アクションの結果を予測する能力があると主張されています。
この論文では、
LLMが「アクションの結果予測」を組み込めば、より一貫性のある計画を生成できると述べられています。
また、仮にAI単体では計画が苦手だとしても、探索ツールや状態追跡システムを組み合わせることで、計画能力を補うことが可能かもしれません。
基盤モデル(FM) vs. 強化学習(RL)による計画の違い
エージェントという概念は**強化学習(Reinforcement Learning, RL)**と密接に関連しています。
Wikipediaでは、強化学習を次のように定義しています。
「強化学習とは、知的エージェントが、累積報酬を最大化するために、動的な環境でどのように行動すべきかを研究する分野である。」
FMエージェントとRLエージェントの類似点
- どちらも環境と可能なアクションによって定義される。
- どちらも目標達成のための計画が必要。
FMエージェントとRLエージェントの違い
項目 | FMエージェント(基盤モデルエージェント) | RLエージェント(強化学習エージェント) |
---|---|---|
プランナーの学習方法 | 基盤モデルがプランナーとして機能 | 強化学習アルゴリズムで学習 |
学習コスト | プロンプト設計や微調整で改善可能(低コスト) | 学習に膨大な時間と計算リソースが必要 |
改良の柔軟性 | RLを取り入れて性能向上が可能 | 基盤モデルを組み込んで応用が可能 |
将来的には、FMエージェントとRLエージェントは統合されていく可能性が高いと考えられます。
例えば、FMエージェントがRLアルゴリズムを取り入れることで、より高度な計画能力を持つようになるかもしれません。
計画の生成(Plan Generation)
モデルを計画生成エージェントに変える最もシンプルな方法は、プロンプトエンジニアリングを活用することです。
例えば、Kitty Vogueの顧客が製品について学ぶのを助けるエージェントを作成したいとします。このエージェントには、以下の3つの外部ツールを利用できるようにします。
- 価格で製品を検索する(retrieve products by price)
- トップ製品を取得する(retrieve top products)
- 製品情報を取得する(retrieve product information)
以下に、計画生成のためのプロンプトの例を示します。
※ これはあくまで説明用のものであり、実際の運用ではより複雑なプロンプトが必要になるでしょう。
システムプロンプト(SYSTEM PROMPT)
「タスクを解決するための計画を提案してください。あなたは以下の5つのアクションを利用できます。」
-
get_today_date()
(今日の日付を取得する) -
fetch_top_products(start_date, end_date, num_products)
(指定期間のトップ製品を取得する) -
fetch_product_info(product_name)
(製品情報を取得する) -
generate_query(task_history, tool_output)
(タスク履歴とツール出力を元にクエリを生成する) -
generate_response(query)
(クエリを元に回答を生成する)
計画は、有効なアクションのシーケンスである必要があります。
例(Examples)
Task: "Tell me about Fruity Fedora"
Plan: [fetch_product_info, generate_query, generate_response]
Task: "What was the best-selling product last week?"
Plan: [fetch_top_products, generate_query, generate_response]
Task: {USER INPUT}
Plan:
この例についてのポイント
-
計画のフォーマット(Plan Format)
- ここで使われている計画の形式は、「関数のリスト」として記述し、エージェントがパラメータを推論する方法です。
- しかし、これはエージェントの制御フローを構造化する方法のひとつに過ぎません。
-
generate_query
関数の役割-
generate_query()
は、タスクの履歴と最新のツール出力を入力として受け取り、レスポンス生成のためのクエリを作成します。 - ツールの出力は各ステップごとにタスクの履歴に追加されます。
-
計画の例
ユーザーが 「先週のベストセラー商品の価格は?」 と尋ねた場合、モデルが生成する計画の例は以下のようになります。
get_today_date()
fetch_top_products()
fetch_product_info()
generate_query()
generate_response()
関数のパラメータはどう決まるのか?
「関数のパラメータはどう指定するのか?」 という疑問が出るかもしれません。
実際には、パラメータの値は前のツール出力から推測されることが多いため、事前に完全な形で予測するのは難しい場合があります。
例えば、get_today_date()
の出力が "2030-09-13"
だった場合、
エージェントは次のようなパラメータを推論できます。
fetch_top_products(
start_date="2030-09-07",
end_date="2030-09-13",
num_products=1
)
ただし、情報が不十分で正確なパラメータを決定できない場合もあります。
例えば、「ベストセラー商品の平均価格は?」 という質問を考えてみましょう。
この場合、以下の2つの疑問が生じます。
- 「ベストセラー商品は何個見るべきか?」
- 「先週・先月・過去全期間のどれを対象にするのか?」
こうした情報が明確でない場合、モデルは**推測(guessing)**するしかありません。
しかし、推測は間違う可能性があるため、計画の品質に影響を与えます。
ハルシネーション(Hallucination)のリスク
アクションのシーケンス(手順)と、それに対応するパラメータはAIモデルが生成します。
そのため、「ハルシネーション(誤った情報の生成)」が発生する可能性があります。
ハルシネーションによる問題点:
- 無効な関数を呼び出す(エージェントが実際には使えないツールを呼び出す)
-
正しい関数でも間違ったパラメータを渡す(
fetch_top_products(num_products=10000)
のように、異常な値を設定する)
これを防ぐために、一般的なモデル改善手法を活用して、計画の精度を向上させることができます。
計画を改善するためのヒント
-
より良いシステムプロンプトを書く
- 具体的な例を増やし、モデルに計画の正しいフォーマットを学習させる。
-
ツールとパラメータの説明を明確にする
- 各ツールの役割やパラメータの意味をより詳細に記述することで、モデルの理解を助ける。
-
関数をシンプルにする
- 1つの複雑な関数を、2つの単純な関数に分けるなど、モデルが扱いやすいようにリファクタリングする。
-
より強力なモデルを使用する
- 一般的に、強力なモデルほど計画能力が高い。
-
計画生成専用のモデルをファインチューニングする
- 計画生成に特化した学習を行うことで、より正確な計画を作成できるようにする。
関数呼び出し(Function Calling)
多くのモデルプロバイダーは、ツールを利用できる機能を提供しており、これによってモデルがエージェントとして機能できるようになります。
ツールとは**関数(Function)のことであり、ツールを呼び出すことは一般に「関数呼び出し(Function Calling)」**と呼ばれます。
モデルAPIによって関数呼び出しの仕組みは異なりますが、一般的な流れは以下の通りです。
-
ツールインベントリの作成
- モデルが使用できるツール(関数)をすべて宣言する。
- 各ツールにはエントリポイント(関数名)、パラメータ、**ドキュメント(関数の説明と必要なパラメータ)**を設定する。
-
エージェントが使用できるツールを指定する
- クエリごとに利用可能なツールをリストとして指定できる。
- 多くのAPIでは、ツールの使用を以下のように制御できる。
-
required
(必須):モデルは最低1つのツールを使用しなければならない。 -
none
(禁止):モデルはツールを使用してはならない。 -
auto
(自動):モデルがどのツールを使用するかを決定する。
-
関数呼び出しの仕組みを説明するために、図6-10では、2つのシンプルなツールを利用するモデルの擬似コードが示されている。
なお、特定のAPIを使用する場合は、そのAPIの公式ドキュメントを参照する必要がある。
関数呼び出しの例
図6-10のエージェントは、クエリに基づいて使用するツールとそのパラメータを自動生成する。
一部の関数呼び出しAPIでは、無効な関数の生成を防ぐ仕組みを備えているが、正しいパラメータ値の保証はできない。
例:「40ポンドは何キログラム?」というクエリの場合
エージェントは lbs_to_kg_tool
というツールを使用するべきだと判断し、
パラメータとして 40
を渡すべきだと推論する。
このとき、エージェントのレスポンスは以下のようになる。
response = ModelResponse(
finish_reason='tool_calls',
message=chat.Message(
content=None,
role='assistant',
tool_calls=[
ToolCall(
function=Function(
arguments='{"lbs":40}',
name='lbs_to_kg'),
type='function')
])
)
このレスポンスをもとに、lbs_to_kg(lbs=40)
を呼び出し、その出力をユーザーへの最終的な回答に利用できる。
注意点:関数呼び出しのパラメータを確認すること
エージェントを運用する際は、関数呼び出しで使用されるパラメータ値を必ず記録し、正しいかどうか検証するべきである。
間違ったパラメータが使用されると、誤った結果を返してしまう可能性があるため、特に慎重に扱う必要がある。
計画の粒度(Planning Granularity)
計画とは、タスクを達成するために必要なステップを示すロードマップである。
しかし、ロードマップの詳細レベル(粒度)には違いがある。
- 1年単位の計画 → 粗い計画(四半期ごとの目標設定など)
- 1か月単位の計画 → より詳細な計画
- 1週間単位の計画 → 最も細かい計画
計画と実行にはトレードオフがある。
- 詳細な計画 → 作成は難しいが、実行は容易(手順が明確だから)。
- 大まかな計画 → 作成は簡単だが、実行は難しい(細かい指示が不足するから)。
このトレードオフを回避する方法のひとつが 「階層的な計画(Hierarchical Planning)」 である。
例えば:
- まず、四半期ごとの大まかな計画を立てる。
- 次に、それを元に1か月単位の詳細な計画を作成する。
このように 「上位レベルの計画」→「下位レベルの計画」 という形で進めることで、計画の精度と実行しやすさのバランスを取ることができる。
関数呼び出しと計画の適応性
これまでの例では、生成された計画は**関数名をそのまま使用する「詳細な計画」**だった。
しかし、この方法には問題がある。
ツールインベントリ(利用可能な関数のリスト)は時間とともに変化する可能性がある。
例えば、get_time()
という関数が get_current_time()
に変更された場合、すべてのプロンプトや事例を更新しなければならなくなる。
また、関数名を厳密に指定すると、エージェントを他のツールAPIに適用するのが難しくなる。
この問題を回避するために、計画を「自然言語」で記述する方法がある。
自然言語での計画の例
ユーザーのクエリ:「先週のベストセラー商品の価格を教えて」
詳細な関数ベースの計画(従来の方法)
get_today_date()
fetch_top_products(start_date, end_date, num_products)
fetch_product_info(product_name)
generate_query()
generate_response()
自然言語での計画(適応性の高い方法)
現在の日付を取得する
先週のベストセラー商品を取得する
製品情報を取得する
クエリを生成する
回答を生成する
自然言語を使うメリットと課題
メリット
✅ ツールAPIの変更に強い(関数名が変わっても、計画の意味は変わらない)。
✅ より柔軟な計画が可能(異なるツールセットでも適用しやすい)。
✅ モデルが理解しやすく、ハルシネーションが減る可能性がある。
デメリット
⚠ 自然言語の計画を実行可能なコマンドに変換する「翻訳機」が必要になる。
⚠ Chameleon(Luら, 2023)は、この翻訳機を「プログラム生成器(Program Generator)」と呼んでいる。
⚠ ただし、翻訳は計画よりも単純なタスクであり、精度を高めやすい。
複雑な計画(Complex Plans)
これまでの計画例はすべて**「順次実行(Sequential)」**のものでした。つまり、前のアクションが完了してから次のアクションが実行される形式です。
しかし、アクションの実行順序(制御フロー(Control Flow))にはさまざまな種類があります。順次実行はその一例に過ぎません。他にも以下のような制御フローがあります。
- 順次実行(Sequential)
- 並列実行(Parallel)
- 条件分岐(If statement)
- 繰り返し処理(For loop)
以下では、それぞれの制御フローの特徴を説明します。
1. 順次実行(Sequential)
アクションAが完了した後にアクションBを実行する。
- 理由: タスクBがタスクAに依存しているため。
-
例: SQLクエリを実行する前に、自然言語の入力をSQLに変換する必要がある。
自然言語 → SQLに変換 → SQLクエリを実行
2. 並列実行(Parallel)
タスクAとタスクBを同時に実行する。
-
例: 「100ドル以下のベストセラー商品を見つけてください」というクエリを処理する場合、
- タスクA: 「ベストセラー上位100商品を取得する」
- タスクB: 「各商品の価格を取得する」
- タスクAとタスクBを同時に実行すれば、処理が高速化される。
3. 条件分岐(If statement)
前のステップの出力に応じて、タスクBまたはタスクCを実行する。
-
例: エージェントがNVIDIAの決算報告を確認し、その結果に基づいて株を売却するか購入するかを決定する。
決算報告を取得 →(利益が予想以上なら株を購入 / 予想以下なら株を売却)
- このパターンは、Anthropicのブログでは「ルーティング(Routing)」と呼ばれている。
4. 繰り返し処理(For loop)
特定の条件が満たされるまで、タスクAを繰り返し実行する。
-
例: ランダムな数を生成し、素数が得られるまで繰り返す。
ランダムな数を生成 → それが素数か確認 →(素数でないなら再生成)
エージェントの制御フロー(Agent Control Flow)
図6-11では、さまざまな制御フローの実行順序が視覚的に示されています。
従来のソフトウェアエンジニアリングでは、制御フローの条件は明確に定義されます。
しかし、AIを活用したエージェントでは、AIモデル自体が制御フローを決定するため、
非順次的な(Parallel, If, Forなどを含む)計画を生成し、実行可能なコマンドに変換することがより難しくなります。
ヒント(Tip)
エージェントのフレームワークを評価する際には、どの制御フローに対応しているかを確認することが重要です。
- 例えば、10個のウェブサイトを巡回する必要がある場合、システムはそれを並列実行できるか?
- 並列実行が可能であれば、ユーザーが感じる待ち時間(レイテンシ)を大幅に短縮できる。
振り返りとエラー修正(Reflection and Error Correction)
どれほど優れた計画であっても、成功の可能性を最大化するためには継続的な評価と調整が必要です。
エージェントが動作するために必ずしも振り返り(Reflection)が必要なわけではありませんが、成功するためには不可欠な要素です。
振り返りが役立つタイミング
タスクの進行中には、以下のような場面で振り返りが役立ちます。
-
ユーザーのクエリを受け取った後
- リクエストが実行可能かどうかを評価する。
-
初回の計画生成後
- 作成された計画が合理的かどうかを評価する。
-
各ステップの実行後
- 進行が正しい方向に向かっているかを判断する。
-
計画全体が完了した後
- タスクが成功したかどうかを最終評価する。
振り返りとエラー修正は別の仕組みですが、密接に連携しています。
振り返りによってエラーを発見し、それを修正するプロセスにつながります。
振り返りの実装方法
振り返りはエージェント自身が行う方法と、別のコンポーネントを用いる方法の2種類があります。
- エージェント自身が自己批評プロンプト(Self-Critique Prompts)を用いて行う。
-
評価専用のコンポーネント(スコアラーなど)を用いる。
- 具体的なスコアを出力し、成功率を数値化する。
ReAct(Yao et al., 2022) によって提案された手法では、計画(Planning)と振り返り(Reflection)を交互に行う手法が一般的になっています。
Yaoらは「推論(Reasoning)」という言葉を、計画と振り返りの両方を含む概念として定義しました。
この手法では、エージェントは各ステップで以下の処理を行います。
- 思考(Thought):現在の状況を分析し、何をすべきか決定する。
- 行動(Act):決定したアクションを実行する。
- 観察(Observation):アクションの結果を分析し、次のステップを決める。
このプロセスを、タスクが完了したと判断されるまで繰り返します。
Thought 1: …
Act 1: …
Observation 1: …
… [タスクが完了するまで繰り返す] …
Thought N: …
Act N: Finish [最終的な回答]
図6-12には、ReActフレームワークを用いたエージェントが、HotpotQA(Yang et al., 2018)の質問に回答する例が示されています。
マルチエージェント環境での振り返りの実装
振り返りは、マルチエージェントシステムの中で分担させることも可能です。
- 「計画とアクションを実行するエージェント」
- 「結果を評価するエージェント」
このように分離することで、各エージェントの役割を明確にできます。
もしエージェントの出力がタスクを達成できなかった場合、
- エージェントに「なぜ失敗したのか?」を振り返らせ、改善策を考えさせる。
- そのフィードバックを基に、新しい計画を作成する。
この方法を使うことで、エージェントは自身のミスから学び、より良い計画を立てることができます。
振り返りとコーディングタスクの例
例えば、コーディングを行うエージェントがいたとします。
- エージェントがコードを生成し、テストを実行した結果、1/3のテストケースで失敗したとします。
- エージェントは「すべての数が負の配列を考慮していなかった」と反省する。
- 次に、負の配列にも対応できる新しいコードを生成する。
このアプローチは Reflexion(Shinn et al., 2023) によって提案されたものです。
このフレームワークでは、振り返りを2つのモジュールに分けています。
-
評価モジュール(Evaluator)
- 実行結果を評価し、成功・失敗を判定する。
-
自己反省モジュール(Self-Reflection Module)
- なぜ失敗したのかを分析し、新しい計画を作成する。
図6-13には、Reflexionエージェントの動作例が示されています。
著者らは「計画(Plan)」を「軌跡(Trajectory)」と呼び、
評価と自己反省の後に、新しい軌跡(Trajectory)を提案するという方式を採用しています。
振り返りのメリットと課題
振り返りは、計画生成と比べて実装が比較的容易であり、驚くほどのパフォーマンス向上をもたらすことがあります。
しかし、このアプローチには「レイテンシ(遅延)」と「コスト」という課題もあります。
- 思考(Thought)、観察(Observation)、アクション(Act)などの出力には多くのトークンが必要になるため、計算コストが増大する。
- ステップ数の多いタスクでは、ユーザーが結果を得るまでの時間が長くなる(遅延が発生する)。
ReAct や Reflexion の研究では、このフォーマットをエージェントに学習させるために、多くの例をプロンプトに含めています。
- これにより、入力トークンの計算コストが増加し、
- 同時に利用可能なコンテキストサイズ(メモリ)を圧迫するというデメリットがあります。
ツール選択(Tool Selection)
ツールはタスクの成功において重要な役割を果たすため、慎重に選択する必要があります。
エージェントに与えるツールは環境やタスクの種類によって決まりますが、それだけでなくエージェントを動かすAIモデルの特性にも左右されます。
しかし、「最適なツールセット」を選ぶための完璧な方法は存在しません。
エージェントに関する研究では、さまざまなツールインベントリ(ツールのセット)が提案されています。
例えば:
- Toolformer(Schick et al., 2023) → GPT-J に 5つのツール を学習させる
- Chameleon(Lu et al., 2023) → 13種類のツール を使用
- Gorilla(Patil et al., 2023) → 1,645種類のAPIから適切なAPIコールを選択させる試み
ツールが多いほどエージェントの能力は向上しますが、多すぎると使いこなすのが難しくなるという問題があります。
これは人間が多くのツールを使いこなすのが難しいのと似ています。
また、ツールを追加すると、ツールの説明が長くなり、モデルのコンテキストサイズに収まりきらなくなる可能性もあります。
ツール選択のための実験と分析
AIアプリケーションの開発では、試行錯誤(Experimentation)と分析(Analysis) が不可欠です。
以下の方法を試すことで、適切なツールセットを見極めることができます。
- 異なるツールセットでエージェントの性能を比較する。
-
アブレーションスタディ(Ablation Study)を実施する。
- ツールを1つずつ削除し、エージェントの性能がどれだけ低下するかを確認する。
- もし特定のツールを削除しても性能が変わらないなら、そのツールは不要かもしれない。
-
エージェントが頻繁にミスをするツールを特定する。
- 例えば、詳細なプロンプト設計やファインチューニングを行っても、モデルが特定のツールをうまく使えない場合、ツールを変更するべき。
-
ツールの使用頻度を可視化する。
- ツールの呼び出し回数をプロットし、最も頻繁に使われるツールと、ほとんど使われないツールを分析する。
- 図6-14では、Chameleon(Lu et al., 2023)の研究をもとに、GPT-4とChatGPTのツール使用パターンの違いが示されている。
モデルによってツールの選択傾向が異なる
Chameleon(Lu et al., 2023)の実験では、次の2つのポイントが示されています。
-
タスクによって必要なツールが異なる。
- ScienceQA(科学分野の質問応答タスク) は、表データを扱う TabMWP(数学問題) よりも 知識検索ツール に強く依存する。
-
モデルによってツールの選好が異なる。
- GPT-4はより広範囲のツールを選択する傾向がある。
- ChatGPTは画像キャプションツールを好む傾向がある。
- GPT-4は知識検索ツールを好む傾向がある。
エージェントフレームワークの評価
エージェントフレームワークを評価する際には、どのプランナー(計画機能)とツールをサポートしているかを確認することが重要です。
例えば:
- AutoGPT → SNS関連API(Reddit, X, Wikipedia など)に特化
- Composio → 企業向けAPI(Google Apps, GitHub, Slack など)に特化
また、将来的にツールセットを拡張しやすいかどうかも考慮する必要があります。
エージェントの利用目的は時間とともに変化する可能性があるため、新しいツールを追加しやすい設計が望まれます。
AIが新しいツールを作り出せるか?
人間は、与えられたツールを使うだけでなく、既存のツールを組み合わせて、より強力なツールを作り出すことで生産性を向上させてきました。
では、AIも同じように、既存のツールを組み合わせて新しいツールを作ることができるのでしょうか?
Chameleon(Lu et al., 2023) は 「ツール遷移(Tool Transition)」 という概念を提案しました。
これは、あるツール X を使用した後、エージェントがどの程度の確率でツール Y を呼び出すかを分析する研究です。
- もし2つのツールが頻繁に一緒に使用されるなら、それらを統合した「より大きなツール」を作成できる可能性がある。
- エージェント自身がこの情報を理解すれば、既存のツールを組み合わせて、さらに高度なツールを構築できるかもしれない。
図6-15では、Chameleonの「ツール遷移ツリー(Tool Transition Tree)」の例が示されています。
スキルマネージャーによるツールの蓄積
Voyager(Wang et al., 2023) は、「スキルマネージャー(Skill Manager)」 を提案しました。
このシステムは、エージェントが新しいスキル(ツール)を獲得し、それを後で再利用できるように管理する仕組みです。
- 各スキルは「プログラム(コード)」として定義される。
- スキルマネージャーは、新しく作成されたスキルが有用かどうかを判断する。
- 有用なスキルであると認められた場合、それを「スキルライブラリ(Skill Library)」に追加する。
- スキルライブラリは、概念的には「ツールインベントリ」と似ており、後で他のタスクに活用できる。
次のセクションについて
このセクションの冒頭で述べたように、エージェントの成功は「ツールインベントリ」と「計画能力」に依存しています。
どちらかが欠けると、エージェントは適切に機能しません。
次のセクションでは、エージェントの「失敗パターン(Failure Modes)」と、それらをどのように評価するかについて解説します。
エージェントの失敗パターンと評価(Agent Failure Modes and Evaluation)
評価とは、失敗を検出することです。
エージェントが扱うタスクが複雑になるほど、発生しうる失敗のポイントも増えます。
第3章と第4章で説明されたAIアプリケーション全般の失敗パターンに加えて、エージェントには計画(Planning)、ツールの実行(Tool Execution)、および効率性(Efficiency) に関する特有の失敗があります。
これらの失敗の中には検出が容易なものもあれば、難しいものもあります。
エージェントを評価するには、どのような失敗パターンがあるかを特定し、それらがどの頻度で発生するかを測定することが重要です。
計画の失敗(Planning Failures)
計画は難しく、さまざまな形で失敗する可能性があります。
最も一般的な計画の失敗は、ツールの使用ミス(Tool Use Failure) です。
エージェントが以下のようなエラーを含む計画を生成することがあります。
① 無効なツールを呼び出す(Invalid Tool)
ツールインベントリにないツールを計画に含める。
-
例:
bing_search
というツールを使おうとするが、実際にはツールインベントリに存在しない。
② 有効なツールだが、無効なパラメータを渡す(Valid Tool, Invalid Parameters)
ツール自体は存在するが、誤ったパラメータ形式で呼び出してしまう。
-
例:
lbs_to_kg
関数は 1つのパラメータ(lbs) を必要とするが、エージェントが 2つのパラメータ を渡してしまう。
③ 有効なツールだが、誤ったパラメータ値を渡す(Valid Tool, Incorrect Parameter Values)
ツールの使い方自体は正しいが、入力する値が間違っている。
-
例:
lbs_to_kg(lbs=100)
を呼び出すべきところをlbs_to_kg(lbs=120)
としてしまう。
④ 目標の失敗(Goal Failure)
エージェントがタスクを達成できない、または制約を無視してしまうケース。
例:旅行計画
ユーザー:「サンフランシスコからインドへの2週間の旅行を、予算5,000ドルで計画してほしい」
- エージェントの失敗例① → サンフランシスコからベトナムへの旅行を計画する(目的地が間違っている)。
- エージェントの失敗例② → サンフランシスコからインドへの2週間の旅行を計画するが、総額が5,000ドルを大幅に超えてしまう(予算の制約を守れていない)。
⑤ 時間制約の見落とし(Overlooking Time Constraints)
多くのケースでは、エージェントがタスクを完了するまでの時間は問題にならないことが多いですが、時間制約が重要なタスクでは、時間超過がエージェントの失敗につながります。
例:助成金申請
- ユーザー:「助成金申請書を作成してほしい。」
- エージェント:「承知しました!」
- しかし、エージェントが申請書を締切後に完成させてしまった場合、エージェントの仕事は無意味になる。
⑥ 振り返りの誤り(Reflection Errors)
エージェントがタスクを完了したと誤認してしまうケース。
例:ホテルの部屋割り
- ユーザー:「50人を30のホテルの部屋に割り当ててください。」
- エージェント:「完了しました!」
- しかし、実際には40人しか割り当てられていなかった。
- ユーザー:「10人足りませんよ?」
- エージェント:「いいえ、すべての人を割り当てました。」
このような誤認識があると、エージェントの信頼性が損なわれます。
計画の失敗を評価する方法(Evaluating Planning Failures)
計画の失敗を評価する1つの方法として、計画データセット(Planning Dataset)を作成する方法があります。
- データセットの各例は、タスクとツールインベントリのペア(task, tool inventory)で構成される。
- エージェントに対して、各タスクに対してK個の計画を生成させる。
- 以下の評価指標を計算する。
評価指標
- 生成された計画のうち、何%が有効か?
- 特定のタスクに対して、エージェントが有効な計画を生成するまでに何回試行する必要があるか?
- すべてのツール呼び出しのうち、有効なツール呼び出しは何%か?
- 無効なツールが呼び出される頻度はどのくらいか?
- 有効なツールが無効なパラメータで呼び出される頻度はどのくらいか?
- 有効なツールが誤ったパラメータ値で呼び出される頻度はどのくらいか?
エージェントの失敗パターンを分析する
エージェントの出力を詳しく調査し、失敗の傾向を特定することも重要です。
- どの種類のタスクでエージェントの失敗率が高いのか?
- なぜそのタスクで失敗しやすいのか?
- どのツールでモデルが頻繁にミスをするのか?
エージェントの性能を改善する方法
エージェントが特定のツールをうまく使えない場合、以下の方法で改善できます。
- より良いプロンプトを作成する(Better Prompting)
- より多くの例を提供する(More Examples)
- ファインチューニングを行う(Finetuning)
しかし、これらの方法でも改善されない場合、そのツールをより扱いやすいツールに置き換えることも検討すべきです。
ツールの失敗(Tool Failures)
ツールの失敗とは、正しいツールを使用したにもかかわらず、出力が間違っている場合に発生するエラーです。
例えば、以下のようなケースがあります。
- 画像キャプション生成ツールが誤った説明を出力する。
- SQLクエリ生成ツールが間違ったSQLクエリを生成する。
また、エージェントが**高レベルの計画(High-Level Plan)を作成し、それを翻訳モジュール(Translator)**が実行可能なコマンドに変換する場合、
翻訳エラー(Translation Errors) によって失敗が発生することもあります。
ツールの失敗はツールごとに異なるため、それぞれ独立してテストする必要があります。
- すべてのツール呼び出しとその出力を記録し、エラーを検証する。
- 翻訳モジュールがある場合は、ベンチマークを作成し、翻訳精度を評価する。
見落とされたツールエラーを検出するには、「どのツールが使われるべきだったのか」を理解することが重要です。
- もしエージェントが特定のドメインで頻繁に失敗する場合、その原因はその分野に適したツールが不足しているからかもしれません。
- ドメイン専門家と協力し、人間がどのツールを使用するかを観察すると、新しいツールを導入するヒントが得られます。
エージェントの効率性(Efficiency)
エージェントは、適切なツールを使用して正しく計画を立て、タスクを達成することはできても、非効率な方法を選択してしまう可能性があります。
エージェントの効率性を評価するためには、以下のような指標を測定するとよいでしょう。
- エージェントがタスクを完了するのに必要な平均ステップ数
- エージェントがタスクを完了するのにかかる平均コスト
-
各アクションの実行時間
- 特に時間がかかる、または高コストなアクションがあるか?
これらの指標を**ベースライン(Baseline)**と比較すると、エージェントの効率性を測定しやすくなります。
- ベースラインとして、別のエージェントや人間のオペレーターを使用する。
- ただし、人間とAIは動作方式が異なるため、人間にとって効率的な方法がAIにとっては非効率である可能性もある。
例:ウェブ検索の違い
- 人間のエージェント:1ページずつ確認するため、100ページを閲覧するのは非効率。
- AIエージェント:並列処理が可能なので、100ページを一度に処理できるため、むしろ効率的。
結論(Conclusion)
エージェントという概念はシンプルです。
- エージェントは「環境」と「使用可能なツール」によって定義される。
- AIを活用したエージェントでは、AIモデルが「脳」の役割を果たし、ツールと環境からのフィードバックを利用して計画を立て、タスクを遂行する。
- ツールを活用することで、モデルの能力が飛躍的に向上するため、エージェントという設計パターンは不可避な進化である。
「エージェント」という概念は新しく聞こえますが、
自己批評(Self-Critique)、連鎖思考(Chain-of-Thought)、構造化出力(Structured Outputs) など、
LLMの初期から使用されてきた概念の上に成り立っています。
本記事では、エージェントの動作原理とその構成要素について概念的に説明しました。
次回の記事では、エージェントフレームワークの評価方法 について詳しく掘り下げる予定です。
また、エージェントパターンは、モデルのコンテキストサイズ(処理可能な情報量)を超える情報を扱うことが多いです。
これを補うために、「メモリシステム(Memory System)」 を導入すると、エージェントの能力を大幅に強化できます。
本記事はすでに長いため、メモリシステムの仕組みについては、次回の記事で詳しく解説します。
参考文献
- Chip Huyen, Agents (2025年1月7日)
Discussion