不具合調査や仕様確認をするとき、最近はまず自分でファイルを探すのではなく、GPTのLunaというモデルに調査を任せます。依頼する内容は、「この不具合を調査して」「仕様はどうなっている？」「ユーザーの言っていることは正しい？」「この機能追加で修正が必要なファイルを列挙して」などです。調査結果に納得できれば、そのまま修正や次の相談へ進む。
便利になった一方で、AIに任せるほど自分の調査能力が落ちる気がしてきました。
AIが使えない状況になったら、同じ調査を自分で進められる自信がなくなってきた。
仕事でGitHub Copilotを使っていると、VS Codeのチャットウィンドウの裏でAIがコマンドを実行しているのが見えます。検索、ファイル一覧、Gitの履歴確認。やっていることは、以前自分が手作業でやっていた調査の延長に見えました。そこで、AIと同じ速さではなくても、自分で再現できる調査の型を整えることにしました。
昔はファイルを全部検索して、資料を最初から読んでいた
以前は、まずファイルを横断検索し、関連しそうな設計資料とマニュアルを見つけたら最初から読み始めていました。設計書が100%正しいか分からないので、最後はコードを確認する。
設計書を読む、コードを読む、マニュアルを見て設計書に戻り、さらにコードを見る。順番も関係なく、しらみつぶしに行き来していて、特段の順番や型といったものはありませんでした。
入社したての頃、先輩にサクラエディタのGrepで検索して調べる方法を教えてもらいました。それ以来、検索はよく使っていました。VS Codeに移ってからは、標準の検索機能を使っています。
今振り返ると、問題はコマンドを知らなかったことだけではありませんでした。検索して、候補を絞り、関連箇所をたどり、最後にテストや履歴で確かめる、という順番を持っていませんでした。
AIがやっていることを見ていると、最初からリポジトリ全体を読んでいるわけではありません。手掛かりを検索し、結果を見て次の検索語を決め、必要な範囲だけを読んでいます。
まずrgを使える環境を整える
WindowsとWSLは別の環境です。Windows側にrgを入れていても、WSLのLinux環境でそのまま使えるとは限りません。それぞれの環境にインストールして、実行場所を確認します。
Windows
PowerShellまたはWindows Terminalから、WinGetでインストールできます。
winget install BurntSushi.ripgrep.MSVC
インストール後にターミナルを開き直し、次のコマンドで確認します。
rg --version
Get-Command rg
where.exe rg
今回のWindows環境では、C:\Users\<ユーザー名>\AppData\Local\Microsoft\WinGet\Links\rg.exeから実行されていました。ripgrepの公式インストール手順にも、WinGetを使った方法が載っています。
WSL
UbuntuやDebian系のディストリビューションでは、aptでインストールできます。
sudo apt update
sudo apt install ripgrep
インストール後は、Linux側のrgが使われているか確認します。
rg --version
command -v rg
command -v rgの結果が/usr/bin/rgなら、WSL側にインストールしたrgです。Windows側のrg.exeが表示される場合は、WSLのPATH経由でWindowsの実行ファイルを呼び出しています。WSLの環境やパッケージ管理については、MicrosoftのWSL公式チュートリアルも参考になります。
調査の型と、よく使うコマンド
調査を進めるときの型は、次のように整理してみました。
- ファイル構成を確認する
- 手掛かりを全文検索する
- 関数やクラスの呼び出し関係をたどる
- 必要な範囲だけ読む
- 設計資料、テスト、Git履歴を照合する
- テストや差分で仮説を検証する
この順番を意識しながら、AIが行う調査を自分でも再現するために、よく使うコマンドを整理します。コマンドの名前を暗記することよりも、それで何を確認したいのかを理解することを重視しています。
1. リポジトリの全体像を把握する
最初に確認するのは、どのようなファイルが存在するかです。
# リポジトリ内のファイルを一覧表示する
rg --files
# Markdownだけに絞る
rg --files -g "*.md"
# ファイル名に user を含むものを探す
rg --files | rg -i "user"
rgはripgrepという検索ツールです。用途はgrepに近いですが、コード調査では、サブディレクトリを含めて速く検索でき、.gitignoreの対象を自動で除外してくれる点が便利です。詳しい使い方は、ripgrepの公式リポジトリや公式ガイドで確認できます。
この段階では、ファイルの中身を詳しく読む必要はありません。設計資料、テスト、画面、設定の場所を把握するだけで、次の検索の方向が決まります。
2. エラーや機能名を全文検索する
次に、ユーザーの言葉や画面に表示されたエラー、機能名を検索します。
# 文字列を検索する。行番号も表示する
rg -n "エラーメッセージ"
# 大文字・小文字を区別しない
rg -n -i "username"
# Markdownだけを検索する
rg -n "ログイン" -g "*.md"
# ヒットした行の前後3行も表示する
rg -n -C 3 "エラーメッセージ"
検索条件をもう少し細かく指定することもできます。
# 正規表現ではなく、文字列として検索する
rg -n -F "Order[0].Id"
# 単語単位で検索する
rg -n -w "UserService"
# ヒットしたファイル名だけを表示する
rg -l "UserService"
# 隠しファイルも検索対象にする
rg --hidden -n "DATABASE_URL"
-Fは記号を正規表現として扱わず、-wは単語単位で検索します。-lを使うと、結果を読む前に調査対象のファイルだけを絞り込めます。設定ファイルなどが検索に出てこないときは--hiddenを試します。
rgはgrepそのものではありませんが、同じように文字列を探すための別のツールです。-nは行番号、-iは大文字・小文字を無視、-C 3は前後3行を表示する指定です。
検索語は一つで終わりません。画面の文言から関数名が見つかったら、その関数名をもう一度検索する。クラス名が見つかったら、呼び出し元を検索する。AIはこの検索を何度も繰り返して、調査対象を狭めています。
3. 見つかった実装の周辺だけを読む
検索結果が出たら、該当箇所の周辺を読みます。最初からファイル全体を表示するのではなく、必要な行だけを確認します。
# 100行目から160行目まで表示する
sed -n '100,160p' path/to/file
検索結果の周辺だけでは足りなければ、少しずつ読む範囲を広げます。これだけでも、「関連しそうなファイルを全部開いて迷子になる」ことが減ります。sedの詳細は、GNU sedの公式マニュアルにまとまっています。
4. Gitの履歴から変更理由を確認する
現在のコードと設計資料が一致しないとき、どちらかを見てすぐに正しいと判断するのは危険です。変更の経緯を確認します。
# ファイルの変更履歴を見る
git log -- path/to/file
# 各行を最後に変更したコミットを見る
git blame path/to/file
# 特定のコミットの変更内容を見る
git show <commit-id>
# 特定の文字列が追加・削除された履歴を探す
git log -S "createUser" --oneline
設計資料が古いのか、実装が仕様から外れているのか、途中で仕様が変わったのか。コードだけでは判断しにくい問題でも、履歴を見ると手掛かりが残っていることがあります。各コマンドの詳細は、git log、git blame、git showの公式ドキュメントで確認できます。
5. 仮説をテストや差分で確かめる
最後に、調査結果から立てた仮説を検証します。
# 自分の作業ツリーの状態を確認する
git status
# 変更内容を確認する
git diff
# プロジェクトに合わせてテストや静的チェックを実行する
npm test
npm run lint
実際のコマンドはプロジェクトによって変わります。大事なのは、「ここが原因だと思う」と説明して終わらず、テストや差分で本当にそうかを確認することです。git statusとgit diffの詳細は、git statusとgit diffの公式ドキュメントで確認できます。
AIがなくても「同じ速さ」ではなく「同じ型」を再現する
AIと同じ速さで調査するのは難しいです。検索範囲も試行回数も、AIのほうが多くなりやすいからです。疲れずに検索を繰り返せる点でも、手作業より有利です。
ただ、調査の型は自分のものにできます。
この順番があれば、AIが使えないときにも、以前のように闇雲にファイルを開き続けずに済みますし、AIが出した調査結果の妥当性も確認できます。
現時点の判断
現時点では、不具合や仕様の調査はAIに任せるほうが効率的です。それでも、最終的な設計判断や調査結果の確認まで任せきりにはしない。AIが使えないときに完全に同じ速度で動く必要はありませんが、同じ調査の型を自分で再現できる状態にはしておかないとまずいと考えています。
GPTのLunaに短い指示で調査を任せるようになった背景については、GPT-5.6で巨大なプロンプトを書くのをやめたにも書いています。
コメント