AI コーディングアシスタントが裏側で使うツールとは？

Claude Code・Codex CLI・Aider がファイルを読み、コードベースを検索し、テストを実行してコミットする仕組み

AI コーディングアシスタントは、まるで魔法のように感じられます。「ダッシュボードにログインフォームを追加して」と入力すると、ツールが適切なファイルを見つけ、コンポーネントを書き、コンパイルが通るか確認し、テストを実行して、git diff を表示してくれます。

しかし、そこに魔法はありません。数十年前からマシンに存在する、同じ Unix シェルツールを呼び出すループがあるだけです。

このガイドでは、AI コーディングアシスタントが動作するときに実際に何のプログラムが動くのか、それがパフォーマンスとセキュリティにどう影響するか、そして自分でアシスタントを作りたいときに知っておくべきことを解説します。

対象読者: Claude Code、GitHub Copilot、Cursorをすでに使っている開発者で、内部の仕組みをより深く理解したい方。

AI コーディングアシスタントの動作原理：エージェントループ

主要なコーディングアシスタント — Claude Code、OpenAI Codex CLI、Aider、Cline、Cursor — はすべて同じ基本的なエージェントループに従います：

1. プロンプトを受け取る
2. 考える：どんなコンテキストが必要か？
3. ツールを呼び出す（rg, cat, git, npm...）
4. 出力を観察する
5. 考える：次のステップは何か？
6. タスクが完了するまで繰り返す

LLM が頭脳であり、シェルツールが手です。アシスタントがやっていることは、ターミナルで手動でできないことは何もありません。ただ、各ステップを尋ねることなく、より速く実行しているだけです。

ツールを理解することで、システム全体の謎が解けます。

1. 検索ツール：AI がコードベースを読む方法

AI コーディングアシスタントが1行でもコードを書く前に、既存のコードを理解する必要があります。これは、開発者が毎日使うのと同じ検索ツールで行われます。

ripgrep（`rg`）— メインの検索ツール

Ripgrep は、ほぼすべてのコーディングアシスタントで最も多く呼び出されるツールです。高速で .gitignore を認識し、大規模なコードベースでも速度が落ちません。

# 特定の関数を含むファイルを検索
rg "authenticate" --type ts

# 関数定義を検索
rg "^export function" src/ -n

# 周辺コンテキスト付きで検索
rg "handleLogin" -C 3

# マッチしたファイル名のみ表示
rg "useAuth" -l

「ログイン関数にエラーハンドリングを追加して」と頼むと、アシスタントはまず rg を実行してログインロジックがどこにあるかを特定します — ファイルに触れる前に。

`fd` — 高速ファイル検索

コンテンツではなくファイル名のパターンでファイルを探します。

fd -e test.ts          # TypeScript のテストファイル一覧
fd "*.config.js"       # 設定ファイル
fd -t f -name "*.env"  # 環境変数ファイル

`find` — 標準のフォールバック

fd が利用できない環境でも広く使われています。

find src/ -name "*.py" -newer requirements.txt

`grep` — 汎用フォールバック

rg がインストールされていない場合、grep -r が同じ役割を果たしますが、速度は劣ります。

パフォーマンスのヒント：ripgrep をインストール（brew install ripgrep / apt install ripgrep）すると、大規模なコードベースでの検索が体感できるほど速くなります。

2. ファイル読み取りツール：既存のコードを把握する

適切なファイルを特定したあと、アシスタントはできる限りシンプルなコマンドでファイルを読みます。

`cat` — ファイル全体を読む

cat src/auth/login.tsx
cat src/lib/api.ts

`head` / `tail` — ファイルの一部を読む

大きなファイル、長いログ、または全体を読み込まずに構造を確認するのに便利です。

head -50 src/api/routes.ts    # 最初の50行
tail -100 logs/app.log        # ログの最後100行

`wc` — まずファイルサイズを確認

アシスタントは、ファイルを全部読むかどうかを決める前に行数を確認することが多いです。

wc -l src/models/user.py

`ls` / `tree` — ディレクトリ構造を把握

ls -la src/components/
tree src/ --depth 2

3. ファイル書き込み・編集ツール：変更を加える

ここで実際のコード生成が行われます。AI は変更の範囲に応じて編集戦略を選択します。

新規ファイルの作成

ゼロから書く新しいファイルの場合：

cat > src/components/LoginForm.tsx << 'EOF'
import React, { useState } from 'react'
// ... 生成されたコード
EOF

`patch` — 構造化された差分を適用

正確でレビュー可能な編集の場合：

patch src/auth/login.tsx < changes.patch

`sed` — ファイル内のインプレース置換

ファイル全体にわたる特定の置換の場合：

sed -i 's/oldFunctionName/newFunctionName/g' src/utils.ts

インライン Python / Node スクリプト

複雑な JSON、YAML、設定ファイルの変換の場合：

python3 -c "
import json
with open('config.json') as f:
    data = json.load(f)
data['featureFlag'] = True
with open('config.json', 'w') as f:
    json.dump(data, f, indent=2)
"

4. コード実行・テストツール：動作を確認する

よく設計された AI コーディングアシスタントはコードを書くだけでなく、そのコードが動くかを検証します。編集・コンパイル・テストのサイクルが自動的に行われます。

テストランナー

# Python（Django・FastAPI プロジェクトで一般的）
pytest tests/ -v
pytest tests/test_auth.py::test_login -x   # 最初の失敗で停止

# JavaScript / TypeScript
npm test
npx jest src/auth/login.test.ts

# Go（マイクロサービスで広く使用）
go test ./...

# Rust
cargo test

型チェッカー

npx tsc --noEmit    # TypeScript（出力ファイルなし）
mypy src/           # Python の型チェック

リンター・フォーマッター

npx eslint src/ --fix
ruff check src/
npx prettier --write src/

ビルドの検証

npm run build
cargo build
go build ./...
make

流れは「書く → テスト → エラーを読む → 修正 → 再テスト」です。AI は開発者が手動でやるのと同じサイクルを実行します。ただしコーヒーブレイクなしで。

5. Git ツール：履歴の把握と作業の保存

Git はコーディングアシスタントの動作において中心的な役割を果たします。変更を加える前にコンテキストを理解するためにも、変更後に作業を保存するためにも使われます。

状態と履歴の読み取り

git status                          # 何が変更されたか
git diff                            # 行レベルの変更内容
git log --oneline -20               # 最近のコミット履歴
git log main..HEAD --oneline        # 現在のブランチの変更
git blame src/auth/login.ts         # 誰がいつ何を変更したか

変更をコミット

git add src/components/LoginForm.tsx
git commit -m "feat: add login form component"

PR ワークフロー用 GitHub CLI（`gh`）

gh pr diff 142                      # レビュー用に PR の差分を取得
gh pr create --title "..." --body "..."
gh pr checks                        # CI ステータスの確認
gh issue view 88                    # Issue のコンテキストを読む

6. パッケージマネージャーとランタイムツール

呼び出される具体的なツールは技術スタックによって異なります。

JavaScript / TypeScript プロジェクト

npm install
npm run dev
npx <tool>
bun install && bun run dev

Python プロジェクト

pip install -r requirements.txt
python manage.py migrate
uvicorn main:app --reload

Docker とコンテナ

docker compose up -d
docker logs app_container
docker exec -it container_name bash

API テスト

curl -X POST http://localhost:8000/api/login \
  -H "Content-Type: application/json" \
  -d '{"email":"test@example.com","password":"pass"}'

実例：「/dashboard にポストフォームを追加して」

Claude Code のようなコーディングアシスタントにそのプロンプトを渡したとき、実際に実行されるシェルコマンドの全シーケンスがこちらです：

# ステップ1：プロジェクト構造の把握
ls src/
tree src/pages --depth 2

# ステップ2：ダッシュボードページを探す
rg "dashboard" src/ --type tsx -l
cat src/pages/dashboard.tsx

# ステップ3：再利用できる既存のフォームパターンを探す
rg "form" src/components/ -l
cat src/components/CommentForm.tsx

# ステップ4：API コールの方法を理解する
rg "fetch|axios|api" src/lib/ -l
cat src/lib/api.ts

# ステップ5：既存のポストエンドポイントを確認
rg "POST" src/api/ -n

# ステップ6：新しいコンポーネントを書く
cat > src/components/PostForm.tsx << 'EOF'
...生成されたコンポーネント...
EOF

# ステップ7：ダッシュボードページにインポートを追加
sed -i "s/from '.\/CommentForm'/from '.\/CommentForm'\nimport { PostForm } from '.\/PostForm'/" \
  src/pages/dashboard.tsx

# ステップ8：TypeScript のコンパイルを検証
npx tsc --noEmit

# ステップ9：関連するテストを実行
npm test -- --testPathPattern=dashboard

# ステップ10：変更内容を確認
git diff

すべてのステップは普通のシェルコマンドです。知性は「どのコマンドをどの順番で実行するか、そして出力をどう解釈するか」を知っていることにあります。

開発者にとってなぜ重要なのか

基盤となるツールレイヤーを理解することには、実際的な意味が4つあります。

パフォーマンス：rg がインストールされていなければ、AI は grep にフォールバックします。これは大規模なコードベースでは大幅に遅くなります。ripgrep のインストールは、あらゆる AI コーディングアシスタントの無料パフォーマンスアップグレードです。

AI のミスのデバッグ：アシスタントが間違った編集をしたとき、多くの場合、読み間違えたものまでさかのぼれます。「何を検索して、何を見つけたか？」と自問してください。エラーはほぼ常にツール出力にあり、AI の推論にあるわけではありません。

セキュリティ：AI が呼び出すすべてのツールは、あなたのマシン上であなたの認証情報で実行されます。git、npm、docker、curl を呼び出すことを知っておくと、実際に必要なパーミッションを明確に考え、適切な制限をかけることができます。

自分でコーディングアシスタントを作る：Claude Code や Aider のようなエージェントを作りたい場合、これでツールの全体像がわかりました。LLM レイヤーは、これらのプログラム周辺のクリーンなツールインターフェースの設計に比べれば、ほぼ二次的なものです。

AI コーディングアシスタントツールマップ完全版

カテゴリ	使用ツール
コンテンツ検索	`rg`（ripgrep）、`grep`、`awk`
ファイル検索	`fd`、`find`、`ls`、`tree`
ファイル読み取り	`cat`、`head`、`tail`、`wc`
ファイル書き込み / 編集	`patch`、`sed`、`tee`、インラインスクリプト
コード実行	`python`、`node`、`go`、`cargo`、`ruby`
テスト実行	`pytest`、`jest`、`vitest`、`go test`、`cargo test`
ビルド	`npm run build`、`cargo build`、`make`、`gradle`
リント / 型チェック	`eslint`、`tsc`、`mypy`、`ruff`、`prettier`
バージョン管理	`git`、`gh`（GitHub CLI）
パッケージ管理	`npm`、`pip`、`cargo`、`brew`、`apt`
インフラ	`docker`、`docker compose`、`kubectl`
ネットワーク / API	`curl`、`wget`、`httpie`

よくある質問

すべての AI コーディングアシスタントは同じツールを使いますか？
コアツール — rg、git、cat、テストランナー — は Claude Code、Codex CLI、Aider、Cline で共通しています。具体的な呼び出し方や順序は異なりますが、基盤となるプログラムは同じです。

AI はファイルシステム全体にアクセスできますか？
デフォルトでは、作業ディレクトリとそのサブディレクトリ内でアクセスできます。Claude Code のようなツールは、実行できるコマンドを制限するパーミッションの許可リスト（例："Bash(git *)"）をサポートしています。

なぜ AI はすべてのファイルを読まずに rg を使うのですか？
大規模なコードベースのすべてのファイルを読むと、LLM のコンテキストウィンドウを超え、トークンを消費しすぎます。最初に rg で検索することで、AI は実際に読む対象を絞り込めます。

これらのツールで自分のコーディングアシスタントを作れますか？
はい。コアアーキテクチャは「LLM + ツール定義（bash、read、write、grep）+ エージェントループ」です。Aider のようなオープンソースプロジェクトがその具体例です。シェルツール自体は特別なセットアップは不要です。

ツールが不足している場合はどうなりますか？
AI は通常、グレースフルにフォールバックします — rg → grep、fd → find。gh のようなツールはオプションで、インストールされていない場合、アシスタントは PR 関連のステップをスキップします。

まとめ

AI コーディングアシスタントが強力なのは、コードを扱う新しい方法を発明したからではありません。すでに存在するツールをオーケストレーションするのが非常に得意だからです。Claude Code の下で動く rg、git、npm、patch コマンドは、開発者が長年使ってきたものと同じです。

AI が推論を担います：どのツールを選ぶか、何を検索するか、出力をどう解釈するか。ツールが実行を担います：実際にコードを読み、書き、実行すること。

この分担を理解すれば、AI コーディングアシスタントはブラックボックスでなくなります。それは、推論し、最適化し、デバッグし、そして望めば自分で作れるシステムになります。