情報源： Elastic on Defence Cyber Marvel 2026: A Technical overview from the Exercise Floor Elastic Security Labs に掲載された DCM26 の記事をもとに、本ブログでは構成や設計上のポイントを整理します。 サイオステクノロジー株式会社 Saman イギリス国防省主催の Defence Cyber Marvel 2026（DCM26） は、伝統的なITネットワーク、企業環境、複雑な産業制御システムを対象にした、英国最大級の軍事サイバー演習です。形式としては force-on-force 型 が採用されており、防御を担う Blue Team が担当システムを守り、攻撃を担う Red Team がさまざまな手法で侵入や妨害を試みます。さらに、その攻防を White Team が監視し、システム可用性、攻撃検知、インシデント報告、復旧状況などをもとに評価します。つまり DCM26 は、単なる製品検証やデモではなく、攻撃・防御・評価が同時に進む実戦型の演習として設計されていました。 DCM26には 29カ国・70組織から 2,500人以上が参加し、5,000を超える仮想システムが稼働しました。演習は 2026年2月に5日間にわたって行われ、シンガポールの Exercise Control を中心に運営されました。Blue Team は地理的に分散した状態で参加し、英国内や海外の拠点から VPN 経由で演習環境に接続していました。この前提だけでも、参加者全員に同じ環境を安全に配布し、チームごとに厳密に分離しながら、攻撃と防御を同時に成立させる必要があったことがわかります。 こうした前提の中で、Elastic は DCM26 全体を役割ごとに異なる形で支えていました。特に中心となったのは Blue Team 向けの単一マルチテナント基盤ですが、それに加えて Red Team 向けには C2 可視化用の専用デプロイメント、NSOC 向けには演習全体と AI 利用監査を担う専用デプロイメントも用意されていました。つまり Elastic は、攻撃・防御・運営の各レイヤーをそれぞれに合った構成で支えていたのです。 目次 Blue Team基盤の設計 データ分離の仕組み 事前検証と負荷テスト 演習向けの防御設定 Red TeamとNSOCの基盤 AI活用のガバナンス Attack Discoveryの役割 3つのAI活用レイヤー 感情分析という試み まとめ 用語集 Blue Team基盤の設計 Blue Team 向けの中心構成は、単一の Elastic Cloud デプロイメント をベースにしたマルチテナント設計でした。記事では、40の defending Blue Teams を支える単一デプロイメントが中核として紹介され、チームごとの分離には Kibana Spaces と datastream namespaces が使われていたと説明されています。 この設計の価値は、規模が大きいほどはっきりします。各チームに個別クラスタを割り当てれば分離はしやすい一方で、構築・更新・監視の負荷が急増します。逆に、単一デプロイメントに集約しつつ Spaces と権限制御でチーム単位に分ければ、標準化しやすく、全体運用も現実的になります。DCM26は、このマルチテナント方式を大規模演習に適用した実例でした。 データ分離の仕組み この構成では、見た目のワークスペースを分けるだけでなく、データの流れ自体もチーム単位で整理されていました。各チームには bt_01_deployed や bt_01_hostnation のような datastream namespace が割り当てられ、読み取り権限もその namespace に応じて制御されていました。認証は Keycloak SSO と Elasticsearch の role mapping でつながれており、どのユーザーがどのチーム空間に入れるかも明確に管理されていました。 この点が重要なのは、マルチテナント環境で本当に避けたいのは UI 上の見え方ではなく、データ境界の破れ だからです。DCM26では、Spaces・データストリーム・認証・権限の各レイヤーをそろえることで、演習に必要な厳格な分離を成立させていました。 事前検証と負荷テスト このアーキテクチャは、ぶっつけ本番で採用されたわけではありません。事前には 50 の Kibana Spaces を用意し、space-scoped Fleet policies を作成したうえで、6,000台の EC2 インスタンスを使った負荷検証が行われました。そこで確認されたのは、データ漏えいが起きないこと、Fleet ポリシー更新が 60 秒以内に伝播すること、space ごとに絞った検索が高負荷でも高速に動作することなどです。 また、6,000台を一度に起動しようとすると AWS EC2 API のレート制限に当たるため、500台ずつ段階的に起動し、間に 5 分のクールオフを挟む形で展開していました。こうした地道な調整も含めて大規模構成を実運用レベルに引き上げていた点は、この事例の大きな価値です。 演習向けの防御設定 Blue Team には、System、Elastic Defend、Windows event forwarding、Auditd、Network Packet Capture などの統合が配布されていました。ただし、 Elastic Defend はそのままだと防御力が高すぎるため、演習中は Prevent mode を無効にし、Detect-only mode で使われていました 。さらに Memory Threat Prevention and Detection も、演習の大部分では無効化されていました。 ここからわかるのは、DCM26が単に「製品機能を最大限見せる場」ではなかったということです。重要だったのは、防御側がきちんと検知し、判断し、対応する訓練を成立させることでした。そのために、製品の強さをあえて制限する判断が取られていたのです。 Red TeamとNSOCの基盤 Blue Team 向けの中心基盤とは別に、Red Team 向けの専用 Elastic デプロイメントと、NSOC 向けの専用デプロイメントも用意されていました。Red Team 側では、Tuoni という C2 フレームワークの状態、ビーコンのコールバック、攻撃オペレーションの進行状況を観測するための基盤として Elastic が使われていました。 一方の NSOC では、演習全体のヘルス状況やセキュリティ監視に加え、AI利用の監査も対象に含まれていました。特に Bedrock API の呼び出しは CloudWatch に記録され、それが NSOC 側の Elastic デプロイメントから観測できるようになっていました。AIもまた、監視されるべき運用対象として扱われていたわけです。 AI活用のガバナンス DCM26では AWS Bedrock を基盤として AI を活用していましたが、運用はかなり慎重に設計されていました。Bedrock Guardrails により、ヘイト、侮辱、性的内容、暴力といった不適切コンテンツ、PII、さらに実際の機密作戦や現実世界の軍事活動に関わる話題を制限していました。 この点は、企業で生成AIを導入するときにも重要です。先に問われるのは「どれほど賢いか」ではなく、「何を扱わせてよいか」「誰が使ったかを追跡できるか」「扱ってはいけない情報に触れないか」です。DCM26は、AIの性能以前に、AIを安全に運用するための条件を固めていた事例として読めます。 Attack Discoveryの役割 演習中、Blue Team は大量のアラートに向き合う必要がありました。そこで有効だったのが Attack Discovery です。複数のアラートを相関し、攻撃の流れをストーリーとして整理することで、平均対応時間の短縮や alert fatigue の軽減に役立ったと説明されています。 ここでの役割は、すべてを自動で解決することではありません。ばらばらのシグナルを整理し、何から見るべきかを判断しやすくすることです。つまり、防御側の判断を置き換えるのではなく、 判断しやすい状態を作る ための支援として位置づけられていました。 3つのAI活用レイヤー DCM26のAI活用を理解するうえでは、この3つを混ぜないことが大切です。まず Elastic AI Assistant や Attack Discovery は、Elastic Security の標準機能として、防御側の調査やアラート理解を助ける役割を担っていました。 一方で Agent Builder は、役割別のカスタムAIエージェントを作るために使われていました。全参加者向けの IT サポートを担う GrantPT 、White Team 向けの採点支援を担う RefPT 、Red Team 向けの攻撃支援を担う Red Rock がその例です。GrantPT は手順書や過去のサポートチケットを参照し、RefPT は提出レポートや演習イベントをもとに採点を支援し、Red Rock は脆弱性や攻撃ベクトルの知識を使って Red Team を助けていました。 さらに Tines は AI そのものではなく、自動化フローの基盤として使われていました。サポート要求が発生すると Tines が動き、Bedrock AI と連携しながら過去の解決策を参照して応答を補助し、サポートキューの負荷を下げていました。つまり、Elastic AI Assistant は調査支援、Agent Builder は役割特化のエージェント構築、Tines は運用自動化と、それぞれの役割は明確に分かれています。 感情分析という試み 演習中には RocketChat の会話全体を Elastic に取り込み、Named Entity Recognition と感情分析を通じて、会話内容やチーム状態の変化を捉える取り組みも行われました。攻撃や障害だけでなく、参加者側のストレスや混乱の兆候も、運営が把握する対象に含まれていたわけです。 大規模演習では、システム異常だけでなく、人の疲労や情報過多も成果に直結します。Elastic がログ以外のテキストデータも同じ基盤で扱えることが、こうした運営の立体化につながっていました。 まとめ DCM26が示したのは、AIの価値は単にモデルを導入することでは生まれない、ということです。大規模データを処理できる基盤、チームごとに厳密に分離された設計、アラートを文脈化する機能、役割別に作られたエージェント、そして AI 利用そのものを監査できる運用モデル。これらがそろってはじめて、AIは実戦的な価値を持ちます。 Elastic はこの演習で、単なるログ基盤や SIEM としてではなく、可視化・検知・AI支援・自動化連携をつなぐ中核として機能していました。ただしそれは Elastic 単独で完結した話ではなく、AWS Bedrock、Tines、Tuoni などとの連携も含めて成立した構成です。DCM26は、AI時代のセキュリティ基盤に必要なのが強い機能の寄せ集めではなく、安全に運用できる一貫した設計 であることを示した事例だと言えるでしょう。 用語集 Elastic 検索、ログ分析、セキュリティ監視、可観測性などをまとめて扱えるプラットフォームです。大量のデータを集めて、見える化し、分析し、異常や攻撃の兆候を見つけるために使われます。 仮想システム 物理的な専用機器ではなく、ソフトウェア上で動くサーバーや端末環境のことです。クラウドや仮想化技術を使って、多数のシステムを柔軟に用意できます。 イベント システム上で起きた出来事を記録したものです。たとえばログイン、ファイル作成、通信、エラー発生などがイベントです。 EPS（Events Per Second） 1秒あたりに処理されるイベント数です。ログやセキュリティイベントがどれくらい大量に流れているかを見る目安です。 マルチテナント 1つの大きなシステムを、複数のチームや組織で共用する考え方です。たとえば1つの建物の中に、別々の会社がそれぞれ専用の部屋を持って入っているイメージです。 テナント マルチテナント環境の中で、各チームや各組織に割り当てられた独立した利用領域のことです。 アクセス制御 誰がどのデータや機能を使えるかを決める仕組み全体を指します。 インフラ自動化 サーバー構築、設定反映、ソフトウェア配布などを手作業ではなく自動で行う考え方です。大規模環境ほど重要になります。 Kibana Elasticに入ったデータを画面で見たり、検索したり、グラフやダッシュボードを作ったりするための画面ツールです。 Kibana Spaces Kibanaの中で、チームごとに画面やダッシュボード、設定を分けるための仕組みです。同じKibanaを使っていても、チームAにはA用の画面、チームBにはB用の画面を見せられます。 Keycloak SSOやユーザー認証、権限管理を行うためのソフトウェアです。誰がどのサービスに入れるかを一元的に管理できます。 SSO（Single Sign-On） 一度のログインで、複数のシステムを使えるようにする仕組みです。何度も別々にIDとパスワードを入れなくて済みます。 自動スケーリング（Autoscaling） 負荷が増えたときに、必要なリソースを自動で増やす仕組みです。逆に負荷が減れば縮小できます。 RBAC（Role-Based Access Control） 役割ベースのアクセス制御です。「この人はこの役割だから、このデータだけ見られる」というように、ロールに応じて権限を決める考え方です。 DLS（Document Level Security） ドキュメント単位のアクセス制御です。同じデータベースの中でも、「このユーザーにはこの文書だけ見せる」「別の文書は見せない」と細かく制御できます。 ドキュメント Elasticの中に保存される1件1件のデータのことです。たとえば1つのログ記録、1つのイベント記録が1ドキュメントになります。 AIガバナンス AIを安全かつ適切に使うための管理の考え方です。何をAIにさせるか、何を禁止するか、記録をどう残すかなどを決めます。 PII（Personally Identifiable Information） 個人を特定できる情報のことです。氏名、電話番号、メールアドレスなどが代表例です。 監査ログ 誰が、いつ、何をしたかを記録するログです。あとで追跡や確認ができるように残します。 CloudWatch AWS上のログやメトリクスを監視・保存するサービスです。 AWS Amazon Web Servicesの略です。Amazonが提供するクラウドサービス群のことです。 IaC（Infrastructure as Code） インフラをコードで管理する方法です。サーバーや設定を手作業で作るのではなく、設定ファイルやコードで自動的に作れるようにします。 Terraform IaCを実現する代表的なツールの1つです。クラウド環境やインフラ構成をコードで定義し、同じ環境を何度でも再現できます。 HashiCorp Vault パスワード、トークン、認証情報などの秘密情報を安全に保管・配布するためのツールです。 Catapult 記事内では、監視エージェントの展開を自動化するために使われたツールとして登場します。大量の環境に同じ設定を一括で配る役割を持ちます。 Fleet エージェントと通信し、設定を配信するための仲介サーバーです。 ポリシー システムに適用する設定ルールのことです。たとえば「このログを集める」「この挙動を監視する」などを定義します。 エージェント 各サーバーや端末に入れて、ログ収集や監視を行う小さなプログラムです。 データストリーム（Data Stream） 時系列で増え続けるデータを効率よく保存・管理するための仕組みです。ログや監視データのように、時間とともにどんどん追加されるデータに向いています。 ILM（Index Lifecycle Management） インデックスを、作成から削除まで自動で管理する仕組みです。たとえば「古いデータは圧縮する」「30日後に削除する」といったルールを自動化できます。 インデックス Elasticでデータを保存する単位です。本でいうと「1冊の本」、データベースでいうと「表」に近いイメージです。 ストレステスト 高い負荷をかけて、システムが耐えられるかを確認するテストです。本番前に限界や弱点を見つけるために行います。 EC2 AWS上で仮想サーバーを起動できるサービスです。必要な台数のサーバーをクラウド上で柔軟に用意できます。 Attack Discovery 多数のアラートやイベントを関連づけて、「1つの攻撃の流れ」として整理するElasticの機能です。ばらばらの警告を、そのままではなく意味のある攻撃ストーリーにまとめます。 アラート 「異常の可能性がある」「確認が必要」とシステムが知らせる通知です。 Initial Access 攻撃者が最初にシステムへ入り込む段階です。たとえば不正ログインや脆弱性悪用が含まれます。 Lateral Movement 攻撃者が、最初に侵入した1台から別の端末やサーバーへ横に広がっていく動きです。 Exfiltration データの持ち出しです。攻撃者が機密情報を外部へ送る段階を指します。 MITRE ATT&CK サイバー攻撃者の手口を体系的に整理した有名なフレームワークです。攻撃の段階や方法を共通言語として扱うためによく使われます。 相関分析 ばらばらに見える複数のデータの関係を見つける分析方法です。個別では小さな異常でも、つなげると大きな攻撃の流れが見えることがあります。 Agent Builder 用途ごとに専用のAIエージェントを作るための機能です。利用者、目的、参照データに応じて、役割別のAIを設計できます。 AIエージェント 特定の目的や役割を持って動くAIです。単なる雑談AIではなく、「サポート担当AI」「分析担当AI」のように仕事が決まっています。 Jira チケット管理や問い合わせ管理によく使われるツールです。障害対応やタスク管理で広く使われています。 SOP（Standard Operating Procedure） 標準作業手順書です。日常運用やトラブル対応で「この順番で対応する」という標準手順をまとめた文書です。 脆弱性 システムやソフトウェアにある弱点のことです。攻撃者に悪用される可能性があります。 可観測性（Observability） システムの状態を、外から十分に把握できるようにする考え方です。問題が起きたときに「今どこで何が起きているか」を見えるようにします。 Blue Team 防御側チームです。攻撃を検知し、調査し、守る役割を担当します。 Red Team 攻撃側チームです。実際の攻撃者を模して侵入や攻撃を行い、防御側の弱点を明らかにします。 NSOC ネットワークやセキュリティの運用全体を監視・統制する役割を持つ運用センターを指します。ここでは演習全体を見守る統制側として使われています。 White Team 演習の運営や審判を行うチームです。ルール管理や評価、全体統制を担当します。 Elastic Defend Elasticのエンドポイント防御・可視化機能です。端末上の挙動を監視し、脅威検知や調査に役立てます。 PCAP ネットワーク通信の中身を記録したデータ形式です。どんな通信が流れていたかを詳しく調べるときに使います。 感情分析 テキストから、その内容がポジティブかネガティブか、怒りや疲労の傾向があるかなどを分析する方法です。 Rocket.Chat チャットやチームコミュニケーションに使うツールです。Slackのような役割を持つソフトウェアです。 ゼロショットNLP 事前に細かく追加学習させていない分類でも、AIが文章の意味を見てテーマやカテゴリを判断する方法です。 NLP（Natural Language Processing） 自然言語処理のことです。人間の言葉をAIやコンピュータで扱えるようにする技術分野です。 ベクトル化 文章や画像を、AIが比較しやすい数値の形に変換することです。 クラスタリング 似ているデータを自動でグループ分けする分析手法です。 人的指標 システムの数字だけではなく、人の疲労、混乱、士気の変化などを表す観点です。運用の現場では、こうした人の状態も重要な判断材料になります。 The post DCM26事例：国防省主催の大規模演習を支えたElasticセキュリティの基盤設計とAI支援 first appeared on Elastic Portal .

はじめに 2026年3月26日、初の試みとして、リクルート本社オフィスにて 「産学連携技術交流会」 を開催しました。本イベント

G-gen の佐々木です。当記事では、Pub/Sub から直接 Vertex AI 上の AI モデルによる推論を取得することができる AI 推論 SMT 機能について解説します。 前提知識 Pub/Sub とは Single Message Transforms（SMTs） AI 推論 SMT の機能 基本事項 AI 推論 SMT の利点 使用できるモデル Model Garden で提供されているモデル Vertex AI Endpoints にデプロイしたモデル モデルの入力・出力 入力するメッセージの形式 推論後のメッセージの形式 制限事項 設定手順 手順の概要 サービスアカウントの作成・権限付与 定義ファイルの作成 トピックの作成 AI 推論 SMT を使用するサブスクリプションの作成 動作確認 メッセージのパブリッシュ メッセージの受信 前提知識 Pub/Sub とは Pub/Sub は Google Cloud におけるフルマネージドなメッセージングサービスです。 メッセージングサービスは、システム間に配置することでメッセージを非同期に中継することができます。これにより、システムの拡張性や保守性を向上することができます。 Pub/Sub を始めとしたメッセージングサービスの詳細やユースケースについては、以下の記事をご一読ください。 blog.g-gen.co.jp Single Message Transforms（SMTs） Single Message Transforms （以下、 SMTs ）は Pub/Sub を使用したストリーミング処理のパイプラインにおいて単純なデータ変換を実現する機能です。 この機能では、Pub/Sub のトピックとサブスクリプションのそれぞれに対して単純なデータ変換処理を実装します。これにより、データの形式の変換やマスキング、フィルタリングなどの処理を、メッセージの配信前に行うことができます。 SMTs の詳細については、以下の記事をご一読ください。 blog.g-gen.co.jp AI 推論 SMT の機能 基本事項 当記事で紹介する AI 推論 SMT （AI Inference Single Method Transform）は、SMTs の機能の1つであり、Vertex AI にある AI モデル（Gemini など）に Pub/Sub のメッセージを渡し、 推論を取得してメッセージに追加することができる 機能です。 通常の SMTs 同様に、AI 推論 SMT はトピックとサブスクリプションのどちらでも設定することができます。 トピックに設定した場合、推論結果がメッセージに追加されたあと、トピックに紐づくすべてのサブスクリプションにメッセージが配信されます。 トピックに対して AI 推論 SMT を設定した場合 サブスクリプションに設定した場合は、そのサブスクリプションでのみ推論を取得するような動作となります。Pub/Sub のユースケースに合わせて設定するとよいでしょう。 サブスクリプションに対して AI 推論 SMT を設定した場合 参考 : AI 推論 SMT 参考 : 単一メッセージ変換（SMT）の概要 - SMT のサンプル メッセージ フロー AI 推論 SMT の利点 AI 推論 SMT を使用してモデル推論とデータ変換を行う場合、以下のようなメリットがあります。 メッセージに対してリアルタイムで AI モデルによる推論結果を追加することができる（データ エンリッチメント） モデルから推論を取得するための処理をアプリケーション側に実装する必要がなくなる サブスクリプションに設定した場合、Pub/Sub はモデル エンドポイントの過負荷を回避し推論のスループットを最大化するため、リクエストレートを最適化する（フロー制御） ※ 単項 pull では最適化されない点に注意 参考 : AI 推論 SMT - メッセージ フロー 使用できるモデル Model Garden で提供されているモデル AI 推論 SMT では、トピックまたはサブスクリプションを作成する際にモデルの推論用のエンドポイントを指定します。 Vertex AI Model Garden で提供されているモデルを使用する場合、以下のような形式でエンドポイントを指定します。 - ai - aiInference : endpoint : "projects/<プロジェクトID>/locations/<モデルを利用するリージョン>/publishers/<モデルのパブリッシャー>/models/<モデル名>" 使用できるモデルの一覧については、以下のドキュメントで最新の情報を確認してください。 参考 : AI 推論 SMT - 互換性のある MaaS モデル Vertex AI Endpoints にデプロイしたモデル ユーザーが Vertex AI Endpoints を使用して Google Cloud 上にデプロイしたモデル（セルフデプロイ モデル）を推論に使用することもできます。 セルフデプロイ モデルを使用する場合は、モデルのエンドポイントの指定の仕方が異なります。 - aiInference : endpoint : "projects/<プロジェクトID>/locations/<エンドポイントのリージョン>/endpoints/<エンドポイント>" 参考 : エンドポイントにモデルをデプロイする モデルの入力・出力 入力するメッセージの形式 AI 推論 SMT による推論を行うためには、Pub/Sub に入力されるメッセージが特定の形式になっている必要があります。 例えば gemini-2.5-flash のような Gemini 基盤モデルを使用する場合、 Chat Completions API を使用して Gemini が呼び出されるため、以下のように Pub/Sub トピックに送信するメッセージの形式を API の仕様に合わせます。 { " model ":" google/gemini-2.5-flash ", " messages ": [ { " role ": " user ", " content ": " Explain how AI works in a few words " } ] } 参考 : AI 推論 SMT - メッセージ処理 推論後のメッセージの形式 AI 推論 SMT によって取得したモデルのレスポンスは、以下のように元のメッセージに追加されます。 { " original_message ": " <元のメッセージ> ", " model_output ": " <推論によって取得したモデルのレスポンス> " } 制限事項 AI 推論 SMT には以下のような制限事項があります。 トピックまたはサブスクリプションに設定できる AI 推論 SMT の数は1つまで Vertex AI Endpoints のプライベート エンドポイントはサポートされていない（公開エンドポイントのみ使用可） グローバル エンドポイントは、Gemini 基盤モデルでのみサポートされる。その他のモデルではリージョン エンドポイントのみ使用可能 Pub/Sub 側では入力されたメッセージのデータ形式などの検証は行われない。トピックにメッセージを送信する前に検証する必要がある 1つのメッセージごとに1つの推論リクエストのみが可能であり、バッチ推論は不可 指定したモデルによる推論は60秒以内に完了する必要がある 推論が60秒を超過するとタイムアウトとなり、Pub/Sub に設定したメッセージ保持期間と再試行回数の上限まで再試行が行われ、その後デッドレタートピックにメッセージが転送されます。 その他、制限事項に関する最新情報は以下のドキュメントをご一読ください。 参考 : AI 推論 SMT - 制限事項 設定手順 手順の概要 当記事で紹介する手順は、サブスクリプションに対して AI 推論 SMT によるメッセージ変換を設定し、そのサブスクリプションのコンシューマーに対してのみ推論結果を含めたメッセージを配信できるようにするためのものです。 参考 : AI 推論 SMT - AI 推論 SMT を作成する サービスアカウントの作成・権限付与 AI 推論 SMT を使用する場合、Cloud Pub/Sub サービスエージェント（ service-<プロジェクト番号>@gcp-sa-pubsub.iam.gserviceaccount.com ）に対して Vertex AI サービス エージェント （ roles/aiplatform.serviceAgent ）ロールを付与するか、カスタムサービスアカウントに対して Vertex AI ユーザー （ roles/aiplatform.user ）ロールを付与します。 当記事ではカスタムサービスアカウントを使用します。 # サブスクリプション用のサービスアカウントを作成 $ gcloud iam service-accounts create pubsub-ai-inference-smt \ --display-name =" Pub/Sub AI Inference SMT " # Vertex AI ユーザー ロールの付与 $ gcloud projects add-iam-policy-binding < プロジェクトID > \ --member =" serviceAccount:pubsub-ai-inference-smt@<プロジェクトID>.iam.gserviceaccount.com " \ --role =" roles/aiplatform.user " 定義ファイルの作成 ai-smt.yaml という名前で AI 推論 SMT の定義ファイルを作成します。これをトピックもしくはサブスクリプションの作成時に指定することで、AI 推論 SMT を使用することができます。 - aiInference : endpoint : "projects/<プロジェクトID>/locations/asia-northeast1/publishers/google/models/gemini-2.5-flash" unstructuredInference : { parameters : { "temperature" : 0.5 , "max_tokens" : 1000 } } serviceAccountEmail : "pubsub-ai-inference-smt@<プロジェクトID>.iam.gserviceaccount.com" endpoint にはモデルのエンドポイントを指定します。 unstructuredInference.parameters には、モデルに推論リクエストを送信する際のパラメータや最大トークン数などを指定できます。 serviceAccountEmail には、先ほど作成したサービスアカウントを指定します。 トピックの作成 Pub/Sub のトピックを作成します。 # トピックの作成 $ gcloud pubsub topics create ai-smt-topic トピックに AI 推論 SMT を設定する場合、ここで --message-transforms-file オプションを使用します。 参考 : gcloud pubsub topics create AI 推論 SMT を使用するサブスクリプションの作成 トピックに紐付けるサブスクリプションを作成します。 当記事ではサブスクリプション側に AI 推論 SMT によるメッセージ変換処理を設定するため、 --message-transforms-file で先ほど作成した定義ファイルを指定します。 # AI 推論 SMT を使用するサブスクリプションの作成 $ gcloud pubsub subscriptions create ai-smt-topic-sub \ --ack-deadline = 600 \ --topic ai-smt-topic \ --message-transforms-file ai-smt.yaml 動作確認 メッセージのパブリッシュ 作成したトピックに対してメッセージをパブリッシュしてみます。 AI 推論 SMT で Gemini モデルを指定しているため、 --message には、 Chat Completions API の仕様に合わせた形式でメッセージを設定します。 # プロンプトを含むメッセージのパブリッシュ $ gcloud pubsub topics publish ai-smt-topic --message =$' { "model":"google/gemini-2.5-flash","messages":[{ "role": "user", "content": "Vertex AI について簡単に説明して" }] } ' 参考 : gcloud pubsub topics publish メッセージの受信 サブスクリプションに配信されたメッセージを確認します。 # メッセージを受信し、データを復号したあと JSON に変換 $ gcloud pubsub subscriptions pull ai-smt-topic-sub \ --auto-ack \ --format =" value(message.data.decode(base64)) " | jq . 受信したメッセージには、元のメッセージである "original_message" に加え、サブスクリプション側の AI 推論 SMT によって "model_output" が含まれていることがわかります。 以下は受信したメッセージの例です。 { " model_output ": { " choices ": [ { " finish_reason ": " stop ", " index ": 0 , " logprobs ": null , " message ": { " content ": " Vertex AI は、Google Cloud が提供する、**機械学習（ML）開発のための統合プラットフォーム**です。 \n\n 簡単に言うと、MLモデルを開発する際に必要な「データの準備」「モデルの構築」「トレーニング」「デプロイ（公開）」「監視・管理」といった**あらゆる工程を、一つの場所で効率的に行えるようにするための「ワンストップショップ」**のようなものです。 \n\n **主なポイント：** \n\n 1. **統合された環境:** これまでバラバラだったML開発のツールやサービスを一つにまとめ、開発プロセスをシンプルにします。 \n 2. **効率化と高速化:** データサイエンティストやMLエンジニアが、インフラの管理に時間を取られることなく、モデルの開発や改善に集中できるよう設計されています。 \n 3. **幅広い対応:** カスタムモデルの構築はもちろん、画像認識や自然言語処理などの特定のタスクに対応した事前学習済みモデルの利用や、AutoML（自動機械学習）機能も提供します。 \n 4. **スケーラビリティ:** Googleの強力なインフラ上で動作するため、大規模なデータや複雑なモデルのトレーニングも柔軟に対応できます。 \n\n 例えるなら、ML開発に必要なあらゆる道具が揃った「高機能な作業台」のようなものです。これにより、企業はより迅速にMLをビジネスに導入し、価値を生み出すことができるようになります。 ", " role ": " assistant " } } ] , " created ": 1775550770 , " id ": " MsHUaYLcFaKTp_QP1_SwiAw ", " model ": " google/gemini-2.5-flash ", " object ": " chat.completion ", " system_fingerprint ": "", " usage ": { " completion_tokens ": 263 , " completion_tokens_details ": { " reasoning_tokens ": 1066 } , " extra_properties ": { " google ": { " traffic_type ": " ON_DEMAND " } } , " prompt_tokens ": 6 , " total_tokens ": 1335 } } , " original_message ": { " messages ": [ { " content ": " Vertex AI について簡単に説明して ", " role ": " user " } ] , " model ": " google/gemini-2.5-flash " } } 佐々木 駿太 (記事一覧) G-gen 最北端、北海道在住のクラウドソリューション部エンジニア 2022年6月に G-gen にジョイン。Google Cloud Partner Top Engineer に選出（2024 / 2025 Fellow / 2026）。好きな Google Cloud プロダクトは Cloud Run。 趣味はコーヒー、小説（SF、ミステリ）、カラオケなど。 Follow @sasashun0805