Google Vertex AI Agent Builder完全ガイド2026｜エンタープライズAIエージェント

結論: Google Vertex AI Agent Builder は、GCP上で動くエンタープライズAIエージェント構築専用のフルマネージドPaaSです。Generative Playbooks・ADK（Agent Development Kit）・Reasoning Engine・DataStore Groundingを統合し、コードファーストでもローコードでも本番運用まで完結します。

この記事の要点:

• Agent Builder の5大コンポーネント（Agent Studio / ADK / Agent Engine / DataStore / A2A）と課金体系（Agent Engine: $0.0864/vCPU-hour、Memory Bank: $0.25/1,000 events）を数字ベースで解説
• Generative Playbooks の Goal＋Instruction 定義から OpenAPI Tools・DataStore Grounding 統合まで、実際に動くコードを10例掲載
• Microsoft Copilot Studio・Anthropic Agents SDK との3社比較で「GCP契約済み企業がAgent Builderを選ぶべき判断軸」を明確化

対象読者: GCP環境を持ちAIエージェント導入・評価を担当するITアーキテクト・CTOクラス・DX推進リーダー

読了後にできること: GCPプロジェクトでAgent BuilderのReasoning Engineに最初のエージェントをデプロイするコマンドを今日実行できる

「Vertex AI Agent Builder って、実際どこまで使えるの？」

企業向けAI研修で最近急増している質問です。Google Cloud Next 2026（2026年4月）でGoogleが「Vertex AI」を「Gemini Enterprise Agent Platform」へ改名・大幅拡張したことで、既存GCPユーザーの間で「今のVertex AI Agent Builderはどう変わったのか」という混乱が起きているんです。

先日、製造業クライアントのITアーキテクトの方から「Microsoft Copilot Studioと迷っているが、GCPが社内標準なのでVertex AIで行くべきかどうか判断できない」という相談を受けました。調べてみると、Agent Builder の仕様・課金・実装ノウハウが日本語でまとまった情報源がほぼないことに気づきました。

この記事では、Google公式ドキュメント・Cloud Next 2026セッション・ADK実装ガイドをベースに、Vertex AI Agent Builderの全体像を解説します。環境構築からGenerative Playbooks設計、Tools統合、Reasoning Engine + Python ADKデプロイまで、コードブロック10例付きで一気に解説します。

エンタープライズAIエージェントの全体像については、AIエージェント導入完全ガイドも合わせて参照してください。

Vertex AI Agent Builder とは — Vertex AI Agentsとの関係整理

まず用語整理から始めます。これが混乱の最大原因です。

命名の変遷と現在地

「Vertex AI Agent Builder」という機能名は2026年現在も Google Cloud コンソールで使われています。上位ブランドが「Gemini Enterprise Agent Platform」に変わっただけで、Agent Builder の実装APIは変わっていません。

5大コンポーネントの全体図

「Vertex AI Agents」と「Vertex AI Agent Builder」という表記が混在していますが、現在は Agent Builder が正式名称です。Vertex AI Agents は「Conversational Agents（Dialogflow CX）」の旧称として残っている場合があります。

課金体系 — Agent Engine / DataStore の実コスト

エンタープライズ採用の意思決定で「課金がわからない」は致命的です。公式情報をもとに整理します。

Agent Engine（Reasoning Engine）の課金

DataStore（Vertex AI Search）の課金

モデル課金（Gemini 2.5系）

月次コスト試算（エンタープライズ・本番環境）

注記: 上記コスト試算は2026年5月時点の公開価格をもとにした概算です。実際の課金は利用パターン・エディション・コミット割引によって大きく変動します。本番移行前に必ずGCP料金計算ツールで試算してください（参照日: 2026-05-06）。

環境構築 — GCPプロジェクト設定とVertex AI API有効化

前提条件

• GCPプロジェクトが作成済みであること
• 請求アカウントがプロジェクトにリンクされていること
• gcloud CLI がローカルにインストール済みであること

Step 1: 必要なAPIを有効化する

# Vertex AI Agent Builder に必要なAPIを一括有効化
gcloud services enable 
  aiplatform.googleapis.com 
  dialogflow.googleapis.com 
  discoveryengine.googleapis.com 
  --project=YOUR_PROJECT_ID

# 有効化確認
gcloud services list --enabled --project=YOUR_PROJECT_ID 
  | grep -E "aiplatform|dialogflow|discoveryengine"

Step 2: ADK（Agent Development Kit）のインストール

# Python仮想環境の作成（推奨）
python3 -m venv .venv && source .venv/bin/activate

# ADK + Vertex AI SDK のインストール
pip install google-adk google-cloud-aiplatform google-cloud-dialogflow-cx

# インストール確認
python3 -c "import google.adk; print(google.adk.__version__)"

Step 3: 認証情報の設定

# アプリケーションデフォルト認証 (ローカル開発用)
gcloud auth application-default login

# または Service Account キーファイルを使用する場合
export GOOGLE_APPLICATION_CREDENTIALS="/path/to/service-account-key.json"

# プロジェクトとリージョンを環境変数に設定
export GOOGLE_CLOUD_PROJECT="YOUR_PROJECT_ID"
export GOOGLE_CLOUD_LOCATION="us-central1"

基本エージェントの作成 — Conversational Agents コンソール

コンソールからの作成が最も手軽です。「5分で動くものを作る」を目標に進めます。

コンソールからの作成手順

1. Google Cloud Console → Vertex AI → Agent Builder を開く
2. 「Create Agent」→「Conversational agent」を選択
3. エージェント名・デフォルト言語（ja）・タイムゾーンを設定
4. 「Playbooks」タブを開き、最初のPlaybookを作成

Pythonコードからエージェントを作成する場合

from google.cloud.dialogflowcx_v3 import AgentsClient, Agent

def create_agent(project_id: str, location: str, display_name: str) -> Agent:
    """Conversational Agentをプログラムから作成する"""
    client = AgentsClient(client_options={"api_endpoint": f"{location}-dialogflow.googleapis.com"})

    agent = Agent(
        display_name=display_name,
        default_language_code="ja",
        time_zone="Asia/Tokyo",
        enable_stackdriver_logging=True,
        enable_spell_correction=False,
    )

    parent = f"projects/{project_id}/locations/{location}"
    created_agent = client.create_agent(parent=parent, agent=agent)
    print(f"Agent created: {created_agent.name}")
    return created_agent

# 使用例
agent = create_agent(
    project_id="your-project-id",
    location="global",
    display_name="CustomerSupportAgent"
)

Generative Playbooks 設計 — ゴールと指示の書き方

Generative Playbooks は、エージェントの「やること」を自然言語で定義する仕組みです。Dialogflow CX の従来型フロー設計とは根本的に異なります。

Playbook の基本構造

Playbookは3要素で構成されます：

• Goal（目標）: エージェントが達成すべきことを1〜2文で
• Instructions（手順）: ステップ形式で自然言語による制約・行動指針
• Referenced Tools: 呼び出し可能なツールのリスト

Playbook を Python で定義する

from google.cloud.dialogflowcx_v3 import PlaybooksClient, Playbook

def create_playbook(agent_name: str, tool_name: str) -> Playbook:
    """Generative Playbookを作成する"""
    client = PlaybooksClient()

    # 指示は自然言語のステップで記述
    instruction_steps = [
        "ユーザーに挨拶し、今日のお問い合わせ内容を確認する。",
        "注文番号を確認したら、${TOOL: order-status-api}を呼び出して注文状況を取得する。",
        "取得した情報をわかりやすく日本語で回答する。",
        "回答後、他にお手伝いできることがないか確認する。",
        "不足している情報があれば、最初に質問してから作業を開始する。",
    ]

    playbook = Playbook(
        display_name="OrderStatusPlaybook",
        goal="顧客の注文状況を確認し、わかりやすく回答する。",
        referenced_tools=[tool_name],
        instruction=Playbook.Instruction(
            steps=[{"text": step} for step in instruction_steps]
        )
    )

    created_playbook = client.create_playbook(parent=agent_name, playbook=playbook)
    print(f"Playbook created: {created_playbook.name}")
    return created_playbook

Playbook 設計の重要なポイント

LLMはOpenAPI 3.0スペックの description フィールドを読んでセマンティクスを理解します。 ツール定義の description が雑だとエージェントはいつ・どのパラメータでツールを呼ぶか判断できません。「ツールの説明こそが最も重要な設計要素」です。

Tools 統合 — OpenAPI / 関数呼び出し / DataStore

OpenAPI ツールの定義

openapi: "3.0.0"
info:
  title: "Order Status API"
  version: "1.0.0"
  description: "顧客の注文状況を照会するAPI。注文番号を渡すと現在のステータス・配送予定日・追跡番号を返す。"
paths:
  /orders/{order_id}:
    get:
      operationId: "getOrderStatus"
      summary: "注文状況を取得する"
      description: "指定した注文番号の現在の状況、配送追跡番号、配達予定日を返す。注文が見つからない場合は404を返す。"
      parameters:
        - name: order_id
          in: path
          required: true
          schema:
            type: string
          description: "照会する注文番号 (例: ORD-2026-12345)"
      responses:
        "200":
          description: "注文情報"
          content:
            application/json:
              schema:
                type: object
                properties:
                  status:
                    type: string
                    description: "注文ステータス (processing/shipped/delivered)"
                  tracking_number:
                    type: string
                    description: "配送追跡番号"
                  estimated_delivery:
                    type: string
                    description: "配達予定日 (YYYY-MM-DD形式)"

ツールを Playbook に登録する

from google.cloud.dialogflowcx_v3 import ToolsClient, Tool

def create_openapi_tool(agent_name: str, openapi_yaml: str) -> Tool:
    """OpenAPIスペックからToolを作成する"""
    client = ToolsClient()

    tool = Tool(
        display_name="order-status-api",
        description="顧客の注文状況を照会するAPI。注文番号から配送状況を取得する。",
        open_api_spec=Tool.OpenApiTool(
            text_schema=openapi_yaml
        )
    )

    created_tool = client.create_tool(parent=agent_name, tool=tool)
    print(f"Tool created: {created_tool.name}")
    return created_tool

DataStore — Vertex AI Search との連携

DataStore は社内ドキュメント・製品マニュアル・FAQ等の非構造化データをグラウンディングに使う仕組みです。「AIが嘘をつく（ハルシネーション）」問題への最も実践的な対策です。

DataStore の作成とドキュメントの取り込み

from google.cloud import discoveryengine_v1 as discoveryengine

def create_datastore_and_import(
    project_id: str,
    location: str,
    datastore_id: str,
    gcs_uri: str  # gs://your-bucket/documents/ のようなパス
) -> str:
    """DataStoreを作成してGCSからドキュメントをインポートする"""

    # DataStore クライアント
    client = discoveryengine.DataStoreServiceClient()
    parent = f"projects/{project_id}/locations/{location}/collections/default_collection"

    # DataStore 作成
    datastore = discoveryengine.DataStore(
        display_name="company-knowledge-base",
        industry_vertical=discoveryengine.IndustryVertical.GENERIC,
        content_config=discoveryengine.DataStore.ContentConfig.CONTENT_REQUIRED,
    )

    operation = client.create_data_store(parent=parent, data_store=datastore, data_store_id=datastore_id)
    result = operation.result(timeout=300)
    print(f"DataStore created: {result.name}")

    # ドキュメントのインポート (GCSから)
    doc_client = discoveryengine.DocumentServiceClient()
    doc_parent = f"{result.name}/branches/default_branch"

    import_operation = doc_client.import_documents(
        parent=doc_parent,
        gcs_source=discoveryengine.GcsSource(
            input_uris=[gcs_uri],
            data_schema="content",
        ),
        reconciliation_mode=discoveryengine.ImportDocumentsRequest.ReconciliationMode.INCREMENTAL,
    )

    import_result = import_operation.result(timeout=600)
    print(f"Documents imported: {import_result}")
    return result.name

Agent に DataStore を紐付ける

from google.cloud.dialogflowcx_v3 import Tool

def create_datastore_tool(agent_name: str, datastore_resource_name: str) -> Tool:
    """DataStoreをエージェントのToolとして登録する"""
    client = ToolsClient()

    tool = Tool(
        display_name="company-knowledge-base",
        description="社内ナレッジベース。製品マニュアル・FAQ・社内規定を参照する。ユーザーが社内情報を求めたら必ずこのツールを先に検索すること。",
        data_store_spec=Tool.DataStoreTool(
            data_store_links=[
                Tool.DataStoreTool.DataStoreLink(
                    data_store=datastore_resource_name,
                    documents=[],
                )
            ]
        )
    )

    return ToolsClient().create_tool(parent=agent_name, tool=tool)

Authentication — Service Account / Workload Identity

Service Account による認証（推奨）

# 1. Vertex AI Agent Builder 専用 Service Account の作成
gcloud iam service-accounts create agent-builder-sa 
  --display-name="Vertex AI Agent Builder Service Account" 
  --project=YOUR_PROJECT_ID

# 2. 必要な権限を付与
# Agent Engine の実行権限
gcloud projects add-iam-policy-binding YOUR_PROJECT_ID 
  --member="serviceAccount:agent-builder-sa@YOUR_PROJECT_ID.iam.gserviceaccount.com" 
  --role="roles/aiplatform.user"

# Vertex AI Search（DataStore）の読み取り権限
gcloud projects add-iam-policy-binding YOUR_PROJECT_ID 
  --member="serviceAccount:agent-builder-sa@YOUR_PROJECT_ID.iam.gserviceaccount.com" 
  --role="roles/discoveryengine.viewer"

# Dialogflow CX エージェント操作権限
gcloud projects add-iam-policy-binding YOUR_PROJECT_ID 
  --member="serviceAccount:agent-builder-sa@YOUR_PROJECT_ID.iam.gserviceaccount.com" 
  --role="roles/dialogflow.admin"

GKE 上での Workload Identity Federation（本番推奨）

# GKE クラスターで Workload Identity を有効化
gcloud container clusters update YOUR_CLUSTER 
  --workload-pool=YOUR_PROJECT_ID.svc.id.goog 
  --zone=us-central1-a

# Kubernetes Service Account と GCP Service Account のバインディング
gcloud iam service-accounts add-iam-policy-binding 
  agent-builder-sa@YOUR_PROJECT_ID.iam.gserviceaccount.com 
  --role=roles/iam.workloadIdentityUser 
  --member="serviceAccount:YOUR_PROJECT_ID.svc.id.goog[NAMESPACE/KSA_NAME]"

# KSA にアノテーションを付与
kubectl annotate serviceaccount KSA_NAME 
  iam.gke.io/gcp-service-account=agent-builder-sa@YOUR_PROJECT_ID.iam.gserviceaccount.com 
  --namespace=NAMESPACE

キーファイルを使わないWorkload Identityは、キーの漏洩リスクがなく、エンタープライズセキュリティ要件を満たすための標準的なアプローチです。本番環境では必ずこの方式を採用してください。

チャネル展開 — Dialogflow CX / Web / API

展開チャネルの比較

REST API での会話セッション

import uuid
import requests

def send_message_to_agent(
    project_id: str,
    location: str,
    agent_id: str,
    text: str,
    session_id: str = None
) -> dict:
    """Dialogflow CX REST APIでエージェントにメッセージを送信する"""

    if session_id is None:
        session_id = str(uuid.uuid4())

    # エンドポイント
    endpoint = f"https://{location}-dialogflow.googleapis.com"
    session_path = f"{endpoint}/v3/projects/{project_id}/locations/{location}/agents/{agent_id}/sessions/{session_id}:detectIntent"

    # 認証トークン取得
    import subprocess
    token = subprocess.check_output(
        ["gcloud", "auth", "print-access-token"], text=True
    ).strip()

    headers = {
        "Authorization": f"Bearer {token}",
        "Content-Type": "application/json",
    }

    payload = {
        "queryInput": {
            "text": {"text": text},
            "languageCode": "ja"
        }
    }

    response = requests.post(session_path, json=payload, headers=headers)
    response.raise_for_status()
    return response.json()

# 使用例
result = send_message_to_agent(
    project_id="your-project-id",
    location="global",
    agent_id="your-agent-id",
    text="注文番号 ORD-2026-12345 の配送状況を教えてください"
)
print(result["queryResult"]["responseMessages"][0]["text"]["text"][0])

Reasoning Engine — Python ADK との連携

Reasoning Engine（Agent Engine）は、ADKで構築したエージェントをフルマネージドでホスティングするサービスです。インフラ管理なし・オートスケーリングで本番エージェントを動かせます。

ADK エージェントの定義

from google.adk.agents import LlmAgent
from google.adk.tools import FunctionTool

# ツール関数の定義
def get_order_status(order_id: str) -> dict:
    """注文番号から配送ステータスを取得する。

    Args:
        order_id: 照会する注文番号 (例: ORD-2026-12345)

    Returns:
        status: 注文ステータス
        tracking_number: 配送追跡番号
        estimated_delivery: 配達予定日
    """
    # 実際の実装では外部APIを呼び出す
    return {
        "status": "shipped",
        "tracking_number": "TRK-987654321",
        "estimated_delivery": "2026-05-10",
    }

# ADK エージェントの定義
order_support_agent = LlmAgent(
    model="gemini-2.0-flash",
    name="order_support_agent",
    description="顧客の注文・配送に関する問い合わせを処理するエージェント",
    instruction="""あなたは丁寧な注文サポートエージェントです。

    - 注文番号を確認したら必ず get_order_status ツールを呼び出してください
    - 取得した情報は日本語でわかりやすく説明してください
    - 不足している情報があれば、最初に質問してから作業を開始してください
    - 数字と固有名詞は、根拠（ツール取得データ）を添えてください
    """,
    tools=[FunctionTool(func=get_order_status)],
)

Agent Engine へのデプロイ

import vertexai
from vertexai.preview import reasoning_engines

# Vertex AI の初期化
vertexai.init(
    project="your-project-id",
    location="us-central1",
    staging_bucket="gs://your-staging-bucket",
)

# ADK エージェントを Agent Engine にデプロイ
# AdkApp でラップすることで Agent Engine に対応させる
from google.adk.runtime.vertexai import AdkApp

app = AdkApp(agent=order_support_agent)

remote_app = reasoning_engines.ReasoningEngine.create(
    app,
    requirements=[
        "google-adk>=1.0.0",
        "google-cloud-aiplatform>=1.70.0",
        "requests>=2.31.0",
    ],
    display_name="OrderSupportAgent",
    description="注文サポートエージェント（ADK + Gemini 2.0 Flash）",
)

print(f"Deployed: {remote_app.resource_name}")

# デプロイ後のテスト
session = remote_app.create_session(user_id="test_user")
for chunk in remote_app.stream_query(
    user_id="test_user",
    session_id=session["id"],
    message="注文番号 ORD-2026-12345 の状況を教えてください"
):
    print(chunk, end="", flush=True)

この一連のコードが動けば、フルマネージドの Agent Engine 上でオートスケールするエージェントが完成します。Cloud Run のような個別インフラ管理は不要です。

Anthropic Agents SDK / Microsoft Copilot Studio との比較

「3社のどれを選ぶか」はエンタープライズでの最大の判断ポイントです。バランスの取れた比較を示します。

判断軸のまとめ

• GCP契約済み + BigQuery / Google Workspace 活用中: Vertex AI Agent Builder 一択。既存インフラへのシームレスな統合が最大の強み
• Microsoft 365がコアインフラ: Microsoft Copilot Studio を選ぶほうが運用コストが低い
• モデルにこだわりがあり、コードで完全制御したい: Anthropic Agents SDK が最も自由度が高い
• マルチクラウドでモデル選択肢を最大化したい: Agent Builder は Gemini・Claude・Llama を同一プラットフォームで使える（Cloud Next 2026時点で Claude は first-class citizen として統合）

AI導入戦略の全体設計については、AI導入戦略ガイドを参照してください。

失敗パターン4選 — エンタープライズ導入でよくある落とし穴

100社以上のAI研修・導入支援経験から、Vertex AI Agent Builderの導入で繰り返される失敗パターンを4つ厳選しました。

失敗1: OpenAPI ToolのDescriptionを手抜きする

❌ NG例: OpenAPI spec の description を「注文API」「データ取得」と雑に書く

⭕ 正しいアプローチ: 「いつ呼ぶか」「何を渡すか」「何が返るか」を description に詳細記述する

なぜ重要か: Playbook の LLM は description を読んでセマンティクスを判断します。description が雑だとエージェントは「このツールを呼ぶべきか」を判断できず、不要な呼び出しや呼び出し漏れが発生します。私が支援した製造業クライアントでは、description を具体化しただけでツール呼び出しの精度が目に見えて改善しました。

失敗2: Playbook Instruction をフロー図の代替として書く

❌ NG例: 「①まずAを確認し、②Bの場合はXを実行し、③Cの場合はYを実行し……」と細かく分岐を書く

⭕ 正しいアプローチ: 目標と制約条件を自然言語で書き、細かい分岐判断はLLMに委ねる

なぜ重要か: Playbook は LLM が推論するものです。Dialogflow CX の従来型フロー設計の発想をそのまま持ち込むと、過度に細かいステップ指定でかえって応答品質が下がります。

失敗3: 本番前にAgent Engineのコールドスタートを測定しない

❌ NG例: 開発環境のレイテンシで「問題ない」と判断し本番リリース

⭕ 正しいアプローチ: 本番と同等のトラフィックパターンで事前負荷試験を実施し、コールドスタートのレイテンシを計測する

なぜ重要か: Agent Engine は「サブ秒のコールドスタート」を謳っていますが、実際のレイテンシはモデルサイズ・ツール数・DataStore クエリ数で変動します。SLA要件がある場合は必ず事前測定が必要です。

失敗4: DataStoreのドキュメント更新頻度を設計しない

❌ NG例: 一度 DataStore にドキュメントをインポートして終わり。製品マニュアルが更新されても DataStore は古いまま

⭕ 正しいアプローチ: GCS + Cloud Functions / Cloud Scheduler で自動更新パイプラインを構築する。インポートは INCREMENTAL モードを使い差分更新にする

なぜ重要か: DataStore が古くなるとエージェントの回答精度が低下し、ユーザー信頼を失います。「ナレッジベースの鮮度管理」は運用設計の必須要素です。

まとめ：今日から始める3つのアクション

1. 今日やること: GCPコンソールで Agent Builder を開き、Playbook を1つ作成してSimulatorで動作確認する（アカウントがあれば30分で完了）
2. 今週中: 社内の「繰り返し発生する問い合わせ業務」を1つ特定し、そのワークフローをPlaybook Instruction として書き出す。API化が難しい場合はDataStore Grounding から始める
3. 今月中: ADK + Reasoning Engine でプロトタイプをデプロイし、Agent Engine のコスト（無料枠内で収まるか）を実測する

Vertex AI Agent Builder は「GCPエコシステムに乗ったまま、エンタープライズ品質のAIエージェントを最短で作る」という用途に最も適したプラットフォームです。BigQuery・Google Workspace・Cloud Runとの統合親和性は他の追随を許さず、モデル選択肢もGemini・Claude・LlamaとGCP上で選べるようになっています。

一方でOpenAPI Toolの description 設計とDataStoreの運用管理は手を抜くと即座に品質劣化につながります。「最初にきちんと設計する」姿勢が長期的な成功につながります。

参考・出典

• Gemini Enterprise Agent Platform | Google Cloud — Google Cloud公式（参照日: 2026-05-06）
• Agent Platform Pricing | Google Cloud — Google Cloud公式料金ページ（参照日: 2026-05-06）
• Vertex AI Agent Builder: 2026 guide | UI Bakery Blog — UI Bakery（参照日: 2026-05-06）
• Generative Agent Anatomy: Building with Vertex AI Playbooks | Google Developer Forums — Google Developer Forums（参照日: 2026-05-06）
• More ways to build and scale AI agents with Vertex AI Agent Builder | Google Cloud Blog — Google Cloud Blog（参照日: 2026-05-06）
• Vertex AI Agent Engine overview | Google Cloud Documentation — Google Cloud公式ドキュメント（参照日: 2026-05-06）

著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。早稲田大学法学部在学中に生成AIの可能性に魅了され、X（@SuguruKun_ai）でAI活用法を発信（フォロワー約10万人）。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』（SBクリエイティブ）。

ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。