Google が公開している Gemini CLI は、ターミナル上で Gemini モデルを利用できるオープンソースの AI エージェントです。通常は Google の API エンドポイントに接続して使いますが、API のリクエスト先を差し替えることで、ローカルで動作する LLM をバックエンドにすることもできます。
本記事では、LiteLLM Proxy と Ollama を組み合わせて、Gemini CLI のバックエンドをローカル LLM に差し替える手順と、セットアップ時に遭遇したいくつかの注意点をご紹介します。
なお、LiteLLM Proxy を使って組織的に LLM API を管理する構成については 以前の記事 で紹介していますので、ご興味あればそちらも併せてご覧ください。
構成概要
全体の構成は次のとおりです。
Gemini CLI は @google/genai SDK の環境変数 GOOGLE_GEMINI_BASE_URL を設定することで、API のリクエスト先を任意のエンドポイントに変更できます。この変数は Gemini CLI の公式ドキュメントには記載されていないようですが、SDK 側でサポートされている変数です（参考 PR）。
LiteLLM Proxy は Gemini API 互換のエンドポイント（/v1beta/models/{model}:streamGenerateContent 等）を提供しており、受け取ったリクエストを Ollama のローカルモデルに中継します。LiteLLM Proxy には model_group_alias という、要求されたモデル名を別のモデルにルーティングする機能があり、これを利用すると Gemini CLI が送信するモデル名（gemini-3-flash-preview など）をローカルモデルにマッピングできます。
検証環境
- macOS (Apple Silicon, Tahoe 26)
- Gemini CLI v0.30.0
- LiteLLM v1.81.16
- Ollama v0.17.0
- Python 3.14.0
- Node.js v22.17.0
セットアップ
Ollama のインストールとモデルの取得
Homebrew でインストールし、サービスとして起動します。
brew install ollama brew services start ollama
モデルをダウンロードします。
gemma3 を使おうと思ったのですが、後述のようにツール呼び出しが Ollama のテンプレートに対応していなかったため、ここでは検証用途として軽量な qwen2.5:3b（約 1.9 GB）を選択しています。
ollama pull qwen2.5:3b
LiteLLM のインストール
Python の仮想環境を作成してインストールします。
python3 -m venv .venv source .venv/bin/activate pip install 'litellm[proxy]'
LiteLLM Proxy の設定
litellm_config.yaml を作成します。
model_list: - model_name: local-model litellm_params: model: ollama_chat/qwen2.5:3b api_base: "http://localhost:11434" router_settings: model_group_alias: "gemini-3.1-pro-preview": "local-model" "gemini-3.1-pro-preview-customtools": "local-model" "gemini-3-flash-preview": "local-model" "gemini-3-flash-preview-customtools": "local-model" "gemini-2.5-pro": "local-model" "gemini-2.5-flash": "local-model" "gemini-2.5-flash-lite": "local-model"
ポイントは model_group_alias の設定です。Gemini CLI は内部で複数のモデルを使い分けており、メインの生成モデル（gemini-3-flash-preview 等）に加えて、入力の分類用に軽量モデル（gemini-2.5-flash-lite）も使用します。これらすべてのモデル名に対応するエイリアスを定義しておく必要があります。ワイルドカードで指定できれば良かったのですが、現状は個別のモデルに対してエイリアスが必要になりそうです。
設定ファイルを指定して Proxy を起動します。
litellm --config litellm_config.yaml --port 4000
Gemini CLI の起動
環境変数を設定して Gemini CLI を起動します。
export GOOGLE_GEMINI_BASE_URL="http://localhost:4000" export GEMINI_API_KEY="sk-dummy-key" gemini --sandbox=false
API キーは使用しないため、適当な設定でも問題ありません。
これでローカル LLM からの応答が返るようになります。
ちなみに、--sandbox=false を指定しているのは、sandbox モードでは GOOGLE_GEMINI_BASE_URL がサンドボックスコンテナ内に渡されないという既知の Issue があるためです（Issue #2168）。
セットアップ時の注意点
model_group_alias に不足があると 500 エラーになる
Gemini CLI はバージョンによって用途ごとに使用するモデルが変わります。今回使用した v0.30.0 では gemini-3-flash-preview, gemini-2.5-flash-lite などが使われていました。
LiteLLM Proxy 側でこれらのモデル名に対応するエイリアスが未定義の場合、BadRequestError: There are no healthy deployments for this model というエラーが返ります。
Gemini CLI のアップグレードおよび Gemini の新しいモデルのリリースによって使用するモデルが変わる可能性があるため、アップグレードの際は Proxy のログに出力されるリクエスト済みモデル名を確認して、不足分を model_group_alias に追加していく運用が必要になりそうです。
使用するモデルが Ollama テンプレートでのツール呼び出しに対応している必要がある
当初は Google 製の gemma3:4b を使用しましたが、does not support tools というエラーで動作しませんでした。
Gemini CLI はリクエストにツール定義（ファイル操作やコマンド実行など）を含めて送信します。Ollama でこの tools パラメータを処理するには、モデルのチャットテンプレートがツール呼び出しに対応している必要があります。
ここで注意が必要なのは、モデル自体の function calling の能力と、Ollama テンプレートの対応状況は別の問題だということです。
gemma3 は、現在、モデルの能力としてはプロンプトベースでの function calling が可能（参考 ですが、Ollama テンプレートには対応していません（ollama/ollama#9941）。
例えば前述の Qwen 2.5 は Ollama の公式テンプレートでのツール呼び出しをサポートしています。
今回使用した qwen2.5:3b は、3B パラメータで約 1.9 GB と軽量なため、コンセプト検証には手頃な選択肢ですね。
まとめ
LiteLLM Proxy と Ollama を組み合わせることで、Gemini CLI のバックエンドをローカル LLM に差し替える方法をご紹介しました。
セットアップ自体は比較的シンプルですが、Gemini CLI のバージョンによるモデル名の変化や、Ollama モデルのツール呼び出し対応状況など、実際に動かしてみないと気付きにくいポイントがいくつかありました。
なお、3B パラメータの小型モデルでは、Gemini CLI の AI エージェントとしての機能（ファイル操作やコード生成など）を十分に使いこなすのは難しい印象です。コーディング支援として本格的に使うのであれば、より大きなモデルの利用を検討するのが良さそうです。
