オレオレニュースサイト構築記：ローカルLLMの理想とAPI課金の現実

以前にもご紹介したように、日々の情報収集をもう少し効率化しようと思い立ち、自分専用のニュースサイトを作っています。
最近の大幅な変更は Python から Typescript への移行です。わたしは TS か Golang が好きなので Python に耐えられなくなったからなのと、Python の意味合いがそもそもなかったので…。

ニュースサイトといっても大規模なものではなく、気になった英語や日本語の記事を自動で取得し、一覧で表示できるようにしただけのシンプルなものです。記事の取得や翻訳、そしてサイトへの登録といった一連の裏側は、n8nのワークフローを使って自動化しています。

このシステムを作り始めたとき、最初は自宅のサーバーで動かしているローカルLLMに翻訳を任せていました。せっかくローカルLLMが動くような大きなマシンを用意したのだから、それを活用すればランニングコストはほとんどタダで運用できると考えたからです。

ところが、実際に運用を始めてみるとすぐに壁にぶつかりました。

1日に流れてくる記事の数はそれなりに多く、中には非常に長文の記事もあります。そうした長い記事をローカルLLMに処理させると、コンテキストやトークンの上限に引っかかってしまい、全文翻訳ではなく単なる短い要約になってしまうケースが頻発したのです。

これではニュースサイトとしての質が保てないため、仕方なく外部のAPIに頼ることにしました。まずはコストパフォーマンスの良いAnthropicのClaude Haiku 4.5を試したものの、やはりトークン不足になることがあり、最終的にはより高性能なSonnet4.6を翻訳に引っ張り出すことになりました。

その結果どうなったかというと、やたらとお金を食うシステムが爆誕してしまいました。

n8nのような自動化ワークフローからAIを組み込む場合、当然ながらAPI経由での接続になります。普段の作業やClaude Code用にMaxプランなどを契約していても、APIの利用料金は全く別で従量課金されてしまいます。日々のコード生成など、大量にトークンを消費する他の作業と並行して使っていると、目に見えてお金がどんどん溶けていくのを感じます。

ローカルLLMを使い倒すつもりで立派なマシンを買ったのに、この用途ではあまり活躍させられていないという現実は、正直少し残念な気持ちもあります。もちろん、そのマシンのメモリは全く別の用途でしっかりと働いてくれているので無駄にはなっていません。ただ、やはり外部の優れたLLMが弾き出す「圧倒的なスピードと精度」を一度味わってしまうと、無理をしてまでローカルLLMにこだわるという判断にはなりにくいものだなと、痛感させられました。

(今ならクーポン使えば50万で128GBのマシンが手に入るぞ)

今はまだ、理想と現実のギャップでお金が溶けていくフェーズにいます。それでも、AIの世界は進化が早く、今後はより使い勝手が良く、安くて速いモデルが登場して価格競争がさらに進んでいくはずです。

それまでは「どのLLMをどう適材適所で組み合わせていくのがベストなのか」を考える良い機会だと捉えて、いろいろな構成を試しながら遊んでいくつもりです。

それまでは、コンテンツだけをうまく取得したり、きれいに見やすく表示できるようなサイト作りに勤しみます。