町工場AIにローカルLLMは要らない ― コスト試算で分かった現実

「機密データがあるからローカルLLM一択」「Ollamaなら無料で運用できる」――町工場へのAI導入を調べると、こうした記事ばかりが目につきます。

しかし「町工場に加工相談AIを入れるならどちらか」を真面目に試算したところ、ほとんどの町工場ではクラウドAPIの方が安く、しかも賢いという、流行と逆の結論になりました。

この記事では、その計算過程をすべて公開します。

想定するシステム

比較の前提として、次のような「加工相談AI」を想定します。

• 作業者が「SUS304にφ3、深さ15mmの止まり穴を20個あけたい」と質問する
• AIが設備台帳・工具在庫・過去の加工実績・メーカー資料を検索する
• 切削条件をPythonで計算し、設備能力と照合する
• 根拠資料付きの加工提案書を返す

つまり単なるチャットボットではなく、社内データを検索し、ツールを呼び出す「エージェント型」です。この前提が、後で効いてきます。

初期費用の比較

ローカルLLM構成では、実用レベルのモデル(32Bクラス以上)を動かすために、VRAM 24GB級のGPUが事実上必須です。

クラウドAPI構成は、手持ちの普通のPCで動きます。GPU不要。初期費用は実質ゼロです。

この時点で45万円以上の差がつきますが、「ローカルは初期費用だけ、APIは使うほど課金される」という反論があるはずです。では、その課金額を計算してみます。

ランニングコストの試算

1回の加工相談で消費するトークン

エージェント型の相談1回は、内部で複数回のAPI呼び出しが発生します。システム指示、ツール定義、検索結果の受け渡しを含めて、実測に近い水準で見積もると次の通りです。

• 入力トークン:累計 約10万トークン(ツール呼び出し10回分の往復を含む)
• 出力トークン:累計 約5,000トークン

Claude Sonnet(標準価格 入力$3/出力$15 per 100万トークン)で計算すると、

入力: 100,000 × $3 ÷ 1,000,000 = $0.30
出力:   5,000 × $15 ÷ 1,000,000 = $0.075
合計: 約$0.38 ≒ 57円(1ドル150円換算)

1回の本格的な加工相談で約57円です。しかもこれは悲観側の数字で、実際にはプロンプトキャッシュ(同じシステム指示や資料を再送する分は9割引)が効くため、運用では1回20〜30円程度まで下がります。

月額に直すと

従業員数人の町工場で、加工相談が1日50回発生することはまずありません。現実的な利用(1日5〜20回)なら、月2,500円〜1万円です。

損益分岐点

初期費用差50万円をAPIの月額で割ると、

• 1日5回利用:50万円 ÷ 2,500円/月 = 回収に約16年
• 1日20回利用:50万円 ÷ 1万円/月 = 回収に約4年

4年後にはGPUの世代が2つ変わり、モデルも様変わりしています。しかもこの計算は、ローカル側の電気代(GPU常時稼働で月2,000〜4,000円)、故障リスク、保守の人件費をゼロと置いた、ローカルに極めて有利な条件です。それでもペイしません。

金額よりも深刻な「精度」の問題

コスト以上に決定的なのが、ツール呼び出しの精度です。

冒頭の加工相談を成立させるには、AIが「設備検索→工具検索→実績検索→条件計算→能力照合→提案書作成」というツールの連鎖を、自律的に正しい順番・正しい引数で実行する必要があります。

ローカルで手軽に動く7B〜14Bクラスのモデルは、この多段ツール呼び出しで頻繁に脱線します。引数を間違える、ツールを呼ばずに数値をでっち上げる、途中で連鎖が止まる。切削条件という安全に関わる数値を扱う用途で、これは致命的です。まともに動く32B以上を狙うから、冒頭のGPU投資が必要になるわけです。

つまりローカルLLMは「安くて使い物にならないか、高くてようやく使えるか」の二択になりがちです。クラウドAPIなら、最初からフロンティアモデルの精度で10ステップのツール連鎖が安定して回ります。

「データを外に出せない」への現実的な答え

それでもローカルを選ぶ理由として残るのが機密性です。ここは丁寧に切り分ける必要があります。

まず、APIに送信されるのは「相談文と、検索でヒットした資料の断片」だけです。図面ファイルの現物や、データベース全体が送られるわけではありません。設計次第で送信範囲は制御できます。

その上で、防衛・自動車系など契約上データの外部送信自体が禁止されている案件を扱う工場だけは、ローカルLLMが正当化されます。逆に言えば、それ以外の「なんとなく不安」レベルであれば、送信内容の設計と説明で解決する方が、50万円のGPUを買うより合理的です。

私自身の方針も、標準はクラウドAPI構成、契約上の制約がある顧客にだけローカル構成をプレミアム対応として提供する、という二段構えに落ち着きました。

結論:町工場AIの推奨構成

試算の結果、私が推奨する構成はこうなりました。

チャット画面(Web UI)
  ↓
Claude API(クラウド)
  ↓ ツール呼び出し
社内データ層
  ├─ 文書・ノウハウ:Markdownフォルダ
  ├─ 設備台帳・加工実績:SQLite
  └─ 切削条件計算:Python(決定論的計算)

GPUなし、月数千円、そして計算はLLMに暗算させずPythonに任せる。地味ですが、一人で保守できて、現場で信用される構成はこれだと考えています。

ローカルLLMは技術としては面白いし、私も検証は続けます。ただ「町工場のAI化」という目的に対しては、2026年時点では手段が目的化した選択です。まず電卓を叩いてから決めましょう。

次回は、この構成の第1段階「Markdownフォルダ+Claude Desktopで加工ノウハウ検索を動かす」を、実際のスクリーンショット付きで紹介する予定です。