先日このブログで「町工場AIにローカルLLMは要らない」という記事を書いた。GPU搭載PCに45〜60万円を投じるより、クラウドAPIを従量課金で使うほうが、コストでも精度でも合理的だという内容だ。
その2週間後、Microsoftが真正面から反対のことを言い出した。
正確には「ローカルで動かせ」と言ったわけではない。だが同社が打ち出した方針は、私が記事の中で結論の根拠にした前提のひとつを、はっきりと崩しにきている。自分の書いたものが外部の事実によって揺さぶられたとき、黙って放置するのは書き手として誠実ではないと思うので、ここで検証しておく。
先に結論を書いておく。結論そのものは変わらない。しかし理由は入れ替わり、旧記事の設計判断にはひとつ明確な誤りがあった。
Microsoftが出してきたもの
Microsoft AIのCEO、Mustafa Suleyman氏が2026年7月末に公開した「Optimizing the frontier performance curve」という文書がある。同社のFY26 Q4決算発表と同じタイミングで出されたものだ。
主張は明快で、最先端の汎用大型モデルは実務のほとんどの仕事には過剰だ、というものである。同社はこの四半期に画像・音声・文字起こし・コーディング・セキュリティにまたがる十数個の新モデルを投入し、品質を保ったまま消費トークンを大幅に削減、GPUコストを5〜9割削減したケースもあると報告している。
具体例として挙がっているものを拾うと、こうなる。
- MAI-Code-1-Flash — GitHubと共同開発。6月からVS Codeで稼働しており、GPT-5.4 MiniやClaude Haiku 4.5と比較して、コード採用率が10%高く、トークン消費の中央値は10%低い
- 同じチェックポイントをExcelのRL環境で追加訓練したところ、頻出タスクではGPT-5.6に匹敵する性能に到達。しかも最新の高価なアクセラレータを必要とせず、A100やH100で提供できるサイズに収まっている
- MAI-Voice-2-Flash — Dynamics 365 Contact Centerで稼働。T-MobileやEasyJetのコールセンターで使われている
- MAI-Cyber-1-Flash — CyberGymベンチマークで95.95%を記録し、競合を12ポイント上回った。従来はGPT-5.4・GPT-5.4 mini・GPT-5.3 Codexを組み合わせていた構成を置き換え、コストは半分になったとされる
そしてSuleyman氏は、競争の焦点はモデルそのものから、安価な専用モデル群にクエリを振り分けるオーケストレーション層へ移りつつある、と述べている。
旧記事の根拠は、どこが崩れたか
私が「ローカルLLMは要らない」と書いたときの根拠は、二本柱だった。
ひとつはコスト。GPU搭載PCの初期投資45〜60万円に対し、Claude APIなら加工相談1回あたり20〜57円。1日5回の利用で月2,500円程度、投資回収に16年かかる計算になり、その頃にはGPUの世代は2つ変わっている、と書いた。
もうひとつが精度だ。加工相談を成立させるには「設備検索 → 工具検索 → 実績検索 → 条件計算 → 能力照合 → 提案書作成」というツールの連鎖を、AIが自律的に正しい順番と引数で回す必要がある。手元で気軽に動く7B〜14Bクラスのモデルはこの多段呼び出しで頻繁に脱線する。引数を間違え、ツールを呼ばずに数値をでっち上げ、途中で連鎖が止まる。切削条件という、失敗すれば工具が折れ人が怪我をする数値を扱う用途では致命的だ——そう書いた。
崩れたのは、後者である。
MAI-Cyber-1-Flashは、汎用大型モデルの組み合わせを、小型の特化モデル単体で置き換えて上回っている。「小さいモデルは複雑な仕事ができない」という私の前提は、少なくとも十分に特化させた場合には成り立たないことが実例で示された。ここは素直に認めるべきところだ。
それでも結論が変わらない理由
ではローカルLLMを買うべきなのか。ここは変わらない。要らない。
理由は身も蓋もなく単純で、Microsoftの言う使い分けは、すべてクラウドの内側で起きている話だからだ。90%を軽量モデル、10%を高性能モデルに振り分けるという構図は、ローカル対クラウドの対立軸とは何の関係もない。どちらもデータセンターで動いている。
そしてもうひとつ、見落としてはいけない一文がある。Excel環境で追加訓練したモデルについて「A100やH100で提供できる程度に小さい」と書かれている点だ。これは裏を返せば、A100が下限だという意味である。A100は数百万円クラスのデータセンター用GPUであって、町工場の事務所の机の下に置くRTX 4090ではない。「小型特化モデル」と聞いて手元のGPUを想像すると、桁をひとつ読み違える。
つまりFlash戦略が示しているのは「特化した小型モデルは強い」であって、「その小型モデルを自分で持て」ではない。小型特化モデルの入手経路は、GPUの購入ではなく、クラウド上のルーティングである。
むしろ間違っていたのは、私の設計のほうだった
ここからが、この記事を書いた本当の理由だ。
旧記事で私は「1回57円、キャッシュを効かせれば20〜30円。だから十分安い」と書いた。この試算自体に計算間違いはない。だが Flash戦略の視点で自分の設計図を見直すと、もっと手前に問題があったことに気づく。
全部のリクエストを同じモデルに投げていた。
工場からの相談を並べてみれば、明らかに難易度は均一ではない。
- 「SUS304の推奨切削速度は」——DBを1回引くだけ
- 「mm/revをmm/minに直して」——四則演算
- 「この材質でφ3のドリル、うちの機械で通るか」——設備スペックとの照合
- 「この形状、うちの3軸で加工できるか。無理ならどこを変えれば通るか」——多段のツール連鎖と判断
最後の1問と、最初の3問を、同じモデルに同じ料金で投げる理由はどこにもない。前者はHaiku級で十分どころか、そのほうが速い。私は「安いモデルは精度が足りない」という一般論を、タスクの難易度を仕分けないままシステム全体に適用していた。
Manufacturing MCP Serverの構成は、いま三層（ドメイン不変条件 / LLMオペレータ / UI）で組んでいる。ここに必要なのは四つ目の層ではなく、LLMオペレータ層の内側に置くモデル選択の関数だ。相談の種類を分類し、決定的な計算はそもそもLLMに渡さずPythonへ、単純な検索は軽量モデルへ、多段判断のみ上位モデルへ振る。Suleyman氏の言う「競争はオーケストレーションに移る」とは、まさにこの層のことである。
旧記事の結論は正しかった。しかし、そこで提示した実装は最適ではなかった。
では、特化モデルを自前で持つには何が要るのか
最後に、ひとつ先の話をしておきたい。
将来、加工に特化した小型モデルが手の届く価格で動くようになったとして、それを自分の工場向けに仕上げるには何が必要か。Microsoftの事例が、そのまま答えになっている。同社は既存のチェックポイントをExcel専用のRL環境の中で追加訓練することで、頻出タスクの性能を引き上げた。
RL環境をつくるということは、「正解が機械的に判定できる問題集」を用意するということだ。この条件を、切削条件に置き換えて考えてみてほしい。
- この材質・この工具・この機械で、送りいくらが正解か
- その正解は、誰がどうやって判定するのか
- 過去の加工実績は、どこに、どんな形式で残っているのか
ここで、旧記事で私が書いたもうひとつの指摘に戻ってくる。町工場AIの本当のボトルネックは技術ではなく、データが存在しないことだ。 熟練者の頭の中にしかない条件は、RL環境の教師にはならない。
だから、いま投資すべきものははっきりしている。GPUではない。作業指示書を出力し、加工後に結果欄を埋めて戻すと自動で記録が貯まる導線のほうだ。記録がシステム利用の副産物として蓄積される仕組みさえ回り始めれば、その資産は将来どんなモデルが来ても効く。逆にそれがなければ、どれだけ良いモデルが安くなっても、空のデータベースを検索することになる。
まとめ
- Microsoftの小型特化モデル戦略は、「小さいモデルは複雑なタスクをこなせない」という私の前提を実例で崩した
- しかし、その使い分けはクラウド内部の話であり、ローカルLLMを買う理由にはならない。提供に必要なハードの下限はA100クラスであって、手元のゲーミングGPUではない
- 一方で、全リクエストを同一モデルに投げていた旧記事の設計は誤りだった。難易度に応じたモデル選択層を入れる
- 特化モデルを自前で持つ日が来るとしても、その前提は検証可能な実績データである。投資すべきはGPUではなく、記録が自然に貯まる業務導線
結論を守るために事実を無視するのは、技術者の仕事ではない。前提が変わったら検算する。今回、結論は生き残ったが、設計はひとつ書き換えることになった。
関連記事: 町工場AIにローカルLLMは要らない――コスト試算で分かった現実
コメント