Zenn
🛠️

Gemini CLIをインストールしVertex AIで安全に使うまで

に公開
CLI
nvm
IAM
vertex
Gemini
tech

Gemini CLIを組織で使うときなど、Gemini APIをバックエンドに使ってしまうと、LLMとのやり取りがGoogle側で学習に使われてしまうのかが懸念となってしまいます。本記事では、Gemini CLIをインストールし、そのバックエンドにVertex AIを使い、情報漏洩、セキュリティを担保する手順について備忘録的に残しています。本記事はLinux環境ですが、セキュリティや情報漏洩、その他インストールの流れなどはOSを問わず参考になる箇所もあると思います。

Gemini CLIを使うに当たって懸念と選択肢整理

※ 本章はデータ取り扱いの違いにフォーカスして整理します。企業に属して仕事で使うときはGemini CLIのバックエンドはVertex AIという選択肢しかなと思います。

Gemini CLIを使う経路は大きく2つ：

  1. Gemini API（Google AI Studioキー） … 手軽だが、GCP統制・データ管理の観点では限定的。
  2. Vertex AI（GCP統合） … プロジェクト/ロケーション/監査/IAMで統制しやすい。本記事は こちら を前提。

⚠️ セキュリティ注記（事実ベース）

  • Gemini API（AI Studioキー）: 公式の追加利用規約に、品質向上と製品改善のために人間のレビュアーが API 入出力を閲覧・注釈・処理する場合がある旨が記載されています。また機密・個人・センシティブ情報は提出しないよう求められています（無料枠“Unpaid Services”では特に注意）。有料枠でも不正利用検知などの目的で一定期間ログが保持され得ます。
  • Vertex AI（Google Cloud）: **Training Restriction（学習制限）**により、事前の許可または指示なしに、提示したデータが Google の基盤モデルの学習/微調整に使われることはないと明示されています。あわせて、レイテンシ低減のためのキャッシュが最大24時間保持される仕様があります（プロジェクト境界内の取り扱い）。

結論: 企業の機密データを扱う運用は Vertex AI 前提で設計し、AI Studioキー（Gemini API）は PoC/個人実験に限定するのが安全策です。

さらに Vertex AI には2つの認証パターン：

  • Express Mode（APIキー） … 検証用に早い。が、本番は鍵運用の手間と漏洩リスクあり。
  • 標準（OAuth/ADC + SA impersonation） … 企業利用の本命。鍵レスで監査/権限分離が効く。

基本の流れ（この記事の中心トピック）

  1. Gemini CLI をインストール（nvm 管理の Node 20+）。
  2. Vertex AI モードを有効化：GOOGLE_GENAI_USE_VERTEXAI=true を設定。
  3. 認証方式を選択：本番は ADC + SA impersonation（鍵レス）推奨。検証のみ Express Mode（APIキー）。
  4. Project / Location / Model を指定：GOOGLE_CLOUD_PROJECT、GOOGLE_CLOUD_LOCATION（例: us-central1）、GEMINI_MODEL（例: gemini-2.5-pro）。
  5. 動作確認：gemini -m "$GEMINI_MODEL" -p "疎通テスト"。

以降の章で、上記 1〜5 を順に詳細化します。nvm で遭遇しやすい罠は 「5. トラブルシュート」 に備忘録として集約。

1. 前提と準備

1-0. gcloud CLI（事前準備）

インストール

  • クイックインストーラ（公式推奨・対話式）
    curl https://sdk.cloud.google.com | bash
exec -l $SHELL

動作確認

gcloud --version
gcloud config list

初期設定（プロジェクト既定値の設定）

gcloud config set project <PROJECT_ID>

認証（gcloud auth login / gcloud auth application-default login）や SA のインパーソネーションは 3章 で実行します。

1-1. GCP プロジェクト準備

  • Billing 有効化
  • APIs: Vertex AI API を有効化
  • ロケーション: us-central1 を推奨（モデル対応が広い）

1-2. IAM 設計（最小権限）

  • 予め 実行用サービスアカウント（例: svc-vertex-cli@<PROJECT_ID>.iam.gserviceaccount.com） を作成。
  • そのSAに roles/aiplatform.user を付与（プロンプト実行に最低限）。
  • 必要に応じて 組織ポリシーで サービスアカウント鍵の作成禁止 を有効化（鍵レス徹底）。

メモ: モデル指定ミスやリージョン不一致は 404/NotFound を生みやすい。後述の「トラブルシュート」を参照。

2. ローカル（Linux）セットアップ

2-0. EACCES回避のためにnvmをインストール（npm/nvmの知識がある人は読む必要なし）

  • Node Version Manager の略。ユーザー単位で Node.js と npm の複数バージョンを共存・切替できる管理ツール。
  • なぜ使う？ ① npm -g の権限問題（EACCES）を回避、② 再現性（プロジェクトごとに Node を固定）、③ sudo不要・システムと分離。
  • どう動く？ シェル起動時に $NVM_DIR/nvm.sh を読み込んで PATH を切り替え。Node 本体は ~/.nvm/versions/node/ 配下に格納。
  • 基本コマンド：
    nvm --version          # nvm自体のバージョン
nvm install --lts      # LTS版を導入
nvm use 20             # v20系を使用
nvm alias default 'lts/*'  # 既定をLTSに固定
nvm ls                 # インストール済み一覧
nvm cache clear        # キャッシュ掃除
  • プロジェクトで固定する（推奨）：.nvmrc を置くと nvm use で自動切替。
    echo "20" > .nvmrc
nvm use                 # .nvmrc のバージョンを読む
  • やらないこと：sudo npm -g、/usr/bin/node の削除、npm config set prefix でグローバル先をシステムに向ける。
  • 落とし穴：シェルで nvm を読み込んでいない／PATH競合／CIの非ログインシェル。対処は本稿「7. トラブルシュート」を参照。

2-1. nvm で Node 20+ を導入

  1. シェルを確認
echo $SHELL

/bin/bash なら ~/.bashrc、/bin/zsh なら ~/.zshrc を後で更新します。

  1. nvm を導入（非 root / ユーザー毎）
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash
  1. シェルを再読み込み
source ~/.bashrc   # zsh の場合は source ~/.zshrc
  1. Node LTS を導入して既定に設定
nvm install --lts
nvm alias default 'lts/*'
nvm use --lts
  1. PATH の優先度を確認
node -v && npm -v
which node   # => ~/.nvm/versions/node/vXX/bin/node を指すこと

Why nvm? npm -g がシステム領域（/usr/local/...）へ書き込みに行って EACCES を出す問題を回避し、開発者ごとに Node を隔離できます。sudo npm -g は権限のねじれ・再現性低下を招くため避けます。

2-1b. 既にシステムに Node が入っている場合の注意

  • 既存の /usr/bin/node は他ツールが使うことがあるため 無理に削除しない。nvm を 先に読み込む ことで上書きします。
  • ~/.bashrc / ~/.zshrc の早い位置に以下を追記：
export NVM_DIR="$HOME/.nvm"
[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh"  # This loads nvm
[ -s "$NVM_DIR/bash_completion" ] && . "$NVM_DIR/bash_completion"
  • その後 which node が ~/.nvm/... を指せばOK。
  • グローバル npm は nvm 管理下で実行（sudo を使わない）。
  • どうしても競合する場合のみ、影響範囲を理解したうえで apt remove nodejs 等を検討。

2-2. Gemini CLI を導入

# グローバルに入れる（推奨）
npm install -g @google/gemini-cli
# あるいはインストール不要で即時起動
npx @google/gemini-cli

Node v20+ 必須。brew install gemini-cli（Linuxbrew）でも可。

3. Vertex AI での“安全な”認証・起動

パターンA（推奨）：ADC + SA impersonation（鍵レス）

  1. ログイン & ADC 設定
# まず自分のユーザーでログイン
gcloud auth login
# このセッションで常に SA を impersonate（短期トークン）
gcloud config set auth/impersonate_service_account \
  svc-vertex-cli@<PROJECT_ID>.iam.gserviceaccount.com
# ADC を作成（CLIやSDKが拾う既定資格情報）
gcloud auth application-default login
  1. 環境変数（Vertex AI 利用を明示）
export GOOGLE_GENAI_USE_VERTEXAI=true
export GOOGLE_CLOUD_PROJECT=<PROJECT_ID>
export GOOGLE_CLOUD_LOCATION=us-central1
export GEMINI_MODEL=gemini-2.5-pro
  1. 動作確認
# 対話モード
gemini
# 単発実行
gemini -m "$GEMINI_MODEL" -p "疎通テスト: 200字で自己紹介"

うまくいかない場合は gcloud config get-value auth/impersonate_service_account と ~/.config/gcloud/application_default_credentials.json を確認。

パターンB（検証用｜非推奨）：Vertex AI Express Mode（APIキー）

  1. APIキー発行（Vertex AI Express）

  2. 環境変数

export GOOGLE_GENAI_USE_VERTEXAI=true
export GOOGLE_API_KEY=<EXPRESS_MODE_API_KEY>
export GOOGLE_CLOUD_LOCATION=us-central1
export GEMINI_MODEL=gemini-2.5-pro
  1. 実行
gemini -m "$GEMINI_MODEL" -p "疎通テスト（Express Mode）"

注意: 通常の Vertex AI エンドポイントは APIキー非対応。Express Mode 以外でAPIキーを使うと UNAUTHENTICATED / Expected OAuth2 になる。

用語メモ：ADC（Application Default Credentials）

ADC は「今この環境で使うべき認証情報を自動発見する仕組み」。コードやCLIは固定の探索順（環境変数 → gcloud の ADC → メタデータサーバ → WIF (Workload Identity Federation) /インパーソネーション等）で資格情報を取得します。

なにが嬉しい？

  • ローカル/CI/クラウドを 同じ書き方 で動かせる（鍵のパス埋め込み不要）
  • 本番は 鍵レス運用（メタデータサーバ or WIF (Workload Identity Federation) + インパーソネーション）

ローカルの基本コマンド

gcloud auth application-default login
gcloud config get-value account
gcloud config get-value auth/impersonate_service_account
gcloud auth application-default print-access-token | head -c 20 && echo

落とし穴メモ

  • 標準の Vertex AI は OAuth/ADC 想定。APIキーは Express Mode 専用
  • JSON鍵の配布は原則禁止。WIF(Workload Identity Federation) / インパーソネーションで短期トークンを使う

4. 設定ファイルでの固定化（チーム運用）

  • ~/.gemini/.env または <repo>/.gemini/.env に環境変数を記載（プロジェクト単位で切替）。
  • ~/.gemini/settings.json でテーマ・サンドボックス・チェックポイント等の既定値を統一。
  • GEMINI_MODEL も .env で固定すると迷子にならない。

例: .gemini/.env

GOOGLE_GENAI_USE_VERTEXAI=true
GOOGLE_CLOUD_PROJECT=<PROJECT_ID>
GOOGLE_CLOUD_LOCATION=us-central1
GEMINI_MODEL=gemini-2.5-pro

5. トラブルシュート（よくあるハマり）

5-1. まずはここを見る（頻出事象と即効薬）

症状 原因 対処
EACCES: permission denied, mkdir '/usr/local/lib/node_modules/...' npm -g がシステム領域に書込 nvmで再インストール / npx を使う
UNAUTHENTICATED: API keys are not supported... Expected OAuth2 標準の Vertex AI を APIキーで叩いている ADC or SA impersonation を使う / あるいは Express Mode のAPIキーに切替
404/NotFound（モデル） モデル名の退役/リージョン未対応 gemini-2.5-* に更新／us-central1 に固定
PERMISSION_DENIED IAMロール不足 実行主体に roles/aiplatform.user 付与
gemini: command not found PATH が nvm 管理の Node に向いていない シェル起動で nvm を読み込む（下記 A を参照）
npm ERR! Tracker 'idealTree' already exists など npm キャッシュ破損/競合 npm cache clean --force → 再実行、Node を入れ直す

6. 小さなレシピ集

  • 一発で単発応答（非対話）
    gemini -m gemini-2.5-pro -p "プロダクトの1文エレベーターピッチを作成"
  • プロジェクトごとの設定を固定
    mkdir -p .gemini
cat > .gemini/.env << 'EOF'
GOOGLE_GENAI_USE_VERTEXAI=true
GOOGLE_CLOUD_PROJECT=<PROJECT_ID>
GOOGLE_CLOUD_LOCATION=us-central1
GEMINI_MODEL=gemini-2.5-pro
EOF

おわりに

本稿は「とりあえず動かす」ではなく、安全に動かすための最小構成をまとめた備忘録です。Gemini CLIについては今後も検証を続けていこうと思います。

Discussion