社内データを ChatGPT に貼り付けるわけにはいかない。でも LLM の処理能力は業務で使いたい。この両立を狙えるのが、ローカル LLM を API サーバーとして立てる構成です。Ollama は、手元の環境で LLM を動かし、その機能を REST API として呼び出せる実行環境です。
クラウドの API に頼らず、自分の PC やサーバーの中だけで大規模言語モデルを動かし、その推論を社内アプリから HTTP リクエストで呼び出す。これが「Ollama をローカル API サーバーにする」という構成です。ローカルのモデルだけを使う構成なら、プロンプトや応答を外部の推論 API へ送らずに処理できるので、機密文書や個人情報を扱う業務でも現実的な選択肢になります。ただし後述するとおり、いまの Ollama にはクラウドモデルや Web 検索といったオンライン機能も含まれるため、「ローカルだから何をしても外に出ない」と単純化はできません。社内で使うときは、この切り分けが大事になります。
- Ollama はローカルで LLM を動かし、OpenAI 互換 API として呼び出せる実行環境
- ローカルモデルだけを使い、クラウド機能を無効化すれば、推論データを Ollama のクラウド機能へ送らず処理できる（ローカル推論はトークン従量課金なし・モデル取得後はオフライン可）
- OpenAI 互換 API を使えば、シンプルな実装なら base_url の差し替えで既存コードを流用しやすい（全機能が完全互換ではない）
Ollama をローカル API サーバーにするとは
Ollama をローカル API サーバーにするとは、自分の環境で動く LLM 実行基盤を HTTP のエンドポイントとして公開し、別のアプリから呼び出せる状態にすることです。普段はコマンドラインで対話するツールという印象が強いかもしれませんが、その本体は API サーバーとして常駐する仕組みになっています。Ollama そのものの導入やモデルの選び方は、ローカルLLMの始め方を解説した記事でも詳しく扱っています。
Ollama を起動すると、内部では推論エンジンが待機状態に入り、特定のポートで HTTP リクエストを受け付けます。ターミナルから手で文章を打ち込まなくても、プログラムが送ってきたリクエストに対して LLM が回答を返す。このプログラムから叩ける口が、API サーバーとしての Ollama の正体です。社内の Web アプリ、業務スクリプト、既存システムのバックエンドなど、どこからでも HTTP で問い合わせれば、ローカルの LLM が処理してくれます。
クラウド API との大きな違いは3つあります。ローカルのモデルだけを使えば、推論データを外部の API へ送らずに処理できること。ローカル推論なら、リクエストごとの従量課金が発生しないこと。そして、必要なモデルを事前に取得しておけば、インターネット接続が切れていても動くこと。この3つがそろうと、外部送信が許されない業務データを LLM で処理する道が開けます。ただし「外に出ない」はローカルモデルを使う場合の条件で、クラウドモデルや Web 検索を使うと前提が変わります。大事な区別なので、運用上の注意点の章で改めて取り上げます。
Ollama が持つ API と互換エンドポイント
Ollama には、モデルの生成や管理に使う独自のネイティブ API（/api 系）に加えて、既存アプリをつなぎやすくする互換エンドポイントが用意されています。本記事で主に扱うのは OpenAI 互換 API（/v1/chat/completions など）です。現行の公式ドキュメントでは Anthropic Messages API 互換（/v1/messages）も案内されており、Claude Code のような Anthropic API 前提のツールをローカルモデルへつなぐ用途に使えます。
ネイティブ API は Ollama の機能をフルに引き出せる作りで、モデルの管理や細かい制御に向いています。一方の OpenAI 互換 API は、その名のとおり OpenAI のリクエスト形式・レスポンス形式に合わせて作られています。すでに OpenAI の SDK や ChatGPT 向けに書いたコードがあるなら、シンプルな呼び出しに限れば、接続先の URL を差し替えるだけでほぼそのまま動かせます。社内アプリへ組み込むときに互換 API がよく選ばれるのは、移行の手間がほとんどかからないからです。
どれを使うか迷ったら、手元のコード資産で決めるのが早道です。OpenAI 向けのコードがあるなら OpenAI 互換 API、Ollama 固有の機能を直接使いたいならネイティブ API、Anthropic API 前提のツールをつなぐなら Anthropic 互換 API。この三択で考えれば、おおむね迷わずに済みます。
社内利用でAPIサーバー化が選ばれる理由
API サーバー化が社内で支持されるのは、機密性・コスト・可用性の3つがそろうからです。
機密性の面では、ローカルのモデルで推論を完結させれば、顧客情報や設計データを外部の推論 API へ送らずに処理できます。とはいえ、ローカルで動かせること自体が「どんな機密情報でも無条件に入力してよい」という意味にはなりません。社内規程上どの区分のデータを入力してよいか、LAN 上の別ユーザーに勝手に使われないか、アプリやプロキシのログに入力内容が残らないか。このあたりはローカルでも別に設計が必要です。コストの面では、トークン課金がないので、大量のドキュメントを一括処理しても請求が膨らむ心配がありません。可用性については、ローカルモデルを取得済みでクラウド機能を使わない構成なら、社内ネットワークさえ生きていれば、インターネット障害の影響を受けずに動き続けます。
これらは「クラウドだと困る場面」の裏返しでもあります。たとえばクラウド AI が急に本人確認を求めてきて使えなくなるような場面では、ローカルで完結できる強みがはっきり出ます。クラウド API は手軽な反面、データの外部送信・従量課金・外部依存という制約がついて回ります。その制約が業務の足かせになるほど、ローカル API サーバーという選択肢が生きてきます。
動作の仕組みと前提環境
Ollama の API サーバーは、既定で localhost:11434 を待ち受けポートとして起動し、受け取った HTTP リクエストをモデルに渡して推論結果を返します。リクエストを受け取り、モデルが処理し、結果を返す。この一往復が基本動作のすべてです。
流れを追うと、まずクライアント（社内アプリ）がプロンプトを JSON 形式で POST します。Ollama サーバーは指定されたモデルをメモリにロードし、推論を実行します。生成されたテキストを JSON で返す、という流れです。一度ロードしたモデルは既定で5分間メモリに保持されるため、連続したリクエストでは2回目以降の応答が速くなる傾向があります（保持時間は OLLAMA_KEEP_ALIVE で変更可能）。逆に、初回や久しぶりのリクエストでは、モデルをメモリに読み込む時間がそのぶん上乗せされます。
実行環境は、GPU があると快適ですが必須ではありません。ひとつの目安として、VRAM 16GB クラスの GPU なら中規模のモデルまで GPU 上で快適に動きます。GPU がなくても CPU と十分な RAM で動かせますが、その場合は応答速度が落ちます。
| 提供元 | Ollama（vendor=Ollama） |
|---|---|
| ライセンス | MIT ライセンス（公式 GitHub リポジトリ） |
| 料金 | ローカル実行は無料（has_free_tier=yes）／クラウド機能は別建て |
| API | ネイティブ API ＋ OpenAI 互換 ＋ Anthropic 互換 |
| 既定ポート | 11434（既定バインドは 127.0.0.1） |
| 対応モダリティ | テキスト／画像（modality=text+vision） |
既定ポート11434とリクエストの流れ
Ollama サーバーは起動すると http://localhost:11434 で待ち受けます。この 11434 が Ollama の標準ポートで、ここへ HTTP リクエストを投げると LLM が応答する、という流れです。
リクエストの中身はシンプルです。「どのモデルを使うか」と「何を聞くか（プロンプト）」を指定して送るだけ。サーバーはそのプロンプトをモデルに通し、生成結果を返してきます。まずはブラウザで http://localhost:11434 にアクセスしてみると、サーバーが立ち上がっているかどうかを確かめられます。応答が返ってくれば、API サーバーとしては正常に動いています。
公式 FAQ にあるとおり、既定では 127.0.0.1（localhost）、つまり同じマシンからのアクセスしか受け付けません。これはセキュリティ上の初期設定で、社内 LAN の他のマシンから叩きたい場合は、別途公開の設定が要ります。この公開設定については、後ろのセクションで詳しく扱います。
モデルサイズと必要メモリの目安
モデル選びで最初にぶつかるのが、メモリ要件です。LLM はパラメータ数が多いほど賢くなる傾向がある反面、必要なメモリも比例して増えていきます。
目安として、軽量なモデルなら一般的な GPU や CPU でも動きますが、大規模なモデルになるほど VRAM や RAM を大量に消費します。VRAM に収まりきらないサイズのモデルを動かすと、はみ出した分が CPU 側のメモリで処理されるため、その分だけ速度が落ちます。
モデル別の具体的な処理速度やメモリ消費量は、量子化（モデルを軽量化する圧縮手法）の設定やバージョンによって変わります。実際にどの程度のスペックが要るかは、モデルごとの必要スペックと量子化を検証した記事が具体的な目安になります。最新の対応モデルと推奨スペックは、公式サイトで確認するのが確実です。まずは軽量モデルで動作を確かめ、性能が物足りなければ一段大きいモデルに上げていく。この順で進めると無理がありません。
API サーバーとして公開する設定手順
Ollama を API サーバーとして公開する手順は、サーバー起動・公開範囲の設定・モデル取得の3ステップに分かれます。ここでは、社内アプリから呼べる状態にするまでの流れを順に見ていきます。コマンドは太字で示すので、入力するときはそのまま打ち込んでください。
導入後の Ollama は、多くの環境でバックグラウンドのサービスとして自動的に立ち上がります。手動でサーバーを起動したいときは ollama serve を実行すると、API サーバーが前面で動き出します。この状態で、先ほどの 11434 ポートが待ち受けに入ります。あとは公開範囲とモデルを整えれば、社内アプリから呼び出す準備が整います。
ローカル起動とネットワーク公開（OLLAMA_HOST設定）
既定の Ollama は localhost からのアクセスしか受け付けないため、社内 LAN の別マシンから呼ぶには、公開範囲を広げる設定が必要です。その役割を担うのが OLLAMA_HOST という環境変数です。
この環境変数に 0.0.0.0（例: OLLAMA_HOST=0.0.0.0:11434）を指定して起動すると、サーバーがすべてのネットワークインターフェースで待ち受けるようになります。これで同じ LAN 内の他のマシンから接続できますが、気をつけたいのは 0.0.0.0 は「LAN だけに限定する」設定ではないことです。そのマシンが VPN や別セグメント、ポート転送、クラウドのパブリック NIC などにつながっていれば、到達できる範囲すべてから叩かれうる待ち受けになります。公開するときは、ファイアウォールやネットワーク ACL で、接続を許可する送信元を明示的に絞ってください。
公開範囲は「必要な分だけ広げる」のが原則です。同じマシン内で完結するなら localhost のまま、特定のチームだけで使うなら公開＋送信元の制限、という具合に、使う範囲に応じて設定を選びます。いきなり全開放するのではなく、最小限から始めるのが安全です。
使うモデルの取得とウォームアップ
サーバーを立てても、肝心のモデルが手元になければ推論はできません。モデルの取得には ollama pull モデル名 を使います。軽量なモデルを試すなら、公式で配布されているモデル名を指定して取得します。
取得したモデルは初回のリクエスト時にメモリへ読み込まれますが、このロードに少し時間がかかります。本番運用では、実際のリクエストが来る前に一度ダミーのリクエストを送ってモデルをメモリに載せておく「ウォームアップ」をしておくと、最初のユーザーを待たせずに済みます。常駐サーバーとして使うなら、このひと手間で初回の体感がだいぶ変わります。
どのモデルを選ぶかは用途しだいです。日本語の文章処理が中心なら日本語性能の高いモデル、コード補助ならコード特化のモデル、と目的に合わせて選びます。実在するモデル名や最新のラインナップは、公式サイトのモデル一覧で確認してください。記憶や推測であいまいなモデル名を指定すると取得に失敗するので、公式の表記をそのまま使うのが確実です。
起動を常駐させる（サービス化の考え方）
社内アプリから恒常的に呼ぶ API サーバーなら、Ollama を常駐させておく必要があります。ターミナルを閉じたら止まってしまう起動の仕方では、業務システムの基盤としては心もとないからです。
多くの環境では、インストールした時点で Ollama が OS のサービスとして登録され、マシン起動時に自動で立ち上がる構成になっています。サービスとして動いていれば、サーバーを再起動しても Ollama が自動で復帰するので、運用の手間が減ります。手動でサーバーを動かしている場合は、OS のサービス管理機構に登録して、自動起動・自動復帰する構成へ切り替えておくと安心です。
常駐化で大事なのは、プロセスが落ちたときに自動で立ち上がり直す仕組みを用意しておくことです。業務で使う以上、誰も気づかないうちにサーバーが止まっていた、という事態は避けたいところ。サービス化に加えてプロセスの死活監視を組み合わせておくと、運用がぐっと安定します。
社内アプリから呼び出す実装パターン
社内アプリからの呼び出しは、OpenAI 互換エンドポイント /v1/chat/completions を使うのがいちばんの近道です。コードを書かずに業務アプリへ組み込みたいなら、Dify のようなノーコードの AI アプリ基盤から Ollama を呼ぶ手もあります。既存の OpenAI SDK を使ったコードがあるなら、接続先の base_url を http://localhost:11434/v1 に差し替えれば、シンプルなチャット呼び出しはほぼそのままローカル LLM に向きます。ただし OpenAI API の全機能が完全互換なわけではなく、たとえば Responses API（/v1/responses）は一部の状態管理パラメータに対応していません。高度な機能を使っているなら、対応範囲を先に確認しておくと安全です。
API キーの欄にはダミーの文字列を入れて構いません（公式の例でも api_key=”ollama” として「必須だが無視される」と説明されています）。ただし、これが認証として働くわけではない点には注意してください。ネットワークへ公開するなら、利用者の認証はリバースプロキシや API ゲートウェイ側で別途用意します。
curl で試すなら、curl http://localhost:11434/v1/chat/completions に対してモデル名とメッセージ配列を JSON で投げるだけです。Python なら OpenAI ライブラリの OpenAI(base_url=…) を書き換え、JavaScript でも同じように、クライアント初期化時の base_url を変更します。
ネイティブの /api/generate や /api/chat を直接叩く選択肢もあります。互換 API ではカバーしきれない Ollama 固有のオプションを使いたいときは、こちらを使います。ストリーミング応答にすれば、レスポンスを逐次受け取って画面に流せるので、チャット UI のような「打ち込んだそばから返ってくる」体験を作れます。
運用上の注意点とセキュリティ
運用でまずつまずきやすいのが認証です。ローカルの Ollama API は標準では利用者認証を要求しないため、ネットワークへ公開した API をそのまま放置すると、到達できる範囲のユーザーなら誰でも呼び出せる状態になります。
社内データを扱う前提なら、もうひとつ必ず押さえておきたいのがクラウド機能の扱いです。いまの Ollama は、ローカルモデルだけでなく、処理を Ollama のクラウドへ預けるクラウドモデルや Web 検索といったオンライン機能も持っています。公式 FAQ は、ローカル実行時はプロンプトやデータを見ない一方、クラウドホストのモデルを使うときはプロンプトと応答を処理する（保存・学習はしない）と明記しています。つまり機密情報を扱う用途では、ローカルモデルだけを使い、クラウド機能を無効化したうえで運用するのが原則になります。
クラウド機能は、環境変数 OLLAMA_NO_CLOUD=1 で無効化できます。設定ファイル（~/.ollama/server.json）で指定する場合は、次のように書きます。
{ "disable_ollama_cloud": true }設定後に Ollama を再起動し、ログに Ollama cloud disabled: true が出ていれば、クラウドモデルと Web 検索が無効になった状態です。これで、Ollama 側のクラウド機能を切ってローカルモデルだけを使う構成にできます。ただし OLLAMA_NO_CLOUD=1 が担保するのは Ollama 側のクラウド機能の無効化までで、社内アプリやリバースプロキシ側のログ・外部連携まで保証するものではありません。そこは別途、自分たちで確認が必要です。社内向けに API サーバーを立てるなら、この無効化は、ネットワーク公開の設定と同じくらい優先度の高い作業だと考えてください。
性能の面で押さえておきたいのは、次の点です。
– 同時リクエストは、十分な RAM／VRAM があれば並列処理できる（並列数は OLLAMA_NUM_PARALLEL で制御、既定は1）。メモリが足りないと新しいリクエストはキュー待ちになり、OLLAMA_MAX_QUEUE（既定512）を超えると 503 エラーが返る
– 別モデルへ切り替えると再ロードが走り、その間は応答が遅延する
– 長い生成にはタイムアウトを長めに設定する
落とし穴を避けるコツは、社内ネットワークが前提でも、ファイアウォールで接続元を絞り、プロセスの死活監視で停止に気づけるようにしておくことです。基盤として使う以上、止まったまま放置されない仕組みは欠かせません。入力してよいデータの区分、アクセス権限、ログの保存方針まで決めておけば、安心して任せられる土台になります。
よくある質問
Q. Ollama の利用に料金はかかりますか？
ローカル実行に使う Ollama 本体は無料で、公式 GitHub リポジトリは MIT ライセンスで公開されています。ローカル API の利用にトークン従量課金もありません。コストは動かすマシンの電気代とハードウェアが中心です。ただし、クラウドモデルなどのオンライン機能はローカル運用とは別建てなので、使う場合は料金や条件を公式で確認してください。
Q. 社外からアクセスできますか？
既定は localhost のみで待ち受けます。社外公開は推奨されません。外部から使うなら VPN 経由や、認証付きプロキシを挟む構成が前提になります。
Q. ローカルで動かせば、社内データは絶対に外に出ませんか？
ローカルモデルだけを使う限り、推論データは外部の API へ送られません。ただし、現在の Ollama にはクラウドモデルや Web 検索といったオンライン機能もあり、それらを使うとプロンプトと応答がクラウドで処理されます。機密データを扱うなら、OLLAMA_NO_CLOUD=1 などでクラウド機能を無効化したうえで運用してください。
Q. OpenAI 向けに書いたコードはそのまま動きますか？
OpenAI 互換エンドポイントを使えば、シンプルな実装は base_url の差し替えだけで流用できます。ただし全機能が完全互換ではなく、Responses API の previous_response_id や conversation など、一部の状態管理機能には対応していません。高度な機能を使う場合は、公式ドキュメントで対応範囲を確認してください。
まとめ
Ollama を API サーバーとして常駐させ、ローカルモデルだけを使ってクラウド機能を無効化すれば、推論データを Ollama のクラウド機能や外部の推論 API へ送らずに処理できます。ローカル推論ならトークンの従量課金もなく、LLM の機能を業務システムに組み込めます。OpenAI 互換 API があるおかげで、シンプルな実装なら、既存コードの接続先を変えるだけで移行しやすいのも利点です。ネットワークへ公開するときは、認証付きプロキシとアクセス制限、ログの扱い、入力してよいデータの区分まであわせて設計しておけば、業務利用の基盤にしやすくなります。まずは軽量モデルを1つ取得し、curl で疎通を確認するところから始めてみてください。そこから先、社内ドキュメントを検索・要約させたいなら、ローカル RAG を組む記事が次の一歩になります。
