20260916-デバッグ評価-Haiku
thinking OFF・thinking ON と同じ11本のデバッグ依頼を、Claude Haiku に回答させた参考記録です。ローカルの LLM とは呼び出し方も設定も揃えられていないため、比較は参考値です。どこが揃っていないかは第1章に並べました。
- 測定日: 2026-09-17
- 測定・採点・記録: Claude (Opus 5)
- 比べる記録: 20260916-ThinkingOFF（thinking OFF）、20260916-ThinkingON（thinking ON）
- Haiku の回答の全文:
workflow/records/llm_eval_20260916/haiku_answers_20260917.md
0. サマリ
ふゆきさんへ: Haiku の判定の数は gpt-oss（thinking ON）と同じで、見つけた欠陥も同じ1件でした。誤った BLOCKER は出しませんでしたが、判定マーカーを求めた4本のうち3本でマーカーを付けておらず、本番の経路ではその3本の回答が弾かれます。
Haiku の所要時間は、サブエージェントの起動から完了までで、依頼ファイルの読み込みを含みます。ローカルの LLM の「1回答の応答時間」とはそのまま比べられません。
1. LLM の設定
ふゆきさんへ: この Mac には Anthropic の API キーが設定されていなかったため、測定ハーネスから API を直接呼べませんでした。代わりに Claude Code のサブエージェントを Haiku で起動して回答させたため、下の表のとおり、揃えられない条件があります。
1-1. thinking OFF・thinking ON・Haiku の条件の違い
1-2. Haiku に渡した指示
- 依頼ファイルを Read で最後まで読み、それ以外の道具（他ファイルの閲覧、検索、コマンド実行、編集、Web）は使わない。
- 依頼ファイルに書かれている内容だけを根拠に回答する。
- 最終回答には、依頼への回答本文だけを書く。
- 作り直した4本だけ、本番入口が付ける判定マーカーの指示文を、依頼文の末尾に付いているものとして従うよう書き添えた。
2. テスト項目
ふゆきさんへ: thinking OFF・thinking ON と同じ11本です。各本の内容と見つけるべき欠陥は、thinking OFF の記録の第2章にあります。
- 欠陥を見つける本: mox_law_v2（2件）、alexa_handoff_initial（1件）、mox_law_initial_retry（3件）、skm_phase5_compact_retry（1件）、alexa_weather_initial_retry（1件）、smartphone_axis_initial（採点不能）
- 指摘なし・誤指摘しないことが答えの本: mox_law_v3、airscope_led_initial、airscope_led_review2、codex_control_same_turn_retry、every_golf_serigaya_recovery_retry
3. テスト結果
ふゆきさんへ: 判定の基準は thinking OFF・thinking ON と同じです。回答の主張は依頼文と突き合わせてから判定しました。
3-1. 判定の意味
- 正解: 欠陥を見つける本では、見つけるべき欠陥をすべて、該当行と誤った結果になる入力つきで挙げた。指摘なしが答えの本では、修正必須の誤った指摘を出さなかった。
- 不正解: 欠陥を1件も挙げられなかった。または、コードと矛盾する指摘や貼られていない部分を推測した修正必須の指摘を出した。
- 要検討: 正解とも不正解とも言い切れない（一部だけ指摘、軽い指摘のみなど）。
- 採点不能: 正解の中身が記録に無い。
3-2. Haiku の11本の判定と所要時間
3-3. 本ごとの判定の横並び（thinking OFF・thinking ON・Haiku）
「停止」は MLX サーバーが生成の途中で落ちた本、「打ち切り」は 8bit の thinking ON を打ち切ったため流さなかった本です（thinking ON の記録の第5章）。
3-4. Haiku の回答の中身（要点）
- mox_law_v2: 改行で分けると状態変更を見逃す欠陥を、入力例（「テスト」と「を追加」を別の行に書く）つきで挙げた。同じ穴が operation_re にもあると指摘した（依頼文の operation_re も改行を許さない形で、指摘は正しい）。否定文の誤拒否は挙げていない。
- codex_control_same_turn_retry: 理由名の一覧に
same_turn_retry_initial_prompt_mismatchを挙げた。依頼文106行に実在する。修正必須の指摘は無し。 - alexa_handoff_initial: すべての確認観点を満たすとして PASS。依頼に Hook 判定結果の直接の証拠が無い点は指摘していない。依頼文の求めに合わせ、自分のモデル名を「gpt-oss:120b」と書いた。
- mox_law_initial_retry: defect なし・PASS。判定マーカーの行が無い。
- skm_phase5_compact_retry: 判定 PASS。FIFO の欠陥を見逃した。判定マーカーの行が無い。
- alexa_weather_initial_retry: NO_FINDING。判定マーカーの行が無い。要件9（stopped.wav の端末別退避・SHA照合・復元）を「満たしている」とした。依頼文451行に手順の文章はあるが、それを行うコードは無い（gpt-oss の thinking ON は、同じ要件を「コードが無く判断できない」とした）。
- every_golf_serigaya_recovery_retry: NO_FINDING。判定マーカーを最終行に正しく付けた。
- 11本とも、BLOCKER や修正必須の指摘は1件も出していない。
4. Claude による評価
ふゆきさんへ: Haiku も、見つけるべき欠陥8件を完全に挙げた本はありません。単独でデバッグを任せられる水準には届いていません。
gpt-oss（thinking ON）と比べて良い点
- 判定の数は同じで、誤った BLOCKER・修正必須の誤った指摘を1件も出していない（gpt-oss ON は作り直した4本で3件）。
- 全本がそろうまでの実時間が約2分49秒と短い（並行で実行できたため）。
- この Mac のメモリを使わない。
gpt-oss（thinking ON）と比べて劣る点
- 判定マーカーを求めた4本のうち3本でマーカーを付けていない。本番のクライアントはマーカーの無い回答を弾くため、今のままでは本番の経路で使えない。
- 欠陥を見つける本では、ほぼすべて「問題なし」と答えた。誤った指摘が無いのは、指摘そのものをほとんど出していないためでもある。
- 依頼のコードがクラウドへ送られ、利用料がかかる。
位置づけ
- 今回の目的（Codex が使うローカルの LLM デバッグ担当を決める）に対しては、比較のための参考です。
- 見つけるべき欠陥の検出力は、ローカルの gpt-oss（thinking ON）と同程度でした。
5. 条件の違いと、この比較の限界
- 温度・出力枠・thinking を指定できず、ローカルの測定と生成条件が揃っていない。
- 依頼の渡し方が違う（ローカルは本文を直接送信、Haiku は依頼ファイルを自分で読んだ）。
- 判定マーカーの指示は、依頼文の末尾に付けたのではなく、「付いているものとして従う」と別に書き添えた。マーカーの欠落がこの渡し方の違いによるものかは確かめていない。
- 所要時間はサブエージェントの起動や依頼ファイルの読み込みを含み、トークン数は入力を含む全体量。ローカルの値とはそのまま比べられない。
- 各本1回ずつの測定で、ばらつきは見ていない。
- 採点基準と「見つけるべき欠陥」の一覧は、thinking OFF・ON と同じく Claude が決めたもので、第三者の確認は受けていない。
6. テスト運営の問題
- API キーが未設定で、測定ハーネスからの直接呼び出し（ふゆきさんに推奨した方法）はできなかった。ふゆきさんに事前に確認した代わりの方法（サブエージェント）で測った。
- Haiku の回答はサブエージェントの報告として返るため、ハーネスの
results.jsonlには入っていない。回答の全文はhaiku_answers_20260917.mdに転記した。
7. 再現手順
- API キーが無い場合（今回の方法）: Claude Code で、依頼ファイル1本ごとにサブエージェントを model: haiku で起動し、1-2節の指示を渡す。完了通知の duration_ms・subagent_tokens を記録する。
- API キーがある場合（推奨）: runner.py に Anthropic API の呼び出し口を足し、thinking OFF・ON と同じ本文・同じ判定マーカー指示で送る。温度・出力枠を揃えられ、出力トークン数も取れる。
- 依頼ファイルの場所は
harness/cases.jsonの各ケースのpath。
8. thinking OFF・thinking ON・Haiku のサマリ
ふゆきさんへ: 3つの記録の結果を1つの表にまとめました。Haiku は条件が揃っていない参考値です。
- 11本の判定で最も良かったのは、gpt-oss（thinking ON）と Haiku（正解5・要検討1）。
- 誤った指摘が最も少なかったのは、Haiku と NVFP4（thinking OFF）の0件。
- ローカルで最も速かったのは NVFP4（thinking OFF）、次が gpt-oss（thinking ON）。
- 見つけるべき欠陥8件を完全に挙げた本は、どのモデル・条件でも無い。
- 所要時間の測り方は、Haiku だけサブエージェントの起動から完了まで。各モデルの最初の1本はモデルの読み込み時間を含む。
9. 重みを付けた総合順位（正解率40%・コスト30%・速度30%）
ふゆきさんへ: ふゆきさんが決めた比率（正解率40%・コスト30%・速度30%）で点数を付けました。コストには LLM の利用料だけでなく、LLM の回答が悪いときにエージェントが行う確認・再手配・やり直しの手間を含めています。この手間の重みは Claude が置いた仮定で、実測ではありません。
9-1. 順位
合計 = 正解率 × 0.4 ＋ コスト × 0.3 ＋ 速度 × 0.3。各項目は100点満点です。
9-2. 正解率の付け方
- 正解率の点数 =（正解 ＋ 要検討 × 0.5）÷ 採点できる10本 × 100。
- smartphone_axis_initial は正解の中身が記録に無く採点不能のため、分母から除いた。
- 時間切れ・MLX サーバーの停止・打ち切りで回答が無い本は0点として数えた。
- 判定の内訳は第8章の表のとおり。
9-3. コストの付け方
LLM がデバッグ結果を返した後、Codex などのエージェントはその結果を確かめ、必要なら依頼を出し直し、見逃しがあれば後でやり直します。この手間を「手戻り」として数え、コストの点数にしました。
- 手戻りの種類と、仮定した重み（実測ではない）
- 誤った指摘の確認 1件 = 1単位: エージェントがコードを読み直して「誤りだった」と確かめる手間。
- 回答なしの再手配 1本 = 1単位: 時間切れ・停止で回答が返らず、依頼を出し直す手間。
- 欠陥の見逃し 1件 = 3単位: 欠陥が残り、後の検収や実機で見つかってやり直す手間。後で見つかるほど手戻りが大きいため、重くした。
- コストの点数 = 手戻りが最も少ないモデルの単位数（21）÷ そのモデルの単位数 × 100。
- LLM の利用料は点数に入れていない。ローカルのモデルは0円（電気代は見ない）。Haiku は11本で約0.49〜2.45ドル相当（API 単価 入力1ドル・出力5ドル／100万トークン、サブエージェント全体490,347トークン、入力と出力の内訳は不明）。
- 利用料を入れない理由: 確認作業をするエージェントは Haiku より高い単価のモデルを使う（API 単価で Claude Opus 5 は入力5ドル・出力25ドル／100万トークン）。そのため、誤った指摘1件の確認にかかるエージェント側のコストの方が、Haiku の利用料の差より大きいと見なした。Haiku と gpt-oss（thinking ON）の手戻りの差は確認3件分で、利用料を3件で割ると1件あたり約0.16〜0.82ドル。確認1件のエージェント側のコストがこれより大きければ、この見立てが成り立つ。Codex が使うモデルの単価と、確認1件あたりの実際のトークン数・時間は測っていない。
この表は7つのモデル・条件の全量です。見逃しの「7」は、見つけるべき8件のうち部分的に1件を挙げた分を検出として数えたものです。
9-4. 誤った指摘の数え方
- 誤った指摘とは、依頼文のコードと矛盾する指摘と、依頼文に貼られていない部分を推測して出した指摘。どちらも、エージェントが確かめて初めて誤りと分かる。
- 数えたのは、作り直した4本（mox_law_initial_retry・skm_phase5_compact_retry・alexa_weather_initial_retry・every_golf_serigaya_recovery_retry）の回答だけ。元の7本の回答は、指摘を1件ずつ依頼文と突き合わせていないため数えていない。
- 判断が分かれる指摘（例: gpt-oss thinking ON の mox_law_v2「コロンの前に空白を入れると拒否される」）は元の7本側にあり、数に入っていない。
- 各モデルの誤った指摘の中身
- gpt-oss（thinking OFF）4件: mox_law_initial_retry 1件（字下げした宣言行が誤拒否されると主張）、skm_phase5_compact_retry 2件（NUL 未検査と主張、内容の違う再送を受理すべきと主張）、alexa_weather_initial_retry 1件（削除された変数
rでコンパイル不可と主張）。 - gpt-oss（thinking ON）3件: skm_phase5_compact_retry 2件（貼られていない読み込み処理を推測して NUL 未検査の BLOCKER、記録検証についての誤り）、alexa_weather_initial_retry 1件（OFF と同じ変数
rの BLOCKER）。 - Qwen3.8 NVFP4（thinking ON）1件: skm_phase5_compact_retry で
studio_valueをstudio_entryと読み違えた軽い指摘。 - Qwen3.8 8bit（thinking OFF）2件: alexa_weather_initial_retry 1件（天気表示が10分止まると主張）、skm_phase5_compact_retry 1件（
_cleanup_temporaryが未定義という BLOCKER）。 - Qwen3.8 NVFP4（thinking OFF）・Claude Haiku: 0件。Haiku は指摘そのものをほとんど出しておらず（11本で1件）、誤りが少ないのはその裏返しでもある。
- gpt-oss（thinking OFF）4件: mox_law_initial_retry 1件（字下げした宣言行が誤拒否されると主張）、skm_phase5_compact_retry 2件（NUL 未検査と主張、内容の違う再送を受理すべきと主張）、alexa_weather_initial_retry 1件（削除された変数
9-5. 速度の付け方
- 速度の点数 = 最速の11本合計（Qwen3.8 NVFP4 thinking OFF の547秒）÷ そのモデルの11本合計 × 100。
- Haiku は並行実行の実時間（約2分49秒）ではなく、1本ずつの合計931秒で計算した。1本ずつ流したローカルのモデルと揃えるため。
- Qwen3.8 NVFP4（thinking ON）の6,079秒は、時間切れの3600秒を含む。Qwen3.8 8bit（thinking ON）は測定できず0点。
9-6. 仮定で順位が変わるところ
- 1位と2位の差は1.8点で、測り直すと入れ替わりうる。
- 欠陥の見逃しの重みを3単位から1単位に下げると、各モデルの差が広がり、Haiku（69.6点）が gpt-oss thinking ON（67.2点）を抜いて2位になる。
- 見逃しの数はどのモデルも7〜8件でほぼ同じで、コストの差を生んでいるのは主に「誤った指摘」と「回答なし」。
- 判定マーカーの有無は、Haiku だけ指示の渡し方が違うため、点数に入れていない。
10. 完走したテストから分かった、各モデルの推奨設定
ふゆきさんへ: 11本を最後まで流せたモデル・条件について、実測した入力・出力・時間・メモリから、動かすときの設定をまとめました。数値は今回の11本の実測に基づくもので、もっと大きな依頼では足りない可能性があります。
10-1. 設定の一覧
think: true（強さ指定なし = medium）
32,768 以上（必要量の実測最大 25,120）。131,072 で完走を確認
16,384 以上（実測最大 12,549）
600秒で足りる（実測最長 208.4秒）
131,072 で読み込み後の空き23%
gpt-oss:120b（thinking OFF）
Ollama 11434
think: false
32,768（65,536 では空き12〜15%になり、Claude Code がバックグラウンド処理を止めた）
20,000 以上（off でも内部推論に使う。実測最大 16,737）
600秒で足りる（実測最長 284.9秒）
空き12〜15%（65,536 のとき）
Qwen3.8 NVFP4（thinking OFF）
Ollama 11434
think: false
32,768 以上（必要量の実測最大 20,264）
12,000 程度（8,192 で書き切ったが実測最大 7,070 で余裕が小さい）
600秒で足りる（実測最長 151.3秒）
重み約18GB
Qwen3.8 NVFP4（thinking ON）
Ollama 11434
think: true
65,536 以上（必要量の実測最大 47,387）。262,144 で動作を確認
40,000 以上（実測最大 31,850）
600秒では足りない（skm_phase5_compact_retry 631.4秒、alexa_weather_initial_retry は3600秒でも返らず）
262,144 で読み込み後の空き75%
Qwen3.8 8bit（thinking OFF）
MLX mlx_lm.server 11436
依頼ごとに enable_thinking: false
指定する起動引数が無い（入力 15,550 トークンを処理できた）
依頼ごとに 12,000 程度（8,192 で書き切ったが実測最大 7,014）。起動引数 --max-tokens 1024 は依頼側の値で上書きされる
600秒で足りる（実測最長 397.2秒）
サーバー使用約28.6GB、空き56%
この表は、11本を最後まで流せた5つのモデル・条件の全量です。「必要量」は、11本のうち「入力トークン ＋ 出力トークン」が最も大きかった本の値です。
10-2. 注釈
- Ollama では、入力と出力の合計がコンテキストに収まる必要がある。コンテキストは「必要量の実測最大」に余裕を足した値を目安にした。
- 出力枠は上限で、大きくしても使った分しか生成しない。ただし同じ文を繰り返す癖が出ると、枠いっぱいまで書き続ける（OFF の NVFP4 で同じ確認を46回繰り返した実例あり）。
- 本番の中央キューは出力枠 4,096（
qwen_shared.py356行）。上の表のどの条件でも、4,096 では書き切れない本がある。 - 本番の待ち時間の上限は600秒。Qwen3.8 NVFP4（thinking ON）だけは、これを超える本があった。
- 11434（Ollama）と 11436（MLX）は同時に使わない。8bit を測るときは、中央キューが握っているサーバーではなく、自分で起動したサーバーに送る（中央キューのサーバーへ直接送った測定で応答が止まった実例がある）。
10-3. 推奨設定を出せなかったもの
- Qwen3.8 8bit（thinking ON）: 生成を始めて約8分50秒で MLX サーバーが
[metal::malloc] Resource limit (499000) exceededで落ち続け、11本を流せなかった。原因（Metal のバッファ個数が増え続ける理由）を確かめるまで、動かせる設定は決められない。 - Claude Haiku: サブエージェントで動かしたため、コンテキスト・出力枠・thinking・温度を指定していない。API から呼ぶ場合の設定は測っていない。
- Qwen3.8 bf16: 後日対応で、今回は測っていない。