この回のゴール
- 現代の AI エージェントが 本当にできること を整理する
- 逆に まだできないこと・苦手なこと を具体例で理解する
- 「いつエージェントを使い、いつ使わないか」の判断ができる
- 第 7 章 MCP への動機「ツールをどう標準化するか」を掴む
1. できること(向いているタスク)
✅ 情報の取得と統合
- 社内文書 + Web 検索 + 計算 などを組み合わせた 調査
- 複数 API の 情報統合(例: 株価 + 為替 + 会計)
- RAG で大量文書から 該当部分を探して答える
✅ 繰り返し型の定型タスク
- 顧客サポート(FAQ 検索 + チケット作成)
- 月次レポート作成(DB 問い合わせ + 整形)
- コードレビュー補助
✅ ユーザーインターフェース
- チャット形式 で柔軟な質問受付
- 自然言語 → 構造化クエリ変換
- 複数ツールの入り口を 統一
✅ 中程度の複雑さのプログラミングタスク
- バグ修正(ファイル検索 + 読込 + 編集)
- 小さな機能追加
- テスト作成
2. できないこと・苦手なこと
❌ 長期的な計画
- 10 ステップ以上の手順を 先回りして全部計画 するのは苦手
- その場で考えながら進む 形式なので、途中で袋小路に入ることも
- プラニング専用のサブエージェント で補う等の工夫が必要
❌ 数学的厳密性を要する問題
- ツールがあれば計算はできる
- でも「どう解くべきか」の数学的洞察は限定的
- 複雑な微分積分、線形代数の応用は 専門家には及ばない
❌ 創造的な芸術性
- 文章生成や絵は出せる
- でも 本当に独創的な作品 や 芸術的価値のあるもの は難しい
- 学習データの範囲内での「再構成」が限界
❌ 継続学習・環境適応
- セッション内ではメモリツールで学べる
- でもモデル自体は 再学習しない限り 変わらない
- 時間とともに陳腐化 する情報に自動追従できない
❌ 身体性を伴うタスク
- ロボティクス統合はまだ発展途上
- 物理世界の 触覚・加速度 などのフィードバックが限定的
❌ 真の意図理解
- 「言っていないニュアンス」を完璧に汲み取るのは難しい
- 文化的背景、業界慣習、組織固有の暗黙ルールには弱い
3. 失敗パターン分類
実戦で観察されるエージェントの 失敗モード:
(a) Tool hallucination
存在しないツールを呼ぼうとする、または存在するツールを 別の仕様 で呼ぶ。 → ツール description の明確化、エラー時の親切なメッセージ
(b) 無限ループ
同じ検索を繰り返す、タスク完了に到達しない。 → 前回の停止条件 (max_iter, repeated_tool 検知)
(c) 浅い検索で早期終了
RAG ヒットを浅く読んで誤った回答。 → top-k を増やす、「十分確信が持てるまで調べよ」と system 指示
(d) ツールエラー時の迷走
エラーを見て別ツールで迂回、でも方向がずれる。
→ is_error: True で明示、分かりやすいエラーメッセージ
(e) 過剰な自信
根拠なしに「XX は YY です」と断言。 → 引用元を必ず示す設計、「根拠がない場合は情報なしと言う」指示
4. いつエージェントを使わないか
NG パターン:
- 単純な分類・抽出: tool_use なしで十分(エージェント過剰設計)
- 厳密な決定論的処理: 会計計算、法律判断 → 専用システムが妥当
- リアルタイム制御: 医療機器制御、自動運転のコア部分 → LLM のレイテンシで危険
- ミッション・クリティカル: 失敗が致命的な業務 → 人間のレビュー必須
5. エージェントを「賢く」使う設計原則
HITL (Human-in-the-Loop)
重要な決定の前に 人間の承認 を挟む:
# 毎回 Jupyter で
import pandas as pd
import matplotlib.pyplot as plt
import numpy as np
df = pd.read_csv("./data/sales.csv")
df["date"] = pd.to_datetime(df["date"])
monthly = df.groupby(df["date"].dt.to_period("M"))["amount"].sum()
plt.figure(figsize=(10,4))
monthly.plot()
plt.title("Monthly Sales")
...
実装は permission_policy: "always_ask" など。
Guardrails(ガードレール)
- 送信するメールの件数上限
- 1 回のトランザクションの金額上限
- 変更可能な設定の範囲
- LLM がアクセスできるファイルパス
観測可能性(Observability)
- 全ての tool_use と tool_result をログ
- エラー・タイムアウトを集計
- ユーザーフィードバック収集
- 失敗ケースから system プロンプト改善
評価(Evaluation)
- 代表的タスクのテストセット を用意
- system プロンプトやツールを変えたら実行して回帰を見る
- RAGAS, braintrust などのツール
6. エージェントのサイズ・料金感
| エージェント種類 | 典型的な消費 |
|---|---|
| シンプル FAQ 答え | 5,000〜10,000 tokens / 1 回 |
| RAG ベース顧客サポート | 20,000〜50,000 |
| コーディングエージェント(小タスク) | 50,000〜200,000 |
| 深い調査タスク | 100,000〜1,000,000 |
| Claude Code による大規模リファクタ | 数百万〜 |
Haiku 4.5 なら $1/1M なので、50,000 トークンで $0.05(約 ¥7)。 Opus 4.7 なら $15/1M、50,000 トークンで $0.75(約 ¥110)。
まとめ
- 得意: 情報統合 / 定型反復 / 自然言語 UI / 中程度のプログラミング
- 苦手: 長期計画 / 数学的厳密性 / 真の創造性 / 環境適応 / 身体性 / 暗黙の意図
- 失敗モード 5 種: tool hallucination / 無限ループ / 浅い検索 / エラー迷走 / 過剰な自信
- 設計原則: HITL / Guardrails / Observability / Evaluation
第 6 章のクロージング → 第 7 章への接続
ここまで作ってきた「社内ハンドブック検索ツール」を考えてみてください:
- Slack 連携 したいなら → Slack 検索ツールを自作
- GitHub 連携 したいなら → GitHub 検索ツールを自作
- Google Drive 連携 したいなら → Drive 検索ツールを自作
👉 毎回、ツール定義と実装をゼロから書く のは非効率。
そこで MCP (Model Context Protocol) の出番:
「ツール定義の標準フォーマット を決めて、誰かが作った MCP サーバーをプラグインで繋ぐ」
Anthropic は 共通のツール市場 を作り、開発者は「MCP サーバーを提供」するか「MCP クライアントで消費」するかを選べます。次章で詳しく扱います。
参考文献
- Anthropic: Building effective agents
- Humanloop / LangFuse: Agent evaluation best practices