第1回では、コンテキストは毎ターン送り直されること、公式の失敗パターンの1つに「終わらない探索」（範囲を決めずに調べさせ、コンテキストを使い切る）があることを見ました。走らせてから直すより、走らせる前に範囲を決めるほうが、ずっと安く済みます。

第2回では、Code タブでのプランモードの使い方、計画を省いてよい作業と要る作業の見分け方、計画を「実際に読む」ときの3つの見どころ、そして範囲を決めるプロンプトの4つのコツを扱います。数値・仕様は2026年10月時点です。

Codeタブでのプランモード

プランモードでは、Claude は読み取りだけで調べ、変更案（計画）を出します。ファイルは何も変更しません。

• 切り替え方：入力欄の下のモード表示をクリックして、メニューから選びます。メニューが開いているときは数字キーでも項目を選べます。キーボードなら Ctrl＋Shift＋M（Mac は Cmd＋Shift＋M）でモードのメニューが開きます
• CLI との違い：CLI の Shift＋Tab は、Code タブでは使えません。公式の文書は「Desktop では、Shift＋Tab はターミナルの対話モードのようには権限モードを切り替えない」と書いています
• 記憶される範囲：メニューで選んだモードはフォルダーごとに記憶されます。ただし 「プラン」だけは、そのセッション限りです。メニューで選んだモードは、そのフォルダーでは設定の既定（permissions.defaultMode）より優先されます
• 公式の勧め：複雑な作業は「プラン」で始め、計画を承認したら「編集を受け入れる」か「手動」に切り替えて実行します

日本語の画面でのモードの表示名は、「自動」「手動」「編集を受け入れる」「プラン」です。「権限をバイパス」は、Pro・Max では、設定（Settings → Claude Code）の「Allow bypass permissions mode」を有効にしたときだけメニューに出ます。入力欄の下には、モード・モデル・Effort が並んで表示されます。モードの詳しい違いは、第5回の「6つの権限モード」で扱います。

CLI では：Shift＋Tab で権限モードを切り替えます。auto から始まったセッションで最初に押すと default になり、その後は default → acceptEdits → plan の順に回ります（プランの後に、有効にしたモードが続きます）。プランモードで起動するには claude --permission-mode plan です。計画が出ると、承認の選択肢（Yes, and use auto mode／Yes, manually approve edits／No, keep planning）が出ます。Code タブの承認の画面の選択肢は、筆者は確かめていません。

連載「Claude活用入門」第5回「探索→計画→実装→検証→コミット」では、プランモードを「Shift＋Tab で切り替え」と紹介しました。これは CLI の操作で、Code タブでは上の方法を使います。

既定のモードについて：CLI と VS Code の拡張機能では、v2.1.283 以降は auto mode から始まります（活用入門 第5回「権限と auto mode」）。デスクトップアプリだけの組み込みの既定の値は、公式の文書には書かれていません。デスクトップアプリは CLI と同じ設定ファイルを読み、permissions.defaultMode を新しいローカルのセッションに適用します。筆者の個人のアカウントの Code タブでは、新しいセッションは「自動」から始まりました（2026年10月4日の記録。第5回の「Code タブでの権限の操作」）。

出典は https://code.claude.com/docs/en/desktop と https://code.claude.com/docs/en/permission-modes です。

計画を省いてよい作業・要る作業

プランモードには手間がかかるので、すべての作業に使う必要はありません。

公式のベストプラクティスの基準は、「差分を1文で説明できるなら、計画は省く」です。計画がいちばん役に立つのは、方法に確信が持てないとき、変更が複数のファイルにまたがるとき、変更するコードに慣れていないときです（https://code.claude.com/docs/en/best-practices ）。

インタビューは、公式の文書の「Let Claude interview you」の節の使い方です。大きな機能では、最小限のプロンプトで始め、AskUserQuestion ツールを使って自分にインタビューするよう頼みます。公式の例の文は「I want to build [brief description]. Interview me in detail using the AskUserQuestion tool.」です。

冒頭の2つ目の相談がこれです。計画が要るかどうかは、差分を1文で説明できるかで決めます。

計画は「実際に読む」

プランモードの価値は、計画を人が読んで直せることにあります。Claude Academy のレッスン「長時間セッションの操縦」（Steering long sessions）は、計画にざっと目を通すのではなく、実際に読むよう勧めています。計画が綿密であるほど、実行が始まってから驚くことが減ります。

読むときは、変更するファイルの一覧、変更の順番、確かめ方の3つを見ます。

• 計画にないファイルを変えようとしていないか
• 本番の環境に触れる手順が入っていないか
• 最後にどう検証するかが書かれているか

ずれや抜けがあれば、「手順3の前に、現在の設定のバックアップを取る手順を足して」のように、計画に足すよう頼みます。計画を直すほうが、走らせてから後片付けするよりずっと速く済みます。

• 計画は流し読みせず、変更するファイル・順番・確かめ方を読む
• 計画にない変更、本番に触れる手順、検証の欠けを探す
• 計画を直すほうが、走らせてから片付けるより速い

CLI では、計画を Ctrl＋G で既定のテキストエディターに開き、直接直してから進められます（活用入門 第5回「探索→計画→実装→検証→コミット」）。Code タブで使えるかは、確認できていません。

筆者が試したら：練習用のリポジトリ（NTP の chrony の参照先を設定する playbook）で、プランモードに「NTPの参照先を3台にしてください」と頼みました。ファイルは何も変わらず、計画が出ました。その計画には、頼んでいない「リストに無い server 行を削除する」タスクが入っていました。本番で既存の行を消すのは別の変更として扱うべきなので、外させました。参照先が2台のときも同じで、2回とも、頼んでいない削除が計画に入りました。計画を読まずに走らせていたら、実装の後で気づくことになります。

プロンプトの4つのコツ

作業範囲は、プロンプトでも決められます。公式のベストプラクティス（Provide specific context in your prompts）の4つのコツを、NTP の例で見ます。

• 参照先を3台にするのは、連載「NTP入門」第3回「何台の時刻源を使うか」で見たように、2台は食い違ったときに決められず、1台と大差ないためです
• chronyc tracking の Leap status の見方は、連載「NTP入門」第4回「chronyc trackingの読み方」にあります

出典は https://code.claude.com/docs/en/best-practices#provide-specific-context-in-your-prompts です。

渡し方の補足です。

• ファイルは @ で指定できます（@ に続けてファイル名。場所を説明する代わりに、Claude が読んでから答えます）。Code タブでは、@ の指定は Local と SSH のセッションで使えます（クラウドと WSL のセッションでは使えません）
• 画像や PDF は、添付ボタンかドラッグ＆ドロップで渡せます（Code タブ）。公式のベストプラクティスは画像の貼り付けを一般の操作として書いていますが、Desktop の機能の比較表では、CLI の「File attachments」は「Not available」とされています。CLI で使うときは、お使いの版で試してください
• URL も渡せます。ベストプラクティスは、よく使うドメインを /permissions で許可するよう書いています。ただし、Code タブでは /permissions のような引数なしのコマンドは「isn’t available in this environment」と返ります。権限の設定は、第5回の「Code タブでの権限の操作」と第6回の「allow・ask・denyルールの書き方」で扱います
• 「必要な情報は自分で取りに行って」と頼むこともできます

考えてみよう

1. 最近 Claude Code に頼んだ作業のうち、差分を1文で説明できたのはどれですか。計画を省いてよかった作業と、計画が要った作業を分けてみてください。
2. 計画を読むとき、あなたの環境で「本番に触れる手順」に当たるのは何ですか。（例：サーバーの設定ファイルの書き換え、サービスの再起動）
3. 「NTPの設定を直して」のような頼み方を、4つのコツ（範囲・情報源・既存のやり方・「直った」の定義）で書き直すと、どうなりますか。

ヒント：「計画を省いてよい作業・要る作業」「計画は『実際に読む』」の節を見直してください。

まとめ

• プランモードでは、Claude は読み取りだけで計画を出し、ファイルを変更しない。Code タブでは、メニューか Ctrl＋Shift＋M（Mac は Cmd＋Shift＋M）で切り替える。CLI の Shift＋Tab は Code タブでは使えない
• 選んだモードはフォルダーごとに記憶されるが、「プラン」だけはそのセッション限り
• 差分を1文で説明できるなら、計画は省く。範囲がはっきりしない・複数のファイル・慣れていない領域は計画が要る。要件があいまいなら、インタビューを頼む
• 計画は実際に読む。変更するファイル、本番に触れる手順、検証の手順を見て、足りなければ計画に足させる。計画を直すほうが、走らせてから片付けるより速い
• プロンプトは、範囲・情報源・既存のやり方・「直った」の定義の4つを書く

演習の手順2で、プランモードの計画を読んで直す体験を試せます（第8回）。

次回は、走らせながら操縦することを扱います。途中で止める、戻す、向きを直す方法です。

連載「Claude Code実践入門」全9回

1. 任せる前に知っておくこと
2. 作業範囲を決める（この記事）
3. 走らせながら操縦する
4. CLAUDE.mdを育てる
5. 権限モードとauto mode
6. allow・ask・denyのルールと設定ファイル
7. 検証で終わらせる
8. 演習（前編）：準備から実装と検証まで
9. 演習（後編）：巻き戻し・差分・権限と振り返り

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 の文書の説明の要旨）。

（段階は 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つの間違いが挙げられています。

出典は 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万トークンを超えると、単価が高くなります。

• 超えると、すべての単価が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

考えてみよう

1. いま使っている Claude Code のセッションで /context を開くと、コンテキストの何が場所を取っていますか。CLAUDE.md、読んだファイル、コマンドの結果のうち、減らせるものはありますか。
2. 最近「何度直しても直らない」作業はありましたか。そのとき /clear してやり直しましたか。やり直すなら、最初のプロンプトに何を足しますか。
3. 任せきりにした作業の後、見ていなかった分を、何で確かめましたか。差分、テストの結果、別の目のレビューのうち、足りなかったのはどれですか。

ヒント：「よくある失敗パターン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回

1. 任せる前に知っておくこと（この記事）
2. 作業範囲を決める
3. 走らせながら操縦する
4. CLAUDE.mdを育てる
5. 権限モードとauto mode
6. allow・ask・denyのルールと設定ファイル
7. 検証で終わらせる
8. 演習（前編）：準備から実装と検証まで
9. 演習（後編）：巻き戻し・差分・権限と振り返り