Ollamaで自社LLM基盤を内製する: SREが見るSLOと運用コスト

社内のLLM（大規模言語モデル）利用で、機密コードや顧客データを外部APIに送らざるを得ない状況に悩むインフラ担当者は少なくありません。本記事はOllama（ローカル環境でLLMを動かすための推論エンジン）を使って、自前のAI基盤を構築・運用する際にSREの視点で見ておきたいポイントを整理します。

Ollamaはルート権限なしでインストールでき、モデルの取得からAPI提供まで1つのバイナリで完結します。手軽さの裏にある可用性・コスト・運用面の論点を、普段Terraformやオブザーバビリティツールを扱うエンジニアの視点で深掘りします。

Ollamaが解決する課題と仕組み

ChatGPTやClaudeのようなクラウドAPIを使う場合、プロンプトやログデータが外部事業者のインフラを経由します。SLA（サービス品質保証）がどれだけ厳格でも、データが学習や保存にどう使われるかを完全にコントロールすることはできません。

Ollamaはこの問題を「推論処理を自社インフラ内で完結させる」ことで解決します。インストールは非常にシンプルで、以下のコマンドだけで動作します。

# インストーラ取得（最新バージョンは公式サイトで要確認）
curl -fsSL https://ollama.ai/install.sh | sh

# バックグラウンドでサービス起動（一般ユーザー権限で可）
ollama serve &

特筆すべきは、システムディレクトリである/etcに変更を加えず、ホームディレクトリ配下で完結する点です。Dockerコンテナでラップしたり、SELinuxの例外設定を書いたりする必要がありません。既存のオンプレミス環境やVM上に素早く検証環境を立てたいSREにとって、導入障壁の低さは明確なメリットです。

モデルの取得もシンプルです。ollama pull llama3を実行すると、約4.7GBのモデルデータが自動的にダウンロード・キャッシュされ、Ollama独自の最適化フォーマットに変換されます。手動でバイナリを管理する必要がある他のフレームワークと比べ、運用の手間が大幅に削減されています。

起動後はREST API（http://localhost:11434）で外部連携が可能になります。

curl http://localhost:11434/api/generate -d '{
  "model": "llama3",
  "prompt": "ログ異常検知のルールを3つ提案して",
  "stream": false
}'

この構造化レスポンスは、社内の監視ダッシュボードやチケッティングシステムに直接組み込めます。プロトタイプ構築が「数週間」ではなく「数分」で済む点は、自動化を進めたいSREチームにとって見逃せない特徴です。

クラウドAPIとの比較で見るSLO設計の違い

クラウドAPIを使う場合のSLO（サービスレベル目標。可用性やレイテンシの数値目標）は、事業者側の公開SLAに依存します。障害時の対応もベンダー任せで、自分たちでコントロールできる範囲は限られます。

一方、Ollamaでローカルホストする場合、SLOの設計・計測・改善はすべて自社の責任範囲になります。これは自由度が増す一方、障害対応の仕組みを自前で用意する必要があることも意味します。

たとえば、推論エンドポイントの死活監視には、PrometheusでNode Exporterと組み合わせてGPU使用率・メモリ消費・レスポンスタイムを収集する構成が考えられます。Ollamaの/api/generateエンドポイントに対して定期的にヘルスチェックを飛ばし、レイテンシのp95やエラー率を可視化するダッシュボードを用意しておくと、障害の予兆を早期に掴みやすくなります。

IaC（Infrastructure as Code。インフラ構成をコードで管理する手法）の観点では、TerraformでOllamaサービスをホストするVMやコンテナを定義し、Ansibleやcloud-initでモデルのプル処理を初期化スクリプトに組み込む構成が現実的です。モデルファイルのバージョン管理（どのタグのllama3を使っているか）をコード側で明示しておくことで、環境差異による「動かない」トラブルを防げます。

外部に公開する場合は、Nginxやcaddyなどのリバースプロキシを前段に置き、TLSを強制する構成が最低限必要です。ポート11434をそのままインターネットに晒す運用は、認証機構がない分リスクが高くなります。

リソース要件とコスト最適化の判断基準

ローカルLLM運用で最初につまずきやすいのが、ハードウェア要件の見積もりです。モデルサイズが大きいほど必要なメモリ量は増え、量子化（モデルの精度を落として軽量化する手法）されたQ4_K_Mのようなバージョンを使うかどうかで必要スペックが大きく変わります。

目安として、8GBのRAMではすぐに上限に達し、実用的な運用には32GB以上のメモリが最低ラインとして語られています。GPUを使わないCPU推論では、レスポンスタイムが数秒〜数十秒単位になることも珍しくなく、リアルタイム性が求められる用途には不向きです。

コスト最適化の観点では、クラウドAPIの従量課金と自前ホスティングの固定費（サーバー・電力・保守人件費）を比較する必要があります。利用頻度が高く、常時起動するワークロードであれば自前ホスティングの方が有利になりやすい一方、スパイク的な利用が中心なら従量課金の方が無駄が出にくいという判断軸があります。

観点	クラウドAPI	Ollamaローカルホスト
データ主権	事業者依存	自社管理
SLO管理	ベンダー任せ	自社設計・自社計測
コスト構造	従量課金	固定費（ハード・電力）
初期構築コスト	ほぼゼロ	サーバー調達・設定が必要
障害対応	SLA頼み	監視・runbook整備が必須

ローカルLLM運用はデータ主権を取り戻せる一方、SLO設計・監視・障害対応の仕組み化を全て自前で担う覚悟が必要です。

今日確認できること

実際に検証を始めるなら、まず以下を確認してみてください。

ollama --versionで現在のバージョンを確認し、公式リポジトリの最新リリースと比較する
対象サーバーの空きメモリをfree -hで確認し、量子化モデル込みで32GB以上の余裕があるか判断する
/api/generateへのヘルスチェックを既存の監視基盤（Prometheus・Datadog等）に組み込めるか検討する
リバースプロキシとTLS終端の構成がすでにある場合、Ollamaのエンドポイントをそこに追加できるか確認する
Terraform等で管理している既存VMテンプレートに、Ollamaのインストールスクリプトを組み込めるか試す

これらは特別な追加ツールを必要とせず、既存のSRE運用フローの延長線上で検証できる項目です。

まとめ

Ollamaは、機密データを外部に出さずにLLMを使いたいというニーズに対する、現実的な選択肢のひとつです。

インストールの手軽さとAPIのシンプルさは魅力的ですが、SLO設計・監視・障害対応の仕組み化は自社の責任範囲になる点を忘れてはいけません。

まずは検証環境でメモリ要件とレスポンスタイムを実測し、既存の監視基盤に組み込めるかを確認するところから始めてみてください。

本番投入を検討する段階では、IaCによる構成管理とコスト比較の2軸で、クラウドAPIとの使い分けを設計しておくと判断がぶれにくくなります。