7月31日、SD Timesが「Why Your Codebase Is Forcing Your AI to Underperform」と題した記事を公開した。この記事では、コードベースに蓄積された技術負債がAIコーディングツールのパフォーマンスを直接的に損なうという構造的な問題について詳しく論じている。なお本記事はAzul Intelligence Cloudの提供するソリューションを具体例として取り上げており、元記事自体がスポンサードコンテンツ的な性格を帯びている可能性がある点は念頭に置いて読んでほしい。
AIが「サボっている」のではなく、コードベースが「足を引っ張っている」
GitHub CopilotやCursor、Claude Codeを数百人のエンジニアに展開してから半年。生産性の向上は確かにあるが、当初の期待より小さく、チームによってバラつきがある——そんな状況に心当たりがあるエンジニアリングリーダーは多いはずだ。
原因はAIではない。コードベースがAIに余計な仕事をさせているのだ。
AIコーディングアシスタントが何らかの変更を行うには、その周辺コードを読み込む必要がある。ところがAIのコンテキストウィンドウ（一度に処理できる情報量の上限）は有限だ。誰も呼び出さないメソッド、使われていないライブラリ、何年も前にリリースされて形骸化したフィーチャーフラグの残骸——こうしたコードがすべてトークンを消費し、本来タスクに使われるべきリソースを食い潰す。
ディスク上では、未使用コードは現役コードと見た目が同じだ。AIはそれを読み込んで初めて「不要だった」と気づく。その時点でコストはすでに発生している。プロンプトは肥大化し、推論精度は落ち、存在しないメソッドへの幻覚的な呼び出し（ハルシネーション）が増え、手戻りが増える。
記事はこう断言する。「コードベース上でのAIの実効的な知性は、デッドコードの量に反比例する」。
技術負債の「利子」が急上昇した理由
これはWard Cunninghamが定義した古典的な意味での技術負債だ。合理的に先送りされた作業が、後になって利子を生む。買収で吸収したレガシーシステム、刷新されずに残った旧フィーチャー、削除されないまま置き換えられた機能——これらが元本を積み上げる。
Azulが実施した「2026 State of Java Survey & Report」によると、63%の回答者がデッドコードや未使用コードがチームの生産性を損なっていると回答し、「まったく影響がない」と答えたのはわずか6%だった。ただし、このレポートはAzul自身が実施・公表したものであり、同社のソリューションを訴求する文脈で引用されている点は割り引いて参照する必要がある。
ここ24ヶ月で構造的な変化が起きた点が二つある。
- 利子率が上がった：AIアシスタントがほぼすべてのコード変更に介在するようになり、プロンプトのたびにトークンという形でコストを支払うようになった。
- 元本の増加速度が加速した：同調査では回答者全員がAIコード生成ツールを使用しており、30%が新規コードの半分以上をAIが書いていると回答。コードは速く生まれるが、削除される速度は追いつかない。
AIツールへの投資がコードの増殖を促進し、その増殖がAIツールの効果を薄める——という循環だ。
静的解析では「80%」に届かない
多くの組織はすでにCIパイプラインに静的解析ツールを組み込み、未到達ブランチや未使用インポートを検出している。これは正しいアプローチだが、到達できるのは全体の10〜20%程度にとどまる。
静的解析は設計上、保守的だ。誤って生きているコードを削除するリスクを避けるため、判断できない場合は「残す」方向に倒れる。リフレクション、DIコンテナ（依存性注入）、フィーチャーフラグ、実行時のサービスルックアップ経由で呼ばれるコードは、紙の上では「到達可能」に見えてしまう。たとえその経路が3年間一度も通っていなくても。
残り80%——コンパイルが通り、呼び出し元があり、リンターも通過するが実際には実行されないコード——は静的解析では検出できない。
解決策：「実行されたか」を本番環境で測る
この問題に対する実践的なアプローチが、ランタイムエビデンス（実行時証拠）だ。本番環境でアプリケーションを観測し、どのクラス・メソッド・ライブラリが実際に呼び出されたかを記録する。
記事ではAzul Intelligence Cloudの「Code Inventory」が具体例として紹介されている。前述のとおり元記事との関係性を踏まえたうえで参考情報として読んでほしいが、アプローチ自体の考え方は汎用的だ。JVM（Java仮想マシン）上で動作する任意の環境——Oracle、Eclipse Temurin、Microsoft、Red Hat、IBMのJVMいずれも対応——でデータを収集できるとされている。
四半期末バッチ、年次レポートモジュール、季節性キャンペーン処理といった業務サイクルをカバーできる十分な期間観測すれば、「本番で実際に動いているコード」の全体像が高い信頼度で得られる。
実際の活用例として、ある企業が買収後に数百万行の見知らぬコードを抱えた状況で、Code Inventoryを使って大量の未使用コードを特定しアーカイブできたと紹介されている。静的解析では不可能だった「削除の根拠」を、実行データという証拠で確保した事例だ。
さらに、自動リファクタリングプラットフォームのModerneとOpenRewriteを組み合わせれば、数千万行規模のコードベースに対しても削除作業をスケールさせられると記事は述べている。
「コードの削除」はAI投資の乗数になる
コードの削除はAIツールへの投資と競合する予算項目ではない。AIツールの費用対効果を決める乗数だ。未使用コードが減ると、以下の連鎖が起きる。
- AIが変更内容を理解するために読むコードが減り、コンテキストウィンドウの空きが増える
- 提案の精度が上がり、存在しないメソッドへのハルシネーションが減る
- 脆弱性トリアージの対象が縮小し、本番で動いていないコードパスに起因するCVE（脆弱性識別子）の誤検知対応が減る（同調査では30%のチームが脆弱性トリアージ時間の半分以上を誤検知対応に費やしていると回答）
- 廃止フィーチャーのテストコードも一緒に削除できる
これらのメリットはAIベンダーの料金表には載らないが、AI支出と実際のアウトプットの比率には確実に現れる。
進め方：並行して走らせる
「AIロールアウトを止めてリファクタリングする」という二択は間違いだ。記事は以下の順序での並行実施を推奨している。
- 本番環境にランタイム計測を仕込む：エンジニアは引き続き開発を続けながら、データだけを蓄積する
- 証拠に基づいて削除する：静的解析で構造的に到達不能なものを、ランタイムエビデンスでそれ以外の大部分を対処する。量が多い場合はルールベースの自動リファクタリングで対応
- 整理されたコードベースに対してAIツールをスケールさせる
「存在しないコードは保守コストがゼロだ」というのはAI以前からの格言だが、AI時代においてはさらに意味が増した。存在しないコードはAIが読む必要もなく、セキュリティ対応も不要で、今後のすべてのプロンプトから除外され続ける。
詳細はWhy Your Codebase Is Forcing Your AI to Underperformを参照していただきたい。
