Gemini CLI MCP設定ガイド｜接続・管理・安全運用

Gemini CLIにMCPサーバーを接続すると、外部システムが公開するツールを対話型の作業フローから利用できます。ただし、実務で重要なのは接続の成功だけではありません。適用範囲、公開ツール、認証情報、実行権限まで設計して、初めて組織で継続利用できる状態になります。

本記事では公式情報に沿って、MCPサーバーの追加・一覧・削除、settings.jsonの記述、stdio・SSE・Streamable HTTPの違い、/mcpによる確認、OAuth認証、トラブルシューティング、安全対策を解説します。サーバーごとに起動コマンドや認証要件は異なるため、接続先の公式手順も必ず確認してください。

Gemini CLI MCPとは

MCP（Model Context Protocol）は、AIアプリケーションと外部のデータやツールを共通の方法で接続するためのプロトコルです。Gemini CLIはMCPクライアントとしてサーバーへ接続し、公開されたツールを検出して利用します。MCP自体の全体像は、MCP（Model Context Protocol）の解説もご覧ください。

役割は次のように分かれます。

要素	役割
Gemini CLI	MCPサーバーへの接続、ツール検出、対話中の利用
MCPサーバー	外部機能やデータをツールとして公開
settings.json	接続方法や利用可能なツール範囲を定義
認証基盤	CLI本体またはMCPサーバーへのアクセスを認証

Gemini CLI本体へのログインと、MCPサーバー側の認証は別の処理です。CLIを使えていても、接続先がOAuthなどを要求する場合はMCP用の認証が別途必要です。この区別により、「CLIは動くがMCPだけ接続できない」という問題を切り分けやすくなります。

導入前に確認する項目

登録前に、接続先の提供・管理主体、ローカル起動かネットワーク接続か、許可する読み取り・更新・削除操作、認証情報の保管方法、設定の適用範囲を明確にします。出所不明のサーバーやパッケージを起動すると、ファイルや認証情報へ意図せずアクセスされるおそれがあります。提供元、ソース、必要権限、通信先を確認してください。

MCPサーバーの選定観点はMCPサーバーの仕組みと選び方で解説しています。Gemini CLI本体の導入が未完了なら、先にGemini CLIの使い方ガイドで基本操作まで確認しましょう。

最短でMCPサーバーを追加する手順

Gemini CLIでは、シェルで実行するgemini mcpと、対話セッション内で実行する/mcpを使い分けます。前者は主に設定の追加・一覧・削除、後者は現在の接続状態やツールの確認に使います。

1. Gemini CLI本体の認証を済ませる

Gemini CLIを起動し、本体の認証を完了させます。利用可能な方法は環境や組織方針によって異なるため、公式Authenticationドキュメントに従ってください。ここで済むのはCLI本体の認証であり、MCPサーバー独自の認証とは別です。

2. gemini mcp addで追加する

ターミナルなどのシェルからMCPサーバーを追加します。

gemini mcp add

実際にはサーバー名、接続方式、起動コマンドまたはURLなど、接続先に必要な値を指定します。引数は方式によって変わるため、利用中のGemini CLIでヘルプを表示し、サーバー提供元が案内する値を当てはめてください。

gemini mcp add --help

推測で登録せず、公式のMCP serversドキュメントと接続先の説明を照合します。特に、ローカル起動するサーバーとURLへ接続するサーバーを取り違えないようにしてください。

3. gemini mcp listで一覧を確認する

登録後、シェルで次を実行します。

gemini mcp list

登録名が一覧に現れるか確認します。見つからなければ、設定を書き込んだ範囲や現在の作業ディレクトリを見直します。

4. /mcpで接続とツールを確認する

Gemini CLIを起動し、対話セッション内で次を入力します。

/mcp

/mcpはシェルではなくGemini CLIのプロンプトへ入力するスラッシュコマンドです。サーバーの接続状態、必要なツールが公開されているか、意図しない高権限ツールが含まれていないかまで確認します。詳細は公式CLI commandsドキュメントで確認できます。

5. gemini mcp removeで削除する

検証が終わったサーバーや不要な接続先は放置せず削除します。

gemini mcp remove <サーバー名>

削除後はgemini mcp listで一覧から消えたことを確認します。settings.jsonを直接編集した場合は、対象エントリーを削除し、JSONの構文が壊れていないかも確認してください。

settings.jsonでmcpServersを設定する

コマンドによる管理に加えて、settings.jsonのmcpServersへ接続先を定義できます。複数項目をレビューする場合や、秘密情報を含まないプロジェクト設定をチームで管理する場合に適しています。

ユーザー設定とプロジェクト設定

主な設定場所は次の2つです。

種類	パス	適した用途
ユーザー設定	~/.gemini/settings.json	同じ利用者が複数の作業で共通利用する設定
プロジェクト設定	<project>/.gemini/settings.json	特定プロジェクトだけで利用する設定

プロジェクト設定は共有しやすい一方、リポジトリへ保存される可能性があります。アクセストークン、クライアントシークレット、個人用の認証情報を直接書かないでください。共有するのは接続名や承認済みツール範囲などに限定し、秘密情報は組織が承認した安全な方法で別管理します。

設定の詳細は公式Configurationドキュメントを確認してください。以下の値は説明用なので、実際のサーバーが指定する値へ置き換えます。

stdio（command）の設定例

stdioでは、Gemini CLIがローカルのMCPサーバープロセスを起動し、標準入出力で通信します。

{  "mcpServers": {    "example-local": {      "command": "/absolute/path/to/example-mcp-server",      "args": ["--mode", "read-only"],      "trust": false    }  }}

commandに実行するコマンドを指定し、必要な引数はargsへ分けて記述します。運用時は実行パスを明確にし、提供元を確認したうえで不要な引数を渡さないことが重要です。起動できなければ、実行権限、パス、依存ファイル、作業ディレクトリを確認します。

SSE（url）の設定例

SSEを利用するサーバーにはurlを指定します。

{  "mcpServers": {    "example-sse": {      "url": "https://mcp.example.com/sse",      "trust": false    }  }}

リモート接続では、URLの入力ミスだけでなく、DNS、プロキシ、ファイアウォール、TLS証明書、接続元制限なども影響します。企業ネットワークから対象ホストへの通信が許可されているか確認してください。

Streamable HTTP（httpUrl）の設定例

Streamable HTTPを利用するサーバーにはhttpUrlを指定します。

{  "mcpServers": {    "example-http": {      "httpUrl": "https://mcp.example.com/api",      "trust": false    }  }}

SSEのurlとStreamable HTTPのhttpUrlは設定キーが異なります。サーバーが対応する方式を確認し、自己判断で置き換えないでください。

3つの接続方式の選び方

接続方式	設定キー	向いている構成	主な確認点
stdio	command、args	端末上のローカルプロセス	実行パス、権限、依存関係
SSE	url	SSE対応のリモートサーバー	URL、ネットワーク、認証
Streamable HTTP	httpUrl	同方式対応のリモートサーバー	エンドポイント、ネットワーク、認証

常に優れた方式があるのではなく、MCPサーバーが正式に対応する方式で選びます。ローカルの開発支援ではstdio、組織で一元管理されたサービスではSSEまたはStreamable HTTPが候補になりますが、サーバー仕様と自社のセキュリティ要件が前提です。

接続の容易さだけでなく、更新管理、障害監視、認証、通信制御、ログ取得、利用停止の手順も検討してください。関連するGoogleの開発支援製品との違いは、Gemini Code Assistの解説で整理しています。

MCPツールを安全に制御する

MCPサーバーへの接続後は、利用できるツールを最小権限に絞ります。サーバー単位の承認だけで終わらせず、ツール単位で業務上の必要性を確認してください。

trustはfalseから始める

初期設定ではtrust: falseを採用します。

{  "mcpServers": {    "example-approved": {      "httpUrl": "https://mcp.example.com/api",      "trust": false    }  }}

trustはツール呼び出し時の確認に関わる設定です。falseでもツールを利用できないという意味ではありません。確認を伴う安全側の状態から始め、ツール名、入力内容、影響範囲を利用者が確認できるようにします。確認を省略する方向へ変更する場合は、対象サーバー、データ範囲、誤操作時の復旧方法をレビューしてください。

includeToolsで許可リスト化する

利用ツールが決まっている場合はincludeToolsで限定します。

{  "mcpServers": {    "example-approved": {      "httpUrl": "https://mcp.example.com/api",      "trust": false,      "includeTools": ["search_documents", "read_document"]    }  }}

ツール名は説明用です。実際には/mcpで正確な名前を確認します。サーバー側に新しいツールが追加されても自動的に利用対象へ入れたくない場合、許可リスト方式が適しています。

excludeToolsで特定操作を除外する

多くのツールを利用しつつ、一部だけ外す場合はexcludeToolsを使います。

{  "mcpServers": {    "example-approved": {      "httpUrl": "https://mcp.example.com/api",      "trust": false,      "excludeTools": ["delete_document"]    }  }}

除外リストでは、新設されたツールが利用可能になる可能性があります。厳格な統制が必要ならincludeToolsを優先し、定期的に/mcpの表示と設定を突き合わせてください。

認証情報を共有設定から分離する

プロジェクト設定を管理する場合、秘密情報をsettings.jsonへ直接含めないことが原則です。個人用トークンをコミットせず、認証情報の発行者、利用者、有効範囲、失効手順を管理します。誤って保存した場合はファイルから消すだけで済ませず、認証情報を失効・再発行してください。

環境変数を利用できるか、どの項目で参照できるかは、Gemini CLIとMCPサーバーの公式仕様に従います。確認できない補間記法を設定へ持ち込まないでください。

trusted foldersとsandboxを併用する

MCP設定だけで全リスクは制御できません。trusted foldersは、作業フォルダーを信頼するかに応じてプロジェクト固有設定などの扱いを制御する防御層です。公式Trusted Foldersドキュメントに沿って状態を確認してください。

sandboxはツール実行を隔離する別の防御層です。ローカルファイルやプロセスへアクセスするサーバーでは、公式Sandboxドキュメントを確認します。接続先の審査、最小権限、実行時確認、隔離を組み合わせる多層防御が重要です。

/mcpで状態・再読込・認証を管理する

対話セッションでは/mcp関連コマンドで状態を管理します。シェルで実行するgemini mcp listなどとは実行場所が違います。

/mcp

現在のセッションから認識されているMCPサーバーとツールを確認する入口です。追加直後だけでなく、利用開始前にも実行すれば、想定外の接続先やツールを発見しやすくなります。設定ファイルに記述があっても、セッションで利用可能とは限らないため、実状態まで確認してください。

/mcp refresh

設定変更やサーバー側のツール変更を再検出するには、対話セッションで次を実行します。

/mcp refresh

続けて/mcpを実行し、状態を比較します。反映されなければ、編集したファイルの場所、JSON構文、作業フォルダー、信頼状態を確認します。必要に応じてセッションの開始し直しも切り分けになります。

/mcp auth

OAuthなどの認証に対応するサーバーでは、対話セッションの/mcp authが認証の導線になります。表示される案内に従い、接続先ドメイン、要求権限、利用する組織アカウントを確認して認証します。

CLI本体へログイン済みでも、MCP側の認証が未完了なら接続やツール呼び出しに失敗する場合があります。認証後は/mcpで状態を再確認し、必要なら/mcp refreshを実行してください。

接続できない場合のトラブルシューティング

問題を「設定」「プロセス」「ネットワーク」「認証」「ツール可視性」の順に分けると効率的です。一度に複数項目を変えず、一つ変更するたびにgemini mcp listと/mcpで結果を確認します。

JSONと設定場所を確認する

まず、次を確認します。

• ユーザー設定とプロジェクト設定を取り違えていないか
• mcpServersの階層、括弧、カンマ、引用符が正しいか
• stdioにcommand、SSEにurl、Streamable HTTPにhttpUrlを使っているか
• 想定したプロジェクトディレクトリから起動しているか
• 同じサーバー名の設定が競合していないか

gemini mcp listに現れなければ、まず保存先とJSONを疑います。一覧にはあるが対話セッションで利用できない場合は、接続方式別の確認へ進みます。

stdioプロセスを確認する

commandのプログラムが端末から起動できるか確認します。実行ファイルの存在、権限、引数、必要なランタイムや依存ファイルを順番に調べます。相対パスに依存すると、Gemini CLIの起動場所によって結果が変わることがあります。各端末で再現可能な導入手順とパス方針を決めてください。

ネットワークを確認する

SSEまたはStreamable HTTPでは、接続先URLと方式が仕様に合うか確認します。その後、DNS、社内プロキシ、ファイアウォール、VPN、TLS証明書、接続元制限を切り分けます。ブラウザでURLを開けてもMCPエンドポイントとして正常とは限りません。サーバー側のログがあれば、Gemini CLI側の表示時刻と照合します。

認証を確認する

CLI本体とMCPサーバーの認証を分けて確認します。MCP側がOAuth対応なら/mcp authの案内に従ってください。以前は使えた接続が失敗する場合は、認証情報の期限切れ、失効、権限変更も候補です。秘密情報をチャットやチケットへ貼らず、定められた手順で再認証します。

ツールフィルターを確認する

接続済みなのに必要なツールがない場合、includeToolsまたはexcludeToolsを確認します。綴りが実際の公開名と一致するか、許可リストから漏れていないかを見ます。制御を全面解除するのではなく、/mcpで正確な名前を把握して修正してください。サーバー側の変更が疑われる場合は/mcp refreshで再検出します。

信頼とサンドボックスを確認する

プロジェクト設定が読み込まれない場合は、現在のフォルダーが信頼されているか確認します。ツールは起動してもファイルやプロセスへアクセスできない場合は、サンドボックスの制約が働いている可能性があります。安全機構を無条件で解除せず、必要なアクセス範囲を特定し、検証用データで動作確認してください。

BtoB導入の運用チェックリスト

企業導入では、初回接続だけでなく変更と廃止まで管理します。提供元・通信先・データ範囲を審査し、ユーザー設定とプロジェクト設定を使い分け、認証情報の発行・更新・失効手順を定めてください。trust: falseと許可リストから始め、gemini mcp listと/mcpの両方で検証します。

プロジェクト設定はコードと同様にレビューし、秘密情報を履歴へ残さないことが重要です。接続先や公開ツールの変更には承認を設け、検証ではダミーデータや読み取り専用権限を使います。廃止時は設定の削除だけでなく、認証情報の失効まで完了させてください。

よくある質問

Q. Gemini CLIのMCP設定ファイルはどこですか？

ユーザー設定は~/.gemini/settings.json、プロジェクト設定は<project>/.gemini/settings.jsonです。個人共通か特定プロジェクトだけかで選びます。プロジェクト設定へ秘密情報を直接保存しないでください。

Q. gemini mcpと/mcpは何が違いますか？

gemini mcp add/list/removeはシェルで実行し、設定の追加・一覧・削除に使います。/mcp、/mcp refresh、/mcp authは対話セッション内で実行し、状態確認、再検出、認証に使います。

Q. stdio、SSE、Streamable HTTPはどう選びますか？

サーバーが公式に対応する方式を選びます。ローカルプロセスならstdioのcommand、SSE対応ならurl、Streamable HTTP対応ならhttpUrlを使用します。組織のネットワーク要件も併せて確認してください。

Q. 追加したのにツールが表示されない原因は何ですか？

設定場所やJSON構文、stdioプロセス、ネットワーク、MCP側の認証、ツールフィルター、フォルダー信頼が主な確認対象です。gemini mcp listで登録を確認し、対話セッションで/mcp refresh、続いて/mcpを実行します。

Q. trust: falseでもMCPツールを使えますか？

利用できます。ツール呼び出し時の確認に関わる安全側の設定です。まずfalseでツール名と影響を確認し、変更する場合は組織でレビューしてください。

Q. includeToolsとexcludeToolsはどちらを使うべきですか？

厳格な最小権限が必要ならincludeToolsが基本です。多くのツールから一部だけ外す場合はexcludeToolsも選べますが、新設ツールが利用対象になる可能性を踏まえて定期的に見直します。

Q. MCPの認証情報をプロジェクト設定へ保存してよいですか？

共有される可能性がある設定へ、トークンやシークレットを直接保存すべきではありません。組織で承認された秘密情報管理の仕組みを使い、設定と認証情報を分離してください。

Q. 設定変更後に再起動する必要はありますか？

まず/mcp refreshを実行し、/mcpで結果を確認します。反映されなければ設定場所、JSON、信頼状態を見直し、必要に応じてセッションを開始し直します。

まとめ

Gemini CLI MCPは、gemini mcp addで追加し、gemini mcp listで登録を確認してから、対話セッションの/mcpで接続と公開ツールを確認するのが基本です。不要な設定はgemini mcp removeで削除します。

設定ファイルでは、ユーザー設定~/.gemini/settings.jsonとプロジェクト設定<project>/.gemini/settings.jsonを使い分けます。stdioはcommand、SSEはurl、Streamable HTTPはhttpUrlを指定し、サーバーが対応する方式に合わせてください。

企業で安全に運用するには、trust: falseから始め、includeToolsを中心に最小権限へ絞ります。認証情報の分離、trusted folders、sandbox、変更レビュー、廃止時の認証失効も組み合わせてください。接続障害は、設定、プロセス、ネットワーク、認証、ツール可視性の順に切り分けると解決しやすくなります。

MCP連携を単発の設定作業で終わらせず、権限・セキュリティ・監査・業務フローまで含めて設計したい企業は、NexaのAI活用相談をご利用ください。