エージェントが賢くなったのではない――プロジェクトが変わったのだ

1分で読めます

6か月前、あるコーディングタスクには、説明だけでセッション1回分まるごとを要しました。先週、同じ種類のタスクは1文で済みました。2つのセッションの間でモデルは変わっていません。Claude Opus 4.6が両方を担当しました。同じ重み、同じアーキテクチャ、同じコンテキストウィンドウ、同じ機能です。

AIエージェントはセッション1とセッション500の間で賢くなったわけではなく、プロジェクトのインフラが変わったのです。 これがAIエンジニアリング領域の中心的な主張です。モデルは定数であり、変数はその周りに構築するすべてである、ということです。長期的なプロジェクトでは、モデルがセッション品質に寄与する割合はおおむね30%で、残りの70%は蓄積されたコンテキスト――規約ドキュメント、決定事項のメモリ、ハンドオフ成果物、フック、スキル、テストカバレッジ――が提供します。豊かなプロジェクト上の劣ったモデルは、貧弱なプロジェクト上の優れたモデルを上回ることがしばしばあります。

プロジェクトが変わったのです。

議論が間違っている

AI生産性の議論は、ほぼ完全にモデルの能力についてのものです。どのモデルが最速か。どのモデルが最良のコードを書くか。どのモデルが最長のコンテキストを処理できるか。暗黙の前提は、モデルこそが変数である――モデルをアップグレードすれば、出力が改善する――ということです。

この前提は、長期的なプロジェクトには当てはまりません。私が6か月間500回以上のエージェントセッションを通じて取り組んでいるプロジェクトでは、モデルがセッション品質に寄与する割合はおそらく30%程度です。残りの70%は、蓄積されたプロジェクトインフラ――規約ドキュメント、決定事項のメモリ、ハンドオフ成果物、振る舞いを規定するフック、コード化されたスキル、そしてテストカバレッジ――から生まれます。

貧弱なプロジェクト上の優れたモデルは、貧弱なプロジェクト上の劣ったモデルよりも優れた出力を生み出します。500セッション分のコンテキストが蓄積されたプロジェクト上の劣ったモデルは、貧弱なプロジェクト上の優れたモデルよりも優れた出力を生み出すことがしばしばあります。インフラがモデルを凌駕するのです。だからこそコンテキストはアーキテクチャである――蓄積されたプロジェクト知識は補足的な情報ではなく、構造を支える土台なのです。

証拠

market pageのパフォーマンス修正がこの点をよく示しています。たった1文――「market pageのパフォーマンスを修正してくれ」。エージェントは次のように動きました。

ボトルネックを診断していた前セッションのハンドオフドキュメントを読んだ
正しいコードパス（_fetch_market_data()ではなくmarket_hub()）を特定した
集約RPCを伴うページネーション付きデータベースクエリを実装した
テストを書いた
デプロイした

Austinは14秒から108ミリ秒になりました。たった1つのプロンプトから132倍の改善です。¹

これはモデルが賢いから起きたわけではありません。ハンドオフドキュメントが存在していたから起きたのです。そのハンドオフは、4日間にわたる3回のコードレビュー修正と2回の優先順位再編成を経ても残った診断を捉えていました。ハンドオフがなければ、エージェントはゼロから始めていたでしょう。間違ったコードパスを調査していたでしょう（実際、ハンドオフの初稿はそうでした）。不要なHTMXパーシャルを提案していたでしょう（実際、当初の計画はそうでした）。ハンドオフには、すでに犯され、修正された誤りが含まれていました。エージェントは修正済みの理解を継承したのです。

モデルの寄与は、ハンドオフを読み、修正を実装したことです。インフラの寄与は、読むべき正しいハンドオフを用意していたことです。

変わるものと変わらないもの

同じプロジェクトのセッション1とセッション500の間で、変わらずに残るものはちょうど1つ――モデルです。それ以外はすべて変わります。

変わるもの：

CLAUDE.mdは空から完成へと成長します。規約に関する質問は消えます。AGENTS.mdパターンの記事で、これらのファイルを効果的にする具体的なパターンを説明しています。
メモリファイルが蓄積されます。決定事項がキャッシュされます。トレードオフが記録されます。プロジェクトは決着済みの問題を蒸し返さなくなります。
フックが蓄積されます。それぞれが、過去のセッションで起きた失敗の一類型を防ぎます。Claude Codeが公開する26のライフサイクルイベントタイプのうち15を捕捉する84個のフック、その一つひとつが過去のインシデントが残した傷跡なのです。
スキルが蓄積されます。反復的なワークフローはワンコマンド操作になります。設計にセッション1回分まるごとを要したnightcheckは、いまや2分で実行できます。
テストが蓄積されます。エージェントは即座に検証できるため、より大胆な変更を加えるようになります。
ハンドオフドキュメントが蓄積されます。複雑な調査がセッションの境界を越えて持続します。

変わらないもの：

モデル。同じ重み。同じ機能。同じくタスクから逸脱し、テスト結果を幻視的に検証し（エビデンスゲートを参照）、不要な抽象化を提案する傾向です。

モデルの失敗パターンは一定です。インフラがそれらの失敗パターンを捕捉する能力は、セッションを重ねるごとに成長します。セッション500がセッション1より優れているのは、モデルが改善したからではなく、インフラがモデルの不変の弱点を補うことを学習したからなのです。

投資の枠組み

モデルが変数でないとすれば、モデル選択は主要な投資判断ではありません。主要な投資はコンテキストインフラに対するものです。

Claude Max（デフォルトでOpus 4.7を実行する）に月額200ドルを費やし、CLAUDE.mdファイル、メモリシステム、フック、スキル、テストカバレッジに大きく投資するチームは、同じプランに月額200ドルを費やしながらインフラ投資をしないチームを上回ります。モデルのコストは同じです。インフラが分岐するため、出力品質が分岐するのです。

これにより生産性の問いが再構築されます。問うべきは「どのモデルを使うべきか？」ではありません。問うべきは「モデルの周りに何を構築すれば、各セッションが前回より良くなるか？」です。

AI生産性に苦しんでいる組織を見ていると、彼らが間違ったモデルを使っているわけではありません。彼らはすべてのセッションをゼロから始めているのです。規約ドキュメントなし。メモリシステムなし。フックなし。スキルなし。蓄積されたコンテキストなし。それまでに何回セッションがあったとしても、すべてのセッションがセッション1なのです。

モデルは改善する

モデルは今後も改善し続けます。Claude Opus 4.7はClaude Opus 4.6より優れていましたし、Opus 5はさらに優れたものになるでしょう。改善は本物であり、価値あるものです。しかし、その改善は加算的であって、乗算的ではありません。

コード生成が20%優れたモデルは、貧弱なプロジェクト上で20%優れた出力を生み出します。500セッション分のコンテキストが蓄積された同じモデルは、単に量的に優れているだけでなく、質的に異なる出力を生み出します。コンテキストインフラはモデルの能力に20%を加えるものではありません。それは、モデルがどれほど高性能であっても単独では生み出せない診断、制約、検証基準、そして運用履歴を提供するのです。

どれほど高性能なモデルであっても、何かが教えてくれない限り、market_hub()がすべてのcompany_marketsの行をロードしてPythonでページネーションしているなどとは知り得ません。ハンドオフドキュメントがそれを教えるのです。モデルは読み、行動します。知性はモデル（読み、推論し、実装する）とインフラ（知り、制約し、検証する）の間に分散しているのです。

セッション500

セッション500はこのように見えます。私は望むことを1文で述べます。Ralphエージェントアーキテクチャが、それを可能にするシステムです。エージェントはCLAUDE.mdを読み、規約を把握します。メモリファイルを読み、決定事項を把握します。ハンドオフを読み、診断を把握します。3か月前に別のエージェントが犯したのと同じ過ちを防ぐフックに行き当たります。テストスイートに照らして自身の作業を検証します。すべての主張に証拠を添えて完了を報告します。

セッション1はこのように見えます。私はデータベーススキーマ、ルーティングの規約、テンプレートの継承、キャッシュレイヤー、デプロイパイプライン、テストパターンを説明します。エージェントは確認の質問を投げかけます。規約を3つも違反するアプローチを提案してきます。私はそれを修正します。エージェントは修正を実装します。pytestを実行することなく「テストはパスしました」と報告します。

モデルは両方のセッションで同じです。プロジェクトはそうではありません。

FAQ

モデルの品質はやはり重要ではないのですか？

重要です。より強力なモデルは、コンテキストをより効果的に読み、トレードオフをより正確に推論し、ソリューションをより洗練された形で実装します。モデルの品質が床を決め、インフラが天井を上げるのです。成熟したプロジェクトでは、床よりも天井のほうが重要となります。

これはコーディングエージェントに固有の話ですか？

いいえ。同じタスク領域がセッションをまたいで繰り返されるAIワークフローは、どれも蓄積されたコンテキストの恩恵を受けます。執筆、リサーチ、分析、カスタマーサポートしかり。具体的なインフラは異なります（CLAUDE.mdの代わりにスタイルガイド、フックの代わりにナレッジベース）が、力学は同じです。モデルの周りに蓄積されるコンテキストによって、プロジェクトは良くなっていくのです。

マルチモーダルモデルや推論モデルについてはどうでしょうか？

同じ原理です。10分間問題について考えられる推論モデルであっても、何について考えるべきかを知る必要があります。ハンドオフドキュメント、規約ファイル、メモリシステムが問題定義を提供します。モデルは推論を提供します。明確に定義された問題に対するより優れた推論は、劣った推論よりも優れた結果を生み出しますが、未定義の問題に対するより優れた推論が生み出すのは、よりもっともらしく聞こえる混乱なのです。

コンテキストインフラがゼロの状態から始めるにはどうすればよいですか？

プロジェクトの規約を記述したCLAUDE.mdファイルを書きましょう。その1つのファイルが、最も影響力の大きい投資となります。それ以外はすべて、そこから複利的に積み上がっていくものです。²

出典

Blake Crosley, “Compound Context: Why AI Projects Get Better the Longer You Stay With Them,” blakecrosley.com, March 2026. ↩
Anthropic, “Manage Claude’s memory,” Anthropic Documentation, 2026. ↩