Claude Codeの使い方のコツ｜2日目からの毎日の回し方【2026年10月】

Claude Codeの使い方のコツは、①自分で確かめる方法を依頼に含める ②大きな変更は先に計画を出させる ③承認は差分を読んでから ④別の作業になったら会話を区切る ⑤同じ指摘を2回したらCLAUDE.mdに書くの5つです。入れ方やログインは済んでいる前提で、2日目から毎日の作業をどう回すかを説明します。

この記事は、Claude Codeを入れて最初の依頼まで済ませた人が、毎日の仕事でうまく回すための記事です。入れ方・ログイン・最初の1回の流れは Claude Codeの始め方 にまとめているので、まだの方は先にそちらをご覧ください。ここでは、指示の出し方、検証の渡し方、承認の判断、会話の続け方、やり直し、Git、CLAUDE.mdの育て方を、公式ドキュメント「ベストプラクティス」（2026年10月21日確認）の内容に沿って整理します。画面は2026年10月14日に、この記事の執筆用の端末（Linux・Claude Code v2.1.299）で実際に操作して撮ったものです。

念のため整理すると、Claude Codeは、パソコンの中のフォルダを作業場にして、ファイルを読み、書き換え、コマンドを実行してくれるAIの道具です。チャットで答えをもらうだけでなく、作業そのものを進めるので、頼み方と確認のしかたが結果を大きく左右します。仕組みや「とは」は Claude Codeとは で解説しています。

先に結論だけ：Claude Codeの出来は「何を頼んだか」と「どう確かめさせたか」でほぼ決まります。公式が最初に挙げているのも、モデルの性能の話ではなく、会話のウィンドウ（Claudeが一度に覚えていられる量）がすぐにいっぱいになり、いっぱいになるほど性能が落ちるという制約です。コツの多くは、この制約に合わせた使い方です。

まだ入れていない人へ：導入の要点

入れ方は、公式のインストーラーを1行実行するだけです（Mac・Linux・WSLは curl -fsSL https://claude.ai/install.sh | bash、Windowsは irm https://claude.ai/install.ps1 | iex）。入れたら、作業するフォルダで claude と打ってログインします。プランで使うなら1番目の選択肢です。うまくいかないときの手順は 始め方 と インストール方法 にあります。

関連記事Claude Codeの便利コマンドは？ ／ Claude Codeで巻き戻すには？

毎日の回し方：1回の作業サイクル

1つの作業は、次の6つの手順で回します。小さな修正なら「頼む→確認→承認」だけで済み、大きな変更ほど前後の手順が効いてきます。

順	手順	やること	使うもの
1	探索	関係するファイルを読ませて、今どうなっているかを説明させる（変更はさせない）	質問、@ファイル名、Plan Mode
2	計画	変更するファイルと進め方を出させ、読んで合意する	Plan Mode（Shift+Tab）
3	依頼	目的・対象・完成条件を書いて頼む。確かめ方も書く	指示の書き方（次の節）
4	承認	コマンドと差分を読んでから、Yesを選ぶ	権限モード、/permissions
5	検証	テストやビルドの結果を、画面の出力で自分の目でも確かめる	テスト、!git diff
6	区切る	コミットして、別の作業なら会話をリセットする	/clear、/compact

この記事は、この順に沿って「どこで何に気をつけるか」を説明します。

指示の出し方のコツ：目的・対象・完成条件をそろえる

公式は「指示が正確なほど、必要な修正が減る」としています。Claudeは意図を推測できても、心は読めません。次の3つがそろっていれば、手戻りがぐっと減ります。

• 目的：何のための変更か（例：ログイン後に画面が固まる不具合をなくしたい）
• 対象：どのファイル・どの場面か（例：src/auth/ のトークン更新）
• 完成条件：どうなったら終わりか（例：失敗するテストを先に書き、直したあとで通ること）

頼み方	具体的にした例
バグを直して	ユーザーから「セッションが切れたあとにログインできない」と報告があった。src/auth/ のトークン更新を確認して、再現する失敗テストを先に書いてから直して
foo.pyのテストを書いて	ユーザーがログアウトしている場合のテストを foo.py に追加して。モックは使わないで
この機能を追加して	ホーム画面の既存のウィジェットの作り方を見て、同じやり方でカレンダーを追加して。新しいライブラリは入れないで
ビルドが失敗している	ビルドがこのエラーで失敗している：（エラーを貼る）。直して、ビルドが成功することまで確認して。エラーを隠さず、根本の原因を直して

毎日よく頼む作業の頼み方

作業	頼み方の例
エラーの原因を調べる	npm test がこのエラーで失敗する：（エラー全文を貼る）。発生するのは cart.js の合計計算を変えたあと。git diff で最近の変更を見て、原因の候補を挙げて。まだ直さないで
テストを足す	@src/utils.js の関数ごとにテストを書いて。境界の値（0・空・負数）も入れて。書いたら実行して、通るまで直して
READMEを更新する	@src の今のコードに合わせて README の使い方の章を更新して。書き換えた箇所の一覧も見せて
レビューをさせる	今の差分をレビューして。バグになりうる点だけ挙げて、好みの指摘は不要。公式の /code-review スキルも使えます
シェルコマンドを作る	ログフォルダの中の7日より古い .log を一覧にする find コマンドを作って。実行はまだしないで

どの頼み方も、「何を・どこに・どう確かめるか」を含めています。エラーの調査は、エラーの全文・発生した状況・直前の変更の3つを渡すと、原因を絞りやすくなります。

対象を指すときに使える入力

• @でファイルを指す：@src/api.ts を読んで… のように書くと、応答の前にそのファイルを読みます。場所を言葉で説明するより確実です。
• 画像を貼る：画面のスクリーンショットやデザイン案を、コピーして貼る（またはドラッグ）だけで渡せます。
• 出力をそのまま渡す：! で始めてコマンドを実行すると結果が会話に入ります。ターミナルからは cat error.log | claude -p "このエラーを説明して" のようにも渡せます。
• URLを渡す：ドキュメントやAPIリファレンスのURLを指定できます。よく使うドメインは /permissions で許可しておくと、毎回の確認が減ります。

頼み方を使い分ける場面

• コードの理解は、先輩に聞くように質問する：「ログはどう出力されている？」「新しいAPIを足すにはどこを触る？」のような質問から始められます。特別な書き方は要りません。
• 大きな機能は、先にインタビューさせる：「〇〇を作りたい。技術面・画面・例外・トレードオフを、AskUserQuestionツールで詳しく聞いて。聞き終わったら仕様を SPEC.md に書いて」と頼むと、自分が考えていなかった点を先に出せます。仕様ができたら、新しい会話で実装に進めます。
• 曖昧な指示が向くのは探索のとき：「このファイルで改善できそうな点は？」のように、方向を決めずに聞くと、思いもしなかった指摘が出ることがあります。直す段階では具体的に頼みます。

検証の方法を渡す：任せられる範囲はここで決まる

公式が最初に挙げているコツがこれです。Claudeは、作業が終わったように見えたところで止まります。実行できる確認（テスト・ビルド・画面の比較）がないと、「できたように見える」だけが手がかりになり、間違いに気づく役が自分だけになります。確認方法を渡せば、Claudeは作業→確認→結果を読む→直す、を自分で繰り返します。

場面	弱い頼み方	確認つきの頼み方
関数を作る	メールアドレスを検証する関数を作って	validateEmail を作って。user@example.com は true、invalid と user@.com は false。実装したらテストを実行して
画面を直す	ダッシュボードをよくして	（スクリーンショットを貼って）この見た目にして。作ったあとに画面を撮って、元と比べて違いを直して
不具合を直す	ビルドが失敗している	このエラーで失敗している：（貼る）。直して、ビルドが通ることを確認して。エラーを隠さないで

さらに「成功した」と言わせるのではなく、証拠を見せてもらうのも効きます。テストの出力、実行したコマンドとその結果、画面のスクリーンショットです。証拠を読むほうが、自分で確認をやり直すより速く、見ていなかった作業にも使えます。

確認の強さは用途で変えられます。1つの依頼の中で「確認して、通るまで直して」と頼むのが基本です。長い作業では /goal で完了の条件を設定して別の評価役に確認させる方法や、Stopフックでテストが通るまで終わらせない方法もあります（公式の説明：公式ドキュメント「ベストプラクティス」）。

注意したいのは、「できました」を鵜呑みにしないことです。処理が失敗しているのに「正常に終了しました」と報告されることがあります（例：HTTPの応答が404なのに完了扱い）。依頼に「まず実際のログや出力を見てから、必要ならテストを実行して」と順序を書いておくと、テストが通っただけで終わる場面が減ります。

先に計画させる：Plan Modeを使うかどうかの判断

いきなりコードを書かせると、間違った問題を解くコードができることがあります。そこで、調べる→計画する→実装する→コミットするを分けます。調べる段階と計画の段階では、Shift+Tabで Plan Mode（入力欄の下に plan mode on と出ます）に入れると、変更をせずにファイルの読み取りと質問への回答だけが行われます。起動時に claude --permission-mode plan と付ける方法もあります。

段階	頼む例	ポイント
探索	@src/auth を読んで、セッションとログインの扱いを理解して	Plan Modeで、変更せずに読ませる
計画	Google認証を足したい。変更するファイルと流れの計画を作って	Ctrl+Gで計画をエディタで開き、直接直せる
実装	計画どおりに実装して。コールバックのテストも書いて、テストを実行して	Shift+TabでPlan Modeを出てから頼む
コミット	説明のあるメッセージでコミットして、PRを作って	差分を読んでから

毎回必要なわけではありません。タイプミスの修正、ログ1行の追加、変数名の変更のように、差分を1文で説明できる作業は、計画を飛ばして直接頼みます。計画が効くのは、進め方に迷うとき、複数のファイルにまたがるとき、見慣れないコードを触るときです。使い方の詳細は Plan Modeの使い方 で解説しています。

承認の判断：何を読み、何を事前に許すか

承認は、毎回同じ強さで読み続けるのが難しい作業です。公式も、10回目の承認あたりからは、中身を読まずにクリックしているだけになりやすいと書いています。そこで、「読むもの」と「任せるもの」を分けます。

承認画面で	読むところ
コマンドの実行	何を実行するか。ファイルの削除、外部への送信、本番や共有環境に触れるものは、必ず中身を読みます
ファイルの編集	赤（削除）と緑（追加）の範囲。頼んでいないファイルや、関係のない場所の変更が混ざっていないか
MCPなどの外部ツール	どのサービスに、何を読み書きしようとしているか

もう1つ、会話に貼る内容にも気をつけます。APIキーやパスワード、お客様の個人情報が入ったファイルは、貼ったり @ で指したりする前に、本当に渡してよいかを確かめます。読ませたくないファイルは、権限ルールで拒否に登録しておけます。

読む負担を減らす方法は2つあります。1つは /permissions で、npm run lint や git commit のように安全と分かっているコマンドを事前に許可することです。もう1つは /sandbox で、OSレベルの隔離を有効にして、ファイルやネットワークの範囲を限ったうえで、その中では質問なしに動かすことです。

なお、Claude Code v2.1.283以降は、ターミナルとVS Codeで始めたときの開始モードが auto（別の分類器が裏で操作を確認し、リスクがありそうなものだけを止めるモード）です。慣れるまで1つずつ見たいときは、claude --permission-mode default で始めるか、Shift+Tabで manual に切り替えます。

権限ルールの書き方は Claude Codeの権限設定、隔離の仕組みは Claude Codeのサンドボックス、リスクの考え方は Claude Codeのセキュリティ で解説しています。

会話の続け方：/clear・/compact・/resumeの使い分け

公式が「管理する最も重要なリソース」としているのが、会話のウィンドウです。やり取り、読んだファイル、コマンドの出力がすべて入るので、1つの調査だけで数万トークンを使うこともあります。次のように使い分けます。

こういうとき	やること	狙い
別の作業に移る	/clear	前の作業の内容を持ち越さない
同じ作業で会話が長くなった	/compact	要点を残して履歴を減らす。/compact APIの変更に集中 のように指示も付けられる
ちょっとした質問をしたい	/btw	答えが会話の履歴に入らず、ウィンドウを増やさない
昨日の続きをしたい	claude --continue または --resume	会話はローカルに保存されている。/rename で名前を付けておくと探しやすい
調べものを任せたい	「サブエージェントで〇〇を調べて」	別のウィンドウで調べて要約だけが戻る

公式が挙げる失敗パターンが2つあります。1つはキッチンシンク型で、1つの作業の途中で関係のない質問をはさみ、元の作業に戻ると、ウィンドウが無関係な内容でいっぱいになっているというものです。もう1つは何度も修正する型で、同じ問題について2回以上直させても直らないときは、失敗したやり方が会話に残っています。どちらも、/clear して、分かったことを入れた具体的な指示で新しく始めるのが公式の勧めです。

自動でも、ウィンドウの上限に近づくと履歴が圧縮されます。圧縮のときに残してほしいこと（変更したファイルの一覧、テストのコマンドなど）は、CLAUDE.mdに「圧縮するときは〇〇を必ず残す」と書いておけます。コマンドの全体像は /compactと/clearの使い分け や 会話の再開 で詳しく解説しています。

使用量を食いつぶさないコツ：/usage・/model・/effort

コツを知らないまま長時間使うと、Proなどのプランの利用枠や、APIの料金を想定より早く使います。公式（コストを効果的に管理する・2026年10月21日確認）が挙げる、日々の習慣は次のとおりです。

習慣	やること
使用量を見る	/usage で今のセッションの使用状況を確認します。Pro・Max・Team・Enterpriseでは、プラン制限に対して何が使用量を占めているかの内訳と、減らすための提案も出ます。何がウィンドウを占めているかは /context で見られます
作業ごとに /clear	古い会話は、後続のすべてのメッセージでトークンを使います。関連のない作業に移るときは /clear で新しく始めます（クリアの前に /rename で名前を付けると、あとで /resume で戻れます）
モデルを合わせる	Sonnetはほとんどのコーディング作業に十分で、Opusより低コストです。複雑な設計の判断や、多段階の推論にOpusを使います。/model でセッション中に切り替えられます
考える深さを合わせる	深い推論が要らない簡単な作業は、/effort で effort のレベルを下げると、コストを減らせます
具体的に頼む	「このコードベースを改善して」のような依頼は広い範囲を読みにいきます。「auth.ts のログイン関数に入力検証を足して」のように範囲を絞ります
出力が多い作業を任せる	テストの実行やログの処理は、サブエージェントに任せると、長い出力が会話に残らず、要約だけが戻ります
使っていない外部ツールを切る	/mcp で設定済みのサーバーを見て、使っていないものを無効にします

使える枠は、使うプランで決まります（claude.com/pricing・2026年10月21日確認）。Claude Codeは有料プランすべてに含まれ、無料プランには含まれません。

プラン	料金	使い方の目安
Pro	月20ドル（年払いなら月17ドル相当）	まず個人で毎日の作業に使う
Max	月100ドルから	毎日長時間使い、利用枠が足りなくなる人
API（従量課金）	使ったトークン量に応じて課金	自動化やスクリプト、利用枠に左右されたくない場合

長く開いたままのセッションは、1行の質問でも毎回、会話全体を送るため、思った以上に使います。「あとで続きをやる」なら、 /clear するか、新しい会話で始めるほうが安く済みます。料金プランの選び方は Claude Codeの料金、APIの従量課金の見積もりは Claude CodeのAPI料金 で解説しています。

やり直し方：止める・巻き戻す・元に戻す

公式は「間違いに気づいたらすぐ直す」ことを勧めています。素早く方向を直した方が、結果的に早く良い答えにたどり着けるためです。

状況	操作	補足
実行の途中で、違う方向に進み始めた	Esc	止めても会話の内容は残るので、指示を言い直せる
さっきの変更をなかったことにしたい	「それを元に戻して」と頼む、または Esc を2回／/rewind	会話・コード・両方・指定したメッセージ以降の要約、から選べる
ターミナルを閉じたあとでも戻したい	/rewind	チェックポイントはセッションをまたいで残る
Claudeが実行したコマンドの結果を戻したい	Git（git restore や git reset など）	チェックポイントはClaudeのファイル編集だけを記録する。Bashコマンドなどの変更は記録されない

チェックポイントはGitの代わりではありません。作業の前にコミットしておき、「危ない変更はClaudeに試させて、うまくいかなければ巻き戻す」という使い方をすると、慎重に計画するより速く進められます。詳しくは /rewindの使い方 で解説しています。

Gitと組み合わせる：毎日の小さなサイクル

Gitで管理しているフォルダで使うと、どんな変更が入っても戻せます。1日の中では、次の小さなサイクルを繰り返すと安定します。

流れは、作業の前にコミット（または作業用ブランチ）→小さく頼む（1依頼は1コミットに収まる大きさ）→!git diffで差分を読む→テストを走らせる→コミットを頼む、の繰り返しです。

幅の広いターミナルなら /diff で専用の画面も開けます（/diffの使い方）。複数の作業を並行するときは、Gitのworktreeで別々のチェックアウトを作り、別々のセッションを割り当てると、編集が衝突しません。GitHubとの連携は Claude CodeとGitHubの連携 で解説しています。

CLAUDE.mdの育て方：毎回の説明をなくす

CLAUDE.mdは、Claudeがすべての会話の最初に読むファイルです。最初に /init を実行すると、プロジェクトを調べて下書きを作ってくれます。作る前に確認が出るので、中身を読んでYesを選びます。

大事なのは、下書きのまま育てず、短く保つことです。長すぎると、重要なルールが埋もれて、Claudeが半分を無視するようになります。公式は「1行ごとに『これを消したらClaudeが間違えるか』を考えて、間違えないなら消す」としています。

書くもの	書かないもの
Claudeが推測できないBashコマンド	コードを読めば分かること
デフォルトと違うコードの決まり	言語の標準的な決まり
テストの指示と、使うテストの実行方法	詳しいAPI仕様（リンクで足りる）
ブランチの名前やPRの決まり	よく変わる情報
必須の環境変数などの環境のクセ	「きれいなコードを書く」のような当たり前のこと

たとえば、次のような短さが目安です（例はこの記事用に作ったもので、自分のプロジェクトのコマンドに置き換えて使います）。公式は、必須の内容だけにして 200行以下に収めることを目安にしています。

# コマンド
- テスト：npm test（1ファイルだけなら npm test -- cart.test.js）
- 型チェック：npm run typecheck（変更をまとめたあとに実行する）

# コードの決まり
- import/export（ES Modules）を使い、require は使わない
- 金額は整数（円）で扱い、小数にしない

# 進め方
- 変更したら、完了と言う前にテストを実行して結果を見せる
- ブランチ名は feature/内容 にする

# 圧縮するとき
- 変更したファイルの一覧と、テストのコマンドを必ず残す

育て方の手順

1. 同じ指摘を2回したら、1行足す：「毎回説明している」と気づいたことが、いちばん効くルールになります。
2. 効いているかを見る：書いたのに守られないときは、ファイルが長すぎてルールが埋もれているか、書き方が曖昧です。/context で読み込まれているかも確認できます。
3. 守られない1行だけ強調する：その行に「IMPORTANT」のような強調を付けます。たくさんの行を強調すると、どれも目立たなくなります。
4. 定期的に削る：コードのようにレビューして、要らない行を消します。チームでGitに入れているファイルは、/doctor でコードから導ける内容の削除候補を出せます。
5. 例外なく毎回実行させたいことはフックにする：CLAUDE.mdの指示は「お願い」で、フックは必ず実行される仕組みです。

置き場所（プロジェクト・個人・組織）と書き方の詳細は CLAUDE.mdの書き方 で解説しています。

毎日の作業を部品にする：Skills・Hooks・MCP・CLI

同じ頼み方を何度もしていると気づいたら、部品にします。長く使うほど効きます。

• Skills：よく頼む手順をファイルにして、/名前 で呼べるようにします。CLAUDE.mdは毎回読まれますが、Skillsは必要なときだけ読まれるので、「ときどきしか使わない手順」はこちらに置きます（Skillsの作り方）。
• Hooks：編集のたびにフォーマッタを実行する、特定のフォルダへの書き込みを止める、のような「例外なく毎回」やることを自動で実行します（Hooksの使い方）。
• MCP：Notionやデータベースなどの外部サービスにつなぎます。たとえば claude mcp add --transport http notion https://mcp.notion.com/mcp のように追加します（MCPの設定方法）。
• CLIツール：GitHubなら gh を入れておくと、Issueの作成やPRの読み取りをClaudeが自分でできます。知らないCLIも「--help で使い方を調べてから使って」と頼めば使えます。
• エディタとの組み合わせ：VS CodeやJetBrainsでは拡張機能やプラグインで、エディタの画面から同じ頼み方ができます（VS Codeでの使い方）。ほかのAIツールとの使い分けは Cursorとの比較 や 代替ツールの比較 で解説しています。

Skillsは、.claude/skills/ にフォルダを作り、SKILL.md を置くだけで作れます（公式の例）。

.claude/skills/api-conventions/SKILL.md
---
name: api-conventions
description: REST API design conventions for our services
---
# API Conventions
- Use kebab-case for URL paths
- Use camelCase for JSON properties

考える深さは /effort で変えられます。公式は、深い推論が要らない簡単な作業ではレベルを下げるとコストを減らせるとしています。

プログラミング以外の仕事でも、コツは同じです

資料の整理や文書づくりのような仕事でも、「目的・対象・完成条件」と「確かめ方」を書く点は変わりません。たとえば「@議事録.txt を読んで、決まったことと担当者を表にまとめて。元のファイルは変更しないで」「このフォルダの請求書のファイル名を『日付_取引先』に直して。直す前に、変更前後の名前の一覧を見せて」のように頼みます。職種ごとの具体例は 非エンジニアのClaude Code活用 で解説しています。

つまずきやすいパターンと直し方

症状	よくある原因	直し方
何度頼んでも、意図と違う	指示に目的・対象・完成条件のどれかが抜けている	3つをそろえて頼み直す。2回直してもダメなら /clear して指示を作り直す
途中から指示を忘れる	1つの会話にいろいろ詰めて、ウィンドウがいっぱいになった	作業ごとに /clear。長い作業は /compact
見た目はよいのに、実際は動かない	確認の方法を渡していない	テスト・ビルド・画面の比較を依頼に入れる
CLAUDE.mdに書いたのに守られない	ファイルが長すぎる、または書き方が曖昧	削る。守られない1行だけ強調する。必ず守らせたいことはフックにする
調べものを頼んだら、ほかの作業ができなくなった	範囲を決めずに「調べて」と頼み、多数のファイルを読んだ	調査の範囲を絞るか、サブエージェントに任せる

動かない・エラーが出るときの原因別の対処は Claude Codeが動かないときの対処法 で解説しています。

1日の頼み方の例

ここまでを1日の中に当てはめた、頼み方の例です。プロジェクトの名前やファイルは、自分のものに置き換えて使えます（例文は、この記事用に作ったものです）。

場面	頼む例	効いているコツ
朝：状況を思い出す	--continue で昨日の会話を再開して、「昨日どこまで進んだか、残りを3行でまとめて」	会話の再開、短い要約
調べる	「@src/cart.js の合計の計算を読んで、消費税の扱いを説明して。まだ変更しないで」	探索、Plan Mode
頼む	「消費税10%を足すように直して。テストも更新して、npm test が通るまで確認して」	完成条件、確認方法
読む	変更の差分を読む → !git diff で、頼んでいないファイルが混ざっていないか見る	承認、Gitの確認
区切る	「変更内容を要約して、メッセージを提案してコミットして」→ 次の作業の前に /clear	1コミット1作業、会話の区切り
気づいたら	同じ説明を2回したなら、その前提を1行 CLAUDE.md に足す	CLAUDE.mdの育て方

よくある質問

Q1. Claude Codeを使うコツを1つだけ挙げるなら何ですか？

Claudeが自分で実行できる確認方法（テスト・ビルド・画面の比較）を依頼に含めることです。確認方法がないと、「できたように見える」ことしか手がかりがなく、間違いを見つける役が自分だけになります。「実装したあとにテストを実行して、通るまで直して」と一文足すだけで、任せられる範囲が広がります。

Q2. 何回直してもうまくいかないときはどうしますか？

同じ問題について2回以上直させても直らないときは、/clear で会話をリセットして、そこまでで分かったことを入れた具体的な指示で新しく始めます。失敗したやり方が会話に残ったままだと、それに引きずられるためです。公式も、きれいな会話と良い指示のほうが、修正を重ねた長い会話より良い結果になりやすいとしています。

Q3. 承認を毎回求められて面倒です。どうすればよいですか？

10回目あたりから、中身を読まずに押すだけになりやすいので、確認の数を減らす設定をします。安全と分かっているコマンドは /permissions で事前に許可し、/sandbox でOSレベルの隔離を有効にして、境界の中では質問なしで動かします。それでも読むべきなのは、削除・外部への送信・本番に関わるコマンドです。

Q4. CLAUDE.mdには何を書けばよいですか？

Claudeがコードを読んでも分からないものだけを短く書きます。ビルドやテストのコマンド、デフォルトと違うコードの決まり、ブランチ名やPRの決まり、環境のクセなどです。「きれいなコードを書く」のような当たり前のことや、長い説明は書きません。1行ごとに「消したらClaudeが間違えるか」を考えて、間違えない行は削ります。

Q5. 会話が長くなると、なぜ精度が落ちるのですか？

会話には、やり取りと、読んだファイルと、コマンドの出力がすべて入っていて、ウィンドウがいっぱいになるほど以前の指示を忘れたり間違いが増えたりするためです。別の作業に移るときは /clear、同じ作業が長引くときは /compact で整理します。

Q6. 使用量（利用枠）を減らすにはどうすればよいですか？

作業ごとに /clear で会話を区切る、簡単な作業ではSonnetなどの軽いモデルを /model で選ぶ、/usage で内訳を確認する、の3つが基本です。依頼の範囲を具体的に絞ることと、出力が多い作業をサブエージェントに任せることも効きます。

Q7. 間違った変更をされたら、どう戻せばよいですか？

直後なら Esc を2回押すか /rewind で、会話やコードを前の時点に戻せます。ただし、Bashコマンドなどで行った変更は記録されないため、Gitの代わりにはなりません。作業の前にコミットしておき、戻したいときはGitで戻すのが確実です。

まとめ

Claude Codeを毎日使いこなすコツは、確かめ方を渡し、計画してから頼み、差分を読んで承認し、作業ごとに会話を区切り、同じ指摘をCLAUDE.mdに残すことです。どれも、会話のウィンドウがすぐいっぱいになるという制約と、Claudeは終わったように見えたところで止まるという性質への対処です。

まず今日の作業で、依頼に「確認の方法」を1つ足し、別の作業に移るときに /clear を使ってみてください。入れ方や最初の設定は Claude Codeの始め方、全体像・できること・料金は Claude Codeとは で確認できます。

関連記事

• Claude Codeの始め方｜初期設定と最初の一歩
• Claude Codeのベストプラクティス
• Plan Modeの使い方
• Claude Codeの権限設定
• CLAUDE.mdの書き方
• /compactと/clearの使い分け
• /rewindの使い方
• Claude Codeのコマンド完全ガイド
• 検証ループの作り方
• Claude CodeをVS Codeで使う方法