Google on KnightLiブログ

Chrome Enterprise Premium が MCP に対応：AI agent がブラウザのセキュリティ管理に参加

Fri, 29 May 2026 15:25:32 +0800

Google Security は Chrome Enterprise Premium MCP Server を公開し、Chrome Enterprise Premium の一部のセキュリティ管理機能を MCP 互換の AI agent に開放しました。これはオープンソースの MCP Server であり、企業の IT チームとセキュリティチームが Gemini CLI などのツールを通じて、自然言語で Chrome ブラウザのセキュリティ管理タスクを照会、分析、処理できるようにすることを目的としています。

これは「ブラウザにチャットボットを追加する」ものではありません。企業向けブラウザ管理のバックエンドを agent のツールチェーンにつなぐものです。大企業にとって、ブラウザはすでに従業員が SaaS、社内システム、機密データにアクセスする主要な入口です。AI agent がポリシー、ログ、セキュリティ状態を理解できるようになる意味は、見た目以上に大きいものです。

何ができるのか

Google の説明によると、Chrome Enterprise Premium MCP Server はチームの次のような作業を支援できます。

Chrome Enterprise Premium 環境内の設定とセキュリティ状態を照会する
企業向けブラウザ管理の健全性を確認する
セキュリティログとイベントの手がかりを分析する
DLP 関連ルールの設定や確認を支援する
自然言語で調査と対応の提案を生成する

これらの機能は、agent が管理者に代わって自由に判断できるという意味ではありません。より正確には、これまで管理コンソール、ドキュメント、ログシステムに分散していた情報をツールインターフェースとして AI アシスタントに公開し、調査とガバナンスの流れをより一貫したものにします。

なぜブラウザセキュリティは agent に向いているのか

ブラウザセキュリティ管理は本質的に複数のコンテキストを扱う問題です。1 回の異常なアクセスには、デバイス状態、ユーザー ID、ブラウザバージョン、拡張機能、DLP ポリシー、アクセス先サイト、ダウンロード動作、ログイベントが関係する可能性があります。

人手で処理する場合、セキュリティ担当者は複数のページを行き来しながら、どのポリシーがどのユーザーに影響するかも覚えておく必要があります。AI agent が MCP を通じてこれらの状態を読み取れるなら、初期の要約と調査を担えます。

まず環境の健全性を確認する。
異常な設定や高リスク項目を見つける。
ログに基づいてユーザー、デバイス、アクセス行動を関連付ける。
次の調査ステップを提案する。
管理者が実行可能なポリシー調整案を作るのを助ける。

この種のタスクは単なるテキスト生成ではありません。実際のシステム状態の集合を中心に、照会、判断、絞り込みを繰り返す作業です。MCP はこうした作業を担うのに適しています。

Gemini CLI との関係

Google は記事の中で、この MCP Server を Gemini CLI から利用できると述べています。Gemini CLI は開発者や技術ユーザー向けのコマンドライン AI ツールであり、MCP Server はそこに Chrome Enterprise Premium の管理機能へアクセスするためのインターフェースを与えます。

この組み合わせは象徴的です。CLI が対話の入口を提供し、MCP がツールプロトコルを提供し、バックエンドサービスが実データと操作能力を提供します。最終的にユーザーが目にするのは自然言語のコマンドですが、その背後では agent が企業のセキュリティシステムを呼び出しています。

この形は今後さらに一般的になる可能性があります。AI ツールはもはや「スクリプトを書くのを手伝う」だけではなく、制御されたインターフェースを通じてクラウドプラットフォーム、セキュリティプラットフォーム、SaaS 管理、社内運用に参加できるようになります。

企業導入で注意すべきこと

セキュリティ管理系の MCP Server には明確な価値がありますが、リスクにも真剣に向き合う必要があります。

まず権限の境界です。agent が何を照会できるのか、何を変更できるのか、人による確認が必要かどうかを明確に制限しなければなりません。次に監査です。セキュリティプラットフォーム上の自動化された提案や操作は、後から追跡できるよう記録を残すべきです。最後に、プロンプトとデータ漏えいのリスクがあります。企業は、どのログ、ポリシー、ユーザー情報がモデルのコンテキストに入るのかを確認する必要があります。

より堅実な進め方は、まず健全性チェック、ログ要約、ポリシー説明、調査提案のような読み取り専用の場面で使うことです。チームが慣れてから、承認を必要とする設定変更機能を段階的に開放していくのがよいでしょう。

私の見方

Chrome Enterprise Premium MCP Server は、MCP が企業セキュリティの現場に入っていく重要なシグナルです。

これまでの MCP の例の多くは、開発者ドキュメント、コードリポジトリ、ローカルツールに集中していました。Google がそれをブラウザのセキュリティ管理に置いたことは、MCP がより本格的な企業運用とセキュリティプロセスに入りつつあることを示しています。ここで重要なのは、AI を「もっと会話上手」にすることではありません。AI agent が制御されたツールインターフェースを通じて、実際のシステム管理に参加できるようにすることです。

すでに Chrome Enterprise Premium を使っている企業なら、この MCP Server は注目に値します。短期的には、セキュリティ状態の照会、ログ調査、ポリシー理解に最も向いています。長期的には、企業セキュリティプラットフォームが AI agent と接続する標準的な方式の一つになるかもしれません。

原文リンク：Bringing AI agents to Chrome Enterprise security management

Google Pay と Wallet が Developer MCP Server を公開：決済連携を AI アシスタントにつなぐ

Fri, 29 May 2026 15:24:18 +0800

Google Developers が Google Pay と Wallet Developer MCP Server を公開した。これは Google Pay API と Google Wallet API を連携している開発者向けのもので、公式ドキュメント、アカウント状態、連携チェック、一部のビジネス指標を MCP 対応の AI 開発ツールにつなぐ。

この種の更新はモデル発表ほど派手には見えないが、開発者にとってはかなり実用的だ。決済やウォレットの連携では、「コードを書けるかどうか」よりも、ドキュメントの細かさ、設定項目の多さ、審査要件、分散したエラーフィードバックが問題になりやすい。MCP Server の価値は、AI アシスタントがより実際の文脈に近い場所から開発者の問題調査を支援できる点にある。

何を解決するのか

開発者が Google Pay や Google Wallet を導入するときは、通常、複数の場所を行き来する必要がある。

公式ドキュメントとサンプルコードを確認する
アカウントと加盟店設定を確認する
リクエストパラメータと返却エラーを確認する
連携が要件を満たしているか検証する
呼び出しの挙動と主要指標を観察する

これらを単なる Web ドキュメントとして扱うだけなら、AI アシスタントにできることは概念の説明やサンプル生成にほぼ限られる。MCP Server に接続すると、アシスタントはツールを通じてより具体的な情報にアクセスでき、現在のプロジェクト状態に近い提案を出せるようになる。

MCP がここに適している理由

MCP の役割は、AI アプリケーションに標準化されたツールインターフェイスを提供することだ。Google Pay や Wallet のような開発者向け製品では、「ドキュメント + 状態 + 検証」を組み合わせたタスクを扱うのに非常に向いている。

たとえば、開発者は MCP 対応の AI ツールに次のような質問への回答を手伝わせることができる。

現在の連携で不足している設定は何か
ある Google Pay リクエストが失敗した理由は何か
Wallet pass の定義で要件を満たしていない可能性があるフィールドはどれか
コードサンプルを現在のビジネス要件に合わせてどう変更すべきか
連携を本番公開する前に、まだ何を確認すべきか

こうした質問を大規模モデルの記憶だけに頼って答えるのはリスクが高い。公式ツールと現在のアカウント情報を組み合わせられれば、回答はより実行しやすいものになる。

AI コーディングワークフローへの意味

今回の公開は、AI コーディングアシスタントが「コードを読む」段階から「プロダクトシステムを読む」段階へ進んでいるという流れも示している。

これまで開発者が AI に決済機能の連携を手伝わせる場合、たいていはドキュメントの断片、エラーログ、コードを貼り付けるしかなかった。AI は説明できるが、現在の連携の実際の状態を必ずしも把握しているわけではない。MCP Server はこの能力を一歩進め、AI アシスタントがプロダクトの連携環境そのものを中心に作業できる可能性を広げる。

これは特に次のような場面で価値がある。

新規プロジェクトで初めて Google Pay や Wallet を導入する。
既存プロジェクトを新しい API や設定方式へ移行する。
本番公開前に連携チェックを行う。
エラーコード、審査上の問題、設定の不一致が起きたときに素早く原因を特定する。

チームにとっての利点は、数ページ分のドキュメント確認を省けることだけではない。「ドキュメントの理解は正しいが、現場の設定が一致していない」という摩擦を減らせることにある。

開発者の判断を置き換えるものではない

決済やウォレット関連の連携には、セキュリティ、コンプライアンス、ユーザー体験の要件がある。MCP Server は AI アシスタントが情報をより速く見つけ、状態を確認し、提案を生成する助けになるが、最終的には開発者がコード、セキュリティ方針、加盟店設定、本番公開フローを確認する必要がある。

特に決済フローでは、AI が一見もっともらしい提案を出したからといって、そのまま本番投入してはいけない。より堅実な使い方は、MCP ツールを検査役やナビゲーターとして扱うことだ。問題特定までの時間は短縮できるが、審査、テスト、ビジネス上の責任を置き換えることはできない。

私の見方

Google Pay と Wallet Developer MCP Server の意味は、「MCP の例がまた一つ増えた」ことではない。MCP が、現実的で複雑で、強い制約のある開発者シナリオに置かれたことにある。

MCP がドキュメントにしか接続しないなら、その価値は限定的だ。アカウント状態、連携チェック、指標、プロダクトのバックエンドにつながるなら、AI アシスタントはより多くの実務的な開発作業を担える。Google の今回の発表は、まさにその方向を示している。

今後、同様の機能はより多くのクラウドサービス、広告プラットフォーム、決済システム、企業向け SaaS に現れる可能性が高い。開発者が適応すべきなのは「AI がコードを書ける」という話だけではなく、「AI が標準ツールインターフェイスを通じて連携プロセス全体に参加できる」という変化だ。

原文リンク：Supercharge your integration workflow with the Google Pay & Wallet Developer MCP Server

Gemini 3.5 FlashとGemini Omniを無料で使う方法：一般ユーザーと開発者向け入口まとめ

Wed, 20 May 2026 23:13:35 +0800

GoogleがGemini 3.5 FlashとGemini Omniを公開したあと、実用面で重要なのはbenchmarkではなく、一般ユーザーや開発者が実際にどう使うか、どの入口が無料で、どの入口が低いハードルの試用にすぎないかです。

まず結論です。

チャット、文章作成、画像理解、日常的な質問：まずGemini app。
Gemini 3.5 Flashのパラメータ、プロンプト、マルチモーダル入力を試す：Google AI Studio。
プログラムからGemini 3.5 Flashを呼び出す：AI StudioでAPI keyを作成。
ターミナルで無料試用する：Gemini CLIを確認。
Gemini Omniの動画編集を体験する：Gemini appとGoogle Flowを優先。
本番利用する：無料枠に依存せず、有料APIまたはVertex AIへ移行。

注意点として、無料枠、地域ごとの提供状況、サブスクリプション階層、モデル選択メニューは時間とともに変わります。この記事の執筆日は2026年5月20日です。正式に使う前に、Googleの最新ページを確認してください。

Gemini 3.5 Flashを無料で使う方法1：Gemini app

最も簡単な入口はGemini appです。

https://gemini.google.com/

使い方はシンプルです。

Geminiを開く。
Googleアカウントでログインする。
モデル選択で 3.5 Flash を探す。
そのまま対話を始める。

この入口は一般ユーザーに向いています。文章作成、要約、画像理解、ファイル内容の分析、日常的な質問、簡単な計画づくりに使えます。公開情報によると、Gemini 3.5 Flashは世界中のユーザー向けに提供されており、Geminiのモデル選択メニューから選べます。

制限も明確です。無料ユーザーには通常、1日のメッセージ数、地域、機能の制限があります。上限を超えた場合は、枠が回復するのを待つか、サブスクリプションをアップグレードする必要があります。

Gemini 3.5 Flashを無料で使う方法2：Google AI Studio

単にチャットしたいのではなく、プロンプトを調整したり、パラメータを見たり、構造化出力を試したりしたい場合は、Google AI Studioのほうが適しています。

https://aistudio.google.com/

基本的な流れは次の通りです。

Google AI Studioにログインする。
新しいpromptを作成する。
モデル選択で gemini-3.5-flash を選ぶ。
プロンプトを入力して実行する。

AI Studioの利点は、制御できる範囲が広いことです。温度、システム指示、構造化出力、複数画像入力を調整でき、試したプロンプトをコードやAPI呼び出しとして書き出すこともできます。

開発者にとって、AI Studioは無料の実験台です。ここでプロンプトと入力形式を整えてからAPI連携に進むと、無駄な枠消費を減らせます。

Gemini 3.5 Flashを無料で使う方法3：無料API key

開発者が最も気にするのはAPIです。AI Studioでは、gemini-3.5-flash を呼び出すためのGemini API keyを作成できます。

基本的な流れは次の通りです。

Google AI Studioを開く。
Get API key を探す。
プロジェクトを選ぶか作成する。
API keyを作成する。
keyをローカルの環境変数に保存する。

Pythonの例：

import os
from google import genai

client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])

response = client.models.generate_content(
    model="gemini-3.5-flash",
    contents="Gemini 3.5 Flashがどのような用途に向いているか、3文で説明してください。"
)

print(response.text)

Node.jsの例：

import { GoogleGenAI } from "@google/genai";

const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY });

const response = await ai.models.generateContent({
  model: "gemini-3.5-flash",
  contents: "Gemini 3.5 Flashがどのような用途に向いているか、3文で説明してください。"
});

console.log(response.text);

curl の例：

curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.5-flash:generateContent" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"contents":[{"parts":[{"text":"Hello Gemini 3.5 Flash"}]}]}'

公開情報では、AI Studioの無料枠はGemini Flashモデルに一定の1日あたりリクエスト枠を提供することが多いとされています。時期、地域、アカウント状態によって異なり、よくある説明には1日約1,500リクエスト、分あたりリクエスト制限、token制限などがあります。これらの数字を本番計画に固定してはいけません。正式公開前にはGoogle AIの最新の料金と制限ページを確認してください。

Gemini 3.5 Flashを無料で使う方法4：Gemini CLI

コマンドラインが好きなら、Gemini CLIを見てみる価値があります。臨時スクリプト、コードベースの要約、ファイル読み取り、ターミナルでの素早い質問に向いています。

通常のインストール方法は次の通りです。

`1`	`npm install -g @google/gemini-cli`

その後、実行します。

gemini

CLIは個人開発者の日常利用に向いており、本番統合には向いていません。本番環境ではAPI key、サービスアカウント、権限制御、監査可能な呼び出し方式を使うべきです。

Gemini Omniを無料または低いハードルで使う方法：Gemini appとGoogle Flow

Gemini Omniは動画制作と編集に向けたマルチモーダルモデルです。中心的な機能は通常のテキストQ&Aではなく、自然言語で動画を複数回編集し、画像、テキスト、動画、音声などの入力を参照することです。

Google DeepMindのページでは、次の入口が示されています。

Gemini app。
Google Flow。
YouTube Shorts。

ページでは、Google AIのサブスクリプションが必要であり、機能は契約階層や地域によって変わるとも説明されています。そのため、Gemini Omniの「無料利用」は慎重に理解する必要があります。一部の入口では無料ユーザーが一部機能を見たり試したりできる可能性がありますが、完全な動画編集機能にはサブスクリプション、地域提供、段階的ロールアウトが必要な場合があります。

試してみたいだけなら、次の順番がおすすめです。

まずGemini appを開き、Gemini Omniまたは関連する動画編集入口があるか確認する。
次にGoogle Flowを開く：https://flow.google/
ショート動画を作る場合は、YouTube ShortsにOmni関連の編集機能が出ているか確認する。

入口が見えない場合、通常は操作ミスではありません。アカウント、地域、サブスクリプション階層、ロールアウト対象がまだ条件を満たしていないだけのことがあります。

Gemini Omniに向いている使い方

Gemini Omniは通常のチャットより、クリエイター向けです。

次のような使い方を試せます。

動画をアップロードまたは選択し、スタイルを変更する。
動画内の特定の動きをより誇張する。
参照画像を使って、シーン内の物体やキャラクターを置き換える。
複数回に分けてカメラ、動き、環境、スタイルを修正する。
スケッチ、参照画像、音声、動画を組み合わせて新しい出力を作る。

プロンプトは編集者への指示のように書けます。

元の動画の人物と部屋の構造はそのままにして、鏡に触れた後の効果を液体の波紋に変えてください。動きは自然にし、光が急に変わらないようにしてください。

複数回編集する場合、一度に多くの要求を詰め込まないほうが安定します。より安全な進め方は次の通りです。

まず主体の動きを変える。
次にスタイルを変える。
次にカメラ角度を変える。
最後に音、文字、リズムを調整する。

こうすると一貫性を保ちやすく、どの段階で問題が出たかも特定しやすくなります。

無料利用で踏みやすい落とし穴

第一に、無料枠は本番枠ではありません。無料API keyはテスト、個人工具、プロトタイプに向いていますが、安定したサービスを約束する用途には向きません。

第二に、機密データを無料または第三者の入口に送らないことです。未公開コード、顧客情報、契約書、キー、財務表、内部文書は特に注意が必要です。

第三に、データ利用設定を確認することです。無料枠には異なるデータ利用ポリシーがある場合があります。利用前にAI StudioやGoogleアカウントの関連設定を確認してください。

第四に、動画機能は通常、テキスト機能より制限が強くなります。Gemini Omniのような動画編集機能は、サブスクリプション、地域、待ち行列、長さ、解像度、コンテンツ安全ポリシーの影響を受ける可能性があります。

第五に、第三者の「無制限無料API」には注意が必要です。多くのゲートウェイは速度制限、リクエスト転送、ログ記録、不透明な支払い方法を伴います。機密タスクでは使わないほうが安全です。

どの入口を選ぶべきか

一般ユーザーなら：

Gemini 3.5 Flash：Gemini appを使う。
Gemini Omni：まずGemini app、次にGoogle Flowを見る。

クリエイターなら：

Google FlowでOmniの動画ワークフローを試す。
Gemini appで脚本、絵コンテ、プロンプト、素材説明を作る。

開発者なら：

AI Studioでプロンプトをデバッグする。
API keyで gemini-3.5-flash を組み込む。
Gemini CLIで個人用ターミナルワークフローを作る。
本番環境ではVertex AIまたは有料APIを検討する。

企業なら：

無料枠に依存しない。
権限、ログ、監査、データ所在地、コンプライアンス、キー管理を重視する。
動画生成と編集では、ウォーターマーク、コンテンツ審査、著作権フローも追加する。

まとめ

Gemini 3.5 Flashの無料利用経路は比較的わかりやすいです。Gemini app、Google AI Studio、AI Studio API key、Gemini CLIはいずれも低いハードルの入口になります。チャット、文章作成、プログラミング、Agentプロトタイプ、マルチモーダルテストに向いています。

Gemini Omniの重点は動画編集とマルチモーダル制作です。主な入口はGemini app、Google Flow、YouTube Shortsですが、完全な機能はサブスクリプションや地域制限の影響を受けやすいでしょう。クリエイターがまず体験や概念検証を行うには向いていますが、最初から安定した本番サービスとして計画するには向いていません。

最も堅実な戦略は、テキストとコードのタスクをまずGemini 3.5 Flashの無料枠で試し、動画制作はGemini appまたはFlowのGemini Omniで効果を確認し、本当に公開する段階で監査、課金、権限制御ができる正式な構成へ移行することです。

参考：

Gemini Omniとは？GoogleのAI動画マルチターン編集モデルを解説

Wed, 20 May 2026 23:11:58 +0800

Google DeepMindが Gemini Omni のページを公開しました。位置づけは明確です。任意の入力からコンテンツを作るモデルで、現時点では動画を中心にしています。

Nano Bananaが画像生成と編集に寄っているとすれば、Gemini Omniは動画向けのマルチモーダル編集モデルに近い存在です。ユーザーは自然言語で動画を段階的に編集でき、後続の変更は前回の変更結果を土台にしながら、シーン、人物、動き、画面の論理的一貫性を保とうとします。

プロジェクトページ：https://deepmind.google/models/gemini-omni/

解決しようとしている問題

従来の動画編集には、タイムライン、レイヤー、マスク、キーフレーム、カラーグレーディング、音声トラック、そして多くの手作業が必要です。AI動画生成ツールはプロンプトからクリップを生成できますが、よくある問題が二つあります。

一度生成した結果を細かく修正しにくい。
複数回編集すると、人物、シーン、スタイル、動きがぶれやすい。

Gemini Omniが狙っているのはこの二つ目の段階です。単に動画を生成するのではなく、編集者と会話するように、ユーザーが継続して修正を依頼できるようにします。

ページでは、自然で段階的な会話を通じて任意の動画を編集できると説明されています。各編集は前回の結果に基づき、連続性のある統一されたシーンを維持することを目指します。

主な機能

Gemini Omniの機能はいくつかに分けられます。

一つ目は自然言語による動画編集です。ユーザーは動画の美的スタイル、動き、エフェクトの変更を直接依頼できます。たとえば、鏡を液体のように波立たせたり、人物を線画、フェルト人形、透明なホログラム風ワイヤーフレームに変えたり、環境全体を 3D voxel art に変換したりできます。

二つ目は動作の再構成です。手で作った穴を拡大する、玩具に対応する動物の鳴き声を出させる、建物の照明を音楽に合わせて点灯させる、といった形で、動画内で起きること自体を変えられます。

三つ目は参照画像に基づく実写動画の編集です。ユーザーは画像を参照として与え、建物、太陽、飛行物体、その他のオブジェクトを実写の動画シーンに配置するよう依頼できます。

四つ目は複数回の編集で一貫性を保つことです。ページでは、バイオリン奏者を参照画像の環境に移動し、バイオリンを消し、さらにショットを肩越しの角度に変える連続編集の流れが紹介されています。一度きりのプロンプトよりも、実際の制作プロセスに近い使い方です。

五つ目は複数入力の参照です。Gemini Omniは画像、テキスト、動画、音声などの入力を一つの出力に統合でき、スタイル転送、動作転送、キャラクター置換、スケッチから動画への変換などに対応します。

なぜ世界知識を強調するのか

Googleはページの中で、Gemini Omniは単に「映像をリアルにする」だけではなく、Geminiの世界知識、物理的直感、歴史、科学、物語の論理を組み合わせると繰り返し強調しています。

これは重要です。動画モデルが画質だけを追求すると、動きが不自然になったり、物体の関係が混乱したり、文字と映像が同期しなかったりしがちです。Gemini Omniの目標は、見た目だけでなく、ストーリー、物理、意味の面でも一貫した動画にすることです。

ページの例には次のようなものがあります。

ビー玉が連鎖反応のコースを転がる。
claymationでタンパク質の折りたたみを説明する。
stop motion風に海馬の働きを説明する。
文字と画面内の物体を対応させて表示する。
画面上の単語をリズムに合わせて一語ずつ表示する。

これらの例から、Gemini Omniは単なるショート動画向けエフェクトツールではなく、知識表現、物語、映像と音声の生成をまとめようとしていることがわかります。

Veo、Flow、Nano Bananaとの関係

Googleの現在の製品ラインを見ると、Gemini Omniはマルチモーダルな制作と編集機能の入口に近い存在です。

Veo は動画生成モデルそのものに近く、映画的な動画と音声生成を重視します。Google Flow はクリエイター向けのAIクリエイティブスタジオで、ショット、素材、動画プロジェクトを整理する用途に向いています。Nano Banana は画像作成と細部編集に寄っています。Gemini Omniは「任意の入力から一貫した出力へ」というマルチモーダル編集を重視し、とくに動画での自然言語による複数回制御を前面に出しています。

簡単に整理すると、次のようになります。

高品質な動画を生成したいなら、Veoに注目。
制作ワークフローの中で動画プロジェクトを整理したいなら、Google Flowに注目。
画像を編集したいなら、Nano Bananaに注目。
会話形式で動画を修正し、画像、テキスト、動画、音声を参照したいなら、Gemini Omniに注目。

利用入口

ページで挙げられている入口は次の通りです。

Gemini app。
Google Flow。
YouTube Shorts。

ただしページでは、Google AIのサブスクリプションが必要であり、機能は契約プランや地域によって異なるとも説明されています。つまり、すべてのユーザーがすべての地域で完全な機能をすぐに使えるわけではありません。

クリエイターにとっては、より完整な制作ワークスペースに近い Google Flow が特に重要な入口になりそうです。一般ユーザーにとっては、Gemini app と YouTube Shorts のほうが試しやすい入口になるでしょう。

安全性とコンテンツ表示

Gemini Omniのページでは安全プロセスにも触れています。Gemini Omni Flashの開発では、社内の安全性および責任あるAIチームと協力し、自動評価、人間による評価、人間のレッドチーミング、自動レッドチーミング、リリース前の倫理・安全レビューが行われたと説明されています。

コンテンツの透明性については、Gemini app、Google Flow、YouTubeでOmniを使って作成または編集されたコンテンツには、不可視の SynthID デジタルウォーターマークと C2PA Content Credentials が含まれるとされています。ユーザーはGemini appでコンテンツを検証でき、今後はChromeや検索にも拡張される予定です。

これは動画モデルでは特に重要です。動画生成と動画編集がリアルになるほど、出所表示、悪用防止、検証ツールの重要性は高まります。

向いているユーザー

Gemini Omniは次のようなユーザーに向いています。

自然言語で素早く動画を修正したいコンテンツクリエイター。
スケッチ、参照画像、音声、動画素材を組み合わせて完成映像を作りたいデザインチーム。
ショート動画、広告コンセプト、教育向け解説動画、製品ビジュアル案を作る人。
Google FlowでAI動画ワークフローを構築したいクリエイター。
マルチモーダル動画編集の限界を観察したい開発者や研究者。

ただし、すべての場面に向いているわけではありません。本格的な商業映像、ブランドのキービジュアル、映像制作、製品発表動画では、人によるレビュー、著作権確認、事実確認、素材管理が依然として必要です。AIはコンセプト生成や初稿の反復を大きく速めますが、最終確認の代わりにはなりません。

Gemini Omniをどう見るか

Gemini Omniの意味は、AI動画を「一度きりの生成」から「会話しながら修正できる編集」へ進める点にあります。これは単に画質を上げることよりも、実際の制作フローに近い変化です。

複数回編集、一貫性、参照素材の制御、音声と映像の同期、コンテンツ表示が安定すれば、AI動画ツールの使い方は変わります。ユーザーは長いプロンプトを一度書いて結果に賭けるのではなく、監督、編集者、デザイナーのように、シーン、動き、スタイル、物語を段階的に修正していくようになります。

現時点では、実際の提供範囲、価格、地域制限、生成時間、解像度、著作権ポリシー、商用利用ルールを見ていく必要があります。一般的なクリエイターにとって最も実用的な観察点は、Google Flow と Gemini app の中で多段階の動画編集を安定して行えるかどうかです。

参考：

Google DeepMind：Gemini Omni

Gemini 3.5 発表：Flash が先行し、Google は Agent と長時間タスク実行に重点

Wed, 20 May 2026 22:51:31 +0800

Google は 2026 年 5 月 20 日、Gemini 3.5 シリーズを正式に発表した。最初に利用可能になるのは Gemini 3.5 Flash で、単なるチャットモデルではなく、Agent、コード生成、長時間にわたる複雑なタスク実行を意識したモデルとして位置付けられている。

今回の発表から見える Google のメッセージは明確だ。Gemini 3.5 は質問に答えるだけでなく、計画し、実行し、結果を確認し、複数ステップのワークフローを継続的に進めることを目指している。

Gemini 3.5 Flash が先行

Gemini 3.5 Flash は、すでに複数のユーザー層に向けて提供されている。

一般ユーザーは Gemini アプリと Google 検索の AI Mode で利用できる。
開発者は Google Antigravity、Google AI Studio、Android Studio の Gemini API から利用できる。
企業ユーザーは Gemini Enterprise Agent Platform と Gemini Enterprise から利用できる。

Google は同時に、Gemini 3.5 Pro はまだ開発中で、すでに Google 内部で使われており、来月の提供を予定しているとも説明している。

つまり 3.5 シリーズでも Flash と Pro の役割分担は続く。Flash は速度、コスト、大規模実行を重視し、Pro はより複雑で高い能力を必要とする用途を担う可能性が高い。

焦点は Agent とコードタスク

Google は Gemini 3.5 Flash を、Agent とコーディング向けの最も強力なモデルの一つとして説明している。発表では、Terminal-Bench 2.1、GDPval-AA、MCP Atlas、CharXiv Reasoning などのコード・Agent 系ベンチマークで、Gemini 3.1 Pro の一部成績を上回ったとされている。

ただし、一般ユーザーにとって重要なのは個々のスコアではない。より大事なのは、Google がモデル能力を「実行可能なワークフロー」に寄せていることだ。コードを書くことに加えて、古いプロジェクトの移行、複雑なアプリ開発、財務レポートの整理、データ分析、継続的なテストまで扱おうとしている。

Antigravity の開発フレームワークでは、Gemini 3.5 Flash が複数の協調する subagents を使い、大きなタスクを処理できる。Google は AlphaZero の論文を解析して遊べるゲームを作る例、レガシーコードを Next.js に変換する例、都市景観や UI 案を並列生成する例を示している。

方向性ははっきりしている。AI コーディングツールは「コード片を生成する」段階から、「複数の Agent を組織してプロジェクトを進める」段階へ移りつつある。

マルチモーダル UI とグラフィック能力の強化

Gemini 3.5 Flash は Gemini 3 のマルチモーダル基盤を引き継いでいる。Google は、より豊かな Web UI、インタラクティブなアニメーション、視覚コンテンツを生成できると説明している。

発表で示された用途には次のようなものがある。

研究論文向けのインタラクティブなアニメーションを作る。
テキスト説明からインタラクティブなハードウェアモデルを生成する。
学校の募金活動向けにブランドコンセプト一式を作る。
短時間でチェックアウトフローの複数の UX 案を生成する。

これは開発者やプロダクトチームにとって意味が大きい。モデルは説明文を出すだけでなく、フロントエンドのプロトタイプ、インタラクション設計、可視化にも関わるようになる。

企業用途：時間のかかるワークフローを自動化する

Google は複数のパートナー事例も挙げている。Shopify は subagents で複雑なデータを分析し、販売者の成長予測に活用している。Macquarie Bank は 100 ページを超える複雑な文書を 3.5 Flash に読ませ、口座開設フローを高速化するテストをしている。Salesforce は Agentforce に統合し、Ramp は複雑な請求書 OCR の改善に使い、Xero は行政的なワークフローを AI Agent で処理し、Databricks はデータ異常の監視と修正提案に自動化ワークフローを使っている。

これらの事例は同じ方向を示している。企業での大規模モデル利用は、単発の Q&A からワークフロー自動化へ移っている。モデルが安価で速く、長時間のタスクで安定して動くかどうかは、単発の回答が見栄えよく見えるかどうかより重要になりつつある。

Gemini Spark：個人向け AI Agent

Google は Gemini Spark も発表した。Gemini 3.5 Flash によって動く個人向け AI Agent で、ユーザーの指示のもとで長時間動作し、能動的にタスクを実行することを目指している。

Gemini Spark は信頼されたテスター向けに展開が始まっており、Google は来週、米国の Google AI Ultra 加入者向けに Beta を開放する予定だ。

ここは注目に値する。Google 検索、Gemini アプリ、Android、Workspace、ブラウザ関連のエコシステムは、すでに個人のデジタル生活の多くに接点を持っている。個人向け Agent がこれらの入口と結び付くなら、単独のチャットボットより大きな影響を持つ可能性がある。

安全対策も前段に移る

Google は Gemini 3.5 を Frontier Safety Framework に基づいて開発し、情報セキュリティや CBRN 関連リスクへの防護を強化したとしている。さらに、モデルが回答する前に推論過程の確認と理解を助ける interpretability tools にも触れている。

これは、最前線のモデル発表が能力競争だけではなくなっていることを示している。Agent、自動実行、長時間タスクを強調するほど、安全制御、誤拒否率、有害出力の抑制、解釈可能性は重要になる。

Gemini 3.5 をどう見るか

Gemini 3.5 Flash の意味は、単なる新モデル発表ではない。Google が次の AI プロダクトの形に賭けているように見える。つまり、ツールを呼び出し、タスクを分割し、協調して実行し、UI を生成し、個人と企業のワークフローに入っていくモデルだ。

開発者にとっては、Google Antigravity、AI Studio、Gemini API、Android Studio での実際の体験が重要になる。企業にとっては、benchmark だけでなく、実際の業務フローで手作業を安定して減らせるかが焦点になる。

Gemini 3.5 Pro はまだ正式公開されていない。Pro が出たあと、Flash と Pro の能力、価格、速度、コンテキスト処理の違いが、それぞれに適した本番用途を決めることになる。

参考:

Google Blog: Gemini 3.5

Google Gemini Spark リーク解説：24 時間オンラインの Gemini Agent が登場するかもしれない

Sun, 17 May 2026 11:58:08 +0800

Google はまだ Gemini Spark を正式発表していません。

現在の情報は、主に Gemini Web 内部のテスト画面、コミュニティのスクリーンショット、TestingCatalog の報道、そして 36Kr / 新智元による関連リークの整理に基づいています。比較的一致している見方は、Gemini Spark BETA が Google の準備している常時稼働 AI Agent かもしれないというものです。単なるチャットアシスタントではなく、バックグラウンドでメール、オンラインタスク、複数ステップのワークフローを処理する「日常の AI 代理人」という位置付けです。

まず境界をはっきりさせると、これはリーク解説であり、Google の公式発表ではありません。機能、名称、公開時期はいずれも Google の正式発表を待つ必要があります。

まず結論

現時点で露出している情報を見ると、Gemini Spark の要点は 3 つです。

Gemini 体系の中で 24 時間オンラインの Agent になる可能性があり、通常のチャットモデルではない。
Google アプリ、チャット履歴、タスク、ログイン済みサイト、位置情報など、より広い個人コンテキストを利用する可能性がある。
情報共有、リモートブラウザデータ、購入操作、第三者サービス呼び出しに関わるため、魅力と同じくらいリスクも大きい。

Google が本当に Spark を投入すれば、Gemini の位置付けは「質問に答える AI」から「継続的に用事を処理する AI」へ変わります。

Gemini Spark とは何か

TestingCatalog は 2026 年 5 月 14 日、Google が Gemini Web 内で Gemini Spark BETA をテストしていると報じました。露出した welcome テキストでは、inbox、online tasks、さらに多くの複数ステップ作業を 24/7 で支援する everyday AI agent と説明されています。

36Kr / 新智元の記事も、Spark が見つかった後、外部からは「常時稼働 Agent」方向に見えると述べています。終日待機し、受信箱を処理し、オンラインタスクを実行し、購入や情報共有に関わる可能性もあります。

つまり Spark は単なる新モデル名ではありません。Gemini を会話ウィンドウから出し、ユーザーのメール、Web、予定、タスク、アプリ横断ワークフローへ入れる Gemini 製品レイヤーのアップグレードに近いものです。

どのように動く可能性があるか

TestingCatalog が公開した隠し onboarding テキストによると、Gemini Spark は複数の情報源からコンテキストを取得します。

Connected Apps。
skills。
chats。
tasks。
ユーザーがログインした Web サイト。
Personal intelligence。
location。

これらの情報は、Spark がユーザーのやりたいことを理解し、タスク実行時に必要なコンテキストを呼び出す助けになります。文面ではさらに、一部のアクションを完了するために、Gemini が名前、連絡先、ファイル、好み、ユーザーが機密と考える可能性のある情報を第三者に共有する場合があるとも示されています。

これらの説明が最終的に正しければ、Spark の動作は一回限りの Q&A ではなく、「コンテキストを持つ代理システム」に近くなります。現在の 1 つの prompt だけを見るのではなく、長期的な好み、連携アプリ、ブラウザ状態、タスク履歴を組み合わせる可能性があります。

なぜ重要なのか

Gemini Spark の重要性は、チャット入口が 1 つ増えることではありません。Google が自然なエコシステム入口を持っている点にあります。

OpenAI や Anthropic も強力な Agent を作れますが、Gmail、Calendar、Drive、Chrome、Android、Workspace という完全なチェーンを自然に持っているわけではありません。Google が Spark をこれらの製品に接続すれば、ユーザーは追加のワークフローをあまり構築しなくても、Agent を日常業務に入れられます。

これにより 3 つの変化が起きます。

第一に、Gemini は受動的な Q&A から能動的な実行へ移ります。ユーザーは「このメールを要約して」と聞くだけでなく、inbox の整理、タスク追跡、後続アクションを継続的に任せるかもしれません。

第二に、Agent は個人コンテキストにより依存します。メール、予定、ファイル、ブラウザ状態、好みを理解するほど、有用な結果を返しやすくなります。

第三に、権限境界がより敏感になります。できることが増えるほど、いつ実行できるのか、どこまでできるのか、確認が必要かを明確にする必要があります。

リスクはどこにあるか

TestingCatalog が公開した文面には、注意すべき点がいくつかあります。

第一に、Spark は experimental です。仮に公開されても、完全に成熟した監督不要のシステムとして扱うべきではありません。

第二に、システム設計上は機微な操作の前に許可を求めるものの、文面では、確認なしに情報を共有したり購入を完了したりする可能性も示されています。

第三に、会話の継続性を保つため、Gemini は login details や remote code execution data などの remote browser data を保存します。ユーザーは Settings からこれらのデータを削除でき、Connected Apps や Personal intelligence 関連機能も無効化できます。

これらを合わせると、Spark の製品方向はかなり攻めています。提案を生成するだけではなく、本当にタスクを実行できる Agent を目指しています。ただし実行に近づくほど、厳格な権限、監査、確認、ロールバック機構が必要になります。

Remy、AI Ultra との関係

TestingCatalog は、Spark が以前 Remy という内部コードネームで呼ばれていた agentic Gemini upgrade のリネーム版であり、Google AI Ultra 加入者向け Gemini Agent の方向とも関係している可能性があると述べています。

この手がかりが正しければ、Spark は突然現れた新規プロジェクトではなく、Google が以前のより高階でクローズドな Agent 機能を再パッケージし、より広いユーザー層へ展開しようとしているものかもしれません。

36Kr / 新智元も、これを “Remy” から “Spark” へのアップグレードとして描写しています。Gemini Agent は単なる機能ではなく、24/7 のデジタル生活マネージャーへ向かうという見方です。

ただし、これはあくまでリーク情報に基づく判断です。Google が Spark を正式名称として使うのか、AI Ultra 限定なのか、より軽量なサブスクリプション層を出すのかは、公式確認を待つ必要があります。

MCP、skills、ツールエコシステム

同じコミュニティスクリーンショット群では、MCP Tool Testing のようなモデルセレクター項目も見つかっています。36Kr の記事は、これが新しい Gemini の MCP サードパーティツール統合ネイティブ対応や Thinking モード再構築を示唆している可能性があると見ています。

この手がかりは Spark と一緒に見ると面白くなります。

Spark が単なる「チャットできる助手」なら、skills や MCP の意味は限定的です。しかし Spark が長時間動作する Agent なら、ツール呼び出し、Web ページアクセス、タスク実行、コンテキストの読み書き、結果の納品が安定して必要になります。

つまり Spark は単独機能ではなく、Google Agent ツールエコシステムの一部かもしれません。モデルが理解と計画を担い、skills / MCP / connected apps が実行と拡張を担う構図です。

一般ユーザーにとっての意味

Gemini Spark が本当に公開されれば、一般ユーザーにとって直接的な変化は次のようなものになる可能性があります。

メールは要約されるだけでなく、分類、フォローアップ、タスク化される。
Web タスクは提案されるだけでなく、リモートブラウザ内で継続的に実行される可能性がある。
予定、位置、好み、過去の会話が Agent の長期コンテキストになる。
購入、予約、フォーム入力などの操作が AI 実行範囲に入る可能性がある。

便利に聞こえますが、ユーザーには新しい習慣が必要になります。AI が何を言ったかだけでなく、何をしようとしているのか、何をすでにしたのか、取り消せるのか、記録があるのかを見る必要があります。

将来の AI Agent 体験は、モデルの賢さだけでなく、権限プロンプトが明確か、タスクログを確認できるか、誤操作から回復できるかにも左右されます。

開発者とチームにとっての意味

開発者にとって Spark が重要なのは、Google が Agent を「デモ製品」から実際のワークフロープラットフォームへ移そうとしている可能性があるからです。

Spark が Google アプリ、サードパーティツール、ブラウザ状態に安定して接続できるなら、開発者は次の点を気にします。

API や拡張機構は公開されるのか。
MCP や skills は第三者が接続できるのか。
企業管理者は権限、データ保持、監査を制御できるのか。
Agent 実行失敗時に追跡可能なログがあるのか。
サンドボックス、承認フロー、機微な操作の確認をサポートするのか。

チームにとって、Spark はまず Gmail、Calendar、Docs、Drive、Chrome のような高頻度シーンから入る可能性があります。最初から高リスク業務を完全自動化するのには向かないかもしれませんが、inbox triage、会議フォローアップ、資料整理、市場調査、軽量な運用タスクには適しています。

今どう見るべきか

このニュースは「方向性の確度は高いが、細部の確定度は低い」と読むのがよさそうです。

方向性の確度が高いのは、Google が Gemini Agent をより能動的、より長時間稼働、より深くエコシステムへ接続する方向に進めている点です。TestingCatalog が報じた Gemini Web のテスト文面、コミュニティのスクリーンショット、36Kr が整理した複数のリークは、同じ方向を示しています。

細部の確定度が低いのは、正式名称、公開時期、権限ルール、サブスクリプション階層、利用可能地域、API 公開の有無、本当に Gemini Spark と呼ばれるかがまだ分からないためです。

現時点で最も安全な見方は次の通りです。

Spark をすでに公開済みの正式製品として扱わない。
Google の次段階の AI Agent 路線を示す強いシグナルとして見る。
権限、プライバシー、第三者へのデータ共有、リモートブラウザデータ保存について、Google がどう説明するかを待つ。

まとめ

Gemini Spark が最終的に公開されれば、Gemini がチャットアシスタントから常時稼働 Agent へ進む重要な一歩になるかもしれません。単にモデルを入れ替える話ではなく、Gemini を Google エコシステムのメール、Web、タスク、位置情報、personal intelligence、第三者サービスの中に入れる話です。

可能性は大きいです。より能動的で、実際のワークフローに近く、Google のエコシステムによって多くのユーザーへ配布しやすいからです。リスクも同じくらい大きいです。AI が情報を共有し、ブラウザ状態を保存し、購入を実行し、第三者サービスを呼び出せるなら、権限境界は非常に明確でなければなりません。

だから Gemini Spark で最も注目すべきなのは「どれだけ賢いか」ではなく、Google が 24 時間オンラインの AI Agent をどのように制御可能で、監査可能で、信頼できるものにするかです。

参考リンク：

Gemini 3.5 Pro がリーク：コードネームは Cappuccino、Google はコーディングと Agent で巻き返しを狙う

Sun, 17 May 2026 11:47:27 +0800

Google はまだ Gemini 3.5 Pro を正式発表していません。

現時点で見えている情報は、主に開発者コミュニティのスクリーンショット、匿名ベンチマーク、リーカーの投稿、メディアの報道に基づいています。36Kr / 新智元は 2026 年 5 月 15 日、次世代 Gemini のチェックポイントが社内で Cappuccino と呼ばれている可能性があり、関連モデルがコミュニティや評価プラットフォームで先に露出していると整理しました。

これらの情報は公式発表と同一視すべきではありません。ただし、方向性ははっきりしています。Google は、コーディングと推論能力、そして常時稼働する AI Agent という 2 つの弱点を同時に補おうとしています。

まず結論

今回のリークは 3 層に分けて見ると分かりやすいです。

Gemini 3.5 Pro はまだ正式発表されておらず、Cappuccino は内部チェックポイントまたは候補版のコードネームに近いものです。
露出した情報では、新しい Gemini はコード生成、SVG / インタラクティブ Web 生成、マルチモーダル出力で改善しているようです。
Google が並行してテストしている Gemini Spark は、モデルそのもの以上に重要かもしれません。24 時間稼働する個人向け AI Agent を示しているからです。

つまり、これは単なる「モデルのベンチマークニュース」ではありません。Google I/O を前にしたプロダクトロードマップのシグナルに近く、モデルは GPT-5.5 に追いつき、Agent はユーザーのワークフロー入口を押さえにいく構図です。

Cappuccino とは何か

36Kr の記事によると、Lentils の投稿では、Cappuccino というコードネームの Gemini 3.5 Pro チェックポイントが生成され始めているとされています。数時間前までコミュニティでは Gemini 3.2 が話題でしたが、最新リークでは一気に 3.5 へ飛びました。

この命名が最終的に正しければ、Google は次の Gemini を通常の小幅更新ではなく、より大きなバージョンジャンプとして見せたいのかもしれません。

ただし現時点では、Cappuccino はあくまでリーク上の内部コードネームとして扱うべきです。Google が正式モデルを公開済みという意味ではなく、最終的なリリース名が必ず Gemini 3.5 Pro になるとも限りません。

なぜコーディング能力が焦点なのか

今回のリークで最も注目されているのは、新しい Gemini のコーディング能力です。

36Kr が引用したコミュニティのスクリーンショットやベンチマーク情報によると、新モデルは次のタスクで強化されているようです。

SVG とビジュアルコンポーネントの生成。
インタラクティブ Web アプリの生成。
アニメーション、3D、調整可能なパラメータパネルなど複雑なフロントエンド出力。
論理推論とコード生成の改善。

記事ではさらに、Abacus.AI CEO の Bindu Reddy が、3.2 Flash はコーディングと推論で GPT-5.5 に近い水準に達しつつ、コストは低いと述べたことも紹介しています。一方、別のメディア筋は、新しい Gemini の総合性能はおおむね GPT-5.5 クラスだが、質的な飛躍とまでは言えないと見ているようです。

そのため、「GPT-5.5 に追いついた」という表現は慎重に読む必要があります。これは Google 公式のベンチマーク結果ではなく、複数のリークや匿名評価に基づく相対的な判断に近いものです。

Google がコーディングを急ぐ理由

AI コーディングは、開発者ツールから基盤モデル競争の中心へ移りました。

OpenAI には Codex があり、Anthropic には Claude Code があります。これらはエンジニアだけでなく、プロダクトマネージャー、デザイナー、運用担当者を「自然言語から動くプロダクトを作る」ワークフローへ連れてきています。

一方で Google には Gemini と Antigravity がありますが、開発者の意識の中で同じ強さのデフォルト入口にはなっていません。36Kr の記事でも、Antigravity は外部市場でまだ本格的に突破できておらず、価格、利用枠通知、体験の安定性についてコミュニティで議論が続いていると触れられています。

だからこそ、新しい Gemini が自分を証明するなら、コーディングが最も直接的な戦場になります。問われるのは「コードを書けるか」だけではありません。完全な UI を安定して生成できるか、複雑な要件を理解できるか、ツールを呼び出せるか、エラーを修正できるか、実際の開発フローに溶け込めるかです。

Spark は 3.5 Pro より重要かもしれない

同じリークの流れで、Gemini Spark BETA も見つかりました。

TestingCatalog などの情報によると、Spark の位置付けは「常時稼働 AI Agent」に近いものです。受信箱を処理し、オンラインタスクを実行し、複数ステップのワークフローを管理し、Google アプリ、スキルモジュール、チャット履歴、定期タスク、ログイン済みサイト、位置情報などのコンテキストに接続します。

これは Spark が通常のチャット入口ではないことを意味します。長時間オンラインで動き続け、コンテキストを読み続け、ユーザーの代わりにタスクを実行するシステムになり得ます。

魅力は明らかです。Google が Gmail、Calendar、Chrome、Android、Workspace、Gemini をつなげられれば、Spark は OpenAI や Anthropic が簡単には再現できない配布面の優位を持ちます。

同時にリスクも明らかです。36Kr の記事では、Spark 関連の説明に「確認なしに情報を共有したり購入を完了したりする可能性がある」という趣旨の表現があったと紹介されています。センシティブな操作の前に許可を求める設計だとしても、この種の Agent はプライバシー、権限境界、誤操作のリスクを生みます。

一般ユーザーにとっての意味

普通の Gemini ユーザーにとって、今回本当に注目すべきなのはモデル名ではなく、次の 3 つの変化です。

第一に、Google は「完成した結果を生成する」能力をさらに強化する可能性があります。これまで Gemini は、ビジュアル生成、SVG、フロントエンドページで手抜きに見える出力をするという不満がありました。新モデルが一度に複数の完成度の高い案を出せるなら、体験はかなり改善します。

第二に、コーディング能力はより軽量なモデルへ下りていく可能性があります。リークでは Flash 版のコーディング、推論、インタラクティブ生成の改善が繰り返し語られており、将来は複雑なタスクに必ずしも Pro モデルが必要ではなくなるかもしれません。

第三に、Agent はより能動的になります。Spark が公開されれば、Gemini は質問に答えるだけではなく、メール、Web、購入、予定、アプリ横断タスクを長期的に引き受け始める可能性があります。

効率面では良い知らせですが、権限管理には新しい課題が生まれます。

開発者にとっての意味

開発者は 2 つの点を注視すべきです。

1 つ目はツールエコシステムです。36Kr の記事では、コミュニティがモデル選択画面に MCP Tool Testing のような未公開入口を見つけたとされています。Gemini が MCP やサードパーティツールテストをネイティブにサポートするなら、開発者自身のツールチェーンに接続しやすくなります。

2 つ目はコストと安定性です。新しい Gemini が一部ベンチマークで GPT-5.5 に追いついたとしても、開発者が最終的に見るのは実際のコード品質、コンテキストの安定性、価格と利用枠が予測可能かどうかです。

過去 1 年の AI コーディングツール競争が示したのは、モデル能力は入場券にすぎないということです。開発者を残すのは、日常プロジェクトで安定してコードを修正し、テストを走らせ、コンテキストを読み、境界条件を扱えるかどうかです。

今このニュースをどう読むべきか

このニュースは「強いシグナル、弱い確認」として読むのが適切です。

強いシグナルは、複数のコミュニティ上の手がかりが、Google がより強い新 Gemini と、より能動的な Gemini Spark Agent を準備していることを示している点です。

弱い確認は、Gemini 3.5 Pro がまだ公式発表されておらず、Cappuccino もリーク上のコードネームにとどまり、「GPT-5.5 に追いついた」という主張も Google 公式ベンチマーク、第三者評価、実ユーザーの検証を待つ必要がある点です。

現時点で最も安全な見方は次の通りです。

すでに公開された製品として扱わない。
Google の次段階の Gemini 路線を示す早期予告として見る。
I/O または今後の公式イベントで、モデル名、API 提供、価格、コンテキストウィンドウ、ツール呼び出し、Agent の権限境界が確認されるかに注目する。

まとめ

Gemini 3.5 Pro / Cappuccino の露出は、Google が次世代 Gemini をより強く押し出そうとしている可能性を示しています。補おうとしているのは単一の能力ではなく、AI ワークフロー全体です。モデルはコードを書き、UI を生成し、複雑な推論を処理する必要があり、Spark は Gemini を常時稼働 Agent へ押し出します。

ただし公式発表前は、すべてのベンチマークやスクリーンショットは手がかりにすぎません。Gemini 3.5 Pro が巻き返せるかを決めるのは、コードネームの響きではなく、実際の開発、実際のオフィス業務、実際の複数ステップタスクで安定して勝てるかどうかです。

参考リンク：

Gemini Intelligence on Android 解説：Google はスマートフォンをプロアクティブな AI システムへ変えようとしている

Sun, 17 May 2026 09:13:32 +0800

Google は 2026 年 5 月 12 日に「A smarter, more proactive Android with Gemini Intelligence」を公開し、Gemini Intelligence on Android を発表しました。これは単独のチャットアプリではありません。Gemini の機能を Android、Chrome、Gboard、Autofill、widgets、マルチデバイス体験に組み込み、スマートフォンを「ユーザーのタップを待つ道具」から「ユーザーのタスクを能動的に手伝うシステム」へ変えるものです。

簡単に言えば、Google は Android を operating system から intelligence system へ進めようとしています。スマートフォンはアプリを開き、通知を表示し、設定を動かすだけではなく、画面、アプリ、音声、個人コンテキストを理解し、ユーザーの確認のもとでより複雑な操作を実行できるようになります。

まず結論

Gemini Intelligence on Android は主に 5 つの方向を持っています。

マルチステップ自動化：Gemini がアプリ間で配車、買い物、調査などの流れを完了する。
Chrome のスマートブラウジング：Android 上でページを要約し、情報を比較し、一部の反復的な Web タスクを処理する。
Autofill の強化：Gemini と個人コンテキストを使い、より複雑なフォームを入力する。
Rambler：自然な話し言葉を、より明確で整ったテキストに変える。
自然言語ウィジェット：ユーザーが欲しいものを一文で説明すると、Android がカスタム widgets を生成する。

これらの機能は 2026 年夏から段階的に展開され、まず一部の Samsung Galaxy と Google Pixel に提供され、その後、時計、自動車、メガネ、ノート PC を含むより多くの Android デバイスに広がります。

マルチステップ自動化：提案から実行へ

今回 Google が最も重視しているのは、Gemini がアプリをまたいで複数ステップのタスクを完了することです。

原文では、Gemini にスピンクラスを予約させる、Gmail から授業シラバスを見つけて必要な本を買い物カートに入れる、旅行ポスターを見て Expedia で似た旅行を探させる、といった例が挙げられています。

この能力のポイントは、単に一文を理解することではありません。同時に次のことを理解する必要があります。

ユーザーの現在の画面や画像に何があるか。
ユーザーが許可した範囲のアプリ情報。
次にどのアプリを開くべきか。
どの手順を自動実行できるか。
どの手順でユーザー確認が必要か。

Google は、Gemini がユーザーの指示に従って動き、タスク完了時に停止し、最終確認はユーザーが保持すると強調しています。これは完全自律のエージェントではなく、人間の確認を含むモバイル端末上の agent です。

画面と画像コンテキストが重要になる

今回の更新で注目すべき変化は、screen context と image context です。

従来のスマートフォンアシスタントは、音声コマンドやアプリ内の固定インターフェースに大きく依存していました。Gemini Intelligence は「今の画面を見る」ことをより重視します。たとえば、メモに買い物リストがある場合、電源ボタンを長押しして Gemini を呼び出し、そのリストから配送カートを作らせることができます。

つまり Android AI は単なるチャットボットではなく、ユーザーの目の前の操作環境を理解しようとしています。今後のモバイル AI 競争は、モデルの回答品質だけでなく、次の点にも左右される可能性があります。

現在の画面を理解できるか。
アプリをまたいで実行できるか。
バックグラウンドでタスク進行を追跡できるか。
重要な場面で確実にユーザー確認を求められるか。

これはモバイル AI と Web チャット AI の大きな違いです。

Chrome のスマートブラウジング：検索から Web タスク代理へ

Google によると、2026 年 6 月下旬から Android デバイスによりスマートな Gemini in Chrome が提供されます。

これは、Web コンテンツの調査、要約、比較を支援し、Chrome auto browse によって予約や駐車場予約など一部の反復的な Web タスクを処理できます。

つまり Gemini in Chrome は単なるページ要約機能ではなく、ブラウザエージェントへ向かっています。ブラウザはもともと多くの Web タスクの入口です。Gemini がページを理解し、情報を入力し、選択肢を比較し、一部手順を実行できれば、Chrome は閲覧ツールからタスク実行インターフェースへ変わります。

ただし、この種の機能には現実的な課題もあります。

Web サイト構造は複雑で、自動操作は失敗しやすい。
フォーム、支払い、ログイン、CAPTCHA などは慎重に扱う必要がある。
ユーザーは Gemini が何をしたのか知る必要がある。
最終送信、支払い、予約は人間の確認を残すべきです。

本当の難しさはモデル能力だけではなく、ブラウザ自動化、安全境界、ユーザー信頼にあります。

Autofill：パスワード入力から複雑なフォーム入力へ

Autofill with Google はもともと、パスワード、住所、支払い情報などの基本的な便利機能でした。Google はこれを、よりスマートなフォームアシスタントへ進化させようとしています。

原文では、Gemini の Personal Intelligence により、Android が接続アプリ内の関連情報を使い、Chrome 内のフォームを含むより複雑なフォーム項目を自動入力できると説明しています。

これは実用的です。モバイルで複雑なフォームを入力するのは面倒です。画面は小さく、項目は多く、メール、カレンダー、チャット、文書から情報をコピーする必要があります。Gemini がユーザー許可のもとで整理して入力できれば、多くの時間を節約できます。

Google は、Gemini と Autofill with Google の接続は厳密に opt-in だとも強調しています。ユーザー自身が接続するかを選び、設定からいつでもオン・オフできます。

Autofill は個人情報、住所、アカウント、支払い、仕事情報、敏感なフォームに関わるため、この点は重要です。便利になるほど、明確な許可と制御可能な退出が必要になります。

Rambler：話し言葉を送信できるテキストへ

Rambler は今回の更新で特に興味深い機能です。

Gboard はすでに音声入力に対応していますが、人が話すときには繰り返し、間、フィラー、自分での言い直しがよくあります。Rambler は自然な話し言葉を、より明確で送信しやすいテキストに整えることを目指しています。

向いている場面は次の通りです。

メッセージを素早く口述したいが、一語ずつ修正したくない。
話し言葉に間、繰り返し、フィラーが混ざる。
思いつきを、よりプロらしい SMS、メール、チャット文に整理したい。
複数言語を切り替えながら話し、文脈を理解してほしい。

Google は、Rambler が有効になっていることを明確に表示し、音声はリアルタイム文字起こしにのみ使われ保存されないと説明しています。これはプライバシーと透明性への対応です。

製品として見ると、Rambler は「音声入力」を「音声ライティング」にアップグレードするものです。言ったことを記録するだけでなく、口語を送信できる文章へ整えます。

自然言語でウィジェットを作る

Gemini Intelligence には Create My Widget も含まれます。ユーザーは「毎週 3 つの高タンパク作り置きレシピをすすめて」のように自然言語で欲しいウィジェットを説明し、Android がホーム画面用のカスタム widget を生成します。

これは Android が generative UI を試していることを意味します。ユーザーは固定テンプレートから選ぶだけでなく、見たい情報と表示方法を説明できます。

この方向が成熟すれば、スマートフォンのホーム画面はより個人化されます。天気、予定、健康、通勤、食事、学習、仕事のリマインダーが、ユーザーの需要に応じて生成される動的モジュールになります。

ただし、生成 UI には安定性が必要です。ウィジェットは一度限りのチャット回答ではなく、長くホーム画面に表示されます。信頼でき、読みやすく、設定可能で、画面を乱さない必要があります。

Material 3 Expressive とインテリジェント UI

Google は、Gemini Intelligence が Material 3 Expressive に基づくデザイン更新ももたらすと述べています。

これは単なる見た目の改善ではありません。AI が能動的にタスクを処理し始めると、UI は次を明確に示す必要があります。

AI が何をしているか。
どの手順が完了したか。
どこでユーザー確認が必要か。
ユーザーがどうキャンセルまたは変更できるか。

明確な UI のないプロアクティブ AI は、ユーザーに制御不能感を与えやすいです。そのためデザイン言語そのものが AI 製品体験の一部になります。

提供時期と展開

Google によると、Gemini Intelligence の機能は最新の Samsung Galaxy と Google Pixel から始まり、2026 年夏に段階的に展開されます。その後、時計、自動車、メガネ、ノート PC を含むより多くの Android デバイスへ広がります。

これは一度に全世界で提供されるものではありません。利用可否は、端末、地域、言語、アプリ対応、アカウント設定に依存する可能性があります。

試したい場合、現実的な期待は次の通りです。

まず Pixel と Samsung のフラッグシップ機を見る。
2026 年夏以降のシステム更新に注目する。
Gemini、Chrome、Gboard、Autofill、Android 設定内の新しいトグルを見る。
地域や言語によって、すべての機能が同時に使えるとは限らない。

Android にとっての意味

Gemini Intelligence on Android の意味は、いくつかの AI 小機能を追加したことではありません。Android の製品ポジションの変化です。

これまでのスマートフォン OS は、主にアプリ、通知、権限、ファイル、ハードウェアを管理していました。Google は今、システムにユーザー意図を理解させ、アプリ間でタスクを完了させようとしています。この方向が成功すれば、Android の競争軸は「システム機能とアプリエコシステム」から「ユーザーの作業をどれだけ能動的に助けられるか」へ広がります。

これはモバイル AI 競争を新しい段階に進めます。

Apple はオンデバイス、プライバシー、システム統合を強調する。
Google は Gemini、検索、Chrome、Android、マルチデバイスエコシステムを強調する。
サードパーティ AI アプリはシステムレベルの入口と競争しにくくなる。
アプリ開発者は、自分のアプリが AI agent からどう呼ばれるかを考える必要がある。

今後数年、スマートフォン上の AI は単なるチャット入口ではなく、システムレベルの実行層になる可能性があります。

まとめ

Google が発表した Gemini Intelligence on Android の中心は、「スマートフォンに Gemini チャット枠を追加する」ことではありません。AI を Android の操作フローに組み込むことです。マルチステップ自動化、Chrome のスマートブラウジング、Autofill、Rambler、自然言語ウィジェットはすべて、スマートフォンを受動的な道具から能動的なアシスタントへ変えるためのものです。

それが本当にユーザー習慣を変えるかは、自動化の信頼性、明確なプライバシー設定、スムーズなアプリ横断操作、そしてユーザーが最終的な制御を持ち続けられるかにかかっています。少なくとも今回の発表を見る限り、Google は Android の次の段階を、従来型のモバイル OS ではなくプロアクティブな AI システムとして定義しています。

参考リンク：

Google Blog：A smarter, more proactive Android with Gemini Intelligence

Gemini Embedding 2：テキスト、画像、動画、音声を同じベクトル空間に入れる

Mon, 04 May 2026 06:01:10 +0800

Google Developers Blog が Gemini Embedding 2 の開発方法を紹介した。このモデルは Gemini API と Gemini Enterprise Agent Platform を通じて GA になっている。重要なのは、単なる新しい embedding モデルではなく、テキスト、画像、動画、音声、ドキュメントを同じ意味空間にマッピングできる点だ。

これにより、検索システムが扱える範囲は広がる。従来の多くの RAG パイプラインでは、画像、動画、音声を先にテキストやメタデータへ変換し、それぞれ別にインデックスする必要があった。Gemini Embedding 2 はマルチモーダル入力を直接処理できるため、エージェント、検索、分類システムが実際の業務資料を扱いやすくなる。

原文リンク：Building with Gemini Embedding 2: Agentic multimodal RAG and beyond

モデルの機能

Gemini Embedding 2 は 100 以上の言語をサポートする。1 回のリクエストで処理できる内容は次の通り。

最大 8,192 text tokens
最大 6 枚の画像
最大 120 秒の動画
最大 180 秒の音声
最大 6 ページの PDF

中心にある考え方は「統一された意味空間」だ。開発者は異なるモダリティの内容を同じベクトル表現に入れ、同じ検索、クラスタリング、再ランキングのロジックで処理できる。

たとえば、テキスト説明と画像を同じ embedding リクエストに入れられる。

from google import genai
from google.genai import types

client = genai.Client()

with open('dog.png', 'rb') as f:
    image_bytes = f.read()
result = client.models.embed_content(
    model='gemini-embedding-2',
    contents=[
        "An image of a dog",
        types.Part.from_bytes(
            data=image_bytes,
            mime_type='image/png',
        ),
    ]
)

print(result.embeddings)

入力ごとに個別の embedding が必要で、集約された 1 つのベクトルでは困る場合は Batch API を使える。原文では、この種のバッチ対応について Agent Platform 側はまだ対応中だとも説明している。

RAG にとっての意味

マルチモーダル embedding はエージェント型 RAG に向いている。AI agent は、コードリポジトリ、PDF、スクリーンショット、図表、音声会議録、商品画像を同時に確認する必要があるかもしれない。すべての資料を同じ意味空間に入れられれば、形式ごとに別々の検索入口を作る必要がなくなる。

Google は、タスクの目的に応じて task prefix を使うことを勧めている。これにより、embedding が検索目的に合いやすくなる。たとえば、質問応答、ファクトチェック、コード検索、検索結果には異なる prefix を使える。

# Generate embedding for your task's query:
def prepare_query(query):
    return f"task: question answering | query: {content}"
    # return f"task: fact checking | query: {content}"
    # return f"task: code retrieval | query: {content}"
    # return f"task: search result | query: {content}"
# Generate embedding for document of an asymmetric retrieval task:
def prepare_document(content, title=None):
    if title is None:
        title = "none"
    return f"title: {title} | text: {content}"

この prefix は非対称検索に適している。ユーザーのクエリは短く、ドキュメントは長いことが多い。query と document をタスクに合わせて別々に整形すると、短い検索語と長い文書のマッチングを改善できる。

原文では 2 つの導入例が紹介されている。

Harvey は法律検索ベンチマークで、以前の embedding と比べて Recall@20 precision が 3% 向上した。
Supermemory は Recall@1 の検索精度が 40% 向上し、記憶、インデックス、検索、Q&A パイプラインに利用している。

これらの数字はすべての場面で同じ改善を保証するものではない。ただし、マルチモーダル embedding がデモだけでなく、実際の検索プロダクトで効果を出していることはわかる。

ビジュアル検索

Gemini Embedding 2 は、画像検索、画像とテキストを組み合わせた検索、商品識別にも使いやすい。原文では、URBN の衣料レンタル会社 Nuuly が、倉庫で撮影したタグ未付与の衣類写真をカタログと照合するために使っている例が紹介されている。この導入により、Match@20 は 60% から約 87% に向上し、全体の識別成功率は 74% から 90% 超に上がった。

この種の場面で重要なのは生成ではなく、「この画像はどの在庫、文書、商品レコードに最も近いか」を理解することだ。業務に大量の画像、動画クリップ、スキャン資料があるなら、マルチモーダル embedding はテキストだけのインデックスより自然に使える。

検索結果の再ランキング

Embedding は rerank にも使える。一般的には、まず基本検索で候補を取得し、その候補とユーザーのクエリとの類似度を計算して、より関連性の高い内容を上位に並べる。

# 1. Define a function to calculate the dot product (cosine similarity)
def dot_product(a: np.ndarray, b: np.ndarray):
  return (np.array(a) @ np.array(b).T)
# 2. Retrieve your embeddings
# (Assuming 'summaries' is your list of search results)
search_res = get_embeddings(summaries)
embedded_query = get_embeddings([query])

# 3. Calculate similarity scores
sim_value = dot_product(search_res, embedded_query)

# 4. Select the most relevant result
best_match_index = np.argmax(sim_value)

原文では別の考え方も紹介されている。まずモデルに内部知識から仮の基準回答を生成させ、その回答を embedding し、候補コンテンツとの類似度を比較して、意味的に最も近い結果を選ぶ方法だ。これは質問応答型 RAG で特に役立つ。

クラスタリング、分類、異常検知

検索以外にも、embedding はクラスタリング、分類、異常検知に使える。前述の質問応答検索とは異なり、これらは対称的なタスクなので、query と document に同じ task prefix を使える。

# Generate embedding for query & document of your task.
def prepare_query_and_document(content):
    # return f'task: clustering | query: {content}'
    # return f'task: sentence similarity | query: {content}'
    # return f'task: classification | query: {content}'

この種のタスクは、評判分析、コンテンツ審査、類似アセットの分類、異常サンプルの発見に使える。また、agent が大量のコンテキスト資料を先に整理してから、後続の推論に入る用途にも向いている。

保存とコスト

Gemini Embedding 2 はデフォルトで 3,072 次元のベクトルを出力する。Matryoshka Representation Learning を使っているため、output_dimensionality でより小さい次元に切り詰められる。Google は効率を優先する場合、1,536 または 768 次元を推奨している。

result = client.models.embed_content(
    model="gemini-embedding-2",
    contents="What is the meaning of life?",
    config={"output_dimensionality": 768}
)

ベクトルは Agent Platform Vector Search、Pinecone、Weaviate、Qdrant、ChromaDB などに保存できる。コスト面では、原文は Batch API がより高いスループットを提供し、デフォルト embedding 価格の 50% で利用できると説明している。

開発者はどう使うか

すでにテキスト RAG がある場合は、まず次の 2 種類の改善から始めるとよい。

PDF、スクリーンショット、画像説明、テキスト文書を同じインデックスに入れ、検索の再現率が安定するか確認する。
質問応答、ファクトチェック、コード検索、商品検索など、タスクごとに task prefix を付ける。すべての内容を同じ embedding 形式で処理しない。

新しいプロダクトを作るなら、次の方向を優先して検討できる。

企業ナレッジベース：文書、図表、プレゼン資料のスクリーンショット、会議資料をまとめて検索する。
ビジュアル検索：画像、テキスト、混合入力で商品、アセット、デザイン案、アーカイブを探す。
Agent ツールチェーン：coding agent、research agent、customer support agent が複数形式の業務資料を検索できるようにする。
コンテンツガバナンス：テキスト、画像、動画クリップを統一的に分類、クラスタリング、異常検知する。

Gemini Embedding 2 の価値は、マルチモーダル資料を同じ検索可能な資産に変えることにある。開発者にとっては、「先にテキストへ変換してから検索する」中間層を減らし、RAG システムを実世界のデータ形態に近づけられる。

Gemini が Google built-in 搭載車に登場：車載音声アシスタントが本物の AI アシスタントに近づく

Fri, 01 May 2026 06:09:57 +0800

Google は 2026 年 4 月 30 日、Gemini が Google built-in 搭載車に順次展開され、Google Assistant のアップグレード版として提供されると発表した。

重要なのは、単に「車内に AI アシスタントが増える」ことではない。車載音声インタラクションが、固定コマンドからより自然な連続会話へ移りつつある点だ。ユーザーは厳密な指示形式を覚える必要がなく、普通のアシスタントと話すように、Gemini にナビ、メッセージ処理、車両情報の確認、さらには一部の車内設定の操作を頼めるようになる。

まずは米国の英語ユーザーから

Google の説明によると、このアップデートは新車と既存車の両方に提供される。条件は、その車が Google built-in に対応しており、ユーザーが車載システムで Google アカウントにログインしていることだ。

rollout はまず米国の英語ユーザーから始まり、その後さらに多くの言語と国へ拡大される。対象ユーザーには、車内で Gemini へのアップグレード案内が表示される。アップグレード後は、以下の方法で Gemini を呼び出せる。

Hey Google と話しかける
ホーム画面のマイクをタップする
ステアリングホイールの音声ボタンを使う

これは、Google が Gemini をまったく新しい入口として作り直したわけではないことを示している。従来の車載音声入口を維持しつつ、その基盤となるアシスタントをより強力な Gemini に置き換えている。

車載音声は固定コマンドだけに頼らなくなる

従来の車載音声アシスタントでよくある問題は、できることは少なくないのに、ユーザーがかなり「正確な」言い方を求められることだ。表現が少し複雑になると、アシスタントが理解できなかったり、最も基本的な動作しか実行できなかったりする。

Gemini が車載システムに入ることで、Google は自然な会話能力を強調している。たとえばユーザーは直接こう言える。

I need to grab lunch, find some highly rated sit-down restaurants along the way. I’m not in a rush, oh, and I’d like to eat outside.

Gemini は Google Maps の情報を参照して、ルート沿いの適切なレストランを探せる。ユーザーはその後、駐車場の状況やベジタリアン対応の有無などを続けて質問でき、検索を最初からやり直す必要がない。

このようなやり取りは運転中の文脈に合っている。運転中は、スマートフォンのように何度も絞り込み、タップし、条件を修正するのが難しい。音声アシスタントがより完全な意図を理解できれば、注意散漫を明確に減らせる。

地図、メッセージ、音楽がより扱いやすくなる

Google が挙げている例は、ほとんどが運転中によくあるニーズに基づいている。

第一のカテゴリは、ルートと場所の検索だ。

Gemini は Google Maps の情報を使って、道中のレストラン、観光スポット、充電ステーションを探せる。また、現在のルートに関連する質問にも答えられる。たとえばスタジアムの近くを通るとき、近くでイベントがあるのか、それが交通に影響するのかを聞ける。

第二のカテゴリは、メッセージ処理だ。

ユーザーは Gemini に新しいテキストメッセージを要約させ、その文脈に基づいて返信できる。たとえば友人に「向かっている途中」と伝え、到着予定時刻を添えるよう頼める。内容を変えたくなった場合も、最初からやり直さずに追加で指示できる。

第三のカテゴリは、音楽と雰囲気づくりだ。

ユーザーはラジオ局名や具体的なプレイリストを知っている必要はない。聴きたい内容をそのまま説明すればよい。たとえばジャズのラジオ局を再生したり、YouTube Music で山道ドライブに合う明るい 70 年代の folk-rock を流し、スローバラードは飛ばすよう頼んだりできる。

これらの機能自体は完全に新しいものではない。Gemini の価値は、複数の条件を一つの自然言語リクエストとして処理し、ユーザーを固定コマンドに戻さない点にある。

Gemini Live によって車内でも移動しながら会話できる

Google は、Gemini Live も車載体験に入ると述べている。現在は beta だ。ユーザーは Gemini Live ボタンをタップするか、Hey Google, let's talk と言うことで、より自由な会話を始められる。

この場面は、「運転中の伴走型の学習やブレインストーミング」に近い。たとえば Lake Tahoe に向かう途中で、Gemini に地域の歴史や豆知識を話してもらえる。興味を引く内容があれば、途中で割り込んでさらに質問できる。到着後のハイキングコースや活動計画を手伝ってもらうこともできる。

従来の車載アシスタントとの差は明確だ。従来のアシスタントはツールボタンに近いが、Gemini Live は連続的に会話できる音声インターフェイスに近い。

オーナーズマニュアルとリアルタイム車両状態が重要な違い

さらに注目すべきなのは、Gemini が一般的な質問に答えるだけではないことだ。Google は、自動車メーカーと協力し、Gemini を車両システムにより深く統合していると説明している。

これにより、車そのものに近い能力がいくつか生まれる。

第一に、ユーザーは車両機能について質問できる。

たとえば「自動洗車の前に車をどう準備すればよいか？」や「ガレージの天井が低く、トランクが当たってしまう。トランクが全開にならないように設定するには？」と聞ける。Gemini はメーカー提供のオーナーズマニュアルをもとに、具体的な車種に合わせた回答を返す。利用できる情報の範囲や細かさは、ブランドや車種によって異なる。

第二に、EV ユーザーはリアルタイムのバッテリー残量や航続距離について質問できる。

たとえば現在のバッテリー残量、目的地到着時の予測残量、近くの充電ステーションの検索などだ。さらに Google Maps と組み合わせて、充電中に立ち寄れる近くのカフェなども探せる。

第三に、一部の車内設定を自然言語で調整できる。

Google の例では、ユーザーが「車内が曇っていて寒い」と言うと、Gemini がその意図を理解し、暖房を上げてデフロスターをオンにできる。

こうした能力は、単にチャットボットを車載画面に移すよりも実用的だ。車は明確な状態、ハードウェア能力、安全上の境界を持つ環境である。AI アシスタントが車両の文脈を理解できれば、通常のQ&Aよりも価値は高くなる。

車載 AI では境界線がさらに重要になる

車内での AI への要求は、スマートフォンやウェブページとは異なる。

運転中、ユーザーは頻繁に画面を見ることも、AI を修正することに多くの注意を割くこともできない。アシスタントは十分に簡潔で信頼でき、重要な場面で新しい負担を生まない必要がある。

そのため、Gemini が車に入ることは、あらゆる複雑なタスクが車内に適しているという意味ではない。より合理的な方向性は次のようなものだ。

ナビゲーションや情報検索の操作コストを下げる
多階層メニューを自然言語で置き換える
ユーザーが車両機能を素早く理解できるようにする
注意をそらさずにメッセージやメディアを扱う
EV ユーザーによりスムーズな充電とルート情報を提供する

一方で、高リスクな操作には明確な境界が必要だ。運転安全に関わる設定、確認が必要なメッセージ送信、車両制御に関わる操作には、十分に明確な確認フローがあるべきだ。

まとめ

Gemini が Google built-in 搭載車に入ることは、AI アシスタントがスマートフォンやウェブページから日常環境へさらに広がっていく一歩だ。

その意味は、車内でようやく「会話」できるようになることではない。車載音声アシスタントがより複雑な意図を理解し、地図、メッセージ、音楽、オーナーズマニュアル、一部の車両状態情報を組み合わせてタスクを完了できるようになることにある。

rollout が順調に進めば、車載音声インタラクションは「コマンドを覚える」ものから「ニーズを説明する」ものへ徐々に変わっていくかもしれない。これは運転シーンにとって重要だ。本当に優れた車載 AI は、ドライバーに多くの注意を割かせるべきではないからだ。

参考リンク：

Your car with Google built-in is about to get smarter, thanks to Gemini - Google Blog

Google Nano Bananaを呼び出して画像を切り出す方法

Thu, 09 Apr 2026 20:10:48 +0800

この記事では、実用的な Python スクリプトを使用して、Google の Nano Banana 画像編集機能を呼び出して商品画像を切り出す方法を示します。

この現在の実装の目標は明確です。

カタログから製品画像を読み取る
Google 画像モデルを呼び出して背景の削除を実行します。
返された画像に対してローカルの透明な背景のクリーニングを再度実行します
最終出力は透明な下部 PNG

白い背景の製品画像、ヘッドフォンの画像、および配線図面のバッチがすでにあり、電子商取引で使用できる透明な背景画像をすばやく生成したい場合、この方法は非常に簡単です。

このコードは何をするのか

このスクリプトは主に 4 つの部分に分かれています。

「背景を削除し、被写体を保持し、影を追加しない」ことをモデルに知らせるプロンプトワードを定義します。
google-genai の画像生成インターフェイスを呼び出します。
モデル応答から画像結果を抽出する
次に、ローカルロジックを使用してエッジの明るい背景を透明に変換し、残留エッジを減らします。

つまり、単にモデルに画像を投げただけでは終わりではなく、「モデル編集＋ローカル後処理」を繋ぎ合わせて完成するのです。

走る前の準備

最初に依存関係をインストールします。

`1`	`.\.venv\Scripts\python.exe -m pip install google-genai pillow`

GEMINI_API_KEYの取得方法

GEMINI_API_KEY は、Gemini API を呼び出すときに使用されるキーです。 Google の公式クイックスタートによると、キーをまだ持っていない場合は、Google AI Studio で直接作成できます。

入手手順は以下の通りです。

Google AIスタジオを開きます。
Google アカウントにサインインします。
Get API key または API keys ページを見つけます。
新しい API キーを作成します。
生成されたキーをコピーします。
スクリプトが読み取ることができるように、これをローカル環境変数に構成します。

ページ上に使用可能なプロジェクトがない場合は、通常、最初にプロジェクトの初期化を完了してから、[API キー] ページに戻ってキーを作成する必要があります。

キーを取得したら、環境変数を構成します。

`1`	`$env:GEMINI_API_KEY="your_api_key"`

cmd を使用している場合は、次のように記述できます。

`1`	`set GEMINI_API_KEY=your_api_key`

GEMINI_API_KEY と GOOGLE_API_KEY を同時に設定した場合、実際の動作では通常 GOOGLE_API_KEY が最初に読み込まれるため、混乱を避けるために 1 つだけを保持することをお勧めします。

ディレクトリ構造の例

スクリプトは 2 つのパラメータを受け取ります。

input_dir: 画像ディレクトリに入る
output_dir: 出力画像ディレクトリ

例えば：

images/
  product1.jpg
  product2.png

output/

走り方

スクリプトファイル名がcutout.pyで、実行方法が次のとおりであるとします。

`1`	`.\.venv\Scripts\python.exe .\cutout.py .\images .\output`

モデルを変更したい場合は、パラメーターを明示的に渡すこともできます。

`1`	`.\.venv\Scripts\python.exe .\cutout.py .\images .\output --model gemini-2.5-flash-image`

スクリプトは、入力ディレクトリ内のファイルを次の形式でループします。

.jpg
.jpeg
.png
.webp

処理が完了すると、同じ名前の透過的な PNG ファイルが出力ディレクトリに生成されます。

コア呼び出しプロセス

実際に Google Nano Banana を呼び出すキーコードは次のとおりです。

response = client.models.generate_content(
    model=model,
    contents=[PROMPT, image],
)

ここでは 2 つのコンテンツが渡されます。

テキストプロンプトの単語 PROMPT
ワンピース PIL.Image

プロンプトの内容は、製品画像全体の背景を削除し、本体のみを残し、いくつかの点を強調するようモデルに依頼することです。

完全な製品を保管する
細いワイヤーとケーブルの詳細を保持
内部の空洞と環状領域をきれいにします
新しいオブジェクトを追加しないでください
影を追加しないでください

この種のプロンプトワードは、カットアウトの品質、特にヘッドフォンケーブル、透明なエッジ、中空領域などの細部に大きな影響を与えます。

なぜローカルで後処理を行う必要があるのでしょうか?

モデルが結果を返した後、スクリプトは直接保存されませんが、make_transparent_from_borders(image) が再度実行されます。

このステップの考え方は次のとおりです。

画像の周囲のエッジから始まる明るい背景ピクセルを見つけます
幅優先検索を使用して、接続されているすべての明るい色の領域をマークします。
最後に、これらの領域を透明に変更します。

これを行う利点は、残っている白いエッジ、明るい灰色の背景、および不十分にきれいなエッジ領域をさらに除去できることです。

「背景かどうか」の判断条件は以下の通りです。

def is_light_background_pixel(r: int, g: int, b: int) -> bool:
    brightness = (r + g + b) / 3
    spread = max(r, g, b) - min(r, g, b)
    return brightness >= 170 and spread <= 35

簡単な理解は次のとおりです。

全体的に色が明るいので
3 つの RGB チャネルの差が大きすぎることはありません

商品画像の背景が白地やライトグレー地、単色に近いものを加工する場合に適しています。

完全なソースコード

現在の完全なソースコードは、直接の再利用や二次的な変更を容易にするために以下に保持されています。

from __future__ import annotations

import argparse
import os
from pathlib import Path
from collections import deque

from PIL import Image

try:
    from google import genai
except ImportError as exc:  # pragma: no cover
    raise SystemExit(
        "Missing dependency: google-genai. Install it with "
        r"'.\.venv\Scripts\python.exe -m pip install google-genai'."
    ) from exc


PROMPT = (
    "Remove the entire background from this product photo and return only the product "
    "on a fully transparent background as a PNG. Keep the full product intact, preserve "
    "thin cable details, clean the inner loops and holes, and do not add any new objects "
    "or shadows."
)


def is_light_background_pixel(r: int, g: int, b: int) -> bool:
    brightness = (r + g + b) / 3
    spread = max(r, g, b) - min(r, g, b)
    return brightness >= 170 and spread <= 35


def to_pil_image(image_obj) -> Image.Image:
    if isinstance(image_obj, Image.Image):
        return image_obj
    pil_image = getattr(image_obj, "_pil_image", None)
    if isinstance(pil_image, Image.Image):
        return pil_image
    as_pil = getattr(image_obj, "pil_image", None)
    if isinstance(as_pil, Image.Image):
        return as_pil
    raise TypeError(f"Unsupported image object type: {type(image_obj)!r}")


def make_transparent_from_borders(image: Image.Image) -> Image.Image:
    rgba = image.convert("RGBA")
    width, height = rgba.size
    pixels = rgba.load()

    visited: set[tuple[int, int]] = set()
    queue: deque[tuple[int, int]] = deque()

    def push_if_bg(x: int, y: int) -> None:
        if (x, y) in visited:
            return
        r, g, b, _ = pixels[x, y]
        if is_light_background_pixel(r, g, b):
            visited.add((x, y))
            queue.append((x, y))

    for x in range(width):
        push_if_bg(x, 0)
        push_if_bg(x, height - 1)
    for y in range(height):
        push_if_bg(0, y)
        push_if_bg(width - 1, y)

    while queue:
        x, y = queue.popleft()
        for nx, ny in ((x - 1, y), (x + 1, y), (x, y - 1), (x, y + 1)):
            if 0 <= nx < width and 0 <= ny < height:
                push_if_bg(nx, ny)

    for x, y in visited:
        pixels[x, y] = (0, 0, 0, 0)

    return rgba


def save_first_image_part(response, dst: Path) -> None:
    parts = getattr(response, "parts", None)
    if parts is None and getattr(response, "candidates", None):
        parts = response.candidates[0].content.parts

    if not parts:
        raise RuntimeError("Model returned no content parts.")

    for part in parts:
        inline_data = getattr(part, "inline_data", None)
        if inline_data is None and isinstance(part, dict):
            inline_data = part.get("inline_data")

        if inline_data is None:
            continue

        if hasattr(part, "as_image"):
            image = to_pil_image(part.as_image())
            dst.parent.mkdir(parents=True, exist_ok=True)
            make_transparent_from_borders(image).save(dst)
            return

        data = getattr(inline_data, "data", None)
        mime_type = getattr(inline_data, "mime_type", "")
        if data:
            dst.parent.mkdir(parents=True, exist_ok=True)
            with open(dst, "wb") as handle:
                handle.write(data)
            with Image.open(dst) as img:
                processed = make_transparent_from_borders(img)
                processed.save(dst.with_suffix(".png"))
            if dst.suffix.lower() != ".png":
                dst.unlink(missing_ok=True)
            return

    raise RuntimeError("Model returned text only and no edited image.")


def process_image(src: Path, dst: Path, client, model: str) -> None:
    with Image.open(src).convert("RGBA") as image:
        response = client.models.generate_content(
            model=model,
            contents=[PROMPT, image],
        )
    save_first_image_part(response, dst)


def main() -> None:
    parser = argparse.ArgumentParser(description="Use Nano Banana / Gemini image editing to cut out product images.")
    parser.add_argument("input_dir", type=Path)
    parser.add_argument("output_dir", type=Path)
    parser.add_argument("--model", default="gemini-2.5-flash-image")
    args = parser.parse_args()

    api_key = os.environ.get("GEMINI_API_KEY")
    if not api_key:
        raise SystemExit("Missing GEMINI_API_KEY environment variable.")

    client = genai.Client(api_key=api_key)
    exts = {".jpg", ".jpeg", ".png", ".webp"}

    for src in sorted(args.input_dir.iterdir()):
        if not src.is_file() or src.suffix.lower() not in exts:
            continue
        dst = args.output_dir / f"{src.stem}.png"
        process_image(src, dst, client, args.model)
        print(dst)


if __name__ == "__main__":
    main()

最適化を続けるのに適した場所

このスクリプトを大量生産に引き続き使用する予定がある場合は、後でこれらの機能を追加し続けることができます。

単一の画像エラーが報告された後にバッチ全体が中断されるのを避けるために、失敗の再試行が追加されました。
ログを記録して、処理に失敗した画像を特定しやすくします
さまざまなバックグラウンドしきい値に合わせて構成可能
サブディレクトリの再帰的スキャンをサポート
元の画像と結果画像の比較プレビューを追加しました

まとめ

「Google Nano Banana を呼び出して画像を切り出す方法」をすぐに理解したい場合は、実際には 3 つの主要な手順があります。

google-genai および Pillow をインストールする
GEMINI_API_KEY を設定します
client.models.generate_content() を使用してプロンプトの言葉と画像を渡します

このコードの価値は、モデルを呼び出すだけでなく、製品画像の切り抜きタスクで直接使用するのに適した透明な背景の後処理も追加することです。

Google Gemma 4 モデル比較: 2B/4B/26B/31B 選び方は?

Sun, 05 Apr 2026 08:30:00 +0800

Gemma 4 は、多模态 と 本地离线运行 に焦点を当てており、軽量エンドから高性能エンドまでの完全なモデルグラデーションを提供します。ほとんどのローカル展開ユーザーにとって重要なのは、「最大のものを選択する」ことではなく、「ハードウェアとタスクに最適なバージョンを選択する」ことです。

Gemma 4 モデルの比較

次の表は、選択を簡単に参照できるようにしたものです。具体的なパフォーマンスとリソースの使用状況については、実際の展開環境のテストを参照してください。

模型	参数规模	定位	主要优势	主要限制	推荐场景
Gemma 4 2B	20 亿	超轻量	延迟低、资源占用小、部署门槛最低	复杂推理与长链路任务能力有限	移动端、IoT、轻量问答、简单自动化
Gemma 4 4B	40 亿	轻量增强	比 2B 更稳的理解与生成能力，仍易本地部署	高强度编码/复杂 Agent 任务上限有限	本地助手、基础文档处理、多语言日常任务
Gemma 4 26B	260 亿	高性能（专家混合）	推理和工具调用能力明显提升，适合生产工作流	显存需求显著上升，硬件门槛更高	编程助手、复杂工作流、企业内部 Agent
Gemma 4 31B	310 亿	高性能（稠密）	综合能力最强，复杂任务稳定性更好	资源消耗最高，部署与调优成本最大	高要求推理、复杂代码任务、重度自动化

選択方法: ハードウェアとタスクから逆算して考える

「走れるかどうか、スムーズに走れるかどうか」を主に見る場合は以下から選べます。

8GB ビデオメモリ: 優先順位 2B/4B。
12GB ビデオメモリ: 4B 以降のモデルの量子化バージョンを優先します。
24GB ビデオメモリ: 26B に焦点を当て、タスクに従って 31B の量子化バージョンを評価できます。
より高いグラフィックスメモリまたは複数のカード: 31B の高精度構成を試すことができます。

安定性と推論速度の確保を優先し、徐々にモデル規模を大きくしていくことをお勧めします。

4 つの典型的な使用シナリオ

1) 現地の一般アシスタント

優先モデル: 4B
理由：コストと効果のバランスが良く、長期の永続運用に適しています。

2) コードと自動化

優先モデル: 26B
理由: 複数ステップのタスク、ツール呼び出し、およびスクリプト生成においてより安定しています。

3) 難易度の高い推理と複雑なエージェント

優先モデル: 31B
理由: 複雑なコンテキスト下での安定性が向上し、フォールトトレランスが向上します。

4) エッジデバイスと軽量オフライン

優先モデル: 2B
理由: リソースに制約のあるデバイスに実装するのが最も簡単です。

導入に関する推奨事項 (Ollama オリエンテーション)

最も現実的な方法は、「小さなステップで素早く実行する」ことです。

まず、4B を使用して、実行可能なベースライン (速度、メモリ、エフェクト) を確立します。
実際のタスクの固定テストセットを作成します (例: 20 の FAQ + 10 の自動タスク)。
次に、26B/31B にアップグレードして、精度、遅延、メモリコストを比較します。
「メリットが明らかな」場合にのみ、大型モデルをアップグレードしてください。

これにより、最初から大きなパラメータを追求し、遅延、低スループット、複雑なメンテナンスなどの問題が発生することを回避できます。

結論は

Gemma 4 の真の価値は、単に「より大きなパラメーター」ではなく、軽量から高性能までの実装可能なグラデーションの完全なセットです。

低コストで迅速にオンラインに接続したい場合は、2B/4B から始めてください。
ローカル AI を本番プロセスに真に統合したい場合は、26B を優先してください。
複雑な推論と高度な自動化に取り組みたい場合は、31B をもう一度試してください。

Gemma 4 に最適な選択は、通常、パラメータが最大のバージョンではなく、ハードウェアの条件とミッションの目標に最もよく一致するバージョンです。