Claudeベストプラクティス｜指示と設定の要点

Claude CodeでCLAUDE.mdを書いたのに指示が効かない、セッションが長くなると精度が落ちる、そんな悩みを抱えていないでしょうか。本記事では、プロンプト設計とワークフロー・環境設計という2つの軸に沿って、claudeのベストプラクティスを体系的に整理します。CLAUDE.mdを200行以内に収める根拠、検証手段を与えた探索→計画→実装のフロー、コンテキストを圧縮・リセットするタイミング、権限設定とフックによる安全な自動化、そして2026年10月時点の最新モデル動向まで、実務でそのまま使えるチェックポイントとして解説します。読み終えたら、自分のCLAUDE.mdやプロンプトをその場で見直せる状態を目指します。

claudeのベストプラクティスとは？押さえるべき2つの軸

「claude ベストプラクティス」と一口に言っても、実はその中身は大きく性質の異なる2つの領域に分かれています。この整理をせずに個別のテクニックだけを拾い読みすると、「自分が今どの問題を解決しようとしているのか」が曖昧なまま設定をいじり続けることになりがちです。まずは全体像を押さえておきましょう。

軸①：プロンプト設計（何を・どう伝えるか）

1つ目の軸は、Claudeに対する指示の出し方そのものに関わる領域です。チャットで使う場合もAPI経由で使う場合も、Claude Codeのようなエージェント型ツールで使う場合も共通して効いてくる、いわば「土台」の技術といえます。

指示を明確かつ直接的に書くこと
コンテキストや役割をどう構造化して渡すか
例示（few-shot）をどこまで使うか
最新モデルの特性に合わせて指示量を調整すること

この領域は、Anthropic公式のプロンプティングガイドが体系的にまとめている分野で、モデルの世代が変わっても考え方の根幹はあまり変わりません。次のH2「プロンプト設計の基本原則」で詳しく扱います。

軸②：ワークフロー・環境設計（Claude Codeの運用）

2つ目の軸は、Claude Codeというコーディングエージェントを、プロジェクトの中でどう運用するかという領域です。こちらはプロンプト単体の話ではなく、

プロジェクト設定ファイルであるCLAUDE.mdの設計
検証手段を与えた上での探索→計画→実装というワークフロー
コンテキストウィンドウやセッションの管理
権限設定・フックによる安全な自動化

といった、いわば「開発現場のオペレーション」に近い領域です。個々のプロンプトがどれだけ優れていても、CLAUDE.mdが肥大化していたり、コンテキストが汚染されたまま作業を続けていたりすると、Claude Codeは本来の性能を発揮できません。逆に言えば、この軸を整えることが、Claude Codeを「毎回微調整が必要な道具」から「安定して任せられるパートナー」に変える分かれ目になります。

2つの軸はどう対応しているか

本記事のH2構成は、この2つの軸に沿って設計しています。

軸①（プロンプト設計）：「プロンプト設計の基本原則」
軸②（ワークフロー・環境設計）：「CLAUDE.mdの書き方」「検証・探索→計画→実装」「コンテキストウィンドウとセッション管理」「権限設定・フック・自動化」

さらに、この2つの軸をどう活かすかは、実際にどのモデルを使うかによっても変わってきます。2026年10月現在のClaudeはFable 5.1・Opus 5.5・Sonnet 5.5・Haiku 4.5という構成になっており、タスクの性質に応じたモデル選択も広い意味でのベストプラクティスの一部です。この点は最後のH2で改めて整理します。

まずは、すべての土台となるプロンプト設計の原則から見ていきましょう。

プロンプト設計の基本原則

Claude Codeの運用ノウハウに入る前に、まずはチャットやAPI経由でClaudeを使う際の土台となる、プロンプト設計の基本原則を押さえておきます。Anthropic公式のプロンプティングガイド（Prompting best practices）は、Claude Fable 5.1、Claude Opus 5.5、Claude Sonnet 5.5、Claude Haiku 4.5といった現行モデルに加え、Claude Mythos 5.1や一つ前の世代のモデルまでを対象にしており、モデルが変わっても通用する原則として整理されています。

明確かつ直接的に指示する

Claudeへの指示は、あいまいな依頼文よりも、目的・出力形式・制約条件を明示した直接的な指示の方が精度高く遵守されます。特に見落とされがちなのが「肯定形で伝える」という点です。

「〜しないでください」という否定形の指示よりも
「〜してください」という肯定形の指示の方が

意図した出力に近づきやすくなります。公式ガイドも「何をしないか」ではなく「代わりに何をするか」を伝えるよう勧めており、「回答にMarkdownを使わないで」ではなく「なめらかな散文の段落で回答して」と書く例を挙げています。同じように、「専門用語を使わないで」ではなく「中学生にもわかる言葉で説明して」のように、避けたい行動を禁止するのではなく、望む行動そのものを具体的に指定するのが基本です。

また、指示は一文にまとめず、目的・背景・期待する出力形式を分けて書くことも有効です。「何を」「なぜ」「どんな形式で」の3点を意識するだけで、Claudeが解釈を誤る余地は大きく減らせます。

コンテキストと役割をXMLタグで構造化する

プロンプトに含める要素が増えてくると、Claudeがどこまでが指示で、どこからが参考情報なのかを取り違えるリスクが高まります。ここで有効なのがXMLタグによる構造化です。

Anthropic公式は、プロンプトに指示・コンテキスト・例・入力データなどが混在する場合、種類ごとに別のXMLタグで囲むとClaudeが曖昧さなく解析でき、誤解が減ると説明しています。たとえば次のように、役割・背景情報・指示を別々のタグで囲むイメージです。

<role>あなたは経験豊富なマーケティングライターです</role>
<context>ここに参考資料や前提条件を記述</context>
<instruction>上記を踏まえて、300字の要約を作成してください</instruction>

ここで大切なのは、特定のタグ名を覚えることではありません。公式ガイドが挙げるポイントは、プロンプト全体で一貫した、中身が分かるタグ名を使うことと、内容に階層がある場合はタグを入れ子にすることです。自分たちのプロジェクトで使いやすい命名ルールを決め、それを一貫して使い続ける方が実務上は効果的です。

役割設定（ロールプロンプティング）も同様に、この構造化の一部として機能します。公式ガイドは、システムプロンプトで役割を設定するとClaudeの振る舞いや口調がその用途に絞られ、一文だけでも効果があると説明しています。役割を冒頭で明示することで、以降の指示や文脈をClaudeがどの視点から解釈すべきかが定まりやすくなります。

例示（few-shot）と最新モデルでの「引き算」発想

出力形式や文体を安定させたい場合は、期待する出力の具体例を示すfew-shotプロンプティングが効果的です。公式ガイドは例を3〜5個含めることを勧めており、例は<example>タグ（複数なら<examples>タグ）で囲んで指示と区別するよう説明しています。言葉での説明だけでは伝わりにくいニュアンス（トーン、粒度、フォーマットの細かい癖など）も、実例を見せることで精度が上がります。

ただし、ここで意識しておきたいのが、モデルの進化に伴う「引き算」の発想です。公式ガイドによると、Claude Opus 4.5・Opus 4.6は以前のモデルよりシステムプロンプトに敏感に反応し、Claude 4.6世代のモデルはより積極的に動くため、以前のモデルに必要だった指示が過剰な動作（overtrigger）を招くことがあります。以前は「CRITICAL: You MUST〜」のような強い表現を添えないと動いてくれなかった場面でも、最新モデルでは「〜のときはこのツールを使ってください」といった普通の書き方で十分だとされています。

具体的には、次のような見直しが有効です。

過去にうまくいったプロンプトの「念押し」表現を、そのまま流用していないか確認する
例示や制約条件を足すのではなく、まず不要な指示を削ってシンプルにしてみる
期待通りに動かない場合、指示を「強める」前に「減らす」選択肢を試す

プロンプト設計は、指示を積み増すほど良くなるとは限りません。モデルの世代が上がるほど、明確さと簡潔さを両立させる「引き算」の視点が、ベストプラクティスの一部として重要になってきています。

CLAUDE.mdの書き方ベストプラクティス

Claude Codeを使い込むほど、多くの人がCLAUDE.mdに情報を足したくなります。しかし「足せば足すほど賢くなる」というのは誤解です。ここでは行数の根拠、書くべき内容と書いてはいけない内容、そして階層設計という3つの観点から、失敗しないCLAUDE.mdの作り方を整理します。

200行ルールの根拠と「削っても大丈夫か」の問い

Claude Code公式ドキュメントのCLAUDE.mdの解説は、CLAUDE.mdのサイズについて「target under 200 lines per CLAUDE.md file. Longer files consume more context and reduce adherence.」と明示しています。つまり200行を超えると、コンテキストを圧迫するだけでなく、指示への遵守率そのものが下がるということです。

Claude Code公式のベストプラクティスも同じ方向を示しています。肥大化したCLAUDE.mdは「本当に守ってほしい指示を無視させる」原因になり、ルールを書いてあるのにClaudeが望まない動きを続けるなら、ファイルが長すぎて肝心のルールが埋もれている可能性が高い、という説明です。行数を減らすこと自体が、Claudeの理解精度を上げる施策になり得るということです。

では実際に何を削ればよいのでしょうか。公式が勧める問いは「この行がなくなったら、Claudeは間違うか？（Would removing this cause Claude to make mistakes?）」です。答えがNoであれば、その行は削除して構いません。一般論や当たり前のコーディング規約を書き連ねるより、そのプロジェクト特有の落とし穴（Gotchas）を優先的に残す方が、Claudeの挙動改善に直結します。

書くべき内容と書いてはいけない内容

CLAUDE.mdに書くべきなのは、そのプロジェクトでしか起きない罠と、絶対に守ってほしいルールです。公式のベストプラクティスでは、Claudeが推測できないBashコマンド、デフォルトと異なるコードスタイル、テストの手順、ブランチ名やPRの作法、プロジェクト固有の設計判断、必要な環境変数などの開発環境の癖、自明でない落とし穴を「書くもの」として挙げています。反対に、コードを読めば分かること、Claudeが既に知っている言語の標準規約、詳細なAPIドキュメント、頻繁に変わる情報、長い説明、ファイルごとの説明、「きれいなコードを書く」のような自明な心がけは「書かないもの」です。最初から完璧を目指す必要はなく、/initで叩き台を生成し、実際に困った場面に遭遇するたびに見直していくやり方が推奨されています。

一方で見落としがちなのが、CLAUDE.mdの性質そのものです。公式ドキュメントによれば、CLAUDE.mdはコンテキストとして読み込まれるものであり、強制設定（enforced configuration）ではありません。つまり書いた内容はClaudeが「参考にする」ものであり、Hooksのような確実な実行保証はないということです。したがって「絶対にこのコマンドを実行させたくない」といった強制力が必要な制約は、CLAUDE.mdではなく後述のパーミッション設定やフックで担保すべきで、CLAUDE.mdに書くのは「参考にしてほしい情報」に留めるのが適切な役割分担です。

具体的な書き方としては、長い説明を直接書き込むのではなく、詳細は別の仕組みへ切り出し、CLAUDE.mdは要点に絞る方針が有効です。ただし@path/to/file形式のインポートは、取り込んだファイルも起動時に読み込まれるため、整理には役立ってもコンテキストの消費は減らない点に注意が必要です。コードベースの一部にしか関係しない指示は、該当ファイルを扱うときだけ読み込まれる.claude/rules/のパス限定ルールへ、ときどきしか使わない手順や知識は必要なときだけ読み込まれるSkillsへ移すと、行数とコンテキストの両方を抑えられます。

階層設計とAuto Memoryとの役割分担

CLAUDE.mdはプロジェクト直下に1つ置くだけのものではありません。Managed policy・Project・User・Localという4階層のスコープを使い分けることで、組織共通のルール、プロジェクト固有のルール、個人の好み、ローカル環境限定の設定を適切に分離できます。すべてを1ファイルに詰め込もうとすると、すぐに200行の壁に突き当たるため、この階層設計そのものが行数を抑える手段としても機能します。

さらに2026年時点では、Auto Memoryという仕組みも役割分担の選択肢に加わっています。これはClaudeが作業中のあなたの修正や好みをもとに、ビルドコマンドやデバッグの気づき、コードの癖などを自動で~/.claude/projects/<project>/memory/配下に書き溜めていく機能です。索引となるMEMORY.mdの冒頭200行（または25KB、先に達した方）が毎セッション自動ロードされ、詳細なメモはトピック別ファイルとして必要なときだけ読み込まれます。

つまりCLAUDE.mdは人間が意図的に「絶対守ってほしいこと」を書く場所、Auto MemoryはClaude自身が学習した「次回も使えそうな気づき」を蓄積する場所、という住み分けです。この2つを混同して、Claudeが勝手に覚えてくれるような情報までCLAUDE.mdに手作業で書き込んでしまうと、無駄な行数の増加につながります。どちらの仕組みに何を任せるかを意識することが、200行以内という制約の中で実効性の高いCLAUDE.mdを保つコツです。各階層の置き場所と読み込み順、/initでの作り方、コピペで使える雛形はCLAUDE.mdの書き方と置き場所で説明しています。

検証・探索→計画→実装という黄金ワークフロー

Claude Codeを使っていて「一見動いているように見えるが、実は要件を満たしていない」というケースに遭遇したことはないでしょうか。この問題を防ぐカギは、プロンプトの書き方そのものよりも「Claudeに何を検証させるか」という設計にあります。

検証手段を与えるという最重要ポイント

Claude Code公式のベストプラクティスは、検証手段を与えることを最初の項目に置いています。Claudeは作業が「完了したように見えた」時点で止まるため、実行できるチェックがなければ人間が検証ループの役を担うことになります。合否を返すチェックを与えれば、Claudeは作業し、チェックを実行し、結果を読み、合格するまで反復する、というのが公式の説明です。

つまりClaudeは、明確な「合格・不合格」の基準がなければ、コードが動いたように見える段階で作業を終えてしまいがちです。逆に、以下のような検証手段を最初から用意しておくと、Claudeはそれをクリアするまで自律的に修正を繰り返します。

テストコード：ユニットテストや結合テストを実行させ、失敗が出れば自動で原因を追って修正する
ビルド確認：型エラーやリントエラーが出ないかを確認させる
スクリーンショット比較：UI変更であれば、期待する見た目とのズレを画像で比較させる

これらの検証手段があるかないかで、Claudeの成果物の信頼性は大きく変わります。人間がいちいち動作確認をして「これは違う」とフィードバックし続ける状態は、時間もかかり、指示の一貫性も保ちにくくなります。最初のプロンプトの中に「テストを通すまで繰り返してください」といった検証ループの起点を組み込むことが、ベストプラクティスの出発点になります。公式は、セッション全体で条件を課す/goalや、チェックが通るまでターンの終了を止めるStopフックといった、より強い方法も紹介しています。

探索→計画→実装→コミットの4フェーズ

検証手段を用意したうえで、Claude Codeの作業を「探索（Explore）→計画（Plan）→実装（Implement）→コミット（Commit）」の4フェーズに分けて進めると、手戻りを大きく減らすことができます。公式のベストプラクティスも、この4フェーズを推奨ワークフローとして示しています。

まず探索フェーズでは、いきなり実装を指示するのではなく、関連ファイルを読み込ませて状況を把握させることが重要です。公式は、Shift+TabでPlan Modeに切り替えるかclaude --permission-mode planで起動し、変更を加えずにファイルを読ませたり質問に答えさせたりする進め方を紹介しています。この一手間が後工程の精度を大きく左右します。

次に計画フェーズでは、実装方針をいきなり実行させず、まず計画だけを立てさせて確認する「Plan Mode」の活用が有効です。公式ドキュメントでは、計画が特に役立つ場面として次の3つが挙げられています。

アプローチが不明確なとき
複数ファイルに変更を加えるとき
馴染みのないコードベースを扱うとき

一方で、タイポ修正やログ1行の追加のような軽微な作業であれば、Plan Modeを使わずに直接実行させても問題ありません。公式も「差分を一文で説明できるなら計画は省略してよい」としています。作業の規模とリスクに応じてPlan Modeの利用を判断することが、時間の節約とミスの防止を両立させるポイントです。

実装フェーズでは、検証手段（テストやビルド確認）を軸にClaudeが自律的に修正を繰り返せる状態を保ちます。そして最後のコミットフェーズで、変更内容を整理してコミットメッセージを作成させます。

なお、このワークフローの中でよく起きる失敗パターンとして、同じ修正を繰り返してもうまくいかず、コンテキストが失敗アプローチの情報で汚染されてしまう状況があります。この対策として、公式のベストプラクティスは「同じ問題で2回以上修正しても直らないなら、/clearして、学んだことを盛り込んだより具体的なプロンプトでやり直す」という基準を示しています。同じ方向性で粘り続けるよりも、一度リセットして計画フェーズからやり直す方が、結果的に早く正しい実装にたどり着けるケースが多いといえます。コンテキストそのものの管理方法については、次の項で詳しく扱います。

コンテキストウィンドウとセッション管理

Claude Codeを長時間使い続けていると、途中から応答が遅くなったり、以前に伝えた指示を忘れたように振る舞ったりすることがあります。この現象の多くは、コンテキストウィンドウの圧迫が原因です。ここでは、何がコンテキストを消費しているのかを理解したうえで、セッションを適切に管理する方法を整理します。

コンテキストウィンドウに何が積まれるのか

コンテキストウィンドウには、会話履歴だけでなく、読み込んだファイルの中身、実行したコマンドの出力、ツール呼び出しの結果などがすべて蓄積されていきます。特に大きなファイルを読み込んだり、冗長なログを出力するコマンドを実行したりすると、あっという間にウィンドウを圧迫してしまいます。公式のベストプラクティスも、コンテキストが埋まってくるとClaudeが前の指示を「忘れ」たりミスが増えたりするとして、コンテキストウィンドウを最も重要な管理対象に位置づけています。

Claude Code公式のコンテキストウィンドウの解説では、サブエージェントに作業を任せた場合について「サブエージェントの最終的な応答と、トークン数や所要時間を記した小さなメタデータだけがあなたのコンテキストに戻る」と説明されています。裏を返せば、メインのセッションで直接ファイルを読み込んだり調査を行ったりすると、その中身がそのままコンテキストに残り続けるということです。この仕組みを理解しているかどうかで、セッション管理の質は大きく変わります。

/compactと/clearの使い分けと実行タイミング

コンテキストが膨らんできたときの主な対処法が「/compact」と「/clear」です。

/compact：会話履歴を要約・圧縮して、コンテキストウィンドウの空き容量を回復するコマンドです。公式は「/compactは会話を構造化されたサマリーに置き換えます」と説明しており、それまでの文脈を大まかに保ったまま作業を続けたい場合に適しています。/compact Focus on the API changesのように、残したい内容を指示することもできます。
/clear：文脈をリセットして新しいセッションとして再スタートするコマンドです。特に、失敗したアプローチの試行錯誤がコンテキストに残り続けている状態（コンテキスト汚染）では、要約より初期化のほうが有効な場合があります。前述のとおり、公式も「2回以上修正しても直らなければ/clearしてやり直す」ことを勧めています。

実行タイミングについて、公式は使用率の目安となる数値は示していません。代わりに示しているのは、関係のないタスクの間では頻繁に/clearすること、上限が近づくとClaude Codeが自動で会話を圧縮すること（100万トークンのコンテキストを持つモデルでは既定で約96.7万トークンで圧縮）、そしてステータスラインでコンテキストの使用量を常に確認できるようにしておくこと、といった運用です。使い切ってから慌てて圧縮するのではなく、タスクの区切りごとに手を打つのがポイントです。

前のH2で触れた探索フェーズも、この文脈と地続きです。「コードはまだ書かなくていい」と伝えたうえでファイルを読ませる探索は、コンテキストを消費しやすい工程でもあるため、必要な範囲に絞って行うことが結果的にセッション全体の健全性を保つことにつながります。公式も、範囲を決めずに「調べて」と頼んで何百ものファイルを読ませてしまう「無限探索」を、よくある失敗パターンに挙げています。

サブエージェントに調査を委任する

コンテキストを圧迫しやすい「調査」そのものを、メインのセッションから切り離す方法もあります。それがサブエージェントの活用です。

Claude Codeでは.claude/agents/に特化したアシスタントを定義でき、公式のベストプラクティスでは「サブエージェントは独自のコンテキストと独自の許可されたツールセットで実行されます」と説明されています。Explore（読み取り専用の探索用）やPlan（Plan Mode中の調査用）といった組み込みのサブエージェントも用意されています（Claude Code公式のサブエージェントの解説）。大量のファイルを読み込んで調べる作業や、複数の候補を比較検討するような下調べは、サブエージェントに任せてしまえば、その過程で発生する大量の中間データはサブエージェント側のコンテキストに留まり、メインセッションには要約された結果だけが返ってきます。

こうしたサブエージェントの活用は、単なる作業の並列化にとどまらず、コンテキスト管理の観点でも有効です。公式も「use subagents to investigate X」のように調査をサブエージェントへ任せ、メインの会話は実装のためにきれいに保つ使い方を勧めています。実装後の検証を、新しいコンテキストを持つサブエージェントにレビューさせる使い方も紹介されています。調査や下調べが必要な場面では、メインセッションで直接手を動かす前に、サブエージェントへの委任を検討する価値があります。

権限設定・フック・自動化で安全にスケールする

Claude Codeを個人の対話ツールから、チームやCI/CDで使う自動化基盤へと広げていく段階で欠かせないのが、権限設計とフックの正しい理解です。ここを曖昧にしたまま自動化を進めると、意図しないコマンド実行やファイル破壊のリスクが一気に高まります。

パーミッションモードとdeny-firstの考え方

Claude Code（およびClaude Agent SDK）には、default・acceptEdits・plan・auto・dontAsk・bypassPermissionsという6つのpermission modeが用意されており、用途に応じて許可の範囲を切り替えられます（Claude Code公式のパーミッションモードの解説）。なお、Claude Code v2.1.283以降は、対話型のターミナルとVS Codeのセッションでauto mode（別の分類モデルが操作を審査し、危険そうなものだけを止めるモード）が既定の開始モードになっています。ここで基本になるのが「deny-first」、つまり原則すべて拒否したうえで、必要なものだけを個別に許可していく考え方です。

具体的な使い分けとしては、次のような整理が有効です。

本番CIで何かを生成する場合：dontAsk + allowedToolsを組み合わせ、「やっていいツールだけ」をホワイトリスト化する。dontAskは、確認が必要になる操作をすべて自動で拒否するモードです
サンドボックス内CI（dev containerなど）で動かす場合：bypassPermissionsで確認を省略しつつ、denyルールでrm -rf /系の破壊的コマンドを必ずブロックしておく。公式はbypassPermissionsを隔離されたコンテナやVMだけで使うよう求めており、denyルールはbypassPermissionsを含むすべてのモードで有効です

ポイントは、自動化を進めるほど「何を許可するか」ではなく「何を絶対に許可しないか」を先に固めることです。特にファイル削除や外部への書き込みを伴うコマンドは、たとえサンドボックス環境であっても明示的なdenyルールで防いでおくのが安全な運用といえます。Agent SDKでの設定方法はClaude Agent SDKとClaude Code CLIの違いでも整理しています。

フックの優先順位とよくある誤解

Hooksは、Claude Codeの特定のイベントに合わせて任意のスクリプトを実行できる仕組みで、権限管理と自動化を橋渡しする重要な機能です。ただし、フックの挙動には誤解が生じやすいポイントがいくつかあります。

まず優先順位について、複数のPreToolUseフックが異なる判定を返した場合、Claude Code公式のHooksリファレンスでは「deny > defer > ask > allow」の順で優先されると明記されています。つまり、どれか一つでもdenyを返せば、他のフックがallowと判定していても実行はブロックされる仕組みです。複数のフックを組み合わせて運用する際は、この優先順位を前提に設計する必要があります。

もう一つよくある誤解が、フックが発火するタイミングです。公式ドキュメントでは、PermissionRequestフックは非インタラクティブモード（-pフラグ）では発火しないと明記されており、自動化された許可判断にはPreToolUseフックを使うべきとされています。対話モード用に組んだフック設計をそのままCI/CD環境へ持ち込むと、期待した確認処理が動かないケースがあるため注意が必要です。

また、Stopフックについても「タスク完了時だけでなく、Claudeが応答を終了するたびに発火する」「ユーザーの割り込みでは発火しない」という仕様があります。「完了時にだけ通知が飛ぶはず」といった思い込みで設計すると、想定より頻繁に、あるいは想定した場面で発火しないという事態を招きやすいので、公式仕様を確認しながら組み立てることが欠かせません。

ヘッドレスモードとCI/CDでの自動化

ここまでの権限設定とフックの理解を土台にすると、Claude Codeをヘッドレスモード（-pフラグによる非対話実行）でCI/CDパイプラインに組み込む運用が現実的になります。

ヘッドレスモードでは人間が都度確認する余地がないため、

allowedToolsによる許可範囲の明確化
deny-firstに基づく破壊的操作のブロック
PreToolUseフックによる自動判定

という3つを事前に固めておくことが、安全な自動化の前提条件になります。公式のベストプラクティスでも、claude -pをファイルごとにループさせる一括処理の例で、--allowedToolsで必要なツールだけを事前承認し、--permission-mode dontAskでそれ以外を拒否する組み合わせが示されています。裏を返せば、対話モードでは多少ゆるく運用していた権限設定も、ヘッドレスモードに載せる際には見直しが必要になるということです。

CI/CD連携では、ビルドやテストの実行、コードレビューの自動コメントといったタスクにClaude Codeを組み込む活用が広がっています。GitHubとの連携方法はClaude GitHub連携の3つの方式で比較していますが、いずれの場合も「何を自動でやらせ、何を人間の確認に残すか」の線引きを、permission modeとフックの仕様に基づいて設計することが、安全にスケールさせるための鍵になります。

2026年最新モデルとClaude活用の指針

ベストプラクティスは、使っているモデルが何であるかによっても最適解が変わります。ここでは2026年10月7日時点の最新ラインナップを整理し、タスクに応じたモデル選択の考え方を押さえます。

2026年10月時点のモデル構成

Anthropic公式のモデル一覧（Models overview）によると、2026年10月時点でのClaudeの現行ラインナップは、Fable 5.1・Opus 5.5・Sonnet 5.5の3モデルと、高速モデルのHaiku 4.5を合わせた4モデルです。2026年9月1日にFable 5.1、9月22日にOpus 5.5、9月28日にSonnet 5.5が相次いで公開され、それまでのFable 5・Opus 5・Sonnet 5はレガシーモデル（引き続き利用可能）の扱いになりました。

それぞれの立ち位置と、100万トークンあたりのAPI料金（入力／出力）は次のとおりです。

Fable 5.1：高度な推論と長期間にわたるエージェント作業向けのモデルです（10ドル／50ドル）。
Opus 5.5：長時間のエージェント型コーディングと知識労働向けのモデルです（4ドル／20ドル）。公式は、迷ったらまずOpus 5.5から始め、Opus 5.5で高いeffortにしても足りない場合にFable 5.1を使うよう勧めています。Claude CodeでもPro・Max・Team・EnterpriseとAPIの既定モデルはOpus 5.5です（Claude Code公式のモデル設定の解説）。
Sonnet 5.5：速度と知能のバランスが最も良いモデルです（2ドル／10ドル）。
Haiku 4.5：最も高速なモデルで、軽量タスクや大量処理に適しています（1ドル／5ドル）。なお、AnthropicはHaiku 5.5を数週間以内に追加すると予告しています。

Fable 5.1・Opus 5.5・Sonnet 5.5はいずれも100万トークンのコンテキストウィンドウを持ち、Claude Codeでも、Anthropic経由で使う場合はプランを問わず追加の設定なしで100万トークンで動作します。各モデルの違いはClaudeのモデル比較で詳しく整理しています。

Sonnet 5.5のコストパフォーマンス

モデル選択で実務上のインパクトが大きいのが、Sonnet 5.5の位置づけです。Anthropicの発表（Introducing Claude Sonnet 5.5）によると、Sonnet 5.5はOpus 5.5を補う、より速く低コストなモデルという位置づけで、範囲のはっきりした日常的なタスクやバグ修正、資料作成を得意とします。料金はSonnet 5と同じ100万トークンあたり入力2ドル／出力10ドルですが、同じ作業に必要なトークンが少なく、タスクあたりのコストはSonnet 5より最大30%低く、出力も30%以上速いとされています。エージェント型コーディングの評価であるTerminal-Bench 4.0では70.6%と、Sonnet 5の10.3%から大きく伸びました。

一方で、上位のOpus 5.5は入力4ドル／出力20ドルで、Anthropicの発表（Introducing Claude Opus 5.5）ではOpus 5より40%安く動かせるとされています。Anthropicは、ベンチマークの数値によってはSonnet 5.5がOpus 5.5に並ぶものの、持続的な判断が必要な複雑で自由度の高い作業ではOpus 5.5の方が明らかに強いとしています。日常的なコーディングタスクや、CLAUDE.mdに沿った反復的な実装作業であればSonnet 5.5を基準モデルとし、設計判断が難しい局面や大規模な計画立案が必要なときはOpus 5.5に切り替える、という運用がコストと精度のバランスを取りやすい選択になります。Claude Codeには、Plan ModeではOpusを使い、実装ではSonnetに切り替えるopusplanというモデル指定も用意されています。API料金の詳細はClaude APIの料金と始め方で解説しています。

タスクに応じたモデル選択の考え方

ここまで見た①プロンプト設計の原則、②CLAUDE.md・ワークフロー・コンテキスト管理・権限設計という運用の型は、いずれのモデルにも通用する土台です。その上で、モデル選択は「タスクの複雑度とコストのトレードオフ」を見極める最後のレイヤーだと捉えると整理しやすくなります。

探索・調査フェーズやサブエージェントへの委任作業は、Haiku 4.5のような高速モデルに任せて全体のスループットを上げる
実装フェーズの中心はSonnet 5.5を基本線とし、遵守率を保つためにCLAUDE.mdは200行ルールの範囲に収めておく
アーキテクチャ判断や複雑な障害対応など、後戻りコストの高い判断はOpus 5.5に任せ、それでも足りない難題にはFable 5.1を使う

モデルは今後も更新が続くと考えられますが、「検証手段を与える」「コンテキストを圧縮する」「権限を絞る」といった本記事で紹介したベストプラクティスの骨格は、モデルが変わっても引き続き有効な指針になります。

まとめ

claudeのベストプラクティスは、プロンプト設計とワークフロー・環境設計という2つの軸で整理すると見通しが良くなります。明確かつ肯定形での指示、XMLタグによる構造化、最新モデルに合わせた「引き算」の発想がプロンプト設計の土台です。運用面では、CLAUDE.mdを200行以内に保ち、検証手段を与えて探索→計画→実装→コミットのフローを踏むこと、タスクの区切りでコンテキストを圧縮・リセットすること、deny-firstの権限設計とフックの優先順位を理解して自動化することが要点になります。まずは自分のCLAUDE.mdを開き、「この行がなくなったら間違うか」を問いながら削れる箇所を見つけることから始めてみてください。