Qiitaの過去24時間の投稿をいいね数の多い順に取得し、LLMでニュース原稿にして読み上げるアナウンサーを作ってみました。
実行方法は、リポジトリのREADME.mdを参照ください。
サンプル音声: https://github.com/mniyk/qiita-trend-announcer/blob/main/sample.mp3
PS C:\Users\mniyk\Work\qiita-trend-announcer> uv run .\main.py
対象記事: 307件 / 目標OK件数: 2件
[1/307] 処理中: Claude Code時代の音声入力アプリ4選|Mac標準を諦めてAqua Vo... (現在OK: 0件)
→ FAILED (スキップ)
[2/307] 処理中: ドキュメントが失われた AWS 環境を 1 日で再現 + 再構築手順書まで生成 ... (現在OK: 0件)
→ FAILED (スキップ)
[3/307] 処理中: New Relic アップデート(2026年4月)... (現在OK: 0件)
→ OK (1ループ, 554字)
[4/307] 処理中: 【AI失業したくない】 このAI時代に、一番人手不足なのはまだまだ「情報サービス... (現在OK: 1件)
→ OK (2ループ, 472字)
================================================================================
原稿確定: 2件
================================================================================
番組原稿:
こんにちは。Qiitaトレンドニュースの時間です。本日注目された記事をお届けします。
1本目のニュースです。New Relic アップデート(2026年4月)。
2026年4月にNew Relicが発表したアップデートでは、クラウドコスト最適化を迅速化するCloud Cost Intelligenceの一般提供が開始されました。AWS・Azure・GCPのコストとアプリ・インフラのパフォーマンスを紐づけ、無駄なリソースを即座に特定できる機能です。さらに、システムに影響を与えるすべての変更イベントを記録し、パフォーマンスデータと重ねて表示するChange Trackingも一般提供されました。ネイティブモバイルアプリのユーザー操作を動画のように再現できるMobile Session Replayも同時に公開され、クラッシュやエラーの原因を可視化できます。パフォーマンスリスクを自動検知し調査時間を短縮するPerformance Risks Inboxはパブリックプレビューを開始し、遅いSQLクエリやN+1問題を即座に集約します。APMエージェントはOpenTelemetry APIをネイティブサポートし、ベンダー依存を段階的に脱却できるようになりました。最後に、Kubernetes環境でWindowsノードの監視が一般提供され、Linuxと同様にメトリクスを収集し単一画面で一元管理できるようになりました。詳細はNew Relic公式ブログで確認できます。
2本目のニュースです。【AI失業したくない】 このAI時代に、一番人手不足なのはまだまだ「情報サービス業」らしい(帝国データバンク調べ)。
AIの活用が進む中、2026年4月に帝国データバンクが実施した調査によると、正社員の人手不足割合が最も高かった業種は「情報サービス」で66.7%に達しました。全体では50.6%の企業が正社員不足を実感しており、これは4月として4年連続で半数を超える数字です。情報サービスに続き、運輸・ 倉庫、メンテナンス・警備・検査が65.9%、建設が65.7%と高い人手不足が報告されています。
一方、AIによるコード生成が普及している現状では、ソフトウェア開発の単純作業は減少しているものの、AIが生成したコードを安全に運用する設計やレビューを担う人材の需要が増えていると、IT系企業の声が示しています。AIコーディングサービスを利用したアプリが本番環境で公開されるケースが増え、AxiosやWIREDが報じたように、個人情報・APIキー・医療情報・社内データなどの漏洩が多発しています。AIコーディングにより、コードの中身を知らずに数時間でWebサービスを公開できるようになった一方で、セキュリティレビューが行われないまま公開される事例が急増しています。
以上、Qiitaトレンドニュースをお届けしました。
音声合成中... → news.mp3
完了
1. 技術スタック
- Python
- LangChain
- LangGraph
- Ollama
- edge-tts
- Qiita API v2
- httpx
2. ニュースソース選び
はじめは、Yahoo!ニュースを、ニュース原稿にしようと思ったのですが、規約でスクレイピング禁止とのことだったので却下。
次に、Hacker Newsを考えましたが、英語記事が中心で本文を取りに行く手間があるので却下。
そこで、Claudeと相談して、Qiitaを利用することにしました。
3. LangGraphの流れ
生成と評価を別のノードに分けて、評価で不合格なら理由をフィードバックとして次の生成に渡す、というループを組みました。
[生成ノード] → [評価ノード] → OK → 終了
↓
NG(フィードバック付き)
↓
[生成ノード]に戻る(最大10回)
4. モデル選び
最初は gemma4:e4b を試しました。しかし、明らかにニュース原稿ではないレスポンスであったり、提案文を返してくることが多く目立ちました。
gpt-oss:20b に変更することで、ニュース原稿として成立する出力が増えました。
ただし、これでも、ニュース原稿ではないレスポンスもあったため、読み上げる原稿は、評価ノードでOKとなったもののみとしました。
5. プロンプト
ニュース原稿ではない出力が多かったため、プロンプトも試行錯誤しましたが、大きな改善にはつながりませんでした。
Few-shotプロンプトで例を含めれば変わりそうですが、評価ノードでOKとなる原稿が安定して得られたため、シンプルなプロンプトのままにしています。
6. 失敗例
明らかにニュース原稿になっていないレスポンスの例です。元のQiita記事がLLMを使った技術解説だったため、LLMが「これは自分への依頼だ」と勘違いして、要約ではなくブラッシュアップ提案文を返してきました。
## 💡 記事の要約とブラッシュアップ案
元の記事は非常に技術的で網羅的ですが、読者層によっては情報量が多すぎ、どこに最も価値があるのかがぼやけている可能性があります。
【改善の方向性】
1. 結論ファースト: 何が達成できたのかを冒頭で明確に打ち出す。
2. 構造化: 「課題」→「アプローチ」→「成果」のストーリーラインを明確にする。
以上、【Ollama】Qiitaの記事を、ニュース原稿にして読み上げるアナウンサーを作ってみたでしたー!