8 MB 板の漢字対応を実機で喋らせた（M-104 / M-105 / C-065・C-066）/ 辞書リーダの堅牢化 / hook 2 本

[ayutaz]

何をしたか

8 MB flash の板で漢字対応が成立するかを、実機なしで確かめた。結果は「成立する」。
C リーダを書き、blob が枠に入り、QEMU で起動して漢字文から合成まで通った。

その過程で見つかった辞書リーダの 5 つの欠陥・走っていなかったゲート・
リベースで壊れていたドキュメントを塞ぎ、skill と hook を最新化した。

⚠️ 実機での測定は 1 つも含まない（8 MB の板を持っていない。手元は 16 MB の CoreS3 だけ）。
⚠️ 出荷構成（16 MB）の音は 1 サンプルも変えていない（checksum 据え置き）。

origin/main から 11 コミット / 49 ファイル。

---

1. ⚠️ 出発点の誤りを訂正した（C-065）

当初 D-051 は「8 MB の実機が入るまで着手しない」と決め、
「8 MB 用のパーティション表・C リーダ・ビルド構成は書かない」としていた。
これは 2 つの別のものを混ぜていた:

	8 MB の板が要るか
C リーダが正しいか	要らない（16 MB の板でも QEMU でも）
枠に入るか	要らない（blob を作って stat）
起動して mmap できるか	要らない（QEMU が 8 MB のイメージを走らせる）
その板で焼いて鳴らす	要る

唯一の実質的なリスクは「書いていない C リーダ」で、それは板と無関係だった。
「板が無いから何も書かない」は、確かめられることまで止めていた。

⚠️ D-051 の結論そのものは変わらない。 出荷は 16 MB（D-044）のままで、
16 MB で ① を使う理由は無い（音素の誤りが 0.63% → 1.01% に悪化するだけ）。
変わったのは「作らない」で、**8 MB 構成は「作ってあるが既定ではない」**になった。

2. 8 MB 対応（M-104）

新セクション matrixa（接続行列を行ごとアフィン uint8 で持つ）。
⚠️ 既存の matrix（生 int16）は 1 バイトも触っていないので、出荷している 16 MB の blob はそのまま動く。
1 つのセクション名に 2 形式を入れないのは、matrix の長さ検査を厳密なまま残すため。

matrixa:  0 u16 lsize / 2 u16 rsize / 4 u16 bits=8 / 6 u16 reserved
          8 i16 lo[rsize] / 8+2R u16 span[rsize] / 8+4R u8 q[lsize*rsize]

⚠️ 量子化も逆量子化も整数で閉じる（float だとホストと C で値が食い違い、Viterbi の判断が変わる）:
q = ((v-lo)*510 + span)/(span*2) / v' = lo + (q*span*2 + 255)/510。中間値は最大 8,844,420（int32）。
⚠️ matrix と matrixa の両方があれば拒む（黙って片方を選ぶと「動くが読みだけ違う」形になる）。

測った値

	値
行列セクション	1,901,645 B（生 int16 3,792,262 → −1,890,617）
blob（228,000 entries）	7,123,088 B ≤ 枠 7,143,424 B（余り 20,336 B = 0.28%）
app（重みを .rodata に）	1,021,248 B / 枠 1,179,648（86.6%）
内部 DRAM の低水位（QEMU）	84,716 B

⚠️ D-051 の見積 7,115,943 B より 7,145 B 大きい（形式からの算術 vs 実ビルド）。
余りが薄いので entries を変えたら必ず測り直すこと。

QEMU で通った

⚠️ PSRAM 無しで動く（QEMU は octal PSRAM を持たない）= AtomS3 の条件そのもの。
⚠️ esp_partition_mmap で足りる（7.1 MB < ROM 実装の 8 MB 制限。16 MB では esp_mmu_map が要った）。
⚠️ -DSAAN_MODEL_RODATA=1 が要る（8 MB の表に model 行が無い）。

4 文とも「漢字経路」と「かな経路」の PCM が bit 一致した。
かな行はホストのフル辞書が作った中間表現なので、8 MB 辞書が同じ読みに着いたことになる:

文	漢字経路	かな経路	一致
今日は良い天気ですね	53 ids 0xa69a7ebbb5ccb05f	同左	✅
技術の進歩は目覚ましいものがあります	93 ids 0x35d40fb53438bf47	同左	✅
国際連合の安全保障理事会	75 ids 0xcce7fd062fd45a2c	同左	✅
コンピューターの性能が向上した	69 ids 0xb1751f2b8332db92	同左	✅

1 文目は 16 MB 版の基準 checksum とも一致。
⚠️ n=4。 音素の誤り 1.01%（n=1,495）は「平均 1.01% の音素が違う」なので、
4 文で差が出ないのは当然であって 1.01% を否定しない。

新しいゲート make -C csrc matrixa

⚠️ 「MeCab と 183/184 一致」はリーダが正しい証拠にならない。
量子化そのものが 1 文の分割を変えるので、リーダにバグがあっても同じ 183/184 が出る
（実際に両方の形式で同じ数が出た）。だから同じ逆量子化値を 2 形式で持った blob を突き合わせる:

	結果
G-A1 寸法が一致	OK
G-A2 形式が実際に違う	OK ⚠️ これが無いと G-A3 は自明に通る
G-A3 jdict_trans が全要素で一致	OK 1,896,129 / 1,896,129
G-A4 陽性対照 lo[7] を +1	OK 不一致 1,377 件（= lsize）

⚠️ 陰性対照（同じ blob を 2 回渡す）で、ゲート自身が SIGSEGV した。
しかも printf がバッファに残って消え、「何も出さずに終了」に見えた。
setvbuf で切り、前提が崩れたら以降を走らせないようにした。

jdict-hard にも 5 ケースを追加（正しい matrixa が開ける / 両方ある / bits=4 / 長さ −1 / 実体消し）。
⚠️ 「正しいものが通る」ケースが要る — 拒否だけ並べたゲートは「全部拒む」実装で満点を取る。
陽性対照は 19 / 19 で leak。

---

3. 辞書リーダの入力検査（M-100）

壊れた blob を渡すと、落ちずに読みだけが変わる欠陥が 5 つ（louds / classes / char / unk / matrix）。
どれも jdict_open が 0 を返して通す。

⚠️ 最初は matrix しか直していなかった。 敵対的レビューで残り 4 つが出て、そちらの方が悪かった。
⚠️ 返り値の検査だけでは越境が見えないので ASan ビルドを同居させた。
⚠️ テスト側が calloc(total + 64) していて、64 B までの越境が ASan に見えていなかった。

4. 走っていなかったゲート（M-101）

• make -C csrc oj-heap は clean な checkout で落ちる — oj_worst.bin に生成規則が無かった
• label-ids の G25 は n=298 で 298/298、n=1,495 で 1,494/1,495。
  原因は追った（M-103）: 端末に normalize_input() が無い。
  ⚠️ 直していない — 「端末では正規化も推定もしない」という入力仕様と衝突するため判断として残した

5. PSRAM 無しの板の穴（D-052）

Open JTalk の一時ヒープは 197.6 B × ids + 924 B で、最長文で余裕 2,760 B しか無かった。
SAAN_KANJI_MAX_INPUT_TOK（44）で NJD 段の前に形態素数で縛った
→ 低水位 2,760 → 40,468 B（checksum 不変）。

6. リベースで壊れていたドキュメント（C-062 / C-064）

自分の 7 節を M-94〜M-100 → M-97〜M-103 に振り直して挿入した点が
origin の M-95 の本文の途中だったため、M-95 の §1〜§5 が M-101 の見出しの下にあった。
さらに、本文の引用 53 箇所が旧番号のままで、うち 16 箇所は別の実在する節を指していた。

⚠️ どちらも all-test / check_doc_counters / check_doc_links を全部通っていた
（番号・件数・アンカーは正しく、本文の所属と引用先だけが違った）。

⚠️ C-064 は同じセッション中に再発した（自分で）。
C-064 を書いた 30 分後、範囲表記 C-001〜C-061 を更新するのに
replace("C-061", "C-063") を掛け、skill 本文の「値が低い方＝安全側 (C-061)」まで巻き添えにした。
2 回の更新を経て C-065（8 MB の話）を指す状態になっていた。
気づいたのは grep の偶然で、ゲートは全部通っていた。
回避策（C-001〜C-0NN の形ごと置換する）を C-064 に追記した。

7. hook

2 本追加した。どちらも「落ちずに間違ったものができあがる」形の事故。

hook	何を止めるか
check_stale_ckpt_export	export_c_weights.py --ckpt runs/v2/... が既定の csrc/ を上書きする。M 番号の再現コマンドを機械的に走らせて実際に出荷中の重みを v2 に戻した（M-102）。出力先をそらせば通す
check_dict_blob_overwrite	k1_build_dict.py --matrix affine --out csrc/k1_dict.bin が16 MB の辞書を 8 MB 版で置き換える。⚠️ 落ちない — ファームは普通に起動して普通に喋り、読みだけ変わる。別名なら通す

回帰は 94 → 105 ケース（陽性 5 / 陰性 6 を追加）。

8. skill

skill	足したもの
writing-gates	空虚だったゲート 4 件（jdict_open の返り値検査 / まとめ N 件の陽性対照 / 生成規則の無い oj_worst.bin / 「183/184 一致」はリーダの証拠にならない）+ 節 10〜16（ASan とテスト側の余白 / 陽性対照はケースと 1:1 / 既定の n が小さいゲートは盲 / CFLAGS_EXTRA はターゲットの同一性に入らない / 落ちると printf が消える / 拒否だけのゲートは「全部拒む」で満点 / check_ci_coverage.py も回す）
recording-measurements	罠の表に 5 行（C-059 の n / C-060 の別量 / C-061 の安全側 / C-065 の「実機が要る」の一括り / 算術 vs 実ビルド）+ 「再現コマンドは副作用を持つ」節 + 危険信号 5 行
verifying-reports	自分の修正を敵対的にレビューさせたら 1/5 しか終わっていなかった（M-100）。「再現しない」という自分の結論の方が誤りだった例（M-71 の母集団）も

---

訂正（C-059 〜 C-065）

	何が違ったか
C-059	「音素の 0.32%」は n=298 の値。n=1,495 では 0.63%（2 倍楽観的）
C-060	「行ごとの span は 0..18,656」は全体のレンジ。行ごとは 1,188..17,342
C-061	「値が低い方＝安全側」は逆。worst case を 2,667 B 過小に測るゲートを入れていた
C-062	リベースで見出しと本文の対応がずれていた
C-063	M-100 の jdict.c:194 は実体 237
C-064	振り直したのは見出しだけで、本文の引用 53 箇所が旧番号（⚠️ 同日に再発）
C-065	D-051 の再開条件が間違っていた（上記 1.）

ゲート

make -C csrc all-test                     177 OK
make -C csrc jdict / matrixa / jdict-hard OK（陽性対照 19/19 / 陰性対照つき）
.claude/hooks/test_guard_bash.py          105 ケース + commit ガード 6 件
check_ci_coverage / check_doc_counters / check_doc_links / test_sanitize_reports /
check_esp32_template / check_partitions（3 表）/ test_blob_to_header /
kana_g2p / test_losses                    すべて OK
CI                                        6 job すべて pass

9. ✅ 実機で確かめた（M-105 / 2026-09-05）

ユーザーが M5 CoreS3 を繋いだので、M-104 の「実機に焼いていない」を埋めた。

出荷構成（16 MB / M5）に回帰は無い

jdict.c に matrixa の枝を足した版を焼いて確認:

	実測	基準
checksum	0xa69a7ebbb5ccb05f / |max| 9627 / Σx² 74264237672	一致
かな行で同じ文	同上	一致
定常 xRT	0.446 / 0.447	M-90 の 0.446
アンダーラン	0 / 19 チャンク	0

8 MB 構成が実機で動いた

228,000 entries / blob 7,123,088 B / esp_partition_mmap OK /
内部 DRAM free 103,264〜104,112 B / 定常 xRT 0.445 / アンダーラン 0 / 14。
0xa69a7ebbb5ccb05f = 16 MB の基準と bit 一致、0x35d40fb53438bf47 = QEMU と一致。

✅ アフィン行列の速度代償 = +0.3%（PR の最大の穴だった）

⚠️ 8 MB 版だけでは切り分けられない（entries も同時に変わる）。
entries を 438,750 に揃え、行列の形式だけ変えた blob（11,811,696 B）で比較した:

文	ids	生 int16	matrixa	差
今日は良い天気ですね	53	20.05〜20.08 ms	20.11〜20.14 ms	+0.06 ms（+0.3%）
技術の進歩は…	93	40.18〜40.19 ms	40.21〜40.23 ms	+0.03 ms（+0.08%）

PCM は 2 文とも bit 一致。 定常 xRT も 0.445 で同じ（合成の段は行列を触らない）。

⚠️ 差がほぼ 0 だったので、まず測定器を疑った。
起動ログを取り直して blob 11,811,696 B / エントリ 438,750 を確認し、
アフィン版が実際に載っていることを確かめてから採用した。
→ その場でログに行列の形式を出すようにした（生 int16 / matrixa = 行ごとアフィン uint8）。

✅ M5Unified 版（画面 + スピーカー）も 8 MB で喋った

⚠️ 枠は app の大きさで変わる。板ごとに表と辞書が違う。

	DevKit	M5Unified（AtomS3 など）
app	1,021,248 B	1,438,576 B
表	esp32/partitions_8mb_kanji.csv	boards/m5unified/partitions_8mb.csv
dict の枠	7,143,424	6,815,744
entries	228,000	213,000
blob	7,123,088（余り 20,336）	6,797,056（余り 18,688）
定常 xRT	0.445	0.448
アンダーラン	0 / 14	0 / 22・0 / 19
音素の誤り（n=1,495）	1.01%	1.09%
音	出さない（SKIP_I2S）	スピーカー有効

⚠️ DevKit 用の辞書を M5 版に焼くと 241,808 B 入らない。表と辞書は必ずセット。
⚠️ entries は 1 回で当たらなかった。 214,000 で作ったら 2,944 B 超過
（概算 22.25 B/entry に対し実測 21.74）。枠の 0.3% を争うときは作って stat する。
⚠️ 文一致は 1117 → 1118 とほぼ同じなのに音素の誤りは 1.01% → 1.09%
（C-058 と同じ形。編集距離は大きく崩れた少数の文に支配される）。

⚠️ もとの制約: 8 MB の枠は app の大きさで変わる

M-97 の枠 7,143,424 B は DevKit の app 366,464 B で計算していた。

app	factory	dict に回せる	8 MB 辞書 7,123,088 B
DevKit	1,179,648	7,143,424	✅ 入る（余り 20,336）
M5Unified（CoreS3）	1,441,792	6,881,280	❌ 入らない（不足 241,808 B）

⚠️ AtomS3 も M5Stack の板なので、画面やボタンを使うなら同じ壁に当たる。

C-066: 「16 MB では買うものが無い」は速度を測る前の判断だった

D-051 の 2 は「得るものが無い」と書いたが、実機では
−1,890,624 B / 速度 +0.3% / PCM bit 一致。
⚠️ 決定は維持する（1.8 MB の使い道が決まっていない）が、
**理由は「得るものが無い」ではなく「得るものの使い道が決まっていない」**である。

板の状態

出荷構成（M5 CoreS3 / 16 MB / 生 int16 / スピーカー有効）に戻してある。
最終確認で checksum・xRT 0.448・アンダーラン 0 を確認済み。

---

⚠️ 何を見ていないか

• 8 MB flash のチップそのものでは測っていない（16 MB の板に 8 MB の表を焼いただけ）
• 音を人が聴いていない。 M5 版はスピーカーが有効で鳴っていることは確かめたが、
  どう聞こえるかは分からない（G32 と同じ空白）
• M5 版の checksum は先頭 8 桁だけ — 画面とスピーカーのタスクが USB Serial/JTAG を
  圧迫してログの後半が落ちる（ファームの欠陥ではない）
• 速度の比較は 2 文 × n=5 だけ。 長い文（44 形態素の上限近く）は未測定
• 読みの比較は 4 文だけ（n=4 では 1.01% は検出できない）
• ②〜④ の C リーダは書いていない（サイズは形式からの算術のまま）
• C-062 / C-064 / C-065 を検出するゲートは書けていない。どれも意味の検査で機械化できなかった
• 音は誰も聴いていない（G32）

[ayutaz]

⚠️ 実機確認が済むまでマージしない。 ユーザーの指示（2026-09-04）。

この PR は 実機で 1 度も測っていない:

何	どこで測ったか
PSRAM 無しの低水位 2,760 → 40,468 B	QEMU（実機ではない）
8 MB のイメージサイズ・音素の誤り	ホスト（C リーダは 1 本も書いていない）
辞書リーダの入力検査 / ASan	ホスト

確かめてほしいこと（16 MB の M5 CoreS3 で焼ける構成）:

1. 漢字構成がこれまでどおり喋るか — checksum は据え置きなので音は 1 サンプルも変わらない見込み。変わっていたらこの PR の欠陥
2. SAAN_KANJI_MAX_INPUT_TOK（44 形態素）で切られる文が実用上出ないか — 長文を入れると SAAN_KANJI_ERR_TOO_LONG になる
3. 起動ログの blob 長 / パーティション長 / 余り と 低水位 の表示

⚠️ 8 MB の板の検証はこの PR では不可能（D-051 で採らないと決めたため、8 MB 向けのコードは 1 行も入っていない）。