Cloud Blog JA

セガサミーホールディングス: Google Security Operations と Google Threat Intelligence を導入し、セキュリティ対策をグローバルで標準化へ

Fri, 17 Jul 2026 02:00:00 +0000

セガサミーグループはグローバルにビジネスを展開する総合エンタテインメント企業です。そのコーポレート IT を担うセガサミーホールディングス株式会社（以下、セガサミー HD）IT ソリューション本部は、SIEM（Security Information and Event Management）の刷新を機に Google Cloud Security の利用検討を開始し、導入を決定。個別最適で積み上がってきたセキュリティ運用の統合管理へと大きく舵を切りました。本プロジェクトの中核メンバーに、当初の課題から選定の決め手、今後の展望までを伺います。

利用しているサービス:
Google Security Operations, Google Threat Intelligence など

利用しているソリューション:
セキュリティ

"個別最適" がもたらした、セキュリティ管理・運用体制の構造的課題

セガサミーグループは、ゲームコンテンツや映像作品などを手がける「エンタテインメントコンテンツ事業」、パチンコ・パチスロ機器の製造・販売などを行う「遊技機事業」、そしてゲーミング機器の開発や統合型リゾートの運営などを行う「ゲーミング事業」という 3 つの柱を持つ、総合エンタテインメント企業グループです。グループで保有する機密情報は、未発売ゲームタイトルの開発データから遊技機の技術情報、さらにはビジネスのノウハウやユーザー情報まで多岐にわたります。セガサミー HD IT ソリューション本部の宮地雅人氏は、「金融系の情報ではないものの、外部への漏えいは絶対に許されないものばかり」だと前置きし、同社が抱えるセキュリティ管理の課題を次のように説明します。

「当グループでは厳しいセキュリティ要件に対応すべく、各セキュリティ領域において、その時点で最も優れた製品を個別に選定・導入する方針を取ってきました。しかし結果として、機能ごとにコンソールが乱立する状況が生まれ、管理・運用の大きな負担になっていたことは否めません。こうした状況を解消し、セキュリティを統合して管理・運用できる環境に移行したいという気持ちが強まってきたのです。」

加えて、ログ管理の中核を担ってきたオンプレミス型 SIEM の老朽化が進んでいたことも解決すべき課題でした。同社 SOC（Security Operations Center）担当として、サイバー攻撃の検出やログ分析を担ってきた IT ソリューション本部グローバルセキュリティ推進室 IT インフラセキュリティ課田邉由嗣氏は、当時の SIEM 環境の課題をこう振り返ります。

「従来のオンプレミス型 SIEM は、とにかくログを集約し、オンラインで見られる状態にしておこうという発想で構築されたものでした。しかし、ログの量があまりに膨大だったため、すべてのログを入れておけない状態が長く続いており、思うような分析ができずにいたのです。増設やクラウド型 SIEM への移行も検討していたのですが、コストの増大などを嫌って後回しにしてしまい、気がつけば抜本的な見直しが急務になっていました。」

ログを蓄積するだけの運用から、インテリジェントな活用へ

そうした中、2024 年ごろ、各国の拠点で個別に管理・運用されていた IT 施策を、セガサミー HD がヘッドクオーターとなって指揮する方針が決定。セキュリティ製品についてもグローバルで統一しようという機運が高まり、蓄積してきた課題を一気に解消するチャンスが巡ってきました。グローバルセキュリティ推進室グローバルセキュリティ企画課範國貴栄氏によれば、新環境に向けたセキュリティソリューション選定で重視されたのは、総合的な利便性の高さでした。

「複数のクラウド型 SIEM を比較・検討した結果、行き着いたのが Google Security Operations（SecOps）でした。最大の決め手となったのが、その利便性の高さ。ログを蓄積してしまえば、標準で搭載されている Curated Detections が自動で脅威検知し、独自アラートルールの作成を Gemini に手伝ってもらうこともできます。我々の目指す、ログのインテリジェントな活用という方向性に最も近い選択肢だと感じました。また、ダッシュボードもカスタマイズしやすいため、グローバルなレベルで運用の標準化を促進する効果も見込まれました。」

さらに「比較・検討した他社製品と比べてコストメリットが大きかった」（宮地氏）という要因も導入を後押ししたといいます。このような中、2024 年 7 月からの PoV（価値実証）、10 月の部門内レビュー、年末の役員説明を経て、2025 年 4 月から、まずは国内での正式な活用がスタートすることになりました。

「Google Cloud のパートナーである株式会社リベルスカイの伴走や、Google Cloud サポートチームの献身的な対応もあり、スムーズに移行することができました。しいて言えば、ログを中継して SecOps に投げるサーバーの構築に少し苦労した程度です。SecOps は Gemini と連携させていくことにより、SIEM という難解な印象の強いソリューションを扱いやすくし、セキュリティに関する全社的なリテラシーを高めていく効果も期待できます。現在は旧来のオンプレミス型 SIEM も並行して動かしていますが、年内には完全に切り替えが完了し、海外拠点でも順次切り替えを進めていく見込みです。」（範國氏）

「ちなみにエストニアの拠点は、今回の取り組みに先行して SecOps の導入を進めていました。彼らも使い始めたばかりですが、実際的な運用方法や細かなチューニングなども含めて弊社グループ内で積極的に情報を共有し、より高度な活用につなげていければと考えています。」（宮地氏）

SecOps と Google Threat Intelligence による管理体制を世界 80 拠点で標準化

今回の SecOps 導入では、運用体制の変革をもたらすことも期待されています。同社の SOC 業務では、スタッフ個々の負担増加や、ノウハウが属人化してしまう状況をいかに回避するかが、目標になってきました。

「少人数 SOC による属人化状態になってしまうと、他の業務の繁忙期や、担当者が体調不良になった際に監視・分析が止まってしまうことも考えられます。しかし、SecOps のように AI も活用しながら、誰でも脅威や侵害に気づいて迅速に対策できるツールがあれば、工数をチームメンバーに分散でき、属人化も解消できます。何より、より多くの社員が実際の運用に関わるようになることで、SOC 業務が "自分ごと化" される価値も大きいと感じています。今後はチケット管理ツールなどと連携させ、アラートから通知までを一気通貫でつなげて自動化させていく予定です。SOC の負荷をさらに低減し、本来やるべきセキュリティ対策の議論に時間を割けるようにしていきたいです。」（田邉氏）

属人化の解消という点では、脅威インテリジェンスの領域でも変革が進んでいます。従来使っていた脅威インテリジェンスサービスは製品としては非常に優れていたものの、ライセンス料が高額で、各拠点に 1 ライセンスずつしか割り振れていない悩みがありました。これを解決すべく、SecOps の導入に並行して、Google Threat Intelligence も採用されています。

「ライセンスが少ないと脅威情報にアクセスできる人間が、ごく一握りになってしまいます。その点、Google Threat Intelligence であれば、同じ予算で各拠点のセキュリティ担当者全員にアカウントを払い出せます。SIEM への取り込みなど、API 連携が容易な点も魅力的です。これにより、自分たちの会社の脅威情報を自分たちでプロアクティブに見にいける環境を整えることができたと思っています。」（宮地氏）

「受け身ではない、能動的なセキュリティ対策は、数年前から目指していました。従来の環境ではうまく実現できていなかったことが、Google Threat Intelligence の導入でいよいよ本格的に実現できるのではないかと期待しています。」（田邉氏）

今後、セガサミー HD は、Sega of America、Sega Europe など、およそ 80 にもおよぶ海外拠点に対して、SecOps や Google Threat Intelligence をはじめとする Google Cloud のセキュリティソリューションを統一的に展開していく予定です。

「ここで活きてくるのが、そのブランド力です。Google Cloud は世界中の誰もが知っており、どの地域でも利用できるため、各海外拠点のエンジニアたちにもすんなりと受け入れてもらえます。今後は ASM（Attack Surface Management）や、CNAPP（Cloud Native Application Protection Platform）である Wiz なども活用し、製品開発業務の生産性や、サービスの品質を世界中で高めていきたいと考えています。」（宮地氏）

セガサミーホールディングス株式会社
2004 年 10 月 1 日に大手パチンコ・パチスロ機器メーカーのサミーと、大手ゲームメーカーのセガの経営統合により設立された総合エンタテインメント企業グループの持株会社。グループの経営管理および、コーポレート IT 整備などの附帯業務を行う。従業員数は単体で 492 名、グループ連結で 11,944 名（2026 年 3 月末現在）。

インタビュイー（写真右から）
IT ソリューション本部
・グローバルセキュリティ推進室部長兼セキュリティガバナンス管理課課長兼
　グループ CIO 室　宮地雅人氏
・グローバルセキュリティ推進室グローバルセキュリティ企画課　範國貴栄氏
・グローバルセキュリティ推進室 IT インフラセキュリティ課　田邉由嗣氏

その他の導入事例はこちらをご覧ください。

エージェンティックエンタープライズに関する 20 の質問（Agent Platform がどのように役立つか）

Fri, 17 Jul 2026 02:00:00 +0000

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

IT リーダーであれば、エージェントの構築とデプロイの方法について多くの質問を受けているかもしれません。

迅速な対応を求めるプレッシャーは強いものですが、エンジニアリングの現実は極めて複雑です。チームはどこから着手すればよいのでしょうか。断片化し、バラバラに乱立するツール群を、どのように整理すればよいのでしょうか。また、規模が拡大するにつれて、エージェントが誤って機密データを漏洩したり、わずか半日でトークン予算を使い果たしたりしないようにするには、どうすればよいでしょうか。バランスを取るべきことが多く、組織全体の安全な基盤を確立しようとすると、すぐに手に負えないと感じてしまう可能性があります。

Google が Gemini Enterprise Agent Platform を構築したのはそのためです。これにより、技術チームは、顧客対応エージェントと社内業務を管理するエージェントの両方を構築、スケーリング、ガバナンス、最適化できる統合された環境を利用できるようになります。根底にある複雑な制御は Agent Platform が担うため、チームは本来のビジネス価値の創出に集中できます。

こうした会話をスムーズに進めるために、エンジニアリングチームに尋ねるべき 20 の重要な質問と、すぐに着手できる実用的なアドバイスやコード例をまとめました。それでは詳しく見ていきましょう。

構築フェーズ — 基盤の確立

#0 アプリケーションを構築しているのは誰か？ツールを選択する前に、チームの誰が実際に作業を行っているかを確認します。エンジニアでしょうか？それとも法務チームでしょうか？AI を活用した構築は、もはやハイコードエンジニアだけのものではありません。誰でもバイブコードを生成できるようになりました。この驚くべきアクセシビリティにより、数百万人の非プログラマーが、数秒でアプリケーションを構築してリリースできるクリエイターに変わったのです。つまり、社内のあらゆる場所からアプリケーションが生まれてくる可能性があるということです。これは当たり前のステップのように聞こえるかもしれませんが、AI 時代においては非常に重要な意味を持ちます。

現在、このエコシステムは、ノーコードのビジネスエキスパートがビジュアルインターフェースを介してロジックを定義する（ビジネスチーム、セールス、マーケティングなど）、ローコード デベロッパーがモジュール部品を組み立てる、ハイコード エンジニアがオーダーメイドのカスタム推論ループを作成するなど、幅広い層のペルソナを網羅しています。導入を成功させる鍵は、データやセキュリティをサイロ化することなく、3 つのペルソナすべてを支援するプラットフォームを選択することにあります。

#1 デベロッパーはどこから始めるべきか？エージェント活用戦略を立てる際、カスタマーサポートや財務分析を行うエージェントなど、最終的な成果物にのみ焦点を当てがちです。しかし、そのように高度なエージェントを構築するには、まず、その基盤となるロジックを記述するビルダーを支援することから始める必要があります。デベロッパーがコード生成やスキャフォールディング、統合を加速させるには、コーディングエージェントのような専用の AI ツールが必要です。

しかし、ほとんどのコーディングエージェントは孤立した状態にあります。これらのツールは、作業中のファイルを分析することしかできず、稼働中のデータベース、社内ドキュメント、技術スタック、ビジネスシステムとは連携されていません。

デベロッパーがガバナンスを犠牲にすることなく迅速に開発を進められるようにするには、Google Antigravity を主要なエンジニアリングハーネスとして使用し、チームが構築しているものに基づいて特定の拡張機能を統合することをおすすめします。以下に、その内訳を示します。

コアアプリケーションエンジニア向け: アップグレードされた Agent Development Kit（ADK）をベースラインフレームワークとして使用し、Agents CLI と組み合わせて、ターミナルからエージェントのライフサイクル全体を管理しましょう。
データエンジニア向け: データパイプラインに特化した専用スキルや Model Context Protocol（MCP）ツールを提供する Google Cloud Data Agent Kit を導入しましょう。
Google Cloud エコシステム向け: エージェントスキルをデプロイして、Google プロダクトを横断するネイティブな機能をコーディング環境に持たせましょう。
IDE 統合エクスペリエンス向け: MCP を介してデベロッパー向けナレッジベースに接続し、公式ドキュメントをチームのワークフローに直接取り込みましょう。

#2 誰のために構築するのか？人間か、それとも他のエージェントか？#1 と同様に、これは単純な質問のように聞こえるかもしれませんが、従業員が直接対話する AI エージェントを構築するのか、それとも舞台裏で他のエージェントと連携させるのかを、早い段階で判断しておくのがよいでしょう。システムとやり取りするユーザーや対象によって、設計要件はまったく異なります。すべてをチームの管理下に置くには、まず誰のために構築しているのかを正確に把握することが重要です。

対象が人間（従業員や顧客向けに構築）の場合は、ユーザーエクスペリエンスに焦点を当てましょう。これらのツールは、Gemini Enterprise app のような単一の場所でホストして共有できます。また、Agent-to-User Interface（A2UI）フレームワークを使用して、インタラクティブなコンポーネントをカスタムアプリに直接組み込むこともできます。

対象がエージェントの場合（他のエージェントと対話するエージェントを構築する場合）、相互運用性に焦点を当てましょう。AI エージェント間のシームレスな通信とコラボレーションのためのオープン標準である、オープンな Agent2Agent（A2A）プロトコルを採用することで、エージェントは標準化されたメタデータを使用して互いを検出し、コンテキストを共有して、完全に異なるエンタープライズフレームワークを横断してバックグラウンド作業を安全に委任できるようになります。

ユーザーとエージェントの ID について詳しくは、質問 #14 をご覧ください。

#3 どのエージェント開発ツールを使用すべきか？利用できるフレームワークが非常に多いため、エンジニアリングチームは、断片化された自社開発のセットアップをデフォルトとして使用しがちです。これを簡素化するために、Google ではエージェント開発を 4段階のはしごとして定義しています。これにより、チームはすぐに使える標準構成から、コードファーストの高度な制御まで、ニーズに合わせて柔軟に行き来することが可能になります。

1 段目: Agent Studio（ローコード）: 迅速なプロトタイピングやビジネスチームに適した、Agent Platform 内のビジュアルワークスペース。Agent Studio でエージェントを構築するには、こちらをご覧ください。
2 段目: Managed Agents API（Agent-as-a-Service）: API を介してエージェントの動作を定義し、安全なサンドボックス内のインフラストラクチャの管理を Google に任せたい技術チーム向け。Managed Agents API を使用してカスタムエージェントを構築するには、こちらをご覧ください。
3 段目: Antigravity 2.0: 高度なコーディングタスクやエンジニアリングパイプラインに AI を活用するデベロッパー向けの専用ワークスペース。Antigravity を使用して構築するには、こちらをご覧ください。
4 段目: Agent Development Kit（ADK 2.0）: ソフトウェアエンジニアが高度にカスタマイズされたマルチエージェントネットワークをゼロから構築するための、エンジニアリングファーストかつコードファーストなフレームワーク。ADK を使用してサンプルエージェントを構築するには、こちらをご覧ください。

#4 エージェントは 1 つから始めるべきか、複数から始めるべきか。また、どのように専門化すればよいか？プロトタイピングの初期段階では、高度に専門化された単一のエージェントから始めるよう、常にチームに推奨してください。エージェントがすべてを処理しようとすると、精度が低下して、レイテンシが急増し、デバッグが非常に困難になる可能性があります。これを避けるには、的確な指示を記述し、アクセスできるツールを制限するようにしましょう。

ワークフローが複雑化した場合や、モデルのコンテキストの上限に達した場合は、エンジニアをマルチエージェントシステムに移行させましょう。マルチエージェントシステムは、本質的には、目標を達成するために連携する個々の自律型エージェントの集合体です。ADK のようなフレームワークを使用すると、エージェントをサブエージェントのネットワークに整理できます。このネットワークでは、コーディネーターが特定のタスクを専門の役割を持つメンバーに委任するため、明確な編成ロジックを維持することが可能です。

例: ADK を使用してサンプルマルチエージェントソリューションを構築するには、こちらをご覧ください。

スケーリングフェーズ - 接続性と相互運用性

#5 エンタープライズデータを接続し、適切なビジネスコンテキストを維持するにはどうすればよいか？エージェントが真に役立つためには、適切なデータにアクセスする必要があります。ここで「企業の実体」が登場します。これは、エージェントが成功するために必要な、エンタープライズ固有のデータ、ツール、制約、ポリシー、プロセスを指します。

これを実現する方法はいくつかありますが、新たな手法として普及しつつあるのは、Model Context Protocol（MCP）などのオープン標準を使用して、エージェントを稼働中のデータベースやビジネスアプリケーションに直接接続する方法です。しかし、接続を確立するだけでは十分ではありません。エージェントが正確に動作し、ハルシネーションを回避できるようにするには、また、明確なビジネスコンテキスト、メタデータ、ロジックを使用してこのデータを整理する必要があります。この構造化されたアプローチにより、エージェントは単に生の情報を取得するだけでなく、それを正しく解釈して、組織全体でより適切な意思決定を行えるようになります。

例: ADK と MCP ツールボックス（マネージドサーバー）を使用して、サンプルマルチエージェントソリューションを構築しましょう。

#6 完全に異なるフレームワークで構築されたエージェントを接続するにはどうすればよいか？大規模な組織では、各チームが特定のニーズに最適なツールを使用してエージェントを構築するのが自然です。LangGraph や自社開発のフレームワーク、あるいはまったく別のものなど、さまざまなツールが使われることになるでしょう。しかし、これらのシステムが連携できない場合、データとワークフローが孤立し、サイロ化を招いてしまいます。

共通の通信標準を確立することで、まったく異なるプラットフォームやフレームワークで開発されたエージェント同士が、特別な統合作業なしにインテント、状態、結果をやり取りできるようになります。

フレームワークをまたぐ接続（たとえば、LangGraph ベースの HR エージェントを ADK ベースの CRM エージェントに接続する場合など）には、A2A プロトコルを実装できます。これにより、複数の独立したエージェントを横断するマイクロサービススタイルの通信パターンが可能になり、エージェント同士が安全に相互通信できるようになります。

例: ADK と A2A を使用して、サンプルマルチエージェントソリューションを構築しましょう。

#7 エージェントが特定のツールを見つけられるようにするにはどうすればよいか？エージェントのコンテキストウィンドウに複数のツールや API を詰め込むと、パフォーマンスが低下して、レイテンシが増加し、トークン費用も上昇します。RAG を使用してオンデマンドでデータを動的に取得するのと同様に、エージェントのツールについても、同様の動的な取得戦略を適用する必要があります。

特定の機能に特化したエージェントスキルを活用することで、エージェントはタスクに必要な場合にのみ機能を読み込みます。エージェントは、汎用的な指示の膨大なライブラリを解析するのではなく、タスク固有の単一のインデックスカードから情報を取得するため、正確で厳密に制御された実行が可能になります。

例: ADK とスキルを使用してマルチエージェントオーケストレーションパターンを構築しましょう。

#8 エージェントを簡単にスケーリングできるようにデプロイするにはどうすればよいか？これは「100 万ドル級の難問」です。あるいはより正確に言えば、「1 分あたりのトークン数」の問題かもしれません。重要なのは、単に最も安価なオプションを選択することではなく、ワークロードのパターンに合ったツールとサービスの適切な組み合わせを見つけることです。

インフラストラクチャのオーバーヘッドを大幅に増やすことなくエージェントをスケーリングするには、フルマネージドのサーバーレス実行環境内にエージェントをデプロイすることをおすすめします。Agent Runtime は、デベロッパーが本番環境で AI エージェントをデプロイ、管理、スケーリングできるようにする一連のサービスです。本番環境でエージェントをスケールするためのインフラストラクチャの処理は Agent Runtime が担うため、デベロッパーはアプリケーションの作成に注力できます。

プロダクションレディなランタイムでは、使用量の急増に対処するための伸縮自在な自動スケーリング、カスタムソフトウェアの依存関係をバンドルするためのコンテナ化による柔軟性、そして低レイテンシのリアルタイムインタラクションを確保するための双方向ストリーミングのネイティブサポートを備えている必要があります。また、このアーキテクチャには、パブリックインターネットにさらすことなく社内のエンタープライズデータに安全に接続するための、組み込みのプライベートネットワーキングインターフェースも統合する必要があります。

例: Agent Runtime を使用してマルチエージェントオーケストレーションパターンを構築しましょう。

#9 長時間実行されるタスクで、エージェントがコンテキストを見失った場合はどうすればよいか？AI エージェントがより効果的に動作できるように、短期記憶と長期記憶の両方を持たせることができます。つまり、リアルタイムのセッション状態によって直近の会話を維持し、長期ストレージレイヤによってユーザーの好みや過去のやり取りを記憶するということです。これらすべてを、エージェントをチームの管理下に安全に置いたまま実現できます。

Agent Platform では、これを 2 つのレイヤで処理します。ADK では、sessionService が複数ステージのタスクにおける直近のステップを処理します。Agent Memory Bank が永続的な長期ストレージレイヤとして機能し、過去のユーザーの好みやプロジェクトの成果を長期にわたって呼び出す役割を担います。

例: Agent Memory Bank と ADK メモリを使用してマルチエージェントオーケストレーションパターンを構築しましょう。

最適化フェーズ — 信頼と効率

#10 スクリプトを実行したりブラウザを使用したりするエージェントの影響範囲を制限するにはどうすればよいか？エージェントが Python やスクリプトを実行したり、ウェブを閲覧してデータを収集したりする必要がある場合、それらを自社ネットワーク上で直接実行させるべきではありません。これらのタスクを一時的な隔離されたサンドボックス環境で実行することで、信頼できないコードやランタイムロジックのエラーを簡単に隔離し、コアエンタープライズシステムから完全に分離できます。

さらに、組み込みのサンドボックスを備えたエージェントランタイムを使用することで、主要なインフラストラクチャを保護しながら、チームの完全な制御下でエージェントにツール呼び出しを安全に実行させることができます。

例: Agent Sandbox を使用してマルチエージェントオーケストレーションパターンを構築しましょう。

#11 エージェントがブランドから逸脱しないようにするにはどうすればよいか？エージェントは企業のアイデンティティを体現する存在です。明確な制約を伴うシステムプロンプトを定義することは第一歩ではありますが、プロンプトだけに頼ることは、本番環境のセキュリティにおいて不十分（かつ危険）です。モデル本来の確率的な性質にかかわらず、エージェントが常に制限された状態を維持できるように、企業の中核的なルールとトーンの制約を強制する必須の安全レイヤが必要です。

ガードレールは、自律的な意思決定を行う柔軟性をエージェントに持たせつつ、コアの安全ルールへの違反を確実に防ぐことで、予測不可能な LLM を安全なエンタープライズシステムに変えます。これらの境界は、エージェントの推論の外部で決定論的な制約として実装されるため、回避することは不可能です。

この安全レイヤを補完する構造化ワークフローは、複雑なタスクを決定論的なステップバイステップのパイプラインに分割することで、予測可能性をさらに高めます。このパイプラインでは、コードレベルのルーティング、条件付きロジック、状態管理を使用して、エージェントを再現性のあるパスに沿って誘導します。

例: Guardrails エージェントを使用してマルチエージェントオーケストレーションパターンを構築しましょう。ADK ワークフローもご覧ください。

#12 結果をどのように信頼するか？信頼は、エージェントのライフサイクル全体にわたる厳格なテストと継続的な評価から得られたエビデンスによって築かれます。信頼は自動的に得られるものではなく、手法の結果として得られるものです。

大規模な環境では、指標、人間参加型の監視、LLM-as-a-Judge パターンを組み合わせて評価を自動化します。より高性能なモデルや、専門的な自己評価エージェントを使用して、エンドユーザーに届く前にプライマリエージェントの出力を監査することで、不正確さを体系的に検知し、ユーザーエクスペリエンスを保護できます。

例: LLM-as-a-Judge と自己評価エージェントを組み込んだマルチエージェントオーケストレーションパターンを構築しましょう。

#13 膨れ上がるコストをどのように管理すればよいか？高性能な推論は強力ですが、決して安くはありません。費用を最適化するには、階層化されたアプローチを試してください。高速で複雑性の低いタスクには高速で軽量なモデル（Gemini Flash など）を使用し、オープンソースモデル（Gemma など）を活用して、最も大規模で高価な推論モデルを最終的な意思決定のために残しておきます。

大規模な本番運用では、プロビジョンドスループット（PT）に切り替えましょう。例えるなら、安定した予測可能な日常のトラフィック専用に容量を予約しておき、予期しない急増が発生した場合には、標準の従量課金制へ自動的に切り替わるような仕組みです。

算をさらに保護するには、高精度な RAG でコンテキストウィンドウをトリミングする、コンテキストキャッシュを利用する、エージェントのイテレーションにハードストップを設定する、予測可能なワークフローを決定論的なコードに移行するといった手法を検討しましょう。

例: 費用管理と重要な KPI を考慮して構築しましょう。

ガバナンスフェーズ - セキュリティと監視

#14 エージェントのデータアクセスを人間のユーザーのデータアクセスと一致させるにはどうすればよいか？エージェントのデータアクセスの一致は、まず安全なエージェント ID を確立することから始まります。このエージェント ID は、ユーザーの ID で直接動作するモデル、エージェント独自の独立した ID を使用するモデル、委任された権限を介して動作するモデルの 3 つをサポートしています。

従業員向けの多くのワークフローでは、委任された権限 を活用することが最も安全なアプローチです。エージェントは、やり取りする従業員の既存の権限を自動的に継承し、それを遵守します。これにより、エージェントが明示的に許可されていないデータにアクセスできないことが保証されます。その結果、クリーンな監査証跡を維持しながら、複雑な権限構造をゼロから再構築する必要がなくなります。

例: エージェント ID を使用して構築しましょう。

#15 シャドー AI とエージェントの無秩序な増加を管理するにはどうすればよいか？監視されていないエージェントは、深刻なデータの断片化とコンプライアンスリスクを引き起こします。無秩序な増加を防止するには、中央のエージェントレジストリを使用できます。これは、すべてのアクティブなエージェント、そのビジネスオーナー、ターゲットデータセット、および許可されたツールを自動的に一覧化する、一元化された検索可能なディレクトリです。手動で追跡するスプレッドシートから移行することで、チームは社内の AI プロジェクトを可視化できるようになります。これにより、重複したエージェントの統合や、孤立したエンドポイントの安全な廃止を確実に行えるようになります。

例: エージェントレジストリを使用して構築しましょう。

#16 ユーザー、エージェント、データ、ツールがどのようにやり取りできるかを定義するにはどうすればよいか？エンタープライズオートメーションを安全にスケーリングするには、2 層構造のポリシーアーキテクチャが必要です。まず、IAM ポリシーを適用して明確な境界を定義し、エージェントが認可されたツールと特定のデータバケットにのみアクセスできるようにします。2 つ目は、ユーザープロンプトの自然言語による意図をリアルタイムで分析するセマンティックポリシーを実装することです。これにより、エージェントが生成しようとしている回答が、実行前に主要なビジネスルールやコンプライアンス要件に準拠していることを検証できます。

例: ポリシーを使用して構築しましょう。

#17 これらのポリシーを適用し、エージェントの活動を可視化するにはどうすればよいか？ポリシーは、ランタイムでの適用と明確な監査証跡がなければ意味をなしません。これを実現するには、すべてのエージェントトラフィックを Agent Gateway 経由でルーティングする必要があります。Agent Gateway は、すべてのエージェントインタラクションにおけるネットワークの出入り口となります。このゲートウェイは、ユーザー、エージェント、ツール間の呼び出しを自動的にインターセプトし、ポリシー違反の即座なブロック、コンテンツのサニタイズ、プロンプトインジェクションの防止を自動で行います。完全な可視性を実現するには、このゲートウェイがあらゆるインタラクションに対してネットワークレイヤのテレメトリーを生成し、リアルタイムの挙動メトリクスと実行トレースをオブザーバビリティダッシュボードに直接フィードする必要があります。

例: Agent Gateway を使用して構築しましょう。

#18 プロンプトとレスポンスをデータ漏洩、プロンプトインジェクション、不適切なコンテンツから保護するにはどうすればよいか？Model Armor は、Agent Platform と統合することで、プロンプトが Gemini モデルに到達する前、およびレスポンスがアプリケーションに届く前に、それぞれの通信をインターセプトします。

構成に基づいて、Agent Platform は Model Armor サービスを呼び出します。このサービスは、定義されたポリシーに違反するトラフィックを検査またはブロックし、プロンプトインジェクションやジェイルブレイクの検出、責任ある AI フィルタ、機密データの保護などのセキュリティ対策を適用します。この統合を構成するには、プロジェクトレベルの保護にフロア設定を使用するか、リクエストごとの保護にテンプレートを使用します。

例: Model Armor を使用して構築しましょう。

#19 エージェントに問題が発生したかどうかは、どのようにしてわかるか？システムを保護するには、エージェントの意思決定ループをリアルタイムで監査して、振る舞い異常を検知する必要があります。脅威検出と並行してこの継続的な振る舞い監査を実行することで、侵害されたエージェントがリスクの高い、普段とは異なるアクションを試みた際に、即座にそれを検知できます。

そこで役立つのが、Agent Platform の脅威検出（Security Command Center の一部）です。エージェントが不正なデータベースコマンドを試行したり、未検証の外部ネットワークアドレスに接続したりすると、システムはほぼリアルタイムでイベントにフラグを立てて迅速に隔離します。これにより、自動化されたワークフォースを安全に管理できます。

例: 脅威検出と Agent Anomaly Detection を使用して構築しましょう。

#20 エージェントのライフサイクル全体を 1 か所で管理するにはどうすればよいか？更新を push したりテストを実行したりするためだけに、5 つもの異なるクラウドコンソールをクリックして移動したくはないでしょう。Agent Platform を使用すれば、プロダクションレディなエージェントを構築、スケーリング、ガバナンス、最適化するために必要な特定のスキルやコマンドを、コーディングエージェントに簡単に付与することができます。

開発チームの主要なコマンドツールとして、Agent Platform の Agents CLI を使用することをおすすめします。ローカルターミナルでの作業と本番環境の管理を直接つなぐブリッジとして機能するため、デベロッパーはテストから本番リリースへの移行を大幅に効率化できます。

また、チームはエージェント構成のバージョン管理、自動評価の実行、既存の CI / CD パイプラインを介したシームレスな更新の push も可能になります。基盤となるツールとスキルは Google のエキスパートが構築し、厳格なテストを行っているため、チームは車輪の再発明や日々のコーディングワークフローの中断を心配することなく、自信を持ってデプロイできます。

例: Agents CLI を使用して構築するには、こちらをご覧ください。

今すぐ始めましょう

これらの 20 の質問に早めに取り組むことで、セキュリティチームや運用チームの安眠を妨げることなく、ビジネスの実務に真に貢献するエージェントを構築できます。

Gemini Enterprise Agent Platform をこちらからお試しください。

-Gemini Enterprise Agent Platform プロダクトマネージャー、Kanchana Patlolla

-Gemini Enterprise Agent Platform プロダクトマネージャー、Greg Brosman

Gemini Enterprise と Google Cloud Marketplace でエージェントを公開するためのデベロッパーガイド

Fri, 17 Jul 2026 01:00:00 +0000

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

Software-as-a-Service（SaaS）は Agents-as-a-Service（AaaS）へと進化しています。

開発者は、複数の分離したアプリケーションではなく、相互運用する AI エージェントを作成するようになってきています。相互運用のためには、Agent2Agent（A2A）プロトコルなどの標準化されたオープンプロトコルを使用し、Gemini Enterprise Agent Platform などの一元的なエージェントプラットフォームを使ってオーケストレーションします。

どのようなユースケースであっても、高品質なエージェントの開発を常に目標とすべきであると Google は考えています。つまり、自律性を前提に、複数ステップの複雑なワークフローを確実に実行できるようなエージェントを開発し、明確なビジネス価値を提供する必要があります。このガイドでは、エージェントの構築 / 開発担当者向けに、Google Cloud Marketplace で有望なサードパーティエージェントを公開、販売する方法、ならびに、Gemini Enterprise app にデプロイする方法を紹介します。この詳細ステップに従うことで、Marketplace ですぐに公開できるような完全統合されたソリューションを実現できます。

ステップ 1: Marketplace との統合を想定して、エージェントアーキテクチャを設計する

最終的なアーキテクチャは、Google Cloud Marketplace の課金の仕組み、ID プロバイダ（IdP）のセキュリティ機能、そして、Gemini Enterprise Agent Platform を連係したものとなります。

このアーキテクチャの要素は、大まかにいって次のとおりです。

カスタマープロジェクト: ユーザーは、Google Cloud Marketplace 内の Agent Marketplace 専用カテゴリでエージェントを見つけます。また、Gemini Enterprise app を通じてこれらのエージェントとやり取りします。
パートナープロジェクト: エージェントに加え、調達ロジックを処理する Marketplace ハンドラ、認証のための動的クライアント登録（DCR）をホストします。
パートナー向け Marketplace プロジェクト: Marketplace のイベント（アカウントの作成や利用資格の承認など）に対応する Partner Procurement API と Pub/Sub トピックを管理します。

ステップ 2: Marketplace で販売するための組織の要件を確認する

Google Cloud パートナーネットワークに参加する。Marketplace でのソリューション提供が初めての場合は、Google Cloud パートナーネットワークに参加する必要があります。
Agent-as-a-Service のリスティング要件を確認する。Marketplace にソリューションを掲載するための要件を組織が満たしていることを確認します。
Marketplace ベンダー契約を確認する。Marketplace ベンダー契約（MVA）を確認して同意します。
Google Cloud Marketplace へのエージェント登録を申請する。Google Cloud の担当者にお問い合わせください。

Marketplace に掲載されるすべてのエージェントは、上記の標準要件を満たすものとします。また、エージェントに関して、以下の要件を満たす必要があります。

エージェントのユースケースの定義: 具体的なエージェントユースケースを定義することをおすすめします。現場の課題解決につながり、複数のエンタープライズカスタマーにスケールできるような、価値の高いエンタープライズ機能に焦点をあてるようにしましょう。
A2A プロトコルへの準拠: エージェントを相互運用するためには、A2A プロトコルの仕様に準拠する必要があります。このプロトコルには、リッチでインタラクティブなユーザーインターフェースを生成するための A2UI プロトコルが含まれます。
A2A エージェントカード: エージェントカード（JSON ファイル）を生成し、機能（スキル）、認証方法、サービスエンドポイントを宣言します。
認証: 一般公開アクセスまたは OAuth 2.0 認証コード付与フローをサポートする必要があります。
Marketplace との統合: 利用資格のライフサイクルを管理するために、Procurement API および Pub/Sub の統合が必須となります。

ステップ 3: Marketplace および Gemini Enterprise app との互換性のための技術要件を確認する

A2A プロトコル

エージェントを設計、実装する際は、A2A プロトコルのドキュメントに従ってください。このドキュメントには、エージェントが提供できるインタラクションパターンの種類（ストリーミングや非同期タスクなど）のほか、A2UI プロトコルによるインタラクティブな UI エクスペリエンスの組み込み方が記されています。A2UI を使えば、最先端かつ最高水準の UX コントロール（高度な動的グラフや最新のインタラクションモデルなど）を組み込めます。これらのネイティブのユーザーコントロールを活用することで、エージェントが確実に機能するようになるだけでなく、Gemini Enterprise app 内で、開発者のこだわりと特別感を打ち出した外観、印象、操作性を実現できます。

A2A エージェントカード

Marketplace に Agent-as-a-Service プロダクトを掲載するには、A2A エージェントカードを用意する必要があります。エージェントカードとは、エージェントの機能（スキル）、サポート対象の認証 / 認可方法、サービスエンドポイントを宣言した JSON ファイルです。

Gemini Enterprise app は、エージェントカードに従って以下を実行します。

エージェントの名前、説明、その他の必須のメタデータを表示する。
動的クライアント登録のエンドポイントを見つける（サポートされている場合）。
エージェントのエントリポイントを見つける（メッセージの送信や、タスク実行に関する最新ステータス取得のためのエントリポイント）。
必須の認証 / 認可方法を判断する。

以下に、定義済みのエージェントカードの例を示します。

code_block: <ListValue: [StructValue([('code', '{\r\n "name": "AI Agent Example",\r\n "protocolVersion": "1.0",\r\n "description": "Marketplace agent example.",\r\n "url": $AGENT_APP_URL,\r\n "preferredTransport": "JSONRPC",\r\n "provider": {\r\n "organization": $AGENT_PROVIDER_ORGANIZATION,\r\n "url": $AGENT_PROVIDER_URL\r\n },\r\n "version": "1.0.0",\r\n "capabilities": {\r\n "streaming": false,\r\n "pushNotifications": false,\r\n "extensions": [\r\n {\r\n "uri": "https://cloud.google.com/marketplace/docs/partners/ai-agents/setup-dcr",\r\n "params": {\r\n "target_url": $AGENT_DCR_URL\r\n }\r\n }\r\n ]\r\n },\r\n "defaultInputModes": [\r\n "application/json"\r\n ],\r\n "defaultOutputModes": [\r\n "application/json"\r\n ],\r\n "skills": [\r\n {\r\n "id": "current_time_generation",\r\n "name": "Current time generation",\r\n "description": "Generates a current time.",\r\n "tags": [\r\n "time"\r\n ],\r\n "examples": [\r\n "What time is it?"\r\n ]\r\n }\r\n ],\r\n "supportsAuthenticatedExtendedCard": false,\r\n "iconUrl": $AGENT_ICON_URL,\r\n "security": [\r\n {\r\n "oauth2": [\r\n $AUTH_SCOPE\r\n ]\r\n }\r\n ],\r\n "securitySchemes": {\r\n "oauth2": {\r\n "type": "oauth2",\r\n "flows": {\r\n "authorizationCode": {\r\n "authorizationUrl": $AUTHZ_URL,\r\n "tokenUrl": $TOKEN_URL,\r\n "refreshUrl": $REFRESH_URL,\r\n "scopes": {\r\n $AUTH_SCOPE: $AUTH_SCOPE_DESCRIPTION \r\n }\r\n }\r\n }\r\n }\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa434f69fd0>)])]>

$AGENT_APP_URL: A2A エージェントにアクセスするためのベース URL エンドポイント（必須項目）。エージェントに対するすべての API 呼び出しで、これがベースパスとして使用されます。
$AGENT_PROVIDER_ORGANIZATION: エージェントプロバイダの組織（必須項目）。
$AGENT_PROVIDER_URL: エージェントプロバイダのウェブサイトまたは関連ドキュメント（必須項目）。
$AGENT_DCR_URL: 動的クライアント登録（DCR）を実装する場合に必須の項目。
$AGENT_ICON_URL: エージェントのアイコンとして使用する画像ファイルの URL を指定する（省略可）。指定した場合、Gemini Enterprise app に表示されます。
$AUTH_SCOPE: クライアントがエージェントのオペレーションにアクセスするために必要なスコープ名の文字列のリスト。
$AUTH_SCOPE_DESCRIPTION: スコープの説明。例: 「ユーザーのメールアドレスを取得する権限」
$AUTHZ_URL: 認証コードフローの OAuth2 セキュリティスキーム定義に必須の要素。リソース所有者からの認可コードを取得する際に必要な、認可サーバーのエンドポイント URL を指定します。これは OpenAPI の仕様に準拠しています。
$TOKEN_URL、$REFRESH_URL: クライアントが認証コードをアクセストークンと更新トークンに交換するための URL（同じでも可）。

認証と認可

A2A プロトコルに従って、エージェントに認証と認可を実装します。Gemini Enterprise app からのエージェント呼び出しを許可するにあたり、以下のいずれかの方法を設定する必要があります。

一般公開: 認証は不要です。ユーザーデータや機密リソースにアクセスしないエージェントにのみ適しています。
OAuth 2.0 認証コード付与フロー: これは、ユーザーが権限を委任（認可）する場合の標準フローです。ユーザーは、エージェントがデータにアクセスしたり、ユーザーの代わりに操作したりすることを許可するよう求められます。

動的クライアント登録（DCR）

従来、サードパーティアプリをエンタープライズシステムに接続するには、クライアント ID とシークレットを手動でコピーする必要がありました。DCR では、Gemini Enterprise がエージェントの認可サーバーに OAuth クライアントとして自動登録されるため、この問題が解消されます。

DCR フローの仕組み:

検出: Gemini Enterprise app がエージェントカードを読み取り、DCR エンドポイントを見つけます。
リクエスト: Google が HTTP POST をエンドポイントに送信します。これには、software_statement（暗号技術を使って署名された JSON ウェブトークン（JWT））が含まれます。
検証: パートナー側のバックエンドで Google の公開鍵を使って JWT 署名を検証し、リクエストが本物であることを確認します。
プロビジョニング: 上記の処理が完了すると、パートナーのサーバーが、ID プロバイダ（Okta など）内に新しい OpenID Connect（OIDC）アプリケーションを作成し、client_id と client_secret を Gemini Enterprise に返します。

code_block: <ListValue: [StructValue([('code', 'DCR Request\r\n{\r\n "software_statement": "eyJhbGciOiJSUzI1NiIsImtpZCI6ImY1OTIwZDJmMjIyYjNjMTE3Y2MyZmQzZmQxYWJjNzM..."\r\n}\r\n\r\nJWT Decoded\r\nHere is the decoded value of software_statement parameter:\r\n\r\nHeader:\r\n{\r\n "alg": "RS256",\r\n "kid": "f5920d2f222b3c117cc2fd3fd1abc7367fd00402",\r\n "typ": "JWT"\r\n}\r\nPayload:\r\n{\r\n "aud": "https://your-provider.com",\r\n "auth_app_redirect_uris": [\r\n "https://vertexaisearch.cloud.google.com/oauth-redirect"\r\n ],\r\n "exp": 1766773074,\r\n "google": {\r\n "order": "xxxxxxxx-c3bc3976a8e0"\r\n },\r\n "iat": 1766772774,\r\n "iss": "https://www.googleapis.com/service_accounts/v1/metadata/x509/cloud-agentspace@system.gserviceaccount.com",\r\n "sub": "xxxxxxxx-xxxx-xxxx-xxxx-4656e5b81fe8"\r\n}\r\nDCR Response\r\n{\r\n "client_id": $CLIENT_ID,\r\n "client_secret": $CLIENT_SECRET,\r\n "client_secret_expires_at": 0\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa434f692e0>)])]>

注: JWT を検証することで、リクエストが Google からのものであることを確認できます。なお、ユーザーが支払い済みであるかどうか確認するために、google.order ID とパートナー側のデータベースを照合する必要があります。

ステップ 4: Marketplace でエージェントを掲載、公開する

エージェントを構築したら、Google Cloud Marketplace で公開しましょう。そのために、エージェントの説明を記述し、提供方法と料金モデルを定義する必要があります。まず最初に、Google Cloud コンソールから Producer Portal にアクセスします。

ソリューションタイプの選択: Producer Portal で、プロダクトタイプとして [AI Agent as a Service] を選択します。
エージェントカードのアップロード: Google Cloud Storage（GCS）バケットを介して、エージェントカードの JSON ファイルを送信します。
提供方法: AI エージェントを、一般公開の料金で販売するか（セルフサービス）、プライベートオファーでのみ提供するかを決定します。
料金: 料金プランを決めて、Marketplace で収益化するための料金モデルを選択します。
技術的な統合: バックエンド側で調達を構成します。このソリューションタイプでは、フロントエンドの統合は不要です。
検証およびエンドツーエンドテスト: Google Cloud が、エージェントの機能、セキュリティ、料金モデルを確認したうえで、カタログに公開します。
公開: エージェントが正常に公開され、Google Cloud Marketplace に掲載されます。

ステップ 5: Marketplace と Gemini Enterprise app におけるトランザクション / 登録の管理

Google Cloud Marketplace と Gemini Enterprise app におけるエージェントの調達と登録のライフサイクルは、明確なフェーズに分かれています。このようなフェーズ分けは、厳格なエンタープライズガバナンスの確立、シャドー IT の防止、組織全体におけるシームレスなコンプライアンスの確保のために欠かせません。安全な管理の連鎖には、次の 3 つの主要なペルソナが介在します。課金管理者は、Google Cloud Marketplace での調達と支出を管理し、財務を監督します。Discovery Engine 管理者は、検証済みのエージェントを安全に登録するとともに、Gemini Enterprise における組織内でのアクセス権を決めるなど、技術的な「門番」の役割を果たします。Discovery Engine ユーザーは、ID に基づいて適切に認可を受けたうえで、Gemini Enterprise app 内でエージェントの全機能を安全に活用します。

1. 調達フロー: 非同期（Google Cloud Marketplace）

リスティングの公開を受け、バックエンドの調達シーケンスが次の流れで行われるようになります。

トリガー: 課金管理者の権限を持つ購入者が、 [登録] をクリックします（セルフサービス型のリスティングの場合）。または、プライベートオファーを承諾します（個別のプライベートオファーのみの場合）。
通知: Google が Pub/Sub 通知をパートナーの環境に送信します。
承認と保存: パートナーが統合した Marketplace ハンドラが、Partner Procurement API を介してアカウントと利用資格を承認します。
アクティベーション: ハンドラが、Firestore などのデータベースに一意の注文 ID を保存し、トランザクションを記録します。これにより、購入者のサブスクリプションやオファーが即座に有効になります。

上の例では、課金管理者はワンクリックで登録を済ませて、Lovable Agent の無料プランを有効にしています。これで、Cloud Marketplace からすでに調達、有効化済みの SaaS サブスクリプションと併せて、このエージェントを利用できるようになります。

2. 登録フロー: 同期（Gemini Enterprise）

調達が完了したら、購入者側の管理者が、実際の Gemini Enterprise app 環境にリンクします。

Gemini Enterprise へのリダイレクト: Discovery Engine 管理者に対して、Marketplace の調達済みリスティング上に [Gemini Enterprise に移動] オプションが表示されます。
プロジェクトの確認: このオプションをクリックすると、Gemini Enterprise ライセンスが割り当てられている Google Cloud プロジェクトにログインする画面が表示されます。なお、この Google Cloud プロジェクトが、調達時に使用した請求先アカウントにアクティブにリンクされていることを、購入者側で確認する必要があります。
DCR ハンドシェイク: Discovery Engine 管理者が、Gemini Enterprise app 内でエージェントを構成します。この段階で、動的クライアント登録（DCR）ロジックが、送られてきた JWT の注文 ID を Firestore レコードと照合、検証します。ID が一致すると、登録が安全に完了します。
エージェントの登録完了: エージェントが Gemini Enterprise に正常に登録されます。これで、Discovery Engine 管理者は、エージェントへのアクセスを特定のユーザーに与えられるようになります。

調達後、Discovery Engine 管理者が Lovable Agent を Gemini Enterprise app に登録し、組織内の承認済みユーザーが利用できるようにしています。

3. エンドユーザーの有効化フロー（Gemini Enterprise）

エージェントの登録が安全に完了すると、対象のエンタープライズユーザーがそのエージェントを見つけられるようになります。

Gemini Enterprise app 内でのエージェントの閲覧とリクエスト: エンドユーザーは、Gemini Enterprise app の Agent Gallery から、Cloud Marketplace で提供されているパートナーが構築したエージェントを閲覧し、直接アクセスをリクエストできます。このリクエストを受け、Discovery Engine 管理者が確認し、課金管理者と直接連携して、Google Cloud Marketplace からエージェントを調達できます。すでに調達、登録済みの場合は、エンドユーザーにアクセス権を付与できます。
アクセス: エージェントへのアクセス権が付与されると、アクティブな Gemini Enterprise app アカウントおよび Discovery Engine ユーザーロールおよびライセンスを持つ任意のエンドユーザーが Gemini Enterprise app 内でエージェントを呼び出せるようになります。
認証: 初回利用時に、ユーザーはパートナーシステムのユーザー名とパスワードを入力して OAuth 認証を完了するよう求められます。認証が完了すると、Gemini Enterprise app のチャットインターフェースからエージェントの全機能をシームレスに利用できるようになります。

エンドユーザーは Gemini Enterprise app 内から Lovable Agent をシームレスに呼び出し、パートナーからの 1 回限りの認証プロンプトを完了したうえで、リアルタイムの会話でタスクワークフローを始められます。

エンドユーザーが、Gemini Enterprise app の Agent Gallery から、Marketplace で公開されている別のエージェント Atlassian Rovo へのアクセスを直接リクエストしています。この例では、Marketplace からこのエージェントをすでに調達済みであるため、Discovery Engine 管理者は検証、統合を行って、アクセス権をただちに付与できます。

実際にやってみる

Gemini Enterprise および Google Cloud Marketplace 向けの AI Agent-as-a-Service ソリューションを構築することで、リーチを拡大し、数百万単位のエンタープライズユーザーの日常的なワークフローにエージェントを組み込んでもらえる可能性が広がります。

Agent Development Kit（ADK）などのツールを使用して今すぐ構築を開始してみましょう。また、エージェント主導のエンタープライズ時代に Google Cloud Marketplace で成長を加速する方法についてさらに詳しく学ぶことをおすすめします。

サポートが必要な場合は、Google Cloud Marketplace サポートチームまでお問い合わせください。

- Google Cloud、スタッフソリューションコンサルタント、Sunny Walia

- Lovable、フォワードデプロイドエンジニア、Victor Dantas

レポート: 83%の組織がエージェント型 AI に対応するためにインフラストラクチャのアップグレードを必要としている

Wed, 15 Jul 2026 02:00:00 +0000

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

長年にわたり、企業向け AI といえば、日常的に利用するカスタマーサービス bot やデジタルアシスタントなどの会話型 AI を指していました。しかし今、市場は大きく変化しています。私たちは、簡単なチャットに回答する AI から、自ら行動し、ワークフローを自動化し、複雑なタスクを実行する AI へと本格的に移行しました。これにより、まったく新しいユースケースが生まれる一方で、課題もあります。これまで利用してきた基盤インフラストラクチャに、大きな負荷がかかるためです。

Google は先ごろ、「AI インフラストラクチャの現状」レポートの作成にあたり、1,400 人を超える IT 部門の上級リーダーを対象に調査を実施しました。その結果、AI に対する構想とインフラストラクチャの実態との隔たりが広がっているという明確な傾向が浮かび上がりました。実際、83% の組織が、本番運用に対応できるエージェント型 AI を支えるには、インフラストラクチャのアップグレードが必要だと回答しています。

その理由は、従来のインフラストラクチャが、自律的に行動するエージェントを想定して構築されていないためです。

このブログ投稿では、変化に強く柔軟な基盤を構築するために、先進的な組織がインフラストラクチャをどのように見直しているのかについて、調査から得られた主な知見を紹介します。さらに詳しい内容については、レポート全文をダウンロードしてご覧ください。

フルイドコンピューティングで「推論税」から脱却する

エージェント型 AI のワークロードでは、従来とは異なる規模への対応が求められます。1 つのプロンプトから数百もの後続処理が実行され、膨大なコンテキストをメモリ上に保持しなければならない場合があるためです。このような継続的な推論ループを従来のアーキテクチャ上で実行しようとすると、コスト面で持続不可能になります。実際、リーダーの 62% が、データの外向き転送料金、ストレージ使用量の肥大化、稼働していない専用ハードウェアによって生じる多額の「推論税」に直面しています。さらに、81% が、運用の複雑さを AI の大規模展開に伴う隠れたコストとして挙げています。

この問題を解決するには、フルイドコンピューティングが必要です。これは、運用上のオーバーヘッドを最小限に抑えながら、タスクに応じて最適なシリコンを動的に割り当てる能力を指します。

大規模なモデル学習: 新しい TPU 8t などのコンピューティングアクセラレータは、世界で最も高度なモデルの学習に必要な圧倒的なスケーラビリティを提供します。
低レイテンシの推論: 一方、TPU 8i はオンチップメモリ容量を最大化するよう専用設計されており、エージェントをリアルタイムで推論し、応答できるようにします。
オーケストレーション: CPU を基盤とする汎用コンピューティングは、AI コントロールプレーンの運用を支える重要な要素として存在感を高めています。Google Axion のような高効率の Arm ベースプロセッサを使用することで、組織は強化学習シミュレーションを費用対効果の高い方法で実行し、エージェントをオーケストレートできます。

一元化されたガバナンスでエージェントの乱立を管理する

エージェントは、メールの閲覧、データベースへの問い合わせ、組織全体にわたるワークフローの実行などを自律的に行うよう設計されています。しかし、エージェント型 AI の導入が拡大するにつれ、組織は「エージェントの乱立」という新たな課題に直面しています。可視性や制御を失うことなく、多様なプラットフォームに分散する数千もの自律型エージェントをどのように管理すればよいのでしょうか。

テクノロジーリーダーの 79% が、推論を大規模に展開するうえで最大の課題として、セキュリティ、ガバナンス、MLOps を挙げているのも不思議ではありません。エージェントの時代にイノベーションを進めるには、まず成熟したガバナンス戦略を整える必要があります。そのためには、エージェントの権限、ID、ワークフローに関する信頼できる一元的な記録基盤となる、中央管理型のコントロールプレーンを構築することが求められます

先進的な企業は、互いに異なるツールをつなぎ合わせて使用するのではなく、Agent Gateway のようなソリューションを活用して、エンタープライズグレードのガバナンスを適用しています。Agent Gateway を使用すると、エージェントがデータをどのように共有しているかを正確に把握できます。また、読み取り / 書き込み権限の範囲を細かく定義し、すべてのやり取りについて完全な監査証跡を保持できます。さらに、重要な操作を実行する前に承認が必要な場合には、人間参加型の監視も提供します。こうした統一的でわかりやすいガバナンスへの需要を背景に、現在では 78% の組織が生成 AI ソリューションを主要クラウドパートナーから直接調達しています。これは 2025 年と比べて 30 ポイントの増加です。

統合データレイヤ

エージェントは推論を行うため、組織内のさまざまなデータに対して継続的に負荷の高いクエリを実行します。データがサイロ化され、分断されていれば、AI は実質的に何も見えない状態で動作することになります。

先進的な組織は、分断されたデータを個別に管理する状態から脱却し、自社固有の実用的なビジネスコンテキストを引き出すために、統合データレイヤを採用しています。非構造化データに自動でアノテーションを付けて検索可能にする Smart Storage や、Cross-Cloud Lakehouse などのツールを活用することで、エージェントは、データの保存場所を問わず、その内容を直接読み取って理解できます。カスタムパイプラインを構築したり、データを複製したりする必要もありません。

ハイブリッドマルチクラウドとデジタル主権

パブリッククラウドとローカルコンピューティングのどちらを選ぶべきかという議論は、すでに決着しています。目指すべき形はハイブリッドです。実際、現在では 52% の組織がハイブリッドマルチクラウドアーキテクチャを採用しています。

テクノロジーリーダーがこの方向へ移行する主な要因は、デジタル主権とデータグラビティです。実際、リーダーの 48% が、厳格なデータ所在地管理に対応できるインフラストラクチャを優先しています。各国または各地域の法令が変化しても、要件を満たす場所で AI を実行できる柔軟性が必要です。幅広いコンピューティング需要にはパブリッククラウドを活用し、エアギャップ環境が必要な場合には Google Distributed Cloud を通じて基盤モデルを完全にオンプレミスに導入するなど、最新のインフラストラクチャは地政学的な現実に合わせて適応しなければなりません。その逆ではありません。

エッジ AI

テクノロジーリーダーやインフラストラクチャアーキテクトにとって、エージェントによるすべてのやり取りを一元化されたクラウド環境だけで処理することは、現実的な戦略ではありません。現在、組織の 90% が AI の取り組みにおいてエッジへのデプロイを重要と位置付けており、そのうち 72% は「非常に重要」または「きわめて重要」と回答しています。

AI をエッジに移行することで、次の 3 つの課題に対処できます。

レイテンシのボトルネック: リアルタイムで動作するエージェント、特に音声、動画、金融取引アルゴリズムを利用するエージェントでは、遠隔地のデータセンターとの往復で生じるわずかな遅延も許容できません。
運用継続性: インターネット接続が途切れても、業務を停止することはできません。エッジにデプロイすることで、製造工場、小売店舗、病院などで稼働するエージェントは、接続が失われた場合でも自律的に動作し続けることができます。
費用対効果の維持: クラウド上で常時、継続的な推論を実行すると、多額のコストがかかります。スマートフォン、IoT デバイス、倉庫内のローカルサーバーなどのエッジデバイスで高度に最適化されたモデルを利用することで、コンピューティング負荷をローカル側に移し、トークン単位で発生する変動コストを大幅に削減できます。

エネルギーの壁を打破する

かつて、エネルギー消費量は年次報告書で扱われるサステナビリティ指標にすぎませんでした。しかし現在では、事業運営を左右する重要な要素となっています。今やリーダーの 91% がハードウェアの選定時に消費電力を考慮しており、61% がこれを主要または重要な判断要因と位置付けています。

テクノロジーリーダーにとって、消費電力は成長を阻む次の 3 つの障壁となっています。

電力網の供給制約: 地域によっては、追加の電力を確保すること自体ができません。そのため、導入可能なコンピューティングインフラストラクチャの規模が大幅に制限されます。
規制遵守: エネルギー効率は今や、事業を運営するうえで満たすべき厳格な法的要件となっています。たとえばドイツでは、新設するデータセンターの電力使用効率（PUE）を 1.2 以下にすることが求められています。またアイルランドでは、大規模データセンターに対し、電力網からの使用量の 100% に相当するオンサイトの出力調整可能な発電能力を確保することが義務付けられています。
インフラストラクチャの経済性: 電力効率の低い構成は、AI 導入の総所有コスト（TCO）を大幅に押し上げます。消費電力の大きいハードウェアを運用するには、高度な冷却アーキテクチャ、専用のラック設計、施設の改修に多額の設備投資（CapEx）が必要となります。

エネルギーの壁を乗り越えるには、テクノロジーリーダーがエネルギーを戦略的資産として捉える必要があります。最適化の重点を、ワットあたりのパフォーマンスへと移すことも重要です。こうした背景から、共同設計されたシリコンの重要性が高まっています。たとえば、新しい TPU 8t は、前世代の約 3 倍のパフォーマンスを実現すると同時に、エネルギー効率を最大 2 倍に高めています。

AI に最適化された統合インフラストラクチャ

従来のアーキテクチャでは、次世代のエージェント型システムがもたらす課題に対応できません。エンジニアリングチームが、異種のコンピューティング、ストレージ、ネットワークの各レイヤを手作業で統合しなければならない場合、基本的な相互運用性を確保するだけでも、組織には大きな運用負荷がかかります。

そこでテクノロジーリーダーは、迅速かつ費用対効果の高いイノベーションを実現するために、包括的に統合されたシステムへと移行しています。

Google Cloud の AI Hypercomputer は、こうした考え方に基づいています。すべてのレイヤが連携して機能するよう、共同で設計および開発されたアーキテクチャです。カスタムシリコン（TPU、GPU、CPU）を単独で設計するのではなく、超広帯域ネットワーク（Virgo Network）、ストレージ（Managed Lustre、Hyperdisk）、ソフトウェアオーケストレーションレイヤ（GKE）と一体的に設計しています。

デジタル世界と現実世界をつなぐ

このような共同設計による包括的なアプローチを採用することで、その効果はさらに広がります。スケーラビリティと柔軟性に優れたインテリジェンスをエッジで利用できるようになり、私たちはフィジカル AI の時代を迎えつつあります。新世代の自律型ロボットは、現実世界を認識し、シミュレーションしながら移動できます。また、実環境に投入される前に、Google Cloud 上のデジタルツインシミュレーションでタスクを数百万回も反復できます。複雑な産業検査から映画品質の映像撮影まで、AI は現実世界の具体的な課題を解決し始めています。

エージェント型 AI のための設計指針

エージェント型アプリケーションがシステムに求める要件に合わせてインフラストラクチャを整備することで、試験導入から本番運用への移行を進めやすくなります。2026 年に成長が期待される組織は、コスト効率に優れ、エッジでも高い復元性を発揮し、自律的な動作に最適化され、ガバナンスが標準で組み込まれた統合基盤を採用しています。

準備はできましたか。「AI インフラストラクチャの現状」レポートをダウンロードして、今回の調査結果を裏付けるデータをご確認ください。また、他の組織が成功に向けてどのような基盤づくりを進めているのかもご覧いただけます。

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

Google Cloud 認定資格を最新の状態に保ち、キャリアアップを図る新しい方法

Wed, 15 Jul 2026 02:00:00 +0000

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

これをお読みになっている方は、Google Cloud 認定資格を取得して、ご自身の能力を証明する努力をすでにされていることでしょう。調査によると、これが成功への近道です。認定資格を取得した方々からは、採用担当者からの連絡が増え、昇進が早まり、給与が上がったとの報告を受けています。実際、81% の組織が、Google Cloud の認定資格によって、候補者の知識や能力に対する信頼が高まると回答しています。

しかし、クラウドテクノロジーの進化のペースが速い今日では、一度認定を取得しただけでは十分ではありません。Harvard Business Review の調査によると、スキルの平均的な半減期は以前は約 6 年でしたが、現在は約 2.5 年です。

そのため、再認定がこれまで以上に重要になっています。

また、新しい技術的アプローチのおかげで、これらの認定資格をこれまで以上に簡単に最新の状態に保つことができます。スキルバッジや実務ベースのトレーニングなどのツールは、すでに達成した進捗を証明する手段のほんの一部です。

試験を新たな形で

従来の再認定モデルでは、2 年ごとに数時間にわたる監視付きの試験を受けるために勉強する必要があり、多くの時間とリソースが必要となります。実際、試験はストレスがたまるものです。スキルは最新の状態に保つ必要がありますが、それを証明するための、より適切で柔軟な方法が必要です。

そのため、Google は再認定プロセスを刷新しています。Google Skills を使えば、最新のコースを受講し、スキルバッジを獲得して Google Cloud クルデンシャルを更新できます。

今すぐ再認定を受けましょう

Google Skills では、各認定資格の基盤となる最も重要なコースとスキルバッジを選択できるようになりました。これにより、自分の役割に最も適した特定のプロダクトとコンピテンシーを優先できます。

厳選されたコースで知識を深める: 新しいトピックについて学び直したい方は、最新のコースやラボを受講して、変更点を確認できます。
スキルバッジでスピードアップ: 日常業務で新しいクラウドテクノロジーをすでに使用している場合は、スキルバッジに直接進むことができます。スキルバッジを獲得するには、知識を現実の問題に適用する能力を検証する、インタラクティブなハンズオンラボを完了する必要があります。スキルバッジの実践的なアプローチにより、コースを受講するよりも迅速に再認定を受けることができます。

この合理化された再認定の機会は現在、Cloud Digital Leader、Associate Cloud Engineer、Professional Cloud Architect、Professional Data Engineer の認定資格をお持ちの方にご利用いただけます。

認定資格が有効な間に必須アクティビティを完了すると、認定資格は自動的に 1 年間延長されます。キャリアに最も役立つものを、時間があるときにいつでも学べます。

生きたクルデンシャル

急速に変化する雇用市場において、有効な認定資格は生きたクルデンシャルです。これは、雇用主に、あなたがかつて（おそらく数年前に）知っていたことだけでなく、今日直面するあらゆる課題に備えていることを伝えるものです。

Google Skills のこの新しいプログラムで、キャリアアップを図り、再認定を受けましょう。

-Google Cloud Learning、マネージングディレクター、Gary Eimerman

Google Cloud 向け Claude アプリゲートウェイを使ってみる

Wed, 15 Jul 2026 01:00:00 +0000

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

Anthropic のエージェントコーディングツールである Claude Code が Google Cloud と連携するようになってから、しばらく経ちます。個々の開発者は簡単に、Google Cloud（GCP）プロジェクトを指すように CLAUDE_CODE_USE_VERTEX=1 を設定し、roles/aiplatform.user ロールを付与することができ、推論は Google Cloud の境界内に留まります。

このフローは、エンジニアが 1 人または数人の場合に最適です。しかし、組織全体に展開するには、企業が抱える摩擦に対処する必要があります。開発者ごとにクラウド認証情報を管理し、managed-settings.json を MDM 経由で各ノートパソコンに push する必要があり、また、ユーザーが適切に確認されないために、開発者ごとの使用状況を特定できなかったり、費用上限を簡単に適用できたりする状況にも対処する必要があります。

Claude アプリゲートウェイは、そのギャップを埋めるものです。同じ Claude バイナリが付属するセルフホスト型サービスで、ローカルの Claude Code クライアントと Google Cloud の間に直接配置されます。この投稿では、このゲートウェイを実行すべき理由と、Google Cloud での安全なデプロイの様子を詳しく説明します。

（注: 今すぐコードを参照するには、Google Cloud 上の Claude アプリゲートウェイのドキュメントで完全なチュートリアルをご覧ください。）

ゲートウェイを実行すべき理由

ゲートウェイを実行すると、開発者とプラットフォーム管理者がそれぞれ単独で行うガバナンス（ID、ポリシー、費用、ルーティングなど）を一元化できます。具体的には次のようになります。

ID: /login リクエストは、ID プロバイダ（IdP）である Google Workspace または OIDC（OpenID Connect）の ID プロバイダを経由してルーティングされ、ゲートウェイはトークンを有効期間の短いセッションに交換します。サービスアカウントキー、API キー、ANTHROPIC_VERTEX_PROJECT_ID などの機密情報が開発者のノートパソコンに保存されることはありません。オンボーディングは、ユーザーを IdP グループに追加するだけで行えます。オフボーディングも、ユーザーを削除するだけで行えて、そのユーザーの次のセッション更新は即座に失敗するようになります。

ポリシー: RBAC（ロールベースアクセス制御）ルールは gateway.yaml に一度だけ記述され、グループごとに解決されてサーバーサイドで適用されます。ゲートウェイは /v1/messages 呼び出しごとに availableModels を再チェックするため、ローカルの managed-settings.json を編集しても何も変わりません。ルールの更新は 1 時間以内にフリート全体に適用されます。

テレメトリー: すべての claude_code.token.usage 指標には、なりすましが可能な、クライアントで設定された OTEL_RESOURCE_ATTRIBUTES ではなく、セッション JWT（署名付きセッショントークン）からの確認済みのメールアドレスとグループが含まれます。ゲートウェイは、OTLP / HTTP 経由で、Cloud Monitoring、Grafana、Datadog など、ユーザーが実行するコレクタにそれらを送信します。

費用上限: 管理 API を使用して、ユーザー、グループ、組織ごとに 1 日、1 週間、または 1 か月あたりの費用上限を設定します。ゲートウェイは、Cloud SQL 台帳に対してトークンを測定し、上限に達すると 429 を返します。費用は正規料金で計算されるため、正確な請求料金の確認には使用せず、使用量の急増を防ぐためのガードレールとして使用してください（確約利用割引や交渉された料金は表示されません）。

ルーティング: 呼び出しは、単一の Cloud Run サービス ID で行われます。Agent Platform のグローバルエンドポイントに region: global を設定するか、2 つ目の upstreams: エントリを追加して、リストの順に 5xx / 429 / タイムアウトでフェイルオーバーします。どちらの場合でも、推論は GCP プロジェクト内に留まるため、割り当て、データ処理に関する契約、料金はすべて変更されません。

連携の仕組み

開発者のローカルまたはデプロイ済みの claude プロセスは、HTTPS 経由で推論トラフィックをゲートウェイに送信します。ゲートウェイは、以下に示すように Cloud Run 上のステートレスコンテナです。

ゲートウェイは独自の署名なしセッショントークンを検証し（Google Workspace にはログイン時とトークンの更新時にのみアクセスします）、ポリシーをチェックし、Cloud Run サービスアカウントを使用してリクエストを Agent Platform に転送します。Cloud SQL はデバイスコードのログイン状態と費用台帳を保持し、OTLP コレクタは特定された指標を受け取ります。

Google Cloud での設定

完全なチュートリアル、すべての gcloud コマンド、完全な gateway.yaml リファレンスは、Google Cloud 上の Claude アプリゲートウェイのドキュメントに記載されています。簡易版は次のとおりです。

ステップ 1: GCP 基盤をプロビジョニングする

Agent Platform、Cloud SQL、Secret Manager の各 API を有効にし、roles/aiplatform.user を持つ claude-gateway サービスアカウントを作成します。また、状態を保存するための小規模な Cloud SQL Postgres データベースインスタンスを立ち上げます。ゲートウェイは、Cloud Run サービス ID として Agent Platform に対する認証を行います。サービスアカウントキーは作成しません。最後に、Google Cloud コンソールで新しい OAuth クライアント（種類: ウェブアプリケーション）を作成します。この例では、ゲートウェイは Google Workspace に対して OIDC の証明書利用者として開発者の認証を行い、このクライアントはハンドシェイク用の client_id と client_secret をゲートウェイに発行します。これらの 2 つの値は、次のステップの oidc: ブロックに渡されます。承認済みのリダイレクト URI は、ゲートウェイ URL がわかってから、後で追加します。

ステップ 2: ゲートウェイを構成する

Google Workspace OIDC クライアント、Postgres 接続文字列、アップストリームとしての Agent Platform を指す gateway.yaml を記述します。このファイルを、OIDC クライアントシークレット、Postgres URL、JWT 署名鍵とともに、Secret Manager に保存します。

code_block: <ListValue: [StructValue([('code', 'listen:\r\n port: 8080\r\n public_url: https://<your-cloud-run-service-url> # the Cloud Run service URL — with --ingress=internal this resolves only inside your VPC / corporate network\r\noidc:\r\n issuer: https://accounts.google.com # Google Workspace\r\n client_id: <client-id>.apps.googleusercontent.com\r\n client_secret: ${OIDC_CLIENT_SECRET} # from Secret Manager\r\n allowed_email_domains: [yourco.com]\r\n\r\nupstreams:\r\n - provider: vertex\r\n region: us-east5\r\n project_id: <your-project>\r\n auth: {} # ADC via the Cloud Run SA, NO key file'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa455495d60>)])]>

次に、https://<public_url host>/oauth/callback を Google OAuth クライアントの承認済みリダイレクト URI として登録します。これは listen.public_url と完全に一致する必要があります。

ステップ 3: Cloud Run にデプロイする

gcloud run deploy を使用して、サービスアカウントをアタッチし、VPC 上で Cloud SQL 接続を行い、Secret Manager から構成をマウントします。コンテナはステートレスで、Cloud Run ロードバランサの背後で水平方向にスケーリングされます。GKE は、すでにプラットフォームとして使用している場合は、変わらず問題なく機能し、デプロイマニフェストのみが変更されます。

code_block: <ListValue: [StructValue([('code', 'gcloud run deploy claude-gateway \\\r\n --service-account="claude-gateway@${PROJECT_ID}.iam.gserviceaccount.com" \\\r\n --set-secrets=/etc/claude/gateway.yaml=gateway-config:latest \\\r\n --ingress=internal \\ # private — developers reach the gateway over the corporate network (VPN/Interconnect into the VPC)\r\n --no-invoker-iam-check # the gateway runs its OWN OIDC; clients carry no GCP token'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa43505a550>)])]>

開発者は企業ネットワーク経由で接続します。内部アプリケーションロードバランサを使用してサービスをフロントエンドに配置できます。Cloud Run のプライベートネットワークに関するドキュメントをご覧ください。

公開か内部かを問わず、開発者は構成した URL にアクセスできる必要があります。または、Cloud Run のデフォルトの URL を使用することもできます。以下の例では、https://claude-gateway.example.internal を使用します。

ステップ 4: 開発者をオンボーディングする

管理対象の設定を使用して、forceLoginMethod: "gateway" と forceLoginGatewayUrl を開発者のマシンに push します。これにより、手動で URL を入力しなくても、/login は接続先を把握します。組織への展開の場合は、MDM チャネルがこれに該当します。開発者は、ローカル管理者権限がある場合、MDM を使用しない最初の試行では、macOS の /Library/Application Support/ClaudeCode/managed-settings.json（または Linux の /etc/claude-code/managed-settings.json）に手動でファイルを書き込むことができます。

code_block: <ListValue: [StructValue([('code', '{\r\n "forceLoginMethod": "gateway",\r\n "forceLoginGatewayUrl": "https://claude-gateway.example.internal"\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa434f91460>)])]>

開発者は Claude Code の起動時に、事前に入力されたゲートウェイのログイン画面で Enter キーを押して URL を確認します。ブラウザのゲートウェイの認証ページでデバイスコードを確認すると、Google Workspace にリダイレクトされるので、ログインします。その後、ブラウザで Google Workspace に対してデバイスコードフローを完了します。セットアップが正しく終了すると、以下のようにターミナルビューに Cloud Gateway が表示されます。

次のステップ

ここまでで、Google Cloud 上の Claude アプリゲートウェイを構成して使用する方法について理解を深められたはずです。おすすめする次のステップをいくつかご紹介します。

完全な構成リファレンス: すべての gateway.yaml フィールドは claude-apps-gateway-config にあります。IdP ごとの設定と GKE トラックは、claude-apps-gateway-deploy と claude-apps-gateway-on-gcp にあります。
グループスコープのポリシー: グループ対応の IdP でゲートウェイをフロントエンドに配置し、groups_claim を設定して、キャッチオールの上に match: { groups: [...] } ポリシーを追加し、チームごとに異なるモデルリストとツール権限を付与します。

今回は以上です。お読みいただきありがとうございました。ご質問やフィードバックがございましたら、ソーシャルメディア（Roy Arsan - Linkedin、X、Ivan Nardini - LinkedIn、X）でお気軽にお問い合わせください。

開発をお楽しみください。

- Anthropic、AI 応用エンジニア Roy Arsan 氏

- Google Cloud、AI エンジニア Ivan Nardini

Cloud Monitoring: 動的しきい値と 2 年間のルックバックを活用したアラートによる異常検出

Wed, 15 Jul 2026 00:00:00 +0000

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

アラートポリシーのしきい値を適切に設定することは難しい作業になりがちです。過去のデータを分析し、意味のある時系列データに集約したうえで、適切なしきい値を選択する必要があります。ワークロードが増加した場合は、以前に設定した静的なしきい値が低くなりすぎ、アラートが頻繁に発生してしまう可能性があります。また、新しいワークロードには新たなしきい値の設定が必要になることもあり、その場合は、ワークロードごとにしきい値を設定するために個別のポリシーを作成することになります。その結果、ほぼ同じようなポリシーを多数管理するという煩わしさが生じます。

言うまでもなく、一部の指標では、静的なしきい値によるアラート設定自体ができません。指標が時間帯によって変動する場合（多くの e コマース指標が該当）、単一のしきい値では対応できません。たとえば、指標が次のような場合はどうすればよいでしょうか。

このグラフの途中では明らかに何か問題が発生していますが、この異常値は日次データの正常範囲内にあるため、静的なしきい値では決して検出できません。

長期ルックバックと動的しきい値の導入

このたび、プレビュー版としてリリースされた PromQL の長期ルックバックアラートポリシーは、Cloud Monitoring のアラートにおけるこの課題を解決するものです。特にご要望が多かったこの機能アップデートにより、Cloud Monitoring に保存された 2 年間以上の指標データに対して PromQL アラートポリシーを構成できるようになり、前年比や前四半期比の分析が可能になります。

PromQL での 2 年間のルックバックによって実現される主なユースケースの一つが、動的しきい値です。これは、しきい値が指標の履歴を参照するポリシーです。簡単な例として、「過去 5 分間の平均値が過去 1 週間の平均値の 2 倍を超えたらアラートを送信する」というアラートポリシーを考えてみましょう。この場合、しきい値として静的な数値を設定する代わりに、アラートを生成する前に、各時系列データが過去のデータに対してどの程度逸脱しているかを設定します。これにより、ポリシーの柔軟性が向上し、ワークロードの増加によって自然に変化するベースラインに対応できるほか、あらゆるワークロードに適用可能な単一のしきい値を提供できます。アラートを適切に設定するためにすべての時系列を分析する必要はありません。「異常」だと判断する要素を設定するだけで済みます。

上の例でこの異常を検出するには、「過去 5 分間の値が、1 週間前の同じ 5 分間の値の 70% を下回った場合にアラートを送信する」というポリシーを作成します。このようなポリシーにより、時間帯に応じて変動するしきい値が設定され、異常な低下を検知できるようになります。

動的しきい値のアルゴリズム

PromQL で適切な動的しきい値のアルゴリズムを選択するには、ソースデータの特性を考慮する必要があります。時間帯によって変動する指標には、変動が少ない指標とは異なるアルゴリズムが必要です。

以下の例を書き換えて、履歴データクエリをしきい値として設定することも可能です（< または > の後に指標を指定します）。ただし、この場合はしきい値を簡単に可視化できなくなります。

これらは履歴データを使用するため、集計値ではなく個々のワークロード単位でトリガーされるきめ細かなアラートポリシーは、新しいワークロードをスピンアップするときに不安定になる可能性があります。この問題は、履歴データが蓄積されるにつれて自然に解消されます。また、動的しきい値アラートを集計値に対してのみ実行することで、この問題を回避することもできます。

移動平均最もシンプルなアルゴリズムでは、データの最近の傾向が長期にわたるデータの移動平均から逸脱した際に、アラートがトリガーされます。これは、比較的安定したデータにおける異常値を検出するのに適しています。

以下は、過去 5 分間のデータを 1 週間のベースラインと比較し、平均より 30% 高いまたは低い場合にアラートを発行する PromQL の例です。

code_block: <ListValue: [StructValue([('code', 'sum(rate(http_requests_total[5m])) /\r\nsum(rate(http_requests_total[1w]))\r\n > 1.3\r\nOR\r\nsum(rate(http_requests_total[5m])) /\r\nsum(rate(http_requests_total[1w]))\r\n < .7'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa434eb72b0>)])]>

これは直接比較する形として記述することもできます（その方がわかりやすいかもしれません）。以下の例は、「直近 5 分間のデータの平均値が 1 週間の平均値の 1.3 倍を超えたらアラートを送信する」というものです。

code_block: <ListValue: [StructValue([('code', 'sum(rate(http_requests_total[5m])) > 1.3 * sum(rate(http_requests_total[1w]))'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa434eb7370>)])]>

Z スコア（標準偏差）このアルゴリズムを使用すると、データの平均値と標準偏差に基づいて異常値を特定できます。Z スコアは、最近のデータと過去のデータとの間の統計的な距離を測定するものです。一般的なしきい値として、Z スコアが 3 を超えるか -3 を下回ると異常とみなされます。これは、通常のノイズと比較したデータの変動性を測定するものであり、平均値が安定していて適度な変動性を持つデータで最も効果を発揮します。

過去 5 分間のデータを 1 週間の平均値と標準偏差と比較する PromQL の例:

code_block: <ListValue: [StructValue([('code', 'abs(\r\nsum(rate(http_requests_total[5m]))\r\n-\r\nsum(rate(http_requests_total[1w]))\r\n)\r\n/\r\nstddev_over_time(sum(rate(http_requests_total[5m]))[1w:5m])\r\n> 3'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa434eb7070>)])]>

Z スコアのシグナルと、その結果として得られる異常検出のしきい値の例:

季節変動の分解（時間オフセット比較）これは、ある期間の時系列データを、前日または前週の同じ期間と比較する単純な時間オフセットアルゴリズムであり、時間帯や曜日によって変動するウェブサイトの訪問者数など、時間に関連するパターンを持つ指標に最適です。祝日やその他の要因によって、特定の日の数値が予想よりも低くなる可能性がある場合は、複数の過去の期間の平均を算出することで平滑化できます（たとえば、1 週間前、2 週間前、3 週間前の平均を算出し、その平均値を今日のデータと比較します）。

過去 5 分間と昨日の同じ時間帯を比較し、最近のデータが 1 日オフセットされたデータよりも 50% 以上低い場合にアラートを発行する PromQL の例:

code_block: <ListValue: [StructValue([('code', 'sum(rate(http_requests_total[5m])) /\r\n sum(rate(http_requests_total[5m] offset 1d))\r\n < .5'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa434eb7400>)])]>

これは、代数的に書き換えると次のようになります。

code_block: <ListValue: [StructValue([('code', 'sum(rate(http_requests_total[5m])) < .5 * sum(rate(http_requests_total[5m] offset 1d))'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa434eb70a0>)])]>

本番環境では、週末や祝日など、本来アクセス数が少ない日にアラートがトリガーされるのを避けるため、1 週間前の同じ期間と比較したり、1 日前や 7 日前の同じ期間の平均値と比較したりすることが望ましい場合があります。

code_block: <ListValue: [StructValue([('code', 'sum(rate(http_requests_total[5m])) /\r\n ((\r\n sum(rate(http_requests_total[5m] offset 1d)) + sum(rate(http_requests_total[5m] offset 7d)) \r\n ) / 2)\r\n < .5'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa4277b42e0>)])]>

時間オフセットを使用する場合は、急激な減少または急激な増加のどちらか一方だけを確実にトリガーするようにします。これは、1 つのポリシーで両方をトリガー対象にすると、アラートが 2 回発生してしまう可能性があるためです。

たとえば、今日のトラフィックが急激に減少した場合、アラートは直ちにトリガーされます。しかし、ちょうど 24 時間後には、今日の異常な減少が明日の過去のベースラインとして扱われます。ポリシーが異常な差異（増加や減少）に対してトリガーされる場合、明日の急激な「正常値への回復」は、前日と比べると大きな値の増減に見えるため、実際には発生していない異常に対してアラートが誤って発行されることになります。これは上のグラフでも確認できます。シグナルの低下（青い線）が、ちょうど 24 時間後にその逆の値として再び現れています。

これを防ぐには、特定の指標をモニタリングする際に、急激な減少または急激な増加のいずれか一方のみを追跡するようにします。

動的しきい値を使用して費用の急増を抑制する

過去のベースラインからの逸脱に基づいてアラートをトリガーできるようになると、多くの興味深いユースケースが生まれます。たとえば、動的しきい値を使用すると、費用を大まかに追跡できる指標を提供する Google Cloud サービスにおいて、予算超過を防ぐことができます。

ここでは、AI トークンの費用の急増を防ぐ例を考えてみましょう。たとえば、次のように設定します。

直近 10 分間の入出力トークンの累積使用量が、過去 1 週間の平均の 25 倍を超えた場合にトリガーされる動的しきい値アラートを構成します。これは、過剰な支出が確実に発生することにつながる極端な異常事態（API キーの漏洩など）のみを捕捉するものです。

sum(rate({"__name__"="aiplatform.googleapis.com/publisher/online_serving/token_count"}[10m])) > 25 * sum(rate({"__name__"="aiplatform.googleapis.com/publisher/online_serving/token_count"}[1w]))

アラートをトリガーして、Pub/Sub 通知チャンネルに通知を送信し、そこから Cloud Run 関数に通知を push します。
この Cloud Run 関数は、Cloud Quotas API を使用してトークン使用量の割り当てを 0 に下げるワークフローを実行し、過剰支出を即座に停止します。トークンの正当な使用は、問題が解決されるまで一時停止されますが、少なくとも損失の拡大は食い止めることができます。

デザインパートナーにご登録ください

Google は現在、しきい値を使用した異常検出をより簡単に実装できるよう製品化を進めています。また、Cloud Monitoring のアラートにおいては、時系列データ向けに特化してトレーニングされた AI モデルを使用する、より高度な異常検出アルゴリズムの開発にも取り組んでいます。

このような分野で Google が進めている取り組みについてご関心をお持ちの方や、先行ユーザーとしてご協力いただける方は、ぜひプレビューパートナーにご登録ください。皆様のご参加を心よりお待ちしております。

- シニアプロダクトマネージャー、Lee Yanco

- スタッフソフトウェアエンジニア、Daniel Koss

エージェントでギアを上げる: ソフトウェア定義車両のセキュリティを確保

Tue, 14 Jul 2026 02:00:00 +0000

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

自動車業界は、新しいテクノロジーの導入を加速させるなかで、重要な岐路に立っています。従来のコネクテッドカーの時代は、ソフトウェア定義車両（SDV）の時代へと移行しました。SDV の時代は、多くの新機能が無線で提供され、急速にイノベーションが起こるのが特徴です。

次世代の SDV は、AI とエージェントを統合することで、未加工のテレメトリーをリアルタイムで実用的な分析情報に変換できるようになるため、車両が環境やユーザーとどのようにやり取りするかを根本的に考え直すことが可能になります。SDV のサポートとセキュリティを強化するために、Google Cloud と Valtech は提携して、Google Cloud 上に構築された、スケーラビリティの高い AI 対応のコネクテッドカープラットフォームである Nexus SDV を開発しました。この開発者向けのモジュール式オープンソースソリューションは、最大 1 億台のデバイスを管理できるように設計されており、Android Automotive OS（AAOS）と深く統合されているため、データフローと車内エクスペリエンスを合理化できます。

このたび、Nexus SDV のオープンソースコアの最初のリリースを発表いたしました。このコアは、Arm ベースのコンピューティングと Bigtable を通じて総所有コストをどのように削減できるかを示すとともに、次世代の自動車インテリジェンスを構築するための AI ネイティブ環境を提供します。

Nexus SDV での AI 主導のエクスペリエンス

Nexus AI はプラットフォームのインテリジェントエンジンとして機能し、車両を受動的なデータソースから能動的なエージェントパートナーに変えます。Nexus AI は、Gemini モデルと Gemini Enterprise Agent Platform を使用することで、複雑なテレメトリーをリアルタイムで分析し、自律的な意思決定と高度にパーソナライズされたドライバーサポートのための情報を提供できるため、ユーザーのニーズを予測するインテリジェントエージェントとして効果的に機能します。

重要なのは、この高度なインテリジェンスが、総所有コスト（TCO）の大幅な削減に重点を置いていることです。高効率の Arm ベースのコンピューティングと Bigtable 向けに最適化されたデータストレージを使用することで、このプラットフォームは大量のデータ処理に関連する運用コストを削減します。このモジュール式の AI ネイティブアーキテクチャにより、メーカーは、次世代の車両ソフトウェアに従来関連付けられていた高額なクラウド費用や開発費用をかけずに、フリートインテリジェンスを迅速にスケールできます。

クラウドネイティブな仕組み

Nexus SDV のアーキテクチャは、車両エッジとデータセンターのギャップを埋めるように設計された、モジュール式のクラウドネイティブな基盤上に構築されています。AAOS との深い互換性は、クラウドと車両の緊密な統合の要であり、高忠実度のテレメトリーがリアルタイムで取り込まれ、同期されることを保証します。この堅牢なデータループにより、Nexus AI はインテリジェントなアップデートとサービスを車両に迅速に push できます。

メーカーは、この開発者向けのオープンフレームワークを提供する Nexus SDV により、Google Cloud エコシステムのスケーラビリティと信頼性を活用して、SDV のライフサイクル全体を管理できます。

Architecture for Nexus SDV.

Google Cloud のセキュリティ管理機能による多層防御

安全性を重視した設計やゼロトラストアーキテクチャなど、Google のセキュアな基盤上に構築された Nexus SDV は、コンプライアンスと脅威保護に関わる煩雑な作業をサポートします。これを実現するために、Nexus SDV アーキテクチャは、6 つの主要な要素にわたって包括的な多層防御セキュリティモデルを実装しています。

相互 TLS（mTLS）と公開鍵基盤（PKI）Nexus SDV は、暗号化された信頼チェーンを利用して、データ交換が行われる前に車両を認証します。インフラストラクチャは Google Cloud Certificate Authority Service（CAS）を使用して、個別の CA プール（サーバー、工場、登録の CA）を管理し、可用性とセキュリティに優れたルートオブトラストを確保します。

具体的には、登録サーバーは、初期 TLS handshake 中にクライアントに有効な「工場出荷時」証明書を提示させることで登録を強制し、接続ストリームから直接証明書を抽出して解析することで、車両の ID を明確に証明します。登録中、サーバーは新しい運用証明書を発行する前に、車両から送信された証明書署名リクエスト（CSR）の検証を行います。

Identity and Access Managementこのシステムでは、Keycloak が中央の OpenID Connect（OIDC）ID プロバイダとしてデプロイされる ID ブローカリングを使用します。車両は、mTLS 経由で運用証明書を使用して Keycloak に対して認証を行い、有効期間の短い JSON Web Token（JWT）を受け取ります。

きめ細かいアクセス制御のために、カスタムの NATS 認証コールアウトサービスが動的なサブジェクト権限を提供します。このサービスは、すべてのメッセージングブローカー接続試行をインターセプトし、JWK 公開鍵を使用して Keycloak JWT を検証し、車両のロールを特定の NATS サブジェクトにプログラムでマッピングします。

サービス間のセキュアな通信には Workload Identity 連携を使用し、パイプラインが GitHub OIDC トークンを一時的な Google Cloud アクセス権と交換して静的認証情報を削除するようにします。一方、GKE Workload Identity では、Kubernetes サービスアカウントを Google サービスアカウントにバインドすることで、Kubernetes Pod が Bigtable などのバックエンドサービスにアクセスできるようにします。

制限付き IAM スコープによってセキュリティが強化され、専用のサービスアカウントが最小限の権限でプロビジョニングされます（データ API が Bigtable からの読み取りのみに制限されるなど）。デプロイコンテキストで VPC-SC、組織ポリシーの制約、Private Service Connect（PSC）を使用することも、セキュアな基盤の実現に役立ちます。

シークレット管理Nexus SDV は、一元化されたシークレット管理により、機密情報を保護します。すべての機密性の高い構成、データベースのパスワード、暗号署名鍵は、Terraform インフラストラクチャのプロビジョニング中に動的に生成され、Google Cloud Secret Manager 内に厳重に保管されます。

シークレットをアプリケーションコードやコンテナイメージに組み込むことを避けるために、デプロイ中にシークレットの取得が行われます。代わりに、サービスは署名鍵と認証情報を実行時にのみメモリに直接読み込み、保存時と転送時の両方でデータ漏洩のリスクを最小限に抑えます。

ネットワーク分離ネットワーク分離を強化するため、基盤となるコンピューティングインフラストラクチャは厳重に保護されています。Nexus SDV は、ワーカーノードにパブリック IP アドレスがないプライベート GKE クラスタで実行されるため、データがインターネットに直接公開されることはありません。さらに、Keycloak PostgreSQL データベースでは Cloud SQL IAM 認証が使用されています。これにより、Cloud SQL Proxy は静的なデータベースパスワードに依存したり、IP 許可リストを管理したりすることなく、IAM ロールを使用してセキュアに接続できます。

セキュア AI フレームワークGoogle Cloud は、セキュア AI フレームワーク（SAIF）のガイダンスに基づき、データプライバシー、モデルガバナンス、安全な実行を優先する包括的なエンタープライズグレードのフレームワークを通じて、これらの高度な AI 機能を保護します。Gemini Enterprise Agent Platform では、説明可能性と安全性の専用の管理機能、継続的な評価とモニタリング、セキュアなモデルレジストリなどの機能を通じて、セキュリティとガバナンスが ML ライフサイクルにネイティブに組み込まれています。

Google Cloud での AI の保護について詳しくは、こちらをご覧ください。

Data API Nexus SDV では、ダウンストリームアプリケーションや外部クライアントが Bigtable などのデータストアに直接アクセスすることを許可するのではなく、カスタムの Data API を介してデータ取得をルーティングします。このマイクロサービスは、セキュアな抽象化レイヤとして機能し、特定の車両 ID、センサーデータの種類、事前定義された時間枠のクエリなどを、厳しく制約された Bigtable の行範囲スキャンと列フィルタに厳密に変換します。

これにより、構造化されたデータアクセスパターンを適用するセキュアなゲートウェイとして機能します。

Nexus SDV の利用を始める

Nexus SDV は自動車インテリジェンスの新時代を象徴するものであり、セキュアで費用効率の高いエージェントプラットフォームを提供します。これにより、メーカーはオープンソースフレームワークで AI の力を最大限に活用できます。ソフトウェア定義車両をどのように再定義しているかについて詳しくは、こちらをご覧ください。

- 自動車 EMEA、業界アーキテクトリード、Florian Haubner

- CISO オフィス、シニアサイバーセキュリティアドバイザー、Vesselin Tzvetkov

Google、2026 年 Gartner® Magic Quadrant™ で分析およびビジネスインテリジェンスプラットフォーム部門のリーダーに 3 年連続で選出

Tue, 14 Jul 2026 01:00:00 +0000

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

このたび Google は、2026 年 Gartner® Magic Quadrant™ において、分析およびビジネスインテリジェンスプラットフォーム部門のリーダーに 3 年連続で選出されました。この評価は、Google Cloud Next 2026 で Google が企業におけるデータの扱い方の根本的な進化について、つまり受動的なインテリジェンスシステムから能動的なアクションシステムへの移行についてご紹介した直後に発表されました。自律型 AI を日常業務に組み込むべく組織が急速に進化するなか、Looker と Google はデータ分析情報とビジネスワークフロー自動化のギャップを埋めることで、最新のデータスタックを再定義しています。Looker のエージェント型ソリューションは、このエージェント型への移行をエンタープライズグレードの信頼に基づいて行うことで、未加工データを信頼できる実用的なビジネス価値へと変換します。これにより、急成長中のスタートアップから大企業まで、世界中の幅広い組織を支え続けています。

このエージェントの時代において Google の勢いを支えているのは、2 つの主要な柱です。1 つは、信頼できる情報の基盤を確立するユニバーサルセマンティックレイヤ、もう 1 つはその情報を自律的なビジネスアクションへと昇華させる Gemini の高度な推論機能です。

こちらから、2025 Gartner Magic Quadrant for Analytics and Business Intelligence Platforms の無料レポートをダウンロードできます。

ユニバーサルセマンティックレイヤエージェント

エージェント型への移行の中核を担うのは、Looker のセマンティックレイヤです。ハルシネーションデータや矛盾する指標がビジネスの命取りになりかねない世界において、LookML は、YouTube、Telenor、Allo Fiber などの顧客がエージェントを本番環境に大規模にデプロイし、それを検証済みの企業の実体に確実にグラウンディングさせるうえで不可欠となっています。

ガバナンスにおける Looker の主な強みをご紹介します。

分析ガバナンスの統合: コードベースの一元化されたセマンティックレイヤにより、組織全体で指標の整合性を確実に維持します。この信頼できる唯一の情報源を階層型権限と新しい認証フレームワークと組み合わせることで、コンテンツの信頼レベルを制御し、プラットフォームのプロアクティブな監査を可能にします。
インデータベース分析とグラフモデリングのための統制されたセマンティックレイヤ: BigQuery Graph や Snowflake セマンティックビューなどのインデータベース分析モデルとのネイティブ統合により、複雑なリレーショナルデータとグラフベースのデータの関係を LookML 内でネイティブに定義、バージョン管理、一元管理しながら、外部アプリケーション全体でセマンティックな一貫性を維持できます。
エンタープライズライフサイクル管理: ネイティブの Git ベースのバージョン管理により、本番環境へのデプロイ前の継続的インテグレーションテストとシームレスなマルチ環境管理に対応します。
同時実行性の高いアーキテクチャ: リソースを柔軟に割り当てることで使用量の急増による負荷を緩和します。ユーザーの需要が急増しているときも、スケーラブルな分析情報を提供できます。

Gemini の推論機能を利用

真のエージェント型ビジネスインテリジェンスには、深い認知的推論が必要です。Gemini 3 を搭載した Looker の専用 BI 生成 AI 機能は、Looker のネイティブ AI ファブリックとして機能し、企業全体に 2 つの大きなメリットをもたらします。

ビジネスユーザー向け: 自然言語による高度な抽象的推論を通じた複雑で多層的な戦略的分析が可能になります。
デベロッパー向け: AI が日常のワークフローに直接組み込まれるため、信頼性の高い LookML 監査やコードの自動生成が可能になり、分析エンジニアリングが劇的に加速します。

Looker と Gemini でエージェント型 BI の時代へ飛躍

Gemini は、エージェントセマンティックモデリング、データ探索、ダッシュボードエージェント、会話分析などの Looker スタックを根本から進化させる原動力となっています。Google Cloud Next 2026 では、Looker 最新のプロダクトイノベーションをご紹介しました。

Looker をあらゆる場所で: Google は、Looker のマネージド MCP サービスをはじめとするヘッドレス BI アーキテクチャを通じて、Looker の利用範囲を従来のインターフェースの枠を超えて拡大しています。この機能により、セマンティックインテリジェンスを外部プラットフォームで直接利用できるようになります。PayPal の事例では、Claude Desktop と Looker MCP を使用して、正確な会話分析を 3,000 人以上のユーザーにスケーリングすることに成功しています。デベロッパーは、Conversational Analytics API を活用して、独自のアプリケーションやサードパーティのエージェントプラットフォーム内で、信頼できるカスタムのデータエージェントを構築、保護、デプロイすることもできます。
Looker BI エージェント: この特化型の会話エージェントを活用すると、ユーザーが日常的な自然言語を使用して、アプリケーションをまたぐ複雑なデータモデルにクエリできるようになります。また、ダッシュボードエージェントによって、こうしたインタラクティブな会話体験を既存のダッシュボードに直接組み込むことも可能です。Gemini Enterprise と完全に統合されたこれらのエージェントは、企業のワークスペースワークフローに直接デプロイすることができます。さらに、これらのエージェントはあらゆる環境でユーザーが自律的なエージェントワークフローをオーケストレートし、その実行状況をモニタリングすることを可能にします。これにより、チームは LookML で管理された信頼できる指標を活用しながら、普段のコラボレーションの場から離れることなく、シームレスに自動アクションをトリガーできるようになります。
AI を活用したセルフサービス: 直感的なドラッグ＆ドロップキャンバスと会話型分析を組み合わせることで、探索モードを刷新しました。ビジュアリゼーションアシスタントなどのツールでは、自然言語を使用して美しいグラフを即座にデザインできます。また、インサイトアシスタントは、主要なトレンドを明らかにする解説文を数秒で自動生成します。これは、一般提供（GA）となったページ分けされたレポートやタブ付きダッシュボードとともにご利用いただけます。
LookML エージェントによるバイブコーディング: この専用の AI エージェントと新しい VS Code 拡張機能により、Looker の画面を開くことなく、VS Code ベースのあらゆる IDE で LookML の開発、管理、デプロイのすべてを完結させることができます。エージェントは自然言語を LookML に変換し、既存の BigQuery や AlloyDB のデータセットから直接モデルを生成して既存のエージェントスキルとスムーズに統合することで、セマンティックモデリングを加速します。開発者が単一のインターフェース内で Looker を開発して操作できるため、一貫性と生産性の高い環境が実現します。
ユニバーサルセマンティックレイヤ: 新たにインデータベース分析モデルがサポートされたことで、LookML は BigQuery Graph や Snowflake セマンティックビューを活用してグラフモデルや複雑なセマンティックオントロジーにも対応できるようになりました。小売、サプライチェーン、サイバーセキュリティなどの業界のデータエージェントの幅広い管理対象ユースケースにも対応可能で、グラフ関係とテーブルベースのモデルを併用してスケールアウト BI エージェントを実現します。

Looker の分析ガバナンスと Google の Agentic Data Cloud を組み合わせることで、自律型 AI エージェントはハルシネーションを伴う推測ではなく、検証済みの企業指標に基づいて動作するようになります。Google Cloud エコシステムを全面的に活用している場合でも、マルチクラウドデータアーキテクチャ全体で Looker を活用している場合でも、Looker はビジネスの未来を切り開くために必要なオープン性、スケーラビリティ、セマンティックグラウンディングを提供します。

レポートをダウンロード: 2026 Gartner Magic Quadrant for ABI Platforms の全文を読んで、ベンダーの評価の詳細をご確認ください。
エージェント型 Looker の詳細を見る: Next '26 で発表されたエージェント型 BI 向け Looker アップデートのまとめをぜひご覧ください。

^{Gartner Magic Quadrant for Analytics and Business Intelligence Platforms - Anirudh Ganeshan、Edgar Macari、Christopher Long、2026 年 6 月 29 日}

^{上の図は、リサーチドキュメントの一部として Gartner, Inc. より公開されているもので、ドキュメント全体の文脈に即して評価する必要があります。この Gartner のドキュメントをご希望の方は、Google までご請求ください。}

^{Gartner は、リサーチに関する発行物に掲載されている特定のベンダー、製品、サービスを推奨するものではありません。また、最高の格付けまたはその他の評価を得たベンダーのみを選択するように助言するものでもありません。Gartner のリサーチに関する発行物は、Gartner のリサーチ組織の見解を表したものであり、事実を表現したものではありません。Gartner は、明示または黙示を問わず、本リサーチの商品性や特定の目的への適合性を含め、いかなる保証も行いません。}

- データクラウド担当プロダクト管理ディレクター、Sean Zinsmeister

- Google Cloud、エンジニアリング担当バイスプレジデント Karthik Ramakrishnan

AI エージェント事例アワード開催！指示するから、自律する AI へ。

Mon, 13 Jul 2026 02:00:00 +0000

前身の「生成 AI 事例アワード」を始めてから、2 年あまりが経ちました。この場には、ビジネスを大きく動かした取り組みから、日々の業務を助ける等身大のアイデアまで、素晴らしい事例が数多く集まってきました。そして、この 2 年で生成 AI そのものも、試す段階から業務に組み込む段階へと移ってきています。

指示を一つずつ出す使い方から、目的を伝えて自律的に動かす使い方へ。この変化は、AI を業務にどう生かすかという問いそのものを変えつつあります。そして、アワードに応募いただく事例の顔ぶれも、この 2 年で確かに変わってきました。

こうした変化に合わせて、今回から名称を 「AI エージェント事例アワード」へと改め、次の一歩をつくる活用事例をあらためて募集します。ビジネスを前に進める最先端の取り組みから、アイデアが光る業務効率化まで。分野や規模は問いません。みなさんの事例をお待ちしています。

事例アワードへの応募・詳細はこちら

スケジュール

エントリーからピッチコンテストまでの日程は次のとおりです。

エントリー開始: 7 月 7 日（火）
エントリー締切: 9 月 2 日（水）
ファイナリストのピッチコンテスト : Agentic AI Summit '26 Fall（10 月 29 日）内で実施

評価基準

審査では、次の 3 つの観点から事例を見ます。

技術的革新性（特に AI エージェントの活用）
実用性と実現可能性
社会的・経済的な影響

表彰内容

受賞した企業には、次の賞を用意しています。※ 表彰内容は予告なく変更になる場合があります。

最優秀賞（1 社 2 名）

トロフィー
Google Cloud Next 27（ラスベガス開催）への特別招待

優秀賞（3 社）

トロフィー
Google Cloud グッズ

ファイナリスト賞（8 社）

Google Cloud グッズ

みなさんの応募をお待ちしています。

Google AI Studio のスターターティアの解説

Fri, 10 Jul 2026 00:00:00 +0000

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

あなたは Google AI Studio で実用的なプロトタイプを作成したところであると仮定しましょう。React フロントエンドに Node.js バックエンド、データベースも使っているとします。今は、チーム、ユーザー、試してみたがっている友人と共有するための一般公開 URL が必要です。

Google Cloud は、きめ細かな IAM 制御、請求管理、リージョン選択機能を備えた、本番環境アプリケーションをデプロイするための完全なプラットフォームを提供します。本格的なシステムを構築する場合は、まさにこれが必要です。一方、10 分以内にプロトタイプをオンラインで公開したいだけの場合、今ならもっと手っ取り早い方法を利用できます。

Cloud Run、Cloud Firestore、Cloud SQL for PostgreSQL、Firebase Authentication など、Google Cloud スターターティアのリソースは、フルマネージドプロジェクトでプロビジョニングされます。利用を開始するのに、お支払い方法（クレジットカードなど）や請求先アカウントは必要ありません。Google アカウントさえあれば、プロンプトの入力から一般公開 URL の取得まで、データベースや認証機能がすべて組み込まれた状態で実現できます。

スターターティアの概要

Google AI Studio でスターターティアサービスを設定すると、Google がバックグラウンドでフルマネージドプロジェクトをプロビジョニングします。ユーザー自身がプロジェクトを作成、構成、管理する必要はありません。リージョンの選択、API の有効化、セキュリティポリシーについては、Google が処理します。

スターターティアは現在、個人の Google アカウントでご利用いただけます。企業または教育機関の Google Workspace アカウントでログインしている場合、組織レベルの管理ポリシーにより、リソースをデプロイする機能が制限されることがあります。これは、各リージョンでの Google AI Studio の提供状況によっても変わります。

スターターティアは、IAM ロールの管理、API の有効化、請求先アカウントとの連携を行う標準の Google Cloud プロジェクトとは異なります。スターターティアプロジェクトは、設計上、最小限の機能しか備えていません。BigQuery や Pub/Sub を有効にすることはできません。リソースのリージョンも変更できません。これがポイントです。設定項目が少なければ少ないほど、軌道を外れる可能性も低くなります。

コンソールエクスペリエンスもこの理念に沿っています。スターターティアユーザーには、数百ものプロダクトページがある Google Cloud コンソール全体ではなく、プロトタイプにとって重要な要素（アプリケーションログ、パフォーマンス指標、基本的なコンテナ構成など）に焦点を当てたシンプルなビューが表示されます。サポート対象外のプロダクトにアクセスすると、課金対象のリソースを誤ってプロビジョニングしないよう、別個の無料トライアルを開始するよう促されます。

ご注意: スターターティアのリソースに標準の Google Cloud 利用規約は適用されません。これらはスターターティア追加利用規約の対象となります。プロトタイピングやビジネスアプリケーションで、これらの規約が障害になることはありません。

提供内容: 事前構成済みのスタック

スターターティアでは、Google Cloud カタログ全体を利用できるわけではありません。代わりに、アプリケーションアーキテクチャの要件に応じてオンデマンドでプロビジョニングされる、4 つのプロダクトの事前構成済みスタックが提供されます。

Cloud Run

Cloud Run はコンピューティングレイヤです。Google AI Studio でデプロイを行うたびに、HTTP トラフィックを処理する Cloud Run サービスが作成されます。スターターティアでは、Google アカウントごとに最大 2 つのアクティブなウェブアプリケーションを同時にデプロイできます。Cloud Run サービスは、受信トラフィックに応じて自動的にスケールし、アイドル状態になるとゼロまでスケールダウンします。つまり、使われていないときは、プロトタイプはリソースを消費しません。これらのサービスは、スターターティア環境を最初にプロビジョニングしたときに固定される、単一のリージョンで実行されます。

Firebase Authentication

アプリでユーザーログインが必要な場合、スターターティアでは Google ログインが事前構成された Firebase Authentication を利用できます。Google AI Studio の AI エージェントは、プロンプトの内容が暗にユーザー ID を必要としている場合（「共有の ToDo リストを作成して」など）、認証を自動的に有効にするよう提案します。

アプリケーションが Google Workspace のインテグレーションを基盤としている場合、このログインフローにより認証が簡素化されます。ユーザーがログインすると、アプリケーションは OAuth アクセススコープをリクエストし、Gmail、ドキュメント、カレンダー、スプレッドシートのデータを安全に操作できるようになります。これにより、要約ツールや受信トレイの整理ツールといった社内ツールのプロトタイプを簡単に作成できます。

Cloud Firestore

Cloud Firestore は、NoSQL データストレージを扱うデータベースサービスです。Google AI Studio エージェントは、プロンプトの内容から構造化データストレージが必要だと判断すると、自動的にプロビジョニングすることができます。AI エージェントは、クライアントサイドの同期コード（通常は /src/lib/firebase.ts ファイル）を生成し、アプリケーションに適した Firebase セキュリティルールのドラフトを作成します（たとえば、request.auth.uid を利用して、認証済みの作成者のみにドキュメントへのアクセスを制限します）。

「権限がない、または十分ではない」というエラーが発生した場合は、Google AI Studio で [エラーを修正] をクリックすると、更新されたアプリのロジックに合わせてエージェントがセキュリティルールを書き換えます。ただし、アプリを広く共有する前に、これらのセキュリティルールを手動でご確認ください。AI によって生成されたセキュリティルールはあくまで出発点であり、確実性を保証するものではありません。

Google AI Studio エージェントによって作成されたすべての Firestore データベースは、使用量の割り当てを共有します（詳しくは、下記の制限事項のセクションをご覧ください）。

Cloud SQL for PostgreSQL デベロッパーエディション

適切なスキーマ、結合、ACID コンプライアンスを備えたリレーショナルデータが必要な場合、スターターティアでは Cloud SQL for PostgreSQL デベロッパーエディションがプロビジョニングされます。これは、AI Studio エージェントとシームレスに連携するよう設計されています。デベロッパーエディションでは、即時のプロビジョニングとゼロへのスケーリングが可能で、迅速かつ低コストな開発環境を実現できます。また、pgvector などの機能を備えたオープンソース PostgreSQL の全機能を利用できるため、独立したベクトルデータベースを追加しなくても、セマンティック検索や RAG アプリケーションを構築できます。

プロンプトを使用してアプリケーションの改良を重ねていくと、Google AI Studio エージェントはアプリケーションの構築や公開の進行状況に合わせて、必要なスキーマの生成や移行を自動的に行います。

プロンプトの入力から一般公開 URL の取得までの 5 つのステップ

1. Google AI Studio のビルドモードを開く。Google AI Studio にアクセスし、ビルドモードに切り替えます。お支払い方法の登録もプロジェクトの設定も不要です。

2. アプリの説明を入力する。「Firebase をバックエンドとして使用する共有 ToDo リストアプリを作成して」のようなプロンプトを入力します。エージェントが React フロントエンドと Node.js バックエンドを生成し、画面の右側にライブプレビューを表示します。

3. Firebase を有効にする（メッセージが表示された場合）。プロンプトにユーザーデータや認証に関する内容が含まれていた場合、エージェントは Firebase を有効にするための構成カードを表示します。設定アイコンをクリックしてリージョンを選択し（これにより Cloud Run のリージョンも固定されます）、確認します。

4. [公開] > [使ってみる] > [アプリを公開] をクリックする。エージェントがコードをパッケージ化し、スターターティアプロジェクトに Cloud Run サービスをプロビジョニングします。

5. URL を取得する。数秒で一般公開の .run.app URL を取得できます。アプリケーションの状況は、デプロイ済みコンテナのログと指標を表示する、簡素化された Google Cloud コンソール画面からモニタリングできます。

以上です。Dockerfile も gcloud も YAML 構成ファイルも必要ありません。

スターターティアとの比較

Google Cloud には、無料で利用できる方法がいくつか用意されています。スターターティアと、新規ユーザーにとって最も一般的な利用開始方法である無料トライアルとの比較は、以下のとおりです。

	スターターティア	無料トライアル
提供内容	4 つのプロダクトを含む事前構成済みスタック（割り当てに上限あり）: Cloud Run Firestore Cloud SQL Firebase Authentication	$300 分のウェルカムクレジット Google Cloud の無料枠その他のプロダクト固有の無料トライアル料金が発生するリスクのない、90 日間の無料体験期間
必要なご対応	Google アカウントの登録スターターティア利用規約への同意	Google Cloud 利用規約への同意不正対策を目的とした、お支払い方法のご提供
時間制限	なし	90 日
プロジェクトの管理	Google が管理	ユーザーがすべてを管理
コンソールエクスペリエンス	シンプル	フル
最適な用途	AI Studio からのプロトタイピング	Google Cloud Platform 全体の評価
さらにご利用をご希望の場合	お支払い方法を追加して、有料アカウントにアップグレードしてください。請求先アカウントを初めて作成する場合は、$300 分のウェルカムクレジットと無料枠をご利用いただけます。アップグレード後は、無料枠と $300 のクレジットでカバーできない使用量に対して請求が発生します。	既存のプロジェクト、残っているクレジット、無料枠、プラットフォームへのフルアクセスを維持するには、有料の請求先アカウントにアップグレードしてください。アップグレード後は、無料枠と残っているクレジットでカバーできない使用量に対して請求が発生します。

スターターティアは、AI Studio でのプロトタイピングに最適です。BigQuery、GKE、Gemini Enterprise Agent Platform が必要な場合や、課金されるリスクなく 90 日間 GCP を幅広く評価したい場合は、無料トライアルをお選びください。どちらのコースでも、準備が整い次第、有料アカウントにシームレスにアップグレードして、すべての機能をご利用いただけます。

制限に備える

スターターティアはプロトタイピングには十分ですが、制限もあります。事前に把握しておけば、予期せぬトラブルを回避できます。

アプリケーションは 2 つまで。デプロイできるアプリケーションは最大 2 つです。アクティブなアプリケーションのいずれかを置き換える場合は、Cloud コンソールでサービスを手動で削除しようとせず、Google AI Studio で既存のアプリスロットにデプロイまたは上書きしてください。

リージョンは 1 つ。スターターティアプロジェクトのリソースはすべて、最初にスターターティアサービスをプロビジョニングしたときに選択した、1 つのリージョンに固定されます。たとえば、Cloud Run にデプロイする前に Firestore データベースをプロビジョニングすると、その時点でリージョンが選択されます。

API サーフェスは固定。スターターティアプロジェクトでは、追加の Google Cloud API（BigQuery、Pub/Sub、Cloud Functions など）を有効にすることはできません。これらが必要な場合は、アップグレードしていただく必要があります。

エフェメラルファイルシステム。公開された Google AI Studio アプリはサーバーレスの Cloud Run コンテナ内で実行されるため、一時的なファイルシステムを継承します。ディスクに直接書き込まれるファイル（アップロードされた画像、生成された PDF、ローカルの SQLite データベースなど）は、コンテナがゼロにスケールされるか、再デプロイされると消滅します。Google AI Studio はプロンプトのイテレーションごとにコンテナを再デプロイするため、この状況は頻繁に発生します。永続データは Firestore または Cloud SQL for PostgreSQL に保存してください。

Firestore の共有割り当て。Google AI Studio エージェントによって作成されたすべての Firestore データベースは、単一の共有割り当てグループを共有します。Google Cloud において、割り当ては、プロジェクトを保護し、不正使用を防ぐことを目的とする、使用量上限または 1 日の予算を表します。サーバー容量が確保されることを保証するものではありません。

割り当て指標	スターターティアの上限
合計保存データ	合計 1 GiB
外向きネットワーク	10 GiB/月
書き込みオペレーション	40,000 回/日
読み取りオペレーション	50,000 回/日
リアルタイム更新	50,000 回/日

グループ内のいずれかのデータベースが 1 日の使用量上限に達すると、そのグループ内のすべてのデータベースは、太平洋時間の午前 0 時頃まで一時停止されます。Firebase Authentication の使用量は個別に測定されるため、ログインが急増してもデータベースの割り当てが減ることはありません。

Cloud SQL の割り当ての共有: Cloud SQL で構築できるアプリは最大 2 つに制限されています。Cloud SQL の割り当てを超過した場合、AI Studio エージェントは自動的に Firestore にフォールバックします。サンドボックスから移行することで、割り当てを増やすことができます。

サンドボックスからの移行

スターターティアの最大の魅力は、そのアップグレード方法です。移行も、データエクスポートも、DNS の切り替えも不要です。スケーリングの準備ができたら、そのままアップグレードできます。

Google AI Studio の [プロジェクト] ページで、[お支払い情報を設定] をクリックします。Cloud 請求先アカウントを作成し、お支払い方法を入力して、Google Cloud の標準利用規約に同意します。Google Cloud を初めてご利用のお客様には、自動的に $300 分のウェルカムクレジットが提供され、トライアル期間中の使用料金に充当されます。アップグレードはダウンタイムなしで実行されます。Cloud Run サービスは稼働し続け、データベースはデータを保持し、.run.app URL は変更されません。

アップグレード後は、IAM を完全に制御できるようになり、任意の Google Cloud API の有効化や、すべてのリージョンとスケーリングオプションの利用が可能になります。以下のようなコスト対策が推奨されています。

予算アラートを設定する: Google Cloud Billing コンソールにアクセスし、使用量が予想（例: $10）を超えると通知するよう、予算アラートを設定します。
Cloud Run のインスタンス数の上限を設定する: スターターティアでは、Google によってコンテナインスタンスの最大数が 1 に固定されています。アップグレードしたら、トラフィックの急増による予期しないスケーリング料金が発生しないよう、インスタンス数の上限を設定（例: --max-instances 5）します。
API の割り当てを設定する: API の呼び出し（Gemini API や Firestore の読み取り / 書き込みなど）に上限を設定し、厳格な制限を使用量に適用します。

ご注意: Google AI Studio エージェントによって作成された Firestore データベースは、請求先を追加した後も共有割り当てグループに残っています。データベースの使用量割り当てを増やすには、Firebase コンソールにアクセスし、Firestore データベースに移動して [データベースをアップグレード] をクリックします。これにより、インスタンスが共有割り当てグループから削除され、標準の請求が適用されるようになります。ただし、課金される前に標準の Firestore 無料枠の上限が適用されます。

パス全体にわたる連続性により、このプロセスはスムーズに進みます。スターターティアでプロトタイプを作成し、数週間かけて改良を重ね、準備が整ったら、何も再構築することなく本番環境グレードの Google Cloud プロジェクトに移行できます。

スターターティアについてご質問がある方や、これを使って構築したものを伝えたい方は、ぜひ私にご連絡ください。また、サブレディットの r/GoogleCloud と r/Firebase では、コミュニティと意見を共有できます。

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

日立「Gemini Enterprise 活用コンテスト」開催レポート ― 112 件の応募から選ばれた、現場を変える 10 の AI エージェント

Thu, 09 Jul 2026 02:00:00 +0000

6 月 17 日（水）渋谷ストリームグーグルオフィスにて AI エージェントは、現場のどんな仕事を本当に楽にしてくれるのか。その答えを、日立製作所のみなさん自身が見せてくれる一日がありました。今年 4 月からデジタルシステム＆サービスセクターの社員を中心に利用が広がった Gemini Enterprise。その活用アイデアを競う「Gemini Enterprise 活用コンテスト」には、総勢 112 件もの応募が集まりました。選り抜かれた 10 組が登壇した発表会の熱気を、そのままお届けします。

112 件の応募から、現場発の 10 組が登壇

発表会は、日立とグーグル・クラウド・ジャパン両社の挨拶で幕を開けました。AI を業務にどう根付かせるかという強い意志が、冒頭から明確に打ち出されていました。

日立デジタルシステム&サービス/ AI &ソフトウェアサービスビジネスユニット事業主管を務める西孝治氏は、AI への期待をこう語りました。「AI は非常に活況を呈していますが、一番やりたいのは日立の社内トランスフォーメーションです。みなさんが AI を使いこなして、お客様の前でもマーケットの中でも、 Gemini をこんな風に使っているぞと宣伝してくれる、そんな AI のショーケースになってほしい」。 1 人で考えるには限界がある、隣の人が何をしているかという知見をぜひ共有してほしい、という呼びかけもそえられました。

続いて登壇した Google Cloud 執行役員自動車・産業営業本部本部長の浅井は、会場を見渡してこう切り出します。「壇上から見ると、みなさんの顔が自信に満ちあふれているのがひしひしと伝わってきて、私自身もワクワクしています」。日頃 Google Cloud と一緒にビジネスの変革を進められていることへの感謝を述べました。

現場の「困った」から生まれた 10 のエージェント

10 組の発表はどれも、日々の業務でぶつかる具体的な「困った」を出発点にしていました。発表順にご紹介します。

失注ポストモーテム AI 「失注リフレクター」: 失注した案件の経緯を SharePoint の社内資料から再構成し、「3 つの分岐点」「顧客の発言と真意」「次回への教訓」を 3 分で構造化レポートにまとめます。レポートは社内のナレッジ DB にためて、営業担当者が商談前に過去の知見として参照できるようにします。原因分析にかかる時間を短縮するとともに、分析の実施率を大幅に高めることで、失注を組織の武器に変える仕組みを提案しました。
Power Automate × Gemini Enterprise による定例会議議事録作成の「完全自動化」 : Microsoft の Power Automate と Gemini Enterprise を組み合わせ、定例会議の議事録づくりを入口から仕上げまで自動でつなぎました。
業務改善アドバイザー: 複数のエージェントが手分けして、自分の業務をヒアリングし、分析し、ボトルネックを洗い出して改善案まで示します。業務の流れは Mermaid 形式の図にして一目で見渡せるようにしました。業務のヒアリングから分析、改善提案までのプロセスを大幅に短縮できる可能性が示されました。これまで数日かかっていた作業が、約 10 分に縮みます。
議事録「ワンショット 5 方向展開」マルチエージェント: Gemini Enterprise の Agent Designer で 5 つのサブエージェントを組み、 Teams のトランスクリプトから Markdown レポート、 Word 議事録、 Excel の Q&A 、 Teams 向けの展開メッセージ、 Redmine チケットを一度に生成します。議事録1 本あたりの二次加工は 90 分から 5 分へ、 94 % 削減。年間およそ 7,000 時間の削減になります。
開発チーム、転生したら AI だった件: 開発が一段落してメンバーが抜けた後の問い合わせや軽微なバグ修正を引き受ける仕組みです。離任する前に「AI 転生テンプレート」で自分の思考の進め方や口調まで写したサブエージェントを残し、人が減ってもチームが回ります。問い合わせ対応や初期調査は 1 時間〜半日から 5 〜 10 分に短くなり、問い合わせの 8 割以上に対して、AIが妥当な回答案を提示できると見ています。
ExcelScribe 手書き帳票の Excel 自動転記ツール: 端末を持ち込めないデータセンターなどの現場で手書きした帳票を、 Gemini Enterprise が文字認識して元の Excel に書き戻します。アウトプットをより精緻に行うために組み合わせるツールを作成しました。
画面録画 × Gemini で PC 操作のムダを可視化: PC 上の自分の作業を画面録画して渡すだけで、 Gemini が操作を読み取り、ショートカットや関数で速くできる箇所を具体的に示します。リモートワークで「隣の人の操作を見て盗む」機会が減った今だからこそ効くアイデアで、マウス操作などをおよそ 20 〜 30 % 減らせます。
NotebookLM と Gemini Enterprise を活用したグラフィックレコーディング作成 : 会議資料や記事を NotebookLM で要約し、その結果を Gemini Enterprise に渡して、グラレコの構成案・レイアウト・イラストの案、さらに画像までを生成します。技術のある社員が、構成作りも含めて 2 時間かかっていた作業が、10 分で実施できるケースも見られました。
提案の質と速度を極める財務分析 with 3 つの AI エージェント: 決算短信サーチ、財務諸表分析、可視化の 3 つのエージェントが連携し、企業名を入れるだけで IR 資料を集め、在庫の回転日数など供給網に効く指標まで自動で計算します。 1 社あたり 3 時間かかっていた情報収集・分析が 45 分に、工数を 75 % 削減しました。
Gemini マルチエージェントによる設計書レビュー支援: チェックリストや日立がこれまで積み上げてきた社内の設計ガイドをレビュー観点として整理し、複数の専門エージェントがシステムの設計書を多角的に確認します。観点不足による見逃しを抑え、レビューがレビュアーの経験に左右されにくくなりました。

どの発表にも共通していたのは、 AI に丸投げするのではなく、「どこを AI に任せ、どこは人が判断するか」をていねいに切り分けていたことです。発表のあとは毎回 Q&A が活発に飛び交い、自分の業務にどう応用できるかを考える声が会場のあちこちから上がっていました。

受賞した 5 組と、審査員からの言葉

審査員が選んだ受賞者の 5 組には、それぞれの着眼点に対して温かいコメントが寄せられました。

オーディエンス賞: 画面録画 × Gemini で PC 操作のムダを可視化。会場の投票で一番多くの支持を集めました。審査員からは「なぜこの人たちは、資料を書かないという選択をしなかったのか。ふつうは AI に資料そのものを作らせたくなるのに、この人たちはあえて、作る作業を速くするほうへ情熱を注いだ。そこがすごい」「現場で起きている泥臭い作業をいかに AI で効率化していくか。これはフィジカル AI の基本で、とても期待できます」と熱のこもった講評がありました。

Google Cloud 賞: 開発チーム、転生したら AI だった件。 Google Cloud の執行役員カスタマーエンジニアリング統括技術本部長渕野は「アイデアとしてとても面白い」と評価したうえで、応用の広がりに触れました。「コーディングを助けるエージェントは増えていますが、実際のシステム開発はプロジェクトの背景を踏まえて進める必要があります。その文脈までエージェントに引き継げる、という意味で応用が効く発想だと思いました」。

Google Cloud 賞: ExcelScribe 手書き帳票の Excel 自動転記ツール。賞品を手渡した Google Cloud 浅井は、「他社のツールであっても、ちゃんと書き込めるモジュールを開発してほしい、という熱いプレッシャーを感じました。フィールドの声として、しっかり開発チームに届けます」とコメントしました。

日立賞: 失注ポストモーテム AI 「失注リフレクター」。日立の内藤氏は、失注分析の難しさに踏み込みました。「受注は意外と再現性が低く、失注は再現性が高いという事実をよく見ていくと、受注確度を上げることに繋がります。そこをきちんと言語化できているのがとても良かった。ぜひお客様の営業活動にも役立てられる形へ、 Gemini と一緒にアイデアを練り上げていってください」。

日立賞: Gemini マルチエージェントによる設計書レビュー支援。日立のものづくりで培ってきた設計の知見を、そのままレビューの観点としてエージェントに持たせた点が評価されました。

5 組とも、削減できた時間や工数といった数字だけでなく、現場の心理的な負担まで軽くしている点が印象的でした。

これからも、日立の挑戦とともに

閉会のあいさつで、 Google Cloud の渕野はこの日の手応えをこう振り返りました。「今日のプレゼンはどれも Q&A が活発で、発表を見て自分のアイデアはこうできるんじゃないか、と考えている様子が伝わってきました。みなさんを支援している私たち Google のメンバーも、やりがいと達成感を感じる素晴らしい会でした」そして、これからへの期待も。「 1 回目でこのレベルの高さです。 2 回、 3 回と続けていけば、どんどん上がっていくはずです。私たちも引き続き、しっかり支援させていただきます」。

また、審査員を務めた日立デジタルシステム&サービス/経営戦略統括本部統括本部長内藤氏からは、30年のキャリアを振り返りつつ、日立の未来への明るい展望が語られました。

「私自身、社内で Gemini Enterprise を毎日5回以上は必ず使う愛用者ですが、今日の皆さんのアイデアを聞いて『こういう使い方もあったのか！』と非常に理解が深まりました。今すぐにでもやってみたいアイデアがたくさんあり、とても楽しいひとときでした」と感謝を述べました。

また、コンテストを通じて見えた社内の変化についても、次のように熱く語りました。「この活動は、自分たちの業務を良くしていく『カスタマーゼロ』につながることはもちろんですが、何より発表者の皆さんが本当に楽しそうでした。これまで30年間会社にいますが、横の人がこんなに楽しそうに仕事をしている姿は見たことがありません。今日そういう一面が見えて、日立の未来は明るいんじゃないかと勝手に思ったりしています」

挨拶の最後には、「日立の取り組みと、Google さんの発展を心から祈念して、ぜひ皆さんと一緒にやってみたいと思います！」と会場に呼びかけました。内藤氏の「すごいぞ！」という掛け声に、会場全体が「Gemini！」と大きな声で応え、イベントは最高潮の盛り上がりのなか締めくくられました。

開会で西さんが語った「日立を AI のショーケースに」という思いは、この日の 10 組の発表で、もう確かな形になり始めていました。現場の「困った」から生まれたアイデアが、 112 件という数になって集まり、その一つひとつが誰かの仕事を軽くしていく。 Google Cloud はこれからも、日立のみなさまのこうした挑戦に、 Gemini Enterprise とともに伴走していきます。

AlloyDB AI 関数 - 革命的なパフォーマンス向上と費用削減を実現

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

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

AlloyDB は AI ネイティブなデータベースです。単なる受動的なデータストアではなく、データをインテリジェントに理解して処理します。AlloyDB では、業界をリードするベクトル検索とハイブリッド検索、会話型エージェントを構築するためのほぼ 100% の精度を誇る自然言語から SQL への変換機能、好みのエージェント型 IDE で構築できるツール、AI 関数を通じて Gemini などの基盤モデルのインテリジェンスをデータに直接適用する機能を利用できます。

このブログ投稿では、AI 関数処理における大きなブレークスルーと、一連のまったく新しい AI 関数について説明します。

まず、AI 機能とは具体的にどのようなものでしょうか？AI 機能は Gemini の世界中の知識を AlloyDB のデータに適用します。ユーザーからの生のフィードバックを管理する課題について考えてみましょう。そのようなフィードバックは構造化されておらず、解析が困難です。このデータを検索に活用するには、前処理とエンティティ抽出が必要になる場合があります。知識抽出のために複雑なカスタムパイプラインを維持する代わりに、AlloyDB 内で Gemini の生成機能を直接使用して、未加工のテキストを構造化された検索可能な分析情報に変換できます。たとえば、ai.generate を使用して、生のフィードバックをクリーンで構造化された JSON に即座に変換する方法は次のとおりです（その他の例はこちら）。

code_block: <ListValue: [StructValue([('code', "SELECT\r\n log_id,\r\n raw_content,\r\n -- Gemini 3.0 を使用して、ユーザーからの生のフィードバックについて推論し、構造を抽出する\r\n ai.generate(\r\n model_id => 'gemini-3.1-pro-preview',\r\n prompt =>\r\n 'Analyze this raw customer feedback entry. Extract the country, service name, and a 1-sentence summary of the feedback. Return as JSON.'\r\n || raw_content) AS structured_feedback\r\nFROM raw_feedback_logs\r\nWHERE user_type <> 'internal';"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa434f161f0>)])]>

結果の例を次に示します。

log_id	raw_content	structured_analysis
1001	2025-12-16 08:00:01 [ERROR] Service: OrderSvc \| DbConnectionTimeout: 5,000 ミリ秒経過後、プール「primary-shard-04」から接続を取得できませんでした。	{"errorCode": "DbConnectionTimeout", "serviceName": "OrderSvc", "rootCause": "サービスが 5,000 ミリ秒のタイムアウト制限内にプライマリシャードプールからデータベース接続を取得できませんでした。"}
1002	2025-12-16 08:05:12 [WARN] Service: IdentityProvider \| 401 Unauthorized: user_id=9942 の署名なしトークンの検証に失敗しました。署名が一致しません。	{ "error_code": "401", "service_name": "IdentityProvider", "root_cause": "署名が一致しないため、署名なしトークンの検証に失敗しました。" }
1003	2025-12-16 08:12:45 [CRITICAL] Service: AnalyticsEngine \| OutOfMemoryError: Java ヒープスペース。1.2 GB の配列の割り当てに失敗しました。ヒープ使用率 99%。	{ "error_code": "OutOfMemoryError", "service_name": "AnalyticsEngine", "root_cause": "サービスが 1.2 GB の配列を割り当てようとした際に、利用可能な Java ヒープメモリを使い果たしました。" }
1004	2025-12-16 08:25:33 [ERROR] Service: WebFrontEnd \| 404 NotFound: リソース /api/v3/users/profile/settings が見つかりません。アップストリームから 404 が返されました。	{ "error_code": "404", "service_name": "WebFrontEnd", "root_cause": "ユーザープロファイル設定に対してリクエストされた API リソースが、アップストリームサービスで見つかりませんでした。" }
1005	2025-12-16 08:35:50 [WARN] Service: NotificationGateway \| GatewayTimeout: 外部プロバイダ「SendGrid」が 30 秒以内に応答できませんでした。再試行がスケジュールされました。	{"error_code": "GatewayTimeout", "service_name": "NotificationGateway", "root_cause": "外部プロバイダ SendGrid が 30 秒のタイムアウト制限内に応答できませんでした。"}

要約や感情分析を行う関数を追加

Google のコア AI 関数である ai.generate、ai.rank、ai.if、ai.forecast の一般提供が開始されました。最初の 3 つの関数のユースケースについて詳しくは、こちらのブログ投稿をご覧ください。予測機能の実際の動作を確認するには、こちらの詳細をご覧ください。

この勢いに乗り、Google は 3 つの新しい関数、ai.summarize、ai.agg_summarize、ai.analyze_sentiment を導入しました。

ai.analyze_sentiment: テキストの感情的なトーンを肯定的、否定的、中立的として自動的に分類します。
ai.summarize: 長文のテキストを、元のトーンとニュアンスを維持しながら、最も重要な情報に凝縮します。
ai.agg_summarize: 列内の複数の行を処理して、（GROUP BY 句などを使用して）グループ全体の統合された単一の要約を生成する集約ツール。

ai.agg_summarize を使用して、小売ウェブサイトの商品レビューを統合する方法の例を以下に示します。

code_block: <ListValue: [StructValue([('code', 'SELECT productname, ai.agg_summarize(review) as reviews_summary\r\nGROUP BY productname;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa434f16af0>)])]>

2 つのゲーム機製品のレビューを要約した結果の例を以下に示します。

productname

reviews_summary

AlphaCore Console

ユーザーは、美しい 4K グラフィック、スムーズな 120 Hz のフレームレート、人間工学に基づいたコントローラのデザインを高く評価しています。

しかし、複数のレビューで、長時間ゲームをプレイすると冷却ファンの音がうるさくなるという不満が示されています。

全体として、熱や騒音に関するわずかな不満はあるものの、最高水準のゲーム機と見なされています。

NeoCore Console

ユーザーは、外出先での携帯ゲームに最適な、優れたバッテリー駆動時間と鮮やかな OLED ディスプレイを気に入っています。

多くのユーザーが、UI が遅く感じられることと、ゲームライブラリが現在限られていることを指摘しています。

カジュアルゲーマーには大きな価値がありますが、パワーユーザーはパフォーマンスが不十分だと感じる可能性があります。

LLM の力をデータに: 大幅な高速化とコスト削減を実現

Google は、AI 機能の処理において前例のないパフォーマンス向上と費用削減のブレークスルーを達成しました。以前は、大規模なデータベースの各行で基盤モデルの呼び出しを実行することで、費用とレイテンシの制約が生じていました。2 つの画期的な機能を導入することで、これらの障壁を打ち破りました。

AI 関数のスマートバッチ処理: この AI 関数アクセラレーション機能は、AI 関数呼び出しのインテリジェントなバッチ処理を実現し、パフォーマンスと品質を最適化します。この効率性は、プロンプトのオーバーヘッドの重複を排除することで実現されます。LLM の定型的な指示は、個々の行で繰り返されるのではなく、バッチごとに 1 回送信されます。「これをアプリケーションレイヤで実行してはいけないのか？」と疑問に思われるかもしれません。そうしない理由は、AlloyDB が最適な結果を得るための適切なバッチサイズをインテリジェントに決定するからです。バッチサイズを過小評価すると、費用とレイテンシのメリットが得られません。バッチサイズを過大評価すると、LLM へのプロンプトが膨張してハルシネーションが発生したり、モデルのトークン制限を超えたりする可能性があります。AlloyDB は、それぞれのリクエストに最適なバッチサイズを計算するだけでなく、設定なしで自動的に再試行を処理するため、パイプラインの復元力を維持できます。社内でテストを行ったところ、大きな成果が得られました。たとえば、従来の 1 行ずつの LLM 呼び出しと比較して、パフォーマンスが最大 2,400 倍向上しました（1 秒あたり 10,000 行を処理）。現在、この機能は ai.if 関数と ai.rank 関数で利用できます。今後、他の関数もサポートされる予定です。

このユースケースを解決するために、ai.if でスマートバッチ処理 / アクセラレーションを使用する例を見てみましょう。ある顧客が、水深 60 メートル以上でも使用できるカメラをガジェット販売サイトで検索しているとします。従来のハイブリッド検索では、最も近い意味的一致と全文一致が抽出されますが、数値データの厳しい制約が考慮されません。つまり、水深 20 メートルでしか使用できないカメラが表示される可能性があります。AlloyDB の ai.if ベースのインテリジェントフィルタリングを使用すると、データベースは水深のニュアンスを実際に理解し、水深 60 メートルの基準を満たすか、それを上回る商品をクエリで返します。以下の例では、バッチサイズを指定する必要がないことに注目してください。ai.if を使用すると、AlloyDB がすべての最適化を内部で処理します。

code_block: <ListValue: [StructValue([('code', "-- スマートバッチ処理 / AI 関数アクセラレーション\r\nSET google_ml_integration.enable_ai_function_acceleration = on;\r\nSELECT productid, productname, category,description\r\nFROM products AS p\r\nWHERE\r\n ai.if(\r\n 'Evaluate if the product description indicates that the product is waterproof at depth 60m or deeper. Description:'\r\n || description);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa434f169d0>)])]>

架空のガジェットサイトでの検索結果の例を以下に示します。商品の詳しい説明が、水深 60 メートルで使用できるという条件に合致していることに注目してください。

最適化された AI 関数: 効率性をさらに高めるために、まずは ai.if に、最適化モードを導入しました。埋め込みを利用し、特定の LLM 出力に基づいてトレーニングされた小さなプロキシモデルをデプロイすることで、データベース内でネイティブに意思決定を処理できます。これにより、外部 LLM を呼び出す必要性が大幅に減ります。Google の内部テストでは、驚くべき成果が見られました。たとえば、1 秒あたりに処理される行数が最大 100,000 行（23,000 倍増加）に達し、費用が 6,000 分の 1（0.1 セント）に削減されました。この手法が最も効果的な場合と効果的でない場合など、技術的な分析情報については、こちらのブログ投稿をご覧ください。最適化された ai.if を使用すると、AlloyDB は次の処理を行います。

プロキシモデルをトレーニングする: AlloyDB は、データのサンプルに基づいて軽量なプロキシモデルをトレーニングします。これは、最適化されたクエリのモデルをトレーニングするために、ai.if 関数で PREPARE ステートメントを使用すると、バックグラウンドで行われます。
クエリを実行する: EXECUTE ステートメントを使用すると、AlloyDB はトレーニング済みのプロキシモデルを使用してクエリをローカルで処理します。
LLM にフォールバックする: モデルの精度が低い場合や、モデルが見つからない場合、AlloyDB は自動的に LLM の使用にフォールバックします。

水深 60 メートル以上で使用できるカメラを検索する先ほどの例で、最適化された ai.if を使用する場合を見てみましょう。ここでは、PREPARE ステートメントを使用してプロキシモデルをトレーニングし、その後 EXECUTE ステートメントを実行します。

code_block: <ListValue: [StructValue([('code', "-- 最適化された関数 / プロキシモデルを準備する\r\nPREPARE waterproof_camera_60m AS\r\nSELECT productid, productname, category, description\r\nFROM products AS p\r\nWHERE\r\n ai.if(\r\n 'Evaluate if the product description indicates that the product is waterproof at depth 60m or deeper. Description:'\r\n || description,\r\n description_embedding);\r\n\u200b\r\n-- プロキシモデルを実行する\r\nEXECUTE waterproof_camera_60m;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa434f16550>)])]>

上のスクリーンショットのように、水深 60 メートルで動作するという基準に実際に合致する商品が表示されます。説明をより詳しく確認できるように、最初の 3 つの商品を表にしたものを以下に示します。

productname	description
Pulsetron Action Camera MZ314	このカメラで次の冒険を制覇しましょう。厳しい自然環境でも使用可能。水深 60 メートルまで潜水できるほか、耐衝撃性に優れたアドベンチャー仕様のシャーシで、過酷なトレイルにも対応します。高度な水平手ぶれ補正により、ジャンプ、ターン、水しぶきなど、あらゆる動きが完璧にスムーズにレンダリングされ、比類のない流動性で映像がストーリーを伝えます。
Hyperbyte Action Camera LG688	激しいアクティビティでも、世界を息をのむほど細部まで捉えます。このカメラは、驚くほど頑丈なポケットサイズのフレームに、1 インチの強力なセンサーを搭載しています。プロ仕様の機器に匹敵する、美しい 5K 動画と鮮明な 20MP の静止画を撮影できます。水深 60 メートルの優れた防水性能で、これまで以上に深く潜水できます。
Alphasync Action Camera WW897	このコンパクトでパワフルなカメラは、あらゆる自然環境に対応。1 インチの大型センサーが、息をのむような瞬間を 5K 動画と 20MP の鮮明な静止画に変換します。水深 60 メートルの防水性能と革新的な水平手ぶれ補正により、深海から高山まで、あらゆる環境で使用可能で、驚くほど安定した映像を実現します。

デモのご紹介

こちらのデモ動画で、これらの機能がどのように連携するかをご覧ください。

始め方は簡単

AI ワークロードに前例のないスピードと費用対効果をもたらす準備はできていますか？

AlloyDB を初めてご利用の場合: 30 日間の無料トライアルで AlloyDB をお試しください。
AI 関数のクイックスタート: いくつかの簡単な前提条件を満たして、SQL クエリ内で ai.if、ai.generate、ai.analyze_sentiment などの関数を直接呼び出しましょう。まずは、実用的な例をご覧ください。
パフォーマンスの向上と費用の最適化: 最大限のパフォーマンス向上と費用削減を実現するには、最適化された関数に関するガイドに従ってください。この最適化は ai.if のプレビュー版で利用可能であり、まもなく他の関数でも利用可能になる予定です。この手法が最も効果的な場合と効果的でない場合など、技術的な分析情報については、こちらのブログ投稿をご覧ください。
スループットのスケーリング: スマートバッチ処理を使用して AI 関数を高速化する（ai.if と ai.rank のプレビュー版で利用可能）か、配列ベースの関数（すべての LLM ベースの AI 関数で一般提供）を使用して、大量のプロンプトをスムーズに処理することができます。

- グループプロダクトマネージャー、Darshana Sivakumar

- ソフトウェアエンジニア、Pushkar Khaldikar

選択、コンプライアンス、コラボレーション: 欧州のオープンなデジタル主権への道

Thu, 09 Jul 2026 00:10:00 +0000

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

欧州委員会の技術主権パッケージは、欧州におけるデジタルの未来を決定づける重要な局面で発表されました。競争力とセキュリティは欧州の企業、公的機関、市民にとっての最優先事項であり、これらの目標を達成するには、欧州のデジタル能力に多額の資金を投じる必要があります。このような状況において、チップからクラウド導入、AI データインフラストラクチャに至るまで、欧州連合のデジタルフットプリントを拡大させる方法が欧州域内で検討されているのはもっともなことです。

欧州委員会の戦略は、「オープン性、パートナーシップ、公正な競争」を基盤としています。実際、このパッケージには、ベンダーロックインに対処するための相互運用性、公共部門向けのオープンソース戦略、データセンターのより迅速なデプロイに関する原則に基づく大胆な施策が盛り込まれています。

Google は、EU 機関と連携して、これらの目標を実際に達成する方法について最高の知識を提供します。その目標を果たすために、クラウドおよび AI 開発法（CADA）の一部を改正する必要があると考えています。それは、意図しない市場の孤立を回避し、信頼できるグローバルパートナーが真のオープン性の枠組みの下で欧州のセキュリティとスケーリングの目標を継続的にサポートできるようにするためです。

Google の主権に対するアプローチは長年にわたって形成されてきたものであり、具体的で技術的かつ検証可能な管理とオープンな選択肢を提供すること、そして欧州のデジタルインフラストラクチャの成長とセキュリティに投資することを基本としています。これは、Google が理解するこの戦略の目標とも一致しています。

Google は、欧州の階層的なコンプライアンス要件をあらゆるレベルで満たすように設計された Sovereign Cloud ソリューションの包括的なメニューを開発しました。厳格な欧州データ境界を持つ標準的なパブリッククラウド構成から、独立して運用されるリージョンクラウドサービス、最も機密性の高い公共部門の業務向けの完全エアギャップ型ソリューションまで、Google は技術的卓越性を犠牲にすることなくコンプライアンスを確保します。

Google は、フランスの S3NS、ドイツの Thales、Schwarz Group、T-Systems、イタリアの PSN、ルクセンブルクの Clarence、スペインの Telefónica などの欧州の主要企業との「Made with Europe」に基づく緊密なコラボレーションを通じて、各国の既存の主権枠組みに関する最高水準の規制要件を満たすように設計された運用上のレジリエンスと管轄権に基づく統制を積極的に提供しています。

パートナー主導の主権ソリューションにおいて、フランスの S3NS サービスは欧州で最も厳格な主権規制基準である SecNumCloud 3.2 を満たすことが認定されています。Google のパートナーである Clarence と S3NS が提供するサービスは、Mistral と並び、主権クラウドを必要とする EU 機関向けのサービスとして EU デジタルサービス総局（DIGIT）の承認を受けています。Google は、これこそが真の信頼できるパートナーシップを構成するものだと考えています。また、欧州委員会に対しては、すでに成果を上げているこの既存の道筋に沿って欧州の主権に向けた取り組みを進めることを推奨します。

1. 主権認証の改善

CADA 法案の最大の懸念事項は、連合保証レベル（UAL）の設計です。加盟国間で主権基準を調和させることは建設的なステップですが、4 つの UAL の各基準は、グローバルプロバイダがどのようなセキュリティ緩和策を提供するかにかかわらず、グローバルプロバイダを制限または排除することにつながります。

厳格な地理的基準によってグローバルサプライチェーンを過度に混乱させずに管理できる可能性を損なうのではなく、主権管理に対する革新的かつ効果的な技術的アプローチの余地を確保することが規制のあり方として求められます。

Google は、欧州の政策立案者がデータ主権と域外リスクの軽減を優先していることを理解し、それを支援しています。Google Cloud は、主権ソリューションスイートのツールの一つである Cloud External Key Manager（EKM）などの機能を通じて、Google のインフラストラクチャの外部で暗号鍵を保持できるようにしています。これは、お客様の明示的な同意と認識なしに暗号化されていないデータに不正アクセスしようとする第三者に対する技術的な障壁となります。

EU はすでに、産業加速法の法案で、よりバランスの取れた代替モデルを設計しています。堅牢なグローバル貿易ルールと強力な予防措置権限に支えられたこのフレームワークにより、信頼できるパートナーは「EU 域内産」として活動できるという推定の下で、信頼できる非 EU パートナーとのコラボレーションを維持できる展望が開けています。Google は、CADA にも同様の理念を適用するよう欧州議会と欧州理事会に対して強く求めています。

2. 相互運用性の促進、ベンダーロックインの防止、調達の改革

主権は、エンドユーザーの選択肢を減らすのではなく、増やすものでなければなりません。健全な欧州のデジタルエコシステムの実現には、ベンダーロックインや選択肢の制限やコストの押し上げを防止するオープンな基盤が必要です。

Google は、オープンで相互運用可能なクラウドエコシステムを育成するという CADA の目標を強く支持しています。この目標を意義あるものにするには、インフラストラクチャ、モデル、アプリケーションというデジタルスタックのあらゆるレベルにわたるオープン性へのコミットメントと政策を一致させる必要があると考えています。

Google のアプローチは、この基盤の上に構築されています。Google は、データエグレス料金無料のオープンでポータブルなインフラストラクチャを提供し、Gemma などのオープン AI モデルを推進し、オープンスタンダードのアプリケーションをサポートしています。スタック全体にわたる Google のオープンなアプローチは、欧州の企業によるスムーズな構築、移行、スケーリングを支援する目的で設計されています。

しかし、制限の多いライセンス慣行によって単一のエコシステムに閉じ込められることから、組織はオープンなアプローチのメリットを最大限に活かすことができていません。真の選択の自由を取り戻すために、Google は 3 つの簡単な改革を提唱しています。それは、ユーザーがソフトウェアライセンスを自由に移動できるようにすること、従来のソフトウェアの公正な価格設定を確保すること、ソフトウェアがどのクラウドプラットフォームでも同様に動作することを保証することです。

3. 欧州の AI の未来に向けたサステナブルでオープンなインフラストラクチャの構築

物理的なコンピューティングインフラストラクチャは、デジタル主権の基盤です。Google は、欧州の半導体研究開発に 300 億ユーロを投資するという欧州半導体法 2.0 の目標を支持していますが、この投資は、コンピューティングインフラストラクチャへの大規模な投資を呼び込む規制ルールを確立することと同じくらい重要であると考えています。

この目標の達成に向け、Google は以下に示す施策を推奨しています。Google は欧州のデータインフラストラクチャに長年投資しており、域内で 13 のクラウドリージョンを運用しています。最近ではドイツ、ベルギー、スウェーデンへの投資を通じて、その取り組みをさらに深めています。このことから、Google のようなグローバル投資家の速度と規模を活用する政策が策定されることを期待しています。

指定されたゾーンでの許可、グリッドアクセス、電力購入契約（PPA）を合理化する「特別プロジェクト」ステータスの導入を歓迎します。これらの施策を成功させるために、Google は以下の取り組みを支持しています。

持続可能性の高いインフラストラクチャプロジェクトに対する許可の迅速化。
国のサステナビリティ基準を今後導入される EU 全体での評価制度と整合させ、水冷などのエネルギー効率の高い技術が不利になることを防ぐ。
これらの産業加速地域が新しい施設の地理的位置を人為的に制約しないようにし、指定地域外で運用されているデータセンターを支援する系統接続対策を拡大する。

今後の展望: Made with Europe

閣僚が次回の欧州理事会に向けて準備を進めているこの瞬間、欧州には、レジリエンスと競争力があり、真にオープンなデジタルの未来を築くという歴史的な機会が訪れています。

Google は、Kubernetes、Chromium、Android、TensorFlow、さらには Gemma などのオープン AI モデルへの貢献に示されるオープンソースソフトウェアの推進や欧州の業界リーダーとのソリューションの共同エンジニアリングを通じて、グローバルなイノベーションと欧州の価値をともに促進できることを証明しています。

Google は、加盟国、欧州の政策立案者、地域のパートナーとの協力のもと、最終的な技術主権パッケージが地域の経済成長を促進し、国家安全保障を確保し、世界の AI イノベーションの最先端拠点としての欧州の地位の維持に貢献することを目指しています。

- Google Cloud EMEA 政府関連業務および公共政策責任者 Giorgia Abeltino

GKE で Ray Serve LLM をスケーリング: デベロッパーエクスペリエンスを損なうことなくパフォーマンスを向上

Thu, 09 Jul 2026 00:00:00 +0000

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

LLM 推論とモデルサービングを求めるデベロッパーは、Anyscale が構築した、デベロッパーに優しい Python ネイティブの API を備えたスケーラブルなモデルサービングライブラリである Ray Serve をよく利用します。デベロッパーは、Google Kubernetes Engine（GKE）と組み合わせることで、初期のモデル開発からオンラインの本番環境でのサービングまで、要求の厳しい LLM サービングのユースケース向けに最適化された強力な統合プラットフォームを利用できます。

この柔軟性と機能セットは、以前はパフォーマンスの低下を伴うものでした。しかし現在は、Anyscale とのパートナーシップにより、Ray Serve で最大 5 倍高いスループットと 8 分の 1 のレイテンシを実現しており、使いやすさを犠牲にすることなく、最先端の分散推論の高まる需要と厳格なパフォーマンス要件を満たしています。

ボトルネックなしで推論をスケーリング

共同エンジニアリングパートナーシップを通じて、Ray Serve LLM のパフォーマンス特性を大幅に向上させる 3 つの主要なアーキテクチャ最適化手法を導入しています。

Ray Serve HAProxy インテグレーション: Ray Serve に HAProxy が組み込まれ、内部リクエストのルーティングとロードバランシングを管理できるようになりました。このセットアップにより、プロキシのオーバーヘッドが大幅に削減され、トラフィックが多い場合でも Python ランタイムが飽和状態になるのを防ぐことができます。
直接トークンストリーミングアーキテクチャ: このアーキテクチャでは、初期リクエストパスと戻りストリームが分離されます。トークンは個々のモデルレプリカからプロキシに直接ストリーミングされ、ストリーミングデータパスの Ingress ルーターを完全にバイパスしてレイテンシを短縮します。
vLLM 用の v2 Ray エグゼキュータバックエンド: vLLM 用に改良された Ray バックエンドは、Ray をデータプレーンから移動して非同期スケジューリングを可能にします。これにより、コードパスがネイティブの vLLM エグゼキュータと統合され、パフォーマンスのギャップが解消され、Ray ユーザーが最新のエンジンレベルの最適化を利用できるようになります。

GKE でのパフォーマンスのベンチマーク

また、Anyscale と協力して、NVIDIA HGX B200 システムを搭載した Google Cloud A4 VM など、次世代 AI ハードウェアを利用する GKE クラスタで、更新された Ray Serve LLM のベンチマークを実施しました。オーケストレーションとルーティングによって生じるボトルネックを特定するために、小規模で効率的なモデルである Gemma 4 E2B を実行することにしました。ベンチマークでは、新しい Ray Serve LLM を以前のパフォーマンスと比較したほか、Ray エグゼキュータを使用したプレーンな vLLM セットアップとも比較しました。

これらの技術的強化により、パフォーマンスに大きな影響がもたらされ、以前の Ray Serve 構成と比較して、スループットが最大 5 倍高く、レイテンシが 8 分の 1 になっています。

改善された Ray Serve LLM は、8 つのレプリカを持つサービングクラスタで目覚ましい改善を実証し、以前のパフォーマンスをはるかに上回るスケーリングパターンと、vLLM をネイティブに実行した場合と同等のパフォーマンスを示しましたが、Ray がもたらす柔軟性はありませんでした。

同時ユーザー数が増加するなかで、Ray は 99 パーセンタイルの最初のトークンまでの時間を短く維持しながら、スループットをスケールアップできるようになりました。これは以前は難しかったことです。今では、LLM の実務担当者が、Kubernetes で本番環境レベルのパフォーマンスを実現するために、Ray の豊富な機能とエコシステムを犠牲にする必要はなくなりました。

Ray Serve に GKE を選ぶ理由

GKE は、これらのソフトウェアの最適化を最大限に活かすための基盤となるインフラストラクチャを提供します。GKE 用の Ray オペレーターアドオンを使用すると、自動水平スケーリング、モニタリング、マルチクラスタスケーリング、組み込みのフォールトトレランスなど、Google Cloud AI アクセラレータ全体でターンキーデプロイが実現します。GKE は、分散された物理ハードウェアのオーケストレーションの複雑な部分を抽象化するため、チームは Ray を使用してモデルとアプリケーションロジックの改良に集中できます。

GKE で Ray Serve LLM を試す

デベロッパーの皆様には、最新の Ray リリース（2.56 以降）でこれらの機能強化を試して、GKE での高パフォーマンス LLM サービングの未来を体験することをおすすめします。

詳細については、以下のリソースをご確認ください。

- Google、ソフトウェアエンジニア、Spencer Peterson

- Anyscale、ソフトウェアエンジニア、Seiji Eicher 氏

Gemini Omni Flash と Nano Banana 2 Lite が圧倒的なスピードと費用対効果をもたらす

Wed, 08 Jul 2026 02:00:00 +0000

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

アイデアのスピードに合わせてツールが動くとき、創造性は最大限に発揮されます。より豊かで信頼性の高いエクスペリエンスを提供しつつ、再生成にかかる時間と費用の削減を実現するために、Gemini Enterprise Agent Platform に新たに 2 つのモデルを追加します。

まず、Nano Banana 2 Lite（Gemini 3.1 Flash-Lite Image）の一般提供を開始します。このモデルは、Nano Banana モデルファミリーの中で最も高速かつ費用対効果の高い画像生成・編集モデルです。アイデアを次々と生み出す場合でも、広告バリエーションの A/B テストを行う場合でも、数百万人のユーザー向けのソーシャルアプリを強化する場合でも、このモデルを使用すると、探索、反復処理、スケーリングを迅速に行うことができます。

もう 1 つは、Gemini Omni Flash です。こちらは、公開プレビュー版としてご利用いただけます。Gemini の実世界に関する知識を基盤とするモデルで、高品質な動画生成と会話型編集が可能になり、キャラクターや商品の入れ替え、動的なスタイル変換、オブジェクトの追加、ライティングの再調整など、動画アセットの編集や改良をきめ細かく制御できます。

Gemini Omni Flash と Nano Banana で、どんなに斬新な構想でもカタチにできます。

どちらのモデルも、画像や動画の生成・編集において、市場をリードする最先端モデルの中でも最高レベルのコストパフォーマンスを実現します。

Gemini Omni Flash: 高品質な動画生成・編集

Gemini Omni Flash を活用すれば、会話型の動画生成・編集機能をアプリケーションに直接実装できます。ユーザーは、強力なメディアモデルを自身のエージェントワークフローに簡単に組み込むことができ、プラットフォームを切り替えることなく、動画の作成、リミックス、ブラッシュアップを行えます。

Google DeepMind による包括的なベンチマーク情報については、Gemini Omni をご覧ください。

Gemini Omni Flash は、以下の 4 つの主要分野に重点を置いて構築されています。

会話型編集: 自然言語を使用して、キャラクターの入れ替え、ライティングの再調整、アングルの変更などを行うことができます。元の音声トラックと動画トラックはネイティブに維持されます。
マルチモーダル入力: テキスト、画像、動画の入力を組み合わせて、動画生成をガイドします。Gemini Omni Flash は、キャラクター、オブジェクト、スタイルの整合性を維持しつつ、すべての動画出力でネイティブに音声を生成します。
実世界の知識とシミュレーション: 物理法則に関する直感的な理解に加えて、歴史、科学、文化的背景に関する Gemini の知識を組み合わせることで、写実的な表現と意味のあるストーリーテリングとの間のギャップを埋めます。
テキストとアクションの同期: 読みやすいテキストやグラフィックを動画内に直接レンダリングし、キネティックタイポグラフィや解説テキストを画面上の動きと同期させます。

注: Gemini Enterprise Agent Platform API を介した Gemini Omni Flash での音声参照、動画参照、最終フレーム、シーン拡張、高解像度のサポートは近日中に提供開始予定です。

モデルの機能の完全なリストと統合方法については、ドキュメントと料金をご覧ください。

Gemini Omni Flash は、最高レベルのコストパフォーマンス（動画出力 1 秒あたり $0.10）で動画生成・編集機能を提供します。

Gemini Omni Flash を使用して次世代のアプリケーションやクリエイティブなエージェントワークフローを構築しているお客様

「Google の最新モデルである Gemini Omni Flash や Nano Banana 2 Lite を、当社のオールインワンクリエイティブ AI スタジオである Adobe Firefly に導入できることを大変嬉しく思います。これにより、クリエイターは、アイデアからコンテンツ完成に至るまでのプロセスをより迅速に進められるようになります。これらの新しいモデルは、プロフェッショナル向けツールと業界最高水準のクリエイティブ AI モデルを連携したワークフローで提供するという Adobe の戦略をさらに強化するものであり、クリエイティブなアイデアを形にする方法をより柔軟かつ高度に制御できるようになります。」- Adobe、プロダクト担当シニアディレクター、Matt Chotin 氏

「まず目を引いたのは、Gemini Omni Flash モデルでできることが想像以上に多彩だったことです。VFX の能力には驚かされましたし、プロデューサーの視点で見ると、非常に面白い可能性を感じました。しかし、私が最も期待しているのはハイブリッドな活用の可能性です。従来の実写撮影で一緒に仕事をしてきたスタッフをそのまま起用しつつ、AI が現在実現できる幅広い機能を同じ制作現場に採り入れることができるのです。」 - Invideo、クリエイティブディレクター、Nishant Tahilramani 氏

「Google との継続的なパートナーシップを通じて、WPP は新しい Gemini Omni Flash モデルへの早期アクセス権を獲得し、当社のエージェント型マーケティングプラットフォームである WPP Open に統合しました。Gemini Omni Flash のマルチモーダル機能（画像、音声、動画の入力参照をシームレスに扱える能力）と直感的な会話型編集機能の組み合わせは、コントロールされた AI 制作の飛躍的な進歩を意味します。各チームではすでに、クライアントの案件に向けて、アセットのローカライズや高精度な商品の差し替え、動的なスタイル変換などの検証を重ねています。Google Cloud とのパートナーシップを通じて、AI 主導のクリエイティビティの可能性を絶えず広げ、極めて柔軟かつインテリジェントな成果を提供していけることを、大変嬉しく思います。」- WPP、最高イノベーション責任者、Elav Horwitz 氏

Nano Banana 2 Lite: 費用とスピードを重視した設計

Nano Banana 2 Lite は、わずか 4 秒で画像を生成できます。デザインコンセプトを数秒で生成して反復修正できるため、白紙の状態から完璧なレイアウトを瞬時に作成できます。

Nano Banana 2 Lite generates images in as little as four seconds.

Nano Banana（Gemini 2.5 Flash Image）からの大幅な改良

Nano Banana 2 Lite は、高速かつ費用対効果の高い画像生成が可能なほか、従来モデルの Nano Banana と比較して視覚品質と機能性が大幅に向上しています。また、複雑なタスクも高速で実行できるよう、中核機能を強化しています。

実世界の知識: 文脈に即した的確なシーンや、データの簡易的な視覚化、特定の場所を想定したモックアップを、素早く書き出すことができます。
キャラクターの一貫性: 複数の高速生成にわたってキャラクターのアイデンティティやオブジェクトの忠実性を維持できるため、ストーリーボードツールの構築や、e コマースのバーチャル試着機能の組み込みが容易になります。
テキスト作成やローカライズの迅速化: 画像の高速生成と同時に鮮明なテキストを直接レンダリングして、コピー案をその場で作成します。ローカライズされた広告バリエーション全体で、タイポグラフィの効果を即座に確認できます。

モデルの機能の完全なリストと統合方法については、ドキュメントと料金をご覧ください。

注: 画像生成は非常に高速ですが、画像編集では応答時間が若干長くなる場合があります。

高速かつ費用対効果に優れた画像生成を実現。従来モデルの Nano Banana と比較して、画質と機能性の両面で飛躍的な進化を遂げています。

Nano Banana 2 Lite でより高速なビジュアルエクスペリエンスを構築している業界のリーダー

「スピードはもはや制約ではありません。生成速度が想像力を上回れば、クリエイターはツールの処理を待つことなく、アイデアを形にすることに集中できます。Nano Banana 2 Lite は、その感覚をクリエイティブなプロセスに吹き込み、思考をほぼ瞬時にビジュアルへと変えてくれます。Artlist のユーザーにとっては、進行状況バーを眺める時間が減り、創作やブラッシュアップ、パーソナライズに費やす時間が増えることを意味します。これにより、時代の潮流に合わせたスピード感で制作を進められるようになるのです。」 - Artlist、AI コンテンツおよびイノベーション担当ディレクター、Idan Yonas 氏

「Nano Banana 2 Lite は高速かつ信頼性が高いツールであり、デザイナーが Figma Weave のノードベースのキャンバス上でより多くのアイデアを探求し、ユニークな画像を作成するのをサポートしてくれます。制作のフローを維持しながら、迅速なブラッシュアップを行うのに理想的です。」 - Figma、共同創設者兼クリエイティブディレクター、Itay Schiff 氏

「当社では、スライド資料からウェブページに至るまで、Manus の自律型ワークフロー内でリアルタイムの画像生成を実現するために、Nano Banana 2 Lite をテストしてきました。そのスピードはこうしたシナリオに非常に適しており、当社の AI エージェントはビジュアルのブラッシュアップを迅速に行い、わずか数秒で結果を出せるようになりました。画質も優れており、フルバージョンの Nano Banana 2 に匹敵するレベルです。今後もパートナーシップを継続し、より優れたエクスペリエンスを共に構築していけることを楽しみにしています。」 - Manus AI、共同創業者 / 最高製品責任者、Tao Zhang 氏

安全性と企業ガバナンス

C2PA コンテンツ認証情報と人の目には見えない SynthID 透かしがデフォルトで有効になっており、両方のモデルでコンテンツの真正性を検証できます。

Gemini Enterprise Agent Platform では、大規模かつ同時実行が多い API リクエストを確実に処理するために、本日より Nano Banana 2 Lite のプロビジョンドスループット（PT）の提供を開始いたします。Gemini Omni Flash のプロビジョンドスループットは、近日中に提供開始予定です。

今すぐ始めましょう

これらの画像や動画の生成・編集機能を、ご自身のアプリケーションやクリエイティブワークフローに早速実装してみましょう。ご利用開始にあたっては、以下のリソースをお役立てください。

モデルの試用: Gemini Enterprise Agent Platform 内の Agent Studio
API ドキュメント: Nano Banana 2 Lite、Gemini Omni Flash
Colab ノートブックへのアクセス: Nano Banana 2 Lite、Gemini Omni Flash
料金: Agent Platform の料金（両方のモデル）
プロンプトガイド: Nano Banana、Gemini Omni Flash
Gemini Omni Flash エージェントスキルのプロンプト

- Cloud AI、プロダクトマネジメント担当バイスプレジデント、Michael Gerstenhaber

BigQuery の AI.AGG 関数で全体像を把握し、傾向を分析する

Tue, 07 Jul 2026 02:00:00 +0000

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

Google は先日、BigQuery の AI.AGG() 関数のプレビュー版を発表しました。AI.AGG() を使用すると、1 行の SQL 内で自然言語による指示を与えるだけで、数百万行に及ぶ非構造化データやマルチモーダルデータに関する情報を要約、合成できます。

1 行の SQL で数百万行を要約: AI.AGG

BigQuery には、データの個々の行を分析するのに役立つ強力な AI 関数がすでに用意されていますが、非構造化データを大規模に分析するには、別のアプローチが必要となります。 AI.AGG() を使用すると、ログやドキュメントなどの非構造化データに対して、以下のような質問をすることができます。

製品に対する否定的なレビューの中で、要望が多かった機能の上位 3 つはどれですか？
ユーザーが最も頻繁に遭遇しているエラーの種類は何ですか？また、何から調査を始めるべきですか？
当社の自動エージェントが顧客の問題解決に一貫して失敗しているのは、どのようなシナリオですか？

この投稿では、AI.AGG() 関数について詳しく説明するほか、この関数によって実現できるユースケースをいくつかご紹介します。また、複雑かつインテリジェントなデータ分析を行うために、BigQuery の他のマネージド AI 関数と組み合わせて使用する方法についてもご説明します。

AI.AGG() を使用したシステムログの分析

AI.AGG() の威力を示す好例が、システムロギングの分析です。ログメッセージ、警告、エラー、スタックトレースには、サービスを改善するうえで非常に役立つ情報が含まれている可能性がありますが、手動で調査するには時間と労力がかかります。特に、大規模な運用を行っており、確認すべきログが数千件もある場合はなおさらです。

AI.AGG() を使用すると、多数のログを一度に簡単に分析できるため、グループ化や優先順位付けを行って、どのログを最初に詳しく調査すべきかを判断できます。実際、BigQuery エンジニアリングチームは AI.AGG() を開発する際にこのアプローチを採用しており、この機能自体の入力処理に関連するエッジケースを特定するためにこの関数を利用していました。

このことを実証するために、Loghub から入手できる Apache Spark 標準の INFO ログの公開データセットを分析してみましょう。クラスタでは、FATAL エラーがスローされることなく、メモリスラッシング、クロックドリフト、ブロードキャストボトルネックといった問題に直面することがよくあります。AI.AGG() を使用すると、こうした一見正常に見えるログから隠れた非効率性を分析できます。サンプルデータファイルは、UI、CLI、クライアントライブラリなど、対応している任意の方法を使用して BigQuery に読み込むことができます。以下の例では、bq_logs_demo というデータセットと spark_logs_unstructured というテーブルにログファイルを読み込んだことを前提としています。

ここでは、プロンプトをどのように作成しているかに注目してください。モデルに対して「すべて正常」と回答することを明示的に許可することで、エラーのハルシネーションを防ぎながら、特定の異常を検出するように指示しています。

code_block: <ListValue: [StructValue([('code', "SELECT\r\n Component AS spark_component,\r\n COUNT(*) AS log_count,\r\n AI.AGG(\r\n Content,\r\n 'これらの Spark システム INFO ログを分析してください。2 文で簡潔にまとめてください。まず、このコンポーネントの通常の動作を説明してください。次に、隠れた非効率性、レイテンシの急増、再試行の繰り返し、異常なパターンを明示的に特定してください。'\r\n ) AS performance_analysis\r\nFROM\r\n `bq_logs_demo.spark_logs_structured`\r\nGROUP BY\r\n Component\r\nORDER BY\r\n log_count DESC;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa43416ca90>)])]>

これらの結果から、AI.AGG() が「正常に動作している」というメッセージを適切に認識しつつ、重要な診断情報を抽出していることがわかります。

クエリ結果のペイン: ログデータセットに対する AI.AGG() が生成した分析情報を表示

非構造化テキストや画像データからのカテゴリ抽出

次に、BigQuery の一般公開データセットの一つである、cymbal_pets（架空のペット用品店）を使用して、AI.AGG() の柔軟性がわかるユースケースをいくつか見ていきましょう。このデータセットには、店舗が取り扱う商品のカタログが用意されています。商品の名前、説明、画像といった非構造化データが含まれているため、非構造化データを処理する AI 関数の威力を示す好例です。

たとえば、データセット内の商品を分類するとします。この場合の最初の課題は、商品にラベルを付けることではなく、商品カタログ全体にどのようなカテゴリが存在するかを把握することです。AI.AGG() を使用すると、元の商品名や説明を分析するようにモデルに指示でき、カテゴリを包括的に特定できます。

code_block: <ListValue: [StructValue([('code', "-- 商品名と説明から商品のカテゴリを特定する\r\nSELECT\r\n AI.AGG(\r\n ('商品: ', product_name, ' - 説明: ', description),\r\n 'これらの商品の主なカテゴリは何ですか？'\r\n ) AS category_description\r\nFROM\r\n `bigquery-public-data.cymbal_pets.products`;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa43416cc40>)])]>

このクエリは、カテゴリについてシンプルな平文のリストを返します。

商品データセットに対して AI.AGG() によって特定されたカテゴリの平文の結果。

この最初のクエリは探索には最適ですが、信頼性の高い自動化されたデータパイプラインを構築するには、シンプルな平文の文字列では不十分です。実際にデータをタグ付けするには、AI.AGG() に JSON 配列などの構造化された形式を返すように指示する必要があります。その後、構造化されたカテゴリを別の AI 関数である AI.CLASSIFY() のパラメータとして使用することで、各商品にカテゴリのラベルを実際に付与できます。

以下の SQL ステートメントは、これらの各ステップを 1 つのスクリプトで完了します。

code_block: <ListValue: [StructValue([('code', "-- 1. カテゴリの配列を保持する変数を宣言する\r\nDECLARE generated_labels ARRAY<STRING>;\r\n\u200b\r\n-- 2. 結果を保存するデータセットを作成する\r\nCREATE SCHEMA IF NOT EXISTS categorized_cymbal_pets;\r\n\u200b\r\n-- 3. AI.AGG で JSON 文字列を生成し、変数に抽出する\r\nSET generated_labels = (\r\n SELECT\r\n JSON_VALUE_ARRAY(\r\n AI.AGG(\r\n ('商品: ', product_name, ' - 説明: ', description),\r\n '主な商品カテゴリを特定してください。文字列の有効な JSON 配列を 1 つだけ返してください。マークダウンのコードブロック、バッククォート、会話テキストは含めないでください。'\r\n )\r\n )\r\n FROM `bigquery-public-data.cymbal_pets.products`\r\n);\r\n\u200b\r\n-- 4. 変数を AI.CLASSIFY に直接フィードする\r\nCREATE OR REPLACE TABLE `categorized_cymbal_pets.categorized_products` AS (\r\nSELECT\r\n product_name,\r\n description,\r\n AI.CLASSIFY(\r\n ('商品: ', product_name, ' - 説明: ', description),\r\n generated_labels\r\n ) AS assigned_category\r\nFROM\r\n `bigquery-public-data.cymbal_pets.products`\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa43416c130>)])]>

結果のテーブルが表示されます。このテーブルには assigned_category が含まれています。

AI.AGG() と AI.CLASSIFY() で作成された新しい assigned_category 列を含む categorized_products テーブルのプレビュー。

中間テーブルをよく見ると、構造化されたカテゴリが最初の平文の結果からわずかに変更されていることがわかります。これには 2 つの理由があります。1 つは、LLM が非決定論的であるということです。そのため、同じプロンプトに対してまったく同じ回答を常に返すとは限りません。もう 1 つは、新しい出力構造に対応するようにプロンプトが調整されたことです。

返された商品カテゴリは、プロンプトの一部として要求されたとおり、AI.AGG() によって JSON として構造化されている。

テーブルにカテゴリのラベルが付けられたので、カテゴリごとにグループ化して従来の SQL 集計を行うことも、AI.AGG() を使用して各カテゴリを個別に扱うこともできます。

たとえば、以下のクエリでは、従来の指標（行数など）に加え、グループ化された特定の商品に共通する点について AI が生成した要約も併せて取得します。

code_block: <ListValue: [StructValue([('code', "-- 新しく割り当てられたカテゴリごとに分析情報を統合する\r\nSELECT\r\n assigned_category,\r\n COUNT(*) AS item_count,\r\n AI.AGG(\r\n ('商品: ', product_name, ' - 説明: ', description),\r\n 'このカテゴリの商品の共通する特徴や目的を簡潔に説明する要約を 1 文で作成してください。'\r\n ) AS category_summary\r\nFROM\r\n `categorized_cymbal_pets.categorized_products`\r\nGROUP BY\r\n assigned_category\r\nORDER BY\r\n item_count DESC;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa43416c220>)])]>

クエリ結果: AI.AGG() による分析と従来の SQL 手法による分析を併せて表示。

非構造化データはテキストに限定されません。AI.AGG() はマルチモーダル入力にネイティブに対応しているため、画像ファイルから、直接集約された分析情報を返すことができます。

cymbal_pets Google Cloud プロジェクトには、商品写真が豊富に含まれた Cloud Storage バケットも用意されています。外部オブジェクトテーブルを作成することで、画像 URI を AI.AGG() に直接安全に渡して、コレクション全体の視覚的コンテンツを要約するようにモデルに指示できます。

code_block: <ListValue: [StructValue([('code', "-- オブジェクトテーブル内の画像コンテンツを要約する\r\nSELECT\r\n AI.AGG(\r\n STRUCT(OBJ.GET_ACCESS_URL(ref, 'r')),\r\n 'これらの画像の主なカテゴリは何ですか？'\r\n ) AS category_description\r\nFROM\r\n `bigquery-public-data.cymbal_pets.product_images`;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa43416ca30>)])]>

クエリ結果: Google Cloud Storage にある商品画像を分析して、AI.AGG() が商品カテゴリを抽出。

AI.AGG() の仕組みとベストプラクティス

AI.AGG() をご自身の環境で効果的に使用するには、その内部でのデータ処理の仕組みを理解することが役に立ちます。ここでは、コンテキストウィンドウ、エラー処理、パイプラインの最適化について知っておくべきことを紹介します。

1. コンテキストウィンドウとマルチレベル集計LLM には特定のコンテキストウィンドウがあり、大量の入力を処理することが難しい場合があります。AI.AGG() は、入力行を自動的にバッチに分割し、それらのバッチを集計した後、その集計結果を最終的な回答としてまとめることで、この問題を解決します。つまり、大量の行を渡す際に、コンテキストウィンドウを手動で管理する必要はありません。なお、AI.AGG() は、データの行を複数のバッチに分割することはありません。そのため、行がスキップされないように、各行がコンテキストウィンドウよりも小さくなるようにしてください。行数が多く、かつ各行が小さいほど、AI.AGG() は各行のバッチ処理においてより柔軟に対応できます。

2. マルチレベル集計におけるトークン使用量 AI.AGG() はマルチレベルの集計構造を使用するため、モデルに送信される入力トークンの合計数は、開始テーブルの元のトークン数よりも多くなる場合があります（必要な集計のラウンド数によって異なります）。ベストプラクティスとして、LIMIT を使用するか、データを AI.AGG() に渡す前に上流で事前フィルタリングすることで、トークン数を常に減らすようにしてください。

3. モデルエンドポイントの指定モデルエンドポイントを指定しない場合、AI.AGG() はデフォルトで最新のモデルを使用します。ただし、本番環境のパイプラインでは、多くの場合、明示的な制御が必要となります。

短縮形の名称: 短縮形のエンドポイント（例: gemini-2.5-flash）を使用できます。その場合、AI.AGG() はクエリ実行リージョンでそのモデルを使用します。

code_block: <ListValue: [StructValue([('code', "AI.AGG(\r\n input_data,\r\n instructions => '指示をここに入力します。',\r\n endpoint => 'gemini-2.5-flash'\r\n)"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa43416c6d0>)])]>

完全修飾名: 希望するモデルがクエリ実行リージョンで対応していない場合、またはグローバルエンドポイントやマルチリージョンエンドポイントを使用する場合は、モデルを完全修飾名で指定します。

code_block: <ListValue: [StructValue([('code', "AI.AGG(\r\n input_data,\r\n instructions => '指示をここに入力します。',\r\n endpoint => 'https://aiplatform.googleapis.com/v1/projects/[YOUR_PROJECT]/locations/global/publishers/google/models/gemini-3.5-flash'\r\n)"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa43416c6a0>)])]>

4. 入力と出力のモダリティ

入力: AI.AGG() では、テキスト（文字列またはテキストファイルへの参照）と画像データに対応しています。これらの型の配列にも対応していますが、既知の問題に関するドキュメントをご参照のうえ、画像の配列に関するエッジケースの注意事項をご確認ください。
出力: この関数は常に文字列を返します。モデルに対して、JSON や Markdown の形式で出力するようにプロンプトで指示することは可能ですが、このことがデータベースエンジンで厳密に適用されるわけではないことにご注意ください。マルチモーダル出力（画像の生成など）は、現在対応していません。

5. NULLの処理AI.AGG() は、NULL の入力行を処理せずに自動的にスキップします。ただし、構造化データを渡す場合は注意が必要です。他の BigQuery AI 関数のように、AI.AGG() は標準の CONCAT() 関数と同様に STRUCT フィールドを連結します。つまり、STRUCT 内のフィールドが 1 つでも NULL である場合、その行全体が NULL として扱われ、スキップされます。

最初のカテゴリのクエリをもう一度見てみましょう。たとえば、products テーブルのいくつかの行で description が欠落している場合、NULL の連結ルールにより、これらの行は何の警告もなく分析から完全に除外されてしまいます。以下に、IFNULL() を使用してフォールバック文字列を指定し、説明が空白であってもすべての商品が確実に考慮されるようにする方法を紹介します。

code_block: <ListValue: [StructValue([('code', "-- 商品名と説明（オプション）から商品のカテゴリを特定する\r\nSELECT\r\n AI.AGG(\r\n ('商品: ', product_name, ' - 説明: ', IFNULL(description, '説明なし')),\r\n 'これらの商品の主なカテゴリは何ですか？'\r\n ) AS category_description\r\nFROM\r\n `bigquery-public-data.cymbal_pets.products`;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa43416cdc0>)])]>

6. エラー処理 AI.AGG() は、無効な入力を受け取った場合や LLM 処理中にエラーが発生した場合に、部分的な結果を提供しようとします。無効な入力を含む行や、LLM モデルによって拒否された行は、最終結果には反映されません。

AI.IF() などのスカラーマネージド AI 関数と同様に、BigQuery ジョブの統計情報を確認することで、処理に失敗した行数を正確に把握できます。

生成 AI 関数エラーの詳細情報の例。

お試しください

上記は、非構造化データの分析に役立つ AI.AGG() の機能のほんの一例です。現在、AI.AGG() 関数は、すべての BigQuery ユーザー向けにプレビュー版として提供しています。ぜひ、ご自身のユースケースでお試しください。

また、BigQuery の他のマネージド AI 関数（AI.CLASSIFY()、AI.IF()、AI.SCORE()）や、AI.GENERATE() などの汎用関数もぜひお試しください。皆様がこれらの関数を活用してどのような成果を達成されるのか、今後を楽しみにしています。

- ソフトウェアエンジニア、Thomas Anchor

- デベロッパーアドボケイト、Alicia Williams

Alphaevolve で分子発見を 4 倍に高速化した Schrödinger の事例

Mon, 06 Jul 2026 19:00:00 +0000

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

計算化学の研究者は、従来より、分子間相互作用をシミュレートする際に、精度を犠牲にする高速な古典的力場を使用するか、大規模なジョブでは実行速度が遅すぎる高精度の量子力学的手法に頼るかという、悩ましいトレードオフに直面してきました。

ML 力場（MLFF）は、高忠実度の量子データでニューラルネットワークをトレーニングすることで、そのギャップを埋めます。しかし、現代の創薬や材料設計では、膨大な化学ライブラリを処理するために、さらに高速な処理速度が求められています。このようなパフォーマンスの制約を克服するために、Schrödinger は Google Cloud と提携して AlphaEvolve をデプロイしました。これは Google DeepMind が開発した進化型 AI コーディングエージェントで、アルゴリズムのボトルネックを克服する最も効率的なコードパスを見つけるために、アルゴリズムを繰り返し生成して改良します。

AlphaEvolve とのコラボレーション

30 年以上にわたり科学ソフトウェアの開発をリードしてきた Schrödinger は、MLFF トレーニングパイプライン内でパフォーマンスを制限する重要なアルゴリズムとして、近傍リスト計算法とエバルト総和法の 2 つを特定しました。これらのアルゴリズムは、原子の近傍からのデータを集計して長距離ポテンシャルを計算しますが、どちらもトレーニングと推論の速度において制限要因となっていました。

Schrödinger の技術面での最大の目標は、エネルギーと力の計算のための AI モデルのトレーニングを高速化することでした。具体的には、分子力学で使用される、重要ではあるものの計算負荷の高い機能であるエバルト総和法をターゲットとしました。Schrödinger の PyTorch コードにおいて、エバルト総和法が主なパフォーマンス上の制約となっていました。ベクトル化されたアルゴリズムは確立されておらず、通常は単純な for ループに頼っていたため、大規模なシミュレーションでは処理が遅くなっていました。

AlphaEvolve をモデルに組み込むことで、システムは並列バッチ行列乗算を使用して、エバルト総和法のバッチ実装を生成できるようになりました。これにより、PyTorch コードが進化し、既存のカスタムカーネルを上回るパフォーマンスを実現できました。

評価指標

Schrödinger は、厳格な多層的評価フレームワークを使用して、進化したコードがパフォーマンスと科学的正確性の両方を備えていることを確認しました。

逆時間（主要指標）: 計算時間をベースラインスコア 7.9 から短縮して、スループットを最大化することが主な目標でした。
機能的正確性: 進化したプログラムはすべて、無秩序水モデルなどの複雑なシステムに対する回帰テストを含む、完全なテストスイートに合格する必要がありました。
成功率: 機能的に正確で、ベースラインよりも高速なプログラムの割合で測定しました。

「AlphaEvolve を使用することで、これまでよりも迅速かつ効率的に、より広範な化学空間を探索できるようになりました。MLFF 推論の高速化は、創薬、触媒設計、材料開発における研究開発サイクルを短縮し、企業が分子候補のスクリーニングを数か月ではなく数日で完了できるようにすることで、ビジネスに現実的な効果をもたらします。」- Schrödinger、ML テクニカルリード、Gabriel Marques 氏

結果: 4 倍の高速化とボトルネックの解消

AlphaEvolve を適用することで、Schrödinger はエバルト総和法のコード内の単純な for ループを並列バッチ行列乗算に置き換えました。この最適化により、プログラムの成功率は 1% 未満（5,000 件の評価のうち 40 件）から 60% 以上に向上し、パフォーマンス指標はベースラインの 7.9 から 30 近くまで改善されました。

これらの基本的なアルゴリズムを最適化することで、MLFF のトレーニングと推論の両方で 4 倍の高速化が実現しました。この高速化により、研究者は分子スクリーニングのタイムラインを短縮できます。これは、いくつかの重要な研究分野に直接的なメリットをもたらします。

創薬: 緊急の医療ニーズに対応するため、有望な治療候補を迅速に特定できます。
触媒設計: 産業用途向けに効率的な化学プロセスを開発できます。
材料開発: 電子機器やエネルギー貯蔵向けに、カスタムプロパティを持つ次世代材料を設計できます。

次なる進化

Schrödinger は、この進化的なアプローチをカスタム GPU カーネルに適用し、AI によって生成されたコードが、人間が設計した実装よりも優れているかどうかをテストする予定です。

進化型 AI エージェントが科学的なコードベースを最適化する方法については、AlphaEvolve に関する技術論文の全文をお読みください。また、研究ワークフローの高速化についてご相談されたい場合は、Google Cloud AI チームにお問い合わせください。

- Google、プログラムマネージャー、Kartik Sanu

- Google、グループ AI プロダクトマネージャー兼エンジニア、Anant Nawalgaria

Cloud Network Insights: クロスクラウドネットワークに対するエンドツーエンドのオブザーバビリティ

Fri, 03 Jul 2026 03:00:00 +0000

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

昨今のデジタル環境では、ネットワークは単一のデータセンターや一つのクラウドプロバイダの範囲に制限されません。クロスクラウド戦略を採用し、Google Cloud ワークロードをオンプレミス環境、AWS や Azure などの他のクラウド、インターネットに接続されたさまざまなアプリケーションに接続させる企業が増えています。この柔軟性はイノベーションを促進する一方で、運用上の複雑さを大幅に増大させる可能性もあります。アプリケーションのパフォーマンスが低下した場合、原因はネットワーク、アプリケーション、それとも他のどこにあるのかという重要な疑問が生じます。

このたび、Cloud Network Insights の一般提供が開始されました。すぐに使用できる Google Cloud ネイティブのソリューションである Cloud Network Insights は、複雑なマルチクラウド環境とハイブリッド環境全体でネットワークとデジタルエクスペリエンスのパフォーマンスを包括的に可視化します。

アクティブなモニタリングで可視性のギャップを解消

Broadcom AppNeta とのパートナーシップにより提供される Cloud Network Insights は、オブザーバビリティを Google Cloud の枠を超えてグローバルなデプロイ全体に拡大します。アクティブな合成プローブの利用によりユーザートラフィックがない場合でもネットワークルートをモニタリングできるため、事後対応ではなく予防的なモニタリングを可能にします。

クラウド、オンプレミスのデータセンター、インターネットアプリケーション、ISP、ラストマイル接続など、パフォーマンス低下の原因がどこにあるとしても、Cloud Network Insights を使用すればボトルネックの正確な場所を特定できます。

Cloud Network Insights は Google Cloud Observability スイートに直接統合されるため、高度なネットワークインテリジェンスを既存のツールに組み込むことができます。Cloud Network Insights は、次の機能を提供します。

エンドツーエンドのネットワークパスの可視性: 送信元と宛先の間のネットワークパスをホップバイホップ方式で可視化します。直接管理していないネットワークにおけるラウンドトリップ時間（RTT）、パケットロス、ジッターなどの重要な指標をモニタリングします。
デジタルエクスペリエンスに関する分析情報: ネットワーク層を超えて、ウェブアプリケーションのデジタルエクスペリエンスをモニタリングします。DNS の解決時間、HTTP レスポンスコード、ブラウザのページ全体の読み込み時間を測定して、アプリケーションのパフォーマンス低下がネットワークによるものか、アプリケーション自体によるものかを特定します。
プロアクティブな検出とアラート: シンセティックテストを使用して、顧客に影響が及ぶ前にパフォーマンスの低下を特定します。アラームは Cloud Monitoring および Cloud Logging と統合されており、メール、Slack、PagerDuty 経由でアラートを送信できます。
SLA の検証: ISP やサービスプロバイダがパフォーマンスのコミットメントを満たしているかを検証するのに必要なデータをチームに提供します。
迅速な根本原因分析: ネットワークの問題、アプリケーションレベルの問題、ブラウザのパフォーマンスへの影響をすばやく区別できます。
統合モニタリング: Google Cloud 内から直接指標とログにアクセスし、Cloud Monitoring と Cloud Logging を活用してダッシュボードとアラートを提供します。Google Cloud のオープンなパートナーエコシステムと、指標とログに利用される OpenTelemetry プロトコルのサポートを利用して、OTel SDK とコレクタによる直接取り込みを可能にします。
エージェントワークロードのモニタリング: シンセティックテストを使用して、接続とネットワークパフォーマンスをモニタリングし、エージェントとツールへの接続を最適化します。

Google Cloud、AWS、Azure との間のネットワークパフォーマンスとマルチパスルートを 1 つのビューで確認

仕組み: アクティブな合成プロービング

Cloud Network Insights は、3 つの主要コンポーネントで構成されるアクティブな合成プローブ技術を使用します。

モニタリングポイント: モニタリングポイントと呼ばれる軽量のソフトウェアエージェントを、中央 VPC、リモートブランチ、オンプレミスデータセンターなどの重要なネットワークセグメントにデプロイします。モニタリングポイントはコンテナまたは仮想マシンとしてデプロイできます。
合成プローブ: モニタリングポイントは、合成トラフィック（ユーザーまたはアプリケーションをシミュレート）の小さなバーストを頻繁にターゲットの宛先に送信します。これにより、ネットワーク上にユーザーが存在しない場合でも、24 時間 365 日パフォーマンスをモニタリングできます。
データ同期: モニタリングポイントは、リアルタイムのパフォーマンステレメトリーを中央のバックエンドサービスに送信します。このデータは Google Cloud に同期され、指標は Cloud Monitoring にエクスポートされ、アラームとイベントは Cloud Logging に送信されます。

核となる機能

Cloud Network Insights は、インフラストラクチャの全体像を把握するために、主に次の 2 種類のモニタリングをサポートしています。

1. ネットワークパフォーマンスのモニタリング（レイヤ 3 と 4）

これにより、送信元と宛先の間のネットワークをホップバイホップ方式で可視化できます。

取得される指標: ラウンドトリップ時間（RTT）、パケットロス、ジッター、パスの変更。
シングルエンドモード: エージェントは、モニタリングポイントがインストールされていない外部ターゲット（URL、IP アドレス、API エンドポイントなど）をプローブします。
デュアルエンドモード: モニタリングポイントが別のモニタリングポイントをプローブします。これにより、一方向のレイテンシの正確な把握と非対称ルーティング（データが送信時と受信時で異なるパスを通る場合）の検出が可能になり、より豊富なデータが提供されます。

Google Cloud コンソールに表示されたネットワークパス指標

2. デジタルエクスペリエンスモニタリング（レイヤ 7）

デジタルエクスペリエンスモニタリングを使用すると、ウェブアプリケーションのエンドツーエンドのエクスペリエンスを追跡できます。ここでは、次のいずれかを選択できます。

ブラウザモード: 実際のブラウザエンジン（Selenium）を使用してウェブページ全体を読み込み、JavaScript を実行してコンテンツをレンダリングします。ページの読み込み時間を完全に測定し、実際のユーザーエクスペリエンスを検証します。
HTTP モード: 合成 HTTP/S リクエストを URL または API エンドポイントに送信します。これにより、サーバーの可用性、レスポンス時間、DNS / TLS パフォーマンスの軽量なチェックを行います。

インテリジェンスと自動化

Cloud Network Insights には、さまざまなモニタリング機能とトラブルシューティング機能も用意されています。

プロアクティブなアラーム: Cloud Network Insights は自動ベースライン設定を利用し、過去の指標データに基づいてパフォーマンスしきい値を動的に設定します。定義されたパラメータから指標が逸脱すると、システムは Google Cloud でイベントを即座にトリガーし、メール、Slack、PagerDuty を介してアラートをチームに直接ルーティングします。
モニタリングポリシー: カスタムタグに基づいてパスを動的に作成または削除するポリシーを定義することで、大規模な環境全体でモニタリング設定を自動化できます。たとえば、主要なウェブアプリケーションのパフォーマンスを特定の地理的地域から自動で追跡できます。
根本原因分析: Cloud Network Insights は、ISP やトランジットネットワークなど、従来は「監視対象外」だった領域まで可視性を拡張するため、速度低下が Google Cloud 内で発生しているのか、ISP レベルで発生しているのか、AWS や Azure などの別のクラウド環境内で発生しているのかを即座に特定できます。
AI による分析情報: Gemini Cloud Assist との統合により、自然言語を使用して、より広範なインフラストラクチャデータとともに Cloud Network Insights テレメトリーを調査できます。ダッシュボードを手動で切り替えるのではなく、Gemini に Cloud Network Insights の特定の指標と他の Google Cloud の指標を相互参照させることで、平均解決時間（MTTR）を短縮します。

お客様の声

Cloud Network Insights に対しては、クロスクラウド運用を簡素化したいと考えているお客様からすでに大きな関心が寄せられています。すでに Sabre や Pexip などの組織は、ハイブリッド環境の透明性を高める目的で Cloud Network Insights を活用しています。

「Sabre のように複雑かつハイスケールな環境では、完全な可視性は単なる贅沢品ではなく、運用のレジリエンスを確保するための不可欠な要件です。Cloud Network Insights を使用することで、プロアクティブな最適化をさらに推進できます。グローバルなクラウドフットプリント全体にわたってきめ細かいリアルタイムのテレメトリーを提供することで、従来のネットワークの『ブラックボックス』を解消し、旅行者のエクスペリエンスに影響を与える前にチームがボトルネックを解決することを可能にします。」- Sabre、クラウドおよびインフラストラクチャ担当バイスプレジデント、Alfredo Rodriguez 氏

「Cloud Network Insights は、企業のプライベートネットワークとパブリッククラウドとの間の『可視性のギャップ』を埋め、共通のお客様がパフォーマンスのボトルネックを数時間ではなく数秒単位で特定することを可能にします。」- Broadcom、CIO、Alan Davidson 氏

Cloud Network Insights でネットワークの健全性を向上させた Pexip

使ってみる

複雑なデジタルエコシステムに対応するために可視性を犠牲にする必要はありません。Cloud Network Insights は、詳細なネットワークパフォーマンス指標とデジタルエクスペリエンスモニタリングを組み合わせることで、マルチクラウド環境とハイブリッド環境のギャップを埋めます。Google Cloud Observability と Gemini Cloud Assist に直接統合されているため、チームはインテリジェントなアラート、堅牢な SLA 検証、迅速な根本原因分析を利用できます。Google は、お客様がクロスクラウドネットワークの全体像をより明確に把握できるよう今後も支援を続けていきます。

Google Cloud コンソールで今すぐご利用いただけます。詳しくは、以下の資料をご参照ください。

モニタリングポイントのデプロイとポリシーの構成について詳しくは、プロダクトドキュメントをご覧ください。
最新のリリースノートで新機能に関する最新情報を確認できます。
概要動画を見る
Google Cloud と Broadcom のパートナーシップについて詳しくは、以下をご覧ください。

- プロダクトマネージャー、Poonam Yadav

お客様とのコラボレーションが切り拓く、Model Armor による生成 AI セキュリティの未来

Fri, 03 Jul 2026 02:00:00 +0000

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

Google Cloud では、最高のプロダクトはお客様とのパートナーシップを通して構築されると考えています。お客様からのフィードバックや実際の経験は、Google のサービスを改良し、お客様の実際のニーズを満たすソリューションを提供するうえで非常に貴重です。2026 年 1 月、Google Cloud デベロッパーアドボカシーチームは、Google Cloud の大手顧客であり、通信業界のリーダーでもある企業との高ベロシティな技術スプリントに参加しました。

この共同作業を通じて得られた深いインサイトは、生成 AI およびエージェント AI 向けランタイムセキュリティサービスである Model Armor の情報エクスペリエンスを大幅に向上させる原動力となりました。

「徹底した当事者意識」による生成 AI 導入の加速

この取り組みの目的は、Google Cloud の Agent Development Kit（ADK）と Agent Platform を使用して構築された、次世代の生成 AI カスタマーサポートプラットフォームの運用化を支援することでした。お客様の開発者やセキュリティスペシャリストと直接対話することで、開発者が複雑なライブ環境で Gemini Enterprise Agent Platform をどのように操作しているかを観察するという貴重な機会を得ることができました。

この経験は、従来のドキュメント作成サイクルからは決して得られない、徹底した当事者意識をもたらしました。開発者が作業する際の摩擦ポイントを一つひとつ記録していくことで、機能的障害をリアルタイムの技術的インサイトへと変換し、曖昧な構成ガイダンスや詳細情報の欠如によって開発者が作業を妨げられている部分を正確に特定しました。

現場で得られた重要な知見

開発ワークフローを直接見せていただくことで、4 つの重要な摩擦ポイントを特定できました。

検索ファーストのワークフロー: 開発者がドキュメントの階層構造を順に辿ることは稀です。それよりも検索を駆使して、目的のコード例へ直接ジャンプすることがほとんどです。PII の秘匿化など、一般的なユースケースに対応する包括的でコピー＆ペースト可能なスニペットがないことが主な摩擦ポイントとなっていました。
信頼レベルの最適化: 包括的な脅威検出と、業務の妨げとなる誤検出の抑制との適切なバランスを見出すことは、想像以上に困難でした。たとえば、「低以上」といった厳格な設定を適用すると、本来スムーズであるべきカスタマーサポートの流れを止めてしまうような誤検出が頻発する結果となりました。
きめ細やかなガイダンスの必要性: Model Armor の基本コンセプトは理解されているものの、セキュリティと利便性を両立させるためのさまざまな適用方法が実務レベルでどう機能するのかに関する、より具体的な詳細情報が必要とされていることがわかりました。
インテグレーションを阻む壁（403 エラー）: Model Armor を Apigee などのサービスと連携させる際、開発者は 403 PERMISSION_DENIED エラーという壁に何度も突き当たっていました。これは、既存ドキュメントにサービスをまたぐ IAM ロールや権限の設定に関する説明が不足していたことを浮き彫りにしました。

知見を実践的に活用

このパートナーシップから得られた知見は、Model Armor のドキュメントとガイダンスの包括的な見直しにすぐに活かされました。

テスト済みのコピー＆ペースト可能なコードサンプル: 検索ファーストのワークフローに対応するため、ドキュメント全体にテスト済みのすぐに使用できるコードサンプルを多数追加しました。
信頼レベルのマトリックス: フィルタレベルごとのトレードオフをユーザーが直感的に把握できるよう、新たな技術リファレンスを追加しました。一般的なコンテンツについては、誤検出を最小限に抑えるために「高」または「中」のしきい値が推奨されることを明記しました。一方、「低以上」の設定は、プロンプトインジェクションやジェイルブレイク検出などの重大なセキュリティ脅威に限定して使用することを推奨しています。
明示的なインテグレーションガイド: Apigee、Gemini Enterprise Agent Platform、GKE に焦点を当ててインテグレーションガイドを更新しました。新しいガイドでは、スムーズでエラーのないデプロイにするために必要な特定の IAM ロール（roles/modelarmor.user など）が明示されています。
技術ドキュメントの拡充: 適用方法と現実世界におけるその応用例について、より深く踏み込んだ解説を追加してドキュメントを強化しました。

パートナーシップの力

今回は実際にお客様と「同じ部屋で過ごす」ことで、技術的な正確さと運用上の有用性のギャップを埋めることができました。こうした共創の取り組みにより、Model Armor はお客様の成功を後押しする確かな原動力へと進化していきます。更新されたドキュメントをぜひご覧いただき、皆様のフィードバックをお寄せください。生成 AI ワークロード向けの最も安全なプラットフォームを目指して、Google はこれからも進化を続けてまいります。

使ってみる:

更新された Model Armor ドキュメントを確認する

- Google Cloud、テクニカルライター Darshana Bhangare

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

Cloud Blog JA

セガサミーホールディングス: Google Security Operations と Google Threat Intelligence を導入し、セキュリティ対策をグローバルで標準化へ

"個別最適" がもたらした、セキュリティ管理・運用体制の構造的課題

ログを蓄積するだけの運用から、インテリジェントな活用へ

SecOps と Google Threat Intelligence による管理体制を世界 80 拠点で標準化

エージェンティック エンタープライズに関する 20 の質問（Agent Platform がどのように役立つか）

構築フェーズ — 基盤の確立

スケーリング フェーズ - 接続性と相互運用性

最適化フェーズ — 信頼と効率

ガバナンス フェーズ - セキュリティと監視

今すぐ始めましょう

Gemini Enterprise と Google Cloud Marketplace でエージェントを公開するためのデベロッパー ガイド

ステップ 1: Marketplace との統合を想定して、エージェント アーキテクチャを設計する

ステップ 2: Marketplace で販売するための組織の要件を確認する

ステップ 3: Marketplace および Gemini Enterprise app との互換性のための技術要件を確認する

A2A プロトコル

A2A エージェント カード

認証と認可

ステップ 4: Marketplace でエージェントを掲載、公開する

ステップ 5: Marketplace と Gemini Enterprise app におけるトランザクション / 登録の管理

実際にやってみる

レポート: 83%の組織がエージェント型 AI に対応するためにインフラストラクチャのアップグレードを必要としている

フルイド コンピューティングで「推論税」から脱却する

一元化されたガバナンスでエージェントの乱立を管理する

統合データレイヤ

ハイブリッド マルチクラウドとデジタル主権

AI に最適化された統合インフラストラクチャ

デジタル世界と現実世界をつなぐ

エージェント型 AI のための設計指針

Google Cloud 認定資格を最新の状態に保ち、キャリアアップを図る新しい方法

試験を新たな形で

今すぐ再認定を受けましょう

生きたクルデンシャル

Google Cloud 向け Claude アプリ ゲートウェイを使ってみる

ゲートウェイを実行すべき理由

連携の仕組み

Google Cloud での設定

次のステップ

Cloud Monitoring: 動的しきい値と 2 年間のルックバックを活用したアラートによる異常検出

長期ルックバックと動的しきい値の導入

動的しきい値のアルゴリズム

動的しきい値を使用して費用の急増を抑制する

デザイン パートナーにご登録ください

エージェントでギアを上げる: ソフトウェア定義車両のセキュリティを確保

Nexus SDV での AI 主導のエクスペリエンス

クラウドネイティブな仕組み

Google Cloud のセキュリティ管理機能による多層防御

Nexus SDV の利用を始める

Google、2026 年 Gartner® Magic Quadrant™ で分析およびビジネス インテリジェンス プラットフォーム部門のリーダーに 3 年連続で選出

ユニバーサル セマンティック レイヤ エージェント

Gemini の推論機能を利用

Looker と Gemini でエージェント型 BI の時代へ飛躍

AI エージェント事例アワード開催！ 指示するから、自律する AI へ。

スケジュール

評価基準

表彰内容

Google AI Studio のスターター ティアの解説

スターター ティアの概要

提供内容: 事前構成済みのスタック

Cloud Run

Firebase Authentication

Cloud Firestore

Cloud SQL for PostgreSQL デベロッパー エディション

プロンプトの入力から一般公開 URL の取得までの 5 つのステップ

スターター ティアとの比較

制限に備える

サンドボックスからの移行

日立「Gemini Enterprise 活用コンテスト」開催レポート ― 112 件の応募から選ばれた、現場を変える 10 の AI エージェント

112 件の応募から、現場発の 10 組が登壇

現場の「困った」から生まれた 10 のエージェント

受賞した 5 組と、審査員からの言葉

これからも、日立の挑戦とともに

AlloyDB AI 関数 - 革命的なパフォーマンス向上と費用削減を実現

LLM の力をデータに: 大幅な高速化とコスト削減を実現

デモのご紹介

始め方は簡単

選択、コンプライアンス、コラボレーション: 欧州のオープンなデジタル主権への道

1. 主権認証の改善

2. 相互運用性の促進、ベンダー ロックインの防止、調達の改革

3. 欧州の AI の未来に向けたサステナブルでオープンなインフラストラクチャの構築

エージェンティックエンタープライズに関する 20 の質問（Agent Platform がどのように役立つか）

スケーリングフェーズ - 接続性と相互運用性

ガバナンスフェーズ - セキュリティと監視

Gemini Enterprise と Google Cloud Marketplace でエージェントを公開するためのデベロッパーガイド

ステップ 1: Marketplace との統合を想定して、エージェントアーキテクチャを設計する

A2A エージェントカード

フルイドコンピューティングで「推論税」から脱却する

ハイブリッドマルチクラウドとデジタル主権

Google Cloud 向け Claude アプリゲートウェイを使ってみる

デザインパートナーにご登録ください

Google、2026 年 Gartner® Magic Quadrant™ で分析およびビジネスインテリジェンスプラットフォーム部門のリーダーに 3 年連続で選出

ユニバーサルセマンティックレイヤエージェント

AI エージェント事例アワード開催！指示するから、自律する AI へ。

Google AI Studio のスターターティアの解説

スターターティアの概要

Cloud SQL for PostgreSQL デベロッパーエディション

スターターティアとの比較

2. 相互運用性の促進、ベンダーロックインの防止、調達の改革

GKE で Ray Serve LLM をスケーリング: デベロッパーエクスペリエンスを損なうことなくパフォーマンスを向上

Nano Banana 2 Lite でより高速なビジュアルエクスペリエンスを構築している業界のリーダー

AI.AGG() の仕組みとベストプラクティス

Cloud Network Insights: クロスクラウドネットワークに対するエンドツーエンドのオブザーバビリティ