TL;DR
-
CLAUDE.mdでプロジェクト規約を宣言すると、コード生成精度が劇的に上がる - サブエージェント並列実行で「調査→実装→レビュー」を同時進行できる
- カスタムスラッシュコマンドを育てると繰り返し作業がゼロになる
背景
Claude Code (旧 claude-engineer) は Anthropic が公開しているターミナルベースの AI コーディングエージェントです。2025 年後半から OSS メンテナや個人開発者の間での採用が急速に増え、「PR レビュー待ちの間に別 Issue を Claude Code に振る」というワークフローが定番化しつつあります。
本記事では 公開ドキュメント・実際の使用体験・OSS コミュニティの知見 をもとに、実務で差が出る 7 つのテクニックをまとめます。
テクニック 1: CLAUDE.md で「チームの暗黙知」を明文化する
Claude Code はプロジェクトルートの CLAUDE.md を毎回コンテキストとして読み込みます。ここに コーディング規約・ディレクトリ構成の意図・禁止事項 を書いておくと、会話のたびに説明し直す手間がなくなります。
# CLAUDE.md
## 言語・ランタイム
- Node.js 22 / TypeScript strict
- formatter: Prettier (設定は .prettierrc 参照)
- linter: ESLint flat config
## ディレクトリ規約
- src/features/<feature>/ ← 機能単位のスライスアーキテクチャ
- 各 feature に index.ts を置き、外部 import はそこだけ通す
## コミットメッセージ
- Conventional Commits 準拠 (feat / fix / docs / refactor)
- 英語で書く・件名 50 字以内
## 禁止事項
- any 型を新規導入しない
- default export を使わない
ポイント: 「禁止事項」セクションが特に効果的です。LLM は「やるな」という指示を positive な制約として解釈するため、否定表現でも高精度で遵守します。
テクニック 2: スコープを「1 コミット分」に切る
「この機能全体を実装して」という大雑把な依頼は失敗率が高くなります。代わりに Conventional Commits の 1 単位 を意識してタスクを分割してください。
| NG な依頼 | OK な依頼 |
|---|---|
| 「ユーザー認証を実装して」 | 「JWT を検証する verifyToken(token: string) 関数を src/lib/auth.ts に追加して、Jest テストも書いて」 |
| 「パフォーマンスを改善して」 | 「src/pages/index.tsx の画像を next/image に置き換えて CLS を 0 にして」 |
| 「バグを直して」 | 「#142 のエラーログ (以下に貼り付け) の原因を調査して修正 PR の diff だけ出して」 |
小さなスコープにするメリットは2つ。
- レビューしやすい: 生成されたコードが 50 行以下なら人間が全行読める
-
ロールバックしやすい: 失敗しても
git checkout .で戻せる
テクニック 3: --dangerously-skip-permissions は CI 専用にする
Claude Code にはファイル書き込み・シェル実行前の確認プロンプトを省略する --dangerously-skip-permissions フラグがあります。
# ローカルでは使わない
claude --dangerously-skip-permissions "..."
# GitHub Actions / GitLab CI など人間がいない環境でのみ
- name: Auto-fix lint errors
run: claude --dangerously-skip-permissions "ESLint のエラーを全て自動修正して"
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
ローカルで無思考に使うと「気づいたら production の設定ファイルが書き換わっていた」という事故が起きます。CI で自動フォーマット・自動 import 整理など、副作用が限定的な用途に絞るのがベストプラクティスです。
テクニック 4: カスタムスラッシュコマンドで定型タスクをゼロコスト化
.claude/commands/ ディレクトリに Markdown ファイルを置くと、/ から呼び出せるカスタムコマンドになります。
.claude/
└── commands/
├── review.md
├── changelog.md
└── i18n-sync.md
例: /review コマンド (review.md)
直近の git diff を読んで以下の観点でレビューしてください:
1. **バグリスク**: 境界値・null/undefined・非同期の順序
2. **型安全性**: any 型・型アサーション (`as`) の不適切な使用
3. **パフォーマンス**: 不要な再レンダリング・N+1 クエリ
4. **可読性**: 変数名・関数の責務分離
各指摘は「ファイル名:行番号 - 指摘内容 - 修正案」の形式で出力してください。
チームで .claude/commands/ を Git 管理しておくと、新メンバーが clone した瞬間に同じ AI ワークフローを使えるようになります。
テクニック 5: サブエージェントで「調査・実装・テスト」を並列化する
Claude Code 内から Task() ツール (Web UI では「サブエージェント起動」) を使うと、複数のエージェントが並列で走ります。CLIから使う場合はプロンプトの構造化で擬似的に再現できます。
以下を順番ではなく並列で処理して:
[調査タスク]
axios と fetch API のエラーハンドリングの違いを公式ドキュメントで確認して、
TypeScript での型定義の差異をまとめて
[実装タスク]
src/lib/http-client.ts に fetch ベースの HTTP クライアントを実装して
- 共通ヘッダ付与
- 4xx/5xx を typed error で throw
- タイムアウト AbortController
[テストタスク]
上記クライアントの Vitest ユニットテストを src/lib/__tests__/http-client.test.ts に書いて
- 正常系 / 4xx / 5xx / タイムアウトのケースを網羅
並列プロンプトはトークン効率も良く、長い「調査→実装→テスト」サイクルを 1 往復で完結できます。
テクニック 6: エラーログは「生のまま」貼り付ける
エラーを自分で要約して渡すと情報が欠落します。スタックトレース・ランタイム出力・ビルドログは 生のテキストをそのままコンテキストに貼る のが鉄則です。
以下のエラーを修正して:
--- エラーログここから ---
TypeError: Cannot read properties of undefined (reading 'map')
at ProductList (src/components/ProductList.tsx:23:34)
at renderWithHooks (node_modules/react-dom/...)
...
--- エラーログここまで ---
関連する src/components/ProductList.tsx の内容:
<ファイル内容を貼り付け>
Claude Code は行番号・コールスタック・ファイルパスを手がかりに原因を特定します。「なんかエラーが出てる」という曖昧な入力とは雲泥の差がでます。
テクニック 7: git worktree と組み合わせて「安全な実験場」を作る
大きな変更を Claude Code に任せるときは、git worktree で作業ブランチを隔離すると安心です。
# 実験用ワークツリーを作成
git worktree add ../my-project-experiment feature/refactor-auth
# 実験用ディレクトリで Claude Code を起動
cd ../my-project-experiment
claude "認証モジュールを JWT から session-based に移行して"
# 結果を確認
git diff main
# 良ければ本ブランチにマージ、ダメなら削除
git worktree remove ../my-project-experiment
worktree は本体のブランチに影響しないため、「破壊的変更を試しやすい」「並列で複数の Claude Code セッションを走らせやすい」というメリットがあります。Node.js の node_modules は共有されないので、必要なら npm install を忘れずに。
まとめ
| # | テクニック | 効果 |
|---|---|---|
| 1 |
CLAUDE.md で規約を宣言 |
会話ごとの説明コストをゼロに |
| 2 | スコープを 1 コミット分に | 失敗率・レビューコストを下げる |
| 3 |
--skip-permissions は CI 専用 |
誤操作による事故を防ぐ |
| 4 | カスタムスラッシュコマンド | チーム全員が同じ AI ワークフローを使える |
| 5 | 並列プロンプトで工程を同時進行 | 調査→実装→テストを 1 往復で |
| 6 | エラーログは生のまま貼る | LLM の診断精度が上がる |
| 7 |
git worktree で実験場を隔離 |
破壊的変更を安全に試せる |
Claude Code はプロンプトの「品質」より「構造」が結果を左右します。上記 7 つはいずれも「情報をどう整理して渡すか」という設計の話です。今日から 1 つずつ試してみてください。
参考リンク
- Claude Code 公式ドキュメント
- CLAUDE.md のベストプラクティス (Anthropic Blog)
- git worktree 公式マニュアル
- Conventional Commits 仕様
✍️ 本記事の著者: 合同会社ジモラボ
ジモラボは、八王子を拠点に AI を活用した SaaS を多数開発しています。本記事の技術検証もそうした開発過程の副産物です。
- 🌐 公式サイト: https://locallab.jp
- 🔍 AI SEO 最適化 SaaS: lookupai.jp
- 📺 YouTube: @locallab_llc
- ✉️ お問い合わせ: info@locallab.jp
興味を持っていただけたら、ぜひ各 SNS のフォローもお願いします!