セキュリティ & アイデンティティ

Google Cloud パートナー、Gemini Enterprise を活用して新たなセキュリティエージェントと AI 防御機能を提供

Tue, 06 Oct 2026 18:00:00 +0000

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

脅威アクターが AI を利用してサイバー攻撃を加速、開発するケースが増えるなか、企業の防御者は AI と、防御者にとって重要な強みである「自社だけが持つビジネスコンテキスト」の両方を活用する必要があります。

企業のサイバー防御は、ID、ネットワーク、エンドポイント、データ、クラウド、アプリケーションの各レイヤにまたがっており、多くの場合、12 種類以上のプロダクトに分散し、それぞれが独自のコンテキストを持っています。Google Cloud Next では、パートナーが構築したエージェントを Gemini Enterprise に組み込み、セールス、コンテンツおよびクリエイティブワークフロー、人事、セキュリティなどの機能にわたり、専門エージェントを 1 か所で検出してデプロイできるようにしました。

このたび、Gemini Enterprise エコシステムでパートナーが構築したセキュリティサービスカタログを拡充し、単一の統合インターフェースからセキュリティコンテキストを最大限に活用できるようにいたしました。

主要なサイバーセキュリティベンダーが提供するこれらの新たなセキュリティエージェントとインテグレーションは、チームが Gemini Enterprise で直接呼び出すパートナー製セキュリティエージェントと、AI およびエージェント型ワークロードの保護という 2 つの領域にわたっています。これらを Gemini Enterprise に組み込むことにより、Gemini Enterprise 環境で直接、複数ステップのセキュリティワークフローをオーケストレーションできるようになり、AI を活用した機能を防御に取り入れることが可能になります。

Gemini Enterprise で構築された、新たなセキュリティエージェントとエージェント型防御のご紹介

Acalvio: Gemini Enterprise からアクセスできる Acalvio ShadowPlex ディセプションエージェントは、企業ネットワーク全体へのデコイとハニートークンのデプロイを自動化し、ディセプションガードレールを顧客の運用環境に直接埋め込みます。手動での構成は不要です。ShadowPlex は、ネットワークデコイ、ID ハニーアカウント、検索拡張生成（RAG）デコイ、ハニースキル、ハニートークンを大規模にデプロイし、不正なインタラクションを迅速に捕捉します。

Britive: Gemini Enterprise を基盤とする Britive Emergency Termination Agent を使用すると、セキュリティチームは複数のコンソールを操作することなく、単一の自然言語リクエストから、侵害された人間または人間以外の ID を封じ込めることができます。このエージェントは、ID を確認し、アクティブな特権セッションをすべて一覧表示して、人間の承認を得てすべてのセッションを取り消し、ID を無効にして、インシデントチケットの監査コンテキストを収集します。その結果、エージェントの厳格なガバナンスと最小権限アクセスを維持しながら、封じ込めまでの平均時間（MTTC）を大幅に短縮できます。

Check Point: Google Cloud Agent Gateway および Agent Registry と統合された Check Point AI Defense Plane は、エンタープライズ規模の AI で必要とされる重要なセキュリティ管理と可視性を提供します。組織は、AI ワークロードの検出、リスクポスチャーのモニタリング、コンプライアンスに違反する動作の検出に加えて、プロンプトインジェクション、データ漏洩、エージェントの不正な挙動に対するリアルタイムのガードレールの適用が可能になります。Gemini Enterprise 内の Check Point Agent を通じて管理されるこの統合ソリューションは、Gemini Enterprise での AI ワークロードのデプロイを保護し、高速化します。

CrowdStrike: CrowdStrike Falcon® Guardian は、Agent Gateway と統合することでガードレールとランタイム保護を拡張し、Gemini Enterprise で実行されるエージェント型ワークロードをプロンプトインジェクション、機密データの漏洩、悪意のある AI アクティビティなどのリスクから保護します。さらに、CrowdStrike Gemini Enterprise エージェントにより、実務担当者は Gemini Enterprise を通じて CrowdStrike プラットフォームを操作できます。これにより、CrowdStrike のセキュリティコンテキストをエージェント型の調査と対応に組み込み、多数のツールにわたる SOC ワークフローのオーケストレーションを支援します。

Cyberhaven: Cyberhaven Linea エージェントは、エンドポイント、クラウドアプリ、エージェント型ワークフロー全体にわたる機密データの検出と分類を Gemini Enterprise で可能にします。Cyberhaven のデータリネージモデルを活用したこのエージェントは、平易な言葉で表現された意図を適用可能なポリシーに変換し、インタラクションをモニタリングして、マッピングされていないリスクを侵害が発生する前に捕捉します。また、証拠の自動収集により調査が迅速化します。Gemini Enterprise の Antigravity 全体にわたり、Linea エージェントはアラート疲れを解消し、自律型エージェントが機密性の高いアセットを移動するのと同じ速さでセキュリティチームがそれらを保護できるようにします。

Cyera: Gemini Enterprise を基盤とする Cyera Agent Guardian は、Gemini で実行されるエージェントを保護し、データセキュリティポスチャー管理（DSPM）とデータ損失防止（DLP）を提供します。Cyera エージェントは、マシン ID、委任された権限、機密データの分類を相互に関連付け、承認されたエージェント型の動作を検証できるため、組織はエージェントを安全にデプロイし、エンタープライズ規模で運用コンプライアンスを維持できます。

Endor Labs: Endor Labs AURI エージェントは、デベロッパーとセキュリティのワークフロー全体に AI ネイティブのアプリケーションセキュリティをもたらします。同社の静的アプリケーションセキュリティテスト（SAST）トリアージエージェントは、Google Antigravity などのデベロッパープラットフォーム内でコードから検出された問題を自動的に分類し、優先順位を付けることができます。Gemini Enterprise では、セキュリティチームはこれらの検出結果を会話形式でクエリして対応できます。実際に悪用可能なものを確認し、修正を追跡することが可能で、そのすべてが Endor Labs アプリケーションのコンテキストに基づいています。

Exabeam: Exabeam は、Gemini Enterprise を基盤とする次世代の Exabeam Nova を導入しています。これは、セキュリティチームが脅威をより迅速に調査して対応できるようにする、統合マルチエージェント AI システムです。Nova は、ワークフロー全体で共有されている運用コンテキストを維持しながら、行動の分析、リスクの優先順位付け、調査の実施、対応アクションの誘導を行うことができる、専門の AI エージェントと連携します。その結果、アナリストはよりインテリジェントで効率的なエクスペリエンスを得ることができ、組織は既存のセキュリティ運用環境からより大きな価値を引き出すことができます。

Fastly: Fastly Autonomous Edge Defense Agent（AEDA）を使用すると、セキュリティチームは Gemini Enterprise 内で、ログを手動で解析する代わりに、エッジやインフラストラクチャのインシデントを平易な言葉で調査できます。AEDA は、組織独自のテレメトリーと Fastly のグローバルな顧客ベースから得た匿名化されたインテリジェンスを組み合わせ、異常は単発的なものなのか、より広範な攻撃の一部なのかを数秒で判断し、証拠に裏付けられた調査結果と推奨される修正策を返します。

Fortinet: Fortinet FortiAIGate は、Google Cloud のお客様に大規模言語モデル（LLM）のランタイム保護を提供します。Gemini Enterprise と統合され、Google Cloud 環境にデプロイされた FortiAIGate は、組織が高度なエージェント型 AI アプリケーションをデプロイできるよう支援します。これにより、データ、プロンプト、モデルとのインタラクションを新たな脅威から積極的に保護できます。

Menlo Security: Gemini を使用して構築された HEAT Shield Agent は、ウェブコンテンツを分析し、実行時にゼロデイ脅威やプロンプトインジェクションをブロックします。これに加えて、Gemini Enterprise を基盤とする Menlo Security Orchestrator が、セキュリティオペレーションセンター（SOC）のレスポンスを自然言語によるエージェント型ワークフローに変換します。これは、攻撃の再構築、影響範囲の特定、ポリシーの適用を、数時間ではなく数秒で行うことができます。Menlo Agent Runtime Security（MARS）は、このループを完結させ、人間とエージェントおよびエージェント同士のインタラクションを保護することで、エージェント型ワークロード全体で検出と封じ込めが統合された状態を維持します。

Obsidian Security: Gemini Enterprise で Obsidian Security の Risk Analyzer エージェントと Breach Response エージェントを使用すると、セキュリティアナリストはリスクを評価し、侵害に対応できるようになります。組織のクラウドと AI ネイティブアプリケーションポートフォリオを保護するために構築された Obsidian エージェントは、企業環境全体にわたり AI エージェントを検出し、リスクを評価して、ガバナンスのギャップを報告します。また、どのエージェントが昇格された権限や書き込みアクセス権を持っているかといった重要な質問に答えます。

Palo Alto Networks: Palo Alto Networks のクラウド、ネットワーク、AI リスク評価（CLARA）エージェントは、開発のペースを落とすことなく、重要なデータとコンプライアンスを確保した AI 運用を保護できるよう、セキュリティチームを支援します。クラウドインフラストラクチャと AI ワークロードを継続的にスキャンし、隠れた脆弱性を自動的に検出して修正の優先順位を付けることで、クラウドや AI のリスクが侵害に発展する前に発見して修正できます。これにより、セキュリティチームは脅威の検出に費やす時間を減らし、脅威の解消により多くの時間を費やすことができるようになります。

Ping Identity: Gemini Enterprise で利用可能になった Ping Identity の新しい PingID セルフサービスエージェントを使用すると、従業員は多要素認証（MFA）のリセットやデバイスの復元など、ID やデバイスに関する一般的な問題を自然言語で質問して解決できます。ヘルプデスクのチケットは不要です。PingOne を基盤とする、セキュアな委任認証を備えた PingID セルフサービスエージェントは、従業員の ID を管理するためのエンタープライズ対応の手段を IT チームに提供すると同時に、サポート費用の削減とオンボーディングエクスペリエンスの向上を実現します。

Qualys: Qualys ROCky for Gemini Enterprise は、セキュリティチームが Gemini Enterprise 内で会話を使用して脆弱性を管理し、パッチを適用するのに役立ちます。「Log4Shell の影響はどの程度か」、「まず何を修正すべきか」、「CISA KEV の期限を守れているか」といった質問をすると、Qualys TruRisk スコアに基づいてランク付けされた回答が得られます。各ユーザーが所有する Qualys の利用資格に基づいて動作するため、誰でもサポートなしで自ら回答を得ることができます。また、パッチのステージングとデプロイも行えます。

Splunk（Cisco 傘下）: Gemini Enterprise と統合された Splunk Security AI エージェントは、膨大なテレメトリーストリームをセキュリティデータとオブザーバビリティデータ全体にわたるリアルタイムインテリジェンスに変換する自律システムとして機能します。手動によるトリアージを省略して、重大な異常やシステム脅威を即座に表面化させることで、チームは事後対応型の調査からプロアクティブな防御へと転換できます。これにより、プレッシャーの大きなインシデント発生時の認知負荷が軽減され、セキュリティチームはリスクをより迅速に解決できるようになります。

Synk: Gemini Enterprise と Antigravity を使用して構築しているすべての企業が、かつてない速さでコードをリリースしています。Snyk は、コードが作成された後ではなく作成されたその瞬間から、コードがセキュアであることを保証します。Snyk は、AI エージェントが生成したものをリアルタイムで検証し、脆弱性やセキュアでない依存関係がリポジトリに到達する前に検出します。これは、AI がコードを記述する速度に合わせて構築されたセキュリティです。人がかつて記述していた速度に合わせたものではありません。

Thales: Gemini Enterprise と統合された Thales AI Security Fabric は、エージェント型 AI のインタラクション全体にわたって可視性、ランタイム保護、一元化されたガバナンスを提供します。組織は、エージェント型 AI を試験運用から本稼働に移行し、きめ細かなアクセスポリシーを適用して、重要なデータアセットを実行環境で直接保護できます。

Transmit Security: Gemini Enterprise を基盤として構築された Transmit Security Agent Intelligence は、顧客向けアプリケーションとやり取りを行うエージェント型アクティビティを特定します。ユーザーがタスク、トランザクション、権限を AI エージェントに委任することが増えるにつれ、組織は、そのアクティビティの内容、発生元、意図を明確に把握する必要があります。こうしたコンテキストを把握することで、企業は正常なエージェントと悪意のあるエージェントを見分け、許可すべきものとブロックすべきものを判断し、正当な取引を制限することなくリスクを未然に防ぐことができます。

Zscaler: Zscaler Risk360 は、既存の Zscaler のデプロイからデータを取り込み、サイバーリスクを定量化し、リスクポスチャーの詳細なビューを作成して、リスクを軽減するための明確な分析情報を提示する、包括的かつ実用的なフレームワークを提供します。Risk360 Agent は、Gemini Enterprise を使用した ZAgent フレームワーク上に構築された AI 搭載コンパニオンです。自然言語によるやり取りを使用して、Zscaler とパートナーからのシグナルの統合、ゼロトラストリスクの分析、財務的影響の定量化、緩和策の推奨、意思決定に役立つ分析情報を提供します。

パートナーが構築したエージェントやコネクタのエコシステムが拡大する中、Gemini Enterprise は、お客様がすでに利用しているセキュリティツールと連携し、それらを基盤としてカスタムエージェント型ワークフローを構築できるようにします。Google Cloud Marketplace で、現在利用可能なセキュリティエージェントを今すぐご確認ください。

- セキュリティおよび ID パートナーシップ担当ディレクター、Vineet Bhan

- セキュリティ担当パートナーエンジニアリング責任者、Ashish Verma

ゲームチェンジャー: エージェント型 AI を使用してインフラストラクチャコードを保護する

Thu, 01 Oct 2026 02:00:00 +0000

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

AI は、かつてないペースでソフトウェア開発を加速させています。しかし、コード生成が拡大するにつれて、コードのセキュリティを確保する課題も増大しています。特に、AI を利用した新たな脆弱性の悪用が懸念されています。こうした課題に対処するため、Google AI およびインフラストラクチャチームは、セキュリティへの取り組み方を変革しています。この記事では、Google が開発した新しい AI ネイティブなエージェント手法について説明します。この手法は、高精度で網羅的な脆弱性スキャンとパッチ適用を、Google のソフトウェア開発ライフサイクルに体系的かつ直接組み込むものです。Google は、インフラストラクチャにデプロイされる数億行に及ぶコードのあらゆる変更を継続的にスキャンすることで、毎月数百件もの脆弱性がコードベースや本番環境に混入するのを未然に防ぎ、グローバルネットワーク、AI インフラストラクチャ、そしてユーザーを保護しています。

ソリューションアーキテクチャと実装

送信前のエージェント型スキャンを徹底: 継続的なソフトウェア開発の一環としてのセキュリティ

従来、テクノロジー業界は、処理に時間がかかり、十分なコンテキストを把握できない単発の大規模なセキュリティスキャンに頼ってきました。その結果、脆弱性の発見が遅れることがよくあります。Google のアプローチでは、これとは異なり送信前スキャンに焦点を当てています。AI エージェントを活用し、スタックのあらゆるレイヤにおいて、コードのチェックインをリアルタイムで評価します。デベロッパーの使い慣れたツールに送信前スキャンを統合することで、セキュリティは、ルールチェッカーや可読性レビューなどのソフトウェア開発ツールと同じように、開発プロセスにおける日常的なルーティン作業になります。また、AI の観点から見ると、個々のコード変更をスキャンする方が、大規模な 1 回限りのスキャンを実行するよりもはるかに少ないコンテキストで済むため、スキャンの効果が大幅に向上します。

ローカライズされた脅威モデルの重要性

この取り組みのために、Google はオープンソースのマルチエージェントレビューハーネスである Mantis を進化させ、ローカライズされた堅牢な脅威モデルのコホートと照合することで、セキュリティエージェントの精度を高めました。脅威モデルは、コードから切り離された静的なドキュメントに依存するのではなく、リアルタイムのコードベースメタデータを使用します。スキャンエージェントは、パッケージやライブラリ間の依存関係コールグラフを使用し、脅威モデルのコンテキストを拡張および洗練させることで、精度をさらに向上させます。脅威モデルを継続的な脆弱性スキャンの一部に組み込むことで、開発者が脅威や依存関係を常に更新するようになり、モデルを最新の状態に保つことができます。ローカライズされた正確な脅威モデルデータを使用することは、精度の劇的な向上に直結しており、場合によっては偽陽性率をわずか 3% にまで抑えることができます。

専門のトリアージエージェントが開発を加速

コードチェックインの一環として脆弱性スキャンを行う場合、エンジニアリングの生産性を妨げないよう、コードを生成する開発者やエージェントに迅速に対応する必要があります。低レイテンシで回答を得るために、2 段階の検証プロセスを実行しています。まず、迅速な軽量スキャンを実行し、その結果を専門のトリアージエージェントで検証します。このエージェントは、コードの実際の構造をプログラムでチェックし（抽象構文ツリーの解析、コールグラフの走査、事前インデックス化されたドメイン安全ルールを使用）、脆弱なパスが実際に攻撃者によって到達可能であることを証明します。このエージェントは 92% 以上の精度を達成し、1 分以内に作業を完了します。次に、夜間の統合テストの一環として、送信後のスキャンが第 2 の防御層として機能し、オフピークサイクルを使用して、複数の変更にわたって導入された可能性のある脆弱性をテストします。

バグ修正エージェントがループを閉じる

脆弱性を見つけることは、解決への道のりの半分にすぎません。Google のソリューションの最後のコンポーネントは、スキャン結果と生成された実証コード（脆弱性がどのように再現されるかを示すコードスニペット）を使用して、Google の社内コーディング標準に合致した正確な修正案を自律的に生成する自動バグ修正エージェントです。エージェントは、元の変更リクエストのレビューの一環として、人間によるレビューのために修正を送信します。これにより、検出から解決までの時間がさらに短縮されます。

学んだことと行動喚起

継続的なスキャンをソフトウェア開発ライフサイクルに直接組み込むことは、Google においてまさにゲームチェンジャーとなりました。AI が提示する修正案は広く採用されており、数多くの脆弱性がコードベースに混入するのを未然に防いでいます。セキュリティ向上を目指す組織であれば、次の原則に従うことで、同様の AI ネイティブなアプローチを導入することが可能です。

システムを分離する: バイアスを防ぐため、開発、スキャン、トリアージの各エージェントのハーネス、ルール、コンテキストを分離します。軽量な AI スキャンと決定的かつ構造的な検証を組み合わせることで、レイテンシを短縮し、精度を向上させます。
コンテキストを賢く使用する: 既存の脅威モデルをエージェントにフィードします。偽陽性を減らすには、正確なコンテキストが不可欠です。また、最新の脅威モデルを使用することで、送信前スキャンの真陽性率が向上し、チームのセキュリティポスチャーの最低基準が引き上げられます。
優れたハーネスを構築する: 基盤となるモデルの選択は重要ですが、マルチエージェントハーネスを使用すると、モデル選択のばらつきを補うことができるため、大きな効果が得られます。
修正を自動化する: エージェントを使用して、人間参加型の修正を提案し、解決までの時間をさらに短縮します。

独自の AI ネイティブなセキュリティ変革を始めたい場合は、Mantis がオープンソースとして公開されていますので、ぜひ活用してそのメリットをお役立てください。また、サイバーセキュリティの基礎や、このエージェント型パイプラインを支える他のプラットフォーム（Google Cloud、Gemini Enterprise、Trillium および Ironwood TPU で実行される Gemini モデル）についても詳しく学ぶことができます。また、Google Cloud のセキュアなソフトウェア開発のライフサイクル（SDLC）の取り組みに不可欠な要素として、エージェント型の脆弱性スキャンと修復が Google Cloud のお客様をどのように保護しているかについても、ヒントを得ることができます。

^{この成果の実現に多大な貢献をした主要メンバーである、Stella Voutsina（リードプログラムマネージャー）、Yulong Zhang（シニアスタッフセキュリティエンジニア、Mantis）、Nick Galloway（スタッフセキュリティエンジニア、Mantis）に心からの敬意を表します。}

- Google、上級エンジニア、Andrés Lagar-Cavilla

- バイスプレジデント兼エンジニアリングフェロー、Parthasarathy Ranganathan

Secure Source Manager の新機能で CI / CD パイプラインを強化

Thu, 01 Oct 2026 02:00:00 +0000

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

レジリエンスを備えたソフトウェアサプライチェーンは、最新のデリバリーの基盤であり、継続的インテグレーションと継続的デリバリー（CI / CD）パイプラインを保護することこそが、イノベーションを安全に推し進める原動力となります。

Wiz の最新のクラウド脅威ハイライトレポートによると、2026 年上半期の注目すべきサプライチェーン攻撃は、2025 年下半期と比較して 2 倍以上に急増しています。

プライベートクラウドにおいて、ソースコードが最も脆弱な部分にならないようにすることが重要です。ソフトウェアサプライチェーンの脅威に、より効果的に対処できるよう、Google Cloud Secure Source Manager（SSM）では、統一された認証と認可の仕組みを使用して、ソースコードと CI / CD システムを管理できます。

Google は、開発と CI / CD ワークフローを簡素化し、セキュリティを高める 2 つの新機能の一般提供を開始しました。

CI / CD システムへの不正アクセス: 攻撃者は、デプロイスクリプトをたった 1 つ改ざんするだけで、CI / CD パイプラインをマルウェアの拡散ルートに変貌させてしまいます。このリスクを軽減するため、SSM は、バージョン管理システムからビルドやアーティファクトのシステム、デプロイツールに至るまで、たとえ企業ネットワークが侵害された場合でも、CI / CD システムへの不正アクセスをブロックできるようになりました。
権限を持つユーザーによるコードの不正な変更: 新しい Code Owners システムは、ファイル単位、ブランチ単位で pull リクエストの承認者セットを管理し、よりきめ細かい Identity and Access Management（IAM）を提供します。Code Owners は、コードの記述、編集、レビューを行うエンジニアを支援します。リポジトリ内のファイルとディレクトリに、ファイル単位またはブランチ単位で追加の保護ルールを適用します。

主な機能

CI / CD パイプラインへのソースコード変更をはじめとして、新しい Code Owners 機能はきめ細かいマージガードを提供します。CODEOWNERS ファイルをリポジトリにチェックインすることで、必要な承認者を極めて詳細に指定できます。

パスごとの承認者セット: 柔軟な glob スタイルのパス指定子を使用して、一致するファイルへの変更に対して、指定されたユーザーセットの 1 人以上による承認を必須にすることができます。
ブランチ固有のガバナンス: セキュリティルールとデプロイルールをブランチ間でスムーズに管理できます。同じファイル内で main や dev に異なるオーナーを定義できるため、既存の CODEOWNERS ソリューションで発生するマージコンフリクトを解消できます。詳しくは、こちらのドキュメントをご覧ください。
ネスト可能な複数ファイルのオーナー設定: 5,000 行にも及ぶような巨大なルートファイル 1 つに縛られる必要はありません。CODEOWNERS ファイルはサブディレクトリにネストできます。SSM は「ローカル優先」ロジックを採用しているため、サブチームがそれぞれのフォルダのオーナー権限を持ちつつ、ルート管理者はリポジトリ全体に対する拒否権を維持できます。
独立した承認セクション: [SectionName][count] 構文（例: [Security Team][2]）により、1 つの pull リクエスト（PR）において、複数の部門からの個別の承認を同時に義務付けることが可能になります。PR 自体はチームのメンバーによってレビューされても、セキュリティチームのメンバー 2 人による承認が揃うまではマージできないようになっています。

ソースコードの準備が整ったら、SSM の新しい Developer Connect 連携により、CI / CD システムとランタイムが異なるプライベートネットワークにある場合でも、セキュアかつ簡単に接続できるようになります。

プライベート CI / CD ブループリントのアーキテクチャは、セキュアな接続経路を採用しています。Secure Source Manager が Private Service Connect に接続し、そこからさらに Cloud Build へと接続されます。リポジトリ、ビルドプール、アーティファクトストレージはすべてプライベートネットワーク内に配置され、VPC Service Controls（VPC-SC）が多層防御を提供することで、プロキシエンドポイントへのアクセスを制限します。

次のステップ

ネットワークを保護するには、新しいプライベートネットワークの統合ガイドに沿って、Developer Connect を使用して SSM を Cloud Build に接続します。

pull リクエストの承認を保護するには、ルート CODEOWNERS ファイルを作成して、一律の IAM「承認者」ロールを、ファイル固有のオーナー権限に置き換えます。

- Google Cloud、プロダクトマネージャー、Logan Henriquez

きめ細かい制御が可能な、新しいネイティブセッション管理ツールのご紹介

Mon, 28 Sep 2026 16:00:00 +0000

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

Google Cloud のセッション管理では、組織のセキュリティポリシーのニーズに基づいてセッション管理を設定できる柔軟なオプションを提供しています。その一環として、セキュリティポスチャーの向上と、認証情報の窃取やアカウント乗っ取り（ATO）リスクの軽減を目的に、Google Cloud をご利用のお客様向けに、デフォルトのセッション時間を 16 時間に設定してロールアウトしました。

このセキュリティ標準は、セッション時間を独自に設定していなかったすべてのお客様への適用を完了しましたが、今日のクラウド環境ではさらに高い精度が求められています。このグローバルロールアウトの完了に伴い、Google Cloud のセッション管理も、広範な管理設定から、コンテキストアウェアアクセス（CAA）の緊密に統合されたきめ細かい機能へと進化しました。

このアップデートにより、管理者はより柔軟に、より優れた自動化を実現し、より自然なセキュリティワークフローを構築できるようになりました。

セッション管理の新機能

1. 自動化ファースト: Terraform、gcloud、API のサポート最新のインフラストラクチャはコードとして管理されます。DevSecOps ワークフローをサポートするため、セッション管理ポリシーの設定は、UI からの手動設定に限定されなくなりました。一般提供が開始されたことにより、以下を使用してプログラムでセッションポリシーを定義、デプロイ、管理できるようになりました。

Terraform: セッション管理をインフラストラクチャマニフェストに直接統合します。
gcloud CLI: コマンドラインからポリシーを管理します。
REST API: 複雑なマルチテナント環境全体でポリシーの適用を自動化します。

2. Google グループによるきめ細かいターゲティング最も要望の多かったアップグレードの一つは、ポリシーを正確にターゲティングする機能でした。以前は、セッション継続時間は組織部門（OU）に関連付けられていました。一般提供が開始されたセッション管理ポリシーでは、Google グループを使用できるようになりました。

この変更により、組織階層内のユーザーの場所に関係なく、特定のユーザークラスタに異なるセッションポリシーを適用できます。たとえば、権限昇格されたユーザー（課金管理者やプロジェクトオーナーなど）には 2 時間のセッションを適用し、一般の開発者には標準の 16 時間のセッションを維持できます。

3. アプリケーションの精密な制御セッション管理ポリシーでは、Google Cloud API スコープを必要とするすべてのアプリケーションに影響する包括的なポリシーではなく、特定のアプリケーションに対して個別にセッション管理を設定できます。これらのアプリケーションには、以下が含まれます。

Google Cloud コンソール
gcloud コマンドラインツール
特定の OAuth アプリケーション

一般提供が開始されたこのアップデートにより、「全か無か（オール・オア・ナッシング）」といった極端なシナリオを防ぐことができます。たとえば、Cloud SDK に厳格なポリシーを適用した結果、OAuth を利用している正当なビジネスインテリジェンスやダッシュボードとの連携まで意図せず遮断されてしまう、といった事態を回避できます。

4. Google Cloud ネイティブのエクスペリエンスこれまで、Google Cloud のセッション継続時間の設定は、Google Workspace 管理コンソールでしか行えませんでした。

Google Cloud のお客様は、お申し込みいただくことで Google Cloud コンソールを使用できるようになり、Access Context Manager（ACM）の他のアクセスレベルやセキュリティバインディングと合わせて、セッションポリシーを管理することも可能になります。プレビュー版として提供されるこのアップデートにより、Google Cloud コンソールでのポリシー管理を好む管理者は、すべての CAA ポリシーをより柔軟に、そして統一された操作感で設定できるようになります。

ご利用方法

セッション制御を静的な組織のデフォルト設定から、動的なコンテキストアウェアポリシーへと進化させることで、セキュリティチームは開発スピードを損なうことなく、最もリスクの高い場面において、認証情報の窃取に対する再認証の制限を厳格化できます。

Terraform、REST API、gCloud を使用してセッション管理を構成する方法については、セッション管理に関するドキュメントをご覧ください。

- プロダクトマネージャー、Senzeni Mpofu

- ソフトウェアエンジニア、Cris Scruggs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cloud KMS における耐量子鍵インポートの発表

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

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

企業の間でマルチクラウドアーキテクチャの採用が広がるなか、Bring Your Own Key（BYOK）は、データ主権の維持と重要なクラウドワークロードの保護において不可欠な柱となっています。同時に、量子コンピューティングは急速に進歩しており、セキュリティチームは、ネットワーク間で暗号鍵を安全に転送する方法を再評価する必要があります。

Cloud Key Management Service（Cloud KMS）における耐量子デジタル署名と耐量子鍵カプセル化メカニズム（KEM）の発表に続き、このたび、ソフトウェアベースの暗号鍵を対象とした Cloud KMS における耐量子鍵インポートのプレビュー版をリリースしました。

ポスト量子暗号（PQC）移行タイムラインの次のフェーズの第一歩となる、更新された耐量子 BYOK 機能は、暗号解読が可能な量子コンピュータ（CRQC）が登場する前に、機密性の高い鍵を保護するのに役立ちます。

転送中の鍵の保護を強化するために耐量子鍵インポートを導入する際は、一般提供が開始された Cloud KMS PQC insights を活用して、ポスト量子に向けた全体的なセキュリティポスチャーをモニタリングすることも可能です。この概要を示すビジュアルでは、使用されているアルゴリズムの分類に基づいて非対称鍵が可視化されます。これにより、将来のモダナイゼーションに向けた計画立案や、長期的なレジリエンスの向上に役立てることができます。

脅威:「今すぐ保存、後で解読」攻撃

従来の鍵インポート方法では、転送中の鍵をラップするために、従来の非対称暗号化標準が使用されます。これらのアルゴリズムは現在の脅威に対しては有効ですが、攻撃者が傍受して保存した鍵を復号できる実用的な量子コンピュータが登場すると、根本的に安全ではなくなります。

耐量子鍵インポートは、鍵を耐量子エンベロープで最初からラップすることで、「今すぐ保存、後で解読」（SNDL）攻撃を軽減するのに役立ちます。

鍵を保護する耐量子エンベロープの構築

Cloud KMS で利用可能になったポスト量子転送メカニズムは、ハイブリッド公開鍵暗号化（HPKE）を使用します。Google の新しいインポート方法では、機密性の高いソフトウェア鍵マテリアルを耐量子転送エンベロープでラップします。このプロセスは既存の Cloud KMS API ワークフローに統合されるため、導入の手間を最小限に抑えることができます。

ジョブの開始: クライアントは、Cloud KMS API を通じて新しいインポートジョブを作成し、ポスト量子 HPKE インポートメソッドをリクエストします。
鍵の生成: Cloud KMS サーバーは、ポスト量子 KEM 秘密鍵を生成し、対応する公開鍵をクライアントに公開します。
クライアントサイドのラッピング: サポートされている暗号ライブラリ（Tink や OpenSSL など）を使用して、クライアントは HPKE Seal() オペレーションを実行します。これにより、共有シークレットを確立するために公開鍵がカプセル化され、HKDF-SHA256 を使用してエフェメラル AES 鍵が導出され、ターゲット鍵マテリアルが暗号化されます。
送信: クライアントは、カプセル化された暗号テキストと暗号化された鍵マテリアルを直接連結して Cloud KMS エンドポイントに送信します。このエンドポイントには、すでに耐量子な転送中データ保護機能が組み込まれています。
ラップ解除: Cloud KMS サーバーは、ラッピング鍵の秘密部分を使用して HPKE Open() オペレーションを実行し、Cloud KMS 境界内で鍵マテリアルを安全に復号して保護します。

KEM レイヤでは、X-Wing、ML-KEM-768、ML-KEM-1024 のいずれかを選択できます。鍵導出レイヤは HKDF-SHA-256 を利用し、最終的な対称ラッパーは、標準の 12 バイトのノンスを備えた AES-256-GCM を採用しています。

インポートジョブの設定、外部暗号ライブラリを使用したローカル鍵マテリアルの準備、耐量子ソリューションの管理の詳細については、Cloud KMS の耐量子鍵インポートに関するドキュメントをご覧ください。

Google Cloud の PQC への取り組みにおける重要なマイルストーン

ポスト量子暗号へのグローバルな移行は、マイルストーンを 1 つずつ達成していくマラソンのようなものです。今すぐ最初の耐量子鍵インポートジョブを作成して、アプリケーションの耐量子化のプロセスを開始できます。

皆様からのフィードバックをお待ちしております。また、貴組織のポスト量子戦略を Google がどのようにサポートできるかについて、ぜひお問い合わせください。

- Cloud KMS、シニアソフトウェアエンジニア、Alessio Buraggina

- Google Cloud、シニアプロダクトマネージャー、Erlander Lo

Fault Injection Testing で復元力テスト戦略を簡素化

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

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

データベースの障害やネットワークパスの不調が発生しても、ミッションクリティカルなクラウドサービスはオンラインの状態を維持し続けなければなりません。しかし、現代の分散システムは複雑化しており、高可用性の確保はますます困難になっています。

障害発生時にも可用性と信頼性を維持できるよう、Fault Injection Testing のプレビュー版をリリースいたしました。Fault Injection Testing は、開発者やアーキテクトが障害テストを自動化し、サービス中断時にも予測可能な動作を確保できるように設計されています。

意図的に障害を環境に注入することで、実際のサービス停止が顧客に影響を与える前に、安全メカニズムを検証できます。

ネイティブな復元力テストが重要な理由

セルフホスト型のデータセンターとは異なり、クラウドアプリケーションでは、フェイルオーバーテストを容易にするために、基盤となるインフラストラクチャへの直接アクセスが制限されています。

アプリケーションが障害を乗り越えられることを証明するネイティブツールがなければ、信頼性戦略に重大なギャップが生じ、複数のリスクにさらされることになります。

信頼と評判の低下: 障害が頻繁に発生したり、パフォーマンスが低下したりすると、顧客の不満を招き、ブランドイメージに長期的なダメージを与えます。
コンプライアンスと規制によるペナルティ: 多くの業界、特に金融機関では、障害復旧機能を証明できないと、コンプライアンス違反、監査、罰金につながる可能性があります。
移行の遅延: ゾーン障害が発生しても重要なアプリケーションの安定性を維持できることを検証できない場合、大規模な移行プロジェクトは停滞してしまいがちです。

Fault Injection Testing の仕組み

Fault Injection Testing では、テストテンプレートを作成してテストを実行できます。これらのテンプレートはブループリントとして機能し、注入する特定の障害と、テストの対象となるリソースを定義します。

この公開プレビュー版では、次の 2 つの主な障害シナリオをテストできます。

Cloud SQL のフェイルオーバー: この障害は、高可用性 Cloud SQL インスタンスの、プライマリゾーンからスタンバイゾーンへのフェイルオーバーをトリガーします。
アプリケーショントラフィックの劣化: レイヤ 7 ロードバランサを介して、レイテンシと HTTP エラーコードを選択的に追加できます。

Fault Injection Testing では、障害が注入される前に自動ドライランが実行されます。この読み取り専用のシミュレーションでは、権限がチェックされ、影響を受けるすべてのリソースの最新リストが提供されます。

スコープを確認したら、手動で注入を開始できます。テンプレートで定義した期間が経過すると、タイマーが切れて障害が元に戻ります。

テスト中に、アプリケーションが計画どおりに動作していることを確認できます。計画どおりに進まない場合は、停止と復元の機能を使用して、テストを直ちに停止し、リソースを通常の状態に復元できます。

プレビュー期間中は、ベストプラクティスとして、本番環境以外で FIT を使用することをおすすめします。プレビュー版では、サービスが既存のテスト手法にどのように適合し、補完するのかを早期に確認できます。また、プロダクトの改善に役立つフィードバックを Google に提供することもできます。

企業向けに設計

KeyBank や Servier などのパートナーは、すでに Fault Injection Testing を使用してデプロイを検証しています。これらの組織はネイティブなフォールトインジェクションを活用することで、ゾーンの停止といった極めて過酷な障害シナリオをシミュレーションし、サービスの安定稼働を確かなものにしています。

Fault Injection Testing を使ってみる

Fault Injection Testing は、Google Cloud コンソール、gcloud CLI、REST API を介して利用できます。

プレビュー版へのアクセスをリクエストする: Google Cloud アカウントチームに連絡して、プロジェクトをプレビュー版に追加します。
API を有効にする: Google Cloud コンソールで「Fault Testing API」を検索し、有効にします。
ロールを割り当てる: チームに roles/faulttesting.operator ロールがあり、テストを構成して実行できることを確認します。
最初のドライランを実行する: 本番環境以外で Cloud SQL またはロードバランサリソースのテンプレートを作成し、ドライランを実行して潜在的な影響を確認します。

実装の詳細については、Google のアカウント担当者にお問い合わせいただくか、Fault Injection Testing のユーザーガイドをご覧ください。

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

Cloud CISO の視点: AI 時代に水道事業者を保護するためのヒント

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

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

2026 年 8 月、2 回目の投稿となる「Cloud CISO の視点」をご覧いただきありがとうございます。今回は、Chris Sistrunk と Stephanie Kiel が、水道事業者が直面している重大な課題と、OT 運用担当者がインフラストラクチャを保護するために実行できる具体的な手順について詳しく説明します。

これまでのすべての「Cloud CISO の視点」と同様、このニュースレターのコンテンツは Google Cloud 公式ブログに投稿されます。現在ウェブサイトでご覧になっていて、メール版の受信をご希望の方は、こちらからご登録いただけます。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud で取締役会向けの重要な情報を得る'), ('body', <wagtail.rich_text.RichText object at 0x7fddb47bb610>), ('btn_text', 'Insights Hub を見る'), ('href', 'https://cloud.google.com/solutions/security/board-of-directors?utm_source=cgc-site&utm_medium=et&utm_campaign=FY26-Q2-GLOBAL-GCP39634-email-dl-dgcsm-CISOP-NL-177159&utm_content=-&utm_term=-'), ('image', <GAEImage: GCAT-replacement-logo-A>)])]>

AI 時代に水道事業者を保護するためのヒント

Mandiant Consulting、OT 担当プラクティスリーダー Chris Sistrunk 氏、および Google Cloud、政府関連業務および公共政策、クラウドセキュリティポリシー責任者、Stephanie Kiel

Chris Sistrunk, Practice Leader, OT, Mandiant Consulting

Google Cloud の脅威インテリジェンスチームは、地政学的紛争の中で、脅威アクターが重要インフラを標的にする際、手口がますます大胆になっていることを確認しています。最近、米国では、インターネットに接続された水道事業のプログラマブルロジックコントローラを標的とした攻撃が増加しています。

Stephanie Kiel, Head of Cloud Security Policy, Government Affairs and Public Policy, Google Cloud

これまで、サイバーインシデントによって業務が中断されることはあまりありませんでした。その理由の一つとして、水道事業者が長年にわたり手動オーバーライド機能を備え、水が消費者に届く前に水質検査を実施してきたことが挙げられます。ポンプや配管の故障は、サイバー脅威とは無関係の理由で日常的に発生します。

しかし、これには緊急の対応と、より強力なセキュリティ対策への取り組みが必要であることは確かです。手動によるオーバーライドは信頼性の高いセーフティネットとなりますが、サイバー脅威を防ぐには、基本的なデジタルセキュリティへの取り組みが依然として必要です。特に AI 時代においてはなおさらです。

脅威を把握し、リスクを管理した対応をおすすめします。水道事業者のセキュリティの現状を踏まえると、これらのシステムを安全に保つ独自の運用レジリエンスを考慮して、さらなる対策を真剣に検討する必要があることを示しています。

上下水道事業者が検討すべきアクション

リソースに制約のある公益事業にとって、最も効果的な防御策はサイバーセキュリティの基本に注力することです。これらの基本的な対策を優先することで、システムを大幅に強化し、組織をはるかに攻撃しにくく、復元力の高い標的に変えることができます。これにより、リソースが豊富な脅威アクターでさえ、別の標的を探すようになります。

アセットのインベントリを作成し、露出を評価する: 制御システムがインターネットに安全でない状態で露出しているかどうかを特定します。このような状態により、脆弱性が悪用される可能性が高くなります。
基本的なセキュリティ対策: デフォルトの認証情報を安全なパスワードに置き換え、ファイアウォールを含む、公開されているアクセスポイントを厳格に強化します。
バックアップ: 制御システムを含む重要なシステムが、実績のある 3-2-1 バックアップルール（データのコピーを 3 つ作成し、2 種類のストレージに保存し、少なくとも 1 つのコピーをオフサイトに保存する）に従って保護されていることを確認します。サイバー攻撃によるダウンタイムを最小限に抑えるために、重要な予備機器を確保します。
セグメンテーション: ネットワークセグメンテーションと多要素認証を使用して、必要に応じてリモートアクセスを厳密に制御します。完全な制御が必要ない場合は、読み取り専用アクセスを使用する必要があります。
緊急時計画: サイバーインシデント計画を、FEMA NIMS や産業用制御システムのインシデントコマンドシステムなど、既存の全ハザードインシデントコマンドシステムに統合します。これは、物理的な配管の破損、煮沸水警報、自然災害に対してすでに使用しているのと同じ対応構造です。
サードパーティとベンダーのアクセスの保護: 多くの水道事業者は、自社の IT や OT を管理せず、サードパーティのシステムインテグレータに依存しているため、システムインテグレータやメンテナンス請負業者が使用するリモート接続を監査する必要があります。サードパーティベンダーに厳格なアクセス制御（MFA 標準など）とロギング要件を適用する必要があります。

これらの推奨事項は、米国水道協会、全米地方水道協会、Water-ISAC、環境保護庁、サイバーセキュリティインフラストラクチャセキュリティ庁、FBI のガイダンスを反映しています。

IT および OT リーダーへの推奨事項: ガバナンスのギャップを埋める

IT と OT のリーダーは、統一されたガバナンスフレームワークを構築するために連携する必要があります。また、サイバーフィジカルシステムのレジリエンスを長期的に高めることに注力すべきです。これは、行政機関、民間組織、個人のすべてが一丸となって取り組む必要があることです。これらのシステムをセキュリティが確保され、適応性が高く、中断から迅速に復元できるものにすることが今後の目標です。

ほとんどの場合、PLC は標準的なソフトウェア開発手法の対象外ですが、組織が使用するソフトウェアに対する堅牢なアプローチは、NIST の Secure Software Development Framework（SSDF）で説明されているように、セキュリティポスチャー全体を大幅に強化できます。また、これらはレジリエンスを測定するのに役立つ先行指標の好例でもあります。Google は、先行指標を評価するためのガイドを公開しています。

手動によるオーバーライドは信頼性の高いセーフティネットとなりますが、サイバー脅威を防止するには、特に AI 時代においては、基本的なデジタルセキュリティへの取り組みが依然として必要です。

テクノロジーの進化に伴い、セキュリティのモダナイズが不可欠となっています。事後対応型の手動モデルから、人間の専門知識を意思決定の中心に据えた AI 拡張型アプローチへの移行が必要です。このアプローチは、小規模なセキュリティチームの能力を増強するまたとない機会を提供します。

昨今の脅威に先手を打つには、組織は単純なコンプライアンスチェックリストから脱却し、コンプライアンスを主要な目標ではなく、優れたセキュリティの自然な結果とする、よりアジャイルで脅威を考慮した戦略を採用する必要があります。

Mandiant のオペレーショナルテクノロジー（OT）に関する Theory of 99 は、AI 時代においてさらに重要性を増しています。機会のファネルは大幅に圧縮されていますが、OT に影響を与えるほど深い侵入では、次のようになります。

侵害されたシステムの 99% は、コンピュータワークステーションとサーバー
マルウェアの 99% は、コンピュータワークステーションとサーバーを対象に設計される
フォレンジックの 99% は、コンピュータワークステーションとサーバーで実施される
検出機会の 99% は、コンピュータワークステーションとサーバーに関連するアクティビティ
侵入の滞留時間の 99% は、Purdue レベル 0～1 のデバイスが影響を受ける前に、市販のコンピュータ機器で発生する

その結果、IT ネットワークと OT ネットワークを標的とする脅威アクターが使用する戦術、手法、手順には、多くの場合、大きな重複があります。しかし、Theory of 99 は、AI 時代における防御側の大きな優位性を浮き彫りにしています。高度な AI 機能を使用して中間インフラストラクチャの 99% を保護することで、組織は脅威をプロアクティブに無力化し、物理的な運用プロセスの重要な 1% を確実に保護できます。

サイバー防御のための AI

以前にもお伝えしたように、AI 機能はネットワークセキュリティのバランスを防御側に有利にシフトする機会を提供します。悪意のある行為者が攻撃ライフサイクル全体で AI 機能を活用するケースが増えているため、防御側の優位性はさらに重要になっています。

現在の脅威環境では、防御を自動化することで、人間のセキュリティチームの能力を強化し、意思決定と生産性を向上させ、重大な脆弱性が悪用される前に対処できます。重要インフラプロバイダは、慎重な計画を立てることで、物理的な資産を保護しながら、より復元力のある、脅威を考慮した防御を構築できます。

防御における AI のメリットを効果的に実現するには、AI ツールを構造化された意図的な方法でシステムに統合する必要があります。事業者は、AI が物理プロセスにもたらす特有の脆弱性を理解し、セキュリティの自動化の恩恵を受けられる特定のビジネスユースケースを評価し、継続的なテストとモニタリングのための明確なフレームワークを確立することが重要です。Google のアプローチの一環として、セキュア AI フレームワークを開発しました。これは、分野を問わず、AI 機能のセキュアなインテグレーションとデプロイを実現するのに役立ちます。

最も重要なのは、人間による監視を中核に据えることです。つまり、AI は意思決定をサポートするものであり、安全対策をインシデント対応計画に直接組み込む必要があります。

水の安全の今後

悪意のあるサイバー脅威から水道システムを保護することは、単なる技術的な課題ではなく、公共の安全を守るための基本的な責務です。清潔で信頼できる水へのアクセスは不可欠なサービスであるため、連邦政府、州政府、地方自治体は、サイバー脅威に直面してもこの重要な公共インフラストラクチャの継続性を確保するために、政策議論から断固とした行動へとますます移行していくことが予想されます。

たとえば、国家サイバー長官室はテキサス州と提携して、水道インフラプロバイダをサイバー攻撃から保護するための試験運用プログラムを立ち上げたばかりです。また、米国上院議員は、最近の出来事に対応して新しい法案をすでに提出しています。

Google は、お客様がクラウドおよびハイブリッドクラウドの OT 環境を保護できるよう支援することに尽力しています。重要インフラストラクチャの保護に関する Google のガイダンスについて詳しくは、CISO インサイトハブをご覧ください。

aside_block: <ListValue: [StructValue([('title', '新しいことを学ぶ'), ('body', <wagtail.rich_text.RichText object at 0x7fdda5efb590>), ('btn_text', '今すぐ見る'), ('href', 'https://x.com/googlecloud/status/2090213589558698309?s=20'), ('image', <GAEImage: Cloud-CISO-Perspectives-logo-A>)])]>

その他の最新情報

セキュリティチームからこれまでに届いた今月のアップデート、プロダクト、サービス、リソースに関する最新情報は以下のとおりです。

高度なセキュリティガバナンスで自律型エージェントを強化: AI エージェントが有用性と安全性を確保するには、アクセス権とガードレールが必要です。Google 最新の AI インフラストラクチャの現状レポートによると、テクノロジーリーダーの 79% が、セキュリティ、ガバナンス、運用のいずれかを推論のスケーリングにおける最大の課題として挙げています。詳細はこちら。
2026 年のクラウドリスクの状況: ほとんどのセキュリティ検出結果は、実際の攻撃者の機会ではない: Wiz Research のテレメトリーにより、重大度の高い検出結果の大部分に侵害への経路がない理由が明らかになりました。詳細はこちら。
Google Cloud Fault Injection Testing のプレビュー版をリリース: データベースに障害が発生し、ネットワークパスが不安定になった場合でも、ミッションクリティカルなクラウドサービスをオンラインに維持する必要があります。Fault Injection Testing（FIT）は、障害テストを自動化し、障害発生時に予測可能な動作を保証するのに役立ちます。詳細はこちら。
Wiz が AI を活用したデータ検出を構築した方法: バケットスキャナをコンテキストエンジンに変えたマルチエージェントパイプラインとフィードバックループの内部。詳細はこちら。
Wiz による FinOps の民主化: Wiz Cloud Cost が費用配分を自動化し、デベロッパー主導の費用最適化を促進して、費用をビジネス価値に結び付ける方法。詳細はこちら。
Google Workspace Studio の多層防御でエージェントのリスクを防御: Studio には、脅威アクターによるリスクを軽減する多層防御と、組織がエージェントを安全に導入できるようにする堅牢なオブザーバビリティツールが組み込まれています。安全性を重視して設計された Google のアーキテクチャを基盤とする Studio は、ネイティブな脅威防御とエコシステムの詳細な可視化を組み合わせて、マルチステップのエージェント型ワークフローを保護します。詳細はこちら。

今月公開されたその他のセキュリティ関連の記事については、Google Cloud 公式ブログをご覧ください。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud CISO Community にご参加ください'), ('body', <wagtail.rich_text.RichText object at 0x7fdda69e86d0>), ('btn_text', '詳細'), ('href', 'https://rsvp.withgoogle.com/events/google-cloud-ciso-community-interest-form-2026?utm_source=cgc-blog&utm_medium=blog&utm_campaign=FY25-Q1-global-GCP30328-physicalevent-er-dgcsm-parent-CISO-community-2025&utm_content=cisop_&utm_term=-'), ('image', <GAEImage: GCAT-replacement-logo-A>)])]>

脅威インテリジェンスに関するニュース

ロシアが関心を寄せる個人を標的とした複数のクラスタ: Google Threat Intelligence Group（GTIG）は、正規の認証フローを悪用して、ヨーロッパと米国全域の学術機関、航空宇宙、政府機関、シンクタンクで働く個人を標的とする、ロシアのサイバーエスピオナージ脅威クラスタと疑われる 3 つのクラスタを追跡しています。詳細はこちら。
AI インフラストラクチャへの 90 日間にわたる攻撃: Wiz のハニーポットが、RCE、ブラインドプロンプトインジェクション、メモリ認証情報の窃取を通じて LiteLLM、MCP サーバー、AI フレームワークを標的とするアクティブなキャンペーンを明らかにしました。詳細はこちら。
バージョン管理 DFIR: GitHub、GitLab、Bitbucket、Azure DevOps のクイックリファレンス: 主要なバージョン管理サービスにおけるログの可視性、インシデントへの備え、脅威ハンティングに関する実務者向けガイド。詳細はこちら。
arrayref に対する Rust サプライチェーン攻撃: 北朝鮮によるキャンペーンと大幅に重複: arrayref Rust クレート（およびその他）の悪意のあるバージョンが、コンパイル時にバックドアを実行しました。このキャンペーンのインフラストラクチャは、Mastra や axios など、最近の北朝鮮のサプライチェーン攻撃と重複しています。詳細はこちら。

注目の Google Cloud ポッドキャスト(英語)

Cloud Security Podcast: AI、エージェント、Rust、タブを使用したブラウザのパッチ適用: Chrome Security の Jasika Bawa と Doug Turner が、Google Chrome が AI エージェントを使用して、これまでにない規模でセキュリティの脆弱性を自律的に特定してパッチを適用し、ブラウザの更新頻度を大幅に向上させている方法について説明します。ポッドキャストを聴く。
Cloud Security Podcast: Wiz の AI 脆弱性調査プロジェクト Atlas のすべて: Wiz の脆弱性調査責任者である Near Orfeld 氏が、クラウドインフラストラクチャにおける深刻なゼロデイ脆弱性を発見するために、チームがマルチエージェント AI システムをどのように活用しているかを詳しく解説します。ポッドキャストを聴く。
Cloud Security Podcast: 脆弱性のクラスを大規模に根絶する Google の手法: AI がコードを記述し、人によるレビューが追いつかない状況下でも、安全性を維持できる Google 規模のエンタープライズ基盤を構築するにはどうすればよいでしょうか。Google のプリンシパルセキュリティエンジニアである Christoph Kern が、AI 時代における「安全性を重視した設計」の真の意味を探ります。ポッドキャストを聴く。

月 2 回発行される「Cloud CISO の視点」をメールで受信するには、ニュースレター(英語版)にご登録ください。次回も Google Cloud からセキュリティ関連の最新情報をお届けします。

- Mandiant Consulting、OT 担当プラクティスリーダー Chris Sistrunk 氏

- Google Cloud、クラウドセキュリティポリシー、政府関連業務および公共政策責任者、Stephanie Kiel

JBサービス: Google Threat Intelligence で、さらに効率的で高精度、プロアクティブなセキュリティサービスを提供

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

JBサービス株式会社（以下、JBサービス）は、SOC（Security Operations Center）の運用を通じて、企業のセキュリティ監視サービスを 24 時間 365 日体制で提供しています。近年は SOAR（Security Orchestration, Automation and Response）で、セキュリティ対策の自動化や効率化を推進。さらに Google Threat Intelligence を導入し、SOAR に組み込むことで、セキュリティの脅威をプロアクティブに阻止できる体制を実現しています。Google Threat Intelligence 導入の背景や効果、新たな顧客向けサービスへの展開について、導入プロジェクトを主導した 3 人の担当者にうかがいました。

利用しているサービス:
Google Threat Intelligence

圧倒的な情報量と利便性を評価し、Google Threat Intelligence を導入

JBサービスは、さまざまな企業の DX 推進を支援する JBCCホールディングスの事業子会社として、2007 年に設立。2015 年からセキュリティ事業を展開し、運用センター SMAC（Solution Management and Access Center）を中心とする SOC サービスを通じて、高い評価を得てきました。上級執行役員でセキュリティ事業部事業部長の平田直樹氏は、同社の持ち味を次のように説明します。

「運用センター SMAC は、SOC とヘルプデスクが同一拠点で連携する独自の運用体制を強みに、アラート検知からユーザー対応、改善提案までをワンストップで提供しています。さらに、既存の SOC で培った知見を基盤に、AI セキュリティ領域へとサービスを拡張し、監視・対応・改善を一体化した次世代 SOC の実現に取り組んでいます。」

同社は SOC 業務に約 80 名、セキュリティ事業部全体では約 200 名のスタッフを擁し、きめ細かなサービスを展開してきました。その鍵となっていたのが、SOAR と各ベンダーから提供される脅威情報を連携させたオペレーションです。しかし、平田氏はさらなる安心・安全の確保のために、次の目標を見据えていたと振り返ります。

「そこで注目したのが、Google Threat Intelligence です。Google Threat Intelligence には、弊社のエンジニアたちが以前から見てきた VirusTotal や、定評ある Mandiant の知見、Google Cloud が持つ膨大なデータまで統合されています。特に、単なる脅威情報の収集にとどまらず、世界規模で観測されている攻撃情報や攻撃者の動向を一元的に把握できる点に大きな魅力を感じました。従来は複数の情報ソースを横断して確認していた分析業務も、Google Threat Intelligence を活用することで効率化でき、アナリストがより高度な調査やお客様への提案に時間を割けるようになることが期待できます。」

第一サイバーセキュリティ部部長で、エンドポイントにおける運用チームのマネージャーを務める鈴木祐介氏によれば、インターフェースのわかりやすさや日常業務での使いやすさ、顧客対応の迅速化が期待できる点も、Google Threat Intelligence への評価を高めました。

「Google Threat Intelligence のインターフェースは、VirusTotal の延長線上のような感覚で、エンジニアにとって非常にわかりやすいものでした。しかも Google Threat Intelligence では、IOC（Indicator of Compromise：攻撃や侵害の痕跡を示す指標）も充実しています。評価の際にはアドバンスドライセンスを利用し、攻撃者情報と攻撃手法を関連付けた情報まで参照できました。Google Threat Intelligence で得られる高品質な脅威情報を SOAR に取り込み、自動分析や相関分析に活用することで、アナリストが対応すべきアラートを効率的に絞り込めるようになりました。」

従来は検出できなかった脅威を可視化し、プロアクティブな防御を展開

JBサービスでは、2025 年 3 月から約 2 か月間、PoC（Proof of Concept: 概念実証）を実施したうえで、Google Threat Intelligence の採用を決定。直後に実装へと移り、SOC サービスの効率化や精度向上、既存システムとの API 連携などの検証を自社グループ内で重ねてきました。ネットワーク運用チームのマネージャーを務める第二サイバーセキュリティ部部長の吉永臣作氏は、技術的なポイントをこう説明します。

「もともと弊社では SOAR を活用してセキュリティ運用の自動化を進めていましたが、Google Threat Intelligence の豊富な脅威インテリジェンスを既存の運用に組み込むことは、新たな取り組みでした。導入にあたっては、API を通じて取得できる情報の精度や有用性を検証しながら、Google Threat Intelligence の情報を SOAR へ連携する仕組みを構築し、脅威情報の収集や分析の自動化を実現しました。また、既存のセキュリティ製品が提供する脅威情報との重複を避け、それぞれの強みを生かせる形で運用を設計することも重要なテーマでした。Google Cloud には検証段階から伴走支援いただき、課題を一つひとつ解決しながら、円滑に本番運用へ移行することができました。」

PoC および導入の過程における Google Cloud のサポートは、平田氏も高く評価していました。

「検討段階から Google Cloud のオフィスで丁寧な説明を受け、エンジニアの皆様にも継続的なサポートをいただきました。導入時には細かな確認や調整を重ねる必要がありましたが、その支援のおかげで、PoC から実装、運用開始までを安心してスムーズに進めることができました。」

2025 年 6 月から約 1 年間かけて行われた社内運用では、確かな手応えも得られています。

「特に大きな効果を感じているのは、膨大な EDR（Endpoint Detection and Response）ログに埋もれた脅威を迅速に特定できるようになったことです。従来は多くのログを分析しながら脅威の有無を見極める必要がありましたが、Google Threat Intelligence を活用することで、優先的に対応すべきリスクを効率的に抽出できるようになりました。また、豊富な IOC を活用することで、インシデントが発生する前の兆候を把握し、お客様に対して先回りした対策や提案を行うなど、よりプロアクティブなサービスの提供を実現しています。」（鈴木氏）

「業務の自動化と最適化を進めた結果、アナリストの負荷増加を抑えながら運用効率を高めることができました。また、Google Threat Intelligence が提供する豊富な脅威情報と分析結果を活用することで、検知精度の向上と対応品質の標準化も実現しています。セキュリティ分析は担当者の知識や経験に依存しやすい領域ですが、経験値の差による判断のばらつきを抑え、より迅速かつ一貫性の高い分析が可能になりました。その結果、お客様へ提供するサービス品質の向上と、より高い安心・安全の実現につながると考えています。」（平田氏）

1 年間の運用で得られた成果を基盤に、新たな SOC サービスの提供を開始

実際の作業を通して、機能性や信頼性の高さを改めて確信した同社は、2026 年 7 月、新たな SOC サービスの提供を開始しました。これは Google Threat Intelligence と SOAR を組み合わせて監視・分析・対応の高度化を実現したもので、既存のセキュリティサービスに追加して利用できるようになっています。

平田氏は「高度な脅威インテリジェンスを自社で個別に運用することが難しいお客様でも、JBサービスの SOC サービスを通じて、最新の脅威情報を活用した監視・分析・対応を受けられる点が大きなメリットです」と語ります。

新たなサービスは段階的な提供が計画されています。第 1 弾では、エンドポイントのセキュリティを強化し、その後ファイアウォールやクラウドへも対象を広げていく予定です。顧客に寄り添った独自のサービスをさらに強化し、より高い安心・安全を提供するため、平田氏はダークウェブを対象とするデジタルスレットモニタリングや、生成 AI の活用も視野に入れていました。

「セキュリティを担保する重要性は、ますます高まっています。最近は生成 AI の技術が悪用されるケースも増えていますが、こちらも Google Threat Intelligence と Gemini をさらに活用することで、緻密なセキュリティ保護が提供できるようになるでしょう。もちろん、セキュリティ管理の分野では誤検知をゼロにはできませんし、最終的には、長年培われてきた人間のノウハウや経験値が重要になってきます。弊社のスタッフにも、より高度な、人にしかできない分析に注力してもらいたい。そのためにも Google Threat Intelligence で、運用の効率化や自動化を追求していく予定です。」

JBサービス株式会社
企業の DX 推進を支援する IT 企業、JBCCホールディングスの事業子会社として、現在の JBCC株式会社（旧・日本ビジネスコンピューター株式会社）の会社分割により設立され、2015 年からセキュリティ事業を展開。企業の IT システム運用や情報セキュリティ対策、機器の保守、ヘルプデスク業務に加え、BPO および AI 運用を含むサービスなどを 24 時間 365 日、一元的に代行・支援する。巧妙化するサイバー攻撃への対応、IT 人材不足などの課題を抱える企業に対し、包括的なサポートを提供している。

インタビュイー（写真左から）
・セキュリティ事業部セキュリティサービス本部第二サイバーセキュリティ部部長　吉永臣作氏
・セキュリティ事業部上級執行役員事業部長　平田直樹氏
・セキュリティ事業部セキュリティサービス本部第一サイバーセキュリティ部部長　鈴木祐介氏

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

プライバシー重視の AI で脳腫瘍研究を後押し

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

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

医療と AI の融合は、目覚ましいイノベーションをもたらしています。しかし現在、開発者は患者のプライバシー保護と、実世界の多様なデータに基づく検証と評価を両立させた、信頼性の高い医療 AI ツールを構築するという難題に直面しています。Google Cloud は、戦略的なコラボレーションと Confidential Computing を組み合わせてこの難題にアプローチしています。

検証プロセスにおいて患者のプライバシーと AI モデルの両方を保護するために、Google は MedPerf イニシアチブを通じて MLCommons と連携しています。今年の Google Cloud Next で初めて発表されたこのパートナーシップは、Confidential Computing を活用して、実際の環境で AI モデルをベンチマークするための安全なデータクリーンルームを確立するものです。

課題: データを見ることなく AI を評価する

テクノロジー業界と学術界に 125 以上のメンバーを擁するグローバルコミュニティである MLCommons は、医療 AI の評価を標準化するため、2023 年に MedPerf を立ち上げました。AI モデルのベンチマーク用オープンソースプラットフォームである MedPerf は、連携評価によるモデルテストを通じて臨床研究を推進しています。

Google Cloud Confidential Space を使用すると、ハードウェアで分離された高信頼実行環境（TEE）内で独自の AI モデルを評価できます。この特別な仮想マシンは、実行中のメモリを暗号化し、オペレーティングシステムを強化するため、病院や研究機関、その他の参加者、さらには Google であっても、評価中にモデルコードや患者データを閲覧することはできません。

医療 AI のベンチマークには高いコンピューティング負荷がかかるため、Confidential VM は CPU だけでなく GPU にも拡張されています。GPU 加速推論時においてもモデルの重みと患者データを保護するため、MedPerf は NVIDIA H100 GPU を搭載した Google Cloud の A3 マシンシリーズ上で稼働します。このシステムは、CPU の Intel TDX テクノロジーと GPU の NVIDIA Confidential Computing を組み合わせた構成となっています。

患者データがワークロードに投入される前に、システムは、承認されたコードのみが正規の Confidential Computing ハードウェアで実行されていること、および環境が適切にセキュリティ強化されていることを暗号によって証明します。

実世界における医療 AI の評価: MedPerf と GCP Confidential Computing のデモ

ML Commons MedPerf が Google Cloud Confidential Computing と連携し、医療 AI モデルの安全な実環境評価を実現する仕組みをご紹介しています。

理論を大きな成果へ: 脳腫瘍研究のさらなる進展

このテクノロジーは、Federated Tumor Segmentation（FeTS）イニシアチブを通じて、すでに極めて重要な研究を推進する原動力となっています。膠芽腫などの脳腫瘍は症例数が少ないため、単一の病院だけで AI トレーニングの精度を高めるのに十分なデータを収集することは困難です。

さらに厄介なことに、ある病院では完璧に機能するモデルが、患者の属性、データの取得手法、さらには機器の差異により、別の病院では十分な性能を発揮できないケースがあります。

インディアナ大学の Spyridon Bakas 博士、ノースウェスタン大学の Yury Velichko 博士、カナダのアルバータ大学の Amber Simpson 博士といった先見の明のある研究者の協力を得て、Google Cloud 上の MedPerf は世界各地の脳 MRI の非公開データで AI モデルを検証し、潜在的なパフォーマンスギャップを特定しています。

たとえば、あるサイトでは 95% の精度を発揮するモデルが、別のサイトでは 63% の精度しか達成できない場合があります。Google の協働的アプローチは、臨床現場に届く AI ツールが、特定の層に偏らない真に代表的な患者集団で機能することを保証するものです。

臨床現場での信頼確立と検証

このコラボレーションによる成果は、臨床研究の最前線にいる方々の言葉に最もよく表れています。

ノースウェスタン大学放射線科准教授の Yury Velichko 博士は次のように述べています。「Google Cloud でのフェデレーションラーニングのテストを通じて、医療 AI の未来は、安全かつスケーラブルな、共同研究に適したクラウド環境にあることがわかりました。管理された研究室レベルの環境から一歩踏み出し、本番環境対応のインフラストラクチャでこれらのワークフローを検証できたことは、実際の臨床アプリケーションにおけるフェデレーションラーニングのパフォーマンスとセキュリティを評価する、またとない機会となりました。」

MLCommons の MedPerf リードである Alexandros Karargyris 氏は次のように語っています。「医療 AI は世界中の患者に多大な恩恵をもたらす可能性を秘めています。しかしそれを実現するには、評価に用いるベンチマークが臨床医、研究者、規制当局から信頼されるものでなければなりません。MedPerf を Google Cloud の Confidential Computing インフラストラクチャ上に構築することで、プライバシー、知的財産、ベンチマークの整合性を損なうことなく、実際の患者データで AI モデルを厳密にテストできる未来に向けた大きな一歩を踏み出せました。」

未来：安全な医療のブレークスルーを普及させる

MLCommons と Google Cloud のコラボレーションは、医療 AI における「プライバシーバイデザイン」への根本的な転換を示すものです。Google は、データとモデルを安全に共有、評価しやすくすることで、より迅速かつ安全で公平性の高い医療イノベーションの実現を後押ししています。

Google Cloud 上での MedPerf プラットフォームの活用にご関心のある研究機関や医療モデル開発者の方は、medical@mlcommons.org または担当の Google Cloud アカウントチームまでお問い合わせください。

- Google Cloud、シニアクラウドセキュリティプロダクトマネージャー、Rene Kolga

- Google、ソフトウェアエンジニア、Peter Mattson

PQC をわかりやすく解説: Google Cloud のポスト量子暗号ロードマップ

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

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

暗号解読に有効な量子コンピュータが将来登場することに備え、インフラストラクチャとサービスを保護することは、Google が 10 年前から目標としてきたことです。Google は、すべての人にメリットをもたらすオープンスタンダードを推進することで、開発者を支援することに取り組んできました。ポスト量子暗号（PQC）が成熟するにつれて、Google は社内サービスとお客様向けサービスの両方で、インフラストラクチャへの PQC のロールアウトを進めてきました。

今回は、2029 年までの PQC 移行に向けた Google Cloud の最新ロードマップをご紹介します。

Google の戦略: 安全性を重視した設計

Google の PQC 移行戦略は、Google 量子脅威モデルに基づいており、3 つの主要なドメイン全体で保護を優先しています。

Store Now, Decrypt Later（SNDL）リスクの軽減: 現在の暗号化されたデータが将来の量子コンピュータによって収集、復号されるのを防ぎます。
偽造に対する完全性の確保: 攻撃者がデータの内容を改ざんしたり ID を偽造したりするのを防ぐために、デジタル署名を強化します。
暗号アジリティの基盤となる機能の強化: 暗号化標準の進化に合わせて、最小限のエンジニアリング作業で新しい暗号化標準を簡単に採用できる柔軟なシステムを構築します。

Google は、規制の期限をはるかに先取りして、社内インフラストラクチャとお客様向けサービスの両方で PQC アルゴリズムへの移行を積極的に進めています。

また、パートナーと協力して、Google Cloud Dedicated（GCD）や Google Distributed Cloud（GDC）などの Sovereign Cloud イニシアチブ全体で PQC ソリューションのデプロイを進めています。同様に、Google の戦略により、AI サービス全体へのポスト量子保護の統合を進めることが可能になり、次世代のクラウドワークロードの安全性を確保できるようになります。

これらの取り組みは、Google Cloud 全体でポスト量子暗号への完全な対応を実現するという Google の包括的な戦略の基本となる柱です。この情勢が変化するにつれて、Google はデプロイスケジュールを継続的に見直し、更新していきます。

Google Cloud PQC ロードマップの図解。Google の取り組みは 2029 年に収束し、それ以降も継続されます。

Google は、取り組みが収束する 2029 年までに PQC への完全な対応を達成する予定です。Google は、より幅広い業界のガイダンスと進化するグローバルスタンダードをサポートするため、これらの取り組みを 2030 年代にかけて継続することを見込んでいます。これらの標準には、CNSA 2.0 や NIST IR 8547 で定義された移行パスが含まれており、2030 年から 2035 年の間に、量子脆弱性のあるレガシーアルゴリズムが最終的に廃止されることが予想されています。

直近の進捗: 2026 年のマイルストーン

量子時代のリーダーシップには、グローバル規模でのデプロイが必要です。Google は、お客様に即時の保護を提供する基盤となるマイルストーンを達成しました。

API エンドポイントの対応: Google Cloud API エンドポイントで耐量子鍵交換が提供されるようになり、将来の復号から受信トラフィックを保護できるようになりました。これらのエンドポイントには google.com と *.googleapis.com が含まれ、いずれも NIST で標準化された ML-KEM（FIPS 203）をハイブリッドモードで実装済みです。
ロードバランサの PQC サポート: アプリケーションロードバランサとプロキシロードバランサで、TLS 1.3 の耐量子ハイブリッド鍵交換（X25519MLKEM768）がサポートされるようになりました。当初はオプトイン方式で提供されるため、お客様は既存のアプリケーションへの影響を最小限に抑えつつ、検証を行うことができます。
大規模な耐量子証明書の試験運用: IETF PLANTS ワーキンググループと協力し、運用チームへの影響を最小限に抑える公開鍵基盤（PKI）の標準を策定しています。Chrome と Cloudflare は、WebPKI で PQC 署名を使用する際の課題に対処するため、Merkle Tree 証明書の試験運用を開始しました。Google は、これらの活動から得られた知見を標準化ワーキンググループと共有しています。
Cloud KMS PQC アルゴリズム: 暗号化鍵と署名鍵に使用する NIST で標準化された PQC アルゴリズム（ML-KEM、ML-DSA、SLH-DSA）の一般提供が開始されました。

2029 年までのロードマップ

Google Cloud では、量子コンピューティングへの対応準備を実現するため、お客様中心の具体的なジャーニーを策定しました。これにより、耐量子イニシアチブの優先順位付けが可能になります。このリスクベースのアプローチを採用することで、セキュリティエキスパートが量子コンピューティングの潜在的な影響を最も受けやすいと特定したコアジャーニーに焦点を当てます。

量子コンピューティングへの対応準備に向けたコアユーザージャーニーのリスクベースの優先順位付け

これらのシナリオは、Google のサービス全体でグローバルなイネーブルメントを確保し、お客様の現在の状況に合わせてサポートを提供できるよう、さまざまなプラットフォームの視点を提供するものです。

各リスクドメインについて、主要なプロダクトとサービスのロードマップをドメイン別に提供します。なお、ここで取り上げているサービスはすべてを網羅したものではありません。ほとんどのサービスは、それぞれのドメインの目標完了日を達成する見込みです。ただし、エンジニアリング要件の進展やサードパーティの依存関係を考慮し、必要に応じて特定のプロダクトのスケジュールが調整される場合があります。

ドメイン 1: Store Now Decrypt Later（SNDL）の軽減

このドメインは、将来の暗号解読に有効な量子コンピュータ（CRQC）が、現在キャプチャされたデータを復号できる可能性があるという、非対称暗号の脆弱性に対処することに重点を置いています。

Google は、お客様の一般的なジャーニーに基づき、段階的な進展を支援しています。

お客様の顧客のワークロードを保護する: Google Cloud サービスと構成済みのロードバランサに量子コンフィデンシャル TLS 1.3 ハンドシェイクを提供し、ユーザーセッションを保護します。
管理者と開発者のフローを保護する: クラウド環境の管理に使用される管理パスウェイを SNDL から保護します。これには、Cloud VPN や Interconnect などのサービスが含まれます。開発者向けには、クライアントライブラリ、SDK、Google のオープンソース暗号ライブラリである Tink などが含まれます。
データパイプラインを保護する: Google の分析プラットフォームとストレージプラットフォームのデータ転送の機密性を確保します。PQC は、これらのシステムを流れる機密性の高い知的財産や顧客データが、現在キャプチャされ、将来的に量子コンピューティング能力を持つ攻撃者によって復号されるのを防ぐために不可欠です。

ロードマップ以下の変更は 2027 年の実施を目標としています。

ジャーニー	利点	代表的なサービス
Store Now, Decrypt Later の軽減（2027 年末）
お客様の顧客のワークロードを保護する	耐量子 Ingress: 標準化されたポスト量子アルゴリズムを使用してクラウド境界を保護します。	アプリケーションとプロキシのロードバランシング[2026 年（完了）]
管理者と開発者のフローを保護する	安全な運用: 管理とデプロイのスタックが新たな暗号化規格を満たしていることを検証します。	量子コンフィデンシャル ALTS[2025 年（完了）]
		API エンドポイント[2026 年（完了）]
		Cloud VPN、Cloud Interconnect、GCE OS Login、Cloud SDK、gCloud CLI、GKE サービスメッシュ、クライアントライブラリ[2026 年 / 2027 年]
データパイプラインを保護する	機密データの転送保護: 量子攻撃者から、機密性の高い知的財産や顧客データを保護します。	Cloud Storage SDK、Storage Transfer Service、BigQuery CLI、Data Transfer Service[2026 年 / 2027 年]

ドメイン 2: 完全性と否認防止

このドメインでは、データの完全性と真正性を損なう可能性のある偽造から保護するために、デジタル署名と証明書の耐量子化に取り組みます。

ソフトウェアサプライチェーンの保護: 量子耐性のある証明書が付与された、信頼できる改ざんされていないイメージのみが本番環境で実行されるようにすることで、量子攻撃者によるビルドの改ざんを防ぎます。これには、Binary Authorization、Cloud Build、Assured Open Source Software などのサービスが含まれます。
耐量子証明書の発行: 内部および外部の認証局（CA）を含む公開鍵基盤（PKI）を移行して、ML-DSA 証明書と、有用な場合は SLH-DSA 証明書をサポートします。この移行は、現在策定中の Internet Engineering Task Force（IETF）の標準化の取り組みに沿って行われます。Google はこうした取り組みに積極的に貢献しており、次のような大規模な実験もいくつか実施しています。

Web PKI 向けの Merkle Tree Certificates などの新たな手法を通じて、証明書チェーンの検証パフォーマンスに影響を及ぼす可能性がある PQC 署名サイズの増大に対処します。
Certificate Authority Service（CAS）などのプライベート CA ソリューションで、ML-DSA / SLH-DSA（純粋な PQC）ベースの証明書をサポートします。
機密保持を目的として、すでに PQC をサポートしている内部トラフィックプロトコル ALTS に加えて、量子認証を追加します。デジタル署名と公開鍵基盤に対する Google のアプローチについて、技術的な詳細をこちらでご確認いただけます。

ID とアクセスの保護: サービスアカウントキーやトークン（JWT / OAuth）などの認証メカニズムが量子偽造に対する耐性を備えるようにします。

ロードマップGoogle は、2028 年までに以下のマイルストーン達成を目標としています。また、特に証明書の分野で進行中の標準化の取り組みについても注視しています。Google は、耐量子証明書の標準に積極的に貢献しており、業界全体がこれらの期限に対応できるよう支援することに尽力しています。

ドメイン / ジャーニー	メリット	代表的なサービス
完全性と否認防止（2028 年末）
ソフトウェアサプライチェーンと署名サービスの保護	耐量子ソフトウェア証明書: 信頼できるイメージのみが本番環境で実行されるようにすることで、不正なビルドの改ざんを防止します。	Binary Authorization、Access Approval（AXA）[2026 年]
		Assured OSS[2027 年]
耐量子証明書の発行	標準化された耐量子トラスト: 量子計算による証明書の偽造から、社内外の通信の真正性を保護します。	量子認証 ALTS[2026 年 / 2027 年]
		Private CA（Certificate Authority Service）[2027 年]
		Google Trust Service: Merkle Tree Certificates[2028 年]
		Google Cloud のプロダクトとインフラストラクチャ全体に PQC 証明書をロールアウト[2027 年 / 2028 年]
ID とアクセスの保護	管理された ID: 監査可能な完全性を確保するため、NIST 標準の署名を使用して、攻撃者による認証情報の偽造リスクを排除します。	Cloud IAM[2028 年]
		インフラストラクチャ全体への耐量子認証とアクセスのロールアウト[2027 年 / 2028 年]

ドメイン 3: 基盤と鍵管理

暗号アジリティは、PQC 移行の基盤です。Google は、この分野への継続的な投資により、鍵管理、ライブラリ、インフラストラクチャの変更に関するエンドツーエンドの戦略を推進しています。

基盤となる鍵管理とライブラリ: Cloud KMS と、BoringSSL や Tink などのライブラリを通じて、NIST 承認済みのアルゴリズムを有効にします。

なお、Cloud KMS は、NIST 標準化 PQC アルゴリズム（ML-KEM、ML-DSA、SLH-DSA）の一般提供（GA）を開始しており、現在は耐量子鍵のインポートの有効化を進めています。

ハードウェアベースの暗号サービス: 量子耐性ルートオブトラストを使用した安全な物理基盤。これには、Confidential Computing サービスの一部としての PQC や Cloud Hardware Security Module（HSM）が含まれます。
鍵の主権とパートナーソリューション: Google Workspace クライアントサイド暗号化（CSE）と External Key Manager（EKM）で PQC オーケストレーションを有効にします。パートナーと連携して、PQC オンプレミス鍵プロバイダをサポートします。

ロードマップGoogle は、2028 年までに以下マイルストーン達成を目標としています。

ドメイン / ジャーニー	メリット	代表的なサービス
基盤と鍵管理（2028 年末）
基盤となる鍵管理とライブラリ	標準化された耐量子鍵: NIST 承認済みの構成要素を提供し、アプリケーションの移行を支援します。	KMS の ML-DSA と SLH-DSA、KMS の ML-KEM とハイブリッド[2025 年（完了）]
		耐量子鍵のインポート（BYOK）[2026 年]
ハードウェアベースの暗号サービス	シリコンに根ざしたハードウェア: 耐量子ハードウェアのルートオブトラストをセキュリティのアンカーとします。	Confidential Compute（証明書と vTPM を含む）[2028 年]

		耐量子 Cloud HSM（FIPS 140-3 L3）[2028 年]
鍵の主権とパートナーソリューション	暗号の来歴: 必要な場所で鍵の制御と来歴を提供します。	外部鍵管理[2028 年]
		パートナーのイネーブルメント（鍵プロバイダとソブリンソリューション）[2028 年]

量子安全における責任の共有

セキュリティは長年にわたり、お客様との共同パートナーシップとして取り組んできました。

Google の責任 - クラウドのセキュリティ: Google は、ネットワーク、転送中の暗号化、グローバルフロントエンド、ALTS プロトコルなど、耐量子インフラストラクチャへの移行を管理します。

この責任は、サーバーの PQC 移行をエンドツーエンドで網羅するものであり、基盤となるハードウェアとオペレーティングシステムが量子の脅威から確実に保護されるようにします。Google は、Caliptra v2.1、TPM 2.0 v185、OpenTitan などの耐量子オープンソースのシリコン基盤を通じて、ハードウェアの完全性を維持しています。後者は、初のオープンソースシリコンルートオブトラストであり、すでに耐量子セキュアブートをサポートしています。

2029 年の目標達成に向けて取り組む中、ハードウェアの PQC への移行は、可能な場合は積極的なリプレースと、自然な機器リプレースサイクルの両方を通じて行われます。段階的なアプローチにより安定性を確保していますが、一部の物理コンポーネントのタイムラインは 2029 年以降に延びる可能性があります。

お客様の責任 - クラウドにおけるセキュリティ: 組織は、PQC ハンドシェイクをネゴシエートするためのクライアントサイドソフトウェアの更新や、非対称鍵のライフサイクルの管理など、独自のアプリケーションを管理する必要があります。

さらに、Google Cloud サービス構成を耐量子設定とポリシーで更新する必要があります。

共に進むこれからの道のり

量子への対応に向けた機運を高めるには、即座に実践的な行動を起こす必要があります。まずは、次の 3 つのステップから始めることをおすすめします。

インベントリ: Cloud Asset Inventory や Wiz の暗号化と PQC への対応状況などのソリューションを使用して、暗号リソース（鍵や証明書など）を特定します。組織全体で暗号リソースの使用状況を可視化すると、移行バックログをより正確に定義し、優先順位を付けることができます。
更新: 開発チームとサイト信頼性エンジニアリングチームが、BoringSSL、Chrome、SDK など、PQC アルゴリズムをサポートするソフトウェアを使用していることを確認します。この更新により、エッジで耐量子接続が有効になった際、内部ワークフローがデフォルトでその接続をネゴシエートできるようになります。
検証: Google の耐量子 API とロードバランサを使用して、既存のアプリケーションの動作をテストします。今すぐワークフローを検証することで、主要な本番環境に影響が及ぶ前にアーキテクチャのボトルネックを見つけ出すことができます。

Google Cloud は、この移行の複雑なプロセスを引き受けることで、お客様がイノベーションに注力しながら、規制とコンプライアンスの要件を達成できるよう取り組んでいます。ポスト量子の環境でお客様が主導権を握れるよう、Google は取り組みの進捗状況を共有し始めたばかりです。

Google の PQC アプローチについて詳しくは、ポスト量子暗号（PQC）ハブをご覧ください。

- 規制対象および Sovereign Cloud 担当 VP 兼 GM、Jai Haridas

- Cloud Foundations 担当バイスプレジデント兼ゼネラルマネージャー、Michael Bachman

Best Buy、Workforce Identity 連携で AI ワークロードをスケールし、アクセスを保護

Fri, 07 Aug 2026 02:30:00 +0000

Best Buy のテクノロジーチームは、同社が高度な分析や AI のために Google Cloud の利用を拡大するなかで、スケーリングに関する 2 つの大きな課題に直面しました。それは、Microsoft Entra ID から数千人のバックエンドユーザーを同期する際のリスクの軽減と、管理の煩雑さへの対処です。

この小売業者は、Google Cloud の Workforce Identity 連携を実装することで、両方の問題を解決し、大規模なクラウド拡張への道を開きました。この直接的なアプローチにより、デベロッパーは別の ID ストアを用意することなく、既存の Microsoft 認証情報でクラウドリソースにセキュアにアクセスできるようになりました。これにより、技術部門のリーダーは、アクセスが厳密に制御され、監査可能で、大規模な管理が可能であるという確信を持つことができました。

サービスアカウントを直接連携に置き換える

Best Buy はこれまで、バックエンドユーザーを Entra ID から Google Cloud にコピーするために、複雑な同期パイプラインを維持していました。Google Workspace をデプロイせずに Cloud Identity を使用していたため、より直接的なアプローチが必要でした。以前は、Best Buy における Power BI と BigQuery の連携は、サービスアカウントの認証情報に依存していました。

このパターンは小規模なチームでは機能しますが、チームが拡大するにつれて、いつの間にか負債になっていきます。

サービスアカウントのキーを手動でローテーションするということは、各チームが保持する認証情報を追跡し、すべてのキーが潜在的なセキュリティの脆弱性であることを受け入れることを意味していました。サービスアカウントキーは、Best Buy のセキュリティチームとプラットフォームチームにとって日々の運用の妨げとなっていました。また、データアクセス要件が複雑化するにつれて、技術的負債も蓄積していきました。

数万人のユーザーをサポートするために、Best Buy は ID アーキテクチャをモダナイズしました。チームは、Workforce Identity 連携を採用して、既存の Entra ID の ID を Google Cloud に直接連携しました。

現在、デベロッパーが Power BI を通じて BigQuery にアクセスする際は、既存の Entra ID の ID を使用して本人認証を行います。キーのローテーション、チャットメッセージで認証情報が公開されることの心配、監査ログで誰がアクションを実行したかの推測をする必要はもうありません。

このアーキテクチャは、2 つのコンポーネントが連携して動作します。Entra ID が認証を処理し、Workforce Identity 連携が Entra ID と Google Cloud 間の信頼関係を仲介します。この連携は Google 側ではステートレスです。ユーザーレコードを同期するのではなく、アクセスの時点でトークンを検証します。サービスアカウントキーのレイヤを削除することで、認証情報管理の負担が大幅に軽減されます。

アーキテクチャ

下の図は、Entra ID から Workforce Identity 連携を介して、Best Buy でチームが使用するサービスにどのように ID が流れるかを示しています。以前のアプローチからの主な変更点は、サービスアカウントキーのレイヤが完全に削除されたことです。Entra ID と Google Cloud の間で管理する認証情報はありません。

ID は Entra ID から Workforce Identity 連携を介して、Best Buy のチームが使用するサービスに流れる

実装に関する主な決定事項

このアーキテクチャを実装するにあたり、Best Buy はいくつかの重要な技術的選択を行いました。

Entra ID でプロビジョニングアプリと SSO アプリを分離する: 構成は、Entra ID のプロビジョニングとシングルサインオン（SSO）の設定ガイドに沿っています。Entra ID でプロビジョニングアプリケーションと SSO アプリケーションを分離する必要があります。2 つの異なるエンタープライズアプリとして実行すると、関心の分離がより明確になります。プロビジョニングの変更が SSO 構成に影響を与えることはなく、その逆も同様です。
Automation OU を慎重に配置する: Entra ID プロビジョニングサービスアカウントを別の組織部門（OU）に配置し、その組織部門の SSO を明示的に無効にする必要があります。これにより、ブートストラップの問題（SSO をグローバルに適用すると、プロビジョニングアカウントが認証を行えず、そもそもプロビジョニングの設定ができなくなる）を回避できます。
同期不要とは、Google 側がステートレスであることを理解する: Workforce Identity 連携では、Cloud Identity にユーザーレコードを作成または保持することはありません。アクセスの時点でトークンを検証します。これにより、同期の遅延、古いレコードのクリーンアップ、個別のプロビジョニングパイプラインが不要になるため、Best Buy の目標規模に合ったアーキテクチャが実現します。

デベロッパー向けのセキュアな認証

デベロッパーにとって、この変更は実質的に意識されることはありませんでした。社内の Entra ID 認証情報で一度認証するだけで、Power BI を使用する場合でも、API を直接呼び出す場合でも、BigQuery に自動的にアクセスできます。SSO のエクスペリエンスは、Microsoft ID を使用してアクセスする他のすべてのものと一致します。

セキュリティチームとプラットフォームチームにとって、そのメリットは非常に大きいものです。認証情報管理による攻撃対象領域が消滅します。監査ログには、共有サービスアカウント ID ではなく個々のユーザーが表示されるようになり、手動での鍵のローテーションを待つのではなく、企業の ID ライフサイクルに基づいてアクセスを迅速に取り消すことができます。

現在、デベロッパーの Google Cloud アクセスをサービスアカウントキーで管理しているなら、Workforce Identity 連携への移行を検討する価値は十分にあります。セキュリティ上の大きなメリットが得られ、チームが拡大するにつれて運用が簡素化されます。Best Buy は現在、将来の小売業務を強化するために、このセキュアなアクセスをより幅広い従業員に拡大しています。

Workforce Identity 連携のサポートを拡大

Google Cloud は、あらゆる組織が独自の ID プロバイダを簡単に導入できるように、継続的に取り組んでいます。最近のアップデートにより、Ping Identity ユーザーの設定が簡素化され、オンライン請求先アカウントへのアクセスが拡張されました。

Ping Identity のインテグレーション: Ping Identity を使用している場合は、新しい専用のセットアップガイドに沿って連携を構成できます。このガイドでは、従業員を Google Cloud リソースにセキュアに接続するための手順を説明します。
オンライン請求サポート: Google Cloud は、オンライン請求先アカウントをお持ちのお客様をサポートします。Workforce Identity 連携を使用すると、企業請求契約を結ぶことなく、セキュアで同期不要のアクセスが可能になります。

使ってみる

Google Cloud は、クラウド導入の障壁を取り除き、組織が環境をより簡単に保護できるように取り組んでいます。これらの新機能を試し、組織の ID プロバイダを接続するには、Workforce Identity 連携で ID を直接連携させる方法の詳細を確認し、サポートされている Google Cloud サービスをご覧ください。

- Best Buy、クラウドエンジニアリング担当シニアマネージャー、Kishor Patil 氏

- Google Cloud Security、シニアプロダクトマネージャー、Stephen Cakebread

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

GKE における AI サプライチェーンの保護: 自動 AI BOM 対応 k8s-aibom のご紹介

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

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

セキュリティチームは、シャドー AI にどのように対応すべきでしょうか？デベロッパーが正式に登録せずにデプロイしたワークロードは、多くの場合、従来のセキュリティスキャナを回避できます。特権 DaemonSet、カーネルレベルのアクセス、Pod 仕様の手動編集を求めることで、開発を遅らせて安定性を損なうことに組織が消極的であるためです。

この行き詰まりを打開するため、Google はこのたび k8s-aibom をオープンソース化いたしました。この特権なしの軽量 Kubernetes コントローラは、クラスタ API とコンテナ環境を継続的にモニタリングして、実行中の AI ランタイム（vLLM や Triton など）を自動的に検出し、標準的な CycloneDX Machine Learning Bill of Materials（ML-BOM）を生成します。

k8s-aibom は、ワークロードが正式に登録されているかどうかに関係なく、ランタイム実行から直接、監査に適した可視性を自動的に確保し、デベロッパーに統合の負担をかけることなく AI プロジェクトをパイロットから本番環境に安全に移行できるようチームを支援します。

負担のないアーキテクチャ

k8s-aibom は、総合的な可視性に関する CISO の要件と、クラスタの安定性に関する SRE の要件の両方を尊重するようにゼロから設計されています。k8s-aibom-system Namespace に、特権なしの単一の Deployment としてデプロイされます。デベロッパー側の負担はゼロです。サイドカー、eBPF カーネルモジュール、特権 DaemonSet は不要で、既存のデベロッパー Pod 仕様を変更する必要もありません。

k8s-aibom は AI ワークロードを監視し、BOM を生成します。

検出パイプラインは、次の 4 つの明確な段階を経て実行されます。

クラスタワークロードのスクレイピング: コントローラは、クラスタ全体で KServe リソース、Deployment、StatefulSet、DaemonSet、Job を継続的にモニタリングします。
AI スタックの特定: 高度なパターンマッチングにより、コンテナイメージ、環境変数、コマンドライン引数を検査して、サービングランタイム（vLLM、Triton Inference Server、TGI、Ollama）、自律型エージェントフレームワーク（LangChain、AutoGen、CrewAI）、ベクトルデータベースと RAG ストア（Milvus、Qdrant、pgvector）、分散トレーニングジョブと評価ハーネスを検出します。
標準的なマニフェストの生成: コントローラは、検出されたアーティファクトを正式な OWASP CycloneDX 1.6 Machine Learning Bill of Materials（ML-BOM）ドキュメントにコンパイルします。
シンクへのエクスポート: コントローラは、生成された ML-BOM をクラスタ内の AIBOM カスタムリソース（CR）のカスタムリソースステータス（status.bomDocument）に直接アタッチし、Google Cloud Storage バケットや外部 Webhook エンドポイントなどのオプションの外部シンクにルーティングします。

アプリケーションチームが、Pod 仕様の変更、サイドカーコンテナの挿入、継続的インテグレーションと継続的デリバリー（CI / CD）のパイプラインの変更を行う必要はありません。さらに、k8s-aibom は Kubernetes クラスタの状態を純粋な関数入力として扱うため、同一のクラスタ入力からは、バイト単位で同一の ML-BOM ドキュメントが生成されます。この決定論的プロパティを持つ k8s-aibom は、GitOps ワークフローに最適です。これにより、サイト信頼性エンジニア（SRE）は、AI の依存関係がドリフトしたときに正確な差分を実行し、精密な変更検出アラートをトリガーできます。

既存の AIBOM ツールでカバーできない領域

多くの AI BOM ソリューションはビルド時スキャナを備えており、保存されているアーティファクトから BOM を生成します。これらのツールを使用すると、デプロイする予定だったコードを追跡できます。

商用 AI セキュリティプラットフォームは、クラウドネイティブなポスチャー管理によって可視化できる範囲を拡大しますが、通常はベンダー固有のデータモデルを中心に形成された外部スキャンによってこれを実現します。こうしたツールで、コンプライアンスレビュー担当者、セキュリティ運用（SecOps）チーム、プラットフォームエンジニアが、現在何が実行されているか、どこに接続しているか、アサーションを検証するにはどうすればよいかを把握できることはほとんどありません。

Google は k8s-aibom を、このギャップを埋めるための専用ツールとして構築しました。k8s-aibom は、アーティファクトのスキャンではなく、ライブクラスタの観測から BOM を生成し、ベンダー独自の形式ではなく、より広範な OWASP および Open Source Security Foundation（OpenSSF）サプライチェーンエコシステムと統合する標準準拠の CycloneDX 1.6 ML-BOM を出力します。また、準拠する Kubernetes クラスタで特権なしのコントローラとして実行されるため、既存のビルド時およびポスチャー管理ツールの代わりとなるのではなく、これらを補完するものとなります。

信頼度モデル: 意図と推論の分離

コンプライアンス監査担当者や SecOps エンジニアにとって、未加工のテレメトリーがノイズになることがよくあります。標準的なモニタリングツールは、コンテナが実行中であることを示しますが、AI モデルがプラットフォームエンジニアによって明示的に構成されたのか、実行時に自律スクリプトによって動的に抽出されたのかを証明することはできません。k8s-aibom は、その決定論的な信頼度モデルによってこの曖昧さを解消し、検出されたアセットを明確な階層に分類します。

宣言: ワークロード構成で、顧客またはデベロッパーによって明示的に定義された（例: --model meta-llama/Llama-2-7b など、明示的に渡されたコンテナ引数）。「宣言」の信頼度検出は、人間の明確な意図を表します。
推論: コンテナイメージ、環境変数、実行プロファイルの詳細な検査を通じて、コントローラのパターンマッチングエンジンによって自律的に導出された（例: ^vllm/.* コンテナ署名の特定）。
未解決: アクティブな AI の存在が検出されたが、正確なモデルパラメータ、重み、バージョンを決定論的に確立できないワークロードに適用される。「未解決」の信頼度検出の場合、対象を絞ったセキュリティレビュー向けにワークロードに即座にフラグが付けられます。

この構造化された分類により、コンプライアンスレビュー担当者は、明示的なエンジニアリングの意図と機械の推論を即座に分離し、監査中に揺るぎない信頼の連鎖を確立できます。

不変性と最小権限: 監査に適したセキュリティモデルの構築

侵害されたノードや権限が昇格された管理者によってログや指標が変更、削除、改ざんされる可能性があるため、監査担当者は標準的なオブザーバビリティテレメトリーに対して依然として強い懐疑心を抱いています。k8s-aibom は、厳格な最小権限の分離とデータの不変性をベースにした、監査に適した証拠トレイルを確立します。

このコントローラは、最小限の Identity and Access Management（IAM）Workload Identity にバインドされた専用の Kubernetes サービスアカウントの下で動作します。BOM レコードを外部ストレージシンクに書き込む権限を持つ唯一の ID として機能し、roles/storage.objectCreator 権限のみを必要とします。

Google Cloud Storage の外部シンクの実装では、最も厳格な監査基準と証拠基準を満たすために、オブジェクト作成時に DoesNotExist 事前条件が適用されます。ML-BOM が Cloud Storage バケットに書き込まれると、オブジェクトは暗号化され、変更できなくなります。

侵害されたクラスタアクターや不正なワークロードによって、サイレントに上書き、変更、または遡及的に改ざんされることはありません。SecOps チームは、規制当局に提出された過去の監査ログが、クラスタ実行の変更不可能な記録であることを絶対的に保証できます。

ガバナンス体制の整備の促進: グローバルな規制フレームワークへのマッピング

k8s-aibom は、標準化された CycloneDX 1.6 ML-BOM の生成を自動化することで、低レベルの Kubernetes ランタイム状態と高レベルのガバナンスフレームワークのギャップを直接的に埋めます。また、主要な国際基準に不可欠な基礎的実証データを提供することで、停滞していた GKE AI のデプロイの道を切り拓きます。

EU AI 規則: 組織が第 12 条（継続的なトレーサビリティのための自動ロギングと記録保持）と第 50 条（AI システムの透明性義務）に準拠できるように設計されています。このツールは、サービングランタイムとエージェントスタックを自動的にカタログ化することで、コンプライアンス監査中に必要となる可能性のある技術的証拠の収集を簡素化します。
NIST AI リスク管理フレームワーク（AI RMF）: ガバナンス、マッピング、測定、管理の各機能を実現する、継続的かつ実証的なアセットの可視性がもたらされ、コンプライアンスワークフローを、純粋な手動チェックから、より自動化されたアセットインベントリトラッキングへと移行できます。
ISO/IEC 42001: AI マネジメントシステムのアセットの検出と追跡に関するコンプライアンスの取り組みをサポートし、インベントリの検証における手動のスプレッドシート入力や定期的なスナップショット監査への依存度を低下させます。

ご利用にあたって

k8s-aibom は、CISO、ガバナンス、リスク、コンプライアンスの各チーム、SecOps チーム、プラットフォームエンジニア、デベロッパーに影響を与えるシャドー AI の多面的な問題の軽減に役立つ数少ない技術ソリューションの一つです。

このコントローラの詳細とカスタムリソース定義について、またオープンソースの k8s-aibom プロジェクトにご協力いただける場合は、k8s-aibom GitHub リポジトリをご覧ください。

- グループプロダクトマネージャー、Glen Messenger

重要な第三者として英国金融セクターのレジリエンス向上に貢献

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

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

Google Cloud は、金融エコシステムにおける自らの役割を非常に重く受け止めています。私たちは、責任あるイノベーションを推進し、維持するためには、オペレーショナルレジリエンスが不可欠であると確信しています。

この度 Google は、英国のお客様に直接関わる、金融セクターに対する継続的な取り組みにおいて重要な節目を迎えました。7 月 10 日、英国財務省は CTP 制度に基づき、Google Cloud EMEA を英国金融セクターにおける重要な第三者（Critical Third Party: CTP）として指定しました。

この指定は、Google Cloud のサービスを利用している英国企業の数や種類、およびそれらのユースケースの重要性を考慮したものです。Google Cloud は、当社のサービスが英国の金融システムに及ぼすシステム的な影響に関する HMT（英国財務省）の判断を真摯に受け止めており、英国金融システムの安定性と信頼性を確保するうえで、自らの責務を果たすことに尽力しています。

金融セクター全体のレジリエンスを強化

Google Cloud EMEA は、CTP として、イングランド銀行、健全性規制機構（PRA）、金融行動監視機構（FCA）による直接的な監督を受けることになります。これらの当局は、総称して英国金融規制当局と呼ばれています。

英国金融規制当局は、CTP を監督するにあたり、金融セクター全体のオペレーショナルレジリエンスの向上を目指します。Google Cloud は、この目標を全面的にサポートします。

より深い連携という新たな段階に入るにあたり、Google Cloud は引き続き英国金融規制当局と建設的な対話を進めてまいります。また、この継続的な対話が、英国金融セクターに具体的なメリットをもたらすものと確信しております。

カスタマーサクセスの実現

Google Cloud は、効果的な監督に向けた当社のコミットメントと並行して、オペレーショナルレジリエンス、アウトソーシング、サードパーティのリスク管理といった英国企業に求められる要件への対応について、お客様を支援することに引き続き尽力してまいります。

SS1/21 ホワイトペーパーでは、PRA 監督声明 1/21 に基づくオペレーショナルレジリエンスの義務を Google Cloud がどのように支援できるかについて詳しく説明しています。
SS2/21 マッピングでは、PRA 監督声明 2/21 に基づく英国企業向けのアウトソーシングとサードパーティのリスク管理の要件に対し、Google Cloud の契約がどのように対応しているかを説明しています。

CTP 制度はこれらの要件に代わるものではありませんが、それらを補完するように設計されています。Google Cloud は、その役割を十分に果たせると確信しています。

今後の対応

CTP 制度の下で、英国の金融規制当局と協力していくことを楽しみにしています。Google Cloud は、お客様とその規制当局に対する現在のアプローチと同様の姿勢で、継続的な透明性と保証への取り組みを堅持してまいります。

この新しい時代が始まっても、私たちの中核的な目標は変わりません。それは、Google Cloud がデジタルトランスフォーメーションにおいて最もセキュアで、スケーラブルかつレジリエンスに優れたプラットフォームであることを保証することです。

- Google Cloud、リスクおよびコンプライアンス担当バイスプレジデント、Jeanette Manfra

- Google Cloud ヨーロッパ、中東、アフリカ担当プレジデント、Tara Brady

CodeMender プレビュー版の提供開始：ソフトウェアの脆弱性を検出および修正

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

敵対的な AI 活用による脅威がコードへの攻撃を加速させるなか、セキュリティチームには、コードの修復を自動化し、 AI に対して AI で対抗するマシンスピードの防御策でこれらに立ち向かう必要があります。

CodeMender は、Google のマネージドコードセキュリティエージェントです。本日より、コードスキャンおよび修復機能をプレビュー版としてお客様に直接提供を開始します。

CodeMender は、Gemini Enterprise Agent Platform を通じて、一般提供中のモデルを利用できるほか、Google AI Threat Defense のコアコンポーネントとして導入することもできます。

また、CodeMender はマルチモデルアプローチに対応しており、コスト、速度、ディープスキャン性能の最適化に合わせて適切なモデルを選択できます。今年の後半には、サードパーティのフロンティアモデルの選択肢も追加する予定です。

Gemini Enterprise Agent Platform における CodeMender の概要動画をご覧ください。

CodeMender は、受動的なスキャンから自動化されたコード修復への移行を支援し、ゼロデイリスクを低減します。開発速度を損なうことなく、既存のコードセキュリティの問題を次のように検証して修復します。

最適なモデルのデプロイ：コスト、速度、詳細なスキャン、コーディングのパフォーマンスに合わせて、複数のモデルから最適なものを選択できます。
マシンスケールでの自動修復：開発者がプロセスを把握できる状態を維持しながら、手動での検証やパッチ適用による修復のボトルネックを解消できます。
悪用可能性に基づく修復の優先順位付け：概念実証（ PoC ）エクスプロイトを実行してシミュレーションを行い、コード内の脆弱性が悪用可能かどうかを検証した上で、重大な問題の修正にリソースを優先的に割り当てることができます。

AI による脆弱性の検出と修正

Google DeepMind の先駆的な AI 研究から生まれた CodeMender は、ボトルネックとなっていた手作業による脆弱性管理を、自律的かつ高速に処理するシステムへと変換します。開発者やセキュリティ担当者は、ソフトウェアの欠陥を自動的にスキャンし、実行可能なエクスプロイトで検証した上で、テスト済みの修正コードによって修復できます。

「Salesforce において、信頼は最優先の価値であり、お客様のデータを保護することは、リスクの検出、検証、軽減に関する基準を常に高め続けることを意味します。 CodeMender は、検証済みの脆弱性をテスト済みの修正へ迅速につなげることで、セキュリティライフサイクルの重要な部分に AI を導入します。AI が脅威環境を変化させるなか、このような機能はレジリエンスを強化し、お客様が安心してイノベーションを継続できるよう支援します。」

— Iain Mulholland 氏（ Salesforce CISO ）

「CodeMender は、他の AI 対応ツールが完全に見落としていた重大な脆弱性を的確に特定しました。単に理論上の欠陥を発見するだけでなく、直接的なリスクを証明し、コアビジネスロジックを妨げることなく環境を保護する、検証済みの的確な修正を提供します。」

— Scott Ponte 氏（ Robinhood セキュリティオペレーション責任者）

「CodeMender は高速かつ包括的であり、検出から修正までのプロセスを完結させるという意欲的なアプローチを備えています。これにより、チームは開発速度を落とすことなくソフトウェアサプライチェーンの安全性を確保できます。」

— Ashwin Kannan 氏（ Palo Alto Networks CTO オフィスプリンシパル AI エンジニア）

CodeMender エージェントの仕組み

CodeMender を支える実行基盤には、最新のエージェントスキル、セキュリティツール、システムプロンプトを含む Google DeepMind の研究成果を継続的に反映しています。

セキュアバイデザインな Agent Platform 上で動作する CodeMender は、VPC 経由の安全なトラフィックルーティング、データの分離と暗号化、ソースコードデータを保持しないゼロリテンションポリシーなど、エンタープライズグレードの組み込みガバナンスとセキュリティガードレールによって保護されています。

エージェントとして、既存の継続的インテグレーション / 継続的デリバリー（ CI/CD ）ワークフローに組み込むことも、軽量なコマンドラインインターフェース（ CLI ）クライアントを使用してローカルの開発環境で直接実行できます。

また、ユーザーが管理するサンドボックス内でコードをスキャンして分析するように CodeMender を設定することもできます。エージェントはコードリポジトリに接続し、VS Code や Antigravity などの開発者ツールと連携して、ファーストパーティ、オープンソース、サードパーティのソフトウェアを安全に分析します。

スキャン：柔軟なモデルスキャンで隠れた脆弱性を検出

CodeMender は、主要な脆弱性クラスをスキャンし、ソフトウェアリポジトリやアプリケーション独自のコンテキスト、目的、機能を理解します。

スキャン：新たに発見された脆弱性を重大度とタイプ別に分類します。

セキュリティコンテキストを備えた CodeMender のハーネスは、静的解析やモデルのみのスキャンでは見落としてしまう複雑な脆弱性の発見に役立ちます。メモリ破損、インジェクション、Web セキュリティ上の問題、暗号の欠陥、安全でないデータ処理など、検出が困難な脆弱性を探索します。CodeMender は、 C/C++、Go、Java、Python、Ruby、Rust、TypeScript などの一般的なプログラミング言語をサポートしています。

検証：エクスプロイトのシミュレーションと検証によりノイズを削減

CodeMender は、問題を修正する前に脆弱性が現実のリスクをもたらすことを証明することで、アラート疲れや誤検知の削減に貢献します。このエージェントは、顧客が管理する隔離された顧客管理下のサンドボックス内で自身が構築、実行するエクスプロイトコードを用いて攻撃をシミュレートし、単なる静的なコードパターン分析を超えた検証を行います。

検証：検証プランを作成し、ユーザーのサンドボックス環境内でエクスプロイトを構築およびテストします。

エージェントはこの概念実証（ PoC ）エクスプロイトを使用して、セキュリティ上の欠陥が現実のリスクをもたらすことを検証します。この重要な検証フェーズにより、セキュリティ担当者や開発者は誤検知を排除し、検証済みのリスクに優先的に対応できるようになります。

修復：コード修正の自動生成とテスト

リスクのあるセキュリティ上の欠陥を特定することは、対策の半分にすぎません。脆弱性が検証されると、CodeMender は問題を解決するための安全なパッチを自動生成します。修正内容はコードの差分（ diff ）として開発者ツールに直接提供するため、既存の開発ワークフローに組み込むことができます。

修復：開発者のレビューと承認のために、コードの差分（ diff ）を含むコード修正を生成してテストします。

さらに、CodeMender は、LLM-as-a-judge を使用して既存のアプリケーション機能に影響を与えないことを確認し、修正の精度をさらに高めます。また、独自のコーディング規約やスタイルのコンテキストを提供することで、それに沿ったコードを CodeMender に生成させることも可能です。コードがリポジトリにコミットされる前に、開発者が CodeMender のパッチを手動でレビューおよび承認するため、常に開発者が管理権限を維持します。

AI Threat Defense における CodeMender

AI Threat Defense の一部として活用する場合、Wiz はエージェント型のアプリケーションセキュリティをオーケストレートし、アプリケーションを分析して調査の優先順位付けを行います。Wiz は CodeMender を呼び出してコードをスキャンし（近日提供予定）、デプロイコンテキストを用いて Wiz Security Graph 内の検出結果を補強します。さらに、Wiz Red Agent を起動して AI ペネトレーションテストを行い、悪用可能性を検証することで、チームが特に高リスクな脆弱性に集中できるようにします。

AI Threat Defense システム内における Wiz と CodeMender の連動アーキテクチャ図。コードスキャンからペネトレーションテストまでのフローが示されている

Wiz は、AI Threat Defense における修復の管理とスケーリングを行うコマンドセンターとして機能します。Wiz Green Agent は、Security Graph から得られるアプリケーションのコンテキストで強化された高精度なパッチの生成とテストを CodeMender に指示し、このライフサイクルを制御します。このワークフローにより、チームはこれまでにないスピードと精度で複雑な脆弱性を解消できるようになります。

CodeMender を使い始めるには

CodeMender は、Google のマルチモデルアプローチに沿って、コスト、速度、詳細なスキャンパフォーマンスの最適化を支援します。

Agent Platform を通じて一般提供している Google の Gemini モデルで CodeMender を利用できるほか、 AI Threat Defense のコアコンポーネントとして導入することも可能です。

Gemini 3.5 Flash Cyber を搭載した CodeMender は、一部の政府機関や特定の組織および企業向けに提供します。アクセス対象は順次拡大していく予定です。

CodeMender は、継続的かつ自律的で自己修復を行うエージェント型のソフトウェア開発ライフサイクルに向けた重要な一歩であり、本番環境へデプロイする前に、コードの安全性確保、検証、パッチ適用を自律的に実行する未来を拓くものです。

CodeMender の詳細およびドキュメントの確認については、こちらをご覧ください。

Gemini Startup Forum に参加する 33 社のサイバーセキュリティスタートアップをご紹介

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

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

スタートアップは、世界で最も複雑な課題に取り組む最前線に立っています。特にサイバーセキュリティでは、常に新しいアイデアと適応性が求められます。これらの企業は、AI を強力なツールとして活用し、その影響力を拡大しています。

Google は、次世代の AI ネイティブなサイバーセキュリティスタートアップを支援することが、世界全体にプラスの影響をもたらすと考えています。このたび、主力の Google for Startups プログラムである Gemini Startup Forum: Cybersecurity で最初の 33 社の先駆的なスタートアップが選出されました。この限定フォーラムは、重要な領域に対処し、サイバーセキュリティにおける AI 統合について深い対話を促進することを目的としています。

すべてのスタートアップは、Google DeepMind、Google Cloud、Wiz の AI およびサイバーセキュリティのスペシャリストとともにロードマップに取り組むことができます。今年のコホート（選出されたスタートアップ）は、自律型エージェントの保護からポスト量子暗号まで、6 つの専門的な重点分野に分類されます。

AI エージェントのセキュリティとガバナンス

Capsule Security（イスラエル）: 自律型 AI エージェントのランタイム保護と動作モニタリングを行います。このプラットフォームは、エージェントのアクティビティ、API 呼び出し、ツールの使用状況をリアルタイムで追跡し、ソフトウェアサービス（SaaS）とエンドポイントエージェント全体で不正なアクションとデータ引き出しを防止します。
Evoke Security（米国）: AI エージェント向けに設計されたエンドポイント検出対応（EDR）プラットフォームとして機能します。エンドポイントセンサーをデプロイして、危険なエージェント構成をスキャンし、ランタイムの動作をモニタリングして、不正なスキルの実行をブロックします。
Manifold Security（米国）: グラフ分析とランタイムモニタリングを使用して、AI エージェントのエージェントレス検出 / 対応を行います。このプラットフォームは、オープンテレメトリーと API フックを活用することで、ローカルマシンにソフトウェアをインストールすることなく、エージェントの動作と接続をマッピングして異常を特定します。
Mirror Security（アイルランド）: 完全準同型暗号化を使用して、AI ワークロードで使用中のデータを保護することを専門としています。このプラットフォームにより、企業は暗号化されたデータを復号せずに、そのデータに対して直接、モデル推論、データベース検索、エージェント通信を実行できます。
Onyx Security（イスラエル）: エンタープライズ環境全体で自律型 AI エージェントを検出、管理、モニタリングする AI コントロールプレーンを提供しています。このプラットフォームは、エージェントのポスチャーを分析し、セッショントークンストリームを追跡し、モデルメッシュを使用してコンテキストに応じたコンプライアンスポリシーを適用します。
Refractal（英国）: エンタープライズ AI エージェントをモニタリングおよび管理するための、ランタイムセキュリティとガバナンス、リスク、コンプライアンス（GRC）のインフラストラクチャを構築しています。エージェントのアクションをインターセプトし、組織のポリシーと欧州の規制に照らして評価し、暗号化された監査ログを生成します。
Unbound Security（米国）: 開発者向けのコーディングエージェントの可視性とガバナンスを提供するエージェントアクセスセキュリティブローカー（AASB）として機能します。エンドポイントフックをデプロイしてターミナルコマンドをモニタリングし、ユーザー ID とグループ権限に基づいてエージェントのアクションを制限します。
XOR（米国）: AI モデルが自律的にセキュリティの欠陥を見つけて修正できるよう、強化学習のトレーニングデータと環境を生成します。同社は、開発者が安全なコーディングエージェントをトレーニングするために使用する、検証済みのタスクの軌跡とベンチマークを提供しています。

アプリケーションのセキュリティと脆弱性管理

Aisy（英国）: 攻撃者の視点からエンタープライズ環境をモデル化し、脆弱性修復の優先順位を付けます。このプラットフォームは、外部の攻撃対象領域をマッピングし、関連するアセットをビジネス中心の脅威モデルにグループ化して、重要なエクスプロイトチェーンを特定します。
Alt Security（イスラエル）: 自律型 AI エージェントを使用してセキュリティテストを実行するエージェント型ペネトレーションテストプラットフォームを開発しています。このシステムは、偵察を自動化し、検出した脆弱性を連鎖させて重大なビジネスリスクを特定し、サンドボックス環境で攻撃手法を検証します。
Arcjet（米国）: SDK を介して開発者のコードベース内でネイティブに実行されるアプリケーションセキュリティを提供します。このプラットフォームは、コードベースで直接、bot 検出、レート制限、プロンプトインジェクションを処理し、低レイテンシの意思決定ループを維持します。
Pixee（米国）: スキャナの結果を検証済みの pull リクエストに変換することで、脆弱性のトリアージとコードの修復を自動化します。このプラットフォームは、コンテキストグラフと決定論的なハーネスを使用して、開発者の継続的インテグレーション（CI）パイプラインに合格する、コードベースと互換性のある修正を生成します。

クラウド、ネットワーク、インフラストラクチャのセキュリティ

CloudFence（米国）: 見えない頭上のドローンのように、企業のクラウドネットワークをモニタリングします。システムが相互に通信する通常のパターンを学習し、システムが未知の場所との通信を開始すると、すぐに管理者にアラートを送信します。
CyberSeQ（英国）: ソフトウェアコードとデジタルパイプラインをスキャンして、暗号化が古くなっていないか確認します。組織が最新の量子耐性セキュリティキーへの移行を計画するのに役立ちます。
Huskeys（イスラエル）: 企業のデジタルファイアウォールのスマートチューナーとして機能します。トラフィックフィルタをリアルタイムで自動的に最適化して適応させることで、誤警報を減らし、正規の顧客がブロックされることなくウェブサイトにアクセスできるようにします。
Native（イスラエル）: Google Cloud、AWS、Azure、Oracle 全体で組み込みのネイティブプロバイダ管理機能を管理するマルチクラウドセキュリティコントロールプレーンとして機能します。このプラットフォームでは、シミュレーションエンジンを使用して、セキュリティポリシーの変更が運用に与える影響をデプロイ前にプレビューできます。
Prowler（米国）: マルチクラウド環境全体でクラウドセキュリティポスチャー管理とコンプライアンスチェックを自動化します。このオープンソースプラットフォームは、コミュニティ主導のセキュリティ管理のデータベースを使用して、構成ミスを特定して修復します。
QIZ Security（イスラエル）: 一元化されたダッシュボードを通じて、企業の暗号アセットとコンプライアンスポスチャーを管理します。このプラットフォームは、証明書、データベース、ソースコードをナレッジグラフにマッピングして、組織がポスト量子暗号に移行できるように支援します。
Tracebit（英国）: クラウドネイティブなデコイ（カナリア）を使用して、インフラストラクチャへの侵入や不正アクセスを検出します。このプラットフォームは、Infrastructure as Code を介してこれらのデコイリソースを大規模にデプロイし、攻撃者が動いた瞬間にアラートをトリガーします。

エンドポイントセキュリティとデータ保護

Bold Security（米国）: 企業のデバイスをデータの引き出しやインサイダー脅威から保護する、ユーザー空間のエンドポイントセキュリティエージェントを提供しています。エージェントはデバイス上でローカル分類モデルを実行するため、クラウドのレイテンシなしでポリシーの適用とデータ損失防止が可能になります。
Glow（イスラエル）: エンドポイント、ソフトウェア、AI エージェントのモニタリングを一つのワークスペース保護レイヤに統合します。プラットフォームは、連携する AI エージェントのチームを使用して、組織全体のソフトウェアフットプリントをマッピングし、不正なブラウザ拡張機能やプラグインをブロックします。
Jazz（米国）: 静的なパターンルールに依存するのではなく、ユーザーの意図とビジネスコンテキストを分析することで、データ損失防止（DLP）をモダナイズします。軽量なエンドポイントエージェントとインテリジェントな調査ツールを使用して、データフローアラートを自動的にトリアージして解決します。
ORION Security（米国）: エンドポイント、ブラウザ、SaaS ツール全体でデータリネージを追跡する、インジケーター主導のデータ損失防止プラットフォームをデプロイします。グラフデータベースでファイル移動をマッピングすることで、手動ポリシーを必要とせずにデータ引き出しのリスクを特定します。
MokN（フランス）: プロアクティブな ID 復元プラットフォームで認証情報の盗難に対処します。独自のテクノロジーにより、極めてリアルなデコイアクセスポイントを使用して攻撃者を欺き、盗んだ認証情報を明らかにさせることで、形勢を逆転させます。これにより、侵害された認証情報が悪用される前に脅威を無効化できます。

SOC の自動化と攻撃型セキュリティ

COGNNA（サウジアラビア）: セキュリティ通知を分析し、脅威対応ワークフローを自動化するエージェント型セキュリティオペレーションセンター（SOC）プラットフォームを運用しています。このプラットフォームは、既存のエンドポイントツールとセキュリティ情報およびイベント管理（SIEM）ツールからテレメトリーを取り込み、AI エージェントを使用してインシデントを調査し、アラートのノイズを低減します。
Latent Defense（米国）: 複雑なシステムアーキテクチャを密度の高い多次元グラフとして表現する、サイバーセキュリティの基礎となる世界モデルを構築します。このプラットフォームは、これらのグラフ表現を使用して、悪用可能な攻撃経路を特定し、自動化されたレッドチームエージェントでテストします。
Mate Security（イスラエル）: AI ネイティブなセキュリティ運用プラットフォームを使用して、セキュリティ通知を大規模に調査します。既存の SIEM およびセキュリティオーケストレーション、自動化、対応（SOAR）ツールと統合して、アセットの関係をマッピングし、受信アラートを自動的にトリアージして、偽陽性率を最小限に抑えます。
Nrdsnipe（スウェーデン）: 内部ネットワークのペネトレーションテストを自動化する、AI を活用したセキュリティテストプラットフォーム、Hedgehog を構築しています。顧客のネットワークに直接デプロイされ、プランナーエージェントとターミナルエージェントを使用してアセットをマッピングし、露出ベースのナレッジグラフを構築します。
RIFFSEC（ポーランド）: 中央ヨーロッパ市場向けにカスタマイズされた、早期に警告を発する脅威インテリジェンスおよび攻撃対象領域管理プラットフォームを提供しています。ダークウェブ、Telegram チャンネル、コードリポジトリをモニタリングして、漏洩したデータや認証情報、フィッシングキャンペーンを特定します。
TandemTrace（スペイン）: 未加工のテレメトリーを分析してアラートを調査し、脅威をハンティングする自律型 AI エージェントでセキュリティ運用チームを強化します。このプラットフォームは、既存のデータレイクと SIEM API に直接接続して、セキュリティインシデントに関する人間が読めるコンテキストを構築します。

セキュリティインフラストラクチャと専門サービス

Netsec（フランス）: コラボレーションチャネル内で直接提供されるオールインワンプラットフォームを通じて、中規模組織の IT とサイバーセキュリティのライフサイクル全体を管理します。ユーザーのオンボーディング、デバイス管理、SaaS ポスチャーの修復を一つのコントロールプレーンから自動化します。
Revelum（米国）: ディープフェイクを利用した大規模な不正行為やなりすましのキャンペーンを検出して排除します。このプラットフォームは、ビジョンモデルと分類エンジンを使用して、ソーシャルメディア広告の分析、生体認証による本人確認、ドメインの削除の自動化を行います。
Synqly（米国）: IT ツールとサイバーセキュリティツールの統合を簡素化する、統合された接続プラットフォームと API 管理コントロールプレーンを提供しています。データスキーマを正規化し、双方向のデータ共有を促進する決定論的なミドルウェアレイヤとして機能します。

上述のスタートアップは、グローバルなスペシャリストと連携しているため、より安全で復元力のあるデジタルインフラストラクチャを構築するのに有利な立場にあります。Gemini Startup Forum は、Google for Startups Gemini キットの特典です。このキットには、スタートアップが AI を活用してビジネスを拡大できるよう、API、ツール、トレーニング、技術リソースが満載されています。キットの詳細については、こちらをご覧ください。

脅威の状況は常に変化しています。この課題に対処するため、Google は Google for Startups への取り組みを継続します。過去 4 年間に、Authologic、BforeAI、Build38、Cerby、Crowdsec、Risk Ledger など、50 社以上のサイバーセキュリティ創業者を支援してきました。

今年のコホートは、業界が境界防御から自律型 AI エージェントのセキュリティへと移行していることを反映しており、エンタープライズガバナンスと自己管理型 AI の安全なデプロイを重視しています。今後、これらのテクノロジーの統合は、次世代のプロアクティブなデジタル防御を定義するのに役立ちます。

- Google Threat Intelligence 担当バイスプレジデント、Sandra Joyce

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Architecture for Nexus SDV.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Nexus SDV の利用を始める

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 主権認証の改善

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

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

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

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

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

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

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

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

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

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

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

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

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

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

今後の展望: Made with Europe

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

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

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

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