AI & 機械学習

Airtel、2026 年インディアンプレミアリーグのクリケット中継を完璧に配信

Fri, 18 Sep 2026 02:00:00 +0000

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

インディアンプレミアリーグ（IPL）の何百万人もの熱狂的なファンにとって、クリケットのライブ配信を完璧な状態で視聴できることは絶対条件です。世界最大規模の同時視聴者数を誇るリーグのテレビ放送を制作する Airtel にとって、パケットのドロップやバッファリングは、決してあってはならないことです。

IPL 2026 のシーズン中、Airtel は Google Cloud と提携して、このデジタル配信に対応しました。このストリーミングインフラストラクチャが 74 試合にわたって配信した外向きデータは数百ペタバイトに及びます。決勝戦だけで数百億件のリクエストが処理され、ピーク時の外向きトラフィックは数 Tbps に達しました。

このような同時接続数の急増に対応して動画を配信するには、ローカル化を徹底追及したエッジアーキテクチャと、プロアクティブな運用モニタリングを組み合わせる必要があります。

IPL 2026 の目標は、同時接続数の急増やネットワークの状況にかかわらず、インド全土のクリケットファンに、スタジアムにいるかのようなスムーズな視聴体験を提供することでした。Airtel は、Google Cloud と提携して Media CDN を使用することで、ローカルエッジへの近接性と優れたキャッシュ効率を実現できました。そして、これを試合当日のプロアクティブなリアルタイムモニタリングと組み合わせることで、最初から最後まで信頼性の高いブロードキャスト体験を提供できました。

同時接続数とエッジ効率を考慮した設計

スポーツのライブ配信における主な課題の一つは、トラフィックの急増をシームレスに処理し、ストリーミングのパフォーマンスを低下させたり、バックエンドの配信元に過剰な負荷をかけたりしないことです。最終オーバーは何百万人もの視聴者が同時に視聴します。1 ミリ秒が勝負を分けるため、この点が特に重要となります。

Airtel は、インドの多様な ISP 環境にわたってコンテンツ配信を高速化するために、Google Cloud の Media CDN を利用しました。Google の広範なグローバルエッジネットワークを活用することで、エンドユーザーに物理的に近いエッジロケーションから視聴者のリクエストを処理できるようになります。この徹底したローカル化が、ブロードキャストの成功の礎となりました。インド国内からローカル配信されたトーナメントのトラフィックは 99.9% にも及びます。

この効率的なアーキテクチャにより、ネットワークホップが最小限に抑えられ、トランジットの輻輳が軽減されました。その結果、全 74 試合にわたりインフラストラクチャと視聴者エクスペリエンスの指標が大幅に向上しました。

優れたキャッシュ効率: キャッシュヒット率が全体的に 98% を超えました。大量の視聴者トラフィック負荷をエッジで効果的に吸収することで、プレーオフの視聴者数がピークに達したときでも、配信元サーバー / 動画プラットフォームに対する需要は最小限に抑えられました。
一貫した超低レイテンシ: Airtel はトーナメント中に 300 ミリ秒未満の p99 レイテンシを維持しました。その結果、ストリーミング開始までの時間が短縮され、試合の重要な場面でのバッファリングのリスクが最小限に抑えられました。

運用準備のためのプロアクティブな戦略

インテリジェントなバックエンドアーキテクチャの維持は、Airtel の IPL ストリーミング戦略において極めて重要なことでしたが、それだけでは不十分でした。全 74 試合連続で一発勝負のライブ配信を行うには、入念な運用準備と、試合当日のプロアクティブな対応も必要でした。

Airtel と Google Cloud は、最初の試合が始まるずっと前に潜在的なボトルネックを特定する必要があることを認識し、緊密に統合された運用サポートモデルを確立しました。

トーナメント前のサポート準備状況の確認: 開幕戦のかなり前に、共同エンジニアリングチームが包括的なサポート準備状況の確認を実施しました。チームは、トラフィック予測の監査、マニフェスト構成の確認、フェイルオーバーメカニズムの検証を早期に実施することで、クライアントが堅牢な準備態勢を整えられるようサポートし、結果的にトーナメント中の運用上の摩擦を軽減しました。
Monitoring as a Service（MaaS）: チームは、Media CDN 上の MaaS を通じて継続的かつプロアクティブなテレメトリーモニタリングを維持しました。リアルタイムのオブザーバビリティにより、異常が視聴者の再生に影響を与える前にネットワークの変化を早期に検出して軽減できました。
試合日と週末の専用サポート: スポーツのライブ配信は通常の営業時間内に行われるとは限らないため、Airtel はすべての試合を対象とした包括的なモニタリングプロトコルを確立しました。週末の重大な試合や、命運をかけたプレーオフのステージでは、Google Cloud のテクニカルアカウントマネジメントチームと MaaS チームが Airtel のエンジニアリングチームと緊密に連携して、専任でリアルタイムのイベントサポートを提供しました。

優れたライブ配信のためのブループリント

Airtel が IPL 2026 のストリーミングに成功したことで、膨大な同時接続数への対応には、アーキテクチャ、エッジのローカル化、運用ガバナンスにわたる統合戦略が不可欠であると実証されました。Airtel は、98% 以上のキャッシュヒット率、99.9% のローカル配信、試合当日のプロアクティブなモニタリングを組み合わせることで、大規模なライブスポーツ放送のベンチマークを達成しました。

このデプロイメントは、同時接続数が多いイベント向けにライブメディア配信をスケールする際の技術アーキテクチャと運用戦略の全体像を示します。ライブ配信とエッジ配信の最適化について詳しくは、Media CDN のデベロッパー向けドキュメントをご覧ください。

-Hitesh Bhatia, Assistant Vice President and Head of Engineering, Airtel Digital

-Anand Vijayan, Senior Product Manager, Media CDN, Google Cloud

Google、2026 年 Gartner® Magic Quadrant™ エンタープライズ AI アシスタント部門のリーダーに選出

Wed, 16 Sep 2026 02:00:00 +0000

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

このたび、新設された 2026 年 Gartner Magic Quadrant エンタープライズ AI アシスタント部門で、Google がリーダーに選出されました。エンタープライズ AI アシスタントの主要ベンダーを対象としたこの包括的な評価において、Google は「ビジョンの完全性」と「実行能力」の両面で「リーダー」のクアドラントに位置付けられました。

Gemini Enterprise は、組織が従業員の日常業務に役立つ安全な AI を直接導入できるよう支援しています。組織内の各チームは、基本的なチャット操作からさらに先に進み、複数ステップのエンドツーエンドワークフローを AI エージェントによって自動化できます。Gemini Enterprise は、会社がすでに使用しているツールやインフラストラクチャと接続し、セキュリティとガバナンスを確保しながら、費用対効果の高い方法で簡単にスケールできます。

Google は、ビジネスユーザーからデベロッパーまで、誰もが AI エージェントと連携してより多くの成果を上げることができる統合プラットフォームの構築を目指してきました。Gartner による今回の評価は、この目標の妥当性を裏付けるものだと考えています。

Google がリーダーに選出された理由

スタンドアロンの AI ツールや新しいプラットフォームが複雑に絡み合う状況の中で、Gemini Enterprise は Google の AI スタック全体を基盤とする統合されたオープンなエージェントプラットフォームとして登場しました。レポートでは、次のような強みが挙げられています。

統合された「AI のフロントドア」: Gemini Enterprise は、エンタープライズ向けのチャットと検索、ファーストパーティとサードパーティのエージェント、ノーコードのエージェントデザイナー、Google Workspace の統合、サードパーティのコネクタをすべて 1 つのプラットフォームに一元化したものであるため、組織は異なる AI ツールを組み合わせる必要がありません。
オープンな接続性: Gemini Enterprise は、Google のエコシステムだけでなく、Microsoft 365、その他のサードパーティソフトウェア、内部のエンタープライズデータソースにまで及ぶ広範な接続性を提供します。このオープンな接続性により、組織は既存のインフラストラクチャと並行して Gemini Enterprise を導入でき、費用のかかるシステムの全面見直しが不要となります。
シンプルな料金体系: Gemini Enterprise は料金モデルがわかりやすく、チャットや検索などの操作は基本 SKU に含まれます。組織は、ユーザーあたりのシートサブスクリプションと従量課金制オプションを選択できます。後者の場合、ユーザーはタスクの途中で割り当て上限に達することなくエージェントワークロードを実行できます。
組み込みのガバナンス: Gemini Enterprise は、追加費用なしですぐに使える堅牢なエージェントガバナンスを提供します。これにより、企業はセキュリティリスクとエージェントの無秩序な増加を抑制しながら、ユーザー、エージェント、データ権限をシームレスに管理できます。
フルスタックの深さと規模: Google の垂直統合型スタックは、グローバルインフラストラクチャ、カスタムシリコン、世界水準のモデル、エンタープライズに対応した安全な基盤を提供します。これらはすべて、セキュリティ、相互運用性、費用を考慮して最適化されています。

レポートの全文は、こちらからダウンロードしてお読みいただけます。

Gemini Enterprise の最新の機能強化でビジョンを推進

この数か月間、Google はプロダクトの大幅な機能強化で Gemini Enterprise をさらに進化させてきました。

業種別ソリューション: 先月、法律と金融サービスに特化したソリューションを公開しました。これらのカスタマイズされたソリューションは、事前構築済みのエージェント、その分野固有のスキル、安全なデータコネクタ、オープンなパートナーエコシステムを備え、迅速なデプロイが可能です。また、Gemini Enterprise の管理されたコントロールプレーン上に構築されているため、規制の厳しい業界でもワークフローを作成、管理できます。
Gemini Enterprise の Google Antigravity: Gemini Enterprise に AI デベロッパーツールが導入され、企業は対象となる Gemini Enterprise ライセンスにより、開発チーム向けに Antigravity や Android Studio などのエージェント型開発ツールを簡単に有効にし、管理コンソール内で完全なガバナンスとオブザーバビリティを維持できるようになりました。
FinOps と費用管理: 新しい FinOps と費用管理機能が先月導入され、組織はより多くの料金オプション、フレキシブル割引プラン、きめ細かい支出管理を通じて AI 支出を最適化できるようになりました。

Gemini Enterprise のお客様も価値を実感

Gartner からこのような評価を受けたことは光栄なことですが、Gartner だけでなく、お客様も実質的な価値を実感しており、それが日々、組織全体にプラスの影響を広げています。

最近のプロダクトの機能強化に対するお客様の声をお聞きください。

「Accenture では、Gemini Enterprise に Antigravity をデプロイすることで、Google Cloud の安全で信頼できる基盤上で、Google DeepMind の優れたテクノロジーをエンジニアに提供しています。運用の複雑さを抽象化することで、開発スピードとエンタープライズグレードのガバナンスのどちらかを選ぶ必要がなくなり、高速なエンジニアリングと革新的な価値をクライアントに提供できるようになりました。」- Accenture Google Business Group、グローバルプラクティスリード、Chetna Sehgal 氏。詳しくはこちらをご覧ください。

「Cleary は、戦略的かつ競争力のある方法で AI をワークフローに組み込むことに取り組んでいます。Google の Gemini Enterprise は、日々の業務で使用する他のツールとシームレスに連携できるため、チームの効率性を高め、クライアントにさらに質の高い成果物を提供できます。」- Cleary Gottlieb、マネージングパートナー、Jeff Karpf 氏。詳しくはこちらをご覧ください。

「金融リサーチエージェントのデザインパートナーとして、Deutsche Bank は、データ保護やガバナンスからチームが日々使用するワークフローまで、規制の厳しい業界の現実を考慮して、この機能の形成を支援してきました。」- Deutsche Bank、技術、データ、イノベーション最高責任者兼取締役、Marie-Jeanne Deverdun 氏。詳しくはこちらをご覧ください。

「Google Cloud と提携して、Gemini Enterprise for Legal を早期に導入できることを嬉しく思います。Google のテクノロジーを統合してワークフローを合理化し、クライアントの将来にとって重要な成果を形作るうえで訴訟担当者をさらにサポートできることを楽しみにしています。」- Williams & Connolly、会長、Joe Petrosinelli 氏。詳しくはこちらをご覧ください。

使ってみる

レポートを読む: 2026 年 Gartner Magic Quadrant エンタープライズ AI アシスタント部門を無料でダウンロードして、詳細な分析をご確認ください。
Gemini Enterprise の詳細を確認: 組織が、管理、接続されたエージェントをすべてのチームにデプロイする方法については、 cloud.google.com/gemini-enterprise をご覧ください。

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

Spanner への移行: Antigravity CLI で二重書き込みを自動化してサービス停止を最小限に

Mon, 14 Sep 2026 02:10:00 +0000

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

Google のファイナンスエンジニアリングチームは、レガシーデータレイヤーをモダナイズする必要が生じた際、グローバルに分散され、強整合性があり、高可用性機能を備えたマルチモデルデータベースである Spanner を選択しました。しかし、本番環境サービスをオフラインにせずに Spanner に移行することは、エンジニアリング上の大きな課題でした。アプリケーションを担当する社内チームとして、数十のデータアクセスオブジェクト（DAO）にわたって二重書き込みロジックを手動で書き換える必要がありましたが、このプロセスは時間がかかり、人的エラーが発生しやすいものでした。さらに、サービスを停止することなくこれを行うには、コードベース内のすべての DAO にわたって、マルチフェーズの二重書き込みアーキテクチャを実装する必要がありました。

この課題を解決するために、別のアプローチを採用しました。ヘッドレスモードの Antigravity CLI を利用した自動リファクタリングパイプラインを構築したのです。これにより、本番環境の準備を進めるなか、ステージング環境で厳格なデータパリティを維持しながら、移行速度を大幅に向上させることができました。

課題: 二重書き込みによる移行の仕組み

財務上の正確性が不可欠な高スループットの本番環境サービスを移行する場合、単純なカットオーバースクリプトは機能しません。過去のデータのバックフィルと検証がすべて完了するまで、レガシーデータストアと Spanner の両方が同じ書き込みを同時に受信することを確認する必要があります。

移行は、次の 3 つのフェーズに分けて実施しました。

過去のデータのバックフィル: 参照整合性を維持しながら、既存の過去のレコードを Spanner にコピーします。
二重書き込み / 二重読み取りの実装: 移行期間中に、すべての DAO を変更して、プライマリストアと Cloud Spanner の両方にミューテーションを並行して書き込みます。
自動化された API 検証とパリティチェック: RPC トラフィックをインターセプトし、すべての書き込みが両方のストアでバイト単位で同等に完了することをエンドツーエンドで検証します。

アーキテクチャパターンはクリーンですが、Google の規模では、摩擦が生じ始めました。これは、各 DAO に以下が必要なためです。

複雑なドメインモデルを Spanner スキーマ列にマッピングする専用の MutationConverter クラス
二重書き込みブランチの処理とロールバックまたはエラー報告のロジック
疑似時間ソースとテストダブル（FakeTimeSource）を使用して、プライマリと Spanner の両方の書き込みを検証する単体テストのスイート

30 以上の DAO にわたって、同一の高精度なコード変更を手作業で行っていたら、エンジニアリングに数か月を要していたでしょう。

解決策: 標準化されたミューテーションコンバータパターン

自動化パイプラインがクリーンなコードを確実に生成できることを検証するために、まず、分離された MutationConverter インターフェースを中心に DAO リファクタリングパターンを標準化しました。

中核的な DAO ビジネスロジック内に未加工の Spanner テーブル名と列割り当てを直接埋め込むのではなく、Spanner スキーマ変換を専用のコンバータユニットに分離します。

code_block: <ListValue: [StructValue([('code', '// Example of the standardized pattern generated by our pipeline\r\n\r\ntype BpcTransferAmountsMutationConverter interface {\r\n ToInsertMutation(entity *model.BpcTransferAmount) (*spanner.Mutation, error)\r\n ToUpdateMutation(entity *model.BpcTransferAmount) (*spanner.Mutation, error)\r\n}\r\n\r\ntype bpcTransferAmountsMutationConverterImpl struct {\r\n tableName string\r\n}\r\n\r\nfunc (c *bpcTransferAmountsMutationConverterImpl) ToInsertMutation(entity *model.BpcTransferAmount) (*spanner.Mutation, error) {\r\n if entity == nil {\r\n return nil, errors.New("entity cannot be nil")\r\n }\r\n \r\n // Map domain fields to Cloud Spanner table schema\r\n cols := []string{"TransferId", "AmountCents", "CurrencyCode", "LastModifiedTimestamp"}\r\n vals := []interface{}{\r\n entity.TransferId,\r\n entity.AmountCents,\r\n entity.CurrencyCode,\r\n spanner.CommitTimestamp, // Use Spanner commit timestamps\r\n }\r\n \r\n return spanner.Insert(c.tableName, cols, vals), nil\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6e597f7350>)])]>

DAO と Spanner SDK（spanner.Mutation）の間に厳格で決定論的なコントラクトを確立することで、AI コーディングエージェントが推論して確実に生成できる正確なターゲット仕様を作成しました。

Antigravity CLI をヘッドレスモードで使用する理由

IDE のインタラクティブな AI チャットインターフェースは、探索的なコーディングには適していますが、コードベース全体にわたる体系的な複数ファイルのコード更新には適していません。エッジケースを見逃さずに、数十のターゲットに繰り返し可能なリファクタリングを適用する必要がある場合は、自動化されたワークフローが必要です。

この問題に対処するため、Antigravity CLI をヘッドレスモード（-p）で実行するオーケストレーションスクリプト（migration_ui.py）を構築しました。

ヘッドレスモードでは、ターミナルのプロンプトに手動で応答しなくても、シェルスクリプト、継続的インテグレーションパイプライン、バックグラウンド自動化ジョブ内で Antigravity を直接実行できます。このアプローチにより、主に 3 つの方法で作業を効率化できました。

決定論的なプロンプトアーキテクチャ: プロンプトをバージョン管理されたエンジニアリングアーティファクトとして扱いました。タイムスタンプのシリアル化、null 可能性の変換、ミューテーションの曖昧さ、FakeTimeSource テストインジェクションなど、Spanner の一般的なエッジケースを処理する正確なルールを、再利用可能なプロンプトテンプレートに直接コード化しました。
バッチ実行と自動検証: オーケストレーションスクリプトが、ターゲット DAO 名を入力として使用し、既存の単一書き込みソースコードとスキーマを取得して、構造規則とともにヘッドレス Antigravity にフィードします。Antigravity は、新しいコンバータ、リファクタリングされた二重書き込み DAO、対応する単体テストを生成します。その後、スクリプトは blaze test を実行します。linter エラーやテストアサーションの失敗が発生すると、エラーログが Antigravity に直接フィードバックされ、自己修正が行われます。
夜間に大規模に実行: ループは無人で実行されるため、エンジニアは 1 日の終わりに 10 個の DAO をキューに入れることができます。朝までに、パイプラインは人間によるコードレビューの準備が整った 10 個のクリーンな変更リストを生成、テスト、検証します。

クラウドエンジニアにとっての成果と重要なポイント

Spanner の分散データベースプリミティブと Antigravity CLI のヘッドレス自動化を組み合わせることで、エンジニアリング組織全体に明確なメリットがもたらされました。

移行作業の大幅な削減: 二重書き込みによる DAO の移行は、以前は広範な手動コーディングとテストが必要でしたが、わずかな時間で完了し、確認されました。
信頼性の高いデータ移行: 生成されたすべての DAO が、テスト済みのまったく同じ MutationConverter パターンに準拠し、Spanner テストダブルに対する自動単体テストを受けたため、広範な移行テスト中も高いデータ忠実度を維持できました。
より価値の高いエンジニアリングに集中: エンジニアは、繰り返しのボイラープレートリファクタリングを回避し、データモデリング、アーキテクチャの復元力、パフォーマンスの最適化に集中する時間を確保できました。

次回のデータベース移行に役立つ 3 つのヒント

まずスキーマ変換を分離する: 移行スクリプトを記述する前に、新しいクラウドデータベース SDK の要件を既存のビジネスロジックから分離する厳密なインターフェース（MutationConverter など）を定義します。AI エージェントは、明確で限定された設計パターンを与えられた場合に、最も効果的に機能します。
インタラクティブなチャットからヘッドレス自動化に移行する: 3～4 個以上のファイルにわたって繰り返しリファクタリングを実行する場合は、スクリプト化されたヘッドレスワークフローにリソースを投入します。プロンプト入力とテスト検証を自動化されたビルドステップとして扱うことで、品質と一貫性を維持できます。
ビルドシステムをガードレールとして機能させる: AI 生成ループをビルドおよびテストハーネス（bazel test または go test）に直接接続します。これにより、デベロッパーがコードを確認する前に、モデルがコンパイルエラーとアサーションエラーを修正できます。

使ってみる

金融システムの移行でも、クラウドネイティブアプリケーションのゼロからの構築でも、Spanner と Antigravity はスケーラブルなソフトウェア開発の基盤となります。

Cloud Spanner を確認する: Spanner の分散アーキテクチャの詳細については、Google Cloud Spanner のドキュメントをご覧ください。
デベロッパー向け Gemini を確認する: AI を活用したコーディングとヘッドレス CLI の自動化がエンジニアリングワークフローにどのように役立つかを、デベロッパー向け Google Cloud AI でご確認ください。

- アプリケーションエンジニア Sachin Mathapati

近畿大学と Google Cloud が包括連携協定を締結 - 約 2 万人超へ「Google AI Pro for Education」を導入し、「AI ネイティブ大学」の実現を支援

Thu, 10 Sep 2026 01:00:00 +0000

Google Cloud は、近畿大学（大阪府東大阪市）と、AI 人材育成モデルの確立ならびに生成 AI を活用した大学運営、学生支援、研究支援の高度化に向け、包括連携協定を締結しました。

本協定に基づく具体的な取り組みとして、全 16 学部の 1・2 年生 19,033 人および教職員 2,105 人、合わせて 21,138 人を対象に、教育機関向け Gemini アプリケーションの有償版である「Google AI Pro for Education」のライセンス導入を Google Cloud がサポートします。また、2026 年度後期の授業開始に合わせて近畿大学が進める、生成 AI 技術を活用した学生支援窓口のオンライン化に向けたトライアルも、Google Cloud が技術面から後押しします。

近畿大学の大規模かつ多様な教育・研究環境と、Google Cloud が提供する生成 AI、クラウド、データ分析などの技術を組み合わせ、AI 人材育成、大学運営、学生支援、研究支援の各領域を横断した「AI ネイティブ大学」の実現を強力に支援してまいります。

【本協定のポイント】

● Google Cloud が近畿大学との包括連携協定を通じて、生成 AI 活用による大学全体の変革を支援

● 全 16 学部の 1・2 年生および教職員合わせて約 2 万人を対象に、「Google AI Pro for Education」のライセンス導入をサポート

● 「AI ネイティブ大学」の実現に向け、AI 人材育成、大学運営、学生支援、研究支援の 4 領域で取り組みを推進

【本件の内容】

近畿大学ではこれまで、従来の教育向け生成 AI サービスの試験導入などを通じて、学生および教職員による生成 AI の活用方法や導入効果を検証してきました。学生の学修支援に加え、教職員による文書作成、要点整理、議事録作成、規程・マニュアルの検索・要約など、さまざまな場面で生成 AI の活用を進めています。

また、学生支援においては、チャットボットやオンライン問い合わせフォームを活用し、対面とオンラインを組み合わせた相談・問い合わせ体制の検証にも取り組んできました。

近畿大学は本協定を機に、これまで培ってきた実績を Google Cloud の技術支援を通じて大学全体の変革へとつなげていきます。

Google Cloud が支援する「AI ネイティブ大学」とは、単に生成 AI サービスを導入するだけではなく、学生と教職員が生成 AI を日常的かつ適切に活用し、AI 人材育成、大学運営、学生支援、研究支援の仕組みそのものを継続的に改善していく大学です。

本協定を通じて、近畿大学は 4 領域で生成 AI を活用した具体的な取り組みを進めます。Google Cloud は、その取り組みを技術面から支えるとともに、そこで得られた知見が国内の高等教育における新たな生成 AI 活用モデルとなることを期待しています。

【近畿大学がめざす 4 つの領域への Google Cloud の支援】

◼︎ AI 人材育成モデルの確立
近畿大学は、自身の持つ多様な教育環境と Google Cloud の生成 AI・クラウド技術を掛け合わせ、全学的な AI 人材育成モデルの確立を目指します。具体的には、全 16 学部の 1・2 年生および教職員の約 2 万人を対象に、「Google AI Pro for Education」のライセンスを導入します。さらに、近畿大学では 2027 年 4 月から全学部で情報リテラシー関連科目を必修化する予定です。Google for Education の協力を得て、生成 AI の仕組み、ファクトチェック、著作権、情報セキュリティ、学術公正などを学ぶこの教育を技術・コンテンツの両面から支援し、学生が専門教育や研究・制作活動において Gemini などの生成 AI を目的に応じて適切に活用できる力の育成を後押しします。

◼︎ AI ネイティブ大学運営モデルの共同構築
近畿大学は、既存業務に生成 AI を追加するにとどまらず、問い合わせ、申請、決裁、文書作成、情報検索、会議運営などの大学業務を生成 AI 活用前提で再設計し、次世代の大学運営モデルの構築を推進します。また、複数のシステムやデータを横断して処理する業務や、複雑な判断・手順を伴う業務、学内 LMS の活用などについて、Gemini Enterprise の AI エージェント機能を活用した自動化・高度化の可能性を Google Cloud とともに検証していきます。

◼︎ AI を活用した「24 時間学生支援モデル」の構築（学生支援窓口のオンライン化）
近畿大学は、2026 年度後期の授業開始に合わせて、AI チャットボット、オンライン問い合わせフォーム、予約制相談を組み合わせた学生支援窓口のオンライン化に向けた移行トライアルを開始します。

学生が時間や場所を問わず必要な情報にアクセスできる環境を目指し、FAQ、学内規程、手続案内、シラバスなどを活用した検索・回答支援の充実に向けた取り組みを、Google Cloud が技術面から後押しします。

◼︎ 研究者と AI が協働する「次世代研究支援基盤」の構築
近畿大学は、論文・研究情報の収集、先行研究の整理、研究データの分析、共同研究者の探索などを支える全学的な研究支援基盤の構築に取り組みます。Google Cloud は、Gemini Enterprise や BigQuery などのサービス提供および技術支援を通じて、研究者と AI が協働する新たな研究環境の創出を支えます。

【近畿大学長松村到のコメント】

生成 AI は、知識を得るためのツールにとどまらず、私たちの思考を広げ、学びを深め、新たな価値を生み出す大きな可能性を持っています。一方で、AI が示す答えをそのまま受け入れるのではなく、情報の正確性を確かめ、自ら考え、判断し、責任を持って活用する力が、これまで以上に重要になります。

今回の Google Cloud との包括連携は、単に新しい AI サービスを導入するものではありません。Google Cloud が持つ生成 AI やクラウド、データ活用に関する技術・知見と、本学の大規模かつ多様な教育・研究環境を掛け合わせ、両者が共に新しい大学のあり方を創り上げていく取り組みです。約 2 万人の学生・教職員への「Google AI Pro for Education」の導入を一つの起点として、教育、学生支援、大学運営、研究の各分野において、生成 AI の活用を前提とした「AI ネイティブ大学」の実現をめざします。

近畿大学はこれまで、社会の変化を先取りし、実社会の課題に向き合う「実学教育」を大切にしてきました。生成 AI が社会に広く浸透する時代だからこそ、学生には AI に使われるのではなく、AI を使いこなし、人にしかできない発想や判断、対話を通じて、新しい価値を生み出せる人材へと成長してほしいと考えています。

令和 9 年（2027 年）4 月から全学部で必修化する情報リテラシー関連科目などを通じて、AI の可能性とリスクの双方を正しく理解し、実践的に活用する力を育んでまいります。さらに、学生支援や大学業務、研究支援にも AI 活用を広げ、大学全体の仕組みそのものを進化させていきます。

Google Cloud との共創を通じて、学生、教職員、研究者が安心・安全に AI を活用し、新しい価値を生み出し続ける大学へ。近畿大学はこれからも、実学教育を進化させながら、これからの高等教育の新しい姿を切り拓いてまいります。

【グーグル・クラウド・ジャパン合同会社執行役員パブリックセクター & ヘルスケア・ライフサイエンス事業本部長和泉綾志のコメント】

先進的な教育を牽引される近畿大学様との包括連携協定の締結を、大変光栄に思います。

Google Cloud は最先端の AI 技術である Gemini、クラウド基盤そしてセキュアなデータ基盤などを提供することで、学生の皆様がこれからの時代に求められる AI スキルを実践的に学べる教育・研究環境づくりを全面的に支援いたします。

また、教職員の皆様の校務、教務等の業務環境 DX、AX 推進を支え、より質の高い学習体験を提供できる基盤づくりに貢献してまいります。

Google Cloud の技術を活用いただくことで、近畿大学様の実学教育による次世代の AI 人材の育成に貢献してまいります。

バグの発見と修正を支援するオープンソースの AI ハーネス、Mantis のスタートガイド

Wed, 09 Sep 2026 02:00:00 +0000

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

AI モデルは、人間の手をほとんど、あるいはまったく介さずに脆弱性を発見して悪用する能力を持っていることが判明しています。防御側が AI を活用して優位性を確保できるよう、Google はソフトウェアの脆弱性の発見、トリアージ、再現、パッチ適用を自動化する Mantis ハーネスを構築しました。

誰でも利用可能なオープンソースフレームワークである Mantis は、マシンスピードでの脆弱性の発見と修正を実現するための Google の社内アプローチの一環として誕生しました。Mantis により、より効果的でスケーラブルかつコンテキストを考慮したリポジトリ分析が可能になります。

AI コードスキャンは精度が低く、ハルシネーションを起こすことが多いため、真陽性率は 7% を下回ります。Mantis は、批評エージェントやレビューエージェントなどの業界標準のエージェント手法とサンドボックス環境での脆弱性の再現を組み合わせてグラウンディングを行うことで、実効性を持たせた設計になっています。

6 月に公開した記事で詳しく解説したとおり、Mantis はリポジトリの履歴を調べて過去のセキュリティに関する修正から学習し、アーキテクチャと脅威モデルのドキュメントが提供されていない場合でも、それらのドキュメントを自動的に作成します。

階層型のセキュリティサマリーツリーを構築し、個々のファイルをディレクトリレベルとルートレベルのサマリーに集約します。この手法により、大規模なリポジトリ全体で重要な構造コンテキストを維持しながら、トークンのオーバーヘッドを 85% 以上削減することに成功しました。

Google が数十年の期間をかけて幅広いコードベースにわたって蓄積してきたサイバーセキュリティの専門知識の結晶である Mantis は、GitHub で入手可能です。Mantis の使用を開始する方法は次のとおりです。

まず、次のコマンドを使用して Mantis リポジトリのクローンをローカルに作成します。

code_block: <ListValue: [StructValue([('code', 'git clone https://github.com/google/mantis.git'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6e597a27d0>)])]>

次に、任意のコーディングエージェントを開き、「path/to/mantis にある Mantis フレームワークを使用して、path/to/your/code にあるコードをレビューしたいのですが、やり方を教えてください」というプロンプトを入力します。

Google 社内では、このプロンプトを使用して、多くのコードリポジトリで実際の脆弱性を発見しています。GitHub の Mantis リポジトリには、サンドボックス化のサンプルオプションが含まれています。自社のワークフローに合わせて独自のサンドボックスを実装することもできます。

Mantis は、脆弱性の検出、真陽性のフィルタリング、パッチ適用を簡単に開始できるようにすることを目的としています。AI が検出した脆弱性を把握したら、新しい mantis-advise スキルを使用して、蓄積された知識を活用し、コーディングエージェントに最初から安全なコードを記述させることができます。

AI を活用した脆弱性検出を最大限に活用して開発手法をモダナイズするにあたって、以下に示す 2 つの重要事項の実行を推奨します。

ツールに適切なコンテキストを提供する。Mantis はコミット履歴とコードを自動的に分析してドキュメントを独自に作成することができますが、人間によってキュレートされた知識を得ることで、結果の品質が大幅に向上することがよくあります。たとえば、プログラムをクラッシュさせるようなバグの修正に時間を取られないようにするには、スキャンパイプラインでそうしたバグを確実に検出できるよう、人間によってキュレートされた知識を提供することが非常に重要になります。
脆弱性受け入れ基準を使用してサイバーサンドボックスを構築する。明確な脆弱性再現基準に基づいて脆弱性を再現できる安全なサンドボックス環境を使用すると、知るべきことのみを明らかにし、修正が正しいことを確認することが容易になります。

Mantis について詳しくは、こちらをご覧ください。

- Google、スタッフセキュリティエンジニア、Nick Galloway

- Google、シニアスタッフセキュリティエンジニア、Yulong Zhang

AI プロトタイプを本番環境に移行する前にすべてのスタートアップが答えておくべき 10 の質問

Fri, 04 Sep 2026 11:00:00 +0000

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

Google Cloud で AI を活用したスタートアップを立ち上げることが、これまでになく簡単になっています。

朝食時に Google AI Studio から API キーを取得し、それを Antigravity に貼り付ければ、昼食時には製品のプロトタイプができ始めているでしょう。

しかし、進歩の道のりは一直線ではありません。スタックを構築する際に、次の 3 つの課題に直面することがよくあります。

API キーが漏洩し、48 時間で高額な請求が発生する。
AI Studio から Gemini Enterprise Agent Platform への移行を急いで進めたが、チームに Identity and Access Management（IAM）の担当者がいないため、ロードマップが数週間停滞する。
リリースは成功したが、プロジェクトごとのデフォルトの割り当てが原因でアプリが「HTTP 429 Too Many Requests」を返すようになり、追加料金を支払わずに容量を増やす明確な方法がない。

これらはどれも特殊なエッジケースではありません。これらは、計画なしに急いで行動して失敗に陥ってしまうパターンであり、誰もが一度は経験したことがあるでしょう。

ここでは、スタートアップが事業を拡大する前に答えられるようにしておくべき 10 の質問を紹介します。これらの質問を、意思決定が将来を左右する 3 つのフェーズに分類しています。

オンボーディング（独自のプロジェクトと ID を適切に設定する）
スケール（費用をかけずにスループットを高める）
管理（費用、キー、エージェントの暴走を防ぐ）。

これらの 10 の質問は、プロトタイプから本番環境への移行そのものを対象としています。各質問の最後には、すぐに実行できる短いスニペットが用意されています。このスニペットは、ご自身のプロジェクトにコピーして使用できます。その移行に特有ではない周辺的な意思決定（データレイヤと RAG アーキテクチャ、CI / CD、ネットワーク設計など）については、同様に重要ですが、ここでは意図的に対象外としています。

オンボーディング: 基礎を固める（ごく初期の段階）。

#1 Google AI Studio と Gemini Enterprise Agent Platform のどちらから始めればよいですか？

どちらのサーフェスも同じ Gemini ファミリーのモデルを提供しますが、解決する問題は異なります。

Google AI Studio（Gemini Developer API を使用）は、アイデアから実際に動作するコードへと至る最短経路となります。ブラウザ IDE、API キー、豊富な無料枠が用意されており、クラウドプロジェクトを構成する必要はありません。ほとんどのアイデアはここから始めるべきであり、Google のガイダンスでもそのように推奨されています。
Gemini Enterprise Agent Platform （旧称 Vertex AI）は、同じ Gemini モデル（サードパーティ製と OSS のモデルも含む）に加えて、企業向けの管理機能を備えています。具体的には、未加工のキーに代わる IAM とサービスアカウントによる認証、VPC Service Controls、Cloud Logging と Cloud Monitoring、予約済み容量、リージョンエンドポイント、そして最初の企業顧客によるセキュリティ審査で問われるコンプライアンスサーフェスです。

ほとんどのスタートアップにとっての正解は、両方を意図した順序で行うことです。まず AI Studio でプロトタイプを作成し、その後、実際のユーザーに提供する前に移行します。スタートアップにとって危険なのは、これらを交換可能なソリューションとして扱うことです。AI Studio のシンプルなキーモデルは企業向けの管理機能に適したものではなく、Agent Platform の IAM モデルは、認証情報が盗まれる被害から保護されていることを実感するまで、過剰なものに見えるかもしれません。

実際には、思ったより手間はかかりません。

統合された google-genai SDK は、両方を対象としています。

code_block: <ListValue: [StructValue([('code', '# Prototype: Google AI Studio, raw API key\r\nfrom google import genai\r\nclient = genai.Client(api_key="YOUR_AI_STUDIO_KEY")\r\n\r\n# Production: GEAP, no key — uses Application Default Credentials (ADC)\r\nfrom google import genai\r\nclient = genai.Client(\r\n vertexai=True,\r\n project="my-startup-prod",\r\n location="us-central1",\r\n)\r\n\r\nresp = client.models.generate_content(\r\n model="gemini-2.5-pro",\r\n contents="Summarize this contract in three bullets.",\r\n)\r\nprint(resp.text)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6e59ff0090>)])]>

#2 IAM のエキスパートがいない場合に Google Cloud プロジェクトを設定するにはどうすればよいですか？

スタートアップが Agent Platform への移行を躊躇する最大の理由は、コードではなく、API キーを 1 つ用意するだけの運用から、フォルダ、サービスアカウント、組織のポリシー、ロギング、IAM バインディングを備えたクラウドプロジェクトに移行するという、運用上の大きな変化です。チームに専任のクラウド管理者がいない場合、最初のプロジェクトのセットアップに 1 週間分のエンジニアリング時間がかかることがあります。

3 つのステップで、この時間を大幅に短縮できます。

コンソールを操作する代わりに、独自の設計思想が反映されたプロジェクトテンプレートを使用する。クラウド設定のチェックリストと Google Cloud アーキテクチャフレームワークを使用すると、本番環境レベルのフォルダ階層（prod / non-prod / dev）、一元的なロギングとモニタリングのプロジェクト、Security Command Center の有効化、ベースライン組織ポリシーが提供されるため、これらをゼロから設計する必要はありません。
実際に使用する API を一度有効にする必要なときにプロジェクトごとに実行しなくても済むように、バッチ処理します。請求先のリンクの手順は省略できません。これから有効にしようとしている有料 API は、請求先アカウントが関連付けられていないプロジェクトでは有効にできないため、まずはその設定を行います。
Gemini にロールを選択させますが、限定的なロールをリクエストします。ロールのリファレンスを覚える必要はありません。アクセス権を付与するダイアログで [推奨ロールの表示] を使用すると、平易な言葉でタスクを説明できます（「このサービスアカウントは Gemini モデルを呼び出し、1 つの Cloud Storage バケットを読み取る必要があります」など）。すると、その理由とともに事前定義ロールが返されます。初日に知っておくべき注意点が 1 つあります。デフォルトでは、一般的なユースケースをカバーするロールが提案されます。通常は、サービスの管理者、編集者、閲覧者のロールです。これらは、必要以上に広い権限を持っています。プロンプトで「最小権限」または「最小限のアクセス」と指定すると、代わりに詳細なロールが返されます。入力する量は同じですが、認証情報が漏洩した場合の影響範囲は大幅に小さくなります。出典: Gemini のアシスト機能を使用して事前定義ロールの候補を取得する

code_block: <ListValue: [StructValue([('code', '# One-shot: create a Vertex-ready project and turn on the services a\r\n# typical AI startup uses.\r\ngcloud projects create my-startup-prod --name="My Startup (prod)"\r\ngcloud config set project my-startup-prod\r\n\r\n# REQUIRED before enabling billing-dependent APIs (aiplatform, run, etc.).\r\n# Use `gcloud billing accounts list` to find your billing account ID.\r\ngcloud billing projects link my-startup-prod --billing-account=012345-6789AB-CDEF01\r\n\r\ngcloud services enable \\\r\n aiplatform.googleapis.com \\\r\n run.googleapis.com \\\r\n artifactregistry.googleapis.com \\\r\n logging.googleapis.com \\\r\n monitoring.googleapis.com \\\r\n secretmanager.googleapis.com \\\r\n cloudbilling.googleapis.com'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6e59b5d050>)])]>

出典: gcloud services enable リファレンス、gcloud billing projects link（GA）、GE Agent Platform 環境の設定。

単独の創業者である場合は、個人の GCP アカウントで構築しないようにしてください。適切な組織または自己所有の組織を最初に作成し、その内部ににプロジェクトを作成します。この 1 つの決定により、IAM から請求、監査まで、その他すべての作業が大幅に簡素化されます。

#3 Google Cloud を使用しています。コードの認証には、API キー、サービスアカウント、ユーザー認証情報のどれを使用すればよいですか？

この問題には安全性の階層があり、最も簡単なオプションが本番環境において適切なオプションであることは稀です。

未加工の API キーは、ローカルでのプロトタイピングには適しています。これは、有効期間が長く、クライアントバンドルや公開リポジトリに漏洩しやすく、それに気づくまで無制限のアクセスを許可してしまうため、本番環境では危険です。
OAuth によるユーザー認証情報（アプリケーションのデフォルト認証情報）は、対話型ツール、CLI のほか、デベロッパーのノートパソコンで実行されるコードに最適です。
サーバー、コンテナ、スケジュールされたジョブで実行されるものには、最小権限の IAM ロールを持つサービスアカウントが適しています。

目指すべきパターンは、コードが鍵をまったく認識しないパターンです。Google Auth ライブラリを呼び出すだけで、環境からアプリケーションのデフォルト認証情報（ADC）が読み取られます。これは、Cloud Run サービス、GKE ワークロード、または Compute Engine VM にアタッチされているサービスアカウントに対して発行された有効期間の短いトークンです。認証コードを記述しなくても、エンタープライズグレードの認証を利用できます。

code_block: <ListValue: [StructValue([('code', '# On a developer laptop\r\ngcloud auth application-default login\r\n\r\n# On a server (Cloud Run, GKE, etc.) — no login, no key file.\r\n# Attach a service account with just the roles the app needs.\r\ngcloud run deploy my-agent \\\r\n --image=us-docker.pkg.dev/my-startup-prod/agents/api:v1 \\\r\n --service-account=agent-runtime@my-startup-prod.iam.gserviceaccount.com \\\r\n --region=us-central1'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6e59b5c490>)])]>

code_block: <ListValue: [StructValue([('code', '# Application code — notice: no keys, no secrets.\r\nfrom google import genai\r\n\r\nclient = genai.Client(\r\n vertexai=True,\r\n project="my-startup-prod",\r\n location="us-central1",\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6e59b5d0d0>)])]>

最後に、今後に備えて、そのサービスアカウントに、ワークロードが実際に必要とする最小限の IAM ロールを付与します。通常は、より広範な管理者ロールではなく、モデルを呼び出すための roles/aiplatform.user にします。30 秒ほど余分に時間がかかりますが、認証情報が漏洩したとしても、それがマスターキーになるのを防ぐことができます。

#4 AI Studio の API キーから Agent Platform の IAM モデルへの移行は、いつまで引き延ばせますか？

思っているよりも早く対応すべきです。正しいトリガーは、実害が出たときではありません。次のいずれかに該当する場合です。

キーがノートパソコンから流出した（リポジトリにチェックインした、Slack に貼り付けた、モバイルアプリに組み込んだ）。
チームに API を呼び出す必要がある人が複数いる。
1 か月あたり数百ドル以上を費やしている。
有料ユーザーのオンボーディングが間近に迫っている。

成長中のスタートアップが不意を突かれる可能性のある落とし穴は、単純なものです。たとえば、通常は月額 180 ドルを支払っているアカウントの Gemini API キーが公開リポジトリから漏洩し、蒸留攻撃に悪用されるケースです。この場合、所有者が最初の請求アラートを確認する前に、数万ドルの料金が累積してしまいます。Google Cloud の責任の共有モデルは明確です。お客様は、有効な認証情報を使用して発生した料金について責任を負います。

移行自体は、移行に対する不安よりもはるかに小規模なものです。google-genai では、#1 に示す 2 行の変更です。実際に時間がかかるのは、それに伴うプロジェクトのセットアップです。まさにそのために 2 が存在します。

カットオーバー日の実用的なチェックリスト:

code_block: <ListValue: [StructValue([('code', '# 1. Revoke every existing AI Studio key that has ever left a laptop.\r\n# (Go to https://aistudio.google.com/apikey and delete them.)\r\n\r\n# 2. Confirm your production code has no api_key= arguments.\r\ngrep -rn "api_key" src/\r\n\r\n# 3. Enable GEAP and confirm ADC works locally.\r\ngcloud services enable aiplatform.googleapis.com\r\ngcloud auth application-default login\r\npython -c "\r\nfrom google import genai\r\nc = genai.Client(vertexai=True, project=\'my-startup-prod\', location=\'us-central1\')\r\nprint(c.models.generate_content(model=\'gemini-2.5-flash\', contents=\'ping\').text)\r\n"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6e59b5f990>)])]>

ステップ 3 でレスポンスが出力された場合は、Agent Platform を使用しています。

スケール: 追加料金を支払うことなく容量を増やす。

#5 リリースしたのに、HTTP 429 エラーが頻発しています。これを解消するにはどうすればよいですか？

Agent Platform からの「429 Too Many Requests」はほとんどの場合、次の 2 つのいずれかを意味します。

プロジェクトの階層の動的共有割り当て（DSQ）の上限に達した場合。DSQ は、プロジェクトの履歴に基づいてサイズが設定される共有プールです。プラットフォーム全体での不正使用を防ぐため、新しいプロジェクトは設計上、控えめな上限から始まります。
世界的に需要が急増しているときに、グローバルエンドポイントを呼び出し、共有容量をめぐって世界中のトラフィックと競合している場合。

対策としてすぐ思いつくのは、割り当て増加のチケットを送信することです。必要であればそうすることもできますが、通常は 2 つのアーキテクチャ上の変更で、より迅速かつ安価に問題を解決できます。

リージョンエンドポイントに固定する。Agent Platform でのスタートアップトラフィックの半分以上は、デフォルトでグローバルルーティングに設定されています。特定のリージョン（us-central1 など）に固定すると、グローバルな競合を回避でき、通常はレイテンシも改善されます（次の質問で説明しますが、1 つだけ例外があります。Priority PayGo を特に希望される場合、この機能は現在グローバルエンドポイントでのみ提供されています。それ以外の場合は、リージョンに固定します）。

code_block: <ListValue: [StructValue([('code', 'from google import genai\r\n\r\n# Global (default): competes against worldwide demand.\r\n# Regional: routes only to the regional cluster, less contention.\r\nclient = genai.Client(\r\n vertexai=True,\r\n project="my-startup-prod",\r\n location="us-central1", # <-- this is the one-line fix\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6e59b5cb10>)])]>

適切な再試行とバックオフを追加する。429 は再試行可能なシグナルであり、致命的なエラーではありません。本番環境のクライアントには、ジッターを伴う指数バックオフが必要です。最新の google-genai SDK には、この動作が組み込まれていますが、実際に有効にした場合にのみ機能します。これは見落としがちです。古い Vertex コードで見たことがあるかもしれませんが、従来の `google.api_core.retry.if_transient_error` デコレータは使用しないでください。これは従来の例外クラス向けに設計されており、新しい `google.genai.errors.APIError` を認識しないため、429 エラーを再試行せずに無視します。代わりに、SDK の組み込みの再試行オプションを使用します。

code_block: <ListValue: [StructValue([('code', 'from google import genai\r\nfrom google.genai import types\r\n\r\nclient = genai.Client(\r\n vertexai=True, project="my-startup-prod", location="us-central1",\r\n http_options=types.HttpOptions(retry_options=types.HttpRetryOptions(\r\n attempts=5, initial_delay=1.0, max_delay=60.0, exp_base=2.0, jitter=1.0,\r\n http_status_codes=[408, 429, 500, 502, 503, 504],\r\n ))\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6e59b5c3d0>)])]>

この状況をどのように予測しますか？できれば、ユーザーから報告を受ける形ではなく。Agent Platform はサービング指標を Cloud Monitoring に公開します。また、[コンソール] > [Agent Platform] > [ダッシュボード] > [モデルのオブザーバビリティ] に、アセンブル不要の事前構築済みダッシュボードがあります。1 秒あたりのリクエスト数、トークンスループット、最初のトークンのレイテンシ、エラー率をすぐに確認できます。

実際にアラートを生成する指標は aiplatform.googleapis.com/publisher/online_serving/model_invocation_count です。error_category ラベルが付き、値は user、system、capacity のいずれかになります。capacityに関するアラートは、自分自身の間違ったリクエストから実際のスロットリングを分離します。これは、未加工の 429 エラーのカウントでは行われません。

注意すべき点として、Standard PayGo では「使用量が割り当ての 80% に達したら警告して」というアラートを作成できません。動的共有割り当てでは、80% を限度とする、プロジェクトごとの固定値はありません。429 エラーは、共有容量の一時的な競合を意味し、限度を超えたことを意味するものではありません。割合を上限とするアラートは、実際の上限指標が提供されるプロビジョンドスループットを使用している場合にのみ意味を持ちます。

code_block: <ListValue: [StructValue([('code', 'gcloud monitoring policies create --policy-from-file=capacity-alert.yaml'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6e59b5eb90>)])]>

出典: Agent Platform の指標リスト、モデルのオブザーバビリティダッシュボード、RetryOptions のソース、コア retry_base.py、genai errors.py、429 エラーの削減、gcloud monitoring policies create、動的共有割り当て。

Agent Platform のレート制限に関するドキュメントに沿って、プロジェクトの現在の上限が実際にどの程度であるかを把握してから、上限を超えているかどうかを判断してください。

#6 Standard PayGo、Priority PayGo、プロビジョンドスループットのうち、どの消費モデルを利用すればよいですか。

3 つの消費モデルは、ワークロードの形態も進め方もまったく異なります。適切なものを選択することで、スタートアップは AI の請求額を大幅に削減できます。まず、それぞれの定義を確認し、どのような場合に適しているか、または適していないかを見ていきましょう。

Standard PayGo（DSQ）: 共有プールからのトークン単位の課金。低価格、保証なし。Priority PayGo: トークン単位の課金、プレミアム料金のためキューをスキップ可能。プロビジョンドスループット（PT）: 予約済み容量を前払い。予測可能、使用しないと無効。

消費タイプ	最適な用途	注意点
Standard PayGo（DSQ）	初期段階、低 QPS、急激に変動するプロトタイプトラフィック	急増時に 429 エラーが発生、信頼性 SLO なし
Priority PayGo	429 を許容できない、バースト性の高い、収益に不可欠なトラフィック	標準トークン価格の約 1.8 倍
プロビジョンドスループット（PT）	安定した、予測可能な、大量の本番環境トラフィック	使用率が 40% 未満の場合、費用が無駄になる。スパイク時には PayGo にオーバーフロー

スタートアップによくある間違いは、PT を早すぎる時期に購入することです。特に、大規模なリリースの翌週、トラフィックが増加する一方のように感じられるときに、こうした間違いが起きます。PT は予約済みの容量です。使用するかどうかにかかわらず料金を支払う必要があり、ベースラインが単なる願望ではなく、真に予測可能になった場合にのみ、元が取れるようになります。

実用的な手順は次のとおりです。

Standard PayGo の第 1～4 週。これを使用して、実際のリクエストの形態（p50 と p99 での 1 分あたりのトークン数、リクエストのバースト、バッチ処理可能とリアルタイム処理の内訳）を測定します。
初めて 429 エラーが大量に発生したときは、実際に重要なトラフィックに対して Priority PayGo を有効にします。これは構成の変更であり、注文書ではないため、調達部門の担当者は関与する必要はありません。

code_block: <ListValue: [StructValue([('code', '# Priority PayGo request: use the global endpoint + two extra headers.\r\nfrom google import genai\r\nfrom google.genai import types\r\n\r\nclient = genai.Client(vertexai=True, project="my-startup-prod", location="global")\r\nresp = client.models.generate_content(\r\n model="gemini-2.5-pro",\r\n contents="Rank these support tickets by urgency: ...",\r\n config=types.GenerateContentConfig(\r\n # Priority PayGo headers, per current GEAP docs.\r\n http_options=types.HttpOptions(headers={"X-Vertex-AI-LLM-Request-Type": "shared", "X-Vertex-AI-LLM-Shared-Request-Type": "priority"}),\r\n ),\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6e59b5c510>)])]>

3. ベースラインの TPM を予測できるようになったら、PT を購入してフラットベースラインをカバーし、ベースラインを超える分は PayGo にオーバーフローします。これが、Google が推奨する組み合わせパターンであり、まったく理にかなったものです。単なる宣伝文句ではなく、両方の利点を活かしています。

出典: Priority PayGo のドキュメント、google-genai HttpOptions のソース、GEAP REST リファレンス。

#7 どのリクエストをライブにして、どのリクエストをバッチジョブにする必要がありますか？

スタートアップのワークロードのほとんどは、リアルタイムを装ったバッチジョブであることが実態です。ジョブをインタラクティブなパスから外すたびに、本当に高速であることが必要なトラフィック、つまりユーザーが実際にスピナーを見つめているトラフィックのために DSQ のヘッドルームが解放されます。

トラフィックを分類するのに役立つ 3 つの質問:

ユーザーが 1 秒以内に結果を確認する必要がありますか？この場合は、ライブ推論です。
ユーザーはスピナーを見ながら数秒間待つことができますか？この場合もライブですが、ストリーミングの候補でもあります。
ユーザーは「準備が整い次第メールでお知らせします」または「しばらくしてからもう一度ご確認ください」というメッセージを許容できますか？この場合は、バッチ予測です。

Agent Platform でのバッチ予測は完全に独立したキューで実行され、インタラクティブな DSQ を消費しません。また、通常はオンデマンド推論の半額程度です。これは、ライブトラフィックの高速化と費用の削減という二重のメリットをもたらす、まれな例です。

code_block: <ListValue: [StructValue([('code', '# Kick off a batch prediction job from a JSONL file in Cloud Storage.\r\n# Each line is one prompt; results land in another Cloud Storage prefix.\r\nfrom google import genai\r\nfrom google.genai import types\r\n\r\nclient = genai.Client(vertexai=True, project="my-startup-prod", location="us-central1")\r\n\r\njob = client.batches.create(\r\n model="gemini-2.5-flash",\r\n src="gs://my-startup-prod-batch/inputs/nightly-summaries.jsonl",\r\n config=types.CreateBatchJobConfig(\r\n dest="gs://my-startup-prod-batch/outputs/",\r\n ),\r\n)\r\nprint(job.name, job.state)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6e59b5c150>)])]>

一般的な候補: 夜間のドキュメント要約、新規登録者のバックグラウンド分類、一括翻訳、エンベディングのバックフィル、テストセットに対する評価実行。これらのいずれかが現在のライブパスにあれば、通常、それらを移動することが、今週できる最も効果的な変更となります。

管理: 費用、鍵、エージェントを管理する。

#8 請求額が 3 倍になっても丁寧なメールが届くだけでなく、実際に費用を削減できる利用額上限を設定するにはどうすればよいですか？

正直なところ、最近まで予算は通知するだけで、ブレーキペダルは自分で作る必要がありました。7 月にこの状況が変わりました。メカニズムは 3 つあり、これらはレイヤとして考えることができます。

利用額上限の予算（プレビュー）。Cloud Billing の予算で、メール通知だけでなく、強制的な適用が可能になりました。プロジェクトに利用額上限を設定すると、使用料金が予算の 100% を超えた時点で、Google はサービスを一時停止します。サービスを再開するには、手動で一時停止を解除する必要があります。Gemini API、Cloud Run、Cloud Run Functions とともに、Agent Platform が対象リストに明示的に記載されています。アラートは 50% と 80% で引き続き発生するため、予告もなく一時停止になるわけではありません。

利用する前に知っておくべき 3 つのこと:

各上限は、1 つのプロジェクトと 1 つの対象サービスに適用されます。アカウント全体の保護ではありません。Agent Platform と Cloud Run の両方に上限を設定する場合は、2 つの上限を設定することになります。
適用は即時ではなく、推定費用に基づきます。上限を超えた分は通常どおり請求されるため、実際の予算上限よりも低い数値を設定してください。上限の解除は手動で行われ、サービスの再開には最長で 1 時間かかることがあります。また、プロビジョンドスループットの使用も一時停止されるため、容量を前払いしている場合は、上限に達するとその容量も使えなくなります。
公開時点ではプレビュー版であり、対象サービスのリストは今後増えていくことが記載されています。設計する前に、現在のリストを確認してください。

2. 課金を無効にする Pub/Sub トリガーによる予算設定。利用額上限では対応できない、広範な影響範囲（複数のサービスの一括設定、プロジェクト全体、まだ対象になっていないサービスなど）が必要な場合は、依然として適切なツールです。予算がしきい値に達すると、Pub/Sub が Cloud Functions の関数を起動して請求先アカウントを切り離し、数分以内にすべての課金対象アクティビティを停止します。ネイティブの上限よりも大雑把で危険です。リソースが回復不能になる可能性があるため、最初にではなく、2 番目に試みてください。詳細なチュートリアル: 予算通知に自動的に応答する。

code_block: <ListValue: [StructValue([('code', '# Sketch: create a budget SCOPED TO ONE PROJECT that publishes to Pub/Sub at 50%, 90%, 100%.\r\ngcloud billing budgets create \\\r\n --billing-account=012345-6789AB-CDEF01 \\\r\n --display-name="my-startup-prod hard stop" \\\r\n --budget-amount=2000USD \\\r\n --filter-projects=projects/my-startup-prod \\\r\n --threshold-rule=percent=0.5 \\\r\n --threshold-rule=percent=0.9 \\\r\n --threshold-rule=percent=1.0,basis=current-spend \\\r\n --notifications-rule-pubsub-topic=projects/my-startup-prod/topics/budget-alerts'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6e59b5edd0>)])]>

出典: 利用額上限の予算を管理する、プログラムによる通知を設定する、gcloud billing budgets create リファレンス、Cloud Billing の予算のコンセプト、通知で課金を無効にするチュートリアル、プログラムによる通知のペイロードスキーマ。

デフォルト設定が予期しない問題を引き起こす可能性があるため、事前に対応すべきことが 2 つあります。

予算の範囲を制限する: --filter-projects を使用しない場合、予算は請求先アカウント全体に適用されます。いずれかのプロジェクトで急増が発生すると、すべてのキルスイッチがトリガーされます。
ローカルにデプロイする: 予算通知では、影響を受けるプロジェクトが指定されていません。キルスイッチが目的のプロジェクトにのみ影響するように、保護するプロジェクト（my-startup-prod など）と同じプロジェクトに Cloud Functions の関数をデプロイします。

次に、そのトピックに小さな Cloud Functions の関数を接続し、100% のしきい値に達したときに projects.updateBillingInfo を呼び出して請求先アカウントのリンクを解除します。これが、回路ブレーカーの役割を果たします。

割り当てのオーバーライドによる機械的な上限。上記のキルスイッチを設定しなくても、プラットフォームのデフォルトを下回る、モデルごと、リージョンごとの割り当てを明示的に設定することで、費用が累積するレートに上限を設けることができます。アプリの本来の用途において gemini-2.5-pro に対する 1 分あたりのリクエスト数が 500 を超えることがない場合は、Cloud Quotas コンソールで上限を 500 に設定します。割り当てによってサービスが拒否されるため、キーが漏洩してもリソースが消費されることはありません。

#9 シークレットはどこに保存すべきですか？（.env ファイルではありません）

簡潔に言うと、Secret Manager です。環境変数、.env ファイル、リポジトリのいずれにも保存しないでください。IAM を介して、読み取りアクセス権を、そのアクセス権を必要とするサービスアカウントにのみ付与します。

code_block: <ListValue: [StructValue([('code', '# Store a third-party API key (Stripe, OpenAI, whatever).\r\necho -n "sk_live_xxx" | gcloud secrets create stripe-live-key --data-file=-\r\n\r\n# Grant only the runtime service account access to read it.\r\ngcloud secrets add-iam-policy-binding stripe-live-key \\\r\n --member=serviceAccount:agent-runtime@my-startup-prod.iam.gserviceaccount.com \\\r\n --role=roles/secretmanager.secretAccessor'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6e59b5e150>)])]>

code_block: <ListValue: [StructValue([('code', '# Application code fetches it at startup; nothing lives on disk.\r\nfrom google.cloud import secretmanager\r\nsm = secretmanager.SecretManagerServiceClient()\r\nresp = sm.access_secret_version(\r\n name="projects/my-startup-prod/secrets/stripe-live-key/versions/latest"\r\n)\r\nstripe_key = resp.payload.data.decode("utf-8")'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6e59b5e610>)])]>

次に、2 つのちょっとした習慣を紹介します。これらは、いざ必要になったときにその価値がわかります。

定期的なローテーションと、疑いがあるときのローテーション。Secret Manager のバージョンは安価です。既存のバージョンを書き換えずに、ロールフォワードしてください。
シークレットが漏洩したときの検出。Secret Manager の通知と Google Cloud のSensitive Data Protectionにより、攻撃者に先んじて、リポジトリにチェックインされたキーやログストリームに貼り付けられたキーを捕捉できます。

ユーザーに代わって動作する AI アプリケーション（ユーザーに代わって Gmail を呼び出す、ドライブのフォルダを読み取る、ユーザーの認証情報を使用してサードパーティの SaaS にアクセスするなど）には、有効期間の長いトークンを保存しないでください。有効期間の短いアクセストークンと更新フローとともに OAuth 2.0 を使用します。これにより、ユーザーが突然退職した場合や、不正使用されたアカウントが取り消された場合、エージェントは同時にアクセス権を失います。

#10 新しい AI エージェントが、決してすべきではないことをしないようにするにはどうすればよいでしょうか？

ツールの呼び出し、ウェブの閲覧、コードの実行が可能なエージェントには、他のあらゆる本番環境サービスと同様の、あるいはそれ以上に「多層防御」の考え方が求められます。なぜなら、そうしたエージェントは、ユーザーにとってもモデルにとっても事前に完全には予測できないような判断を下すからです。

4 つのレイヤがあり、実際のユーザーがいる場合は、どれも省略できません。

1. エージェント自体の ID。エージェントに独自のサービスアカウントを付与し、本当に必要なリソースとツールのみにスコープを限定します。これは、他のワークロードと同じ最小権限の原則です。Agent Engine はファーストクラスのエージェント ID をサポートしているため、監査ログですべてのアクションを特定のエージェントインスタンスに関連付けることができます。

2. サンドボックス化されたコード実行。エージェントが生成されたコードを実行する場合（データ分析や「この Python を実行して」のフローにおける一般的なパターン）、アプリケーションプロセスで実行しないでください。隔離されたサンドボックスを使用することで、不適切な組み合わせが本番環境データに影響を与えないようにします。

code_block: <ListValue: [StructValue([('code', '# Enable server-side code execution inside a sandbox for a request.\r\nfrom google import genai\r\nfrom google.genai import types\r\n\r\nclient = genai.Client(vertexai=True, project="my-startup-prod", location="us-central1")\r\nresp = client.models.generate_content(\r\n model="gemini-2.5-pro",\r\n contents="Compute the correlation between these two columns: ...",\r\n config=types.GenerateContentConfig(\r\n tools=[types.Tool(code_execution=types.ToolCodeExecution())],\r\n ),\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6e5b345cd0>)])]>

3. プロンプトと回答のフィルタリング。Model Armor は、モデル呼び出しの手前に配置され、プロンプトインジェクション、ジェイルブレイク、機密データの引き出し、ブランドにそぐわない出力をスクリーニングします。これらはすべて、実際のユーザーが使い始めれば、実質的に避けられないものとなります。

4. 行動のモニタリング。脅威検出機能を備えた Security Command Center は、エージェントの動作における異常にフラグを立てます。たとえば、サービスアカウントがこれまで使用したことのない API を突然呼び出す、エージェントが未知の外部ホストにアクセスする、特権操作が予期せず急増する、といったことです。これは、ほぼリアルタイムで行われます。

エージェントが実際のユーザーに代わって行動したり、実際のお金を扱ったりするようになると、これらはどれも省略できなくなります。

いわば宿題として

リポジトリ、ノートブック、本番環境ランタイムで、未加工の API キーを監査します。そこにあるべきでないキーをローテーションします。
同期レスポンスを必要としないワークロードは、Batch API に移行します。
モデルのオブザーバビリティダッシュボードを有効にして、容量エラーに関するアラートを 1 つ設定し、次の 429 エラーが顧客より前に自分に届くようにします。
プロジェクトの利用額上限を設定し、50% と 80% のアラートに注意します。使用量が予算の 100% を超えると、手動で解除するまで、Google はサービスを一時停止します。

今週この 4 つの事項を実施すれば、AI 機能をリリースしているほとんどのスタートアップよりも先を行くことができます。

次回取り上げてほしいシナリオはありますか？Google Cloud for Startups までお問い合わせください。

- Google Cloud AI、テクニカルソリューション、Sergio Villani

エージェントがより適切に委任を行う方法

Fri, 04 Sep 2026 02:10:00 +0000

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

組織行動論の授業では、効果的な委任が経験豊富なリーダーにとって最も重要なスキルの一つであると生徒は学びます。有意義な作業を完了するには、プロジェクトを管理可能なタスクに細分化し、そのタスクをチームのスキルにマッピングして、適切な担当者に割り当てることから始めて、慎重に調整する必要があります。

Google Cloud では、エンタープライズワークフローにおける AI エージェントの構築とデプロイに関しても、同様の教訓を得ています。これらのワークフローには、複雑なタスクを分割して実行できるマルチエージェントシステムが最適です。そのためには、AI エージェントが優れた委任者になる必要があります。

その方法を学ぶために、Google DeepMind の研究に目を向けました。最近の研究「Intelligent AI Delegation」では、委任自体にインテリジェンス、具体的には、適応型の交渉、正式なコントラクトに基づく調整、セキュリティガードレールがどのように関わっているかが実証されています。

この研究により、コミュニケーション、タスクの共有、設定された目標に向けた調整が可能な AI エージェントを構築するお客様に新たな機会がもたらされます。今回は、その研究から生まれた 4 つの原則と、それらを独自のワークフローに適用する方法をご紹介します。

原則 1: 委任された作業を検証する

AI にタスクを委任することを許可する場合、単に作業を任意に割り当てる以上のことが AI に求められます。エージェントは、作業を、確実に検証できるタスクにインテリジェントに分割する必要があります。Google の研究では、これを「コントラクトファーストの分解」と呼んでいます。

人間が委任を行う場合と同様に、これには慎重な検討が必要です。人間の場合、リーダーがチームの強みを理解し、完了前に作業を確認することなどが考えられます。AI にも同様の学習曲線があります。オーケストレーション AI（マルチエージェントシステムの最上位に位置するマネージャー）は、作業を最適に分解して割り当てる方法について複数の計画を検討し、サブ目標を、監視および検証できるほど単純になるまで、より小さなチャンクに分解し続けます。理想的には、すべてを確実に評価できる計画を立てる必要があります。しかし、実際には、これを常に実現できるとは限りません。

場合によっては、期待どおりに作業が完了したかどうかを主観的に評価する必要があるかもしれません。このようなコンポーネントを特定することは、問題にはならず、むしろ、人間の時間をどこに費やすのが最適か、エージェントシステムの監視に人間の専門家の判断をどのように関与させるのが最適かを判断するのに役立ちます。

原則 2: 費用を賢く管理する

この研究フレームワークは、お客様からよく寄せられる「この特定のタスクは、より小さく、より安価なモデルで処理できるか？」という質問に答えるのに役立ちます。企業は費用にますます注意を払うようになっており、それは当然のことです。

パフォーマンスと予算の適切なバランスを見つけるのは難しいことです。給与計算のような複雑な問題を軽量モデルに任せても、期待する結果を得るだけの能力がない可能性があります。また、スプレッドシートの形式の再設定のような単純なタスクを強力な推論モデルにルーティングすることは不必要です。

研究によると、委任についてインテリジェントなエージェントは、このようなシナリオを認識し、各タスクに適したツールまたはエンドポイントを選び、最小限のコストで望ましい結果と最大限の信頼性を実現することを学習します。API ゲートウェイ内のモデルルーティング機能の使用は、クライアントサイドプロキシの使用の代替手段（LiteLLM など）に加えて、お客様の間で人気が高まっています。

モデルルーティングについて詳しくは、こちらをご覧ください。

原則 3: 機密データを尊重する

多くのワークフローは非公開の機密データを処理するため、AI エージェントはそれらの境界と権限を尊重する必要があります。たとえば、給与データ用のオーケストレーターエージェントをデプロイする場合、そのエージェントが一連の情報全体をサブエージェントに渡すことがあってはなりません。これが発生すると、セキュリティが損なわれるだけでなく、エージェントのコンテキストウィンドウが肥大化し、パフォーマンスが低下します。エージェントには、特定の任務を完了するために必要な最小限の権限のみを付与する必要があります。

難しいのは、最初の原則に従って、非公開の情報を明らかにすることなく、作業が確実に完了したことを証明する必要がある場合です。研究によると、ゼロ知識証明などの手法による高度な暗号化が、この問題の解決に役立つ可能性があります。ゼロ知識証明により、一方の AI エージェントが、データ自体を明らかにすることなく、計画された計算が正しく実行されたことをもう一方の AI エージェントに証明できます。たとえば、機密性の高いデータセットの分析を任されたエージェントは、結果の特定のプロパティを証明する簡潔で非インタラクティブな知識の論証を生成できます。これにより、委任者は証明の有効性を即座に検証できます。

原則 4: 無関心圏に注意する

無関心圏とは、アメリカの企業経営者であるチェスターバーナードが 1938 年に著した『The Function of the Executive（経営者の役割）』で用いた造語であり、従業員が疑問を抱くことなくタスクを受け入れる心理的スペースのことを意味します。通常、このタスクは従業員の業務範囲内にあるため、無意識のうちに受け入れてしまいます。たとえば、営業担当者が、重要な顧客との今後のプレゼンテーションに参加するようマネージャーから指示された場合、おそらく反論したり、深く考えたりすることはないでしょう。

研究で示されているように、現在の AI システムは、トレーニング後の安全フィルタとシステム指示によって定義されています。リクエストが重大な違反を引き起こさない限り、モデルはリクエストに従います。しかし、台頭しつつあるエージェント型ウェブを考慮すると、リクエストに従うというこの行動は実際にはシステム上のリスクを生み出す可能性があります。研究で言及されているように、「委任チェーンが長くなると（? → ? → ?）、広範な無関心圏により、微妙な意図の不一致やコンテキストに依存する危害が下流に急速に伝播する可能性があり、各エージェントは責任あるアクターではなく、無思考のルーターとして機能します。」

これは重大な影響を及ぼします。なぜなら、インテリジェントな委任には「動的な認知的摩擦」が必要であることを意味するためです。つまり、エージェントに提供される情報を検証して、その情報が正確で、関連性があり、管理されており、効率的であることを確認する必要があるということです。

このようにして、エージェントは、リクエストがあまりにも曖昧なために、無関心圏から脱却することを正当化し、委任者に異議を唱えたり、人間の検証を要求したりする必要がある場合に、それを認識できます。同様に、人間の参加と監督は、ある程度の認知的摩擦と積極的なエンゲージメントを前提としていますが、システムのユーザーに過度の負担をかけないように、慎重に管理する必要があります。人間の時間は貴重であり、必要な場合にのみ人間の介入を要求する必要があります。

今後の展望

Google Cloud の長期的な目標は、エージェントを組織に自然かつ効率的に統合することです。これは、人間の専門家との間で委任を行い、境界を尊重することを意味します。この組み合わせが、個々のエージェントが対応できる枠を超えたビジネス価値をもたらすと考えています。

エージェント型ウェブをナビゲートする準備ができたら、arXiv で Google DeepMind のレポート「Intelligent AI Delegation」をお読みください。

^{注: この投稿に協力してくれた Google DeepMind の Matija Franklin と Simon Osindero、Google Cloud の Vishal Agarwal と Andrea Morange に感謝します。}

- Google DeepMind、リサーチサイエンティスト Nenad Tomasev

- Google Cloud、応用 AI ブラックベルト Reshu Yadav

業務の再定義: Pythian の社内 AI ハンドブックがもたらす顧客の ROI

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

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

Pythian が 27 か国に展開する 500 人規模の自社全体に Google Cloud の Gemini Enterprise を導入した際、その目的は明快でした。それは、自社を実証の場として、エンタープライズ AI が実際にどのように ROI をもたらすのかを見極めることでした。

そこで得られた知見が、私たちの戦略を根本から変えました。

Gemini Enterprise のロールアウトや、それ以前のエンタープライズ AI のデプロイを通じて、Pythian は、なぜこれほど多くの AI プロジェクトが停滞や失敗に終わるのかを、実体験として目の当たりにしてきました。

ほとんどの組織は、ツール中心の考え方の罠に陥っています。ライセンスを購入してツールを広く展開しさえすれば、価値は自ずとついてくると信じ込んでいるのです。ユーザーあたり 5 分の節約といった些細な効率化を追い求めるあまり、構造的で ROI の高いワークフローの変革を見逃してしまいます。さらに厄介なことに、カスタムエージェントを構築したとしても、AI モデルドリフト、エージェントのライフサイクル、継続的なオブザーバビリティを管理する運用能力がチームに不足しているため、試験運用の段階で停滞したり、本番環境で破綻したりすることが少なくありません。

この課題を解決するために、Pythian は Pythian AI オペレーティングモデルを構築しました。これは、エンタープライズ AI を大局的な戦略策定から持続的な本番運用へと導くために設計された、多面的かつエンドツーエンドのフレームワークです。デュアルセンターオブエクセレンス（COE）が実行の原動力を担う一方で、一貫して数百万ドル規模の成果を引き出しているのは、フィールド CTO 戦略やツールのデプロイからデュアル COE、XOps に至るまで、フレームワーク全体を適用することにほかなりません。

この完全なモデルをまず社内で実証することで、Pythian はアクティブユーザーエンゲージメントを 3 倍に急増させ、データベースインシデントの解決時間を 80% 短縮しました。

Pythian AI オペレーティングモデルの 4 つの柱

エンタープライズ AI の一般的な失敗要因を克服するために、Pythian のフレームワークでは、戦略、実行、運用を 1 つの継続的なループに統合しています。

フィールド CTO 戦略 ──> ツールのデプロイ ──> デュアル COE の実行 ──> 本番環境 XOps

フィールド CTO 戦略とガバナンス: 生成 AI は、IT の歴史において、理論的にも最も難易度の高いアーキテクチャの転換であると言えるでしょう。役員出身の技術リーダー陣が率いるフィールド CTO プラクティスは、経営幹部向けのアドバイザリーを通じて、運営委員会の設立や明確な価値指標の策定を支援します。チームは、16 個の水平方向のエージェント型パターン（ドキュメント処理の自動化やランブックの作成など）を使用して運用を監査し、開発が開始される前に、費用対効果の高いユースケースの優先順位付けされたバックログを構築します。
ツールとプラットフォームのデプロイ: チームは、Gemini Enterprise などのプラットフォーム上に本番環境グレードのセキュアな基盤を確立し、AI を CRM、ERP、データベース資産に直接接続して、実際の企業コンテキストにモデルをグラウンディングします。
デュアル COE: この実行エンジンは、2 つの専門エンジンに分かれています。

従業員の生産性 COE: このグループは、導入とチェンジマネジメントを担当します。技術部門以外のチーム（人事や調達など）が独自のエージェントを構築することを期待するのではなく、この COE は、イネーブルメントに完全に焦点を当てて、これらのチーム向けにノーコードエージェントを構築します。
プロセス生産性 COE: このチームは、自律的な運用のためにコアデータプラットフォームに統合される、高度なカスタムコード AI エージェントと複雑なエージェントワークフローを設計します。

XOps（AI 本番環境管理）: エージェントのデプロイは取り組みの 20% にすぎず、本番環境での精度を維持することが 80% を占めます。AI モデルとプロンプト構造は時間の経過とともに自然に変化するため、この XOps プラクティスは、コアワークフローを中断することなくエージェントのパフォーマンスを維持するために必要な継続的なモニタリング、プロンプトチューニング、モデルのオブザーバビリティを提供します。

散発的な小さい効率化を追求することと、構造的な企業 ROI を推進することの違いは、オペレーティング戦略をどのように調整するかによって決まります。

アライメント要素	ツール中心のアプローチ	Pythian AI オペレーティングモデル
主要な指標	ユーザー 1 人あたりの節約時間	インパクトの大きいワークフローの再定義と ROI
運用の重点	指針のない広範なツール提供	16 のエージェントパターンによる優先順位付けされたバックログ
実行力	ユーザーによるアドホックなテスト	デュアル COE（人材とプロセスの生産性）
本番環境のライフサイクル	モニタリングされていない静的デプロイ	アクティブ XOps（継続的な精度とドリフトの管理）

実際の導入効果: データベース運用からグローバルサプライチェーンまで

70 か所の製造プラント管理であれ、30,000 個のエンタープライズデータベース管理であれ、AI は構造的で価値の高いワークフローに結びついたときに成果を発揮します。

「自らが顧客となる」Pythian の事例: 月間 15,000 件に及ぶデータベースチケットに対し、プロセス COE は、エンジニアが着手する前にチケットの読み取り、ナレッジベースの検索、ミニランブックの自動生成を行うエージェント型ワークフローをデプロイしました。その結果、平均解決時間が 80% 短縮され、アクティブユーザーエンゲージメントが 3 倍になりました。
ナレッジマネジメント企業の顧客: 10,000 人のコンサルタントに自律型 IT サポートエージェントをデプロイしました。その結果、年間 20,000 件の IT チケットの 10% を「ノータッチ」で解決できるようになり、100 万時間以上の運用時間を節約できました。
サプライチェーン企業の顧客: Gemini Enterprise でカスタムのエージェントサプライチェーンツールを構築することで、世界 70 か所の製造拠点で予測マッチングサイクルを数週間から 2～3 日に短縮できました。
小売企業の顧客: Gemini エージェント型 AI とコンピュータビジョンを組み合わせて、店舗の商品オンボーディングを自動化しました。その結果、20 分かかっていた手動タスクを数秒のフローに変換できました。

AI オペレーティングモデルを構築する準備はできましたか？

AI をスケールするには、ツールレベルのテストだけでは不十分です。エンドツーエンドの AI オペレーティングモデルも必要になります。Pythian が Google Cloud と連携して戦略を体系化し、XOps を合理化して、Gemini Enterprise 導入への道のりをどのように加速させるか、ぜひ詳細をご覧ください。

- Pythian、最高技術責任者、Paul Lewis 氏

- Pythian、ビジネス開発担当バイスプレジデント、Vanessa Simmons 氏

Google Antigravity の提供対象を企業のお客様まで拡大

Tue, 01 Sep 2026 02:00:00 +0000

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

5 月の I/O で Gemini Enterprise Agent Platform の Google Antigravity を発表して以来、お客様から有益なフィードバックをいただいています。デベロッパーは、さまざまなサーフェスでコーディングエージェントに簡単にアクセスしたいと考えています。企業ガバナンスチームは、セキュリティ管理とライセンス管理を求めています。財務チームは、プリペイドトークンが未使用のままになることがないよう、使用できるトークンをプールしたいと考えています。このたび、いずれのチームの要望にも対応できるようになりました。

Antigravity は、対象となる Gemini Enterprise app サブスクリプションの一部として提供されます。これには、すぐに利用できる管理機能と支出管理機能が含まれます。
新しい IDE 拡張機能により、デベロッパーは VS Code などの任意の IDE で Antigravity を使用できます。

AI デベロッパーツールとエンタープライズグレードの管理機能を 1 つのサブスクリプションに統合

デベロッパーに高度なエージェントツールを提供するために、アドオンライセンス、請求書、課金コンソール、セキュリティ設定を個別に管理する必要はありません。Gemini Enterprise サブスクリプションに含まれる AI デベロッパーツールを使用すると、管理者は、対象となる Gemini Enterprise Standard、Plus、Standard Emerging Market のライセンスを持つユーザーに対して Antigravity と Android Studio を簡単に有効化でき、Gemini Enterprise 管理コンソールに統合された費用、セキュリティ、オブザーバビリティ、使用状況の指標を使用して、完全なガバナンスを維持できます。

支出を管理しながら、デベロッパーの障害を取り除く

Gemini Enterprise の柔軟な課金および費用管理ツールにより、費用を管理しながら、デベロッパーに必要なリソースを確保できます。

詳細な費用上限: 管理者は、課金コンソールでプロジェクトレベルの月間予算上限を直接設定できます。ユーザーごと、チームごとの追加の管理機能は、今年中にリリースされる予定です。
割り当てのプール: トークンの共有プールにより、需要の高いチームに柔軟性がもたらされ、組織全体で購入した割り当てが使用されずに残ることを防ぎます。
超過分の有効化: プールされた割り当てを使い切ってもデベロッパーのワークフローを継続できるように、管理者は月額費用の上限を設定して超過分を有効にすることで、超過分の使用量を標準の使用量ベースの料金にスムーズに移行できます。
使用状況の指標: 使用状況を一元的に追跡することで、トークンの使用量、API 呼び出し、デベロッパーのアクティビティを可視化し、組織が AI への投資を継続的に最適化できるようにします。

組み込みのプライバシーとセキュリティの機能で組織のコードとデータを保護

Gemini Enterprise サブスクリプションでは、Google Antigravity が Google Cloud の標準的なセキュリティとコンプライアンスの保護の対象となります。管理者と IT チームは、単一のコンソールから、ワークスペースへのアクセスに関する明確な境界を設定し、完全な監査ロギングを有効にして、データプライバシーを適用できます。

構成可能なセキュリティポリシー: ワークスペースのサンドボックス化、ブラウザと MCP サーバーへのアクセスなど、セキュリティとコンプライアンスの管理を適用して、AI エージェントが承認されたエンタープライズ環境内で安全に動作するようにします。
一元的な監査ロギング: 1 回の切り替えで包括的な監査ロギングを有効にし、プロンプト、エージェントの回答、メタデータをキャプチャしてコンプライアンスレポートを作成します。
データプライバシー: Google Cloud の利用規約に基づいてデータの所有権を維持し、すべてのエージェントアクティビティが安全なクラウド境界内で厳密に実行されるようにします。

チームが好む開発環境にエージェントコーディングを直接導入

このたび、デベロッパーは、新しい IDE 拡張機能、Antigravity 2.0 デスクトップアプリ、Antigravity CLI を介して、Visual Studio Code、Visual Studio（プレビュー版）、Jetbrains（プレビュー版）、Zed IDE（プレビュー版）など、すでに使い慣れているサーフェスで Antigravity を使用できるようになりました。

管理者は、すべてのサーフェスで、企業 ID 標準を適用でき、また Workforce Identity 連携（WIF）とアプリケーションのデフォルト認証情報（ADC）のネイティブサポートにより、技術チームのセットアップの煩雑さを解消できます。

AGY IDE 拡張機能のデモ

お客様の声

Google Antigravity は、迅速なコード生成からエンドツーエンドのタスク自動化まで、Google Cloud の安定性、ガバナンス、スケールに支えられた最先端の AI 開発の勢いをエンジニアリングチームに与えています。大手企業のお客様とパートナー様が、本番環境で測定可能な成果をどのように実現しているかをご紹介します。

「Accenture では、Gemini Enterprise に Antigravity をデプロイすることで、Google Cloud の安全で信頼できる基盤上で、Google DeepMind の優れたテクノロジーをエンジニアに提供しています。運用の複雑さを取り除くことで、当社のチームは開発スピードとエンタープライズグレードのガバナンスのどちらかを選ぶ必要がなくなり、お客様に迅速なエンジニアリングと革新的な価値を提供できるようになりました。」- Accenture Google ビジネスグループ、グローバルプラクティスリード、Chetna Sehgal 氏

「AirAsia とグループ全体で、従業員の能力強化に力を入れています。Antigravity 2.0 を使用して、高性能な Gemini モデルを日々のワークフローに直接組み込むことで、まさにそれを実現しています。当社は、ソフトウェアエンジニアリングから、財務、マーケティング、法務、人事などに至るまで、全従業員に最先端の AI 機能を提供しています。これにより、デベロッパーと重要なバックオフィスチームの両方が、これまでにないペースでイノベーションを起こし、全体的に時間を節約できるようになりました。」- AirAsia Next、CTO、Nikunj Shanti 氏

「企業は AI の試験運用から一歩進んで、測定可能なビジネス成果を期待しています。Gemini Enterprise と、Antigravity 2.0 や Antigravity CLI などの次世代デベロッパーツールにより、エージェント型 AI、特に Gemini モデルの高度な推論機能をソフトウェアデリバリーワークフローに直接組み込む大きな機会が生まれています。これは生産性向上にとどまらず、意思決定の迅速化、コード品質の向上、技術的負債の削減を大規模に実現します。特に際立っているのは、これらの機能が、コードの記述から成果のオーケストレーションへとチームを進化させ、ソフトウェア開発ライフサイクルのあらゆるフェーズを強化しながら、安全かつ責任を持ってイノベーションを拡大するのに役立っている点です。」- CGI、アジア太平洋グローバルデリバリーセンターオブエクセレンス担当プレジデント、Rakesh Aerath 氏

「デベロッパーのワークフローはそれぞれ異なります。エンジニアがエージェント型 AI に適応するのではなく、エージェント型 AI がはエンジニアに適応するべきです。Google Antigravity は、デベロッパーが好む IDE、デスクトップアプリ、CLI でサポートされているため、Cognizant はエージェント型エンジニアリングをグローバルデリバリーセンター全体にシームレスに組み込むことができます。これにより、当社のチームは好みのサーフェスを自由に選択しながら、お客様に高速で安全なソフトウェアを提供できます。」- Cognizant India、グローバルオペレーション担当プレジデント兼会長兼マネージングディレクター、Rajesh Varrier 氏

「Antigravity は、Datamatics の AI ファースト戦略を推進するうえで重要な役割を果たしています。この数か月間、当社のチームは Antigravity を使用して、複数のアプリケーションを迅速に構築、デプロイし、ソリューション開発を加速させ、AI をコアビジネスプロセスに組み込んできました。AI Impact Hub から分析ソリューションやセールスイネーブルメントソリューションまで、Antigravity は当社が試験運用段階から実際の実行段階へと移行するうえで役立ちました。その結果、測定可能なビジネス成果を達成し、チームがより迅速かつ大規模にイノベーションを起こせるようになりました。」- Datamatics、情報システムグループ（ISG）担当バイスプレジデント、Vijay Venkatachalam 氏

「Google Antigravity の自律機能を Gemini Enterprise の開発環境に直接組み込むことで、社内チームと現場配置エンジニアリングチームが複雑なタスクを自動化できるようになりました。プラットフォームの新しい FinOps とガバナンス管理に支えられ、当社のチームは、価値が高く、安全で、費用対効果の高い成果をお客様のために大規模にオーケストレートすることに自信を持って集中できます。」— Deloitte、米国 AI / エンジニアリング戦略およびサービスリーダー、Faruk Muratovic 氏

「Wipro は Antigravity を採用したことで、AI 主導のソフトウェア開発ライフサイクルの最先端に立っています。Antigravity 2.0、CLI、新しい IDE 拡張機能を、シームレスなデベロッパーエクスペリエンスおよび優れたコード精度と組み合わせることは、当社の AI ファーストのエンジニアリング戦略に自然に適合します。Google Cloud と連携することで、ソフトウェアデリバリーを加速し、グローバル企業のお客様に次世代の価値を提供できます。」- Wipro、Google パートナーシップ担当バイスプレジデント兼グローバル責任者、Debashish Ghosh 氏

Gemini Enterprise で Antigravity を使ってみる

Gemini Enterprise の Google Antigravity は、対象となる Gemini Enterprise Standard、Plus、Standard Emerging Market のライセンスをお持ちのお客様に、本日よりご利用いただけます。また、まもなく、より幅広いお客様にご利用いただけるようになる予定です。

管理者の場合: 企業向けのセットアップガイドにアクセスして、Google Antigravity と Android Studio の AI デベロッパーツールを有効にすることができます。
デベロッパーの場合: Antigravity 2.0、Antigravity CLI、または Antigravity IDE 拡張機能を介したお好みの IDE で構築を開始できます。

- エンジニアリング担当シニアディレクター、Scott Densmore

- グループプロダクトマネージャー、Damith Karunaratne

Mirendil の事例: トレーニング前後のアプリケーションに AI Hypercomputer のTPU と GPU を活用

Tue, 01 Sep 2026 01:00:00 +0000

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

ほぼすべての大手 AI 研究所が、モデルのトレーニング、エージェントの推論、最先端の研究などに Google Cloud インフラストラクチャを使用しています。Google Cloud は、業界の研究とイノベーションを牽引する急成長中の新興 AI スタートアップから選ばれるプラットフォームであり続けています。

このたび、AI 開発の加速に注力する最先端の AI 研究所である Mirendil も、Google Cloud の AI Hypercomputer を採用することを発表しました。具体的には、Google の TPU AI アクセラレータと、Google Cloud 上で稼働するフルスタックの NVIDIA AI インフラストラクチャを併用し、この専用設計の AI インフラストラクチャによって Mirendil のモデル事前トレーニングと事後トレーニングのアプリケーションをサポートします。

Mirendil チームは、AI の研究開発を加速し、民主化するのに役立つ新しい AI システムを構築しています。これはつまり、初期モデルの事前トレーニングから事後トレーニングまで、複雑なエンドツーエンドのトレーニングワークフローを管理し、大規模な強化学習をサポートすることを意味します。Google Cloud を通じて TPU と、NVIDIA のフルスタックアクセラレーテッドコンピューティングプラットフォームの両方を自在に組み合わせることで、Mirendil は不可欠なコンピューティングに非常に迅速にアクセスし、状況の変化に合わせてワークロードを最適なアーキテクチャに適合させ続けることが可能になっています。

Google は Mirendil と緊密に連携して、コンピューティング、ストレージ、ネットワーク、コントロールプレーンの各層にわたって、TPU と NVIDIA AI インフラを統合した環境の設計からデプロイまでをエンドツーエンドで実施しました。また、Gemini Enterprise Agent Platform で実行されるマネージドトレーニングクラスタを使用するシステム構築でも協力し、Mirendil における TPU と GPU 両環境のプロビジョニングと管理を大幅に効率化しました。Mirendil はすでに TPU v5P チップのクラスタでの運用を開始しており、NVIDIA AI アクセラレーテッドコンピューティングシステムも近日中に稼働を開始する予定です。

Mirendil の共同創業者 / CEO である Behnam Neyshabur 氏は、次のように述べています。「AI の進歩は、実験の設計、結果の評価、反復という研究ループを人間がどれだけ速く実行できるかによって制限されてきました。私たちは、そのループ自体を加速させ、改善することができる AI システムを構築しています。Google Cloud を基盤として拡張することで、システムをさらに進化させ、最先端の AI 研究機能をより多くの科学者やエンジニアの手に届けるためのスケールと柔軟性が得られます。これにより、研究ループをより迅速かつ大規模に回すことが可能になります。」

Google と Mirendil のパートナーシップについて詳しくは、Mirendil のブログをご覧ください。

- Google、グローバルスタートアップおよび投資家エコシステム担当バイスプレジデント、Darren Mowry

金融サービスにおけるエージェント型 AI を活用したオペレーショナルレジリエンスの構築

Fri, 28 Aug 2026 01:00:00 +0000

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

金融機関にとって、オペレーショナルレジリエンスは、消費者の高い期待はもとより、規制当局や監督当局の期待事項として長年織り込まれてきました。欧州連合のデジタルオペレーショナルレジリエンス法（DORA）の施行により、こうした期待は一段と厳格なものとなり、より明確で整合性が取れた、エビデンス重視の要件が課されるようになりました。企業は、重要なビジネスサービスとそれを支えるデジタルインフラストラクチャが、業務の中断に耐え、連携した対応を可能にし、統制を保った状態で復旧できることを実証しなければなりません。

これらの条件を満たすために、Deutsche Bank は AI 搭載のエージェント型レジリエンスプラットフォームを開発しました。これにより、規制に関する机上レジリエンス演習を大規模にモダナイズし、手動で行っていた準備作業を、実際の運用データに基づいたコンテキストアウェアで、かつ即座にエビデンスとして活用可能なシミュレーションへと刷新しました。このプラットフォームは、アーキテクチャ、データフロー、ログ、インシデント履歴、アラートシグナル、運用テレメトリーからエンタープライズコンテキストを構築し、シナリオ、シミュレートされた運用エビデンス、構造化されたセッションレコード、規制当局に対応したアーティファクトを生成します。

相互に依存するアプリケーション、データフロー、サードパーティサービスにまたがる業務を抱える多くの大手銀行にとって、これは重要かつ不可欠な変化です。金融サービス全体で監督当局の期待が高度化するなか、銀行の机上演習においても、本番環境の依存関係や実際の運用条件、そして一貫したエビデンス基準への準拠を、より直接的に反映させることが求められています。

Deutsche Bank は、この移行を大規模かつ効率的に成功させる方法を検討するにあたり、長年のパートナーである Google Cloud と、その拡大するエージェント型 AI ツールのスイートに注目しました。

机上演習からレジリエンスインテリジェンスへ

Deutsche Bank は、エージェント型レジリエンスプラットフォームを活用することで、従来の手動による準備を伴う机上演習を、継続的なインテリジェンスモデルへと進化させました。さらに、実際の運用コンテキストが必要な場合には、この同じエージェントレイヤを根本原因分析にまで拡張して活用できるようになっています。

つまり、実行されるすべてのシナリオが、実際のエンタープライズシグナルに基づいたものとなっています。これにより、リアルタイムのインサイトよりも推測に陥りがちな「静的な入力」に頼るのではなく、実際のシステム依存関係や障害パターン、ビジネスへの影響を正確に反映できるようになります。

Gemini Enterprise Agent Platform を使用することで、Deutsche Bank はこの運用コンテキストを、明確なタイムライン、意思決定ポイント、予想される回答を含む構造化されたシナリオに移行できました。これにより、各演習は実際のシステム動作に基づいたものとなり、規制当局の期待に応える、一貫性のある監査対応のエビデンスを確実に生成できるようになっています。

制御と柔軟性を実現するデュアルオーケストレーション

規制当局レベルの制御と運用の柔軟性を両立させるため、Deutsche Bank のプラットフォームには、ワークフローを 2 つの補完的な実行モデルに分離するデュアルオーケストレーションアーキテクチャが採用されました。

まず、規制に準拠した実行を実現するため、同行は LangGraph を活用しています。これにより、入力コンテキストから出力まで明確なリネージを備えた、追跡可能かつ決定論的なプロセスを通じてすべてのシナリオを生成し、監督審査で求められる監査可能性を担保しています。

次に、適応型シナリオと調査型シナリオについては、Google Agent Development Kit（ADK）を使用してエージェント主導の連携を実現しています。このアプローチにより、同行のプラットフォームは、あらかじめ実行パスを定義しておく必要がなく、状況を動的に分析して回答を生成できるようになります。

図 1. コンテキストアセンブリ、オーケストレーション、シナリオ生成のアーキテクチャ。

このアーキテクチャ上の分離により、プラットフォームは共通のインテリジェンスレイヤを維持しながら、統制された実行と適応型の調査を組み合わせることができます。同一のエージェントとツールを使用して、机上演習シナリオの生成から関連するインシデント分析ワークフローに至るまで、アーキテクチャ、データフロー図、ログ、コードアーティファクトを横断的に推論できます。重要なのは、計画された演習と実際の運用イベントの両方で一貫したレジリエンスモデルがサポートされることです。

「Deutsche Bank がこのプラットフォームで目指したのは、極めて複雑な分散環境においても、規制当局の期待に応える重要金融システム向けのレジリエンスモデルを構築することでした。動的に生成されたシナリオを実際のビジネスコンテキストに結びつけ、統制されたオーケストレーションと適応型の分析を組み合わせることで、このプラットフォームは、オペレーショナルレジリエンスのためのインテリジェントで継続的に適応可能なモデルを当行にもたらしました。」- Deutsche Bank、マネージングディレクター、監視テクノロジーおよびコンプライアンスクラウド担当グローバル責任者、AI トランスフォーメーションリード、Sanjay Tripathi 氏

Google Cloud で生成とガバナンスを強化

Google Cloud のエージェントツールスイートは、Deutsche Bank のプラットフォームを、管理されたエンタープライズグレードのレジリエンスワークフロー全体にスケールするための基盤を提供しています。その仕組みは次のとおりです。

Cloud Run が、シナリオおよびエビデンス生成サービスの弾力的な実行をサポートします。
Gemini Enterprise Agent Platform が、運用コンテキストを構造化されたレジリエンスシナリオに変換します。
Google ADK が、適応型エージェントの連携を可能にします。
Cloud SQL が、シナリオ、セッションアーティファクト、レビュー記録に対して、高い耐久性と永続性を提供します。

これらのサービスを組み合わせることで、コンプライアンスレビューと継続的な改善に不可欠な、追跡可能な生成、制御された実行、永続的なエビデンス記録の保持を、Deutsche Bank が実現できるようになります。

スケーラブルでエビデンス対応のレジリエンステスト

Deutsche Bank のプラットフォームで生成されるあらゆるシナリオは、対応、エスカレーション、復旧を担うチームの構造化された机上演習セッションを推進します。これらの演習は実際のエンタープライズコンテキストに基づいているため、運用の実態を反映すると同時に、チーム間の一貫性を強化し、規制当局の期待に応える監査対応のエビデンスを生成します。これにより、DORA や同様のフレームワークの規制下にある金融機関にとって、統制され、連携の取れた、規律ある対応を大規模に実証することが容易になります。

このモデルは現在、Deutsche Bank の複数のポートフォリオに適用されており、同行がより一貫性のあるスケーラブルなレジリエンスパラダイムを確立し、金融セクター全体で活用できる再現可能なブループリントを構築する一助となっています。

このモデルでは、根本原因分析が実際のインシデントと将来のレジリエンステストの間のフィードバックループとして機能します。本番環境のイベントから得られたインサイトは、将来の机上演習シナリオに反映させることができます。また、演習の結果は、対応ハンドブック、エスカレーションパス、復旧準備の強化に役立てられます。

こうした一連の取り組みにより、シナリオベースのレジリエンステストを主なユースケースとして維持しつつ、計画的なレジリエンス演習から実際の運用イベントに至るまで、プラットフォームの価値が拡張されます。

導入が拡大するにつれて、このプラットフォームはコンテキストアウェアなレジリエンスに関する Google Cloud の手法を組み込むことで、運用の一貫性をもたらします。また、断片的な手動アプローチを解消し、同行全体で部門横断的な AI 活用型運用モデルを確立します。

レジリエンスインテリジェンスに向けて

同行の次のステップは、このアプローチをより広範なレジリエンスインテリジェンスレイヤへと拡張することです。同じパターンを展開することで、ハンドブックの改良、復旧準備の評価、そして刻々と変化するシステム状況に対する制御の継続的検証が可能になります。

金融機関にとって、これは戦略的な転換です。システムの分散化が進み、規制当局からの要求が厳しさを増すなか、銀行は定期的なレジリエンステストから、インテリジェンス主導の継続的な対応能力へと移行する必要があります。Deutsche Bank では、Google Cloud によって組織全体でこの移行を簡単に行うことができています。

コンテキストアウェアなレジリエンスに関する Google Cloud の手法について詳しくは、こちらの記事をご覧ください。

- Deutsche Bank、エージェント型レジリエンスプラットフォーム - ディレクター兼リードアーキテクト、Pankaj Ojha 氏

- Google Cloud コンサルティング、スタッフソリューションコンサルタント、Florian Graf

Google Dataflow で費用対効果に優れた高スループットな生成 AI ワークフローを構築する

Thu, 27 Aug 2026 02:00:00 +0000

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

リアルタイムストリーミングパイプラインは現代の企業において運用のバックボーンとなっており、カスタマーサポートでのやり取りからトランザクションログまで、あらゆるデータを処理し続けています。従来のストリーミング DAG は静的なものであり、一度デプロイされると、その処理ロジックや実行パスは変更できなくなります。しかし、生成 AI エージェントを統合すれば、静的なロジックから適応型の実行へと移行することが可能です。これにより、データの内容に応じてストリーミングワークフローが実行時にプランを動的に立案し、データベースへのクエリや独自の修復処理を自律的に開始できるようになります。

たとえば、注文品の破損について顧客から不満を示すメッセージが届いた際、パイプラインの役割は単なるエラーログの記録や、ダッシュボードへのフラグ立てにとどまるべきではありません。顧客の注文と在庫の記録を保持するデータベースで注文情報を検索し、修復アクション（交換品の発送や払い戻しなど）を自ら判断して、顧客へのメール送信から最終的な対応結果の記録までを一貫して行うべきです。

しかし、生成 AI ワークフローをストリーミングシステムに実行しようとすると、スケール、レイテンシ、コストという、エンジニアリング上の根本的な障壁に直面することになります。すべての未加工イベントを、外部データベースとメールツールを備えた高負荷なモデルやマルチステップエージェントに直接送信すると、コストが跳ね上がり、レイテンシも増大します。また、API のレート制限もすぐに使い果たしてしまいます。

ここで紹介するパターンは、Google Dataflow（Google Cloud が提供する Apache Beam のフルマネージドサーバーレス実行サービス）と Agent Development Kit（ADK）を組み合わせてハイブリッドストリーミングパイプラインを構築することで、スケーラビリティと複雑さという課題に対処します。軽量で CPU バウンドな ML モデルをアップストリームで使用してイベントをフィルタリングし、評価することで、パイプラインの費用対効果を高く保ち、複雑なケースのみをダウンストリームエージェントにルーティングします。ケースを受け取ったエージェントは、実行するアクションを動的に決定し、パイプラインの静的 DAG に膨大な数の条件付きステップをハードコードすることなく、ストリームに動的分岐を導入します。

大規模ストリーム向けのユニバーサルなブループリント

以下ではカスタマーサポートにおけるトリアージのシナリオを例にしていますが、この「事前フィルタ + エージェントによるアクション」というパターンは、幅広い分野に適用できる普遍的モデルです。このパターンは、イベントの大多数（90% 超）が定型的であり、複雑なコンテキスト推論を必要とするイベントはごくわずかである、以下のようなストリームに適用できます。

IT 運用と DevOps: 数百万件の定型的なシステムログを CPU 上でフィルタリングし、重大な異常が検知された場合にのみエージェントをトリガーして診断を実行し、バグチケットを開く。
金融詐欺のトリアージ: 数百万件のトランザクションを軽量なローカルルールでスクリーニングし、疑わしいパターンが検出された場合にのみエージェントを呼び出してマルチデータベース検索ツールを実行する。
産業用 IoT: エッジで定常的なテレメトリーをモニタリングし、突発的な異常をエージェントにルーティングして、機器のシャットダウンやフィールドエンジニアへの通知など一連の対応を調整する。

アーキテクチャ: ストリーミングイベントを事前にフィルタする理由

高スループットなストリームの場合、メッセージの大部分は複雑な推論や修復を必要としません。その多くは、肯定的なフィードバック、中立的な問い合わせ、単純な質問などです。

すべてのイベントを高負荷な LLM ワークフローにルーティングすると、主に 3 つのボトルネックが発生します。

API のコスト: フロンティアモデルはトークン単位で課金されます。高スループットの場合、コストはストリームのボリュームに比例して増加します。
レイテンシ: データベース参照や外部 API 呼び出しを含むマルチステップワークフローには数秒かかるため、ストリーミング DAG のボトルネックになります。
割り当て: 外部 API には厳格なレート制限があり、ストリーミングワーカーがその枠をすぐに使い切ってしまうおそれがあります。

これを防ぐため、Apache Beam と Dataflow を使用して、事前フィルタリングされたパイプラインを構築します。

パイプラインフロー

取り込み: Google Pub/Sub から未加工の顧客メッセージを読み取ります。
軽量の感情分類器（CPU）: Apache Beam の RunInference 変換を使用して、軽量の CPU ベースの Hugging Face モデル（distilbert-base-uncased-finetuned-sst-2-english）ですべてのメッセージを処理します。これは Dataflow ワーカーの CPU でローカルに実行されるため、外部 API の費用は発生しません。
事前審査ゲート: シンプルな DoFn でストリームをフィルタします。感情が POSITIVE または NEUTRAL と判定されたメッセージは、確認応答を返したうえで破棄されます。
自動修復（ADK）: メッセージが NEGATIVE に分類された場合にのみ、ADKAgentModelHandler を介して gemini-3.5-flash を基盤とする生成 AI エージェントをトリガーします。エージェントは各種ツールを活用して、BigQuery でのユーザー検索、注文情報の取得、対応策の選定、Gmail API を介した通知メールの送信までを自律的に実行します。

適応的実行: Beam DAG の動的な構成

従来のストリーミングアーキテクチャでは、パイプラインの有向非巡回グラフ（DAG）は固定されています。Dataflow にデプロイされると変換のシーケンスが固定されるため、新しいタイプのアラートを処理したり、特定のイベントのルーティング方法を変更したりする必要が生じた場合はパイプライン全体を変更、テスト、再デプロイする必要があります。

感情の事前フィルタのダウンストリームに生成 AI エージェントを配置することで、静的な DAG 内に動的で適応性のあるノードを導入できます。

全レコードの 95% を占める肯定的または中立的なデータは、パイプライン上の高速な静的パスに沿って処理されます。しかし、フィルタがネガティブなレコードを検知すると、エージェントはペイロードを評価し、実行時に API ツールの適切な実行順序（データベースへのクエリ、在庫確認、メール通知など）を動的に選択します。これにより、パイプラインで複雑な決定木を動的に実行できるようになり、静的な Apache Beam コードに膨大な数の条件分岐をハードコードして構築、保守し続けるといった煩雑な作業が不要になります。

パイプラインの実装

Google Agent Development Kit（ADK）と RunInference フレームワークを活用した Apache Beam での実装例を以下に示します。

1. 軽量な感情モデルの定義

HuggingFacePipelineModelHandler を使用して、アップストリームの CPU モデルを定義します。このモデルは、ワーカーインスタンス上で感情を POSITIVE、NEUTRAL、NEGATIVE に分類します。

code_block: <ListValue: [StructValue([('code', 'model_handler = HuggingFacePipelineModelHandler(\r\n task="sentiment-analysis",\r\n model="distilbert-base-uncased-finetuned-sst-2-english"\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6e5a35a290>)])]>

2. 高負荷な ADK エージェントの構築

ADK エージェントは修復アシスタントとして機能します。このエージェントに、次の 3 つのツールを実装します。

lookup_user: BigQuery に顧客のメールアドレスをクエリします。
lookup_orders: BigQuery に顧客の注文と現在の商品在庫をクエリします。
send_email: Gmail API を使用して対応メールを顧客に送信します。

code_block: <ListValue: [StructValue([('code', 'def make_adk_tools(project: str, dataset: str = "sentiment_demo"):\r\n def lookup_user(user_id: int) -> dict:\r\n """Look up user information (email address) from BigQuery by user ID."""\r\n from google.cloud import bigquery\r\n\r\n client = bigquery.Client(project=project)\r\n query = (\r\n f"SELECT user_id, user_email "\r\n f"FROM `{project}.{dataset}.users` "\r\n f"WHERE user_id = @user_id"\r\n )\r\n job_config = bigquery.QueryJobConfig(\r\n query_parameters=[bigquery.ScalarQueryParameter("user_id", "INT64", user_id)]\r\n )\r\n try:\r\n results = list(client.query(query, job_config=job_config).result())\r\n if results:\r\n row = results[0]\r\n return {"user_id": row.user_id, "user_email": row.user_email}\r\n return {"error": f"No user found with user_id={user_id}"}\r\n except Exception as exc:\r\n return {"error": str(exc)}\r\n\r\n def lookup_orders(user_id: int) -> dict:\r\n """Look up a user\'s orders and current product inventory from BigQuery."""\r\n from google.cloud import bigquery\r\n\r\n client = bigquery.Client(project=project)\r\n query = (\r\n f"SELECT p.order_id, p.product_id, pr.remaining_inventory, pr.price "\r\n f"FROM `{project}.{dataset}.purchases` p "\r\n f"JOIN `{project}.{dataset}.products` pr ON p.product_id = pr.product_id "\r\n f"WHERE p.user_id = @user_id"\r\n )\r\n job_config = bigquery.QueryJobConfig(\r\n query_parameters=[bigquery.ScalarQueryParameter("user_id", "INT64", user_id)]\r\n )\r\n try:\r\n results = list(client.query(query, job_config=job_config).result())\r\n orders = [\r\n {\r\n "order_id": row.order_id,\r\n "product_id": row.product_id,\r\n "remaining_inventory": row.remaining_inventory,\r\n "price": float(row.price),\r\n }\r\n for row in results\r\n ]\r\n return {"orders": orders}\r\n except Exception as exc:\r\n return {"error": str(exc)}\r\n\r\n def send_email(to_address: str, subject: str, body: str) -> str:\r\n """Send a plain-text email to the customer via the Gmail API."""\r\n import google.auth\r\n import googleapiclient.discovery\r\n import email.mime.text\r\n import base64\r\n\r\n try:\r\n creds, _ = google.auth.default(\r\n scopes=["https://www.googleapis.com/auth/gmail.send"]\r\n )\r\n service = googleapiclient.discovery.build("gmail", "v1", credentials=creds)\r\n\r\n mime_msg = email.mime.text.MIMEText(body)\r\n mime_msg["to"] = to_address\r\n mime_msg["subject"] = subject\r\n raw = base64.urlsafe_b64encode(mime_msg.as_bytes()).decode("utf-8")\r\n service.users().messages().send(userId="me", body={"raw": raw}).execute()\r\n return "Email sent successfully"\r\n except Exception as exc:\r\n return f"Failed to send email: {exc}"\r\n\r\n return [lookup_user, lookup_orders, send_email]'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6e5a026750>)])]>

LlmAgent を構成し、ADKAgentModelHandler に組み込みます。

code_block: <ListValue: [StructValue([('code', 'adk_agent = LlmAgent(\r\n name="remediation_agent",\r\n model="gemini-3.5-flash",\r\n instruction=(\r\n "You are a customer service remediation assistant with access to "\r\n "BigQuery lookup tools and an email sending tool. "\r\n "When given a prompt describing a customer situation, follow the "\r\n "numbered steps exactly and use your tools to complete the task."\r\n ),\r\n tools=adk_tools,\r\n)\r\n\r\n# RunInference handler for the ADK agent\r\nadk_handler = ADKAgentModelHandler(agent=adk_agent)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6e5a024c50>)])]>

3. Dataflow DAG の組み立て

パイプライン全体を明確に定義します。アップストリームの感情推論の結果はフィルタリングステップ（FilterNegativeADK）に直接渡され、フィルタリングステップはダウンストリームの ADKInference を条件付きで実行します。

code_block: <ListValue: [StructValue([('code', 'with beam.Pipeline(options=pipeline_options) as p:\r\n # 1. Read from Pub/Sub and classify sentiment on CPU\r\n sentiment_results = (\r\n p\r\n | "ReadFromPubSub" >> beam.io.ReadFromPubSub(topic=known_args.input_topic)\r\n | "DecodeMessages" >> beam.Map(lambda x: x.decode(\'utf-8\'))\r\n | "SentimentInference" >> RunInference(model_handler)\r\n )\r\n\r\n # 2. Filter out non-negative sentiment and invoke the ADK Agent\r\n _ = (\r\n sentiment_results\r\n | "FilterNegativeADK" >> beam.ParDo(FilterNegativeAndPromptADK())\r\n | "ADKInference" >> RunInference(adk_handler)\r\n | "LogADKResults" >> beam.ParDo(LogADKResponse())\r\n )'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6e5a024d50>)])]>

コストとパフォーマンスのメリット

このフィルタリングステップを導入すると、エンジニアリング面と運用面の両方で大きなメリットがあります。

1. 大幅なコスト削減

すべての受信イベントに対して料金を支払うのではなく、顧客のネガティブな感情が含まれる一部のメッセージ（通常は 5% 未満）に対してのみ Gemini の入出力トークンの料金を支払うだけで済みます。残りの 95% は CPU インスタンスでローカルに分類されるため、API の追加費用はかかりません。

2. 高いストリーミングスループット

Dataflow は、CPU による分類ワークロードを多数のインスタンスに分散して処理します。CPU 推論はミリ秒単位で完了するため、パイプラインを水平方向にスケールして高スループットのイベントストリームを処理できます。ツール実行のためにリクエストごとに数秒を要する高負荷な LLM エージェントは、呼び出し回数を最小限に抑えることで、バックログの発生を防いでいます。

3. ネイティブな Apache Beam 統合

DAG にエージェントを追加するのに、複雑なオーケストレーションロジックや手動のスレッドプールは一切必要ありません。ADKAgentModelHandler を Beam ネイティブの RunInference 変換と併用することで、並列ワーカースレッド、バッチ処理、統合の処理が自動化され、コードベースをクリーンでメンテナンスしやすい状態に保てます。

重要ポイント

ストリーミングデータは高速かつ大量であるのに対し、高負荷な生成 AI 推論は低速でコストがかかります。

Google Dataflow と ADK を使用して事前フィルタリングを組み込んだパイプラインを構築することで、ローカルの CPU ベースのモデルが持つ「低コストとスピード」、そして Gemini を活用したエージェントの「高度な自動化機能」という両方の長所を最大限に引き出すことができます。

完全なコードベースを参照してご自身でデプロイしてみる場合は、next-2026-demo GitHub リポジトリをご確認ください。

^{Apache Beam は Apache Software Foundation の商標です。}

- グループプロダクトマネージャー、Reza Rokni

- Google Cloud、ソフトウェアエンジニア、Danny McCormick

AI 時代の FinOps：エージェント向けの新しい柔軟な請求と費用管理

Thu, 27 Aug 2026 02:00:00 +0000

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

AI がより複雑な業務を担うようになる中、ビジネスリーダーは、利益率と予算を守りながら、エージェントを活用して迅速なイノベーションを可能にするという新しい課題に直面しています。AI から投資対効果を得るには、技術の進化にあわせて財務運用 (FinOps) とともに費用管理も進化させる必要があります。これにより、明確なコストの可視化、プロアクティブなコスト統制、ニーズに合った柔軟な支払いモデルの実現が可能になります。

本日、Gemini Enterprise 全体にわたるエージェントワークロード、ならびに Google Antigravity in Gemini Enterprise や Android Studio といったデベロッパーツール向けに、請求を柔軟にする支払いオプションと新しい費用管理ツールを発表します。

柔軟な支払いオプション：既存の予測可能なユーザー単位のシートサブスクリプションと、Gemini Enterprise app の新しい従量課金オプションを組み合わせることができます。これにより、タスクの途中で制限に達することなく、エージェントワークロードを実行できます。
デベロッパーへのアクセス権と AI の一括管理：Google Antigravity および Android Studio での AI 利用が Gemini Enterprise のサブスクリプションに含まれるようになりました（一部のお客様に提供中、他のお客様には順次提供予定）。これにより、管理負担を増やすことなくデベロッパーにより多くの機能を提供できます。Google Antigravity、プラットフォーム、アプリにわたる利用状況は、個別ライセンスや請求でサイロ化されず、単一のビューに集約されます。
用量の増加に応じた割引：AI ワークロードが安定している、または増加している場合、 Flexible Savings Plans を利用することで、許容できる月額支出にコミットし、トークン費用を 10〜20% 削減できます。最低額や上限額の条件はなく、新しい請求サイロの管理も発生しません。
統合された支出ガードレール：AI 支出やプロジェクトに月額の上限を設定し、エージェントの実行費用を見積もり、請求書に反映される前に予期しない予算の急増を検知できるようになりました。

Gemini Enterprise の支出をコントロールしながらチームに柔軟性を提供

企業ごとに組織運営の方法は異なります。また同じ企業内であっても、AI の利用方法はチームによって様々です。ビジネスユーザーは日常的な生産性ツールを継続的に使用する傾向にある一方で、技術チームは AI エージェントワークロードを短期間に集中して実行することがあります。

実際の業務の進め方に費用を適合させるため、以下の支払いおよびライセンスの選択肢を Gemini Enterprise の各機能と組み合わせることができます。

オプション	仕組み	費用最適化に役立つ理由
Gemini Enterprise app のユーザー単位シートサブスクリプション	ユーザーごとに一定の月額料金を支払います。これにはプロジェクト全体で共有される毎日の割り当てプールが含まれます。	予測可能な予算：日々安定した生産性ニーズを持つチーム向け。財務経理部に明確な月額費用を提供します。
【新機能】従量課金制 Gemini Enterprise app *一部のお客様に提供中、他のお客様には順次提供予定	前払い契約や基本サブスクリプション料金はなく、標準モデル API レートに基づき、チームが消費したコンピューティングとトークンの分のみを厳密に支払います。	使用した分のみ支払い：支出は実際の利用状況に応じて自動的に増減するため、プロジェクトの需要が低下したときに利用されていない社員の料金を支払う必要がありません。
【Google Antigravity in Gemini Enterprise の向け新機能】統合されたプール割り当て	日々の利用上限はプロジェクト全体でプールされ、ビジネスアプリ、デベロッパーツール、カスタムエージェントはこの共有枠から消費します。プールされた割り当てが常に優先して消費されますが、管理者は超過利用を許可するかどうかを制御でき、許可した場合の超過分は従量課金レートで請求されます。	リソース利用の効率化：ビジネスユーザーの未使用の制限枠を、デベロッパーやカスタム API エージェントの負荷の高いワークロードに自動的に、割り当てられるため、日々の制限枠が無駄になりません。
【今後提供開始】遅延実行価格 *一部のワークロード向けに提供予定	対象となるエージェントワークロードを遅延実行として指定すると、Gemini Enterprise Agent Platform のインテリジェントスケジューラがオフピーク時間帯のキャパシティで実行します。	急がない業務の大幅な割引：AI ワークロードを分離されたオフピーク容量で実行できるため、推論コストを半額程度に抑えつつ、標準の割り当てを使わずにすむため、同じ予算内で大幅に多くのエージェントワークロードを実行できます。

単一の Gemini Enterprise サブスクリプションで高度なエージェントツールをデベロッパーに提供

Google Cloud は、Google Antigravity in Gemini Enterprise を提供開始しています。Google Antigravity in Gemini Enterpriseは、高度なエージェントコーディングおよびエージェント構築機能を技術チームにもたらすエージェントファーストのデベロッパープラットフォームで、対象となるお客様の Gemini Enterprise サブスクリプションに含まれます。さらに、Android デベロッパーは、プロフェッショナルな Android 開発向けのエージェント IDE である Android Studio 内で、 Gemini Enterprise サブスクリプションに含まれる Google Antigravity の割り当てをネイティブに活用できます。

エージェントコーディングの費用効率を高めるため、各 Gemini Enterprise サブスクリプションに含まれるデベロッパーツールの割り当てをプール化し、Google Cloud プロジェクト全体で利用できるようにしています。これにより、チームは購入済みのキャパシティを無駄なく活用できます。一元化されたガバナンスと管理を維持しながら、デベロッパーに高度なエージェントツールを提供できます。Google Antigravity in Gemini Enterprise の新機能や、お客様による本番環境での活用事例の詳細については、こちら（英語）をご覧ください。

Gemini Enterprise Flexible Savings Plans（FSPs）でよりスマートに予算を管理

企業の AI ワークロードが安定または増加している場合、Gemini Enterprise Flexible Savings Plans（FSPs）は、Gemini Enterprise 全体の利用に対してシンプルな利用額ベースのモデルを提供します。FSPs は、予算の柔軟性を維持しながらトークン費用を削減するように設計されています。

プログラムによる割引：Gemini Enterprise 全体の月額利用額に対し、1 年間の約定で 10% 割引、3 年間の約定で 20% 割引を受けられます。
ペースに合わせて調整：最低利用額や上限額の条件がないため、現在のトラフィックに合った月額コミットメントを決め、利用量の増加に合わせて調整できます。
Enterprise Agreement（EA）に対応： FSPs の利用額は、既存の Google Cloud EA の枠からシームレスに消化されるため、全体的なクラウドの約定枠を細分化することなく、各事業部門専用の予算管理が可能です。

Gemini Enterprise Flexible Savings Plans は、セルフサービスのお客様およびエンタープライズ契約をご利用のお客様に提供を開始しています。

財政規律を維持しながらチームに構築の自由を提供

ビジネスリーダーとしての目標は、AI の潜在的な価値を制限することではなく、管理されていない AI 費用によって発生する財務上および運用上のリスクを取り除くことです。エンジニアリング、マーケティング、運用の各チームにエージェントを活用したイノベーションの自由を与えつつ、それらのエージェントの挙動を信頼できる可視性と、予算を保護するセーフティネットを確保する必要があります。

このギャップを埋めるため、Google Cloud Billing Console 内に 3 つの明確な目標に基づいた堅牢なネイティブガバナンスツールを構築しました。

プロジェクト開始前に費用試算：Google Cloud Pricing Calculator を使用すると、ユーザー単位のライセンス、デベロッパーツール、バックグラウンドエージェントのランタイム全体にわたる Gemini Enterprise の見込み費用を試算できます。プロジェクト業務の開始前に、必要な予算を確認できます。
支出を細かく管理せずにしきい値を設定：プロジェクトチーム全体の日々の利用変動を管理するため、以下のツールにモニタリングを依頼することができます。
- 早期の異常検知：プロジェクトの AI 支出が通常より高くなる傾向を示した場合、システムは根本原因分析とともに異常値をフラグ付けし、増加の原因となっている上位 3 つの SKU を特定します。これにより、何が変化したのかを正確に把握できます。

Billing Console に表示された初期異常アラートと、原因の主なSKUを強調表示した根本原因分析（RCA: the Root Cause Analysis）の内訳

プロジェクトレベルの支出上限：プロジェクトで明確な予算上の制限が必要な場合、Google Cloud Billing Console で直接、確実な月額支出上限を設定できます。プロジェクトが上限に達すると、エージェントの API 呼び出しが一時停止し、本番インフラストラクチャに影響を与えることなく予算を保護します。また、予算の 50%、80%、100% に達した際に送信される自動メールアラートにより、支出上限に対する進捗状況を把握できます。
超過利用コントロール：支出上限に達し処理が停止した場合でも、コンソールで 1 クリックで業務を再開できます。継続的な運用を優先する場合は、超過利用を有効にして超過利用分を従量課金レートへとスムーズに移行させることができます。この超過分は FSPs から直接引き落とされるため、超過単価には大幅な割引価格を維持できます。

プロジェクトの従量課金による超過利用の有効化

3. ビジネス価値の可視化：統合された請求レポートを FinOps エージェントと組み合わせて使用することで、予算の支出先に関するインサイトを自然言語で生成し、経営陣に ROI を簡単に提示できます。

Google Cloud Console における AI 支出レポート

AI 費用の最適化をさらに深めるには

モデルとインフラストラクチャの費用、レイテンシ、パフォーマンスを最適化するフルスタックの FinOps 戦略を構築するには、詳細なアーキテクチャ仕様とフレームワークをご覧ください。

動的な容量管理によりインフラストラクチャの制約を克服する方法： Google Kubernetes Engine および Google Compute Engine の機能を活用してコンピューティング投資を最適化する方法をご紹介します。これらの機能は、リソースを自動的にスケジュールおよび再割り当てし、中断、過剰なプロビジョニング、特定のハードウェア構成への過度な依存を回避します。
エンタープライズのお客様向けに Google Antigravity を拡張：技術チームがエージェントファーストのワークフローによってソフトウェアのデリバリーをどのように加速しているか、デベロッパーツールに関する詳細解説ををご確認ください。
スポーツカーから学ぶ AI 支出最適化：トークン数が多ければ常に優れた AI になるとは限りません。Gemini Enterprise Agent Platform プロダクトマネジメントディレクターである Mike Clark との対談で、馬力と効率のバランスをとり、AI への投資からより高いリターンを得る方法をご覧ください。
利用スパイク時の保護：負荷の大きいワークロードは、それ以外の時間にアイドル状態となる高価な専用インフラストラクチャの料金を支払うことなく、ピーク時に急増させることができます。AI の利用が拡大しても、Gemini モデルは人工的なレート制限に達することなくオンデマンドで自動的にスケーリングし、1 分あたり最大 5,000 万トークンを処理できます。プロビジョンドスループットの詳細をご覧ください。

Malachyte がマネージドリアルタイム AI で小売業のコールドスタート問題を解決した方法

Thu, 27 Aug 2026 01:00:00 +0000

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

未知の潜在顧客に商品をすすめるには、どのような方法が最適なのでしょうか。

私たちは、Spotify や Priceline などの大手企業とともに、長年この問題の解決に取り組んできました。そして、Sidd Motwani を中心に、AI を活用した e コマースのレコメンデーションプラットフォーム Malachyte を創設したのも、まさにこの問題を解決するためでした。最近では、消費者はパーソナライズされて関連性の高いコンテンツを期待するようになり、オンラインサービスは消費者の関心を集めるために競わねばならず、その結果がビジネスの成否を左右するまでになっています。

Malachyte は、高度な AI モデル、特に大規模言語モデルを、パーソナライズやレコメンデーションといった従来の課題に新しい方法で適用する独自のインサイトを見い出し、それが革新を生むきっかけとなりました。

さらに、潜在顧客の獲得を目指すうえで、Malachyte が常に思い描いていたビジョンを実現し、パーソナライズアルゴリズムを構築し続けるには、セキュアかつスケーラブルで信頼性が高く、何よりも最先端の AI インフラストラクチャが必要でした。そこで、Bigtable や Managed Service for Apache Kafka などの Google Cloud ツールを活用することで、Malachyte は小売業者の売上を 2 倍、場合によっては 3 倍に増やすことに成功したのです。

ここでは、Malachyte がそのプラットフォームをいかにして構築したか、そして、企業家の皆様がこのようなサービスを利用して AI 基盤モデルのデプロイを新しい方法で開始するにはどうすればよいか、ご紹介します。

Malachyte はお客様の売り上げをどのように伸ばしたのか

Malachyte には、アテンションメカニズムを備えたニューラルネットワーク（大規模言語モデルを支えるのと同じコンセプト）を使用して、小売検索と商品ページをパーソナライズできることを発見したときがひらめきの瞬間でした。このアプローチは、大規模言語モデル（LLM）でシーケンス内のアイテムの相対的な順序から意味を引き出すために使用されています。この場合、シーケンスは文中の単語と音節の順序です。Malachyte は、これを小売業のウェブサイトやアプリに応用し、顧客がサイトを操作する際の一連の行動の把握に努めました。

LLM が文の次の単語を予測するように、e コマースサイトでユーザーが次に何を求めているかを予測できたらどうでしょうか。

GPT 以前の言語モデルでも、単語や単語の断片（現在ではトークンとして知られているもの）の特定の並びを調べることは可能でした。しかし、それらの初期のモデルでは、単語が同等の順序で並んでいても、連続していなかったり、並べ替えられていたりした場合にどうなるかを調べることはできませんでした。この状況が打破されたのは、LLM がアイテムのシーケンス内の複雑で広い範囲の依存関係を理解できるようになったときでした。これには、Google の Transformer に関する取り組みも部分的に貢献しています。

このより洗練された手法は、生成 AI の一般的な普及はもちろん、Malachyte によるこのテクノロジーの応用という点でも、劇的な成果をもたらしました。

これを実践で機能させるために、Malachyte はユーザーがサイトにアクセスしたときに、そのユーザーについて知り得るすべての情報をベクトル化しています。ほとんどのユーザーは初めてサイトを訪れるため、ユーザーに関する情報はほぼありません。これが、いわゆる「コールドスタート」問題です。これに対応するには、ユーザーとのあらゆるやり取りをすべて活用して、このベクトルを改良する必要があります。たとえば、クリックやクエリなど、ベクトルに新しい要素が追加されるたびに、ユーザーが次に何を求めているかの予測が促進され、ユーザーに関する情報がさらに提供されます。

Malachyte のプラットフォームでは、その際にユーザーベクトルと予測を同時に更新します。これにより、個々のユーザーとその好みをより深く理解できるだけでなく、匿名化されたユーザーデータを使用してモデル全体を改善することができます。推論を行うたびに、平均的な買い物客と特定の買い物客の両方のコンテキストが拡大する仕組みです。

Malachyte は、アテンションベースのニューラルネットワークを使用するだけでなく、ユーザープロファイルを 100 ミリ秒ごとに更新することで、さらなるイノベーションを実現しています。

Malachyte のレコメンデーションエージェントと検索エージェントは、ユーザーが前のページでクリックした内容に基づいて、次のページの検索結果やレコメンデーションカルーセルにデータを入力します。

正確には、このコンセプト自体は新しいものではありません。小売業者は長年にわたり、コラボレーションフィルタリングレコメンデーションシステムを使用して、類似するユーザーとアイテムを特定してきました。ただし、これには膨大な量のインタラクション履歴が必要でした。これらのモデルでは通常、サードパーティ Cookie ベースのプロファイルやユーザー属性など、大量のデータを必要とします。

しかし、セッション内のインタラクションのシーケンスに焦点を当てることで、小売業者はユーザーのプロファイルのみに焦点を当てるよりも、必要なデータや費用を抑えながら、はるかに多くのパーソナライズを実現できるようになります。また、長期的な Cookie データに依存しないことで、ユーザーのプライバシーをより尊重できる利点もあります。

これは、モデルの構造と、ブラウザデータ、クリック履歴、検索など、ユーザーに関するあらゆる情報をエンコードするマルチモーダルベクトルによって実現されます。出力もマルチモーダルです。同じモデルを、サイト内検索の商品ページ、カテゴリページ、「カートに追加」カルーセルに適用できます。

この仕組みは、カタログ内の各商品がユーザーベクトルと同じ空間に埋め込まれることで機能します。それにより、ユーザーベクトルが更新されて、関連する商品に近づき、関連しない商品からは遠ざかるようになります。エンベディングを計算するニューラルネットワークは、Malachyte と連携する小売業者全体で継続的にトレーニングされ、すべてのユーザーの品質を向上させています。このシステムは事実上、データ協同組合として機能し、各小売業者のユーザーがモデルをさらにスマート化させながら、それが全ユーザーに役立つ仕組みになっています。

商品の空間でベクトルとして表されるユーザーセッション。

この仕組みをすべてのユーザーに対して推論ごとに 100 ミリ秒で実現するために、Malachyte は Google Cloud のリアルタイム AI スタックを基盤とすることに大きなメリットを見出しました。

このシステムでは、すべての行動イベントが Managed Service for Apache Kafka クラスタにストリーミングされます。各イベントは、将来のトレーニングジョブのためにキューに入れられるのではなく、Bigtable で直ちにユーザープロファイルの更新に使用されます。Kafka クラスタにより、お客様のフロントエンドが永続化されるため、ユーザーセッションのシグナルをユーザーベクトルにどのように適合させるかをあまり心配することなく、迅速に処理できます。

Bigtable によって、Malachyte のサービスは適切なユーザーベクトルを検索して更新できるようになります。Bigtable と Kafka はステップごとに 10 ミリ秒のオーダーで動作するため、レコメンデーションループ全体が、ユーザーエクスペリエンスを中断することなく完了します。

小売業者のウェブサイト、Malachyte の AI モデルとサービングフロントエンド、コンテキスト管理インフラストラクチャから成る 3 層のリアルタイム AI アーキテクチャ。

高速コアの機能に加え、商品カタログの更新事項、在庫シグナル、小売店固有のディメンションデータから成る第 2 レイヤには、商品データを最新の状態に保つ働きがあります。このデータは Cloud Pub/Sub 経由で送信されます。Cloud Pub/Sub は、グローバルアクセスが可能な REST API を提供するため、小売業者は緻密な統合作業なしで接続を利用できます。Malachyte エージェントは Google Kubernetes Engine （GKE）で実行され、モデル推論は Google Compute Engine（GCE）で行われます。

商品カタログの更新事項などの外部データの継続的な取り込みは、Pub/Sub のグローバルメッセージングシステムを通じて行われます。

Google Cloud AI アーキテクチャに移行したことで、Malachyte は本番環境の AI 推論とトレーニングが GPU とストレージだけでは決まらないことを実証しました。高速な Key-Value ストア、ストリーミングレイヤ、マネージドメッセージングシステムを含むリアルタイムの継続的学習インフラストラクチャが必要であり、これらすべてが基盤モデルアーキテクチャと統合されていることが重要です。

このアプローチは、Malachyte のような小規模なチームでも業界に多大な影響を与えることができることを示しています。必要なのは、強力なインフラストラクチャとコア AI マネージドサービスへのアクセスです。

使ってみる

Malachyte のように業界に革新をもたらしたり、他社に先駆けて業界をリードしたりすることを目指すなら、Managed Service for Apache Kafka、Cloud Pub/Sub、Bigtable をお試しください。新規のお客様は、$300 分の Google Cloud クレジットを利用できます。

- Malachyte、CEO、Sidd Motwani 氏

Malachyte、スタッフ ML エンジニア、Vicki Boykis 氏

Gemini Enterprise、業界特化型ソリューション向けに進化

Wed, 26 Aug 2026 03:00:00 +0000

※この投稿は米国時間 2026 年 8 月 26 日に、Google Cloud blog に投稿された Gemini Enterprise for Financial Services および Gemini Enterprise for Legal の抄訳です。

Google Cloud は本日、金融サービス向け AI Gemini Enterprise for Financial Services および法務向け AI Gemini Enterprise for Legal の提供開始を発表しました。あらゆる専門家が日々の業務プロセスに合わせて Google AI を活用できるようにネイティブ設計し、安全でガバナンスの行き届いた Gemini Enterprise プラットフォーム上に構築した、業界特化型のパッケージソリューションのシリーズの第一弾です。

各業界向けソリューションは、すぐに導入可能な領域特化型の AI 機能を備えています。これには調整済みのエージェント、多様なワークフローの管理を簡素化する専用の「スキル」、データコネクタ、特定業界向けに最適化したモデルなどが含まれます。 Google Cloud のインフラストラクチャと Gemini Enterprise プラットフォーム上に構築したこれらのソリューションは、エンタープライズプラットフォームに求められるセキュリティ、ガバナンス、コンプライアンス、コストマネジメント機能を提供します。顧客データ、ビジネスルール、知的財産、カスタムエージェント、モデルの出力結果は組織固有のプライベートな状態を維持し、リスクマネジメント、監査ログ、ガバナンスをプラットフォームアーキテクチャに直接組み込んでいます。さらに、インフラストラクチャやモデルからアプリケーションレイヤーに至る Google Cloud のフルスタックアプローチにより、組織はパフォーマンスとコストを最適化し、AI 投資の価値を最大限に引き出せます。

Gemini Enterprise for Financial Services によるイノベーション、セキュリティ、コンプライアンスの融合

資産の保護にスピードが求められる現在の市場において、汎用的な AI ツールには規制対象となる金融機関が求めるセキュリティ、リアルタイムな精度、データリネージが不足しています。また、手作業によるレポート作成によって、アナリストは迅速なインサイトの抽出ではなく、定型的なデータ収集に貴重な時間を費やしています。エージェンティック AI が業界標準となりつつある中、従来のマニュアル作業に依存したままの機関は、提案、価格設定、市場変化への対応において不利な状況に直面します。

Gemini Enterprise for Financial Services は、モデルと金融サービス業界に必要なデータ、システム、専門知識、統制機能を統合するプラットフォームを提供し、これらの課題を解決します。

Google Cloud の CEO である Thomas Kurian は次のように述べています。「金融分野の専門家は、特定のモデルやエコシステムにロックインされることなく、日常的に使用する IT システムと接続し、高度なセキュリティとコンプライアンスを備えた AI プラットフォームを求めています。 Gemini Enterprise for Financial Services により、検証可能なデータの説得力を備えた金融ワークフロー向けのエージェント機能を提供し、金融機関が AI イノベーションを確実な競合優位性へと変えられるよう支援します。」

Gemini Enterprise for Financial Services の主な構成要素:

Financial Research エージェント: Google が管理するこのエージェントは、完全な説明可能性を備えたエンドツーエンドのリサーチを自動化します。50 以上の基礎的なスキルを備え、確信度スコア、明示的な手法、監査を容易にするデータスナップショット、確実な検証を可能にする正確な情報源の引用を通じて、推論プロセスの透明性を提供します。ユーザーは Gemini Enterprise app から直接エージェントにアクセスできるほか、 Agent2Agent (A2A) API を介して既存のエージェントワークフローに接続できます。エージェントは Model Context Protocol (MCP) 統合を介して多種多様なエンタープライズデータソースに直接接続し、個別のニーズに合わせたカスタマイズ可能なレポートやドキュメントを生成します。
業界特化型金融スキル: 業界特化型スキルにより、ブランドガイドラインの適用からレポートのフォーマット作成、特定データへのアクセスに至るまで、反復的な作業のショートカットを作成できます。プライベートエクイティの専門家、資産運用担当者、コンプライアンスチームのいずれが使用する場合でも、本ソリューションは信用リスク評価、ポートフォリオモニタリング、市場ニュースの要約、調査型財務リサーチなど、多様なワークフローに適応します。スキルは Financial Research エージェント内で利用できるほか、お客様が自社で構築するエージェントからもアクセス可能です。
コネクタ: 本ソリューションは、CoinDesk Data & Indices、Daloopa、Dun & Bradstreet、FactSet、Finnhub、Fiscal.ai、Guidepoint、LSEG、Moody’s、MSCI、PitchBook、S&P Global、SEC Edgar などのライセンス取得済みデータソースに対する 13 のセキュアな統合を提供し、顧客環境内で直接設定できます。
サードパーティエージェントおよびパートナーエコシステム: Gemini Enterprise for Financial Services は、法人顧客のオンボーディング加速と Know Your Customer (KYC) コンプライアンス強化を実現する D&B Business Verification エージェント、ローンパックの完全性確認、書類抽出、キャピタルマーケット向けのデータ照合を行う FlowX エージェント、プライベートマーケットや法人融資チームによる複雑な財務分析の加速を支援する Obin Financial エージェント、多段階の分析、レポート作成、リサーチワークフローに対応する S&P Global Data Retrieval エージェント、複雑なエネルギーやサステナビリティに関するデータを財務ワークフロー向けの迅速なインサイトに変換する S&P Global Energy Horizons エージェントなど、 Google Cloud のパートナーエコシステムが提供する複数のサードパーティエージェントへ簡単にアクセスできます。

Gemini Enterprise for Financial Services は、すでに CME Group や、 Financial Research エージェントの主要な設計パートナーである Deutsche Bank をはじめとするグローバル金融機関が導入しています。 BNY、Citi Wealth、Lloyds Banking Group、Macquarie Bank、Signal Iduna などの多くの大手金融機関が、生産性と効率性を向上させる先進的なエージェンティックワークフローツールとして利用を進めており、 Gemini Enterprise の導入の勢いは急速に高まっています。

法務実務向けに特化した AI である Gemini Enterprise for Legal

企業が複雑なエンドツーエンドプロセスの自動化を進める一方で、汎用ツールには厳格な機密保持、倫理的障壁（エシカルウォール）、検証済みの法的根拠、完全なデータ隔離など、法務作業が求める統制機能が欠けています。分断されたポイントソリューションや単体のモデルを組み合わせてこの問題に対処しようとすると、システム統合にかかるコストが増大し、脆弱なワークフローにつながります。

Gemini Enterprise for Legal は、これらの要件に焦点を当てて設計しており、契約レビュー、デューデリジェンス、規制モニタリング、プライバシーリクエストなどの法務ワークフロー全体を実行する特化型スキル、パートナーエージェント、コネクタを提供します。主要なドキュメントおよび案件管理システムへのセキュアなコネクタを通じて、組織のエシカルウォールを自動的に引き継ぎます。リサーチ出力はモデルの学習データだけでなく一次法源に基づき、組織のデータ、プレイブック、クライアントファイル、交渉ポジションは常にプライベートな領域内に保護します。

Gemini Enterprise for Legal の主な構成要素:

法務エージェント向け特化型スキル: Gemini Enterprise for Legal には、準備書面の作成、引用の検証、コントラクトライフサイクルマネジメント、規制動向の監視、データ主体アクセスリクエスト (DSAR) への対応など、複雑で高度な法務業務で AI エージェントを導く特化型スキルが含まれています。
コネクタ: 本ソリューションは、 Docusign、Everlaw、Harvey、iManage、Legora、NetDocuments、RelativityOne、Solve Intelligence、Thomson Reuters など、主要な法務業界プラットフォームへのセキュアな Model Context Protocol (MCP) 統合を提供します。
サードパーティエージェントおよびパートナーエコシステム: Gemini Enterprise for Legal は、本プラットフォーム上で開発を行う法務技術プロバイダーのネットワークに加え、Accenture、Deloitte、Devoteam、Eudia、Factor Law、KPMG、Tribe AI、Valtech、Zazmic、Zencore、66degrees などの大手コンサルティングパートナーやシステムインテグレータへのスムーズなアクセスを提供します。

Google Cloud の CEO である Thomas Kurian は次のように述べています。「エージェンティック AI により、法務の専門家は過去の判例のリサーチ、複雑な論理展開の構築、定型作業の自動化を実現し、クライアントに大きな価値を提供できるようになります。一方で、これらのエージェンティックワークフローのすべての側面が正確かつ事実に基づき、法的根拠に裏付けられていることが非常に重要です。 Gemini Enterprise for Legal は、現代の法務における複雑な実務に対応しながら、チームが自信を持って戦略的なアドバイスに集中できるよう、重要な根拠付けとガバナンス機能を提供します。」

提供時期

Gemini Enterprise for Financial Services および Gemini Enterprise for Legal は、本日より世界中の Google Cloud をご利用のお客様向けにプレビュー版として提供を開始します。ソリューションの詳細については、 Gemini Enterprise for Financial Services ブログおよび Gemini Enterprise for Legal ブログをご覧ください。

Google Cloud について

Google Cloud は、AI インフラストラクチャ、Gemini をはじめとする先進的なモデル、データ管理、マルチクラウドセキュリティ、開発ツール、さらにエージェントやアプリなど、強力で最適化された AI スタックを提供し、エージェント時代に向けた組織の変革を支援します。200 以上の国と地域で、信頼されるテクノロジーパートナーとして選ばれています。

Box が Gemini Embeddings 2 でマルチモーダルエンタープライズエージェントを実現

Wed, 26 Aug 2026 02:00:00 +0000

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

エンタープライズコンテンツ管理は、クラウド移行の時代以来、最も大きなアーキテクチャの転換期を迎えています。

長年にわたり、企業は財務モデル、臨床試験プロトコル、M&A デューデリジェンスルーム、エンジニアリングスキーマ、法令遵守ハンドブックなど、数兆ギガバイトに及ぶ重要なデータを Box に保存してきました。これまでは、テキストベースの検索と検索拡張生成（RAG）によって、これらのリポジトリ内の膨大なナラティブナレッジが効果的に活用され、エンタープライズ AI インテリジェンスの強力かつ非常に効果的なベースラインが確立されてきました。

従来の RAG アーキテクチャはテキスト処理に優れていますが、エージェントの時代にはそれ以上のものが求められます。次なる論理的な進化は、このフレームワークを拡張して、テキストと並存する本質的にマルチモーダルで、高度な空間情報や構造を持つ要素を捉えることです。テキストエンベディングは文章のインデックス作成に優れていますが、マルチモーダルアーキテクチャは、これまでにない画期的な機能を実現します。たとえば、財務表における厳密な行と列のセマンティクスを保持したり、臨床データのような視覚的情報を解釈したり、複数ページにわたるフローチャートのロジックを空間レイアウトを維持したままマッピングしたりすることが可能になります。

あらゆるデジタルコンテンツに対応する次世代の機能を提供するため、Google Cloud と Box は Gemini Multimodal Embeddings 2 を活用して高度なマルチモーダル機能を Box の Agentic Platform に統合し、業界をリードする Box のインテリジェントコンテンツ管理プラットフォームと Google Cloud の高度な AI エンべディングを融合させています。

エンベディングの改善によるメリット: ドキュメントコンテンツの次元の拡張

視覚的および空間的なジオメトリの保持: 複数列の表や財務マトリックスなどの複雑なドキュメント要素は、その空間的なレイアウトによって意味を成しています。これらの要素をフラットなテキスト文字列に変換すると、列ヘッダーと対応するデータポイントとの関連付けが失われてしまうおそれがあります。マルチモーダルエンベディングにより、システムは人間とまったく同じようにドキュメントを解釈できるようになり、空間的な位置関係の整合性が維持されます。
視覚的なモダリティの解明: 企業のドキュメントには、技術的な図表、プロセスフローチャート、ブランディングアセット、製品写真などの視覚的なインジケーターが多数含まれています。マルチモーダル機能により、これらの要素は検索システムにとって不可視なものではなくなり、ユーザーは画像とテキストを組み合わせた同時検索が可能になります。
ハイブリッドファイル形式の接続: 実際のビジネスワークフローが、単一のドキュメント形式で完結することはほとんどありません。エージェントは、PDF ポリシー、ログを追跡するスプレッドシート、プレゼンテーション資料を相互参照する必要がある場合があります。マルチモーダルエンベディングによって RAG を拡張することで、これら多様な形式を横断した統一的な理解が可能になります。

アーキテクチャソリューション: Gemini Multimodal Embeddings 2

Google Cloud の Gemini Multimodal Embeddings 2 は、テキスト、ラスター画像、ドキュメントページ、レンダリングされたスプレッドシートの表、ビジュアルチャートを同一のセマンティック表現空間に埋め込むことができる、統合されたマルチモーダルベクトル空間を実現します。

gemini-embeddings-2 によって実現される主なプロダクト機能:

クロスモーダル検索（テキストからビジュアル / ビジュアルからテキスト）: 自然言語クエリにより、手動のタグ付けをすることなく、膨大なスライドライブラリから特定のチャートや図解といったピンポイントなビジュアル要素を検索および抽出できるようになります。
レイアウトを考慮したドキュメントエンベディング: ファイルを任意のテキストブロックに分割するのではなく、ドキュメントページのレンダリングを直接埋め込むことで、視覚的な階層構造、コールアウトボックス、構造的なコンテキストをそのまま保持できます。
異種形式のブリッジ: モダリティ固有の構造情報を損なうことなく、.docx、.xlsx、.pdf、.pptx、.png、.csv 間のコンテンツをシームレスにつなぐネイティブサポート。

マルチモーダルエンタープライズエージェントの 3 つのコアパターン

Box 内でマルチモーダルエンベディングを活用することで、従来の RAG を拡張して複雑なビジュアルワークフローをサポートするための、主要な 3 つの独自デザインパターンを見出しました。

パターン 1: 複雑な財務レポートと分析レポート

課題

企業の財務、調査、監査の各チームは、高度に構造化されたドキュメントを分析します。こうしたドキュメントでは、埋め込みの表、成長チャート、脚注アノテーションの中に重要なデータが存在しています。テキストのみのインデックス登録では、これらの数字がコンテキストから分離されるため、自動分析が困難になります。

マルチモーダルの利点

構造の整合性: エンベディングモデルは表やグラフの物理的な構造を捉えるため、財務エージェントは、どの列ヘッダーが特定の指標の行に対応しているのかを正確に理解できるようになります。
視覚的な傾向分析: エージェントは、記述された要約と、付随する棒グラフや折れ線グラフの視覚的な傾向を相互参照し、文書内の主張とソースデータとの不一致を特定して指摘できます。
コンテキストに応じたソースの特定: ユーザーは複雑なポートフォリオに対してクエリを実行し、特定の指標を裏付ける正確なページ、表、グラフを即座に取得できます。

パターン 2: マルチモーダルによる臨床意思決定支援と診断補助

課題

医療および臨床環境では、重要な患者データが、外部の外観写真（視覚的証拠）、顕微鏡の病理スライド（検査レポート）、構造化されたリスクマトリクス（トリアージグリッド）など、さまざまな非構造化の視覚およびテキスト形式に断片化されています。従来のテキストベースのシステムや個別の分析ツールでは、こうしたクロスモーダルな関係性を同時に統合して理解することはできません。その結果、重要な診断の遅れを招いたり、生命に直結する処置上の合併症を見逃したりするリスクが生じます。

マルチモーダルの利点

クロスモーダルな臨床情報の統合: 臨床写真、組織病理画像、トリアージグリッドを同一のスペースにインデックス化することで、身体症状と細胞レベルの検査エビデンスを同時に評価します。
微細な異常の特定: 顕微鏡下で観察される微細な視覚パターン（寄生虫の嚢胞壁など）を医学的知識と結び付け、希少な疾患を迅速に特定します。
リスクを考慮した意思決定支援: 得られた所見をトリアージフレームワークと照合し、生命を脅かすアナフィラキシーショックなど、患者の差し迫ったリスクについて即座に警告を発します。

パターン 3: ドキュメント間のマルチモーダル統合とデータ調整

課題

企業内の情報は、接続されていないファイルや形式（PDF の議事録、Excel のグラフ、PNG のチラシ、メールスレッドなど）に断片化されています。従来のツールはこれらのファイルを個別に分析するため、独立したドキュメントを横断して詳細を確認したり、データの矛盾を解消したりする際に、情報を結びつけて全体像を把握することができません。

マルチモーダルの利点

ファイル間の統合: 完全に異なる形式（PDF、スプレッドシート、画像、メール）の情報を同時に結び付けて、複雑なビジネスクエリに回答します。
不整合の解決: アセット間の不整合を特定して解消します。たとえば、最新の財務スプレッドシートと照合することで、画像内に記載された古い価格情報を見つけ出すといったことが可能です。
画像とテキストの照合監査: 画像やスキャンされたファイルをテキストベースの記録と照らし合わせ（署名済みの PDF 契約書を法的レビューのメールで検証するなど）、条項の欠落や変更箇所を特定します。

エージェント型エンタープライズコンテンツ管理の未来

gemini-embeddings-2 と Box のエージェントプラットフォームのインテグレーションは、次世代のコンテンツインテリジェンスを向上させる重要な新機能です。マルチモーダルエンベディングにより、Box は従来の検索の枠を超え、能動的かつインテリジェントなコラボレーションへと進化します。Box のインテリジェントコンテンツ管理プラットフォームは、エンタープライズ AI インフラストラクチャの根本的な転換を体現するものです。単なる受動的なドキュメントストレージから、ガバナンスの効いたセマンティックインデックスによる推論レイヤに移行することで、AI エージェントは、既存のコンプライアンスとセキュリティ管理を維持したまま、コンテンツの照会や相互参照、アクションの実行を自在に行えるようになります。

マルチモーダルエンベディングと、検索、メタデータ抽出、調査、分析、作成にわたるネイティブ AI エージェントスイートを搭載した Box により、組織は、古い価格データの特定、契約条項の期限切れ、ドキュメント間の矛盾といったインサイトを、ビジネスリスクが顕在化する前にプロアクティブに抽出できるようになります。金融サービス、ライフサイエンス、法務業務といった複雑性の高い業界では、マルチモーダル理解が競争上の必須要件となっています。Box なら、テキスト、表、グラフ、画像を横断して推論することが可能です。

より広範なエンタープライズ AI エコシステムとの相互運用を前提に設計された Box は、ガバナンスの効いた一元的なコンテンツ基盤として機能します。これにより、AI を活用したあらゆるワークフローが、承認済みで監査可能な企業データに基づいていることが保証されます。

考えてみれば、企業のデータ環境はもともとマルチモーダルなものでした。そして今、それを最大限に活用するためのテクノロジーが現実のものとなりました。gemini-embeddings-2 とのインテグレーションにより、Box は、ユーザーが非構造化エンタープライズコンテンツからこれまでにない価値を引き出せるよう支援します。マルチモーダルファーストのアーキテクチャ、厳格な精度ベンチマーク、そして監査対応のグラウンディングを積極的に取り入れるプロダクトリーダーが、企業の生産性とイノベーションにおける次なる波を牽引することになるでしょう。

このプロジェクトに携わってくださった Ken Ikeda、Afshaan Mazagonwalla、Samip Thakkar の各氏に感謝いたします。

- Google、エージェントプロダクトコンサルティングリード、Sandhya Patil

- Box、スタッフ AI プロダクトマネージャー、Darryl Sladden 氏

【Google Cloud Next Tokyo 26】DAY 2 基調講演まとめ：インフラからセキュリティまで、フルスタックで支える AI エージェント

Tue, 25 Aug 2026 02:00:00 +0000

Google Cloud Next Tokyo 26 の Day 2 基調講演では、AI エージェントの実用化をフルスタックで支える最新テクノロジーが勢ぞろいしました。インフラの進化から、エージェント開発、データ基盤、そしてセキュリティまで。GovTech東京や NTTドコモなど先進企業の実践も交えて、最前線で今何が起きているのか、注目のトピックを分かりやすくお届けします！

見逃した方はぜひこちらからご覧ください。

AI を支えるインフラ

幕開けは Google Cloud の渕野の挨拶から。AI コンピューティングへの需要が急速に高まるなか、ハードウェアからモデル、プラットフォームまで全レイヤーを自ら手がけてきたことが強みだと語りました。その象徴が、クリーンエネルギーや専用インフラを 1 つのエンジンにまとめた AI Hypercomputer です。学習と推論それぞれの要求に合わせた第 8 世代 TPU を用意し、新しいネットワーク Virgo Network は 134,000 個のチップを束ねて 170 万エクサ FLOPS を生み出します。運用の面では、Google Kubernetes Engine（GKE）が 256,000 ノードを 1 つのクラスタにまとめ、大規模な学習も支えます。すでに Woven by Toyota が時空間理解の視覚言語モデルの学習を高速化するなど、多くの企業がこの基盤で成果を上げています。

エージェントを本番で動かすプラットフォーム

続いて登壇したのは Google Cloud の Brad Calder。エージェントを本番で動かすための Gemini Enterprise Agent Platform を紹介しました。作る出発点はオープンソースの Agent Development Kit (ADK) で、Google Cloud の全サービスが標準で MCP に対応し、エージェント同士は Agent2Agent プロトコル (A2A) で協調します。動かす Agent Runtime、守る Agent Identity や Agent Gateway、Model Armor まで、本番運用に必要な部品が一式そろいました。

デモでは、Google Cloud の塚越が、Antigravity CLI で作った購買エージェントを動かして見せました。「ノート PC が 3 台ほしい」と頼むと、A2UI が申請ボタンやフォームをその場で組み立て、在庫を確かめて発注を 2 台へ調整します。不正な指示や未登録の MCP への通信は、ポリシーがブロック。開発者が向き合うのは業務ロジックだけです。

データにコンテキストを与える Agentic Data Cloud

続いて、データの活かし方を語ったのは Google Cloud の Sirish Chandrasekaran です。これまでのデータ基盤は、人が問いかけて初めて答える受け身のものでした。Sirish はこうした仕組みを System of Intelligence と呼びます。これからは、AI が自分で判断して動く System of Action が要ります。そのためには、文書や画像のまま眠っている 9 割の非構造化データにも意味を持たせ、いつでも引き出せるようにしておかなければなりません。これを実現するのが Agentic Data Cloud です。データを動かさずに扱う Borderless Lakehouse、AIエージェントや分析基盤に信頼できるコンテキスト（文脈）を提供する「Knowledge Catalog」、自然言語で分析・実行できる Intent-Driven Outcomes という 3 つの柱で支えます。国内でも、メルカリが「Socrates」を BigQuery や Looker の Semantic Layerを使って、NTT データが決済サービス「ADAPTIS」を AlloyDB 上で動かしています。

デモでは、Google Cloud の山田が、架空の食品会社のマーケターとして腕を振るいます。話題の「お濃茶ジェラート」を海外に広げるべきか。その判断までふだんは 5 週間かかるところを、5 分に縮めました。PDF に埋もれた原材料の情報を Gemini が読み解き、AWS にある購買データを動かさず BigQuery につなぎ、組み上げたデータエージェントが売上や ROI を予測して、報告スライドまで用意しました。

1,000万人の都民が使う共通の入り口を目指して

ここで紹介されたのが、GovTech東京の井原氏です。きっかけは 2024 年 1 月 1 日、能登半島での地震でした。災害のさなかに行政サービスにアクセスできない不安を自ら経験し、行政のデジタル化に飛び込んだといいます。GovTech東京は東京都と 62 の市区町村と連携し、デジタルサービスを内製する組織です。現在、600 万ダウンロードを超えた東京都公式アプリを、1,000 万人の都民が使う共通の入り口とすることを目指しています。災害時等の集中アクセスでも安定して動き、情報が矛盾なく整合すること。この要件を満たす基盤に Google Cloud を選び、大規模な書き込みと強い整合性を両立できる Spanner を採用しました。

NTTドコモが目指すフル AI マーケティング

NTTドコモの鈴木氏が語ったのは、フル AI マーケティングの構想です。1 億を超える dポイントのユーザーと 2,000 種類以上の顧客データを前に、一人ひとりに最適な体験を届けるには膨大な検討が欠かせません。着目したのは、社内の資産。5,000 人以上の社員が使うデータ活用アプリのソースコードや利用ログに眠る現場の知識を、AI が読み取れるナレッジに変えました。基盤の Google Cloud なら、月 160 億通の顧客アプローチも、お客様の声や営業社員の日報も、BigQuery でまとめて扱えます。施策設計エージェントは、100 パターンを超えるセグメントへ自動で分け、立案から生成、審査までを自律的に進めます。目指すのは、2027 年のマーケティングフル AI 化です。

AI の脅威に AI で立ち向かうセキュリティ

渕野が最後に取り上げたのは、エージェント時代に欠かせないセキュリティでした。攻撃側も AI を使いこなす今、Google は共同プロジェクト Big Sleep で未知のゼロデイ脆弱性を AI 単独で見つけ、脆弱性を自動で直す CodeMender も投入しました。CodeMender では、Gemini 3.5 Flash をセキュリティ用途に特化させたカスタムモデル Gemini 3.5 Flash Cyber も選べます。渕野が掲げたのは、可視化から優先順位付け、修復、監視までを AI で連携させる AI Threat Defense です。

デモでは、Wiz Cloud Japan の大井が、公開状態の Python 製チャットボットに潜む認証回避の脆弱性をレッドエージェントで突き止め、グリーンエージェントが対策を提案するところを見せました。

修復役の CodeMender は、Google Cloud の高橋が cm find・cm verify・cm fix で、脆弱性の発見からパッチ作成までを実演しました。防御を人間のスピードからマシンのスピードへ。渕野はそう締めくくりました。

まとめ

2 日間の基調講演で見えてきたのは、AI エージェントを業務に取り入れる技術が、事例とともに整いつつある姿です。ハードウェアからアプリケーションまで、Google Cloud が一貫してそろえます。最後に、渕野が紹介したのは、手を動かして試せるハンズオンイベント「Build with Gemini Tokyo」や、「第 6 回 AI エージェント事例アワード」。次にこの基盤を活かすのは、みなさんです。来年の Next Tokyo は 8 月 5 日と 6 日。また会場でお会いしましょう。

Google Cloud Next Tokyo 公式サイトにて基調講演を含むセッションをアーカイブ公開中です。現地 / ライブ配信での視聴が出来なかったという方も、ぜひアーカイブ配信にてセッションの復習や新たな学びのきっかけに、ぜひご活用ください。

メジャーがサポートされるようになった BigQuery Graph を使用して、信頼できるエージェントワークロードを実現

Tue, 25 Aug 2026 02:00:00 +0000

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

企業が単純なチャットアシスタントの使用から自律型のエージェントワークロードに移行すると、すぐに厳しい現実に直面します。それは、エージェントが元テーブルを直接使用する際に、不正確な分析情報を生成する傾向があるということです。

BigQuery Graph は、組織がフラットで静的なテーブルから脱却し、現実世界に存在する企業を正確に表現できるように、つまり、現実世界の依存関係を持つ、相互に接続された事業体として表現できるようにします。BigQuery Graph（プレビュー版）でメジャーがサポートされるようになったことで、管理された指標と関係マッピングが統合されます。これにより、エージェントはグラフで収集された複雑な依存関係全体について、メジャーの精度に基づいて推論できます。

関係が重要な理由

従来のデータ構造では、マルチホップのビジネスコンテキストが考慮されないため、次のように、AI エージェントが運用上誤った意思決定を行うことがあります。

具体的な問題: 小売業者のエージェントが、シアトルでの冬用ジャケットの売り上げが 12% 減少した理由を尋ねられた場合、フラットテーブルをクエリして、「事実」（12% の減少）を報告することはできますが、「シアトルの注文 ➔ 配送センター ➔ 地域の嵐によるサプライヤーの遅延」という関係パスを追跡できないため、「理由」を特定することはできません。
分断されたシステムのリスク: 関係のコンテキストがないため、エージェントが関連性のない 15% オフのキャンペーンを提案し、不必要に利益率を低下させます。さらに、あるチームがサプライヤーの関係を別のグラフデータベースにマッピングし、別のチームが SQL 指標を維持するというように、別々のシステムを維持すると、エージェントは実行時にこれらのスタックを結合せざるを得なくなります。このプロセスは時間がかかり、費用もかさみ、KPI の計算に一貫性がなくなります。

BigQuery Graph のメジャーは、既存のテーブルをプロパティグラフにインプレースでマッピングし、ETL を不要にすることで、この問題を解決します。この統合された設定により、次のような問い合わせの論理的な進化が可能になります。

メタデータのグラウンディングは、存在するデータを確立します。
ビジネス指標（メジャー）は、ビジネスのパフォーマンスを計算します。
関係マッピング（グラフ）は、それが起こった理由を明らかにします。

仕組み

従来、グラフ走査中の標準 SQL の結合では行が重複し、集計計算が不正確になっていました。BigQuery Graph は、これをネイティブに解決します。

データモデラーは、プロパティグラフ DDL 内で直接 MEASURE（SUM や AVG など）を定義します。エンジンは GRAPH_EXPAND 関数と AGG アグリゲータを介して標準 SQL を使用して、指標を評価する前に構造グラフのパスを解決します。これにより、エージェントは計算機（SQL）が必要なときと地図（グラフ）が必要なときを認識できるほどスマートになります。

bigquery-public-data のような一般公開プロジェクトは厳密に読み取り専用であるため、読み取り専用の一般公開テーブルをノードおよびエッジとして直接参照しながら、プレースホルダ変数（YOUR_PROJECT_ID）を使用して独自のプロジェクト内で論理プロパティグラフをマッピングする必要があります。

code_block: <ListValue: [StructValue([('code', '-- 1. Map the graph inside YOUR project \r\n\r\n\r\nCREATE OR REPLACE PROPERTY GRAPH `YOUR_PROJECT_ID.YOUR_DATASET.thelook_ecommerce_graph`\r\nNODE TABLES(\r\n `bigquery-public-data.thelook_ecommerce.users` AS User\r\n KEY(id)\r\n LABEL User PROPERTIES(id, city, country),\r\n `bigquery-public-data.thelook_ecommerce.orders` AS Order\r\n KEY(order_id)\r\n LABEL Order PROPERTIES(\r\n order_id, \r\n MEASURE(AVG(num_of_item)) AS avg_items_per_order,\r\n MEASURE(SUM(num_of_item)) AS total_items\r\n )\r\n)\r\nEDGE TABLES(\r\n `bigquery-public-data.thelook_ecommerce.orders` AS OrderedBy\r\n SOURCE KEY(order_id) REFERENCES Order(order_id)\r\n DESTINATION KEY(user_id) REFERENCES User(id)\r\n LABEL ORDERED_BY\r\n);\r\n\r\n-- 2. Query your new graph with standard SQL—using standard {Label}_{Property} column outputs\r\nSELECT\r\n User_city AS city,\r\n ROUND(AGG(Order_avg_items_per_order), 2) AS agg_avg_items,\r\n ROUND(AGG(Order_total_items), 2) AS agg_total_items\r\nFROM GRAPH_EXPAND("YOUR_PROJECT_ID.YOUR_DATASET.thelook_ecommerce_graph")\r\nGROUP BY User_city\r\nORDER BY agg_total_items DESC\r\nLIMIT 10;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f6e599bf9d0>)])]>

BigQuery Studio でグラフインテリジェンスを民主化

デベロッパーとビジネスユーザーの双方が、これらの関係ネットワークをスムーズに管理、デプロイできるように、直感的なネイティブ運用ツールを BigQuery Studio に直接組み込みました。

視覚的なグラフモデラー: BigQuery Studio 内のノーコードのドラッグ＆ドロップインターフェースで、複雑な DDL スクリプトを手動で記述することなく、プロパティグラフ、ノード、エッジを視覚的に構築、編集、マッピングできます。

会話型分析（CA）のインテグレーション: ユーザーはグラフと自然にやり取りできます。会話型分析エージェントは、テーブル結合を推測するのではなく、グラフの決定論的な関係認識マップをナビゲートし、自然言語の質問を、境界が制約された正確な GoogleSQL クエリまたは ISO GQL クエリに変換します。これにより、モデルのハルシネーションを防ぎ、セマンティックな一貫性を確保します。

統合されたセマンティクス: Looker とのネイティブなインテグレーション

断片化されたロジックスタックの維持を避けるために、ビジネス指標はデータレイヤに存在する必要があります。Looker（LookML）を、データベース内分析モデルとしての BigQuery Graphs とネイティブに統合することで、コアでロジックを一度定義するだけで済みます。

データベース管理モデル（sql_analytic_model_name）: sql_analytic_model_name を使用して、Looker にデータベース定義の BigQuery Graph を直接参照させ、標準の LookML のディメンションとメジャーをグラフプロパティに直接マッピングします。
Looker 管理モデル（derived_analytic_model）: derived_analytic_model を使用して、LookML ビュー内で BigQuery Graph スキーマを直接定義します。Looker は、SQL DDL ステートメントを動的に生成して実行し、BigQuery 内のグラフを維持します。
エンタープライズ DevOps ワークフロー: Looker IDE、Git ベースのバージョン管理、継続的インテグレーション（CI）を使用して、グラフのライフサイクル全体を管理します。主要な KPI（離脱率など）は、検証済みで、信頼できる、まったく同じものが維持されます。

- Google Cloud、グループプロダクトマネージャー、Deepak Dayama

- ソフトウェア開発マネージャー、Yun Zhang

【Google Cloud Next Tokyo 26】 DAY 1 基調講演まとめ：日本企業の現場で動き始めた AI エージェント

Tue, 25 Aug 2026 01:00:00 +0000

Google Cloud Next Tokyo 26 の Day 1 基調講演では、自ら考えて業務を進める AI エージェントが、日本企業の現場を動かし始めた姿がくっきりと見えてきました。変革の全体像から、Gemini Enterprise の進化、NTTデータやＳＯＭＰＯホールディングス、Ｓｋｙ、スクウェア・エニックスの実践、そして Google Workspace とセキュリティまで。最前線で今何が起きているのか、注目のトピックを分かりやすくお届けします！

見逃した方はぜひこちらからご覧ください。

「電気で 30 年」を、AI なら何年で？

最初に立った Google Cloud の三上は、今の AI による変化を工場の電化になぞらえました。工場に電気が通っても、生産性が上がるまでには約 30 年。中央の蒸気機関を大きなモーターに替えただけでは変わらず、機械の一台ごとに小さなモーターを載せ、作業の流れごと作り直したときに一気に伸びました。AI エージェントも、業務の一つひとつに組み込んでこそ力を発揮します。しかも今回は、3 年、3 か月で景色が変わります。

世界では Google Cloud のお客様の約 75% が AI を活用し、多くが本番運用へ進んでいます。一方、日本市場の独自調査では、対象の 70% が AI エージェントをまだ使えておらず、利用者の約半数は会社非公認の「シャドー AI」に頼っています。ここに、日本企業の伸びしろがあります。

Google 自身は、検索や YouTube など月間のべ 150 億人以上のサービスに AI を組み込んでいます。その規模を支える力をお客様に届けるのが Google Cloud で、AI ハイパーコンピュータからモデル、データ基盤、Agent Platform まで、変革に必要なフルスタックを自社で持ちます。AI 専用チップの TPU は第 8 世代となり、学習用と推論用に最適化した 2 種類をそろえました。このフルスタックの上で、働く人が実際に触れるのが Gemini Enterprise です。日立製作所やファナックでもすでに導入が進んでいるといいます。

NTTデータ：自らが Client Zero となって

NTTデータの西村氏は、機微データを守りガバナンスを効かせつつ AI を速く届ける難しさを挙げ、その答えが、自社を実践の場にする Client Zero だと説明しました。同社は 2026 年 6 月に Google Cloud と包括契約を結び、Google Workspace と Gemini Enterprise を大規模に活用する基盤を整備。業務にAIエージェントを組み込んで働き方を見直し、得た知見をお客様への提案につなげるといいます。

NTTデータの西村氏は、機密データを守りガバナンスを効かせつつ AI を速く届ける難しさを挙げ、その答えが、自社を実践の場にする Client Zero だと説明しました。同社は 2026 年 6 月に Google Cloud と包括契約を結び、Google Workspace と Gemini Enterprise を大規模に導入。業務にエージェントを組み込んで働き方を見直し、得た知見をお客様への提案につなげるといいます。

Gemini Enterprise の進化と、小売の現場デモ

Google Cloud の Lilly McNealus は、Gemini Enterprise を、企業で働く人が AI を利用する入口だと位置づけました。複雑なツールやトークン課金の悩みに対し、シンプルさ、安全性、コスト効率の 3 つの価値を届けると話します。コードなしで使える 24 時間 365 日のスーパーエージェント、一つの管理画面でのガバナンス、目的に合わせてモデルを選べるコスト最適化がそろい、単一のアーキテクチャで統合されています。

続いて、Google Cloud の岡本によるデモです。店舗を担当する社員が店舗巡回アシスタントエージェントに相談すると、ミネラルウォーターの陳列スペースが足りない点や、古い POP を指摘します。音声メモと写真を渡せば、報告書 PDF が作られ Teams や Outlook へ連携されます。本部の担当者が Gemini Enterprise の Spark に POS や気象データを渡すと、翌朝には熱中症対策商品を目立つ位置に置く棚割り案が届きました。デモのあと Lilly は、目的を伝えれば動く Gemini Spark や、ノーコードで作れる Agent Designer など、Gemini Enterprise の新機能も紹介しました。

開発者に向けたアップデート

さらに Lilly からは、Gemini Enterprise から直接アクセスできる Antigravity、日本リージョン対応の Gemini Enterprise app、国内で処理を完結できる Gemini 3.5 Flash の一般提供、Anthropic や Mistral なども選べる Model Garden、コード最適化の AlphaEvolve などが紹介されました。

SOMPOホールディングス：グループ 3 万 4,000 人が使う「SOMPO AI エージェント」

ＳＯＭＰＯホールディングスの中島氏は、SOMPOグループの AI 戦略を紹介しました。同グループは今年 1 月、全社員が使う汎用型 AI を従来のチャット型 AI から Gemini Enterprise へ切り替え、3 万 4,000 人へ「SOMPO AI エージェント」として提供しています。決め手は、約款やマニュアルなどの社内ナレッジと相性の良い Gemini Notebook。

ユースケースを拡大するために、会議の録音を自動共有する「SOMPO 音声メモアプリ」を個別開発したほか、レッカー費用を一次チェックする「レカみる」など市民開発では、数か月で 1 万件超のエージェントが生まれ、週 1 回以上使う社員は 80% 超、部長以上では 98% に達しました。

Ｓｋｙ：5 か月で 2 万個のエージェントを自作

Ｓｋｙ株式会社の太田氏は、処理精度と検索、ガバナンスの強さから Gemini Enterprise を全社導入しました。社員が業務に合う独自エージェントを自作し、単一の用途に分類するのが難しい、複合的なプロンプトが約 48% を占めます。AI への総リクエストは 1 日 1 万 5,000 回から 3 万回へ倍増し、エージェント数は 5 か月で 20,000 個に。作る過程で個人の暗黙知が集まり、可視化されるのも効果的です。

スクウェア・エニックス：見て、考えて、動く AI

スクウェア・エニックスの荒牧氏は、音や画面を理解するマルチモーダル AI の活用を目指し、Gemini Enterprise Agent Platform を採用しました。今年 8 月に 14 周年を迎えた『ドラゴンクエストX オンライン』において、期間限定のクローズドベータテストとして開発・提供していた対話型AIバディ「おしゃべりスラミィ」の取り組みが紹介されました。「おしゃべりスラミィ」は、プレイヤーと音声で会話し、プレイ状況に応じて自ら話しかける機能を備えています。

さらに会場では、ゲーム QA 作業の自動化デモ動画として、「船を見たい」という指示に応じて Gemini が地図を開き、コントローラーを操作して QA を進める様子も紹介されました。

Google Workspace で変わる、ある一日

Google Workspace の Yulie Kwon Kim は、相手の必要を先に汲む「おもてなし」を AI に込めたいと話しました。朝は Google Chat の「デイリーブリーフ」が要点を届け、Sheets Canvas がデータからダッシュボードを作り、Google Meet の Gemini 3.5 Live Translate が 70 以上の言語をつなぎます。さらに、Microsoft 365 からの移行も、従来と比べて最大 5 倍速くなったと紹介されました。

Google Cloud の服部によるデモでは、Google Workspace に標準搭載される Google Pics で写真のスパークリングワインをビールジョッキに差し替え、必要な情報をサイドパネルから呼び込み、AI でスライドの体裁を整えるなど、顧客への案内スライドを数分で仕上げました。

AI の脅威に AI で備える、そして次の一歩

三上が最後に強調したのは、エージェント時代に欠かせないサイバーセキュリティでした。攻撃者も AI を使う今、脆弱性の悪用までの時間は、この数年で 1.3 年から 1.6 日へと縮まりました。こうした脅威には AI で自律的に立ち向かう必要があります。

Google 自身も月に数万件の脅威レポートを処理し、エージェントで対応時間を 90% 以上短くしました。5 月発表の Google AI Threat Defense を、準備・スキャン・修復・監視の 4 ステップで、NTTデータや NEC、日立製作所、富士通などと日本でも展開します。

電気で 30 年かかった変化を、AI ではどこまで短くできるか。この問いかけとともに、DAY 1 基調講演は幕を閉じました。

SOAP Architecture: S3 に眠るデータを、Google Cloud で AI エージェントの基盤に変える

Mon, 24 Aug 2026 02:00:00 +0000

利用している主なサービス・ソリューション

Products Used: BigQuery, Looker / LookML, Knowledge Catalog, BigQuery Graph, Cross-Cloud Interconnect, Gemini Enterprise
Solutions Used: Borderless Lakehouse, Data Analytics & AI Platform

生成 AI の活用が経営課題となる一方で、その原動力であるデータの多くは、長年運用されてきた Amazon S3 に眠ったままです。「まずデータ基盤を全面刷新してから」と考えた瞬間に、移行の規模とリスクの前で計画は止まり、AI 活用は PoC の先へ進めなくなります。膨れ上がる移行コスト、断片化したナレッジ、そしてビジネスの文脈を持たないままもっともらしい回答を返す AI——従来のアプローチでは、この距離を容易に埋めることはできません。

本稿では、この課題に対する一つの答えとして、SOAP Architecture (Semantic and Ontology Agent Platform) をご紹介します。データを動かさずにつなぎ、意味と知識の層で AI をグラウンディング（接地）し、エージェントに働かせる。Google Cloud のデータ分析ポートフォリオを一枚の設計図にまとめた、リファレンスアーキテクチャです。

SOAP の考え方はシンプルです。

つなぐ - データは AWS 等に置いたまま、BigQuery から直接分析します。
意味を与える - LookML、BigQuery Graph、Knowledge Catalog、Open Knowledge Format がデータに文脈を与えます。
働かせる - Conversational Analytics と Gemini Enterprise が、その意味を理解して動きます。

大規模なデータ移行プロジェクトは、前提ではありません。

データは動かさない: Borderless Lakehouse で「いま在る場所」につなぐ

SOAP の土台は Borderless Lakehouse です。 S3 上の Apache Iceberg テーブルは、Cross-Cloud Interconnect とキャッシュ(プレビュー版)を通じて BigQuery から直接クエリでき（Cross-Cloud Interconnect を導入していない環境でも、インターネット経由での接続が可能です）、AWS Glue Data Catalog / Databricks Unity Catalog / Snowflake Horizon のメタデータは、カタログフェデレーション(プレビュー版)で Lakehouse のランタイムカタログと自動的に同期されます。 ETL パイプラインを組む前に、まず「つながる」のです。 ( Iceberg 形式のファイルでない場合は Cross-Cloud Connections で直接参照可能です)

このアプローチは、次のメリットをもたらします。

ゼロコピーのクロスクラウド分析: ファイルを複製することなく、S3 のデータをその場で分析できます。分析のために「まずコピー」する運用から解放されます。
「クラウド間の税金」の解消: 外向きデータ転送料はかかりません。(相互接続サービスの時間単位の料金はかかります) 従量の egress 課金に怯えることなく、クロスクラウド分析を定額で計画できます。 (Partner Cross-Cloud Interconnectを使用した場合)
初日からの価値: 接続したその日から、使い慣れた SQL でレガシーデータに問い合わせできます。移行の完了を待つ必要はありません。

AI の信頼性は、モデルではなく「意味の層」で決まる

SOAP の名前の中核である Semantic and Ontology は、このアーキテクチャの最も重要な主張を表しています。エージェントの回答品質を決めるのは、モデルの選定ではなく、データに与えられた意味と関係の質だということです。

ここで言うオントロジーとは、業務上の実体 (顧客・注文・商品…) と、その関係と意味を、AI が直接読める形で表現した知識の構造のことです。メタデータが「何があるか」の目録なら、オントロジーは「何を意味し、どう繋がるか」の地図です。

セマンティックレイヤを担うのは LookML です。指標やディメンションの定義を一元管理し、ダッシュボードと AI が同じ「言葉の定義」を共有します。オントロジーを担うのは BigQuery Graph、Knowledge Catalog、そして Open Knowledge Format (OKF) です。テーブル間の関係をグラフとして明示すれば、エージェントが結合方法を推測する余地がなくなり、ハルシネーションの入り口を塞げます。

この層は、次の 3 つの要素で構成されます。

セマンティックレイヤ(LookML): 「売上」「アクティブ顧客」の定義を一箇所に。 BI と AI の回答が食い違う問題を根本から解決します。
ナレッジグラフ(BigQuery Graph): 顧客、注文、商品といった実体の関係をプロパティグラフとして定義し、ISO 標準の GQL で問い合わせます。グラフはそのままエージェントのデータソースになります。
オントロジーの「共通語」(OKF + Knowledge Catalog): Knowledge Catalog が社内 Wiki のようなページも参照しながら、テーブルの意味、指標の背景、運用のナレッジを OKF (Markdown のバンドル) として生成します。生成した OKF は Git で管理し、エージェントへは Knowledge Catalog が供給します。散在していた組織のナレッジが、AI の資産に変わります。

3 つの入口、1 つの基盤: エージェントが「使う」

意味の層が整うと、その上で複数の利用スタイルが同じガバナンスのもとに成立します。 SOAP では、利用者を 3 つのペルソナで捉えます。

定型分析とドリルダウン: Looker のダッシュボードが LookML に接地した指標を提供します。Looker の Conversational Analytics は最大 5 つの Explore を束ね、質問ごとに適切な Explore へルーティングします。
Agentic なアドホック分析: BigQuery の Conversational Analytics が、BigQuery Graph をデータソースとして自然言語の質問に答えます。エージェントは A2A(Agent2Agent)プロトコルで Gemini Enterprise に公開され、ビジネスユーザーは Slack や社内ポータルから話しかけるだけです。
エンジニアリング分析: VS Code や Claude Code などのコーディングエージェントが、Data Agent Kit を通じて同じ基盤に接続します。 OKF は Git ネイティブなので、エンジニアはナレッジそのものをコードと同じレビュープロセスで育てられます。

入口は 3 つですが、接地はひとつです。どの入口から入っても、同じ定義、同じ権限、同じナレッジで答えが返ります。権限はエージェントのために新設するものではなく、BigQuery と Looker の既存のアクセス制御がそのまま適用されます。

モダナイズもエージェントと進める: 「移行計画書」から始まる

データ基盤のモダナイゼーションが止まる本当の理由は、技術ではなくアセスメントです。ストレージ内に何があるか誰も説明できず、棚卸しに数か月を要し、その間に意思決定が止まる——多くの企業で繰り返されてきた光景です。

SOAP では、この最初の壁もエージェントに任せます。既存のメタデータやクエリ履歴などを読み取り専用で収集すれば、コーディングエージェントがテーブル単位の処遇(移行 / アーカイブ / 残置 / 廃棄候補)を判定根拠つきで分類し、フェーズ単位の移行計画書をドラフトします。判断できない項目は「確認事項」として人間に返してくるため、レビューと承認に集中できます。

生成される計画書には、機械可読な移行マニフェストが付属します。つまり、資料のための計画ではなく、そのまま次のフェーズで DDL 等に変換できる、実行可能な計画です。データの棚卸しからドキュメント整備、移行計画の立案まで——これまで数か月を要した工程が、エージェントとの協働では最初のワークショップのアジェンダになります。

SOAP の経済性

このアーキテクチャの経済性は、「運ばない・書き換えない・全部やらない」の 3 点に集約されます。 S3 のデータはゼロコピーで分析し、既存の Parquet 資産はメタデータだけで Iceberg 化し、移行対象はアクセス実態にもとづいて絞り込みます。実際の棚卸しでは、テーブルの相当数が 12 か月以上参照されていない「廃棄候補」であることも珍しくありません。移行の恐怖の大半は「全部運ぶ」という誤解から来ています。

次のステップ

AI の賢さは、モデルの選定ではなく、データに与える意味で決まります。そしてその意味の層は、データを動かす前から作り始めることができます。

最初の一歩は、大きな移行の決断ではありません。読み取り専用の棚卸しと、最初の OKF バンドルから始めてください。

Borderless Lakehouse の全体像は、概要ドキュメントをご確認ください。
Open Knowledge Format は、紹介ブログと仕様をご覧ください。
グラフを AI との対話に使う方法は、グラフとチャットすることで今日から試せます。

SOAP という名前は Semantic and Ontology Agent Platform の頭字語ですが、そこにはもうひとつの意図も込められています。長年の運用で埃をかぶったデータも、意味の層で洗い上げれば AI の一級の資産になる、ということです。

レガシーも、洗えば資産です。

関連リンク・次のステップ

著者・コントリビューター紹介

執筆者:
- Kuma Arakawa: Senior Customer Engineer
  Yu Yamada:Data Analytics Specialist Tech Lead
  Akira Igarashi: Data Analytics Specialist Sales Manager
  Mei Sakurai: Head of Data Analytics Specialist Customer Engineering, Japan
お問い合わせ: Google Cloud のデータ分析・AI エージェント基盤導入に関するご相談は、担当営業またはカスタマーエンジニアまでお気軽にお問い合わせください。

AI & 機械学習

Airtel、2026 年インディアン プレミアリーグのクリケット中継を完璧に配信

同時接続数とエッジ効率を考慮した設計

運用準備のためのプロアクティブな戦略

優れたライブ配信のためのブループリント

Google、2026 年 Gartner® Magic Quadrant™ エンタープライズ AI アシスタント部門のリーダーに選出

Google がリーダーに選出された理由

Gemini Enterprise の最新の機能強化でビジョンを推進

Gemini Enterprise のお客様も価値を実感

Spanner への移行: Antigravity CLI で二重書き込みを自動化してサービス停止を最小限に

課題: 二重書き込みによる移行の仕組み

解決策: 標準化されたミューテーション コンバータ パターン

Antigravity CLI をヘッドレス モードで使用する理由

クラウド エンジニアにとっての成果と重要なポイント

次回のデータベース移行に役立つ 3 つのヒント

使ってみる

近畿大学と Google Cloud が包括連携協定を締結 - 約 2 万人超へ「Google AI Pro for Education」を導入し、「AI ネイティブ大学」の実現を支援

バグの発見と修正を支援するオープンソースの AI ハーネス、Mantis のスタートガイド

AI プロトタイプを本番環境に移行する前にすべてのスタートアップが答えておくべき 10 の質問

オンボーディング: 基礎を固める（ごく初期の段階）。

#1 Google AI Studio と Gemini Enterprise Agent Platform のどちらから始めればよいですか？

#2 IAM のエキスパートがいない場合に Google Cloud プロジェクトを設定するにはどうすればよいですか？

#3 Google Cloud を使用しています。コードの認証には、API キー、サービス アカウント、ユーザー認証情報のどれを使用すればよいですか？

#4 AI Studio の API キーから Agent Platform の IAM モデルへの移行は、いつまで引き延ばせますか？

スケール: 追加料金を支払うことなく容量を増やす。

#5 リリースしたのに、HTTP 429 エラーが頻発しています。これを解消するにはどうすればよいですか？

#6 Standard PayGo、Priority PayGo、プロビジョンド スループットのうち、どの消費モデルを利用すればよいですか。

#7 どのリクエストをライブにして、どのリクエストをバッチジョブにする必要がありますか？

管理: 費用、鍵、エージェントを管理する。

#8 請求額が 3 倍になっても丁寧なメールが届くだけでなく、実際に費用を削減できる利用額上限を設定するにはどうすればよいですか？

#9 シークレットはどこに保存すべきですか？（.env ファイルではありません）

#10 新しい AI エージェントが、決してすべきではないことをしないようにするにはどうすればよいでしょうか？

いわば宿題として

エージェントがより適切に委任を行う方法

原則 1: 委任された作業を検証する

原則 2: 費用を賢く管理する

原則 3: 機密データを尊重する

原則 4: 無関心圏に注意する

今後の展望

業務の再定義: Pythian の社内 AI ハンドブックがもたらす顧客の ROI

Pythian AI オペレーティング モデルの 4 つの柱

実際の導入効果: データベース運用からグローバル サプライ チェーンまで

AI オペレーティング モデルを構築する準備はできましたか？

Google Antigravity の提供対象を企業のお客様まで拡大

AI デベロッパー ツールとエンタープライズ グレードの管理機能を 1 つのサブスクリプションに統合

支出を管理しながら、デベロッパーの障害を取り除く

組み込みのプライバシーとセキュリティの機能で組織のコードとデータを保護

チームが好む開発環境にエージェント コーディングを直接導入

お客様の声

Gemini Enterprise で Antigravity を使ってみる

Mirendil の事例: トレーニング前後のアプリケーションに AI Hypercomputer のTPU と GPU を活用

金融サービスにおけるエージェント型 AI を活用したオペレーショナル レジリエンスの構築

机上演習からレジリエンス インテリジェンスへ

制御と柔軟性を実現するデュアル オーケストレーション

Google Cloud で生成とガバナンスを強化

スケーラブルでエビデンス対応のレジリエンス テスト

レジリエンス インテリジェンスに向けて

Google Dataflow で費用対効果に優れた高スループットな生成 AI ワークフローを構築する

大規模ストリーム向けのユニバーサルなブループリント

アーキテクチャ: ストリーミング イベントを事前にフィルタする理由

パイプライン フロー

適応的実行: Beam DAG の動的な構成

パイプラインの実装

コストとパフォーマンスのメリット

重要ポイント

AI 時代の FinOps：エージェント向けの新しい柔軟な請求と費用管理

Gemini Enterprise の支出をコントロールしながらチームに柔軟性を提供

単一の Gemini Enterprise サブスクリプションで高度なエージェント ツールをデベロッパーに提供

Gemini Enterprise Flexible Savings Plans（FSPs）でよりスマートに予算を管理

財政規律を維持しながらチームに構築の自由を提供

AI 費用の最適化をさらに深めるには

Malachyte がマネージド リアルタイム AI で小売業のコールド スタート問題を解決した方法

Malachyte はお客様の売り上げをどのように伸ばしたのか

使ってみる

Gemini Enterprise、業界特化型ソリューション向けに進化

Gemini Enterprise for Financial Services によるイノベーション、セキュリティ、コンプライアンスの融合

Gemini Enterprise for Financial Services の主な構成要素:

法務実務向けに特化した AI である Gemini Enterprise for Legal

Gemini Enterprise for Legal の主な構成要素:

提供時期

Airtel、2026 年インディアンプレミアリーグのクリケット中継を完璧に配信

解決策: 標準化されたミューテーションコンバータパターン

Antigravity CLI をヘッドレスモードで使用する理由

クラウドエンジニアにとっての成果と重要なポイント

#3 Google Cloud を使用しています。コードの認証には、API キー、サービスアカウント、ユーザー認証情報のどれを使用すればよいですか？

#6 Standard PayGo、Priority PayGo、プロビジョンドスループットのうち、どの消費モデルを利用すればよいですか。

Pythian AI オペレーティングモデルの 4 つの柱

実際の導入効果: データベース運用からグローバルサプライチェーンまで

AI オペレーティングモデルを構築する準備はできましたか？

AI デベロッパーツールとエンタープライズグレードの管理機能を 1 つのサブスクリプションに統合

チームが好む開発環境にエージェントコーディングを直接導入

金融サービスにおけるエージェント型 AI を活用したオペレーショナルレジリエンスの構築

机上演習からレジリエンスインテリジェンスへ

制御と柔軟性を実現するデュアルオーケストレーション

スケーラブルでエビデンス対応のレジリエンステスト

レジリエンスインテリジェンスに向けて

アーキテクチャ: ストリーミングイベントを事前にフィルタする理由

パイプラインフロー

単一の Gemini Enterprise サブスクリプションで高度なエージェントツールをデベロッパーに提供

Malachyte がマネージドリアルタイム AI で小売業のコールドスタート問題を解決した方法

Box が Gemini Embeddings 2 でマルチモーダルエンタープライズエージェントを実現

エンベディングの改善によるメリット: ドキュメントコンテンツの次元の拡張

アーキテクチャソリューション: Gemini Multimodal Embeddings 2

マルチモーダルエンタープライズエージェントの 3 つのコアパターン

エージェント型エンタープライズコンテンツ管理の未来

メジャーがサポートされるようになった BigQuery Graph を使用して、信頼できるエージェントワークロードを実現

BigQuery Studio でグラフインテリジェンスを民主化