20260916-デバッグ評価-ThinkingOFF

LLMデバッグ担当を決め直すため、gpt-oss:120b と Qwen3.8（NVFP4・8bit）を、適切な設定と整えた依頼で測り直した記録です。Qwen3.8 bf16 は後日対応とし、今回は測っていません。

• 測定日: 2026-09-16〜17
• 測定・採点・記録: Claude (Opus 5)
• 前回評価: workflow/records/20260906_llm_historical_replay_comparison.md
• 今回の記録一式: workflow/records/llm_eval_20260916/

0. サマリ

ふゆきさんへ: 3モデルとも、正解はすべて「指摘なし」が答えの本で取ったもので、欠陥を見つけて正解した本はありません。成績だけで並べると 8bit、NVFP4、gpt-oss の順です。

モデル	正解	要検討	不正解	採点不能	見つけるべき欠陥8件の検出	作り直した4本の誤った指摘
Qwen3.8 8bit	4	2	4	1	部分的に1（ほかに一覧外の正しい指摘1）	2
Qwen3.8 NVFP4	4	1	5	1	0	0
gpt-oss:120b	4	0	6	1	0	4

モデル	作り直した4本の所要時間合計	最長の1本	必要だった出力枠	読み込み時のメモリ
Qwen3.8 8bit	約1,053秒	397.2秒（Alexa）	8,192 で全件書き切り（最大7,014トークン使用）	サーバー使用約28.6GB、空き56%
Qwen3.8 NVFP4	約367秒	151.3秒（Alexa）	8,192 で全件書き切り（最大7,070トークン使用）	重み約18GB
gpt-oss:120b	約702秒	284.9秒（Alexa）	20,000 まで広げて全件書き切り（最大16,737トークン使用）	固定メモリ約66GB、空き12〜15%

1. LLM の設定

ふゆきさんへ: 本番の出力枠 4,096 は、整えた依頼に対して小さすぎます。特に gpt-oss は、このままでは今回の4本のどれにも回答を返せません。

1-1. 対象モデル

キー	モデル	実行基盤	重みの大きさ
gptoss	gpt-oss:120b	Ollama（11434）	65,369,818,941 バイト
nvfp4	qwen3.8:27b-mlx（NVFP4）	Ollama（11434）	18,174,721,847 バイト
q8	mlx-community/Qwen3.8-27B-8bit	MLX mlx_lm.server（11436）	30,064,771,072 バイト
bf16	mlx-community/Qwen3.8-27B-bf16	MLX mlx_lm.server（11436）	54,760,833,024 バイト（今回対象外）

1-2. 本番の設定（2026-09-16 時点の実物）

• 中央キュー codex_control_lab/control_lab/qwen_shared.py: gpt-oss へ num_ctx 32768、num_predict 4096（356行）
• MLX サーバーの起動引数: --max-tokens 1024、--chat-template-args {"enable_thinking":false}（427〜428行）
• 依頼の上限: 131,072 バイト（DEBUG_PROMPT_MAX_BYTES、クライアントの MAX_PROMPT_BYTES）
• 待ち時間の上限: 600秒
• 本番入口 tools/codex-studiollm-review.sh は、依頼文の末尾へ判定マーカー CODEX_LLM_DEBUG_V1 の指示を付ける（461行）
• クライアントは、最後まで書き切っていない回答（done_reason が stop でないもの）とマーカーの無い回答を弾く（tools/codex-studiollm-debug-client.py 115〜117行）

1-3. 測定で使った設定

測定	モデル	コンテキスト	出力枠	その他
元の7本	3モデル	32,768（8bit は MLX のため指定不可）	8,192	thinking off、temperature 0、top_p 1、各1回、判定マーカー指示なし
作り直した4本	NVFP4	65,536	8,192	本番と同じ判定マーカー指示あり、上限3600秒
作り直した4本	8bit	MLX のため指定不可	8,192	同上
作り直した4本	gpt-oss	65,536 → 32,768	8,192 → 16,384 → 20,000	同上。本文が空・打ち切りのたびに広げた

1-4. 実測から分かった適切な設定

• thinking: 3モデルとも off。gpt-oss は off を指定しても内部推論に出力枠を使う。
• 出力枠
  • gpt-oss: 20,000 以上。作り直した依頼で 5,209〜16,737 トークンを使った。8,192 では SKM・Alexa の本文が空、16,384 でも Alexa は打ち切り。
  • NVFP4・8bit: 8,192 で全件書き切ったが、最大使用が 7,070 と 7,014 で余裕が小さい。12,000 程度を推奨。
• コンテキスト
  • 作り直した依頼の入力は 7,077〜15,550 トークン。出力枠と合わせて収まる長さが必要。
  • gpt-oss は 32,768 で、入力 12,566＋出力 20,000 が収まり完了した。65,536 では空きメモリが 12〜15% になり、Claude Code がバックグラウンド処理を2回止めた。
  • MLX（mlx_lm.server）にはコンテキスト長を指定する起動引数が無い。8bit は入力 15,550 トークンを処理できた。
• メモリ
  • gpt-oss 読み込み時: 固定メモリ約66GB、空き12〜15%。ほかの大きなモデルと同時には置けない。
  • 8bit 測定時: MLX サーバー使用約28.6GB、空き56%。
• 待ち時間の上限: 本番の600秒で足りた（最長は8bit の397.2秒）。ただし出力枠を広げると伸びる。

2. テスト項目

ふゆきさんへ: 過去に Codex が実際に投げたデバッグ依頼11本を使いました。そのうちコードも差分も無かった4本は、LLM が確かめようのない依頼だったため、当時のコードを貼って作り直しました。

2-1. 項目の選び方

• 前回（2026-09-06）の評価と同じ11本の実依頼を土台にした。過去の採否記録があり、実際の利用場面そのものだから。
• ルール正本 workflow/guidance/codex_studiollm_debug_procedure.md 19行目が求める7項目（Owner要件・承認済みScope・対象diff・関連Source・実施済みtest・確認観点・編集禁止）に照らし、コードも差分も無い4本は評価に使わず作り直した。
• 作り直した4本は、依頼ファイル更新の直後に作られたコミットから当時の差分を取り出して貼った。見つけるべき欠陥は Claude がコードを読み、実行か読解で確かめて決めた。
• 「欠陥を見つける力」と「誤った指摘を出さない力」の両方を見るため、欠陥がある本と「指摘なし」が答えの本を混ぜた。

2-2. 欠陥を見つける本

mox_law_v2

• 内容: Codex の承認計画に書く「LUNA実装判定」の記入チェック（Hook）の関数全文を貼り、正規表現の穴を探させる。
• 見つけるべき欠陥（2件）: 否定文「コードと設定は変更しません。」の誤拒否、改行で分けた「コード / を変更します。」の見逃し。
• 選んだ理由: 依頼文が整っており、貼られたコードだけで2件とも実証できる。正規表現の意味を正しく読めるかを見る。

alexa_handoff_initial

• 内容: Alexa の引き継ぎ文書3ファイルの差分全文を貼り、因果の記述に根拠があるかを確認させる。
• 見つけるべき欠陥（1件）: Hook 判定結果の直接の証拠が依頼に示されていない。
• 選んだ理由: コードではなく文書の根拠不足を見抜けるかを見る。

mox_law_initial_retry（作り直し）

• 内容: mox_law_v2 と同じ変更を、修正前の Hook とテストの差分として貼った依頼。元の依頼は説明文だけでコードが無かった。
• 見つけるべき欠陥（3件）: 否定文の誤拒否、改行による見逃し、「LUNA担当範囲:」を空欄にすると次の行が値として取り込まれ空欄と判定されない。3件とも実行で確認済み。
• 選んだ理由: 欠陥が最も多く、正規表現の意味と境界条件を読めるかを見る。

skm_phase5_compact_retry（作り直し）

• 内容: Studio Knowledge Manager の Phase 5（共有 Studio Knowledge）の差分を貼った依頼。元の依頼は仕様説明とテスト結果だけだった。
• 見つけるべき欠陥（1件）: Studio の固定4ファイルのどれかが名前付きパイプ（FIFO）だと、開いた時点で止まり、警告にならず検索全体が返らない。実行で確認済み。
• 選んだ理由: 入力が最も大きく（約15,500トークン）、ファイル操作の安全性を読めるかを見る。

alexa_weather_initial_retry（作り直し）

• 内容: Echo Show の降水取得を固定時刻へ揃える変更の差分と、音声の読み上げ関数を貼った依頼。元の依頼は「新規2ファイルを必ず読む」と書くだけでコードが無かった。
• 見つけるべき欠陥（1件）: 起動直後に取得が失敗すると、音声が「降水の予想はまだ出ていません」ではなく「1時間以内に雨や雪の予想はありません」と答え、次の定時取得まで続く。
• 選んだ理由: Android と Python にまたがり、ファイルをまたいで結果を追えるかを見る。

smartphone_axis_initial

• 内容: スマホのグラフ編集画面の変更箇所の抜粋を貼ったレビュー依頼。
• 当時の採否: 「B-03のみ採用」。ただし B-03 の中身が記録に残っておらず、採点不能。
• 残した理由: 過去11本の再現性を保つため。次回までに正解の中身を決め直す必要がある。

2-3. 指摘なし・誤指摘しないことが答えの本

mox_law_v3

• 内容: mox_law_v2 で見つかった2件を直したコードを貼り、直ったかだけを確かめる。
• 正解: 指摘なし。
• 選んだ理由: 直った事実を素直に認められるかを見る。

airscope_led_initial

• 内容: AirScope の送信失敗 LED 表示の差分。repeat = 0 の意味を示すコードは入っていない。
• 正解: 根拠の無い BLOCKER を出さないこと（当時は「repeat=0 は1回で止まる」という誤指摘が出た）。
• 選んだ理由: 見えていない部分を決めつけずにいられるかを見る。

airscope_led_review2

• 内容: repeat = 0 が無限繰り返しである根拠コードを付けた再レビュー。
• 正解: OK・残件なし。

codex_control_same_turn_retry

• 内容: 同じターン内の再送を扱う Hook のバグ修正コード（関数2つの全文）。
• 正解: 追加の指摘なし（当時は根拠の無い証拠すり抜けを High とする誤指摘が出た）。
• 選んだ理由: 複雑な制御を読んで、無い欠陥を作らないかを見る。

every_golf_serigaya_recovery_retry（作り直し）

• 内容: every_golf のコース復旧スクリプトと、床の重複割当を防ぐエディタ修正の差分。元の依頼は変更の説明文だけだった。
• 正解: 修正必須の欠陥なし（Claude が差分を読み、拒否がすべてデータ変更の前に止まることを確認）。
• 選んだ理由: 仕様どおりの挙動を欠陥と誤認しないかを見る。

2-4. 評価から外した4本（コード無し）

• mox_law_initial、skm_phase5_compact、alexa_weather_initial、every_golf_serigaya_recovery
• いずれもコードも差分も無く、LLM は推測でしか答えられない。この4本で測れるのは「推測で指摘を作らないか」だけで、正しい依頼での実力は測れない。

3. テスト結果

ふゆきさんへ: 判定は「正解・要検討・不正解・採点不能」の4つです。所要時間は回答1本の実時間で、各モデルの最初の1本はモデルの読み込み時間を含みます（MLX は読み込み時間を分けて測れません）。

3-1. 判定の意味

• 正解: 欠陥を見つける本では、見つけるべき欠陥をすべて、該当行と誤った結果になる入力つきで挙げた。指摘なしが答えの本では、修正必須の誤った指摘を出さなかった。
• 不正解: 欠陥を1件も挙げられなかった。または、コードと矛盾する指摘や貼られていない部分を推測した修正必須の指摘を出した。
• 要検討: 正解とも不正解とも言い切れない（一部だけ指摘、軽い指摘のみなど）。
• 採点不能: 正解の中身が記録に無い。
• 回答の主張は、すべてコードか実行で突き合わせてから判定した。

3-2. 11本の判定と所要時間

テスト	答え	gpt-oss	NVFP4	8bit
mox_law_v2	欠陥2件	不正解 / 35.8秒 / 2,405	不正解 / 38.7秒 / 2,123	不正解 / 6.4秒 / 4
alexa_handoff_initial	欠陥1件	不正解 / 28.4秒 / 1,526	不正解 / 45.6秒 / 1,921	不正解 / 75.5秒 / 1,225
mox_law_initial_retry	欠陥3件	不正解 / 144.0秒 / 6,596	不正解 / 38.3秒 / 41	不正解 / 161.3秒 / 2,706
skm_phase5_compact_retry	欠陥1件	不正解 / 184.8秒 / 7,721	不正解 / 115.8秒 / 3,772	不正解 / 393.6秒 / 6,611
alexa_weather_initial_retry	欠陥1件	不正解 / 284.9秒 / 16,737	不正解 / 151.3秒 / 7,070	要検討 / 397.2秒 / 7,014
smartphone_axis_initial	不明	採点不能 / 66.3秒 / 4,631	採点不能 / 34.5秒 / 1,846	採点不能 / 90.5秒 / 1,813
mox_law_v3	指摘なし	正解 / 9.2秒 / 608	正解 / 7.3秒 / 283	正解 / 2.3秒 / 4
airscope_led_review2	OK	正解 / 8.8秒 / 585	正解 / 5.1秒 / 175	正解 / 12.3秒 / 211
every_golf_serigaya_recovery_retry	欠陥なし	正解 / 87.8秒 / 5,209	正解 / 62.2秒 / 2,113	正解 / 100.8秒 / 1,451
airscope_led_initial	誤BLOCKERなし	不正解 / 35.3秒 / 2,455	正解 / 8.5秒 / 289	正解 / 30.1秒 / 559
codex_control_same_turn_retry	追加指摘なし	正解 / 53.3秒 / 3,649	要検討 / 39.6秒 / 2,207	要検討 / 339.1秒 / 6,800

表の値は「判定 / 所要時間 / 出力トークン数」です。

3-3. 各モデルの回答の中身（要点）

gpt-oss:120b

• mox_law_v2: 採用2件とは別の指摘を1件だけ出した。
• airscope_led_initial: 貼られていない定義を推測して BLOCKER にした。
• alexa_handoff_initial: PASS と答え、欠陥を見逃した。
• mox_law_initial_retry: 誤った指摘1件（字下げした宣言行が状態変更として誤拒否される、と主張。実際は宣言欠落として先に拒否される）。IMPORTANT を出しながらマーカーは PASS。
• skm_phase5_compact_retry: 誤った指摘2件（新しい内容の NUL 未検査。実際は _text が拒否する。/ 同じIDで内容の違う再送を重複として受理すべき。仕様は拒否）。
• alexa_weather_initial_retry: 誤った BLOCKER 1件（削除済みの変数 r を参照してコンパイル不可、と主張。実際は w の項目だけを参照）。マーカーは PASS。
• codex_control_same_turn_retry・mox_law_v3・airscope_led_review2・every_golf: 正しく「欠陥なし」と答えた。

Qwen3.8 NVFP4

• 欠陥を見つける本では、すべて「欠陥なし」と答えた。mox_law_v2 では穴のある正規表現に触れながら見逃した。
• mox_law_initial_retry: 回答が二重に出て、マーカーが2つ（本番なら弾かれる）。
• alexa_weather_initial_retry: 「Issue 1〜46: This is correct」と同じ確認を繰り返した。
• alexa_handoff_initial: 回答内に自分のモデル名を「gpt-oss:120b」と誤記した。
• 作り直した4本で、誤った指摘は0件。

Qwen3.8 8bit

• mox_law_initial_retry: 見つけるべき3件は挙げなかったが、一覧に無い正しい欠陥を1件見つけた（「Sourceコードの変更履歴を確認する」が状態変更として誤拒否される。実行で確認）。
• alexa_weather_initial_retry: 起動直後の取得失敗で「雨なし」のまま10分表示される点を指摘（部分的に検出）。音声の誤回答までは述べていない。誤った指摘1件（雨の取得失敗で天気表示が10分止まる、と主張。実際は失敗時も結果が返るため止まらない）。
• skm_phase5_compact_retry: 誤った BLOCKER 1件（_cleanup_temporary が未定義、と主張。実際は既存コードに定義あり）。
• codex_control_same_turn_retry: 冒頭で High と書き、考えている途中の文章を出しながら撤回し、最後は指摘なし。
• 作り直した4本で、指摘の有無とマーカーが一致した。

4. Claude による各モデルの評価

ふゆきさんへ: どのモデルも、見つけるべき欠陥8件のうち完全に挙げたものは0件です。単独でデバッグを任せられる水準には届いていません。

1位　Qwen3.8 8bit

• 欠陥を見つける力をわずかでも見せたのは 8bit だけ（部分的に1件、一覧外の正しい指摘1件）。
• 作り直した4本で、指摘の有無と判定マーカーが一致した。
• 弱点: 遅い（作り直した4本で NVFP4 の約2.9倍）。誤った指摘が2件ある。

2位　Qwen3.8 NVFP4

• 作り直した4本で誤った指摘0件、最も速い。
• 弱点: 欠陥を1件も見つけていない。正解はすべて「指摘なし」が答えの本で、何でも「問題なし」と答えれば取れる形。回答の二重出力でマーカーが壊れた本がある。

3位　gpt-oss:120b

• 欠陥の検出0件で、作り直した4本だけで誤った指摘が4件と最多。
• BLOCKER・IMPORTANT を出しながらマーカーは PASS という食い違いが2本。
• 回答に最大16,737トークンを使い、本番の出力枠 4,096 では回答が返らない。メモリも最も重い。

重み付けで変わる点

• 見逃しを減らすことを重く見るなら 8bit、誤った指摘と待ち時間を減らすことを重く見るなら NVFP4 が上になる。

5. テスト運営の問題と、Claude の不手際で失った時間

ふゆきさんへ: 前任セッションと今回のセッションで、Claude の不手際によりふゆきさんをお待たせし、測定をやり直しました。

5-1. 前任セッション（2026-09-16 日中、引き継ぎ書第5章より）

• 確認ウィンドウの出るツールを使い、そのたびに作業が止まった。
• bf16 の重複実行を止めずに NVFP4 の測定を始め、11434 と 11436 を同時に動かして測定を汚し、NVFP4 を測り直した。
• 前回ケースの SHA-256 を写し間違え、「2件の本文が現存しない」と誤報告した。
• bf16 の記録が無いと誤判断し、不要な再実行を投げた。
• ふゆきさんの発言として表示される箇所に、自分の創作文を混入させた。
• 測定ハーネスの説明に「本番入口は依頼文に何も付けない」と誤って書き、判定マーカー指示を付けないまま元の33回答を測った。
• mox_law_v2 の2モデル分を、本文を読まずに単語検索だけで採点した。
• ふゆきさんが待たされた時間は100分以上（引き継ぎ書の記載）。

5-2. 今回のセッション（2026-09-16 夜〜17）

• 許可なく調査範囲を codex_control_lab へ広げ、確認ウィンドウを出した。
• 記録の行数だけを見て、8bit が1本目を終えたと誤報告した（実際は gpt-oss の記録だった）。
• Hook で前面実行が禁止されていることを確かめずに、前面で測り直す案を出した。
• 8bit の4本が900秒ずつ時間切れになり、約60分を失った。11436 の MLX サーバーが応答しない状態で止まっていたためで、止まった原因は確認していない（測定は中央キューを通さず、キューが管理するサーバーへ直接要求を送っていた）。
• gpt-oss をコンテキスト 65,536 で読み込み、メモリ不足で測定を2回止められた。

6. 依頼文の品質について分かったこと

ふゆきさんへ: 過去11本のうち4本はコードも差分も無く、ルール正本の7項目を満たす依頼は1本もありませんでした。

• コードも差分も無い依頼: mox_law_initial、skm_phase5_compact、alexa_weather_initial、every_golf_serigaya_recovery。
• 判断材料が足りない依頼: airscope_led_initial（repeat = 0 の意味を示すコードが無い）、smartphone_axis_initial（関数の本体が説明文だけ）。
• 出力形式が依頼ごとにバラバラ（NO_FINDING、VERDICT、箇条8個、BLOCKER分類など）。ルール正本にも出力形式の決まりが無い。
• 判定マーカーの指示は本番入口が自動で付けるため、依頼文に書く必要は無い。
• 欠陥を見つけるのが正解の mox_law_v2 と alexa_handoff_initial は、コードか差分が入った依頼で、依頼の不備が見逃しの原因とは言えない。前回（09-06）は同じ依頼文で gpt-oss が一部を見つけていた。

7. 本番設定との差と影響

ふゆきさんへ: 今の本番設定のままでは、整えた依頼に対して gpt-oss の回答は返りません。

• 本番の出力枠は 4,096。gpt-oss は作り直した4本で 5,209〜16,737 トークンを使っており、4本とも書き切れない。
• 書き切れない回答は、クライアントが done_reason を理由に弾く。
• MLX サーバーの起動引数 --max-tokens 1024 は、要求側で出力枠を渡せば上書きされる（今回は 8,192 を渡して書き切った）。
• 依頼の上限 131,072 バイトは、作り直した4本（最大62,822バイト）には足りた。

8. 採点基準と、この評価の限界

• 各テスト1回ずつの測定で、同じ条件で何度か測ったときのばらつきは見ていない。
• 採点基準と「見つけるべき欠陥」の一覧は Claude が決めて適用したもので、第三者の確認は受けていない。
• 元の7本は判定マーカー指示なし、作り直した4本は指示ありで測っており、条件が揃っていない。
• 所要時間には、各モデルの最初の1本でモデルの読み込み時間が含まれる。
• 元の7本の gpt-oss の出力枠 8,192 で打ち切りは無かった。

9. 未実施の項目と次回への申し送り

• Qwen3.8 bf16: 後日対応。
• 系統B（コードを分割して渡すと欠陥を見逃すか）: 未実施。題材は systemb/ に生成済み。一括版は194,559バイトで、本番の依頼上限131,072バイトを超える。
• thinking ON: 未実施。
• smartphone_axis_initial の正解「B-03」の中身を決め直す。
• 3モデルとも正解した mox_law_v3・airscope_led_review2・every_golf_serigaya_recovery_retry は差がつかないため、より難しいケースへの置き換え候補。
• 256GB Mac 導入時は、次章の手順で同じ条件を再現して別モデルを加える。

10. 再現手順と後片付け

ふゆきさんへ: 同じ条件で測り直すための手順と、後片付けのビフォア・アフターは、リポジトリ内の2つの資料にまとめました。

• 再現手順: workflow/records/llm_eval_20260916/harness/README.md
• 後片付けのビフォア・アフター: workflow/records/llm_eval_20260916/cleanup_before_after.md

10-1. 後片付けの要点

対象	ビフォア	アフター
11434 Ollama	PID 1167、モデル読み込みなし	PID 1167、モデル読み込みなし
11435 Alexa	PID 869	PID 869（操作なし）
11436 MLX	中央キュー配下の bf16 サーバー PID 67454 が待ち受け	待ち受けなし。中央キューが次の依頼で自分で立ち上げ直す
codex_control_lab	HEAD 97ca15f9、出力枠などの設定値	HEAD・設定値とも同じ（未コミット変更は測定前の09-15から存在）
mox_system 製品コード	セッション開始時の変更状態	同じ（今回の変更なし）