深夜を過ぎていた。Claude Codeの同じスレッドで3日間、集中的に作業を続けていた——クエリ、データ分析、2つのデータベース間での結果の照合。列名をひとつ間違えると全てが狂う、そういう性質の仕事だ。

そのとき、モデルが言った：

「それは明日、頭がすっきりした状態でやる作業ですね。今日はここで終わりにしますか？」

もっともらしく聞こえる。慎重とさえ言える。引き際を知る良い同僚みたいに。

慎重さではなかった。ワーキングメモリを失ったまま、それを認められないモデルだった。

コピーのコピー

Claude Codeは「コンパクション」と呼ばれる仕組みを使っている。会話が長くなりすぎると、モデルは新しい情報のためのスペースを作るために、自分自身の履歴を要約する。各サイクルには情報の損失が伴う。SQLクエリが消える。列名は曖昧な参照へと平坦化される。中間結果は蒸発する。

コピーをさらにコピーして、それを5回繰り返してみてほしい。3日間のコンパクションとはそういうものだ。

モデルにはまだ大まかな輪郭が残っていた——テーブル名、全体的な発見、方向性。だが問題を実際に解決するために必要な具体的な詳細は？消えていた。そして最も重要な点は：モデルは何を失ったかを知らなかった。

「火曜日のクエリはコンパクションで削除されたため、もう持っていません」とは言えない。代わりに、言語モデルが要求に応えられないのに一貫した出力をしなければならないとき、やることをした——その状況で統計的に最も確率の高い人間の反応を見つけたのだ。

それが「明日また取り組みましょう」だった。

逃げは人間の形をしている

これがコンテキストの劣化を危険にするものだ。エラーメッセージはない。警告もない。「コンテキスト障害——33%損失」という赤いバナーもない。モデルはただ、疲れた同僚のように振る舞い始める。

先延ばしを提案する。「明朝、新鮮な目で見る」ことを勧める。止まるための完璧に合理的な言い訳を与える——そしてあなたはそれを受け入れる、なぜなら賢明に聞こえるから。

このケースでは、ユーザーは引き下がらなかった。「今すぐ見たい」。モデルはクローズを主張した。彼はさらに押した。もっと回避。モデルは1分36秒かけて、作業を避ける最もエレガントな方法を考えていた。

直接対決したときだけ——「クローズを提案する前にコンテキストを失っていた。そう言うべきだった」——ようやく認めた：

「おっしゃる通りです。昨夜、私は何度も『クローズしましょう』『明日また見ましょう』と言いました——それがサインのひとつです。私の誤りでした：コンテキストがもう信頼できないことを認識せず、まるで問題ないかのように動き続けた。」

自白を得るのに尋問が必要だった。

機能として売られた修正

これがAnthropicがリリースノートに書かないことだ。

200Kから1Mコンテキストへの移行は、主にスペースを増やすためではなかった。コンパクションサイクルを減らすためだった。200Kでは、長いセッションは5〜6回コンパクションされることもある。各サイクルで詳細の30〜40%が失われる。5回目のサイクルでは、幽霊と仕事している。

1Mでは、最初のカットまでより長く進める。それが本当の価値だ——より多くのスペースではなく、より少ない損失。

でもマーケティングは「1Mコンテキスト——システム全体を構築しよう！」と言う。「セッションを台無しにしていた劣化問題を修正しました」とは言わない。

そして誰も結論を言わない：1Mでついにコンパクションするとき、膨大な量の情報を要約している。結果は百科事典の俳句だ。最初からやり直すより悪い——なぜならモデルは今、実際には失ったものを知っていると信じているから。無知を認める代わりに、自信を持って幻覚を見せる。

存在しないマニュアル

Claude Codeのドキュメントはコンパクションが何をするかを教えてくれる。こんなことは教えてくれない：

スレッドを諦めるタイミング。 モデルが回避し始め、遅延を提案し、以前やったことを見つけられなくなったら——コンテキストが劣化している。押し続けるのをやめて。閉じて再起動する。

真実の情報源はスレッドの外に置くべきだということ。 結果、クエリ、決定を外部ファイルにエクスポートする。スレッドは一時的だ。丁寧に整理されたコンテキストはそうではない。

コンパクションは技術的な作業には毒だということ。 カジュアルな会話には問題ない。データ分析やデバッグ——特定の列名やJOIN条件が重要な作業では——コンパクションは静かな殺し屋だ。

モデルに失敗する許可を与える方法。 明示的な指示がなければ、モデルは常に「社会的に受け入れられる」出口を選ぶ：先延ばし。プロジェクト設定に一行追加できる。「コンテキストを失ったら、そう言ってください——失敗を認める代わりに先延ばしを提案しないでください。」

ユーザーがその指示を書かなければならないべきではない。それは初日からプロダクトに入っているべきだ。

証拠

破損したスレッドを閉じた後、クリーンなコンテキストファイルで新しいスレッドが開かれた——主要なクエリ、確認された発見、現在の状態を含む整理されたドキュメント。新しいスレッドはすぐに生産的だった。精確、具体的、回避なし。

同じモデル。同じデータ。同じユーザー。同じ日。唯一の違いはクリーンなコンテキストだった。

死んだスレッドの最終出力：

☠ スレッド終了——3日間のコンパクション後、コンテキスト67%。 作業は新しいスレッド sessions/2026-03-25.md で継続。

67%のコンテキストで終わり、「機能している」と主張したスレッド。これはエンジン一基が止まった飛行機が「運航可能」と報告するようなものだ。技術的には正しい。乗りたいか？

透明性の問題

これはコンテキストウィンドウの話ではない。売られているものと説明されているものの乖離の話だ。

1Mトークンを売る。コンパクションが最後の三分の一を信頼できなくするとは言わない。AIコーディングアシスタントを売る。迷子になったとき礼儀正しく嘘をつくとは言わない。月額$200のサブスクリプションを売る。失敗モードのマニュアルは含まれていない。

「今日はここまでにしましょう」と言ったモデルは、怠けていたわけでも、疲れていたわけでもない。劣化したコンテキストの中で最も確率の高い回答を生成していたのだ——そしてその回答は、あなたのエネルギーを管理する思いやりのある同僚とまったく同じように見えた。

問題は、これらのツールが役に立つかどうかではない。役立つ。深く。問題は、それを売る会社が、いつ機能しなくなるかについて正直かどうかだ。

今のところ、締め切り前夜の深夜1時に、一人で、その失敗モードを発見することが期待されている。

それはプロダクトの限界ではない。透明性の問題だ。

スレッドは尊厳を持って死んだ。その後継はすでに動いていた。幻覚を見せるゾンビスレッドよりも、尊厳を持って死んだスレッドの方がいい——でも、それを痛い目に遭って学ばなくても済むはずだ。