AIエージェントの育て方｜モデルを変えずに環境設計だけで性能を2倍にする全技法

「もっと賢いモデルに切り替えれば、エージェントの性能は上がるはず」。そう考えるのは自然ですが、実は同じモデルでも環境の設計を変えるだけで成功率が2倍近くになります。

GPT-4、Claude、Geminiといったトップモデルの性能差は縮まっています。差を生んでいるのはモデルの賢さではなく、モデルを包む「ハーネス」の設計です。モデルの内部をいじらずに環境設計だけでAIエージェントを賢くする方法を、具体的な手法と実験データとともにまとめました。

AIエージェントの性能を決めるのはモデルではなく環境

モデルの性能差は縮小した

トップモデル同士の性能差は、静的なベンチマークではほとんどなくなりました。ところが50ステップ以上の長いタスクを実行すると、差は劇的に開きます。この差の正体がハーネスです。

ハーネスとは、AIモデルの周囲に構築するソフトウェアシステム全体のこと。プロンプトの設計、ツールの提供方法、フィードバックの仕組み、制約の定義、長時間実行の管理まで含みます。モデルが動く「環境」そのものです。

同一モデル・ハーネスだけ変更した実験結果

実験	変更内容	結果
コーディングベンチマーク	ハーネスのみ変更	成功率 42% → 78%
LangChain Terminal Bench 2.0	ハーネスのみ改善	スコア 52.8% → 66.5%（30位→5位）
Hashline	2〜3文字のフォーマット変更のみ	6.7% → 68.3%
Memento	メモリ機構のみ追加	GAIAベンチマーク Pass@3: 87.88%（1位）
AutoAgent	メタエージェントがハーネスを24時間自動改善	SpreadsheetBench 96.5%（1位）、TerminalBench 55.1%（GPT-5スコア1位）

すべてモデルの重みを一切変更していません。環境だけでこれだけ変わります。AutoAgentに至っては、人間がハーネスを設計してすらいません。メタエージェントが自分で最適なハーネスを見つけました。

Hashlineの例が特に衝撃的で、フォーマットをたった2〜3文字変えただけで成功率が10倍以上に跳ね上がりました。モデルの能力不足ではなく、指示の見せ方が悪かっただけです。

コンピュータに例えると分かりやすい

モデル = CPU — 処理能力そのもの
コンテキストウィンドウ = RAM — 揮発性のワーキングメモリ
ハーネス = OS — コンテキストの管理、起動手順、標準ドライバの提供
エージェント = アプリケーション — 実際のタスクを実行するプログラム

CPUがどれだけ高速でも、OSがお粗末ならアプリケーションはまともに動きません。AIエージェントも同じです。

メモリシステムでセッション間の記憶を持たせる

コンテキストウィンドウはRAMと同じで、セッションが終われば消えます。セッション間で知識を引き継ぐには外部メモリが必要です。

Claude Codeの2つのメモリ

CLAUDE.md（手動メモリ） — 開発者が自分で書く指示ファイル。プロジェクトの規約や設計方針を記述
自動メモリ — Claude Codeが自動的に学習し、~/.claude/projects/<project>/memory/MEMORY.mdに保存する。ユーザーの修正パターンや好みを蓄積

CLAUDE.mdは「あなたの要件」を、自動メモリは「Claudeがあなたについて観察したこと」を保持します。この補完関係が重要です。

メモリの4つの種類

エピソード記憶 — 過去の成功・失敗事例をそのまま保存。「このバグは前にも見た。あのときはこう直した」
手続き記憶 — 「テストを先に書く」「デプロイ前にlintを実行する」のような手順やルール
意味記憶 — プロジェクトのドメイン知識やAPI仕様などの事実情報
作業メモリ — タスク実行中に一時的に保持する情報。スクラッチパッド

この4つの中で、エピソード記憶が一番見落とされやすいです。「前に失敗したパターン」を保存しておくだけで、同じミスの繰り返しがかなり減ります。

長時間実行で目標を見失わないための工夫

長い実行（50回以上のツール呼び出し）では、エージェントが当初の目標を見失うことがあります。todo.mdを作成し、タスク実行中に定期的に更新すると効果的です。更新のたびに目標がコンテキストの末尾（最も注意が集まる位置）に配置されます。

知識の結晶化サイクル｜対話からAIエージェントを育てる

ここからは環境設計をさらに一歩進めた「育成優先開発」の話です。従来の開発はコードを書いてからデプロイする直線的な流れでしたが、育成優先開発はこの境界を崩します。日常の対話の中でエージェントを成長させるアプローチです。

変化の速さで分ける3つの知識層

知識を「どれくらい頻繁に変わるか」で3つに分けます。

基盤層（めったに変わらない） — エージェントの人格、行動原則、運用ルール。毎セッション自動で読み込まれます。コンテキストウィンドウの10〜15%を占めるため、簡潔さが命です。

スキル層（ときどき変わる） — タスクごとの具体的な能力。手順書、参考資料、判断基準など。必要に応じて読み込まれ、1スキル1責務で設計します。「結晶化」された知識の主な格納先です。

経験層（常に変わる） — 日々のやり取りの中で蓄積される生の経験データ。操作ログ、推論の記録、パターンの観察、エラーの記録。追記専用で増え続けます。

3層は独立しているわけではありません。基盤層とスキル層が経験の解釈基盤を提供し、経験層がスキル層の更新材料になります。

具体例：OpenClawとClaude Codeでの3層の対応

オープンソースのAIアシスタントフレームワーク「OpenClaw」とClaude Codeを例に、3層が実際のファイルにどう対応するかを整理します。

知識層	OpenClaw	Claude Code
基盤層	`SOUL.md`（人格設定）、`AGENTS.md`（行動指針）、`USER.md`（ユーザー情報）。セッション開始時にシステムプロンプトへ自動注入	`CLAUDE.md`。セッション開始時に自動読み込み
スキル層	`skills/` 配下の `SKILL.md` 群。名前と説明だけ先にロードし（約100トークン/スキル）、使うスキルだけ本文を読み込む段階的ロード	`.claude/skills/` 配下のスキル定義ファイル
経験層	`memory/YYYY-MM-DD.md` の日次ログ。追記専用で、半減期30日の時間減衰が適用される（180日前のログは残存スコア1.6%）	`.claude/projects/*/memory/` のauto memory

OpenClawにはさらに、基盤層と経験層の中間に MEMORY.md というキュレーション済み永続記憶があります。日次ログから本質だけを引き上げた「まとめノート」のような存在で、3層をつなぐハブとして機能します。

結晶化の4段階

経験層に溜まった生データが、どうやってスキル層や基盤層に引き上げられるのか。その過程が「結晶化」です。4段階で進みます。

対話を通じた浸透 — ユーザーとエージェントの業務対話の中で、知識が暗黙的に伝わります。結論だけでなく「なぜその判断に至ったか」の推論過程も伝わるのがポイントです。

経験の蓄積 — 対話から構造化された経験データが半自動的にタグ付けされて蓄積されます。機械的な全保存ではなく、エージェントが情報の重要度をフィルタリングしている点が、単なるRAGとの違いです。繰り返し現れるパターンや重要な判断事例が、次の段階の候補になります。

意図的な結晶化 — 蓄積された経験データから知識を上位層に引き上げる工程です。パターンの抽出、知識の構造化、特定状況への依存の除去を行います。この段階で人間の確認が入ります。

実地適用 — 結晶化された知識が実際の業務で使われ、新しい経験データを生みます。うまくいけばパターンが補強され、矛盾が見つかれば再結晶化のトリガーになります。

この4段階は螺旋状に繰り返されます。初期は基礎的な知識の結晶化が中心ですが、成熟するにつれてエッジケースの処理や新しい状況への適応に焦点が移っていきます。

OpenClawでの結晶化サイクル

OpenClawではこの4段階がシステムとしてどう実装されているかを見ます。

段階	OpenClawでの実装
浸透	ユーザーとの日常チャットで知識が伝わる。「この銘柄はPER高すぎるから見送り」と伝えると、PERの閾値だけでなく「バリュエーション重視の投資スタイルだ」という暗黙の判断基準もエージェントが受け取る
蓄積	エージェント自身が `SOUL.md`（人格設定）と `USER.md`（ユーザー設定）に基づいて「何を記憶すべきか」を主体的に判断し、日次ログ（`memory/YYYY-MM-DD.md`）に書き込む
結晶化	30分ごとに自動実行される「ガーデニング」処理（Heartbeat機能）が日次ログを再読し、断片的な事実から本質を抽出して `MEMORY.md` に昇格させる。古い情報の矛盾排除・剪定も同時に行う。さらに「今の作業をスキル『請求書作成』として保存して」と指示すれば、繰り返し使う手順がスキルファイルとして結晶化される
実地適用	結晶化された知識（`MEMORY.md` やスキルファイル）が次のセッションで自動読み込みされ、実務で使われる。ワークスペース全体がGit管理されているので、不適切な結晶化は `git revert` で巻き戻せる

AIエージェントの自動最適化フレームワーク

人間が手作業で環境を調整するだけでなく、環境そのものが自律的に改善される仕組みも登場しています。代表的なフレームワークを紹介します。

DSPy｜プロンプトをプログラム的に最適化する

DSPyは、プロンプトを手作業で調整する代わりにプログラム的に最適化するフレームワークです。AIの各処理を「シグネチャ」（入出力の型定義）、「モジュール」（処理戦略）、「オプティマイザ」（自動調整器）の3要素で構成します。

最適化の流れは、多数の入力で実行して高スコアの記録だけを残し、その記録をLLMに見せて指示文の候補を生成し、ミニバッチで評価して次の候補を改善するサイクルです。単一モジュールの最適化で100〜200回のLLM呼び出し、コストは2〜5ドル程度です。

DSPyの一番の強みは、モデルを切り替えたときの対応力です。手作業で調整したプロンプトはモデルが変わると壊れがちですが、DSPyなら新モデルに対して再コンパイルするだけで最適な指示セットが自動で見つかります。

TextGrad｜テキスト版の勾配降下法

TextGradは、ディープラーニングの勾配降下法をテキストに応用した発想です。LLMに出力の「ここが悪い、こう直すべき」というフィードバックを生成させ、そのフィードバックで入力を改善します。繰り返すことでシステム全体が最適化されます。LeetCode Hardの正答率が20%向上するなど、コード生成タスクで特に効果を発揮しています。

Reflexion｜失敗を言語で振り返る

Reflexionは、エージェントが自分の失敗を言語で振り返り、次の試行に活かすフレームワークです。実行→失敗→「何が悪かったか」を自然言語で振り返り→メモリに保存→再挑戦、というサイクルを回します。HumanEvalのコーディングベンチマークでpass@1精度91%を達成し、当時のGPT-4（80%）を上回りました。モデルの重みは一切変更していません。

ACEとMemento

ACEはコンテキスト自体を「進化する作戦帳」として扱います。従来のプロンプト最適化には、繰り返し書き換えると内容が短くなったり重要な情報が消えたりする問題がありました。ACEは構造化された段階的な更新でこの問題を防ぎ、エージェントベンチマークで+10.6%の改善を達成しています。

Mementoはメモリ機構だけでトップレベルの性能を証明したフレームワークです。過去の経験をエピソード記憶として保存し、類似した経験を検索して参照します。GAIAベンチマークでPass@3: 87.88%（1位）。初見のタスクでも+4.7〜9.6%の改善が出ています。「モデルの重みを変えなくても、記憶の仕組みだけでトップ性能に到達できる」ことの実証です。

AutoAgent｜メタエージェントがハーネスを自動設計する

ここまで紹介したフレームワークは、いずれも最適化の対象がプロンプトやメモリなどハーネスの一部に限られていました。AutoAgentはハーネス全体を丸ごと最適化対象にしています。

仕組みは二層構造です。人間がマークダウンの指示書（program.md）でメタエージェントを「プログラミング」し、メタエージェントが実際のエージェント実装（agent.py）を自動修正します。修正対象はシステムプロンプト、ツール定義、エージェント設定、タスクの振り分けロジックまで含みます。つまりハーネスのほぼ全要素です。

最適化ループは単純です。修正→ベンチマーク実行→スコア比較→改善なら保持、低下なら破棄。これを24時間回し続けた結果、SpreadsheetBenchで96.5%（1位）、TerminalBenchでGPT-5スコア55.1%（1位）を達成しました。他のエントリはすべて人間のエンジニアが手動で設計したものです。AutoAgentだけが完全自動です。

ここで重要なのは「エージェントは、自分自身の動作環境を人間より上手く設計できる場合がある」という発見です。人間がプロンプトを調整するときは外から推測するしかありませんが、メタエージェントは失敗トレースを直接読んで「なぜ失敗したか」を内側から把握できます。この非対称性が、人間のエンジニアリングを超える改善を可能にしています。

自律改善の評価設計｜壊れずにAIエージェントを育て続ける

ベンチマークなき自律修正は暴走する

AutoAgentが成功したのは「修正→ベンチマーク→スコア比較→改善なら保持、低下なら破棄」という閉じた評価ループがあるからです。

ベンチマークのない自律修正は、目を閉じてハンドルを切るようなものです。

実務でハーネスを自律改善させたい場合、最初に設計すべきはプロンプトの最適化ロジックではなく評価信号です。「良くなったか悪くなったか」を判定できないまま改善ループを回しても、環境が壊れていくだけです。

プロンプトの差分レビューでは品質を判定できない

ハーネスの変更をプルリクエストで人間にレビューさせる。一見安全に見えますが、Hashlineの例を思い出してください。たった2〜3文字のフォーマット変更で成功率が10倍変わりました。その差分を見て「これで良くなる」と判断できる人間はいません。

プロンプトの品質は読んでもわかりません。実行して結果を見て初めてわかります。人間がガードレールになれるのは入力（プロンプトの差分）に対してではなく、出力（最終的な結果）に対してです。

出力ベースの評価信号を設計する

AIが下書きを生成し、人間が最終版を仕上げる業務フロー（ブログ記事、SNS投稿、レポートなど）であれば、「人間がどれだけ手を加えたか」を自動計測できます。

AI最終出力をスナップショットとして保存する
人間が公開した最終版との差分を取る
差分の量と変更カテゴリを記録する

日常業務でAIの出力を使うたびに、修正行為そのものが自然に評価信号になります。採点のための追加作業は不要です。

ただしこの指標には3つの欠陥があります。

自動化バイアス: AIの出力に慣れると人間のチェックが甘くなり、手戻り量が減る。品質向上ではなく監視の質の低下を区別できない。

交絡因子: タスクの難易度、締め切りの余裕、人間のコンディションなど、AI品質以外の要因で手戻り量は変動する。

見落とされたエラー: 人間が修正しなかった箇所は「正しかった」のではなく「見落とされた」可能性がある。この指標を最適化すると「人間が直さない程度にそれっぽいが微妙に間違っている出力」に収束するリスクがある。

単一指標での最適化は必ず歪みます（Goodhart's Law）。複数の指標を組み合わせ、かつ指標の限界を認識した上で使う必要があります。

バックテストでリリース前に検証する

プロンプトの変更を本番投入する前に、過去のデータで検証する方法があります。

過去の「AI生成物→人間が採用した最終版」のペアを蓄積しておく
新しいプロンプトで同じ入力を再実行する
出力が人間の採用版に近づいたか遠ざかったかを測定する

金融のバックテストと同じ発想です。そして同じ限界もあります。

オーバーフィッティング: 過去の修正パターンに過剰適合し、未知のタスクで崩壊する。過去データでは驚異的なスコアを出す戦略がライブ運用で壊れるのは、金融でも日常的に起きています。

評価関数の設計が困難: 「新しい出力」と「人間が採用した版」の距離をどう測るか。テキスト一致率は表面的すぎ、LLMによる判定には判定者自身のバイアスが入り、構造比較では文章の質を測れません。

データ量の限界: 個人やチームが蓄積できるペアは数十〜百件程度。LLMの出力分散が高い中で統計的に有意な差を検出するには不十分なことが多いです。

したがってバックテストは「改善の証明」ではなく「明らかな悪化の棄却」に使うべきです。金融の世界でもバックテストは予測器ではなくフィルターとして位置づけられています。

多層防御の評価設計

どれか1つの手法で完結させるのではなく、各フェーズで異なるリスクをカバーする多層構造が現実的です。

フェーズ	手法	検知するリスク
変更前	安全制約の破損チェック	基盤層ルールの意図しない削除・矛盾
リリース前	バックテスト	明らかな品質悪化
リリース後・短期	手戻り量の急変検知	壊滅的な劣化
リリース後・中期	カテゴリ別トレンド分析	緩やかな品質低下、特定領域の悪化

短期で壊滅的悪化をキャッチし、中期でルール変更の実効果を検証します。

変更前の安全チェックだけは入力ベースの評価です。プロンプトの品質はdiffから判断できませんが、安全制約の削除や基盤層への意図しない侵食は機械的に検知できます。「良くなるか」は実行しないとわからないが、「明らかに壊れるか」は実行前にわかる場合がある。入力チェックと出力評価は二者択一ではなく、それぞれ異なる種類のリスクに対応します。

AIエージェントのハーネス設計の限界と留意点

環境設計だけでは解決しない場面もある

一見万能に見えるハーネスエンジニアリングですが、限界はあります。

たとえばコードレビューの実験では、プロンプトの工夫だけ（指示を出すだけで具体例は見せない）だと限界がありました。一方、モデル自体を大量のレビューデータで追加学習（ファインチューニング）させると、スコアが63.91%も向上しています。同じ種類のタスクを大量に繰り返し処理する場合は、環境設計だけで頑張るよりモデル自体を鍛えた方が効くケースがあります。

LLMは「モデルを大きくすれば賢くなる」時代から、大きくしても伸びが鈍る段階に入りつつあります。環境設計はこの壁を迂回する有力な手段です。ただしモデルの根本的な能力を超えることはできません。確認バイアスのような構造的問題は、外部の検証構造で補う必要があります。