「ステップで考えて」と書いたら Local LLM の精度が下がった — 8GB 環境で観察した CoT が逆効果になる 3 場面

"ステップで考えてください" "Let's think step by step"。

LLM にこう書くだけで精度が上がるとする説明は、2022 年の論文以降、広く受け入れられた前提として定着した。私もそう信じて、ローカルで動かしている Qwen2.5-14B にも同じ呪文を書いていた。

8GB VRAM 環境でモデルをいくつか回しているうちに気づいたのは、8GB に乗るサイズの言語モデルだと、Chain-of-Thought を書かせると逆に遅くて、間違える場面が増えるということだった。

この方向は 2022 年以降の研究と整合する。Wei et al. (2022) の原論文の図でも、CoT の効果はモデルサイズに対して非線形で、~100B を下回るモデルでは CoT が目立った効果を出さず、小さいほど "思考の連鎖" が論理的に破綻して最終回答を引きずる、と示唆されている。最近では Wharton Generative AI Labs が 2025 年に出したテクニカルレポート「The Decreasing Value of Chain of Thought in Prompting」が、フロンティアの汎用 API モデル (GPT-4o / Claude 3.5 Sonnet / Gemini Pro 1.5 など) を対象に、CoT を足すと平均は微改善でもばらつきが増え、コストに見合わない場面が広がっていると整理している (こちらは小さいローカル LLM の話ではない、念のため)。

"CoT 効果はサイズ依存" "フロンティアでも汎用 CoT のコスト/ベネフィットは怪しくなり始めた" を重ねると、汎用タスクで素朴に "think step by step" と書く運用は、特に小さいローカル LLM では見直したい、というのがいまの私の立ち位置だ。

この記事では、私が 8GB 環境で観察した「CoT が逆効果になる」3 つのパターンと、CoT が効く例外を整理する。

• ハードウェア: RTX 4060 8GB VRAM、Ryzen 7 7700X、メモリ 32GB -
• モデル: Qwen2.5-14B-Instruct Q4_K_M (llama.cpp)、Qwen2.5-7B-Instruct Q5_K_M、Qwen2.5-Math-7B-Instruct (比較用) -
• 観察対象: コード生成、JSON 変換、ツール呼び出し、数学

最初に断っておくと、この記事に出てくる数値は厳密なベンチマークではなく、Wharton 報告などの公開研究の方向と、私が手元のモデルで使い回している中での体感の重ね合わせだ。再現実験のログを取り切ったわけではない。

"体感" "観察" と書いている部分は、同じプロンプトを何度か投げ直したときの成功/失敗の傾向の話で、数字は精密なものではない。Wharton 報告と Qwen2.5-Math-7B の公式ベンチは精密な数字なので、後者は補強として明示的に引用する。

2022 年の Jason Wei らの論文「Chain-of-Thought Prompting Elicits Reasoning in Large Language Models」が、PaLM 540B の GSM8K 精度を 17.9% から 56.9% に引き上げた。ここから "step by step と書け" が広まった。

ただし、原論文の図にも書いてあるように、CoT の効果はモデルサイズに対して非線形だった。8B-62B あたりは横ばい、100B 超でジャンプする。小さいモデルが書く "思考の連鎖" は論理的に破綻していて、むしろ最終回答を引きずられる。

この「サイズ依存」を忘れて、すべてのモデルに同じ呪文を書く運用は雑だ。私もしばらくその雑な運用をしていた。

最初に気づいたのは、ちょっとした計算混じりのコード生成だった。

ユーザー：月 50 時間使う前提で、Claude API の Opus 入力 5 ドル/Mtok・出力 25 ドル/Mtok で、
入力 2 万トークン・出力 5 千トークンのリクエストを月 900 回するときの費用を計算して。
ステップで考えてください。

これを Qwen2.5-14B Q4_K_M に投げると、こう出てきた。

ステップ 1: 入力トークン総数を計算します。
20,000 × 900 = 18,000,000 トークン (18M トークン)
ステップ 2: 入力費用を計算します。
...

正解。

ところが入力トークンを 20 万に変えただけで失敗が増える。手元の体感では、桁が一段増えると、ステップ 3-4 あたりで「200,000 × 900 = 180,000,000」を「18,000,000」と書き損じる失敗が混じり始める。出力としては論理が整っているように見えるので、最後の数字を読まないと気づかない。

「計算を sympy に任せて」「コードを書いて」と指示すると、CoT を書かせなくても結果は安定する方向に動く。

これはLocal LLM の数値感覚が大きい桁になると怪しいことを暴露している。CoT で "考えさせる" と、その怪しい数値感覚が出力に乗る。だったら CoT を書かせず、ツールに任せた方が速くて正確だ。

プロンプト	桁が小さい時の挙動 (体感)	桁が大きい時の挙動 (体感)	速度
step by step (CoT)	おおむね正解	中盤の計算でズレ始める	遅い (出力長が長くなる)
...
「桁が増えると精度が落ちる」は、私の手元の体感の話だが、複雑度と精度の負の相関を扱う最近の研究 (Wharton の報告など) とも方向としては整合する。

OpenAI Function Calling や Anthropic の Tool Use に相当する JSON スキーマのパターンを、Qwen2.5-14B でもローカルなツール経由で動かしていた。

ユーザー：今の東京の気温と、ロンドンとの気温差を教えて。ステップで考えて。

Qwen2.5-14B が返したのは、こんな出力だった。

ステップ 1: 必要な情報を整理します。
- 東京の気温
- ロンドンの気温
...

一見正しい。だがツールがまだ実行されていない時点で、ステップ 2 の JSON ブロックの隣に「→ 18°C」と書いている。これは存在しない結果の捏造だ。続けて気温差まで「計算」してしまう。

ローカル運用のスケジューラ側がこれを真に受けて、「ツールはもう呼んだ」と判定してしまうとアウトだ。私はここで一度、温度計の値を捏造した記事を書きかけて止まった。

CoT を書かせない素朴なプロンプトに切り替えると、こうなった。

ユーザー：今の東京の気温と、ロンドンとの気温差を教えて。
必要なツールがあれば呼んでから、結果を待って答えること。

返答は

{"tool": "weather", "location": "Tokyo"}
{"tool": "weather", "location": "London"}

だけで止まる。スケジューラがツールを実行して結果を返した次のターンで、初めて気温差を答える。正しい挙動だ。

CoT は「思考の流れを言語化する」プロンプトだから、まだ起きていないツール結果を「言語化」して埋めてしまう副作用がある。Qwen2.5-14B 程度のサイズでは、この埋め草が嘘になる確率が高い。

ここでも対策は単純で、ツール呼び出しを混ぜるタスクでは、step by step を書かない。

3 つ目の罠は、コンテキストが長くなると CoT で書かれた中盤の論理が無視されることだった。

「Lost in the Middle」(2023, Liu et al.) で報告されている通り、長いコンテキストの中盤に置かれた情報は、LLM が取りに行きにくい。Local LLM では、これが CoT 中の「ステップ N」あたりの論理にも起きる。

私が手元で受けた印象は、Qwen2.5-14B Q4_K_M で 20K トークン近いプロンプトを書いて、その中で「以下の手順で考えて、最後にまとめてください」と指示したケース。出力された手順 1-7 のうち、中盤あたりの論理が結論に反映されず、最初と最後の見出しだけを混ぜ直したような結論になっているように感じることがあった。

同じプロンプトを 8K コンテキストに収めると、論理的整合のある結論が出る方向に動く。

これはLocal LLM の実効コンテキストが、論文の主張するコンテキスト長より短いという事実を反映している。32K コンテキストモデルでも、KV キャッシュを Q4 まで落とすと中盤の精度はもっと落ちる。CoT を長く書けば書くほど、その「長さ」が中盤の蒸発に直結する。

対策は、長いコンテキストでは CoT を諦めて、短い「直接答え」プロンプトに分割する。1 ターンで全部考えさせるのではなく、3-4 ターンに分けて、各ターンを 8K に収める。レイテンシは増えるが、精度は確実に上がる。

ここまで「CoT を書かせるな」と書いてきたが、数学特化モデルは別だ。

Qwen2.5-Math-7B-Instruct は CoT 設定で MATH ベンチマーク 83.6 を出している。Tool-Integrated Reasoning (TIR) なら 85.3 まで上がる。これは公式テクニカルレポートに載っている数字で、私の観察ではない。

汎用 Qwen2.5-14B との対比で言えば、数学特化モデルは「step by step」の指示を素直に受け取って、検算めいた中間ステップを書く方向が強い。私の手元でも汎用モデルに AMC 級の問題を解かせるよりは、特化モデルに CoT で解かせる方が筋がいいと感じている。8GB VRAM にギリギリ載るサイズで、本気で CoT を使うべきはここだけだ、と私は今思っている。

汎用 Qwen2.5-14B と Qwen2.5-Math-7B で明暗が分かれるのは、数学特化のファインチューニングが CoT フォーマットに沿った推論を学習しているからだ。汎用モデルが CoT で「思考っぽい言葉を生成する」のとは別の訓練が入っている。

つまり「CoT が効くか」は、モデルがそのフォーマットに最適化されているかで決まる。素のサイズだけで判断してはいけない。

タスク	モデル	CoT を書く？
数値計算 (桁が小さい)	Qwen2.5-14B	書いてもいいが、コード化が安全
...

雑に「step by step と書く」をやめて、タスクとモデルで使い分けるだけで、私の体感では運用がかなり安定した。

CoT を書かない代わりに、私が今使っているテンプレートを 2 つ載せておく。

[タスクの記述]
ルール:
- 中間思考を書かない
...

わからない

を許すと、ハルシネーションが体感半減する。これは CoT より効いた。

[タスクの記述]
ルール:
- 必要なツールを呼ぶ。結果を待つ
...

「ツール結果が来るまで最終回答を書かない」を明示するだけで、観察 2 の捏造が止まる。

「step by step」は、100B クラスのモデルが訓練データの中で CoT フォーマットの思考を大量に見ているから効く呪文だった。8GB VRAM に乗るサイズのモデルでは、思考の連鎖が論理的に破綻し、ツール結果を捏造し、長コンテキストで蒸発する。

관찰	무엇이 일어날지	대응책
계산에서 유효숫자가 큰 경우	중간 단계의 계산 오류	코딩화, CoT 제거
...
예외는 수학 특화 모델 등 CoT 포맷에 맞춰 훈련된 모델로 한정된다.

로컬 운영은「프론티어에서 잘 되는 기술이 그대로 적용된다」고 가정하면 큰 실수를 범하게 된다. 손에 있는 프롬프트를 조금씩 step by step 을 제거해 나갔다. 출력 길이가 짧아지고, 레텐시 (Latency) 가 낮아졌으며, 오류가 줄었다는 느낌을 받았다.

로컬 LLM 은 로컬 LLM 의 방법론이 있을 것이다. 지금 그 방법론을 매일 조금씩 재작성하고 있다.