Ollama APIをlocalhostで使う方法｜最初のリクエストを確認する

Ollamaでモデルを動かせたら、次はlocalhostのAPIへ一つだけリクエストを送ってみると、自作アプリやRAGへつなぐための基準を作れる。

Ollamaの公式API資料では、独自APIの基準となるURLとして次が案内されている。

http://localhost:11434/api

ただし、環境変数やネットワーク設定を変更している場合は、自分の設定を優先する。

図を拡大して見る

図: 処理や設定の流れを1枚に整理。実際の操作条件は本文で確認する。

まずOllamaとモデルが動いているか確認する

APIの問題を調べる前に、Ollama自体が動き、指定するモデルを認識しているか確認する。

Ollamaが起動している
        ↓
指定したモデルをOllamaが認識している
        ↓
APIへリクエストを送る

モデルをまだ取得していない状態で、送信するJSONだけを直し続けても解決しない。

目的に合うエンドポイントを一つ選ぶ

Ollamaには/api/...で始まる独自APIがある。文章生成とチャットでは、使うエンドポイントや送信内容が同じとは限らない。

最初は公式資料を見ながら一つだけ選ぶ。

基準URL: http://localhost:11434/api
エンドポイント: /generate または /chat など
モデル: 自分が取得・実行したモデル名

OpenAI互換APIは別の入口なので、独自APIと同じ設定だと決めつけない。

/api/generateへ最小の1本を送る

/api/generateを試すなら、最初はモデル名と短い入力だけにする。curlを使えるシェルでは、たとえば次のように送れる。

curl http://localhost:11434/api/generate -d '{
  "model": "gemma4",
  "prompt": "日本語で一文だけ返してください"
}'

gemma4は例なので、手元で取得済みのモデル名へ置き換える。

これで返答が来れば、少なくともOllamaサーバーへの接続、/api/generateのパス、モデル名、JSON送信の組み合わせではリクエストが成立していると切り分けられる。逆に失敗した場合も、どこから確認するかを狭めやすい。

Ollamaの生成APIは既定でストリーミングするため、複数行に分かれてJSONが返っても、それだけで失敗とは限らない。まずこの最小構成で返答を確認してから、必要な設定を一つずつ追加する。

最初のリクエストは小さくする

最初から多数の設定を追加せず、モデル名と短い入力を中心にして返答が得られる状態を作る。

PowerShellとcurlでは引用符の扱いが異なるため、送信しているJSONが壊れていないかも確認する。

失敗した場合は、次の順番で切り分ける。

1. ホストとポートへ接続できるか
2. エンドポイントのパスは正しいか
3. モデル名は正しいか
4. JSONの書式は正しいか
5. そのエンドポイントで必要な項目がそろっているか

ストリーミングの返り方を確認する

Ollamaの生成APIでは、生成途中の内容が複数回に分かれて返る場合がある。

ターミナルへ複数行のJSONが順番に表示されても、それだけで壊れた応答とは限らない。

自作プログラムへ組み込む前に、

• 一回ごとのデータに何が入るか
• 完了を何で判断するか
• ストリーミングを無効にできるか
• エラーはどの形式で返るか

を確認する。

まずターミナル上で返り方を見てから実装すると、途中データを完成した回答と誤認しにくい。

localhostだけの利用とLAN公開を分ける

OllamaのFAQでは、通常はループバックアドレスを使う設定が案内されている。

これは同じPC内で使うときの初期的な境界であり、「どこへ公開しても安全」という意味ではない。

LANや別端末から接続できるようにする場合は、待ち受け先、リバースプロキシ、認証、ファイアウォールなどを別に確認する。

成功したリクエストを基準として保存する

一つ成功したら、そのコマンドや送信内容を残す。

Ollamaのバージョン:
モデル:
エンドポイント:
送信内容:
ストリーミング:
返答の状態:
確認日:

その状態からPythonやOpen WebUI、RAGへつなげば、問題が起きても「Ollama API自体はこの条件で動く」と切り分けられる。

最初の目標は複雑な連携ではなく、localhostのOllama APIへ一つリクエストを送り、どのように返答が来るか自分で確認できる状態にすることだ。

APIへcurlで送る基本から整理したい場合は、ローカルLLM APIへcurlで最初のリクエストを送る方法も確認できる。

接続に失敗したら、返ってきたものから確認先を選ぶ

Ollamaへ届かなかったのか、届いた要求にエラーが返ったのかを先に分ける。モデル名・ポート・JSONを同時に変えると、どの変更が必要だったか分からなくなる。

観測した状態	次に確認すること
接続拒否、または応答に届く前のタイムアウト	Ollamaアプリの起動、要求を送るホストとポート、送信元を確認する。まだモデルの生成能力を判断する段階ではない
HTTP 400とJSONのエラー	送信JSONの書式と必須項目を見る。文字列の引用符がシェルで崩れていないかも確認する
HTTP 404	APIのパスと、エラー本文に示された対象を見る。公式資料ではモデル不在も404の例なので、パス違いだけと決めつけない
応答開始後、途中のJSONにerrorがある	先頭のHTTP成功だけで全体成功にしない。ストリーミングの途中エラーを保存して読む

公式APIエラー資料では、エラー本文をJSONのerror項目で返すとしている。また、応答が始まった後のストリーミングエラーでは、すでに返したHTTPステータスは変更されない。自作アプリでも、接続できたかだけでなく最後までエラーがないかを見る必要がある。

Windowsで状況が分からなければ、公式Windows資料とトラブルシューティング資料が示す%LOCALAPPDATA%\Ollama\server.logを、失敗した時刻と照合する。モデル保存先とは別の場所だ。ログ全体を外部へ貼る前に、個人情報や認証情報が含まれていないか確認する。

要求を送るアプリがDocker内にある場合は、ホストPC上のPowerShellと同じ接続先表記で動くと決めつけない。Open WebUIからホストのOllamaへ接続する手順へ進み、実行場所に合う設定を確認する。接続失敗を理由に、すぐLAN公開やファイアウォール開放へ進める必要はない。

モデルがまだ取得できていないことが分かったら、APIのJSONを直し続けず、Ollamaのダウンロード失敗を確認する手順へ切り替える。この表は公式のエラー契約を使った切り分けであり、今回すべての故障条件を実機で再現した結果ではない。