AIにリポジトリを読ませる前に「調査範囲」を固定するプロンプト

AIコーディングへ「このプロジェクトを調べて」と頼むと、便利な反面、依存物や生成物、設定ファイルまで読み始めてしまうことがあります。問題はAIの能力より、依頼の境界が曖昧なことです。

今回は、AIに渡す調査依頼を入口・対象・除外・変更禁止・質問条件・完了形式の6項目に分けます。これなら、調査と実装を混同せずに、次の会話へ渡す情報も小さくできます。

検証日：2026年7月25日。自作の小規模なディレクトリ構成を使用し、対象外の`secrets/`と依存物を含めずに調査結果をまとめられるかを確認しました。

「何を読むか」より先に「何を読まないか」を書く

最初の入口を`README`や`src/`に限定し、生成物、依存物、秘密情報、履歴ファイルを除外すると、調査の説明責任が上がります。不明な仕様があれば、AIが補完して先へ進むのではなく、質問として止まる条件も必要です。

実際に使ったプロンプト

小さな構成で試した結果

テストでは`README.md`、`src/`、`tests/`を対象にし、`secrets/`と`vendor/`を除外しました。結果は入口ファイル、処理の流れ、未確認の環境変数を分けて報告し、除外ディレクトリの内容を調査結果へ含めませんでした。

この形式の利点は、AIの報告に「確認していないこと」が残る点です。未確認が空欄のままだと、読んでいないのか、問題がなかったのか、判断できません。対象外を明示すれば、次に必要な権限や質問が見えます。

GitHub Copilotの指示ファイルとも考え方は同じ

GitHubの公式ドキュメントでは、リポジトリ全体、パス別、エージェント向けの指示を使い分けられます。ただし、利用できる指示形式は環境や機能で異なります。この記事の6項目は、特定製品の設定手順ではなく、どのAIコーディング環境でも最初の依頼に書ける調査の型です。

実案件での止めどころ

• 認証情報、顧客データ、本番設定、鍵ファイルがあり得る場所は最初から対象外にする。
• AIに実行や変更を許可する場合は、調査依頼とは別の指示として扱う。
• 対象外の情報が必要になったら、パスと理由を示して人の承認を得る。

まとめ：境界があると報告をレビューできる

リポジトリ調査では、広く読ませることより、どこまで読んだかを再現できることが重要です。最初に6項目を埋めてから依頼すれば、AIの報告を人が検証しやすくなります。

参考情報

• GitHub Docs：リポジトリのカスタム指示
• GitHub Docs：カスタム指示の対応範囲
• GitHub Docs：Copilotコードレビュー

本記事は、自作の小規模構成で調査依頼の出力形式を確認したものです。各AIツールの対応機能や権限は、導入環境の公式ドキュメントで確認してください。