この実験で使った問い合わせは、すべて検証用に作った架空の文章です。実在のお客さまの声ではありません。
1時間前から、すべてのお客さまが決済できません。注文が止まっています。
決めたいのは、返事の文面ではない。この一通を、誰に回すか。請求の担当か、技術の担当か、営業の担当か。
この仕事を、文章を一文字も書かないAIに任せたらどうなるだろう。しかも、問い合わせを外部の推論APIへ送らず、手元の機械で。
Cloudflareが公開した判断モデルClef-flashを、M4 Max・メモリ128GBのMacと、RTX 4070 Ti SUPER・16GBのGPUで動かした。Macでは、保存した静かな時の16件で1件の中央値が約0.6秒。載せ方を工夫し、GPUを専有したNVIDIAの構成では、保存集計の中央値が約0.11秒だった。
担当の第一候補は、両方とも作者案と16/16一致。ただし、問い合わせも行き先案も制作側のAIが一緒に作ったものだ。実際の窓口での精度を測った数字ではない。それでも、「手元で使える判断部品になりそうか」という最初の問いには、具体的な答えが見えてきた。
返事を書くAIではなく、行き先を選ぶAI
Clef-flashに渡すのは、状況と型を決めた質問だ。今回は「急ぎか」「どの担当か」「影響の深刻さはどの段階か」の三つ。モデルは一度の前向き計算で候補を採点し、選択肢ごとの確率を返す。返信文は書かない。公式モデルカード
土台はQwen3.5-9B。公開された重みを動かしているので、私たちが一からモデルを学習したわけではない。今回作ったのは、同じ問い合わせを流し、返答と時間を保存する実験環境だ。
問い合わせは架空の16件。技術6、請求5、営業5を想定し、作者の担当案はモデルに渡さず、本文と固定の質問から選ばせた。「二重に引き落とされた」「プランの見積もりがほしい」「注文が入っても在庫が減らない」といった文を使った。
採点できるのは担当案との一致だけ。「急ぎ」と「深刻さ」には独立した正解を用意していない。担当案も、問い合わせを作ったClaudeが同時に付けたもので、別の窓口担当者が付けた正解ではない。
Macで返ってきたのは、担当と「迷い」の数字だった
MacはM4 Max、メモリ128GB。公式の読み込み処理にApple GPUを使う指定を渡し、必要な依存関係を整えると動いた。公式モデルカードの動作確認環境はH200 1枚なので、このMacでの結果は私たちの観測だ。
冒頭の決済停止の一通に、保存された16件の実行ではこう返ってきた。
急ぎ：はい 88.1%
担当：技術 81.1%、請求14.3%、営業4.6%
深刻さ：致命的 83.1%
技術担当が第一候補だが、請求にも値が残っている。「何を選んだか」だけでなく、候補がどれくらい分かれたかが見える。ただし、この81.1%は実際の正答率ではない。モデルが候補へ割り当てた値だ。なぜその値になったかという理由文も、今回の返答にはない。
16件を1件ずつ流した時間は、中央値598.75ミリ秒、最短542.5、最長659.7ミリ秒。合計は9,579.4ミリ秒、約9.6秒だった。これは重い作業が静かな時の保存記録で、モデルの読み込み時間は含まない。
1件ずつ担当候補を付ける下準備なら、約0.6秒は待てそうだ。大量の問い合わせを一気に処理するなら、同時実行や処理能力も別に確かめたい。今回測ったのは、1件ずつ渡した時の待ち時間である。
16GBのGPUに、丸ごとは載らなかった
NVIDIA側では、最初からすんなり、とはいかなかった。Clef-flashの公開ファイルはBF16で約19GB。16GBのVRAMへ、モデル全体をそのまま載せる構成では足りない。
そこで、計算の大きな部分を担う言語処理の32層をGPUへ。入口の埋め込み、画像を扱う部分、出口の重み、そして判断を返す「頭」はCPU側に分けた。これは今回組んだ自前の構成で、公式の推奨手順ではない。
BF16の測定では、ほかのGPUサービスを短時間止め、GPUをこの実験だけに使った。16件を3周、計48回の推論。その保存集計は次のとおりだ。
1件の中央値：114.1ミリ秒。中央の半分は113.4〜115.7ミリ秒。
言語処理側：中央値77.3ミリ秒。CPUでの埋め込みとGPUへの転送を含む。
CPUへ戻す処理と判断の頭：中央値36.7ミリ秒。総時間に含む。
読み込み直後のGPU割り当て：12.9GiB。計算中の最大値ではない。
担当の第一候補：作者案と16/16一致。Macの確率との差は最大0.7ポイント。
48回といっても、48種類の問い合わせではない。同じ16件を3回ずつ流したものだ。また、処理の内訳の中央値を足した値が、総時間の中央値と必ず一致するわけでもない。
作者作成の架空16入力。Macは16行から再計算、NVIDIAは16件×3周の保存集計。配置・GPU使用状況・計時範囲が異なる。GiBは読み込み時の割り当てで、最大値ではない。
動画では、この数字から仕分けのレースを描き直している。同時に2台を走らせた操作録画ではない。NVIDIAの16件ぶんは中央値×16の約1.8秒という見積もり、Macは各件の実測合計の約9.6秒。動く図で感覚をつかみ、条件は図と数値で読み直してほしい。
保存測定から再構成したLAB動画です。同時に2台を走らせた操作録画ではありません。担当案は、架空の問い合わせと一緒に制作側のAIが作成したもので、独立した人間の正解ではありません。
小さくした構成では、第一候補が同じでも数字が揺れた
別の測定では、ほかのGPUサービスを動かしたまま、言語処理の層を4bit（NF4）にした。この構成の保存集計は、中央値148.3ミリ秒、読み込み直後のGPU割り当て3.6GiBだった。
BF16は専有、4bitはほかのサービスと共存。だから「同じ条件で4bitにすると何秒変わる」という比較ではない。それでも、より小さな割り当てで動いた構成があったことは、手元の使い方を考える材料になる。
注目したいのは、担当の第一候補が16件とも同じでも、確率は同じではなかったことだ。在庫が減らないというT10では、技術の値がMacのBF16で73.5%、NVIDIAの4bitで47.1%。後者では営業も41.5%まで接近した。
「一番高い候補を選ぶ」なら、どちらも技術。しかし「候補が拮抗したら人へ戻す」運用なら、扱いが変わりうる。これは機械と構成の両方が違う比較であり、差のすべてを量子化だけのせいにはできない。軽い構成でも担当は同じだった、と安心して終わらず、周囲の判断基準も確かめたい。
T10の丸め済みモデル出力。正答率ではない。機材・配置も違い、量子化だけの因果比較ではない。棒の幅だけ合計100%へ正規化した。
深刻さの第一候補が入れ替わった例もあった。ただ、こちらには正解ラベルがないので、「精度が落ちた」とは採点できない。出力が変わったことと、現実に間違えたことは分けて読む必要がある。
Macの最適化は、やれば必ず速くなるわけではない
Macでも、複数件をまとめる処理や、Apple向けのMLXを使った構成を試している。保存記録では、4・8・16件をまとめた処理時間を件数で割ると、1件換算で約1.6秒。これはまとめ処理の効率であって、各問い合わせが1.6秒で返ってくるという意味ではない。たとえば16件のまとまり全体は約26.5秒。期待したほど処理は短くならなかった。
土台をMLXへ移した同一プロセス内の交互比較では、保存集計は公式構成1,456.2ミリ秒、MLXとPyTorchを組み合わせた構成1,128.9ミリ秒。約22.5%短くなった。ただし、冒頭の静かな時の0.6秒とは別の実行で、これを「最適化したら0.6秒より遅くなった」と読むのも違う。
今回のMacでは高速な計算経路を使えず、別の実装へ切り替わる警告も出た。一方、NVIDIAで高速経路を無効にした測定でも中央値151.3ミリ秒。Macとの差を、それだけで説明できるわけではない。速さの内訳は、まだ調べる余地がある。
次は「自分たちの受信箱でも選べるか」
1秒かからず、担当候補が返ってきた。問い合わせの前処理を手元に置ける可能性は、十分にわくわくする。一方、今あるのは判断の部品であって、受信から返信まで任せられる窓口アプリではない。
次に試すなら、担当者が先に行き先を付けた、別の問い合わせを使いたい。用件が二つある文、表記の崩れ、情報不足、長文。最初は送信や返金へつなげず、担当候補のタグを付け、実際の判断と照らすところから始める。その失敗を見るほうが、同じ16件を繰り返して「全件一致」を増やすより役に立つ。
また、ローカル実行は、問い合わせを外部の推論サービスに送らない構成を選べるという利点だ。端末、アクセス権、外向き通信、保存ログ、モデル更新の管理まで、自動で片づくわけではない。
AIの使い道は、上手な返事を書かせることだけではない。誰に渡すべきかを先に選び、人が仕事に入るまでの段取りを整える。今回の実験は、その小さな判断係を、自分たちの機械で持てるかもしれないと感じさせる結果だった。
測定の読み方
測定日：2026年10月3日。既存のEDIFORCE LAB記録を記事用に再集計・照合した。新たな推論を再実行した報告ではない。
入力：架空の日本語16件、質問は急ぎ・担当・深刻さ。問い合わせと担当案は同じ制作AIが作成。独立した正解評価ではない。
共通：ウォームアップ後、1件ずつ。読み込み時間と画面表示時間を除く。
Mac：M4 Max・128GB、PyTorch BF16・MPS。16件の個別時間から中央値と合計を再計算した。入力バッチの組み立てを含む。
NVIDIA：RTX 4070 Ti SUPER 16GB。言語32層をGPU、判断の頭などをCPU。各16件×3周。保存されている中央値・四分位は計測スクリプトの集計値で、48回の個別時間列は保存されていないため、中央値を独立に再計算はしていない。16件の出力と一致数は再集計した。
GPUメモリは読み込み直後の割り当て。最大使用量や、ほかの機種の最低要件を示す値ではない。
Cloudflareの公式速度、JevのAPI往復時間とは、入力・環境・計時範囲が違うため優劣を付けていない。
公開モデルの仕様はClef-flashのモデルカードとCloudflareの発表を参照。実測の数値は、EDIFORCE LABの保存JSONと計測スクリプトに基づく。
