デベロッパー

Google ADK、MCP、Cloud Run を使用して専門家向けコンテンツ用のマルチエージェントシステムを構築する - パート 1

Thu, 09 Apr 2026 01:00:00 +0000

※この投稿は米国時間 2026 年 3 月 19 日に、Google Cloud blog に投稿されたものの抄訳です。

私のチームのミッションは、コードの作成から Google Cloud で安全な AI ワークロードを実行するまで、デベロッパーの取り組みを加速させることです。デベロッパーの成功を支援するため、Google はデベロッパーが最も切実に求めている質問を特定し、簡単に実装できるわかりやすいソリューションを提供するデモを構築することに重点を置いています。

最近、新しい Developer Knowledge MCP サーバーがリリースされたとき、私にはひらめきが湧きました。そこで、Google Agent Development Kit（ADK）を使用して設計されたマルチエージェントシステムである Dev Signal を構築し、Reddit から技術的な質問を特定し、公式ドキュメントを使用して調査し、詳細な技術ブログ記事の下書きを作成しました。Dev Signal には、Nano Banana Pro を使用したカスタムビジュアルも備わっています。エージェントが私の好みのスタイルやブログ記事の書き方を記憶できるように、長期記憶レイヤも統合しました。

コーディングアシスタントである Gemini CLI をデベロッパーナレッジ MCP サーバーに接続することで、このシステム全体をわずか 2 日で構築して Google Cloud Run にデプロイしました。

ここでは、長期記憶を備えた複雑なマルチエージェントシステムを設計する方法、ローカルおよびリモートの MCP サーバーを利用してツールを標準化する方法、安全な Cloud Run デプロイのための詳細な Terraform スクリプトを作成する方法など、さまざまな方法をご紹介します。

今すぐコードを見てご自分のペースで調べる場合は、こちらからリポジトリをクローニングできます。

学習内容

4 回に分けてお届けするこのブログシリーズでは、このプロジェクトをどのように実現したのか、その手順を段階的にご紹介します。各ブログ投稿では、Dev Signal の構築とデプロイの過程を説明します。

パート 1: エージェント機能を構築するためのツール – まず、プロジェクト環境をセットアップし、Model Context Protocol（MCP）を使用してエージェントにツールを装備します。トレンドの発見に Reddit を、技術的なグラウンディングに Google Cloud ドキュメントを、画像生成にカスタム Nano Banana Pro ツールを使用する方法を学びます。
パート 2: 長期記憶を備えたマルチエージェントアーキテクチャ – ルートオーケストレーターと専門エージェントチームを実装して、システムの「頭脳」を構築します。また、Vertex AI Memory Bank を統合することで、エージェントがセッション全体でユーザーの好みを学習して保持できるようになります。
パート 3: エージェントをローカルでテストする – クラウドに移行する前に、エージェントのコンポーネントを同期し、ワークステーションでエージェントのパフォーマンスを検証します。専用のテストランナーを使用して、検出、調査、マルチモーダル作成のライフサイクル全体をシミュレートします。特に、ローカルエージェントをクラウドベースの Vertex AI Memory Bank に直接接続して、長期記憶の永続性を検証することに重点を置きます。
パート 4: Cloud Run へのデプロイと本番環境への移行 – 最後に、再現可能なインフラストラクチャを実現するため、Terraform を使用して Google Cloud Run にサービスをデプロイします。また、高品質で安全な本番環境システムに必要な次のステップについても説明します。

Dev Signal の概要

Dev Signal は、ノイズをフィルタして価値を生み出すように設計されたインテリジェントなモニタリングエージェントです。Dev Signal は次のように動作します。

発見: Reddit を調査して、エンゲージメントの高い技術的な質問を見つけます。
グラウンディング: 正確性を確保するために、Google Cloud の公式ドキュメントを使用して回答を調査します。
作成: 調査結果に基づいて、プロフェッショナルな技術ブログ投稿の下書きを作成します。
マルチモーダル生成: これらの投稿のカスタムインフォグラフィックヘッダーを生成します。
長期記憶: Vertex AI Memory Bank を使用して、さまざまなセッションにわたってフィードバックを記憶します。

前提条件

始める前に、以下がインストールされていることを確認してください。

Python 3.12 以降

uv（Python パッケージ管理システム）: curl -LsSf https://astral.sh/uv/install.sh | sh
Google Cloud SDK（gcloud CLI）（インストールおよび認証済み）
Terraform（Iinfrastructure as Code 用）
Node.js と npm（Reddit MCP ツールに必要）

次も必要です。

課金を有効にした Google Cloud プロジェクト。
有効な API: Vertex AI、Cloud Run、Secret Manager、Artifact Registry。
Reddit API 認証情報（クライアント ID、シークレット）- Reddit デベロッパーポータルから入手できます。
Developer Knowledge API Key（Google Cloud ドキュメント検索用）- 入手方法については、こちらをご覧ください。

プロジェクトのセットアップ

Dev Signal システムは、Remigiusz Samborski 氏と Vlad Kolesnikov 氏による Agent Factory のエピソードで説明されている自動化されたアーキテクトワークフローに従って、まず Agent Starter Pack を実行して構築されました。この基盤により、エージェントロジック、サーバーコード、ユーティリティ、ツール間の関心を分離するために使用される、プロジェクトのモジュール式ディレクトリ構造が用意されました。

Starter Pack は、プロフェッショナルなインフラストラクチャ、CI / CD パイプライン、オブザーバビリティツールの作成を数秒で自動化するため、強力な出発点となります。これにより、基盤となるプラットフォームのセキュリティとスケーラビリティを確保しながら、エージェント独自のインテリジェンスに十分集中できるようになります。Gemini CLI と Antigravity の AI アシスタンスを使用して、生成されたボイラープレートを基に構築することで、開発プロセスが大幅に加速されます。

Agent Starter Pack のアーキテクチャの概要:

1. プロジェクトを初期化する

プロジェクト用の新しいディレクトリを作成し、初期化します。ここでは、非常に高速な Python パッケージ管理システムである uv を使用します。

code_block: <ListValue: [StructValue([('code', 'uv init dev-signal'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48583b4a00>)])]>

2. フォルダ構造

このプロジェクトは次の構造に従います。これらのファイルにデータを段階的に入力していきます。

code_block: <ListValue: [StructValue([('code', 'dev-signal/\r\n├── dev_signal_agent/\r\n│ ├── __init__.py\r\n│ ├── agent.py # Agent logic & orchestration\r\n│ ├── fast_api_app.py # Application server & memory connection\r\n│ ├── app_utils/ # Env Config\r\n│ │ └── env.py\r\n│ └── tools/ # External capabilities\r\n│ ├── __init__.py\r\n│ ├── mcp_config.py # Tool configuration (Reddit, Docs)\r\n│ └── nano_banana_mcp/# Custom local image generation tool\r\n│ ├── __init__.py\r\n│ ├── main.py\r\n│ ├── nano_banana_pro.py\r\n│ ├── media_models.py\r\n│ ├── storage_utils.py\r\n│ └── requirements.txt\r\n├── deployment/\r\n│ └── terraform/ # Infrastructure as Code\r\n├── .env # Local secrets (API keys)\r\n├── Makefile # Shortcuts for building/deploying\r\n├── Dockerfile # Container definition\r\n└── pyproject.toml # Dependencies'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48583b4df0>)])]>

3. 依存関係を定義する

必要な依存関係を使用して pyproject.toml を更新します。エージェントフレームワークには google-adk を、モデルのインタラクションには google-genai を使用します。

code_block: <ListValue: [StructValue([('code', '[project]\r\nname = "dev-signal"\r\nversion = "0.1.0"\r\ndescription = "A multi-agent system for monitoring and content creation."\r\nreadme = "README.md"\r\nrequires-python = ">=3.12, <3.14"\r\ndependencies = [\r\n "google-adk>=0.1.0",\r\n \xa0"google-genai>=1.0.0",\r\n "mcp>=1.0.0",\r\n \xa0"python-dotenv>=1.0.0",\r\n "fastapi>=0.110.0",\r\n "uvicorn>=0.29.0",\r\n "google-cloud-logging>=3.0.0",\r\n "google-cloud-aiplatform>=1.38.0",\r\n \xa0"fastmcp>=2.13.0",\r\n "google-cloud-storage>=3.6.0",\r\n "google-auth>=2.0.0",\r\n "google-cloud-secret-manager>=2.26.0",\r\n]'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48583b4430>)])]>

uv sync を実行してすべてインストールします。

エージェントコード用の新しいディレクトリを作成します。

code_block: <ListValue: [StructValue([('code', 'mkdir dev_signal_agent\r\ncd dev_signal_agent'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48583b40d0>)])]>

エージェント機能の構築: MCP ツール

エージェントは外部とやり取りする必要があります。これを標準化するために、Model Context Protocol（MCP）を使用します。Model Context Protocol（MCP）は、AI エージェントを外部のデータやツールに接続するための普遍的な基準です。カスタム API ラッパーを記述する代わりに、標準の MCP サーバーを使用します。これにより、共通のインターフェースを使用して、API（Reddit）、ナレッジベース（Google Cloud ドキュメント）、さらにはローカルスクリプト（Nano Banana Pro を使用した画像生成）にも接続できます。エージェントツール用の新しいディレクトリを作成します。

code_block: <ListValue: [StructValue([('code', 'mkdir tools\r\ncd tools'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48583b42e0>)])]>

ツールの構成

ツールセットは dev_signal_agent/tools/mcp_config.py で定義します。

このファイルでは、3 つの主要なツールの接続パラメータを定義します。

Reddit: ローカル stdio サブプロセス経由で接続されます。
デベロッパーナレッジ: リモート HTTP エンドポイント経由で接続されます。
Nano Banana: ローカル stdio サブプロセス（Google のカスタム Python スクリプト）経由で接続されます。

Reddit 検索（発見ツール）

Reddit MCP サーバーは Reddit API へのブリッジとして機能し、複雑な API ラッパーを記述しなくても、トレンドとなっている投稿をエージェントが発見してエンゲージメントを分析できるようにします。移植性を確保するために、コードでは「検索またはフェッチ」戦略が使用されています。まずローカルインストールをチェックし、見つからない場合は npx を使用してサーバーをオンデマンドでダウンロードして実行します。

ネットワーク接続の代わりに、エージェントはサーバーをローカルサブプロセスとして起動し、標準入出力（stdio）を介して通信します。Google ADK 内の McpToolset クラスは、これらの接続を標準化する普遍的なラッパーとして機能し、エージェントが共通のインターフェースを使用して、コミュニティリソースからカスタムスクリプト（Nano Banana 画像生成ツールなど）まで、さまざまなツールとやり取りできるようにします。環境変数を介して API 認証情報を安全に渡すことで、システムはこれらの「プラグアンドプレイ」モジュールが AI と外部プラットフォーム間のシームレスなブリッジとして機能することを保証します。

次のコードを dev_signal_agent/tools/mcp_config.py に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'import os\r\nimport shutil\r\nfrom mcp import StdioServerParameters\r\nfrom google.adk.tools import McpToolset\r\nfrom google.adk.tools.mcp_tool import StreamableHTTPConnectionParams, StdioConnectionParams\r\n\r\ndef get_reddit_mcp_toolset(client_id: str = "", client_secret: str = "", user_agent: str = ""):\r\n """\r\n Connects to the Reddit MCP server.\r\n This server runs as a local subprocess (stdio) and proxies requests to the Reddit API.\r\n """\r\n # Check if \'reddit-mcp\' is installed globally, otherwise use npx to run it\r\n cmd = "reddit-mcp" if shutil.which("reddit-mcp") else "npx"\r\n args = [] if shutil.which("reddit-mcp") else ["-y", "--quiet", "reddit-mcp"]\r\n \r\n # Inject secrets into the environment of the subprocess only\r\n env = {\r\n **os.environ, \r\n "DOTENV_CONFIG_SILENT": "true", \r\n "LANG": "en_US.UTF-8"\r\n }\r\n\r\n if client_id: env["REDDIT_CLIENT_ID"] = client_id\r\n if client_secret: env["REDDIT_CLIENT_SECRET"] = client_secret\r\n if user_agent: env["REDDIT_USER_AGENT"] = user_agent\r\n\r\n return McpToolset(\r\n connection_params=StdioConnectionParams(\r\n server_params=StdioServerParameters(\r\n command=cmd, \r\n args=args, \r\n env=env # Pass injected secrets directly to the subprocess\r\n ),\r\n timeout=120.0\r\n )\r\n )'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f48583b4b80>)])]>

Google Cloud ドキュメント（ナレッジツール）

Developer Knowledge MCP サーバーは、エージェントが Google Cloud の公式ドキュメントのコーパス全体を検索できるようにすることで、エージェントのグラウンディングを提供します。これは、ローカルの Reddit サーバーとは異なり、Google がホストするマネージドサービスであり、インターネット経由でリモートエンドポイントとしてアクセスされます。セマンティッククエリ用の google_developer_documentation_search や、完全なマークダウンコンテンツを取得するための google_developer_documentation_fetch などの特殊なツールが公開されており、エージェントが技術的な主張を行うたびに、最新の確かな事実によって裏付けられるようになっています。

注: Gemini CLI や Antigravity などのコーディングアシスタントツールをデベロッパーナレッジ MCP サーバーに接続して、最新の便利な Google Cloud ドキュメントをアシスタントに提供することもできます。このブログ記事を書くときも使っています。

接続するために、エージェントは McpToolset クラスと StreamableHTTPConnectionParams を使用し、ローカルプロセスを起動する代わりにウェブ URL を指定します。リクエストヘッダーで渡される DK_API_KEY（API キーを作成）を使用して安全に認証し、エージェントが単一の標準化されたインターフェースを通じて、公式ドキュメント、コミュニティの感情、より広範なウェブコンテキスト全体で「包括的な調査スイープ」を実行できるようにします。

次のコードを dev_signal_agent/tools/mcp_config.py に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'def get_dk_mcp_toolset(api_key: str = ""):\r\n """\r\n Connects to Developer Knowledge (Google Cloud Docs).\r\n This is a remote MCP server accessed via HTTP.\r\n """\r\n headers = {}\r\n if api_key:\r\n headers["X-Goog-Api-Key"] = api_key\r\n else:\r\n # Fallback to os.environ for local testing if not passed via API\r\n headers["X-Goog-Api-Key"] = os.getenv("DK_API_KEY", "")\r\n\r\n return McpToolset(\r\n connection_params=StreamableHTTPConnectionParams(\r\n url="https://developerknowledge.googleapis.com/mcp",\r\n headers=headers\r\n )\r\n )'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f48583b4a60>)])]>

画像生成ツール（Nano Banana MCP）

Reddit とドキュメントには外部 MCP サーバーを使用しましたが、特定の Python ロジックをラップする独自のカスタム MCP サーバーを構築することもできます。この例では、Gemini 3 Pro Image（Nano Banana Pro とも呼ばれます）を搭載した画像生成ツールを作成します。これは、任意の Python 関数を、任意のエージェントが理解できるツールに標準化できることを示しています。

画像生成の仕組み:

FastMCP: fastmcp ライブラリを使用してサーバーの作成を大幅に簡素化し、数行のコードで Python 関数をツールとして登録できるようにします。
Gemini のインテグレーション: サーバーは Google GenAI SDK を使用して gemini-3-pro-image-preview モデルを呼び出し、エージェントの説明的なプロンプトを未加工の画像バイトに変換します。
GCS へのアップロードとホスティング: エージェントインターフェースでは通常、画像を表示するために URL が必要となるため、サーバーは生成されたバイトを Google Cloud Storage（GCS）に自動的にアップロードし、公開リンクを返します。

このローカルツールを接続するには、StdioConnectionParams を使用します。これは、サーバーが標準入出力を介して通信するローカルサブプロセスとして実行されるためです。この転送方法は、サーバーのエントリポイントで定義する transport="stdio" 構成に直接一致し、カスタムのローカルスクリプトのシームレスな接続を保証します。

次のコードは、dev_signal_agent/tools/mcp_config.py で MCP 接続を定義します。uv run を使用して、すべての依存関係が正しくインストールされている、隔離された環境でサーバーが起動するようにします。

次のコードを dev_signal_agent/tools/mcp_config.py に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'def get_nano_banana_mcp_toolset():\r\n """\r\n Connects to our local \'Nano Banana\' image generator.\r\n This demonstrates how to wrap a local Python script as an MCP tool.\r\n """\r\n path = os.path.join("dev_signal_agent", "tools", "nano_banana_mcp", "main.py")\r\n bucket = os.getenv("AI_ASSETS_BUCKET") \r\n return McpToolset(\r\n connection_params=StdioConnectionParams(\r\n server_params=StdioServerParameters(\r\n command="uv", \r\n args=["run", path], \r\n env={**os.environ, "AI_ASSETS_BUCKET": bucket}\r\n ),\r\n timeout=600.0 # Image generation can take time\r\n )\r\n )'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f48429921c0>)])]>

Nano Banana Pro サーバーロジックの実装

次に、このサーバーの実際のロジックを実装します。この実装は、Remigiusz Samborski 氏による Agent Factory デモのコードに基づいています。Remi の元のコードには、MCP サーバーを Cloud Run にデプロイする手順が記載されていますが、ここでは開発とテストを迅速に行うために、ローカルサブプロセスとして実行します。

まず、新しいサーバー用のディレクトリを作成します。

code_block: <ListValue: [StructValue([('code', 'mkdir -p dev_signal_agent/tools/nano_banana_mcp\r\ncd dev_signal_agent/tools/nano_banana_mcp'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48429928e0>)])]>

サーバーエントリポイント（`main.py`）

このファイルは、MCP サーバーを初期化して起動する「頭脳」として機能します。

FastMCP の初期化: FastMCP ライブラリを使用して、「MediaGenerators」という名前のサーバーを作成し、generate_image 関数をツールとして登録します。
安全なロギング: _initialize_console_logging 関数が重要な役割を果たします。この関数はすべてのログを sys.stderr に強制的に出力します。これは、MCP の「stdio」転送がエージェントとツールの間の通信に sys.stdout を使用するためです。stdout に送信される標準ログは、そのプロトコルを破損させます。
実行: mcp.run(transport="stdio") 行は、サーバーをローカルサブプロセスとして起動し、標準入力経由でエージェントからのリクエストをリッスンできるようにします。

次のコードを dev_signal_agent/tools/nano_banana_mcp/main.py に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'import logging\r\nimport os\r\nimport sys\r\nfrom fastmcp import FastMCP\r\nfrom dotenv import load_dotenv\r\nfrom nano_banana_pro import generate_image\r\n\r\ndef _initialize_console_logging(min_level: int = logging.INFO):\r\n # Ensure logs go to STDERR so they don\'t break the MCP stdio protocol\r\n handler = logging.StreamHandler(sys.stderr)\r\n logging.basicConfig(level=min_level, handlers=[handler], force=True)\r\n\r\ntools = [generate_image]\r\nmcp = FastMCP(name="MediaGenerators", tools=tools)\r\n\r\nif __name__ == "__main__":\r\n load_dotenv()\r\n _initialize_console_logging()\r\n mcp.run(transport="stdio")'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f4842992250>)])]>

生成ロジック（`nano_banana_pro.py）`

ここでは、Gemini を使用して実際に画像が生成されます。

GenAI クライアント: Google の生成モデルとやり取りするために、genai.Client() を初期化します。
モデルの選択: 具体的には gemini-3-pro-image-preview モデルを対象とします。response_modalities を「IMAGE」に設定して、テキストだけでなくピクセルも必要であることをモデルに伝えます。
堅牢性: コードには、一時的な生成エラーを処理するための MAX_RETRIES ループ（5 に設定）が含まれており、エージェントが有効な画像を複数回取得できるようにしています。
バイト処理: モデルが画像を生成すると、未加工のインラインデータとして届きます。これらのバイトを抽出し、ヘルパーを呼び出してクラウドに移動します。
URI 変換: 最後に、内部の gs:// パスを、ブラウザからアクセス可能な https:// URL に置き換え、ユーザーが実際に画像を見られるようにします。

次のコードを dev_signal_agent/tools/nano_banana_mcp/nano_banana_pro.py に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'import logging\r\nfrom typing import Literal, Optional\r\nfrom google import genai\r\nfrom google.genai import types\r\nfrom media_models import MediaAsset\r\nfrom storage_utils import upload_data_to_gcs\r\n\r\nAUTHORIZED_URI = "https://storage.mtls.cloud.google.com/"\r\nMAX_RETRIES = 5\r\n\r\nasync def generate_image(\r\n prompt: str,\r\n aspect_ratio: Literal["16:9", "9:16"] = "16:9",\r\n) -> MediaAsset:\r\n """Generates an image using Gemini 3 Image model."""\r\n genai_client = genai.Client()\r\n content = types.Content(parts=[types.Part.from_text(text=prompt)], role="user")\r\n \r\n logging.info(f"Starting image generation for prompt: {prompt[:50]}...")\r\n asset = MediaAsset(uri="")\r\n \r\n for _ in range(MAX_RETRIES):\r\n response = genai_client.models.generate_content(\r\n model="gemini-3-pro-image-preview",\r\n contents=[content],\r\n config=types.GenerateContentConfig(\r\n response_modalities=["IMAGE"],\r\n image_config=types.ImageConfig(aspect_ratio=aspect_ratio)\r\n )\r\n )\r\n if response and response.parts:\r\n for part in response.parts:\r\n if part.inline_data and part.inline_data.data:\r\n # Upload the raw bytes to GCS\r\n gcs_uri = await upload_data_to_gcs(\r\n "mcp-tools",\r\n part.inline_data.data,\r\n part.inline_data.mime_type\r\n )\r\n asset = MediaAsset(uri=gcs_uri)\r\n break\r\n if asset.uri: break\r\n\r\n if not asset.uri:\r\n asset.error = "No image was generated."\r\n else:\r\n # Convert gs:// URI to an HTTP accessible URL if needed\r\n asset.uri = asset.uri.replace(\'gs://\', AUTHORIZED_URI)\r\n logging.info(f"Image URL: {asset.uri}")\r\n \r\n return asset'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f4842992610>)])]>

GCS アップロードヘルパー（`storage_utils.py）`

エージェントは画像を表示するためにリンクを必要とするため、このユーティリティは Google Cloud Storage（GCS）でホスティングを処理します。

バケットの動的な選択: 環境変数でバケット名を探し、AI_ASSETS_BUCKET から LOGS_BUCKET_NAME にフォールバックして、データの保存場所が常に確保されるようにします。
一意のファイル名: 未加工の画像データの MD5 ハッシュを使用して、一意のファイル名を作成します。これにより、ファイル名の競合を防ぐことができ、同じ画像の重複アップロードを回避する簡単な方法として機能します。
クラウドアップロード: blob.upload_from_string メソッドは、未加工の画像バイトを GCS バケットに直接 push します。

次のコードを dev_signal_agent/tools/nano_banana_mcp/storage_utils.py に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'import hashlib\r\nimport mimetypes\r\nimport os\r\nfrom google.cloud.storage import Client, Blob\r\nfrom dotenv import load_dotenv\r\n\r\nload_dotenv()\r\nstorage_client = Client()\r\nai_bucket_name = os.environ.get("AI_ASSETS_BUCKET") or os.environ.get("LOGS_BUCKET_NAME")\r\nai_bucket = storage_client.bucket(ai_bucket_name)\r\n\r\nasync def upload_data_to_gcs(agent_id: str, data: bytes, mime_type: str) -> str:\r\n file_name = hashlib.md5(data).hexdigest()\r\n ext = mimetypes.guess_extension(mime_type) or ""\r\n blob_name = f"assets/{agent_id}/{file_name}{ext}"\r\n blob = Blob(bucket=ai_bucket, name=blob_name)\r\n blob.upload_from_string(data, content_type=mime_type, client=storage_client)\r\n return f"gs://{ai_bucket_name}/{blob_name}"'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f4842992400>)])]>

データモデル（`media_models.py`）

このファイルにより、データが厳格な構造（スキーマ）に従うことが保証されます。

構造化された出力: Pydantic BaseModel を使用することで、ツールが常に uri（リンク）とオプションの error メッセージを含む一貫した JSON オブジェクトを返すことを保証します。これにより、AI エージェントがツールの結果を理解して処理することがはるかに容易になります。

次のコードを dev_signal_agent/tools/nano_banana_mcp/media_models.py に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'from typing import Optional\r\nfrom pydantic import BaseModel\r\n\r\nclass MediaAsset(BaseModel):\r\n uri: str\r\n error: Optional[str] = None'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f4842992d30>)])]>

ツールの依存関係（`requirements.txt）`

コードの実行には uv を使用しますが、requirements.txt ファイルは、Nano Banana サーバーが機能するために uv がインストールする必要がある特定の依存関係を定義するため、依然として不可欠です。これにより、隔離された環境をサーバーの起動前にセットアップするために必要な「材料」が提供されます。

このファイルには、このツールに必要な 3 つのコアライブラリがリストされています。

google-cloud-storage: 生成された画像をクラウドでホストするために使用されます。
google-genai: Gemini 3 Pro の画像生成のロジックを提供します。
fastmcp: Python スクリプトを標準化された MCP ツールに変えるフレームワークです。

次のコードを dev_signal_agent/tools/nano_banana_mcp/requirements.txt に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'google-cloud-storage==3.6.*\r\ngoogle-genai==1.52.*\r\nfastmcp==2.13.*'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f4863bd1d30>)])]>

まとめ

シリーズのパート 1 では、Model Context Protocol（MCP）を通じて外部統合を標準化することにより、エージェントのコア機能を確立することに焦点を当てました。高速な依存関係管理のために uv を使用してプロジェクトを初期化し、トレンド発見のための Reddit、技術的なグラウンディングのための Google Cloud ドキュメント、マルチモーダル画像生成のためのカスタム「Nano Banana」MCP サーバーという 3 つの重要なツールセットを構成しました。Google ADK の McpToolset を利用することで、複雑な API ロジックをシンプルなプラグアンドプレイモジュールに抽象化し、ツールが共通のインターフェースを共有してインテリジェンスから統合を切り離せるようにしました。

技術的基盤について詳しく確認するには、Developer Knowledge MCP サーバーでナレッジグラウンディングの詳細を確認するか、Google ADK GitHub リポジトリでフレームワークのコア機能について調べることができます。

ツールセットが完全に構成され、使用できる状態になったので、パート 2 に進みましょう。パート 2 では、マルチエージェントアーキテクチャを構築し、Vertex AI Memory Bank を統合してこれらの機能をオーケストレートします。さらに詳しく調べる場合は、GitHub リポジトリでシリーズ全体の詳細なコードを確認できます。

この記事に対して、レビューとフィードバックを提供してくださった Remigiusz Samborski 氏に心より感謝いたします。

このようなコンテンツをさらにご覧になりたい場合は、LinkedIn と X で私をフォローしてください。

- AI / プロダクト / DevRel 責任者、Shir Meir Lador

LLM 推論の効率的フロンティアに到達するための 5 つの手法

Wed, 08 Apr 2026 02:10:00 +0000

※この投稿は米国時間 2026 年 3 月 28 日に、Google Cloud blog に投稿されたものの抄訳です。

モデル推論に費やした費用の分だけ、レイテンシとスループットのグラフ上で良いポジションが得られます。上の図には、ハードウェアから可能な限り最大のパフォーマンスを引き出した、最適な構成の曲線が示されています。この曲線は、金融のポートフォリオ理論から借用したもので、効率的フロンティアと呼ばれます。

ハードウェアの予算が固定されていると仮定すると、レイテンシとスループットをトレードオフできます。ただし、フロンティア曲線自体が移動しない限り、一方を改善するには他方を犠牲にする必要があります。根本的に異なる 2 つのダイナミクスが作用しており、これは本番環境で LLM を実行するすべての人にとって重要なインサイトです。

最初のダイナミクスはフロンティアに到達することです。これには、現在利用可能なあらゆる手法を適用することが含まれます。この部分は、自分で制御できます。継続的なバッチ処理、アテンションの分割、インテリジェントルーティング、投機的デコーディング、量子化はすべて、現在存在する手法です。これらの手法を使用していない場合、運用がフロンティアを下回り、パフォーマンスを最大限に引き出すことができません。

2 つ目のダイナミクスは、フロンティア自体が常に外側に移動していることです。この部分は、ほとんどの場合、自分で制御できません。研究者は新しいアルゴリズムを発表し、ハードウェアベンダーは新しいアーキテクチャを出荷し、オープンソースプロジェクトは成熟します。ブレイクスルーが起こるたびに、物理的に達成可能なことが再定義され、曲線が拡大されるため、昨日の最適な構成が今日の非効率になります。

プラットフォームエンジニアの仕事は、フロンティアにできるだけ近い位置を維持しながら、新しい進歩がもたらされるたびにそれを吸収できる十分な柔軟性を持つインフラストラクチャを構築することです。この記事では、そのためのツールをご紹介します。

推論に効率的フロンティアがある理由

すべての LLM リクエストには 2 つの計算フェーズがあり、それぞれ異なるハードウェアリソースでボトルネックが発生する可能性があります。

1. プレフィル（コンピューティングバウンド）: このフェーズでは、GPU が入力プロンプト全体を一度に処理して、アテンション機構の Key-Value（KV）キャッシュを構築します。命令は並列でバッチ処理されるため、GPU のコンピューティングコア（テンソルコア）の使用率が高くなります。このフェーズは高速かつ効率的です。プロセッサは、大規模な行列乗算を実行するために必要なすべてのデータをすぐに利用できます。プロンプトが長くなると、単純に計算量が増えます。

2. デコード（メモリ帯域幅バウンド）: このフェーズでは、新しいトークンが一度に 1 つずつ自己回帰的に生成されます。1 つのトークンのみを生成する場合、GPU は作業をバッチ処理できません。モデル全体の重みと増大する KV キャッシュを高帯域幅メモリ（HBM）からコンピューティングコアにフェッチする必要があります。その後、GPU はその 1 つのトークンを計算し、次のトークンに対して再び同じ処理を行うのを待ちます。

この不一致こそが、フロンティアが存在する根本的な理由です。トレードオフなしに、単一のシステムを同時に両方のフェーズ向けに最適化することはできません。

推論の 2 つの軸

LLM 推論の効率的フロンティアでは、リスクとリターンの代わりに、ハードウェア予算が固定されているという前提で、別の基本的なトレードオフが測定されます。

軸	測定される主な指標	ハードウェアの制約
レイテンシ（X 軸）	最初のトークンまでの時間（TTFT）+ トークン間の時間（TBT）	コンピューティング（プレフィル）とメモリ帯域幅（デコード）
スループット（Y 軸）	すべての同時ユーザーの 1 秒あたりの合計トークン数	バッチサイズ × メモリ容量

費用は、レイテンシとスループットのグラフ自体を購入する制約です。ハードウェアの予算を増やすか、業界が画期的な新しいアルゴリズムを発明すると、フロンティア曲線全体が外側にシフトします。特定の予算とソフトウェアスタックで、最適ではない状態からそのフロンティアに向かって移行するための現在のベストプラクティスを適用できます。

フロンティアに到達する: 制御可能な 5 つの手法

現在、本番環境における大部分の推論システムの運用は、フロンティアを下回っています。優れた手法は存在するものの、そのような手法をまだ採用していないために、パフォーマンスが向上していないのです。このセクションで説明する手法はすべて、現在利用可能なものです。これらの手法を適用しない場合、運用が曲線を下回ることになります。

1. モデル階層間のセマンティックルーティング

すべてのクエリに 4,000 億パラメータのモデルが必要なわけではありません。単純な分類、要約、書式設定のタスクは、トークンあたりの費用が桁違いに安い、より小さな量子化モデルにルーティングできます。ゲートウェイエッジの軽量分類器がクエリの複雑さを分析し、それに応じてルーティングします。難しい推論にはフロンティアクラスのモデル、それ以外には小規模モデルを使用します。

セマンティックルーティングにより、システムは理論上の最大スループットに劇的に近づき、簡単なタスクでの無駄なサイクルが回避されます。集約された出力の品質が犠牲になることはありません。

2. プレフィルとデコードの分離

プレフィルフェーズとデコードフェーズを異なるハードウェアに物理的に分離することは、現在利用可能な、アーキテクチャ上最も重要な最適化の一つです。

プレフィルフェーズには、コンピューティング能力の高い GPU が必要です。デコードフェーズには、高帯域幅メモリが必要です。両方のフェーズを同じ GPU に強制的に割り当てると、一方のリソースが常に十分に活用されない状態になります。

両方のフェーズをそれぞれ理論上のハードウェア上限に近づけるには、専用のプレフィルクラスタとデコードクラスタを実行します。これらのクラスタを、圧縮された KV キャッシュの状態のみを同じ GPU に転送する高速ネットワークで接続すると、一方のリソースが常に十分に活用されない状態になります。

3. 量子化: 精度と速度のトレードオフ

モデルの重みを FP16 から INT8 または INT4 形式に減らすと、メモリ使用量を半分または 4 分の 1 に削減できます。デコードフェーズにはメモリ帯域幅の制限があるため、4 ビットの重みは 16 ビットの重みよりも最大 4 倍速く読み取ることができます。このアプローチにより、TBT が直接改善されます。

単純な量子化ではモデル出力の品質が低下するため、品質とのトレードオフが生じます。Activation-aware Weight Quantization（AWQ）や GPTQ などの最新の手法では、重要な重みの品質を維持しながら、他の重みを積極的に圧縮して、INT4 の速度で FP16 に近い品質を実現します。

4. コンテキストルーティング: ほとんどのチームが見落としている最大の要素

数十個のモデルレプリカを使用した本番環境でのデプロイでは、ルーティングレイヤが、現在最大の競争優位性を獲得できるかどうかの分かれ目となっています。

2026 年は、接頭辞のキャッシュ保存が基盤となっています。10 人のユーザーが 100 ページの RAG ドキュメントについてまったく同じ質問をしたり、同一の膨大なシステムプロンプトを使用したりする場合、コンピューティング負荷の高いプレフィルフェーズを 10 回実行すべきではありません。KV キャッシュを一度計算して保存し、他の 9 人のユーザーが再利用できるようにする必要があります。このアプローチにより、TTFT を最大 85% 短縮し、コンピューティング費用を大幅に削減できます。

ただし、注意点があります。標準の L4 ロードバランサはリクエストをランダムに分散します。ユーザー 2 のリクエストがユーザー 1 のリクエストとは異なる GPU に到達した場合、接頭辞のキャッシュは役に立たず、システムはキャッシュをゼロから再計算する必要があります。

コンテキスト認識型 L7 ルーティングが差別化要因となるのはこのためです。インテリジェントルーターは、受信したプロンプトの接頭辞を検査し、そのコンテキストをキャッシュにすでに保持している特定の Pod に意図的にリクエストをルーティングします。冗長な作業にコンピューティング能力を無駄に費やすことがなくなり、レイテンシとスループットをハードウェアの物理的な上限に即座に近づけることができます。

5. 投機的デコーディング

重要な点として、デコードフェーズでは、メモリ帯域幅にボトルネックがあるため、テンソルコアはほとんどアイドル状態です。投機的デコーディングは、この無駄な計算能力を利用します。

小規模で高速な「ドラフト」モデルが、複数の候補トークンを低コストで生成します。その後、大規模なターゲットモデルが、すべての候補を単一のフォワードパスで検証します。これは、シーケンシャルメモリバウンドのオペレーションではなく、並列コンピューティングバウンドのオペレーションです。ドラフトモデルが候補を正しく予測した場合、1 トークンのメモリコストで 4～5 トークンを生成したことになります。

このアプローチにより直接、メモリ帯域幅によって設定された TBT の下限よりも短い TBT を達成できます。レイテンシの影響を受けやすいワークロードに投機的デコーディングを使用していない場合、利用可能な最も効果的な最適化の一つを活用できていないことになります。

ドラフトモデルを追加すると、運用が多少複雑になり、コンピューティング費用がわずかに増加する可能性がありますが、ドラフトモデルはメインモデルに比べて比較的小さなものです。これとレイテンシをトレードオフする価値はあります。

なお、一部の新しいモデルでは自己投機的デコーディングが導入されており、2 つ目のモデルを管理するオーバーヘッドがなくなります。これらのモデルは、将来の追加トークンを同時に予測するようにトレーニングされた特殊な内部レイヤ（多くの場合、予測ヘッドと呼ばれる）を使用します。これらのモデルは一般に、非常に有意義なトークンヒット率を達成します。

ケーススタディ: Vertex AI がフロンティアに近づいた方法

Vertex AI エンジニアリングチームは、標準の Kubernetes Gateway API を基盤として構築された GKE Inference Gateway を採用したときに、フロンティアに近づきました。Inference Gateway はレイヤ 7 でリクエストをインターセプトし、2 つの重要なインテリジェンスレイヤを追加しました。

負荷認識ルーティング: モデルサーバーの Prometheus エンドポイントからリアルタイムの指標（KV キャッシュ使用率やキューの深さなど）を直接スクレイピングしました。このプロセスでは、リクエストを最も迅速に処理できる Pod にルーティングします。
コンテンツ認識ルーティング: リクエストの接頭辞を検査し、そのコンテキストを KV キャッシュにすでに保持している Pod にトラフィックをルーティングしました。このプロセスでは、コストのかかる再計算を回避できます。

本番環境のワークロードをこのインテリジェントなルーティングアーキテクチャに移行したところ、ネットワークレイヤの最適化が、大規模なパフォーマンス向上を実現する鍵であることが、Vertex AI チームによって証明されました。本番環境のトラフィックで検証した結果は、以下のとおりです。

Qwen3-Coder（コンテキストの多いコーディングエージェントワークロード）で TTFT が 35% 短縮
DeepSeek V3.1（バースト性の高いチャットワークロード）の P95 テールレイテンシが 2 分の 1（52%）に改善
接頭辞キャッシュヒット率が 2 倍（35% から 70% に最適化）

まとめ

LLM 推論には効率的フロンティアがあります。効率的フロンティアとは、特定のコンピューティング予算に対してレイテンシとスループットの最適なバランスが取れた絶対的な境界を表します。

効率的フロンティアに到達することは、自分で制御できます。現在、継続的なバッチ処理、アテンションの分割、インテリジェント L7 ルーティング、投機的デコーディング、量子化、プレフィルとデコードの分離といった手法が存在します。GKE Inference Gateway のケーススタディでは、ハードウェア、モデル、クラスタサイズを変更せずに、ルーティングのみで、TTFT が 35% 短縮され、キャッシュ効率が 2 倍になったことが示されています。フルスタックを適用しない場合、運用は曲線を下回り、トークンごとに過剰な料金を支払うことになります。

フロンティア自体が外側に移動し続けています。この部分は、自分で制御できません。研究者は新しいアルゴリズムを発表し、ハードウェアベンダーは新しいアーキテクチャを出荷し、オープンソースのサービングフレームワークはこれらのアルゴリズムとアーキテクチャを統合します。18 か月前には最先端の最適化だったものが、今では基本的な必須事項となっています。次にどのようなブレークスルーが起こるかを予測するのではなく、ブレークスルーが起こったときにそれを吸収できる柔軟なインフラストラクチャを構築することが、あなたの仕事です。

推論エコノミクスで成功する組織は、GPU を最も多く保有している組織ではなく、現在のフロンティアとのギャップを体系的に埋めながら、明日のフロンティアに備える組織です。

これらの最適化手法をご自身の LLM 推論ワークロードに適用したことがある方は、その体験談をぜひお聞かせください。構築したものを LinkedIn、X、Bluesky で共有していただければ幸いです。

- デベロッパーリレーションズ担当ディレクター、Karl Weinmeister

AI リテラシーの新しい形: 学生デベロッパーを対象とした調査結果

Tue, 07 Apr 2026 01:00:00 +0000

※この投稿は米国時間 2026 年 3 月 27 日に、Google Cloud blog に投稿されたものの抄訳です。

AI により、学生デベロッパーはかつてないレベルで作業を効率化し、難しい問題を解決したり、野心的なプロジェクトに取り組んだりできるようになりました。一方、この新技術の登場によって、技術専攻の学生たちは学習について本質的な問いに向き合うようになってきています。

それは、AI をどの程度、何に使用すべきか、という問題です。

Google の DORA 2025 レポートによると、現在、日々の業務で AI を使用している技術者は 90% に達しています。こうした状況の中で、次世代が AI ツールとどう付き合っているのかを理解することがこれまでになく重要になっています。カリフォルニア大学バークレー校の学生を対象とした Google の調査では、学業における不正行為や知的作業の省略といった懸念を覆す結果が明らかになりました。学生は AI を近道としてではなく、学習パートナーとして捉え、タスクによって意図的に使用したり、使用を控えたりしています。

AI がソフトウェア開発の基盤となるにつれ、AI ツールを導入するかどうかよりも、懸命な活用方法が焦点になってきています。カリフォルニア大学バークレー校の学生たちは、その答えの一つを示してくれます。それは、彼らのもつ好奇心や、慎重さ、学習に対する純粋な意欲を、AI は支えることはできても、取って代わることはできない、ということです。

調査

カリフォルニア大学バークレー校の 4 人の学生チーム（Andrew Harlan、Mindy Tsai、Kenny Ly Hong、Karissa Wong）が、学業での AI の利用状況を把握するため、コンピュータサイエンス、電気工学、デザイン、データサイエンス専攻の学生を対象に調査を実施しました。この調査には、混合手法を使用しています。

また、同校の別のチーム（Edward Fraser、Jessie Deng、Eileen Thai）が、デベロッパー歴 1～5 年の人々を対象に、アイトラッキング技術を使って AI コーディングアシスタントの使用状況を観察しました。両チームとも専任メンターの支援のもと調査を進め、混合手法調査については Google 社員の Harini Sampath、Becky Sohn、Derek DeBellis が、アイトラッキング調査についてはカリフォルニア大学バークレー校の John Chuang 教授（博士）が助言を行っています。

これらの調査から、学生が AI を活用すると同時に、真の専門知識を身につけるためにどのような方法をとっているのか、3 つの重要な結果が明らかになりました。学生の間で見られるパターンは、実際に開発職に就いている人々を対象にした DORA の調査結果とよく似通っています。

調査結果その 1: 24 時間 365 日、いつでも頼れる先生

AI は近道ではなく家庭教師

調査で AI との関係性について尋ねられた学生は皆一様に、学びの場ならではの言葉を使いました。AI のことを、アシスタントや生産性向上ツールではなく、「家庭教師」や「先生」と呼んでいたのです。

「AI は教師のような存在です。内容の濃い資料を解説してもらったり、データベースにあらかじめ記述されているコードを部分的に説明してもらったりするなど、プロジェクトの基礎的な部分について理解を深めるためにとても役立っています。」

「[AI を] お抱えの家庭教師として利用しています。授業や講義の特定のトピックの [理解を深める] ために。コンピュータサイエンスだけでなく、あらゆる授業で使っています。」

ここで重要なのは、学生が AI に依存せず、計画的に使用しているということです。AI に課題を完成させるのではなく、自分の理解度を踏まえて AI を使用し、知識の抜けを特定したり、不確かな概念を明らかにしたり、学習プロセスをリードしてもらったりしています。回答の中には、講義で取り上げられた複数の学術論文を要約してもらい、どれを深く読みこむべきかを判断するといった使い方や、コードでエラーが発生する理由を AI に説明してもらう、といったものがありました。

ある学生は、学習プロセスに次のように組み込んでいます。

「教授の説明がわからなかったときは AI に尋ねます。たとえば、ある概念や、コードの機能について説明してもらったりします。また、ラボのどこから手をつけたらよいかわからないときは、AI にプロンプトで尋ねます。それからコードを書き始め、修正すべき点を尋ねるといった具合です。」

学習障がいのある学生にとっては、常に利用できるという点が、不利な状況を克服するために役立っています。

「私は学習障がいがあるため、問題を理解するのに人より時間がかかります。AI にはすごく助けられています。24 時間 365 日、いつでも付いていてくれるサブ教師のような存在です。」

AI を使えば、学校の営業時間に縛られることなく、いつでも理解を掘り下げられます。AI のおかげで脳の処理能力に余裕が生まれ、より高度な思考が可能となります。

「実際にコーディングする時間は減り、全体のアイデアを練るのに時間をかけられるようになりました。今では、手動でコードを生成する代わりに、ロジックとコンセプトの検討や、アイデアの創出に時間を費やしています。」

こうしたコメントから、AI が最終的な作品を仕上げるためではなく、探索ツールとして利用されている様子が浮かび上がります。これは、DORA の調査結果と一致しています。調査によると、AI がルーチンワークを引き受けることで、デベロッパーはユーザーへの価値提供に専念できるようになっています。

調査結果その 2: 過度な依存に対する積極的な抵抗

学びのプロセスを守るために、境界線を設ける

学生たちは、AI を学習ツールとして活用する一方で、AI への過依存への不安を率直に表現しました。

「AI がなくなったら、自分で解決方法を探すのに苦労してしまうかもしれません。」

エッセイ執筆中の脳活動を脳波検査で測定した最近の研究では、AI の利用者は、検索エンジンやツールを使用しない人に比べ、認知エンゲージメントのパターンが弱いことがわかりました。また、AI のヘビーユーザーが、アシスタントを使わずにエッセイを書いてみたところ、以前に書いた作品についての記憶があまりなく、自分の作品であるという意識も低いことがわかりました。このことを、論文の著者は「認知の負債」と表現しています。1

一方で、ポジティブな兆候が明らかになりました。学生たちは、この認知上のリスクをただ受け入れるのではなく、意図的に境界線を設けて対応しています。

機械工学専攻のある学生は、電子機器を何年も使用するうちに、以下のように能力ベースの AI 使用ルールを確立したといいます。

「サーボや超音波などの基本的センサーなら自分でコーディングできますが、複雑なセンサーで、かつ、機能を厳密に把握する必要性がないときは、AI を使用します」と回答し、次のように説明しています。「何かがうまくいかないとき、その理由を理解できても、問題を解決するための直接的な言語を知らない場合があります。AI は、そのような状況で役立ちます。」

この学生は、最近携わったプロジェクト（触って操作できるストーリーテリングツールの構築）において、基本的なコンセプトを理解した後、カウントおよび比較のシステム構築のために助けを求めたとのことです。「AI は、基本構造のセットアップに大変役立ちましたが、その後、微調整のコーディングは自力でやる必要がありました。」また、作業の振り分けについては、次のように明確な意見を述べています。「自分でも引き続き、コードを書いています。技術者のように丸投げするわけではなく、AI と共同で作業を進め、私が司令塔となって AI にやってほしいことを指示します。ただやみくもにリクエストしても、まったく役に立ちません。」

学生が AI を利用する際には、明確な利用ルールを設けているケースが多く見られました。

「AI にはたまに、完全な答えではなく方向性だけを示すように頼みます。」

過度な依存を避けるため、学生は以下のような具体策を編み出しています。

高度なモデルの利用を避ける:

「料金制の AI ツールを使用するつもりはありません。AI モデルを使いすぎてしまう恐れがありますから。」

AI の使用、不使用を交互に繰り返す:

「for ループの処理など、一部の処理はまた自分で書くようになりました。」

「バイブコーディング」を警戒する:

「AI ツールがデベロッパーの生産性を高めるために役立つことは間違いありません。ただし、バイブコーディングに慣れてしまわないよう、十分な注意が必要です。AI が生成するコードを理解して検証し、適切な方法で使用するということが大前提です。」

こうした懸念は、学生たちが認知について意識的に考えているということを示しています。彼らは、一番楽な方法が最も学習効果が高いわけではないと認識しています。これは DORA の調査結果とも一致しています。調査によると、AI の導入率が 90% にのぼるにもかかわらず、利用者の約 30% が AI が生成したコードをほとんど（あるいはまったく）信用していないと答えています。AI を効果的に使用するには、単に導入するだけでなく、厳しい評価と検証の方法を習得することが求められます。

調査結果その 3: AI の使いどころを心得ている

アイトラッキングデータからわかったこと

アイトラッキング技術を使用した調査では、人の動作の面から検証を行いました。1～5 年の経験を持つデベロッパーを対象に、AI コーディングアシスタントとやり取りする様子を観察したところ、タスクの種類によって AI の利用に大きな違いがあることがわかりました。

思考と深い理解が必要なタスク: AI への視覚的注目が 1% 未満
機械的なタスク（ボイラープレートコードなど）: AI への視覚的注目が 19%

高度な作業においては、たとえ AI の提案が正確で時間の節約につながるような場合でも、敢えて無視されていることがわかりました。深い理解が必要なときは、AI は認知上の負担となります。熟練デベロッパーは、AI をオフにすべきときを心得ています。

すべてを任せるのではなく、意図的に取り入れる

学生への聞き取り調査からも、学生が AI を用途に応じて使い分けている様子が伺えます。

「私は普段、とっかかりとなるアイデアを得るために AI を使っています。」

「AI の使用が許可されていることは知ってましたが、学習と試行錯誤のプロセスを大事にしました。創造性の余地も必要です。」

カスタマイズが肝

現在、ほとんどの AI コーディングアシスタントは、インライン提案のオン / オフを切り替えたり、オンデマンド専用モードに設定したり、提案頻度を調整したりできます。これらの設定を試して、タスクとその認知要件に応じて AI を使い分けることで、ルーチンワークでは助けてもらいつつ、自分で深く考えたい仕事の邪魔をされないようにすることができます。

この調査結果が業界において意味すること

AI を利用した開発の未来を形作っていくのは、今の学生たちです

調査に協力してくれた学生たちは、時代の一歩先をいっており、すでに AI リテラシーを身につけています。用途に応じた使い分けや、出力の検証方法を心得ており、自らの理解力を維持するためにときには敢えて手動で作業するといった対策をとっています。AI 導入を検討中の方にとって、こうした学生の経験は、進むべき方向を探るヒントとなります。

さまざまなカスタマイズ設定を試す: 作業の妨げとならず、助けとなるような設定を見つけましょう。
ワークフローに検証プロセスを取り入れる: AI の提案を無批判に受け入れないようにしましょう。
自分の聖域を確保する: スピードよりも深い理解が重要となる高度な問題には、AI の助けを借りずに自分で取り組むようにしましょう。

業界の専門家が AI の導入をどのように進めているかについて詳しくは、2025 年 DORA レポート: AI 支援によるソフトウェア開発の現状をダウンロードしてご覧ください。カリフォルニア大学バークレー校の研究者との共同研究による論文全文もあわせてお読みいただけます。

^{1. Kosmyna, Nataliya, et al. "Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task." arXiv, 10 June 2025, doi:10.48550/arXiv.2506.08872.（参照日付: 2026 年 1 月 28 日）}

- Andrew Harlan 博士（独立系 UX リサーチャー兼クリエイティブテクノロジスト）

- Steve Fadden 博士（Google、UX リサーチ担当リード）

分散 AI エージェントの構築

Thu, 02 Apr 2026 03:00:00 +0000

※この投稿は米国時間 2026 年 3 月 19 日に、Google Cloud blog に投稿されたものの抄訳です。

率直に言って、1 回だけ動作する AI エージェントを構築するのは簡単です。しかし、本番環境で確実に動作する AI エージェントを構築し、既存の React や Node.js アプリケーションと統合する場合は、まったく別の話です。

（説明は省略して、コードに直接移動したい場合は、GitHub のコース作成エージェントのアーキテクチャをご覧ください。）

身近な例で考えてみましょう。トピックを調査し、コンテンツを生成して、それを評価するという複雑なワークフローがあるとします。このワークフローを、1 つの巨大な Python スクリプトまたは大きなプロンプトに詰め込んだとしましょう。ローカルマシンでは正常に動作しましたが、スマートな外観のフロントエンドに接続しようとすると、厄介なことになります。レイテンシが急上昇し、デバッグが困難で、スケールするためにモノリス全体の複製が必要となります。

一方、AI に対応するために、アプリケーション全体を書き換える必要がないとしたらどうでしょうか。プラグを差し込むだけで使えるとしたら？

この投稿では、オーケストレーターパターンという優れた方法について説明します。具体的には、すべてを請け負う強力なエージェントを 1 つだけ作るのではなく、複数の特化した分散マイクロサービスから成るチームを構築します。このアプローチにより、モノリスの書き換えに悩まされることなく、強力な AI 機能を既存のフロントエンドアプリケーションに直接統合することが可能となります。

そのために、Google の Agent Development Kit（ADK）を使ってエージェントを構築し、Agent-to-Agent（A2A）プロトコルによって複数のエージェントを接続して相互通信し、Cloud Run 上でスケーラブルなマイクロサービスとしてデプロイします。

分散エージェントを使用する理由（フロントエンドチームに感謝される理由）

すでに完成された状態の Next.js アプリケーションがあるとします。これに、「コース作成ツール」という機能を追加したいとしましょう。

そのためにモノリスエージェントを構築すると、フロントエンドは、長時間かかる単一プロセスがすべて完了するまで待たされることになります。調査部分が滞ると、リクエスト全体がタイムアウトになります。また、個々のエージェントを必要に応じてスケールするといったこともできません。たとえば、評価エージェントがより多くの処理能力を必要とする場合、評価エージェントだけでなく、すべてのエージェントをスケールアップすることになります。

これに対し、分散オーケストレーターパターンを使用すれば、スケーラビリティと柔軟性が得られます。

シームレスなインテグレーション: フロントエンドは 1 つのエンドポイント（オーケストレーター）と通信し、オーケストレーターがバックグラウンドで複雑な処理を管理します。
個別にスケーリング: 評価ステップに時間がかかる場合は、そのサービスだけを 100 インスタンスにスケールアップし、調査サービスは小規模のままにできます。
モジュール式: 高パフォーマンスのネットワーキング部分を Go で、データサイエンス部分を Python で記述できます。これらの通信には HTTP を使用します。

全体的な設計: コース作成アプリ

では、コース作成システムを構築しましょう。以下の 3 つのスペシャリストに分けて考えます。

調査担当: 情報を掘り起こすスペシャリスト。
評価担当: 品質を保証する QA スペシャリスト。
オーケストレーター: 作業間の調整を行い、フロントエンドと通信するマネージャー。

ステップ 1: スペシャリスト（リサーチャー）の配備

まず、調査の担当者が必要です。ADK を使って、Google 検索の部分のみを担当するエージェントを構築しましょう。

code_block: <ListValue: [StructValue([('code', '# researcher/app/agent.py\r\nfrom google.adk.agents import Agent\r\nfrom google.adk.tools import google_search\r\n\r\nresearcher = Agent(\r\n name="researcher",\r\n model="gemini-2.5-flash",\r\n description="Gathers information on a topic using Google Search.",\r\n instruction="""\r\n You are an expert researcher. Your goal is to find comprehensive information.\r\n Use the `google_search` tool to find relevant information.\r\n Summarize your findings clearly.\r\n """,\r\n tools=[google_search],\r\n)'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f486568b100>)])]>

ご覧のように、とても簡単です。このエージェントは、コースやフロントエンドについては関知しません。調査のみを行います。

ステップ 2: 評価担当者（構造化されたデータ出力）

エージェントからの長ったらしい説明はいりません。コード側で判断しやすいよう、合格（pass）または不合格（fail）の厳密な評価が必要です。Pydantic を使って、このデータ規定を適用しましょう。

code_block: <ListValue: [StructValue([('code', '# judge/app/agent.py\r\nfrom pydantic import BaseModel, Field\r\nfrom typing import Literal\r\n\r\nclass JudgeFeedback(BaseModel):\r\n status: Literal["pass", "fail"] = Field(\r\n description="Whether the research is sufficient (\'pass\') or needs more work (\'fail\')."\r\n )\r\n feedback: str = Field(\r\n description="Detailed feedback on what is missing."\r\n )\r\n\r\njudge = Agent(\r\n name="judge",\r\n model="gemini-2.5-flash",\r\n description="Evaluates research findings.",\r\n instruction="""\r\n You are a strict editor. Evaluate the findings.\r\n If they are missing key info, output status=\'fail\' and provide feedback.\r\n """,\r\n output_schema=JudgeFeedback, # Enforce the contract!\r\n)'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f486568baf0>)])]>

これで、評価担当者が JSON で話すようになり、アプリケーションロジックはそれを信頼できます。

ステップ 3: 共通言語（A2A プロトコル）

ここでマジックを使いましょう。A2A プロトコルを使って、これらのエージェントをウェブサービスとしてラップします。エージェントの共通言語のようなものとお考えください。エージェントは機能を説明し（agent.json）、標準の HTTP で通信します。

code_block: <ListValue: [StructValue([('code', '# researcher/app/server.py\r\nfrom fastapi import FastAPI\r\nfrom a2a.server.apps import A2AFastAPIApplication\r\nfrom app.agent import app as adk_app\r\n\r\n# ... setup runner ...\r\n\r\n# Create the A2A App wrapper\r\na2a_app = A2AFastAPIApplication(agent_card=agent_card, http_handler=request_handler)\r\n\r\napp = FastAPI(lifespan=lifespan)\r\n\r\n# Register routes: /.well-known/agent.json and /rpc\r\na2a_app.add_routes_to_app(app)'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f486568bd00>)])]>

これで、リサーチャー（ポート 8000 で実行されるマイクロサービス）を配備できました。このサービスを、オーケストレーターなど、あらゆるものから呼び出すことが可能です。

ステップ 4: オーケストレーターパターン

では、すべてを組み合わせましょう。オーケストレーターは、請負業者のようなものです。つまり、自分で調査を行わず、リサーチャーを雇います。自分で判断を下さず、評価担当者に尋ねます。

重要な点は、フロントエンドはこのエージェントのみを識別できればよいということです。

code_block: <ListValue: [StructValue([('code', '# orchestrator/app/agent.py\r\nfrom google.adk.agents import LoopAgent, SequentialAgent\r\nfrom google.adk.agents.remote_a2a_agent import RemoteA2aAgent\r\n\r\n# Connect to the remote Researcher service\r\nresearcher = RemoteA2aAgent(\r\n name="researcher",\r\n agent_card="http://researcher-service:8000/.well-known/agent.json",\r\n description="Gathers information on a topic."\r\n)\r\n\r\n# Connect to the remote Judge service\r\njudge = RemoteA2aAgent(\r\n name="judge",\r\n agent_card="http://judge-service:8000/.well-known/agent.json",\r\n description="Evaluates research findings."\r\n)\r\n\r\n# The Orchestrator manages the loop\r\nresearch_loop = LoopAgent(\r\n name="research_loop",\r\n sub_agents=[researcher, judge, escalation_checker],\r\n max_iterations=3,\r\n)\r\n\r\n# The full pipeline\r\nroot_agent = SequentialAgent(\r\n name="course_creation_pipeline",\r\n sub_agents=[research_loop, content_builder],\r\n)'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f486568ba30>)])]>

オーケストレーターが複雑な処理（再試行、ループ、状態管理）を担当するため、フロントエンドはクリーンかつシンプルに保たれます。

デプロイ:「食料品店」モデル

このシステムを Cloud Run にデプロイすることを、私は「食料品店」モデルと呼んでいます。チェックアウトの列（リサーチャーのタスク）が長くなっても、新しい店舗を建設する必要はありません。レジを増やせばいいだけです。Cloud Run は、調査の負荷増大に対応するために調査サービスのみをスケールし、評価サービスはそのまま保たれます。

注意事項、セキュリティ上の配慮

もちろん、大いなる力には大きな責任が伴います（そして、セキュリティチェックが必要となります）。

認証: このデモでは、エージェントはオープンな HTTP を介して通信しています。本番環境では、このアクセスを制限する必要があります。mTLS、OIDC、または API キーを使用して、オーケストレーターのみがリサーチャーと通信できるようにします。
レイテンシ: ホップごとに時間が追加されます。オーケストレーターパターンは、詳細レベルの頻繁なインタラクションではなく、ざっくりとしたタスク（「このトピックを調査して」など）に使用するようにしましょう。
エラー処理: ネットワークにはエラーがつきものです。オーケストレーターには、タイムアウトと再試行を適切に処理できるような堅牢性が必要です。

構築を始めるにあたって

あらゆる作業を請け負う 1 つの巨大なエージェントを構築するのはやめましょう。オーケストレーターパターンと分散マイクロサービスを使用することで、スケーラブルで保守が容易な AI システムを構築できるだけでなく、既存のアプリとスムーズに連携できるというメリットも得られます。

コードについては、GitHub のコース作成エージェントのアーキテクチャで詳細をご確認ください。

準備ができたら、Cloud Run、ADK、A2A を使ってさっそくエージェントチームを結成しましょう。

- AI デベロッパーリレーションズエンジニア、Amit Maraj

マルチクラスタ GKE Inference Gateway のご紹介: 世界中で AI ワークロードをスケール

Wed, 25 Mar 2026 03:00:00 +0000

※この投稿は米国時間 2026 年 3 月 18 日に、Google Cloud blog に投稿されたものの抄訳です。

AI の世界は急速に変化しており、モデルのサービングを大規模かつ確実に行う必要性も高まっています。このたび、マルチクラスタ GKE Inference Gateway のプレビュー版がリリースされましたのでお知らせいたします。これにより、複数の Google Kubernetes Engine（GKE）クラスタにわたり（異なる Google Cloud リージョンにまたがる場合も含め）、AI / ML 推論ワークロードのスケーラビリティ、復元力、効率性を強化できます。

GKE Gateway API の拡張機能として構築されたマルチクラスタ Inference Gateway は、マルチクラスタ Gateway の機能を活用して、特に要求の厳しい AI アプリケーション向けに、モデル対応のインテリジェントなロードバランシングを提供します。

AI 推論にマルチクラスタを使用する理由

AI モデルの複雑性が増し、ユーザーのグローバル化が進むにつれて、単一クラスタのデプロイでは次のような課題に直面する可能性があります。

可用性のリスク: リージョンの停止やクラスタのメンテナンスがサービスに影響を及ぼす可能性があります。
スケーラビリティの上限: 単一のクラスタまたはリージョン内で、ハードウェアの上限（GPU / TPU）に達してしまいます。
リソースのサイロ化: あるクラスタで十分に活用されていないアクセラレータ容量を別のクラスタで使用できません。
レイテンシ: サービスを提供しているクラスタから離れているユーザーはレイテンシが高くなる可能性があります。

マルチクラスタ GKE Inference Gateway は、これらの課題に正面から取り組み、次のようなさまざまな機能とメリットを提供します。

信頼性とフォールトトレランスの強化: 異なるリージョン間を含め、複数の GKE クラスタにわたってトラフィックをインテリジェントにルーティングします。1 つのクラスタまたはリージョンで問題が発生した場合、トラフィックは自動的に再ルーティングされ、ダウンタイムが最小限に抑えられます。
スケーラビリティの向上とリソース使用量の最適化: さまざまなクラスタから GPU / TPU リソースをプールして活用できます。単一クラスタの容量を超えてバーストすることで需要の急増に対応し、利用可能なアクセラレータをフリート全体で効率的に活用できます。
グローバルに最適化されたモデル対応のルーティング: Inference Gateway は、高度なシグナルを使用してスマートなルーティング判断を下すことができます。GCPBackendPolicy を使用して、リアルタイムのカスタム指標（モデルサーバーの KV キャッシュ使用率指標など）に基づいてロードバランシングを構成できるので、最適なバックエンドインスタンスにリクエストが送信されるようになります。処理中リクエストの制限など、他のモードもサポートされています。
運用の簡素化: モデルを複数の「ターゲットクラスタ」で実行しながら、専用の GKE「構成クラスタ」で 1 つの Inference Gateway 構成を使用して、グローバルに分散された AI サービスへのトラフィックを管理できます。

仕組み

GKE Inference Gateway には、InferencePool と InferenceObjective という 2 つの基本リソースがあります。InferencePool は、同じコンピューティングハードウェア（GPU や TPU など）とモデル構成を共有する Pod のリソースグループとして機能し、スケーラブルで高可用性のサービングを実現します。InferenceObjective は、特定のモデル名を定義し、サービングの優先順位を割り当てます。これにより、Inference Gateway はトラフィックをインテリジェントにルーティングし、レイテンシの影響を受けやすいタスクと緊急性の低いワークロードを多重化できます。

このリリースでは、Kubernetes カスタムリソースを使用して、分散推論サービスが管理されます。各「ターゲットクラスタ」の InferencePool リソースは、モデルサーバーのバックエンドをグループ化します。これらのバックエンドはエクスポートされ、「構成クラスタ」で GCPInferencePoolImport リソースとして表示されます。構成クラスタ内の標準の Gateway リソースと HTTPRoute リソースは、エントリポイントとルーティングルールを定義し、トラフィックをこれらのインポートされたプールに転送します。CUSTOM_METRICS や IN_FLIGHT リクエストの使用など、きめ細かいロードバランシングの動作は、GCPInferencePoolImport にアタッチされた GCPBackendPolicy リソースを使用して構成されます。

このアーキテクチャにより、グローバルな低レイテンシのサービング、障害復旧、容量のバースト、異種ハードウェアの効率的な使用などのユースケースが可能になります。

GKE Inference Gateway のコアコンセプトについて詳しくは、ガイドをご覧ください。

使ってみる

AI 推論サービングワークロードをより多くの場所とより多くのユーザーにスケールする際に、マルチクラスタ GKE Inference Gateway をぜひお試しください。詳細と利用方法については、次のドキュメントをご覧ください。

- シニアプロダクトマネージャー、Arman Rye

- シニアスタッフソフトウェアエンジニア、Andres Guedez

Vertex AI で復元力の高い LLM アプリケーションを構築し、429 エラーを減らす

Mon, 23 Mar 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 3 月 13 日に、Google Cloud blog に投稿されたものの抄訳です。

Vertex AI で大規模言語モデル（LLM）を活用したアプリケーションを構築するのは楽しいことですが、429 エラーが発生すると、イライラの原因になることがあります。これらのエラーは、リクエストの受信速度が、その時点でサービスが処理できる量を上回っていることを示しています。

昨年、Google はこれらの 429 エラーの処理に関するガイドを公開しました。この記事では、Vertex AI の使用量モデルについて詳しく掘り下げ、リクエストフローを管理するためのアーキテクチャのベストプラクティスについて説明します。これにより、スムーズで復元力が高く、真にスケーラブルな AI アプリケーションを構築できます。

適切な使用量オプションの選択

Vertex AI は、さまざまなタイプとボリュームの API トラフィックに対応するように設計された、幅広い使用量モデルが用意されています。429 エラーを最小限に抑えるための主な戦略は、アプリケーション固有のトラフィックパターンに最も適した使用量モデルを選択することです。

デフォルトオプション: Vertex AI の Gemini におけるデフォルトオプションは、Standard 従量制（Paygo）です。Standard 従量制（Paygo）トラフィックの場合、Vertex AI は使用量ティアシステムを使用します。この動的なアプローチでは、共有プールからリソースが割り当てられ、組織の過去の費用に基づいて使用量ティアとベースラインスループット（TPM）が決まります。このベースラインにより、一般的なワークロードの予測可能なパフォーマンスの下限が決まるものの、アプリケーションは引き続きベストエフォートベースでそれ以上のパフォーマンスを発揮できます。

予測不可能で、Standard Paygo よりも高い信頼性を必要とする、重要なユーザー向けトラフィックをアプリケーションが生成する場合は、Priority Paygo が適しています。リクエストに優先度ヘッダーを追加することで、そのトラフィックを優先すべきであることを示し、スロットリングされる可能性を減らします。

リアルタイムトラフィックの量が常に多いアプリケーションの場合、共有 PayGo プールから分離できる使用量オプションはプロビジョンドスループット（PT）だけであり、PayGo における競合が激しい場合でもエクスペリエンスが安定します。PT では、保証されたスループットを予約して料金を支払うことで、重要なトラフィックがスムーズに流れるようにします。Vertex AI での PT について詳しくは、こちらのガイドをご覧ください。

費用対効果の高いオプション: Vertex AI には、レイテンシの影響を受けにくいトラフィック向けに、費用対効果の高いオプションが用意されています。Flex PayGo は、レイテンシが許容されるトラフィックに適しており、リクエストを低料金で処理します。オフライン分析や一括データ拡充などの大規模な非同期ジョブは、Batch で処理するのが最適です。このサービスは、スケーリングや再試行を含むワークフロー全体をより長い期間（約 24 時間）にわたって管理し、メインのアプリケーションをこの高い負荷から保護します。

複雑なアプリケーションとハイブリッドアプローチ: 複雑なアプリケーションでは、ハイブリッドアプローチがよく利用されます。PT は最も重要なリアルタイムトラフィック、Priority Paygo は変動するトラフィック、Standard Paygo は一般的なリクエスト、Batch / Flex はレイテンシが許容されるオフラインのリクエストフローに使用されます。

Vertex AI で 429 エラーを減らす 5 つの方法

1. スマート再試行の実装

アプリケーションで 429（リソース不足）や 503（サービス利用不可）などの一時的なオーバーロードエラーが発生した場合、すぐに再試行することは推奨されません。ベストプラクティスとして、ジッターを伴う指数バックオフと呼ばれる再試行戦略を実装できます。指数バックオフとは、再試行の間隔が指数関数的に長くなり、通常は事前定義された上限まで長くなることを意味します。これにより、サービスが過負荷状態から回復する時間を確保できます。

SDK とライブラリ: Google Gen AI SDK には、クライアントパラメータの HttpRetryOptions を使用して構成できるネイティブの再試行動作が含まれています。ただし、Tenacity（Python 用）などの専用ライブラリを活用したり、カスタムソリューションを構築したりすることもできます。詳しくは、こちらのブログ投稿をご覧ください。
エージェントワークフロー: エージェントを開発するために、Agent Development Kit（ADK）には Reflect and Retry プラグインが用意されています。このプラグインは、429 エラーを自動的にインターセプトすることで、AI ワークフローに復元力を組み込みます。
インフラストラクチャとゲートウェイ: Apigee によるサーキットブレーキングも、復元力を高めるためのもう一つの堅牢なオプションです。これにより、トラフィックの分散を管理し、正常な障害処理を実装できます。

2. グローバルモデルルーティングの活用

Vertex AI のインフラストラクチャは複数のリージョンに分散されています。デフォルトでは、特定のリージョンエンドポイントをターゲットにした場合、リクエストはそのリージョンから処理されます。これは、その単一リージョンの容量に基づいてアプリケーションの可用性が決まることを意味します。そして、グローバルエンドポイントが、可用性と復元力を高めるための効果的なツールとなります。グローバルエンドポイントは、1 つのリージョンに限定されるのではなく、可用性がより高い可能性のあるリージョンフリート全体にトラフィックをルーティングし、潜在的なエラー率を低減します。

3. コンテキストキャッシュによるペイロードの削減

Vertex AI の負荷を軽減する効果的な方法として、繰り返しクエリの呼び出しを避けることができます。多くの本番環境アプリケーション、特に chatbot やサポートシステムでは、似たような質問が頻繁に寄せられます。それらの質問を再処理する代わりに、コンテキストキャッシュを実装できます。コンテキストキャッシュ保存を使用すると、Gemini は事前に計算されたキャッシュトークンを再利用するため、API トラフィックとスループットを削減できます。これにより、費用を節約できるだけでなく、プロンプト内の繰り返しコンテンツのレイテンシも短縮されます。

4. プロンプトの最適化

各リクエストのトークン数を減らすと、TPM の使用量と費用が直接削減されます。

Flash-Lite による要約: Gemini Pro などのモデルに長い会話履歴を送信する前に、Gemini 2.5 Flash-Lite などの軽量モデルを使用してコンテキストを要約します。
エージェントメモリ最適化: エージェントワークロードでは、Vertex AI Agent Engine Memory Bank を活用できます。メモリーの抽出と統合などの機能により、会話から意味のある事実を抽出できるため、エージェントは未加工のチャット履歴がなくてもコンテキストアウェアな状態を維持できます。
プロンプトの衛生: プロンプトを確認し、詳細すぎる JSON スキーマの説明（モデルがすでに精通している場合）を減らし、過剰な空白や冗長な書式設定を削除します。

5. トラフィックのシェイプ

リクエストの急激なバーストは、429 エラーの主な原因です。平均トラフィックレートが低くても、急激に増加するとリソースに負荷がかかる可能性があります。目標は、トラフィックを平滑化し、長期間にわたってリクエストを分散することです。

使ってみる

ご紹介したパターンを実際に使用される場合は、 GitHub の Vertex AI サンプルを確認するか、Google Cloud 初心者向けガイドの Vertex AI クイックスタートを使用して次のプロジェクトをすぐに開始するか、Agent Development Kit（ADK）で次の AI エージェントの構築を開始してください。

- Google Cloud シニアプロダクトマネージャー、Richard Liu

- Cloud AI テクニカルエバンジェリスト、Pedro Melendez

Ollama、GKE の GPU 共有、vCluster を使って、費用対効果の高い AI を実現する

Tue, 17 Mar 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 3 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。

組織が AI ワークロードをスケールすると、主に 2 つの課題が浮上します。1 つは、使用率の低い GPU に費用がかさむということ、もう 1 つは、複数チームの分離環境を管理運用するのが複雑であるということです。経験則として、GPU 全体を 1 つの Pod に割り当てるのは非効率です。また一方で、チームごとに個別のクラスタを管理すると、運用上の負担が大きくなるという問題があります。

この投稿では、Google Kubernetes Engine（GKE）の GPU タイムシェアリングと、マルチテナンシー用の vCluster を組み合わせて、この両方の問題を解決する方法を紹介します。具体的には、分離した複数の仮想環境に Ollama をデプロイしてオープンモデル（Mistral など）を提供し、これらの環境で 1 つの物理的な GPU インフラストラクチャを共有します。

アーキテクチャ: 共有ハードウェア上の仮想クラスタ

このアーキテクチャでは、GKE Autopilot を活用して物理インフラストラクチャを抽象化しています。ワークロードをデプロイすると、Autopilot が GPU やドライバなどの必要なハードウェアをオンデマンドでプロビジョニングしてくれるため、ノードの管理は不要です。

これにより複数のチームがそれぞれ分離された環境内で、API、Ollama インスタンスや、場合によっては異なるモデルを使用しながら、これらをすべて費用対効果の高い同じ共有 GPU ノードで実行することが可能となります。たとえば、チーム A（法務調査など）とチーム B（カスタマーサポートなど）が、GPU リソースを共有しながら、別々の環境で作業できます。

vCluster では、既存の Kubernetes クラスタ上に仮想 Kubernetes クラスタを作成できます。vCluster はさまざまなテナンシーモードをサポートしています。たとえば、この図に示されている共有ノードモデルでは、各仮想クラスタが独自の分離したコントロールプレーンを取得しながら、基盤となるワーカーノードを共有しています。個々の仮想クラスタには、そのクラスタへのフルアクセスを持つ管理者がアクセスでき、他のチームとの干渉は発生しません。このモデルでは、ホストクラスタ機能も適宜利用できるほか、各仮想クラスタ内に独自のコントローラや CRD をデプロイできます。

vCluster では、次のいずれかのテナンシーモードを使用できます。

共有ノード: このモードでは、複数の仮想クラスタが同じ物理 Kubernetes ノードでワークロードを実行できます。この構成は、リソース使用率の最大化が最優先のシナリオに最適です。特に、社内の開発環境、CI / CD パイプラインや、コスト重視のユースケースに適しています。
プライベートノード: このモードでは、ホストクラスタのワーカーノードを共有せず、個々の vCluster にそれぞれワーカーノードを追加します。これらのプライベートノードはその vCluster のワーカーノードとして機能し、同じホストクラスタ内の他の vCluster には共有されません。
自動ノード: ノードとリソースの要件に基づいて、ワーカーノードを自動的にプロビジョニングして追加するように vCluster を構成します。自動ノードを使用するには、vCluster Platform をインストールし、それに vCluster を接続する必要があります。
スタンドアロン: これは、コントロールプレーンとノードに関してアーキテクチャが異なるモードです。スタンドアロンモードでは、ホストクラスタは不要です。他の Kubernetes ディストリビューションと同様、vCluster はノードに直接デプロイされます。スタンドアロンの vCluster は、ベアメタルノードや VM など、あらゆるタイプのノードで実行できます。コントロールプレーンやワーカーノードの共有ホストクラスタがないため、ワークロードを最も厳格に分離できます。

デプロイ

デプロイ手順に沿って進めるには、次のものがインストールされていることを確認してください。

ステップ 1: GKE Autopilot クラスタを設定して作成する

GKE Standard とは異なり、ノード数を計算したり、ノードプールを手動で構成したりする必要はありません。自動的にクラスタが作成されて、認証情報が取得されます。

環境変数を設定し、GKE Autopilot クラスタを作成します。

export PROJECT_ID=YOUR_PROJECT_ID

export REGION=YOUR_REGION_ID

# GKE Autopilot クラスタを作成する

gcloud container clusters create-auto vcluster-gpu-sharing \

--region=$REGION --project $PROJECT_ID
YOUR_PROJECT_ID と YOUR_REGION_ID は、使用する Google Cloud プロジェクトとリージョンに置き換えます。
ローカルの kubectl を構成するために、認証情報を取得します。

gcloud container clusters get-credentials vcluster-gpu-sharing \

--region $REGION --project $PROJECT_ID

ステップ 2: 仮想クラスタ（vCluster）を作成する

Autopilot クラスタを実行すると、テナントに対して分離環境を作成できるようになります。ここでは、demo1 と demo2 の 2 つの vCluster を作成します。構成には vcluster.yaml マニフェストファイルが必要です。

GKE Autopilot を使用する場合、最初の vCluster の作成には数分かかることがあります。これは、独自のコントロールプレーンの Pod が稼働するのを待機するためです。Autopilot はこの新しいワークロードに対して基盤となるノードを動的にプロビジョニングするため、インフラストラクチャが初期化されるまで少々遅延が発生します。

code_block: <ListValue: [StructValue([('code', '# Create the vcluster configuration file\r\ncat <<EOF > vcluster.yaml\r\n# Place your vCluster configuration here. \r\n# For GPU workloads on GKE Autopilot, this typically involves \r\n# enabling node synchronization so the vCluster can see the \r\n# underlying GPU nodes provided by Autopilot.\r\nsync:\r\n fromHost:\r\n ingressClasses:\r\n enabled: true\r\n nodes:\r\n enabled: true\r\n toHost:\r\n ingresses:\r\n enabled: true\r\nEOF\r\n\r\n# Create the first virtual cluster\r\nvcluster create demo1 -n demo1 -f vcluster.yaml\r\n\r\n# Create the second virtual cluster\r\nvcluster create demo2 -n demo2 -f vcluster.yaml'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48652e2910>)])]>

注: vCluster を別の vCluster 内に作成しようとしているというエラー警告が表示された場合は、[no] を選択して、正しいホストコンテキストに切り替えてください。

ステップ 3: Ollama を仮想クラスタにデプロイする

まず、Ollama のデプロイマニフェストを作成します。このマニフェストによって Ollama をデプロイし、Kubernetes Service を使用してポート 11434 で公開します。

Ollama のデプロイマニフェストを作成します。このマニフェストによって Ollama をデプロイし、Kubernetes Service を使用してポート 11434 で公開します。GPU タイムシェアリングを使用するノードを選択します。

# Ollama のデプロイマニフェストを作成する

cat <<EOF > ollama.yaml

apiVersion: apps/v1

kind: Deployment

metadata:

name: ollama

namespace: default

spec:

replicas: 1

selector:

matchLabels:

app: ollama

template:

metadata:

labels:

app: ollama

spec:

nodeSelector:

# GPU タイムシェアリングを使用するノードを選択する。

# 基盤の GPU を一定数のコンテナで共有することを

# 許可するノードを選択する。

# Nvidia L4 GPU を搭載したノードを選択する。

cloud.google.com/gke-gpu-sharing-strategy: "time-sharing"

cloud.google.com/gke-max-shared-clients-per-gpu: "5"

cloud.google.com/gke-accelerator: nvidia-l4

containers:

- name: ollama

image: ollama/ollama:latest

ports:

- containerPort: 11434

resources:

limits:

nvidia.com/gpu: 1

---

apiVersion: v1

kind: Service

metadata:

name: ollama

namespace: default

spec:

selector:

app: ollama

ports:

- port: 11434

targetPort: 11434

type: ClusterIP

EOF
vCluster がアクティブになったら、コンテキストを切り替えて demo1 内で作業します。

# 仮想クラスタ demo1 に接続する

vcluster connect demo1 -n demo1
仮想環境に Ollama をデプロイします。

# デプロイマニフェストを適用する

kubectl apply -f ollama.yaml
仮想クラスタ内にいても、GPU をリクエストする Pod を作成すると、このリクエストはホストに同期されます。GKE Autopilot はこのリクエストを検出し、ワークロードを実行するノードに必要な GPU ハードウェアを自動的にアタッチします。

ステップ 4: モデルの pull とテスト

サーバーが実行されたら、仮想クラスタのコンテキスト内で、モデルの pull とテストを実行します。

# Pod 内で pull コマンドを実行する

kubectl exec -it <pod-name> -- ollama pull mistral
API を検証します。

# Ollama サービスをポート転送する

kubectl port-forward svc/ollama 8080:11434

# 新しいウィンドウでチャットリクエストを送信する

curl -s http://localhost:8080/api/chat \

-H "Content-Type: application/json" \

-d '{ "model": "mistral", "stream": false, "messages": [ {"role": "user", "content": "Explain GKE Autopilot"} ] }' | jq -r '.message.content'

ステップ 5: Ollama を vCluster demo2 にデプロイする

同じ手順を繰り返して、Ollama をデプロイし、モデルを 2 つ目の仮想クラスタに pull します。

code_block: <ListValue: [StructValue([('code', '# 仮想クラスタに接続する\r\nvcluster connect demo2 -n demo2\r\n\u200b\r\n# デプロイマニフェストを適用する\r\nkubectl apply -f ollama.yaml\r\n\u200b\r\n# Pod 内で pull コマンドを実行する\r\nkubectl exec -it <pod-name> -- ollama pull mistral\r\n\u200b\r\n# Ollama サービスをポート転送する\r\nkubectl port-forward svc/ollama 8080:11434\r\n\u200b\r\n# 新しいウィンドウでチャットリクエストを送信する\r\ncurl -s http://localhost:8080/api/chat \\\r\n-H "Content-Type: application/json" \\\r\n-d \'{ "model": "mistral", "stream": false, "messages": [ {"role": "user", "content": "Explain GKE Autopilot"} ] }\' | jq -r \'.message.content\''), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48652e2610>)])]>

基盤となるインフラストラクチャを検証する

それでは、ホストクラスタのコンテキストに戻って、何が起こっているかを確認しましょう。

プロビジョニングされたノードの数と、Ollama Pod が実行されている場所を確認します。

# 利用可能なコンテキストを一覧表示する

kubectx

# ホストクラスタのコンテキストに切り替える

kubectx gke_$PROJECT_ID_$REGION_vcluster-gpu-sharing

# ノードを一覧表示する

Kubectl nodes
2 つのノードが表示されるはずです。1 つは vCluster コンポーネントを実行しています。もう 1 つは、L4 GPU を使用して Ollama インスタンスを実行しています。出力は次のようになります（ノード名は異なります）。

# kubectl get nodes の出力

$ kubectl get nodes

NAME STATUS ROLES AGE VERSION

gk3-vcluster-gpu-sharing-nap-1w88cyly-895203e4-xbqk Ready <none> 7h8m v1.33.5-gke.2072000

gk3-vcluster-gpu-sharing-pool-2-0a984fed-7mff Ready <none> 4d v1.33.5-gke.2072000
Ollama Pod が実行されている場所を確認します。

# Ollama Pod を実行しているノードを確認する

kubectl get pods -n demo1 -o wide

kubectl get pods -n demo2 -o wide
両方の Ollama Pod が同じノードで実行されていることに注目してください。このノードは GKE Autopilot によってプロビジョニングされ、L4 GPU と GPU 共有を使用するように構成されています。

まとめ

この例では、GKE Autopilot を使用することで、GPU ノードプールやタイムシェアリングを手動で構成せずに済んでいます。Autopilot によってリソースが動的に提供される一方で、vCluster によって、チーム A の法務調査データとチーム B のカスタマーサポートの bot が完全に分離されています。この実装方法により、AI ワークロードのスケーリングにおいて堅牢でメンテナンスの少ないプラットフォームを実現できます。

- シニアクラウドデベロッパーアドボケイト、Abdel Sghiouar

- vCluster デベロッパーリレーションズ、 Saiyam Pathak

プロダクションレディな AI エージェントに関するデベロッパーガイド

Tue, 17 Mar 2026 00:00:00 +0000

※この投稿は米国時間 2026 年 2 月 26 日に、Google Cloud blog に投稿されたものの抄訳です。

この 1 年間で、デベロッパーコミュニティに変化が生じました。AI エージェントは、「興味深い研究コンセプト」から「チームが実際に構築しているもの」へと進化したのです。プロトタイプは機能しています。デモが示す可能性には目を見張るものがあります。ところが、ここで難題が持ち上がります。AI エージェントをどのようにリリースすればよいのでしょうか？

この問いは多面的です。エージェントは従来のソフトウェアのようには動作しません。推論し、行動し、適応するという性質から、エージェントにはテスト、メモリ、オーケストレーション、セキュリティに対して異なるアプローチが求められます。決定的なコードで有効だったパターンをそのまま適用することはできません。

開発者がこれらの課題を解決できるよう、Google はエージェントのライフサイクル全体を網羅したガイド集を公開しました。これらのリソースは、Kaggle の 5 日間 AI エージェント集中講座で初めて公開されました。そこで非常に高い人気と有用性が確認されたことから、より多くのユーザーに向けて公開する運びとなりました。

これらのガイドでは、実用的なフレームワークとコードサンプルが提供されており、自身のプロジェクトに合わせて柔軟に適用できます。以下では、エージェントのアーキテクチャから本番環境へのデプロイまで、主要なコンセプトを順を追って説明します。それに基づき、どのテーマについてより深掘りすべきかを判断してください。

エージェントとは

エージェントの中核をなすものは、推論、行動、経時的な改善を行う自律的なエンティティです。エージェントの頭脳は大規模言語モデルです。これは、タスクを理解し、回答を生成し、コンテキストに基づいて意思決定を行う認知エンジンです。エージェントは静的なツールとは異なり、動作する中で適応します。思考、行動、観察という再帰的なループに基づいて機能します。各サイクルでエージェントは進歩し、その過程でアプローチを洗練させます。

この中核の周囲にあるのがオーケストレーションレイヤであり、これは通信とデータフローを管理する神経系の役割を果たします。専門的なツールや外部サービスを調整する指揮者のようなものです。これには、即座に思い出すための短期記憶（セッションの状態）、過去のインタラクションを保持するための長期記憶（メモリサービス）、情報検索（RAG）、外部の世界でアクションを実行するためのモジュール（ツールの使用）などが含まれます。セキュリティフレームワークにより、エージェントが安全に、意図された境界内で動作することが保証されます。このアーキテクチャの目的は、インテリジェントで有用かつ信頼できるアシスタントを作成することです。

これらの基本コンセプトの詳細については、エージェントの概要に関するガイドをご覧ください。

ツールと相互運用性

エージェントが真に有用であるためには、ツール、データソース、他のエージェントとやり取りできる必要があります。2 つの新しいプロトコルが、そうした接続に対する標準化されたアプローチを提供します。

Anthropic の Model Context Protocol（MCP）により、エージェントは外部のデータソースやステートレスツールに標準化された方法で接続できます。デベロッパーは、サービスごとにカスタム統合を構築する代わりに、MCP の標準化されたインターフェースを使用して開発を簡素化し、相互運用性を向上させることができます。

Google の Agent2Agent プロトコル（A2A）はさらに一歩踏み込み、基盤となるフレームワークにかかわらずエージェント間の直接通信を可能にします。A2A を使用するエージェントは、安全かつ構造化されたメッセージの交換を通じて、互いの能力を把握し、やり取りの方法を交渉し、連携してタスクを処理します。

これらのプロトコルを組み合わせることで、ツール、データ、他のエージェントとの接続を通じてより広範なエコシステム内で動作するエージェントの基盤が構築されます。ツールと MCP による相互運用性に関するガイドでは、実装例とともにこれら 2 つのプロトコルについて詳しく説明しています。

コンテキストエンジニアリング

LLM がエージェントの脳であるとすれば、コンテキストエンジニアリングは、適切な情報を適切なタイミングで LLM に提供する手法です。これには、プロンプト設計、検索メカニズム、ツールの選択、会話履歴など、エージェントが各リクエストを理解して応答する方法を形作るすべてのものが含まれます。

コンテキストエンジニアリングにより、汎用モデルがパーソナライズされたアシスタントに変わります。コンテキストエンジニアリングは、どのメモリを取得するか、どのツールを提供するか、各インタラクションをどのように構成するかを決定します。効果的なコンテキストエンジニアリングにより、複数のセッションをまたいで一貫性を保持する有用なエージェントが作成されます。コンテキストエンジニアリングが実装されない場合、エージェントは記憶を忘却したり、同じことを繰り返したり、的外れな回答を返したりすることになります。

コンテキストエンジニアリングガイドでは、コンテキストエンジニアリングのフレームワークと実装のための実用的な手法について説明しています。

テストと評価

自律エージェントには、品質保証に対する新しいアプローチが必要です。エージェントが独自の判断を下す場合、その成否は正しい出力を生成できるかという点だけでなく、プロセス全体にわたって正しい判断ができているかという点にもかかっています。

エージェントを評価するにあたっては、最終的な回答の正しさだけでなく、エージェントが結果に至るまでに行う一連の意思決定と行動の軌跡に重点が置かれます。2 つのエージェントがまったく異なる経路で同じ結論に達する可能性があり、その経路を理解することが重要です。優れた評価では、ツールの選択、推論の質、エラー回復、エージェントが明確化のための質問をすべきときに質問したかどうかを調べます。

実用的な評価アプローチには、個々のコンポーネントの単体テスト、複数ステップの意思決定シーケンスの軌跡分析、サンドボックスからカナリア、本番環境への段階的な公開が含まれます。各ステージでは、より多くのユーザーに公開する前に、エージェントの動作のさまざまな側面を検証します。

評価フレームワークとテスト方法の詳細については、エージェントの品質ガイドをご覧ください。

エージェントの本番環境へのデプロイ

プロトタイプから本番環境に移行するには、エージェント固有のニーズに合わせて設計されたインフラストラクチャが必要です。状態を維持し、ツールを動的に使用し、自律的に動作するシステムを実現するには、従来型のデプロイパターンに適応性を持たせることが求められます。

本番環境のエージェントには、インタラクション全体でコンテキストを維持するためのセッション管理、長期記憶のための永続的なメモリシステム、適切な認証と権限によるツール統合、エージェントの意思決定とアクションを追跡するためのリアルタイムのロギングが必要です。

ほとんどのチームは、内部テスト用のサンドボックス、限定的な実環境でのテスト用のカナリア、完全なロールアウト用の本番環境という段階でデプロイします。各ステージでパフォーマンスを検証し、アクセスを拡大する前に問題を検出します。

プロトタイプから本番環境へのガイドでは、プロダクションレディなエージェントインフラストラクチャを構築するためのアーキテクチャに関するガイダンスとコードサンプルを提供しています。

出発点

どこから始めるべきかは、お客様の取り組みの段階によって異なります。エージェントの概要ガイドでは基本的なコンセプトを説明し、ツールと MCP による相互運用性やコンテキストエンジニアリングのガイドでは構築の実践的な課題を取り上げます。検証とリリースを行う準備ができた段階では、エージェントの品質とプロトタイプから本番環境へのガイドが役立ちます。

エージェントの分野は急速に進化していますが、一人で解決する必要はありません。現在の課題に合ったリソースを選んで、構築を始めましょう。

- テクニカルソリューションマネージャー、Kanchana Patlolla

- Google、シニアスタッフ ML エンジニア兼生成 AI 集中講座創設者、Anant Nawalgaria

RAG 対応生成 AI アプリケーションのプライベートネットワーク接続の設計

Fri, 13 Mar 2026 03:00:00 +0000

※この投稿は米国時間 2026 年 3 月 3 日に、Google Cloud blog に投稿されたものの抄訳です。

Google Cloud は柔軟性に優れており、企業が AI ワークロード向けに安全で信頼性の高いアーキテクチャを構築することを可能にします。この投稿では、検索拡張生成（RAG）対応生成 AI アプリケーションのプライベート接続のリファレンスアーキテクチャについて説明します。このアーキテクチャは、システム全体で通信にプライベート IP アドレスを使用する必要があるようなシナリオで、通信がインターネットを通過してはならないような場合に適しています。

RAG の効力

RAG は、大規模言語モデル（LLM）の出力を最適化するために使用されるパワフルな手法であり、LLM の出力を、元のトレーニングデータ以外の特定の信頼できるナレッジベースにグラウンディングできます。アプリケーションから RAG を使って、ドキュメント、データソース、データベースから関連情報をリアルタイムで取得することができます。ここで取得したコンテキストは、ユーザーのクエリとともにモデルに提供されます。これにより、AI の回答を正確で検証可能なものにするとともに、業務内容との関連性を高めます。この仕組みによって、回答の質が向上し、ハルシネーションが減少します。

このアプローチは、生成 AI においてモデルの既存の知識のみに依存することなく、指定された信頼できる情報源を使用できるため、モデル自体を再トレーニングやファインチューニングしなくて済むという点で利便性に優れています。

設計パターンの例

RAG アプリケーションのプライベート接続向けにネットワークを設定するということを念頭におきながら、このようなリージョン設計のパターンを見ていきましょう。

このネットワークは、外部ネットワーク（オンプレミスおよび他のクラウド）と Google Cloud 環境で構成されています。Google Cloud 環境は、ルーティングプロジェクト、RAG 用の共有 VPC ホストプロジェクト、3 つの特化したサービスプロジェクト（データ取り込み、サービング、フロントエンド）で構成されています。

この設計では、次のサービスを使用してエンドツーエンドのソリューションを提供します。

Cloud Interconnect または Cloud VPN: オンプレミスまたは他のクラウドからルーティング VPC ネットワークに安全に接続する
Network Connectivity Center: VPC スポークおよびハイブリッドスポークを介して、ルーティング VPC ネットワークと RAG VPC ネットワーク間の接続を管理するオーケストレーションフレームワーク
Cloud Router: ルーティングプロジェクト内で、外部ネットワークと Google Cloud 間の動的な BGP ルート交換を行う
Private Service Connect: ルーティング VPC ネットワークにプライベートエンドポイントを提供し、パブリックインターネットを経由せずに Cloud Storage バケットにアクセスしてデータを取り込めるようにする
共有 VPC: 複数のサービスプロジェクトで、共通の一元的な VPC ネットワークを使用できるようにするホストプロジェクトアーキテクチャ
Google Cloud Armor とアプリケーション ロードバランサ: フロントエンドサービスプロジェクトに配置され、ユーザーインタラクションに対してセキュリティとトラフィック管理を提供する
VPC Service Controls: すべてのリソースの周囲にマネージドセキュリティ境界を作成し、データ漏洩のリスクを軽減する

トラフィックフロー

RAG の挿入フロー

上の図の緑色の点線が RAG の挿入フロー（データエンジニアからベクトルストレージへとデータが移動する仕組み）を表しています。

外部ネットワークからのデータが、Cloud Interconnect または Cloud VPN 経由で渡されます。
ルーティングプロジェクト内の Private Service Connect エンドポイントを使って Cloud Storage バケットにアクセスします。
データ取り込みサービスプロジェクト内のデータ取り込みサブシステムが Cloud Storage バケットからの元データを処理します。
AI モデルがチャンクからベクトルを作成し、データ取り込みサブシステムに返します。データ取り込みサブシステムはこれを受け、サービングサービスプロジェクトの RAG データストアに書き込みます。

推論フロー

上の図のオレンジ色の点線が推論フロー（お客様またはユーザーのリクエスト）を表しています。

リクエストは、Cloud Interconnect または Cloud VPN 経由でルーティング VPC ネットワークに渡され、その後、VPC スポーク経由で RAG VPC ネットワークに渡されます。
リクエストは、Cloud Armor で保護されたアプリケーションロードバランサ に到達し、許可されるとフロントエンドサブシステムに渡されます。
フロントエンドサブシステムはリクエストをサービングサブシステムに転送します。サービングサブシステムは、RAG データストアのデータでプロンプトを拡張し、AI モデルを介して回答を生成します。
上記によってグラウンディングされた回答が、リクエスト元に同じパスで返されます。

管理とルーティング

上の図の青い点線は、Network Connectivity Center のハイブリッドスポークと VPC スポークが、ルーティングネットワークと RAG VPC ネットワーク間のコントロールプレーンとルートオーケストレーションを管理する様子を表しています。これにより、外部ネットワークから学習したルートが環境全体に適切に伝播されます。

IAM 権限、VPC Service Controls、デプロイに関する考慮事項などについて詳しくは、アーキテクチャドキュメント「RAG 対応生成 AI アプリケーションのプライベート接続」をお読みください。

次のステップ

クロスクラウドネットワークの詳細や、RAG を使用した生成 AI に関する以下のガイドをご覧ください。

ご質問やご意見がございましたら、Linkedin 経由で筆者までご連絡ください。

- デベロッパーリレーションズエンジニア、Ammett Williams

エージェント型 chatbot に高速で信頼性の高い長期メモリを提供

Thu, 12 Mar 2026 00:00:00 +0000

※この投稿は米国時間 2026 年 2 月 28 日に、Google Cloud blog に投稿されたものの抄訳です。

会話エージェントを大規模展開する際は、データレイヤの設計が成否を左右することが少なくありません。数百万人規模のユーザーを支えるには、会話の継続性が欠かせません。つまり、応答性の高いチャットを維持しつつ、バックエンドのモデルが必要とするコンテキストも保ち続ける能力です。

この記事では、Google Cloud のソリューションを用いて、AI の 2 つのデータ課題（リアルタイムチャットのコンテキスト更新を高速化すること、長期履歴の検索を効率化すること）をどう解決するかをご紹介します。また、Redis、Bigtable、BigQuery を組み合わせるポリグロットなアプローチにより、直近のやり取りから数か月前のアーカイブまで、エージェントが細部と文脈の連続性を保てるようにする方法も解説します。

短期、中期、長期の履歴に対応するポリグロットストレージアプローチ

ポリグロットアプローチとは

ポリグロットアプローチとは、単一のデータベースに集約するのではなく、用途に特化した複数のデータサービスを組み合わせ、データのライフサイクルに応じて使い分ける多層型のストレージ戦略です。これにより、たとえば、高速化のためのインメモリキャッシュ、大規模データを扱うための NoSQL、非構造データを置くための Blob ストレージ、分析のためのデータウェアハウスといったように、それぞれの強みを活かしながら、データの「鮮度」や量に応じて効率的に処理できます。

短期、中期、長期メモリに対する Google Cloud での定義例

会話の継続性を保つため、Google Cloud 上では次のように組み合わせて、このポリグロットアプローチを実装できます。すなわち、ミリ秒未満で「ホット」なコンテキストを取得する用途には Memorystore for Redis を、永続的な履歴を蓄積するペタバイト規模の記録基盤には Cloud Bigtable を、長期アーカイブや分析的な洞察には BigQuery を用います。また、画像や音声などの非構造マルチメディアは Cloud Storage で扱い、Pub/Sub と Dataflow による非同期パイプラインで連携させます。

1. 短期メモリ: Memorystore for Redis

ユーザーは、新しいチャットを開始する場合でも、以前の会話を続ける場合でも、チャット履歴が瞬時に読み込まれることを期待しています。会話のコンテキストについては、Memorystore for Redis が主要なキャッシュとして機能します。フルマネージドのインメモリデータストアである Redis は、自然な会話の流れを維持するために必要なサブミリ秒レベルの低レイテンシを提供します。チャットセッションはメッセージが順次追加されていくリスト構造のため、履歴は Redis リストを使って保存します。ネイティブの RPUSH コマンドを使えば、アプリケーションは最新のメッセージだけを追加すればよく、Memcached のような単純なストアで発生しがちな「読み取り → 更新 → 書き込み」というネットワーク負荷の大きい処理を避けることができます。

2. 中期メモリ: Cloud Bigtable

会話が時間とともに増えていくにつれ、エージェント型アプリケーションは、増え続けるチャット履歴をより大規模に、かつ長期的に保存できる設計を考える必要があります。そこで、Bigtable が、永続性を備えた中期ストアとして、また全チャット履歴の正式な記録として機能します。Bigtable は、高速で書き込みが集中するワークロード向けに設計されたペタバイト級の NoSQL データベースで、数百万件の同時チャットを取り込む用途に適しています。大量のデータを扱いつつも、ガベージコレクションポリシーを設定すれば、アクティブなクラスタを必要最小限に保てます。たとえば、高性能ティアには直近 60 日分だけ残すといった運用が可能です。検索を高速化するため、キーは user_id#session_id#reverse_timestamp というパターンで設計します。これにより、同一セッションのメッセージが近接して格納され、範囲スキャンで直近のメッセージを効率よく取り出せるため、履歴の再読み込みがスムーズになります。

3. 長期メモリと分析: BigQuery

アーカイブと分析のため、データは BigQuery に移されます。BigQuery は、このシステムにおける長期メモリの役割を担います。Bigtable が稼働中のアプリケーション向け処理に最適化されているのに対し、BigQuery は大規模な複雑 SQL クエリを実行するために設計された Google のサーバーレス型データウェアハウスです。これにより、チームは単なるログ保存にとどまらず、そこから分析的なインサイトを引き出せるようになります。最終的には、この運用データがフィードバックループとして機能し、ユーザー向けコンポーネントのパフォーマンスに影響を与えることなく、エージェントやユーザー体験の改善につながります。

4. アーティファクトストレージ: Cloud Storage（GCS）

ユーザーが分析のためにアップロードしたものでも、生成モデルが生成したものでも、画像や音声などの非構造データ（マルチメディアファイル）は、非構造アーティファクトの保管に適した Cloud Storage に格納します。ここではポインタ戦略を採用します。Redis や Bigtable のレコード側には、実体データそのものではなく、オブジェクトを指し示す URI（例: gs://bucket/file）を保持します。セキュリティ面では、アプリケーションが署名付き URL を使ってファイルを配信し、バケットを公開することなく、クライアントに期限付きのアクセス権だけを付与します。

データの流れを最適化するハイブリッド同期 / 非同期戦略

以下のシーケンス図で示すとおり、このハイブリッド同期 / 非同期戦略では、前述のストレージ群を組み合わせることで、高速で整合性のある処理と耐久性のある永続化を両立させます。

次の図は、ユーザーのメッセージと、それに対応するエージェントの応答が、アーキテクチャ内をどのように流れていくかを示しています。

次の図は、ユーザーが特定のセッションのチャット履歴を取得する際に、データがアーキテクチャ全体をどのように流れるかを示しています。

今すぐ構築を開始

堅牢な永続化レイヤを備えたエージェントを構築する準備はできていますか？

エージェントをすばやく構築: Vertex AI Agent Builder を使って、エージェント型ワークフローのプロトタイピングを始めましょう。
キャッシュを構成する: レイテンシと可用性の要件に合わせて、最適な Memorystore for Redis の構成を決定します。
堅牢な Bigtable スキーマを設計する: スキーマ設計のベストプラクティスを確認しましょう。
分析へつなぐ: Bigtable の Change Stream から BigQuery へのテンプレートを活用し、ライブチャットログを実用的なビジネスインサイトへと変換します。
分析でデータを活用する: Looker Conversational Analytics を使って、ビジネスインテリジェンスに基づいたプロダクトの意思決定を行いましょう。

- AI ソリューションアクセラレーションアーキテクト Aishwarya Prabhat

- プリンシパルアーキテクト Yun Pang

Java SDK「MCP ツールボックス」リリースのお知らせ

Tue, 10 Mar 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 3 月 4 日に、Google Cloud blog に投稿されたものの抄訳です。

エンジニアリングチームは、単純な chatbot から、ミッションクリティカルなデータベースと直接やり取りするエージェントシステムの構築へと移行しています。しかし、このようなエンタープライズエージェントを構築する際には、カスタムのグルーコード、脆弱な API、複雑なデータベースロジックという統合の壁にぶつかることがよくあります。

これらのハードコードされたボトルネックをセキュアで統合されたコントロールプレーンに置き換えるために、このたび、「データベース向け Model Context Protocol（MCP）ツールボックス」Java SDK をリリースしました。このリリースにより、世界で最も広く採用されているエンタープライズエコシステムで、最高水準の型安全なエージェントオーケストレーションが実現します。Java の成熟したアーキテクチャは、このような厳しい要求に対応できるよう構築されており、本番環境でミッションクリティカルな AI エージェントを安全にスケールするために必要な高い同時実行性、厳格なトランザクションの整合性、堅牢な状態管理を提供します。

MCP: AI エージェント向けの USB Type-C

Model Context Protocol（MCP）は、AI のユニバーサルトランスレータのようなものです。

MCP は、AI モデルが外部のツールやデータセットに接続する方法を標準化するために作成されており、カスタムの断片的な統合スクリプトをセキュアなユニバーサルプロトコルに置き換えます。エージェントがトランザクション SQL クエリの実行、数千ものポリシードキュメントの検索、REST API のトリガーなどを行うときに、MCP が単一の統合インターフェースを提供します。

データベース向け MCP ツールボックスを使用すると、このプロトコルの実装が簡単になります。

データベース向け MCP ツールボックス

データベース向け MCP ツールボックスは、データベース用のオープンソース MCP サーバーです。AlloyDB、Cloud SQL、Cloud Spanner をはじめ、サードパーティを含む 42 種類のデータソースをネイティブにサポートしています。重要なのは、AI エージェントの自然言語の意図を特定のデータベース操作に直接、安全にマッピングするカスタムツールを定義できることです。これにより、接続プーリングや認証などの複雑な処理に対応して、ツールの開発をより簡単、迅速、セキュアに行うことができます。

Python、JavaScript、TypeScript、Go 向けの堅牢かつプロダクションレディな SDK はすでに提供していました。しかし、高い同時実行性、トランザクションの整合性、会話の状態管理が不可欠な Day 2（2 日目からの）本番環境ワークロードに関しては、Java と Spring Boot が依然として圧倒的な存在です。

この新しい Java SDK を使用すると、好みの技術スタックから離れることなく、ステートフルで同時実行性の高いマルチエージェントシステムをネイティブに構築できます。この SDK は、場合によってはエンタープライズアーキテクトにとって最優先事項となる、最高水準の型安全なオーケストレーションを Java にもたらします。

この Java SDK を使ってみる

「MCP ツールボックス」Java SDK は、企業チームがスムーズに利用できるように設計されています。今すぐエージェントの構築を開始できます。

依存関係の追加

MCP ツールボックスは、pom.xml に次の依存関係を追加するだけで、Java または Spring Boot のプロジェクトに組み込むことができます。

code_block: <ListValue: [StructValue([('code', '<dependency>\r\n <groupId>com.google.cloud.mcp</groupId>\r\n <artifactId>mcp-toolbox-sdk-java</artifactId>\r\n <version>0.2.0</version>\r\n</dependency>'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48643d73d0>)])]>

これで準備は完了です。以下のエンタープライズグレードのユースケース例でも同じ操作を行っています。

実際の例: 自律型の交通機関コンシェルジュ

「MCP ツールボックス」Java SDK を AlloyDB と組み合わせて活用する例として、交通機関のユースケースを見てみましょう。

Cymbal Transit は架空の都市間バス交通ネットワークです。利用者は、旅行を計画するのに、15 個ものプルダウンメニューをクリックしたくはありません。次のように質問できれば理想的です。

「明日の朝、ニューヨークからボストンまで移動する必要があります。ゴールデンレトリバーを連れて行くことはできますか？できる場合は、最も早い便を予約して。」

AI エージェントがこの質問に答えるには、非構造化データ（ペットに関するポリシー）と構造化データ（運行スケジュール、座席の空き状況）をシームレスに相互参照し、会話のコンテキストを記憶しながらトランザクション（予約）を実行する必要があります。

このケースは、「MCP ツールボックス」Java SDK を使用して次のように構築します。

基盤となるデータベース（ネイティブエンベディングを備えた AlloyDB スキーマ）

AlloyDB は、リレーショナルデータと高次元の AI ベクトルを単一のクエリエンジンで処理するため、この目的に最適なエンジンです。AlloyDB はさらに、google_ml_integration 拡張機能を使用してエンベディングをネイティブに生成できるため、構築する Java アプリケーションとエンベディング API との間でテキストをやり取りする必要がありません。

まず、こちらのクイック設定ラボに沿って、AlloyDB のクラスタとインスタンスを設定します。

次に、以下の SQL ステートメントを使用してデータベースオブジェクトを設定します。

code_block: <ListValue: [StructValue([('code', "-- AI セマンティック検索とエンベディング生成に必要な拡張機能を有効にする\r\nCREATE EXTENSION IF NOT EXISTS vector;\r\nCREATE EXTENSION IF NOT EXISTS google_ml_integration;\r\n\u200b\r\n-- 表 1: 交通機関のポリシー（RAG 用の非構造化データ）\r\nCREATE TABLE transit_policies (\r\n policy_id SERIAL PRIMARY KEY,\r\n category VARCHAR(50),\r\n policy_text TEXT,\r\n policy_embedding vector(768)\r\n);\r\n\u200b\r\n-- 表 2: 都市間バスの運行スケジュール（構造化データ）\r\nCREATE TABLE bus_schedules (\r\n trip_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),\r\n origin_city VARCHAR(100),\r\n destination_city VARCHAR(100),\r\n departure_time TIMESTAMP,\r\n arrival_time TIMESTAMP,\r\n available_seats INT DEFAULT 50,\r\n ticket_price DECIMAL(6,2)\r\n);\r\n\u200b\r\n-- 表 3: 予約台帳（トランザクションアクションデータ）\r\nCREATE TABLE bookings (\r\n booking_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),\r\n trip_id UUID REFERENCES bus_schedules(trip_id),\r\n passenger_id VARCHAR(100),\r\n status VARCHAR(20) DEFAULT 'CONFIRMED',\r\n booking_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48643d7bb0>)])]>

テーブルを定義し、ベクトルサポートを有効にしたことで、AlloyDB が構造化されたトランザクションデータとセマンティックナレッジベースの両方に対応する統合ブレインとして機能する準備が整いました。

レコードの取り込みと現実的なエンベディングの生成

エージェントのコンテキストウィンドウで推論に使用できる現実的なオプションを確保するには、堅牢なデータセットが必要です。AlloyDB で PostgreSQL の強力な generate_series を使用すると、翌日以降の現実的なバス旅行のデータ 200 件以上を即座にデータベースに供給できます。このデモアプリケーションのモックデータの取り込みには、このアプローチを採用しました。

code_block: <ListValue: [StructValue([('code', '-- 1. AlloyDB で非構造化ポリシーを挿入し、現実的なエンベディングをネイティブに生成する\r\nINSERT INTO transit_policies (category, policy_text, policy_embedding)\r\n...（完全なステートメントはリポジトリを参照）\r\n\u200b\r\n-- 2. generate_series を使用して、今後 7 日間の現実的なスケジュールを 200 件以上生成する\r\nINSERT INTO bus_schedules (origin_city, destination_city, departure_time, arrival_time, ticket_price, available_seats)\r\n...（完全なステートメントはリポジトリを参照）'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48643d7760>)])]>

完全なコードについては、リポジトリをご覧ください。

このようにして、現実的なスケジュールとネイティブに生成されたエンベディングがデータベースに動的に入力され、AI エージェントはデータが豊富でクエリ可能な環境に即座にアクセスできるようになります。

Spring Boot のステートフルエージェントアーキテクチャ

会話型 UI の構築で最も難しいのはセッション管理です。ユーザーが「空いている時間は？」と尋ねた後、「午前 8 時の便を予約して」と言った場合、エージェントはコンテキストを覚えている必要があります。

「MCP ツールボックス」Java SDK を Spring Boot、LangChain4j と併せて使用すると、HTTP セッションで会話の記憶をシームレスに維持し、エージェントの思考プロセスに注入できます。最新のフロントエンドと、このステートフルバックエンドを組み合わせることで、エンタープライズアプリケーションは連続的でインテリジェントなワークスペースになります。

ユーザーの意図を解析するために大量の if / else ブロックを記述する代わりに、宣言型の AI インターフェースを定義し、それに MCP ツールをバインドするだけです。詳細なクエリをハードコードしたり、静的な条件コードのブロックを追加したりすることなく、オーケストレーションのロジックをコードに組み込むことがいかに簡単かを示します。

code_block: <ListValue: [StructValue([('code', 'interface TransitAgent {\r\n @SystemMessage({\r\n "You are the Cymbal Transit Concierge.",\r\n "Use the \'querySchedules\' tool for finding schedules.",\r\n "Use \'bookTicket\' to execute transactions.",\r\n "Use \'searchPolicies\' to look up luggage and pet rules."\r\n })\r\n String chat(@MemoryId String sessionId, @UserMessage String userMessage);\r\n}\r\n\u200b\r\n@Service\r\nclass TransitAgentTools {\r\n // これらのメソッドは、データベース向け MCP ツールボックスサーバーを自動的に呼び出します。\r\n @Tool("Query specific schedules between an origin and destination city.")\r\n public String querySchedules(String origin, String destination) { ... }\r\n\u200b\r\n @Tool("Book a ticket for a passenger.")\r\n public String bookTicket(String tripId, String passengerName) { ... }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48643d7a60>)])]>

LangChain4j により、LLM プロンプトのロジックが実際のツールの実行から明確に分離されるため、エージェントは目標を失うことなく、予測可能で、時間が経過しても非常に簡単にメンテナンスできる状態が維持されます。最新のフロントエンドと、このステートフルな Spring Boot バックエンドを組み合わせることで、エンタープライズアプリケーションは、つながりのない一連のプロンプトではなく、連続的でインテリジェントなワークスペースになります。

意図と SQL のマッピング: tools.yaml

データベース向け MCP ツールボックスの真の魅力は、これらのカスタムツールの定義方法にあります。Java アプリケーションは SQL に直接アクセスする必要がなく、LLM はテーブルスキーマに関してハルシネーションを起こす必要がありません。代わりに、MCP サーバーにクリーンな tools.yaml 構成を提供します。このファイルは、エージェントのツール呼び出しを AlloyDB のパラメータ化された SQL ステートメントにセキュアにマッピングします。

code_block: <ListValue: [StructValue([('code', 'tools:\r\n query-schedules:\r\n kind: postgres-sql\r\n source: alloydb\r\n description: Find available bus schedules between cities.\r\n parameters:\r\n - name: origin\r\n type: string\r\n - name: destination\r\n type: string\r\n statement: |\r\n SELECT CAST(trip_id AS TEXT) AS trip_id, departure_time, ticket_price\r\n FROM bus_schedules\r\n WHERE lower(origin_city) = lower($1) AND lower(destination_city) = lower($2)\r\n\u200b\r\n search-policies:\r\n ... 完全な tools.yaml については、リポジトリを参照してください'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48643d7280>)])]>

このシンプルな宣言型構成により、データベーススキーマを LLM に直接公開することなく、自然言語の意図と複雑な SQL クエリのギャップを埋めることができます。

点と点をつなぐ: Java でのツールのリスト表示、呼び出し、実行

データベースとツールを構成したら、それらとのやり取りという手間のかかる作業は、「MCP ツールボックス」Java SDK が処理します。この SDK は、直感的で型安全な API を提供し、Spring Boot サービスからトランザクションをセキュアに検出、クエリ、実行できます。

code_block: <ListValue: [StructValue([('code', '// 1. クライアントの初期化\r\nMcpToolboxClient mcpClient = McpToolboxClient.builder()\r\n .baseUrl("https://toolbox-my-project-uc.a.run.app")\r\n .apiKey(myIdToken)\r\n .build();\r\n\u200b\r\n// 2. 検出可能なツールのリスト表示\r\nmcpClient.listTools().thenAccept(tools -> {\r\n System.out.println("Successfully discovered " + tools.size() + " tools.");\r\n});\r\n\u200b\r\n// 3. ツールの呼び出し（読み取り専用データ）\r\nString schedules = mcpClient.invokeTool("query-schedules", Map.of(\r\n "origin", "New York",\r\n "destination", "Boston"\r\n)).join().content().get(0).text();\r\n\u200b\r\n// 4. トランザクションツールの実行（バインドされた認証が必要）\r\nAuthTokenGetter toolAuthGetter = () -> CompletableFuture.completedFuture(myIdToken);\r\n\u200b\r\nString bookingConfirmation = mcpClient.loadTool("book-ticket", Map.of("google_auth", toolAuthGetter))\r\n .thenCompose(tool -> {\r\n // 認証されたユーザーコンテキストをセキュアにバインドする\r\n tool.bindParam("passenger_name", "Jane Doe");\r\n // 可変トランザクションを実行する\r\n return tool.execute(Map.of("trip_id", "123e4567-e89b-12d3-a456-426614174000"));\r\n }).join().content().get(0).text()'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48643d7550>)])]>

これで完了です。型安全な Java のコード数行で、Spring Boot アプリケーションがローカルメソッドかのようにリモートツールをセキュアに検出して実行します。上の bindParam メソッドに注目してください。この強力な機能を使用すると、アプリケーションレベルのコンテキスト（認証されたユーザーの ID など）をデータベーストランザクションにセキュアに直接挿入し、LLM を完全にバイパスできます。詳しくは、「MCP ツールボックス」Java SDK のドキュメントをご覧ください。

アプリケーションのデフォルト認証情報（ADC）によるゼロ構成のセキュリティ

ハードコードされたシークレットや JSON キーの管理が不要であることに注目してください。Java アプリケーションは、Google のアプリケーションのデフォルト認証情報（ADC）を使用して、バックグラウンドで myIdToken を取得することで、環境から直接、セキュアな ID を自動的に継承します。gcloud CLI を使用してローカルで開発する場合でも、本番環境で実行する場合でも、アプリケーションはデフォルトでセキュアに保たれ、手動で認証情報を構成する必要がありません。

フリートを Cloud Run にデプロイ

先ほど説明した「2 日目」のエンタープライズ要件を覚えているでしょうか。高い同時実行性、トランザクションの整合性を適切に処理し、ステートフルな会話を大規模に維持するには、アーキテクチャが堅牢である必要があります。データベース向け MCP ツールボックスと Spring Boot エージェントは完全に分離されているため、Google Cloud Run で個別にスケーリングして、これらの正確な需要に対応できます。

まず、オープンソースのデータベース向け MCP ツールボックスを独自のセキュアなサービスとしてデプロイします。

code_block: <ListValue: [StructValue([('code', '# ツールボックスの CLI をダウンロードする\r\nexport VERSION=0.27.0\r\ncurl -L -o toolbox https://storage.googleapis.com/genai-toolbox/v$VERSION/linux/amd64/toolbox\r\nchmod +x toolbox'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48643d73a0>)])]>

次に、ローカルのツールボックスサーバーを Cloud Run にデプロイします。公式ドキュメントのこちらの手順に沿って操作します。

ツールボックスは、稼働状態になると、データベースと外部の世界との間のセキュアでスケーラブルなブリッジとして機能します。

次に、Java Spring Boot エージェントをデプロイし、動的に生成された MCP ツールボックスの URL と Vertex AI の設定を環境変数として挿入します。

Cymbal Transit エージェントアプリは次の手順で設定します。

リポジトリのクローンを作成します。
次に、Java Spring Boot エージェントをデプロイし、動的に生成された MCP ツールボックスの URL と Vertex AI の設定を環境変数として挿入します。

code_block: <ListValue: [StructValue([('code', 'gcloud run deploy cymbal-transit \\\r\n --source . \\\r\n --allow-unauthenticated \\\r\n --set-env-vars GCP_PROJECT_ID=my-project,GCP_REGION=us-central1,GEMINI_MODEL_NAME=gemini-2.5-flash,MCP_TOOLBOX_URL=https://toolbox-...'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48643d7520>)])]>

たった 1 つのコマンドで、ステートフルなマルチエージェントのエンタープライズアプリケーションが Cloud Run にデプロイされ、ユーザーに代わってワークフローをセキュアにオーケストレートする準備が整いました。

統合をハードコードする時代は終了

ステートレスな chatbot から自律型のトランザクションエージェントへの移行は、この 10 年間の技術的変化を象徴するものです。しかし、エージェントの能力は、セキュアにやり取りできるシステムによって決まります。

「データベース向け MCP ツールボックス」Java SDK を使用することで、企業開発者はようやく、ネイティブでエレガントかつスケーラビリティの高い方法で、ビジネスを運営するミッションクリティカルな記録システムに対する読み取り / 書き込みアクセスを AI エージェントに付与できるようになります。

独自のステートフルなエンタープライズエージェントを構築する準備はできましたでしょうか。まず、「MCP ツールボックス」Java SDK の公式 GitHub リポジトリをご覧ください。また、デモアプリケーション、Cymbal Bus エージェントの GitHub リポジトリで完全なソースコードを確認し、今すぐお試しください。

- Google スタッフデベロッパーアドボケイト Abirami Sukumaran

- Google ソフトウェアエンジニア、Anubhav Dhawan

データ戦略 = AI 戦略シリーズ: Google Cloud で開発者を AI アーキテクトに進化させる

Tue, 10 Mar 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 3 月 4 日に、Google Cloud blog に投稿されたものの抄訳です。

エージェントの性能は、データによるグラウンディングの質に左右されます。データが整理されていないと、エージェントは高い確信度で回答していても、実際にはハルシネーションを起こしている可能性があります。2026 年には、データ戦略と AI 戦略は実質的に同じものになります。どちらか一方だけでは成り立ちません。

このシリーズ「データ戦略 = AI 戦略」では、この戦略のさまざまな側面を取り上げ、自律エージェントを構築しながら、より決定論的なワークフローを設計する方法をご紹介します。本投稿は、データと AI アーキテクチャの融合に焦点を当てたシリーズの第 1 回です。

業界は重要な転換点を迎えつつあります。2024 年と 2025 年は「API 時代」と定義され、開発者はアプリやエンドポイントを通じて LLM を統合する方法を学びました。2026 年には、エンタープライズアーキテクチャへの移行が求められます。本番環境に対応したアプリケーションを構築するには、プロンプトを書く段階から、インテリジェントなエンドツーエンドのスタックを設計する段階へと移行する必要があります。

課題は、使用する AI モデルだけではありません。それを支えるインフラストラクチャも重要です。アプリケーションがエンタープライズグレードであるためには、スピード、スケール、セキュリティという 3 つの重要な柱の要件を満たす必要があります。本記事では、AI の導入を目的としたエージェントの構築から、十分に戦略化されたコンテキストに基づくエージェントの設計へと移行するという観点から、これらの柱に焦点を当てます。具体的には、このブログとリンク先の Codelab において実践的な学習プログラムを提供し、Google のデータクラウドを活用してアーキテクチャを構築する方法を示します。このアプローチでは、PostgreSQL と完全互換のリレーショナルデータベースを使用します。

戦略的転換: コンテキストエンジンとしてのデータベース

最新の AI スタックでは、データベースはもはや単なるストレージレイヤではなく、コンテキストエンジンとしての役割を担うようになっています。Google の戦略は、AlloyDB for PostgreSQL や Cloud SQL など、PostgreSQL と完全互換のサービスを活用し、本番環境における AI の主なボトルネックであるレイテンシ、AI 機能、検索精度を解消することに重点を置いています。

この学習プログラムでは、開発者からアーキテクトへの移行を支援するために、インフラストラクチャに伴う負担を減らし、高レベルのアーキテクチャ設計に集中できるようにすることを重視しています。

1. インフラストラクチャ税の解消

これまで、ローカルでのプロトタイピングからクラウド規模のデプロイへ移行する際には、「インフラストラクチャ税」とも呼ばれる問題が大きな障壁となっていました。これは、クラスタ、インスタンス、VPC ネットワークピアリングの設定などに多くの時間を費やさなければならないことを指します。自動設定ユーティリティを導入することで、開発者はこうした構成上の障壁を回避できるようになります。

その結果、焦点はインフラストラクチャの管理から、安全なデータフローや高スループットのベクトルパイプラインの設計へと移ります。最近開催されたインストラクター主導の Code Vipassana セッションでは、参加した開発者が、この変化により、各ラボで 1 時間以上の時間を節約できました。このアプローチにより、本番環境への移行を効果的に加速できます。

2. スケーラビリティを前提とした設計: 100 万ベクトル、ループなし

エンタープライズアーキテクチャを構築するには、小規模なデモの段階を超える必要があります。そのため、ベクトル検索を高速化するために、エンベディングのバッチ処理に重点を置いています。AlloyDB では、データベースレイヤ内でエンベディングを大規模に直接生成できます。この機能を活用することで、従来のループ処理に伴うレイテンシを解消し、大規模なデータセットに対してリアルタイム分析を行えるようになります。

3. ソブリンインテリジェンスと行レベルセキュリティ（RLS）

AI におけるセキュリティは、単にファイアウォールを設ければよいというものではなく、データガバナンスまで含めて考える必要があります。そのため Google は、アクセスが許可された特定のデータのみにアクセスするように AI エージェントを制御する仕組みとして、行レベルのセキュリティ（RLS）の活用を重視しています。このプライベート Vault アーキテクチャは、データの分離が不可欠な規制業種において特に重要です。たとえば、ユーザーがエージェントと対話する中で、他のユーザーに関する情報やベンチマーク情報まで知ることができてしまう状況を想像してみてください。データレベルのセキュリティをデータベースに組み込むことは、もはや任意ではありません。誰に何を知らせるべきかという判断を、エージェント任せにすることはできません。

アーキテクチャ学習プログラム

Google は、エンタープライズ AI 開発の全体像を体系的に理解できるよう、一連のハンズオン形式の技術ラボを用意しました。各ラボは、インテリジェントスタックを構成する特定のレイヤに対応しています。

多くのラボでは AlloyDB を使用します。ただし、このアーキテクチャ戦略の流れは Cloud SQL のエコシステムにも広がっています。そのため、この学習プログラムには Cloud SQL for PostgreSQL ユーザー向けの代替ラボもいくつか含まれています。

推奨される学習プログラムには、次のコアアーキテクチャラボが含まれています。

AlloyDB クイックセットアップラボこのラボは、必要な VPC とネットワーク設定を備えた高性能な AlloyDB クラスタを数分でプロビジョニングする方法を紹介するアーキテクト向けの入門ラボです。ここでは、後続のすべての AI ロジックのための安全でスケーラブルな基盤を確立するための「デイゼロ」オペレーションに焦点を当てます。
アプリを AlloyDB データに接続して Cloud Run にデプロイする（または Cloud SQL に接続して Cloud Run にデプロイする）デプロイの段階に進み、このラボではサーバーレスアプリケーションのアーキテクチャを取り上げます。開発者は、セキュリティ向上のためにマネージド ID や接続文字列を活用しながら、Cloud Run サービスを AlloyDB（または Cloud SQL）に接続する方法を学びます。このアプローチにより、アプリケーションレイヤもデータレイヤと同様に堅牢な構成にすることができます。
リアルタイム余剰エンジンを構築する: Gemini 3 Flash と AlloyDB（または Gemini 3 Flash と Cloud SQL）このラボでは、エンドツーエンドのデータドリブン AI アプリケーションを構築し、スピードの柱に対応します。高効率な Gemini 3 Flash モデルを用いてストリーミングデータを処理し、リアルタイムのインサイトを生成する方法をご紹介します。このアプローチにより、データベースとエンドユーザーの間に応答性の高いフィードバックループが構築されます。
100 万ベクトル、ループなし: AlloyDB によるスケーリングスケールに焦点を当てたこのラボでは、ベクトル検索のプロセスについて詳しく説明します。アーキテクトは、データベース内でエンベディングのバッチ処理を直接実装する方法を学びます。このアプローチにより、アプリケーションレイヤのボトルネックを回避し、エンタープライズグレードのパフォーマンスで数百万規模のベクトルの取り込みと検索を実現できます。
プライベート Vault: RLS によるゼロトラストインテリジェンスアーキテクチャのパズルの最後のピースは、セキュリティの強化に焦点を当てています。このラボでは、開発者向けにゼロトラストエージェントの構築方法をご紹介します。PostgreSQL で RLS を実装することで、AI エージェントがユーザーごとのデータ境界を確実に尊重する仕組みを構築できます。このアプローチは、セキュリティを強化しながらコンプライアンスにも対応した AI システムを設計するための指針となります。

未来をデザインする

インフラストラクチャの負担を減らし、スピード、スケール、セキュリティという基本原則に注力することで、新世代の AI アーキテクトを育成することができます。この戦略的な転換により、現在構築されているアプリケーションが、将来の本番環境の要件にも対応できるようになります。

今後開催されるインストラクター主導のハンズオンセッションに参加し、開発者からアーキテクトへのステップアップを始めたい方は、Code Vipassana にご登録ください。

- Google、スタッフデベロッパーアドボケイト Abirami Sukumaran

Gemini 3 Pro Image を使ってみる

Thu, 05 Mar 2026 00:00:00 +0000

※この投稿は米国時間 2026 年 2 月 19 日に、Google Cloud blog に投稿されたものの抄訳です。

前回の投稿では、AI の世界に少し足を踏み入れてみました。Gemini API キーを取得し、最初の「Hello World」AI アプリを構築しました。さらに、Google AI Studio のバイブコーディングを活用してウェブアプリを作成し、Cloud Run にデプロイしました。

しかし、Google Cloud プロジェクトを設定しないままパート 2 の [デプロイ] ボタンを押そうとすると、少し手間取ったかもしれません。Google Cloud プロジェクトを作成すれば、AI アプリのホスティングや大規模データセットの保存が可能になるほか、Nano Banana Pro（Gemini 3 Pro Image）をはじめとする Gemini Pro モデルの機能をフル活用できるようになります。

これらは無料で始められるうえ、試しに使えるクレジットも提供されます。この投稿では、Google Cloud 無料トライアルへの具体的な登録方法と、実際にどのような特典が受けられるのかを詳しく解説します。

Google Cloud アカウントが必要な理由

Google AI Studio はプロトタイピングやテストに最適な環境であり、アプリケーションを Cloud Run に直接デプロイすることもできます。しかし、アプリケーションが成長していくと、拡張や運用管理のために、より幅広い Google Cloud のサービスが必要になります。具体的には、次のようなサービスです。

ホスティング: 有効期限のない URL で AI アプリを公開したい場合。
ストレージ: ユーザーやアプリケーションのデータ、画像、ファイルを保存および検索できる場所が必要な場合。
コンピューティング: バックグラウンド処理を行うワーカーや仮想マシンが必要になる場合。
グローバルスケール: ソリューションを複数のリージョンにデプロイし、世界中のユーザーに高可用性と低レイテンシを確保したい場合。

Google Cloud はこうしたニーズに応えます。Google 検索や YouTube と同じインフラストラクチャをご自身のプロジェクトにも活用できます。

無料で利用できるもの

登録手続きに進む前に、まずは無料で利用できる内容を確認しておきましょう。Google Cloud の無料特典は、次の 2 つで構成されています。

300 ドル分のクレジット（無料トライアル） - 新規のお客様には、91 日間利用できる 300 ドル分の無料クレジットが提供されます。このクレジットは、さまざまな Google Cloud プロダクトにご利用いただけます。
Google Cloud の無料枠 - こちらは開発者にとって心強い制度です。トライアル期間が終了した後も、多くのサービスで毎月更新される無料利用枠が用意されています。利用上限の範囲内であれば、料金は発生しません。

無料枠の主な内容は次のとおりです。

Cloud Run: 1 か月あたり 200 万回の呼び出し（パート 2 で構築したアプリに最適です）。
Compute Engine: 1 か月あたり非プリエンプティブル e2-micro VM インスタンス 1 台（特定の米国リージョンのみ）。
Cloud Storage: 1 か月あたり 5 GB-月分の Regional Storage（米国リージョンのみ）。
BigQuery: 1 か月あたり 1 TiB のクエリ処理と 10 GiB のストレージ。
このほかにも、多くの無料枠が用意されています。

注: 利用上限や対象リージョンは変更される場合があります。最新情報については、無料枠の公式ドキュメントを必ずご確認ください。

ステップごとの登録手順

次の 2 つの条件をいずれも満たしている場合、無料トライアルをご利用いただけます。

これまでに Google Cloud、Google Maps Platform、または Firebase を有料で利用したことがない。
これまで無料トライアルに登録したことがない。

条件を満たしていることを確認できたら、次の手順に沿って進めていきましょう。

ステップ 1 - 開始する

cloud.google.com/free にアクセスします。[無料で利用開始] または [無料で開始] というボタンが表示されるはずです、

注: [無料で開始] ボタンが表示されない場合は、過去に Google Cloud アカウントを有効化している可能性があります。ただし、その場合でも無料枠は利用できます。

ステップ 2 - ログインする

Google アカウント（Gmail アドレス）でログインします。Google AI Studio で使用しているものと同じアカウントを使用できます。

注:「Google アカウント（ユーザー名@gmail.com）をすでにお持ちのようです。別のプロバイダのメールアドレスで新しいアカウントを作成するには、[キャンセル] をクリックしてください。」というメッセージが表示された場合は、[ログイン] をクリックして続行してください。

ステップ 3 - 利用規約に同意する

お住まいの国を選択します。これにより、使用する通貨や適用される利用規約が決まります。続行するには、利用規約に同意する必要があります。

注: スペシャルオファーなどに関するメールを定期的に受信することを希望する場合は、チェックボックスをオンにします。

ステップ 4 - 本人確認を行う

不安を覚えている方もいらっしゃるかもしれませんので、明確にしておきたいと思います。Google では本人確認と不正行為防止のために、クレジットカードなどのお支払い方法の登録を必須としています。

自動請求はありません: 無料トライアルが終了しても、自動的に課金されることはありません。トライアル終了後も引き続きリソースを利用するには、有料アカウントに手動でアップグレードする必要があります。

無料クレジットが付与される前に、銀行口座の確認の一環としてカードが使用される場合があります。確認方法は地域によって異なります。

続行するには、連絡先情報とお支払い方法を入力してください。

ステップ 5: 構築を始める

確認が完了するとコンソールが表示され、画面上部のバナーおよび [請求先アカウント] セクションに、300 ドル分の無料トライアルクレジット残高が表示されます。通常は「My First Project」などのデフォルトのプロジェクトが用意されており、そこから作業を開始できます。必要に応じて、新しいプロジェクトを作成することも可能です。

注: クレジット残高は、現地通貨で表示される場合があります。

AI Studio に戻る

課金が有効なプロジェクトを作成できたので、Google AI Studio に戻りましょう。有料 API キーの入力を求められた場合は、このプロジェクトを使用して Nano Banana Pro を利用できます。

新しいプロジェクトを Google AI Studio にインポートする

新しくインポートしたプロジェクトと連携する新しい API キーを作成する

新しい API キーで Nano Banana Pro を呼び出す

次のステップ

300 ドル分のクレジットと強力なクラウドプラットフォームをご利用いただけるようになりました。では、実際にどのようなものをビルドできるのでしょうか。次回の投稿では、これらを利用して次世代の AI アプリケーションやエージェントをビルドする例をいくつかご紹介します。

それまでの間は、ぜひ Google の豊富な Codelab ライブラリをご覧いただき、次のアイデアの実現に取り組んでみてください。

- リードデベロッパーリレーションズエンジニア、Remigiusz Samborski

Conversational Analytics API を使用して BigQuery で会話型エージェントを構築する

Wed, 04 Mar 2026 01:10:00 +0000

※この投稿は米国時間 2026 年 2 月 20 日に、Google Cloud blog に投稿されたものの抄訳です。

データを BigQuery に取り込むことで情報は一元化できますが、真の課題はそのデータを利用できるようにすることです。技術的な障壁のために、知りたいことがある人（経営幹部からアナリストまで）が必要な回答を得られない、ということが少なくありません。

Gemini を搭載した Conversational Analytics API を使用すれば、複雑なシステムを使わなくてもインサイトが得られます。この API は、自然言語を理解し、BigQuery データをクエリして、テキスト、テーブル、グラフで回答を提供する、コンテキスト認識型エージェントの構築を支援するよう設計されています。

現在、API と連携できるソリューションであれば、どのようなものでも構築できます。たとえば、Agent Development Kit（ADK）と統合してマルチエージェントシステムを構築したり、以下のようなデータ戦略を実装したりすることができます。

運用担当者向けのセルフサービストリアージ: サポートチームやセールスチームなどに、データに関する質問に即座に回答するエージェントを提供します。「Why did signups drop last week?（先週、登録者数が減ったのはなぜ？）」といった質問をチケットで問い合わせなくても、すぐに回答を得ることができます。
SaaS プロダクトを差別化: 優れたチャットインターフェースをプラットフォームに直接埋め込むことで、プラットフォームを差別化できます。お客様は平易な英語を使用して、独自の使用状況データをクエリ、可視化できます。
動的なレポート: 静的な PDF を超えるレポート機能です。核となるレポート機能を自動化し、レポートをリアルタイムの会話バージョンに効果的に置き換え、関係者が微妙なニュアンスのフォローアップの質問をしてより詳細な調査ができるようにします。

この投稿では、Conversational Analytics API を使用して BigQuery で会話型エージェントを構築する方法をご紹介します。

ステップ 1: エージェントを構成して作成する

データ分析エージェントをデプロイするには、最終的な作成呼び出しを行う前に、アクセス、コンテキスト、環境を構成する必要があります。

ご紹介する例では Python SDK を使用していますが、Conversational Analytics API はユーザーの好みや環境に応じて他の多くの言語にも対応しています。

クライアントを初期化し、BigQuery ソースを定義する

まず、API とのやり取りに必要なクライアント（DataAgentServiceClient）をインスタンス化します。このクライアントは、明示的な BigQueryTableReference オブジェクトと組み合わせて使用します。BigQueryTableReference オブジェクトは、エージェントが特定のテーブル（project_id、dataset_id、table_id で定義）にアクセスすることを承認します。こうした個々の参照は、bq フィールドの下の DatasourceReferences オブジェクトに集約されます。

code_block: <ListValue: [StructValue([('code', 'from google.cloud import geminidataanalytics\r\n\r\n# Set project-specific variables (client, location, project IDs)\r\ndata_agent_client = geminidataanalytics.DataAgentServiceClient()\r\nlocation = "global"\r\nbilling_project = "your-gcp-project-id"\r\ndata_agent_id = "google_trends_analytics_agent"\r\n\r\n# Define the BigQuery table sources\r\nbq_top = geminidataanalytics.BigQueryTableReference(\r\n project_id="bigquery-public-data", dataset_id="google_trends", table_id="top_terms"\r\n)\r\nbq_rising = geminidataanalytics.BigQueryTableReference(\r\n project_id="bigquery-public-data", dataset_id="google_trends", table_id="top_rising_terms"\r\n)\r\ndatasource_references = geminidataanalytics.DatasourceReferences(\r\n bq=geminidataanalytics.BigQueryTableReferences(table_references=[bq_top, bq_rising]))'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48652b6040>)])]>

エージェントコンテキストを設定する

system_instruction（エージェントの動作 / ロールを定義）と datasource_references（エージェントがアクセスできるデータを定義）をバンドルして、コンテキストオブジェクトを構築します。完成したコンテキストは、最終オブジェクト DataAgent の DataAnalyticsAgent 構造体の中でネストされます。

文字列ベースのシステム指示を与えることもできますが、より堅牢なコンテキストオブジェクトを使用してエージェントに指示を与えることをおすすめします。さらに、オブジェクトに追加のシステム指示を与えて、補足ガイダンスを提供できるようにすることもできます。

code_block: <ListValue: [StructValue([('code', '# Set the context using our system_instruction string\r\npublished_context = geminidataanalytics.Context(\r\n system_instruction=system_instruction,\r\n datasource_references=datasource_references\r\n example_queries=example_queries\r\n)\r\n\r\ndata_agent = geminidataanalytics.DataAgent(\r\n data_analytics_agent=geminidataanalytics.DataAnalyticsAgent(\r\n published_context=published_context\r\n ),\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48652b63d0>)])]>

エージェントを作成する

data_agent_client.create_data_agent を呼び出します。このリクエストには、親リソースパス（projects/{billing_project}/locations/{location}）、一意のdata_agent_id、デプロイを完了できるようにすべて構成された data_agent オブジェクトが含まれます。

code_block: <ListValue: [StructValue([('code', '# Create the agent\r\ndata_agent_client.create_data_agent(request=geminidataanalytics.CreateDataAgentRequest(\r\n parent=f"projects/{billing_project}/locations/{location}",\r\n data_agent_id=data_agent_id,\r\n data_agent=data_agent,\r\n))'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48652b6a90>)])]>

これで、エージェントが作成され、published_context によって定義されます。

ステップ 2: 会話を作成する（ステートフルとステートレス）

Conversational Analytics API は、以下の 2 つの方法で会話を処理できます。

ステートレス: 質問とエージェントコンテキストを送信します。会話履歴は自身のアプリケーションで管理し、新しいリクエストごとに送信する必要があります。
ステートフル: サーバーで「会話」を作成します。API が履歴を管理します。これにより、ユーザーはフォローアップの質問をすることができます。

ここでは、ステートフルな会話を構成します。新しいエージェントに関連付けられた会話オブジェクトを作成します。

code_block: <ListValue: [StructValue([('code', 'def setup_conversation(conversation_id: str):\r\n data_chat_client = geminidataanalytics.DataChatServiceClient()\r\n conversation = geminidataanalytics.Conversation(\r\n agents=[data_chat_client.data_agent_path(\r\n billing_project, location, data_agent_id)],\r\n )\r\n request = geminidataanalytics.CreateConversationRequest(\r\n parent=f"projects/{billing_project}/locations/{location}",\r\n conversation_id=conversation_id,\r\n conversation=conversation,\r\n )\r\n try:\r\n # Check if it already exists\r\n data_chat_client.get_conversation(name=data_chat_client.conversation_path(\r\n billing_project, location, conversation_id))\r\n except Exception:\r\n response = data_chat_client.create_conversation(request=request)\r\n print("Conversation created successfully.")\r\n\r\nconversation_id = "my_first_conversation"\r\nsetup_conversation(conversation_id=conversation_id)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48652b6e50>)])]>

ステップ 3: ストリーミングチャットループを作成する

インタラクティブな分析を可能にするため、会話フローを管理する関数 stream_chat_response を実装します。Data Analytics Agent API は、レスポンスをストリームとして返すように設計されています。この処理は、エージェントの最新の進捗状況をリアルタイムで提供するために不可欠です。

一般的なレスポンスストリームには、以下のような個別のコンポーネントが含まれます。

スキーマ: テーブルの解像度の確認。
データ（クエリ）: 生成された SQL クエリ（デバッグと透明性の確保に適しています）。
データ（結果）: 結果のデータ構造体（Pandas のような DataFrame など）。
グラフ: データ可視化のための Vega-Lite JSON 仕様。
テキスト: 合成された自然言語での最終的な要約。

関数を定義する

この関数は、ユーザーの質問を受け付けるように定義されています。内部では、DataChatServiceClient を初期化し、ストリーミング完了後にグラフをレンダリングする必要があるかどうかを追跡するための単純なフラグ（chart_generated_flag）を定義します。ユーザーの質問は、API リクエストに必要な Message オブジェクトにラップされます。

code_block: <ListValue: [StructValue([('code', "def stream_chat_response(question: str):\r\n data_chat_client = geminidataanalytics.DataChatServiceClient()\r\n chart_generated_flag = [False] # Flag to help with visualization\r\n \r\n # Format the user's question into an API-ready Message object\r\n messages = [\r\n geminidataanalytics.Message(\r\n user_message=geminidataanalytics.UserMessage(text=question)\r\n )\r\n ]"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48652b6bb0>)])]>

ストリームを処理する

ConversationReference は必須です。ステートフルな会話に関連付け、先ほど作成した特定の data_agent にリンクします。親パス、メッセージ、参照を使ってリクエストオブジェクトを完全に構築したら、data_chat_client.chat を呼び出します。

次に、返されたストリームを反復処理します。ここでは、ユーティリティ関数 show_message を使用して、さまざまなレスポンスタイプ（テキスト、グラフ、データ）を解析し、ユーザーに合わせて適切にフォーマットしています。最後に、ストリーム内で chart_generated_flag が設定されていた場合は、後処理ユーティリティ（preview_in_browser）が可視化のレンダリングを処理します。

code_block: <ListValue: [StructValue([('code', '# Reference the stateful conversation and the created Data Agent\r\n conversation_reference = geminidataanalytics.ConversationReference(\r\n conversation=data_chat_client.conversation_path(\r\n billing_project, location, conversation_id\r\n ),\r\n data_agent_context=geminidataanalytics.DataAgentContext(\r\n data_agent=data_chat_client.data_agent_path(\r\n billing_project, location, data_agent_id\r\n ),\r\n ),\r\n )\r\n \r\n # Prepare the chat request\r\n request = geminidataanalytics.ChatRequest(\r\n parent=f"projects/{billing_project}/locations/{location}",\r\n messages=messages,\r\n conversation_reference=conversation_reference,\r\n )\r\n \r\n # Process the streaming response\r\n stream = data_chat_client.chat(request=request)\r\n for response in stream:\r\n # \'show_message\' is a utility function that formats\r\n # and prints the different response types (text, data, chart)\r\n show_message(response, chart_generated_flag)\r\n\r\n # If a chart was generated, \'preview_in_browser\'\r\n # is a utility to save and serve it as HTML\r\n if chart_generated_flag[0]:\r\n preview_in_browser()'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f4864334820>)])]>

ステップ 4: エージェントと会話する

質問する

では、成果を見てみましょう。stream_chat_response 関数を使用して会話できます。

コンテキストを確認する

まず、エージェントがそのコンテキストを理解しているかどうかを確認しましょう。

Python

code_block: <ListValue: [StructValue([('code', 'question = "Hey what data do you have access to?"\r\nstream_chat_response(question=question)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f4864334b50>)])]>

エージェントは、system_instruction で指定した説明を使用して、top_terms テーブルと top_rising_terms テーブルの概要を返します。

自然言語から SQL、そしてグラフへ

今度は、複雑なクエリを見てみましょう。平易な英語でグラフをリクエストしていることに注目してください。

Python

code_block: <ListValue: [StructValue([('code', 'question = "What are the top 20 most popular search terms last week in NYC based on rank? Display each term and score as a column chart"\r\nstream_chat_response(question=question)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f4864334100>)])]>

エージェントは、このプロセスを以下のようにストリーミングします。

生成された SQL クエリを表示します。このクエリは、top_terms テーブルにアクセスし、dma_name = 'New York NY' と直近の 1 週間でデータをフィルタします。
結果のデータをテーブルとして出力します。
Vega グラフの仕様を生成します。
preview_in_browser ユーティリティがこれを、縦棒グラフを表示する index.html ファイルとして提供します。

ステートフルなフォローアップ

ここで、ステートフルな会話（ステップ 2）が力を発揮します。

Python

code_block: <ListValue: [StructValue([('code', 'question = "What was the percent gain in growth for these search terms from the week before?"\r\nstream_chat_response(question=question)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f4864334940>)])]>

エージェントは、「these search terms（これらの検索語句）」が質問 2 の結果を指していることを記憶しています。新しいクエリを生成し、今回は（join_instructions の指示に沿って）top_terms テーブルと top_rising_terms テーブルを INNER JOIN して、同じ語句リストの percent_gain を取得します。

ステップ 5: エージェントを管理する

エージェントとメッセージのライフサイクル管理について詳しくは、Conversational Analytics API ドキュメントの、実行できるさまざまな API リクエスト（HTTP / Python）に関するページをご確認ください。エージェントの管理方法、SetIAM API、GetIAM API 経由で新たにユーザーを招待して共同作業を行う方法などについても説明しています。

上級者向けのヒント: データと人のギャップを埋める

明確なシステム指示とスキーマ説明を与えることで、単なる会話型エージェントではなく、該当分野のエキスパートとなるエージェントを構築できます。このインタラクティブなアプローチは、静的なダッシュボードを越え、真に利用できるデータ分析を実現します。

始める

- デベロッパーリレーションズエンジニア、David Tamaki Szajngarten

- デベロッパーアドボケイト、Wei Hsia

Gemini CLI で Neo4j の拡張機能を使用する

Mon, 02 Mar 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 2 月 19 日に、Google Cloud blog に投稿されたものの抄訳です。

Gemini CLI は、Gemini の推論機能をターミナルに直接統合します。Neo4j のようなグラフデータベースが、元データを実用的な知識に変える AI 基盤インフラストラクチャとして利用されるようになったため、Gemini CLI との統合は強力な新しいソリューションを提供します。Model Context Protocol（MCP）を活用することで、Neo4j の Gemini CLI 拡張機能は、Gemini の推論エンジンとナレッジグラフの構造化された「メモリ」の橋渡しをします。これにより、開発者はターミナルを離れることなく、クラウドインフラストラクチャのデプロイ、自然言語を使用した Cypher クエリの生成、高度な GraphRAG アプリケーションの構築を行うことができます。

Google Cloud で Neo4j を使用する理由

Neo4j は、情報をノードとノード間の関係として表します。このネットワーク（グラフ表現）は、データ内のつながりから価値を引き出すのに役立ちます。顧客と製品に関する 360 度ビュー、ロジスティクスと最適化、不正行為の検出、製薬業界での創薬など、さまざまな業種で応用されています。本番環境での一部のユースケースは以下のとおりです。

Dun & Bradstreet は、Google Cloud 上で Neo4j を使用して、さまざまな企業間の所有権情報を管理しています。
Uber は構成管理情報を Google Cloud 上の Neo4j に保存しています。

Neo4j の Gemini CLI 拡張機能

Neo4j の Gemini CLI 拡張機能は、拡大を続ける Gemini CLI 拡張機能エコシステムの一部です。Neo4j の Gemini CLI 拡張機能には、Gemini CLI 内に 4 つの Neo4j MCP サーバーがパッケージ化されています。これによりユーザーは、Neo4j Aura のデプロイ、自然言語による Cypher クエリの記述、グラフの可視化、より大規模なエージェントフローでのナレッジグラフのメモリとしての使用ができるようになります。こうしてナレッジグラフと GraphRAG アプリケーションの構築が、これまで以上に簡単になります。

Gemini CLI 拡張機能にバンドルされている 4 つの MCP サーバーは次のとおりです。

mcp-neo4j-cloud-aura-api - Neo4j Aura クラウドサービス管理 API
mcp-neo4j-cypher - 自然言語から Cypher クエリへの変換
mcp-neo4j-data-modeling - インタラクティブなグラフデータモデリングと可視化
mcp-neo4j-memory - Neo4j に保存されたナレッジグラフのメモリ

では、この拡張機能の仕組みを見ていきましょう。

I: Google Cloud Marketplace で Neo4j Aura をサブスクライブする

Neo4j MCP サーバーを使用するには、Neo4j Aura サブスクリプションと API キーが必要です。

Google Cloud Marketplace にログインして、Neo4j Aura をサブスクライブします。
サブスクライブしたら、Neo4j Aura コンソールに移動し、Marketplace で組織を選択してからテナントを選択し、テナント ID を保存します（後のステップで必要になります）。
Aura コンソールで、右上のプロフィールアイコンをクリックし、[アカウント設定] を選択して [API キー] に移動します。そこから [API キーを生成] をクリックします。生成された NEO4J_AURA_CLIENT_ID と NEO4J_AURA_CLIENT_SECRET をコピーします。これらは mcp-neo4j-cloud-aura-api サーバーで使用されます。

Marketplace を通じてデプロイする方法を示す動画をこちらでご覧いただくこともできます。

II. 環境変数を構成する

必要に応じて、こちらの手順に沿って操作してください。視覚的に学びたい方のために、こちらに動画も用意されています。

まず、シェルで環境変数を設定します。これにより、MCP サーバーが Neo4j Aura に接続し、Aura API に対して認証できるようになります。

III. Neo4j の Gemini CLI 拡張機能をインストールする

次のコマンドで拡張機能をインストールします。

code_block: <ListValue: [StructValue([('code', 'gemini extensions install https://github.com/neo4j-contrib/mcp-neo4j'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48643975b0>)])]>

gemini コマンドで Gemini CLI を起動します。

code_block: <ListValue: [StructValue([('code', 'gemini'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48429b2580>)])]>

/mcp desc を実行して、Neo4j MCP サーバーのステータスが [Ready] であることを確認します。緑色のインジケーターが、例えば以下のように表示されます。

Neo4j MCP サーバーの一部が赤色で表示される場合があります。これは、接続するデータベースがまだないためです。

管理サーバー mcp-neo4j-cloud-aura-api の使用

では、MCP サーバーの 1 つを使用してみましょう。Aura Database Manager MCP サーバーを使用すると、新しいデータベースをデプロイできます。デプロイするには、Gemini CLI でプロンプトを入力します。

AuraDB Pro インスタンスを作成するプロンプト:

code_block: <ListValue: [StructValue([('code', 'Create a new AuraDB Pro instance.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48587c9d30>)])]>

Gemini にフォローアップの質問をされる場合があります。たとえば、私のアカウントには Aura テナントが多数あるため、使用するテナントとインスタンスの名前を尋ねられました。

十分なコンテキストが揃うと、Gemini はインスタンスをプロビジョニングし、インスタンス ID、URL、データベースパスワードなどの詳細を返します。

出力は次のようになります。

これらの値を、後で参照できる場所にコピーします。環境変数を設定する際に必要になります。

Gemini CLI をいったん終了し、これらを環境変数として設定します。

環境変数を設定したら、Gemini CLI を再度開きます。

/mcp desc をもう一度実行すると、Neo4j MCP サーバーがすべて緑色で表示されます。これは、すべての環境変数が設定され、接続するデータベースが存在するためです。

コマンドを実行して、他のサーバーを試してみましょう。

Cypher サーバー mcp-neo4j-cypher の使用

グラフの保存には Neo4j が使用されます。グラフはノードとノード間の関係で構成されます。非常に簡単な例として、ノードを作成してみましょう。

code_block: <ListValue: [StructValue([('code', 'Create a Customer node with customer_id = "Gemini".'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f4865701cd0>)])]>

では、データベースに対してクエリを実行しましょう。

code_block: <ListValue: [StructValue([('code', 'Return the count of Customer nodes with customer_id = "Gemini".'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48429b67f0>)])]>

それでは、実行したプロンプトによって Aura コンソールがどのように変化したかを見てみましょう。Neo4j Aura コンソールを開き、インスタンスに移動します。

Gemini を使用してデプロイしたインスタンスが、Aura コンソールに表示されています。

次に、[接続]、[クエリ] の順にクリックします。先ほど使用したパスワードを使用します。Gemini と MCP を使用して作成したノードを確認できます。

Gemini を使用して作成したノードが、Aura コンソールに表示されています。

このように、MCP と Gemini CLI のみを使用して、まったく新しい AuraDB Pro インスタンスを作成できました。次に、そのデータベースインスタンス内に保存されるノードを作成しました。自然言語を使用してすべてを自動的に行えるのは、非常に便利です。

データモデリングサーバー mcp-neo4j-data-modeling の使用

別の MCP サーバーを見てみましょう。

データモデリング MCP サーバーは、グラフの構造を分析して理解するのに役立ちます。具体的には、データベースに存在するラベル、関係、数に関する分析情報をすばやく提供します。これにより、グラフモデルの設計、改良、可視化が容易になります。

Gemini CLI のプロンプト:

code_block: <ListValue: [StructValue([('code', 'Using the data modeling server, list all labels and relationship types in my database,and include a count of nodes per label and relationships per type. Keep it concise.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48432aca00>)])]>

これ以外の操作をしない限り、データベースには 1 つのラベルを持つ 1 つのノードのみが存在しているはずです。

メモリ MCP サーバー mcp-neo4j-memory を使用する

もう 1 つの MCP サーバーを見てみましょう。

メモリ MCP サーバーは、Neo4j 内に事実とコンテキストを永続的に保存する長期的なナレッジストアとして機能します。これにより、エージェントフローと Gemini セッションで、以前に保存された情報の呼び出し、更新、削除ができるようになるため、さらにコンテキストに沿ったより深い対話が可能になります。

メモリに保存するためのプロンプト:

code_block: <ListValue: [StructValue([('code', 'Use the neo4j-memory server to store this fact: "Customer Asha prefers the enterprise support tier."'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48432acb80>)])]>

メモリから取得するためのプロンプト:

code_block: <ListValue: [StructValue([('code', 'Use the neo4j-memory server to retrieve what support tier Asha prefers.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48432ac340>)])]>

もちろん、これは単純化した例です。このようなナレッジグラフを使用すると、複雑な関係を、AI が簡単に取得できる方法で保存できます。これにより、企業で利用可能な知識に基づいて AI をグラウンディングできます。

クリーンアップ

完了したら、このブログの手順説明の冒頭で使用したのと同じ MCP サーバーを使用して、AuraDB Pro インスタンスを削除できます。

Aura インスタンスを破棄するためのプロンプト:

code_block: <ListValue: [StructValue([('code', 'Using the Aura API server, delete the Aura instance "bentest" we just created. Confirm when deletion is complete.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48432ac190>)])]>

必要に応じて、Aura コンソールで削除が実行されたことを確認できます。

まとめ

Neo4j の拡張機能を使用すると、これまでになく簡単にデータをグラフとして表現できるようになります。これにより、データ内のつながりの価値を引き出すことができます。

Google と Neo4j の連携について詳しくは、https://neo4j.com/google をご覧ください。利用可能な Gemini CLI 拡張機能の完全なリストを確認するには、geminicli.com/extensions にアクセスしてください。

皆様がどのようなものを構築されるかとても楽しみにしております。

- デベロッパーアドボケイト、Jack Wotherspoon

- Neo4j、シニアディレクター、Ben Lackey 氏

モデル適応をマスターする: Google Cloud でのファインチューニングガイド

Fri, 20 Feb 2026 03:00:00 +0000

※この投稿は米国時間 2026 年 2 月 12 日に、Google Cloud blog に投稿されたものの抄訳です。

AI アプリケーションを構築している場合、プロンプトをテストしたり、エージェントを試してみたりするかもしれません。しかし、プロトタイプから本番環境に移行するにつれて、モデルの整合性が十分でないという、よくある壁にぶつかることがあります。

Gemini は非常に優れた汎用基盤モデルですが、ブランドのスタイルガイドに沿った回答をより一貫して生成したい場合や、API がカスタムの非標準 JSON 形式で毎回フォーマットされるようにしたい場合もあるでしょう。多くの場合は、プロンプトエンジニアリングとコンテキスト内学習だけで必要な結果を得ることができます。しかし、より専門性の高い本番環境要件に移行するにつれて、モデルの能力をさらに引き出したいと考えるかもしれません。そこでファインチューニングの出番です。

ファインチューニングでは、Gemini 2.5 Flash などの汎用モデルや Llama などのオープンソースモデルを、特定のドメインに適応させることができます。独自の例を含むキュレートされたデータセットでモデルをトレーニングすることで、次のことが可能になります。

整合性を確保する: 特定の回答スタイルや非標準のデータ形式を毎回返すことができます。
効率を高める: 一部のタスクでは、ファインチューニングされた、より小さく、安価で、レイテンシの低いモデルでも同様のパフォーマンスを実現できます。
特化する: トレーニングデータが少ない分野では、ファインチューニングによって精度が向上し、ハルシネーションが減少します。

Google は、プロダクションレディな AI シリーズの一環として、Google Cloud における 2 つの異なるファインチューニングオプションをカバーする 2 つの新しいハンズオンラボをリリースします。1 つは Vertex AI のフルマネージドエクスペリエンス、もう 1 つは Google Kubernetes Engine（GKE）の自由にカスタマイズ可能なパスです。

オプション 1: Vertex AI を使用したマネージドパス

多くのデベロッパーにとって、目標はインフラストラクチャのオーバーヘッドをできるだけ抑えながらモデルのパフォーマンスを向上させることです。すぐにモデル適応を実現できる「ボタン」があったら便利でしょう。

Vertex AI には、Gemini などのモデルをファインチューニングするためのフルマネージドサービスが用意されています。GPU のプロビジョニング、チェックポイントの管理、複雑なトレーニングループの記述について心配する必要はありません。データを指定してパラメータを構成するだけで、残りの処理は Vertex AI が行います。

最初の新しい Codelab では、軽量で効率性の高いモデルである Gemini 2.5 Flash をファインチューニングする方法をご紹介します。Vertex AI SDK for Python を使用した教師ありファインチューニング（SFT）のワークフロー全体を知ることができます。

学習内容

データ準備: Gemini で想定される JSONL 形式に元データを変換する方法。
ベースライン: 改善を定量化するために、まずベースモデルを評価する方法。
チューニング: わずか数行の Python でチューニングジョブを起動する方法。
評価: ROUGE などの自動指標を使用して、新しいチューニング済みモデルをベースモデルと比較する方法。

aside_block: <ListValue: [StructValue([('title', 'ラボに移動'), ('body', <wagtail.rich_text.RichText object at 0x7f48656fe4f0>), ('btn_text', ''), ('href', ''), ('image', None)])]>

オプション 2: GKE を使用したカスタムパス

本番環境の要件によっては、完全な制御が必要になることがあります。Llama、Mistral、Gemma などのオープンソースモデルを使用している場合、特定の重みを調整したり、カスタムトレーニングライブラリを使用したり、特定のハードウェア構成で実行したりする必要があります。

Google Kubernetes Engine（GKE）は、そのために最適なプラットフォームです。Google のスケーラブルなインフラストラクチャのメリットを享受しながら、独自の GPU リソースと環境を管理し、AI ワークロードを柔軟にオーケストレートできます。

2 つ目のファインチューニング Codelab では、Kubernetes における MLOps の基本を学びます。LoRA（Low-Rank Adaptation）と呼ばれる手法を使用して Llama 2 をファインチューニングします。LoRA では、事前トレーニング済みモデルの重みが固定され、目的に合わせてチューニングされた、より小さいトレーニング可能なパラメータレイヤが注入されるため、多くのモデルを効率的にファインチューニングできます。これにより、トレーニングが必要なパラメータの数が大幅に減り、より小さく、費用対効果の高いアクセラレータで巨大なモデルをファインチューニングできるようになります。

学習内容

インフラストラクチャ: GPU ノードプール（特に NVIDIA L4 GPU を使用）で GKE クラスタをプロビジョニングする方法。
効率性: LoRA を使用して、膨大な費用をかけなくても 70 億パラメータモデルをファインチューニングできる方法。
セキュリティ: Workload Identity を使用して、サービスアカウントキーを管理しなくても Cloud Storage に安全にアクセスできる方法。
コンテナ化: 再現可能な実行のために、PyTorch トレーニングコードを Docker コンテナにパッケージ化する方法。

aside_block: <ListValue: [StructValue([('title', 'ラボに移動'), ('body', <wagtail.rich_text.RichText object at 0x7f48656fe670>), ('btn_text', ''), ('href', ''), ('image', None)])]>

どのパスを選択すべきか？

Vertex AI は、迅速なイテレーションが必要であり、マネージドサービスを希望し、Google の強力な Gemini モデルを基盤として構築する場合に選択できます。
GKE を選択できるのは、詳細なカスタマイズが必要な場合、オープンソースエコシステム（Hugging Face、Llama など）にコミットしている場合、またはトレーニングを既存の Kubernetes ベースのプラットフォームに緊密に統合する必要がある場合です。

どちらのパスを選んでも同じ目的地、つまり汎用モデルでは決して実現できないレベルでビジネスを理解した、本番環境対応のモデルに到達できます。

プロトタイプから本番環境へ

これらのラボは、Google の公式な学習プログラムである「Google Cloud でのプロダクションレディな AI」の一部です。有望なプロトタイプから堅牢な本番環境グレードの AI アプリケーションへの移行に役立つコンテンツについては、カリキュラム全体をご覧ください。

学習プログラム全体を確認する

ハッシュタグ #ProductionReadyAI で成果を共有し、仲間とつながりましょう。ぜひご活用ください。

- デベロッパーアドボケイト、Drew Brown

Gemini を使用してコードサンプルを大規模に生成する際の 7 つの技術的なポイント

Fri, 20 Feb 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 2 月 12 日に、Google Cloud blog に投稿されたものの抄訳です。

生成 AI を使用したコードの作成はよく知られたタスクですが、別の課題として、生成 AI を利用してプロダクションレディな教育コンテンツを作成することが挙げられます。Google Cloud プロダクトの説明に利用できるリソースの幅を広げる作業に Gemini を活用し始めたとき、既存の汎用的な生成 AI 搭載アプリやツールだけでは不十分で、ユースケースに合わせた専用のシステムが必要であることに気づきました。

解決しようとしていた問題

Google Cloud には 100 以上のプロダクトがあります。各プロダクトには、JavaScript、Python、Go、Java などの言語のクライアントライブラリを使用して作成、操作、クエリできる独自のリソースセットがあります。Google のチームは、開発者がこれらのクライアントライブラリを使用する方法を学ぶためのサンプルコードを用意しています。

例として、@google-cloud/storage-control Node.js クライアントライブラリを使用して Google Cloud Storage の「フォルダ」リソースを一覧表示する方法を示すサンプルがあります。

code_block: <ListValue: [StructValue([('code', 'const { StorageControlClient } = require("@google-cloud/storage-control").v2;\r\n...\r\nconst client = new StorageControlClient();\r\n...\r\n const request = {\r\n...\r\n };\r\n...\r\n const [folders] = await client.listFolders(request);\r\n...\r\n for (const folder of folders) {\r\n console.log(`Folder name: ${folder.name}`);\r\n console.log(` Metageneration: ${folder.metageneration}`);\r\n }\r\n...'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f486214d6d0>)])]>

近年、Google は生成 AI を活用してこれらのサンプルを開発しています。これは驚くことではありません。しかし、2024 年後半に、より体系的なアプローチを取り始め、チームが高品質なサンプルを迅速に作成できるよう、専用のツールセットを開発しました。これらのツールは、Vertex AI の Gemini と Genkit（生成 AI ツール開発用のオープンソースフレームワーク）を活用した、一連の決定論的な自動化と AI ワークフローで構成されています。

このブログ投稿では、まずサンプル生成システムのアーキテクチャの概要を説明し、次に開発プロセスから得られた 7 つの技術的なポイントをご紹介します。

サンプル生成アーキテクチャ

このシステムは、次のサブシステムで構成されています。

生成: このサブシステムは Gemini を使用して、サンプルファイルと、単体テストや依存関係マニフェスト（package.json や requirements.txt など）といったその他の必要なアーティファクトを作成します。
検証: 生成されたコードは、検証サブシステムによって「LLM-as-a-judge」と決定論的ツール（linter など）を組み合わせて評価され、クラウドスタイルや言語固有のベストプラクティスなどのカテゴリでコードにスコアが付けられます。そのフィードバックは生成システムに送り返され、サンプルが改良されます。
デリバリー: 生成されたサンプル（および単体テストなどの関連するアーティファクト）は、人間によるレビューとテストを経て、GitHub リポジトリ、サンプルブラウザ、その他の docs.cloud.google.com ページに公開されます。

このようなアーキテクチャを踏まえ、開発プロセスから得られた7 つの技術的なポイントをご紹介します。

7 つの技術的なポイント

これらの知見は、基本的なプロンプトエンジニアリングを超えて、プロダクションレディな生成 AI システムを構築およびスケーリングするための実用的なロードマップとなります。

ポイント 1: 分解する

私たちが当初 Gemini にもたらしていた問題は、問題が大きすぎることでした。

各サンプルファイルは 50～100 行程度です。システムの初期バージョンでは、1 回のプロンプトで Gemini がファイルコンテンツの大部分を生成することを想定していました。しかし、特に私たちのユースケースではコードの各行が非常に細かくなるため、Gemini（2.5）ではこの問題が大きすぎることがわかりました。Gemini が指示から逸脱するケースは数多くありました。下の画像で、左側のコードには Gemini が生成したコード（具体的には約 20 行のコード）が含まれており、右側のコードには、私たちが実際に臨んでいたコード行が含まれています。2 つのコードチャンクの間には、不要なコメントや不要な process.exit() 呼び出しなど、多くの差分（つまり違い）があることがわかります。

問題をより小さなサブ問題に分ける必要があることは明らかでした。分解が必要だったのです。私たちの場合、サンプルファイルを複数のパーツに分割しました。サンプルファイルは、次の要素で構成されています。

スニペット: 開発者にとって役立つ、サンプルファイルの教育的パーツ
CLI ロジック: ユーザーがコマンドラインインターフェースを使用してサンプルファイルを呼び出すことを可能にする

code_block: <ListValue: [StructValue([('code', '...\r\n// The snippet\r\nasync function getSecret(projectId, secretId) {\r\n const name = `projects/${projectId}/secrets/${secretId}`;\r\n try {\r\n const [secret] = await client.getSecret({\r\n...\r\n// The CLI logic\r\nUsage:\r\n node secretmanager-service-client-secret-get-async.js example-project-id example-secret-id\r\n`);\r\n process.exitCode = 1;\r\n });\r\n main(process.argv.slice(2));\r\n...'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f48656bedf0>)])]>

サンプルを意味のあるパーツに分割し、各パーツに個別の生成プロンプトを割り当てることで、LLM のハルシネーションと指示からの逸脱を大幅に減らすことができました。

重要なポイント 2: 決定論を採用する

発生した問題が決定論的に簡単に解決できる場合は、決定論的に解決します。

発生した特定の問題を解決しようとするとき、最初に Gemini を思い浮かべてしまうという、視野狭窄のような状態に陥りやすい時期もありました。LLM の導入ではなく、自動化の導入というより大きな目標を忘れてしまうこともありました。発生した問題の多くを解決する、既存の確実な決定論的方法があることを忘れがちでした。

現在でも、ファイルに Apache ライセンスヘッダーを追加する、依存関係マニフェスト（package.json ファイルなど）を生成する、LLM で生成されたコードの lint 関連の問題を自動修正する、lint 関連のフィードバックを生成して Gemini に送り返すなど、システムが決定論的に行うことはたくさんあります。

ポイント 3: プロンプトを具体的に記述する

プロンプトは具体的に記述し、暗黙の前提を明示します。もちろん、これはプロンプトエンジニアリングの基本です。しかし、その重要性は過言ではありません。

具体的に記述することは特に重要でした。なぜなら、開発者が記述する他のほとんどの種類のコードとは異なり、サンプルコードには次のような特長があるからです。

多くのオーディエンスがおり、その多くはプログラミング初心者である
教育目的で存在している。主なオーディエンスは、コードが実行されるマシンではなく人間です。
異なるプロダクト間で一貫している必要がある。どのサンプルも同じ開発者が書いたようにする必要があります。

そのため、ユーザーが読む可能性のあるすべての行を計画的に作成する必要があります。

プロンプトで数十もの異なるルールを明示する必要がありました。たとえば、私たちがワンショットの例として作成したサンプルでは「projectId」パラメータのデフォルト値を設定していないのに、Gemini は設定しました。Gemini にそうしないよう明示的に指示する必要がありました。

code_block: <ListValue: [StructValue([('code', "async function createGlossary(\r\n projectId = 'example-project-id', // We don't want Gemini to set a default value for projectId.\r\n location = 'us-central1',\r\n glossaryName = 'example-glossary-name',\r\n) {"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f4862ebe640>)])]>

プロンプトを具体的に記述することで、次のことも可能になりました。

検証システムのフィードバックに埋め込まれていた指示の一部をシフトレフトする必要がありました。つまり、最初の世代のプロンプトの初期バージョンでは、モデルが検証システムからのフィードバックを通じて後で学習する重要な指示がモデルに与えられていませんでした。
人間が生成するサンプルの種類に関する専門知識を深める必要がありました。つまり、チームとしてこれまで体系的に回答したことのないサンプルに関する質問に答える必要があったのです。サンプルについて 100 以上の異なる設計上の決定事項について合意に達しました。

ポイント 4: 評価者を評価する

一般的に、評価システムは生成システムよりも信頼できますが、評価システムも慎重に評価する必要があります。

生成評価モデルがうまく機能するのは、人間と同じように、LLM は一般的に、評価対象のコンテンツを作成するよりも、コンテンツを評価する方が得意だからです。しかし、評価システム（または検証システム）の信頼性を高めるために、（LLM-as-a-judge LLM の評価プロンプトから得られた）いくつかの質問に対する Gemini の回答と、手作業で作成したデータセットを比較しました。私たちは、LLM-as-a-judge の質問の一部について、不完全なサンプルとそれに関連する正解を手作業で作成しました。下の図では、4 つの不完全なサンプルで 5 つの質問が評価されています。黄色（薄い色）の正方形は、Gemini が正しく回答できなかった質問を表しています。LLM が確実には回答できない「危うい」質問を特定できました。このプロセスにより、これらの「危うい」質問を破棄し、評価プロンプト全体を改良することができました。

ポイント 5: 他の側面もスケーリングする

システムの LLM 以外の側面もスケーリングできるようにします。

chat bot やコードの自動補完とは異なり、私たちのユースケースでは Gemini からの即時のフィードバックは必要ありません。単一のサンプル、検証フィードバック、および単体テストなどの関連するアーティファクトの生成が完了するまで、1 分ほど待つ余裕がありました。さらに、Gemini は、生成した数百ものサンプルの中でも、ユースケースの費用を低く抑えてくれました。そのため、Google のシステムの LLM 関連の側面はうまくスケーリングできました。

しかし、プロセスの最終工程は同じようにはうまくいきませんでした。サンプルを公開する準備には、サンプルあたり約 5～15 分かかりました。各サンプルの人間によるレビューとエンドツーエンドのテストが含まれるため、このプロセスが最大のボトルネックとなりました。

ポイント 6: 最終的な出力をエンドツーエンドでテストする

コードが機能しない場合は、公開できません。

そのため、公開するサンプルをエンドツーエンドでテストすることが重要でした。これは、おそらく教訓というよりは、チームとしてたどり着いた哲学的なコンセンサスです。

私たちが公開するコードは、ユーザーが実行することを想定して設計されています。ユーザーと同じような状況で自分たちが実行できるのでなければ、ユーザーにとって役に立つことが実証されたサンプルを提供することはできません。当初から、手書きのサンプルは、公開前に手動またはプログラムでエンドツーエンドテストを行っています。サンプルの作成方法を変えても、サンプルの品質が低下してはなりません。

DORA は、この「信頼するが検証はする」アプローチを「成熟した AI 導入」の兆候として説明しています。厳格なエンドツーエンドテストは、私たちのためだけでなく、サンプルを利用する開発者の信頼を維持するために不可欠です。

ポイント 7: 優れたエンジニアリングを行う

確立されたエンジニアリングのベストプラクティスを適用すれば、他のすべては後からついてきます。

よく考えてみると、上述したポイントの多くは、LLM を大規模に使用してコンテンツやコードを生成する分野に特有のものではありません。これらのシステムを構築する際に下した、プラスの影響をもたらすエンジニアリング上の決定の多くは、LLM とはまったく関係がなく、上記のポイントでも言及されていません。

まとめ

高品質な教育用コードサンプルを大規模に生成する過程で、成功の鍵は強力な LLM だけではないことがわかりました。Gemini と Genkit が必要な生成能力を提供してくれましたが、真のブレークスルーは、専門的なエンドツーエンドのシステムを構築したことによってもたらされました。問題を分解すること、決定論を採用すること、エンドツーエンドのテスト、パイプライン全体のスケールなど、ここで説明した 7 つのポイントは、LLM と確立されたエンジニアリングプラクティスを組み合わせた、信頼性が高くスケーラブルな生成システムを構築する方法を示しています。

- シニアデベロッパーリレーションズエンジニア、Nim Jayawardena

- スタッフデベロッパーリレーションズエンジニア、Adam Ross

Antigravity と Gemini CLI の比較

Wed, 18 Feb 2026 02:00:00 +0000

aside_block: <ListValue: [StructValue([('title', '注'), ('body', <wagtail.rich_text.RichText object at 0x7f48643e15b0>), ('btn_text', ''), ('href', ''), ('image', None)])]>

※この投稿は米国時間 2026 年 2 月 5 日に、Google Cloud blog に投稿されたものの抄訳です。

要約

Antigravity: エージェントの管理機能と IDE のエクスペリエンスを最大限に利用したい場合。
Gemini CLI: ターミナルでの CLI や、ヘッドレスでの実行が必要な場合。

比較早見表

機能	Antigravity IDE	Gemini CLI
対象ユーザー	アプリケーションの構築やタスクの実行にエージェントを活用することを検討しているユーザー（職種は問わない）。	ターミナルで作業することを好む技術者。
インストール	簡単に操作できるグラフィカルユーザーインターフェースを使用。事前のインストール作業なし。	`npm install -g @google/gemini-cli` によるクイックインストール（Node.js が必要）。
複数のエージェントのオーケストレーション	Agent Manager（複数のエージェントを実行するためのミッションコントロールダッシュボード）を利用。	`tmux` または個別のターミナルウィンドウによる多重化により、複数のエージェントを実行可能。
仕様駆動開発	独自。豊富なチュートリアルを用意。	Conductor 拡張機能を使用して構成可能。
拡張性	Open VSX 拡張機能、MCP、Agent Skills。	Gemini CLI 拡張機能、MCP、Agent Skills。
インターフェースの特長	統合ブラウザにより、アプリケーションの表示、視覚的なフィードバックの提供、エージェントとのスムーズな連携が可能。ネイティブデバッグ機能を使用して、スタックトレースの検知と修正が可能。	ヘッドレスモードは、インタラクティブな UI なしで実行できるため、出力のパイプ処理、CI / CD 統合、自動化スクリプトに最適。 `gh` や `gcloud` などのローカルツールを直接呼び出し可能。

判断に迷う場合

どちらを選ぶべきかまだ決められない場合でもご安心ください。どちらも優れた選択肢であることは間違いありません。Antigravity は、どなたでも気軽に使い始めることができます。Gemini CLI は、GitHub で 10 万個近くのスターを獲得しており、デベロッパーコミュニティにおいて高い支持を得ています。どちらも充実した無料枠を用意していますので、ぜひ両方をお試しいただき、お好みのものをお選びください。

- Google Cloud、デベロッパーアドボケイト、 Luke Schlangen

AI エージェントを大規模に構築する新たな道筋、Gemini Enterprise Agent Ready（GEAR）プログラムが利用可能に

Mon, 16 Feb 2026 02:00:00 +0000

※この投稿は米国時間 2026 年 2 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。

現在の世の中はエージェント型で満ちています。エージェントとは、複雑なワークフローを実行するために、ユーザーに代わって推論、計画し、行動できるソフトウェアのことです。

この状況に対応するため、Google は Gemini Enterprise Agent Ready（GEAR）学習プログラムをすべてのユーザーに公開することにしました。Google Developer Program 内の新しい専門パスウェイとして、GEAR は開発者やプロフェッショナルが Google AI を使用してエンタープライズグレードのエージェントを構築、デプロイできるようにします。

GEAR は、ユーザーが次の時代を築いていけるよう、以下のようなお手伝いをします。

試験運用からプロダクションレディなアーキテクチャへの移行

エンタープライズグレードのエージェントを構築するには、適切なツール、計画、インフラストラクチャが必要です。ですが、これらのスキルを習得するには、費用を気にすることなく自由に試せる環境が必要となります。

そのため、GEAR メンバーには、Google Skills で使用できる 35 の学習クレジットが毎月提供されます。この特典は繰り返し利用でき、サンドボックス環境でラボやテストを無料で実行できます。

メンバーはこれらのクレジットを使用して、コードをすぐにリリースできるよう設計されたエンドツーエンドの学習プログラムにアクセスできます。現在利用可能な学習プログラムは以下のとおりです。

エージェントの概要: エージェントの構造、動作、Gemini Enterprise ワークフローへの統合、より広範な Google Cloud エコシステム内での位置付けを理解します。
Agent Development Kit（ADK）を使用したエージェントの開発: オープンソースの ADK について詳しく学びます。推論ループを使用して、予測可能で信頼性の高い結果を提供するエージェントを構築し、プロンプトの入力から実際のエンジニアリングに移行します。

習熟した技術を業界で認められた認定資格に変える

GEAR では、これらの学習プログラムの進捗に合わせて、身に付けた技術を具体的な認定資格に変えることができます。

バッジの獲得: Google Skills でエージェントに焦点を当てたラボを修了すると、Google デベロッパープロフィールに修了バッジが表示されます。さらに、専門知識を認証する公式の中級および上級スキルバッジも獲得できます。
認定資格の取得:「認定資格を取得する」では、スキルの認定を目指すお客様向けに、インストラクター主導のトレーニングや技術メンターシップを提供しています。Google Cloud のお客様を対象とするこのコホートベースのプログラムには、AI コース、ハンズオンラボ、スキルバッジが組み込まれています。そのいずれも、業界で認められた認定資格の取得に向けて準備できるよう設計されています。

使ってみる

エージェント型 AI への移行は大きなチャンスですが、今までとは違うスキルセットが求められます。GEAR は、次の時代を築くためのツール、クレジット、ガイダンスを提供します。

Google Developer Program のプロフィールを作成するかログインして GEAR バッジを申請すると、GEAR の特典を利用できます。

今すぐ、developers.google.com/program/GEAR で最初の学習プログラムを始めましょう。

- プロダクトマーケティング担当バイスプレジデント、Peder Ulander

- グローバルソリューションおよびインダストリー担当バイスプレジデント、Carrie Tharp

Agent Factory のハイライト: Gemini 3 で AI 従業員を構築

Mon, 16 Feb 2026 01:00:00 +0000

※この投稿は米国時間 2026 年 2 月 6 日に、Google Cloud blog に投稿されたものの抄訳です。

Agent Factory の今回のエピソードは、Smitha Kolan と Vlad Kolesnikov が、フルスタックエンジニアの Brandon Hancock を迎えてお送りします。Brandon は、8 万人以上のデベロッパーに AI のコンセプトを教えている YouTube チャンネル AI with Brandon のクリエイターでもあります。

今回の収録は、新しいフラッグシップモデルの Gemini 3、コーディング環境 Antigravity、Gemini CLI のアップデートなど、Google がいくつかの重要な最新情報を発表した数時間後という特別なタイミングで行われました。このエピソードでは、ライブデモを通じてこれらの新しいツールについて詳しく説明しています。

Gemini 3 と Gemini CLI

Gemini 3 は、Google の最新のフラッグシップモデルです。高度な推論と複雑なエージェント運用を目的に設計されており、オーケストレーションに最適です。Gemini CLI は、ターミナルから Gemini モデルと直接やり取りできるコマンドラインインターフェースであり、デベロッパー向けの機能です。入力と出力のパイプ処理をサポートしているため、複雑なインフラストラクチャなしで、プロンプトを連鎖して軽量な「AI 従業員」を構築できる強力なツールです。

Gemini 3 Pro で個人ポートフォリオを構築する

タイムスタンプ: 01:18

Smitha は、Google AI Studio と Gemini 3 Pro を使用して、わずか数分でゼロから個人用ウェブサイトを構築するデモを披露しました。この目的は、LinkedIn プロフィールを変換してポートフォリオサイトにデプロイすることでした。

入力データ: LinkedIn プロフィールの PDF エクスポートと個人の顔写真のほかに、Nano Banana（画像生成ツール）で生成したインスピレーション画像をアップロードしました。
マルチモーダルプロンプト: コンテンツに PDF を使用することと、Nano Banana の画像をスタイルの指針にするように Gemini 3 に指示しました。
反復的な改良: 最初の出力にプレースホルダ画像が含まれていたため、Smitha は AI Studio のアノテーション機能を使用して該当箇所をハイライトし、アップロードした写真を使用して修正するように Gemini に指示しました。
デプロイ: 最終結果は、ワンクリックで Cloud Run に直接デプロイされました。

Gemini CLI で「AI 従業員」を作成する

タイムスタンプ: 07:54

Brandon は、Gemini CLI を使用して「AI 従業員」を構築する方法を紹介しました。デモでは、潜在顧客を見つけるために設計された市場調査エージェントに焦点を当てています。このエージェントは、Brandon が関わる救急医療サービス分野のスタートアップを対象にしたものです。

標準作業手順書（SOP）: Brandon は、プロンプトをマークダウンファイルに保存された SOP として扱っています。Gemini 3 Pro を使用して大まかな指示を書き、より高速で安価な Gemini 2.5 Flash を使用して「働き蜂（作業担当者）」のタスクを実行しました。
並列実行: Gemini CLI を呼び出して複数のエージェントを並列実行する Python スクリプトを実演しました。これにより、潜在顧客を複数の都市（例: マイアミ）で同時に検索することが可能になりました。
裏技: Brandon は、Python スクリプトを Gemini に渡すことで、モデルがパラメータを理解し、ワークフロー自体を開始できる仕組みを説明し、自動化を効果的に自動化できることを紹介しました。

「Anya the Capybara」動画エージェント

タイムスタンプ: 18:15

Vlad は、Agent Development Kit（ADK）で構築したエージェントを実演しました。このエージェントは、技術ドキュメントを魅力的な教育動画に変換するもので、AI キャラクターの「Anya the Capybara」がナビゲートします。

エージェントアーキテクチャ: このシステムは、2 つのサブエージェントを管理するルートオーケストレーターエージェントを使用しています。これらのサブエージェントは、スクリプトシーケンサー（技術的なテキストを自然なスクリプトに変換し、8 秒単位のセグメントに分割する）と動画生成ツールです。
一貫性: キャラクターの一貫性を保つため、Vlad は Nano Banana を使用して Capybara の 4 つの特定のビューを生成しました。エージェントはチャンクごとにランダムにビューを選択し、動画をダイナミックに保ちます。
Antigravity の活用: Vlad は、新しい Antigravity の機能を使用してエージェントのコードをリファクタリングしたことを明らかにしています。プロンプトとサブエージェントの変更を Antigravity に指示するだけで、コーディング作業がツールで自動的に処理されました。
動画の結合: 最後に、Gemini CLI を使用して FFmpeg コマンドを記述し、生成された 92 個の動画チャンクを 11 分間の 1 本の動画に結合しました。

動画生成エージェントのコードはこちらで確認できます。

AI ファーストの考え方

タイムスタンプ: 10:21

デモの合間には、これらのツールを構築する際の理念について話し合いました。Brandon は、AI 時代における生産性向上へのアプローチについて語りました。

AI 従業員のコンセプト

タイムスタンプ: 15:50

Brandon は、あらゆる面で「AI ファースト」を目指すという目標を説明しました。彼は、エージェントを単なるスクリプトとして考えるのではなく、自身が高度な戦略に集中できるようにしてくれる従業員と捉えており、「標準業務手順書」（マークダウンファイル）のフォルダを作成することで、市場調査やメールの下書きなどのタスクを Gemini に割り当てることができると説明しました。また、現在は参入障壁が非常に低くなっているため、コーディングの経験がなくても、Gemini モデルの「従業員」を立ち上げて、反復作業を大規模に処理できると指摘しています。

「ゴーストライター」ワークフロー

タイムスタンプ: 15:50

Brandon は、市場調査の例のほかに Gemini CLI を「ゴーストライター」として使用する方法についても触れました。MCP（Model Context Protocol）サーバーを Gmail に接続することで、AI に過去の文体を学習させ、メールの返信の下書きを作成できることを紹介しました。重要なのは、AI がタスクを開始する前に「自分が誰であるか」を認識できるように、適切なコンテキストを提供することだと、Brandon は強調しています。

まとめ

本エピソードでは、開発サイクルが急速に進化してることを浮き彫りにしました。推論に Gemini 3 Pro、迅速な実行に Gemini CLI、コードのリファクタリングに Antigravity といったツールを使用することで、あらゆるものを自動化することが現実となる時代が到来しています。個人のウェブサイトを構築する場合でも、市場調査エージェントのフリートを構築する場合でも、アイデアから実行に至るまでの障壁はかつてないほど低くなっています。

構築してみる

Gemini CLI を使用してご自身の「AI 従業員」を構築することに挑戦してみませんか。繰り返し行っている簡単なタスクから始め、マークダウンで標準作業手順書を作成し、Gemini にそのタスクを任せられるかどうか試してみましょう。

エピソード全体をチェックして、コードが動作する様子をご覧ください。

担当者のソーシャルメディア

Smitha Kolan → YouTube、LinkedIn、X
Vlad Kolesnikov → Linkedin、X
Brandon Hancock → YouTube

- シニアデベロッパーリレーションズ Smitha Kolan

デベロッパー

Google ADK、MCP、Cloud Run を使用して専門家向けコンテンツ用のマルチ エージェント システムを構築する - パート 1

学習内容

Dev Signal の概要

前提条件

プロジェクトのセットアップ

1. プロジェクトを初期化する

2. フォルダ構造

3. 依存関係を定義する

エージェント機能の構築: MCP ツール

ツールの構成

Reddit 検索（発見ツール）

Google Cloud ドキュメント（ナレッジツール）

画像生成ツール（Nano Banana MCP）

Nano Banana Pro サーバー ロジックの実装

サーバー エントリポイント（main.py）

生成ロジック（nano_banana_pro.py）

GCS アップロード ヘルパー（storage_utils.py）

データモデル（media_models.py）

ツールの依存関係（requirements.txt）

まとめ

LLM 推論の効率的フロンティアに到達するための 5 つの手法

推論に効率的フロンティアがある理由

推論の 2 つの軸

フロンティアに到達する: 制御可能な 5 つの手法

ケーススタディ: Vertex AI がフロンティアに近づいた方法

まとめ

AI リテラシーの新しい形: 学生デベロッパーを対象とした調査結果

調査

調査結果その 1: 24 時間 365 日、いつでも頼れる先生

調査結果その 2: 過度な依存に対する積極的な抵抗

調査結果その 3: AI の使いどころを心得ている

すべてを任せるのではなく、意図的に取り入れる

カスタマイズが肝

この調査結果が業界において意味すること

分散 AI エージェントの構築

分散エージェントを使用する理由（フロントエンド チームに感謝される理由）

全体的な設計: コース作成アプリ

ステップ 1: スペシャリスト（リサーチャー）の配備

ステップ 2: 評価担当者（構造化されたデータ出力）

ステップ 3: 共通言語（A2A プロトコル）

ステップ 4: オーケストレーター パターン

デプロイ:「食料品店」モデル

注意事項、セキュリティ上の配慮

構築を始めるにあたって

マルチクラスタ GKE Inference Gateway のご紹介: 世界中で AI ワークロードをスケール

AI 推論にマルチクラスタを使用する理由

仕組み

使ってみる

Vertex AI で復元力の高い LLM アプリケーションを構築し、429 エラーを減らす

適切な使用量オプションの選択

Vertex AI で 429 エラーを減らす 5 つの方法

使ってみる

Ollama、GKE の GPU 共有、vCluster を使って、費用対効果の高い AI を実現する

アーキテクチャ: 共有ハードウェア上の仮想クラスタ

デプロイ

プロダクション レディな AI エージェントに関するデベロッパー ガイド

出発点

RAG 対応生成 AI アプリケーションのプライベート ネットワーク接続の設計

RAG の効力

設計パターンの例

トラフィック フロー

RAG の挿入フロー

推論フロー

管理とルーティング

次のステップ

エージェント型 chatbot に高速で信頼性の高い長期メモリを提供

短期、中期、長期の履歴に対応するポリグロット ストレージ アプローチ

ポリグロット アプローチとは

短期、中期、長期メモリに対する Google Cloud での定義例

データの流れを最適化するハイブリッド同期 / 非同期戦略

今すぐ構築を開始

Java SDK「MCP ツールボックス」リリースのお知らせ

MCP: AI エージェント向けの USB Type-C

データベース向け MCP ツールボックス

この Java SDK を使ってみる

実際の例: 自律型の交通機関コンシェルジュ

統合をハードコードする時代は終了

データ戦略 = AI 戦略シリーズ: Google Cloud で開発者を AI アーキテクトに進化させる

戦略的転換: コンテキスト エンジンとしてのデータベース

Google ADK、MCP、Cloud Run を使用して専門家向けコンテンツ用のマルチエージェントシステムを構築する - パート 1

Nano Banana Pro サーバーロジックの実装

サーバーエントリポイント（`main.py`）

生成ロジック（`nano_banana_pro.py）`

GCS アップロードヘルパー（`storage_utils.py）`

データモデル（`media_models.py`）

ツールの依存関係（`requirements.txt）`

分散エージェントを使用する理由（フロントエンドチームに感謝される理由）

ステップ 4: オーケストレーターパターン

プロダクションレディな AI エージェントに関するデベロッパーガイド

RAG 対応生成 AI アプリケーションのプライベートネットワーク接続の設計

トラフィックフロー

短期、中期、長期の履歴に対応するポリグロットストレージアプローチ

ポリグロットアプローチとは

戦略的転換: コンテキストエンジンとしてのデータベース

3. ソブリンインテリジェンスと行レベルセキュリティ（RLS）

ステップ 3: ストリーミングチャットループを作成する

データモデリングサーバー mcp-neo4j-data-modeling の使用

モデル適応をマスターする: Google Cloud でのファインチューニングガイド

試験運用からプロダクションレディなアーキテクチャへの移行

担当者のソーシャルメディア