AIがコードを10倍速く書く世界で——実装と理解の致命的な乖離
2026.06.04執筆者：DigKnow株式会社 CTO 桑原 脩
ここ一年で、チームが書くコードの量は明らかに増えています。PRの数も、マージの頻度も、デプロイの回数も。でも同じ期間、ドキュメントのページ数はほとんど変わっていません——むしろ、差し引きでは減っているかもしれません。コードは10倍速く書かれるようになりました。では、そのコードを「なぜそうなっているか」まで含めて理解する速度は、10倍になったでしょうか。
コードは10倍速くなった。では、理解は何倍速くなったか
AIコーディングで、コードを書く速度は上がりました。体感で2倍、5倍、10倍と言う人もいます。数字の正確さはいったん置いておきましょう。問題はその先です。
コードを書く速度が10倍になったとき、コードを理解する速度は何倍になったでしょうか。
答えは、だいたいの現場で、1倍のままです。人間の脳の処理能力は、AIが実装を加速させても変わりません。一日に読めるコードの量、把握できる設計の複雑さ、思考を巡らせられる時間——これらはAI以前とほとんど同じです。一方で「書かれる量」が10倍になった。
この差分が、いま、開発現場で静かに積み上がっている「何か」の正体です。実装と理解の乖離が、目に見えにくい形で広がっている——これが、いま起きている現象の本質だと考えています。
ドキュメントは「相対的に」足りなくなる
この乖離が最初に現れる場所のひとつが、ドキュメントです。書かれなくなったわけではないし、既存のものが削除されたわけでもありません。起きているのは、もっと地味で厄介な現象です。書かれる量は同じか微減しているのに、説明されるべきコードの量が急増している。
これはインフレと同じ構造です。貨幣の価値が下がるのは、貨幣そのものが傷んだからではありません。市場に出回る量に対して、裏付けとなるものが追いつかないから、相対的な価値が下がるのです。
具体的に考えてみましょう。AI導入前、あるチームが1スプリントで書くコードが100ファイル、そのうち重要な20ファイル分については、PRの説明やレビューコメント、Slackでの議論といった形で、何らかの文脈が周辺に残っていたとします。完璧ではないにせよ、2割くらいは「なぜ」が追える状態でした。
AI導入後、同じチームが同じ期間で書くコードが300ファイルになる。書いている側の人数・労働時間は同じなので、文脈を残す活動に使える時間はほぼ変わりません。結果、文脈付きの20ファイルは維持されますが、残りの280ファイルは「動くコードだけ」の状態になる。文脈付きの比率は20%から7%弱に落ちます。
そしてこの比率の低下は、コードベースの健康診断には反映されません。テストは通る。デプロイは成功する。売上も立つ。表面上の数字は、むしろ良くなっている。だから誰にも気づかれないまま進行するのです。
ドキュメントが足りないと感じる本当の理由は、書かれていないからではなく、コードの海のなかで比率として溺れている、ということなのだと思います。
ドキュメントが追いつけない、四つの構造的な理由
「人が怠けているから」で片付けていたら、この問題はずっと解けません。私が観察してきた範囲では、四つの構造的な理由が噛み合っています。
①：生成と説明の所要時間が非対称すぎる。 AIがコードを生成するのは秒単位です。一方、「なぜそう書かれているか」を人間が言語化するには分〜時間単位の時間がかかります。実装より説明のほうが時間がかかることすらある。合理的に動く人間は、そのコストを払わずに次のタスクに進みます。
②：書き手の中にも「なぜ」が明確に存在しない。 AIとの対話で生まれたコードについて、書いた本人でさえ細部の理由を即答できないケースが増えています。「AIがそう提案したから、違和感がなかったから採用した」——これは意思決定ではありますが、言語化できる種類のものではありません。書き手の中に明示的な「なぜ」がない状態で、ドキュメントだけが立派に書けるわけがないのです。
③：ドキュメントの鮮度が、コードの変化速度に追いつけない。 仮に頑張って書いたとしても、AIコーディング時代のコードは頻繁に書き換わります。先月の設計ドキュメントが今月のリファクタで実態と乖離する。そしてさらに厄介なのは、古いドキュメントは、ないよりも悪いということです。一度信頼を失ったドキュメントは、ますます読まれず、メンテされなくなっていきます。
④：成果物の評価軸に「理解可能性」が入っていない。 ほとんどの現場で評価されるのは「動いた」「リリースした」「スペックを満たした」です。「三ヶ月後に他人が読んで理解できる形になっている」という軸はKPIに入っていません。入っていないものには時間が使われない。これは道徳の話ではなく、ただの組織の物理です。
この四つは互いに強化し合っています。ひとつずつ潰そうとしても、他の三つが引き戻してくる。「ドキュメントを書こう」という号令が毎回失敗する理由の核心はここにあります。個人の意志の問題ではなく、構造の問題なのです。
乖離が生むコストは、静かに、しかし確実に膨らむ
速度の乖離の本当の厄介さは、発生するコストが、見えにくい場所で時間差で膨らむことにあります。時間軸で整理してみます。
短期（数週間〜数ヶ月）。 コードレビューの質が落ちていきます。「何をしているか」は追えても「なぜそうなっているか」を判断する材料がないので、レビューは「動けばOK」に寄っていく。似たロジックが別の場所に微妙に違う形で重複実装されていく。コードベースは増え続けるのに、情報量としては薄まっていく現象が始まります。
中期（半年〜数年）。 人材の生産性に直接効いてきます。新人のキャッチアップが長期化する。退職時の引き継ぎコストが膨らむ。障害対応では、「本来どういう設計だったか」を踏まえた一次調査ができず、手探りの試行錯誤になる。平均復旧時間が伸びていくチームは多いですが、その原因の一定部分は、この乖離の蓄積にあると私は見ています。
長期（数年〜十年）。 ここがいちばん怖いところです。長期コストはもはや「コスト」という言葉では足りない、組織の戦略的自由度の喪失として現れます。
「このシステムをリプレイスすべきか」「このモジュールを切り出せるか」——こうした経営レベルの意思決定には、全体像と設計の経緯を理解している人が必要です。乖離が長年積み上がったシステムでは、その「理解している人」が社内にいない。判断を下せない。結果、現状維持を選び続けるしかない状況に追い込まれていきます。
ここで起きているのは、もはや技術的負債ではなく、意思決定の麻痺です。技術的負債なら、人を増やすか時間をかければ返済できます。しかし意思決定の麻痺は、「何を返すべきか」を判断する材料そのものが失われた状態であり、お金や人を投入しても解けません。整備を発注しようにも、何を発注すればいいか、どこから手をつければいいかが、社内の誰にもわからない。変えたくても、変えるための前提情報が社内にない、という地点に到達してしまっているのです。
そしてこの麻痺が怖いのは、発生した時点ではもう対処が遅いということです。意思決定が止まってから「ドキュメントを整備しよう」と言っても、その整備自体を誰がやるのか、という問いに答えられないからです。
速度の乖離は、それ自体が問題なのではありません。時間とともに複利で積み上がり、数年後には組織の選択肢そのものを奪う、というところまで射程に入れて考えるべき問題なのだと思います。
これは「ツールの話」ではなく、「スピードと理解の設計の話」
誤解されたくないことがひとつあります。私自身はAIコーディングをやめろと言っているわけではありません。Claude Codeを毎日使っていて、その恩恵は本当に大きい。以前の働き方には戻りたくないのです。
問題は、AIが加速させたスピードに対して、理解を保つ仕組みの側が何もアップデートされていないことです。実装の速度だけが10倍になり、理解の速度は1倍のまま。この不均衡を放置することは、車のエンジンをスーパーチャージャー付きに積み替えたのに、ブレーキは自転車のままにしておくような状態に近い。速くなったのはよい。でも、止まれないし曲がれません。
従来のアプローチ——「ドキュメントを書く文化を作ろう」「レビューを厳しくしよう」「ルールを徹底しよう」——は、どれも「人間が頑張って書く」ことに依存しています。AI以前の速度なら、それでどうにか釣り合っていた。AI以降の速度では、人間側のスループットが絶望的に足りません。頑張り方の問題ではなく、仕組みの構造を変える話になっているのです。
方向性だけ言えば、二つあると考えています。ひとつは、「書くコスト」そのものをゼロに近づけること。もうひとつは、「書かなくても残る」仕組みを設計すること——コミット履歴やPRの議論など、開発過程で自然に発生する情報から、「なぜ」を復元できる形で残していく方向です。このどちらか、あるいは両方を真剣に考えない限り、速度の乖離は埋まりません。
AIが実装を加速させたなら、AIが理解も加速させられるはずだ——というのが、この一年ずっと考え続けている仮説であり、以前の記事の「コードは残るが、仕様は誰も知らない」で描いた構造問題の、解決の方向性にもなると考えています。
まとめ
AIコーディングはコードを書く速度を劇的に上げました。しかし人間が理解する速度は変わっていません。この10倍と1倍の差が、いま開発現場に静かな乖離を生んでいます。乖離は短期では品質劣化、中期では引き継ぎコスト、長期では意思決定の麻痺として現れます。「書こう」という号令では間に合いません。書くコストをゼロに近づけるか、書かずに残る仕組みを作るか——発想を移すタイミングに来ています。
あなたのチームが先月書いたコードのうち、三ヶ月後の誰かが「なぜそうなっているか」を追える状態になっているのは、何パーセントでしょうか。その比率は、一年前と比べて上がっていますか、それとも下がっていますか。
次回は、この乖離が生む新しい現象——「AIが書いたコードだから」という言葉で、責任の所在が溶けていく現場を掘り下げていきます。コードは誰のものか、という古くて新しい問いに、AI時代の答えを探っていきます。