AIエージェント開発

Gemini Sparkのアーキテクチャを開発者視点で読み解く

Gemini Sparkのアーキテクチャ解剖 — Antigravity基盤・権限モデル・自作の可能性

この記事の結論

Gemini Sparkの常時稼働アーキテクチャを開発者視点で解剖。Antigravityとの関係、権限モデル、公式Interactions APIでの自作可能性まで一次情報で検証する。

結論:Gemini Sparkは「Google Antigravityという同じハーネスの上に立つ、消費者向けにパッケージングされたエージェント」であり、開発者にとって重要なのは製品としてのSparkそのものより、その土台を素で触れる公式の入り口が既に存在するという事実だ。

  • Sparkは専用の公開APIを持たない。ただし同じ「Antigravityエージェント」はGemini APIのInteractions API(プレビュー)経由で誰でも呼び出せる。
  • クラウド常駐(デバイス非依存)を実現しているのは、セッションをローカルプロセスではなく永続サンドボックス環境に紐付ける設計。environment_idで環境そのものを再利用する仕組みが公開されている。
  • 対象読者は、Claude CodeやCLI型エージェントとの設計思想の違いを理解したい開発者・PM。
  • 今日やること:Interactions APIのクイックスタートを1本動かし、environmentbackgroundパラメータの挙動を自分の目で確認する。

「常時稼働のパーソナルエージェント」と聞いて、多くの開発者が真っ先に気になるのはUIやユースケースではなく「セッションはどこで生きているのか」「権限確認はどのタイミングで挟まるのか」という設計の中身だろう。ChromeとGmailを閉じても動き続けるという触れ込みは、裏を返せば「クライアントの生存に依存しないエージェントランタイム」を誰かが常時運用しているということでもある。

2026年7月16日、Googleは「Gemini Spark」の日本語提供を開始した。Google AI Ultra加入者向けのベータ機能で、基盤にはGemini 3.5 FlashとGoogle Antigravityのハーネスが使われている。ここまでは各メディアが報じている外形情報だ。この記事では「何ができるか」「料金はいくらか」には深入りしない。それは既に多くの媒体が書いている。ここで扱うのは、この製品の裏側にある設計思想を、公式ドキュメントで確認できる範囲まで分解し、「では自分たちが似た仕組みを組むなら何が要るか」まで考えることだ。

なお、似た名前の製品として「Meta Muse Spark」があるが、これは別記事で扱ったMetaのエージェント開発者向けツールであり、GoogleのGemini Sparkとは無関係の別製品である。検索結果で混同しやすいので、先に区別しておく。

Gemini Sparkとは何か — 確認できる外形

Google公式ページと国内報道を突き合わせると、確認できる事実は次の通りだ。Google I/O 2026(2026年5月19日)でSundar Pichai氏が発表し、米国でのベータ提供を経て、2026年7月16日に日本語での提供が始まった。対象はGoogle AI Ultraプランの契約者(一部法人ユーザーも含む)。Gmail、カレンダー、ドキュメント、スプレッドシート、スライド、YouTube、Googleマップといった主要Workspaceツールとネイティブに連携し、Canva・OpenTable・Instacartなど外部サービスとの連携も順次拡大中とされている。

製品ページでは権限に関する記述として「常にユーザーの指示下にあり、重要なアクションの前には確認を求めるよう設計されている」「レスポンスを確認し、密接に監督し、必要なら中断する」という趣旨の説明がある。裏を返せば、確認なしで実行される操作の線引きは運用者側の設計に委ねられており、そこがこの種の常駐エージェント全般に共通する設計上の論点になる。

アーキテクチャ解剖:常時稼働をどう実現しているか

「電源を切っても動き続ける」という挙動は、魔法ではなく素直な設計判断の結果だ。3つの観点に分けて見ていく。

実行環境という選択 — 専用VMという設計判断

Sparkはユーザーのデバイス上ではなく、Google Cloud上の専用インスタンスで稼働する。これはローカル実行型のエージェント(後述のClaude Codeなど)との最大の違いで、クライアントの生死とエージェントの生存が完全に切り離されている。この設計の代償はコストとレイテンシで、常時起動しているVM・サンドボックスのリソースを誰かが支払い続ける必要がある。Googleが開発者向けに公開しているAntigravityエージェント(後述)のドキュメントでは、Ubuntu上のLinuxサンドボックスにPython 3.12・Node.js 22があらかじめ用意され、4 CPUコア・16GBメモリという具体的なスペックが明記されている。これはSparkそのものの内部仕様ではないが、同じ系譜の実行環境として参考になる数字だ。

状態管理とセッションの永続化

「デバイスを閉じても続きから動く」ためには、会話履歴だけでなく、ファイルシステムやインストール済みパッケージまで環境ごと保持する必要がある。開発者向けInteractions APIのドキュメントには、この永続化が2つのIDで表現されている。environment_idはサンドボックス環境そのものの再利用(ファイルやパッケージの状態を維持)、previous_interaction_idは会話履歴の継続を担う。呼び出しのたびに新しい使い捨て環境を作るのではなく、環境を「生きたまま」持ち回す設計だ。長時間タスクはbackground: trueを渡すことでサーバー側非同期実行になり、APIは即座にIDを返してポーリングに切り替わる。Sparkの「バックグラウンドで作業を続ける」という挙動は、この非同期実行モデルの消費者向け表現だと考えると理解しやすい。

権限モデルと確認フロー

常時稼働かつ複数サービス横断で動くエージェントの権限設計は、単純な「許可/拒否」では済まない。開発者向けドキュメントでは、ネットワークアクセスは既定で「無制限のアウトバウンド」だが許可リストで絞り込み可能であること、認証情報(シークレット)はサンドボックス内部に一切存在させず、エグレスプロキシ経由で注入する設計であることが明記されている。Spark本体の内部実装がこれと同一かは確認できないが、「重要な操作は確認を挟む」という製品ページの説明と、「シークレットをエージェント実行環境に直置きしない」という開発者向けAPIの設計思想は、方向性として一致している。

Antigravityとの関係 — 消費者向けと開発者向けが同じ土台に立つ

Antigravityという名前は、Claude CodeユーザーであればCLI型の開発ツールとして見覚えがあるかもしれない。Gemini CLI終了とAntigravity CLI移行ガイドで扱った通り、Antigravityは2026年6月にGemini CLIを置き換えたGoogleのエージェント開発プラットフォームだ。今回のSparkは、このAntigravityという基盤の上に、Workspace連携・Gmail経由の依頼受付・常駐VMという消費者向けパッケージを載せたものと理解すると筋が通る。

興味深いのは、Googleが同じ2026年5月19日に、開発者向けにも「Antigravityエージェント」をGemini API経由のマネージドエージェントとして公開している点だ。公式ブログは「Gemini 3.5 Flashをベースに構築された新しいAntigravityエージェントによって強化されている」と説明しており、AntigravityのIDE版・CLI版と「同じハーネス」を使っていると明言している。つまりGoogleは、コンシューマー向け(Spark)と開発者向け(Interactions API経由のAntigravityエージェント)の両方を、同じ技術基盤から同時に切り出して出荷した。Sparkの中身を知りたい開発者にとって、最も近い一次情報は「Spark自体の非公開の内部実装」ではなく、この公開されているAntigravityエージェントの仕様書だ。

ローカル実行型エージェントとの比較

クラウド常駐という設計は万能ではない。Claude Codeのようなローカル実行型のコーディングエージェントと並べると、トレードオフがはっきりする。

観点 Gemini Spark(消費者向け) Antigravityエージェント(Interactions API) Claude Codeなどローカル実行型
実行場所 Google Cloud上の常駐VM 呼び出し時にプロビジョニングされるLinuxサンドボックス ユーザーのローカル端末・セッション内
デバイス非依存性 高い(端末オフでも継続) APIコール単位(呼び出し元は別途必要) 低い(端末・セッションに紐付く)
状態の持ち方 非公開(推定:環境永続化型) environment_idでサンドボックスを再利用 ローカルファイルシステム・会話コンテキスト
権限確認 重要操作の前に確認を求める設計 ネットワークallowlist・シークレットのプロキシ注入 ツール実行ごとに許可ダイアログ/設定ファイルで制御
主な利用者 Google AI Ultra加入者(一般消費者・一部法人) アプリケーション開発者 ソフトウェア開発者
現在のステータス(確認日: 2026-07-28) 日本語ベータ提供中 プレビュー(Interactions API) GA

ここで言いたいのは優劣ではなく、「常時稼働」を選ぶかどうかは、タスクの性質で決めるべき設計判断だということだ。人間の作業と並走してコードを書くならローカル実行の応答性と可視性が有利で、人間が寝ている間や離席中にリサーチや調整を進めたいならクラウド常駐が有利になる。

開発者が今日から使える入り口 — Interactions APIでAntigravityエージェントを呼ぶ

「Gemini Spark用の公開SDK」は現時点で確認できない。だが、同じAntigravityハーネスをそのまま叩ける公式の入り口は既に開いている。以下はGoogle公式ドキュメントに掲載されている呼び出し例をベースにした最小構成だ。

# 動作環境: Python 3.11+, google-genai SDK
# 必要パッケージ: pip install google-genai
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

from google import genai

client = genai.Client()

interaction = client.interactions.create(
    agent="antigravity-preview-05-2026",
    input="Hacker Newsの上位10記事を要約し、PDFとして保存して",
    environment="remote",
)
print(interaction.output_text)

これだけでLinuxサンドボックスがプロビジョニングされ、エージェントループが実行され、結果が返る。Sparkのような「バックグラウンドで動き続ける」挙動に近づけたい場合は、backgroundパラメータと環境の再利用を組み合わせる。

# 長時間タスクを非同期実行し、後からポーリングする例
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。

first = client.interactions.create(
    agent="antigravity-preview-05-2026",
    input="週次の競合リサーチを開始して、途中経過をファイルに残して",
    environment="remote",
    background=True,
)
env_id = first.environment_id

# 同じ環境・会話を維持したまま追いタスクを投げる
follow_up = client.interactions.create(
    agent="antigravity-preview-05-2026",
    input="さっきのリサーチにもとづいてサマリーを1枚にまとめて",
    environment=env_id,
    previous_interaction_id=first.id,
)

料金体系は、環境そのもののコンピュート費用がプレビュー期間中は無課金で、課金対象は基盤モデルのトークン利用量とツール利用分になる。ステータスはあくまで「preview」であり、構造化出力や一部の生成パラメータが非対応など、GA版のAPIと同列には扱えない制約もある点は留意しておきたい。

自前でSpark相当を組むなら何が要るか

Googleの内部実装は公開されていないため、ここから先は一般的な「常時稼働エージェント」を自前で構築する場合に必要な要素の整理であり、Sparkの内部仕様の推測ではない。上記のInteractions APIのような公開APIを土台にする場合でも、最低限次の4つを自分たちで用意する必要がある。

  • スケジューラ/トリガー層:Interactions API自体はリクエスト駆動で、Spark的な「定期的に自律巡回する」挙動は呼び出し側が作る必要がある。Cronやメッセージキュー(Cloud Tasks、Amazon SQS等)で「いつ・何を投げるか」を管理する層が要る。マルチエージェントの設計パターンで整理した通り、オーケストレーション層を薄く保つほど障害時の切り分けがしやすい。
  • 認可・スコープ管理:Gmail送信やカレンダー変更のような「取り返しがつく操作」と「調べるだけの操作」を分け、後者はエージェント単独実行、前者は人間承認を挟むゲートを置く。allowlist方式のネットワーク制御と合わせて、権限は機能単位で最小化する。
  • 状態ストアenvironment_idのような「生きた環境」を延命させるか、都度使い捨てて外部DB(Postgresやオブジェクトストレージ)に成果物だけ永続化するかは設計判断が分かれる。常時稼働時間が長いほど環境延命型はコストが積み上がるため、タスクの継続時間に応じて使い分けるのが現実的だ。
  • 監査ログ:エージェントが「誰の代理で」「何を」「いつ」実行したかを追跡できる構造化ログ(JSON Lines形式など)が必須になる。特にシークレットをプロキシ経由で注入する構成では、注入イベント自体もログに残しておかないと事後調査が不可能になる。

この4点は目新しいものではなく、ジョブキュー・IAM・ステートストア・監査ログという、分散システムの基本コンポーネントそのものだ。Sparkのような製品が「新しい」のは、この4点をGoogleが自社インフラの上でユーザーに意識させずに束ねて出荷した点にあり、要素技術自体はAntigravityエージェントのAPIから透けて見える。

よくある質問

Q. Gemini SparkとAntigravityは同じものですか?

いいえ、別物として区別すべきだ。Antigravityはエージェント実行の基盤(ハーネス)で、Gemini CLIの後継であるAntigravity CLIや、Gemini API経由のAntigravityエージェントもこの基盤の上で動く。Gemini Sparkは、この基盤にWorkspace連携・常駐VM・Gmail経由の依頼受付を組み合わせた、Google AI Ultra向けの消費者製品という位置づけになる。

Q. Gemini Spark専用の開発者向けAPIやSDKはありますか?

2026年7月28日時点で確認できる範囲では、Spark専用の公開APIは存在しない。ただし同じAntigravityハーネスを使う「Antigravityエージェント」は、Gemini APIのInteractions API(プレビュー)経由で開発者が直接呼び出せる。Spark相当の挙動を試したい開発者にとっては、これが最も近い公式の入り口になる。

まとめ:開発者が今週やるべきこと

Gemini Sparkそのものを分解することはできないが、同じ基盤を公式に触る手段はすでに開いている。今週やることとしては、まずInteractions APIのクイックスタートを1本動かしてenvironmentbackgroundパラメータの挙動を体感すること。次に、自分のプロダクトで「常時稼働にする価値があるタスク」と「ローカル実行のままで十分なタスク」を仕分けること。最後に、認可・監査ログの設計は後回しにせず、プレビュー段階の今のうちに自分たちの要件でPoCを組んでおくことをおすすめしたい。GA後に権限モデルが変わることは十分あり得るため、早めに触っておく価値がある。

参考・出典

この記事を読んで、自社プロダクトへの常駐エージェント導入イメージが固まってきた方へ

UravationではAIエージェント導入の研修・コンサルを行っています。


あわせて読みたい:
OpenAI Presence構成解剖|Agents SDK自前実装との違い — 別ベンダーの「常駐エージェント製品 vs 自前実装」を同じ切り口で読み解く記事
【2026年最新】AIエージェントツール完全比較12選|用途・料金・選び方ガイド — 用途別のツール選定を体系的に整理したピラー記事


著者:佐藤傑(さとう・すぐる)
株式会社Uravation代表取締役。X(@SuguruKun_ai)フォロワー10万人超。100社以上の企業向けAI研修・導入支援。著書累計3.1万部突破。

ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。

関連記事: Meta Model API入門|Muse Spark 1.1を叩く実装ガイド

Need help moving from reading to rollout?

この記事を読んで導入イメージが固まってきた方へ

Uravationでは、AIエージェントの要件整理、PoC設計、社内導入、研修まで一気通貫で支援しています。

この記事をシェア

X Facebook LINE

※ 本記事の情報は2026年7月時点のものです。サービスの料金・仕様は変更される可能性があります。最新情報は各サービスの公式サイトをご確認ください。

関連記事