アプリケーション開発

Cloud Run、Firebase、Cloud SQL を使用したフルスタックのバイブコーディングが AI Studio で可能に（クレジットカードは不要）

Wed, 03 Jun 2026 01:00:00 +0000

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

Google I/O 2026 では、Google AI Studio と Google Cloud のインテグレーションに関する最新情報を発表しました。

新規ユーザーは、請求先アカウントなしで、フルスタックアプリケーションを 2 つまで Google Cloud スターターティアにデプロイ可能
データベースの選択肢の拡大: 非リレーショナルデータ用の Firestore と、新しいリレーショナルデータベースオプションとしての Cloud SQL
Firebase Auth を単一のユーザーログインフローとして使用することで、Google スプレッドシート、Google カレンダー、Gmail などの Google Workspace ツールとの緊密なインテグレーションを実現

これらは、3 月に発表したインテグレーションのアップデートであり、これには、Cloud Run、Firestore、Firebase Auth を活用することで、バイブコーディングされたフルスタックアプリケーションを AI Studio からデプロイするためのサポートが含まれていました。

このインテグレーションの拡大により、AI Studio を使用してより幅広いアプリケーションを構築できるようになりました。データベースには、Cloud SQL を使用したリレーショナルデータベースか、Firestore を使用した非リレーショナルデータベースのいずれかを使用できますが、ユーザーがデータベースを指定する必要はありません。AI エージェントが、アプリや機能に適したデータベースを自動的に判断します。

ぜひ実際にお試しください。AI Studio では、スターターティアで Cloud Run、Cloud SQL for PostgreSQL（来月提供開始）、Firestore、Firebase Auth を無料でご利用いただけます。

AI Studio から Cloud Run へ、フルスタックアプリケーションをワンクリックで公開

手軽に導入: Google Cloud スターターティア

AI Studio でアプリケーションを構築して、プロトタイプを Cloud Run に直接デプロイしたり、Firebase Auth で認証を行ったり、データを Firestore や Cloud SQL データベースに保存したりできます。クレジットカードや Google Cloud アカウントは必要ありません、面倒な手続きも一切不要です。プロンプトを入力するだけで、すぐに開始できます。

AI Studio では、アカウントがない場合は、Google Cloud スターターティアを使用してリソースが作成されます。フルスタックアプリケーションは 2 つまでデプロイできます。スターターティアの制限を超えた場合は、請求先アカウントが登録されている標準の Google Cloud プロジェクトにアップグレードできます。すべてのリソースが課金対象の Google Cloud プロジェクトに移行されるため、アプリケーションを成長に合わせてスケールできます。

Cloud SQL でフルスタックのバイブコーディングを強化

インテリジェントかつ自動化されたデータ基盤を導入することで、デベロッパーは、インフラストラクチャではなくアプリケーションに集中できるようになります。

AI Studio と Cloud SQL のインテグレーションには、以下が含まれます。

即座に利用開始: インスタントプロビジョニングにより、プロンプト入力から完全にデプロイされた PostgreSQL データベースの利用までを迅速に実現できます。
無料で開始: クレジットカードや Google Cloud アカウントがなくても、Google Cloud スターターティアで Cloud SQL を無料でお試しいただけます。
柔軟な費用管理: AI エージェントは新しい Cloud SQL for PostgreSQL デベロッパーエディションを使用します。これにより、バックエンドが自動的にゼロにスケールできるようになります。課金されるのはアプリを使用している間のみです。
エージェント主導のエクスペリエンス: 新しいプロンプトを入力するだけでアプリケーションを更新できます。AI エージェントが自動的にスキーマを作成し、データベース内で SQL ステートメントを実行します。
グローバルなスケーラビリティ: インターフェースはシンプルですが、アプリケーションは Google Cloud の堅牢で信頼性が高く、安全に設計されたインフラストラクチャ上で実行されます。数百万人ものユーザーをサポートするようにスケールすることも可能です。

Cloud SQL for PostgreSQL デベロッパーエディションを活用したアプリの作成

Firestore と Firebase Auth を使用したフルスタックのバイブコーディング

AI Studio でアプリを構築する際、エージェントは、プロンプトに基づいてデータストレージや認証が必要かどうかをプロアクティブに検出し、データベースやユーザー認証の設定を提案します。ドキュメントデータベースが役立つアプリの場合、エージェントは、Firestore や Firebase Authentication を有効にするカードを表示し、ユーザーの承認を求めます。

アプリケーションで Firebase を有効にするかどうかの確認を求めるエージェント

[Firebase を有効にする] をクリックすると、エージェントは自動的に以下の処理を行います。

Firestore をプロビジョニングし、認証を有効にして、アプリをデータベースに接続する
ウェブアプリのログインページを作成し、Google ログインによる認証を構成する
アプリ内で Firestore コードを生成し、セッションやデバイス間でデータを同期できるようにする
アプリのロジックに基づいて Firestore セキュリティルールの下書きを作成してデプロイする（ただし、アプリの共有やデプロイを行う前に、ユーザーがこれらのルールを必ず再確認する必要があります）

Firebase Auth を使用すると、以下のことが可能になります。

自然言語を使用してアプリを Google Workspace に接続する: Workspace の機能（Google スプレッドシート、Google カレンダー、Gmail など）をリクエストすると、エージェントは Firebase Authentication を利用した「Google でログイン」フローを実装し、Google AI Studio がデータに安全にアクセスできるようにします

Firebase Authentication を利用してアプリを Google スプレッドシートに接続

詳しくは、Google I/O で発表された Firebase の最新情報に関するブログ記事をご覧ください。

AI Studio を使ってみる

アイデアをアプリで実現することは、もはや絵空事ではありません。以下の手順に沿って進めることで、フルスタックアプリケーションを無料で構築できます。

AI Studio にログインする: プラットフォームにアクセスしてプロジェクトを開始します。
プロンプトを使用して構築する: 自然言語のプロンプトを使用してアプリケーションの構築を開始します。たとえば、「経費管理アプリを構築して」などと指示します。
データベースを有効にする:「データベースを追加して」という指示をすると、AI Studio が「Enable」ウィジェットを通じてデータベースをインテリジェントにプロビジョニングします。特定のリレーショナルデータベースを明示的に指定することもできます。
システムを設定する: [Enable] を選択し、利用規約に同意します。
共有を開始: [Publish] ボタンを使用してアプリケーションをデプロイし、共有します。

AI Studio を今すぐ利用して、アイデアを数秒でライブアプリケーションに変換しましょう。

- プロダクトマネージャー、Justin Mahood

- プロダクトマネージャー、Gopal Ashok

Google Cloud でリソース単位からビジネス単位のメンテナンスへの移行を実現

Tue, 02 Jun 2026 02:00:00 +0000

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

定期メンテナンスの管理は、信頼できるビジネスを運営するうえで不可欠です。しかし、クラウドフットプリントが数百、数千のプロジェクトに拡大すると、個々のアップデートをすべて把握するのは大変な作業になります。多くのプラットフォームチームは、作業の分断という現実に直面しています。どのメンテナンスイベントがどのビジネスサービスに影響するかを把握するために、ダッシュボードを切り替える必要があります。

Google Cloud では、ビジネス上の問題を解決しようとするときに、インフラストラクチャの管理について案じるべきではないと考えています。そこで、アプリ単位でメンテナンスイベントを可視化する Unified Maintenance の新機能をリリースすることになりました。

ビジネスに焦点を移す

これまで、メンテナンスの可視化では主にリソースに重点が置かれていました。特定の Compute Engine VM や Cloud SQL インスタンスの更新期限は確認できましたが、それらのリソースが稼働させているアプリケーションとのマッピングは手動で行う必要がありました。

Google Cloud は、アプリ単位での可視化を提供することで、インフラストラクチャレベルのリソースからビジネス指向のビューに焦点を移します。App Hub と直接統合された Unified Maintenance では、アプリケーションのコンテキストでメンテナンスイベントを確認できるようになりました。

仕組み

この新機能では、「アプリケーション」を主要な管理単位として活用します。GKE クラスタ、GCE VM、AlloyDB インスタンスなどのリソースを App Hub に登録すると、Unified Maintenance によってメンテナンススケジュールが自動的に集計され、アプリケーションを認識する単一のダッシュボードに表示されます。

この新機能によってプラットフォームエンジニアは以下のことが可能になります。

トイルの削減: メンテナンスアラートをアプリケーションオーナーに手動でマッピングする必要がなくなります。
トリアージの迅速化: アプリのパフォーマンス低下が、計画されたインフラストラクチャのアップデートと一致するかどうかを即座に確認できます。
予測可能な運用: メンテナンスが環境全体に及ぼす影響をビジネス指向で把握できます。

使ってみる

Google Cloud でアプリケーションをすでに定義している場合は、Google Cloud コンソールで新しいアプリ単位の可視化機能を直接確認できます。アプリケーションの境界の設定とリソースのマッピングについて詳しくは、スタートガイドをご覧ください。

また、サポート対象のサービスのページで新しいサービスのオンボーディングをご確認ください。

- Google Cloud、プロダクトマネージャー、Erol-Valeriu Chioasca

Google の分散エージェントランタイム、Agent Executor のご紹介

Thu, 28 May 2026 03:00:00 +0000

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

モデルとハーネスの進化に伴い、エージェントは数時間、場合によっては数日間にわたって実行される、より複雑なタスクを担うようになっています。しかし、エージェントにより多くの処理を任せるにつれ、新たな運用上の課題も明らかになってきました。長時間実行されるエージェントワークフローは壊れやすく、本番環境で信頼性と効率を保ちながら管理することが非常に困難です。

Google はこのたび、エージェントの実行、再開、分散デプロイのためのオープンソースランタイム標準である Agent Executor を発表します。Google が社内でこうした課題を解決する過程で得た知見をもとに、Agent Executor には次のネイティブ機能が組み込まれています。

耐久性のある実行: 長時間実行される処理では、障害が発生した場合や、人間参加型（HITL）の確認などによってエージェントの処理が中断された場合でも、再開できる仕組みが必要です。Agent Executor は、イベントログとスナップショットを通じて、エージェント、エージェントハーネス、スキル、ツール、サンドボックスなど、あらゆるアクターにこのバックエンドのレジリエンスを自動的に提供します。
安全な分離: Agent Executor は、安全性を重視して設計されたサンドボックス内にコンポーネントを分離し、有害な副作用を防ぐとともに、悪意のあるアクティビティがサービス全体を侵害しないようにします。サンドボックスは、エージェントがコードを生成する場合や、複数のテナントやユーザーデータを同時に扱う場合に特に有用です。
セッションの整合性: 分散エージェントワークフローでは、複数のコンポーネントが共有セッション状態を同時に更新しようとすることがあります。Agent Executor に組み込まれた単一ライターアーキテクチャは、この状態の整合性を維持し、破損のリスクを軽減します。
接続の復旧: 長時間実行されるエージェント型処理では、ネットワーク障害など、さまざまな理由でクライアントが切断されることがあります。Agent Executor を使用すると、クライアントはエージェントに再接続し、クライアントが最後に確認したシーケンス以降のレスポンスを補完できるため、ユーザーエクスペリエンスが向上します。
トラジェクトリの分岐: チェックポイントを使用すると、エージェントのトラジェクトリ、つまり意思決定やワークフローのパスを任意の時点で分岐できます。これにより、エージェントはコンテキストやその他の状態を失うことなく、複数のパスをテストまたは評価できます。

このブログ記事では、Agent Executor の詳細と、使い始める方法をご紹介します。

Google のエージェントランタイムと連携する

企業がエージェントを導入するには、さまざまなデプロイモデルを横断してオーケストレーションできることが必要です。独自のワークフロー、パフォーマンス、コンプライアンスのためにオンプレミスインフラストラクチャを必要とするチームもあれば、価値実現までの時間を短縮するために、事前構築済みのエージェントやカスタムのマネージドエージェントを選ぶチームもあります。Google I/O では、エージェント型エンタープライズにおけるチームの構築とスケーリングを加速するために設計された新しいソリューション群として、Antigravity 2.0 や Managed Agents API などを発表しました。

Agent Executor は、こうしたデプロイモデルの橋渡しをします。次のいずれか、またはすべてを自由に組み合わせて使用できます。

Gemini の最先端エージェントハーネスである Google Antigravity
最新の Deep Research エージェントなど、Google が構築したフロンティアエージェント
お客様が構築し、Google が管理するカスタムエージェント（新しい Gemini API の Managed Agents など）
LangChain / LangGraph、Agent Development Kit（ADK）などで構築されたカスタムの専用エージェント、および Agent2Agent Protocol（A2A）を使用する任意のエージェント

エージェント、モデル、コンピューティングを自社で管理する

Agent Executor を使用すると、企業は最大限の柔軟性を確保しながら、ワークロードの主権を維持し、独自のワークフローを自社管理のコンピューティング環境やカスタムサンドボックス内に保持できます。社内の開発チームは、エージェントのデプロイと管理の方法をより柔軟に選択でき、次のようなメリットを得られます。

ベンダーロックインの防止: 特定のプロバイダのモデルやコンピューティング環境に縛られることなく、自社のインフラストラクチャにエージェントをデプロイできます。これにより、データ所在地やコスト、予算管理を完全に制御できます。
独自のハーネスとエージェントの使用: Agent Executor はハーネスに依存しない設計のため、独自のハーネスを使用することも、他のベンダーが提供するハーネスを使用することもできます。また、業界標準のフレームワークやプロトコルで開発されたエージェントもサポートしており、互換性のあるエージェントからなる幅広いエコシステムを利用できます。
実行の完全な制御: Agent Executor を使用すると、デベロッパーは MCP、スキル、その他のエージェントを含むエージェント型スタック全体を、自社のデータプレーン上で直接実行できます。カスタムの分離境界やワークロードポリシーの適用を備えた、任意のコンピューティング環境を選択できます。

エージェントファーストのコンピューティングレイヤを使用して Kubernetes 上でエージェントをスケール

エージェントワークロードが数億規模へと拡大し、実行時間も長くなるにつれて、お客様は従来のコンピューティング抽象化の限界に直面しています。従来のソフトウェアとは異なり、エージェントは外部入力を待機する非線形のプログラムだからです。この問題を解決するため、Google は Google Kubernetes Engine チームと連携し、本日発表した新しいオープンソースプロジェクト Agent Substrate を開発しました。

Agent Substrate は Kubernetes に新しい抽象化レイヤを導入し、準備済みのコンピューティングキャパシティにエージェントをリアルタイムで割り当てたり、そこから退避させたりします。これにより、レイテンシを低減しながら、スケールと効率を高めることができます。標準の Kubernetes は、長時間実行される数千のサービスを処理するよう最適化されています。一方、Agent Substrate は、標準的なコントロールプレーンでは処理しきれない、数百万件規模の 1 秒未満のツール呼び出しが頻繁に発生する状況に対応できるよう設計されています。Agent Substrate は、既存のサンドボックスインフラストラクチャが備えるセキュアなランタイムとスナップショットの中核機能を活用しながら、Kubernetes の一部の制限を回避するために設計された最小限のコントロールプレーンと組み合わせます。Kubernetes のそれ以外の部分を作り直す必要はありません。これらのレイヤを連携させることで、次のことが可能になります。

コンピューティング効率の最大化: Agent Substrate は、数億の登録済みエージェントを処理できるように設計された新しいコントロールプレーンを導入します。Agent Executor と組み合わせることで、Agent Substrate は現在最大規模のエージェントデプロイメントを支える基盤を提供できます。
Kubernetes エコシステム内での運用: Agent Substrate は Kubernetes 上に構築されており、宣言型構成によるコンピューティングのスケジューリングと水平スケーリングを可能にします。

以下のデモでは、サンプルワークロードを使って、Agent Executor と Agent Substrate を併用する方法を紹介します。

使ってみる

モデル、エージェント、ハーネス、そしてそれらを取り巻くインフラストラクチャは、かつてない速さで進化しています。Google は Agent Executor をオープンに開発することで、実際のデベロッパーに使用してもらいながら設計を検証し、皆様からのフィードバックに基づいて改善できるようにしています。

Agent Executor は現在、プレビュー版としてご利用いただけます。ぜひコードをご確認いただき、ご自身のワークロードでテストしながら、エージェントランタイムの未来を形作る取り組みにご参加ください。今すぐ GitHub リポジトリにアクセスして、使い始めることができます。

- ソフトウェアエンジニア Jaana Dogan

- エンジニアリングディレクター Ethan Bao

法改正対応を AI で加速する富士通の挑戦：暗黙知の言語化が開発プロセスを変えた

Tue, 19 May 2026 02:00:00 +0000

行政システムや電子カルテなど、法律に基づく社会インフラを支えるソフトウェアの開発には、独特の難しさがあります。法改正のたびに、数百ページに及ぶ法令文書を読み解き、既存システムへの影響を見極め、限られた納期でシステム改修を完了させなければなりません。しかも、その判断ができるのは、長年の経験で培われた業務知識を持つごく一部のエンジニアだけ。

富士通株式会社は、このような既存システムの改修案件におこる構造的な課題に AI で挑んでおり、こうした取り組みを、富士通のシステム開発を変革するプロジェクト「Takane Driven Initiative」として推進しています。今回は、この検討プロセスの一部において、Google Cloud の Tech Acceleration Program（TAP）を知見探索の場として活用しました。ここで得た知見を社内の開発プロセスに還元し、「暗黙知の言語化」という独自のアプローチで成果を上げ始めました。今回は、AI Innovation Center の小副川健氏、Public＆Education事業本部の馬塲燿司氏、AI&Tech-Driven Transformation 本部の魚瀬秀明氏にお話を伺いました。

左から順に、インタビューにご協力いただいた富士通Japanの馬塲氏、富士通の小副川健氏、富士通Japanの魚瀬氏

属人化した現場の課題：800 ページの法令を読み解き、数ヶ月でシステムへの反映をせまられる現実

富士通が開発・提供する行政システムや医療システムは、法改正に合わせて改修を繰り返す宿命を持っています。

医療分野では 2 年に 1 度の診療報酬改定があり、1 月末に出される仕様は 3 月にかけて段階的に詳細化されていきます。それを 6 月の施行日までに、つまり、たった 3 ヶ月でシステムへ反映させなければなりません。対象となる法令文書は 800〜900 ページ。行政分野でも、マイナンバー制度や標準化法など、大規模な法改正が定期的に発生します。

「法律が変わると、当然システムも変えていかなければなりません。その作業を何年も繰り返してきた結果、システムの母体が大きくなり、保守が大きなウエイトを占める状況になっています」と馬塲氏は語ります。

改修を繰り返す中で保守のウェイトが増していく現場の実情を語る馬塲氏

課題は規模だけではありません。法令文書を読み込み、各自治体や医療機関での運用を頭に描きながらシステムを設計し改修を行うには、既存のソースコードの理解、コーディングスキルに加えて、深い業務知識が求められます。しかも、この作業にかけられる時間は多くはありません。できる人材はどうしても限られ、一部のベテランの担当の「暗黙知」として蓄積され、業務の属人化が進んでいました。

この問題の解決に向けて、富士通社内で立ち上がったのが全社横断の取り組み「Takane Driven Initiative 」です。富士通の技術と蓄積された業務知見をあわせ、設計から、製造、テストまでを一気通貫で AI が担う「AI-Driven Software Development Platform（AI-Driven SDP）」の開発を進めています。現在、行政とヘルスケアを中心に活用がはじまっています。

AI-Driven Software Development Platform の全体像

Gemini CLI との出会い：コンテキストの長さとインタラクティブ性が決め手に

AI-Driven SDP の開発を統括する小副川氏が Gemini に注目した理由は明快でした。

「まず、当時のタイミングで圧倒的にコンテキストが長かった。我々のソースコードの量が膨大なので、どれだけ詰め込めるかが重要だと考え、これに耐えうる AI として Gemini に注目、それをターミナルで使える Gemini CLI を選びました」

加えて、すでに Google Cloud 環境を利用していたことも後押しになりました。富士通が独自に開発する AI-Driven SDP は、設計から製造、テストに至るまで、全工程一気通貫で処理が実行されます。ただし、そのドメインナレッジは、各工程ごとに試行錯誤しながら整備する必要があります。Gemini CLI のインタラクティブなやり取りは、ベテランの持つ暗黙知の抽出と言語化のアプローチにマッチしていました。TAP での検証を通じて暗黙知抽出のアプローチを確立し、それをTakane Driven Initiative に持ち帰って活かすこと。それが今回の狙いでした。

TAP で見つけた「暗黙知を言語化する」アプローチ

Google Cloud の TAP では、3 日間のワークショップを通じて具体的な検証を行いました。馬塲氏のチームが取り組んだのは、過去に実施した法改正の案件を題材にした 4 段階のアプローチです。

Gemini CLI の応答を前に、富士通と Google Cloud が議論を重ねた

まず、過去の法改正における法令文書とソースコードを Gemini に読み込ませ、正しく改修できるかを試しました。ところが、最初はうまくはいきませんでした。

そこで次に、正解となるコードを与えて逆算させました。「この正解を導き出すにはどういう実装方針が必要か」を Gemini に考えさせ、実装方針を言語化させたのです。

そして、コンテキストをリセットした上で、導き出した実装方針に基づいて改めて改修を試みます。それでも正解に届かなければ、プロンプトをチューニングして精度を上げていく。

「この 3 つのステップだけではうまくいかなかったんですね。なぜかというと、我々の頭の中にしかない暗黙知、言語化されていないものがあると、やはり期待どおりの開発ができないということがわかりました」と馬塲氏は振り返ります。

ここから生まれたのが、4 つ目のステップ、暗黙知の体系的な言語化です。Gemini CLI とインタラクティブに対話しながら、「なぜ正解にたどり着けなかったのか」を考察させ、足りなかった知識を一つひとつ洗い出していきました。

魚瀬氏はこのプロセスを「新人を教育しているようなイメージ」と表現します。

「最初の 50 点から 100 点に引き上げるために何が足りなかったのかが、少しずつアウトプットされていく。それをまとめて体系化すると、『こういうことが足りなかったんだ』という気づきが得られるんです」

Gemini との対話を新人教育になぞらえて説明する魚瀬氏

ソースコードの構造を一度に学習させようとするとトークン超過が発生しましたが、体系的に順序を整理し、フューショット（Few-shot prompting）で段階的に知識を投入していくことで、精度は大きく向上しました。

技術よりも大きかった「マインドの変化」

TAP を通じて得られた最大の成果は、技術的な知見だけではありませんでした。

「一番大きなところは、マインドの変化です」と馬塲氏は言います。「暗黙知をちゃんと言語化して AI に読み込ませないと、正しい正解を導き出せないことが目に見えてわかりました。普段何気なくやっているシステム開発の一つひとつを、AI に教えるならどう言語化すればいいか、と考えるようになったんです」

この意識の変化は、TAP 後の活動にも波及しています。TAP で得た暗黙知抽出のノウハウを社内に展開したことで、AI エンジニアとして活動できる人材が増えるという副次的な効果も生まれました。

小副川氏はこう補足します。「AI-Driven SDP における暗黙知の抽出・体系化プロセスとして整理し、環境やモデルが変わっても活用できる手法として確立したことで、ベテランの経験がなくても暗黙知を抽出できる人材が育ちつつあります」

Google Cloud スペシャリストとの連携で大きな手応え

TAP での Google Cloud スペシャリストとの協業について、馬塲氏は「非常に素晴らしかった」と評価します。

「目先のゴール達成だけでなく、ビジネスの背景や目的から理解していただきました。3 日間に限らず、その後も個別のフォローアップをしていただき、暗黙知の言語化についても継続的に支援を受けられたのは非常にありがたかったです」

魚瀬氏も、まず課題の真因に対して仮説を立て、それに対してどういった技術とアプローチで解決できるかを議論するという進め方に手応えを感じたと話します。

「来るたびに最新の技術を出し惜しみなく紹介してくれて、それを自分たちの中でどう活用できるかを検討できました」

小副川氏は「非常に真摯に課題に向き合っていただいた。自分たちの技術やサービスを当てはめようとするのではなく、課題そのものをしっかり見てくれた」と振り返ります。

Google Cloud スペシャリストとの協業を「課題そのものをしっかり見てくれた」と振り返る小副川氏

AI が主役になる開発、その先にあるもの

富士通は TAP で得た知見を AI-Driven SDP に還元し、法令の解釈から設計、製造、テストまでの全工程自動化を目指しています。プレスリリースでは、3 人月を要していた改修期間を 4 時間に短縮した実証結果も報告されました。

ただし、課題も残っています。馬塲氏は「AI は同じ命令を与えても結果が微妙に異なります。社会システムでは再現性が必須なので、間違ったアウトプットを検知して軌道修正する仕組みが必要です」と指摘します。

今後の展望について、魚瀬氏はこう語ります。「私たちはソフトウェアを通じてお客様の課題を解決するためにこの仕事をしています。AI が開発を加速してくれるなら、空いた時間でお客様のところに行き、業種を横断した社会課題の解決に取り組みたい。それが真の目的だと思っています」

馬塲氏は、AI を開発に活用する上での心構えをこう締めくくりました。

「今回の AI は、補助ではなくシステム開発の主役です。高速にアウトプットが出てきますが、それは最後の一瞬の動作にすぎません。裏には、暗黙知を地道に言語化して蓄えさせるという準備がある。一足飛びではなく、その地道な作業があってこそだということを、社内にも広めていきたいと思っています。そして今後も、社会システムに求められる品質と再現性を満たす AI ドリブン開発の在り方を追求していきます」

Tech Acceleration Program (TAP) とは

グーグル・クラウド・ジャパンは、ユーザー企業の DX の取り組みを加速させるために、生成 AI やクラウドネイティブな技術を活用して、実際のアプリケーションを題材に、迅速で効率的なアプリケーション開発を体験するアジャイル型のワークショップ「Tech Acceleration Program (TAP) 」を提供しています。TAP ではアジャイルなアプリケーション開発を支援するための環境づくり（開発環境の整備やコンテナベースのプラットフォームの検討など）もご支援しています。こちらからお問い合わせください。

インタビュイー

富士通株式会社
・AI Innovation Center 小副川健様

富士通Japan株式会社
・Public＆Education事業本部馬塲燿司様
・AI&Tech-Driven Transformation 本部魚瀬秀明様

Gemini Cloud Assist: ユーザーの指示を待たずにユーザーに代わって機能するプロアクティブなクラウド運用

Thu, 07 May 2026 01:00:00 +0000

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

このたび、Google Cloud Next において、よりプロアクティブな運用を可能にするアップデートが AI 支援型クラウド運用プラットフォームの Gemini Cloud Assist に導入されたことを発表いたします。このアップデートにより、Google Cloud の運用が手動のワークフローから、エージェントの強力なエコシステムに支えられたプロアクティブでインテリジェントなエクスペリエンスに移行します。

このアップデートの重要性: 新しいエージェントアーキテクチャにより、Gemini Cloud Assist が煩雑なクラウド管理作業をユーザーに代わって処理できるようになります。インテリジェンス、企業のコンテキスト、Gemini の機能を運用レイヤに直接組み込むことで、Gemini Cloud Assist は、アプリケーションの設計、問題のトラブルシューティング、コストの先行的な最適化など、これまで人間の継続的な監視が必要だった複雑なタスクをプロアクティブに実行します。エンタープライズ規模のシステムでこのアプローチを採用すれば、開発速度が向上し、解決までの時間が短縮されます。

新機能:

自然言語と Gemini の機能を使用することで、再設計された App Design Center での設計から新規のデプロイまたは既存のマルチリソースデプロイメントまでの時間を短縮できます。
gcloud、kubectl、Terraform を使用してインフラストラクチャ運用を自動化し、プロアクティブなマルチターンエージェントを使用してインシデントのトラブルシューティングと解決を行います。
支出の急増を分析してオンデマンドで詳細な費用レポートを生成するプロアクティブな FinOps エージェントにより、24 時間 365 日、費用の異常を検出できます。
どこからでもサポートを提供。Google Cloud MCP サーバーとプロアクティブなエージェントを基盤とする Gemini Cloud Assist は、設計、運用、トラブルシューティング、最適化の機能を公開された MCP サーバーとして公開し、IDE から直接利用できるようにしています。

「Gemini Cloud Assist は当社の開発チームを大いに助けてくれました。Google Cloud に関する質問について、開発チームに連絡する回数やタッチポイントが 60% 減少しました。これにより、当社のクラウドチームはより効果的にスケールし、より複雑なタスクに集中できるようになりました。」- Petco、シニアクラウドエンジニア、Oscar Aldana Assad 氏

エージェント型の Gemini Cloud Assist がどのように運用を支援できるか、詳しく見ていきましょう。

App Design Center で本番環境への準備を加速

Gemini Cloud Assist は、App Design Center のインテリジェントな推論エンジンとして機能し、自然言語のインテントと、視覚的でプロダクションレディなアーキテクチャとの橋渡し役を果たします。Gemini Cloud Assist は App Design Center を活用し、インフラストラクチャの目標を平易な言葉で記述することで、デプロイ可能な Terraform を含むビジュアルデザインを自動的に作成します。これらのテンプレートは、Google Cloud のベストプラクティスアーキテクチャガイダンスに基づいており、セキュリティ、信頼性、コンプライアンスを設計段階から実現するのに役立ちます。Security Command Center と統合されているため、組織のポリシーに準拠したアイデアを迅速にデプロイできます。

プラットフォームチームは、事前承認されたテンプレートの共有カタログをキュレートし、独自のカスタム Terraform モジュールを設計プロセスに直接統合して、管理されたフレームワークを提供できます。この確立された信頼性の高いアプローチは、デベロッパーがデプロイの初日から組織のセキュリティとコンプライアンスのガードレールを遵守するのに役立ちます。Gemini は、クラウドリソースを更新するためのインタラクティブなマルチターン問題解決により、最初のデプロイだけでなくアプリケーションのライフサイクル全体をサポートします。

事後対応型から事前対応型の修復へ

本番環境では、Gemini Cloud Assist によって運用を事後対応のトラブルシューティングから仮説の迅速な分析に移行させ、解決までの時間を短縮することができます。アラートによってトリガーされた Gemini Cloud Assist は、シグナルをプロアクティブにクラスタ化して分析し、問題がエスカレートする前に調査を開始します。Gemini 3 を搭載した Gemini Cloud Assist は、ログと指標を関連付け、インフラストラクチャのシグナルからアプリケーションコードにまで掘り下げて根本原因を特定します。Gemini Cloud Assist は、ツール呼び出しを介して複数の仮説を同時に検証し、観測結果の技術的な分析を一元化された UI に表示します。根本的な Google Cloud の問題に対処するために人間の介入が必要な場合、ユーザーは完全なコンテキストを Google サポートに引き渡すことができます。これにより、構成やコンテキストのデータを共有するために必要な反復処理を最小限に抑えることができます。

24 時間 365 日体制での費用の異常の特定

Gemini Cloud Assist はプロジェクトの事前最適化エージェントとして機能し、経済的な健全性の維持を支援します。Gemini Cloud Assist は 24 時間 365 日バックグラウンドで実行され、費用の異常をモニタリングし、根本原因分析を提供します。費用の急増を、新しいリソースの作成、自動スケーリングイベント、料金の変更などの特定のエンジニアリングトリガーと関連付けます。自然言語でリソース使用率をクエリして、AppHub に登録されているプロジェクトとアプリケーションごとに、オンデマンドの表形式レポートを生成できます。これにより、手動でデータを集計することなく、「誰が、何を、いつ、どのように」使用したかを詳細に把握することができます。たとえば、「昨日、アプリケーションの費用が増加したのはなぜですか？」や「先月のプロジェクトの費用はいくらでしたか？」と質問すると、Gemini Cloud Assist は費用データとインフラストラクチャの変更、監査、モニタリングのログを関連付けて正確な回答を返します。

あらゆる場所でアシスタンスを提供

Google は、利用可能なサーフェスの拡大により、ユーザーが実際に作業する場所で Gemini Cloud Assist を利用できるように努めています。Gemini Cloud Assist エージェントは、コンソールとモバイルインターフェースからすでにアクセスできるようになっています。また、Model Context Protocol（MCP）に新たに対応したことで、Gemini Cloud Assist を Gemini CLI、任意のエージェント IDE や CLI のほか、ServiceNow や Slack などのサードパーティツールチェーンで利用できるようになりました。既存のワークフローにプロアクティブな支援を統合することで、チームはコンテキストの切り替えを回避し、フローの中断を防ぐことができます。

プロアクティブな機能を簡単に利用

Gemini Cloud Assist は、新しいアプリケーションのデプロイからクラウド内の既存のアプリケーションの管理まで、マルチエージェントアプローチを提供し、アプリケーションのエンドツーエンドのライフサイクルを管理できるように設計されています。Gemini 3 のサポートにより、Gemini Cloud Assist では以下のことが可能になりました。

開発速度の向上: ベストプラクティス、セキュリティポリシー、企業のコンプライアンスを統合するインテント駆動型アーキテクチャを使用して、本番環境への準備を加速します。
本番環境の運用を合理化: Gemini によるトラブルシューティング、推奨事項、修復を通じて、本番環境の問題のトリアージ、診断、解決を迅速化します。
費用最適化の自動化: プロジェクトの費用の異常を毎日自動的に検出、分析し、根本原因の特定やアラート通知を行います。
チームのニーズに対応: Google Cloud コンソールから CLI や IDE に至るさまざまなサーフェスからプロアクティブなエージェントと MCP ツールを通じて機能を利用できるため、チームはフロー状態を維持できます。

運用の未来はエージェントにあります。今すぐプロジェクト設定で Gemini Cloud Assist を有効にして、プロアクティブなクラウドの利用を開始しましょう。

- Cloud Foundations 担当バイスプレジデント兼ゼネラルマネージャー、Michael Bachman

- プロダクト管理担当シニアディレクター、Ines Envid

Next ‘26 で発表された GKE の新機能

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

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

今週開催の Google Cloud Next ‘26 では、Google Kubernetes Engine（GKE）の進化についてご紹介しています。GKE は、特に要求が厳しく複雑なワークロードや、次世代の AI アプリケーションとエージェントアプリケーションに対して、優れたパフォーマンス、効率性、セキュリティ、スケーラビリティを提供します。

重要である理由: Kubernetes は AI 時代のオペレーティングシステムとして急速に普及しており、GKE は現在、最大規模のフロンティアモデルの構築企業を含む、プラットフォーム上の上位 50 社すべてのお客様の AI ワークロードを支えています。エンタープライズ AI は急速に普及しています。わずか数か月で、マルチエージェント AI ワークフローの数が 327% も急増しました。同時に、組織の 66% が生成 AI アプリやエージェントの強化に Kubernetes を利用しています。

自律型エージェントが大規模に運用されるこの新しい時代には、インフラストラクチャの管理方法に根本的な変革が求められています。これは、ステートレスアプリケーションからステートフルアプリケーションへの移行よりも要求の厳しい変革です。

新機能:

GKE Agent Sandbox: 安全でスケーラビリティが高く、低レイテンシのエージェントインフラストラクチャ
GKE ハイパークラスタ: Google Cloud リージョン全体で数百万のアクセラレータを管理する、単一の適合 GKE コントロールプレーン
推論パフォーマンスの向上: GKE Inference Gateway と KV キャッシュ管理の基盤となる機能強化
強化学習（RL）の強化機能: アクセラレータ使用率をスロットリングするボトルネックを解消するネイティブ機能
カスタム指標に基づくスケーリング: CPU とメモリ以外のトリガーに基づくインテントベースの自動スケーリングをサポート

GKE に関するこれらのお知らせについて詳しく説明します。

GKE Agent Sandbox: エージェント時代を加速

AI が単純な会話型チャットボットから、エコシステム全体へのプロアクティブで自律的なエージェントへと進化するにつれて、基盤となるインフラストラクチャは、従業員と連携して複雑なタスクを計画、評価、実行するために数百または数千のエージェントを処理できるように適応していく必要があります。大規模なインフラストラクチャでは、パフォーマンス、応答性、厳格なセキュリティが不可欠です。

このたび Google は、業界有数のスケーラビリティと低レイテンシを誇る AI エージェントインフラストラクチャである GKE Agent Sandbox を発表しました。Gemini の保護と同じ gVisor カーネル分離テクノロジーで構築された Agent Sandbox を使用すると、パフォーマンスを犠牲にすることなく、信頼できないコード、ツール、エージェント全体を安全に実行できます。GKE は、完全に分離されたエージェントに対して、1 秒あたり 300 個のサンドボックス、1 秒未満のレイテンシ、Axion で実行した場合の他のハイパースケールクラウドと比較して最大 30% 優れた費用対効果を実現し、業界をリードするスピードと効率性を提供します。

Lovable を使用すると、誰でもアプリやウェブサイトを構築できます。毎日ビルダーによって 20 万件以上の新しいプロジェクトが作成されています。Lovable では、起動の速さとスケーリングの速さ、そして安全な分離が可能なことから、これらの AI 生成アプリケーションを GKE Agent Sandbox で実行しています。

「GKE の最先端のサンドボックス機能により、1 秒あたり数百個の安全なサンドボックスに確実にスケーリングできるため、予測不能な膨大な需要が発生した場合でも、ビルダーをシームレスに支援できます」- Lovable、共同創業者 Fabian Hedin 氏

GKE ハイパークラスタがスケーラビリティの上限を再定義

基盤となる AI モデルが指数関数的に成長し、アクセラレータの需要が高い状態が続いているため、組織は Kubernetes コンピューティングインフラストラクチャを数百の切断されたクラスタに分割する手段をとっており、これは、運用上の大きな負担につながる可能性があります。この問題を解決するために、Google は GKE ハイパークラスタの限定公開 GA を発表します。これにより、複数の Google Cloud リージョンにまたがる 256,000 個のノードに分散された 100 万個のチップを、Kubernetes に準拠した単一の GKE コントロールプレーンで管理できるようになります。GKE ハイパークラスタを使用すると、広範囲に分散されたインフラストラクチャが、複数の地理的場所にまたがる単一の統合された容量の予備となります。

セキュリティを損なうことなくグローバルにスケーリングするために、GKE ハイパークラスタは Google の Titanium Intelligence Enclave を利用しています。これは、プライベート AI コンピューティングを提供するソフトウェア強化型のセキュリティエンジンです。この「管理者権限なし」モデルは、ハードウェア証明済みの Pod レベルの分離を提供するため、独自のモデルの重みとプロンプトは、プラットフォーム管理者とインフラストラクチャレイヤから暗号的にシールされたままになります。

最先端の推論を強化

最先端の推論を実現するには、数か月にわたる複雑なパフォーマンスチューニングが必要です。この手間を軽減するために、GKE では TPU と GPU 全体で「SOTA までの時間」をわずか数分に短縮しました。これを実現するために、以下の新機能を提供しています。

GKE Inference Gateway の ML を活用した予測レイテンシブースト。ヒューリスティックな推測をリアルタイムの容量を考慮したルーティングに置き換えることで、最初のトークンまでの時間（TTFT）のレイテンシを最大 70% 削減できます。手動によるチューニングは必要ありません。
RAM、ローカル SSD、GCS/Lustre 間での自動 KV キャッシュストレージティアリングにより、長いコンテキストのメモリボトルネックが解消されます。KV キャッシュを RAM にオフロードすると、システムプロンプトの長さが 10,000 の場合、TTFT が 40% 以上短縮され、スループットが 50% 向上しました。KV キャッシュをローカル SSD にオフロードすると、システムプロンプトの長さが 50,000 の場合、スループットがほぼ 70% 向上しました。これらのベンチマークについて詳しくは、llm-d Offloading Prefix Cache to Shared Storage guide をご覧ください。

レイヤ化されたコンポーズ可能なスイートの一部として構築されたこれらの新しい GKE 機能は、現在公式の CNCF サンドボックスプロジェクトである llm-d を活用しています。最大限の柔軟性を実現するため、Google は NVIDIA と緊密に連携して Dynamo をシームレスに統合し、大規模な混合エキスパート（MoE）モデルをスケーリングできるようにしました。どのツールを選択しても、GKE は、あらゆる最先端の AI ワークロードを安全に実行するために必要な、高度に最適化された柔軟なインフラストラクチャを提供します。これには、新しく発表された Gemma 4 の高度なエージェント機能も含まれます。

RL コンピューティングのボトルネックの解消

強化学習（RL）は AI コンピューティング需要の重要な推進力であり、RL ジョブにはサンプリング、報酬、トレーニングの順次処理が含まれます。これらの RL ステップの間では GPU および TPU アクセラレータがアイドル状態になる可能性があります。RL を効率化するために、新しい GKE 機能をプレビュー版として追加しています。

RL スケジューラは「ストラグラー効果」とバッチ間のテールレイテンシを解決し、インテリジェントなルーティングによってスループットを最大化します。
RL Sandbox は、ツール呼び出しと報酬評価のためにカーネルレベルの分離を提供し、ミリ秒単位でプロビジョニングします。RL サンプリングと報酬のステップとの統合は簡単です。
RL のオブザーバビリティと信頼性のダッシュボードは、RL ループ全体のトラブルシューティングと最適化を即座に、すぐに使える状態で実行するために必要な詳細な可視性を提供します。

GKE レシピの RL、特に Verl と NeMo RL の実装をご確認ください。

カスタム指標に基づくインテントベースの自動スケーリング

従来、アプリケーションの健全性に基づいて AI ワークロードをスケーリングするには、「カスタム指標税」が課せられていました。基本的なコンピューティングやメモリ使用率以外の要素に基づいてシステムをスケーリングするには、組織は複雑なモニタリングシステムと IAM ロールを管理する必要があります。これにより、運用上のリスクが生じます。外部のオブザーバビリティスタックに障害が発生すると、自動スケーリングも機能しなくなります。

インテントベースの自動スケーリングでは、GKE の HorizontalPodAutoscaler（HPA）のネイティブなカスタム指標サポート により、このオーバーヘッドが解消されます。このエージェントレスアーキテクチャは、Pod から直接指標を取得することで外部依存関係を回避し、信頼性を高めながらコストを削減します。重要なのは、反応時間が 25 秒からわずか 5 秒に短縮されたことです。これは、インフラストラクチャの弾力性がほぼ瞬時に発揮されることを意味し、パフォーマンスが 5 倍向上しています。

新しいワークロード、変わらないミッション

GKE は 10 年以上にわたり、スケーラブルなインフラストラクチャの標準を確立してきました。エージェント AI と自律型 AI の時代を迎えても、Google の使命は変わりません。それは、運用上の摩擦を排除し、お客様がイノベーションに集中できるようにすることです。Next '26 で発表する機能（GKE ハイパークラスタ、Agent Sandbox、超高速推論、インテントベースの自動スケーリングなど）は、意欲的な AI ワークロードを成功させるために必要な、安全で効率的かつ強力なエンジンを提供します。AI ワークロードに GKE を使用する方法について詳しくは、GKE Inference Quickstart をご覧ください。

- オーケストレーションおよび Kubernetes プロダクト管理担当シニアディレクター Drew Bradstock

- GKE グループプロダクトマネージャー Gari Singh

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 0x7fa774fa9490>)])]>

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 0x7fa774fa9640>)])]>

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 0x7fa774fa9a90>)])]>

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

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 0x7fa775ba2a00>)])]>

このポリシーが適用されると、エージェントはデータセットスキーマを自由に検索できますが、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 0x7fa775ba2d30>)])]>

次に、プロジェクト内のすべての 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 0x7fa7743fff70>)])]>

有効化すると、呼び出し元のエージェントまたはクライアントに関係なく、プロジェクト内のすべての 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 0x7fa774f85af0>)])]>

倉庫ロボットサービスは、次のようなバイナリの 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 0x7fa774f85190>)])]>

物流部門は、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 0x7fa774f85550>)])]>

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

エージェントのワークフロー: 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 0x7fa774f85940>)])]>

フィルタが渡されると、パイプラインは 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 0x7fa774f856a0>)])]>

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 0x7fa7741d6370>)])]>

最後に、パイプラインに直接、堅牢な再試行ポリシー（線形バックオフ、最大 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 0x7fa76bc63a00>)])]>

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 0x7fa76bc63400>)])]>

以上です。必要な 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 0x7fa774328610>)])]>

このように分けてしまうことで、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 と共に歩む彼らの取り組みは、製薬業界のみならず、多くの企業の開発現場に新たな可能性を示唆していると言えるでしょう。

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

インタビュイー

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

アプリケーション開発

Cloud Run、Firebase、Cloud SQL を使用したフルスタックのバイブ コーディングが AI Studio で可能に（クレジット カードは不要）

手軽に導入: Google Cloud スターター ティア

Cloud SQL でフルスタックのバイブ コーディングを強化

Firestore と Firebase Auth を使用したフルスタックのバイブ コーディング

AI Studio を使ってみる

Google Cloud でリソース単位からビジネス単位のメンテナンスへの移行を実現

ビジネスに焦点を移す

仕組み

使ってみる

Google の分散エージェント ランタイム、Agent Executor のご紹介

Google のエージェント ランタイムと連携する

エージェント、モデル、コンピューティングを自社で管理する

エージェント ファーストのコンピューティング レイヤを使用して Kubernetes 上でエージェントをスケール

使ってみる

法改正対応を AI で加速する富士通の挑戦：暗黙知の言語化が開発プロセスを変えた

属人化した現場の課題：800 ページの法令を読み解き、数ヶ月でシステムへの反映をせまられる現実

Gemini CLI との出会い：コンテキストの長さとインタラクティブ性が決め手に

TAP で見つけた「暗黙知を言語化する」アプローチ

技術よりも大きかった「マインドの変化」

Google Cloud スペシャリストとの連携で大きな手応え

AI が主役になる開発、その先にあるもの

Gemini Cloud Assist: ユーザーの指示を待たずにユーザーに代わって機能するプロアクティブなクラウド運用

App Design Center で本番環境への準備を加速

事後対応型から事前対応型の修復へ

24 時間 365 日体制での費用の異常の特定

あらゆる場所でアシスタンスを提供

プロアクティブな機能を簡単に利用

Next ‘26 で発表された GKE の新機能

GKE Agent Sandbox: エージェント時代を加速

GKE ハイパークラスタがスケーラビリティの上限を再定義

最先端の推論を強化

RL コンピューティングのボトルネックの解消

カスタム指標に基づくインテントベースの自動スケーリング

新しいワークロード、変わらないミッション

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 でデータを活用して構築する

Cloud Run、Firebase、Cloud SQL を使用したフルスタックのバイブコーディングが AI Studio で可能に（クレジットカードは不要）

手軽に導入: Google Cloud スターターティア

Cloud SQL でフルスタックのバイブコーディングを強化

Firestore と Firebase Auth を使用したフルスタックのバイブコーディング

Google の分散エージェントランタイム、Agent Executor のご紹介

Google のエージェントランタイムと連携する

エージェントファーストのコンピューティングレイヤを使用して Kubernetes 上でエージェントをスケール

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

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

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

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

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

バス: ガバナンスレイヤ

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

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

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

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

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

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

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

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

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

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

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