この記事のポイント
- ✓3日で作ったニュース配信エージェントは、2ヶ月半の運用を経て「収集・編集・配信・記憶・観測」の5層構成に育った
- ✓後から足したのは、重複抑制の3層フィルタ・前日との文脈接続・実行アーカイブと評価ハーネス。どれも本体の作り直しなしで入った
- ✓育てやすさの源泉は、最初のADRで決めた「エージェントの疎結合」と「観測の仕込み」。MVPの設計は2ヶ月半後の拡張の質を決めていた
この記事の位置づけ——シリーズの地図
毎朝6:30、自分専用のニュースメール「朝刊エージェント便」が届く。Claude APIとAWS Lambdaで作った個人用のAIエージェントだ。
2026年3月に3日で作った記録を書いた。それから2ヶ月半、このシステムは止まらず動き続け、そして少しずつ形を変えてきた。機能が増え、コストが下がり、品質を測る仕組みが付いた。
変化が積もってきたので、現在の全体像を1枚に整理しておくのがこの記事だ。個別の深掘りは2本の記事に分けた。
この記事は橋渡し役として、「いま何がどう動いているか」と「なぜ作り直さずに育てられたか」に絞って書く。
全体アーキテクチャ——5層で見る現在形
現在のシステムは、役割で切ると5つの層になる。
収集層 — WebAgent
編集層 — LLM（Haiku 4.5）＋ ComposerAgent
配信層 — Amazon SES
記憶層 — S3
- ・配信済み履歴（14日・重複抑制の根拠）
- ・前日の編集コンテキスト（紙面の継続性）
- ・実行アーカイブ（評価ハーネスの原料）
観測層
- ・CloudWatch 構造化ログ（トークン・コスト）
- ・評価ハーネス（重複率・精度・忠実性）
- ・origin寄与レポート（検索の費用対効果）
3月のMVPにあったのは、このうち収集・編集・配信の3層と、観測層の構造化ログだけだった。記憶層のS3と評価まわりは、すべて運用しながら後から足したものだ。
言い換えると、この2ヶ月半の進化は「記憶と観測が増えていく過程」だったことになる。賢くするより先に、覚えさせて、測れるようにする。結果的にこの順番が正解だった。
収集——並列フェッチ＋web_search補強
情報ソースはWebに絞っている。トピックはyamlで管理していて、現在は5系統。AI・LLM、金融・投資、ゲーム、AI論文（arXivのRSS）、政治・行政だ。トピックの追加はyamlに数行足すだけでいい。
収集経路は性格の違う3本立てになっている。
定点観測: 公式サイト・RSSの並列フェッチ
トピックごとに決めたURLをコードが並列HTTPで取得。LLMは関与しないので無料。確実に見たいソースはここに置く。
広域走査: Google News RSSのキーワード検索
トピックのキーワードでGoogle News RSSを引く。定点に載らないニュースの取りこぼしを防ぐ。これも無料。古い記事はパース段階の日付フィルタで弾く。
鮮度補強: Claude APIのweb_search
動きの速いAIトピックのみ、当日の最新情報を検索で補う。1検索$0.01の従量課金なので、対象トピックと回数上限を設定値で絞っている。
設計の考え方はシンプルで、無料の経路で土台を作り、課金経路は効果を測りながら最小限。web_searchが本当に紙面に貢献しているかは、評価ハーネスのorigin寄与レポートで計測している（品質評価編参照）。
「新聞らしさ」を作る仕組み——重複抑制と文脈の継続
運用していて分かったのは、新聞の品質は要約の上手さよりも「昨日との関係」で決まるということだった。同じ記事が2日続けて載れば信頼を失うし、逆に昨日の続報がちゃんと「続報」として載れば、ぐっと新聞らしくなる。
そのための仕組みが2つある。
ひとつめは重複抑制の3層フィルタ。配信済み記事の履歴をS3に14日分持ち、それを3つの段階で使う。
「コードで確実に弾けるものは入口と出口で、意味の判断が要るものだけ編集（LLM）で」という分担になっている。LLMへの指示だけに頼らず、前後を決定的なコードで挟むのがポイントだ。
ふたつめは前日コンテキストの注入。前日の紙面の編集コンテキストをS3に残しておき、翌朝の編集時に渡す。これで「昨日取り上げた話題の続き」という視点が紙面に生まれる。毎回ゼロから書くLLMに、新聞としての記憶を外付けしている格好だ。
どちらの仕組みも、LLM本体を賢くしたわけではない。記憶（S3）を足して、使わせ方を設計しただけ。それで紙面の質感は別物になった。
進化のタイムライン——何をいつ足したか
2ヶ月半の変更履歴を並べると、システムの育ち方が見えてくる。
2026年3月下旬 — 誕生
ADRを書いて3日でMVP実装、本番稼働。数日後に夕刊便を追加して朝夕2便体制に。当初はメール本文の最終生成だけSonnet 4.6を使う2モデル構成だったが、コスト試算の結果この用途にはオーバースペックと判断し、リリース直後にHaiku 4.5単独へ一本化した。
4月上旬 — コスト構造の作り直し
tool_useループを廃止し並列フェッチ＋LLM1回に。実測$0.20→$0.019/回（約90%削減）。
4〜5月 — トピックの出入り
arXiv論文・政治行政トピックを追加。試したが合わなかったトピックは削除。yaml編集だけで完結。
6月上旬 — 鮮度と紙面品質
web_search補強を導入し、配信は朝刊一本に整理。S3の配信済み履歴による重複抑制3層、前日コンテキスト注入、structured outputs導入。
6月中旬 — 測る仕組み
実行アーカイブ基盤と評価ハーネス（重複率・カテゴリ精度・見出し忠実性）、origin寄与レポートを追加。いまここ。
並べてみるとリズムがある。機能を足す→運用で粗が見える→測る仕組みを足す→数字を見て次を決める。夕刊を畳んで朝刊一本に絞ったような「引き算」も、運用の実感があってこその判断だった。
なぜ作り直しなしで育ったのか
2ヶ月半でこれだけ手を入れて、アーキテクチャの作り直しは一度もしていない。振り返ると、効いていたのは最初のADRで決めた2つの判断だった。
ひとつはエージェントの疎結合（Strategyパターン）。収集も編集も「Agent」という同じインターフェースで抽象化し、パイプラインへの登録1行で足し外しできるようにしてあった。web_searchの追加も、収集経路が3本に増えたのも、WebAgentの内側の変更で完結し、パイプラインや配信側には触れていない。
もうひとつは観測の仕込み。初日からLLM呼び出しごとのトークン・コストを構造化ログにしていたから、「コストが高い」が体感ではなく数字で見え、削減の効果も数字で確認できた。コスト最適化も評価ハーネスも、この延長線上にある。
MVPの設計は「最初の機能」のためではなく、「2ヶ月後の変更」のためにある。
3日で作るときに将来の機能を予測する必要はなかった。予測したのは「変更は必ず来る」ことだけ。境界と観測さえ仕込んでおけば、何が来ても受け止められた。
逆に、最初に仕込まず後悔したものもある。実行アーカイブだ。評価ハーネスを作ろうとしたとき、過去の配信の「入力側」のデータが残っておらず、評価できるのはアーカイブを始めた日以降の配信だけになった。ログと違ってアーカイブは意識して設計しないと残らない。これからエージェントを作る人には、初日から入出力ペアの保存だけは入れておくことを勧めたい。
これから——次に足したいもの
現在の運用コストは月$1弱（内訳：LLM呼び出し 約$0.02×30回＋web_search $0.01×30回 ≒ $0.9。AWS側はほぼ無料枠内。詳細はコスト編）。毎朝のメールは生活の一部になっていて、「動かし続けるモチベーション」の心配はもうしていない。次に足したいのは3つ。
回帰テストの定型化
プロンプトを変えるたびに、過去アーカイブへの評価実行を習慣にする。「直したつもり」の検出を機械に任せる。
トピック設定のUI化
いまはyaml直編集。家族にも使ってもらうなら、トピックの追加・削除くらいは画面から触れるようにしたい。
読者（自分）のフィードバックループ
「この記事は良かった」を1タップで返せる仕組み。judgeの自動評価と人間の主観評価を突き合わせて、評価の精度そのものを上げていく。
AIエージェントは「作った」で終わらず、運用の中で育っていく。そしてその育ちやすさは、最初の3日の設計でかなり決まっていた——というのが、2ヶ月半運用しての実感だ。
作った経緯は制作記、お金の話は運用コスト編、品質の話は品質評価編へ。このシステムの記録は、また変化が積もったら更新する。
著者: しきぴょんた / 2026年6月