2026/05/11 8:39
保守コスト削減に寄与する AI が不可欠です。
RSS: https://news.ycombinator.com/rss
要約▶
日本語訳：
本稿は、人工知能コーディングエージェントが長期的な生産性を維持するためには、コード生成の増加に比例したメンテナンスコストの削減が行われる必要があると論じています。このバランスが存在しなければ、チームは避けられないシステム腐敗および永続的な効率低下に直面します。核心的な問題は、すべてのコード行にバグ修正と依存関係のアップグレードのための無限期間の保守が必要であることであり、したがって、メンテナンスコストを劇的に削減しない限り、生産性は 2.5年後時点で 50%未満へと低下します。単純に出力を二倍にしても高コストを維持すれば、総負担は四倍となり、これは技術的負債の蓄積によって 5〜9年後の遅れ期スタートアップが不機能となることにより実証された罠です。将来の見通しでは、戦略的なコスト削減措置なしに生産性が急速に悪化し、10年以内にゼロに近づくと警告されています。最も重要なのは、高メンテナンスのレガシーコードが永久的に残存するため、後から高価なエージェントを廃棄しても失われた効率を取り戻すことはできないという点です。したがって、持続可能な成功はコーディング速度と AI 使用（特にメンテナンスタスク向け）のバランスによるものであり、出力が増加するにつれてコストを低下させ、会社を管理不可能な技術的負債および不機能のチームへの罠に陥らせるのを防ぐことが求められます。
本文
要点をストレートに申し上げます。貴社がコードを作成するために利用している AI コーディング・エージェントは、維持コストの削減が必要不可欠です。わずかの削減では十分ではなく、重要度を誇張するほどです。現在、貴社のコード作成速度が 2 倍になったのであれば、維持コストも少なくとも半分にできることを願いますが、そうではありませんね。生産性が 3 倍向上した場合は、維持コストを 3 分の 1 にする必要があります。さもなくば、貴社は困ることになります。一時的なスピード向上に対し、永続的な束縛（indenture）を選んでいるのですから。
「どうしてでしょう？」とのご質問でしょうか。もちろん、なぜそうなるのかをお話ししましょうか……暗い砂漠のハイウェイをドライブしましょうか……
生産性は維持コストによって決定される
あなたが書かれたすべてのコード行は、保守の対象となります：バグ修正、リファクタリング、依存パッケージのアップデートなどがそうです。ここでは新機能や機能強化の話ではありません。あくまで「保守」です。コード開発に費やした 1 ヶ月分について考えると、翌年にはそのコードを維持するにあたり一定量の時間を、そして以降も毎年同様に時間を費やすことになります。それは、そのコードが存在している限り、永続的に続くものです。
さて、50 名の開発者という群衆に対して、これらの維持コストはいくらでしょうかと問いかけ、それを回答させたところを想定しましょう。「群衆の叡智」と呼ばれる手法を用いることで、それなりの精度で答えを得ることができます。
「ご自身でも『群衆の叡智』に関するアンケート調査を実施いただけますが、結論としては、ここで私が論じる全体的なポイントにとっては、具体的な数値は重要ではありません。」
貴方の群衆が示唆するのは、おそらく次のような内容でしょう：
- コード開発に費やした 1 ヶ月分に対して、翌年には保守に 10 日、
- その後は各年度、それぞれ 5 日を費やす。
特に執念深い方であれば、これらの推定値が時間の経過とともに生産性に及ぼす影響をシミュレーションするためのスプレッドシートを作成し、何時間も費やすかもしれません。（この曲線を示したチャートを想像してみてください。）
新規プロジェクトの最初の月は快晴です。あなたはすべての時間を、洗練された新機能の実装に充てています。
その次の月は少し退色します。わずかな時間ですが、1 ヶ月目にデザインミスやバグを修正し、クリーンアップする分に割かれます。3 ヶ目目もまた、さらに少しだけ、4 ヶ月目、5 ヶ月目、6 ヶ月目……と、その割合は増加していきます。
やがて、それはもはや「快晴」ではなくなります。群衆による維持コストの推定に基づけば、プロジェクト開始から 2 年半を過ぎたあたりで、あなたの時間は半分を超えて保守に費やされることになります。10 年後には、ほとんど別のことをする余裕さえない状態になります。
群衆による維持コスト推定の半分であれば、50% の水準に至るまであと 3 年と見込みます。逆に 2 倍の場合には、それを下回るまで不足は 1 年にも満たない時間です。
教訓は明白です。生産的なチームを構築するには、彼らの維持コストに焦点を当てる必要があるのです。
すべてのモデルは不正確である
これらの数値、貴方にも合致しますか？私にはそう感じられます。コンサルタントとしての私のキャリアにおいて、私はスタートアップの最終段階を専門分野としていました。そして彼ら全員が、上記のグラフで示された問題に直面していました。事業開始から約 5〜9 年後に、チームがもはや成果を挙げられなくなってきたことに気づき、私のもとに相談を持ちかけました。
実際のチーム状況は、このグラフほど深刻ではなかったかもしれません。維持コストの方が低かっただけなのか、あるいは……これこそがより可能性が高いように思いますが……維持コストはまさにその程度には悪化しており、彼らは問題の表面を覆うだけだったのかもしれません。例えば、以下のような対応を行った可能性があります：
- すべてのバグを修正せず、すべての依存関係をアップデートしなかった。
- チームが遅れるたびに人材を増員し、それが十分でないと判断すればさらに増やした。
- 全て廃棄し、書き換え（リファクト）からやり直した。
維持コストの数値については議論の余地がありますが、全体としてモデルは現実を正しく表していると感じています。社会経験豊富な方は、このグラフが真実であることを認識されています。生産性が時間の経過とともに溶け去る様子をご覧になったことのあるはずです。傷跡をお持ちの方こそ、そのことを知っておられます。
これは AI とどう関連するのでしょうか？
実はすべてです。
さて、貴社のチームがいよいよ最新の代理型コーディングフレームワークである「ロックロブスター（Rock Lobster）」を導入し開始したとします。するとコード生産量は 2 倍になります！大成功でしょう！ただし、そのコードは少し理解しにくく、チームはプルリクエストに溺れています。おそらくあなたも、承認ボタンを押す前にコードを完全に確認していないかもしれません。「いや、少なくとも読んでいない」ということまでありますね。つまり、退屈な会議の隙間にざっと目を通した程度で、「これで十分だ」と思い込んでいるのかもしれません。LGTM（Looks Good To Me）、やろう！
こうなると、1 ヶ月分の作業を 1 ヶ月に終わらせ、それぞれの「1 ヶ月分」の出力にかかる維持コストも 2 倍になっている状態です。すると、翌月の維持コストはさらに 4 倍になります。
（この下降を示す別のチャートを想像してみてください。）
おっと。
ロックロブスターを採用してから約 5 ヶ月後には、貴社の生産性は当初の水準に戻り、さらに数ヶ月経つと、ロックロブスターに触れた場合よりももはや悪い状態になっています。
ここでは AI が維持コストを 2 倍にしたり、生産性を低下させたりするわけではありません。これは極端な例です。ただし、AI が人類が書かれたコードと同様に保守しやすいコードを生み出していたとしても、生産性の向上効果は持続しません。
（最終的なチャートでネットロスを示すイメージを描いてみてください。）
いつでも退出できます
しかし、一度入れば、出ていけないのです。
エージェントは高額であり、しかもその金額はますます高騰しています。やがて、エージェントのコストに対する価値が見えなくなると、あなたは貯金を節約して、昔ながらのコーディング方法に戻るかもしれません。例えば、穴門人のようには。指で書くように。
ハ！冗談です！あなたがエージェントの使用を止めた時、すべての生産性利得は失われます……しかし、追加された維持コストはそのままです！コードが存在している限り、エージェントを使用していなかった場合よりも低い生産性に縛り付けられています。
復帰の道
この式が成立するのは、LLM が貴社の維持コストを削減し、かつ新規に生み出すコードの増加率と正確な逆比例関係にある場合のみです。例えば、出力量を 2 倍にし、その維持コストも 2 倍にした場合、「2 かける 2」で維持コストは 4 倍になります。逆に、出力量を 2 倍に保ちながら維持コストを一定に抑えたいのであれば、「2 かける 1」でも結果として維持コストは 2 倍になります。
したがって、貴方は生産性を「逆転」させる必要があります。コード生産量が 2 倍の場合には、維持コストを半分にするコードが必要であり、3 倍のコードを生産する場合には、維持コストを 3 分の 1 にすることが必要です。
これが成功への秘密です。すべての利点を持ちながら、ロックイン（縛り付け）はゼロ。
怪我人を撃つことはできるか？
私は知りません。最新の信頼できるニュースソースを読む限り、コーディング・エージェントは維持コストを増加させると言われています。一部の人は、それにより大規模なシステムを理解しやすくなると述べていますが、必要とされるような大幅なコスト削減はあり得ないと考えられます。どころか、その逆です。
これは問題です。モデルが現実を完璧に表しているわけではありませんが、全体的なメッセージは正しいのです。貴社は、生産性の向上速度に見合った比例した程度で維持コストを削減する AI を必要としています。それがなければ、貴社は困ることになります。一時的なスピード向上に対し、永続的な束縛を選んでいるのですから。
ですから、コード作成の改善を追及するのはもちろん大切です。しかし、同様に維持コストの改善にも時間をかける必要があります。さもなくば、貴方も「ホテル・カリフォルニア」に囚われることになります。
どれほど素敵で愛らしい場所でしょう。 どれほど愛らしい顔立ちでしょう。
AI への批判としてこの文章を意図しているわけではありません。他にも重要なレバレッジ（調整可能な要素）があります。例えば、コード自体がより保守しやすくなるかに関わらず、メンテナンス業務そのものの生産性を向上させる AI などです。スプレッドシートのコピーを取って、モデル内のすべてのレバレッジを操作してみてください。仮定を変更して、実際の状況に近い値に設定したとき、何が起きるかを試していただければ幸いです。