Copilot Chatは「コードを読むツール」として使える

はじめに

GMOコネクトの石井です。

途中参加したプロジェクトのソースコードを前にして「で、これ全体像どうなってるの？」と途方に暮れた経験、ありませんか😇

800超のJavaファイル、150超のディレクトリ。READMEは最低限。設計書は古い。手作業でディレクトリを追い始めたものの、30分経っても全貌が見えない。そこでGitHub Copilot Chatにディレクトリ構成を丸ごと食わせてみたところ、数分でプロジェクトの地図が手に入りました。おまけに、誰も気づいていなかったパッケージ名のスペルミスまで見つかりました。

先にまとめ

• tree コマンドの出力をCopilot Chatに貼るだけで、技術スタック・レイヤー構成・各パッケージの責務が数分で整理できる
• AIの「初見の目」が、人間が慣れで見逃していた命名不備を3件以上検出した
• コード自動生成だけがCopilotの使い方ではない。「静的解析・コードレビュー」的な活用が、リファクタリングの第一歩として強力

やりたかったこと

あるSpring Boot + Thymeleafのプロジェクトに途中からアサインされました。規模感はこんな感じです。

項目	数値
Javaファイル数	約800
ディレクトリ数	約150
フレームワーク	Spring Boot 4.x + Thymeleaf + Spring Data JPA
Java バージョン	21

ディレクトリ構成を見ると、業務ドメインごとにパッケージが切られていて、さらに common、backend、core といった共通層が入り組んでいます。

src/main/java/com/example/myapp/
├── PortalApplication.java
├── SecurityConfig.java
├── InterceptorConfig.java
├── common/
│   ├── backend/
│   ├── bean/
│   ├── constants/
│   ├── db/（entity, repository, service）
│   ├── lib/
│   ├── session/
│   ├── web/
│   │   └── regacyAbstruct/    ← ？
│   └── util/
├── serviceA/（業務ドメインA）
│   ├── common/
│   │   ├── backend/
│   │   ├── interceptor/
│   │   ├── fastplan/
│   │   └── ...
│   ├── contract/
│   ├── order/
│   └── ...
├── serviceB/（業務ドメインB）
│   └── mail/
├── option/
├── plan/
└── init/

手作業で一つずつ開いて中身を確認する？ 約800ファイルを？ 無理です。

Copilot Chatにディレクトリ構成を渡してみた

やったことはシンプルです。

tree src/main/java -d

この出力をCopilot Chatに貼り付けて、こう聞きました。

このプロジェクトのディレクトリ構成を解析して

すると、Copilotはこんな趣旨の回答を返してきました（要約）。

技術スタック判定
Spring Boot + Thymeleaf + Spring Data JPA のWebアプリケーション。SecurityConfigとInterceptorConfigから、認証・認可とリクエスト制御の仕組みが入っている。

レイヤー構成

• common/ 配下にDB層（entity/repository/service）、セッション管理、バリデーション等の横断的関心事が集約
• 業務ドメインはサービス単位でパッケージが分離されている
• 各ドメイン内にも common/ が存在し、ドメイン固有の共通処理を持つ

パッケージ責務の推定
backend/mapper/impl → バックエンドAPIとのマッピング層、interceptor → 認証チェック用のインターセプター、order/plan → 注文・プラン管理の業務ロジック...

手作業なら1時間コースの整理が、数分で返ってきました。もちろん推定なので100%正確ではありませんが、全体像の初期仮説としては十分で、ここからコードを読むとっかかりが全然違います。

この「地図」がどう役立ったか

Copilotが出してくれた構成解析は、そのままプロジェクトの読み方ガイドになりました。

たとえば「契約情報の表示ロジックを修正してほしい」というタスクが来たとき、Copilotの解析結果から serviceA/contract/ 配下を起点にすればいいと分かります。さらに「ドメイン固有の共通処理は serviceA/common/ にある」と把握できているので、共通部品の探索範囲も絞れます。

解析前は「どこに何があるか分からないので片っ端から grep する」状態でしたが、解析後は「このあたりにあるはず」という当たりを付けてからコードに入れるようになりました。

構成解析の精度はどのくらいか

Copilotが返した推定を実際のコードと照合してみると、技術スタックの判定は正確でした。レイヤー構成の説明もおおむね合っていて、パッケージ責務の推定は7〜8割くらいの感覚です。

外したのは init/ パッケージの役割で、Copilotは「初期化処理」と推定しましたが、実際はアプリ起動時の商品マスタ読み込みに特化したパッケージでした。ただ、方向性は大きく外れておらず、「初期化っぽい何か」という仮説から実コードを読めば数分で正解にたどり着けます。

100%正確である必要はありません。全体の方向感が分かるだけで、コードリーディングの効率は大きく変わります。

副産物：AIが見つけた命名不備

構成解析が主目的でしたが、Copilotの回答の末尾に予想外の指摘が含まれていました。

注目すべき命名ミス
src/test/java/ 配下のパッケージ名が protal になっている → 正しくは portal ではないか

これをきっかけに改めてディレクトリ名を見直したところ、合計3件の命名不備が見つかりました。

種類	現状	正しくは	場所
パッケージ名のタイポ	protal	portal	テストパッケージ、pom.xml の groupId
二重スペルミス	regacyAbstruct	legacyAbstract	ディレクトリ名
クラス名の表記ゆらぎ	FastPlan と Fastplan が混在	どちらかに統一	同一パッケージ内のクラス名

いずれもビルドは通るし、テストも動く。だからこそ誰も気づかなかったわけです。毎日見ていれば見慣れるし、IDEの補完で入力するからスペルを意識する機会もない。AIにはこの「慣れ」がないので、初見の目でさらっと拾ってくれます。

プロンプトのコツ

実際に試して効果的だったプロンプトのパターンを整理します。

Step 1: まず全体像を掴む

このプロジェクトのディレクトリ構成を解析して

これだけで技術スタックの判定、レイヤー構成の解説、各パッケージの責務推定が返ってきます。tree -d の出力を添えるのがポイントです。ファイル単位まで出すとトークンを食いすぎるので、ディレクトリだけで十分です。

Step 2: 命名の不整合を明示的に聞く

ディレクトリ名やパッケージ名に、スペルミスや命名規則の不統一がないか指摘して

Step 1の回答でもタイポは見つかりましたが、明示的に聞くとより網羅的に検出してくれます。「命名規則の不統一」と入れることで、snake_case と camelCase の混在のような表記ゆらぎも拾ってくれました。

Step 3: 設計パターンの一貫性を確認する

各パッケージの構成パターンに一貫性があるか確認して。
パッケージごとに異なる設計パターンが使われている箇所があれば指摘して。

これは構成解析の発展形です。「このドメインには mapper 層があるのに、あのドメインにはない」といった構造の非対称性を指摘してくれます。

コツのまとめ

プロンプト	得られるもの
構成を解析して	技術スタック・レイヤー構成・責務の俯瞰
命名の不整合を指摘して	タイポ・表記ゆらぎ・規則違反
設計パターンの一貫性を確認して	構造の非対称性・リファクタリング候補

段階を分けて聞くのがコツです。一度に全部聞くと回答が浅くなりがちでした。

まとめ

• tree -d の出力をCopilot Chatに渡すだけで、約150ディレクトリ・約800ファイルのプロジェクト構成が数分で整理できた
• AIの「初見の目」が、パッケージ名のタイポ（protal）、二重スペルミス（regacyAbstruct）、表記ゆらぎ（FastPlan / Fastplan）を検出した。人間が慣れで見逃す命名不備を、先入観なく拾ってくれる
• Copilotは「コードを書くツール」だけではなく、「コードを読むツール」として使える