Google Cloud Japan
📝

プロンプト入力はもう古い？法務のルール改定がそのままインフラコードに直結する「Agentic CI/CD」入門

Nozo Yoshida
に公開
Google Cloud
Google Cloud
CI/CD
Agent
Gemini
tech

はじめに

企業におけるクラウドインフラの監査やセキュリティポリシーの適用は、長らく「法務やセキュリティ部門が作成したドキュメント（理想）」と「エンジニアが書くコード（現実）」の間に深い溝があり、監査違反や設定漏れのリスクを抱えてきました。

本記事では、Google Workspace の機密ドキュメントをソースとして、AIエージェントが自律的にインフラコードである Terraform を修正し GitHub にプルリクエスト（PR）を出す、いわば「ドキュメント駆動型動的ガバナンス」を構築します。なお、セクションごとに関連するドキュメントも付記しているので、適宜ご参照ください。

【本ハンズオンの3つのポイント】

  1. APIキー不要・エンタープライズAIの活用: 万が一漏洩すると危険な API キー は使わず、顧客データが学習に使われない、エンタープライズ向けAIプラットフォームである Vertex AI を使用。
  2. 完全なゼロトラスト・セキュリティ: 機密文書（Docs）の読み込みから、AIの推論まで、すべて Google Cloud の「1つのサービスアカウント（IAM）」のみでセキュアに一元管理。
  3. 安全な Human-in-the-loop: AIが勝手に本番環境を変更するのではなく、エンジニア宛に PR を自動起票し、最後の Approve（承認）は人間が行うガバナンスを維持します。

大枠の流れはこのようになります。

システム構成図

アーキテクチャとデータの流れは以下のようになります。

イメージが湧きやすいように、簡単なサンプルのデモ動画を録りました。
https://www.youtube.com/watch?v=pdxjoqUg2zU

事前準備（要件）

  • Google Cloud プロジェクト（Cloud Shell 利用・課金有効化済）
  • Google Workspace アカウント（制限付きDocsの作成用）
  • GitHub アカウント

Step 1: 【Cloud Shell】各種APIの有効化とエージェント用SA（社員証）の発行

Google Cloud コンソールを開き、画面右上の 「Cloud Shell をアクティブにする（>_ アイコン）」 をクリックしてターミナルを起動します。以降の作業はすべてこのターミナルで行います。

まず、Docs読み取り用の Drive API と、AI推論用の Vertex AI API を有効化し、サービスアカウント（SA）に両方の権限を付与して JSON キーを発行します。以下のコマンドを順に実行してください。

# 1. 作業用ディレクトリの作成
mkdir agent-demo && cd agent-demo

# 2. Drive API および Vertex AI API の有効化
gcloud services enable drive.googleapis.com aiplatform.googleapis.com

# 3. プロジェクトIDの取得とSAの作成
export PROJECT_ID=$(gcloud config get-value project)
export SA_EMAIL="policy-agent@${PROJECT_ID}.iam.gserviceaccount.com"
gcloud iam service-accounts create policy-agent --display-name="Policy Agent"

# 4. SA に Vertex AI の実行権限と「APIクォータ消費権限」を付与
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member="serviceAccount:${SA_EMAIL}" \
  --role="roles/aiplatform.user"

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
  --member="serviceAccount:${SA_EMAIL}" \
  --role="roles/serviceusage.serviceUsageConsumer"

# 5. JSONキー（社員証）を発行してカレントディレクトリに保存
gcloud iam service-accounts keys create sa-key.json \
  --iam-account=${SA_EMAIL}

# 6. エージェントのメールアドレスを表示（※次のステップで使うのでコピーしてください）
echo -e "\n✅ 【重要】Docs に招待するメールアドレス:\n${SA_EMAIL}\n"

これで、Cloud Shell 上に sa-key.json が配置されました。

サービスアカウントや Google Drive API については以下のドキュメントを参照ください。
https://cloud.google.com/iam/docs/service-account-overview
https://developers.google.com/drive/api/guides/about-sdk

Step 2: 【GWS側】「制限付き」の機密Docsを作成し、SAを招待する

ブラウザの別タブで Google Docs を開き、ポリシーの源泉となるドキュメントを作成します。

  1. 新規作成します。今回はタイトルを 「【社外秘】全社クラウドセキュリティ基準」 とします。

  2. 本文に以下の ポリシー全文 をコピーして貼り付けます。 （AIが無関係な条項の中からインフラに関する該当箇所だけを自律的に見つけ出せるかを確認するため、関係のない箇所も記述を入れています。）

【社外秘】全社クラウドセキュリティ基準（v1.0）

第1章 総則 第1条（目的） 本基準は、当社が利用するパブリッククラウド環境における情報漏洩および不正アクセスを防止し、安全なシステムインフラを維持するための最低遵守事項を定める。

第2条（適用範囲） 当社のすべての役員、従業員、および業務委託先が構築・運用するすべての Google Cloud プロジェクトに適用する。

第2章 インフラ構築要件 第3条（認証とアクセス制御） クラウド環境へのアクセスには、例外なく多要素認証（MFA）を有効化しなければならない。

第4条（ネットワークの保護） 本番環境のデータベース（Cloud SQL等）にはパブリックIPを付与せず、VPC内のプライベートIPのみで構成すること。

第5条（クラウドストレージの保護） 情報漏洩を防ぐため、当社のすべての Google Cloud Storage バケットは、「公開アクセスの防止（Public access prevention）」を継承（inherited）のままでよい。

  1. 右上の「共有」ボタンを押します。

    • 一般的なアクセスは 「制限付き（Restricted）」のまま にします。
    • ユーザー追加欄に、Step 1でターミナルに表示されたSAのメールアドレスを入力し、「閲覧者」として追加します。

  1. DocsのURLバーから ドキュメントID（/d/ と /edit の間の長い文字列）をコピーしてメモしておきます。

【FAQ】他社のWordツールのAPIでも連携できるのでは？

テキスト抽出だけであれば他社製APIでも可能ですが、Google Workspace（Google Docs）を採用する優位性は以下の2点です。

  1. セキュリティ境界（IAM）の完全な統合: 1つのサービスアカウントを発行するだけで、機密ドキュメントへのアクセスと AI の推論権限を同一のセキュリティ境界内で透過的に管理できます。SaaSを跨ぐ複雑な認証連携（OIDC等）や二重の権限管理が不要になり、ゼロトラスト構築が極めて容易になります。
  2. 同期コラボレーション×AI のシナジー: ファイルベースのツールに対し、GWSは「リアルタイムな共同作業のキャンバス」です。例えばシステム障害時、「Google Chat で飛び交うエンジニアの会話をエージェントが読み取り、Docs の障害報告書を自動タイピングしつつ、裏側の別エージェントがインフラ修正PRを出す」といった動的な War Room（対策本部）の構築は、GWS のシームレスなエコシステムならではのユースケースです。

Step 3: 【Cloud Shell】GitHub の認証とインフラコードの準備

Cloud Shell には GitHub CLI (gh) と git が標準搭載されています。

1. GitHub へのログインと Git 初期設定

以下のコマンドを実行して認証を行います。

gh auth login

(対話型のプロンプトが出ます。以下のように選択してください)

  • What account do you want to log into? → GitHub.com
  • What is your preferred protocol for Git operations? → HTTPS
  • How would you like to authenticate GitHub CLI? → Login with a web browser (表示されたワンタイムコードをコピーし、提示されたURLをブラウザで開いて認証を完了させます)

続けて、Git のコミット設定を行います。

git config --global user.name "Policy Agent"
git config --global user.email "agent@example.com"

# PR起票先となる空の GitHub リポジトリをCloud Shellから作成
gh repo create demo-doc-driven-policy-update --public

2. 対象のインフラコード（Terraform）作成と Push

Cloud Shell 内蔵のテキストエディタ nano を使ってサンプルコードを作成します。

nano main.tf

以下のコードを貼り付け、Ctrl+O（保存）→ Enter → Ctrl+X（終了） で閉じます。
現状では Google Cloud Storage の Bucket が公開アクセス可能になっている点がポイントです。

# main.tf
resource "google_storage_bucket" "company_data" {
  name                     = "corp-critical-data-bucket"
  location                 = "asia-northeast1"
  public_access_prevention = "inherited" 
}

事前に作成しておいたご自身の空リポジトリへ Push します。

# 1. 秘密鍵（sa-key.json）と一時ファイル（current_policy.txt）をGit管理対象外にする
echo "sa-key.json" >> .gitignore
echo "current_policy.txt" >> .gitignore

# 2. Git初期化とコミット（main.tfと.gitignoreのみを対象とする）
git init
git add main.tf .gitignore
git commit -m "Initial commit: Add infrastructure code and .gitignore"
git branch -M main

# 3. ご自身の空リポジトリへ Push
# 【重要】YOUR_USER をご自身の GitHub ユーザー名に書き換えて実行してください
git remote add origin https://github.com/YOUR_USER/demo-doc-driven-policy-update.git
git push -u origin main
【コラム】運用Tips：PRの起票者を「AIエージェント（Bot）」にするには？

本ハンズオンでは手軽さを優先し、個人の GitHub アカウント（gh auth login）で認証を行いましたが、実際のエンタープライズ運用では個人の権限からは完全に切り離します。本番環境では、GitHub 上で専用の 「Machine User（Botアカウント）」 または 「GitHub Apps」 を作成し、そのトークンをシークレットマネージャー等に登録してパイプラインを回します。これにより、PRの起票者が policy-bot のようになり、「人間による意図的な変更」と「AIによる自律的な変更」の監査証跡を完全に分離・証明することが可能になります。
https://docs.github.com/en/authentication/connecting-to-github-with-ssh/managing-deploy-keys#machine-users
https://docs.github.com/en/apps/overview

Step 4: 【Cloud Shell】自律エージェントの実装（3つのスクリプト）

Cloud Shell に最新の Gemini SDK と API クライアントを追加インストールします。

pip3 install --user google-genai google-api-python-client

引き続き nano エディタを使い、エージェントの「目」「脳」「手足」となる3つのファイルを作成します。

① エージェントの「目」: fetch_docs_secure.py

(※ADC認証を利用し、環境変数にセットされたSAキーで制限付きDocsをセキュアに取得します)
https://cloud.google.com/docs/authentication/application-default-credentials

nano fetch_docs_secure.py

import sys
import google.auth
from googleapiclient.discovery import build

DOC_ID = sys.argv[1]

try:
    # ADC (Application Default Credentials) を使用して自動認証
    creds, _ = google.auth.default(scopes=['https://www.googleapis.com/auth/drive.readonly'])
    drive_service = build('drive', 'v3', credentials=creds)
    
    text_bytes = drive_service.files().export_media(
        fileId=DOC_ID, mimeType='text/plain').execute()
    print(text_bytes.decode('utf-8').strip())
except Exception as e:
    print(f"Error: {e}", file=sys.stderr)
    sys.exit(1)

② エージェントの「脳」: apply_policy.py 

nano apply_policy.py

import sys
import os
from google import genai

policy_file = sys.argv[1]
# Cloud Shellの環境変数からプロジェクトIDを自動取得
project_id = os.environ.get("GOOGLE_CLOUD_PROJECT")

with open(policy_file, "r") as f:
    policy_text = f.read()

with open("main.tf", "r") as f:
    current_code = f.read()

prompt = f"""
あなたは優秀なクラウドインフラエンジニアです。
以下の【最新セキュリティポリシー（全文）】を読み込み、現在のインフラ構成に影響・違反があるか確認してください。
修正が必要な場合は、【現在のTerraformコード】をポリシーに準拠するよう書き換えてください。
出力は修正後のTerraformコードのみとし、Markdownの装飾(```hcl など)は絶対に含めないでください。

【最新セキュリティポリシー（全文）】
{policy_text}

【現在のTerraformコード】
{current_code}
"""

# Vertex AI モードで初期化 (ADCによるIAM認証が自動適用されます)
client = genai.Client(vertexai=True, project=project_id, location='us-central1')
response = client.models.generate_content(
    model='gemini-2.5-flash',
    contents=prompt,
)

clean_code = response.text.strip().replace("```hcl", "").replace("```terraform", "").replace("```", "")
with open("main.tf", "w") as f:
    f.write(clean_code)

print("✅ Vertex AI: ポリシー全体の文脈を解釈し、Terraformコードの修正を完了しました。")

③ エージェントの「手足」: daemon.sh

(※10秒ごとの監視ループを回すスクリプトです)

nano daemon.sh

#!/bin/bash

# ==========================================
# 【重要】実行前に以下の変数を設定してください
# ==========================================
export DOC_ID="Step2でメモした_DOC_ID"
# ==========================================

export GOOGLE_CLOUD_PROJECT=$(gcloud config get-value project)
# 重要: Pythonスクリプトの認証をSAキー（Drive & Vertex AI 権限あり）に向ける
export GOOGLE_APPLICATION_CREDENTIALS="$(pwd)/sa-key.json"

PREV_HASH=""
POLICY_FILE="current_policy.txt"

echo "👀 [Agent] 制限付き Docs の裏側監視をスタートしました（10秒間隔）..."

while true; do
  # エラーを見逃さないようログファイルに逃がして取得
  python3 fetch_docs_secure.py "$DOC_ID" > "$POLICY_FILE" 2> fetch_error.log
  
  if [ ! -s "$POLICY_FILE" ]; then
      echo "⚠️ [警告] Docsの取得に失敗しました。詳細: $(head -n 1 fetch_error.log)"
      sleep 10
      continue
  fi

  # ファイルのハッシュ値を計算
  CURRENT_HASH=$(cksum "$POLICY_FILE" | awk '{print $1}') 

  if [ "$CURRENT_HASH" != "$PREV_HASH" ] && [ -n "$PREV_HASH" ]; then
    echo "🚨 [Agent] 機密Docsの更新を検知！自律修復プロセスを開始します..."
    echo "🤖 [Agent] Vertex AI にインフラコードの修正を依頼中..."
    
    python3 apply_policy.py "$POLICY_FILE"
    
    echo "📦 [Agent] GitHubへの Pull Request を起票中..."
    BRANCH="fix-policy-$(date +%s)"
    git checkout -b "$BRANCH" > /dev/null 2>&1
    git commit -am "🤖 [AI自動実行] セキュリティポリシー更新への追従" > /dev/null 2>&1
    git push -u origin "$BRANCH" > /dev/null 2>&1
    
    gh pr create \
      --title "🚨 【AI自動起票】セキュリティ基準改定に伴うインフラ設定の修正" \
      --body "Google Docsの更新を検知し、Vertex AI エージェントが自律的に起票しました。インフラ担当者は内容を確認の上 Approve をお願いします。" \
      > /dev/null 2>&1
    
    echo "✅ [Agent] GitHubにPRの起票が完了しました！監視に戻ります。"
    git checkout main > /dev/null 2>&1
  fi
  
  PREV_HASH=$CURRENT_HASH
  sleep 10
done

最後に、監視スクリプトに実行権限を付与します。

chmod +x daemon.sh
【コラム】実際の運用における「監視タイミング」のベストプラクティス

デモの都合上、今回は即時性を見せるために10秒ごとに高頻度で定期チェックしていますが、本番運用において常にAPIを叩き続けるのはコンピュート資源の無駄になります。実際には以下のような運用アーキテクチャを推奨します。

  • 定期バッチ ＋ 手動トリガー（推奨）: Cloud Scheduler を用いて「1日1回（深夜など）」に差分を監査・チェックする安定運用を基本とします。急ぎでインフラに反映させたい場合は、法務部門が承認を終えた後、Google Chat で /apply-policy などのコマンドを打つと Cloud Run（エージェント）が即時起動する、「人間がタイミングをコントロールできる」仕組みにします。
  • イベント駆動型: Docs の更新（バージョン保存）をトリガーとする Webhook を Eventarc で受け取り、無駄なくリアルタイムに処理を実行する構成も可能です（※執筆中の細かい保存アクションの度に起動しないよう、承認フローとの連携が必要です）。

https://cloud.google.com/scheduler/docs/overview
https://cloud.google.com/run/docs/overview/what-is-cloud-run
https://cloud.google.com/eventarc/docs/overview

【コラム】おかしなPRを防ぐ「ガードレール」の設置

AIエージェントが生成したコードが常に正しいとは限りません。PRを出す前に terraform validate を実行する処理をエージェントに組み込んだり、GitHub Actions で CI を設定したりすることで、構文エラーのある PR が本番環境へ混入するのを防ぎ、レビューの信頼性を高めることができます。
https://developer.hashicorp.com/terraform/cli/commands/validate
https://developer.hashicorp.com/terraform/tutorials/automation/github-actions

Step 5: 動作確認（ドキュメント更新による自律修正の体験）

すべての準備が整いました。「APIキーを一切使わない純粋な Google Cloud ネイティブ環境」で、システムが全体の文脈から自律的に判断して修正を行う体験を確認します。

  1. 監視デーモンの起動 Cloud Shell で ./daemon.sh を実行し、監視状態にしておきます。

  2. 画面の配置 ブラウザのウィンドウを2つ並べ、左側に Google Docs、右側にご自身の GitHub リポジトリ（Pull Requests のタブ）を開きます。

  3. ポリシーの変更（トリガーの発火） 左側の Docs の本文をスクロールし、【第5条（クラウドストレージの保護）】 の記述を見つけます。 末尾の 継承（inherited）のままでよい。 という部分を、手動で 有効（enforced）にしなければならない。 に書き換えます。

  4. 自律実行の観察 Cloud Shell のログに 🚨 [Agent] 機密Docsの更新を検知！ と表示され、裏側で Vertex AI と Git コマンドが自動実行されるのを確認します。 💡 ここがポイント： AIはドキュメント全体を読み込み、第3条（認証）や第4条（ネットワーク）といった無関係なルールに惑わされることなく、Terraform構成（GCS）に関係する第5条の変更だけを自ら判断・解釈しています。

  1. PRの自動起票 約10〜15秒後、右画面の GitHub をリロードしてください。「🚨【AI自動起票】セキュリティ基準改定に伴うインフラ設定の修正」という Pull Request が自律的に作成されています。

  1. PR の中身（Files changed）を確認すると、main.tf の inherited が正しく enforced に修正されていることがわかります。

🌐 まとめと本番環境への展開

このハンズオンを通じて、ユーザーは Google Workspace 上で doc を更新するだけで、AIエージェントがドキュメント全体の文脈から自律的にコードを修正し、最終的な承認のみを人間に委ねる、新しい Agentic CI/CD の一端を体験できました。

しかも今回は、APIキーの管理といったセキュリティリスクを抱えることなく、「Workspace の機密文書へのアクセス権」と「Vertex AI へのアクセス権」のすべてを、Google Cloud の IAM（サービスアカウント）で統合制御しています。

なお、実際のエンタープライズ環境では、このローカルの監視スクリプトを以下のように実装できます。

  • Google Workspace Events (Webhook) で Docs の更新をリアルタイム検知
  • Eventarc がイベントをセキュアにルーティング
  • サーバーレスの Cloud Run コンテナが起動し、サービスアカウント権限で Vertex AI をキックして GitHub へ PR を発行

「Workspace のユーザーID」と「Google Cloud のシステムID（IAM）」が根底で完全に統合されているからこそ、最高レベルのゼロトラスト・セキュリティと自律型運用（Agentic CI/CD）を両立させることが可能です。真のガバナンスを実現するための第一歩として、ぜひ自社環境での応用をご検討ください。
https://developers.google.com/workspace/events
https://cloud.google.com/iam/docs/overview

シーケンス図

参考までに、本ハンズオンで作成したエージェントの動作フローは以下のようになります。

Google Cloud Japan
Google Cloud Japan

Google Cloud Japan のエンジニアを中心に情報発信をしている Publication です。Google Cloud サービスの技術情報を中心に公開しています。各記事の内容は個人の意見であり、企業を代表するものではございません。

Discussion