Google のオープンソース Gemini CLI—Gemini をシェルに持ち込むターミナル常駐型の AI エージェント—は、リリース以来急速に成熟し、リッチな設定、プロジェクトコンテキストファイル（GEMINI.md / .gemini）、カスタムスラッシュコマンド、ワークスペースディレクトリ制御をサポートするようになりました。プロジェクトは GitHub（公式リポジトリ）で活発に進化しており、寛大なクオータでパブリックプレビューに入り、他の開発者ツール（エディタ統合や CI/Actions）への統合も進んでいます。しかし、チームが拡大したり、ドライブをまたいだり、制約の強い環境（コンテナ、会社管理のノート PC、Cloud Shell、Windows システム）で作業すると、現実的な疑問にすぐぶつかります。Gemini はファイルをどこに保存し、Gemini が読み書きするディレクトリをどう変更できるのか？
Gemini CLI とは？
Gemini CLI は、Google のオープンソースのコマンドライン AI エージェントで、Gemini モデルの力を直接ターミナルにもたらします。コード支援、ファイルやプロジェクトの検査、（セーフガード付きの）シェルコマンドの実行、Google Search、Model Context Protocol (MCP) 拡張、Gemini に同梱されるメディア生成ツールなどのツール統合といった、対話型エージェント機能を提供します。CLI は軽量で、スクリプト化可能かつ拡張可能であることを意図しており、公式リポジトリから入手でき、簡単にインストールできるようパッケージ化されています。
なぜディレクトリが重要か
Gemini CLI は、設定（例：settings.json）、システムプロンプトやコンテキスト（GEMINI.md）、キャッシュされた認証情報、テレメトリー識別子、その他の永続的な状態を .gemini ディレクトリ内に保存します。そのディレクトリの場所によって以下が制御されます。
- CLI が読み込む設定（グローバル vs. プロジェクト固有）
- エージェントが読み取る「メモリ」ファイル
- 認証情報のキャッシュ場所（ログイン動作に影響）
- カスタム設定リポジトリを提供したい場合の、マシン間や CI の再現性
ディレクトリを理解し（必要に応じて）変更することは、マルチプロジェクトのワークフロー、CI、コンテナ化されたデプロイ、集中管理された設定ストアを持つチームに役立ちます。
Gemini CLI はデフォルトでどこに設定を保存するのか？
デフォルトでは CLI は .gemini ディレクトリを使用します。多くのユーザーインストールでは ~/.gemini（ホームディレクトリ内の .gemini フォルダ）に解決されます。CLI はプロジェクトレベルの .gemini ファイル（例：プロジェクトルートの .gemini/settings.json）にも対応しており、そのプロジェクトフォルダで操作している間はユーザー設定を上書きします。システムレベルの設定は、該当する場合に OS 固有の場所（例えば Linux の /etc/ や Windows の %PROGRAMDATA%）から読み取られます。典型的なパスは次の通りです。
- Linux / macOS:
~/.gemini/（例：/home/alice/.geminiや/Users/alice/.gemini） - Windows:
%USERPROFILE%\.gemini（例：C:\Users\Alice\.gemini）
.geminiの中には通常、settings.json、GEMINI.md、commands/、ローカルキャッシュが見つかります。CLI はプロジェクトルートの.gemini/フォルダ（プロジェクトレベルの設定）も読み取ります。
このデフォルトは重要です。歴史的に設定ディレクトリはホームディレクトリの .gemini にハードコードされていました。
Gemini CLI の設定ディレクトリをどう変更・リダイレクトできるか？
いくつかの実用的な方法があります。最も簡単なもの（目的のフォルダで作業する）から、より堅牢なもの（環境変数やファイルシステムのリダイレクト）まで。実行環境（ローカル開発機 vs. CI）を制御できるか、使用する OS、変更を一時的にするか恒久的にするかに応じてアプローチを選びます。
1) プロジェクトレベルの .gemini を使用する（プロジェクト単位の設定に推奨）
プロジェクト単位の設定が欲しい場合は、プロジェクトルートに .gemini サブディレクトリを作成し、settings.json、GEMINI.md、その他のプロジェクトファイルを配置します。プロジェクトディレクトリから CLI を実行すると、Gemini CLI はプロジェクト設定を優先します。
your-project/├─ .gemini/│ ├─ settings.json│ └─ GEMINI.md└─ src/
シェルを your-project/ に置いた状態で gemini を起動すると、CLI はそのツリーから .gemini ファイルを（上位ディレクトリまで探索して）取得します。これはプロジェクトごとの設定に最も安全で明示的な方法です。
2) ドキュメント化された環境変数を使用する（サポートされる場合）
Gemini CLI のコードベースとドキュメントには、動作を変更するために使われるいくつかの環境変数が参照されています。これらの一部はシステム設定や特別なファイルの上書きに意図されています。
GEMINI_API_KEY、GEMINI_MODELなどは認証やモデル選択で一般的に使用されます。- コードベースやドキュメントには、
GEMINI_CLI_SYSTEM_SETTINGS_PATH（システム設定パスの上書きに使用）や、コード内のデフォルトの.gemini名を表す定数GEMINI_CONFIG_DIRなどの変数への言及があります。コミュニティからは、設定ディレクトリ全体を移動できるようにGEMINI_CONFIG_DIR環境変数を追加・尊重する提案や PR もあります。
例（bash / macOS / Linux）:
# Temporary for this shell sessionexport GEMINI_CONFIG_DIR="$HOME/custom_gemini_dir"# Or override system settings path if your install supports it:export GEMINI_CLI_SYSTEM_SETTINGS_PATH="/etc/my-gemini/system.settings.json"# Then rungemini
PowerShell（Windows）:
$env:GEMINI_CONFIG_DIR = 'C:\Users\you\CustomGemini'gemini
重要な注意: 最新のコミュニティディスカッションや Issue によると、
GEMINI_CONFIG_DIRは一部で参照・要求されていますが、特に Windows でプラットフォーム固有のバグや不一致が報告されています。つまり、環境変数ベースのリダイレクトは、すべてのプラットフォームやリリースで一様に信頼できるとは限りません。これに依存する場合は、インストール済みバージョンの Gemini CLI のリリースノートやリポジトリの Issue を確認してください。
3) セッション内で Gemini のワークスペースにディレクトリを追加する
追加のディレクトリを Gemini に認識させたい（コンテキストとしてファイルを読ませたい）場合は、対話的な /directory コマンドセットがあります。例えば:
/directory add path/to/another/project/directory list
これは設定ディレクトリを移動するものではありませんが、エージェントが他ディレクトリのファイルをワークスペースコンテキストに含められるようにします。グローバル設定を変更せずに他のリポジトリを参照したい場合に便利です。
4) シンボリックリンクやファイルシステムバインドを作成する（実用的な回避策）
CLI が環境の上書きを受け付けない場合や、プロセス間で信頼できる解決策が必要な場合は、ファイルシステムのリダイレクトを使います。
Unix/macOS の場合:
# move the original config foldermv ~/.gemini ~/gemini_backup# create a symlink to your desired locationln -s /path/to/central/gemini-config ~/.gemini
Windows（管理者権限の PowerShell）:
# Move the original directoryMove-Item -Path $env:USERPROFILE\.gemini -Destination C:\GeminiConfigBackup# Create a junction (administrator)New-Item -ItemType Junction -Path $env:USERPROFILE\.gemini -Target C:\CentralGeminiConfig
この方法は、CLI にネイティブなサポートを必要とせずに、希望の場所から読み取るよう強制します。注意: シンボリックリンク／ジャンクションには適切なファイルシステム権限が必要で、コンテナや Windows 環境では動作が異なる場合があります。注意して使用してください（「Windows 固有の注意事項」を参照）。
5) プロセスの実効ホームディレクトリを変更する（コンテナ／CI の小技）
CI、コンテナ、エフェメラル環境で実行する場合、gemini プロセスの $HOME（Unix）または %USERPROFILE%（Windows）環境変数を変更して、デフォルトの ~/.gemini を制御可能なパスに解決させることができます。
# Run gemini with a custom HOME (bash)HOME=/ci/workspace/you gemini --some-command# Or in a container DockerfileENV HOME=/app/userRUN mkdir -p /app/user/.geminiCOPY config /app/user/.gemini
これは CI の再現性に有用ですが、HOME を変更すると他のツールや認証フロー（例：Google OAuth キャッシュ）に影響する場合があるため、この手法は隔離されたコンテナやプロセスレベルのラッパーに限定して用いてください。
CometAPI 経由で Gemini CLI をインストールして使うには？
短い答え: 実用的なパスは 2 つあります。（A）CometAPI を通して Gemini モデルを「直接」呼び出す（推奨・最も簡単）、または（B）公式 Gemini CLI に CometAPI を話させる。後者は、カスタムベース URL をサポートする Gemini-CLI リリース（いくつかのリリース／PRが追加）を使うか、Gemini-CLI のリクエストを CometAPI／OpenAI 風の呼び出しに変換する小さなローカルプロキシを動かす方法です。
CometAPI とは？
CometAPI は、OpenAI スタイルの HTTP API の背後で何百ものサードパーティモデル（Google の Gemini ファミリーを含む）を公開する API アグリゲーション／ゲートウェイです。サインアップしてベアラー API キーを取得し、https://api.cometapi.com/v1/chat/completions のようなエンドポイントを呼び出します。CometAPI は Authorization ヘッダーの標準ベアラートークンを使用します。
なぜ CometAPI を使うのか？統合を容易にするため、公式 API より低価格の API を提供します。Gemini CLI インストールと使用ガイド:
CometAPI で Gemini モデルを「直接」呼び出すには？（推奨）
Gemini モデルを使うことが目的で、Gemini CLI の機能が厳密には不要であれば、CometAPI を直接呼び出すのが簡単で確実です。
export COMET_KEY="sk-xxxx"curl -s -X POST "https://api.cometapi.com/v1/chat/completions" \ -H "Authorization: Bearer $COMET_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "gemini-2.5-pro", "messages": [ {"role": "system", "content": "You are a helpful assistant."}, {"role": "user", "content": "Summarize the 3 key benefits of unit tests."} ], "max_tokens": 300 }' | jq .
これらの直接呼び出しにより、Gemini CLI に依存せずに、CometAPI をスクリプト、アプリ、CI に統合できます。
Gemini CLI を CometAPI に向けることはできる？
一部の Gemini CLI バージョン／PR は、Gemini API ベース URL の上書き用の環境変数を追加しています。インストール済みの gemini がカスタム Gemini ベース URL の設定と CometAPI キーの使用をサポートしている場合、CometAPI を指すように設定し、CometAPI キーを GEMINI_API_KEY（CLI は Gemini API キー認証用の変数名として GEMINI_API_KEY を期待）として設定できます。
例:
# example env — *check your gemini-cli docs for exact var names*export GEMINI_API_KEY="sk-xxxxx" # CometAPI keyexport GOOGLE_GEMINI_BASE_URL="https://api.cometapi.com/v1" # if supportedgemini # run the CLI; it will use the configured base URL
トラブルシューティング：よくある問題と対処
問題: 別のリポジトリ内のファイルが Gemini から見えない
- 起動時に
gemini --include-directories /path/to/repoを試してください。あるいはセッション内で/directory add /path/to/repo。 - リポジトリがネットワークマウントにある場合、権限と CLI プロセスユーザーがファイルを読み取れることを確認してください。
.geminiを移動するためにシンボリックリンクを使った場合、CLI がGEMINI.mdやsettings.jsonのシンボリックリンクに従うか検証してください（バージョンによってはセキュリティ上の理由で特定のシンボリックリンクに従いません）。
問題: Windows で gemini が ~/.gemini の作成に失敗する（EPERM）
これは通常、プロセスに %USERPROFILE% への書き込み権限がないことを意味します。対処:
- 端末を管理者として実行するか、フォルダ権限を調整します。
- シンボリックリンクや、サポートされる場合は環境変数でカスタム設定場所を設定します（将来の
GEMINI_CONFIG_DIRサポートに注意）。
問題: シェルモード内で cd が作業ディレクトリを変更しない
これは一部プラットフォームで認識されている問題です。推奨: Gemini CLI プロセス外からシェルコマンドを実行するか、/directory add でディレクトリを追加してください。
問題: CometAPI のモデル名が期待と一致しない
/v1/models エンドポイントを呼び出し、JSON を確認してください。モデル ID はしばしば正確なバリアント文字列（例：gemini-2.5-flash-preview-04-17）を含みます。リクエストではその文字列を正確に使用してください。
結論
Gemini CLI のデフォルト設計は、わかりやすく妥当な動作を重視しています。ユーザーレベルのデフォルト用にグローバルな ~/.gemini と、リポジトリ単位の上書き用にプロジェクトの .gemini。コミュニティは、マルチユーザー、コンテナ化、エンタープライズ環境により親和的にするため、よりネイティブな構成可能性（明示的な環境変数やフラグ）を後押ししています。
Gemini CLI のディレクトリ変更方法:
概要: Gemini CLI はユーザー全体の設定とコンテキストファイルを .gemini ディレクトリ（通常は ~/.gemini）に保存します。CLI が使用するディレクトリに影響を与えるには、（1）現在の作業ディレクトリ内のプロジェクトレベル .gemini に依存する、（2）サポートされる場合は環境変数や CLI オプションを使用する、（3）対話セッション内でワークスペースディレクトリを追加する、（4）ネイティブオプションがない場合はファイルシステムの手法（シンボリックリンク、バインドマウント、ホーム／プロファイル変数の変更）を使う、といった方法があります。
始めるにあたり、Gemini 3 Pro の機能を Playground で試し、詳細な手順は API ガイド を参照してください。アクセス前に、CometAPI にログインして API キーを取得していることを確認してください。CometAPI は、統合を支援するため公式価格よりもはるかに低い価格を提供しています。
Ready to Go?→ gemini モデルの無料トライアル !
