今更だけどよくやる Claude Code 活用法
Claude Code が途中から指示を聞かなくなるのはコンテキスト圧迫が原因です。仕組みを整理したうえで、私が日常的にやっているリセット、模範解答、計画、巻き戻しの 4 つの対策をまとめます。
目次
Claude Code、長く話していると最初に出した指示を無視されはじめますよね。
「同じことを何度も言わないと意図が伝わらない」「気づいたらトークンだけ消費して、思っていたのと違うコードができている」。私もずっとこれに悩んでいました。
原因はモデルの限界ではなく、コンテキストウィンドウの圧迫です。
会話のたびに過去の履歴をまとめて送り直す仕組みのため、長く話すほど入力トークンが膨らみ、精度が落ちていきます。
この記事では仕組みを整理したうえで、私が日常的にやっているリセット、模範解答、計画、巻き戻しの 4 つの対策をまとめます。
なぜ長く話すと壊れるのか
Claude Code は会話のたびに「今回の指示」だけでなく、これまでの会話履歴 + システムプロンプトも一緒にモデルへ送っています。
1回目: [System] + [Q1] → [A1]
2回目: [System] + [Q1+A1] + [Q2] → [A2]
3回目: [System] + [Q1+A1+Q2+A2] + [Q3] → [A3]
4回目: [System] + [Q1+A1+Q2+A2+Q3+A3] + [Q4] → [A4]会話が進むほど、毎回送信するトークン量は雪だるま式に増えていきます。
そして、コンテキストウィンドウは無限ではありません。Chroma が公開した Context Rot: How Increasing Input Tokens Impacts LLM Performance という研究では、入力トークンが増えるほど LLM の精度が大きく落ちることが示されています。
つまり「会話を続ければ続けるほど賢くなる」のではなく、埋まれば埋まるほど指示を見失っていくのが現実です。
こまめにリセットする
精度が落ちる主因がコンテキスト圧迫なら、対策はシンプルです。
こまめに /clear で会話をリセットすることです。
機能を実装したいときは、機能全体を 1 会話でやり切ろうとせず、タスクを分解して別セッションで実装したほうが結果的に速く、精度も安定します。
ここまで話した内容を捨てるのがもったいないときは、リセット前に Claude Code 自身に引継ぎ文章を作らせてからクリアします。
私がよく使うのはこれです。
次のセッションの指示を簡潔に考えて、pbcopy してクリップボードに入れてください。これでクリップボードに次セッション用のプロンプトが残るので、/clear の直後にそのまま貼り付ければ続きから再開できます。
引継ぎ用に長大なファイルをわざわざ作る必要はありません。
指示を詰め込まず、模範解答を渡す
ルールをびっしり書き並べた長文プロンプトより、良い例を 1 つ見せるほうが圧倒的に効きます。
たとえば議事録を作らせる場面を考えます。
「箇条書きで、敬語で、堅苦しくなりすぎず、部署名は正式名称で、個人名は書きすぎないで議事録を作成して」
このように指示するのではなく、次のように指示します。
「過去に作成した
meeting-2026-05-01.mdと同じトーンで議事録を作成して」
このほうが、求めている内容に近い出力をします。
開発タスクでも同じです。設計方針、命名規則、テストパターンを長文で説明するより、「UserService.ts を参考に同じスタイルで実装して」と書いたほうが意図が伝わります。
模範解答が最初から手元にあるとは限りません。その場合は、Claude Code と一緒に模範解答を育てればいい話です。
何度かやり取りして満足できる出力ができたら、それを次回以降のリファレンスとして残しておきます。
ただし、模範解答を育てる過程でも会話は長くなるので、こまめにリセットするのは忘れずにやりましょう。
実装前に計画を立てる
Claude Code は、ユーザーからの依頼をよしなに解釈してすぐ実装を始める傾向があります。
その結果「は？思ってたのと違うんだけど🤮」となってトークンと時間を失います。
これを防ぐには、実装前に計画を立てさせるか、自分の考えを整理してまとめてから Claude Code に作業させたほうがよいです。
/planでプランモードに切り替え、実装計画を先に立てさせる- そもそも自分の頭が整理できていないなら、要件を言語化するインタビュー型のスキル(
grill-me) で先に依頼内容を明確にする
さらに、できあがったプランファイルを鵜呑みにせず、サブエージェントにレビューさせるのも有効です。
私がよくやるのは「プランファイルはシニアエンジニアのサブエージェントにレビューさせ、真っ当な指摘だけ修正を実施。判断に悩むものは必ず私に質問する」という指示です。
プランは作っただけだと観点が漏れていることがあるので、別視点を通すのが安全です。
記憶を書き換える
最後はリセットの応用です。あと、ちょっと言ってみたかっただけです。
エスケープキーを 2 回押す(または /rewind)と、過去の会話に戻れます。
「いまの回答、ちょっと違うな」と感じた瞬間に追加で説明を重ねるより、最初の指示を出した時点まで巻き戻してより具体的に指示し直すほうが、無駄な情報が入らず精度は落ちにくいです。
私「議事録作成して」
🤖「はい、作成しました」
私「これ、敬語が丁寧口調すぎるな…もうちょいフレンドリーにして。」
🤖「はい、フレンドリーにしました(もはやタメ口)」
私「え？フレンドリーすぎん？相手はお客様で取引相手だよ？」
私「なんか思ってたんと違うなぁ….」このような経験は誰にでもあるはずです。
「なんか思ってたのと違うなぁ。」となったら、記憶を書き換えましょう。
私「議事録作成して」
🤖「はい、作成しました」
// このタイミングでエスケープキー 2 回(または `/rewind`)で「議事録作成して」まで戻す
私「議事録作成して。相手はお客様で取引相手です。敬語がベースだけど、堅苦しくなりすぎず、過去に作成した `meeting-2026-05-01.md` くらいの少しだけフレンドリーな口調で作成して。」
🤖「はい、作成しました」ここでも、前章の指示を詰め込まず、模範解答を渡すが活きてきます。
まとめ
- コンテキストウィンドウは積み重なるほど精度が落ちる
- 長く話し続けるより、こまめにリセットして引継ぎプロンプトで橋渡しするほうが速い
- ルールを書き連ねるより、良い例を 1 つ見せたほうが伝わる
- 実装前にプランを立て、サブエージェントにレビューさせると手戻りが減る
- 「ちょっと違うな」と感じたら追加で説明するより、
/rewindで巻き戻して指示し直すほうが精度は落ちにくい - 突き詰めると全部「Claude Code に渡す情報の質と量を、自分でコントロールする」という 1 つの話に収まる
参考
Claude Codeですぐ制限にかからないようにするコツ
Intelligence Degradation in Long-Context LLMs: Critical Threshold Determination via Natural Length Distribution Analysis
Large Language Models (LLMs) exhibit catastrophic performance degradation when processing contexts approaching certain critical thresholds, even when information remains relevant. This intelligence degradation-defined as over 30% drop in task performance-severely limits long-context applications. This degradation shows a common pattern: models maintain strong performance up to a critical threshold, then collapse catastrophically. We term this shallow long-context adaptation-models adapt for short to medium contexts but fail beyond critical thresholds. This paper presents three contributions: (1) Natural Length Distribution Analysis: We use each sample's natural token length without truncation or padding, providing stronger causal evidence that degradation results from context length itself. (2) Critical Threshold Determination: Through experiments on a mixed dataset (1,000 samples covering 5%-95% of context length), we identify the critical threshold for Qwen2.5-7B at 40-50% of maximum context length, where F1 scores drop from 0.55-0.56 to 0.3 (45.5% degradation), using five-method cross-validation. (3) Unified Framework: We consolidate shallow adaptation, explaining degradation patterns and providing a foundation for mitigation strategies. This work provides the first systematic characterization of intelligence degradation in open-source Qwen models, offering practical guidance for deploying LLMs in long-context scenarios.
実装前に設計を徹底的にインタビューし、要件を明確にするためのスキル `/grill-me`
コーディングエージェントの自律性が向上し、並行して複数のエージェントを動かすことが当たり前になってきた今、エージェントの動きを逐一監視することは現実的ではなくなっています。そのため実装前に人間と AI の間で共通理解を形成することが重要になっています。この記事では、実装前の設計フェーズで要件を明確にし、人間と AI の間で共通理解を形成するためのスキル `/grill-me` について紹介します。
skills/skills/engineering/grill-with-docs at main · mattpocock/skills
Skills for Real Engineers. Straight from my .claude directory. - mattpocock/skills
Prompting best practices
Comprehensive guide to prompt engineering techniques for Claude's latest models, covering clarity, examples, XML structuring, thinking, and agentic systems.
なぜ、あの人のAIは賢いのか？「AIの限界」を越える3つのコツ | 本気AI
毎日10分で最先端のAIを使いこなす人材へ。徹底検証したマジ便利なAI活用だけを紹介！知識ゼロでも楽しく気軽に学べる本気AIで、あなたもAIマスターに！
