AIコーディングエージェントはコードを書くよりも保守コストを下げるべき

90秒でリポジトリに800行ものコードを投入してくれるコーディングエージェントは、作業がはかどっているように感じます。けれども半年後、午前2時に呼び出されて、未使用の抽象化レイヤーのデバッグや一貫していないエラーハンドリングの調整をすることになると、同じエージェントは高くつく存在に見えてきます。James Shoreは最近のエッセイで、率直にこう述べています。AIコーディングツールの価値は、どれだけ速くコードを書くかではありません。結果として得られるコードベースを、生かし続けるためのコストがどれだけ低いかです。

私たちは、Copilot、Cursor、Claude Codeに同じメンテナンス重視のワークフローを実行しました。30ファイル以上に及ぶリファクタ、レガシーモジュール内のバグ修正、そして既存のパターンの上に積み重ねる段階的な機能追加です。結果は、1分あたりの行数を売りにするマーケティングが示唆するものとは違いました。

メンテナンスが、ソフトウェアが実際にあなたに請求してくる場所だ

業界の見積もりでは、メンテナンスはソフトウェアのライフサイクル総コストの60〜80%を占めており、その比率は数十年にわたる研究を通じて驚くほど安定しています。1970年代のLehmanの法則から、2000年代のGlassの調査までです。その理由は機械的なものです。コードは、書かれるよりも、およそ一桁多い頻度で読まれ、デバッグされ、変更されます。重複したロジック、不統一な命名、説明のない分岐、フィットしていない抽象化など、読み取りや変更のコストを増やすものは、ファイルの生涯にわたって増幅し続けます。

タイピング速度を2倍にする一方で、レビューと修正に1.5倍の時間がかかるコードを生み出すAIエージェントは、結局のところ帳尻が合わず、課税のようなものです。不快な計算ではありますが、避けられません。

AIエージェントが静かに負債を積む場所

ほとんどのAIコーディングツールの初期設定は、ひとつの指標に最適化されています。ユーザーが提案を受け入れたかどうかです。この指標が評価するのは、差分のレベルでもっともらしく見える生成であって、コードベースに適合する生成ではありません。

私たちが繰り返し目にした具体的な失敗パターンは以下の通りです。

• 関数レベルでのコピペ。 既存のヘルパーを再利用するのではなく、エージェントが新しいバリアントをインラインで書きます。その結果、コードベースには微妙に異なるformatCurrency関数が3つできてしまい、どれもさりげなく分岐していきます。
• 不可能な入力に対する防御的コード。 投げることができないコードに対するtry/catch、型シグネチャで必須のパラメータに対するnullチェック、到達不能な分岐に対するフォールバック。どれも読み取り負荷を増やし、実際には一度も発火しません。
• 規約の不一致。 リポジトリは早期returnを使います。エージェントはネストしたifを書きます。リポジトリはロガーを1つ使っています。エージェントは2つ目をimportします。レビュアーは修正するか（コストを払う）、そのまま通すか（負債を先送りする）になります。
• コードを言い直すだけの冗長なコメント。 // increment counter が counter++ の上に書かれています。こうしたものは信頼されることもなく、誰も削除しないままノイズとして年を重ねていきます。
• モックを動かすテスト。 生成されたテストは多くの場合、被テスト対象をモックし、モックが返す値をアサートして緑になります。カバレッジは上がりますが、確信は上がりません。

これらのパターンは、AIに特有のものではありません。問題は、AIがそれらを“規模”として生成し、マージされそうに見えるPRの中に入れてしまうことです。

最も高くつくAI生成コードの形は、「マージして問題なさそうに見える」一方で、コードベースのパターンに合っていないものです。レビュアーは、それを修正するか（今この瞬間にコストを払う）そのまま通すか（永遠にコストを払う）になります。「エージェントが書く前にファイルを読んだかどうか」を、一次級の評価基準として扱ってください。

Copilot、Cursor、Claude Codeがメンテナンスでどう違うか

これらのツールは似た基盤モデルの上にありますが、文脈（コンテキスト）に関する判断がまったく異なります。

Copilotのインエディタ補完は、カーソルの直近の周辺に最適化されています。他の場所にあるパターンを取り込むことはほとんどないため、何マイル（数フォルダ）も離れたところに既にあるヘルパーを、平気で作り直します。確立されたコードベースでのメンテナンス作業において、その初期設定はまさに間違っています。

Cursorは初期の段階で、コードベースのインデックスをもとにフルリポジトリのコンテキストを扱うようにしました。@でファイル参照したり、エージェントモードで複数ファイルにまたがる変更を計画させたりすると、新しい抽象化を生成するよりも、既存の抽象化を見つけて再利用する傾向があります。代償として、提案ごとの速度は遅くなり、さらにコンテキスト機能を能動的に使う必要があります。accept-the-ghost-textモードは、結局Copilot風の挙動にフォールバックします。

Claude CodeはCLIとして動作するエージェントで、別の運用モードになっています。書き込む前にファイルを読み取り、多くの場合、かなり積極的に読みます。同じリファクタ作業でも、私たちはClaude Codeが変更提案の前に周辺コンテキストとして約十数ファイルを読んでいるのを観察しました。一方Copilotは実質的に1ファイルしか読んでいません。出力はより保守的で、既存のスタイルとも整合しており、レビューしやすくなります。

これは一枚岩の推奨ではありません。Claude Codeはタスクごとに遅く、費用も高く、些細な変更では過剰に読み込むことがあります。言いたいのは、「AIコーディングエージェント」は一様なカテゴリではないということです。出力のメンテナンス負荷は、ツールが書く前にどの程度コンテキストを集めるかに強く依存します。

より良い評価フレームワーク

生成された行数や受け入れられた提案数でAIツールを測るのをやめましょう。実際に追跡できるメンテナンスの代理指標で測ってください。

• AI支援付きPRあたりのレビュー反復回数。 レビュアーが一貫して変更を求めるなら、ツールはコードに合うものを生成できていません。非AIのPRと比較して基準値を作りましょう。
• マージまでの時間。 書くよりマージするまでの方が時間がかかるPRは、負債のシグナルです。
• マージ後30日以内のバグ発生率。 きれいに出荷されたのに後で壊れるAI生成コードは、最悪の負債カテゴリです。
• 6か月後の変更数（タッチ回数）。 2四半期以内に書き直されたり、大幅に修正されたコードは、そもそも完成していません。単に出荷しただけです。

これらの数値は容赦がありません。私たちは、AI支援付きPRが人手で書かれたものより明確にレビュー反復回数が多いチームや、30日間のバグ率がAI群で高い方向に推移するケースを見てきました。ツールは受け入れ（acceptance）指標では「成功」していましたが、私たちが気にしているあらゆるメンテナンス指標では、結局は損失でした。

生産性の主張として正直なのは、マーケティングが言うほど広くありません。AIコーディングエージェントは、新規に作るコード（greenfield）、使い捨てスクリプト、うまく切り離された追加については明らかにプラスです。一方で、既存のコードベースでは、その影響は「どのツールを、どう使い、どれだけレビューの規律を保てたか」に大きく依存します。もしあなたのチームのレビュー手順が、AI出力をジュニアエンジニアの最初のPRと同じ扱いにする—注意深く読み、合わないコードには反論する—なら、メンテナンスの計算が成り立つ可能性はあります。逆に、AI出力を「たいていは問題ない」と扱っているなら、機械の速さで負債を積み上げていることになります。