Cloud Blog JA

ID.me、1 億 6,000 万ユーザーに対応するスケーリングと運用リスクの軽減を同時に達成

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

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

編集者注: ID.me は、デジタル ID のセキュリティを変革することで、ID の確立が容易であることを証明しています。さらに、同社のプラットフォームは 1 億 6,000 万人の会員に対応できるようスケールされ、1 分あたり最大 40,000 人のユーザーへの対応が可能となっています。圧倒的な規模とリアルタイム AI を必要とする税務申告などのサービスに対応するために、同社のチームは 50 テラバイトのデータを従来のプラットフォームから Google Cloud に移行し、AlloyDB、Cloud SQL、Vertex AI を基盤とする最新のアーキテクチャを採用しました。このアーキテクチャにより、開発の迅速化、不正行為の検出精度の向上、データチーム全体の作業完了時間の 40% 短縮が実現しました。

皆さん、家を出るときは、スマートフォン、運転免許証、クレジットカードなど、必ずなんらかの身分証明書を携帯するでしょう。それによって自分の身元を証明できますし、ほぼどこでも利用できます。しかし、オンラインでは、何度も本人確認を求められ、新しいサービスやツールを使い始めるたびに、新しいログイン情報を作成する必要があります。ID.me は、ユーザーが本人確認を一度だけ安全に行い、その認証情報をオンラインのどこでも使用できるようにすべきだと考えています。

当社の目標は、公的機関と民間企業の両方で信頼性の高いログイン方法として機能する、ID 用のデジタルウォレットを開発することです。当社は現在、1 億 6,000 万人以上の会員にサービスを提供しており、私たちの生活や仕事において ID の重要性が高まっています。このため当社は、対面で運転免許証を提示する場合と同じくらい簡単に、オンラインで本人であることを証明できるよう規模を拡張しています。

追いつかないスピードで増える需要

ID.me の以前の会員数は 5,000 万人でしたが、この数年間で 1 億 6,000 万人以上という規模まで成長しました。現在は 1 日単位での使用状況のトラッキングは行わず、代わりにほぼリアルタイムのモニタリングを行っています。現時点で、当社のプラットフォームは 1 分あたり最大 40,000 人の会員に対応できるように設計されています。この種の需要は予測できません。ID.me の会員にとって、アクセスがすべてです。稼働時間だけでなく、政府の給付金、医療、限定特典などに関して、会員が必要とする場合に、安全かつ即座に本人確認を行えることが重要です。そしてユーザー数が拡大する中、当社のインフラストラクチャを必要な形でスケールできていないことがわかりました。アーキテクチャの限界に達しつつあったため、当社はある決断を下しました。ID.me のデータ基盤を Google Cloud 上で再構築して、次の成長段階に備えることにしたのです。

1 億 6,000 万人の大切なお客様と当社のための新しいデータベース

最初の作業は、当社が必要としていた圧倒的なスケーラビリティと信頼性を実際に提供できるデータベースを選択することでした。すぐに目に留まったのが AlloyDB for PostgreSQL でした。以前の環境で直面していたスケーリングのボトルネックと運用上の複雑さに直接対処するソリューションであったため、ピーク時の需要にも自信を持って対応できるようになりました。この移行によって、技術的な課題を解決できただけでなく、開発者のエクスペリエンスが劇的に向上しました。チームがプロビジョニング、メンテナンス、パッチ適用に費やす時間が大幅に減り、開発サイクルが数週間からわずか数日に短縮されました。

過去 2 年間で、15 個のデータベースインスタンスに分散されていた 50 テラバイト以上のデータを Google Cloud に移行しました。しかも、ダウンタイムは最小限で済みました。また、2 階層アーキテクチャも導入しました。Cloud SQL がより小規模かつ標準的なサービスをサポートし、AlloyDB が ID.me プラットフォームのバックボーンを形成するより負荷の高いワークロードを実行します。これにより、安定性を損なうことなく迅速に処理を進めることができます。また、チームに余裕が生まれ、実際にイノベーションを推進する作業に集中できています。たとえば、当社の ID に対する取り組みに逆行するのではなく、確実に役立つ AI の開発などです。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud データベースでよりスマートに構築'), ('body', <wagtail.rich_text.RichText object at 0x7f9a886ce250>), ('btn_text', ''), ('href', ''), ('image', None)])]>

AI トレーニングの目的は . . . AI との戦い？

あらゆる組織が AI を活用しようと躍起になっています。しかし ID.me では、その不正使用を防ぐことも同じくらい重要です。脅威の状況は進化しており、特に生成モデルは、個人になりすます能力だけでなく、合成 ID を作成する能力も高めています。ユーザーが名乗ったとおりの人物であることを確認することをビジネスとしている当社にとって、この脅威は大きな問題です。

AlloyDB の優れた点の一つは、複数の読み取りプールを作成できることです。当社では、これらの読み取りプールを、データエンジニアやデータサイエンティストと迅速に共有できるデータクリーンルームとしています。不正行為分析担当者がそこに入り、問題を発見して、リアルタイムで修正または防止できます。

全体で見ると、AlloyDB AI のおかげで従来のシステムを 10～20 倍にスケールし、さらに料金も下げることができました。その効果は非常に大きいものです。ID.me は、米国連邦政府から、国家システム内での大規模な不正行為を防止する役割を担っていると認められています。この成功の重要な要因となったのは、AlloyDB に組み込まれた高可用性と、スケーリングが容易な読み取りプールです。これにより、米国の国家税務当局である Internal Revenue Service（IRS）は、前回の納税申告のピーク時に、1 秒あたり 120,000 件を超えるトランザクションを滞りなくシームレスに処理できました。これは実質的に、以前のセルフホスト型 PostgreSQL のパフォーマンスの 2 倍に相当します。

多くの新機能を試してきましたが、特に期待しているのは Gemini Enterprise と AlloyDB AI の自然言語です。これにより、当社の AI の構築と操作の方法に根本的な変化がもたらされるからです。

1 つのログインであらゆるシステムにスムーズに対応

当社のデータチームは Google Cloud を大いに活用しており、作業が大幅に楽になりました。移行後は、変更をはるかに迅速に行えるようになり、全体の作業完了時間が 40% 短縮されました。ID.me のエンジニアリングチームでは、開発者のエクスペリエンスが劇的に向上しました。チームが製品の機能全体をリリースするまでに要する期間が数週間から数日に短縮し、当社の会員にとって重要な問題の解決に時間を費やせるようになりました。

インフラストラクチャのスケーリングと信頼の拡大を同時に達成できました。ポータブル ID を圧倒的な規模で処理できるように構築された、より高速でスマートなプラットフォームにより、当社は目標達成に一歩近づきました。それは、必要なときに必要な場所で、デジタルによる安全な方法で本人確認を行うことができるソリューションです。子どもの頃に飼っていたペットに関するセキュリティ保護用の質問は、もうなくなるかもしれません。

詳細:

AlloyDB と AlloyDB AI の機能の詳細をご確認ください。
AlloyDB の無料トライアルを今すぐ開始しましょう。
AlloyDB を活用してビジネスを変革している Bayer や Character.ai などのお客様の事例をご覧ください。

- ID.me、クラウドプラットフォームアーキテクト Kevin Liu 氏

Google ADK、MCP、Cloud Run を使用して専門家向けコンテンツ用のマルチエージェントシステムを構築する - パート 1

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

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

私のチームのミッションは、コードの作成から Google Cloud で安全な AI ワークロードを実行するまで、デベロッパーの取り組みを加速させることです。デベロッパーの成功を支援するため、Google はデベロッパーが最も切実に求めている質問を特定し、簡単に実装できるわかりやすいソリューションを提供するデモを構築することに重点を置いています。

最近、新しい Developer Knowledge MCP サーバーがリリースされたとき、私にはひらめきが湧きました。そこで、Google Agent Development Kit（ADK）を使用して設計されたマルチエージェントシステムである Dev Signal を構築し、Reddit から技術的な質問を特定し、公式ドキュメントを使用して調査し、詳細な技術ブログ記事の下書きを作成しました。Dev Signal には、Nano Banana Pro を使用したカスタムビジュアルも備わっています。エージェントが私の好みのスタイルやブログ記事の書き方を記憶できるように、長期記憶レイヤも統合しました。

コーディングアシスタントである Gemini CLI をデベロッパーナレッジ MCP サーバーに接続することで、このシステム全体をわずか 2 日で構築して Google Cloud Run にデプロイしました。

ここでは、長期記憶を備えた複雑なマルチエージェントシステムを設計する方法、ローカルおよびリモートの MCP サーバーを利用してツールを標準化する方法、安全な Cloud Run デプロイのための詳細な Terraform スクリプトを作成する方法など、さまざまな方法をご紹介します。

今すぐコードを見てご自分のペースで調べる場合は、こちらからリポジトリをクローニングできます。

学習内容

4 回に分けてお届けするこのブログシリーズでは、このプロジェクトをどのように実現したのか、その手順を段階的にご紹介します。各ブログ投稿では、Dev Signal の構築とデプロイの過程を説明します。

パート 1: エージェント機能を構築するためのツール – まず、プロジェクト環境をセットアップし、Model Context Protocol（MCP）を使用してエージェントにツールを装備します。トレンドの発見に Reddit を、技術的なグラウンディングに Google Cloud ドキュメントを、画像生成にカスタム Nano Banana Pro ツールを使用する方法を学びます。
パート 2: 長期記憶を備えたマルチエージェントアーキテクチャ – ルートオーケストレーターと専門エージェントチームを実装して、システムの「頭脳」を構築します。また、Vertex AI Memory Bank を統合することで、エージェントがセッション全体でユーザーの好みを学習して保持できるようになります。
パート 3: エージェントをローカルでテストする – クラウドに移行する前に、エージェントのコンポーネントを同期し、ワークステーションでエージェントのパフォーマンスを検証します。専用のテストランナーを使用して、検出、調査、マルチモーダル作成のライフサイクル全体をシミュレートします。特に、ローカルエージェントをクラウドベースの Vertex AI Memory Bank に直接接続して、長期記憶の永続性を検証することに重点を置きます。
パート 4: Cloud Run へのデプロイと本番環境への移行 – 最後に、再現可能なインフラストラクチャを実現するため、Terraform を使用して Google Cloud Run にサービスをデプロイします。また、高品質で安全な本番環境システムに必要な次のステップについても説明します。

Dev Signal の概要

Dev Signal は、ノイズをフィルタして価値を生み出すように設計されたインテリジェントなモニタリングエージェントです。Dev Signal は次のように動作します。

発見: Reddit を調査して、エンゲージメントの高い技術的な質問を見つけます。
グラウンディング: 正確性を確保するために、Google Cloud の公式ドキュメントを使用して回答を調査します。
作成: 調査結果に基づいて、プロフェッショナルな技術ブログ投稿の下書きを作成します。
マルチモーダル生成: これらの投稿のカスタムインフォグラフィックヘッダーを生成します。
長期記憶: Vertex AI Memory Bank を使用して、さまざまなセッションにわたってフィードバックを記憶します。

前提条件

始める前に、以下がインストールされていることを確認してください。

Python 3.12 以降

uv（Python パッケージ管理システム）: curl -LsSf https://astral.sh/uv/install.sh | sh
Google Cloud SDK（gcloud CLI）（インストールおよび認証済み）
Terraform（Iinfrastructure as Code 用）
Node.js と npm（Reddit MCP ツールに必要）

次も必要です。

課金を有効にした Google Cloud プロジェクト。
有効な API: Vertex AI、Cloud Run、Secret Manager、Artifact Registry。
Reddit API 認証情報（クライアント ID、シークレット）- Reddit デベロッパーポータルから入手できます。
Developer Knowledge API Key（Google Cloud ドキュメント検索用）- 入手方法については、こちらをご覧ください。

プロジェクトのセットアップ

Dev Signal システムは、Remigiusz Samborski 氏と Vlad Kolesnikov 氏による Agent Factory のエピソードで説明されている自動化されたアーキテクトワークフローに従って、まず Agent Starter Pack を実行して構築されました。この基盤により、エージェントロジック、サーバーコード、ユーティリティ、ツール間の関心を分離するために使用される、プロジェクトのモジュール式ディレクトリ構造が用意されました。

Starter Pack は、プロフェッショナルなインフラストラクチャ、CI / CD パイプライン、オブザーバビリティツールの作成を数秒で自動化するため、強力な出発点となります。これにより、基盤となるプラットフォームのセキュリティとスケーラビリティを確保しながら、エージェント独自のインテリジェンスに十分集中できるようになります。Gemini CLI と Antigravity の AI アシスタンスを使用して、生成されたボイラープレートを基に構築することで、開発プロセスが大幅に加速されます。

Agent Starter Pack のアーキテクチャの概要:

1. プロジェクトを初期化する

プロジェクト用の新しいディレクトリを作成し、初期化します。ここでは、非常に高速な Python パッケージ管理システムである uv を使用します。

code_block: <ListValue: [StructValue([('code', 'uv init dev-signal'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9a984cfd00>)])]>

2. フォルダ構造

このプロジェクトは次の構造に従います。これらのファイルにデータを段階的に入力していきます。

code_block: <ListValue: [StructValue([('code', 'dev-signal/\r\n├── dev_signal_agent/\r\n│ ├── __init__.py\r\n│ ├── agent.py # Agent logic & orchestration\r\n│ ├── fast_api_app.py # Application server & memory connection\r\n│ ├── app_utils/ # Env Config\r\n│ │ └── env.py\r\n│ └── tools/ # External capabilities\r\n│ ├── __init__.py\r\n│ ├── mcp_config.py # Tool configuration (Reddit, Docs)\r\n│ └── nano_banana_mcp/# Custom local image generation tool\r\n│ ├── __init__.py\r\n│ ├── main.py\r\n│ ├── nano_banana_pro.py\r\n│ ├── media_models.py\r\n│ ├── storage_utils.py\r\n│ └── requirements.txt\r\n├── deployment/\r\n│ └── terraform/ # Infrastructure as Code\r\n├── .env # Local secrets (API keys)\r\n├── Makefile # Shortcuts for building/deploying\r\n├── Dockerfile # Container definition\r\n└── pyproject.toml # Dependencies'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9a984cf610>)])]>

3. 依存関係を定義する

必要な依存関係を使用して pyproject.toml を更新します。エージェントフレームワークには google-adk を、モデルのインタラクションには google-genai を使用します。

code_block: <ListValue: [StructValue([('code', '[project]\r\nname = "dev-signal"\r\nversion = "0.1.0"\r\ndescription = "A multi-agent system for monitoring and content creation."\r\nreadme = "README.md"\r\nrequires-python = ">=3.12, <3.14"\r\ndependencies = [\r\n "google-adk>=0.1.0",\r\n \xa0"google-genai>=1.0.0",\r\n "mcp>=1.0.0",\r\n \xa0"python-dotenv>=1.0.0",\r\n "fastapi>=0.110.0",\r\n "uvicorn>=0.29.0",\r\n "google-cloud-logging>=3.0.0",\r\n "google-cloud-aiplatform>=1.38.0",\r\n \xa0"fastmcp>=2.13.0",\r\n "google-cloud-storage>=3.6.0",\r\n "google-auth>=2.0.0",\r\n "google-cloud-secret-manager>=2.26.0",\r\n]'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9a984cfbe0>)])]>

uv sync を実行してすべてインストールします。

エージェントコード用の新しいディレクトリを作成します。

code_block: <ListValue: [StructValue([('code', 'mkdir dev_signal_agent\r\ncd dev_signal_agent'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9a984cf130>)])]>

エージェント機能の構築: MCP ツール

エージェントは外部とやり取りする必要があります。これを標準化するために、Model Context Protocol（MCP）を使用します。Model Context Protocol（MCP）は、AI エージェントを外部のデータやツールに接続するための普遍的な基準です。カスタム API ラッパーを記述する代わりに、標準の MCP サーバーを使用します。これにより、共通のインターフェースを使用して、API（Reddit）、ナレッジベース（Google Cloud ドキュメント）、さらにはローカルスクリプト（Nano Banana Pro を使用した画像生成）にも接続できます。エージェントツール用の新しいディレクトリを作成します。

code_block: <ListValue: [StructValue([('code', 'mkdir tools\r\ncd tools'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9a984cf760>)])]>

ツールの構成

ツールセットは dev_signal_agent/tools/mcp_config.py で定義します。

このファイルでは、3 つの主要なツールの接続パラメータを定義します。

Reddit: ローカル stdio サブプロセス経由で接続されます。
デベロッパーナレッジ: リモート HTTP エンドポイント経由で接続されます。
Nano Banana: ローカル stdio サブプロセス（Google のカスタム Python スクリプト）経由で接続されます。

Reddit 検索（発見ツール）

Reddit MCP サーバーは Reddit API へのブリッジとして機能し、複雑な API ラッパーを記述しなくても、トレンドとなっている投稿をエージェントが発見してエンゲージメントを分析できるようにします。移植性を確保するために、コードでは「検索またはフェッチ」戦略が使用されています。まずローカルインストールをチェックし、見つからない場合は npx を使用してサーバーをオンデマンドでダウンロードして実行します。

ネットワーク接続の代わりに、エージェントはサーバーをローカルサブプロセスとして起動し、標準入出力（stdio）を介して通信します。Google ADK 内の McpToolset クラスは、これらの接続を標準化する普遍的なラッパーとして機能し、エージェントが共通のインターフェースを使用して、コミュニティリソースからカスタムスクリプト（Nano Banana 画像生成ツールなど）まで、さまざまなツールとやり取りできるようにします。環境変数を介して API 認証情報を安全に渡すことで、システムはこれらの「プラグアンドプレイ」モジュールが AI と外部プラットフォーム間のシームレスなブリッジとして機能することを保証します。

次のコードを dev_signal_agent/tools/mcp_config.py に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'import os\r\nimport shutil\r\nfrom mcp import StdioServerParameters\r\nfrom google.adk.tools import McpToolset\r\nfrom google.adk.tools.mcp_tool import StreamableHTTPConnectionParams, StdioConnectionParams\r\n\r\ndef get_reddit_mcp_toolset(client_id: str = "", client_secret: str = "", user_agent: str = ""):\r\n """\r\n Connects to the Reddit MCP server.\r\n This server runs as a local subprocess (stdio) and proxies requests to the Reddit API.\r\n """\r\n # Check if \'reddit-mcp\' is installed globally, otherwise use npx to run it\r\n cmd = "reddit-mcp" if shutil.which("reddit-mcp") else "npx"\r\n args = [] if shutil.which("reddit-mcp") else ["-y", "--quiet", "reddit-mcp"]\r\n \r\n # Inject secrets into the environment of the subprocess only\r\n env = {\r\n **os.environ, \r\n "DOTENV_CONFIG_SILENT": "true", \r\n "LANG": "en_US.UTF-8"\r\n }\r\n\r\n if client_id: env["REDDIT_CLIENT_ID"] = client_id\r\n if client_secret: env["REDDIT_CLIENT_SECRET"] = client_secret\r\n if user_agent: env["REDDIT_USER_AGENT"] = user_agent\r\n\r\n return McpToolset(\r\n connection_params=StdioConnectionParams(\r\n server_params=StdioServerParameters(\r\n command=cmd, \r\n args=args, \r\n env=env # Pass injected secrets directly to the subprocess\r\n ),\r\n timeout=120.0\r\n )\r\n )'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f9a984cf460>)])]>

Google Cloud ドキュメント（ナレッジツール）

Developer Knowledge MCP サーバーは、エージェントが Google Cloud の公式ドキュメントのコーパス全体を検索できるようにすることで、エージェントのグラウンディングを提供します。これは、ローカルの Reddit サーバーとは異なり、Google がホストするマネージドサービスであり、インターネット経由でリモートエンドポイントとしてアクセスされます。セマンティッククエリ用の google_developer_documentation_search や、完全なマークダウンコンテンツを取得するための google_developer_documentation_fetch などの特殊なツールが公開されており、エージェントが技術的な主張を行うたびに、最新の確かな事実によって裏付けられるようになっています。

注: Gemini CLI や Antigravity などのコーディングアシスタントツールをデベロッパーナレッジ MCP サーバーに接続して、最新の便利な Google Cloud ドキュメントをアシスタントに提供することもできます。このブログ記事を書くときも使っています。

接続するために、エージェントは McpToolset クラスと StreamableHTTPConnectionParams を使用し、ローカルプロセスを起動する代わりにウェブ URL を指定します。リクエストヘッダーで渡される DK_API_KEY（API キーを作成）を使用して安全に認証し、エージェントが単一の標準化されたインターフェースを通じて、公式ドキュメント、コミュニティの感情、より広範なウェブコンテキスト全体で「包括的な調査スイープ」を実行できるようにします。

次のコードを dev_signal_agent/tools/mcp_config.py に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'def get_dk_mcp_toolset(api_key: str = ""):\r\n """\r\n Connects to Developer Knowledge (Google Cloud Docs).\r\n This is a remote MCP server accessed via HTTP.\r\n """\r\n headers = {}\r\n if api_key:\r\n headers["X-Goog-Api-Key"] = api_key\r\n else:\r\n # Fallback to os.environ for local testing if not passed via API\r\n headers["X-Goog-Api-Key"] = os.getenv("DK_API_KEY", "")\r\n\r\n return McpToolset(\r\n connection_params=StreamableHTTPConnectionParams(\r\n url="https://developerknowledge.googleapis.com/mcp",\r\n headers=headers\r\n )\r\n )'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f9a984cf190>)])]>

画像生成ツール（Nano Banana MCP）

Reddit とドキュメントには外部 MCP サーバーを使用しましたが、特定の Python ロジックをラップする独自のカスタム MCP サーバーを構築することもできます。この例では、Gemini 3 Pro Image（Nano Banana Pro とも呼ばれます）を搭載した画像生成ツールを作成します。これは、任意の Python 関数を、任意のエージェントが理解できるツールに標準化できることを示しています。

画像生成の仕組み:

FastMCP: fastmcp ライブラリを使用してサーバーの作成を大幅に簡素化し、数行のコードで Python 関数をツールとして登録できるようにします。
Gemini のインテグレーション: サーバーは Google GenAI SDK を使用して gemini-3-pro-image-preview モデルを呼び出し、エージェントの説明的なプロンプトを未加工の画像バイトに変換します。
GCS へのアップロードとホスティング: エージェントインターフェースでは通常、画像を表示するために URL が必要となるため、サーバーは生成されたバイトを Google Cloud Storage（GCS）に自動的にアップロードし、公開リンクを返します。

このローカルツールを接続するには、StdioConnectionParams を使用します。これは、サーバーが標準入出力を介して通信するローカルサブプロセスとして実行されるためです。この転送方法は、サーバーのエントリポイントで定義する transport="stdio" 構成に直接一致し、カスタムのローカルスクリプトのシームレスな接続を保証します。

次のコードは、dev_signal_agent/tools/mcp_config.py で MCP 接続を定義します。uv run を使用して、すべての依存関係が正しくインストールされている、隔離された環境でサーバーが起動するようにします。

次のコードを dev_signal_agent/tools/mcp_config.py に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'def get_nano_banana_mcp_toolset():\r\n """\r\n Connects to our local \'Nano Banana\' image generator.\r\n This demonstrates how to wrap a local Python script as an MCP tool.\r\n """\r\n path = os.path.join("dev_signal_agent", "tools", "nano_banana_mcp", "main.py")\r\n bucket = os.getenv("AI_ASSETS_BUCKET") \r\n return McpToolset(\r\n connection_params=StdioConnectionParams(\r\n server_params=StdioServerParameters(\r\n command="uv", \r\n args=["run", path], \r\n env={**os.environ, "AI_ASSETS_BUCKET": bucket}\r\n ),\r\n timeout=600.0 # Image generation can take time\r\n )\r\n )'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f9a984cfc10>)])]>

Nano Banana Pro サーバーロジックの実装

次に、このサーバーの実際のロジックを実装します。この実装は、Remigiusz Samborski 氏による Agent Factory デモのコードに基づいています。Remi の元のコードには、MCP サーバーを Cloud Run にデプロイする手順が記載されていますが、ここでは開発とテストを迅速に行うために、ローカルサブプロセスとして実行します。

まず、新しいサーバー用のディレクトリを作成します。

code_block: <ListValue: [StructValue([('code', 'mkdir -p dev_signal_agent/tools/nano_banana_mcp\r\ncd dev_signal_agent/tools/nano_banana_mcp'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9a984cfac0>)])]>

サーバーエントリポイント（`main.py`）

このファイルは、MCP サーバーを初期化して起動する「頭脳」として機能します。

FastMCP の初期化: FastMCP ライブラリを使用して、「MediaGenerators」という名前のサーバーを作成し、generate_image 関数をツールとして登録します。
安全なロギング: _initialize_console_logging 関数が重要な役割を果たします。この関数はすべてのログを sys.stderr に強制的に出力します。これは、MCP の「stdio」転送がエージェントとツールの間の通信に sys.stdout を使用するためです。stdout に送信される標準ログは、そのプロトコルを破損させます。
実行: mcp.run(transport="stdio") 行は、サーバーをローカルサブプロセスとして起動し、標準入力経由でエージェントからのリクエストをリッスンできるようにします。

次のコードを dev_signal_agent/tools/nano_banana_mcp/main.py に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'import logging\r\nimport os\r\nimport sys\r\nfrom fastmcp import FastMCP\r\nfrom dotenv import load_dotenv\r\nfrom nano_banana_pro import generate_image\r\n\r\ndef _initialize_console_logging(min_level: int = logging.INFO):\r\n # Ensure logs go to STDERR so they don\'t break the MCP stdio protocol\r\n handler = logging.StreamHandler(sys.stderr)\r\n logging.basicConfig(level=min_level, handlers=[handler], force=True)\r\n\r\ntools = [generate_image]\r\nmcp = FastMCP(name="MediaGenerators", tools=tools)\r\n\r\nif __name__ == "__main__":\r\n load_dotenv()\r\n _initialize_console_logging()\r\n mcp.run(transport="stdio")'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f9a984cf700>)])]>

生成ロジック（`nano_banana_pro.py）`

ここでは、Gemini を使用して実際に画像が生成されます。

GenAI クライアント: Google の生成モデルとやり取りするために、genai.Client() を初期化します。
モデルの選択: 具体的には gemini-3-pro-image-preview モデルを対象とします。response_modalities を「IMAGE」に設定して、テキストだけでなくピクセルも必要であることをモデルに伝えます。
堅牢性: コードには、一時的な生成エラーを処理するための MAX_RETRIES ループ（5 に設定）が含まれており、エージェントが有効な画像を複数回取得できるようにしています。
バイト処理: モデルが画像を生成すると、未加工のインラインデータとして届きます。これらのバイトを抽出し、ヘルパーを呼び出してクラウドに移動します。
URI 変換: 最後に、内部の gs:// パスを、ブラウザからアクセス可能な https:// URL に置き換え、ユーザーが実際に画像を見られるようにします。

次のコードを dev_signal_agent/tools/nano_banana_mcp/nano_banana_pro.py に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'import logging\r\nfrom typing import Literal, Optional\r\nfrom google import genai\r\nfrom google.genai import types\r\nfrom media_models import MediaAsset\r\nfrom storage_utils import upload_data_to_gcs\r\n\r\nAUTHORIZED_URI = "https://storage.mtls.cloud.google.com/"\r\nMAX_RETRIES = 5\r\n\r\nasync def generate_image(\r\n prompt: str,\r\n aspect_ratio: Literal["16:9", "9:16"] = "16:9",\r\n) -> MediaAsset:\r\n """Generates an image using Gemini 3 Image model."""\r\n genai_client = genai.Client()\r\n content = types.Content(parts=[types.Part.from_text(text=prompt)], role="user")\r\n \r\n logging.info(f"Starting image generation for prompt: {prompt[:50]}...")\r\n asset = MediaAsset(uri="")\r\n \r\n for _ in range(MAX_RETRIES):\r\n response = genai_client.models.generate_content(\r\n model="gemini-3-pro-image-preview",\r\n contents=[content],\r\n config=types.GenerateContentConfig(\r\n response_modalities=["IMAGE"],\r\n image_config=types.ImageConfig(aspect_ratio=aspect_ratio)\r\n )\r\n )\r\n if response and response.parts:\r\n for part in response.parts:\r\n if part.inline_data and part.inline_data.data:\r\n # Upload the raw bytes to GCS\r\n gcs_uri = await upload_data_to_gcs(\r\n "mcp-tools",\r\n part.inline_data.data,\r\n part.inline_data.mime_type\r\n )\r\n asset = MediaAsset(uri=gcs_uri)\r\n break\r\n if asset.uri: break\r\n\r\n if not asset.uri:\r\n asset.error = "No image was generated."\r\n else:\r\n # Convert gs:// URI to an HTTP accessible URL if needed\r\n asset.uri = asset.uri.replace(\'gs://\', AUTHORIZED_URI)\r\n logging.info(f"Image URL: {asset.uri}")\r\n \r\n return asset'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f9a984cf6a0>)])]>

GCS アップロードヘルパー（`storage_utils.py）`

エージェントは画像を表示するためにリンクを必要とするため、このユーティリティは Google Cloud Storage（GCS）でホスティングを処理します。

バケットの動的な選択: 環境変数でバケット名を探し、AI_ASSETS_BUCKET から LOGS_BUCKET_NAME にフォールバックして、データの保存場所が常に確保されるようにします。
一意のファイル名: 未加工の画像データの MD5 ハッシュを使用して、一意のファイル名を作成します。これにより、ファイル名の競合を防ぐことができ、同じ画像の重複アップロードを回避する簡単な方法として機能します。
クラウドアップロード: blob.upload_from_string メソッドは、未加工の画像バイトを GCS バケットに直接 push します。

次のコードを dev_signal_agent/tools/nano_banana_mcp/storage_utils.py に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'import hashlib\r\nimport mimetypes\r\nimport os\r\nfrom google.cloud.storage import Client, Blob\r\nfrom dotenv import load_dotenv\r\n\r\nload_dotenv()\r\nstorage_client = Client()\r\nai_bucket_name = os.environ.get("AI_ASSETS_BUCKET") or os.environ.get("LOGS_BUCKET_NAME")\r\nai_bucket = storage_client.bucket(ai_bucket_name)\r\n\r\nasync def upload_data_to_gcs(agent_id: str, data: bytes, mime_type: str) -> str:\r\n file_name = hashlib.md5(data).hexdigest()\r\n ext = mimetypes.guess_extension(mime_type) or ""\r\n blob_name = f"assets/{agent_id}/{file_name}{ext}"\r\n blob = Blob(bucket=ai_bucket, name=blob_name)\r\n blob.upload_from_string(data, content_type=mime_type, client=storage_client)\r\n return f"gs://{ai_bucket_name}/{blob_name}"'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f9a88382d30>)])]>

データモデル（`media_models.py`）

このファイルにより、データが厳格な構造（スキーマ）に従うことが保証されます。

構造化された出力: Pydantic BaseModel を使用することで、ツールが常に uri（リンク）とオプションの error メッセージを含む一貫した JSON オブジェクトを返すことを保証します。これにより、AI エージェントがツールの結果を理解して処理することがはるかに容易になります。

次のコードを dev_signal_agent/tools/nano_banana_mcp/media_models.py に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'from typing import Optional\r\nfrom pydantic import BaseModel\r\n\r\nclass MediaAsset(BaseModel):\r\n uri: str\r\n error: Optional[str] = None'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f9a88382a90>)])]>

ツールの依存関係（`requirements.txt）`

コードの実行には uv を使用しますが、requirements.txt ファイルは、Nano Banana サーバーが機能するために uv がインストールする必要がある特定の依存関係を定義するため、依然として不可欠です。これにより、隔離された環境をサーバーの起動前にセットアップするために必要な「材料」が提供されます。

このファイルには、このツールに必要な 3 つのコアライブラリがリストされています。

google-cloud-storage: 生成された画像をクラウドでホストするために使用されます。
google-genai: Gemini 3 Pro の画像生成のロジックを提供します。
fastmcp: Python スクリプトを標準化された MCP ツールに変えるフレームワークです。

次のコードを dev_signal_agent/tools/nano_banana_mcp/requirements.txt に貼り付けます。

code_block: <ListValue: [StructValue([('code', 'google-cloud-storage==3.6.*\r\ngoogle-genai==1.52.*\r\nfastmcp==2.13.*'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9a883820d0>)])]>

まとめ

シリーズのパート 1 では、Model Context Protocol（MCP）を通じて外部統合を標準化することにより、エージェントのコア機能を確立することに焦点を当てました。高速な依存関係管理のために uv を使用してプロジェクトを初期化し、トレンド発見のための Reddit、技術的なグラウンディングのための Google Cloud ドキュメント、マルチモーダル画像生成のためのカスタム「Nano Banana」MCP サーバーという 3 つの重要なツールセットを構成しました。Google ADK の McpToolset を利用することで、複雑な API ロジックをシンプルなプラグアンドプレイモジュールに抽象化し、ツールが共通のインターフェースを共有してインテリジェンスから統合を切り離せるようにしました。

技術的基盤について詳しく確認するには、Developer Knowledge MCP サーバーでナレッジグラウンディングの詳細を確認するか、Google ADK GitHub リポジトリでフレームワークのコア機能について調べることができます。

ツールセットが完全に構成され、使用できる状態になったので、パート 2 に進みましょう。パート 2 では、マルチエージェントアーキテクチャを構築し、Vertex AI Memory Bank を統合してこれらの機能をオーケストレートします。さらに詳しく調べる場合は、GitHub リポジトリでシリーズ全体の詳細なコードを確認できます。

この記事に対して、レビューとフィードバックを提供してくださった Remigiusz Samborski 氏に心より感謝いたします。

このようなコンテンツをさらにご覧になりたい場合は、LinkedIn と X で私をフォローしてください。

- AI / プロダクト / DevRel 責任者、Shir Meir Lador

Red Hat OpenShift on Google Cloud を移行およびスケールする新しい方法

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

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

オンプレミスワークロードを実行している組織は、クラウドに移行する際に、難しい選択によく直面します。それは、ビジネスの基盤となるアーキテクチャの整合性を損なわずに、どのようにモダナイズするかということです。Red Hat OpenShift を使用すると、強制的なプラットフォームの再構築というリスクを負わずに、これらの環境を連携させることができます。Google Cloud は、OpenShift 向けの安全かつ信頼性の高い高性能なプラットフォームを提供し、グローバルスケールおよび独自の費用最適化インテグレーションを実現します。こうした強固な基盤に支えられ、Google はこのたび Red Hat との連携に関するいくつかのアップデートを発表しました。具体的には、Google Cloud Cluster Services for Red Hat OpenShift、新しいコンソールエクスペリエンス、OpenShift Virtualization on OpenShift Dedicated の一般提供が含まれます。これらのアップデートにより、Google Cloud の高パフォーマンスインフラストラクチャで、コンテナ化されたワークロードと仮想化されたワークロードを実行できるようになります。

Google Cloud インフラストラクチャによる費用の最適化

Google Cloud のグローバルインフラストラクチャは、パフォーマンス、スケーラビリティ、効率性を重視して構築されており、貴組織の最も重要なアプリケーションに活用できる世界クラスの基盤を提供します。この革新的なインフラストラクチャは、Red Hat OpenShift をデプロイする際に大きなメリットをもたらします。Deutsche Börse、Kohl’s、Salling Group、Amadeus、UPS など、数百もの企業のお客様が、Red Hat OpenShift on Google Cloud で本番環境ワークロードを実行し、Google の信頼性とセキュリティを活用されています。Google Cloud に移行することで、組み込みのテクノロジーを使用して総所有コスト（TCO）を削減し、インフラストラクチャをワークロードのニーズに合わせて最適化できます。

カスタムマシンタイプ: CPU とメモリを特定の要件に合わせて調整できるため、あらかじめパッケージ化されたインスタンスで未使用のリソースに対する料金の発生を回避できます。
Hyperdisk ストレージプール: パフォーマンスと容量を個別にスケールできるため、多数のボリュームの費用を一度に最適化できます。
Axion プロセッサ: Google のカスタム ARM ベースのプロセッサを使用して、費用対効果とエネルギー効率を高められます。

これらのツールを使用して得られる金銭的影響は明らかです。Red Hat OpenShift を Google Cloud に移行して得られるビジネス価値に関する IDC の最新調査では、組織が年間平均 2,630 万ドル相当のメリットを得ていることがわかりました。このメリットの大部分は、カスタムマシンタイプや Hyperdisk などのツールを使用してインフラストラクチャ費用を節約することで実現されました。

Google Cloud Cluster Services for Red Hat OpenShift のご紹介

Cluster Services for OpenShift は、Google Cloud のコアサービスとの OpenShift ネイティブインテグレーションを提供し、運用を簡素化します。Google は、お客様が既存のアーキテクチャとの整合性を維持しながら、クラウドネイティブな運用モデルをより簡単に導入できるようにしたいと考えています。オンプレミスで OpenShift を使用している多くのお客様にとって、ワークロードをクラウドに移行する際に、どうバランスをとるかが課題になります。アプリケーションの深い依存関係や企業ポリシーによる制約を満たしながら、クラウドの効率性を確保しなければならないからです。

Google Cloud Cluster Services for OpenShift では、マネージドサービスを選択して導入できるため、「オールオアナッシング」のアプローチから脱却できます。極めて重要な点は、これらのサービスは Google Cloud で利用可能なすべての OpenShift エディションでサポートされていることです。これは、セルフマネージド OpenShift エディションが必須のターゲットアーキテクチャである場合に特に重要になります。複雑なシナリオでも、組織がクラウドネイティブな運用モデルを活用できるようになるからです。

これらのインテグレーションは、Red Hat と Google Cloud が共同で設計およびサポートしており、責任の所在が明確になっています。このサービスには以下が含まれます。

マネージドサービスのインテグレーション: OpenShift の使い慣れたインターフェースから、Hyperdisk、Filestore、Cloud Monitoring、マネージド Prometheus、Secret Manager、Workload Identity 連携、Certificate Authority Service、Google Identity などのサービスへの深い連携が可能です。これらのサービスは、OpenShift のユースケース向けにカスタマイズされています。たとえば、1 TB 未満の Filestore インスタンスサイズの有効化や、OpenTelemetry 指標の取り込みのマネージド Prometheus でのサポートが挙げられます。
ミドルウェアとインテグレーションレイヤ: CSI ドライバ、OpenTelemetry、cert-manager、Secret Store CSI などの業界標準のプラグインと拡張機能を含む堅牢なスタックが提供されるため、ご利用になっているプラットフォームと基盤となるクラウドサービス間の OpenShift ネイティブなインテグレーションを確保できます。

環境を健全に保てるよう、Google Cloud Workload Manager を介した構成の検証も導入されています。このサービスは、マネージドサービスとのインテグレーションがベストプラクティスに準拠しているかどうかを自動的にチェックし、問題があればアラートを発します。また、マネージドサービスの使用によるクラスタのモダナイズの機会も通知します。

Google Cloud コンソールでのクラスタの作成

OpenShift の使用は、直感的に始められるべきです。そのため、OpenShift を Google Cloud コンソールに直接統合することで、ガイド付きのエクスペリエンスが実現されました。シンプルなインターフェースで新しいクラスタを作成できるようになったため、Google のプラットフォームで、環境をより迅速にデプロイできます。

Google Cloud コンソールでの OpenShift の操作性により、クラスタ作成の前提条件を確認し、Red Hat Hybrid Console にリダイレクトしてクラスタ作成を完了できるため、クラスタのデプロイが容易になります。

Red Hat OpenShift Virtualization で VM とコンテナを同時に実行

また、Red Hat OpenShift Dedicated on Google Cloud で利用できる Red Hat OpenShift Virtualization の一般提供も発表いたしました。OpenShift に含まれるこの機能を使用すると、同じプラットフォーム上でコンテナと並行して仮想マシン（VM）を実行および管理できます。Google Cloud ベアメタルインスタンスと Hyperdisk を使用することで、VM を以前の仮想化ソリューションから最新の Kubernetes ベースのコントロールプレーンに移行できます。さらに、OpenShift Virtualization on Google Cloud は、ベアメタルアクセスとハイパーバイザレベルの構成可能性により、最大レベルの柔軟性を提供します。これには、貴組織のワークロードに適したオーバーコミットをカスタム設定できる機能が含まれており、費用の最適化に役立ちます。OpenShift Virtualization on Google Cloud を使用すると、インフラストラクチャ管理を統合し、独自のペースでクラウドに移行できます。

始める

さまざまなコンポーネントとその可用性について詳しくは、Google Cloud Cluster Services for OpenShift に関するドキュメントをご覧ください。
新しいクラスタ作成方法をお試しになるには、Google Cloud コンソール上の OpenShift にアクセスしてください。
OpenShift Virtualization が VM ワークロードのモダナイズにどのように役立つかについては、OpenShift Virtualization に関するドキュメントをお読みください。

- プロダクトマネージャー、Pablo Osinaga

- スタッフソフトウェアエンジニア、Bharat Singh

【先着特典あり】Next Tokyo 登録開始！7 月 30 日、31 日東京ビッグサイト

Wed, 08 Apr 2026 03:00:00 +0000

革新的なアイデアを、AI とクラウドで実現しよう

旗艦イベント Google Cloud Next Tokyo を 2026 年 7 月 30 日（木）、 31 日（金）に東京ビッグサイト南展示棟・会議棟にて開催します。

Next Tokyo 2026 は、現場を支えるエンジニアと、未来を担うビジネスリーダーが主役となる舞台です。AI と Google Cloud の最先端トレンドを凝縮し、あなたの戦略を具現化するための具体的なソリューションをお届けします。

未来を築くのは、あなた自身です。Next で得られる最先端の知見や戦略、ツールを手に、次の一歩を踏み出しましょう。革新的なアイデアを現実へと変えるための、多彩な学びがここにあります。

公式サイトからご登録いただき、新たな可能性を切り拓くこの機会に、ぜひご参加ください。

先着 2,000 名様に早期登録特典

Google Cloud を試すための 100 ドル分のクーポンを先着 2,000 名様にプレゼント！お早めに公式サイトからご登録ください！

※クーポンの利用上限 100 ドルを超えると課金されますのでご注意ください

基調講演

ビジネスの「自律」を実現する Agentic AI（エージェント型 AI） と Google Cloud の最新技術を紹介。日本市場のリーダーが登壇し、変革の軌跡と AI による成長戦略のビジョンを提示します。

ブレイクアウトセッション

9 つの専門分野から、次なるイノベーションを形にするセッションをご用意。米 Next 最新技術アップデートや国内企業のリアルな活用事例など、実践的な情報を凝縮。また、エキスパートに直接質問し、議論を深めるチャンスも！

Expo、Learning & Certification

最新の Agentic AI とクラウドを Expo でライブ体験！Gemini 最新モデルの圧倒的な性能を実感してください。Learning & Certification では、レベルを問わず個々の成長を加速させる最新の学習パスをご提案。あなたのスキルアップを応援します！

入門、スペシャルセッション

Google Cloud 認定トレーナー「Authorized Training Partner」による入門セッションに加え、公共・ヘルスケア・カルチャー分野の体験型スペシャルセッションも実施します！

開催概要

名称：Google Cloud Next Tokyo（略称 Next Tokyo）

日時：2026 年 7 月 30 日（木）、31 日（金）

会場：東京ビッグサイト南展示棟・会議棟

対象：エンジニアからビジネスリーダーまで、生成 AI やクラウドを活用して、ビジネスを次のステージへと進めたいすべての方へ

- お問い合わせ -

Google Cloud Next Tokyo 運営事務局

E-mail: gc-nexttokyo-info@google.com

FM Logistic が AlphaEvolve を使って倉庫規模の「巡回セールスマン問題」を解決

Wed, 08 Apr 2026 03:00:00 +0000

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

巡回セールスマン問題とは、「すべての地点を 1 回ずつ訪問する最短ルートは何か」という、一見すると単純な問題です。これはコンピュータサイエンスにおける最も難しい問題の一つであり、数学者は 1 世紀近くもこの問題に取り組んでいます。また、FM Logistic のポーランドの倉庫作業員が日々直面している課題でもあります。

倉庫は全体でサッカー場 8 面分の広さがあり、ピッキングポイントの数は 17,700 を超えています。シフトごとの作業員数は数十人にのぼり、その各人が電動車両に乗ってフロアを縦横に駆け巡り、1 度の巡回で数十か所の保管場所を回って段ボール箱を回収します。こうした作業において、不要な経路が積み重なっていくと、時間が無駄になるだけでなく、車両の劣化や、納品の遅延にもつながります。

14 か国以上でグローバル事業を展開する物流プロバイダの FM Logistic は、すでにルーティングを最適化する仕組みを有していました。既存のモデルは、費用優先の高速なルート割り当てロジックに基づき、リアルタイムで応答を得られるようなものです。これはこれでうまく機能していましたが、ルートの判断がその都度行われる仕組みになっており、倉庫全体から見たルート調整能力に限界がありました。一度のシフトで同時に働く作業員数が数十人にのぼることを考えると、ルートがわずかでも改善されれば、大きな効果に直結します。

そこで導入されたのが、Google Cloud の AlphaEvolve です。

AI に、もっと優れたアルゴリズムを書いてもらう

AlphaEvolve は、Gemini モデルを使ってアルゴリズムを自律的に生成、改良する進化型のコーディングエージェントです。固定ルールからスケジュールを計算するのではなく、コーディングパートナーのように動作するのが特徴で、新しいコードを記述し、スコアを付け、最初のコードよりも優れたソリューションが見つかるまで反復処理を行います。

この取り組みをゼロから始めたわけではありません。既存のアルゴリズムを AlphaEvolve に「シード」プログラムとして提供しました。このアルゴリズムは、各ステップごとに、最善と思われるルートをその都度採用するというものです。この実際に使用されているアルゴリズム（すでに問題を解決しており、まだ最適化の余地があるもの）をベースラインとして使用し、Gemini を使って変更や新しいロジックを加えて新たなコードを生成して、人間が設計した元のコードを上回ることができるかどうかを調べました。

改善結果の評価

AlphaEvolve によって改善するには、各アルゴリズムのパフォーマンスを測定する方法が必要となります。そこで、60 件の巡回（合計 1 時間以上の作業員データ）を代表的なデータセットとして使ってカスタム評価関数を設計し、生成された数千のアルゴリズムを実際の状況下でテストしました。

この評価では、「ピックごとの平均移動距離を最小に抑える」という基本的な目標に基づいてコードをスコア付けします。また、運用上の問題を回避するため、フォークリフトの容量超過や、注文品の回収漏れ、同じ箱の重複割り当て、注文の先入れ先出しルール違反、リアルタイム運用で許容される計算時間の超過といった事象にそれぞれペナルティを設け、不適切な解を避けられるようにしています。

結果

新しいルーティングロジックでは、過去最良だったベースラインからの改善をただちに数値で確認できました。

過去最良のソリューションと比較して、ルーティング効率が 10.4% 向上。
全体で、倉庫内の移動距離が年間 15,000 km 以上削減。

この効率化により、人員や車両を増やすことなく、従来と同じ作業員数および設備でより多くの注文を処理できるようになりました。

FM Logistic のグループ CIO である Rodolphe Bey 氏は、次のように述べています。「Google Cloud と協力して AlphaEvolve および Gemini を実装したことで、このスピードが要求される業務においてルーティングアプローチをさらに最適化することができました。既存のアルゴリズムもすでに高度に最適化されていたため、そのベースラインを超えることは困難と思われましたが、上乗せで 10.4% の改善を実現しました。この改善は、納品のスピードアップや、労働条件の改善、車両の劣化軽減に直結しています。」

最終的に勝ち残ったアルゴリズムの動作

AlphaEvolve の実験を繰り返し、実験のたびに数百の候補プログラムを生成するという方法によって、人間が設計した最良のアルゴリズムを上回る新しいアルゴリズムが生み出されました。この新しいアルゴリズムは、人間が解読可能なルールセットとなっており、倉庫チームが内容を確認して適宜調整することが可能です。

3 つの主な改善点:

密度ベースの開始点（アンカー選択）: 旧システムでは、最も多くのピッキングが必要な一か所を開始点として選択していました。新しいアルゴリズムでは、開始点を広く捉えるようになっています。具体的には、互いに近くにあるアイテム同士をクラスタ化して、アイテムが密集しているエリアを開始点（基点アンカーグループ）として使用します。この方法によって、すべての巡回において開始点の効率が高められます。
距離シミュレーションにおけるフィルタリング: リアルタイムに通用する速度を維持するため、2 段階の処理プロセスを使用しています。まず、クイックフィルタによって、ルートロジックに適さない注文を除外します。続けて、残った適切な候補に対してのみ厳密な距離シミュレーションを実行することで、スピードを落とすことなく最も効率の良い経路を見つけています。
柔軟なルート構築: ある出発点から初めて、トラックを効率的に満載にできなくなった場合、無駄なルートを強制することはありません。メインプールにいったん積み荷を戻し、後でもっと良いルートでピックすることで、倉庫全体で効率を向上させています。

次のステップ

ポーランドでの試験運用（現在は本番環境に移行済み）では、倉庫規模の複雑なルーティングにおいて、進化型 AI が役立つことが示されました。FM Logistic は現在、大量の商品を扱っている他の e コマース施設にもこのアルゴリズムを適用することを計画中です。また、AlphaEvolve を道路輸送にも応用し、トラックが積載量に満たない場合の効率化に役立てられないかどうか探っています。さらに、倉庫内の商品配置にも AI を活用して移動距離をさらに短縮できないかどうか検討中です。

^{このプロジェクトは、FM Logistic チーム（Mateusz Klimowicz、Jarosław Urbański、Florent Martin、Alberto Brogio）、Google Cloud の AI for Science チーム（Kartik Sanu、Laurynas Tamulevičius、Nicolas Stroppa、Chris Page、Gary Ng、John Semerdjian、Skandar Hannachi、Vishal Agarwal、Anant Nawalgaria、他）、Google DeepMind の協力によって実現しました。}

- FM Logistic、シニアソフトウェアエンジニア、Mateusz Klimowicz 氏

- Google、シニアスタッフ ML エンジニア兼プロダクトマネージャー、 Anant Nawalgaria

Vertex AI に Veo 3.1 Lite と Veo の新しいアップスケーリング機能を導入

Wed, 08 Apr 2026 03:00:00 +0000

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

このたび、Vertex AI に、最も費用対効果の高い動画モデルである Veo 3.1 Lite を導入いたします。

また、この新しいモデルとともに、既存の動画アセットを強化するのに役立つ、Veo のスタンドアロンの新しいアップスケーリング機能も Vertex AI でリリースいたします。

ワークロードに適した Veo モデルの選択

動画生成機能をアプリケーションに統合する際は、特定のユースケースに合わせてモデルを選ぶことが重要です。Veo 3.1 ファミリーのティアは 3 つになり、いずれのティアでもネイティブ音声生成機能が利用可能です。

Veo 3.1: このモデルは、最終的な制作カットで視覚的な忠実度が最優先される最先端の動画生成向けに設計されています。
Veo 3.1 Fast: 高品質を維持しながら動画生成を高速化するオプションで、標準的な制作ワークフローに最適です。
Veo 3.1 Lite: Google の最も費用対効果の高いモデルです。企業は大量の動画アプリケーションを構築し、迅速に反復処理してスケールできます。

料金の内訳については、Vertex AI の料金ページをご覧ください。

完全なガイドについては、Veo 3.1 のプロンプトに関する究極のガイドをご覧ください。

Veo の新しいアップスケーリング機能でアセットをアップスケール

お客様から特に要望の多かった機能は、既存の低解像度動画を高解像度にアップスケールする機能です。限定公開プレビュー版で利用可能で、近日中に公開プレビュー版で利用可能になる Veo の新しいアップスケーリング機能により、Veo、他の AI モデル、従来のカメラのいずれで生成された動画でも、1080p および 4K まで画質を向上させることができます。

次のデモで、Veo がアイデアをどのように形にするかをご覧ください。

Veo 3.1 Lite を今すぐお試しください

このたび、Vertex AI API と Vertex AI Media Studio を通じてこのモデルにアクセスいただけるようになりました。

ベストプラクティスについて詳しくは、以下のリソースをご覧ください。

- Google Cloud、生成メディア担当グループプロダクトマネージャー、Sandeep Gupta

LLM 推論の効率的フロンティアに到達するための 5 つの手法

Wed, 08 Apr 2026 02:10:00 +0000

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

モデル推論に費やした費用の分だけ、レイテンシとスループットのグラフ上で良いポジションが得られます。上の図には、ハードウェアから可能な限り最大のパフォーマンスを引き出した、最適な構成の曲線が示されています。この曲線は、金融のポートフォリオ理論から借用したもので、効率的フロンティアと呼ばれます。

ハードウェアの予算が固定されていると仮定すると、レイテンシとスループットをトレードオフできます。ただし、フロンティア曲線自体が移動しない限り、一方を改善するには他方を犠牲にする必要があります。根本的に異なる 2 つのダイナミクスが作用しており、これは本番環境で LLM を実行するすべての人にとって重要なインサイトです。

最初のダイナミクスはフロンティアに到達することです。これには、現在利用可能なあらゆる手法を適用することが含まれます。この部分は、自分で制御できます。継続的なバッチ処理、アテンションの分割、インテリジェントルーティング、投機的デコーディング、量子化はすべて、現在存在する手法です。これらの手法を使用していない場合、運用がフロンティアを下回り、パフォーマンスを最大限に引き出すことができません。

2 つ目のダイナミクスは、フロンティア自体が常に外側に移動していることです。この部分は、ほとんどの場合、自分で制御できません。研究者は新しいアルゴリズムを発表し、ハードウェアベンダーは新しいアーキテクチャを出荷し、オープンソースプロジェクトは成熟します。ブレイクスルーが起こるたびに、物理的に達成可能なことが再定義され、曲線が拡大されるため、昨日の最適な構成が今日の非効率になります。

プラットフォームエンジニアの仕事は、フロンティアにできるだけ近い位置を維持しながら、新しい進歩がもたらされるたびにそれを吸収できる十分な柔軟性を持つインフラストラクチャを構築することです。この記事では、そのためのツールをご紹介します。

推論に効率的フロンティアがある理由

すべての LLM リクエストには 2 つの計算フェーズがあり、それぞれ異なるハードウェアリソースでボトルネックが発生する可能性があります。

1. プレフィル（コンピューティングバウンド）: このフェーズでは、GPU が入力プロンプト全体を一度に処理して、アテンション機構の Key-Value（KV）キャッシュを構築します。命令は並列でバッチ処理されるため、GPU のコンピューティングコア（テンソルコア）の使用率が高くなります。このフェーズは高速かつ効率的です。プロセッサは、大規模な行列乗算を実行するために必要なすべてのデータをすぐに利用できます。プロンプトが長くなると、単純に計算量が増えます。

2. デコード（メモリ帯域幅バウンド）: このフェーズでは、新しいトークンが一度に 1 つずつ自己回帰的に生成されます。1 つのトークンのみを生成する場合、GPU は作業をバッチ処理できません。モデル全体の重みと増大する KV キャッシュを高帯域幅メモリ（HBM）からコンピューティングコアにフェッチする必要があります。その後、GPU はその 1 つのトークンを計算し、次のトークンに対して再び同じ処理を行うのを待ちます。

この不一致こそが、フロンティアが存在する根本的な理由です。トレードオフなしに、単一のシステムを同時に両方のフェーズ向けに最適化することはできません。

推論の 2 つの軸

LLM 推論の効率的フロンティアでは、リスクとリターンの代わりに、ハードウェア予算が固定されているという前提で、別の基本的なトレードオフが測定されます。

軸	測定される主な指標	ハードウェアの制約
レイテンシ（X 軸）	最初のトークンまでの時間（TTFT）+ トークン間の時間（TBT）	コンピューティング（プレフィル）とメモリ帯域幅（デコード）
スループット（Y 軸）	すべての同時ユーザーの 1 秒あたりの合計トークン数	バッチサイズ × メモリ容量

費用は、レイテンシとスループットのグラフ自体を購入する制約です。ハードウェアの予算を増やすか、業界が画期的な新しいアルゴリズムを発明すると、フロンティア曲線全体が外側にシフトします。特定の予算とソフトウェアスタックで、最適ではない状態からそのフロンティアに向かって移行するための現在のベストプラクティスを適用できます。

フロンティアに到達する: 制御可能な 5 つの手法

現在、本番環境における大部分の推論システムの運用は、フロンティアを下回っています。優れた手法は存在するものの、そのような手法をまだ採用していないために、パフォーマンスが向上していないのです。このセクションで説明する手法はすべて、現在利用可能なものです。これらの手法を適用しない場合、運用が曲線を下回ることになります。

1. モデル階層間のセマンティックルーティング

すべてのクエリに 4,000 億パラメータのモデルが必要なわけではありません。単純な分類、要約、書式設定のタスクは、トークンあたりの費用が桁違いに安い、より小さな量子化モデルにルーティングできます。ゲートウェイエッジの軽量分類器がクエリの複雑さを分析し、それに応じてルーティングします。難しい推論にはフロンティアクラスのモデル、それ以外には小規模モデルを使用します。

セマンティックルーティングにより、システムは理論上の最大スループットに劇的に近づき、簡単なタスクでの無駄なサイクルが回避されます。集約された出力の品質が犠牲になることはありません。

2. プレフィルとデコードの分離

プレフィルフェーズとデコードフェーズを異なるハードウェアに物理的に分離することは、現在利用可能な、アーキテクチャ上最も重要な最適化の一つです。

プレフィルフェーズには、コンピューティング能力の高い GPU が必要です。デコードフェーズには、高帯域幅メモリが必要です。両方のフェーズを同じ GPU に強制的に割り当てると、一方のリソースが常に十分に活用されない状態になります。

両方のフェーズをそれぞれ理論上のハードウェア上限に近づけるには、専用のプレフィルクラスタとデコードクラスタを実行します。これらのクラスタを、圧縮された KV キャッシュの状態のみを同じ GPU に転送する高速ネットワークで接続すると、一方のリソースが常に十分に活用されない状態になります。

3. 量子化: 精度と速度のトレードオフ

モデルの重みを FP16 から INT8 または INT4 形式に減らすと、メモリ使用量を半分または 4 分の 1 に削減できます。デコードフェーズにはメモリ帯域幅の制限があるため、4 ビットの重みは 16 ビットの重みよりも最大 4 倍速く読み取ることができます。このアプローチにより、TBT が直接改善されます。

単純な量子化ではモデル出力の品質が低下するため、品質とのトレードオフが生じます。Activation-aware Weight Quantization（AWQ）や GPTQ などの最新の手法では、重要な重みの品質を維持しながら、他の重みを積極的に圧縮して、INT4 の速度で FP16 に近い品質を実現します。

4. コンテキストルーティング: ほとんどのチームが見落としている最大の要素

数十個のモデルレプリカを使用した本番環境でのデプロイでは、ルーティングレイヤが、現在最大の競争優位性を獲得できるかどうかの分かれ目となっています。

2026 年は、接頭辞のキャッシュ保存が基盤となっています。10 人のユーザーが 100 ページの RAG ドキュメントについてまったく同じ質問をしたり、同一の膨大なシステムプロンプトを使用したりする場合、コンピューティング負荷の高いプレフィルフェーズを 10 回実行すべきではありません。KV キャッシュを一度計算して保存し、他の 9 人のユーザーが再利用できるようにする必要があります。このアプローチにより、TTFT を最大 85% 短縮し、コンピューティング費用を大幅に削減できます。

ただし、注意点があります。標準の L4 ロードバランサはリクエストをランダムに分散します。ユーザー 2 のリクエストがユーザー 1 のリクエストとは異なる GPU に到達した場合、接頭辞のキャッシュは役に立たず、システムはキャッシュをゼロから再計算する必要があります。

コンテキスト認識型 L7 ルーティングが差別化要因となるのはこのためです。インテリジェントルーターは、受信したプロンプトの接頭辞を検査し、そのコンテキストをキャッシュにすでに保持している特定の Pod に意図的にリクエストをルーティングします。冗長な作業にコンピューティング能力を無駄に費やすことがなくなり、レイテンシとスループットをハードウェアの物理的な上限に即座に近づけることができます。

5. 投機的デコーディング

重要な点として、デコードフェーズでは、メモリ帯域幅にボトルネックがあるため、テンソルコアはほとんどアイドル状態です。投機的デコーディングは、この無駄な計算能力を利用します。

小規模で高速な「ドラフト」モデルが、複数の候補トークンを低コストで生成します。その後、大規模なターゲットモデルが、すべての候補を単一のフォワードパスで検証します。これは、シーケンシャルメモリバウンドのオペレーションではなく、並列コンピューティングバウンドのオペレーションです。ドラフトモデルが候補を正しく予測した場合、1 トークンのメモリコストで 4～5 トークンを生成したことになります。

このアプローチにより直接、メモリ帯域幅によって設定された TBT の下限よりも短い TBT を達成できます。レイテンシの影響を受けやすいワークロードに投機的デコーディングを使用していない場合、利用可能な最も効果的な最適化の一つを活用できていないことになります。

ドラフトモデルを追加すると、運用が多少複雑になり、コンピューティング費用がわずかに増加する可能性がありますが、ドラフトモデルはメインモデルに比べて比較的小さなものです。これとレイテンシをトレードオフする価値はあります。

なお、一部の新しいモデルでは自己投機的デコーディングが導入されており、2 つ目のモデルを管理するオーバーヘッドがなくなります。これらのモデルは、将来の追加トークンを同時に予測するようにトレーニングされた特殊な内部レイヤ（多くの場合、予測ヘッドと呼ばれる）を使用します。これらのモデルは一般に、非常に有意義なトークンヒット率を達成します。

ケーススタディ: Vertex AI がフロンティアに近づいた方法

Vertex AI エンジニアリングチームは、標準の Kubernetes Gateway API を基盤として構築された GKE Inference Gateway を採用したときに、フロンティアに近づきました。Inference Gateway はレイヤ 7 でリクエストをインターセプトし、2 つの重要なインテリジェンスレイヤを追加しました。

負荷認識ルーティング: モデルサーバーの Prometheus エンドポイントからリアルタイムの指標（KV キャッシュ使用率やキューの深さなど）を直接スクレイピングしました。このプロセスでは、リクエストを最も迅速に処理できる Pod にルーティングします。
コンテンツ認識ルーティング: リクエストの接頭辞を検査し、そのコンテキストを KV キャッシュにすでに保持している Pod にトラフィックをルーティングしました。このプロセスでは、コストのかかる再計算を回避できます。

本番環境のワークロードをこのインテリジェントなルーティングアーキテクチャに移行したところ、ネットワークレイヤの最適化が、大規模なパフォーマンス向上を実現する鍵であることが、Vertex AI チームによって証明されました。本番環境のトラフィックで検証した結果は、以下のとおりです。

Qwen3-Coder（コンテキストの多いコーディングエージェントワークロード）で TTFT が 35% 短縮
DeepSeek V3.1（バースト性の高いチャットワークロード）の P95 テールレイテンシが 2 分の 1（52%）に改善
接頭辞キャッシュヒット率が 2 倍（35% から 70% に最適化）

まとめ

LLM 推論には効率的フロンティアがあります。効率的フロンティアとは、特定のコンピューティング予算に対してレイテンシとスループットの最適なバランスが取れた絶対的な境界を表します。

効率的フロンティアに到達することは、自分で制御できます。現在、継続的なバッチ処理、アテンションの分割、インテリジェント L7 ルーティング、投機的デコーディング、量子化、プレフィルとデコードの分離といった手法が存在します。GKE Inference Gateway のケーススタディでは、ハードウェア、モデル、クラスタサイズを変更せずに、ルーティングのみで、TTFT が 35% 短縮され、キャッシュ効率が 2 倍になったことが示されています。フルスタックを適用しない場合、運用は曲線を下回り、トークンごとに過剰な料金を支払うことになります。

フロンティア自体が外側に移動し続けています。この部分は、自分で制御できません。研究者は新しいアルゴリズムを発表し、ハードウェアベンダーは新しいアーキテクチャを出荷し、オープンソースのサービングフレームワークはこれらのアルゴリズムとアーキテクチャを統合します。18 か月前には最先端の最適化だったものが、今では基本的な必須事項となっています。次にどのようなブレークスルーが起こるかを予測するのではなく、ブレークスルーが起こったときにそれを吸収できる柔軟なインフラストラクチャを構築することが、あなたの仕事です。

推論エコノミクスで成功する組織は、GPU を最も多く保有している組織ではなく、現在のフロンティアとのギャップを体系的に埋めながら、明日のフロンティアに備える組織です。

これらの最適化手法をご自身の LLM 推論ワークロードに適用したことがある方は、その体験談をぜひお聞かせください。構築したものを LinkedIn、X、Bluesky で共有していただければ幸いです。

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

Google Cloud Partner Tech Influencer Challenge 2026 実施のご案内

Tue, 07 Apr 2026 03:00:00 +0000

Google Cloud ではパートナー企業の社員の皆様による技術コンテンツの投稿を応援しています。2022 年より開始した「テクニカルブログチャレンジ」は、2025 年から「Google Cloud Partner Tech Influencer Challenge」と名称を変更し、ブログに限らない Web 媒体も対象として実施しています。

昨年は 2,500 を超えるコンテンツを投稿頂き大盛況だった本プログラムですが、2026 年度も実施させて頂きます。

本記事では 2026 年度の参加ガイドをご紹介します。

Google Cloud Partner Tech Influencer Challenge 2026 参加ガイド

期間：2025 年 11 月 1 日〜2026 年 10 月 31 日
対象：上記期間内に初めて投稿されたGoogle Cloud 技術コンテンツとします。技術コンテンツとは、Google Cloud と Google Workspace に関する検証内容、使い方Tips、アーキテクチャ説明を含めた導入事例等を指します。
対象投稿者：パートナー企業にお勤めの方であればエンジニア・非エンジニアは問いません。
投稿場所：自社のテクニカルブログサイト、自社ホームページ、または Qiita、Zenn、スライド共有サービスといった、Web 媒体（URL が存在して誰でもアクセスできるもの）にご投稿ください。テキストベースのブログコンテンツだけでなく、YouTube などの動画コンテンツも対象となります。
参加方法：エントリーフォームにてコンテンツの URL をご登録ください。1つのフォームで最大 10 の投稿をエントリーできます（1 記事ずつお送りいただいても問題ありません）。期間内であれば、新規の投稿を何回でもエントリーいただけます。

優秀コンテンツの発表

チャレンジ期間の終了後、後述の評価基準に応じて入賞企業および個人を選出いたします。選出されたコンテンツとその執筆者は本ブログで公開いたします。昨年の入賞コンテンツはこちらのブログをご覧ください。

またチャレンジ期間中に数回、ご応募いただいたコンテンツを厳選して紹介する特集記事も公開を予定しています。

評価基準

以下の賞を予定しておりますが、内容は変更となる可能性がございます。

企業の部

最優秀賞（発信数、昨年度からの伸び率によって選定）
Gemini Enteprise 賞（Gemini Enterprise の機能紹介や検証記事等の投稿数や内容によって総合的に選定）

個人の部

マルチメディア賞（ユニークなメディア媒体を用いていただいたコンテンツ）
Gemini 賞（Gemini による審査で特に優秀と判断されたコンテンツ）
Deep Dive 賞（製品技術についての How to や深堀りいただいたコンテンツ）

Google Cloud Next 特集のお知らせ

次回は 2026 年 4 月 22 〜 24 日にラスベガスで開催する Google Cloud Next に関する技術コンテンツの特集を予定しています。2026 年 5 月末までにご応募いただいたコンテンツから優秀なものを抜粋して本ブログで公開いたします。冒頭のエントリーフォームよりたくさんのご応募をお待ちしております。

エージェント型 AI の時代を支える Spanner のマルチモデルによる強み

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

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

エージェント型 AI の時代を迎え、データベースの役割は根本的に変わりつつあります。データベースは、もはや単なる受け身のデータ保管場所ではありません。生成 AI の基盤モデルを支え、先回りしたアクションを促す推論エンジンの土台となる、インテリジェントで能動的なコンテキストハブへと進化しています。高度な AI やエージェント型ワークフローを支えるには、データベースは単にデータを保存して検索するだけでは不十分です。複数のデータモデルが共存する環境の中で、推論を支援し、豊かなコンテキストを提供し、静的な情報から先を見越したアクションを導く役割が求められます。

マルチモデルデータベースというアプローチでは、分断されたサイロ間でデータを手作業で連携させる代わりに、リレーショナルデータ、ベクトルデータ、グラフデータを統合し、豊富で一元化されたナレッジベースを構築できます。これにより AI は、状況に関するコンテキスト、意味的なコンテキスト、関係性のコンテキストを同時に活用できるようになります。Google Cloud の Spanner は、グローバルな整合性、スケーラビリティ、フルマネージドの運用性を備えたデータベースとして、AI 時代を見据えて設計されています。データを統合し、高度なエージェント型 AI を支えるための一貫したアプローチを提供します。

この投稿では、Spanner が組織の AI 活用を本番運用レベルへと引き上げるうえで、どのように役立っているのかを見ていきます。さらに具体的な事例を知りたい方は、関連する記事もあわせてご覧ください。そこでは、不正検出、パーソナライズされたおすすめ表示、ハイブリッド検索、自律型ネットワーク運用という 4 つの主要分野を取り上げています。

相互運用性を備えたマルチモデルデータベースの力

現在一般的に行われている分断された複数データベースの運用戦略には、次のような重大な課題があります。

データの不整合: 信頼できる単一の情報源が存在しないため、開発者は壊れやすいアプリケーションコードによって無理に整合性を保たなければなりません。その結果、データの重複や陳腐化が生じるだけでなく、ガバナンスやセキュリティ上の深刻な脆弱性につながります。最終的には、アプリケーション全体の信頼性は、最も SLA の低いデータベースに左右されてしまいます。
運用とスキルのサイロ化: 異なるシステムを個別に管理することは、膨大な運用負荷を生むだけでなく、チームを専門スキルごとの縦割り構造に分断します。その結果、「複雑性のコスト」が発生し、コストの増大と開発スピードの低下を直接招きます。
統合インテリジェンスを阻む要因: 本質的なデータサイロに加え、ETL に伴う遅延がアーキテクチャ上の障壁となり、先進的な AI アプリケーションに不可欠な、リアルタイムで文脈を理解するインテリジェンスの実現を妨げます。

こうした課題が重なることで、AI 時代において大きな構造的不利が生じます。

Spanner がもたらす AI 時代の優位性

Google は長年にわたり、最も要求の厳しいクラウドワークロードにも対応できるよう、Spanner を継続的に進化させてきました。そして生成 AI の登場により、データベースにはこれまでにない新たな課題への対応が求められています。

そうした中、Spanner はその中核基盤を土台に、昨年、相互運用性に優れたマルチモデル機能を導入しました。これにより、リレーショナル、Key-Value、グラフ、ベクトルといった多様なモデルを用いて、単一の高性能なデータベース基盤の中でデータにアクセスし、クエリを実行できるようになりました。各データモデルは、それぞれ独自の強みを備えています。

リレーショナル: Spanner は、リレーショナルスケールアウトデータベースの先駆けとして、Google SQL と PostgreSQL の両方の言語で ANSI SQL を提供し、世界規模で可用性 99.999% と強整合性を実現しています。
Key-Value: Spanner は高性能な Key-Value データベース機能も備えています。Cassandra ネイティブエンドポイントにより、アプリケーションコードを変更することなく、Cassandra のワークロードを Spanner に容易に移行できます。
グラフ: ISO 標準の GQL を基盤としており、データをネイティブなグラフとしてモデル化することも、リレーショナルデータの上にシンプルなオーバーレイとして表現することも可能です。
ベクトル: KNN と ANN の両方に対応した、完全統合型のセマンティック検索ソリューションを提供します。特に ANN は、Google が持つ最先端の ScaNN 技術を用いて構築されており、100 億を超えるベクトルを含むインデックスにも対応できます。
全文検索: Google が数十年にわたり培ってきた検索技術を基盤に、40 以上の言語に対応した高度な情報検索機能を標準で備えており、構造化データと非構造化データの両方を横断して検索できます。
データウェアハウスとの統合: トランザクションデータと、分析処理から得られるインサイトをシームレスに結び付けることができます。

この統合アーキテクチャにより、複数の専用データベース間で複雑なデータ同期を行う必要がなくなり、環境を大幅に簡素化しながら開発を加速できます。お客様は Spanner の相互運用性に優れたマルチモデル機能を活用することで、異なる種類のデータをシームレスに組み合わせられるようになります。

AI をグローバル規模で成功へと導く企業

MakeMyTrip は、Spanner のマルチモデル機能を活用し、厳しい実運用環境の中で AI を本番導入している数多くの企業の一つです。

インドを拠点とするオンライン旅行会社 MakeMyTrip は、4 つの専用データベースを単一の Spanner インスタンスに統合することに成功しました。これにより、運用の複雑さを大幅に軽減するとともに、AI イノベーションを加速させ、高性能で高品質なアウトプットを実現しています。

MakeMyTrip でテクノロジー開発を統括する Ravindra Tiwary 氏は、Spanner への移行が組織にもたらしたさまざまなメリットについて、次のように述べています。「私たちは MongoDB、Neo4j、Elasticsearch、Qdrant を 1 つの統合システムに集約し、運用の複雑さを 75% 削減しました。この移行によって、複数のデータベースごとの違いに対応する負担や、重複した同期パイプラインを管理する手間が解消されました。

とりわけ大きな変化をもたらしたのは、語彙検索、キーワード検索、埋め込み検索を横断する統合クエリを、単一のプラットフォーム上で実行できるようになったことです。この統合により、統合ビュー機能の開発サイクルは 30% から 50% 加速し、目的地ごとに週 5.5 時間から 9.5 時間の運用工数を削減できました。

さらに、Spanner を信頼できる単一の情報源として活用することで、データドリフトを解消し、事実情報をアトミックに更新できるようになりました。その結果、回答品質スコアは 9% 向上しました。Spanner は今や、当社の『Destination Expert』エコシステム、すなわちパーソナライズされた旅行提案を行う自社開発の生成 AI 搭載旅行プランナー bot と、今後の AI ワークフローを支えるうえで不可欠な、スケーラブルかつ高性能な基盤となっています。」

AI 活用の取り組みで新たな到達点に達したのは、MakeMyTrip だけではありません。Target、Palo Alto Networks、MasOrange といった先進的な企業が Spanner を活用してどのように成果を上げているのかについては、次回の投稿でご紹介します。

Spanner を活用した自社の AI 活用を始めるには、Spanner のページをご覧ください。詳細を確認し、今すぐ取り組みを始めることができます。

- グループプロダクトマネージャー Wenzhe Cao

AI 搭載ツールが切り拓く、サステナブルなインフラとレポートの次なる潮流

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

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

生成 AI の活用が広がるなか、サステナビリティとテクノロジーが交わる領域で大きな変化が起きています。これまで報告業務を担うチームは、散在するデータの収集や手間のかかる文書作成に多くの時間を取られ、サステナビリティ戦略そのものに十分に注力できない状況にありました。ところが、AI を導入し始めた組織では、前年の実績や影響を説明するための作業に費やす時間が減り、その分、先を見据えたレジリエンス強化により多くの時間を充てられるようになっています。その結果、業務の効率化とスピード向上が進んでいます。

サステナビリティチームは、財務データ、施設面積、エネルギー使用量、材料消費量など、複数の異なるデータソースをもとにレポートを作成しなければならないことが少なくありません。しかも、報告基準は急速に変化しています。そのため、複数のデータソースをまたいで正確性を確保するのは難しく、ひとたび誤りがあれば、その影響も大きいという特有の課題があります。Google では、この課題に対応するため、この 2 年にわたり、自社の環境報告プロセスに AI を取り入れ、その有効性を検証しながら統合を進めてきました。

Google がレポート作成に AI をどう活用しているのか

まず Google は、自社の社内報告プロセスそのものを、AI ソリューションの実験の場として活用しました。環境報告書の作成にあたっては、環境に関する記述を確認する最初のレビュープロセスに Gemini を試験的に導入し、草案に含まれる記述を社内ポリシーやベストプラクティスと自動的に照合しました。この自動化は、専門家の役割を置き換えるものではなく、むしろその力を引き出すものです。人のレビュー担当者は、個々の記述を毎回ゼロから確認するのではなく、AI による評価結果の妥当性を見極めることに集中できます。また、NotebookLM を活用して静的な環境報告書を対話型のナレッジベースへと変換し、利用者が複雑なデータについて質問すると、出典付きの回答を即座に得られるようにしました。

私たちのチームは、効果のあったプロンプトや、期待どおりに機能しなかったプロンプトから得た教訓も含め、実験の内容と進捗をオープンソースの AI ハンドブックに記録しました。こうした取り組みを文書化するなかで、AI は単なる効率化のためのツールではなく、より大きな成果を生み出す触媒でもあることを実感しました。レポート作成に伴う複雑で手作業の多い工程を効率化することで、ファイルやデータの管理に費やす時間を減らし、その分、世界を前に進めるための戦略の推進に、より多くの時間を充てられるようになります。

Equinix におけるサステナビリティデータレイクの構築

デジタルインフラストラクチャプロバイダである Equinix は、Google Cloud の支援を受けながら、報告業務の変革に取り組みました。顧客から寄せられるサステナビリティ関連の要望が前年比で 46% 増加するなか、Equinix のチームは、手作業によるスプレッドシート運用ではもはや対応しきれないと判断しました。そこで必要とされたのが、リアルタイムの意思決定を支える仕組みでした。

Equinix は BigQuery 上にサステナビリティデータレイクを構築し、世界 240 箇所以上の拠点からデータを自動的に取り込めるようにしました。これにより、従来は手作業でのデータクリーニングに数週間を要していた報告サイクルが、必要なときにすぐ活用できるインサイトを提供する仕組みへと生まれ変わりました。

「私はもはや単なるデータアナリストではなく、戦略アドバイザーとしての役割を担っています」と、Equinix のサステナビリティ担当シニアマネージャーである Alexa Cotton 氏は述べています。「当社のサステナビリティデータは、今や戦略的な資産であり、年間経常収益（ARR）の 60% 以上に影響を与えています。私たちは事後対応型の姿勢から脱却し、エネルギーとコストの双方を削減できる自動化されたアクションに目を向けるようになりました。」

サステナビリティを設計段階から組み込む: Well-Architected Framework（WAF）の活用

Equinix は、AI による革新を実現するには、まず強固なデータ基盤が不可欠であることを示しました。また、レガシーな業務プロセスのモダナイズは、適切なアーキテクチャに基づいて進めることで、効率向上にもつながることを実証しました。

Equinix は BigQuery を活用したサーバーレスアーキテクチャへ移行し、コスト、パフォーマンス、環境負荷という 3 つの面で成果を上げました。

サーバーレスの弾力性を生かすことで、必要な分のコンピューティングリソースだけを使い、その分だけを支払う運用を実現した結果、「ゾンビ」サーバーは不要となり、無駄なエネルギー消費も削減されました。
BigQuery はワークロードのスケーリングと最適化をプログラムによって自動的に処理するため、リソース配分における人的ミスを抑えつつ、データレイクが拡大しても、無駄を最小限に抑えながら高い性能を維持できます。
Google のカーボンインテリジェントなデータインフラストラクチャを活用することで、「ワット当たりのパフォーマンス」を根本から改善し、報告業務という要件を、運用効率の高さを示す好例へと変えました。

これらは、Google の Well-Architected Framework における「4 つの M」、すなわち Machine、Model、Mechanization、Map を体現する優れた事例です。

アンビションループ

Equinix で進められている取り組みは、私たちが「アンビションループ」と呼ぶ好循環を生み出しています。アーキテクチャレベルで改善に取り組むことは、単にサステナビリティレポートの要件を満たすためだけではありません。経済性の向上にも直結し、その結果としてサステナビリティの成果も高まり、最終的には報告できる実績そのものの向上へとつながっていきます。

詳しくは、Google の「AI Playbook for Sustainability Reporting（サステナビリティレポートのための AI ハンドブック）」と、新たに追加された「WAF sustainability pillar」（WAF のサステナビリティの柱）をご覧ください。これらを手がかりに、データを AI 活用へとつなげる取り組みを始めることができます。ともに、レポートの未来、そしてよりレジリエントな世界を築いていきましょう。

- サステナビリティ担当グローバルマーケットリード Denise Pearl

- サステナビリティレポート担当シニアリード Luke Elder

AI リテラシーの新しい形: 学生デベロッパーを対象とした調査結果

Tue, 07 Apr 2026 01:00:00 +0000

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

AI により、学生デベロッパーはかつてないレベルで作業を効率化し、難しい問題を解決したり、野心的なプロジェクトに取り組んだりできるようになりました。一方、この新技術の登場によって、技術専攻の学生たちは学習について本質的な問いに向き合うようになってきています。

それは、AI をどの程度、何に使用すべきか、という問題です。

Google の DORA 2025 レポートによると、現在、日々の業務で AI を使用している技術者は 90% に達しています。こうした状況の中で、次世代が AI ツールとどう付き合っているのかを理解することがこれまでになく重要になっています。カリフォルニア大学バークレー校の学生を対象とした Google の調査では、学業における不正行為や知的作業の省略といった懸念を覆す結果が明らかになりました。学生は AI を近道としてではなく、学習パートナーとして捉え、タスクによって意図的に使用したり、使用を控えたりしています。

AI がソフトウェア開発の基盤となるにつれ、AI ツールを導入するかどうかよりも、懸命な活用方法が焦点になってきています。カリフォルニア大学バークレー校の学生たちは、その答えの一つを示してくれます。それは、彼らのもつ好奇心や、慎重さ、学習に対する純粋な意欲を、AI は支えることはできても、取って代わることはできない、ということです。

調査

カリフォルニア大学バークレー校の 4 人の学生チーム（Andrew Harlan、Mindy Tsai、Kenny Ly Hong、Karissa Wong）が、学業での AI の利用状況を把握するため、コンピュータサイエンス、電気工学、デザイン、データサイエンス専攻の学生を対象に調査を実施しました。この調査には、混合手法を使用しています。

また、同校の別のチーム（Edward Fraser、Jessie Deng、Eileen Thai）が、デベロッパー歴 1～5 年の人々を対象に、アイトラッキング技術を使って AI コーディングアシスタントの使用状況を観察しました。両チームとも専任メンターの支援のもと調査を進め、混合手法調査については Google 社員の Harini Sampath、Becky Sohn、Derek DeBellis が、アイトラッキング調査についてはカリフォルニア大学バークレー校の John Chuang 教授（博士）が助言を行っています。

これらの調査から、学生が AI を活用すると同時に、真の専門知識を身につけるためにどのような方法をとっているのか、3 つの重要な結果が明らかになりました。学生の間で見られるパターンは、実際に開発職に就いている人々を対象にした DORA の調査結果とよく似通っています。

調査結果その 1: 24 時間 365 日、いつでも頼れる先生

AI は近道ではなく家庭教師

調査で AI との関係性について尋ねられた学生は皆一様に、学びの場ならではの言葉を使いました。AI のことを、アシスタントや生産性向上ツールではなく、「家庭教師」や「先生」と呼んでいたのです。

「AI は教師のような存在です。内容の濃い資料を解説してもらったり、データベースにあらかじめ記述されているコードを部分的に説明してもらったりするなど、プロジェクトの基礎的な部分について理解を深めるためにとても役立っています。」

「[AI を] お抱えの家庭教師として利用しています。授業や講義の特定のトピックの [理解を深める] ために。コンピュータサイエンスだけでなく、あらゆる授業で使っています。」

ここで重要なのは、学生が AI に依存せず、計画的に使用しているということです。AI に課題を完成させるのではなく、自分の理解度を踏まえて AI を使用し、知識の抜けを特定したり、不確かな概念を明らかにしたり、学習プロセスをリードしてもらったりしています。回答の中には、講義で取り上げられた複数の学術論文を要約してもらい、どれを深く読みこむべきかを判断するといった使い方や、コードでエラーが発生する理由を AI に説明してもらう、といったものがありました。

ある学生は、学習プロセスに次のように組み込んでいます。

「教授の説明がわからなかったときは AI に尋ねます。たとえば、ある概念や、コードの機能について説明してもらったりします。また、ラボのどこから手をつけたらよいかわからないときは、AI にプロンプトで尋ねます。それからコードを書き始め、修正すべき点を尋ねるといった具合です。」

学習障がいのある学生にとっては、常に利用できるという点が、不利な状況を克服するために役立っています。

「私は学習障がいがあるため、問題を理解するのに人より時間がかかります。AI にはすごく助けられています。24 時間 365 日、いつでも付いていてくれるサブ教師のような存在です。」

AI を使えば、学校の営業時間に縛られることなく、いつでも理解を掘り下げられます。AI のおかげで脳の処理能力に余裕が生まれ、より高度な思考が可能となります。

「実際にコーディングする時間は減り、全体のアイデアを練るのに時間をかけられるようになりました。今では、手動でコードを生成する代わりに、ロジックとコンセプトの検討や、アイデアの創出に時間を費やしています。」

こうしたコメントから、AI が最終的な作品を仕上げるためではなく、探索ツールとして利用されている様子が浮かび上がります。これは、DORA の調査結果と一致しています。調査によると、AI がルーチンワークを引き受けることで、デベロッパーはユーザーへの価値提供に専念できるようになっています。

調査結果その 2: 過度な依存に対する積極的な抵抗

学びのプロセスを守るために、境界線を設ける

学生たちは、AI を学習ツールとして活用する一方で、AI への過依存への不安を率直に表現しました。

「AI がなくなったら、自分で解決方法を探すのに苦労してしまうかもしれません。」

エッセイ執筆中の脳活動を脳波検査で測定した最近の研究では、AI の利用者は、検索エンジンやツールを使用しない人に比べ、認知エンゲージメントのパターンが弱いことがわかりました。また、AI のヘビーユーザーが、アシスタントを使わずにエッセイを書いてみたところ、以前に書いた作品についての記憶があまりなく、自分の作品であるという意識も低いことがわかりました。このことを、論文の著者は「認知の負債」と表現しています。1

一方で、ポジティブな兆候が明らかになりました。学生たちは、この認知上のリスクをただ受け入れるのではなく、意図的に境界線を設けて対応しています。

機械工学専攻のある学生は、電子機器を何年も使用するうちに、以下のように能力ベースの AI 使用ルールを確立したといいます。

「サーボや超音波などの基本的センサーなら自分でコーディングできますが、複雑なセンサーで、かつ、機能を厳密に把握する必要性がないときは、AI を使用します」と回答し、次のように説明しています。「何かがうまくいかないとき、その理由を理解できても、問題を解決するための直接的な言語を知らない場合があります。AI は、そのような状況で役立ちます。」

この学生は、最近携わったプロジェクト（触って操作できるストーリーテリングツールの構築）において、基本的なコンセプトを理解した後、カウントおよび比較のシステム構築のために助けを求めたとのことです。「AI は、基本構造のセットアップに大変役立ちましたが、その後、微調整のコーディングは自力でやる必要がありました。」また、作業の振り分けについては、次のように明確な意見を述べています。「自分でも引き続き、コードを書いています。技術者のように丸投げするわけではなく、AI と共同で作業を進め、私が司令塔となって AI にやってほしいことを指示します。ただやみくもにリクエストしても、まったく役に立ちません。」

学生が AI を利用する際には、明確な利用ルールを設けているケースが多く見られました。

「AI にはたまに、完全な答えではなく方向性だけを示すように頼みます。」

過度な依存を避けるため、学生は以下のような具体策を編み出しています。

高度なモデルの利用を避ける:

「料金制の AI ツールを使用するつもりはありません。AI モデルを使いすぎてしまう恐れがありますから。」

AI の使用、不使用を交互に繰り返す:

「for ループの処理など、一部の処理はまた自分で書くようになりました。」

「バイブコーディング」を警戒する:

「AI ツールがデベロッパーの生産性を高めるために役立つことは間違いありません。ただし、バイブコーディングに慣れてしまわないよう、十分な注意が必要です。AI が生成するコードを理解して検証し、適切な方法で使用するということが大前提です。」

こうした懸念は、学生たちが認知について意識的に考えているということを示しています。彼らは、一番楽な方法が最も学習効果が高いわけではないと認識しています。これは DORA の調査結果とも一致しています。調査によると、AI の導入率が 90% にのぼるにもかかわらず、利用者の約 30% が AI が生成したコードをほとんど（あるいはまったく）信用していないと答えています。AI を効果的に使用するには、単に導入するだけでなく、厳しい評価と検証の方法を習得することが求められます。

調査結果その 3: AI の使いどころを心得ている

アイトラッキングデータからわかったこと

アイトラッキング技術を使用した調査では、人の動作の面から検証を行いました。1～5 年の経験を持つデベロッパーを対象に、AI コーディングアシスタントとやり取りする様子を観察したところ、タスクの種類によって AI の利用に大きな違いがあることがわかりました。

思考と深い理解が必要なタスク: AI への視覚的注目が 1% 未満
機械的なタスク（ボイラープレートコードなど）: AI への視覚的注目が 19%

高度な作業においては、たとえ AI の提案が正確で時間の節約につながるような場合でも、敢えて無視されていることがわかりました。深い理解が必要なときは、AI は認知上の負担となります。熟練デベロッパーは、AI をオフにすべきときを心得ています。

すべてを任せるのではなく、意図的に取り入れる

学生への聞き取り調査からも、学生が AI を用途に応じて使い分けている様子が伺えます。

「私は普段、とっかかりとなるアイデアを得るために AI を使っています。」

「AI の使用が許可されていることは知ってましたが、学習と試行錯誤のプロセスを大事にしました。創造性の余地も必要です。」

カスタマイズが肝

現在、ほとんどの AI コーディングアシスタントは、インライン提案のオン / オフを切り替えたり、オンデマンド専用モードに設定したり、提案頻度を調整したりできます。これらの設定を試して、タスクとその認知要件に応じて AI を使い分けることで、ルーチンワークでは助けてもらいつつ、自分で深く考えたい仕事の邪魔をされないようにすることができます。

この調査結果が業界において意味すること

AI を利用した開発の未来を形作っていくのは、今の学生たちです

調査に協力してくれた学生たちは、時代の一歩先をいっており、すでに AI リテラシーを身につけています。用途に応じた使い分けや、出力の検証方法を心得ており、自らの理解力を維持するためにときには敢えて手動で作業するといった対策をとっています。AI 導入を検討中の方にとって、こうした学生の経験は、進むべき方向を探るヒントとなります。

さまざまなカスタマイズ設定を試す: 作業の妨げとならず、助けとなるような設定を見つけましょう。
ワークフローに検証プロセスを取り入れる: AI の提案を無批判に受け入れないようにしましょう。
自分の聖域を確保する: スピードよりも深い理解が重要となる高度な問題には、AI の助けを借りずに自分で取り組むようにしましょう。

業界の専門家が AI の導入をどのように進めているかについて詳しくは、2025 年 DORA レポート: AI 支援によるソフトウェア開発の現状をダウンロードしてご覧ください。カリフォルニア大学バークレー校の研究者との共同研究による論文全文もあわせてお読みいただけます。

^{1. Kosmyna, Nataliya, et al. "Your Brain on ChatGPT: Accumulation of Cognitive Debt when Using an AI Assistant for Essay Writing Task." arXiv, 10 June 2025, doi:10.48550/arXiv.2506.08872.（参照日付: 2026 年 1 月 28 日）}

- Andrew Harlan 博士（独立系 UX リサーチャー兼クリエイティブテクノロジスト）

- Steve Fadden 博士（Google、UX リサーチ担当リード）

AI 時代のオープンプラットフォーム: GKE、エージェント、OSS のイノベーションを KubeCon EU 2026 で披露

Tue, 07 Apr 2026 01:00:00 +0000

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

今週、クラウドネイティブのコミュニティがアムステルダムに集まり、Kubecon + Cloudnativecon Europe が開催されます。Google は、オープンソースの Kubernetes エコシステムとGoogle Kubernetes Engine（GKE）を支援するために取り組んでいる活動の一部をご紹介します。これには、クラスタの運用モード間の壁を打ち破ることから、Kubernetes を AI エージェントや Ray を実行するための最適な場所にすることまで、Google が現在展開しているさまざまな取り組みが含まれます。

Autopilot をすべてのお客様に

5 年前、Google は、スケーリングとインフラストラクチャ管理を大幅に簡素化できるフルマネージドの GKE エクスペリエンスである GKE Autopilot を発表しました。以前は、GKE Autopilot モードと Standard モードのどちらを選択するかという判断は、クラスタ作成時の「分岐点」でした。たとえば、Standard モードで開始した後に Autopilot に切り替えたい場合は、まったく新しいクラスタを作成する必要がありました。そのため、厳格なノードレベルの制御が必要なワークロードと、シームレスで手間のかからないスケーリングが必要なワークロードが混在することになり、こうしたクラスタを管理する組織には大きな負担となっていました。

新しい GKE では、すべてのクラスタで Autopilot を利用できるようになりました。Autopilot コンピューティングクラスが Standard クラスタでも利用可能になったことで、ワークロードごとにいつでも Autopilot を有効にできます。GKE Autopilot の Container-Optimized Compute Platform（COCP）は、必要なときに必要な容量を最適な価格とパフォーマンスで提供するほか、ニアリアルタイムで垂直方向および水平方向にスケーラブルなコンピューティング環境を実現できます。

これに加え、お客様のインフラストラクチャプロビジョニングを推進するコアコンポーネントの一つである GKE クラスタオートスケーラーをオープンソース化することも発表します。Google の目標は、OSS コミュニティが活用でき、基盤を構築できる、ベンダーに依存しないプラットフォームを提供することです。

CNCF Kubernetes AI Conformance に向けて

この業界が大規模な AI へと移行する中、標準化は極めて重要です。昨年 Google は、Kubernetes コミュニティとともに、クラスタの相互運用性とポータビリティの標準を確立することで Kubernetes 上の AI / ML を簡素化する CNCF Kubernetes AI Conformance プログラムを立ち上げました。このたび、GKE が AI 適合プラットフォームとして認定されたことで、モデルや AI ツールを環境間で移行できるようになりました。

今後の Kubernetes v1.36 リリースに向けて、AI Conformance コミュニティは、AI サービングの進化するニーズに対応するために、高度な推論 Ingress、分離型サービング、高性能ネットワーキングという 3 つの新しい要件を提案しています。Google Cloud は、GKE Inference Gateway、llm-d、DRANET を通じて、これらの新たなコミュニティ規約をサポートすることに尽力しています。

Model Context Protocol: エージェントインターフェース

昨年 Google は、AI エージェントと Kubernetes との連携を効率化するために、オープンソースの GKE Model Context Protocol（MCP）サーバーを発表しました。これは、標準化されたインターフェースを提供することで、明確に定義された機能を通じて、ワークロード、クラスタ、リソースをエージェントが管理、分析、モニタリングできるようにするものです。これらの機能を公開することで、MCP サーバーは Gemini CLI や Antigravity などのさまざまな AI クライアントの統合を容易にするほか、Kubernetes エコシステムの管理の自動化を促進し、よりインテリジェントなものにします。

AI インフラストラクチャとしての Kubernetes

llm-d は正式に CNCF サンドボックスプロジェクトとなり、Kubernetes を最先端の AI インフラストラクチャに進化させるための大きな一歩を踏み出しました。2025 年 5 月に Red Hat や NVIDIA といった業界リーダーとの共同プロジェクトとして立ち上げられた llm-d は、特定のハードウェアやベンダーに依存しないように設計された Kubernetes ネイティブの分散推論フレームワークです。

このプロジェクトでは、推論を考慮したトラフィック管理、マルチノードレプリカのネイティブオーケストレーション、階層型 KV キャッシュオフロードの高度な状態管理について、well-lit paths（明確なパス）を導入することで、複雑な AI オーケストレーションの課題に対処します。クラウドネイティブなオーケストレーションと最先端の AI 研究のギャップを埋めることで、llm-d は高性能 AI サービングを広く普及させ、さまざまなアクセラレータの推論性能に関するオープンで再現可能なベンチマークを確立します。Google は、llm-d に関して CNCF AI Conformance プログラムと連携することで、分散型サービングなどの重要な機能をエコシステム全体で相互運用できるようにする予定です。llm-d について詳しくは、こちらのブログ記事をご覧ください。

DRA はリソース管理の新たな標準です

Kubernetes が誕生した頃は、変化するものは CPU とメモリだけであり、クラウドは無限に伸縮できると考えられていました。現在では、当然ながら、ハードウェアは専門化され、多様化しています。動的リソース割り当て（DRA）は、独自のハードウェアを標準形式で記述するための業界標準ソリューションであり、これにより、上位レベルのワークロードやスケジューラは、リソースに関する低レベルの詳細情報にアクセスすることなく、リソースを最適化できます。このたび、オープンソースでリリースすることを発表しました、TPU 用の DRA ドライバは、AI ワークロードのポータビリティを Kubernetes エコシステムにもたらすうえで重要なマイルストーンとなります。Google と NVIDIA は、統一されたリソース管理標準を確立するための共同の取り組みとして、OSS Kubernetes での DRA の設計と実装について緊密に連携しています。Google は、今回のリリースを、NVIDIA DRA ドライバの寄贈と合わせて発表できることを誇りに思います。これは、GKE のマネージド機能としてすでに利用可能なネットワーキング用の DRA ドライバである DRANET に加えて使用できます。

エージェントの波に対応: 推論とエージェント

エージェント AI の波が押し寄せています。Google は、エージェントの実行に最適なプラットフォームは Kubernetes であると確信しています。LLM が生成したコードを実行し、AI エージェントと安心してやり取りするには、高度な分離、起動時間の短縮、専用のインフラストラクチャが必要です。

Google は、これを実現するために、オープンソースの推論技術に多大な投資を行っています。たとえば、gVisor 対応のセキュアな分離を実現する Kubernetes Agent Sandbox や、ワークロードをメモリスナップショットから復元することで起動レイテンシを大幅に改善する GKE Pod Snapshots などのイノベーションを活用することで、Kubernetes 上のエージェント AI の標準を確立したうえで、GKE で実行されるエージェントのパフォーマンスやコンピューティング効率を高めています。

Kubernetes 上の Ray: TPU と優れたオブザーバビリティ

Ray は、要求の厳しい AI ワークロードをスケールするための標準になりつつあり、Kubernetes は Ray の実行に最適な環境であると Google は考えています。最近まで、公式のアクセラレータサポートは NVIDIA GPU に限定されていましたが、このたび、Anyscale と Google による完全なサポートを備えた Ray v2.55 の TPU を発表しました。

これまで、Kubernetes 上の Ray では、ジョブに関する過去のデータにアクセスできなかったため、デバッグやパフォーマンスの最適化が困難でしたが、この問題を解決するために、RayJob の完了または終了後に問題をデバッグする機能を導入しました。これを実現する Ray History Server は、Kuberay を使用して実行中の RayJob からログ、状態、指標を設定して永続化し、Ray ダッシュボードにそれらを再現できます。Ray History Server（アルファ版）は今すぐお試しいただけます。

ブースにお立ち寄りください

次世代の AI 推論のスケールアップ、高度に分離されたエージェントワークフローのデプロイ、クラスタ全体のコンピューティング容量の最適化など、どのような場合でも、Google は Kubernetes と GKE を究極のプラットフォームにすることに尽力し、お客様を成功に導きます。

KubeCon Europe に参加される方は、ぜひ Google Cloud ブース（#310）にお立ち寄りください。上述の発表について詳しくご説明するほか、セッション、ライトニングトーク、ハンズオンラボ、デモをご覧いただけます。また、テキストベースの冒険ゲームで楽しく競い合うイベントもご用意しています。Kubernetes の未来に乾杯！

- シニアクラウドデベロッパーアドボケイト、Abdel Sghiouar

- GKE プロダクト管理担当ディレクター、Allan Naim

初級者コースのように簡単: Vail Resorts がパーソナライズされたおすすめを自動化する AI アシスタントを構築した方法

Mon, 06 Apr 2026 02:20:00 +0000

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

スキーヤーやスノーボーダーは、新雪を追い求めたり、新しいトリックをマスターしたり、新しい地形を探索したりと、ゲレンデでのあらゆる瞬間を精一杯楽しむものです。よく知っているお気に入りのゲレンデを訪れる場合でも、初めてのゲレンデを訪れる場合でも、必要な情報をすぐに手に入れて、自信を持って移動し、隠れた名所を見つけ、到着した瞬間からその場所に溶け込みたいと考えています。

そのような理由から、Vail Resorts は 2024～2025 年の雪シーズンに My Epic Assistant をリリースしました。Vail は、世界で最も象徴的で愛されている山岳リゾート（ウィスラーブラッコム、パークシティマウンテン、ストウ、クレステッドビュートなど）を運営しています。同社は、すべての利用者が新しいアプリで十分なサポートを受けられる、つまり、ゲレンデ体験に没頭したまま、迅速かつ有益な回答を得て、ゲレンデにあるすべてのものを発見できるようにしたいと考えていました。

情報ブースを探すのと、次の滑走に向けてリフトに乗っている間にアプリで情報を得るのと、どちらがよいか、考えれば答えは明白です。

My Epic Assistant は、Vail Resorts の IT チーム、接客チーム、運営チームのノウハウを Google の強力な Gemini モデルにフィードする AI 搭載アシスタントです。結果として、ゲレンデで適切なシーズンパスを選択するサポート、最新の雪の状況の共有、レッスンの準備状況の確認、ココアを飲むのに最適な場所の提案などを、このエージェントで行えるようになりました。Vail Resorts は、単なる chatbot ではなく、ウィスラーでパウダースノーを楽しめる日と、ビーバークリークへの家族旅行に適した日の微妙な違いを理解できるデジタルコンシェルジュを求めていました。

これらのサービスを次のレベルに引き上げるため、Vail Resorts のチームと Google Cloud スペシャリスト 66degrees は、2025～2026 年シーズン向けに My Epic Assistant を更新し、シーズンパスのおすすめや強化されたパーソナライズなどの新機能を追加しました。この機能により、ゲストの質問を理解し、複雑なリクエストに対応して、ゲストに最適なパスをインテリジェントに案内できるようになりました。

この投稿では、ゲレンデを楽しむために迅速なサポートを求めている、目の肥えた利用者からの、微妙な違いのある複雑な質問に効果的に回答できるマルチエージェントシステムをオーケストレートするという難題に、Google がどのように取り組んだのかをご紹介します。このような AI 搭載ツールを活用できるのは、ゲレンデに詳しい利用者だけではありません。

このような AI 搭載ツールを活用できるのは、ゲレンデに詳しい利用者だけではありません。

このブログ投稿では、接客業のこの過酷な分野特有の課題に巧みに対処できるマルチエージェントシステムをオーケストレートして、My Epic Assistant を構築した方法について詳しく説明します。これは、顧客中心の他の分野の組織が、それぞれの状況に合わせてエージェントシステムを構築するうえでも役立つアプローチです。

新しいシーズン、より良い結果

My Epic Assistant 内のパーソナライズ、検索、要約の各機能、会話フローを実装して改良した結果、アプリの初回リリース以降、人間のエージェントへのエスカレーションが 45% 減少しました。

テクノロジーは人と人の触れ合いに取って代わるのではなく、それを強化するものです。日常的なロジスティクスを自動化し、パーソナライズを拡大することで、Vail Resorts のゲストエクスペリエンステクノロジーチームは、そのことを確実にすることができました。全体的に、サポートを求める利用者は、より迅速かつ確実に、より多くの方法とタイミングでサポートを利用できるようになりました。

「Google Cloud のツールを利用することで、エージェント設計パターンを活用して、自然でパーソナライズされた会話を実現できました。これにより、顧客満足度が向上し、手動でのインテント設計の必要性が低減しました。また、これらのツールにより、柔軟性と制御性を組み合わせて、アシスタントがブランド、ポリシー、プロダクト戦略の範囲内で常に流動的に対応できるようになりました」とチームは述べています。

My Epic Assistant の構築手順

まず、My Epic Assistant はサブトピック分類エージェントを使用して、パスの比較、おすすめの提案、一般的な情報の検索など、利用者の最初のリクエストを理解します。パスは期間限定でのみ購入できるため、日付オブジェクトを使用して時期を判断します。パスが販売終了している場合は、自動的にリフト券の情報にルーティングされます。パスとリフト券の両方が購入可能な場合、アシスタントはいくつかの確認の質問をして、旅行に最適な価値を提供するオプションを顧客が決定できるようにします。次に、アシスタントは、おすすめを提示するために必要な追加データを判断するために、データ収集エージェントに引き継ぎます。認証済みのユーザーの場合、Vail Resorts は、よく訪問するリゾート、平均訪問回数、年齢、今後訪問予定のリゾート、ピーク日の好みなどの既存のデータを、Webhook から呼び出して提供します。認証されていない新規のユーザーの場合、ギャップを埋めるために、確認のための回答しやすい質問をします。一方通行の静的なフォーム入力ではありません。

このステップでは、生成 AI の会話機能が真価を発揮します。My Epic Assistant は、自由に会話できるように設計されているため、利用者はいつでも確認のための質問をして、コンテキストを失うことなくレコメンデーションプロセスに戻ることができます。ハンドブックの手順に沿って、モデルは出力に必要なすべてのパラメータが入力されているかどうかを継続的に評価し、次のステップに進みます。このプロセス中も、利用者は他の質問をすることができます。

たとえば、ピーク日の利用を希望するかどうかを尋ねられた利用者が、「制限の対象となる今年のピーク日はいつですか？」と続けて質問する可能性があります。My Epic Assistant は、Vail Resorts の広範な知識を体系化したウェブサイトのデータストアを呼び出して対応します。その後、My Epic Assistant は回答を提供し、コンテキストを失うことなく会話の前のターンに戻ります。

最後に、レコメンデーションエージェントが引き継ぎます。収集したユーザーデータを使用して、すべてのパスオプションの構造化データベースに対してクエリを実行し、完全一致を見つけます。その後、システムは、特定されたパスが適している理由を説明するユーザーフレンドリーな回答を生成し、直接購入リンクを含むコンテンツカードを提供して、利用者の最終ステップを簡素化します。

パスレコメンデーションエージェントのコア機能は、既存のすべてのパス、その特長、制限事項の構造化ファイルを含むパスマトリックスのデータストアツールです。利用可能なオプションが多数あるため、ツールがすべての入力パラメータを受け取ったときに有効で適切なオプションを返すことを確認するには、広範なテストが必要でした。66degrees は、この分野に関する Vail Resorts の深い知識を活用して、あらゆる結果を検証しました。

プロンプトエンジニアリングにより、最終的な回答では、特定のパスが利用者に最適なオプションである理由を詳細に説明したおすすめが提示されます。また、おすすめの購入リンクを含むコンテンツカードも呼び出されます。ハンドブックを終了する必要はありません。新しくリリースされた Epic Friends 機能に関する詳細情報が表示されるなど、生成された回答が適切でない場合もありました。静的な回答は、コードスニペットと条件付きアクションを介して呼び出されます。これらもハンドブック自体に格納されるため、全体的なアーキテクチャが簡素化されます。

パーソナライズが初級者コースのように簡単に

My Epic Assistant のスマートテクノロジーとユーザー重視のデザインの新しい組み合わせにより、Vail Resorts は、単なる顧客の質問とその回答という枠を超えて、多くの顧客のリクエストに対して真に会話型でありながら完全に自動化されたエクスペリエンスを提供できるようになりました。重要なのは、Vail Resorts のような運営企業にリゾート利用者が期待するコンシェルジュサービスを、AI とクラウドテクノロジーなしでは実現できない規模で提供していることです。

Vail Resorts は、My Epic Assistant のパスのおすすめ機能により、すべての利用者がこれまでで最高のシーズンを過ごすためのカスタムのおすすめ情報を受け取れるように準備を進めています。

上級者コースのように技術的に難しい課題を、初級者コースのように簡単に扱えるソリューションで解決することをご希望の場合は、66degrees と Google Cloud のエキスパートにお問い合わせのうえ、最新の AI とクラウドテクノロジーで何ができるかをご確認ください。

- 66degrees、会話アーキテクト、Olivia Marrese

- Google、カスタマーエンジニア、Jacob Walcik

Manhattan Associates、Google Cloud データベースで 1 日に 10 億件以上の API 呼び出しを処理

Mon, 06 Apr 2026 02:10:00 +0000

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

編集者注: サプライチェーンとオムニチャネルコマースソリューションのグローバルリーダーである Manhattan Associates は、それまで使用していた Oracle と DB2 のシステムから Google Cloud データベースに移行することで、Manhattan Active SaaS プラットフォームをモダナイズしました。Cloud SQL と BigQuery を活用することで、同社は現在、1 日あたり 10 億件以上の API 呼び出しを平均 150 ミリ秒未満の応答時間で処理しており、数万の店舗と物流センターで毎月数十万人のアクティブユーザーをサポートしています。

モノリシックな基盤からクラウドのレジリエンスへ

当社の Manhattan Active SaaS プラットフォームは、グローバルサプライチェーンのサポートに不可欠なため、常時稼働と高いパフォーマンスが求められます。従来の Oracle と DB2 のインフラストラクチャは、手動によるスケーリング、複雑なライセンス管理、高額なメンテナンス費用が必要で、運用に大きな負担が生じていました。そのため、可用性を契約条項に規定した SLA、自動化されたレジリエンス、予測可能な費用モデルを利用できる新しいデータベース基盤を必要としていました。

当社が Google Cloud のデータベースを選んだのは、Manhattan Active をグローバル規模で稼働させるために必要な、柔軟性、スケーラビリティ、運用の容易さのバランスが適切だったからです。マネージドデータベースの Google Cloud SQL を使用することで、手動でのメンテナンスを排除でき、組み込みの高可用性、スケーラビリティ、リージョン間の障害復旧に注力できるようになりました。

Manhattan Active の各機能は、現在、独立したコンテナ化されたサービスとして実行されており、Google Kubernetes Engine（GKE）によってオーケストレートされています。データは Pub/Sub を介して BigQuery にストリーミングされ、リアルタイム分析が行われます。また、Cloud Logging と Cloud Monitoring により、大規模なオブザーバビリティを実現しています。Google Cloud のマネージドサービスを活用したマイクロサービスファーストの設計により、当社は、迅速に進化するためのアジリティを得られたほか、全リージョンにおいてミッションクリティカルな運用のレジリエンスを維持できるという確信を持つことができました。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud データベースでよりスマートに構築'), ('body', <wagtail.rich_text.RichText object at 0x7f9a984cfa30>), ('btn_text', ''), ('href', ''), ('image', None)])]>

あらゆるトランザクションにレジリエンスとスピードを組み込む

当社のプラットフォーム基盤を Google Cloud で刷新したことで、大規模に価値を提供する方法を再検討する機会が生まれました。Manhattan Active のアーキテクチャは、マネージドデータベースと連携することで、サプライチェーンの煩雑さが解消され、応答性とレジリエンスに優れたシステムへと変わりました。

そのメリットはプラットフォーム全体に波及しています。Cloud SQL は Manhattan Active の中核を担っており、1 日あたり数百万件に及ぶサプライチェーンのトランザクションを迅速かつ確実に実行しています。リアルタイム分析は BigQuery に送信され、より精度の高い予測と、より迅速な異常検出を小売業者に提供しています。自動フェイルオーバーとクロスリージョンレプリカによってビジネスの継続性が確保されるため、障害が発生した場合でも重要なサービスは利用可能な状態を維持できます。

基盤をモダナイズ: データベースからインテリジェンスへ

従来の Oracle と DB2 のシステムからの Google Cloud データベースへの移行は、パフォーマンスの問題を解決しただけでなく、次のステップに向けた強固な基盤を築くことにもなりました。その信頼性とスケーラビリティにより、生成 AI をサプライチェーンに直接組み込むことも可能になりました。

当社のエージェント型 AI スイートには、店舗や物流センターの業務全体でリアルタイムの意思決定を調整する事前構築済みエージェント（Intelligent Store Manager や Labor Optimizer など）が含まれています。また、Manhattan Agent Foundry を利用すれば、ローコード環境を使用してカスタム AI エージェントを構築することも可能です。この基盤は、リアルタイムのログ分析、デベロッパー向けコード支援、シナリオシミュレーションといったユースケースを通じて、社内の効率化も支えています。

かつてないスピード、規模、運用効率を実践

このプラットフォームのモダナイゼーションの効果は、小売業者にもすぐに現れました。それは、目に見えるスピードと信頼性です。

現在、Manhattan Active は、Cloud SQL と BigQuery を活用して驚異的な数の API 呼び出しに日々対応しており、平均応答時間は 150 ミリ秒未満を実現しています。このスピードにより、数万の店舗と物流センターにわたって数十万人の月間アクティブユーザーをサポートしており、重要な場面でのリアルタイムな意思決定を可能にしています。

運用面では、プラットフォームの弾力性と効率性が向上しました。このシステムは、1 日に数十万件のスケーリングイベントを自動的に処理するため、ピーク時のトラフィック急増時でも一貫したパフォーマンスを維持できます。高額なオーバープロビジョニングを行う必要はありません。また、Query Insights などのデータベースオブザーバビリティツールにより、エンジニアは状況を明確に把握できるため、データベースのパッチ適用や事後対応型のトラブルシューティングに費やす時間が減り、機能開発やパフォーマンスチューニングにより多くの時間を割けるようになりました。

現在、Manhattan Associates では、レジリエンスが組み込みの機能となっています。これは、当社のソフトウェアを利用する小売業者にとって、よりスマートかつ迅速で、将来のあらゆる事態に備えたサプライチェーンの実現へとつながるものです。

詳細

Cloud SQL でビジネスを変革する方法をご確認ください。今すぐ無料トライアルを開始できます。
IDC レポートをダウンロードして、Cloud SQL への移行によってコストの削減、アジリティの向上、デプロイの高速化を実現する方法をご確認ください。
Ford と Yahoo が Cloud SQL でモダナイズして、高いパフォーマンスを実現し、費用を削減した方法をご確認ください。

- Manhattan Associates、シニアディレクター、Narayana Reddy Kothapu 氏

- Manhattan Associates、テクニカルディレクター、Rajkumar Ramani 氏

M-Trends 2026: 最前線のデータ、分析、戦略情報のまとめ

Mon, 06 Apr 2026 01:00:00 +0000

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

サイバー脅威の状況は年々変化し、防御側は敵の戦術、手法、手順（TTP）の進化に対応することを迫られています。2025 年、Mandiant は攻撃者のペースがくっきりと 2 つに分かれていることを確認しました。これは、過去 1 年間にわたり Google が防御者向けの文書で指摘した傾向と一致しています。一方は、即時的な影響と復旧妨害を意図しているサイバー犯罪グループです。もう一方は、持続性を最優先とする巧妙なサイバーエスピオナージ集団やインサイダー脅威で、モニタリング対象外のエッジデバイスやネイティブのネットワーク機能を使用して検出を徹底的に回避します。

このたび、M-Trends 2026 が公開になりました。Mandiant が 2025 年、世界中の現場で 50 万時間以上にわたり実施したインシデント調査に基づき、現在、よく利用されている TTP をまとめた決定版レポートとなっています。

aside_block: <ListValue: [StructValue([('title', 'M-Trends 2026 を公開'), ('body', <wagtail.rich_text.RichText object at 0x7f9a9afcb400>), ('btn_text', '今すぐダウンロード'), ('href', 'https://cloud.google.com/security/resources/m-trends?utm_source=cgc-blog&utm_medium=blog&utm_campaign=FY26-Q1-GLOBAL-STO89-website-dl-dgcsm-mtrends26-162712&utm_content=-&utm_term=-'), ('image', <GAEImage: m-trends blog callout>)])]>

数字で読み解く: M-Trends 2026

今年のレポートでは、現代のセキュリティ対策を回避するために攻撃者がアプローチを変化させてきている様子がデータから明らかになっています。

滞留時間の中央値（全世界）: 滞留時間の中央値は、全世界で 11 日から 14 日に増加しました。このことから、攻撃者の手法が高度化していること、なかでも、防御を回避する手段が巧妙化していることが伺えます。特にインシデント件数が多い、サイバーエスピオナージおよび北朝鮮の IT ワーカーに限って見ると、滞留時間の中央値は 122 日でした。
初期感染ベクトル: 初期感染ベクトルとしては、脆弱性利用型不正プログラムが 6 年連続で最も多く、32% を占めています。一方、音声でのやりとりを主体とするビッシングが 11% に急増し、上位から 2 番目に位置付けています。
検出ソース: 組織内部の可視性が向上しています。2025 年、悪意ある活動の痕跡が組織内で最初に見つかった割合は全体で 52% となっており、2024 年の 43% から増加しています。
狙われた業界: 調査対象のインシデントで影響を受けた業界数は 16 を超えています。最も狙われたのはハイテク業界（17%）で、2024 年と 2023 年にトップだった金融業界（14.6%）を上回りました。

「引き継ぎ」期間の短縮

2025 年に観察されたなかで特に注目すべき傾向の一つは、サイバー犯罪エコシステムにおいて専門分野ごとの分業化と連携がますます進んでいることです。初期アクセスの請負人が、悪意のある広告や、ClickFix と呼ばれるソーシャルエンジニアリング手法などの目立たない手法を使用して、アクセスを確立します。その後、このアクセス権が、ランサムウェアなどの重大な攻撃を仕掛ける二次グループに引き継がれます。

初期アクセスイベントから二次グループへの引き継ぎにかかる時間の中央値は、2022 年は 8 時間超でしたが、2025 年にはわずか 22 秒にまで縮まりました。また、初期アクセスの請負人による「お膳立て」の範囲が広がり、二次グループが求めるマルウェアやトンネルの手配まで行うケースが増えています。つまり、二次アクターがネットワークに初期アクセスした瞬間にはもう、攻撃を開始する準備が万全に整っているのです。

この分業化というパターンは、初期感染ベクトルにも反映されています。世界中のあらゆる侵害を対象とすると、初期感染ベクトルとして「既存の侵害」（10%）が 3 番目に多くなっています。なかでも、ランサムウェアに関して言えば、初期感染ベクトルとして「既存の侵害」が最も多く（30%）、2024 年の 15% から倍増しています。

ビッシングと、SaaS ID の危機

これまで、攻撃者の常套手段といえばメールフィッシングでした。しかし、機械制御と自動処理が向上したことで、2025 年にはメールフィッシングによる侵入はわずか 6% まで減少しています。その代わりに台頭してきているのが、音声によるやりとりを主体とするソーシャルエンジニアリングです。

この変化については、ブログ投稿やレポートで詳しく取り上げています。特に、UNC3944 などのグループが IT ヘルプデスクを標的にし、多要素認証（MFA）を回避して、Software as a Service（SaaS）環境への初期アクセスを獲得する方法について詳しく追跡しています（「アクセスを目的としたビッシング: ShinyHunters ブランドの SaaS データ窃盗の拡大を追跡」を参照）。

M-Trends 2026 は、これらの手法が連鎖しながらどのような影響を及ぼしているかを明らかにしています。脅威アクターは、有効期間の長い OAuth トークンとセッション Cookie を収集して、標準的な防御策を回避します。続けて、サードパーティの SaaS ベンダーを侵害した後、ハードコードされたキーと個人のアクセストークンを盗み、それらのシークレットを使用してダウンストリームの顧客環境にシームレスに移動し、大規模なデータ窃盗を実行します。

ランサムウェアが復旧妨害型へと進化

ランサムウェアグループは、もはやデータを暗号化するだけではありません。復旧能力を徹底的に破壊します。2025 年には、REDBIKE（Akira）や AGENDA（Qilin）の使用で知られる有力なランサムウェアグループの攻撃対象が体系的にシフトしていることが確認されました。具体的には、バックアップインフラストラクチャや、ID サービス、仮想化管理プレーンを積極的に標的にするようになってきています。

たとえば、Active Directory 証明書サービステンプレートの構成ミスを悪用し、パスワードローテーションを無効にした管理者アカウントを作成して、クラウドストレージからバックアップオブジェクトを意図的に削除します。また、ハイパーバイザの「ティア 0」という性質を利用して、ゲストレベルの防御を無効化するケースもあります。さらに、仮想化ストレージレイヤを直接標的にしたり、ハイパーバイザのデータストアを暗号化したりして、関連するすべての仮想マシンを同時に動作不能な状態に陥れます。

この複雑に入り組んだ手口については、Google のガイド「ヘルプデスクからハイパーバイザまで: UNC3944 から VMware vSphere 環境を防御する」で説明しています。ランサムウェアは今や、根本的な復元力の問題と化しており、身代金を支払うか、さもなくば、ゼロからの再構築を迫られることになります。

エッジデバイス、ゼロデイ、徹底的な持続性

一般的なサイバー犯罪者がスピードの最適化に励む一方で、スパイ活動グループは、持続性を徹底的に追求しています。たとえば、UNC6201 や UNC5807 などの脅威クラスタは、エッジデバイスやコアネットワークデバイス（バーチャルプライベートネットワーク（VPN）やルーターなど）を意図的に標的にするようになってきていますが、その背景には、これらのデバイスには標準的なエンドポイント検出および対応（EDR）のテレメトリー機能が不足しているという事情があります。また、M-Trends 2026 によると、脆弱性が悪用されるまでの平均時間は推定で -7 日まで落ち込んでおり、パッチリリース前の悪用が頻発していることが伺えます。この傾向は、Google が近年指摘してきた内容（2024 年のゼロデイ攻撃増加について詳説した「脆弱性の状況: 2025 年のゼロデイを振り返る」や、「UNC6201 が Dell RecoverPoint for Virtual Machines のゼロデイ脆弱性を悪用」）と一致しており、こうした傾向やキャンペーンがいかに深刻であるかを物語っています。攻撃者は、ワークステーションやサーバーといった従来のソースに深く攻め入ることなく、ネットワークデバイスのネイティブなパケットキャプチャ機能を利用し、ネットワークを通過する機密データや平文の認証情報を直接傍受して、インテリジェンスを収集しています。

また、BRICKSTORM バックドアなどの独自のインメモリマルウェアをネットワークアプライアンスに直接デプロイすることで、標準的な修復作業やシステム再起動の影響を受けることなく持続的に定着します。これらのデバイスはオンボードストレージが最小になるように設計されているため、従来のセキュリティツールを利用できず、ファイルシステムやメモリのフォレンジック分析が非常に困難です。アーティファクトも限られるため、攻撃者の存在を確認したり、修復対象範囲を見極めたりしづらい状況が生まれています。さらに、この徹底的な持続性によって、可視性に重大な穴が生じます。たとえば、BRICKSTORM のように 400 日近くの滞留時間を達成している脅威は、標準的な 90 日間のログ保持ポリシーでは初期アクセスベクトルとして特定できず、被害の全容も完全に把握しきれません。

AI を用いた脅威の動向

2025 年の脅威動向を包括的に把握するには、攻撃者による AI の使用状況を知る必要があります。Google Threat Intelligence Group の継続的な調査により、攻撃ライフサイクルの加速を目的とした AI の活用が進んでいることが明らかになっています。たとえば、PROMPTFLUX や PROMPTSTEAL などのマルウェアファミリーは、検出を回避するため、実行中に大規模言語モデル（LLM）へのクエリを常時行っています。また、「蒸留攻撃」は、価値の高い ML モデルの独自ロジックおよび専門的なトレーニングデータを抽出して、知的財産を脅かします。M-Trends 2026 では、侵害された環境内で、AI が多用されていることが確認されています。たとえば、QUIETVAULT という認証情報窃取マルウェアは、標的コンピュータ上にローカルの AI コマンドラインツールがあるかどうかを調べ、事前定義されたプロンプトを実行して構成ファイルを探します。

このように急速に技術が進歩しているものの、2025 年の時点で、AI が侵害に直結しているとは結論付けられません。最前線の見解によると、ほとんどの侵入は、依然として人為的ミスやシステム上の欠陥に起因しています。それでもなお、Mandiant のレッドチームは AI を活用した攻撃の進化に備え、プロンプトインジェクションなどの AI を活用したテクニックを積極的に取り入れ、防御力を徹底的にテストしています。一方で、組織において AI 導入が進むのに伴い、開発者ツールチェーンが悪用されるといった特有のリスクが生じることを懸念し、Google は組織が Google セキュア AI フレームワーク（SAIF）の原則を採用するよう支援しています。AI モデル自体の保護に加えて、防御における AI の活用（セキュリティ運用の増強など）も支えていく方針です。AI とセキュリティについて詳しくは、最近公開されたホワイトペーパー「AI のリスクとレジリエンス: Mandiant スペシャルレポート」をご覧ください。

防御者向けの推奨事項

運用において真のレジリエンスを確立し、新しい手法を駆使する攻撃者を封じ込めるには、攻撃者に負けないスピードで行動する必要があります。M-Trends 2026 では実用的なアドバイスを幅広く提供していますが、ここではその一部を紹介します。

軽微なアラートを、重要な指標として扱う: 引き継ぎ時間が数秒に短縮されていることを鑑み、セキュリティチームは対応プレイブックを新たに策定し直す必要があります。日常的に発生するマルウェアアラートを、二次侵害の重要な兆候として捉え、インタラクティブなキーボード操作が始まる前に確実に修復するようにしましょう。
重要なコントロールプレーンを分離する: 仮想化プラットフォームと管理プラットフォームを「ティア 0」のアセットとして扱い、アクセスを厳格に制限する必要があります。復元機能の破壊に対抗するには、バックアップ環境を会社の Active Directory ドメインから切り離し、不変ストレージを使用するようにします（この種の攻撃に対する防御については、「破壊的攻撃に事前に備え、セキュリティを強化する方法: 2026 年版」をご覧ください）。
継続的な ID 検証に移行する: 対話型のソーシャルエンジニアリングでは、従来の MFA が回避されることがよくあります。したがって、組織において厳格な最小権限を適用すること、SaaS のインテグレーションを定期的に監査すること、すべての SaaS アプリケーションを中央の ID プロバイダ（IdP）経由でルーティングすることが重要です。
静的 IOC から行動異常検出に移行する: 攻撃者がインフラストラクチャを次々と変え、独自のインメモリマルウェアをデプロイするようになった今、静的なセキュリティ侵害インジケーター（IOC）のみに頼るのではもはや十分ではありません。防御側は、行動ベースの検出モデルを実装して、確立済みベースラインからの逸脱や異常なアクティビティを検出できるようにする必要があります。具体的には、エッジデバイスへの不正アクセスや、異常な API 一括オペレーション、SaaS 統合トークンの不審な使用などに注意が必要です。
可視性を拡大し、ログ保持期間を延長する: エコシステム全体に、高度な脅威検出の仕組みをデプロイする必要があります。たとえば、複数年にわたる侵入を可視化するためには、ログの保持ポリシーを標準の 90 日間よりもはるかに長くする必要があります。また、重要なネットワークデバイスのログ（特にアプリケーションログと管理ログ）やハイパーバイザレベルのテレメトリー情報を、一元化された長期保存ストレージに転送すれば、高度なアクターに狙われがちな箇所も含めて徹底的に可視化できます。

脅威に対応するための準備

Mandiant のミッションは、あらゆる組織をサイバー脅威から保護し、万全な態勢を維持できるように支援することです。このミッションの中核となっているのが、M-Trends 年次レポートであり、17 年間にわたり、可視性の危険なギャップを埋めるのに役立つ最前線の知識を共有し続けています。

サイバー脅威の動向、ならびに、変化し続ける状況にどのように対応すべきかについて詳しくは、M-Trends 2026 の以下のリソースをご覧ください。

M-Trends 2026 レポートをダウンロードして、最前線のデータについて詳しくご確認ください。
M-Trends 2026 Executive Edition には、データ、傾向、主な推奨事項がまとめられています。
M-Trends 2026 ウェブセミナーシリーズの第 1 弾にご登録ください。レポートで取り上げているデータや、トピック、推奨事項について詳しくご説明する予定です。
Google Cloud Security Podcast の M-Trends 2026 特集で、調査結果およびレポートの作成方法について聴くことができます。

- Google Cloud、Mandiant コンサルティング、バイスプレジデント、Jurgen Kutscher

AI インフラストラクチャとしての Kubernetes: Google Cloud、llm-d、CNCF

Fri, 03 Apr 2026 01:00:00 +0000

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

Google Cloud は、大規模な基盤モデルのビルダーや AI ネイティブ企業の膨大なニーズに応えることを、当社の AI インフラストラクチャ戦略の最優先事項としています。生成 AI の利用がミッションクリティカルな本番環境へと移行する中、このようなイノベーターは、複雑なオーケストレーションの課題を克服し、エージェント主導の未来を推進できる、動的かつ絶え間なく効率的なインフラストラクチャを必要としています。

こうした状況を鑑み、このたび、llm-d が Cloud Native Computing Foundation（CNCF）のサンドボックスプロジェクトとして正式に承認されたことを大変嬉しく思います。Google Cloud は、Red Hat、IBM Research、CoreWeave、NVIDIA とともに、llm-d の創設メンバーとして貢献できることを誇りに思います。私たちは、業界を定義する明確なビジョン「あらゆるモデル、あらゆるアクセラレータ、あらゆるクラウド」の下に団結しています。

この貢献は、オープンソースのイノベーションにおける Google の長年のリーダーシップを裏付けるものです。私たちはまた、Linux Foundation の信頼できる管理の下、分散 AI 推論の未来が、閉ざされた環境ではなくオープンスタンダードに基づいて構築されるよう支援しています。これにより、基盤モデルのビルダーは、ベンダーに縛られることなくモデルをグローバルにデプロイできるという確信を得られるとともに、これらのオープンテクノロジーの実装を高度に最適化したうえで Google Cloud で直接行えるようになります。

推論のための Kubernetes の強化

Kubernetes は、オーケストレーションの業界標準として揺るぎない地位を確立しています。強固な基盤を提供しますが、元々は、LLM 推論のために構築されたものではなく、高度にステートフルで動的な要求には対応できませんでした。GKE Inference Gateway は、こうした新しいタイプのワークロードに対応するために Kubernetes を進化させたもので、単純なロードバランシングをはるかに超えるネイティブ API を提供します。このゲートウェイの内部では、スケジューリングインテリジェンスのために llm-d Endpoint Picker（EPP）を活用しています。このシステムでは、ルーティングの決定を llm-d に委任することで、リアルタイムの KV キャッシュヒット率、処理中のリクエスト数、インスタンスキューの深さを考慮した多目的ポリシーを適用し、各リクエストを処理に最適なバックエンドにルーティングします。

大規模に運用する基盤モデルのビルダーにとって、こうしたモデル対応のルーティングがもたらす現実世界への影響は画期的です。最近、Google の Vertex AI チームは本番環境でこのアーキテクチャを検証し、脆弱なカスタムスケジューラに依存することなく、予測が非常に難しいトラフィックを処理できることを証明しました。Qwen Coder を使用したコンテキストを多用するコーディングタスクでは、最初のトークンまでの時間（TTFT）のレイテンシが 35% 以上短縮されました。また、研究目的に DeepSeek を使用してバースト性が高く確率的なチャットワークロードを処理した場合には、P95 テールレイテンシが 52% 改善され、深刻な負荷変動を効果的に吸収できました。特に重要なのは、このゲートウェイのルーティングインテリジェンスにより、Vertex AI の接頭辞キャッシュヒット率が 35% から 70% に倍増したことであり、これにより、再計算のオーバーヘッドとトークンあたりの費用が大幅に削減されました。

インテリジェントなルーティングに加えて、マルチノード AI デプロイをオーケストレートするには、堅牢な基盤となるプリミティブが必要です。そのため、Google では Kubernetes LeaderWorkerSet（LWS）API の開発を主導しています。LWS により、llm-d は広範なエキスパート並列処理をオーケストレートし、計算負荷の高いプリフィルフェーズとメモリ負荷の高いデコードフェーズを、個別にスケーリング可能な Pod に分離できます。業界で広く採用されている LWS は、今では、急速に拡大する本番環境の AI ワークロードのフットプリントをオーケストレートし、グローバル規模で TPU と GPU の大規模なフリートを管理しています。このオーケストレーションを補完するものとして、Google は最近、Cloud TPU 向けに vLLM をネイティブに拡張しました。PyTorch と JAX の統合バックエンドに加え、Ragged Paged Attention v3 などの革新的な機能を備えたこのインテグレーションにより、昨年初めにリリースした最初のバージョンと比較して、スループットが最大 5 倍向上しました。Google Cloud TPU や NVIDIA GPU のどちらでスケールする場合でも、これらの進歩により、最先端の AI サービングが高度に最適化され、アクセラレータに依存しない機能として維持されます。

次世代の AI インフラストラクチャを共同で構築

究極の AI インフラストラクチャを構築するには、クラウドネイティブな Kubernetes オーケストレーションと最先端の AI 研究との間のギャップを埋める必要があります。本番環境レベルの生成 AI への移行には、信頼性と透明性を備えたエンジンが必要であり、可能性の限界を押し広げる AI / ML リーダーとの緊密なコラボレーションも求められます。

私たちは、Linux Foundation、CNCF、PyTorch Foundation、その他のオープンソースコミュニティとともに、次世代の AI インフラストラクチャを構築できることを大変嬉しく思っています。「well-lit paths」（現実的な負荷の下でエンドツーエンドにテストされた、実証済みで再現可能なブループリント）を確立することで、高性能な AI がオープンで誰もがアクセスできるエコシステムとして発展し、境界のないイノベーションを促進できるようにしています。

AI 推論のオープンな未来を一緒に形作りましょう。大規模基盤モデルのビルダー、AI ネイティブ企業、プラットフォームエンジニア、AI 研究者の皆様の参加を心よりお待ちしております。

「well-lit paths」を確認する: llm-d ガイドを参照し、ご自身のインフラストラクチャに SOTA 推論スタックを今すぐデプロイしましょう。
詳細: 公式ウェブサイト（https://llm-d.ai/）をご覧ください。
ご協力のお願い: Slack のコミュニティに参加し、GitHub リポジトリ（https://github.com/llm-d/）での活動にご協力ください。

llm-d の CNCF サンドボックスプロジェクトへの参加をお待ちしております。皆様とともにこのエンジンを発展させていくことを楽しみにしています。

- プロダクトマネージャー、Sean Horgan

- シニアクラウドデベロッパーアドボケイト、Abdel Sghiouar

分散 AI エージェントの構築

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

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

率直に言って、1 回だけ動作する AI エージェントを構築するのは簡単です。しかし、本番環境で確実に動作する AI エージェントを構築し、既存の React や Node.js アプリケーションと統合する場合は、まったく別の話です。

（説明は省略して、コードに直接移動したい場合は、GitHub のコース作成エージェントのアーキテクチャをご覧ください。）

身近な例で考えてみましょう。トピックを調査し、コンテンツを生成して、それを評価するという複雑なワークフローがあるとします。このワークフローを、1 つの巨大な Python スクリプトまたは大きなプロンプトに詰め込んだとしましょう。ローカルマシンでは正常に動作しましたが、スマートな外観のフロントエンドに接続しようとすると、厄介なことになります。レイテンシが急上昇し、デバッグが困難で、スケールするためにモノリス全体の複製が必要となります。

一方、AI に対応するために、アプリケーション全体を書き換える必要がないとしたらどうでしょうか。プラグを差し込むだけで使えるとしたら？

この投稿では、オーケストレーターパターンという優れた方法について説明します。具体的には、すべてを請け負う強力なエージェントを 1 つだけ作るのではなく、複数の特化した分散マイクロサービスから成るチームを構築します。このアプローチにより、モノリスの書き換えに悩まされることなく、強力な AI 機能を既存のフロントエンドアプリケーションに直接統合することが可能となります。

そのために、Google の Agent Development Kit（ADK）を使ってエージェントを構築し、Agent-to-Agent（A2A）プロトコルによって複数のエージェントを接続して相互通信し、Cloud Run 上でスケーラブルなマイクロサービスとしてデプロイします。

分散エージェントを使用する理由（フロントエンドチームに感謝される理由）

すでに完成された状態の Next.js アプリケーションがあるとします。これに、「コース作成ツール」という機能を追加したいとしましょう。

そのためにモノリスエージェントを構築すると、フロントエンドは、長時間かかる単一プロセスがすべて完了するまで待たされることになります。調査部分が滞ると、リクエスト全体がタイムアウトになります。また、個々のエージェントを必要に応じてスケールするといったこともできません。たとえば、評価エージェントがより多くの処理能力を必要とする場合、評価エージェントだけでなく、すべてのエージェントをスケールアップすることになります。

これに対し、分散オーケストレーターパターンを使用すれば、スケーラビリティと柔軟性が得られます。

シームレスなインテグレーション: フロントエンドは 1 つのエンドポイント（オーケストレーター）と通信し、オーケストレーターがバックグラウンドで複雑な処理を管理します。
個別にスケーリング: 評価ステップに時間がかかる場合は、そのサービスだけを 100 インスタンスにスケールアップし、調査サービスは小規模のままにできます。
モジュール式: 高パフォーマンスのネットワーキング部分を Go で、データサイエンス部分を Python で記述できます。これらの通信には HTTP を使用します。

全体的な設計: コース作成アプリ

では、コース作成システムを構築しましょう。以下の 3 つのスペシャリストに分けて考えます。

調査担当: 情報を掘り起こすスペシャリスト。
評価担当: 品質を保証する QA スペシャリスト。
オーケストレーター: 作業間の調整を行い、フロントエンドと通信するマネージャー。

ステップ 1: スペシャリスト（リサーチャー）の配備

まず、調査の担当者が必要です。ADK を使って、Google 検索の部分のみを担当するエージェントを構築しましょう。

code_block: <ListValue: [StructValue([('code', '# researcher/app/agent.py\r\nfrom google.adk.agents import Agent\r\nfrom google.adk.tools import google_search\r\n\r\nresearcher = Agent(\r\n name="researcher",\r\n model="gemini-2.5-flash",\r\n description="Gathers information on a topic using Google Search.",\r\n instruction="""\r\n You are an expert researcher. Your goal is to find comprehensive information.\r\n Use the `google_search` tool to find relevant information.\r\n Summarize your findings clearly.\r\n """,\r\n tools=[google_search],\r\n)'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f9a984e84c0>)])]>

ご覧のように、とても簡単です。このエージェントは、コースやフロントエンドについては関知しません。調査のみを行います。

ステップ 2: 評価担当者（構造化されたデータ出力）

エージェントからの長ったらしい説明はいりません。コード側で判断しやすいよう、合格（pass）または不合格（fail）の厳密な評価が必要です。Pydantic を使って、このデータ規定を適用しましょう。

code_block: <ListValue: [StructValue([('code', '# judge/app/agent.py\r\nfrom pydantic import BaseModel, Field\r\nfrom typing import Literal\r\n\r\nclass JudgeFeedback(BaseModel):\r\n status: Literal["pass", "fail"] = Field(\r\n description="Whether the research is sufficient (\'pass\') or needs more work (\'fail\')."\r\n )\r\n feedback: str = Field(\r\n description="Detailed feedback on what is missing."\r\n )\r\n\r\njudge = Agent(\r\n name="judge",\r\n model="gemini-2.5-flash",\r\n description="Evaluates research findings.",\r\n instruction="""\r\n You are a strict editor. Evaluate the findings.\r\n If they are missing key info, output status=\'fail\' and provide feedback.\r\n """,\r\n output_schema=JudgeFeedback, # Enforce the contract!\r\n)'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f9a984e8fd0>)])]>

これで、評価担当者が JSON で話すようになり、アプリケーションロジックはそれを信頼できます。

ステップ 3: 共通言語（A2A プロトコル）

ここでマジックを使いましょう。A2A プロトコルを使って、これらのエージェントをウェブサービスとしてラップします。エージェントの共通言語のようなものとお考えください。エージェントは機能を説明し（agent.json）、標準の HTTP で通信します。

code_block: <ListValue: [StructValue([('code', '# researcher/app/server.py\r\nfrom fastapi import FastAPI\r\nfrom a2a.server.apps import A2AFastAPIApplication\r\nfrom app.agent import app as adk_app\r\n\r\n# ... setup runner ...\r\n\r\n# Create the A2A App wrapper\r\na2a_app = A2AFastAPIApplication(agent_card=agent_card, http_handler=request_handler)\r\n\r\napp = FastAPI(lifespan=lifespan)\r\n\r\n# Register routes: /.well-known/agent.json and /rpc\r\na2a_app.add_routes_to_app(app)'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f9a984e8790>)])]>

これで、リサーチャー（ポート 8000 で実行されるマイクロサービス）を配備できました。このサービスを、オーケストレーターなど、あらゆるものから呼び出すことが可能です。

ステップ 4: オーケストレーターパターン

では、すべてを組み合わせましょう。オーケストレーターは、請負業者のようなものです。つまり、自分で調査を行わず、リサーチャーを雇います。自分で判断を下さず、評価担当者に尋ねます。

重要な点は、フロントエンドはこのエージェントのみを識別できればよいということです。

code_block: <ListValue: [StructValue([('code', '# orchestrator/app/agent.py\r\nfrom google.adk.agents import LoopAgent, SequentialAgent\r\nfrom google.adk.agents.remote_a2a_agent import RemoteA2aAgent\r\n\r\n# Connect to the remote Researcher service\r\nresearcher = RemoteA2aAgent(\r\n name="researcher",\r\n agent_card="http://researcher-service:8000/.well-known/agent.json",\r\n description="Gathers information on a topic."\r\n)\r\n\r\n# Connect to the remote Judge service\r\njudge = RemoteA2aAgent(\r\n name="judge",\r\n agent_card="http://judge-service:8000/.well-known/agent.json",\r\n description="Evaluates research findings."\r\n)\r\n\r\n# The Orchestrator manages the loop\r\nresearch_loop = LoopAgent(\r\n name="research_loop",\r\n sub_agents=[researcher, judge, escalation_checker],\r\n max_iterations=3,\r\n)\r\n\r\n# The full pipeline\r\nroot_agent = SequentialAgent(\r\n name="course_creation_pipeline",\r\n sub_agents=[research_loop, content_builder],\r\n)'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7f9a984e8cd0>)])]>

オーケストレーターが複雑な処理（再試行、ループ、状態管理）を担当するため、フロントエンドはクリーンかつシンプルに保たれます。

デプロイ:「食料品店」モデル

このシステムを Cloud Run にデプロイすることを、私は「食料品店」モデルと呼んでいます。チェックアウトの列（リサーチャーのタスク）が長くなっても、新しい店舗を建設する必要はありません。レジを増やせばいいだけです。Cloud Run は、調査の負荷増大に対応するために調査サービスのみをスケールし、評価サービスはそのまま保たれます。

注意事項、セキュリティ上の配慮

もちろん、大いなる力には大きな責任が伴います（そして、セキュリティチェックが必要となります）。

認証: このデモでは、エージェントはオープンな HTTP を介して通信しています。本番環境では、このアクセスを制限する必要があります。mTLS、OIDC、または API キーを使用して、オーケストレーターのみがリサーチャーと通信できるようにします。
レイテンシ: ホップごとに時間が追加されます。オーケストレーターパターンは、詳細レベルの頻繁なインタラクションではなく、ざっくりとしたタスク（「このトピックを調査して」など）に使用するようにしましょう。
エラー処理: ネットワークにはエラーがつきものです。オーケストレーターには、タイムアウトと再試行を適切に処理できるような堅牢性が必要です。

構築を始めるにあたって

あらゆる作業を請け負う 1 つの巨大なエージェントを構築するのはやめましょう。オーケストレーターパターンと分散マイクロサービスを使用することで、スケーラブルで保守が容易な AI システムを構築できるだけでなく、既存のアプリとスムーズに連携できるというメリットも得られます。

コードについては、GitHub のコース作成エージェントのアーキテクチャで詳細をご確認ください。

準備ができたら、Cloud Run、ADK、A2A を使ってさっそくエージェントチームを結成しましょう。

- AI デベロッパーリレーションズエンジニア、Amit Maraj

DRA: 動的リソース割り当てが切り開く Kubernetes デバイス管理の新時代

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

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

大規模言語モデル（LLM）の爆発的な普及により、GPU や TPU などの高性能アクセラレータの需要が高まっています。組織が AI 機能を拡大させる中で、コンピューティングリソースの不足が主要なボトルネックとして浮上することがあります。すべての GPU と TPU のサイクルを効率的に管理することは、もはや推奨事項ではなく、運用上の必要事項となっています。

Kubernetes は、企業が LLM を実行する際の事実上の標準プラットフォームになりつつあります。今週開催された KubeCon Europe において、NVIDIA は GPU 用の動的リソース割り当て（DRA）ドライバを、Google は Tensor Processing Unit（TPU）用の DRA ドライバをそれぞれ Kubernetes コミュニティに寄贈しました。このことは、より広範なコミュニティの育成とイノベーションの加速を実現し、Kubernetes が最新のクラウド環境に対応して AI ワークロードのポータビリティを向上させることにつながります。DRA は Google Kubernetes Engine（GKE）でも一般提供されています。このブログ記事の残りの部分では DRA について掘り下げ、DRA が構築された理由、DRA でできること、DRA の使用方法について説明します。

静的なインフラストラクチャからの脱却

長年にわたり、ハードウェアアクセラレータを使用するには、Kubernetes のデバイスプラグインフレームワークを利用するのが標準的な方法でした。ただし、デバイスプラグインでは、ハードウェア要件を単純な整数（例: gpu: 1）としてしか表現できないため、フラクショナル GPU は使用できません。これでは、現代の複雑なワークロードに求められる微妙できめ細かな調整を行うには不十分です。また、デバイスプラグインでは、Pod のスケジューリングに先立って、クラスタにアクセラレータを事前プロビジョニングさせておく必要があります。

Kubernetes におけるリソース管理の新標準である DRA は Kubernetes OSS 1.34 で「安定版」のステータスに昇格しました。DRA は、ハードウェアの処理方法において、静的な割り当てから柔軟なリクエストベースのモデルへの移行というパラダイムシフトを体現しています。これにより、次のような課題が解決されます。

手動によるノードの固定が不要: デバイスプラグインフレームワークでは、アプリオペレーターは、特定のハードウェアを搭載したノードを自分で調べてから、nodeSelector またはアフィニティを使用して、Pod がそのノードに配置されるようにする必要がありました。DRA は、スケジューラが特定のハードウェア機能をネイティブに認識できるようにすることで、このプロセスを自動化します。リクエストに基づいてワークロードに適したノードを検出するため、ユーザーがクラスタのトポロジをマッピングする必要はありません。
柔軟なパラメータ化: デバイスプラグインの「全か無か」のアプローチとは異なり、DRA では、ResourceClaim を使用して、最小 VRAM 量、特定のハードウェアモデル、相互接続要件などの特定の要件を定義できます。これにより、高価なハードウェアをよりきめ細かく効率的に使用できます。
DeviceClass を介したハードウェアの抽象化: DRA は、ハードウェアの「ブループリント」として機能する DeviceClass を導入します。プラットフォーム管理者は、デベロッパーが名前でリクエストするクラス（例: high-memory-gpu や low-latency-fpga）を定義できます。これにより、基盤となるハードウェアアドレスからワークロードのニーズが切り離されます。これは、スケジューラがワークロードの要件と利用可能なハードウェアインベントリのマッチングを行うことを可能にします。

詳細解説: DRA の仕組み

DRA の中核をなすのは ResourceSlice と ResourceClaim です。これら 2 つの主要な構成要素は、ハードウェアインベントリとワークロード要件を分離します。これらは、Kube-scheduler が適切な意思決定を行い、より柔軟なリソースプールを実現するために使用する入力です。

ResourceSlice: 可用性の記述

ResourceSlice API は、基盤となるハードウェアの機能と属性をリソースドライバがクラスタに公開するために使用されます。デバイスプラグインが単純なラベルを使用することでデバイスの詳細を覆い隠しがちであるのと対照的に、ResourceSlice は利用可能なアセットを忠実に記述します。これにより、ドライバは各デバイスに関する以下のような詳細情報を報告できます。

容量: 合計メモリ、コア数、または特殊なコンピューティング単位数
属性: アーキテクチャ、バージョン、PCIe ルートコンプレックスまたは NUMA ノード

ResourceClaim: 要件の定義

ResourceClaim API を使用すると、AI エンジニアはアプリケーションを正常に実行するために必要なものを正確に定義できます。ResourceSlice API がデバイスの詳細を公開するため、開発者は一般的なリクエストにとどまらず、次の項目に基づく要件の指定を行うことができます。

属性ベースの選択: 特定のモデルを指定する代わりに、ユーザーは「40 GB 以上の VRAM を備えた GPU」という風にリクエストできます。
複雑な制約: DRA はデバイス間の制約をサポートします。たとえば、ハイパフォーマンスコンピューティングジョブでは、レイテンシを最小限に抑え、スループットを最大化するために、GPU と NIC の両方が同じ PCIe ルートコンプレックスに接続されているという要件のもとに、GPU と NIC をリクエストできます。

能力ベースのアプローチによるスマートなスケジュール設定

DRA は、「何」（ResourceClaim）を「どこ」（ResourceSlice）から切り離すことで、デバイスのマッチングの負担をユーザーから Kube-scheduler に移します。

以前までは、ユーザーは適切なハードウェアに Pod を配置するために、手動のノードセレクタや taint に頼らざるを得ないことがほとんどでした。DRA を使用すると、スケジューラはデバイスの属性とクラスタのトポロジを全体的な視点から把握できるようになります。これにより、より「流動的な」リソースプールが可能になります。スケジューラは、利用可能なすべてのスライスをクレームの特定の基準に基づいて評価し、静的なラベルではなく実際のハードウェアの可用性に基づいて配置を最適化できます。

この能力ベースのアプローチによって利用可能なハードウェアのうち最適なものにワークロードを確実に割り当てられるようになり、リソース使用率とアプリケーションパフォーマンスの両方が向上します。

DRA の動作を確認するには、Google デベロッパーフォーラムのこちらのブログ記事をご覧ください。このブログ記事では、環境設定、GKE クラスタの作成、ドライバのインストール、レプリカのスケーリングなど、カスタム ComputeClass を使用して GPU をスケールする方法を紹介しています。

1.35 のリリースでは、AI / ML ワークロードと最新のユースケースの新しい標準を確立するために、Kubernetes AI Conformance プログラムが作成されました。DRA のサポートは、この新しい基準の要となるため、最初の必須要件として特定されました。

ぜひお試しください

Kubernetes ワークロードがより複雑でミッションクリティカルになるにつれて、柔軟でインテリジェントかつ使いやすいリソース管理の実現が重要になっています。GKE の DRA は、要求の厳しい動的な環境でハードウェアリソースを最適化する際に手作業や当て推量に頼る必要性を排除します。DRA の詳細と利用方法については、以下のリソースをご覧ください。

- シニアソフトウェアエンジニア、Morten Torkildsen

- シニアプロダクトマネージャー、Bo Fu

Google の企業向けブラウザでセキュリティを一層強化する 5 つの方法

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

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

RSA には、セキュリティ業界の多くのエキスパートが集います。常に変化するリスク環境をサポートし続けるソリューションプロバイダであれ、業界で新しいベストプラクティスを共有するリサーチコミュニティであれ、社内のセキュリティ強化のために知識の拡大に励むセキュリティ担当者であれ、こと企業セキュリティに関しては、次から次へと把握すべき最新情報が尽きません。この最先端の情報共有の場で、Google は、セキュアな企業向けブラウジングソリューションを紹介し、急速に進化する AI 時代に企業データを保護する方法をお客様にご体験いただいています。

また、Chrome とコアを一層強化し、Chrome Enterprise にさらに多くの保護をもたらす新しい機能もいくつかご紹介しています。ここでは、ブラウザの継続的な堅牢化からダウンロード管理の強化まで、BYOD ユーザーや契約社員も含む、すべての従業員の保護に役立つ新機能についてご案内します。ぜひ最後までお読みください。

セッションハイジャックと Cookie の盗難の防止: Chrome は昨年、デバイスにバインドされたセッション認証情報（DBSC）を導入し、ユーザーセッションの侵害防止に向けて大きく前進しました。セッション Cookie を特定のデバイスにバインドすることで、「セッションハイジャック」の試みを効果的に無効化します。高度な攻撃者がユーザーのセッション Cookie を盗むことに成功したとしても、その Cookie は元の認証済みデバイス以外では役に立たなくなるため、企業のユーザーアカウントとデータは安全に保たれます。このアプローチは、ブラウザのセキュリティ強化の重要な基盤となり、すべてのユーザーのセキュリティに役立つだけでなく、企業全体のセキュリティにも大きく寄与します。
保存データの保護: ユーザーがブラウザを閉じてもセキュリティが不要になるわけではありません。使用中のデータ同様、残されたデータを保護することも重要です。Chrome では、新しいブラウザキャッシュ暗号化機能により、デバイスのハードドライブに保存されたキャッシュが完全に暗号化されます。つまり、ノートパソコンの紛失や盗難があった場合、キャッシュに保存されたデータが第三者によって不正に再構築または悪用されることはありません。組織と従業員の両方に安心をもたらす機能です。
情報窃取型マルウェアの無効化:「情報窃取型」マルウェアの増加により、悪意のあるアプリケーションから機密性の高いブラウザデータを保護することの重要性がかつてないほど高まっています。そこで Chromeは、アプリケーションにバインドされた暗号化により、不正なソフトウェアがブラウザを掘り下げてパスワードや認証情報を抽出することを防ぐ鉄壁の防御補強機能を備えました。ブラウザデータへのアクセスをブラウザ自体に限定することで、マルウェアによるデータ侵害のリスクを大幅に軽減します。
企業データのダウンロード制御を強化: 企業システムが周辺環境のセキュリティを維持するには、クラウドやウェブからローカルデバイスへのデータの移動をきめ細かく制御する必要があります。Chrome では、ダウンロード管理機能が強化され、ダウンロードしたファイルの保存場所に関するより厳格なポリシーの設定が可能になりました。これにより、IT チームやセキュリティチームは、Chrome のダウンロードを Google ドライブに保存することを義務付けるルールを設定できます。この機能は、まもなく Microsoft OneDrive でも利用できるようになります。これは、ハイブリッド環境で従業員のセキュリティを確保するために特に重要で、管理対象デバイスはもちろん、BYOD ユーザーや提携先のハードウェアにも堅牢なデータ損失防止（DLP）を適用できます。

5. 技術パートナーエコシステムによる安全なアクセスの推進: 組織で安全なアクセスを保つため、特に管理対象外デバイスのアクセスに対応するため、企業はすでに環境全体でさまざまなソリューションに投資しています。Chrome Enterprise でも、主要セキュリティソリューションプロバイダと継続的に連携を深め、企業向けのフルスタックセキュリティアプローチをさらに強化しています。たとえば、Citrix Secure Access と Chrome Enterprise の機能を組み合わせると、キーロギング防止などの高度な専用保護機能を適用しながら、SSH や RDP のワークロードに安全にアクセスできます。また、Chrome Enterprise は、ID ソリューションの Okta と提携し、Okta のお客様にアンチウイルス補足シグナルを提供することでアクセス決定をサポートしています。さらに、Chrome Enterprise のリモートコマンド（Cookie とキャッシュの消去など）は、Okta などのサードパーティプロバイダによって管理されているプロファイルにも拡張され、各ユーザーにご利用いただけるようになっています。

Chrome Enterprise、および高度な企業向けブラウジング保護について詳しくは、Chrome Enterprise のウェブサイトをご覧ください。

- Chrome Enterprise、シニアプロダクトマネージャー、Niamh Cunningham

- Google Cloud Security、グループプロダクトマネージャー、Christopher Altman

読み取りのスケーラビリティを合理化する Cloud SQL の自動スケーリングを備えた読み取りプール

Wed, 01 Apr 2026 02:10:00 +0000

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

データベースから頻繁に読み取りを行うアプリケーションの一般的なパターンは、読み取り負荷の高いワークロードをリードレプリカにオフロードすることです。これにより、アプリケーションをスケールしても、プライマリデータベースインスタンスでの重要な書き込みオペレーションに影響が及ぶことはありません。しかし、このような読み取り負荷の高いワークロードでは、単一のリードレプリカの容量を簡単に超えてしまう可能性があります。デベロッパーはロードバランサの背後に複数のレプリカを手動で実装できますが、この方法は複雑で、保守とスケーリングが困難です。

Cloud SQL は、MySQL と PostgreSQL の読み取りプールを使用して、読み取りをスケールするための簡素化されたフルマネージドソリューションを提供します。この機能を使用すると、単一の読み取りエンドポイントからアクセスできる複数のリードレプリカをプロビジョニングできるため、アプリケーションを変更することなく、リードレプリカを簡単に追加および削除できます。効率をさらに向上させるために、Google は最近、Cloud SQL の読み取りプールに自動スケーリングを導入しました。これにより、リアルタイムのアプリケーションニーズに基づいて読み取り機能が動的に調整されます。自動スケーリングを備えた読み取りプールは、 Cloud SQL Enterprise Plus エディションで一般提供されています。詳しくは、MySQL と PostgreSQL のドキュメントとリリースノートをご覧ください。

読み取りプールを使用する理由

プライマリインスタンスからレプリケートする読み取りプールを作成すると、Cloud SQL は 読み取りプールノードと呼ばれる複数のリードレプリカを自動的にプロビジョニングし、クエリをノードにラウンドロビン方式でディスパッチする単一のロードバランサ（読み取りエンドポイント）を作成します。1 つのプールには 1～20 個のノードを含めることができます。

読み取りプールは単一のエンティティとして管理されるため、運用上の負担が軽減されます。プールは同種のノードのセットを表します。データベースフラグ、VM タイプ、その他のパラメータの更新などの構成変更を行うと、その変更はプール内のすべてのノードに自動的に適用されます。また、ワークロードの変化に応じて、プールからノードの追加や削除ができるため、いつでもスケールアウトとスケールインが可能です。すべてのクエリは読み取りエンドポイントのロードバランサを通過するため、プール内のノードが更新、追加、削除されても、アプリケーションを再構成する必要はありません。

読み取りプールの自動スケーリングでスケーリングが容易に

読み取りプールは、ワークロードが変動するシナリオで真価を発揮します。Cloud SQL の読み取りプール向けの自動スケーリングの一般提供が開始されたことで、こうした変動の管理がさらに簡単になりました。

読み取りプールの自動スケーリングの主なメリットは以下のとおりです。

トラフィックの急増に対する自動管理: データベース接続または CPU 使用率に基づいてプールが最大 20 個のノードまで動的にスケールアップされるため、需要がピークに達してもアプリケーションの応答性を維持できます。
オペレーションの簡素化: 自動スケーリングは単一の読み取りエンドポイントと統合されているため、基盤となるノードが調整されても、アプリケーションは同じアドレスに接続されたままになります。
費用の最適化: トラフィックが少ない期間は自動的なスケールインによって、実際に使用したリソースに対してのみ料金が発生するため、オーバープロビジョニングによって発生する費用を回避できます。

Cloud SQL が読み取りプールで可用性を向上させる仕組み

ミッションクリティカルな信頼性を実現するように設計された Cloud SQL の読み取りプールは、可用性が高い読み取りワークロードの基盤となります。ノードを 2 つ以上維持することで、読み取りプールは 99.99% の可用性 SLA によってサポートされ、これにはメンテナンスのダウンタイムも含まれます。これを実現するために、Cloud SQL は次のように環境をインテリジェントに管理します。

読み取りプールにノードを追加する際、既存の接続は、既存のノードで中断することなく続行されます。新しい接続は新たに追加されたノードに割り当てられる場合があります。既存の接続が処理を完了すると、負荷はすべてのノード間で均等に分散されるようになります。
2 つ以上のノードを含む読み取りプールの場合、VM タイプやデータベースフラグを変更したり、その他の大半の構成更新を実行したりすると、読み取りプールはダウンタイムがほぼゼロで更新されます。
他の Cloud SQL インスタンスと同様に、Cloud SQL は読み取りプールインスタンスの基盤となるハードウェアの問題を自動的に検出して修復します。異常が検出されたノードは、ロードバランサのローテーションから削除され、それを置き換えるための新しいノードが作成されます。

自動スケーリングを備えた読み取りプールの有効化と使用

読み取りプールは、ワークロードが大きく変動する環境で優れた性能を発揮します。Cloud SQL の自動スケーリングでは、CPU 使用率やデータベース接続などの主要な指標の目標値を設定すると同時に、ノードの最小数と最大数を定義できます。

小売業界は良い例になります。トラフィックが、日々のサイクル、季節の変化、期間限定セールなどに基づいてよく変動するからです。こうしたピーク時に動的にスケールアウトし、需要が落ち着いたらスケールインすることで、オーバープロビジョニングされた環境のオーバーヘッドなしに、優れたカスタマーエクスペリエンスを提供できます。

Enterprise Plus エディションのインスタンスをすでに作成している場合は、そのインスタンスからレプリケートする読み取りプールを作成できます。次のコマンドは、2 つのノードを含む読み取りプールを作成し、自動スケーリングを有効にします。自動スケーリングは、CPU 使用率を 60% 前後で維持しながら、ノードを 2～10 個の間でスケールするように構成されています。

code_block: <ListValue: [StructValue([('code', 'gcloud sql instances create myautoscaledreadpool \\\r\n --tier=db-perf-optimized-N-4 --edition=ENTERPRISE_PLUS \\\r\n --instance-type=READ_POOL_INSTANCE \\\r\n --master-instance-name=myprimary \\\r\n --region=us-west1 \\\r\n --node-count=2 \\\r\n --auto-scale-enabled \\\r\n --auto-scale-min-node-count=2 \\\r\n --auto-scale-max-node-count=10 \\\r\n --auto-scale-target-metrics=AVERAGE_CPU_UTILIZATION=0.60'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9a984c3f40>)])]>

読み取りエンドポイントの IP アドレスは、Google Cloud コンソールでインスタンスを確認するか、gcloud CLI を使用して取得できます。この IP アドレスは、プールの存続期間中は変更されません。

既存の読み取りプールがある場合は、簡単に自動スケーリングを有効にできます。

code_block: <ListValue: [StructValue([('code', 'gcloud sql instances patch myreadpool \\\r\n --auto-scale-enabled \\\r\n --auto-scale-min-node-count=2 \\\r\n --auto-scale-max-node-count=10 \\\r\n --auto-scale-target-metrics=AVERAGE_DB_CONNECTIONS=100'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9a984c3eb0>)])]>

このコマンドは、ノードが 2～10 個の間で自動的にスケールされるように myreadpool を構成します。その際、ノードあたりの平均データベース接続数が最大 100 になるように調整されます。

自動スケーリングは、変動するワークロードのほとんどに推奨されますが、必要に応じてノード数を直接更新することで、読み取りプールを手動でスケールすることもできます。

code_block: <ListValue: [StructValue([('code', '# Manually scale out to 4 nodes\r\ngcloud sql instances patch myreadpool --node-count=4\r\n\r\n# Manually scale back in to 2 nodes\r\ngcloud sql instances patch myreadpool --node-count=2'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7f9a984c3dc0>)])]>

使ってみる

新しい自動スケーリング機能を備えた読み取りプールを使用することで、多数の読み取りレプリカの管理に伴う面倒な作業を回避できるほか、アプリケーションに必要な読み取り容量を必要に応じて提供でき、過剰な費用を回避できます。今すぐ始めるには、以下のリソースをご覧ください。

読み取りプールに関する Cloud SQL のドキュメント

読み取りプールについて（MySQL、PostgreSQL）
読み取りプールの作成と管理（MySQL、PostgreSQL）: gcloud CLI、Terraform、REST API のコマンド例を含む
読み取りプールの自動スケーリング（MySQL、PostgreSQL）: gcloud CLI、Terraform、REST API のコマンド例を含む

新しい Cloud SQL の無料トライアルにご登録ください。これは、新規および既存の Google Cloud ユーザーの皆様を対象とした、Cloud SQL（PostgreSQL および MySQL）が提供するプレミアムなエンタープライズグレードの機能をご利用いただくことを目的とした 30 日間の専用プログラムです。

- ソフトウェアエンジニア、Phil Sung

- プロダクトマネージャー、Shahzeb Farrukh

Cloud Blog JA

ID.me、1 億 6,000 万ユーザーに対応するスケーリングと運用リスクの軽減を同時に達成

追いつかないスピードで増える需要

1 億 6,000 万人の大切なお客様と当社のための新しいデータベース

AI トレーニングの目的は . . . AI との戦い？

1 つのログインであらゆるシステムにスムーズに対応

Google ADK、MCP、Cloud Run を使用して専門家向けコンテンツ用のマルチ エージェント システムを構築する - パート 1

学習内容

Dev Signal の概要

前提条件

プロジェクトのセットアップ

1. プロジェクトを初期化する

2. フォルダ構造

3. 依存関係を定義する

エージェント機能の構築: MCP ツール

ツールの構成

Reddit 検索（発見ツール）

Google Cloud ドキュメント（ナレッジツール）

画像生成ツール（Nano Banana MCP）

Nano Banana Pro サーバー ロジックの実装

サーバー エントリポイント（main.py）

生成ロジック（nano_banana_pro.py）

GCS アップロード ヘルパー（storage_utils.py）

データモデル（media_models.py）

ツールの依存関係（requirements.txt）

まとめ

Red Hat OpenShift on Google Cloud を移行およびスケールする新しい方法

Google Cloud インフラストラクチャによる費用の最適化

Google Cloud Cluster Services for Red Hat OpenShift のご紹介

Google Cloud コンソールでのクラスタの作成

Red Hat OpenShift Virtualization で VM とコンテナを同時に実行

始める

【先着特典あり】Next Tokyo 登録開始！7 月 30 日、31 日 東京ビッグサイト

革新的なアイデアを、AI とクラウドで実現しよう

先着 2,000 名様に早期登録特典

基調講演

ブレイクアウト セッション

Expo、Learning & Certification

入門、スペシャル セッション

開催概要

FM Logistic が AlphaEvolve を使って倉庫規模の「巡回セールスマン問題」を解決

AI に、もっと優れたアルゴリズムを書いてもらう

改善結果の評価

結果

最終的に勝ち残ったアルゴリズムの動作

次のステップ

Vertex AI に Veo 3.1 Lite と Veo の新しいアップスケーリング機能を導入

ワークロードに適した Veo モデルの選択

Veo の新しいアップスケーリング機能でアセットをアップスケール

Veo 3.1 Lite を今すぐお試しください

LLM 推論の効率的フロンティアに到達するための 5 つの手法

推論に効率的フロンティアがある理由

推論の 2 つの軸

フロンティアに到達する: 制御可能な 5 つの手法

ケーススタディ: Vertex AI がフロンティアに近づいた方法

まとめ

Google Cloud Partner Tech Influencer Challenge 2026 実施のご案内

Google Cloud Partner Tech Influencer Challenge 2026 参加ガイド

優秀コンテンツの発表

評価基準

Google Cloud Next 特集のお知らせ

エージェント型 AI の時代を支える Spanner のマルチモデルによる強み

相互運用性を備えたマルチモデル データベースの力

Spanner がもたらす AI 時代の優位性

AI をグローバル規模で成功へと導く企業

AI 搭載ツールが切り拓く、サステナブルなインフラとレポートの次なる潮流

Google がレポート作成に AI をどう活用しているのか

Equinix におけるサステナビリティ データレイクの構築

サステナビリティを設計段階から組み込む: Well-Architected Framework（WAF）の活用

アンビション ループ

AI リテラシーの新しい形: 学生デベロッパーを対象とした調査結果

調査

調査結果その 1: 24 時間 365 日、いつでも頼れる先生

調査結果その 2: 過度な依存に対する積極的な抵抗

調査結果その 3: AI の使いどころを心得ている

すべてを任せるのではなく、意図的に取り入れる

カスタマイズが肝

この調査結果が業界において意味すること

AI 時代のオープン プラットフォーム: GKE、エージェント、OSS のイノベーションを KubeCon EU 2026 で披露

Autopilot をすべてのお客様に

Google ADK、MCP、Cloud Run を使用して専門家向けコンテンツ用のマルチエージェントシステムを構築する - パート 1

Nano Banana Pro サーバーロジックの実装

サーバーエントリポイント（`main.py`）

生成ロジック（`nano_banana_pro.py）`

GCS アップロードヘルパー（`storage_utils.py）`

データモデル（`media_models.py`）

ツールの依存関係（`requirements.txt）`

【先着特典あり】Next Tokyo 登録開始！7 月 30 日、31 日東京ビッグサイト

ブレイクアウトセッション

入門、スペシャルセッション

相互運用性を備えたマルチモデルデータベースの力

Equinix におけるサステナビリティデータレイクの構築

アンビションループ

AI 時代のオープンプラットフォーム: GKE、エージェント、OSS のイノベーションを KubeCon EU 2026 で披露

Model Context Protocol: エージェントインターフェース

分散エージェントを使用する理由（フロントエンドチームに感謝される理由）

ステップ 4: オーケストレーターパターン