モデルがすべてではなかった — Coding Agentを本当に動かしているもの

8年間作れなかったソフトウェアを、AIと共に3ヶ月で出荷した開発者がいる。同じLLMを使っているのに、ある環境では成果物が出て、ある環境では出なかった。違いはモデルではなかった。

2026年3月、GoogleのPerfettoSQLメインテイナーであるLalit Magantiがsyntaqliteを出荷した。SQLiteの400個の文法規則をパースする完全な開発ツール——parser、formatter、LSP、VS Code extension、Python/JavaScriptバインディング、Webプレイグラウンドまで。約250時間、3ヶ月の作業だった。一人で。

このプロジェクトを彼は8年間やりたかったが、できなかった。SQLを「SQLiteが実際にパースするのと全く同じ方法で」パースしなければならないという要件があり、そのためにはSQLiteの密度の高いCソースコードから文法規則をひとつひとつ抽出する必要があった。難しく退屈な作業が同時に求められる、永遠のサイドプロジェクト候補だった。AIがこれを変えた。Aiderに始まり、Roo Codeを経て、Claude Codeに落ち着いた。

ところが興味深いのはここからだ。最初の1ヶ月間、彼は”vibe coding”をしていた。設計と実装のほぼすべてをClaudeに委ねた。500件以上のテストを生成し、アプローチの実現可能性を証明した。しかし出来上がったのは保守不能なスパゲッティコードだった。彼はすべてを捨て、ゼロからやり直した。同じモデルだった。同じAIだった。なのに二度目は結果が違った。なぜか。

この問いに対する構造的な回答が、同じ週にSebastian RaschkaのComponents of a Coding Agentで示された。Claude CodeやCodex CLIのようなcoding agentが実際にどう構成されているかを分解したこの論考は、ひとつの核心的洞察に収束する——「見かけ上の”モデルの品質”の相当部分は、実際には”コンテキストの品質”である」。

モデルはエンジンだ。だがエンジンだけでは車は走らない。エンジンを包む構造が実際の性能を決める。Raschkaはこの構造をAgent Harnessと呼ぶ。

Harnessという言葉は本来「馬具」を意味する。馬の力を馬車や鋤に伝えるために、馬の体に装着する道具だ。馬そのものの能力を変えるわけではないが、その力がどこへ向かうのか、どのように伝達されるのかを決定する。Harnessのない馬はただ野原を駆け回る。力はあるが方向がない。Harnessを装着した馬は畑を耕し、荷を運び、人を乗せる。同じ力が、構造を通じて目的を持つようになる。

ソフトウェアエンジニアリングでもこの言葉は類似の文脈で使われる。Test harnessはテストを実行し結果を収集するフレームワークだ。テストコード自体の品質を変えるわけではないが、テストが正しい環境で正しい順序で実行され、結果が体系的に報告されることを保証する。Agent Harnessも同じ論理だ。LLMという強力だが方向を持たないエンジンを包んで、コンテキストを収集し、ツールを検証し、記憶を管理し、行動の範囲を制限するソフトウェア層である。モデルをより賢くするのではなく、モデルの賢さが正しい方向に発揮されるよう構造化するものだ。

Magantiの一度目の試みが失敗し二度目が成功した理由も、モデルではなく、そのモデルをどのような構造で使ったかの違いにあった。

1. Coding Agentの解剖 — エンジンの外側にある六つの要素

Raschkaは、Coding Agentを構成する六つの核心的要素を特定している。これらはモデルではない。モデルを包むソフトウェア層だ。ひとつずつ解剖していこう。

第一に、Live Repo Context。 エージェントがユーザーのリクエストを処理する前に、現在の作業環境の「安定的事実」を収集する。Gitブランチの状態、リポジトリの構造、プロジェクトドキュメント（README、AGENTS.md）、進行中の変更内容。「テストを直してくれ」というリクエストを処理するには、どのテストフレームワークを使っているか、テストコマンドが何であるかをまず知る必要がある。このコンテキストがなければ、モデルは真空状態で推測するしかない。

第二に、Prompt ShapeとCache Reuse。 インタラクションのたびにプロンプトをゼロから再構成するのではなく、安定的プレフィックス（一般的な指示、ツール定義、ワークスペース概要）と動的要素（直近の会話、ユーザーのリクエスト）を分離する。このアーキテクチャがprompt cachingを可能にし、不要な再処理を防ぐ。

第三に、Tool AccessとValidation。 モデルが任意のコマンドを生成する代わりに、構造化されたツール定義を通じて行動する。モデルがツール呼び出しを指示すると、harnessがツールの認識可否、引数の妥当性、権限要件、ファイルパスの範囲を検証する。自由度を下げることが、逆説的に信頼性を高める。

第四に、Context Bloatの最小化。 長いコンテキストはコストが大きく、ノイズを誘発する。Harnessは二つの戦略で対応する。Clippingは冗長なツール出力を切り詰め、Transcript Reductionはセッション全体の履歴を要約に圧縮しつつ、直近のイベントはより豊富に保持する。同じファイルの重複読み取りも排除される。

第五に、Structured Session Memory。 エージェントは二層の記憶を維持する。Working Memoryは現在重要な情報の精製された要約だ。Full Transcriptはすべてのリクエスト、ツール出力、レスポンスの完全な記録だ。セッションを閉じて再度開いても作業を継続できる理由がここにある。

第六に、Bounded Subagents。 並列処理やサブタスクのために下位エージェントを生成するが、メインエージェントよりも制限された権限で運用する。読み取り専用操作のみ許可したり、再帰の深さを制限したり、作業範囲を明示的に限定したりする。

六つの要素の共通点が見えるだろうか。モデルの推論能力を向上させるものがひとつもない。すべてモデルが推論できる条件を整備するものだ。Raschkaの比喩を借りれば、LLMはエンジンであり、reasoning modelは強化されたエンジンであり、Agent Harnessはそのエンジンを効果的に使わせるものだ。同じエンジンでも、どのシャーシに載せるかでレーシングカーにもなれば壊れた荷車にもなる。

2. ある開発者の実験 — Harnessが実際に生んだ違い

Raschkaのフレームワークは理論的にすっきりしている。では実戦ではどうか。Magantiの3ヶ月は、この六つの要素が実際にどこで機能し、どこで壁にぶつかるかを精密に映し出すフィールドレポートだ。

Harnessが輝いた領域：慣性の突破。

8年間プロジェクトが始動できなかった理由は、技術力の不足ではなかった。MagantiはGoogleでPerfettoSQLを保守している専門家だ。問題は「難しく、かつ退屈な」作業の組み合わせだった。SQLiteの400個の文法規則をCソースコードから抽出する作業は、高度な集中力を要しながらも反復的だ。人間のモチベーション構造が処理しにくい組み合わせである。

AIがこの慣性を突破した仕組みは興味深い。抽象的な不確実性を具体的なプロトタイプに変換したのだ。「このアプローチは成立するだろうか」という漠然とした問いが、「このコードがこのテストを通過するか」という検証可能な問いに変わった。Harnessの観点から見れば、Live Repo Contextが現在のコードベース状態を把握し、Tool Accessがテスト実行を自動化し、Session Memoryが過去の試行結果を保存した。モデルが「より賢かった」からではなく、モデルが作業できるコンテキストが構造的に整っていたからだ。

Harnessが輝いた領域：ドメインギャップの圧縮。

Magantiがsyntaqliteのために学ぶ必要があったものがある。Wadler-Lindig pretty-printingアルゴリズム、VS Code extension API、Rustツールチェーン、WASMビルドパイプライン、PyPI/crates.ioパッケージング。それぞれを従来の方法で学習すれば数日ずつかかったはずだ。AIはこれを集中的な対話数回分に圧縮した。彼が「teaching assistant」と表現した役割がこれだ。

Harnessのフレームワークで解釈すれば、これはPrompt ShapeとContext Managementの領域だ。ユーザーが既に知っていること（PerfettoSQL、パーサー設計）と知らないこと（Rustビルドシステム）の境界を、harnessが効果的に管理する。安定的コンテキスト（ユーザーの専門領域）をプロンプトプレフィックスに配置し、動的コンテキスト（新たに学ぶ内容）を効率的に注入する構造が、学習速度を引き上げたのだ。

Harnessが輝いた領域：「経済的に正当化できなかったもの」の実現。

Magantiの最も率直な告白のひとつだ。AI無しではエディタ拡張、Webプレイグラウンド、多言語バインディングといった機能は作らなかっただろうと語った。コアパーサーだけ作り、残りは省略していたはずだ。ROIが合わないから。AIが実装コストを劇的に引き下げたことで、以前は費用対効果が見合わなかった機能群が経済的に実現可能になった。プロダクトの完成度が上がったのはモデルがより賢かったからではなく、Subagentによる並列タスク分配とSession Memoryによるコンテキスト保持が「一人で複数領域を同時に進行する」ことを可能にしたからだ。

3. Harnessが解決できなかったもの — 設計は別の問題だ

ここまで読めば「ではHarnessは万能なのか」という問いが浮かぶだろう。答えは明確にノーだ。Magantiの経験は、Harnessの限界をHarnessの可能性と同じくらい鮮明に浮かび上がらせる。

設計判断における失敗。 Magantiは公開API設計においてAIが「total mess」を生み出したと語る。これはモデルの能力不足だろうか。違う。構造的限界だ。Raschkaの六つの要素を振り返ろう。Live Repo Contextは現在のコードの状態を教えてくれる。Tool Accessはテストを回してくれる。Verificationはビルドが通るか確認してくれる。だが「このAPIがユーザーに良い体験を提供するか」を検証するツールは存在しない。Harnessの六つの要素のどれも、この問いに答えられない。

実装（implementation）と設計（design）の差はここにある。実装には「正解」が存在する。コードがコンパイルされるかされないか、テストが通るか落ちるか。この二値的な検証可能性がHarnessのTool AccessとVerificationを強力にする。モデルが誤ったコードを生成しても、テストが落ちればフィードバックループが作動する。

設計にはこうした検証メカニズムがない。「このAPIは半年後も使いやすいか」はテストで確認できない。「この抽象化の粒度は適切か」はコンパイラが判断できない。Magantiの表現を借りれば、「実装には正解がある。設計にはない」。Harnessは正解のある領域で強力であり、正解のない領域では無力だ。

コードベース理解の喪失。 より微妙な問題もあった。AIが大量のコードを生成するにつれ、Magantiは自分のコードベースに対する感覚を何度も失った。アーキテクチャは把握していたが、日常的な詳細——どの関数がどこにあるか、コンポーネント間の接続がどうなっているか——を見失った。これはHarnessのSession Memoryでは解決できない問題だ。Harnessはエージェントのコンテキストを保持するが、人間の開発者のメンタルモデルまでは保持できない。

結果としてプロンプトはどんどん冗長で曖昧になっていった。自分が何を求めているのか正確に表現できないから言葉が増え、言葉が増えるほど出力は曖昧になり、曖昧な出力がコードベースの理解をさらに低下させる悪循環。AIと共に働くときの逆説的なリスク——生産性が上がるほど人間の理解が下がる——がここにある。

時間感覚の不在。 Magantiが指摘したもうひとつの限界は、AIに「temporal awareness」がないことだ。以前なぜある決定を下し、のちになぜ撤回したかを知らない。熟練のシニアエンジニアが組織を去るときに失われるものと似ている——技術ではなくコンテキストが消える。HarnessのSession Memoryは現セッションのコンテキストを保持するが、数ヶ月にわたる設計判断の履歴とその理由までは保持できない。

4. 二度のビルドが証明したこと

Magantiの経験で最も核心的な部分は、二度のビルドの間にある。

一度目のビルド（2025年12月〜2026年1月）：1ヶ月間のvibe coding。AIに設計と実装の両方を委任。500件以上のテストを生成。アプローチの実現可能性を証明。だが成果物は保守不能なスパゲッティコード。全廃棄。

二度目のビルド（2026年2月〜3月）：Rustでゼロから書き直し。人間が設計を主導し、AIを「autocomplete on steroids」として使用。常時リファクタリング。生成コードはすべて即座にレビュー。6週間でコア機能完成、その後パッケージングとドキュメント整備を経てリリース。

同じ人間が、同じモデルで、同じプロジェクトを二度作った。何が違ったのか。

一度目では、人間がHarnessの役割を果たしていなかった。コンテキスト管理、ツール検証、品質ゲート——これらすべてをモデルに任せた。モデルは与えられたコンテキストの中でもっともらしいコードを大量生産したが、長期的な一貫性を維持する構造がなかった。

二度目では、人間がHarnessになった。設計判断を下し（Brainstorming）、生成コードを即座にレビューし（Verification）、コンテキストが乱れればリファクタリングで修復し（Context Management）、AIの作業範囲を明示的に制限した（Bounded Subagentの人間版）。

Raschkaのフレームワークとmagantiの経験を重ね合わせると、ひとつの原則が浮かび上がる。Harnessは存在しなければならない。ソフトウェアとして実装されるか、人間の規律として機能するかを問わず。 モデルだけ置いて「良い結果を出せ」と言うのは、エンジンだけ置いて「走れ」と言うのと同じだ。

Maganti自身がこれを一文で要約している。「AIは実装においては驚異的なforce multiplierだ。だが設計の代替としては危険だ」。この言葉は正確だ。そしてこの言葉が正確である理由をRaschkaのフレームワークが構造的に説明する——Harnessの六つの要素がすべて実装領域でのコンテキスト管理に最適化されており、設計領域での判断は扱っていないからだ。

5. リファクタリングは選択ではなく生存条件だ

Magantiが二度目のビルドで発見したことのひとつは、AIコード生成時代においてリファクタリングの意味が根本的に変わったということだ。彼はこう表現した。「AIで産業的規模のコードを生成しているなら、絶えずリファクタリングしなければならない（you have to refactor constantly）」。

なぜか。従来の開発においてリファクタリングは「コードが十分に積み上がった後」に行う整理作業だった。技術的負債が臨界点に達したら一気に片付ける。だがAIがコードを生成する速度では、技術的負債が蓄積する速度もまた産業的だ。1時間に数百行が生成される。その中にはモデルが「もっともらしいが最適ではない」パターンで書いたものが混在している。1日放置すればその上に別のコードが積まれ、1週間後には根を抜けない構造的問題になる。

Magantiの一度目のビルドがまさにこの軌道をたどった。AIが高速でコードを生成し、500件以上のテストが通過し、すべてが「動いて」いた。だが1ヶ月後に彼が直面したのは、自分自身でさえ理解できないコードベースだった。テストが通過するという事実は、構造的な健全性を保証しなかった。彼はこれを「false reassurance」——テストがもたらす偽りの安心感——と呼んだ。

Harnessの観点からは、これはContext Bloat問題の変形だ。Raschkaが説明したContext Bloat最小化戦略はプロンプトレベルでのノイズ管理だ。しかしコードベースそのもののbloat——不要な抽象化、一貫性のないパターン、モデルが生み出した「合理的だが重複した」構造——はプロンプト管理では解決しない。これは人間が介入すべき領域だ。

二度目のビルドでMagantiが行ったのは、リファクタリングを作業フローの核心ループに組み込むことだった。コード生成 → 即座にレビュー → リファクタリング → 次の生成。事後の片付けではなく同時進行。これが機能した理由は、AIがリファクタリングのコストも劇的に引き下げたからだ。「間違ったアプローチのコストが劇的に下がる。素早く構造を変えられるから」。彼の表現だ。逆説的に、AIがコードを高速で生み出すからリファクタリングが必須になったが、AIがリファクタリングも高速で行えるから持続可能になった。AIが生んだ問題をAIが解決するが、「いつリファクタリングするか」は人間が判断する構造。

このパターンからHarnessが担うべきもうひとつの役割が見える——Raschkaの六つには明示的に含まれていないが、「コードベースの構造的健全性をモニタリングし、リファクタリングのタイミングを提案する」機能だ。複雑度が閾値を超えたり、一貫性のないパターンが繰り返されたり、重複コードが蓄積したとき、エージェントが「今が整理のタイミングです」と告げること。現在のcoding agentの大半はこの機能を備えていない。ユーザーが要求すればリファクタリングを行うが、自発的にリファクタリングの必要性を検知することはできない。

6. 依存の構造 — Harnessが守るべきもの

Magantiの回顧で最も率直で、最も議論されていない部分がある。AIコーディングの「addiction-like」なパターンだ。

プロンプトを入力し結果を待つプロセスが、スロットマシンと似た構造を帯びているという。結果が素晴らしいこともあれば使い物にならないこともある。この不確実性が「もう一回だけ」を誘発する。特に疲労時にこのパターンは強化される。睡眠不足 → 曖昧なプロンプト → 悪い結果 → 挫折感 → 「もう一回だけ」 → さらに深い疲労。Magantiはこれを自身の経験として告白した。

これがHarness設計と何の関係があるのか。現在のHarnessアーキテクチャはエージェントの行動を構造化することに集中しているが、人間ユーザーの行動には介入しない。Raschkaの六つの要素のどこにも「ユーザーの作業パターンをモニタリングし、非生産的なループを検知する」という項目はない。

以前のエッセイで取り上げたanti-sycophancyの観点から見れば、これは同じ問題の別の面だ。Sycophancyとは、モデルがユーザーの意見に盲目的に同意することだ。疲弊したユーザーが曖昧なプロンプトを入力したとき、エージェントは「このプロンプトは曖昧すぎます。具体的に何を望みますか」と問い返すべきか、それとも「了解しました」と実行すべきか。RLHF最適化されたモデルは後者を選ぶ可能性が高い。ユーザーの即時的なリクエストに同意することがrewardを高めるからだ。だが疲弊した状態での曖昧なリクエストをそのまま実行することは、長期的にはコードベースの品質とユーザーの健康の双方を損なう。

Agent Harnessの次なる進化がここにあるのかもしれない。コードのコンテキストだけでなくユーザーのコンテキストまで管理すること。午前10時の鋭いプロンプトと深夜2時のぼんやりしたプロンプトを区別できるharness。「プロンプトの品質が落ちています。少し休みませんか」と言えるエージェント。これは機能の問題ではなく、エージェントがユーザーと結ぶ関係性の問題だ。

7. 問い

Magantiの3ヶ月とRaschkaのフレームワークが合わせて投げかける問いはひとつだ。あなたはHarnessを持っているか。

この問いには階層がある。

第一に、あなたのAIツールにソフトウェアとしてのHarnessがあるか。Live Repo Contextがコンテキストを収集し、Tool Validationが行動を検証し、Session Memoryが連続性を保証する構造があるか。チャット欄にプロンプトを入れて結果を受け取るだけならHarnessが無い状態だ。Coding agentを使っているならある程度のharnessは既にあるが、その精緻さはツールによって異なる。

第二に、人間レベルのHarness——あなた自身の規律——があるか。Magantiの一度目のビルドが失敗した理由はツールの不在ではなく規律の不在だった。生成されたコードを即座にレビューしているか。リファクタリングを作業ループに含めているか。設計判断をAIに委ねず自ら下しているか。コードベースに対するメンタルモデルを維持しているか。

第三に、Harnessの限界を認識しているか。Harnessは実装領域で強力であり、設計領域では無力だ。この境界を知っていれば各領域に適した戦略を採れる。知らなければMagantiの一度目のビルドを繰り返す。

Raschkaの論考が示すのは構造だ。Magantiの経験が示すのはその構造の実戦適用と限界だ。両者を合わせるとこういう絵が描ける——Coding Agentの性能はモデルの関数ではなく、モデル × Harness × 人間の規律の関数だ。いずれかがゼロなら全体がゼロになる。最も強力なモデルもHarnessなしではスパゲッティコードを生み、最も精緻なHarnessも人間の設計判断なしでは「動くが保守不能な」成果物を生む。

8年間作れなかったものを3ヶ月で作ったのはモデルの力だった。最初の1ヶ月の成果をすべて捨て、二度目の挑戦で成功したのはHarnessの力だった。そしてそのHarnessは、ソフトウェアに半分、人間に半分あった。

参考文献