Claude Codeを3ヶ月使ってわかった、無数の遠回りを防いだ9つのベストプラクティス#

Claude Codeを3ヶ月使って、私が遭遇した最大の落とし穴は、プロンプトの書き方が悪いとか、モデルを間違えたとかではありませんでした。それは、ほとんどの人が気づきもしないことでした：コンテキストウィンドウです。

まるで部屋の中の象のような存在です。Claudeがバカになったように感じる、モデルの問題だと思う、でも実際には、ただホワイトボードがいっぱいになっただけなのです。

この記事では、私が「コンテキスト初心者」から「コンテキスト管理のプロ」になるまでの完全な経験を共有します。すべてのポイントは実戦でテスト済みです。

もしあなたがClaude Codeを使っているなら、この記事は数十時間の無駄な努力を防ぐかもしれません。

さあ、始めましょう。

まず、一つ理解すること：コンテキストウィンドウとは何か？#

Claudeの脳にはホワイトボードがあります。

あなたが送るすべてのメッセージ、Claudeが読むすべてのファイル、実行するすべてのコマンド——これらすべてがこのホワイトボードに書き込まれます。

ホワイトボードがいっぱいになると、Claudeのパフォーマンスは低下し始めます。1時間前に与えた指示を忘れます。本来ならしないはずのミスを犯します。同じことを繰り返し始めます。

だから時々「Claudeがバカになった」と感じるのです。バカになったのではなく、ただ覚えていられないだけです。

Claude Codeの開発者であるBoris Chernyはこう言っています：

> Claude Codeをうまく使うコツは、このホワイトボードを管理することです。

これを理解すれば、以下のすべての戦略が意味をなすようになります。

戦略1: Claudeにすぐにコードを書かせない#

これは、ほぼすべての初心者が踏む最初の落とし穴です。

要件を説明すると、Claudeはすぐにコードを書き始めます。15分後、あなたはClaudeがあなたが望んでいたのとは全く別の問題を解決していることに気づきます。

さらに悪いことに、その15分間のコード生成で、すでにコンテキストスペースの大部分を消費してしまっています。

正しいアプローチ：まずプランモードに切り替える。

Claude Codeにはプランモードがあり、Shift+Tabを押すと起動します。

このモードでは、Claudeはファイルを読み、考えを明確にするだけで、コードには一切触れません。

私の現在の標準的なワークフローは：

1️⃣ プランモードに切り替え、Claudeに関連ファイルを読ませ、関連性を理解させる。

2️⃣ Claudeに完全な計画を書かせる：どのファイルを変更するか？ステップの順序は？どこで問題が発生する可能性があるか？

3️⃣ 私自身が計画をレビューし、必要に応じて修正する。

4️⃣ 通常モードに戻り、計画に基づいて開発する。

5️⃣ Claudeに明確なコミットメッセージでコードをコミットさせる。

計画に10分余分にかけることで、数え切れないほどのやり直しを防げます。

Borisのチームでは、一人がClaudeを使って計画を書き、別のClaudeがシニアエンジニアとして計画をレビューするという方法さえ取っています。彼らは計画のステップを真剣に捉えています。

戦略2: サブエージェントを使って主戦場を守る#

ホワイトボードの比喩に戻りましょう。

Claudeが問題を調査するとき、多くのファイルを読みます。ログ、設定、コード——すべて読み終えた時点で、ホワイトボードは半分埋まっています。調査が終わり、コードを書き始める準備ができたときには、十分なスペースが残っていません。

サブエージェントはこの問題を完璧に解決します。

サブエージェントは、独自のコンテキストウィンドウ内で動作する独立したClaudeインスタンスです。結果を報告しますが、メインセッションのホワイトボードスペースを占有しません。

使い方は非常に簡単：調査タスクの後に「use subagents」と追加するだけです：

> 「支払いフローが失敗したトランザクションをどのように処理するか、サブエージェントを使って調査を手伝ってください。」

サブエージェントがすべてのデータを読み、あなたのメインセッションはクリーンなままです。レポートを受け取った後も、開発を続けるための十分なスペースが残っています。

これは現在、私が最も頻繁に使うトリックで、間違いありません。

Javaバックエンド開発者として、私は複雑な分散システムの問題をトラブルシューティングする必要がよくあります。以前は、1回のトラブルシューティングタスクでセッション全体が台無しになることがありました。今では、「ログを読む、ソースコードを確認する、呼び出しチェーンを分析する」といった作業はすべてサブエージェントに投げ、メインセッションでは決定を下し、コードを書くだけです。

効率の違いは歴然です。

戦略3: CLAUDE.mdはあなたの「生きたルールブック」#

もしあなたが毎日Claude Codeを使っているのに、CLAUDE.mdを真剣にメンテナンスしていないなら、多くの効率を無駄にしています。

CLAUDE.mdは、Claudeが起動するたびに読むファイルです。そこに書かれたルールに従って、Claudeはあなたと一緒に作業します。

あなたがよく繰り返すことを考えてみてください：

「CommonJSではなくESモジュールを使う」
「テストにモックを使わない」
「コード変更後に一度リンターを実行する」
「ブランチ名のフォーマットはfeature/チケット番号」

CLAUDE.mdがなければ、毎回言わなければなりません。CLAUDE.mdがあれば、一度言うだけです。

しかし、最も重要なトリックはこれです：

Claudeがミスを犯し、あなたが修正するたびに、最後にこの行を追加してください：

> 「このミスを二度と犯さないようにCLAUDE.mdを更新してください。」

Claudeはその教訓を自身のルールに書き込みます。時間が経つにつれて、CLAUDE.mdはあなた専用に最適化された「生きた文書」になります。

私のCLAUDE.mdにある一つのルールは、このようにして生まれました：Claudeが私のObsidian Vault内に.txtファイルを作り続けていることに気づきました（Obsidianは表示しません）。一度修正した後、ルールを追加しました：「Vault内では.mdファイルのみ作成する」。それ以来、そのミスは二度とありませんでした。

⚠️ ただし、一つ注意点：CLAUDE.mdは長すぎてはいけません。

500行に達すると、Claudeの注意力が散漫になり、一部のルールが無視されます。すべてのルールはこの質問に答えるべきです：もしこのルールがなくなったら、Claudeはミスを犯すか？もしそうでないなら、削除してください。

戦略4: Claudeに自己チェックの機会を与える#

ほとんどの人の使用パターンは：要件を説明する → Claudeが正しく書くことを祈る → 手動で一行ずつチェックする。

これでは、あなたが唯一の品質検査官になります。信じてください、これは疲れます。

より良いアプローチ：プロンプトに検証基準を組み込む。

例えば。メール検証関数を書きたいなら、ただ「メール検証関数を書いて」と言うのではなく、こう言ってください：

> 「メールが有効かどうかを判断する関数を書いてください。これらのケースでテストしてください：hello@gmail.comは合格、hello@は不合格、@domain.comは不合格。書いた後、テストを実行してください。」

これでClaudeは自己チェックできます；あなたはすべての行を見守る必要はありません。

視覚的なタスクでも機能します。ボタンのデザインを変更する？スクリーンショットを貼り付けて言ってください：「これをこのように見えるようにしてください。変更後、スクリーンショットを撮って、何が違うか教えてください。」

Claudeに比較基準を与えることで、唯一のフィードバックループになることを避けられます。このトリックは何時間も節約できます。

戦略5: プロンプトを技術文書のように書く#

Claudeは文脈から多くのことを推測できますが、あなたの心を読むことはできません。

対比を見てみましょう：

❌ 曖昧：「auth.pyのテストを追加して」

✅ 具体的：「auth.pyのテストを書いてください。ユーザーのセッションがリクエスト中に期限切れになるシナリオをカバーしてください。モックは使わないでください。トークンが有効に見えるが実際には期限切れになっているエッジケースに焦点を当ててください。」

同じタスクでも、結果は全く異なります。

また、Claudeにどこを見るべきかを直接指し示すこともできます。

❌ 「この関数はなぜ変な動作をするの？」

✅ 「このファイルのgit履歴を見て、この動作がいつ、なぜ追加されたか調べてください。」

違いは：Claudeが当てずっぽうで推測しているのか、それとも具体的な答えを出しているのか？

バックエンド開発者として、私のプロンプトを書く習慣は今ではこうです：入力を指定、出力を指定、制約を指定、検証方法を指定。APIドキュメントを書くように扱います。

戦略6: 30〜45分ごとにコンテキストをリセットする#

Claudeとしばらくチャットしていると、軌道から外れ始めることに気づくでしょう。

同じことを繰り返す。前に与えたルールを忘れる。回答の質が明らかに低下する。

これはコンテキスト汚染です。ホワイトボードがいっぱいで、Claudeは古いコンテンツを上書きするしかありません。

Borisのチームは、複雑なタスク中に30〜45分ごとにコンテキストをリセットします。

方法：

1️⃣ Claudeに現在の進捗を要約させる：「これまでに何をしたか、残っているタスクは何か、現在の問題は何かを要約してください。」

2️⃣ 新しいセッションを開始する。

3️⃣ 要約を貼り付けて続ける。

これにより、Claudeの思考は明確に保たれ、長時間セッションによる「脳の霧」を避けられます。

多くの人はセッションを閉じることを嫌がり、「すべてのコンテキストがそこにある」と考えます。実際には、肥大化したコンテキストは洗練された要約よりも悪いのです。

戦略7: 並列セッション + Git Worktree#

これはBorisのチームが認める生産性キラーアプリです。

複数のClaude Codeセッションを同時に開き、git worktrees（コードベースの独立した作業コピー）と組み合わせて、互いに干渉せずに作業できます。

例えば：

🅰️ セッションAは新機能の作成を担当。

🅱️ セッションBはAが書いたコードのレビューを担当。

Aの出力をBに渡し、エッジケースや欠陥を見つけさせます。そしてフィードバックをAに戻します。

一つのClaudeが書き、別のClaudeがレビューする。より高いコード品質、より速い効率。

3〜5つのセッションを同時に開き、worktreesに名前を付け、シェルエイリアス（za, zb, zc）を設定してワンクリックで切り替える人もいます。

テスト駆動開発にも同じ方法を使えます：一つのClaudeがまずテストを書き、別のClaudeがテストを通過するコードを書く。TDDですが、Claudeがすべての重労働をします。

戦略8: 繰り返し操作をスキルにカプセル化する#

もしあなたがClaude Codeで1日に2回以上同じ操作を繰り返すなら、それをスキルにすべきです。

スキルは本質的には保存されたワークフローです。ステップを書き、名前を付け、後で名前を呼び出すだけです。

私は自分自身で十数個のスキルをカプセル化しました：カバー画像生成、記事公開、画像圧縮、ウェブページからMarkdownへの変換...

それぞれが「毎回完全なプロンプトを手動で言う」から「一つのコマンドで完了」へと進化しました。

Borisのルールは採用する価値があります：1日に2回以上するなら、スキルとしてカプセル化する。

BorisのチームはBigQuery用のスキルを構築し、チームメンバーがSQLを書かずにClaude Codeで直接データ分析クエリを実行できるようにしました。一つのスキルで、すべてのプロジェクトで再利用可能です。

戦略9: あなたの推測ではなく、実際のデータを与える#

従来のバグ修正プロセスはこうです：

言葉でバグを説明する → Claudeが数回間違えて推測する → あなたが数回修正する → 最終的に修正される。

その間の無駄なコンテキストスペースは膨大です。

より速いアプローチ：Claudeに実際のエラー情報を与え、その後は離れる。

BorisのチームはSlack MCPを統合しました。Slackがバグを報告すると、彼らは会話を直接Claudeに貼り付け、一言「fix」と投げます。

追加の説明も、手取り足取りの指導もありません。Claudeは会話を読み、問題を見つけ、修正します。

または「あの失敗しているCIテストを修正して」と言い、その後は離れます。どのテストか、なぜ失敗したかをClaudeに説明しません。それでもClaudeは理解します。

重要なのは：Claudeに実際のデータ（Slackスレッド、エラーログ、Docker出力）を与えることで、あなたの問題についての推測ではありません。

Claudeは分散システムのログを読み、正確に障害点を特定するのが得意です。バックエンド開発者として、これは私にとって嬉しい驚きでした。

すべてをまとめる：私の日常ワークフロー#

すべての上記の戦略を結びつけた、私の典型的な日常ワークフローを共有しましょう：

タスクを開始する前：

CLAUDE.mdの更新が必要か確認する。
タスクの複雑さを評価し、プランモードが必要か判断する。

タスク実行中：

複雑な調査サブエージェントに投げる。
コードを書くメインセッション + 具体的なプロンプト + 組み込み検証。
コードレビュー2番目のセッションを開く。

30〜45分ごとに：

Claudeに進捗を要約させる。
コンテキストリセットが必要か評価する。

タスク完了後：

Claudeが犯したミスCLAUDE.mdを更新。
繰り返し操作スキルにカプセル化。

このワークフローは、私の効率を少なくとも3倍にしました。Claudeが強くなったからではなく、私がその「脳」を管理することを学んだからです。

最後に#

記事の冒頭の比喩に戻りましょう。

コンテキストウィンドウはClaudeのホワイトボードです。ホワイトボードのサイズは固定されていますが、何を書き、いつ消して最初からやり直すかはあなたが決めます。

コンテキストを管理することは、本質的にAIの注意力を管理することです。

これは新しいスキルです。プログラミング能力やドメイン知識とは関係ありませんが、AIからどれだけの価値を引き出せるかを決定します。

早くマス