Cloud Blog JA

Sky: Gemini を全社で一斉に導入し、98% の利用定着率と 2,000 個近いエージェントの共有を実現

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

「AI に強く、AI を使いこなす会社」を目指す Sky株式会社（以下、Sky）は、内製の AI ツールで活用の土台を構築。さらに後継のツールとして Gemini を全従業員約 5,000 名へ一斉配布し、大きな成果を上げています。単なる「業務効率化」ではなく「業務プロセスそのものの変革」を目指すアプローチ、そして具体的な成果について、改革を牽引する AI Innovation Lab の 2 名に伺いました。

利用しているサービス:
Gemini, Gemini Notebook など

利用しているソリューション:
生成 AI

「SKYAI」の内製開発で定着した AI 活用文化を、いかに発展させるか

クライアント運用管理ソフトウェア「SKYSEA Client View」や営業名刺管理サービス「SKYPCE」などで知られる Sky は、自社商品を開発・提供する ICT ソリューション事業と、顧客のシステム開発を担うクライアント・システム開発事業を両輪としています。そんな同社の特長の 1 つは、現場のニーズに応じてソリューションを独自に開発する企業文化です。社内システムも大部分を内製しており、その数は約 200 にのぼります。

事実、生成 AI が登場すると、同社は対話型の生成 AI サービス「SKYAI」を独自開発して全社に提供。自律型リサーチ機能「Deep Research」が普及したときにも、「SKYAI Deep Research」を自力で開発しています。こうしたプロジェクトを牽引してきたメンバーが集まって誕生したのが、社内の AI 専門チームである AI Innovation Lab です。同 Lab 課長の須藤康正氏は、一連の開発プロジェクトの狙いを次のように説明します。

「AI Innovation Lab は、会社のスタイルを構築しつつ、代表が掲げる理念をサービスや機能という形で体現していく、Skyスタイル部に所属しています。『SKYAI』と『SKYAI Deep Research』には、皆の業務を便利にするという目的以上に重要な役割がありました。AI を使うということを従業員のスタイルとして根付かせていくことです。」（須藤氏）

ウェブ検索機能やプロンプト評価機能の実装、全従業員向けの研修といった取り組みもあり、SKYAI の月間利用率は最終的に 90% に達しました。しかしここで須藤氏は、大きな決断を迫られます。SKYAI の継続に注力すれば、新たな AI システムの開発ができなくなるからです。保守部門に運用を引き継ぐ選択肢もありましたが、須藤氏は「攻めの決断」を下しました。

「SKYAI は役割を果たしたと判断し、サービスを終了することにしました。ただし従業員には、代わりとなる AI ツールが必要になりますので、検討に入りました。そこで念頭に置いたのは『どのツールを選ぶか』ではなく、『我々は AI を会社の中でどう使いたいのか』『我々が目指している AI の活用スタイルを育むためには、ツールはいかにあるべきか』というものでした。」（須藤氏）

横断検索の精度、データ連携、ガバナンスを評価して Gemini を選定

このような問題意識に基づき、最終的に選ばれたのは Gemini でした。その際にまず検証されたのは、横断検索の精度だったといいます。同社では高機能な AI を使うことがすでに当たり前となっており、検索精度が低いとユーザーがすぐに離れていくことが懸念されたからです。

「社内で Deep Research を内製していたときには、ナレッジグラフを作っていかなければなりませんでした。また、ベクトル化やチューニング、チャンクサイズの調整など、多くの試行錯誤を繰り返していましたが、企業向け Gemini を採用してみると、我々が作ったシステムと同等以上の精度がすぐに得られました。これはまさに驚きでした。」（須藤氏）

次に検証されたのはデータ連携です。同社は Google Workspace を導入していませんが、企業向け Gemini には、サードパーティ SaaS 向けのコネクタが数多く用意されているため、多様なプラットフォームとのデータ連携は容易に実現できました。そして 3 つ目が、ガバナンスとセキュリティです。同社は顧客のシステム開発も担っているため、エンタープライズ利用を想定したアクセスコントロール、法務部門との調整に必要な情報の確保、知的財産の侵害リスクに備える IP 補償、EnterpriseWebSearch との統合などが不可欠になります。これらの機能が揃っていたことも、採用の後押しとなりました。

「セキュリティについては、条件が『保証されている』『明文化されている』ことを重視しています。Google Cloud は AI 活用におけるセキュリティの担保にも非常に慎重かつ真摯に取り組んでおり、我々が目指しているのと同じ方向で、安全性を追求できるのではないかと感じました。」（須藤氏）

これらの検証を踏まえて、2026 年 1 月、Sky は Gemini の利用を開始。「スタイルは従業員全員で作る」という指針のもと、約 5,000 名の全従業員に一斉に展開しました。これはかなり思い切った決断でしたが、現場ではさまざまな成果が生まれ始めています。AI Innovation Lab 課長代理の帯野幸司氏は、最初の例として、新メンバーのオンボーディングを挙げました。

「従来は新しいメンバーに大量の資料を渡して読んでもらう形になっており、どこまで理解しているかが、なかなか正確に把握できませんでした。しかし、社内の業務情報を部署ごとに整理して Gemini Notebook に読み込ませるようにしたところ、AI との対話を通じて新メンバーが自律的に学習し、疑問点を自己解決できるようになりました。これによりオンボーディング期間が大幅に短縮されています。また、従業員が自律的に部署のノウハウを蓄積し、データを共有する際の形式まで意識してくれるようになりました。これも思わぬ効果です。」（帯野氏）

次の好例は、上長の簡易クローン構築によるコミュニケーションの効率化です。

「上長に案件のレビューや相談を依頼したくても、時間を確保してもらうのが難しいのが実情です。幸い、Sky には従業員が日頃感じていることや考えていることを社内ブログにアウトプットする文化があるので、そこから上長の思考スタイルを Markdown にまとめ、Gemini でエージェント化しました。メンバーだけでなく上長も含め、双方の時間が短縮できています。」（帯野氏）

さらに帯野氏は、Deep Research を使った検索の充実にも触れました。

「以前は AI 活用研修を企画する際にも、ウェブ上の他社事例と社内の過去の研修内容を別々に調べる必要があり、手間がかかっていました。しかし、社内情報とウェブの情報を横断的に検索することにより、自社の実情や過去の文脈に合った精度の高いリサーチができるようになりました。」（帯野氏）

「従業員が AI と一緒に働く」環境を構築し、独自のスタイルを追求

Gemini のアクティブユーザー数は、展開後約 2 か月で急増した後に高止まりしており、定着率は 98% というきわめて高い水準を維持しています。帯野氏は「Gemini が物珍しさだけで使われているのではなく、日々の業務に不可欠なツールとしてほぼすべての従業員に受け入れられ、継続的に利用されていることを示していると考えられます」と解説します。

事実、現場主導で Gemini の活用が広がったことにより、Sky では 2,000 個近くのエージェントが従業員によって開発され、広く共有されるようになりました。その結果、エージェントの検索が困難になるという嬉しい悩みも発生しましたが、この問題は Google Cloud のサポートによって解決されています。

「検索機能の問題もそうですが、エンタープライズユースで『こういう機能が欲しい』と相談すると、いつもすごく真摯に解決案を提案してもらえます。製品の機能とは別に、これも Google Cloud と仕事をしていくうえですごく良いと感じている点です。」（須藤氏）

Sky における AI 活用は、既存業務の強化を目的としたものから、「業務プロセスを変える」ものへ、そして「従業員が AI と一緒に働くようなスタイル」を実現させるものへと進化してきました。導入成果の測定に関しては KPI を設定せず、各部署に独自の基準作りを委ねる一方、活用度そのものを全社共通で評価できる「PAM」というシステムも新たに構築されています。また最近では、自社を「ゼロカスタマー（最初の顧客）」に設定した商品開発でも、AI を活用する方法が模索され始めています。最後に須藤氏は、Gemini に寄せる信頼の大きさを改めて語りました。

「2026 年 7 月には、AI Innovation Lab に『AI 社員』が参加しました。AI は業務のチャットログを常にチェックしており、自分ができる業務をどんどん代行していきます。私たちはこうして生まれた時間を、新たな創発的な業務に 100% 投下していく予定です。生成 AI の活用は、単なるツールの導入に終わらせるのではなく、企業が目指す『スタイル』を明確に思い描き、AI ネイティブな業務改革を進めていくことが重要です。その点、Gemini は私たちにとって、最も使いやすいツールになっています。」（須藤氏）

Sky株式会社
1985 年 3 月 2 日設立。クライアント運用管理ソフトウェア「SKYSEA Client View」や営業名刺管理サービス「SKYPCE」などの自社商品を開発・提供する ICT ソリューション事業と、顧客のシステム開発を担うクライアント・システム開発事業を両輪に事業を展開している。「AI に強く、AI を使いこなす会社」を掲げ、AI 活用による DX やサービス開発などに取り組む。従業員数は 4,655 名（2026 年 10 月 1 日現在）。

インタビュイー（写真右から）
・Skyスタイル部 AI Innovation Lab 課長須藤康正氏
・Skyスタイル部 AI Innovation Lab 課長代理帯野幸司氏

▼ セッション動画を観る
本事例のインタビュイーによるセッション動画が公開中です。あわせてご覧ください。
【Next Tokyo 26 セッション】ツール導入ではない、企業のスタイルを創る「AI 戦略」としての Gemini Enterprise

▼他の導入事例記事を読む
その他の Google Cloud 導入事例はこちらをご覧ください。

Gemini エージェントがスタートアップにもたらすメリット

Wed, 28 Oct 2026 01:20:00 +0000

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

小規模なチーム、限られたランウェイ、そして常に迅速なプロダクト提供を求められるプレッシャー。これは、Google for Startups が日々ともに働く起業家たちが直面している現実です。会社をゼロから立ち上げる際、運用上のオーバーヘッドやインフラストラクチャ構築に費やす時間は、コアプロダクトの開発に割くべき時間を削ることになります。

先週開催された Gemini at Work 2026 で、Google は Gemini エージェントを発表しました。これは、パーソナルアシスタントとしても、チームの専任メンバーとしても機能する汎用エージェントです。そして今週、新しいフロンティアモデルである Gemini 4 Argon の一般提供を開始しました。このモデルは、長時間のマルチステップタスク全体を通してコンテキストを維持するようにトレーニングされています。

ここでは、Gemini エージェントの仕組み、創業者に役立つ 5 つのポイント、そしてスタートアップが実力以上の成果を上げるためにこれをどう活用しているかをご紹介します。

Gemini エージェントとは

文書作成、コーディング、データ分析ごとに、別々の chatbot にプロンプトを入力する必要はもうありません。Gemini エージェントなら、1 つのエージェントが大まかな目標を理解し、完成した成果物まで仕上げて提供します。これは、次の 3 つの原則によって定義されます。

統合型: 1 つのエージェントで、ナレッジワーク、データ分析、クリエイティブアセットの生成、コードの記述と実行を処理できるようになりました。複雑なジョブの場合、専用の一時的なサブエージェントを動的にスピンアップし、それらの作業を並列または順次連携させます。
どこからでもアクセス可能: ウェブ、コマンドライン、デスクトップ、モバイルなど、日常的に使うあらゆる環境で動作します。さらに、Gmail、ドキュメント、スプレッドシート、スライド、ドライブ、Chat、カレンダーにもネイティブに対応しています。
永続性: クラウド上で動作し、4 つの領域（セッション、セマンティック、手続き、エピソード）にわたって連続的なメモリーを保持します。新規採用者のように自ら業務に慣れ、チーム、ツール、ビジネスコンテキストを学習するため、プロンプトごとに自社について説明し直す必要はありません。また、ノートパソコンを閉じた後も、数日間にわたるタスクを進め続けることができます。

5 つの役割を同時にこなす創業者にとって、Gemini は、カレンダー、プロジェクト、ドキュメントの状況をすでに把握している「デジタル参謀」のように機能します。マーケットトレンドの調査、スプレッドシートでの財務モデル作成、そしてその両方を網羅した提案資料の作成まで、各ステップでプロジェクト概要や目標を繰り返し説明することなく、Gemini にまとめて依頼できます。また、先回りして自発的に機能します。投資家から最新のプロダクトアップデートを資料として求めるメールが届くと、Gemini がそのリクエストを検知して処理を提案します。ワンクリックで作業が完了し、すぐに共有やレビューが可能な状態で手元に戻ってきます。

スタートアップ向けの 5 つの重要ポイント

1. コワーカーエージェントとスキルでアウトプットを拡大

個人のアシスタント機能にとどまらず、チーム全体と連携する持続的なコワーカーエージェントを作成することもできます。各エージェントには、それぞれ専用の Workspace アカウント、メールアドレス、ドライブストレージ、ディレクトリ情報が付与されます。リリースコーディネーター、QA トリアージ担当者、財務アナリストといった特定の役割を設定すれば、チームメンバーは Chat スペースにエージェントを追加したり、Google ドキュメントのコメントで @名前リンクを追加したりして作業を委任できます。

また、エージェントに再利用可能なスキルを持たせるだけでなく、Gemini が業務プロセスを学習しながら自らスキルを作成することも可能です。たとえば、BigQuery や Knowledge Catalog と連携した運用レポートスキルを使えば、チームの誰もが平易な言葉で質問するだけで、リアルタイムのレポートを作成して保存できます。一度保存すれば、追加のトークンコストをかけることなく、必要なときにいつでもレポートを実行できます。さらに Gemini では、法務や金融サービスをはじめとする、特定の領域に特化した事前構築済みの機能も提供しています。

スタートアップにとっての意味: コワーカーエージェントによってチームの対応力を即座に引き上げることができます。また、スキルを活用することで、投資家向けレポートや運用レポートなどの定期的なプロセスを標準化し、実行のたびにトークンを消費することもなくなります。

2. オープンモデルとサードパーティモデルを自由に選択

Gemini はエージェントであり、その基盤となるモデルは自由に選択できます。スタートアップのアーキテクチャが成熟するにつれて、すべてのタスクを単一のフロンティアモデルに処理させると、粗利益が急速に圧迫されます。Gemini エージェントを使用すると、Gemini モデル、Anthropic の Claude などのサードパーティモデル、Gemma などの軽量なオープンモデルの間で、ワークロードを動的にルーティングできます。

スタートアップにとっての意味: ロックインされることなく、柔軟性を確保できます。大量の決定的ジョブにはコンパクトモデルを、複雑な推論にはフロンティアモデルを使用することで、タスクあたりのコストを最適化できます。また、プロダクトの進化に合わせて、ワークフローを再構築することなくモデルを入れ替えることができます。

3. サービスやツールに接続

エージェントの有用性は、アクセスできるシステムによって決まります。Gemini エージェントは、Google Workspace に加え、パートナーソリューションを含むエンジニアリング、データ、ビジネスの各種スタックに直接接続できます。

開発とコラボレーション: Git、Slack、Jira など。
データとローカルファイル: BigQuery、Postgres、Snowflake、Databricks などに加え、デスクトップ上のファイルにも対応。
MCP を介したカスタムツール: ネットワーク内外の Model Context Protocol（MCP）サーバー。エンジニアが社内ツールを構築して共有できます。

スタートアップにとっての意味: カスタムコネクタの保守にエンジニアのリソースを割く代わりに、エージェントを既存のコードベース、データベース、MCP ツールに直接接続して、データの所在を問わずリアルタイムに操作できるようになります。

4. 組み込みのセキュリティとガバナンス

B2B スタートアップにとって、大企業によるセキュリティ監査は、商談が失速しやすい大きな関門です。バックグラウンドでは、各エージェントに暗号化されたエージェント ID が割り当てられ、明確な監査証跡が確保されます。また、エージェントは分離されたサンドボックス内で実行され、組み込みのプロンプトインジェクション防御機能によって保護されます。外部トラフィックは Agent Gateway を経由してルーティングされるため、ガバナンスポリシーを確実に適用できます。さらに、コワーカーエージェントもそれぞれ Workspace アカウントを持つため、管理の手間はこれまでのユーザー管理とまったく変わりません。

スタートアップにとっての意味: 大企業の最高情報セキュリティ責任者から、AI ワークフローにおけるデータプライバシー、プロンプトインジェクション、アクセス制御への対策を問われても、すでにエンタープライズグレードのアーキテクチャが整っているため、調達プロセスのハードルをスムーズにクリアできます。

5. リアルタイムのコスト管理でランウェイを保護

サブエージェントを数時間から数日間にわたって実行する自律型エージェントは、ループ処理をチェックしないままでいると、すぐに請求額が膨れ上がってしまいます。こうした事態を防ぐため、Cloud Billing コンソールでリアルタイムの費用上限を直接設定できるようになりました。上限に達するとプロジェクトのエージェントが自動的に一時停止するため、バグによる予期せぬ高額請求を確実に回避できます。その基盤として、Gemini は推論に最適化された TPU 8i を含む Google による特化型 AI インフラストラクチャ上で動作し、前世代比で 80% 優れたコストパフォーマンスを実現します。

スタートアップにとっての意味: 創業者や開発者は、長時間動く並列エージェントループの試行錯誤に安心して取り組めます。標準で備わった財務セーフティネットが手元資金を守り、投資家からの信頼確保にもつながります。

すでに実践している創業者

スタートアップや AI ネイティブなイノベーターは、すでに Gemini を活用しています。没入型ストーリーテリングプラットフォームを提供する Whenere は Dreamlands を活用して、名作小説『高慢と偏見』の世界を Fortnite 上に再現しました。Dreamlands は Gemini 基盤のエージェント型 3D ワールド構築プラットフォームであり、Gemini は新しいオブジェクトごとにテクスチャを約 7 秒、10 セント未満のコストで生成しました。あるアーティストは、1 日で約 250 個のカスタムアセットを作成し、歴史的に忠実な邸宅を 1 週間足らずで完成させました。アプリケーション構築プラットフォームの Lovable をはじめ、OpenEvidence、Recursion、Replit などのスタートアップやイノベーターも、この動きに加わっています。

Google for Startups で構築

エージェント時代の到来により、社内業務を担うコワーカーエージェントのデプロイから、プロダクトへのエージェント型ワークフローの直接組み込みまで、少数精鋭のチームであっても実力以上の大きな成果を生み出せるようになります。

これらの新しい Gemini エージェント機能はまだ一般公開されていませんが、スタートアップのお客様は Google のセールスチームにお問い合わせいただくことで、詳細の確認や今後の準備についてご相談が可能です。また、Google for Startups プログラムで、クレジット、実践的な技術ガイダンス、メンターシップ、グローバルな創業者コミュニティプログラムなどもご利用いただけます。

- Google、グローバルスタートアップおよび投資家エコシステム担当バイスプレジデント、Darren Mowry

Google Antigravity で Claude Opus 5.5 と Claude Sonnet 5.5 が利用可能に

Wed, 28 Oct 2026 01:00:00 +0000

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

手早いバグの修正の繰り返しから複雑な移行の計画まで、タスクごとに適したモデルは異なります。

オープンなエコシステムへの取り組み、そしてあらゆるタスクに最適なモデルを開発者に提供するという Google Cloud のコミットメントに基づき、Google Cloud をご利用のお客様は Google Antigravity で Claude Opus 5.5 と Claude Sonnet 5.5 をお使いいただけるようになりました。Claude Opus 5.5 は複雑なタスク向けに設計されているのに対し、Claude Sonnet 5.5 はより高速かつ低コストな補完モデルです。

管理者によって有効化されると、開発者はモデル選択ツールから Claude Opus 5.5 と Sonnet 5.5 を直接選択できるようになります。管理者は、Gemini 3.8 Flash や Gemini 4 Argon を含む Google の Gemini モデルを選択することもできます。これらのモデルは、Antigravity 2.0、Antigravity CLI のほか、VS Code、JetBrains IntelliJ、Visual Studio 向けに最近リリースされた Antigravity IDE 拡張機能に適用されます。これにより、エンタープライズ共通の請求枠組みとセキュリティ境界のもとで、タスクに最適なモデルを選択できるようになります。

この投稿では、これらのモデルを使用して Antigravity で開発を行うための 2 つのエンジニアリングパターンをご紹介します。全サブスクリプションプランにおいて Antigravity でサポートされているモデルの一覧については、こちらのドキュメントをご覧ください。

Antigravity のマルチモデルエンジニアリングパターン

同じエージェントハーネス内で複数のモデルファミリーを利用可能にすることで、レイテンシとコストを管理しながらコードの品質を高める、実践的なマルチモデルワークフローが実現します。

パターン 1: ループワークフローとグラフワークフローでのクロスモデル検証（「LLM-as-a-Judge」）

エージェントループや複数ステップのグラフワークフローを構築する際、コードの記述と自身の出力のレビューに同じモデルを使用すると、そのモデル固有の盲点を補強してしまう恐れがあります。2 つの異なるモデルファミリーを組み合わせ、一方を実装者、他方を検証者（判定者）とすることで、ワークフローの次のステージに進む前に第三者的な検証が可能になります。

Antigravity では、このパターンをインタラクティブに実行することも、自動化されたサブエージェントを介して実行することもできます。

モデル A で計画と実装を行う: Claude Opus 5.5 または Gemini 4 Argon を使用してプランニングモードで開始し、複数ファイルにわたる変更の設計と実装を行います。
モデル B で検証する: ループの変更を commit するか、次のステップへ進める前に、モデルを切り替えるか、CLI で単発の /model チェックを呼び出して、別のモデルファミリーにテストスイートや要件に照らして実装を評価させます。

パターン 2: 推論モデルと Flash サブエージェントの組み合わせ

複雑なエンジニアリングタスクでは、高度な推論を要する少数の意思決定と、大量の機械的なルックアップ（ファイルの検索、ログの grep、lint 出力の確認、テスト失敗の分類など）が組み合わされることがよくあります。すべてのルックアップをフロンティアモデルで実行すると、レイテンシとコストの両方が増加する可能性があります。

Antigravity のサブエージェントカスタマイズシステム（.agents/agents/*.md）を使用すると、特定のモデルティア（inherit、flash、pro）を専門のサブエージェントに割り当てることができます。プライマリセッションでより強力なモデルを稼働させている場合、以下のように動作します。

model: inherit が設定されたサブエージェントは、高度な推論を要するサブタスクに対してアクティブなセッションモデルを使用します。

model: flash が設定されたサブエージェントは、高速な検索、分類、トリアージ作業を Gemini Flash モデルにオフロードします。

たとえば、.agents/agents/test-triager.md で高速なログトリアージサブエージェントを以下のように定義できます。

code_block: <ListValue: [StructValue([('code', '---\r\nname: test-triager\r\ndescription: Runs unit tests, classifies failures, and returns a concise summary of failing assertions.\r\nmodel: flash\r\ntools:\r\n - read\r\n - edit\r\n---\r\n\r\nRun the requested test targets, classify any failures by root cause (compilation error, assertion failure, or timeout), and return a structured summary to the parent agent.'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fac257efed0>)])]>

また、.agents/agents/gemini-judge.md では、クロスモデルのコードレビュー担当者サブエージェントを以下のように定義できます。

code_block: <ListValue: [StructValue([('code', "---\r\nname:cross-model-judge\r\ndescription: Independent LLM-as-a-judge verifier that audits diffs and edge cases using Gemini Pro.\r\nmodel: pro\r\ntools:\r\n - read\r\n---\r\n\r\nReview the current workspace diff against the user's requirements. Check for regressions, missing edge-case tests, and security issues. Output a pass/fail verdict with specific line references."), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fac257ec4d0>)])]>

この設定により、高速な「テストと分類」のループを test-triager に委任し、cross-model-judge をトリガーして最終的なコード差分を検証できます。これにより、各モデルの強みを単一のワークフロー内で活かすことが可能になります。

ご利用にあたって

Claude Opus 5.5 と Claude Sonnet 5.5 は、Antigravity を使用している Google Cloud のお客様にご利用いただけます。

管理者（Gemini for Business）: サードパーティのパートナーモデルは、プールされている Gemini Enterprise Standard および Plus エディションの月間トークン割り当てから消費されることはありません。代わりに、既存の Google Cloud 請求先アカウントを通じて従量課金制で請求されるため、超過料金の設定を有効にする必要があります。Google Cloud コンソールで [Gemini Enterprise] > [設定] > [AI デベロッパーツール] に移動して、超過料金の請求、費用の上限、組織のパートナーモデルの承認を構成します。詳しい手順については、AI デベロッパーツールの設定方法をご覧ください。
管理者（Gemini プラットフォーム）: Gemini プラットフォームの API 経由で Antigravity をご利用の場合も、パートナーモデルを有効化できます。Model Garden で Claude モデルを有効化し、Anthropic の標準利用規約に同意してください。
開発者: Antigravity 2.0、Antigravity CLI、または Antigravity IDE 拡張機能を最新バージョンに更新し、モデル選択ツールを開いて（または /model を実行して）、タスクに適したモデルを選択します。エンタープライズガバナンスやマルチエージェント構成の詳細については、Google Antigravity Enterprise のドキュメントをご覧ください。ワークスペースの状態、開いているアーティファクト、ターミナルのコンテキストを保持したまま、同じ会話スレッド内のターン間でアクティブなモデルを切り替えることが可能です。

^{注: コンテキスト管理や要約といった高頻度で発生するクライアントサイドの調整処理のために、軽量なファーストパーティの Gemini モデルがバックグラウンドで引き続き稼働します。これらのモデルはファーストパーティトークンを消費するため、料金が発生する場合があります。}

- Google Cloud、プロダクトマーケティングマネージャー、Marialaura Garcia

- Google Antigravity、デベロッパーリレーションズ、Rich Hyndman

グローバル規模のハードウェア格納型セキュリティ: NVIDIA Blackwell を搭載した Confidential G4 の一般提供を開始

Tue, 27 Oct 2026 16:00:00 +0000

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

自律型エージェントを本番環境に導入するには、機密データや貴重な知的財産をリアルタイムで処理する必要があります。独自のモデルの重み、ユーザープロンプト、生成された出力を守るには、計算処理を実行している最中のデータを保護するセキュリティが必要です。

企業のセキュリティを確保するための取り組みの一環として、このたび、NVIDIA RTX PRO 6000 Blackwell Server Edition GPU を搭載した Google Cloud の G4 インスタンスで Confidential Computing の一般提供を開始したことをお知らせいたします。このリリースにより、NVIDIA Confidential Computing が Google Cloud の AI Hypercomputer に直接統合され、プライバシーを損なうことなくスケーリングに必要な動的パフォーマンスを実現します。

今年に入って Confidential G4 のプレビュー版を発表した際、そのグローバルな展開規模についてお話ししました。このたび、36 のゾーンにまたがり、複数の利用モデルに対応したこれらのインスタンスを、Compute Engine VM と GKE ノードにて、一般提供を開始いたしました。

さらに、安全なマルチパーティデータ共有を可能にする Confidential Space のサポートも、今後数週間かけて順次一般提供される予定です。

機密データとモデルを低レイテンシで保護

使用中のデータを保護するために、GPU スループットや運用のアジリティを犠牲にする必要はありません。エクスポート不可のハードウェアキー、検証可能なリモート認証、透過的なメモリ暗号化を統合した Confidential G4 は、エージェント型ワークロードや推論ワークロードへの投資効果を最大化します。企業は、厳格な規制要件やコンプライアンス要件を満たしながら、コストを低く抑えることができます。

「組織がクラウド、オンプレミス、エージェント環境など、ますます複雑化する環境に AI をデプロイするなかで、機密データの保護は極めて重要となっています。また、AI システムがセキュリティを確保したうえで、自社のポリシーに準拠して一貫して動作することを担保しなければなりません。NVIDIA RTX PRO 6000 Blackwell GPU を搭載した Google Cloud Confidential G4 VM は、プライバシー保護型の AI および AI 運用に向けた強力な基盤を提供します。Confidential Core AI は Google Cloud 上で動作し、企業の原則、ポリシー、運用要件を、AI エージェント、モデル、データ、ツールをモニタリングおよび統制するリアルタイムの安全保護対策へと落とし込みます。これらの機能を組み合わせることで、組織は管理、機密性、説明責任を維持しながら、Google Cloud 上で信頼性の高い AI を大規模に展開できます。」- Confidential Core AI、創業者 / CEO、Taher Behbehani 氏

エンタープライズ AI ワークロードにおけるその他のメリットは以下のとおりです。

エンドツーエンドの機密性と分離: ハードウェアによって保護された実行環境でデータとモデルパラメータを暗号化し、知的財産やお客様の入力をホストシステム管理者、ハイパーバイザ、さらにはクラウドプロバイダによるアクセスから保護します。
検証可能な暗号化による信頼: ハードウェアをルートとするリモート認証を活用し、機密データセットの解放やワークロードの実行前に、コード、プラットフォーム構成、環境の整合性を検証します。
コードのリファクタリングが不要: 標準の Ubuntu OS イメージ、NVIDIA ドライバ、NVIDIA CUDA-X ライブラリを使用し、アプリケーションの変更やカスタムビルドを行うことなく、そのままモデルをデプロイできます。

Polaris Cloud にとって、このデプロイの容易さはまさに画期的なものでした。

「Polaris は AI エージェント用のワークスペースを開発しています。お客様は、エージェントの処理が実際にどこで実行されたのか、そしてその過程で暗号技術によって確実に分離されていたかを知る必要があります。Google Cloud Confidential G4 の登場によって、その課題は一気に解決しました。NVIDIA RTX PRO 6000 Blackwell GPU からハードウェア格納型の来歴を取得し、お客様が結果とともに受け取るレシートにバインドしています。それ以外は実質的に何も変わっていません。同じ G4 イメージ、同じ NVIDIA ドライバ、同じコンテナランタイムを使い、起動時にフラグを 1 つ指定するだけで、パフォーマンスもそのままです。これにより、お客様に対する当社の約束は、『お客様のエージェントを実行します』というものから『当社で実行するすべてのワークロードは検証可能です』というレベルへと、一夜にして引き上げられたのです。」- Polaris Cloud、創業者 / CEO、Fred Esere 氏

マルチパーティデータコラボレーション: Confidential Space を使用して、共同分析やモデルの共同トレーニングを安全に行うことができます。複数の関係者が、元となるプライベートデータを互いに開示することなく、機密性の高いデータセットを組み合わせることができます。

「企業は、最も価値のあるデータを AI で活用しながら、その処理中の保護も両立させる必要があります。NVIDIA Confidential Computing は、GPU アクセラレーションワークロードにハードウェア格納型の保護を提供し、使用中の機密データや独自モデルを守ります。Google Cloud と連携し、NVIDIA Blackwell のパフォーマンスとこれらのセキュリティ機能を Confidential G4 VM に導入することで、組織は高いパフォーマンスと検証可能な保護機能を備えた本番環境の AI を大規模に展開できるようになります。」- NVIDIA、アクセラレーテッドコンピューティングプロダクト担当ディレクター、Dave Salvator 氏

パフォーマンスのテスト

メモリ暗号化が運用に与える影響を把握するため、g4-standard-48 マシンシェイプを使用して、Confidential G4 インスタンスと標準の非 Confidential G4 インスタンスの比較分析を行いました。今回のテストでは、広く採用されているオープンウェイトモデルに焦点を当てました。これらのモデルは、お客様が自社の推論パイプラインにおいて、単一の GPU インスタンスによくデプロイしているものです。

Llama 3、Llama 3.3、Resnet-50、SDXL などの主要なモデルを対象としたベンチマークでは、Confidential G4 は AI 推論ワークロードにおいて標準の G4 インスタンスと同等のパフォーマンスを発揮し、スループットの低下は 3.5% 未満（1 秒あたりのトークン数または画像数で測定）であることが示されています。

注: パフォーマンス測定結果は、特定のテスト条件および構成に基づくものです。実際のワークロードのパフォーマンスは、システムのセットアップ、選択するハードウェア、ソフトウェア環境によって異なる場合があります。

Google の分析結果は、機密データを保護し、コンプライアンス要件を満たしながら、スピーディーな展開を可能にします。この両立は、実際の導入現場ですでに実証されています。

「当社のワークロードにおいて、Google Cloud の Confidential G4 と、まったく同じソフトウェアを稼働させた標準の G4 との比較ベンチマークを実施しました。エンドツーエンドのレイテンシ増加はわずか 5.2% にとどまり、その一方で、認証された環境外にいる権限のないユーザーによる会話の盗聴を防ぐ、ハードウェアレベルの保証が得られることがわかりました。このトレードオフなら、何度でも選ぶ価値があります。ユーザーはオンプレミス同等のプライバシーを確保しながら、クラウドの利便性を享受できるからです。」- Vertebrae、CEO、Andy Qin 氏

Confidential G4 を使ってみる

Confidential G4 を活用すれば、モデルの実行やエージェントワークロードにおけるセキュリティを強化するにあたって、パフォーマンス、柔軟性、運用の容易さを犠牲にする必要はありません。スループットの低下をほぼゼロに抑えつつ、検証可能な信頼性と堅牢なハードウェア分離を提供することで、組織は価値の高いモデルを安全にデプロイし、重要なデータアセットをクラウド規模で保護できます。

GPU を使用した Confidential VMs のドキュメントに沿って、今すぐご利用を開始してください。

- Confidential Computing 担当プロダクトマネージャー、Meghna Sreenivasan

- Confidential Computing 担当プロダクトリード、Sam Lugani

Cloud Run 上の Temporal Serverless Workers: 需要の変動を見越してワーカーをスケーリング

Tue, 27 Oct 2026 02:10:00 +0000

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

オープンソースの Temporal 実行プラットフォームは、現代のソフトウェアインフラストラクチャにおける基盤レイヤとして急速に普及しており、特に分散システムや AI エージェントワークロードのオーケストレーションで真価を発揮しています。しかし、Temporal でワーカーのデプロイやスケーリングを行うには、特有の課題が伴います。ワーカーはリクエストの処理ではなくタスクのポーリングを行うため、リクエストドリブンなサーバーレスプラットフォームには適していません。その結果、Kubernetes や VM 上でワーカーフリートを運用せざるを得なくなり、継続的な管理の手間と費用が発生します。指標パイプラインを構築し、自動スケーリングのトリガーをチューニングしても、指標の反映遅延によってスケーリングが急激な負荷に追いつかないことがあります。デプロイごとにアップグレードやバージョンの複雑な管理に追われ、タスクがキューにない状態でもコンピューティング料金を払い続けなければなりません。

Google は、まさにこのような pull ベースのタスクのために Cloud Run ワーカープールを開発しました。インスタンスがキューやストリームに接続し、次のアイテムを取り出して処理します。このたび、Temporal のオープンソースプラットフォームのフルマネージド版である Temporal Cloud が、これらのワーカープールを自動スケーリングできるようになりました。現在プレビュー版として提供されている Cloud Run 上の Temporal Serverless Workers を使用すると、ワーカーをワーカープールとしてデプロイできます。Temporal は、タスクキューの作業量に合わせてプールのサイズを自動調整します。タスクがない場合は、プールをゼロにスケールダウンできます。運用すべきクラスタやオートスケーラーは不要で、既存のワーカーコードもそのまま利用できます。

Cloud Run ワーカープールと Temporal の連携の仕組み

ワーカープールは、継続的なバックグラウンドタスクを実行するための Cloud Run リソースです。パブリックエンドポイントを持たず、各インスタンスのライフサイクル全体にわたって CPU が常時割り当てられます。これは Temporal ワーカーの実行モデルと一致しています。Temporal は、Cloud Run ワーカープールを次のように管理します。

Temporal ワーカーは、プロジェクト内で Cloud Run ワーカープールのインスタンスとして実行され、Temporal Cloud をポーリングしてタスクを取得します。
Temporal Cloud は、付与された IAM 権限を使用してタスクキューの状況をトラッキングし、Cloud Run Admin API 経由でワーカープールのインスタンス数を設定します。Temporal がインスタンスへの接続を開くことはないため、ポートを開いたり、ファイアウォールルールを追加したりする必要はありません。
ビルドのバージョンごとに、それぞれ独立した Cloud Run ワーカープールとして実行します。古いビルドのワーカープールは、そのビルドで開始されたワークフローで再び処理が必要になるまで、インスタンス数をゼロの状態で待機させることができます。

Temporal ワーカーは、ご自身のプロジェクト内、サービスアカウント、ネットワーク上で実行されます。Temporal が、その実行数を判断します。

Temporal Serverless Workers の活用例

Cloud Run ワーカープールと Temporal Serverless Workers を組み合わせることで、以下のようなさまざまなユースケースが実現します。

自動スケーリングするエージェントワーカー: AI エージェントが、LLM の推論とツール呼び出しのマルチステップチェーンを実行します。ここでは、Temporal の耐久性に優れた実行機能と Cloud Run ワーカープールが効果的に連携します。Temporal ワーカーは即座にスピンアップし、LLM の処理ステップ、エンベディング生成、API 呼び出しなどの急激な負荷を処理したあと、キューが空になると自動でゼロにスケールダウンします。ワーカーは Google Cloud AI API にキーレスでアクセスできます。推論用に GPU をアタッチすることも可能で、その場合でも GPU 付きのワーカーは問題なくゼロまでスケールダウンします。Temporal は、各モデルやツールの呼び出しを耐久性に優れたアクティビティとして実行します。ステップの途中でワーカーが消失した場合でも、アクティビティは別のワーカーで再試行され、ワークフローは継続されます。

長時間実行されるワークフロー: Temporal ワークフローは無制限に実行し続けることができるため、現実世界のリソース状態を長期間にわたってトラッキングするアプリケーションを構築できます。このパターンは、あるエンティティの状態をワークフローが表すことから、一般に「エンティティパターン」と呼ばれます。しかし、こうした長時間実行されるワークフローでは、常に一定のコンピューティングが必要とされるわけではありません。個々のステップによって処理時間が短いものもあれば長いものもあり、時にはワークフロー自体がスリープして、人間や外部システムからの入力を待機している状態になることもあります。Cloud Run ワーカープールは、このパターンをサポートする柔軟なコンピューティングリソースを提供します。個々のステップは必要な時間だけ実行でき、処理すべきタスクがないときは、Temporal がワーカープールを自動的にスケールダウンします。

バーストバッチ処理: ワーカープールはインスタンスの実行中にのみ課金されるため、バッチ実行の合間にアイドル状態になっているワーカープールは、インスタンスがゼロの間は費用が発生しません。請求処理やメディアのコード変換といったジョブでは、バッチ処理の到着に合わせて Temporal がプールをスケールアウトし、キューが空になると自動でスケールインします。最大インスタンス数を設定することで、課金対象となるインスタンス数を制限できます。設定した上限を超えるタスクは、ドロップされるのではなく、キューで待機します。

Temporal ワーカーの実行基盤に Cloud Run ワーカープールを選ぶ理由

以前は、Cloud Run サービス上で Temporal ワーカーを実行するために、いくつかの回避策を講じる必要がありました。

HTTP リスナーの実装（Cloud Run サービスは、コンテナが特定のポートでリクエストをリッスンすることを前提としているため）
インスタンス単位の課金への変更（リクエスト処理の合間もワーカーが CPU を保持し続けるようにするため）
最小インスタンス数の設定（Cloud Run サービスがゼロにスケールダウンしないようにするため）

Cloud Run ワーカープール上で Temporal ワーカーを実行することで、これらの回避策は不要になり、次のようなメリットが得られます。

エンドポイントの管理が不要。ロックダウンすべき公開 URL やロードバランサは存在せず、実装が必要なヘルスチェックポートもありません。
低料金で安定した CPU。インスタンスはアイドル状態にならず、スロットリングも行われません。Cloud Run はアイドル状態に見えるインスタンスを勝手に削除しないため、プールが縮小するタイミングは Temporal のみが決定します。ワーカープールの料金は、インスタンス課金型の Cloud Run サービスと比較して、vCPU 時間あたりおよび GB 時間あたりで約 40% 安く設定されています。
リビジョンのチャーンなしでスケーリング。インスタンス数を変更しても新しいリビジョンは作成されないため、Temporal は負荷の変化に応じて頻繁にプールのサイズを変更できます。

Temporal によるワーカープールのスケーリングとバージョニングの仕組み

Temporal は、タスクがタスクキューのバックログに追加されてからワーカーに取得されるまでの遅延を主要な指標として、リソースを追加するタイミングを判断します。この遅延が大きくなっている場合は、利用可能なワーカーが飽和状態にあります。スケーリングは次のように行われます。

サーバーサイドの検出: Temporal サーバーは、タスクキューごとにバックログからワーカー取得までのレイテンシをトラッキングします。
プッシュ通知: レイテンシがトリガー条件を超えると、サーバーはワーカーコントローラインスタンスにプッシュ通知を送信します。
プロビジョニング: ワーカーコントローラがワーカープールにリソースを追加します。新しいインスタンスが起動して接続し、タスクのポーリングを開始するまでには一定の時間を要するため、リソースの追加はシグナルの検知より遅れて反映されます。

Temporal は常に予備のリソースを保持しているため、タスクが溜まってから対処するのではなく、需要の増加に先立ちあらかじめプールを拡張します。スケールインはより慎重に行われます。Temporal は、利用可能なワーカーが見つからなかった最後の時点から一定の安定化期間（デフォルトは 90 秒）が経過するのを待ってからスケールインを行い、連続してインスタンスを減らす際にも一定の間隔を空けます。Cloud Run の構成可能な正常シャットダウン機能により、シャットダウン時間が 10 秒から 10 分に延長されます。これにより、SIGTERM に対応したワーカーが処理を完了させるか、チェックポイントを作成するための時間を確保できます。インスタンス数は、設定した最小値から最大値の範囲内に維持されます。アイドル期間後の最初のタスクがインスタンスの起動を待てない場合は、最小値を 1 以上に設定してください。

実行中のワークフローに影響を与えずに新しいコードをデプロイするのは容易ではありません。Temporal ワークフローはステートフルで決定的な挙動をするため、実行途中でコードを差し替えると非決定性エラーが発生します。Cloud Run 上の Serverless Workers は、Temporal ワーカーのバージョニングを必須にすることで、この問題を解決します。条件分岐を使用してコードにパッチを適用する必要はありません。代わりに、各ワーカーデプロイバージョンは独立したワーカープールとしてデプロイし、deploymentName と buildId で識別します。個別のワーカープールを使用することで、次の 2 つの問題を解決できます。

特定のワーカーデプロイバージョンで開始されたワークフローは、そのバージョンのまま実行を継続し、完了まで処理されます。
各ワーカーデプロイバージョンは個別にスケーリングとドレインが行われるため、コンピューティング費用とリソース利用率をアプリケーションの要件に沿って最適化できます。既存のワークフローが完了して以前のワーカーデプロイバージョンがドレインされると、基盤となるワーカープールは最終的に自動でゼロにスケールダウンされます。

ワークフロータイプごとにバージョニング動作を設定するか、ワーカーレベルのデフォルトを設定します。

PINNED: ワークフローは、開始されたワーカーバージョン（ビルド ID）に固定され、そこで終了します。短時間実行のワークフロー、注文処理、マルチステップ API に最適です。
AUTO_UPGRADE: ワークフローのロールアウトに伴い、新しい「現在の」または「ターゲット」ワーカーデプロイバージョンへと移行します。サブスクリプション請求や数週間に及ぶタスクなど、長時間実行のワークフローに最適です。

ワーカーバージョニングの構成の詳細については、こちらをご覧ください。

使ってみる

セットアップは次の 3 つのステップで行います。

Temporal ワーカーをコンテナ化し、プール名にビルド ID を含めて Cloud Run ワーカープールとしてコンテナをデプロイします。Temporal API キーなどの認証情報は Secret Manager に保管します。
ワーカープールをスケールできるように、Temporal Cloud に管理権限を付与して、Temporal をワーカープールに接続します。
プールのプロジェクト、リージョン、名前を指定したワーカーデプロイバージョンを Temporal で作成します。

Cloud Run の Temporal Serverless Workers はプレビュー版であるため、安定版リリースまでに API や構成が変更される可能性があります。利用を開始する方法は次のとおりです。

Cloud Run 上の Serverless Workers がどのようにスケールし、バージョンを処理するかを理解する。
セットアップガイドに沿って、最初のワーカーをデプロイする。
Cloud Run ワーカープールに関するドキュメントで、CPU、メモリ、GPU、ネットワーキングのオプションを確認する。
構成可能な正常なシャットダウンのプレビュー版に申し込む。

- プロダクトマネージャー、Sagar Randive

- エンジニアリングマネージャー、Aniruddh Chaturvedi

ARMORY CASTLE が BeyondTrust の脆弱性を悪用

Tue, 27 Oct 2026 02:00:00 +0000

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

執筆者: Jayson Frost、Bryce Greathouse、Brian Meyer、John Palmisano、Rajesh Rajeshirke、Steve Rasch、John Wolfram

はじめに

BeyondTrust は 10 月 15 日に、BeyondTrust Remote Support（旧 Bomgar）アプライアンスに影響する脆弱性 CVE-2026-102764 を公表しました。BeyondTrust Remote Support は、IT チームがリモートエンドポイントに安全にアクセスしてトラブルシューティングを行うことができる、エンタープライズ向けのセキュアなリモートアクセスソリューションです。この脆弱性の悪用に成功すると、任意のファイルをアップロードできます。

Mandiant は、インシデント対応において、中国との関連が疑われるサイバースパイ目的の脅威アクターである ARMORY CASTLE（以前は UNC5221 として追跡）が、2026 年 8 月下旬にこの脆弱性をゼロデイとして悪用した証拠を特定しました。このブログ投稿では、ARMORY CASTLE が CVE-2026-102764 を悪用した後、どのように権限を昇格させ、侵害された BeyondTrust Remote Support アプライアンスへの永続的なアクセスを確立したかを説明し、防御に関する実用的なガイダンスを提供します。

ARMORY CASTLE やその他の脅威アクターはこれまで、脆弱性が一般に公表された後に、それを広範囲にわたって日和見的に悪用してきた経緯があるため、組織は脆弱性が明らかになった後に悪用が広がる可能性に備える必要があります。

脆弱性の悪用

Mandiant は、access、syslog、messages、thin-scc、brain、SSL の各ログファイルで、CVE-2026-102764 の悪用の痕跡を特定しました。これらのファイルは、/home ディレクトリを含む LUKS 暗号化パーティションを介してのみアクセスできるものです。影響を受ける組織は、BeyondTrust が提供するセキュリティパッチを直ちに適用して脆弱性を修復し、BeyondTrust のブログで追加のガイダンスを確認することを強くおすすめします。

侵入後の活動

Mandiant は、ARMORY CASTLE が CVE-2026-102764 の悪用に成功した後、複数の異なる TTP を利用して足がかりを確立し、権限を昇格させ、ラテラルムーブメントを可能にしたことを確認しています。ARMORY CASTLE は、侵入全体を通じて、BeyondTrust アプライアンスの内部構造に関する深い知識を利用していました。これは、独自の CLI ユーティリティ、起動構成テンプレート、ローカルのリバースプロキシルーティングが悪用されたことからわかっています。脅威アクターは、新たに特定されたカスタムマルウェア、SAWFLY ウェブシェル、BARECLAW トンネラーを使用して、BeyondTrust デバイスを操作していました。また、アクセスを維持して検出を回避するために、アプライアンスのログとエンドポイントのアーティファクトを定期的に削除していました。

図 1: ARMORY CASTLE による BeyondTrust 侵害における一連のイベント

ステージング用のウェブシェル

CVE-2026-102764 の悪用に成功した後、ARMORY CASTLE は /app_84304470%2Ephp への POST リクエストを開始しました。Mandiant は、これらの POST リクエストに関連付けられたファイルを復元できませんでした。最初の POST リクエストから約 11 分後に、ウェブルートパス /%SITE_SERVICE_ACCOUNT%/ingredi/app/laravel/public/ に SAWFLY ウェブシェルが作成されたことをファイルシステムが記録しています。ARMORY CASTLE は、侵入の過程で、環境内の主要な足がかりの一つとして SAWFLY ウェブシェルを利用していました。

SAWFLY ウェブシェル

SAWFLY（mangoapi.php）は、難読化された軽量の PHP ウェブシェルで、カスタムの Base32 トランスポート層と 256 ビットの RC4 ストリーム暗号を使用して、双方向の暗号化された C2 通信を実装します。このウェブシェルは、受信する HTTP POST リクエストで、難読化されたパラメータ _c94mfe の有無を確認します。

パラメータが存在しない場合、スクリプトは直ちに HTTP ステータス「404 見つかりません」（http_response_code(404)）を設定し、自動ウェブクローラや脆弱性スキャナを回避するために終了します。_c94mfe パラメータが指定されている場合、ウェブシェルはペイロードを Base32 でデコードし、ハードコードされた 32 バイトの鍵を使用して RC4 で復号してから、結果の PHP コードを @eval() で実行します。評価されたコードから返される null 以外の値は、同じ鍵を使って RC4 で暗号化され、Base32 でエンコードされて、クライアントにエコーバックされます。

SUID ビット権限による権限昇格

SAWFLY ウェブシェルは、サイトのサービスアカウント（権限のないローカルユーザー）で実行されました。脅威アクターは、権限を昇格させるために、システムシェルの実行可能ファイル（/bin/sh）をファイル /usr/bin/dbus-authd にコピーしました。

その後、脅威アクターはファイルの所有権を root に変更し、Set User ID（SUID）ビットを設定しました。バイナリで SUID 権限が有効になっている場合、コマンドを実行するユーザーではなく、ファイルの所有者（root）の権限で実行されるため、結果的に、ホストシステムへの永続的な root レベルのバックドアアクセスが脅威アクターに許可されました。

ウェブシェルを介して足がかりを確立した後、アクターはウェブサービスアカウントからアプライアンスホストの root レベルの制御に昇格しました。これにより、アプライアンスが保存または仲介するすべての認証情報にアクセスし、ファイルを変更できるようになりました。これは、再起動や構成のリセット後も維持されます。

認証情報の収集: BeyondTrust Vault の抽出

Mandiant は、脅威アクターがアプライアンスのネイティブシークレット管理データベースから認証情報を直接収集しようと試みていたことを確認しました。アクターはその際に /ns/sbin/bt-secrets バイナリを利用していました。これは、BeyondTrust アプライアンスにネイティブの独自の管理コマンドラインインターフェース（CLI）ユーティリティであり、パスワード、API キー、エンドポイント認証情報の管理、保存、取得に使用されているものです。

脅威アクターは、アプライアンスの認証情報 Vault を特定してダンプするために、いくつかの CLI 構文のバリエーションを体系的に繰り返していました。

/ns/sbin/bt-secrets get -p %SITE_SERVICE_ACCOUNT% vault
/ns/sbin/bt-secrets get %SITE_SERVICE_ACCOUNT% vault
/ns/sbin/bt-secrets get vault

図 2: メッセージログから復元されたコマンド

脅威アクターは最初に、特定のサイトのサービスアカウント用 Vault を標的にして、そのプロファイル専用に割り当てられたパスワードと鍵を取得しようとしました。

次に、フォールバックコマンドを実行して、グローバルなアプライアンスレベルのパスワードセーフを標的にして、保存されている管理者の認証情報をすべてダンプしました。

そして、/home/bomgar/log/bt-secrets.log に保存されたレコードとアーカイブファイルを強制的に削除して、bt-secrets バイナリとのやり取りを終了しました。

/usr/sbin/sh -c 'rm -f /home/bomgar/log/bt-secrets.log /home/bomgar/log/bt-secrets.log.* 2>/dev/null;'

図 3: メッセージログから復元されたコマンド

永続性

Mandiant は、脅威アクターが長期的な永続アクセスを目的として、BeyondTrust 構成テンプレートを標的にし、サイトのサービスアカウントにパスワードなしの root 権限を付与したことを確認しました。

脅威アクターは最初に /home/bomgar/sbin/post_boot.d ディレクトリを作成しました。このディレクトリは、システム起動時に自動的に実行されるスクリプト用に予約されているものです。このディレクトリ内に、zz-root-persist という名前のシェルスクリプトを作成しました。

zz-root-persist スクリプトの内容を見ると、まず /ns/config/sudoers.template ファイル内で、ユーザーアカウントにパスワードなしの root 権限がすでに付与されているかどうかを確認しています。エントリがない場合、スクリプトは '%SITE_SERVICE_ACCOUNT% ALL=(ALL) NOPASSWD: ALL' をテンプレートに追加します。sudoers テンプレートに追加されたこのエントリにより、サイトのユーザーアカウントに、ホストシステムで任意のコマンドを実行するためのパスワードなしの管理者権限が付与されます。

最後に、スクリプトは '/ns/sbin/bt-sysconfig' --no-restart misc を実行します。これは、アプライアンスのバックエンドに、/ns/config/sudoers.template を直ちに解析して、アクティブな /etc/sudoers ファイルを再構築するよう強制するものです。この戦略により、脅威アクターの権限昇格は、システムの再起動や構成のリセット後も維持されます。通常、システムの再起動や構成のリセットを行うと、/etc/sudoers に直接加えられた手動の変更は上書きされます。

#!/bin/bash
grep -qF '%SITE_SERVICE_ACCOUNT% ALL=(ALL) NOPASSWD: ALL' '/ns/config/sudoers.template' || echo '%SITE_SERVICE_ACCOUNT% ALL=(ALL) NOPASSWD: ALL' >> '/ns/config/sudoers.template'
'/ns/sbin/bt-sysconfig' --no-restart misc

図 4: zz-root-persist の内容

フォレンジック対策

Mandiant は、脅威アクターがアプライアンスへの不正アクセスを通じて、システム、ウェブサーバー、アプリケーションレベルのログを体系的に削除することで、防御を損ない、検出を妨げようとした複数のケースを確認しました。

脅威アクターは、SAWFLY ウェブシェルから、昇格した sudo 権限を使用して次のコマンドを実行し、ホストとサイト固有のディレクトリの両方でアクティビティログを削除しました。

'rm -f \'/ns/log/auth.log\' \'/ns/log/ssl.log\' \'/ns/log/proto-handler.log\' \'/ns/log/bt-docker.log\' \'/ns/log/http-access.log\' \'/ns/log/http-errors.log\' \'/ns/log/php-fpm.log\' \'/ns/log/php-fpm-access.log\' \'/ns/log/php_debug.log\' \'/ns/log/php_web_errors.log\' \'/var/log/messages\' \'/home/%SITE_SERVICE_ACCOUNT%/ingredi/log/httpd_access.log\' \'/home/%SITE_SERVICE_ACCOUNT%/ingredi/log/httpd_error.log\' /tmp/sshauth.*'

図 5: 復元されたコマンド

ラテラルムーブメント: BeyondTrust 管理者セッションの不正使用

脅威アクターは、BeyondTrust デバイスを侵害した後、BeyondTrust Remote Support アプリケーションにピボットし、不正に入手した管理者の認証情報を使用して偵察を行いました。脅威アクターはまず、管理者アカウントを利用してウェブ管理ポータルにログインしました。

{
  "event": "login",
  "status": "success",
  "target": "web/login",
  "who": "[REDACTED_USERNAME] using password",
  "who_ip": "[REDACTED_IP]"
}

図 6: BeyondTrust Syslog エントリ

脅威アクターはその後、初期アクセスをテストし、ネイティブの Administrators グループポリシーに一時的に参加できることを確認した後、長期的な永続化のために戦略を変更しました。アクターは、侵害したアカウントの権限を直接変更し、ローカルの Jump Item とチームの権限の両方を「No Access」から「Administrator」にアップグレードしました。Jump Item は、Jump Group 内でリモートアクセスを可能にした個々のシステムまたはデバイスであり、管理者がリモートシステムへのアクセスを整理、管理できるようにするものです。この構成の変更により、脅威アクターは、アプライアンスの Jump Item リストに登録されているダウンストリームシステムへのリモートセッションを起動する、永続的かつ無制限の権限を取得しました。

{
  "event": "user_changed",
  "old_username": "[REDACTED]",
  "old_permissions:jump_item_role:default:id": 1,
  "new_permissions:jump_item_role:default:id": 3,
  "old_permissions:jump_item_role:default:name": "No Access",
  "new_permissions:jump_item_role:default:name": "Administrator",
  "old_permissions:jump_item_role:teams:id": 1,
  "new_permissions:jump_item_role:teams:id": 3,
  "old_permissions:jump_item_role:teams:name": "No Access",
  "new_permissions:jump_item_role:teams:name": "Administrator"
}

図 7: BeyondTrust Syslog エントリ

内部偵察

Mandiant は、脅威アクターが昇格した管理者権限を取得した後、リモートサポートセッションを確立して、内部エンドポイントを標的にしたことを確認しました。

接続が確立されると、脅威アクターはアプライアンスに組み込まれているサポートツールを利用して、ファイルシステムへのフルアクセスをリクエストし、取得しました。その後、BeyondTrust Remote Support のネイティブファイル転送サービスを利用して、ソフトウェアインベントリなど、ネットワーク偵察に役立つ機密性の高い内部ドキュメントをユーザーのデスクトップ環境から直接ダウンロードして引き出しました。

BARECLAW トンネラー

Mandiant は、脅威アクターがカスタム SOCKS5 プロキシトンネラーを使用して、BeyondTrust デバイスを通過するトラフィックをトンネリングしたことを確認しました。BARECLAW は C 言語で記述されたトンネラーであり、WebSocket トランスポートを介して運ばれる SOCKS5 プロキシサービスを提供し、リモートクライアントと宛先間の TCP 接続を中継します。BARECLAW は、静的に埋め込まれた CivetWeb WebServer を利用して HTTP と WebSocket の機能を提供し、TLS に OpenSSL を利用します。BARECLAW は構成可能で、認証を必須とすること、クライアントとトンネラー間のデータを暗号化すること、到達可能な宛先を特定の CIDR の範囲に制限すること、トラフィックをアップストリームプロキシに転送すること、そしてデフォルトの WebSocket エンドポイントとリスニングポートを変更することが可能です。TLS は PEM 証明書を提供することで有効になります。認証、暗号化、宛先フィルタリング、TLS はデフォルトで無効になっています。

BARECLAW は CLI 入力から構成を受け取り、CLI オプションメニューを提供します。

Usage: %s [options]
  --listen PORT            plain ws port (default 8080)
  --listen-tls PORT        wss port (default 8443, needs --ssl-cert)
  --ssl-cert FILE          PEM certificate (enables wss)
  --token STRING           shared secret (?token= auth + obfs seed)
  --obfs                   enable XOR stream obfuscation
  --timeout SEC            idle timeout (default 300)
  --connect-timeout SEC    target connect timeout (default 10)
  --max-tunnels N          concurrent tunnel limit (default 100)
  --allow-net CIDR         allowed target subnet (repeatable)
  --upstream [socks5://]host:port   route via upstream SOCKS5
  --threads N              civetweb worker threads (default 64)
  --ws-path PATH           websocket endpoint path (default /wsproxy)
  -q, --quiet              zero output (all logging suppressed)
  -h                       this help

図 8: BARECLAW の CLI オプションメニュー

脅威アクターは、次のコマンドライン引数を使用して BARECLAW を実行しました。

/tmp/ingredi_ws --listen 19800 --token %REDACTED% --obfs -q --ws-path /uidchanarge

図 9: BARECLAW の全コマンドライン引数

このコマンドラインは、TCP ポート 19800 でリッスンし、被害者のシステムに WebSocket エンドポイント /uidchanarge を作成するよう BARECLAW を構成しています。また、コマンドライン引数で指定するトークンを認証に使用することをクライアントに求め、-q 引数でトンネラーのロギングを抑制しています。トンネリングされたデータは、そのトークンと、セッションの開始時にクライアントから提供された 8 バイトの値から導出された XOR ベースのルーチンで暗号化されます。CLI オプションに --ssl-cert と --listen-tls の引数がないということは、この特定のインスタンスで TLS が有効になっていなかったことを意味します。

Haproxy.conf の変更

Mandiant は、脅威アクターが BARECLAW トンネラーを作成しただけでなく、BARECLAW にインターネットから直接アクセスできるように /ns/config/haproxy.conf ファイルを変更したことも確認しました。BeyondTrust デバイスで動作する HAProxy サービスは、デバイスのリバースプロキシとして機能し、BeyondTrust サーバーに代わって受信リクエストを受け入れ、リクエストのポートまたは URL パスに基づいて、ローカルシステムで実行されている適切なバックエンドサービス（ウェブインターフェース、管理ポータル、アプリケーションゲートウェイなど）にリクエストを転送するものです。

haproxy.conf ファイルは、BeyondTrust アプライアンスが受信トラフィックを処理、ルーティング、保護する方法を指示する、主要な構成ファイルです。脅威アクターが変更した内容として、まず、特定の URI パス /uidchanarge への受信トラフィックをモニタリングする、wswsws という名前のアクセス制御リスト（ACL）が確立されました。このパスに一致するリクエストが検出されると、HAProxy は通常のアプライアンスウェブサービスをバイパスし、webskd3 というカスタムバックエンドにトラフィックをルーティングします。

    acl wswsws path /uidchanarge
    use_backend webskd3 if wswsws

図 10: haproxy.conf における ACL の変更

次に、webskd3 バックエンドが、受信したウェブストリームをローカル（127.0.0.1 / localhost）で TCP ポート 19800 にルーティングします。このポートでは、BARECLAW ユーティリティがアクティブにリッスンしています。このローカル専用バインディングにより、バックドアリスナーは HAProxy のローカルリダイレクトを介して内部からのみアクセスできるため、外部ネットワークスキャンから完全に隠蔽されます。

backend webskd3
    mode http
    server websocks5srv 127.0.0.1:19800
    option http-keep-alive
    timeout server 28s
    timeout tunnel 5h

図 11: haproxy.conf におけるバックエンドルートの変更

アトリビューション

GTIG は、CVE-2026-102764 のゼロデイ攻撃と、それに続く SAWFLY および BARECLAW のデプロイを、中国との関連が疑われるサイバースパイアクター ARMORY CASTLE（以前は UNC5221 として追跡）によるものと特定しています。この侵入で使用されたツールと TTP は、以前に確認された ARMORY CASTLE の活動と一致しています。

GTIG は以前、ARMORY CASTLE がエッジアプライアンスの複数の脆弱性を悪用し、パッシブバックドアやウェブシェルからエッジデバイスのトロイの木馬化されたコンポーネントまで、目的をサポートする広範なカスタムツールのスイートをデプロイしていることを報告しました。ARMORY CASTLE は 2023 年 10 月から活動しており、これまでにさまざまな国や業種を標的にしてきました。

見通しと影響

ARMORY CASTLE は、過去のキャンペーンで、ゼロデイとして選択的に悪用していた脆弱性が公表された後、それを広範囲にわたって日和見的に悪用し、パッチが適用される前に標的組織に侵入しようとしました。そのため、CVE-2026-102764 に関しても、同様の広範な悪用の試みが確認される可能性があります。

GTIG は、ARMORY CASTLE がサイバースパイの目的を達成するために、今後もエッジデバイスのゼロデイ脆弱性を利用して環境へのアクセスを獲得し続けると高い確信を持って評価しています。防御側は、CVE-2026-102764 の公表後にも、2024 年の CVE-2023-46805 と CVE-2024-21887 の公表後に GTIG が確認したものと同様の広範な悪用を ARMORY CASTLE が行う可能性に備える必要があります。

修復とセキュリティ強化

BT26-05 パッチをまだ適用していない組織は、直ちに影響とリスクを評価し、BeyondTrust のブログに記載されている追加のガイダンスを確認する必要があります。CVE-2026-102764 は、サポートされているすべての Remote Support バージョン（26.2.3 まで）に影響します。認証されていないリモート攻撃者がアプライアンス上でファイル操作を実行できるため、ホストレベルの制御や、アプライアンスが保存または仲介するすべての認証情報へのアクセスにつながる可能性があります。脆弱性のあるバージョンで、悪用が可能な期間中にインターネットからアクセス可能だったアプライアンスは、確認が完了するまで、侵害された可能性があるものとして扱う必要があります。Mandiant は、封じ込めとサポート対応の中断のバランスを取りながら、パッチ適用を優先する段階的なアプローチを推奨しています。

即時の緩和

組織は、リスク許容度、侵害の証拠、運用上のニーズに基づいて、次のオプションから選択する必要があります。

オプション 1: BT26-05 パッチを適用する（Mandiant 推奨）

Remote Support SaaS: 2026 年 10 月 9 日に、BeyondTrust がすべての SaaS テナントにパッチを適用済みです。アプライアンス自体について、お客様による対応は必要ありません。ただし、オプション 3 の認証情報と構成の手順は依然必要です。
セルフホスト型、バージョン 24.3.1 以降: /appliance インターフェースから BT26-05-RS パッチを適用するか、アプライアンスが自動更新に登録されている場合は、パッチが自動的に適用されたことを確認します。
セルフホスト型、24.3.1 より前のバージョン: サポート対象のバージョンにアップグレードしてから、パッチを適用します。アップグレードすると脆弱性は解消されますが、それ以前に受けた影響は修復されません。
/appliance にパッチが表示されない場合は、BT26-05 を指定して BeyondTrust サポートにケースを登録してください。

オプション 2: 侵害された、または侵害が疑われるアプライアンスを隔離する

対応前に保存する: 変更や再起動を行う前に、メモリを含む仮想アプライアンスのスナップショットを作成し、ディスクをエクスポートします。B シリーズのハードウェアと SaaS テナントの場合は、BeyondTrust サポートを通じてフォレンジック保存をリクエストしてください。ホストにアクセスできる攻撃者はアプライアンス上のログを削除できるため、脆弱性がインターネットに露出していた期間中の syslog、リバースプロキシまたは WAF、境界ファイアウォールのログを収集します。Mandiant は、アクターがインシデント期間中のログを削除していたことを確認しています。
境界で隔離する: アプライアンスのパブリックアドレスへのインバウンドトラフィックは、/appliance ではなくファイアウォールでブロックします。これにより、構成はそのまま残り、後で確認できます。
外向きトラフィックを制限する: BeyondTrust のアップデートとライセンスのエンドポイントへのトラフィックを除き、アウトバウンドトラフィックを拒否し、拒否されたすべての接続をログに記録します。
アクセスパスを終了する: /login から、アクティブなサポートセッションを終了し、新しいセッション、Jump Client、Jumpoint、API アカウントを無効にします。削除ではなく無効化することで、監査証跡が残ります。
クリーンアップではなく再構築する: 侵害が確認された、または侵害ステータスが不明なアプライアンスを、完全にパッチが適用されたクリーンなイメージから再デプロイします。お客様はアプライアンスのホストファイルシステムを監査できません。また、ホストレベルの永続性は再起動や構成のリセット後も維持されます。露出期間より前の日付の構成バックアップのみを復元するか、隔離された状態で最新のバックアップを復元し、オプション 3、パート B の確認を完了してから、再接続します。新しい TLS 証明書を発行し、再構築したアプライアンスから Jump Client、Jumpoint、担当者向けコンソールを再デプロイします。

注: 隔離やセッションの終了を行うと、サポート対応が中断されます。組織は、続行する前にヘルプデスクやベンダーサポートの関係者と調整を行う必要があります。

オプション 3: ターゲットを絞った補完的な制御を適用する

以下の制御により、露出を減らし、侵害後の影響を制限できます。これらはパッチの代わりにはなりません。

パート A: ネットワークの制限

アプライアンスレベルで、IP またはネットワークセグメントによって管理インターフェース /login と /appliance へのアクセスを制限します。インターネットからアクセスできるのは、担当者向けコンソール、カスタマーポータル、Jump Client のトラフィックのみにする必要があります。
運用上可能な場合は、アプライアンスの前に完全な URI ロギングを備えたリバースプロキシまたは WAF を配置して、アプライアンスが変更できないリクエストパスの記録をとります。

パート B: 認証情報のローテーションと構成の確認

セッションと登録を取り消す: すべてのアクティブなサポートセッションを終了し、パッチ適用済みまたは再構築済みのアプライアンスから Jump Client、Jumpoint、担当者向けコンソールを再デプロイして、既存のトークンを無効にします。
依存関係の順に認証情報をローテーションする: /appliance 管理者の認証情報、/login 管理者とローカルユーザー、API クライアントシークレット、セキュリティプロバイダのバインドアカウントと SAML 署名鍵、Remote Support Vault と統合された Password Safe または Privileged Remote Access（PRA）認証情報（ターゲットシステムでローテーション）、統合認証情報（SMTP、syslog、情報技術サービス管理（ITSM）コネクタ、アウトバウンドイベントのシークレット）、期間中にサポートセッションに入力された認証情報。
/login 構成を対象期間前のベースラインに照らして確認する: ユーザーとロールの変更、特に管理者権限に昇格された Jump Item ロール、グループとセッションのポリシー、API アカウント、セキュリティプロバイダ、Jump Item と Jumpoint、アウトバウンドイベントまたは syslog の宛先。変更記録や所有者名のないものはすべて削除します。
サポートセッションのレポートを確認する: ファイル転送を含む期間中のレポートを確認し、どのエンドポイントにアクセスされ、何が残されたかを特定します。アクセスされたすべてのエンドポイントが、ダウンストリームハンティングの対象となります。

注: 認証情報のローテーションは、アプライアンスのパッチ適用か再構築の後で行ってください。それより前にローテーションを行うと、新しい認証情報が、アプライアンスをまだ制御している攻撃者に開示されます。

パート C: コントロールプレーンの制限

すべての /login ユーザーに、フィッシング耐性のある MFA を使用した SAML シングルサインオンを必須とします。また、ローカルアカウントは、Vault に保存され、使用時にアラートが発生する、ブレークグラスアカウント 1 つを除いて削除します。
組み込みの管理者アカウントについては、公式の BeyondTrust 2 要素認証ガイドラインに沿って多要素認証（MFA）が構成されていることを確認します。
すべてのグループポリシーで、Jump Item のデフォルトのロールを「No Access」（アクセスなし）に設定し、ユーザーごとではなくポリシーを通じてロールを付与します。
API アカウントのスコープを最小限の権限セットに設定し、ユーザーまたは Jump Item の管理権限を持つアカウントには自動化の所有者を指名します。また、API シークレットはスケジュールに沿ってローテーションします。
特権認証情報は、Remote Support Vault ではなく、認証情報インジェクションを使用する Password Safe または外部 Vault に保管します。アプライアンスには、非対話型サービスアカウントの認証情報のみを保存します。
アプライアンスからのアウトバウンドトラフィックにデフォルト拒否のフィルタリングを適用し、BeyondTrust のエンドポイントおよび組織独自の syslog サーバーとディレクトリサーバーのみを許可します。

パート D: ロギングと検出エンジニアリング

ロギングと可視性

アプライアンスの syslog を TLS 経由で SIEM に転送し、数か月にわたる露出期間をカバーする保持期間を設定します。また、アプライアンスのアドレスのリバースプロキシまたは WAF と境界ファイアウォールのログを収集します。
/login セッション、チームアクティビティ、ユーザー監査レポートをスケジュールに沿ってエクスポートします。

検出エンジニアリング

アカウントとポリシーの変更: Jump Item またはチームロールを昇格させる user_changed イベント、変更チケットのない user_added イベント、api_account イベント、security_provider イベント、アウトバウンドイベントまたは syslog 宛先の変更。
認証: 家庭向けブロードバンドまたは商用 VPN アドレス空間からの /login の成功、営業時間外の管理者ログイン。
セッションアクティビティ: ファイル転送イベント、対象期間中にロールが変更されたアカウントによって開始されたセッション。
リクエストパス: リバースプロキシまたは WAF で、Remote Support の既知のパスセット外のパス（不明な .php パス、サポートスタッフやエンドポイントのアドレス範囲外からの WebSocket アップグレードなど）。
フォレンジック対策: アプライアンスからの syslog 転送におけるギャップ。1 つのセッションに限定された中断は、ログの改ざんを強く示唆します。

セキュリティ侵害インジケーター（IoC）

このブログ投稿で説明した活動の検出と特定に役立てていただくため、登録ユーザー向けの GTI コレクションにセキュリティ侵害インジケーター（IoC）を含めました。

ファイルインジケーター

ファイル名	説明	SHA-256
app_84304470%2Ephp	ステージング用のウェブシェル	該当なし
mangoapi.php	SAWFLY ウェブシェル	dc14e215269a93fdbc4c1a80b984c23faf7af0911c6dbb85309796a6f2ae95fb
ingredi_ws	BARECLAW トンネラー	1f19b9a27d79c11bda00a1e8faf74a7fdd683d38ccef1b60df2fd0307e3aa462

検出

YARA ルール

rule G_Hunting_Webshell_SAWFLY_1 {
  meta:
author = "Google Threat Intelligence Group"    
  strings:
    $b32 = "ABCDEFGHIJKLMNOPQRSTUVWXYZ234567" ascii wide
    $rc4 = "range(0,255)" ascii wide
    $pack = "pack('H*'," ascii wide
    $eval = "@eval(" ascii wide
    $code404 = "http_response_code(404)" ascii wide
  condition:
    filesize < 20KB and
    all of them
}

rule G_Hunting_Backdoor_BARECLAW_1 {
  meta:
    author = "Google Threat Intelligence Group"

  strings:
    $s1 = "[%s ws_socks5d] " ascii wide
    $s2 = "--obfs requires --token" ascii wide
    $s3 = "mux: %s (frame[%lu]: %s)" ascii wide
    $s4 = "cannot create stream pump/writer thread (stream %d)" ascii wide
    $s5 = "reject: bad or missing token from %s" ascii wide
    $s6 = "listening on %s path=%s (token=%s obfs=%s max_tunnels=%d threads=%d)" ascii wide
    $s7 = "--ws-path must start with '/'" ascii wide
    $b_xorshift = { 48 c1 e0 17 48 31 c1 48 89 f0 48 c1 e8 1a 48 31 f0 48 31 c8 48 c1 e9 11 48 31 c8 }
  condition:
    uint32(0) == 0x464c457f and (5 of ($s*)) or ($b_xorshift and (3 of ($s*)))
}

Google Security Operations（SecOps）

Google SecOps をご利用のお客様は、Mandiant Hunting、Mandiant Frontline Threats、Mandiant Intel Emerging Threats の各ルールパックで、これらの幅広いカテゴリのルールやその他のルールをご利用いただけます。このブログ投稿で取り上げた活動は、Google SecOps において以下のルール名で検出されています。

Echo Pipes Base64 To Shell
Base64 Encoded Shell Command Execution
Low Severity Endpoint Detection Cluster on Host
Suspicious Curl Download to tmp
Suspicious Curl Network Connection to Staging Directory

謝辞

この脅威への対応における BeyondTrust のご協力に感謝いたします。

- Google Threat Intelligence Group

- Mandiant

Google Public Sector と SUNY、大学の研究を加速する AI 対応プラットフォームを開設

Mon, 26 Oct 2026 01:00:00 +0000

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

公立研究大学は、社会が直面する最も差し迫った課題の解決に取り組んでいますが、アイデアを画期的な成果へと結び付けるには、最先端テクノロジーへの迅速かつセキュアなアクセスが欠かせません。エージェント型 AI の時代において、研究機関にはかつてない機会が訪れています。膨大なデータセットの処理、複雑なワークフローの実行、そして科学的発見の劇的な加速を実現するインテリジェントシステムを活用できるようになるからです。

このたび、Gemini at Work で、ニューヨーク州立大学（SUNY）との協業による SUNY AI Platform の開設を発表しました。本プラットフォームは、Gemini Enterprise を搭載し、Google Cloud 上に構築されたセキュアな AI およびハイパフォーマンスコンピューティング環境です。

当初は SUNY の中で最も研究に重点を置く 9 つのキャンパスで展開されるこのプラットフォームは、研究者が仮説から発見へとよりスピーディに移行できるよう支援するとともに、ニューヨークの学生や人材が AI 主導の経済環境に適応できるよう設計されています。

実社会に寄与する研究

SUNY の研究者は、ニューヨーク州内外の地域社会に直結する課題の解決に取り組んでいます。具体的な取り組みとしては、気象予測の精度向上、水質問題の早期発見、がん治療に向けた DNA シーケンシング、診断精度を高める高解像度脳画像データの解析などが挙げられます。

このような取り組みをサポートするため、SUNY AI Platform では、あらゆる技術的背景を持つ研究者が Google Cloud の高度な機能を簡単に活用し、その恩恵を受けられるようにしています。本プラットフォームは、ストレージ、ハイパフォーマンスコンピューティング、Gemini Enterprise、200 以上の信頼できる AI モデルを、シームレスかつ一元化された 1 つのエコシステムに統合しています。個々のチームやキャンパスがこれらの機能を独自に準備する必要はなく、すべての研究者が共通の基盤上で研究を進められます。これにより、データ分析の簡素化、研究機関を跨ぐコラボレーションの促進、そして一貫したガバナンスや「責任ある AI への取り組み」の適用が可能になります。

New Way Now: SUNY、Google Cloud の活用により社会と科学にもたらす公益を推進

SUNY コミュニティへの AI 対応スキルの展開

インパクトを生み出すのは、テクノロジーそのものではなく「人」です。

この協業の一環として、SUNY は業界で高く評価されている Google のセルフペース型 AI 認定資格を大学システム全体で導入し、学生や教職員が無料で受講できるようにしています。各コースは 5〜10 時間程度で修了でき、事前知識や経験は一切不要です。効果的なプロンプトの作成、複雑な課題の解決、AI ツールの責任ある活用など、実務に役立つ実践的なスキルを習得できます。さらに SUNY は、Google Career Certificates を学術プログラムに組み込む取り組みも進めています。これにより、学生は学位の取得と同時に、社会で即戦力となる技術スキルを身につけて卒業できるようになります。

SUNY AI Platform とこれらの学習機会は、AI 導入に対するより包括的なアプローチを示すものです。つまり、高度なテクノロジーへのアクセスと、それを責任を持って現場で活用するために必要なスキルや組織体制を組み合わせて提供するというアプローチです。

SUNY が提供する無料の AI 学習ツールとリソースについては、suny.edu/google をご覧ください。あわせて、SUNY の研究データ戦略担当ディレクター、Catherine Stollar Peters 氏が出演するパートナーシップ動画もぜひご覧ください。学術界のリーダーたちが AI を活用して教育や公共部門をどのように変革しているかを紹介しています。

また、10 月 20 日に開催される Google Public Sector Summit にご参加いただくと、公共部門のリーダーたちが AI を活用して組織を変革している事例を直接聞くことができます。

- Google Public Sector、米国教育機関、州政府、地方自治体担当マネージングディレクター、Matt Schneider

サイバーエージェント: Cloud Run や Agent Development Kit を活用し、クリエイティブ生成 AI プラットフォーム「AI SCREAM」のエージェント化を推進

Fri, 23 Oct 2026 02:00:00 +0000

株式会社サイバーエージェントは、広告領域での活用を想定した社内向けクリエイティブ生成 AI プラットフォーム「AI SCREAM（アイスクリーム）」を、Google Cloud 上に構築し、約 3 年にわたって運用してきました。2025 年には Agent Development Kit（ADK）を活用したエージェント基盤を追加し、画像を作るための「道具」から、制作ワークフローを支援する「仕組み」へと進化させることに成功しています。その開発キーマンに、3 年間の総括と今後の展望を伺いました。

利用しているサービス:
Cloud Run、Pub/Sub、Veo、Imagen、Nano Banana など

利用しているソリューション:
生成 AI

独自プラットフォーム「AI SCREAM」で全社員に生成 AI を届ける

AI SCREAM は、動画生成 AI の Veo や、画像生成 AI の Imagen、Nano Banana（Gemini Flash Image / Pro Image 等）など、社内審査を経て商用利用可能な複数の生成 AI モデルを統一された UI 上で横断的に活用できる、サイバーエージェント独自のクリエイティブ生成AIプラットフォームです。広告制作などで必要となる静止画や動画、音声といった素材の作成から、それらを組み合わせた最終アウトプットまでを、誰もが手軽に行える仕組みを提供しています。

AI SCREAM 開発責任者の瓜生和也氏は、その出発点は「生成 AI を使いたくても使えない人が社内に大勢いたこと」だったと振り返ります。

「2023 年当時、画像生成 AI 活用の機運は高まり始めていましたが、導入と利用には高度な専門知識が求められており、エンジニア以外のクリエイターや営業担当者は、到底手の出せない状況でした。そうした『壁』を取り払い、全社員に生成 AI を届けることが、このプロジェクトの目的となっています。」（瓜生氏）

2023 年 10 月、VM 1 台でスモールスタートした AI SCREAM は、2024 年 1 月に全社展開を見据えたリアーキテクチャを実施します。Cloud Run で動くフロントエンド／バックエンドと、推論ワーカーの VM 群の間に Pub/Sub を挟み、非同期の境界で疎結合にする構成に作り替えることで、より多くの社員が快適に使えるようになりました。

「インフラ層においては、社員約 8,000 人のうち 3 割、約 2,400 人が日常的に使うところまでスケールさせたいという事業要求に応えることが求められていました。一方、当時の GPU モデルは容量が大きく、1 つの VM に複数モデルを載せるのは現実的ではないという物理制約もありました。そこで、この両方の要件を満たすために、モデルごとに VM を分け、Pub/Sub のメッセージ流量で水平にスケールさせる構成にしています。事業要求と物理制約を先に見込んで Pub/Sub の境界を作り込んだおかげで、その後モデルが増え続けても、基本的にこの境界は触らずに済みました。」（瓜生氏）

（2024 年 1 月全社展開に向けたリアーキテクチャ）

アプリケーション層では、異なるアプローチが採られています。2024 年 6 月には「2 週間に 1 つ、新しいモデルを提供する」という目標を設定。常に新しい生成 AI を試せること自体を価値と捉えて過度な共通化を避け、推論ワーカーのテンプレート化やコピーも意図的に許容しました。これにより、次々に登場する新たなモデルに迅速に対応することが可能になりました。瓜生氏は、わずか 3 年で 30 を超えるモデルを導入できたのも、この判断があったからだと言います。

「ただし緩めたのは実装の部分だけで、アーキテクチャ設計とデータ設計は守りました。何でも緩めたのではなく、緩める粒度を選んだというのが正確な表現だと思います。」（瓜生氏）

（2024 年 7 月〜 Stable Image Core / Ultra で初の API 連携での生成 AI モデル導入）

エージェント化によって営業メンバーもクリエイティブ制作の担い手に

次の転機となったのが AI エージェント機能の追加です。もともと社内では 2024 年 6 月頃から、クリエイティブ制作をエージェンティックにできないかという要望がありました。これを受けて 2025 年 3 月に検証が開始され、翌 4 月には、Google がリリースしたオープンソースのエージェント開発フレームワーク「Agent Development Kit（ADK）」の採用を決定。そのわずか 3 か月後の 2025 年 7 月に、エージェント基盤をリリースしています。

「ADK を選んだ理由は 3 つあります。オープンソースかつ Google の長期サポートが見込めること、Agent2Agent（A2A）プロトコルというエージェント間連携の仕組みが設計に組み込まれていること、そして Google Cloud のマネージドサービスと親和性が高いことです。」（瓜生氏）

短期間でのリリースを可能にしたのは、新規構築と既存資産の見極めでした。エージェント基盤そのものは ADK、Cloud Run、PostgreSQL で別アプリケーションとしてゼロから設計したのに対し、画像生成については既存基盤をそのまま呼び出す形にしたのです。現在稼働する主なエージェントは、プロンプトから画像を生成する「画像生成」、画像内のテキストを差し替える「ブラッシュアップ」、LP（ランディングページ）や参考画像をもとに広告バナーを作る「バナー生成」、アスペクト比に合わせてレイアウトを組み替える「リサイズ」の 4 種類。これらはすでに現場での活用が進んでいます。

「2026 年 4 月にはエージェント機能を用いて約 1 万枚の広告クリエイティブが生成され、そのうち約 20% にあたる約 2,000 枚が実用候補としてダウンロードされました。従来、生成機能のダウンロード率は 7～8% 程度だったので、予想以上の数字だったと言えるでしょう。利用の拡大は、用途が明確なリサイズ機能に牽引されている面もありますが、バナー生成単体でもダウンロード率は 10% 弱となっています。素材生成が中心だった従来の生成機能より、バナー生成やリサイズなど制作工程をより先まで進められるエージェント機能の方が、ダウンロードにつながりやすい傾向が見られます。」（瓜生氏）

エージェント機能の提供開始により、営業担当者が自らバナーを制作し、それを叩き台に広告主企業とすり合わせたりするといった事例も生まれ始めました。まだ制作・外注コストの削減効果までは確認できていないものの、生成 AI の利用者をクリエイター以外の職種にも広げられたことは、エージェント化がもたらした大きな成果と言えます。

（アーキテクチャ全体像）

より対話的な体験を追求、そして社外への展開も開始

2 度の大きなアップデートで実用性を高め、サイバーエージェント社内に根付いた AI SCREAM。2025 年 2 月から 2026 年 6 月までの間に生成された成果物は累計 160 万点を超え、制作時間は従来比で約 3 割も短縮されています。瓜生氏はその実績を踏まえたうえで、これから AI SCREAM が目指すのは、エージェントをむやみに増やすことではなく、さらに品質を高め、実際の制作業務のニーズに応えていくことだと説明します。

「たとえばクライアント様のロゴや商品画像は原則として改変してはならない要素です。守るべきところはしっかりと守った上で、それ以外の部分を生成 AI で加工し、バナーとして成立させていく取り組みを進めています。」（瓜生氏）

そしてもう 1 つ、今後の AI SCREAM の進化の軸として検討されているのが、より対話的な制作体験の実現です。現在のバナー生成は、制作に必要な情報をフォームに入力すると生成結果が返ってくる仕組みで、その後も AI と継続的に対話しながら、制作を進める仕組みにはなっていません。しかし実際の制作現場では、関係者とのやり取りのなかでバナーの方向性を固め、フィードバックを受けて修正を重ねながら仕上げていくプロセスです。瓜生氏は、AI とやり取りを重ねながら仕上げていく体験に近づけることで、AI SCREAM の「次」が見えてくるのではないかと語ります。

「エージェントのランタイムやセッションサービスなど、今後実現したい制作体験に必要となる機能は、Google Cloud にすでに揃っていると考えています。今後はこれらを上手に活用しながら、AI SCREAM をより良いものにアップデートしていきたいですね。Google Cloud には今後も、より高精度な画像生成・動画生成モデルの提供を期待しています。」（瓜生氏）

サイバーエージェントは、こうして社内で磨き上げてきた AI SCREAM の企業向け提供を、2026 年 8 月に開始しました。AI クリエイティブ BPO 事業の専門チームが、導入から運用定着、制作体制の構築まで一貫して伴走するなど、大規模な SaaS として一気に利用拡大を図るのではなく、顧客とコミュニケーションを取りながら丁寧に展開していく方針を打ち出しています。

株式会社サイバーエージェント
「21 世紀を代表する会社を創る」をビジョンに掲げ、1998 年に設立。国内最大級のインターネット広告代理事業をはじめ、メディア & IP 事業、ゲーム事業を主軸とした多岐にわたる事業を展開している。従業員数は 8,878 名（連結子会社含む。2026 年 6 月時点）。

インタビュイー
AI クリエイティブカンパニー
AI SCREAM 開発責任者
瓜生和也氏

▼ セッション動画を観る
本事例のインタビュイーによるセッション動画が公開中です。あわせてご覧ください。
【Next Tokyo 26 セッション】SDXL から AI エージェントへ: クリエイティブ AI プラットフォーム 3 年間の設計判断

▼他の導入事例記事を読む

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

「MCP ツールボックス」Java SDK v1.0 のご紹介: 企業向けのエージェント型データアクセス

Fri, 23 Oct 2026 02:00:00 +0000

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

MCP ツールボックス v1.0 の画期的な発表に続き、「MCP ツールボックス」Java SDK バージョン 1.0 が正式にリリースされたことをお知らせいたします。

このリリースにより、世界で最も広く採用されているエンタープライズ向けエコシステムの一つで、最高水準の型安全なエージェントオーケストレーションが実現します。Java の成熟したアーキテクチャは、厳しい要求に対応できるよう構築されており、本番環境でミッションクリティカルな AI エージェントを安全にスケールするために必要な高い同時実行性、厳格なトランザクション整合性、堅牢な状態管理を提供します。

この投稿では、Java SDK v1.0 の新機能について説明し、実際の例を示しながら、独自の実装を始めるためのステップを解説します。

MCP: ユニバーサルインターフェース

現在、デベロッパーは複雑化する統合のボトルネックに直面しています。N 個の異なる AI モデルと M 個のエンタープライズデータソースがある場合、N × M 個のカスタム接続を構築、保護、維持する必要があります。このように統一されたインテグレーションレイヤがないため、エンジニアリングチームは、断片化されたアドホックなパイプラインが複雑に入り組んだ状態に頼らざるを得ません。その結果、エージェントアーキテクチャのスケーリングはすぐに持続不可能になり、機密性の高いエンタープライズデータベースが深刻なセキュリティ脆弱性、断片化されたアクセス制御、膨大なメンテナンスオーバーヘッドにさらされることになります。

Model Context Protocol（MCP）が解決する根本的な課題は、複雑に絡み合った独自のインテグレーションを解消することです。MCP は、AI オーケストレーションの「USB Type-C」のようなユニバーサルインターフェースとして機能し、モデルをデータソースから分離します。デベロッパーは、新しいモデルやデータベースごとにカスタムまたはマネージド API 統合コードを記述する代わりに、単一の標準化されたプロトコルに準拠してコードを記述します。このアプローチにより、MCP 準拠のエージェントは、MCP 対応のシステムとセキュアかつ即座にやり取りできます。MCP 接続により、デベロッパーは新しいモデルごとに個別のインテグレーションを構築することなく、エージェントを実世界のシステムに接続できます。

Java SDK v1.0 の新機能: 本番環境ワークロードに対応

「MCP ツールボックス」Java SDK の公開ベータ版を発表した際、Google の目標は、最高水準の型安全なエージェントオーケストレーションをエンタープライズ Java 環境に提供することでした。それ以来、Google はデベロッパーやオープンソースのコントリビューターと協力して API の堅牢化に努めてきました。

v1.0 リリースは、エンタープライズワークロードに適した、安定した後方互換性を備えた基盤となります。v0.2 リリース以降の新機能と堅牢化された機能は次のとおりです。

トランスポート層の抽象化と HttpMcpTransport: HttpMcpTransport とともに、クリーンなトランスポート層の抽象化を導入しました。この機能により、コアプロトコルロジックが基盤となる HTTP クライアントから分離されるため、ネットワーク実装の入れ替えや接続プールのカスタマイズが容易になります。
クライアント認証の疎結合化: 企業のセキュリティコンプライアンスを簡素化するため、CredentialsProvider クラスと AuthMethods クラスを使用してクライアント認証を切り離しました。認証情報はリクエストごとに非同期で解決されるため、チームはトークンを動的に更新したり、独自のトークンソースをプラグインしたりできます（ADC 経由の Google OIDC は標準で組み込まれており、それ以外は 1 つのメソッドを実装するだけのインターフェースです）。
デフォルトパラメータのサポート: ツールパラメータのデフォルト値をネイティブにサポートすることで、プロンプトのペイロードサイズを削減し、エージェントの信頼性を高めます。
バインドされたパラメータのプルーニング: サーバーサイドでバインドされた機密性の高いパラメータ（tenant_id など）が、公開されたツール定義から自動的に削除されるようになり、LLM による操作を防ぎます。
バージョン選択とセッショントラッキング: 標準化された MCP バージョン選択と堅牢なセッショントラッキングにより、一貫したプロトコルネゴシエーションと会話状態のライフサイクルを実現します。
HTTP 認証情報の漏洩に関する警告: 認証情報が平文の HTTP 接続で送信されようとしているときに、実行時に警告を発する組み込みの検出機能を追加しました。
汎用クライアントヘッダーのマップ: カスタムの企業プロキシヘッダー、トランザクショントレース ID、相関メタデータを、すべての送信リクエストに簡単に追加できます。

Java SDK v1.0 を使ってみる

「MCP ツールボックス」Java SDK は、企業チームがスムーズに利用できるように設計されています。pom.xml に次の依存関係を追加するだけで利用を開始できます。

code_block: <ListValue: [StructValue([('code', '<dependency>\r\n <groupId>com.google.cloud.mcp</groupId>\r\n <artifactId>mcp-toolbox-sdk-java</artifactId>\r\n <version>1.0.0</version>\r\n</dependency>'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fac24a73dd0>)])]>

実際の例: 自律型交通コンシェルジュ

Java SDK を AlloyDB と組み合わせて活用する例として、企業のユースケースを見てみましょう。

架空の都市間バス交通ネットワークである Cymbal Transit をご紹介します。利用者は、旅行を計画するのに、ネストされたプルダウンメニューを何度もクリックするような操作は望んでいません。次のように質問したいと考えています。

「明日の朝、ニューヨークからボストンまで移動する必要がある。ゴールデンレトリバーを連れて行くことはできる？連れて行ける場合は、最も早い便を予約して。」

AI エージェントがこの質問に答えるには、非構造化データ（ペットに関するポリシー）と構造化データ（運行スケジュール、座席の空き状況）を相互参照し、会話のコンテキストを維持しながらトランザクションを実行（予約）する必要があります。

基盤: ネイティブエンベディングを備えた AlloyDB スキーマ

この実装には、リレーショナルデータと高次元ベクトルをネイティブに処理できる AlloyDB を使用しました。そして、次のステートメントを使用してデータベーステーブルを作成しました。

code_block: <ListValue: [StructValue([('code', "-- Enable necessary extensions for semantic search and embeddings\r\nCREATE EXTENSION IF NOT EXISTS vector;\r\nCREATE EXTENSION IF NOT EXISTS google_ml_integration;\r\n\r\n-- Table 1: Transit Policies (Unstructured Data for RAG)\r\nCREATE TABLE transit_policies (\r\n policy_id SERIAL PRIMARY KEY,\r\n category VARCHAR(50),\r\n policy_text TEXT,\r\n policy_embedding vector(768)\r\n);\r\n\r\n-- Table 2: Intercity Bus Schedules (Structured Data)\r\nCREATE TABLE bus_schedules (\r\n trip_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),\r\n origin_city VARCHAR(100),\r\n destination_city VARCHAR(100),\r\n departure_time TIMESTAMP,\r\n arrival_time TIMESTAMP,\r\n available_seats INT DEFAULT 50,\r\n ticket_price DECIMAL(6,2)\r\n);\r\n\r\n-- Table 3: Booking Ledger (Transactional Action Data)\r\nCREATE TABLE bookings (\r\n booking_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),\r\n trip_id UUID REFERENCES bus_schedules(trip_id),\r\n passenger_id VARCHAR(100),\r\n status VARCHAR(20) DEFAULT 'CONFIRMED',\r\n booking_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP\r\n);"), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7fac24a71c50>)])]>

インテントと SQL のマッピング: `tools.yaml`

MCP ツールボックスを使用すると、カスタムツールをセキュアに定義できます。LLM にデータベースへの直接アクセスを許可するのではなく、tools.yaml の設定によって、自然言語のインテントをパラメータ化された安全なクエリに直接マッピングします。

code_block: <ListValue: [StructValue([('code', 'kind: source\r\nname: alloydb\r\ntype: alloydb-postgres\r\nproject: my-project\r\nregion: us-central1\r\ncluster: my-cluster\r\ninstance: my-instance\r\ndatabase: postgres\r\n---\r\nkind: tool\r\nname: query-schedules\r\ntype: postgres-sql\r\nsource: alloydb\r\ndescription: Find available bus schedules between cities.\r\nparameters:\r\n - name: origin\r\n type: string\r\n description: The departure city name.\r\n - name: destination\r\n type: string\r\n description: The arrival city name.\r\n - name: limit\r\n type: integer\r\n description: Maximum number of schedules to return.\r\n default: 5\r\nstatement: |\r\n SELECT CAST(trip_id AS TEXT) AS trip_id, departure_time, ticket_price\r\n FROM bus_schedules\r\n WHERE lower(origin_city) = lower($1) AND lower(destination_city) = lower($2)\r\n ORDER BY departure_time ASC\r\n LIMIT $3'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fac24a72890>)])]>

完全な YAML ファイルについては、mcp-toolbox-sdk-java リポジトリの tools.yaml ファイルをご覧ください。

Spring Boot のステートフルエージェントアーキテクチャ

エンタープライズアプリケーションで会話型 AI を構築するうえで最も難しいのは、状態の管理です。ユーザーが「空席がある便の出発時間は？」と尋ねた後、「午前 8 時の便を予約して」と言った場合、エージェントはターンをまたいで前のコンテキストを覚えておく必要があります。

「MCP ツールボックス」Java SDK を Spring Boot および LangChain4j と併せて使用すると、HTTP セッションで会話のメモリを適切に維持し、エージェントを次の 2 つの宣言型コンポーネントに明確に分離できます。

HTTP セッションを介してプロンプト、ツール、会話のメモリを管理する宣言型エージェントインターフェース。
エージェントのリクエストを MCP ツールボックスサーバーに直接ルーティングするツール実行サービス。

code_block: <ListValue: [StructValue([('code', 'interface TransitAgent {\r\n @SystemMessage({\r\n "You are the Cymbal Transit Concierge.",\r\n "Use the \'querySchedules\' tool for finding schedules.",\r\n "Use \'bookTicket\' to execute transactions.",\r\n "Use \'searchPolicies\' to look up luggage and pet rules."\r\n })\r\n String chat(@MemoryId String sessionId, @UserMessage String userMessage);\r\n}\r\n\r\n@Service\r\nclass TransitAgentTools {\r\n // These methods automatically invoke our MCP Toolbox server!\r\n @Tool("Query specific schedules between an origin and destination city.")\r\n public String querySchedules(String origin, String destination) { ... }\r\n\r\n @Tool("Book a ticket for a passenger.")\r\n public String bookTicket(String tripId, String passengerName) { ... }\r\n\r\n @Tool("Search transit policies for luggage and pet rules.")\r\n public String searchPolicies(String query) { ... }\r\n}'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fac24a71e90>)])]>

@MemoryId アノテーションがセッショントラッキングを抽象化している点に注目してください。これにより、Spring Boot は会話のコンテキストをユーザーの HTTP セッションに自動的に関連付けることができます。その一方で、LangChain4j と MCP ツールボックスが舞台裏でスキーマ変換とツールルーティングを処理するため、手動で if/else 文によるインテント解析を書く必要はありません。

「MCP ツールボックス」Java SDK と LangChain4j を組み合わせることで、関心の分離を明確にし、手間をかけずに状態を管理できるようになります。

ボイラープレート不要のセッション管理: @MemoryId String sessionId パラメータにより、会話履歴がユーザーの HTTP セッションに直接バインドされます。
宣言型エージェントコントラクト: TransitAgent インターフェースは、複雑なプロンプトテンプレートを使用せずに、モデルのペルソナとシステム指示を定義します。
型安全なツールの実行: TransitAgentTools Spring サービスが、リモート MCP データベースツールをネイティブ Java メソッドとしてラップします。

このアーキテクチャにより、エージェントのモジュール性を保つことができます。インターフェースでプロンプトガイダンスを改良し、ユーザーセッションを自動的に管理しながら、密結合させることなく MCP ツールボックスを介して安セキュアなデータベースクエリを実行できます。

すべてをつなぎ合わせる: Java v1.0 におけるツールのリスト表示、呼び出し、実行

次に、TransitAgentTools インターフェースの内部を見てみましょう。Spring @Service の LangChain4j @Tool メソッド内では、MCP ツールボックス Java SDK が、Java サービスメソッドを tools.yaml ファイルで定義された MCP ツールに橋渡しするという複雑な処理を肩代わりします。型安全なコードを数行記述するだけで、新しい v1.0 の疎結合な認証情報とヘッダーの抽象化を使用してクライアントを初期化できます。

code_block: <ListValue: [StructValue([('code', '// 1. Initialize the Client with Decoupled Auth and Custom Headers (v1.0)\r\nString serviceUrl = "https://toolbox-my-project-uc.a.run.app/mcp";\r\nMcpToolboxClient mcpClient = McpToolboxClient.builder()\r\n .baseUrl(serviceUrl)\r\n .credentialsProvider(new GoogleCredentialsProvider(serviceUrl)) // Decoupled OIDC credentials\r\n .headers(Map.of( // Generic client headers\r\n "X-Correlation-ID", "enterprise-session-abc123",\r\n "X-Client-Platform", "Spring-Boot"\r\n ))\r\n .build();\r\n\r\n// 2. Listing Discoverable Tools\r\nmcpClient.listTools().thenAccept(tools -> {\r\n System.out.println("Successfully discovered " + tools.size() + " tools.");\r\n});\r\n\r\n// 3. Invoking a Tool (Read-Only Data with Default Parameter Support)\r\n// "limit" is omitted: the SDK fills it from the default in the tool definition\r\nString schedules = mcpClient.loadTool("query-schedules")\r\n .thenCompose(tool -> tool.execute(Map.of(\r\n "origin", "New York",\r\n "destination", "Boston")))\r\n .join().text();\r\n\r\n// 4. Executing a Transactional Tool (Using Bound Parameters)\r\nAuthTokenGetter toolAuthGetter = () -> CompletableFuture.completedFuture(myIdToken);\r\n\r\nString bookingConfirmation = mcpClient.loadTool("book-ticket", Map.of("google_auth", toolAuthGetter))\r\n // Bind the authenticated user context securely. bindParam returns a new immutable\r\n // Tool, and the bound parameter is pruned from the definition exposed to the LLM!\r\n .thenCompose(tool -> tool.bindParam("passenger_name", "Jane Doe")\r\n // Execute the mutable transaction\r\n .execute(Map.of("trip_id", "123e4567-e89b-12d3-a456-426614174000")))\r\n .join().text();'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fac24a71c90>)])]>

セキュアバイデフォルト: 認証とデプロイ

AI エージェントを本番環境に移行するには、堅牢な認証情報処理と、需要に応じてスケールするインフラストラクチャが必要です。さまざまな環境で認証情報の安全性を確保し、Cloud Run に独立してデプロイする方法を見ていきましょう。

アプリケーションのデフォルト認証情報（ADC）と安全性

GoogleCredentialsProvider サービスを使用すると、Java アプリはアプリケーションのデフォルト認証情報（ADC）を介して、実行環境（ローカルまたは Google Cloud）から安全な ID を継承します。ハードコードされた鍵は不要で、OIDC トークンがオーディエンスごとにバックグラウンドで生成され、キャッシュに保存されます。さらに、v1.0 では HTTP 認証情報の漏洩警告が提供されます。これは、認証情報が平文の HTTP 接続で送信されようとしていることを自動的に検出し、HTTPS に切り替えるよう指示するランタイム警告を発します。

フリートを Cloud Run にデプロイ

MCP ツールボックスと Spring Boot エージェントは完全に疎結合化されているため、Google Cloud Run で独立してスケールし、高い同時実行性とステートフルな会話の要件に対応できます。

Cloud Run でツールボックスをセットアップして構成するには、オープンソースのデータベース向け MCP ツールボックスをダウンロードしてから、デプロイガイドに沿って操作します。

使ってみる

「MCP ツールボックス」Java SDK v1.0 を使用すると、企業の Java チームは Spring Boot と LangChain4j エージェントをツールボックスサーバーに接続し、そこから AlloyDB やその他のサポートされているデータソースに接続できます。ツールボックスを使用すると、引数は JVM から送信される前にツール定義に照らして検証され、認証は疎結合化され、カスタムヘッダーがすべての送信リクエストに添付されます。導入手順は次のとおりです。

ステップ 1: 依存関係を追加する

SDK を使用して開発を始めるには、Maven プロジェクトの pom.xml ファイルに次の依存関係を追加します。

code_block: <ListValue: [StructValue([('code', '<dependency>\r\n <groupId>com.google.cloud.mcp</groupId>\r\n <artifactId>mcp-toolbox-sdk-java</artifactId>\r\n <version>1.0.0</version>\r\n \r\n </dependency>'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fac24a71390>)])]>

ステップ 2: リソースとデモを確認する

GitHub リポジトリ: データベース向け MCP ツールボックスを操作するための Java SDK
公式ドキュメント: MCP Toolbox for Databases（データベース向け MCP ツールボックス）

デモアプリケーション:「MCP ツールボックス」Java SDK V1.0 の最新版を体験するには、サンプルアプリケーションである Cymbal Transit プロジェクトをお試しください。

Gradle の実装

チームが Maven ではなく Gradle を使用している場合は、この依存関係を書き換える必要がある点にご注意ください。

code_block: <ListValue: [StructValue([('code', "implementation 'com.google.cloud.mcp:mcp-toolbox-sdk-java:1.0.0'"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fac24a70a90>)])]>

バージョンの自動追跡

この設定を自動化された内部リポジトリにコピーする場合は、XML コメント  はそのままにします。これは、リリースマネージャーのデプロイスクリプトがバージョンを自動的に更新するために必要です。

最新のエージェントツールとサーバーを、安定した「MCP ツールボックス」Java SDK を使用してエンタープライズ Java アプリケーションに統合できるようになりました。今すぐお試しください。

- Google、スタッフデベロッパーアドボケイト Abirami Sukumaran

共同執筆者:

- Google、戦略的クラウドエンジニア Stenal Jolly

- Google、ソフトウェアエンジニア Anubhav Dhawan

非構造化データワークフローのモダナイズ: Alteryx Live Query と Google Cloud BigQuery の連携

Fri, 23 Oct 2026 01:00:00 +0000

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

Alteryx One Live Query と Google Cloud BigQuery は、分断されたツールへの依存を減らし、データの移動を最小限に抑え、ウェアハウスネイティブの実行を可能にすることで、企業が複雑な非構造化データを大規模に処理する方法を一新します。

Live Query は、ビジネスユーザーがコードを 1 行も記述することなく高度なデータパイプラインを構築できる、直感的なブラウザベースの環境を提供します。BigQuery のスケールとパフォーマンスを組み合わせることで、安全な SQL プッシュダウンが可能になります。つまり、データ変換ロジックは、ネットワーク経由でデータを移動させることなく、ウェアハウス内で直接実行されます。この相乗効果は、ドキュメントを多用するワークフローで特に威力を発揮します。Live Query は、BigQuery 環境の厳格なデータガバナンスとセキュリティを維持しながら、Gemini などの Google の高度な AI および ML モデルをオーケストレートして、PDF や画像から情報を抽出できます。

請求書 PDF の処理から、Live Query を使用した BigQuery での例外レポート管理まで

財務チームやオペレーションチームは、ベンダーからの請求書の山に埋もれてしまうことがよくあります。これらのドキュメントは PDF 形式で届きますが、データに一貫性がなく、請求書番号の形式もさまざまであるため、手作業によるエラーが発生するリスクが高くなっています。従来、データチームは手動でデータを抽出するか、分断された複数のツールを使用してデータをウェアハウスに移す必要がありました。このプロセスには、時間がかかるだけでなく、データの重複や金額の不一致が発生しやすいという問題がありました。

Live Query for BigQuery のインテグレーションにより、請求書のライフサイクル全体を自動化できるようになりました。データチームは、BigQuery エコシステム内で直接、PDF の処理、主要なフィールドの抽出、結果の標準化を行うことにより、ドキュメント内の異常やデータの問題といった例外をより迅速に特定できると同時に、BigQuery のきめ細かなアクセスポリシーに基づいて構成、ガバナンス管理された企業データを、ウェアハウスの外部に転送する必要がなくなります。

ソリューションの概要: 抽出、分類、検証、ルーティング、計上

Live Query ソリューションの仕組みについて、さらに詳しく見ていきましょう。請求書 PDF は、非構造化ドキュメントとして Google Cloud Storage に届きます。Live Query ワークフローでは、ドキュメント抽出ツールが、ユーザーが選択したモデル（Gemini や Document AI など）を使用して構造化フィールドを抽出します。その後、結果は信頼性の高い照合が行えるよう標準化され、BigQuery にすでに格納、ガバナンス管理されている請求書の履歴レコードと照合されます。

この自動化されたワークフローは、手作業による介入を最小限に抑えながら、ドキュメントから意思決定へとスムーズに至れるよう設計されています。エンタープライズ規模では、このパターンは少数の PDF を処理するだけにとどまりません。照合ロジックを BigQuery と整合させながら、数百万件もの非構造化ドキュメントに対する分析や AI 活用を可能にします。

AI を活用した抽出と BigQuery ネイティブの実行を組み合わせることで、このソリューションは以下を実現します。

ストレートスルー処理の向上: 手作業を減らし、より多くの請求書を自動的に処理できるようにします。
照合の迅速化と手動例外の削減: 抽出した請求書をプロセスの早い段階で BigQuery データと照合することにより、チームは重複や不一致を早期に特定し、手動での確認が必要な請求書の数を減らすことができます。
監査可能性の強化: ソースから最終的な業務出力まで、データの明確な処理履歴を保持します。
データ移動の削減: データを BigQuery 内にとどめ、その組み込み機能を活用することで、セキュリティ、ガバナンス、管理機能を強化します。

アーキテクチャ: Google Cloud ネイティブパターン

大まかに言うと、請求書 PDF は Cloud Storage にステージングされ、ブラウザ上の Live Query ワークフローで処理された後、BigQuery にすでに格納、ガバナンス管理されている請求書履歴と照合され、ファイナンスチームの最終的な業務出力として書き戻されます。このパターンのアーキテクチャ上の主な利点は、ワークフローの作成をブラウザ上で行える一方、変換や照合のロジックは、プラットフォームサービスを通じて、ガバナンス管理されたデータ環境に対して実行されることです。

Live Query アーキテクチャは、ウェアハウス規模の処理とガバナンス管理された実行を目的として設計されています。安全な SQL プッシュダウンを使用して、変換と照合のロジックを BigQuery 内で直接実行し、Gemini と連携することで、ドキュメントの抽出、分類、要約といった高度な AI 機能を実現します。

Live Query（ブラウザ）: ユーザーはブラウザ上でワークフローを視覚的に作成し、ドキュメントの抽出、分類、クレンジング、検証、ルーティングのロジックを構成します。
Alteryx One Platform Services: 変換サービスは、ブラウザワークフローとお客様のデータ環境の間におけるリクエスト処理、実行計画、結果取得を調整します。また、これらのサービスにより、ワークフローの実行全体にわたるトレーサビリティとオブザーバビリティが向上し、運用モニタリングと監査可能性の両方が強化されます。
お客様の Google Cloud: 請求書 PDF は Google Cloud Storage（GCS）にステージングされ、請求書の履歴データは BigQuery でガバナンス管理された状態で保持されます。AI を活用した抽出はその環境に対して実行され、ワークフローの出力は BigQuery に書き戻されます。

このパターンでは、ブラウザがオーサリングレイヤ、Alteryx One Platform Services が調整レイヤ、Google Cloud がガバナンス管理されたデータおよび実行レイヤとなります。この構成により、Live Query でワークフローロジックを視覚的に作成しながら、BigQuery でガバナンス管理されたデータおよびウェアハウス規模の処理と連携して実行できます。

Live Query ワークフロー解説: PDF から分析情報まで

請求書を例に、Live Query ワークフローが非構造化 PDF をどのように処理するかを詳しく見ていきましょう。

請求書 PDF を取り込むワークフローは、未加工の PDF ファイルが格納されている Google Cloud Storage のディレクトリ入力を指定することから始まります。実際には、このステップではフォルダを特定するだけでなく、PDF の場所を列挙し、絶対ファイルパス、サイズ、作成 / 更新タイムスタンプといったファイルレベルのメタデータを返します。これにより、ワークフローは適切なドキュメントセットをダウンストリームの抽出ステップに確実に渡すことができます。

主要なフィールドを抽出するAlteryx の Document Extract ツールを使用して、ワークフローは Google Cloud Storage に格納されている PDF 請求書を処理し、構造化または半構造化された結果を BigQuery 内で直接抽出します。抽出ステップでは、ワークフローの構成に応じて、ユーザーが選択したモデル（Document AI または Gemini AI）が使用されます。このツールは、内部で入力ドキュメントの URI から一時的な外部オブジェクトテーブルを構築し、適切な関数（Document AI モデルの場合は ML.PROCESS_DOCUMENT、Gemini AI モデルの場合は AI.GENERATE）を実行します。このワークフローでは Gemini の処理ルートが使われており、AI.GENERATE がリクエストされた請求書フィールドをダウンストリームの Live Query ワークフローに返します。

インタラクティブな設計時、Live Query はプレビューのためにドキュメント URI のごく一部のみに処理を制限しますが、ランタイム実行ではすべての請求書 PDF を処理します。

code_block: <ListValue: [StructValue([('code', "-- illustrative pattern only\r\nSELECT *\r\nFROM AI.GENERATE(\r\n MODEL project.dataset.gemini_model,\r\n (\r\n SELECT\r\n uri,\r\n 'Extract invoice_number, invoice_amount, vendor_name, net_amount, tax_amount, and line_items.' AS prompt\r\n FROM project.dataset.temp_invoice_object_table\r\n )\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fac24cb65d0>)])]>

抽出されたデータの内容を分類する抽出後、ワークフローは Alteryx の Classify ツールを使用して、抽出された請求書テキストにゼロショット分類を適用します。このユースケースでは、BigQuery の AI.CLASSIFY を使用して、明細項目の内容を、工業用品や事務用品などの事前定義されたビジネスカテゴリに分類します。これにより、予測ラベルが新しい列としてダウンストリームワークフローに返されます。このビジネスコンテキストにより、抽出されたデータは、ダウンストリームでの照合、例外処理、レポート作成においてより有用なものとなります。

code_block: <ListValue: [StructValue([('code', "-- illustrative pattern only\r\nSELECT *,\r\n AI.CLASSIFY(line_item_text, categories => ['industrial', 'office']) AS line_item_classify\r\nFROM upstream"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fac25994e10>)])]>

データを正規化する抽出された請求書番号はクレンジングされ、標準化されます。これにより、空白文字や書式の不一致といった軽微な表記の違いによって照合中に重複の可能性が見落とされることがなくなります。

履歴と比較するワークフローは、正規化された現在の請求書レコードを、すでに BigQuery に格納されている請求書の履歴データと結合します。この照合ステップでは、履歴にすでに存在する請求書番号と一致するレコードを特定し、重複の可能性があるものとしてフラグを立てます。

例外にフラグを立てる次に、数式ステップで、残りのレコードにビジネスルールロジックを適用します。これらのルールはワークフローによって異なり、金額の不一致、必須フィールドの欠落、無効な合計額、その他の財務特有の例外に対するチェックなどが含まれます。この例では、1 つのルールで invoice_amount が net_amount + tax_amount と一致するかどうかを確認し、不一致があれば確認対象としてフラグを立てます。

業務出力を生成するこのワークフローでは 2 つの業務出力が生成されます。1 つは、履歴レコードと一致し、重複の可能性があるとしてフラグが立てられた請求書に関するものです。もう 1 つは、履歴と一致しなかった今回の請求書に関するもので、検証と必要に応じて例外のラベル付けが行われ、未払い請求書の処理に回されます。

その結果得られるのは、単に抽出されたデータにとどまらず、ファイナンスチームがすぐに確認して対応できる、ガバナンス管理された業務出力です。

まとめ: ドキュメントから意思決定まで、ガバナンス管理されたワークフロー

私たちの共通のお客様は、ビジネスプロセスの改善に役立つこれらの新機能に大きな期待を寄せています。

「Alteryx One: Google エディションで特に印象的だったのは、Google Cloud のエクスペリエンスに自然にフィットしている点です。ビジネスユーザーが直感的でガバナンス管理されたエクスペリエンスを通じて BigQuery データを操作できるようにすることで、分析をより身近なものにする機会が得られることを嬉しく思います。」 - Papa Johns、エンタープライズデータおよびコーポレートソリューション担当バイスプレジデント、Michael Wyant 氏

これは、単なる抽出ツールのユースケースにとどまりません。非構造化ドキュメントを実用的な業務出力に変換する、強力な Google Cloud ネイティブパターンを表しています。このワークフローは、分断された準備ツールにウェアハウスデータを移動するのではなく、ストレージ、抽出、照合、出力生成を、BigQuery にすでに格納されているガバナンス管理された企業データと整合させます。Alteryx One Live Query の直感的な設計と BigQuery のスケールおよび AI 機能を組み合わせることで、ファイナンスチームは手作業による負担を減らし、例外処理を迅速化して、より価値の高い戦略的な取り組みに注力できるようになります。

- Alteryx、シニアプロダクトマネージャー、Kira Droganova 氏

- Google、データ分析スペシャリスト、Rama Vundela

Gemini のイノベーションで、ボーダーレス Lakehouse をエージェントの時代へ導く

Fri, 23 Oct 2026 01:00:00 +0000

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

企業が AI の利用を試験運用的な chatbot から自律型エージェントへと移行するにつれ、チームは重大なボトルネックに直面しています。それは、複数のクラウド、SaaS プラットフォーム、オンプレミスシステムに分散したデータへのアクセスと、そのデータに基づく推論です。AI エージェントを真の「アクションシステム」に変えるには、データ移動に伴うセキュリティリスクを負うことなく、ペタバイト規模の推論を処理できる基盤が必要です。先週開催された Gemini at Work イベントでは、Gemini がビジネスワークフローの変革にどのように役立つかをご紹介しました。皆様がエンタープライズデータを活用してエージェントを強化できるよう、Gemini とボーダーレス Lakehouse の新たな連携について詳しく解説し、データ資産全体にわたって機能するエージェントの構築、保護、スケーリングを支援します。

Gemini を通じて Google Cloud の外部にあるデータにアクセスする

ボーダーレス Lakehouse の真価は、Gemini をフロントドアとして組織を変革するために構築するエージェントを通じて発揮されます。Gemini との新たな連携により、事前構成されたデータやボーダーレス Lakehouse に保存されたデータを、Gemini に直接取り込んで活用できるようになりました。現在プレビュー版として提供されているこの機能により、Gemini から直接、Lakehouse カタログ連携を通じて Databricks Unity Catalog や Snowflake Horizon などの新しいデータソースへのアクセスを設定できるようになります。

これで、ビジネスユーザーは自然言語を使ってクラウド全体に分散して存在するレコードをクエリできるようになり、AI エージェントは同じデータを根拠として推論を行い、コードを生成できるようになりました。これらはすべて、データを移動することなく実行できます。ボーダーレス Lakehouse 全体にわたり AI エージェントに直接コンテキストを提供することで、重要な情報へのアクセスを簡素化しながら、組織の AI 導入を加速させることができます。

ビジネスユーザーが呼び出した Gemini エージェントは、BigQuery と Databricks Unity Catalog に格納されているデータにアクセスし、包括的なレポートを提供するとともに、自然言語を使用して分析情報を取得できます。

ボーダーレス Lakehouse の進化

このたび、Gemini との新しいネイティブ連携に加えて、ボーダーレス Lakehouse でデータ基盤を強化するために今年初めに導入したいくつかの機能の一般提供が開始されたことをお知らせします。

AWS および Azure 向けの Cross-Cloud Interconnect とクロスクラウドキャッシュのサポート
BigQuery での Apache Iceberg V3 仕様のサポート
BigQuery と Managed Service for Apache Spark の両方における Apache Iceberg テーブルの読み取り / 書き込みの相互運用性
Lakehouse ランタイム連携を使用した、AWS Glue、Databricks Unity Catalog、Snowflake Horizon カタログとの双方向キャッシュ
Knowledge Catalog とのインテグレーション
Salesforce、SAP、Workday、そして新たに Confluent Tableflow とのゼロコピーデータ統合
Dataflow を使用した Lakehouse コンソール経由での Databricks Delta Lake アセットの同期

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

ペタバイト規模のパフォーマンスと推論

エージェントのコンテキストウィンドウは通常、一度に取り込めるデータ量が数百キロバイトに制限されていますが、エンタープライズワークフローでは、複数のクラウドにわたりペタバイト規模のデータを結合することがあります。製品データや顧客データといったさまざまなソースのデータを、CRM クラウドやウェアハウスのテレメトリーと結合する必要があるエージェントネイティブなデータプラットフォームは、大規模なデータ処理が可能でなければなりません。MCP を使用してこれを行う場合、コンテキストウィンドウとペイロードサイズの制約により、処理の規模がメガバイト単位に制限されます。ボーダーレス Lakehouse は、データと AI スタックをあらゆるレイヤで連携させることで、エンタープライズグレードのスケーラビリティを提供します。これにより、エージェントはペタバイト規模のデータをローカルに保存されている場合と同様のパフォーマンスで推論できます。

ネットワーキングレイヤでは、Cross-Cloud Interconnect とクロスクラウドキャッシュにより、AWS と Azure への高スループット、低レイテンシのパスが提供され、変動する外向きデータ送信料金が不要になります。エージェントが Amazon や Azure Data Lake Storage の Iceberg テーブルを BigQuery のデータと結合すると、スキャンするキャッシュ保存されていないバイトがすべてクラウドの境界を越えるため、ネットワークにより処理速度が決まります。Cross-Cloud Interconnect は、Google Cloud と AWS または Azure の間に、1 接続あたり 10 Gbps または 100 Gbps の専用プライベート接続を Lakehouse に提供します。Lakehouse のクエリは、パブリックインターネットではなく、この接続を介して送信されるため、低レイテンシの予測可能な状態が維持されます。また、クロスクラウドキャッシュは、Google Cloud 内から繰り返し行われる読み取り処理に対応するため、エージェントは他のクラウドのデータを移行することなく直接クエリできます。

ボーダーレス Lakehouse には、Iceberg メタデータをクエリエンジンに統合するための重要な最適化がいくつか盛り込まれています。BigQuery で、バイナリ削除ベクトルや並べ替え順など、Apache Iceberg V3 仕様がサポートされるようになりました。これらの機能により、データファイル全体を書き換える必要がなくなるため、エンジンは行レベルの更新や削除をより効率的に処理できるようになります。また、BigQuery の実行エンジンをアップグレードし、新しい FlatBuffers ベースの Parquet リーダーと並列化された I/O を導入しました。これにより、CPU オーバーヘッドやシリアル化によるボトルネックを軽減し、オープンフォーマットとネイティブストレージのパフォーマンスの差を縮めました。

これは、エージェントのワークロードをサポートするように設計されたクエリエンジンの最近のパフォーマンスイノベーションに基づいています。エージェントのワークロードは一斉に大量発生することが多く、小規模なクエリを迅速かつ費用対効果の高い方法で処理することが求められます。BigQuery の流動的なスケーリングと履歴ベースの最適化により、Apache Iceberg とのオープン性を維持しながら、スケーラブルかつ効率的なエージェントワークロードを実行できます。

一方、BigQuery と Managed Service for Apache Spark の両方で Apache Iceberg テーブルの読み取り / 書き込みの相互運用性が確保されているため、すべてのデータチームが Google Cloud Storage 内の同じ Iceberg テーブルを簡単に利用できます。この垂直方向に最適化されたスタックは、BigQuery と Lightning Engine の力を活用してデータを移動することなく有効化し、エージェントの高速化と費用対効果の向上を実現します。Lakehouse の分析能力をさらに拡張するため、BigQuery の Iceberg 向けグラフ機能のサポートにより、サプライチェーンなどの関係ネットワークをオープンテーブルデータセットで直接分析できるようになりました。

エージェント向けの包括的なコンテキストとデータアクセス

AI エージェントの能力は、アクセスできるコンテキストに左右されます。ハルシネーションを防止し、メタデータレイヤの精度を向上させるために、ボーダーレス Lakehouse は Lakehouse ランタイムカタログを使用してエンタープライズデータを統合します。Apache Iceberg REST カタログをベースに、AWS Glue、Databricks Unity Catalog、Snowflake Horizon Catalog との双方向のカタログ連携を実現します。Lakehouse ランタイムカタログには、新たな標準の Hive Metastore 互換エンドポイントも含まれており、Apache Spark、Trino、Presto などのエンジンがアーキテクチャを変更することなくメタデータを参照できます。

ボーダーレス Lakehouse は、分散したデータアセットを自動的にインデックス化する Knowledge Catalog とも直接連携しており、エージェントがエンタープライズコーパス全体（Cloud Storage 内の非構造化データを含む）を推論するために必要な、正確なビジネスメタデータとセマンティック定義を提供します。これにより、エージェントはトークン費用を抑えながら、正確性を確保するのに十分なコンテキストを得られるため、インテリジェントで持続可能なエージェント活用戦略を策定できます。

ボーダーレス Lakehouse は、Salesforce、SAP、Workday などの SaaS アプリケーションとのゼロコピーデータ統合を実現し、より広範なパートナーエコシステムと連携することにより、Knowledge Catalog を通じてエンタープライズデータをキャプチャし、エージェントのための単一のコンテキストエンジンとして機能します。このたび Google は、パートナーエコシステムを拡大し、Confluent Tableflow との新たな連携機能の一般提供を開始しました。これにより、Lakehouse ランタイムカタログと同期され、生成された Iceberg テーブルが BigQuery に直接表示されるようになります。コピーや追加の ETL は不要です。

最後に、Databricks 中心のリポジトリを持つ組織は、Lakehouse コンソール経由で Dataflow を使用して、Delta Lake アセットを Lakehouse に簡単にインポート、変換、同期できるようになりました。

モダナイゼーションを容易に

2025 年初頭以降、Apache Iceberg の利用は 3 倍以上に増加しており、Google Cloud のボーダーレス Lakehouse を使用してデータ基盤を構築している企業は、大きな成果を上げています。

Etsy: ボーダーレス Lakehouse を活用して、3 ペタバイトのデータを統合し、データを移動させずに結合することで、パイプラインクエリを 60% 高速化しました。
Commerzbank: 分散している生データを、ガバナンス管理されたエージェントがすぐにアクセスできるデータへと変換しています。
Hightouch: ボーダーレス Lakehouse と直接連携しているため、チームはオープンな Iceberg Lakehouse 上で直接マーケティング活動を強化し、Google Cloud エコシステム全体でそのデータを活用できます。
Roundel: ボーダーレス Lakehouse を活用して Target Product Ads の技術スタックを徹底的にモダナイズし、データの取り込み、処理、測定のパイプラインを完全に再構築しました。

組織でボーダーレス Lakehouse に移行する準備ができているなら、そのプロセスは難しくありません。現在、従来の Dataproc Metastore をご利用中の組織向けに、サーバーレス Lakehouse ランタイムカタログへの自動化されたダウンタイムゼロの移行パスが用意されています。これにより、既存のスキーマやリネージを維持したまま、ボーダーレス Lakehouse の AI 対応機能を活用できるようになります。その結果、インフラストラクチャの管理から解放され、エージェントの活用に注力できるようになります。

ボーダーレス Lakehouse 構築の Codelab を今すぐお試しください。詳細については、Google のウェブサイトをご覧ください。

- プロダクトマネジメント担当ディレクター、Gaurav Saxena

- エンジニアリング担当ディレクター、Ahmet Altay

あらゆるエンドポイントでセキュアかつインテリジェントなエクスペリエンスを実現

Fri, 23 Oct 2026 00:00:00 +0000

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

オフィスワーカーの働き方は長年にわたり、驚くほどに変わらないままでした。従業員はデバイスにログインし、ブラウザを開いて、相互に連携していない 10 種類以上ものアプリケーションを切り替えつつ作業を行います。この働き方においてユーザーは、タブ間で情報をコピー＆ペーストする、いわばアプリの橋渡しの役割を担ってきました。しかし現在では、より迅速で、従業員の生産性をさらに高めるエージェントワークフローが登場し、存在感を高めつつあります。このワークフローでは、得られる成果を従業員が主体的に設定し、自律型 AI エージェントが複数ステップのビジネスプロセスをエンドツーエンドで実行します。これによって冗長なタスクを手動で行う必要がなくなり、従業員はより複雑で戦略的な作業に集中することが可能になります。

したがって、従業員が使用するエンドポイントは、セキュリティを確保しつつ、この新しい働き方で生産性を向上させる最新のアプローチとアーキテクチャに対応できるものである必要があります。Google の企業向けブラウザ、オペレーティングシステム、ハードウェアはすべて、組み込みのコンテキストインテリジェンス、強力な AI モデル、ポリシーを適用するための柔軟な管理オプションによって統合されています。Google インテリジェントエンドポイントのコレクションはその全体にわたってセキュアなエンドユーザーコンピューティングソリューションを提供して、この進化した働き方をサポートします。インテリジェントエンドポイント戦略を実践することで、企業は従業員の生産性を変革し、セキュリティリスクを軽減し、エージェント型 AI の時代とその先に来るものに備えることができます。

日々のワークフローをスケールして時間を節約

Google のエンドユーザーコンピューティング戦略は、作業で通常使用されるプラットフォームやアプリにインテリジェンスを直接組み込んで生産性を大幅に向上させることを中核としており、そのため、ブラウザを重要なインテリジェントエンドポイントと考えています。

今年の初めに、Google は Chrome でブラウザにエージェント機能を直接組み込み、複数のタブにまたがる複雑なマルチステップのタスクをネイティブに自動化できるようにしました。CRM ツールでの見込み顧客の追跡から、Asana などのツールでのワークフローのオーケストレーションまで、ウェブ上のさまざまな場所で発生する繰り返しタスクをブラウザに組み込みのタスク自動化で処理できるため、従業員はその分の時間を取り戻すことができます。

ビジネスユーザーが繰り返しタスクの処理に Gemini in Chrome をさらに活用できるよう、企業向けスキルライブラリも新しく提供されています。また、IT チームは Trusted Tester プログラムを利用して、IT チームが検証した事前構成済みの AI スキルを専用ライブラリに直接公開できます。管理対象ユーザーはこのライブラリを、標準化された会社承認済みのワークフローを見つけてデプロイするための一元的なハブとして利用できます。これにより、従業員はプロンプトをゼロから作成しなくても、日常業務のサポートを簡単に得ることができます。

Gemini in Chrome の機能が、さらに多くの地域の企業や Google Workspace のお客様にご利用いただけるようになりました。全言語の一覧はこちらをご覧ください。

最新のセキュアなエンドポイントに移行しても、中核的なビジネスツールや既存のシステムが使えなくなることはありません。Chrome Enterprise Premium は、従来のアプリケーションにもシームレスでセキュリティの高い基盤を提供します。Google の Cameyo を使用すると、Chrome タブ内で従来のアプリケーションを直接ストリーミングして使用できます。

この強力な組み合わせにより、Chrome Enterprise Premium のブラウザベースのセキュリティ保護が従来のアプリに継承されるほか、Gemini in Chrome による生産性向上のための AI 機能やエージェント機能も利用可能になります。これにより古いツールに新しい命が吹き込まれ、従業員はブラウザを離れることなくそれらを活用できるようになります。

プロアクティブなセキュリティと可視性の強化

最近になって、新たな脅威ベクトルが出現しています。それは、従業員が業務を効率的に進めようとする中で、誤って機密データを一般公開 AI ツールに流出させてしまうことです。実際、労働者の約 80% が個人用の AI ツールを業務に利用しており、その半数以上が機密性の高い知的財産や企業データを一般公開システムに直接貼り付けたことがあるというレポートがあります*。Google インテリジェントエンドポイントは、オペレーティングシステム、ブラウザ、ユーザーの各レベルでデータを保護し、最新の脅威に対するスケーラビリティの高い防御を提供します。これにより、従業員の生産性を損なうことなく、組織のセキュリティをより強固に維持できます。

IT チームとセキュリティチームは、Chrome Enterprise Premium を使用して厳格できめ細かいデータ損失防止（DLP）ルールを適用し、ブラウザ内で扱われる企業データを保護できます。サードパーティのネイティブ LLM アプリケーションは、基本的なデータプライバシー設定はあっても、データの引き出しの防止に欠かせないアクティブな DLP 制御は備えていません。Chrome Enterprise Premium を使用しない場合、企業は複雑なセキュリティソリューションを導入せざるを得ず、しかも、そうしたソリューションでも管理対象外のデバイスや個人用デバイスをカバーできないことは珍しくありません。

まもなく、IT 部門はブラウザでのコピー操作をトリガーとして機密レコードのコピーを積極的に検出してブロックする DLP ルールをデプロイできるようになります。これにより、機密データをシステムのクリップボードにコピーすることさえ防止できます。さまざまな AI サービス全体で企業の知的財産を保護する必要性を考慮すると、この機能の重要性はさらに高まります。ファイルのダウンロード、貼り付けたコンテンツやスクリーンショットのブロックと共有など、ブラウザベースの DLP 機能の多くはモバイルデバイスでも使用できるようになっており、デバイス間のセキュリティギャップがさらに縮小されました。

また、Chrome Enterprise の生成 AI レポート機能も改善されました。IT チームとセキュリティチームは、ウェブ全体での AI と SaaS の使用状況を包括的にリアルタイムで確認できるのに加え、レポートから直接是正措置を講じることも可能です。IT チームは、高リスクなアプリへのアクセスのブロック、セキュリティポリシーの更新、会社が承認した別の AI へのリダイレクトなどを、数回クリックするだけで実施できます。

次世代デバイスで従業員を支援

Google インテリジェントエンドポイントは、従業員が次世代のワークロード向けに設計されたさまざまな最新デバイスを使って途切れることなく業務を進められるようにします。従業員が 1 日を通じてさまざまなデバイスで業務を行う中で、それらのエンドポイントデバイスはプロアクティブで一貫したエクスペリエンスのメリットを提供します。

Chromebook Plus は、管理対象デバイスで優れたパフォーマンスと統合された Gemini 機能をすでに提供しており、既存のワークフロー内でユーザーを支援します。これにより、従業員は作業中のアプリやファイル、タブから直接、手厚いサポートを受けることが可能です。また、Google は今週初め、最前線で開発や作業を行う方に最適なコンパニオンである Googlebook を発表しました。Googlebook は 10 月にリリースされ、2027 年後半にはエンタープライズ機能が追加される予定です。

Googlebook は、モバイルデバイスを含む Android エコシステム全体に、相互運用性によるさらに多くのメリットをもたらします。生産性を高め、シームレスな作業を可能にするデバイスには、最新の Google Pixel 11、Google Pixel 11 Pro、Google Pixel 11 Pro XL、Google Pixel 11 Pro Fold、Samsung Galaxy S26 Ultra、Samsung Galaxy Z Fold 8、Samsung Galaxy Z Fold 8 Ultra、Samsung Galaxy XCover7 Pro があります。Android Enterprise を使用すると、IT チームはこれらすべてのデバイスの AI 機能を管理して、会社を前進させつつ、データの安全性と保護を維持できます。

Android は、従業員が簡単にさまざまなタイプのデバイスで作業を行えるよう、マルチフォームファクタのラインナップを拡大させ続けています。Android XR プラットフォームを使えば、軽量なエンタープライズグレードのスマートヘッドセットや有線グラスは、従業員がどこにいても利用できるプライベートなマルチモニターワークステーションになります。IT 部門は、会社のスマートフォンやタブレットの管理に使用しているのと同じモバイルエンタープライズ管理機能を使用して、これらの空間コンピューティングデバイスをシームレスにプロビジョニング、保護、デプロイできます。Android Enterprise に関するその他のニュースについては、ブログをご覧ください。

インテリジェントエンドポイントは、人と人とのつながりもさらに深めます。Google Beam は Google AI を活用したリアルな 3D ビデオコミュニケーションプラットフォームです。従業員が同じ部屋にいるかのような没入感のある会議体験を提供し、地理的に分散したチームが距離を意識することなく話し合えるようにします。より多くの組織で仮想会議のエクスペリエンスを向上できるよう、幅広いパートナーネットワークを通じて、これらのデバイスが提供される国や地域は拡大を続けています。

Google インテリジェントエンドポイントの使用を開始する方法

Google インテリジェントエンドポイントの詳細は、複数の方法でご確認いただけます。

Google インテリジェントエンドポイントを形成する Google のプラットフォームとデバイスの連携について詳しくは、こちらをご覧ください。
今すぐの導入をお考えの場合は、Chrome Enterprise Premium の試用を開始して、ブラウザ内の高度な保護機能をご利用ください。
Lenovo Digital Workplace Solutions with Google は、職場全体を 1 つのセキュアなモジュール型ソリューションとして統合します。信頼できるパートナーに面倒な作業を任せることができるため、IT を簡素化し、自信を持って AI を管理しながら、自社のペースで拡張できます。

* Forbes の 2026 年の職場における「BYO AI」に関するレポート、および Airia のシャドー AI に関する統計レポート

- Android Enterprise、プロダクト＆エンジニアリング担当バイスプレジデント、David Still

- Chrome Enterprise およびセキュリティ、プロダクト管理ディレクター、Mark Berschadski

Cloud CISO の視点: CISO や政策立案者が PQC への準備を整えるのに役立つ Gemini Notebook の新しいノートブック

Thu, 22 Oct 2026 10:00:00 +0000

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

2026 年 10 月最初の投稿となる「Cloud CISO の視点」をご覧いただきありがとうございます。今回は、Stephanie Kiel がポスト量子暗号（PQC）に対する Google のアプローチの最新情報について説明し、CISO や経営幹部が組織の PQC への準備を整えるのに役立つ新しいツールをご紹介します。

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

aside_block: <ListValue: [StructValue([('title', 'Google Cloud で取締役向けの重要な情報を得る'), ('body', <wagtail.rich_text.RichText object at 0x7fac248b8f10>), ('btn_text', 'インサイトハブを見る'), ('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>)])]>

CISO や政策立案者が PQC への準備を整えるのに役立つ Gemini Notebook の新しいノートブック

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

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

ポスト量子暗号（PQC）は、セキュリティに関してこの 10 年間で最も緊急性の高い変化の一つであり、最も無視されやすいものでもあります。セキュリティリーダーや政策立案者にとって、この研究内容は、論文やエンジニアリングブログに散在しており、専門的で理解が難しいため、対応するのは困難な場合があります。

そこで、Google の PQC 研究、エンジニアリングブログ、移行ガイダンスを 1 か所にまとめた、Gemini Notebook の公開ノートブック「ポスト量子暗号への準備」をリリースします。質問したり、音声解説を聴いたり、フラッシュカードで理解度をテストしたりして、量子脅威についてすばやく理解を深めましょう。

PQC が今重要な理由

量子コンピューティングは、理論から現実へと急速に移行しています。Willow チップと Quantum Echoes アルゴリズムは、大きな進歩を遂げています。Google Research の推定によると、ECDLP-256 と RSA-2048 の暗号化（オンラインデータの多くを保護する公開鍵暗号スキーム）を破るには、それぞれ約 50 万個と 100 万個の不完全な量子コンピュータコンポーネント（ノイズの多い量子ビット）が必要になります。

そこで、Google の PQC 研究、エンジニアリングブログ、移行ガイダンスを 1 か所にまとめた、Gemini Notebook の公開ノートブック「ポスト量子暗号への準備」をリリースします。

この研究内容は、現在すでに私たちに影響を及ぼしており、昨今のオンラインセキュリティが、将来の量子コンピュータに対して、これまで考えられていたよりも脆弱であることを示しています。

Store Now, Decrypt Later 攻撃は、攻撃者が暗号化されたデータを盗み、十分に強力な量子コンピュータが実現するまで待ってから、そのデータを復号するものです。医療記録、財務データ、知的財産、政府機密など、長年機密情報として扱われてきたデータは、すでに危険にさらされています。

アーキテクチャ、量子アルゴリズム、量子誤り訂正の継続的な進歩により、将来の量子ハードウェアの要件は縮小しているため、デジタルロックのアップグレードを待つことは、現実的な選択肢ではありません。組織が時代の先を行くことができるよう、Google は 2029 年までに PQC に移行する計画を記した移行タイムラインを公開し、他社にも同様の検討を促しています。

テクノロジーの進歩に伴い、政策立案者は、重要インフラの所有者や運営者に、タイムラインの短縮を認識し、既存のリスク軽減計画に PQC への準備を組み込むよう促すことを検討する必要があります。また、政府が世界各国の政府関係者と連携して、標準開発への調和のとれたアプローチを推進し、耐量子に焦点を当てた政策や規制要件の構築に技術やセキュリティの専門家を関与させることも Google は推奨します。

Google の PQC に関する専門知識を 1 つのノートブックに

「ポスト量子暗号への準備」ノートブックは、Google が長年培ってきた専門知識を、誰でも利用できるインタラクティブな入門書にまとめたものです。量子時代、量子コンピューティングのブレークスルー（Willow、Quantum Echoes、表面コードエラー抑制など）、業界の PQC 標準、Google 独自のデプロイ、最新の研究を網羅する、厳選された Google のソースに基づいて作成されています。

このノートブックでは、以下のことができます。

Google のソースに基づく回答を得る。
ポッドキャスト形式の音声解説を聴く。
フラッシュカードで PQC の理解度を確認する。
量子脅威のインタラクティブで視覚的な図を確認する。
簡潔な概要ドキュメントを読む。

以下のプロンプトをお試しください

まずは、ノートブックに次のような質問をしてみましょう。

CISO 向け:「CISO は PQC への移行の最初の 90 日間で何を優先すべき？」
PQC について詳しく知らないユーザー向け:「Store Now, Decrypt Later についてわかりやすく説明して。」
デベロッパー向け:「Chrome でのハイブリッド ML-KEM 鍵交換はどのような仕組み？」

すべての生成 AI と同様に、ノートブックも間違えることがあるため、リンクされたソースと照らし合わせて回答を確認してください。

直面しているリスク

SHA-1 からの移行や TLS のアップグレードなど、過去の暗号移行には 10 年以上かかっています。ウェブトラフィック、ソフトウェアアップデート、デジタル ID、署名などのデジタル要素を保護するうえで公開鍵暗号が重要であることを考えると、暗号解読に適した量子コンピュータが利用可能になるまで移行を待つことは、重大なセキュリティリスクとなります。

CISO の方は、まず以下のことを行うことをおすすめします。

組織内で暗号化が脆弱な場所を把握する。
量子脅威のリスクが最も高いデータとシステムを特定して優先順位を付け、これらのリスクに対処するための計画を策定する。
PQC への移行がシステム全体に及ぼす影響を予測する。
Heartbleed などの過去の経験から得た教訓を活かして、セキュリティ計画に暗号アジリティを組み込む。

これらの推奨事項の詳細については、以前のブログ投稿をご覧ください。

セキュリティコミュニティ全体で、この移行が成功するには、暗号化専門チームを持つ組織だけでなく、誰もがこの知識にアクセスできる必要があります。

Google が PQC を実現している方法

Google は長年にわたって PQC をデプロイしてきました。注目すべき点は以下のとおりです。

Google はまた、Amazon Web Services、Cisco、IBM、NVIDIA などの業界リーダーとともに、Linux Foundation で Post-Quantum Cryptography Alliance（ポスト量子暗号アライアンス）を共同設立し、Open Quantum Safe などのオープンソースツールをサポートしています。

チーム独自の PQC ノートブックを作成する

組織のニーズに合わせて、PQC に関する Google の Gemini Notebook のノートブックと同様のリソースを作成する方法は次のとおりです。

信頼できるソースをキュレートします。まずは、信頼できる研究、標準、ガイダンスを絞り込みます。
中立的なプロンプトを作成します。出力がソースを根拠とするように、指示は事実に基づくものにしてください。
AI の免責条項とウェルカムメッセージを追加します。ノートブックの内容を読者に伝え、AI が間違える可能性があることを注意喚起します。
すべての出力を人間の目で確認します。共有する前に、専門家にすべてのアーティファクトをチェックしてもらいます。

今すぐ準備を始めましょう

量子移行はすでに始まっていますが、組織の準備を始めるにあたり 100 ページのホワイトペーパーを読む必要はありません。まずは脅威を理解し、次に暗号インベントリを評価して、移行ロードマップを構築します。

今すぐ Gemini Notebook の「ポスト量子暗号への準備」ノートブックを確認し、チームと共有しましょう。PQC に対する Google Cloud のアプローチについて詳しくは、専用の Google Cloud PQC リソースハブをご覧ください。

aside_block: <ListValue: [StructValue([('title', '新しいことを学ぶ'), ('body', <wagtail.rich_text.RichText object at 0x7fac258efbd0>), ('btn_text', '今すぐ見る'), ('href', 'https://www.youtube.com/watch?v=Wpo-5ke9uvQ'), ('image', <GAEImage: Cloud-CISO-Perspectives-logo-A>)])]>

その他の最新情報

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

マシンスピードの時代にビジネスのアジリティを確保する方法: 最新の脅威の状況について経営幹部が知っておくべきこと、セキュリティチームが取るべき対応、Google AI Threat Defense が役立つ理由について説明します。詳細はこちら。
Gemini 4 Argon が Google Cloud で利用可能に: Google の新しいフロンティアモデルである Gemini 4 Argon が、Google Cloud で誰でも利用できるようになります。防御側の優位性を高めるうえで、これがどのように役立つのかをご紹介します。詳細はこちら。
オンデバイス AI 向けの Android の次世代エンクレーブ: パーソナライズされたオンデバイス AI エクスペリエンスを実現する Android のエンクレーブアーキテクチャについて説明します。詳細はこちら。
Wiz Red Agent が、他のツールでは見逃されていた Fortune 500 企業のデータ漏洩を検出: Red Agent は、攻撃者の視点から、機密データを公開しているページを数分で発見しました。詳細はこちら。
最近の ccTLD レジストリのハイジャックに対する Chrome の対応: 最近発生した .gh、.sl、.as ccTLD ドメインのハイジャックを受け、Chrome は CRLSet を通じて不正な HTTPS 証明書を即座にブロックし、ユーザーを自動的に保護しました。詳細はこちら。
Wiz Blue Agent の視点: AWS と GitHub にわたるデータ盗難の調査: Blue Agent が AWS と GitHub にわたる証拠を追跡し、侵害された認証情報、盗まれたソースコード、カスタムのデータ引き出しツールを明らかにして、マルチプラットフォーム攻撃を数分で調査した方法をご覧ください。詳細はこちら。
Wiz AI SAST のご紹介: ユーザーを理解するアプリケーションセキュリティ: Wiz Research によって支援され、既存のセキュリティプログラムで運用化されている AI コードスキャナを使用して、複雑なビジネスロジックの欠陥を検出、検証、修正します。詳細はこちら。
Kubernetes サプライチェーンを保護する WizOS Helm チャートの導入: WizOS Helm チャートは、Kubernetes 向けに強化、署名された、CVE スキャン済みのチャートにより、隠れた CI / CD リスクやメンテナンスされていない依存関係を排除するのに役立ちます。詳細はこちら。
Wiz サービスカタログの新機能: よりスマートな検出、ガバナンス、サービスレベルのコンテキストにより、サービスカタログをより迅速に構築し、サービスコンテキストを最新の状態に保ち、クラウドのリスクからアカウンタビリティまでの明確な道筋をチームに提供できます。詳細はこちら。

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

aside_block: <ListValue: [StructValue([('title', 'Google Cloud CISO Community にご参加ください'), ('body', <wagtail.rich_text.RichText object at 0x7fac258eeb90>), ('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>)])]>

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

AI 時代の脆弱性の発見と悪用の傾向: 脆弱性の迅速な発見と悪用によるリスクの増大に対抗するには、優先順位がないパッチの一括適用から、脅威インテリジェンスに基づくトリアージに移行し、標的型のエッジ防御とエージェントによる自動修復を組み合わせる必要があります。詳細はこちら。
Citrix NetScaler ADC および Gateway アプライアンスの脆弱性のアクティブな悪用に対する防御: Mandiant Consulting と Google Threat Intelligence Group（GTIG）は、Citrix NetScaler ADC および NetScaler Gateway アプライアンスに影響を及ぼすゼロデイ脆弱性のエクスプロイトが実際に行われていることを確認しました。封じ込めと修復のガイダンスをご紹介します。詳細はこちら。
ShinyHunters、Oracle PeopleSoft を標的とした大規模な脆弱性悪用キャンペーンを再開: Mandiant と Google Threat Intelligence Group（GTIG）は、UNC6240（ShinyHunters）による CVE-2026-35273 の大規模な悪用キャンペーンの再開と、複数のセクターにわたる世界的な標的の拡大を確認しました。詳細はこちら。
コードパイプラインと CI / CD インフラストラクチャの堅牢化によるプロアクティブな防御: ソフトウェア開発ライフサイクル全体を通じて、現在進行形で悪用されている脅威ベクトル、サードパーティのリスク、およびアーキテクチャ上の脆弱性からソフトウェアサプライチェーンを保護するために設計された、ソフトウェア / プラットフォームアーキテクト向けの実践的なガイドラインをご覧ください。詳細はこちら。

今月公開されたその他の脅威インテリジェンス関連の記事については、Google Cloud 公式ブログをご覧ください。

注目の Google Cloud ポッドキャスト

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

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

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

Google Cloud がモデルの選択肢と柔軟性を拡充、OpenAI モデルを提供開始

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

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

Google Cloud は、選択肢の豊富さ、エンタープライズレベルのガバナンス、そして業界トップクラスのコストパフォーマンスで高く評価されてきました。このオープンで柔軟な基盤において重要となるのが、コスト、能力、パフォーマンスの最適なバランスを実現するために、お客様が選択したモデルやインフラストラクチャを横断して、エージェントティックなワークロードを柔軟に実行できるようにすることです。本日、 Google はこの基盤を拡張するために、Google Cloud のモデルガーデンにおいて OpenAI モデルの提供を開始したことを発表しました。

Google Cloud は、統合されたエンタープライズ AI プラットフォーム上で、200 以上のファーストパーティ、サードパーティ、およびオープンモデルに加え、3 つの主要クローズドソース LLM へのアクセスを提供するハイパースケールクラウドプロバイダーとなります。

あらゆるワークロードに最適なモデルを

現代のエンタープライズ AI において、すべてのタスクを単一のモデルに依存するのではなく、それぞれのワークロードに適したモデルを組み合わせることが不可欠です。OpenAI の最新モデルをモデルガーデンに組み込むことで、エンタープライズにおけるあらゆるワークロードに対応する幅広い選択肢を提供します。OpenAI モデルについて：

GPT-6 Astra: コーディング、コンピュータの操作、専門的なタスク、および科学研究にわたる、高度な要求を伴う業務向けに設計
GPT-6.1 Sol: エージェンティックコーディング、コンピュータ操作、専門的業務において、より低いコストで Astra に近いレベルの知能を実現
GPT-6 Luna: 大規模な日常業務に最適な高速かつ低コストモデル

お客様はこのプラットフォームを活用することで、アーキテクチャの制約や個別のベンダー契約に縛られることなく、パフォーマンス、レイテンシ、費用対効果に応じた最適なモデルを、あらゆるユースケースに合わせて動的に選択し、切り替えることができます。開発者は、モデルガーデン上の数百もの選択肢を活用して自由に開発を進められます。また、OpenAI モデルは Google Cloud Marketplace を通じて直接取引されるため、すべての利用実績が単一の Google Cloud の請求書にまとまり、既存のクラウドコミットメントの消化に充てられるほか、モデルプロバイダーを横断した Flexible Savings Plans（FSP）の対象としてもカウントされます。

組み込みのデータガバナンスとエンタープライズセキュリティ

生成 AI の規模を拡大するにあたり、コンプライアンスやセキュリティを犠牲にする必要はありません。Gemini プラットフォームはエンタープライズガバナンスを念頭に構築されており、現在、世界をリードする多くの組織から信頼を得ています。サードパーティや OpenAI のワークロードを実行する際にも、厳格なエンタープライズ基準を確実に満たすよう徹底しています。

厳格なデータ境界: お客様のプロンプト、コンテキスト、出力結果は、指定されたデータ境界内に完全に保持され、基盤モデルのトレーニングに使用されることは決してありません。また、データを保持しないゼロリテンションオプションも近日中に選択可能になる予定です。
分離されたアクセス境界: OpenAI モデルは、近日中に Confidential Compute 上に構築された専用の Google Cloud インフラストラクチャ上で動作するようになる予定です。すべてのクエリは堅牢化された独立ゲートウェイを経由してルーティングされるため、データ転送は Google Cloud の安全な環境内のみに留まり、サードパーティのモデルプロバイダーがお客様のクラウド環境に不正アクセスすることはありません。
統合された監査とアイデンティティ: エージェントおよびモデルとのすべてのやり取りは認証済みのアイデンティティの下で動作し、IT 管理者に対してエンドツーエンドの可視性、 VPC Service Controls による保護、およびエンタープライズ環境全体にわたる統合された監査ログを提供します。

今すぐはじめるには

Google Cloud のモデルガーデンでは、一部のエンタープライズ顧客を対象に、OpenAI の GPT-6 Astra、GPT-6.1 Sol、GPT-6 Luna モデルのプライベートプレビューの提供を開始しており、今後さらに提供範囲を拡大する予定です。本日より、お客様は Google の API を通じてこれらのモデルを活用した構築を行えるほか、ローカルの Codex CLI やデスクトップワークフローを Gemini プラットフォームに直接接続して推論を実行できます。ご関心のある方は、こちらのフォーム（英語）よりお申し込みください。

さらに近日中に、OpenAI モデルが、Google Cloud の Gemini for business および Google Antigravity に登場します。これにより、エンタープライズのお客様や開発者の皆様にモデルの選択肢、柔軟性、そして各タスクに最適なモデルを提供します。

-Michael Gerstenhaber, VP, Product Management, Gemini, Google Cloud

BigQuery で多変量時系列予測を行う TimesFM 3.0 のご紹介

Wed, 21 Oct 2026 17:00:00 +0000

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

概要

BigQuery に AI.FORECAST を使用したゼロショット時系列予測が導入されて以来（当初は TimesFM 2.0 を搭載し、後に TimesFM 2.5 にアップグレード）、カスタムモデルのトレーニングや管理を行うことなく、SQL で直接予測を生成できるようになりました。しかし、TimesFM 2.5 までは、これらの基盤モデルは単変量予測に限定されており、単一の時系列の履歴のみから将来の値を予測していました。実際には、現実世界の予測問題のほとんどは多変量であり、関連するターゲットと、天気、プロモーション、休日などの外部要因が組み合わさって将来の結果を形成します。

本日、BigQuery での TimesFM 3.0 プレビュー版のリリースをお知らせできることを嬉しく思います。Google Research が開発した TimesFM 3.0 は、3 億 3,000 万のパラメータを持つ最先端の基盤モデルで、BigQuery SQL 内で直接、組み込みの多変量時系列予測を実現できるように設計されています。TimesFM 3.0 は、GIFT-Eval、FEV-Bench、TIME という 3 つの主要な公開時系列リーダーボードすべてで 1 位を獲得しており、既存の基盤モデルと比較して、共変量予測タスクと多変量予測タスクの両方で最高のゼロショット精度を達成しています。

TimesFM 3.0 は、新しい多変量機能に加えて、AI.FORECAST による単変量予測と AI.DETECT_ANOMALIES による異常検出のドロップインアップグレードとしても機能します。既存のワークフローでも、model => 'TimesFM 3.0' を指定するだけで、向上したベンチマーク精度の恩恵をすぐに享受できます。

新機能: 多変量基盤モデリング

TimesFM 3.0 により、BigQuery では AI.FORECAST を通じて、使い慣れた SQL ワークフローにエンタープライズグレードの多変量モデリングを取り入れることができます。

機能	TimesFM 2.0 / 2.5	TimesFM 3.0
予測の範囲	単変量のみ	単変量と多変量
ターゲット列	単一のターゲット	単一または複数のターゲット
過去の値のみを含む共変量列	非対応	サポート対象
過去と未来の値を含む共変量列	非対応	サポート対象

BigQuery SQL を使用した多変量予測

これらの機能がどのように連携するかを確認するために、NYC Citi Bike の一般公開データセット（bigquery-public-data.new_york.citibike_trips）を使用して、7 日間の通勤（subscriber_trips）とレジャー（casual_trips）の自転車利用を予測してみましょう。

BigQuery は、多変量予測に単一テーブルの入力形式を使用します。この形式では、次の 2 つの行セットが結合されます。

過去の観測行: 開始時間（2016 年 1 月 1 日）から予測カットオフ日（2016 年 6 月 1 日）までのタイムスタンプ。ターゲット指標、過去の共変量、既知の将来の共変量がすべて入力されています。
将来のホライズン行: 7 日間の予測ホライズン（2016 年 6 月 1 日～2016 年 6 月 7 日）にわたるタイムスタンプ。既知の将来の共変量が入力され、ターゲット列と過去のみの共変量は NULL に設定されています。

code_block: <ListValue: [StructValue([('code', "WITH data AS (\r\n SELECT\r\n DATE(starttime) AS date,\r\n IF(MIN(starttime) < '2016-06-01', COUNTIF(usertype = 'Subscriber'), NULL) AS subscriber_trips,\r\n IF(MIN(starttime) < '2016-06-01', COUNTIF(usertype = 'Customer'), NULL) AS casual_trips,\r\n IF(MIN(starttime) < '2016-06-01', AVG(tripduration / 60.0), NULL) AS avg_duration_min,\r\n IF(EXTRACT(DAYOFWEEK FROM MIN(starttime)) IN (1, 7), 1.0, 0.0) AS is_weekend\r\n FROM `bigquery-public-data.new_york.citibike_trips`\r\n WHERE starttime >= '2016-01-01' AND starttime < '2016-06-08'\r\n GROUP BY date\r\n)\r\nSELECT\r\n *\r\nFROM\r\n AI.FORECAST(\r\n TABLE data,\r\n MODEL => 'TimesFM 3.0',\r\n TIMESTAMP_COL => 'date',\r\n TARGET_COLS => ['subscriber_trips', 'casual_trips'],\r\n PAST_COVARIATE_COLS => ['avg_duration_min'],\r\n FUTURE_COVARIATE_COLS => ['is_weekend']\r\n );"), ('language', 'lang-sql'), ('caption', <wagtail.rich_text.RichText object at 0x7fac25804510>)])]>

このクエリは、TimesFM 3.0 でサポートされている 3 つの多変量ディメンションを示しています。

相関するターゲット（target_cols）の予測: 利用者セグメントごとに個別のモデルを実行する代わりに、TARGET_COLS => ['subscriber_trips', 'casual_trips'] を渡すことで、1 回の呼び出しで両方の指標を同時に予測できます。TimesFM 3.0 は、通勤利用者とカジュアル利用者における系列間の動向（天候に対する共通の感度や、週末の利用パターンの違いなど）を捉えます。
過去の共変量（past_covariate_cols）の使用: 平均乗車時間（avg_duration_min）、過去の来店数、計画外のサービス中断など、一部のシグナルは過去にしか観測できず、事前に把握できません。PAST_COVARIATE_COLS => ['avg_duration_min'] を渡す（将来のホライズン行は NULL に設定）ことで、モデルに過去のコンテキストが提供されます。これにより、その特徴量の将来の値を必要とせずに、一時的な変動と根本的な傾向を区別できます。
将来の共変量（future_covariate_cols）の使用: 週末（is_weekend）、休日、予定されているプロモーションなど、その他の外部要因は、履歴ウィンドウと予測ホライズンの両方で事前に把握できます。FUTURE_COVARIATE_COLS => ['is_weekend']（2016 年 6 月 7 日までのすべての行に設定）を渡すことで、TimesFM 3.0 は今後のカレンダーイベントを直接反映して 7 日間の予測を行うことができます。

出力について

関数は、target_cols で指定された各ターゲット列の構造化された予測を返します。target_cols の列ごとに、AI.FORECAST はポイント予測（値）と、予測区間の下限および上限を含む構造体を返します。

日付	subscriber_trips.value	subscriber_trips.prediction_interval_lower_bound	subscriber_trips.prediction_interval_upper_bound	casual_trips.value	casual_trips.prediction_interval_lower_bound	casual_trips.prediction_interval_upper_bound	time_series_type	confidence_level	ai_forecast_status
2016-06-01 00:00:00 UTC	44699.64	32590.76	55723.44	4581.32	1727.91	9189.31	予測	0.95
2016-06-02 00:00:00 UTC	44611.75	30413.05	57209.19	4647.17	1466.23	10273.55	予測	0.95
2016-06-03 00:00:00 UTC	41379.15	26218.65	54940.09	5341.36	1568.23	11805.86	予測	0.95
2016-06-04 00:00:00 UTC	30164.34	14266.43	45075.92	9097.74	2558.27	18452.52	予測	0.95
2016-06-05 00:00:00 UTC	26727.27	10101.44	42239.33	8398.50	1692.15	17768.99	予測	0.95
2016-06-06 00:00:00 UTC	36713.84	19493.00	52679.59	4723.08	400.08	11710.73	予測	0.95
2016-06-07 00:00:00 UTC	39749.97	22157.42	56119.86	4180.97	95.70	10845.74	予測	0.95

BigQuery 会話型分析の TimesFM 3.0

BigQuery 会話型分析では、自然言語を使用して多変量予測を実行することもできます。同じ bigquery-public-data.new_york.citibike_trips データセットで、「2 か月間の過去のデータを使用して、2016 年 6 月 1 日から 7 日までの 1 日あたりの定期利用回数とカジュアル利用回数を予測してください。過去の共変量として平均利用時間、将来の共変量として週末インジケーターを使用してください」と依頼するだけです。会話型分析は、TimesFM 3.0 を使用して基盤となる AI.FORECAST クエリを自動的に生成して実行し、結果の要約、各ターゲットの予測区間を含むインタラクティブな予測グラフ、主要な予測分析情報を返します。

BigQuery 会話型分析で TimesFM 3.0 を使用した多変量予測。自然言語プロンプトから 7 日間の予測、インタラクティブなグラフ、分析情報を生成。

まとめと次のステップ

TimesFM 3.0 の多変量予測がネイティブサポートされたことで、BigQuery は、データの移動、カスタムの特徴量エンジニアリングパイプライン、専用のモデルホスティングインフラストラクチャを必要とすることなく、複雑で相互に関連するエンタープライズデータセットに対して最先端の基盤モデルによる予測機能を提供します。

BigQuery の TimesFM 3.0 で予測を開始するには:

TimesFM 3.0 モデルのアーキテクチャと機能の詳細について、Google Research のブログ投稿を読む。
BigQuery TimesFM のドキュメントを確認する。
多変量予測のチュートリアルの手順に沿って操作する。
BigQuery Studio SQL ワークスペースで `model => 'TimesFM 3.0'` を直接指定して AI.FORECAST を試す。
BigQuery で `model => 'TimesFM 3.0'` を指定して AI.DETECT_ANOMALIES を使用し、単変量時系列の異常検出を試す。
BigQuery で `model => 'TimesFM 3.0'` を指定して AI.EVALUATE を使用し、単変量時系列の評価を試す。

- ソフトウェアエンジニア、Haiyang Qi

- エンジニアリングマネージャー、Haoming Chen

BigQuery で AI 費用を予測可能に: 生成 AI 関数の費用管理のご紹介

Wed, 21 Oct 2026 17:00:00 +0000

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

BigQuery の生成 AI 関数（AI.GENERATE、AI.IF、AI.CLASSIFY、AI.SCORE など）では、大規模言語モデル（LLM）が SQL に直接組み込まれるため、1 つのクエリで数百万件のサポートチケットを分類したり、感情について各商品レビューにスコアを付けたりできます。ただし、これらの関数はトークン単位で課金されるため、大規模なデータセットで使用する場合は、予算を事前に管理することが重要になります。

Google は先日、BigQuery 生成 AI 関数のトークンベースの費用管理の一般提供（GA）が開始されたことを発表しました。これは、管理者が AI トークン消費にセルフサービスのガードレールを設定できる 1 日あたりの割り当てで、チームは予算内でイノベーションを推進できるようになります。このブログ投稿では、BigQuery の生成 AI 関数の費用管理の概要を示し、いくつかの実用的な例と、利用を開始する際に役立つリソースをご紹介します。それでは詳しく見ていきましょう。

費用を管理するための割り当て

Google Cloud Identity and Access Management（IAM）割り当てシステムで管理される 1 日あたりの割り当ては 4 種類あり、プロジェクト レベルおよびユーザーレベルでの管理が可能です。ユーザーごとの上限は、組織全体ではなく、プロジェクト内の各ユーザーに適用されます。

割り当て名	指標	範囲	デフォルト値
1 日あたりの AI 入力トークン数	LLM で使用される入力トークン数	1 日あたり、プロジェクトごと	2,000 億
ユーザーごとの 1 日あたりの AI 入力トークン数	LLM で使用される入力トークン数	1 日あたり、プロジェクトごと、ユーザーごと	1,500 億
1 日あたりの AI 出力トークン数	LLM で使用される出力トークン数と思考トークン数	1 日あたり、プロジェクトごと	200 億
ユーザーごとの 1 日あたりの AI 出力トークン数	LLM で使用される出力トークン数と思考トークン数	1 日あたり、プロジェクトごと、ユーザーごと	150 億

詳細:

割り当てはグローバルです。使用量はすべてのリージョンで合計されるため、監視していないリージョンで費用が気づかないうちに積み上がることはありません。
出力割り当てには「思考」トークンが含まれます。推論トークンは、Gemini プラットフォームの請求にカウントされるのと同様に、出力割り当てにカウントされます。

対象となる関数

割り当ては、LLM を利用した生成を行う以下の BigQuery 関数に適用されます。

AI.GENERATE
AI.GENERATE_TABLE
AI.GENERATE_TEXT（およびそのエイリアス ML.GENERATE_TEXT）
AI.CLASSIFY
AI.IF
AI.SCORE
AI.AGG

対象外: AI.GENERATE_EMBEDDING（ML.GENERATE_EMBEDDING としても利用可能）や AI.EMBED などのエンベディング関数は、大幅に費用が低い別のモデルで実行されるため、これらの割り当ての対象にはなりません。

割り当ての管理

管理者は、ワークロードの変化に応じて、Google Cloud コンソールで直接割り当てを確認、調整できます。サポートケースは必要ありません。

[IAM と管理] → [割り当てとシステム上限] に移動します。
サービスでフィルタし、[BigQuery API] を選択します。
[名前] 列で並べ替えて、4 つの AI 割り当てを一番上に表示します。

[IAM と管理] → [割り当てとシステム上限] で生成 AI トークンの割り当てを確認。

4. 割り当て（1 日あたりの AI 入力トークン数など）を見つけます。

5. その他メニューを開き、[割り当てを編集] を選択します。

次の操作を行います。

費用管理を厳しくするには、割り当てを減らします。これはすぐに有効になり、承認は必要ありません。
使用量の増大に対応するには、同じページから増加をリクエストします。多くのリクエストは自動的に承認されますが、大幅な増加の場合は簡単な審査が行われることがあります。

[IAM と管理] → [割り当てとシステム上限] で生成 AI トークンの割り当てを編集。

適切な権限が必要です。オーナー、編集者 、割り当て管理者（roles/servicemanagement.quotaAdmin）、Service Usage 管理者（roles/serviceusage.serviceUsageAdmin）のいずれかが必要です。

自動化をご希望の場合は、Cloud Quotas API、gcloud CLI、Terraform を使用してこれらの割り当てをプログラムで管理し、プロジェクト全体に一貫したガードレールを適用することもできます。

使用量のモニタリング

[割り当てとシステム上限] ページでは、上限を設定できるだけでなく、トークン消費量の履歴も表示されるため、急増をすばやく検出して予算を適正化できます。これらの傾向から、新しい生成 AI ワークロードとデータパイプラインがトークンの全体的な使用量に与える影響を確認できます。

[IAM と管理] > [割り当てとシステム上限] に表示された、生成 AI トークンの割り当てに対するプロジェクトレベルの 1 日あたりのトークン使用量。

7 日間、14 日間、30 日間、カスタムの期間を選択できる長期的な使用量グラフ。

詳しい手順については、トークン割り当てによる費用の管理に関する BigQuery のドキュメントをご覧ください。

トークン割り当てと費用上限

Google Cloud の費用ガードレールは、トークン割り当てだけではありません。

トークン割り当て（この機能）は、予防的で AI 固有のものです。BigQuery はクエリ実行中のトークン使用量を追跡し、上限に近づくと処理を停止します。上限はプロジェクトごと、ユーザーごとに個別に設定されます。
Cloud Billing の費用上限は、プロジェクトレベルとサービスレベルでドル単位で設定され、しきい値に達すると自動的に使用をブロックできます。これは、使用量を正確に管理するものではなく、財務上の広範な安全策です。また、適用が即座に行われないため、超過料金が発生する場合があります。

AI 費用の最初の防御策としてトークン割り当てを使用し、プロジェクト全体のセーフティネットとして費用上限を使用します。

適用の仕組み

割り当ては、上限を超えてクエリを実行するのではなく、処理を停止することで適用されます。クエリは、必要な割り当てがすでに使い果たされている場合にのみ、事前に拒否され、その際に QuotaExceeded エラーが発生します。それ以外の場合はクエリが開始され、クエリの途中で割り当てがなくなると、BigQuery は新しい LLM 呼び出しの送信を停止します。

max_error_ratio をサポートする関数（AI.IF など）は、未処理の行が比率内に収まっている場合は部分的な結果を返し、そうでない場合は失敗します。
汎用関数（AI.GENERATE など）は成功します。ただし、スキップされた行には生成された値がなく、status フィールドには割り当て超過エラーが含まれます。

詳細については、ドキュメントの割り当ての適用動作をご覧ください。

入力データのサイズ設定: `AI.COUNT_TOKENS`

割り当て値を選択するには、ワークロードがモデルに送信するテキストの量を把握しておくと便利です。それに役立つのが AI.COUNT_TOKENS 関数です。

AI.COUNT_TOKENS は、課金対象の生成呼び出しを行わずに、モデルのトークナイザーがテキスト文字列に対して生成するトークンの数を返します。列に対してこの関数を実行して、入力データを測定します。

code_block: <ListValue: [StructValue([('code', "-- Count the input text tokens for each product review\r\nSELECT\r\n SUM(\r\n AI.COUNT_TOKENS(\r\n CONCAT('Classify the sentiment of this review as positive, negative, or neutral: ', review_text),\r\n\r\n endpoint => 'gemini-3.1-flash-lite').result) AS total_input_tokens\r\nFROM\r\n `my_project.my_dataset.product_reviews`;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fac25a95d10>)])]>

この数は、入力トークンの下限です。出力トークンや思考トークン、各 AI 関数が入力に追加する指示、画像などのテキスト以外の入力は含まれません。次の目的でこの関数を使用します。

ワークロードを起動する前に、ワークロードの入力側を測定する。
実際の入力と出力の使用量を測定する小規模なサンプル実行と組み合わせて、割り当てを適正化する。
モデルについて公開されている Gemini プラットフォームの料金を使用して、トークンをドルに換算する。

トークンから予算まで: 具体例

たとえば、Gemini 3.1 Flash-Lite モデルを使用した、プロジェクトの 1 日あたりの AI 費用を $100 程度に抑えたいとします。現時点で公開されている料金は以下のとおりです（BigQuery はバッチ処理を行うため、50% 割引が適用されます）。

入力トークン: 100 万トークンあたり $0.125
出力トークン（回答 + 推論）: 100 万トークンあたり $0.75

小規模なサンプル実行で、入力トークンと出力トークンの比率が平均 100:1 であることがわかった場合、1 日の予算を次のように計算できます。

code_block: <ListValue: [StructValue([('code', 'Cost: 0.125 × I + 0.75 × O = 100 (I, O in millions of tokens)\r\nRatio: I = 100 × O'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fac26aae850>)])]>

この計算式で計算すると、1 日あたり約 7 億 5,400 万の入力トークンと 754 万の出力トークンになります。1 日あたりの AI 入力トークン数と 1 日あたりの AI 出力トークン数をこれらの値に設定して、プロジェクトの費用を 1 日あたり約 100 ドルに抑えます。プロジェクトで異なる料金のモデルを使用する場合は、モデルごとに予算を設定するか、平均料金に基づいて予算を設定します。

AI 費用管理のベストプラクティス

ユーザーごとの割り当てから始めます。これにより、1 人のユーザーや暴走したテストによってプロジェクトの予算が使い果たされるのを防ぐことができます。
規模を拡大する前に測定します。AI.COUNT_TOKENS を使用して入力のサイズを測定し、使用量グラフで小規模なサンプル実行を確認してから、上限を設定します。
出力側を意識します。出力トークンは費用が高くなります。関数で max_output_tokens を使用できる場合は、生成の長さを制限するように設定します。
モニタリングと反復処理を行います。実際の使用量と予算の変化に応じて上限を調整します。

使ってみる

トークンベースの費用管理が利用可能になりました。手順は次のとおりです。

Google Cloud コンソールで [IAM と管理] → [割り当てとシステム上限] を開き、[BigQuery API] でフィルタします。
AI 関連の 4 つのトークン割り当てを確認し、予算に合った上限を設定します。
AI.COUNT_TOKENS を使用して、入力データのサイズを測定します。

詳細については、生成 AI の費用の管理に関するドキュメントをご覧ください。

トークンベースのガードレールを導入することで、組織が必要とする費用の予測可能性を確保しながら、BigQuery で生成 AI を使用できます。

- ソフトウェアエンジニア、Tushar Jaiswal

- デベロッパーアドボケイト、Alicia Williams

Google Cloud で Gemini 4 Argon が利用可能に：ビジネスの最も困難な課題解決をサポート

Wed, 21 Oct 2026 02:00:00 +0000

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

先週、Google は Gemini Enterprise が進化し、業務をさらに簡単に完了できるようになったことを発表しました。また、あらゆる業務に対応する新しい万能エージェント、Gemini エージェントも紹介しました。常時稼働しており、いつでも質問に答えてくれます。コードの生成、より長く複雑なタスクの処理、業務を遂行するために必要なあらゆる作業を、すべて 1 つのプロンプトボックスから実行できます。そして、そのすべてをモデルインテリジェンスが支えています。

新たな働き方を実現するため、Google は新しいフロンティアモデルである Gemini 4 Argon を Google Cloud で提供開始します。

Argon は、高度な思考力と正確性を併せ持つようにトレーニングされています。そのため、複数のステップからなる長いタスクでも一貫してコンテキストを維持でき、専門的な知識を活用しながら処理を進めることができます。チームが複雑なソフトウェアビルドを実行する場合も、財務や法務の詳細な作業を処理する場合も、CodeMender のようなサイバーセキュリティツールを導入する場合も、Argon はチームが最初から最後まで集中して作業を進められるよう支援します。

Gemini 4 Argon をご利用中のお客様とパートナー

Argon がビジネスのあり方を変える 4 つの方法

1. 面倒な作業を委任可能

皆様のチームでも、質問への回答やコンテンツの下書きに Gemini for Business をすでにご活用いただいているかと思います。Argon を使用すると、これまで数時間から数日かかっていた、複数のステップからなる複雑な作業を任せ、すぐに使える完成した成果物を受け取ることができます。

Argon は、テキスト、表、グラフ、画像が混在する長文ドキュメントを読み取り、それらのソースを確実な根拠とした 1 つの明確なアウトプットを生成します。多数のソースから得られた知見を 1 つの構造化された回答にまとめ、経時的なデータ分析を行い、法務、財務、経営に関するより完成度の高い文書を作成できます。時間のかかるタスクであっても、処理が完了するまで途切れることなく実行し続けます。Argon は、システムの権限や制約を遵守し、ネガティブな検出結果も隠さず報告し、元に戻せない操作を行う前には必ずユーザーの確認を挟むようトレーニングされています。また、目的のデータが見つからなかった場合やタスクを完了できなかった場合も、その旨を明確に通知します。

Argon をテストしたお客様からは、膨大な非構造化データをまとまりのあるアウトプットに変換する能力が非常に優れている、という声が寄せられています。

「ソフトウェア開発がよりエージェント指向になるにつれ、開発ライフサイクルのすべての段階で、長時間にわたるマルチステップの作業をサポートできるモデルがチームに必要になります。Gemini 4 Argon は、組織が開発、セキュリティ、運用の領域に AI を導入する際、既存のエンタープライズワークフローや統制の枠組みを維持できるよう設計されています。」– GitLab、バイスプレジデント、Stuart Moncada 氏

2. ビジネスを推進する重要業務において、正確かつ検証可能な結果を実現

財務、法務、税務をはじめとする規制対象の業務では、計算やデータ抽出における高い正確性、再現性、そして検証可能性が求められます。

財務定量業務において、Argon は複数ステップにわたる元帳照合、スプレッドシートの数式設定、差異分析の自動化をサポートします。定量モデル全体で、計算の整合性、引用の忠実度、数式の精度を高く保ちます。数字がそれを証明しています。Argon は、財務、コーディング、法務、税務の業務における経済効果を測定する Vals Index で首位を獲得しています。

法務調査において、Argon は法務チームによる判例法や規制当局への提出書類の確認をサポートし、検証済みの引用や重要な判例の抽出を支援します。法務調査や文書作成に関する Harvey の Legal Agent Benchmark などの分野固有の評価でトップに立っており、チームが複雑な判例を検討する際にも、正確な引用とともに的確で直接的な回答を提供します

「Gemini 4 Argon は、Google がエージェントによる法的推論においてどれほど進歩したかを示しています。当社の法務エージェント評価では、特に企業の M&A、データプライバシーとサイバーセキュリティ、EC / VC において、Gemini 3.1 Pro と比較して大幅な向上が見られました。長いドキュメントの分析でも精度が維持され、詳細な取引事項を扱う弁護士にとって心強い結果となりました。」– Harvey、応用研究責任者、Niko Grupen 氏

「当社は Google と NowAI-Bench で連携し、Gemini 4 を主要なエンタープライズ業務向けに最適化できるよう協力しました。早期アクセスでは、Gemini 3.8 Flash と比較してタスクの成功率が約 20% 向上し、人事とカスタマーサービスで特に大きな成果を上げました。ServiceNow AI Platform では、当社の L1 サービスデスク AI スペシャリストが、ガバナンスの効いた安全な環境のもとで Google の最先端インテリジェンスを活用し、定型タスクを完全自律型の業務へと変革します。」- ServiceNow、AI プロダクト担当シニアバイスプレジデント、Nenshad Bardoliwalla 氏

3. プロダクトの構築とリリースを迅速化

Argon は、複数のステップからなる複雑なプロジェクトを、最初から最後まで一貫して処理できるよう設計されています。お客様からは、目標を細分化し、進捗状況を追跡し、複数のファイルを同時に更新できるインテリジェンスを求める声が常に寄せられています。

「Gemini 4 Argon は、3D ゲームからリッチなアニメーションまで、複雑なタスクを確実に処理します。Figma Make では、チームが抱く複数のステップに及ぶ最も野心的なアイデアを、魅力的なプロトタイプとして具現化するのを強力にサポートします。」- Figma、最高デザイン責任者、Loredana Crisan 氏

Argon がこうした高度な処理をどれほど優れてこなせるか検証するため、Google 自身のツールで実際に活用してみました。Google のオープンソース Agent Development Kit（ADK）の開発チームは、既存のアプリケーションとの完全な互換性を維持しながら、フレームワークのオーバーヘッドを削減し、コードのパフォーマンスを向上させることに取り組みました。Argon は、自動テストのガードレールのもと夜間に自律的に動作し、コードの最適化ポイントを見つけ出しました。この最適化は現在 google/adk-python に反映されており、長時間のセッションにおけるインメモリセッション準備時間を 40% 短縮し、コールドインポートを 21% 高速化させています。詳細については、こちらのエンジニアリング詳細解説をご覧ください。

Google 全体で、Google Antigravity 上で Argon を活用しているエンジニアリングチームは、エージェントによるコード提出量を 35% 以上増加させつつ、コードのロールバックをほぼ 3 分の 1 削減しました。Chrome チームは Argon を使用して、Chromium の 4,000 万行のコードベースにある数百ものファイルにわたるアーキテクチャリファクタリングを行い、数か月かかる作業をわずか数週間で完遂しました。Argon は空間推論、数学的精度、ビジュアルコーディングが向上しているため、アイデアから実用的なプロトタイプをより迅速に作成できます。

より高度なアルゴリズムについては、コード最適化および検出エージェントである AlphaEvolve が Argon を使用して、工場のスケジューリング、ロジスティクス、ゲームコードの高速化、チップレイアウトなどの実際のエンタープライズワークロードや、複雑な数学的ベンチマークなどで、大幅なパフォーマンス向上を実現しています。

Argon を最大限に活用する方法については、デベロッパーガイドをご覧ください。

4. コードとビジネスの防御を強化

Argon には、ペネトレーションテストや悪用などの攻撃的なタスクをブロックするサイバー攻撃緩和策が備わっていますが、CodeMender を使用して脆弱性を発見および修正したり、独自のセキュリティハーネスで Argon を使用したりすることで、その防御機能を最大限に活用できます。CWE-Bench v1 では、セキュリティの脆弱性の修復において最高スコアの 68% を獲得し、1 位タイとなっています。

「当社では、MarketingX に Gemini 4 Argon を統合して、コードベースのセキュリティ監査を自動化しています。当社の評価では、検証された指摘事項において、モデルは最優先で対応すべき脆弱性を 100% 特定し、架空の脆弱性の誤検知は 0% でした。この精度により、デプロイ前にコードレベルでプロアクティブなセキュリティを確保できます。」- HubX、AI ラボ最高 AI 責任者、Yunus Emre 氏

セキュリティとは、自社の環境内で Argon を信頼できることも意味します。Argon は、悪意のある指示やコンテキストを使用してモデルの動作を乗っ取る間接的なプロンプトインジェクションに対して、これまでで最も高い耐性を備えたモデルです。Gray Swan の間接プロンプトインジェクションベンチマークでトップに立ち、15 回のアダプティブ攻撃の成功率を 0.7% にまで低減しました。これは、悪意のある指示が隠されている可能性のあるメール、ドキュメント、ウェブページを Argon が読み取る場合に重要です。

また、サイバーガードレールなしの Argon を、信頼できる一部の防御者に提供しています。これにより、サイバーセキュリティ機能の全範囲をテストできます。信頼できる防御者は、Fairwind プログラムを通じて審査されます。このプログラムは、政府機関、重要インフラ、サイバーセキュリティパートナーに、高度なモデルへの独占的かつ無制限のアクセスを提供する、対象者限定の取り組みです。

早期アクセスプログラムに参加している企業のお客様やパートナーは、すでに Argon で大きな成果を上げています。

^{Amplitude、Deloitte、楽天のリーダーが Gemini 4 Argon の成果を共有}

使ってみる

このたび、Gemini 4 Argon がウェブ、デスクトップ、モバイルの Gemini for Business でご利用いただけるようになりました。企業のデベロッパーやビルダーは、Gemini プラットフォーム（モデル ID gemini-4-argon）、Google AI Studio、Google Antigravity において、API を介して Argon にアクセスできます。

Argon は、2026 年 11 月 30 日まで、100 万入力トークンあたり 2 ドル、100 万出力トークンあたり 10 ドルの特別価格で提供されます。キャッシュに保存された入力トークンは 95% 割引となります。2026 年 11 月 30 日以降は、100 万入力トークンあたり 4 ドル、100 万出力トークンあたり 20 ドルの標準価格が適用されます。技術仕様、トークン制限、移行手順の詳細については、モデルカードとデベロッパーガイドをご覧ください。

サイバー防御者の皆様は、Security Summit にご参加いただくことで、Gemini 4 Argon を使用してマシンスピードの脅威から防御し、修復を自動化する方法を学ぶことができます。

- Google Cloud、Gemini、プロダクトマネジメント担当バイスプレジデント、Michael Gerstenhaber

Agent Development Kit は 5 つの言語に対応

Wed, 21 Oct 2026 02:00:00 +0000

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

エージェントといえば Python というイメージがありますが、実際は必ずしもそうではありません。現在の先進的なエコシステムでは、エージェントは Cloud Run 上で Go マイクロサービスとして大規模に同時実行されることもあれば、ブラウザタブ内で動作して Chrome のオンデバイスモデルを呼び出すこともあります。しかし、エージェントフレームワークの多くは Python のみのスタックを想定しています。そのため、エージェントワークロードのためだけに Python サービスをスピンアップしたり、エージェントオーケストレーションロジックを独自の言語でゼロから構築したりすることが必要になります。

Google の Agent Development Kit（ADK）は、Python、Go、TypeScript、Java、Kotlin をサポートしているため、このようなトレードオフは発生しません。ADK の各バージョンはそれぞれの言語のランタイムと型システムに合わせてゼロから構築されており、かつ、オープンプロトコルによる相互運用性を備えた統合アーキテクチャを共有しています。

共通の基盤

5 つの言語すべてが同じオープンプロトコルをサポートしているため、使用する言語によってアーキテクチャが固定されることはありません。すべての言語の ADK に Model Context Protocol クライアントが含まれており、MCP サーバーとして公開されたカスタムツールを、どの言語からでもすぐに呼び出すことができます。

マルチエージェントシステムの場合、ADK は Agent2Agent（A2A）プロトコルをサポートしているため、エージェントは HTTP 経由でリモートエージェントと通信できます。エージェントが異なる言語やフレームワークで記述されていても、A2A を通じて相互運用することができます。

エージェントファースト開発の第一歩

まず、1 回限りの設定コマンドを実行して Google Cloud 認証を確認し、CLI をインストールします。その後、Antigravity、Claude Code、Codex などのコーディングエージェントでファーストパーティの ADK スキルを設定します。

code_block: <ListValue: [StructValue([('code', 'uvx google-agents-cli setup'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fac26a7a950>)])]>

次に scaffold コマンドを実行して、A2A エンドポイントと Cloud Run、Gemini Enterprise Agent Runtime、または Google Kubernetes Engine（GKE）のデプロイ構成を含む作業プロジェクトを生成します。

code_block: <ListValue: [StructValue([('code', '# Scaffold an ADK project (use --agent adk for Python or --agent adk_go for Go)\r\nagents-cli scaffold create my-go-agent \\\r\n --agent adk_go \\\r\n --deployment-target cloud_run \\\r\n --region us-central1'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fac26a7ac90>)])]>

ADK for Python リポジトリと ADK for Kotlin リポジトリの両方とも、ソースツリーにはエージェントビルダーのスキルも含まれています。また、adk.dev/llms.txt リソースにより、5 つの言語すべてのコーディングエージェントでオンデマンドの API ドキュメントを利用できます。

コーディングエージェントスキルがプロジェクトの基盤を構築し、MCP と A2A が 5 つの言語ランタイムすべてを接続します。

各 ADK の実践的なサンプル

5 つの言語の違いを感じるには、各言語で同じ天気ツールを定義し、その設計とランタイムの連携方法を確認することが最もわかりやすいでしょう。

Python

ADK for Python では、デコレータやスキーマビルダークラスは必要ありません。プレーンな Python 関数を tools パラメータに渡すと、ADK の起動時にシグネチャ、型ヒント、docstring が検査され、ツール宣言と Pydantic パラメータスキーマが自動的に構築されます。

code_block: <ListValue: [StructValue([('code', 'from google.adk.agents.llm_agent import Agent\r\n\r\n\r\ndef get_weather(city: str) -> dict:\r\n """Retrieves the current weather report for a specified city.\r\n\r\n Args:\r\n city (str): The name of the city for which to retrieve the weather report.\r\n """\r\n return {"status": "success", "report": f"Sunny and 72F in {city}."}\r\n\r\n\r\nroot_agent = Agent(\r\n name="weather_agent",\r\n model="gemini-3.8-flash",\r\n instruction="Answer questions about the weather in a city.",\r\n tools=[get_weather],\r\n)'), ('language', 'lang-py'), ('caption', <wagtail.rich_text.RichText object at 0x7fac26a7a8d0>)])]>

Python は迅速なプロトタイピングが可能であるだけでなく、ADK のリファレンス実装でもあり、最も幅広い Google Cloud の統合（BigQuery、Spanner、Bigtable）とモデルアダプタ（Gemini、Anthropic、OpenAI、LiteLLM）が提供されています。adk eval コマンドまたは agents-cli eval run コマンドと組み合わせて評価ツールを使用することで、継続的インテグレーション（CI）でゴールデンデータセットを基準としてエージェントの軌跡をスコアリングし、本番環境サービスが別の言語で実行されている場合でも、システム全体をエンドツーエンドでテストできます。

Go

Python がテストと評価に優れている一方で、ADK for Go は本番環境のバックエンドエンジニアリングに最適です。

Go ツールの関数は、agent.Context 構成と厳密に型指定された入力構造体を受け取ります。functiontool.New 関数は、Go ジェネリクスを使用して、struct タグから入力スキーマと出力スキーマの両方を推測します。

code_block: <ListValue: [StructValue([('code', 'type GetWeatherArgs struct {\r\n\tCity string `json:"city" jsonschema:"The city to look up weather for."`\r\n}\r\n\r\ntype GetWeatherResult struct {\r\n\tReport string `json:"report"`\r\n}\r\n\r\nfunc getWeather(_ agent.Context, args GetWeatherArgs) (GetWeatherResult, error) {\r\n\treturn GetWeatherResult{Report: "Sunny and 72F in " + args.City}, nil\r\n}\r\n\r\nweatherTool, err := functiontool.New(functiontool.Config{\r\n\tName: "get_weather",\r\n\tDescription: "Retrieves the current weather report for a city.",\r\n}, getWeather)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fac26a79710>)])]>

functiontool.New 関数はハンドラのシグネチャに対してジェネリクスを活用しているため、Go コンパイラは関数が想定されるコントラクトと一致することを確認してからバイナリを実行します。

Go は、Python の次に ADK 2.0 Graph Workflow ランタイムが提供された言語でもあります。LLM 推論と併せて決定的な制御フローを使用する必要がある場合は、workflow.New 関数を使用して、エージェントとプレーンな Go 関数を条件付きルーティングと並列ステップを持つ有向グラフに接続します。

code_block: <ListValue: [StructValue([('code', 'ag, err := workflowagent.New("order_pipeline", []workflow.Edge{\r\n\t{From: workflow.Start, To: triageNode},\r\n\t{From: triageNode, To: fulfillNode, Route: workflow.StringRoute("fulfill")},\r\n\t{From: fulfillNode, To: notifyNode},\r\n})'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fac26a78050>)])]>

Go が真価を発揮するのは、本番環境でCloud Run および GKE と組み合わせて使用する場合です。コンパイルされた Go エージェントは、約 2 MiB の Google distroless 静的ベースイメージにパッケージ化され、言語 VM や重い依存関係ツリーはありません。静的な Go バイナリはコンテナが起動するとすぐにポートにバインドされ、動的言語のモジュールインポートや、JVM サービスの JAR の展開と JIT のウォームアップはスキップされます。

Go の同時実行モデルは、実行されたエージェントのワークロードと優れた適合性を発揮します。各 goroutine は 2 KB のスタックと最小限のスケジューリングオーバーヘッドで開始されるため、単一のインスタンスで数千の同時ストリーミングリクエストとツール呼び出しを多重化できます。ADK for Go には、組み込みの A2A サーバーハンドラと OpenTelemetry トレースも含まれています。

TypeScript

TypeScript は JavaScript へのコンパイル時に型アノテーションが消去されるため、ランタイムリフレクションは使用できません。代わりに、ADK for TypeScript は Zod と連携します。z.object(...) スキーマを FunctionTool 関数に渡すと、TypeScript はその単一の宣言から execute コールバックのパラメータ型を静的に推測します。

code_block: <ListValue: [StructValue([('code', 'import { FunctionTool, LlmAgent } from "@google/adk";\r\nimport { z } from "zod";\r\n\r\nconst getWeatherTool = new FunctionTool({\r\n name: "get_weather",\r\n description: "Retrieves the current weather report for a city.",\r\n parameters: z.object({\r\n city: z.string().describe("The name of the city."),\r\n }),\r\n execute: async ({ city }) => {\r\n return { status: "success", report: `Sunny and 72F in ${city}.` };\r\n },\r\n});\r\n\r\nexport const rootAgent = new LlmAgent({\r\n name: "weather_agent",\r\n model: "gemini-3.8-flash",\r\n instruction: "Answer questions about the weather in a city.",\r\n tools: [getWeatherTool],\r\n});'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fac26a7b750>)])]>

ランタイム入力の検証、モデルに送信される JSON スキーマ、execute コールバック内の IDE 予測入力はすべて、信頼できる唯一の情報源から取得されます。

TypeScript は ADK 2.0 Graph Workflow エンジンでも動作し、スタンドアロンのブラウザバンドルが提供されています。Node.js サービス以外にも、ページレベルのツール用の WebMCP と Chrome のオンデバイス Prompt API を使用して、ブラウザタブで ADK エージェントを直接実行することができます。

Java

ADK for Java は、Maven、Gradle、Spring Boot で標準化している場合に最適です。メソッドパラメータに @Schema アノテーションを追加し、Fluent API である LlmAgent.builder() を使用してエージェントを組み立てます。

code_block: <ListValue: [StructValue([('code', 'public class WeatherTools {\r\n public static Map<String, String> getWeather(\r\n @Schema(name = "city", description = "The name of the city")\r\n String city) {\r\n return Map.of("status", "success", "report", "Sunny and 72F in " + city);\r\n }\r\n}\r\n\r\nLlmAgent agent = LlmAgent.builder()\r\n .name("weather_agent")\r\n .model("gemini-3.8-flash")\r\n .instruction("Answer questions about the weather in a city.")\r\n .tools(FunctionTool.create(WeatherTools.class, "getWeather"))\r\n .build();'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fac26a78f50>)])]>

実行時には、ランナーが RxJava を介してエージェントイベントをリアクティブにストリーミングします。ローカルテストと既存の JVM アプリ向けに、ADK for Java には Maven Dev UI プラグインと、Spring AI および LangChain4j 用のファーストパーティブリッジが提供されています。

Kotlin

ADK for Kotlin は、ビルド時の安全性を重視しています。Kotlin Symbol Processing（KSP）コンパイラプラグインが、ビルド時に @Tool アノテーションと @Param アノテーションを読み取り、ツールスキーマをバイトコードに直接出力します。

code_block: <ListValue: [StructValue([('code', 'class WeatherTools {\r\n @Tool(\r\n name = "get_weather",\r\n description = "Retrieves the current weather report for a city.",\r\n )\r\n suspend fun getWeather(\r\n @Param("The name of the city.") city: String\r\n ): Map<String, String> = mapOf("status" to "success", "report" to "Sunny and 72F in $city")\r\n}\r\n\r\nval agent = LlmAgent(\r\n model = Gemini("gemini-3.8-flash"),\r\n name = "weather_agent",\r\n instruction = Instruction("Answer questions about the weather in a city."),\r\n tools = WeatherTools().generatedTools(),\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fac26a7bc10>)])]>

ツールシグネチャが、サポートされていない型を使用したり、null 非許容パラメータにデフォルト値を宣言したりした場合、本番環境で問題が発生するのではなく、Gradle ビルドがただちに失敗します。.generatedTools() 関数はランタイムリフレクションを使用しないため、Android R8 圧縮後も保持されます。

リフレクションを使用しないこの設計により、エージェントループ全体を Android 上でローカルに実行できます。また、JVM サーバーをサポートしており、Spring AI ブリッジや試験運用版の ADK 2.0 グラフワークフローなどを使用できます。オンデバイスでは、ADK for Kotlin は LiteRT-LM（ツール呼び出し）および ML Kit（Gemini Nano、テキスト生成）と統合できます。さらに、Room および AppSearch と連携してローカル状態を管理したり、Android AppFunctions と連携して OS レベルのアクションを実行したりすることができ、このいずれにもネットワーク接続は必要ありません。

妥協のない選択

ADK は 5 つの言語にネイティブで対応しているため、組織全体で 1 つのランタイムに統一する必要がありません。すべてのバージョンが MCP と A2A に対応しており、システムの各コンポーネントで最適な言語を使用できます。

Google の ADK で、どの言語を使用してエージェントを構築しましたか？皆様がどのようなスタックを使用しているか、X、LinkedIn、Bluesky でぜひ教えてください。

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

ブラウザベースのセキュリティの未来: ブラウザデータを活用してプロアクティブな防御を実現

Wed, 21 Oct 2026 00:00:00 +0000

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

ブラウザは大きく変化しました。現代の企業では、ウェブへの入口としてだけでなく、AI ワークスペースとしても機能し、中心的な運用環境となっています。ナレッジワーカーは勤務時間の 56% 以上でブラウザを使用しており、ブラウザは日常業務、複雑なワークフロー、自律型 AI エージェントとの直接的なやり取りのための主要な場所であると言えます（Omdia、2026 年）。脅威アクターに対抗するには、ブラウザテレメトリーをセキュリティアーキテクチャの中心に据えたブラウザ戦略が必要です。

シャドー AI の登場とエージェントがもたらすリスク

さまざまな企業が AI を導入する中、新たな脆弱性が生じています。シャドー AI（一般公開されている生成 AI ツールを未承認で使用すること）は、プロンプトの共有や自律型エージェントのアクションを通じて、企業の機密 IP を漏洩させる可能性があります。92% の組織が、これらのチャネルを通じたデータ漏洩の危険性に懸念を示しています。こうした状態を監視せずに放置すると、重大なリスクが生じます（Omdia、2026 年）。

そもそも従来のセキュリティスタック（エンドポイントの検出と対応（EDR）や境界ファイアウォールなど）は、ブラウザ内のインタラクションを認識できません。AI 主導のワークフローに特有の、次のような高リスクの脅威ベクトルは完全に見逃されます。

機密性の高い財務データを「読み取る」、またはログインページにキーロガーを「書き込む」悪意のある拡張機能。
「環境寄生型」（LOTL）戦術とセッションハイジャック。
AI を利用して攻撃ライフサイクルを加速する、国家支援型脅威アクター。

Chrome Enterprise Premium: 高忠実度のテレメトリーエンジン

Chrome Enterprise Premium は、ブラウザのテレメトリーを取り込むことで、この可視性のギャップを解消します。事後に外部から観察するのではなく、ユーザーインタラクションの時点でシグナルを直接記録します。

最新の防御の中核となる機能

リアルタイムシグナル: ネットワークイベント、リスクの高いユーザー行動、不審なドメインアクセスに関する継続的なテレメトリー。
拡張機能のテレメトリー: 従来の EDR では見逃される可能性のある、サイドローディングされた拡張機能や拡張機能とドメインの間の通信を詳細に可視化。
生成 AI と SaaS アプリのレポート: フリート全体で承認済みの AI ツールと未承認の AI ツールを検出して管理するための専用機能。
エビデンスロッカー: DLP ポリシーに違反するファイルやコンテンツを取り込む機能。フォレンジック分析、根本原因の特定、検出ルールの改良に不可欠な証跡を提供します。

リアクティブなレビューからプロアクティブな緩和戦略への転換

プロアクティブな防御に移行することで、セキュリティチームは脅威を早期に緩和できるようになります。ブラウザのシグナルを Google Security Operations などのセキュリティ運用プラットフォームにストリーミングすることで、対応を自動化し、手動での調査時間を短縮して、インシデント対応にかかる費用を削減できます。

最前線からのインサイト: Mandiant の事例紹介

Mandiant の観測から、ブラウザの可視性が及ぼす実質的な効果が明らかになっています。これらの事例は、標準的な制御を回避する攻撃を検出するうえで、ブラウザのテレメトリーが果たす役割を示すものです。

RMM ソフトウェアのダウンロード: Chrome Enterprise Premium が、ある正規のリモートモニタリングおよび管理（RMM）実行可能ファイルにフラグを立てました。このファイルが新規登録されたドメインから配信されたものであったためです。新規登録されたドメインは、ネットワークツールが見落としがちなソーシャルエンジニアリングの重要な指標です。
認証情報の窃取: Chrome Enterprise Premium が、インタラクションが発生した瞬間に URL のリスクとナビゲーションパラメータを評価し、ユーザーが認証情報を送信する前にフィッシングの試みを阻止しました。
マルバタイジング: Google Threat Intelligence との統合により、悪意のある広告クリックを即座に特定し、アクターがハンズオンキーボード攻撃を実行する前に脅威を封じ込めました。

セキュリティギャップを解消するには、まずブラウザが企業セキュリティの重要なリソースであることを認識する必要があります。数十億台の保護されたデバイスに Google のテレメトリーを行き渡らせることで、組織は新たな AI を利用しながら防御の可視性を維持し、プロアクティブなセキュリティ戦略を推進できます（Google セーフブラウジング）。

セキュリティポスチャーの変革に向けて

セキュリティ戦略には盲点を残すべきではありません。ウェブ防御に関するさまざまな選択肢について詳しくは、Google のデジタルペーパー「Securing the Browser: How telemetry brings web defense into the next frontier」（ブラウザのセキュリティ確保: テレメトリーがウェブ防御を次のフロンティアに導く方法）をご覧ください。

このリソースでは、最新の防御のフレームワークを概説し、敵対者の戦術、感染経路、脅威の傾向について詳しく説明しています。このデジタルペーパーで、組織のブラウザセキュリティ戦略を評価しましょう。

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

Cloud Blog JA

Sky: Gemini を全社で一斉に導入し、98% の利用定着率と 2,000 個近いエージェントの共有を実現

「SKYAI」の内製開発で定着した AI 活用文化を、いかに発展させるか

横断検索の精度、データ連携、ガバナンスを評価して Gemini を選定

「従業員が AI と一緒に働く」環境を構築し、独自のスタイルを追求

Gemini エージェントがスタートアップにもたらすメリット

Gemini エージェントとは

スタートアップ向けの 5 つの重要ポイント

すでに実践している創業者

Google Antigravity で Claude Opus 5.5 と Claude Sonnet 5.5 が利用可能に

Antigravity のマルチモデル エンジニアリング パターン

ご利用にあたって

グローバル規模のハードウェア格納型セキュリティ: NVIDIA Blackwell を搭載した Confidential G4 の一般提供を開始

機密データとモデルを低レイテンシで保護

パフォーマンスのテスト

Confidential G4 を使ってみる

Cloud Run 上の Temporal Serverless Workers: 需要の変動を見越してワーカーをスケーリング

Cloud Run ワーカープールと Temporal の連携の仕組み

Temporal Serverless Workers の活用例

Temporal ワーカーの実行基盤に Cloud Run ワーカープールを選ぶ理由

Temporal によるワーカープールのスケーリングとバージョニングの仕組み

使ってみる

ARMORY CASTLE が BeyondTrust の脆弱性を悪用

はじめに

脆弱性の悪用

侵入後の活動

最新生成 AI 活用事例 121 社を一挙公開！ AI エージェントの本格活用が広がる（2026 年 10 月更新）

10 月版で新しく追加された事例

第 6 回 生成 AI 事例アワード ピッチコンテスト

Google Public Sector と SUNY、大学の研究を加速する AI 対応プラットフォームを開設

サイバーエージェント: Cloud Run や Agent Development Kit を活用し、クリエイティブ生成 AI プラットフォーム「AI SCREAM」のエージェント化を推進

独自プラットフォーム「AI SCREAM」で全社員に生成 AI を届ける

エージェント化によって営業メンバーもクリエイティブ制作の担い手に

より対話的な体験を追求、そして社外への展開も開始

「MCP ツールボックス」Java SDK v1.0 のご紹介: 企業向けのエージェント型データアクセス

MCP: ユニバーサル インターフェース

Java SDK v1.0 の新機能: 本番環境ワークロードに対応

Java SDK v1.0 を使ってみる

実際の例: 自律型交通コンシェルジュ

基盤: ネイティブ エンベディングを備えた AlloyDB スキーマ

インテントと SQL のマッピング: tools.yaml

Spring Boot のステートフル エージェント アーキテクチャ

すべてをつなぎ合わせる: Java v1.0 におけるツールのリスト表示、呼び出し、実行

セキュア バイ デフォルト: 認証とデプロイ

使ってみる

非構造化データ ワークフローのモダナイズ: Alteryx Live Query と Google Cloud BigQuery の連携

請求書 PDF の処理から、Live Query を使用した BigQuery での例外レポート管理まで

ソリューションの概要: 抽出、分類、検証、ルーティング、計上

アーキテクチャ: Google Cloud ネイティブ パターン

Live Query ワークフロー解説: PDF から分析情報まで

まとめ: ドキュメントから意思決定まで、ガバナンス管理されたワークフロー

Gemini のイノベーションで、ボーダーレス Lakehouse をエージェントの時代へ導く

Gemini を通じて Google Cloud の外部にあるデータにアクセスする

ボーダーレス Lakehouse の進化

ペタバイト規模のパフォーマンスと推論

エージェント向けの包括的なコンテキストとデータアクセス

モダナイゼーションを容易に

あらゆるエンドポイントでセキュアかつインテリジェントなエクスペリエンスを実現

日々のワークフローをスケールして時間を節約

プロアクティブなセキュリティと可視性の強化

次世代デバイスで従業員を支援

Google インテリジェント エンドポイントの使用を開始する方法

Cloud CISO の視点: CISO や政策立案者が PQC への準備を整えるのに役立つ Gemini Notebook の新しいノートブック

Google Cloud がモデルの選択肢と柔軟性を拡充、OpenAI モデルを提供開始

あらゆるワークロードに最適なモデルを

組み込みのデータ ガバナンスとエンタープライズ セキュリティ

今すぐはじめるには

BigQuery で多変量時系列予測を行う TimesFM 3.0 のご紹介

概要

新機能: 多変量基盤モデリング

BigQuery SQL を使用した多変量予測

BigQuery 会話型分析の TimesFM 3.0

まとめと次のステップ

BigQuery で AI 費用を予測可能に: 生成 AI 関数の費用管理のご紹介

費用を管理するための割り当て

対象となる関数

割り当ての管理

使用量のモニタリング

トークン割り当てと費用上限

適用の仕組み

Antigravity のマルチモデルエンジニアリングパターン

第 6 回生成 AI 事例アワードピッチコンテスト

MCP: ユニバーサルインターフェース

基盤: ネイティブエンベディングを備えた AlloyDB スキーマ

インテントと SQL のマッピング: `tools.yaml`

Spring Boot のステートフルエージェントアーキテクチャ

セキュアバイデフォルト: 認証とデプロイ

非構造化データワークフローのモダナイズ: Alteryx Live Query と Google Cloud BigQuery の連携

アーキテクチャ: Google Cloud ネイティブパターン

Google インテリジェントエンドポイントの使用を開始する方法

組み込みのデータガバナンスとエンタープライズセキュリティ

入力データのサイズ設定: `AI.COUNT_TOKENS`

AI 費用管理のベストプラクティス

早期アクセスプログラムに参加している企業のお客様やパートナーは、すでに Argon で大きな成果を上げています。

エージェントファースト開発の第一歩