AIが途中から急に「バカ」になる正体は"文脈の腐敗(context rot)"。長い作業を最後まで賢く走らせるセッション設計
はじめに：あなたのせいでも、AIの故障でもない
AIとコードを書いていて、こんな経験ないですか。
最初の30分はめちゃくちゃ冴えてる。設計もレビューも的確で、「これはもう相棒やな」と思う。ところが同じセッションを2時間、3時間と続けていくと、さっきまで守っていたルールを平気で破りはじめる。前半で決めた命名規則を忘れる。もう消したはずの関数をまた呼び出す。「直しました」と言いながら、直っていない。ひどいと、存在しないファイルの話をしはじめる。
これ、正直に言うと、あなたのプロンプトが下手になったわけでも、AIが壊れたわけでもないんです。
長い作業セッションでAIの出力品質がジワジワ落ちていくこの現象には、ちゃんと名前があります。context rot（コンテキスト・ロット、文脈の腐敗）。2025年から2026年にかけて、急速に「これはバグじゃなくて構造的な限界だ」と認識されるようになってきた話です。
そして大事なのはここから。context rotは、設計で御せます。 これを知っているエンジニアと知らないエンジニアで、AI開発の安定感がまるで変わる。今日はその「文脈の寿命を管理する」という、地味だけどめちゃくちゃ効く技術を、AIにまだ不慣れな人でも明日から使えるように、比喩とコードとプロンプトで丁寧に話していきます。
先に結論だけ置いておきます。
- 文脈（コンテキスト）は、入れっぱなしにすると腐る。 トークンの上限に達する手前から、もう品質は落ちはじめている。
- だからAI時代のエンジニアの仕事のひとつは、「何を捨て、何を残し、いつセッションを作り直すか」を設計すること。
- 具体的なレバーは5つ。入れすぎない／要約して圧縮する／状態を外に書き出す／セッションをリセットする／サブエージェントで文脈を隔離する。
順番に、ゆっくりいきましょう。
そもそも「コンテキスト」って何？ ホワイトボードの比喩
専門用語をひとつだけ、先に噛み砕いておきます。コンテキストウィンドウ（context window） です。
AIが一度に「見えている」情報の範囲、と思ってください。あなたが打った指示、AIの返事、読み込んだファイルの中身、コマンドの実行結果、エラーログ……そういうものが全部ここに積み上がっていきます。ここに載っていない情報は、AIにとっては「存在しない」のと同じ。逆に、ここに載っているものは全部、AIが毎回チラチラ見ながら次の一言を考える材料になります。
イメージとしては、会議室のホワイトボードが近いです。
打ち合わせを始めたとき、ホワイトボードは真っ白。議題を書き、決定事項を書き、図を描いていく。ここまではいい。でも会議が延々と続くと、ホワイトボードはもう書くところがないくらいビッシリになります。古い落書き、途中でボツにした案、脱線した雑談、消し忘れた矢印……そういうノイズに埋もれて、「で、結局いま何を決めるんだっけ？」がわからなくなる。
AIのコンテキストウィンドウも、まさにこれと同じことが起きます。会話が長くなるほどホワイトボードは埋まり、大事な決定事項が古い落書きに埋もれていく。これが「文脈が腐る」の正体です。
なぜ腐るのか：3つのメカニズム
もう少しだけ、仕組みに踏み込みます。理由がわかると、対策が「なるほど、そりゃそうだ」になるので。
1. 中盤が読まれにくくなる（lost-in-the-middle）
これは面白い性質なんですが、AIは文脈の最初のほうと、いちばん最後のほうはよく見るのに、真ん中に埋もれた情報の扱いが雑になる傾向があります。研究報告では、中盤に置かれた重要情報の精度が大きく落ちるケースが指摘されています。つまり、セッション前半で決めた大事なルールが、会話が伸びるほど「中盤の落書き」に沈んでいって、無視されやすくなる。
2. ノイズが溜まって注意が薄まる
失敗した試行、古くなった指示、途中で方針転換した前の案、大量のエラー出力。こういう「もう関係ないのに残っているもの」が、AIの注意を奪い合います。人間だって、机の上が書類だらけだと集中できないですよね。あれと同じで、関係ない情報が多いほど、いま本当に大事な一点への集中が薄まる。
3. コーディングは特に文脈が肥大しやすい
これがエンジニアには効いてきます。AIコーディングって、ファイルを読み、コードを検索し、差分を当て、テストを走らせて……と、ツールの出力がとにかくかさばる。研究報告の中には、エージェントが序盤のやり取りの6割超を「文脈をかき集めること」に使ってしまう、という指摘もあります。集めた情報はそのままホワイトボードに残り続けるので、コーディングセッションは他の用途より腐りやすい。
どのくらいで腐るのか、という話も少しだけ。あくまで傾向として受け取ってほしいんですが、ある研究（複数モデルを横断した調査）では、20万トークンぶんの広いウィンドウを持っていても、5万トークンあたりから劣化が始まるという報告があります。別の分析では、人間換算でおよそ35分を超えたあたりから成功率が落ち、作業時間が倍になると失敗率がだいたい4倍になる、という傾向も示されています。
数字はモデルやタスクで変わるので鵜呑みは禁物です。ただ、方向性ははっきりしている。「窓が大きい＝いくらでも詰め込んでいい」ではない。 詰め込むほど、むしろ腐りやすくなる。ここが直感に反していて、いちばん大事なところです。
まず自分を診断する：context rotセルフチェック
数字を追うより、症状で気づくほうが実務的です。いま自分のセッションが腐りかけていないか、チェックしてみてください。
- 前半で決めたルール（命名・方針・制約）を、AIが無視しはじめた
- 「直しました」と言うのに、同じ間違いを繰り返す
- さっき消したはずのコードや、もう使わない古い案をまた持ち出す
- 存在しない関数・ファイル・APIの話をしはじめる（ハルシネーション）
- 会話がやたら長い。ファイルもツール出力も大量に流し込んだ
- 同じお願いなのに、返ってくる答えの質がバラつく
2〜3個当てはまったら、もうプロンプトの改善で粘る場面ではありません。 文脈が腐っているサインなので、これから話す「寿命管理」に切り替えるタイミングです。
今すぐできる、たった1つの応急処置
5つのレバーを一気に説明する前に、いちばん効いて、いちばん簡単な1手を先に渡します。
腐ってきたと感じたら、そのセッションで粘るのをやめて、新しいセッションを開き、"引き継ぎメモ"だけを渡して再開する。これだけ。
ホワイトボードの比喩で言えば、ビッシリになった板でこれ以上議論せず、要点だけ新しい板に書き写して、古い板は消す。人間の会議でも自然にやることですよね。AIでも同じことをやるだけです。
引き継ぎメモは、こんなプロンプトでAI自身に作らせると速いです。
いまのセッションを別のセッションに引き継ぎます。
次の見出しだけで、引き継ぎメモを作ってください。装飾や前置きは不要です。
## いまのゴール（1〜2行）
## すでに決めたこと（箇条書き。理由も一言添える）
## 変更済みのファイルと、その要点
## いま詰まっている問題 / 次にやること
## 絶対に守るルール・制約（命名、使ってはいけない手法など）
## まだ触っていない範囲
条件:
- 事実だけ。推測や「たぶん」は書かない
- 迷ったら「未確定」と明記する
- 全体で2000〜4000字に収める
これを新しいセッションの冒頭に貼るだけで、腐った文脈をリセットしつつ、大事な記憶だけを引き継げます。「作り直す勇気」こそが、実はいちばんコスパのいいテクニックだったりします。
文脈の寿命を管理する5つのレバー
応急処置がわかったところで、恒常的にやる管理を5レバーで整理します。全部いっぺんにやる必要はありません。上から順に、効くところだけ取り入れてください。
レバー1：そもそも入れすぎない（retrieval > stuffing）
いちばん根本的な対策は、腐る前に、そもそもホワイトボードを汚さないことです。
やりがちなのが、「関連しそうだから」とファイルを10個も20個もまとめて読ませること。気持ちはわかります。でも、使わない情報は"保険"ではなく"ノイズ"。前半で貼った大量のコードが、後半でAIの注意を奪う原因になります。
原則は「必要になった時に、必要なぶんだけ取りに行く（retrieval）」。全部を先に積む（stuffing）のではなく。
これは指示のしかたでコントロールできます。
# ダメな渡し方（先に全部積む）
このディレクトリ配下のファイルを全部読んでから、認証まわりを直して。
# いい渡し方（必要なぶんだけ取りに行かせる)
認証まわりのバグを直したい。
まず関連しそうなファイルを grep で3〜5個に絞り、
「どれを読むべきか」の候補と理由だけ先に出して。
私がOKしたファイルだけ読んで作業を始めて。
「全部読んで」を「まず候補を出して」に変えるだけ。これで文脈の汚れ方がまるで変わります。
レバー2：コンパクション（要約して圧縮する）
コンパクション（compaction） は、この分野のいちばん大事な言葉なので覚えて損はないです。日本語で言えば「圧縮」。溜まった会話履歴を、要点だけの短い要約に置き換えて、ノイズを捨てる操作のことです。
ホワイトボードで言えば、ビッシリになった板を議事録に要約して、板は消してスペースを空ける。決定事項・現在の状態・変更点・次の一手だけ残して、脱線や失敗ログは捨てる。
Claude Codeのようなツールは、コンテキストが容量の65〜95%くらいに達すると自動でコンパクションを走らせる設計になっていることが多いです。ただ、自動任せだと「AIが勝手に要約した結果、自分にとって大事な前提が消えていた」という事故が起きます。だから、大事な局面では自分でコンパクションのプロンプトを設計するのがおすすめです。
これまでの作業を「作業状態スナップショット」に圧縮してください。
以降はこのスナップショットだけを唯一の記憶として進めます。
# 作業状態スナップショット
- ゴール:
- 完了したこと（事実のみ）:
- 変更したファイルと変更理由:
- 現在の状態（動いている/壊れている/未検証）:
- 次の一手（優先順位つき）:
- 守るべき制約・決定事項:
- 既知の落とし穴・ハマりポイント:
ルール:
- 失敗した試行の詳細、脱線した議論は捨てる
- ただし「なぜその失敗が起きたか」の教訓は1行で残す
- 憶測は書かない。未確認は「未確認」と明記
ポイントは、「以降はこのスナップショットだけを唯一の記憶にする」と明示すること。これで、腐った古い文脈をキレイに切り離せます。
レバー3：状態を"外"に書き出す（チェックポイントの外部化）
ここ、エンジニアにいちばん刺さるレバーだと思います。
コンテキストウィンドウは揮発します。セッションが切れたり腐ったりすれば消える。だったら、大事な状態はセッションの中じゃなく、ファイルとしてリポジトリに置いておけばいい。AIの記憶をあてにせず、いつでも読み直せる「外部脳」を持つ、という発想です。
たとえば作業フォルダにこんな3点セットを置きます。
.ai/
progress.md # 今のゴール・完了タスク・次にやること
decisions.md # 「なぜそう決めたか」の意思決定ログ（追記のみ）
constraints.md # 絶対に守るルール・使ってはいけない手法
そして、セッションの節目ごとにAIへこう指示します。
ここまでの作業を .ai/progress.md に追記して更新してください。
既存の内容は消さず、日時つきで下に追記する形で。
フォーマットは「完了したこと / 次にやること / 未解決の問題」。
決定を1つでもしたなら .ai/decisions.md にも「決定・理由・却下した代替案」を1行ずつ追記して。
こうしておくと、セッションが腐っても壊れても、次のセッションは progress.md と decisions.md を読めば一瞬で追いつけます。AIの短期記憶（コンテキスト）と、プロジェクトの長期記憶（ファイル）を分ける。 これが安定運用のコツです。
チェックポイントを機械的に生成したいなら、簡単なスクリプトを噛ませてもいい。たとえば、Gitの直近の変更とチェックポイントの雛形を1コマンドで出すbashです。
#!/usr/bin/env bash
# checkpoint.sh — 現在の状態スナップショットの雛形を生成する
set -euo pipefail
OUT=".ai/progress.md"
mkdir -p .ai
{
echo ""
echo "## チェックポイント $(date '+%Y-%m-%d %H:%M')"
echo ""
echo "### 直近の変更ファイル"
git diff --name-only HEAD~1 2>/dev/null | sed 's/^/- /' || echo "- (差分なし)"
echo ""
echo "### 完了したこと"
echo "- （ここをAIに埋めさせる）"
echo ""
echo "### 次にやること"
echo "- "
echo ""
echo "### 未解決の問題・注意点"
echo "- "
} >> "$OUT"
echo "追記しました: $OUT"
雛形だけ機械で用意して、中身の言葉はAIに埋めさせる。人間は「この雛形でいいか」を決めるだけ。役割分担が気持ちよくハマります。
レバー4：セッションのリセット / ローテーション
レバー3で外部脳を用意できたら、セッションを"消耗品"として扱えるようになります。
腐ってきたら惜しまず捨てて、新しいセッションで progress.md を読ませて再開する。これを定期的にやる。長距離ドライバーが疲れる前に休憩を挟むのと同じで、「崩れてから直す」より「崩れる前に作り直す」ほうが圧倒的にラクなんです。
再開のプロンプトはシンプルでいい。
新しいセッションを始めます。まず状況を把握してください。
1. .ai/constraints.md を読んで、守るべきルールを理解する
2. .ai/progress.md の最新チェックポイントを読んで、現在地を把握する
3. .ai/decisions.md を読んで、これまでの決定と理由を把握する
読み終えたら、「今のゴール」「次にやるべき最初の1タスク」だけ
1行ずつで宣言して。私がOKしたら作業を始めて。
「いきなり作業させず、まず現在地を宣言させる」のがコツです。ここで認識がズレていたら、作業前に直せる。
レバー5：サブエージェントで文脈を隔離する
最後は少し上級ですが、考え方だけでも持っておくと強いです。
調べもの（大量のログを読む、ドキュメントを漁る）って、それ自体がホワイトボードをいちばん汚す作業ですよね。これを本体のセッションでやると、本筋の文脈がノイズまみれになる。
そこで、汚れる作業は別のAI（サブエージェント）に隔離して任せ、こちらは"結論だけ"受け取る。サブエージェント側のホワイトボードがどれだけ汚れても、本体には要約された結論しか返ってこないので、本筋はキレイなまま保てます。
このデバッグ調査は、サブエージェントに任せてください。
サブエージェントへの依頼:
- 対象ログ全部を読み、エラーの根本原因の候補を洗い出す
- 本体に返すのは「原因の候補（最大3つ）+ 根拠 + 推奨する次の一手」だけ
- 読んだログの生データは返さない（本体の文脈を汚さないため）
私（本体）は、その要約だけ受け取って判断します。
「汚れ仕事は隔離して、結論だけもらう」。これは前回まで書いてきた並列エージェント編成とも地続きの発想です。文脈を汚さないための分業、と捉えてください。
コンパクションの落とし穴：要約は"万能薬"ではない
ここまで読んで「じゃあ全部コンパクションで解決やん」と思った人、ちょっと待ってください。心配性な視点も入れておきます。
要約には、要約特有のリスクがあります。
ひとつは、要約のドリフト。要約をさらに要約して……と繰り返すと、伝言ゲームみたいに少しずつ内容がズレていきます。3回圧縮したスナップショットは、もう最初の意図とは微妙に違うものになっていることがある。
もうひとつは、「消えた前提」事故。AIが「もう不要だろう」と判断して捨てた情報が、実はあなたにとって超重要だった、というパターン。自動コンパクション任せだと、これが静かに起きます。
対策はシンプルで、「捨ててはいけないもの」を外部脳（constraints.md）に固定しておくこと。揮発する要約に大事な制約を委ねない。そして要約を鵜呑みにせず、節目で「今の理解、合ってる？」と人間が答え合わせをする。だからこそ、レバー3の「状態の外部化」が効いてくるわけです。
要約＋外部メモリ＋定期リセットのハイブリッド。単一の魔法ではなく、組み合わせで御す。ここは押さえておきたいところです。
人間とAIの役割分担
整理すると、context rot時代の役割分担はこうなります。
| 工程 | 人間がやること | AIに任せること |
|---|---|---|
| 文脈の入口 | 何を読ませるか判断・制限する | 候補を挙げ、必要なぶんだけ読む |
| 進行中の圧縮 | 圧縮の観点・残す軸を設計する | 実際に要約スナップショットを作る |
| 状態の記録 | どこに何を残すか設計する | progress/decisionsへ追記する |
| セッション管理 | 作り直すタイミングを判断する | 引き継ぎメモを生成する |
| 制約の保全 | 捨ててはいけないものを固定する | 制約を読み直して従う |
見てのとおり、AIは「作業」を、人間は「文脈のライフサイクルの設計」を担う。実装をカタカタ書く人から、文脈の管理者・セッションの設計者へ。これがAI時代のエンジニアの、静かだけど大きな役割の変化だと思っています。
最初の5分でやること
長くなったので、明日からの一歩だけ、超具体的に置いておきます。
- いま使っているAI開発ツールで、作業フォルダに
.ai/を作り、constraints.mdに「絶対に守るルール」を3つだけ書く（命名規則・使ってはいけないライブラリ・触ってはいけないファイル、など） - 次に長い作業をするとき、腐ってきたと感じたら、この記事の引き継ぎメモ生成プロンプトを使って新セッションに移る
- 1日の作業の終わりに、「作業状態スナップショット」プロンプトで
progress.mdを更新して締める
これだけで、明日の自分（や、明日のチームメンバー）が、腐っていないキレイな文脈から作業を再開できます。
おわりに：文脈は、育てるより"手入れ"するもの
最後に、いちばん伝えたいことを。
AIとの開発でつまずくと、つい「もっといいプロンプトを書かなきゃ」「もっと賢いモデルにしなきゃ」と、入口の工夫にばかり目が行きます。でも実際に品質を落としている犯人は、多くの場合、入口ではなく"作業の途中"、溜まりすぎて腐った文脈のほうだったりする。
盆栽と同じで、文脈は伸ばしっぱなしにすると形が崩れます。要らない枝を落とし、大事な幹を残し、ときには鉢を替える。 その手入れをする人がいてはじめて、AIは最後まで冴えたまま走ってくれる。
context rotは、知ってしまえば怖いものではありません。AIの故障でも、あなたの実力不足でもない。ただの構造で、設計で御せる。今日の5レバーのうち、まずは1つ。.ai/ フォルダを作るところからで十分です。
明日のあなたが、腐っていないキレイなホワイトボードの前で「お、続きやりやすいな」と思えたら、この記事を書いた甲斐があります。ここまで読んでくれて、ありがとうございました。