Geminiに『今日読むべき記事』を選んでもらう仕組みを作ってみた
情報収集、してますか？
みなさんは普段どのように情報収集していますか？今日はそんな話です。
今まではテレビとか新聞とかありましたが、最近はYouTubeのニュースチャンネルとか気になる情報を選択して視聴するのが良いですよね。関係ない情報を頭に入れなくて済むのが嬉しい。
私はというと、この数年間RSSリーダー（Feedly）を使って情報収集をしています。
💡RSSリーダーとは
Webサイトが公開している「フィード」（feed）と呼ばれる更新情報を受信し、掲載されているWebページへのリンクなどを分かりやすく一覧表示するソフトウェア。当初はRSS形式のフィードを読み込むソフトだったためこのように呼ばれるが、実際にはAtomなど様々な形式に対応していることが多い。
RSSリーダーは利用者が登録したサイトのフィードを定期的に巡回して受信し、新しい内容があると利用者に一覧表示する。利用者はフィードの記された記事のタイトルや要約、公開日時、URLなどを確認し、興味があればWebブラウザなどで当該URLにアクセスしてページ全体を閲覧することができる。
ざっくりいうと、気に入った複数のニュースサイトを購読しておき、一つのアプリから確認できるということだけ押さえておけばOKです。
情報多すぎて、朝から疲れる問題
私は、以下サイトから情報収集していました。
CodeZine — IT/開発者向けニュース
Qiitaトレンド
Zennトレンド
はてなブックマーク テクノロジー
Yahoo!ニュース・トピックス 経済
Yahoo!ニュース・トピックス 国際
Yahoo!ニュース・トピックス 国内
特にはてなブックマークのテクノロジーを重宝していたのですが、
記事数が非常に多かったり、
「X（旧Twitter）まとめ」みたいな関係ない情報が流れてくる
のが非常にストレスでした。
一つでも記事本文を読み始めてしまうと、朝の情報収集の時間に収まらない。（毎朝、60〜70記事ぐらい届くイメージ）
結局タイトルベースで何があったか判断するようになってしまい、情報収集としては形骸化してしまっている状況でした。
ただでさえ毎朝追いつけていないのに、さらに購読しているニュースサイトの守備範囲を広げたい（IT関連のセキュリティ情報を積極的に追いたい）という気持ちもあったので、毎朝モヤモヤが止まらない状態でした。
じゃあ、Geminiに任せちゃおう
今回はGeminiを選びました。理由はシンプルで、Flash-liteという安いモデルが選択肢にあるからです。個人で運用するアプリの場合、「使い続けられるか」がすべてだと考えています。月数千円かかるなら正直やめていました。
Gemini 2.5シリーズには、
Pro：高性能だけど高い
Flash：バランス型（今これ使ってる）
Flash-lite：安い
みたいに段階があります。
今はFlashで運用してますが、さらにコストを下げたいという要望が発生した時、レコメンド精度を見ながらFlash-liteに切り替えることで大幅なプログラムの修正なしにコストを下げられる可能性が高いと考えています。
この「用途に応じて価格と性能のバランスを選べる」「モデルの切り替えの容易さ」という柔軟性が、個人開発者には本当にありがたいです。
アプリの機能を決める（What, Why）
アプリを作るにはWhat（何を作るのか）、Why（なぜ作るのか）を定義しなければなりません。
今回実装したい機能としては、
ニュース情報（フィード）をわかりやすく一覧表示する
メイン機能のため
未読・既読管理を行う
記事毎に「これ読んだっけ….？」という余計な判断をしたくない
ブラックリストを導入する
興味ないサイトからの記事を明示的に表示しない
anond.hatelabo.jp（増田）と togetter.com をブラックリストに入れ、情報源としての信頼性や、朝から読みたくないコンテンツを機械的に弾く
スマホ対応する
基本的にスマホから見るため
AIによるレコメンド機能実装する
大量の記事に埋もれてしまうため
レコメンド方針は運用しながらステップバイステップで要件を詰める
というシンプルなものです。
逆にやらないことは以下としました。
あとで読む機能
ニュース取得元を画面上から管理（ニュースサイトの追加、削除）する機能
これらをやらないこととした理由は単純に使わないからです。
あとで読むの「あとで」は一生来ないし、ニュースサイトの追加、削除する機能はそんな頻度高くないのでプログラムを編集すれば事足りるという判断をしました。
アプリ機能をどうやって実現するか？（How）
アプリを公開する（自分のスマホやPC等のデバイスからアクセス出来るようにする）には、プログラムを書くこと以外にもアプリを格納するためのサーバーが必要です。
正直サーバーまわりはそこまで自信ない…（設定ミスが高額請求に繋がるため非常に怖い）かつ、アプリの仕様上、全世界に公開しなくても良い…。
また開発者の方ならわかるかもしれませんが、画面レイアウト組むの面倒なんですよね…。今回の要件としてはスマホから操作できることを掲げているので、普段、PCで操作する前提のWebアプリばかり作っている私としては、少々しんどい。
今回、1〜2日で運用に乗せたいと考えていたため、できるだけ省力化したいとも考えていました。
そこで白羽の矢が立ったのがGitHubというサービスです。
GitHubは、ユーザのみなさんからヒントを得て作成された開発プラットフォームです。オープンソースプロジェクトやビジネスユースまで、GitHub上にソースコードをホスティングすることで数百万人もの他の開発者と一緒にコードのレビューを行ったり、プロジェクトの管理をしながら、ソフトウェアの開発を行うことができます。
めちゃくちゃ端的に言えば、機能絞って上手く構築すれば、サーバー要らない、レイアウト組まなくていい、定期実行できる！ということです。
処理フローは以下としました。
記事を集める係（３時間ごと）
集めた記事の中でおすすめを選んでissueとして投稿する係（毎朝7時）
ここからは開発者（Claude Code）の方が詳しいので解説してもらいます。
フェーズ１：記事を集める係（３時間ごと）
ニュースサイトを巡回して、新しい記事を受信箱に貯めていくだけの係です。
1. ニュースサイトを巡回 — 配信元（Yahoo!ニュース、Qiita、Zenn等）をチェック
2. 既に集めた記事 or ブラックリスト対象は除外 — 受信箱と過去の投稿を見て、ダブりは捨てる。ブラックリストに入っているドメインの記事も捨てる。
3. 受信箱（GitHub Actionsのアーティファクト機能）に投入 — 新しい記事だけを受信箱に入れる
ポイントは、この時点ではGeminiを使わないこと。ただ集めるだけ。
フェーズ２：集めた記事の中でおすすめを選んでissueとして投稿する係（毎朝7時）
受信箱に溜まった記事をGeminiに見せて選ばせ、まとめて投稿する係です。
1. 受信箱の中身を全部出す — 過去24時間で集まった全記事を取り出す
2. AIに見せて選ばせる — 「これは興味ありそう」「これは重要ニュース」とAIが判定
3. GitHubに記事リストを投稿 — カテゴリごとに整形して、毎朝の「今日の注目記事」として貼り出す
受信箱を空にする — 処理し終わった記事は削除して、明日に備える
補足
受信箱の役割は本来であれば、データベースを使うべきですが、どうせ1日でクリアするのでArtifactで必要十分だと判断しました。
実装して動かしてみた
以下が毎朝出力してもらっているissueとなります。
レコメンドされなかった記事はコメントとして記載してもらってます。
既読、未読管理はissue（ざっくり言うと問題提起し議論する機能）に対し、close（解決済み）にすることで対応しています。
また記事ごとに観点が異なることに気がついたので、それぞれ別issueとして投稿してもらってます。
同じAI（Gemini）でも、フィード（情報源）によって役割を切り替えています。
技術記事 ：
ユーザーの好みに合うもの、ユーザーが普段使う道具（ツール・言語・フレームワーク）に関係するものだけ選ぶ
一般ニュース：
選別せず全部出力する
セキュリティ情報：
選別せず「Chrome関連」「WordPress関連」みたいにタグ付けだけして、製品ごとにまとめ、読みやすくする
「ニュースは見落としたくない」「セキュリティは製品ごとに整理したい」など、人間が情報を読むときの実際のニーズに合わせて、振る舞いを変えているのが上手いところです。
実際に運用してみて
Geminiにレコメンドしてもらうことで、今まで並列的だった記事がある意味優先度付けされ、「これらの記事は集中してみよう」「これらは流し見でいいや」という、選択と集中ができるようになったのが非常によかったです。本当に作ってよかった。
Geminiのレコメンド精度はまずまずといったところなので、これからも試行錯誤していこうと思います。
以下は実際の利用額画面のスクリーンショットなのですが、1日あたり8円ほどで運用できています。
土日は意図的に動かしていないため、１ヶ月だと160円ぐらいですかね？個人的にはコスパ良いと思っているので、大大大満足です。
エンジニア向け補足
APIはFlex Inferenceで動かしています。今回のアプリでは即時性不要のため。
参考情報：https://codezine.jp/news/detail/23875
注意点
もし似たようなアプリを開発される場合、以下注意してください。
サイトの利用規約、robots.txtを確認。許可されていないことはしない。（サイト本文のスクレイピング等、要注意です。今回のアプリではタイトルとRSSに含まれている概要のみGeminiに渡し、レコメンドしてもらってます）
頻繁にサイトに記事取得することは避ける。
Gemini APIキーは絶対漏らさない。誰にも教えない。定期的にキーのローテーションを行うこと。利用額上限を設定しておくこと。（下手したら数十万単位の請求につながります）
同じ記事を何度も取りに行かない（ETag / If-Modified-Since による304対応）
毎朝、近所の掲示板に新しいお知らせが貼られていないか見に行くとします。
普通のやり方（304対応なし） 毎回掲示板の前まで行って、貼ってある紙を全部読み直す。新しいお知らせがなくても、古いお知らせを毎回読み直すので時間と労力がムダ。
304対応ありのやり方 掲示板の管理人さんに「前回見たのが朝7時です。それ以降に更新ありました？」と聞く。更新あり → 新しい紙だけ渡してくれる
更新なし → 「変わってないよ」と一言だけ返ってくる（紙を持ってこなくていい）
この「変わってないよ」の合図が HTTP 304 Not Modified です。
このRSSツールは3時間ごとにニュースサイトを巡回しています。でも、ニュースサイトによってはそんなに頻繁に更新されないことがあります。
そこで、前回アクセスした時の「目印」を覚えておく 各サイトが「これが今の最新版ですよ」という目印（ETagとか更新日時）をくれるので、それを保管しておく
次回アクセスする時にその目印を見せる 「前回はこの目印の状態でした。変わってますか？」と聞く
変わってなければ"304"が返ってくる サイト側は中身を送ってこない → 通信量も処理時間も節約できる
メリット
・相手のサーバーに優しい — 中身を送らせずに済むので負荷が下がる（マナー的にも◎）
・自分側も速い・安い — ダウンロード量が減るので処理が軽くなる
・障害に強い — 全サイトが304を返した日があっても「異常」と誤判定しない仕組みも入っている
今回の実装方針
世の中には「ETagを覚えてくれる便利な部品」もあるんですが、このツールは3時間ごとに別々のプロセスで動くため、「目印」を毎回ちゃんとファイルに書き出して引き継ぐ仕組みが必要でした。既存の部品だとそこが噛み合わないので、必要な部分だけ自分たちで書いた、という感じです。
イメージとしては、「便利な家計簿アプリじゃなくて、自分たちの家のルールに合うように Excel で家計簿を作った」みたいな話です。
まとめ
今回実用性の高いアプリを作れたのも、Gemini APIを低価格で提供してくださっているおかげなので本当に感謝ですね。Gemini APIは1 か月の費用の上限を設定することが可能で、いきなり○十万請求された！みたいなことを仕組みで防ぐことができるのもとても嬉しいです。（試験運用中かつ10分ほどラグがあるみたいなので過信厳禁。）
みなさんもセキュリティや法律、利用規約に気をつけながら、自分専用にカスタマイズされたアプリを作ってみてください。
