こんにちは、GMOメイクショップ SREグループの金井です。 ECシステムの開発・保守を担当しています。
業務や技術の情報収集において、 本当に時間を奪われているのは「記事を読むこと」ではなく、 読むべきかどうかを判断する作業だと感じる場面が増えてきました。
本記事では、 Google アラートで集まったニュースをそのまま読むのではなく、
- 読むか迷わない
- 今の業務に関係あるかを即判断できる
- 判断に必要な文脈が揃った状態で Slack に届く
「判断が一瞬で終わる状態」を作るために、 GAS・LLM・Slack を組み合わせて改善した取り組みを紹介します。
記事のサマリー
本記事で扱うのは、 ニュース収集の効率化そのものではありません。
Google アラートで集まる大量のニュースに対し、
- 読むかどうかで迷わず
- 判断に必要な文脈を考える必要もなく
- Slack を見るだけで意思決定できる
「判断が終わった状態の情報」を自動生成する仕組みを、 実運用ベースで解説します。
設計編（Part1）では、 なぜこの構成にしたのか、どこで判断コストを削っているのかを中心に、 実装編（Part2）では、 実際に動かしているコードと処理フローを紹介します。
Part1 設計編
背景と直面していた課題
技術ニュースや業界動向の情報量は年々増え続けています。 特に以下の領域では、情報量が人間の処理能力を簡単に超えます。
私自身、Google アラートを使って絞り込んだ情報収集をしていましたが、次第に次のような状態に陥っていました。
- 1日に届く記事数：約50件
- 実際に読む価値があるのはその一部
- しかし「読むべきか判断する作業」に時間を取られる
問題の本質は、 記事を読むことではなく、 読むに値するかを判断するコストだと考えました。
本記事のゴール
この記事のゴールは、 「ニュースを読む仕組み」を作ることではありません。
ニュースに対する判断を、一瞬で終わらせる状態を作ることです。
Google アラートで集まった大量のニュースに対し、
- 読むかどうか迷わない
- 業務への関係性を即判断できる
- 判断材料が揃った状態で Slack に届く
この状態を、 GAS・LLM・Slack を使って自分の環境で再現できることを目指します。
想定読者と前提スキル
本記事は、以下のようなエンジニアを想定しています。
- Google Apps Script で API を叩いたことがある、または調べながら実装できる
- HTTP / JSON の基礎知識がある
- Slack アプリの作成経験がある、またはこれから触りたい
- LLM API（OpenAI / Gemini）に抵抗がない
完全な初心者向けではありませんが、 高度な機械学習やインフラ知識は不要です。
要件の整理
機能要件
非機能要件
- 個人利用でも破綻しないコスト
- スプレッドシートによるログ永続化
- Slack アプリの権限を最小限に抑える
Google アラートの位置づけ
なお、本記事の主題は Google アラートの設定方法や精度向上ではありません。
Google アラートは、 候補となる情報を集めるための前処理装置です。
本記事で扱うのは、 その後に必ず発生する 人間の判断作業をどこまでシステム側で肩代わりできるか という設計と実装です。
検討した選択肢とトレードオフ
本システムでは、 AWS 構成（Lambda 中心）と GAS の2案を検討しました。
AWS 構成は拡張性が高く技術的にも妥当ですが、
- IAM や権限設計の確認作業
- 課金状況を継続的に意識する必要性
- 小規模用途に対する準備コスト
といった 作業負荷 が気になりました。
今回の用途では、
という条件から、 作業コストが最も低い GAS 構成を採用しています。
LLM の役割分担
LLM は、処理単位ごとに役割を明確に分けています。 これは、分析精度だけでなく、 トークン消費量を制御しやすくすることも目的のひとつです。
| 項目 | gpt-4o | Gemini |
|---|---|---|
| 処理単位 | 単一記事 | 複数記事 |
| 主な役割 | 要点抽出・重要度判定・三行広告生成 | 傾向分析・パターン抽出 |
| 入力 | 記事本文 | 同期間の複数記事 |
| 出力 | 判断用短文 | 全体傾向レポート |
このように役割を分離した結果、 本構成における LLM API の利用量は、 日次運用ベースで月あたりおおよそ 3ドル前後に収まっています。
- gpt-4o：単一記事の要点抽出・重要度判定
- Gemini：日次・半月単位のまとめ分析
不要にトークンを消費しない設計としているため、 個人利用でも無理なく継続できるコスト感を維持できています。
この金額は、 記事数やプロンプト内容によって変動するものの、 日次バッチ前提の用途では十分に制御可能な範囲です。
三行広告で学習できたパターンとその役割
三行広告の表現パターンは、 人手で分類ルールを設計したものではありません。
実運用の中で、 AI に三行広告の生成を継続的に任せた結果として、 「判断しやすい書かれ方」が自然に収束していったものです。
運用初期には他にも複数の表現パターンが観測されましたが、 実装上は、
- 読む／読まないの判断に直結する
- Slack 上で一瞬で意味が取れる
という観点から、 意思決定に直接影響するものだけを残し、 最終的に以下の5パターンに集約しました。
| パターン名 | 概要 | 主な特徴 | 意思決定上の役割 |
|---|---|---|---|
| トレンド訴求型 | 業界全体の流れや変化の兆しを伝える | 傾向・文脈重視 「◯◯が増えている」「注目が集まっている」など |
業界の前提認識を揃え、読むべき背景を理解する |
| 機能紹介型 | 新機能・アップデート・仕様変更を伝える | 機能名や変更点が明確 事実ベース |
自分の業務に影響があるかを即判断する |
| 課題解決型 | 現場の課題と解決策を提示する | 読者の悩み前提 実務に直結しやすい |
「今すぐ読むべき記事」を見極める |
| 新サービス告知型 | 新しく登場したサービスや提供開始情報 | イベント性が高い 将来性への言及 |
中長期的な選択肢として記憶に残す |
| ベネフィット訴求型 | 導入・活用によって得られる効果を伝える | 成果・改善点を強調 読者視点 |
技術詳細より成果重視で判断する |
これらの分類は、 「どう整理したいか」という設計者視点ではなく、
「どう書かれていると、人は即座に判断できるか」 という観点を AI が学習した結果として現れたものです。
三行広告は要約ではなく、 判断を高速化するための表現形式であり、 このパターンに分類することによって、
- 読む前に立ち止まる
- 内容を頭の中で再構成する
といった思考コストを、ほぼ発生させずに済むようになりました。
全体構成の概要
- Google アラート RSS を取得
- GAS で重複排除し新規記事のみ抽出
- gpt-4o による個別記事分析と三行広告生成
- 結果をスプレッドシートに保存
- Slack へ即時通知
- 日次バッチで総括レポート生成
これにより、 大量の記事 → 判断が終わった情報 → Slack で意思決定 という流れを自動で実現します。
まとめ
本記事では、Google アラートを起点とした情報収集を、 「大量の記事を読む仕組み」から 「判断が一瞬で終わる情報に変換する仕組み」 へ改善した設計判断を紹介しました。
Part2 では、 この設計をどのようにコードに落とし込み、実運用で破綻しない形にしているかを解説します。
