メンテナンスコストを下げられないAIに、価値はない

2026年5月10日

単刀直入に言おう。君がコードを書くために使っているその「AIコーディングエージェント」は、メンテナンスコストを削減できていなければならない。しかも、ちょっとやそっとの削減じゃ足りない。

もし今、以前の2倍の速さでコードを書いているなら、メンテナンスコストを半分にできていなければ計算が合わない。生産性が3倍になったなら、コストは3分の1だ。そうでなければ、君は詰んでいる。一時的なスピードアップと引き換えに、永続的な負債を背負い込んでいるだけなのだから。

なぜかって？まあ、落ち着いてくれ。少しドライブにでも出かけよう。暗い砂漠のハイウェイを……。

生産性を決めるのは、メンテナンスコストである

君が書くコードは、その1行1行すべてにメンテナンスが必要になる。バグ修正、クリーンアップ、依存関係のアップデート、云々。新機能の開発や機能強化の話ではない。純粋な「維持」の話だ。 ある月にコードを書けば、翌年にはそのコードを維持するために一定の時間を費やすことになり、その後もコードが存在し続ける限り、毎年毎年、永遠にその時間は奪われ続ける。

仮に、50人のエンジニアを集めて、メンテナンスコストがどれくらいかかるか聞いてみたとしよう。「群衆の知恵」というやつを使えば、そこそこ正確な数字が出るはずだ。1

1（自分で調査してみるのもいい。ただ、これから話す本質的な結論において、具体的な数値がいくつであるかはさほど重要ではないということが後でわかるはずだ）

その群衆は、こう答えるだろう。1ヶ月分のコードを書くごとに、必要なメンテナンス時間は……

• 1年目は10日間
• 2年目以降は、毎年5日間

もし君が執念深い性格なら、これらの見積もりが時間の経過とともに生産性にどう影響するか、スプレッドシートで何時間もかけてモデル化するかもしれない。こんな感じに。

グラフの説明：プロジェクトの経過時間に伴うメンテナンスコストの影響。横軸は月数（0〜120）、縦軸は付加価値を生む仕事に費やせる時間の割合（0〜100%）。「通常（Normal）」とラベルされた太い青線は100%から始まり、最初の12ヶ月で約65%まで急落、その後11年かけて12.5%まで緩やかに落ちていく。他の2本の線も似た軌跡を辿る。黄色の破線（メンテナンス半分）は約35%で止まり、赤の破線（メンテナンス2倍）は約5%まで落ち込む。各線が「生産性50%以下」になるポイントは、「通常」で31ヶ月、「メンテナンス半分」で68ヶ月、「メンテナンス2倍」だとわずか10ヶ月だ。

新規プロジェクトの最初の1ヶ月は最高だ。すべての時間を華やかな新機能の構築に注ぎ込める。

翌月は少しだけ輝きが失われる。ほんのわずかだが、前月のバグ修正や設計ミスの手直しに時間が持っていかれるからだ。3ヶ月目はもう少し増える。そして4ヶ月、5ヶ月、6ヶ月……。

最終的には、輝きなんてカケラも残らない。群衆の見積もりによれば、2年半後には時間の半分以上をメンテナンスに費やすことになる。10年も経てば、他のことはほとんど何もできなくなるだろう。

メンテナンスの見積もりを半分にできれば、生産性50%のデッドラインを3年先延ばしにできる。逆に2倍になれば、1年経たずにそのラインを下回る。

教訓は明白だ。生産的なチームを作りたいなら、メンテナンスコストを注視しなければならない。

あらゆるモデルは間違っている（が、役には立つ）

この数字、実感としてどうだろう？ 少なくとも僕はしっくりくる。 コンサルタントとしてのキャリアの中で、僕は末期のスタートアップを専門にしてきたが、彼らは皆、上のグラフ通りの問題を抱えていた。創業から5〜9年ほど経った頃、彼らは自分たちのチームが「何も成し遂げられなくなっている」ことに気づき、僕を呼ぶんだ。

実際のチームはグラフほどひどくないこともある。メンテナンスコストが低いのかもしれないし、あるいは……こっちの方が可能性が高いと思うのだが……コストは最悪なままで、問題を「誤魔化して」いるだけかもしれない。たとえば：

• すべてのバグを直すのをやめる。依存関係のアップグレードも無視する。
• チームが遅くなったら人を増やす。それでも足りないから、さらに増やす。
• すべてを投げ捨てて、ゼロから書き直す。

正確なメンテナンスコストの数値には議論の余地があるだろう。だが、全体的なモデルとしては正しいはずだ。業界を渡り歩いてきた人間なら、このグラフが真実だと知っている。時間が経つにつれて生産性が溶けていく様を、身をもって経験してきたはずだから。

これがAIと何の関係があるのか？

「大あり」だ。というか、それがすべてだ。

君のチームが、最新の最強エージェント型コーディングフレームワーク「Rock Lobster（ロック・ロブスター）」を使い始めたとしよう。なんと、コードのアウトプットが2倍になった！最高だ！ ただし、生成されたコードは少し理解しづらく、チームはプルリクの山に溺れている。君は「承認」ボタンを押す前に、正直コードをまともに読んでいないかもしれない。会議の合間に斜め読みする程度で、「まあ、いいでしょ！LGTM！」といった具合だ。

これで君は、1ヶ月で2ヶ月分の仕事をこなしている。そして、1ヶ月あたりのアウトプットに対するメンテナンスコストも2倍になったとしよう。 すると、翌月のメンテナンスコストは4倍に跳ね上がる。

グラフの説明：先ほどの「通常」の青線の上に、細い赤線（AIで生産性とメンテナンスが2倍）が重なっている。36ヶ月目で生産性は85%まで急上昇し、「AIが短期的に莫大な利益をもたらす」というピークを迎える。しかしその後、生産性はAI導入前より急速に低下し、「5ヶ月で利益が消失」というラベルが貼られる。その後の12ヶ月で青線より10%低い位置まで落ち込み、「長期的なペナルティ」として定着する。

……おっと。

Rock Lobsterを使い始めてから約5ヶ月で、生産性は導入前と同じレベルまで落ち込む。さらに数ヶ月経てば、Rock Lobsterに触れなかった方がマシだった、というレベルまで悪化するのだ。

別に「AIを使えばメンテナンスコストが2倍になる」と断定したいわけではない。生産性が2倍になるとも限らない。これは極端な例だ。 ただ、仮にAIが「人間と同等にメンテナンスしやすいコード」を書いたとしても、生産性の向上は長続きしないのだ。

グラフの説明：「通常」の青線に加え、細い赤線（AIで生産性2倍、メンテナンスは通常）が表示される。36ヶ月目で85%に急上昇するが、今回は下落が緩やかだ。それでも55ヶ月目にはAI導入前の水準を下回り（19ヶ月で利益消失）、86ヶ月目には累積でマイナス（40ヶ月で純損）に転じ、最終的には青線より数％低い位置に落ち着く。

いつでもチェックアウトできるが…… 2

2（だが、立ち去ることはできない。※『ホテル・カリフォルニア』の歌詞の引用ですね）

エージェントは高価だし、そのコストは上がる一方だ。エージェントを使う割が合わなくなったとき、君は節約のために「昔ながらのやり方」に戻ろうとするかもしれない。原始人のように。自分の指で。

は！残念だったな。エージェントの使用をやめても、生産性の向上という恩恵は消え失せるが、積み上がったメンテナンスコストは消えてくれない！ そのコードが生き残っている限り、君はエージェントに触れなかった場合よりも低い生産性に縛り付けられることになる。

グラフの説明：AIが生産性とメンテナンスを2倍にするモデルの再掲。60ヶ月目で「AIを削除（AI removed）」すると、グラフはさらに急落し、AIを使い続けた場合（赤の破線）よりも10%ほど低くなる。その後少し回復するが、最終的には「通常」の青線より5%悪い結果に終わる。

帰還への道

計算が成立するのは、LLMがメンテナンスコストを「コードの増加率の逆数」分だけ減少させたときだけだ。 アウトプットを2倍にし、その維持コストも2倍になれば、2×2でメンテナンスの手間は4倍になる。アウトプットを2倍にして維持コストを据え置いても、2×1でメンテナンスは2倍だ。

そうではなく、生産性を反転させなければならない。2倍のコードを生成するなら、維持コストが半分のコードが必要だ。3倍のコードなら、コストは3分の1。

これこそが成功の秘訣だ。ロックインされることなく、すべての恩恵を享受できる唯一の道である。

グラフの説明：今度の細い赤線（AIで生産性2倍、メンテナンス半分、後に削除）は、青線を下回らない。36ヶ月目で85%まで跳ね上がった後、青線より高い位置を維持し続ける。84ヶ月目で「AIを削除」すると、そこからは正確に青線の軌跡に戻る。

その「獣」を仕留められるか？

正直、わからない。僕が読んでいる最新のニュースによれば、コーディングエージェントはメンテナンスコストを「増加」させているようだ。巨大なシステムの理解を助けてくれると言う人もいる。だが、僕らが必要としているレベルの劇的なコスト削減？いや、そんな話は聞かない。むしろ逆だ。

これは問題だ。このモデルは現実の完璧な写し鏡ではないが、メッセージは正しい。君には、新機能の開発スピードに見合った分だけ、メンテナンスコストを削減してくれるAIが必要なのだ。 それなしでは、君は詰む。一時的なブーストのために、一生のタコ部屋行きを契約しているようなものだから。

だから、まあ、コードを書くスピードを追い求めるのは勝手にすればいい。だが、同じくらい情熱を傾けてメンテナンスコストの削減も追求するんだ。さもないと、君も「ホテル・カリフォルニア」に囚われることになる。

なんて素敵な場所。 なんて素敵な表情。

……と、ここまで散々言ってきたが、別にAIアンチの暴論を吐きたいわけではない。 コード自体の保守性を上げられなくても、「メンテナンス作業自体の生産性を上げるAI」のような、別のレバーも存在するはずだ。 ぜひ、このスプレッドシートをコピーして、モデルのレバーをいろいろいじってみてほしい。君の現実の状況に合わせて前提条件を変えたとき、何が起きるかを確かめるんだ。

僕のコンテンツはすべて、100%人間の生身の脳で作られている。この記事が気に入ったら、僕の他の執筆物やプレゼンもチェックしてみてくれ。メールやRSSでの購読も大歓迎だ。