System One モデルが AI ソフトウェアに革命を起こす：Laya と Jev

9 月 15 日、AI とテックの世界に地殻変動が起きましたが、一般の人々にはほとんど気づかれませんでした。いつものように、ほかの誰もが素通りしたこの進歩の最前線にいたのはソフトウェアエンジニアたちです。この日、TypeSafe AI が初の商用 System One モデル「Jev」をリリースしたのです。

その 3 週間後、私は今後リリース予定の自社製品の 1 つのために、独自の System One モデルを訓練し終えていました。この記事は、その経験の振り返りです。

いま AI の動向を追っている人なら、誰でもこの感覚を知っているはずです。誰かが新しく出た AI 製品のリンクを送ってきて、あなたはあきれ顔をする。「System One モデル？」と聞き返す。知ったことか。こっちには Claude Opus があるし、やるべき仕事は山ほどある。また Manus や Rabbit r1 みたいなものに付き合っている暇はない。

初めて Jev のことを聞いたとき、私の頭をよぎったのもまさにそれでした。ただ、意見を求めてくる人がいたので、調べてみることにしました。最初に言っておくと、TypeSafe AI のウェブサイトはこの概念の説明がとても下手です。彼らのリリース告知のブログ記事を読んで、OpenAI や Anthropic のフロンティア AI モデルと競合するものだと思ってしまっても無理はありません（そう示すグラフまで載っているのだから、なおさらです）。「Reinforcement Learning for Calibrated Decisions」（RLCD）のような言葉が飛び交いますが、一般の消費者にはほとんど意味がありません。

Jev が実際に何をするのかを説明してくれたのは、LangChain によるはるかに優れたこの記事でした。詳しく知りたいなら、ぜひその記事を読んでください。読む価値は十分にあります。以下は、その記事に載っていたインフォグラフィックです。これを見て衝撃を受けました。TypeSafe が出したどの資料よりも、用途をうまく説明しています。

その例を見た瞬間、可能性の世界が一気に開け、抱えていた問題への解決策が次々と頭に浮かんできました。これなら、開発中の 2 つのプロジェクト、Infinilang と kcalc.ai（後者のウェブサイトはこの記事の時点では未完成）の問題を解決できると気づいたのです。

どちらのプロジェクトも、機能の中核を LLM に頼っています。私は話題づくりのために何にでも AI を押し込むような人間ではありませんし、そんな会社を経営したいとも思っていません。この 2 つのアイデアは、ここ 4 年で AI ツールが発展していくなかで、それぞれ独自に構想したものです。人々が長年頭を悩ませてきた問題に対して、真に革新的な解決策を提供します。

背景を知ってもらうために 2 つのプロジェクトを簡単に紹介しますが、この記事の中心は Infinilang なので、時間がない方は kcalc.ai の部分を飛ばしてください。

減量や増量に挑戦したことはありますか？ 私はあります。ジムに通って 3 年経ってようやく、筋トレは体づくりの 3 分の 1 にすぎないと気づきました。残りの 2 つは睡眠とカロリー摂取です。あいにく私は体重を増やすのが苦手で、体重の維持に必要な量以上を食べるのは大変すぎました。

アプリストアでよく見かけるカロリー計算アプリを試してみました。よくあるタイプです。1 日の食事を記録して、目標値の達成を目指す。コンセプトは素晴らしいのですが、作りはほぼ例外なくひどいものです。実際に食べている時間より、食事を記録して、マクロ栄養素のバランスやカロリーを修正している時間のほうが長くなります。たいていカメラ機能もありますが、うまく動くのは 20% 程度で、マクロ栄養素や量、カロリーを正しく出すことは決してありません。手料理や定番から外れた料理にも、ほとんど役に立ちません。

kcalc.ai が違うのは、記録の手間を大幅に減らすことを目指している点です。写真を撮るか LiDAR スキャンを行うと、15 段階からなる複雑なエビデンスパイプラインがその情報を処理します。LLM、ベクトルデータベース、食品とレシピの膨大なデータベース、ビジョンモデル、LiDAR スキャンからの 3D 再構成、多段階の推論エージェントなど、さまざまな技術を組み合わせています。

実際のところ、このアプリの AI 部分は途方もない大仕事でした。これに挑んだ人がほとんどいないのも不思議ではありません。膨大なソフトウェアエンジニアリングの経験と高度なシステム思考が必要で、それを持つ人はごくわずかだからです。AI コーディングエージェントの助けがなければ、あるいは 1000 万米ドルとエンジニア 5 人の 1 年分の時間がなければ、とても実現できなかったでしょう。

kcalc.ai が商業的に成り立つには、解決すべき深刻な問題がいくつもありました。大きなものは 2 つ、精度の評価と速度です。

ある場面を考えてみましょう。

ユーザーが「マヨネーズ添えベルギーフライ」の写真をアップロードする。

エビデンスパイプラインが画像を処理し、各ステージと多段階の LLM 推論の組み合わせによって、これは確かにベルギーフライで、おそらくマヨネーズ付きだという結論に至ります。kcalc.ai の面白いところは、あらかじめ用意された記録をそのままユーザーに返すとは限らない点です。文脈と、体積計算を伴う実際のサイズ計測をもとに、記録を動的に生成します。ここまでは申し分ありません。ちゃんと動きます。ただ、パイプラインを通り抜けるのに 2 分ほどかかります。

このアプリには「World Atlas」という機能があり、各国の料理、つまり「定番料理」を集めて世界地図を埋めていくことができます。そのため、料理を特定した最後に、照合すべき料理のリストがあります。これをどう実現するか？ 従来なら、正規表現（Regex）や類似度アルゴリズムのようなものでリストを検索し、一致しそうな候補を探したでしょう。私も最初にそれを試しましたが、似た名前の料理を取り違えてアトラスの項目を認定してしまうミスが繰り返し起きました。そこで次に思いつくのが、一致しそうな候補を取り出して、LLM に最も適切なものを選ばせる方法です。問題は、それでは計算資源を食いすぎることでした。おまけ程度の機能のために、カロリー推定機能を待たせるのは正当化できませんでした。

解決策は、System One モデルとベクトルデータベースの組み合わせです。

System One モデルなら、正確な選択がミリ秒単位で得られ、本格的な LLM と比べてリソースのコストも驚くほど安く済みます。似通った選択肢がたくさんありうる場面では、まさに救世主です。

System One モデルのインターフェースの本当の魅力は、驚くほど簡単に組み込めることです。コードベースの中に差し込める場所は何百と見つかるでしょうし、安くて速いので、ほとんど迷う必要もありません。これは、kcalc.ai がこの新技術の恩恵を受けると私が考える多くの場面の、ほんの一例にすぎません。

時間がとても限られ、（正直に言えば）語学の才能もない長年の日本語学習者として、私はどうにか通用する程度の日本語を身につけました。日本を旅して回ったり、バーで面白い会話を始めたりできるくらいにはなりましたが、例の「日本語上手ですね」を言われずに済むほどではありません。

日本語学習で特に厄介なのが「漢字」です。日本語の表記体系を構成する 3 種類の文字のうち、3 つ目にあたり、最も数の多い文字です。3 種類の文字の例を挙げます。

• ひらがな：ありがとうございます（ローマ字表記 arigatou gozaimasu、英語では「Thank you very much」）
• カタカナ：コールドブリューアイスコーヒー（ローマ字表記 korudo buru aisu kohi、英語では「Cold Brew Iced Coffee」）
• 漢字：人工知能（ローマ字表記 jinkou chinou、英語では「Artificial Intelligence」）

漢字は中国の文字に由来し、中国語と意味が共通するものもありますが、発音はたいていまったく違います。ややこしいのは、実用的な読み書きに必要な常用漢字が 2136 字あり、ネイティブ並みの流暢さに近づくには約 4000 字が必要になることです。さらに悪いことに、漢字には複数の読みがあることが多く、使われる場所によって発音が変わります。覚えるのは、まさに悪夢です。

OpenAI の GPT-3 が登場したとき、私はいち早く使い始めた一人で、この技術のほぼ無限の可能性を早くから感じていました。私にとって一番大きかったのは、一人ひとりに合わせた語学学習、つまりこれまでにないほど効果的に言語を学ぶ方法です。

当時、私は LLM の斬新な応用を 3 つ構想し、何年もそのアイデアを温め続けました。その間に、この技術のプロトタイプを 2 世代にわたって開発し、実際に機能することを証明しました。

このうっとりするほど学術的な見出しは、私が Infinilang のアイデアをもとに、修士号のために取り組んでいた論文の題名です。当初はこれらのツールをオープンソースの研究として公開するつもりでしたが、フルタイムの仕事とリソースの制約のせいで、それは難しすぎることが分かりました。そこで、まずは Infinilang をクローズドソースのモバイルアプリとして市場に出すつもりです。その後、自分の AI を持ち込める（BYO AI）オープンソースのデスクトップアプリとして公開する予定です。

では、Infinilang は何をもたらすのでしょうか？ 日本語学習者にとって、漢字の暗記は、効果的に読めるようになるための一側面にすぎません。現在、暗記は間隔反復システム（SRS）を使った、時間がかかって退屈なプロセスです。有名なのは Anki と WaniKani で、私の個人的なお気に入りは後者です。SRS では、フラッシュカードを繰り返し見せながら、次に見せるまでの間隔を少しずつ延ばしていきます。覚えた文字を、毎回ちょうど忘れる直前に見せるように設計されているのです。フラッシュカードを見る回数が増えるほど情報を長く覚えていられ、しかも見る頻度がだんだん減っていくほど定着の効果は高まります。SRS は漢字を暗記する最良の方法であることが実証されていますが、最大の弱点は、漢字を含む文を効果的に読む方法を教えてくれないことです。

NHK Easy の記事か、子ども向けの本を読めばいい。

昔からの定番の知恵は、やさしい読み物を見つけて、ふりがな 東(とう)京(きょう)（媒体によっては漢字の上に添えられている、読み方を示す小さなひらがな）を頼りに、知らない漢字をどうにか乗り越えていくというものでした。問題は明らかです。知らない漢字が 1 つでもあると、そこで完全につまずいてしまい、文が読めなくなることもよくあります。

そこで、こう考えました。SRS アプリには、どの漢字を覚えたか、それぞれどのくらい身についているかを記録する優れた仕組みがあります。では、覚えた漢字だけで書かれた読み物が手に入るとしたらどうでしょう？ それこそ LLM にできることであり、Infinilang の出番です。

Infinilang（フェーズ 1）の目標は、ユーザーの実力にぴったり合わせた読み物を作ることです。SRS アプリから直接取り込んだ、あなたが覚えた漢字を LLM に渡し、その限られた文字セットの範囲内で文を生成します。とはいえ、文字セットを LLM に渡せば素晴らしい読み物ができあがる、というほど単純ではありません。AI を手なずけてこの作業をうまくこなさせるのは、想像以上に大変です。それでも、ちゃんと機能します。

質の高い読み物を作るうえでの課題は、いくつかの「ファミリー」に分けられます。要するに、LLM が間違えていないかを確かめるために問うべき質問であり、間違えていた場合には、まったく新しい応答を生成し直さずに修正できるかどうかを問うものです。

• 文はどのくらい自然か？
• 文が不自然に削られた、あるいは壊れたように読めるか？
• 文章に一貫性はあるか？
• 文章は話題に沿っているか？
• 文章は未成年にふさわしいか？
• 実在の人物、ブランド、場所が含まれているか？
• N+1 で挿入した語を文脈から推測できるか？
• 文章は今後再利用する価値があるか？
• 文は文法的に正しいか？

これで全部ではありませんが、生成したコンテンツについて問うべき主な質問はこれらです。

早い段階ではっきりしたのは、サードパーティの LLM API を使えば、プロジェクトは最初から沈むということでした。API クレジットはとにかく高すぎて、サブスクリプションの収益の大半を食いつぶしてしまいます。下手をすれば、赤字になってしまいます。

解決策は 1 つしかありませんでした。自前の AI インフラを構築することです。限られた資本でスタートアップを立ち上げている身には、簡単なことではありません。幸い、小型の LLM は数か月ごとにどんどん賢くなっています。もちろんフロンティアモデルの水準には及びませんし、Opus 級の LLM を使えるなんて夢のまた夢です。それでも、対象を狭く絞り、しっかり支えたソフトウェアアーキテクチャ（つまり大量の手なずけ作業）があれば、こうした小型の LLM でも質の高い出力を出せます。

とはいえ、それでインフラが当初は小規模だという事実が解決するわけではなく、何千人ものユーザーが毎日コンテンツを生成すれば、推論リソースは足りなくなります。しかも、それなりの速さで生成する必要もあります。どんなに出来が良くても、日本語の段落が 1 つ画面に出てくるのを 2 分も座って待ちたい人はいません。

そのため、1 回の生成ごとに AI が行う推論タスクは、たとえば次のようになります。

1. 制約の範囲内で、文、段落、または短い物語を生成する。おそらくある程度の推論が必要で、内容が長いほど時間がかかる。
2. 上に挙げた質問のファミリーに基づいて、生成した文章を評価する。
3. プログラムで修正できなかった箇所は、文をピンポイントの外科的な修正パスに通す。
4. ステップ 2 をもう一度繰り返す。
5. 場合によっては、ユーザーに送る前にステップ 3 とステップ 2 をもう一度繰り返す。

エンタープライズ向けの GPU とプレフィックスキャッシュを使っても、この処理には 1、2 分かかることがあります。しかも並列推論のスロットは 8 つしかないので、同時に生成しようとする人が 8 人を超えると、ジョブを待ち行列に入れなければなりません。どう考えても実用的ではありません。

そこで登場するのが System One モデルです。

System One モデルには、従来の LLM に比べていくつかの重要な利点があり、私のようなユースケースにはうってつけです。

1. 応答が爆速です。私はオーストラリアにいて、Jev はシリコンバレーで運用されていますが、それでも呼び出しは ping 込みで約 258ms で返ってきます。従来の LLM と比べれば圧倒的に有利です。
2. 多くの質問に並列で答えられます。質問を 1 つずつ順番に処理しなければならない LLM と違い、System One モデルはまとめて受け取った質問に、質問 1 つの場合とほぼ同じ時間で答えを返せます。つまり、LLM で 9 つの質問にきちんと答えるのに 60 秒かかったとしても、System One モデルなら同じ 9 つに 258ms で答えられるということです。問う質問が多いほど、Jev のようなツールから得られる利点は大きくなります。

3. 信じられないほど安いです。このプロジェクトの間、Jev に使ったのは 1000 回の呼び出しあたりわずか 0.025 米ドルでした。学んだことの 1 つは、Jev は運用コストが驚くほど安いということです。あらゆる場所に組み込んでも抵抗はありません。ほぼタダですから。

もう 1 つ、あまり語られない利点が信頼性です。LLM によっては応答が暴走し、プログラムで処理できない、構造化されていない応答を返すことがあります。Jev は常にパース可能な有効な応答を返すという意味で「型安全（typesafe）」です。

ここで Laya の話になります。今回の実験の主役で、おそらくあなたがこの記事を読んでいる理由でもあるでしょう。Jev の一般公開から数日のうちに、この技術を再現しようとするオープンソースの試みが次々と現れました。

https://github.com/NandhaKishorM/laya

執筆時点で GitHub のスターは実に 35,000 に達し、Laya は勢いよく登場しました。わずか 2 週間ほどで 1000 件を超えるコミットがあり、執筆時点では 3000 件近くになっています。かなり見事な滑り出しで、ソフトウェアエンジニアリングのコミュニティが System One モデルにどれほど関心を持っているかを示しました。

Laya には laya (421M)、laya-multilingual (322M)、laya-typed-decisions (421M) の 3 つのベースモデルが付属していました。ざっくり言うと、laya は万能型、laya-multilingual は英語以外の言語に強い代わりに精度が落ち、laya-typed-decisions は精度が高い代わりに状況への柔軟性が低く、多言語能力も弱いモデルです。

Laya の最も分かりやすい利点は、オープンソースで、インフラを自分で管理できることです。Laya が突然倒産してサーバーを停止し、慌てて代わりを探すか、さもなくば自分のソフトウェアが壊滅的な障害に見舞われるか、という心配がありません。大きく規模を広げたい一方でリスクは最小限に抑えたい、私のような会社にとっては魅力的な動機です。

Laya のもう 1 つの長所は、モデルサイズが小さいことです。標準設定では動作に必要な VRAM はごくわずかで、AI が生成した巨大な README.md によれば CPU でも動かせるそうです。私の実験では、ベースモデルは 2GB の VRAM で動いていたと記憶しており、自分のサーバーインフラに楽に収まりました。

話がうますぎるときは、たいてい裏があります。GitHub のページに載っている統計や Jev との比較では、次のような主張がされています。

なかなか説得力がありそうに見えます。では、落とし穴は何でしょうか？ Laya のモデルがどんなテーマでテストされたかを見てください。

「メールのスパム」「フィッシング」「RAG のパッセージ関連性」「サポートの振り分け」。どれも非常に限定的で、欠点に深く関わるものです。「LLM ガードレール」「モデレーション」「モデルのルーティング」には「ホールドアウト」と書かれていることに気づくでしょう。これは重要な違いです。

簡単に言えば、Laya はワンショットのモデルではありません。手に取ってどんなユースケースにでも組み込める、というわけにはいかないのです。そのままの状態では非常に限られた能力しかなく、それ以外のことにはほとんど役に立ちません。Jev が本領を発揮するのは、まさにこの点です。「とにかく動く」のです。Infinilang と laya-multilingual モデルで行った最初のテストは完全な失敗で、必要なタスクをどれ一つとして十分にこなせませんでした。

最初の失敗のあと、すぐには諦めませんでした。kcalc.ai と Infinilang はまだ本番稼働まで時間があるので、かなり本格的なサーバーインフラがほとんど使われずに眠っています。つまり Qwen 3.8 27B が仕事を待って待機していて、強力な GPU が必要になれば、いつでも止めて訓練に回せるわけです。実験の時間です。

現実問題として、AI モデルの訓練には法的に深刻なハードルがあります。法人として、Hex Pro はこうした法律をしっかり守らなければなりません。そこで、あらゆるライセンス要件に従うよう細心の注意を払いました。

最初の実験は比較的シンプルでした。目的は、訓練したモデルが事前に決めた基準を満たせるかどうかを確かめることです。

1. Qwen 3.8 が、Infinilang のプロトタイプで必要になるのと同じ方法で、日本語の例を 1,995 件生成しました。

2. Claude Opus が 3 つ一組の審査団で 6 つのファミリーについて各出力を評価し、これを比較の基準となる「ゴールド」としました。

3. 教師役の Qwen 3.8 が、同じ 6 つのファミリーについて独自に評価し、訓練データにラベルを付けました。

最初の実験の 6 つのファミリーは次のとおりです。

• S1：文がどのくらい自然か（5 点満点のスコア、指標：Spearman）
• S2：文が不自然に削られた、あるいは壊れたように読める（はい／いいえ、指標：pAUROC）
• S3：英語の訳が忠実である（はい／いいえ、指標：pAUROC）
• P1：3 つの修正候補のうち最良のもの、またはどれでもない（4 択、指標：ゴールドとの一致率）
• P2：修正候補に許容できるものはあるか？（はい／いいえ、指標：pAUROC）
• G1：文が文法的に正しい（はい／いいえ、指標：pAUROC）

結果は期待外れでした。特に目立ったのは S1（自然さ）で、Spearman で 0.60 の基準を満たす必要があったのに、0.452 にとどまりました。とっさに、Laya で訓練するという構想はその場でお蔵入りにしようと思いました。この時点で 1 日半ほど費やしていて、この結果ではとても足りなかったのです。

時間をかける価値はないと判断し、実験はそこで打ち切りました。Jev は運用コストがとても安いので、モデルを訓練するほうが、Jev を 5 年間ヘビーに使うより桁違いにお金がかかります。その日の少しあとで、ふと思い立って同じ実験で Jev をテストしてみたところ、とても興味深いことが分かりました。

おいおい！ ちょっと待てよ。なんだこの数字は？ 教師はすべての指標で Jev と互角で、文の修正候補を選ぶタスクでは、むしろ大差で勝っていました。とはいえ、私が一番納得させられたのは S1 の 0.446 という数字です。Jev も 0.6 の基準を満たしていなかったのです。

この結果でプロジェクトは息を吹き返し、私はすぐにこれを足がかりに先へ進もうとしました。ざっと試しただけで、Infinilang のこれらのタスクでは Jev に並んだのです。ただ一点、Jev が終始まったく寄せつけなかったところがあり、それがキャリブレーションです。Laya でも実際の結果はしっかりしていましたが、Jev が出す「確信度」のスコアはあらゆる面ではるかに優れています。Jev のスコアは多次元的で、何かに確信があるときとないときを分かっているのです。どんなタスクにも差し込めるワンショットのモデルにとって、これはとても重要です。非常に限られたタスクのために作られたモデルなら、キャリブレーションの数値はそれほど必要ではありません。

この時点で実験 1 を締めくくり、ベンチマークを凍結しました。これからお金を使うことになり、話は本格的になります。今度の目標は、Infinilang 向けの能力で Jev を大きく上回ることでした。実験 1 のスコアを改善する方法は、私の見たところ 3 つありました。

1. 訓練データを増やす
2. より優れた LLM を使う
3. より多様な評価基準（ルーブリック）にする

この時点で、Jev のベンチマークはすべての結果を集め終えてから出すと決めました。Jev のベンチマークを一度開けてしまえば、Jev を隔離しておくために、新しいデータセットに移らなければならないからです。

最初のステップは、別の教師候補の選別でした。探していたのは、はるかに大きいモデルか、Infinilang の日本語の制約でより良い成績を出せそうなモデルです。候補は次のとおりです。

• DeepSeek V4.1：巨大で有能な推論モデルで、推論コストも比較的安い。日本語のスコアが高い。
• Gemma 4 31B：Infinilang のプロトタイプで試したことがあり、制約外の漢字が漏れ出るのを防ぐ点で際立っていた。自分のサーバーインフラで動かせるほど小さいので、テストは実質無料。
• Qwen 3.8 Flash Next：実質的には Qwen 4 のプレビュー版。混合エキスパート（MOE）モデルで、Qwen 3.8 27B よりはるかに大きく、知識も豊富。
• Hy3 と Inkling-Small：あまり知られていない 2 つのモデルで、日本語の能力が高いかもしれないと考えた。

ほかのモデルは候補から外しました。たいていは、ライセンスで訓練への利用が認められていないためです。

最初に脱落したのは Qwen 3.8 Flash Next です。大きな問題は、生成器（Qwen 3.8 27B）と同じ系列のモデルであるため、自己選好のリスクがあることでした。Extreme Self-Preference in Language Models（Steven A. Lehr、Mary Cipperman、Mahzarin R. Banaji、2026 年）は一読の価値があります。LLM は自分の出力を好み、他者の出力には厳しくなりがちだと示した研究です。

「自己選好は生物の基本的な特徴である。大規模言語モデル（LLM）には感覚がないため、こうした歪みは避けられると予想されるかもしれない。しかし、72 の実験と約 41,000 件のクエリを通じて、我々は広く使われている 8 つの LLM に大規模な自己選好があることを発見した。」

自己選好が結果に影響するリスクは高すぎましたし、テストでもその結果は Qwen 3.8 27B とほぼ一致していました。27B 版を無料で使って同じような結果が得られるのに、そんなリスクを抱えたモデルに実際のお金をつぎ込む意味はありません。

次に脱落したのは Hy3 と Inkling-Small です。ここで言うことはあまりありません。費用が高く、ほかのどのモデルよりも良い結果は出せませんでした。

全体を通して明らかに抜きん出ていたのが DeepSeek V4.1 です。結果は予想をはるかに超えていました。DeepSeek については、OpenAI と Anthropic から何もかも盗んだ、品質の低い中国製のパクリモデルにすぎないという印象をずっと持っていました。盗んだという点はおそらく本当でしょうが、もはや品質が低いとは言えません。そのデータでの訓練も認めているオープンウェイトモデルの中では、間違いなく最高でした。中国の人たちに神のご加護を。

最後のモデルは Gemma 4 です。ほとんどのファミリーでは DeepSeek が圧倒しました。Gemma 4 はほとんどの点で DeepSeek の水準に達しており、特に S3（忠実な翻訳）では好成績を収めました。P2（許容できる修正があるか）と B2（話題に沿う）でも良い結果でした。テストは無料なので、続けて使う価値があると判断しました。

こうして、以降のテストはすべて Qwen 3.8 27B、Gemma 4 31B、DeepSeek V4.1 で行うことになりました。

最初の実験ではファミリーの数が限られていましたが、Infinilang の中でこのモデルを使える場面はもっとたくさんあります。必要になるすべてのタスクについて、確実に訓練しておきたかったのです。

新しい評価基準は 14 のファミリーで構成しました。前述の 6 つ（S1、S2、S3、P1、P2、G1）は表現を磨いて引き締め、そこに次の新しいファミリーを加えました。

• B1：文章に一貫性がある（はい／いいえ、指標：pAUROC）
• B2：文章が話題に沿っている（はい／いいえ、指標：pAUROC）
• B3：文章が未成年にふさわしい（はい／いいえ、指標：pAUROC）
• B4：実在のブランドや場所を含まない（はい／いいえ、指標：pAUROC）
• B5：N+1（新出漢字）の語を文脈から推測できる（はい／いいえ、指標：pAUROC）
• B6：文章に再利用する価値がある（5 点満点のスコア、指標：Harrell's C）
• B7：文章の日本語が自然である（5 点満点のスコア、指標：Harrell's C）
• PS2：文章の日本語が壊れているように読める（はい／いいえ、指標：pAUROC）

今回は、訓練データが 1 行の日本語（1、2 文）だけではありません。文、段落、短い物語が混ざったものになります。評価基準もこの必要に合わせて拡張しました。また、ほかのユーザー向けに再利用するためのキャッシュや、年齢制限のために未成年にふさわしいコンテンツを判別することなど、私が関心を持っていた機能がほかにもいくつかあることにお気づきでしょう。

GPU が 10 時間うなりを上げ、Qwen 3.8 27B で新しいトピックと訓練用の素材を生成し続けました。ここで訓練データの生成に Qwen を使い続けたのは、今後 Infinilang の生成に使われるのが、どのみちこのモデルだからです。ここでもっと強力なモデルを使うのは逆効果になります。

最終的に 215,000 行のデータと、そのすべてに対する Claude のゴールド審査団の判定がそろいました。Jev にも拡張して強化した評価基準を与えることにしており、これにより実験 1 のベンチマークに対する Jev の結果は大きく向上しました。

以下の結果は、強化した評価基準とともに作った新しいルールを使っている点に注意してください。そのため、実験 1 を大きく上回っています。また、一部のファミリーでは、DeepSeek と Gemma の結果を平均し、互いの一致度で重み付けする方法も試しました。もう 1 つ注意点として、モデルによっては、場合によって推論を増やすとかえって結果が悪くなりました。したがって、これらの結果は、モデルとファミリーごとに、推論ありとなし、ルールありとなしのさまざまな組み合わせを調整したうえで得られた最良の値です。

*K8：思考をオフにして短い回答を 8 回サンプリングし、平滑化したヒストグラムにしたもの

これらの数字で、手持ちの材料がどんなものか、かなりよく分かりました。前にも書いたとおり、この新しい基準で Jev もテストしたところ、今回はずっと良い成績でした。Jev は長いテキストで際立っており、これは Laya を考えるうえで押さえておくべき点です。Laya はコンテキストウィンドウがそれほど長くなく、長いテキストの扱いが苦手だからです。

ファミリーごとの教師が決まったので、いよいよ System One モデルを実際に訓練する段階です。思い出してください。実験 2 は、各ファミリーにどの教師が最適かを見極めるためのものでした。だからといって、生徒モデルが教師と同じくらいの成績を出せるとは限りません。これらのタスクをすべて 1 つのモデルにまとめれば、どうしてもトレードオフが生じます。Laya の導入を考えている人は、1 つのモデルにいくつのタスクをこなさせる必要があるかを検討すべきです。たとえば、ファミリーごとに別々のモデルを訓練して限界まで最適化し、その 14 個のモデルをプログラム全体に戦略的に配置すれば、どの面でも最高の結果が得られるでしょう。しかしその場合、14 個のモデルを別々に動かす必要があり、GPU リソースの割り当てがかなり大きくなるという問題があります。つまり規模の問題です。高価なサーバーに何十億も使える巨大企業なら、迷うまでもありません。こうしたモデル 1 つで、最小限のリソースで天文学的な数のユーザーに対応できます。それ以外の人にとっては、貴重な GPU 計算資源の最善の使い道ではないでしょう。

ここからが本番です。GPU を再び稼働させ、今回は 35 時間かけてさらに訓練データを生成し、ラベルを付けました。続いて新しいデータに対して Claude のゴールド審査団を再び走らせ、Ultra（旧 Max 20x）プランで 2 億トークン以上を消費しました。

費用がかさんだのは DeepSeek です。ローカルでは動かせないため、クラウドでの推論が必要でした。9 つのファミリーに選ばれ、費用は 233.56 豪ドル、完了まで 18 時間かかりました。USD で見るとかわいいものですが、AUD で記された銀行の取引明細はずっと痛々しく見えます。Gemma 4 の推論は自前のインフラで動かしたので無料で、割り当てられた少数のファミリーのラベル付けに 60 時間ほどかかりました。

最終的に、チューニングとコンセプトの異なる 4 つの候補を訓練しました。prod-q38、prod-ds41、prod-mix1、prod-mix2 です。外れ値に惑わされないよう、各生徒は 3 つのアームで、アームごとに 2 つのシードを使って訓練しました。最終候補はさらに 3 つのシードで訓練しました。

• アーム A：事前学習済みのヘッドをそのまま使った laya-multilingual（mmBERT）。
• アーム B：新しいヘッドを付けた modernbert-ja-310m。
• アーム E：アーム B のアーキテクチャに移植した sokudan-ja-310m。

130M パラメータでレイテンシを試すアーム D もありましたが、性能では後れを取りました。

最初に訓練した、最も安上がりなモデルです。Qwen だけを使い、最も高いスコアが出たものに応じて構成（推論あり／なし、ルールあり／なし）を変えました。ほかのモデルほどの成績は出ないと分かっていましたが、実験 1 の延長であり、ほかのモデルがどこまで改善できるかを測る基準になりました。

前の実験で明らかに最も成績が良かったのは DeepSeek ですが、いくつかのファミリーでは Qwen が上回るか、DeepSeek にかなり近い成績でした。DeepSeek と同等以上だったところでは、費用を抑えるために Qwen を使いました。

各ファミリーで最良のものを集め、究極の盛り合わせを作ろうとしたモデルです。また、prod-ds41 の生徒が予想より成績が悪かったように見えた箇所では、Qwen を DeepSeek に置き換えることも試しました。

prod-mix1 と似たコンセプトですが、結果の改善につながるかを見るため、P1 と B3 を prod-ds41 と同じ構成に戻しました。

複数のアームで訓練したのは賢明でした。非常に重要なデータが明らかになったからです。laya-multilingual をもとに訓練したアーム（アーム A）は、どれもアーム B とアーム E に劣っていました。これは重要な発見でした。少なくとも日本語だけが必要な私のケースでは、多言語版はゴミ同然だと分かったのです。

System One モデルの訓練に挑戦する人には、Laya に最初から付いているモデルは捨てて、ModernBERT のまっさらなヘッドから訓練することを強くおすすめします。少なくとも、劣ったチェックポイントにだまされないよう、私たちがやったように複数アームのテストは行ってください。

以下は、新しい訓練データと強化した評価基準での、各生徒の最終的な数値と Jev の最終的な数値の比較です。

この結果が面白いのは、必ずしも直感どおりでも予想どおりでもないからです。押さえておくべき重要な点は、各ファミリーの値の訓練が、ほかのすべてのファミリーにわずかずつ、しかし積み重なる形で影響することです。そのため、数値はばらばらです。生徒が教師を上回るケースもありますが、多くはわずかに下回っています。

また、各ファミリーの価値が等しくないため、本当の勝者を決めるのもとても難しいところです。たとえば S1（日本語の自然さ）は重要なファミリーで、ここでは Jev がほかを大きく上回っています。逆に B7（文章全体としての日本語の自然さ）もとても重要ですが、ここでは Jev がほかのすべてのモデルに後れを取っています。

同じように、多くのファミリーで「勝って」いるからといって、そのモデルが自動的に優れているわけではありません。prod-ds41、prod-mix1、prod-mix2 は、ほとんどの場合とても僅差です。prod-mix1 の S2 の 0.890 と prod-ds41 の 0.889 の差は、実質的にゼロです。ノイズを取り除き、各ファミリーで勝ったか同率首位になったものについてだけ、Jev に対する優劣を示すと、それがよりはっきりします。

私の考えでは、望ましい万能型は prod-ds41 です。prod-mix1 はいくつかのファミリー（特に P1、P2、B6）で目を見張る結果を出していますが、ほかのファミリー（S3、S1、B1、B3）では、prod-ds41 よりも大きく Jev に後れを取っています。prod-mix2 はほかの 2 つと比べて深刻な弱点があり、特にいくつかのファミリー（S3、P1、P2、B5）で弱く、残りでもそれほど強くありません。とはいえ全体としては、Jev が本当に優れているいくつかの例外（S1、S3、B3）を除き、3 つとも概ね Jev より優位に立っています。

そのため、prod-ds41 と prod-mix1 のどちらかを選ぶなら、すべてのファミリーでより安定して強いという一点で、prod-ds41 が上回ります。

最終的に栄冠を手にし、infini-jp-v1 の名を得たのは prod-ds41 でした。数値は、ほとんどの役割をこなせる能力があることをはっきり示しています。残念な例外は S1（文の自然さ）ですが、これについてはいずれにせよ別の解決策を見つけました（詳しくは後ほど）。

では本題です。Laya は Jev より優れているのか。もしかしたら？ でも、おそらく違います。今回のこの特定のタスク群では確かに Jev を上回っていますが、開発にどれだけのコストがかかったかを整理してみましょう。

このプロジェクトに使った費用は全部で 270 米ドル（389 豪ドル）で、そのうちクラウドでの推論が 268.23 米ドル、Jev が 0.21 米ドルです。Anthropic や OpenAI が抱えているという数千億規模の借金を真に受けるなら、AI の訓練としては安いものです。資本が限られ、収益も（今のところ）わずかなスタートアップの基準では、安くはありません。それでも、今後ほかのプロジェクトでこれを使うべきかという重要な問いに答えてくれたので、価値のある研究開発でした。さらに、1000 件を超えるコミットと 14,522 件の単体テストを持つ訓練パイプラインのプロジェクトができたので、今後また System One モデルを開発するときは、評価基準を磨いてモデルの比較テストを行うだけで済みます。

実際に手を動かす時間という点では、安くはありませんでした。Claude Code をくれた Dario 様様です。面倒な雑務（実行が終わるのを見張ったり、次の工程をキューに入れたりなど）の多くを引き受けてくれたのですから。おかげで手が止まる時間は最小限で、作業は夜通し進みました。それでも、このプロジェクトを最初から最後まで終えるのに 24 日かかりました。AI の助けがなければ 6 か月はかかったはずです。それは間違いありません。

AI が膨大な時間を節約し、並行してほかの作業を進められたとはいえ、私自身が実際に手を動かした時間は、以前の単価で換算すると約 5000 豪ドル分の労働に相当します。System One モデルを訓練するなら、このコストは必ず考慮すべきです。

私は、高速で強力なエンタープライズ級の GPU を使えるという点では恵まれています。それでも、このプロジェクトには 40 時間以上 GPU を専有する必要があり、電気代がいくらになったかは考えるのも恐ろしいです。知りたくもありません。

もう 1 つの継続的なコストは、サーバーの VRAM を約 2GB 占有することです。

これは重要な問いですが、数値で表すのは難しいものです。もし私がこれに挑戦するかどうか検討しているなら、次の問いに答えたいと思います。

• Jev はそのタスクをうまくこなせるか？
• 呼び出し量はどのくらいを見込んでいるか？
• こなしてもらう必要のあるタスクはいくつあり、どのくらい多様か？
• 投資を回収するまでにどのくらいかかるか？
• TypeSafe がなくなってもソフトウェアが動き続けると分かっている安心感は、どのくらい重要か？
• 正確なキャリブレーション（確信度）をどのくらい重視するか？

私の場合、能力の向上によって Infinilang の性能が上がるかもしれません。その結果 Infinilang の性能が上がり、より大きなユーザー基盤を築けるなら、いずれ必ず元が取れます。Jev ではなく Laya を使うことを正当化できるのは、そう考えた場合だけです。

• レイテンシ：オーストラリアからだと、Jev は往復で約 258ms かかります。Laya は平均約 19ms で、Jev より少なくとも 13 倍、DeepSeek より 2000 倍速いです。
• GPU の余力：VRAM を 2GB 使います。無視できる量ではありませんが、巨大でもありません。ただ、本当の利点はここからです。infini-jp-v1 が答えている 14 のファミリーの質問は、Qwen 3.8 27B が（下手に）答えなくて済む質問です。そのぶん GPU が空き、ほかのもっと重要でふさわしいリクエストに応えられます。
• 上位モデルの模倣：DeepSeek V4.1 を動かさなくても、それにかなり近い答えが得られます。infini-jp-v1 はこれらのタスクで Qwen 3.8 27B をはるかに上回り、そのために VRAM 614GB の DeepSeek モデルを持ち出す必要もありません。
• 事業の安定性：何度か触れたとおり、自分のモデルを使えば、Jev が突然なくなる心配をしなくて済みます。予期せぬ障害も、代わりを探して慌てふためくこともありません。自分のソフトウェアが動いていれば、System One モデルも動いていると分かります。
• 限られたタスクでの優位性？：本番環境で実際に性能が上回るかどうかは、まだ分かりません。様子を見ましょう。スコアで見たとおり、理論上は Infinilang で 6% 優れていますが、それはすべてのファミリーを通しての話で、肝心のファミリーでそうとは限りません。

ご存じない方のために説明すると、LoRA（Low-Rank Adaptation）は、LLM に差し込むだけで使える人格のようなものです。代わりに「ファインチューニング」と呼ぶのを耳にしたことがあるかもしれません。独立したサービスである System One モデルと違い、LoRA は推論時に LLM に直接適用され、重みをずらして振る舞いを変えます。

そこで、Infinilang の開発の後半で、Qwen 3.8 27B がより質の高い出力を出し、より厳しいルールに従えるよう LoRA を訓練しました。つまり、infini-jp-v1 はより質の高い文章を分類することになります。それほど頑張らなくて済み、特に覚えている漢字が少ないユーザーに対して、より確実な効果が期待できます。

開発を続けながら、Infinilang をさらに良くしていくつもりです。