Google Cloud では Gemini や Vertex AI などの AI 機能を有効化してAPI利用ができます。
一方で、ガバナンスやコスト管理の観点からプロジェクトごとにAI機能の利用を制限したいというニーズも弊社のお客様の中でありました。
本記事では、Google Cloud 上でAI機能の利用を柔軟に制御する機能について解説します。
IAM
まず基本となるのは IAM (Identity and Access Management) によるアクセス制御です。
AI 機能を利用させたいプリンシパル(ユーザー,サービスアカウント,グループ)に、例えば以下のようなロールを付与します。
- Vertex AI User:
roles/aiplatform.user - Gemini for Google Cloud User:
roles/cloudaicompanion.user
Editor や Owner は本来避けた方が良いものの何らかの事情でPrimitiveなロールを使用している場合はIAMによるコントロールには限界があります。
VPC Service Controls
VPC Service Controls は、プロジェクト間や外部とのデータ境界を定義し、許可されたネットワークや特定のパブリックIP からのみAPIを利用できるようにする仕組みです。
主に多層防御としての機能を果たし、IAMや後述の組織ポリシーと併用することで、より強固なセキュリティ境界を構築できます。
VPC SCはサポートされているAPI一覧がありますので適宜公式ドキュメントを参照してください。
現状、Vertex AI 系は対応されていますが、Gemini API は未対応です。
組織ポリシー
AI 機能をプロジェクト単位で確実に制御する方法は 組織ポリシー (Organization Policy) の利用です。組織・フォルダ・プロジェクトの階層ごとに柔軟に適用できます。
組織ポリシーでサポートされている制約一覧は以下です。
リソースサービスの利用を制限
組織ポリシーの constraints/gcp.restrictServiceUsage という制約を用いることで、指定した階層(フォルダやプロジェクト)における特定のAPI（今回の場合はVertex AIやその他のAI関連API）の利用を禁止/許可ができます。
例:
- 組織全体で Vertex AI を禁止
- 特定プロジェクトのみ許可（オーバーライド）
こちらもVPC SCと同様、サポートされているAPIに限りがあり、Vertex AI系等は全て対応されていますが、Gemini APIの制限はリストにないです。
設定が効いていると、対象プロジェクトのコンソールでアクセス時に以下のようなエラーが表示されます。
利用モデルの制限
constraints/vertexai.allowedModelsによってModel Gardenで選択するVertex AIで利用できるモデルを制限することができます。
拒否リストを登録することもできますが基本的には許可リストのケースが多いと思います。
プレビューや新規のモデル等を拒否リストで追従するのは現実的でないというのが個人的見解です。
許可・拒否リストを登録する際はフォーマットが決まっていて、例えば Gemini 2.5 Flash のみを許可する場合は以下のような形式になります。
publishers/google/models/gemini-2.5-flash:predict
フォーマットについては公式を参照。
制約が有効になると、許可されていないモデルを選択した場合は利用できません。
この例では、Gemini 2.5 Flashは許可しているので以下のように Model GardenのページからVertex AI Studioを開くことができます。
Vertex AI Studio上でも同様に、許可外モデルを切り替えて実行しようとすると適切に利用制限されます。
Google Workspaceでの制御
これまで解説してきたのは、Google Cloud 内での制御方法です。しかし、Gemini API は VPC Service Controls や組織ポリシーの対象外であることも述べました。
そのため、以下のサービスを含む Gemini 系機能を組織レベルで利用制限したい場合は、Google Workspace 側の設定によって制限する必要があります。
- Gemini
- Google AI Studio
- NotebookLM
例えば、Gemini API キーは Google AI Studio で発行されますが、この API キーはユーザー自身または組織内の Google Cloud プロジェクトに紐づきます。
IAM の制御が緩いプロジェクト（前述の Primitive role を利用している検証用プロジェクトなど）が組織内に存在する場合、どのユーザーでも実質的に Gemini API を有効化できてしまう可能性があります。
組織ポリシーでは Gemini API の利用制御ができないため、Google Workspace 側での管理も重要なポイントとなります。
まとめ
- IAM → 基本的な権限付与の制御
- VPC SC → サービスへのアクセス制限
- 組織ポリシー → プロジェクト単位でのサービス利用禁止 / モデル利用制限
- Workspace 管理 → Google Cloudでの制御ができない範囲(Gemini API や Google AI Studio) の利用制御
これらを組み合わせることで、組織に適したAI利用ガバナンスを実現できます。参考になれば幸いです。
長崎を拠点とするシステム開発会社です。 地方からでもモダンな開発をテーマに、クラウドネイティブかつセキュアなアプリケーション開発、インフラ構築等を手がけています。最近はAI駆動開発にも注力しています。
Discussion