実運用でちゃんと動くミニエージェントを作るには？そして、誰も語っていない本当の問題とは。
AIの中で起きている分岐があり、それを多くの人が見落としています。
Camp Aは「スーパ―エージェント」を作ります。Webを閲覧し、コードを書き、数十ものツールを使い、複数ステップのワークフローを計画する、自律型システムです。Devin、Manus、Operator。ツイートは拾い、資金も集め、デモもこなします。
Camp Bは「ミニエージェント」を作ります。狭く、単一タスクに特化した意思決定システムで、量をさばくうえでの精度に最適化されています。ツールも、閲覧も、複数ステップの計画もありません。1つの問いに、正しく答える。それを1日あたり何万回も行うだけです。
Camp Bはほぼ沈黙しています。私は何か月もCamp Bにいましたが、これらのエージェントを生み出すハーネスは、個々のエージェントよりも重要だと思っています。
The Economics
1日に二値の意思決定が10,000回ある業務プロセスを考えてください。各決定は熟練した労働で約5分かかります。つまり常勤換算で104人です。
| Super Agent（80%） | Mini Agent（97%） | |
|---|---|---|
| 自動化 | 8,000/日 | 9,700/日 |
| 人によるレビュー | ~2,000/日（修正が遅い） | ~300/日（きれいにフラグが立つ） |
| 人員 | ~50 + 5 eng | ~6 |
| 誤り/日 | 2,000 | 300 |
| 1決定あたりコスト | ~$0.05 | ~$0.002 |
$50〜500（ヘルスケア、金融、法務）/エラーなら、この精度ギャップは1日あたり$85K〜$850Kの価値があります。
スーパ―エージェントはより良いストーリーを作ります。ミニエージェントはより良いビジネスを作ります。
What the Leaders are Saying (But Nobody's Connecting)
このパズルのピースは、AI業界のトップの人たちのブログ記事やツイートに散らばっています。誰も、それをプロダクションシステム向けの一貫した見取り図として組み立てていません。
Andrej Karpathyは、代表的な論文「Software 2.0」で、そのマクロな転換を次のように捉えました：
"ニューラルネットワークを訓練する過程が、データセットをバイナリへとコンパイルします。今日の多くの実用的なアプリケーションでは、ニューラルネットのアーキテクチャや学習システムがますますコモディティ化（商品化）されているため、実際に行われる『ソフトウェア開発』の大部分は、ラベル付きデータセットのキュレーション、成長、加工、クリーニングという形をとります。"
これはニューラルネットについて書かれていますが、プロンプトベースのミニエージェントにはまさにそのまま当てはまります。プロンプトはますますコモディティです。評価時に照らし合わせるラベル付きデータが、本当のIPです。
Anthropicは、影響力のある「Building Effective Agents」のガイドで、多くの読者が読み飛ばしがちな点を強調しています：
"LLMを使ってアプリケーションを構築する際は、可能な限り最も単純な解決策を見つけ、必要になったときだけ複雑さを増やすことを推奨します。これは、エージェント的なシステム自体を作らないということを意味するかもしれません……。多くのアプリケーションでは、検索（retrieval）とイン・コンテキスト例によって単一のLLM呼び出しを最適化するだけで十分なことが多いのです。"
もう一度読んでください。Claudeを作っている会社Anthropicが、「たいていの場合、そもそもエージェントは要らない」と言っているのです。検索の質が良い、うまく作られた単一のLLM呼び出しで十分。それがまさにミニエージェントのパターンです。
Hamel Husainは、GitHub Copilotの前身（CodeSearchNet）を作り、今はAI企業のコンサルをしています。かなり率直に言っています：
"上手くいかなかったプロダクトは、ほぼ例外なく共通の根本原因があります。頑健な評価システムを作ることに失敗しているのです……。評価プロセスを効率化すれば、他のすべての活動が簡単になります。"
彼は何年も前からこれを言っています。ボトルネックはモデルではありません。プロンプトでもありません。評価（eval）です。
Jason Wei（OpenAI、chain-of-thought prompting）は、評価が本当に機能するための条件をこう述べています：
"単一の数値指標が重要です。単一の数値指標を持たない、素晴らしいevalを思いつくことはできません。"
そして最も一般的な失敗パターンは：
"うまくいかなかったevalの大半は、少なくとも1つはミスをしています……。もしevalが複雑すぎると、人がそれを理解しづらくなり、結局はあまり使われなくなります。"
シンプルな指標。シンプルなeval。たくさん回す。これがレシピの全てです。
Eugene Yan（Amazon、かつてApple）による、評価階層（eval hierarchy）について：
"私見では、精度（accuracy）は粗すぎて有用ではありません。少なくとも再現率と適合率に分け、できれば閾値ごとに分ける必要があります。"
彼の言う通りで、それは示唆されている以上のことです。ビジネス上の意思決定では、件数だけで重み付けするのではなく、ドルで重み付けする必要があります。詳細は下で説明します。
Finding 1: The Model is Already Smart Enough
私たちの実験で一番の驚きでした。同じタスクを、GPT-5-mini（$0.75/1M input）からo1（$45/1M）まで、さまざまなモデルでテストしました。
最安と最高の間の精度ギャップは：約2パーセントポイント。コスト倍率が54倍であるのに対してです。
モデルがボトルネックではありませんでした。
Finding 2: Context Beats Instructions
まずルールだらけのプロンプトから始めました。意思決定ツリーが何千トークンも。上限：84.9%。
次に反転しました。短いプロンプト、豊富なデータです。過去の結果、統計的な支払い率、似た過去事例。
同じ500トークンのプロンプトです。入力データだけが変わりました。84.9%から97.3%へ。
これはKarpathyがSoftware 2.0について言ったことを裏付けています。データはプログラムです。私たちのプロンプト（「アーキテクチャ」）は同じままでした。「学習データ」（コンテキストウィンドウ）が、すべての仕事をしてくれました。
Finding 3: Long Prompts Overfit
300回以上の実験で一貫していました。
意思決定ツリーをふんだんに含む長いプロンプトは、学習データでは素晴らしいスコアを出す一方、新しいデータではひどくなります。最も良いパフォーマンスを示したアーキテクチャは、約500トークンの指示のあとに、すべてデータです。
Hamel Husainも、クライアントにおいてまったく同じパターンを見ていました：
"プロンプトが長く扱いにくい形へと膨らみ、多数の例やエッジケースをカバーしようとする。"
彼は、これを「行き詰まり（プラトー）に達したAIプロダクトの主要な症状の一つ」だと説明しています。解決策は、より長いプロンプトではありません。実際に何がうまく機能しているかを教えてくれる、より良い評価ループです。
The Harness
では、モデルが十分に賢く、プロンプトが短いとしたら……本当のエンジニアリング上の問題は何なのでしょうか？
それは反復システムです。ハーネスです。
中核となるループ：
- Generate プロンプトのバリエーションを生成する（手動またはメタプロンプトで）
- Evaluate 各バリエーションをラベル付きの正解データで評価する
- Score 事業価値に結びついた指標でスコア付けする
- Analyze 上位実績者の失敗パターンを分析する
- Evolve その特定の失敗に狙いを定めた新しいバリエーションを生み出す
- Repeat
マルチエージェントのオーケストレーションはありません。RAGもありません。思考過程（chain-of-thought）の足場作りもありません。API呼び出しとスコアリング関数を使った「forループ」です。
私たちは300以上のプロンプト・バリエーションに対して、合計330,000回超の評価を実行しました。ハーネスは疲れません。確認バイアスにも陥りません。お気に入りのプロンプトに恋をしたりもしません。
これは、Anthropicが効果的なエージェントを構築するための助言にそのまま対応しています。彼らは、「エージェント」パターン（LLMが自分のプロセスを動的に指揮する）とは別に、「workflow」パターン（あらかじめ定義されたコードパスがLLM呼び出しをオーケストレートする）を挙げています。ハーネスは、はっきりとworkflow領域にあります。そしてAnthropicはこう述べています：
"Workflows offer predictability and consistency for well-defined tasks."
その通りです。ミニエージェントは、定義の明確なタスクにうまく対応します。予測可能性こそが要点です。
The Two Hard Parts
1. Ground Truth Data
人間がすでに正しい判断を下している、何千ものラベル付き例。学習、検証、テスト用のセットに分割します。
Jason Weiの助言はここにそのまま当てはまります：
"If an eval doesn't have enough examples, it will be noisy and a bad UI for researchers... It's good to have at least 1,000 examples for your eval."
ビジネス上の意思決定タスクなら、私はこれを5,000+に引き上げます。3分割しても、各セグメントごとに統計学的な有意性が保たれるだけの十分な数が必要です。
もし過去の意思決定がデータベースに記録されている領域（請求、アンダーライティング、コーディングなど）にいるなら、過去のあらゆる判断が、無料のラベル付き例になります。
2. The Objective Function
正確さ（正解率％）は、すべての誤りを同じに扱います。しかし現実は違います。
| Component | Weight | Measures |
|---|---|---|
| Dollar-weighted sensitivity | 60% | 追求すべき売上のうち、何％を捕捉できたか？ |
| Dollar-weighted specificity | 20% | クローズすべき事例のうち、何％を正しくクローズできたか？ |
| Unweighted accuracy | 20% | 標準的な正しさ（健全性チェック） |
Jason Weiは「単一の数値指標が重要だ」と言っています。彼の言う通りです。ただし、その数値は分類性能だけでなく、ビジネスの現実を反映している必要があります。件数ではなく金額で重み付けしてください。
What Evolution Looks Like
面白いのは、勝者の失敗を分析することです。
例：私たちの最良のプロンプトは、すべてにおいて素晴らしかったのですが、特定の否認コードを伴う注射薬（injectable drug）の請求（claims）だけはダメでした。そのコードは曖昧でした。「間違った請求情報」（再提出）なのか、「契約上除外」（償却）なのかは、薬によって変わるのです。
改善点は、より良いルールではありませんでした。より良い文脈、つまりその薬＋支払者（payer）の組み合わせにおける過去の支払率（pay rate）でした。
- 支払者はこれまでこの薬に対して支払ったことがない？おそらく除外です。償却。
- 支払者は通常支払うが、このケースだけ否認されている？おそらく請求エラーです。再提出。
データが、否認コードだけでは分からない部分を切り分けました。90%から97%までの各パーセンテージポイントは、この種の「狙いを定めた進化」から生まれました。
Where This Generalizes
このパターンは、次の条件を満たすあらゆる意思決定に対して機能します：
- 高ボリューム（1日あたり数千件）
- 現時点で人が作っている（自動化の余地がある）
- 歴史的に記録されている（グラウンドトゥルースが利用可能）
- 経済的に定量化できる（現実の目的関数が作れる）
候補：ローンの与信審査、コンテンツモデレーション、保険料の価格設定、税の分類、顧客サービスの振り分け、製造におけるQA、不正検知。
それぞれが、独自のハーネス、独自のグラウンドトゥルース、独自のスコアリング関数、独自のトーナメントを持ちます。生まれてくるエージェントは使い捨てです。ハーネスこそ資産です。
What Needs to Happen
研究コミュニティ自身の推奨事項に基づくと：
オープンソースの評価（eval）ハーネス・フレームワーク。 ラベル付きデータ＋スコアリング関数＋プロンプト生成器を組み込むだけで、有効化されたチャンピオンを得られます。LMSYSは、一般用途のチャットボットをEloレーティングでランキングするためのChatbot Arenaを構築しました。私たちは、ドメイン固有の本番タスクに対する同等のものを必要としています。
プロンプト進化戦略に関する研究。 ランダム突然変異と狙いを定めた進化、あるいは遺伝的アルゴリズム。Jason Weiは「evalは研究コミュニティへのインセンティブであり、ブレークスルーはしばしば、いくつかのevalでの大幅なパフォーマンス向上と密接に結びついている」と述べています。これはプロンプトエンジニアリングにも同じことが言えます。evalを作れば、プロンプトエンジニアリングが取り扱い可能になります。
ドメイン固有のベンチマーク用データセット。 MLにはImageNet、GLUE、SuperGLUE、GSM8Kがあります。ミニエージェントには何もありません。
コストを意識した評価。 1決定あたり$0.002で97%は、1決定あたり$0.10で98%よりも優れています。あらゆるリーダーボードには、精度に加えて「1決定あたりのコスト」を含めるべきです。
The Bottom Line
AIにおける最も“それっぽい”（sexyな）課題は、何でもできるエージェントを作ることです。
しかし最も価値のある課題は、「あることを、非常に非常にうまくやる」エージェントを生み出すシステムを作ることです。
エージェントは使い捨てです。堀（moat）はハーネスです。
Bo Romirは、応用AIの意思決定システムを構築しています。ヘルスケアのレベニュー・サイクル・マネジメント領域で、300以上のプロンプト・バリエーションに対して330K件超の自動評価を実行してきました。
References:
- Karpathy, A. "Software 2.0" (2017)
- Anthropic. "Building Effective Agents" (2024)
- Husain, H. "Your AI Product Needs Evals" (2024)
- Wei, J. "Successful Language Model Evals" (2024)
- Yan, E. "Task-Specific LLM Evals that Do & Don't Work" (2024)
- Zheng, L. et al. "Chatbot Arena: Benchmarking LLMs in the Wild" (2023)
