コーディングエージェントが作業するとき、その手元では多くの bash コマンドが走っています。権限確認ダイアログや操作ログを眺めるとき、コマンドの意図が読めると「AI が何をしようとしているか」を自分で追跡・検証できるようになります。このガイドはコマンドの暗記ではなく、AI の確認行動のパターンを読む視点を身につけることを目的としています。

探索系 — 「どこにあるか」を調べる

AI がコーディングを始めるとき、まず行うのはリポジトリ全体の把握です。人間のエンジニアが新しいコードベースに入ったときと同じ順序を踏みます。

find はファイルシステムを再帰的に検索するコマンドです。AI はタスクに関係しそうなファイルを一覧するためにまず叩きます。

find . -name "*.rs" -type f
find . -name "*.toml" -type f

プロジェクト全体に Rust ファイルがいくつあるか、どこに配置されているかを把握することで、以降の作業のスコープを決めます。

grep または rg（ripgrep）は、コード内のシンボルや文字列を検索します。定義されている場所と参照されている場所を同時に探せるため、関数名や型名の依存関係を追うのに使われます。

grep -r "FunctionName" . --include="*.rs"
rg "FunctionName" --type rust

rg は grep -r より高速で、.gitignore を自動的に考慮します。AI がどちらを選ぶかは環境に入っているツールに依存します。

ls -la や tree はディレクトリ構造を俯瞰するためのコマンドです。AI はプロジェクトの全体感を掴むために使います。ls -la は隠しファイルも含めたファイル一覧と権限を、tree はネスト構造を視覚的に示します。

ls -la
tree -L 2

git 系 — 「なぜそうなっているか」を掘る

コードの現状だけでなく、変更の文脈を把握することが正確な判断につながります。AI が git コマンドを叩くのは「このコードがいつ・なぜこうなったか」を確認するためです。

git log --oneline は最近のコミット履歴を一覧します。どのような変更が積み重なっているかを掴み、自分の変更が適切な流れにあるかを確かめます。

git log --oneline -20

git diff は作業ツリーの変更内容を確認します。AI がファイルを編集する前後に使い、意図した変更だけが含まれているかを検証します。

git diff
git diff HEAD

git blame は各行がどのコミットで変更されたかを表示します。バグが混入したタイミングを特定したり、変更の意図を追ったりするために使います。

git blame src/main.rs

git show は特定コミットの変更内容を確認します。git log で見つけたハッシュを深掘りする際に使います。

git show a1b2c3d

テキスト処理系 — 「出力を整形・抽出する」

コマンドの出力は生のままでは扱いにくいことが多いです。AI は必要な情報だけを取り出すためにパイプラインを組みます。

jq は JSON を整形・抽出するコマンドです。API レスポンスや設定ファイルの確認、必要なフィールドだけの抜き出しに使います。

cat config.json | jq '.database.host'
curl -s https://api.example.com/status | jq '.'

grep -E と sed はパターンマッチと置換のための基本ツールです。ログの中から特定の行を絞り込んだり、文字列を軽微に変換したりするために使います。

grep -E "ERROR|WARN" app.log
sed 's/old_value/new_value/g' config.txt

sort | uniq -c | sort -rn は出現頻度の集計を行う定番パイプラインです。ログ分析でどのエラーが多いかを調べるときなどに AI がよく組み合わせます。

grep "ERROR" app.log | sort | uniq -c | sort -rn

wc -l はファイルの行数を確認します。大きなファイルを編集する前に規模感を掴むために使います。

wc -l src/main.rs

実行・環境確認系 — 「今どういう状態か」を把握する

コードを変更するだけでなく、環境の状態を確認することも作業の一部です。AI が環境系コマンドを使うのは、実行に必要な条件が整っているかを検証するためです。

which / command -v はコマンドがインストールされているか、どのパスが使われるかを確認します。ツールが存在しない環境でのエラーを避けるための事前確認です。

which rg
command -v cargo

env / printenv は環境変数を一覧または特定の変数を確認します。設定ミスや意図しない値の混入を発見するために使います。

printenv DATABASE_URL
env | grep AWS

curl -I は HTTP ヘッダーだけを取得するオプションです。エンドポイントが生きているか、リダイレクトが正しく設定されているかを確認します。

curl -I https://api.example.com/health

ps aux | grep <process> はプロセスの一覧を確認します。サーバーが本当に起動しているかを確かめるために使います。

ps aux | grep nginx

lsof -i は特定ポートを使用しているプロセスを特定します。「ポートがすでに使われている」というエラーの原因を診断するために使います。

lsof -i :8080

パターンとして覚える——AI の「型」

個々のコマンドを覚えるより、AI がコマンドを叩く順序のパターンを把握する方が実用的です。多くの場合、次のような流れをたどります。

  1. find / ls / tree で全体の構造を掴む
  2. grep / rg で関心のある箇所を絞り込む
  3. git log / git diff で変更の文脈を確認する
  4. 実行・変更して curl / ps / lsof で結果を確認する

このパターンを知っていると、権限確認ダイアログに長いコマンドが表示されたときでも「今どのフェーズにいるか」が読めるようになります。「なぜこのコマンドが実行されるのか」が分かると、承認か拒否かの判断もより根拠を持てます。

まとめ

  • AI がコマンドを叩く目的は「現状の把握」「変更の文脈の確認」「実行後の検証」の 3 つに大別できます。
  • コマンドを個別に暗記するより、探索 → 絞り込み → 文脈確認 → 結果確認というパターンとして捉える方が、AI の行動を読みやすくなります。
  • コマンドの意図が理解できると、操作ログや権限ダイアログを「ただ承認するだけ」でなく、AI が正しい方向に進んでいるかを自分で判断する材料として使えます。