OpenClawのコンテキスト超過・圧縮失敗を直す：作業を残して会話を再開する手順
context length exceededが出たら、完了した操作と未処理の依頼を残し、実際に失敗したモデルと入力予算を確認してください。圧縮できる会話なら履歴を要約し、圧縮自体が失敗するなら固定の指示や読み込み済みモデルの容量を調べます。新しい会話へ移る前に、作業状態を引き継ぐことが大切です。
目次
OpenClawでcontext length exceededやCompaction failedが出たら、まず完了した操作と未処理の依頼を残し、失敗した要求の入力予算を調べます。履歴が主な原因で、使っている実行方式が手動圧縮に対応していれば、/compactで会話を要約できます。圧縮そのものが失敗する場合は、同じ依頼を繰り返す前に、固定の指示・ツール定義・新しい入力が占める容量と、実際に動いているモデルの上限を確認してください。
新しい会話へ移す/newも復旧手段ですが、先に作業状態を引き継ぎます。すでに編集されたファイルや送信済みの処理は、エラーや停止によって元に戻りません。ここでは、2026年10月4〜5日に確認した公式資料に基づき、今の会話を続ける場合と、新しい会話へ移る場合を切り分けます。実機での復旧試験や有料モデルへの呼び出しは実施していません。
再送する前に、完了した作業と残りの依頼を保存する
回答が途切れていても、その直前のツール操作は完了していることがあります。最初に会話の実行履歴と成果物を見て、次の情報を短いメモへまとめてください。モデルへ依頼できない状態なら、画面やファイルを確認して自分で保存します。
- 最後に頼んだことと、まだ回答・処理されていない部分。
- 完了した操作、その結果を確認できるファイルや記録。
- 途中で止まった操作、実行したか不明な操作。
- 次に行う一つの作業と、完了と判断する条件。
- 変更してはいけないもの、確認が必要な外部への操作。
例えば、ファイル編集を続けるなら次の程度で十分です。下記は記入例であり、実際の復旧記録ではありません。
目的: report.mdの数値を更新して、残りの誤記を直す。
完了: report.mdの売上表を更新。ファイルで内容を確認済み。
未完了: 本文の数値との整合確認、誤記の修正。
不明: 最後の検証コマンドの終了結果。再編集前に出力を確認する。
次の作業: report.mdを読み、表と本文を照合する。
制約: 公開・送信はまだ行わない。完了した更新を重複実行しない。組み込みOpenClawの現在の復旧処理は、ツール結果が確定している場合、記録された結果から圧縮して続行し、完了した操作を再実行しません。ただし、ツールが未完了、承認待ち、キャンセル済みの場合まで同じ扱いになるわけではありません。人が依頼を再送する際も、成果物を確認して重複を避けます。圧縮とツール実行後の復旧
進行中の処理を止めた場合、その後の復旧や再試行も停止します。停止は取り消しではなく、すでに確定した編集や圧縮は残ります。送信・購入・公開などの処理結果が不明なら、先に送信先や実行記録を確認し、同じ操作をもう一度実行しないでください。
エラーが出た要求のモデルと予算を確認する
図は要求の内訳を示すイメージです。実際の容量や画面を示したものではありません。
コンテキストウィンドウは、モデルが一回の要求で扱える容量です。会話の文章だけでなく、システムの指示、ワークスペースから読み込まれる指示、ツールの定義、ツール結果、添付ファイル、過去の要約も含みます。画面の会話が短くても、要求全体が小さいとは限りません。コンテキストに含まれるもの
対象の会話で、次のコマンドを一つずつ送ります。これは利用者の環境で確認する手順であり、この記事の作成時に実行した結果ではありません。
/status
/context list
/context detail/statusでは会話の設定と圧縮回数を、/context listでは読み込まれたファイルなどの概算を、/context detailでは大きいツール定義や指示の内訳を調べます。実行レポートがない会話でも、/context list、/context detail、/context jsonはその場で推定できます。/context mapは保存された実行レポートが必要なため、表示できない場合に同じコマンドを繰り返す必要はありません。
Control UIのPrompt budget (last run)は、選択中のモデルと有効な上限に合う最後の実行から得た推定入力予算です。圧縮用の余裕が差し引かれており、モデルの公称上限とは異なります。モデルや上限を変更した直後は、対応する新しい実行が得られるまでContext window表示になります。古いトークン数だけで「まだ余裕がある」「圧縮が済んだ」と判断しないでください。メーターと推定値の意味
Gatewayホストのターミナルでは、バージョンと失敗時のログを確認します。
openclaw --version
openclaw logs --follow同じ失敗について、時刻、agent・会話、提供元、実際に要求を受けたモデル、入力の推定値または提供元が返したトークン数、予算、圧縮の成否を対応付けます。公開して相談する場合は、キー・トークン・個人情報・非公開の本文を除きます。
| ログや状態から分かること | 次に行う確認 |
|---|---|
| 長い会話で、古いツール結果が大きい | 手動圧縮が使えるか確認し、履歴を要約する |
| 新しい会話の短い依頼でも超過する | 固定の指示・ツール定義と、実際のモデル容量を確認する |
| 圧縮の入力自体が予算を超える | 圧縮モデルの要求と通常の応答に使う要求を分け、両方の予算を見る |
| 画面の選択モデルと失敗したモデルが違う | fallbackの試行記録を確認する |
HTTP 408、504、品質チェック失敗などが出る | 単なる履歴過多と分けて、圧縮がどう終わったか確認する |
既定モデルや自動選択でfallbackを使う場合、実際に応答したモデルはそのターンだけ変わり、会話の選択モデルは変わらないことがあります。明示的に会話で選んだモデルは厳密に扱われます。「429の後に小さいfallbackへ進み、そこで超過した」という可能性は、試行記録が裏付けて初めて判断できます。429そのものがコンテキスト超過を意味するわけではありません。モデル復旧とfallbackの仕様
履歴を圧縮できる場合は、未完了の依頼を含めて要約する
組み込みOpenClawの実行方式で手動圧縮が使えるなら、対象の会話へ次を送ります。
/compact 完了した操作、変更したファイル、未処理の依頼、次の作業と制約を残してください。圧縮は古い会話を要約し、最近のメッセージを残します。ツール呼び出しと対応する結果も、分割時に組として扱われます。元の会話履歴は保存されますが、モデルが次の要求で見る内容は要約と残した直近の会話になるため、要約がすべての情報を忠実に残すとは考えないでください。手動圧縮の動作
実行方式によって対応が異なります。公式資料では、対応するネイティブCodexセッションは引数なしの/compactを使い、補足指示を渡しません。Sign in with ChatGPTを使うネイティブCodexセッションは自動圧縮に対応しますが、手動/compactは使えません。手動操作が非対応なら、コマンドを増やして試すのではなく、保存した作業メモを使って新しい会話へ移ります。
圧縮後は、/statusの圧縮回数やログの完了記録を見てから、残りの作業を一つだけ続けます。例えば「先ほどのreport.mdについて、表と本文の整合確認だけを行ってください」と依頼し、実際のファイルやツール結果を照合します。単に「覚えています」と答えることや、トークン表示が変わることだけでは復旧の証明になりません。
圧縮も失敗する場合は、予算不足と要約失敗を分ける
圧縮には古い履歴を要約するための要求が必要です。履歴を減らす処理だからといって、入力容量が不要になるわけではありません。組み込み実行方式の自動圧縮は、通常の応答に使う要求が準備できている場合、システムの指示・ツール定義・未処理の入力・出力用の余裕も考慮して直近の履歴を選びます。一方、要求が準備される前の事前確認は履歴中心の推定であり、同じ余裕を保証しません。圧縮の予算と残す履歴
固定の指示や新しい入力だけで大きくなっている
/context detailでシステムの指示やツール定義が大部分を占めるなら、古い会話を要約しても減らせる量が少なくなります。大きいログやファイルを一度に渡している場合は、原本を保存したうえで、対象箇所だけを読む作業に分けます。必要な指示やアクセス制御を一律に削除することは避け、重複した説明や今回不要な大量入力から見直してください。
ワークスペースの初期読み込みには、公式の既定値でファイルごとに20,000文字、合計60,000文字の上限があります。これはトークン数ではありません。/contextで元の長さと実際に注入された長さを確認し、文字数だけからモデルの空き容量を計算しないでください。初期読み込みの上限
新しい会話でも固定の指示やツール定義は読み込まれます。したがって、履歴がほぼなくても失敗するなら、/newだけで解決したことにはなりません。実行可能な容量に合った入力へ縮めるか、必要な容量を実際に使えるモデルへ変更する必要があります。
圧縮モデルを変えても、会話側の容量は増えない
agents.defaults.compaction.modelは要約用モデルを選ぶ設定です。要約用に大きいモデルを使えても、通常の応答で使うモデルのコンテキストウィンドウは増えません。要約と未処理の入力が、最終的に会話側の予算へ収まる必要があります。
要約モデル側で容量不足が確認でき、そのモデルへ接続する認証・実行方式も使える場合にだけ変更を検討します。通常の応答に使う入力が超過しているのに、要約モデルだけを変え続けるのは適切な切り分けではありません。また、明示した圧縮モデルは通常のfallbackを引き継ぐ設定ではないため、指定先自体の失敗を確認します。圧縮専用モデルの仕様
現在の組み込み実行方式は20,000トークンを基本の予備容量とし、小さいウィンドウではその4分の1までに抑えます。例えば32,768トークンのウィンドウなら、予備容量は8,192、残りは24,576です。これは公式の説明を再計算した例であり、利用者の実際の要求予算ではありません。固定の指示、出力、提供元の制約などを含む実際の記録を優先してください。予備容量の仕様
タイムアウトや品質チェックで止まっている
現在の組み込み自動圧縮では、会話の処理がまだ進行中に要約の期限へ達した場合、または提供元がHTTP 408・504を返した場合、要約なしの縮小処理で続行する例外があります。直近の会話、確定したツール呼び出しと結果、未処理の依頼、以前の要約を残しますが、以前に要約されていない古い事実はモデルの入力から外れ得ます。元の履歴には残るため、必要な事実は明示的に取り出して渡します。
このときGatewayログには[compaction-diag] fallback ... reason=timeout summary=deterministicが記録されます。すべての圧縮失敗がこの動作になるわけではありません。手動/compact、キャンセル、その他の要約エラーは別に扱われます。自動圧縮のタイムアウト例外
品質チェックに通らない要約は、組み込みのsafeguardで保存前に止められ、元の履歴が維持されます。失敗を消すために品質チェックを無効にするのではなく、ログにある入力予算や要約の失敗を調べてください。
また、timeoutSecondsの既定値180は、進捗がない時間の上限です。実際の出力が続くとその待ち時間は更新され、全体には10回分の上限があります。「3分経ったので確実に失敗した」とは判断できません。停止したい場合は処理を止め、その後に自動回復が続くことを期待しないでください。タイムアウトと品質チェックの設定
LM Studioでは、公称上限と読み込み済み容量を揃える
図は確認する対象の関係を示しています。特定モデルの容量や実測結果ではありません。
ローカルモデルの説明に大きいコンテキストウィンドウが載っていても、実際に読み込まれたインスタンスが小さい容量で動いていることがあります。OpenClawの現在のLM Studio連携では、読み込み済みインスタンスの容量を、公称最大値より優先します。OpenClawのcontextWindowだけを大きく書き換えても、バックエンドの容量を増やした証拠にはなりません。LM Studioのモデルとコンテキスト
次の順に照合します。
- 失敗した要求のモデルIDと、LM Studio側の実際の読み込み済みインスタンスを対応付けます。
- そのインスタンスのコンテキスト長と、OpenClawが使用したモデル上限・入力予算を確認します。
- 不一致があれば、実行環境が確保できる容量でモデルを読み込み、OpenClaw側の設定をそれに合わせます。JITによる読み込みと事前読み込みを区別してください。
- 同じ会話・agent・接続先で短い応答を確認し、次に小さい読み取り作業を試します。容量を変更しても同じ要求で失敗するなら、ログの入力予算へ戻ります。
事前読み込みが有効な場合、現在の連携は選択された予算を満たすインスタンスを準備して要求を送ります。事前読み込みを無効にしている場合は、LM StudioのJITや解放設定も確認します。メモリ容量が多い機材を買うことや、公称上限をコピーすることだけでは、意図した容量での読み込みを確認できません。接続とモデル選択からやり直す必要がある場合は、OpenClawのLLM設定手順を参照してください。
Qiitaの「4,785対4,500」は、設定の不一致を調べる手掛かり
2026年5月27日のQiitaの個人報告では、LM StudioとOpenClawのローカルモデルで自動圧縮が失敗し、ログに推定プロンプト4,785、予算4,500、超過285と記録されています。差は4,785 − 4,500 = 285で一致します。著者は設定値の引き上げ、セッション削除、再インストールでは解消せず、その後にクライアントのcontextWindowを20,000へ合わせた経緯を報告しています。
この報告から得られるのは、圧縮の失敗でもログの推定値と予算の差を具体的に見るという手掛かりです。20,000がどのモデルにも使える値、現在の全環境に効く修正、ある機材なら必ず復旧するという結論にはなりません。現在の読み込み済み容量と実際の要求を確認してから、使える値を選んでください。ここでの数字は第三者の古い事例であり、本站の実機測定ではありません。
pruning・メモリ保存・圧縮の設定を混同しない
古い設定例を貼り付ける前に、その設定が何を減らすか確認します。現在の仕様では、役割は次のように分かれています。
| 仕組み | 対象と用途 | コンテキスト超過への限界 |
|---|---|---|
| compaction | 古い会話を要約し、最近の会話を残す | 要約の要求にも容量が必要。固定の指示は消えない |
| context pruning | 古いツール結果を縮める | 通常の会話文を要約する処理ではない。接続経路と設定条件がある |
| memory flush | 圧縮前に重要な情報を永続的なメモリへ保存する | 会話のウィンドウを増やさず、停止しても圧縮自体は無効にならない |
/new・/reset | 新しい会話を始める | 作業の引き継ぎが必要。固定の指示とツール定義は残る |
pruningはすべての提供元で自動的に動く機能ではありません。Anthropic系プラグインの初期設定と、その他の提供元を区別します。直接のAnthropic APIキー接続では、対応する条件下でサーバー側のツール結果クリアを使います。その他の適格な接続では、TTLとコンテキスト量に応じたクライアント側処理です。クライアント側で縮めた入力内容は復元用の記録を持ち、Gateway再起動後も維持されますが、元のツール結果は履歴に残ります。「RAM内だけの一時処理」「再起動すれば必ず戻る」という説明は現在の仕様には合いません。pruningの現在の条件と保存方法
softThresholdTokensはagents.defaults.compaction.memoryFlushに属し、圧縮のしきい値より手前でメモリ保存を始める余裕を表します。memorySearchの検索結果上限でも、モデル容量でもありません。公式の32,768トークンの例では、圧縮側の24,576から4,000を引いた20,576で早期保存が始まります。この算術は自分の実行予算を確定するものではありません。メモリ保存のしきい値
以前の記事にあるreserveTokensFloorや固定の大きな予備容量を、そのまま今の設定へ追加しないでください。古いキーが手元のバージョンで有効かは、インストール済みのスキーマで確認します。ターミナルでopenclaw config fileを使って実際の設定ファイルを特定し、openclaw config validateで現在の設定を検証できます。保存や検証が成功しても、モデル側が要求を受け付けることまでは証明しません。変更後は表示された反映方法に従い、同じ接続で応答を確認します。設定CLIの仕様
同じ超過が続くなら、作業メモを持って新しい会話へ移る
圧縮が使えない、圧縮を一度試しても同じ入力予算不足が残る、あるいは現在の会話から必要な履歴を適切に減らせない場合は、保存した作業メモを使って新しい会話へ移ります。容量の不一致が見つかっているなら、先にそれを修正します。
対象の会話で/newを実行し、新しい会話に次の順で渡します。
- 目的、未処理の依頼、次に行う一つの作業。
- 完了した操作と、結果を確認するためのファイルや記録。
- 重複実行してはいけない操作、実行済みか不明な操作。
- 作業に必要な短い情報。巨大な旧ログや会話全体は貼り戻さない。
/resetも公式には手動で新しい会話を始める操作として記載されています。永続的なメモリをすべて消す操作と考えて、メモリディレクトリを削除する必要はありません。会話のリセット方針
再開後は、短い応答が返ること、必要な作業状態を正しく参照できること、残りの作業が実際に進むことを確かめます。新しい会話の短い依頼でも同じエラーなら、旧履歴が原因という説明は弱くなります。固定の指示、ツール定義、入力予算、読み込み済みモデルの容量へ戻って調べてください。
同じ超過を何度も再送する、成果物の状態が分からないまま再実行する、履歴・設定を消して症状だけ消す、という段階へ進む前に止めます。ログから実際の容量を判別できない場合は、バージョン、実行方式、モデルと接続先、失敗時の入力予算、実施した変更を整理して、提供元やOpenClaw側へ確認します。
よくある質問
/compactが成功すれば、会話の内容はすべて残りますか？
元の履歴は保存されますが、モデルが次に見る要約は全文ではありません。重要な決定、識別子、未完了の依頼を確認し、必要な原本はファイルや履歴から読み直せるようにしてください。特に自動圧縮のタイムアウト時は、古い未要約の事実が入力から外れ得ます。圧縮とタイムアウトの仕様
新しい会話でもコンテキスト超過になるのはなぜですか？
新しい会話にもシステムの指示、ツール定義、初期ファイル、新しい入力が含まれるからです。/context detailで固定部分の大きさを確認し、実際に要求を受けたモデルの容量と照合します。履歴がなくても超過するなら、履歴の削除を繰り返すだけでは解決しません。コンテキストの内訳
contextWindow: 20000へ変えれば、LM Studioの圧縮失敗は直りますか？
一律には直りません。20,000はQiitaの一人の報告で使われた値です。現在のLM Studio連携は読み込み済みインスタンスの容量を優先するため、実際の読み込み条件とOpenClaw側の認識を合わせて確認してください。設定ファイルの数値だけでは、バックエンドがその容量で動く証明になりません。読み込み済み容量の扱い
圧縮を無効にすれば、Compaction failedを避けられますか？
agents.defaults.compaction.enabled: falseは組み込み実行方式のしきい値による自動圧縮などを抑えますが、手動圧縮や超過後の復旧処理まで全面的に止める設定ではありません。容量不足の原因も残ります。まず実際の入力予算とログから、必要な変更を選んでください。圧縮の有効・無効設定
