Ollama と Antigravity の接続そのものは通っているのに、応答が途中でぷつりと切れる。長いリファクタリング指示を出すと数十秒無反応になって最終的に「Stream closed」で落ちる。こうした症状は、私も Gemma 4 を手元で回し始めた頃に何度も踏みました。そして気づいたのは、「接続できない」系のトラブルシューティング記事では ほとんど触れられていない別レイヤーの問題 が原因になっているケースが多いということです。
接続はできているのに 生成の途中で切れる・固まる という症状に絞って、切り分け手順と具体的な設定変更を実例とともに整理しました。既に ollama list で接続確認ができている方を想定しています。そもそも接続できない場合は ローカルLLM接続エラー診断ガイド を先にご覧ください。
私自身、個人開発の合間にローカルモデルへ切り替える時間帯があり、クラウド API の課金を気にせず長い試行錯誤を回すために Ollama を常用しています。だからこそ「途中で切れる」は生産性を静かに削る、地味だが痛い問題でした。ここでは、その痛みを二度と踏まないための恒久対策まで、一気通貫で整理しました。
「接続エラー」と「途中切断」は別問題として切り分ける
まず前提として、ローカル LLM 連携のトラブルは大きく3層に分けられます。層を混同したまま設定を触ると、的外れな修正で時間を溶かします。
接続層（TCP・ポート・ファイアウォール）: curl http://localhost:11434/api/tags で応答が返るか
モデルロード層（VRAM・メモリ）: Ollama 単体で ollama run gemma-4:8b が一文字ずつ出るか
ストリーミング層（長時間推論の維持）: Antigravity から 30 秒以上かかる指示を出して途中で切れないか
接続エラー系の既存記事はほぼ1と2を扱っています。この記事が対象にするのは 3 の層です。症状が「最初は出力されるが途中で止まる」「短い指示は通るが長い指示で落ちる」なら、ここに該当します。
切り分けを最短にするために、症状とログの対応関係を先に一枚にしておきます。ここを頭に入れておくと、以降の各原因の当たりをつけやすくなります。
観察された症状 ログに出る手がかり 疑うべき原因
数分の沈黙後に再開が遅い・落ちる Ollama: model stopped: timeout 原因1: keep-alive 長い入力で応答が途中から破綻 Ollama: context length exceeded 原因2: num_ctx 最初のトークンが出る前に切れる Antigravity: stream aborted 原因3: クライアントタイムアウト 出力途中の長い沈黙で切れる Ollama は正常完了ログ 原因3または4: 経路の切断
原因1: keep-alive タイムアウトによる早期アンロード
Ollama のデフォルト挙動で意外と詰まりやすいのが OLLAMA_KEEP_ALIVE です。これはモデルをメモリに保持する時間で、デフォルトは 5 分。Antigravity のエージェントが途中で考え込んで 5 分以上静止すると、バックグラウンドでモデルが解放され、再開時にロードし直しで大幅に遅延、最悪の場合タイムアウトで切られます。
長い推論を安定させたい場合は、Ollama を起動する環境変数を明示的に伸ばすのが実用的です。macOS で launchd から起動している場合は launchctl 経由で設定します。
# macOS: Ollama サービスに環境変数を渡す # Ollama.app を使っている場合、設定 → Advanced → Environment Variables で設定可能 # CLI からやるなら以下 launchctl setenv OLLAMA_KEEP_ALIVE "30m" launchctl setenv OLLAMA_MAX_LOADED_MODELS "2"
# 変更後は Ollama を再起動 osascript -e 'quit app "Ollama"' open -a Ollama
# 期待動作: 30分間はモデルがメモリに残り、 # Antigravity の長時間思考中にアンロードされなくなる Linux の systemd 管理下であれば systemctl edit ollama で Environment= を追加します。Windows なら環境変数に OLLAMA_KEEP_ALIVE=30m を設定してサービス再起動です。
-1（無期限保持）を使いたくなるかもしれませんが、他の用途で VRAM を取り合う場合に逆効果になります。個人開発マシンでは 30 分〜2 時間程度が現実的な落としどころでした。
なぜ再ロードがそれほど致命的なのか。手元の Apple M2（24GB）で gemma-4:8b（Q4量子化）を計測したところ、コールドロードは初回応答まで平均 11〜14 秒かかりました。エージェントの思考が長引いてアンロードされた直後に再開すると、この十数秒がそのまま「無反応時間」に上乗せされ、原因3のクライアントタイムアウトと組み合わさって切断に至ります。keep-alive を伸ばすのは、この二次被害を断つための最初の一手です。
原因2: コンテキスト長（num_ctx）のデフォルトが足りない
もうひとつの典型的な「途中で切れる」原因が、Ollama 側の num_ctx のデフォルトです。モデルカタログ上のコンテキスト長に関係なく、Ollama はデフォルトで 2048 トークンしか確保しないことがあります。Antigravity から複数ファイルを参照しながらリファクタリングを依頼すると、入力だけで簡単に超過し、途中で切り捨てられた応答が返ってきます。
この設定は Modelfile で上書きするのが確実です。
# カスタム Modelfile を作成 cat << 'MODELFILE' > Modelfile.gemma4-long FROM gemma-4:8b PARAMETER num_ctx 16384 PARAMETER num_predict 4096 PARAMETER temperature 0.3 MODELFILE
# 新しい名前で登録 ollama create gemma-4-long -f Modelfile.gemma4-long
# 確認: 新しいモデル名で呼び出せるか ollama show gemma-4-long --modelfile | grep num_ctx
# 期待出力: PARAMETER num_ctx 16384 Antigravity 側ではこの gemma-4-long をモデル名として指定します。num_ctx を上げると VRAM 消費も増えるので、闇雲に最大化するのではなく、手元のマシンの余力に合わせて選ぶのが肝心です。同じ gemma-4:8b（Q4）を M2 24GB で num_ctx だけ変えて計測した目安が以下です。数値はマシンや量子化で変わりますが、「上げるほど重くなる」勾配の感覚を掴む助けにはなるはずです。
num_ctx 常駐 VRAM/メモリ目安 生成速度の体感 向く用途
2048（既定） 約 6.0 GB 速い（約 24 tok/s） 単発の短い補完 8192 約 7.2 GB やや速い（約 21 tok/s） 1〜2ファイルの編集 16384 約 8.8 GB 実用範囲（約 18 tok/s） 複数ファイルのリファクタ 32768 約 11.5 GB 重い（約 13 tok/s） 大規模文脈・要注意
num_ctx を既定の 2048 から 16384 へ引き上げると、手元では生成速度が約25%ほど落ちる代わりに、複数ファイルを跨ぐ指示が途中で崩れなくなりました。私はこの 16384 を日常の基準にし、リポジトリ全体を読ませたいときだけ 32768 の別モデルを用意して切り替えています。num_predict は 1 回の応答で生成するトークン数上限で、長めのコード生成を期待するなら 4096 以上が無難です。ここを絞りすぎると、文脈に余裕があっても出力側で頭打ちになり、やはり「途中で切れた」ように見えます。
原因3: Antigravity 側のリクエストタイムアウト
ここまで Ollama 側を直しても症状が残る場合、Antigravity 側のクライアントタイムアウトが短すぎる可能性があります。特に Gemma 4 の 27B クラスを CPU のみで回していると、最初のトークンが出るまでに 30 秒以上かかることがあり、多くの HTTP クライアントはその時点で諦めてしまいます。
Antigravity のモデル設定 UI で明示的にカスタムエンドポイントを指定している場合、URL に加えて「Request Timeout」の入力欄があるはずです。ここを 300（秒）程度まで伸ばすと、初回トークンの生成待ちで切られる問題はほぼ解消します。UI がない場合は、ユーザー設定ファイル（macOS では ~/Library/Application Support/Antigravity/settings.json）の llm.requestTimeoutMs を直接編集する方法もあります。
{ "llm.providers" : [ { "name" : "ollama-local" , "baseURL" : "http://localhost:11434/v1" , "model" : "gemma-4-long" , "requestTimeoutMs" : 300000 , "streamReadTimeoutMs" : 120000 } ] } streamReadTimeoutMs は「ストリーム中、次のトークンが届くまで待つ最大時間」です。推論中の一時停止で切られる症状はここが短いことが原因なので、2 分（120000ms）程度を確保しておくと安定します。
2つのタイムアウトは役割が違います。requestTimeoutMs は「最初のトークンが来るまでの我慢」、streamReadTimeoutMs は「トークンとトークンの間の我慢」です。前者だけ伸ばして後者を既定のままにしておくと、初回は通るのに生成途中で切れる、という中途半端な状態になります。両方を対で調整するのが要点です。
原因4: プロキシ・VPN・ファイアウォールによるストリーム切断
見落としがちなのがネットワーク経路の問題です。企業 VPN やセキュリティソフトが長時間アイドルな TCP 接続を問答無用で閉じるケースがあります。接続自体は成立するので「つながらない」とは感じませんが、最初の応答が始まった後、数十秒単位で無音になると中間のプロキシが切断してくる、という厄介なパターンです。
これを疑うときは、VPN をオフにして同じ指示を流してみるのが最速の切り分けです。VPN なしで通るなら、VPN クライアントの「keep-alive」や「idle timeout」の設定を確認します。社内プロキシ経由なら、情報システム部門に相談して HTTP/1.1 の長時間接続を許可してもらう必要があるかもしれません。
家庭環境で踏むことが多いのは、Little Snitch や LuLu のようなアウトバウンドファイアウォールです。Ollama の最初の接続だけを許可していると、ストリーミング中の長時間接続で別ルールが発動して切られることがあります。該当ツールを使っている方は、ollama プロセスのアウトバウンドを「永続許可」にしてみてください。
それでも切れる場合のログ収集
上記で直らない場合は、原因特定のためのログを揃えます。Ollama のサーバーログと Antigravity のデベロッパーログを同時刻で見比べるのが最も効率的です。
# Ollama 側のログをリアルタイム監視（macOS） tail -f ~/.ollama/logs/server.log
# Linux の systemd 経由なら journalctl -u ollama -f
# Antigravity 側のログ場所（macOS） tail -f ~/Library/Logs/Antigravity/main.log
# 期待する観察ポイント: # - Ollama ログに "model stopped: timeout" があるか → keep-alive 問題 # - Ollama ログに "context length exceeded" → num_ctx 問題 # - Antigravity ログに "stream aborted" → クライアント側タイムアウト Ollama 側が「最後まで生成し終わっている」のに Antigravity 側で「途中で切れた」と表示される場合、原因はほぼ確実にクライアント側のタイムアウトかネットワーク経路です。逆に Ollama ログが途中で error を吐いているなら、モデル側の設定（num_ctx / VRAM）が原因です。ここを見分ければ、直すべき場所が一気に絞り込めます。
恒久化レシピ: 再起動しても崩れない設定に固める
原因を突き止めたら、次は「マシンを再起動しても、別のモデルを触った後でも、同じ安定状態に戻れる」ことを保証したいところです。設定が揮発すると、数日後に同じ症状で悩むことになります。私は以下の3点を固定して、環境をやり直しても数分で復元できるようにしています。
まず Modelfile をリポジトリ管理下の1ファイルに集約します。keep-alive を環境変数に頼るのではなく、モデル定義そのものに num_ctx と num_predict を焼き込んでおけば、モデル名を指定するだけで正しい挙動になります。
# hardened Modelfile を一本化して管理 cat << 'MODELFILE' > Modelfile.gemma4-agent FROM gemma-4:8b PARAMETER num_ctx 16384 PARAMETER num_predict 4096 PARAMETER temperature 0.3 # エージェント用途では出力の一貫性を優先 PARAMETER repeat_penalty 1.1 MODELFILE
ollama create gemma-4-agent -f Modelfile.gemma4-agent 次に keep-alive と同時ロード上限を、シェルのプロファイルではなくサービス定義側に置きます。ログイン中のシェルにだけ設定していると、GUI から起動した Ollama には効きません。macOS の launchctl setenv、Linux の systemctl edit ollama、Windows のシステム環境変数——いずれも「サービスが読む場所」に置くのが要点です。
最後に Antigravity の settings.json を dotfiles と一緒にバージョン管理下へ置きます。requestTimeoutMs と streamReadTimeoutMs を明記した provider 定義を1ブロック残しておけば、環境を作り直しても貼り戻すだけで済みます。この「Modelfile・サービス環境変数・settings.json の三点セット」を揃えておくと、途中切断の再発はほぼ起きなくなりました。
検証ループ: 「本当に直ったか」を機械的に確かめる
設定を触った後に「たぶん直った」で終わらせると、たまたま短い指示が通っただけかもしれません。私は変更のたびに、意図的に負荷の高い指示で再現テストを回すようにしています。ポイントは、症状が出ていたのと同じ条件——長い文脈と長い生成——を確実に踏むことです。
# 1. 長文脈・長生成を強制する再現テスト（Ollama 単体で先に確認） # 大きめの入力を渡し、num_ctx とタイムアウトの効きを見る time ollama run gemma-4-agent "次の要件で TypeScript の CLI を一から実装し、 \ 各関数に JSDoc を付け、最後に使用例とテストも書いてください: \ （ここに 300 行程度の要件テキストを貼る）"
# 期待: 途中で止まらず最後まで生成し切る。time の実測で # 初回トークン待ち + 生成時間の内訳を把握しておく
# 2. Ollama が完走したら Antigravity から同じ指示を投げ、 # 片方だけ切れるならクライアント側（原因3/4）に確定できる Ollama 単体では完走するのに Antigravity では切れる、という結果が出たら、モデル設定は無罪でクライアントかネットワークが原因だと確定します。逆に Ollama 単体でも途中で崩れるなら、num_ctx か VRAM を疑う——この二段構えのテストが、原因の押し付け合いを終わらせてくれます。直ったと判断する基準を「同じ重い指示が3回連続で完走する」まで引き上げておくと、偶然の成功に騙されずに済みます。
問題の切り分けが終わったら、Antigravity × Ollama × LM Studio ローカル LLM 統合ガイド の構成を参考に、keep-alive と num_ctx を盛り込んだ設定を Modelfile で恒久化しておくと、再発予防になります。より網羅的なトラブルシューティングを確認したい方には、ローカル LLM 起動・接続トラブル完全対処法 も合わせて参考になります。
まずは今使っているモデルの ollama show <モデル名> --modelfile を打って、num_ctx の値を確認するところから始めてみてください。ほとんどのケースで、ここが 2048 になっているだけでも症状の半分は説明がつきます。ローカルで長い試行錯誤を回せる環境は、それ自体が個人開発の大きな武器です。途切れの不安なく回せるようになれば、その武器がようやく本領を発揮します。実装の一助になれば幸いです。