# AI 技術的負債は2つの異なる問題である : コード負債と認知負債 URL: https://codebasechat.com/ja/journal/ai-technical-debt-two-problems Type: blog Locale: ja Published: 2026-07-14 Updated: 2026-07-14 --- > AI生成コードは見た目には正しいが隠れた欠陥を持つ。だが本当の問題は、チームがコードの背景にある設計を理解できなくなることだ。AI技術的負債を2つに分けて考える。 AI 技術的負債は、あなたが想像しているものではない。単なる重複した関数や、リンターで検出できる一貫性のない命名ではない。その半分は、プルリクエストで完全に正常に見え、レビューを通り、本番に入る。その問題は、6週間後、チーム全体が「あそこの変更が、なぜ予想外のあっちもこっちも壊したのか」説明できなくなるまで、表に出ない。その出ない方の半分が、ほとんどのチームが測定できていない領域だ。 ## AI技術的負債は実は2つの全く別の問題である エンジニアリング責任者に「AI技術的負債とは何か」と問えば、5つの答えが返ってくるが、その大半は2つのカテゴリに分かれる。 1つは**コード負債** : 重複、パターンの不一貫性、技術的には正しいが誰も求めていなかった表面積のコード。これは静的解析ツールが生まれた領域だ。 もう1つは**認知負債** : コードが生成されるスピードと、チームがそれを実際に理解する共有メンタルモデルを構築するスピードの落差のことだ。Sonarの2026年開発者調査では、開発者の88%がAIによる技術的負債の悪影響を少なくとも1つ報告し、53%がAIは見た目では正しいが隠れた欠陥を持つコードを生成すると述べている。これはコード負債だ。だが調査が完全に捉えていないのが2番目のタイプで、[LeadDevの記事](https://leaddev.com/ai/ai-coding-creates-two-kinds-of-debt-youre-only-measuring-one)がこの概念を最も明確に論じている。 5つのチーム中3つはこの両者を混同している。残り2つが何を違うことをしているか : コード負債はツールで追跡し、認知負債は会話で追跡しているのだ。 ## コード負債：見た目は正しいが、中身が違うコード コード負債は古くからある問題だ。AI生成コードはコンテキストにない限り、既に別の3ファイルに存在する論理を知らないため、その論理を重複させてしまう傾向がある。Sonarの数値では、開発者の40%がAIが不要または重複するコードを生成することで負債が増えたと答えている。 危険な変種は、間違ったコードではなく、正しく見えるコードだ。関数はテストに通る。ハッピーパスをきれいに処理する。シニアエンジニアが書いたように読める。ただし、元の実装が処理していたエッジケースを静かに落とす。コードレビューは誤字を見つける。だが、もっともらしく見える関数が実は微妙に不完全であることを見つけるには、レビューは得意ではない。 `// AI生成: テストに通り、見た目はきれい function getActiveUsers(users) { return users.filter(u => u.status === "active"); } // 3ファイル先で実装されていた元の実装: function getActiveUsers(users) { return users.filter(u => u.status === "active" && !u.deletedAt); }`ここではエラーは出ない。CIでテストが落ちない。3週間後、削除済みユーザーがレポートに復活したときにだけ問題が表面化する。オンコール担当のエンジニアはgrepとblameのループに入り、どちらのバージョンが正しいのか、なぜなのかを確認する必要がある。そのgrepとヒアリングのループが実際のコストであり、これは「何かおかしい」という漠然とした感覚ではなく、時間で測定できるものだ。 別のウィキではなく、リポジトリと一体化したDocs-as-Codeツールは、関数の背景にある推論が誰かのメモリではなく、その関数から1クリックの場所にあるため、このループが何度も起こる頻度を減らす。 ![Close-up of hands on a keyboard with a red-and-green code diff visible on the blurred screen behind](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-07/eaeaef-inline1.webp) ## 認知負債：チームが自分たちのシステムを説明できなくなる ビクトリア大学コンピュータ科学教授のマーガレット・アン・ストーリー博士は、2025年10月に「認知負債」という概念を提唱した。学生たちがAIで高速に出荷し、その後、ユーザーフィードバックに対応するのに苦労するのを見たからだ。彼女の診断：学生たちはコードを失ったのではなく、自分たちが何を作っているのか、なぜ作っているのか、チーム内の誰が何を知っているのかを失ったということだ。 この見方はピーター・ナウルの古い主張を参考にしている : ソフトウェアは実はコードではなく、それを作った人の頭の中にある共有理論だということだ。コードが生成される速度がチームがその理論を構築する速度を上回ると、理論は形成されない。テストは完全、コードはクリーンでも、それを出荷した人間がそれを完全に説明できないか、1人だけが説明できるなら、認知負債は大きく存在する。 これが、ダッシュボードがコードを追跡するが理解を追跡しないため、標準的なAI技術的負債メトリクスが完全に見落とす領域だ。次のレトロで聞く価値がある質問は単刀直入だ：アーキテクチャ図を置き、チームの誰がそれぞれのボックスを説明できるか聞いてみよう。答えが「1人、そして彼は今週休みです」なら、あなたのリンターが何と言おうと、認知負債がある。 生きた社内ウィキだけでは認知負債は解決しない。だが、その「why」が1人の脳の中だけにある状態になる前に、それを書き下ろす場所を与える。それは始まりだ。 ![Three engineers standing at a whiteboard sketching a system architecture diagram together](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-07/e90110-inline2.webp) ## コードレビューは生成速度に追いつけない理由 ここが両方の負債の下にある機械的な問題だ：AIは1人のエンジニアが昼までに1週間分のコードを生成させる。だがレビュー容量は全く拡大していない。ボトルネックが書きから読みに移った。読みのスピードは誰も上げなかった。 ここはツール比較が本当に重要だ。具体的に言おう。CopilotとCursorは、開いているファイルの中でのコード生成は速い。だから多くのコードが生成される。CodyとContinue.devはリポ全体を先に調べてから生成する傾向がある。重複の問題は減るが、新しいコードがシステム設計にどう合うかを判断するステップは置き換わらない。彼らはPRをマージする人がそれを実際に理解しているかは教えてくれない。構文的に正しいかは別の問題だ。 コードベース質問ツールがこのギャップのために存在するのはそのためだ：AI生成コードをうまくレビューする最速の方法は、マージ前に「このパターンは他のどこにあるか」または「このケースは既に誰が処理しているか」を明確に聞けることだ。その質問は、かつてシニアエンジニアがgrepとblameに20分かけていた。そうあるべきではない。 また、リポサイズの効果も無視できない。5,000行のサービスなら、1人のレビューアーがシステムのほぼ全体を脳に入れられるため、もっともらしく見えるコードはレビュー者のメンタルモデルと違うから目立つ。80,000行のモノリポで6チームが手を入れていたら、誰もメンタルモデルを持たないため、もっともらしく見えるコードは単に誰も「それは間違い」と気づく文脈がないから通ってしまう。リポが大きいほど、レビュー件のボトルネックは1人のシニアの記憶ではなくツールに依る。 ## ジュニアエンジニアがこの負債を最初に、最も速く払う Antrophicは2026年1月、52人のジュニア開発者を対象とした無作為化試験を実施した。AIアシスタントを使った開発者はコード理解テストで17%低いスコアを記録、ほぼ2段階落ちた。Infobipの人材育成チームは225人のインターンを2022年以来追跡している。AI前のコホートはインターンシップ中に自己評価技術スキルで平均2.50ポイント向上した。AI時代のコホートは1.56だ。 メカニズムはAI利用そのものではない。Infobipの最新コホートで、AIを同じ頻度で使った2人のインターンがいた。結果は正反対だった。1人はフォローアップ質問をし、AIが生成したものを完全に説明できた。その人の成長はコホート最高だ。もう1人は最小限のレビューで出力を受け入れ、ブラックボックスとして扱い、成長は0だった。ツールは同じ。使い方が違った。 ペアリングセッションとアーキテクチャウォークスルーを記録して検索できるようにすると、ジュニアは誰が空いているか聞くのではなく、戻る場所がある。メンターの代わりにはならないが、二度目の質問のコストは下がる。 ![A senior engineer pointing at a laptop screen while a junior engineer leans in to follow along](https://fdzlnqpwsaniezitwiuw.supabase.co/storage/v1/object/public/cms-media/codebasechat/2026-07/ec3aa0-inline3.webp) ## 「ジュニアのAI利用禁止」という処方箋は捨てろ このテーマのまとめは最後、同じ結論に到達する：ジュニアのAIアクセスを「実力相応」になるまで禁止しろと。それは捨てろ。実際に測定したチームが見つけたことと合致していない。ジュニアがチームと同じツールを使えないことも、別の形の遅れだ。同じくらい実質的だ。 Infobipが成功したのは禁止ではなく、順序だ：問題を先に解く、AIは次だ。そのおかげで独立した思考の習慣がAIデフォルトになる前に身につく。彼らはAI無料チェックポイントを入れた。罰ではなく、キャリブレーション。インターンとメンターが実スキルを把握する。メンターはPRレビューから、プロセス追跡に転換した：誰が何を聞き、どこで詰まり、誰が手助けなしに変更を説明したか。 スキル成長が落ちながら満足度スコアは上がった。ここがデータの実際の警告だ：ツール満足度だけ追跡したら、これは見えない。Infobipの最新コホートの20%は、そもそもジュニアエンジニアに何が期待されるのか知らなかった。自己評価はほぼ無意味になった。参照点がなければ、ギャップは測定できない。 ## このスプリントで何をするか 上の問い掛けから始めろ：システムの各部分を誰が説明できるか、今すぐ声に出して。その1つの質問が、どのダッシュボードより短時間で認知負債を見つけ出す。 コード負債には、静的解析をツールチェーンに入れておく。[Sonarの2026年開発者調査](https://www.sonarsource.com/blog/how-ai-is-redefining-technical-debt/)では、開発者の70%がそれを既に使っており、使用しているチームは修正作業でもっと良い成果を報告している。議論の余地がない推奨ではなく、高速移動時にAI出力が完成したように見えるのでスキップするチームがあるという話だ。 AIが書きから取り除く辛い作業は消えない。Sonarはこれを「大きな辛い仕事の移動」と言っている。下流にトリアージの形で再び現れる。その反復作業を自動化する : 古いPRをフラグ、レビューリクエストを振り分け、フォローアップを追跡する。シニア時間を本当に人間がいる部分に解放：チームが出荷したものを理解しているか判断する。 軌跡を測定しろ。満足度ではなく。AIで気分が良くて、6ヶ月後に自分たちのアーキテクチャを説明できないチームは、時間を節約していない。借金は返済しただけだ。金利は誰も書いてない。 ## FAQ ### AI技術的負債とコード負債、認知負債の違いは何か？ AI技術的負債は2つの問題に分かれます。コード負債は重複やパターン不一貫など、静的解析ツールで検出できる問題です。認知負債は、コードが生成される速度がチームが理解を構築する速度を上回ることで生じる、見えない負債です。 ### Sonarの調査でAIの悪影響はどの程度か？ Sonarの2026年開発者調査によると、開発者の88%がAIによる技術的負債への悪影響を報告し、53%がAIは見た目では正しいが隠れた欠陥を持つコードを生成すると述べています。40%は不要または重複するコード生成による負債の増加を報告しています。 ### AIはジュニアエンジニアのスキル成長に影響するか？ はい。Anthropicの52人ジュニア開発者を対象とした試験では、AI使用者はコード理解テストで17%低いスコアを記録しました。Infobipの225人インターン追跡調査では、AI前コホートは2.50ポイント、AI時代コホートは1.56ポイントのスキル向上に留まっています。 ### ジュニアエンジニアのAI利用を禁止すべきか？ いいえ。Infobipの実測データでは禁止が有効でなく、むしろ使用順序の工夫が機能します。問題を先に独立して解く、AIは次という順序と、AI無料チェックポイントにより、スキル成長が改善されました。 ### 認知負債を測定するにはどうするか？ ダッシュボードではなく、レトロで直接尋ねることです。システムのアーキテクチャ図を置き、チーム全員が各ボックスを説明できるかを確認します。1人だけが説明できるなら、認知負債が存在します。