はじめに
AIコーディングツールの普及が止まらない。GitHub Copilot、Cursor、Claude Code——開発者の多くが何らかのAIアシスタントを日常的に使っている。生成されたコードは動く。テストも通る。PRも出せる。
しかし、ここで見落とされている問題がある。「そのコード、本当に理解しているか？」という問いである。
技術負債（Technical Debt）は広く知られた概念だが、AIコーディングの時代にはそれとは質的に異なる負債が蓄積されつつある。本記事では、それを「理解負債（Comprehension Debt）」と「認知負債（Cognitive Debt）」として整理し、その実態と対策を考察する。
「理解負債」とは何か
技術負債との違い
技術負債は「わかっているけどやらない」問題である。リファクタリングすべきコード、更新すべき依存関係——開発者は何が問題かを理解している。
理解負債はその逆で、「何が問題かすらわからない」状態を指す。AIが生成したコードが何をしているのか、なぜそう書かれているのか、開発者が把握できていない。コードは動作するが、変更しようとした瞬間に壁にぶつかる。
3つの負債の構造
| 負債の種類 | 定義 | 発生条件 |
|---|---|---|
| 技術負債 | 既知の品質問題を先送りにしたコスト | 意図的なショートカット |
| 理解負債 | AIコードの意図・構造を開発者が理解できない状態 | AI生成コードの無批判な受け入れ |
| 認知負債 | AIへの依存によりシステム全体の理解が失われる状態 | 長期的なAI依存 |
理解負債が蓄積すると、やがて認知負債へと発展する。個々のコードだけでなく、システム全体の設計意図や動作原理を誰も説明できなくなる——これが認知負債である。
MIT Media Labの調査結果
MIT Media Labの調査によると、ChatGPTを使ってコーディングタスクを完了した参加者の83%が、AIが生成した誤った情報を検出できなかった。AIが生成したコードの正確性を自力で判断できない開発者が大多数を占めるという結果は、理解負債の深刻さを裏付けている。
SWE-benchの盲点 — テスト合格≠マージ可能
SWE-benchは、AIコーディングエージェントの能力を測定する代表的なベンチマークである。実際のGitHubリポジトリのissueを解決するPRを生成し、テストに合格するかどうかで評価する。
しかし、Hacker Newsで話題になった調査は、「SWE-benchで合格したPRの多くが実際にはマージされない」という事実を明らかにした。
なぜか。テストに合格することと、人間のレビュアーがマージを承認することは、まったく別の基準で判断されるからである。
レビュアーが実際に評価する基準
テスト合格は「動作検証」にすぎない。マージ承認には「適合性検証」が必要である。
| 評価軸 | テスト合格で検証されるか |
|---|---|
| 正しく動作するか | はい |
| コードが読みやすいか | いいえ |
| 既存のアーキテクチャに適合するか | いいえ |
| チームのコーディング規約に準拠するか | いいえ |
| 保守性・拡張性があるか | いいえ |
AI生成コードは前者には強いが、後者が弱い。これがSWE-benchのスコアと実務での受け入れ率の乖離を生んでいる。
AIコードの特徴的な問題
Hacker Newsでの議論では、実際にAI生成コードをレビューした開発者たちから具体的な事例が共有された。
コード膨張の実例
| ケース | AI生成 | 人間によるリファクタリング後 | 削減率 |
|---|---|---|---|
| Codex（GPT 5.4）のRustコード | 480行 | 230行 | 52% |
| Claude Codeの実装 | 624行 | 334行 | 46% |
| Claude Codeの別事例 | 400行 | 130行 | 68% |
単に行数が多いだけではない。AI生成コードに共通する構造的な問題がある。
AI生成コードに共通する課題
過度なエッジケース処理: 発生し得ないケースに対するガード条件が多重にネストされ、本質的なロジックが埋もれる。
不要な抽象化: 1箇所でしか使われないにもかかわらず、汎用的なヘルパー関数やインターフェースが生成される。
既存パターンとの不整合: AIはリポジトリ全体のアーキテクチャを理解しているとは限らない。結果として、既存のコーディングスタイルや設計パターンから逸脱したコードが生成される。
過剰な条件分岐: ある開発者は「AIが生成する複雑にネストされた条件分岐は、古いアセンブリのgotoのような混乱を引き起こす」と評している。
定量的なデータ
@ITの記事によると、以下の数値が報告されている。
- AI生成コードのレビュー時間は人間が書いたコードの1.7倍
- AI生成コードに対するバグ指摘数は平均10.83個（人間のコードは6.45個）
レビュー時間が1.7倍ということは、AIによる生産性向上が、レビューフェーズでかなりの部分相殺されていることを意味する。
理解負債が組織にもたらすリスク
理解負債は個人の問題にとどまらない。組織レベルで以下のリスクを引き起こす。
チーム全体の技術知識の喪失: AIがコードを書き、人間がそれをそのまま受け入れるサイクルが続くと、チーム全体の設計能力が低下する。「なぜこの設計なのか」を説明できるメンバーがいなくなる。
オンボーディングコストの増大: 新しいメンバーがコードベースを理解しようとしたとき、AI生成コードは「なぜそう書かれているか」の文脈が欠落しているため、学習コストが増大する。
障害対応の遅延: 本番障害が発生したとき、コードの意図を理解していなければ原因特定に時間がかかる。「動いているから触るな」は、障害時に最大のリスク要因になる。
技術的意思決定の質の低下: システムの全体像を把握している人間がいなければ、アーキテクチャの判断が場当たり的になる。
理解負債を防ぐための実践
コードレビューの維持と強化
AIがコードを書く時代だからこそ、コードレビューの重要性は増している。ただし、レビューの観点は変わる。
- 「何をしているか」ではなく「なぜそうしているか」を問う: AI生成コードは動作は正しいことが多い。問う対象は設計の意図と選択の理由である
- 過剰な複雑性を指摘する: AI生成コードは冗長になりがち。「これはもっとシンプルに書けないか」という視点を意識的に持つ
- 既存パターンとの整合性を確認する: リポジトリのコーディング規約やアーキテクチャパターンに沿っているかをチェックする
AI生成コードのガイドライン整備
チームでAIコーディングツールを使う場合、以下の整備が効果的である。
- AGENT.mdやコーディングガイドラインの明示: AIに対してもチームの規約を明示的に伝える
- linter規則の整備: 自動チェックできる項目は機械に任せる
- PRテンプレートへの項目追加: 「AI生成コードを含むか」「理解度の自己評価」などの項目を追加する
設計プロセスの重視
AIに実装を任せるとしても、設計は人間が行うべきである。
- 実装前に設計を言語化する: 何をどう実装するか、AIに書かせる前にチームで合意する
- AIの出力を「下書き」として扱う: 生成されたコードをそのまま使うのではなく、理解した上で書き直す覚悟を持つ
- 定期的なアーキテクチャレビュー: AI生成コードが蓄積しても全体の設計意図が保たれているか、定期的に確認する
まとめ
AIコーディングは生産性を向上させる。この事実に異論はない。しかし、「動くコードが速く書ける」ことと「良いソフトウェアが作れる」ことは同義ではない。
理解負債は、AIコーディングの恩恵を受けながらも見落とされがちな代償である。SWE-benchで高得点を取るPRが実際にはマージされない事実、レビュー時間が1.7倍になるデータ、480行が230行に削減される事例——これらはすべて、「動作する」と「理解している」の間にある溝を示している。
この溝を埋めるのは、結局のところ人間の仕事である。AIに書かせるのは良い。だが、理解することをやめてはいけない。