はじめに
Gemini Sparkのベータ版が公開されてしばらくして、試用を兼ねて動作を確かめられる題材を探していました。そこで選んだのが、個人用のニュース収集です。当初、集めたニュースのメール送信は手動で行っていました。
その後、久しぶりに動作を確かめようとしたところ、メニューにSparkが見当たらなくなっていました。確認すると、名称が「タスク」に変わっていました。
改めてニュースの自動収集を試しましたが、その時は期待どおりに動かせませんでした。そこでGeminiに相談し、収集したニュースをスプレッドシートへ記録して、Google Apps Script（GAS）でメールを送るところまで自動でつなぐ仕組みを作りました。
情報収集だけでなく、連携するコードや構成までまとめて相談できるところが、Geminiの良い点だと感じています。
一方、振り返ると、私の設計や依頼内容も曖昧でした。できあがったものを見直すと、コードや仕組み、テストに不足が残っていました。
そこでChatGPTのdotsに、設計やコードのレビューと不足している部分の補完を依頼しました。Geminiで作ったものを確かめ、実際に動かすところまで進めるためです。
今回は、この進め方を個人用のニュース配信で試しました。本番への反映を承認して就寝し、翌朝には自分の受信箱へメールが届きました。
目指したニュース配信の流れ
目指した流れは、Geminiの定期タスクで作られたGmail下書きをGASで読み取り、スプレッドシートへ記録してメールを送ることです。
Google公式では、名称変更後も既存のタスクとスケジュールは残ると説明されています。Google公式の説明
dotsと不足している処理やテストを見直す
dotsには、設計やコードをレビューし、不足している処理やテストを補ってほしいと依頼しました。Geminiとの修正のやり取りも任せました。
依頼を受けたdotsは、クラウド上のブラウザでGeminiを開き、「スケジュール」から対象を探しました。Geminiへ直接修正を依頼し、返ってきたコードをChatGPT側でもテストしました。問題が見つかれば、失敗する入力と期待する結果を付けて差し戻しました。
私はスマホから指示と確認を行い、ブラウザ操作やテストはクラウド側で進めました。
見直しは一度で終わりませんでした。「最終版」「本番用」と説明されたコードも、実際の入力で確かめると、修正が必要な箇所が残っていました。
「項目がある」と「中身がある」は違った
例えば、ニュースの要約を取り出す処理です。途中の版では、「事象」「技術的影響」「対策」という項目名があれば、その後ろが空でも要約として受け入れていました。次は、問題を説明するために短くした架空のテスト例です。
入力
- 事象:
- 技術的影響:
- 対策:
修正前：3項目があるので受け入れる
修正後：本文が空のため、エラーにして止める
見出しがそろっていても、ニュースの内容はありません。この入力が受け入れられてしまうことを確認し、各項目に本文があるかも検査するよう修正を求めました。修正版が同じ入力を拒否することまで確かめました。
dotsは、どの入力で何が起きたかをGeminiへ返し、同じ条件で再テストしました。「修正済み」という回答だけで判断せず、前に失敗した条件で結果が変わったかを確認しました。
さらに、日付の異なる実際の下書きも使いました。それぞれに含まれる4記事について、各記事の8列分の値を照合しました。Node.jsでの試験に加え、本番と切り離したGASでも固定データによる11項目の試験を通しています。この段階では、実際のメール送信やシートへの書き込みはしていません。
就寝前に、個人用の運用へ反映することを決めた
検証を進めるうちに、私は眠くなってきました。
眠くなったので、①②を任せてよいか？
依頼したのは、翌朝のメール配信とスプレッドシートの確認、それから今回の記録を記事にまとめることです。一旦本番へ反映し、これ以上の改良を重ねるより、動かしながら調整する方が合理的だと判断しました。
ただし、本番に入れたのはGeminiの候補コード全体ではありません。検証した本文解析と日次データの変換処理を既存コードへ組み込み、宛先制限、週次の処理条件、送信済みの記録は維持しました。
本番へ保存したのは、私の承認を受けたdotsです。統合版をローカルでテストし、保存後にコードを読み直して、保存した版と一致することを確認しました。Geminiのコード生成と、GASへの本番保存は別の作業でした。
既存の定期実行設定は変えず、手動で本番処理を実行して送信することもせず、翌朝の実行を待ちました。
翌朝、メールが届いた
翌朝には、日付の異なる2回分の日次メールについて、送信済みの記録と自分の受信箱への到着を確認できました。各メールには4記事があり、確認した検索では各版1通でした。スプレッドシートは私自身でも確認し、dotsへ「スプシ確認済」と伝えました。
今回確認できた範囲
これは個人利用での検証です。他の宛先での受信、ニュース内容の真偽、dotsによるシート全8列・重複の直接照合、GAS実行ログの確認まではしていません。私自身のシート確認についても、詳細な検査項目までは記録していません。人が承認したことや、今回メールが届いたことを、今後の安全性・正確性の保証にはしません。
任せたあとも、自分で判断するために
Geminiで収集から配信までの仕組みを形にできるのは便利でした。ただ、私の依頼にも曖昧なところがあり、dotsとコードやテストを見直しながら不足を補いました。
私が選んだのは、さらに修正を重ねるより、個人用の仕組みとして一度動かし、運用しながら調整することでした。既存の制限を残した最小限の変更で、翌朝の配信結果を確かめる段階へ進みました。
人もAIも間違うことがあります。任せたあとも、何が動き、どこに影響し、どう結果を確かめるのかは、自分でも分かるようにしておきたいです。
分からないところはAIと一緒に整理し、使い始めるか、もう少し直すかを判断できるようにする。それが、今回の経験から次に生かしたい点です。