一言で言うと
AI エージェントが「本当に役立つ」ためには、個人データへの深いアクセスが前提条件として必要です。Google はそのデータを Gmail・カレンダー・写真・検索履歴という形で長年蓄積しており、Gemini Spark はその資産を活用して他社が追いつけない水準の文脈理解を実現しています。著者が「最も印象的で最も恐ろしい AI 体験」と表現した理由は、その便利さと「自分のデータが採掘されている」感覚が構造的に切り離せないという点にあります。
先に理解しておくこと
「Gemini Spark」は Google が発表した常時稼働型 AI エージェントです。ここでいう「エージェント」とは、ユーザーが都度指示しなくても外部アプリを操作・参照できるソフトウェアを指します。Spark は現在、Google の「AI Ultra」プラン（月額 99 ドル）向けに段階的に提供が始まっています。
Spark の「個人文脈理解」は新たなデータ収集ではなく、Google が「Personal Intelligence（個人インテリジェンス）」機能として整備してきた既存データの統合利用です。Gmail・Google カレンダー・Google フォト・Google 検索履歴はすでに Google のサーバーに保存されています。Spark はそれを「旅行計画を立てて」のような具体的な依頼を起点に参照・組み合わせて出力します。
「AI が知っていた」という表現を記事は使いますが、技術的には「Google のサービス群に保存されていたデータが参照された」という方が正確です。この違いが、後述の「不気味さ」の本質に関係します。
記事では Spark を、OpenClaw（個人 PC 上で動く常時稼働型のオープンソース AI エージェント。開発者 Peter Steinberger が始めたプロジェクトで、OpenAI の公式製品ではない）に 「よりよいインターネット接続が付いたようなもの」 と例えています。OpenClaw が外部アプリや Web を操作する「エージェントの型」を示したのに対し、Spark は Gmail・カレンダー・写真・検索履歴など Google がすでに持っている個人データ に強く依存できる——この差が、今回の旅行プランの精度を生んだ、という位置づけです。
何が起きているのか
著者は Spark に「ペンシルバニア州ハーシーで 2026 年 7 月 18 日の週末を家族で過ごす旅行計画を立てて」と依頼しました。伝えた情報は「妻・子供 2 人・犬と出かけること」のみです。
数分後、Spark が返してきた旅行プランには以下が含まれていました。
著者が伝えた情報にない内容:
- 自宅住所からの道順 — 住所はこのやり取りで著者が伝えていません。Google が持つ情報から参照されたと著者は推測しています。
- 子供の名前と年齢 —「Lewis は 1 歳未満なので入園無料、Arthur（3 歳）はチケットが必要」と記載。名前・年齢は著者が伝えていません。
- 犬の名前「Frida」 — 獣医（vet）からのメールを参照したと著者は推測しています。
- 妻のネギ類嫌い — 「onions や scallions を避けるよう考慮した」という記述がプランに含まれていました。
- 土曜夜のコンサート情報 — Thomas Rhett と Niall Horan のコンサートが記載され、「駐車場はチケット代に含まれている」と付記。Ticketmaster の予約確認メールを参照したと推測されます。
- Lewis の午後 1 時 30 分の昼寝時間 — 著者は「推測か、実際に知っていたのか不明だが正確だった」と記録しています。
その後、著者が「両親も一緒に来るので子供の世話をしてくれる」と追加すると、Spark は両親の名前を呼び、宿泊先の提案をホテルから Airbnb に切り替えました。妻の名前を添えてドキュメントを共有する依頼にも対応しましたが、下書きの文面が「夫婦ではなくビジネスパートナー同士のような口調」になっていた、と著者は書いています。
失敗したのは Airbnb の予約実行のみです。「セキュリティ・認証ポリシーによりログイン・決済・予約を直接行うことができない」と Spark が返し、代わりに条件に合う候補物件をリストアップしました。
AI業界の文脈では
AI エージェントの「文脈理解の深さ」は、モデルの性能ではなく、参照できるデータの量と構造化の深さによるところが大きいです。Spark が詳細な旅行計画を生成できた理由は、Google が長年にわたって個人データを統合的に蓄積・構造化してきたからです。
OpenAI・Anthropic が個人データをどう獲得するかを模索している段階に対し、Google はすでにその資産を持っており、エージェント競争における優位の源泉は技術ではなくデータにあります。著者の表現を借りると、Spark が強いのは「Google がすでに私のことを知り尽くしているから」です。
著者の要約（記事より）：昔は、Facebook や Instagram、Google 検索のように利用料が無料のサービスでは、「あなたの行動データが広告主に売られる商品になる」と言われました。Gemini Spark の時代はその一歩先で、月額99ドルなどお金を払いながらも、Gmail や写真・検索履歴が素材として使われ、旅行プランのように自分向けの成果物として返ってくる——有料でも、自分のデータが原料のまま、という違和感がある、と書いています。
私の見立て
今回の体験で言えるのは、「すごい便利」と「なぜ知っているの？」がセットで来るということです。著者がゾッとしたのは、Google が新しく秘密を盗んだからではありません。犬の名前や子どもの年齢、妻の嫌いな食材——これらは、本人が Gmail や写真・検索などにすでに預けていた情報です。それが旅行プランづくりという別の場面で、いつの間にかつながって使われていた、というギャップが不快感の正体です。「渡した覚えはあるが、こんな形で使われるとは思わなかった」——この感覚は、AI エージェントが普及すればするほど、日常になります。
→ 何が変わるか: Gmail や写真・検索履歴を横断して動く Gemini Spark のようなサービスが、実用段階で出てきたことです。モデル単体の賢さより、「どのデータに触れるか」が体験の差を決めます。医療でも同型の論点が出ます——電子カルテ・検査結果・問診履歴へのアクセスを広げればエージェントは便利になる一方、「なぜそれを知っているのか」の説明が求められます。Spark は、その設計判断を先に体験できる縮図です。
→ 何をすべきか: AI エージェントを業務に組み込む際、「どのデータソースへのアクセスを許可するか」を最初に明示的に決める設計が必要です。デフォルトで全データを参照させる設計は能力を最大化しますが、説明責任のコストを後から大きくします。Spark の体験から得られる実務的な教訓は、エージェントの「賢さ」の設計よりも「アクセス境界の設計」を先行させることの重要性です。