クラウドに出せない現場で、AIを動かすために

｜ 小野克樹

AILLMエッジAIオンプレミスセキュリティファインチューニング業務AIローカルLLM

私たちは、750B規模のpost-trainingに関わってきたチームです。最先端のフロンティアモデルに近い規模で、データを設計し、学習を回し、評価する一連の作業を経験してきました。

そのうえで、最初に正直に言っておきます。

多くの業務現場で本当に必要になるのは、巨大なクラウドAIではなく、用途を絞った小さなモデルを、自分たちの環境で安全に動かせる形に整えたものです。

フロンティアモデルを超える話ではない

誤解されやすいので、最初にはっきりさせておきます。

小さなモデルをチューニングしたからといって、GPT-5級のような最先端モデルを総合性能で超えられる、という話ではありません。幅広い知識、汎用的な推論、多言語対応、複雑な道具使いといった面では、フロンティアモデルには大きな強みがあります。

私たちはその強みを近くで見てきたからこそ、「正面から勝ちにいく」とは言いません。

大切なのは、用途を絞ることです。

  • 社内マニュアルに沿って回答する

  • 決まった形式の問い合わせを分類する

  • 現場の記録を要約する

  • 定型文を作る

  • 専門領域の表現に揃える

  • インターネットのない環境で補助的に動く

こうした目的なら、必ずしも最大級のAIは要りません。むしろ、用途を絞った小さなモデルを、手元の環境に合わせて調整した方が現実的なことが多くあります。

なぜクラウドではなく手元で動かすのか

エッジ環境とは、クラウドではなく、手元の端末や社内サーバー、現場の機器に近い場所で処理を行う環境のことです。LLMをエッジ・オンプレミスで動かす利点は、大きく三つあります。

データを外に出しにくくできる。業務文書には、顧客情報、社内ノウハウ、契約情報、医療・福祉に関する情報など、外部サービスに送りにくい内容が含まれます。ローカルで動かせれば、処理の中心を自分たちの管理下に置きやすくなります。

ネットワークに依存しにくい。クラウドAIはインターネット接続が前提です。通信が遅い、途切れる、外部接続が制限されている――そうした環境では使いにくい場面があります。

応答速度やコストを管理しやすい。クラウドは利用量に応じて費用が増え、外部サービスの仕様変更にも影響を受けます。ローカル運用は初期設計が必要ですが、コストや速度を読みやすい構成にできます。

「どこを学習させるか」は、想像よりずっと大きく違う

ここが、私たちが大規模post-trainingで得た知見を、現場のエッジLLMチューニングに直接転用している部分です。

エッジ向けのチューニングでは、計算資源が限られています。GPUメモリ、学習時間、消費電力、応答速度、運用コスト――どれも制約になります。だからこそ、モデル全体をむやみに学習させるのではなく、どこを調整して、どこは触らないかを決めることが、効率と性能の両方を握ります。

私たちはこの問いを、勘ではなく実証的に詰めてきました。

近年の言語モデルで使われているハイブリッドアーキテクチャ（Gated Delta Network層と Attention層の組み合わせ）について、Qwen3.5-0.8Bを対象に、7パターンの凍結条件 × 2タスク × 6シード、合計84実験を行いました。主な結果はこうです。

  • GDN層18層（全パラメータの51.6%）を凍結したまま学習しても、Attention層6層（14.6%）を凍結した場合と、性能が統計的に区別できない

  • 凍結する場所を選ぶと、フルのSFTより知識QAで性能が上がるケースがある（正則化効果と考えられる）

  • 一方で、Attentionのprojection層は知識適応にとって不釣り合いに重要で、ここを凍結すると影響が大きい

これは、学習コストを大きく下げながら性能を保つための、具体的な設計指針になります。

別の検証では、43モデル × 15アーキテクチャ系列にわたって、内部の残差ストリームの挙動を測定しました。モデルによってその挙動が500倍以上違うこと、そしてその違いと「層を削っても壊れにくいか」が無相関であることなどが分かっています。言い換えると、「どこを削れて、どこを触ってはいけないか」はモデルごとに違うので、汎用の答えはない、ということです。

何が言いたいか。

エッジLLMで「小さく作る」「絞って学習する」というのは、響きとしては素朴に聞こえますが、実際はモデルの構造を見て、学習対象を実証的に切り分ける作業です。私たちは、そこを自分たちの検証で詰めながら、現場のチューニング方針に落とし込んでいます。

両方の検証結果は preprint として記事末尾にリンクを置いています。

重要なのは「何をさせないか」でもある

業務用AIでは、「何ができるか」と同じくらい、「何をしないか」が大事になります。

  • わからないことを勝手に断言しない

  • 個人情報を不用意に出さない

  • 社内ルールにない回答をしない

  • ユーザーに誤解を与える表現を避ける

  • 必要なときは人間に確認を促す

万能性ではなく、こうした安定したふるまいの方が、現場では重要なことが多くあります。「何でも答えられるAI」ではなく、決められた範囲で、安定して、余計なことをしないAI。これはセキュリティやガバナンスの観点でも本質的です。

実務では、いきなり大きく作らない

業務用AI導入の失敗パターンの典型は、最初から大きな完成形を作ろうとすることです。大きなモデルに大量のデータを与え、長く学習を回し、最後に評価する――予算も時間もかかり、結果が悪かったときに何が悪かったのかも分かりにくくなります。

エッジAI・ローカルLLMでは、小さく始める方が向いています。

  1. 使いたい場面を絞る

  2. 小さなデータで試す

  3. ローカルで動くサイズのモデルを選ぶ

  4. 回答の質、速度、メモリ使用量、セキュリティ要件を確認する

  5. 必要なら、絞った範囲でチューニングする

この段階分けが、「本当にローカルで動かす意味があるのか」「どの程度の性能で十分なのか」「どこにリソースを使うべきか」を見えやすくします。

EqualFrontiersの立ち位置

私たちは、大規模なpost-trainingに関わる中で、フロンティアモデルの強さも限界も近くで見てきました。そのうえで、現場の多くの問題は最大級のAIを呼んでくることでは解けず、用途を絞ったモデルを、現場の制約に合わせて調整することで解ける、という結論に至っています。

クラウドに出しにくいデータがある。ネットワークに頼れない環境がある。大きなGPUを常時使えるわけではない。それでも、現場にはAIで軽くできる作業がある。

そうした場面で、用途を絞ったモデルを選び、小さく検証し、必要な範囲でチューニングする。これがEqualFrontiersの考える現実的なLLM活用です。

具体的には、以下のような相談に対応しています。

  • 社内文書を外部に出さずにAI活用したい

  • オンプレ・ローカル環境でLLMを動かしたい

  • 小さなモデルを業務用に調整したい

  • SFT・LoRA・凍結戦略でどこまでできるか試したい

  • クラウドAIとローカルAIの使い分けを設計したい

  • セキュリティ要件を踏まえたAI導入を検討したい

おわりに

LLM活用の選択肢は、クラウドの巨大AIだけではありません。

社外に出せないデータを扱う現場、ネットワークに頼れない環境、セキュリティ要件の厳しい業務では、手元で動くAIが本命になることがあります。小さなモデルに限界はあります。それでも、用途を絞れば、必要十分なAIを手元の環境で動かせる可能性があります。

大切なのは、フロンティアモデルを超えることではありません。自分たちのデータを守りながら、必要な場所で、必要な仕事を、安定してこなせるAIを作ること。

私たちは、大規模なpost-trainingで得た知見を、その「小さなAI」の設計に注ぎ込みます。

参考：私たちの検証

‹ ブログ一覧へ