20260918-コーディング評価

0. ふゆきさん向けのまとめ

ローカルLLMに実際のコミットと同じ実装を書かせ、テストと検収で合否を測りました。小さな変更ならローカルに任せられます。落ちる原因はコードの理解力ではなく、ファイル全文を書き写すときの崩れです。

• 任せられる目安（実測から）: 渡すファイルの合計が 60KB 程度まで、返させる全文が 1.2万トークン程度まで。
• この範囲の題材（易1 25KB・易2 54KB・中2 28KB・中3 36KB）では、ローカルの各条件が1〜3回で合格した例があります。
• 範囲の外（中1 129KB・難1 102KB）は、どの条件も不合格でした。1回の生成に NVFP4 で約12〜14分、8bit で約34〜38分かかります。
• 所要時間は難しさではなく返す量で決まります（8bit: 出力 5,723トークンで 278秒 ／ 出力 36,272トークンで 2,062秒）。

決めていただきたいこと: ①任せる範囲の線（上の目安で良いか） ②空白の変更だけで不合格にする基準を続けるか ③1トライ目をローカル、NG なら Haiku か Luna に回す運用を採るか。

1. 測った内容

過去の実コミット6本を題材に、Opus が要件と関係コードの全文を渡して発注し、モデルが変更後のファイルを全文で返し、Opus がテストとチェックリストで検収しました。NG は最大3回まで直させ、3回目も NG なら不合格です。

• 易1: codex_control_lab f7c3862（2ファイル・依頼 約25KB）
• 易2: mox_system f3e69844（hub.py と contract.json・約54KB）
• 中1: alexa_cfw00 6e7e0f0（2ファイル・約129KB）
• 中2: codex_control_lab e3cb8a4（1ファイル・約28KB）
• 中3: mox_system 6a3aa19c（新規222行ほか・約36KB）
• 難1: mox_system 0e1e43b6（7ファイル・約102KB）

条件は Qwen3.8 NVFP4（思考なし／思考あり）、gpt-oss:120b（思考あり／思考なし）、Qwen3.8 8bit（思考なし）、参考として Claude Haiku です。テストはモデルに見せず、修正依頼には指摘と落ちたテスト名・例外だけを渡しました。

2. 結果のサマリ

下の表は測定した全量です。空欄は測っていません。

判定済み22本の内訳は、合格11本・不合格9本・保留2本です。

3. 時間と量の実測

下の表は、その題材を終えるまでの全トライの合計です（全量）。ローカルは出力トークン数、Haiku はサブエージェントの全体量（入力を含む）で、そのままでは比べられません。

返す量と時間の関係が最もはっきり出たのは 8bit です。易1（出力 5,723）が 278秒、中1（出力 36,272）が 2,062秒で、約6.3倍の出力に約7.4倍の時間がかかりました。

4. 落ちた原因

不合格9本の、最後のトライでの理由です（全量）。

テストが全部通ったのに不合格になったのは4本（NVFP4 思考なしの中1・難1、NVFP4 思考ありの易2、8bit 思考なしの中1）です。いずれも要件外の書き換えが残ったためです。

5. 判定の基準と注意書き

頼んでいない変更は、動作に関係しない空白の変更でも NG としました。この厳しさが妥当かどうかは未決で、ふゆきさんのご判断を待っています。

• 空白の変更だけで不合格にした本: NVFP4 思考なしの中1（テスト 353/353・空白約60か所）、NVFP4 思考なしの難1（64/64・空白2行）、NVFP4 思考ありの易2（110/110・空白約30行）。
• その回だけ空白で NG にした例: gpt-oss 思考ありの易2 1回目（110/110・空行1行）。最終判定は別の理由です。
• 足したコードの中の空行（空白だけの行を含む）は NG にしていません。既存の行の書き換えではないためです。

6. Claude Haiku の参考結果

Haiku は Claude Code のサブエージェントで測りました（API からは測れないため）。

• 易1・易2 は1回目で合格。難1 は3回目で合格（1回目 59/64 → 2回目 64/64 で要件のずれ → 3回目で全て解消）。
• 中1 は、出力上限32,000トークンに達して回答が途中で切れ、続きを別の発言で出し直したため、取り込んだ回答に片方のファイルが無く形式崩れになりました。ふゆきさんのご指示で不合格として記録しています。
• 中2・中3 は1回目 NG のまま保留です（有料であることを踏まえ、全体が一通り終わった後にリトライする方針）。

7. ローカルに任せられる範囲

実測から引いた目安です。判定は、渡すファイルのバイト数と返させる量だけで決まるため、誰でも同じに判定できます。

8. 運用の案

• 範囲内は1トライ目をローカル、NG なら Haiku か Luna に回す。範囲内ではローカルが1〜3回で合格に届いています。
• 範囲外は最初から上位モデルに回す。30分以上かけた末に不合格になる例が出ています。
• 検収の費用を抑えるため、頼んでいない変更は機械で先に弾く。差分の変更行数だけで判別できます（易1 は合格が7行、不合格が95行）。
• 大きいファイルは、全文ではなく変更箇所だけを返させる形が要ります。ただしこの形は今回測っておらず、見込みです。

9. 採点（重みつきの順位）

6本すべてを測れた条件が無いため、易1・易2 の2本がそろっている6条件だけで順位を出しました。重みは正確さ40%・手戻り30%・速度30%です。正確さは合格本数、手戻りは総トライ数、速度は2本の合計秒で、いずれも最良を100点として比べています。

この順位は易1・易2 の2本だけの結果です。全6本での順位は、条件ごとに測った本数が違うため出していません。Haiku の利用料は、トークン量の内訳（入力と出力）を分けて測れていないため、金額は入れていません。

10. 未測定と残務

• 打ち切り: 8bit 思考なしの中1・中2（2026-09-18・所要時間が題材の大きさに見合わないため）。以降の 8bit 思考なしの題材と、8bit 思考ありは未着手です。
• 未測定: NVFP4 思考ありの中1〜難1、gpt-oss（思考あり・思考なし）の中1〜難1。いずれも範囲の外に当たる大きい題材が多く、結論が変わりにくいと判断しています。
• 残務: Claude Haiku の中2・中3 のリトライ。Qwen3.8 bf16 の扱いは未定です。

11. 記録の置き場所

• 記録一式: workflow/records/llm_coding_eval_20260917/（依頼文 prompts、回答 answers、テスト結果 checks、検収 reviews、進捗 progress.md）
• 判定の注記と残務: workflow/records/llm_coding_eval_20260917/review_notes.md
• ハーネス: harness/coding_runner.py（発注・テスト・取り込み）、harness/answer_diff.py（差分）、harness/run_q8_coding.py（8bit 用にサーバーを題材ごとに起動・終了）
• 計画書: workflow/plans/plan_llm_coding_eval_260917.md

この本文の数値は、上の記録ファイルから集計したものです。表はいずれも代表例ではなく、測定した全量です。