Claude Code活用術：AI時代のプログラミング効率を最大化する方法

Anthropic公式サイトで紹介されているClaude Codeのベストプラクティスとクイックスタートガイドをもとに、AI時代のプログラミングを効率的に進めるための実践的な方法をご紹介します。本記事は2026年9月2日に現行の公式ドキュメントの内容へ更新しました。

Claude Codeとは

Claude Codeは、Anthropicが提供するコマンドラインのコーディング環境です（登場の経緯は正式リリース時の記事を参照）。公式ドキュメントはこれを「エージェント型のコーディング環境」と位置づけ、質問に答えて待つチャットボットとは違い、ファイルを読み、コマンドを実行し、変更を加え、自律的に問題を解いていくと説明しています。開発者はその様子を見ていることも、途中で方向を変えることも、席を外すこともできます¹。

すべての土台にあるのはコンテキストウィンドウ

公式ドキュメントは、ベストプラクティスのほとんどが1つの制約に由来すると述べています。Claudeのコンテキストウィンドウはすぐ埋まり、埋まるにつれて性能が落ちるという制約です¹。会話のすべて、読んだファイル、コマンドの出力がここに乗るため、デバッグ1回やコードベースの探索1回で数万トークンを消費することもあります¹。ドキュメントは「コンテキストウィンドウは管理すべき最も重要なリソース」だとしています¹。

以下の実践項目は、いずれもこの制約への対処として読むと筋が通ります。

検証手段を与える

現行のドキュメントで最初に置かれている実践項目が、Claudeが自分で走らせられるチェックを用意することです。テスト、ビルド、比較用のスクリーンショットなど、合否が返るものを指します¹。

なぜ重要かというと、Claudeは「作業が終わったように見えたとき」に止まるためです。チェックが無ければ「終わったように見える」以外の信号が存在せず、開発者自身が検証ループの一部になってしまいます¹。合否が返るものを渡せば、Claudeが作業し、チェックを実行し、結果を読み、通るまで繰り返す、というループが自分で閉じます¹。

ドキュメントは、チェックをどの程度強く「終了の関門」にするかを4段階で示しています¹。

• 1つのプロンプトの中で: 同じメッセージの中でチェックの実行と反復まで指示する
• セッション全体で: /goal の条件として設定する。別の評価役が毎ターン再チェックし、目標が解決するまでClaudeは作業を続ける
• 決定的な関門として: Stop フックがスクリプトとしてチェックを走らせ、通るまでターンの終了をブロックする。ただし8回連続でブロックされるとClaude Codeがフックを上書きしてターンを終える
• 第三者の目として: 検証用のサブエージェントや動的ワークフローに、別のモデルで結果を反証させる

ドキュメントは、成功を主張させるのではなく証拠を出させることも勧めています。テストの出力、実行したコマンドとその戻り値、結果のスクリーンショットなどです。証拠を見るほうが、検証を自分でやり直すより速く、見ていなかったセッションにも使えます¹。

効果的な使い方：4つの基本ステップ

推奨されるワークフローが「探索 → 計画 → 実装 → コミット」の4段階である点は、公開当初から変わっていません¹。

1. 探索（Explore）から始める

まずplan modeに入り、変更を加えずにファイルを読ませて質問に答えさせます。plan modeへはShift+Tabを押してステータスバーに ⏸ plan mode on が出るまで切り替えるか、claude --permission-mode plan でセッションを開始します¹。

2. 計画（Plan）を立てる

plan modeのまま、詳細な実装計画を作らせます¹。Ctrl+Gを押すと計画をテキストエディタで開いて直接編集でき、Claudeが先へ進む前に手を入れられます¹。

ただしplan modeにはオーバーヘッドもあります。ドキュメントは、タイプミスの修正、ログ行の追加、変数名の変更のように範囲が明確で小さい修正なら、直接やらせてよいとしています。判断の目安は「差分を一文で説明できるなら計画は飛ばす」です¹。

3. 実装（Implement）

計画を承認するかShift+Tabでplan modeを抜け、計画と突き合わせながらコーディングさせます¹。

指示は具体的なほど手戻りが減ります。ドキュメントは、対象ファイル・シナリオ・テストの方針まで含めること、質問に答えられる情報源（該当箇所のgit履歴など）を指し示すこと、コードベース内の既存パターンを例として挙げることを勧めています¹。

4. コミット（Commit）で完了

作業が完了したら、内容を説明するコミットメッセージでのコミットとPR作成まで依頼できます¹。

環境を整える

CLAUDE.mdファイルの活用

CLAUDE.md は、Claudeがすべての会話の冒頭で読むファイルです。Bashコマンド、コードスタイル、ワークフローのルールなど、コードだけからは推測できない文脈を持たせます¹。/init を実行すると現在のプロジェクト構成をもとに雛形が生成されるので、そこから育てていく形になります¹。読み込まれたかどうかは /context で確認できます¹。

重要なのは短く保つことです。ドキュメントは各行について「これを消したらClaudeが間違えるようになるか？」を自問し、そうでなければ削れと述べています。肥大化したCLAUDE.mdは、Claudeが本来の指示を無視する原因になります¹。リポジトリにチェックインしたCLAUDE.mdなら、/doctor を実行するとClaudeがコードベースから導ける内容の削除案を出してくれます¹。

含めるべきでないものの目安として、Claudeがコードを読めば分かること、一般的な言語規約、詳細なAPIドキュメント（リンクで済ませる）、頻繁に変わる情報などが挙げられています¹。

1つの指示だけが繰り返し無視される場合は、その行だけに「IMPORTANT」のような強調を足します。多くの行を強調すると、どれも目立たなくなります¹。

なお、たまにしか必要にならない領域知識やワークフローはCLAUDE.mdではなくスキルに置くことが推奨されています。スキルは必要なときだけ読み込まれるので、毎回の会話を膨らませません¹。

権限モードの設計

初期の記事では「Safe YOLO mode」という呼び方で、Claudeに一定の自由度を与える運用を紹介していました。現行のドキュメントでは、この領域はpermission modeの枠組みとして整理されています。

• auto mode: Pro・Max・Teamの各プランでは、対話型のターミナルとVS Codeのセッションにおける既定の開始モードです。分類器モデルが開発者の代わりにほとんどの操作を確認し、権限の拡大、未知のインフラ、敵対的なコンテンツに誘導された操作といった危険に見えるものだけをブロックします¹（既定化の経緯はauto modeが既定になった件の記事を参照）
• Manual mode: それ以外のプランでの既定の開始モードです。ファイル書き込み、Bashコマンド、MCPツールなど、システムを変更しうる操作の前に毎回確認が入ります。安全ですが、10回目の承認あたりからはレビューではなくクリック作業になりがちだとドキュメント自身が認めています¹

確認の回数を減らす道具は2つあり、いずれもauto modeでも効きます。信頼できるツールを事前に許可する許可リスト（npm run lint や git commit など）と、ファイルシステムとネットワークのアクセスをOSレベルで制限するサンドボックスです¹。操作は /permissions と /sandbox から行い、自分で編集やコマンドを承認したいときはManual modeに切り替えます¹。

外部サービスはCLIツールで触らせる

ドキュメントは、外部サービスとやり取りする際に最もコンテキスト効率が良いのはCLIツールだとしています。GitHubを使うなら gh を入れておけば、Issueの作成、PRのオープン、コメントの読み取りにClaudeがそのまま使えます。gh が無い場合もGitHub APIは使えますが、認証なしのリクエストはレート制限に当たりやすくなります¹。

Claudeは知らないCLIツールも学習できるので、「foo-cli-tool --help で使い方を調べてから、A・B・Cを解いて」のように頼む形も紹介されています¹。

拡張のしかた：スキル・サブエージェント・フック・プラグイン

記事の公開当初は「カスタムスラッシュコマンド」が主な拡張手段でしたが、現在は用途ごとに4つの面が用意されています。

スキルは .claude/skills/ に SKILL.md を置いて、プロジェクトやチーム、領域に固有の知識と再利用可能なワークフローを持たせる仕組みです。関連する場面でClaudeが自動的に適用するほか、/スキル名 で直接呼び出せます。副作用があって手動でだけ起動したいワークフローには disable-model-invocation: true を指定します¹。

サブエージェントは .claude/agents/ に定義する専門アシスタントで、独立したコンテキストと独自の許可ツール一式を持ちます。多数のファイルを読むタスクや、本流の会話を散らかさずに特化した集中が要るタスクに向いています¹。

フックは、例外なく毎回起きてほしい動作のための仕組みです。CLAUDE.mdの指示があくまで助言なのに対し、フックは決定的で、その動作が起きることを保証します。設定は .claude/settings.json で行い、/hooks で現在の設定を一覧できます¹。

プラグインは、スキル・フック・サブエージェント・MCPサーバーを1つのインストール単位にまとめたものです。/plugin でマーケットプレイスを閲覧できます¹。

外部ツールとの接続にはMCPサーバーを使い、claude mcp add にサーバー名とURLまたはコマンドを渡します（例: claude mcp add --transport http notion https://mcp.notion.com/mcp）¹。Notion、Figma、自社のデータベースなどがここに繋がります¹。

セッションの扱い

会話は永続的で、巻き戻しもできます¹。

Claudeが道を外れたと気づいたら、早めに軌道修正するのが基本です。Escで動作を途中で止められ、そのときコンテキストは保持されるので、そのまま方向を変えられます¹。Escを2回、または /rewind でチェックポイントまで巻き戻せます¹。

大きな機能に取りかかる前には、Claudeに自分をインタビューさせる進め方も紹介されています。最小限のプロンプトから始めてAskUserQuestionツールでの詳細な質問を求め、技術的な実装、UI/UX、エッジケース、トレードオフを洗い出してSPEC.mdに書かせる、という流れです。仕様ができたら新しいセッションを起こして実行すると、実装だけに集中したきれいなコンテキストで進められます¹。

自動化とスケール

非対話モード

claude -p "プロンプト" で、対話プロンプトなしに実行できます。CIパイプライン、pre-commitフック、任意の自動化ワークフローへの組み込みはこの形です¹。出力形式はプレーンテキスト、JSON（--output-format json）、ストリーミングJSON（--output-format stream-json --verbose）から選べます¹。--no-session-persistence を渡さない限り、実行は再開可能なセッションを作ります¹。GitHub Actionsとの組み合わせについてはGitHub ActionsのMaxサブスクリプション対応の記事でも紹介しています。

非対話実行で止まらずに走らせたい場合は auto mode を使い、claude --permission-mode auto -p "fix all lint errors" のように指定します¹。

複数セッションの並行実行

並行実行の選択肢は、自分でどこまで調整したいかによって分かれます¹。

• worktrees: 分離したgitチェックアウトで別々のCLIセッションを動かし、編集が衝突しないようにする
• セッション間メッセージング: 自分で起こしたセッション同士に調査結果を渡させる
• デスクトップアプリ: 複数のローカルセッションを、それぞれ独自のworktreeで視覚的に管理する
• Claude Code on the web: 既定でAnthropic管理のインフラ上、クラウドでセッションを動かす
• agent view: リサーチプレビュー。claude agents でバックグラウンドに動き続けるセッションを起こし、1画面で見る
• agent teams: 実験的で既定では無効。共有タスク・メッセージング・チームリードによる複数セッションの自動調整

並行化以外の使いどころとして、品質重視のワークフローが挙げられています。新しいコンテキストはコードレビューを良くします。直前に自分が書いたコードへのバイアスがかからないためです¹。セッションAが実装し、セッションBがレビューするWriter/Reviewerパターンや、片方にテストを書かせてもう片方にそれを通すコードを書かせる形が紹介されています¹。

ファイルをまたいだファンアウト

大規模な移行や解析では、多数の並行実行に作業を分散できます。gitリポジトリの中なら /batch <指示> を実行すると、Claudeが変更を5〜30個のサブエージェントに分割します。各サブエージェントは自分のworktreeで作業し、それぞれプルリクエストを開きます¹。

自分のスクリプトから回す場合は、対象ファイルの一覧を作らせてから claude -p をループで呼びます。まず2〜3ファイルで試してプロンプトを直し、それから全体に流す、という手順です¹。無人で走らせるときは --allowedTools でできることを絞るのが要点になります¹。

敵対的なレビュー工程を挟む

タスクを完了とみなす前に、サブエージェントに新しいコンテキストで差分をレビューさせて不足を報告させる方法が推奨されています¹。無人で動く時間が長いほど、独立したチェックの価値が上がるという理屈です。新しいサブエージェントのコンテキストで動くレビュー役は、変更を生んだ推論ではなく差分と与えられた基準だけを見るので、結果をそれ自体として評価します¹。

正しさの確認には同梱の /code-review スキルを使えます。現在の差分をバグ観点で新しいサブエージェントがレビューし、結果をセッションに返します¹。

ただし注意点も明記されています。不足を探せと言われたレビュー役は、作業が妥当でもたいてい何かしら報告します。それを追いかけ続けると、余計な抽象化層、防御的なコード、起こりえないケースのテストといった過剰設計に向かいます。正しさや明示された要件に関わる不足だけを挙げるよう指示し、それ以外は任意扱いにするのが対処です¹。

よくある失敗パターン

ドキュメントは、早く気づけば時間の節約になる失敗を挙げています¹。

• なんでも詰め込むセッション: 1つのタスクを始めたのに無関係なことを尋ね、また元のタスクに戻る。コンテキストが無関係な情報で埋まる。対処は、無関係なタスクの間に /clear を挟むこと
• 修正の繰り返し: Claudeが間違え、直させ、まだ間違っていて、また直させる。失敗した試行でコンテキストが汚れる。対処は、2回失敗したら /clear して、学んだことを織り込んだ初回プロンプトを書き直すこと
• 書きすぎたCLAUDE.md: 長すぎると、重要なルールがノイズに埋もれてClaudeが半分を無視する。対処は、容赦なく削ること。指示が無くても正しく動いているならその行は消すか、フックに変換する

内部構造やより高度な使いこなしに興味がある方は、Claude Code Deep Diveの記事も参考にしてください。

Sources

1. Best practices for Claude Code - Anthropic公式ドキュメント（Claude Codeのベストプラクティス。旧URL anthropic.com/engineering/claude-code-best-practices からの移転先）
2. Claude Code Quickstart - Anthropic公式ドキュメント（初心者向けクイックスタートガイド。旧URL docs.anthropic.com/en/docs/claude-code/quickstart からの移転先）