オープンな再実装と systemone エコシステム

このガイドの他のページは「どう使うか」でした。このページはどれを使うか —— そしてその問いが一年前より答えやすく、同時に間違えやすくなった理由です。

一つのインターフェースが事実上の標準になった

POST /v1/systemone はもはや公式 SDK の細部ではありません。事実上の標準になった理由は、 クライアント側の移行コストがほぼゼロだからです。バックエンドの切り替えは base URL の環境変数を変えるだけで、リクエストと応答の形は変わりません。

そこから、同じインターフェースを実装する数十のプロジェクトが生まれました。 任意のオープンモデルを「意思決定モデル化」するもの（logits を読み、テキストを生成しない）、 オープンな基盤への微調整、純粋なローカル実行環境、他のエコシステムをつなぐブリッジまで幅があります。

ローカル代替の位置関係

公開されているオープンな再実装は、パラメータ数で五桁にわたります。 数十万から 27B までです。

再確認できる具体的な数字をいくつか。

• 1B の CPU 実装（GGUF、619 MB）は短い要求で 54 ms、長い要求で 220 ms、 ホスト版が 344 / 345 ms —— ただし精度は 0.815 対 0.927 で、 しかも yes/no の質問しか受け付けません。
• 別のオープン重みは 308 件の密封された判断で 33.1% 対 36.7%（約 13 ms）。
• 専用のフォーム入力モデル（706,048 パラメータ、2.8 MB）は自分のタスクで 99.7%、 汎用モデルは 83.6% —— 著者はこれがホームでの強さであり普遍的勝利ではないと 明記しています。

この表から読み取るべきは順位ではなく桁です。 「6 倍速いが精度は 11 点低い」と 「精度は近いが質問の種類が一つだけ」はまったく別のトレードオフであり、 どちらも「ローカルの代替案」と表現できてしまいます。

適合率：飛ばしてはいけない数字

エコシステムが賑わうとき、問うべきは全員が本当に同じインターフェースを 守っているかです。

あるプロジェクトは /v1/systemone の意味論を 48 条の検査可能な要件に固定し （例：Choice の各選択肢の確率は定義上合計 1、Score の期待値は確率による 重み付き和、選択肢の数は 2 から 255、質問の順序が変わっても答えは変わらない）、 互換を主張する任意のサーバーを検査するスイートを公開しています。

その実測結果：

star の最も多いオープンなポート 8 件のうち、完全に適合していたのは 2 件だけ。

これは二つの方向に効きます。クライアントにとっては「base URL を変えるだけ」が スイートで確認すべきことであり、仮定すべきことではないという意味です。 代替実装を作る側にとっては、精度より到達しやすく、はるかに空いている差別化軸を示します。

選定にとって何を意味するか

まとめると、重心は「どのモデルのスコアが高いか」から離れています。

1. インターフェースは共通で、モデルは交換可能。 あの 48 条の要件が 交換可能性の定義です。まずスイートで確認し、それから他を語ってください。
2. 堀はモデルの外に移りました。 モデル層がコモディティになれば、 真似しにくいのはインターフェース契約 + しきい値方針 + 自分のデータでの校正です。 これはこのガイドの他のページが扱っているものまさにそのもので、 しかも三つともベンダーではなくあなたのリポジトリにあります。
3. 精度差は正しい座標で見る。 「83.6% 対 99.7%」はホームでの専門家の成績であり、 「0.815 対 0.927」は CPU で動き yes/no しか答えない小さなモデルです。 両方を続けて言わないと、表は誤解を招きます。

エコシステムの規模

エコシステムの公開されている規模はおよそ 1,100 件です（2026 年 9 月時点）。

数は品質ではなく、成熟度でもありません。 その件数には 単一コミットで同じ足場を共有するプロジェクトが多く含まれます。同じ作者が同じ日に 複数のリポジトリを出し、AGENTS.md を共有し、コミット履歴は一つで、 コードより文章の方がずっと多い、という形です。完全に正当なこともありますが、 まだ証明されていないだけです。選ぶときは「動くものがあるか」でふるいにかけ、 「どこかの一覧に載っていたか」では判断しないでください。

一文で

モデル層は消耗品になりつつあり、インターフェース・しきい値・校正はそうではありません。 力を後ろ三つに注いでください。最初のものはいつでも交換できます。