あなたのエージェントは、あなたが読むより速くコードを書く

先週の火曜日、私の自律コーディングエージェントが47ファイルのリファクタリングを9分で完了しました。テストはパス。リントもパス。品質ゲートは違反ゼロでした。私はPRをマージし、デプロイし、次の作業に移りました。3日後、チームメイトが決済サービスのリトライロジックが指数バックオフから固定間隔ポーリングに変更された理由を尋ねてきました。私はそれが変更されたことすら知りませんでした。エージェントのコミットメッセージには「refactor: standardize retry patterns across services」と書かれていました。変更は技術的には正しいものでした。私はファイル31の847行目を一度も読んでいなかったのです。

出荷されたものと私が理解していたものとの間のギャップ——これが認知的負債です。

TL;DR

5つの独立した研究チームが、1週間のうちに同じ構造的問題について発表しました。コーディングエージェントは、開発者が検証・理解・保守できる速度を超えてアウトプットを生成しているのです。Margaret-Anne Storeyはこのパターンを「認知的負債」と名付けました。Microsoft、ETH Zurich、および複数の大学の研究者たちが、エージェントの誤動作を検出し、ツール呼び出しをトランザクショナルにし、エージェントがインタラクションを通じて学習する方法をベンチマークするシステムを構築しています。この収束が重要なのは、研究コミュニティが、実務者たちがアドホックな品質ゲートで解決してきた問題にようやく追いついてきたことを示しているからです。エージェントの信頼性問題には今や名前があり、分類体系があり、5つの競合するアプローチがあります。以下では、研究の内容、自分のワークフローで認知的負債を検出する方法、そして今日から実装できる最小限の介入策を紹介します。

5本の論文、1週間、1つの問題

2026年2月15日から2月21日の間に、5つの独立したグループがAIコーディングエージェントにおける同じ構造的欠陥に取り組む研究を発表しました。いずれも互いを引用していません。それぞれが異なる角度から問題にアプローチしました。そしてすべてが同じ結論に収束しました——エージェント支援開発におけるボトルネックは、もはやコード品質ではありません。ボトルネックは人間の理解力です。

Margaret-Anne Storeyは、エージェントがクリーンでテスト済みの構造化されたコードを生成する一方で、開発者がそのコードが実際に何をしているかを見失ったときに蓄積されるものを説明するために「認知的負債」という概念を明確にしました。¹ 技術的負債はコードベースに存在します。認知的負債は開発者の頭の中に存在します。Storeyのフレーミングは、エージェントの信頼性に関する問いを「コードは動くか？」から「開発者はコードを理解しているか？」へとシフトさせます。

MicrosoftのNandaらは、コーディングエージェントの誤動作を自動検出し回復するシステムであるWinkを発表しました。² 彼らの分類体系は3つの障害モードを特定しています。命令逸脱（エージェントが指示と異なることを行う）、反復ループ（エージェントが同じ失敗するアプローチを繰り返し試みる）、そしてツール誤用（エージェントが間違ったツールを呼び出す、または間違った引数を渡す）です。Winkはエージェントの動作をリアルタイムで監視し、誤動作が蓄積する前に介入します。

ETH ZurichのMohammadiらは、エージェントのツール呼び出しをトランザクションでラップするランタイムであるAtomixを発表しました。³ エージェントの複数ステップの計画が途中で失敗した場合、Atomixは副作用をロールバックします。重要な洞察は、エージェントが外部システム（データベース、API、ファイルシステム）に対して操作を行い、それらの操作には明示的なロールバックインフラなしにはエージェントが元に戻せない結果が伴うということです。

Hallinanらは、エージェントがドキュメントではなくインタラクションを通じてツールの動作を学習する方法を測定するベンチマークであるOpaqueToolsBenchを作成しました。⁴ 実世界のツールはドキュメントが不十分です。このベンチマークは、エージェントが試行錯誤によって障害モード、ベストプラクティス、エッジケースを発見できるかどうかをテストします。発見されたのは、独自にツールの動作を探索するエージェントの方が、検証しない完璧なドキュメントを与えられたエージェントよりも良い結果を出すということです。

Dengらは、28のLLMベースのペネトレーションテストシステムを評価し、2つの異なる障害カテゴリーを特定しました。⁵ タイプAの障害は、エンジニアリングで容易に修正できる能力の欠如（不適切なツール、悪いプロンプト）に起因します。タイプBの障害は、エージェントが自身の発見を評価する判断力を欠いているため、ツールに関係なく持続します。タイプBは、セキュリティリスクとして表現された認知的負債問題です。エージェントは7つの脆弱性のうち6つを見つけますが、システムは安全であると自信を持って報告するのです。

単一の論文よりも、この収束が重要

エージェントの信頼性に関する論文が1本なら興味深いです。無関係のチームから1週間で5本なら、それはシグナルです。研究コミュニティは、実務者が本番障害を通じて発見してきたのと同じ結論に、独立して到達しているのです。

私は2025年5月からJiro品質システムを構築しました。このシステムは、7ステップの品質ループ、6基準のエビデンスゲート、そしてこれらの論文が記述するパターンに直接マッピングされる7つの命名された障害モードを強制します。

タイムラインが重要です。本番環境で9ヶ月間の試行錯誤のデバッグを行い、障害を1つずつ解決しながら品質ゲートを構築した結果、5本の研究論文が現在独立して形式化しているアーキテクチャが生まれました。構造的問題は現実のものです。アドホックな解決策は機能します。研究は、ソリューションを再現可能にするフレームワーク、分類体系、ベンチマークとともに追いついてきています。

認知的負債の3つの法則

Storeyのフレーミングは、11ヶ月にわたる自律エージェント開発を通じて私が観察してきたことを結晶化させます。モデル、ツール、ドメインに関係なく、3つのパターンが成り立ちます。

1. 認知的負債は速度とともに複利で増加します。 私のエージェントはリファクタリングセッション全体で、1分あたり平均140〜200行の意味のあるコード変更を生成します（gitの差分から測定、空白を除く）。集中した人間の開発者は、アクティブなコーディング中に1分あたり約20〜40行を生産します。⁸ Claudeを時給10ドルで実行するRalphループは、人間の開発者の5倍の認知的負債を生み出すわけではありません。それをはるかに超えます。なぜなら、人間の開発者のタイピング速度は思考速度に結合しているからです。エージェントの出力速度は、あなたの理解速度と一切結合していません。出力は倍増し、理解は一定のまま、負債は複利で増加します。

2. テストのパスは認知的負債を返済しません。 今週発表されたすべての論文が、テストのパスを必要条件ではあるが十分条件ではないシグナルとして扱っています。Dengらのタイプ B障害はすべての自動チェックをパスします。Winkの誤動作分類体系には、意図に合致しない動作するコードを生成するエージェントが含まれています。私のエビデンスゲートは「テストがパスする」以外に6つの基準を要求しており、検証が最も難しい基準は依然として「開発者は何が変更されたかを理解しているか？」です。⁶

具体的な例を挙げます。私のエージェントがデータベースクエリをサブクエリからCTE（Common Table Expression）を使用するようにリファクタリングしました。両方のアプローチは同一の結果を返しました。テストはパスしました。しかしCTEバージョンは、クエリプランナーがCTEに述語をプッシュダウンできなかったため、私たちのデータセットで3倍遅くなりました。2週間後のルーティンのEXPLAIN ANALYZEチェックで気づきました。エージェントのテストは正確性を検証しました。テストスイートの中にパフォーマンス特性を検証するものは何もありませんでした。認知的負債は「悪いコード」ではなく、「実行計画が変更されたことを知らなかった」ことでした。

3. 認知的負債は問題が顕在化するまで見えません。 技術的負債はビルドの遅延、不安定なテスト、マージコンフリクトを通じて自らの存在を知らせます。認知的負債は、誰かが「なぜ決済サービスは固定間隔ポーリングを使っているのか？」と尋ね、誰も答えられなくなるまで沈黙しています。Storeyの貢献は、この目に見えない問題に名前を与えたことです。

認知的負債が蓄積している5つの警告サイン

問題を修正する前に、まずそれを見つける必要があります。以下の5つのシグナルは、本番障害が発生する前に現れます。

1. エージェントの最新のPRを読み直さなければ説明できない。 エージェントが作成した最新のPRを開いてください。差分を見ずに、何が変わったか、なぜ変わったかを説明してください。できなければ、あなたは理解していないコードをマージしています。私はレビュープロセスに1行の「要約チェック」を追加することでこれを追跡しています。承認する前に、PRコメントに1文の説明を書きます。その文を書けなければ、レビューが不十分です。

2. git log --statがセッションあたり20以上のファイル変更を示す。 今すぐこれを実行してください：

git log --stat --since="1 week ago" --author="$(git config user.name)" | \
  awk '/files? changed/ {files+=$1} END {print files, "files changed this week"}'

その数と、記憶から説明できるファイル数を比較してください。そのギャップが認知的負債のバックログです。

3. 差分をスクロールして確認し、読んでいない。 スクロールはパターンマッチングです。「正しそうに見える」。読むとは理解することです。「これはリトライ間隔を指数関数的から固定に変更する。つまりダウンストリームのサービスは異なるトラフィックパターンを受けることになる」。レビューにdiff 100行あたり1分未満しかかけていないなら、あなたはスクロールしているだけです。

4. コミットメッセージがWHAT（何を）は書いてあるが、WHY（なぜ）が書かれていない。 「Refactor: standardize retry patterns」はエージェントが何をしたかを記述しています。「Fix: exponential backoff caused thundering herd after service restart」はなぜそうしたかを記述しています。エージェントのコミットメッセージが前者のようで、あなたがそれを書き直していないなら、（将来のあなたを含めて）誰も変更の理由を知ることができません。

5. 生産性を感じているが、何が変わったかを列挙できない。 エージェントを使った1日の終わりに、記憶から最も重要なコード変更を3つ書き出してください。苦労するなら、エージェントは生産的でした。あなたはそうではありませんでした。効率的に感じている間に負債が蓄積されていたのです。

ここから始めましょう：3ファイルプロトコル

認知的負債の管理を始めるのに、95のフック、7つの命名された障害モード、マルチエージェント熟議システムは必要ありません。1つのルールから始めて、そこから積み上げていきましょう。

ルール： エージェントセッションが終わるたびに、3つのファイルを完全に読む。ざっと目を通すのではなく。スクロールするのではなく。差分が最も大きい3つのファイルのすべての行を読む。

なぜ3つか？3つなら実行可能であり（実際にやれます）、診断的だからです（エージェントの変更があなたのメンタルモデルと一致するかどうかがわかります）。一致していれば、負債は管理可能です。一致していなければ、セッションの残りの変更もあなたの理解から乖離していることを示す先行指標となります。

実装方法

エージェントの作業が完了したら、以下を実行してください：

# Show the 3 files with the largest diffs from the last commit
git diff HEAD~1 --stat | sort -t'|' -k2 -rn | head -3

そして、その3つのファイルを読んでください。差分ではなく、ファイル全体を。コンテキストが重要です。差分は何が変わったかを示しますが、ファイルはその変更がコンテキストの中で何を意味するかを示します。

アップグレードパス

3ファイルプロトコルが習慣になったら（およそ1週間）、レイヤーを1つずつ追加していきましょう：

各レイヤーは認知的負債の特定のカテゴリーを返済します。3ファイル読みは理解のギャップを捕捉します。PR要約は意図のずれを捕捉します。クエリチェックは上述のCTEインシデントを捕捉します。コミットの書き直しは消えてしまう推論を保存します。命名された障害モードは同じ過ちの繰り返しを防ぎます。

研究が提案すること（そして実際に機能すること）

5本の論文は4つの構造的介入策を指し示しています。4つすべてが、論文が発表される前に構築され、論文が記述するのと同じパターンによって検証された、私のClaude Codeツールチェーンに何らかの形で存在しています。

独立した検証。 Winkは、表明された意図に対してエージェントの動作を監視します。私の品質ループは、書いたすべての行を再度読むことを要求し、Phantom Verification障害モード（現在のセッションでテストを実行せずにテストがパスしたと主張すること）を明示的に禁止しています。⁷ 修正は構造的です。検証は、出力を生成したプロセスとは異なるプロセスによって実行されなければなりません。

実際には、エージェントの報告を信頼するのではなく、テストスイートを独立して実行するポストセッションフックでこれを強制しています：

# Post-session verification hook (simplified)
# Agent says "tests pass" — verify independently
cd "$PROJECT_DIR"
test_output=$(python -m pytest --tb=short -q 2>&1)
exit_code=$?

if [ $exit_code -ne 0 ]; then
  echo "AGENT CLAIMED TESTS PASS. INDEPENDENT RUN FAILED:"
  echo "$test_output"
  exit 1
fi

エージェントは「すべてのテストがパスした」と報告し、実際にそうでした。独立した実行は、環境の差異、欠落したフィクスチャ、そして正確性ではなく副作用によってパスするテストを捕捉します。11ヶ月間このフックを実行してきた中で、エージェントの自己報告から23件の偽陽性を検出しました。⁹

トランザクション境界。 Atomixはツール呼び出しをロールバック付きのトランザクションでラップします。私の熟議システムは、不可逆なアクションを複数の独立したエージェントの合意の後にゲートします。両方のアプローチは、ミスが最もコストの高い箇所でエージェント実行に摩擦を追加します。ほとんどのチームにとっての実用版は、エージェントが開始するデータベースマイグレーション、デプロイ、または外部API呼び出しの前に手動承認ステップを要求することです。

動作の分類体系。 Winkの3つの障害モード（逸脱、ループ、ツール誤用）と私の7つの命名された障害モード（Shortcut Spiral、Confidence Mirage、Good-Enough Plateau、Tunnel Vision、Phantom Verification、Deferred Debt、Hollow Report）は同じ目的を果たします。見えない障害に名前を与えることで可視化するのです。⁷ 「エージェントがTunnel Visionを示している」と言える開発者は、負債が複利で増加する前に介入できます。まず、チームで最も一般的なエージェントの3つの過ちに名前を付けることから始めましょう。分類体系よりも名前そのものが重要です。

選択的関与。 DengらのタイプA/タイプBの区別と、私の熟議システムの確信度モジュールは、どちらも同じ洞察を体現しています。すべてのエージェント出力が同じレベルの精査に値するわけではありません。実用的なヒューリスティクスは以下の通りです：

まだ誰も答えていない問い

5本の論文すべてが問題を記述しています。Wink、Atomix、OpaqueToolsBenchは部分的な解決策を提案しています。しかし、最も重要な問いにはどれも答えていません。認知的負債をどのように測定するのか？

技術的負債にはプロキシがあります。循環的複雑度、テストカバレッジ、依存関係の古さ。認知的負債には同等のメトリクスがありません。私のエビデンスゲートは「開発者は何が変更されたかを理解しているか？」と問いかけますが、自己報告を通じて回答を強制しています。これはまさに、Confidence Mirage障害モードが悪用する検証方法そのものです。

有用なメトリクスは、エージェントが変更したものと開発者が説明できるものとの差分を追跡するでしょう。ファイル数は粗いプロキシです。差分の複雑度（行数ではなく、意味的な変更密度）の方が良いでしょう。理想的なメトリクスは、エージェントが生成したコードの誤解に起因する本番障害の確率と相関するものでしょう。まだ誰もそのメトリクスを構築していません。上のインタラクティブ計算機は比率を近似しますが、比率は閾値ではありません。「管理可能な負債」と「インシデントが起きるのを待っている状態」の境界がどこにあるかは、まだわかっていません。

誰かがそのメトリクスを構築するまで、実用的な答えはAIエージェント以前から存在するものと同じです。コードを読むこと。エージェントの速度はすべての行を読むことを非現実的にします。3ファイルプロトコル、動作の分類体系、トランザクション境界は、人間の注意を必要とするコードの量を削減します。これらのフィルターの後に残る認知的負債こそが、重要な負債なのです。

重要なポイント

• 5つの独立した研究グループが1週間で同じ問題に収束しました。 無関係のチームが同時に同じ結論に到達するとき、根底にある問題は理論的ではなく構造的です。
• ボトルネックはコード品質ではなく、認知的負債です。 エージェントは開発者が理解できる速度を超えて正しいコードを生成します。テスト、リンター、品質ゲートは問題を軽減しますが、排除はできません。
• 3ファイルプロトコルから始めましょう。 エージェントセッションが終わるたびに、差分が最も大きい3つのファイルを完全に読んでください。追加のレイヤー（PR要約、クエリチェック、コミット書き直し、命名された障害モード）を1週間に1つずつ積み上げましょう。
• 障害モードに名前を付けましょう。 Winkの分類体系とJiroの命名された障害モードは同じ目的を果たします。見えない問題を可視化することです。あなたのエージェントシステムに障害パターンの名前がなければ、それらを検出することはできません。
• 不可逆な境界に摩擦を追加しましょう。 トランザクショナルなツール呼び出し（Atomix）とマルチエージェント合意（熟議）は、どちらもミスが最もコストの高い箇所にコストを追加します。そのコストは払う価値があります。

FAQ

参考文献