「Claude Code に作業を任せているうちに、最初に伝えたルールを守らなくなってきました。会話を続けるべきか、新しく始めるべきか分かりません」
「使用量の枠がすぐなくなります。同じ作業なのに、日によって減り方が違うのはなぜですか」
Claude Code は、ファイルを読み書きし、コマンドを実行して、何段階もの作業を任せられる道具です。ただし、任せる範囲を広げるほど、うまくいかなかったときの原因が見えにくくなります。その手前で押さえておきたいのが、Claude が作業に使える情報（コンテキスト）の仕組みと、「見ていなかった分だけ検証が要る」という考え方です。
この連載「Claude Code実践入門」は、連載「Claude活用入門」（全6回）の続編です。活用入門では、Claude 全体の使い方と、Claude Code のベストプラクティスを一通り見ました。この連載では、その中から日々の作業に効く5つを掘り下げ、最後に練習用のリポジトリで手を動かします。
第1回では、連載全体の案内、活用入門のおさらい、公式のモデルと Effort の選び方、コンテキストが毎ターン送り直される仕組み、公式の「よくある失敗パターン」5つ、検証の考え方、使用量の確認を扱います。
この連載の案内
この連載で掘り下げる5つと、最後の演習は次のとおりです。
- 作業範囲を決める（第2回）：走らせる前に、プランモードで計画を出させて読み、直す
- 走らせながら操縦する（第3回）：途中で止める・戻す・向きを直す
- CLAUDE.md を育てる（第4回）：毎回の前提を、短く保って渡す
- 権限で任せる範囲を決める（第5回・第6回）：権限モードと auto mode、allow・ask・deny のルールと設定ファイル
- 検証で終わらせる（第7回）：「できました」ではなく、証拠で終わらせる
- 演習（第8回・第9回。前編と後編）：練習用のリポジトリで、ここまでを一通り試す
前提と、この連載の扱いは次のとおりです。
- 個人の Pro・Max のプランを前提にします。組織（Team・Enterprise）の話は、補足として添えるだけにします
- 操作は Claude のデスクトップアプリの Code タブ（Claude Code for Desktop）を主に書きます。ターミナルで使う CLI の操作は「CLI では」と添えるので、読み替えられます
- 数値・仕様は 2026年10月時点のものです。公式の文書は変わりやすいので、使うときは公式で確かめてください
- 手元で確かめた版は、CLI が Claude Code 2.1.289（2026年10月18日）、Code タブが 2.1.284（2026年10月4日の記録）です
- この連載は、筆者が公式の文書（code.claude.com、Claude Academy）を読んで整理したもので、Anthropic の公式の文書ではありません。公式の推奨と、筆者の使い方の例は、分けて書きます
連載「Claude活用入門」のおさらい
活用入門の要点を5つだけ振り返ります。くわしくは各回を見てください。
- 使い分け：公式は「コードを書いて動かすなら Code、それ以外の成果物づくりは Cowork」としています（活用入門 第2回「公式が勧める使い分け」）。筆者の例では、成果物を作る作業は Code タブを標準にし、Chat は短い質問と壁打ち、Cowork は例外にしています（同「筆者の例：インフラの作業を Code に寄せる」）
- ModelとEffort：公式の推奨に沿って、次の節で整理し直します（活用入門 第3回「公式のモデルの選び方」「作業別の設定の例（筆者の例）」）
- プロンプト：Claude は「優秀だが、事情を知らない新入社員」と考え、目的・背景・理由を書く（活用入門 第4回「明確に、背景と理由を添える」）
- Claude Code：探索→計画→実装→検証。検証手段を渡す。CLAUDE.md は短く、コンテキストはこまめにリセットする（活用入門 第5回「探索→計画→実装→検証→コミット」「検証手段を渡す」「CLAUDE.md」「コンテキストの管理」）
- この連載：活用入門 第5回（Claude Code のベストプラクティス）で一覧にした使い方のうち、日々の作業に効く5つを掘り下げ、最後に自分の環境で試す演習を付ける
モデルとEffortの選び方（公式の推奨）
最初に迷う「どのモデルで、どの Effort で始めるか」を、2026年10月時点の公式の記述で整理します。
- Claude Code の既定のモデルは、Pro・Max・Team・Enterprise・Anthropic API のいずれも Opus 5.5 です。v2.1.280 より前は、Pro と Team Standard の既定は Sonnet 5、Max などは Opus 5 でした
- 既定の Effort は、Opus 5.5・Sonnet 5.5・Haiku 5.5 では medium です（ほかのモデルは high が多く、Opus 4.7 は xhigh）
- モデル選びのガイドは、「Most workloads start with Claude Opus 5.5.」（多くの作業は Opus 5.5 から始める）としています。始め方は2通りです
- 効率優先：Haiku 5.5 のような速く安いモデルから始め、足りなければ上げる
- 能力優先：作業に合う最も強いところから始め、あとで効率のよいモデルへ移す
- 同じガイドは「Tuning effort is often a better lever than switching models.」（Effort の調整は、モデルを替えるより効くことが多い）とも書いています
- 公式ブログ「Choosing a Claude model and effort level in Claude Code」（2026年7月7日。当時のモデルを例にした記事）は、ほとんどの作業で既定の Effort を使うことを勧め、必要な文脈を渡して明らかに試したのに間違えたなら、より大きなモデルを選ぶ合図としています
公式の Effort の目安は次のとおりです（Claude Code の文書の説明の要旨）。
| Effort | 向く作業 |
|---|---|
| low | 結果を毎回見直す短いやりとり。ブレインストーミング、最初の下書き、名前の変更のような小さな変更 |
| medium | Opus 5.5・Sonnet 5.5・Haiku 5.5 の既定。Opus 5.5 と Sonnet 5.5 では、新機能の実装のような、範囲がはっきりした日々のエンジニアリングの作業に合う |
| high | 検証が大事な作業や、境界の場合が出やすい作業（既存のコードのバグ修正など）。Opus 5.5・Sonnet 5.5・Haiku 5.5・Opus 4.7 以外のモデルの既定 |
| max | 任せきりで解かせたい難しい問題（セキュリティ上の脆弱性の探索など）。収穫が減りやすく、考えすぎやすいので、広く使う前に試す |
（段階は xhigh を含めて全部で5つです。全体は活用入門 第3回「Effort とは」を見てください）
この連載では、次の進め方にします。
- 公式の既定（Opus 5.5・Effort medium）のまま始める
- うまくいかなければ、まず Effort を上げる（たとえば high）。モデルを替えるより、Effort の調整が効くことが多い
- Haiku 5.5 のような軽いモデルは、公式の説明では速く効率的で、単純な作業に向くモデルです。Claude Code の
haikuというエイリアスが Haiku 5.5 を指すのは Anthropic API 上の記述で、公式の文書は、Claude Code では v2.1.293 以降で使うよう書いています。Pro・Max の Claude Code のモデルのメニューに Haiku 5.5 が出るかは、公式の文書では確かめられていません（筆者の CLI は 2.1.289 でした）
筆者が Pro で使うときの設定の例（Sonnet 5.5 を既定にして、作業に合わせて上げる）は、活用入門 第3回「作業別の設定の例（筆者の例）」にあります。これは筆者の例で、公式の推奨ではありません。この連載の演習では、手動・既定のモデル（Opus 5.5）・Effort medium で試します。
あわせて読みたい公式の教材
Claude Academy（academy.claude.com）には、この連載に近い無料の公開コースがあります（進み具合を保存するにはサインインが要ります）。
- Claude Code in action（日本語版は「Claude Codeを実践する」。9レッスン・約1時間）：https://academy.claude.com/ja/courses/claude-code-in-action
- この連載に合うレッスン（講座の1〜5番目と8番目）：Steering long sessions（長時間セッションの操縦）、A CLAUDE.md that follows（Claudeが従うCLAUDE.md）、Verification skills（検証スキル）、Permission modes（権限モード）、Hooks、Trust it: Verifying unsupervised runs（信頼する：監視なしの実行を検証する）
- Claude Code 101：https://academy.claude.com/ja/courses/claude-code-101
- Claude Code をまだ使っていない人は、「Daily workflows（日々のワークフロー）」の3レッスン（The explore → plan → code → commit workflow、Context management、Code review）を先に読んでください
レッスンの題は英語版のページで、括弧の中の日本語の題は日本語版のページで確かめました（2026年10月17日）。Claude Code 101 のレッスンの日本語の題は、確かめていません。
コンテキストは毎ターン送り直される
Claude が作業に使えるのは、学習で得た知識と、いまのコンテキストの中身だけです。コンテキストには、私たちが書いたプロンプトのほかに、システムプロンプト、CLAUDE.md、読んだファイル、コマンドの実行結果が入ります。公式の文書も、リクエストの中身はすべてコンテキストウィンドウに数えられる、と書いています。
そして、メッセージを送るたびに、それまでの会話全体が送り直されます。そのため、長い会話の最後の短い質問は、新しい会話で同じ質問をするより高くつくことがあります。
公式のベストプラクティスは、「コンテキストウィンドウはすぐに埋まり、埋まるほど性能が落ちる」ことを、すべての前提にしています。
大きさと自動コンパクトは、次のとおりです（2026年10月時点）。
- 大きさ：サポートの記事（有料プランでのコンテキストウィンドウの大きさ）の取得版では、Claude Code の節に Opus 5.5・Sonnet 5.5・Haiku 5.5 の3つが 100万トークンとあります。Claude Code の文書も、Sonnet 5 以降・Haiku 5.5・Opus 4.7 以降は、既定で 1M のウィンドウで動く、と書いています。この大きさはモデルと記事の版で違うので、自分のプランは公式のサポートの記事で確かめてください
- 自動コンパクト：100万トークンのウィンドウを持つモデルは、ウィンドウがいっぱいになる前に、既定で 約96万7千トークンに達したところで会話の要約（コンパクト）を始めます。要約の始まる量は、100K〜1M の範囲で変えられます（環境変数
CLAUDE_CODE_AUTO_COMPACT_WINDOW） - 大きいからといって詰め込んでよいわけではありません。作業ごとに区切ることが、品質とコストの両方に効きます
要点は次の3つです。
- コンテキスト＝システムプロンプト＋CLAUDE.md＋会話＋読んだファイル＋コマンドの結果
- 毎ターン、会話全体が送り直される。長い会話ほど1回の質問が高くつく
- 公式の前提：コンテキストは埋まるほど性能が落ちる。作業ごとに区切る
何が場所を取っているかは /context で見られます。公式の文書は、会話が長くなったら /context で何がウィンドウを埋めているかを見て、/compact で要約して空きを作る、と書いています。筆者が練習用のリポジトリで試したときは、/context の「Memory files」の欄に CLAUDE.md が 290 トークンと出て、全体は 26k / 1m（3%）でした（CLI 2.1.289）。
冒頭の1つ目の相談がこれです。最初に伝えたルールを守らなくなるのは、コンテキストが埋まって、大事な指示が埋もれてくるためです。
よくある失敗パターン5つ
公式のベストプラクティスには、「Avoid common failure patterns（よくある失敗パターンを避ける）」という節があり、早く気づけば時間を節約できる5つの間違いが挙げられています。
| 失敗パターン（公式） | どうなるか | 対策 |
|---|---|---|
| 何でも詰め込んだセッション（The kitchen sink session） | 関係ない話題が混ざり、コンテキストが汚れる | 作業が変わるときは /clear |
| 何度も直す（Correcting over and over） | 失敗した試みが残り、どんどん悪くなる | 2回直してだめなら /clear し、分かったことを入れてやり直す |
| 書きすぎたCLAUDE.md（The over-specified CLAUDE.md） | 大事な指示が埋もれて無視される | 容赦なく削る。指示しなくてもできることは消すか、フックにする |
| 信じてから確かめる、の穴（The trust-then-verify gap） | もっともらしいが動かないもの（境界の場合を扱わない実装）ができる | 検証手段（テスト、スクリプト、スクリーンショット）を必ず渡す。検証できないものは出さない |
| 終わらない探索（The infinite exploration） | 範囲を決めずに調べさせ、何百ものファイルを読んでコンテキストを使い切る | 調べる範囲を絞るか、サブエージェントに調べさせる |
出典は https://code.claude.com/docs/en/best-practices#avoid-common-failure-patterns です。この5つへの対策が、第2回から第7回の中身になっています（「終わらない探索」は第2回の「プロンプトの4つのコツ」、「何度も直す」「何でも詰め込んだセッション」は第3回の「早めに止めて直す」、「書きすぎたCLAUDE.md」は第4回の「CLAUDE.mdは「設定」ではなく「指示」」、「信じてから確かめる、の穴」は第7回の「検証を強制する4段階」）。
修正の回数について：公式のベストプラクティスには、「2回直してだめなら（After two failed corrections）/clear する」という書き方と、別の節に「同じ問題で2回を超えて直したら（more than twice）/clear して、分かったことを入れた具体的なプロンプトでやり直す」という書き方の両方があります。この連載では、目安を「2回直してだめなら /clear」とします。
見ていなかった分だけ検証する
Claude Academy のレッスン「信頼する：監視なしの実行を検証する」（Trust it: Verifying unsupervised runs）は、検証の考え方を「見ていなかった分だけ、検証する必要がある」とまとめています。
メッセージが流れるのを見ながら進めた短い作業なら、さっと目を通すだけで十分です。しかし、任せきりにして席を外した作業では、何が起きたかを誰も見ていません。そのため、終わった後に差分やテストの結果から作業を再現して確かめる必要があります。Claude に任せる範囲を広げるほど、最後の確認を本格的にしなければなりません。
この連載は、この考え方に沿って、範囲を決める→操縦する→指示を育てる→権限で絞る→証拠で終わらせる、の順に組み立てています（図の下の流れ）。
- 見ながら進めた作業は軽く確認、任せきりにした作業は本格的に確認する
- 任せる範囲を広げるほど、最後の検証を厚くする
筆者が試したら：練習用のリポジトリで、NTP の参照先を3台にする変更を実装させ、ansible-lint と stg への --check --diff まで頼みました。Claude は報告の最初の段落で「stg への --check --diff は接続できず、実際の差分はまだ確認できていない」「lint も1件で不合格」と書いてきました（stg のアドレスは練習用で、届かない設定でした）。確かめられていない分を分けて書いたので、人が見るべき所が分かりました。手順は第8回の演習の手順3で扱います。
使用量の確認とコスト
使用量の確認のしかたと、コストの考え方を整理します。個人の Pro・Max では、使用量は金額ではなく、5時間ごと・週ごとの枠で数えられます（活用入門 第1回「使用量の上限」、第3回「使用量の上限と費用の考え方」）。
- 確認のしかた：Code タブでは、モデル選択の横の使用量リングをクリックすると、いまのコンテキストの使用量と、その期間の使用量（プランの枠）が分かります。コンテキストの使用量はセッションごと、プランの使用量は Claude Code のすべての画面（Code タブ・CLI など）で共有されます。内訳は
/usage（/costは同じもの）、コンテキストの中身は/contextです。CLI では、ステータスラインを設定すると使用量を表示し続けられます /usageの見方：「Session」の欄は API 利用者向けで、Pro・Max では使用量が購読に含まれるので、その金額は請求の目安になりません。プランの使用量のバー、アクティビティ、内訳が同じ画面に出ます/clearは無料：新しい会話を始めるだけなので、コストはかかりません/compactは大きなリクエスト：会話全体を読んで要約するので、要約そのものに使用量がかかります。長くなってからまとめるより、作業ごとに/clearするほうが安く済みます- 長いセッションで使用量が増える理由：毎回、全履歴を送ります。キャッシュの有効期限が切れると、読み直しになります。キャッシュの有効期限は、サブスクリプションの枠の中では本体の会話が1時間で、枠を超えて usage credits を使うと5分に縮みます（API キーやクラウド経由では既定で5分）。サブエージェントのような本体の会話の外の要求は、サブスクリプションでも既定で5分です。サブエージェントやコンパクトも使用量に数えられます
- 枠との関係：作業ごとに
/clearで区切ることが、使える回数を増やすいちばん手軽な方法です
出典は、https://code.claude.com/docs/en/costs 、https://code.claude.com/docs/en/commands 、https://code.claude.com/docs/en/desktop 、https://code.claude.com/docs/en/model-config 、https://platform.claude.com/docs/en/about-claude/pricing です。
API の従量課金で使う場合（補足）：Pro・Max は単価ではなく枠で数えますが、API の従量課金で Claude Code を使う場合は、モデルの単価が効きます。2026年10月時点で、Haiku 5.5 は1回のリクエストの入力が 10万トークンを超えると、単価が高くなります。
| Haiku 5.5 の単価（100万トークンあたり） | 通常 | 5分のキャッシュ書き込み | 1時間のキャッシュ書き込み | キャッシュの読み出し | 出力 |
|---|---|---|---|---|---|
| 10万トークン以下のプロンプト | $0.10 | $0.125 | $0.20 | $0.01 | $0.50 |
| 10万トークンを超えるプロンプト | $0.50 | $0.625 | $1 | $0.05 | $2.50 |
- 超えると、すべての単価が5倍になります。超えた分だけではなく、そのリクエスト全体が高い単価になります
- プロンプトの長さには、キャッシュの読み書きも数えます。一部がキャッシュに当たっていても、超えたリクエストは高い単価です
- 長い会話で Haiku 5.5 を使うと、作業ごとの
/clearがなおさら効きます - API の既定の Effort は、Opus 5.5 が medium、Sonnet 5.5 が high、Haiku 5.5 が medium です（Claude Code では、Opus 5.5・Sonnet 5.5・Haiku 5.5 のどれも medium）。出典：https://platform.claude.com/docs/en/models/overview
考えてみよう
- いま使っている Claude Code のセッションで
/contextを開くと、コンテキストの何が場所を取っていますか。CLAUDE.md、読んだファイル、コマンドの結果のうち、減らせるものはありますか。 - 最近「何度直しても直らない」作業はありましたか。そのとき
/clearしてやり直しましたか。やり直すなら、最初のプロンプトに何を足しますか。 - 任せきりにした作業の後、見ていなかった分を、何で確かめましたか。差分、テストの結果、別の目のレビューのうち、足りなかったのはどれですか。
ヒント：「よくある失敗パターン5つ」「見ていなかった分だけ検証する」の節を見直してください。
まとめ
- モデルは公式の既定（Opus 5.5・Effort medium）のまま始め、足りなければ Effort を上げる。モデルを替えるより、Effort の調整が効くことが多い
- コンテキストは毎ターン、会話全体が送り直される。埋まるほど性能が落ちるので、作業ごとに
/clearで区切る - 公式の失敗パターン5つ（詰め込み・何度も直す・書きすぎた CLAUDE.md・信じてから確かめる穴・終わらない探索）への対策が、第2回から第7回
- 見ていなかった分だけ検証する。任せる範囲を広げるほど、最後の検証を厚くする
- 使用量は Code タブの使用量リングと
/usage、中身は/contextで確かめる。/clearは無料、/compactは大きなリクエスト
演習の手順1で /context を、手順3で「見ていなかった分」の証拠を見る体験を試せます（どちらも第8回）。
次回は、作業範囲を決めることを扱います。Code タブでのプランモードと、計画を「実際に読む」コツです。
連載「Claude Code実践入門」全9回
- 任せる前に知っておくこと（この記事）
- 作業範囲を決める
- 走らせながら操縦する
- CLAUDE.mdを育てる
- 権限モードとauto mode
- allow・ask・denyのルールと設定ファイル
- 検証で終わらせる
- 演習（前編）：準備から実装と検証まで
- 演習（後編）：巻き戻し・差分・権限と振り返り
コメント