#22 長い会話が重くなるのは、なぜ？

まず結論

会話が重くなる正体は、ホワイトボードが埋まっていくことです。

第6回で、Claude Codeくんの記憶は会話ごとに1枚のホワイトボードに書かれる、という話をしました。今回そこに足すのが、Claude Codeくんは、返事をする前に、毎回、そのホワイトボードを最初から最後までぜんぶ読み直しているということです。前の返事の続きを覚えているのではなく、毎回ホワイトボード全体を読んでから、次の一言を考えています。だから、会話が長くなるほど毎回読む量が増えて、返事が重くなります。

ホワイトボードが埋まってくると、4つの現象が起きます。

1. 埋まるほど、正確さが落ちる — 読む量が増えるほど、1個1個の情報を拾いそこねやすくなる
2. 道具の出力が、場所を食う — ファイルを1個読むだけで、ホワイトボードがごっそり埋まる
3. 真ん中が、抜ける — 長い内容は、最初と最後に比べて、真ん中が落ちやすい
4. 要約で、数字が溶ける — いっぱいになって古い部分が要約されると、金額や日付が「だいたい」になる

対策は3つです。

1. 金額や日付みたいな大事な事実は、会話とは別の「事実メモ」に書いて、毎回見せる
2. 長い内容を渡すときは、要点を先頭に置いて、見出しで区切る
3. 道具の出力は、必要な部分だけに絞る

4つの現象は、どれもホワイトボードが埋まっていくことから起きます。3つの対策は、どれも「ホワイトボードには、今の作業に必要なことだけを、拾いやすい形で載せる」という1つの考え方から来ています。

よくある3つの誤解

1. 「返事が雑になってきたのは、AIが疲れたか、今日は調子が悪いんでしょ？」 — AIに疲れや機嫌はありません。返事が雑になるのは、ホワイトボードが埋まって毎回読む量が増え、Claude Codeくんが1個1個の情報を拾いそこねているからです。同じ質問を新しい会話で聞き直すと、最初の頃のちゃんとした返事に戻ります。Claude Codeくんが元気になったのではなく、まっさらなホワイトボードで読み直したからです。第6回の「1会話1テーマ」は、この現象を避けるためのものでした。今どれくらい埋まっているかは、下の「ホワイトボードの使用量の一覧の見方」で確かめられます
2. 「長く会話してるほど、AIはこっちのことを学習して、賢くなっていくんでしょ？」 — 逆です。Claude Codeくんは会話の中で学習しているのではなく、ホワイトボードに書いてあることを毎回読んでいるだけです。「分かってくれている」と感じるのは、みなさんの事情がホワイトボードにたくさん書いてあるから。そして書いてあることが増えるほど、正確さは落ちていきます。公式の説明でも、文字数（トークン）が増えるほど正確さと拾い上げる力が落ちる、と書かれています。みなさんの事情は第7回の貼り紙（CLAUDE.md）に書いておけば、新しい会話でも最初から知っている状態にできるので、長い会話で息を合わせていく必要はそもそもありません
3. 「古い部分を要約してくれる機能があるなら、情報は何も失われないんでしょ？」 — 要約は必ず何かを落とす作業です。特に落ちやすいのが、数字と、日付と、お客さんとか上司とか、誰かが言った言葉そのもの。「A社から、10月15日までに、税込で48万円の見積もりが欲しいと連絡があった」が、要約されると「A社から見積もりの依頼があった」になり、期限も金額も「税込」も消えてしまいます。一度ホワイトボードから消えた情報は、あとから「48万って言ったよね？」と聞いても戻りません

ステップ1: 毎回ぜんぶ読み直す。そして、1つ目と2つ目の現象

Claude Codeくんは、返事をする前に、毎回、ホワイトボードを最初の一行から最後の一行まで読み直してから返事を考えています。会議で言うと、一言発言する前に、毎回、その日の議事録を最初から全部読み返してから口を開く人です。最初のうちは議事録が短いのですぐ答えられますが、2時間経って議事録が何十ページにもなると、一言のたびにそれを全部読み返すことになります。返事も遅くなるし、読み飛ばしも増えます（下の「毎回ぜんぶ読み直す、の図」）。

現象の1つ目「埋まるほど、正確さが落ちる」。ホワイトボードは、たくさん書いてあればあるほどいい、というものではありません。公式の言葉では「コンテキストの劣化（context rot）」と呼ばれています。「たくさん書いてあるから安心」ではなく、「たくさん書いてあるから見落とす」。なので基本の考え方は、ホワイトボードには、今の作業に必要な情報だけを載せる、です。

現象の2つ目「道具の出力が、場所を食う」。Claude Codeくんがファイルを読んだり検索したりする「道具」の出力は、ぜんぶホワイトボードに書き込まれます。公式ドキュメントにも「ファイルの読み込みが、使用量の大半を占める」とあります。たとえば「注文の一覧から、この注文の情報を出して」と頼むと、住所も電話番号も支払い方法も配送状況も、何十項目もの情報が丸ごと乗りますが、今の作業に必要なのは5項目くらいだったりします。

対策は、3つの対策の3つ目「道具の出力は、必要な部分だけに絞る」。「注文の情報を出して」ではなく「注文の、金額と期限と状態だけを出して」と、必要な項目だけ出してもらいます。第19回の「部下に別室で作業してもらう」やり方も、道具の出力を部下のホワイトボードに閉じ込めておく工夫でした。

ステップ2: 3つ目の現象。真ん中が抜ける

Claude Codeくんは、長い文章の最初のほうと最後のほうに比べて、真ん中を落としやすい性質があります。英語で「ロスト・イン・ザ・ミドル（lost in the middle）」という名前がついているくらい、AIによく起きるものとして知られています。たとえば30ページの資料を渡して「15ページ目に書いてある、あの条件を守って」と頼むと、最初の3ページや最後の3ページに比べて、読んでいるはずなのに答えに反映されにくくなります。

対策は、3つの対策の2つ目「要点を先頭に置いて、見出しで区切る」。

• 要点を、先頭に置く — 資料の一番上に「この資料の要点は、この3つです」というまとめを置く。真ん中に埋まっている大事な条件も、先頭のまとめに1行書いておけば、そこから拾ってもらいやすくなります
• 見出しで、区切る — だらっと長い文章ではなく、「1. 条件」「2. 手順」「3. 注意」のように見出しで区切る。真ん中の内容でも、見出しが目印になって拾いやすくなります

Claude Codeくんにまとめてもらった資料を、あとで新しい会話のClaude Codeくんに渡すときも同じです。まとめを頼む時点で「要点を先頭に書いて、見出しで区切った形でまとめて」と頼んでおけば、その形で出してくれます（下の「要点を先頭に置いた資料の形の例」）。

ステップ3: 4つ目の現象。要約で数字が溶ける。そして、事実メモ

Claude Codeくんは、ホワイトボードがいっぱいに近づくと、古い部分を自動で要約して場所を空けます（公式の説明では、上限に近づくと自動で要約が走るので、ホワイトボードがいっぱいになっても会話は終わりません）。便利な機能ですが、要約は必ず何かを落とすので、特に金額、割合、日付、注文番号、「見積もり待ち」みたいな今の状況、それから誰かが言った言葉そのもののような「正確じゃないと意味がない情報」が、「だいたいこんな感じ」にぼんやり溶けやすくなります。「48万円」が「50万円くらい」に、「10月15日まで」が「来月くらい」に、「税込で」の一言がそもそも消える、という具合です。

これの対策が、3つの対策の1つ目で、今回一番持ち帰ってほしい「事実メモを、ホワイトボードの外に持つ」です。正確じゃないと困る事実だけを短い箇条書きにして、会話の中ではなく別の場所（たとえば小さなファイル）に書いておき、Claude Codeくんに何か頼むたびに一緒に見せます。会話のほうがどれだけ要約されても、事実メモは要約の対象ではないので溶けません（下の「事実メモの書き方の実例」）。

たとえば、経理の作業で、朝から同じ会話でずっと請求書や見積書を作っていたとします（仮定の例です）。午前中は完璧だったのに、午後になって「この請求書、金額が微妙に違うな」というのがぽつぽつ出てくる。確認すると、午前中に会話の中で伝えた金額が要約されて「だいたい」になっていた。こういうときにやることは2つです。

• 案件ごとの事実メモ（会社名・金額・期限・状態だけを書いたファイル）を作って、請求書を作るときは必ずそのメモを見せてから頼む
• 第6回の「1会話1テーマ」で、午前と午後で会話を分ける

なお、自分で要約を操作する方法、会話を分けて続きから再開する方法、メモをファイルとして持つ方法などの具体的な操作は、次回の第23回でまとめてお話しします。

4つの現象と3つの対策の対応表

どの現象に、どの対策が効くかの対応です。

毎回ぜんぶ読み直す、の図

会話が1往復進むごとに、Claude Codeくんが返事の前に読む量がどう増えていくかのイメージです。

• 貼り紙（作業フォルダの一番上の CLAUDE.md）は、要約のあとにファイルから読み込み直されます（公式ドキュメント「What survives compaction」）。事実メモを「会話の外」に持つと溶けないのは、これと同じ理屈です

事実メモの書き方の実例

事実メモは、正確じゃないと困る事実だけを短い箇条書きにしたものです。文章で説明せず、1行1事実で書きます。

# A社 見積もり 事実メモ
- 会社名：A社
- 金額：税込 48万円
- 期限：10月15日まで
- 状態：見積もり待ち
- 先方の言葉：「納品は分割でもかまわない」

• 案件ごとに1つ作ります。何でも書き足すと、事実メモ自体が長くなって埋もれてしまうので、溶けたら困るものだけに絞ります
• 「誰かが言った言葉そのもの」は、言い回しのまま「」で残しておくと、要約で意味が変わるのを防げます

毎回見せるときは、こんなふうに頼みます。

A社の事実メモを見てから、見積書を作って。
金額と期限は、会話の中の話じゃなくて、必ず事実メモの数字を使って。

事実メモを作るところから頼むこともできます。

この案件で、決まった金額・期限・状態と、先方が言った言葉を、
事実メモとして箇条書きのファイルにまとめておいて。
このあとは、毎回そのメモを見ながら進めて。

• 5分で終わるような短いお願いなら、そこまでしなくて大丈夫です。1時間以上、同じ会話で続けている作業が、事実メモを作る一番の候補です
• メモをファイルとして持つ方法の詳しい話は、第23回で扱います

要点を先頭に置いた資料の形の例

長い資料を渡すとき、または、あとで渡すための資料をClaude Codeくんにまとめてもらうときの形です。

# 新しい請求書の運用ルール

## 要点（ここだけは必ず守る）
1. 金額は税込・税抜の両方を書く
2. 支払期限は請求月の翌月末
3. A社だけは分割請求OK（3ページ目の「例外」）

## 1. 条件
……

## 2. 手順
……

## 3. 注意
……

• 真ん中のページにある大事な条件（例の3つ目）を、先頭の要点に1行書いておくのがポイントです
• まとめを頼むときは「要点を先頭に書いて、見出しで区切った形でまとめて」と一言添えるだけで、この形で出してくれます

ホワイトボードの使用量の一覧の見方

本編の誤解コーナーで触れた、今どれくらいホワイトボードが埋まっているかの確かめ方です。

Claude Codeくんに指示を打ち込む欄に、/context（スラッシュ、コンテキスト）と打ちます。公式ドキュメントでは、カテゴリ別の使用量の内訳と、軽くするための提案が表示され、どの CLAUDE.md やメモが読み込まれているかも確認できる、とされています（2026年10月時点）。

見るポイントは3つです。

• 全体でどれくらい埋まっているか — 上限に対して、いまどれくらい使っているか。上限に近いほど、もうすぐ自動の要約が走ります
• 会話のやりとりの分がどれくらいか — 会話のやりとり（ファイルを読んだ結果も含む）が大きければ、話題を変えるタイミングで新しい会話にする目安です
• 最初から載っている分がどれくらいか — 貼り紙（CLAUDE.md）や道具の一覧など、会話を始める前から載っている分です。ここが大きいと、どの会話でも最初から場所を使っていることになります

表示の項目名や並びは、Claude Code のバージョンによって変わることがあります。「この一覧のどこが大きい？ 軽くするにはどうしたらいい？」とClaude Codeくんに聞けば、その場の表示に合わせて説明してくれます。

補足: トークン・ホワイトボードの大きさ・読み直しのコスト

本編では「文字数」「読む量」と言いましたが、正確には、Claude Codeくんが読む量はトークンという単位で数えます。文字数みたいなもの、と思っておけば大丈夫です。

• ホワイトボードの大きさは、使っているモデルごとに決まっています。モデルによっては、もっと大きなホワイトボード（100万トークン）を選べます（利用できるかはプランによります）。ただ、大きくしても「埋まるほど正確さが落ちる」ことと、いっぱいに近づくと要約が走ることは同じです。大きくするより、今の作業に必要なことだけを載せるほうが、正確さには効きます
• 自動の要約が走るタイミングも、モデルや設定によって変わります
• 毎回ぜんぶ読み直すのは、仕組みとしては正しいのですが、毎回ゼロから同じ手間をかけているわけではありません。同じ部分を使い回して処理を軽くする仕組み（キャッシュ）があるので、料金や待ち時間の面では、読み直しのコストはある程度軽くなっています。それでも、ホワイトボードに載っている量そのものは毎回ぜんぶ読まれるので、「埋まるほど正確さが落ちる」ことは変わりません

※ここに書いた仕様は 2026年10月9日時点の公式ドキュメントに基づいています。Claude Code は更新が速いので、最新の情報は公式ドキュメントで確認してください。