タグアーカイブ Gemini

AI検索で消えるブランド、SEO上位でもAI回答に登場しない実態。Fractl調査が明かす視認性格差

AI検索で消えるブランド、SEO上位でもAI回答に登場しない実態。Fractl調査が明かす視認性格差

SEOで上位を獲得しているブランドの一部が、AIチャットの回答にはほとんど登場しない。検索エンジン向けの最適化だけでは、生成AI時代のブランド視認性を確保できないことが明らかになってきた。

Fractlの調査では、GPT-4o、Gemini 2.5 Flash、Claude Sonnet 4.6の3つのモデルに96種の業界別プロンプトを投げ、4,320件の回答と8,500件超のブランド言及を分析した。SEO指標とAI回答での言及頻度を突き合わせ、その乖離を数値化している。

この記事では、AI検索から消えつつあるブランドの特徴、逆にAIで過剰に登場するブランドの共通点、そしてブランド戦略に必要な対応を解説する。

AI回答に潜む「デフォルトブランド」の存在

調査対象の全業界に共通して、プロンプトの言い回しを変えても繰り返し登場する「デフォルトブランド」が存在した。ただし、その顔ぶれは検索エンジンの上位表示とは必ずしも一致しない。ドメイン評価が高く、大量のキーワードで上位表示されているブランドが、AI回答では自社カテゴリにすら登場しないケースが目立つ。

逆に、従来のSEO指標では目立たないブランドが、AI回答では頻繁に推奨される事例も多かった。注目すべきは、デフォルトブランドの顔ぶれが業界ごとに大きく異なる点だ。

旅行カテゴリではBooking.com(285回)、Airbnb(227回)、Expedia(215回)の3ブランドが、カテゴリ全体の言及量の約20%を占めた。3社で推奨の5分の1を握る集中度だ。保険カテゴリではLemonade(213回)がState Farm(172回)を上回り、Root Insurance(165回)がProgressive(114回)を超えた。デジタルネイティブの保険会社が先に挙げられ、従来の大手は代替案として扱われている。

ライフスタイルカテゴリでは、Patagonia、Allbirds、Eileen Fisher、Everlaneといったサステナビリティ系D2Cブランドが、SephoraやSamsung、Whirlpoolを上回った。Fractlの記事では、この傾向は第三者コンテンツで語られるブランドストーリーがAIの訓練データに強く反映された結果だと指摘している。

従来のSEO検索(Before)
大手保険ブランド Google検索1位
ドメイン評価 80以上、月間訪問数 数百万
キーワード 数十万件で上位表示
AIチャット回答(After)
デジタル保険ブランド AI回答で先に登場
大手保険ブランドは言及なし、または代替案としてのみ
従来のSEO上位  AI回答で優先  言及なし

このデモが示す通り、検索エンジンでの強さとAI回答でのプレゼンスは一致しない。AI回答内の競争集合は、検索結果ページよりはるかに小さい。自社カテゴリでAIが想起する上位5〜10ブランドに入れなければ、Googleで上位表示できていても、AIが生成する検討リストには載らない。

伝統的なSEO権威性とAIリコールの乖離

伝統的なSEO権威性とAIリコールの乖離

Fractlの分析によれば、データセット全体の9割超のブランドでは、従来の検索権威性とAI視認性がほぼ連動していた。つまり、SEOの基本原則が無効になったわけではない。ただし、データの端に位置するブランド群にこそ戦略の変化が見える。

全体の約5%、471ブランドが「AI過少露出」だった。ドメイン評価が高く、オーガニック流入も多く、大量のキーワードで上位表示しているにもかかわらず、AIモデルからはほとんど参照されなかった。SEO指標上は市場リーダーに見えるのに、LLMからの言及では「誰も書いたことがない企業」のように映る。

一方、全体の約4%、377ブランドが「AIオーバーパフォーマー」だった。控えめなSEO指標に比べて、AIモデルからの参照が大幅に多かった。さらに9%は、第三者コンテンツでの言及頻度とAI視認性が一致した。

ここから見える最大の示唆は、自社が発信するコンテンツよりも、外部サイトが繰り返し語ってきた内容の方がAIの回答に強く影響するという点だ。まとめ記事、専門家リスト、比較レビューに登場する頻度が高いブランドほど、AIモデルの訓練データに取り込まれやすい。

カテゴリ誤分類で消える大手ブランド

カテゴリ誤分類で消える大手ブランド

AI過少露出のブランドには、従来の指標ではカテゴリの勝者とみなされてきた大手が並ぶ。ドメイン評価80以上、月間訪問数数百万、数十万のキーワードで上位表示しているブランドが、自社カテゴリのプロンプトで一切言及されない。

この問題の根底にあるのが、カテゴリ分類のズレだ。MicrosoftとSpotifyはFinTechのプロンプトで言及されなかった。両社とも伝統的な視認性は巨大だが、AIモデルはFinTechカテゴリに分類していない。Microsoftは生産性ソフトやクラウドの文脈では頻繁に引用される。FinTechの回答セットには含まれないだけだ。

同様の構図は保険、小売、ヘルスケアでも見られた。Aetna、Cigna、Humana、Liberty Mutualはドメイン評価80以上でも、AI回答ではLemonadeやRootに置き換えられた。Sephora、Samsung、Whirlpoolも、ライフスタイルのプロンプトではPatagoniaやAllbirdsに劣位した。

言及されない理由は、AIがブランドを知らないからではない。検索者が使うカテゴリと異なる引き出しに、そのブランドがしまわれているからだ。コンテンツ量を増やすだけでは解決しない。AIモデルがブランドを正しいカテゴリに結び付けるための外部シグナルが必要になる。

ブランド分類のズレが示すもの
Microsoft 検索側の見立て 生産性ソフト
Microsoft FinTechプロンプトでは 言及なし
Spotify FinTechプロンプトで 言及なし
ブランド  AIが認識するカテゴリ  カテゴリ不一致

AIモデルがブランドをどのカテゴリに分類しているかを把握し、ズレがあれば修正する方が先だ。カテゴリの結び付きを強化するには、アナリスト記事、業界メディア、比較ページ、パートナーページ、カスタマーストーリー、レビューサイトでの露出が有効になる。

AIで際立つオーバーパフォーマーの戦略

AIオーバーパフォーマー377ブランドの動きは、マーケターにとって他山の石になる。小さいSEOプロフィールでも、AIの回答に繰り返し登場するブランドは、共通してAIモデルの訓練データに使われた第三者コンテンツに複数回登場している。

データセット最大のオーバーパフォーマーはMonday.comだ。AI視認性スコアは0.71を記録した。オーガニック訪問数は約100万、上位キーワードは5万以上。すでに大きなSEO基盤を持ちながら、SaaSプレイヤーの平均を大きく上回る頻度でAIに参照されている。

保険カテゴリではRoot Insuranceが突出した。大手保険会社の規模に遠く及ばないにもかかわらず、AI参照数ではすべての従来型保険会社を上回った。オーバーパフォーマーの上位15ブランドのうち6つは教育分野で、Stanford、MIT、Khan Academy、LinkedIn Learning、IBM Data Science、Google Career Certificatesが並ぶ。AIモデルは商用的なプラットフォームではなく、信頼性の高さで教育ブランドを参照している。

共通項は「良いSEO」ではなく、他者のコンテンツにカテゴリレベルで登場していることだ。製品まとめ記事、エキスパートリスト、比較記事に取り上げられる頻度が、AI視認性を押し上げる。AI視認性の向上は、デジタルPRやカテゴリ権威性の構築に近づいている。

モデル間で異なるAI視認性の実態

モデル間で異なるAI視認性の実態

調査対象のうち、3モデルすべてに参照されたブランドは11%、900ブランドにとどまった。2モデルに登場したのは12%。残りの77%は、1つのモデルにしか登場しなかった。これはAI視認性の測定に深刻な課題を突き付ける。

ChatGPTで勝てるブランドがGeminiでは消える。Claudeで登場してもChatGPTからは出てこない。1つのモデルの回答を制しても、別のモデルではほとんど登録されない。AI視認性の「総合スコア」だけで改善を判断すると、実態を見誤る原因になる。

3モデルすべてに参照されたブランド(11%)
900ブランドが該当
2モデルに参照されたブランド(12%)
データセットの約12%が該当
1モデルだけに参照されたブランド(77%)
大多数がここに集中
全モデルで一致  2モデルで一致  1モデルのみ

モデルごとの「指紋」も異なる。ClaudeはSaaSと保険に偏り、Notion、Linear、Lemonadeが他モデルより頻繁に登場した。Geminiは旅行とヘルスケアに偏り、Booking.com、Teladoc、Livongoの言及が多かった。ChatGPTは3モデルの中で最も合意型で、他モデルとの重複が最も多い。

NotionはClaudeからの引用がGeminiの17倍に達し、Whoopは約4倍だった。State FarmはChatGPTに言及のほぼ半分を依存し、Geminiからは約4分の1しか得られなかった。総合スコアが同じでも、どこで差が出ているかを確認しないと対策は打てない。

ブランド戦略に必要な5つの視点

Fractlの記事は、この調査から導ける5つの教訓を提示している。実行しやすい順に並べると、次の通りだ。

1. 検索権威性とAIリコールを分けて測る

ドメイン評価、オーガニック流入、キーワード順位は引き続き重要だ。ただし、それだけでは全体像を捉えられない。Googleでの順位とAI回答での登場を別々に追跡し、乖離を探す。そのズレにこそ戦略のヒントがある。

2. 第三者による検証を増やす

自社サイトのコンテンツだけではAI回答への登場を保証できない。まとめ記事、ベストリスト、比較記事、専門家レビュー、アナリストページ、ポッドキャスト、YouTubeの文字起こし、コミュニティの議論など、外部コンテンツでの言及を積み重ねることが、AI視認性の実用的なレバーになる。

3. モデルごとに個別測定する

3モデルすべてに参照されたブランドは11%に過ぎない。「AI視認性」を1つの指標として扱うのは誤解を招く。ChatGPT、Gemini、Claudeを分けて計測し、プロンプトをカテゴリ別、購買意図別、比較セット別に分解する。どのモデルで、どの文脈で、どの競合と共に登場するかを追跡する。

4. カテゴリ分類の修正を優先する

ブランド全体の認知度が高くても、狙うカテゴリでのリコールが弱いなら、問題は分類にある可能性が高い。AIモデルはブランドを知っているが、重要なクエリの回答セットに含めるべき存在だとは考えていない。メディア報道、比較コンテンツ、パートナー参照、カスタマーストーリー、受賞歴、レビュー、第三者ページなどを通じて、ブランドとカテゴリの結び付きを繰り返し強化する必要がある。

5. デフォルト回答の枠が固まる前に動く

ウェルネス、ライフスタイル、ヘルステックの一部では、デフォルト回答の座がまだ空白だ。一方、旅行、主要SaaS、FinTechの一部では、AIが返す顔ぶれがすでに固定化しつつある。カテゴリとの結び付きを早期に築いたブランドほど、AIの回答に残りやすい。後発が割り込む余地は徐々に狭まる。

この記事のポイント

  • SEO上位でもAI回答に登場しないブランドが全体の約5%存在する
  • AI回答での競争集合は検索結果ページよりはるかに小さい
  • 第三者コンテンツでの言及頻度がAI視認性を左右する
  • 3モデルすべてに参照されるブランドは11%に過ぎない
  • カテゴリ誤分類の修正がAI視認性改善の近道になる
Gemini 3.7 Flash登場。エージェント向け性能向上と半額価格の全容

Gemini 3.7 Flash登場。エージェント向け性能向上と半額価格の全容

Google DeepMindは8月13日、新しいAIモデル「Gemini 3.7 Flash」を発表した。コーディングとエージェント用途に特化したFlashシリーズの最新版で、わずか3週間前に登場したGemini 3.6 Flashから大幅な性能向上を実現している。

特に注目したいのは価格だ。導入価格として入力トークン100万個あたり0.75ドル、出力トークン100万個あたり3.75ドルに設定された。これは3.6 Flashの当初価格の半額にあたる。

本記事では、ソフトウェアエンジニアリング、Web開発、知識処理の各ベンチマークを掘り下げつつ、エージェント開発者にとって何が変わるのかを具体的に解説する。

Gemini 3.7 Flashの概要と位置付け

Gemini 3.7 Flashの概要と位置付け

Gemini 3.7 Flashは「Flashシリーズ史上もっとも知的な作業用モデル」という位置付けで投入された。3.6 Flashの発表からわずか3週間という短期間での後継モデル登場は異例の速さだが、Google DeepMindによればこれは開発者からのフィードバックとアルゴリズムの革新的な改善によるものだという。

モデル名の「Flash」は、大規模モデルと比べて応答速度を重視した軽量版という意味を持つ。処理速度を保ちながら推論能力を高めるのがFlashシリーズの設計思想で、3.7 Flashはそのバランスを一段階引き上げている。

改善領域はソフトウェアエンジニアリング、ナレッジワーク、Web開発ワークフローの3つに大別される。単にベンチマーク数値が上がっただけでなく、実務のワークフローに組み込んだ際の体感品質が向上している点が特徴的だ。

コーディング性能の飛躍的向上

ソフトウェアエンジニアリングのベンチマーク

デバッグやイシュー解決などのコーディングタスクで、3.7 Flashは3.6 Flashに対して明確な差をつけた。フロンティアコードと呼ばれる本番品質のコード生成ベンチマークでは43.6%を記録し、3.6 Flashの34.4%から約9ポイント向上している。

長期にわたるソフトウェアエンジニアリングタスクを測るDeepSWE v1.1でも、65.3%と3.6 Flashの49.0%から16ポイント以上の伸びを示した。初回のコード精度が上がったことで、修正のための再試行が減り、開発サイクル全体の効率が改善する。

Gemini 3.6 Flash(Before)
FrontierCode 34.4%
DeepSWE 49.0%
※修正と再試行が多く、開発工数が膨らみやすい
Gemini 3.7 Flash(After)
FrontierCode 43.6%
DeepSWE 65.3%
※初回精度が上がり、再試行と手動監視を削減できる

このデモでは2つのベンチマークを比較している。FrontierCodeとDeepSWEのいずれも、3.7 Flashは3.6 Flashを大きく上回る結果を示している。

Web開発とUI生成の実力

Web開発では、より機能的なレイアウトと完成度の高いアプリを少ないプロンプト数で生成できるようになった。UI生成では、スクリーンショット、画像、デザインシステムのいずれを参照として与えた場合でも、高いデザイン忠実度を発揮する。

Arena.aiのWebDev Arenaというベンチマークでは、Eloスコア1588を記録し、3.6 Flashの1538から50ポイント上回った。Eloスコアとはチェスなどで使われる相対評価の指標で、数値が高いほど他のプレイヤーとの対戦で勝率が高いことを意味する。

実際のユースケースとしては、シンプルなテキストプロンプトからプレイ可能な3Dゲームを動的生成するデモや、パララックス効果を使ったインタラクティブなランディングページを一発生成するデモが紹介されている。副次的なエージェントをオーケストレーションする能力も備えており、複数コンポーネントを連携させたUI構築が可能になった。

知識集約分野での大幅改善

知識集約分野での大幅改善

複雑文書処理の進化

金融、法律、バイオサイエンスなど、専門知識が求められる分野でも3.7 Flashは大幅な改善を見せた。複雑なPDF文書を処理する能力を測るGDP.pdfベンチマークでは34.0%を記録し、3.6 Flashの22.0%から12ポイント向上している。

この改善は、静的なPDFをインタラクティブなデータストーリーに変換するというデモで具体的に示されている。複雑な年次報告書を、ライブチャートや集計済みの洞察を含むWeb体験に変換できるというものだ。単なるテキスト抽出を超え、文書構造の理解と再構築が可能になっている。

業務自動化ワークフロー

実世界のビジネスワークフローを完遂する能力を測るAutomationBenchでは、30.4%を記録し、3.6 Flashの17.0%を大きく上回った。この数値は、複数のアプリケーションやデータソースをまたいだ業務フローを、どれだけ正確に遂行できるかを示す指標だ。

STEP 1 ユーザーが自然言語で業務タスクを指示する
STEP 2 3.7 Flashがワークフローを分解して必要なツールを特定する
STEP 3 各アプリケーションを順次呼び出して実データを処理する
STEP 4 結果を統合してファイルを整理し、レポートを作成する

このステップ図は、3.7 Flashが複数ツールを連携させて実業務を自動化する流れを示している。分解したタスクを順番に実行し、最終成果物までまとめ上げる自律性が向上した。

価格改定と開発者体験の改善

導入価格の詳細

3.7 Flashの導入価格は、入力トークン100万個あたり0.75ドル、出力トークン100万個あたり3.75ドルに設定された。これは3.6 Flashの当初価格と比較して半額である。年内いっぱいこの価格が適用される。

Gemini 3.6 Flash 当初価格(Before)
入力 100万個あたり 1.50ドル
出力 100万個あたり 7.50ドル
Gemini 3.7 Flash 導入価格(After)
入力 100万個あたり 0.75ドル
出力 100万個あたり 3.75ドル
※どちらも半額。年内いっぱい適用される

価格が半額になったことと性能向上が組み合わさることで、本番環境でのエージェントを大規模に展開する際のコスト効率が大きく改善する。特に出力トークンの価格引き下げは、長い推論を必要とするエージェント用途で効果を発揮する。

エージェントワークフローへの適合

3.7 Flashは開発者体験の面でも改善されている。障害に遭遇した際の適応力が高まり、必要に応じて意図を明確化するための質問を行う。指示への忠実度も向上した。複数ステップの計画立案とツール呼び出しに、より多くの推論リソースを費やすようになったことで、手動の監視や再試行が減る。

この「規律のある実行」は、エージェントワークフローにおいて重要な意味を持つ。エージェントが途中で誤った判断をして軌道修正が必要になる回数が減れば、開発者の介入コストが削減され、自動化の信頼性が高まるからだ。

Gemini Sparkとの統合と安全性

Gemini Sparkとの統合と安全性

Sparkへの適用

Google AI ProおよびUltraプランの加入者が利用できるパーソナルAIエージェント「Gemini Spark」は、8月13日からGemini 3.7 Flashを基盤モデルとして使用するようになった。SparkはGoogle I/Oで発表された24時間稼働の個人向けエージェントで、ユーザーの指示のもとで自律的にタスクを実行する。

今回のモデル更新により、Sparkはファイルの整理、メールの下書き、ステータス文書の更新などの知識作業をより効率的にこなせるようになった。Google Workspaceアプリとの連携も改善され、複数のスキルを組み合わせた複雑なワークフローの精度が向上している。

安全対策の強化

3.7 Flashは、化学・生物・放射線・核(CBRN)分野およびサイバー攻撃分野における悪用を防ぐための最新の安全対策を備えて出荷される。Google DeepMindのフロンティアセーフティの枠組みに基づき、有益なユースケースを維持しながら悪用リスクを低減する設計になっている。

モデルの詳細な安全性情報や性能データは、公開されているモデルカードで確認できる。エンタープライズ環境で導入を検討する際には、このモデルカードを確認しておくとよい。

利用方法と提供チャネル

利用方法と提供チャネル

3.7 Flashはすでに複数の経路で利用可能だ。開発者はGoogle Antigravityでエージェントファーストのワークフローを試せるほか、Google AI StudioからGemini APIを直接呼び出すことができる。Androidアプリ開発者はAndroid Studioからもアクセス可能だ。

エンタープライズ向けには、Gemini Enterprise Agent PlatformとGemini Enterpriseアプリで提供される。個人ユーザーはGeminiアプリ内のSparkを通じて利用できる。対応国や地域の詳細はGoogleのサポートページに掲載されている。

この記事のポイント

  • Gemini 3.7 Flashは3.6 Flashからわずか3週間で登場した後継モデル
  • コーディングの初回精度が大幅に向上し、再試行コストを削減できる
  • Web開発では少ないプロンプト数で機能的なUIを生成可能
  • 導入価格は3.6 Flash当初価格の半額に設定され、年内いっぱい適用
  • Gemini Sparkの基盤モデルとしても即日採用された
Gemini Robotics ER 2 が登場、動画理解とタスク自動化でロボット知能が進化

Gemini Robotics ER 2 が登場、動画理解とタスク自動化でロボット知能が進化

Google DeepMindは2026年7月30日、ロボット向けの大規模モデル「Gemini Robotics ER 2」を発表した。このモデルは、連続した動画フィードを理解してタスクの進捗を自律的に判断し、複数のロボットを協調させる能力を持つ。

従来のモデルに比べてツール制御や安全性の面で大幅な性能向上が確認されており、GitHub上でサンプルコードも公開された。ロボットが実世界で人間を支援するための基盤技術として注目される。

Gemini Robotics ER 2 の概要と開発者向け提供

Gemini Robotics ER 2 の概要と開発者向け提供

Gemini Robotics ER 2 は、ロボットの「高次脳」として設計されたモデルだ。人間との自然な対話や空間把握、複数ステップのタスク計画を担い、実際の動作は下位の視覚言語行動(VLA)モデルやAPIに委ねる。この階層的な設計により、思考と実行を並列で進めることが可能になる。

開発者は Gemini API、Google AI Studio、Gemini Enterprise Agent Platform(プライベートプレビュー)を通じてモデルを利用できる。スターター用のノートブックが GitHub で公開されており、物理AIタスクへの組み込みがすぐに試せる。

物理的なエージェント能力の進化

物理的なエージェント能力の進化

多くの実作業は複数ステップを必要とする。Gemini Robotics ER 2 は、VLAモデルやナビゲーションAPIなどをツールとして宣言するだけで、動画や音声、テキストのマルチモーダル入力をストリーミング処理し、ロボットの動作を自動的にオーケストレーションする。途中で失敗しても自己修正が可能だ。

ツールオーケストレーションの仕組み

従来のロボット制御では、各動作を人間が順序立ててプログラムする必要があった。Gemini Robotics ER 2 はこれを自動化し、低遅延の双方向ストリーミングを活かして「停止して考える」ような間断のない滑らかな指令を実現する。評価では、実VLA・シミュレーションVLA・遠隔操作の3つの制御モードすべてで前世代のER 1.6を上回る性能を示した。

従来のロボット制御(Before)
開発者 タスクを細分化して手順を固定 固定ルール 動作を順次実行
※環境変化に弱く、手順の修正には人間の介入が必要
Gemini Robotics ER 2 のエージェント制御(After)
ユーザー 自然言語で指示 ER 2 が推論 動画フィードを解析し状況を把握
VLA / API ツール ER 2 が適切なツールを選択して呼び出す
ロボット 自動でタスクを完了、失敗時は自己修正

実機デモと開発リソース

このオーケストレーション能力を示すため、Boston Dynamics の四足歩行ロボット「Spot」を用いたデモが公開された。Gemini Robotics ER 2 が Spot のナビゲーションAPIやマニピュレーターを制御し、自然言語の指示でポップコーンを取りに行く様子が確認できる。対応コードは GitHub の robotics-samples リポジトリから入手可能だ。

タスク進捗把握のための時間的知能

タスク進捗把握のための時間的知能

ロボット工学の大きな課題は「タスクがいつ完了したか」を正確に判断することだ。Gemini Robotics ER 2 は連続動画フィードから進捗を追跡し、電球の締め付けやゴミ袋の結束といった作業が正しく終わったことを検証してから次のステップに移行できる。

連続的な進捗分類

このモデルは動画の各フレームを 0〜20%、20〜40% といった 5 段階の進捗レベルに分類する。その精度は 57.4% に達し、前世代モデルや他の最先端モデルを上回った。これによりロボットはリアルタイムで状況を把握し、途中で動作を調整したり、失敗したステップだけを再実行したりできる。

精密なモーメント検出

「コーヒーを注ぐのを止める瞬間」のような重要なタイミングを特定するモーメント検出では、91.3% の精度と平均絶対誤差 0.96 秒を達成した。大規模モデルと同等の性能を、より少ない計算量と約 4 倍の実行速度で実現している。物理世界で安全に動くために必要なサブ秒レイテンシを満たす点が重要だ。

マルチロボット連携

車輪型ローバーは屋内走行が得意だが、人型ロボットは不整地に強い。Gemini Robotics ER 2 は異なるロボット間で意味的な理解を共有し、タスクの引き継ぎを可能にする。Apptronik の Apollo 2 と Franka F3 Duo が協調して作業を行うデモも公開されている。

単体ロボットによる作業(Before)
人型ロボットA 広いエリアの全タスクを1台で処理
※不整地と棚の両方に対応しきれず、作業効率が低下
マルチロボット連携(After)
ER 2 が全体を統括 ロボットの得意分野に応じてタスクを割り当て
ローバーB 床面の運搬を担当 人型ロボットA 棚からのピックアップを担当

空間知能と安全性の向上

空間知能と安全性の向上

コアな空間推論能力も底上げされた。成功・失敗の検出は静止画ではなく生の動画を扱い、こぼれや滑りといった実行中のミスを捉える。一般計器の読み取りは円形ダイヤルだけでなく、デジタルディスプレイ、リニアスケール、温度計など 10 種類に対応した。空間VQAでもマルチモーダル理解の進歩が活きている。

安全性の面では、安全指示の遵守と人間の近接検知の両ベンチマークでER 1.6や他の競合モデルを上回った。Gemini Robotics ER 2 は近くに人がいることを感知すると人型ロボットを停止させ、エリアが安全になったら自律的に作業を再開する。さらに、安全なVLAオーケストレーターとしての能力を評価する新しいベンチマークも導入された。詳細は安全技術レポートを参照できる。

この記事のポイント

  • Gemini Robotics ER 2 は高次脳としてタスク計画とツール制御を担い、低次動作モデルと組み合わせて使う
  • 連続動画フィードから進捗を5段階で分類し、最適なタイミングで次のステップへ移行できる
  • 複数ロボットの協調が可能になり、台車型と人型が役割分担する実証も進んでいる
  • 安全性ベンチマークで前世代を大幅に上回り、人検知や自己停止が自動で行える
  • Gemini APIやGitHub経由ですぐに試せる開発環境が整っている
Gemini 3.6 Flash登場、3.5 Flash-LiteとCyberも発表。AIエージェント開発の新定番へ

Gemini 3.6 Flash登場、3.5 Flash-LiteとCyberも発表。AIエージェント開発の新定番へ

Google DeepMindは7月21日、AIエージェント開発の最前線を支える3つの新モデル、Gemini 3.6 Flash、3.5 Flash-Lite、3.5 Flash Cyberを発表した。今回のアップデートは、トークン効率の大幅な改善と、速度・コストの両立を追求した点が特徴だ。

3.6 Flashはコード生成や知識処理の精度を高めつつ、出力トークン数を最大65%削減するケースも報告されている。3.5 Flash-Liteは毎秒350トークンという爆速で、エージェントの大規模運用を想定した設計。そして3.5 Flash Cyberは、コードの脆弱性発見と修正に特化し、限定的な提供が始まる。

本記事では、それぞれのモデルの性能と実用面へのインパクトを、開発者視点で詳しく掘り下げる。AIエージェントのコスト構造やアーキテクチャ設計に直結する情報なので、Gemini API を扱うエンジニアは必見だ。

3.6 Flashで加速するトークン効率革命

3.6 Flashで加速するトークン効率革命

出力トークン17%削減がもたらすコストインパクト

3.6 Flashの最大のセールスポイントは、3.5 Flash比で出力トークンを平均17%削減した点だ。Artificial Analysis Indexによる計測で明らかになったこの数字は、単なる省サイズ化を超えた意味を持つ。AIエージェントがマルチステップのワークフローを回す際、出力トークン量はAPI利用料金に直結するからだ。

具体的には、3.6 Flashの価格は入力100万トークンあたり1.50ドル、出力100万トークンあたり7.50ドル。3.5 Flashより安く、かつ出力が短くなったことで、1タスクあたりの実質コストが明確に下がった。エージェントが複数回の推論やツール呼び出しを繰り返すシナリオでは、コスト削減効果が累積的に効いてくる。

コード生成とナレッジワークでの明確なスコア向上

効率化と同時に、ベンチマークスコアも軒並み向上している。ソフトウェアエンジニアリングタスクを評価するDeepSWEでは、3.5 Flashの37%から49%へ向上。機械学習研究向けのMLE Benchでは49.7%から63.9%へと大幅に伸びた。不要なコード編集や実行ループの削減が、精度向上に寄与したと見られる。

また、OSWorld-Verifiedというコンピュータ操作タスクでは78.4%から83.0%へ改善。ドキュメント解析やチャート分析、レポート作成といった知識処理の指標GDPval-AA v2でもスコアを伸ばしている。企業ユーザーのFigmaやHarvey、Hebbiaからも「複雑なワークフローでのコストと品質の両立が進んだ」と高い評価が寄せられている。

従来のエージェントタスク(3.5 Flash)
開発者 プロンプト送信 AI 長文応答(350トークン) ツール実行 さらに応答
※1タスクあたりの出力トークン数が多く、コストがかさむ
改善後のエージェントタスク(3.6 Flash)
開発者 プロンプト送信 AI 簡潔応答(290トークン、17%減) ツール実行 推論ステップも削減
※出力トークン削減により1タスクのAPIコストが低下。マルチステップで効果が大きい

上の図は、エージェントが1つのタスクを処理する際の出力トークン数の違いを模式化したものだ。実際のDeepSWEベンチマークでは最大65%のトークン削減が観測されており、コード生成のような長大な出力が求められる分野ほど恩恵が大きい。

3.5 Flash-Liteが切り開く高速エージェント運用

3.5 Flash-Liteが切り開く高速エージェント運用

毎秒350トークン、低レイテンシと高スループットの両立

Gemini 3.5 Flash-Liteは、速度を極限まで追求したモデルだ。Artificial Analysisの計測では毎秒350トークンの出力を達成。前世代の3.1 Flash-Liteと比較してコーディングやエージェントタスクのスコアが大幅に向上し、実務に耐える品質を備えた。

価格は入力100万トークンあたり0.30ドル、出力100万トークンあたり2.50ドルと、3.6 Flashよりさらに安い。大規模なドキュメント処理やエージェント検索など、大量のリクエストをさばく必要があるシステムに最適だ。開発者は「思考レベル」を設定できるため、低レイテンシが求められる単純タスクでは最小限の推論に抑え、複雑なサブエージェント処理には高思考レベルを割り当てるといった柔軟な運用が可能になる。

3 Flashをも凌駕するエージェント性能

興味深いのは、3.5 Flash-Liteが先代の3 Flashを上回るベンチマーク結果を残している点だ。SWE-Bench Proでは54.2%(3 Flashは49.6%)、OSWorld-Verifiedでは74.0%(同65.1%)と、より高速でありながら高精度を実現している。長期コンテキストタスクのGDM-MRCR v2でも72.2%と、3.1 Flash-Liteの60.1%から大きく伸びた。

Google DeepMindの発表では、3.6 Flashをマスターエージェント、3.5 Flash-Liteをサブエージェントとして組み合わせるユースケースが紹介されている。マスターが全体の指示を出し、大量のサブタスクをLiteが高速に処理するアーキテクチャだ。これにより、Webデザインの複数案を瞬時に生成するといったワークフローが実用的な速度で回せるようになる。

マルチエージェント構成の概念
マスター(3.6 Flash) タスク分割 サブエージェントA(Lite) データ抽出 サブエージェントB(Lite) レイアウト生成
3.6 Flashが司令塔となり、3.5 Flash-Liteが並列で高速処理。1つの重いモデルで逐次処理するより、レスポンスが速くコストも抑えられる。

この構成は、従来の「1つの大きなモデルに全部任せる」スタイルから、役割に応じたモデルを組み合わせるマルチエージェント設計への移行を象徴している。コストと速度のバランスを取る上で、3.5 Flash-Liteの存在は極めて重要になるだろう。

3.5 Flash Cyberがセキュアなコードを変える

3.5 Flash Cyberがセキュアなコードを変える

脆弱性の発見と修正に特化したファインチューニング

3つ目の発表であるGemini 3.5 Flash Cyberは、3.5 Flashをベースにサイバーセキュリティ用途に特化して調整されたモデルだ。コードの脆弱性を高効率で検出し、修正パッチを生成する能力に優れている。単体で使うのではなく、Google DeepMindが開発したコードセキュリティエージェント「CodeMender」と組み合わせることで、複数のCyberエージェントが協調して1つの統合レポートを出力する。

ベンチマークCyberGymにおいて、CodeMender上の3.5 Flash Cyberは最前線クラスの競争力を持つことが示された。大規模モデルに頼らず、価格あたりのトークン単価を抑えつつ高い検出精度を実現している点がポイントだ。

限定的な提供と悪用防止の枠組み

この種の技術には悪用リスクがつきまとう。Google DeepMindは意図的に配布を制限し、政府機関と信頼できるパートナーに対してのみ、CodeMender経由の限定的なアクセスパイロットプログラムとして提供を開始する。フロントラインの防御側が脆弱性を早期に発見・修正できるようになる一方で、広範な悪用を防ぐ設計だ。

このアプローチは、セキュリティAIがいたずらに攻撃者の手に渡ることを防ぎつつ、本来の防御目的を達成する現実的な落とし所と言える。企業のセキュリティチームにとっては、コードレビューの自動化とパッチ生成の高速化が期待できるが、現時点では一般のAPIとしては利用できない点に注意が必要だ。

Gemini Flashシリーズが描くAIエージェントの次なる潮流

Gemini Flashシリーズが描くAIエージェントの次なる潮流

効率・速度・専門性の3軸で攻めるGoogleの戦略

今回の発表から読み取れるGoogleの戦略は明確だ。AIエージェントの実用化においてボトルネックとなる「コスト」「レイテンシ」「専門精度」の3つを、それぞれ最適化したモデルラインナップでカバーしようとしている。

  • 3.6 Flashは汎用的な頭脳として、コストパフォーマンスと品質を高次元でバランス
  • 3.5 Flash-Liteはスピードと低コストを武器に、大量のサブタスクや高スループット処理を担当
  • 3.5 Flash Cyberはセキュリティという特定領域に深く特化し、専門エージェントとして機能

これは単なるモデルバリエーションの追加ではない。開発者がエージェントを設計する際に、「重いモデル1つで全てを処理する」のではなく、役割に応じたモデルを組み合わせるマルチエージェントアーキテクチャを標準化しようとする意図が感じられる。

競合との差別化と実務へのインパクト

OpenAIやAnthropicもエージェント向けの高速モデルを提供しているが、Googleはモデルのバリエーションと価格設定の粒度で一歩抜きん出た印象だ。特に3.5 Flash-Liteの「0.30ドル/1M入力トークン」という価格は、大量のAPIコールが発生するエージェント運用において強力な競争力になる。

さらに、3.6 Flashのトークン効率改善は、単にAPI利用料を下げるだけでなく、出力が短くなることで後続のコンテキストウィンドウ消費を抑え、長大な会話や複数ステップのタスクでも破綻しにくくなる。開発者体験としての「扱いやすさ」が向上している点も見逃せない。

AIエージェントの従来型アーキテクチャ
単一の高性能モデル に全タスクを任せる
※遅延が大きく、単純タスクでも高コスト
Flashシリーズで実現するマルチエージェント構成
司令塔(3.6 Flash) が判断し、 高速処理(3.5 Lite) セキュリティ(Cyber) に委譲
※役割に応じた最適なモデルを使い分け、速度とコストを両立

上の図は、AIエージェントの設計思想の変化を模式化したものだ。Flashシリーズの充実により、開発者は「全部入り」の巨大モデルに頼らず、適材適所でモデルを組み合わせるアーキテクチャを選択しやすくなる。

この記事のポイント

  • Gemini 3.6 Flashは出力トークンを平均17%削減、コードやナレッジ処理の精度も向上
  • 3.5 Flash-Liteは毎秒350トークンの速度で、高スループットなエージェント処理に最適
  • 3.5 Flash CyberはCodeMenderと連携し、コード脆弱性の検出と修正を効率化(限定提供)
  • 3つのモデルは役割を分担するマルチエージェント設計を前提に開発されており、コストと速度の最適化を実現
  • AIエージェント開発は「1つの巨大モデル」から「目的別モデルの組み合わせ」へと移行しつつある
Nano Banana 2 LiteとGemini Omni Flash登場、高速画像生成と動画編集がAPIで利用可能に

Nano Banana 2 LiteとGemini Omni Flash登場、高速画像生成と動画編集がAPIで利用可能に

Google DeepMindは2026年6月30日、高速画像生成モデル「Nano Banana 2 Lite」と、動画生成・編集モデル「Gemini Omni Flash」を開発者向けに公開した。どちらもGoogle AI StudioとGemini APIから即日利用できる。

Nano Banana 2 Liteはテキストから画像をわずか4秒で生成し、1,000枚あたり0.034ドルという低コストが売りだ。Gemini Omni Flashは自然言語による動画編集と高品質な動画生成を両立し、1秒あたり0.10ドルで提供される。

この2つのモデルを組み合わせることで、画像を生成して即座に動画化するといったマルチメディア制作のワークフローが一気に加速する。本記事では各モデルの性能、活用シナリオ、連携方法を詳しく見ていく。

Nano Banana 2 Liteの概要と位置づけ

Nano Banana 2 Liteの概要と位置づけ

Nano Banana 2 Lite(モデル名 gemini-3.1-flash-lite-image)は、Nano Bananaファミリーの中で最も高速かつ低コストな画像生成モデルだ。主に短時間でのプロトタイピングや大量の画像生成が必要な開発パイプラインを想定している。

旧世代モデル Nano Banana(初代)
gemini-2.5-flash-image 標準的な速度とコスト。すでに後継モデルへの移行が推奨されている
新世代モデル Nano Banana 2 Lite(今回公開)
gemini-3.1-flash-lite-image 4秒で生成、1K枚あたり0.034ドル。速度重視の開発に最適
新世代(高効率)  旧世代(移行推奨)

旧モデルであるNano Banana(gemini-2.5-flash-image)からの置き換えが推奨されており、差し替えるだけで速度・品質・コストのすべてで改善が見込める。

速度とコストの具体的な数値

  • レイテンシ(処理時間) テキストから画像を出力するまでの時間は約4秒。対話的なプロトタイピングや下書き用途に向く。
  • 料金 1,000枚あたり0.034ドル。大量生成や予算管理が求められるプロジェクトでコストを抑えやすい。
  • 品質のバランス 速度優先ながら、プロンプトへの忠実度・キャラクターの一貫性・画像内テキストの可読性は確保されている。
Nano Banana 2 Lite の得意領域
速度 4秒で画像出力 コスト 0.034ドル/1K枚 用途 大量生成・高速プロトタイピング
速度・コスト・用途の3軸で最適化されたモデル

Nano Bananaファミリー全体の比較

Nano Bananaシリーズには4つのモデルが存在し、用途に応じて使い分ける設計だ。以下が各モデルの位置づけである。

最速・低コスト Nano Banana 2 Lite(Gemini 3.1 Flash Lite Image) 4秒生成、0.034ドル/1K枚。速度重視のワークフロー向け
バランス型 Nano Banana 2(Gemini 3.1 Flash Image) 品質と速度のベストバランス。汎用ユースケース向け
高精度 Nano Banana Pro(Gemini 3 Pro Image) 複雑なプロ用途向け。速度より正確さを優先
旧世代 Nano Banana(Gemini 2.5 Flash Image) 初代モデル。2 Liteへの移行が推奨されている
最速  バランス  高精度  旧世代

開発者は自分たちのプロジェクトが「速度」を求めるのか「品質」を求めるのかによって、Lite・標準・Proを切り替えられる。たとえば広告バナーの大量生成ならNano Banana 2 Lite、製品写真の精密な加工ならNano Banana Proといった使い分けが現実的だ。

Gemini Omni Flashがもたらす動画編集の変化

Gemini Omni Flashがもたらす動画編集の変化

Gemini Omni Flash(gemini-omni-flash-preview)は、テキスト・画像・動画を組み合わせたマルチモーダル入力をネイティブに扱い、高品質な動画生成と会話型編集を実現するモデルだ。2026年5月のGoogle I/Oで発表され、今回初めてGemini APIとGoogle AI Studioに公開された。

料金は出力動画1秒あたり0.10ドル。Veo 3.1 Fastと同水準であり、動画生成AIとしては競争力のある価格設定だ。

4つの得意領域

機能 1 会話型動画編集 自然言語で動画を調整・編集できる。たとえば「背景を夕方に変えて」といった指示が通る
機能 2 マルチモーダル参照 画像・テキスト・動画を組み合わせて入力し、シーンの一貫性を保ったまま生成できる
機能 3 実世界知識の活用 Geminiが持つ歴史・生物学・物語構造などの知識を動画構成に活かす
機能 4 テキストとアクションの同期 簡単なプロンプトで、動きとテキスト・図形を直接結びつけられる
会話型編集  マルチモーダル参照  実世界知識  テキスト同期

従来の動画生成AIでは「1回のプロンプトで動画を出力して終わり」という単発的な使い方が多かった。Omni Flashは会話を重ねながら微調整できる点が大きく異なる。動画の一部だけを修正したり、複数回の編集を積み重ねたりするワークフローが自然に回せるようになる。

現在の制限事項

  • 生成できる動画の長さは現時点で10秒まで。長時間の動画生成は今後対応予定。
  • 音声参照のアップロードとシーン延長機能は、今回のAPIでは未サポート。
  • APIの仕様上は3秒までの動画参照を受け付けるが、現時点では正しく処理されない。
  • シーン切り替えやパン(カメラの横移動)時のキャラクター一貫性に制限あり。改善中。

「10秒制限」は短く感じるかもしれないが、SNS向けショート動画やeコマースの商品紹介動画であれば十分な長さだ。3秒の動画参照制限についても、短いクリップを下敷きにした編集という使い方であれば実用範囲内といえる。

2つのモデルを連携させた実践ワークフロー

2つのモデルを連携させた実践ワークフロー

Nano Banana 2 LiteとGemini Omni Flashの真価は、両者を組み合わせることで発揮される。具体的には次のような流れだ。

STEP 1 Nano Banana 2 Liteでテキストから画像を高速生成
STEP 2 生成した画像を参照画像としてGemini Omni Flashに渡す
STEP 3 静止画を動画化。会話型編集で微調整を重ねる
STEP 4 Interactions APIでセッション履歴を保持し、最大3回の連続編集をスタック
画像生成  参照渡し  動画化  連続編集

Interactions APIを使うことでセッション履歴とコンテキストが保持されるため、ユーザーは最大3回まで連続した編集を積み重ねられる。1回の生成で終わらない、試行錯誤を前提としたクリエイティブ制作に適した設計だ。

公式デモアプリに見る実用例

Google DeepMindは両モデルを組み合わせた3つのデモアプリを公開している。いずれもGoogle AI Studio上で動作し、ソースコードをリミックスして自社サービスに組み込める。

Anywhere 自撮り写真をアップロードすると、世界中の名所に瞬間移動した画像をNano Banana 2 Liteが生成。画像をタップするとOmni Flashがその場所の動画クリップを生成する
Space Lift 部屋の写真をアップロードすると、Nano Banana 2 Liteが複数のインテリアデザイン案を自動生成。気に入ったデザインをOmni Flashでシネマティックな動画に変換し、空間を体感できる
Omni Product Studio Nano Banana 2 Liteで生成した商品画像を、Omni Flashでシネマティックなeコマース動画に変換。静止画のカタログを動画広告へ素早く展開できる
旅行・観光  インテリア  eコマース

これらのデモは、画像生成と動画編集を別々のAIに任せるのではなく、一つのワークフローとして統合することで生まれる価値を示している。eコマース事業者であれば、商品写真のバリエーションを大量生成し、その中から選んだ数枚だけを動画化するといった効率的な運用が可能になる。

開発者が知っておくべき安全性とモデル情報

開発者が知っておくべき安全性とモデル情報

両モデルともGoogleのセキュアなインフラ上で動作し、SynthIDによる電子透かし(ウォーターマーク)が埋め込まれる。SynthIDはAI生成コンテンツであることを検証可能にする技術で、GeminiアプリやChrome、Google検索を通じてコンテンツの来歴を確認できる。

すでにNano Banana 2 Liteは検索のAI Mode、Geminiアプリ、NotebookLM、Google Photos、Stitch、Google Flow、Google Adsなど、Googleの一般向けサービスにも順次展開されている。

API経由での利用にあたっては、各モデルの詳細な機能やリージョン別の制限が公式ドキュメントにまとめられている。開発を始める前に、Google AI Studioのプレイグラウンドで実際の挙動を試すのが確実だ。

この記事のポイント

  • Nano Banana 2 Liteは4秒で画像を生成し、1,000枚あたり0.034ドルの低コストで利用できる
  • Gemini Omni Flashは自然言語による動画編集と高品質な動画生成を両立し、1秒あたり0.10ドルで提供される
  • 両モデルを連携させると、画像生成から動画化・編集までを一貫したワークフローで回せる
  • Google AI StudioとGemini APIから即日利用可能で、具体的なデモアプリも公開済み
  • SynthIDによるAI生成コンテンツの検証機能が組み込まれており、商用利用にも配慮されている
Gemini 3.5 Flashにコンピュータ操作機能統合、長期業務の自動化を加速

Gemini 3.5 Flashにコンピュータ操作機能統合、長期業務の自動化を加速

Google DeepMindは2026年6月24日、マルチモーダルモデルGemini 3.5 Flashにコンピュータ操作機能を標準搭載したと発表した。これまで専用のGemini 2.5モデルとして提供されていた機能が、メインのFlashモデルに統合された形だ。

この統合により、ブラウザやモバイル、デスクトップ環境をAIエージェントが見て、推論し、実際に操作するという一連の流れが一段と高速かつ安定する。長期間にわたるソフトウェアテストや、複数アプリケーションを横断する知識業務の自動化が、より実用的な選択肢になる。

Gemini 3.5 Flashにコンピュータ操作機能が統合

Gemini 3.5 Flashにコンピュータ操作機能が統合

これまでと何が変わったのか

従来、コンピュータ操作機能はスタンドアロンのGemini 2.5モデルとして提供されていた。このモデルは画面操作に特化していたものの、メインのGemini APIとは別の呼び出しが必要となり、複雑なエージェントを構築する際にレイテンシや統合の手間が課題になりやすかった。

Gemini 3.5 Flashでは、もともと高い性能を誇るFlashモデルに、コンピュータ操作がビルトインツールとして組み込まれている。関数呼び出しや検索、マップグラウンディングと同じレイヤーで扱えるため、開発者は単一のAPIで、テキスト処理から実環境の操作までシームレスに実行できるようになる。

コンピュータ操作機能の仕組み

エージェントは画面のスクリーンショットを画像として受け取り、そのなかのUI要素やテキストを解析する。解析結果に基づいて、次にとるべき操作(クリック、キーボード入力、スクロールなど)を推論し、実際のブラウザやデスクトップ環境でその操作を実行する。このサイクルを繰り返すことで、複数ステップにわたる業務も自動で完遂できる。

コンピュータ操作エージェントの動作サイクル
STEP 1 画面キャプチャを取得(スクリーンショット)
STEP 2 画像を解析し、UI要素と現在の状態を推論
STEP 3 適切な操作(クリック、入力、スクロール)を実行
このサイクルを反復し、複数ステップのタスクを自律的に完了する

このループによって、ユーザーが細かく指示しなくても、自然言語による高レベルの指示だけで長期間の自動化が実現できる。

エンタープライズ向けの安全性対策

エンタープライズ向けの安全性対策

標的型敵対的学習と保護機能

実環境で稼働するエージェントのリスクとして、プロンプトインジェクションや不適切な操作が常に課題となる。Gemini 3.5 Flashでは、こうしたリスクを低減するために、コンピュータ操作に特化した標的型敵対的学習(targeted adversarial training)が施されている。

さらに、企業向けのオプションとして2つの保護機能が提供される。ひとつは、機密性の高い操作や元に戻せない操作を実行する前に明示的なユーザー確認を要求する仕組みだ。もうひとつは、間接的プロンプトインジェクションが検知された場合に、タスクを自動停止する仕組みである。

エンタープライズ保護機能の効果
保護機能なし(Before)
エージェントが危険な操作を即座に実行
操作 データベース削除コマンドを実行しました(確認なし)
保護機能あり(After)
機密操作の前にユーザー確認を要求
エージェント「データベースを削除してよろしいですか?」
いいえ
はい
さらに、間接的プロンプトインジェクションを検出すると自動的にタスクを停止する仕組みも搭載される

多層防御のベストプラクティス

Google DeepMindは、これらの安全機能だけに頼らず、安全なサンドボックス環境の利用や人間による監視・検証、厳格なアクセス制御を組み合わせる「多層防御」を推奨している。これにより、エージェントが予期せぬ行動をとった場合でも、システム全体への影響を最小限に抑えられる。

導入事例と開発者向けリソース

導入事例と開発者向けリソース

顧客の声

すでに複数の企業が、このコンピュータ操作統合から価値を引き出している。BrowserbaseのMiguel Gonzalez Fernandez氏は、エンドツーエンドのテスト自動化が大きく前進し、環境構築の手間が格段に減ったと評価する。Browser UseのMagnus Muller氏は、自然言語による指示だけでブラウザ上の複雑なワークフローが完遂できる点を高く評価している。UiPathのAlvin Stanescu氏は、エンタープライズRPAと生成AIの融合が加速し、ノンコードでの高度な自動化が可能になるとコメントしている。

デモ環境とAPIの利用方法

開発者はBrowserbaseがホストするデモ環境ですぐにコンピュータ操作の挙動を試せる。実際の開発には、Gemini APIのドキュメントに従ってリファレンス実装を参照し、Gemini Enterprise Agent Platformを通じてエンタープライズグレードのエージェントを構築できる。GitHub上で公開されているコードサンプルを活用すれば、自社環境への導入もスピーディに進められる。

Gemini 3.5 Flashのコンピュータ操作統合がもたらす価値

Gemini 3.5 Flashのコンピュータ操作統合がもたらす価値

今回のアップデートは、Googleがエージェント型AIを本格的にエンタープライズ市場へ押し出す明確な一手といえる。競合各社もブラウザ操作機能を提供し始めているが、既存のFlashモデルにビルトインで組み込む手法は、推論コストと応答速度の面で優位に立つ可能性が高い。多数の業務アプリケーションをまたぐシナリオでも、別モデルの呼び出しオーバーヘッドが不要になるからだ。

安全性への取り組みも、この領域での普及を左右するカギを握る。標的型敵対的学習やオプションの確認機能は、金融や医療など厳格なコンプラ要件が求められる業界でもAIエージェントを受け入れやすくする。ただし、まだ攻撃手法の進化は続くため、多層防御を徹底することが現実的な運用には不可欠だ。

開発者視点では、Gemini APIを通じて簡単に試行錯誤できる環境が整ったことが大きい。自社の業務アプリケーションにエージェント操作を組み込むハードルは確実に下がっており、今後数ヶ月で実運用事例が急増するとみられる。

コンピュータ操作導入の流れ
STEP 1 デモ環境で動作を確認
STEP 2 Gemini APIのリファレンス実装をベースにプロトタイプを構築
STEP 3 エンタープライズ向け保護機能を設定
STEP 4 実業務に展開し、多層防御で安全に運用
まずは小規模なタスクから始め、効果を検証しながら徐々に適用範囲を広げるのが推奨される

この記事のポイント

  • Gemini 3.5 Flashにコンピュータ操作機能がビルトインされ、専用モデルの呼び出しが不要になった
  • 画面を見て操作するエージェントが、長期のソフトウェアテストや業務自動化で威力を発揮する
  • 敵対的学習と2つのオプション保護機能により、エンタープライズ環境でも安全性を担保しやすくなった
  • Browserbase、Browser Use、UiPathなどがすでに導入しており、導入用のデモ環境やAPIドキュメントが整備されている
  • 多層防御の考え方を取り入れることで、より堅牢なエージェント運用が実現できる
建築許可の審査期間を半減。英国政府がGemini活用ツール、2027年全国展開

建築許可の審査期間を半減。英国政府がGemini活用ツール、2027年全国展開

英国政府は2029年までに150万戸の新築住宅を供給する目標を掲げている。しかし自治体の計画許可部門は、大量の紙書類と行政手続きの滞留に直面しており、目標達成の大きな足かせとなっている。

この課題に対し、Google DeepMindは英国政府、Google Cloud、ならびにFacultyとの協力のもと、建築許可申請の審査にかかる時間を抜本的に短縮するAIプロトタイプの開発を進めている。目標は担当官の判断にかかる時間を半減させること。2026年6月時点で一部自治体での試験運用が始まっており、2027年には全国のすべてのカウンシルで利用可能になる見通しだ。

建築許可のボトルネックとAI活用の背景

建築許可のボトルネックとAI活用の背景

年間の計画申請のうち、住宅所有者による増築やロフト改修といった比較的単純な申請が約7割を占める。ところが担当官は一件ごとに地域の方針書、過去の許可事例、住民からの意見書など大量のPDFを手作業で照合しなければならず、この単純作業が大きなボトルネックになっている。

こうした背景から、英国政府のAIインキュベーター(i.AI)はすでにExtractというツールを開発し、旧来の文書を構造化データに変換する取り組みを進めてきた。今回のプロトタイプは、その土台の上にGeminiによる高度な解析支援を組み合わせ、審査プロセス全体を加速させる狙いがある。

AIが支援する新たな計画審査プロトタイプ

AIが支援する新たな計画審査プロトタイプ

このプロトタイプは、Barnet、Camden、Dorsetの3つの自治体と共同で開発が進められている。計画担当官にとっては「熟練したアシスタント」のように機能し、データ抽出や事例分析といった重労働を肩代わりする。具体的には以下の4つの作業をAIが自動化する。

  • データ統合:滞留している申請情報を前処理し、不足データの可視化やサイト主要情報の抽出を行う。担当官は1つの画面で全体を把握できる。
  • 地域方針の照合:国および地域の関連方針を自動でハイライトし、事前にコンプライアンスを評価。正確な引用情報を添えて担当官に提示する。
  • 住民意見の要約:個別の意見書を分析し、主要な反対意見や判例を要約する。
  • 審査レポートの下書き作成:最終報告書の初稿を生成し、判断の根拠や提案する条件を整理する。

ここで重要なのは、最終的な判断を下すのは常に計画担当官であり、人間の監視が必ず残る点だ。プロトタイプは生成した文章を一歩一歩記録し、明確な思考の連鎖と監査証跡を残す設計になっている。担当官はAIが提案した内容を一行ずつレビューし、根拠を編集したうえで許可・却下を決定する。

従来の手動作業(Before)
計画担当官 申請書類のPDFを印刷し内容を読み込む
計画担当官 地域方針文書や過去事例を手動で照合
計画担当官 住民からの意見書を1通ずつ要約
計画担当官 すべての情報を基にレポートを一から作成
AI支援ツール導入後(After)
AIツール 全書類を自動解析し、不足項目と重要情報を統合
AIツール 関連方針を抜き出し、引用付きでコンプライアンス事前評価
AIツール 全意見書を要約し主要な反対意見や判例を抽出
AIツール 根拠と条件を示したレポートの初稿を自動生成
計画担当官 AI下書きを一行ずつレビューし、最終判断を下す

手動では数時間かかっていた作業が、AIによる事前のデータ整理と下書き作成によって大幅に短縮される。計画担当官は単純な転記や照合から解放され、より複雑な案件や公共の利益に資する判断に集中できるようになる。

試運用で見える効果と全国展開への展望

試運用で見える効果と全国展開への展望

今回のプロトタイプのベースとなったExtractは、すでに20以上の自治体で試験運用され、平均的なカウンシルで年間約255時間の手動作業を削減できる実績を残している。2026年6月には全イングランドのカウンシルで利用可能となり、旧式のPDFをわずか数分で構造化データに変換できるようになった。

新しいAIツールはこのExtractの成果に加え、審査そのものの自動下書きまで踏み込んでいる。Barnet、Camden、Dorsetでの初期試験を経て、英国政府は2027年から全国すべてのカウンシルに展開する計画だ。もし全国で導入されれば、担当官の審査時間が半減し、戸建て住宅の増改築といった日常的な申請が迅速に処理されるようになる。これにより住宅供給の加速だけでなく、地域経済の活性化にもつながると期待されている。

行政におけるAI活用では、透明性と説明責任の確保が常に課題となるが、今回のプロトタイプは全ステップを記録し、人間が最終判断する設計を徹底している点が特徴だ。AIが下書きを生成し、担当官がそれを検証・修正するハイブリッド型のワークフローは、他の公共サービス分野にも応用可能なモデルケースとなるだろう。

この記事のポイント

  • 英国政府とGoogle DeepMindがGeminiを活用した建築許可審査AIツールを共同開発中
  • 書類統合、方針照合、意見要約、レポート下書きの4機能で担当官の負荷を大幅に軽減
  • 計画担当官が最終判断を保持し、全ステップが監査証跡として記録される設計
  • 試験運用を経て2027年までにイングランド全カウンシルへの提供を予定
  • 単純作業の自動化により住宅供給の加速と行政リソースの最適化が期待される
GeminiがApple Foundation Modelsフレームワークに対応、Firebase経由でプレビュー提供開始

GeminiがApple Foundation Modelsフレームワークに対応、Firebase経由でプレビュー提供開始

WWDC 2026において、AppleはFoundation Modelsフレームワークをサードパーティのモデルアダプタに開放した。iOS 27やmacOS 27など最新OSで、各モデル提供者がLanguageModelプロトコルを実装し、独自のAIモデルをデバイス上で動かせる仕組みだ。これにより、オンデバイス推論とクラウド推論をアプリ内で自由に切り替えられる可能性が大きく広がる。

そして本日、FirebaseがこのフレームワークにGeminiクラウドモデルをもたらすインテグレーションのプレビューを公開した。すでにFoundation Modelsフレームワークを利用している開発者であれば、わずかなコード変更でオンデバイスモデルをGeminiに置き換えられる。Firebase App Checkによるリクエスト認証も組み込まれ、安全なAPIコールが実現する。

本記事では、この統合の概要、コードの実装イメージ、セキュリティ設計、そして対応可能な機能群を整理する。

Apple Foundation Modelsフレームワークとは

Apple Foundation Modelsフレームワークとは

Foundation Modelsフレームワークは、Appleが提供するデバイス上AI推論の公式APIセットだ。これまでApple Intelligenceで使われるオンデバイスモデルが主な対象だったが、今回のWWDC 2026で第三者モデルアダプタへの門戸が開かれた。

具体的には、LanguageModelプロトコルを実装した任意のモデルインスタンスを用意し、LanguageModelSessionに渡すことで、respond(to:)streamResponse(to:)といった共通メソッドで推論を取得できる。テキストだけでなく画像や音声、動画などのマルチモーダル入力も、プロトコル内で一元的に扱える設計だ。

このフレームワークはオンデバイス処理に最適化されているが、クラウドモデルとの共存を前提とするアーキテクチャも整っている。開発者はネットワーク状態やタスクの重さに応じて、どのモデルを使うかをコード内で自由に決定できる。

FirebaseがGeminiを橋渡しする

FirebaseがGeminiを橋渡しする

今回のプレビューで、FirebaseはAppleのFoundation ModelsフレームワークにGeminiクラウドモデルを統合するアダプタを提供した。Firebase AI Logicライブラリを経由し、LanguageModelプロトコルに準拠したGemini APIコールが可能になる。

大きなメリットは、オンデバイスモデルとGeminiクラウドモデルが同一のAPIサーフェスの背後に隠れることだ。開発者はSystemLanguageModelの代わりにGeminiLanguageModelをインスタンス化するだけで、残りのコードを一切変更せずに推論先を切り替えられる。

従来のオンデバイス専用(Before)
SystemLanguageModel デバイス上で推論
プライバシー重視だがオフライン以外の機能に制限
Firebase経由でGemini統合(After)
GeminiLanguageModel Firebase AI Logic Gemini APIで推論
大規模コンテキストやリアルタイム情報検索に対応

このデモにあるとおり、開発者は単にモデルインスタンスを切り替えるだけで、アプリの推論基盤をオンデバイスからクラウドへ、あるいはその逆に切り替えられる。実際のコード量は数行の差でしかない。

コード変更は最小限

コード変更は最小限

既存コードとの互換性

Foundation Modelsフレームワークを使っているプロジェクトでは、@Generableによるパース構造も、SwiftUIビューも、ツール定義もそのまま流用できる。変更が必要なのは、セッションに渡すモデルをGeminiLanguageModelに置き換える箇所だけだ。

この設計は、カスタムのハイブリッド推論を自前で構築する開発者にとって強力だ。オンデバイスとGeminiの両方が同一プロトコルを共有しているため、アプリの状態や要件に応じて「どのモデルに問い合わせるか」を1リクエストごとにコードで制御できる。フレームワークが自動でルーティングするのではなく、判断は開発者の手に委ねられている。

実装コード例

以下は実際のSwiftコードの抜粋である。Firebase AI LogicとApp Checkをセットアップし、gemini-3.5-flashを使ってストーリーを生成する例だ。

import FirebaseAppCheck
import FirebaseCore
import FirebaseAILogic
import FoundationModels

// App起動時にFirebaseを構成
AppCheck.setAppCheckProviderFactory(AppCheckDebugProviderFactory())
FirebaseApp.configure()

func generateStory(
    topic: String,
    wordCount: Int,
    language: String
) async throws -> String {
    let ai = FirebaseAI.firebaseAI()
    let model = ai.geminiLanguageModel(name: "gemini-3.5-flash")

    let session = LanguageModelSession(
        model: model,
        instructions: """
        You are a creative storyteller who writes engaging, vivid prose.
        You must write strictly in \(language).
        Your stories must be approximately \(wordCount) words long.
        You must return ONLY the story text. 
        Do not include a preamble, title, or conversational filler.
        """
    )

    let response = try await session.respond(
        to: "Write a short story about \(topic)."
    )

    return response.content
}

// 使用例
let story = try await generateStory(
    topic: "a lighthouse keeper who discovers a message in a bottle",
    wordCount: 300,
    language: "Spanish"
)
print(story)

FirebaseAI.firebaseAI()でモデルインスタンスを取得し、LanguageModelSessionに渡す流れは、オンデバイスモデルを使う場合と完全に同じだ。モデル名をgemini-3.5-flashに指定する点が唯一の差分となる。

セキュリティ設計

セキュリティ設計

Firebase AI Logicを経由したGeminiへのリクエストは、すべてFirebase App Checkによる認証が適用される。改ざんされた端末やエミュレータ、スクリプトからの不正な呼び出しは、モデルに到達する前に遮断される仕組みだ。

App Checkの証明プロバイダをAppleアプリ向けに設定し、クライアントからの全APIアクセスに適用することで、Gemini連携機能のセキュリティを強化できる。この証明はFirebase側で強制されるため、開発者は最低限の設定を行うだけで安全な呼び出し基盤を手に入れられる。

STEP 1 アプリがFirebase AI Logicへリクエスト
STEP 2 App Checkが端末の正当性を検証
STEP 3 認証成功時のみGemini APIへ転送

Firebase AI Logicは単なる中継ではなく、証明と認可のゲートキーパーとして機能する。これにより、クライアントサイドのSwiftアプリから直接安全にGemini APIを呼び出す環境が整う。

テキストを超えた活用領域

テキストを超えた活用領域

この統合を使えば、テキスト生成だけでなく多彩な機能をアプリに組み込める。以下が主なユースケースとなる。

  • 実世界の情報に基づく回答googleMapsgoogleSearchツールをセッションに登録することで、最新の店舗情報やWeb情報を引用した応答を生成できる。
  • マルチモーダル入力:画像、音声、動画、PDFをプロンプトとともに渡し、テキスト以外の情報を理解する機能を提供する。
  • 画像生成:Nano Bananaモデルによる会話型の画像生成と編集が行える。
  • ストリーミング応答streamResponse(to:)を使えば、長い回答も体感速度を落とさずに表示可能。マルチターンのチャット履歴管理もフレームワークが担う。
  • エージェント機能:ツール呼び出しを使ってアプリ内のコードをGeminiが実行し、思考署名(thought signatures)がセッションをまたいだ推論の一貫性を保持する。

いずれもLanguageModelプロトコル上で統一されたインタフェースのまま扱えるため、追加のSDK学習は不要だ。

導入ステップ

導入ステップ

プレビュー段階ではあるが、すでにSwiftアプリからFirebaseを使っているプロジェクトなら、セットアップの大部分は整っている。最短で動作確認まで進む手順は以下のとおり。

  1. Firebaseコンソールでプロジェクトを作成し、Appleアプリを登録する。
  2. Firebase AI Logicを有効にし、Gemini APIプロバイダ(無料枠のGemini Developer APIまたはエンタープライズ向けGemini Enterprise Agent Platform API)を選択する。
  3. XcodeでFirebase Apple SDKをSwift Package Manager経由で追加する。プレビュー期間中は依存ルールにブランチwwdc26-previewを指定する。
  4. FirebaseAILogicライブラリを追加し、アプリ起動時にFirebaseApp.configure()を呼び出す。
  5. Geminiを利用する箇所でimport FirebaseAILogicし、前述のコード例に沿ってモデルインスタンスを生成する。
  6. App Checkの証明プロバイダを設定し、デバッグ用であっても必ず有効化してから実機で動作確認する。

詳細な手順は公式のスタートガイド(Firebaseコンソール内)にも記載されているため、合わせて参照してほしい。

この記事のポイント

  • WWDC 2026で公開されたFoundation Modelsフレームワークに、Firebase経由でGeminiクラウドモデルが接続可能になった。
  • オンデバイスモデルとGeminiは同一のLanguageModelプロトコルで扱えるため、コード変更はモデルインスタンスの差し替えのみで済む。
  • Firebase App Checkによるリクエスト認証が組み込まれ、クライアントからの安全なAPI呼び出しが担保される。
  • テキスト生成にとどまらず、最新情報検索、画像生成、マルチモーダル入力、エージェント機能など多様なユースケースに対応する。
Gemini 3.5 Live Translate公開、自然な音声翻訳の全容

Gemini 3.5 Live Translate公開、自然な音声翻訳の全容

はじめに

はじめに

Gemini 3.5 Live Translateが2026年6月9日に公開された。これは音声をリアルタイムで翻訳し、話者の抑揚や間合いを保ったまま自然な音声を生成するAIモデルだ。

従来の逐次翻訳とは異なり、相手が話し終えるのを待たずに翻訳を開始する。遅延は数秒程度に抑えられ、70以上の言語を自動検出して処理する。Google DeepMindが発表した本モデルは、開発者向けAPIやGoogle Meet、Google翻訳アプリを通じて順次利用可能になる。

このリリースは、音声翻訳の「待ち時間」という長年の課題に正面から取り組んだものだ。翻訳品質とリアルタイム性の両立にどこまで迫れたのか、開発者や企業にとっての実用性はどの程度か、本記事で詳細を解説する。

従来の逐次翻訳(Before)
話者A(日本語) 話し終えるまで待機 翻訳エンジン 全文処理後に出力
※無音の間が発生し、会話のテンポが損なわれる
Gemini 3.5 Live Translate(After)
話者A(日本語) 発話しながらストリーム送信 Gemini 3.5 数秒遅れで連続出力
※抑揚や間合いを保持した自然な会話が実現

上図のように、逐次翻訳の「全文処理待ち」というボトルネックが解消される。リアルタイム性を重視するビデオ会議や同時通訳の現場では、この差が決定的だ。

Gemini 3.5 Live Translateの技術的な特長

Gemini 3.5 Live Translateの技術的な特長

音声ストリーミングによる連続翻訳

最大の特長は、音声をストリーミング処理しながら翻訳結果を連続的に生成する点にある。話者が文を完結させるのを待たず、部分的な発話から逐次翻訳を開始する。

この方式では「コンテクストを待って翻訳精度を高める」ことと「即座に翻訳を開始する」ことのトレードオフが発生する。Gemini 3.5 Live Translateは、両者のバランスを自動調整しながら、自然な間合いを保ったまま数秒の遅延で追随する。

音声通話において「間」はコミュニケーションの質を大きく左右する。2秒の無音がストレスになるシーンは多い。本モデルはその課題に直接応える設計思想だ。

70以上の言語を自動検出して翻訳

手動での言語設定は不要だ。入力音声を分析し、70以上の言語を自動識別する。多言語が混在する会議やイベントでも、参加者ごとの言語選択といった事前設定なしに翻訳が動作する。

多言語対応の自動化は、実際の運用負荷を大幅に下げる要素だ。特にエンタープライズ領域では、IT管理者が会議ごとに翻訳設定を手動で行う手間が削減される。

抑揚・テンポ・ピッチの保持

単なる文字起こし翻訳とは異なり、元の話者の声の高さや抑揚、話す速度までも翻訳音声に反映する。これにより「機械的な翻訳音声」から「人格を感じる翻訳」へと体験が変化する。

感情表現や強調、皮肉といったパラ言語情報が翻訳でも伝わる可能性が生まれる点は、ビジネス通話や国際交渉の現場で特に重要だ。

翻訳音声の品質要素
保持される要素 声の高さ(ピッチ) 話す速度(テンポ) 抑揚(イントネーション)
従来の課題 平坦な機械音声 不自然な間合い 感情表現の喪失
3.5 Live Translateで改善  従来モデルの弱点

ノイズ耐性の高さ

屋外やイベント会場など、騒がしい環境でも動作するノイズ耐性を備えている。Google DeepMindの公式ブログでは「loud, unpredictable environments(騒がしく予測不能な環境)」でもアプリケーションが機能すると明記されている。

これは実用面で極めて重要な仕様だ。空港や駅、工事現場、混雑したカンファレンス会場など、現実の翻訳需要は静かな会議室だけではない。ノイズ耐性の高さは、本モデルが実世界での利用を前提に設計されている証左と言える。

開発者向けの提供形態とAPI活用法

開発者向けの提供形態とAPI活用法

Gemini Live APIとGoogle AI Studio

開発者はGemini Live APIを通じて本モデルにアクセスできる。現在はパブリックプレビュー段階で、Google AI Studioからも試用可能だ。

APIを利用すれば、自社のビデオ会議システムや通話アプリ、配信プラットフォームにリアルタイム翻訳機能を組み込める。音声ストリームをAPIに送信するだけで翻訳音声が返ってくるため、インフラ構築のハードルは低い。

API連携の流れ
STEP 1 音声ストリームをGemini Live APIに送信
STEP 2 Gemini 3.5がリアルタイムで翻訳処理
STEP 3 翻訳済み音声がアプリケーションに返却
STEP 4 エンドユーザーに再生

対応する開発者プラットフォーム

Agora、Fishjam、LiveKit、Pipecat、Vision Agentsといったプラットフォームが既にGemini Live APIとの統合を完了している。これらのプラットフォームはリアルタイムメディアストリーミングの複雑なインフラ部分を抽象化するため、開発者はユーザー体験の設計に集中できる。

Google DeepMindのGitHubリポジトリ(Gemini Cookbook)では、LiveKitを使った同時多言語翻訳のデモコードが公開されている。実際の実装イメージを掴みたい開発者は参照するとよい。

Grabでの導入事例

東南アジアの配車サービス大手Grabは、ドライバーと乗客間の多言語通話に本モデルを試験導入している。同社では月間1,000万件以上の音声通話が発生しており、ピックアップ時のコミュニケーション障壁を低減する狙いだ。

多言語国家での配車サービスでは、ドライバーと乗客の言語不一致が日常的に発生する。リアルタイム翻訳が実用レベルに達すれば、この摩擦は大幅に軽減される。Grabの事例は、本モデルの実運用における有効性を示す重要な先行例である。

Google MeetとGoogle翻訳アプリでの展開

Google MeetとGoogle翻訳アプリでの展開

Google Meetでの通訳機能が大幅強化

Google Meetの音声翻訳機能にGemini 3.5 Live Translateが統合される。従来は5言語のみの対応だったが、70以上の言語に拡大される。さらに、英語を介した翻訳のみだった制限が外れ、2,000以上の言語ペアでの双方向翻訳が可能になる。

従来のGoogle Meet翻訳(Before)
対応言語数、5言語のみ 翻訳方向、英語⇔他言語の1対1 UI、設定画面で手動選択が必要
Gemini 3.5 Live Translate統合後(After)
対応言語数、70以上の言語 翻訳方向、2,000以上の言語ペアで双方向 UI、即時アクセス可能なインターフェースに刷新

本機能は今月から一部のGoogle Workspace企業向けにプライベートプレビューとして提供開始され、年内に広範なロールアウトが予定されている。

Google翻訳アプリでの新体験

AndroidおよびiOS版のGoogle翻訳アプリにも本モデルが展開される。有線・無線を問わずヘッドフォンを接続するだけで、70以上の言語に対応したリアルタイム翻訳が利用可能になる。

特に注目すべきはAndroid向けの新機能「リスニングモード」だ。スマートフォンを受話器のように耳に当てるだけで、翻訳音声が端末のイヤースピーカーから直接再生される。ヘッドフォンを持っていない場面や、周囲に翻訳音声を聞かれたくない場面で有用だ。

例として、スペイン語のガイドツアーを英語の翻訳音声で聞くといったユースケースが公式ブログで紹介されている。観光や出張先での利用シーンが明確に想定されている。

SynthIDによる安全性担保

本モデルが生成するすべての音声には、SynthIDによる電子透かしが埋め込まれる。この透かしは人間の耳では検知できないが、AI生成音声であることを機械的に判別可能にする。

音声のAI生成が一般化するにつれ、なりすましや偽情報への対策は避けて通れない課題だ。リアルタイム翻訳という機能の利便性と、AI生成コンテンツの検出可能性を両立させる設計は、今後のAIサービスにおける標準的な取り組みになるだろう。

詳細な安全性の取り組みについては、Google DeepMindが公開するモデルカードで確認できる。

この記事のポイント

  • Gemini 3.5 Live Translateは70以上の言語を自動検出し、話者の抑揚を保ったまま連続的に翻訳する
  • 従来の逐次翻訳とは異なり、話し終えを待たずに数秒遅れで追随するストリーミング処理を採用
  • 開発者はGemini Live APIやGoogle AI Studioからパブリックプレビューとして利用可能
  • Google Meetでは対応言語が5から70以上に拡大し、2,000超の言語ペアでの双方向翻訳が実現
  • 生成音声にはSynthIDの電子透かしが埋め込まれ、AI生成コンテンツの検出が可能
Google AI Threat Defense発表、AIで脆弱性を自動修正する次世代セキュリティ

Google AI Threat Defense発表、AIで脆弱性を自動修正する次世代セキュリティ

Google Cloudは2026年5月27日、AIを活用したセキュリティプラットフォーム「Google AI Threat Defense」を発表した。このシステムは脆弱性のスキャンから修正までを自律的に実行し、攻撃者が悪用する前に防御を固めることを目的としている。

AIの進化に伴い、攻撃者は従来の手作業による対策では追いつけないスピードで脆弱性を悪用するようになった。AI Threat DefenseはWiz、CodeMender、Gemini、Mandiantの各テクノロジーを統合し、組織が機械的な速度で脅威に対抗できる環境を提供する。

AI Threat Defenseが目指す次世代セキュリティ

AI Threat Defenseが目指す次世代セキュリティ

近年、サイバー攻撃の高速化が顕著だ。従来は数週間かけて実施されていた攻撃が、AIエージェントの支援により数時間〜1日程度で完了するケースが増えている。防御側もこのスピードに追随する必要があり、人手による脆弱性管理やパッチ適用だけでは限界がある。

Google Cloud Blogの記事では、単一のAIモデルですべての脆弱性を捕捉することは難しく、コストと性能のバランスを取るために軽量なモデルと最先端のモデルを組み合わせて使うマルチモデル戦略が有効だと説明している。AI Threat Defenseは、ジェネレーティブAIの推論能力とコード生成能力を核に据えた自動防御システムとして、この考え方を具現化したものだ。

従来の脆弱性管理(Before)
人手中心のスキャンと手動パッチ適用
脆弱性発見から修正まで数週間
大量のアラートに埋もれ、優先順位付けに時間がかかる
AI Threat Defense(After)
AIによる自動スキャン・優先順位付け・パッチ生成
数分〜数時間で修正完了
実際に悪用可能なリスクのみを抽出し、開発者の負荷を軽減

上の比較は、従来型の反応的なセキュリティ運用と、AI Threat Defenseがもたらす自律的な運用の差を端的に表している。プロセス全体が機械速度で回ることで、攻撃者が脆弱性を悪用する「タイムウィンドウ」を最小化できる点が最大の強みだ。

4つのコンポーネントが支える統合防御

4つのコンポーネントが支える統合防御

AI Threat Defenseは、単一の製品ではなく、複数のクラウドセキュリティ技術を組み合わせた統合プラットフォームだ。基盤にはGoogleのジェネレーティブAIモデル「Gemini」の推論エンジンがあり、周辺にクラウドセキュリティの可視化を担うWiz、コード修正を自動化するCodeMender、そして現場のサイバー攻撃対策ノウハウを持つMandiantが配置される。

Wizによる可視化とリスク優先付け

WizはアプリケーションやAPI、ID、設定、ビジネスロジックなど、クラウド環境のあらゆる要素を継続的に可視化し、実際に悪用可能な攻撃パスをマッピングする。従来の攻撃面管理(ASM)を超え、AIペネトレーションテストエージェントが複雑な連鎖リスクを自動検証する。この結果、ただの脆弱性リストではなく、事業リスクを反映した優先順位付きの修復計画が出力される。

CodeMenderによる自律的なコード修正

CodeMenderはGeminiのコード生成力を活用し、開発者のIDEやCLIに直接パッチ候補を提示する。脆弱なコードの置換、レガシーコードのメモリ安全な言語への書き換え、ライブラリ依存関係の調整までをカバーし、修正後の自動テスト生成も行う。これにより、パッチの生成から検証までの時間が大幅に短縮される。

Geminiの推論とマルチモデル戦略

AI Threat DefenseはGemini Enterprise Agent Platform上で複数の最先端モデルを動かし、モデルごとに得意なタスク(アプリケーションロジック分析、クラウド設定監査、バイナリ解析など)に割り当てる。軽量モデルで広くスキャンし、フロンティアモデルを最高リスク領域に集中させることで、コスト効率と検出範囲の両立を実現している。

Mandiantの現場知見と運用ガイダンス

Mandiantはこれまでに蓄積したサイバー攻撃の最前線知識を、AI駆動の修復プロセスに注入する。重大な脆弱性が一気に表面化した場合の対応戦略や、旧式システムの安全な停止方法、AI生成パッチをエンジニアリングチームに負荷をかけずに展開するノウハウなど、実践的なガイダンスが提供される。

脅威対策の4段階フレームワーク

脅威対策の4段階フレームワーク

AI Threat Defenseの運用は「準備(Prepare)」「スキャンと優先順位付け(Scan and prioritize)」「修正(Remediate)」「監視(Monitor)」の4段階で構成される。各ステップがシームレスに連携し、攻撃者が悪用するスピードに追いつくための機械的なワークフローを形成する。

STEP 1 準備 基盤を強化し、リスク露出を削減する
STEP 2 スキャンと優先順位付け 深掘り分析とAIによる悪用可能性の検証
STEP 3 修正 自律的にパッチを生成・適用し、修正を検証
STEP 4 監視 継続的な検出とリアルタイム対応

このフレームワークでは、各段階が独立しているのではなく、リアルタイムのリスク情報に基づいてループする。たとえば監視中に新たな暴露経路が見つかれば、即座にスキャンへ戻り、自動的にパッチが生成される。

STEP 1 準備(Prepare)

まず重要なのは、攻撃対象領域を最小化することだ。インターネットから直接到達可能なセンシティブな資産や、信頼できない経路で露出しているサービスを特定し、パッチの有無にかかわらず接続経路そのものを削減する。同時に、各チームの責任範囲とエスカレーションフローを明確化し、次の脆弱性が発見されたときに即応できる体制を整える。

STEP 2 スキャンと優先順位付け(Scan and prioritize)

この段階では、AIによる多層的な分析が行われる。軽量モデルで全資産を継続的にウォッチしつつ、インターネット向けアプリケーションや認証機能などビジネスクリティカルな部分にはフロンティアモデルを用いた深掘りスキャンを実施する。Wizのリアルタイムコンテキストと連携し、単なるコード上の欠陥ではなく「実際に攻撃可能か」という観点で優先度が決定される。

STEP 3 修正(Remediate)

特定された脆弱性は、CodeMenderによって自動的に修正案が生成される。開発者はIDE上でパッチ候補を確認し、承認するだけでよい。また、ライブラリの変更が他のコンポーネントに与える影響も分析され、複数リポジトリにまたがる安全なロールアウトが支援される。修正後には自動テストが走り、パッチの有効性を検証する仕組みも組み込まれている。

STEP 4 監視(Monitor)

最後の監視フェーズでは、Google Security Operationsが提供するエージェント型SOC機能を活用し、ネットワーク、ID、アプリケーションのテレメトリを横断的に分析する。AIが不審な挙動を自律的に検出し、場合によっては自動で封じ込めアクションを発動する。また、日次でビルド・署名されたハードニング済みコンテナイメージを用いることで、基盤自体のセキュリティも維持される。

実践導入とパートナーエコシステム

実践導入とパートナーエコシステム

AI Threat Defenseは、単にツールを導入するだけでは機能しない。クラウドアーキテクチャに適したセキュリティ設計と、既存の開発パイプラインへの組み込みが必要になる。そのため、Google CloudはAccenture、Deloitte、PwC、Netenrich、TENEX.AIなどのパートナー企業と協業し、導入から継続的な管理、カスタムワークフローの構築までを支援する体制を整えている。

パートナー企業の役割

各パートナーは、顧客固有のクラウド構成を評価し、AI駆動のセキュリティ運用を定着させるためのハーネス(カスタム連携基盤)を開発する。これにより、組織ごとのコンプライアンス要件や運用ポリシーに合わせたきめ細かな防御が可能になる。

Google自身のセキュリティ実績

Google Cloudは、このプラットフォームを自らのセキュリティ運用実績の上に構築している。同社は10年以上にわたり、Titanチップによるハードウェア保護やZero Trustアーキテクチャの先駆的導入を進めてきた。現在も毎分数千万件のスパムを自動ブロックし、数十億のユーザーを保護している。こうしたノウハウが、AI Threat Defenseの設計思想に深く反映されている。

この記事のポイント

  • AI攻撃の高速化に対抗するため、Google Cloudが自律型防御プラットフォーム「AI Threat Defense」を発表
  • Wiz、CodeMender、Gemini、Mandiantの4要素を統合し、脆弱性の可視化からパッチ適用までを機械速度で自動化
  • 従来の人間主導のプロセスでは数週間かかっていた対応が、数分〜数時間に短縮される見込み
  • 「準備→スキャン→修正→監視」の4段階フレームワークで、攻撃者が悪用する前に防御を完了させる
  • パートナー企業による実装支援と既存の開発パイプラインへの統合が、導入の鍵を握る