昔、大きな会社に出向していたとき、社内で使う道具はほとんど何も持ち込めませんでした。
便利なメモアプリも、速い翻訳サービスも、全部だめ。理由は「情報が外に出るから」の一点です。当時は正直、少し窮屈だと思っていました。こんなに便利なのに、なぜ使わせてくれないんだ、と。
いまになって、あの窮屈さの正体が分かる気がします。あれは意地悪ではなく、外に出た瞬間に、私が責任が取れなくなるものを、線の内側に留めていたんです。
先に一行だけ置きます。ローカルLLMとは、AIのモデルを外部のクラウドに預けず、自社が管理する環境の中に置いて動かす構成のことです。オンプレミスのAI、とも呼ばれます。基幹システムを自前で持つのと、発想は同じです。
題材は、ホテルの滞在客からの問い合わせに答えるAIです。タオルはどこか、荷物を送りたい、近くの観光地を知りたい。1日に何百件も来る、短い問い合わせの束です。
前置きはさておき、本題に入ります。
今日は、この仕組みを作るときにクラウドから自社へ持ってこようとして、持ってこられなかった話をしていこうと思います。結論から言うと、止めたのは性能ではありませんでした。見積書の一行です。
① 教科書どおりに、クラウドのAIで作る
最初は、教科書どおりに作りました。
→ 対話AIのサブスクリプションを契約する
→ 問い合わせをAPIに投げる
→ 返ってきた文章をそのまま返す
→ 難しいものだけ人に回す
きれいに動きました。 精度も速度も十分で、作るのに時間もかかりません。
社内データの扱いも、教科書どおりに手当てしました。一般向けの契約では入力が学習に使われる場合があるので、法人向けの契約に切り替える。これで「入力は学習に使わない」が契約で担保されます。
ここまでは、教科書どおりです。
このときの構成を数字で置いておきます。問い合わせは1日あたり数百件、応答は2秒以内、対応言語は3つ。 精度も速度も、要件を満たしていました。
② そのとおりに進めて、規約で詰まる
ところが、詰まったのは性能でも精度でもありませんでした。規約です。
使っていた対話AIのサブスクリプションが、契約上、1アカウントの共有を禁じていることが分かりました。サーバー経由で複数人が使う構成を組むと、それが「認証トークンの共有」に当たるのではないか。あるいは「人格的な操作代行」とみなされるのではないか。
規約を読んでも、どちらとも読めます。
黒とは書いていない。白とも書いていない。判断がつかないまま、構成を変えるかどうかの議論になりました。
ここで気づきます。性能の話は、一度も出ていません。
法人契約で解決したのは「入力を学習に使われない」の一点だけでした。処理が向こうの環境で走ること自体は、何も変わっていません。 その事実が、規約という形で戻ってきただけです。
代替として、重みが公開されている別系統のモデルが候補に挙がりました。これなら自社で動かせます。ただ、そのモデルは中国発で、情報の扱いと倫理観の面で懸念が出ました。ここでも止まります。
では、自社の中で動かせばいい。 記事の前半に書いたとおりの結論です。そこで、見積もりを取りました。
③ そして、見積書を見て止まる
エンジニアが出してきた見積もりは、こういう構造でした。
→ ローカルLLMを動かすには、GPUを積んだサーバーが要る
→ その費用は、使っても使わなくても毎月出ていく固定費になる
→ 対してAPIは、使った分だけの従量課金で済む
金額そのものは伏せますが、構造だけで判断がつきました。
| 項目 | 自社で持つ | 借りる |
|---|---|---|
| 費用の出方 | 毎月固定 | 使った分だけ |
| 使わない月 | 同額かかる | ほぼゼロ |
| 必要な機材 | GPU搭載サーバー | 不要 |
| 立ち上げまで | 数週間 | 即日 |
片方は毎月確実に出ていき、もう片方は使わなければほとんど出ていきません。
この差が決定的でした。
両者は、そもそも比較の土俵が違います。 単価を並べても意味がない。並べるべきは、自社の利用量が、両者の入れ替わる点のどちら側にあるかです。
サーバーの費用は、基本料と使った分に分かれます。小さい組織では基本料が重すぎて、大きくなるほどローカルが有利になる。 つまり、分岐点が実在します。
そして私たちは、その手前に立っていました。
「大企業ほどローカルに行き着く」というのは、思想の話でも意識の高さの話でもありません。単に、分岐点の向こう側に立っている、というだけの話でした。
④ 原因は「所有か、借りるか」を全か無かで考えていたこと
止まった原因を一つに絞ると、これでした。
私たちは、ローカルにするかしないかを、全部か全部でないかで考えていました。
問い合わせ対応という仕事を、ひとかたまりの箱として見ていた。だから「この箱を自社に持ってくると、いくらかかるか」という問いになり、答えは「固定費が重すぎる」になった。
けれど、実際の処理は一枚岩ではありません。
→ どの種類の問い合わせか判定する（タオル／配送／観光）
→ その種類に応じた答えを組み立てる
→ 判断がつかないものを人に回す
このうち、社内の機密に触れるのはどこか。 監査で挙動を固定したいのはどこか。提供側の都合で止まると事業が止まるのはどこか。
問いを分解した瞬間に、答えが変わりました。
⑤ 直してみる — 統制権が要る場所だけを、自社に持つ
やったことは3つです。
1. 処理を分解して、統制権の要否を1行ずつ書いた。
「この処理は、外に出た瞬間に自分で責任が取れなくなるか」を基準にしました。全部に○が付くわけではありません。観光地の紹介文を作るのに、統制権は要りません。
2. 振り分けだけを、自社の小型モデルに移した。
問い合わせがどの種類かを判定する部分だけを切り出し、専用の小さなモデルを作りました。容量は100MB程度。ルーティングの精度は95%から97%まで上がりました。 大きなモデルを借りて振り分けさせていたときより、速くて、安くて、外に出ません。
3. 残りは借りたままにした。
答えの文章を組み立てる部分は、クラウドのAPIのままです。ここを自社に持つ理由が無かったからです。
そして、この構成にした瞬間に、固定費の問題が消えました。 100MBのモデルはGPUを積んだサーバーを必要としません。
→ 所有すべき場所だけを所有する
→ 分岐点は、処理を分解すると手前に動く
→ 動かせる線だった
⑥ あとで知った — この作り方には、名前がついていた
素朴な対処のつもりでしたが、調べると同じものを指す言葉は、すでにありました。
1つ目。用途を絞った小さなモデルには名前があります。小規模言語モデル（SLM／Small Language Model）です。「小さい」が指しているのはパラメータの数で、少ないぶん速く、動かすのに要る資源も小さい。特定の仕事をこなすために作られる、と説明されています。
規模感も具体的です。Microsoft の Phi-3 系列は、Phi-3-mini が38億、Phi-3-small が70億、Phi-3-medium が140億パラメータという構成になっています。「小さい」と呼ばれる領域が、すでにこれだけ確立しているということです。
2つ目。難しさに応じてモデルを振り分ける組み方も、既に語られていました。問い合わせを受け取って評価し、適切なモデルへ振り分ける役割を置く。単純な依頼は小さなモデルが処理し、複雑なものは大きなモデルに回す。難易度・リスク・遅延・プライバシー・コストを見て自動的に選ぶ、と説明されています。
「プライバシー」が選択の基準として並んでいるのが要点です。 私が「統制権が要る処理だけ自社に置く」と呼んでいたものは、この振り分けの一項目でした。
3つ目。所有と賃借の分岐点は、昔からある損益分岐の話でした。固定費と変動費が入れ替わる点を探すという、それだけのことです。AIに限った新しい問題ではありません。
新しい理屈は、ひとつも要りませんでした。
⑦ 何が変わったか
判断の順番が、逆になりました。
“`
前：ローカルにするか？ → 見積もりを取る → 高いのでやめる
後：どの処理に統制権が要るか？ → その部分だけ見積もる → 持てる
“`
「ローカルLLMを導入するか」は、そもそも問いの立て方が間違っていました。 導入するのは製品ではなく、処理ごとの判断だからです。
⑧ 現場で使うなら、この2枚
表1：統制権の棚卸し（処理を1行ずつ書く）
| 処理 | 機密に触れるか | 挙動を固定したいか | 止まると事業が止まるか | 判定 |
|---|---|---|---|---|
| 問い合わせの種類判定 | 入力に個人情報 | 監査対象 | 入口なので止まる | 自社 |
| 回答文の生成 | 触れない | 不要 | 代替可能 | 借りる |
| 観光情報の紹介 | 触れない | 不要 | 代替可能 | 借りる |
| 決済に関わる確認 | 触れる | 固定したい | 止まる | 自社 |
3列とも「いいえ」なら、借りてください。 1つでも「はい」が付いた処理だけを、自社に持つ候補にします。全部に○を付けると、固定費で止まります。
表2：分岐点を手前に動かす手
| 手 | 何をするか | 効き方 |
|---|---|---|
| 処理を分解する | 統制権の要否を処理ごとに判定 | 最も効く。箱のままだと必ず高い |
| モデルを小さくする | 用途を絞ってSLMにする | GPUが不要になる規模まで落ちる |
| ~~基本料を分ける~~ | ~~複数社でサーバーを共有~~ | 見送った。理由は次節 |
補：判断に使った数字
| 項目 | 値 |
|---|---|
| 検査が通る回数 | 1日あたり数千回 |
| 振り分けモデルの容量 | 100MB |
| ルーティング精度 | 95%から97% |
| 常駐に使えるメモリ | 16GB中の数百MB |
| 1件あたりの判定 | 数十ミリ秒 |
| 対応言語 | 3件 |
| 応答の目標 | 2秒以内 |
ところで、この7行のうち5行は、処理を分解しなければ測れない数字です。箱のまま見積もると、1行目しか出てきません。
⑨ この考え方が効き続ける理由
モデルの値段は、これからも下がります。それでも、この判断は消えません。 値段の問題ではないからです。
→ AIが基幹に食い込む → 判断そのものを担うようになる
→ 事故が起きたとき、頭を下げるのは貸した側ではなく、組み込んだ側
→ 責任を持つ側が、判断の土台を所有していない → いずれ耐えられなくなる
賢さは借りられます。責任は借りられません。
大企業がローカルへ向かうのは、けちだからでも時代遅れだからでもありません。責任を持つ主体は、いずれ土台を所有したくなるという力学です。
ただし、正直に書いておきます。所有した瞬間に、運用の重さがまるごと自分に乗ります。
この記事を書いている途中で、社内の判断が動きました。サーバーを共有して基本料を割る案は、見送りになっています。
「ローカルLLMの運用における課題として、同時接続時の速度低下が挙げられました。特にMac環境ではNVIDIA CUDAのような最適化された計算資源が利用できないため、性能面で不利である現状が確認されました。」
「本格的なシェアホスティング事業を展開するには、接続数やアカウント管理、ルーティングなどの検証に多大なコストと手間がかかるため、スモールスタートは難しいとの認識が共有されました。」
「基本料を割れば手が届く」は、割る側の運用コストを数えていませんでした。 接続数の制御、アカウントの管理、どのモデルへ流すかの振り分け。共有するということは、その全部を自分が持つということです。
同じ日に、仮想マシンからの撤退も決まっています。当初はそこでローカルLLMを動かす想定でしたが、メリットが薄れたという判断でした。
一方で、明るい材料も同じ場で共有されています。小規模ながら高性能なモデルが出てきており、自社でのホスティングは現実的になりつつある、という見立てです。
分岐点は動きます。ただし、動かす方向は「共有して割る」ではなく「小さくして要らなくする」でした。
だから、全部を持たない。持つべき場所を決める。 そこだけが、今日の話です。
関連して、ファインチューニングで用途を絞ったモデルを作る話と、MCPで社内の文書をAIから引けるようにする話を別に書いています。社内RAGが現場で止まる場所話はすでに公開しています。あわせて読むと、同じ判断が別の場所でも効いていることが分かると思います。
この判断を実際の案件で使う場面については、社内GPT・RAG構築のページに整理しています。
手元に置きたい、といえば、電子で買った本を紙でも買い直したことが何度かあります。
置き場所はもうありません。それでも手元にある状態に、いくらか払っているわけです。
以上です。
Yuki Susai
