thinking を切っていいのか測ったら、採点器のほうが2回壊れていた thinking を切っていいのか測ったら、採点器のほうが2回壊れていた

はじめに

CLI を整えた回で、 thinking を既定でオフにしました。理由はこう書いています。

これがトークンを大量に食います。 「日本語で1文だけ自己紹介してください」という質問に対して、思考に 1313 文字使っていました。

速度しか見ていません。 品質が落ちていないかは測っていませんでした。 切ったせいで損をしている可能性が残ったままです。

測りました。結論は「この難易度帯では切って問題なし」でしたが、 そこに至るまでに採点スクリプトのバグを 2 回踏んでいます。 今回の収穫はそちらでした。

測り方を決める

品質を主観で採点すると比較になりません。 なので正解が機械的に検証できる課題だけを使うことにしました。

「説明文が丁寧になるか」は測れないので、測らないと決めました。 測れないものを測ったふりをするほうが害が大きいと考えています。

課題は 5 問。thinking が効きそうなものと、効かないはずのものを混ぜてあります。

課題	種類	想定	正解
T1	多段の算術（まとめ買い割引）	効きそう	1800 円
T2	数え上げ（包除原理）	効きそう	53 個
T3	日付計算（月跨ぎ）	効きそう	2026-11-10
T4	単純な抽出（2 番目に大きい値）	効かないはず	7
T5	単位変換（秒 → 時分秒）	効かないはず	2 時間 46 分 40 秒

正解はすべて計算で検算しました。

「効かないはず」を混ぜたのが肝です。 もし全課題で差が出たら、それは thinking の効果ではなく 別の要因（温度、運の偏り）を疑うべき、という切り分けになります。

前回で 「もっともらしい説明ほど危ない」を学んだので、 仮説が外れる可能性を先に組み込んでおきました。

条件は temperature 0、max_tokens 4096、各条件 2 回ずつです。

1 回目: thinking OFF のほうが正答率が高い？

結果はこうでした。

ON   正答 4/5
OFF  正答 5/5

T2（数え上げ）で thinking ON だけが不正解。 4171 文字も考えて間違えている。

「考えすぎて自滅した」という筋書きが浮かびました。面白い結果です。

念のため、実際の出力を見ました。

3または5で割り切れる数は 33 + 20 - 6 = 47個です。
したがって、3でも5でも割り切れない数は 100 - 47 = 53個となります。

答え: 53個

正解していました。 包除原理を正しく使っています。 不正解だったのは私の採点でした。

バグ 1: 採点対象が条件によって変わっていた

本文全体に正規表現をかけていました。

thinking を出すと、本文に途中計算が並びます。33 個、20 個、6 個、47 個……。 一方 thinking OFF は結論だけを短く返します。

同じ正規表現を当てても、見ている文章の量がまるで違うわけです。 ON 側だけが余計な数字に晒される、フェアでない採点でした。

「答え:」で始まる行だけを採点するよう直しました。 出力形式を指示してあるので、形式を守っているかも同時に測れるという副次効果もあります。

2 回目: 今度は両方とも不正解

直して測り直したら、T2 が両条件とも不正解になりました。

前回 OFF は正解していたのに、です。明らかにおかしい。

バグ 2: \b が日本語で効かない

正規表現に \b53\b を使っていました。

\b は「単語文字と非単語文字の境目」にマッチします。 そして .NET の正規表現は、漢字やかなを「単語文字」として扱います。

「53個」の 3 と 個 はどちらも単語文字なので、その間に境界が立ちません。

"答え: 53個" -match '\b53\b'          # False
"答え: 53個" -match '(?<!\d)53(?!\d)'  # True

正解を不正解と記録していたわけです。

数字を囲みたいなら、\b ではなく 「前後が数字でないこと」を直接書くのが確実でした。

今度は採点器を先に検証した

3 度目は、測る前に採点器のほうをテストしました。

正解を拾えるか。

答え: 1800円        -> True
答え: 1,800円       -> True
答え: 53個          -> True
答え: **7**         -> True
答え: 2時間46分40秒 -> True

誤答を弾けるか。

答え: 47個    -> False
答え: 9       -> False
答え: 1700円  -> False

両方を実際の文字列で確かめてから、本番を回しました。

確定した結果

	正答	平均時間	平均トークン	思考
thinking ON	10/10	39.5 秒	925	1,931 字
thinking OFF	10/10	12.6 秒	238	0

正答率は同じ。時間が 3.1 倍、トークンが 3.9 倍。

課題別に見ても、時間差は一貫していました。

課題	種類	ON	OFF	時間比
T1	多段の算術	26.6s / 508tok	9.0s / 145tok	3.0 倍
T2	数え上げ	74.4s / 1762tok	21.8s / 454tok	3.4 倍
T3	日付計算	44.7s / 1028tok	13.1s / 249tok	3.4 倍
T4	単純な抽出	19.0s / 444tok	5.6s / 78tok	3.4 倍
T5	単位変換	34.9s / 864tok	13.4s / 261tok	2.6 倍

効きそうだと踏んだ T1〜T3 でも、正答率は上がりませんでした。 どちらも全問正解です。

T4 が象徴的でした。「配列 [3, 7, 2, 9, 4] の 2 番目に大きい値」を答えるだけで、 969 文字考えて 3.4 倍の時間をかけています。答えは同じ 7 です。

この結論が言えること、言えないこと

言えること。 CLI で thinking を切った判断は、この難易度帯では正しかった。 対価を払うだけの効果はありませんでした。

言えないこと。 今回の課題は「正解が一意に決まり、手順も定型」のものばかりです。 もっと難しい問題では差が出る可能性があります。 その領域は測っていません。

llm -Think "..." で個別に有効化できるようにしてあるので、 「難しそうなときだけ付ける」という使い分けは残してあります。

教訓: 測定器を先に疑う

前回のベンチで「差を見つけたら、まず測定系のばらつきを確かめる」と書きました。 その直後に、今度は測定器そのもののバグを 2 回踏んでいます。

共通していたのは、**最初の結果が「面白かった」**ことです。

• 1 回目は「thinking は考えすぎて自滅する」
• 2 回目は「両方間違えるほど難しい問題だった」

どちらも記事になりそうな筋書きで、そのぶん疑いにくかった。 助かったのは、どちらも物理的・論理的におかしい点があったからでした。 包除原理を正しく解いている出力を見れば、不正解のはずがありません。

測定結果より先に、測定器が正しいかを確かめる。 そのコストは、今回で言えば数分でした。 3 回測り直した時間のほうがずっと長くついています。

まとめ

• thinking を切った判断は、この難易度帯では正しかった（正答率は同率）
• ただし 3.1 倍の時間と 3.9 倍のトークンを使う。定型課題では払う意味が薄い
• 難しい問題での差は測っていない。切り替えられる余地は残す
• \b は日本語で効かない。 .NET は漢字・かなを単語文字とみなす
• 採点器は、本番の前にテストする。 正解を拾えるかと、誤答を弾けるかの両方

測りたかったのは thinking の効果でしたが、 いちばん学んだのは自分の採点スクリプトの信用度でした。