Prime Agent Ollama 2026：接続障害の切り分け

Ollamaのモデルは表示されるのに、Prime Agentのコーディング作業だけが止まる。

最短の解決策は再インストールではありません。2026年8月11日時点では、Ollamaサービス、接続先URL、models.json、API互換パラメーター、モデル能力の5層に分けて、1項目ずつ確認してください。基礎APIが正常なのにコード作業が安定しないなら、モデルを変更するか、切断後も継続できる独立環境へ移す判断が必要です。

このページは、Prime AgentでOllamaのモデルが見えない個人開発者、接続後にリクエストエラーやツール不使用が起きるAIエンジニア、そして遠隔環境で長時間処理を運用したいチーム向けです。

※最終更新：2026年8月11日。Prime Agentの公式リポジトリ、Providers・Custom Models関連文書、Ollama公式API・FAQ・トラブルシューティング文書を再確認しています。設定項目は今後のリリースで変わる可能性があります。

まず5層の故障線を分けて確認します

Prime Agentはmodels.jsonを使って、Ollamaのようなカスタムプロバイダーを登録できます。公式のProviders文書でも、OpenAI Completionsなど対応APIを話すサービスをカスタムプロバイダーとして追加できると説明されています。

ただし、次の問題は別々に見えるため、最初から設定全体を作り直すと原因が消えます。

1. Ollama自体が起動していない。
2. Prime Agentから見たlocalhostが、Ollamaのあるホストを指していない。
3. models.jsonが別の場所にある、またはJSONとして読めない。
4. APIは応答するが、developer roleやストリーム用フィールドなどを受け付けない。
5. モデルは会話できるが、ツール呼び出しや長いコーディング作業を安定して処理できない。

Prime Agentはファイル操作やシェル実行をモデル経由で行う設計です。単発の文章応答だけで「接続成功」と判断しないことが重要です。公式リポジトリでも、長時間セッション、バックグラウンド実行、再接続を前提にした機能が説明されています。(Prime Agent公式リポジトリ)

0〜5分：Ollamaサービスとモデル本体を分離します

最初にPrime Agentを閉じ、Ollamaを単独で確認します。

ollama list
curl -i http://127.0.0.1:11434/api/tags
curl -i http://127.0.0.1:11434/v1/models

ollama listに対象モデルがなければ、設定を直しても表示されません。モデル名は、たとえばqwen2.5-coder:7bのように、タグまで含めて実際の出力を使います。llama3とllama3:latestを別名として扱う設定もあるため、画面に表示されたIDをそのまま転記してください。

次に、モデルを指定した最小リクエストを送ります。

curl http://127.0.0.1:11434/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer ollama' \
  -d '{
    "model": "MODEL_ID",
    "messages": [
      {"role": "user", "content": "短く応答してください"}
    ],
    "stream": false
  }'

HTTP応答とJSON本文が返れば、少なくともOllamaのOpenAI互換経路は動いています。Ollama公式文書では、互換エンドポイントとして/v1/chat/completionsと/v1/modelsが案内され、APIキーはクライアント側で要求されてもOllama側では無視されると説明されています。(OllamaのOpenAI互換API)

404ならパス、401なら中継や認証設定、404 model not foundならモデルID、接続拒否ならサービスまたは待ち受けアドレスを疑います。

5〜10分：models.jsonの読み込み先と名前を確認します

モデルが単独で応答するのにPrime Agentで見えない場合は、models.jsonを確認します。公式文書に記載された基本構造を、利用中のバージョンに合わせて確認してください。

{
  "providers": {
    "ollama": {
      "baseUrl": "http://127.0.0.1:11434/v1",
      "api": "openai-completions",
      "apiKey": "ollama",
      "models": [
        {
          "id": "MODEL_ID"
        }
      ]
    }
  }
}

確認する順番は次のとおりです。

• ~/.prime/agent/models.jsonを編集しているか。
• ファイル名の大文字・小文字が正しいか。
• JSONの末尾カンマ、引用符、括弧が壊れていないか。
• providerの識別子と、モデル配列のidが正しいか。
• baseUrlに/v1を付ける仕様か。
• Prime Agentを再起動し、モデル一覧を再読み込みしたか。

構文だけなら、次で検査できます。

python -m json.tool ~/.prime/agent/models.json

エラーが出れば、Prime AgentではなくJSONを先に直します。エラーが出なくても、編集したファイルが実際に読み込まれているとは限りません。ファイルの更新時刻、Prime Agent起動時のログ、モデル一覧の変化を一緒に記録してください。

Custom Models文書では、プロバイダー全体に互換設定を置く方法と、特定モデルだけに上書きを置く方法が分けられています。全モデルへ一括適用する設定と、問題のモデルだけに適用する設定を混ぜないことが、切り分けを短くします。(Prime AgentのProviders文書) (Prime AgentのCustom Models文書)

10〜15分：baseUrlとlocalhostの意味を分けます

同じ端末でPrime AgentとOllamaを動かしているなら、次のようなURLから試します。

http://127.0.0.1:11434/v1

localhostでも動くことはありますが、名前解決やIPv4・IPv6の違いを避けるため、最初の確認では127.0.0.1を使う方が結果を読みやすくなります。

一方、Prime Agentをコンテナ、OllamaをホストOSで動かす場合、コンテナ内のlocalhostはホストOSではありません。Prime Agentを別のMacやサーバーで動かしている場合も同様で、Ollama側から見えるアドレスと、Prime Agent側から到達できるアドレスは一致しません。

次のコマンドを、Prime Agentが動く環境から実行します。

curl -i http://OLLAMA_HOST:11434/v1/models

ここで重要なのは、pingではなくHTTP応答を確認することです。OllamaのAPIが200を返し、対象モデルIDを含むなら、名前解決、ポート、基本経路は通っています。Ollama公式のトラブルシューティングでは、Macのサーバーログを~/.ollama/logs/server.logで確認する方法が示されています。(Ollamaのトラブルシューティング)

遠隔接続では、Ollamaを外部へ無制限に公開しないでください。SSHトンネル、VPN、アクセス制御付きの中継など、誰がAPIへ到達できるかを限定した経路を選びます。URLを修正した後は、Prime Agent側とOllama側のログを同じ時刻で照合してください。

15〜20分：API互換性は1項目ずつ下げます

基礎応答は成功するのに、Prime Agentだけが400を返す場合、モデル全体を「非対応」と決めつけないでください。実際には、次のようなリクエスト項目のどれかが原因になっている可能性があります。

• developer role
• reasoning_effort
• stream_options.include_usage
• ツール定義やtool_choice
• ストリーム形式、終了理由、JSON構造

Ollamaの現行OpenAI互換文書では、ストリーミング、JSONモード、ツール、推論制御、stream_options.include_usageなどの対応項目が整理されています。ただし、利用しているOllamaの版、モデル、Prime Agent側の送信方式によって結果が変わるため、文書上の対応表だけで実運用の成功を保証しないでください。(Ollamaの互換フィールド一覧)

修正は一度に1項目だけ行います。まず通常のユーザー・アシスタント会話で通す、次にストリームを確認する、その後にツール、最後に推論関連のフィールドを加える順番です。developer roleで拒否されたなら互換設定で無効化できるかを確認し、全プロバイダーへ影響する設定ではなく、Ollamaのモデル単位で試します。

変更ごとに、次の4点を記録します。

• 変更したフィールド。
• HTTPステータス。
• レスポンス本文のエラー。
• Prime AgentとOllamaの両側ログ。

「接続できた」という状態と、「Prime Agentが必要な形式で応答を解釈できた」という状態は別です。

20〜30分：会話成功とコーディング成功を分けます

典型的な失敗は、Ollamaの画面や単純なcurlで会話できたため、Prime Agentのコーディング用途にも十分だと判断することです。コーディングエージェントでは、指示の保持、ファイル内容の正確な参照、ツール呼び出し、結果を受けた再試行が必要になります。

次の順番で小さく検証してください。

1. 読み取り：作業ディレクトリのファイル一覧を取得させ、存在しないファイルを作らないか確認します。
2. 参照：短いソースファイルを読み取り、関数名や条件分岐を正しく説明できるか確認します。
3. 小変更：コメント追加など、差分が明確な変更を1つだけ依頼します。
4. コマンド実行：既存のテストや静的解析コマンドを1つ実行させます。
5. 修正と再実行：意図的に小さな失敗を与え、エラーを読んで再実行できるか確認します。

ファイル変更が起きない、JSON風のツール呼び出しを文章として出す、存在しない成功結果を報告する、といった症状が同じ段階で再現するなら、Prime Agentの確定バグとは限りません。モデルのツール利用能力や指示追従能力が不足している可能性があります。失敗を隠すために「実行済み」と扱うのではなく、モデルを変更するか、作業を小さな単位へ分割してください。

長時間処理は状態・メモリ・継続性を別々に見ます

処理が止まったとき、ネットワークだけを疑うのは危険です。次の順番で確認します。

• Ollamaのログにモデル読み込み、メモリ不足、503、接続終了がないか。
• ollama psで対象モデルが実行中か。
• Prime Agentのセッション状態、ワーカー、バックグラウンド処理が生きているか。
• コンテキストが増え続けていないか。
• 複数のサブタスクを同時に走らせていないか。
• ホストのメモリ圧迫やスワップ増加が起きていないか。

OllamaのFAQでは、既定のコンテキスト長やkeep_aliveの扱い、リクエスト過多による503が説明されています。モデルを毎回ロードし直している場合は、初回だけ遅いのか、アイドル後にも遅いのかを分けて観察してください。(Ollama公式FAQ)

Prime Agent側では、公式リポジトリの案内にあるprime-agent status、prime-agent agents、prime-agent attachなどを使い、端末の表示だけでなくセッションの実体を確認します。端末を閉じた後も処理を継続したい場合は、セッション、Ollamaプロセス、作業ディレクトリの3つが同じライフサイクルで維持される構成にしてください。(Prime Agentの長時間実行文書)

復旧後は段階的な受け入れ基準を残します

修正後にいきなり大規模なリファクタリングを任せるのではなく、次のマイルストーンで合格を記録します。

記録には、Prime Agentのバージョン、Ollamaのバージョン、モデルID、実行ホスト、models.jsonの設定要約、ログの保存場所、再現した失敗段階を残します。これがないと、アップデート後に同じ問題が起きたとき、設定変更が原因なのかモデル更新が原因なのか判断できません。

本機、独立環境、Macレンタルを比較して決めます

五層の切り分けで設定問題が消えた後も、長時間処理が安定しないなら、配置場所そのものを見直します。

手元の環境では、作業中にスリープやアプリ終了が起きやすく、OllamaとPrime Agentが同じメモリを奪い合います。一般的な遠隔サーバーでは、Mac固有の開発環境や既存の運用手順を別途整える必要があります。

一方、短期検証や継続運用の切り替えでは、日本国内のMacレンタル環境や、利用場所に応じた米国西部のMacレンタルを比較候補にできます。国や地域を変える場合は、Prime AgentとOllamaの間の遅延、SSH接続、ログ保存先、端末切断後の継続性を先に確認してください。

よくある確認事項

Prime AgentでOllamaのモデルが表示されない場合

ollama list、/api/tags、/v1/modelsの順で確認し、モデル本体が存在することを確定させます。その後、models.jsonのパス、JSON構文、provider識別子、モデルID、再起動の有無を確認します。独立APIが正常でも、設定ファイルの読み込み失敗や名前の不一致なら一覧には出ません。

baseUrlはどのURLにすればよいか

同じホストならhttp://127.0.0.1:11434/v1から試します。Prime Agentがコンテナや別ホストにある場合、localhostはOllamaのホストを意味しません。Prime Agentの実行環境から/v1/modelsへリクエストし、200応答が得られるアドレスを使います。

Ollamaでは会話できるのにコーディングできない場合

読み取り、小変更、テスト実行の順に確認します。文章応答が成功しても、ツール呼び出し、エラーからの再試行、長い指示の保持まで成功するとは限りません。失敗が同じ段階で再現するなら、設定を増やすよりモデル変更または作業分割を優先します。

処理が止まる、断流する場合

モデルの初回ロード、コンテキスト増加、同時実行、メモリ不足、503、ストリーム互換性を切り分けます。Prime Agentのセッション状態、Ollamaのserver.log、OSのリソース記録を同じ時刻で照合し、ネットワークだけに原因を限定しないでください。

遠隔環境からOllamaへ接続する場合

Ollamaが127.0.0.1だけで待ち受けていないか、遠隔ホストのポートへ到達できるか、ファイアウォールで遮断されていないかを確認します。外部へ直接公開するのではなく、SSHトンネルやVPNなど、認証と暗号化を含む経路を選びます。端末切断後もPrime AgentのセッションとOllamaが継続するかも確認してください。

設定が正しいのに手元のMacで処理が止まる場合、原因はPrime AgentやOllamaではなく、スリープ、メモリ競合、端末切断、単一マシンへの依存に移っています。自前運用は物理ファイルやローカル機器を扱える一方、長時間処理の維持と監視を自分で担う必要があります。短期の検証や継続稼働を優先するなら、KvmkitのMacレンタルを含む独立したMac算力環境と比較し、同じ5段階の受け入れ試験を通してから移行するのが安全です。まずはMac環境の選択肢を確認し、必要な期間と接続経路が決まってから導入を判断してください。

よくある質問