なぜ、コードは速く書けるのに開発は遅くなったのか ―AI時代の「理解負債」との向き合い方
生成AIが生み出す新しい負債「理解負債」について
こんにちは！
株式会社ココナラのVP of Product Engineeringの村上です。
こちらは株式会社ココナラ Advent Calendar 2025 25日目の記事です。
本内容は以下の登壇内容について深堀りしたものとなります。
登壇資料も合わせてご確認ください。
はじめに
「このコード、どういう意図で書いたんですか？」
PRレビューでの何気ない質問。でもメンバーは答えられません。
「AIが生成したコードなので...正直、よく分かってないです」
「動いてるから大丈夫だと思うんですけど」
この会話、最近よく聞きませんか？
レビュー時間は増加傾向にあり、生成AI疲れを実感し始めているのではないでしょうか？
生成AI導入効果に関する矛盾
2023年以降、GitHub Copilot、Claude Code、Cursorといった生成AIツールが急速に普及しました。
わずか1-2年で、これらのツールは開発現場で「当たり前」の存在になっているのは誰もが知るところです。
生成AIの普及によりコーディングスタイルも劇的に変わりました。
数行のコメントから数百行のコードが生成されて、ボイラープレートは一瞬で完成するし、テストコードも自動生成される。
エンジニアは「書く」時間を大幅に削減できるようになりました。
多くのエンジニアが実装速度の向上を実感しています。
しかし、この急速な変化は、想定していなかった副産物も生み出しました。
Faros AIとGoogle Cloud DORAが10,000人以上のエンジニア、1,255チームのテレメトリデータを分析した結果を示します。
個人レベルでは成功している。
- 82.3%のエンジニアが20%以上の生産性向上を実感[1]
- コーディングは確実に速くなった
- 単純作業から解放された
組織レベルでは苦悩している。
個人では生産性が向上しているのに、組織全体では効率が低下している。
局所的には最適化できているのに、全体最適が崩れている。
このような生成AI活用効果に関する矛盾は、最近 「AIパラドックス」 と呼ばれています。
なぜAIパラドックスが起きるのでしょうか。
このAIパラドックスには複数の原因がありますが、その中でも特に見過ごされがちな問題があります。
本記事では、AIパラドックスの主要な原因の一つである「理解負債」という概念について説明し、どう向き合っていくべきかについて私の考えを整理したいと思います。
第1章：理解負債とは何か
1.1 理解負債とは
AIパラドックスの主要な原因の一つ、それが 「理解負債（Comprehension Debt）」 という概念です。
理解負債とは、AI生成コードに特有の新しい形態の負債で、「コードは動作するが、誰もそのロジックを説明できない状態」を指します。
個人が速く書けるようになった一方で、チーム全体での「理解」がボトルネックになっています。
コードは爆速で生まれるのに、そのコードを理解し、保守し、発展させることが追いつかない。
この概念の詳細については、Codemanship's Blogの記事で解説されています。
1.2 技術負債と理解負債の違い
「技術負債」という概念は多くのエンジニアにとって馴染み深いものですが、技術負債と理解負債は何が違うのでしょうか。
両者の主な違いを以下の表にまとめます。
| 観点 | 技術負債 | 理解負債 |
|---|---|---|
| 対象 | コード・システムの品質（「物」） | エンジニアの知識・認知負荷（「人」） |
| 定義 | 実装品質が低く、将来の修正コストが高い状態 | 動作するが、誰もロジックを説明できない状態 |
| 原因 | 時間的制約、技術的判断ミス | AIへの過度な依存、理解の欠如 |
| 解決策 | リファクタリング、コード改善 | 教育、文化変革、プロセス改善 |
| 可視性 | 比較的可視化しやすい | 見えづらい（動作するため） |
重要なポイントは「対象」の違いです。
技術負債はコードそのものの問題、つまり「物」の問題です。
コードが複雑すぎる、設計が不適切、テストが不足している。
これらはリファクタリングやコード改善で解決できます。
一方、理解負債はエンジニアの理解の問題、つまり「人」の問題です。
コードは動作するし、テストも通る。
しかし、誰もそのロジックを説明できない。
なぜその実装になっているのか分からない。
これは単なるコード修正では解決できません。
理解負債は、AI生成コードに特有の新しい形態の技術的負債です。
「動くコード」だからこそ見過ごされやすく、気づいたときには手遅れになっていることが多いのです。
1.3 理解負債の具体例 - 現場で起きている3つのシーン
理解負債が実際の開発現場でどのように現れるのか、3つの典型的なシーンを見ていきましょう。
以下具体例は、分かりやすく説明するための架空のシーンとなります。
シーン1: コードレビューで答えられない
あなたは新しい決済APIの統合コードをレビューに出しました。
「このエラーハンドリング、リトライロジックが複雑だけど、なぜこの実装にしたのですか？タイムアウトの値の根拠はありますか？」
シニアエンジニアからの質問に、あなたは言葉に詰まります。
実は、「決済API統合のエラーハンドリングを実装して」と生成AIに指示して、生成されたコードをそのままコミットしただけ。
なぜこのリトライ回数なのか、タイムアウト設定の理由は何か、全く説明できません。
「...テストは通っているので、動作は問題ないと思います」
結局、その言葉でマージされました。
でも、誰も本当には納得していません。
シーン2: 3ヶ月前の自分のコードが読めない
「ユーザー検索機能にフィルター追加してほしいです。簡単に実装できますか？」
朝会でPMからの依頼で、簡単そうに聞こえます。
該当コードを開くと、3ヶ月前に自分が実装したファイルでした。
しかし、画面に表示されたコードを見て、あなたは固まります。
複雑にネストされた条件分岐、謎の状態管理ロジック、300行を超える関数。
コメントは一切ありません。`git blame`を実行すると、すべての行に自分の名前が表示されます。
「なぜこんな実装に...？」
記憶を辿りますが、思い出せません。
Cursorが生成したコードをそのまま使ったことだけは覚えています。
でも、なぜこのロジックなのか、どの部分が重要で、どこに副作用があるのか、全く分かりません。
見積もり2時間の作業は、結局2日間に。
コード理解だけで1日、影響範囲の調査に半日、実装と動作確認に半日かかりました。
シーン3: 本番障害で原因特定できない
Slackの通知音で障害に気づきます。
「本番環境で決済処理エラーが多発しています」
急いでPCを開き、Datadogのダッシュボードを確認すると、エラー率が通常の30倍になっています。
CSチームからは顧客からの問い合わせが殺到しているとの報告。
エラーログを追うと、2日前にマージされた「決済フローのリファクタリング」のPRに行き着きます。
コミットメッセージは「AI refactoring: improve payment flow」とだけ。
実装者に連絡して内容を確認してみます。
「Claude Codeでリファクタリングしたんですが、テストは通っていたので...具体的にどこを変えたかはわかっていません」
エラーは出ているものの、なぜこのコードがこのエラーを引き起こすのか、誰も説明できません。
コードレビューの履歴を見ても、「LGTMです」というコメントのみ。
結局、根本原因を特定できないまま、PRを丸ごとロールバック。
通常1時間で終わる障害対応が、4時間以上かかりました。
共通する特徴
これら3つのシーンには、共通するパターンがあります。
見えない負債：「動くから問題ない」という錯覚
テストは通るし、動作する。
しかし、表面的な成功の裏に、理解の不足が隠れています。
実装者本人でさえ、なぜその実装になっているのか説明できないことがあります。
問題はコミット直後には現れません。
数週間〜数ヶ月後の要件変更やバグ修正のタイミングで初めて気づくことが多く、そのときには対応に多くの時間を要する状態になっています。
チーム全体が誰も理解していないことを許容している状態
特定の個人の能力の問題ではなく、組織やチーム全体で起きやすい状況です。
「なぜこの実装？」「別のアプローチは？」といった健全な技術的議論が、「AIが書いたから」という言葉で終わってしまう。
レビュアーも「動いているから」で承認する。こうして「誰も深く理解していない」状況が見過ごされやすくなっています。
これが「理解負債」の正体です。
第2章：理解負債がもたらす問題
理解負債がもたらす影響は、想像以上に深刻です。
組織にどのような影響があるのでしょうか。
具体的な問題の例をいくつかピックアップしてみます。
2.1 修正コストの爆発
前述の通り、PRレビュー時間が91%増加していますが、その理由の一つとしてPRサイズ（変更行数）が154%増加[4]していることが挙げられます。
一度に送りつけられるコードの塊が巨大化し、人間が理解可能な認知限界を超えているのです。
さらに深刻なのは、書くコストと直すコストの逆転です。
AIは1分で数百行のコードを生成できますが、バグがあった場合、人間が原因を特定し修正するには数日かかることも珍しくありません。
デバッグ時に「なぜこの実装なのか」を理解するところから始める必要があります。
その上、影響範囲も不透明で、最初の数分の時間節約が、後に数日〜数週間のコストとして跳ね返ってきます。
2.2 セキュリティリスクの増大
理解負債は、セキュリティリスクを著しく高めます。
AI生成コードの45%に脆弱性が含まれる[5]というデータがありますが、レビューで見逃されるケースが多発しています。
SQLインジェクション、XSS、認証バイパスといった典型的な脆弱性が、「テストが通っているから」という理由で本番環境に混入してしまうのです。
さらに問題なのは、監査やコンプライアンス対応です。
セキュリティ監査で「なぜこの実装にしたのですか？」「この処理の安全性をどう担保していますか？」と問われても、実装者が答えられません。結果として、監査対応に膨大な時間がかかり、場合によっては大規模な修正を余儀なくされます。
理解していないコードは、セキュリティの観点から見れば「未知の爆弾」です。
いつ、どこで、どんな脆弱性が発見されるか分からない状態で、組織はリスクを抱え続けることになります。
2.3 エンジニアの疲弊とオーナーシップの喪失
理解負債は、エンジニア個人にも深刻な影響を及ぼします。
65%がバーンアウトを経験[6]しているというデータが示すように、AIによる開発の高速化は、皮肉にもエンジニアを疲弊させています。
理由の一つは、認知負荷の質的変化です。
「コードを書く」という創造的な作業から、「AI生成コードを理解し、レビューし、デバッグする」という高負荷な認知作業にシフトしています。
しかも、マネージャーは「生成AIで速くなったはず」と期待するため、現場との期待ギャップが広がり、プレッシャーが増大します。
もう一つの深刻な問題は、オーナーシップの喪失です。
AI生成コードに対して、エンジニアは心理的な距離を感じます。「生成AIが書いたコードだから」という言い訳が常態化し、「誰かが直してくれる」という依存心が蔓延します。
多くのエンジニアがAI生成コード使用前よりセキュリティ脆弱性の解決により多くの時間を費やしているのは、「自分のコード」という責任感の欠如が品質低下を招いているからです。理解していないコードに責任を持つことはできません。
結果として、品質への意識が低下し、さらなる負債を生む悪循環に陥ります。
第3章：理解負債を増やさない組織のあり方
理解負債を増やさないために、何をすべきか。
技術的な対策だけでは足りません。
私は、組織全体で構造的に理解負債を防ぐ仕組みが必要だと考えています。
3.1 プロセスの根本的変革
従来の開発プロセスは、「実装→テスト→レビュー」という流れでした。
しかし、AI生成コードの時代には、このプロセスだけでは理解負債を防げません。
なぜなら、実装者自身が生成されたコードを理解しないまま次のステップに進んでしまうからです。
そこで、生成AI時代の開発プロセスには「理解確認」という新しいステップを明示的に追加する必要があります：
このプロセスを機能させるには、エンジニアのマインドセットの転換が不可欠です。
生成AIは便利なツールですが、完璧ではありません。
生成されたコードを無批判に受け入れる姿勢は、理解負債を確実に増やします。
重要なマインドセット:
- 生成AIは「有能だが経験の浅い部下」として扱う
- 常に疑い、検証する
- AI生成コードは必ず理解してからコミット
また、自動化できる部分は徹底的に自動化すべきです。
自動テスト、セキュリティスキャン、コード品質チェックを義務化することで、人間の認知リソースを本当に重要な判断に集中させることができます。
具体的には、人間は 「アーキテクチャの安全性」 と 「ビジネスロジックの妥当性」 に集中すべきです。
なぜなら、これらは機械的なチェックでは判断できない、高度な文脈理解と経験が必要な領域だからです。
生成AIは構文的に正しいコードを生成できますが、システム全体の設計や、ビジネス要件との整合性を保証することはできません。
3.2 スキルと役割の変革
プロセスの変革だけでは不十分です。
生成AI時代において、エンジニアに求められるスキルと役割そのものが変化しています。
ジュニアエンジニアは、生成AIに頼りすぎることで基礎力が育たないリスクに直面しています。
一方、シニアエンジニアには、従来のコードレビュー中心の役割から、アーキテクチャ設計やリスク管理といったより高次の判断が求められるようになりました。
ジュニアエンジニア:
- 基礎力（疑う力）を育成
- 生成AIの出力を鵜呑みにしない訓練
- 生成AI非使用のコーディング課題で基礎固め
シニアエンジニア:
- Reviewer（承認者）からOrchestrator（指揮者）へ
- 「正解を教える」から「一緒に探索する」へ
- コードレビューよりアーキテクチャ設計、リスク管理に価値
このように、生成AI時代のエンジニアリングは、単にツールを使いこなすだけでなく、エンジニア一人ひとりの役割と成長の方向性を見直す必要があります。
プロセスとスキルの両面から変革に取り組むことで、理解負債を防ぎながら、生成AIの恩恵を最大限に活かせる組織を作ることができるでしょう。
まとめ：生成AI時代のエンジニアと組織のあり方
ここまで、理解負債の正体とその影響、そして対策として必要なプロセスとスキルの変革について説明してきました。
改めて強調したいのは、理解負債は「人」の問題だということです。
AIが速く書けるからこそ、人間の「理解」が律速段階になります。
技術負債はコードを直せば解決しますが、理解負債は人が学ばなければ解決しません。
理解負債は避けられない課題ですが、適切な対処と文化変革により、持続可能な開発体制を構築できます。
短期的な生産性に惑わされず、理解を犠牲にせず、組織全体で取り組むことが必要です。
まず、自分のチームが理解負債を抱えていないか確認してみてください。
以下のチェックリストで現状を把握することから始めましょう。
あなたのチームは理解負債を抱えていませんか？
以下の項目に当てはまるものが3つ以上ある場合、理解負債のリスクが高い状態です：
- PRレビューで「なぜこの実装？」という質問が減っている
- 「生成AIが書いたから大丈夫」というコメントを聞く
- レビュー時間が半年前より大幅に増えている
- コードの説明を求められて答えられないことがある
- テストが通れば良いという雰囲気がある
- 本番環境でのバグ修正に予想以上の時間がかかる
- 新メンバーのオンボーディングが困難になっている
- セキュリティ監査で説明に困ることがある
- 「動くから大丈夫」という会話が増えている
- 実装者が数ヶ月後に自分のコードを説明できない
3つ以上該当した場合は、組織として理解負債とどう向き合っていくか、検討を始めることをお勧めします。
ココナラでは積極的にエンジニアを採用しています。
まずは話だけでも聞いてみたいという方は、以下カジュアル面談よりご連絡ください。
採用情報としてこちらもご確認ください。
Discussion
この記事のおかげで今年のモヤモヤが言語化され、来年はより良いAIコーディングへの向き合い方が出来そうと感じることが出来る良記事でした。
ありがとうございます。
すごく興味深い記事です。確かに私も一人プロジェクトでAIを使うと、なかなか進捗が早いなと思ってますが、いくつかの欠点も気づいてきました。たとえばAIで生成したコードは必要以上に行数が多いとなります。つまり従来エンジニアが誇りに思える「シンプルな」あるいは「エレガントな」コードが全く生成されてないものです。あとはDRY概念をしっかりみて実装してくださいっとルールを書いてもそうならないものです。
チーム仕事の場合にはこの記事に書かれているものが本当にそうですよ、いつもPRは「LGTM。。。」になってしまい、ジュニアだけじゃなくてシニアエンジニアまでAIに頼りすぎて、説明しようとなったら「まあ、テストが通ったのでそこまで見てなかった。。時間も限られてたし。。」と。