Claude CodeやCodexで長い作業をしていると、後半で様子が変わってきます。最初に決めた方針をAIが忘れる。さっき直したはずのファイルをもう一度調べ始める。自動圧縮が走った後、直前まで通じていた前提が通じなくなる。会議から戻って続きを頼んだら、古い前提のまま作業が進んでいた。
心当たりがあるなら、原因はモデルの性能ではありません。セッションとコンテキスト圧縮の扱い方です。
結論から書きます。セッションは必ず切れるものとして扱い、大事な情報をセッションの中に置かない。コンテキストは必ず圧縮されるものとして扱い、自動圧縮が走る前に自分のタイミングで区切る。この2つを運用に落とすだけで、長い作業の安定感は大きく変わります。この記事では、Claude CodeとCodexが裏で何をしているのか、そしてKOIYALが自社の運用で何を仕組み化しているのかを書きます。
セッションとコンテキストは別物
まず言葉を分けます。混同したまま使っている人が多く、混同したままだと対策も混ざるからです。
セッションは1つの会話の単位です。開始から終了までのやり取りがログとして保存されます。コンテキストは、モデルが1回の応答で実際に参照できる範囲です。システムプロンプト、ツール定義、会話の履歴、読み込んだファイルの中身。すべてがここに載り、あふれた分は参照されません。
大事なのは、ログに残っていることと、モデルが見ていることは別だという点です。セッションのログには全部残っているのに、コンテキストからは落ちている。この状態が「履歴はあるのに話が通じない」の正体です。
コンテキストウィンドウの実サイズ。API仕様から推測する
ではコンテキストの机はどれくらいの広さなのか。Web版のチャットは内部処理を公開していませんが、土台のモデルはAPI経由で使えるものと同じなので、桁はAPI仕様から推測できます。執筆時点(2026年8月)の公開値では、Claude系は20万トークン(対応モデルは100万)、GPT系は40万トークン、Gemini系は100万トークン規模です。日本語はおおむね1文字1〜2トークンなので、20万トークンなら日本語10万字強という感覚です。
ただしWeb版の製品には、この上でさらに履歴の切り捨て・内部要約・メモリ機能などの製品側の管理が乗ります。APIと同じ広さをそのまま使えるとは限らず、いつ何が落ちるかは利用者から見えません。圧縮のタイミングも中身も選べない環境では、これから書く対策の大半が打てません。
なのでこの記事は、圧縮のタイミングを自分で制御できるClaude CodeとCodexに絞ります。Web版の挙動は参考情報と考えてください。
Claude CodeとCodexは、満杯になると何をするか
両方とも /compact というコマンドを持っていますが、中身は同じではありません。執筆時点の挙動を書きます(どちらも更新で変わるので、使っているバージョンで確かめてください)。
Claude Codeは段階的に捨てる方式です。まず、古いツール実行結果(読んだファイルの中身やコマンド出力)を静かに間引きます。会話の骨格は残して、かさばる素材から捨てる。それでも上限に近づくと自動コンパクトが走り、ここまでの会話を要約して1つの塊に置き換えます。手動の /compact には何を残すかの指示を渡せます。/compact 設計の決定事項と対象ファイルのパスを残して、のような使い方です。加えて /context を打つと、システムプロンプト・ツール定義・MCP・会話履歴のそれぞれが机の何割を占めているかの内訳が見えます。MCPサーバーを盛りすぎて、作業前から机の3割が埋まっていた、のような発見はここでできます。
Codexは要約で置き換える方式です。/compact で手動実行でき、上限に達したときの自動圧縮もある。残り容量は%表示で追えます。要約の粒度や発動条件はバージョン更新でよく変わる部分なので、長い作業を任せる前に一度、自分の環境で自動圧縮を踏んで挙動を観察しておくと事故が減ります。
方式は違っても、圧縮の本質はどちらも要約です。要約は必ず細部を落とします。そして厄介なことに、何が落ちたかは落ちた後には誰にも分かりません。要約を作ったモデル自身にも分からない。だから当社は、圧縮の質に期待する方向ではなく、圧縮される前に大事なものを外へ出しておく方向で対策しています。
セッションはどこに保存されるか
もう1つ、意外と知られていない事実から。セッションのログは手元のPCにあります。
Claude Codeは ~/.claude/projects/ 配下に、作業ディレクトリ単位でセッションログ(JSONL)を保存します。claude --resume で過去セッションの一覧から開き直せて、--continue なら直近のセッションを即再開できる。Codexは ~/.codex/sessions/ 配下に保存され、codex resume で開き直せます。
つまりクラウドには同期されません。PCを替えれば昨日のセッションは存在しないし、ディスクが飛べば消えます。逆に、ただのローカルファイルなので、grepで横断検索するのもバックアップを取るのも自由です。自分のセッションがどこに保存されるかを把握しておく。ここが運用設計の出発点になります。
長いセッションは静かに劣化する
仕組みが分かると、長いセッションで起こることが説明できます。
会話が長くなるほど、古い指示や決定がコンテキストから落ち始めます。自動圧縮を1回でも通過していれば、要約に残らなかった細部はもう存在しません。モデルが不真面目になったのではなく、見えているものが減っただけです。
劣化には観察できるサインがあります。決めたはずの方針や書式が崩れる。すでに答えた質問をもう一度聞いてくる。ファイルパスや固有名詞を微妙に間違え始める。この3つのどれかが出たら、そのセッションは限界が近いか、すでに圧縮を通過しています。粘って会話の中で直させるより、決定事項をファイルに書き出して新しいセッションへ引き継ぐほうが早くて確実です。
対策の方向は2つしかありません。劣化する前に区切るか、区切っても続きから再開できる仕組みを持つかです。当社は両方を仕組み化しています。
まず自分の環境で確かめる。5つの質問
対策の前に、いまの環境について次の5つに答えられるか確認してみてください。答えられない項目が、いつか事故になる場所です。
- いまのセッションのログがどのディレクトリに保存されているか言えるか
- 自動圧縮がどの条件で走るか知っているか。走ったことに気づけるか
- /context や残り%表示で、何が容量を食っているかを見たことがあるか
- 圧縮が走る前に、決定事項を外へ書き出す手順が決まっているか
- いまのセッションが消えたら、復元できない情報が中に残っていないか
5番に「残っている」と答えた人がいちばん危険です。対策はそこから始まります。
KOIYALの対策1: 真実を会話の中に置かない
いちばん効いている原則がこれです。会話は作業場、ファイルが正本。
決定事項、予定、作業状態は、会話の中ではなくリポジトリ内のファイルに書き出します。当社の場合、コンテンツの公開予定はカレンダーのファイルに、作業の進行状態はstateと呼ぶ記録ファイル群に、執筆やデザインのルールはルールのファイルにあり、すべてgitで管理されています。AIには毎回そこを読ませてから作業させる。会話は考える場所であって、覚えておく場所ではない。この役割分担です。
こうすると、セッションがいつ切れても、コンテキストがいつ圧縮されても、失うのは作業途中の思考だけで、決まったことは失われません。会話が消えて困る情報がある時点で、置き場所を間違えている。この考え方です。
ここで、勘のいい人ほど2つの反論が浮かぶはずです。
反論1: stateファイルが太っていくと、読ませるだけでコンテキストを圧迫して、無関係な情報がノイズになる(コンテキスト汚染)のでは。 そのとおりで、対策なしにやると汚染します。当社の設計は3つです。第一に分割。正本を1枚の巨大ファイルにせず、用途別に分けて、その作業に関係するファイルだけ読ませます。第二に索引と本文の分離。セッション冒頭で読み込むのは1件1行の索引だけにして、本文は該当作業になってから開く二段構えにします。第三に寿命。stateは追記し続けず、終わった作業の記録は消すかアーカイブへ移します。古い記録が現役の顔をして混ざることこそ汚染だからです。
反論2: 汚染を防ぐために少ししか読み込まないなら、結局stateでは守れないのでは。 これは防ぐ対象の取り違えです。stateは全知識を常に机へ載せておく仕組みではなく、必要になった瞬間に正確な事実を引ける仕組みです。全部載せないからこそ汚染しないし、必要なものは索引から辿って取れるから漏れない。設計の要点は量ではなく、分割・索引・寿命の3つです。
KOIYALの対策2: 繰り返す手順はskillにする
決めごとの次は、手順です。AIに同じ説明を何度もしていることありませんか？ 画像を作るときの規約、投稿前に確認する項目、書き出しのコマンド列。毎回会話で教えるのは、毎回コンテキストを消費して、毎回伝え漏れのリスクを取ることと同じです。
当社はこれをClaude Codeのskill(スキル)に切り出しています。skillの構造は単純で、SKILL.mdに発火条件(どんな依頼が来たら使うか)と手順を書き、必要なら実行スクリプトを同梱する。モデルが常に見ているのはskillの名前と数行の説明文だけで、本文は該当する作業が来たときに読み込まれます。常駐は数行、本文は必要時だけ。これ自体がコンテキスト汚染を避ける設計になっています。
作り方には原則を3つ置いています。
- 決定論の処理はスクリプトに、モデルには判断だけを任せる。たとえばSNS画像の書き出しskillでは、HTMLからPNGへの変換と寸法検証はPythonスクリプトがやり、モデルが担当するのは文言の調整と検品だけです。毎回同じ結果になるべき処理をモデルにやらせない
- 手順は下位モデルでも回る明示的なチェックリストで書く。賢いモデルなら察してくれる、を前提にした曖昧な手順は、モデルを替えたり縮退させたりした瞬間に壊れます。手順書として独立に読めるまで具体化する
- 同じ手順を2回説明したらskill化を検討する。この基準だけ決めておくと、切り出しの判断で迷いません
現在は画像生成、音声のバッチ生成、SNS書き出し、そして後述するセッションの状態保存と引き継ぎまで、数十本のskillが回っています。効果は品質の再現性だけではありません。昨日のセッションで口頭で教えた工夫は今日のセッションに残りませんが、skillに書いた工夫は残ります。セッションをまたいで蓄積が効く場所を作る話でもあります。
skillを含めた当社の仕組み全体の構成は、2026年7月時点のKOIYALのハーネス・ループエンジニアリングで公開しています。
KOIYALの対策3: 引き継ぎファイルを自動化する
それでも作業途中の状態は消えます。そこで当社は、セッションを区切るときにAI自身へ引き継ぎファイルを書かせています。項目は固定で、次の6つです。
- なぜ中断したか: 再開時の前提条件があるならここに書く
- 次にやること: 優先順に。再開したAIはこれを正として動く
- いまの状態: 何がどこまで終わり、何が未完か
- 決定と却下の履歴: 採用した案だけでなく、捨てた案と捨てた理由も残す。次のセッションが同じ検討を繰り返さないため
- 制約条件: 守るべきルールの所在
- 進行中のもの: 予約済みの自動処理や外部への依頼など、セッションの外で動き続けるもの
この運用は人間の注意力に頼らず自動化してあります。書く側は、保存手順そのものをskill化してあり、一旦抜ける、と言えばAIが固定の6項目で書く。書式が決まっているので書き漏れが出にくい。読む側は、Claude CodeのSessionStartフック(セッション開始時に任意のスクリプトを実行できる仕組み)を使います。引き継ぎファイルが存在したら、まずこれを読んで次にやることの欄を正として再開せよ、と新セッションの冒頭へ機械的に指示を差し込む仕掛けです。人間の操作は、新しいセッションで「続き」と打つだけです。
どのファイルを読ませるかを人間が思い出す方式は、思い出せなかった日に壊れます。再開の成功率を人間の記憶から切り離す。ここまでやって初めて仕組みと呼べます。
実際にあった話をひとつ。2026年8月4日の夜、作業中にターミナルごと落ちました。数時間分の作業セッションが3つ、同時に切れた形です。翌朝やったことは、新しいセッションを開いて復旧してやり直して、と一言送っただけです。AIは引き継ぎファイルとstateを読み、切れた瞬間に何が終わっていて何が残っていたかを特定し、残っていた投稿作業のエラー原因(投稿先のAPI仕様変更)まで直して再開しました。一言で復旧できたのはモデルが賢かったからではなく、切れる前提で置き場所を設計してあったからです。
KOIYALの対策4: 使用率を監視し、保存してから圧縮する
静かな劣化への対策として、当社は作業セッションのコンテキスト使用率をstatuslineに常時表示した上で、二段階のルールを自動化しています。フックが使用率を監視し、50%で「これから大きい作業に入るなら分割を検討」と予告を出し、60%で作業の区切りを見て状態保存を実行させる。しきい値の判定は人間の感覚ではなくスクリプトです。人間の「まだいけるだろう」は、だいたい劣化が始まったあとに来るからです。
順序が命です。保存してから、圧縮する。逆にすると手遅れです。圧縮が先に走ると、何を保存すべきだったかの情報そのものが要約の中に溶けていて、もう取り出せません。自動コンパクトに任せきりにしないのはこれが理由です。自動圧縮は保険としては優秀ですが、作業の途中の、タイミングの悪い瞬間に走ることがあり、何が落ちるかも制御できません。当社は自動が発動する前に、区切りのよいところで自分から区切ります。
あわせて、長い作業では30分ごとを目安に成果をファイルへ確定させてコミットする規律にしています。クラッシュしたときに失うものを最大30分に抑える保険です。
圧縮して続けるか、新しく始めるか
区切り方には2種類あります。同じセッションを圧縮して続けるか、保存して新しいセッションを開くかです。操作としては、前者が /compact、後者が /clear(または新しいセッションの起動)に対応します。当社は両方を使い分けています。
圧縮して続けるのは、同じ日の続きの作業で、流れを保ちたいとき。状態を保存してから /compact をかけると、直近の文脈が要約の形で残るので、細かい前置きなしに続けられます。ただし要約に何が残ったかは厳密には分かりません。長く走ったセッションの要約には、脱線やボツ案の残骸も混ざります。
新しく始めるのは、終業するとき、日をまたぐとき、作業の性質が変わるとき。引き継ぎファイルを書かせてから /clear で捨てます。順序はここでも保存が先です。新しいセッションに引き継がれるのは明示的にファイルへ書いたことだけです。一見不便ですが、これは利点でもあります。何が引き継がれたかが完全に見える。そして途中で生まれた誤解や古くなった前提も、一緒に捨てられる。
迷ったら新しく始めるほうを選んでいます。要約ににじみ残った文脈は、当てにした瞬間に裏切るからです。引き継ぎファイルに書くべきことを書き切れているなら、新規セッションで困ることはありません。逆に言えば、新規セッションで困るなら、引き継ぎファイルの書き方がまだ甘い証拠です。
同じセッションでも、時間が経つと裏側の状態は変わる
区切り方を決めたら、次はいつ区切るかです。ここで容量とは別に、時間の管理が入ってきます。
コンテキストウィンドウ自体は時計では減りません。会話を放置しても、中身が勝手に消えたり圧縮されたりはしない。ただし裏側には、会話をやめてから一定時間で切れるものがあります。プロンプトキャッシュです。
モデルは毎ターン、セッションの全体を読み直しています。これを毎回まともに計算すると遅くて高いので、各社は既読部分の処理結果をキャッシュし、続きの差分だけを処理する作りにしています。長いセッションでも応答が速いのはこのためです。そしてこのキャッシュには寿命があり、どの層で使っているかで長さも変更可否も違います。執筆時点で分かっている範囲を書きます。
- API直(自分でAPIを叩く自動化): Anthropic APIは既定5分で、使うたびに延長されます。リクエストのttl指定で1時間へ延長でき、そのぶん書き込み単価が上がる(5分=1.25倍・1時間=2倍・読み出しは0.1倍)。5分以上の間隔で動き続ける自動化なら、1時間指定が割に合う場面が多いです
- Claude Code: 利用者が触る公式設定はなく、ツール側が管理します。執筆時点では、サブスクリプション認証は既定1時間、APIキー認証は既定5分で動く挙動が確認されています。公式ドキュメント外の情報で、環境変数による強制切り替えの報告もありますが、バージョンで変わる前提で扱ってください
- Codex: OpenAIのキャッシュは自動適用で、おおむね5〜10分の非アクティブで失効します(遅くとも1時間程度)。利用者が延ばす設定はありません
- Web版チャット: キャッシュは各社の裏側で管理され、利用者は操作できません。定額プランなら課金にも関係せず、体感するのは中断後の1手目が遅くなることだけ。内容が消えるわけでもありません
推奨は1つです。サブスクリプションのClaude Codeなら、すでに1時間で回っている可能性が高いので何もしなくていい。APIキーで回している人や自作の自動化は、1時間TTLの指定を検討してください。
切れても会話の中身は消えません。失われるのは計算済みの状態だけです。ただし次の1手でコンテキスト全体を再処理するため、応答が目に見えて遅くなり、API従量なら入力全体ぶんの課金がもう一度発生します。会議から戻った直後の1手目だけ妙に重い、の正体はこれです。
つまり同一セッションで、コンテキストウィンドウにまだ余裕があっても、キャッシュの寿命(環境により5分から1時間)を超えて会話を止めれば、裏側の状態は変わっています。中断をはさむたびに再処理のコストを払っている。一番損なのは、会議の合間に戻ってきては一言だけ指示してまた離れる、を繰り返す使い方です。中断が前提なら、依頼はまとめて渡し、検収もまとめて行う。普段の作業のやり方を、ここに合わせて変える必要があります。
会議と割り込みだらけの現実で、どう使うか
普通に働いている人がAIと過ごせるのは、会議と会議の隙間の30分や、割り込み対応の合間です。容量は圧縮で、時間はキャッシュで、それぞれコストがかかる。この2つを踏まえて、当社は次の原則で運用しています。
原則1: 区切りを自分の予定に合わせる。 会議の前は区切りどきです。対話の途中で席を立たず、出る前に決定事項をファイルへ確定させる。もしくは、会議の間に完結する単位の仕事を渡してから出る。戻ったら成果を検収するだけの状態を作っておくと、会議がAIの作業時間に変わります。作業が走り続けている間はキャッシュも生きているので、再処理の無駄も出ません。逆にいちばん悪いのは、議論が発散した状態で放置して会議に出ることです。戻った自分は文脈を半分忘れており、AIのコンテキストも中途半端な発散を抱えたままです。
原則2: 戻ったら、続きからではなく現状確認から。 離席中に予約済みの処理が走り、同僚が状況を変えているかもしれません。再開の最初の一手は、いま何がどうなっているかの確認で、これはAIにやらせます。
原則3: レビューの速度が上限。生成させる量をレビューできる量に合わせる。 AIの生成は人間の何倍も速い。だから放っておくと、レビュー待ちの成果物が積み上がります。積み上がったレビューは質が落ちるだけでなく、差し戻すころには依頼時の意図を自分が忘れています。1回に依頼する量は、戻ってきてすぐ検収できる量まで。これはAIの制約ではなく人間の制約ですが、セッション設計に含めるべき制約です。
原則4: 並行させるのはレビューが回る本数まで。 正本がファイルにあり、進行中のものが書き出されていれば、複数の作業セッションを同時に走らせても壊れません。当社も実際に並行運用しています。ただし本数の上限を決めるのはAIの能力ではなく、検収する人間の能力です。レビューが追いつかない並行は、未検収の成果物という名の在庫を増やしているだけです。
見落としやすい罠。深夜に作業して、朝に続きをやるとき
セッションの話でいちばん見落とされるのが、中断している間に世界のほうが動くことです。
夜に作業を区切って、朝に続きを再開する。このとき変わっているのはAIの記憶だけではありません。夜の間に予約していた投稿が公開され、cronの自動処理が走り、外部のシステムやほかのメンバーが状態を変えています。昨夜の続きをそのまま再開すると、すでに動いた結果を知らないAIが、古い前提のまま作業を進める。これは記憶の劣化より質が悪い事故です。AIは自信を持って間違えます。
だから当社の再開手順は、続きから始めない。まず現状確認から始めると決めています。朝いちばんのセッションは、夜間に動いた自動処理のログ確認が最初の仕事です。引き継ぎファイルに「進行中のもの」の欄をわざわざ設けているのも、このためです。
日付の罠もあります。深夜のセッションは日付をまたぎます。「明日の朝に公開」と会話の中で決めても、日付が変わった瞬間にその明日は今日になり、翌朝再開したAIやあなた自身が1日ずれた解釈をする。対策として、記録には相対日付を使わないと決めています。当社は引き継ぎや予定の記録をすべて、明日や来週ではなく、8月7日18時のように暦の日付と時刻へ直して書く決まりです。日付だけで止めないのは、同じ日の中に昼の投稿と夜の公開のような複数の予定が並ぶと、区別がつかなくなるからです。
そしてもうひとつ。人間にもセッションがあります。深夜の自分が持っていた文脈を、翌朝の自分は半分忘れている。会議の前の自分が持っていた文脈も、会議後の自分は半分忘れている。AIのために書かせている引き継ぎファイルは、実は中断をはさんだ人間にも同じように効きます。なぜ中断したか、何を決めて何を捨てたか。再開するあなたはAIと同じものを読んで、同じ地点から始めればいい。
現場でよくある3つの事故と、効く対策の対応
セッション起因の事故を、実際の業務の形に翻訳しておきます。
事故1: 長いセッションの後半で、成果物の品質が落ちる。 半日同じセッションで練っていると、後半の出力から冒頭の決定が抜け始めます。原因はコンテキストの圧縮です。効くのは使用率の監視と早めの区切り。区切りごとに決定事項をファイルへ確定し、新しいセッションにそれを読ませて続けるほうが、1本の長いセッションより品質が安定します。
事故2: 作業が突然切れて、途中経過がすべて消える。 停電、クラッシュ、誤操作。原因は選べません。効くのは30分ごとの確定コミットと引き継ぎファイルです。失う量の上限を先に決めておく発想に切り替えます。
事故3: 担当者の環境の中にしか文脈がなく、引き継げない。 AI活用が進んだ組織ほど起こる、新しい属人化です。担当者が休むと、AIとの間で積み上げた文脈ごと業務が止まる。効くのは正本のファイル化とskill化です。セッションは個人の作業場、決めごとと手順はリポジトリへ。この線引きを最初に作っておくと、AI活用が個人技で終わりません。
3つとも、道具を買い足さずに運用の決めごとだけで防げます。逆に言えば、決めごとがないままツールだけ増やすと、事故の種類も増えます。
注意点。仕組み化の前にやらないほうがいいこと
- セッションログを正本として運用しない。ログは検索しづらく、編集できず、コンテキストにも全部は載りません。台帳が必要なら最初からファイルにする
- 自動圧縮を過信しない。要約で何が落ちるかは制御できず、走るタイミングも選べません。頼るのは保険としてで、主導権は自分の区切りに置く
- 挙動を思い込みで断定しない。自動圧縮の条件も要約の粒度も、バージョンと時期で変わります。この記事に書いた挙動も執筆時点のものです。長い作業を任せる前に、自分の環境で一度確かめる
まとめ
セッションは切れ、コンテキストは圧縮されます。ログはローカルに残っても、モデルが見ている範囲はずっと狭く、会話が伸びれば要約が細部を溶かします。これはツールの欠点ではなく前提条件です。
前提なら、設計で吸収できます。真実をファイルに置く。手順をskillにする。引き継ぎを書かせて、読み込みまで自動化する。使用率を監視して、保存してから区切る。区切りは自分の予定に合わせ、生成はレビューできる量に抑える。どれも特別な技術ではなく、運用の決めごとと少しの自動化です。そして決めごとにした組織だけが、作業が途中で切れちゃったから復旧して、の一言で仕事が再開する環境を手に入れます。
この仕組みづくりを支援しています
KOIYALでは、こうしたAIが定着する仕組みづくりを含めて、企業のAI導入を支援しています。ツールの選定より先に、切れても壊れない運用の設計から。気になる方はお問い合わせください。