結論から言うと、Ollamaを起動するとローカルにhttp://localhost:11434というHTTP APIサーバーが立ち上がり、curl・Python・任意のHTTPクライアントからローカルLLMを呼び出せます。中心になるのは文章を生成する/api/generateと、会話形式の/api/chatの2つです。
「APIといっても難しい設定が必要なのでは?」と身構える必要はありません。APIキーも認証も不要で、curl1発で応答が返ってきます。本記事では、実際に稼働中のOllama 0.30.8に対して各エンドポイントをcurlとPythonから叩き、返ってきた生のレスポンスと実測した応答速度をそのままお見せします。
この記事のポイント
- OllamaのAPIは
http://localhost:11434で動き、/api/(ネイティブ)と/v1/(OpenAI互換)の2系統がある - 文章生成は
/api/generate、会話は/api/chat。どちらもJSONをPOSTするだけ "stream":trueにするとトークンが逐次返り、初トークンは実測149msで届く- レスポンスに
eval_count・total_durationが含まれ、生成速度を自分で計算できる(実測233 tokens/sec) - Pythonは
requestsでも公式ollamaライブラリでも、base_urlを変えたopenaiライブラリでも呼べる
目次
- OllamaのAPIとは(ポートと2系統のエンドポイント)
- curlで叩く基本:/api/generate と /api/chat
- ストリーミングで逐次トークンを受け取る
- モデル一覧と稼働状態を確認する
- 実測したAPIのパフォーマンス
- Pythonから呼び出す3つの方法
- OpenAI互換の /v1/chat/completions
- 対応エンドポイント一覧
- よくあるエラーと解決策
- まとめ
検証環境
Ollama 0.30.8 / ローカルAPI http://localhost:11434 / 生成モデル qwen2.5:0.5b・埋め込みモデル nomic-embed-text / Python検証は ubuntu:24.04 Dockerコンテナ / 2026年6月15日に実測
OllamaのAPIとは
Ollamaは「ターミナルでollama runするツール」というイメージが強いですが、実体はバックグラウンドで常時HTTP APIサーバーを動かしているソフトウェアです。ollama serve(またはアプリ起動)の時点で、11434番ポートでリクエストを待ち受けています。
このAPIには2系統あります。1つはOllama独自の/api/系(/api/generate、/api/chatなど)、もう1つはOpenAI APIと同じ形式の/v1/系(/v1/chat/completionsなど)です。どちらも同じ11434ポートで同時に動いています。
まずサーバーが生きているか、curlでルートURLとバージョンを叩いて確認します。

ルートURLはOllama is runningというプレーンテキストを返し、/api/versionは{"version":"0.30.8"}というJSONを返してきました。ブラウザでhttp://localhost:11434/を開いても同じく「Ollama is running」が表示されます。

curlで叩く基本:/api/generate と /api/chat
APIの中心はこの2つです。/api/generateは1回きりのプロンプトに答える単発生成、/api/chatはmessages配列で会話の文脈を渡す形式です。どちらもPOSTでJSONを送るだけです。
①単発生成:/api/generate
最小構成はmodelとpromptの2つだけです。"stream":falseを付けると、応答が完成してから1つのJSONで返ってきます(付けないとデフォルトでストリーミングになります)。
“model”: “qwen2.5:0.5b”,
“prompt”: “Linuxとは何か1文で説明して”,
“stream”: false }’ | jq -r ‘.response’
Linuxは、オープンソースのソフトウェア開発ツールです。主な特徴と
しては、ユーザが自由にプログラムを導入できることです…
応答本文は.responseフィールドに入っています。さらに、このJSONには生成にかかった統計情報も一緒に返ってきます。jqでメタデータだけ抜き出してみます。
| jq ‘{eval_count, prompt_eval_count, total_duration, done_reason}’
{
“eval_count”: 265,
“prompt_eval_count”: 45,
“total_duration”: 1345900000,
“done_reason”: “stop”
}
eval_countは生成したトークン数、total_durationはナノ秒単位の総処理時間です。eval_count ÷ eval_durationで生成速度を計算でき、この回は233 tokens/secでした(小型モデルqwen2.5:0.5bをCPUで実行)。
②会話形式:/api/chat
ChatGPTのように文脈を持った会話をしたいときは/api/chatを使います。promptではなくmessages配列で、role(system/user/assistant)とcontentを渡します。
“model”: “qwen2.5:0.5b”,
“messages”: [
{“role”: “system”, “content”: “簡潔に答えて”},
{“role”: “user”, “content”: “SSHのデフォルトポート番号は?”}
],
“stream”: false }’ | jq -r ‘.message.content’
22
応答は.message.contentに入ります(/api/generateの.responseとフィールド名が違う点に注意です)。この回はtotal_durationが136ms、生成トークンは3つでした。会話を続けるときは、返ってきたassistantの発言をmessagesに追加して再送します。

ストリーミングで逐次トークンを受け取る
"stream":true(またはstreamを省略)にすると、トークンが生成されるたびに改行区切りのJSON(NDJSON)が1行ずつ流れてきます。チャットUIで文字が少しずつ出てくるのと同じ挙動です。
{“model”:”qwen2.5:0.5b”,”response”:”はい”,”done”:false}
{“model”:”qwen2.5:0.5b”,”response”:”、”,”done”:false}
{“model”:”qwen2.5:0.5b”,”response”:”1″,”done”:false}
… (1トークンずつ続く)
{“model”:”qwen2.5:0.5b”,”response”:””,”done”:true,”done_reason”:”stop”}
各行のresponseをつなげると完全な文章になります。最後の行は"done":trueになり、ここで生成終了です。実測では最初のトークンが149msで届き、全体で23チャンク・250msでした。体感上のレスポンスが速く感じられるのがストリーミングの利点です。
stream省略時のデフォルトに注意
streamを指定しないとOllamaはストリーミングがデフォルトです。1つのJSONとしてパースしようとすると「複数行返ってきて壊れる」ことがあります。1回で受け取りたいときは必ず"stream":falseを明示しましょう。
モデル一覧と稼働状態を確認する
どのモデルが使えるか、いま何が動いているかもAPIで取れます。これらはGETなので、ブラウザでURLを開くだけでも確認できます。
$ curl -s http://localhost:11434/api/tags | jq ‘.models | length’
19
# いま起動中(メモリに載っている)モデルとVRAM占有
$ curl -s http://localhost:11434/api/ps | jq -r ‘.models[] | “\(.name) \(.size_vram)”‘
qwen2.5:0.5b 476MB
nomic-embed-text:latest 370MB
/api/tagsはダウンロード済みの全モデル、/api/psは実際にメモリにロードされて待機しているモデルだけを返します。/api/psでVRAM占有を確認できるので、メモリ不足のトラブル切り分けに便利です。ブラウザで/api/tagsを開くと、次のようにJSONがそのまま表示されます。

実測したAPIのパフォーマンス
ローカルAPIの強みは、なんといってもネットワーク遅延がほぼゼロな点です。実際に各エンドポイントを計測しました。

/api/versionへの往復はわずか平均1.59ms(3回計測、1.52〜1.72ms)。インターネット越しのクラウドAPI(通常100〜500ms以上)とは桁違いの速さです。生成自体も小型モデルなら233 tokens/sec出ており、初トークンも149msで届きます。データが外部に一切出ないプライバシー面のメリットと合わせて、ローカルAPIは試作・社内ツール向きです。
Pythonから呼び出す3つの方法
Pythonからは大きく3通りあります。ここではubuntu:24.04のDockerコンテナを立てて、実際にライブラリをインストールして動かした結果を載せます。
①requestsで素朴に叩く
追加ライブラリ不要で、requestsだけで叩けます。APIの構造がそのまま見えるので最初の理解に向いています。
r = requests.post(“http://localhost:11434/api/chat”, json={
“model”: “qwen2.5:0.5b”,
“messages”: [{“role”: “user”, “content”: “Reply with the single word: OK”}],
“stream”: False,
})
print(r.json()[“message”][“content”])
# → OK
②公式ollamaライブラリを使う
公式のollamaパッケージを使うと、より短く書けます。Ubuntu 24.04ではPEP 668の制約があるため、pip installに--break-system-packagesが必要です(本番は仮想環境を推奨)。実際にコンテナでインストールして動かしました。
Successfully installed ollama-… requests-2.34.2
$ python3 – <<'PY'
from ollama import Client
c = Client(host=”http://host.docker.internal:11434″)
r = c.chat(model=”qwen2.5:0.5b”,
messages=[{“role”:”user”,”content”:”Reply with the single word: OK”}])
print(r[“message”][“content”], r.get(“done_reason”))
PY
OK stop
③openaiライブラリでbase_urlを差し替える
すでにOpenAI SDKでコードを書いているなら、base_urlをhttp://localhost:11434/v1に向けるだけでOllamaに切り替わります。これは次の章で詳しく扱います。
OpenAI互換の /v1/chat/completions
Ollamaは/v1/chat/completionsというOpenAI APIと同じ形式のエンドポイントも内蔵しています。実際に叩くと、レスポンスもOpenAIと同じ構造で返ってきます。
“model”: “qwen2.5:0.5b”,
“messages”: [{“role”:”user”,”content”:”Say hello in one word.”}],
“max_tokens”: 10 }’ | jq ‘{object, system_fingerprint, usage}’
{
“object”: “chat.completion”,
“system_fingerprint”: “fp_ollama”,
“usage”: {
“prompt_tokens”: 35,
“completion_tokens”: 3,
“total_tokens”: 38
}
}
objectがchat.completion、usageにトークン数が入る構造はOpenAI APIと完全に同じです。system_fingerprintにfp_ollamaが入っているのが、Ollamaで動いている目印です。openai PythonライブラリならOpenAI(base_url="http://localhost:11434/v1", api_key="ollama")と書けば、既存コードがそのまま動きます(api_keyは認証に使われないので任意の文字列で構いません)。
対応エンドポイント一覧
今回Ollama 0.30.8で実際に叩いて確認したエンドポイントをまとめます。

テキスト生成は/api/generateと/api/chat、ベクトル化(RAG用途)は/api/embedでnomic-embed-textを使うと768次元の埋め込みが取れます。OpenAI互換が必要なら/v1/系を使う、という使い分けになります。
実アプリと組み合わせる(Open WebUI)
このAPIを土台にした代表的なアプリがOpen WebUIです。ChatGPTライクなブラウザUIから、裏でOllamaのAPIを叩いてローカルモデルとチャットできます。OLLAMA_BASE_URLにOllamaのアドレスを渡して起動すると、登録済みモデルがそのままUIに並びます。

画面上部のモデル選択に、APIの/api/tagsで見えていたモデルがそのまま表示されているのが分かります。自分でAPIを叩くアプリを作るときも、この「/api/tagsでモデル一覧を取り、/api/chatで会話する」という流れが基本形になります。
よくあるエラーと解決策
①Connection refused(接続できない)
Ollamaのサーバーが起動していません。ollama serveを実行するか、Dockerで動かしているならdocker psでコンテナが上がっているか確認してください。ollama listがエラーになる場合も同じ原因です。
②model not found(モデルが無い)
リクエストしたmodelがダウンロードされていません。ollama pull llama3.2:3bで先に取得するか、/api/tagsで正しいモデル名を確認してください。タグ(:3bなど)まで含めて一致している必要があります。
③Dockerコンテナ内からホストのOllamaに繋ぐ
別のコンテナ(自作アプリなど)からホストのOllamaに接続するとき、localhostはコンテナ自身を指してしまうので繋がりません。ホストを指すhost.docker.internalを使います。実際にコンテナから叩いて確認しました。
bash -c ‘apt-get install -y curl -qq >/dev/null; \
curl -s http://host.docker.internal:11434/api/version’
{“version”:”0.30.8″}
Linuxホストの場合は--add-host host.docker.internal:host-gatewayを付けると名前解決できます(上の実行例もこの方法です)。あるいはdocker0のゲートウェイIP(多くは172.17.0.1)を直接指定する手もあります。
まとめ
- OllamaのAPIは
http://localhost:11434で常時動き、認証不要でcurl・Python・任意のHTTPから叩ける - 単発生成は
/api/generate(.response)、会話は/api/chat(.message.content)が基本 "stream":trueで逐次トークンを受信。省略時もデフォルトでストリーミングになる点に注意- レスポンスの
eval_count・total_durationから生成速度を計算できる(実測233 tokens/sec、初トークン149ms) - OpenAI互換が必要なら
/v1/chat/completions(system_fingerprint=fp_ollama)を使う
ローカルで動かしたAPIを24時間動くサーバーとして公開したくなったら、VPS上にOllamaを立てるのが定番です。メモリ(RAM)の大きいプランを選ぶと、より大きなモデルもAPIから呼べるようになります。Ollama向けのスペックの選び方は関連記事も参考にしてください。
→ あわせて読みたい:



コメント