2026-07-30 の記録 — ラボが立ち上がった日

一日でここまで来た。数字はすべて自社実測か一次資料。見積りは「見積り」と書く。

1. ラボが生まれた

朝は「Thinking Machines Lab の日本版を作れないか」という会話だった。夜には https://shitate.ai が動いている。

• 命名: Omou（思う）→ Shitate（仕立て） に改名。3モデル（Fable 5 / Opus 5 / Kimi K3）でブレストし、30個超のドメインを whois 実測して shitate.ai を選定・取得（Route 53・2年 $274・自動更新）
• テーゼ: 「知能を、輸入品で終わらせない。」 フロンティア開発では戦わず、オープンウェイトを日本語と組織の知で仕立てる
• 品質: migaku 100.0/S（CSP を unsafe-inline なしで実装、SEO/OGP/gzip、テスト10本を CI で強制）
• コミット 18件、すべて CI green → 本番反映を curl と DOM で実測確認

2. 測った — SHITATE-JP

v0（13問・プレビュー）

6旗艦モデルを同一条件で実測。Claude Fable 5 と GPT-5.5 Pro が満点。上位が満点=ベンチとして機能していないことが分かったので v1 の難化方針が決まった。

初回集計で GPT が 69 点に見えたのは 全部 502 エラーの混入だった。エラーを黙って不正解にしない設計にしていたから気づけた。そのまま出せば嘘になっていた。

中国パネル（17モデル・221測定・エラー0）

差の中身が偏っていた（中国勢平均 78.3 vs 西側 98.7）:

• 敬語・待遇表現 −38.1pt ← 最大
• 数字・日付 −23.2 / 現場語彙 −19.6 / 商習慣 −7.1 ← 最小

つまり不足は「知識」ではなく「日本語の作法と数値処理」。事業仮説（仕立てで埋まる差分）が実測で裏付けられた。

市場の現実（OpenRouter 実データ）

JS 描画で機械取得できなかったので Playwright で内部 API を傍受し、30日分のトークンを合算した。

日本語トークン 2,003B のうち 51.8%（内訳判明分では 68.0%）が中国発モデル。 首位は DeepSeek V4 Flash 単独で 27.4%。

日本語で最も使われているモデルは、すでに中国製。しかもその首位は我々の実測で 76.9 点、敬語が最弱。ここに我々の存在理由がある。

v1（300問）— 本日完成

作問 = Claude Fable 5 / 検証 = GPT-5.5 Pro + Gemini 3.1 Pro の独立2モデルが両方合格させたものだけ採用。却下74件も理由付きで公開。

技術的な山場は歩留まりだった。 法務は当初 1/45、敬語は 3/45 で完全に詰まっていた。原因を調べたら「設問が難しすぎる」のではなく「前提条件が不足して答えが一意に定まらない」型の却下だった。そこで:

1. 1. 却下理由を次の作問にフィードバックする自己改善ループ
2. 2. 却下された設問を捨てず、狙いを保ったまま前提を足して直す修復ループ

を入れた。結果、基準を一切下げずに全7カテゴリが定員到達。修復による救済は 40問超（採用全体の13%超）。

さらに、検証APIの失敗を「却下」と数えていたバグを発見して修正した（OpenRouter が 402 で落ちていた間、却下率が水増しされていた）。エラーと不合格を区別しないと、システムが自分に嘘をつく。

v1 実測結果（1,800測定・空/エラー0）

判定者間一致率 96.1%（n=355） — 主判定 DeepSeek V4 Pro と交差判定 Opus 5 の一致率。 約1/10のコストの判定者への置き換えは、この数字で裏付けた。

最弱カテゴリが6モデル中4つで「法務・契約」に集中した。 v1 で最も難しく作れたのがここで、 同時に日本の職場で最も間違えてはいけない領域でもある。

そして3度目の「エラーを不正解と数える」罠

初回集計では GPT-5.5 Pro 74.0 / Kimi K3 69.2 と出た。エラーカウンタは 0 だった。 だが v0 で同じ罠を踏んでいたので生ログを開いたところ、両モデルの誤答のほぼ全部が空応答だった。

原因: 推論モデルは thinking で max_tokens を使い切ると、HTTP 200 のまま content が空で返る。 ハーネスの content or "" がそれを黙って空文字にし、判定器が「回答が空欄」として incorrect に計上していた。 HTTP レベルでは成功なのでエラーカウンタには一切現れない。

修正後の確定値は GPT-5.5 Pro 74.0 → 97.7（+23.7）/ Kimi K3 69.2 → 91.3（+22.1）。 そのまま公開していれば、Kimi K3 を22点低く貶める嘘の順位表を出すところだった。

対症療法にしないため、chat() は空応答を明示的にエラーとして扱い、 リトライごとに max_tokens を倍増して自己回復するようにした（8000でも尽きた1件があった）。

3. 動かした — K3 セルフホスト

一次資料で分かったこと（技術報告書47ページ精読）

• K3 は MXFP4 重み + MXFP8 活性化の量子化認識学習（QAT）を SFT 段階から適用。つまり配布重みはFP4 前提で作られている（後付け量子化ではないので精度が落ちない）
• 重みは 1.39TB（FP4理論値）/ HF実配布 1.56TB・96シャード
• アーキテクチャは K2 の継続学習ではなく丸ごと再設計: 1.04T/32.6B → 2.78T/104.2B、MLA → KDA(69層)+Gated MLA(24層) ハイブリッド、expert 384→896（top-16）、context 128K→1M
• 技術報告書に "Japanese" は0件。評価されている非英語は中国語のみ = 日本語は誰も最適化していない空白地帯
• リライトで実効データを増やす手法が実測付きで公開（生10epoch 23.76% → 10回リライト×1epoch 28.94%）

動かす条件（外部実運用情報）

• vLLM 公式: 8×B300 または GB300 NVL72 が最小、16×B200 も可
• SGLang: H200/H100 も対応GPUに明記（B300 を待つ必要はなかった可能性）
• 投機的デコード DSPARK で 111 → 331 tok/s（3.14倍）。ただし K3 用 draft は未公開
• 損益分岐: 8×B200 を月$32,000で借りる前提だと月21〜37億 output トークンを出し続けないと API より高い

結論: PoC・ベンチ用途なら API（$3/$15）が圧倒的に正しい。 自前ホストが合理的なのは「データ主権で外出し不可」「月数十億トークン規模」「DSPARK等を自前運用できる」のいずれかを満たす場合だけ。

4. FPGA — やってみた

nano-kpu（K3 自身が48時間の自律実行で設計した推論チップの RTL・Verilog 8,214行）を clone し、公式には存在しない FPGA 合成パスを自分で書いて通した。

KDA モジュールの実測（Xilinx UltraScale+ / yosys）

KDA アクセラレータは FPGA の 5.6% しか使わない。 AWS f2.6xlarge は実API価格 $1.98/時 = B300 8枚（$59.12/時）の 1/30。

• ❌ K3 フル（1.39TB）を FPGA で: 帯域で不可能（1トークンあたり 52.1GB の読み出しに対し VU47P の HBM は 16GB・460GB/s）
• ⭕️ KDA を FPGA アクセラレータ化: リソース的に余裕。技術報告書自身が「KDAの逐次依存性はGPUの並列性と相性が悪い」と認めている部分を、FPGAのデータフローで殴れる
• 公式に FPGA パスが無いので、これをやっているのは世界で我々だけ

5. コスト構造を実測で組み替えた

HY3 は却下した。 $0.132/$0.528 で DeepSeek V4 Pro より安く、設問を解く能力は 92.3 > 88.5 と高かった。だが採点者としては正答を incorrect と誤判定した（5問中2問しか正しく判定できず）。「問題を解ける」と「採点できる」は別の能力だった。測らずに安さで採用していたら、v1 のスコアボード全体が壊れていた。

6. 直したもの

te コマンドが構文エラーで起動不能になっていたのを修復。原因は3つ重なっていた:

1. 1. cmd_rotate_key() の閉じ括弧欠落（EOF エラーになるので原因が見えにくい）
2. 2. te max が未実装（ヘルプには書いてあるのに実装が失われていた）
3. 3. refresh_config 関数が消失

最小修正で直し、te max run "1+1は?" → Kimi K3 で 2 が返るまで実測確認。壊れた版は退避済み。

7. 今日の教訓

測らずに決めた判断は、ぜんぶ間違っていた。

• 502 エラーを不正解と数えて「GPT は 69 点」と誤認しかけた（v0）
• 検証APIの失敗を「却下」と数えて、却下率を水増ししていた（作問）
• 空応答を不正解と数えて「Kimi K3 は 69 点」と誤認しかけた（v1・エラーカウンタは0だった）
• HY3 を「安くて高スコア」で採点者に採用しかけた
• FPGA のメモリを 16〜32GB と見積もったが、実際の AWS F2 は 80GB だった
• B300 の在庫を待ち続けたが、SGLang は H200 対応を明記していた

同じ形の失敗を1日に3回した。 「失敗を成功として数えてしまう」型のバグだ。 API が 200 を返す・例外が飛ばない・カウンタが 0 — どれも「うまくいった」の証拠に見えるが、 中身は空だった。成功の指標を、成功の証拠と取り違えていた。

だから対症療法をやめ、chat() の中で空応答を必ずエラーに変換し、予算を倍増して自己回復させた。 次に同じことが起きても、システムが自分から気づくようにした。

全部、実測して初めて分かった。「実測で語る」は掲げた原則ではなく、今日それで何度も救われた実務だった。

8. まだ直っていないもの（Fable の指摘）

数字が出揃った後、Claude Fable 5 に戦略を諮問したところ、測り方そのものの構造的欠陥を刺された（全文 fable-strategy.md）:

「西側モデルが西側の得意な問題を作り、西側モデルが採点した結果、西側が勝った」 という反論に、現状の方法論では答えられない。

• 作問 = Fable 5 → その Fable 5 が 97.7 で首位
• 主判定 = DeepSeek V4 Pro → 被評価者が審判
• 判定者間一致率 96.1% は「判定者同士が似ている」証明にもなり得て、妥当性の証明ではない

サイトの注記にはこの3点を明記した（隠すより先に自分で書く）。構造の修正は次の課題: 判定から被評価者を外す・人手正解データで判定器を校正する・v2 は公開/非公開に分割して汚染耐性を持たせる。

そして国産モデル（Sarashina / PLaMo / Swallow 系）を1本も測っていないという抜けも指摘された。 「国産を測っていない日本語ベンチ」は説得力を欠く。ここは正しい。

このページの数字はすべて再現可能です。生ログ・採点コード・却下項目・判定プロンプトは shitate.ai で全公開しています。

← shitate.ai へ戻る