AIによるコード生成が当たり前になった今、エンジニアの生産性は劇的に向上している。しかし「コードを書くコスト」が下がるとき、別のコストが静かに積み上がっているとしたら？2000年代のオフショア開発ブームが残した教訓が、今まさに繰り返されようとしている。

コードが安くなると、コストは消えない

2000年代初頭、オフショア開発の波が世界を席巻した。トーマス・フリードマンが「フラット化する世界」を説き、米国のエンジニアが自分の仕事を心配していた時代。ある米国の医療記録転記サービス会社での経験が、今回の考察の原点だ。

オフショアチームのエンジニアは優秀だった。コードの品質も高かった。しかし必然的に、「なぜそう作ったか」という文脈が地球の裏側に残ったまま、保守責任だけがこちらに移ってくる瞬間があった。知識は「どこか」に存在した。ただ、必要なときに、必要な場所になかっただけだ。

AI生成コードは「意図」をどこにも残さない

今起きていることはその再演だが、構造的に一段深刻だ。

オフショア開発時代、知識は人間の頭の中にあった。バンガロールのエンジニアが意図を理解していた。伝達は難しくても、理解はどこかに存在した。

AI生成コードには、その人間がいない。コードは文法的に正しく、テストを通過し、出荷されるかもしれない。しかし「なぜこう作ったか」を知っている人間が、最初から存在しない。コミットされた瞬間、意図は宙に浮く。

経済学的に見れば、これは「インプットが安くなると、価値はその補完物にシフトする」という原則の再現だ。コード生成が安くなった今、価値がシフトしているのは「理解」だ。コードを安全に変更できる理解、プレッシャー下でデバッグできる理解、次の担当者に「なぜ」を説明できる理解。

実務での活用ポイント

日本のエンジニア・IT管理者がすぐに取り入れられる対策を整理する。

レビューの目的を変える: AI生成コードのレビューは「バグ探し」だけではもはや不十分だ。「この実装の意図は把握できるか」「半年後に自分が変更できるか」をレビュー項目に加える。

意図をコメントに残す役割分担を明示する: AIに「実装」は任せても、「なぜこのアプローチを選んだか」の記録は人間が書く。この分担をチームで明示的に決めておくだけで、後の混乱を大きく減らせる。

計測指標を見直す: 「コード行数」「PRのマージ速度」だけで生産性を測るのは危険だ。「理解可能なコードベースの維持」を明示的なエンジニアリング目標として設定することを検討してほしい。

AIをドキュメント生成にも使う逆転の発想: AIはコード生成だけでなく、既存コードの意図の文書化にも有効だ。「このコードは何をしているか、なぜこう設計されているか」をAIに分析させ、人間がそれをレビュー・修正する使い方は、今すぐ導入できる。

筆者の見解

AIを使い倒している立場から正直に言えば、この指摘は刺さる。

AIが生成するコードは「平均的に優秀」だ。動く。テストを通る。スピードは圧倒的だ。しかし「動くコード」と「理解できるコード」は別物であり、その差がじわじわと技術的負債として蓄積する。

オフショア時代に賢明な組織が学んだ教訓は「分散開発をやめる」ではなかった。共有コンテキストへの意図的な投資、コードレビュー、相互理解の構築という「遅い仕事」を大切にした組織が生き残った。今われわれに必要なのも、まったく同じことだ。

AIエージェントが自律的に動き続ける世界が本格化したとき、そのエージェントが生成するコードのコンテキストをどう維持するか——これは今から設計しておくべき問いだ。コードが安くなった分だけ、理解に投資する余力が生まれるはずだ。その余力を理解の向上に使うか、ただ出力量を増やすだけに使うか。そこに、この時代を生き残る組織とそうでない組織の分かれ目がある。

出典: この記事は What we lost the last time code got cheap の内容をもとに、筆者の見解を加えて独自に執筆したものです。