コーディングエージェントが当たり前になった今、LLMは開発の必須ツールになりました。けれど、その裏で「顧客データや未公開の設計情報を、外部のクラウドLLMにそのまま投げてしまっていいのか」という不安を抱えている情報システム部門は少なくないはずです。実際、企業の6割超が従業員の無許可AI利用（いわゆる「シャドーAI」）の発生を認めている、あるいは否定できない状態にあるという調査結果もあり、この手の話題は今まさにホットです。
そんな中、2026年7月にNTTドコモビジネスのエンジニアブログが公開した「Local LLM Model as a Service（MaaS）」の取り組みが、社内向けAI基盤の実装例としてよく話題に上っています。
Local LLMを社内に提供！ Local LLM Model as a Serviceとその取り組みについて
この記事を起点に、似たような取り組みをしている他社の事例、実装方法の選択肢、実際の活用方法を整理してみます。「クラウドLLMは便利だけど、機密情報を扱う業務では使いにくい」というジレンマに、各社がどう向き合っているかが見えてきます。
なぜ今「社内に閉じたLLM基盤」が話題なのか
NTTドコモビジネスが挙げている課題意識は、次の3点に整理できます。
- データセキュリティ：機密情報をクラウドへ送信したくない
- 利用実態の把握：社内での使用ログを記録し、統制したい
- 供給の安定性：外部サービスの提供方針の変化（値上げ・仕様変更・提供終了）に業務を依存させたくない
同じ課題意識は、後述するIIJやRevComm、はてなの事例にもほぼ共通して出てきます。つまり「うちだけの特殊事情」ではなく、生成AIを本格的に業務へ組み込もうとした企業がほぼ必ずぶつかる壁だということです。
裏を返せば、「禁止すればいい」という単純な話にはなりません。現場が求めているのは「AIを使えないこと」への我慢ではなく、多くの場合「会社が用意したAIが使いにくい・遅い・機能が古い」ことへの不満です。公式に使える、しかも快適なAI環境を用意することが、結果的に無許可利用を減らす一番の近道になります。ローカルLLM基盤は、その「受け皿」を自社のコントロール下に置くための選択肢のひとつというわけです。
事例1：NTTドコモビジネスの「Local LLM MaaS」
まずは起点となった記事の構成を整理します。3層構成のシンプルなアーキテクチャです。
| 層 | 採用技術 | 役割 |
|---|---|---|
| 推論エンジン | vLLM | 継続的バッチ処理（Continuous Batching）とPagedAttentionにより、GPUメモリの断片化を抑えつつ高速に推論 |
| ゲートウェイ | LiteLLM Proxy | 複数モデルを単一のOpenAI互換APIとして束ねて公開。ユーザー管理と流量制限を実装 |
| UI層 | OpenWebUI | チャット履歴管理とモデル切り替え機能を提供 |
提供モデルは20Bから2.8Tパラメータまでの11のOpen Weightモデル（gpt-oss系、Qwen、Gemma、tsuzumi 2、Kimi-K3など）で、テキストに加えて画像入力にも対応しています。リソース効率化のために4ビット量子化を採用し、VRAM使用量を「4分の1に抑える」運用をしているとのことです。
可観測性の設計も参考になります。OpenTelemetry Collectorでテレメトリを収集し、ログはCloudWatch Logsへ、トレースはLangfuseへとそれぞれ適した先に振り分けています。ログとトレースを一つのツールに寄せずに使い分けている点は、運用が長く続くほど効いてくる設計判断でしょう。
実利用のパターンとして興味深いのは、新モデル追加時に利用が集中する傾向です。GLM-5.2を追加した際は「リクエストの9割以上」がそのモデルに向かったと報告されています。ユーザーは常に最新モデルを試したがる、という生成AI活用でよく見られる挙動が、社内基盤でもそのまま再現されているわけです。今後はログ分析による提供モデルの見直し、クラウド型との性能比較、運用自動化、リソース確保とスケーリングが課題として挙げられています。
事例2〜4：他社も同じ壁にぶつかっている
NTTドコモビジネスの構成は目新しいものではなく、同種の取り組みを公開している企業は他にもあります。並べてみると、課題意識の重なりと、選択の分かれ方の両方が見えてきます。
| 企業 | 課題意識 | 採用構成 | 得られた効果 | 残る課題 |
|---|---|---|---|---|
| NTTドコモビジネス | 情報漏えい防止・利用統制・供給安定性 | vLLM＋LiteLLM Proxy＋OpenWebUI、11モデル、4bit量子化 | 新モデル追加時に利用が集中するなど利用実態を可視化 | ログ分析、性能比較、運用自動化、リソース拡張 |
| IIJ | 従量課金コストの増大・機密情報の外部流出リスク | FastAPI＋複数vLLMサーバ＋埋め込み用llama.cpp、EZO-Gemma-2-9B（FP8）／Llama-3.1-70B日本語版（AWQ INT4） | コーディング支援・要約・ログ解析に活用。応答速度25〜35 Token/sec | INT4量子化モデルの単語ループ発生、VRAM不足（FP8運用に120GB必要）、利用者が一部社員にとどまる |
| RevComm | 複数プロバイダー（Bedrock／Azure OpenAI／Vertex AI）呼び出しの重複実装、コスト把握困難、国内処理制約の適用漏れリスク | LiteLLM Proxyを検討したが、複雑なルーティング要件のため自社実装（FastAPI＋DDD、PostgreSQL JSONBでコスト計測） | ルーティング一元化、コスト内訳の明確化、国内処理要件の確実な適用 | APIキーのセルフサービス発行など運用機能の追加整備が必要 |
| はてな | 複数プロバイダー（Gemini／Claude／GPT-5等）の利用状況が不透明、APIキー管理の複雑化 | **LiteLLM Proxy（OSS版）**をそのまま採用。BigQueryビューでコスト分析 | 利用者急増に対応するため運用をv1（CCoE一元管理）→v2（Internal User機能で各チームに委譲）へ進化 | OSS版にはSSOや監査ログが無く現状は許容、今後MCPゲートウェイ等へ拡張検討 |
この4社を並べて見えてくるのは、「ゲートウェイに何を採用するか」で判断が割れているという点です。はてなはLiteLLM Proxy（OSS版）をそのまま活用してうまく回している一方、RevCommは同じLiteLLM Proxyを検討したうえで「国内処理制約とフォールバック戦略を連動させる」という要件がカスタムハンドラーの範囲を超えたため、あえて自社実装を選んでいます。「まずは既製品で始めて、要件が複雑化したら自前化を検討する」という順序が、実務的には無難なようです。
もう一つの共通点は、VRAM（GPUメモリ）不足がほぼ全社で顕在化していることです。IIJは「VRAMがいくらあっても足りない」と率直に書いており、NTTドコモビジネスも今後の課題として「リソース確保とスケーリング」を挙げています。ローカルLLM基盤は、いったん構築して終わりではなく、モデルの大型化・利用拡大に合わせてハードウェア投資を継続する前提で計画する必要があります。
実装方法を要素分解する
自社で構築する場合に検討すべき要素を、層ごとに整理します。
推論エンジン層
| 選択肢 | 特徴 | 向いている用途 |
|---|---|---|
| vLLM | PagedAttentionによるメモリ効率化と継続的バッチ処理で高スループット。OpenAI互換APIで既存コードの変更が最小限 | 本番運用・大規模同時アクセス |
| Ollama | セットアップが容易で、100種以上のモデルに対応。それ自体がAPIサーバとして機能 | PoC検証や小規模導入の立ち上げ |
| llama.cpp | 軽量。埋め込み（Embedding）生成用のサブシステムとして使われることが多い | RAG用の埋め込みサーバなど補助的な用途 |
| LM Studio | GUI操作で個人検証がしやすい | 個人の動作確認。本格運用には不向き |
IIJの構成のように、チャット用の推論はvLLM、埋め込み生成はllama.cppと役割分担する例もあります。「なんでも1つのエンジンでやろうとしない」という発想は参考になります。
ゲートウェイ層
LiteLLM Proxyが提供する標準機能は、OpenAI互換エンドポイント、複数プロバイダー間のルーティング、コスト計測など、社内向けAIゲートウェイに必要な要素をひととおり備えています。まずはこれをそのまま使ってみて、はてなのように「シンプルな利用状況ならこれで十分」と判断できるか、RevCommのように「国内処理制約やフォールバック戦略など、自社特有のルーティングロジックがある」と判断するかで、その後の実装コストが大きく変わります。自社実装に踏み切る場合も、はてな・RevComm双方の事例が示すとおり、LiteLLM自体をインフラ層のコンポーネントとして内部で使い続ける（ゼロから作り直さない）選択肢は検討する価値があります。
APIキー管理も見落とされがちなポイントです。はてなの事例では、当初は情報システム部門的なチーム（CCoE）が一元管理していたキー発行を、利用者増加に伴って各チームが自律的に発行できる仕組み（Internal User機能）へ移行しています。立ち上げ期はガバナンスを優先した集中管理、拡大期は現場への権限委譲、という段階を踏む設計は他社でも参考にしやすいはずです。
UI層・可観測性
UIはOpenWebUIがよく使われる選択肢で、チャット履歴管理とモデル切り替えの機能を提供します。Dify等のLLMアプリケーションフレームワークと組み合わせて、業務アプリの裏側として使う構成も一般的です。
可観測性については、OpenTelemetry Collectorでテレメトリを収集し、ログとトレースを別々の適所（例：ログはCloudWatch Logs、トレースはLangfuse）に振り分ける設計が実用的です。「誰が」「どのモデルを」「どれだけ」使っているかの可視化は、はてなの事例が示すように、利用拡大期の意思決定（権限委譲のタイミングなど）に直結してきます。
モデルの量子化とハードウェア
VRAM不足への対処として各社が採用しているのが量子化です。NTTドコモビジネスは4ビット量子化でVRAM使用量を4分の1に抑え、IIJはAWQによるINT4量子化とFP8量子化を使い分けています。ただしIIJの事例が示すとおり、INT4量子化モデルは特定条件下で単語ループなど生成が不安定になることがあり、精度とリソース効率のトレードオフを見極める必要があります。
ハードウェアの目安としては、おおむね次のような段階感で語られることが多いです。
| 規模 | GPU構成の目安 |
|---|---|
| PoC検証 | 24GB級GPU（例：RTX 4090）1枚 |
| 数十人規模の展開 | 48GB級GPU（例：L40S） |
| 全社規模の本番運用 | A100・H100など、複数枚構成 |
CPUのみでも動作はしますが、応答速度が大幅に低下するため実用的ではありません。そして前述のとおり、IIJやNTTドコモビジネスの事例が示すように、「いったん十分な容量を確保したつもりでも、モデルの大型化や利用拡大でまたすぐ足りなくなる」というのが実態に近いようです。段階的な投資計画を前提にしておくのが無難でしょう。
活用方法――実際に何に使われているか
各社の事例を横断すると、ローカルLLM基盤の用途は次のようなパターンに集約されます。
- コーディング支援：各社共通で最も主要な用途。コーディングエージェントの普及が、そもそもローカルLLM基盤構築の主要な動機になっています。
- ドキュメント要約・議事録作成：社内文書や会議録を外部に出さずに要約させる用途。
- 技術文書・規程のRAG検索：設計書や法令・社内規程をベクトル検索と組み合わせ、検索工数を大幅に削減する使い方。機密性の高い文書を扱う製造業や金融機関で特に相性が良いとされています。
- 機器ログ・障害ログの解析：IIJの事例にあるように、運用ログの一次解析にLLMを充てるパターン。
- コンプライアンス対応の下支え：規程・法令データをローカルで処理し、社外に出せない情報を扱いながら対応スピードを上げる用途。
なお、新モデルが追加された直後に利用が偏るという傾向（NTTドコモビジネスのGLM-5.2の例）は、社内基盤を運用するうえで覚えておいて損はありません。新モデルのリリース直後はアクセスが集中しやすく、その分の余力をあらかじめ見込んでおく、あるいは新モデル投入のタイミングを計画的にアナウンスするといった運用上の工夫につながります。
導入を検討する際に押さえておきたいこと
複数社の事例を並べて見えてきた、共通の教訓を整理します。
- VRAM不足は前提として計画する：どの企業も「思ったより早くリソースが足りなくなる」と報告しています。初期構築時点で将来の拡張余地（電源・ラック・GPU増設）を見込んでおくべきです。
- 量子化は万能ではない：VRAM削減効果は大きい一方、精度や生成の安定性とのトレードオフがあります。特にINT4など強い量子化を本番投入する前には、業務で実際に使うプロンプトパターンでの検証が欠かせません。
- ゲートウェイは既製品から始める：LiteLLM Proxyのような既製のOSSゲートウェイは機能が充実しています。自社特有の複雑な要件（国内処理制約など）が明確に出てくるまでは、自前実装に踏み切らない方が開発・保守コストを抑えられます。
- 利用拡大期には権限委譲を設計する：立ち上げ期の中央集権的なキー管理は、利用者が増えると必ずボトルネックになります。はてなの事例のように、拡大を見込んだ権限移譲の仕組みをあらかじめ設計しておくと移行がスムーズです。
- 「ローカルに閉じる」ことと「ガバナンス」は別問題：ローカルLLM基盤を作ったからといって、利用ログの可視化やルール整備が自動的に済むわけではありません。誰が・何に・どのモデルを使っているかを追える仕組み（可観測性）とセットで運用してはじめて、当初の「利用実態把握」という目的が果たされます。
- 全部をローカル化する必要はない：機密性の高い業務はローカルLLM、それ以外の一般業務は使い勝手の良いクラウドLLM（Claude・ChatGPTなど）、というハイブリッドな使い分けを提案する声もあります。何でもローカルに寄せようとすると、運用負荷とハードウェア投資が際限なく膨らみかねません。
まとめ
「機密情報を外に出したくない」というニーズに対する答えは、ローカルLLM基盤だけではありませんが、コーディングエージェントの普及でLLM利用が業務の隅々まで広がった今、有力な選択肢の一つになっています。NTTドコモビジネス、IIJ、RevComm、はてなという毛色の異なる4社が、ほぼ同じ課題意識（データセキュリティ・利用統制・コスト管理）から出発しながら、ゲートウェイの自前実装／既製品利用、量子化戦略、キー管理の設計といった各所で異なる判断をしているのは興味深いところです。
自社で検討する場合は、まず小規模なPoCから始め、既製のOSS（vLLM＋LiteLLM Proxy＋OpenWebUIなど）で構成の当たりをつけたうえで、自社特有の要件（国内処理制約、既存の権限管理体系との整合など）が見えてきた時点で、どこをカスタマイズするかを判断するという順序が、各社の事例からも現実的に見えてきます。
本記事は、NTTドコモビジネス・IIJ・RevComm・はてなの各社エンジニアブログ、およびローカルLLM導入に関する公開情報をもとに、一般的な実装方法・活用方法として整理したものです。実際の構成・モデル選定・ハードウェア投資にあたっては、自社のデータ量・利用者数・セキュリティ要件に応じて個別に検討してください。
参考リンク
- Local LLMを社内に提供！ Local LLM Model as a Serviceとその取り組みについて — NTTドコモビジネス Engineers’ Blog
- 社内でローカルLLM APIサーバを構築・運用してみた話 — IIJ Engineers Blog
- 社内 LLM Gateway を作った話 — RevComm Tech Blog
- 社内にLiteLLM Proxy（OSS版）を導入してマルチプロバイダLLM運用基盤を作った話 — Hatena Developer Blog
- ローカルLLM（オンプレミスAI）導入完全ガイド【2026年版】Ollama・vLLM・LM Studio比較と企業活用 — Aurant Technologies
- LiteLLM Proxy（LLM Gateway）でOllamaへのプロキシサーバーを立ててみる — CLOVER🍀
- OpenWebUIとLiteLLMの組み合わせで自分専用LLMコンソールを構築する — ゆにりあ ブログ版
- LiteLLM＋Open WebUIでローカルAIチャット環境をDockerで構築 — Qiita
