アプリケーション開発

Google が管理する MCP サーバーを使用してプロダクションレディな AI エージェントを構築する方法

Tue, 21 Apr 2026 00:00:00 +0000

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

デベロッパーがより高度な推論システムを使用した AI エージェントを構築するのに伴い、真のビジネス価値を推進するために、より高品質な燃料として、エンタープライズデータと専用ツールが必要になります。このオクタン価の高い組み合わせを最大限に活用するために、Google は Google が管理する Model Context Protocol（MCP）サーバーを提供しています。これは、AI エージェントが Google および Google Cloud サービスと安全にやり取りするために構築されたエンジンです。

これらの Google がホストするフルマネージドエンドポイントにより、AI エージェントは Google マップ、BigQuery、Google Kubernetes Engine、Cloud Run、その他多くの Google サービスと通信できます。AI エージェントを大胆に構築するにあたっては、責任を持って構築することも重要です。

このガイドでは、Google のマネージド MCP サーバーでエージェントを安全に構築する方法を説明します。

Google が管理する MCP サーバーを使用する理由

ローカルでのテストからエンタープライズグレードの AI に移行するには、スケーリングと監視を優先する堅牢なマネージドインフラストラクチャを採用する必要があります。主なメリットは次のとおりです。

本番環境への準備: オープンソースの MCP サーバーはローカルでの開発には最適ですが、本番環境ではスケーラビリティ、単一障害点、管理オーバーヘッドの問題が生じます。Google のマネージド MCP サーバーでは、Google がホスティング、スケーリング、セキュリティに対応するため、インフラストラクチャのプロビジョニングは不要です。
統合された検出機能: シンプルなディレクトリサービスを使用して、Google サービス（maps.googleapis.com/mcp など）で利用可能なすべての MCP エンドポイントを公開アクセスでクエリし、簡単に検出できます。
エンタープライズセキュリティ: Google MCP サーバーは、Cloud IAM、VPC-SC、Model Armor などの Google Cloud セキュリティスタックとネイティブに統合されています。
統合されたオブザーバビリティと監査機能: Google MCP サーバーは Cloud Audit Logs と統合されており、すべてのツール呼び出しアクティビティを一元的に表示できます。これにより、プラットフォームチームは、単一のエンタープライズグレードのロギングペインを通じて、エージェントのパフォーマンスのモニタリング、コンプライアンスの確保、インタラクションのトラブルシューティングを行うことができます。

図 1: Google MCP サーバーのアーキテクチャ概要図

ADK と Google MCP サーバーを使用する AI エージェントの例

Cityscape は、Google の Application Development Kit（ADK）を使用して構築されたデモエージェントです。「京都の景観を生成して」のようなシンプルなテキストプロンプトを、AI が生成した独自の都市画像に変換します。信頼できる場所情報には Google Maps Grounding Lite によって管理される MCP サーバーを使用し、画像生成には Nano Banana モデル（ローカル MCP サーバー経由）を使用します。

この軽量アプリは、サーバーレスランタイムである Google Cloud Run に簡単にデプロイされ、ユーザーとやり取りします。以下は、エージェントがローカルのリアルタイムの気象状況に基づいて生成した 2 つの画像の例です。

図 2: リアルタイムの天気情報を使用して Cityscape エージェントが生成した画像の例

1. ADK エージェントから Google MCP サーバーを呼び出す:

下の get_weather コードスニペットで示されているように、Cityscape エージェントはストリーミング可能な HTTP エンドポイントを利用して、Google マップ MCP サーバーとやり取りします。このサーバーは、指定された都市のリアルタイムの気象状況をエージェントに提供します。提供されたデータは、生成された都市景観画像に天候を設定するために使用されます。

これは Google が管理するリモート MCP サーバーであるため、Google がホスティング、スケーリング、セキュリティに対応します。そのため、エージェントは、あらゆるトラフィックレベルに対応する自動スケーリング、Google の本番環境インフラストラクチャによる組み込みの信頼性、エンタープライズグレードのセキュリティといったメリットをすぐに活用できます。ユーザーが管理するインフラストラクチャはありません。以下のようにマップ URL を指定し、API キーで認証するだけです。本番環境へのデプロイに最適です。

code_block: <ListValue: [StructValue([('code', '# Remote Google MCP server: connects to Google Maps Grounding Lite \r\n# to fetch real-time weather conditions for a given city.\r\nget_weather = McpToolset(\r\n connection_params=StreamableHTTPConnectionParams(\r\n url="https://mapstools.googleapis.com/mcp",\r\n headers={"X-Goog-Api-Key": os.environ["MAPS_API_KEY"] }\r\n ),\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9be95ac7f0>)])]>

Google Maps Grounding Lite は Google が管理するリモートエンドポイントですが、Cityscape エージェントは、画像生成のためにローカルでホストされる MCP サーバーという、対局的な例も示しています。nano_banana ツールセットは、StdioConnectionParams を使用して GenMedia MCP サーバーに接続します。

この設定により、エージェントは、先ほど収集したランドマークと天候のデータを取り込んで、デザイン化されたアイソメトリックな都市景観画像を生成します。自己ホスト型 MCP サーバーを実行すると、プロセスのライフサイクルと環境構成を完全に制御できますが、ホストマシンまたはサイドカーコンテナにローカルバイナリが必要になるため、ホスト型アプローチと比較して設定が複雑になります。

code_block: <ListValue: [StructValue([('code', '# Self-hosted MCP server: launches the GenMedia MCP server (mcp-gemini-go)\r\n# as a subprocess to generate cityscape images via the Gemini image model.\r\nnano_banana = McpToolset(\r\n connection_params=StdioConnectionParams(\r\n server_params=StdioServerParameters(\r\n command="mcp-gemini-go",\r\n env=dict(os.environ, PROJECT_ID=os.environ["GOOGLE_CLOUD_PROJECT"]),\r\n ),\r\n timeout=60,\r\n ),\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9be95ac0d0>)])]>

ADK は、Google が管理する MCP サーバー、リモート MCP サーバー、自己ホスト型 MCP サーバーをサポートしています。Google が管理する MCP サーバーは運用オーバーヘッドがゼロの、プロダクションレディなインフラストラクチャを提供し、リモート MCP サーバーと自己ホスト型 MCP サーバーはカスタムツールや試験的なツールに対する柔軟性を提供します。

2. エンタープライズグレードのセキュリティとコンテンツのガードレール

エージェントの時代において、セキュリティは後回しにできません。2 つの主要なセキュリティ機能を Cityscape エージェントに適用する方法をご紹介します。

IAM 拒否ポリシーによる MCP ツールのきめ細かい制御

Google Cloud では、IAM 拒否ポリシーを使用して MCP ツールへのアクセスを制御できます。これは、他の Google Cloud リソースですでに使用しているガバナンスフレームワークと同じです。

たとえば、過去の都市景観メタデータや人口統計のデータセットをクエリするために、BigQuery MCP サーバーを追加して Cityscape エージェントを拡張するとしましょう。BigQuery MCP サーバーは、get_dataset_info や list_datasets などの読み取り専用ツールと、データを変更できる execute_sql などの書き込みツールの両方を公開します。

このユースケースでは、エージェントは BigQuery に情報をクエリするだけで、データの挿入、更新、削除を行う SQL を実行してはなりません。Google が管理する MCP サーバーを使用する場合、プロンプトエンジニアリングだけに頼ってこれを適用する必要はありません。

代わりに、読み取り専用としてアノテーションが付けられていないツールをブロックする IAM 拒否ポリシーを適用します。

code_block: <ListValue: [StructValue([('code', '// IAM deny policy: blocks all MCP tool calls that are not read-only.\r\n{\r\n "rules": [\r\n {\r\n "denyRule": {\r\n "deniedPrincipals": ["principalSet://goog/public:all"],\r\n "deniedPermissions": ["mcp.googleapis.com/tools.call"],\r\n "denialCondition": {\r\n "title": "Deny read-write tools",\r\n "expression": "api.getAttribute(\'mcp.googleapis.com/tool.isReadOnly\', false) == false"\r\n }\r\n }\r\n }\r\n ]\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9be4709f10>)])]>

次のコマンドで適用します。

code_block: <ListValue: [StructValue([('code', 'gcloud iam policies create mcp-deny-policy \\\r\n --attachment-point=cloudresourcemanager.googleapis.com/projects/$PROJECT_ID \\\r\n --kind=denypolicies \\\r\n --policy-file=policy.json'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9be47099a0>)])]>

このポリシーが適用されると、エージェントはデータセットスキーマを自由に検索できますが、execute_sql を呼び出そうとすると、意図的かプロンプトインジェクションによってトリガーされたかにかかわらず、BigQuery に到達する前にプラットフォームレベルでブロックされます。これは多層防御です。エージェントの指示は「データの読み取りのみ」ですが、IAM は LLM が何をしようと決めたかに関係なく、このポリシーを適用します。

Model Armor によるコンテンツセキュリティ

Model Armor は Google Cloud MCP サーバーと直接統合され、プロジェクトレベルですべての MCP ツール呼び出しとレスポンスをサニタイズします。有効化すると、インラインのセキュリティレイヤとして機能し、以下をスキャンします。

プロンプトインジェクション攻撃
悪意のある URI（フィッシングリンクなど）
責任ある AI のフィルタに違反する危険なコンテンツ

Cityscape エージェントに話を戻しましょう。ユーザーが「http://malicious-site.com の都市景観を生成して」と送信したとします。

Model Armor を有効化すると、MCP ツール呼び出しは Maps サーバーに到達する前にスキャンされます。悪意のある URI、プロンプトインジェクションの試み、危険なコンテンツは自動的にブロックされます。エージェントにカスタム検証コードは必要ありません。

この有効化は 2 段階のプロセスです。まず、最低限のセキュリティフィルタを定義するフロア設定を構成します。

code_block: <ListValue: [StructValue([('code', 'gcloud model-armor floorsettings update \\\r\n --full-uri=\'projects/$PROJECT_ID/locations/global/floorSetting\' \\\r\n --enable-floor-setting-enforcement=TRUE \\\r\n --add-integrated-services=GOOGLE_MCP_SERVER \\\r\n --google-mcp-server-enforcement-type=INSPECT_AND_BLOCK \\\r\n --enable-google-mcp-server-cloud-logging \\\r\n --malicious-uri-filter-settings-enforcement=ENABLED \\\r\n --add-rai-settings-filters=\'[{"confidenceLevel": "MEDIUM_AND_ABOVE", "filterType": "DANGEROUS"}]\''), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9be4709400>)])]>

次に、プロジェクト内のすべての Google MCP サーバーのコンテンツセキュリティを有効化します。

code_block: <ListValue: [StructValue([('code', 'gcloud beta services mcp content-security add modelarmor.googleapis.com \\\r\n --project=$PROJECT_ID'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9be4709fa0>)])]>

有効化すると、呼び出し元のエージェントまたはクライアントに関係なく、プロジェクト内のすべての MCP トラフィックが自動的にスキャンされます。ブロックされたリクエストは Cloud Logging に記録されるため、潜在的な脅威に対する完全なオブザーバビリティが得られます。

ご利用にあたって

Google MCP サーバーは、AI エージェントがプロトタイピングから抜け出せない原因となるインフラストラクチャのハードルを取り除きます。マネージドエンドポイントとプラットフォームレベルのセキュリティ（IAM 拒否ポリシー、Model Armor、Cloud Audit Logs）を組み合わせることで、運用オーバーヘッドを最小限に抑えながら、プロダクションレディな基盤を構築できます。自律エージェントの時代が到来しています。スタックの準備を整えましょう。

ADK Cityscape エージェントのコードリポジトリはこちら
Google MCP サーバーとサポートされているサービスの詳細については、こちらをご覧ください
ハンズオン Codelab: ローカルからクラウドへの移行 - Gemini CLI、Cloud Run、Cloud SQL MCP サーバーを使用したフルスタックアプリの移行
Google Cloud Run で AI エージェントを構築: エージェント型 AI アプリケーション向けのサーバーレスランタイム

- Google Cloud、プロダクトマネージャー、 Lisa Shen

- Google Cloud、ソリューションリード、 Daniel Strebel

一元化されたポリシーと分散ロジック: Eventarc Advanced の概要

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

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

エンタープライズアーキテクトは、開発者のアジリティと組織の管理のどちらを優先するかという根本的なジレンマに直面することがよくあります。開発チームは、迅速に作業し、許可を待つことなく独立したマイクロサービスをデプロイする必要があります。セキュリティチームとコンプライアンスチームは安全を確保し、データフローが可視化され、ポリシーによって管理されるようにする必要があります。

そこで、Google はサーバーレスのイベント処理プラットフォームである Eventarc Advanced を構築しました。これは Eventarc Standard の進化版です。Eventarc Advanced は、一元化されたポリシーと分散されたロジックを組み合わせることで、最新のクラウド向けに改善されたアーキテクチャパターンを提供します。Eventarc Advanced では、ガバナンスレイヤ（「バス」）と処理レイヤ（「パイプライン」）を明確に分離することで、SecOps チームが求める可視性と制御を実現する一方で、開発者が AI エージェントを調整してイベントドリブンアプリケーションを自律的に構築できるようにしています。Eventarc Advanced は 2025 年 8 月に一般提供されました。

この投稿では、インテグレーションアーキテクチャの変遷（サービスバスから、マイクロサービス、現在に至るまで）について見ていくとともに、実例を挙げながら解説します。それでは詳しく見ていきましょう。

インテグレーションアーキテクチャの進化

新しいパターンの価値を理解するために、これまでの経緯と、以前のアーキテクチャパターンで妥協を余儀なくされた点について確認しておきましょう。

エンタープライズサービスバスにおける集中的なボトルネック

インテグレーションアーキテクチャの初期のアプローチの一つに、エンタープライズサービスバス（ESB）があり、これは、一元管理を優先していました。ESB は、ポイントツーポイントのインテグレーションにおける「スパゲッティアーキテクチャ」を解決するために登場しました。具体的には、異種システム間のやり取りを標準化する一元化された通信レイヤを提供します。しかし、多くの場合、重大な落とし穴がありました。

主な問題は、一元化されたロジックのトラップと呼ばれるものです。変換やオーケストレーションなどの複雑なビジネスロジックがガバナンスレイヤに直接埋め込まれることが多く、その結果、ミドルウェアレイヤが不透明になり、サービスを所有する開発者側から重要なビジネスルールが見えない状態になりました。

そのため、インテグレーションの変更に、中央のミドルウェアチームが介入しなければならないのが一般的でした。開発チームは自律性を失い、インテグレーションスペシャリストの順番待ちを強いられ、小さな機能でさえリリースに数週間かかることがよくありました。

マイクロサービスのガバナンスの盲点

これに対処するため、業界はマイクロサービス（通称「スマートエンドポイントとダムパイプ」）へと移行し、ロジックを分散してチームが求めていた自律性を実現しました。同期トラフィック（REST、gRPC）では、API ゲートウェイやサービスメッシュなどのツールによってインフラストラクチャレベルで認証やレート制限などのポリシーを適用することで、ガバナンスレイヤを復元できます。

しかし、アーキテクチャがレジリエンスと分離を強化するためにイベントドリブンアーキテクチャ（EDA）へと移行するにつれ、新たな課題が生じました。分散された非同期環境では、一元管理が失われることがよくあり、SecOps チームが秩序を維持するのに苦労するというガバナンス上の課題が生まれたのです。問題となったのは、以下の 3 点です。

可視性の欠如: 一元的なポリシーがないと、シャドー IT サービスが検出されずに機密性の高いイベントをひそかにサブスクライブする可能性があります。
ポリシーの問題: ブローカーが個々のメッセージを不透明な blob として扱う場合、データ所在地や PII マスキングを適用することはほぼ不可能です。
依存関係のリスク: 明示的な取り決めなしにイベントスキーマを変更すると、ダウンストリーム側の不明なコンシューマーがいつのまにか破損されるリスクがあります。

新しいパターン: ポリシーは一元化、ロジックは分散

Eventarc Advanced は、一元化されたポリシーと分散ロジックという新しいアーキテクチャパターンにより、制御とスピードの両立という課題に対処しています。

Eventarc Advanced では、これらの異なる責任を 2 つの特定のアーキテクチャリソースにマッピングします。各リソースはそれぞれ、以下の異なるロールに対応しています。

バス: このガバナンスレイヤは、イベントがルーティングされる前にプラットフォーム管理者がグローバルな制約を適用する、一元管理用のハブです。これは、従来の ESB の一元化されたルーティングと、サービスメッシュの最新のセキュリティアーキテクチャを統合したものです。Identity and Access Management（IAM）やそのコンテンツベースのアクセス制御を処理し、誰にパブリッシュを許可するかを厳密に定義して、VPC Service Controls と連携しながらデータ引き出しを防止できます。
パイプライン: この分散型のチーム所有リソースは、いわば、開発者のインテグレーションロジックレイヤです。このレイヤで、AI エージェントとマイクロサービスのイベント処理パターンが自由に解放され、開発者は特定のビジネスロジックに従ってイベントフローと配信を構成できます。データを不透明なビットとして扱う多くのサービスメッシュとは異なり、このパイプラインはコンテンツを理解します。開発者は、イベントの変換、ペイロードの形式変換（JSON から Avro など）、再試行ポリシーおよび認証の構成を独立して行うことができます。

つまり、Eventarc Advanced はこれらの役割を分離することで、ESB の制御、マイクロサービスのアジリティ、最新型のイベントドリブンアーキテクチャのレジリエンスをすべて実現しています。

仕組み: 小売業のイベントメッシュの例

一般的な Eventarc Advanced ソリューションは最小限の構成で実装でき、管理ガバナンスと分散インテグレーションロジックの両方で合理化されたエクスペリエンスを提供します。このモデルが実際にどのように機能するかを、小売業のイベントメッシュの事例で見てみましょう。

例として、グローバルな小売業者のエコシステムについて考えます。4 つの自律的な部門があり、それぞれ以下のサービスを担当しています。

コマース

財務

物流

インテリジェンス（AI インサイトエージェント）

従来の方法では、これらの部門を連携させるのは困難です。インテリジェンス部門はモデルの全データにアクセスしたいと考えます。一方、財務部門はコンプライアンスのためにすべてのデータをロックする必要があります。物流チームは出荷のために安定したスキーマを求めています。コマース部門は新しい機能を即座にリリースする必要があります。

基盤: CloudEvents 上に構築

Eventarc Advanced は、オープンな CloudEvents 標準に基づくデータモデルを使用しており、あらゆる種類のペイロードに対応できます。そのため、柔軟性を維持しながら、ガバナンスおよび検出可能性を確保することが可能です。この例では、プラットフォーム管理者によって、単一イベントをパブリッシュする前に、すべてのメッセージに標準属性およびガバナンス用のカスタム拡張属性を含めることが義務付けられているものとします。

この例では、バス上のすべてのイベントに次の属性を含める必要があります。

type: イベントインスタンスの標準識別子（例: com.retail.order.created）
source: プロデューサーを識別する標準属性（例: //commerce/frontend）
data_sensitivity: リスクを分類するカスタム拡張属性

さらに、この組織では 3 種類のデータ機密性レベルを定義しています。

restricted （高）: クレジットカードのトークンや納税者番号などの高リスクデータ
confidential （中）: 自宅住所などの個人情報（PII）
general （低）: 注文 ID などの安全な運用データ

この標準化されたメタデータレイヤにより、特定の属性名に基づいてバスからポリシーを適用することが可能となります。具体的には、データの送信元（source）とデータの種類（data_sensitivity）をチェックできます。

ワークフロー

このモデルは、単一の注文のライフサイクルにおいて、機密性がステップごとに変化する安全なフローとなります。

注文: Commerce（コマース）サービスが order.created をバスにパブリッシュします。このイベントのデータ機密性は general とタグ付けされています。AI Insights Agent（AI インサイトエージェント）サービスは、市場のトレンドを分析するために、この情報をサブスクライブします。
支払い認証: Commerce サービスが payment.authorized をパブリッシュし、restricted タグを付けます（セキュアトークンが含まれます）。Finance（財務）サービスが、このトークン取得をサブスクライブして、請求処理を実行します。
決済: Finance サービスが payment.success をパブリッシュし、general タグを付けます。これが、出荷に進んでよいという合図になり、財務上の機密情報は隠されたままになります。Logistics（物流）が出荷のためにこれをサブスクライブします。また、Intelligence AI Insights Agent（インテリジェンス AI インサイトエージェント）がトリガーされて、次のサプライチェーンサイクルの市場動向を評価します。
出荷: Logistics サービスが shipment.ready をパブリッシュし、confidential タグを付けます（お客様の電話番号が含まれます）。Logistics が自らの通知パイプラインによってこれをサブスクライブし、SMS 通知をトリガーします。

従来のアーキテクチャだと、PCI、PII、運用のデータが単一バスに混在し、コンプライアンスの面で非常に複雑になりますが、Eventarc Advanced を使用すれば、この問題は解決します。

バス: ガバナンスレイヤ

プラットフォーム管理者は、バスに安全な戦略を実装できます。たとえば、内部サービスをむやみに信頼するのではなく、グローバルポリシーによってきめ細かなアクセス制御（FGAC）を適用し、CloudEvents 属性を検査することができます。

ソースの整合性の検証

サービスの侵害によるイベントのスプーフィングを防ぐため、バス管理者は、プロデューサー ID とソース属性の一致を求めます。

たとえば、プリンシパル sa-commerce@retail.com のみに、message.source.startsWith("//commerce/") という表記に一致するイベントのパブリッシュを許可するようにバスポリシーを設定できます。仮に Intelligence AI Insights Agent サービスが //commerce/payments からであると偽ってイベントをパブリッシュしようとすると、バスはこのリクエストを拒否します。

データ分類の検証

バス管理者は、すべてのイベントを機密性に基づいて分類できるようにするために、バスに送られるすべてのペイロードに有効な機密性属性を求めます。バスポリシーに、message.data_sensitivity が ['general', 'confidential', 'restricted'] のいずれかであるかどうかを検証するよう指定できます。これにより、イベントメッシュにはガバナンス対応の分類済みデータのみが確実に含まれるようになります。

パイプライン: ロジックレイヤと、自律的なチームのイノベーション

バスでセキュリティポスチャーを確立する一方で、開発チームはパイプラインを使用し、複雑なインテグレーションの課題を独自のドメイン内で解決できます。具体的にどんな課題があるのかを見てみましょう。

スキーマに対応した形式変換とペイロードの変換

物流部門は、高効率のプロトコルバッファを使って倉庫ロボットをアップグレードすることにしました。財務部門に JSON 出力の変更を強制すると、他のコンシューマーが壊れる可能性があるため、その代わりに、物流部門が独自のパイプラインを使って変換ステップを構成できます。

財務部門からの一般的な com.retail.payment.success イベントは、次のような JSON として届きます。

code_block: <ListValue: [StructValue([('code', '{\r\n "id": "89d5663e-789e-4d9f-a65f-f7d83742d987",\r\n "source": "//finance/ledger",\r\n "type": "com.retail.payment.success",\r\n "data_sensitivity": "general",\r\n "datacontenttype": "application/json",\r\n "data": {\r\n "order_number": "ORD-2023-8841",\r\n "total_amount": 249.99,\r\n "currency": "USD",\r\n "transaction_id": "tx_77382910",\r\n "status": "SETTLED"\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9be75dcdc0>)])]>

倉庫ロボットサービスは、次のようなバイナリの Protobuf メッセージを想定しています。

code_block: <ListValue: [StructValue([('code', 'message PaymentConfirmed {\r\n string order_id = 1;\r\n double insured_value = 2;\r\n string currency_code = 3;\r\n string ledger_reference = 4;\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9be9463160>)])]>

物流部門は、json を入力として受け付け、Protobuf に出力するようにパイプラインを構成します。データをマッピングするために、以下のように Common Expression Language（CEL） を使って変換を構成しています。

code_block: <ListValue: [StructValue([('code', '// CEL 変換によって、ターゲットの Protobuf メッセージを構築\r\n{\r\n "order_id": message.data.order_number,\r\n // 交換費用をカバーするため、総額の 110% にする\r\n "insured_value": message.data.total_amount * 1.1,\r\n // 通貨を大文字に統一\r\n "currency_code": message.data.currency.upperAscii(),\r\n "ledger_reference": message.data.transaction_id,\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9be79459a0>)])]>

この変換では、入力のマッピングだけでなく、ビジネスロジックも適用され、保険適用後の金額計算と通貨コードの正規化が行われています。物流部門は、財務部門と打ち合わせを一切することなく、このモダナイゼーションを実装できます。

エージェントのワークフロー: AI エージェントのフィルタとトリガー

Eventarc Advanced では、Agent2Agent（A2A）や Model Context Protocol（MCP）などのオープンスタンダードプロトコルを使って、パイプラインが AI エージェントと直接通信できるようにし、エージェントのワークフローを実現しています。また、フィルタなどの豊富な機能もあり、エージェントの呼び出しタイミングを最適化できます。

インテリジェンス部門は、ai-insights と名付けたパイプラインと A2A プロトコルを使用して AI インサイトエージェントに接続し、注文に基づいて市場動向をプロアクティブに分析してもらえます。エージェントの処理はリソースを大量に消費するため、フィルタを使用して、詳細な分析が必要な高額注文に対してのみエージェントを呼び出すことができます。

パイプラインフィルタを、次のように構成します。

code_block: <ListValue: [StructValue([('code', 'message.type == "order.created" && \r\ndouble(message.amount) > 5000.0'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9be7ccb790>)])]>

フィルタが渡されると、パイプラインは HTTP Message Destination Binding（MDB）の構文を使ってエージェントを直接トリガーします。CEL テンプレートを定義することによって、ネイティブな A2A SendMessage リクエストを構築して戦略担当の AI インサイトエージェントに送るという複雑な処理をパイプラインで行えます。これにより、手動で「グルーコード」を作成することなく、複雑なイベントデータから派生した会話型プロンプトをエージェントに送信することができます。

code_block: <ListValue: [StructValue([('code', '{\r\n "headers": headers.merge({ "Content-Type": "application/json", "A2A-Version": "1.0" }),\r\n "body": {\r\n "jsonrpc": "2.0",\r\n "id": message.id,\r\n "method": "message/send",\r\n "params": {\r\n "message": {\r\n "messageId": message.id,\r\n "role": "ROLE_USER",\r\n "parts": [\r\n { \r\n "text": "Analyze Order " + message.data.order_number + " for market trends." \r\n }\r\n ]\r\n }\r\n }\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9be6da4bb0>)])]>

MCP などの他の一般的なエージェント通信プロトコルでも、同様のプロンプトメッセージを作成できます。

フィルタとエージェントプロトコル変換を組み合わせることで、AI リソースを本当に必要な場面で有効利用することが可能となります。インテリジェンス部門は、取り込みコードを記述したり、コマース部門や管理部門と調整したりすることなく、独自にこれを実装できます。さらに、エージェントが独自の戦略的推奨事項をバスにパブリッシュし、AI の知見を適宜活用できるようにすることで、一般的なクラウドイベントが競争に役立つインテリジェンスへと生まれ変わります。

高度な API リクエストモデリング

出荷の準備が整うと、物流部門はパイプラインからレガシーのゲートウェイ API を使って SMS を送信します。サードパーティのレガシー API と統合するためには、リクエストの書式設定のために、「グルーコード」サービスの記述が必要となるのが一般的です。

物流部門は、レガシーサービスが想定しているリクエストを正確に記述するために専用のパイプラインを構成することで、このメンテナンスの負担を解消しています。

具体的には、HTTP Message Destination Binding の CEL 構文を使って、電話番号を標準化し、API で必須の X-SMS-To HTTP ヘッダーにマッピングします。また、以下のように SMS テキストも作成します。

code_block: <ListValue: [StructValue([('code', '{\r\n "headers": { "X-SMS-To", \r\n message.data.phone.matches(\'^\\\\+1\') ?\r\n message.data.phone : \r\n \'+1\' + message.data.phone \r\n },\r\n\r\n "body": {\r\n "sms_text": "Order " + message.data.order_id + " shipped!"\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9be6da4d00>)])]>

最後に、パイプラインに直接、堅牢な再試行ポリシー（線形バックオフ、最大 5 回の試行）を構成して、一時的なネットワーク中断によって通知が失われないようにします。このパイプラインは、確実な配信を実現するほか、すぐに使える認証を提供します。宛先として、HTTP エンドポイントのほか、Cloud Run、Pub/Sub、バス、ワークフローや、200 以上の Google サービスがサポートされています。

アジャイルなインテグレーションに向けた未来

Eventarc Advanced は、一元化ポリシー、分散型ロジックのパターンを導入することで、イベントドリブンアーキテクチャにおける重要な盲点に対処し、非同期通信において同期通信と同レベルの成熟度を達成しています。

プラットフォームチームは、バスですべてのメッセージに整合性と機密性を厳格に適用することで、あたかもサービスメッシュのようなセキュリティをイベントレイヤに導入できます。
開発者は、自律性を取り戻せます。パイプラインを使って、特定のニーズに応じてイベントをフィルタ、変換、形式変換、ルーティングできるため、イベントを不透明なアーティファクトではなく、重要な産物として扱うことが可能となります。

このアーキテクチャは、次世代のインテリジェントアプリケーションの基盤となります。安全で定型化された、信頼できるイベントメッシュは、生成 AI エージェントおよびリアルタイム分析の基軸となり、ビジネスコンテキストを必要とするシステムに安全に公開することが可能となります。

使ってみる

ガバナンスに足を引っ張られることなく、イノベーションを促進しましょう。Eventarc Advanced の使用を開始するにあたっては、以下のリソースをご利用ください。

詳細: Eventarc Advanced のドキュメントで、バスとパイプラインの全機能をご確認ください。
実践: 「小売業のイベントメッシュ」のシナリオを自分でデプロイしてみましょう。また、クイックスタートとチュートリアルでエンタープライズのパターンについて理解を深められます。
構築してみる: Google Cloud コンソールを開き、初めてのバスとパイプラインをさっそく構成してみましょう。
ご相談ください: 複雑なエンタープライズユースケースがおありですか？Google Cloud の営業担当者までお問い合わせください。Eventarc Advanced がお客様の広範なインテグレーション戦略にどのように役立つかについて、ご説明させていただきます。

- スタッフソフトウェアエンジニア、Milen Kovachev

Google Cloud データベースで次世代のエージェントを強化する

Thu, 26 Feb 2026 03:00:00 +0000

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

カスタムエージェントや chatbot などの AI アプリケーションを構築する開発者は、オープンソースの Model Context Protocol（MCP）標準により、作成したイノベーションがデータやツールに一貫性のある方法で安全にアクセスできるようにすることができます。Google は 2025 年末、Google マップや BigQuery などのサービス向けにマネージドおよびリモート MCP のサポートを導入することで、AI がツールに接続するための標準的な方法を確立し、アプリケーションのユニバーサルインターフェースを効果的に作成しました。このたび、このサービスを拡張し、PostgreSQL（AlloyDB、Spanner、Cloud SQL）と、高パフォーマンスの NoSQL ワークロード向けの Firestore および Bigtable を追加しました。また、IDE を Google のドキュメントに接続する API を備えた新しい Developer Knowledge MCP サーバーも導入します。これらのサーバーは Google Cloud で実行され、Gemini やその他の MCP 準拠のクライアントがデータやインフラストラクチャと簡単にやり取りできる安全なインターフェースを提供します。

Gemini 3 のリリースにより、開発者は高度な推論機能を利用して、複雑な問題を計画、構築、解決できるようになりました。しかし、AI モデルが有用な「エージェント」として機能するには、信頼できる方法で環境とやり取りする必要があります。今回の発表は、これらの機能を、お客様が作業環境のバックボーンとして日常的に利用しているデータベースツールにまで幅広く拡張するものです。

エージェントをこれらのサーバーに接続するために、インフラストラクチャをデプロイする必要はありません。エージェント構成で MCP サーバーエンドポイントを構成するだけで、エンタープライズグレードの監査、オブザーバビリティ、ガバナンスに裏付けられた運用データに即座にアクセスできます。インフラストラクチャの管理が不要なため、運用上のオーバーヘッドを発生させることなく、エージェントのワークロードをスケーリングできます。

エージェントに運用データを提供

これらの新しいマネージドサーバーにより、エージェントは Google のポートフォリオ全体で特定の機能にアクセスできるようになります。

AlloyDB for PostgreSQL: エージェントは PostgreSQL ワークロードとやり取りして、スキーマの作成、複雑なクエリの遅延の診断、ベクトル類似性検索の実行などのタスクを可能にします。
Spanner: Spanner の統合マルチモデル機能（Spanner Graph など）を使用すると、エージェントは標準（SQL および GQL）クエリを使用し、リレーショナルデータやセマンティックデータと並行して複雑な関係をモデル化およびクエリできます。これにより、エージェントは MCP ツールを自由に使用して、詐欺組織の特定や商品のレコメンデーション生成など、深い分析情報を迅速に発見できます。
Cloud SQL for PostgreSQL、MySQL、SQL Server: 開発者とデータベース管理者は、MySQL、PostgreSQL、SQL Server のフリート全体で Cloud SQL MCP Server を使用し、データベースとの自然言語でのやり取り、AI によるアプリ開発の支援、クエリパフォーマンスの最適化、エージェントによるデータベースのトラブルシューティングを行うことができます。
Bigtable: Bigtable の柔軟なスキーマと高スループットの取り込み機能は、デジタル統合ハブの構築や時系列データの管理によく使用されます。MCP を使用すると、運用ワークフローの自動化が簡素化され、カスタマーサポート、CRM、人事、IT 運用、サプライチェーン、ロジスティクス分野でこのデータを使用したエージェントアプリケーションを開発しやすくなります。
Firestore: モバイルとウェブの開発に重点を置いた Firestore MCP サーバーにより、エージェントはライブドキュメントコレクションと同期できます。その結果、自然言語プロンプトを介してユーザーセッションの状態を確認したり、注文状況を確認したりするなどの動的なインタラクションがサポートされます。

アプリケーションとインフラストラクチャの管理

Google は、エージェントがデータの取得だけでなく、アプリケーションの構築と管理を支援できるようにしています。Developer Knowledge MCP サーバーは、IDE を Google のドキュメントに接続し、エージェントが関連性の高いコンテキストを使用して技術的な質問に答えたり、コードのトラブルシューティングを行ったりできるようにします。

セキュリティとガバナンス

エージェントをデータベースに接続するには、堅牢なセキュリティとガバナンスが必要です。これらのサーバーは、Google Cloud の標準的な ID およびオブザーバビリティフレームワークに基づいて構築されています。

ID ファーストのセキュリティ: 認証はすべて、共有キーではなく、Identity and Access Management（IAM）を通じて処理されます。これにより、エージェントはユーザーが明示的に承認した特定のテーブルまたはビューにのみアクセスできるようになります。
完全なオブザーバビリティ: エージェントのアクティビティを追跡できるように、これらの MCP サーバーを介して行われたすべてのクエリとアクションは Cloud Audit Logs に記録されます。これにより、セキュリティチームはすべてのデータベース操作の記録を取得し、可視性を維持しながら簡単にアクセスできます。

デモ: ローカルコードからマネージドデータへ

新しい MCP サーバーの動作例を見てみましょう。

フィットネスコミュニティ向けのフルスタックイベント管理プラットフォームの移行を自動化するエージェントを想像してみてください。Gemini CLI で一連の自然言語の指示を使用することにより、エージェントは Cloud SQL リモート MCP サーバーを利用して、マネージド PostgreSQL インスタンスをプロビジョニングし、正しいスキーマを適用して、ローカルデータを安全に移行します。複雑な gcloud コマンドを習得したり、Cloud SQL のエキスパートになったりする必要はありません。面倒な作業はエージェントが行います。この移行は、Developer Knowledge MCP サーバーが公式ドキュメントを参照してエージェントをベストプラクティスに導くことによって、リアルタイムで設計されます。その結果、アプリケーションのバックボーンがローカルストレージからフルマネージドのエンタープライズデータベースに簡単にアップグレードされます。

サードパーティエージェントのサポート

これらのサーバーはオープンな MCP 標準に準拠しているため、お気に入りの AI エージェントとも連携できます。設定でカスタムコネクタを追加することで、Anthropic の Claude などのクライアントを簡単に接続できます。Google Cloud データベースの MCP エンドポイントを指定するだけで、すぐに構築を開始できます。複雑な構成ファイルはいりません。

次のステップ

今後数か月以内に、Looker、Database Migration Service（DMS）、BigQuery Migration Service、Memorystore、データベースセンター、Pub/Sub、Kafka などのマネージド MCP サポートが追加され、このエコシステムはさらに拡大する予定です。

安全なデータドリブンエージェントの構築を開始するには、AlloyDB、Spanner、Cloud SQL、Bigtable、Firestore のガイドをご覧ください。Cloud SQL と Spanner の Codelab や、Google Cloud へのアプリの移行手順について説明するこちらのデモ動画もご覧ください。

- AI およびデータベース担当バイスプレジデント、Amit Ganesh

- データベース向け AI 担当シニアプロダクトマネージャー、Rahul Deshmukh

プラットフォーム使用の落とし穴（パート 1）: アクティビティの多さが必ずしも価値の高さを示すとは限らない理由

Fri, 13 Feb 2026 01:00:00 +0000

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

社内デベロッパープラットフォームに投資した組織では、必ず「実際に機能しているのか？」という疑問が生じます。

導入率を追跡するだけでは、プラットフォームがデベロッパーに真の価値をもたらしているかどうかはわかりません。英国の大手小売業者である John Lewis も、この課題に直面していました。これまでの記事（パート 1 とパート 2）では、John Lewis Digital Platform（JLDP）が数十のプロダクトチームによる高品質なソフトウェアの迅速な構築を可能にし、www.johnlewis.com やその他の重要なアプリケーションを強化した方法を紹介しました。しかし、このプラットフォームが実際に成功を収めたことはどのようにしてわかったのでしょうか？収益や販売などの従来のプロダクト指標をこの分野にそのまま当てはめることはできません。テナントがプラットフォームを使用しているかどうかだけを重視していると、プラットフォームがテナントに価値をもたらしているかどうかを把握できません。

この記事では、John Lewis のプラットフォームチームの Alex Moss 氏が、単純な使用状況の指標から、プラットフォームの真の価値を測定するための洗練された多段階のアプローチを開発するまでの経緯について説明します。この取り組みは、リードタイムの指標から DORA、そして最終的には「技術的健全性」スコアへと発展しました。その過程で、JLDP の目的がどのように進化し、それとともにその価値がどのように高まってきたのかを探ります。- Darren Evans

最初の測定: プラットフォームの価値に焦点を当てる

プラットフォームの初期の頃は、その価値の把握は実際にははるかに簡単でした。これは、プラットフォームが非常に明確な目的、つまり変更の迅速化を実現するために作成されたからです。John Lewis のビジネス部門は、johnlewis.com の複数の機能を並行して開発する複数のプロダクトチームを編成し、それらの機能を顧客に迅速に提供してフィードバックを得たいと考えていました。

同社のオンラインビジネス「John Lewis Digital」の世界で生まれたため、非常に早い段階からプロダクトとして扱われ、その分野のレポートメカニズムとも統合されました。そのため、プラットフォームの目標をオンラインビジネスのより広範な目標に四半期ごとにリンクさせ、測定可能かつ主要な成果を報告することが標準になりました。これにより、このプラットフォームが重要とみなす理由に焦点を当てることができました。プラットフォームの改善は、別のプラットフォームを探すのではなく、そのプラットフォームを使用し続けることを正当化するものでしょうか？現状に満足してはなりません。

6 つの年間指標が四半期ごとに報告されています。具体的な対策は年々変化しました。

これに加えて、プラットフォームの最初の数年間は、プラットフォーム作成の根拠を最もよく示す 3 つのシンプルな指標がありました。

サービス作成のリードタイム: テナント（プロダクトチームがソフトウェアを作成するスペース）の作成にかかった時間
オンボーディングのリードタイム: プロダクトチームが本番環境にデプロイするのにかかった時間
最初の顧客までのリードタイム: プロダクトチームがサービスを「顧客向けに本稼働開始」するまでに要した時間

プラットフォームの自社作成サービスカタログの初期バージョンのスクリーンショット。前述の 3 つの指標を追跡

これをプラットフォームに存在するテナントの数と組み合わせてレポートを作成し、上記の初期の自社製サービスカタログの一部として表示しました（その後、Backstage に置き換えられました）。このレポートには 2 つの目的がありました。

プラットフォームの導入状況と、稼働開始までの時間（特に「サービス作成」は、従来チームが数週間待つ必要があったのに対し、1 桁の時間で測定）を、関係者向けに非常にわかりやすく可視化する。これは、プロダクトの初期段階では、継続的な成長を実証して投資を正当化する必要があるため重要です。
どのチームが本番環境への移行に時間をかけているかを、プラットフォームチーム自身（および関係者）が確認できるようにする。プロダクトは実際に役に立っているか？そうでない場合、他に何ができるか？

これをテナントとの会話のきっかけとして利用することで、プラットフォームの機能にいかせる豊富なフィードバックを得ることができました。テナントに「本稼働開始を妨げているものは何ですか？」と尋ねたところ、多くの場合、構築しているプロダクトが複雑すぎるという回答が返ってきました。しかし、独自のプロセスが妨げになっていることもよくありました。これは重要なことでした。これにより対策を講じることができたからです。

これらの障壁のうち、当社が最も簡単に克服できたのは、通常、技術関連のものでした。これまでの記事では、「チームが PubSub をプロビジョニングするために Terraform の記述に多くの時間を費やしている」と「Kubernetes の使用方法を学ぶのに苦労している」という 2 つの例を取り上げました。これに対処するため、プラットフォームチームは「Paved Road（舗装された道）」を作り、セルフサービスプロビジョニングや Kubernetes の簡素化を実現して、チームの負担を大幅に軽減しました。

新しいサービスを本番環境に移行する手順を合理化するためのより大きな機会は、当社のプロセス（セキュリティ承認など）に存在していました。プラットフォームがこのような組織機能を簡素化できるように強化されていれば、得られるメリットは非常に大きくなります。その一例が、情報セキュリティリスク保証プロセスです。必要なセキュリティ承認を得て、必要なドキュメントを作成する作業が必要でしたが、時間がかかりました。また、ビジネスの変化の速さから、多くのチームが並行してこの作業を行っていました。プラットフォームチームは、テナント向けの簡素化されたプロセスを交渉で獲得しました。これは、プラットフォームに常駐することで、セキュリティ管理が実施され、ポリシーが遵守されていることを保証できたからです。これは、このニーズを満たす機能をプラットフォームが構築し、それらの機能が使用されているという証拠を提示できたことから直接もたらされた結果です。これにより、テナントチームがこれをドキュメント化したり、独自に考案したりする必要がなくなりました。このソリューションは技術的な要素が少ないものですが、プラットフォームエンジニアリングを通じてデベロッパーのエクスペリエンスを簡素化しています。

会話の結果、プラットフォームの形をなさないフィードバックが得られることもありました。たとえば、機能フラグやダークローンチなどのコンセプト、あるいはレガシーシステムとの依存関係を解消するのに役立つソフトウェア設計オプションをチームが理解できるよう支援することなどです。John Lewis のプラットフォームチームには、経験豊富なエンジニアが配置されています。このようなやり取りに大いに貢献できる、ソフトウェア開発の経験があるエンジニアが理想的です。

ここで重要なのは、チームがどれだけ効果的に本番環境に移行できたかを測定することで、誰に話を聞くべきかを特定し、対処すべき問題について必要なフィードバックを明らかにできることです。テナントが全体像を把握していない（または他の優先事項がある）場合にテナントが自らこれを考えることを期待するだけでは、効果はほとんどありません。

その後、アンケートの実施やネットプロモータースコアの利用など、より従来的なアプローチと組み合わせることで、プロダクトの人気を高めることができました。その結果はたいてい非常にポジティブなものであり、マインドシェアの獲得に利用できました。特に、プロダクトチームが社内の技術会議などでポジティブな経験について話すことに抵抗がない場合は、その効果が大きくなります。

チームのパフォーマンスを把握できるようにする

プラットフォームを運用してから数年経つと、重視する点が変わり始めました。プラットフォームの価値を証明する必要性は低くなり、ビジネス部門とエンジニアは満足していました。そのため、「いかに早く本番環境に移行できるか」から「いかにして日常業務で迅速さを維持しつつ、摩擦を減らすことができるか」へと焦点を移しました。これが DORA 指標につながりました。

DORA の最初の実装では、変更とインシデントに関する記録システムから情報をマイニングし、すでに成熟していた可用性データ用のオブザーバビリティスタックで補完しました。また、クラウド監査ログなどのイベントも取得しました。このためのソフトウェアを構築して BigQuery に保存し、自社開発のサービスカタログツールでデータを可視化できるようにしました。その後、これを Grafana ダッシュボードに移行し、現在も使用しています。

このデータからパターンを探した結果、構築に役立つ他の機能を発見できました。この 2 つの大きな例は、変更への対応と運用準備です。

JLP のサービス管理プロセスは、複数の大規模なシステムやチームにわたる複雑なリリースプロセスを処理することを目的としていましたが、マイクロサービスを採用することでアーキテクチャを根本的に変更しました。これにより、チームは必要に応じて独立してリリースできるようになり、変更の失敗による影響を自分たちで管理できるようになりました。変更時の障害率と小規模なリリースの頻度について収集したデータを使用して、別のアプローチを正当化しました。テナントが CI / CD パイプラインの一部として変更を自動的に発生させて終了できるようにするアプローチです。サービス管理チームにこのアプローチを承認してもらった後、チームがパイプライン内で使用できる CLI ツールを開発しました。これには、より扱いにくいデータソースをスクレイピングするのではなく、リリース時に有用なデータを取得できるというメリットもありました。自動変更の「アメ」は非常に人気があり、広く採用されました。これにより、承認ポイントはリリースプロセスの後半ではなく、pull リクエストの段階に移行しました。この結果、時間の無駄、変更セットのサイズ、衝突のリスクが軽減されました。

同じような事例として、独自のサービスを運用するチームが増えたことで、サイト全体の運用チームを中央に置く必要性が低下しました。指標から、「You Build It, You Run It（自ら開発し、自ら運用する）」を実践しているチームはインシデントが少なく、インシデントの解決もはるかに迅速であることがわかりました。これを根拠として、インシデントへの迅速な対応に役立つツールを導入し、集中型の運用チームをこれらのプロセスから切り離しました。これにより、レガシーシステムに集中できるようになったチームもあれば、サービス自体が不要になったチームもあります（後者の場合、個々のプロダクトチームのオンコールが増えたにもかかわらず、大幅な費用削減につながりました）。これに加えて、オブザーバビリティ / アラートツールをサポートするものはすべて、前回の記事で説明したプラットフォームの「Paved Road」パイプラインを通じて構成されました。

DORA の指標は、アーキテクチャの面でも役立ちました。運用データから、サードパーティサービスと従来のサービスの脆弱性が明らかになり、その結果、レジリエンスエンジニアリングや代替ソリューションへの投資が拡大しました。構築と購入の意思決定を再評価することになったケースもありました。

測定対象を選択する

何を測定するかを賢く選択することは非常に重要です。この分野の専門家（Laura Tacho 氏など）から、見栄えのよい指標は避け、収集した指標の解釈には慎重になるようアドバイスを受けました。さらに、指標がターゲットオーディエンスにとって意味のあるものであり、それに応じて提示されることも重要です。

たとえば、費用や脆弱性についてチームとコミュニケーションをとりますが、その形式はターゲットオーディエンスの役割によって異なります。たとえば、新しい脆弱性や費用の急増は、プロダクトチームのコラボレーションチャネルに直接送信します。これは、エンジニアがこれらの脆弱性を確認することで、より迅速な対応が可能になることが経験からわかっているためです。一方、コンプライアンスレポートやチームリーダーによるレビューでは、対応が必要な領域を要約するためにはレポートの方が効果的です。「ポリシー外の脆弱性」ダッシュボードのリーダーになりたい人はいないことは、よく知っています。

それまで、インシデントの数や頻度などの指標を調べることは珍しくありませんでした。しかし、高度に自動化された対応システムの世界では、アラートは簡単に複製できるため、これは落とし穴となります。数値を重視しすぎると、間違った行動につながる可能性があります。最悪の場合、インシデントの登録を意図的に避けることさえあります。代わりに、親インシデントの影響と復旧にかかった時間に焦点を当てる方がはるかに良いでしょう。もう一つの例は、脆弱性の数の報告です。分散システム内の多くのコンポーネントで広く使用されているパッケージがあるとします。パッケージに脆弱性があることを開示すると、ベースイメージにパッチを適用すればすぐに問題に対処できる場合でも、影響の範囲が実際より大きく誤認される可能性があります。代わりに、重大度に基づく事前合意済みのポリシーよりも、対応のスピードを重視することをおすすめします。これは、チームが行動を起こすうえでより効果的かつ合理的な指標であるため、エンゲージメントが向上します。

データを示す際には、できるだけ多くのコンテキストを伝えることが非常に重要です。そうすることで、正しい結論を導き出すことができます。特に、意思決定者がレポートを見る場合はなおさらです。それを踏まえて、可視化できる未加工の指標と、それに関するユーザーの意見を組み合わせました。これにより、欠けていたコンテキストが明らかになりました。変更時の障害率が高いチームは、リリースプロセスやバッチサイズにも苦労しているのでしょうか？脆弱性に迅速に対処していないチームは、機能の開発に時間をかけすぎて、運用上の問題にも十分な時間をかけられていないと報告していますか？そこで、このような情報を活用するために、別のツールである DX を使用することにしました。続編の記事では、これをどのように行ったかと、その結果テナントに関する収集データの拡大がどのように促されたかについて詳しく説明します。今後の情報にご注目ください。

Google Cloud でのプラットフォームエンジニアリングを活用したシフトダウンについて、詳しくはこちらをご覧ください。

- アプリケーションプラットフォーム担当 EMEA プラクティスソリューションリード、Darren Evans

- John Lewis Partnership、プリンシパルプラットフォームエンジニア、Alex Moss 氏

プラットフォーム使用の落とし穴（パート 2）: 意味のあるモニタリング指標を選択する

Fri, 13 Feb 2026 01:00:00 +0000

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

この記事のパート 1 では、John Lewis Partnership の Alex Moss 氏が、同社がデベロッパープラットフォームの価値を測定するために使用している指標について説明しました。ここでは、あらゆる測定戦略の重要な側面である、測定対象の適切な選択について説明します。膨大なデータの中に迷い込んだり、見栄えはするものの、実際にはプラットフォームの健全性やデベロッパーのエクスペリエンスを反映していない指標に注目したりしがちです。ここでは、意味のある指標を選択し、適切な会話と行動を促す方法で提示することにより、データを常に可能な限り多くのコンテキストとともに提示するという John Lewis の理念について、Alex 氏が説明します。- Darren Evans

この記事の前半で詳しく説明したソリューションは非常にうまく機能しましたが、客観的な指標のみに頼ることには、いくつかの落とし穴があります。誤解されやすいため、時間を無駄にしたり（「チームは現在別のプロダクトに取り組んでいる」）、正しい情報を伝えられなかったり（「インシデントは適切にクローズされなかった」）します。その結果、スケーリングの課題が生じます。少数のチームと話して状況を把握することはできます。しかし、プロダクトを構築しようとしているのが 1 つの小さなチームしかなく、数十のチームとやり取りする必要がある場合は、そう簡単ではありません。

エンジニアの主観的なフィードバックを収集する

当社は、主観的なフィードバックを収集する方法を必要としていました。できれば、客観的な DORA やその他のサービス指標と比較して可視化できる形式です。

この最初の試みとして、サービス運用性評価を作成しました。これは、テナントが四半期ごとに記入するアンケートです。サービス運用性評価は、チームがサービスの実行に関する優れたプラクティスに従っているかどうかを調べることを目的とした、示唆に富んだ一連の質問で構成されています。これは、さらに質問を掘り下げて、重要なフィードバックとアクションを引き出すことができる経験豊富なファシリテーター（通常はシニアプラットフォームエンジニア）がいる場合には有効でした。しかし、ご想像のとおり、この方法ではスケーリングの課題が生じました。最終的に、このプロセスは完全にセルフサービスで処理されるようになりました。これは完璧なシステムではありません。多くのチームは、前の四半期の回答をコピー＆ペーストするだけで満足しているからです。その回答が現実を反映しているかどうかはわかりません。

その後、DX プラットフォームと呼ばれるツールについて知りました。このツールは、この問題への取り組み方を大きく変え、現在ではエンジニアリングコミュニティ全体で使用されています。3 か月ごとに数分間、チームではなく個々のエンジニアにアンケートを実施します。質問は、DORA やその他の類似のフレームワークの創設者によって裏付けられた DX の調査に基づいて厳選されます。結果をさまざまな方法で分析できるのは非常に便利でした。プラットフォーム全体にわたる領域を調べることも、特定のチームを詳しく調べることもできます。後者の場合、DORA データと組み合わせれば、充実した会話が生まれます。たとえば、DX ツールでは、大きな影響を及ぼすインシデントを最近経験したチームは「本番環境のデバッグ」に関する懸念を登録した可能性がある一方、リリース頻度が大幅に低下したチームは「変更の信頼性」や「リリースの容易さ」に関する懸念を登録した可能性があります。この時点で、プラットフォームチームは、チームが抱えている問題に対処するために、アドバイスを提供したり、新しい機能を実装したりできます。

DX の事前構築されたドライバとレポートは非常に便利ですが、当社では、現在の重点分野を把握するため、独自のカスタムクエリも追加しています。たとえば、プラットフォームとそのポータル（Backstage）の顧客満足度（CSAT）を測定したり、新入社員が pull リクエストの送信を開始するまでにかかる時間をデータとして収集したり、オンボーディングプロセスについてどのように感じたかを尋ねたりしています。さらに、最近では、AI コーディングアシスタントの有効性に関するエンジニアの意見を評価し始めました。これは、市場の分析情報に頼るだけでなく、AI コーディングアシスタントへのさらなる投資を正当化するためです。

このアプローチが役立った例として、ドキュメント化があります。具体的には、Backstage デベロッパーポータルに機能を組み込み、コンテンツを自動的に公開して見つけやすくするパイプラインを通じて、チームが互いのドキュメントを簡単に閲覧できるようにしました。

サービスの健全性 - 機能の導入とそれ以降

DORA や DX などから生成される分析情報以外にも、最近では、プラットフォーム自体に価値があるかどうかだけでなく、テナントがプラットフォームから期待される価値を得ているかどうかについても調べ始めています。つまり、プラットフォーム機能の導入結果の測定を効果的に始めたのです。

これを実現するため、社内で「技術的健全性」機能と呼んでいるものを構築しました。これは、カスタムプラグインの形で Backstage デベロッパーポータルと統合されています。このプラグインは、測定対象に関する情報を収集する多数の小規模なジョブから得られたデータを明らかにする社内 API をクエリします。これらのジョブはそれぞれ独立してリリースできるため、比較的迅速にスケールアップできました。

現在、4 つのカテゴリの健全性指標を収集しています。

技術的健全性: 現在、17 の「技術的」指標があります。たとえば、各チームが独自のリソースを「Terraform 化」するのではなく、当社の「Paved Road（舗装された道路）」パイプラインとカスタムマイクロサービス CRD（以前の記事 1 と 2 を参照）を使用しているかどうか、推奨される Kubernetes プラクティス（リソースのサイズ設定、中断予算、ライフサイクルプローブなど）に従っているかどうか、ベースイメージを最新の状態に保っているかどうかを測定することなどが挙げられます。また、変更を反映するためにパイプラインを十分な頻度で実行しているか（チームでは実行していません）、運用性評価を確認しているか、Git ブランチを最新の状態に保っているかなど、「よりソフトな」技術的対策も含まれます。
運用準備: 次に、運用面の健全性に関する 18 の指標があります。たとえば、プリフライト構成が整っているか、ランブックが作成されているか、ドキュメントが公開されているかなどです。これは、数年前の運用準備チェックリストの進化版です（当時はデリバリーチームと運用チームが分かれていたため、このようなチェックは「引き渡し」に必須でした）。このチェックリストは、一般的なリストではなく、チームが高い運用性を実現するのに役立つプラットフォームの特定の機能に合わせて調整されています。さらに、適切なプラクティスに従っていることをサービス管理チームが確信できるようになり、手動レビューの実施時に摩擦が生じることもなくなりました。
移行: プラットフォーム自体に変更があった場合、テナントはその変更に対応するために随時作業を行う必要があります。この典型的な例として、チームに非推奨の Kubernetes API バージョンに対処してもらうことが挙げられます。これには、古いやり方を排除するために、より強力に推進したいさまざまな機能を導入することも含まれます（たとえば、より安全な方法を優先するなど）。プラットフォームが成長するにつれて、チームが実行する必要がある移行作業が長期間にわたって続くことがわかりました。その結果、プロダクトマネージャーとデリバリーリードがチームのワークロードに優先順位を付けやすくなりました。
エンジニアリングプラクティスの拡大: 最近、この機能の使用範囲を広げ、他のチーム（この場合はエンジニアリングリーダーシップ）が独自の指標を組み込めるようにしました。たとえば、チームがデザインシステムのバージョンを最新の状態に保っているかどうかや、JL デジタルプラットフォームだけでなく、より広範なエンジニアリングプラクティスに従っているかどうかなどです。

このデータは、集計ビュー（下の例を参照）や個々のタスク、より広範なリーダーボードを通じて提示されます。これらはすべて、チームの優先事項に影響力を持つ人々の目に留まるように設計されています。エンジニアが信号を青に変えたいという欲求は、ドキュメントや発表に頼るよりもはるかに効果的な、強力なモチベーターになることがわかりました。

このテクノロジーは、Backstage ポータル用に構築したカスタムプラグインを通じて機能します。各「ヘルスチェック」は、それ自体が独自のマイクロサービス（多くの場合、ジョブとして実行される）であり、該当するシステムを調べて、測定基準が満たされているかどうかを判断します。たとえば、あるマイクロサービスは、Kubernetes に直接クエリを実行して PodDisruptionBudget が作成されていることを確認します。別のマイクロサービスは、コンテナイメージのレイヤを検査して、distroless のベースイメージが使用されているかどうかを確認します。新しい指標を作成するためのテンプレートが用意されているため、エンジニアは新しい指標を簡単に作成できます。プラットフォームチーム以外のエンジニアも同様です。結果は BigQuery に保存されます。Backstage プラグインの開発を簡素化する API も用意されています。

このような対策を導入した場合の現実として、プロダクトチームの作業量が増えることが挙げられます。そのためには、組織文化がこの変化に対応できることが重要です。プラットフォームの初期段階でこれらの対策を導入していた場合、製品の認識に影響が及んでいた可能性があります。たとえば、厳格すぎるとか、ガードレールによって変化のペースが阻害されるといった認識です。これは、全体的な導入に悪影響を及ぼす可能性があります。これらの機能を後から導入したことで、プラットフォームを非常に価値あるものとすでに認識していた多くのテナントの恩恵を受けることができました。さらに、適切な対策を選択し、一貫性のある方法で適用できるという自信も得られました。とはいえ、この取り組みを開始した後、プラットフォームの CSAT はわずかに低下しました。プロダクトチームが作業を吸収する時間を確保できるよう、各指標を導入するペースに配慮し、チームが自分たちに関係のない指標を抑制する手段を提供しています。たとえば、テナントがパフォーマンス上の理由で Pod の自動スケーリングを使用しないことを意図的に選択したり、当社のマイクロサービス CRD を使用できない機能上の理由が存在していたりする場合があります。

テナントの行動に関するこのような保証対策の導入は、プラットフォームの成熟度を反映しています。初期の頃は、高度なスキルを持つチームが、正しいことを迅速に行うことを期待していました。しかし、時間が経つにつれて、さまざまなスキルや能力、サービス所有権の移行が組み合わさったことで、適切な成果を上げるための手法を導入する必要に迫られました。これは、プラットフォーム自体が複雑になっていることも原因です。多くの新機能が追加されたため、新しいチームの認知負荷が以前よりもはるかに高くなっています。チームが「Paved Road（舗装された道路）」から外れないように、道路の端に沿ってライトを設置する必要がありました。

この進化の過程で、ビジネス自体の主な成果（つまり、当社はお客様が望むことを今も行っているか？）について報告し続けてきました。そのため、「迅速にチームを支援する」（正直なところ、これはほぼ解決済みの問題と見なされています）から「安全に実行し、技術的負債を管理する」へと自然に移行しました。

プラットフォームは期待に応えている？重要ポイント

要するに、デベロッパープラットフォームに価値があるかどうかという問題は複雑であり、それに答える方法はさまざまです。独自のデベロッパープラットフォームの構築と定量化に着手するにあたり、最後に留意すべき点をいくつかご紹介します。

測定は目的地ではなく道のりである: 関係者にとって意味のあるものを測定することから始めましょう。ただし、プラットフォームの進化に合わせて適応する準備もしておきましょう。最初は、プロダクトへのさらなる投資を優先してもかまいませんが、プラットフォームがチームにどのように役立っているかを実際に測定することをおすすめします。プラットフォームの実現可能性を最初に実証したときに重要だったことは、数年後に機能が成熟し、優先事項が変わったときには重要ではなくなっている可能性があります。
人間の声に耳を傾ける: プラットフォームが使用されているからといって、価値を生み出しているとは限りません。最も効果的な指標は、多くの場合、定性的なものです。エンジニアがツールを使用したいと思っていることや CSAT は重要なシグナルですが、どのように使用しているかを質問することで、どう改善できるかに関するより深い分析情報を得ることができます。測定だけでは、何が効果的で何がそうでないかを把握するのは困難です。
データはレポート作成だけでなく、チームの能力向上にも役立てる: グラフを経営陣に見せるだけでなく、分析情報をチームの改善に役立てましょう。さらに、行動の根拠となった具体的なデータを明確に示しましょう。たとえば、特定のチームのリリース頻度が低下していることがわかったら、それを問題として指摘するだけでなく、そのデータを使って潜在的な障害について話し合うきっかけにしましょう。そうすることで、リーダーシップとテナントの両方から信頼と好意を得て、プラットフォームを前進させ続けることができます。

John Lewis Partnership の測定戦略の進化は、説得力のあるケーススタディとして役立ちます。基本的なリードタイム追跡から、DORA の指標とデベロッパーからの定性的なフィードバックを組み合わせた包括的なモデルに移行することで、プラットフォームの真の成功は、単に導入率ではなく、プラットフォームが生み出す真の価値によって定義されることを実証しました。

Google Cloud のプラットフォームエンジニアリングについて詳しくは、他の記事をご覧ください（プラットフォームエンジニアリングを駆使して開発者の利便性を強化 - パート 1、パート 2、プラットフォームエンジニアリングに関する 5 つの誤解: プラットフォームエンジニアリングとは一体なのか、プラットフォームエンジニアリングにまつわるさらなる 5 つの誤解）。また、App Hubについてもお読みになることをおすすめします。これは、組織全体でアプリケーション中心のガバナンスを管理するための基盤となるツールです。

- アプリケーションプラットフォーム担当 EMEA プラクティスソリューションリード、Darren Evans

- John Lewis Partnership、プリンシパルプラットフォームエンジニア、Alex Moss 氏

Google の ADK を使ったエージェントアプリケーションを Datadog LLM Observability でモニタリングする

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

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

Google の Agent Development Kit（ADK）は、強力なエージェントシステムを構築するための基盤を提供します。こうした複数ステップのエージェントは、計画を立て、ループ処理を行い、協調し、必要に応じてツールを動的に呼び出しながら、自律的に問題を解決できます。一方で、この柔軟性は予測しにくさにもつながり、出力の欠落、想定外のコスト、セキュリティリスクといった問題を招く可能性があります。こうした複雑さを管理できるよう、Datadog LLM Observability は ADK で構築されたシステムに対する自動計測を提供するようになりました。この統合により、エージェントの挙動を可視化してモニタリングし、コストやエラーを追跡できるほか、大がかりな手動設定を行うことなく、オフライン実験とオンライン評価を通じて、応答品質と安全性の観点からエージェントを最適化できます。

これは重要な点です。エージェントシステムは複雑で、エージェント同士の相互作用に加え、LLM の非決定性によって、応答を事前に予測することが難しいためです。

こうしたエージェントを運用する際に一般的に想定されるリスクには、次のようなものがあります。

変化のスピード: 新しい基盤モデルは毎週のように登場し、「ベストプラクティス」とされるプロンプト設計のパターンも同じくらいの速さで変化します。そのため、チームは新しい組み合わせを継続的に評価する必要があります。
マルチエージェント間の受け渡し: あるエージェントが低品質な出力を生成すると、その影響がダウンストリームに連鎖し、他のエージェントが誤った判断を下す原因となる可能性があります。
ループとリトライ: プランナーが同じツール呼び出しに固執してしまい、検索クエリを無限に再試行するなど、ループに陥ることがあります。これにより、レイテンシの急増を招くおそれがあります。
見えにくいコスト: プランナーのステップが 1 つでも誤ってルーティングされるだけで、トークン使用量や API 呼び出し回数が増幅し、コストが予算を超過する可能性があります。
安全性と正確性: LLM の応答には、ハルシネーション、機密データの混入、プロンプトインジェクションの試みなどが含まれる場合があり、セキュリティインシデントや顧客からの信頼低下につながるリスクがあります。

最後に、ADK は市場に存在する数多くのエージェントフレームワークの一つにすぎません。これを手作業でインストルメンテーション（計測の仕込み）しなければならないとなると、すでに煩雑でエラーが発生しやすいプロセスに、さらに学習コストが上乗せされることになります。

エージェントの判断と予期しない挙動をトレース

Datadog LLM Observability は、ADK エージェントを自動的に計測およびトレースすることで、こうした課題に対応します。コードを変更することなく、数分でエージェントをオフラインで評価し、本番環境でモニタリングを開始できます。これにより、エージェントのオーケストレーションからツール呼び出しに至るまで、すべてのステップやプランナーの判断を単一のトレースタイムライン上で可視化できます。

たとえば、エージェントがユーザーのクエリに応答する際に誤ったツールを選択した場合、想定外のエラーや不正確な応答につながることがあります。Datadog の可視化機能を使えば、どのステップで誤ったツールが選択されたのかを正確に特定できるため、トラブルシューティングが容易になり、問題の再現や原因の特定にも役立ちます。

トークン使用量とレイテンシをモニタリング

レイテンシやコストの急激な増加は、エージェントアプリケーションに問題が生じている兆候であることが少なくありません。Datadog では、ツール、ブランチ、ワークフローごとにトークン使用量とレイテンシを可視化できるため、どこでエラーが発生し、それがダウンストリームの処理にどのような影響を及ぼしたのかを明確に把握できます。

たとえば、プランナーエージェントが要約ツールを 5 回も再試行した場合、レイテンシは大幅に増加します。Datadog はこうしたループを強調表示し、処理に要した正確な時間とそれに伴うコストへの影響を可視化します。

エージェントの応答品質とセキュリティを評価

レイテンシのような運用パフォーマンス指標は重要なモニタリングシグナルですが、エージェントアプリケーションの動作状況を包括的に把握するには、LLM やエージェントの応答が持つ意味的な品質についても評価する必要があります。Datadog には、ハルシネーション、個人を特定できる情報（PII）の漏えい、プロンプトインジェクション、不適切または危険な応答を検出するための組み込み評価機能が用意されています。

さらに、ドメイン固有のチェックを行うために、LLM-as-a-judge 型の評価ツールを含むカスタム評価ツールを追加することも可能です。たとえば、検索エージェントが無関係なドキュメントを取得し、その結果として回答が話題から逸れてしまった場合、カスタム評価ツールによって、そのトレースを「検索関連性が低い」と判定できます。

テストを通じて、迅速かつ確信を持って改善を重ねる

新しいシステムプロンプトを展開すると、レイテンシの急増や出力の一貫性の低下に気付くことがあります。Datadog では、本番環境の LLM 呼び出しを Playground 上で再生し、異なるモデル、プロンプト、パラメータを試すことで、理想とする挙動に近づく構成を見つけることができます。

さらに、実際のトラフィックから構築したデータセットを用いて、複数のバージョンを並べて比較する構造化されたテストを実行し、運用面および機能面のパフォーマンスを最適化できます。ADK のインストルメンテーションによってすべてのエージェントステップが記録されるため、デプロイ前に回帰を再現し、修正内容を検証するために必要となる完全なコンテキストを把握できます。

Datadog LLM Observability を使ってみる

Datadog LLM Observability は、Google ADK を利用したシステムのモニタリングとデバッグを簡素化し、エージェントの動作を把握しやすくします。これにより、エージェントの挙動を解析し、応答を評価し、迅速に改善を重ねながら、本番環境にデプロイする前に変更内容を検証できます。

最新バージョンの LLM Observability SDK を使って、今すぐ利用を開始できます。Datadog を初めて利用する方は、無料トライアルから始めることも可能です。

エージェントの挙動を解析し、応答を評価する方法について詳しくは、Datadog の LLM Observability ドキュメントをご覧ください。

-Google、シニア戦略的パートナーシップ担当マネージャー、Abhi Das

-Datadog、プロダクトマーケティングマネージャー、Trammell Saltzgaber 氏

Model Context Protocol の gRPC トランスポート

Mon, 19 Jan 2026 03:00:00 +0000

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

AI エージェントはテスト環境から企業業務の中核へと移行していて、複雑なマルチステップの目標を達成するには、外部のツールやシステムと確実にやり取りする必要があります。Model Context Protocol（MCP）は、こうしたエージェントとツールの間の通信を可能にする標準プロトコルです。実際、Google は先月、フルマネージドのリモート MCP サーバーのリリースを発表しました。デベロッパーは、Gemini CLI などの AI エージェントや標準の MCP クライアントを、Google サービスと Google Cloud サービスのグローバルな整合性を備えたエンタープライズ対応エンドポイントに、簡単に接続できるようになりました。

MCP は標準トランスポートとして JSON-RPC を使用しています。これは、行動指向のアプローチと、エージェントが基盤モデルとのコミュニケーションで直接伝達できる自然言語ペイロードを兼ね備えているため、多くのメリットをもたらします。しかし、多くの組織がリモートプロシージャコール（RPC）モデルの高性能なオープンソース実装である gRPC を利用しています。gRPC フレームワークを採用している企業は、MCP で使用される JSON-RPC トランスポートに合わせて自社ツールを調整する必要があります。現在、これらの企業は、JSON-RPC MCP リクエストと既存の gRPC ベースのサービスの間で変換を行うために、コード変換ゲートウェイをデプロイする必要があります。

MCP コード変換の興味深い代替手段として、MCP のネイティブトランスポートとして gRPC を使用する方法があります。多くの gRPC ユーザーが、独自のカスタム MCP サーバーを実装して、この方法を積極的に試しています。Google Cloud は、サービスを有効にしてグローバル規模で API を提供するために gRPC を幅広く使用しており、こうした広範な利用から得られた技術と専門知識の共有に尽力しています。具体的には、本番環境で MCP を導入している gRPC 実務担当者にサポートを提供したり、MCP コミュニティと積極的に協力して、MCP のトランスポートとして gRPC を利用する手段を模索したりしています。MCP の主なメンテナーは、MCP SDK でプラグ可能なトランスポートをサポートすることに合意しており、Google Cloud は、MCP SDK にプラグインできる gRPC トランスポートパッケージを近い将来提供する予定です。コミュニティがサポートするトランスポートパッケージにより、gRPC 実務担当者は、一貫性があり相互運用可能な方法で、gRPC を使用して MCP をデプロイできるようになります。

トランスポートとして gRPC をネイティブに使用すると、コード変換の必要性がなくなり、gRPC を積極的に使用している環境の運用で整合性を維持できます。この投稿の残りの部分では、MCP のネイティブトランスポートとして gRPC を使用するメリットと、Google Cloud がこの移行をどのようにサポートしているかについて説明します。

RPC トランスポートの選択

サービスに gRPC をすでに使用している組織は、gRPC がネイティブにサポートされることで、サービスの変更や、コード変換プロキシの実装をすることなく、既存のツールを引き続き使用して MCP 経由でサービスにアクセスできるようになります。これらの組織は、エージェントがサービスにアクセスする手段として MCP が使用されるようになっても、gRPC のメリットを維持できるように取り組んでいます。

「gRPC はバックエンドの標準プロトコルであるため、社内で gRPC を使用した MCP の試験的なサポートに投資してきました。すでにメリットを実感しています。それは、開発者が使い慣れているため扱いやすいという点や、構造と静的に型付けされた API を使用することで MCP サーバー構築に必要な作業を減らせるという点です。」 - Spotify、シニアスタッフエンジニア兼デベロッパーエクスペリエンス担当テクニカルリード Stefan Särne 氏

gRPC のメリット

ネイティブトランスポートとして gRPC を使用すると、MCP が gRPC ベースの最新分散システムのベストプラクティスに準拠できるようになるため、パフォーマンス、セキュリティ、運用、デベロッパーの生産性が高まります。

パフォーマンスと効率

gRPC のパフォーマンス面でのメリットは、次の特性により効率を大幅に向上させます。

バイナリエンコード（プロトコルバッファ）: gRPC はバイナリエンコードにプロトコルバッファ（Protobuf）を使用しているため、JSON と比較してメッセージサイズを最大 10 分の 1 に縮小できます。つまり、帯域幅の消費が削減され、シリアル化 / シリアル化解除がより高速になります。これにより、ツール呼び出しのレイテンシの短縮、ネットワーク費用の削減、リソースフットプリントの大幅な縮小が実現します。
全二重双方向ストリーミング: gRPC は、クライアント（エージェント）とサーバー（ツール）が、単一の永続的な接続を通して、連続したデータストリームを同時に相互送信することをネイティブにサポートしています。この機能は、エージェントとツールのやり取りを大きく変えるものであり、アプリケーションレベルの接続同期を必要とせずに、真にインタラクティブなリアルタイムのエージェントワークフローを実現できるようになります。
組み込みのフロー制御（バックプレッシャー）: gRPC にはネイティブなフロー制御が含まれているため、送信速度の速いツールがエージェントを圧倒するのを防止できます。

エンタープライズクラスのセキュリティと認証

gRPC ではセキュリティが最重要事項とされているため、エンタープライズクラスの機能がコアに直接組み込まれています。これには以下が含まれます。

相互 TLS（mTLS）: ゼロトラストアーキテクチャに不可欠な mTLS は、クライアントと gRPC を利用したサーバーの両方を認証することで、なりすましを防止し、信頼できるサービスのみが通信できるようにします。
厳格な認証: gRPC は、業界標準のトークンベースの認証（JWT / OAuth）と統合するためのネイティブフックを提供し、すべての AI エージェントに検証可能な ID を提供します。
メソッドレベルの認可: 特定の RPC メソッドまたは MCP ツールに認可ポリシーを直接適用できるため（例: エージェントは ReadFile が認可されるが、DeleteFile は認可されない）、最小権限の原則を厳格に遵守し、「過剰なエージェンシー」に対処できます。

運用の成熟度とデベロッパーの生産性

gRPC は、拡張性と再利用性を通じて、復元力に関する措置の負担を軽減し、デベロッパーの生産性を向上させる、強力な統合ソリューションを提供します。主な機能は次のとおりです。

統合されたオブザーバビリティ: 分散トレース（OpenTelemetry）と構造化されたエラーコードとのネイティブ統合により、すべてのツール呼び出しの完全かつ監査可能な証跡が提供されます。デベロッパーは、単一のユーザープロンプトを、その後に続くすべてのマイクロサービスインタラクションを通じてトレースできます。
堅牢な復元力: 期限、タイムアウト、自動フロー制御などの機能により、たった 1 つの応答しないツールがシステム全体に障害を引き起こすことを防止できます。これらの機能により、クライアントはツール呼び出しのポリシーを指定して、このポリシーを超過したらフレームワークが自動的にキャンセルされるようにすることで、障害の連鎖を回避できます。
多言語開発: gRPC では 11 以上の言語でコードが生成されるため、デベロッパーは厳密に型指定された一貫した取り決めを維持しつつ、作業に最適な言語で MCP サーバーを実装できます。
スキーマベースの入力検証: Protobuf の厳格な型指定により、シリアル化レイヤで不正な形式の入力を拒否することで、インジェクション攻撃が軽減され、開発タスクが簡素化されます。
エラー処理とメタデータ: フレームワークは、標準化された一連のエラーコード（例: UNAVAILABLE、PERMISSION_DENIED）を返して、クライアントが確実に処理できるようにします。また、クライアントは、主なリクエストの内容をシンプルに保ちながら、メタデータで Key-Value ペアとして帯域外情報を送受信できます（例: トレース ID）。

使ってみる

Agentic AI Foundation の初期メンバーであり、MCP 仕様の主要な貢献者である Google Cloud は、コミュニティの他のメンバーとともに、MCP SDK にプラグ可能なトランスポートインターフェースを含めることを提唱してきました。MCP のトランスポートとして gRPC を使用することにご関心がある場合は、ぜひ参加してお知らせください。

MCP トランスポートとして gRPC を有効化することにご関心をお持ちの場合は、Python MCP SDK のプラグ可能なトランスポートインターフェースのアクティブな pull リクエストに貢献してください。
AI のコミュニケーションの未来を形作るコミュニティに参加して、Model Context Protocol の発展にご協力ください。Contributor Communication - Model Context Protocol（貢献者によるコミュニケーション - Model Context Protocol）。
お問い合わせください。Google は、ユーザーの皆様の経験から学び、それぞれの取り組みをサポートしたいと考えています。

- ソリューションプロダクトマネージャー Victor Moreno

- シニアスタッフソフトウェアエンジニア Mark D. Roth

企業データを Google の新しい Antigravity IDE に接続する

Thu, 25 Dec 2025 01:00:00 +0000

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

AI の最先端技術は、単純なチャットインターフェースから、複雑なワークフローを計画、実行、改良できる自律型エージェントへと急速に移行しています。こうした新たな状況においては、これらのインテリジェントエージェントを企業データにグラウンディングする能力こそが、真のビジネス価値を引き出す鍵となります。Google Cloud はこの変革の最前線に立ち、堅牢なデータドリブンアプリケーションを迅速かつ正確に構築できるようお客様を支援しています。

先月、Google は AI ファーストの統合開発環境（IDE）である Antigravity を発表しました。そして今回、Antigravity で構築した AI エージェントに、組織を支える信頼できるデータインフラストラクチャへの直接的かつ安全なアクセスを提供できるようになりました。これにより、抽象的な推論が具体的なデータ認識型アクションへと変わります。Antigravity 内で MCP Toolbox for Databases を利用した Model Context Protocol（MCP）サーバーが利用可能になったことで、開発ワークフロー内で AI エージェントを Google のデータクラウド内の AlloyDB for PostgreSQL、BigQuery、Spanner、Cloud SQL、Looker などのサービスに安全に接続できます。

Antigravity で MCP を使用する理由

Antigravity は、ユーザーがフローを維持できるように設計されていますが、AI エージェントの能力は「知っていること」によって制限されます。本当に役立つアプリケーションを構築するには、エージェントがデータを理解する必要があります。MCP はユニバーサルトランスレータとして機能します。AI 向け USB-C ポートのようなものと考えることができます。これにより、IDE の LLM が標準化された方法でデータソースに接続できるようになります。事前構築済みの MCP サーバーを Antigravity に直接統合することで、手動で構成する必要がなくなります。エージェントがデータベースと直接会話できるようになり、IDE を離れることなくより迅速に構築と反復処理を行えるようになります。

MCP サーバーを使ってみる

Antigravity では、エージェントをデータに接続する作業は UI を使用して行われるため、データベース接続を動作させるためだけに複雑な構成ファイルと格闘するという、誰もが経験したことのある課題が解消されます。使用を開始する方法は以下のとおりです。

1. 発見とリリース

Google Cloud 向け MCP サーバーは、Antigravity MCP ストアで入手できます。「AlloyDB for PostgreSQL」や「BigQuery」など必要なサービスを検索し、[インストール] をクリックして設定プロセスを開始します。

Antigravity MCP ストアのリリース

2. 接続を構成する

Antigravity には、プロジェクト ID やリージョンなどのサービスの詳細を追加できるフォームが表示されます。また、パスワードを入力するか、Antigravity に Identity and Access Management（IAM）認証情報を使用させることで、セキュリティを強化することもできます。これらは安全に保存されるため、エージェントはチャットウィンドウで未加工のシークレットを公開することなく、必要なツールにアクセスできます。

AlloyDB for PostgreSQL MCP サーバーのインストール

エージェントの活用事例を見る

Antigravity に接続すると、エージェントはユーザーを支援するために使用できる「ツール」（実行可能な関数）のスイートを獲得し、さまざまなサービスにわたって開発とオブザーバビリティのエクスペリエンスを変革するのに役立ちます。一般的なシナリオをいくつか見てみましょう。

AlloyDB for PostgreSQL によるデータベースタスクの効率化

PostgreSQL などのリレーショナルデータベースに対して構築する場合、スキーマ名の確認やクエリのテストのために IDE と SQL クライアントを切り替えるのに時間がかかることがあります。AlloyDB MCP サーバーを使用すると、エージェントがそのコンテキストを処理し、データベース管理を実行して、アプリに含めることができる高品質の SQL コードを生成する機能を獲得します。これらすべてが Antigravity インターフェース内で実行されます。

例:

スキーマの探索: エージェントは list_tables と get_table_schema を使用してデータベース構造を読み取り、関係を即座に説明できます。
クエリの開発: エージェントに「上位 10 ユーザーを検索するクエリを作成して」と指示すると、execute_sql を使用してクエリを実行し、結果をすぐに確認できます。
最適化: コードをコミットする前に、エージェントを使用して get_query_plan を実行し、ロジックがパフォーマンスに優れていることを確認します。

MCP ツールを使用した Antigravity エージェント

BigQuery で分析を促進する

大量のデータが必要になるアプリケーションの場合、エージェントは有能なデータアナリストとして機能します。BigQuery MCP サーバーを活用することで、たとえば以下のようなことが可能になります。

予測: forecast を使用して過去のデータに基づいて将来の傾向を予測します。
カタログの検索: search_catalog を使用してデータアセットを検出、管理します。
拡張分析: analyze_contribution を使用してさまざまな要因がデータ指標に与える影響を把握します。

Looker で真実を構築する

Looker は、ビジネス指標における信頼できる唯一の情報源として機能します。Looker の MCP サーバーにより、エージェントはコードとビジネスロジックのギャップを埋めることができます。たとえば、

指標の整合性の確保: フィールド名が total_revenue なのか revenue_total なのかを推測する必要がなくなります。get_explores と get_dimensions を使用して、エージェントに「ネットリテンションの正しい指標は何ですか？」と質問し、セマンティックモデルから正確なフィールド参照を取得します。
ロジックを即座に検証: ダッシュボードをデプロイして理論をテストするまで待つ必要はありません。run_query を使用して、IDE で直接 Looker モデルに対してアドホックテストを実行することで、アプリケーションロジックがライブデータと一致するようになります。
監査レポート: run_look を使用して、既存の保存済みレポートから結果を抽出します。これにより、アプリケーションの出力が公式のビジネスレポートと一致していることを確認できます。

Antigravity でデータを活用して構築する

Google のデータクラウド MCP サーバーを Antigravity に統合することで、AI を使用した分析情報の発見や新しいアプリケーションの開発がこれまで以上に簡単になりました。ビジネスを運営するさまざまなデータソースにアクセスできるようになった今、コードに話しかけるだけでなく、ユーザーに新しいエクスペリエンスを提供できるようになりました。

実際にやってみるには、以下のリソースをご覧ください。

ドキュメント: MCP を使用して AlloyDB に接続する
GitHub: MCP Toolbox for Databases

-データベース向け AI 担当シニアプロダクトマネージャー Rahul Deshmukh

-データベース向け AI 担当スタッフソフトウェアエンジニア Averi Kitsch

NEC、AI で TNFD レポート作成業務を自動化、8 万時間相当の作業を 200 時間に大幅短縮

Fri, 05 Dec 2025 02:00:00 +0000

企業の価値を測る尺度は、財務情報以外にも広がっています。2019 年 1 月の世界経済フォーラム（ダボス会議）で構想が発表された「TNFD（自然関連財務情報開示タスクフォース）」は、企業と自然環境との関わりを開示する国際的な枠組みであり、グローバル企業の新たなスタンダードになりつつあります。

国内 IT 業界でいち早くこの課題に向き合った日本電気株式会社（NEC）は、「TNFD レポート第 3 版」の作成にあたり、サプライヤーを含む約 2,000 拠点もの広範なリスク評価という大きな課題に直面していました。このレポートを作成するには、政府や自治体が発行する環境関連の文書や学術論文などを読み込み、必要な情報を抽出・評価する必要がありました。人手で約 2,000 拠点分を実施した場合、その工数は実に 8 万時間にも上り、従来の手法では「あきらめざるを得ない」ほどの規模でした。

本記事では、NEC が自らを「最初の顧客」とする「クライアントゼロ」戦略のもと、いかにしてこの AI ソリューションを開発し、TNFD 対応におけるリスク評価（守り）の高度化と、事業機会の探索（攻め）を両立させたのか。創出された時間をより付加価値の高いステークホルダーとの「対話」へつなげた、その取り組みの裏側に迫ります。

利用している主なサービス:

Gemini
Agent Development Kit (ADK)
Cloud Run
Vertex AI Agent Engine

人手では不可能ー 2,000 拠点、8 万時間の壁

2023 年 7 月、NEC は国内 IT 業界で初めて TNFD レポートを公開し、以来、国際的なルール形成にも寄与してきました。しかしその裏側で、サステナビリティ推進チームは新たな課題に直面します。TNFD が求める開示レベルは年々高まり、第 3 版では評価対象をバリューチェーン上流の約 2,000 拠点へ拡大する必要に迫られたのです。

「第 2 版では 3 拠点の深掘りが限界でした」と岡野様が語るように、従来の人手による調査は 1 拠点あたり約 40 時間を要していました。単純計算で 8 万時間にもなる膨大な工数を前に、チームは従来の手法に限界を感じ、AI 活用へと大きく舵を切る決断をします。

この課題に対し、NEC は Google Cloud の AI サービスと伴走型内製開発支援プログラム「Tech Acceleration Program（TAP）」を活用。Google Cloud のスペシャリストと共に短期集中で検討を重ね、Google の AI、Gemini をはじめとする最新技術を駆使した「Agentic AI」ソリューションを自ら開発しました。これにより、膨大なタスクをわずか 200 時間で完遂する目処を立てたのです。

Google Cloud の AI サービスと TAP によって実現手段を見出す

解決の鍵となったのが、複数の AI エージェントが自律的に連携してタスクを実行する「Agentic AI」という先進的なアプローチでした。そして、このアイデアを現実のものとしたのが、Google Cloud のエンジニアが伴走支援するプログラム「Tech Acceleration Program（TAP）」です。

TAP では、TNFD レポート作成に関わる全体のプロセスを確認し、そのうえで、もっとも重要な箇所について、どのように改善できるかを掘り下げて検討していきます。今回、レポートを作成するうえで、そのクオリティを左右するもっとも重要なタスクである「リスク評価」にフォーカスし、そのなかでも特に「渇水リスク」をテーマに 3 日間の TAP を実施しました。現状の業務フローから扱うデータ形式や出力イメージなどを Google Cloud のスペシャリストと細かく確認。この業務では、国や拠点が変わると条件が変わるため、当初、2,000 もの拠点のループ処理は実現のハードルが高いと考えられていましたが、Google Cloud のエンジニアと共にアーキテクチャを検討する中で、同社の AI を中心とした技術で十分に実現できる可能性があるとわかってきました。倉地様は、「TAP でのアーキテクチャのディスカッションによって、どのように実現すればいいかを理解できました」と、その効果を語ります。

前述のアーキテクチャのディスカッションに先立ち、Google Cloud の AI サービスを理解するためのハンズオントレーニングを実施しました。これにより、Google Cloud の利用経験がないメンバーもいる中で技術力を高めた状態でディスカッションに入ることができました。そして、アーキテクチャの検討の後、サンプルとなる拠点を選定し、そこに対するレポートのプロトタイプを実際に開発しました。ハンズオンで学んだ AI エージェント開発を加速する「Agent Development Kit (ADK)」やサーバーレスでアプリケーションを実行できる「Cloud Run」を中心に作成したサンプルコードをもとにプロンプト調整を重ねて、実際に動くプロトタイプが出来上がりました。実際に開発したエンジニアからは、「AI エージェントでのタスク処理の流れと開発プロセス、ツールなどを幅広く知ることができました。特に Google マップとの連携など ChatGPT では想定していなかったことも可能になると分かり、貴重な機会となりました」とのフィードバックがありました。

3 日間のワークショップの後、NEC は自社にノウハウを持ち帰り、見事に 2,000 拠点の分析を実行するプロトタイプを完成させたのです。

もちろん、この先進的な取り組みは順風満帆ではありませんでした。初期には個人のブログのような無関係な情報まで収集してしまうという課題に直面しました。しかし、チームはプロンプトの表現を工夫し、タスクを複数の専門エージェントに分割することでこの課題を乗り越え、分析の精度を大きく向上させることに成功したのです。

宇野様は、「スピード感がすごいと思いました。初日に環境ができて、その後すぐに具体的に動くものが見られたのは衝撃的でした」と、TAP の効果を振り返ります。

AI が「調査」、人が「対話」へー新しい協働関係

この Agentic AI は、拠点情報をインプットすると、複数の専門 AI エージェント（水源確認、水管理方法調査、地下水調査など）が並行して自律的に調査・分析を実行します。さらに、その結果を統合してレポートのドラフトを執筆する「WriterAgent」や、内容をレビューする「ReviewAgent」も連携することで、レポート作成プロセス全体を自動化します。この仕組みにより、8 万時間かかっていた作業が、わずか 200 時間（99.75% 削減）へと大幅に短縮されました。

しかし、この取り組みの真価は、単なる効率化に留まりません。NEC は、AI によって創出された膨大な時間を、AI にはできない、より付加価値の高い活動へと振り向けたのです。

岡野様は、「コミュニケーションや信頼関係づくりに時間を使い、アウトプットを早めに出して、それをもとに現場に行って、そこでどうするかの議論に時間をかけられます」と語ります。AI が算出したリスク分析結果を「コミュニケーションツール」として活用し、現地の担当者や自治体、専門家といったステークホルダーと、より具体的で深い対話を行うことで、データだけでは見えてこない現地のリアルな状況を把握し、リスク評価の精度を格段に向上させました。これは、AI と人間がそれぞれの得意分野を活かし合う、新しい協働の形と言えるでしょう。

さらに、AI によって創出された時間は、こうした「守り」のリスク評価を深化させるだけでなく、「攻め」の事業機会の探索にも向けられました。AI が各国の環境法令や顧客ニーズ、そして NEC が持つトラスト技術といった強みを分析し、新たなビジネスのヒントを探索できるようになったのです。

「クライアントゼロ」から、社会全体のサステナビリティ向上へ

この「クライアントゼロ」としての成功体験を、NEC は新しいビジネスとして顧客に展開することを決定しており、すでに多くの企業から具体的な引き合いが寄せられています。

さらに、この Agentic AI の仕組みは、TNFD に留まらず、有価証券報告書作成や、サステナビリティ開示基準（SSBJ）対応、経済安全保障におけるサプライチェーンのリスク評価など、様々な領域への応用が検討されています。

「過去にあきらめていた大変なことほど、AI を活用する価値がある」と倉地様は語ります。人手では不可能だった壮大な課題に、AI との協働で立ち向かう。NEC の取り組みは、データドリブンなサステナビリティ経営の未来を力強く指し示しています。同社はこれからも、テクノロジーの力で、持続可能な社会の実現を加速させていくでしょう。

本レポートの詳細はこちら
NEC TNFDレポート第3版

インタビュイー

日本電気株式会社
プラットフォームサービスビジネスユニット統括技師長
サプライチェーンサステナビリティ経営統括部
事業化推進グループディレクター
岡野豊

サプライチェーン DX 統括部
AI・データ活用推進第 1 グループ
シニアプロフェッショナル
宇野仁志

日本電気株式会社
コーポレートITシステム部門　経営システム統括部　AIインテリジェンスグループ
プロフェッショナル
倉地崇裕

インタラクションから分析情報へ: Google ADK 向け BigQuery Agent Analytics の発表

Wed, 03 Dec 2025 01:05:00 +0000

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

エージェント AI の世界では、エージェントの構築はプロセス全体の半分にすぎません。もう半分は、ユーザーがエージェントをどのように利用しているかを把握することです。最も一般的なリクエストは何か、ユーザーはどこでつまずいているか、どうすれば成功につながるか。こうした疑問への答えが、エージェントを改良し、より優れたユーザーエクスペリエンスを提供するための鍵となります。これらの分析情報は、エージェントのパフォーマンスを最適化するうえでも非常に重要です。

このたび、Google の Agent Development Kit（ADK）では、エージェントのデベロッパーがこうした疑問の答えを簡単に見つけられるようになりました。ADK デベロッパーは、たった 1 行のコードでエージェントのインタラクションデータを BigQuery に直接ストリーミングし、エージェントのアクティビティに関する分析情報をスケーラブルな方法で取得できます。そこで、Google は BigQuery Agent Analytics を導入します。これは、エージェントのインタラクションデータを BigQuery に直接エクスポートして、エージェントのパフォーマンス、ユーザーインタラクション、費用を把握、分析、可視化する ADK 向けの新しいプラグインです。

エージェントのインタラクションデータが BigQuery に一元化されているため、レイテンシ、トークン消費量、ツール使用量などの重要な指標を簡単に分析できます。Looker Studio や Grafana などのツールを使ったカスタムダッシュボードの作成も容易です。さらに、生成 AI 関数、ベクトル検索、エンベディングの生成などの最先端の BigQuery 機能を利用して、高度な分析を実行できます。これにより、エージェントのインタラクションをクラスタ化し、そのパフォーマンスを正確に測定して、一般的なユーザーのクエリやシステム障害のパターンを迅速に特定できます。いずれもエージェントエクスペリエンスの改善に不可欠です。また、インタラクションデータを関連するビジネスデータセットと結合（サポートエージェントのインタラクションを CSAT スコアにリンクさせるなど）して、エージェントの実際の影響力を正確に測定することもできます。この機能全体は、最小限のコード変更で利用できます。

このプラグインは現在、ADK ユーザー向けにプレビュー版が提供されており、他のエージェントフレームワークのサポートも近日中に開始される予定です。

プラグインの活用例については、以下の動画をご覧ください。

BigQuery Agent Analytics について

BigQuery Agent Analytics プラグインは、さまざまなエージェントのアクティビティデータを BigQuery テーブルに直接ストリーミングする非常に軽量なツールで、主なコンポーネントは次の 3 つです。

ADK プラグイン: 新しい ADK プラグインを使用すると、たった 1 行のコードで、リクエスト、回答、LLM ツール呼び出しなどのエージェントアクティビティを BigQuery テーブルにストリーミングできます。
事前定義された BigQuery スキーマ: 最適化されたテーブルスキーマをすぐに利用して、ユーザーインタラクション、エージェントの回答、ツールの使用状況に関する豊富な詳細情報を保存できます。
低コストで高性能なストリーミング: このプラグインは BigQuery Storage Write API を使用して、イベントをリアルタイムで BigQuery に直接ストリーミングします。

重要な理由: データドリブンなエージェント開発

エージェントの分析データを BigQuery に統合することで、基本的な指標を表示できるだけでなく、行動につながる詳細な分析情報を生成することもできます。具体的には、この統合により次のことが可能になります。

エージェントの使用状況とインタラクションを可視化: エージェントのパフォーマンスを明確に把握できます。トークン消費量やツール使用量などの主要な運用指標を簡単に追跡して、費用とリソース割り当てをモニタリングできます。
高度な AI でエージェントの品質を評価: BigQuery の高度な AI 機能を使用して、単純な指標を超えた評価を実現します。AI 機能とベクトル検索を活用して会話データの品質分析を行い、改善すべき領域をより正確に特定します。
エージェントのデータと会話して学習する: 新しいオブザーバビリティデータと直接連携する会話型データエージェントを作成します。これにより、ユーザーとチームは、エージェントのアクティビティについて自然言語で質問し、複雑なクエリを記述することなく、即座に分析情報を得ることができます。

仕組み

堅牢な分析パイプラインをできるだけ簡単に設定できるように、次のプロセスを設計しました。

1. 必要なコードを追加する: このプラグインでは、エージェントを構築する際に ADK のアプリケーション（アプリ）コンポーネントを使用する必要があります。次のコードは、新しいプラグインを初期化してアプリの一部にする方法を示しています。

code_block: <ListValue: [StructValue([('code', '# --- プラグインを初期化 ---\r\nbq_logging_plugin = BigQueryAgentAnalyticsPlugin(\r\n project_id=PROJECT_ID, \r\n dataset_id=DATASET_ID, \r\n table_id="agent_events" # 任意\r\n)\r\n\r\n# --- モデルとルートエージェントを初期化 ---\r\nllm = Gemini(\r\n model="gemini-2.5-flash",\r\n)\r\n\r\nroot_agent = Agent(\r\n model=llm,\r\n name=\'my_adk_agent\',\r\n instruction="You are a helpful assistant"\r\n\r\n)\r\n\r\n# --- アプリを作成 ---\r\napp = App(\r\n name="my_adk_agent",\r\n root_agent=root_agent,\r\n plugins=[bq_logging_plugin], # ここでプラグインを登録\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9bd42d8e20>)])]>

2. ストリーミングする内容を選択し、前処理をカスタマイズ: BigQuery に送信するデータを完全に制御できます。ストリーミングする特定のイベントを選択して、自分のニーズと最も関連性の高いデータのみをキャプチャできます。次のコード例では、ログに記録する前にドル表記の金額を秘匿化しています。

code_block: <ListValue: [StructValue([('code', 'import json\r\nimport re\r\n\r\nfrom google.adk.plugins.bigquery_agent_analytics_plugin import BigQueryLoggerConfig\r\n\r\n\r\ndef redact_dollar_amounts(event_content: Any) -> str:\r\n """\r\n Custom formatter to redact dollar amounts (e.g., $600, $12.50)\r\n and ensure JSON output if the input is a dict.\r\n """\r\n text_content = ""\r\n if isinstance(event_content, dict):\r\n text_content = json.dumps(event_content)\r\n else:\r\n text_content = str(event_content)\r\n\r\n # ドル表記の金額を検索する正規表現: $ の後に数字。任意でカンマまたは小数点を使用可能。\r\n # 例: $600、$1,200.50、$0.99\r\n\r\n redacted_content = re.sub(r\'\\$\\d+(?:,\\d{3})*(?:\\.\\d+)?\', \'xxx\', text_content)\r\n return redacted_content\r\n\r\nconfig = BigQueryLoggerConfig(\r\n enabled=True,\r\n event_allowlist=["LLM_REQUEST", "LLM_RESPONSE"], # これらのイベントのみを記録\r\n shutdown_timeout=10.0, # 終了時にログがフラッシュされるまで最大 10 秒待機\r\n client_close_timeout=2.0, # BQ クライアントが終了するまで最大 2 秒待機\r\n max_content_length=500, # コンテンツを 500 文字に切り捨て（デフォルト）\r\n content_formatter=redact_dollar_amounts, # ログ内容のドル表記の金額を秘匿化\r\n)\r\n\r\nplugin = BigQueryAgentAnalyticsPlugin(..., config=config)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9bd42d8fd0>)])]>

以上です。必要な BigQuery テーブルを正しいスキーマで自動作成し、エージェントデータをリアルタイムでストリーミングするなど、残りの処理はプラグインが行います。

これで、使い慣れた BigQuery セマンティクスを使用して、エージェントの指標を分析する準備が整いました。空でない列に対して「select * limit 10」を使用して BigQuery テーブルに表示されるログの例は以下のとおりです。

使ってみる

エージェントの可能性を最大限に引き出すときが来ました。新しい BigQuery Agent Analytics を使用すると、重要な疑問の答えを明らかにして、エージェントを改良し、パフォーマンスを最適化して、優れたユーザーエクスペリエンスを提供できます。近いうちに、LangGraph との統合によるマルチモーダルエージェントインタラクションの高度な分析など、さらに多くの機能が追加される予定です。

まずは、Google ADK サイトで Google Cloud BigQuery Agent Analytics のドキュメントをご確認ください。このプラグインの使用方法に関するガイド付きチュートリアルについては、包括的な新しい Codelab をご覧ください。

皆様が構築する、データドリブンな素晴らしい会話型エクスペリエンスを拝見できることを楽しみにしております。

エンジニアリング担当シニアディレクター Ganesh Kumar Gella
プロダクトリード Sandeep Karmarkar

NTTドコモ社内データ活用基盤の裏側 - Cloud Run が支える開発の民主化とデータ活用の未来

Fri, 21 Nov 2025 02:00:00 +0000

「つなごう。驚きを。幸せを。」というブランドスローガンをかかげ、通信サービスだけでなく金融決済サービスやエンタメサービスなど多様な事業に取り組む株式会社 NTTドコモ（以下、NTTドコモ）。NTTドコモが保有する数十 PB（ペタバイト）級の膨大なデータを、全社員が迅速かつ安全に活用できるようにするために、社内データ活用基盤「Pochi」が開発されました。その開発で採用された Google Cloud のモダンなサービス群と、それによって実現した開発の民主化、そして生成 AI を活用した未来の展望について、今回は、NTTドコモデータプラットフォーム部（以下、DP 部）の吉田氏、藤平氏、黒須氏、と開発支援するNTTデータの兼子氏にお話を伺いました。

データ活用を 9 割高速化せよ - 全社データ活用基盤「Pochi」開発の背景

1 億人を超える dポイントクラブ会員、約 7,200 万の携帯電話契約者など、膨大かつ多様な顧客データを保有する NTTドコモ。このデータを事業成長の武器とすべく、これまでもメール施策の配信リスト作成など、様々なデータ活用が行われてきました。

しかし、そこには大きな課題がありました。事業部門の担当者がデータ抽出を必要とする場合、専門部署に依頼する必要があり、そのプロセスが複雑でした。「依頼書を作成し、専門部署が要件をヒアリングし、SQL を設計し、すり合わせを行う。この一連の流れで、データ抽出までに 2 週間以上かかるケースも珍しくありませんでした。」と黒須氏は語ります。

この状況を打破し、「データ活用までにかかる期間を 9 割削減する」という高い目標を掲げてスタートしたのが、データ活用基盤「Pochi」の開発プロジェクトでした。

「Pochi」が目指したのは、専門家でなくても、誰もが簡単かつ安全にデータを扱えるようにすること。そのために、UI フレームワークとして Streamlit を採用し、直感的な操作でデータ抽出や分析ができるアプリケーションを、迅速に開発・提供できる基盤を構築することにしたのです。

“誰でも開発者”を実現するモダンな開発環境の裏側

「Pochi」の成功を支えているのは、そのアプリケーションだけではありません。全社員が開発者になり得る「開発の民主化」を支える、モダンでセキュアな開発環境の存在が不可欠でした。その中核を担っているのが、Google Cloud のマネージドサービスです。

現在「Pochi」上で稼働する 133 の Streamlit アプリケーションは、すべて Cloud Run でホスティングされています。開発チームが Cloud Run に感じているメリットは多岐にわたります。

「Cloud Run はインスタンス数ゼロまでスケールインができるのがとても魅力的です。分析系のアプリの場合、そのアプリが実際のどの程度利用されるかがデプロイしてみないと分からないことも多いです。Cloud Run ではアクセスがない場合はゼロまでスケールインするので、コストを気にせず『どれだけ使うかわからないけど、まずリリースしてみよう』という文化が生まれました。」と兼子氏は話します。

また、「Pochi」の大きな特徴は、開発者が DP 部のメンバーに限らないことです。事業部門や支社の社員など、現在では 300 人以上の開発者が存在します。このため、それぞれの開発環境をいかにセキュアに、かつ簡単に提供できるかが重要でした。

当初は Google Compute Engine 上に共有の開発環境を構築し、複数のユーザーが環境にログインして開発をしていましたが、SSH キーやポートの管理が発生する上、コンピューティングリソースの奪い合いが発生するなど、効率的かつセキュアな運用管理が課題でした。そこで採用されたのが Cloud Workstations です。

「Cloud Workstations は、ワンクリックで自分専用の開発環境が立ち上がります。開発者のスキルレベルは、今回の開発をきっかけに Python を覚えた初心者から、10 年選手のベテランまで様々ですが、誰もが開発のハードルを低く感じられるようになりました。」

ブラウザから直接アクセスできる手軽さや、インスタンスの消し忘れによる不要なコスト発生を防ぐアイドルシャットダウン機能も、開発者と管理者双方にとって大きなメリットです。また、カスタムコンテナイメージによって全社の開発環境を統一し、安全にアップデートしていく仕組みも構築しています。

さらに、「Pochi」の基盤を構築し継続的に進化させる上でテクノロジーパートナーである NTTデータの存在も不可欠であったと藤平氏は振り返ります。従来の開発現場にありがちな要件を元にした受発注の関係を越えて、一人の技術者として Pochi を良いものにする思いが共有され、積極的な提案が可能な「垣根を意識しない」良好な関係性が、Pochi の成功に寄与しています。

開発の民主化が生んだ成果と、AI エージェントが実現する次のステージ

「Pochi」の導入は、NTTドコモ社内のデータ活用に劇的な変化をもたらしました。現在、月間アクティブユーザー（MAU）は 4,700 人を超え、年間 74 万回以上利用され、累計で 30 万時間もの業務稼働削減に貢献しています。

そして、最も注目すべき成果の一つは「開発の民主化」の成功です。現在稼働する 133 個のアプリのうち、最もアクセス数が多いアプリは、なんと関西支社の現場のメンバーが開発したものです。

「その方は、社内の研修プログラムで Python と SQL を習得し、現場の課題を解決したいという想いから開発に参加してくれました。現場の担当者が作ったアプリは、やはり現場のニーズに即しており、利用者からの人気も高い。これは、私たちが当初から目指していた理想の姿です。」と吉田氏は話します。

アプリが増える一方で、新たな課題も生まれました。「どのアプリを使えば自分のやりたいことができるのか分からない」というユーザーの声です。この課題に対し、チームは生成 AI の活用に乗り出しました。

各アプリのリポジトリにある README などのドキュメントを、Vertex AI RAG Engine を使って検索可能なナレッジベースとして整備。そして、ユーザーが自然言語でやりたいことを入力すると、Gemini がその意図を汲み取り、最適なアプリを推薦してくれる機能を開発しました。

この機能の開発に携わった担当者は、その能力に驚きを隠せません。「正直、Pochi のアプリについては自分が一番詳しいと思っていましたが、自分よりも詳しいんです。自分が思いつかなかったようなアプリの組み合わせを提案してくれることもあり、AI が持つ知識の広さと深さを実感しました。」

NTTドコモの挑戦はここで終わりません。現在はアプリを「推薦」するにとどまっている AI の役割を、さらに一歩進めようとしています。

「将来的には、個々のアプリが持つ機能を部品として AI が扱えるようにしたいと考えています。例えばユーザーが『こういう条件でデータを抽出して、グラフ化してほしい』と指示するだけで、AI が複数のアプリ機能を自律的に組み合わせて実行し、結果を提示してくれる。ユーザーが画面を直接操作しなくても、対話するだけでデータ活用が完結する世界です。」

事業戦略の核としてコンシューマーサービスの更なる成長を目指す NTTドコモにとって、誰でも簡単にデータを活用できる基盤「Pochi」はまさに戦略上の重要な取り組みとなります。「つなごう。驚きを。幸せを。」というブランドスローガンの実現、そして AI エージェントが自律的にデータ活用を完結させるという次のステージに向けて、NTTドコモの挑戦は続きます。

インタビュイー（写真右から）
・吉田祥平氏 (株式会社NTTドコモコンシューマサービスカンパニーデータプラットフォーム部データ基盤担当部長)

・藤平亮氏 (株式会社NTTドコモコンシューマサービスカンパニーデータプラットフォーム部データ基盤 Senior Principal Data Scientist)

・黒須遥介氏 (株式会社NTTドコモコンシューマサービスカンパニーデータプラットフォーム部データ基盤データプロダクト担当)

・兼子菜緒見氏 (株式会社NTTデータテクノロジーコンサルティング事業本部テクノロジーコンサルティング事業部課長代理)

株式会社NTTドコモ
国内約 9,000 万ユーザーを擁する日本最大の携帯電話事業者。携帯電話サービス、光通信サービスなどからなる通信事業を主軸に、近年は動画配信などのコンテンツ・ライフスタイルサービスや金融・決済サービスなどのスマートライフ領域事業も意欲的に展開。従業員数は 9,433 名、グループ全体では 5 万 1,698 名（2025 年 3 月 31 日時点）。

株式会社NTTデータ
1988 年 5 月設立。多様な産業分野に向けて IT システムの企画・構築・運用からコンサルティング、研究開発まで幅広いサービスを提供。官公庁や金融など社会基盤を支える実績を持ち、クラウド活用による先進的なソリューション展開を推進している。近年は「LITRON®」ブランドで多様な AI エージェントソリューションを展開しており、Google Cloud 上でも柔軟に構築可能なサービスをラインナップ。生成 AI を活用したお客様の業務効率化と価値創出を支援している。

Agent Sandbox のご紹介: Kubernetes と GKE 上のエージェント AI 向けの強力なガードレール

Wed, 19 Nov 2025 01:50:00 +0000

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

Google とクラウドネイティブコミュニティは、最新のアプリケーションをサポートするために Kubernetes を絶えず強化してきました。今年初めの KubeCon EU 2025 では、AI 推論のサポートを強化するための Kubernetes の一連の機能強化を発表しました。本日 KubeCon NA 2025 で発表した Agent Sandbox をはじまりとして、Google は Kubernetes を AI エージェントにとって最もオープンでスケーラブルなプラットフォームに進化させることを目指します。

AI エージェント導入に伴う課題について考えてみましょう。AI エージェントは、アプリケーションとそれを利用するユーザーが目的を効率的に達成するために、単純なクエリの回答から複雑なマルチステップタスクの実行まで、さまざまな支援を提供できます。「前四半期の販売データを可視化して」というリクエストが与えられたら、まず最初のツールでデータをクエリし、2 つ目のツールでそのデータをグラフ化してユーザーに返さなければなりません。従来のソフトウェアが予測可能で決定論的に動くものであるのに対し、AI エージェントは、コードの生成、コンピュータターミナルやブラウザの使用など、ユーザーの目標達成のために利用できるツールを「いつ、どのように」使うかを自ら判断できます。

非決定論的に動ける強力なエージェントをオーケストレーションするには、強固なセキュリティと運用上のガードレールを施さなければ重大なリスクが生じる可能性があります。コードとコマンドを実行するエージェントをカーネルレベルで分離することは、妥協できない要件です。また従来型のアプリケーションと比べて、AI とエージェントベースのワークロードではインフラストラクチャのニーズも高まります。なかでも、数千ものサンドボックスをエフェメラル環境としてオーケストレートし、必要に応じて迅速に作成と削除を行いつつ、ネットワークアクセスを確実に制限するという AI ワークロード固有のニーズがあります。

成熟度、セキュリティ、スケーラビリティを備えた Kubernetes は、AI エージェントを実行するのに最適な基盤であると Google は考えています。しかし、エージェントによるコード実行やコンピュータの使用などのニーズを満せるまでには一層の進化が必要であることも認識しており、その方向への取り組みの第一歩が、今回発表した Agent Sandbox になります。

堅牢な分離と高いスケーラビリティ

エージェントによるコード実行とコンピュータの使用のために、タスクごとに隔離されたサンドボックスをプロビジョニングする必要があります。さらに、数千ものサンドボックスが同時に実行されるような状況でも、ユーザーはインフラストラクチャが遅れをとることなく対応できるものと期待しています。

Kubernetes コミュニティと共同で構築した Agent Sandbox は、エージェントによるコード実行とコンピュータの使用に特化して設計され、次世代のエージェント AI ワークロードに必要なパフォーマンスとスケーリングを実現するた新しい Kubernetes プリミティブです。Agent Sandbox は gVisor を基盤として構築され、ランタイム分離のための Kata Containers のサポートが追加されています。gVisor の強力なセキュリティ境界を提供することで、データの損失や引き出し、本番環境システムへの損害につながる可能性のある脆弱性のリスクを軽減します。オープンソースへの継続的な取り組みとして、Agent Sandbox は Kubernetes コミュニティの Cloud Native Computing Foundation（CNCF）プロジェクトとして構築されています。

GKE でのパフォーマンスの向上

最小のコストで最高のエージェントユーザーエクスペリエンスを提供するには、強固な分離だけでなく、エージェントをスケールさせてパフォーマンスを最適化する必要もあります。Google Kubernetes Engine（GKE）で Agent Sandbox を使用すると、GKE Sandbox 内のマネージド gVisor とコンテナ最適化コンピューティングプラットフォームを活用して、サンドボックスをより迅速に水平スケーリングできます。また、Agent Sandbox では管理者があらかじめサンドボックスのウォームプールを構成できるため、サンドボックスを低レイテンシで起動できます。この機能により、Agent Sandbox では完全隔離されたエージェントワークロードのレイテンシが 1 秒未満となり、コールドスタートと比較して最大 90% の改善を実現します。

隔離された環境で外部からの脅威を防ぐというサンドボックスの特性は、その一方でコンピューティングリソースの利用率低下の原因にもなります。スクリプトを使って各サンドボックス環境を再初期化する方法は、不安定で時間もかかり、アイドル状態のサンドボックスは貴重なコンピューティングサイクルを無駄にしてしまいがちです。実行中のサンドボックス環境のスナップショットを取得して、特定の状態から開始できるようにするのが理想的な方法です。

Pod Snapshots は、実行中の Pod の完全なチェックポイントと復元を可能にする、GKE 専用の新機能です。Pod Snapshots は、エージェントと AI のワークロードの起動レイテンシを大幅に短縮します。Pod Snapshots を Agent Sandbox と組み合わせると、スナップショットからサンドボックス環境をプロビジョニングできるため、数秒で起動できます。GKE Pod Snapshots は、CPU ベースと GPU ベースの両方のワークロードのスナップショットと復元をサポートしており、これまで数分を要した Pod の起動時間を数秒に短縮します。Pod Snapshots 使ってアイドル状態のサンドボックスのスナップショットを作成して一時停止できるため、エンドユーザーへの影響を最小限に抑えながらコンピューティングサイクルを大幅に節約できます。

AI エンジニアのためのサンドボックス

エージェント AI や強化学習（RL）システムを現在構築しているチームは、インフラストラクチャの専門家である必要はありません。そのような AI エンジニアを念頭に置いて構築された Agent Sandbox には、基盤となるインフラストラクチャを気にすることなく、サンドボックスのライフサイクルを管理できるように API と Python SDK が設計されています。

code_block: <ListValue: [StructValue([('code', 'from agentic_sandbox import Sandbox\r\n\r\n# SDK はすべての YAML を単純なコンテキストマネージャーに抽象化する\r\nwith Sandbox(template_name="python3-template",namespace="ai-agents") as sandbox:\r\n\r\n # サンドボックス内でコマンドを実行する\r\n result = sandbox.run("print(\'Hello from inside the sandbox!\')")'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9be6da4670>)])]>

このように分けてしまうことで、AI デベロッパーは自分が得意とする役割に専念しながら、Kubernetes 管理者やオペレーターが期待する運用上の制御や拡張性も実現できます。

今すぐ使ってみる

エージェント AI は、ソフトウェア開発とインフラストラクチャの両チームに大きな変化をもたらします。Agent Sandbox と GKE は、エージェントに必要な分離とパフォーマンスを実現するのに役立ちます。オープンソースで提供されている Agent Sandbox は、今すぐ GKE にデプロイできます。GKE Pod Snapshots は限定プレビュー版で提供されており、今年後半にすべての GKE のお客様にご利用いただける予定です。まずは、Agent Sandbox のドキュメントとクイックスタートをご覧ください。皆様がどのようなものを構築されるか楽しみにしております。

ーシニアプロダクトマネージャー、Brandon Royal

Google Cloud でのカオスエンジニアリング: 原則、実践、開始方法

Mon, 27 Oct 2025 01:30:00 +0000

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

エンジニアであれば誰でも、完璧な復元力を持つシステムを夢見ます。完璧にスケーリングし、優れたユーザーエクスペリエンスを提供し、決してダウンしないシステムです。このような復元力のあるシステムを構築する鍵が、障害を回避することではなく、意図的に障害を引き起こすことだとしたらどうでしょうか。カオスエンジニアリングの世界へようこそ。ここでは、管理された環境でシステムにカオス（障害）を導入して、システムにストレステストを行います。ダウンタイムが数百万ドルの損失につながり、評判が瞬く間に失墜する時代において、最も革新的な企業としては、災害が起こるのをただ待っているだけではいけません。災害を意図的に引き起こし、その結果として生じる障害から学び、本番環境で混乱が起こる前に混乱に対する免疫を獲得して行くのです。

カオスエンジニアリングはあらゆる種類のシステムに役立ちますが、特にクラウドベースの分散システムに有効です。最新のアーキテクチャは、モノリシックなシステムからマイクロサービスベースのシステムへと進化し、多くの場合、数百から数千のサービスで構成されています。このように複雑なサービス依存関係は、複数の障害点をもたらします。また、従来のテスト方法では、あらゆる障害モードを予測することは、不可能ではなくても、困難です。これらのアプリケーションをクラウドにデプロイすると、複数のアベイラビリティゾーンとリージョンにデプロイされます。クラウド環境は分散性が高く、多数のサービスが共存しているため、障害の発生する可能性が高くなっています。

良くある誤解ですが、クラウド環境ではアプリケーションには自ずと復元力があるので、テストは不要であるというものがあります。クラウドプロバイダは、クラウドプロダクトに対してさまざまなレベルの復元力と SLA を提供していますが、これだけではビジネスアプリケーションが保護されるとは限りません。アプリケーションがフォールトトレラントになるように設計されていない場合や、クラウドサービスが常に利用可能であることを前提としている場合、依存している特定のクラウドサービスが利用できなくなると、アプリケーションは動作しなくなります。

手短に言えば、カオスエンジニアリングは、担当者にとって最悪の「もしも」のシナリオを想定し、それに対する対応を十分にリハーサルできるようにします。カオスエンジニアリングは、システムを破壊すること（いわばカオスなエンジニアリング）ではありません。カオスエンジニアリングは、管理された条件下とはいえ、すでにカオスを乗り切った経験から得られる冷静な自信を持って本番環境のインシデントに対処できるチームを構築することです。

Google Cloud の Professional Service Organization（PSO）エンタープライズアーキテクチャチームは、アプリケーション開発、クラウド移行、エンタープライズアーキテクチャなど、お客様のクラウド変革の取り組みについてコンサルティングを行い、実践的な専門知識を提供しています。また、クラウド環境向けの復元力のあるアーキテクチャの設計についてアドバイスする際には、カオスエンジニアリングの原則とプラクティス、およびサイト信頼性エンジニアリング（SRE）のプラクティスを定期的に紹介しています。

シリーズの最初になるこのブログ投稿では、カオスエンジニアリングの基本、つまりカオスエンジニアリングとは何か、そのコアとなる原則と要素について説明します。次に、クラウドで分散アプリケーションを実行しているチームにとって、カオスエンジニアリングが特に役立ち、重要である理由を説明します。最後に、これを活用開始する方法と、その他のリソースについて説明します。

カオスエンジニアリングについて

カオスエンジニアリングは、Netflix が 2010 年に考案した手法です。AWS 環境の複雑度が上がる中、より復元力と信頼性が高いシステムを構築する必要性に対処するため、「Chaos Monkey」を作り出し、普及させました。同じ頃、Google は障害復旧テスト（DiRT）を導入しました。これにより、Google のビジネス、システム、データの継続的て、自動的な障害対策、対応、復旧が可能になりました。Google Cloud の PSO チームでは、お客様が SRE プラクティスの一環として DiRT を実装できるよう、さまざまなサービスを提供しています。これらのサービスには、Google Cloud で動作するアプリケーションやシステムで DiRT を実行する方法に関するトレーニングも含まれています。中心となるコンセプトは単純です。管理された障害を意図的にシステムに導入して、脆弱性を特定し、その復元力を評価し、全体的な信頼性を高めるというものです。

予防的な手法であるカオスエンジニアリングにより、組織はシステム内の弱点を、大規模なサービス停止や障害につながる前に特定できます。ここで言うシステムには、技術的なコンポーネントだけでなく、組織の人員やプロセスまでも含まれます。カオスエンジニアリングでは、管理された、実際の停止状態を導入することで、システムの堅牢性、復元可能性、フォールトトレランスをテストできます。このアプローチによって担当者は潜在的な脆弱性を発見できるため、システムは予期しないイベントに対処し、ストレス下でもスムーズに機能し続けることができます。

カオスエンジニアリングの原則と実践

カオスエンジニアリングは、これを実施すべき理由に関する一連の基本原則によって導かれ、また実践は実施すべき内容を定めます。

カオスエンジニアリングの原則は次のとおりです。

定常状態に関する仮説を立てる: 停止を引き起こすアクションを開始する前に、システムにとっての「正常」な状態がどのようなものかを決定する必要があります。これは一般に「定常状態仮説」と呼ばれます。
現実世界の状況を再現する: カオステストでは、本番環境でシステムが遭遇する可能性のある現実的な障害シナリオをエミュレートします。
本番環境でテストを実行する: カオスエンジニアリングは、実際のトラフィックと、依存関係の両方がある本番環境でのみ復元力の正確な全体像を把握できるという信念にしっかりと根ざしています。これが、カオスエンジニアリングと従来のテストの違いです。
テストの自動化: 復元力テストを、一度限りのテストではなく、継続的なプロセスの一部にします。
影響範囲を特定する: 本番環境システムへの悪影響を最小限に抑えるために、テストは綿密に設計する必要があります。そのためには、テストが顧客や他のアプリケーション、サービスに与える影響に基づいて、アプリケーションとサービスをさまざまな階層に分類する必要があります。

これらの原則を確立したら、カオスエンジニアリングのテストを実施する際に次の手法に従います。

定常状態を定義する: 注目する特定の指標（レイテンシ、スループットなど）を特定し、それらのベースラインを確立します。
仮説を立てる: これは、テスト可能な単一のステートメントを作成する手法です。たとえば、「このコンテナ Pod を削除しても、ユーザーのログインには影響しない」などです。仮説は通常、お客様のユーザージャーニーを特定し、そこからテストシナリオを導き出すことで作成されます。
管理された環境を使用する: カオスエンジニアリングの原則の一つに、テストは本番環境で実行する必要があるというものがありますが、まずは小規模に始め、非本番環境でテストを実行し、学び、調整してから、徐々に本番環境に範囲を拡大するようにしてください。
障害の注入: これは、システムに直接（VM の削除、データベースインスタンスの停止など）または環境に間接的に（ネットワークルートの削除、ファイアウォールルールの追加など）障害を注入して、停止状態を引き起こす手法です。
テストの実行を自動化する: カオスエンジニアリングを再現可能でスケーラブルなプラクティスとして確立するには、自動化が不可欠です。これには、障害注入に自動ツールを使用すること（CI/CD パイプラインの一部にするなど）や、自動ロールバックメカニズムを使用することが含まれます。
行動につながるインサイトを導き出す: カオスエンジニアリングを使用する主な目的は、システムの脆弱性に関するインサイトを導き出し、それによって復元力を高めることです。これには、テスト結果の厳密な分析、弱点と改善すべき点の特定、関連チームへのテスト結果の周知が含まれ、これによってその後のテスト設計とシステム強化を行います。

つまり、カオスエンジニアリングは、単にシステムを壊すことが目的ではなく、システムの限界を理解し、それらに事前に対処することで、より復元力の高いシステムを構築することが目的です。

カオスエンジニアリングの要素

カオスエンジニアリングテストで使用するコア要素は、次の 5 つの原則から導き出されます。

テスト: カオステストは、システムに障害を発生させてその応答を確認する、意図的で事前に計画された手順で構成されます。
定常状態仮説: 定常状態仮説は、評価対象のシステムのベースラインとなる運用状態、つまり「正常」な動作を定義します。
アクション: アクションは、テスト対象のシステムに対して実行される具体的なオペレーションを表します。
プローブ: プローブは、テスト中にシステム内で定義された条件を観察するメカニズムを提供します。
ロールバック: テストでは、テスト中に実装された変更を元に戻すように設計された一連のアクションが組み込まれる場合があります。

カオスエンジニアリングを開始する

カオスエンジニアリングと、クラウド環境でカオスエンジニアリングを使用する理由について理解を深めたら、次のステップとして、独自の開発環境で実際に試してみましょう。

市場には複数のカオスエンジニアリングソリューションがあります。有料のプロダクトもあれば、オープンソースのフレームワークもあります。すぐに始めるには、Chaos Toolkit をカオスエンジニアリングフレームワークとして使用することをおすすめします。

Chaos Toolkit は、Python で記述されたオープンソースのフレームワークです。モジュール式のアーキテクチャが提供されており、他のライブラリ（「ドライバ」とも呼ばれます）をプラグインして、カオスエンジニアリングのテストを拡張できます。たとえば、Google Cloud、Kubernetes、その他多くのテクノロジーの拡張ライブラリがあります。Chaos Toolkit は Python ベースの開発者ツールであるため、まず Python 環境を構成します。Chaos Toolkit のテストの優れた例と、その手順については、こちらをご覧ください。

最後に、Google Cloud のお客様とエンジニアがアプリケーションにカオステストを導入できるように、特に Google Cloud のための一群のカオスエンジニアリングレシピを作成しました。各レシピには、特定の Google Cloud サービスにカオスを導入する特定のシナリオを収めています。たとえば、あるレシピでは Google Cloud の内部または外部アプリケーションロードバランサの背後で実行されているアプリケーション/サービスにカオスを導入し、また別のレシピでは ToxiProxy という別の Chaos Toolkit 拡張機能を利用して、Cloud Run で実行されているアプリケーションと Cloud SQL データベースに接続するアプリケーション間のネットワーク停止をシミュレートします。

Google Cloud 環境にカオスエンジニアリングを導入する方法を学ぶための、手順ガイド、スクリプト、サンプルコードを含むレシピの完全なコレクションは、GitHub にあります。今後の投稿では、Google Cloud 環境に障害を導入する方法など、カオスエンジニアリングの手法を取り上げますので、ご期待ください。

-Parag Doshi、キーエンタープライズアーキテクト

製薬業界の開発を変革する中外製薬の挑戦：Gemini Code Assist 活用で開発速度は最大 5 倍に

Wed, 22 Oct 2025 02:00:00 +0000

日本の製薬業界をリードする中外製薬株式会社（以下、中外製薬）は、Google の AI、Gemini を活用したコーディングエージェント「Gemini Code Assist」を導入し、開発プロセスに大きな変革をもたらしています。臨床開発からアジャイルなソフトウェア開発、データサイエンスまで、多様な分野で Gemini Code Assist がどのように活用され、どのような成果を上げているのか、具体的な事例を交えてご紹介します。

今回お話を伺ったのは、多様な立場で Gemini Code Assist の活用を推進する 3 名のキーパーソンです。バイオメトリクス部で AI を活用した臨床開発を推進する高野様。デジタルソリューション部アジャイル開発グループで、全社向け生成 AI アプリ「Chugai AI Assistant」などを開発する尾形様。そして、デジタルソリューション部データサイエンスグループで、データサイエンスの観点から AI モデルの精度改善や創薬研究支援まで幅広く手がける水谷様。それぞれの視点から、具体的な取り組みについて語っていただきました。

属人化と心理的ハードル、AI 導入前の開発課題

Gemini Code Assist 導入以前、中外製薬の開発現場ではいくつかの課題に直面していました。

臨床開発部門の高野様は、「ビジネスサイドである臨床部門では、アプリケーション開発ができる人材が限られており、新しいアプリケーション開発に対する心理的なハードルが高かった」と語ります。「従来は 1 つのアプリケーションを開発するだけでも相当な工数がかかり、じっくりと要件をヒアリングして、効果があるものなのかを精査した上で企画書にまとめてから作り始めるというプロセスを踏んでいました。特に外部へ委託する案件では、効果の定量化やマネジメント承認といったハードルがさらに高くなるため、気軽に『作ってみよう』とは言えない状況でした。」

また、アジャイルなアプリ内製開発と全社展開を推進するアジャイル開発グループの尾形様は、「一度決めた仕様はなかなか変更できず、フィードバックを受けて改善するサイクルを迅速に回すことが困難でした」と振り返ります。

データサイエンスグループの水谷様も同様に、従来の開発スタイルに課題を感じていました。「LLM が登場した当初は、生成されたコードが自身の環境で動作しないことや、意図と異なるコードが出力されることがありました。また、ライブラリのバージョンの問題で、自身の環境では動作しないといったこともありました。」

プロトタイピングを加速し、開発文化を変革する Gemini Code Assist

Gemini Code Assist の導入は、これらの課題を解決し、開発文化そのものを変革するきっかけとなりました。選定の決め手となったのは、主に「コンテキスト性能」「ライセンス体系」「Google Cloud との親和性」の 3 点でした。

尾形様が特に評価したのは、Gemini Code Assist の基盤となる Gemini モデルが持つ、膨大な情報から開発者の意図を正確に汲み取る広いコンテキストウィンドウです。これにより、他製品と比較してエラーが少なく、精度の高いコード生成が可能になります。加えて、高野様は、多くの他製品が従量課金制である中で、開発時間や予算を気にせず利用できるサブスクリプション体系を魅力に感じています。データサイエンスを担う水谷様にとっては、BigQuery の SQL を容易に作成できるなど、既存の Google Cloud 環境とシームレスに連携できる点も大きな利点でした。

これらの特長が、中外製薬の開発プロセスに具体的な変化をもたらします。高野様は、まず開発着手までのプロセスが劇的に変化したと話します。「以前は数週間かかっていたプロトタイプの作成が、今では数十分で可能になりました。ビジネスユーザーからの『こんなアプリはできないか』というフランクな相談に対し、その場ですぐにモックアップを作ってイメージをすり合わせることができます。アプリ開発について詳しくない臨床開発のメンバーに対しても完成イメージをすぐに共有することができるため、実現可能性を迅速に検証できるようになりました。」

この変化は、開発の進め方にも影響を与えています。「以前は要件を固めてから開発していましたが、今は『まず作って、見てもらう』というサイクルを高速で回すスタイルに変わりました。完成度が高くなくても、早い段階でフィードバックをもらい、改善を重ねていく。このアジャイルなアプローチが、ビジネス部門主導の開発を可能にしています。」

臨床開発、アジャイル開発、データサイエンス ―― 多様な現場での活用事例

Gemini Code Assist は、部門の垣根を越えて、それぞれの専門領域で効果を発揮しています。

高野様（臨床開発） 臨床試験では、規制当局へ提出するための文書など、膨大な量のドキュメント作成が求められます。高野様は Gemini Code Assist を活用し、これらのドキュメント作成を効率化するための AI エージェント開発に取り組んでいます。特に、最近追加されたエージェントモード（Gemini CLI と連携し、目標を複数のステップに分解し、必要なツールを使いながら自律的に計画を実行・修正）は、開発の幅を広げる上で大きな役割を果たしていると語ります。「エージェントモードのおかげで、これまで自身の得意な Python や Streamlit に限定されがちだった開発の幅が広がり、React のような自分にとって未知の言語やフレームワークにも気軽に挑戦できるようになりました。最適な技術を選択して、より良いアプリケーションを迅速に開発できるようになったのは大きな進歩です。」

尾形様（アジャイル開発） 全社向けの生成 AI アプリケーション「Chugai AI Assistant」をはじめ、様々なアプリケーション開発に Gemini Code Assist を活用しています。特にエージェントモードの登場は、働き方を大きく変えたと語ります。「要件を伝えるだけで、エージェントが既存のコードベースを理解し、変更箇所を提案、そして実装まで一気通貫で行ってくれます。エラーが発生した際も、エラーメッセージを貼り付けるだけで原因分析と解決策を提示してくれる。現在は、AI に適切な指示を出して効率的に開発を進めることが、業務の中心になっています。」

水谷様（データサイエンス） データサイエンスの領域でも Gemini Code Assist は不可欠なツールです。水谷様は、論文の再現実装、コードのリファクタリング、データ分析など、幅広い業務で活用しています。「論文のテキストを渡すだけで、その内容を実装してくれます。また、自身で書いた雑多なコードを、ベストプラクティスに沿ったリーダブルなコードに整理してくれるので、コードの品質が格段に向上しました。」さらに、データ分析のプロセス自体も変化しています。「Jupyter Notebook 上でデータを可視化すると、Gemini Code Assist がその結果を解釈し、インサイトまで提供してくれます。単なるコーディング支援に留まらず、データサイエンティストの思考を拡張してくれるパートナーです。」

開発速度は最大 5 倍に ―― Gemini Code Assist がもたらした定量的・定性的効果

Gemini Code Assist の導入効果は、定量的にも定性的にも表れています。

尾形様は、「体感的な開発速度は 5 倍になりました。会議の合間にエージェントに指示を出して開発を進めることができるため、時間を非常に有効活用できます。実質的に、1 時間の作業時間で 5 時間分の開発成果を得られる感覚です」と、その効果を語ります。水谷様も「3〜4 倍の効率化」を実感しており、複数のプロジェクトを並行して担当できるようになったと語ります。

高野様も、「以前は 1 年に 1、2 個のアプリケーションを開発するのがやっとでしたが、今では 3、4 個は普通に作れる感覚です」と、生産性の向上を実感しています。

これらの効果は、単に仕事が速くなっただけでなく、新しい挑戦への心理的ハードルを下げ、より多くのプロジェクトに取り組む余裕を生み出しています。

今回 Gemini Code Assist を選定された理由について、尾形様は「コンテキストウィンドウの広さ」を挙げられました。膨大な情報から開発者の意図を正確に汲み取るため、他製品と比較してエラーが少なく、コード生成の精度が高い点を評価いただいています。

加えて、高野様は「サブスクリプションのライセンス体系」を評価されています。多くの他製品が従量課金制であるのに対し、Gemini Code Assist はサブスクリプションで利用できるため、開発時間や予算超過を気にすることなく、安心して開発に集中できる点も魅力だと語ります。

水谷様は、Google Cloud 環境との親和性の高さを挙げられました。データ分析で利用する BigQuery の SQL 文を容易に作成できることや、開発環境である Cloud Workstations から手軽に利用できる点を評価されています。

AI との協業時代における、人と組織の在り方

AI の活用が広がる一方で、新たな課題も生まれています。AI を使いこなす人材とそうでない人材の生産性の差や、ジュニア層の育成、AI が生成したコードのレビュー体制などです。

尾形様は、「AI は先生としても振る舞える」と考えています。「ジュニア層は、AI が生成したコードの意図を質問し、対話することで、自身の理解を深めることができます。良いコードに触れることで、スキルアップの機会にもなります。」

中外製薬では、AI を活用した開発のベストプラクティスをドキュメント化し、社内での浸透を図っています。AI が生成したコードは 100% 正しいわけではないことを前提に、必ず人間がレビューする「ヒューマンインザループ」のプロセスを徹底しています。

未来への展望：AI と共に創る新しい開発スタイル

最後に、今後の展望について伺いました。

高野様は、「ビジネス部門が主体となって高速にアプリケーションを開発できる文化と体制を、さらに推進していきたい」と語ります。将来的には、業務ごとに特化したエージェントを複数開発し、それらをプラットフォーム上から誰もが簡単に利用できる世界を目指しています。

尾形様も、LangGraph や Dify といったツールを活用し、より高度な特化型エージェントの開発を構想しています。「個別のプロジェクト要件に合わせて、エージェントの振る舞いをノーコードで定義できるような仕組みを導入し、さらなる開発の高速化を目指します。」

水谷様は、Gemini のさらなる進化に期待を寄せています。「最新のライブラリやリファレンスをより正確に参照できるようになること、そして、より多くのファイルコンテキストを一度に扱えるようになることで、私たちの生産性はさらに向上するでしょう。」

中外製薬の挑戦は、AI が単なるツールではなく、開発者の能力を拡張し、組織全体の創造性を高めるための強力なパートナーであることを示しています。Gemini と共に歩む彼らの取り組みは、製薬業界のみならず、多くの企業の開発現場に新たな可能性を示唆していると言えるでしょう。

中外製薬株式会社は「革新的な医薬品とサービスの提供を通じて新しい価値を創造し、世界の医療と人々の健康に貢献します」をミッションとして掲げ、独自の技術とサイエンスを強みとして、ヘルスケア産業のトップイノベーターを目指しています。

インタビュイー

バイオメトリクス部臨床システム・インフォマティクスグループ高野達人様
デジタルトランスフォーメーションユニットデジタルソリューション部アジャイル開発グループ尾形遥介様
デジタルトランスフォーメーションユニットデジタルソリューション部データサイエンスグループ水谷圭佑様

新しい Gemini CLI 拡張機能でアプリのデプロイとセキュリティ分析を自動化

Wed, 01 Oct 2025 01:10:00 +0000

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

セキュリティの脆弱性を検出して修正します。アプリをクラウドにデプロイします。コマンドラインを離れる必要はありません。

このたび、2 つの新しい拡張機能（セキュリティ拡張機能と Cloud Run 拡張機能）を通じて提供する Gemini CLI の未来像を、初めてご紹介します。これによって、お客様のターミナルとクラウドの間にあるギャップを取り払います。これらの拡張機能は、ワークフローの重要な部分をシンプルで直感的なコマンドで処理するように設計されています。

1）/security:analyze は、ローカルリポジトリで包括的なスキャンを実行します。GitHub プルリクエストのサポートも近日中に提供予定です。これにより、セキュリティが開発サイクルの自然な一部になります。

2）/deploy は、フルマネージドのサーバーレスプラットフォームである Cloud Run にアプリケーションを数分でデプロイします。

これらのコマンドは、Gemini CLI の新しい拡張性フレームワークの最初の表現です。Gemini CLI 拡張機能の全容については近日中に詳しくご紹介しますが、これらの機能をいち早く皆様にお届けしたく、今後の展開を少しだけご紹介します。

セキュリティ拡張機能: /security:analyze でセキュリティ分析を自動化

チームが開発ライフサイクルの早い段階でソフトウェアの脆弱性に対処できるよう、Google は Gemini CLI Security 拡張機能をリリースします。この新しいオープンソースツールはセキュリティ分析を自動化し、ターミナルで /security:analyze コマンドを使用するか、近日中にリリースされる GitHub Actions 統合を通じて、問題をプロアクティブに検出して修正できるようにします。

ローカル開発ワークフローと CI/CD パイプラインに直接統合されたこの拡張機能は、

コード変更の分析: 拡張機能がトリガーされると、ローカルの変更または pull リクエストの git diff が自動的に取得されます。
脆弱性を特定: 専用のプロンプトとツールを使用して、Gemini CLI は、ハードコードされたシークレット、インジェクションの脆弱性、アクセス制御の不備、安全でないデータ処理など、幅広い潜在的な脆弱性について変更を分析します。
実用的なフィードバックを提供: Gemini は、詳細でわかりやすいレポートをターミナルに直接、またはプルリクエストのコメントとして返します。このレポートは、問題を指摘するだけでなく、潜在的なリスクを説明し、具体的な修復の提案を行うことで、問題を迅速に修正し、その過程で学習できるようにします。

レポートの生成後、Gemini CLI にレポートをディスクに保存するよう指示したり、各問題の修正を実装するよう指示したりすることもできます。

/security:analyze の使用を開始する

セキュリティ分析をワークフローに統合するのは簡単です。まず、Gemini CLI をダウンロードし、拡張機能をインストールします（Gemini CLI v0.4.0 以降が必要）:

code_block: <ListValue: [StructValue([('code', 'gemini extensions install https://github.com/google-gemini/gemini-cli-security'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9bd4759910>)])]>

最初のスキャンを実行します。

ローカル: ローカルで変更を加えたら、Gemini CLI で /security:analyze を実行するだけです。
CI/CD（近日提供予定）: セキュリティ分析を CI/CD ワークフローに直接組み込みます。まもなく、GitHub アクションを構成して、pull リクエストが開かれたときに自動的にレビューできるようになります。

これはほんの始まりにすぎません。チームは拡張機能の機能をさらに強化するために積極的に取り組んでおり、コミュニティにも、バグの報告、機能の提案、セキュリティプラクティスの継続的な改善、コードの改善の提出を通じて、このオープンソースプロジェクトに貢献していただくよう呼びかけています。

完全なドキュメントと投稿については、公式 GitHub リポジトリをご覧ください。

Cloud Run 拡張機能: /deploy でデプロイを自動化

Gemini CLI の /deploy コマンドは、ウェブアプリケーションのデプロイパイプライン全体を自動化します。ローカルワークスペースから直接プロジェクトをデプロイできるようになりました。コマンドを発行すると、Gemini はライブアプリケーションの公開 URL を返します。

/deploy コマンドは、Cloud Run MCP サーバーを使用して、コマンドラインからウェブアプリケーションとクラウドサービスをデプロイする完全な CI/CD パイプラインを自動化します。以前は、ビルド、コンテナ化、プッシュ、構成という複数のステップが必要でしたが、現在は Gemini CLI 内から直感的な単一のコマンドで実行できます。

この機能は、ターミナルの Gemini CLI、Gemini Code Assist エージェントモードを介した VS Code、Cloud Shell の Gemini CLI の 3 つの異なるサーフェスからアクセスできます。

ターミナルで Gemini CLI の /deploy コマンドを使用して、アプリケーションを Cloud Run にデプロイする

/deploy を使ってみる:

Google Cloud の既存ユーザーは、ターミナルの Gemini CLI で /deploy を簡単に使い始めることができます。

前提条件: マシンに gcloud CLI がインストールされ、構成されていること。既存のアプリがあるか、Gemini CLI を使用してアプリを作成すること。

ステップ 1: Cloud Run 拡張機能をインストールする/deploy コマンドは、Cloud Run 拡張機能に含まれている Model Context Protocol（MCP）サーバーを介して有効になります。Cloud Run 拡張機能をインストールするには（Gemini CLI v0.4.0 以降が必要）、次のコマンドを実行します。

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

ステップ 2: Google Cloud で認証する次のコマンドを実行して、ローカル環境が Google Cloud アカウントに対して認証されていることを確認します。

code_block: <ListValue: [StructValue([('code', 'gcloud auth login\r\ngcloud auth application-default login'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9bd4759040>)])]>

ステップ 3: アプリをデプロイするターミナルでアプリケーションのルートディレクトリに移動し、「gemini」と入力して Gemini CLI を起動します。チャットに入ったら、「/deploy」と入力してアプリを Cloud Run にデプロイします。

これで、しばらくすると、Gemini CLI から、新しくデプロイしたアプリケーションにアクセスできる公開 URL が返されます。Google Cloud コンソールにアクセスして、Cloud Run で実行されている新しいサービスを確認することもできます。

この機能は、ターミナルの Gemini CLI のほか、Gemini CLI を利用した Gemini Code Assist のエージェントモード、Cloud Shell の Gemini CLI でも利用できます。Cloud Shell の Gemini CLI では、認証手順が自動的に処理されます。

/deploy コマンドを使用して、Gemini Code Assist エージェントモードで VS Code の Cloud Run にアプリケーションをデプロイする。

堅牢な拡張機能エコシステムの構築

セキュリティ拡張機能と Cloud Run 拡張機能は、Gemini CLI のための豊富でオープンなエコシステムを構築するために設計された新しいフレームワーク上に構築された、Google の最初の拡張機能の 2 つです。Google は、あらゆるデベロッパーが CLI の機能を拡張およびカスタマイズできるプラットフォームを構築しています。これは、プラットフォームの可能性を垣間見ることができる初期プレビューにすぎません。拡張機能プラットフォームのより包括的な概要と、独自の拡張機能の構築と共有を開始する方法については、近日中にご紹介します。

今すぐ Gemini CLI をお試しください。GitHub はこちらからアクセスできます。

ーグループプロダクトマネージャー、Prithpal Bhogill

ープロダクトマネージャー Evan Otero

Eventarc Advanced で複雑なイベント処理を大規模に簡素化

Thu, 25 Sep 2025 02:00:00 +0000

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

最新のアプリケーション開発では、スケールアップだけに投資するだけでは十分でなく、簡素化と一元的なガバナンスにも投資する必要があります。これはメッセージのルーティング以上の意味を持ちます。つまり、リアルタイムで情報の流れをインテリジェントにフィルタリング、変換、管理し、複雑さをすべて 1 か所で解消できる、シンプルで統合されたメッセージングプラットフォームが必要になります。

このたび、Eventarc Advanced の一般提供を開始しました。これは、リアルタイムのフィルタリング、変換、管理、デリバリーを 1 か所に集約することで、単純なルーティングを超えた、複雑なマルチソースのイベントドリブンアーキテクチャに対応する統合されたサーバーレスのイベントプラットフォームです。

複雑性に対処するための Eventarc の進化

Eventarc Advanced は Eventarc Standard の進化版であり、イベント処理のニーズを簡素化する統合パターンをすぐに利用できます。

Eventarc Advanced では以下のことが可能です。

Publish API を使用して既存のサービスを統合し、Google Cloud イベントを活用して高度なイベントドリブンアプリケーションを構築します。
メッセージ単位のきめ細かいアクセス制御をサポートし、サービス間のメッセージフローを集中管理、保護、監視します。
インテリジェントにルーティング: 柔軟なメッセージ条件に基づいて、メッセージを適切な宛先にルーティングします。
変換: 複数のペイロード形式をサポートし、イベント属性を変換する機能が組み込まれているため、イベントをリアルタイムで変換します。
HTTP バインディングを使用して Google Cloud サービスに公開します。

Eventarc Advanced を使用すると、高度なイベントシステムを構築できます。一方、Eventarc Standard は、Google Cloud イベントを含むシンプルな 1 対 1 のイベント処理のニーズに最適です（比較）。

Eventarc Advanced の主な技術的特徴は次のとおりです。

Publish API を使用して、CloudEvents 形式でカスタムメッセージとサードパーティメッセージを取り込みます（詳細）。
メッセージバス: イベントドリブンアーキテクチャの中枢神経系として機能し、オブザーバビリティ、セキュリティ、管理を一元化します。メッセージバスは Envoy をベースとしており、Cloud Load Balancer と Cloud Service Mesh のポリシーエンジンを使用します。

既存のシステムは、中央のメッセージバスにメッセージをパブリッシュできます。このメッセージバスは、柔軟な基準に基づいて適切なコンシューマーにインテリジェントにルーティングできます。メッセージバスは、イベント管理を簡素化し、運用上のオーバーヘッドを削減します。
一元化されたモニタリング、ロギング、トレース機能により、メッセージフローに関する分析情報を得ることができます。ログは Cloud Logging でキャプチャされ、イベント処理とエラーに関する詳細な情報が提供されます。

すぐに使用できるイベントメディエーション機能により、ソースまたは宛先サービスを変更せずにメッセージをその場で適応させ、複数のペイロード形式（Avro、JSON、Protobuf）のサポートとイベント属性を変換する組み込み機能を通じてさまざまなイベントを処理できます。

Eventarc Advanced は、信頼性の高いイベント配信と一時的な障害からのスムーズな復旧を提供することで、エラー処理を組み込んでいます。

デベロッパーとオペレーターを支援

Eventarc Advanced は、デベロッパーとオペレーターの両方のニーズに対応するように設計されています。

デベロッパーにとっての「シンプルさ」: 複雑なイベントルーティングロジックではなく、アプリケーションのコア機能の構築に集中できます。Eventarc Advanced は、統合された API と一貫したエクスペリエンスを提供し、リアルタイム変換などの分離された信頼性の高いスケーラブルなサービスを構築できます。
プラットフォームオペレーター向けの「一元化されたガバナンス」: イベントインフラストラクチャのセットアップと管理を簡素化します。プロジェクトおよびチーム全体でガバナンスを一元化し、モニタリングとロギングを行うことで、問題の特定と解決が容易になり、運用オーバーヘッドが削減されます。

Eventarc Advanced の仕組み

注文の作成、支払いの処理、商品の発送を行う注文処理システムを考えてみましょう。各アクションは「イベント」であり、複雑なシステムでは、このフローの管理が困難になることがあります。そこで役立つのが Eventarc Advanced です。アプリケーションのすべてのイベントを一元的に管理、監視、ルーティングできます。この仕組みを詳しく見ていきましょう。

メッセージバスを設定する

Eventarc Advanced の中心となるのは、イベントドリブンアプリケーションの中枢神経系として機能するメッセージバスです。すべてのイベントは、その発生元にかかわらず、分析とルーティングのためにメッセージバスに送信されます。この中央ハブでは、セキュリティポリシーを定義して、イベントを送信できるユーザーと許可されるイベントの種類を正確に制御できます。

この例では、注文関連のすべてのイベントを受信するためのメッセージバスを作成します。注文が新規作成された場合、支払いが確認された場合、ステータスが「発送済み」に変更された場合など、イベントはここに記録されます。

イベントソースを接続する

次に、注文イベントを生成するソースを接続します。イベントソースは、イベントを生成してメッセージバスにフィードするサービスとアプリケーションです。Eventarc Advanced では、以下を含む幅広いソースをサポートしているため、これが簡単になります。

Google API イベント
Publish API を介した外部アプリまたはカスタムシステム

この例では、イベントソースは Publish API を使用するカスタムサービスです。新しい注文が保存されるか、既存の注文が更新されるたびに、メッセージバスにイベントが自動的に送信されます。

パイプラインと宛先の構成

これも Eventarc Advanced の優れた点です。イベントがメッセージバスに流れ込むと、パイプラインを構成して、イベントを正しい宛先にインテリジェントにルーティングできます。これにより、イベントを正確にフィルタリング、変換、指示できます。

上記の例では、次のように設定されています。

新規注文の通知: ステータスが「新規」のイベントを検索するフィルタを設定できます。このパイプラインは、これらのイベントを通知サービスにルーティングし、通知サービスが注文確認メールをお客様に送信します。
不正行為の検出: 高額な注文（例: 1,000 ドル以上）の場合、変換を適用して、分析のために専門の不正行為検出サービスにルーティングできます。

新たな可能性を切り開く

Eventarc Advanced は、アプリケーションとワークフローに新たな可能性をもたらします。

大規模なアプリケーション統合: 多数のサービスとエージェントを接続し、異なるイベント形式やスキーマ間でも、非同期で確実に通信できるようにします。
AI と分析のためのイベントストリーミング: IoT デバイスや AI ワークロードからの大量のデータを、分析パイプラインにフィードする前にフィルタリングして変換することで処理します。
ハイブリッドクラウドとマルチクラウドのデプロイ: イベントドリブンアーキテクチャを Google Cloud の枠を超えて拡張し、オンプレミスシステムや他のクラウドプロバイダと統合します。

次のステップ

昨今のアプリケーションは、エージェント化、分散化、データドリブン化が進んでおり、効率的かつ安全なイベントオーケストレーションの必要性がこれまで以上に高まっています。データパスにカスタムコードを挿入する Service Extensions のネイティブサポートと、Model Armor、Eventarc Advanced のメッセージバスなどのサービスが間もなく提供される予定です。これにより、エージェント通信のセキュリティとネットワーキング制御が提供されます。

Eventarc Advanced は今すぐご利用いただけます。Eventarc Advanced の詳細については、ドキュメントをご覧ください。イベントドリブンアーキテクチャの詳細については、Google Cloud のベストプラクティスに基づいたアーキテクチャセンターをご覧ください。イベントドリブンアーキテクチャを次のレベルに引き上げましょう。

ープロダクト管理担当ディレクター、Vidya Nagarajan Raman

ープロダクトマネージャー、Raj Duraisamy

AI エージェント開発の内製化支援へ：TAP プログラムの拡充

Wed, 24 Sep 2025 02:00:00 +0000

近年、ビジネス界では「AI エージェント」が関心の高いトピックとして注目を集めています。Google Cloud Next Tokyo の基調講演でも「AI エージェントが変える、開発、データ活用、そしてセキュリティ」や「顧客体験から働き方まで、AI エージェントがすべてを変える」と強調されたように、AI エージェントは企業の今後を形作る上で不可欠な存在となりつつあります。Agentspace、Agent Development Kit (ADK)、Agent2Agent プロトコル (A2A) といった先進的なエージェントに関する発表が相次ぎ、多くのお客様から「エージェントについて Google Cloud から紹介してほしい」というご要望や、「エージェント開発について議論したい」「プラットフォーム選定中のため、キャッチアップしたい」といったご相談が寄せられています。

Google Cloud が提供する Tech Acceleration Program (TAP) は、これまで約 3 年間にわたり、多くのお客様のアプリケーション開発の内製化に貢献してきました。当初、TAP は主にアプリケーションモダナイゼーションの領域で、迅速なアプリケーション開発や最適なアーキテクチャ設計をサポートするアジャイル型のワークショップとして提供されてきました。

そして今、AI エージェント開発の領域においても、お客様が自信を持って内製化を進められるよう、AI エージェント開発の内製化支援に対応するため、 TAP を拡充しました。

活用事例：日本テレビ放送網株式会社

「コンテンツ企画業務を支援する AI エージェント開発にあたり、Google Cloud の TAP を活用しました。企画業務のようなクリエイティブな領域で AI をどう活用すべきか、当初は手探りの状態でしたが、TAP の専門家チームに伴走していただき、業務プロセスの解像度を上げるところから支援してもらえたのが大きかったです。おかげで、単なる時短ツールではない、制作者の『暗黙知』を活かし『個性を育てる』という、我々が本当に目指すべきエージェントの姿を発見できました。Agent Development Kit などを活用した高速なプロトタイピングを通じて、具体的な効果を早期に実感できたことも、プロジェクトを力強く推進する上で非常に重要でした。」

活用事例：株式会社バンダイナムコエンターテインメント

「ゲームのプロモーションや開発において、数十時間に及ぶ膨大な録画データから目的のシーンを探し出す作業は、まさに苦痛でした。人力での検索は限界があり、AI で何とかしたいという思いはありつつも、どこから手をつけるべきか悩んでいました。そんな中、Google Cloud の TAP はまさに『決め手』となりました。合宿形式のワークショップを通じて、社内外の複数部署にまたがるチームの目線を合わせ、プロジェクトの初動をスムーズに完了できたのです。Gemini の高度な動画理解能力と、TAP を起点に蓄積した知見があったからこそ、動画検索システム『ClipSearch』の PoC は成功したと確信しています。」

AI エージェント開発における内製化の重要性と課題

AI エージェントは、ビジネスの生産性向上や顧客体験の変革を担う可能性を秘めていますが、その導入・活用には依然として多くの課題が存在します。

効果のイメージが掴みにくい：具体的な事例データの不足や、効果測定指標の設定の難しさから、導入後の具体的な効果をイメージしにくいという声が聞かれます。
スキル・リソースの不足：AI 技術に関する深い理解に加え、ビジネス課題と技術を橋渡しするスキルや幅広い知識が求められますが、こうしたリソースが不足している企業も少なくなく、スキルギャップの解消が急務となっています。
倫理的な問題・リスクへの懸念：データサイエンティストや専門家だけでなく、幅広い層が AI に触れるようになるため、倫理的な側面や特性を理解して利用する必要があります。

特に AI エージェント開発の領域はまだ歴史が浅く、「フィールドでの知見がまだ少ない」という現実があります。そのため、お客様が自社で AI エージェント開発を成功裏に推進していくためには、経験豊富なパートナーからの効果的かつ実践的な内製化支援が不可欠であると私たちは考えています。

AI エージェント開発への支援

Google Cloud は、お客様の AI エージェント開発に対するニーズとプロジェクトの成熟度に合わせて、3 段階のプログラムをご用意しました。お客様の AI ジャーニーの段階に合わせた最適な支援が、ここにあります。

1.Mini TAP：まずは触れてみたい、AI エージェントの可能性を探りたいお客様へ

Mini TAP は、AI エージェントに関する Google Cloud が提供する技術の「基本的なキャッチアップ」を目的としたプログラムです。特に「まずは触ってみたい」「製品の使い方が知りたい」「生成 AI とは何か？」といった初期的なニーズに素早くお応えし、AI エージェントの世界への第一歩を支援します。

目的：Google Cloud が提供する AI エージェント開発の基本的な事項についてキャッチアップいただき、技術への理解を深めていただきます。
対象：Google Cloud 上での「AI エージェント開発・活用」に興味がある全てのお客様、特に AI エージェント開発の初期段階のお客様に最適です。
提供形式：数時間から半日程度の定型のオンサイトハンズオンやクラスルームトレーニングをご提供します。
成果物：ハンズオンを通じた実践的な体験や、生成 AI に関する基礎的な知識の習得。
具体的なメニュー例：LLM プロンプトエンジニアリングの基礎講座、Agent Engine を利用した AI エージェントの開発基礎などを体験いただけます。

2.TAP Lite：具体的なプロジェクトの方向性を定めたいお客様へ（AI エージェント開発のみ）

TAP Lite は、Mini TAP に加えて、プロジェクトの初期段階での「設計方針」や「ハイレベルなアーキテクチャの議論」を Google Cloud の専門家と共に行うプログラムです。お客様の具体的なアイデアを、実現可能なプロジェクトへと具体化する重要なステップです。

目的：お客様が実際にプロジェクトを開始するために必要なことを一緒に議論し、プロジェクトの方向性を確定させます。AI エージェントとして何を作るのかの概要を固める議論の場を提供します。
対象：AI エージェント開発・活用に関する具体的なプロジェクト素案があり、Google Cloud のサポートを得たい開発段階のお客様に推奨されます。
提供形式：半日〜1 日程度のオンサイトでのクラスルームトレーニングとディスカッションを通じて、プロジェクトの検討方針の策定やハイレベルなアーキテクチャ検討を支援します。
成果物：AI エージェントに関する議論とその結果としてのハイレベルなアーキテクチャ図。これはプロジェクトの成功に向けた確かな一歩となります。

3.TAP：AI エージェント開発プロジェクトを本格的に加速したいお客様へ

TAP は、AI エージェントを活用したプロジェクトの「立ち上げからプロトタイピング」までを Google Cloud の専門チームが伴走し、プロジェクトを強力に加速させるプログラムです。最終的には「プロダクション化」に向けた支援まで視野に入れ、お客様の AI エージェントを現実世界で稼働させることを目指します。

目的：Google Cloud を活用した AI エージェント開発・活用のプロジェクト計画を立て、プロジェクト組成からプロトタイピングまでを伴走し、プロジェクトの加速を支援します。プロトタイピングによって技術的な課題を洗い出し、案件を加速させることに注力します。
対象：AI エージェント開発・活用に関する具体的なプロジェクト計画があり、Google Cloud のサポートを得たいお客様。
提供形式：数日間にわたるオンサイトセッションや、アイディエーションワークショップ、プロトタイピングサポートを組み合わせたアジャイル型のワークショップです。ユーザージャーニーの明確化、アーキテクチャ設計支援、プロトタイピング支援、ビジネス効果報告、プロダクション計画支援といった段階的なサポートを提供し、お客様のプロジェクトを成功へと導きます。
成果物：お客様が検討している AI エージェントのプロトタイピング、アプリケーションのアーキテクチャ図、お客様自身で開発されたプロトタイプ。

なぜ、AI エージェント開発に TAP が重要なのか

TAP は、約 3 年間の実績を通じて、お客様がアプリケーション開発の内製化を進める上で直面する「方法論がない」「アジャイル開発の知識が不足している」「最適なサービスを選べない」といった課題を解決してきました。この内製化支援のノウハウは、「フィールドでの知見が少ない」AI エージェント開発の領域でこそ、大きな力を発揮します。

Google Cloud のエンジニアがお客様と「伴走」することで、お客様は短期間で実践的な知見を獲得し、AI エージェント開発プロジェクトを効率的に立ち上げることができます。これは、特に新しい AI エージェントの分野において、初期段階での「適切な方向性付け」と「迅速なプロトタイピング」がプロジェクト成功の鍵となるからです。TAP は、お客様の AI 活用のナレッジ蓄積を強力に支援し、お客様がこの変革の時代に早期の競争力を確立できるよう伴走します。

まとめと次のステップ

AI エージェント開発の内製化は、企業の競争力強化に不可欠な要素です。TAP は、お客様の AI エージェント開発におけるあらゆる段階を強力にサポートし、確実な成果へと導きます。

お客様の AI エージェント開発のフェーズやニーズに合わせて、Mini TAP、TAP Lite、TAP のいずれか、または組み合わせをご検討いただけます。

ご興味をお持ちいただけましたら、ぜひお気軽に担当営業にご相談ください。Google Cloud の専門家が、最適な AI エージェント開発の内製化支援プログラムをご提案させていただきます。

AI エージェント開発の内製化という新たな挑戦を、Google Cloud と共に踏み出し、ビジネスの新しい可能性を広げましょう。

推測にとどまらず、徹底的に調べましょう。Gemini Cloud Assist で根本原因分析が利用可能に

Thu, 04 Sep 2025 01:05:00 +0000

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

複雑な分散クラウド環境でのデバッグは、干し草の山から針を探すようなものです。膨大な量のデータ、絡み合った依存関係、一時的な問題により、従来のトラブルシューティング方法は時間がかかるうえ、多くの場合、事後対応になります。最新のソフトウェア開発で効果的なデバッグに多くのコンテキストが求められるのと同様に、クラウド運用でも同じことが言えます。

Google Cloud with Gemini ポートフォリオの主要プロダクトである Gemini Cloud Assist は、AI を活用したアシスタンス機能でアプリケーションの設計、デプロイ、最適化を支援し、アプリケーションの管理方法を簡素化します。これにより、効率、コスト、信頼性、セキュリティの目標を達成できます。

次に、インフラストラクチャとアプリケーションのトラブルシューティングを行う根本原因分析（RCA）AI エージェントである Gemini Cloud Assist Investigations が、現在プレビュー版として利用可能となっています。

問題が発生した場合は、ログエクスプローラ、Cloud Monitoring のアラート、あるいは直接 Gemini のチャットパネルからなど、さまざまな場所から調査を開始できます。Cloud Assist は、ログ、構成、指標などの複数のソースからのデータを分析し、環境の状態に関する分析情報を提供する、ランク付けおよびフィルタリング済みの「観察結果」を生成します。これらの観察結果を統合して考えられる根本原因を診断し、コンテキストを説明するとともに、問題解決に向けた次のステップや修正方法を推奨します。さらにサポートが必要な場合は、調査とそのすべてのコンテキストを Google Cloud サポートケースにシームレスに転送して、サポートエンジニアによる解決を迅速化できます。

Gemini Cloud Assist の調査の仕組み

Gemini Cloud Assist の調査は、以下の機能を組み合わせて問題の根本原因の特定を支援します。

プログラマティック、プロアクティブ、そしてインタラクティブなアクセス: API 呼び出し、チャットメニュー、UI を通じて調査をトリガーまたは利用でき、プロアクティブかつインタラクティブなトラブルシューティングを実現できます。
コンテキスト化: 調査では、環境内で最も関連性の高いリソース、データソース、API を特定し、焦点を絞ったトラブルシューティングを提供します。
包括的なシグナル分析: 調査では、Cloud Logs、Cloud Asset Inventory、App Hub、指標、エラー、ログテーマにわたって並列で詳細な分析を行い、異常、構成の変更、パフォーマンスのボトルネック、繰り返し発生する問題を明らかにします。
AI による分析情報と推奨事項: Google Cloud サポートのナレッジベースや社内ランブックなどの専門知識ソースを活用し、考えられる根本原因と実行可能な推奨事項が調査によって生成されます。
インタラクティブなコラボレーション - チーム全体で調査内容をチャットや共有で伝え、チームや Gemini Cloud Assist と連携してトラブルシューティングを行えます。
Google Cloud サポートへの引き継ぎ: 調査を直接サポートケースに変換でき、時間やコンテキストを失うことがありません。

プログラマティック、プロアクティブ、インタラクティブな調査

早期ユーザーは、Cloud Assist の調査によって難しい問題を迅速かつ効果的にトラブルシューティングして解決できることに満足しています。

「ZoomInfo では、稼働時間を維持することが非常に重要ですが、エンジニアが複雑な問題を迅速かつ効果的にトラブルシューティングできるようにすることも同様に重要です。開発プロセスの早い段階で Gemini Cloud Assist の調査を統合したことで、エンジニアリングチームのあらゆるレベルでトラブルシューティングを迅速化できました。あらゆる経験レベルのエンジニアが問題を迅速に診断して解決できるようになり、解決までの時間が数時間から数分に短縮されました。この効率性により、チームはイノベーションに注力する時間を増やし、事後対応型の問題解決に費やす時間を減らすことができます。Gemini Cloud Assist の調査は、トラブルシューティングの支援ツールであるだけでなく、生産性とイノベーションを牽引する重要な存在です。」- ZoomInfo、DevOps エンジニア Yasin Senturk 氏

「Gemini Cloud Assist 調査機能は 2 分で潜在的な根本原因に関する有効な提案をいくつか提示してくれ、最初の提案がまさにその原因だったことに本当に感銘を受けました。1 時間以内に問題全体に対処することができたのです。Gemini Cloud Assist のおかげで週末返上にならずに済みました。」 - Google Waze、SRE、Chuanzhen Wu 氏

Gemini Cloud Assist 調査機能をもう少し詳しく見ていきましょう。

プログラマティック、プロアクティブ、インタラクティブなアクセス調査は、ログエクスプローラのログメッセージ、特定のプロダクトページ（Google Kubernetes Engine や Cloud Run など）、または中央の [調査] ページなど、Google Cloud 内のさまざまな場所から直接開始できます。中央の [調査] ページでは、エラーメッセージ、影響を受けたリソース、観察時間などのコンテキストを提供できます。Gemini Cloud Assist の調査には API も用意されているため、Slack などの既存のワークフローや他のインシデント管理ツールに統合できます。問題の根本原因の特定にさらに支援が必要な場合は、調査の出力を用いて Google Cloud サポートケースをトリガーし、サポートエンジニアがその時点から対応できるようにします。

コンテキスト化調査は、自然言語の説明、エラーメッセージ、ログスニペット、または問題に関する情報の任意の組み合わせから開始できます。まず、問題に関連する初期コンテキストを収集し、関連するリソースや、根本原因の分析に役立つ可能性のある関連データソースをすべて示すトポロジを構築します。

調査では、公開・非公開のナレッジ、Google SRE および Google Cloud サポートの事例に基づくプレイブック、ユーザーのトポロジを活用し、類似の問題を基盤として、問題のトラブルシューティング計画を生成します。このコンテキストは、的を絞った包括的なシグナル分析を提供するうえで重要になります。

包括的なシグナル分析調査が実行されると、プロジェクトからの収集が開始された観察結果が表示されます。調査は表面的な観察にとどまりません。Google Cloud 環境全体にわたる重要なデータソースを自動的に分析します。

Google Cloud ログ: 膨大なログデータを精査して、異常や重大なイベントを特定する
Cloud Asset Inventory: リソース構成の変更とその潜在的な影響を把握する
指標（近日提供予定）: パフォーマンスデータを関連付けて、リソースの枯渇や予期しない動作を特定
エラー: エラーを集計して分類し、パターンと繰り返し発生する問題をハイライト表示
ログのテーマ: ログデータ内の一般的なパターンとテーマを特定し、問題のより上位レベルのビューを提供する

AI による分析情報と推奨事項Gemini Cloud Assist Investigations の根本原因に関する分析情報と推奨事項は、観察結果に基づいています。 Gemini の分析機能を活用することで、Cloud Assist はさまざまなデータソースからの観察結果を統合し、情報をランク付けしてフィルタリングすることで、最も関連性の高い詳細に焦点を当てます。重要なのは、調査で差別化された知識ソースと、広範な Google Cloud サポートのトラブルシューティングに関する知識や社内のランブックなどの一般公開されているドキュメントを利用して、非常に正確で関連性の高い分析情報と観察結果を生成することです。その後、以下が生成されます。

考えられる根本原因: 問題の根本原因について、状況説明を添えて明確な仮説を提示
実用的な推奨事項: トラブルシューティングの具体的な次のステップや、直接的な修正方法を提示し、インシデントの迅速な解決を支援

Google サポートチームへの引き継ぎ特に解決が難しい問題の場合、ボタンをクリックするだけで、調査パッケージがコンテキスト、観察結果、仮説をサポートケースにまとめ、問題の解決を迅速化します。そのため、問題について Google サポートチームに問い合わせる前に、調査を実施することをおすすめします。

Gemini Cloud Assist Investigations を今すぐ使ってみましょう

問題をより迅速に根本から解決する準備はできていますか？ログエクスプローラコンソールから任意のエラーログを調査して、今すぐお試しください。または、調査を直接作成して、発生している問題を記録してみましょう。

-GCP 基盤サービス、グループプロダクトマネージャー、Deepak Kallakuri
-Mark Church 、GCP 基盤サービス担当プロダクトマネージャー

Jina AI が Cloud Run GPU を使用して 1,000 億トークンのウェブグラウンディングシステムを構築した方法

Wed, 30 Jul 2025 01:30:00 +0000

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

編集者注: Jina AI Reader は、URL やローカルファイルから取得した未加工のウェブコンテンツを、クリーンで構造化された LLM フレンドリーな形式に変換する専用ツールです。この投稿では、Han Xiao 氏が、Cloud Run を活用して、経済的に持続可能な、安全で信頼性の高い、大規模にスケーリング可能なウェブスクレイピングシステムを構築する方法について詳しく説明します。この投稿では、現在 1 日あたり 1,000 億トークンを処理しているウェブグラウンディングシステム Jina Reader の背後にある、共同イノベーション、技術的課題、画期的な成果について説明します。

2024 年 4 月にリリースされた Jina Reader は、1 日あたり 1,000 万件以上のリクエストと 1,000 億トークンを処理する爆発的な成長を遂げ、信頼性が高く LLM に適したウェブコンテンツに対する大きな需要があることを裏付けました。Jina Reader は単なるスクレイパーではありません。AI システムがウェブコンテンツを消費する方法について、未加工のノイズの多いウェブページをクリーンで構造化された Markdown に変換するという異なるアプローチを採用しています。

ウェブデータを処理する AI システムの主な課題は、「ウェブグラウンディング問題」です。現代のウェブサイトは、コンテンツ、広告、トラッキングスクリプト、動的な JavaScript が混在しており、ノイズ対信号比が圧倒的に高くなっています。従来のスクレイパーでは、この複雑さに対応できず、動的なシングルページアプリケーションで失敗したり、LLM で使用できない根拠のないデータを生成したりすることがよくあります。Jina Reader の画期的な ReaderLM-v2 は、15 億のパラメータを持つ専用の言語モデルです。数百万のドキュメントでトレーニングされ、単純なルールを超えてウェブ構造を理解し、コンテンツをインテリジェントに抽出します。

図 1: Jina Reader: 高度なブラウザ自動化システム

Cloud Run: Jina Reader のスケーリングを支えるエンジン

Jina Reader は、ウェブスクレイピングワークロードに固有のバースト性と予測不可能性に直面していました。従来の仮想マシン設定では、高額なオーバープロビジョニングか、負荷がかかった状態での重大な障害のどちらかしかありませんでした。Google Cloud Run は不可欠なソリューションとなり、Jina Reader は安全で信頼性が高く、大規模にスケーラブルで経済的に実行可能なウェブスクレイピングシステムを構築できるようになりました。

ウェブグラウンディングアプリ（ウェブコンテンツをスクレイピングしてクリーンアップするブラウザ自動化システム）は、Cloud Run（CPU）でホストされています。完全な Chrome ブラウザインスタンスを実行します。
ReaderLM-v2 は、サーバーレス GPU を使用して Cloud Run で実行される、HTML から Markdown への変換専用の 15 億パラメータの言語モデルです。

Cloud Run は、いくつかの重大な問題を直接解決しました。

最適化されたパフォーマンス: Jina Reader と Google Cloud エンジニアリングの緊密な連携は不可欠でした。ブラウザの自動化のためのコンテナライフサイクル管理を共同で最適化し、プリウォーミング、イメージの最適化、インテリジェントなリソース割り当てにより、起動時間を 10 秒以上から 2 秒未満に短縮しました。ReaderLM-v2 では、Google のチームがカスタムコンテナ構成の作成を支援し、15 億パラメータのモデルを Cloud Run GPU で効率的に実行できるようにしました。Cloud Run GPU のオンデマンドスケーリングと高速起動機能は、モデルのパフォーマンスを最適化するうえで非常に重要であり、1 日あたり 1,000 億トークンを処理する能力に直接影響しました。

図 2: Cloud Run GPU を使用したオンデマンド AI 推論（ReaderLM-v2 モデルをホスト）

真のゼロへのスケーリングのサーバーレス: Cloud Run の完全な Chrome ブラウザインスタンスを実行する機能により、費用対効果の高い運用が可能になりました。リクエストごとに、独自のヘッドレス Chrome を備えた分離されたコンテナが生成されます。重要なのは、リクエストが完了するとこれらのコンテナが消滅することです。この一時的な性質は、信頼できないウェブコンテンツを処理し、セキュリティリスクとメモリリークを軽減するために不可欠です。
グローバルなマルチリージョンデプロイ: Cloud Run はグローバルに展開されているため、ユーザーと対象ウェブサイトの両方の近くでリクエストを処理できます。これにより、地理的制限のあるコンテンツに対しても、レイテンシを大幅に最小限に抑え、成功率を高めることができます。
大規模かつ自動のスケーリング: トラフィックのピーク時には、プラットフォームが数個から 1,000 個以上のコンテナインスタンスにシームレスにスケールし、手動での介入なしにウェブスクレイピングの予測不可能な性質に対応します。
経済的実現可能性: Cloud Run の従量課金制モデルにより、Jina Reader はエンドユーザーに十分な無料枠を提供しながら、月間使用量が大幅に増えても収益性を維持できます。この料金の柔軟性が、幅広い導入の基本となりました。
レジリエンスと運用上の卓越性: 最近発生した継続的な DDoS 攻撃の際、Cloud Run のサーバーレスアーキテクチャは非常に貴重であることが証明されました。インテリジェントなレート制限によって悪意のあるトラフィックがフィルタリングされる一方で、大規模な負荷（1 分あたり 100,000 件を超えるリクエスト）を吸収するためにスケールアップされました。重要なのは、ゼロへのスケーリング機能により、攻撃が収まるとすぐに費用が通常に戻ったことです。このシステムは 99.9% を超える稼働率を維持しています。

まとめ

Google Cloud Run で Jina Reader を構築したことで、AI 機能とクラウドネイティブアーキテクチャが補完関係にあることが証明されました。Cloud Run の独自の機能（サーバーレス GPU、コンテナの分離、グローバルなデプロイ、ゼロへのスケーリングの経済性）により、このアーキテクチャが実現しました。Google との緊密なパートナーシップは、AI ファーストのシステムと最新のクラウドインフラストラクチャの緊密な統合により、これまで不可能と考えられていた機能を実現できることを示しています。これにより、毎日 1,000 億トークンを処理できるようになりました。

Cloud Run GPU について詳しくは、プロダクトページをご覧ください。Cloud Run で大規模言語モデルをホストする方法については、こちらの動画をご覧ください。

ー Han Xiao 氏 、Jina AI CEO

ー Google Cloud、エンジニアリング担当ディレクター、Yunong Xiao

aside_block: <ListValue: [StructValue([('title', 'Google Cloud を無料で試す'), ('body', <wagtail.rich_text.RichText object at 0x7f9bd47594c0>), ('btn_text', '無料で開始'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

ルノーグループによる、Google のソフトウェア定義自動車業界ソリューションの活用法

Thu, 24 Jul 2025 01:08:00 +0000

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

ルノーグループはヨーロッパの大手自動車メーカーとしてよく知られており、ソフトウェア会社だと認識している方は少ないかもしれませんが、そう考えるのが妥当である理由も多くあります。ルノーグループの Ampere Software Technology は、インテリジェントな電気自動車向けの高度ソフトウェアソリューションを開発および統合し、顧客体験の向上と新しいサービスを実現するソフトウェア定義自動車（SDV）の開発に取り組んでいます。

Ampere は、大規模な Android Automotive OS（AAOS）コードベースを活用して、ルノーグループのソフトウェア定義自動車を開発しています。しかし、他のソフトウェア企業と同様に、費用の抑制、コードベースの同期、適切なテスト体制の維持、新しい人材のオンボーディングに苦労していました。

Google Cloud とルノーグループの既存のパートナーシップを基盤として、Ampere はソフトウェア定義自動車の開発に Google Cloud ソリューションを導入しました。Google Cloud Workstations と Gemini Code Assist を活用したこのソリューションは、開発過程でよく発生する障害の多くを排除することで、プロセスを効果的に合理化し、安全性と生産性を高めました。

Cloud Workstations は、セキュリティを重視する企業を対象にフルマネージド開発環境を提供します。同時に、Gemini 2.5 を活用した Gemini Code Assist は、ソフトウェア開発ライフサイクル全般にわたって安全な生成 AI コーディング支援とエージェントを提供します。また、AAOS 向けに特別に開発された Google のバーチャルツイン技術を活用することで、Ampere はフルデジタル版の自動車を構築しました。

このソリューションのコンポーネントを詳しく見ていきましょう。

Google Cloud Workstations

Google Cloud Workstations は、Android オープンソースプロジェクト（AOSP）に携わる開発者の全般的な生産性向上に大きく役立ちます。Ampere のコンテキストでは、お客様の AAOS リポジトリと事前に同期された永続ディスクを備えたオンデマンドの開発環境が提供されます。これにより、長い同期時間やビルド時間が不要になり、開発者はどこからでも作業にアクセスできます。Ampere のプラットフォーム管理者はこれらのワークステーションをプロビジョニングし、開発者が生産性を発揮できるようになるまでの時間を大幅に短縮しています。開発者は、十分な vCPU、RAM、高速 SSD ストレージを備えた高性能な仮想マシンに即座にアクセスできます。これは、要求の厳しいエミュレータを使用する開発者にとって重要なことです。リソースを柔軟に利用できるようになり、ボトルネックの防止や開発の加速が進みます。次に、安全な認証済みクラウドアクセスと Google Cloud のセキュリティツールにより、IP（知的財産）の漏洩と不正アクセスを大幅に削減できます。最後に、一貫した開発環境を確保することで、「私のマシンでは動いたのに」という問題を回避し、デバッグ時間を短縮できます。柔軟なアクセスとディスク構成により、どこからでもワークステーションにアクセスでき、永続ディスクを介したコードベース、構成、ビルドアーティファクトのセッション間での保持が可能になりリポジトリの同期を繰り返す必要がなくなるため、AAOS 開発者の生産性が向上します。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud を無料で試す'), ('body', <wagtail.rich_text.RichText object at 0x7f9bd43749a0>), ('btn_text', '無料で開始'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

AI を活用した Android 開発のための Gemini Code Assist

そこで Ampere は、Gemini Code Assist と統合された Android Studio と Code OSS の IDE を開発者に提供して複雑化するコード管理に対処しました。これは、習得に要する時間を短縮しただけでなく、エラーの防止にも役立ちました。Gemini Code Assist は、検索拡張生成（RAG）を使用して Ampere の非公開コードベースとドキュメントにアクセスし、Android 開発の標準と規則に合わせて調整された、関連性が高く正確なコード提案を提供します。関数についての説明、モジュールの要約、次のステップの提案で、膨大なコードベースを迅速に把握できるようになり、新しい開発者や SDV ソフトウェアのさまざまな部分に取り組む開発者にメリットをもたらしました。また、ボイラープレートコードの自動化、API の提案、潜在的な問題の検出により、Android 開発の生産性向上にも役立ちました。開発者は反復作業ではなく、SDV のコアロジックに集中できるようになりました。

バーチャルツイン

Google Cloud により、Ampere の AAOS 開発者とテスターは車の「バーチャルツイン」を使用できるようになり、実車テストや管理が不十分な仮想テストに必要なリソースの確保や工程の複雑化という問題が解決されました。開発者は、強力な Compute Engine インスタンスと、Cuttlefish などの特殊な Android エミュレータを使用して、正確な仮想車両組み込みシステムを構築できます。これにより、仮想ハードウェアを使った厳格なソフトウェアテストが可能になり、物理プロトタイプを作る前に堅牢なパフォーマンスを確保できます。AAOS 開発者は、スケーラブルな仮想デバイスを使用して、並列テスト、包括的な回帰スイート、シミュレーションを行うこともできます。これにより、CI/CD パイプラインの「テスト」フェーズが加速し、SDV ライフサイクルが改善されます。バーチャルツインは、GKE と GitLab などを利用して Cloud Workstations 開発環境とお客様の CI/CD パイプラインに統合されているため、開発者は、ワークステーションで AAOS に追加した変更をビルドしてバーチャルツインのフリートでトリガーする自動テストにより、コードに関するフィードバックを即座に取得できます。

SDV 開発のモダナイゼーションによる具体的な効果

Google Cloud は、Cloud Workstations の堅牢なマネージドインフラストラクチャ、Gemini Code Assist のインテリジェントな支援、バーチャルツインを組み合わせることで、Renault による自動車ソフトウェア開発のモダナイゼーション、イノベーションの加速、新機能のこれまでになくスピーディーな市場投入に役立っています。

「...ヨーロッパでソフトウェア定義自動車向けソフトウェアプラットフォームに投資して構築するには、ツールが必要です。Google はその点で優れています。その中心にあるのは AI です。コード生成について言えば、コンパイルを待ってから開発者が利用できるようになるのではなく、すぐに実行する必要があるものをインスタンス化します。エンジニアの効率を高めて、より少ない時間でより多くのことを行えるようにするためです。私たちは時間に追われています。」 - Ampere 最高ソフトウェア責任者（ルノーグループ）Henry Bzeih 氏

Google Cloud と Gemini Code Assist は、自動車 OEM にとって単なるツール導入に留まりません。競争力、収益性、イノベーションのスピードを高め、ビジネス成果に確かなインパクトをもたらす変革を実現します。

従来、新しい開発者のオンボーディングには数日と費用がかかります。AAOS での開発には、セットアップに時間がかかるだけでなく、依存関係の管理、ビルドシステムのトラブルシューティングも必要となるケースが多くあります。リポジトリの同期やツールチェーンの構成など、これまで数日かかっていた環境のセットアップを数分に短縮し、AI アシスタンスを活用すれば開発スピードも大幅に加速します。

OEM は、ローカルデバイスから知的財産が漏洩することを懸念しています。Cloud Workstations は、お客様の Virtual Private Cloud 内で動作することで、この懸念に対処します。このアプローチでは、ソースコードがローカル環境で同期されるため外部エンドポイントに公開されることがなく、セキュリティリスクを抑えることができます。

クラウドインフラストラクチャの費用は発生しますが、全体として大幅なコスト削減が可能です。ハイエンドのローカルマシンを排除し、環境管理にかかる開発者の時間を最小限に抑えることでスケジュールを短縮し、総開発コストを削減します。また、実際に利用した分にのみ料金が発生するクラウドリソースを迅速に調整できることで、アイドル状態のハードウェアにかかるコストを避け、エンジニアリング投資のリターンも向上します。

最後に、自動車のバーチャルツインを活用すれば、品質保証や検証作業の効率がよくなります。開発者は、限られたプロトタイプや信頼性に欠けるローカルエミュレータに頼る代わりに、精緻な仮想自動車モデルを活用することで、イテレーションの高速化、スケーラブルなテスト、早期のバグ検出、高度なシナリオシミュレーションを実現できます。

Cloud Workstations と Gemini Code Assist の活用により、自動車メーカーは新たなテクノロジーを導入するだけでなく、開発能力そのものの再構築を進めています。詳細については、SDV 業界ソリューションの成功に関する、ルノーグループの Ampere 最高ソフトウェア責任者（ルノーグループ）Henry Bzeih 氏との対談をご覧ください。

自動車業界のお客様は、Google の GitHub リポジトリをご覧になることで、Gemini Code Assist を活用したカスタム AAOS 開発環境の構築をすぐに始めていただけます。もちろん、Google のパートナーエンジニアリング担当者、カスタマーエンジニアリング担当者がサポートいたします。

-Cloud Shell および Cloud Workstations プロダクトリード Femi Akinde

アプリケーション開発

Google が管理する MCP サーバーを使用してプロダクション レディな AI エージェントを構築する方法

Google が管理する MCP サーバーを使用する理由

ADK と Google MCP サーバーを使用する AI エージェントの例

1. ADK エージェントから Google MCP サーバーを呼び出す:

2. エンタープライズ グレードのセキュリティとコンテンツのガードレール

Model Armor によるコンテンツ セキュリティ

ご利用にあたって

一元化されたポリシーと分散ロジック: Eventarc Advanced の概要

インテグレーション アーキテクチャの進化

新しいパターン: ポリシーは一元化、ロジックは分散

仕組み: 小売業のイベント メッシュの例

バス: ガバナンス レイヤ

パイプライン: ロジックレイヤと、自律的なチームのイノベーション

アジャイルなインテグレーションに向けた未来

使ってみる

Google Cloud データベースで次世代のエージェントを強化する

エージェントに運用データを提供

アプリケーションとインフラストラクチャの管理

セキュリティとガバナンス

デモ: ローカルコードからマネージド データへ

サードパーティ エージェントのサポート

次のステップ

プラットフォーム使用の落とし穴（パート 1）: アクティビティの多さが必ずしも価値の高さを示すとは限らない理由

最初の測定: プラットフォームの価値に焦点を当てる

チームのパフォーマンスを把握できるようにする

測定対象を選択する

プラットフォーム使用の落とし穴（パート 2）: 意味のあるモニタリング指標を選択する

エンジニアの主観的なフィードバックを収集する

サービスの健全性 - 機能の導入とそれ以降

プラットフォームは期待に応えている？重要ポイント

Google の ADK を使ったエージェント アプリケーションを Datadog LLM Observability でモニタリングする

エージェントの判断と予期しない挙動をトレース

トークン使用量とレイテンシをモニタリング

エージェントの応答品質とセキュリティを評価

テストを通じて、迅速かつ確信を持って改善を重ねる

Datadog LLM Observability を使ってみる

Model Context Protocol の gRPC トランスポート

RPC トランスポートの選択

gRPC のメリット

使ってみる

企業データを Google の新しい Antigravity IDE に接続する

Antigravity で MCP を使用する理由

MCP サーバーを使ってみる

エージェントの活用事例を見る

Antigravity でデータを活用して構築する

NEC、AI で TNFD レポート作成業務を自動化、8 万時間相当の作業を 200 時間に大幅短縮

人手では不可能 ー 2,000 拠点、8 万時間の壁

Google Cloud の AI サービスと TAP によって実現手段を見出す

AI が「調査」、人が「対話」へ ー 新しい協働関係

「クライアントゼロ」から、社会全体のサステナビリティ向上へ

インタラクションから分析情報へ: Google ADK 向け BigQuery Agent Analytics の発表

BigQuery Agent Analytics について

重要な理由: データドリブンなエージェント開発

仕組み

使ってみる

NTTドコモ 社内データ活用基盤の裏側 - Cloud Run が支える開発の民主化とデータ活用の未来

データ活用を 9 割高速化せよ - 全社データ活用基盤「Pochi」開発の背景

“誰でも開発者”を実現するモダンな開発環境の裏側

開発の民主化が生んだ成果と、AI エージェントが実現する次のステージ

Agent Sandbox のご紹介: Kubernetes と GKE 上のエージェント AI 向けの強力なガードレール

堅牢な分離と高いスケーラビリティ

GKE でのパフォーマンスの向上

AI エンジニアのためのサンドボックス

今すぐ使ってみる

Google Cloud でのカオス エンジニアリング: 原則、実践、開始方法

カオス エンジニアリングについて

カオス エンジニアリングの原則と実践

カオス エンジニアリングの要素

カオス エンジニアリングを開始する

製薬業界の開発を変革する中外製薬の挑戦：Gemini Code Assist 活用で開発速度は最大 5 倍に

属人化と心理的ハードル、AI 導入前の開発課題

プロトタイピングを加速し、開発文化を変革する Gemini Code Assist

臨床開発、アジャイル開発、データサイエンス ―― 多様な現場での活用事例

開発速度は最大 5 倍に ―― Gemini Code Assist がもたらした定量的・定性的効果

AI との協業時代における、人と組織の在り方

未来への展望：AI と共に創る新しい開発スタイル

新しい Gemini CLI 拡張機能でアプリのデプロイとセキュリティ分析を自動化

Eventarc Advanced で複雑なイベント処理を大規模に簡素化

複雑性に対処するための Eventarc の進化

Google が管理する MCP サーバーを使用してプロダクションレディな AI エージェントを構築する方法

2. エンタープライズグレードのセキュリティとコンテンツのガードレール

Model Armor によるコンテンツセキュリティ

インテグレーションアーキテクチャの進化

仕組み: 小売業のイベントメッシュの例

バス: ガバナンスレイヤ

デモ: ローカルコードからマネージドデータへ

サードパーティエージェントのサポート

Google の ADK を使ったエージェントアプリケーションを Datadog LLM Observability でモニタリングする

人手では不可能ー 2,000 拠点、8 万時間の壁

AI が「調査」、人が「対話」へー新しい協働関係

NTTドコモ社内データ活用基盤の裏側 - Cloud Run が支える開発の民主化とデータ活用の未来

Google Cloud でのカオスエンジニアリング: 原則、実践、開始方法

カオスエンジニアリングについて

カオスエンジニアリングの原則と実践

カオスエンジニアリングの要素

カオスエンジニアリングを開始する

Jina AI が Cloud Run GPU を使用して 1,000 億トークンのウェブグラウンディングシステムを構築した方法

バーチャルツイン