この記事は、Source Score というマイクロサービスの開発を続けている筆者が、「ニュースソースの追加」を自動化した記録です。
最初は、ソースはたった5件を手で追加して動作確認していたそうです。まあ、最初の一歩としてはすごく自然です。システムを作るとき、最初から完璧に自動化しようとすると逆に進まないので、まずは人力で土台を作るのはよくあるやり方です。
でも問題は、その先です。
世界中の主要ニュースサイトを定期的に取り込みたいのに、毎回手作業でPRを作るのは正直しんどい。そこで筆者は、
という流れを、ほぼ全部自動にしたわけです。
この「地味な作業を機械に任せる」感じ、個人的にはかなり好きです。AIの派手さより、こういう実務寄りの使い方のほうがずっと価値があると思います。
最初の課題は、ニュースランキングが載っているページをどう扱うかでした。
元のHTMLは広告や見出し、脚注などが混ざっていて、そのままでは扱いづらい。そこで使ったのが Firecrawl です。
Firecrawl は、Webページをスクレイピングして、読みやすい形に整えてくれるツールです。ここでいう スクレイピング は、Webページから情報を機械的に集めることです。人間が見る画面そのものではなく、プログラムが処理しやすい形に変えるイメージですね。
筆者は Firecrawl を使って、ページを Markdown に変換しています。Markdown は、見出しや箇条書きをシンプルに表せるテキスト形式です。HTMLよりずっと軽く、LLMにも渡しやすい。
この判断はかなり賢いと思います。AIに長文のゴミだらけHTMLを渡すより、Markdownにしてから投げたほうが、抽出精度が上がりやすいからです。
次に筆者は、OpenRouter を使って LLM にURL抽出をさせています。
OpenRouter は、複数のモデルをまとめて扱えるサービスです。しかも無料枠があるので、コストを抑えながら試せるのが魅力だったようです。
ここで面白いのは、1つのモデルに頼り切っていない ことです。
筆者は無料モデルを3つ用意し、1つが失敗しても次を試す作りにしています。対象モデルは以下です。
LLMは便利ですが、APIが失敗したり、返答が空になったりすることがあります。
なので「ダメなら次へ」という実装は、かなり現実的です。AIを本番運用に組み込むときは、魔法扱いせず、普通のシステムとして壊れ方を想定するのが大事なんですよね。
LLMへの指示はかなりシンプルで、
という形です。
ただし、ここで出てくる結果は完璧ではなく、余計な文字が混ざったり、URLが省略されたりすることもあるそうです。
ここが「AIを使えば全部一発で終わるわけじゃない」ポイントです。むしろ、AIは下書きを作るのが得意 で、最終確認は別の工程で補うのが現実的だと思います。
1回目のLLM出力だけだと不安なので、筆者はもう1回 OpenRouter を使います。今度は web_search ツールを使って、URLの正しさを確認しています。
ここでの考え方はシンプルです。
これはすごく堅実です。
LLMはもっともらしい嘘を混ぜることがあります。いわゆる hallucination です。日本語だと「幻覚」と訳されますが、要するに「それっぽいけど実は違う情報」を出してしまう現象です。
だからこそ、最後に検索で検証するのは正解だと思います。AIを信じすぎず、裏取りを自動化する。ここに本当の実用性があります。
URLがきれいに取れたら、次は Source YAML を作ります。
YAML は設定ファイルによく使われる、人間に読みやすいデータ記述形式です。例えば「名前」「URL」「説明」みたいな情報を整理して書けます。
筆者はここでもLLMを使い、既存のYAMLサンプルを「schema例」として与え、その形式に合わせて各ニュースソースのYAMLを生成させています。
つまり、
という流れです。
これもなかなか面白い使い方です。AIに「文章を書いて」と頼むのではなく、決まった構造のデータを埋めさせる のがポイントです。
LLMは自由作文よりも、「型に沿った生成」で真価を発揮しやすいと思います。
生成したYAMLをそのまま保存すると、同じソースを何度も作ってしまう可能性があります。
そこで筆者は、sources/ 配下の既存YAMLを全部読み込み、name と uri を比較して、すでにあるものは除外しています。
さらに、ファイル名もそのまま使わず、使えない文字を置換して安全な名前にしています。
このへんは地味ですが、とても大事です。
AIでファイルを量産するときは、内容よりも 安全な保存処理 のほうが事故防止に効きます。上書き事故や重複は、本当にあとで面倒なので。
最後の仕上げが GitHub Actions です。
これは GitHub 上で定期実行やCIを動かせる仕組みで、今回のような自動化と相性がいいです。
筆者のワークフローは毎月1日に動き、
という流れです。
PRがマージされると、既存の validate.yml がYAMLの正しさを確認し、post_on_merge.yml がAPIに反映します。
つまり、人間は最後にPRをマージするだけ。それ以外はほぼ自動です。
個人的には、この「自動でPRを作る」という形がとても良いと思います。
いきなり本番反映ではなく、ちゃんとPRレビューの余地を残している。自動化しつつ、人間の確認ポイントも残しているので、安心感があります。
筆者によると、この仕組みで新しいソースは正しいURLと短い説明付きで追加され、CIも問題なく通ったとのことです。
しかも、毎月かかる人間の作業時間は「PRをマージする1分未満」になったそうです。
これはかなり強いです。
「AIで全部置き換える」というより、「退屈な手作業だけを削る」アプローチとして優秀です。こういうのを見ると、AIの価値は派手な生成物より、継続運用の摩擦を減らすこと にあるんだなと改めて思います。
筆者は次の課題として、同じパターンを claims と proofs に広げたいと書いています。
ソース追加よりデータセットが大きく、検証も複雑で、LLMの幻覚が起きやすいので、より難しくなるようです。
ここはまさに本番っぽい話です。
単純なリスト追加は自動化しやすいけれど、検証対象が増えるほどAIの弱点も見えやすくなる。だからこそ、今回の仕組みを土台に次へ進む、という流れは自然です。
この記事の面白さは、AIを「賢いチャットボット」として使っているのではなく、スクレイピング・抽出・整形・検証・PR作成 という実務パイプラインの一部として使っている点にあります。
Firecrawlで入力を整え、OpenRouterで候補を作り、web_searchで裏取りし、GitHub Actionsで定期運用する。
この流れは、かなり実用的ですし、再利用もしやすいはずです。
派手さはないけれど、こういう「毎月やる面倒を消すAI活用」こそ、いちばん効くのではないかと思います。
AI導入の本命は、会話のうまさより、面倒な定型作業をちゃんと終わらせる力なのかもしれません。
参考: Source Score: Using AI to automate addition of new sources
