Claude Code 運用Tips 12選｜Boris Cherny発信の手法を全部公式docs URLで裏取りした版

この記事はClaude Codeを触ったことがあって、
もっと使いこなしたい開発者・副業エンジニア向け（CLI＝コマンドラインで操作する画面 の基本が分かる前提です）。

そもそもClaude Codeの「運用Tips」って何の話？

Claude Codeをインストールして1〜2週間触ると、
たいてい同じ壁にぶつかります。
プロンプトを丁寧に書いてるのに違うファイルをいじられる。
同じミスを何度も繰り返される。
コンテキスト（AIが覚えている会話の長さ）が足りなくなって性能が落ちる。

このあたりは「設定ファイルを置く」「モードを切り替える」「サブエージェント（メインの会話と別枠で動く子分のAI）に投げる」といった運用側の工夫でかなり減らせます。
Claude Code 作者の Boris Cherny が X やイベントで発信している運用Tipsはまさにこの「運用工夫集」で、
その内容の大半は公式docsにも書いてあります。

ただ翻訳まとめ記事は、
肝心の公式URLが添えられていない。
「本当にAnthropicの公式情報なのか」を読者が自分で確かめにくい。
私はこれが気持ち悪くて、
12個に絞って公式URLを1〜2本ずつ貼り直しました。

公式docsで裏取れた12のTips

Tip 1: Plan Mode で「調査と実装」を分ける

公式 Best Practices には "Explore first, then plan, then code" という順番で進めろと書いてあります（出典: Anthropic公式 Best Practices）。
読まずにいきなり実装すると、
間違った問題を解いてしまう。

Separate research and planning from implementation to avoid solving the wrong problem.（調査と計画を実装から分けて、
間違った問題を解くのを避けろ）

出典: Anthropic公式 Best Practices

Plan Mode（計画モード。
実装せずに計画だけ出させる状態）は Shift+Tab でモードを切り替えるか、
起動時に claude --permission-mode plan をつけると入れます。
プラン中に Ctrl+G でテキストエディタが開いて直接編集もできるそうです（出典: Anthropic公式 Common Workflows）。

個人的に効くと感じるのは、
Plan Mode をデフォルト化する設定です。
.claude/settings.json に書ける。

Plan Mode をデフォルトで起動する手順

1. プロジェクトのルートに .claude/ ディレクトリ（フォルダ）がなければ作る
2. その中に settings.json を作って {"permissions": {"defaultMode": "plan"}} と書く
3. 次回 claude コマンドで起動した時、Plan Mode で立ち上がっていれば成功

逆に注意すべきは公式docsの逆説。
"Plan Mode is useful, but also adds overhead. For tasks where the scope is clear and the fix is small, ask Claude to do it directly."（明らかに小さい修正なら直接やらせろ）。
常時Plan Modeは過剰な時もある。

Tip 2: Claude 自身に「自分の仕事」を検証させる

公式 Best Practices で「最大レバレッジ」と明言されている1個がこれ。

Include tests, screenshots, or expected outputs so Claude can check itself. This is the single highest-leverage thing you can do.（テスト・スクショ・期待される出力を渡してClaude自身に確認させろ。
これが単一で最も効くこと）

出典: Anthropic公式 Best Practices

具体的には、
テスト実行→「全テスト通ってから完了」と指示する。
UI変更ならChrome拡張でスクショ比較もできる、
と公式は書いています。

テスト検証ループを自分のプロジェクトで動かす手順

1. テストコマンド（例: npm test や pytest）を CLAUDE.md に1行で書く
2. 修正タスクを依頼する時に「実装後に npm test を実行して全パスしたら完了にして」と添える
3. テストが落ちたら自分で直して再実行するまでループさせる

これだけで「動いてないコードを完了報告される」事故が激減します。

Tip 3: CLAUDE.md は 200行未満に剪定し続ける

CLAUDE.md（Claudeに毎回読ませるルールブック。
Markdownファイル）は便利だからといって肥大させると逆効果になります。

If your CLAUDE.md is too long, Claude ignores half of it because important rules get lost in the noise.（長すぎるとClaudeは半分無視する。
重要なルールがノイズに埋もれるから）

出典: Anthropic公式 Best Practices

公式の推奨サイズは200行未満（出典: Anthropic公式 Memory docs）。
同じミスを2回したら追記、
すでに守れているルールは削除、
というメンテ運用が公式に書かれています。

これ意外と聞かれない話。

CLAUDE.md を月1回剪定する手順

1. wc -l CLAUDE.md で行数を確認。200行を超えていたら剪定対象
2. 「直近1か月でClaudeが破ったルールはどれか」をログ・コミット履歴から洗い出して残す
3. 「Claudeが指示なしで毎回守れているルール」は削除する（公式の推奨手順）

初回ファイルは /init コマンドでプロジェクト構造から自動生成できます。
配置場所は4つ（ホーム / プロジェクトルート / CLAUDE.local.md＝個人設定 / サブディレクトリ用）。

Tip 4: 繰り返し作業はスキル化して git 管理

同じ作業を3回以上やってるなら、
スキル（.claude/skills/<名前>/SKILL.md という形で置く再利用テンプレ）に切り出す価値があります。
CLAUDE.mdとの違いは大きい。
CLAUDE.mdは毎回読まれてコンテキストを食うけど、
スキルは呼ばれた時だけ読み込まれる（出典: Anthropic公式 Skills docs）。

SKILL.mdの推奨サイズは500行未満。
$ARGUMENTS で引数を渡せるので /fix-issue 1234 のようなコマンド化もできます。

独自スキルを作って呼び出す手順

1. プロジェクトに .claude/skills/my-task/ を作る
2. その中に SKILL.md を作り、フロントマター（YAML形式の設定ヘッダ）に name と description を書く
3. 本文に手順を書いて保存。Claude Code を再起動して /my-task で呼べたら成功

デプロイなど副作用が大きい作業は disable-model-invocation: true をフロントマターに追加すると、
ユーザー手動呼び出しのみになります。
これ重要。

スキルとCLAUDE.mdの境界線については、
私の見方では「全プロジェクト共通の絶対ルールはCLAUDE.md、
特定タスク用の手順書はスキル」がいちばん事故が少ないと感じます。

Tip 5: Permissions（allow / ask / deny）でダイアログ疲れを消す

毎回「このコマンド実行していい？」と聞かれて発狂する人は permissions 設定を入れてない可能性が高い。
公式の評価順はdeny → ask → allow で、
最初にマッチしたルールが勝ちます（出典: Anthropic公式 Permissions docs）。

セキュリティの落とし穴。
Read(./.env) を deny しても cat .env は Bash 経由なので止まりません。
シェルからの読み出しは別途 Bash(cat *) を ask にする等の対応が要ります。

最低限のpermissions設定を入れる手順

1. .claude/settings.json を開く（なければ作る）
2. "permissions" キーに allow / ask / deny の3配列を書く
3. .env や secrets/** を必ず deny に入れる

Tip 6: Hook で「例外なく守るルール」を強制実行する

CLAUDE.md は助言、
Hooks（フック。
特定のタイミングで自動実行されるスクリプト）は強制。
公式は明確に区別しています。

Unlike CLAUDE.md instructions which are advisory, hooks are deterministic and guarantee the action happens.（CLAUDE.md は助言にすぎないが、
hooksは決定論的で実行を保証する）

出典: Anthropic公式 Best Practices

例えば「ファイル編集後に必ず prettier を走らせる」を CLAUDE.md に書いても、
Claude が忘れる時があります。
Hook なら絶対に走る。
主要イベントは PostToolUse（ツール実行後）/ PreToolUse（実行前）/ Notification（入力待ち時）の3つです（出典: Anthropic公式 Hooks Guide）。

編集後に Prettier 自動実行する hook を仕込む手順

1. .claude/settings.json の "hooks" キーに PostToolUse を定義
2. "matcher": "Edit|Write" でファイル編集系のツールに反応するよう指定
3. "command" に jq -r '.tool_input.file_path' | xargs npx prettier --write を書く

注意点。
Hookが重いとセッション全体が遅くなる、
と公式ガイドも言っています。
最初は軽い1個から。
Hook自体を Claude に書かせるのも公式推奨です（"Write a hook that runs eslint after every file edit." で生成と設定まで通せる）。

Tip 7: Subagents で「調査」と「実装」のコンテキストを分ける

サブエージェント（メインの会話と完全に別枠で動くClaudeの子分）は、
独自のコンテキスト・独自のツール・独自の権限で動きます。
主目的はコンテキスト保全。

Use one when a side task would flood your main conversation with search results, logs, or file contents you won't reference again.（後で参照しない検索結果・ログ・ファイル内容でメイン会話が溢れる時に使え）

出典: Anthropic公式 Sub-agents docs

built-in（最初から入っている）サブエージェントは Explore（Haikuモデル・読み取り専用・コードベース探索用）/ Plan（計画用・読み取り専用）/ general-purpose（全ツール）の3種。
サブエージェントから別のサブエージェントは呼べない（ネスト不可）という制約があります。

公式が推す Writer/Reviewerパターン も覚えておきたい。
Session A で実装、
別の Session B でレビュー。
"A fresh context improves code review since Claude won't be biased toward code it just wrote."（書いたばかりのコードに引っ張られないので、
別コンテキストの方がレビュー精度が上がる）。

Subagent に調査だけ任せる手順

1. メイン会話で「Use a subagent to investigate the auth module」のように明示的に依頼する
2. built-in の Explore（Haiku）が呼ばれてコードベースを調査
3. 結果サマリーだけメインに返ってきて、メインのコンテキストはほぼ消費されない

Tip 8: コンテキストは積極的に管理する（/clear と /compact）

公式の主要警告がこれ。

Claude's context window fills up fast, and performance degrades as it fills.（コンテキストウィンドウは速く埋まり、
埋まるほど性能が落ちる）

出典: Anthropic公式 Best Practices

対策は3つ。
/clear で関連性のないタスク間はリセット、
/compact [指示] で会話を要約圧縮、
/btw <質問> でコンテキストに残さないサイド質問。
/compact は指示付きで /compact Focus on the API changes のように使えます（出典: Anthropic公式 Best Practices）。

公式の失敗パターンが面白くて、
2回以上同じ問題で修正を繰り返したら諦めて /clear しろと書いてあります。
粘らずリセット。

長セッションでコンテキストを延命する手順

1. サブタスクが終わるたびに /compact で会話を要約圧縮する
2. 無関係な次タスクに移る時は /clear で完全リセット
3. 同じバグで2回直しても解決しなかったら /clear して最初から再スタート

私が読んでいて意外だったのは「粘るより捨てる」を公式が明文化していること。
AIに粘ってもらうほど精度が上がる気がしてしまうけど、
コンテキストが汚れたら捨てるのが正解。

Tip 9: /rewind と Checkpoint で探索的な変更を安全に試す

Checkpointは「Claudeのアクションごとに自動で保存される復元ポイント」。
Escキー2回または /rewind コマンドで呼び出せます（出典: Anthropic公式 Checkpointing docs）。
復元オプションは4種類あります。

重要な制約。
"Checkpointing does not track files modified by bash commands."（Bash経由のファイル変更＝rm や mv は追跡対象外）。
Bashで消したファイルは戻りません。
Gitの代替ではない、
と公式も "Think of checkpoints as 'local undo' and Git as 'permanent history'" と書いています。

Checkpoint はセッション終了後30日で自動削除（設定変更可）。

Tip 10: 非対話モード claude -p で CI・スクリプトに組み込む

対話なしで Claude を呼びたい時は claude -p "プロンプト"。
出力フォーマットは --output-format text|json|stream-json から選べます。
CI（継続的インテグレーション。
コードを自動でテスト・ビルドする仕組み）にそのまま乗せられる設計です（出典: Anthropic公式 CLI Reference）。

強力なのがfan-outパターン（1ファイル1セッションで並列処理する型）。
公式 Best Practices の例:

for file in $(cat files.txt); do
  claude -p "Migrate $file..." --allowedTools "Edit,Bash(git commit *)"
done

出典: Anthropic公式 Best Practices

200ファイル級の移行で威力を発揮します。
--allowedTools でツール制限、
--max-turns で最大ターン数、
--max-budget-usd で最大コストを縛れる。
安全装置も揃っています。

fan-out で大量ファイル移行を回す手順

1. 対象ファイルを files.txt に1行ずつリスト化
2. ループ内で claude -p を呼び、--allowedTools で実行可能ツールを限定
3. --max-budget-usd で予算上限をつけて暴走を防ぐ

Tip 11: git worktree で複数セッションを並列実行

機能ブランチごとに別ディレクトリで Claude Code セッションを並列起動する方式。
CLI は claude --worktree feature-auth で .claude/worktrees/feature-auth/ に新ブランチが切られます（出典: Anthropic公式 Common Workflows）。
名前を省略すると bright-running-fox のような自動名がつく。

各worktreeは独立したファイル・ブランチを持ちつつ、
リポジトリ履歴は共有します。
.worktreeinclude ファイルで .env 等の gitignore 対象ファイルを新worktreeにコピーする設定もできる。

運用で効くのはWriter/Reviewerパターンとの組み合わせ。
実装worktreeとレビューworktreeを分ければ、
レビュー側はフレッシュなコンテキストでバイアスなしの指摘を返してくれます。

worktree並列で2セッション動かす手順

1. .gitignore に .claude/worktrees/ を追加
2. ターミナル1で claude --worktree feature-auth を実行して実装セッション開始
3. ターミナル2で claude --worktree review-auth を実行してレビュー専用セッション開始

Tip 12: GitHub Actions で @claude メンション連携

これは GA（v1.0、
正式リリース済み）。
研究プレビューではありません（出典: Anthropic公式 GitHub Actions docs）。
Pull Request や Issue のコメントで @claude とメンションするだけで、
コード変更や質問回答ができます。

セットアップは対話的に1コマンド。
/install-github-app で API キーの登録とワークフローファイル配置までやってくれます。
公式リポジトリは anthropics/claude-code-action。
AWS Bedrock や Google Vertex AI でも動きます（Enterprise向け）。

GitHub Actions に @claude メンションを仕込む手順

1. Claude Code 内で /install-github-app を実行
2. 対話に従って ANTHROPIC_API_KEY を GitHub Secrets に登録
3. .github/workflows/ に生成されるワークフローファイルをコミット・プッシュ

これで Issue コメントに @claude このバグ直して と書くだけで PR が飛んできます。
便利すぎ。

研究プレビュー枠（仕様変更注意）

ここから先は2026年4月時点で研究プレビュー（research preview）またはbetaのもの。
仕様・課金条件・可用性が変わる可能性があるので、
確定機能と分けて並べます。
本番運用に組み込むのは早い段階。

Routines・Remote Control・Ultraplan・Ultrareview は Pro / Max / Team / Enterprise プラン対象。
無料プランやAPIキー単体の利用では使えないものが含まれます。
Ultrareview の「3回無料」期限が近いので、
試すなら2026年5月5日までに。

Chrome拡張は WSL2 環境では未対応。
私の手元の WSL2 では起動自体ができないので、
これは Mac か Windows ネイティブの Chrome / Edge で試すしかなさそうです。

FAQ

Plan Mode は常時オンにすべき？

常時オンは過剰になる場面があります。
公式 Best Practices にも "For tasks where the scope is clear and the fix is small, ask Claude to do it directly."（範囲が明確で小さい修正なら直接やらせろ）と書かれています。
複数ファイル変更や不明確なアプローチの時だけ Plan Mode、
という使い分けが推奨です。

CLAUDE.md と スキル と Hook はどう使い分ける？

CLAUDE.md は「毎回読ませる助言ルール」、
スキルは「呼ばれた時だけ読まれる作業テンプレ」、
Hookは「例外なく強制実行される自動処理」。
公式は "Unlike CLAUDE.md instructions which are advisory, hooks are deterministic" と区別しています。
守らせたい度合いが Hook > CLAUDE.md、
コンテキスト消費はスキルが最小、
という関係です。

Checkpoint は Git の代替になる？

なりません。
公式が "Think of checkpoints as 'local undo' and Git as 'permanent history'"（Checkpointはローカルundo、
Gitは恒久履歴と思え）と明示しています。
さらに Bash 経由のファイル変更（rm 等）は追跡対象外で、
セッション終了30日後に自動削除されます。
永続保存は Git で。

サブエージェントから別のサブエージェントを呼べる？

呼べません。
公式docsに "subagents cannot spawn other subagents" と明記されています。
ネスト構成を組みたい場合はメインのオーケストレーション層から並列に呼ぶ設計にする必要があります。

fan-outで大量ファイル移行する時の安全装置は？

3つあります。
--allowedTools で実行可能ツールを "Edit,Bash(git commit *)" のように制限。
--max-turns で最大ターン数を縛る。
--max-budget-usd で最大コストを縛る。
3つ全部つけてから流すのが公式の推奨です。

研究プレビュー機能は本番に組み込んでいい？

2026年4月時点で Routines / Remote Control / Ultraplan / Ultrareview / auto permission / Chrome拡張は研究プレビュー or beta です。
仕様・課金・可用性が変わる可能性があるため、
本番のクリティカルパスに組み込むのは早い段階です。
動作確認や個人利用にとどめて、
確定機能（Plan Mode / hooks / skills / subagents 等）を本番運用の主軸にする方が安全寄りです。

参考リンク（公式のみ）

• Anthropic公式 Best Practices
• Anthropic公式 Common Workflows（Plan Mode / worktree）
• Anthropic公式 Memory（CLAUDE.md / auto memory）
• Anthropic公式 Skills
• Anthropic公式 Hooks Guide
• Anthropic公式 Sub-agents
• Anthropic公式 Permissions
• Anthropic公式 CLI Reference
• Anthropic公式 Checkpointing
• Anthropic公式 Commands（/simplify / /batch / /ultrareview）
• Anthropic公式 Routines（研究プレビュー）
• Anthropic公式 Remote Control（研究プレビュー）
• Anthropic公式 Ultraplan（研究プレビュー）
• Anthropic公式 Chrome拡張（beta）
• Anthropic公式 GitHub Actions
• 公式GitHub: anthropics/claude-code-action

※この記事の内容は執筆時点のものです。AIは進化が速い分野のため、最新の仕様は公式サイトでご確認ください。