環境設定から並列セッションの活用まで、Claude Codeを最大限に活用するためのヒントとパターン集
Claude Codeはエージェント型のコーディング環境です。
質問に答えて待機するチャットボットとは異なり、Claude Codeはファイルを読み、コマンドを実行し、変更を加え、あなたが見守る中、指示を出す中、あるいは離席している間も自律的に問題を解決します。
これにより作業スタイルが変わります。
自分でコードを書いてClaudeにレビューを依頼するのではなく、何が欲しいかを説明すれば、Claudeがどう構築するかを考えます。Claudeが探索し、計画し、実装するのです。
ただし、この自律性には学習曲線があります。
Claudeには理解すべき制約があります。
このガイドでは、Anthropic社内チームや、様々なコードベース・言語・環境でClaude Codeを使用するエンジニアの間で効果的だと実証されたパターンを紹介します。
最も重要な制約:コンテキストウィンドウ
ほとんどのベストプラクティスは1つの制約に基づいています:
Claudeのコンテキストウィンドウはすぐに埋まり、埋まるほどパフォーマンスが低下する
Claudeのコンテキストウィンドウには、会話全体、Claudeが読んだすべてのファイル、すべてのコマンド出力が含まれます。
1回のデバッグセッションやコードベース探索で数万トークンを生成・消費することがあります。
これが重要な理由は、コンテキストが埋まるとLLMのパフォーマンスが低下するからです。
コンテキストウィンドウがいっぱいになると、Claudeは以前の指示を「忘れたり」、ミスが増えたりします。
コンテキストウィンドウは最も重要な管理対象リソースです。
Claudeに作業を検証させる方法を与える
テスト、スクリーンショット、期待される出力を含めて、Claudeが自己検証できるようにする。
これが最も効果の高い方法です。
Claudeは自分の作業を検証できるとき、つまりテストを実行したり、スクリーンショットを比較したり、出力を検証できるときに、劇的に良い結果を出します。
明確な成功基準がないと、正しく見えるが実際には動作しないものを生成する可能性があります。
あなたが唯一のフィードバックループとなり、すべてのミスにあなたの注意が必要になります。
| 戦略 | 改善前 | 改善後 |
|---|---|---|
| 検証基準を提供する | 「メールアドレスを検証する関数を実装して」 | 「validateEmail関数を書いて。テストケース例:user@example.comはtrue、invalidはfalse、user@.comはfalse。実装後にテストを実行して」 |
| UI変更を視覚的に検証する | 「ダッシュボードをもっと良くして」 | 「[スクリーンショットを貼り付け] このデザインを実装して。結果のスクリーンショットを撮って元と比較して。違いをリストアップして修正して」 |
| 症状ではなく根本原因に対処する | 「ビルドが失敗している」 | 「このエラーでビルドが失敗している:[エラーを貼り付け]。修正してビルドが成功することを確認して。エラーを抑制するのではなく、根本原因に対処して」 |
検証はテストスイート、リンター、または出力をチェックするBashコマンドでも可能です。
検証を確実なものにすることに投資してください。
まず探索、次に計画、そしてコーディング
調査と計画を実装から分離して、間違った問題を解決することを避ける。
Claudeにいきなりコーディングさせると、間違った問題を解決するコードが生成される可能性があります。
Plan Modeを使って探索と実行を分離しましょう。
推奨ワークフローは4つのフェーズです:
1. 探索(Explore)
Plan Modeに入ります。
Claudeはファイルを読み、変更を加えずに質問に答えます。
/src/authを読んで、セッションとログインの処理方法を理解して。
また、シークレット用の環境変数の管理方法も確認して。2. 計画(Plan)
Claudeに詳細な実装計画を作成させます。
Google OAuthを追加したい。
どのファイルを変更する必要がある?
セッションフローは?
計画を作成して。3. 実装(Implement)
Normal Modeに戻り、Claudeに計画に基づいてコーディングさせます。
計画に基づいてOAuthフローを実装して。
コールバックハンドラのテストを書いて、テストスイートを実行して失敗があれば修正して。4. コミット(Commit)
Claudeに説明的なメッセージでコミットさせ、PRを作成させます。
説明的なメッセージでコミットしてPRを開いて⚠️ 注意:Plan Modeは便利ですが、オーバーヘッドも追加されます。
タスクのスコープが明確で修正が小さい場合(タイポ修正、ログ行の追加、変数名の変更など)は、直接実行させてください。
計画が最も有用なのは、アプローチが不確かなとき、変更が複数ファイルにまたがるとき、または変更するコードに不慣れなときです。diffを1文で説明できるなら、計画はスキップしましょう。
プロンプトに具体的なコンテキストを提供する
指示が正確であるほど、修正が少なくて済む。
Claudeは意図を推測できますが、心を読むことはできません。
特定のファイルを参照し、制約を述べ、例となるパターンを指し示してください。
| 戦略 | 改善前 | 改善後 |
|---|---|---|
| タスクのスコープを定める | 「foo.pyのテストを追加して」 | 「foo.pyのテストを書いて、ユーザーがログアウトしているエッジケースをカバーして。モックは避けて」 |
| ソースを指し示す | 「ExecutionFactoryのAPIがなぜこんなに変なの?」 | 「ExecutionFactoryのgit履歴を調べて、そのAPIがどのように生まれたかを要約して」 |
| 既存パターンを参照する | 「カレンダーウィジェットを追加して」 | 「ホームページの既存ウィジェットの実装を見てパターンを理解して。HotDogWidget.phpが良い例。そのパターンに従って、月を選択し前後にページネーションして年を選べる新しいカレンダーウィジェットを実装して。コードベースで既に使われているライブラリ以外は使わずにゼロから構築して」 |
| 症状を説明する | 「ログインバグを直して」 | 「ユーザーからセッションタイムアウト後にログインが失敗するという報告。src/auth/の認証フロー、特にトークンリフレッシュを確認して。問題を再現する失敗するテストを書いてから修正して」 |
曖昧なプロンプトは、探索中で軌道修正する余裕があるときに有用です。
「このファイルで何を改善する?」のようなプロンプトは、考えもしなかったことを浮き彫りにできます。
リッチコンテンツを提供する
@でファイルを参照、スクリーンショット/画像を貼り付け、またはデータを直接パイプする。
Claudeにリッチデータを提供する方法:
@でファイルを参照:コードの場所を説明する代わりに。
Claudeは応答前にファイルを読みます- 画像を直接貼り付け:コピー&ペーストまたはドラッグ&ドロップ
- URLを与える:ドキュメントやAPIリファレンス用。
/permissionsで頻繁に使用するドメインを許可リストに追加 - データをパイプ:
cat error.log | claudeでファイル内容を直接送信 - Claudeに必要なものを取得させる:Bashコマンド、MCPツール、ファイル読み込みでClaudeに自らコンテキストを取得させる
環境を設定する
いくつかのセットアップ手順で、Claude Codeはすべてのセッションで大幅に効果的になります。
効果的なCLAUDE.mdを書く
/initを実行して現在のプロジェクト構造に基づくスターターCLAUDE.mdファイルを生成し、時間をかけて改良する。
CLAUDE.mdはClaudeが会話の開始時に読む特別なファイルです。
Bashコマンド、コードスタイル、ワークフロールールを含めてください。これにより、コードだけからは推測できない永続的なコンテキストをClaudeに与えられます。
/initスラッシュコマンドはコードベースを分析してビルドシステム、テストフレームワーク、コードパターンを検出し、改良するための堅実な基盤を提供します。
CLAUDE.mdファイルに必須の形式はありませんが、短く人間が読みやすい状態に保ってください:
# コードスタイル
- CommonJS(require)ではなくESモジュール(import/export)構文を使用
- 可能な場合はインポートを分割代入(例:import { foo } from 'bar')
# ワークフロー
- 一連のコード変更が終わったら必ず型チェックを実行
- パフォーマンスのため、テストスイート全体ではなく単一テストの実行を優先
このファイルにすべてを詰め込みたくなりますが、簡潔に保ってください。
各行について「これを削除したらClaudeがミスをするか?」と問いかけてください。
そうでなければ削除します。肥大化したCLAUDE.mdファイルはClaudeに実際の指示を無視させます!
| ✅ 含めるもの | ❌ 含めないもの |
|---|---|
| Claudeが推測できないBashコマンド | Claudeがコードを読めばわかること |
| デフォルトと異なるコードスタイルルール | Claudeが既に知っている標準的な言語規約 |
| テスト指示と優先テストランナー | 詳細なAPIドキュメント(代わりにリンク) |
| リポジトリのエチケット(ブランチ命名、PR規約) | 頻繁に変わる情報 |
| プロジェクト固有のアーキテクチャ決定 | 長い説明やチュートリアル |
| 開発環境の癖(必要な環境変数) | コードベースのファイルごとの説明 |
| よくある落とし穴や非自明な動作 | 「クリーンなコードを書く」のような自明な慣行 |
Claudeがルールに反することを繰り返す場合、ファイルが長すぎてルールが埋もれている可能性があります。
CLAUDE.mdで回答されているはずの質問をClaudeがしてくる場合、表現が曖昧かもしれません。
CLAUDE.mdをコードのように扱ってください:うまくいかないときにレビューし、定期的に剪定し、Claudeの行動が実際に変わるかどうかを観察して変更をテストしてください。
強調(例:「IMPORTANT」や「YOU MUST」)を追加することで遵守を改善できます。
CLAUDE.mdをgitにチェックインしてチームが貢献できるようにしてください。
このファイルは時間とともに価値が複合的に増します。
CLAUDE.mdファイルは@path/to/import構文を使用して追加ファイルをインポートできます:
プロジェクト概要は@README.mdを、利用可能なnpmコマンドは@package.jsonを参照。
# 追加指示
- Gitワークフロー:@docs/git-instructions.md
- 個人オーバーライド:@~/.claude/my-project-instructions.mdCLAUDE.mdファイルの配置場所
- ホームフォルダ(
~/.claude/CLAUDE.md):すべてのClaudeセッションに適用 - プロジェクトルート(
./CLAUDE.md):gitにチェックインしてチームと共有、またはCLAUDE.local.mdと名付けて.gitignoreに追加 - 親ディレクトリ:
root/CLAUDE.mdとroot/foo/CLAUDE.mdの両方が自動的に取り込まれるモノレポに便利 - 子ディレクトリ:Claudeはそれらのディレクトリのファイルを扱うときに子CLAUDE.mdファイルをオンデマンドで取り込みます
権限を設定する
/permissionsで安全なコマンドを許可リストに追加するか、/sandboxでOSレベルの分離を行う。これにより中断が減りつつ、制御を維持できる。
デフォルトでは、Claude Codeはシステムを変更する可能性のあるアクション(ファイル書き込み、Bashコマンド、MCPツールなど)に対して許可を要求します。
これは安全ですが面倒です。
10回目の承認後には実際にはレビューしておらず、ただクリックしているだけです。
中断を減らす2つの方法があります:
- 権限許可リスト:安全だとわかっている特定のツールを許可(
npm run lintやgit commitなど) - サンドボックス:ファイルシステムとネットワークアクセスを制限するOSレベルの分離を有効にし、定義された境界内でClaudeがより自由に作業できるようにする
あるいは、--dangerously-skip-permissionsを使用して、リントエラーの修正やボイラープレート生成のような制限されたワークフローですべての権限チェックをバイパスできます。
⚠️ 警告:Claudeに任意のコマンドを実行させると、データ損失、システム破損、またはプロンプトインジェクションによるデータ流出が発生する可能性があります。
--dangerously-skip-permissionsはインターネットアクセスのないサンドボックスでのみ使用してください。
CLIツールを使用する
外部サービスと対話するときは
gh、aws、gcloud、sentry-cliなどのCLIツールを使用するようClaudeに指示する。
CLIツールは外部サービスと対話する最もコンテキスト効率の良い方法です。
GitHubを使用しているなら、gh CLIをインストールしてください。Claudeはissue作成、プルリクエストのオープン、コメントの読み取りにこれを使用する方法を知っています。
ghがないと、ClaudeはまだGitHub APIを使用できますが、認証されていないリクエストはレート制限に達することがよくあります。
Claudeはまだ知らないCLIツールの学習にも効果的です。
「’foo-cli-tool –help’を使ってfooツールについて学び、それを使ってA、B、Cを解決して」のようなプロンプトを試してください。
MCPサーバーを接続する
claude mcp addを実行してNotion、Figma、データベースなどの外部ツールを接続する。
MCPサーバーを使用すると、Claudeにissueトラッカーからの機能実装、データベースのクエリ、監視データの分析、Figmaからのデザイン統合、ワークフローの自動化を依頼できます。
カスタムスラッシュコマンドを作成する
繰り返しのワークフローをプロジェクトレベルのコマンドとして
.claude/commands/に、またはすべてのセッションで利用可能なグローバルコマンドとして~/.claude/commands/にMarkdownファイルとして保存する。
カスタムスラッシュコマンドには、コマンド呼び出しからパラメータを渡すための特別なキーワード$ARGUMENTS、または位置引数用の$1、$2などを含めることができます。
---
description: GitHubのissueを修正する
---
GitHubのissueを分析して修正してください:$ARGUMENTS。
以下の手順に従ってください:
1. `gh issue view`を使用してissueの詳細を取得
2. issueに記載されている問題を理解
3. 関連するファイルをコードベースで検索
4. issueを修正するために必要な変更を実装
5. 修正を検証するテストを書いて実行
6. コードがリンティングと型チェックをパスすることを確認
7. 説明的なコミットメッセージを作成
8. プッシュしてPRを作成
これで/fix-github-issue 1234を実行できます。
プラグインをインストールする
/pluginを実行してマーケットプレイスを閲覧する。プラグインは設定なしでコマンド、ツール、統合を追加する。
プラグインは、コミュニティとAnthropicからの事前構築された機能でClaude Codeを拡張します。
すべてを自分で設定する代わりに、プラグインをインストールすればすぐに動作します。
プラグインが追加できるもの:
- カスタムコマンド:特定のワークフロー用の新しいスラッシュコマンド(例:
/deploy、/review、/migrate) - MCPサーバー:外部ツール(データベース、API、SaaS製品)への事前設定された接続
- サブエージェント:セキュリティレビュー、ドキュメント作成、テストなどのタスク用の専門アシスタント
- スキル:Claudeが関連するときに自動的に適用するドメイン知識
フックを設定する
/hooksを使用してClaude Codeの動作を決定論的に制御する。
Claudeがアクションを実行することを覚えていることを期待する代わりに、フックは毎回それが起こることを保証する。
フックはClaudeのワークフローの特定のポイントで自動的にスクリプトを実行します:
- 自動フォーマット:すべての編集後に
.tsファイルにprettier、.goファイルにgofmtを実行 - リンティング:変更されたファイルを自動的にリントしてエラーを表示
- ガードレール:
.env、secrets/、または本番設定への変更をブロック - ロギング:コンプライアンスまたはデバッグのためにすべての実行コマンドを追跡
- 通知:Claudeが入力を待っているときにアラートを受け取る
Claudeにフックを書いてもらえます。
「すべてのファイル編集後にeslintを実行するフックを書いて」や「migrationsフォルダへの書き込みをブロックするフックを書いて」のようなプロンプトを試してください。
例外なく毎回何かが起こる必要がある場合(フォーマット、リンティング、機密ファイルへの書き込みブロック)はフックを使用してください。
判断が必要なガイダンスの場合(コードスタイルの好み、アーキテクチャパターン)はCLAUDE.mdを使用してください。
フックは決定論的、CLAUDE.mdは助言的です。
カスタムサブエージェントを作成する
Claudeが委任できる専門アシスタントを
.claude/agents/に定義する。
各サブエージェントは独自のコンテキストウィンドウ、ツール、指示を持つ。
スラッシュコマンド(明示的に呼び出すプロンプトテンプレート)とは異なり、サブエージェントは独自のコンテキストで独自の許可されたツールセットで実行されます。
スクリプト化されたワークフローではなく、委任されたアシスタントです。
---
name: security-reviewer
description: セキュリティの脆弱性についてコードをレビュー
tools: Read, Grep, Glob, Bash
model: opus
---
あなたはシニアセキュリティエンジニアです。以下についてコードをレビューしてください:
- インジェクション脆弱性(SQL、XSS、コマンドインジェクション)
- 認証と認可の欠陥
- コード内のシークレットまたは資格情報
- 安全でないデータ処理
具体的な行参照と提案される修正を提供してください。
サブエージェントが有用な場面:
- コードレビュー:レビュアーサブエージェントがメインの会話にバイアスを与えずに作業をチェック
- 調査:メインコンテキストを消費せずに不慣れなコードを探索
- 専門タスク:セキュリティレビュー、ドキュメント生成、テスト作成
- 検証:サブエージェントにメインエージェントの作業が正しいかチェックさせる
明示的にサブエージェントを使用するようClaudeに指示してください:「サブエージェントを使ってこのコードのセキュリティ問題をレビューして」
エージェントスキルを追加する
.claude/skills/にMarkdownファイルを作成して、Claudeが自動的に適用するドメイン知識を与える。スラッシュコマンドとは異なり、スキルは明示的な呼び出しではなくコンテキストによってトリガーされる。
スキルは、プロジェクト、チーム、またはドメインに固有の情報でClaudeの知識を拡張します。
Claudeはスキルを読み、タスクに基づいていつ適用するかを自律的に決定します。
---
name: api-conventions
description: サービス用のREST API設計規約
---
# API規約
- URLパスにはkebab-caseを使用
- JSONプロパティにはcamelCaseを使用
- リストエンドポイントには常にページネーションを含める
- URLパスでAPIをバージョン管理(/v1/、/v2/)
スキルと他のカスタマイズの比較
| 機能 | トリガー | 最適な用途 |
|---|---|---|
| CLAUDE.md | 常に読み込み | グローバルプロジェクトコンテキスト |
| スラッシュコマンド | 明示的な/command | 繰り返し可能なワークフロー |
| スキル | コンテキスト(自動) | ドメイン知識 |
| サブエージェント | 委任 | 分離されたタスク |
効果的にコミュニケーションする
Claude Codeとのコミュニケーション方法は、結果の品質に大きく影響します。
コードベースについて質問する
シニアエンジニアに聞くような質問をClaudeにする。
新しいコードベースにオンボーディングするとき、Claude Codeを学習と探索に使用してください。他のエンジニアに聞くのと同じような質問をClaudeにできます:
- ロギングはどう機能する?
- 新しいAPIエンドポイントはどう作る?
foo.rsの134行目のasync move { ... }は何をする?CustomerOnboardingFlowImplはどんなエッジケースを処理する?- このコードが333行目で
bar()ではなくfoo()を呼ぶのはなぜ?
この方法でClaude Codeを使用することは効果的なオンボーディングワークフローであり、立ち上げ時間を改善し、他のエンジニアの負担を軽減します。
特別なプロンプティングは不要で、直接質問してください。
Claudeにインタビューさせる
大きな機能の場合、最初にClaudeにインタビューさせる。
最小限のプロンプトから始めて、AskUserQuestionツールを使ってインタビューするようClaudeに依頼する。
Claudeはまだ考慮していないかもしれないことについて質問します。
技術的な実装、UI/UX、エッジケース、懸念事項、トレードオフなど。
[簡単な説明]を構築したい。AskUserQuestionツールを使って詳細にインタビューして。
技術的な実装、UI/UX、エッジケース、懸念事項、トレードオフについて聞いて。
明らかな質問はせず、考慮していないかもしれない難しい部分を掘り下げて。
すべてをカバーするまでインタビューを続けてから、完全な仕様をSPEC.mdに書いて。
仕様が完成したら、実行するために新しいセッションを開始してください。
新しいセッションは実装に完全に集中したクリーンなコンテキストを持ち、参照する文書化された仕様があります。
セッションを管理する
会話は永続的で元に戻せます。
これを有利に活用してください!
早めに、頻繁に軌道修正する
Claudeが軌道を外れていると気づいたらすぐに修正する。
最良の結果は緊密なフィードバックループから生まれます。
Claudeが最初の試みで完璧に問題を解決することもありますが、一般的には素早く修正することでより良いソリューションがより速く得られます。
Esc:Escキーでアクション中にClaudeを停止。
コンテキストは保持されるので、リダイレクトできますEsc + Escまたは/rewind:Escを2回押すか/rewindを実行して巻き戻しメニューを開き、以前の会話とコード状態を復元- 「それを元に戻して」:Claudeに変更を元に戻させる
/clear:無関係なタスク間でコンテキストをリセット。
無関係なコンテキストを含む長いセッションはパフォーマンスを低下させる可能性があります
同じセッションで同じ問題について2回以上Claudeを修正した場合、コンテキストは失敗したアプローチで散らかっています。
/clearを実行して、学んだことを組み込んだより具体的なプロンプトで新しく始めてください。
より良いプロンプトでのクリーンなセッションは、蓄積された修正を含む長いセッションをほぼ常に上回ります。
コンテキストを積極的に管理する
タスク間で
/clearを頻繁に実行してコンテキストウィンドウをリセットする。
Claude Codeはコンテキスト制限に近づくと自動的に会話履歴を圧縮し、重要なコードと決定を保持しながらスペースを解放します。
長いセッション中、Claudeのコンテキストウィンドウは無関係な会話、ファイル内容、コマンドで埋まる可能性があります。
これはパフォーマンスを低下させ、時にはClaudeの注意を散らせます。
- タスク間で
/clearを頻繁に使用してコンテキストウィンドウを完全にリセット - 自動圧縮がトリガーされると、Claudeは最も重要なもの(コードパターン、ファイル状態、重要な決定)を要約
- より制御が必要な場合は、
/compact <指示>を実行(例:/compact API変更に焦点を当てて)
調査にはサブエージェントを使用する
「サブエージェントを使ってXを調査して」で調査を委任する。メインの会話を実装用にクリーンに保ちながら、別のコンテキストで探索する。
コンテキストが基本的な制約であるため、サブエージェントは利用可能な最も強力なツールの1つです。
Claudeがコードベースを調査するとき、多くのファイルを読み、それらすべてがコンテキストを消費します。
サブエージェントは別のコンテキストウィンドウで実行し、要約を報告します:
サブエージェントを使って、認証システムがトークンリフレッシュをどう処理するか、
再利用すべき既存のOAuthユーティリティがあるかを調査して。サブエージェントはコードベースを探索し、関連ファイルを読み、発見を報告します。
すべてメインの会話を散らかさずに。
Claudeが何かを実装した後の検証にもサブエージェントを使用できます:
サブエージェントを使ってこのコードのエッジケースをレビューしてチェックポイントで巻き戻す
Claudeが行うすべてのアクションはチェックポイントを作成する。任意の以前のチェックポイントに会話、コード、または両方を復元できる。
Claudeは変更前に自動的にチェックポイントを作成します。
Escapeをダブルタップするか/rewindを実行してチェックポイントメニューを開きます。会話のみを復元(コード変更を保持)、コードのみを復元(会話を保持)、または両方を復元できます。
すべての動きを慎重に計画する代わりに、Claudeにリスクのあることを試させることができます。
うまくいかなければ、巻き戻して別のアプローチを試してください。
チェックポイントはセッション間で永続するので、ターミナルを閉じても後で巻き戻せます。
⚠️ 注意:チェックポイントはClaudeによって行われた変更のみを追跡し、外部プロセスは追跡しません。gitの代わりにはなりません。
会話を再開する
claude --continueを実行して中断したところから再開するか、--resumeで最近のセッションから選択する。
Claude Codeは会話をローカルに保存します。
タスクが複数のセッションにまたがるとき(機能を開始し、中断され、翌日戻ってくる)、コンテキストを再説明する必要はありません:
claude --continue # 最新の会話を再開
claude --resume # 最近の会話から選択/renameを使用してセッションに説明的な名前を付けてください(「oauth-migration」、「debugging-memory-leak」)。後で見つけやすくなります。
セッションをブランチのように扱ってください。異なるワークストリームは別々の永続的なコンテキストを持てます。
自動化とスケール
1つのClaudeで効果的になったら、並列セッション、ヘッドレスモード、ファンアウトパターンで出力を倍増させましょう。
ここまでは1人の人間、1つのClaude、1つの会話を前提としていました。
しかしClaude Codeは水平にスケールします。
このセクションのテクニックは、より多くのことを成し遂げる方法を示します。
ヘッドレスモードを実行する
💡 CI、pre-commitフック、またはスクリプトで
claude -p "prompt"を使用する。ストリーミングJSON出力には--output-format stream-jsonを追加。
claude -p "your prompt"で、対話型セッションなしでClaudeをヘッドレスで実行できます。
ヘッドレスモードは、ClaudeをCIパイプライン、pre-commitフック、または任意の自動化ワークフローに統合する方法です。
出力形式(プレーンテキスト、JSON、ストリーミングJSON)により、結果をプログラムで解析できます。
# 1回限りのクエリ
claude -p "このプロジェクトが何をするか説明して"
# スクリプト用の構造化出力
claude -p "すべてのAPIエンドポイントをリストして" --output-format json
# リアルタイム処理用のストリーミング
claude -p "このログファイルを分析して" --output-format stream-json
複数のClaudeセッションを実行する
開発を高速化したり、分離された実験を実行したり、複雑なワークフローを開始するために、複数のClaudeセッションを並列実行する。
並列セッションを実行する2つの主な方法:
- Claude Desktop:複数のローカルセッションを視覚的に管理。各セッションは独自の分離されたワークツリーを取得
- Web上のClaude Code:Anthropicのセキュアなクラウドインフラで分離されたVMで実行
作業の並列化を超えて、複数のセッションは品質重視のワークフローを可能にします。新鮮なコンテキストはコードレビューを改善します。Claudeは自分が書いたばかりのコードにバイアスを持ちません。
例えば、Writer/Reviewerパターンを使用:
| セッションA(Writer) | セッションB(Reviewer) |
|---|---|
| 「APIエンドポイント用のレートリミッターを実装して」 | |
| 「@src/middleware/rateLimiter.tsのレートリミッター実装をレビューして。エッジケース、レース条件、既存のミドルウェアパターンとの一貫性を確認」 | |
| 「レビューフィードバック:[セッションBの出力]。これらの問題に対処して」 |
テストでも同様のことができます:1つのClaudeにテストを書かせ、別のClaudeにそれをパスするコードを書かせます。
ファイル間でファンアウトする
タスクをループして各タスクで
claude -pを呼び出す。
バッチ操作の権限をスコープするには--allowedToolsを使用。
大規模な移行や分析では、多くの並列Claude呼び出しに作業を分散できます:
- タスクリストを生成:Claudeに移行が必要なすべてのファイルをリストさせる(例:「移行が必要なすべての2,000個のPythonファイルをリストして」)
- リストをループするスクリプトを書く:
for file in $(cat files.txt); do
claude -p "$fileをReactからVueに移行して。OKまたはFAILを返して" \
--allowedTools "Edit,Bash(git commit:*)"
done
- 数ファイルでテストしてから大規模実行:最初の2-3ファイルでうまくいかなかったことに基づいてプロンプトを改良し、その後フルセットで実行。
--allowedToolsフラグはClaudeができることを制限し、これは無人で実行するときに重要です。
既存のデータ/処理パイプラインにClaudeを統合することもできます:
claude -p "<your prompt>" --output-format json | your_command
開発中のデバッグには--verboseを使用し、本番では無効にします。
安全な自律モード
claude --dangerously-skip-permissionsを使用して、すべての権限チェックをバイパスし、Claudeを中断なしに作業させます。
これはリントエラーの修正やボイラープレートコードの生成のようなワークフローでうまく機能します。
⚠️ 警告:Claudeに任意のコマンドを実行させることはリスクがあり、データ損失、システム破損、またはデータ流出(プロンプトインジェクション攻撃など)を引き起こす可能性があります。これらのリスクを最小限に抑えるには、インターネットアクセスのないコンテナで
--dangerously-skip-permissionsを使用してください。サンドボックスを有効にすると(
/sandbox)、より良いセキュリティで同様の自律性が得られます。サンドボックスはすべてのチェックをバイパスするのではなく、事前に境界を定義します。
よくある失敗パターンを避ける
これらはよくある間違いです。
早く認識することで時間を節約できます:
キッチンシンクセッション
1つのタスクから始めて、Claudeに無関係なことを聞き、最初のタスクに戻る。
コンテキストは無関係な情報でいっぱい。
修正:無関係なタスク間で
/clear。
何度も修正する
Claudeが何か間違いをし、修正し、まだ間違い、また修正。
コンテキストは失敗したアプローチで汚染されている。
修正:2回の修正失敗後、
/clearして学んだことを組み込んだより良い初期プロンプトを書く。
過度に指定されたCLAUDE.md
CLAUDE.mdが長すぎると、重要なルールがノイズに埋もれてClaudeは半分を無視する。
修正:容赦なく剪定。Claudeが指示なしでも既に正しく行っていることがあれば、削除するかフックに変換する。
信頼してから検証のギャップ
Claudeがエッジケースを処理しないもっともらしい実装を生成する。
修正:常に検証(テスト、スクリプト、スクリーンショット)を提供する。
検証できなければ、出荷しない。
無限の探索
スコープを定めずにClaudeに何かを「調査」するよう依頼する。
Claudeは数百のファイルを読み、コンテキストを埋める。
修正:調査を狭くスコープするか、サブエージェントを使用して探索がメインコンテキストを消費しないようにする。
直感を養う
このガイドのパターンは固定されたものではありません。
一般的にうまく機能する出発点ですが、すべての状況で最適とは限りません。
1つの複雑な問題に深く取り組んでいて履歴が価値がある場合、コンテキストを蓄積させるべきこともあります。タスクが探索的なのでClaudeに自分で解決させるために計画をスキップすべきこともあります。
問題を制約する前にClaudeがどう解釈するか見たいので、曖昧なプロンプトがまさに正しいこともあります。
何がうまくいくかに注意を払ってください。
Claudeが素晴らしい出力を生成したとき、何をしたか気づいてください:プロンプトの構造、提供したコンテキスト、使用していたモード。
Claudeが苦戦したとき、なぜか問いかけてください。
コンテキストがノイズだらけ?プロンプトが曖昧すぎ?タスクが1回のパスには大きすぎ?
時間とともに、どんなガイドでも捉えられない直感を養います。
いつ具体的にしていつオープンエンドにするか、いつ計画していつ探索するか、いつコンテキストをクリアしていつ蓄積させるかがわかるようになります。
