AIエージェントや業務システムへの生成AI組み込みが加速する中、実務の現場ではCTOやインフラ責任者から共通の「悲鳴」が聞こえてきます。
「生成AIをプロダクトに組み込みたいが、APIの従量課金が怖くて踏み出せない」
「機密データを外部APIに投げることに、法務部がどうしても首を縦に振らない」
皆さんも、似たようなジレンマを抱えていないでしょうか？
革新的な技術を使いたいというエンジニアの情熱と、コストやリスクを管理しなければならない経営の論理。この板挟みこそが、現在のAI導入における最大の障壁です。
今回は、高速プロトタイピングや実運用を見据えたアーキテクチャ設計の観点から、一つの「現実解」を共有したいと思います。それは、OllamaとDockerを活用した、GGUF形式モデルの自社運用（セルフホスト）というアプローチです。
最新のH100 GPUを並べた豪華なクラスタでもなければ、巨大なパラメータ数を誇るフルモデルの運用でもありません。限られたリソースの中で、いかに「使える」AI基盤を構築し、ビジネス課題を解決するか。その泥臭くも実践的なアプローチを、技術的な詳細とともに解説していきます。
プロジェクト背景：APIコストの爆発と「クラウド破産」の危機
AI機能を組み込んだプロダクト開発において、当初の想定を遥かに超えるコスト増大と、厳格化するデータセキュリティ要件は、多くの開発チームが直面する共通の課題です。特に、PoC（概念実証）から本番運用へ移行するフェーズで、これらの問題は顕在化します。
月額200万円を超えたGPUインスタンス費用
開発初期段階では、API利用料は許容範囲内に収まることが一般的です。しかし、サービスがスケールし、ユーザー数が増加するにつれて、コスト構造は劇的に変化します。特に、最新の推論モデル（OpenAIのoシリーズやClaudeの最新モデルなど）を利用する場合、トークンごとの従量課金は指数関数的に跳ね上がります。
コスト圧迫の要因は、単なるAPI利用料だけではありません。レスポンス速度（レイテンシ）を安定させるために確保するプロビジョニング済みスループット（予約帯域）のコストは、さらに高額になる傾向があります。
また、独自データでのファインチューニングや検証のためにクラウド上でGPUインスタンス（H100やA100などのハイエンドGPU）を立ち上げるケースも増えています。ここで頻発するのが、開発チームによるインスタンスの停止忘れです。時間単価の高いGPUインスタンスが週末を通して稼働し続けた結果、単月で数百万円規模の請求が発生し、プロジェクトの予算を圧迫する「クラウド破産」のリスクは、決して珍しい話ではありません。
ビジネスモデルを成立させるためには、推論コストを劇的に、例えば現行の10分の1以下に圧縮するアプローチが求められます。
機密データ処理におけるSaaS利用の限界
コストと同様に、あるいはそれ以上に深刻なのがデータガバナンスの問題です。特に金融機関や医療機関、公共部門をターゲットとするシステムでは、データの取り扱いに極めて慎重な判断が求められます。
たとえAPI提供元の規約で「学習に利用しない」と明記されていたとしても、またAzure OpenAIのようなエンタープライズ向けのセキュリティ機能（PII検出やプライベート接続）を利用したとしても、「顧客データや社内文書を外部のサードパーティサーバーへ送信する」こと自体がコンプライアンス上許容されないケースがあります。
「データは自社の管理下にあるVPC（仮想プライベートクラウド）やオンプレミス環境から一歩も出してはならない」
このような厳格な要件（データ主権）を満たすために、外部APIへの依存を断ち切る必要に迫られるプロジェクトは少なくありません。
オンプレミス回帰という決断
「コストの大幅な削減」と「完全なデータ主権の確保」。この相反するようにも見える2つの課題を同時に解決する有効な手段が、「自社管理環境でのLLMホスティング」です。
かつて、自前でLLMを運用することは、巨大なVRAM（ビデオメモリ）を持つ高価なハードウェアと、複雑怪奇な環境構築を必要とするハードルの高い選択肢でした。しかし、技術の進歩により状況は一変しています。
モデルの軽量化技術である「量子化（Quantization）」と、それを手軽に扱えるランタイムツール「Ollama」の登場により、一般的なGPUリソースでも実用的な速度でLLMを動作させることが可能になりました。これにより、セキュリティを担保しながら、推論コストをハードウェアの電気代と償却費のみに抑えるという、新たな選択肢が現実的になっています。
選定プロセス：なぜ「vLLM」ではなく「Ollama + GGUF」だったのか
自社でLLMをホスティングしてAI基盤を構築する場合、推論エンジン（Inference Engine）の選定がプロジェクトの成否を分ける重要な分岐点となります。市場には優秀なオープンソースツールが数多く存在しますが、実運用を見据えた場合、以下の3つが主要な候補として比較検討される傾向にあります。
- vLLM: 圧倒的な高スループットを誇り、大規模なプロダクション環境におけるデファクトスタンダード。
- Text Generation Inference (TGI): Hugging Faceが開発。高い安定性と広範なモデルサポートが特徴。
- Ollama: ローカル実行に特化し、GGUF形式をネイティブサポートすることでリソース効率を最大化。
推論エンジンの比較検討（vLLM vs TGI vs Ollama）
パフォーマンスの観点から見れば、vLLMが強く推奨されるケースが多いでしょう。理由は明白で、「速いから」です。PagedAttention技術によるメモリ管理は極めて優秀で、多数の同時リクエストをさばく能力においてvLLMは他の追随を許しません。
しかし、vLLMを最大限に活用するには、基本的にモデルをFP16（16ビット浮動小数点）やBF16でロードすることが推奨され、これには膨大なVRAMが必要です。例えば、Llamaシリーズの70Bクラスのモデルを動かすには、FP16だと約140GB以上のVRAMが必要となり、A100 80GBが2枚必要になる計算です。これでは、「コスト効率の高い自社LLM基盤」という目的からは乖離してしまいます。
対して、OllamaはGGUF形式のモデルを扱うことに特化しています。GGUFは、モデルの重みを量子化（Quantization）して保存するフォーマットであり、リソース制約の厳しい環境の要件に合致します。
GGUF形式（量子化）がもたらすリソース効率の革命
ここで「量子化」のインパクトについて補足します。通常、AIモデルのパラメータは16ビットや32ビットの数値で表現されますが、これを4ビットや5ビットといった小さな情報量に圧縮する技術が量子化です。
「精度が大幅に劣化するのではないか？」という懸念は、多くのエンジニアが抱く共通の疑問です。しかし、近年の研究や実務におけるPoC（概念実証）の傾向として、適切な手法（Q4_K_Mなど）で4ビット量子化を行えば、推論精度の低下は実用上無視できる範囲に収まることが確認されています。特にRAG（検索拡張生成）やチャットボットのようなタスクにおいて、人間がその差を体感するのは困難です。
GGUF形式の4ビット量子化モデルを採用することで、70Bクラスの大型モデルであっても約40GB程度のVRAMで動作させることが可能になります。これにより、高価なH100/A100ではなく、比較的安価なコンシューマーグレードのGPUや、クラウド上のコストパフォーマンスに優れたGPUインスタンス（NVIDIA L4やA10Gなど）でも十分に運用可能となります。
開発者体験（DX）と保守性のバランス
技術的なリソース効率に加え、採用の決定打となり得るのが「Modelfile」による管理の簡便さです。DockerにおけるDockerfileの概念をLLMに応用したModelfileを使用することで、ベースモデル、プロンプトテンプレート、パラメータ設定をコードとして管理（IaC）できます。
# 最新のLlamaモデル（70B・4bit量子化版）を指定
FROM llama-model:70b-instruct-q4_k_m
# パラメータ設定
PARAMETER temperature 0.7
# システムプロンプトの定義
SYSTEM """
あなたは優秀なAIアシスタントです。ユーザーの質問に対して、簡潔かつ論理的に日本語で回答してください。
複雑な推論が必要な場合は、ステップバイステップで考えてください。
"""
このシンプルさは、LLM運用の経験が浅いインフラエンジニアや開発者にとって強力な武器となります。vLLMやTGIの複雑な設定ファイルや環境構築に比べ、Ollamaは直感的であり、チームへの導入障壁が極めて低い点が評価されます。
結果として、「理論上の最高性能（スループット）」ではなく、「リソース効率（コスト）」と「運用容易性（保守性）」を優先し、Ollama + GGUFを採用することは、限られた計算資源の中で最大のビジネス価値を生み出すための、戦略的な選択となります。
実装の深層：軽量コンテナの構築とデプロイ戦略
選定が終われば、次は実装フェーズです。ここでの技術的課題は、いかにしてOllamaをDockerコンテナ化し、Kubernetes（k8s）などのオーケストレーション環境で効率的かつ安定して稼働させるかに集約されます。
モデルファイルを同梱するか、マウントするか
Dockerイメージを構築する際、アーキテクトが直面する最初の分岐点は「巨大なGGUFモデルファイルをDockerイメージの中に含めるべきか否か」という問題です。
モデルファイルをイメージに COPY してしまえば、単一のイメージで完結するためデプロイフローは単純化されます。しかし、数GB〜数十GBもあるモデルを含めると、イメージサイズが肥大化し、レジストリへのプッシュやノードへのプルに膨大な時間を要することになります。
さらに、昨今のAIトレンドを考慮する必要があります。推論能力が強化されたモデルや、コーディングに特化した軽量モデルなど、新しいモデルが日進月歩でリリースされています。モデルをイメージに同梱してしまうと、モデルを更新するたびにコンテナの再ビルドと巨大なイメージの再配布が発生し、迅速な検証やロールバックの妨げとなります。
そのため、専門家の視点からは「ベースイメージとモデルの分離」戦略を強く推奨します。
- Dockerイメージ: Ollamaのランタイムと、共通の設定ファイルのみを含む軽量なイメージ（数百MB程度）を作成します。
- モデルファイル: KubernetesのPersistent Volume（PV）や、S3互換のオブジェクトストレージに配置し、コンテナ起動時にマウント、あるいは
initContainerを使用して取得する構成にします。
具体的には、起動スクリプト（entrypoint.sh）内で ollama pull を実行してダウンロードを待つのではなく、事前に配置済みのGGUFファイルを指定ディレクトリにマウントし、Modelfileからそれを参照してモデルを即座にロードするフローを構築します。これにより、コンテナの起動時間（コールドスタート）を大幅に短縮し、オートスケーリングへの追従性を高めることが可能です。
CPU推論へのフォールバック戦略
Ollamaの採用における大きな利点の一つに、ハードウェアリソースへの柔軟な対応力が挙げられます。具体的には、GPUが見つからない場合やVRAMが枯渇した場合に、自動的にCPU推論へフォールバックする機能です。
量子化されたGGUF形式は、その構造上CPUでの推論も比較的実用的な速度で実行可能です（もちろんGPUには及びませんが）。この特性を活かし、開発環境や緊急時のバックアップとして、CPUのみのノードでも最低限のサービスレベルを維持できる設計が可能になります。
このアーキテクチャは、クラウドにおけるGPUインスタンスのスポット利用（AWSのSpot InstancesやGCPのPreemptible VMs）と非常に相性が良いと言えます。コスト削減のために利用しているGPUインスタンスがプロバイダーの都合で強制終了されたとしても、一時的にCPUノードでリクエストを処理することで、サービスダウンという最悪の事態を回避できるからです。
Kubernetes上でのOllamaクラスタ構成
Kubernetesへのデプロイにおいて、最も重要なのはGPUリソースの適切な割り当てです。一般的にNVIDIA Device Pluginを導入し、Deploymentマニフェストで以下のようにリソース制限を明示します。
resources:
limits:
nvidia.com/gpu: 1
また、ネットワーク設定にも注意が必要です。Ollamaはデフォルトでセキュリティを考慮し、127.0.0.1 （ローカルループバック）のみをリッスンする設定になっています。コンテナ外（Pod間通信やService経由）からのアクセスを許可するためには、環境変数 OLLAMA_HOST=0.0.0.0 の設定が不可欠です。
さらに、プロダクション環境では以下の環境変数の調整も検討すべきです：
OLLAMA_KEEP_ALIVE: モデルをメモリに保持する時間を制御します。頻繁なリクエストが予想される場合は、デフォルト（5分）より長く設定することで、モデルの再ロードによるレイテンシを防げます。OLLAMA_NUM_PARALLEL: 同時リクエスト処理数を設定します。GPUメモリに余裕がある場合、これを増やすことでスループットを向上させることができます。
これらは初歩的ながら、安定した自社LLM基盤を構築する上で見落としやすい重要な設定ポイントです。
直面した壁：推論レイテンシと並列処理の限界
しかし、本格的な負荷テストを実施する段階になると、ローカルLLM運用特有の大きな壁に直面することがよくあります。クラウドAPIを利用する場合とは異なる、リソース管理の難しさが露呈するのです。
同時リクエスト時のパフォーマンス低下
Ollamaは開発者個人のPCで動作させることを主眼に設計されており、そのシンプルさが魅力です。しかし、サーバーとして多数の同時リクエストを捌くスループット性能に関しては、vLLMなどのプロダクション向け推論エンジンと比較すると、設計思想の違いからくる制約があります。
初期設定のまま複数のユーザーが同時にチャットボットを利用すると、2人目以降のリクエストが極端に遅延するか、タイムアウトするという現象が発生しがちです。これはOllama（およびそのバックエンドであるllama.cpp）がデフォルトではリクエストを順次処理するため、前のユーザーの生成完了を待つ「Head-of-Line Blocking」が発生することが原因です。Azure OpenAIのようなクラウドサービスでは自動的にスケーリングされますが、オンプレミス環境ではこの並列処理の制御を自前で行う必要があります。
Ollamaの並列処理設定のチューニング
この課題を解決するためには、OLLAMA_NUM_PARALLEL 環境変数の調整が必要になります。これは、同一モデルをメモリにロードした状態で、同時にいくつのリクエストを処理するかを決定する重要なパラメータです。
しかし、単純に数値を上げれば解決するわけではありません。ここには明確なトレードオフが存在します。
- VRAM消費量の増加: 並列数を増やすと、各リクエストのコンテキスト（KVキャッシュ）を保持するためのVRAM領域が追加で必要になります。コンテキスト長を長く設定している場合、並列数を上げると容易にVRAM溢れ（OOM）を引き起こします。
- 生成速度の低下: 計算リソース（Compute）が分散されるため、1リクエストあたりの生成速度（Tokens Per Second）は低下します。
使用するGPUのVRAM容量と、ユーザーが許容できるレイテンシのバランスを見極めるため、徹底的なベンチマークを行うことが推奨されます。例えば、あるハードウェア構成では「同時接続数4」を最適値（スイートスポット）と判断し、それ以上のリクエストがスパイクした場合は、前段のNginxやアプリケーションサーバー側でキューイングして、ユーザーには「ただいま混み合っています」という待機ステータスを明示する設計が有効です。
ユーザー体験を守るためのフロントエンド側の工夫
バックエンドの物理的な限界をハードウェア増強だけで解決しようとすると、コスト削減という本来の目的が損なわれます。そこで、UX（ユーザー体験）デザインによるカバーを併用することが重要になります。
具体的には、ストリーミングレスポンス（Streaming Response）の完全実装です。Ollamaはトークン生成ごとの逐次レスポンスに対応しています。これを利用し、回答全体の生成完了を待たずに、文字が打たれている様子をリアルタイムで画面にレンダリングすることで、ユーザーの体感待ち時間を劇的に短縮できます。
「待たされている」と感じるのは、画面に何も変化がない時間です。たとえ全体の生成時間が同じでも、最初のトークン（TTFT: Time To First Token）が素早く表示されるだけで、ユーザーのストレスは大幅に軽減されます。これは、リソースに制約のあるオンプレミスLLM構築において、非常に効果的なアプローチです。
成果とROI：コスト90%削減と開発サイクルの加速
OllamaとDockerを活用した基盤構築は、多くのプロジェクトにおいて、単なる技術的な置き換え以上の成果をもたらします。ここでは、一般的な導入ケースにおける定量的・定性的なインパクトについて解説します。
GPUコスト：月額200万→20万への圧縮（試算例）
最も顕著な成果はコスト構造の変革です。商用APIの従量課金や、高額なクラウドGPUインスタンスを常時稼働させる構成と比較して、適切なサイズのGPU（NVIDIA L4など）と量子化モデルを活用することで、ランニングコストを大幅に圧縮できるケースが珍しくありません。
適切に導入した場合、月額200万円規模だったインフラコストが約20万円まで削減されるような試算も十分に成り立ちます。これは単なる「節約」にとどまりません。損益分岐点が劇的に下がることで、よりアグレッシブな機能開発や、無料ユーザーへのAI機能開放といったビジネス戦略の選択肢が広がります。経営視点で見れば、AI機能の原価率をコントロール可能な範囲に収めるための重要な施策と言えます。
ローカル環境での開発スピード向上
副次的な、しかし非常に重要な効果として、開発チームの生産性向上が挙げられます。
クラウドAPIに依存した開発では、ネットワーク遅延やAPIのレート制限、エラーハンドリングに悩まされることが一般的です。しかし、OllamaとDockerによってローカルPC（MacBook Proなど）でも本番とほぼ同じ環境をコンテナとして再現できるため、エンジニアはオフラインでも開発・検証が可能になります。
「手元で動く」という安心感は、エンジニアの心理的ハードルを下げ、プロンプトエンジニアリングの試行錯誤（トライ＆エラー）の回数を飛躍的に増やします。結果として、AIの回答精度や機能の改善サイクルが加速します。
社内セキュリティ審査の通過期間短縮
そして、データガバナンスの課題解決も大きなメリットです。「データは自社のVPC内で完結し、外部には一切送信されない」というアーキテクチャは、セキュリティ部門や法務部門への説明を極めてシンプルにします。
外部APIを利用する場合、データの取り扱いに関する厳格な審査が必要となり、数週間から数ヶ月を要することも珍しくありません。一方、自社管理のコンテナ基盤であれば、既存のセキュリティポリシーの延長線上で審査が可能となり、承認までの期間が大幅に短縮されます。これにより、市場への価値提供までのリードタイムが最小化されます。
まとめ：持続可能なAI活用のために
今回の解説から見えてくるのは、「最新・最高スペック」が常に唯一の正解ではないということです。
確かに、ChatGPTの最新モデル（GPTシリーズ）や、推論能力に特化したoシリーズ（OpenAIの推論モデル, OpenAIの推論モデル等）のような商用モデルは強力であり、複雑な推論や高度な創造性が求められるタスクでは他を圧倒します。また、Azure OpenAIなどで提供される最新のセキュリティ機能（PII検出など）も魅力的です。
しかし、要約、分類、定型的な応答といった特定のタスクにおいては、適切にチューニングされ、量子化されたオープンモデルでも十分実用的な性能を発揮します。そして何より、コストとデータを自分たちでコントロールできるという「自由」は、長期的なビジネスの競争力に直結します。
OllamaとDocker、そしてGGUF形式モデルの組み合わせは、リソースの制約がある現実世界で、AIを持続的に活用していくための賢明で戦略的な選択肢の一つです。
クラウドAPIの進化（エージェント機能や特定領域特化型モデルなど）を見据えつつ、適材適所でローカルLLMを組み合わせる「ハイブリッドなAI戦略」こそが、これからのエンジニアリング組織に求められるアプローチではないでしょうか。
コメント