---
title: "コンテキストウィンドウ：エージェントが忘れる理由と、やり直すタイミング"
url: https://www.stacklogs.io.vn/ja/gijutsu/context-window-agent-ga-wasureru-riyu-to-yarinaoshi-doki/
language: ja
author: "Nhu Duy Thin (Thinnd)"
published: 2026-10-30
updated: 2026-10-30
section: "エンジニアリング"
tags: ["コンテキストウィンドウ", "AIエージェント", "コンテキストロット", "圧縮", "引き継ぎ", "チェックリスト"]
summary: "コンテキストウィンドウとは、AIエージェントが一度に見られる文章全体のことです。依頼、読んだファイル、コマンドの出力、指示が入ります。サイズには上限があり、入力が長いほど精度が落ちやすいという研究があります。無関係な作業に移るときは会話をクリアし、満杯に近いときは指示つきで圧縮します。長く守らせたいルールは会話ではなく指示ファイルに書きます。"
license: "Cite with the author name and the canonical URL above."
---

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

> AIエージェントにコードを書かせたり、複数の手順にまたがる作業を任せたりする人なら、初心者の方でも読めます。モデルの仕組みの知識は不要です。用語にはどれも身近なたとえを添えています。計算の部分は印をつけてあるので、不要なら読み飛ばせます。
>
> 数字は公開情報から取っており、末尾に一覧があります。「例」と書いたものは作った例で、実在の人物や会社には触れていません。モデルが長い入力を内部でどう扱うかは、まだ誰にも完全には分かっていません。以下のたとえは覚えやすくするための補助です。コマンド名は、読んだ時点のClaude Codeの文書によるもので、他のツールや新しいバージョンでは異なる場合があります。

---

## まず要点

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

---

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

| 用語 | やさしい言い方 |
|---|---|
| **Context window**（コンテキストウィンドウ） | エージェントの作業机。机の上に開いているものが、見えているものです。広さには限りがあります。 |
| **Token**（トークン） | モデルが文章を数える単位。短い単語はふつう1トークン、長い単語は数トークンになることもあります。壁ではなくレンガを数えるようなものです。 |
| **Context rot**（コンテキストロット） | 入力が長いほど精度が落ちやすいという観察につけられた呼び名。机が散らかると必要な紙を探しにくくなるのと似ています。 |
| **Compaction**（圧縮） | ツールが長い会話を短い要約にして、その要約から続けること。メモを新しい紙に写して、古い紙の山を捨てるようなものです。 |
| **Handoff**（引き継ぎメモ） | 新しいセッションが、何をしていて、何を決め、何が残っているか分かるように自分で書く数行。当直の引き継ぎ帳のようなものです。 |
| **Subagent**（サブエージェント） | 自分の机で作業し、要約だけを返してくれる別のエージェント。同僚に調べものを頼むようなものです。 |
| **指示ファイル／メモリ** | CLAUDE.mdやAGENTS.mdのように、ツールが毎回読み込むファイル。壁に貼った決まりごとのようなものです。 |
| **Session**（セッション） | 開いてから閉じるまでの1つの会話。新しいセッションは、まっさらな机で始まります。 |

---

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

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

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

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

---

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

### 2.1 場所をとるもの

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

### 2.2 圧縮後に残るもの

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

| 内容の種類 | 圧縮後（文書による） |
|---|---|
| プロジェクトのルートの指示ファイル | ディスクから読み直される |
| 自動メモリ | ディスクから読み直される |
| 読んだ、または編集したファイル | 最近更新された最大5つが読み直される。大きすぎるファイルはパスだけ戻る |
| パスで範囲を絞ったルール、サブフォルダの指示ファイル | 必要に応じて読み直される。以前読み込まれた内容は要約されて消えることがある |
| 会話の中で口頭で伝えた指示 | 要約の中に入る。初めのほうの細部は失われることがある |

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

**教訓：**長く守らせたいルールは、**机の上の紙の山**ではなく**壁に貼る決まりごと**に属します。その決まりごとの書き方は、[AGENTS.mdの書き方](https://www.stacklogs.io.vn/ja/gijutsu/agents-md-no-kakikata/)を参照してください。

---

## 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回でできています。

```python
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. いつ何をするか：整理、圧縮、分割、やり直し

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

| 状況 | 行動 | 根拠 |
|---|---|---|
| 無関係な作業に移る | 会話をクリアする（`/clear`） | Claude Codeの文書：古い会話が次に必要なファイルの場所を奪い、メッセージごとにトークンを使う |
| 同じ作業だが長く、満杯に近い | 指示つきで圧縮する（`/compact focus on <話題>`） | Claude Codeの文書：ツールの推測ではなく、あなたが選んだものを要約に残せる |
| 調べるためだけに多くのファイルを読む必要がある | サブエージェントに任せる | 文書：ファイルの内容はサブエージェントの机に残り、返ってくるのは要約だけ |
| ルールが何度も忘れられる | プロジェクトのルートの指示ファイルに入れる | 文書：このファイルは圧縮後に読み直される |
| 同じ誤りを何度直しても直らない、またはエージェントが堂々巡りを始める | 引き継ぎメモを書いて新しいセッションを開く | 私自身の経験則で、測定はない |
| 翌日に続きをする | 新しいセッションと引き継ぎメモ | 文書：新しいセッションはまっさらなウィンドウで始まる |

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

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

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

---

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

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

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

「未確認または仮定」の欄は、[AIの結果に証拠を求める5つの方法](https://www.stacklogs.io.vn/ja/gijutsu/ai-no-kekka-ni-shoko-wo-motomeru-5tsu-no-hoho/)から取っています。実行したことと推測にすぎないことを分けておけば、新しいセッションが推測を事実として扱わずにすみます。エージェントに下書きを頼み、そのあと**自分で読んで直す**ことができます。AIが書いた要約にも、抜けや誤りがありうるからです。

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

```text
/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つの失敗](https://www.stacklogs.io.vn/ja/keiken/agent-eno-irai-no-shippai-7tsu/)も参照してください。

---

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

| 状況 | 仕組み | 見抜き方 |
|---|---|---|
| 圧縮で大事な細部が失われる | 要約はツールが重要と判断したものを残す | 指示つきで圧縮する。必須の細部は指示ファイルか引き継ぎメモに入れる |
| 引き継ぎメモに誤りがある | AIが書いた下書きには抜けや誤解がありうる | 自分で読み、仮定に印をつけ、再実行コマンドで確かめる |
| やり直しが早すぎる | エージェントがファイルを読み直す手間とトークンがかかる | 5.1のサインが出たときだけにする |
| サブフォルダに結びついたルールが要約で消える | 必要に応じて会話履歴に読み込まれるため | 必須のルールはルートの指示ファイルに置く |
| 大きなウィンドウで十分だと思う | 入力が長いと精度が落ちうる | それでも整理し、調べものはサブエージェントに任せる |
| 巨大なファイルや出力ですぐ満杯に戻る | 自動圧縮が数回で止まることがある | トラブルシューティングの文書を見る。ファイルを分け、サブエージェントを使う |

---

## 9. 使った数字と文書

| 出典 | 内容 | 読み方 | 注意 |
|---|---|---|---|
| Liuら、2023年7月（v3は2023年11月） | 情報が先頭か末尾にあるときに性能が最も高く、中ほどで下がる | 長い入力の中での位置が影響する | 2023年当時のモデル。概要ページにモデル名なし |
| Chroma、2025年7月14日 | 18モデル。入力が長いほど信頼性が低下 | 長いほど良いとは限らない | 1社の報告。課題は実際より単純。仕組みの説明なし |
| Anthropic、2025年9月29日 | コンテキストは有限の資源。圧縮、外部メモ、サブエージェントを提案 | 実践の根拠 | ツールを売る会社の見解 |
| Claude Codeの文書（How Claude Code works、Explore the context window） | 最初に読み込まれるもの、圧縮後に残るもの、`/clear`、`/compact`、`/context`の使い方 | 第2節と第5節の根拠 | コマンド名と挙動はバージョンで変わる |

**正しく読むために：**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](https://arxiv.org/abs/2307.03172)（arXiv、2023年7月、第3版は2023年11月20日）
- Hong、Troynikov、Huber（Chroma）、[Context Rot: How Increasing Input Tokens Impacts LLM Performance](https://www.trychroma.com/research/context-rot)（2025年7月14日）
- Anthropic、[Effective context engineering for AI agents](https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents)（2025年9月29日）
- Anthropic、Claude Codeの文書：[How Claude Code works](https://code.claude.com/docs/en/how-claude-code-works) と [Explore the context window](https://code.claude.com/docs/en/context-window)