はじめに
こんにちは。DTダイナミクスのFACommonチームでmeviyの開発を担当している張です。
普段の業務に加え、社内ではAI Native開発の推進メンバーとして、AIを活用した開発プロセス改善やツール導入の支援も行っています。
最近、この活動の一環として、開発者がより効率的にGeminiモデルを利用できるよう、Gemini CLIの導入と環境整備を主導しました。
本記事では、この導入経験を基に、以下の2点について詳しく解説します。
- Vertex AIを利用した安全な認証・認可設計
- 最小権限の原則に基づいたIAMの構築方法
セキュアなAI活用環境を整備する上で、この記事が少しでも参考になれば幸いです。
Gemini CLIとVertex AI:基本をおさえる
Gemini CLIの役割
Gemini CLIは、Googleが提供するGeminiモデルをターミナルやスクリプトから直接利用するためのコマンドラインツールです。主な用途として、以下のような場面で役立ちます。
CLIベースであるため、複雑なSDKの導入なしに、すぐにGeminiの機能を試せるのが大きな特徴です。
Vertex AI経由で利用するメリット
Gemini CLIは、バックエンドでVertex AIを経由してGeminiモデルを呼び出します。これにより、単にモデルを利用するだけでなく、エンタープライズ向けの堅牢な基盤を享受できます。
- IAMによる詳細な権限制御 利用者や用途に応じて、必要最低限の権限(最小権限)を割り当てられます。
- 監査ログによるトレーサビリティ確保 誰が、いつ、どのモデルを利用したかを記録・追跡でき、セキュリティとコンプライアンスを担保します。
- APIキー不要のセキュアな認証 サービスアカウント認証を用いるため、APIキー漏洩のリスクを根本から排除できます。
- コスト管理と利用状況の可視化 Vertex AIのダッシュボードで、コストやリソースの使用状況を容易に把握できます。
安全な認証フローの全体像
Gemini CLIを安全に利用する鍵は、Google Cloudの認証フロー、特にサービスアカウントの権限借用(impersonation)にあります。 以下の図は、開発者のPCからVertex AI(Gemini)に至るまでの認証と権限委譲のフローを表します。
認証フローの全体図

フローの解説
- 開発者の認証:
gcloud auth application-default login --impersonate-service-account SERVICE_ACCT_EMAILを実行し、開発者個人の資格情報(ADC)を取得します。 - ADCの利用: Gemini CLIは、ローカルに保存されたADCを自動で利用してGoogle Cloudにアクセスします。
- 権限借用 (Impersonation): 開発者の資格情報を使い、あらかじめ定義されたサービスアカウント(SA)の権限を一時的に借用します。
- Vertex AIの呼び出し: 借用したSAの権限で、Geminiモデルへのリクエストが安全に実行されます。
この認証方式は、開発者個人の権限を最小限に保ちつつ、必要な操作のみをサービスアカウントに委任できるため、非常にセキュアです。APIキーのような漏洩リスクのある認証情報を扱う必要もありません。次のセクションで、この仕組みを支えるIAM設計について詳しく見ていきましょう。
最小権限を実現するIAM設計
Gemini CLIを安全に運用するための核心は、サービスアカウント(SA)に付与するIAM権限を最小限に抑える「最小権限の原則」の実践です。 ここでは、実際に社内で導入した設計思想と具体的な設定例を紹介します。
基本方針:権限をユーザーではなくSAに集約する
IAM設計では、以下の3つの原則を徹底します。
- 開発者個人のアカウントに強い権限を与えない
- サービスアカウント側に必要最小限の権限を集約する
- 権限借用(impersonate)を必須とし、直接的な権限利用を避ける
このアプローチにより、万が一の誤操作やアカウント侵害が発生した際の影響範囲を限定し、リスクを大幅に低減できます。
サービスアカウント(SA)の具体的な設計
推奨する構成は以下の通りです。
- 用途別のSA作成: 1つのGoogle Cloudプロジェクトにつき、Gemini利用専用のSAを1つ作成します。
- 事前定義ロールの活用: SAには事前定義ロール
roles/aiplatform.userを付与します。 - 開発者への権限付与: 開発者には、このSAを借用(impersonate)できる
iam.serviceAccountTokenCreatorロールのみを付与します。
これにより、SAの権限と開発者の権限が明確に分離され、管理がシンプルになります。
実践的な権限設定:なぜroles/aiplatform.userが必要なのか
理論上の最小権限とその落とし穴
理論上、Gemini CLIがモデルを呼び出すために必要な権限は以下の2つだけです。
aiplatform.endpoints.predict(推論の実行)aiplatform.locations.list(利用可能なロケーションの取得)
しかし、実務上この最小構成では問題が発生することがあります。
Token count exceedsエラーの発生
上記2つの権限のみでは、Vertex AIの処理に制約が生じ、入力テキストが適切に処理されない可能性があり、 その結果、以下のようなエラーが高頻度で発生すると考えられます。
status: { code: 3, message: "The input token count (XXXXX) exceeds the maximum number of tokens allowed (65536)" }
結論:roles/aiplatform.userの利用が安定稼働の鍵
このトークン数超過問題を回避し、Vertex AIの機能を安定して利用するには、SAに事前定義ロールであるroles/aiplatform.userを付与するのが最も確実な方法です。
カスタムロールによる細かな権限管理の代わりに、事前定義ロールを利用することには以下のような明確なメリットがあります。
- 包括的な権限セット:
aiplatform.endpoints.predictやaiplatform.locations.listはもちろん、Vertex AIが内部で利用する補助的な権限がすべて含まれており、権限不足に起因する予期せぬエラーを防ぎます。 - 優れたメンテナンス性: Googleがプラットフォームの更新に合わせてロールを自動でメンテナンスするため、自前で権限変更を追従する必要がなく、長期的な運用コストを削減できます。
一方で、開発者側に必要な権限はiam.serviceAccountTokenCreatorだけで十分です。これにより、開発者はSAを借用できますが、モデルを直接利用する権限は持たないため、安全な運用が担保されます。
まとめ
本記事では、Gemini CLIをVertex AIと組み合わせて安全に運用するための、具体的な認証・認可設計について解説しました。
重要なポイントは以下の通りです。
- 認証はサービスアカウントのimpersonationを前提とする: 開発者個人の権限に依存せず、APIキーも不要なセキュアな方法を採用する。
- 権限は最小限かつシンプルに: サービスアカウントにはメンテナンス性に優れた事前定義ロール
roles/aiplatform.userを利用し、開発者には権限借用(impersonate)のためのiam.serviceAccountTokenCreatorロールのみを付与する。 - 監査ログの活用: Vertex AIの監査ログを監視し、利用状況を把握することで、継続的に安全な運用体制を維持する。
私たちが社内で環境を整備した際も、これらの仕組みを導入することで、開発者がセキュリティを気にすることなく、安心してGeminiの活用に集中できる環境を実現できました。
この記事が、皆さんの組織で安全なAI活用基盤を構築する一助となれば幸いです。