AI & 機械学習

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

#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 0x7f66e937cf40>)])]>

出典: 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 0x7f66e937c070>)])]>

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

最後に、今後に備えて、そのサービスアカウントに、ワークロードが実際に必要とする最小限の 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 0x7f66e937c9d0>)])]>

ステップ 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 0x7f66e937c4c0>)])]>

適切な再試行とバックオフを追加する。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 0x7f66e937c6d0>)])]>

この状況をどのように予測しますか？できれば、ユーザーから報告を受ける形ではなく。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 0x7f66e937c280>)])]>

出典: 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 0x7f66e937c610>)])]>

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

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

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

#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 0x7f66e937c340>)])]>

出典: 利用額上限の予算を管理する、プログラムによる通知を設定する、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 0x7f66e937c490>)])]>

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

次に、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 0x7f66e937c640>)])]>

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

金融サービスにおけるエージェント型 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 0x7f66e91a63a0>)])]>

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

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

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

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

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

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

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 エージェント基盤導入に関するご相談は、担当営業またはカスタマーエンジニアまでお気軽にお問い合わせください。

Gemini Enterprise データを Looker のセマンティックレイヤで制御してユーザーの信頼を確保

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

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

AI エージェントを大規模にデプロイする組織にとって、構造化データと非構造化データのギャップは、しばしば重大な問題となります。大規模言語モデル（LLM）は、テキストドキュメント、メール、PDF の解析には優れた力を発揮しますが、企業の未加工データベースには手こずることがあります。一方、標準的な自然言語から SQL への変換（NL2SQL）モデルは、データベーススキーマの相互適合性を推測に頼りがちで、予測不可能なクエリ、一貫性のない指標、AI ハルシネーションを生んでユーザーの信頼を損なう可能性があります。

Gemini Enterprise は、こうした課題を解決する役割を果たします。直感的なチャットインターフェースを通じて Google AI の最先端機能をすべての従業員に提供し、職場における AI 活用の「一元化された窓口」として機能します。しかも、Looker の統制されたセマンティックレイヤが Gemini Enterprise 内における構造化データの信頼できる基盤として機能するようになりました。これにより、Gemini Enterprise のすべてのユーザーは、信頼できるセルフサービスビジネスインテリジェンスを利用できます。このインテグレーションにより、Looker を使用するアナリストと管理者は、Agent-to-Agent（A2A）プロトコルを介して、会話型エージェントを Gemini Enterprise 環境にネイティブに公開できます。つまり、組織は、AI をフル活用するタスクフォースを編成して、リアルタイム分析を完備した安定性と信頼性の高いツールを提供できるようになったのです。しかも、ツールはワークスペースの日常業務同様、自然言語で対応し、活用することができます。Gemini Enterprise で会話型エージェントを簡単に提供できるようになったことで、必要な情報を見つけやすくなり、データドリブンな文化が促進され、誰もが AI を活用しやすくなりました。

構造化データと非構造化データの両方に対応するセマンティック基盤

Looker のセマンティックレイヤと Gemini Enterprise のインテグレーションにより、構造化データベースと非構造化ドキュメントの両方を 1 か所で、平易な自然言語でクエリできるようになりました。数値を把握するために、もうダッシュボードと他のツールを行ったり来たりする必要はありません。客観的かつ具体的な指標を現実世界のコンテキストに即座に結び付け、問題解決や意思決定を迅速に行うことができます。

Looker エージェントを公開し、Gemini Enterprise で使用可能に

AI ハルシネーションを最小限に抑える

一般的な AI chotbot は、非構造化クラウドデータベースを使用した「収益」や「離脱率」の計算を指示されると、どのテーブルを結合し、どのフィルタを適用し、どのタイムスタンプを信頼するか、などの推測が必要になります。このため、同じ質問をしても、そのときどきでまったく異なる回答が得られたりします。

Looker のセマンティックレイヤは、この推測を排除し、重要なコンテキストをコード化されたデータ形式で Gemini Enterprise にフィードすることで、エージェントが確定的で予測可能な回答を提供できるようにします。

code_block: <ListValue: [StructValue([('code', '[ Gemini Enterprise Chat UI ] \r\n │\r\n (A2A Protocol / NLP)\r\n ▼\r\n [ Looker Governed Agent ] ──► Generates Deterministic SQL\r\n │\r\n [ Looker Semantic Layer ] ──► Business-Approved Definitions & Logic\r\n │\r\n ▼\r\n [ Enterprise Data Cloud ] ──► (BigQuery, AlloyDB, Spanner, etc.)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f66e933baf0>)])]>

Gemini Enterprise でユーザーがビジネス KPI をリクエストすると、リクエストは Looker エージェントに直接ルーティングされます。セマンティックレイヤは、バージョン管理されたビジネスロジックに基づいて、正確な決定論的 SQL を生成します。これにより、たとえば、経営幹部が「収益」を尋ねたときには、推測ではなく、きちんと管理された正確な企業指標が得られるようになります。

堅牢なガバナンスとセキュアなアクセス管理

AI を企業のデータウェアハウスに導入する際には、データガバナンスとセキュリティが非常に重要です。組織は、企業情報が厳格な権限を通さずに緩く取り込まれたり、インデックス化されたり、公開されたりするリスクを負うことはできません。

その点、Looker と Gemini Enterprise のインテグレーションは、ゼロリスクのパススルーアーキテクチャに基づいて構築されており、データを処理はしますが、永続ストレージには書き込みません。Gemini Enterprise は、基盤となるデータベースのレコードを取り込んだり、複製したり、保存したりすることはありません。代わりに、Looker とのインテグレーションにより、A2A プロトコルを介して安全かつセキュアに運用し、次の基本原則に沿って処理します。

OAuth 認証: Gemini Enterprise 内で Looker エージェントを使用する際、エンドユーザーはセキュアな 1 回限りの OAuth 同意を提出する必要があります。これにより、Gemini セッションが特定の Looker 認証情報にバインドされます。
強力なガバナンスの適用: アーキテクチャはライブパススルークエリに依存しているため、Looker の既存の行および列単位のアクセス制御が維持されます。
厳格なセキュリティ分離: ユーザーが Looker プラットフォーム内で、たとえば地域別の給与や財務など、機密データの行を表示する権限を持たない場合、Looker エージェントは Gemini 環境でそのデータを能動的に制限します。エージェントを Agent Gallery に公開してアクセスしやすくしても、確立済みのセキュリティ制御がバイパスされることはありません。

技術的な機能性とエンタープライズ対応

A2A プロトコルを介して Gemini Enterprise にネイティブにデプロイできる Looker エージェントの効果は、スマートさの向上だけにとどまりません。セキュリティを犠牲にせずに、インタラクティビティと相互運用性を高める効果もあります。たとえば、このリリースには以下の機能が含まれています。

優れたビジュアルインタラクティビティ: グラフのサポート

「1 枚の写真は千の言葉に値する」と言われますが、ユーザーが Gemini Enterprise 内の Looker エージェントとやり取りすると、プラットフォームはテキストによる説明だけでなく、ネイティブでインタラクティブなデータグラフを提示できます。たとえば、月次販売実績や地域別の分布などの視覚的なトレンド情報を求めると、Looker エージェントはデータベースレスポンスを、プレゼン資料にそのまま使えるような豊かなビジュアルにマッピングして、ユニバーサルチャットボックス内に直接表示します。

注: バージョン 26.12 より前の Looker リリースで Gemini Enterprise に Looker エージェントを公開した場合は、これらの強化されたビジュアリゼーション機能を活用するために、エージェントを 26.12 以降のリリースで更新することをおすすめします。

ファーストパーティおよびサードパーティエージェントとの相互運用性

Gemini Enterprise に公開された Looker エージェントは、他のさまざまなエージェントおよびデータソースのコンテキストを理解することができます。Looker エージェントは、標準的な通信フレームワークを活用して、構造化され、管理されたインサイトを Deep Research エージェントなどの他のファーストパーティ Google Cloud エージェントや外部のサードパーティエージェントとセキュアに共有し、構造化されたワークフローを作成できます。これにより、複雑なマルチエージェントオーケストレーションが可能になり、企業の運用エージェントが Looker エージェントからデータを取得して、別の生産性ワークフローやサプライチェーンワークフローにフィードできます。

Looker ベースのユーザー認証

企業のガバナンスを維持するために、Looker と Gemini Enterprise のインテグレーションでは、ID を中心とした堅牢な認証モデルが実装されています。ユーザーは、1 回限りの OAuth 同意を提出し、基盤となる Looker 認証情報にアクティブな Gemini Enterprise セッションをセキュアにバインドする必要があります。これにより、データベースに送信されるすべての会話型クエリがユーザーレベルで認証され、既存の Looker 権限構造、行レベルのデータアクセスフィルタ、列レベルのマスキングルールが例外なく適用されます。

信頼できるデータをもたらす Gemini Enterprise

エージェント型 AI は未来の仕事を支えます。Gemini Enterprise は、このエージェント型 AI をデジタルタスクフォースとしてグローバルに展開する一元化されたセキュアなアーキテクチャを提供し、企業の開発者、従業員、顧客のための最先端の Google AI でビジネスを力強く後押しします。

Looker と Gemini Enterprise のインテグレーションにより、信頼できるデータ分析がビジネスユーザーに提供されるだけでなく、豊かなインタラクティビティ、視覚的なグラフ、データストーリーテリングが日常のワークスペースに直接追加されます。ビジネスユーザーは、エージェントを活用した、この新しい働き方を取り入れることで、テキストによる回答を得るだけでなく、そのままプレゼン資料に使えるような、運用指標や複雑な分析情報をわかりやすく提示するビジュアリゼーションを得ることができます。

まず、Gemini Enterprise でデータエージェントを公開する方法を学び、エージェントの事前定義されたコンテキストと分析力を組織全体で利用できるようにしましょう。

- プロダクトマネージャー、Tarunima Tripathi

WPP が AI マーケティングのためにプラットフォームとデータエンジニアリングを運用化

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

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

市場の細分化と経済の不安定化が無秩序に進むなか、マーケティングやコミュニケーションの代理店は、クライアントを獲得し、広告費用を最適化するために従来使用してきた人間の直感に頼ることができなくなっています。WPP は、AI を活用して市場動向の変化を把握することで、こうした推測に頼る必要をなくしています。これにより、ブランドは予測の確実性が得られ、市場のスピードに合わせて自信を持って投資できます。これがエージェント型マーケティングシステム WPP Open の価値です。

しかし、高度な AI モデルを適用して分析情報を強化する前に、WPP は重要なエンジニアリング上の課題を克服する必要がありました。モデルを構成するマーケティングデータが、世界中の数百もの代理店に分散していたのです。このような状況で、AI ツールを効率的かつ安全にデプロイすることはほぼ不可能でしたが、モデルへのアクセスは問題の一部にすぎませんでした。そして、データをモデルに取り込み、クリーニングし、提供するための信頼できる方法を構築するまで、WPP が生成 AI の本当の実力を引き出すことはできませんでした。

この問題を解決するため、WPP は Google Cloud と提携して、統合されたデータバックボーンとカスタムプラットフォームエンジニアリングパスを構築しました。現在、WPP はサーバーレスコンピューティングパターンとデータ処理ワークフローを標準化することで、標的型マーケティングキャンペーンを数か月ではなく数日で安全に展開できるようになりました。

サービスベースの集中型データ基盤の設計

この取り組みにおける重要な部分は、データの可用性向上と管理の一元化でした。これを実現するために、WPP は現在の本番環境にサービスベースのプロジェクト構造を採用しました。エンジニアリングチームは、すべてのワークロードを別個のサイロに分離するのではなく、Google Cloud Storage（GCS）と BigQuery を専用の共有データプロジェクトに一元化すると同時に、コンピューティングと処理のワークロードを異なる処理プロジェクトに分離しました。

この構造により、コアチームのユーザーエクスペリエンスが簡素化され、データ利用者全員が、統合された信頼できる情報源を操作できるようになりました。共有インフラストラクチャには、WPP のさまざまなプロダクトラインのデータが保存されているため、セキュリティを細部まで厳格に適用することが不可欠でした。同社は個々の GCS バケットと BigQuery データセットのレベルで Identity and Access Management（IAM）制御を直接適用することで、各チームがアクセスを許可されたデータのみを表示できるようにしました。

同時に、さまざまなパートナーからの元データは、未加工の入力データを整理して分離するために、専用の GCS バケットに保存されます。そこから、Managed Service for Apache Spark が Apache Spark のカスタムジョブを実行して、情報をクレンジング、正規化し、標準のコホート定義（SCD）に変換します。WPP のデータエンジニアリングチームは、サーバーレスアーキテクチャを、パイプラインオーケストレーション用の Kubeflow と組み合わせて利用することで、クラスタインフラストラクチャの管理でよく発生するオーバーヘッドを回避しました。これにより、ダウンストリームの GCS と BigQuery のレイヤに対するデータ変換ロジックに完全に集中できるようになりました。これらのレイヤが、最終的にオーディエンスとパフォーマンスの AI モデルにデータを提供することになります。

Google Cloud とのコラボレーションが成功したのは、ベストプラクティスに関する妥協のないプロ意識と、非常に実用的で現実的なソリューションのタイムリーな提供のバランスが取れていたからです。- WPP、シニアデータエンジニアリングリード、Jonas Dahlbaek 氏

データを統合コホートで標準化

元データが WPP の処理ゾーンに入ると、プラットフォームによって SCD に変換され、それがフレームワーク全体でキーイング目的で使用されるコアコンセプトになります。これらは、年齢、性別、地域、商品、興味 / 関心の 5 つのキーに基づきます。しかし、これらの基礎となるデータ定義は流動的であり、進化するマーケティングのコンセプトを反映するために継続的に正規化されます。その結果、この統一された構造により、WPP は機密性の高い基礎的な詳細を公開したり、共有識別子に依存したりすることなく、グローバル規模でデータを結合および集計できます。

プラットフォームのコア処理エンジンは、包括的な可視性とコンプライアンスを確保するために、型安全性を備えた Scala で構築されました。このカスタムフレームワークは、データの変換方法を厳密に制御するとともに、キュレートされたデータセット内のすべてのデータポイントをその起源までたどれることを保証しながら、ソースの完全なトレーサビリティを本質的にサポートします。データサイエンティストと監査担当者は、モデルにどのような情報が入力されるかを正確に把握する必要があるため、これはエンタープライズ AI アプリケーションを構築する際に重要なレベルのトレーサビリティです。ただし、WPP はそれと並行して、全社的なデータガバナンス自動化のために、将来的に Google Cloud Knowledge Catalog に移行する準備も進めています。

Google Cloud との連携は、エンジニアリングの取り組みを迅速化、標準化するうえで非常に役立っています。大量の断片化されたデータが日々課題となる環境においては、適切なインフラストラクチャの存在が AI 時代に成功を収めるために最も重要であり、社内の開発者と AI マーケターの双方に役立ちます。- WPP、OI および Google パートナーシップ担当プロダクトマネージャー、Suleman Khan 氏

エンタープライズソフトウェアライフサイクルの標準化

これらのステップをすべて実施しても、データの処理は WPP にとってまだ課題の半分にすぎません。同社のプラットフォームエンジニアリングチームは、アプリケーションを提供し、基盤となるインフラストラクチャを管理するために、再利用可能な継続的インテグレーションと継続的デプロイ（CI / CD）のテンプレートスイートを GitLab で開発し、一元化しました。これにより、WPP は個々の開発チームの認知負荷を軽減するとともに、すべてのデプロイが厳格な全社的セキュリティ基準を満たすようにしました。

これらのテンプレートは、さまざまなエンタープライズワークロードを自律的に管理します。テンプレートスイートには、フルスタックのウェブアプリケーション、データのバッチ処理、スケジュール設定されたパイプライン用の汎用 Cloud Run テンプレートが含まれています。また、マルチステージワークフロー用のデプロイ専用テンプレートと、イベントドリブンマイクロサービス用の Cloud Run functions デプロイテンプレートも含まれています。

再ビルドなしのプロモーションの実装

本番環境でコンテナイメージを再ビルドすると、不必要なリスクや構成ドリフトが発生する可能性があります。WPP は、環境の整合性を維持するために、「一度のビルドで何度でもデプロイする」手法を採用し、IAM ロジックと Google Cloud Artifact Registry の構成をプロジェクト間で適用しました。

このプロセスでは、開発者が開発環境でコンテナイメージを構築してテストします。これらの不変のコンテナイメージは、検証後にそのまま本番環境にプロモートされます。この再構築不要のプロモーションにより、デプロイステージ間で完全な整合性が確保され、本番環境での予期しない動作がなくなります。CI / CD テンプレートは、段階的なトラフィック移行も容易にします。これにより、チームは完全なロールアウトを開始する前に、トラフィックのごく一部を新しいリビジョンにルーティングできるようになりました。

不変のデプロイ、追跡可能なデータ、揺るぎない信頼。AI に何が入力されるかを正確に把握できれば、光の速さでリリースできます。- WPP Media、DevOps（I&P）担当アソシエイトディレクター、Ranjith K Poldas

セキュリティとインテリジェントネットワーキングの自動化

この最新式のアーキテクチャでは、エンタープライズセキュリティが WPP の基盤となるイネーブラーとして機能するため、同社は Wiz のセキュリティスキャンを CI / CD パイプラインの push 前のフェーズに直接統合し、コードがマージされる前に脆弱性を検出できるようにしました。また、Google Cloud Identity-Aware Proxy を利用して、社内アプリケーション全体にゼロトラストアクセスを適用しました。

運用をさらに簡素化するために、WPP はインテリジェントな Virtual Private Cloud（VPC）ロジックを盛り込んだテンプレートを採用しました。この構成では、以前の VPC コネクタと最新のダイレクト VPC アクセスの間でネットワークの競合が自動的に特定され、解決されます。このネットワーキングの自動化により、デプロイの失敗が防止され、リリースサイクルが加速されます。

運用の健全性をモニタリングして ROI を促進

復元力のあるプラットフォーム基盤には詳細なオブザーバビリティが必要であるため、WPP のエンジニアリングチームは現在、デプロイ頻度のみに頼らずに、厳格な運用指標をモニタリングしています。チームは、4xx と 5xx のエラー率とともに、p50、p95、p99 のパーセンタイルでリクエストのレイテンシを追跡しています。また、コンテナの起動時間をモニタリングしてコールドスタートを軽減するとともに、CPU とメモリの全体的な使用率を追跡しています。この詳細レベルにより、データパイプラインとサーバーレスインフラストラクチャの両方で、常に高い可用性が維持されることになります。

「データエンジニアリング、プラットフォームインフラストラクチャ、AI 統合にまたがる複数の複雑なワークストリームにわたって、これほど大規模な変革を推進するには、単なる連携以上のもの、つまり深い相互信頼が必要でした。Google Cloud と WPP は真のパートナーとして連携し、プロダクションレディなプラットフォーム機能を予定どおりに実現しました。」Google Cloud、プログラムマネージャー、Yang Yue

WPP は、このスピード感でデータと AI スタックを運用化することで、高度なワークロードに必要なインフラストラクチャを実現しました。そのビジネスインパクトは明らかで、数値化も可能でした。この二重の基盤を構築することで、同社はクリエイティブと戦略にかかる時間を 4 週間からわずか 3 時間に短縮しました。また、制作効率が 70% 向上し、コンテンツ量が 33 倍に増え、キャンペーンの投資収益率が 2.8 倍に向上しました。まとめると、WPP は Google Cloud と提携して、幅広いプロダクトとツールのスイートを実装することで、短期間で高い ROI を実現し、全社的に生産性、効率性、信頼性、セキュリティを向上させることができたのでした。

- テクニカルソリューションコンサルタント、Utkarsh Bhardwaj

- 戦略的クラウドエンジニア、Prabha Arya

API 対応エコシステムでアジリティを獲得した Deutsche Bank の手法

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

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

銀行のデジタルトランスフォーメーションというと、モバイルアプリや新しいデジタルサービスといった、目に見える結果に目を奪われがちです。しかし、これらのサービスすべてを実現している、目に見えないインフラストラクチャが存在します。それが API です。Deutsche Bank では、API を単なる技術的な「配管」ではなく、現代の銀行業務の「神経系」であると認識していました。

数年前、当行のアプリケーション環境はモノリシックシステムが主流でした。これらをモジュール式の再利用可能な API に分割する方法を評価する中で、明らかになった点が 1 つあります。それは、単に業務を API に分解するだけでは不十分で、これから生じるものを管理するための一元的な API 管理プラットフォーム（APIM）が必要であるということです。ドキュメント、セキュリティポリシー、ガバナンスが、後付けではなく最初から組み込まれているプラットフォームが必要でした。

問題は、モダナイズの方法だけではありませんでした。特に技術面で新たなパラダイムシフトが発生している中で、お客様に最適なサービスを提供し、将来の機会に備える方法が重要でした。

現代の銀行業務の需要に対応できる適応性、スケーラビリティ、信頼性、安全性、AI 対応能力を備えたシステムを必要としていた当行は、APIM プラットフォームとして Google Cloud の Apigee を選択しました。

バックボーンの構築: 4 つの主要な機能

現在、フィンテックパートナーと当行をつなぐオープンバンキング API から、さまざまなバンキングプラットフォームを支える社内マイクロサービス、オンラインバンキングなどのシームレスなデジタルエクスペリエンスを可能にするクライアント向けアプリケーションまで、当行の API エコシステムを Apigee が管理しています。

このプラットフォームが提供する 4 つの重要な機能は次のとおりです。

1. スピードを犠牲にしない統合ガバナンス

Apigee は、当行の API カタログの基盤です。すべてのエンドポイント、バージョン、依存関係が文書化され、検出可能な状態になっています。開発チームは、機能を再構築するのではなく、既存の API を探して再利用しています。数日をかけて顧客データ API を探し回る環境から、どの開発者でもアクセスできる検索可能なリアルタイムカタログに移行しました。

しかし、ガバナンスは本来、ボトルネックとなるものではなく、ガードレールの役割を果たすものです。当行では、Apigee のポリシーフレームワークを使用して、標準を自動的に適用しています。現在では、OpenAPI 仕様、スキーマ検証、エラー処理がプラットフォームに組み込まれています。一貫したフレームワーク内で作業できるため、チームの作業が迅速化しました。

2. セキュリティ: 従業員のオンボーディングとの類似性

API のセキュリティについて、新入社員のオンボーディングにたとえて考えてみましょう。新入社員に、初日からすべてのシステムに対するアクセス権を付与することはないでしょう。最小権限の原則に従い、その役割に必要な権限のみを付与します。異動した場合は、アクセス権が更新されます。退職した場合は、アクセス権が直ちに取り消されます。Apigee は、サービスやアプリケーションについて同様に機能します。

たとえば、顧客アカウントにアクセスする新しいサービスに接続する場合、いきなりすべてを許可することはありません。OAuth2 スコープと API キー管理を通じて、次のようにエージェントがアクセスできるものを細かく定義します。

口座残高の読み取り: 許可する。
電信送金の開始: 許可しない。
90 日間の取引履歴へのアクセス: 許可する。
過去のデータ全体: 昇格された権限がある場合のみ。

従業員のアクセス権と同様に、これらの権限は一元管理され、定期的に監査され、即座に取り消すことができます。コンプライアンスを目的に従業員の活動を追跡する場合と同様、Apigee はすべての API 呼び出しをログに記録し、誰が、いつ、どのデータに、どのような理由でアクセスしたのかを確認します。

この点は、大量のデータを処理する自動化システムでは特に重要です。構成が不適切な場合、自動化されたサービスが、休むことなく 1 分間に数千回もの呼び出しを行う可能性があります。レート制限と割り当てを適用することで、問題が発生した場合でも、その影響範囲を抑えることができます。

3. 大規模なレジリエンスとパフォーマンス

銀行業務にダウンタイムはありません。顧客が午前 3 時に残高を確認した場合や、市場の取引活動が急増した場合も、API が即座かつ確実に応答する必要があります。

Apigee のロードバランシングと自動スケーリングにより、こうしたトラフィックが均等に分散されます。ヘルスチェックと回路ブレーカーが、問題のあるサービスを自動的に回避します。また、頻繁にアクセスされるデータについては、Apigee のキャッシュが、バックエンドにアクセスすることなくミリ秒未満の応答を実現します。

4. オブザーバビリティ: すべて測定可能

Apigee を導入する前は、API のパフォーマンスを把握することは、別々の箱からピースを集めてジグソーパズルを組み立てるようなものでした。現在は、リアルタイムのトラフィック、サービス別のエラー率、消費者別の使用状況分析、コンプライアンス指標を示す統合ダッシュボードがあります。この可視性が、運用、パートナーの価値を追跡するプロダクトマネージャー、異常を特定するセキュリティチームの支えとなっています。

Apigee は、API ライフサイクル全体を管理するための中心的な機能スイートを提供する

将来を見据える

当行は、API エコノミーのためにこのインフラストラクチャを構築しました。また、そうすることで、デジタルバンキングの未来に向けた強固な基盤も構築できました。業界の進化に応じて、この API ファーストのアプローチは、次世代のサービスを統合するうえで不可欠になるでしょう。

デジタルバンキングの進化に伴い、リアルタイムで対応、予測、支援できるインテリジェントサービスへの移行が進んでいます。リアルタイムのパターン認識、予測インサイト、AI 搭載アシスタントなどの機能は、日常的なデジタルエクスペリエンスの一部になりつつあり、導入が加速するにつれて、その可視性と影響力が高まっています。これらの機能はそれぞれ API を使用します。そして、超低レイテンシ、高スループットのデータフロー、複数の API にわたる安全なオーケストレーションといった新しい要件が生まれます。

当行は、Apigee で柔軟な API プラットフォームに投資したため、インフラストラクチャを再構築する必要はなく、こうした将来のニーズに合わせてインフラストラクチャを適応させ、最適化していく準備が整っています。

新たな標準: MCP、A2A、そして未来

業界は新たな統合標準を模索しています。Model Context Protocol（MCP）や Google の Agent2Agent（A2A）などのプロトコルは、既存の API インフラストラクチャを基盤としているため、興味深いものです。

Apigee で管理している当行の API では、こうした進化を最適な形で活用できます。たとえば、MCP は OpenAPI 仕様のメリットを享受でき、A2A は OAuth2 フレームワークを活用できます。そして、どちらも当行が構築したガバナンスを基盤にすることができます。

また、最新のワークフローに対応しながらセキュリティ管理を維持するために、新しいタイプのサーバーを Apigee プロキシの背後に配置するといったパターンも検討しています。当行の「常時 API」パターンでは、サービスへのアクセス方法に関係なく、サービスが集中管理のメリットを確実に享受できます。

MCP と A2A は補完関係にあり、MCP はツールとリソースに、A2A はピアコラボレーションに重点を置いている

ビジョン: ユニバーサルインターフェースとしての API

すべての銀行業務機能は最終的に API として公開されるようになるでしょう。これは、API が流行しているからではありません。モバイルアプリ、パートナーフィンテック、分析プラットフォーム、その他の自動エージェントなど、何によって利用される場合でも、最も柔軟かつコンポーズ可能で、管理しやすい機能の共有方法だからです。

Deutsche Bank では、この変化がすでに形になりつつあります。当行のコアプラットフォームを支えるものと同じ API 基盤が、銀行全体でのよりインテリジェントな AI 支援サービスへの進化を可能にしています。この基盤は、これらの機能を実際に活用するために必要な整合性、ガバナンス、スケーラビリティを提供し、新しいインテリジェントサービスが登場したときに、シームレスかつ安全に、エンタープライズ規模で統合できるようにします。

Apigee は、すべてのユースケースに拡張できるガバナンスを提供することで、これを可能にします。重要なのはイノベーションを制御することではなく、安全に実現することです。

学んだ教訓

優れたドキュメントに投資する。セマンティックな要約と明確なスキーマは、単に追加するものではなく、開発者と AI の両方にとって欠かせない基盤です。
セキュリティを従業員のオンボーディングのように扱う。最小権限とロールベースのアクセス権は、API にも同様に適用されます。
オブザーバビリティは競争上の優位性をもたらす。統合された分析により、データに基づく意思決定が可能になります。
今すぐ将来に備える。API 管理インフラストラクチャが高度な統合レイヤになります。
好奇心を持ち続ける。さまざまな新標準を試しましょう。柔軟性が勝利の要因になります。

まとめ

当行は転換点を迎えています。API エコノミーにより、フィンテックとオープンバンキングが実現しました。今では、同じインフラストラクチャが、次のイノベーションのバックボーンとして機能できます。API プラットフォームへの当行の投資は、API をより適切に管理することだけが目的ではありませんでした。次に何が起こっても対応できる基盤を構築することが重要でした。

業界が変化する中でも、当行の準備は万全です。未来は、破壊を伴わずに迅速に行動できる組織のものです。当行の場合、その未来は Apigee によって実現されます。

- Deutsche Bank、API 戦略およびインテグレーション担当、Stefan Mesquita 氏

Spanner Graph で小売商品の検索性能を強化し、データベースのメンテナンス工数半減を達成した Target の取り組み

Thu, 20 Aug 2026 01:10:00 +0000

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

現代の小売環境における買い物客は、高度にパーソナライズされた商品発見体験と、自然で本物らしく、心から役に立つと感じられる会話型アシスタンスを期待しています。今日、優れた商品検索には、商品、カテゴリ、顧客の意図の密接な関係やセマンティックな意味を理解することが求められます。キーワードや基本的なブラウジングだけでは不十分です。

Target でこの作業を担当しているのがゲストプロダクトコンフィデンスプラットフォームチームです。評価、レビュー、AI を活用したデジタルショッピングアシスタントなど、信頼を確立し、購入の意思決定を導く機能を構築する責任を担っています。その好例が、2025 年のホリデーシーズンにオンラインストアと Target アプリにリリースされた Gift Finder チャットエージェントです。このエージェントは、親しみやすい会話を通じて、買い物客がぴったりの商品を見つけるのをサポートします。

このようなリアルタイムのパーソナライズとコンテキストリッチなセマンティック応答をグローバル規模で提供するには、断片化されたデータエコシステムを脱却し、統合型のデータプラットフォームに移行するという重要なアーキテクチャ上の課題があることがわかりました。当社は、高スループットのトランザクションワークロード、高度に接続されたグラフ関係、ベクトル類似度検索、全文キーワード検索をまとめてサポートできるソリューションを必要としていました。

この投稿では、これら 4 つのすべてを実現するうえで Spanner が果たした役割について説明します。

断片化されたアーキテクチャからの脱却

従来の Target のディスカバリーデータエコシステムは、検索と転置インデックス用の Elasticsearch クラスタと、トランザクションデータ用の個別の NoSQL データストアの組み合わせで構成されていました。この断片化されたアーキテクチャは機能はするものの、運用上および技術上の大きな課題を抱えていました。

コンテキストの分断: 検索、ベクトル、トランザクションの各データベースの完全同期は常に課題でした。情報がサイロ化されていることで、コンテキストの欠落、属性間の関係の断絶、クエリ結果の不整合が発生していました。
運用上のオーバーヘッドの増大: 独立したクラスタの管理、検索インデックスのチューニング、複雑なカスタム同期と集計ロジックの処理を実行するには、エンジニアリングチームによる集中的な手動介入が必要でした。
拡張のボトルネック: 小売データドメインを拡張するには、新しいデータベースコレクションの追加、複雑な結合の維持、検出システムとコアトランザクションシステムにおける弱いトランザクション保証への対処が必要でした。
サイロ化されたインテリジェンス: グラフの関係、ベクトル類似度、キーワード検索インデックスを 1 件のトランザクションでクエリする機能が欠如していました。

AI を活用した次世代のゲストエクスペリエンスを構築するには、1 つのプラットフォームに統合する必要がありました。

Spanner Graph でエンタープライズオントロジーを構築

スタンドアロンのベクトルデータベースやニッチなグラフデータベースなど、複数の専用テクノロジーを評価しました。しかし、単一目的のデータベースを追加すると、運用の複雑さとデータ同期パイプラインのパフォーマンスが悪化するだけでした。

最終的に選択した方法が、Spanner Graph を利用してエンタープライズオントロジーを構築することでした。これは「グラフのグラフ」パラダイムであり、生成 AI を活用した大規模なショッピンググラフの構築を可能にします。

データを統合することで、セマンティックデータ、グラフ関係、ベクトルエンベディング、運用トランザクションを 1 つの屋根の下に集約します。これにより、トランザクションの状態とセマンティックインテリジェンスの両方について、Spanner が信頼できる唯一の情報源となります。

当社のハイレベルなアーキテクチャは、以下の 3 つの主要な柱で構成されています。

1. エンタープライズ拡張このレイヤは、当社のエンタープライズ小売カタログをキャプチャし、複数のバックエンドソースから関連するメタデータを集約し、エージェントによるデータ拡充に生成 AI を活用して、取り込む商品データの品質と深さを大幅に向上させます。

2. グラフ、ベクトル、検索の統合ストアSpanner Graph では、複数のデータベース間でデータを移動させるのではなく、エンティティノード、関係エッジ、ベクトルエンベディングを同じデータベースエンジンに保存します。Spanner Graph は、リレーショナルテーブルに対するマルチホップグラフ探索、セマンティックベクトル類似検索、全文キーワードクエリをネイティブにサポートしています。このマルチモデルシナジーはネイティブであるため、脆弱な外部同期パイプラインを介さずに分散ワークロード全体で厳格な ACID トランザクションを実現し、絶対的な正確性を確保できます。

3. オーケストレーションと AI レイヤこのレイヤは、会話型ゲストインターフェースを強化し、Spanner Graph から直接供給される豊富な構造化コンテキストを利用して LLM をグラウンディングします。責任ある AI プロセスを管理し、生成された出力を評価しながら、非常に具体的な商品関係を抽出することで Gift Finder などのツールを強化します。

ダウンタイムなしでスムーズに段階的に移行

当社の検索と見つけやすさのインフラストラクチャは何百万人もの顧客が利用する重要なものであるため、移行にあたってはダウンタイムをゼロにする慎重なアプローチが必要でした。この移行は、4 つの構造化されたフェーズで実行されました。

スキーマとオントロジーのマッピング: Spanner Graph スキーマ内で、商品、カテゴリ、ブランド、顧客の好みなどの特定の小売エンティティと、それらに対応する関係を定義しました。
データ統合と並列リプレイ: ミューテーションベースのデータ統合を並列パイプラインで構築しました。これにより、リアルタイムのトランザクションの更新を継続的にリプレイし、スキーマ変換を適用して、エンベディングを生成し、リアルタイムで Spanner Graph に直接書き込むことができました。
カナリアデプロイ: ライブの読み取りトラフィックを新しい Spanner Graph ベースのプラットフォームに徐々に移行し、実際の小売ワークロードでクエリのパフォーマンス、セマンティックの精度、データベースの安定性を検証しました。
カットオーバーとクリーンアップ: パフォーマンスを徹底的に検証した後、すべての検索と見つけやすさのトラフィックを Spanner に完全に移行し、以前の Elasticsearch スタックを廃止することで、Elasticsearch クラスタのメンテナンスの負担を完全に排除しました。

ビジネスへの影響

Spanner Graph 上で直接構築することで、技術面とビジネス面で測定可能な成果を達成できました。

究極の GraphRAG 基盤: 従来の RAG はフラットなベクトル類似度に依存しているため、たとえば特定のおもちゃと互換性のあるアクセサリーや年齢適合性の照合など、商品間の構造化された関連性を見落としがちです。統合された GraphRAG アーキテクチャ内で深いグラフ探索とセマンティックベクトル検索を組み合わせることで、LLM を高精度のコンテキストでグラウンディングしました。これにはおすすめの関連性を直接改善する効果があり、顧客の満足度とネットプロモータースコアの向上につながりました。

SQL と GQL の相互運用性の統合: Spanner Graph を使用すると、デベロッパーは標準 SQL と GQL（Graph Query Language）を使用して、1 回のクエリで構造化されたリレーショナルカタログデータと接続されたグラフ関係に対して処理を要求できます。これにより、これらのパラダイムを橋渡しするためのデータの重複、レイテンシ、複雑な ETL パイプラインが不要になります。

成長の上限がないサーバーレスのスケーラビリティ: Spanner は、ブラックフライデーやサイバーマンデーなどの小売イベントのピーク時に、予測不可能な大規模なトラフィックの急増を自動的に処理します。Spanner に組み込まれたオートスケーラーがコンピューティング容量を動的に調整し、期間限定のプロモーション特典期間中に発生した高負荷のバーストトラフィックを、パフォーマンスを犠牲にすることなく処理しました。

インフラストラクチャのメンテナンス工数の半減: トランザクション NoSQL データベースと検索インデックスデータベースを 1 つのマネージド Google Cloud サービスに統合することで、別々のデータベースクラスタを維持する運用上の負担がなくなりました。開発者がデータベース管理とインフラストラクチャの維持に費やす時間が 50% 削減され、顧客向けの新しい AI 機能をより迅速に構築してデプロイできるようになりました。

Spanner Graph への移行により、当社の生成 AI ロードマップは加速しました。これは、適切なデータ基盤の構築が提供する価値を証明する究極の例となりました。

AI アプリの強化を目指しているのであれば、まずは、適切なグラフ機能を備えたデータベースを事実上無制限の規模で利用することから始めましょう。Spanner Graph で組織のデータをアクションに変える方法をご確認ください。

- プリンシパルエンジニア Sayanti Dey

- Target 社シニアエンジニアリングマネージャー Kaushik Shelat 氏

「The Forrester Wave™: AI Platforms, Q3 2026」で Google がリーダーに選出

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

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

Google Cloud は、あらゆる規模の組織が複雑なエージェントワークフローを確信を持って構築し、運用できるよう支援を行っています。世界水準の AI 研究と、オープンで完全に統合された AI プラットフォームを組み合わせることで、お客様にイノベーションのための柔軟性と、測定可能なビジネス価値を創出するための基盤を提供しています。

その中心にあるのが Gemini Enterprise です。これは、エージェント型エンタープライズを推進し、ビルダーのニーズに応え、すでに組み込まれた企業レベルの信頼性を提供できるように設計された統合プラットフォームです。

この統合されたアプローチが評価され、Google は「The Forrester Wave™: AI Platforms, Q3 2026」レポートにおいてリーダーに選出され、戦略カテゴリで最高スコアを獲得しました。

エージェントの時代を推進

エージェントがビジネスのあらゆる部分に組み込まれるようになったため、組織は統合プラットフォームを必要としています。Gemini Enterprise は、組織全体にとって AI の表玄関として機能し、ビジネスユーザー、デベロッパー、IT リーダーを全社共通の背景知識でつなぐことで、既存のサイロを解消します。

Gemini Enterprise Agent Platform は、技術チームと IT リーダーが本番環境レベルのエージェントを安全かつセキュアに、費用対効果の高い方法で構築、デプロイできるようにする基盤です。Agent Platform で構築されたエージェントは、Gemini Enterprise app を通じて全従業員にデプロイできるため、カスタムエージェント機能をすべての従業員が直接利用できるようになります。

Gemini Enterprise は、エンタープライズデータ、フロンティアモデルの機能、デベロッパーツール、IT 運用を 1 つに統合することで、チームがプロダクトやサービス、複雑なエージェントタスクを変革しながら、あらゆる段階で一元管理を維持できるようにします。

New Way Now: Mars、Gemini Enterprise でマーケティングキャンペーンを数か月から数週間に短縮

Mars が Gemini Enterprise を使用して、どのようにマーケティングキャンペーンを数か月から数週間に短縮したかをご覧ください

ビルダーのニーズに合わせた対応

開発チームがエージェントを構築する方法は、2 つとして同じものはありません。コーディング環境で作業する人もいれば、ローコードツールに頼る人もいます。多くの組織では、さまざまなモデルが混在しています。Gemini Enterprise は、その実情を考慮して構築されています。Google は、あらゆるチームのスキルセットに合わせたプラットフォームを提供しています。ハイコード開発者は複雑なエージェントシステムを構築でき、ビジネスチームや運用チームはローコードツールやノーコードツールを使用してエージェントの動作を迅速に設計、テストできます。また、200 以上のネイティブモデルとサードパーティモデル、事前構築済みのエージェントテンプレートにアクセスできるため、エンジニアリングチームはプロトタイプからデプロイまでを迅速に進めることができます。

真のエンタープライズ AI は、テキスト以外にも対応できなければなりません。Gemini Enterprise はマルチモーダルな設計であるため、1 つのワークフローでテキスト、コード、音声、画像、動画の入力をネイティブに理解し、推論して生成します。どこに保存されている社内データでも、こうしたマルチモーダルインテリジェンスとセキュアに接続することで、エンジニアリングチームはその情報を状況に応じたビジネスエクスペリエンスへと変換できるようになります。

New Way Now: Kohl’s、Gemini Enterprise でデータ分析を活発な対話へと変革

Kohl’s が Gemini Enterprise を使用してデータ分析をアクティブな会話に変え、パーソナライズされたカスタマーエクスペリエンスを提供している方法をご覧ください

組み込み済みの企業レベルの信頼性

信頼は AI 導入の基盤です。そのため、Agent Platform はエンタープライズグレードのガバナンス、セキュリティ、オブザーバビリティをデフォルトで備えて構築されています。確信を持ってスケールできるよう、Agent Platform には、組み込みのガードレール、継続的な評価、費用、レイテンシ、トークン使用量のリアルタイムトラッキングなどの機能が備わっています。この運用上の透明性により、組織はエージェントワークフローをビジネス全体に安全に拡大するために必要な制御を確保できます。ビルダーは、Knowledge Catalog などの機能を活用して、企業全体にわたるユニバーサルコンテキストエンジンを確立し、ゼロコピーフェデレーションでメタデータを集約してエージェントの精度を向上させることもできます。

New Way Now: TELUS、Agentic Data Cloud を構築し、接続性をカスタマーインテリジェンスへと変革

TELUS が Gemini Enterprise を使用してデータサイロを Agentic Data Cloud に変換し、リアルタイムでプロアクティブなカスタマーエクスペリエンスを推進している方法をご覧ください。

今後の対応

この評価は、オープンでスケーラブル、かつ強力な AI プラットフォームを提供するという Google の取り組みが認められた結果だと考えています。エージェントシステムがエンタープライズソフトウェアの構築プロセスに変革をもたらすなか、Gemini Enterprise は、デベロッパーが確信を持って構築するために必要な基盤を提供し続けます。

レポートについてさらに詳しく知りたい場合は、「The Forrester Wave™: AI Platforms, Q3 2026」レポートの全文をこちらからご覧いただけます。

^{Forrester がリサーチに関する発行物に掲載されている特定の企業、製品、ブランド、サービスを推奨することはありません。また、当該発行物に記載されている評価に基づいて、特定の企業またはブランドの製品またはサービスを選択するよう個人に助言することもありません。情報は、利用可能な最適なリソースに基づいて示されます。内容はその時点での判断によるものであり、変更される可能性があります。このレポートは、インタラクティブなモデルやフレームワーク、ツール、データ、アナリストによるガイダンスへのアクセスなど、Forrester が提供する広範なリソースの一つです。詳しくは、Forrester の客観性に関するこちらの説明をご覧ください。}

- アウトバウンドプロダクト管理担当シニアディレクター、Jamie de Guerre

AI を活用した現実のメインフレームモダナイゼーション: メインフレームからクラウドへの安全でスケーラブルな道筋

Wed, 19 Aug 2026 01:40:00 +0000

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

長年にわたり、レガシーメインフレーム資産を抱える企業は、重大なジレンマに直面してきました。メインフレームの保守を継続して実質的にモダナイゼーションを先送りにするか（いずれ対処が必要なことは承知の上で）、あるいは未知の要素やリスクが渦巻く危険な「ビッグバン」移行を断行するか、という選択です。

Google Cloud では、AI の力とクラウドのアジリティを活用し、反復的かつ継続的なモダナイゼーションを可能にするモダナイゼーション戦略という代替案を提案しています。このアプローチは、メインフレームのモダナイゼーションが単なるコード間の変換作業ではない、という本質的な事実に基づいています。もちろん、他から独立した単一の小規模なアプリケーションであれば、昨今の AI や大規模言語モデルの進歩もあり、モダナイズは比較的容易です。真の課題は、大規模なグローバル企業に見られる複雑に絡み合った依存関係やレガシーデータ形式を損なうことなく、機能の同等性を確保しながら、実際の規模でモダナイゼーションを実現することです。

たとえば、以下のような「現実世界」の課題があります。

アプリケーションロジックが、レガシーな独自のデータベースやレコードスキーマと、直接かつ緊密に結合している。
VSAM、フラットファイル、IMS 階層構造など、AI エージェントがアクセスできない非リレーショナル形式。
CICS や IMS TM などのトランザクションモニタが、高度に統合されたトランザクション管理を提供している。1 つのトランザクションシナリオが数百万行ものコードで構成されている場合がある。
複雑な条件付きステップロジックと依存関係を持つ、入り組んだシーケンシャルワークフロー。
CTG、IMS Connect、MQ、LU 6.2 ソケットなどの独自プロトコルを利用した、システム内外の境界。
専門性の高い独自のメインフレームユーティリティスイートによる、運用上の深いロックイン。

つまり、メインフレームアプリケーションの実際のモダナイゼーションは、COBOL から Java への変換をはるかに超えるものです。また、基盤となるデータモデルをモダナイズし、数十年にわたって不明瞭だったアプリケーションの依存関係やインターフェースに対処し、さらに基盤となるデータストアもモダナイズする必要があります。最も重要なのは、本番公開の前に、実際の本番トラフィックを使用して最新のコードを検証し、リスクを軽減する必要があるということです。

Google のアプローチでは、コード理解のための高度な推論と Gemini モデルのスケールを、メインフレーム固有のモダナイゼーションプロダクトと組み合わせて、現実世界の複雑さと課題に対処します。Google のソリューションは、評価、モダナイゼーション、リスク軽減、データ移行という 4 つの主要な柱で構成されています。

では、それぞれ詳しく見ていきましょう。

1. 評価: レガシーアプリケーションの AI リバースエンジニアリング

Google の Mainframe Assessment Tool（MAT）は、レガシーコードベースを極めて大規模にリバースエンジニアリングし、現在のレガシーアプリケーションの動作を明確化するとともに、モダナイゼーションに必要な基盤を構築します。

MAT は、メインフレーム環境に関する詳細な分析情報を、次の 4 つの主要分野で提供します。

依存関係の可視化: DB2 データベースや VSAM ファイルなど、異なるアプリケーションとデータストア間の関係や相互接続をマッピングします。
自動ビジネスルール抽出（BRE）: 複雑なメインフレームアプリケーションロジックを、分かりやすい自然言語による要件と視覚的なディシジョンツリーの両方に変換します。
自動ドキュメント生成: 本番環境のメインフレームのソースコードから、包括的で最新の技術ドキュメントを直接生成します。
ドメインとビジネス機能の検出: アプリケーションの境界を自動的に特定し、アプリケーションをハイレベルなビジネスドメインにグループ化して、入力、出力、インターフェース、処理が行われる場所など、これらのドメインのアーキテクチャを可視化します。

MAT は、既存のアプリケーションとビジネスプロセスを理解し、クラウドネイティブな未来を設計する上で不可欠な、クリーンで検証済みのロジック要件を提供します。これらの出力を、MCP を介してエージェント型のモダナイゼーションワークフローに直接統合することで、高精度のコード変換、実行のスケーリング、独自のコードベースの最適化を保証するために必要な、アプリケーション固有のきめ細かいコンテキストを AI エージェントに提供します。

Google Mainframe Assessment Tool: レガシーなメインフレームアプリケーションからのビジネスルール抽出（BRE）

Google Mainframe Assessment Tool: アプリケーションのリバースエンジニアリングにより、入力、出力、処理、ユーザーインターフェースを可視化するインフォグラフィックを生成している様子

2. モダナイゼーション: コード変換

モダナイゼーションには、目指すべきビジネス成果に合わせた戦略的な選択が必要です。すべてのユースケースに適合する唯一のパスというものは、ほとんど存在しませ。Google の柔軟なアプローチにより、ビジネスに必要なモダナイゼーションの深さを正確に選択し、メインフレームのワークロードごとに異なる戦略を適用することが可能になります。理論と実行（AI から実用 AI へ）のギャップを埋めるため、Google はメインフレームモダナイゼーションプロフェッショナルサービスチームと提携し、専門的な AI エージェントを構築しました。これらのエージェントは、実証済みの手法や現場での実践的な経験を、構造化されたエージェント型のモダナイゼーションワークフローへと直接コード化します。Google のエージェント型メインフレームモダナイゼーションソリューションでは、次の 2 つの方法でモダナイゼーションを実現できます。

書き換え / 再構築

ビジネスロジックのイノベーションによって戦略的 ROI が最大化されるレガシーアプリケーションには、このパスを選択します。このパターンでは、Mainframe Assessment Tool（MAT）によるビジネスルールの抽出と、Mainframe Modernization Agents によるフォワードエンジニアリングを組み合わせて活用します。このエージェント型のワークフローは、複雑なビジネスプロセスを分析および抽出することで、レガシーコードを明確なビジネス仕様へと変換します。

エージェント型ハーネスとして Antigravity と組み合わせることで、このソリューションは、安全で AI 加速型の開発パイプラインを提供します。このパイプラインでは、メインフレームからのビジネスルール抽出、ターゲットアプリケーション仕様の作成、ターゲットアーキテクチャ設計の作成、ユーザーストーリーとバックログの生成、さらにはエージェントによるコーディング実装計画の作成など、あらゆるステップでオプションの人間参加型ガバナンスを備えています。

これにより、エンジニアリングチームは複雑なロジックを実装の詳細から切り離し、従来のメインフレームの「ブラックボックス」を、透明性が高く、保守が容易で、優れた進化性を備えたクラウドネイティブアプリケーションへと置き換えることができます。

エージェント型のモダナイゼーションワークフローを確立するために連携する Google Mainframe Modernization ソリューション

決定論的なモダナイゼーション（同等移行）

このパターンは、レガシーアプリケーションの動作を厳密に維持しながら、構造的なモダナイゼーションを必要とするユースケース向けに設計されています。Google は、厳格なコントラクトの忠実性を基本原則とする制約として、内部アプリケーション構造をコードからコードへ直接モダナイズするために AI を使用しています。モダナイズされたシステムには、外部インターフェースを維持したまま技術的負債を解消し、どのような入力に対してもレガシーシステムとまったく同じビジネス結果を出すことが求められます。

ワークロードに応じたパターンの適用

これら 2 つのパターンによるモダナイゼーションは、実際にはどのようなものなのでしょうか。金融サービス業界のお客様が、自社のシステム環境全体にわたって混合アプローチを適用しているケースを想定してみましょう。安定した大量のバックオフィスバッチジョブ（夜間の明細書処理など）を同等移行のパスでモダナイズすれば、リスクを抑え、短期間で MIPS 消費量を削減することが可能です。たとえば、基幹システムである総勘定元帳に決定論的 AI モダナイゼーションを採用し、規制遵守のロジックを維持したまま、データ構造を Google Cloud SQL へとモダナイズして分析機能を向上させる、といった選択も考えられます最後に、顧客向けのローン組成プラットフォームなど、競争上の差別化要因となるアプリケーションについては、AI による書き換え戦略を導入し、Gemini を使用してアプリケーションを書き換えてリアルタイムの承認を実現することで、ビジネスにおける真の優位性を確立できます。

3. セーフティネット: 本番稼働前のリスク軽減

本番稼働のリスクを排除するために、Google Cloud の Dual Run は、メインフレームと新しい Google Cloud 環境の両方で、実際の運用ワークロードを同時に処理します。メインフレームのライブトランザクションを自動的にキャプチャし、モダナイズされたアプリケーションに対して実行して、出力を並べて比較します（プロトコル、メッセージ、データの変更内容など）。この継続的検証は、ロジックとデータの完全な同等性が達成されるまで実行されます。これにより、メインフレーム上のレガシーアプリケーションを廃止する前に、安全性を確保し、運用の中断をゼロにすることを保証します。グローバル企業はすでに Dual Run を使用して移行リスクを排除しており、特定の業界でモダナイゼーションに必要とされる厳格な規制当局の承認までも確保しています。Dual Run は、メインフレームのモダナイゼーションを成功させるための、本番環境グレードの「保険」のような存在です。

4. データ移行: サイロ化されたメインフレームデータのモダナイズ

最後に、Google Cloud Mainframe Connector を使用すると、メインフレームからデータを取り出し、BigQuery、Spanner、Cloud SQL、Cloud Storage などのさまざまな Google Cloud サービスにコピーできます。Mainframe Connector は、コードベースやデータ型の変換を処理します。既存の ETL プロセスに簡単に統合できるため、メインフレームから Google Cloud へと反復的にデータをコピーすることが可能です。Mainframe Connector を活用することで、メインフレームから処理をオフロードし、拡張モダナイゼーションパターンと分析 / データウェアハウジングの両方をサポートできるようになります。MIPS の使用量を削減しながら、サイロ化されたメインフレームデータを解放し、クラウド上で新しいビジネス機能を創出できるようになります。

これら 4 つのソリューションを組み合わせることで、目的を絞った応用 AI が、メインフレームのお客様が直面する実際のモダナイゼーションの課題（既存のビジネスプロセスの理解、アプリケーションのモダナイズ、本番環境への移行前のリスク軽減、サイロ化されたデータのモダナイズ）をどのように解決できるかを実証しています。

ぜひお試しを

メインフレームのモダナイゼーションは、確信が持てないまま進めるべきではありません。不確実な状況から実行へと貴社を導くために設計された、対象を絞ったパイロットプログラムを通じて、AI 加速型の Google のアプローチをぜひお確かめください。

まずは、以下のステップから始めましょう。

自動コードベース評価: ターゲットアプリケーションで Mainframe Assessment Tool スキャンを実行して、隠れた依存関係をマッピングし、ドメインアーキテクチャを可視化します。また、ビジネスルールを平易な言葉でレガシーコードから直接抽出します。
エージェント型モダナイゼーションワークショップとパイロット: Google Cloud のエキスパートや専門パートナーとハンズオンで協力し、エージェント型のワークフローを実社会で適用して、メインフレームモダナイゼーションの課題を解決する能力を実証します。共にモダナイズするアプリケーションを 1 つ選び、モダナイゼーションのビジネスケースを構築しましょう。

ご関心をお持ちの場合は、mainframe@google.com までお問い合わせください。

- AI アプリケーションモダナイゼーション担当グループプロダクトマネージャー、David Yahalom

AI & 機械学習

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 を使ってみる

金融サービスにおけるエージェント型 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 の主な構成要素:

提供時期

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

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

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

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

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

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

AI を支えるインフラ

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

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

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

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

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

まとめ

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

仕組み

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

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

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

#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 でグラフインテリジェンスを民主化

Gemini Enterprise データを Looker のセマンティックレイヤで制御してユーザーの信頼を確保

優れたビジュアルインタラクティビティ: グラフのサポート

ファーストパーティおよびサードパーティエージェントとの相互運用性

WPP が AI マーケティングのためにプラットフォームとデータエンジニアリングを運用化

エンタープライズソフトウェアライフサイクルの標準化

セキュリティとインテリジェントネットワーキングの自動化

ビジョン: ユニバーサルインターフェースとしての API

Spanner Graph でエンタープライズオントロジーを構築

New Way Now: Mars、Gemini Enterprise でマーケティングキャンペーンを数か月から数週間に短縮

New Way Now: TELUS、Agentic Data Cloud を構築し、接続性をカスタマーインテリジェンスへと変革

AI を活用した現実のメインフレームモダナイゼーション: メインフレームからクラウドへの安全でスケーラブルな道筋

1. 評価: レガシーアプリケーションの AI リバースエンジニアリング

3. セーフティネット: 本番稼働前のリスク軽減

4. データ移行: サイロ化されたメインフレームデータのモダナイズ