Gemini on KnightLiブログ

Google I/O後、GPTとGeminiのサブスクリプションはどちらを選ぶべきか？一般ユーザーと開発者向け比較

Thu, 21 May 2026 08:33:14 +0800

Google I/O 2026の後、AIサブスクリプションの選び方はかなり複雑になりました。

以前は比較的単純でした。文章作成、質問応答、プログラミング、ファイル分析なら、多くの人はまずChatGPTを検討し、Google Search、Android、Gmail、Docs、YouTubeを深く使う人だけがGeminiを考える、という流れでした。しかし今は違います。GoogleはI/OでGemini 3.5 Flash、Gemini Omni、Antigravity 2.0、Gemini API Managed Agents、Google AI Studio、AI Ultraをまとめて打ち出し、Geminiエコシステムは「選択肢の一つ」から「強い競争軸」へ変わり始めています。

この記事では抽象的なモデルベンチマークではなく、実際の問いに答えます。一般ユーザー、開発者、コンテンツクリエイター、企業ユーザーは、GPT / ChatGPTとGemini / Google AIのどちらを契約すべきなのでしょうか。

注意：AIサブスクリプションの価格、利用枠、地域、モデル提供状況はすぐ変わります。この記事の執筆日は2026年5月21日です。契約前にはOpenAIとGoogleの最新ページを確認してください。

まず結論

主力サブスクリプションを一つだけ選ぶなら、次の考え方で十分です。

日常的な文章作成、質問応答、ファイル分析、一般的なオフィス作業、中国語と英語の混在利用：ChatGPT Plusを優先。
高頻度のコーディング、Codex、複雑な推論、プロジェクト単位のコード作業：ChatGPT Plus / Proを優先し、利用枠に応じてアップグレードを判断。
Gmail、Docs、Drive、Android、SearchなどGoogleエコシステムを深く使う：Gemini / Google AI Proを優先。
動画、AI映像、Google Flow、YouTube Shorts、Gemini Omniが中心：Google AI Pro / Ultraを優先。
Antigravity、Gemini API Managed Agents、AI StudioからAndroidへのワークフローが必要：Google AI Pro / Ultraを重点的に見る。
企業チーム：個人向けプランだけで判断せず、Business / Enterprise、Workspace、権限、監査、データ境界を見る。
予算が限られる場合：主力の有料プランを一つ契約し、もう一方は無料枠または従量課金APIで使う方が、二つの上位プランを同時契約するより現実的。

一言でいえば、GPTは汎用生産性とコード支援の主力であり、Google I/O後のGeminiはGoogleエコシステム内のシステム級AIスイートに近づいています。

Google I/O後、Geminiは何が変わったか

Google I/O 2026によって、Geminiの価値はGemini App単体だけでは決まらなくなりました。

重要な変化は次の通りです。

Gemini 3.5 Flash：promptからactionまでの高速モデルとして位置づけられ、実際のAgentワークフローを意識している。
Gemini Omni：任意の入力からコンテンツを作成し、現時点では動画を起点に、多モーダル作成と自然言語による反復編集を支える。
Google Antigravity 2.0：開発者向けのagent-first development platformで、複数Agentの編成とコーディングを扱う。
Gemini API Managed Agents：API経由で、推論、ツール利用、コード実行ができるホスト型Agentを作成できる。
Google AI Studio：prompt playgroundから、モバイル、Androidネイティブアプリ生成、Antigravityプロジェクト出力へ広がっている。
Google AI Ultra：I/O後に追加された月額$100のプランで、開発者、技術責任者、知識労働者、高度なクリエイターを対象にしている。

さらに重要なのは、GoogleがGemini Appの利用枠を従来の日次prompt制限からcompute-usedモデルへ移行したことです。複雑な動画、コード、長文コンテキストのタスクは多くの枠を消費し、単純なテキストタスクは少なく済みます。枠は5時間ごとに更新され、週次制限に達するまで使えます。

これは、GoogleがGeminiのサブスクリプションを「モデル + アプリ + クリエイティブ + 開発ツール + Googleエコシステム」の入口として作ろうとしていることを示しています。

ChatGPT / GPTは誰に向いているか

ChatGPTの強みは今も大きく、AIを日常業務の主力として使う人に特に向いています。

OpenAIの現在の価格ページとヘルプ文書によれば、ChatGPT FreeではGPT-5.5 Instantなどの基本機能を利用できます。PlusではGPT-5.5 Thinking、より多いメッセージとアップロード枠、強化された画像生成、deep research、agent mode、Projects、Tasks、カスタムGPT、拡張されたCodex利用が提供されます。Proではさらに高い利用枠、GPT-5.5 Pro、より大きいCodex利用枠、最大級のdeep researchとagent modeが提供されます。

ChatGPTに向く場面は次の通りです。

文章作成、要約、翻訳、リライト。
複雑な質問応答と構造化分析。
ファイルアップロード、表計算分析、調査レポート。
プログラミングQ&A、コードレビュー、リファクタリング提案。
Codexによるリポジトリ作業。
多言語コンテンツ制作。
モデル品質と回答の安定性を重視しつつ、Google製品への依存が強くない場合。

一般ユーザーにとって、ChatGPT Plusは今も最も安定した主力サブスクリプションです。カバー範囲が広く、学習コストが低く、中国語と英語のタスクもバランスよく扱えます。

開発者にとって、ChatGPTの重要点はチャットだけではなくCodexです。OpenAIのヘルプ文書では、条件を満たすChatGPTプランでCodexを利用でき、利用枠はプランによって変わると説明されています。コード修正、PR、リファクタリング、テスト修正にCodexを多用するなら、サブスクリプション選びではCodex枠も一緒に考える必要があります。

Gemini / Google AIは誰に向いているか

Google I/O後、Geminiの強みはよりはっきりしました。Googleエコシステムとの結びつきが深いことです。

Google AIサブスクリプションは、Gemini App内のモデル枠だけではありません。Gemini Omni、Google Flow、Antigravity、AI Studio、一部のYouTube Premium / Lite特典、Workspace / Android / Searchエコシステムの機能も含みます。GoogleはAI Ultraを$100およびそれ以上の上位プランに広げ、開発者、技術責任者、知識労働者、高度なクリエイターを強調しています。

Geminiに向く場面は次の通りです。

Gmail、Docs、Drive、Sheets、Slides、Androidを深く使っている。
AIをGoogle Search、YouTube、Workspaceの中に入れたい。
Gemini Omni、Google Flow、動画生成、動画編集に関心がある。
Antigravity、Gemini API Managed Agents、AI Studio mobileを試したい。
超長文コンテキストで文書を理解したい。
Googleエコシステムアプリ、Androidネイティブアプリ、Workspace自動化を作る。

Googleのヘルプページによると、Gemini Appsのコンテキストウィンドウはサブスクリプションに応じて大きくなります。AI planなしでは32K、AI Plusでは128K、AI ProとAI Ultraでは1 millionです。AI Pro / Ultraでは、より高い利用制限、追加機能、一部の早期機能も提供されます。

仕事環境がすでにGoogleエコシステム内にあるなら、Geminiの価値は大きくなります。そうでなければ、Geminiを単に「もう一つのチャットボット」として契約する価値は、ChatGPTより安定して高いとは限りません。

一般ユーザーの選び方

一般ユーザーが陥りやすい失敗は、新モデル発表のたびに複数プラットフォームを同時契約することです。

より合理的な選び方は、主な利用場面から考えることです。

主に次のことをするなら：

記事を書く。
資料を調べる。
要約する。
PDFを読む。
メールを書く。
履歴書を直す。
言語を学ぶ。
日常的に質問する。

ChatGPT Plusを優先してください。汎用性が高く、タスクの境界が明確で、特定のエコシステムに深く縛られる必要がありません。

主に次のことをするなら：

Gmail / Docs / Drive / YouTube / Androidを高頻度で使う。
AIをGoogleエコシステムに直接入れたい。
Gemini App、Daily Brief、Google Search AI、YouTubeコンテンツQ&Aを試したい。
Googleドキュメントを長文コンテキストで読みたい。

Google AI Proを優先してください。

軽い利用だけなら、まず両方の無料枠を使い、明確な制限に当たってから有料化すれば十分です。「使うかもしれない」だけで上位プランを契約する必要はありません。

開発者の選び方

開発者は大きく二種類に分けられます。

第一のタイプは、コード質問、bug修正、スクリプト作成、リポジトリ読解が中心の人です。ChatGPT Plus / Pro + Codexを優先してください。

理由は次の通りです。

CodexとChatGPTアカウントがつながっている。
ChatGPTはコード説明、リファクタリング、テスト、エラー分析が安定している。
Plusで多くの日常開発タスクをカバーできる。
Proは高頻度、長時間、複雑なリポジトリ作業に向いている。

第二のタイプは、Googleエコシステム、Agentプラットフォーム、Android、Workspace、Gemini APIを中心に開発する人です。Google AI Pro / Ultraを優先してください。

理由は次の通りです。

Gemini 3.5 FlashはGoogle I/O後のAgentワークフローの重点モデル。
Antigravity 2.0はGoogleのAgent-first開発プラットフォーム。
Managed AgentsはAPI経由で、ツール付きかつ隔離Linux環境を持つAgentを作れる。
AI StudioはAndroid、Workspace、Antigravityと自然につながる。

フルスタック開発者にとって現実的な組み合わせは、多くの場合次の通りです。

ChatGPT Plusを日常のコードとドキュメントの主力にする。
Gemini無料枠またはAI ProをGoogleエコシステム、長文コンテキスト、動画/Agent新機能に使う。
APIは従量課金で使い、個人サブスクリプションを本番API予算と誤解しない。

コンテンツクリエイターの選び方

コンテンツクリエイターの選択は、何を作るかで決まります。

主に次のことをするなら：

コピー。
見出し。
台本。
記事。
画像付きコンテンツ。
資料整理。
多言語リライト。

ChatGPT Plusは今も安定しています。

主に次のことをするなら：

動画生成。
ショート動画のアイデア。
AI映像。
YouTube Shorts。
Google Flowワークフロー。
多モーダル素材の統合。

Gemini / Google AI ProまたはUltraに注目する価値があります。I/O後、Gemini OmniとGoogle FlowはGoogleのクリエイティブ領域での中心的なカードです。

予算が限られるなら、まずテキスト主力を一つ契約し、もう一方の無料枠や短期契約で動画機能を試すのがよいでしょう。動画モデルの利用枠、待ち時間、長さ、解像度、地域制限は変化が速いため、最初から長期の制作基盤として計画しない方が無難です。

企業とチームの選び方

企業は個人ユーザーの発想で選ぶべきではありません。

本当に見るべきなのは「今週どのモデルが強いか」ではなく、次の点です。

データが学習に使われるか。
SSO、MFA、RBACがあるか。
監査ログがあるか。
社内ナレッジ接続に対応するか。
プラグイン、コネクタ、Agent権限を制御できるか。
組織のコンプライアンス要件を満たすか。
既存のオフィススイートと連携できるか。

企業がすでにGoogle Workspaceを深く使っているなら、Geminiの企業向けプランは自然に評価対象になります。チームがすでにChatGPT、Codex、OpenAI API、社内ツールチェーンを中心にプロセスを作っているなら、OpenAI Business / Enterpriseの方が自然です。

エンジニアリングチームは、Codex、Antigravity、Gemini API Managed Agents、MCP、CI/CD、コード権限、リポジトリアクセス、監査も別途評価する必要があります。

Pro / Ultraが必要になるタイミング

多くの人は実際には上位プランを必要としていません。

ChatGPT Proが必要な典型的なサイン：

毎日長時間ChatGPTを使う。
Plusの利用枠がよく足りなくなる。
Codexを高頻度で使う。
deep research、agent mode、複雑な推論をよく使う。
GPT-5.5 Proのような上位モデルが必要。

Google AI Ultraが必要な典型的なサイン：

Gemini、Flow、Antigravityを高頻度で使う。
Gemini / Antigravityのより高い利用枠が必要。
動画制作、AI映像、長文コンテキスト研究を行う。
Googleエコシステムと新機能の早期利用に深く依存している。
Gemini Spark、Project Genie、または上位サブスクリプション特典が必要。

毎日数回質問する、たまに記事を書く、少しコードを直す程度なら、Plus / ProやAI Pro / Ultraは必須ではありません。

最も安く使う戦略

おすすめは次の組み合わせです。

まず主力の有料サブスクリプションを一つ選ぶ。
もう一方のプラットフォームは無料枠で使う。
APIが本当に必要になったら従量課金で使う。
動画、Agent、deep researchのような高消費機能は月単位でオン/オフし、年間で盲目的に契約しない。
毎月振り返る：本当に利用枠を使い切ったか。

よくある組み合わせ：

一般的なオフィス作業：ChatGPT Plus + Gemini無料枠。
Googleエコシステムユーザー：Google AI Pro + ChatGPT無料枠。
開発者：ChatGPT Plus/Pro + Gemini API/AI Studioを必要に応じて利用。
動画クリエイター：Google AI Pro/Ultra + ChatGPT無料枠またはPlus。
企業チーム：個人プランを寄せ集めず、Business / Enterprise / Workspaceプランを直接評価。

契約前チェックリスト

支払う前に、次の点を確認してください。

自分の地域で対象プランが使えるか。
必要なモデルがそのプランに含まれているか。
Codex、Antigravity、Flow、Omniが本当に使えるか。
動画機能に地域、年齢、待ち行列、解像度の制限があるか。
API呼び出しはサブスクリプションに含まれるのか、別課金なのか。
ファイルアップロード、コンテキストウィンドウ、agent mode、deep researchに制限があるか。
データプライバシー設定がプロジェクト要件に合うか。
Google One、Workspace、ChatGPT Business、学校/会社アカウントの特典をすでに持っていないか。

特に注意すべき点は、個人サブスクリプションはAPI無料、商用無制限、企業コンプライアンスを意味しないということです。

まとめ

Google I/O後、Geminiの競争力は明らかに強まりました。特に動画、多モーダル、Googleエコシステム、Android、AI Studio、Antigravityの領域です。一方で、ChatGPTは日常の文章作成、複雑な質問応答、ファイル分析、コード支援、Codexワークフローにおいて、今もより安定した汎用主力です。

最も簡単な判断は次の通りです。

迷うなら：まずChatGPT Plus。
Googleを深く使うなら：Google AI Pro。
高頻度の開発者なら：CodexとAntigravityのどちらが自分のワークフローに合うかを見る。
動画クリエイターなら：Gemini Omni、Flow、Google AI Pro / Ultraを優先して確認。
企業ユーザーなら：モデルの話題性ではなく、コンプライアンス、権限、監査、既存オフィスエコシステムで選ぶ。

AIサブスクリプションは多ければよいわけではありません。本当にコスト効率がよいのは、主力ワークフローを一つ決め、他のプラットフォームを補助として使うことです。発表会のたびに長期サブスクリプションを増やす必要はありません。

参考情報：

Google I/O 2026まとめ：Gemini 3.5、Omni、Antigravity、システムレベルAgent

Thu, 21 May 2026 00:07:06 +0800

Google I/O 2026の主線は明確です。GoogleはGeminiを「モデル」や「チャットアシスタント」から、より大きなAgentエコシステムへ進めようとしています。質問に答えるだけではなく、Search、Android、開発者ツール、動画制作、ショッピング、Workspace、ハードウェア、エンタープライズ基盤に入り込み、より長いタスクの流れを支援する方向です。

この記事では、公式発表と開発者視点に基づき、Google I/O 2026の主要内容を整理します。実際の開発では、Google、Android Developers、Gemini APIの公式ドキュメントを基準にしてください。

一言でまとめると

Google I/O 2026のキーワードは agentic Gemini era です。

Googleは次のようなラインを発表、または強化しました。

Gemini 3.5 Flash：速度、実行能力、Agentワークフローを重視。
Gemini Omni：任意の入力からコンテンツを生成し、まず動画制作と編集に注力。
Gemini app：チャットアシスタントから、能動的で常時支援し、タスクを実行できる個人Agentへ。
Google Antigravity 2.0：AIコーディングツールからAgent優先の開発プラットフォームへ。
Gemini API Managed Agents：推論、ツール利用、コード実行が可能なホスト型AgentをAPIで作成。
Google AI Studio：モバイル、Androidネイティブ対応、Antigravityへのプロジェクト書き出しへ拡張。
Search、Shopping、YouTube、Workspace、Android：より強いGeminiとAgent機能を導入。

つまりGoogleは、単に「モデルがどれだけ賢いか」を見せる段階から、「モデルが製品、ツール、システムに入り、ユーザーのために実際にタスクを実行する方法」を示す段階へ進んでいます。

Gemini 3.5 Flash：プロンプトからアクションへ

Gemini 3.5は、GoogleがI/O 2026で発表した新世代モデルシリーズです。最初の公開上の焦点は Gemini 3.5 Flash です。

Googleはこれを単なる「より速いチャットモデル」としてではなく、実際のAgentワークフローのための高速エンジンとして位置づけています。公式の開発者向け記事では、3.5 Flashがフロンティア級の知能と高速性を組み合わせ、promptからactionへの移行を支えると説明されています。

主な意味は次の通りです。

Agentとcodingシーン向けに最適化。
より長いタスクチェーンとツール呼び出しを支援。
Antigravity、Gemini API、Google AI Studio、Android Studio、Gemini Enterpriseなどで提供。
高速応答、多段階実行、頻繁なツール呼び出しが必要なアプリに向く。

開発者にとって、Gemini 3.5 Flashは単なるモデル選択肢ではなく、Googleの新しいAgentツールチェーンの標準的な動力源の一つです。

Gemini Omni：動画と世界モデル能力が重点に

Gemini Omni はI/O 2026のもう一つの中核発表です。Googleは、任意の入力からコンテンツを作成し、現在は動画から重点的に始めると説明しています。

見どころは主に三つあります。

マルチモーダル入力：テキスト、画像、動画、音声などを参照として使える。
動画編集：一度生成して終わりではなく、自然言語で複数回動画を修正できる。
世界理解：物理、シーン、動き、物語、音声と映像の一貫性を重視。

これは、AI動画ツールが「一つのプロンプトで短編を生成する」段階から、「編集者と話すように段階的に修正する」段階へ進んでいることを示します。クリエイターにとって本当に価値があるのは一度きりの生成ではなく、制御可能で追跡でき、反復できる編集フローです。

Gemini App：チャットアシスタントから常時稼働の個人Agentへ

GoogleはGemini appもよりAgent的な方向へ明確に進めています。公式記事では、Gemini appがより能動的になり、日次ブリーフや常時支援を提供すると説明されています。

主なポイントは次の通りです。

Gemini 3.5 Flash がGemini appに入る。
新しいUIとより動的なインタラクション。
Gemini Spark のような個人AI Agentの概念。
Proactive daily briefsで、ユーザーが毎日知るべき情報を能動的に整理。
ユーザーが毎回チャットを始めるのではなく、7×24時間のバックグラウンド支援を重視。

この部分は一般ユーザーへの影響が最も大きいところです。以前のGeminiは「聞かれたら答える」助手に近いものでした。I/O 2026以降、Googleはそれを、タスクを継続的に追跡し、能動的にリマインドし、複数製品をまたいで協調する個人Agentに近づけようとしています。

Antigravity 2.0：開発者ツールはAgent優先へ

開発者向けで最も重要な発表の一つが Google Antigravity 2.0 です。

GoogleはAntigravityを agent-first development platform と位置づけています。I/O 2026以降、それはコードを書く支援だけでなく、アイデア、プロトタイプ、Agent編成、本番アプリの提供までを支援するものになります。

公式が挙げる主な変化は次の通りです。

Antigravity 2.0の独立デスクトップアプリ。
複数Agentの並列オーケストレーション。
動的subagents。
バックグラウンドのスケジュールタスク。
Google AI Studio、Android、Firebaseなどとの統合。
ターミナルユーザー向けのAntigravity CLI。
Agentの振る舞いとデプロイをカスタマイズするAntigravity SDK。

これは、AIコーディングツールが「コード補完 / 対話生成」の次の段階へ進んでいることを示しています。開発者が管理するのは、一つのチャットウィンドウではなく、複数の実行可能なAgentになります。

Gemini API Managed Agents：AgentをAPI能力としてホストする

Googleは Managed Agents in the Gemini API も発表しました。

公式説明によると、この種のAgentは一回のAPI呼び出しで作成でき、推論、ツール利用、隔離されたLinux環境でのコード実行が可能で、Antigravity agent harnessによって支えられます。

開発者にとって重要な点は次の通りです。

完全なAgent実行環境を自分で構築しなくてよい。
永続的で隔離された実行環境を得られる。
複数回のやり取りでファイルと状態を保持できる。
markdown skills、カスタム指示、テンプレートでAgentを拡張できる。
Interactions APIとGoogle AI Studioから利用できる。

この流れが成熟すれば、Agentプラットフォームはますますクラウドサービスに近づきます。開発者はモデルだけでなく、状態、ツール、実行環境、安全境界を持つAgentを呼び出すようになります。

Google AI Studio：prompt playgroundからアプリ生成入口へ

I/O 2026では、Google AI Studioの位置づけもさらに進みました。

主な変化は次の通りです。

Google AI Studio mobile appで、モバイルからアイデアを記録しプロトタイプを生成。
Workspace API統合により、AgentがGoogle Workspaceへ自然に接続。
プロジェクトをAntigravityへ書き出し、文脈を保ったままローカル開発と本番化へ進める。
Androidネイティブ対応により、promptからAndroidアプリを構築。
Google Play Consoleと連携し、アプリをテストトラックへ公開。

これにより、AI Studioは「プロンプトを調整してモデルを試す場所」から「アイデアからアプリへ進む入口」になります。Antigravityとの役割分担も明確です。AI Studioは素早い構想と生成に向き、Antigravityは継続開発、編成、デバッグ、提供に向きます。

AndroidとAppFunctions：モバイルAgentの重要インターフェース

AndroidのシステムレベルAgentは単独で見る価値のある方向ですが、正確なインターフェースと製品境界で理解する必要があります。

現時点で最も注目すべきなのは、Android公式の AppFunctions です。公式ドキュメントでは、AppFunctionsはAndroidプラットフォームAPIであり、Jetpackライブラリを伴い、アプリが自分の機能をエージェント、アシスタント、その他の権限を持つ呼び出し元へ公開できるものだと説明されています。Android MCP統合も簡素化します。

その意味は、モバイル自動化がスクリーンショット、OCR、タップのシミュレーション、UI要素の特定だけに頼らなくなることです。

従来のモバイル自動化は次のような流れでした。

画面を認識する。
ボタンを探す。
タップをシミュレートする。
ページ変化を待つ。
エラー時に再試行する。

AppFunctionsの方向は次の通りです。

アプリが自分に何ができるかを宣言する。
Agentが許可のもとでその能力を呼び出す。
システムが権限、呼び出し境界、安全制約を管理する。

これはAndroidアプリ設計に影響します。将来のアプリは、人間が見るUIだけでなく、Agentから呼び出せる能力インターフェースとして中核機能を設計する必要があります。

Search、ショッピング、コンテンツ製品もAgent化へ

Google I/O 2026の変化はモデルや開発者ツールだけではありません。検索とコンシューマー製品も同時に変わっています。

公式I/Oまとめでは、次のような点が挙げられています。

Searchが新しいAI Search段階へ入る。
Searchの中にInformation agentsが登場する。
Gemini SparkとDaily BriefがGemini appへ入る。
Universal Cartがショッピングカートをより賢くする。
Ask YouTubeにより、動画内容を会話形式で検索し移動できる。
Geminiの能力がさらに多くの製品と形態へ広がる。

これらの発表は、GoogleのAgent戦略が単一製品ではなく、検索、動画、ショッピング、オフィス、モバイル、ハードウェアへ横に広がっていることを示しています。

開発者への実際の影響

Google I/O 2026が開発者に与える最大の影響は、「また一つモデルが増えた」ことではなく、開発対象が変わることです。

これまで開発者が主に作っていたものは次のようなものでした。

App。
Webサイト。
API。
プラグイン。
自動化スクリプト。

これからは次のものも作る必要があります。

Agentから呼び出せるアプリ能力。
複数Agentのワークフロー。
状態を持つツール実行環境。
監査可能な自動化フロー。
human-in-the-loopの確認機構。
MCP、AppFunctions、Workspace API、Playwright、Firebaseなどとの統合。

ソフトウェアはますます「画面の集合」ではなく「能力の集合」になります。自分たちの能力を明確、信頼可能、安全にAgentへ公開できる製品ほど、ユーザーの自動化タスクチェーンに入りやすくなります。

モバイル自動化への影響

モバイル自動化は「GUI優先」から徐々に「インターフェース優先、GUIはフォールバック」へ移ります。

短期的には、スクリーンショット認識、OCR、タップのシミュレーション、ブラウザー自動化はまだ価値があります。多くの古いアプリには標準インターフェースがないからです。

長期的には、Android AppFunctions、MCP、システムレベルの権限モデルが成熟すれば、安定したタスク実行は次の方向に寄っていきます。

まずアプリが宣言した能力を呼び出す。
必要ならシステムインターフェースを呼び出す。
さらに必要な場合だけGUI自動化をフォールバックとして使う。

これはRPA、モバイルAgent、テストツール、アプリエコシステムを変えます。能力を公開するアプリほど、システムレベルAgentから呼ばれやすくなります。公開しないアプリは、従来の「画面を見て、画面を押す」方法でしか操作できないかもしれません。

セキュリティ、権限、監査は必須条件になる

Agentの能力が強くなるほど、リスクも大きくなります。

Agentがアプリをまたいでタスクを実行し、支払いを呼び出し、設定を変更し、ファイルにアクセスし、文脈を読むことができるなら、明確な安全境界が必要です。

権限レベル。
ユーザーの明示的な許可。
機密操作の二重確認。
サンドボックス隔離。
操作ログ。
取り消しとロールバック。
企業監査とコンプライアンス。

Googleがホスト型Agentの隔離環境、AppFunctionsの権限要件、企業向けプラットフォーム、制御可能な展開を強調するのはこのためです。Agentの未来は「何でも無制限にできる」ことではなく、安全境界の中で実行可能、追跡可能、管理可能であることです。

まとめ

Google I/O 2026の主要内容は一言でまとめられます。GoogleはGeminiを、モデル、アプリ、システム、開発者ツール、ハードウェアを横断するAgentプラットフォームにしようとしています。

Gemini 3.5 Flash は速度と実行能力を提供し、Gemini Omni はマルチモーダル制作を動画と世界理解へ進め、Gemini app は能動的な個人アシスタントへ向かいます。Antigravity 2.0 と Managed Agents は開発者ツールをAgentネイティブへ押し出し、AppFunctions はAndroidアプリが智能体へ能力を公開する入口になります。

開発者が次に見るべきものは、モデルパラメータだけではありません。アプリ能力をどう構造化するか、Agentツールチェーンへどう接続するか、権限と監査をどう設計するか、そして自分の製品をシステムレベルAgentエコシステムの中で安全かつ信頼できる形で呼び出せるようにするかです。

参考：

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 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 3.5 Pro が早くも流出：Google は Spark Agent で AI コーディングの入口を取り戻せるか

Fri, 15 May 2026 23:45:34 +0800

Gemini 3.5 Pro はまだ正式発表されていませんが、関連するリークはすでに盛り上がり始めています。

今回の情報で目立つキーワードは、Gemini 3.5 Pro、コードネーム Cappuccino、Gemini Spark、AI コーディング、MCP ツール接続です。これらが示す方向は一つです。Google は単にチャットモデルを更新したいのではなく、モデル、ツール、Agent、そして Google エコシステムの入口を再び結び直そうとしています。

ただし、正式発表前の情報はあくまで「リーク」として見るべきです。本当に注目すべきなのは、1 枚のスクリーンショットや 1 つのスコアではなく、Google が次にどの弱点を補おうとしているかです。

Gemini 3.5 Pro が注目される理由

公開された情報を見る限り、Gemini 3.5 Pro は命名上のジャンプになる可能性があります。

少し前までは Gemini 3.2 が話題になっていましたが、その後 Gemini 3.5 Pro という名称が出てきました。もしこの命名が本当なら、Google は次のリリースで通常の小さな更新ではなく、より大きなバージョンストーリーを語ろうとしていることになります。

現時点で流れている重点は主に 3 つです。

コーディングと推論能力の継続的な改善。
SVG、インタラクティブページ、アニメーション、3D 生成能力の強化。
新しい Agent 製品 Gemini Spark が前面に出る可能性。

これらの方向性自体は意外ではありません。Gemini シリーズは以前からマルチモーダルを重視しており、Google には強力な配布チャネルもあります。問題は、開発者ツールと Agent ワークフローで OpenAI や Anthropic のペースに追いつけるかどうかです。

コーディング能力は Google が最も補うべき課題

2026 年に入ってから、大規模モデル競争におけるコーディングは、単なる「モデル能力テスト項目」ではなくなりました。最も直接的なプロダクト入口の一つになっています。

理由は単純です。AI コーディングツールは利用頻度が高く、大量のフィードバックデータを生みます。開発者は毎日、モデルにコードを読ませ、修正させ、テストを走らせ、バグを直させています。こうしたやり取りは、次世代モデルとツールチェーンの進化を自然に押し進めます。

この 1 年で Claude Code は開発者の間で強い存在感を得ました。OpenAI も Codex と ChatGPT の連携を継続的に強化しています。一方で Google には Antigravity などの製品がありますが、外部での存在感はそれほど強くありません。

だからこそ Gemini 3.5 Pro は注目されています。もしチャットが少し上手くなり、回答が少し速くなるだけなら、意味は限定的です。コード理解、複数ファイル編集、ツール呼び出し、長時間タスク実行が本当に改善されるなら、開発者のワークフローを変える可能性があります。

Gemini Spark はより大きな変数かもしれない

モデルそのものより攻めているのが、噂されている Gemini Spark です。

リークによれば、Spark は通常のチャットアシスタントではなく、常時稼働する AI Agent として位置づけられています。メール、カレンダー、Web ページ、タスク、アカウント状態、個人コンテキストに接続し、複数ステップのワークフローを処理する可能性があります。

このタイプの製品には大きな可能性があります。たとえば次のような使い方です。

受信箱を自動整理する。
ユーザーのタスクをフォローする。
Web ページ上で操作を実行する。
アプリをまたいだ流れを処理する。
個人の好みに基づいて日常タスクを調整する。

ただしリスクも同じくらい明確です。常時稼働する Agent がログイン状態、ブラウザデータ、ファイル、位置情報、サードパーティサービスにアクセスできるなら、いくつかの問いに答える必要があります。どの操作でユーザー確認が必要なのか。自動実行を禁止すべき操作は何か。データは第三者に共有されるのか。リモートブラウザと認証情報はどう隔離されるのか。

つまり Spark の本当の見どころは、「作業を代行できるか」だけではありません。Google が権限、監査、確認フロー、ユーザー制御を十分に明確にできるかどうかです。

MCP ツール接続が示すもの

リークでは、新しい Gemini のモデル選択画面に MCP 関連モデルやテスト入口が出る可能性も触れられています。

もしこれが実装されるなら、Google もモデルを「質問応答システム」から「ツール操作システム」へ進めていることになります。モデルは単にテキストを生成するだけではなく、外部ツールを呼び、業務システムにアクセスし、ファイルを読み書きし、コマンドを実行し、複数ステップにわたってタスク状態を保つ必要があります。

これは OpenAI や Anthropic と同じ方向です。ツール呼び出しをより安定させられる企業ほど、AI を現実のワークフローに組み込みやすくなります。

ただし MCP 接続そのものがゴールではありません。本当に難しいのは安定性です。

モデルは正しいツールを選べるか。
パラメータは信頼できるか。
失敗後に復旧できるか。
権限境界は明確か。
ユーザーは各ステップを追跡できるか。

これらが解決されないままツールだけが増えると、失敗の表面積も広がります。

マルチモーダルは依然として Google の強いカード

Google が差別化しやすい領域は、やはりマルチモーダルです。

流出した SVG、インタラクティブページ、アニメーション、視覚生成の例を見ると、Gemini は「プロンプトから操作可能なコンテンツを生成する」能力をさらに強化する可能性があります。単にコードを書くよりも、これはプロダクトプロトタイピングに近いものです。ユーザーがアイデアを説明すると、モデルが操作可能で調整でき、プレビューできる画面を直接出すという流れです。

この路線は Google に合っています。Gemini のマルチモーダル能力を活かせるだけでなく、Android、Chrome、Workspace、検索、広告、クラウドサービスなどの入口とも結びつけられます。

Google が「どのコードモデルが一番強いか」だけの勝負を避けたいなら、より完全なマルチモーダル Agent システムへ重点を置く可能性があります。

3 社の戦い方は分かれ始めている

現在の大規模モデル競争は、単一のランキング競争ではありません。

OpenAI の強みは、プロダクト反復と配布速度です。Codex、ChatGPT、企業向けツール、API の連携はますます強くなっています。

Anthropic の強みは、開発者の認知とコードモデル品質です。Claude Code はすでに多くの人にとって標準の AI コーディング入口になっています。

Google の強みはエコシステム入口です。Gmail、Docs、Chrome、Android、検索、YouTube、Maps、クラウドサービスは、巨大な個人・企業データネットワークを形成しています。Agent がこれらの入口に安全に接続できれば、Google は「モデルの追随者」から「ワークフロー入口の支配者」へ移れる可能性があります。

だからこそ Gemini Spark は注目に値します。すべてのベンチマークで 1 位になる必要はありません。日常のワークフローに入り込めれば、独自の堀を作れる可能性があります。

一般ユーザーはどう見るべきか

一般ユーザーにとっては、短期的にすべてのリークに振り回される必要はありません。

より実用的な観察点は 3 つです。

Gemini 3.5 Pro のコーディング能力が本当に改善されるか。特に複雑なリポジトリ、長いコンテキスト、ツール呼び出し。
Gemini Spark がデフォルトで安全か。機密操作の前に明確な確認と追跡可能な記録があるか。
Google が価格、クォータ、企業向け権限管理を明確に示すか。デモだけで終わらないか。

きれいなスクリーンショットを数枚生成するだけなら価値は限定的です。現実のワークフローへ安定して接続できるかどうかが、この世代の AI Agent 製品の分岐点になります。

開発者にとっての意味

開発者が最も気にするべきなのは、「どのモデルが勝ったか」ではなく、自分のワークフローが移行可能かどうかです。

Claude Code、Codex、Gemini、Antigravity、Cursor、Windsurf など、多くのツールが入口を奪い合っています。すべての作業を 1 つのプラットフォームに固定すると、将来コスト、クォータ、モデル方針、権限ルールが変わったときに移行がつらくなります。

より堅実なやり方は次の通りです。

重要なプロジェクトでは標準的な Git ワークフローを維持する。
自動編集後は必ず diff を確認する。
重要なタスクはテストと CI で支える。
本番用の認証情報を不透明な Agent に渡さない。
オープンなプロトコルでツール接続できる場合は、置き換え可能な選択肢を優先する。

モデルはこれからも強くなりますが、エンジニアリングの規律は古くなりません。

まとめ

Gemini 3.5 Pro のリークは、Google が AI コーディングと Agent の入口を急いで補強していることを示しています。モデル性能の向上はその一部であり、Gemini Spark のような常時稼働 Agent こそ、より大きな戦略的動きかもしれません。

ただし、ユーザーの代わりに「自動で作業する」システムほど、厳格な権限境界と検証可能なワークフローが必要です。Google にとって本当の課題は、GPT-5.5 や Claude に追いつくことだけではありません。強いモデル、安全機構、エコシステム入口を、信頼できる日常ワークフローとして組み合わせることです。

それが実現できれば、Gemini はすべてのランキングで 1 位にならなくても、AI の入口における主導権を一部取り戻せるかもしれません。

Codex は中国系 LLM とどう接続する？CCX で OpenAI 互換 API を一元管理する

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

CCX は AI API プロキシ兼プロトコル変換ゲートウェイです。Claude Messages、OpenAI Chat Completions、OpenAI Images、Codex Responses、Gemini API を 1 つのサービス入口にまとめ、チャネル、キー、モデルマッピング、優先度、フェイルオーバー、トラフィック監視を設定する Web 管理画面も提供します。

Claude、OpenAI、Gemini、Codex を同時に使っている場合や、OpenAI API 互換の上流サービスを複数維持している場合、CCX の価値は入口と管理の一元化にあります。クライアントは 1 つのサービスアドレスへ接続し、後続の上流チャネルは CCX が選択します。

プロジェクト：https://github.com/BenedictKing/ccx

CCX が解決すること

複数の AI API を混在させると、次の問題が起きやすくなります。

プロバイダーごとにパス、認証方式、リクエスト形式が異なる。
同じ種類のモデルでも複数の上流があり、base URL や API key を手動で切り替える必要がある。
ある key やチャネルが失敗したとき、クライアント側では自動でバックアップへ切り替わらないことが多い。
チーム利用では、モデル許可リスト、プロキシ、カスタムヘッダー、呼び出しログの集中管理が難しい。
Claude、Gemini、OpenAI Chat、画像 API、Codex Responses を同時に扱うと設定が散らばる。

CCX はこれらの差異をプロキシ層へ集約します。フロントエンドツール、スクリプト、業務サービスは CCX だけにアクセスし、CCX が API 種別、モデル、チャネル状態、優先度、ヘルス状態に基づいて適切な上流へ転送します。

対応エンドポイント

CCX は統一されたバックエンド入口を提供します。デフォルトポートは 3000 です。主なパスは次の通りです：

GET  /                         -> Web 管理画面
GET  /health                   -> ヘルスチェック
/api/*                         -> 管理 API
POST /v1/messages              -> Claude Messages プロキシ
POST /v1/chat/completions      -> OpenAI Chat プロキシ
POST /v1/responses             -> Codex Responses プロキシ
POST /v1/images/generations    -> OpenAI Images 生成
POST /v1/images/edits          -> OpenAI Images 編集
POST /v1/images/variations     -> OpenAI Images バリエーション
GET  /v1/models                -> モデル一覧
POST /v1beta/models/*          -> Gemini プロキシ

つまり、1 種類のプロトコルだけをプロキシするのではなく、Messages、Chat、Responses、Gemini、Images というよく使われる AI API 種別を個別のチャネルとして管理します。プロトコルごとにヘルス状態やログ空間が分かれるため、トラブルシュートしやすくなります。

アーキテクチャの考え方

CCX は Go バックエンドと Vue 3 フロントエンドで構成されています。フロントエンドのビルド成果物はバックエンドバイナリに埋め込まれるため、単一ポートでデプロイできます。同じサービスが Web UI、管理 API、プロキシ API を提供します。

リクエストの流れは概ね次の通りです：

`1`	`Client -> Auth Middleware -> Route Handler -> Channel Scheduler -> Provider / Converter -> Upstream API -> Metrics / Channel Logs -> Client Response`

主要モジュールの役割：

handlers: 各プロトコルのリクエストと管理操作を受け付ける。
providers: 上流 API のリクエストとレスポンス処理をラップする。
converters: Responses などの場面でプロトコル変換を行う。
scheduler: 優先度、プロモーション期間、ヘルス状態、サーキットブレーカー状態、セッション親和性に基づいてチャネルを選ぶ。
metrics: リクエスト数、成功率、遅延、ログ、サーキットブレーカー状態を記録する。
config: ランタイム設定を管理し、ホットリロードとバックアップをサポートする。

この設計の要点は、すべての API を無理に 1 つの形式へ変換することではありません。プロトコル種別ごとに代理し、管理、スケジューリング、ログ、認証を統一することです。

CCX と CodexBridge の違い

CCX と CodexBridge はどちらも Codex と OpenAI 互換 API に関係しますが、解決する問題が違います。

CodexBridge は専用の Codex ブリッジに近いツールです。目的は Codex CLI/SDK を OpenAI 互換の /v1/chat/completions サービスとして公開し、OpenWebUI、Cherry Studio、スクリプト、その他の OpenAI 互換クライアントからローカル Codex を呼び出せるようにすることです。つまり、CodexBridge の焦点は「Codex を外へ出す」ことです。

CCX は統一 AI API ゲートウェイに近いツールです。Codex Responses だけでなく、Claude Messages、OpenAI Chat、OpenAI Images、Gemini API も扱い、Web 管理画面、チャネル優先度、フェイルオーバー、ログ監視、複数 key 管理を提供します。つまり、CCX の焦点は「複数のモデルとプロバイダーをまとめて管理する」ことです。

簡単な比較：

項目	CodexBridge	CCX
中心的な位置づけ	Codex ローカルブリッジ	マルチプロトコル AI API ゲートウェイ
主な目的	Codex を OpenAI 互換エンドポイントにする	Claude、OpenAI、Gemini、Codex などのチャネルを一元管理する
管理画面	API サービス自体が中心	Web 管理画面を提供
複数チャネル調度	主目的ではない	チャネル優先度、フェイルオーバー、ログ監視に対応
向いている場面	ローカルまたは単一サービスで Codex を呼ぶ	チーム、多数の key、複数プロバイダー、複数プロトコル

Codex を OpenWebUI や Cherry Studio に接続したいだけなら CodexBridge のほうが直接的です。Codex、Claude、Gemini、DeepSeek、Qwen、Kimi など複数の上流をまとめて管理したいなら CCX が向いています。

クイックデプロイ

最も簡単なのはバイナリをダウンロードする方法です。ダウンロード後、同じディレクトリに .env を作成します：

PROXY_ACCESS_KEY=your-proxy-access-key
PORT=3000
ENABLE_WEB_UI=true
APP_UI_LANGUAGE=zh-CN

起動後、次へアクセスします：

`1`	`http://localhost:3000`

Windows で WSL、Docker、PowerShell などから localhost に接続できない場合は、Windows ホストの LAN IPv4 アドレスを使います。例：

`1`	`http://192.168.1.23:3000`

CCX はデフォルトで :PORT により全ネットワークインターフェースを待ち受けるため、LAN に公開する場合はアクセス制御に注意してください。

Docker デプロイ

Docker は常駐サービスに向いています：

docker run -d \
  --name ccx \
  -p 3000:3000 \
  -e PROXY_ACCESS_KEY=your-proxy-access-key \
  -e APP_UI_LANGUAGE=zh-CN \
  -v $(pwd)/.config:/app/.config \
  crpi-i19l8zl0ugidq97v.cn-hangzhou.personal.cr.aliyuncs.com/bene/ccx:latest

リポジトリに docker-compose.yml がある場合は次でも起動できます：

`1`	`docker compose up -d`

自動更新が必要なら Watchtower 設定を重ねます：

`1`	`docker compose -f docker-compose.yml -f docker-compose.watchtower.yml up -d`

デプロイ後、.config ディレクトリにはランタイム設定と永続データが保存されます。コンテナ再作成時に設定を失わないよう、ホストへマウントするのがおすすめです。

ソースから実行

開発またはカスタムビルドではソースから実行できます：

git clone https://github.com/BenedictKing/ccx
cd ccx
cp backend-go/.env.example backend-go/.env
make run

よく使うコマンド：

make dev
make run
make build
make frontend-dev

フロントエンドのみの開発：

1
2
3

cd frontend
bun install
bun run dev

バックエンドのみの開発：

1
2

cd backend-go
make dev

主な環境変数

最小構成は通常次のようになります：

PORT=3000
ENV=production
ENABLE_WEB_UI=true
PROXY_ACCESS_KEY=your-proxy-access-key
ADMIN_ACCESS_KEY=your-admin-secret-key
APP_UI_LANGUAGE=zh-CN
LOG_LEVEL=info
REQUEST_TIMEOUT=300000

ポイント：

PROXY_ACCESS_KEY はプロキシ API 用で、必ず変更します。
ADMIN_ACCESS_KEY は Web 管理画面と /api/* 用で、プロキシ用キーとは分けるべきです。
ENABLE_WEB_UI は管理画面の有効化を制御します。
REQUEST_TIMEOUT はリクエストタイムアウトです。長文コンテキストや画像タスクでは増やせます。
LOG_LEVEL はログレベルです。本番環境では通常 info または warn を使います。

リクエスト本文サイズを制限したい場合：

`1`	`MAX_REQUEST_BODY_SIZE_MB=50`

画像編集、base64 画像、マルチモーダルリクエストでは本文サイズが大きくなりがちです。

チャネル編成とフェイルオーバー

CCX の管理画面では複数チャネルを設定でき、各チャネルに次のような項目を指定できます：

上流サービス種別。
API key または複数 key のローテーション。
プロキシアドレス。
カスタムリクエストヘッダー。
モデル許可リスト。
ルートプレフィックス。
優先度。
ヘルスチェックとサーキットブレーカー復旧。

スケジューリングでは、チャネル状態、優先度、プロモーション期間、Trace 親和性、サーキットブレーカー状態、利用可能な key を総合的に考慮します。簡単に言うと：

通常は優先度の高いチャネルが先に使われる。
あるチャネルが失敗するとバックアップへフェイルオーバーできる。
サーキットブレーカーにより、明らかに使えない上流へ打ち続けることを避ける。
Trace 親和性により、同種のセッションをなるべく適切なチャネルに維持する。

これは複数 key、複数プロバイダー、複数地域の上流がある場合に便利です。個人の軽量利用なら、1 つのチャネルだけを設定して Web UI 付きプロキシ層として使うこともできます。

ログと監視

CCX はチャネル指標とリクエストログを提供します。確認できるもの：

リクエスト数。
成功率。
失敗率。
平均遅延。
モデル別の履歴データ。
チャネル状態とサーキットブレーカー状態。

本番環境では控えめなログ設定がよいです：

ENV=production
LOG_LEVEL=info
ENABLE_REQUEST_LOGS=true
ENABLE_RESPONSE_LOGS=false

これにより基本的なリクエスト情報を残しつつ、完全なレスポンス内容をログに書かないようにできます。調査時には一時的に詳細ログを有効化できますが、終わったら戻すべきです。特に本番でリクエスト本文とレスポンス本文を長期出力し続けるのは避けます。

セキュリティ上の注意

CCX はプロキシゲートウェイであり、上流 API key を保存します。したがって「動けばよい」だけで終わらせるべきではありません。少なくとも：

デフォルトまたは短すぎる PROXY_ACCESS_KEY を使わない。
ADMIN_ACCESS_KEY を別に設定する。
Web 管理画面を直接インターネットへ公開しない。
公開が必要な場合は、リバースプロキシ、VPN、アクセス制御、SSO の後ろに置く。
.env、.config、ログファイルを Git にコミットしない。
本番環境で完全なリクエスト本文とレスポンス本文のログを長期的に有効化しない。

ランダムキーは次のように生成できます：

1
2

PROXY_ACCESS_KEY=$(openssl rand -base64 32)
ADMIN_ACCESS_KEY=$(openssl rand -base64 32)

向いている人

CCX は次のような場面に向いています：

Claude、OpenAI、Gemini、Codex、画像 API を同時に維持している。
複数の API key があり、ローテーション、分流、フェイルオーバーが必要。
設定ファイルを手で編集するのではなく Web UI で上流チャネルを管理したい。
各チャネルの成功率、遅延、リクエストログを観察したい。
チームへ統一された AI API 入口を提供したい。

自分のマシンで単一モデルをたまに呼ぶだけなら、公式 SDK や単一の OpenAI 互換プロキシのほうが簡単です。CCX の強みは、複数チャネル、複数プロトコル、統一運用にあります。

まとめ

CCX は AI API ゲートウェイであり、特定モデルのクライアントではありません。Claude Messages、OpenAI Chat、OpenAI Images、Codex Responses、Gemini を 1 つのプロキシ層にまとめ、チャネル編成、フェイルオーバー、ログ監視、Web 管理画面を提供します。

個人利用では API アドレスやキーの切り替えを減らせます。チームや長期運用サービスでは、軽量な AI ゲートウェイに近い存在です。本番導入前には、モデル設定だけでなく、キー、管理入口、ログレベル、チャネル優先度、フェイルオーバー戦略も整える必要があります。

参考

GitHub プロジェクト：https://github.com/BenedictKing/ccx
アーキテクチャ説明：https://github.com/BenedictKing/ccx/blob/main/ARCHITECTURE.md
環境変数説明：https://github.com/BenedictKing/ccx/blob/main/ENVIRONMENT.md

ChatGPT、Claude Code、Gemini の記憶機構は何が違うのか

Thu, 07 May 2026 14:47:17 +0800

AI 製品における「記憶」はますます重要になっている。これは AI が「単発の会話ツール」から「長期的な協力相手」へ移行していることを示している。毎回背景を説明し直す必要がなくなり、好みを繰り返し伝える必要もなく、同じプロジェクトを何度も理解させる必要も減る。

しかし、製品ごとの記憶は同じものではない。ChatGPT、Claude Code、Gemini はいずれも「AI がより長く覚える」問題を扱っているが、設計目標、保存場所、透明性、適用シーンは大きく異なる。

2026 年 5 月 7 日時点では、おおまかに3つに分けられる。

ChatGPT は「個人アシスタントの記憶」に近い。
Claude Code は「エンジニアリングプロジェクトの記憶」に近い。
Gemini は「Google エコシステムの文脈」に近い。

ChatGPT：人を中心にした長期的な好み

ChatGPT の記憶機構は主に個人協作向けだ。関心の中心は「あなたは誰か」「何を好むか」「長期的に何をしているか」にある。

OpenAI は現在、ChatGPT の記憶を saved memories と chat history に分けている。

saved memories は、ChatGPT が保存する重要情報だ。名前、好み、目標、よく使う技術スタック、文章の癖などが含まれる。ユーザーが明示的に覚えるよう頼むこともできるし、ChatGPT が会話の中から将来役立つと判断した情報を保存する場合もある。

chat history は、回答時に過去の会話を参照する仕組みだ。すべての会話がそのまま記憶になるわけではなく、必要に応じて過去の会話から関連文脈を探す。

つまり ChatGPT の中核ロジックは、同じユーザーを会話をまたいで理解することだ。

典型例は次のようなものだ。

「今後コード例はできるだけ簡潔にして。」
「私は主に Python と TypeScript を使っている。」
「AI ツールについての Hugo ブログを書いている。」
「先に結論を見て、その後に詳細を読むのが好き。」

これらの記憶は特定プロジェクトに紐づくものではなく、アカウントと個人の利用習慣についてくる。

Memory Sources：個人化の出所を見えるようにする

OpenAI は 2026 年 5 月の更新で Memory sources を強調した。

これは新しい記憶タイプではなく、ChatGPT が回答を個人化するときに参照した情報源をユーザーに見せる仕組みだ。OpenAI のヘルプ文書によると、Memory Sources には次のようなものが表示される場合がある。

過去のチャット。
保存された記憶。
カスタム指示。
ファイルライブラリ内のファイル。
接続済み Gmail のメール。

ファイルや Gmail の表示範囲は、プラン、地域、接続状態によって制限される。OpenAI はまた、Memory sources が回答に影響したすべての要因を表示するとは限らず、個人化の理解と管理を助けるものだと説明している。

これは重要だ。AI が「あなたを覚える」ほど、ユーザーは何に基づいて回答したのかを知る必要がある。そうでなければ個人化はブラックボックスになりやすい。AI が自分を知っているように見えるが、なぜ知っているのか分からない状態になる。

ChatGPT の強みは、会話やテーマをまたいで個人の好みを継続的に理解することだ。一方で、記憶が古くなったり、古い記憶がまだ回答に影響していることをユーザーが忘れたりするリスクもある。そのため saved memories と古いチャットは定期的に整理したほうがよい。

Claude Code：コードベースとエンジニアリングルールを中心に

Claude Code の記憶機構はエンジニアリング協作寄りだ。関心の中心は「ユーザーが普段何を好むか」ではなく、「このコードベースをどう変更すべきか」だ。

Claude Code には混同されやすい2種類の記憶がある。

明示的なプロジェクト記憶：CLAUDE.md。
自動プロジェクト記憶：Auto Memory。

CLAUDE.md は最も基本的で安定したプロジェクト記憶ファイルだ。プロジェクトルートにも、サブディレクトリにも置ける。Claude Code はこれらのファイルを読み、プロジェクト説明と作業ルールとして扱う。

CLAUDE.md に書くのに適した内容は次の通りだ。

よく使う build、test、lint コマンド。
コードスタイルと命名規則。
プロジェクトアーキテクチャ。
モジュール境界と危険な領域。
チームの約束事とコミットフロー。

CLAUDE.md をリポジトリに置けば、Git にコミットしてチーム共有の agent 説明書にできる。これは ChatGPT のクラウド上の個人記憶とはまったく異なる。

Claude Code Auto Memory：プロジェクト経験を自動で蓄積する

Claude Code には現在 Auto Memory もある。目的は、ユーザーが毎回手で説明を書かなくても、Claude が複数セッションにまたがってプロジェクト経験を自動的に蓄積できるようにすることだ。

Claude Code の文書によると、Auto Memory は作業中に Claude が自分用のメモを保存する仕組みだ。build コマンド、デバッグで分かったこと、アーキテクチャ説明、コードスタイルの好み、ワークフロー習慣などが対象になる。すべてのセッションで保存するわけではなく、将来役立ちそうな情報を判断する。

誤解されやすい点がある。Auto Memory はデフォルトでプロジェクトルートの .claude/memory.md に書くわけではない。公式文書では、各プロジェクトはユーザーディレクトリ配下に独自の memory ディレクトリを持つと説明されている。パスは次のような形だ。

`1`	`~/.claude/projects/<project>/memory/`

MEMORY.md は各会話開始時に最初の 200 行または 25KB が読み込まれ、詳細は別のトピックファイルへ分割される場合がある。Auto Memory ファイルはローカルの Markdown ファイルで、ユーザーは /memory から表示、編集、削除できる。

これにより Claude Code の記憶は「ローカル上のプロジェクト経験庫」に近くなる。ChatGPT の個人記憶よりコードベースに近く、単なる CLAUDE.md より動的だ。

ただし Auto Memory はローカルマシン上のものだ。リポジトリと一緒に他のマシンやクラウド環境へ自然に同期されるわけではない。チームで共有すべき安定したルールは、やはりプロジェクト内の CLAUDE.md に書くべきだ。

Gemini：Google エコシステムの文脈を中心に

Gemini の記憶ロジックはまた別だ。

Gemini にも保存情報と過去チャット参照の能力がある。Google のヘルプ文書では、ユーザーは生活、仕事、好みに関する情報を保存でき、Gemini は回答前に過去のチャットを参照できると説明されている。これらの情報を使うと、回答下部のソース領域に Your saved info や Previous chats が表示される場合がある。

しかし Gemini の差別化は「好みを数個保存する」ことだけではなく、Google エコシステム連携にある。

ユーザーが許可し、機能が利用可能な場合、Gemini は Gmail、Google Drive、Docs、Sheets など接続された Google アプリから文脈を取得できる。強みは、ユーザーが一つずつ教え込むことではなく、すでに Google アカウント内にある資料を検索可能な作業文脈にできることだ。

典型的な違いは次のようになる。

ChatGPT は「最近 LTO テープドライブを修理している」と覚える。
Gemini は Gmail から購入確認メールを見つけたり、Drive から修理メモを読んだりできる場合がある。

もちろん、Gemini が無条件で Google データすべてを読めるわけではない。アカウント種別、地域、権限、接続アプリ、Keep Activity 設定、具体的な製品提供状況に依存する。企業や学校アカウントでは、Google Workspace 管理者の制御も受ける。

より正確に言えば、Gemini の記憶は単純な「メモ帳」ではなく、「保存情報 + 過去チャット + Google エコシステム接続」の組み合わせだ。

3者の主な違い

次元	ChatGPT	Claude Code	Gemini
中心対象	人と好み	プロジェクトとコードベース	Google アカウントとエコシステム資料
典型的な記憶	好み、背景、長期目標	アーキテクチャ、コマンド、規約、デバッグ経験	saved info、過去チャット、Gmail/Drive/Docs 文脈
保存形態	OpenAI アカウント内の記憶とチャット文脈	`CLAUDE.md`、`MEMORY.md`、ローカル Markdown ファイル	Google アカウント活動、保存情報、接続アプリデータ
透明性	Memory sources で一部の出所が見える	Markdown ファイルを直接表示・編集できる	ソース表示、Gemini Apps Activity、Google 設定で管理
プロジェクト横断	強い。ユーザーアカウントに追従	弱い。主にプロジェクトまたはローカル project memory に追従	強い。Google 資料と権限に依存
チーム共有	直接共有には不向き	`CLAUDE.md` を Git で共有可能	主に Workspace と権限体系に依存
得意領域	個人の好みと長期アシスタント	長期コードプロジェクトと agent 協作	Google Workspace 資料検索とクロスツール作業

どう選び、どう使うか

AI に「自分は誰か、どんなスタイルが好きか、普段どう働くか」を覚えさせたいなら、ChatGPT の記憶が向いている。

文章スタイル、よく使う技術スタック、回答形式、職業背景、長期プロジェクトの方向といった個人の好みを保存するのに適している。重点は自己紹介コストを下げ、新しい会話を素早く始めることだ。

AI に「このコードベースをどう変えるか、どのコマンドが動くか、どの罠を避けるか」を覚えさせたいなら、Claude Code が向いている。

安定したルールは CLAUDE.md に書いてチーム共有する。動的な経験は Auto Memory に補助させる。重要な意思決定はローカル自動記憶にだけ残さず、文書や CLAUDE.md に整理するのがよい。

資料の多くが Gmail、Drive、Docs、Sheets にあるなら、Gemini のエコシステム文脈が有利だ。

過去メールの検索、Google Drive 文書の整理、カレンダーやオフィス資料との連携に向いている。Gemini を使うポイントは、チャット内で何度も思い出させることではなく、関連アプリの接続、権限、アクティビティ設定を正しくしておくことだ。

実用的な分担

3者は次のように分担できる。

ChatGPT は「自分の一般的な好み」を覚える。
Claude Code は「このリポジトリのエンジニアリング知識」を覚える。
Gemini は「Google エコシステム内の資料」を検索する。

つまり、ChatGPT は個人秘書、Claude Code はプロジェクト内のシニアエンジニア、Gemini は Google アカウント内の資料インデクサーに近い。

この3種類の記憶に絶対的な優劣はない。目的が違うだけだ。

最も注意すべきなのは混同することだ。個人の好みは必ずしもプロジェクト記憶に書くべきではない。プロジェクトアーキテクチャは必ずしもクラウド上の個人記憶に保存すべきではない。Google エコシステム検索は、モデルがあなたを長期的に本当に理解したことと同じではない。

短い判断

AI 記憶の次の段階は、単に「多く覚える」ことではない。記憶は階層化され、見えるようになり、制御可能である必要がある。

ChatGPT の重点は会話をまたいだ個人化、Claude Code の重点はコードプロジェクトの継続性、Gemini の重点は Google エコシステム文脈だ。本当に使いやすい長期 AI 協作は、すべての情報を一つのブラックボックスに詰め込むのではなく、異なる種類の記憶を適切な場所に置く。

個人の好みは個人記憶に、エンジニアリングルールはコードベースに、過去資料は元の文書やメールシステムに置く。AI がすべきことは、必要なときに正確にそれらの文脈を呼び出すことであり、すべてを一つに混ぜることではない。

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

ChatGPT・Claude・Gemini の役割分担はどうするべきか：日常会話、コーディング、特殊機能の選び方

Sat, 25 Apr 2026 10:51:19 +0800

今では、多くの人が1つのモデルだけを使うのではなく、ChatGPT、Claude、Gemini を行き来しながら使っています。そうなると問題はかなり実務的になります。どんなタスクを、どのモデルに任せるべきなのか。

この点が悩ましくなるのは、3社とも弱いからではありません。むしろ十分に強くなった結果、それぞれの得意分野が分かれてきたからです。いまだに「どれがいちばん賢いか」のような曖昧な基準で選ぶと、かえって外しやすくなります。

まずは簡略版の結論から言うと、おおむね次のように考えられます。

日常会話や汎用タスクなら、まず ChatGPT を思い浮かべる人が多い
コマンドラインでのコーディング、長いコンテキストでの協業、継続的に進めるタイプの作業なら、Claude のほうが扱いやすいことが多い
Google エコシステム、検索、マルチモーダルの入口、あるいは一部の製品レベルの特殊機能が必要なら、Gemini の存在感が強い

以下、3つに分けて見ていきます。

1. 日常会話：なぜ多くの人がまず `ChatGPT` を開くのか

多くの一般的な利用シーンでは、ChatGPT は今でも「標準の入口」のような存在です。

ここで言いたいのは、特定の benchmark の話ではなく、全体的な使い心地です。
ちょっとした質問をしたいとき、考えを整理したいとき、短い文章を書きたいとき、たたき台を作りたいとき、資料を要約したいときに、ChatGPT は全体としてバランスがよく感じられます。

強みは主に次の点にあります。

回答スタイルが比較的安定している
一般ユーザーにとって使い始めるハードルが低い
多くの総合タスクで過度な追加調整がいらない
製品としての完成度が高く、日常的に高頻度で使いやすい

たとえば次のような作業なら、

あるテーマを整理してほしい
アイデアを構造化された内容にまとめたい
長文を要約したい
いくつかの案をブレインストーミングしたい
表現をより分かりやすく整えたい

ChatGPT はかなり自然な出発点になります。

これは、あらゆる専門タスクで必ず最強だという意味ではありません。むしろ「広く汎用的に使える」という点で、標準の作業台に近いということです。

2. コマンドラインでのコーディングと長いタスク：なぜ `Claude` を好む人が多いのか

タスクが「少し会話する」段階から、「最後まで継続して進める」段階に移ると、多くの人の好みは Claude に傾き始めます。

特に次のような場面です。

コマンドラインでのプログラミング
大規模プロジェクトのコンテキスト理解
複数ファイルをまたぐ修正
長い流れのデバッグ
コードを読みながらタスクを前進させる作業

こうしたタスクで重要なのは、1回の返答がどれだけ派手かではなく、長い作業の流れの中で安定していられるかどうかです。

Claude が好まれる理由は、「ひとことが他よりうまいから」ではなく、主に次の点にあります。

長いコンテキストのタスクでも粘り強い
ファイル、ログ、ルールを連続して読むときの安定感が高い
複雑なコーディング作業を段階的に進めやすい
コマンドラインや agent ワークフローでは主力モデルとして扱われやすい

vibe coding、コマンドラインでのバグ修正、プロジェクト構造の理解、複数ファイルにまたがる機能改修をしているなら、Claude の強みはより見えやすくなります。

要するに、Claude は一問一答のためだけでなく、一緒に「作業を進める」相手として向いているモデルだと言えます。

3. `Gemini` の強みは「何でも正面から勝つこと」ではない

Gemini を語るとき、多くの人は「結局3つの中で最強なのか」と聞きがちです。

しかし実際の利用感覚からすると、もっと有用な問いはそこではありません。どんな場面で、あえて単独で使う価値が高いのか。

Gemini の価値は、主に次の方向で表れやすいです。

Google エコシステムとの連携
検索や情報収集
マルチモーダルの入口
一部の製品機能との連動

もし普段のワークフローがもともと Google のツールチェーンに近いなら、たとえば

検索
ドキュメント
メール
ブラウザ上での利用
モバイル側の入口

Gemini の実用上の便利さは、単純なモデル性能の比較よりも重要になるかもしれません。

つまり Gemini の使いやすさは、「どこで自分のワークフローに自然につながるか」から来ることが多く、「単発の回答で誰に勝つか」だけでは測れません。

4. 本当に役立つ選び方は、最強を問うことではなく、タスクの種類を問うこと

3つのモデルを並べて比較するとき、いちばん陥りやすい罠は「唯一の最強」を探そうとすることです。

ですが、現実のタスクはあまりにも違います。

単発のQ&Aもある
長い対話で伴走してもらうものもある
コードベースを扱う作業もある
情報検索もある
マルチモーダル処理もある
ツールチェーンとの協業もある

だからこそ、より有効なのはタスクの種類で分けることです。

総合型で、日常的に高頻度に使えて、開けばすぐ使える助手がほしいなら、まず ChatGPT
長いコンテキスト、コマンドライン、コーディング協業、複雑な作業の継続的な前進が必要なら、まず Claude
Google エコシステム、検索、マルチモーダルの入口、あるいは一部の製品連携を活かしたいなら、Gemini を重視する

このような役割分担のほうが、無理に総合優勝を決めるより、実際の使い方に近いです。

5. なぜヘビーユーザーは3つとも契約するのか

ライトユーザーの視点では、3つ全部に課金するのは重複して見えがちです。
けれどもヘビーユーザーの視点では、それは異なる仕事に異なる道具を割り当てているだけです。

理由は単純です。
3つのモデルの強みがすでにはっきり分かれ始めているなら、同時に使うことは重複課金ではなく、タスク切り替えのコストや試行錯誤のコストを下げる方法だからです。

たとえば、

日常的な整理や総合Q&Aには ChatGPT
コーディングの主作業には Claude
検索、マルチモーダル、Google 関連の導線には Gemini

この組み合わせの考え方は、デザイナーが複数のソフトを入れることや、開発者が複数の IDE を使うことと本質的には変わりません。

6. 何度もモデルを切り替えすぎないほうがいい場面

もちろん、モデルが多ければ常に良いわけではありません。

まだ安定したワークフローを作っている途中なら、3つのモデルを早い段階で頻繁に行き来すると、かえって混乱しやすくなります。よくある問題は次の通りです。

同じタスクを何度も説明し直す
モデルごとに違う提案が出て、判断が難しくなる
コンテキストが途切れ、協業コストが上がる
自分なりの使い分けができる前に、道具選びそのものに引っ張られる

なので、より安定したやり方は次の通りです。

まず各モデルに1つずつ主な担当領域を与える
その担当領域でしばらく続けて使う
そのうえで自分なりの使い分けを徐々に作っていく

こうすることで、「今日はこれを試してみよう」という段階に留まり続けるのではなく、再利用しやすい実践知を得やすくなります。

7. まずはこう覚えておけばいい

とりあえず使える覚え方だけ欲しいなら、次のような口語的な分担表で十分です。

ChatGPT：汎用型の標準アシスタント
Claude：長いタスクとコーディング協業の主力
Gemini：検索、マルチモーダル、Google エコシステムで強みを発揮しやすいツール

これは絶対的なルールではありませんし、3者が互いに代替できないという意味でもありません。あくまで実際の利用感覚に近い出発点です。

本当に重要なのは、「宇宙最強のモデル」を選ぶことではなく、できるだけ早く次を見極めることです。
今、目の前のこの種類のタスクに対して、どのモデルがもっとも時間を節約し、気力を消耗させず、結果につながりやすいか。

Google App デスクトップ版体験：AI 検索を Windows に入れる

Sat, 18 Apr 2026 11:08:00 +0800

Google は、Windows デスクトップ上により軽量な検索入口を用意しました。毎回ブラウザを開かなくても、ショートカットを押すだけで検索ボックスを呼び出し、質問の入力、画像アップロード、ファイル分析、画面上の範囲選択、さらに追加質問まで行えます。

このツールの正式名称は Google app for desktop です。従来のブラウザを置き換えるものではなく、Google Search、AI Mode、Google Lens、画面共有、PC 内ファイル検索、Google Drive 検索を 1 つのデスクトップ検索ボックスにまとめるためのアプリです。

普段から調べ物、文書の要約、スクリーンショット内容の確認、PC 内ファイルの検索をよく行うなら、このデスクトップ版 Google App は試す価値があります。

利用条件

Google の公式ページによると、現在の要件は次の通りです。

ユーザーは 13 歳以上。
Windows 10 以降のデスクトップ端末。
現在、このアプリは英語のみ対応。
Google Search の AI Mode は、すべてのアカウント、国、言語で利用できるわけではありません。

つまり、Windows 10 または Windows 11 を使っている場合は、まずインストールして試すことができます。公式ページには現在 Now available on Windows と明記されているため、この記事では Windows 版を前提に紹介します。

主な機能

1. ショートカットで検索ボックスを開く

インストール後は、次のキーで起動できます。

`1`	`Alt + Space`

Google のデスクトップ検索ボックスがすぐに表示されます。もう一度押すと非表示にできます。

体験としてはシステムランチャーに近いものです。文書作成中、Web ページ閲覧中、ファイル整理中、別アプリの使用中でも、ブラウザに戻らず検索入口を呼び出せます。

2. AI Mode 検索と追加質問

通常の検索は Web ページのリンク一覧を返すことが多いですが、AI Mode は検索結果をもとにした回答を先に整理してくれます。質問を直接入力すると、まとまった説明と参考リンクを受け取れます。

便利なのは、続けて質問できる点です。たとえば最初にこう聞きます。

`1`	`このツールはどんな用途に向いていますか？`

回答を受け取ったあと、さらに続けて聞けます。

`1`	`文章コンテンツを作る場合、どのように使うと作業効率を上げられますか？`

毎回キーワードを作り直したり、複数のページを行き来したりする手間を減らせます。

3. 画像をアップロードして認識・検索する

デスクトップ版 Google App では、画像をアップロードして質問できます。よくある使い方は次の通りです。

画像内の人物、場所、商品、物体を識別する。
類似画像や関連情報を探す。
画像内容から説明文を抽出する。
画像をもとに AI 用のクリエイティブなプロンプトを作る。

たとえば人物画像をアップロードしたあと、次のように質問できます。

`1`	`この画像の人物は誰ですか？関連する紹介と参考資料も教えてください。`

日常的な画像検索、出典探し、物体認識なら、Web ページを開いて画像をアップロードするより手軽です。

4. Google Lens で画面上の内容を選択する

Google Lens は、このデスクトップアプリの中でも特に実用的な機能です。画面上の一部を直接選択し、その内容を認識して検索できます。

次のような場面で使えます。

Web ページ上の商品を選択し、同じ商品や関連情報を探す。
スクリーンショット内の文字を選択し、意味を説明してもらう。
ソフトウェア画面を選択し、何のツールか判断してもらう。
エラーメッセージを選択し、原因調査の手がかりをもらう。

基本の価値は「見たものをそのまま検索できる」ことです。以前ならスクリーンショットを撮って保存し、アップロードする必要がありましたが、今は画面上で直接対象を選べます。

5. 画面共有検索

一部を選択するだけでなく、画面共有にも対応しています。有効にすると、AI が現在のウィンドウまたは画面全体を見ながら、その内容について質問に答えられます。

たとえば記事を開いているときは、次のように聞けます。

`1`	`現在のページの重要ポイントを要約してください。`

または：

`1`	`このページで改善できそうな点はありますか？`

Web ページの読解、デザイン案の確認、コード断片の分析、長いページの要約に向いています。画面共有中は、通常わかりやすい枠線が表示されるため、共有状態を確認しやすくなっています。

6. PC 内ファイルと Google Drive を検索する

公式説明では、同じ検索ボックスから PC 内のアプリやファイル、Google Drive の内容も検索できるとされています。

これはデスクトップ検索とクラウド検索をまとめた機能です。ファイル名の一部、内容のキーワード、Google Drive 内の資料を探したいとき、ファイルエクスプローラーと Drive を別々に開く必要が少なくなります。

初回利用時に Google Drive 検索やローカルファイル検索の有効化を求められた場合は、必要な範囲だけ許可するのがおすすめです。ローカルファイルやクラウドデータに関わるため、アクセス範囲は確認しておきましょう。

インストールと使い方

1. 公式ダウンロードページを開く

公式ページにアクセスします。

https://search.google/google-app/desktop/

ページ内の Download app をクリックしてアプリをダウンロードします。

2. デスクトップアプリをインストールする

ダウンロード完了後、インストーラーを実行し、案内に従ってインストールします。

インストール後は Google アカウントでログインできます。ログインすると Google Drive 検索、パーソナライズ検索、一部の AI 機能を使いやすくなります。基本的な検索だけを試す場合は、画面の案内に従って先に体験してもかまいません。

3. 検索ボックスを呼び出す

ショートカットを押します。

`1`	`Alt + Space`

デスクトップ上に Google 検索ボックスが表示されます。質問を入力したり、ファイルをアップロードしたり、Lens や画面共有を使ったりできます。

4. 必要な検索範囲を有効にする

Google Drive やローカルファイルを検索したい場合は、案内に従って権限を有効にします。

おすすめの流れは次の通りです。

まず Google Drive 検索を有効にし、クラウド資料の検索を試す。
必要になったらローカルファイル検索を有効にする。
不要な検索範囲は許可しない。

こうすると機能を試しながら、どのデータへアクセスしているかも把握しやすくなります。

よくある利用シーン

PDF や文書を分析する

PDF、表、文書をドラッグして、要点をまとめてもらえます。

たとえば：

`1`	`この PDF の重要ポイントを要約し、注意すべき点を列挙してください。`

申請書、明細、表、マニュアルのように情報量が多いファイルなら、続けてこう聞けます。

`1`	`重要な情報をカテゴリ別に整理してください。`

長い文書を 1 ページずつ読むより効率的です。

Web ページを要約する

画面共有を有効にすると、現在のページを直接要約できます。

たとえば：

`1`	`このページの主な論点を抽出し、5 つの箇条書きでまとめてください。`

長文記事、製品ページ、ドキュメント、ニュースページの確認に向いています。

スクリーンショットや画面を識別する

Google Lens で画面上のソフトウェア画面、コード断片、エラー表示、画像内容を選択し、見えている情報を説明してもらえます。

たとえば：

`1`	`このエラーの意味を説明し、調査の進め方を提案してください。`

または：

`1`	`このスクリーンショットに表示されているツールは何ですか？どんな場面で使われそうですか？`

コンテンツ作成を補助する

タイトル作成、アウトライン生成、訴求ポイントの整理にも使えます。

たとえば：

`1`	`AI ツール紹介の記事タイトルを 10 個作ってください。実用ノウハウ、効率化ツール、オフィス業務向けの方向でお願いします。`

初稿を受け取ったあと、さらに調整できます。

`1`	`これらのタイトルをテックブログ向けに調整してください。`

このように続けて聞けるため、検索エンジンに一度で結果を求めるより自然に使えます。

使うときの注意

日常的な調べ物だけなら、より速い Google Search 入口として使えます。画像、PDF、Web ページ、スクリーンショットをよく扱うなら、Lens、ファイルアップロード、画面共有を重点的に試すとよいでしょう。

注意点は 3 つあります。

公式ページでは現在英語のみ対応とされています。中国語や日本語での質問結果は、アカウントや地域によって変わる可能性があります。
AI Mode はすべてのアカウントで使えるとは限りません。表示されない場合は、アカウント、地域、言語設定を確認してください。
ローカルファイル、Google Drive、画面共有はプライバシー権限に関わります。有効にする前に、アクセスさせる内容を確認しましょう。

まとめ

Google App デスクトップ版の一番の価値は、検索入口をブラウザの外に出し、いつでも呼び出せるデスクトップ AI 検索ボックスにすることです。

できることをまとめると：

Alt + Space で素早く検索を呼び出す。
AI Mode で整理された回答を得る。
画像やファイルをアップロードして分析する。
Google Lens で画面上の内容を選択して検索する。
画面共有で現在のウィンドウや画面全体を理解させる。
PC 内ファイル、アプリ、Google Drive の内容を検索する。

すでに Google 検索をよく使っていて、検索を「アシスタントに聞く」感覚に近づけたいなら、Google app for desktop は試してみる価値があります。

参考リンク

Google App デスクトップ版公式ページ：https://search.google/google-app/desktop/

eコマース商品画像の切り抜きと標準化されたエージェントスキルを共有する

Thu, 09 Apr 2026 21:43:50 +0800

product-cutout-normalize は、商品画像に使用されるエージェントスキルです。

元画像を統一仕様の下透明正方形画像に加工します。デフォルトのルールは次のとおりです。

1024x1024 キャンバス
透明な背景
件名は可能な限り完全なものにしてください
縦長の被写体を横長に自動変換
センターボディ
メインの表示幅は820pxに統一

電子商取引資料、製品ライブラリ、詳細ページの画像の前処理に適しています。

このスキルはどのような問題を解決しますか?

多くの製品画像には、基本的な切り抜き後も次の問題が発生します。

白い枠または薄い灰色の背景が残る
被写体の水平方向と垂直方向が一致しない
キャンバスのサイズが不安定です
被写体のサイズは大きいものから小さいものまでさまざまです
透明部分に小さなノイズがある

このスキルは一定のプロセスに従って処理されます。

ジェミニのカットアウト
明るい背景のエッジをクリーンアップ
ノイズの小さな断片を除去する
縦長画像を横長画像に変換
ターゲットの幅に合わせて拡大縮小する
均一なサイズの透明なキャンバスの中央に配置します。

この方法でエクスポートされた画像はよりきれいになり、バッチ使用に適しています。

該当するシナリオ

以下のニーズに適しています。

商品写真をバッチ処理する
下透過PNGの統合出力
メインビジュアルのサイズを統一する
安定した反復可能な処理手順が必要

少数の画像のみを扱う場合、または各画像のレイアウトを個別に調整する必要がある場合には、これは適さない可能性があります。

クイックスタート

最も直接的な実行方法:

`1`	`& ".\.venv\Scripts\python.exe" ".codex\skills\product-cutout-normalize\scripts\run_pipeline.py" "input_dir" "output_dir" --overwrite`

実行前に必須:

GEMINI_API_KEY
google-genai
Pillow

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

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

環境変数を設定します。

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

出力ルール

デフォルトの出力:

透明な背景 PNG
1024x1024 キャンバス
身幅820px
センターボディ
小さなノイズもクリーンアップされます

つまり、これは単なるスクリプトの暗記ではなく、製品イメージを整理するスクリプトのようなものです。

主なパラメータの説明

一般的に使用されるパラメータ:

--model デフォルト gemini-2.5-flash-image
--canvas-size 出力正方形キャンバスサイズ、デフォルト 1024
--target-width 本体の表示幅、デフォルトは 820
--min-component-pixels このピクセル数より小さい透明なフラグメントは削除されます (デフォルトは 500)
--overwrite 出力ファイルがすでに存在する場合は、出力ファイルを直接上書きします

例えば：

`1`	`& ".\.venv\Scripts\python.exe" ".codex\skills\product-cutout-normalize\scripts\run_pipeline.py" ".\input" ".\output" --canvas-size 1280 --target-width 960 --overwrite`

処理の流れ

処理フローは簡単です。

ジェミニのカットアウト
明るい背景のエッジをクリーンアップ
ノイズの小さな断片を除去する
縦長画像を横長画像に変換
ターゲットの幅に合わせて拡大縮小する
均一なサイズの透明なキャンバスの中央に配置します。

通常の切り抜きスクリプトとの違い

通常の暗記スクリプトと比較して、次の問題もさらに処理します。

主な方向性は統一されています
均一なボディサイズ
均一なキャンバスサイズ
小さな破片やノイズのクリーンアップ
結果はマテリアルライブラリに直接入れるのに適しています。

SKILL.md ソースコード

SKILL.md の完全なソースコードは以下に保持されており、内容は変更されていません。

---
name: product-cutout-normalize
description: Run a reusable Gemini product-image pipeline that removes backgrounds, preserves the full subject, rotates tall products to a horizontal orientation, centers them on a 1024x1024 transparent canvas, and normalizes the visible subject width to 820px. Use when the user wants a repeatable cutout-and-normalize workflow for product photos or asks to batch-process product images into standardized square PNG assets.
---

# Product Cutout Normalize

Use this skill when product photos need the same deterministic finishing pipeline:

- Gemini cutout from the original photo
- border cleanup to transparent
- preserve the full subject
- rotate to horizontal when the subject is taller than it is wide
- center on a `1024x1024` transparent canvas
- normalize the visible subject width to `820px`

## Quick Start

Run the bundled script:

```powershell
& ".\.venv\Scripts\python.exe" ".codex\skills\product-cutout-normalize\scripts\run_pipeline.py" "input_dir" "output_dir" --overwrite
```

Required environment:

- `GEMINI_API_KEY`
- `google-genai`
- `Pillow`

## Workflow

1. Confirm the request matches this standard pipeline. If the user asks for a different canvas size, subject width, or layout rule, pass explicit flags instead of changing the script.
2. Run the bundled script on the input directory.
3. If a result looks misaligned, inspect the alpha bounding box and small detached artifacts first; this pipeline already removes tiny alpha components by default.
4. Report the exact input and output directories used, plus any non-default flags.

## Script

Primary entry point:

- `scripts/run_pipeline.py`

Key flags:

- `--model`: Gemini image model, default `gemini-2.5-flash-image`
- `--canvas-size`: output square size, default `1024`
- `--target-width`: visible subject width after normalization, default `820`
- `--min-component-pixels`: remove detached alpha specks smaller than this, default `500`
- `--overwrite`: replace existing outputs in the destination directory

## Repo Integration

If the current project already has [`scripts/nano_banana_cutout.py`](/c:/Work/my_shop/scripts/nano_banana_cutout.py), prefer that repo script when the user wants the same pipeline inside this repository. Use the bundled skill script when the task is cross-project reuse or when you want the workflow to stay self-contained inside the skill.

スクリプト/run_pipeline.py ソースコード

scripts/run_pipeline.py の完全なソースコードは以下に保持されており、内容は変更されていません。

from __future__ import annotations

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

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."
)
DEFAULT_CANVAS_SIZE = 1024
DEFAULT_TARGET_WIDTH = 820
DEFAULT_MIN_COMPONENT_PIXELS = 500
SUPPORTED_EXTENSIONS = {".jpg", ".jpeg", ".png", ".webp"}


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 remove_small_components(image: Image.Image, min_component_pixels: int) -> Image.Image:
    if min_component_pixels <= 0:
        return image

    rgba = image.convert("RGBA")
    alpha = rgba.getchannel("A")
    width, height = rgba.size
    alpha_pixels = alpha.load()
    rgba_pixels = rgba.load()
    visited: set[tuple[int, int]] = set()

    for y in range(height):
        for x in range(width):
            if alpha_pixels[x, y] == 0 or (x, y) in visited:
                continue

            queue: deque[tuple[int, int]] = deque([(x, y)])
            visited.add((x, y))
            component: list[tuple[int, int]] = []

            while queue:
                cx, cy = queue.popleft()
                component.append((cx, cy))
                for nx, ny in ((cx - 1, cy), (cx + 1, cy), (cx, cy - 1), (cx, cy + 1)):
                    if 0 <= nx < width and 0 <= ny < height:
                        if alpha_pixels[nx, ny] == 0 or (nx, ny) in visited:
                            continue
                        visited.add((nx, ny))
                        queue.append((nx, ny))

            if len(component) < min_component_pixels:
                for px, py in component:
                    r, g, b, _ = rgba_pixels[px, py]
                    rgba_pixels[px, py] = (r, g, b, 0)

    return rgba


def normalize_product_image(
    image: Image.Image,
    canvas_size: int,
    target_width: int,
) -> Image.Image:
    rgba = image.convert("RGBA")
    bbox = rgba.getchannel("A").getbbox()
    if bbox is None:
        return Image.new("RGBA", (canvas_size, canvas_size), (0, 0, 0, 0))

    subject = rgba.crop(bbox)
    if subject.height > subject.width:
        subject = subject.rotate(-90, expand=True, resample=Image.Resampling.BICUBIC)
        rotated_bbox = subject.getchannel("A").getbbox()
        if rotated_bbox is not None:
            subject = subject.crop(rotated_bbox)

    scale = target_width / subject.width
    subject = subject.resize(
        (target_width, max(1, int(round(subject.height * scale)))),
        Image.Resampling.LANCZOS,
    )

    canvas = Image.new("RGBA", (canvas_size, canvas_size), (0, 0, 0, 0))
    offset_x = (canvas_size - subject.width) // 2
    offset_y = (canvas_size - subject.height) // 2
    canvas.alpha_composite(subject, (offset_x, offset_y))
    return canvas


def finalize_product_image(
    image: Image.Image,
    canvas_size: int,
    target_width: int,
    min_component_pixels: int,
) -> Image.Image:
    transparent = make_transparent_from_borders(image)
    cleaned = remove_small_components(transparent, min_component_pixels)
    return normalize_product_image(cleaned, canvas_size=canvas_size, target_width=target_width)


def save_first_image_part(
    response,
    dst: Path,
    canvas_size: int,
    target_width: int,
    min_component_pixels: int,
) -> 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)
            finalize_product_image(
                image,
                canvas_size=canvas_size,
                target_width=target_width,
                min_component_pixels=min_component_pixels,
            ).save(dst)
            return

        data = getattr(inline_data, "data", None)
        if data:
            dst.parent.mkdir(parents=True, exist_ok=True)
            with open(dst, "wb") as handle:
                handle.write(data)
            with Image.open(dst) as image:
                processed = finalize_product_image(
                    image,
                    canvas_size=canvas_size,
                    target_width=target_width,
                    min_component_pixels=min_component_pixels,
                )
                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,
    canvas_size: int,
    target_width: int,
    min_component_pixels: int,
) -> 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,
        canvas_size=canvas_size,
        target_width=target_width,
        min_component_pixels=min_component_pixels,
    )


def parse_args() -> argparse.Namespace:
    parser = argparse.ArgumentParser(
        description="Cut out product images with Gemini and normalize them to square transparent PNGs."
    )
    parser.add_argument("input_dir", type=Path)
    parser.add_argument("output_dir", type=Path)
    parser.add_argument("--model", default="gemini-2.5-flash-image")
    parser.add_argument("--canvas-size", type=int, default=DEFAULT_CANVAS_SIZE)
    parser.add_argument("--target-width", type=int, default=DEFAULT_TARGET_WIDTH)
    parser.add_argument("--min-component-pixels", type=int, default=DEFAULT_MIN_COMPONENT_PIXELS)
    parser.add_argument("--overwrite", action="store_true")
    return parser.parse_args()


def main() -> None:
    args = parse_args()
    api_key = os.environ.get("GEMINI_API_KEY")
    if not api_key:
        raise SystemExit("Missing GEMINI_API_KEY environment variable.")
    if not args.input_dir.is_dir():
        raise SystemExit(f"Input directory does not exist: {args.input_dir}")
    if args.canvas_size <= 0:
        raise SystemExit("--canvas-size must be positive.")
    if args.target_width <= 0 or args.target_width > args.canvas_size:
        raise SystemExit("--target-width must be positive and no larger than --canvas-size.")
    if args.min_component_pixels < 0:
        raise SystemExit("--min-component-pixels must be >= 0.")

    args.output_dir.mkdir(parents=True, exist_ok=True)
    client = genai.Client(api_key=api_key)

    for src in sorted(args.input_dir.iterdir()):
        if not src.is_file() or src.suffix.lower() not in SUPPORTED_EXTENSIONS:
            continue
        dst = args.output_dir / f"{src.stem}.png"
        if dst.exists() and not args.overwrite:
            print(f"skip {dst}")
            continue
        process_image(
            src,
            dst,
            client,
            args.model,
            canvas_size=args.canvas_size,
            target_width=args.target_width,
            min_component_pixels=args.min_component_pixels,
        )
        print(dst)


if __name__ == "__main__":
    main()

添付ファイルをダウンロード: product-cutout-normalize.7z

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() を使用してプロンプトの言葉と画像を渡します

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