はじめに
テックタッチで SRE をしている masao です。
最近、趣味のマラソンで日々の練習メニューからレース当日のペース配分まで生成 AI に提案、管理してもらうようにした結果、自分で考えることが減り、走ることに集中できるようになりました。業務・プライベートを問わず、生成 AI を様々な場面で活用できるようになってきていると感じています。
このように生成 AI の活用が急速に広がる中、Apple が Apple Foundation Models に Google の Gemini を採用すると発表したように、外部の高機能な生成 AI モデルをいかに安全に利用できるかが重要になってきていると思います。
外部の生成 AI モデルの利用が盛んになったことでセキュリティとガバナンスの強化が不可欠です。本記事では、外部モデルとして Google Cloud の Gemini をマルチクラウド環境で利用するにあたり、堅牢かつ広範なセキュリティとガバナンスを実現するための多層防御の例を IaC（Terraform）のソースコードを含めて紹介します。
本記事では AWS の ECS 環境から Google Cloud の Vertex AI を利用するケースを取り上げます。 Vertex AI は Google Cloud が提供するフルマネージドの AI プラットフォームです。Gemini をはじめとする生成 AI モデルの学習、デプロイ、監視などを一元管理でき、他の Google Cloud サービスと同様に IAM による詳細な権限管理や組織ポリシーによる一括制御が可能です。
Google Cloud では他に Gemini API がありますが、以下の点から商用アプリケーションへの組み込みにおいて統制が難しいため、本記事の対象外となります。
- 組織ポリシーの適用外：利用モデルの一括制限や特定機能の無効化ができない
- データ処理場所の指定不可：特定のリージョンでの実行、データ保存の制限ができない
- 監査ログ（Audit Log）非対応：誰がいつどのモデルを利用したか等のトレーサビリティ確保が困難
- API キーを用いた認証：キーの管理やローテーション対応が必要
逆ピラミッド型の多層防御
生成 AI を利用するにあたって考慮すべき点はたくさんありますが、代表的なものとして以下が考えられます。
- 生成 AI を利用するまでの通信は安全か
- どのように認証認可するか
- 認証情報が流出した場合の影響を最小限にできるか
- 生成 AI を安全に利用できるか
- 入力データを学習に利用されないか
- 入力データを閲覧されたり、流出した場合の責任はどうなるか
- データの保管場所はどこか（日本国内に留められるか）
- 推論（AI モデルによる計算処理）の実行場所はどこか
上記を考慮して、広範な統制から一意の制御へ絞り込んでいく「逆ピラミッド型の多層防御構造」を以下のように定義しました。
- 基盤層（組織ポリシー）
- 信頼層（Workload Identity Federation）
- 権限層（IAM プリンシパル）
基盤層
先ほどの課題における「生成 AI を安全に利用できるか」を実現するための要となる層です。
原稿執筆時点（2026 年 2 月）時点では、Gemini 3 Pro、Gemini 3 Flash いずれもプレビュー版のみの提供です。プレビュー版は生成 AI プレビュー版プロダクトに関する追加規約の対象となります。 最も重要な事項として生成 AI プレビューモデルは評価およびテストの目的でのみ利用することが許可され、以下の行為は禁止されています。
- 生成 AI プレビューモデルを商用または生産目的で使用する
- 生成された出力結果を第三者に開示する
加えて、Google Cloud の Service Specific Terms の「Pre-GA Offerings Terms」が適用されるため、以下のような制限や注意事項があります。（セキュリティおよびデータ保存に関する部分については Google Cloud サポートにも確認済みです）
- 書面による通知もしくは Google ドキュメントに明示的に記載されている場合を除き、Cloud のデータ処理に関する追加条項（CDPA）の対象外となるため、個人情報や法規制の要件のあるデータは処理しない
- Vertex AI については明示的な記載がないため、Google 側に閲覧や利用される可能性があります
- データの場所に関する条項が適用されない
- 日本国内に留めることが約束されません
- 万が一、Google 側の過失で何らかの損害が発生しても、賠償責任の上限は$25,000 である
- 現状のまま提供されており、SLA も適用されず、予告なくサービスが変更、中止となる可能性がある
そのため、非常に高性能な Gemini ですがプレビューモデルを商用で利用したり、機密情報を入力するようなことは避けねばなりません。
組織ポリシーの適用
対策として Google Cloud の組織ポリシーを使うことで、組織レベルもしくはプロジェクトレベルで Vertex AI で利用可能なモデルを定義することができます。
例えば個別のプロジェクトで Gemini 2.5 Flash モデルの推論のみを許可する場合は、Google Cloud コンソールで組織ポリシー vertexai.allowedModels を用いて以下のように設定することができます。vertexai.allowedModels ではワイルドカードが使えないため、ホワイトリストで制御します。
Terraform で組織ポリシーを IaC 管理する場合は google_org_policy_policy を用いて以下のように記載します。
resource "google_org_policy_policy" "vertex_ai_allowed_models" { name = "projects/${var.project_id}/policies/vertexai.allowedModels" parent = "projects/${var.project_id}" spec { rules { values { allowed_values = [ "publishers/google/models/gemini-2.5-flash:predict", ] } } } }
上記のポリシーを設定した状態で Gemini 3 Flash Preview モデルを使おうとすると以下のようなエラーとなり、確かにそのモデルでは利用ができないことが確認できます。
{
"error": {
"code": 400,
"message": "Organization Policy constraint constraints/vertexai.allowedModels violated for `projects/1234567890` attempting to use a disallowed Gen AI model gemini-3-flash-preview. Please contact your organization administrator to fix this violation by adding `publishers/google/models/gemini-3-flash-preview:predict` to the allowed values. For more info, see https://cloud.google.com/vertex-ai/generative-ai/docs/control-model-access.",
"status": "FAILED_PRECONDITION"
}
}
データの保管場所と推論の実行場所
さて、もう一つの課題であるデータの保管場所と推論の実行場所についてです。Google Cloud では全世界のリソースを使えるグローバルエンドポイントと地域限定のリージョナルエンドポイントがありますが、日本に閉じて利用したい場合はリージョナルエンドポイントとして asia-northeast1 を指定する必要があります。
組織ポリシーにリソースロケーションの制約ポリシーがあるのでそちらで制御できそうに思えますが、SDK や REST API は対象外なので効果がありません。Google にて issue 化されていますがあまり動きはないようです。
また IAM 条件で以下のような CEL（Common Expression Language）による制御も試みましたが、Google 提供のベースモデルについては効果がないどころかそもそも locations でマッチしないので全てのモデルで実行できなくなりました。（Google 提供のベースモデルのリソースが IAM 条件に非対応であることは Google Cloud サポートに確認済みです）
resource.name.extract('/locations/{loc}/') == 'asia-northeast1'
よって、地域の制限に関しては組織ポリシーもしくは IAM 条件の対応を待つ必要があるので、ひとまずワークアラウンド対応としてアプリケーション側でロケーションを asia-northeast1 に固定することとし、開発ドキュメントにルールを記載して、生成 AI のレビューで担保するのが良いかと思います。
信頼層
次に必要なのは、外部環境である AWS から Google Cloud へ、いかにセキュアにアクセスするかという認証の部分です。
外部環境から Google Cloud の Vertex AI API を呼び出すには以下のいずれかの方法が必要です。
- サービスアカウントをバインドした API キー
- サービスアカウントキー
- Workload Identity 連携（サービスアカウントの権限借用方式）
- Workload Identity 連携（Identity Pool に紐づくプリンシパルによる直接アクセス方式）
API キーおよびサービスアカウントキーは手軽に利用できますが、現在の Google Cloud の組織ポリシーではデフォルトで発行不可になっていますし、漏えいリスクへの対策（定期的なローテーションなど）が必要となるため商用アプリケーションへの組み込みにおいては避けたい選択肢です。
残り2つの選択肢のうち、AWS に慣れている開発者には Assume Role と同じ考え方であるサービスアカウントの権限借用方式がわかりやすいですが、実は Identity Pool に紐づくプリンシパルに IAM ロールを直接付与すれば、サービスアカウントを作成する必要がありません。
この場合、以下の図で示しているサービスアカウントの権限借用（Impersonation）のステップを省略できるため通信を簡略化することができます。
また、権限借用方式では Google Cloud 上でのアクセス者はサービスアカウントになるため、実際の外部アクセス者は監査ログで delegation 情報を見ないと確認できませんが、Identity Pool の場合は外部アクセス者のロール名をダイレクトに確認できます。
Identity Pool の設定は Google Cloud コンソールからももちろん可能ですが、詳細な手順は公式ドキュメントに譲り、本記事では実務的な再現性を重視して、次章の「権限層」にて Terraform による実装例をカスタムロールとあわせて紹介します。
WIF 連携における実装上の注意点
AWS の ECS 環境から Google Cloud に Workload Identity 連携するにあたっては実装上の制約があります。Google Cloud コンソールからダウンロードできる「外部認証情報の設定ファイル」や Google Cloud の Go SDK は EC2 インスタンスのみをサポートしており、ECSタスク から利用する場合には externalAccount の実装をオーバーライドするなどの工夫が必要です。
（認証情報の EC2 インスタンス の IMDS v2 メタデータエンドポイントを ECS メタデータエンドポイントに書き換えても通信プロトコルが異なるためそのままでは動きません）
AWS の一時認証情報の環境変数（AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、 AWS_SESSION_TOKEN）を上書きする方法もありますが、こちらはクレデンシャルを定期的に更新する必要があるため継続して利用する際には処理が複雑になります。
一方で externalAccount のオーバーライド方式であれば Credential クラスの自動リフレッシュや遅延実行の仕組みが使えるため堅牢かつ安全に利用できます。
ですが、昨今のマルチクラウド構成を考えると Go SDK が ECS タスクからの認証に対応していないというのは運用上での懸念点です。そこで Go SDK の実装を調査し、ECS タスクからの認証を標準サポートするよう Go SDK のリポジトリに issue を立てて設計を提案したところ、メンテナに受理され Google の内部チケットでフォローアップしてくれることとなりました。
権限層
さて、セキュアな接続は上記で確立できましたが、それでも認証情報の流出の可能性はゼロではありませんし、万が一流出した場合に備えて必要最小限の権限にとどめておく必要があります。
Gemini でコンテンツ生成のみを実行するのであれば、 generateContent の権限があれば十分です。
カスタムロールと Identity Pool を作成し、それらを紐付ける Terraform 実装は以下の通りです。
本記事のソースコードを apply し、アプリケーションから利用するには、プロジェクトで以下の API が有効である必要があります。
- IAM：
iam.googleapis.com - Cloud Resource Manager：
cloudresourcemanager.googleapis.com - Organization Policy：
orgpolicy.googleapis.com - STS：
sts.googleapis.com - Vertex AI：
aiplatform.googleapis.com
# Vertex AI 呼び出しに必要な最小権限を付与したカスタムロール resource "google_project_iam_custom_role" "this" { project = var.project_id role_id = "geminiGenerateContent" title = "Gemini GenerateContent" permissions = [ "aiplatform.endpoints.predict", ] } resource "google_iam_workload_identity_pool" "this" { project = var.project_id workload_identity_pool_id = "aws-ecs-pool" display_name = "AWS ECS Pool" description = "Workload Identity Pool for AWS ECS tasks to access Vertex AI" } resource "google_iam_workload_identity_pool_provider" "this" { project = var.project_id workload_identity_pool_id = google_iam_workload_identity_pool.this.workload_identity_pool_id workload_identity_pool_provider_id = "aws-ecs-provider" display_name = "AWS ECS Provider" aws { account_id = var.aws_account_id } attribute_mapping = { "google.subject" = "assertion.arn" "attribute.aws_role" = "assertion.arn.extract('assumed-role/{role}/')" "attribute.aws_account" = "assertion.account" } attribute_condition = "assertion.arn.startsWith('arn:aws:sts::${var.aws_account_id}:assumed-role/${var.ecs_role}/')" } resource "google_project_iam_member" "this" { project = var.project_id role = google_project_iam_custom_role.this.id member = "principalSet://iam.googleapis.com/${google_iam_workload_identity_pool.this.name}/attribute.aws_role/${var.ecs_role}" }
これでもし万が一、認証情報が流出してしまい有効期限内に何かしようとしても Gemini 2.5 Flash モデルでコンテンツ生成する以外のことはできず、クラウド環境から情報が流出することも莫大な費用が発生することもありません。
まとめ
生成 AI の進化スピードは目覚ましく、2026 年現在も新しいモデルや新機能のリリースが絶えず行われています。今回、組織ポリシーや Workload Identity Federation、IAM といった「多層防御」を構築したのは、開発者を縛るためではありません。むしろ、「ここまでは安全である」という境界線を引くことで、開発者が余計な不安を抱えず、Gemini という強力なツールを安心して利用できるようにするためです。
生成 AI の活用が広がる中、ガバナンスを適切に設計しセキュリティを確保することで、安心して高機能なモデルを活用できる環境を構築できます。本記事が、マルチクラウド環境での生成 AI 導入の参考になれば幸いです。
