最近、Google Workspace Studio（AIを活用したワークフロー自動化ツール）を試しています。今回は、特定のニュースサイトから自分好みのトピックだけを抽出しようとして、AIの「Webページの見え方」と格闘した記録を残しておきます。
以前、Geminiアプリ単体の「予約アクション（スケジュール実行）」を使って毎日のニュース収集を試みたことがありました。しかし、結局アプリを開いて確認しに行くのが手間で定着しませんでした。「チャットを読めばわかる」という状態だけでは、受動的な情報収集の仕組みとしては弱かったです。
そこで試したのがGoogle Workspace Studioでした。これなら実行結果をGmailで送信するといったフローが組めるため、プッシュ型の情報収集ができるのではないかと期待しました。
やりたかったこと
私がたまにチェックしている某ニュースサイトがあります。そこでは毎日、その日のニュースをまとめた「ヘッドライン記事」がアップされるのですが、記事の構成が以下のようになっています。
- サブカル
- IT・ガジェット（ここだけ読みたい！）
- サイエンス
- 社会・政治
- ...etc
情報量が多く、直接見に行くのが面倒です。私は「IT・ガジェット」のセクションにあるリンクと、関連するSNSの埋め込みコメントだけをサクッと読みたいと思ってました。
そこで、Workspace Studioを使って以下のようなフローを考えました。
- 毎日決まった時間に起動
- Geminiがその日の記事URLを生成してアクセス
- ITカテゴリだけを抽出
- 結果を自分宛てにメールで送信
しかし、「3. ITカテゴリだけを抽出」の部分に沼がありました。
試行錯誤の連続（HTMLを読んでくれない）
人間が見れば「見出し」や「区切り線」で明確に分かれているセクションですが、Geminiのブラウジング機能（グラウンディング）を通すと、どうやらWebページがベタ書きのテキストの塊として認識されているようでした。
「h2タグの中身を取得して」とか「divクラスが...」といったWebスクレイピング的な指示は通用せず、あくまで自然言語によるテキスト処理として指示する必要がありました。
失敗1：ざっくり要約してしまう（リンク消失）
最初は「"IT・ガジェット"に関する内容を抽出して」とシンプルに頼んでみました。 するとGeminiは、気を利かせて記事の内容を「要約」してくれました。
- 結果: 文章は読みやすいが、元の記事へのリンクが消滅。気になった記事をクリックして深掘りできない。
これではニュースキュレーションとして機能しません。
失敗2：URLを「創作」し始める（ハルシネーション）
次に「記事のURLとリンクも含めて抽出して」と指示しました。すると今度は、存在しないURLをもっともらしく生成し始めました。
例えば、https://example.com/news/20260216-example... のような、いかにもありそうなURLが出力されましたが、クリックすると404エラー。Webページからリンクを「取得」するのではなく、文脈から「ありそうなURL文字列を予測生成」してしまいました。
失敗3：必要な情報まで削ぎ落とす
「正確に引用して」「余計なことはしないで」と制約を強めると、今度は記事のコメント（長文）をすべてカットしたのは良いものの、そのコメントの中に含まれている外部サイトへの参照リンクまで無視してしまいました。
「HTMLのaタグをすべて拾って」と指示できれば楽なのですが、テキストの意味だけを理解しようとするあまり、「これは不要な説明文だ」と判断して、リンクごと切り捨ててしまうのです。この「さじ加減」が非常に難しい問題でした。
回避策：プロンプトを「テキスト処理プログラム」のように書く
HTML構造での指定を諦め、目に見える文字パターンを頼りに抽出する泥臭い作戦に変更しました。自然言語での会話のように指示するのではなく、文字列処理の手順書（アルゴリズム）のようにプロンプトを記述する方法です。
成功したプロンプトの構成要素
実行手順の明記
「URLを推測するな」ではなく、「日付からこのルールでURLを生成しろ」→「そのURLにブラウジング機能でアクセスしろ」と、実行の順序を厳密に定義しました。
抽出範囲の物理的な指定（ここが重要）
「ITカテゴリ」という曖昧な言葉ではなく、**「『◆IT・ガジェット』という文字列から、次の『◆』が出る直前まで」**と、まるで正規表現のようにテキストベースで範囲を指定しました。これにより、AIの解釈の揺れを防ぎます。
除外と取得の条件分岐
- 「コメントの長文解説（地の文）は除外する」
- 「ただし、文中に外部ソース（URL）がある場合は、タイトルとセットで抽出する」
- 「URL」という文字列の存在をトリガーにすることで、リンクの取りこぼしを防ぎました。
出力フォーマットの固定
タイトル、URL、SNS引用の形式を厳密にテンプレート化し、出力が崩れないように制御しました。
実際のプロンプト（抜粋・一般化）
実際に使用したプロンプトの構造は以下のようになります。
以下の【実行手順】と【抽出ルール】に従って、[サイト名]のヘッドラインから情報を抽出してください。
# 実行手順
1. 【対象日付】から、記事URLを生成してください。（規則：https://.../news/yyyymmdd-headline/）
2. ブラウジング機能を使用して該当URLにアクセスし、ページ内容を読み込んでください。
3. 以下のルールに従ってテキストを抽出し、フォーマット通りに出力してください。
# 抽出ルール
1. 抽出範囲: 「◆IT・ガジェット」の大見出しから開始し、次の「◆」の直前まで。
2. 記事の扱い: 抽出範囲内にある記事は「タイトル - メディア名」「URL」を出力。
3. 長文解説の扱い（重要）: 編集者による解説テキスト自体は除外。ただし、解説文の中に紹介されている外部ソースがある場合は、それも抽出対象とする。
4. SNS埋め込み: 「本文」「URL」「投稿者・日付」の形を維持。
# 対象日付
{予約アクションの実行日付}
結論：完璧ではないが、プロンプトの作り込みで少しマシになった
ここまでプロンプトを厳密に定義した結果、抽出の精度は以前より格段にマシになりました。しかし、これを「成功」と呼ぶにはほど遠いのが実情です。
当初の目的だったGoogle Workspace Studioで「メール通知」するほどの信頼性は得られず、結局、この自動化フローを組むことは断念しました。
最終的に行き着いたのは、最初の出発点であったGeminiアプリの予約アクションに戻る、という選択です。ただ、以前との違いは、今回作り込んだ「泥臭いプロンプト」のおかげで、ただニュースが一覧化されるよりも、少しだけ精度の高い情報が得られるようになった点です。
完全な解決には至りませんでしたが、今回の試みは「AIにWebページを正しく、かつ自分の意図通りに解釈させることの難しさ」と、そのためのプロンプトエンジニアリングの重要性を再認識する良い機会となりました。この「テキストパターンで物理的に指定する」というテクニックは、他のWebサイトの要約や情報収集タスクでも応用できる知見だったと感じています。