ChatGPTのように文章を長く生成するのではなく、入力に対して「invoice か refund か」「危険か安全か」といった判断を素早く返すモデルがある。Ollayaは、その種の decision model を自分のPCやサーバー上で動かすための仕組みを前面に出してきた。クラウドAPIに投げるのではなく、ローカルで、しかも数ミリ秒単位の応答を狙うのが売りだ。特に、個人情報や社内データを外に出しづらい用途では、かなり現実的な選択肢に見える。
Ollayaは、open decision models を自分のマシンでダウンロードして提供するサイト兼ツールだ。トップページでは「typed questions about any text or JSON」に答え、しかも calibrated answers を milliseconds で返すと説明している。ここでいう decision model は、長文を生成するLLMとは少し違う。選択肢の中から答えを一つ返したり、yes/no を出したり、スコアを付けたりする用途に向いたモデルで、文章を1トークンずつ出すのではなく、1回の forward pass で判断を出すのが特徴だとされる。
ページでは、たとえば ollaya run decider --preset agent という実行例が出てくる。Fix the typo in README.md と git push --force origin main のような依頼文とコマンドを与え、そこに対して action block の値や risk、destructive yes といった判定が返る。実際の出力例としては decider:2b が RTX 4090 上で 178 ms で応答したと書かれている。
速度の説明もかなり具体的だ。Ollayaは、NVIDIA RTX 4090 上での five-question request を例に、Laya では end to end で 8〜10 ms ほどだとしている。一方で、第三者ベンチマークによる TypeSafe Jev の hosted API は 236〜276 ms とされ、同じ軸に並べた図では laya:multilingual が 8.1 ms、laya:en が 9.6 ms、gliclass が 14.7 ms、nli が 20.4 ms、decider:0.8b が 155 ms、decider:2b が 190 ms、TypeSafe Jev hosted API が 236〜276 ms と示されていた。もちろん、Ollaya側も注記で「セットアップが違うので、おおまかな比較として読んでほしい」としている。
もう一つの柱は互換性だ。Ollayaは TypeSafe のAPIに合わせていて、/v1/systemone と /v1/models を同じ request/response shape で返す。公式の TypeSafe Python SDK 0.7.1 も、そのままローカルサーバーに向けて動くとしている。例では TYPESAFE_BASE_URL=http://localhost:11435、TYPESAFE_API_KEY=local、TYPESAFE_DEFAULT_MODEL=laya を設定し、/v1/systemone に投げると、intent に invoice が confidence: 0.9547 で返る様子が載っていた。
モデル群もかなり幅広い。Convai Innovations の Laya は英語モデルと100+言語モデル、typed decisions 用のモデル、ルーターを含み、Mapika の decider は Qwen3.5 ベースの decoder decision model、Moritz Laurer の nli は entailment を使う zero-shot classifier、Knowledgator の gliclass は選択肢ごとにスコアを付ける classifier、Qwen team の qwen3guard は安全性判定、Jared Palmer の kev や Victor Hugo Panisa の von も並ぶ。Ollayaは、こうした open models を自分の hardware に置いて使える、と打ち出している。
プライバシー面の説明もはっきりしている。Tickets、emails、user messages のような機微なデータは外に出さず、すでにある場所でスコアリングする。server はデフォルトで 127.0.0.1 を listen し、モデルの重みは作者の Hugging Face repository から commit 固定で取り、sha256 で検証する。再ホストはせず、runtime は Apache-2.0。料金は per-token ではなく、使えるだけ使う形だ。対応環境は macOS、Windows、Linux、Docker で、デスクトップアプリと command line があり、NVIDIA GPU があれば milliseconds に落とせるとしている。ページの最後は、ollaya run laya の一行で始められる、と締めていた。
このサイトで面白いのは、生成AIの延長線ではなく、判断の道具としてAIを置き直している点だと思う。文章を出すモデルは派手だが、実務で繰り返し起きるのは、問い合わせを分類する、危険な操作を止める、フォームの入力を判定する、といった地味な作業だ。そこに対して「数ミリ秒で返る」「一回の forward pass で済む」と言われると、急に使い道が具体的になる。人手でルールを書くより柔らかく、LLMより安定した範囲で、しかも待たされない。これはかなり強い。
ただ、ベンチマークの見せ方には少し注意がいると思う。Ollayaはローカルの RTX 4090 と、第三者ベンチマークの hosted API を並べているが、注記でも書いている通り条件は揃っていない。とはいえ、ここで本当に伝えたいのは「正確な同一条件比較」ではなく、「ローカルでこのくらいまで下がる」という感触だろう。実務側が知りたいのもそこだ。精密な順位より、API待ちが消えるかどうかのほうが重要だからだ。そう考えると、この比較は宣伝としてより、採用検討の入口として読むのが正しい。
/v1/systemone や公式SDKがそのまま動くというのは、地味だが効く。新しいローカル基盤は、機能が良くても「既存のコードをどれだけ直すか」で脱落しやすい。特に社内システムでは、モデルそのものより、周辺の認証やデータ転送、ログ、監査のほうが面倒だからだ。そこに既存API互換を置くと、アプリ側は接続先を変えるだけで試せる。最初の導入ハードルが一気に下がる。
一方で、互換性が強いほど、利用者は「本当にローカルで十分か」を厳しく見るはずだ。クラウドの大規模モデルと同じような安心感はまだないし、モデルの種類も用途次第では足りないかもしれない。だからOllayaは、理想論で勝つというより、既存の TypeSafe を使っているチームに「試してみるならここから」と差し込む戦略に見える。これはかなり現実的だ。新しい思想を売るというより、今のワークフローの中に入り込む発想だからだ。
Ollayaの説明の中で、いちばん強いのは性能よりも、tickets や emails を外に出さないというメッセージかもしれない。AI利用の現場では、モデルの賢さより、データをどこに置いたかのほうがずっと重いことが多い。特にサポート、法務、医療、社内ヘルプデスクのような領域では、外部APIに生テキストを送ること自体が止められる場合がある。そこにローカル実行と、127.0.0.1 での待受、重みの検証まで含めて提示したのは、かなり筋が通っている。
ただし、ローカルだから自動的に安全というわけでもない。モデルを動かすマシンの管理、重みの更新、ログの保存、権限の切り分けは別途必要になる。API課金がなくなる代わりに、運用の責任が手元に戻るとも言える。だからこの製品は、完全な魔法というより「自分で面倒を見る代わりに、判断を速く、安く、外に出さずに回せる」道具として見るのが正確だと思う。そこを受け入れられる組織には、かなり相性がいいはずだ。
Ollayaが並べているモデルを見ると、狙っているのは会話エージェントの全面置き換えではない。choice、score、yes/no のような型が決まった問いに強いモデルを集め、そこに calibration を付けて、しきい値を置いて運用できるようにしている。ここが重要で、判断モデルは「それっぽい返事」よりも、「どの確率なら止めるか」を決めやすい。ビジネス用途では、この制御しやすさがかなり大きい。
その意味で、OllayaはAIの次の主戦場の一つをかなり正しく掴んでいると思う。派手な生成ではなく、毎日大量に発生する判定。しかも、待たせたくない、外に出したくない、料金は読みづらいのは困る、という条件が重なるところだ。ここでは、巨大な汎用モデルより、軽くて校正された decision model のほうが合う場面が多いだろう。もちろん、どこまで置き換えられるかは用途次第だが、「LLMは文章を作るもの」という見方を少しずつ壊していく流れの一部として、Ollayaはかなりわかりやすい例になっている。
