はじめに

AI駆動開発が当たり前になった今、自然言語で要件を伝えるだけで機能が完成する時代になりました。

しかしその便利さの裏で、コードの中身を理解しないまま成果物を提出するケースが増えています。これが「理解負債（Comprehension Debt）」です。

理解負債が溜まると、以下のリスクが高まります。

機能の詳細を説明できなくなる
コードの品質を正しく判断できなくなる
設計への理解も失われ、誤った設計判断をしやすくなる（これは「認知負債」と呼ばれる状態に近いです）

特に成果物に対する前提知識が少ない新人エンジニアは、このリスクが非常に高いです。

※この記事では「新人」＝「特定分野の知識が少ない人」とします

新人は理解負債のリスクが高い

新人は、特定の分野に対する知識量が経験者に比べて圧倒的に少ないです。自分も新卒1年目の頃は、1つの不明な単語を調べるために関連用語を次々と調べる必要があり、理解に時間がかかっていました。

AI駆動開発が主流になる前は、ボタンの色を変えるような単純なタスクから少しずつ着手できたため、コードを1行1行理解しながら進める余裕がありました。

しかし、AIエージェントが主流になった今は状況が変わりました。短期間で多くのタスクをこなせるようになった結果、新人でも一度に扱う情報量が大幅に増えています。

実際、AI駆動開発が主流となった新卒2年目の頃は、1000行以上の実装を数日でこなすようになりました。AI以前と開発期間が同じでも、成果物の量がかなり増えたのです。

そのとき、動くコードはできたものの、レビューなどで実際に説明を求められると、適切な言葉が出てこないという経験をしました。「動いている」ことと「説明できる」ことは別物だと痛感した出来事です。

この状態で「全ての内容を理解してから提出する」ことを徹底しようとすると、期限に間に合わなくなるリスクが高まります。結果として、「理解していない箇所を飛ばしたまま提出する」という選択をしてしまいやすくなります。

また、「わからないことがわからない」状態も新人特有の落とし穴です。AIに質問攻めにすれば理解が進むという意見もありますが、一度に理解できる容量には限界があります。特に新人はそれが顕著で、一気に聞きすぎると、かえって何が分かって何が分かっていないのかが曖昧になります。

自分が取り組んでいる理解負債対策

一番意識しているのは、「AIが生成した内容をそのまま受け入れない」ことです。対策は大きく3つあります。

1. 詳細を詰める質問をする

意図的に、次のような質問をAIエージェントに投げています。

○○は何？
○○ってどこに書かれている？
○○ってどういう仕組みで動いている？
なぜこの実装になっているの？
具体的にはどう動くの？

「なんとなく動いている」状態から「自分で説明できる」状態に近づけることが狙いです。

ただし、一度に全部を聞くと容量を超えてしまいます。

そのため、質問は1回につき1テーマに絞り、全体像 → 詳細の順に段階的に聞くようにしています。分からない用語が出てきたら、その場で脱線せずメモしておき、あとでまとめて調べます。

2. オウム返しで確認する

「○○って、つまり△△ということ？」
自分の言葉で言い換えて、「この理解で合ってる？」と確認する

特にこの「自分の言葉で言い換える」ステップを大事にしています。AIの説明をそのまま受け取るのではなく、一度自分の頭で咀嚼してから確認することで、理解が定着しやすくなると感じています。

3. 理解する時間を意図的に増やす

1・2をしっかりやろうとしても、提出期限が短すぎると理解に充てる工数を確保できません。そこで、次の2点で時間を作っています。

作業の効率化を徹底する

定型作業を自動化する（Agent Skillsの活用など）ことで、作業工程で時間の無駄を作らないようにします。そのうえで、浮いた工数は別の作業ではなく、コードの理解や調べ事に充てます。

作業工数を「遅れる前提」で見積もる

見積もりの段階で、理解のためのバッファをあらかじめ入れておきます。「予定通りに進む」ことを前提にせず、理解に時間がかかることを織り込むことで、焦って理解を飛ばすリスクを減らしています。

今後AI駆動開発がさらに主流になり、開発サイクルが短くなる可能性が高い以上、個人として「時間の余白」を作り出す工夫を続けることが、理解度を維持するうえで重要だと考えています。

対策を続けてどうなったか

AIの出力を疑えるようになった

1年目の頃は、AIの出力をあまり疑わずそのまま採用してしまうことが多くありました。しかし、複数パターンの質問を何度も壁打ちするうちに、「何について問うべきか」という感覚が自然と身についてきました。出力の良し悪しを自分で判断できるようになったのも大きな変化です。

特定分野の知識が深まり、チームに還元できた

次のような好循環が生まれました。

効率化や余裕のある作業計画で工数が浮く
→ 理解や調べ物の時間が増える
→ 特定分野を研究できる
→ ナレッジをチームに展開する
→ その分野で頼られるようになる

自分の場合は、次の流れでした。

自動化などで工数を浮かす
理解や調べ物に時間を使えるようになる
AIエージェント設計に関する個人研究を始める
調べた知見を活かして、チームに開発用のハーネスを構築する
チームでAI駆動開発に関する相談を受けるようになった

専門外の分野にも対応しやすくなった

フロントエンドしかできていない状態で、バックエンドのコードレビューを任されたことがありました。持っていた知識は対象プロダクトのDDD（ドメイン駆動設計）だけでした。

変更差分は約1500行と大きく、時間も限られていたため、すべてを最初から完璧に理解するのは現実的ではありませんでした。そこで、AIに指摘された箇所を中心に、コードの意味を1行ずつ確認しながら「この指摘は本当に適切か？」を自分で判断するように進めました。

結果として、適切なレビューを行うことができました。

理解負債を意識的に減らそうと取り組んだことが、専門性を高めるだけでなく、専門外の領域に対応する力にもつながったと感じています。

まとめ

本記事では、AI駆動開発時代に起きやすい「理解負債」と、新卒3年目の自分が実際に取り組んでいる対策を紹介しました。

理解負債とは、コードの中身を理解しないまま成果物を提出することで蓄積されるリスクである
新人は知識量が少ない上に、AIによって一度に扱うタスク量が増えやすいため、特にリスクが高い
自分が取り組んでいる対策は次の3つ
1. AIに詳細を詰める質問をする（1テーマずつ段階的に）
2. 自分の言葉で言い換えて確認する
3. 理解する時間を意図的に確保する（効率化＋余裕のある見積もり）
続けた結果、次の変化があった
- AIの出力を疑えるようになった
- 特定分野でチームに知見を還元できた
- 専門外の分野にも対応しやすくなった

理解負債への対策は、単なるリスク回避にとどまりません。意図的に理解を深める習慣が、結果的に自分の成長や専門性の向上にもつながると感じています。

AI駆動開発がさらに当たり前になっていくこれからも、理解を放棄せず、自分の頭で考える時間を大切にしていきたいです。

皆さんは、AIが書いたコードの理解をどう担保していますか？ぜひコメントで教えてください。