# 今更だけどよくやる Claude Code 活用法

  Claude Code、長く話していると最初に出した指示を無視されはじめますよね。

「同じことを何度も言わないと意図が伝わらない」「気づいたらトークンだけ消費して、思っていたのと違うコードができている」。私もずっとこれに悩んでいました。

原因はモデルの限界ではなく、コンテキストウィンドウの圧迫です。
会話のたびに過去の履歴をまとめて送り直す仕組みのため、長く話すほど入力トークンが膨らみ、精度が落ちていきます。
この記事では仕組みを整理したうえで、私が日常的にやっているリセット、模範解答、計画、巻き戻しの 4 つの対策をまとめます。

## なぜ長く話すと壊れるのか

Claude Code は会話のたびに「今回の指示」だけでなく、これまでの会話履歴 + システムプロンプトも一緒にモデルへ送っています。

```text
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](https://arxiv.org/abs/2601.15300) という研究では、入力トークンが増えるほど LLM の精度が大きく落ちることが示されています。

つまり「会話を続ければ続けるほど賢くなる」のではなく、埋まれば埋まるほど指示を見失っていくのが現実です。

## こまめにリセットする

精度が落ちる主因がコンテキスト圧迫なら、対策はシンプルです。
こまめに `/clear` で会話をリセットすることです。
機能を実装したいときは、機能全体を 1 会話でやり切ろうとせず、タスクを分解して別セッションで実装したほうが結果的に速く、精度も安定します。

ここまで話した内容を捨てるのがもったいないときは、リセット前に Claude Code 自身に引継ぎ文章を作らせてからクリアします。
私がよく使うのはこれです。

```text
次のセッションの指示を簡潔に考えて、pbcopy してクリップボードに入れてください。
```

これでクリップボードに次セッション用のプロンプトが残るので、`/clear` の直後にそのまま貼り付ければ続きから再開できます。
引継ぎ用に長大なファイルをわざわざ作る必要はありません。

## 指示を詰め込まず、模範解答を渡す

ルールをびっしり書き並べた長文プロンプトより、良い例を 1 つ見せるほうが圧倒的に効きます。
たとえば議事録を作らせる場面を考えます。

> 「箇条書きで、敬語で、堅苦しくなりすぎず、部署名は正式名称で、個人名は書きすぎないで議事録を作成して」

このように指示するのではなく、次のように指示します。

> 「過去に作成した `meeting-2026-05-01.md` と同じトーンで議事録を作成して」

このほうが、求めている内容に近い出力をします。

開発タスクでも同じです。設計方針、命名規則、テストパターンを長文で説明するより、「`UserService.ts` を参考に同じスタイルで実装して」と書いたほうが意図が伝わります。

模範解答が最初から手元にあるとは限りません。その場合は、Claude Code と一緒に模範解答を育てればいい話です。
何度かやり取りして満足できる出力ができたら、それを次回以降のリファレンスとして残しておきます。

ただし、模範解答を育てる過程でも会話は長くなるので、こまめにリセットするのは忘れずにやりましょう。

## 実装前に計画を立てる

Claude Code は、ユーザーからの依頼をよしなに解釈してすぐ実装を始める傾向があります。
その結果「は？思ってたのと違うんだけど🤮」となってトークンと時間を失います。

これを防ぐには、実装前に計画を立てさせるか、自分の考えを整理してまとめてから Claude Code に作業させたほうがよいです。

- `/plan` でプランモードに切り替え、実装計画を先に立てさせる
- そもそも自分の頭が整理できていないなら、[要件を言語化するインタビュー型のスキル(`grill-me`)](https://azukiazusa.dev/blog/before-implementation-interview-design-requirements-grill-me/) で先に依頼内容を明確にする

さらに、できあがったプランファイルを鵜呑みにせず、サブエージェントにレビューさせるのも有効です。
私がよくやるのは「プランファイルはシニアエンジニアのサブエージェントにレビューさせ、真っ当な指摘だけ修正を実施。判断に悩むものは必ず私に質問する」という指示です。
プランは作っただけだと観点が漏れていることがあるので、別視点を通すのが安全です。

## 記憶を書き換える

最後はリセットの応用です。あと、ちょっと言ってみたかっただけです。

エスケープキーを 2 回押す(または `/rewind`)と、過去の会話に戻れます。
「いまの回答、ちょっと違うな」と感じた瞬間に追加で説明を重ねるより、最初の指示を出した時点まで巻き戻してより具体的に指示し直すほうが、無駄な情報が入らず精度は落ちにくいです。
```
私「議事録作成して」
🤖「はい、作成しました」
私「これ、敬語が丁寧口調すぎるな…もうちょいフレンドリーにして。」
🤖「はい、フレンドリーにしました(もはやタメ口)」
私「え？フレンドリーすぎん？相手はお客様で取引相手だよ？」
私「なんか思ってたんと違うなぁ….」
```

このような経験は誰にでもあるはずです。
「なんか思ってたのと違うなぁ。」となったら、記憶を書き換えましょう。

```
私「議事録作成して」
🤖「はい、作成しました」

// このタイミングでエスケープキー 2 回(または `/rewind`)で「議事録作成して」まで戻す

私「議事録作成して。相手はお客様で取引相手です。敬語がベースだけど、堅苦しくなりすぎず、過去に作成した `meeting-2026-05-01.md` くらいの少しだけフレンドリーな口調で作成して。」
🤖「はい、作成しました」
```

ここでも、前章の指示を詰め込まず、模範解答を渡すが活きてきます。

## まとめ

- コンテキストウィンドウは積み重なるほど精度が落ちる
- 長く話し続けるより、こまめにリセットして引継ぎプロンプトで橋渡しするほうが速い
- ルールを書き連ねるより、良い例を 1 つ見せたほうが伝わる
- 実装前にプランを立て、サブエージェントにレビューさせると手戻りが減る
- 「ちょっと違うな」と感じたら追加で説明するより、`/rewind` で巻き戻して指示し直すほうが精度は落ちにくい
- 突き詰めると全部「Claude Code に渡す情報の質と量を、自分でコントロールする」という 1 つの話に収まる

## 参考

https://zenn.dev/aun_phonogram/articles/4be2f4745726fb

https://arxiv.org/abs/2601.15300

https://azukiazusa.dev/blog/before-implementation-interview-design-requirements-grill-me/

https://github.com/mattpocock/skills/tree/main/skills/engineering/grill-with-docs

https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices

https://ma-ji.ai/articles/933e1d8c-4df6-4e19-9d9d-90b398ce0686