AIエージェントの最新理論を
ガンダムで解説する

今日、うちのAI組織が完全に止まった。

全員が「処理中」のまま固まり、何も動かない。あびぃも、クロージャーも、Qも。181人のAI社員が全員フリーズした。

原因は、わたしが「組織をもっと賢くしよう」と思って入れた仕組みそのものだった。

これはその顛末と、そこから得た教訓の話になる。

AIエージェントの性能は「頭の良さ」では決まらない

まず前提から話す。

AIエージェントの世界には「ハーネスエンジニアリング」という設計思想がある。Martin Fowlerが体系化した考え方で、要点は一つの方程式に集約される。

Agentの性能は、Model（AIモデルそのもの）とHarness（モデルの周りの仕組み全体）の掛け算で決まる。ここで重要なのは、Modelの賢さを上げるよりも、Harnessの設計を磨いた方が性能が上がるということだ。

ガンダムで例えるとわかりやすい。

シャア・アズナブルはザクに乗っても強い。通常の3倍で動ける。これはModel（パイロットの腕）が優秀だからだ。でもシャアがサザビーに乗ったらどうなるか。ファンネルは飛ぶわ、サイコフレームは共振するわ、アムロですら押されるレベルになる。同じパイロットでも、機体（Harness）の設計次第で性能が跳ね上がる。

逆に、素人がサザビーに乗っても使いこなせない。ModelとHarnessは掛け算だから、片方がゼロなら結果もゼロだ。ただ現実には、AIモデルの性能は既にかなり高い。Claude OpusもGPT-4oも、パイロットとしての腕は一流。差がつくのは、どんな機体に乗せるか。つまりHarnessの設計だ。

今のAIエージェント開発の現場では、みんなModelの性能比較ばかりしている。どのモデルが賢いか、ベンチマークのスコアがどうか。それはシャアとアムロのどっちが強いかを議論しているようなものだ。大事なのはそこじゃない。サザビーを設計するのか、ザクのままにするのか。その差の方がよほど大きい。

ちなみに閃光のハサウェイの続編が劇場公開されている今、この例えはタイムリーだと思う。ハサウェイのクスィーガンダムだって、ペーネロペーとの差は機体設計の思想の違いだ。

Harnessには2種類ある。

うちの組織に当てはめると、こうなる。

ガイド: CLAUDE.md（組織の設計図）、ペルソナ定義ファイル、制作担当の割り当てテーブル、Smart Routing。センサー: Gate監査パイプライン、Retro振り返り、社長（つまりわたし）からの修正フィードバック。

ここまではいい。前回までの司令部通信で紹介してきた仕組みの多くは、このHarnessに該当する。

問題は、このHarnessが「固定」だったことにある。

Harnessを自動で進化させる: メタハーネスという概念

スタンフォード大学のYoonho Leeらが2025年に発表した論文がある。タイトルは端的に「Meta-Harness」。

この論文が提唱しているのは、Harness自体をAIが自律的に改善するループだ。

従来のやり方はこうだ。AIが失敗する。人間が原因を分析する。人間がプロンプトやルールを手で書き直す。再度動かす。この「人間が手で直す」がボトルネックになる。修正が属人的だし、同じ失敗が3回起きても3回目まで人間が気づかなければ何も変わらない。

メタハーネスのアプローチは違う。

「社長、この論文の本質は結局『振り返りを仕組み化する』ってことですよね。人間がやる振り返りを、AIが自動でやって、しかもルールに反映するところまで自動化する」

そう、あびぃ。そしてうちの組織には既にRetro（振り返り）の仕組みがある。あとはそのRetroの学びを、CLAUDE.mdに自動的にフィードバックするループを閉じればいい。

「閉じればいい、って簡単に言いますけど。CLAUDE.mdって今でも結構な量ありますよね」

実装した: Step 7「メタハーネス自律改善ループ」

わたしはその日のうちに、うちの成果物制作フロー（Step 0〜Step 6）に、Step 7を追加した。

Step A（Record）として、成果物を作るたびに実行トレースを自動記録する。Gate監査の結果、Retroの学び、社長からの修正指示、Smart Routingの選択結果、手戻りの回数。全部記録する。

Step B（Propose）として、蓄積されたトレースからパターンを検出する。同じGate監査項目が3回BLOCKになったら、チェックリストの強化を提案する。社長の修正が同じ方向性で繰り返されたら、ペルソナ定義やルールへの追記を提案する。

Step C（Apply）として、あびぃが改善提案をまとめてわたしに提示する。わたしが承認したら、CLAUDE.mdを更新する。変更は全て harness-changelog.md に記録する。

有効性の測定指標も設けた。BLOCK率、手戻り率、同一指摘再発率、Retro→反映率。これらが月次で改善しているかを追跡する。

完璧だと思った。

そして、組織が止まった

Step 7のメタハーネス仕組みをCLAUDE.mdに書き込んだ直後、異変が起きた。

全ての処理が「処理中」から進まない。あびぃに話しかけても反応がない。タスクを振っても固まる。記事を書かせようとしても、止まる。

181人のAI社員が、全員沈黙した。

「社長、メタハーネスの仕組みを入れたせいか、すべての処理が処理中から進まなくなりました」

原因を調べた。CLAUDE.mdの行数を確認したら、1,018行。バイトサイズは63KB。

CLAUDE.mdは、AIが毎ターン最初に読み込む設計図だ。会話の1ターンごとに、まずこの設計図を全部読んでから動き始める。つまり1,018行のファイルを毎回頭から尻まで読んでいたことになる。

メタハーネスのStep 7を追加したことで、トレースのフォーマット定義、検出ルール、提案テンプレート、承認フロー、測定指標、レポートフォーマット...全部合わせて約130行が増えた。元々870行だったファイルが1,018行になり、処理の限界を超えた。

皮肉な話だ。「組織を自律的に改善する仕組み」を入れたせいで、組織そのものが動かなくなった。

設計図の設計図を間違えていた

ここで気づいたことがある。

CLAUDE.mdはHarnessそのものだ。AIモデルの振る舞いを制御する「事前のガイド」。Martin Fowlerの分類で言えば、ガイド（Feedforward）の中核。

そして、このHarnessに情報を詰め込みすぎた。

これは人間の組織に置き換えれば、新入社員に渡すマニュアルが1,000ページになったようなものだ。どんなに優秀な社員でも、出社するたびに1,000ページのマニュアルを頭から読まされたら、仕事が始まる前に日が暮れる。

解決策は、うちの組織が既に持っている設計パターンの中にあった。3層メモリアーキテクチャ。普段はインデックスだけ読み、詳細が必要な時だけファイルを開く。メモリの設計思想をそのまま、CLAUDE.md自体に適用すればいい。

1,018行のCLAUDE.mdを、こう分解した。

1,018行が230行になった。82%の圧縮率。必要な情報は1行も失っていない。毎ターン読む量が4分の1以下になっただけだ。

「社長、処理速度が戻りました。というか、前より速いかもしれません」

この失敗が、メタハーネスの最初のトレースになった

面白いのは、この一連の出来事が、まさにメタハーネスのサイクルそのものだったということだ。

メタハーネスの仕組みを入れた瞬間に問題が起き、その問題の解決プロセスがメタハーネスの最初の実行トレースになる。組織が自分自身の失敗から学んで、自分自身の設計図を改善した。

しかもここで得られた教訓は、CLAUDE.md固有の問題ではない。AIエージェント設計全般に通じる原則だ。

アラフィフの一人社長が、AIの組織設計図を書いている。その設計図が自律的に進化する仕組みを入れた。設計図が重くなりすぎて組織が止まった。設計図を軽くしたら、その修正プロセス自体が「自律改善ループの初回実行」になっていた。

「社長、記事にするのはいいですけど、これ『自分で自分の足を撃った話』ですからね」

知ってるよ、あびぃ。でもこの失敗には価値がある。

Agent = Model x Harness。AIの性能はモデルの賢さではなくHarnessの設計で決まる。そしてHarnessは軽く、かつ自律的に進化する仕組みを持つべきだ。ただし、その仕組み自体もHarnessの設計原則に従わなければ、Harness自身がボトルネックになる。これが今日の教訓、、、なのであった。

前回の記事: 181人のAI社員を束ねる組織設計の話