Claude ベストプラクティス完全ガイド｜CLAUDE.mdと運用の要点

Claude CodeでCLAUDE.mdを書いたのに指示が効かない、セッションが長くなると精度が落ちる、そんな悩みを抱えていないでしょうか。本記事では、プロンプト設計とワークフロー・環境設計という2つの軸に沿って、claudeのベストプラクティスを体系的に整理します。CLAUDE.mdを200行以内に収める根拠、検証手段を与えた探索→計画→実装のフロー、コンテキストを70〜80%で圧縮するタイミング、権限設定とフックによる安全な自動化、そして2026年9月時点の最新モデル動向まで、実務でそのまま使えるチェックポイントとして解説します。読み終えたら、自分の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年9月現在のClaudeはFable 5.1・Opus 5・Sonnet 5・Haiku 4.5という構成になっており、タスクの性質に応じたモデル選択も広い意味でのベストプラクティスの一部です。この点は最後のH2で改めて整理します。

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

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

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

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

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

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

AIには遵守されやすい傾向があるとされています。たとえば「専門用語を使わないで」ではなく「中学生にもわかる言葉で説明して」のように、避けたい行動を禁止するのではなく、望む行動そのものを具体的に指定する方が、意図した出力に近づきやすくなります。

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

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

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

Anthropic公式は、プロンプトにコンテキスト・指示・例など複数のコンポーネントが含まれる場合、XMLタグで区切ることがClaudeの正確な解析を助けると説明しています。たとえば次のように、役割・背景情報・指示を別々のタグで囲むイメージです。

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

ここで注意したいのは、「Claude専用の正解タグ名」が存在するわけではないという点です。公式も、Claudeが特定のタグ名でトレーニングされているわけではないと述べており、<role>や<context>といったタグ名自体に魔法があるのではなく、タグ名と中身の内容が一致していることの方が重要とされています。つまり、自分たちのプロジェクトで使いやすい命名ルールを決め、それを一貫して使い続ける方が実務上は効果的です。

役割設定（ロールプロンプティング）も同様に、この構造化の一部として機能します。「あなたは〇〇の専門家です」といった役割を冒頭で明示することで、以降の指示や文脈をClaudeがどの視点から解釈すべきかが定まりやすくなります。

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

出力形式や文体を安定させたい場合は、期待する出力の具体例を1〜3個ほど提示するfew-shotプロンプティングが効果的です。言葉での説明だけでは伝わりにくいニュアンス（トーン、粒度、フォーマットの細かい癖など）も、実例を見せることで一気に精度が上がります。

ただし、ここで意識しておきたいのが、モデルの進化に伴う「引き算」の発想です。Claude 4.6世代以降は、以前のモデルに比べてClaude自身が賢く、そして積極的に振る舞うようになっているという前提を持つことが重要とされています。以前は「もっと徹底的に」「絶対に」といった強い促しを添えないと動いてくれなかった場面でも、最新モデルではそうした強い表現がかえって過剰な行動を引き起こす原因になり得ます。

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

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

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

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

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

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

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

この裏付けとして興味深いのが、HumanLayerの検証結果です。指示数が増えたときに起きるのは「特定の指示だけが無視される」ことではなく、「すべての指示の遵守率が一様に下がる」という現象だと報告されています。これはフロンティアLLMが一貫して守れる指示数には150〜200程度の壁があるという指摘とも一致しており、200行ルールが単なる経験則ではなく、モデルの限界に基づいた実務上の目安であることがわかります。

実際にQiitaで紹介されている検証事例では、200行を超えていたCLAUDE.mdの品質スコアが79点だったのに対し、内容を50行のセキュリティルールから1行の参照パスに圧縮し、3ファイルに分割した結果、96.9点まで改善したという報告があります。行数を減らすこと自体が、Claudeの理解精度を上げる施策になり得るということです。

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

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

CLAUDE.mdに書くべきなのは、そのプロジェクトでしか起きない罠と、絶対に守ってほしいルールです。最初から完璧を目指す必要はなく、概要と絶対遵守ルールの2項目からスタートし、実際に困った場面に遭遇するたびに追記していくやり方が推奨されています。汎用的な「良いコードを書きましょう」といった精神論は、遵守率を下げる無駄な行として真っ先に削る対象です。

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

具体的な書き方としては、長い説明を直接書き込むのではなく、詳細は別ファイルへ切り出し、CLAUDE.mdは索引として保つという方針が有効です。ビルド手順やセキュリティルールの詳細を50行で書くのではなく、要点と参照パスの1行だけを残すことで、行数を抑えながら必要な情報にはいつでもたどり着ける構成にできます。

階層設計と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を保つコツです。

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

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

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

Claude Codeの検証重視の設計思想について、よっしーノートでは「Claude は『完了したように見える』時点で止まるため、テスト・ビルド・スクリーンショット比較など、合否シグナルを返すチェックを与えると、Claude 自身がチェックを実行し合格するまで反復するようになります。人間が検証ループになる状態を避けられます」と解説されています。

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

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

これらの検証手段があるかないかで、Claudeの成果物の信頼性は大きく変わります。人間がいちいち動作確認をして「これは違う」とフィードバックし続ける状態は、時間もかかり、指示の一貫性も保ちにくくなります。最初のプロンプトの中に「テストを通すまで繰り返してください」といった検証ループの起点を組み込むことが、ベストプラクティスの出発点になります。

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

検証手段を用意したうえで、Claude Codeの作業を「探索（Explore）→計画（Plan）→実装（Implement）→コミット（Commit）」の4フェーズに分けて進めると、手戻りを大きく減らすことができます。

まず探索フェーズでは、いきなり実装を指示するのではなく、関連ファイルを読み込ませて状況を把握させることが重要です。wentz-design.comが紹介する運用でも「Explore：ファイルを読ませる。『コードはまだ書かなくていい』と伝える」ことが推奨されており、この一手間が後工程の精度を大きく左右します。

次に計画フェーズでは、実装方針をいきなり実行させず、まず計画だけを立てさせて確認する「Plan Mode」の活用が有効です。Plan Modeを使うべき場面については、公式スライドで次のような基準が示されています（Speaker Deck/みのるん）。

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

一方で、タイポ修正のような軽微な作業であれば、Plan Modeを使わずに直接実行させても問題ありません。作業の規模とリスクに応じてPlan Modeの利用を判断することが、時間の節約とミスの防止を両立させるポイントです。

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

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

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

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

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

コンテキストウィンドウには、会話履歴だけでなく、読み込んだファイルの中身、実行したコマンドの出力、ツール呼び出しの結果などがすべて蓄積されていきます。特に大きなファイルを読み込んだり、冗長なログを出力するコマンドを実行したりすると、あっという間にウィンドウを圧迫してしまいます。

公式ドキュメントでも、サブエージェントは独自の別コンテキストウィンドウで処理を行うため「大きなファイル読み込みはあなたのコンテキストウィンドウから外れます。サマリーと小さなメタデータトレーラーだけが戻ってきます」と説明されています（code.claude.com公式）。裏を返せば、メインのセッションで直接ファイルを読み込んだり調査を行ったりすると、その中身がそのままコンテキストに残り続けるということです。この仕組みを理解しているかどうかで、セッション管理の質は大きく変わります。

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

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

/compact：会話履歴を要約・圧縮して、コンテキストウィンドウの空き容量を回復するコマンドです。公式は「/compactは会話を構造化されたサマリーに置き換えます」と説明しており（code.claude.com公式）、それまでの文脈を大まかに保ったまま作業を続けたい場合に適しています。
/clear：文脈をリセットして新しいセッションとして再スタートするコマンドです。特に、失敗したアプローチの試行錯誤がコンテキストに残り続けている状態（コンテキスト汚染）では、要約より初期化のほうが有効な場合があります。実際、「2回失敗したら/clearして再プロンプト」という運用が失敗パターンへの対策として紹介されています（Speaker Deck/みのるん）。

実行タイミングの目安としてよく言われるのが「70〜80%ルール」です。コンテキスト使用率がこの水準に達したら/compactを検討する、という考え方で、使い切ってから慌てて圧縮するのではなく、余裕があるうちに手を打つのがポイントです（start-link.jp）。また、そもそも1回のセッションで使うコンテキストは50%以内に収まるように作業を分割する、という目安を持っておくと、圧縮や初期化の頻度自体を減らせます（wentz-design.com）。

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

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

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

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

こうしたサブエージェントの活用は、単なる作業の並列化にとどまらず、コンテキスト管理の観点でも有効です。「Claude Codeを長時間使っていると、コンテキストが長くなりすぎてしまい、Claudeが以前の指示を忘れたり、動作が不安定になったりする」という問題を、独立コンテキストで動作するサブエージェントが緩和すると指摘されています（SHIFT AI TIMES）。調査や下調べが必要な場面では、メインセッションで直接手を動かす前に、サブエージェントへの委任を検討する価値があります。

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

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

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

Claude Agent SDKには6つのpermission modeが用意されており、用途に応じて許可の範囲を切り替えられます。ここで基本になるのが「deny-first」、つまり原則すべて拒否したうえで、必要なものだけを個別に許可していく考え方です。

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

本番CIで何かを生成する場合：dontAsk + allowedToolsを組み合わせ、「やっていいツールだけ」をホワイトリスト化する
サンドボックス内CI（dev containerなど）で動かす場合：bypassPermissionsで確認を省略しつつ、denyルールでrm -rf /系の破壊的コマンドを必ずブロックしておく

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

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

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

まず優先順位について、複数のPreToolUseフックが異なる判定を返した場合、公式仕様では「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つを事前に固めておくことが、安全な自動化の前提条件になります。裏を返せば、対話モードでは多少ゆるく運用していた権限設定も、ヘッドレスモードに載せる際には見直しが必要になるということです。

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

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

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

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

はてなベースの記事によると、2026年9月時点でのClaudeの現行ラインナップは、Claude 5世代の3モデル（Fable 5・Opus 5・Sonnet 5）と、高速モデルのHaiku 4.5を合わせた4モデルです。2026年6月から7月にかけてFable 5（6月9日）、Sonnet 5（6月30日）、Opus 5（7月24日）が相次いで提供開始され、2026年9月1日にはFableがFable 5.1へ更新されています。

それぞれの立ち位置は、おおむね次のように整理できます。

Opus 5：最も複雑な推論・エージェントタスクを担う最上位モデルです。コストは高めですが、難易度の高い設計判断や長期タスクの遂行力が求められる場面に向いています。
Sonnet 5：中位価格帯でありながらエージェント性能に優れたバランス型モデルです。
Fable 5.1：Fableシリーズの最新版で、9月1日にアップデートされました。
Haiku 4.5：高速・低コストなモデルで、軽量タスクや大量処理に適しています。

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

モデル選択で特に実務上のインパクトが大きいのが、Sonnet 5の位置づけです。WEELの解説によると、Claude Sonnet 5はAnthropicが2026年7月1日に公開した、Sonnet史上最もエージェント性能に優れた中位価格帯モデルであり、エージェントコーディング性能で63.2%を記録しています。これは上位モデルOpus 5の69.2%に迫るスコアをSonnet価格帯で実現したものです。

料金面でも、NTTドコモビジネスの整理によると、Sonnet 5の標準の利用単価は100万トークンあたり入力2ドル／出力10ドルで、上位のOpusクラス（同5ドル／25ドル）のおよそ4割にとどまります。日常的なコーディングタスクや、CLAUDE.mdに沿った反復的な実装作業であれば、Sonnet 5を基準モデルとし、設計判断が難しい局面や大規模な計画立案が必要なときだけOpus 5に切り替える、という運用がコストと精度のバランスを取りやすい選択になります。

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

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

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

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

まとめ

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