この記事で得られること
- AIエージェントのAPI代を月$600から$100に削減した具体的な方法がわかる
- コスト構造の分析と最適化ポイントを実データつきで理解できる
- Claude Code Maxプランを活用したコスト削減戦略を参考にできる
対象読者: AIエージェントの運用コストを下げたい方 / API料金の最適化を検討している方
月$600の請求書が届いた日
自律AIエージェント「Sentinel」の開発初期、OpenClawのAPI従量課金で月$600を叩き出した。1日あたり約$20の消費が30日続いた結果だ。
内訳はこうだ。Sentinelは自律的にタスクを回す。タスクの判断にLLMを呼び、サブエージェントを起動し、その結果を解釈してまたLLMを呼ぶ。1サイクルで数万トークンを消費し、それが1日に何十回も回る。
個人開発者の$600は笑えない金額だ。「AIエージェントを作ったが、動かすと破産する」——冗談のようだが、LLMの従量課金でエージェントを運用すると普通に起きる。
従量課金の構造的な罠
API従量課金でAIエージェントを動かすと、使うほど高くなる→使用を控える→価値が出ないという悪循環に陥る。
エージェントの本質は「自律的に動き続けること」だ。人間が寝ている間も巡回し、タスクを処理し、状況を監視する。だが従量課金モデルでは、動くたびにコストが発生する。エージェントが賢くなって仕事量が増えるほど、請求額も比例して膨らむ。
従量課金の悪循環:
エージェントが自律的に動く
→ トークン消費が増える
→ API代が膨らむ
→ 動作頻度を制限する
→ エージェントの価値が下がる
→ 「やっぱり手動でいいか」
これはチューニングで解決する問題ではない。課金モデルそのものが、自律エージェントと相性が悪い。
OpenClawでも同様の構造に直面し、最終的にOpenClawの利用を諦めた経緯は以前の記事に書いた。
課金構造の転換: 従量課金→定額プラン
なぜClaude Code MAXプランか
$600の請求を見た時点で、従量課金のチューニングではなく課金構造そのものの転換が必要だと判断した。
選択肢を整理するとこうなる。
| 選択肢 | 月額 | エージェント運用との相性 |
|---|---|---|
| OpenClaw API従量課金 | $600+（実績） | 使うほど高い。天井なし |
| Claude API従量課金 | $300〜500（推定） | 同上。モデル性能は高い |
| Claude Code MAXプラン | $100（定額） | 使い放題。天井あり |
Claude Code MAXプラン（$100/月）は、Claude CLIを定額で使える。APIのトークン課金が発生しない。時間あたりのトークン利用制限はあるが、従量課金のように「動かすほど請求が膨らむ」構造ではない。
Claude Code MAXプランには2つのティアがある。Max 5x（$100/月）とMax 20x（$200/月）だ。それぞれProプランの5倍・20倍の利用枠が付与され、5時間ローリングウィンドウで利用量がリセットされる。Sentinelでは$100/月のMax 5xを採用している。
自律エージェントにとって「定額」は決定的に重要だ。エージェントを好きなだけ動かしても月$100。これで「コストが怖くて動かせない」問題が消える。
移行の判断基準
移行を決めたのは単純な損益計算だ。
- 従量課金で月$600の実績がある
- MAXプランは月$100
- 差額$500が、利用制限による速度低下を許容するコスト
月$500の削減と引き換えに、ピーク時の処理速度が制限される。だが個人開発のAIエージェントにリアルタイム性は必須ではない。30分遅れても問題ない処理がほとんどだ。この判断は正しかった。
設計レベルでのコスト制御: 3層アーキテクチャ
MAXプランで課金額は$100に固定された。だがトークン利用制限は存在する。制限内で最大限の仕事をさせるには、設計レベルでトークン消費を制御する必要がある。
SentinelではBrain / Runtime / Subagentの3層構造でこれを実現している。
┌─────────────────────────────────────┐
│ Brain（Claude LLM） │ ← 判断のみ。短いプロンプト
│ 「何をすべきか」を決める │
├─────────────────────────────────────┤
│ Runtime（Node.js） │ ← ノーコスト。LLM不要
│ ファイルI/O、Discord通信、スケジュール │
├─────────────────────────────────────┤
│ Subagent（Claude CLI子プロセス） │ ← 使い捨て。重い処理を委任
│ 記事執筆、リサーチ、コード生成 │
└─────────────────────────────────────┘
Brain: 判断だけさせる
Brainの役割は**「次に何をすべきか」の判断のみ**。実際の処理は一切しない。
Brainへの入力（例）:
- TASKS.mdの現在のタスク一覧
- 前回のHeartbeatからの差分
- 「次に実行すべきタスクを1つ選べ」
Brainの出力:
- タスクID + 実行指示（数十トークン）
Brainに渡すプロンプトは意図的に短く保つ。タスクの詳細、過去の実行ログ、コードの中身などはBrainには渡さない。判断に必要な最小限の情報だけ。これでBrainのトークン消費を低く抑える。
Runtime: LLMを使わない層
ファイルの読み書き、Discordへの通知送信、Heartbeat（定期巡回）のスケジューリング——これらはLLMに頼る必要がない処理だ。Node.jsで書いたRuntimeレイヤーが担当する。
Runtimeのトークンコスト: ゼロ。
当たり前だが、これが意外と重要だ。初期のSentinelでは「Discord通知を送る��という単純な処理もLLMに指示していた。LLMは律儀に「Discordに通知を送信します」と宣言してから送信し、「送信完了しました」と報告する。この一連のやり取りだけで数百トークン消費する。
Node.jsで discord.js を直接叩けば、トークンはゼロで同じことができる。LLMにやらせる必要のない処理は、LLMにやらせない。 当たり前の原則だが、エージェント開発では意外と見落とす。
Subagent: 使い捨ての重い処理
記事の執筆、コードの生成、複雑なリサーチ——こうした「重い処理」はSubagentに委任する。
Subagentの特徴は使い捨てであること。
Brain: 「Qiita記事を執筆せよ」
→ Subagentを起動（新しいCLIプロセス）
→ 記事を執筆（大量のトークンを消費）
→ 結果を返して終了（プロセス破棄）
Subagentはタスク完了後にプロセスごと破棄される。Brain本体のコンテキストにSubagentの作業内容が蓄積されないので、Brain側のプロンプトが肥大化しない。
これはトークン消費の制御として効果が大きい。仮にSubagentが10万トークンを消費しても、Brain本体のコンテキストには「タスクXが完了した」という数十トークンの結果だけが残る。
実測: $600→$100の内訳
Before（従量課金時代）
| 項目 | 月額 |
|---|---|
| OpenClaw API利用料 | ~$600 |
| インフラ（自宅PC） | $0 |
| 合計 | ~$600 |
After（MAXプラン移行後）
| 項目 | 月額 |
|---|---|
| Claude Code MAXプラン | $100 |
| インフラ（自宅PC） | $0 |
| 合計 | $100 |
削減額: 月$500（83%削減）
※$600は1日あたり約$20の消費 × 30日の概算値。日によって変動はあるが、この水準が続いていた。
定額化で変わったこと
コスト削減だけでなく、開発の行動パターンが変わった。
| 観点 | 従量課金時代 | 定額化後 |
|---|---|---|
| エージェント稼働時間 | コストを気にして制限 | 24時間常駐 |
| 実験・試行錯誤 | 「もったいない」で躊躇 | 気軽に試せる |
| サブエージェント起動 | 最小限に抑制 | 必要なだけ起動 |
| 月末の心理 | 請求額を恐れる | 固定なので気にしない |
従量課金では「1トークンも無駄にしたくない」というマインドになり、結果としてエージェントの活用幅が狭まっていた。定額化によって「とりあえず動かしてみる」が可能になり、エージェントの改善サイクルが加速した。
コスト削減のレイヤー構造
ここまでの施策を整理すると、コスト削減には3つのレイヤーがある。
レイヤー1: 課金モデルの選択（本記事）
従量課金 → 定額プラン = $600 → $100
レイヤー2: アーキテクチャ設計（本記事）
Brain/Runtime/Subagentの3層 = トークン消費を構造的に制御
レイヤー3: ト��クン単位の最適化（⑥の記事）
プロセスモデル変更 = cache_creation 95%削減
多くの記事はレイヤー3（プロンプト圧縮、キャッシュ最適化）の話をしている。それも重要だが、レイヤー1とレイヤー2を先に固めないと、枝葉の最適化に終わる。
幹を先に決めて、枝葉を後から刈る。 コスト最適化の順序として、これが実運用で得た結論だ。
レイヤー3の詳細——プロセスモデルをstream-json常駐方式に変えてトークン消費を95%削減した話は、⑥トークン最適化の記事に書いている。本記事と合わせて読むと、上位の設計判断からトークン単位の最適化まで一気通貫で理解できる。
まとめ
- 従量課金でAIエージェントを運用すると「動かすほど高い」悪循環に陥る
- 課金構造の転換（定額プランへの移行）が最もインパクトが大きい
- 定額プランの利用制限内で最大効率を出すには、設計レベルのトークン制御が必要
- Brain（判断のみ）/ Runtime（ノーコスト）/ Subagent（使い捨て）の3層構造が有効
- トークン単位の最適化は、課金モデルとアーキテクチャを固めた後にやる
$600から$100への削減は、テクニックではなく構造の転換で実現した。
関連記事・リンク:
- ⑥ トークン消費を95%削減した話 — 本記事のレイヤー3。プロセスモデル変更によるcache_creation最適化の詳細
- ai-agent-blueprint — Sentinelの設計テンプレート一式。Brain/Runtime/Subagentの3層構造もここに含まれる
- @sentinel_dev93 — AIエージェント開発のリアルタイムな学び
AIエージェントのコスト管理で苦労している方の参考になれば幸い。シリーズ他の記事も含め、フォローしてもらえると続きが届きやすくなる。
おわりに
この記事では、AIエージェントのAPI代を月$600から$100に削減した実践記録を紹介しました。AIエージェントのコスト削減で効果的だった方法があれば、コメントで共有してください。
参考になったら いいね、後で見返すなら ストック していただけると励みになります。
他にもAIエージェント構築のノウハウを公開しています：
- トークン消費95%削減 — コスト最適化の実践