10年前のコードを引き継いだ。コメントはほぼない。作った人間はもういない。このとき、AIに何をさせるべきか——答えは「書かせる」ではなく「読ませる」だ。
コードを書く時間より読む時間の方が10倍を超える
Robert C. Martinは著書 Clean Code のなかでこう述べている。「コードを読む時間と書く時間の比率は、ゆうに10対1を超える。だから読みやすいコードを書くことが、書く速さより圧倒的に重要なのだ」と。
実際の開発者の時間配分を見ると、この感覚はデータでも裏付けられている。The New Stackの調査によれば、開発者がコードを実際に書いている時間は全体の32%以下だ。残りの68%は会議、コードレビュー、バグ調査、ドキュメント読解、そして最も大きな割合を占める既存コードの理解に使われる。
2025年に発表されたCodeMapの研究論文（arXiv:2504.04553）はさらに踏み込んだ数字を出している。ソフトウェア開発における活動の58%が「プログラム理解活動」——コードを読んで、構造を把握して、「これは何をやっているのか」を理解する作業——に費やされていた。
コード生成にフォーカスしたAIツールは、開発時間のうち最も薄い部分に注目している。最も厚い部分——理解する、読む——は後回しにされてきた。
AIコーディングツールのほぼすべては「書く」で語られる
GitHub Copilot、Cursor、Claude Code——これらのプロモーションはどれも「速く書ける」「コードが自動で出てくる」という文脈だ。SNSでバズるのも「プロンプト一発でAPIが完成」「30分でアプリができた」という話だ。
この文脈は間違いではない。だがコードを一度も触ったことのない新規プロジェクトならともかく、実際の開発現場には必ず「すでに動いているコード」がある。引き継いだコードベース、3年前に誰かが書いたサービス、バグの原因を特定したい既存の処理——そこにAIを当てると、話が変わる。
Claude Code vs Cursor vs GitHub Copilotの2026年比較では、Claude Codeがレガシーコード理解において特に優れていると評価されている。「モジュールが実際に何をしているか（コメントの主張ではなく）を説明し、ロジックに焼き込まれた前提を特定し、変更リスクを浮かび上がらせる」能力だ。
新しいコードベースに携わる開発者がAIツールでどう変わるかについても数字がある。GitHubの調査では、新しいコードベースを担当した開発者がGitHub Copilotを使うことで25%速く作業を進められたという結果が出ている。速くなったのはコードを書く速度ではなく、コードを理解する速度だ。
また、Augment Codeは40万以上のファイルに及ぶ大規模コードベースのオンボーディングを6週間から6日に短縮した事例を持つ。コードベースを意味論的にインデックス化し、「このコードは何をしているか」を即座に問い合わせられる仕組みがそれを実現した。
Salesforceが証明した：2年の移行を4ヶ月で完了した理由
単なる「速くなった」という話ではなく、具体的なケースとして引用できるのがSalesforce Engineering Blogに掲載された事例だ。
SalesforceはOwn Archive managed packageをApexからJavaベースのCore基盤へ移行するプロジェクトを抱えていた。275のApexクラス、3,537ファイルが対象で、当初の見積もりは2年間だった。それをAI駆動のリファクタリングで4ヶ月に短縮した。
このプロジェクトで採用されたのが「葉ノードから移行する（leaf-to-root refactoring）」というアプローチだ。コードベースの依存関係グラフを把握し、他のコードに依存されていない「末端」のモジュールから順番に移行する。末端から始めれば、移行済みのコードが他の未移行コードに依存されることがなく、安全に進められる。
この判断——どこから始めるか——はAIなしには時間がかかる。数百のモジュールの依存関係を人間が手で把握するには数週間かかる。AIは数分でその地図を描く。移行の実行よりも、移行の準備にAIが効いた。
「書かせる」と「説明させる」の違い
実際のプロンプトの差を見てみよう。
❌ いきなり移行を指示する（理解が伴わない）
「このAPIエンドポイントを新しいフレームワークに移行して」
→ AIは機械的に変換する。
移行後のコードが何の前提条件を持っていたか、
どのモジュールに依存されているか、
副作用がないか——何も確認せずに進む。
✅ 先に説明させてから理解する
「このAPIエンドポイントは何をしているか教えて。
移行する前に、どんな前提条件や副作用があるかを確認したい。
特に他のモジュールとの依存関係を教えて」
→ AIは答える:
「このエンドポイントはX、Y、Zの3つのモジュールから
呼ばれており、Zのキャッシュ状態に依存している。
移行時にはZの初期化タイミングに注意が必要」
移行前に知っておくべきことが全部わかる。
このプロンプトの差は、結果の差に直結する。前者は「動いた」が後になって不具合が出る。後者は移行前にリスクが把握できる。
実践ワークフロー：コードベースを「読む」3ステップ
引き継いだコードベースや見慣れないリポジトリを理解するときの実践的なワークフローがある。
# ステップ1: 全体像を把握する
「このリポジトリの全体構造を説明して。
どのモジュールが最も重要か、依存関係はどうなっているか。
最も複雑な箇所はどこか」
→ AIがアーキテクチャの地図を描く。
どこから読み始めるべきかが分かる。
# ステップ2: ホットスポットを特定する
「このファイルが頻繁に変更されているようだが、
なぜこれが複雑なのか教えて。
どこが最もリスクが高い箇所か」
→ AIが「この関数はXとYとZの3つの処理を同時に担っている」
「コメントには〇〇と書いているが、実際は△△している」
と教えてくれる。
# ステップ3: 変更の影響を確認する
「この関数を変更する場合、どこに影響が出る可能性があるか。
テストが必要な箇所を全て挙げて。
変更によって壊れそうな箇所があれば教えて」
→ 移行や修正の前に「何を確認すべきか」が明確になる。
Salesforceのケースで採用された「葉ノード」アプローチも、このステップ2の延長線上にある。依存関係グラフを把握してはじめて、「どこから手を付けるべきか」が見える。
# Salesforce式：依存関係グラフから葉ノードを特定する
「このコードベースの依存関係を分析して。
最も依存されていない（他のモジュールから参照されていない）
モジュールはどれか。
安全に移行できる順番を教えて」
→ AIが依存関係の末端から順に列挙する。
どこから手を付ければ安全かが分かる。
AIが苦手なこと——「なぜ」の判断
AIはコードの構造とロジックを読む。だがコードには書かれていないことがある。
「なぜこの関数は3つの処理を1つに詰め込んでいるのか」という問いに対して、AIは「設計上の問題がある可能性があります」と答える。それは正しい。だが本当の理由は「当時のデプロイ制約で1ファイルしか変更できなかった」かもしれないし、「当時のチームリーダーの強いこだわりがあった」かもしれない。
コードは結果だ。判断の理由は、コメントに書かれていなければAIには読めない。引き継いだコードを前にした考古学者のアシスタントがAIだとすれば、遺跡の構造を分析して意味を解説するのはAIにできる。だがその遺跡が何のために建てられたかを判断するのは、人間にしかできない。
AIはコードが「何をしているか」を速く正確に説明できる。だが「なぜそうなっているか」——ビジネス上の判断、過去の経緯、当時の制約——はコードに書かれていないことが多い。AIの説明はスタート地点であって、最終判断は人間が担う。
index.devの開発者生産性統計（2026年）によれば、46%の開発者がAIの出力結果を完全には信頼していない。この数字は警戒心の表れではなく、健全な判断力の表れだと解釈できる。AIが出した「理解」を確認する習慣こそが、AIを正しく使う前提条件だ。
「書く機械」から「理解の相棒」へ
2026年時点で84%の開発者がすでにAIツールを使用しており、41%のコードがAI生成だという現実のなかで、使い方の差が結果の差になりつつある。
AIをコード生成マシンとして使うか、コード理解のパートナーとして使うか——この違いは短期的には見えにくい。だが積み重なると大きな差になる。生成したコードの意味がわからないまま積み上げると、後でそれを修正するときに同じ問いが戻ってくる——「これは何をしているのか」と。
引き継いだ10年物のコードも、自分が先週書いたコードも、3ヶ月後には「誰かが書いたコード」になる。そのときAIは、最初の問いに答えてくれる。
「これは何をしているのか」——その問いを正しく立てることが、AIを使いこなすということだ。