Cloud Blog JA

AlloyDB に追加されたグループ認証により、エンタープライズ規模の運用と AI エージェントのセキュリティを強化

Thu, 06 Aug 2026 03:00:00 +0000

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

データベースセキュリティは従来、開発者が求める緻密なアクセス制御と、数千もの個別データベースパスワードの管理に伴う運用オーバーヘッドとの間の「危ういバランス」に頼ってきました。AI エージェントのアクセス管理、静的認証情報のローテーション、従業員のオンボーディングとオフボーディングの処理、アクセスログの監査など、パスワードは依然として運用上の負担であり、潜在的なセキュリティの脆弱性となっています。

Google Cloud の目標は、データベースアクセスを透過的でセキュア、かつパスワード不要なものにすることです。

Google はその取り組みにおいて重要な一歩を踏み出します。このたび、AlloyDB の Identity and Access Management（IAM）グループ認証がプレビュー版で利用可能になりました。この機能により、エンタープライズワークロードに ID 主導のアクセス制御がもたらされます。

Cloud SQL のお客様は、すでにこの認証パターンを導入して大きな成果を上げており、今回のリリースにより、両サービスでセキュリティ体制が統一されることになります。

個々のスケールに関する問題

長年にわたり、Cloud SQL と AlloyDB は、ネイティブな IAM 認証を使用して、個々の Google Cloud ID をデータベースユーザーに直接マッピングしてきました。しかし、エンタープライズ規模においては、アクセスを個別に管理すると、複雑さが大幅に増す可能性があります。

グループベースの管理を行わない場合、数百のインスタンスと数千のユーザーにスケールすると、次のような課題が生じます。

オンボーディングのボトルネック: 新しいチームメンバーごとにデータベースユーザーのプロビジョニングが必要になります。
オフボーディングのリスク: 分散データベース環境全体で従業員のアクセス権を完全に削除するには、監査が複雑になる可能性があります。
ポリシーの逸脱: 開発、ステージング、本番環境のシステム間で同一の権限を維持すると、エラーが発生しやすくなります。

このような課題に直面すると、アプリケーション全体にサービスを提供するために、単一の強力なユーザーアカウントまたはサービスアカウントを使用したいという誘惑に駆られます。しかし、このような強力なアプリケーションアカウントのアクセスを単純化しすぎると、リスクにさらされ、詳細な監査機能が失われるという代償が伴います。

エージェント型 AI の未来を守る

規模に関する課題は、もはや人間のユーザーだけにとどまりません。組織がデプロイする AI エージェントの数が増えるにつれて、データベースの ID とアクセス制御の管理はより複雑になります。

AI エージェントが汎用の共有アカウントや広範なサービスアカウントを使用してデータベースに接続する場合、混乱した使節の問題を引き起こすリスクがあります。ユーザーの ID を引き継ぐ代わりに、過剰な権限を持つ認証情報を使用すると、エージェントは、アクションをリクエストしたエンドユーザーが閲覧を許可されている範囲を超えてデータにアクセスしたり、データを変更したりする可能性があります。さらに重要なことに、アクションが汎用サービスアカウントに紐付けられるため、監査ログから個別の責任の所在が失われてしまいます。

きめ細かい認証は、このリスクを軽減するのに役立ちます。エージェントはエンドユーザーの特定のアイデンティティと認証スコープをデータベース層まで引き渡すことができるため、クエリはユーザーに代わって実行され、データアクセスはエンドユーザーが許可されているオブジェクトのみに制限されます。

AI エージェントを介してユーザーグループ ID を AlloyDB に渡すことで、データベースはアクセスを承認し、正確な監査証跡を記録できます。

IAM グループ認証は、このアーキテクチャを簡素化します。セキュリティチームは、エージェントとユーザーの組み合わせごとにマイクロ権限を管理する代わりに、最大 200 個の機能的な Google グループ（financial-agents@company.com や regional-analysts@company.com など）を定義できます。Google Cloud のマネージドデータベースインフラストラクチャは、ユーザーのグループコンテキストを検証し、データベースまたはテーブルのレベルでデータアクセスが承認されるようにします。また、監査ログには、アクセスされたデータ、変更されたデータ、誰の代理として行われたかが正確に記録されます。

デジタルリーダーにとっての実証された価値

一元化された ID の原則を採用することで、すでに運用スピードを向上させている企業があります。大手プラットフォームポイントプログラムの Bilt は、Google の統合アプローチを使用して、大規模なデータベース環境のセキュリティ強化に役立てています。

「AlloyDB のグループベースの IAM と、自動化されたグループ管理および Privileged Access Manager（PAM）の権限を組み合わせることで、共有認証情報のリスクを完全に排除しました。データベースとロールのプロビジョニングは、初日から完全にテンプレート化されているため、エンジニアは必要なときに必要なデータにのみ安全にアクセスできます」と、Bilt の CTO である Kosta Krauth 氏は述べています。

パスワードレスアクセスのための統合ブループリント

今回のリリースにより、Google Cloud は Cloud SQL と AlloyDB の両方にわたるアクセス制御の統合アプローチを提供します。組織は、リレーショナルデータベースポートフォリオ全体に対して、標準化された多層防御アクセス戦略を適用できるようになりました。

IAM グループ認証を VPC Service Controls、組織のポリシー、IAM 条件、Private Service Connect などの機能と組み合わせることで、セキュリティチームは、人間のエンジニアによるアクセスか自律型 AI エージェントによるアクセスかを問わず、データベースアクセスが、検証済みの企業 ID とセキュアなネットワーク境界にバインドされるようにすることができます。

ゼロトラストデータベースの未来に向けて

セキュリティによって、エンジニアリングの速度とコンプライアンスの間に妥協が生じるべきではありません。AlloyDB と、Cloud Identity および Workforce Identity 連携を統合することで、データベース管理の摩擦を解消し、よりセキュアなアーキテクチャの実装を支援します。

この機能を今すぐお試しになり、グループベースのデータベースロールを設定する方法をご確認ください。セキュリティとコンプライアンスに関するその他の推奨事項とベストプラクティスについては、ドキュメントをご覧ください。

- プロダクトマネージャー、Bjoern Rost

- プロダクトマネージャー、Alok Srivastava

The Blueprint: Voicify が AI を活用した注文体験を顧客にとって満足度の高いものに

Thu, 06 Aug 2026 02:10:00 +0000

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

「The Blueprint」へようこそ。今回始まったこの特集では、最新の AI とクラウドテクノロジーを使用して業界共通の課題や個別の課題に対処する Google Cloud のお客様の取り組みをご紹介します。仕事でイノベーションを目指す皆さまの着想の一助になれば幸いです。

2018 年に設立された Voicify は、すべての通話をシームレスで魅力的な体験に変えることを目標として、従来の電話の概念を一変させています。

課題:

2018 年に Voicify を創業したとき、当社のビジョンは、組織が、電話やチャットなどのあらゆるチャネルで、信頼性が高く、実用的で、技術的な基盤に基づく音声駆動型アシスタントを構築できるよう支援することでした。しかし、パンデミックによってすべてが変わりました。

当社は、主に飲食業界と医療業界の電話のユースケースに焦点を移しました。これらの業界では当時、通話量と人員配置が大きな課題となっていました。飲食店では、電話の最大 20% に応答できず、その結果注文を失う可能性がありました。また、医療機関では、予約情報を診療管理システムに統合する際に、情報の精度を 100% 維持しながら多くの通話に対応するのに苦労していました。その際、専門的な目的別 AI アシスタントが、企業が優れたサービスを大規模に維持するための鍵であることに気づきました。

成功を収めるには、4 つの主要な課題を克服する必要がありました。

トランザクションの精度: 音声アシスタントは、POS システムや診療管理システムに対する複雑な顧客リクエストを 100% の精度で推論する必要がありました。
トラフィックの急増への対応: 飲食店や医療機関では（極端な）トラフィックの急増がよく見られますが、費用を抑え、カスタマーサービスを維持するには、LLM の使用量を正確にプロビジョニングする必要があります。
レイテンシ: アシスタントの応答が遅れると、顧客が電話を切ってしまう可能性があります。ユーザーが音声またはテキストのリクエストを送信してから、AI モデルが最初の出力を生成するまでの遅延を最小限に抑え、最初のトークンまでの時間を極めて短くする必要がありました。
セキュリティとコンプライアンス: 2018 年の創業以来、当社は HIPAA、SOC2、ISO27001、PCI に準拠し、エンタープライズグレードのセキュリティを確保しています。データの完全性とセキュリティを保護するために、可能な限りの安全保護対策を採用したアーキテクチャとインフラストラクチャが必要でした。

ソリューション:

当社の会話型オーケストレーションプラットフォームは、飲食店の注文を送信する前に、POS システムと照合して構築および検証し、正確性を確保します。そのプラットフォームの内部では、Gemini Enterprise Agent Platform を介して提供される Gemini Flash が、レイテンシを大幅に短縮し、ユーザーの待ち時間を最小限に抑え、ユーザーが電話を切るのを防ぎます。それにより、以前に使用していた他の LLM と比較して、約 25%～30% の費用削減と、信頼性向上も実現しました。

ビジネスの成長、通話量の増加、そしてトラフィックの急増に対応するために、Google AI Studio から Vertex AI（現在は Gemini Enterprise）に切り替えました。後者が提供するエンタープライズ向けの保証は、医療機関のお客様のセキュリティとコンプライアンスだけでなく、スケーリングにも必要でした。Gemini Enterprise Agent Platform の特定の機能により、サービスの中断や、応答できない状況が発生することなく、大量の通話に対応できます。

これらのエンタープライズグレードのサービスは、AI Studio よりも費用がかかる可能性がありますが、信頼できる稼働時間を確保するうえで価値は十分にあります。また、従量課金制のプレミアム機能により、スケーリングがはるかに簡単になりました。たとえば、感謝祭の前日に過去最高の使用量に対応するために、Vertex AI でプロビジョンドスループットと従量課金制のプレミアム機能を組み合わせて使用したところ、レート制限の問題は発生しませんでした。

アーキテクチャ:

結果:

Gemini により、コンテキストの取得とメニューの作成を行う社内プログラマティックツールの負担が軽減されました。Gemini を使用することで、レイテンシが短縮され、信頼性が向上するなど、パフォーマンスと信頼性が大幅に向上しました。また、Gemini を活用したアシスタントの安定性が向上したことで、お客様のオンボーディングがはるかに効率的になりました。飲食店が POS システムにアクセスできるようになってからテストの準備が整うまでの期間は、以前は 1～2 週間でしたが、現在はわずか 1～2 日になりました。

スケーリングとエンタープライズグレードのサービスを実現する Google のソリューションにより、重要な指標である最初のトークンまでの時間を最適化し、お客様の待ち時間を最小限に抑えることができました。Vertex AI のプロビジョンドスループットと従量課金制の機能を使用することで、過去最高の使用量となった期間でも、100% の稼働率を確保し、応答できない状況やレート制限の問題を回避できました。今では、飲食店のトラフィックの急増に簡単に対応できるようになりました。

技術面では、会話型の注文取得から、会話や POS アクティビティのコンテキストを使用したよりプロアクティブな支援へと移行することを見込んでいます。たとえば、金曜日の夜に、いつものようにお気に入りの日本料理店に注文する際には、近い将来、Voicify の音声アシスタントがプロアクティブに注文してくれるようになるかもしれません。

詳細:

当社が注力している業界には、バックエンド内で時間をかけて解決しなければならない独自の課題がいくつかあります。

Voicify ソリューションの中核となるコンポーネントは、音声オーケストレーションプラットフォームです。これは、電話 AI スタック全体を管理し、エンタープライズグレードのスケーラビリティとセキュリティを実現するように設計されています。また、ユーザーのニーズに応じて業界ソリューションが呼び出されるノードでもあります。当社の音声オーケストレーションプラットフォームは、お客様の近くに配置され、Gemini や音声アシスタントのさまざまなコンポーネントなどのバックエンドサービスを調整します。このプラットフォームは、純粋な生成ではなく、プログラム上の要素を含む、自動音声認識、テキスト読み上げ、テキスト生成などの機能を管理するために使用します。

アーキテクチャについて当社が下した独自の決定の一つは、複雑で膨大な飲食店のメニューを管理する方法でした。メニュー全体を 1 つのプロンプトに含めることは避け、最初のプロンプトには特定の情報のみを含め、会話が進むにつれて詳細情報を収集することにしました。これにより、応答時間が短縮され、特定のやり取りで各メニューの関連部分のみに焦点を当てることで、大規模な注文の複雑さを管理できます。

また、当社は創業当初から、特に医療分野において、セキュリティとコンプライアンスに関する企業のお客様の高い基準を満たすようにアーキテクチャを設計しました。エンタープライズグレードのスケーラビリティも保証しています。アーキテクチャの面でも、データの完全性と安全性を確保するために、あらゆる安全保護対策を講じています。最後に、可能な限り高いレベルの可用性を実現するための戦略の一環として、当社のプラットフォームはマルチクラウド環境をサポートするように設計されています。

- Voicify、CTO / 共同創業者、Nick Laidlaw 氏

- Voicify、エンジニアリング担当ディレクター、Aadu Pirn 氏

Gemini Enterprise Agent Platform の最新情報

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

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

数か月前に Gemini Enterprise Agent Platform をリリースして以来、企業やビルダーの双方において素晴らしい進展が確認されています。開発をさらに活性化させるために役立つ、Agent Platform の汎用性とパワーを解説する 13 のデモと、堅牢なエージェント基盤の構築において確認すべき 20 の質問も用意していますので、ぜひご確認ください。

一方、Google Cloud では、より多くの機能をお客様にお届けし、エージェントを簡単かつセキュアにスケールするためのより良い方法を提供するという約束を果たし続けるべく、チームが一丸となって取り組んできました。

その一環として、このたび、Agent Runtime から Agent Identity に至るまで、特に人気の高い機能をすべてのお客様にご利用いただけるようになったことをお知らせします。また、新しいマネージドコードセキュリティエージェントである CodeMender も先日発表しました。これは、これまでの受動的なスキャン機能を自動化されたコード修正へと発展させ、ゼロデイリスクを低減するものです。詳しくは以下をご覧ください。

長時間実行されるエージェントを、より高速かつ優れたメモリ管理で自動化

長時間実行されるエージェントワークフローについて考えてみましょう。たとえば、顧客開拓のアプローチを継続的に管理すること、ベンダーのサプライチェーンを常時モニタリングしてコンプライアンスリスクを検知すること、IT インシデントへの対応や根本原因の修正をインフラストラクチャ全体でオーケストレートすること、などが挙げられます。基本的なチャット機能の枠を超えるには、マルチステップエージェントを長期にわたって実行し続ける持久力と、エクスペリエンスをパーソナライズし、関連性を維持するためのコンテキストメモリが必要です。

その実現を後押しするために、Google は以下の機能をすべてのお客様に提供いたします。

Agent Memory Bank: 構造化されたスキーマを定義することで、重要な会話のコンテキストを自動的に抽出して維持し、低遅延でのエージェントのパーソナライズを実現し、効率を最大化します。これにより、エージェントは長期にわたるタスク全体で、ユーザーの重要な設定、過去の決定、アカウント履歴を保持できるため、コンテキストを失ったり応答時間を遅らせたりすることなく、中断した箇所からすぐに再開できるようになります。
Agent Runtime: 最大 7 日間連続して実行可能なエージェントにより、数日間にわたる複雑なエージェント処理や推論タスクを自動化します。たとえば、顧客開拓のアプローチを 1 週間にわたって実行する、多段階のオンボーディングプロセスをオーケストレートする、といった非同期プロセス全体を委任することが可能になり、人間による常時介入やコンテキストの喪失を招くことなく、エージェントがバックグラウンドで意思決定を行えるようになります。

エージェントのオペレーションを保護、監査、一元化

堅牢なメモリと信頼性の高いランタイムを備えたエージェントを実行する際は、その安全性とセキュリティを確保する必要があります。特にエンタープライズ業務においては、ワークフローの種類や担当者に関係なく、すべての業務にセキュリティを組み込むことが不可欠です。安全な業務を支援するために、Google は、エージェントの保護、監査、一元化に役立つ以下の 3 つの機能を提供します。

Agent Identity: オープン標準に基づいて構築された新しいネイティブの IAM タイプです。エージェントの権限に対して最小権限の原則を適用します。アクセスを Agent Runtime に直接バインドすることでトークンの盗難を軽減します。また、すべてのエージェントアクションについて否認できない監査機能を提供するとともに、ID ライフサイクルを自動的に管理して、使用されていない認証情報を排除します。
Agent Gateway: エージェントエコシステム全体にわたるすべてのやり取りを保護、管理できる一元的なコントロールポイントを提供します。IAM 条件や自然言語ルールを通じてきめ細かなアクセス制御をここから適用できるほか、プロンプトインジェクション、ツールポイズニング、データ漏洩から保護できる、Model Armor によるインライン保護機能が統合されています。
Agent Registry: Google は、すべての個人がエージェントを構築できるようにしたいと考えています。その一方で、組織をまたがって構築されたエージェントを一元的に管理できる方法が必要であることも認識しています。Agent Registry は、まさにその一元的なビューを提供するもので、組織全体のすべての AI エージェント、サーバー、接続を管理できる単一のライブラリとして機能します。エージェントをゼロから構築するのではなく、既存のエージェントを簡単に検索して再利用できるようになり、システムを整理整頓できるほか、管理者はエージェントの無秩序な増加をモニタリングできるようになります。

以下に、Agent Gateway を活用して、エージェントを大規模に、シンプルかつセキュアに管理している Broadcom、Palo Alto Networks、Ping Identity の事例を紹介します。

パフォーマンスの向上とエージェントの意思決定の最適化

AI エージェントが稼働した後も、エージェントがユーザーに代わってどのように意思決定を行っているかを明確に把握する必要があります。オブザーバビリティは、エージェントが何をしたかを示し、評価は、その意思決定が適切であったかどうかを判断します。Agent Platform では、これら両方を 1 つのエンジンで提供するため、構築中に反復処理を行う際の指標と、リリース後のエージェントを評価する指標が同一になります。

エージェントの評価: パフォーマンスの低下や動作のドリフトをプロアクティブに特定するオンライン評価モニターを使用して、本番環境でのエージェントのパフォーマンスを継続的にモニタリングおよび評価します。指標の選択肢は多岐にわたり、事前構築済みのもの、カスタム Python、LLM-as-a-judge、Google DeepMind と共同開発した適応型ルーブリックなどを利用できます。
エージェントのオブザーバビリティ: 包括的なトレース機能とリアルタイムのオブザーバビリティダッシュボードにより、エージェントの推論、ツールの利用状況、実行パフォーマンスをエンドツーエンドで詳細に可視化できます。

Gemini Enterprise で成果を挙げているお客様

「AT&T では、長期記憶に Agent Memory Bank を活用しています。これにより、当社の App チャネルの自律型かつインテリジェントな AI セールスエージェントが、過去の顧客とのやり取りから重要な事実を統合し、会話が中断した後でも会話を再開できるようになり、推測ではなく記憶に基づく応答が可能になりました。この機能を IVR（自動音声応答）に拡張することで、シームレスなクロスチャネルの販売プロセスを構築しています。お客様は、アプリ、音声、ウェブのエクスペリエンスをまたいで会話を続けることができ、コンテキストが失われたり、同じことを繰り返したりする必要はありません。」- AT&T、デジタルプロダクト管理および開発担当 AVP、Jeff Dixon 氏

「Best Buy では、AI エージェントを導入する組織が増えるにつれて、エージェントのアイデンティティが人間のアイデンティティと同じくらい重要になってきています。これまで私たちは、孤立したサービスアカウント、不明確な所有権、時間の経過とともに増え続ける権限といった課題に悩まされてきました。Agent Identity は、エージェントが誰であるか、何にアクセスできるか、誰が責任者であるかを明確にすることで、自律型システムにアカウンタビリティとガバナンスをもたらします。セキュリティの観点からは、エージェントには最小限のアクセス権を適用することでリスクを軽減しており、これにより、組織は AI を安全にスケールできるという確信を得られます。」- Best Buy、クラウドプラットフォームエンジニアリング担当シニアマネージャー、Kishor Patil 氏

「Commerzbank AG は、責任あるエージェント型 AI のためのセキュアな基盤を Google Cloud 上で構築しています。このビジョンを大規模に展開するため、Google Cloud の新しい Agent Registry と Agent Gateway を積極的に評価しています。これらのサービスは、当社のガバナンス戦略において重要な役割を果たしており、エージェントの検出可能性やポリシーの適用など、アクセス管理に不可欠な重要な制御機能を提供してくれます。さらに、コンプライアンスを遵守し、信頼できる方法で AI プラットフォームをスケールするために不可欠な、詳細なオブザーバビリティと監査可能性も備わっています。」- Commerzbank AG、クラスタアーキテクト / AI トランスフォーメーションオフィス、AI 戦略プログラム、AI プラットフォームおよびサービス担当、Seenuvasan Devasenan 氏

「Liberty Global は、Gemini Enterprise Agent Platform を活用することで、専門的な AI 機能を迅速に作成およびデプロイするために必要な高速エンジンを開発者に提供しています。ガバナンスが極めて重要である複数の事業体が存在する環境において、Agent Gateway や Agent Registry は、そのガバナンスを大きく前進させる革新的な機能です。これにより、厳格なセキュリティプロトコルを適用しつつ、一元的な監視体制を維持できるため、多様な事業会社にわたって、コンプライアンスを確保しながら安全に AI を展開できるようになります。」- Liberty Global、AI アーキテクチャ担当ディレクター、David Mortimer 氏

「WellSky にとって、責任ある AI のスケーリングとは、ガバナンスを常に先回りして確立することを意味します。ヘルスケアとコミュニティケアのプラットフォーム全体で生成 AI 機能を拡張するにあたり、当社のプラットフォームエンジニアリングチームは、エコシステム内の AI エージェントをカタログ化、バージョン管理、ライフサイクル管理するためのプロアクティブなフレームワークを確立しました。また、Google Cloud とのパートナーシップによって、一元化された Agent Registry を実装しました。これは、コンプライアンスポリシーを適用して、徹底的に検証されたエージェントのみが本番環境に到達できるようにするもので、テクノロジーの進化に合わせて柔軟に対応できるようにも設計されています。その結果、医療機関のお客様が信頼を寄せるセキュリティとガバナンスの基準を損なうことなく、AI イノベーションの加速に不可欠な基盤となる可視性を得ることができました。」- WellSky、最高技術責任者、Joel Dolisy 氏

今すぐ Agent Platform を使ってみる

エージェントをシンプルかつセキュアにスケールする準備はできていますか？Gemini Enterprise Agent Platform のドキュメントで詳細をご確認のうえ、一般提供が開始されたこれらの新機能を今すぐお試しください。こちらの最近公開されたライブ配信では、エージェントのライフサイクル全体を段階的にご案内しています。

- Gemini Enterprise Agent Platform、プロダクト管理担当ディレクター、Mike Clark

Panasonic Automotive、C4A-metal と vSkipGen で自動車のイノベーションを加速

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

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

自動車業界がソフトウェア定義車両への移行を加速させるなか、コックピットドメインコントローラ（CDC）は次世代の車内エクスペリエンスの中核になりつつあります。柔軟でハードウェアに依存しない環境において、CDC ソフトウェアを迅速に開発、テスト、検証できる能力は、イノベーションと市場投入までの時間短縮にとって極めて重要です。しかし、物理ハードウェアの制約や高性能グラフィックスへの要件は、グローバルな開発チームにとって大きな課題となっています。

Panasonic Automotive の vSkipGen™ は、こうした課題に対処する次世代の CDC 仮想化プラットフォームであり、現在、Google Cloud の C4A-metal（Axion ベアメタルサービス）で検証が行われています。Panasonic Automotive の先進的な Unified HMI™ リモート GPU オフロード技術と、Android Automotive OS（AAOS）および Android SDV のサポートを統合した vSkipGen は、コックピットソフトウェアの開発と検証のための堅牢なクラウドネイティブソリューションを提供することで、ハードウェアの制約に縛られることなくイノベーションを推進できます。

Google Cloud は、ワークロードに最適化されたインフラストラクチャを提供することで、各タスクに適したリソースを確実に利用できるようにしています。C4A-metal インスタンスは、Axion 仮想マシンファミリー全体と同様に、Google Cloud のカスタム Arm ベースの Axion アーキテクチャ上に構築されています。C4A-metal は、96 個の vCPU、2 種類の DDR5 メモリ構成（384 GB、768 GB）、最大 100 Gbps のネットワーキング帯域幅を提供するほか、Google Cloud Hyperdisk の各タイプ（Balanced、Extreme、Throughput、ML を含む）を完全にサポートしています。また、他のベアメタルポートフォリオと同様に、C4A-metal には Titanium が搭載されています。Titanium は、マルチティアオフロードとセキュリティのための重要なコンポーネントであり、Google Cloud のインフラストラクチャの基盤となっています。

要求の厳しいワークロードに対応する高パフォーマンス

C4A-metal は、実際の挙動を正確に再現する必要がある、車両コックピットのデジタルツインの作成などの複雑なタスクに特に適しています。従来、ソフトウェア定義車両への移行には、高価で希少な物理的なプロトタイプに依存してきましたが、C4A-metal は、ベアメタルならではの高パフォーマンスとハードウェアレベルのアクセス性をクラウドのスケーラビリティと組み合わせることで、この課題を克服します。

Panasonic Automotive は、C4A-metal を活用することで従来のハードウェアによるボトルネックを回避し、複雑な仮想化タスクを実行しながら、次世代のコックピットソフトウェアの開発を加速しています。

「Google Cloud の Axion ベアメタルは、当社の vSkipGen™ プラットフォームに大きな変革をもたらしました。スケーラブルで高性能な Arm ベースのインフラストラクチャを提供する C4A-metal により、ターゲットとなる自動車用ハードウェアの挙動に極めて近い状態で、本番環境向けソフトウェアをクラウド上で開発、テストできるようになりました。このように、クラウドと車載側の環境がビットレベルで一致することで、高価な物理プロトタイプへの依存度が低減し、検証効率が向上し、テストカバレッジが拡大し、次世代のコックピットプラットフォームの市場投入までの時間が短縮されます。」 - Panasonic Automotive Systems America、CTO、Andrew Poliak 氏

自動車メーカーは、C4A-metal で vSkipGen と Unified HMI を活用することで、ハードウェアに依存しないクラウドネイティブな環境において、AAOS スタック全体の構築、テスト、検証が可能になるとともに、物理的な依存から脱してスケーラブルなデジタルツインへと移行できます。

図 1: Unified HMI ソリューションの概要

vSkipGen の仕組み: Cuttlefish によるコックピットの仮想化

Panasonic Automotive の vSkipGen は、物理的な CDC ハードウェアのデジタルツインとして機能し、Android 仮想マシン用のハードウェアに依存しない環境を提供するために、Android Cuttlefish のコンポーネントを使用します。vSkipGen の中核には、crosvm（Chrome OS 向けに開発されたセキュリティ重視のオープンソース VMM）をベースに構築された、クラウド向けに最適化された仮想マシンモニター（VMM）があり、この VMM は、ハードウェア支援の仮想化に Linux KVM（カーネルベースの仮想マシン）を利用します。VMM バックエンドは、セキュリティ、スケーラビリティ、パフォーマンスを向上させるために Rust で実装されています。C4A-metal でフルスタックを実行することで（図 2 を参照）、開発者はクラウドで完全な AAOS イメージを起動できます。これは、物理的な車両で実行されるソフトウェアとまったく同じように動作します。

このプラットフォームは、VirtIO 標準を使用して、音声、GPU、センサー、カメラ、コントローラエリアネットワーク（CAN）、Bluetooth、Wi-Fi など、主要な周辺機器をすべて仮想化します。この VirtIO ネイティブのアプローチにより、開発者は物理ハードウェアとまったく同じように仮想デバイスとやり取りできます。さらに、vSkipGen では自動車用シミュレータやソフトウェアインザループ（SiL）環境とシームレスに連携して、包括的なシナリオやエッジケースの検証が可能なため、ソフトウェアの検証や自動テストスイートの実行を行うことができます。これにより、物理的なプロトタイプを早い段階で確保する必要がなくなります。

図 2: vSkipGen Cockpit の仮想化アーキテクチャ

図 3: リモート GPU レンダリングのフロー

Unified HMI で作業場所を問わずグラフィック処理を高速化

高性能なグラフィックスは現代の運転体験において不可欠ですが、仮想環境でのレンダリングは困難を伴う場合があります。Panasonic の Unified HMI は、HMI レンダリングを特定のハードウェアから切り離すことで、この課題を解決します。軽量な Unified HMI コンポーネントは VM の外側で動作し、Cuttlefish インスタンスから OpenGL ES コマンド（レンダリング対象のデータ）をオフロードして、Google Cloud 上の GPU 搭載コンピューティングリソースに渡します。これらのリソースは、ハードウェアアクセラレーションを使用してワークロードを処理します。レンダリングされた UI は、低レイテンシの WebRTC を使用して、任意の標準ブラウザにストリーミングされます。これにより、世界中の開発チームが、作業場所を問わず、忠実度の高いビジュアルをリアルタイムで利用できるようになります。

Unified HMI は、複数の電子制御ユニット（ECU）と仮想マシンにまたがる統合された仮想ディスプレイレイヤを確立し、アプリケーションがシステム内のどこからでも任意のディスプレイにレンダリングできるようにします。

ソフトウェア定義車両の開発におけるメリット

C4A-metal と Panasonic Automotive の vSkipGen を活用することで、ソフトウェア定義車両を開発するメーカーは以下のことを実現できます。

物理ハードウェアが準備できる前に、Cuttlefish を使用してクラウドで AAOS ベースのソフトウェアを構築および検証する
業界標準の VirtIO を使用して重要な CDC デバイスをエミュレートし、堅牢な本番環境グレードの検証を行う
インタラクティブなコックピットエクスペリエンスを任意のブラウザにストリーミングして、分散しているエンジニアリングチームをサポートする
大規模な自動テストや CI / CD パイプラインをサポートするために、複数の隔離された CDC インスタンスを並行して実行する
高価な物理ハードウェアプロトタイプの必要性を最小限に抑えることで、費用と環境への影響を低減し、持続可能な開発手法をサポートする
オープン標準、crosvm、Rust を基盤とする将来を見据えたアーキテクチャにより、セキュリティ、パフォーマンス、長期的な適応性を強化する

使ってみる

C4A-metal は世界中で一般提供されています。詳細については、一般公開ドキュメントをご覧ください。Google Cloud 向けに Unified HMI を備えた Panasonic Automotive の vSkipGen は、評価版のアクセスをまもなく開始する予定です。これらのソリューションがコックピットソフトウェア開発の迅速化にどのように役立つかについて、詳細情報をご希望の場合は、vSkipGenSupport@panasonicautomotive.com までお問い合わせください。

^免責条項

^{本書で使用されているすべての商標、商号、サービスマークは、それぞれの所有者に帰属します。}

- Google Cloud、プロダクトマネージャー、Yarden Halperin

- Panasonic Automotive Systems、シニアスタッフアーキテクト、Senthilnathan Subramanian 氏

レポート「2026 Public sector threat landscape: M-Trends and beyond（2026 年の公共部門における M-Trends とその先）」の主な調査結果

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

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

2026 年現在、公共部門が防御しているのは、もはや従来の境界ではありません。現在防御しているのは、マシンスピードで動作する攻撃者と戦うための、相互接続された複雑な信頼関係のネットワークです。Google は最近、レポート「2026 Public sector threat landscape: M-Trends and beyond（2026 年の公共部門における脅威の展望: M-Trends とその先）」を公開しました。本レポートは、2025 年に Mandiant が実施した 50 万時間以上にわたる最前線のインシデント調査をまとめたもので、公共部門のリーダーのミッションクリティカルなニーズに特化した内容となっています。

レポートの主な調査結果と、それが公共部門に意味するもの

今年の M-Trends データで最も憂慮すべき傾向は、22 秒の引き継ぎです。これは、初期アクセスブローカーが足場を確立してからランサムウェアオペレーターに引き継ぐまでの時間の中央値です。このように攻撃サイクルが極限まで短縮されたことにより、人間のスピードに頼った従来のトリアージは完全に通用しなくなりました。自治体のワークステーションが感染してから、人間のアナリストがチケットを開くことすらできないうちにネットワーク全体が暗号化されてしまう現状において、レジリエンスのための戦略的至上命令はマシンスピードの防衛へと転換しなければなりません。

さらに、このレポートでは、攻撃者が組織的に悪用している、新たに浮上した「信頼の境界」がいくつか明らかになりました。

永続性のパラドックス: 国家が支援するスパイ活動者は数年にわたる永続性を追求しており、5 年以上検知されないままのケースもあります。この「永続性のパラドックス」は、標準的な 90 日間のテレメトリー保持ポリシーに直接的な課題を突きつけ、多くの場合、機関は侵害の全体的な影響を定量化できなくなります。
仮想化スタック: 攻撃者は「スタックの下層」に移動し、仮想化管理プレーンを標的にしています。「スナップショットマウント」などの手法により、攻撃者はゲストレベルのセキュリティツールをバイパスし、ドメインコントローラのスナップショットを作成してデータベースをオフラインで盗むことができます。
SaaS のドミノ効果: 州レベルと地方レベルでは、サードパーティのクラウドツールへの依存により、統合が脅威ベクトルに変わっています。サービスアカウントや OAuth トークンなどの非人間 ID（NHI）が悪用されると、1 回の侵害で機関のネットワーク全体に連鎖反応を引き起こす可能性があります。
ビッシングの急増: 音声フィッシング（ビッシング）が世界全体の感染の 11% に急増しました。これらの非常に高度なソーシャルエンジニアリング攻撃は、政府のヘルプデスクを標的として、パスワードのリセットや不正なデバイスの登録を試みます。これは、「人的要素」、つまりヘルプデスクスタッフや IT 管理者に与えられた管理上の信頼が、初期アクセスを確立するための主要なベクトルになっていることを証明しています。

継続的な検証の義務

今後、公共部門のレジリエンスには、コンプライアンスチェックリスト以上のものが必要になります。信頼は決して前提とせず、常に再検証する必要があるというセキュリティドクトリンである、継続的な検証への文化的な転換が求められます。成功の定義は、もはや「侵害がないこと」だけではなく、「アクティブな攻撃を受けている最中でも業務を継続できる能力」へと変化しています。Google は、3 つのコア機能を通じて継続的な検証を実現する技術アーキテクチャを提供しています。

新しい境界としての ID: Chrome Enterprise Premium を使用して、従来の VPN をコンテキストアウェアアクセスに置き換えます。ユーザーの身元とデバイスのセキュリティポスチャーをアプリケーションリクエストごとに検証し、適切な条件が満たされた場合にのみアクセスを許可します。

エージェント型防御: Google Security Operations を使用して、機関が膨大なテレメトリーデータセットをリアルタイムで取り込んで分析できるようにします。これには、脅威を中心としたケース管理、インタラクティブでコンテキスト豊富なアラートのグラフ化、エンティティの自動ステッチが含まれます。これにより、22 秒の引き継ぎ時間内に攻撃者を特定するために必要な「マシンスピード」の検出が可能になり、手動のトリアージが、自動化された継続的なモニタリングに変わります。こうした急速な変化に先手を打つため、この運用スタックには Google Threat Intelligence が直接組み込まれています。これにより、グローバルなアクターインフラストラクチャを公開し、内部テレメトリーを Mandiant の最前線のインシデント分析情報とリアルタイムで照合します。

Google Cloud Next '26 では、Google Security Operations 内の 3 つの新しい AI 搭載自律型エージェントを発表しました。隠れた攻撃パターンをプロアクティブに発見する Threat Hunting エージェント、テレメトリーカバレッジのギャップを自動的に解消する Detection Engineering エージェント、アナリストのワークフローをシームレスに強化する Third-Party Context エージェントです。

強化されたインフラストラクチャ: Security Command Center で「スタックの下層」に移行し、Wiz との戦略的パートナーシップを活用することで、仮想化レイヤとクラウドレイヤを詳細に可視化します。これにより、機関はハイパーバイザとクラウド構成の整合性を継続的に検証し、攻撃者が永続化のために利用する不正な「スナップショットマウント」や構成のドリフトを自動的に検出できます。ID や仮想化などの管理ファブリックを強化し、ログ保持をモダナイズして可視性のギャップを解消することで、政府機関のリーダーは、事後対応のトリアージの状態から、コンテキストを認識したレジリエンスの未来へと移行できます。

Google のセキュリティの活用

Google のセキュリティテクノロジーは、公共部門全体で活用されています。各機関は、手動によるトリアージからエージェント型防御へと移行し、セキュリティの変革を加速させています。パスコ郡保安官事務所は、Google Security Operations でサイロ化されたツールを統合し、セキュリティと運用を変革しました。これにより、効率性を高め、地域社会の安全性を向上させ、法執行機関向けの安全な AI を推進しています。また、コネチカット州は、Google Security Operations を活用することで、分断されていた運用モデルから、統合的かつプロアクティブなセキュリティポスチャーへと移行しました。これにより、フォレンジック調査の時間を数か月からわずか数時間に短縮したほか、将来の行政サービスを見据えた、安全性を重視した設計のデジタルインフラストラクチャを構築しています。

将来のセキュリティを確実なものに

「2026 Public sector threat landscape: M-Trends and beyond（2026 年の公共部門における脅威の展望: M-Trends とその先）」レポートをダウンロードして、最新の分析情報とトレンドに関するデータと戦略的推奨事項、およびそれらが公共部門に与える影響についてご確認ください。Gemini for Government ウェブセミナーの録画をご覧になり、エージェントのセキュリティ保護と管理についてさらに詳しくご確認ください。

- インシデント対応責任者、Fernando Tomlinson Jr.

- 公共部門、脅威インテリジェンスアドバイザーリード、Jose Valerio

BigQuery と %%bqsql マジックで SQL と Python のギャップを埋める

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

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

データサイエンティストとデータエンジニアは SQL と Python の使い分けに頭を悩ませることがよくあります。特に BigQuery のような強力なエンジンと組み合わせて大規模データを処理する場合に、SQL はより直感的に使えると感じる人がいる一方、ライブラリやランタイムの豊富なエコシステムを活用できる Python の方が使いやすいと感じる人もいます。従来、1 つのノートブックでこれらの言語を併用するには、まずデータを SQL の結果からインメモリに移動し、Python のメモリから一時テーブルに書き込んだうえで、SQL からアクセスする必要がありました。

この手間を解消するため、Google Cloud チームは Colab Enterprise に SQL セルを導入しました。このたび、そのシームレスな体験を、より広範なオープンソースエコシステムへと拡大しました。今後は %%bqsql IPython セルマジックを使用して、SQL と Python のコードセル間でデータ処理ワークロードを簡単に連携させることができます。

Jupyter、pandas、BigFrames、BigQuery サンドボックスなどのオープンソースパッケージのおかげで、このガイドに記載されたすべての手順は無料で*クレジットカードなしで実行していただけます。

* 制限事項については、BigQuery サンドボックスのドキュメントをご確認ください。

環境を設定する

事前準備：

1. BigQuery サンドボックスを有効にします。Google Cloud プロジェクト ID をメモしておきます。

2. ローカルの Python 開発環境を設定するか、Python 環境がすでにインストールされている Colab でこのノートブックを開きます。

ローカルの Python 環境を設定する方法については、Google Cloud ドキュメントの手順をご確認ください。ローカルの Python 環境を設定する場合は、次の手順に進みます。設定しない場合は、次のセクションにスキップしてください。

3. 前のステップで作成した venv を有効にして、Python の依存関係を分離します。

Linux または macOS では、次のコマンドを使用します（お好みの Python バージョンに更新してください）。

code_block: <ListValue: [StructValue([('code', '. ./env/bin/activate'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe7958ff8e0>)])]>

4. Jupyter、bigframes、python-calamine パッケージをインストールします。

code_block: <ListValue: [StructValue([('code', 'pip install --upgrade jupyterlab bigframes python-calamine'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe7958ffd00>)])]>

5. JupyterLab を起動します。

code_block: <ListValue: [StructValue([('code', 'jupyter lab'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe7958ff460>)])]>

6. ウェブブラウザを開き、出力に表示された URL にアクセスします。表示される URL は、http://localhost:8888/lab?token=somesupersecretvaluehere のような形式になります。

7. Jupyter Lab UI を使用して新しいノートブックを作成します（[File] > [New] > [Notebook]）。または、BigQuery DataFrames GitHub リポジトリからこのチュートリアルに関連付けられたノートブックをダウンロードして開きます。

ローカルデータにアクセスして準備する

このチュートリアルでは、USDA の小麦データを分析します。Pandas はデータをダウンロードし、一般的なローカルデータ分析ワークフローを模倣します。

code_block: <ListValue: [StructValue([('code', 'url = "https://www.ers.usda.gov/media/5706/wheat-data-all-years.xlsx?v=52690"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe7958ff760>)])]>

次に、データをローカルの pandas DataFrame に読み込みます。SQL 処理用のローカルの pandas データを準備する際は、pyarrow dtype_backend を使用します。これにより、データを BigQuery SQL エンジンに渡す際の NULL 値の処理で一貫性が維持され、スキーママッピングもシームレスに行えるようになります。この例では、小麦の年間供給量と消失量のデータが含まれている「Table05」シートを読み込みます。

code_block: <ListValue: [StructValue([('code', 'import pandas as pd\r\n\r\ndf = pd.read_excel(\r\n url,\r\n sheet_name="Table05",\r\n dtype_backend="pyarrow",\r\n engine="calamine",\r\n header=1, # Skip the first row.\r\n)\r\ndf'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe7958fffa0>)])]>

SQL でローカルの DataFrame に対してクエリを実行する前に、SQL に適した列名になっているか確認してください。BigQuery は柔軟な列名をサポートしており、ほとんどの Unicode 文字を使用できますが、"/" や "" などの特殊文字は削除または置き換えておく必要があります。

code_block: <ListValue: [StructValue([('code', 'df.columns = [name.replace("/", "") for name in df.columns]\r\ndf'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe7957b8190>)])]>

標準的な Python と pandas の構文を使用して基本的なフィルタリングを行い、欠損データのある行を削除します。これは、処理チェーンにおける最初の Python のみのステップとなります。

code_block: <ListValue: [StructValue([('code', "full_rows = df[~df['Beginning stocks'].isna()]\r\nfull_rows"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe7957b8c70>)])]>

BigQuery SQL マジックを初期化する

BigQuery DataFrames ライブラリには、Python 環境と SQL 環境の橋渡し役となる %%bqsql マジックが用意されています。このマジックを使うことで、BigQuery クエリエンジンがローカルの pandas DataFrame（一時テーブルとして暗黙的にアップロードする）だけでなく、実際の BigQuery テーブルや、GCS（Parquet、Iceberg、CSV）内の外部テーブルを直接参照してクエリできるようになります。

ノートブックでこの統合を有効にするには、bigframes 拡張機能を読み込みます。

code_block: <ListValue: [StructValue([('code', '%load_ext bigframes'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe7957b8b50>)])]>

注: この拡張機能は、BigQuery Studio 環境と Colab 環境にプリロードされています。

無料枠内での利用を含め、クエリの使用料が適切な Google Cloud プロジェクトに対して課金されるように、マジックで使用するプロジェクト ID を設定します。無料のサンドボックスティアであっても、クエリリソースを割り当てるにはプロジェクト ID が必要です。明示的に設定しない場合、BigFrames は環境（アプリケーションのデフォルト認証情報など）から検出を試みます。

code_block: <ListValue: [StructValue([('code', 'import bigframes.pandas as bpd\r\n\r\nbpd.options.bigquery.project = "your-project-id-here"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe7957b80d0>)])]>

SQL を使用したローカルの pandas DataFrame にクエリを実行する

プロジェクトの設定が完了し、ローカルの pandas DataFrame（full_rows）に対して BigQuery のテーブルと同様に、SQL クエリを直接実行できるようになりました。SQL クエリ内で、変数名を波括弧 {full_rows} で囲んで記述するだけです。認証コードの入力を求められる場合がありますが、その場合は同じメッセージに含まれているリンクをクリックして認証コードを取得してください。

code_block: <ListValue: [StructValue([('code', '%%bqsql\r\nSELECT * FROM {full_rows}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe7957b8d90>)])]>

SQL と Python のチェーン: SQL の結果を保存する

%%bqsql マジックの真の力は、処理を連結できる点にあります。%%bqsql の引数に保存先の変数名を指定すると（例: %%bqsql destination_var）、クエリ結果が BigQuery DataFrame としてその変数に保存されます。

この DataFrame は BigQuery エンジン上で処理されますが、Python では pandas DataFrame と同じように操作できます。この結果は、後続の Python セルですぐに使用したり、別の SQL セルから再度参照したりできます。これにより、マルチステップのハイブリッドな処理パイプラインを構築できます。

SQL を使用してデータをフィルタリングし、年単位のエントリのみを抽出して、その結果を「yearly」という名前の新しい BigFrames DataFrame に保存します。

code_block: <ListValue: [StructValue([('code', "%%bqsql yearly\r\nSELECT *\r\nFROM {full_rows}\r\nWHERE STARTS_WITH(`Time period`, 'MY')"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe7957b8910>)])]>

これで、別の SQL オペレーションをチェーンできます。作成したばかりの年単位の BigFrames DataFrame を参照し、SQL の正規表現を使用して年を抽出します。それをタイムスタンプにキャストして、結果を timeseries という名前の新しい BigFrames DataFrame に保存します。

code_block: <ListValue: [StructValue([('code', "%%bqsql timeseries\r\nSELECT\r\n * EXCEPT (`Marketing year 1`),\r\n TIMESTAMP(CONCAT(\r\n REGEXP_EXTRACT(`Marketing year 1`, r'([0-9]+)\\/'),\r\n '-01-01')) AS `year`\r\nFROM {yearly}"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe7957b8bb0>)])]>

Python から SQL、そして再び Python へと処理のチェーンが構築されていることに注目してください。

Python に戻って可視化する

SQL 変換が完了したので、次は Python へとチェーンを戻して可視化を行います。BigFrames の DataFrame は pandas API を実装しているため、データセット全体を事前にダウンロードすることなく、標準的な可視化メソッド（.plot.line() など）を時系列 DataFrame で直接呼び出すことができます。計算は BigQuery で行われ、要約されたグラフデータのみがノートブックに返されます。

code_block: <ListValue: [StructValue([('code', "timeseries.set_index('year').sort_index().plot.line()"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe7957b8850>)])]>

または、時系列を pandas DataFrame としてダウンロードして、選択した可視化ライブラリで使用することもできます。

code_block: <ListValue: [StructValue([('code', "pddf = timeseries.set_index('year').sort_index().to_pandas()"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe7957b86d0>)])]>

ハイブリッドパイプラインが重要である理由

BigQuery DataFrames と %%bqsql マジックを組み合わせることで、SQL と Python をシームレスに橋渡しする強力で相互運用性に優れたパイプラインが構築されました。

ローカルの pandas df と full_rows DataFrame
SQL フィルタへ
BigFrames の yearly DataFrame へ
SQL 変換へ
BigFrames の timeseries DataFrame へ
Python によるデータ可視化へ
ローカルの pandas DataFrame へ

このアーキテクチャの主な利点:

最適なツールの使い分け: SQL が得意な処理（大規模な集計、ウィンドウ関数、複雑な結合）は SQL に、Python が得意な処理（可視化、統計モデリング、ML オーケストレーション）は Python に任せられます。
コードの可読性が向上: 数十もの共通テーブル式（CTE）が連なる巨大な SQL クエリを書いたり、SQL に比べて複雑になりがちな pandas API で集計を行ったりする代わりに、パイプラインを論理的なステップに分割し、SQL と Python を交互に組み合わせて記述できます。
シームレスなスケーリング: %%bqsql コードは、ローカルの小さな pandas DataFrame から本番環境の BigQuery テーブルの数十億行まで、まったく同じコードでスケールできます。最初のローカルの pandas DataFrame を BigQuery DataFrame 参照に置き換えるだけです。

次のステップとスケールアップ

BigFrames API リファレンスサイトでその他のノートブックもご確認ください。%%bqsql セルマジックに加えて、BigFrames は標準の pandas DataFrame に BigQuery Accessor も登録します。これにより、ローカルの pandas データに対して SQL スカラー関数を直接実行できるようになります。

たとえば、df.bigquery.sql_scalar(...) を使用して、BigQuery Utils、BigFunctions、CARTO Analytics Toolbox for BigQuery などで公開されている Google Cloud コミュニティの強力な UDF を呼び出すことができます。

code_block: <ListValue: [StructValue([('code', 'import pandas as pd\r\nimport bigframes.pandas as bpd # Registers the accessor\r\n\r\nbpd.options.bigquery.project = "your-project-id"\r\ndf = pd.DataFrame({"x": [1, 2, 3]})\r\npandas_s = df.bigquery.sql_scalar("`bqutil`.fn.cw_setbit({x}, 2)")'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe7957b8ee0>)])]>

BigQuery サンドボックスは、これらのハイブリッド Python-SQL ワークフローを無料でテストできる強力な環境ですが、BigQuery Machine Learning（BQML）などの高度な機能は制限されています。請求先アカウントを Google Cloud プロジェクトに接続すると、bigframes.bigquery.ai.forecast 関数などの高度な機能を利用できるようになります。この関数を使用すれば、SQL と Python のチェーンで Google 最先端の基盤モデルを直接使用して時系列データを予測できます。

code_block: <ListValue: [StructValue([('code', 'forecasted_pandas_df = (\r\n pddf\r\n .reset_index(drop=False)\r\n .bigquery.ai.forecast(\r\n data_col="Production",\r\n timestamp_col="year",\r\n horizon=10,\r\n )\r\n)\r\n\r\n# Plot the results\r\nforecasted_pandas_df_sorted = forecasted_pandas_df.sort_values(by=\'forecast_timestamp\')\r\nplt.plot(pddf.index, pddf[\'Production\'], label=\'Real Production\', color=\'blue\')\r\nplt.plot(forecasted_pandas_df_sorted[\'forecast_timestamp\'], forecasted_pandas_df_sorted[\'forecast_value\'], label=\'Forecasted Production\', color=\'red\', linestyle=\'--\')\r\nplt.fill_between(\r\n forecasted_pandas_df_sorted[\'forecast_timestamp\'],\r\n forecasted_pandas_df_sorted[\'prediction_interval_lower_bound\'],\r\n forecasted_pandas_df_sorted[\'prediction_interval_upper_bound\'],\r\n color=\'red\',\r\n alpha=0.2,\r\n label=\'Confidence Interval\'\r\n)\r\n# ...\r\nplt.show()'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe7957b8250>)])]>

ハイブリッド Python-SQL エクスペリエンスに関するフィードバックを BigFrames チームまでぜひお寄せください。

メール: bigframes-feedback@google.com
問題: オープンソースの BigFrames リポジトリでバグ報告や機能リクエストを提出してください。
最新情報: ニュースや最新情報を受け取るには、BigFrames のメーリングリストにご登録ください。
詳細: ドキュメントで BigFrames API リファレンスとユーザーガイドをご確認ください。

- BigQuery DataFrames チームリーダー、Tim Swena

列レベルのセキュリティを強化: BigQuery で IAM データガバナンスタグを使用する

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

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

BigQuery のお客様の多くは、機密情報を保護するためにポリシータグを利用しています。ポリシータグは、列レベルのアクセス制御を適用するための主要なソリューションであり、適切な権限を持つユーザーのみが個人情報（PII）などの機密性の高い列を表示できるようにするものです。当時の環境においては、堅牢で効果的なシステムでした。

しかし、データエコシステムは複雑化しており、そのセキュリティを確保するために使用するツールも、それに応じて進化する必要があります。新たな課題としては、複数のリージョンとロケーションにわたって複数のタグをサポートする分類の作成と管理、障害復旧の実現、広範な一元化されたガバナンス戦略との統合などが挙げられます。

今日のデータエコシステムのニーズに対応するため、BigQuery でデータガバナンスタグのプレビューが導入されました。Google Cloud の Identity and Access Manager（IAM）の Resource Manager インフラストラクチャ上に構築されたデータガバナンスタグは、スケーラブルで堅牢な方法を提供することで、アクセス制御の管理と BigQuery 列データの保護を支援します。

IAM データガバナンスタグとは

データガバナンスタグは、特殊なタイプの Resource Manager タグです。このタグは、IAM でタグキーを作成するときに、目的フィールドを DATA_GOVERNANCE に設定することで作成し、BigQuery の列レベルのセキュリティで使用するように指定します。列データのガバナンスを目的としたデータガバナンスタグの階層ツリーを作成し、BigQuery 列に直接適用できます。

列レベルのセキュリティにデータガバナンスタグを使用する理由

グローバルスコープ、リージョンごとの適用: ポリシータグ（リージョンのみ）とは異なり、データガバナンスタグはグローバルに適用されます。組織レベルで 1 つのタグキーと値のペア（「data_sensitivity:high」など）を定義し、組織内のあらゆるプロジェクトやリージョンで使用できます。
マネージド障害復旧: セキュリティポリシーはフェイルオーバー中も維持する必要があります。データガバナンスタグとそれに関連するデータポリシーは、セカンダリリージョンに自動的に複製されます。必要に応じてリージョンを切り替えても、セキュリティポスチャーは自動的に移行されます。
階層型セキュリティ: タグのツリーを最大 5 階層まで構築できるようになりました。これにより、継承とより詳細な分類（PII > Financial > CreditCardNumber など）が可能になります。
ガバナンスの分離: セキュリティを適用する前に、データをタグ付けして整理、分類できます。アクセス制御は、そのタグのデータポリシーを定義した後にのみ適用されるため、データのオンボーディング時に柔軟に対応できます。

列レベルのセキュリティを実装する 3 つのステップ

ステップ 1: タグキーと値を作成する

1. データガバナンスタグキーを作成する: まず、コンソール、gcloud CLI、または API で IAM タグキーを作成します。このタグキーの目的フィールドを --purpose=DATA_GOVERNANCE と指定するだけで、データガバナンスタグキーになります。このキーの変更により、このタグが BigQuery の列レベルのセキュリティに使用されることが Google Cloud に通知されます。

code_block: <ListValue: [StructValue([('code', '# Example: Creating a Data Governance tag key named "data_class"\r\ngcloud resource-manager tags keys create data_class \\\r\n --parent=projects/my-governance-project \\\r\n --purpose=DATA_GOVERNANCE'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe794187e50>)])]>

2. タグ値を作成する

データガバナンスタグキーを作成したら、そのキーの下に、列データの分類に使用するタグ値を設定する必要があります。データガバナンスタグの便利な機能の一つが、タグ値の階層ツリーを構築できることです。タグ値のツリーでは、まず大まかなカテゴリを作成し、そこからデータタイプに基づいてより詳細なカテゴリにドリルダウンしていくことができます。最大 5 階層の深さまでのツリーを構築できるため、きめ細かいアクセス制御が可能になります。

code_block: <ListValue: [StructValue([('code', '# Level 1: Create a tag value called "pii"\r\ngcloud resource-manager tags values create pii \\\r\n --parent=my-governance-project/data_class\r\n\r\n\r\n# Level 2: Create a child value under "pii" for "private" data\r\ngcloud resource-manager tags values create private \\\r\n --parent=my-governance-project/data_class/pii\r\n\r\n\r\n# Level 3: Create another child tag value for "email" under "private"\r\n# You can go up to 5 levels deep for granular control\r\ngcloud resource-manager tags values create email \\\r\n --parent=my-governance-project/data_class/private'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe794187dc0>)])]>

ステップ 2: JSON スキーマを使用して列にタグを付加する

1. 既存のスキーマをエクスポートする

既存のテーブルの場合、タグを管理する最も効率的な方法は、JSON ファイルを使用して API または bq CLI でテーブルスキーマを更新することです。これにより、複数の列に一度にタグを付けることができます。

code_block: <ListValue: [StructValue([('code', '# Save the current table schema to a local JSON file.\r\nbq show --schema --format=prettyjson my_project:my_dataset.my_table > schema.json'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe794187490>)])]>

2. dataGovernanceTags を JSON ファイルに追加する

schema.json を開き、機密性の高い列へのタグマッピングを追加します。名前空間付きのキーと値の略称が使用されていることに注意してください。

code_block: <ListValue: [StructValue([('code', '[\r\n {\r\n "name": "user_email",\r\n "type": "STRING",\r\n "dataGovernanceTagsInfo": {\r\n "dataGovernanceTags": {\r\n "my-governance-project/data_class": "email" \r\n }\r\n }\r\n },\r\n {\r\n "name": "phone_number",\r\n "type": "STRING",\r\n "dataGovernanceTagsInfo": {\r\n "dataGovernanceTags": {\r\n "my-governance-project/data_class": "private"\r\n }\r\n }\r\n },\r\n {\r\n "name": "government_id",\r\n "type": "STRING",\r\n "dataGovernanceTagsInfo": {\r\n "dataGovernanceTags": {\r\n "my-governance-project/data_class": "pii"\r\n }\r\n }\r\n }\r\n]'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe7941877f0>)])]>

3. テーブルを更新する

スキーマを BigQuery テーブルに適用します。

code_block: <ListValue: [StructValue([('code', '# Overwrite the table schema with your newly tagged JSON file.\r\nbq update --project_id=my-data-project --schema=schema.json my_dataset.my_table'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe794187a30>)])]>

また、SQL を使用してデータガバナンスタグを BigQuery テーブルの列にバインドすることもできます。

code_block: <ListValue: [StructValue([('code', "CREATE OR REPLACE TABLE my_dataset.my_table(\r\n user_email STRING\r\n OPTIONS (\r\n data_governance_tags = [('my-governance-project/data_class', 'email')]),\r\n );\r\nALTER TABLE my_dataset.my_table\r\nALTER COLUMN phone_number\r\n SET OPTIONS (\r\n data_governance_tags = [('my-governance-project/data_class', 'private')]);\r\nALTER TABLE my_dataset.my_table\r\nADD COLUMN government_id\r\n STRING\r\n OPTIONS (\r\n data_governance_tags = [('my-governance-project/data_class', 'pii')]);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe794187f10>)])]>

また、列タグを削除するには、次のように [] に設定します。

code_block: <ListValue: [StructValue([('code', 'ALTER TABLE my_dataset.my_table\r\nALTER COLUMN phone_number\r\n SET OPTIONS (\r\n data_governance_tags = []\r\n);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe794187d60>)])]>

information_schema COLUMNS ビューを使用して、列タグを確認できます。

code_block: <ListValue: [StructValue([('code', "SELECT\r\n column_name,\r\n data_governance_tags[SAFE_OFFSET(0)].key AS tag_key,\r\n data_governance_tags[SAFE_OFFSET(0)].value AS tag_value,\r\nFROM `my_project.my_dataset.INFORMATION_SCHEMA.COLUMNS`\r\nWHERE table_name = 'my_table'"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe794187b20>)])]>

次のような結果になります。

code_block: <ListValue: [StructValue([('code', '+---------------+----------------------------------+-----------+\r\n| column_name | tag_key | tag_value |\r\n+---------------+----------------------------------+-----------+\r\n| user_email | my-governance-project/data_class | email |\r\n| phone_number | my-governance-project/data_class | private |\r\n| government_id | NULL | NULL |\r\n+---------------+----------------------------------+-----------+'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe794187970>)])]>

ステップ 3: データポリシーを作成する

最後に、BigQuery のデータポリシーを定義して、タグ付けされた列へのアクセスを管理します。これらのポリシーは、以前に付加したタグ値を明示的に参照します。データガバナンスタグはグローバルですが、データポリシーはリージョンに適用される点に注意してください。

データを保護するため、ポリシーは BigQuery テーブルと同じリージョンで作成する必要があります。ポリシーが定義されると、指定されたユーザーのみにアクセス権が付与され、それ以外のすべてのユーザーは機密性の高い列データへのアクセスが拒否されます。

また、BigQuery のセキュリティは階層化されていることに留意してください。データポリシーを有効にするには、ユーザー（被付与者）がまずテーブル自体への基本レベルのアクセス権を持っている必要があります（通常は roles/bigquery.dataViewer などのロールを介して付与される）。これによりデータポリシーは 2 つ目のセキュリティレイヤとして機能し、ユーザーに応じて機密性の高い列の未加工のデータを表示するか、マスクにより難読化されたバージョンを表示するかを決定します。

「pii」タグ付き列データのマスキングポリシー（SHA256 マスキング）

code_block: <ListValue: [StructValue([('code', 'curl --request POST "https://bigquerydatapolicy.googleapis.com/v2/projects/myProject/locations/us-east1/dataPolicies" \\\r\n --header "Authorization: Bearer $(gcloud auth print-access-token)" \\\r\n --header \'Accept: application/json\' \\\r\n --header \'Content-Type: application/json\' \\\r\n --data \'{\r\n "dataPolicy": {\r\n "dataPolicyType": "DATA_MASKING_POLICY",\r\n "dataMaskingPolicy": { "predefinedExpression": "SHA256" },\r\n "grantees": [ "principalSet://goog/group/grp-sales@corp.com" ],\r\n "dataGovernanceTag": { "key": "myProject/data_class", "value": "pii" }\r\n },\r\n "dataPolicyId": "masking_policy_for_data_class_pii"\r\n}\' \\\r\n --compressed'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe794187550>)])]>

「pii」タグ付き列データに対する未加工データアクセスポリシー

code_block: <ListValue: [StructValue([('code', 'curl --request POST "https://bigquerydatapolicy.googleapis.com/v2/projects/myProject/locations/us-east1/dataPolicies" \\\r\n --header "Authorization: Bearer $(gcloud auth print-access-token)" \\\r\n --header \'Accept: application/json\' \\\r\n --header \'Content-Type: application/json\' \\\r\n --data \'{\r\n "dataPolicy": {\r\n "dataPolicyType": "RAW_DATA_ACCESS_POLICY",\r\n "grantees": [ "principal://goog/subject/abc@xyz.com" ],\r\n "dataGovernanceTag": { "key": "myProject/data_class", "value": "pii" }\r\n },\r\n "dataPolicyId": "raw_access_policy_data_class_pii"\r\n}\' \\\r\n --compressed'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe794187af0>)])]>

「private」タグ付き列データのマスキングポリシー（NULL マスキング）

code_block: <ListValue: [StructValue([('code', 'curl --request POST "https://bigquerydatapolicy.googleapis.com/v2/projects/myProject/locations/us-east1/dataPolicies" \\\r\n --header "Authorization: Bearer $(gcloud auth print-access-token)" \\\r\n --header \'Accept: application/json\' \\\r\n --header \'Content-Type: application/json\' \\\r\n --data \'{\r\n "dataPolicy": {\r\n "dataPolicyType": "DATA_MASKING_POLICY",\r\n "dataMaskingPolicy": { "predefinedExpression": "ALWAYS_NULL" },\r\n "grantees": [ "principal://goog/subject/abc@xyz.com" ],\r\n "dataGovernanceTag": { "key": "myProject/data_class", "value": "private" }\r\n },\r\n "dataPolicyId": "null_policy_data_class_private"\r\n}\' \\\r\n --compressed'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe794187880>)])]>

以上の 3 つのステップで、列データの保護は完了です。次回プリンシパルが BigQuery テーブルをクエリすると、Google の認可エンジンが自動的にプリンシパルの ID をデータポリシーと照合して評価します。プリンシパルがポリシーに含まれている場合、ポリシーに従ってマスクされたデータまたは未加工のデータのいずれかが表示されます。プリンシパルがポリシーに含まれていない場合は、アクセスが拒否されます。

使ってみる

データガバナンスタグは、BigQuery のデータセキュリティとガバナンス戦略を強化する強力な新しいツールです。Google は、BigQuery のデータガバナンス機能を強化するために継続的に取り組んでいます。今後のアップデートでは、SQL を使用してタグとタグベースのポリシーを作成する機能、1 つの列に複数のタグを付加する機能、タグの組み合わせに基づいてポリシーを定義する機能、Knowledge Catalog などのサービスとのより深い統合が予定されています。

まずは列へのタグ付けと、きめ細かいアクセス制御を大規模に定義することから始めましょう。詳しくは、データガバナンスタグのドキュメントをご覧ください。

- プロダクトマネージャー、Vignesh Rajamani

- ソフトウェアエンジニア、Pramod Busam

アイドル状態のアクセラレータを最小限に抑える: llm-d での協調型タイムスライスによるネイティブ RL ジョブのインターリーブ

Mon, 03 Aug 2026 02:20:00 +0000

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

大規模言語モデル（LLM）のトレーニング後の強化学習（RL）において、その背後にある数学は妥協が許されないことで知られています。最先端の AI ラボでは、Group Relative Policy Optimization（GRPO）などの RL のトレーニング後のアルゴリズムを使用して推論モデルやコーディングモデルの限界を押し広げるなか、アーキテクチャやインフラストラクチャの厳しい制約に日常的に直面しています。業界の関心の多くは、依然としてアクセラレータの物理容量の獲得に集中していますが、複数の RL ジョブを実行し、モデルをより高いレベルのインテリジェンスに引き上げるために必要な高速性を実現するには、インフラストラクチャの効率も同様に重要です。大規模な分散 RL では、同期サンプリングとトレーニングが厳密に順次フェーズとして実行されるため、トレーナーとサンプラーのリソースが交互にアイドル状態になるため、深刻なリソースボトルネックが発生します。一方、非同期アーキテクチャではこれらのフェーズを重複させようとしますが、トレーナーは、次のサイクルを開始する前に特定の軌跡バッチが完了するのを待つ間、頻繁にアイドル状態になります。

本日は、この構造的な無駄を解消するソリューションとして、llm-d プロジェクトによる協調型タイムスライスをご紹介します。ロールアウトのサンプリングや勾配トレーニングといった個別の RL ステップを、スケジュール可能な動的エンティティとして扱うことで、独立した RL ジョブを共有物理ハードウェアにインターリーブできます。初期ベンチマークでは、このプラットフォームレベルの多重化により、モデルの収束や精度に影響を与えることなく、アクセラレータの集計デューティサイクルがベースラインの約 40% から最大 70% まで向上することが示されています。これにより、時間の経過とともに発生するコンピューティングの無駄がなくなるため、コストパフォーマンスが向上し、TCO の大幅な削減が実現します。

同期設定の場合、プラットフォームはサンプラーとトレーナーの両方をインターリーブして、交互に生じるアイドル時間を最小限に抑えます。一方、非同期ワークロードはタイムスライスを利用して、RL トレーナーのイテレーション間に生じる断片的なアイドル時間を動的に回収して再利用します。

このブログ記事では、このタイムスライスソリューションについて、技術フロー、現在のリリース、今後のロードマップを詳しく説明します。

RL インフラストラクチャの効率化のための llm-d（全体像）

Google は当初から、大規模な RL のトレーニング後にインフラストラクチャに深刻なボトルネックが生じることを予測し、RL ワークロードにおけるインフラストラクチャの非効率性を解消することに取り組んできました。

そのなかで、アクセラレータのアイドル時間をなくすことを重視し、推論、エージェント、RL ワークロード向けの高度にコンポーズ可能なインフラストラクチャスタックに llm-d を組み込みました。RL 向け llm-d スタックには、次のような特徴があります。

スループット重視の推論 （llm-d-router）: RL ワークロード全体にデプロイされ、成熟した、本番環境でテスト済みのエンジンです。ロールアウト生成スループットを最大化してパイプライン常にフル稼働させることに重点を置いています。
高ベロシティの Agent Sandbox （レシピ）: 大規模かつ高密度な環境での検証済みで、ロールアウトの生成と評価中に、安全な 1 秒未満でのツール使用と分離されたコード実行を実現します。Agent Sandbox は、報酬シグナルの生成のための高速インテークマニホールドとして機能し、タイムスライスされた NVIDIA GPU がリソース不足になるような、サンドボックスがレイテンシのボトルネックにならないように設計されています。
コアパイプラインプリミティブ: 重み転送の信頼性と速度の問題に対処するため、Google は Weight Propagation Interface（WPI）を構築するとともに、RL の全体的なオブザーバビリティと信頼性の向上に注力しています。

RL ループにおける効率性の課題

分散型 RL トレーニングの後の運用は、生成（ロールアウトのサンプリング）と最適化（勾配の更新）を交互に繰り返す、断片的で継続的なサイクルとして機能します。従来のクラウドインフラストラクチャは、継続的で安定した状態のワークロード向けに設計されているため、標準の Kubernetes クラスタでは、この交互のリズムに適応できません。

この構造的なケイデンスは、運用が大規模になると、次の 2 つのような大きなシステム上の非効率性を生み出します。

アイドル状態のアクセラレータ: 各フェーズは順次発生するため、GPU クラスタはライフサイクルの 40～60% の間にわたって、完全にアイドル状態（使用率 0%）になります。トレーナーはサンプリングロールアウトが完了するまでアイドル状態で待機し、サンプラーは勾配の更新と重みの分散中にアイドル状態で待機します。これは、年間で数百万ドル規模の資本の無駄につながる可能性があります。
コンテキストのロックイン: RL トレーニングとサンプラーは、NVIDIA CUDA コンテキストとすべてのデバイスメモリを常駐させておく必要があるため、アイドル状態のフェーズでも、ランタイム全体にわたってアクセラレータの割り当てを保持し続けます。標準的なスケジューラでは、これらの Pod を稼働中の RL ループのフェーズレベルでの状態が交互に変化することに合わせるのではなく、静的でサイロ化された割り当てとして扱います。そのため、非アクティブなフェーズでも貴重なハードウェアがロックされたままになります。

重要なのは、これが単なる同期 RL の問題ではないということです。非同期バリアントでは生成とトレーニングが重複して行われますが、アイドル時間を完全に軽減するわけではありません。生成は RL ループ固有のボトルネックであり、ロールアウトデータが蓄積されるのを待っている間、トレーナーアクセラレータは依然としてリソース不足に陥ります。非同期ジョブがポリシーに沿って実行されるほど、こうしたアイドル状態の時間は増大します。生成とトレーニングのずれを制限するバウンドステイルネスにより、新しいロールアウトの準備が整っていない場合はパイプラインが停止するからです。

協調型タイムスライス（RL ジョブのインターリーブ）のメリット

RL ジョブ中にアクセラレータがアイドル状態になるのを防ぐために、llm-d プロジェクトの協調型タイムスライスでは、ハードウェアがアップストリームフェーズを待機するのではなく、インフラストラクチャが独立した RL ジョブを共有ハードウェアブロックに動的にインターリーブできます。これにより、基盤となるモデルの収束や精度を変更することなく、アクセラレータの総使用率を向上させることができます。

同期 RL のフェーズ境界でジョブ A がアイドル状態になると（または非同期 RL で新しいロールアウトデータ待ちでジョブ A が停止すると）、インフラストラクチャは物理アクセラレータをタイムスライスし、ジョブ B のアクティブなサンプリングフェーズまたはトレーニングフェーズに切り替えます。内部的にこの切り替えは、チェックポイント / 復元として扱われます。ジョブ A のデバイス状態全体がアクセラレータメモリからホスト DRAM にチェックポイントされ、代わりにジョブ B の以前に保存された状態が復元されます。アクセラレータを占有するジョブの状態は常に 1 つだけであるため、フレームワークレベルの干渉やメモリ不足（OOM）障害を発生させることなく、ステップを安全に切り替えることができます。

タイムスライス: アーキテクチャの概要

タイムスライスシステムアーキテクチャは、ワークロードスコープ（アプリケーションロジック）、クラスタスコープ（調整）、ノードスコープ（ハードウェア管理）の 3 つのレイヤで構成されています。

ワークロードスコープのレイヤ（アプリケーションランタイム）ユーザーのコードが実行される場所で、トレーニングループ、推論サーバー、RL フレームワークなどがあります。新たに追加されたのは、タイムスライスクライアントライブラリで、タイムスライスオーケストレーターで 2 つの gRPC API を公開します。1 つはアクセラレータへの排他的アクセスをリクエストする acquire() で、もう 1 つはそれを解放する yield() です。ユーザーは、アクセラレータに触れるフェーズをこれらの呼び出しでラップし、オーケストレータにフェーズの境界を通知します。ML フレームワーク（PyTorch FSDP、vLLM など）や、CUDA コンテキスト、アクセラレータメモリ割り当てなど、他はすべて変更なしで実行されます。

クラスタスコープのレイヤ（制御およびオーケストレーションプレーン）このレイヤは、どのジョブがいつアクセラレータにアクセスできるかを決定します。同じ物理アクセラレータを共有するジョブ（例: 同じ GPU ノードセットでインターリーブする 2 つの RL ジョブ）は、1 つのグループに配置されます。タイムスライスオーケストレーターは、グループごとにロックキューを維持します。ロックキューは、そのグループのアクセラレータへの排他的アクセスを待機しているジョブの順序付きリストです。キューの先頭のジョブのみがロックを保持してハードウェア上で実行され、他のすべてのジョブは acquire() 呼び出しでブロックされた状態で待機します。実行中のジョブが yield() を呼び出すと、オーケストレーターはロックをキュー内の次のジョブに渡し、グループ内のすべてのノードで協調的なコンテキスト切り替えをトリガーします。将来的には、ワークロード配置オプティマイザーがワークロードフェーズパターンをプロファイリングし、互いに補完的なアイドルフェーズのジョブを自動的にペアリングできるようになるため、ユーザーがジョブのグループ化を明示的に指定する必要はなくなります。

ノードスコープレイヤ（ハードウェアとデータプレーンの分離）このレイヤは、各アクセラレータノードでチェックポイントと復元の切り替えを実行します。特権 DaemonSet であるスナップショットエージェントは、オーケストレーターから指示を受け取り、それをハードウェアレベルのオペレーションに変換します。具体的には、アクセラレータプロセスを一時停止し、デバイスの状態をホスト DRAM にシリアル化して、ジョブがアクセスを再開したときに復元します。このエージェントは、プラグイン可能なバックエンドインターフェースを中心に構築されており、最初の実装として cuda-checkpoint が使用されています（今後さらに追加される予定です）。今後のバックエンドでは、より高速なスナップショットメカニズムや、デバイスの状態全体ではなく LoRA アダプタなどの特定のメモリアドレスをオフロードするなどの、より選択的なアプローチが導入される見込みです。エージェント自体は、ベアメタル環境と Slurm 環境向けに Kubernetes の外部でスタンドアロンで動作するように設計されています。

フロー: 全体像

ワークロードが現在のアクセラレータフェーズを終了すると、そのタイムスライスクライアントライブラリはタイムスライスオーケストレーターに対して yield() を呼び出し、アクセスを解放します。オーケストレーターは、グループ内の各ノードのスナップショットエージェントに指示を送信して、コンテキストの切り替えを開始します。エージェントは、譲歩するワークロードのプロセスをフリーズし、そのデバイスの状態をアクセラレータメモリからホスト DRAM に移動します。

アクセラレータが解放されると、オーケストレーターはキューで待機している次のワークロードにグループロックを付与します。それらのノード上のスナップショットエージェントに対して、そのワークロードの以前に保存された状態をホスト DRAM からアクセラレータメモリに復元するよう指示し、その後、ワークロードの保留中の acquire() 呼び出しのブロックを解除します。ワークロードは、コンテナの再起動やフレームワークの再初期化、ストレージからのモデル再読み込みを行うことなく、中断したところから正確に実行を再開します。

譲歩したワークロードは、ホスト DRAM でウォーム状態を維持します。オーケストレータが再びロックを許可すると、スナップショットエージェントは同じ切り替えを逆方向に実行します。

開発者エクスペリエンス（クライアントサイド）研究者は、低レベルの CUDA コンテキスト切り替えやカスタムスケジューリングループに煩わされることなく、コアモデリングロジックに集中したいと考えています。RL ジョブのオーケストレーションに Ray や同様のプラットフォームを使用している場合、タイムスライスを使用してもクライアント側への影響は最小限に抑えられます。実際、プラットフォームレベルでトレーニングジョブとサンプリングジョブを別々にキューイングしている場合は、クライアント側にはまったく影響が及ばない可能性があります。

code_block: <ListValue: [StructValue([('code', 'from timeslice import TimeSliceOrchestratorClient\r\n\r\norchestrator = TimeSliceOrchestratorClient(target="orchestrator:50051")\r\n\r\n@orchestrator.on_accelerators(group_id="trainer-group")\r\ndef train_phase(model, trajectories):\r\n return model.update(trajectories)\r\n\r\n@orchestrator.on_accelerators(group_id="sampler-group")\r\ndef generate_phase(model, prompts):\r\n return model.generate(prompts)\r\n\r\n# Standard sequential loop — interleaved with other jobs under the hood\r\nfor epoch in range(EPOCHS):\r\n trajectories = generate_phase(policy, dataset)\r\n rewards = compute_rewards(trajectories)\r\n train_phase(policy, rewards)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe794fe6220>)])]>

現在のリリースと今後の見通し

このたび、タイムスライスのフルスタック（スナップショットエージェント、アクセラレータオーケストレーター、Python クライアントライブラリ）をリリースいたしました。各スタックには、RL ワークロードにタイムスライスを統合するためのユーザーガイドが付属しています。

ロードマップの主なハイライトは次のとおりです。

レイテンシと状態の最適化: より高速なチェックポイント / 復元バックエンドでスナップショットエージェントを拡張し、コンテキスト切り替えのオーバーヘッドを最小限に抑えます。また、アプリケーション対応のバックエンドを使用して、特定のメモリ領域をスナップショットします（例: モデルの重み全体ではなく、LoRA アダプタを切り替え）。
自動スケジューリングとオンボーディング: 実行中のプロセスをプロファイリングし、タイムスライス可能な構造を特定して、ジョブの配置を動的に処理する自動スケジューラを導入します。
ハードウェア間の互換性: データプレーンのサポートを GPU から TPU やカスタムアクセラレータアーキテクチャに拡張します。

使ってみる

堅牢で高度に最適化された RL インフラストラクチャを構築するには、これらのワークロードを大規模に実行するエンジニアや研究者との緊密な連携が不可欠です。

現在課題となっている、トレーニング後のパイプラインでの GPU 使用率の低さ、同期による停止、複雑なスケジューリングロジックは、タイムスライスで解決できます。まずは以下のリソースをご確認いただき、ぜひフィードバックをお寄せください。

これらのユーザーガイドを使用して、RL の実行中にタイムスライスをお試しください。
RL 生成フェーズ中のサンプリングスループットを向上させるには、llm-d-router（Kubernetes ネイティブ）または RL スケジューラ（Python ライブラリ）のユーザーガイドをお試しください。
Weight Propagation Interface のリポジトリをご覧ください。
llm-d Slack の #sig-rl チャンネルでディスカッションにご参加ください。
リファレンス実装、ベンチマーク、エッジケースを共有して、この手法の改善にご協力ください。

このブログ投稿の執筆に協力してくれた Dolev Ish Am と Bogdan Berce に感謝します。

- シニアプロダクトマネージャー、Poonam Lamba

- ソフトウェアエンジニア、Aishu Kamal

10 組の自律型映画制作チームから学んだ、AI エージェントのチームワークのあり方

Mon, 03 Aug 2026 02:10:00 +0000

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

AI エージェントのチームが協力して短編映画を制作することはできるのか？

Google 社内での生成メディアハッカソンの一環として、私たちはこの疑問を検証しました。AI エージェントが、ソフトウェア開発よりもなじみの薄い分野で共同作業できるのかどうかを明らかにするための試みです。各制作チームには、異なる役割を持つ 3 つのエージェントを割り当て、エージェント専用のハッカソンでメッセージや共有ファイルを通じて共同で作業してもらいました。各エージェントは、オープンソースのエージェントオーケストレーションテストベッドである Scion の中で実行しました。コードやテキストとは異なり、メディアや構成は AI エージェントにとってあまり馴染みのないテーマです。そのためこの実験では、エージェントがプロジェクトを完遂するために、チェックやゲートといった検証プロセスとどのように連携するのかについて学ぶことができました。

10 組の制作チームはそれぞれ短編映画を制作し、エージェントがスタッフを務める別のドキュメンタリー制作チームがそのプロセスを「撮影」しました。そのドキュメンタリー自体がハッカソンの提出物となり、メダルを受賞しました。

その結果、このプロジェクトを通じて、数百ものエージェントインスタンスが作成されました。パイロットラウンドとコンペティション全体で 25 件以上の作品が制作され、合計約 44 分に及ぶ映画が完成しました。出力に対する人間のフィードバックは、エージェントが生成したツールを使用して継続的な改善ループに組み込まれました。

エージェントが生成した短編映画の例を 2 つご紹介します。

ペーパーフロンティア

版画家の幽霊

チーム構造

各制作チームには 3 つのエージェントが割り当てられました。アイデア担当者はスクリプトを書き、ビジュアルスタイルを定義しました。技術責任者は、生成メディアツールを操作しました。編集者は、テンポの調整と最終的な仕上げを担いました。チームコーチのエージェントはゲート付きのチェックポイントを監督しましたが、脚本の執筆や演出は行いませんでした。

まずアイデア担当者が 3 つのアイデアを生成し、そのアイデアをチームそれぞれの役割の視点から評価しました。生成メディアでうまく生成できるか、編集作業は複雑になるかといった評価の後、ハッカソンに参加している他のチームにアイデアを発表し、チームが調整や方向転換を行えるようにしました。たとえば、3 つのチームがすべて SF 宇宙戦争をテーマに選んでしまうと、コンペティションの作品としてはあまり面白くなくなります。

コーディネーターエージェントがコンペティションの進行を管理し、5 回にわたって 2 チームずつで競いました。このイベントの所要時間は約 21 時間でした。

制作チームは、従来の映画制作手法の基本であるコンセプト、ビートシート、キャラクターワークショップ、ストーリーボード、本撮影、アセンブリ、最終レンダリングという 7 ステップのパイプラインに従いました。各ステップには検証ゲートを設け、少なくとも 1 つのエージェントが他のエージェントの作業を技術的なコンプライアンス（解像度やタイミングなど）についてチェックするようにしていました。

初期のパイロット版では、あるチームが映画の完成を報告しましたが、それは 94 バイトのプレースホルダファイルでした。エージェントは、実際には完了していない作業を、さも完了したかのように自信を持って報告できてしまうことがわかりました。

驚くべきことに（ときには面白いことに）、エージェントたちが自分たちの判断で、映画を独自の方向へと導いていたケースが他にも見つかりました。たとえばエージェントは、私たちが予想していなかった方法で独自に作業を分担しました。あるチームでは、アイデア担当者が最初のドラフトとして散文を 1 行書きました。編集者は、そのセリフの前後 8 秒に無音部分を設け、タイムラインに「交渉不可」とマークしました。技術責任者は、適切なフレームで花束から花が 1 本離れるまで、1 つのショットを繰り返し再生成しました。この作業について、エージェントたちは連携しておらず、それぞれが共有されたファイルを読み込んで独自の編集判断を下していました。

チームワークやツールの使用に関するこのプロセスは、試験運用フェーズでエージェントと共同で作り上げられたものです。このフェーズでは、エージェントのチームが動画を作成し、それに対して人間がフィードバックを行いました。指摘事項には、音声の重なりや音量レベルの不備、キャラクターの一貫性の欠如、ストーリーやナレーションのわかりにくさなどがありました。

このフィードバックと、エージェントが作成した各試験運用の振り返りを組み合わせて、エージェントたちは今後のチームにプロセスを指示するためのハンドブックやガイドを再構築しました。それだけでなく、エージェントたちは Golang CLI と Python のバッチ自動化を組み合わせたカスタムメディアツールチェーンを自ら構築し、改良まで行いました。

生成メディアモデル

各映画は、複数の Google AI モデルを組み合わせて生成されました。エージェントは、genmedia という共有 CLI ツールキットを使用してこれらのツールを呼び出しました。

Gemini の画像生成（Nano Banana）で、キャラクターの参照シート、ストーリーボードのフレーム、シーンの構成が生成されました。エージェントは、参照チェーンを使用して、映画全体でキャラクターのビジュアルの一貫性を保ちました。まずヘッドショットを生成し、それをボディシートの入力として使用し、ボディシートをシーンテストの入力として使用しました。各生成呼び出しでは、これらの蓄積された参照をアンカーとして使用しました。

動画は Veo 3.1 で生成されました。クリップは 720p で 4～8 秒の長さになります。エージェントは、ショットに応じてさまざまな生成モードを選択し、シンプルな構図にはテキストから動画への変換、ストーリーボードのフレームに固定されたショットには画像から動画への変換、正確な開始フレームと終了フレームが必要な場合はフレーム補間を使用しました。8 秒を超えるショットでは、あるクリップの最後のフレームを次のクリップの最初のフレームとして使用しました。

Veo 3.1 は、各クリップ内の音声（環境音、ルームトーン、キャラクターとリップシンクされたセリフなど）も生成します。Lambda チームは、この機能を軸にして映画を制作しました。生成された音声と唇の動きを同期させることで「間」の重みを際立たせるため、脚本を楽譜に見立てて速度記号（Allegretto、Accelerando、Adagio）を使用して構成しました。

Lyria 3 はオリジナルの音楽を生成しました。ある編集者は、動画撮影前に 3 楽章構成のジャズの楽譜を作成し、それを制作のマスタークロックとして使用しました。また、チームはプロンプトを「サウンドスケープ」として表現することで、Lyria に効果音も生成させました。

Gemini Flash TTS は、特定の音声ペルソナとスタイル指示（「人生に疲れたナレーター、ゆっくりとしたペース」など）を組み合わせて、キャラクターの音声やナレーションを生成しました。テキスト音声変換が話すペースは予測困難でした。あるチームのナレーターは、予定していた 1 分あたり 130 語ではなく 108 語で話したため、再生時間が丸 1 分も長くなってしまいました。別のチームも同様の問題を抱えていましたが、68 歳の映写技師というキャラクター設定にはスローペースが合うと判断しました。

4 分間の映画を 1 本制作するために、40 回以上の画像生成、25 本以上の動画クリップ、複数の音楽ステム、12 件の音声録音、そして数百回に及ぶ組み立て作業が必要でした。

Scion: オーケストレーションシステム

これらのエージェントは、オープンソースのマルチエージェントオーケストレーションテストベッドである Scion で実行されました。Scion は、テンプレート（ペルソナ、指示、スキル、ツール）に基づいてエージェントを定義し、コンテナ化されたサンドボックス内で実行します。各エージェントは共有 CLI を通じて他のエージェントを生成してメッセージ送信ができるほか、イベントドリブン型の通知によって起動し、プロジェクト内の全エージェントに共有ファイルシステムへのアクセスを付与することもできます。

メッセージと通知を活用することで、共通のワークフローに沿った連携が可能になりました。プロセスの各段階では、それぞれのエージェントが自身の役割に特化した貢献を行いました。つまり、複雑なプロセスを複数のコンテキストウィンドウに「シャーディング」できるようになったのです。これらのコンテキストウィンドウには、長時間維持されたものもあれば、短期間で消滅したものもありました。Scion はモデルとハーネスに依存しないため、さまざまなモデルとハーネスの組み合わせが使用されました。同じエージェントテンプレートを、Claude、Gemini、Codex のいずれでも動かすことができます。

共有ファイルシステムにより、レジリエンスが確保されました。エージェントがクラッシュしたり、コンテキストウィンドウを使い果たしたりしても、システムによって再起動されます。書き出されたファイルはそのまま残ります。最終アセンブリの作業中に、あるチームの編集者がクラッシュしたとき、技術責任者はその編集者のタイムライン計画を開いて読み、作業を完了させました。コーディネーターは、プロジェクトの期間中、ドキュメンタリー制作担当のエージェントを何度も再起動させました。新しく起動したインスタンスは、前のインスタンスが残したファイルを読み取って作業を引き継ぎました。

今回の実験でわかったこと

エージェントの共同作業には、メッセージよりもファイルを通じたやり取りの方が適しています。決定事項（プロンプトに含めるビジュアルキーワード、タイムライン上のショットの配置、スコアから除外する楽器など）を書き留めていたチームは、システムがクラッシュしても、進むべき方向を見失わずに復旧することができました。メッセージの履歴に決定事項を保存していたチームは、エージェントが再起動すると決定事項を見失っていました。効果的な組み合わせは、ファイルパスを含むメッセージを渡すことでした。

AI 生成の強みに合ったスタイルを選ぶことで、より良い映画を制作できます。その独特なカクカクとした動きで映像のズレが気にならなくなるという理由で、クレイアニメーションは複数のチームに選ばれていました。また、顔の整合性の問題を回避できるという理由でシルエットアニメーションも選ばれていました。あるチームは、セーフティフィルタによる制限でキスシーンを生成できませんでした。代わりに、壁に映る 2 つの影が合わさる様子を見せました。コーチは、そのシーンを映画で最も印象的なカットだと評しました。

具体的なプロンプトは、大まかな指示よりも効果的です。動画生成のデフォルトの出力は、情緒的で映画のようなノワール調になります。独自性のある作品を制作したチームは、色の名前ではなく 16 進数のカラーコードを指定し、使用を禁止する楽器をリストアップし、望ましくないスタイルを排除するための否定型のプロンプトを作成していました。「暖かみのある感じにして」といった指示では、ありきたりな結果しか得られませんでした。「#F4A261, no string instruments, no lens flare」（#F4A261、弦楽器なし、レンズフレアなし）の結果はそうではありませんでした。

検証ゲートにコーチ役を配置したことで、成果が大きく変わりました。コーチは制作の全工程を把握することはできましたが、介入できるのは各ステップの節目のみでした。この制約があるため、コーチはプロセスの細やかな管理はできず、完成した成果物の評価しかできませんでした。あるコーチはこの状況を、「超人的なスピードで特定の作業をこなせる専門家ばかりが集まっているのに、誰一人としてそのスープの味見ができない状態」と表現しました。

詳細

ドキュメンタリーの全編はこちらでご覧いただけます。Scion Framework の詳細と、ハッカソンでの使用方法についてもぜひご覧ください。

- プロダクトマネージャー、Preston Holmes

- テクニカルソリューションマネージャー、Hussain Chinoy

AlloyDB AI で PostgreSQL の多言語全文検索における制限を解消する方法

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

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

AlloyDB は、いくつかの世界最大規模の組織において、エンタープライズグレードの検索を強化し、テキスト検索、ベクトル検索、キーワード検索をシンプルなランク付けされた SQL クエリに組み合わせる堅牢なハイブリッド検索機能を提供しています。また、最近リリースされた RUM インデックスのサポートにより、AlloyDB のお客様はさらに強力な全文検索機能をすぐに利用できるようになりました。

しかし、データベース開発者は、中国語、日本語、韓国語などの表語文字言語の連続するテキストをインデックス化する際に、従来の空白ベースのトークン化は機能しないという制限に直面しています。Gemini の多言語機能を使用すると、これらの言語のテキストをインテリジェントに解析して、高度な単語分割とストップワードの削除を実装できますが、大規模なデータセットで行単位の API 呼び出しをオーケストレートすると、処理が遅く、脆弱なものになります。AlloyDB AI 関数を使用すれば、Gemini モデルが持つ広範な知識をデータベースにネイティブに統合できるため、複雑な ETL パイプラインの管理オーバーヘッドなしで、表語文字言語の全文検索を高い精度で実行できるようになります。

連続したテキストと表語文字言語

このネイティブ統合が大きな進歩であることを理解するには、まずテキスト検索の基本的な仕組みと、連続したテキストの処理には従来のインデックス手法が機能しない理由を確認する必要があります。

PostgreSQL で効果的な全文検索インデックスを構築するには、エンジンが to_tsvector 関数を使用してテキストを解析し、検索トークン（語彙素）に分割する必要があります。simple や english などの標準的なテキスト検索構成では、デフォルトで単語が空白で区切られていると想定されます。データベースエンジンは、これらの空白位置で入力文字列を分割し、検索語句を抽出します。

しかし、中国語などの表語文字言語では、単語の間に空白は使用されません。単語は連続して記述され、境界を示すのは句読点のみです。そのため、標準の PostgreSQL パーサーでは個々のキーワードを抽出できません。代わりに、文全体や長い句を 1 つの連続した語彙素として扱います。

たとえば、入力文字列が「你们研究所有十个图书馆」（研究所には図書館が 10 館あります）であるとします。

この文字列を to_tsvector('simple', ...) に渡すと、空白がないため、「你们研究所有十个图书馆」という 1 つの長い語彙素が生成されます。

そのため、「研究所」または「图书馆」（図書館）を検索しても、一致は返されません。キーワードが長い文字列の中に埋め込まれているため、長い文字列を正確に指定して検索しなければ、結果は得られません。

従来の方法とその限界

従来のツールやパイプラインを使用してこの問題を解決しようとすると、どちらを使用した場合でも、大きな運用上の摩擦や精度の限界が生じます。

サードパーティのデータベース拡張機能: zhparser や pg_jieba などの拡張機能は、PostgreSQL に中国語トークン化機能を追加します。ただし、これらの機能は、フルマネージドデータベース環境ではサポートされていないことがほとんどです。また、定義済みの固定の辞書に依存しているため、最新の専門用語、ブランド名、文脈に依存する用語を正しく解析できないことがよくあります。
外部の前処理パイプライン: テキストを外部アプリケーション（jieba や spaCy を実行する Python マイクロサービスなど）にエクスポートし、スペースを挿入してデータベースに保存します。このパターンでは、データベース層外にデータを移動するため、ETL が大幅に複雑化し、ネットワークレイテンシが発生し、データ漏洩のリスクが高まります。
ルールベースおよび辞書を利用した分割では不十分: 従来のトークナイザーは、固定の辞書と手動でコーディングされた構文ルールに依存してテキストを分割しますが、セマンティックな曖昧さにより、まったく同じ文字シーケンスでも、コンテキストに応じて分割方法を変えることが必要となるため、それを解消するのは困難です。正確な分割を行うには、Gemini のような大規模言語モデルが有する世界中の知識とコンテキストインテリジェンスが必要です。

Gemini を使用したデータベース内での前処理

AlloyDB AI では、ai.generate() などのネイティブなデータベース内 AI 関数が導入されているため、これらの回避策は必要はなく、その限界に制限されることもありません。SQL から直接 Gemini を呼び出すことができるため、データとインテリジェンスは 1 箇所に保持されます。

このアプローチには、主に 3 つの利点があります。

データの移動なし: テキストの前処理と分割はすべて、データベースエンジン内で直接行われます。これにより、ネットワークレイテンシが最小限に抑えられ、データはデータベースの境界内で保護されます。
データベース内インテリジェンス: 外部マイクロサービスやオーケストレーションフレームワークを構築、デプロイ、保守する必要はありません。モデルの呼び出しは、データベースエンジンによりネイティブに調整されます。
ストアドプロシージャベースのバッチ処理: 配列集計が組み込まれた PL/pgSQL ストアドプロシージャを使用すると、行を並列バッチで処理し、GENERATE_SERIES を使用して結果を安全に展開して、各バッチを即座に commit できます。これにより、大規模なテーブルを処理する場合でも、データベースのメモリ枯渇や行ロックの競合が回避され、安定した高パフォーマンスの実行を実現できます。

セマンティック単語分割の実装

このソリューションを実装するために、元のコンテンツ、分割されたテキスト、検索ベクトル、ベクトルエンベディングをまとめて保存するデータベーステーブルを作成します。

code_block: <ListValue: [StructValue([('code', "CREATE TABLE documents (\r\n id SERIAL PRIMARY KEY,\r\n title TEXT NOT NULL,\r\n original_content TEXT NOT NULL,\r\n content_segmented TEXT,\r\n search_vector tsvector GENERATED ALWAYS AS (to_tsvector('english', content_segmented)) STORED,\r\n embedding vector(3072) GENERATED ALWAYS AS (embedding('gemini-embedding-001', content_segmented)) STORED\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe794919c40>)])]>

search_vector と embedding を生成された列として定義することにより、content_segmented 列が更新されるたびに、AlloyDB で全文検索インデックスとベクトルエンベディングの両方が自動的に更新されます。これにより、アプリケーション側のロジックが 1 つの UPDATE ステートメントに削減されます。

ステップ 1: ドキュメントのバッチ分割

AlloyDB AI のドキュメントでは、大規模なデータセット（10,000 行から数百万行）を扱う場合、メモリのボトルネックを回避するために、カーソルベースの処理を使用することが推奨されていますが、

ドキュメントのカーソル例は、INSERT を使用して新しい空のテーブルにテキストをストリーミングする、追加専用の演算に重点を置いています。このブログ投稿のユースケースでは、ライブの documents テーブルでインプレース UPDATE を行う必要があります。標準的な匿名ブロック（DO $$）で未加工のカーソルループを使用してこれを実装すると、本番環境で発生する可能性のある重大なリスクがあります。ライブアプリケーションをフリーズさせる過剰な行ロック、ネットワークの障害が発生した場合のロールバックリスク、並列カーソルが同期しなくなるアライメントリスクの 3 つです。

これらのリスクを軽減し、パフォーマンスを向上させるために、高スループットの配列ベースのバッチ処理を実行するよう構成されたストアドプロシージャを使用します。

code_block: <ListValue: [StructValue([('code', "CREATE OR REPLACE PROCEDURE segment_all_documents(p_batch_size INT DEFAULT 100)\r\nLANGUAGE plpgsql AS $$\r\nDECLARE\r\n v_processed_count INT;\r\nBEGIN\r\n LOOP\r\n -- 1. Grab a single isolated batch, aggregate into arrays, and call Gemini.\r\n -- We explicitly ORDER BY id during aggregation to guarantee the arrays match perfectly.\r\n WITH batch_raw AS (\r\n SELECT id, original_content\r\n FROM documents\r\n WHERE content_segmented IS NULL OR content_segmented = ''\r\n ORDER BY id\r\n LIMIT p_batch_size\r\n ),\r\n batch_processed AS (\r\n SELECT \r\n ARRAY_AGG(id ORDER BY id) AS target_ids,\r\n ai.generate(\r\n prompts => ARRAY_AGG('Perform Chinese word segmentation (分词) on the provided text to prepare it for full-text search indexing.\r\nRules:\r\n- Insert a single space between every atomic, meaningful word.\r\n- Separate all punctuation marks (both full-width and half-width) with spaces.\r\n- Preserve the original structure, line breaks, and non-Chinese characters (e.g., English words, numbers).\r\n- Output ONLY the processed text. Do not include any greetings, explanations, or formatting wrappers like markdown code blocks unless they exist in the original text.\r\nText to process: ' || original_content ORDER BY id),\r\n model_id => 'gemini-2.5-flash-lite'\r\n ) AS ai_outputs\r\n FROM batch_raw\r\n ),\r\n -- 2. Use GENERATE_SERIES to unpack the paired array indexes safely\r\n unpivoted_results AS (\r\n SELECT \r\n b.target_ids[i] AS doc_id,\r\n b.ai_outputs[i] AS segmented_text\r\n FROM batch_processed b,\r\n GENERATE_SERIES(1, COALESCE(ARRAY_LENGTH(b.target_ids, 1), 0)) i\r\n )\r\n -- 3. Execute the batch update for this chunk\r\n UPDATE documents d\r\n SET content_segmented = r.segmented_text\r\n FROM unpivoted_results r\r\n WHERE d.id = r.doc_id;\r\n\r\n -- Check how many rows were updated in this pass\r\n GET DIAGNOSTICS v_processed_count = ROW_COUNT;\r\n\r\n -- If the update affected 0 rows, it means the whole table is finished\r\n EXIT WHEN v_processed_count = 0;\r\n\r\n -- 4. Commit immediately to save progress and release row locks!\r\n COMMIT;\r\n \r\n RAISE NOTICE 'Successfully processed and committed a batch of % rows.', v_processed_count;\r\n END LOOP;\r\nEND $$;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe7949199d0>)])]>

テーブル全体に対してこの前処理パイプラインを実行するには、ストアドプロシージャを呼び出します。

code_block: <ListValue: [StructValue([('code', 'CALL segment_all_documents(100);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe794919c10>)])]>

このストアドプロシージャを使用するアプローチには、本番環境での課題を直接解決する次の 3 つの利点があります。

配列の並列集計（シーケンスのボトルネックを解消）: バッチを配列に集計し、配列を指定して ai.generate(prompts => ...) を呼び出すことで、AlloyDB がモデルのリクエストをバッチ処理し、並列実行します。これは、行を 1 つずつ順に処理するよりも高速です。
インデックスベースの安全な展開（カーソルの同期ずれを解決）: GENERATE_SERIES を使用して配列インデックスを展開すると、モデル出力が正しいドキュメント ID にマッピングされ、並列ストリームの同期ずれが発生するリスクが軽減されます。
即時 commit とロック解除（ブロッキングとロールバックのリスクを解消）: COMMIT; を使用して各ループイテレーションの最後にトランザクションを commit することは、重要な最適化です。進行状況がすぐにディスクに保存され、行ロックが解除されるため、トランザクションの長時間実行によりライブアプリケーションがフリーズするのを防ぎ、ネットワーク障害によって数時間分の作業がロールバックされないようにします。

このパイプラインを実行すると、上記の例の文は content_segmented に「你们研究所有十个图书馆」として保存されます。

ステップ 2: simple と english の選択

生成された tsvector 列を定義する際は、適切な PostgreSQL テキスト検索構成を選択する必要があります。この選択はデータセットによって異なります。

simple を使用する場合: データベースに中国語のテキストのみが含まれている場合は、simple 構成が最適です。この構成ではテキストが小文字に変換されますが、ステミングやデフォルトのストップワードの削除は実行されません。モデルのプロンプトでセマンティック分割とカスタムストップワードフィルタリングが処理されるため、simple 構成は、それ以上の変更を加えることなく、モデルの最適化された出力に直接マッピングされます。
english を使用する場合: 最新のエンタープライズアプリケーションでは、中国語のドキュメントやユーザーのクエリに、英単語（商品コード、ブランド名、技術用語など）が含まれていることがよくあります。これらのバイリンガルシナリオでは、english 構成の方が優れています。英語の Porter ステマーは、非 ASCII の中国語文字は語彙素としてそのまま残しながら、英単語を自動的に正規化（例: 「running」を「run」にステミング）し、一般的な英語のストップワード（「the」、「and」）をフィルタリングします。これにより、個別の列や複雑なルーティングロジックを必要とせずに、バイリンガル検索機能を統合できます。

ステップ 3: クエリ時の前処理

ドキュメントコンテンツの分割は、処理の半分にすぎません。インデックス化されたデータと一致させるには、入力された検索クエリを、同じ Gemini ベースのセグメンテーションロジックを使用して前処理する必要があります。

検索の精度を向上させるため、これをさらに一歩進めます。モデルをインテリジェントなストップワードフィルタとして機能させ、検索結果に不要な要素を追加する価値の低い文法的なノイズを取り除くよう指示できます。

文法助詞（例: 的、了）
代名詞（例: 你、我们）
比較語（例: 比、最）
疑問詞（例: 怎么、为什么）

たとえば、SQL クエリを使用して、ユーザーのクエリをその場で処理できます。

code_block: <ListValue: [StructValue([('code', "SELECT ai.generate(\r\n '提供されたテキストに対して中国語の単語分割（分词）を実行してください。\r\n さらに、助詞（例: 的、了）、代名詞（例: 你、我们）、比較語（例: 比、最）、疑問詞（例: 怎么、为什么）などの価値の低い文法的なノイズを削除してください。\r\n ルールは次のとおりです。\r\n - 残りのテキストで、意味のある最小単位の単語の間に半角スペースを 1 つ挿入する。\r\n - 処理されたキーワードのみを出力する。挨拶や説明は含めない。\r\n 処理するクエリ: 你们研究所的图书馆在哪里？'\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe794fe6610>)])]>

モデルはこのクエリを処理し、キーワード文字列「研究所图书馆」を返します。

ステップ 4: RUM で検索を実行する

ドキュメントを分割してインデックス化したら、生成された search_vector 列に RUM インデックスを作成できます。RUM インデックスは、語彙素の位置を直接保存するインデックスタイプです。これにより、AlloyDB は検索の関連性と単語の距離をインデックス内で直接計算できるようになり、従来の GIN インデックスで必要だった低速の再スキャン操作を回避できます。

code_block: <ListValue: [StructValue([('code', 'CREATE INDEX idx_docs_rum\r\nON documents\r\nUSING rum (search_vector rum_tsvector_ops);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe794fe6cd0>)])]>

検索を実行するには、前処理されたクエリ文字列（「研究所图书馆」）を plainto_tsquery を使用して検索クエリに変換し、RUM インデックスに対して実行します。RUM 距離演算子（<=>）を使用すると、結果を関連度順に並べ替えることができます。

code_block: <ListValue: [StructValue([('code', "SELECT id, title, original_content,\r\n search_vector <=> plainto_tsquery('english', '研究所 & 图书馆') AS distance\r\nFROM documents\r\nWHERE search_vector @@ plainto_tsquery('english', '研究所 & 图书馆')\r\nORDER BY distance ASC;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe794fe68e0>)])]>

RUM インデックスは距離スコアを直接計算するため、このクエリは効率的に実行され、関連する一致が数ミリ秒で返されます。

ハイブリッド検索への拡張

キーワードベースのテキスト検索は、完全一致を見つけるには優れていますが、異なる用語を使用している関連ドキュメントを見逃す可能性があります。これを解決するには、多言語対応の gemini-embedding-001 モデルを使用して、分割された全文の検索とセマンティックベクトル検索を組み合わせます。ハイブリッド検索と呼ばれるこのパターンでは、語彙的にも意味的にも関連する結果が取得されます。

AlloyDB を使用すると、ハイブリッド検索を簡単に実行できます。embedding 列に ScaNN インデックス（Google のベクトルインデックス技術）を作成し、RUM インデックスと組み合わせることができます。

ScaNN インデックスの作成

ベクトル検索を高速化するために、embedding 列に ScaNN インデックスを作成します。

code_block: <ListValue: [StructValue([('code', 'CREATE EXTENSION IF NOT EXISTS alloydb_scann;\r\n\r\nCREATE INDEX idx_docs_scann\r\nON documents\r\nUSING scann (embedding cosine);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe794fe6430>)])]>

ハイブリッド検索クエリの実行

ベクトル検索の結果とテキスト検索の結果を組み合わせるには、Reciprocal Rank Fusion（RRF）を実装する SQL クエリを使用できます。RRF は、ランクベースのアルゴリズムの一種で、複数の検索結果リストを 1 つの統合リストにマージするために、個々のリストにおけるドキュメントのランクに基づいて、各ドキュメントにスコアを割り当てます。

次のクエリは、共通テーブル式（CTE）を使用して両方の検索を並行実行し、FULL OUTER JOIN を使用して結果を結合して、最終的な RRF スコアを計算します。

code_block: <ListValue: [StructValue([('code', "WITH vector_search AS (\r\n SELECT id,\r\n RANK() OVER (ORDER BY embedding <=> ai.embedding('gemini-embedding-001', '研究所图书馆')::vector) AS rank\r\n FROM documents\r\n ORDER BY embedding <=> ai.embedding('gemini-embedding-001', '研究所图书馆')::vector\r\n LIMIT 10\r\n),\r\ntext_search AS (\r\n SELECT id,\r\n RANK() OVER (ORDER BY search_vector <=> plainto_tsquery('english', '研究所 & 图书馆')) AS rank\r\n FROM documents\r\n WHERE search_vector @@ plainto_tsquery('english', '研究所 & 图书馆')\r\n ORDER BY search_vector <=> plainto_tsquery('english', '研究所 & 图书馆')\r\n LIMIT 10\r\n)\r\nSELECT\r\n COALESCE(vector_search.id, text_search.id) AS id,\r\n COALESCE(1.0 / (60 + vector_search.rank), 0.0) + COALESCE(1.0 / (60 + text_search.rank), 0.0) AS rrf_score\r\nFROM vector_search\r\nFULL OUTER JOIN text_search ON vector_search.id = text_search.id\r\nORDER BY rrf_score DESC\r\nLIMIT 5;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe795b213d0>)])]>

クエリの説明:

vector_search CTE は、gemini-embedding-001 モデルを使用し、ScaNN インデックスを利用してクエリに意味的に最も近い上位 10 件のドキュメントを検索します。
text_search CTE は、RUM インデックスを使用して、分割されたキーワードに一致する上位 10 件のドキュメントを検索します。ランキングには RUM 距離演算子が使用されます。
最後の SELECT ステートメントでは、これらのリストを結合し、標準定数 60 を使用して RRF スコアを計算します。キーワードの完全一致とセマンティックの一致を高い精度で組み合わせた、上位 5 件の結果が返されます。

検索に AlloyDB AI が最適な理由

AlloyDB AI を使用して多言語検索とハイブリッド検索の課題を解決することで、エンタープライズ AI アプリケーションの堅牢でスケーラブルかつ費用対効果の高い基盤を構築できます。

ネイティブのデータベース内インテリジェンス: AlloyDB AI 内で直接モデル処理を実行することにより、トランザクションデータを外部の AI サービスに移動する場合の費用、レイテンシ、データ漏洩のリスクを回避できます。
エンタープライズグレードの検索パフォーマンス: ScaNN ベクトル検索（Google の検索テクノロジーをベースに構築）と RUM 全文検索を単一のリレーショナルデータベースに統合することで、複雑な検索エンジンを個別に維持することなく、高速かつ正確な検索結果が得られます。
高いコンテキストアウェア精度: 最新の用語が含まれていないルールベースの固定の辞書とは異なり、Gemini の世界中の知識を活用して深く意味を理解した単語分割が行われるため、高い検索精度を実現します。
運用の簡素化: 標準 SQL を使用して、堅牢なバイリンガル検索機能とハイブリッド検索機能を利用できます。つまり、新しい API を習得したり、複雑な外部パイプラインを管理したりすることなく、すでに持っているデータベースのスキルを使用して AI アプリケーションを構築し、スケールできます。

次のステップ

アプリケーションがトランザクションデータと安全かつ効率的にやり取りできるようにすることで、断片化されたデータサイロから、AI が企業の実体に確実にアクセスできるアーキテクチャへと移行できます。

構築を始める準備ができたら、30 日間の無料トライアルで AlloyDB をお試しください。また、AlloyDB でハイブリッド検索を使ってみる Codelab を活用して、アプリケーションでインテリジェントな検索エクスペリエンスの構築を今すぐ始めましょう。

- クラウドソリューションアーキテクト、Charlie Wang

- AlloyDB AI プロダクトマネージャー、Paul Ramsey

Open Knowledge Format v0.2 におけるエージェントの信頼性担保の取り組み

Fri, 31 Jul 2026 02:30:00 +0000

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

2026 年 6 月に Open Knowledge Format（OKF）を導入した際、Google は「エージェントに必要なコンテキスト（テーブルスキーマ、指標の定義、ランブック）は特定のサービスや非構造化テキストに散在させるのではなく、単一の標準形式として定義されるべきだ」と提言しました。こうした方針のもと、OKF v0.1 はマークダウン、YAML フロントマター、そしていくつかの規則のみで構成されるシンプルな形でスタートしました。

デベロッパーコミュニティからの多大な反響と貢献は、次期バージョンの重点事項を決める指針となりました。リリース以来、コントリビューターによって拡張機能の提案（型付き関係エッジ、エージェントルーティングヒントフィールド、オプションの消去適合性プロファイル、.okfignore 規則など）が作成され、新しいサンプルバンドルが提供されたほか、Google 以外で構築された OKF エコシステムツールのカタログ化も始まりました。こうした貢献やフィードバックの多くは、OKF に関するある大きな懸念を示していました。それは「エージェントによるコーパスへの書き込みは本当に信頼できるのか」という点です。

最も価値のある OKF バンドルは、一度手作業で作成して、その後は読み取られるだけというものではありません。エージェントによって継続的に書き込まれ、また別の一連のエージェントによって使用されるものです。人間が作成した Wiki ページには、暗黙の保証が伴います。それは、人間が書いたものであり、誤りがあった場合は執筆者に責任を問えるという点です。エージェントが一晩で 1 万個のコンセプトを生成する場合、その保証はありません。説明責任を確保するため、コンシューマ（多くの場合、別のエージェント）は、人間に頼る代わりに明示的なシグナルに基づいて各コンセプトを判断し、次の 5 つの質問に答える必要があります。

何をもとに作成されたのか？（来歴）
どの程度信頼できるか？（信頼）
この内容は今でも有効か？（鮮度）
最新のバージョンか？（ライフサイクル）
この数値は指定した方法で生成されたものか？（証明）

OKF v0.2 では、形式は v0.1 と同様に設計上の制約は最小限に抑えながら、フロントマターの情報だけで上の 5 つの質問すべてに回答できるようになりました。追加されるのはルールではなく語彙です。type が唯一の必須フィールドである点は変わらず、新しく追加されたフィールドはすべて任意となります。カスタムキーも拒否されず保持されるため、新しいフィールドを一切使わないバンドルも v0.1 のときと同様に有効なものとして扱われます。新機能のフィールドはすべて任意ですが、フィールドが存在しないこと自体も意味（未検証であること）を持つようになります。これにより、未検証と検証済みのコンセプトを識別できるようになりますが、未検証だからといってエラーとして扱われることはありません。

説明から意思決定まで

v0.1 では、type、title、description、resource、tags といったメタデータがすでにフロントマターに含まれていました。従来のフィールドがコンセプト（それが何であるか、何を指しているか）を説明するものであるのに対し、v0.2 では、コンセプトを読む前にそのコンセプトの妥当性を判断するための新たなフロントマターフィールドが追加されました。たとえば、誰が作成したか、検証済みか、まだ最新か、報告する値をどのように計算すべきかなどの情報がここに含まれます。

これらのフィールドがフロントマターに含まれているのは、コンセプトとのやり取りのほとんどが本文の情報を読み込む手前の段階で終わるためです。コンシューマ（人間、決定論的コード、検索や探索の過程でスキャンを行うエージェントなど）は、まずそのコンセプトにそもそも関連性があるかどうかを判断しなければなりません。コンセプトのあらゆる要素は簡潔であるべきですが、フロントマターの役割はさらに限定的で、関連性と信頼性を判断するために必要なシグナルのみを的確に抽出することに絞り込まれています。そのため、説明文にトークンを費やすことなく、安価かつ頻繁に判断を下すことができます。全文を読み込む必要があるコンテンツは本文に格納され、コンセプトが選択された場合にのみアクセスされます。信頼性は、実際に読み込む前にフィルタリングできるものになります。

以降のセクションの内容を具体的にイメージしていただけるよう、ここからはこの投稿の補足として用意した acme_retail という小規模な OKF v0.2 バンドルから引用した例を使って説明していきます。acme_retail は、BigQuery で AI を活用して分析を行っている架空の米国小売企業の共有ナレッジです。

code_block: <ListValue: [StructValue([('code', 'acme_retail/\r\n├── index.md, log.md\r\n├── tables/ orders.md\r\n├── metrics/ revenue.md, gross-margin.md, gross-margin-legacy.md\r\n├── computations/ revenue-ytd.md, gross-margin-period.md\r\n├── skills/ run-on-bq.md\r\n├── attesters/ sql_equality.py\r\n└── policies/ revenue-recognition.md, margin-standard.md'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe795920670>)])]>

以降の各セクションは、対応するファイルの内容を示します。以下は新しいシグナルを伝えるコンセプトである tables/orders.md です。

code_block: <ListValue: [StructValue([('code', "---\r\ntype: BigQuery Table\r\ntitle: Customer Orders\r\ndescription: One row per completed customer order across web, mobile, and marketplace channels. The grain is the order, not the line item.\r\nresource: https://bigquery.googleapis.com/v2/projects/acme/datasets/sales/tables/orders\r\ntags: [sales, orders, revenue]\r\ngenerated: { by: reference_agent/gemini-2.5-pro, at: 2026-06-30T14:00:00Z }\r\nverified:\r\n - { by: human:kliu@acme, at: 2026-07-01T16:00:00Z }\r\nstatus: stable\r\nstale_after: 2026-12-31\r\nsources:\r\n - id: warehouse-schema\r\n resource: https://wiki.acme.internal/data/warehouse/schemas/sales\r\n title: Acme Retail warehouse schema — sales dataset\r\n author: team:data-platform\r\n usage_count: 1240\r\n last_modified: 2026-06-15\r\n - id: revenue-policy\r\n resource: policies/revenue-recognition.md\r\n title: Revenue Recognition Policy (FY2026)\r\n author: human:jsmith@acme\r\n last_modified: 2026-06-15\r\n---\r\n\r\n# Schema\r\n\r\n| Column | Type | Description |\r\n|----------------|---------------|----------------------------------------------------------------------------------------|\r\n| `order_id` | STRING | Globally unique order id. [^warehouse-schema] |\r\n| `order_ts` | TIMESTAMP | Order placement time in UTC; drives fiscal-year assignment. [^revenue-policy] |\r\n| `order_status` | STRING | Revenue is recognized only at `'delivered'` and after the 30-day return window. [^revenue-policy] |\r\n| `net_amount` | NUMERIC(18,4) | `gross_amount - discount_amount`. The recognized-revenue amount per policy. [^revenue-policy] |"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe795920610>)])]>

各ファミリーは 5 つの質問の 1 つに回答します。

来歴: スコアではなくソースを記録

新しい sources フィールドは、コンセプトの派生元となる資料を記録します。外部ドキュメント、バンドル相対パスのほか、「プロジェクト X のすべてのクエリ」といった範囲も指定できます。同時に、各エントリは客観的な信頼性シグナル（author、usage_count、last_modified）を保持できます。

ここで意図的に行ったのは、あえて追加しないという選択です。OKF は信頼性スコアではなく、シグナルを記録します。スコアは主観的なものであり、コンシューマ間での汎用性に欠け、書き込まれた瞬間に古くなってしまいます。その代わりとなる信頼性は、コンシューマがシグナルから推測します（必要に応じて、コンシューマが動的にスコアを付けることもできます）。これは、「匿名ソースよりも、利用頻度が高く最近更新された信頼できるソースを優先する」という人間側の判断基準と同様の考え方です。本文で特定のソースを引用する際は、ソースの id（[^export-schema]）をキーとする通常の Markdown 脚注を使用します。このため、出典情報を最後にまとめてリスト化するのではなく、個々の主張に直接紐付けることができます。

信頼性: generated、verified

信頼性の確立には、意図的に区別された 2 つのフィールドを使用します。これは、作成者と確認者は別人であってもよいという考えに基づいています。

generated: { by, at }: 現在のコンテンツがどのように生成されたか、および最後に実質的な変更が加えられたのはいつかを示します。
verified: [ { by, at } ]: ソースまたは基盤となるリソースに対する独立した確認のリスト。人間の承認、夜間の財務プロセス、またはその両方を指します。

verified から、コンシューマは信頼性ティアを導き出します。verified キーがない場合は未確認、マシンアクターによる確認のみの場合はマシン確認済み、人間:<id> アクターによる確認の場合は人間によるレビュー済みとなります。ティアはアクセス制御ではなく、参考情報です。これにより、コンシューマは「経営幹部向けダッシュボードには人間によるレビュー済みの指標のみを表示する」といったフィルタリングをフロントマターで指定できるようになります。

acme_retail の例: metrics/revenue.md はリファレンスエージェントによって作成され、財務担当バイスプレジデントによって検証されるため、人間によるレビュー済みティアに分類されます。信頼性ティアフィルタが構成されたエグゼクティブダッシュボードのコンシューマは、その条件を満たすデータのみを抽出して表示します。一方、破棄前提のテスト環境では、下位ティアのコンセプトを取り込むことも可能です。

code_block: <ListValue: [StructValue([('code', 'type: Metric\r\ntitle: Revenue\r\ngenerated: { by: reference_agent/gemini-2.5-pro, at: 2026-06-30T14:00:00Z }\r\nverified:\r\n - { by: human:jsmith@acme, at: 2026-07-01T09:00:00Z }'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe795920310>)])]>

鮮度とライフサイクル: stale_after, status

OKF v0.2 では、stale_after フィールドと status フィールドを使用して鮮度とライフサイクルを定義します。status は、コンセプトを draft → stable → deprecated の順に遷移させます（指定がない場合は stable とみなされます）。stale_after は単一の絶対日付を指定します。相対的な TTL ではなくあえて絶対日付を採用したのは、コンセプトがいつ読み取られたかの情報に関係なく、単純な日付の比較だけで鮮度を判定できるようにするためです。こうした決定論的な動作は、LLM 以外のコンシューマにとってまさに必要とされるものです。

acme_retail の例: metrics/revenue.md と metrics/gross-margin.md の両方に stale_after: 2026-12-31 が指定されています。これは、Acme の財務チームが毎年 1 月に基本ポリシーを再承認することを踏まえた日付です。2027 年 1 月 1 日以降、これら 2 つのコンセプトをサービングするには、2027 年度のポリシーに照らした再検証が必要になります。

また、metrics/gross-margin-legacy.md は status: deprecated とされています。Acme は 2026 年 2 月に費用配賦基準を変更しました（以前の計算式では、売上原価に配送費とフルフィルメント費が含まれていませんでした）。以前の定義は、過去のクエリの再現性を確保するために保持されますが、新しい作業で利用されることはありません。

code_block: <ListValue: [StructValue([('code', 'type: Metric\r\ntitle: Gross Margin (legacy, pre-FY2026)\r\nstatus: deprecated'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe7959204c0>)])]>

証明: この数値は正規の手法で計算されたものか？

来歴は、その主張の出所を明らかにするものです。証明は、エージェントが金額を報告する際に重要となる、より踏み込んだ質問（この数字は指示された方法に沿って生成されたものなのか、それともエージェントが独自の SQL を即興で作成したのか）に答えるものです。

OKF v0.2 では、新しいコンセプトタイプである証明付きコンピューティングが導入されています。値の意味だけでなく、その値を計算する正規の計算手法と、その手法が実際に実行されたことを確認する手段が含まれています。acme_retail/computations/revenue-ytd.md の記述例を以下に示します。

code_block: <ListValue: [StructValue([('code', "---\r\ntype: Attested Computation\r\ntitle: Revenue for a fiscal year\r\nruntime: bigquery\r\nparameters:\r\n - { name: year, type: integer, required: true }\r\nexecutor:\r\n resource: skills/run-on-bq.md\r\n receipt: [job_id, executed_sql, result]\r\nattester:\r\n resource: attesters/sql_equality.py\r\ngenerated: { by: reference_agent/gemini-2.5-pro, at: 2026-06-30T14:00:00Z }\r\nverified:\r\n - { by: human:jsmith@acme, at: 2026-07-01T09:00:00Z }\r\nstatus: stable\r\nstale_after: 2026-12-31\r\nsources:\r\n - id: revenue-policy\r\n resource: policies/revenue-recognition.md\r\n title: Revenue Recognition Policy (FY2026)\r\n author: human:jsmith@acme\r\n last_modified: 2026-06-15\r\n---\r\n\r\n# Computation\r\n\r\nSELECT\r\n SUM(\r\n CASE\r\n WHEN o.currency = 'USD' THEN o.net_amount\r\n ELSE o.net_amount * fx.rate_to_usd\r\n END\r\n ) AS revenue_usd\r\nFROM `acme.sales.orders` AS o\r\nLEFT JOIN `acme.finance.fx_daily_rates` AS fx\r\n ON fx.currency = o.currency\r\n AND fx.rate_date = DATE(o.order_ts)\r\nWHERE o.order_status = 'delivered'\r\n AND DATE_DIFF(CURRENT_DATE(), DATE(o.order_ts), DAY) >= 30\r\n AND EXTRACT(YEAR FROM o.order_ts) = @year"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe7959201c0>)])]>

エージェントは、宣言されたparameters を入力することはできますが、計算方法の作成や編集はできません。コンシューマは executor を介して計算を実行すると、receipt（ここでは BigQuery の job_id、実際に実行された SQL、結果）が返されます。次に、LLM を使用しない決定論的な attester がそのレシートを検査し、判定を返します。具体的には、実行されたクエリが指定のパラメータにバインドされた正規の計算方法と等しいか、そして表示された値はレシートの信頼できるソースと一致するか、という判定です。比較は機械的に行われるため、クエリの書き換え、計算ファイルの入れ替え、依存関係の変更があると、チェックは失敗します。

acme_retail の例: attesters/sql_equality.py の attester は、両方の SQL を正規化（コメントの削除、空白の集約、既知のキーワードの大文字化）し、正規化された形式が異なる場合は ok を返さないようにします。テーブル名の差し替え、フィルタの追加、JOIN の削除が行われると、いずれも証明に失敗します。判定結果が false の場合、コンシューマはその値を表示しません。

この例では BigQuery（および SQL）を使用しましたが、この抽象化の仕組みには意図的に柔軟性を持たせてあります。証明済みの計算方法は、セマンティックモデル（Looker、AtScale、その他のシステム）の呼び出し、構造化されたナレッジグラフへのクエリ、さらには任意の API 呼び出しなど、さまざまな処理に適用できます。

重要なのは、OKF は計算方法とその確認方法を記録するだけで、それ自体は何も実行しないということです。また、証明は検証とは異なります。verified は、定義がポリシーと一致していることを確認します（低速、ドキュメントレベル、バンドルに保存）。証明では、1 回の実行で値が正しく生成されたことを確認します（呼び出しごと、ランタイム、バンドルに保存されない）。定義が古くなっていても、証明自体は問題なく行われることがありますが、たとえ検証されたばかりの定義であっても、実行のたびに証明を行う必要があります。そのため、証明と検証の両方があります。

v0.2 の主な更新内容

v0.1 と同様、リファレンス実装は意図的に概念実証として提供されています。OKF を利用するうえで、これらの実装は必須要件ではありません。GitHub リポジトリの変更点は次のとおりです。

reference_agent は、生成時に来歴と信頼ファミリーを出力するようになりました。これにより、新たに作成されたバンドルも生成ソースと引用が組み込まれた状態で提供されます。
静的ビジュアライザーには、コンセプトグラフとともに信頼性ティア、ステータス、鮮度が表示されるため、これらのシグナルを解析できるだけでなく、視覚的に把握できるようになります。
アップデートされたサンプルバンドル（GA4 e コマース、Stack Overflow、Bitcoin、このブログ投稿で使用されている Acme Retail の例）には、v0.2 のフィールドが実装されています。
Knowledge Catalog のデモでは、Google Cloud の Knowledge Catalog（旧称 Dataplex）を介したバンドルのラウンドトリップを紹介しています。ディスク上のクリーンな OKF が、カタログを経由して戻ってくる際も、信頼と来歴のシグナルがそのまま保持される様子を確認できます。

互換性

v0.2 は後方互換性を維持したマイナーアップデートですが、2 つのフィールド名が変更されています。timestamp は generated.at に置き換えられ、本文の # Citations リストは sources に置き換えられていますが、いずれも v0.2 のコンシューマは引き続き v0.1 の形式を利用できます。v0.1 のバンドルも、そのまま利用可能です。

次のステップ

仕様書は短くまとめられていますので、ぜひご一読ください。ソースシステムのトラストシグナルを出力するプロデューサーを記述しましょう。さらに、それらをフィルタリングするコンシューマを記述します。ご自身の財務定義を使って、証明付きコンピューティングをお試しください。問題の報告、PR の送信、拡張機能のご提案をお待ちしております。共通言語の価値は、それを利用するコミュニティの広がりによって高まります。v0.2 では、その言語を通じて互いの情報を検証し合うこともできるようになりました。

OKF v0.2 の仕様、サンプル、リファレンス実装: github.com/GoogleCloudPlatform/knowledge-catalog/tree/main/okf

- データクラウド、エンジニアリング、データ分析担当テクニカルリーダー、Sam McVeety

- データクラウド、エンジニアリング、BigQuery 担当テクニカルリーダー、Amir Hormati

pgvector の強化: AlloyDB で HNSW ベクトル検索が 4 倍高速化

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

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

AlloyDB は、特に要求の厳しいエンタープライズワークロード向けに構築された PostgreSQL 互換のフルマネージドデータベースサービスです。オープンソースの PostgreSQL の優れた機能と Google の高度なテクノロジーを組み合わせることで、大規模なスケーラビリティ、高可用性、ネイティブ AI 機能を提供します。高性能なリレーショナルストア、ベクトル検索と全文検索の統合バックエンド、標準の PostgreSQL より最大 100 倍高速な分析エンジンとして機能します。

ベクトル検索は、最新の AI アプリケーションと検索拡張生成（RAG）アプリケーションの基盤です。AlloyDB やその他の PostgreSQL データベースを使用する開発者にとって、pgvector はベクトルエンベディングの保存、インデックス作成、クエリに広く採用されている拡張機能であり、HNSW（Hierarchical Navigable Small World）は、多層構造にわたる近似最近傍探索用に設計された、非常に効率的なグラフベースのアルゴリズムです。AlloyDB のカラム型エンジンで高速化された HNSW（現在プレビュー版）を使用すると、標準の PostgreSQL HNSW と比較して、ベクトル検索の秒間クエリ数（QPS）を最大 4 倍に向上させることができます。

エンタープライズ AI アプリケーションは、常にスピードと精度のトレードオフに直面しています。数百万または数十億のベクトルを検索する場合、検索品質（再現率）を損なうことなく秒間クエリ数（QPS）を最大化することは、本番環境ワークロードをスケールするうえで非常に重要です。PostgreSQL の pgvector 拡張機能は、近似最近傍（ANN）検索を高速化できるインデックスの一つとして HNSW を提供します。AlloyDB が速度と精度のトレードオフをどのように解決するのかを詳しく見ていきましょう。

注: この投稿では HNSW のパフォーマンスに焦点を当てていますが、HNSW は AlloyDB の高度なベクトルツールキットの一部にすぎません。AlloyDB には、14 年以上にわたる Google Research の成果に裏打ちされた最先端のインデックスである ScaNN も搭載されており、ワークロードに最適なインデックスを柔軟に選択できます。さらに、絶対的な精度が求められるユースケースでは、標準の k 近傍法（KNN）検索をいつでも利用して 100% の再現率を確保できます。各インデックスの比較については、ベクトルインデックスの選択ガイドをご覧ください。

aside_block: <ListValue: [StructValue([('title', 'AlloyDB の 30 日間の無料トライアルインスタンスを使ってみる'), ('body', <wagtail.rich_text.RichText object at 0x7fe7955e3790>), ('btn_text', '無料で構築を始める'), ('href', 'http://goo.gle/try_alloydb'), ('image', None)])]>

まず、AlloyDB カラム型エンジンとは？

AlloyDB カラム型エンジンは組み込みのインメモリキャッシュで、頻繁にクエリされるデータを、スキャンに最適化された特殊なカラム型形式で自動的に保存します。これにより、AlloyDB は標準の PostgreSQL よりも最大 100 倍高速に大量の分析クエリを処理できます。さらに、インデックスをメモリに保存し、高速な走査のためにベクトル化されたメモリレイアウトを使用し、標準の PostgreSQL バッファマネージャーのオーバーヘッドをバイパスすることで、ANN 検索を高速化します。

パフォーマンスの可視化

カラム型エンジンで高速化された HNSW の実際のパフォーマンス特性を把握するために、100 件の制限で 100 万件以上のレコードを検索して、GloVe 100 Angular データセットの標準 QPS と再現率の曲線を作成しました。

このベンチマークスクリプトを実行すると、次のようなグラフが得られます。

注: これらの測定値は、AlloyDB C4A 16 vCPU マシンで取得されたものです。HNSW グラフの構築には固有のランダム性があるため、実行ごとに結果が若干異なる場合があります。

このデータから、2 つの変革的なメリットが明らかになりました。

パフォーマンススループットが大幅に向上: 任意の目標再現率（0.95 など）に対して、QPS が約 4.2～4.9 倍に増加します。これにより、同じハードウェアで同時に処理できるベクトル検索の数が大幅に増加します。
再現率（精度）が大幅に向上: 逆に、QPS レベルが一定の場合、カラム型エンジンで高速化された HNSW は再現率を大幅に向上させます。たとえば、上述のグラフでは、約 350 QPS の時点で、カラム型エンジンを有効にすると、再現率が約 0.78 から 0.94 超へと向上し、0.163 の再現率の向上が見られました。つまり、AI アプリケーションはレイテンシの影響を受けることなく、より正確な結果を得られます。

特筆すべきは、ベースライン（青い線）は、インデックスが PostgreSQL の共有バッファキャッシュに完全に保存されている状態をすでに示しているという点です。ここで示されているパフォーマンスの向上は、単にデータをディスクから RAM に移動した結果ではなく、より効率的なメモリアーキテクチャを採用した結果です。

仕組み: カラム型エンジンで高速化された HNSW

標準的な PostgreSQL アーキテクチャでは、インデックスオペレーションで共有バッファキャッシュが使用されます。データが完全にメモリ内にある場合でも、データベースはバッファマネージャーから大きなオーバーヘッドを発生させます。バッファマネージャーは、ページの固定と固定解除、ロックの取得、バッファテーブルのルックアップ、LRU（Least Recently Used）管理などのオペレーションを処理する必要があります。

AlloyDB のカラム型エンジンは、スキャン用に最適化された特殊な形式でデータを保存する、組み込みのインメモリキャッシュです。

このリリースにより、AlloyDB はカラム型エンジンで高速化された HNSW を使用して、以下の処理を行うことができます。

インデックスの固定: pgvector HNSW インデックスは、カラム型エンジンのメモリに直接固定（高速アクセスを確保するためにメモリ内に永続的に保持）されます。
ベクトル化されたアクセス: HNSW グラフに必要な、同時実行性が高くポインタを多用する走査向けに特別に設計されたメモリレイアウトを利用します。
バッファのオーバーヘッド回避: AlloyDB は、専用のメモリ空間でグラフをナビゲートすることで、標準のバッファマネージャーのボトルネックを回避します。このアーキテクチャの移行により、完全にキャッシュされた標準インデックスと比較した場合でも、上述のような QPS と再現率の大幅な改善が可能になります。

これが重要である理由

エンタープライズ規模のアプリケーションの場合、これは単にデータベースが高速になるだけでなく、費用と品質にも影響します。

インフラストラクチャ費用の削減: コンピューティングリソースを大幅に削減しながら、同じパフォーマンスを実現できます。
AI の精度向上: 以前は「ドラフト」（高速、低精度の結果）品質の検索でしか実現できなかった速度で、より高い再現率と品質を実現できます。
アプリケーションの変更は不要: これは AlloyDB に組み込まれているため、同じ標準の pgvector SQL 構文を使用してこれらのメリットを得られます。

カラム型エンジンはメモリを使用しますが、高度に圧縮され、緻密に管理されています。エンジンはベクトルデータを効率的なカラム形式で保存するため、メモリ使用量はパフォーマンスの大幅な向上に比べて最小限に抑えられます。これは、エンタープライズワークロードにとって非常に有利なトレードオフです。

クイックスタートガイド

AlloyDB でカラム型エンジンで高速化された HNSW を試すには、次の手順を行います。

1. インデックスキャッシュとカラム型エンジンを有効にする

AlloyDB インスタンスで google_columnar_engine.enabled フラグと google_columnar_engine.enable_index_caching フラグの両方が on に設定されていることを確認します。

2. HNSW インデックスをカラム型エンジンに追加する

pgvector を使用して HNSW インデックスを作成したら、次の SQL コマンドを実行してカラム型エンジンにキャッシュ保存します。

code_block: <ListValue: [StructValue([('code', "SELECT google_columnar_engine_add_index('<hnsw_index_name>');"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe7955e3580>)])]>

3. 参考情報

AlloyDB をまだご利用でない場合は、30 日間の無料トライアルで AlloyDB をお試しください。
Google Colab ノートブック: GloVe データセットの取り込み、インデックスの作成、再現率と QPS の曲線のプロットを行うエンドツーエンドの Python スクリプト。
HNSW は貴社のユースケースに最適なベクトルインデックスでしょうか？「AlloyDB AI でベクトルインデックスを選択する」ガイドをご覧ください。

- シニアソフトウェアエンジニア、Vinay Sharma

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

条件付きの寛大さ: Google Cloud のアクセス管理の強化

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

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

Google Cloud において、Identity and Access Management（IAM）はクラウドのリソースやオペレーションに対するアクセス制御を維持するのに役立ちます。他の機能も含まれますが、これが主な目的です。アプリケーションのセキュリティを強化しようとしたことがある方なら、最小権限の原則（PoLP）の重要性をご存知でしょう。ユーザーとワークロードにタスクの実行を許可するために、最小限の権限を付与するという原則です。事前定義ロールとカスタムロールを使用し、プロジェクト、フォルダ、組織のレベルで許可と拒否の IAM ポリシーを組み合わせて設定することで実現できます。リソース階層で許可ポリシーと拒否ポリシーを組み合わせて使用すると、アクセスを効果的に制御できます。このアプローチにより、さまざまなシナリオで PoLP を適用できます。

しかし、プロジェクト内のリソースが複数のワークロードで共有されていたり、複数のチームで使われていたりすると、既存の柔軟な制御だけでは不十分な場合があります。このようなシナリオの多くでは、IAM ポリシーをプロジェクト内の特定のリソースにバインドすることが可能です。たとえば、プロジェクトで Artifact Registry 編集者（roles/artifactregistry.editor）ロールを付与する場合と、プロジェクト内の特定のリポジトリで付与する場合の違いを考えてみましょう。前者の場合、プロジェクト内のあらゆるリポジトリへのアクセス権が付与されます。後者の場合、ユーザーは特定のリポジトリに対する編集者アクセス権のみを持ちます。ただし、IAM ポリシーをリソースレベルやサービスレベルに常にバインドできるとは限りません。このような場合に、IAM の条件を使用します。アクセス管理を堅牢化する際、条件がいかに強力に機能するか、2 つの異なる例で見てみましょう。1 つは従来の管理者ロール、もう 1 つは最新の AI インテグレーションの例です。

ユースケース 1: 管理者の権限を制限する

このケースでは、広範な IAM ロールに許可されている特定のオペレーションを制限する方法を示します。プロジェクトレベルで「リソース作成者」ロールを付与し、選択したリソースで編集者ロールを付与すれば、プロジェクト内の特定のリソースを管理するための管理者権限のスコープを簡単に設定できます。しかし、特定のリソースではなく、オペレーションへのアクセス権を付与することを目的とした IAM 管理者ロールを制限するのは、はるかに困難です。代表的な例としては、IAM 管理者ロール（roles/iam.admin）があります。このロールを付与されたユーザーは、他のロールを自分に付与したり、新しいロールを作成したりできます。これは実際のニーズを大幅に超えています。最初のステップとしては、プロジェクトレベルでのみ管理者権限を提供するプロジェクト IAM 管理者ロール（roles/resourcemanager.projectIamAdmin）を使用してアクセスを絞り込むことです。

さらに、付与する権限をより細かく制限することも可能です。たとえば、リソースを作成してワークロードをデプロイするビルダーサービスアカウントにプロジェクト IAM 管理者ロールを付与するとします。ワークロードに必要なのは、BigQuery API と Agent Platform API（旧称 Vertex API）へのアクセス、およびログとトレースを書き込む権限のみです。このような場合は、次の gcloud CLI コマンドまたは Terraform の代替コマンドを使用できます。

code_block: <ListValue: [StructValue([('code', 'gcloud projects add-iam-policy-binding "${PROJECT_ID}" \\\r\n --member="serviceAccount:${SA_MAIL}" \\\r\n --role="roles/resourcemanager.projectIamAdmin" \\\r\n --condition="^:^\\\r\ntitle=LimitedIAMAdmin:\\\r\nexpression=api.getAttribute(\'iam.googleapis.com/modifiedGrantsByRole\', [])\\\r\n.hasOnly([\\\r\n\'roles/aiplatform.user\',\\\r\n\'roles/bigquery.jobUser\',\\\r\n\'roles/bigquery.dataViewer\',\\\r\n\'roles/cloudtrace.agent\',\\\r\n\'roles/logging.logWriter\'\\\r\n])"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe794721a00>)])]>

condition パラメータの値は、Common Expression Language（CEL）構文を使用して定義されます。まず、フィールド区切り文字をカンマではなくコロンにカスタマイズしてから、条件フィールド title と expression を記述します。expression フィールドでは、API 属性の関数を使用して、付与されるロールを特定し、カンマ区切りのリストにあるロールのみを付与できるようにします。Terraform で同じ操作を行う場合も、ほぼ同じようになります。環境変数ではなく入力変数を使用すると、次のようになります。

code_block: <ListValue: [StructValue([('code', 'resource "google_project_iam_member" "limited_project_iam_admin" {\r\n project = var.project_id\r\n role = "roles/resourcemanager.projectIamAdmin"\r\n member = "serviceAccount:${var.sa_email}"\r\n condition {\r\n title = "LimitedIAMAdmin"\r\n expression = <<-EOT\r\n api.getAttribute(\'iam.googleapis.com/modifiedGrantsByRole\', []).hasOnly([\r\n \'roles/aiplatform.user\',\r\n \'roles/bigquery.jobUser\',\r\n \'roles/bigquery.dataViewer\',\r\n \'roles/cloudtrace.agent\',\r\n \'roles/logging.logWriter\'\r\n ])\r\n EOT\r\n }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe794721fd0>)])]>

ユースケース 2: MCP サーバーへのアクセスを制御する

このケースでは、単一の権限セットの背後にある特定のサービスへのアクセスを強化します。

Google は、Model Context Protocol（MCP）エンドポイントを公開する MCP サーバーを介して、クラウドリソースとサービスのサブセットへのアクセスを公開しています。これらのサーバーへのアクセスは、事前定義された MCP ツールユーザー（roles/mcp.toolUser）ロールを使用して付与されます。このロールは、利用可能なすべての MCP サーバー（IAM ポリシーが設定されているプロジェクトの場合）へのアクセスを許可します。条件を使用すると、特定の MCP サーバーへのアクセスを絞り込むことができます。

code_block: <ListValue: [StructValue([('code', 'gcloud projects add-iam-policy-binding $PROJECT_ID \\\r\n --member="serviceAccount:$SA_EMAIL" \\\r\n --role="roles/mcp.toolUser" \\\r\n --condition="^:^\\\r\ntitle=bigquery_mcp_server_only:\\\r\nexpression=resource.service == \'bigquery.googleapis.com\'"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe794721670>)])]>

resource.service 属性と比較される値は、MCP サーバーエンドポイント（bigquery.googleapis.com/mcp）ではなく、サービスのエンドポイントであることに注意してください。アクセススコープを特定の MCP ツールレベルまでさらに絞り込むことも可能です。そのためには、API 属性を再度使用する必要があります。次の式は、サービスアカウントのアクセスを 2 つの BigQuery MCP ツールのみのレベルに制限します。

code_block: <ListValue: [StructValue([('code', "expression=api.getAttribute('mcp.googleapis.com/tool.name', '') in [\\\r\n'mcp_bigquery-mcp_execute_sql',\\\r\n'mcp_bigquery-mcp_execute_sql_readonly'\\\r\n]"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe794721d90>)])]>

MCP ツールレベルで IAM ポリシーバインディングを条件付けする場合は、resource.service 属性を検証する必要はありません。

MCP サーバーへのアクセスを試すには、「Google MCP サーバーを使ってみる」Codelab を使用し、その gcloud projects add-iam-policy-binding コマンドを変更します。

さらなる活用例

事前定義ロールを使用する際の精密な制御に加えて、IAM 条件を使用すると「リクエストの時刻」に基づいたアクセス管理を構築することも可能です。たとえば、以下の条件式は平日の日中のみアクセスを許可します。

code_block: <ListValue: [StructValue([('code', "expression=request.time.getHours('Europe/Berlin') >= 9 &&\\\r\nrequest.time.getHours('Europe/Berlin') <= 17 &&\\\r\nrequest.time.getDayOfWeek('Europe/Berlin') >= 1 &&\\\r\nrequest.time.getDayOfWeek('Europe/Berlin') <= 5"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe794721130>)])]>

この式は、「Europe/Berlin」タイムゾーンに従って、月曜日から金曜日（曜日は日曜日を 0 とする 0〜6 の範囲）の午前 9 時から午後 5 時までのアクセスに制限します。

IAM 条件を使用すると、プリンシパル属性を使用してアクターの ID を制御できます。ただし、これはアンチパターンになりやすいため注意が必要です。推奨される方法は、条件を使用するのではなく、IAM ポリシーのプリンシパルのリストを通じて、ポリシーの使用を許可するアクターの ID を制御することです。

まとめとその他のリソース

IAM 条件は許可ポリシーに対して精密な制御を提供しますが、IAM 拒否ポリシーを活用することで、多層防御戦略をさらに進めることができます。拒否ポリシーを使用すると、許可ポリシーを持つ事前定義 IAM ロールでアクセス権を付与しつつ、そのロールの過剰な権限を削ぎ落として PoLP を適用できます。拒否ポリシーの詳細については、以下のリソースをご覧ください。

Google Skills を使用して、IAM ポリシーを実際に体験できます。

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

Google Cloud、日本の公共部門向けに Gemini Notebook Enterprise および Gemini Enterprise の国内データレジデンシーオプション（申請・選定制）を提供開始

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

デジタル変革が進む日本の公共部門において、データの機密性とセキュリティの確保は最優先事項です。Google Cloud は、行政機関や公共団体が最新の生成 AI 技術をより安心して活用いただけるよう、この度、日本国内に特化したデータレジデンシーオプションを日本の公共部門様に拡充することを発表いたします。

今回のアップデートにより、Gemini Notebook Enterprise および Gemini Enterprise において、データの保管から処理に至るまでを日本国内のインフラストラクチャ内に完結させることが可能になります。

サービスにおけるデータ概念の定義

Google Cloud では、お客様のデータを保護するための透明性を重視しています。本オプションの提供にあたり、Google Cloud の利用規約に基づき、以下の 2 つの重要な概念を明確に定義しています。

概念	定義の詳細
Data at Rest	データベースやストレージに保存されている状態のデータを指します。これには、お客様が入力したプロンプトや、モデルが生成した応答の記録が含まれます。
ML Processing	モデルの推論やトレーニングの実行など、計算リソースを使用してデータをアクティブに処理する段階を指します。

国内限定オプションの詳細と利用条件

通常、Google Cloud の生成 AI サービスは「グローバル」または「米国 / 欧州マルチリージョン」の環境を通じて提供され、優れたパフォーマンスとスケーラビリティを実現しています。しかし、極めて高い機密性が求められる公共部門のお客様のニーズに応え、以下の運用を選択いただけるようになります。

日本国内への限定: 事前の申請および所定の手続きを行うことで、上述の「Data at Rest」および「ML Processing」のすべてを日本国内のリージョン内に限定して運用することが可能です。
利用にあたっての留意点: この国内ローカルモードを選択した場合、一部の最新機能や特定の高度な機能の利用が制限される場合があります。あらかじめご了承ください。

本オプションの導入をご検討の際は、担当のセールスチームまたはパートナーまでお問い合わせいただき、必要な手続きについてご確認をお願いいたします。

公共部門の信頼に応える Google Cloud の取り組み

Google Cloud は、日本の政府・公共機関が求める高度なセキュリティ基準とコンプライアンス要件を満たすため、継続的な投資を行っています。

現在、私たちはガバメントクラウドの枠組みにおいて、Gemini Notebook Enterprise や Gemini Enterprise を含む生成 AI サービスを円滑に提供できるよう、必要な調整と準備を進めております。こちらについての詳細は 2026 年 7 月 30 日に開催された Google Cloud Next Tokyo パブリックセクター（公共・官公庁）向け特別セッションのデジタル庁様セッションにても触れて頂いております。

将来的に、政府共通のプラットフォーム上でこれらの革新的なツールが安全に利用できる環境を整えることで、国ならびに地方公共団体における行政サービスの住民の体験価値の向上と職員の業務効率化を強力に支援してまいります。

おわりに

Google Cloud は、テクノロジーの力で社会課題を解決しようとする公共部門の皆様のパートナーとして、常に安全で信頼できる AI サービスの提供に努めています。今回のデータレジデンシーオプションの拡充が、日本における安心なデジタル社会の実現に向けた一助となることを願っております。

今後とも、Google Cloud のソリューションをご愛顧賜りますようお願い申し上げます。

BigQuery を使用して Gemini Enterprise app の大規模な使用状況を分析および管理する方法

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

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

Gemini Enterprise app を組織全体にデプロイすることは、従業員の生産性を飛躍的に向上させる変革の第一歩です。従業員は、エージェント AI ツール、検索グラウンディングアシスタント、NotebookLM などの専用ソリューションで構成される、驚くほど高性能なスイートを利用できるようになります。大規模な導入が進むにつれて、大量のテレメトリーを手作業のオーバーヘッドに悩まされることなく監査および管理して、分析情報を抽出する方法について、管理上の重大な課題に直面することがあります。管理者の成功を支援するため、Google Cloud は、事前計算されたダッシュボードを介して、日々の導入、ユーザーエンゲージメント、アクティブユーザーの指標を追跡するための、すぐに使える包括的な分析を提供しています。この方法では、Gemini Enterprise app の使用状況をプロダクト中心の視点から確認できますが、エージェント型 AI の効果を把握するために、組織中心のより詳細な視点から、組織の内部コンテキストに合わせてカスタマイズされた分析が必要になる場合があります。このような場合に Google BigQuery を使用すると、組織全体で詳細なフォレンジックを実行し、エージェント型 AI の導入を分析および管理できるため、管理者にとっての秘密兵器となります。

Gemini Enterprise app と BigQuery がもたらす変革

ログシンクを使用して Gemini Enterprise app を BigQuery で補強すると、少人数の管理チームでも大規模なデプロイを分析および管理できます。具体的には、IT チーム、データチーム、セキュリティチームが次のことを行えるようになります。

導入と行動の微妙な違いをプロファイル化: 部門ごとに使用パターンをセグメント化して、カスタムエージェントを構築しているチームを確認し、NotebookLM の利用状況を追跡して、エージェントと従業員の比率を計算します。
組織における価値を定量化: 会話ログを人事部門や事業部門のデータセットと組み合わせて、従業員が実際に節約した時間を計算し、価値創造を追跡して、経営幹部向けの Looker ダッシュボードを構築します。
正確なコンプライアンス監査を実施: Google ドライブフォルダと企業ディレクトリ全体でグラウンディングクエリを監査し、データ漏洩を防止して企業の知的財産を保護します。
安全に関するアラートを即座に調査: セキュリティフィルタによりプロンプトにフラグが立てられた場合に、履歴ログをクエリし、Model Armor のブロックをトリガーしたテキストを特定して、コンプライアンスアラートを解決します。

これらのユースケースをサポートするために、テレメトリーは BigQuery の 5 つの異なるログテーブルに分割され、固有のデータフィールドがキャプチャされます。

BigQuery の宛先テーブル	キャプチャされるテレメトリー
生成 AI のユーザーメッセージ `discoveryengine_googleapis_com_gen_ai_user_message`	ユーザーが入力した実際のプロンプト
生成 AI の選択肢 `discoveryengine_googleapis_com_gen_ai_choice`	実際のモデルからの回答、終了した理由、LLM の推論ステップ
ユーザーアクティビティのテレメトリー `discoveryengine_googleapis_com_gemini_enterprise_user_activity`	企業 ID（IAM メール）とグラウンディングファイルのアクセスパス
Cloud Audit のアクティビティ `cloudaudit_googleapis_com_activity`	コントロールプレーンの構成変更と管理者権限を持つユーザーのログ
Cloud Audit のデータアクセス `cloudaudit_googleapis_com_data_access`	大量のデータプレーンのインタラクションと検索クエリ
OOB 指標の集計（バッチエクスポートテーブル）	過去 30 日間の事前集計されたシートの利用、シートの購入、およびエンゲージメント指標。導入と費用の概要ダッシュボードを構築するため、`analytics:exportMetrics` API のカスタムの日次バッチ実行によって非同期的にプルされます。

取り込みパイプラインとアーキテクチャ

スケーリングに対応したオブザーバビリティを実装するために、管理者は自動化されたテレメトリーパイプラインを確立します。Gemini Enterprise のデータを BigQuery に移行する際に、複雑なカスタムソフトウェアを開発する必要はありません。その代わりに、会話ログには継続的な Cloud Logging ログルーターシンクが利用され、集計シート指標の概要には非同期バッチエクスポート API が利用されます。

下の図は、取り込みパイプラインと、テレメトリーが BigQuery にマッピングされる方法を示しています。

これが、Gemini Enterprise を BigQuery に接続して、組織の究極の分析とガバナンスの基盤を構築するためのブループリントです。

ルーティングパイプライン: 継続的なロギングと監査シンク

テレメトリーをキャプチャするには、Cloud Logging 内にログシンクを確立して、ランタイムイベントをインターセプトし、BigQuery にルーティングします。

ストリーミングパイプライン（詳細ログ）: 会話データを 1 行ずつストリーミングします（ユーザープロンプト、モデルの選択、グラウンディングイベント）。Gemini Enterprise 管理コンソールで、プロンプトと回答のロギングが有効になっていることを確認します（使用状況と監査ログの設定を参照）。
包含フィルタ（[PROJECT_ID] を Google Cloud プロジェクト ID に置き換えます）:

code_block: <ListValue: [StructValue([('code', 'logName="projects/[PROJECT_ID]/logs/discoveryengine.googleapis.com%2Fgemini_enterprise_user_activity" OR\r\nlogName="projects/[PROJECT_ID]/logs/discoveryengine.googleapis.com%2Fgen_ai.user.message" OR\r\nlogName="projects/[PROJECT_ID]/logs/discoveryengine.googleapis.com%2Fgen_ai.choice"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe795ae2a90>)])]>

ガバナンスパイプライン（監査ログ）: 管理アクション（管理アクティビティ）とデータプレーンのオペレーション（グラウンディングデータコネクタのルックアップなどのデータアクセス）をキャプチャします。
包含フィルタ（[PROJECT_ID] を Google Cloud プロジェクト ID に置き換えます）:

code_block: <ListValue: [StructValue([('code', 'logName:"projects/[PROJECT_ID]/logs/cloudaudit.googleapis.com" AND \r\nprotoPayload.serviceName="discoveryengine.googleapis.com"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe795ae2af0>)])]>

管理アクティビティログ: デフォルトで常に有効になっています。リソースの変更（カスタムエージェントの作成、更新、削除など）を追跡します。
データアクセスログ: デフォルトではオフになっています。チャット中に発生するユーザーレベルでのデータの読み取り / 書き込み操作をログに記録するには、Discovery Engine API の GCP IAM 設定で有効にする必要があります。

BigQuery で高度なインテリジェンスを実現

未加工のテレメトリーを分析情報に変換

BigQuery では、テレメトリーの理解とナビゲーションを容易にする AI 搭載の分析ツールが提供されています。管理者は、Gemini in BigQuery を活用することで、手動で推測することなく、未加工のログストリームを視覚的な分析情報と明確なドキュメントに変換できます。

ノーコードの会話型分析（BigQuery CA）BigQuery の会話型分析（BQ CA）を使用すると、ネストされた JSON スキーマのクエリを簡単に実行できます。BQ CA は BigQuery Studio 内のインテリジェントエージェントとして機能し、スキーマ、ビジネスメタデータ、検証済みのクエリ / UDF にグラウンディングされた SQL を自動的に生成して実行し、指標の一貫性を保ちます。また、生成されたコードとともに「思考プロセス」が提示されるため、管理上の信頼性が高まります。

たとえば、下のスクリーンショットに示すように、「oob_metrics を使用して、NotebookLM、Deep Research、カスタムエージェントの使用状況を比較して」というプロンプトを入力すると、正しい SQL が生成され、クエリが実行されて、結果が数秒で出力されます。

下のスクリーンショットに示すように、BQ CA では、従来のクエリや標準 SQL 生成に加え、ユーザーがコンソール内で高度な AI および ML タスクを直接実行できます。管理者は、これらのネイティブ機能を活用して、ユーザープロンプトの感情の分類や今後の導入傾向の予測などの高度な分析を実行し、ガバナンスプロセスを合理化できます。

スキーマのドキュメントと分析情報の自動生成

適切な分析情報を抽出するには、useriamprincipal、finish_reason、groundedContent などのテレメトリーフィールドを理解することが非常に重要です。BigQuery では、スキーマのドキュメントの自動生成と AI によるコンテキストにより、このプロセスが簡素化されます。

自動プロファイリングとメタデータ: Knowledge Catalog のデータプロファイリングと Gemini を組み合わせることで、元テーブルの一意の値の数、null の割合、データの分布を評価できます。ワンクリックするだけで、データ分析情報により、テーブルとネストされた個々の列の両方に関する記述的なメタデータが生成されます。
統合データ分析情報: Gemini はこの豊富なコンテキストを活用して、データ資産全体から分析情報を抽出します。単一のテーブル（gen_ai_user_message など）内の異常や安全性の問題を検出するためのクエリを自動的に提案します。データセットレベル（プレビュー版）では、テーブル間の結合パスをマッピングするインタラクティブな関係グラフを生成し、ユーザーアクティビティやモデル出力などのデータを組み合わせてタスクの複雑さを計算するクエリを提案します。
エージェントのシームレスなインテグレーションと用語集: テーブルとデータ分析情報が BigQuery Conversational Analytics（BQ CA）エージェントの UI に直接統合されるため、エージェントは拡充されたメタデータと少数ショットの例にすぐにアクセスできます。エージェントがドメイン固有のプロンプトを正確に解釈できるように、BQ CA ではビジネス用語集もサポートされています。エージェント用のカスタム用語を直接定義するか、Knowledge Catalog から既存の用語集をインポートして、標準化された語彙を確立できます。

管理者は、コンプライアンス監査のために、プロファイリング、拡充されたメタデータ、分析情報を活用して、ログに記録されたフィールドをナビゲートし、テレメトリー構造を理解して、データをカタログ化できます。以下のスクリーンショットに示すように、Gemini を活用したスキーマ、説明、関連付けの自動生成により、Gemini Enterprise app でのエージェントのやり取りによって出力される複雑な関係とテレメトリーデータを簡単に理解できます。

データポータルダッシュボードによる可視化

経営幹部クラスのステークホルダー向けには、未加工のログテーブルをインタラクティブで効果の高いビジネスインテリジェンスダッシュボードに変換できます。データポータルを BigQuery に直接接続することで、次のものをモニタリングするダッシュボードを構築できます。

ユーザーの導入とシートの費用対効果: 部門別の使用状況の傾向をセグメント化し、従業員数に対する構築されたカスタムエージェント数の比率をハイライト表示します。
データグラウンディングトラフィック: SharePoint、Google ドライブ、Gmail など、最も利用率の高いエンタープライズコネクタをマッピングします。
コンテンツの安全性と違反: Model Armor のサニタイズブロックと感情フィードバックループを長期にわたって追跡し、安全基準を維持します。
BQ 会話分析エージェントの共有: データポータルを介して構築した BQ CA エージェントを共有し、ビジネスユーザーがデータについてさらに質問できるようにします。

Gemini Enterprise app で組織を強化し、BigQuery で管理者を支援

Gemini Enterprise app をデプロイ: Google AI の最先端機能を、すべての従業員が利用できます。
プロンプトと回答のロギングを有効化: 管理コンソールでプロンプトと回答のロギングを有効にして、ユーザーアクティビティのテレメトリーの記録を開始します。
ログルーターのシンクを構成: テレメトリーを BigQuery にストリーミングするシンクを確立します。
指標を追跡し、分析をエクスポート: コンソールで事前計算されたすぐに使えるダッシュボードにアクセスし、集計統計の履歴をエクスポートします。
テーブルレベルとデータセットレベルの分析情報を抽出: なじみのないログテーブルを探索し、関係結合パスを自動的に検出します。
会話型分析でクエリ: データ推論エージェントを構築し、BigQuery Studio 内で自然言語クエリを活用します。
データポータルによる可視化: データポータルを BigQuery に接続して、経営幹部レベルのダッシュボードを構築し、ビジネスユーザーが BQCA エージェントにアクセスできるようにします。
上記の分析設定における費用対効果が最も高く安全な構成については、Google Cloud カスタマーエンジニアにご相談ください。

この記事の基盤となる作業にご協力いただいた Google Forge チーム、特に Vicky Falconer、Dharini Chandrashekhar、Adhaar Gupta に感謝します。

- Aishwarya Prabhat、Google Cloud、Google Forge、ソリューションアクセラレーションアーキテクト

- Sudipto Guha、Google Cloud、データ分析および AI テクニカルリード

GKE マネージド DRANET を使用した Autopilot クラスタ: GPU と TPU

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

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

Google Kubernetes Engine（GKE）マネージド DRANET は、GPU と TPU の両方をサポートしています。この実装を使用するための構成には、標準クラスタ（ユーザーが完全に制御する）や Autopilot クラスタ（Google によって複雑な構成が自動的に行われる）など、いくつかあります。私自身、これまでその機能を検証してきましたが、このブログでは、Autopilot クラスタの設定について説明します。

Autopilot とマネージド DRANET

GKE Autopilot は、ノード、スケーリング、セキュリティ、その他の事前構成された設定を処理する、GKE のマネージドバージョンです。GKE マネージド DRANET を使用すると、ネットワーキングリソースをリクエストして Pod に割り当てることができます。たとえば、TPU およびリモートダイレクトメモリアクセス（RDMA）をサポートするネットワークインターフェースを割り当てられます。

設定フロー

GKE Autopilot クラスタをデプロイしてマネージド DRANET を有効にするには、Virtual Private Cloud（VPC）を作成する必要があります。その設定を見ていきましょう。

Autopilot クラスタをデプロイする。
アクセラレータタイプ（TPU または GPU）をサポートするカスタム ComputeClass を作成する。
GPU（RDMA）または非 GPU（TPU）の ResourceClaimTemplate を作成する。
ワークロードをデプロイし、ComputeClass と ResourceClaimTemplate を参照して、適切なネットワーキングを設定する。

次に、TPU と GPU の両方の構成について見ていきましょう。

次のように変数を構成します。

code_block: <ListValue: [StructValue([('code', 'export PROJECT_ID=$(gcloud config get project) #automatically sets your Project_ID\r\nexport REGION="REGION"\r\nexport CLUSTER_NAME="CLUSTER_NAME"\r\nexport NETWORK="NETWORK"\r\nexport SUBNETWORK="SUBNETWORK"\r\nexport RESERVATION_URL="RESERVATION_URL"\r\nexport HF_TOKEN="HUGGING_FACE_TOKEN"'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe796ec6eb0>)])]>

次のように置き換えます。

REGION: クラスタを作成するリージョン（us-east1 など）。クラスタは、予約またはリソースが存在するリージョンでのみ作成できます。
CLUSTER_NAME: クラスタの名前（例: dranet-cluster）。
NETWORK: VPC ネットワークの名前。
SUBNETWORK: VPC 内のサブネットの名前。
RESERVATION_URL: リソースの作成に使用する予約の URL。
HUGGING_FACE_TOKEN: モデルをダウンロードするための Hugging Face アクセストークン。

1. Autopilot クラスタをデプロイする

Autopilot クラスタをデプロイします。

code_block: <ListValue: [StructValue([('code', 'gcloud container clusters create-auto $CLUSTER_NAME \\\r\n --project=$PROJECT_ID \\\r\n --region=$REGION \\\r\n --release-channel=rapid \\\r\n --network=$NETWORK \\\r\n --subnetwork=$SUBNETWORK'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe796ec6c70>)])]>

2. カスタム ComputeClass を作成する

例: GPU B200 カスタム ComputeClass（マネージド DRANET をサポートし、予約を使用）

code_block: <ListValue: [StructValue([('code', 'apiVersion: cloud.google.com/v1\r\nkind: ComputeClass\r\nmetadata:\r\n name: dranet-a4-computeclass\r\nspec:\r\n nodePoolAutoCreation:\r\n enabled: true\r\n nodePoolConfig:\r\n dra:\r\n networking:\r\n enabled: true\r\n priorities:\r\n - machineType: a4-highgpu-8g\r\n gpu:\r\n count: 8\r\n type: nvidia-b200\r\n acceleratorNetworkProfile: auto\r\n reservations:\r\n affinity: Specific\r\n specific:\r\n - name: ${RESERVATION_URL}\r\n project: ${PROJECT_ID}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe796ec6b80>)])]>

次のように置き換えます。

${RESERVATION} : リソースの作成に使用する予約の URL に置き換えます。
${PROJECT_ID}: 使用しているプロジェクトの ID に置き換えます。

または、ターミナルで変数を設定し、次のコマンドを使用して作成時に変数を渡すこともできます:

envsubst < filename.yaml | kubectl apply -f -

例: TPU v6e カスタム ComputeClass（オンデマンド）の例

code_block: <ListValue: [StructValue([('code', 'apiVersion: cloud.google.com/v1\r\nkind: ComputeClass\r\nmetadata:\r\n name: dra-gke-auto\r\nspec:\r\n nodePoolAutoCreation:\r\n enabled: true\r\n nodePoolConfig:\r\n dra:\r\n networking:\r\n enabled: true\r\n priorities:\r\n - tpu:\r\n type: tpu-v6e-slice\r\n count: 8\r\n topology: "2x4" \r\n acceleratorNetworkProfile: auto\r\n location:\r\n zones: \r\n - us-east5-b'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe796ec6ca0>)])]>

3. ResourceClaimTemplate を作成する

GPU の RDMA サポート deviceClassName: mrdma.google.com ResourceClaimTemplate の例:

code_block: <ListValue: [StructValue([('code', 'apiVersion: resource.k8s.io/v1\r\nkind: ResourceClaimTemplate\r\nmetadata:\r\n name: all-mrdma\r\nspec:\r\n spec:\r\n devices:\r\n requests:\r\n - name: req-mrdma\r\n exactly:\r\n deviceClassName: mrdma.google.com\r\n allocationMode: All'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe796ec6df0>)])]>

TPU の非 RDMA deviceClassName: netdev.google.com ResourceClaimTemplate の例:

code_block: <ListValue: [StructValue([('code', 'apiVersion: resource.k8s.io/v1\r\nkind: ResourceClaimTemplate\r\nmetadata:\r\n name: all-netdev\r\nspec:\r\n spec:\r\n devices:\r\n requests:\r\n - name: req-netdev\r\n exactly:\r\n deviceClassName: netdev.google.com\r\n allocationMode: All'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe796ec6cd0>)])]>

4. ワークロードをデプロイし、ComputeClass と ResourceClaim を参照する

クラスタに Secret を作成します。

code_block: <ListValue: [StructValue([('code', 'kubectl create secret generic hf-secret \\\r\n --from-literal=hf_token=${HF_TOKEN}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe796ec60a0>)])]>

GPU のデプロイの例:

code_block: <ListValue: [StructValue([('code', 'apiVersion: apps/v1\r\nkind: Deployment\r\nmetadata:\r\n name: gemma-4-31-deploy\r\nspec:\r\n replicas: 2\r\n selector:\r\n matchLabels:\r\n app: gemma4\r\n template:\r\n metadata:\r\n labels:\r\n app: gemma4\r\n ai.gke.io/model: gemma-4-31b\r\n ai.gke.io/inference-server: vllm\r\n spec:\r\n resourceClaims:\r\n - name: rdma-claim \r\n resourceClaimTemplateName: all-mrdma\r\n containers:\r\n - name: vllm-inference\r\n image: us-docker.pkg.dev/vertex-ai/vertex-vision-model-garden-dockers/pytorch-vllm-serve:gemma4\r\n resources:\r\n requests:\r\n cpu: "10"\r\n memory: "1000Gi"\r\n ephemeral-storage: "1Ti"\r\n nvidia.com/gpu: "8"\r\n limits:\r\n cpu: "10"\r\n memory: "1000Gi"\r\n ephemeral-storage: "1Ti"\r\n nvidia.com/gpu: "8"\r\n claims:\r\n - name: rdma-claim\r\n command: ["python3", "-m", "vllm.entrypoints.openai.api_server"]\r\n args:\r\n - --model=$(MODEL_ID)\r\n - --tensor-parallel-size=8\r\n - --host=0.0.0.0\r\n - --port=8000\r\n - --max-model-len=131072\r\n - --max-num-seqs=16\r\n - --enable-chunked-prefill\r\n - --gpu-memory-utilization=0.90\r\n env:\r\n - name: MODEL_ID\r\n value: google/gemma-4-31B\r\n - name: HUGGING_FACE_HUB_TOKEN\r\n valueFrom:\r\n secretKeyRef:\r\n name: hf-secret\r\n key: hf_token\r\n volumeMounts:\r\n - mountPath: /dev/shm\r\n name: dshm\r\n startupProbe:\r\n httpGet:\r\n path: /health\r\n port: 8000\r\n failureThreshold: 240\r\n periodSeconds: 10\r\n livenessProbe:\r\n httpGet:\r\n path: /health\r\n port: 8000\r\n periodSeconds: 10\r\n readinessProbe:\r\n httpGet:\r\n path: /health\r\n port: 8000\r\n periodSeconds: 5\r\n volumes:\r\n - name: dshm\r\n emptyDir:\r\n medium: Memory\r\n nodeSelector:\r\n cloud.google.com/compute-class: dranet-a4-computeclass'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fe796ec61c0>)])]>

Deployment が ResourceClaimTemplate と ComputeClass をどのように参照しているかに注目してください。これが開始されると、スケールアップオペレーションがトリガーされます。GKE Autopilot は ComputeClass を読み取って、特定のノードタイプをプロビジョニングし、マネージド DRANET ネットワーキングを構成します。一方、リソースクレームはブリッジとして機能し、Pod をノード上のアクセラレータに直接バインドします。このプロセスは TPU でもまったく同じように機能します。

次のステップ

GKE マネージド DRANET と Autopilot について詳しくは、以下のリソースをご覧ください。

ハンズオンラボ: TPU を使用する GKE Autopilot クラスタ、GKE マネージド DRANET、Gemma 4
ドキュメント一式: DRANET
ドキュメント: AI Hypercomputer

ご質問やご意見がございましたら、Linkedin 経由で筆者までご連絡ください。

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

AI アプリが本番環境で失敗する理由と Google がそれらを解決した方法

Thu, 30 Jul 2026 03:00:00 +0000

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

今は、個人が週末に AI でアプリを自作できる、まさに黄金時代です。エージェントエンジニアリングと LLM のおかげで、空白の IDE から機能するローカルアプリケーションを構築するまでの時間は、数四半期から数時間へと激減しました。コーヒーを飲みながら、思いつく限りのアイデアを形にできます。

しかし、インフラストラクチャが厳格で、ユーザーが数百万人に及ぶ企業のエコシステム内では、バイブコーディングは目に見えない壁にぶつかります。ローカルプロトタイプは、企業ネットワークや連鎖的なエラーに直面したり、運用の不確実性を恐れる経営陣によってブロックされたりして崩壊してしまいます。

データは現実を突きつけています。AI プロトタイプが本番環境に移行できるのはわずか 5% で、残りの 95% は検証の段階で立ち消えになっています。

開発者にとって、ソーシャルメディア上の人々が電光石火のスピードで AI をデプロイしているのを見ながら、自分だけが終わりのない検証ループにはまり込んでいる状況は苛立たしいものです。この溝を埋める方法を見つけるため、私は YouTube のエンジニアリングの現場に潜入し、YouTube がこのスピードとリスクのパラドックスをどのように管理しているのかを調べました。私が発見したことは、AI ソフトウェア開発ライフサイクル（SDLC）設計に関する従来の考え方を完全に覆すものでした。

スピードとリスクのパラドックス

個人で構築している場合、失敗しても大したことはありません。エージェントコードの記述は、小回りの利くジェット戦闘機を操縦するようなものです。AI エージェントが誤った動作をした場合は、プロンプトを書き換えてサーバーを即座に再起動すれば済みます。

しかし、AI エンジニアリングリーダーの Addy Osmani が Emergent の初回エピソードで指摘しているように、企業内でエージェントオーケストレーションを無制限に行うと、予測不可能な影響範囲が生まれます。Addy は、個人プロジェクトで 10 個の並行エージェントを実行し、コンテキストを行き来しながらクイックプレビューのみに基づいてコードを push した際のエピソードを振り返ります。技術的負債は急速に蓄積し、変更が適切に分離されていなかったため、2 つのアプリが壊滅的な被害を受けました。

そのリスクを YouTube の規模まで拡大してみてください。そのインフラストラクチャは、20 年の歴史を持つ堅牢なコードベースで数十億人のユーザーを処理しています。これは実質的な公共インフラストラクチャであり、実験的な技術的負債によって過負荷になるリスクを冒すことはできません。この規模のプラットフォームを保護するには、広範で厳格なガードレールが必要です。

このパイプラインを通じて原始的なデモを構築する頃には、基盤となる AI モデルが進化し、アイデアが時代遅れになっている可能性があります。システムリスクを最小限に抑えながら、光速で移行するにはどうすればよいでしょうか？

YouTube の AI プロトタイピングスタック

DeepMind の元 YouTube ソフトウェアエンジニアである Benji Bear は、レビューを高速化することによってではなく、インフラストラクチャの哲学を変えることでこのパズルを解き明かしました。彼はチームとともに、プロトタイピングスタック を構築しました。これは、設計からコーディングまでのライフサイクルを統合したプラットフォームで、迅速な実験をメインラインの本番環境サーバーから完全に切り離すものです。開発速度における 2 つの主な摩擦点を体系的に解決します。

データレイヤの分離

スタンドアロンアプリを完全に分離すると、データや環境が何もない「白紙状態」という問題が発生し、現実的な条件でプロトタイプをテストできなくなります。この問題を解決するために、開発者は事前構築済みの Google AI Studio テンプレートを使用してアイデアをブートストラップします。これらのテンプレートは、プロトタイプ承認済みの読み取り専用データ用に Google Cloud で設定されたプロキシサーバーにフックされます。これにより、プロトタイプは厳格なトークンを介して、ライブメタデータバンドル（再生リスト、動画、チャンネル）への事前認証された読み取り専用 API アクセスを即座に取得します。

開発者は、コアデータベースに書き込んだり、汚染したり、クラッシュさせたりすることなく、ライブ本番環境パラメータの技術的正確性を手に入れることができます。

ライブ UI インジェクション

コンセプトに実際の検証が必要な場合、このスタックはクライアントサイドの YouTube 拡張機能ラッパーを提供します。このラッパーはグルーコードとして機能し、開発者は試験運用版の機能を YouTube の実際のライブ本番環境のウェブ画面に直接挿入できるようにします。コード分割チャンクの安全保護対策により、試験運用版の機能が本番環境のバイナリから分離されるため、プロトタイプの更新を安全なステージング環境に数分でデプロイできます。

その結果、YouTube は、アイデアの検証に数四半期を要していた状態から、「YouTube ハイライト」や「YouTube に相談」などのプロトタイプを数週間でユーザー調査（UXR）に直接投入し、いくつものプロトタイプを成功させました。

使い捨てコードを積極的に取り入れる

このスタックを導入するには、大きな意識改革が必要です。エンジニアは、コードを永続的なインフラストラクチャとして扱い、完璧になるまで磨き上げ、リファクタリングするように訓練されています。しかし、Benji が提唱するエンタープライズ AI の核となる哲学は至ってシンプルです。それは、使い捨てコードを積極的に取り入れることです。

Google AI Studio のプロトタイプは、技術的負債を抱えた、やや雑なものになることを想定しています。その目的は、定量データを使用してプロダクトマーケットフィットを検証することです。AI 生成の混沌としたアプリをエンタープライズコードベースにリファクタリングしようとすると、摩擦が生じるアーキテクチャ上の落とし穴に陥る可能性があります。

しかし、Google AI Studio は、本番環境インフラストラクチャのミラーバージョン上にプロトタイプを直接構築するため、初日から非常に精度の高いベースラインを確立できます。AI 生成の雑然としたスクリプト自体は破棄することになりますが、アイデアの成功が証明された後であれば、本番環境向けの書き直しは大幅に速く、低コストで済みます。また、その作業をリスクの低い開発ライフサイクルの後半へと安全に遅らせることも可能です。つまり、白紙状態から始めるのではなく、検証済みのブループリントをベースに実装を進められるようになるのです。

障害を起こさず、迅速に動く

ここで重要なのは、95% の失敗率はバグではなく、戦略であるということです。チームがより頻繁かつ安全に失敗できる環境を設計する必要があります。

AI により、コード生成のコストが大幅に削減されました。その結果、私たちの役割は、構文のゲートキーパーからシステムアーキテクトへと変化しています。私たちの仕事は、チームが壊滅的な障害を引き起こすことなく、大胆なアイデアをテストできるようにするブリッジ、読み取り専用サンドボックス、分離されたパイプラインを設計することです。

最大のリスクは、乱雑な AI コードでサーバーをダウンさせることではなく、検証ループが遅すぎて技術革新の機会を逃してしまうことです。失敗しても安全な構造的制約を構築することで、チームは超高速で自由に作業できるようになります。

技術的な詳細、YouTube のコアインフラストラクチャエンジニアとのインタビュークリップ、Google AI Studio Proto-Stack の内部については、YouTube で Emergent の初回エピソードをご覧ください。

- デベロッパープログラムグローバルリード、Stephanie Wong

Borderless Lakehouse: AWS、Databricks、Snowflake のデータを AI エージェントで活用

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

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

現在、データレイクハウスは単なるデータリポジトリではなく、常時稼働する自律型 AI エージェントを通じて積極的にタスクを実行する「アクションシステム」としての役割を強めています。これらのエージェントは、静的なレポートの出力を待つのではなく、リアルタイムの推論ループを絶え間なく回し続けます。サプライチェーンをモニタリングして異常をいち早く察知し、ビジネスワークフローを自律的に実行します。このモデルをスケールさせるには、AI エージェントがデータ資産全体にアクセスできる環境に加え、どのデータをいつ活用すべきかを判断するための適切なコンテキストが不可欠です。しかし、コストの増大、セキュリティの分断、ガバナンスの欠如といった問題を抱える従来のデータアーキテクチャでは、これを容易に実現することはできません。

このたび、Google は Next Tokyo で、これらの課題を解決する Borderless Lakehouse を発表いたします。オープンな Apache Iceberg を基盤とするこの仕組みは、オンプレミス、クロスクラウド、SaaS アプリケーションをシームレスに接続します。これにより、データを移動させることなく、保存場所を問わずにクエリを実行し、データを活用できるようになります。

Iceberg REST で複数のカタログを統合

Borderless Lakehouse は、データの物理的な場所に関係なく、Gemini Enterprise と会話エージェントがデータを分析して行動に移すことを可能にします。Iceberg REST カタログ上に構築されているため、リモートデータを瞬時に見つけ出してクエリを実行できます。これにより、データパイプライン構築に伴う膨大なコストや遅延といった課題を根本から解決します。この接続性を可能にしているのが、AWS Glue、Databricks Unity、Snowflake Horizon のカタログフェデレーション（現在プレビュー版）です。BigQuery、Managed Service for Apache Spark、さらに Iceberg 互換のあらゆるエンジンを介して、セキュアな双方向アクセスを提供します。

このオープンなアプローチはアプリケーションレイヤにも広がっており、SAP、Salesforce、Workday といった主要な SaaS アプリケーションとのゼロコピーデータ統合を可能にします。BigQuery からこれらのプラットフォーム上のライブデータに直接クエリを実行できるため、複雑な ETL パイプラインはもう不要です。同時に、BigQuery の AI エンジンを自社データに直接適用できるため、財務、人事、顧客データを簡単に統合できます。これらの機能は、次の 3 つの大きなメリットをもたらします。

ゼロコピーのクロスクラウド分析: ファイルを複製することなくプラットフォームをまたいで企業データを即座に検出してクエリを実行できるため、さまざまなデータチームが同一の Apache Iceberg データを共有して分析することができます。
双方向の相互運用性: 環境をまたいだデータの読み書きが可能です。BigQuery や Managed Spark から外部テーブルをクエリし、Google AI で強化した派生データセットをパートナーシステムへ戻すことで、後続のアクションに活用できます。
統合されたガバナンスとアクセス制御: 信頼できるコンテキストと Gemini の分析情報を活用して、エージェントのガバナンスを特別な設定なしで実現できます。どのプラットフォームからクエリが実行されても、認証情報の自動払い出しをサポートし、テーブルレベルでセキュアなアクセス制御を実現します。

Borderless Lakehouse の機能は Google Cloud のデータベースポートフォリオにまで広がっており、トランザクションシステムとデータレイクハウスの統合を実現します。Spanner Omni によるマルチクラウド環境での高スケーラブルなデータベース実行や、AlloyDB 向け Lakehouse Federation によるウェアハウスへの直接クエリなど、活用の幅が大きく広がります。費用のかかるデータ移動が不要になるため、ライブの運用データと過去のデータをセキュアかつ効率的にリアルタイムで一元的に分析できるようになります。これで、レイクハウスが真の意味でボーダーレスになります。

Google AI を AWS と Azure のデータに直接活用

これまで、クラウドをまたいで高度な分析を実行したり、ML モデルをトレーニングしたりするには「クラウド間の税金」、つまり高額な外向き料金、ネットワークレイテンシ、脆弱な ETL パイプラインが必要でした。Borderless Lakehouse は、Cross-Cloud Interconnect でこれを解決します。これらの専用のプライベートリンクは、従来のクロスクラウド接続のわずか数分の一のコストで、パブリックインターネットよりも安定した帯域幅と低いレイテンシを提供します。

Borderless Lakehouse では、AWS からデータにアクセスする際、従量課金の外向きデータ転送料はかかりません1。パートナー Cross-Cloud Interconnect の料金体系なら、SLA で保護された接続を予測可能な月額料金で利用できます。このマネージドなプライベート接続は、定額制のサブスクリプションモデルを採用しており、1 G から 100 G までのプロビジョニングを簡素化します。

さらに、Borderless Lakehouse のインテリジェントなクロスクラウドキャッシュ機能は、リモートデータの断片を Google Cloud 内に一時的かつセキュアに保存します。これにより、アドホッククエリや BI クエリのたびに発生していた高コストなデータ転送の繰り返しを排除できます。これらの機能に、BigQuery のベクトル化処理やマルチモーダル分析用の BigQuery AI 関数、Spark の Lightning Engine ランタイム、スケーラブルなメタデータストレージと組み合わせることで、パフォーマンスを犠牲にすることなくペタバイト規模までデータを拡張して以下のような高度な処理も実現できます。

インプレース AI と ML: データを移行することなく、AWS や Azure 上のデータに強力な AI モデルや Gemini を直接適用できます。メタデータとコンテキストをデータがある場所でそのまま取り込むことで、グラウンディングの精度を高め、市場投入までの時間を短縮できます。
データコピーの費用と遅延を解消: 他のクラウドに保存されているライブデータを直接クエリし、データをエージェントがすぐに活用できる環境を整えます。
統合された分析エクスペリエンス: マルチクラウドコンピューティングを Google Cloud のインフラストラクチャに一元化することで、BigQuery、Spark、オープンソースエンジン全体で、ハードウェアに最適化された一貫したパフォーマンスを実現します。

ユニバーサルコンテキストでエージェントの信頼性のギャップを解消

ハルシネーションを防ぐには、AI エージェントに技術的なメタデータだけでなく、ビジネスに関する深いコンテキストを提供する必要があります。ボーダーレス Lakehouse は、常時稼働のエージェントコンテキストエンジンである Knowledge Catalog を利用して、物理ファイルを移動することなく、マルチクラウド環境での企業コンテキストの一元管理を実現します。

これをサポートするために、Borderless Lakehouse のランタイムカタログは、AWS Glue、Databricks Unity Catalog、Snowflake Horizon と自動的に同期されます（すべてプレビュー版）。Knowledge Catalog はこれらのフィードを取り込んでメタデータを集約、抽出、インデックス化し、未加工のスキーマをわかりやすいビジネス用語に変換して、検索可能な列レベルのリネージを作成します。スキーマが変更されると、それを即座にビジネス定義へ反映し、以下のメリットを実現します。

コストとオーバーヘッドの削減: 膨大なコストと時間を要するデータ移行パイプラインを最小限に抑えつつ、マルチクラウド環境全体の統合ビューを構築できます。
信頼できる AI の意思決定: エージェントに明確なセマンティックレイヤとリネージトラッキングを提供し、データの迅速な特定、信頼性の確認、そして正確な解釈を可能にします。
自動化されたガバナンス: セキュリティをメタデータレイヤに直接組み込むことで、AI エージェントによるコンプライアンスガードレールとアクセス権限の厳格な遵守を徹底します。

Gemini Enterprise によるエージェントの構築とスケーリング

オープンソースの Google Cloud Data Agent Kit と Conversational Analytics API を連携させることで、Borderless Lakehouse で動作するカスタムデータエージェントを構築し、Gemini Enterprise に直接公開できます。これにより、ビジネスユーザーは自然言語を使用してデータと対話できるようになります。Data Agent Kit は、エージェント構築機能のフルスタックコレクションです。開発者は使い慣れた IDE（VS Code など）内で、事前にコード化された分析スキルや Model Context Protocol（MCP）ツールをパッケージ化できます。Borderless Lakehouse では、エージェントがデータ資産全体を対象に動作し、以下を支援します。

統合されたデータとエージェントのエコシステム: 組み込みの MCP ツールが BigQuery、Managed Spark、Cloud Storage へのセキュアな直接接続を確立します。これにより、複雑なパイプラインコードを記述したり、大規模なテーブルスキーマを LLM プロンプトにコピー＆ペーストしたりする必要がなくなります。
セルフサービス分析: ビジネスユーザーが静的なダッシュボードに頼ることなく、Gemini Enterprise インターフェース内でマルチクラウドデータセットを平易な言葉で即座にクエリして可視化できます。
グラウンディングされた高精度なエージェント出力: Knowledge Catalog 上でエージェントを実行することで、自然言語から SQL への変換が精査されたビジネススキーマに基づいて行われます。これにより、高度なセキュリティと厳格なガバナンスに裏打ちされた正確な結果が得られます。

Borderless Lakehouse とエージェントの経済性

ボーダーレスなレイクハウスは、データ転送、コンピューティング、トークン消費の各領域で相乗的なコスト削減を実現することで、エンタープライズ AI の経済性を再定義します。Cross-Cloud Interconnect とゼロコピー共有を利用することで、脆弱なデータパイプラインや予測不可能な外向き料金を回避し、予測可能な定額料金でリモートデータセットをクエリできます。Knowledge Catalog は、各プロンプトに必要な正確かつ最小限のビジネスコンテキストをフィルタして提供することで、トークンの肥大化を防ぎ、不要な推論ループを排除します。BigQuery AI は、組み込みのトークン制御により、クエリ前にトークン使用量を推定し、厳格な上限を適用して、より小さな蒸留モデルを自動的に使用する最適化モードを活用することで、エージェントによる予期せぬ課金増加を防ぎます。実際、BigQuery のコスト最適化済みの組み込み AI 関数を利用することでトークン消費量を 230 分の 1 に削減できたケースもあります。

次のステップ

未来は「アクションシステム」の時代です。Borderless Lakehouse で、AI エージェントがデータが保存されている場所を問わず安全かつ迅速に、費用対効果の高い方法で、データのクエリ、推論、アクションを実行できるようにしましょう。構築を開始するには、公式の Google Cloud Lakehouse の概要ガイドをご確認ください。また、ボーダーレスなレイクハウス構築の Codelab もぜひお試しください。

-プロダクトマネジメント担当バイスプレジデント、Sirish Chandrasekaran

-グループプロダクトマネージャー、Will Ochandarena

^{1. 相互接続サービスの時間単位の料金はかかります}

AI エージェントの準備は完了。では、データは？

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

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

組織による AI イニシアチブの拡張を妨げている最大のボトルネックの一つは何でしょう？それは、現在のモデルの機能ではありません。ビジネスコンテキストとセマンティックな意味へのアクセスです。

エージェントの時代における企業は、単にデータを保存するだけでなく、信頼できるコンテキストでデータを有効活用し、受動的な記録システムから能動的な「アクションシステム」へと移行する必要があります。

しかし、AI エージェントは非線形的な速度で動作します。たとえば、1 つのプロンプトでエージェントが複数のシステムを対象に自律的にブラウジングを行い、クエリを発行して処理を実行する場合、基盤となるインフラストラクチャに負荷をかけることがあります。コンピューティング、ネットワーキング、ストレージの各レイヤがエージェント型 AI 向けに最適化されていない場合、その上に位置するデータプラットフォームは崩壊します。

Google のインフラストラクチャの現状に関するレポートによると、本番環境グレードのエージェント型 AI システムをサポートするにはインフラストラクチャのアップグレードが必要だと考える組織が 83% を占めています。

この問題を解決するために、Google は Google Cloud Next 2026 で Agentic Data Cloud を発表しました。これは、データ、AI モデル、運用データベースを単一の「アクションシステム」に統合するソリューションです。Agentic Data Cloud を機能させるには、チップからモデルまで、すべてが AI ネイティブである必要があります。基盤となるインフラストラクチャは、エージェントの負荷に対応できる必要があります。

Google の Agentic Data Cloud

適切なインフラストラクチャ基盤を整えることで、組織が現在直面している最大のデータ課題を Agentic Data Cloud がいかに解決できるか、以降で見ていきましょう。

コンテキストの欠如を克服する

エージェント型システムを効果的に機能させるにはコンテキストにアクセスする必要がありますが、こうしたコンテキストは、多くの場合、断片化されたデータシステムや従来のアーキテクチャに存在します。このため、エージェントがこうしたコンテキストを把握することが難しくなり、不完全かつ不正確な結果につながる可能性があります。実際、Google のレポートによると、43% の IT リーダーが「従来の API やデータソースとの統合の難しさ」をエージェント型 AI インフラストラクチャの最大のギャップとして挙げています。

しかし、組織が膨大なデータセットを移動して AI に接続しようとする場合、必ず複雑さと費用の増大が伴います。

Agentic Data Cloud は、オープンかつ柔軟なインフラストラクチャ上で実行されるボーダーレスなレイクハウスを活用することで、この問題を解決します。エージェントは、オープンスタンダード（Apache Spark、Apache Iceberg）を介して BigQuery や Spanner などの強力なネイティブエンジンにアクセスすることで、従来の環境で発生するレイテンシと費用を回避しながら、まるでローカルであるかのように複数の環境間でデータを読み取り、推論し、有効活用できます。

不要な手作業を回避する

分断されたシステムの寄せ集めにエージェントをスケールすると、大きなボトルネックが生じる可能性があります。Google の調査では、AI をスケールする際の予期せぬ費用の筆頭として、81% のリーダーが運用の複雑さとエンジニアリングのオーバーヘッドを挙げています。その例として、エンジニアが異なるシステムにまたがる AI エージェントを手動でつなぎ合わせる作業に費やす時間が挙げられています。

「考える」エージェントから「実行する」エージェントに移行するには、分析ソースと運用ソースの両方でリアルタイムデータを接続できなければなりません。これには垂直統合が必要です。モデル、データシステム、基盤となるアクセラレータが共同設計された AI ネイティブインフラストラクチャ上に Agentic Data Cloud を構築すると、ネットワークホップが減り、ツールがより適切に統合されます。この統合システムにより、エージェントは典型的なエンジニアリングのオーバーヘッドなしで分析情報を取得し、安全なトランザクションをトリガーできます。

データに信頼と知識をもたらす

エージェントに必要なのは、データを検出してクエリを実行する機能だけではありません。安全かつ正確なアクションを実行するには、豊富なコンテキストとビジネスロジックも必要です。しかし、36% のリーダーが、AI モデルのグラウンディングに使用される専門的な高スループットのベクトルデータベースの不足を、インフラストラクチャの主要なギャップとして挙げています。このギャップにより、エージェントにコンテキストを提供する能力が損なわれます。

エージェントがその可能性を最大限に発揮するには、レガシー ERP やサードパーティ CRM を含むデータシステムに対してリアルタイムで読み書きを実行できるように構築された基盤が必要です。また、複雑なタスクを実行する際に、たとえば 3 週間前のユーザーの好みを「思い出す」ことができる長期記憶も必要です。こうしたリアルタイムの自動化がない場合、エージェントはクエリごとにデータを再処理する必要があります。

AI にコンテキストを提供するために、組織は Knowledge Catalog を使用してデータレイク内のデータを集約して拡充し、エージェントによる検索を可能にしています。非構造化データから意味を抽出してセマンティクスを自動生成することで、カタログはアクティブな推論レイヤとして機能するようになります。そして、そのカタログは、エージェントが適切なコンテキストを取得できるように、高スループットのインフラストラクチャによって支えられている必要があります。

将来を見据える

今こそ、AI によって真の競争優位性を獲得するために、接続されたアクティブなデータエコシステムを構築する絶好のタイミングです。試験運用から本番環境に移行するには、エージェントがすべてのデータにシームレスにアクセスできるようにする必要があります。また、エージェントの時代の要求に対応できるインフラストラクチャで、これを支える必要があります。2026 年以降に勝利を収められるのは、必ずしも高度にスマートなエージェントを備える企業とは限りません。これらのエージェントに適切な知識を、安全かつ費用対効果の高い方法で大規模に提供できる企業が勝利するでしょう。貴社のデータは、エージェントの時代に対応する準備ができていますか？

エージェント型 AI 時代におけるインフラストラクチャの現状に関するレポートで、アーキテクチャに対して AI に最適化されたアプローチを採用しているリーダーたちの手法をご確認ください。

- プロダクト管理、データ分析担当バイスプレジデント、Sirish Chandrasekaran

Frontier and Center: 誰が評価ツールを評価するのか？

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

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

編集者注: AI に関する最も興味深い問いとして、新たなクラスの AI エージェントにコンテキストを提供する方法に関して情報理論家が提起しているものがあります。数週間前、Google は Open Knowledge Format に関するブログ記事で、この問題に踏み込みました。Open Knowledge Format は、最新の AI システムを動作させるために必要なメタデータ、コンテキスト、キュレートされた知識を表すために、LLM-wiki パターンを移植可能で相互運用可能な形式に形式化する仕様です。このブログ記事は大きな関心を集めたため、同様のコンテンツを新しい「Frontier and Center」シリーズとして提供する運びとなりました。今回は、Google データクラウドのフロンティア AI チームに属する 2 人のメンバーから、エージェントがコンテキストに基づいて効果的に質問に回答できるかどうかをどのように体系的に評価するかという、繰り返し直面する課題について話を聞きます。詳しくは、記事全文をご覧ください。また、このチームによる今後のブログ記事にもご期待ください。

試験に関して合格点だけを知っても、それほど意味はありません。生徒が合格したかどうかはわかりますが、不合格だった場合は合格点からどれだけ離れていたのか、合格だった場合はどれだけ余裕があったのか、次回のために何を教えるべきなのかはわかりません。しかし、AI エージェントはまさにこのように評価されています。固定のベンチマークを実行し、スコアを計算して、進歩したと宣言しているのが現状です。このような評価では、エージェントに合格 / 不合格の試験を行っているのと同じです。必要なのは、エージェントの能力がどの部分でどの程度不足しているのかを正確に表す地形マップです。

データエージェントにとって、このマップは検索と取得におけるデータ探索に極めて重要です。このプロセスは、エージェントが曖昧な人間の質問と、数千のテーブルとファイルからなるデータウェアハウスまたはデータレイクを受け取った後、推論を行うための前段階として適切なデータセットを見つけなければならないという、地味な最初のステップです。探索は「干し草の山から針を探す」ようなものです。実際のユーザーからの質問は完璧に表現されたものではないため、どのデータセットを取得すべきかを推測するのはエージェントにとって非常に困難です。そのため、真に問うべきことは「エージェントは合格できるか」という点ではないのです。真に問うべきことは、「質問がどれだけ曖昧になるとエージェントが機能しなくなるか」という点です。試験ではこの問いに簡単に答えることはできませんが、マップでなら可能です。

このブログ投稿では、情報理論に基づいたアプローチをご紹介します。このアプローチは、ベンチマークに詳細とニュアンスを追加して忠実度を高めるために活用されており、評価の一環としてエージェントのパフォーマンスをより深く理解できるようになります。忠実度を高めたことで、発生した評価ケース自体の品質に関するより深い問題も明らかになりました。

難易度を測定

取得に関しては、評価ケースは多くの場合、難易度に応じて階層化されます。こうした階層化は、自然に生じることもあります。たとえば、広範囲で発生し、失敗が繰り返されるシナリオが「困難」と判断される場合などです。また、たとえばクエリで提供されたコンテキストに基づいて、エージェントが正しく回答する難易度が低いか高いかについて、人間やマシンが適用したラベルに基づいて、質問を分類することもできます。このような感情ベースのラベル付けは、テストケースにラベルを付ける唯一の方法ではありませんが、再現が難しいなどの欠点があるにもかかわらず、頻繁に使用されています。

すべての評価ケースを手作業で評価する方法も業界では一般的ですが、規模が大きくなれば現実的な方法ではなくなります。必要なのは、評価ケースの難易度を調整できる厳格なアプローチです。Google は、Discovery Bench と呼ばれるメタベンチマークの改良を重ねています。このベンチマークは、すべてのケースの「低難易度」バリエーションと「高難易度」バリエーションを生成することで評価ケースを調整するフレームワークです。これにより、エージェントがこれらのケースで成功からどれだけ離れているかを監査できます。

入力クエリの難易度を調整する手段は、情報理論と ML の分野で実績があり、信頼できるコンセプトであるサプライザル（意外性）、あるいは、ある一連の入力に対する出力の可能性によって実現されます。今回のケースでは、クエリのサプライザルとは、与えられたクエリから正しいデータセットを特定するうえで、依然として残っている不確実性を表します。

このアプローチの背後にある考え方はシンプルです。評価クエリの用語やフレーズは、コーパス内の他のすべてのものからターゲットを明確に特定できる場合、高い情報提供力を持つとみなされます。そのため、さまざまな情報提供力を持つ用語を追加または削除することにより、評価ケースの難易度を調整できます。

一般公開されているベンチマークである KramaBench の実際の例を見てみましょう。KramaBench のデータセットの一つには、地球を周回する衛星に関する情報が含まれます。スイートからのサンプルクエリには、次のテキストが含まれています。「…TLE 履歴を使用して、2024 年に衛星 48445 の高度が大きく変化した合計回数。」

トークン "TLE" が指定されているため、データセットの TLE_____48445 テーブルがほぼ一意に特定されます。これを削除すると、クエリは「衛星 48445 の高度の回数」のように曖昧なフレーズとなり、密度テーブル、精密軌道ファイル、減衰ログなどにも一致します。サプライザルはこれを定量化します。出現頻度の低い、的を絞った用語は、一般的な用語よりも情報量（ビット数）が多くなります。

クエリの残存サプライザルとは、その回答を得るために依然として残っている不確実性の量のことです。サプライザルがゼロに近づくにつれて、クエリはデータセットを 1 つ特定するのに十分な情報量があるとみなされるようになります。

Discovery Bench のアイデアの中核となるのは、この改良ループです。これは、サプライザルベースの反復クエリ改良（iSQR）と呼ばれ、情報提供力の高いケースと低いケースを生成して、エージェントがクエリに正しく回答できるようになる地点をテストします。

図 2: iSQR の改良ループ。

重要なのは、評価ケースに組み込まれた課題を調整によって制御できるようにすることです。質問ごとに 1 つの固定された表現を使用するのではなく、同じ質問を調整された 3 つの曖昧性レベル（高、中、低）で生成し、それぞれを（主観的な意見ではなく）ビット数に基づいてグラウンディングします。単語が追加または削除された理由を、用語ごとに説明することもできます。難易度は、感情や分類に基づくプロパティではなく、構築されるプロパティになります。

見えていなかった崖

次に、Discovery Bench の難易度ダイヤルで明らかになったことと、単一フレーズのベンチマークでは構造的に不可能であったことを説明します。

Google には、再現率を重視して構築された F1 エージェント（Gemini 3.1 Pro 上）があります。これを KramaBench に対して、曖昧性レベルのスイープを実行すると、曲線が得られます。曖昧性が高の場合は 0.34、標準の場合は 0.76、中の場合 0.81、低の場合 0.78 です。

図 3: F1 をすべての曖昧性レベルでスイープ - 点対曲線。

すぐに 2 つの知見が得られました。これらはどちらも、従来の評価では得られなかったものです。

まず、崖があるということです。このクエリは、標準のフレーズでは F1 = 1.00 の完璧なスコアが得られましたが、曖昧性が高いフレーズでは 0.00 が得られました。これは、上述の衛星 48445 のケースです。識別トークン「TLE」を削除すると、エージェントはテーブルを検出できなくなります。同じクエリ、同じエージェント、同じグラウンドトゥルースでも、少しでも曖昧になると崖から落ちてしまいます。静的なベンチマークは、標準的な表現をテストし、「解決済み」のスタンプを押して平地であると報告しますが、実際には断崖があります。合格 / 不合格の評価では、崖が見逃されるだけでなく、平地であると報告されるため、特に誤解を招きやすくなります。

2 つ目は、スイートスポットです。Discovery Agent では、曖昧性が中のプロンプトの方が標準プロンプトよりも結果が良い場合や、曖昧性が低のプロンプトの方が標準プロンプトよりもパフォーマンスが低い場合がありました。評価対象のシステムにとって、特異性は高いほど良いというわけではなく、最適な調整量があるということです。これは、評価された、実用的なシグナルです。これが、スカラー評価には欠けていた「どれだけ離れているか、どれだけ難易度が高いか」という特性です。これにより、エージェントのどの部分を改良すべきかがわかります。このケースでは、時間でシャーディングされたテーブル（回答が 2 つのテーブルである場合にエージェントがほぼ同一のシャード 21 個を過剰に取得すると、精度が約 8% に低下）や、コンテキストの急増（クエリが長い検索チェーンをトリガーすると、F1 が 0.75 から 0.32 に低下）などの具体的な失敗モードが直接示されます。このマップには、エージェントが失敗したことだけでなく、その場所と理由も示されます。（用語の調整により）曖昧さを減らし、コンテキストを増やすことで取得が改善するという仮説は一般的には当てはまりますが、今回使用した特定の Discovery Agent では、特有の「スイートスポット」があることから、実装におけるトレードオフが明確に示されました。

分野全体での傾向

この分野はメタベンチマークを使用する方向に収束しつつあり、エージェントにどのように負荷をかけ、評価するかをより細かく制御できるようになってきています。項目反応理論（標準化されたテストの背後にある潜在能力モデル）を使用して、難易度をラベルではなく測定量として扱う研究が増えています。tinyBenchmarks と metabench は、少数の情報量の多い項目でモデルのフルスコアを再現できることを示しており、PSN-IRT はベンチマークの品質自体にも同じ考えを適用しています。また、グラウンドトゥルースを直接監査する研究もあります。MMLU-Redux では、大規模マルチタスク言語理解（MMLU）の質問の 6.49% に誤ったラベルが付けられていることがわかりました。Platinum Benchmarks では、ラベルエラーと曖昧さの両方を最小限に抑えるために 10 個のデータセットを再クリーニングしました。これらは、Google がスイープするのと同じ 2 つの軸です。また、曖昧性はノイズではなく本質的なものとして扱われることが増えています。AmbigQA では、実際の質問の大部分に複数の解釈があることが示され、後の研究では、見かけ上のハルシネーションは、モデルの失敗ではなく、クエリの曖昧さに起因することが多いと報告されています。他では見られないのは、情報理論的な曖昧性をエンタープライズのライブデータに対してメタベンチマークとして適用するという組み合わせです。

信頼していたベンチマークが機能しなくなった

最初の評価は、この分野で確立されたベンチマークである kramabench-astronomy を基に構築しました。他のチームも、独自の評価にこのベンチマークを利用していました。チームはこのデータセットからベンチマークを派生させていましたが、時間の経過とともに微妙な問題が発生するようになった可能性があると仮定しました。Gemini の助けを借りて、チームが使用したベンチマークを実際に読んでみると、重要な問題があることがわかりました。グラウンドトゥルーステーブルがクエリに回答しない、質問の 124 個のシャードテーブルが一部のチームの検索 API で返せる数を超えている、正確な日付が必要なのに月が指定されているなどです。グラウンドトゥルースが気づかないうちに壊れていたということは、今回だけでなく、それに基づいて構築されていた以前の分析についてもすべて、結果が間違っていたということです。

これが一般的な問題の核心です。評価自体が欠陥のあるアーティファクトであり、それを評価する人はほとんどいません。エージェントを計測し、計測ツールを信頼しますが、その計測ツールが正しいことはどこで検証すればよいのでしょうか。

2 つのマップが一致しない場合

ここに再帰的な問題があります。難しさが生成されるものであるなら、生成器自体を評価する必要があります。生成器を盲目的に信頼すべきではありません。

そこで、同じ曖昧性スイープを 2 つの方法で構築しました。1 つは純粋な LLM の推測から用語を調整する方法、もう 1 つは TF-IDF サプライザルに基づいて用語をグラウンディングする方法です。この 2 つの結果は大きく異なりました。曖昧性が高い場合、LLM で構築されたスイープでは F1 のエージェントのスコアは約 0.34 でしたが、グラウンディングされたスイープでは約 0.85 でした。これらのマップのどちらかが大きく歪んでいます。予想どおり、グラウンディングされた方法の方がより堅牢です。サプライザルにより、グラウンディングされていない LLM にはない基盤が与えられるからです。

これは「評価ツールの評価」を具体化したものです。情報理論の視点からは、エージェントを連続軸に沿って評価するだけでなく、ベンチマーク自体の構築も評価し、両者を判定します。

評価ツールを評価する

Google は何年もかけて、測定したことのない測定ツールに対してエージェントを最適化してきました。皮肉なことに、モデルが優れているほどこの問題は悪化します。エージェントが大まかなベンチマークをクリアすると、スコアは上限近くで飽和し、試験によってエージェントの改良可能な部分を示すことができなくなります。

そのため、必要な行動は心地よいものではなく、遅きに失しています。評価ツールを評価することが必須です。グラウンドトゥルースを確認することが重要です。難易度をラベルではなく測定量として扱い、スイープしてプロットし、システムが機能しなくなるビット幅を見つけます。「合格したか」だけでなく、「合格からどれだけ離れていたか、どれだけの余裕を持って合格できたか、少し曖昧な質問をしたらどうなるか」を尋ねます。判定だけではなく、シグナルを生成する評価を構築します。

ここで、じっくりと考えるべき対立があります。難易度をエントロピーと捉えると、その信頼性はエントロピーを推定するモデルの信頼性に依存します。測定可能な代理の指標を過度に重視すると、エージェントではなく評価ツールを最適化することになるというリスクがあります。でも、これは合格 / 不合格の試験に後退する理由にはなりません。評価対象となるエージェントと同じ精密な調査を、評価ツールにも適用する必要があるということです。誰が評価ツールを評価するのか尋ねるのをやめれば、マップは再び役に立たないものになります。

^{1. Maia Polo, F. 他著『tinyBenchmarks: Evaluating LLMs with Fewer Examples』 ICML 2024 年、arxiv.org/abs/2402.14992}

^{2. Kipnis, A. 他著『metabench: A Sparse Benchmark of Reasoning and Knowledge in Large Language Models』 ICLR 2025 年、arxiv.org/abs/2407.12844}

^{3. 『Lost in Benchmarks? Rethinking Large Language Model Benchmarking with Item Response Theory』（PSN-IRT）、AAAI 2026 年、arxiv.org/abs/2505.15055}

^{4. Gema, A. P. 他著『Are We Done with MMLU?』（MMLU-Redux）、2024 年、arxiv.org/abs/2406.04127}

^{5. Vendrow, J. 他著『Do Large Language Model Benchmarks Test Reliability?』(Platinum Benchmarks)、2025 年、arxiv.org/abs/2502.03461}

^{6. White, C., Dooley, S. 他著『LiveBench: A Challenging, Contamination-Limited LLM Benchmark.』 2024 年、arxiv.org/abs/2406.19314}

^{7. Min, S. 他著『AmbigQA: Answering Ambiguous Open-domain Questions.』 EMNLP 2020 年、aclanthology.org/2020.emnlp-main.466}

^{8. Lai, E., Vitagliano, G. 他著『KramaBench: A Benchmark for AI Systems on Data-to-Insight Pipelines over Data Lakes』 2025 年、arxiv.org/abs/2506.06541}

- データクラウドフロンティア AI、ソフトウェアエンジニア、Manav Garg

- データクラウドフロンティア AI、テクニカルリード、Sunil Pedapudi

Cloud Blog JA

AlloyDB に追加されたグループ認証により、エンタープライズ規模の運用と AI エージェントのセキュリティを強化

個々のスケールに関する問題

エージェント型 AI の未来を守る

デジタル リーダーにとっての実証された価値

パスワードレス アクセスのための統合ブループリント

ゼロトラスト データベースの未来に向けて

The Blueprint: Voicify が AI を活用した注文体験を顧客にとって満足度の高いものに

課題:

ソリューション:

アーキテクチャ:

結果:

詳細:

Gemini Enterprise Agent Platform の最新情報

長時間実行されるエージェントを、より高速かつ優れたメモリ管理で自動化

エージェントのオペレーションを保護、監査、一元化

パフォーマンスの向上とエージェントの意思決定の最適化

Gemini Enterprise で成果を挙げているお客様

今すぐ Agent Platform を使ってみる

Panasonic Automotive、C4A-metal と vSkipGen で自動車のイノベーションを加速

要求の厳しいワークロードに対応する高パフォーマンス

vSkipGen の仕組み: Cuttlefish によるコックピットの仮想化

Unified HMI で作業場所を問わずグラフィック処理を高速化

ソフトウェア定義車両の開発におけるメリット

使ってみる

レポート「2026 Public sector threat landscape: M-Trends and beyond（2026 年の公共部門における M-Trends とその先）」の主な調査結果

レポートの主な調査結果と、それが公共部門に意味するもの

継続的な検証の義務

Google のセキュリティの活用

将来のセキュリティを確実なものに

BigQuery と %%bqsql マジックで SQL と Python のギャップを埋める

環境を設定する

ローカルデータにアクセスして準備する

BigQuery SQL マジックを初期化する

SQL を使用したローカルの pandas DataFrame にクエリを実行する

SQL と Python のチェーン: SQL の結果を保存する

Python に戻って可視化する

ハイブリッド パイプラインが重要である理由

次のステップとスケールアップ

列レベルのセキュリティを強化: BigQuery で IAM データ ガバナンス タグを使用する

IAM データ ガバナンス タグとは

列レベルのセキュリティにデータ ガバナンス タグを使用する理由

列レベルのセキュリティを実装する 3 つのステップ

使ってみる

アイドル状態のアクセラレータを最小限に抑える: llm-d での協調型タイムスライスによるネイティブ RL ジョブのインターリーブ

RL インフラストラクチャの効率化のための llm-d（全体像）

RL ループにおける効率性の課題

協調型タイムスライス（RL ジョブのインターリーブ）のメリット

タイムスライス: アーキテクチャの概要

フロー: 全体像

現在のリリースと今後の見通し

使ってみる

10 組の自律型映画制作チームから学んだ、AI エージェントのチームワークのあり方

チーム構造

生成メディアモデル

Scion: オーケストレーション システム

今回の実験でわかったこと

詳細

AlloyDB AI で PostgreSQL の多言語全文検索における制限を解消する方法

連続したテキストと表語文字言語

Gemini を使用したデータベース内での前処理

セマンティック単語分割の実装

ハイブリッド検索への拡張

検索に AlloyDB AI が最適な理由

次のステップ

Open Knowledge Format v0.2 におけるエージェントの信頼性担保の取り組み

説明から意思決定まで

来歴: スコアではなくソースを記録

信頼性: generated、verified

鮮度とライフサイクル: stale_after, status

証明: この数値は正規の手法で計算されたものか？

v0.2 の主な更新内容

互換性

次のステップ

pgvector の強化: AlloyDB で HNSW ベクトル検索が 4 倍高速化

まず、AlloyDB カラム型エンジンとは？

パフォーマンスの可視化

仕組み: カラム型エンジンで高速化された HNSW

これが重要である理由

クイック スタートガイド

デジタルリーダーにとっての実証された価値

パスワードレスアクセスのための統合ブループリント

ゼロトラストデータベースの未来に向けて

ハイブリッドパイプラインが重要である理由

列レベルのセキュリティを強化: BigQuery で IAM データガバナンスタグを使用する

IAM データガバナンスタグとは

列レベルのセキュリティにデータガバナンスタグを使用する理由

Scion: オーケストレーションシステム

クイックスタートガイド

Google Cloud、日本の公共部門向けに Gemini Notebook Enterprise および Gemini Enterprise の国内データレジデンシーオプション（申請・選定制）を提供開始

ルーティングパイプライン: 継続的なロギングと監査シンク

YouTube の AI プロトタイピングスタック

ユニバーサルコンテキストでエージェントの信頼性のギャップを解消