API課金ゼロでAIメディアを2本動かす — 実際の構成と、かかっている費用の全部

株式会社TOEでは、自社メディアを2本運営しています。宇宙産業の情報メディア「UchUchU」（uchuchu.tech）と、補助金情報の「補助金の鬼」（hojokin.website）です。

どちらも記事の収集・翻訳・要約・公開までを自動で回していますが、AIの従量課金（APIを叩いた分だけ払う課金）は1円も発生していません。

この記事では、その構成を実際のコードと実行ログから説明します。「うちでも同じことができそうか」を判断できるように、うまくいっていない部分と、この方式が向かないケースも書きます。

なお、両サイトを公開したのは2026年7月18日です。構成の記録であって、長期運用の実績記録ではありません。この記事に出てくる数字は、すべて7月19日時点の実データと実行ログから取っています。

なぜ「課金ゼロ」から設計したのか

自社メディアは、クライアント案件と性質がまったく違います。納品してお金をもらうものではなく、稼げるようになるまで時間がかかる資産です。

検索エンジンに評価され、読者がつき、問い合わせに変わるまでには年単位かかります。その間ずっと赤字が出続ける構成にしてしまうと、成果が出る前に「今月も1万円出ていくな」という理由でやめることになります。

そこで社内ルールとして、コンテンツ部には次の鉄則を置いています。

運用中に従量課金を発生させない構成を維持する。新機能を足すときも「これは毎月いくらかかるか」を必ず問う。

「安く抑える」ではなく「ゼロにする」と決めたのは、ゼロなら判断が要らなくなるからです。月1万円だと毎月「これは元が取れているか」を考えることになりますが、ゼロなら考えなくていい。放っておけます。放っておけるものだけが、資産として積み上がります。

お金がかかる5か所と、それぞれの回避策

メディアを自動運転しようとすると、費用は次の5か所で発生しがちです。順に見ていきます。

1. 情報収集 — 有料APIを使わない

ニュース収集をAPIで買うと、月額数千円から数万円かかります。UchUchUでは、無料で公開されているRSSと公開APIだけを使っています。

RSSは、サイトの更新情報を機械が読める形で配信する仕組みです。ニュースサイトの多くが無料で出しています。

現在つないでいるのは26のソースです。日本語ではJAXA、国立天文台、sorae、宙畑など。英語ではNASA、ESA、SpaceNews、Ars Technica など。打ち上げ情報は Launch Library 2、論文は arXiv の公開APIから取っています。すべて無料・登録不要です。

実データの件数はこうなっています。

データ	件数
ニュース	570件（うち英語473件・日本語97件）
打ち上げ	200件（予定99・実績101）
論文	250件

2. 翻訳 — ここが一番お金のかかるところ

英語記事473件を翻訳APIに投げると、当然その分だけ課金されます。しかも毎日増えます。ここが一番お金が漏れる場所でした。

回避策は後述しますが、加えて訳したものは必ずキャッシュする設計にしています。翻訳結果は translations.json に保存され、現在473件が入っています。実行ログを見ると、2回目以降の実行ではこうなります。

[translate] 英語記事473件: 既訳流用 7件 / 新規翻訳 7件

473件を毎回訳し直せば、無料でも数十分かかります。翻訳するのは新しく増えた分だけです。

3. 要約 — 一度に全部やらない

記事本文を取ってきて日本語要約をつける処理も、AIを使います。UchUchUでは1回の実行あたり40件までと上限を切っています。

全件を一度に回すと数時間かかるため、毎日少しずつ消化して未処理を減らす設計です。現時点で570件中226件に本文要約がついています。まだ半分以下ですが、毎日削っていけば埋まります。

4. ホスティング・配信 — 静的サイトにする

静的サイトとは、あらかじめHTMLファイルを全部作っておいて、それをそのまま配るサイトのことです。アクセスのたびにサーバー側で計算する仕組み（データベースやWordPressなど）を持ちません。

サーバー側で何も動かないので、サーバー代がかかりません。UchUchUは手元のMacでHTMLを生成し、それを GitHub Pages に置いて配信しています。生成されるのは1267ファイル・31MBです。これで月額ゼロ、商用利用も可能です。

補助金の鬼のほうは Vercel を使っています。ここは正直に書いておくと、Vercelの無料枠（Hobby）は商用利用不可です。将来この2本を本格的に収益化するなら、有料プランに移すか GitHub Pages に寄せる必要があります。ここは未解決の課題として認識しています。

5. 問い合わせ受付 — 共通の仕組みを1本だけ持つ

静的サイトはサーバー側の処理を持てないので、問い合わせフォームが素直には作れません。フォームサービスを契約すると月額がかかります。

ここは Google Apps Script（GASと呼ばれる、Googleアカウント内で動く無料のスクリプト）で受付を1本だけ作り、全メディアで共有しています。新しいメディアを増やしても、設定に1行足すだけで済みます。メディアごとに同じものを作らないことも、社内ルールにしています。

ローカルのLLMを使うという発想

ここが今回いちばん伝えたい部分です。

翻訳と要約に使っているのは、手元のMacに入っている claude コマンド（Claude Code のCLI）です。従量課金のAPIキーを使っていません。

正確に言うと、CLIは通信して応答を得ています。計算が手元で完結しているわけではありません。重要なのは課金の経路です。APIキーを使うと使った分だけ請求が増えますが、CLIはすでに社内業務で契約済みのClaude Codeの枠で動きます。つまり、メディアを回しても支払いが増えません。

コードでは翻訳をこう組んでいます。

1. claude CLI を使う（品質が最も高い）
2. 失敗したら argostranslate に落とす（完全にオフラインで動く無料の機械翻訳。品質は劣る）
3. どちらも駄目なら原文のまま載せる

3段構えにしているのは、どこかが止まってもサイトは動き続けるようにするためです。実際、7月19日の実行ログでは claude 側で訳せなかった7件を argostranslate が拾っています。

翻訳は1回のプロンプトに12件をまとめて渡します。1件ずつ呼ぶと回数が増えて時間もかかるためです。

そして最重要の設定がこれです。

export UCHUCHU_BATCH_MODEL=haiku

バッチ処理では必ず軽量モデル（Haiku）を指定する。これは事故から学んだルールです。以前、553件の要約をモデル未指定で回したところ、上位モデルが使われて途中で利用上限に達し、414件が失敗しました。しかも枠を食い潰したせいで、その間こちらの対話作業まで止まりました。定型の翻訳処理に上位モデルは要りません。

実際にかかっている費用

正直に全部書きます。

項目	費用
ニュース収集（RSS・公開API）	0円
翻訳・要約（claude CLI）	0円（契約済みの枠内）
ホスティング（GitHub Pages / Vercel）	0円
問い合わせ受付（GAS）	0円
実行環境	0円（社内の常時稼働Mac）
ドメイン代	ゼロではない（uchuchu.tech と hojokin.website の2本）

ゼロなのは従量課金であって、費用の総額ではありません。ドメイン代は毎年かかります。またClaude Codeの契約料は別途払っています。ただしこれはメディアのために契約したものではなく、もともと社内で使っているものです。メディアを増やしても、この金額は増えません。そこが要点です。

実行にかかる時間

cronという定時実行の仕組みで、UchUchUは毎日6時30分と18時30分の2回、補助金の鬼は毎日6時30分に動きます。朝は前夜の海外ニュース、夕方は国内の当日発表を拾う狙いです。

実際の所要時間は、7月19日のログでこうでした。

• 新規が少ない回：約3分（00:01:34 開始 → 00:04:24 終了）
• 要約を10件生成した回：約8分（00:47:38 開始 → 00:55:29 終了）

処理が終わると、生成した1250ページ分のURLを IndexNow で検索エンジンに通知します。ここまで全部無人です。

うまくいっていないこと

同じ7月19日のログに、こういう行があります。

要約生成が8件連続で失敗。利用上限に達した可能性が高いため中断する。

契約枠を使う以上、枠の上限には当たります。そのときは要約がその回だけ進みません。連続失敗したら自動で中断し、次の回に持ち越す設計にしてあります。無理に続けて対話用の枠まで食い潰すより、諦めたほうがましだからです。

もうひとつ、cronから動かすと claude コマンドが見つからず無音で失敗する問題がありました。cronは環境変数を最小限しか渡さないためで、PATH と USER LOGNAME を明示して解決しています。この手の環境の詰まりは、AIの問題ではなく普通のシステム運用の問題です。そしてだいたいここで時間を取られます。

補助金の鬼のほうは、そもそも日次処理にAIを使っていません。jGrants（国の補助金データベース）から取得して差分を出すだけなので、普通のプログラムで足ります。AIを使わなくていいところで使わないのも、コストを増やさないコツです。かわりに、取得件数が50件を下回ったら異常とみなして更新を巻き戻す、ビルドが通らなければ本番反映を中止する、といった安全弁を入れています。

この方式が向かないケース

正直に書きます。次のような場合、この構成は向きません。

リアルタイム性が要る場合。1日2回の更新です。速報を分単位で出したいメディアには使えません。株価やスポーツの実況のように「今この瞬間」が価値の中心にあるなら、別の構成が要ります。

大量アクセスが来る場合。静的配信なのでアクセス自体には強いのですが、無料枠には転送量の上限があります。本当に当たったら有料プランに移す判断が要ります（そのときは収益も出ているはずなので、良い問題です）。

ログインや会員機能が要る場合。静的サイトにはサーバー側の処理がありません。会員登録、決済、ユーザーごとの表示出し分けが必要なら、この構成では作れません。

処理量が桁違いに多い場合。契約枠で回している以上、上限があります。1日に数千件を翻訳したいなら、素直に従量課金のAPIを使ったほうが速く、結果的に安いこともあります。枠内で足りる規模かどうかが分かれ目です。

社内に手を動かせる人がいない場合。これが一番大きいかもしれません。この構成はコードで3312行あります。ノーコードで組めるものではありません。作った後も、cronが止まった、RSSの仕様が変わった、といった保守が要ります。

まとめ

やっていることを整理すると、こうなります。

1. 収集は無料の公開情報だけを使う（RSSと公開API）
2. 翻訳・要約は契約済みの枠で動くCLIを使い、従量課金のAPIキーを使わない
3. バッチ処理は必ず軽量モデルを指定する（ここを外すと事故る）
4. 訳したものはキャッシュして、新規分だけ処理する
5. 配信は静的サイトにして、サーバー代を発生させない
6. 共通の仕組みは1本だけ持ち、メディアごとに作らない

特別な技術は使っていません。「どこでお金が漏れるか」を先に洗い出して、1か所ずつ塞いだだけです。

AIを業務に入れるとき、最初から従量課金の構成で作ってしまうと、成果が出る前にコストの話で止まります。すでに払っているものの範囲で作れないかを先に考えると、続けられる形になることがあります。少なくとも、私たちのメディアはその形で動き始めました。

これが半年後もちゃんと回っているかは、また記録します。