問い合わせを一件読むたびに、「どの担当へ回すか」「注文番号があるか」「人の確認が必要か」を別々にAIへ尋ねる。同じ文章を繰り返し処理するコストが、大量の仕分けでは気になってきます。Flideは、このような判断用モデルを動かす推論エンジンです。モデルそのものや、顧客への返信を自動送信するサービスではありません。
2026年11月9日時点の最新版は0.1.9。対応モデルの追加と、複数のリクエストを一度に送る機能が入りました。この記事では、Jevとの関係、何を共有して高速化するのか、日本語の問い合わせで試す前に必要な条件を整理します。モデルの速度・日本語精度は本誌では未実測です。
公式の動作条件はLinuxとNVIDIA GPUです。Apple SiliconのMacで動くMLX向け製品としては案内されていません。Macから別のGPUサーバーを呼ぶ構成と、Mac内で推論する構成は分けて考えてください。
今回の更新:初公開ではなく、0.1.8から0.1.9への拡張
| 出来事 | 確認した日時・版 | 内容 |
|---|---|---|
| 0.1.0の公開 | 公式READMEでは2026年10月24日、0.1.0 | 今回が製品の初登場ではない |
| 0.1.8の配布 | 2026年11月8日23:27 JST | AutoTrust・Clef系とdrex-max-v1を追加と告知 |
| 0.1.9の配布 | 2026年11月9日03:31 JST | pplx-decider-v1.1-27b・JEV-35Bの追加と複数リクエスト対応を告知 |
日付は公式READMEの更新案内とPyPIの配布履歴を照合しました。0.1.9の配布ファイルはUTCでは11月8日18:31です。READMEの「11月9日」と矛盾するわけではなく、日付を読む際は時差を分ける必要があります。GitHub Releasesの一覧は確認時点で空でした。
Jev、判断モデル、Flideの役割を分ける
| 層 | 担当すること | 混同しない点 |
|---|---|---|
| 判断モデル | 入力を読んで、指定した選択肢や段階へ確率を割り当てる | モデルが変われば判断品質も変わる |
| Flide | 対応モデルを読み込み、計算をまとめてAPIとして提供する | TypeSafeのJev本体の新バージョンではない |
| 業務アプリ | 入力を整え、判定を記録し、人の確認や次の処理へ渡す | Flideを入れるだけで社内の判断規則が決まるわけではない |
FlideはJev型の /v1/systemone APIを提供しますが、API形式が近いことと、TypeSafeのJevと同じ重み・回答・料金になることは別です。Jev自体の入口は既存のJev解説を参照してください。今回は、対応する公開モデルを自分の環境で配信する側の話です。
なぜ速くなるのか:共有する文章と、独立させる質問
公式が説明する中心技術はExact State Forkingです。stateは、判定対象の文章やデータを指します。同じstateについて複数の質問をする場合、共通部分の計算を共有し、そこから質問ごとの処理へ分ける考え方です。
| 問い合わせ一件に対する処理 | 共有する材料 | 質問ごとの目的 |
|---|---|---|
| 担当の振り分け | 同じ問い合わせ本文 | 交換相談か、請求相談か、人へ戻すか |
| 不足情報の確認 | 同じ問い合わせ本文 | 注文番号が本文にあるか |
| 対応前の確認項目 | 同じ問い合わせ本文 | 納品日など必要な情報が足りるか |
質問をただ一つの長いプロンプトに詰め込むと、前の質問や追加した区切りが、別の質問の答えへ影響する可能性があります。Flideは、各質問を単独で尋ねた場合の計算関係を保つことを狙っています。ただし公式FAQも丸め誤差を留保しています。通常の計算で全ビットが常に同一だという意味ではありません。--batch-invariantは、同時に処理される他のリクエストによる数値の揺れを抑える別の設定です。
これは計算の再利用と再現性の話です。モデルが誤って分類する問題、日本語の曖昧な表現、入力にない情報を推測する問題が自動的に解決するわけではありません。
「最大9倍台」を読むときは、測定条件もセットで
作者のREADMEは、H200を1基、Qwen3.5-0.8Bを使った条件で、vLLM・SGLangとの比較を報告しています。Show HNの見出しは最大9.5倍、確認したREADMEの概要は最大9.4倍と表記が異なります。本誌ではこの差を丸めて独自の性能値にせず、作者報告であり、モデル・問題・同時実行数によって変わると扱います。
導入判断で知りたいのは、自分たちの長さの日本語データ、質問数、GPUで、何件を何秒で処理できるかです。広告的な最大値を、手元のMacや別モデルの速度へ当てはめることはできません。GPU代、起動時間、保守にかかる時間まで含めて比較します。
動作条件と費用:Linux・NVIDIA GPUを先に確認する
公式インストール案内は、Linux、NVIDIA GPU、Python 3.10以上、PyTorch 2.12以上を前提にしています。対象コミットのpyproject.tomlではtorchの上限を2.15未満に指定しています。CUDAとドライバーの組み合わせも必要で、画像を使う場合はtorchvisionを対応するtorchとそろえます。
FlideのコードはApache-2.0ですが、モデルの重みにはそれぞれの利用条件があります。ソフトウェアを取得できても、GPU、電力、サーバー運用が無料になるわけではありません。必要なVRAMはモデルのサイズ、量子化、入力の長さ、並列数で変わり、「Flideなら何GBで全部動く」と一律には言えません。モデルによっては取得時の利用条件への同意も確認します。
今回の作業環境はDarwin arm64のMacです。公式のLinux・NVIDIA GPU条件を満たさないため、推論サーバーを起動したという実測は載せていません。公開コードのリクエスト検証部分を分離して、日本語のサンプルJSONの形式だけ確認しています。
試す手順:架空の問い合わせ一件を、二つの質問で点検する
以下は条件を満たす検証用Linux環境で試すための手順案です。本誌でGPU実行済みの手順ではありません。まず既存環境と分けたPython環境を作り、0.1.9を指定して導入します。公式のQuick startにあるQwen3.5-4Bを例にしますが、モデルの利用条件と容量は別途確認してください。
python3 -m venv .venvsource .venv/bin/activatepython -m pip install "flide==0.1.9"flide serve --model Qwen/Qwen3.5-4B --host 127.0.0.1公式READMEでは、既定のサーバーは全ネットワークインターフェースで待ち受けます。この例は127.0.0.1を明示して同じマシンからだけ接続します。外部公開や認証を整える作業は別の段階です。初回はモデル取得やGPU用カーネルの準備に時間がかかる場合があります。
次の内容をrequest.jsonとして保存します。すべて架空の入力です。「supportを必ず選ぶ」とは指示せず、担当を決められない選択肢を用意しています。
{ "state": "架空の問い合わせ:昨日届いたキーボードの一部のキーが反応しません。交換を希望します。注文番号は書かれていません。", "questions": { "route": { "type": "choice", "instructions": "最初に確認を依頼する担当を選ぶ。本文にない情報を補わない。", "criteria": { "support": "製品の不具合・交換相談の窓口", "billing": "請求・入金の確認窓口", "human": "情報が足りず担当を決められないため人が確認" } }, "missing_order": { "type": "noul", "instructions": "問い合わせ本文に注文番号が記載されていない。" } }}curl --fail-with-body http://127.0.0.1:8000/healthcurl --fail-with-body http://127.0.0.1:8000/v1/systemone \ -H "Content-Type: application/json" \ --data-binary @request.json返る数値や選択結果はここでは作っていません。人の観点では不具合・交換相談を含み、注文番号が書かれていない例です。モデルがそう読めるかを、実際の返答と比べます。API仕様のchoiceは候補選択、noulは命題が成り立つ確率を返す形式です。確率やconfidenceは、その判定が業務上正しいという保証ではありません。
0.1.9の一括送信:一件の複数質問とは別の機能
ここまでの例は「一件のstateに二つの質問」です。今回加わった機能は、それとは別に、複数の独立したリクエストをrequests配列に入れて一度に送るものです。0.1.9のサーバー実装で確認しました。
この実装は、各項目の検査を終えてから実行し、結果をresultsへまとめます。不正な項目や実行失敗を一部成功として黙って返す設計ではないため、アプリ側は一括処理全体の失敗にも対応します。大量データをいきなり送るより、一件の評価、少量の一括処理、再試行の設計の順に進めます。API説明ページには単一リクエスト中心の記載が残っていたため、新機能は版を固定したコードを根拠にしています。
業務で価値が出るかを測る:速さと誤りを別々に記録する
| 試す場面 | 人が先に決める正解・基準 | 残す記録 |
|---|---|---|
| 問い合わせの担当分け | 担当区分と、判断不能として戻す条件 | 正答率、担当ごとの誤り、人に戻した割合 |
| 商品説明の不足チェック | 必須項目と、未記載・不明の区別 | 見逃し、誤警報、入力の長さ |
| 社内資料の分類候補 | 分類の定義と複数候補時の扱い | 分類別の結果、質問数、処理時間 |
最初は個人情報を含まない架空例や、利用許可のある匿名化データで、人が付けた正解と比較します。日本語では省略、否定、「交換ではなく返品」といった訂正も含めます。正解付きの評価用データを残して、モデルやプロンプトを変えた後も同じ条件で測れるようにします。これは本誌が提案する検証方法であり、Flideで達成した成果ではありません。
flide verifyは、まとめた質問と単独の質問、バッチの組み合わせ、セッションキャッシュの有無による結果の違いを調べる道具です。verifyに通ることと、日本語業務の正解率が高いことは別です。計算の一貫性を確認したうえで、人の正解との比較を行います。
本誌で確認した範囲と、まだ確認していないこと
対象は2026年11月9日のFlide 0.1.9、ソースコミットa1af291です。PyPIでの配布、更新内容、公式の動作条件、単一リクエストと一括リクエストのコードを確認しました。掲載JSONは、公式のPydanticスキーマで受理されることと、質問が空・choiceの基準が欠ける入力を拒否することを確認しています。これは入力形式の検証であり、モデルの推論成功やAPI通信の成功ではありません。
GPU推論、速度比較、日本語の判定精度、業務コストの削減は未実測です。Jev型の判断を自社GPUへ載せたい開発者には検討価値がありますが、まずは既存の方法と同じデータで比べ、速さだけでなく人へ戻す率と誤りの影響を判断するのが実用的です。