- はじめに：ローカルLLM環境で遭遇する「謎の壁」
MacBook M5 Pro（CPU 18Core / GPU 20Core / メモリ64GB）という最高峰のマシンに、LM StudioとOpenClawを組み合わせ、Qwen3.6（35B-A3B）のような重量級モデルを動かす。ローカルLLMを追求するエンジニアにとって、これほど胸が高鳴るセットアップはありません。
しかし、期待に胸を膨らませてプロンプトを入力した瞬間、処理が始まる代わりに無情な警告が表示されることがあります。
「Auto-compaction could not recover this turn」
このメッセージが出ると、画面の指示通りに /compact コマンドで圧縮を試みたり、/new でセッションを新しくしたりしても、一向に解決しない「絶望のループ」に陥ることがあります。最強のハードウェアを揃えたはずなのに、なぜか目の前のAIが動かない。そんなエンジニアの「謎の壁」を突破するための、ログに隠された真実をお話しします。
- 【衝撃の事実1】エラーメッセージの「指示」は必ずしも正解ではない
エラー画面には、非常に具体的で親切そうなアドバイスが表示されます。 「agents.defaults.compaction.reserveTokensFloor を 20000 またはそれ以上に設定してください」
しかし、ここには大きな落とし穴があります。実は今回のケースにおいて、このアドバイスは解決どころか**状況を悪化させる「罠」**でした。
なぜなら、reserveTokensFloor（予備トークン）を増やすという行為は、利用可能なプロンプト予算をさらに「削る」ことを意味するからです。全体の器（コンテキストウィンドウ）が十分に確保されていない状態で予備だけを増やしても、計算上の空きスペースがなくなるだけ。表面上の指示を鵜呑みにすることは、デバッグにおいて最も危険な道なのです。
"ChatGPTや画面のエラーメッセージを鵜呑みにするのではなく､ 問題が発生した時はエラーログも必ず確認しよう！"
- 【衝撃の事実2】AIの提案（ChatGPT）が通用しない「盲点」がある
自力で解決できないとき、私たちはChatGPTに泣きつきます。実際にこのトラブルを相談した際も、AIからはもっともらしい3つの対策が提案されました。
- openclaw.json の reserveTokensFloor を20000に設定する（UIと同じ指示）
- 既存のセッションを削除する
- OpenClawを再インストールする
残念ながら、これらの対策をすべて試しても状況は1ミリも改善しませんでした。
ChatGPTは一般的なベストプラクティスを提示してくれますが、MacBook M5 Pro 64GBという潤沢なリソースを持つ環境と、ソフトウエア側の制限値との「乖離」までは見抜けないのです。高スペック環境だからこそ発生する、設定の「不一致」という盲点が存在します。
- 【衝撃の事実3】真の答えは「ログ」の中の数計算に隠されていた
解決の鍵は、UIの親切なメッセージを無視し、OpenClawの「生のエラーログ」を覗いた瞬間に見つかりました。ログには、冷徹な算術結果が記されていたのです。
- estimatedPromptTokens（推定プロンプト）：4785
- promptBudgetBeforeReserve（予備前の予算）：4500
- overflowTokens（オーバーフロー）：285
- effectiveReserveTokens（有効な予備トークン）：4500
ここから読み取れる事実は、わずか285トークンの不足です。 さらに注目すべきは、予算の土台となる数値が 4500 前後に固定されてしまっている点です。画面の指示通りに reserveTokensFloor（床）をいくら高く設定しても、この「予算の天井」が低いままでは、プロンプトが入る隙間など生まれるはずもありません。
真のボトルネックは、バッファの設定ではなく、OpenClawが認識している**「コンテキストウィンドウ（全体の器）」のサイズ不足**だったのです。
- 解決編：openclaw.jsonの「contextWindow」を書き換える
根本的な原因は、OpenClaw側の設定ファイルにおいて、使用しているQwenモデルに対して割り当てられた contextWindow が、LM Studio側の設定と同期しておらず小さすぎたことでした。
最終的な解決手順
設定を変更する前に、必ず openclaw.json のバックアップを取ってください。その上で、該当するモデルの contextWindow を適切な値（例：20000）へ引き上げます。
"models": [
{
"id": "qwen/qwen3-next-80b", // または使用中の qwen3.6-35b-a3b
"name": "qwen/qwen3-next-80b",
"contextWindow": 20000,
"maxTokens": 10000
}
]
この変更を保存した瞬間、それまでの「Auto-compaction」エラーが嘘のように消え、Qwen3.6 への実行文が正常にデリバリーされるようになりました。
技術的な洞察：同期の重要性
OpenClawはオーケストレーターとして、独自の「クライアント側リミット」を持っています。
- LM Studio（バックエンド）： モデルが扱える広大なコンテキストを設定
- OpenClaw（フロントエンド）： openclaw.json で定義された contextWindow で制限
この2つが同期していないと、バックエンドにどれだけ余裕があっても、OpenClaw側で勝手に「溢れた！」と判断して処理を止めてしまいます。ハイスペックマシンを活かすには、この両者のパイプラインを等しく広げる必要があるのです。
- おわりに：デバッグの本質への立ち返り
今回のトラブルから得られた教訓はシンプルです。**「ツールが便利になればなるほど、生のデータ（ログ）を見る習慣が大切になる」**ということ。
MacBook M5 Proというモンスターマシンを使っていても、設定ファイルのたった一行、わずか285トークンの計算ミスで、システムは沈黙します。UIのメッセージやAIのアドバイスはあくまで「二次情報」であり、エンジニアが最後に信頼すべきは、システムが吐き出した「一次情報（ログ）」です。
次にエラーが出たとき、あなたは画面の優しい言葉を信じますか？ それとも、裏側で牙を剥くログの数値を信じますか？
※youtubeにも動画をアップしています