7:00に頼んで、7:00 / 7:25 / 7:34に来た。Gemini Sparkに毎朝の巡回を3日間任せた記録

毎朝7時に、AIエージェント関連の新着情報を5件拾ってGoogleドキュメントに書き足す。それだけの仕事を、Gemini Sparkに3日間任せた。

Sparkは、Geminiの中で常駐して定期タスクをこなす機能だ。私がこれを試したかった理由ははっきりしていて、自分ではもう同じ仕組みをClaude Codeのスケジュール実行で持っているからだ。持っているものと同じ仕事を別の基盤にやらせれば、差がそのまま見える。

結論を先に書く。3日とも動いた。実行された時刻に、私のPCはどの日も起動していない。ただし7:00ちょうどに来たのは初日だけで、2日目は7:25、3日目は7:34だった。そして出てきたテキストは、形式は指示どおりなのに、中身の具体が少しずつ削れていた。

うまくいったかどうかで言えば、うまくいっている。それでもこの記事で書きたいのは、任せた結果として返ってきたものが「指定したもの」とは微妙に違った、という部分のほうだ。

登録は2分で終わった

やったことは2つだけだった。

1. Googleドキュメントで「AI巡回メモ」という空のファイルを1つ作る(出力先を固定するため)
2. gemini.google.com でSparkに切り替えて、次の文面を貼って送信する

毎朝7時に、AIエージェントと業務自動化ツールの新着情報をWebで調べて、
Googleドキュメント「AI巡回メモ」に当日分を追記してください。

書き方のルール:
- 1件につき「見出し / 出典URL / 公開日 / 3行以内の要約」の形式で書く
- 出典URLか公開日が確認できないものは載せない
- 多くても5件まで。該当がない日は「該当なし」とだけ書く
- 既存の記述は書き換えず、ドキュメントの末尾に追記するだけにする
- メールの送信や、私以外への共有はしない

ドキュメントの作成に1分、タスク登録に1分。合計2分で、つまずいた箇所はなかった。Skillのような定義ファイルは作っていない。プロンプトの直書きだけだ。Gmail連携は最初から使わない設計にしたが、そもそも要求もされなかった。

想定と違ったのはこの後だ。Sparkは、私が貼った文面をそのままタスクとして保存しなかった。 登録後の画面はこうなっていた。

• タスク名: 「AIと自動化ツールの最新情報収集」(私は指定していない。Sparkが付けた)
• 実行するタイミング: 毎日 7:00 頃
• 実行する内容: 目的と、手順3ステップ(検索する → 最大5件を抽出して整形する → 既存内容を消去・変更せず末尾に追記する)への分解

出力先のGoogleドキュメントは、名前ではなくドキュメントIDで解決されていた。以後ファイル名を変えても壊れない形だ。細かいが、ここは丁寧だと思った。画面には「ベータ版」の表記が出ている。

なお、この記事にはドキュメントIDは載せない。個人のファイル識別子なので伏せる。

3日とも動いた。時刻は 7:00 / 7:25 / 7:34

3日分の実行時刻はこうだった。数字はSpark側の実行履歴から取っている(ドキュメントの更新履歴ではない)。

3回とも遅れる方向にずれた。ただし3回の観測で「遅れが広がっていく」と言うつもりはない。サンプルが少なすぎるし、原因も調べていない。サーバー側の混み具合なのか、実行キューの順番なのか、確かめる手段が私の側にない。

もう1つ、Sparkの名誉のために書いておく。登録直後の画面表示は最初から「毎日 7:00 頃」だった。厳密な時刻は約束されていない。つまりこれは不具合ではなく、期待値の話だ。「7時に」と書いた私が、7:00ちょうどを想定していただけである。

そのうえで、この34分をどう見るかは用途によって割れる。私が任せたのは自分で読むだけのメモなので、朝のうちに溜まっていれば足りる。定刻に人が待っている仕事なら、この基盤は選べない。

完了の通知は、3日とも届いていた。ただし届き先は携帯のGeminiアプリで、8月13日の時点で私はこれに気づいておらず、自分の検証メモには「通知なし」と書いていた。PCの画面の側だけを見ていたからだ。

PCが落ちている時間に処理が走り、終わったことは携帯に届く。実行がこちらのマシンから離れると、完了の知らせ方も変わる。

追記は壊さなかった

初日の時点では判定できなかった項目が1つあった。「既存の記述を書き換えず末尾に追記する」というルールだ。初日はドキュメントが空だったので、壊しようがない。

2日目と3日目の結果を見て、これは守られたと言える。

• 初日に書かれた5件が、そのまま残っていた
• その下に「2026年8月14日」「2026年8月15日」という日付見出しを自分で作って追加していた
• 通し番号が1〜15で連続していた。日をまたいでも1に戻していない
• 件数は3日とも5件ちょうど(上限どおり)
• 見出し / 出典URL / 公開日 / 3行以内の要約という形式は、全15件で崩れていない
• メール送信や共有といった指示外の動作は、3日ともなし

ここは満点だと思う。「追記のみ」「外部に出さない」という縛りは、自分の道具に対して私がいつもかけているものと同じものだが、それが初回から3日間そのまま通った。

拾ってきた領域が、頼んだつもりのものとずれた

初日の5件を見て、まず引っかかったのは中身の正しさではなく、選ばれた領域のほうだった。

5件のうち3件が、企業のプレスリリースだった。自治体DXへの参画、大企業の社内導入体制の発表、といった法人の導入事例だ。私が読みたかったのは、副業でコードを書く人間がその日から触れるもの——新しいツール、APIの仕様変更、料金改定——で、それに当たるのは5件中2件しかなかった。

これはSparkのせいではない。私が書いた「AIエージェントと業務自動化ツールの新着情報」という指示が広すぎた。この書き方なら法人の導入事例は完全に射程内で、むしろ真面目に拾ってきた結果だ。

指示を絞り直す実験は、この記事を出した後にやる。プロンプトを直すのか、定義ファイルとして持たせるのか、その選択自体が次に書くことになると思っている。

リンクは全部本物だった。削れていたのは要約のほう

初日の5件について原文を当たった。結果を先に書くと、5件中4件を照合して、4件すべてで何かしらの劣化があった。残る1件(国内メーカーのプレスリリース)は、ページが実在することをブラウザで確認したものの、こちらの取得環境から本文を読めず原文との照合はできていない。以下の表は4件についてのものだ。

でっち上げはゼロだった。URLは5件とも実在し、存在しない記事を作った形跡はない。壊れているのは要約の精度のほうで、しかも壊れ方の向きが揃っている。

具体が抽象に置き換わっている。 数値、条件、固有の言い回しが落ちて、一般的な表現になる。読み物としてはむしろ滑らかになっているのが厄介なところだ。

そして私の運用で言えば、これは看過できない。出所が自社ベンチマークだという留保を落とした「60%削減」をそのまま引用すれば、効果を断定したことになる。1日ずれた公開日をそのまま書けば、単に誤記になる。出典URLと公開日がきちんと並んでいる出力ほど、原文を開き直す気が失せる。 だが劣化しているのはURLではなく要約の中身なので、リンクが正しいことは中身が正しいことを何も保証していない。

2日目・3日目に拾われた10件については、原文との照合をしていない。したがってこの記事では、その10件の中身には触れない。件数と形式が守られていたか、という観察にだけ使っている。

「リンクが壊れた」と早合点した

上の裏取りの前に、私は一度間違えている。

最初にドキュメントの中身をチャット欄に貼り付けて眺めたとき、URLの直前に見慣れない記号が入り込んで 公開日 と連結して見えた。リンクが壊れている、と判断した。

壊れていたのは私の見方のほうだった。ドキュメントをPDFに書き出してリンクアノテーションのURIを直接読んだところ、5件とも余計な文字のないクリーンなURLだった。あの記号は、Googleドキュメントからチャット欄へリッチテキストをコピーした際の変換で生じたものだ。Sparkが書いたものではない。

教訓は単純だ。AIの出力を評価するときは、コピペを経由した見た目で判断してはいけない。 出力先の実体を見に行く必要がある。この寄り道は完全に自分の失敗だが、同じ形で誤判定する人はいると思うので残しておく。

指定した具体が、近い何かに置き換わる

3日間で起きたことを並べると、形が似ている。

• 7:00と指定した実行が、7:34に来た
• 「約15分で準備」という原文の数値が、「自動化成果」という言葉に置き換わった
• 「個人が触れるツールの新着」のつもりで書いた指示が、法人の導入事例を連れてきた

技術的な原因は3つともまったく別だろう。実行時刻はスケジューラの都合、要約は言語モデルの要約の癖、領域のずれは私の指示の粗さだ。同じ理由で起きていると書くつもりはない。

それでも、使う側に見えている症状は同じだ。指定した具体が、近いけれど違う何かになって返ってくる。 そして3つとも、パッと見では気づけない。7:34に届いたメモは、7:00に届いたメモと同じ顔をしている。

任せる仕組みを組むときに構えるべきなのは「動かないかもしれない」ではなく、こちらだと思った。動かなければすぐ分かる。近いものが返ってくる場合は、こちらが確認しない限り気づかない。

自前のスケジュール実行と何を交換したのか

私が持っているもう1つの仕組み——Claude Codeのスケジュール実行——と比べる。

自前の側は、時刻に関しては正確だ。その代わり、マシンが起きていることが前提になる。私はこの前提を承知のうえで、閉じていた場合は次に起動したときに走る形で運用を組んでいた。裏を返せば、PCを開かない日は仕事が発生しない。

Sparkはその前提を消した。3日とも、実行された時刻に私のPCは動いていない。それでもメモは積み上がり、終わったことは携帯に通知が来る。クラウド側で完結するとはそういうことだ。

その代わりに手放したのが、時刻の厳密さだ。

どちらが上という話ではない。朝の定刻に確実に手元に置きたいものは自前で、開いていない日にも溜まっていてほしいものはSparkで、という分け方が実測に合っている。私の巡回メモは後者だった。

同じことをする人へ

• 登録は私の環境では2分で終わった。まず出力先のドキュメントを空で作っておくと、SparkがそれをドキュメントIDで掴んでくれるので、後からファイル名を変えても壊れない
• 時刻は「頃」だと思って組む。私の3日間は0分・25分・34分の遅れだった。始業前に必ず要る仕事は載せないほうがいい
• 「追記のみ」「外部に送らない」という縛りは、3日間そのまま守られた。ここは信用してよさそうだ(私が確認したのは3日分である、という但し書き付きで)
• 拾ってくる領域は、指示の広さがそのまま出る。「AIエージェントの新着情報」では法人の導入事例まで入ってくる。読みたい対象は最初から絞って書いたほうがいい
• 出力をそのまま引用しない。 URLと公開日が付いていても、要約の中身は原文から削れている。私の実測では、照合できた4件が4件とも削れていた。数字と日付を引くなら原文を開く
• AIの出力を評価するときは、コピペした画面ではなく出力先の実体を見る。私はこれで一度、壊れていないリンクを壊れていると判定した

この記事は、運営者自身の実践記録に基づいています。