コンテキストウィンドウ：エージェントが忘れる理由と、やり直すタイミング

AIエージェントにコードを書かせたり、複数の手順にまたがる作業を任せたりする人なら、初心者の方でも読めます。モデルの仕組みの知識は不要です。用語にはどれも身近なたとえを添えています。計算の部分は印をつけてあるので、不要なら読み飛ばせます。

数字は公開情報から取っており、末尾に一覧があります。「例」と書いたものは作った例で、実在の人物や会社には触れていません。モデルが長い入力を内部でどう扱うかは、まだ誰にも完全には分かっていません。以下のたとえは覚えやすくするための補助です。コマンド名は、読んだ時点のClaude Codeの文書によるもので、他のツールや新しいバージョンでは異なる場合があります。

---

まず要点#

• エージェントが「覚えて」いるのは、コンテキストウィンドウの中にあるものだけです。あなたの依頼、読んだファイル、コマンドの出力、プロジェクトの指示が入ります。ウィンドウには上限があり、開いたものはすべて場所をとります。
• 複数の研究が、モデルは短い入力より長い入力を安定して使えないことを見つけています。Liuら（2023年）は、必要な情報が先頭か末尾にあるときに結果が良くなりやすく、中ほどにあると落ちることを見つけました。Chromaの報告（2025年7月）は18のモデルを調べ、入力が長くなるほど信頼性が落ちることを見つけました。著者自身、課題は実際の仕事より単純だと述べています。
• 会話が満杯に近づくと、ツールが会話を要約に圧縮することがあります。Claude Codeの文書は、要約はあなたの依頼と主要なコードを残すが、初めのほうの指示の細部は失われうると述べています。
• 本記事の計算例では、長い作業でウィンドウの約91.5%が埋まり、そのうち約43%は終わった古い作業でした。短い引き継ぎメモで新しく始めると、使用量は約8%になります。これは自分で計算し直すための例の数字です。
• 長く守らせたいルールは、会話ではなくプロジェクトの指示ファイルに書きます。無関係な作業に移るなら会話をクリアし、同じ作業で長くなったなら指示つきで圧縮します。
• やり直しにも代償があります。エージェントはファイルを読み直す必要があり、引き継ぎメモが不足したり間違ったりすることもあります。「いつ」の部分は経験則で、測定結果ではありません。

---

むずかしい言葉をやさしく#

---

1. まずイメージ：広さが決まった机#

あまり大きくない机で仕事をしているところを想像してください。上司の依頼、何枚かの資料、いくつかの調べものの結果、自分のメモを広げます。最初は机が空いていて、すべてが見渡せます。2時間後には机は紙でいっぱいで、必要な1枚は3枚の下です。それでも仕事はできますが、遅くなり、見落としも増えます。完全に埋まってしまったら、大事な点を新しい紙に写し、机を片づけて続けます。写しには、いくつか細部が欠けているはずです。

エージェントも、かなり似た動き方をします。Claude Codeの文書は、コンテキストウィンドウには会話の履歴、ファイルの内容、コマンドの出力、指示ファイル、自動メモリ、読み込んだスキル、システムの指示が入ると説明しています。作業が進むにつれてウィンドウは埋まっていきます。これは覚えやすくするためのたとえにすぎません。モデルの内部は、机よりずっと複雑なはずです。

教訓：「エージェントが忘れた」のは、怠けているからでも愚かだからでもなく、場所が限られていて、場所をとっているものが必要なものとは限らないからであることが多いのです。机を管理するのはあなたの仕事です。

---

2. 何が場所をとり、圧縮後に何が残るか#

2.1 場所をとるもの#

Claude Codeの文書によると、何も入力しないうちから、いくつかのものが机の上にあります。指示ファイル、自動メモリ、MCPツールの名前、スキルの説明です。その後は、ファイルを読むたび、コマンドの出力が出るたび、やりとりが1往復するたびに増えていきます。/contextコマンドを使うと、種類別の使用量と減らすための提案が見られます。

2.2 圧縮後に残るもの#

満杯に近づくと、ツールは会話を要約に圧縮します。下の表は、文書の「What survives compaction」の節を、私が読んだ版でまとめたものです。バージョンによって細部は変わりえます。

表から言えることは2つです。ルールが必ず残らなければならないなら、口頭ではなく、プロジェクトのルートの指示ファイルに書くこと。そして何を残すかを自分で決めたいなら、ツールに推測させず、指示つきで意図的に圧縮すること。例：/compact focus on the auth bug fix。

教訓：長く守らせたいルールは、机の上の紙の山ではなく壁に貼る決まりごとに属します。その決まりごとの書き方は、AGENTS.mdの書き方を参照してください。

---

3. 会話が長いとエージェントが悪くなりやすい理由#

300ページの資料を読んだあとで、150ページ目の細部を聞かれたところを想像してください。答えられるかもしれませんが、1ページだけ渡されたときよりずっと難しいでしょう。言語モデルの研究も似たことを示しています。ただし、なぜそうなるのかは、誰も十分には説明できていません。

3.1 Liuら（2023年）：中ほどの情報は見落とされやすい#

著者たち（Percy Liangを含む）は、複数の文書から質問に答える課題と、キーと値のリストから値を取り出す課題を試しました。arXivの概要によると、関連する情報が入力の先頭か末尾にあるときに性能が最も高くなることが多く、長い入力の中ほどにある情報を使わせると大きく下がります。長い文脈に対応すると宣伝されたモデルでも同じです。これは2023年当時のモデルでの実験です。私が読んだ概要ページには個々のモデル名がないため、新しいモデルでは結果が違うかもしれません。

3.2 Chroma（2025年7月）：18モデルで、入力が長いほど信頼性が低下#

Chromaの技術報告（Hong、Troynikov、Huber）は、GPT-4.1、Claude 4、Gemini 2.5、Qwen3の系列を含む18のモデルを、3種類の課題で調べました。拡張版の「干し草の山の中の針探し」、長い会話に対する質問応答（LongMemEval、306問、平均約11万3,000トークン）、単語列の繰り返しです。著者たちは、入力が長くなるほど性能がますます不安定になると書いています。また、邪魔な情報が1つあるだけでも結果が悪くなること、モデルによって反応が異なることも見つけています。彼らによると、Claude系のモデルはあいまいなときに回答を控える傾向があり、GPT系のモデルは邪魔な情報があると誤答が多くなる傾向がありました。

著者自身の言葉もあわせて読んでください。課題は実際の仕事より単純なので、現実ではもっと悪くなりうると考えているものの、長さの影響と課題の難しさの影響を切り分けるのは難しく、報告は仕組みを説明していません。1社の技術報告であり、独立した検証は私は見つけていません。

3.3 Anthropic（2025年9月）：有限な「注意の予算」#

Anthropicのコンテキストエンジニアリングの記事（2025年9月29日）は、context rotという用語を使い、コンテキストを有限の資源として説明しています。追加されたトークンは1つ1つ、モデルの「注意の予算」の一部を使います。記事は、満杯に近づいたら圧縮する、ウィンドウの外にメモを残してあとで読み返す、自分の机を持つサブエージェントを使う、といった方向を提案しています。これはツールを売る会社の技術的な見解であり、対照実験ではありません。

**教訓：**3つの出典は同じ方向を向いています。長いほど良いとは限りません。どの程度か、なぜかは不確かで、モデルによっても違います。

---

4. 自分で確かめられる計算（例、読み飛ばし可）#

これは作った数字による例で、測定値ではありません。ウィンドウが20万トークンだとします。ある作業は、開始時に読み込まれる1万2,000トークン、1回3,000トークンのファイル読み込み25回、1回1,500トークンのコマンド出力40回、1回600トークンのやりとり60回でできています。

window = 200_000
startup = 12_000
files, file_size = 25, 3_000
cmds, cmd_size = 40, 1_500
turns, turn_size = 60, 600

used = startup + files * file_size + cmds * cmd_size + turns * turn_size
print(used, round(used / window * 100, 1))
# 183000 91.5

# 作業の半分が、終わった古い作業だとする
old = 0.5 * (used - startup)
print(old, round(old / window * 100, 1))
# 85500.0 42.8

# 4,000トークンの引き継ぎメモで新しく始める
fresh = startup + 4_000
print(fresh, round(fresh / window * 100, 1), (window - fresh) // file_size)
# 16000 8.0 61   (3,000トークンのファイルがあと何個入るか)

結果の読み方：長い作業はウィンドウの約91.5%を使い、そのうち約43%は古い作業です。あと入るファイルは約5個だけです（1万7,000を3,000で割る）。4,000トークンの引き継ぎメモで新しく始めると、使用量は約8%になり、あと約61個のファイルが入ります。

はっきり注意しておきます。上のトークン数はすべて仮定で、作業の半分が古い作業だという仮定も含みます。ウィンドウの大きさ、自動圧縮のしきい値、トークンの数え方は、モデルとツールによって違います。この計算は、8%のほうが91.5%より良い結果になるとは言っていません。示しているのは、古い作業がどれだけ場所をとるかだけです。実際の数字は、自分のセッションで/contextを実行して確かめてください。

---

5. いつ何をするか：整理、圧縮、分割、やり直し#

机を思い浮かべてください。紙を少し脇へ寄せるだけでよいときも、メモを新しい紙に写すときも、別の机へ移ったほうがよいときもあります。

「根拠」の列は、どこが文書にあり、どこが個人の経験かを示しています。「2回の訂正」や「ウィンドウの半分以上」のような具体的な目安を測った研究は、私は見つけていません。出発点として使い、自分で調整してください。

5.1 やり直しを考えてよいサイン#

1. 机の上のほとんどと無関係な作業に移る。
2. エージェントが、伝えたルールを破り、2回目の注意が必要になる。
3. エージェントが同じ箇所を直し続ける、または一度退けた案をまた出してくる。
4. 会話で何が決まったか、自分でも思い出せなくなる（エージェントはなおさら難しい）。
5. 自動圧縮のあと、品質がはっきり変わる。
6. /contextを見ると、場所の大半が終わった作業のコマンド出力とファイルになっている。

---

6. 引き継ぎメモのひな形（コピーして使えます）#

当直の引き継ぎ帳を思い浮かべてください。次の人が1分読めば続けられるものです。新しいセッションの冒頭に貼るか、プロジェクト内のファイルとして保存して、あとで読み直せるようにします。

## 引き継ぎメモ
目的: <1文>
完了して確認済み: <内容と、実行したコマンドと結果>
作業中: <ファイル、関数、次の手順>
決めたことと理由: <決定を1行ずつ>
試してだめだったこと: <方法と、やめた理由>
してはいけないこと: <境界、触らないファイル>
未確認または仮定: <エージェントが実行せず推測したこと>
確認を再実行するコマンド: <1つのコマンド>

「未確認または仮定」の欄は、AIの結果に証拠を求める5つの方法から取っています。実行したことと推測にすぎないことを分けておけば、新しいセッションが推測を事実として扱わずにすみます。エージェントに下書きを頼み、そのあと自分で読んで直すことができます。AIが書いた要約にも、抜けや誤りがありうるからです。

同じ作業のまま続けるときの、指示つき圧縮のコマンド：

/compact focus on: 現在の目的、決めたこと、編集中のファイル、
確認コマンド、触ってはいけないもの

---

7. 例：ある朝、2つの進め方#

これは作った例で、実在の人物や製品には触れていません。

会話をクリアしない場合：

• 09:00。 開発者がエージェントに請求書の丸めバグの修正を頼み、「新しい関数名はcalcで始めてください」と伝えます。
• 09:40。 エージェントは25個のファイルを読み、多くのコマンドを実行しました。バグは直り、テストも通ります。
• 10:30。 同じセッションで、開発者は別のページのボタンの色の変更を頼みます。
• 10:45。 エージェントはcomputeColorという名前の関数を追加します。09:00に伝えたルールに反しています。開発者が指摘して直りますが、その後、09:20に退けたはずの方法をまた提案してきます。

クリアして引き継ぎメモを使う場合：

• 09:40。 修正が終わり、開発者はコミットして、短い引き継ぎメモをプロジェクトのメモファイルに保存します。calcのルールは、ルートの指示ファイルにすでにあります。
• 10:30。 開発者は/clearを実行し、はっきりした依頼で新しい作業を始めます。
• 10:45。 エージェントは指示ファイルを読み、最初から正しい名前を付けます。

どちらでもすべきこと：長く守らせたいルールは指示ファイルへ、終わった作業はコミットしてから机を片づける。これは例なので、何かを証明するものではありません。根拠は第3節の研究で、それにも限界があります。古いモデルであること、課題が実際の仕事より単純なことです。あわせてエージェントへの依頼でありがちな7つの失敗も参照してください。

---

8. この通りにしても弱いところ#

---

9. 使った数字と文書#

正しく読むために：3つの研究の出典は、どれも「長いほど信頼性が落ちやすい」という方向を示唆しています。一方、「会話をクリアする」「引き継ぎメモを書く」ことで、実際の仕事の結果がどれだけ良くなるかを直接測った対照研究は見つけられませんでした。第5節の目安は経験則です。

---

10. 明日から使える習慣#

10.1 作業の途中での8つの質問#

1. いまの作業は、机の上のほとんどのものとまだ関係があるか。
2. 必須のルールは、ルートの指示ファイルに入っているか、それとも口頭で言っただけか。
3. /contextで、いちばん場所をとっているものは何か。
4. 終わった作業はコミットして確認したか。
5. 調べるためだけに多くのファイルを読ませる必要があるか。サブエージェントに任せるべきか。
6. 圧縮するなら、何を残したいか（指示として書いたか）。
7. やり直すなら、引き継ぎメモに「未確認または仮定」の欄があるか。
8. はっきりしたサインがあってやり直すのか、それとも習慣でやり直すのか。

10.2 今すぐできる3つのこと#

1. いまのセッションで/contextを実行し、場所をとっている上位3つを書き留める。
2. 何度も繰り返しているルール3つを、ルートの指示ファイルの短いブロックに移す。
3. 第6節の引き継ぎメモのひな形をファイルとして保存し、今週の作業1つで試す。

---

11. バランスよく見る：やり直しができること、できないこと#

**できること：**古い作業が場所をとる量を減らす、一度退けた案の繰り返しを避ける、決めたことを書き出させる（あとで読む人にも役立つ）、そして大事なルールを指示ファイルに安定して置く。

できないこと：

• より良い結果を保証するものではありません。新しいセッションは、引き継ぎメモに書かなかった細部を失い、エージェントはファイルを読み直すので手間とトークンがかかります。
• 「いつ」の目安について、実際の仕事での測定値は私にはありません。試して比べてください。
• 圧縮、読み直し、しきい値の決め方はツールごとに違い、バージョンでも変わります。今日読んだ文書が数か月後には当てはまらないかもしれません。
• AIが書いた要約も間違うことがあります。

**大げさに言わない：**エージェントの失敗すべてに効く薬ではありません。多くは、ウィンドウの満杯ではなく、あいまいな依頼から来ます。**軽く見ない：**机を誰も見ないまま続く会話は、小さな誤りが積もる場所です。整理は、エージェントが何を忘れたかを推測するよりずっと安く済みます。

---

12. 結論#

エージェントの記憶は無限ではありません。広さが決まった机の上で作業していて、机が散らかると結果が不安定になりやすいと研究は示唆しています。長く守らせたいルールは指示ファイルへ。同じ作業なら指示つきで圧縮し、作業を変えるならクリアし、やり直すときは自分で読み直した短い引き継ぎメモを持っていきましょう。

---

参考資料#

数字と説明は、2026年10月時点の公開情報によります。コマンド名とツールの挙動はバージョンで変わるため、引用する前に原典を開いて確認してください。

• Liuら、Lost in the Middle: How Language Models Use Long Contexts（arXiv、2023年7月、第3版は2023年11月20日）
• Hong、Troynikov、Huber（Chroma）、Context Rot: How Increasing Input Tokens Impacts LLM Performance（2025年7月14日）
• Anthropic、Effective context engineering for AI agents（2025年9月29日）
• Anthropic、Claude Codeの文書：How Claude Code works と Explore the context window