AIと読む他人のコード：リポジトリ調査の型
初めて触るリポジトリを前に、どこから読めばいいかわからず手が止まることがあります。AIコーディングエージェントを調査の相棒にすることで、全体像の把握を大きく効率化できます。
最終更新: 2026-07-23・読了目安 約3分
いきなり細部を読まない
初めて触るリポジトリを前にすると、つい最初のファイルから順番に読み込みたくなりますが、これは非効率になりがちです。全体像を把握しないまま細部を読むと、その処理が全体の中でどんな役割を持つのかがわからず、理解に時間がかかります。
先に「このリポジトリは何をするものか」「主な処理の入り口はどこか」という全体像をつかんでから、必要な部分だけを深掘りする順番の方が、結果的に早く目的の理解に到達できます。GitHub公式のドキュメントでも、ファイルやシンボルを横断的に検索してコードを探索する機能が紹介されており、全体像を素早くつかむ手段として参考になります（出典：GitHub Docs「Navigating code on GitHub」）。
AIに全体像を聞く質問の型
AIコーディングエージェントは、リポジトリ内のファイルを横断的に読み、要約することが得意です。次のような質問から始めると、全体像を効率よくつかめます。
- 「このリポジトリが何をするものか、主な機能を要約してください」
- 「ディレクトリ構成と、それぞれの役割を教えてください」
- 「ユーザーの操作が実行されるまでの処理の流れを、入り口から順に説明してください」
- 「このプロジェクトで使われている主要なライブラリや設計上のパターンは何ですか」
これらの質問への回答は、AIの要約が完全に正しいとは限りません。回答を鵜呑みにせず、気になった箇所は実際のファイルを開いて確認する姿勢はAIが書いたコードのテストとレビューと同様に重要です。
機能追加・修正の前に調査する型
既存のリポジトリに機能を追加したり、バグを修正したりする前は、いきなり実装を頼むのではなく、まず影響範囲を調査させることをおすすめします。
- 「この機能に関連するファイルをすべて挙げてください」
- 「この変更を加えると、他にどこへ影響が及ぶ可能性がありますか」
- 「同じような処理が他の場所にも重複して存在していませんか」
この調査を挟むことで、AIは変更の実装前に必要な文脈を持てるようになり、影響範囲を見落とした実装を防ぎやすくなります。調査結果をもとに仕様を固める流れはDESIGN.mdテンプレート実例とも接続します。
わからない用語はその場で確認する
コードリーディング中に知らない用語やライブラリ名が出てきたら、読み飛ばさずその場でAIに確認しましょう。「このコードで使われている〇〇という関数は何をするものですか」のように、具体的なコード片を示しながら質問すると、一般的な説明ではなく、そのリポジトリの文脈に沿った回答が得やすくなります。調査中に見つけたエラーへの対処はエラーをAIに直させる手順も参考にしてください。
よくある失敗パターン
- いきなり細部から読み始める：全体像がないまま細部を追い、時間がかかる。
- AIの要約を検証せず鵜呑みにする：要約は間違っていることがあるため、重要な判断の前には実ファイルで裏取りする。
- 影響範囲を調べずに変更する：関連箇所を見落とし、別の場所を壊してしまう。
- わからない用語を放置する：後から理解が追いつかなくなる原因になる。
コードを読んで理解することと、そのコードが安全かどうかは別の観点です。公開前にはAIが生成したコードのセキュリティ確認：最低限のチェックリストもあわせて確認してください。
よくある質問
Q1. 初めてのリポジトリはどこから読み始めるべきですか？
最初のファイルから順に読むのではなく、まずAIに全体像を要約させることをおすすめします。「主な機能」「ディレクトリ構成」「処理の入り口」を先に把握してから、必要な部分だけを深掘りする順番の方が効率的です。
Q2. AIの要約はどこまで信じてよいですか？
AIの要約が完全に正しいとは限りません。重要な判断の前には、気になった箇所を実際のファイルで確認する姿勢が必要です。要約はあくまで理解を早めるための出発点として扱いましょう。
Q3. 機能追加の前に何を調査させればよいですか？
「関連するファイルをすべて挙げてください」「この変更が他にどこへ影響しますか」のように、実装前に影響範囲を調査させます。これにより、変更の影響を見落とした実装を防ぎやすくなります。AIへのレビュー依頼の言い回しはAIへのレビュー依頼フレーズ集も参考になります。