はじめに：ローカル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にも動画をアップしています