はじめに
エンジニアとして日々の技術トレンドをキャッチアップするのは正直大変だと思います。新しい技術やツールの情報が次々と登場する中、それらを自分で探しに行くのはなかなか手間がかかります。「情報の方から自分の方に来てくれたらいいのに...」と思われたことはみなさんあると思います。
そこで私は、「最新の技術情報を毎朝メールで教えてくれる仕組み」をAWSで構築してみました。この記事では、その概要と構築過程で得た気づきについて紹介します。
当初検討していた構成
以下のような構成を検討していました。
- Amazon EventBridgeが毎朝7時に定期実行
- AWS Lambda（ニュース収集）が起動
- 各ニュースサイトからRSS経由で最新情報を収集
- 収集データをS3（記事本文）と、DynamoDB（記事メタデータ）に保存
- AWS Lambda（ニュースレコメンド）が起動
- DynamoDBから過去24時間の記事データを取得
- Amazon Bedrockを使って分析し、個人的に興味がありそうな記事をレコメンド
- Slack・Discord・メールなどで通知
特に力を入れたかったのは、Amazon Bedrockを使った記事のレコメンド機能でした。単に新着記事を通知するだけでなく、「私はこういう記事に興味がありそう」という推測を生成AIにやってもらおうと考えていました。
実際にできた構成
しかし、いくつかの壁にぶつかった結果、実際に実装できたのは以下のシンプルな構成でした。
- Amazon EventBridgeが毎朝7時に定期実行
- AWS Lambda（ニュース収集）が起動
- Qiita RSSから最新情報を収集（他のソースは断念）
- 収集データをDynamoDBに保存（記事本文の取得は断念）
- AWS Lambda（ニュース通知）が起動
- DynamoDBから過去24時間の記事データを取得
- 単純にランダムで5件ピックアップ（Bedrockによるレコメンドは断念）
- Amazon SESでメール通知
直面した3つの壁と妥協案
1. ウェブスクレイピングの壁
| 項目 | 内容 |
|---|---|
| 課題 | 記事本文を取得しようとしたものの、スクレイピング結果が空になる |
| 理想 | 記事の全文を取得して内容をより深く分析したかった |
| 妥協案 | 「タイトルだけでも十分に記事の概要は把握できるだろう」と割り切る |
2. Bedrockのクォータ制限の壁
| 項目 | 内容 |
|---|---|
| 課題 | Bedrockのクォータ制限が厳しく、毎日のバッチ処理で使うには不十分 |
| 理想 | AIによる高度な記事レコメンド機能を実装したかった |
| 妥協案 | 「人気記事ランキングという形で世間の関心事が分かればよいだろう」と目的を調整 |
3. マルチソース対応の複雑さの壁
| 項目 | 内容 |
|---|---|
| 課題 | ニュースサイトによってRSSの形式が異なり、統一的な処理が難しい |
| 理想 | 複数の技術ブログやニュースサイトから情報を集約したかった |
| 妥協案 | 「まずはQiitaだけでも情報収集の習慣づけができるだろう」と対象を限定 |
以上、3つの課題に直面しましたが、いずれも「実現できていないけどひとまずOK！」と前向きに妥協することで、シンプルながらも動く仕組みが完成しました。
実際に届く通知内容
毎朝届くメールは以下のようになっています。
【日次】人気ニュース記事TOP5（2025-04-29）
過去24時間以内の高評価ニュース記事TOP5:
1. SortedContainersの計算量まとめ
スコア: none
URL: https://qiita.com/kemuniku/items/1dd49b4cad22c54d3754
投稿日時: 2025-04-28T15:10:26+09:00
2. BedrockナレッジベースでAuroraを使ったハイブリッド検索サポート！日本語でもいけるの？？
スコア: none
URL: https://qiita.com/moritalous/items/2931c07495b34d341708
投稿日時: 2025-04-28T12:17:40+09:00
3. 生存率使ったSaaSのCLV(顧客生涯価値)の計算を、AIにやらせたら一瞬で終わった
スコア: none
URL: https://qiita.com/IkuyaM/items/f1f3ee6b1fe65d5f53b0
投稿日時: 2025-04-28T08:16:38+09:00
見た目はシンプルですが、毎朝届くことで「今日はどんな技術記事が話題になっているんだろう？」と確認する習慣がつきました。
この開発で学んだ3つのこと
1. MVPの重要性
最初から完璧なものを作ろうとするよりも、「とりあえず動くもの」を作って徐々に改善していく方が現実的です。今回、当初の設計から機能を削ぎ落としてシンプルにしたことで、比較的簡単にシステムを構築することができました。
2. 事前調査の大切さ
特にAWSのサービスを使う際は、クォータ制限や料金体系をきちんと調べておくべきでした。Bedrockの利用制限は事前に把握していれば、最初からもっと現実的な設計ができたと感じています。
3. シンプルさの価値
結果的に、シンプルな仕組みでも十分に役立つものが作れました。「完璧な仕組み」より「実際に使える仕組み」の方が価値があります。この経験から、「まずはシンプルに、そして少しずつ改善していく」というアプローチの有効性を実感しました。
これからの展望
現在のシステムはシンプルですが、毎日の情報収集の助けになっています。
今後は以下のような改善を考えています。
- マルチソース対応（他の情報源の追加）
- 生成AIによるレコメンド機能の実装（Bedrockのクォータ制限が緩和されれば...）
- 興味のあるトピックによるフィルタリング機能
「理想の姿」に一度でたどり着けなくても、少しずつ前進していくことが大切だと感じています。
おわりに
技術的な制約や予期せぬ問題に直面したとき、「理想を追求して立ち止まる」よりも「できる範囲で前に進む」ことの大切さを学びました。
皆さんも何か作りたいものがあれば、完璧を求めすぎずまずは動くものを作ってみることをおすすめします。思っているより早く価値を生み出せるかもしれません。
ありがとうございました。