ai_work

• ブログの素案
• テスト
• テスト2
• 【試験】web_book_agent 2026-09-18
• 【試験】下書き CZ-697D 2026-09-18
• 【試験】新規記事 アップグレードの選び方 2026-09-18
• ITX68000Lにフロッピーディスクの「魂」を灯す
• 【試験】ITX68000L 書き直し 2026-09-18
• ITX68000Lにフロッピーの鼓動を！ イジェクトボタンとアクセスLEDの実装
• フロッピーの鼓動を、筐体で。ITX68000LにイジェクトボタンとアクセスLEDを実装した話
• LLM性能評価
• 20260916-デバッグ評価-ThinkingOFF
• 20260916-デバッグ評価-ThinkingON
• 20260916-デバッグ評価-Haiku
• 20260918-コーディング評価

ブログの素案

テスト

転記元URL: https://zinichi.net/home/cz-697d2_00/
タイトル: 止まらない進化！？ CZ-697Dのアップグレードを紹介！
カテゴリ: 3Dプリンター/DIY
投稿日: 2025.02.01

おかげさまでご好評いただいているCZ-697Dですが、姉妹品の CZ-617D の制作を通じて、色々とやりたかったことが実現できました。せっかく作った仕組みということで、CZ-697Dにも適用してみました。これらの機能は新規でご購入いただく方向けだけでなく、既存の購入者様に向けて有償アップグレードも対応いたします。

ことの発端

おかげさまでご好評いただいているCZ-697Dですが、姉妹品の CZ-617D の制作を通じて、色々とやりたかったことが実現できました。

せっかく作った仕組みということで、CZ-697Dにも適用してみました。

これらの機能は新規でご購入いただく方向けだけでなく、既存の購入者様に向けて有償アップグレードも対応いたします。

機能拡張１：ステレオスピーカーのマウント

X68000をご存じの方であれば全員が憧れた「あのスピーカー」を1/2サイズで制作したことがあります。今回のアップグレードで、このスピーカーをマウントできるようになりました！

マウンタの取り付け方は簡単。まずはマウンタをスピーカーに取り付けます。板ナットをセットした状態で、スピーカーへセット、ネジ止めするだけです。

モニターに対しても、同じ要領でネジ穴にあわせて取り付けてください。

一方で、このスピーカーの取り付けは、横に隙間が空くという課題があります。今回はZと並べて使うためのマウンタも付属させます。

専用マウンタを使うことで、やや高いところに取り付けます。実際にZと並べてみるとピッタリです。

【画像挿入位置：CZ-697Dにステレオスピーカーをマウントした状態、および専用マウンタを使用してZと並べた際の隙間がなくなった状態の写真】

機能拡張２：折りたたみ式スタンドと固定力の大幅強化

CZ-697Dの初期型は、スタンドが収納できませんでした。

しかし今回のアップグレードによりスタンドをたたむことができるようになり、使わない時は立てかけておくことができるようになります。

更にスピーカーを安定してマウントさせるために、スタンドの保持力を上げるためのゴムワッシャーの取り付けに対応しました。

【画像挿入位置：折りたたみ式スタンドの構造、およびゴムワッシャーを取り付けたスタンドの保持力強化の様子】

機能拡張３：リモコン操作に対応

#CZ697D をリモコン操作してみた😀 こいつぁ使いやすいぜーっ！ @kunichiko はんには足向けて寝られまへんなぁ😊 pic.twitter.com/2xYjS9vWLm — ふゆき@パンタロン (@zinfyk) February 1, 2025

配布版はピッピッって受信音は鳴りません

今回の目玉機能です。CZ-697Dは普段使いにはちょうどよいモニタですが、VGAとHDMIの切替や音量などの変更をするときに、背面のボタンを押す必要があります。

長年これがやりづらいと思っていましたが、なななんと、リモコン操作できるようにアクセサリを制作していただきました！

作者は、あの KeplerX の制作者でもある くにちこ( @kunichiko ) さんです。あっという間の実装にびっくり(^^) くにちこさん、素晴らしいアイテムをありがとうございます！

詳細は別途投稿しますが、リモコンの信号を受信するための「レシーバーユニットとコントローラー」で構成しています。

なお、ブラウン管のCZモニターに付属していたコントローラー（リモコン）を使って操作することもできます。

リモコン操作できるモニターって実は希少ですよね！

【画像挿入位置：リモコン操作によるCZ-697Dの動作デモ、またはレシーバーユニットとコントローラーの構成図】

拡張機能４：電飾ユニットのLED

リモコンの受信ユニットを取り付けることで、より本物っぽくLEDが点灯するようになります。

受光部は15KHzの裏に設置されていまして、モニターの電源がOFFの時は主電源のみ、受信状態時はその他のLEDも点灯するようになります。

嬉しいディテールアップです。

【画像挿入位置：リモコン受信時に点灯する電飾ユニットのLEDの様子】

新型CZスピーカーの紹介

過去に数回配布したことがあるCZスピーカーは、もともとダイソーの300円スピーカーをリメイクしていました。

残念ながら終売となったため、新たにバージョンアップしました。

ユニットは小型化しましたが、良いアンプを搭載したことで互角の音が出るようになったと思っています。

今回はスピーカー取り付けの拡張を行うため、この投稿にて紹介いたします。

変更内容：１：スピーカーユニットを変更 ２：密閉型ハウジングへ変更 ３：電源入力端子をUSB-TypeCに変更（これは自動的に5Vへ変換して給電できるものを採用しています）

#CZスピーカー の調整が完了したので、ダイソースピーカーと因縁（？）の対決をさせてみた😀 ちなみにこのCZスピーカーはダイソースピーカーは一切使っていないので、もはやリメイクではなくなりました😊 比較するとダイソースピーカーは音が薄いですね、原因は箱の剛性かな🤔 pic.twitter.com/gK9T4EqtwK — ふゆき@パンタロン (@zinfyk) January 18, 2025 （音量注意）

CZスピーカーを仕上げてみた 今回のバージョンアップによって、電源はTypeCを使えるようにしました 給電側はAもCもおk😀 なか綿の量を半分にすることで少し音の角を取れました（プラシーボ🤔 pic.twitter.com/gCgRWulqsJ — ふゆき@パンタロン (@zinfyk) January 12, 2025

まぁコストは３倍以上に増えてしまったんですけどね（白目

【画像挿入位置：新型CZスピーカーの外観、ダイソースピーカーとの比較、およびUSB-TypeC給電の様子】

アップグレードプランの紹介

これらの内容はすべて必要というものではないと思います、なのでプランを選べるようにします。

【新外装】内容物: 造形物（フロント・リア・スタンド）・受光部パーツ・スイッチパーツ(１つ)・ゴムワッシャー(２つ)・デカール・背面ステッカー。説明（できること）: スピーカーのマウント、収納式スタンドの対応

【受信機】内容物: 受光機能付きLEDユニット・赤外線制御ユニット・PHケーブル・電源配線用ケーブル・取り付けネジ(M2-6を2本・ワッシャー2つ)。説明（できること）: CZモニター用コントローラー（リモコン）からの赤外線を受信

【リモコン】内容物: リモコン（コントローラー）。説明（できること）: CZ-697D、CZ-617D、各ブラウン管CZモニタの操作が可能

【CZスピーカー】内容物: ステレオスピーカー・スピーカーマウンタ(6つ) 取り付けネジ(M4-10を2本・M3-15と板ナット4組)。説明（できること）: CZ-697Dの音声を高音質に再生できるようになります。

すでにリモコンをお持ちの方のために、赤外線の受信機とコントローラーを別プランとしました。

新外装、受信機のみのプランは、既存ユーザー様向け限定といたします。

アップグレード作業は私の方で対応させていただきますが、御本人で行っていただくことも可能です。

2025年1月以降に新しくCZ-697Dをご購入いただく方は、新規外装版のご提供となります。

価格は仕入れにより変化しますので、配布時に都度設定とさせていただきます。

あとがき

これまでも細かな調整は適宜行っていたものの、大きな機能拡張を行わせていただきましたが、更に便利に楽しく使えるようになりました！

費用や配布時期はXで告知いたします。

おしまい

テスト2

【試験】web_book_agent 2026-09-18

目的

道具の書き込み試験です。

更新試験。

項目	値
表の試験	2026-09-18

【試験】下書き CZ-697D 2026-09-18

おかげさまでご好評いただいているCZ-697Dですが、姉妹品のCZ-617Dの制作を通じて、色々とやりたかったことが実現できました。せっかく作った仕組みということで、CZ-697Dにも適用してみました。これらの機能は新規でご購入いただく方向けだけでなく、既存の購入者様に向けて有償アップグレードも対応いたします。

ことの発端

CZ-697Dは、ふゆきじんいちさんが手がけるCZシリーズのモニターです。姉妹品のCZ-617Dを制作する過程で、いくつかの機能拡張が実現しました。そこで、せっかく作った仕組みをCZ-697Dにも適用し、既存の購入者様にも有償アップグレードとして提供することになりました。

機能拡張１：ステレオスピーカーのマウント

X68000をご存じの方であれば全員が憧れた「あのスピーカー」を1/2サイズで制作したことがあります。今回のアップグレードで、このスピーカーをマウントできるようになりました。

【画像挿入位置：1/2サイズのステレオスピーカーの全体写真】

マウンタの取り付け方は簡単です。まずはマウンタをスピーカーに取り付けます。板ナットをセットした状態で、スピーカーへセットし、ネジ止めするだけです。

【画像挿入位置：マウンタをスピーカーにネジ止めする作業写真】

モニターに対しても、同じ要領でネジ穴にあわせて取り付けてください。

一方で、このスピーカーの取り付けは、横に隙間が空くという課題があります。今回はZと並べて使うためのマウンタも付属させます。

【画像挿入位置：専用マウンタを使った取り付けイメージ】

専用マウンタを使うことで、やや高いところに取り付けます。実際にZと並べてみるとピッタリです。

【画像挿入位置：Zと並べて設置したスピーカーの完成写真】

機能拡張２：折りたたみ式スタンドと固定力の大幅強化

CZ-697Dの初期型は、スタンドが収納できませんでした。しかし今回のアップグレードによりスタンドをたたむことができるようになり、使わない時は立てかけておくことができるようになります。

【画像挿入位置：折りたたみ式スタンドのたたみ方と立てかけ状態の写真】

更にスピーカーを安定してマウントさせるために、スタンドの保持力を上げるためのゴムワッシャーの取り付けに対応しました。

機能拡張３：リモコン操作に対応

今回の目玉機能です。CZ-697Dは普段使いにはちょうどよいモニタですが、VGAとHDMIの切替や音量などの変更をするときに、背面のボタンを押す必要があります。長年これがやりづらいと思っていましたが、なんとリモコン操作できるようにアクセサリを制作していただきました。

作者は、あのKeplerXの制作者でもあるくにちこ（@kunichiko）さんです。あっという間の実装にびっくりしました。くにちこさん、素晴らしいアイテムをありがとうございます！

【画像挿入位置：リモコン操作のデモ写真】

詳細は別途投稿しますが、リモコンの信号を受信するための「レシーバーユニットとコントローラー」で構成しています。なお、ブラウン管のCZモニターに付属していたコントローラー（リモコン）を使って操作することもできます。リモコン操作できるモニターって実は希少ですよね！

配布版はピッピッって受信音は鳴りません。

拡張機能４：電飾ユニットのLED

リモコンの受信ユニットを取り付けることで、より本物っぽくLEDが点灯するようになります。受光部は15KHzの裏に設置されていまして、モニターの電源がOFFの時は主電源のみ、受信状態時はその他のLEDも点灯するようになります。嬉しいディテールアップです。

【画像挿入位置：LEDが点灯した電飾ユニットの写真】

新型CZスピーカーの紹介

過去に数回配布したことがあるCZスピーカーは、もともとダイソーの300円スピーカーをリメイクしていました。残念ながら終売となったため、新たにバージョンアップしました。ユニットは小型化しましたが、良いアンプを搭載したことで互角の音が出るようになったと思っています。今回はスピーカー取り付けの拡張を行うため、この投稿にて紹介いたします。

【画像挿入位置：新型CZスピーカーの全体写真】

変更内容は以下の通りです。

１：スピーカーユニットを変更
２：密閉型ハウジングへ変更
３：電源入力端子をUSB-TypeCに変更（これは自動的に5Vへ変換して給電できるものを採用しています）

比較するとダイソースピーカーは音が薄いですね、原因は箱の剛性かな。まぁコストは３倍以上に増えてしまったんですけどね（白目）

アップグレードプランの紹介

これらの内容はすべて必要というものではないと思います、なのでプランを選べるようにします。

プラン	内容物	説明（できること）
新外装	造形物（フロント・リア・スタンド）・受光部パーツ・スイッチパーツ(１つ)・ゴムワッシャー(２つ)・デカール・背面ステッカー	スピーカーのマウント、収納式スタンドの対応
受信機	受光機能付きLEDユニット・赤外線制御ユニット・PHケーブル・電源配線用ケーブル・取り付けネジ(M2-6を2本・ワッシャー2つ)	CZモニター用コントローラー（リモコン）からの赤外線を受信
リモコン	リモコン（コントローラー）	CZ-697D、CZ-617D、各ブラウン管CZモニタの操作が可能
CZスピーカー	ステレオスピーカー・スピーカーマウンタ(6つ)・取り付けネジ(M4-10を2本・M3-15と板ナット4組)	CZ-697Dの音声を高音質に再生できるようになります。

すでにリモコンをお持ちの方のために、赤外線の受信機とコントローラーを別プランとしました。新外装、受信機のみのプランは、既存ユーザー様向け限定といたします。アップグレード作業は私の方で対応させていただきますが、御本人で行っていただくことも可能です。2025年1月以降に新しくCZ-697Dをご購入いただく方は、新規外装版のご提供となります。価格は仕入れにより変化しますので、配布時に都度設定とさせていただきます。

あとがき

これまでも細かな調整は適宜行っていたものの、大きな機能拡張を行わせていただきましたが、更に便利に楽しく使えるようになりました！費用や配布時期はXで告知いたします。

おしまい

【試験】新規記事 アップグレードの選び方 2026-09-18

CZ-697Dをすでにお持ちの方へ、有償アップグレードの選び方についてまとめます。今回のアップグレードは4つのプラン（新外装・受信機・リモコン・CZスピーカー）から構成されています。既存の購入者向けには、新外装と受信機のみのプランが限定で用意されます。費用や配布時期はXで告知されるため、ここでは「自分に必要なプランはどれか」を選ぶための目安として書いています。

4つのプランでできること

まず、各プランで何が変わるのかを整理します。

新外装：フロント・リア・スタンドの造形物、受光部パーツ、スイッチパーツ、ゴムワッシャー、デカール、背面ステッカーが含まれます。ステレオスピーカーのマウントが可能になり、スタンドは折りたたみ式で使わない時は収納できます。ゴムワッシャーでスピーカーの保持力も強化されます。

受信機：受光機能付きLEDユニット、赤外線制御ユニット、ケーブル類、取り付けネジが含まれます。リモコンからの赤外線信号を受信してリモコン操作に対応し、電飾ユニットのLEDが点灯して本物らしいディテールアップが実現します。

リモコン：CZ-697D、CZ-617D、および各ブラウン管CZモニタの操作が可能になります。VGA/HDMI切替や音量変更など、背面ボタン操作が不要になり利便性が向上します。すでにリモコンをお持ちの方は、このプランをスキップして受信機のみ購入できます。

CZスピーカー：ステレオスピーカー、マウンタ、取り付けネジが含まれます。CZ-697Dの音声を高音質で再生できるようになります。小型化しつつ良いアンプを搭載し、従来のダイソースピーカーリメイク版と同等以上の音質を実現しています。密閉型ハウジングに変更され、電源入力端子がUSB-TypeCに変更されています。

既存購入者向けの限定プラン

既存の購入者向けには、新外装と受信機のみのプランが限定で用意されます。すでにCZ-697Dをお持ちで、外装を新バージョンに更新しつつリモコン操作と電飾の点灯に対応させたい方には、この限定プランがそのまま対象になります。

自分に必要なプランの選び方

選び方の目安を挙げます。

外装を新バージョンに更新したい、スピーカーのマウントを可能にしたい場合は新外装。リモコン操作に対応させたい、電飾のLEDを点灯させたい場合は受信機。リモコン自体をまだ持っていない場合はリモコンも必要です（すでに持っていれば受信機のみでよい）。音声を高音質で再生したい場合はCZスピーカー。

既存購入者の方は、限定プラン（新外装＋受信機）を軸に考え、リモコンを持っていない場合はリモコンを追加、音質向上も欲しい場合はCZスピーカーを追加、という形になります。

費用と配布時期

費用や配布時期はXで告知されます。具体的な金額や時期はここでは書かないので、告知を待ってください。

【画像挿入位置：4つのプラン（新外装・受信機・リモコン・CZスピーカー）の全体像を示す写真】

ITX68000Lにフロッピーディスクの「魂」を灯す

ITX68000Lに、フロッピーディスクのイジェクトボタンとアクセスLEDを実装しました。X68000用エミュレータと連携して、実機さながらの挙動を再現しています。

X68000という存在

1987年にシャープが発売したX68000は、当時としては画期的な性能を持つビンテージコンピュータでした。最大65,536色の表示能力やFM音源による豊かなサウンド、そしてコーディングのしやすさを武器に、少年たちの心を掴みました。

このマシンは、ゲームクリエイターやCGアーティストなど、コンピュータを使いこなす様々なクリエイターを排出しました。私自身も、X68000でゲームを遊び、その表現力の高さに魅了された一人です。

【画像挿入位置：X68000の実機写真（マンハッタンシェイプのツインタワー型デザイン）】

ITX68000Lの現状

ITX68000Lは、私が制作・頒布しているMiniITXマザーボード用PCケースです。X68000のデザインを再現しつつ、RTX 4070 Ti Superのような大型グラボまで搭載できる設計になっています。

幅140・高さ325・奥行き295mmのコンパクトな筐体に、SFX-L電源や2.5インチSSD2基、背面・底面・天面のファン配置まで詰め込みました。ABSとレジン素材で制作しています。

すでにHDDのアクセスランプを実装しており、X68000が電源のON/OFFに連動して独特な点滅を行う挙動を忠実に再現しています。

【画像挿入位置：ITX68000Lの完成写真（グラボ搭載状態）】

欠けていたもの

X68000にあって、ITX68000Lにまだなかったものは2つです。

1. フロッピーディスクのイジェクトボタン
2. フロッピードライブのアクセスステータスを表示するLED

これらがなければ、X68000の「魂」が完全に再現されたとは言えません。今回、この2つを開発しました。

XEiJ+t と XM6t

ただし、これらの機能を利用するには、XEiJ+t と XM6t という「X68000用エミュレータ」を使う必要があります。エミュレータ上でX68000を動かすことで、フロッピーディスクのアクセスやイジェクトのシグナルを取得し、物理的なLEDやボタンに反映させる仕組みです。

実現できると思っていなかった

正直に言うと、長年Windowsで動かしているX68000のエミュレータのフロッピードライブに関する情報を、物理的なLEDに連動させるなんてことができると思っていなかったんです。

SNSで「やりたい」とつぶやいたところ、以前からお世話になっている「たんぼ」さんから「やってみよう」と声をかけていただきました。

テスト制作

本当に実現できるかを検証するために、秋月電子さんで「USB接続デジタル入出力モジュール」を購入しました。これをPCに接続し、以下の流れでLEDを点滅させることに成功しました。

WINDOWS → X68000エミュレータ → USB接続デジタル入出力モジュール → LED

【画像挿入位置：USB接続デジタル入出力モジュールとLEDの接続写真】

本制作

しかし、秋月電子のUSB接続デジタル入出力モジュールでは、ITX68000Lの筐体に入らないことが判明しました。小型のモジュールを開発する必要があり、また、専用のファームウェアの開発も必要です。

秋月電子のモジュールに書かれている回路図を参考に、担当を振り分けた結果、以下のようになりました。

• 回路図：たんぼさん、ふゆき
• PCB：ふゆき、たんぼさんの先輩
• ファームウェア：たんぼさん

まさに最強布陣です。

【画像挿入位置：開発した小型モジュールの基板写真】

嬉しいハプニング

もともとはフロッピーディスクのアクセスLEDだけの対応予定だったのですが、せっかく基板をつくるのであれば、ディスクイジェクトボタンも対応しよう！ということになりました。

ええ、なんでもできるんですね。

素人の試行錯誤

ふゆきのKiCadレベルは緑帯程度です。たんぼさんの先輩に色々とご監修いただきつつ、試行錯誤を繰り返しました。

【画像挿入位置：KiCadでのPCB設計画面のスクリーンショット】

筐体の見直し

LEDランプはもともと光らせる余地を残していたものの、イジェクトボタンは想定外でした。CADデータの修正、押し心地の確認、コンパクトな筐体に無駄なく装着できるように小型化させるなど、実は困難を極めました。

【画像挿入位置：イジェクトボタンの装着部分の拡大写真】

完成

XM6tを使い、大好きなゲームを動かしました。フロッピーディスクのアクセスもイジェクトボタンも完璧に動作します。

実際にディスクが出てこないのが変な感じです。

【画像挿入位置：完成したITX68000Lでゲームを動かしている写真（フロッピーLED点灯中）】

あとがき

（ここは私が書く。）

【試験】ITX68000L 書き直し 2026-09-18

今回は、私が制作・頒布しているX68000風MiniITXケース「ITX68000L」に、フロッピーディスクのイジェクトボタンとアクセスLEDを実装した話です。Windows上で動くX68000用エミュレータの動作を、筐体の物理的なボタンやLEDに連動させるという、もともと実現できると思っていなかったことを、たんぼさんたちと協力して形にしました。レトロPCの自作や、エミュレータの周辺機器化に興味のある方に向けて書いています。

予備知識：X68000シリーズ

X68000は、1987年にシャープが発売したパーソナルコンピュータで、現在では伝説のビンテージコンピュータとして知られています。最大6万5536色のグラフィックスやFM音源による音楽性能など、当時としては画期的な性能を備えており、少年たちの心を強く掴みました。

表現力の高さやコーディングのしやすさを武器に、X68000はコンピュータを使いこなすさまざまなクリエイターを排出しました。システムコールやハードウェア構成が公開されていたこともあって、自作や改造の文化も根づいた、特別なマシンだったと言えます。

予備知識：ITX68000L

ITX68000Lは、X68000の外観を再現したMiniITXマザーボード用のPCケースで、私が制作・頒布しているものです。一般的なMiniITXマザーボードに対応し、2.5スロット・長さ270mmまでのビデオカードまで搭載できるのが特徴です。

対応パーツや組み込みの手順は、私のブログの「グラボも入るぞ！ ITX68000Lを紹介！」と「グラボも入る『ITX68000L』パーツ組み込み編！」の2記事に詳しく記載しています。今回の記事は、その筐体に追加した機能の話です。

すでに実装されているもの

ITX68000Lには、HDDのアクセスランプの点灯がすでに実装されています。X68000は電源のON/OFFに連動して、独特な点滅を行なうのですが、この挙動を忠実に再現しています。

一方で、X68000にあってITX68000Lにないものも2つありました。1つはフロッピーディスクのイジェクトボタン、もう1つはフロッピードライブのアクセスステータスを表示するLEDです。今回開発したのは、まさにこの2つです。

そもそも実現できると思っていなかった

長年Windowsで動かしているX68000のエミュレータについて、フロッピードライブに関する情報を物理的なLEDに連動させるなんてことができるのか、私は正直思っていなかった。エミュレータはあくまでソフトウェアの世界で、筐体のハードウェアにまで手を伸ばす発想が私にはなかったのです。

ところがSNSでそのことをつぶやいたところ、以前からお世話になっている「たんぼ」さんから「やってみよう」と声をかけていただきました。ここから、今回の開発が始まります。なお、XEiJ+tとXM6tというX68000用エミュレータを使うことで、今回実装した機能を利用できます。

テスト制作

本当に実現できるかを検証するために、まず秋月電子さんで「USB接続デジタル入出力モジュール」を購入しました。これをPCに接続し、エミュレータから信号を送ってLEDを点滅させる構成を試します。

Windows → X68000エミュレータ → USB接続デジタル入出力モジュール → LED、という流れでLEDを点滅させることに成功しました。エミュレータのフロッピーアクセス情報をUSB経由で取り出し、物理的なLEDに反映できることが実証されたのです。

本制作

ところが、テストに使った秋月電子のUSB接続デジタル入出力モジュールは、ITX68000Lの筐体に入らないことがわかりました。小型のモジュールを開発する必要があり、さらに専用のファームウェアの開発も必要になります。

そこで、秋月電子のモジュールに書かれている回路図を参考に、担当を振り分けることにしました。回路図はたんぼさんとふゆき、PCBはふゆきとたんぼさんの先輩、ファームウェアはたんぼさんが担当します。まさに最強布陣である。

嬉しいハプニング発生！

もともとは、フロッピーディスクのアクセスLEDだけの対応予定でした。しかし、せっかく基板をつくるのであれば、ディスクイジェクトボタンも対応しよう、ということになりました。

ええ、なんでもできるんですね。基板を1枚増やすコストはかかりますが、LEDとボタンをまとめて実装できるなら、筐体としての完成度は大きく上がります。この判断は、後の完成度を大きく左右するものになりました。

いうてもふゆきは素人

いうてもふゆきは素人です。ふゆきのKicadレベルは緑帯程度で、PCB設計の経験はほとんどありません。

たんぼさんの先輩に色々とご監修いただきつつ、試行錯誤を繰り返しました。回路の検証、レイアウトの修正、実装後の動作確認。素人だからこそ手間がかかる工程を、先輩方の知見を借りながら一つずつ乗り越えていきました。

ITX68000Lの見直し

LEDランプはもともと光らせる余地を残していたものの、イジェクトボタンは想定外でした。ボタンをどこに置くのか、どうやって筐体に組み込むのか、ゼロから考え直す必要があったのです。

CADデータの修正、押し心地の確認、コンパクトな筐体に無駄なく装着できるように小型化させるなど、実は困難を極めました。既存の筐体を壊さずに機能を追加するというのは、一見簡単なようでいて、寸法や強度、使い心地のバランスをすべて取り直す作業になります。

完成

完成したITX68000Lで、XM6tをつかい、大好きなゲームを動かしました。フロッピーディスクのアクセスもイジェクトボタンも、完璧に動作します。

実際にディスクが出てこないのが変な感じです。ボタンを押すと「カチッ」と音がしてLEDが点滅するのに、ディスクは出てこない。エミュレータの世界と現実の筐体が、ちょうどいい距離感で混ざり合っている、そんな感覚です。

あとがき

（ふゆきさんが書く）

ITX68000Lにフロッピーの鼓動を！ イジェクトボタンとアクセスLEDの実装

目次

・予備知識：X68000シリーズ
・予備知識：ITX68000L
・すでに実装されているもの
・X68000にあって、ITX68000Lにないもの
・今回開発したもの
・そもそも実現できると思っていなかった
・テスト制作
・本制作
・嬉しいハプニング発生！
・いうてもふゆきは素人
・ITX68000Lの見直し
・完成
・あとがき

予備知識：X68000シリーズ

X68000シリーズは、シャープが1987年に発売したパーソナルコンピュータのシリーズです。通称「ペケロク」「ロクハチ」と呼ばれ、今では伝説のビンテージコンピュータとして語り継がれています。

当時としては画期的な性能を備えていました。最大6万5536色の多色グラフィック、シンセサイザーに匹敵するFM音源、そしてアセンブラが扱いやすいMC68000の命令セット。少年たちの心を掴んで離さなかったのは、まさにこの表現力の高さです。

さらにコーディングのしやすさという武器もあり、X68000はコンピュータを使いこなす様々なクリエイターを排出しました。ゲームクリエイター、音楽クリエイター、そして数多くの同人作家。このマシンからキャリアをスタートさせた人々は、今もなお日本のエンタメ業界を支えています。

【画像挿入位置：X68000の実機写真（マンハッタンシェイプの筐体）】

予備知識：ITX68000L

ITX68000Lは、MiniITXマザーボード用のPCケースです。X68000の筐体を忠実に再現しつつ、現代のPCパーツを搭載できるように設計しています。これは私が制作・頒布しているものです。

幅140・高さ325・奥行き295mmのコンパクトな筐体に、GeForce RTX4070Ti Superクラスのビデオカードまで収まる設計が特徴です。X68000の「マンハッタンシェイプ」を3Dプリンターで再現し、実機さながらの佇まいをデスクの上で楽しめます。

詳細は下記のページに記載していますので、あわせてご覧ください。

・グラボも入るぞ！ ITX68000Lを紹介！
・グラボも入る「ITX68000L」パーツ組み込み編！

【画像挿入位置：ITX68000Lの完成写真（実機との比較）】

すでに実装されているもの

ITX68000Lには、すでにHDDのアクセスランプの点灯機能が実装されています。X68000は電源のON/OFFに連動して独特な点滅を行うのですが、この挙動を忠実に再現しています。

電源を入れると、HDDのランプがゆっくりと点滅しながら起動していく。あの「X68000が息を吸っている」ような感覚を、現代のPCでも味わえるようにしたかったのです。この部分はすでに完成しており、多くのフォロワーさんにも好評をいただいています。

【画像挿入位置：HDDアクセスランプの点滅の様子】

X68000にあって、ITX68000Lにないもの

しかし、X68000にあってITX68000Lにないものがありました。それは以下の2点です。

１：フロッピーディスクのイジェクトボタン
２：フロッピードライブのアクセスステータスを表示するLED

X68000のフロントには、5.25インチのフロッピーディスクドライブが2基搭載されていました。ディスクを挿入するとアクセスLEDが点滅し、イジェクトボタンを押すとディスクが「カチッ」と出てくる。あの操作感と、LEDの点滅がもたらす「マシンが動いている」感覚は、X68000の体験を語る上で欠かせない要素です。

ITX68000Lは現代のPCケースなので、物理的なフロッピードライブは搭載していません。しかし、X68000のエミュレータを動かす場合、この「フロッピーの鼓動」がないと、どうしても物足りなさを感じてしまうのです。

【画像挿入位置：X68000実機のフロント（FDDとイジェクトボタン、LED）】

今回開発したもの

そこで今回、以下の2つを開発しました。

１：フロッピーディスクのイジェクトボタン
２：フロッピードライブのアクセスステータスを表示するLED

ただし、これらはXEiJ+tとXM6tという「X68000用エミュレータ」を使うことで初めて機能します。エミュレータがフロッピードライブのアクセス情報を検知し、それを物理的なLEDに連動させる。さらにイジェクトボタンを押すと、エミュレータ上の仮想ディスクが「イジェクト」される、という仕組みです。

【画像挿入位置：XEiJ+t / XM6tのスクリーンショット】

そもそも実現できると思っていなかった

正直に告白すると、そもそも実現できると思っていなかったのです。

長年Windowsで動かしているX68000のエミュレータ。そのフロッピードライブに関する情報を、物理的なLEDに連動させるなんてことができるのか？ イジェクトボタンを押して、エミュレータ上のディスクが出てくるなんて、夢のまた夢だと思っていたのです。

ある日、SNSで「ITX68000LにフロッピーのLEDとイジェクトボタンをつけられたらいいなぁ」とつぶやいたところ、以前からお世話になっている「たんぼ」さんから「やってみよう」と声をかけていただきました。

あの瞬間、胸が熱くなりました。自分では「無理だ」と諦めていたことを、誰かが「やってみよう」と言ってくれる。その一言が、このプロジェクトの始まりでした。

【画像挿入位置：SNSでのつぶやきとたんぼさんのリプライのスクリーンショット】

テスト制作

本当に実現できるかを検証するために、まずテスト制作から始めました。

秋月電子さんで「USB接続デジタル入出力モジュール」を購入し、これをPCに接続します。そして、以下の流れでLEDを点滅させることに成功しました。

WINDOWS → X68000エミュレータ → USB接続デジタル入出力モジュール → LED

エミュレータがフロッピーにアクセスした瞬間、USBモジュール経由でLEDが点灯する。あの「カチッ」という音は 없지만、LEDの点滅を見るたびに「X68000が動いている」という実感が湧いてきました。

このテストで、原理的には実現可能であることが確認できました。次の課題は、このUSBモジュールをITX68000Lの筐体にはめ込むことです。

【画像挿入位置：USB接続デジタル入出力モジュールとPCの接続写真】

本制作

しかし、秋月電子のUSB接続デジタル入出力モジュールでは、ITX68000Lの筐体に入らないことが判明しました。幅140mmのコンパクトな筐体に、このサイズのモジュールは収まりません。

そこで、小型のモジュールを開発する必要がありました。また、専用のファームウェアの開発も必要です。秋月電子のモジュールに書かれている回路図を参考に、担当を振り分けていただきました。

回路図：たんぼさん、ふゆき
PCB：ふゆき、たんぼさんの先輩
ファームウェア：たんぼさん

まさに最強布陣です。回路設計、PCB設計、ファームウェア開発の3本柱が揃い、それぞれが得意分野を担ってくれました。この布陣があれば、きっと実現できる。そう確信しました。

【画像挿入位置：回路図とPCB設計のスクリーンショット】

嬉しいハプニング発生！

本制作が進む中で、嬉しいハプニングが発生しました。

もともとはフロッピーディスクのアクセスLEDだけの対応予定だったのですが、「せっかく基板をつくるのであれば、ディスクイジェクトボタンも対応しよう！」とたんぼさんから提案があったのです。

ええ、なんでもできるんですね（白目）

LEDだけならUSBモジュールの流用で済んだかもしれないのに、基板を新規に作るならボタンも足そう、という発想。この「ついでに全部やろう」精神こそ、DIYの醍醐味だと思います。結果として、ITX68000LはX68000のフロントをより忠実に再現できるようになりました。

【画像挿入位置：イジェクトボタンを追加した基板の写真】

いうてもふゆきは素人

しかし、いうてもふゆきは素人です。

ふゆきのKicadレベルは緑帯程度。PCB設計は初めてというわけではありませんが、実用的な基板を設計するのは初めてです。たんぼさんの先輩に色々とご監修いただきつつ、試行錯誤を繰り返しました。

配線のルートを間違えたり、コンポーネントの配置が筐体に収まらなかったり、はんだ付けで足を飛ばしたり。そのあたりは割愛しますが、トラブルや超えなければならない壁などたくさんありました。

それでも、先輩の「ここはこうするといいよ」という一言が、いつも背中を押してくれました。素人でも、正しい人に助けてもらえれば、ちゃんと形にできる。そう実感したプロジェクトでした。

【画像挿入位置：KicadでのPCB設計画面と、はんだ付け中の写真】

ITX68000Lの見直し

LEDランプはもともと光らせる余地を残していたものの、イジェクトボタンは想定外でした。

CADデータの修正、押し心地の確認、コンパクトな筐体に無駄なく装着できるように小型化させるなど、じつは困難を極めました。幅140mmの筐体に、ボタンを押しやすく、かつ見た目を崩さずに配置する。このバランス調整に、何度もCADをいじくり回しました。

ボタンの押し心地も重要です。X68000のイジェクトボタンは「カチッ」とした感触がありますが、3Dプリンターで再現するのは意外と難しい。素材の硬さ、バネの強さ、ストロークの長さ。何度も試作を繰り返し、やっと「これだ」という感触に辿り着きました。

【画像挿入位置：CADデータと、イジェクトボタンの試作写真】

完成

そして、完成です。

XM6tを使い、大好きなゲームを動かします。フロッピーディスクのアクセスも、イジェクトボタンも、完璧に動作します。ディスクを「挿入」するとLEDが点滅し、イジェクトボタンを押すと「カチッ」と音がして、エミュレータ上のディスクがイジェクトされる。

ただし、実際にディスクが出てこないのが変な感じです（汗）

物理的には何も出てこないのに、ボタンを押した瞬間に「ディスクが出た」という感覚になる。この「実在しないものの実在感」を、X68000の体験として再現できたことに、大きな満足感があります。

【画像挿入位置：完成したITX68000Lでゲームを動かしている写真（LED点滅とイジェクトボタン）】

あとがき

（ふゆきさんが書く）

おしまい

フロッピーの鼓動を、筐体で。ITX68000LにイジェクトボタンとアクセスLEDを実装した話

ITX68000Lに、フロッピーディスクのイジェクトボタンと、アクセスLEDを実装しました。X68000用エミュレータを動かしながら、実機さながらにランプが点滅し、ボタンを押すとディスクがイジェクトされる、あの感覚を、コンパクトな筐体の中で味わえるようにした話です。

目次

• ことの発端
• ITX68000Lに、まだなかったもの
• そもそも実現できると思っていなかった
• テスト制作：秋月のモジュールで検証
• 本制作：最強布陣で基板を開発
• 嬉しいハプニング発生！
• いうてもふゆきは素人
• ITX68000Lの見直し
• 完成
• あとがき

ことの発端

ITX68000Lは、私が制作・頒布しているMiniITXマザーボード用のPCケースです。X68000の佇まいを、今のパーツで再現できる、そんなケースです。

実はこのケース、HDDのアクセスランプはすでに実装済みでした。X68000は電源のON/OFFに連動して独特な点滅を行なうのですが、その挙動を忠実に再現しているんです。電源を入れると、あの懐かしいリズムでランプが明滅する。このあたりは、すでに完成していた部分です。

【画像挿入位置：ITX68000Lの全体と、点滅するHDDアクセスランプ】

ITX68000Lに、まだなかったもの

ただ、X68000にあってITX68000Lにないものが、二つありました。

一つは、フロッピーディスクのイジェクトボタン。もう一つは、フロッピードライブのアクセスステータスを表示するLEDです。実機では、ディスクを読み書きするたびにこのLEDが点滅し、ボタンを押すとディスクが「カチッ」と出てくる。あの感覚が、ITX68000Lにはまだなかったんです。

そこで今回、この二つを実装することにしました。ただし、XEiJ+t と XM6t というX68000用エミュレータを使うことで、これらの機能を利用できるようにします。実機のドライブそのものではなく、エミュレータの情報を物理的なボタンとLEDに落とし込む、という形です。

【画像挿入位置：実機のフロッピーイジェクトボタンとアクセスLED、とITX68000Lの比較】

そもそも実現できると思っていなかった

正直に言いますと、そもそも実現できると思っていなかったんです。

長年Windowsで動かしているX68000のエミュレータ。そのフロッピードライブに関する情報を、物理的なLEDに連動させるなんてことができるのか、と。エミュレータの中の世界と、筐体の外の物理世界を繋ぐ、その橋が架かるのか、自分では到底想像がつきませんでした。

ところが、SNSで「やりたいなぁ」とつぶやいたところ、以前からお世話になっている「たんぼ」さんから「やってみよう」と声をかけていただいたんです。この一言が、すべてのはじまりでした。

テスト制作：秋月のモジュールで検証

本当に実現できるのか、まず検証したかったんです。そこで秋月電子さんで「USB接続デジタル入出力モジュール」を購入しました。

これをPCに接続して、次のような流れでLEDを点滅させてみたんです。

WINDOWS → X68000エミュレータ → USB接続デジタル入出力モジュール → LED

……点滅しました。エミュレータのフロッピーアクセスが、物理的なLEDにちゃんと反映されたんです。あの瞬間、本当に嬉しかった。実現できる、と確信できた瞬間でした。

【画像挿入位置：USB接続デジタル入出力モジュールと、点滅するLEDのテスト風景】

本制作：最強布陣で基板を開発

ただ、ここで壁にぶつかりました。秋月電子のUSB接続デジタル入出力モジュールでは、ITX68000Lの筐体に入らないんです。コンパクトな筐体に収めるには、小型のモジュールを開発する必要があり、また専用のファームウエアの開発も必要でした。

そこで、秋月電子のモジュールに書かれている回路図を参考に、担当を振り分けたんです。

回路図：たんぼさん、ふゆき
PCB：ふゆき、たんぼさんの先輩
ファームウエア：たんぼさん

まさに最強布陣である。回路・基板・ファームウエア、それぞれの得意な人が揃った、この布陣に、ふゆきも胸を躍らせました。

【画像挿入位置：開発した小型モジュールの基板と、回路図】

嬉しいハプニング発生！

ここで、嬉しいハプニングが発生しました。

もともとは、フロッピーディスクのアクセスLEDだけの対応予定だったんです。ところが、「せっかく基板をつくるのであれば、ディスクイジェクトボタンも対応しよう！」となったんです。

ええ、なんでもできるんですね。LEDだけならLEDだけ、ボタンもつけたいならボタンも、と。基板を新しく作るなら、ここで一気に両方対応してしまう、という、なんとも贅沢な判断が下りました。我ながら、この布陣の強さを実感した瞬間です（白目）

いうてもふゆきは素人

とはいえ、いうてもふゆきは素人です。

ふゆきのKicadレベルは、緑帯程度。PCBの設計は、たんぼさんの先輩に色々とご監修いただきつつ、試行錯誤を繰り返しました。ここは、先輩の知恵と、ふゆきの根性で乗り切った、そんな感じでした。

【画像挿入位置：KicadでPCBを設計している画面、または監修をいただく様子】

ITX68000Lの見直し

基板ができたところで、今度は筐体側の話です。

LEDランプは、もともと光らせる余地を残してはいたものの、イジェクトボタンは完全に想定外でした。ボタンを置く場所が、そもそもなかったんです。

そこでITX68000Lの見直しに着手しました。CADデータの修正、押し心地の確認、コンパクトな筐体に無駄なく装着できるように小型化させるなど、じつは困難を極めたんです。押し心地が硬すぎても、柔らかすぎてもいけない。あの「カチッ」とした実機の感覚に近づけるには、何度も試作を繰り返しました。

【画像挿入位置：イジェクトボタンの試作と、押し心地を確認している様子】

完成

そして、完成です。

XM6tをつかい、大好きなゲームを動かします。フロッピーディスクのアクセスも、イジェクトボタンも、完璧に動作するんです。ディスクを読み書きするたびにLEDが点滅し、ボタンを押すと「カチッ」と反応する。

ただ、一つだけ変なところがあります。実際にディスクが出てこないんです。ボタンを押しても、物理的なディスクは出てこない。あの「カチッ」という感覚だけが、そこにある。ちょっとだけ、寂しいような、嬉しいような、そんな気持ちになりました。

【画像挿入位置：XM6tを動かしながら、点滅するアクセスLEDとイジェクトボタン】

あとがき

（ふゆきさんが書く）

おしまい

LLM性能評価

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 製品コード	セッション開始時の変更状態	同じ（今回の変更なし）

20260916-デバッグ評価-ThinkingON

thinking OFF の測定（20260916-ThinkingOFF）と同じ11本を、thinking ON で測り直した記録です。コンテキストは各モデルの上限、出力枠は大きめにとりました。系統B（分割の比較）は保留、Qwen3.8 bf16 は後日対応のため、今回は測っていません。

• 測定日: 2026-09-17
• 測定・採点・記録: Claude (Opus 5)
• thinking OFF の記録: workflow/records/llm_eval_20260916/report/Qwen3.8_OSS比較260916.html
• 今回の記録一式: workflow/records/llm_eval_20260916/（回答は answers_thinking_on/、進捗は thinking_on_progress.md）

0. サマリ

ふゆきさんへ: gpt-oss は thinking ON にすると、11本の合計時間が短くなり、判定も良くなりました。NVFP4 は判定がほぼ変わらず、時間が大きく伸びました。8bit は MLX サーバーが生成の途中で落ち続け、測定できませんでした。

0-1. thinking ON の結果

モデル	正解	要検討	不正解	時間切れ・停止	採点不能	見つけるべき欠陥8件の検出	11本の所要時間
gpt-oss:120b	5	1	4	0	1	部分的に1（mox_law_v2 の改行で見逃す欠陥）	678秒（11分18秒）
Qwen3.8 NVFP4	4	1	4	時間切れ1	1	0（ほかに一覧外の正しい指摘1）	6,079秒（1時間41分19秒。時間切れの3600秒を含む）
Qwen3.8 8bit	1	0	0	サーバー停止5	0	測定できず	測定できず（残り5本は打ち切り）

0-2. thinking OFF との比較

モデル	判定（OFF → ON）	11本の所要時間（OFF → ON）	最大の出力トークン（OFF → ON）
gpt-oss:120b	正解4・不正解6・採点不能1 → 正解5・要検討1・不正解4・採点不能1	939秒（15分39秒） → 678秒（11分18秒）	16,737 → 12,549
Qwen3.8 NVFP4	正解4・要検討1・不正解5・採点不能1 → 正解4・要検討1・不正解4・時間切れ1・採点不能1	547秒（9分7秒） → 6,079秒（1時間41分19秒）	7,070 → 31,850
Qwen3.8 8bit	正解4・要検討2・不正解4・採点不能1 → 正解1・サーバー停止5・打ち切り5	1,609秒（26分49秒） → 測定できず	7,014 → 3,627（回答できた1本のみ）

NVFP4 は、時間切れの1本を除いた10本で比べると、OFF 395秒（6分35秒） → ON 2,479秒（41分19秒）で、約6.3倍です。

1. LLM の設定

ふゆきさんへ: 「コンテキストは各モデルの上限、出力枠は大きめ、予備実行で枠を決める工程は省く」という方針で設定しました。上限の値は、この環境の実物で確かめたものです。

1-1. thinking ON で使った設定

モデル	コンテキスト	確認元	出力枠	thinking の指定
gpt-oss:120b	131,072	ollama show の context length	116,326	think: true（強さは指定なし。テンプレート4〜9行により medium）
Qwen3.8 NVFP4	262,144	ollama show の context length	246,605	think: true
Qwen3.8 8bit	262,144（MLX は指定する起動引数が無い）	config.json 121行 max_position_embeddings	246,594	依頼ごとに chat_template_kwargs.enable_thinking: true

• 出力枠は「コンテキスト − そのモデルの OFF 記録での最大入力トークン数」で計算した（最大入力は gpt-oss 14,746、NVFP4 15,539、8bit 15,550。いずれも skm_phase5_compact_retry）。
• 生成設定は OFF と同じ temperature 0・top_p 1。各本1回、1回答の上限3600秒。
• 判定マーカー指示（本番入口の末尾文面）は OFF と同じ条件にした。元の7本は付けず、作り直した4本だけ付けた。
• 8bit の MLX サーバーは OFF と同じ起動引数（--max-tokens 1024、--chat-template-args {"enable_thinking":false}）のまま起動した。依頼ごとの enable_thinking: true で上書きされ、思考の文章が返ることを1本目で確認した。

1-2. 使ったメモリ

• 各モデルの1本目を終えた直後に memory_pressure で測った空きメモリ: NVFP4 75%、8bit 61〜62%、gpt-oss 23%。
• 1回ずつの測定で、測った時点はモデルごとに1本目の直後だけ。

2. テスト項目

ふゆきさんへ: thinking OFF と同じ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 と同じです。所要時間は回答1本の実時間で、各モデルの最初の1本（airscope_led_review2）はモデルの読み込み時間を含みます。

3-1. 判定の意味

• 正解: 欠陥を見つける本では、見つけるべき欠陥をすべて、該当行と誤った結果になる入力つきで挙げた。指摘なしが答えの本では、修正必須の誤った指摘を出さなかった。
• 不正解: 欠陥を1件も挙げられなかった。または、コードと矛盾する指摘や貼られていない部分を推測した修正必須の指摘を出した。
• 要検討: 正解とも不正解とも言い切れない（一部だけ指摘、軽い指摘のみなど）。
• 時間切れ: 3600秒以内に回答が返らなかった。サーバー停止: MLX サーバーが生成の途中で落ち、回答が返らなかった。
• 回答の主張は、依頼文のコードと突き合わせてから判定した。

3-2. 11本の判定と所要時間（thinking ON）

テスト	答え	gpt-oss	NVFP4	8bit
mox_law_v2	欠陥2件	要検討 / 26.3秒 / 1,725	不正解 / 394.0秒 / 24,660	サーバー停止（約8分50秒）
alexa_handoff_initial	欠陥1件	不正解 / 27.2秒 / 1,448	不正解 / 122.0秒 / 6,261	打ち切り
mox_law_initial_retry	欠陥3件	不正解 / 46.0秒 / 2,613	不正解 / 368.8秒 / 20,688	打ち切り
skm_phase5_compact_retry	欠陥1件	不正解 / 141.2秒 / 7,969	不正解 / 631.4秒 / 31,850	打ち切り
alexa_weather_initial_retry	欠陥1件	不正解 / 208.4秒 / 12,549	時間切れ / 3600秒	打ち切り
smartphone_axis_initial	不明	採点不能 / 52.3秒 / 3,659	採点不能 / 135.0秒 / 7,095	サーバー停止（約8分50秒）
mox_law_v3	指摘なし	正解 / 8.4秒 / 542	正解 / 26.1秒 / 1,633	サーバー停止
airscope_led_review2	OK	正解 / 50.5秒 / 440	正解 / 26.8秒 / 1,098	正解 / 178.3秒 / 3,627
every_golf_serigaya_recovery_retry	欠陥なし	正解 / 43.2秒 / 2,226	正解 / 563.6秒 / 17,674	打ち切り
airscope_led_initial	誤BLOCKERなし	正解 / 26.3秒 / 1,810	正解 / 59.1秒 / 3,138	サーバー停止（約8分50秒）
codex_control_same_turn_retry	追加指摘なし	正解 / 48.2秒 / 3,294	要検討 / 152.3秒 / 8,430	サーバー停止（約8分50秒）

表の値は「判定 / 所要時間 / 出力トークン数」です。出力トークン数は思考の分を含みます。8bit の経緯は第5章にあります。

3-3. thinking OFF から判定が変わった本

モデル	テスト	OFF	ON	変わった点
gpt-oss	mox_law_v2	不正解	要検討	見つけるべき2件のうち「改行で分けると見逃す」を入力例つきで挙げた。
gpt-oss	airscope_led_initial	不正解	正解	貼られていない定義を推測した BLOCKER を出さなくなった。
NVFP4	alexa_weather_initial_retry	不正解	時間切れ	3600秒以内に回答が返らなかった。

この表は、判定が変わった本の全量です。ほかの本は OFF と同じ判定です（8bit を除く）。

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

gpt-oss:120b

• mox_law_v2: 改行で分けた状態変更の見逃しを入力例つきで指摘。否定文の誤拒否は挙げていない。もう1件、「コロンの前に空白を入れると不明な項目として拒否される」を指摘した（挙動の説明は正しいが、欠陥と言えるかは判断が分かれる）。
• skm_phase5_compact_retry: 誤った BLOCKER 1件（Studio の読み込みで NUL を検査していない、と主張。依頼文に貼られた _read_knowledge は S_ISREG の検査で切れており、読む部分は見えていない。NUL を含むファイルで警告が出ることを確かめるテストは通っている）。誤った指摘1件（後から来た報告で Studio を含む記録が拒否される、と主張。依頼文497行は保存済み記録の report が今回の報告と同じことを求めており、別の報告と照合されない）。FIFO の欠陥は見逃した。マーカーは PASS。
• alexa_weather_initial_retry: OFF と同じ誤った BLOCKER（削除された変数 r を参照してコンパイル不可）。マーカーは PASS。
• alexa_handoff_initial: すべて NON-BLOCKING と答え、欠陥を見逃した。
• mox_law_initial_retry: NO_FINDING と答えた。
• airscope_led_initial: CONDITIONAL_OK・BLOCKER なし。推奨事項は出したが、修正必須の指摘は無かった。

Qwen3.8 NVFP4

• mox_law_v2: 見つけるべき2件は挙げなかったが、一覧に無い正しい指摘を1件出した（「DBの構造を確認する」という読み取りだけの計画が、operation_re の DB と する に一致して拒否される。依頼文130行の正規表現で確認）。
• skm_phase5_compact_retry: FIFO の欠陥を見逃した。依頼文360行の _mapping(studio_value, ...) を studio_entry と読み違え、「NameError になる」と軽い指摘にした。
• codex_control_same_turn_retry: 依頼文に貼られていない _text_content の戻り値を推測し、軽い修正を勧めた（要検討）。
• alexa_handoff_initial: 「すべての要件を満たす」と答えた。OFF と同じく、回答内に自分のモデル名を「gpt-oss:120b」と書いた。
• mox_law_initial_retry・every_golf_serigaya_recovery_retry: NO_FINDING と答えた。

Qwen3.8 8bit

• airscope_led_review2: VERDICT OK・BLOCKER なし（正解）。回答が返ったのはこの1本だけ。

3-5. 思考の中身の確認

答えが思考の中にだけ書かれていないかを確かめるため、思考の文章も書き出して確認しました。

• NVFP4 の mox_law_v2: 思考の中で「テスト\nコードの変更 は改行で一致しない。だが状態変更だ」と、改行で見逃す欠陥に気付いていた。回答では「設計上の限界」として欠陥に数えなかった。
• NVFP4 の skm_phase5_compact_retry: 思考にも FIFO・名前付きパイプへの言及は無かった。
• NVFP4 の mox_law_initial_retry: 思考にも、見つけるべき3件への言及は無かった。

この確認は NVFP4 の上記3本だけで、全量ではありません。gpt-oss の思考は、回答本文の採点に必要な範囲でしか読んでいません。思考の文章は answers_thinking_on/ の各ファイルの末尾にあります。

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

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

1位　gpt-oss:120b（thinking ON）

• 正解5で3モデル中最多。欠陥を部分的に1件、入力例つきで挙げた。
• 11本を11分18秒で終え、最も速い。OFF の15分39秒より短い。
• 弱点: 作り直した4本で誤った指摘が3件。BLOCKER を出しながらマーカーは PASS という食い違いが2本。読み込み後の空きメモリが23%と最も少ない。

2位　Qwen3.8 NVFP4（thinking ON）

• 修正必須の誤った指摘は出していない（軽い指摘の中に、読み違い1件と、貼られていない部分の推測1件がある）。一覧外の正しい指摘を1件出した。
• 弱点: 欠陥を1件も見つけていない。11本で1時間41分19秒かかり、1本は3600秒で時間切れ。出力は最大31,850トークン。

3位　Qwen3.8 8bit（thinking ON）

• MLX サーバーが生成の途中で落ち続け、11本中1本しか回答が得られなかった。今の MLX 環境では thinking ON で使えない。

thinking OFF の評価との関係

• thinking OFF では 8bit、NVFP4、gpt-oss の順だった。gpt-oss は ON にすると速さと判定の両方が良くなり、OFF の3モデルのどれよりも正解が多い。
• 見逃しの少なさを重く見るなら gpt-oss（ON）。誤った指摘の少なさを重く見るなら NVFP4 だが、ON では時間が大きく伸びるため、NVFP4 は OFF の方が扱いやすい。

5. 8bit の thinking ON で試したことと、結果が得られなかった経緯

ふゆきさんへ: 8bit は3回試し、回答が得られたのは1本目の airscope_led_review2 だけでした。生成を始めて約8分50秒で MLX サーバーが落ちることが続いたため、ふゆきさんの判断で打ち切りました。

5-1. 試行1（11:14〜11:17）: 思考の文章が取れなかった

• 1本目は179.7秒で回答し、出力は3,627トークン（OFF の同じ本は211トークン）。思考は行われていた。
• ハーネスが思考の欄を reasoning_content と読んでいたため空と判定し、残りを流さずに止まった。
• mlx_lm.server は、非ストリーミングの応答で思考を message.reasoning に入れて返す（server.py 1353・1358行）。runner.py を直した。

5-2. 試行2（11:18〜12:57）: 同じサーバーで2本目を流すと落ちた

• 1本目（airscope_led_review2）は174.1秒で回答し、思考の文章（13,608文字）も取れた。
• 2本目（mox_law_v3）で、サーバーの生成スレッドが RuntimeError: [metal::malloc] Resource limit (499000) exceeded. で落ちた。サーバーは依頼を受けたまま応答を返さず、12:21:43 に3600秒の時間切れになった。
• 3本目も応答待ちのままになったため、ふゆきさんにプロセスを止めていただいた。

5-3. 試行3（13:09〜14:09）: 1本ごとにサーバーを起動し直した

• 起動直後のサーバーでは1本目が2回とも回答していたため、1本ごとにサーバーを起動・終了する形に変えた。
• 1本目（airscope_led_review2）は178.3秒で回答した。
• 2本目（mox_law_v3）は、起動し直したサーバーでも同じエラーで落ちた（13:19〜13:29 の間）。ふゆきさんに runner を止めていただいた（13:33:26）。
• サーバーログに Traceback が出たら10秒以内に打ち切る処理を runner.py に足した。以後は止める操作なしで次の本へ進んだ。
• 自動で打ち切られた本と、開始から打ち切りまでの時間は次のとおり。

テスト	開始	打ち切り	経過
airscope_led_initial	13:33:32	13:42:22	約8分50秒
smartphone_axis_initial	13:42:27	13:51:18	約8分51秒
codex_control_same_turn_retry	13:51:23	14:00:13	約8分50秒
mox_law_v2	14:00:19	14:09:09	約8分50秒

この表は、自動打ち切りが働いた本の全量です。ログは10秒ごとに見ているため、実際に落ちた時刻は最大10秒早い可能性があります。

5-4. 打ち切り

• 5本中4本が同じエラーで落ちた。残りの本も、NVFP4 の ON で1万トークンを超えていた本が多く、8bit の生成速度では約8分50秒を超える見込みだったため、ふゆきさんの判断で打ち切った。
• 打ち切り用のファイル stop_q8_thinking_on.flag を置き、残り5本（alexa_handoff_initial、mox_law_initial_retry、every_golf_serigaya_recovery_retry、alexa_weather_initial_retry、skm_phase5_compact_retry）は流さずに終えた（14:09:14〜14:09:36）。ファイルは後でふゆきさんに削除していただいた。

5-5. 分かったことと、分かっていないこと

• 分かったこと: エラーの上限はメモリの量ではなく、Metal のバッファを同時にいくつ持てるかという個数の上限（MLX の allocator.h 72〜73行 num_resources_・resource_limit_）。空きメモリが61〜62%あっても落ちた。開始から落ちるまでの時間が約8分50秒で揃っていた。
• 分かっていないこと: 生成中に何がバッファを増やし続けているのか（mlx_lm 側の処理か、Qwen3.8 の作りによるものか）。落ちた時点で何トークン生成していたか。
• 同じ Qwen3.8 でも、Ollama で動く NVFP4 ではこのエラーは起きていない。

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

ふゆきさんへ: 今回のセッションでも、Claude の不手際によりふゆきさんのお手を煩わせ、時間を失いました。

• 8bit を262,144・thinking ON で動かせるかを一度も確かめずに、「レポート作成まで進められます」と断言した。
• 無人測定中の10分ごとの確認を怠り、11:21 に落ちた MLX サーバーに約1時間気付かなかった。2本目が3600秒の時間切れになり、止めて gpt-oss を始める 12:57 まで、測定が約1時間36分進まなかった。
• 思考の欄の名前をサーバーのコードで確かめずにハーネスを書き、8bit の試行1をやり直した（約4分）。
• OFF 記録の測定条件（本番の末尾文面の有無）を確かめずに出力枠の計算を書き、NVFP4 の開始が1回止まった（モデルは読み込む前で、時間の損失はほぼ無し）。
• 試行3で自動打ち切りを入れる前に同じエラーが出て、13:12:25〜13:33:26 の約21分を待った。プロセスを止める操作を、ふゆきさんに合わせて3回お願いした。
• 測っていない所要時間（採点に1〜2時間、その後30分）を口にした。実測は、NVFP4 の採点が1分52秒、gpt-oss の採点が58秒だった。
• モデルの置き場所を確かめずに /add-dir を案内し、ふゆきさんに2回実行していただいた。
• 打ち切り用のファイルを削除できず（権限設定で拒否）、ふゆきさんに削除していただいた。

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

ふゆきさんへ: thinking OFF の記録の第6章と同じです。thinking ON で新たに分かったことはありません。

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

ふゆきさんへ: 本番の出力枠 4,096 と待ち時間600秒のままでは、thinking ON の回答が返らない本があります。

• 本番の出力枠は 4,096（中央キュー qwen_shared.py 356行）。書き切れない回答はクライアントが弾く（tools/codex-studiollm-debug-client.py 115〜116行）。
• gpt-oss（ON）は11本中2本で 4,096 を超えた（skm_phase5_compact_retry 7,969、alexa_weather_initial_retry 12,549）。最長は208.4秒で、600秒には収まった。
• NVFP4（ON）は、回答が返った10本中7本で 4,096 を超えた（最大31,850）。skm_phase5_compact_retry（631.4秒）と alexa_weather_initial_retry（時間切れ）は600秒も超えた。
• 本番の入口が thinking をどう指定しているかは、今回は確認していない。

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

• 各テスト1回ずつの測定で、同じ条件で何度か測ったときのばらつきは見ていない。
• 採点基準と「見つけるべき欠陥」の一覧は Claude が決めて適用したもので、第三者の確認は受けていない。
• 元の7本は判定マーカー指示なし、作り直した4本は指示ありで測っている（OFF と同じ条件にそろえた）。
• 所要時間には、各モデルの最初の1本でモデルの読み込み時間が含まれる。
• gpt-oss の思考の強さは medium（指定なし）だけを測った。
• 思考の中身の確認は NVFP4 の3本だけで、全量ではない。
• 空きメモリは、各モデルの1本目の直後に1回だけ測った値。

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

• Qwen3.8 bf16: 後日対応。
• 系統B（コードを分割して渡すと欠陥を見逃すか）: 保留。thinking OFF・ON とも未実施。
• Qwen3.8 8bit の thinking ON: MLX サーバーが落ちる原因（Metal のバッファ個数の増加）を確かめない限り測れない。
• gpt-oss の思考の強さ low・high での測定。
• 同じ条件で繰り返し測ったときのばらつき。
• smartphone_axis_initial の正解「B-03」の中身を決め直す。
• 3モデル（8bit は OFF）とも正解した mox_law_v3・airscope_led_review2・every_golf_serigaya_recovery_retry は差がつかないため、より難しいケースへの置き換え候補。
• gpt-oss を thinking ON で本番に使う場合は、出力枠 4,096 の見直しが必要。

11. 再現手順と後片付け

ふゆきさんへ: 同じ条件で測り直すためのコマンドと、後片付けの結果です。

11-1. 再現手順

• ハーネスの置き場所: workflow/records/llm_eval_20260916/harness/（共通の手順は README.md）
• thinking ON の無人測定（1モデルずつ。11434 と 11436 が空いていることをスクリプトが確かめてから始める）
  • /usr/bin/python3 run_thinking_on_unattended.py --model nvfp4 --context 262144
  • /usr/bin/python3 run_thinking_on_unattended.py --model gptoss --context 131072
  • /usr/bin/python3 run_thinking_on_unattended.py --model q8 --context 262144（8bit は1本ごとにサーバーを起動し直す）
• 回答の書き出し: /usr/bin/python3 runner.py export --series A --thinking on（answers_thinking_on/ へ、思考の文章つきで出る。OFF の回答は上書きしない）
• 8bit の thinking ON を測る前に、workflow/records/llm_eval_20260916/stop_q8_thinking_on.flag が無いことを確かめる。あると8bit の thinking ON は何もせずに終わる。
• 進捗は thinking_on_progress.md、8bit のサーバーログは thinking_on_mlx_server.log に追記される。

11-2. 後片付けの結果（2026-09-17 14時台に確認）

対象	測定前	測定後
11434 Ollama	モデル読み込みなし	モデル読み込みなし（各モデルの終了時にアンロード）
11435 Alexa	PID 869（09-16 の記録）	PID 869（操作なし）
11436 MLX	待ち受けなし	待ち受けなし（測定で起動したサーバーはすべて終了）
中央キュー qwen-shared.py	PID 46674（9月15日起動）	PID 46674（操作なし）
codex_control_lab	未コミット変更あり（測定前の09-15から存在）	同じ（今回の編集なし）
mox_system	セッション開始時の変更状態	同じ。増えたのは評価フォルダの中身だけ
打ち切り用ファイル	無し	無し（ふゆきさんが削除）

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本の回答が弾かれます。

モデル	正解	要検討	不正解	時間切れ・停止	採点不能	見つけるべき欠陥8件の検出	作り直した4本の誤った指摘	判定マーカーの欠落（4本中）
Claude Haiku（参考）	5	1	4	0	1	部分的に1（mox_law_v2 の改行で見逃す欠陥）	0	3
gpt-oss:120b（thinking ON）	5	1	4	0	1	部分的に1（同じ欠陥）	3	0

モデル	11本の所要時間の合計	1本の最短〜最長	全本がそろうまでの実時間
Claude Haiku（参考）	931秒（15分31秒）	29.1〜169.2秒	約2分49秒（11本を並行で実行）
gpt-oss:120b（thinking ON）	678秒（11分18秒）	8.4〜208.4秒	11分19秒（1本ずつ順に実行）

Haiku の所要時間は、サブエージェントの起動から完了までで、依頼ファイルの読み込みを含みます。ローカルの LLM の「1回答の応答時間」とはそのまま比べられません。

1. LLM の設定

ふゆきさんへ: この Mac には Anthropic の API キーが設定されていなかったため、測定ハーネスから API を直接呼べませんでした。代わりに Claude Code のサブエージェントを Haiku で起動して回答させたため、下の表のとおり、揃えられない条件があります。

1-1. thinking OFF・thinking ON・Haiku の条件の違い

項目	thinking OFF	thinking ON	Claude Haiku（参考）
実行場所	この Mac（ローカル）	この Mac（ローカル）	Anthropic のクラウド
呼び出し方	runner.py から Ollama・MLX の API を直接	同左	Claude Code のサブエージェント（model: haiku）
依頼の渡し方	依頼ファイルの本文をそのまま送信	同左	依頼ファイルのパスを渡し、Read で読ませた
道具の使用	なし	なし	依頼ファイルの Read だけ（全本とも2回）
コンテキスト	32,768〜65,536（8bit は指定不可）	各モデルの上限	指定できない
出力枠	8,192〜20,000	コンテキスト − 最大入力	指定できない
thinking	off	on（gpt-oss は medium）	指定していない
temperature・top_p	0・1	0・1	指定できない
判定マーカー指示	作り直した4本だけ末尾に付けた	同左	作り直した4本だけ「末尾に付いているものとして従う」と指示した
所要時間の測り方	1回答の応答時間	同左	サブエージェントの起動から完了まで
トークン数	出力トークン数	出力トークン数（思考を含む）	サブエージェント全体の使用量（入力を含む）
実行の順序	1本ずつ	1本ずつ	11本を並行
回数	各1回	各1回	各1回

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本の判定と所要時間

テスト	答え	判定	所要時間	トークン（全体）	判定マーカー
mox_law_v2	欠陥2件	要検討	49.9秒	36,818	指示なしの本
alexa_handoff_initial	欠陥1件	不正解	83.1秒	44,385	指示なしの本
mox_law_initial_retry	欠陥3件	不正解	169.2秒	55,616	なし
skm_phase5_compact_retry	欠陥1件	不正解	110.1秒	60,380	なし
alexa_weather_initial_retry	欠陥1件	不正解	138.1秒	60,373	なし
smartphone_axis_initial	不明	採点不能	35.5秒	34,229	指示なしの本
mox_law_v3	指摘なし	正解	38.2秒	33,698	指示なしの本
airscope_led_review2	OK	正解	29.1秒	32,988	指示なしの本
every_golf_serigaya_recovery_retry	欠陥なし	正解	129.8秒	54,844	あり（PASS）
airscope_led_initial	誤BLOCKERなし	正解	37.6秒	34,308	指示なしの本
codex_control_same_turn_retry	追加指摘なし	正解	110.4秒	42,708	指示なしの本

3-3. 本ごとの判定の横並び（thinking OFF・thinking ON・Haiku）

テスト	答え	gpt-oss OFF	gpt-oss ON	NVFP4 OFF	NVFP4 ON	8bit OFF	8bit ON	Haiku
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_review2	OK	正解	正解	正解	正解	正解	正解	正解
every_golf_serigaya_recovery_retry	欠陥なし	正解	正解	正解	正解	正解	打ち切り	正解
airscope_led_initial	誤BLOCKERなし	不正解	正解	正解	正解	正解	停止	正解
codex_control_same_turn_retry	追加指摘なし	正解	正解	要検討	要検討	要検討	停止	正解

「停止」は 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 は条件が揃っていない参考値です。

モデル・条件	実行場所	正解	要検討	不正解	時間切れ・停止・打ち切り	採点不能	見つけるべき欠陥8件の検出	作り直した4本の誤った指摘	11本の所要時間
gpt-oss:120b（thinking OFF）	ローカル	4	0	6	0	1	0	4	939秒（15分39秒）
gpt-oss:120b（thinking ON）	ローカル	5	1	4	0	1	部分的に1	3	678秒（11分18秒）
Qwen3.8 NVFP4（thinking OFF）	ローカル	4	1	5	0	1	0	0	547秒（9分7秒）
Qwen3.8 NVFP4（thinking ON）	ローカル	4	1	4	時間切れ1	1	0（一覧外の正しい指摘1）	1（軽い読み違い）	6,079秒（1時間41分19秒。時間切れ3600秒を含む）
Qwen3.8 8bit（thinking OFF）	ローカル	4	2	4	0	1	部分的に1（一覧外の正しい指摘1）	2	1,609秒（26分49秒）
Qwen3.8 8bit（thinking ON）	ローカル	1	0	0	停止5・打ち切り5	0	測定できず	測定できず	測定できず
Claude Haiku（参考）	クラウド	5	1	4	0	1	部分的に1	0	931秒（15分31秒。並行実行で実時間約2分49秒）

• 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. 順位

順位	モデル・条件	正解率（40%）	コスト（30%）	速度（30%）	合計
1	Qwen3.8 NVFP4（thinking OFF）	45点	87.5点	100点	74.3点
2	gpt-oss:120b（thinking ON）	55点	87.5点	80.7点	72.5点
3	Claude Haiku（参考）	55点	100点	58.8点	69.6点
4	Qwen3.8 8bit（thinking OFF）	50点	91.3点	34.0点	57.6点
5	gpt-oss:120b（thinking OFF）	40点	75.0点	58.3点	56.0点
6	Qwen3.8 NVFP4（thinking ON）	45点	80.8点	9.0点	44.9点
7	Qwen3.8 8bit（thinking ON）	10点	61.8点	0点	22.5点

合計 = 正解率 × 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件あたりの実際のトークン数・時間は測っていない。

モデル・条件	誤った指摘（作り直した4本）	回答なし	見逃し（8件中）	手戻りの単位数	コストの点数
Claude Haiku（参考）	0	0	7	21	100点
Qwen3.8 8bit（thinking OFF）	2	0	7	23	91.3点
gpt-oss:120b（thinking ON）	3	0	7	24	87.5点
Qwen3.8 NVFP4（thinking OFF）	0	0	8	24	87.5点
Qwen3.8 NVFP4（thinking ON）	1	1	8	26	80.8点
gpt-oss:120b（thinking OFF）	4	0	8	28	75.0点
Qwen3.8 8bit（thinking ON）	測定できず（0として計算）	10	8	34	61.8点

この表は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件）、誤りが少ないのはその裏返しでもある。

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. 設定の一覧

モデル・条件	実行基盤	thinking の指定	コンテキスト	出力枠	1回答の待ち時間の上限	メモリ（実測）
gpt-oss:120b（thinking ON）	Ollama 11434	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.py 356行）。上の表のどの条件でも、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: 後日対応で、今回は測っていない。

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. 結果のサマリ

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

条件	易1	易2	中1	中2	中3	難1
NVFP4 思考なし	2回目で合格	不合格	不合格	3回目で合格	2回目で合格	不合格
NVFP4 思考あり	2回目で合格	不合格	未測定	未測定	未測定	未測定
gpt-oss 思考あり	2回目で合格	不合格	未測定	未測定	未測定	未測定
gpt-oss 思考なし	1回目で合格	不合格	未測定	未測定	未測定	未測定
8bit 思考なし	1回目で合格	1回目で合格	不合格	不合格（打ち切り）	未測定	未測定
Claude Haiku（参考）	1回目で合格	1回目で合格	不合格	保留（1回目NG）	保留（1回目NG）	3回目で合格

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

3. 時間と量の実測

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

条件	題材	トライ数	合計秒	トークン
NVFP4 思考なし	易1	2	152.4	11,438
NVFP4 思考なし	易2	3	498.1	33,355
NVFP4 思考なし	中1	3	2,358.0	109,021
NVFP4 思考なし	中2	3	291.6	20,415
NVFP4 思考なし	中3	2	137.9	9,214
NVFP4 思考なし	難1	3	1,048.9	61,062
NVFP4 思考あり	易1	2	189.1	13,906
NVFP4 思考あり	易2	3	870.8	52,491
gpt-oss 思考あり	易1	2	176.7	11,869
gpt-oss 思考あり	易2	3	539.1	33,348
gpt-oss 思考なし	易1	1	92.1	6,251
gpt-oss 思考なし	易2	3	517.6	32,256
8bit 思考なし	易1	1	278.1	5,723
8bit 思考なし	易2	1	556.2	11,124
8bit 思考なし	中1	3（3回目は打ち切り）	6,499.6	72,554
8bit 思考なし	中2	2	697.3	13,941
Claude Haiku	易1	1	95.1	47,510
Claude Haiku	易2	1	154.3	62,947
Claude Haiku	中1	1	585.9	140,865
Claude Haiku	難1	3	728.2	335,862

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

4. 落ちた原因

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

条件・題材	テスト	理由
NVFP4 思考なし・易2	動かず	hub.py の字下げが空白1つずれ、読み込めない
NVFP4 思考なし・中1	353/353	頼んでいない空白の変更が約60か所
NVFP4 思考なし・難1	64/64	行末コメントの前の空白2行が元に戻らない
NVFP4 思考あり・易2	110/110	続きの行の字下げを空白1つ減らす変更が約30行
gpt-oss 思考あり・易2	109/110	無関係な SQL の書き換えが1か所残り、表定義の改行も変更
gpt-oss 思考なし・易2	動かず	既存メソッド3つ（約150行）が回答から脱落
8bit 思考なし・中1	353/353	無関係な変数の書き換え（3回目は時間切れで打ち切り）
8bit 思考なし・中2	32/34→未送信	判定の消し過ぎ、次のトライは見出しなしの形式崩れ
Claude Haiku・中1	実行せず	出力上限32,000トークンで回答が2つに分かれ、片方しか取り出せない

テストが全部通ったのに不合格になったのは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. ローカルに任せられる範囲

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

区分	目安	実測の裏づけ
ローカルに任せる	渡すファイル合計 60KB 以下、返させる全文 1.2万トークン以下	易1 25KB・易2 54KB・中2 28KB・中3 36KB で合格例あり。1回 60〜560秒
上位モデルに回す	1ファイルが 100KB 超、または返させる全文が 3万トークン超	中1 129KB・難1 102KB は全条件で不合格。1回 約12〜38分

8. 運用の案

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

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

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

順位	条件	合格	トライ数	合計秒	総合
1	Claude Haiku（参考）	2/2	2	249.3	100.0
2	8bit 思考なし	2/2	2	834.3	79.0
3	gpt-oss 思考なし	1/2	4	609.7	47.3
4	NVFP4 思考なし	1/2	5	650.4	43.5
5	gpt-oss 思考あり	1/2	5	715.8	42.4
6	NVFP4 思考あり	1/2	5	1,059.9	39.1

この順位は易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

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