1回$0.20の朝刊が、
$0.02になるまで

毎朝6:30に、その日のニュースをまとめたメールが届く。朝刊エージェントを3日で作った話の続きだ。

作る話はよく記事になる。でも個人開発のAIエージェントには、作った後にしか出会えない問題がある。それが「このメール1通、いくらかかってるのか」だ。

月額固定のサブスクと違って、LLM APIは従量課金。プロンプトをちょっと変えただけで、翌月の請求が倍になることも普通にありえる。逆に言えば、仕組みを1ヶ所変えるだけで請求が1/10になることもある。この記事は、それが実際に起きた記録だ。

先に効いた前提をひとつ。設計段階のADRで「LLM呼び出しごとにトークン数とコストを構造化ログに残す」と決めて、CloudWatch Logsに{ inputTokens, outputTokens, costUsd }を毎回出力していた。

初版のWebニュース収集は、Claude APIのtool_use（関数呼び出し）をループで回す構成だった。LLMに「このURL一覧から情報を集めて」と頼み、LLMが「次はこのページを取得して」とツールを呼び、結果を会話履歴に積んでまた考える。エージェントらしい、教科書どおりの作りだ。

実測コストは1回あたり約$0.20。当時は朝刊・夕刊の2便体制だったから、1日$0.40、月に換算すると約$12。個人の趣味ツールとしては「うーん」という金額だった。

ログを見て原因はすぐわかった。tool_useループでは、毎回のLLM呼び出しにそれまでの会話履歴がまるごと入力トークンとして再送される。取得したWebページ本文が履歴に積まれていくので、n回目の呼び出しの入力には1〜n-1回目の全取得結果が含まれる。

ツール呼び出しが10回あれば、総入力トークンはおおよそ二乗のオーダーで効いてくる。「賢いやり方」が「高いやり方」だったわけだ。

考えてみると、ニュース収集においてLLMが本当に必要な仕事はひとつしかない。集まった記事を読んで、重要なものを選び、要約すること。つまり「編集」だ。

どのURLを取得するかはトピック設定に書いてある。取得自体はただのHTTPリクエストだ。そこにLLMの判断はいらない。

そこでtool_useループを廃止し、こう変えた。

あわせて、入力に載せるRSSの取得上限を半分に、max_tokensを8192→4096に絞った。出力トークンは入力の5倍の単価なので、出力の上限管理は地味に効く。

結果は実測で$0.20 → $0.019/回。約90%の削減だった。しかも収集はPromise.allの並列実行になったので、実行時間もむしろ短くなった。品質面でも、編集に専念させたほうが出力が安定した。

90%削減のあとも、ログを眺めていると細かい無駄が見えてくる。

たとえば記事の鮮度。当初は「2日以内の記事だけを選んでください」とプロンプトで指示していた。これはつまり、古い記事の本文まで律儀に入力トークンとして送りつけて、LLMに捨てさせていたということだ。日付の比較なんてコードの得意分野なのに。

RSSのパース段階で日付フィルタをコード側に移し、古い記事は入力に載せないようにした。配信済み記事の除外も同じで、URL正規化による突き合わせはコードでやり、LLMには判断が必要な分（続報の扱いなど）だけを残した。

もうひとつ効いたのがstructured outputs（JSONスキーマ強制）への置き換え。それまで「JSONで出力して」とお願いベースで生成させていた箇所は、たまにパースに失敗してリトライが走る。リトライは丸ごと追加コストだ。出力形式をAPIレベルで強制すれば、この再試行コストが消える。

これは少し恥ずかしい話。6月にコスト周りを総点検したとき、コスト計算式に入れていたモデル単価が間違っていたことに気づいた。

使っているHaiku 4.5の単価を「入力$0.8/出力$4（per 1Mトークン）」で計算していたが、これはひと世代前のHaiku 3.5の価格。正しくは入力$1/出力$5だった。つまりダッシュボード上のコストは、実際より2割ほど安く見えていた。

さらに、ニュースの鮮度を補強するために導入したweb_searchツールの課金も計上漏れしていた。web_searchは$10/1,000検索（=1検索$0.01）の固定料金で、トークン代とは別枠。しかも検索結果はモデルへの入力トークンとしても課金されるので、実際の負担は「$0.01＋結果ぶんのトークン代」になる。1回の検索$0.01は、本体のLLM呼び出し$0.019の半分以上に相当する。「検索を何回まで許すか」は、このシステムの最大のコストレバーになる。

だから検索回数の上限はWEB_SEARCH_MAX_USESという設定値（デフォルト1回）としてコードの外に出した。コストに直結するパラメータは、プロンプトの中ではなく設定値として握っておく。これで「ちょっと検索を増やしてみる」が、料金影響を見積もれる変更になる。

LLMのコスト削減を調べると、必ず出てくるのがprompt cachingだ。プロンプトの共通部分（システムプロンプトや長い前置き）をキャッシュしておき、2回目以降の読み込みを約1/10の単価にする仕組み。うまくハマれば9割引きという、いかにも魅力的な機能である。

当然うちの朝刊にも入れたくなる。でも、検討した結果見送った。理由はキャッシュの2つの性質にある。

朝刊エージェントの実行は1日1回。1回の実行内でLLMを呼ぶのは数回で、しかも各呼び出しの入力の大部分はその日のニュース本文＝毎回まったく違う内容だ。共通プレフィックスといえるシステムプロンプトは短い。キャッシュしても読み戻す機会がほぼなく、計算するまでもなく書き込み割増のほうが勝つ。

prompt cachingが輝くのは、長いシステムプロンプトや資料を短時間に何度も使い回すワークロード——チャットボット、対話型エージェント、同じ文書への連続質問など。1日1回・毎回入力が異なる定時バッチは、ちょうどその対極にいる。

現在の朝刊エージェントの運用コストは、1回あたり$0.02前後＋web_search分。朝刊のみの月30回配信で、月額はおよそ$1弱。缶コーヒー1本分で、毎朝自分専用の新聞が届く計算になった。初版の構成のままなら月$12だったから、同じ機能を約1/10のコストで動かしていることになる。

ふりかえると、効いた打ち手は3つの原則に集約できる。

そしてコストを測れるようにした次は、品質を測れるようにする番だった。同じシステムに評価ハーネスを組み込んだ話は、別の記事に書いた。