月 5 万円の定額で 24 時間ループを回す — サブスクの上限を最外周の停止条件にする【v0.39.1】

📖 はじめに — AI コスト、どこで歯止めをかけるのか

AI コーディングの費用が予算を超えた、という話をよく見かけるようになった。あるスタートアップの共同創業者は、1 か月で約 3 万ドルの AI トークンを消費したと語っている。原因は、高速だが単価の高いモードをオンにしたままにしていたことだった。大手企業が年間の AI 予算を 4 か月で使い切った、という報道もある（こちらは二次報道で、発言の一次資料は確認できていない）。

当社は、ループエンジニアリングで長時間の開発ループを回している。1 つのセッションが 49 時間続いたこともある（第 18 回）。それでも、AI の費用は開発者 1 席あたり月約 5 万円である。

金額は 2026 年 10 月時点の当社の契約額である。どちらも公式クライアント（Claude Code と Codex CLI）を、プランの範囲で使っている。

先に結論を書く。

定額プランの上限は、最も外側の停止条件である。 使いすぎたときに起きるのは請求の増加ではなく、待ち時間になる。その内側で、2 つの枠に負荷を分け、モデルを使い分け、run（Codex やワークフローの 1 回の実行）の重さを起動前に測る。

上限に達する週もある。10 月 2 日（金）は 9 時に上限に達し、22 時のリセットまで 13 時間止まった。ただしこれは、週 7 日・24 時間で回した場合の話である。1 週間 168 時間のうち、155 時間は回っていた。本稿は、その限界も含めて記録する。

🛑 サブスクの上限は、AI コストの最も外側の停止条件

第 15 回と第 16 回で、ループの停止条件を機械の側に置く話を書いた。周回の上限、進捗なしの検出、大きい run の起動前承認。どれも「止める判断を AI に任せない」ための仕組みだった。

費用にも同じ構造がある。従量課金は、止める仕組みを自分で用意しない限り、使った分だけ請求が増える。定額プランは、上限に達すると使えなくなる。止まる場所が、契約の時点で決まっている。

ただし、定額プランにも、上限を超えて使う仕組みはある。Claude には使用量の追加購入があり、Codex には上限を超えて使うためのクレジットがある。当社はどちらも使っておらず、Codex の追加クレジットは 0 のままにしている。追加購入を自動にすれば、この停止条件は外れる。上限を「止まる場所」にしているのは、契約そのものではなく、追加しないという自分たちの決定である。

冒頭の 3 万ドルの事例は、設定 1 つを変えただけで解決したと報じられている。問題は設定の誤りそのものではなく、誤りが、気づくまでそのまま請求に積み上がったことにある。外側に停止条件があれば、同じ誤りは「今週は早く上限に達した」で済む。

これは従量課金を否定する話ではない。上限を自分で設計できるなら、従量課金でも同じことができる。言いたいのは、費用にも停止条件が要る ということだ。

💴 同じ量を API の定価で払うと、いくらになるか

定額の枠でどれだけの量を回しているのかを、API の定価に換算した。対象は cts-ec の 1 プロジェクトだけ、期間は 2026-09-28 から 10-04 までの 7 日間である。

月約 5 万円の契約に対して、定価換算は約 35 倍になる。

換算の方法

• Claude 側: Claude Code のセッション記録には、応答ごとに入力、キャッシュ書き込み、キャッシュ読み取り、出力のトークン数が残る。サブエージェントの記録も含めて集め、メッセージ ID で重複を除き、モデルごとの定価を掛けた
• Codex 側: ハーネスが run のたびに書く台帳（入力、キャッシュ入力、出力）に、モデルごとの定価を掛けた
• 単価: 2026-10-04 に公式の料金情報で確認した。100 万トークンあたり、Fable 5.1 が入力 10 ドル・出力 50 ドル、Opus 5.5 が 4 ドル・20 ドル、Sonnet 5.5 と Sonnet 5 が 2 ドル・10 ドル、Haiku 4.5 が 1 ドル・5 ドル。GPT-5.6 Sol が 4 ドル・20 ドル、Terra が 2 ドル・12 ドル。キャッシュの読み取りは、Fable 5.1 が 0.25 ドル、Opus 5.5 と Sonnet が 0.20 ドル、Haiku 4.5 が 0.10 ドル。キャッシュの書き込みは、入力単価の 1.25 倍（保持 5 分）または 2 倍（保持 1 時間）で計算した。Codex のキャッシュ入力は、Sol が 0.40 ドル、Terra が 0.20 ドルである

この数字の限界

1. 「同じ量を定価で払ったら」という仮定の計算である。 従量課金なら使い方を変えるはずで、実際の請求額の予測ではない
2. 量は控えめに出ている。 cts-ec 以外のプロジェクト、台帳を通らない Codex の直接実行、途中で打ち切られて台帳に残らなかった run は含んでいない
3. 為替と単価は変わる。 1 ドル 150 円で換算した。プランの上限や価格も、ベンダーの判断で変わる

🔀 Claude Code と Codex で枠を 2 つに分ける — クロスファミリーは費用にも効く

当社は、実装を Codex に、仕様とテストと検証を Claude に分けている。もともとは品質のための分業だった（設計編）。同じ分業が、費用の面では 負荷を 2 つの定額枠に分ける 働きをする。

2026-10-04 の夕方、両方の利用状況はこうなっていた。

Claude は、週の開始から約 2 日で 38% を使い、「このペースだと水曜の夕方に上限に達する」という警告が出ている。Codex は 80% が残っている。

運用はこうしている。

• 平時: Codex が実装と調査、Claude が指揮と検証を担う。49 時間のセッションでは、Codex の実装 run が 93 本、調査 run が 17 本走った
• Claude の枠が切れそうなとき: 調査や下書きを Codex（Sol または Terra）へ寄せて、Claude の消費を抑える
• それでも足りないとき: 止まる。10 月 2 日（金）は、9 時から 22 時まで止まった

運用者の実感として、Codex の枠には比較的余裕がある。第 10 回で「遊休 90% の枠に仕事を振る」と書いた状況は、形を変えて今も続いている。

🎚️ 枠の中の適材適所 — 規則と判断を分ける

枠の中では、モデルを使い分ける。ここには、機械が守る規則と、人が決める判断の 2 層がある。

規則になっているもの

サブエージェントのモデルは、エージェント定義に固定してあり、台帳との食い違いは機械が検知する。

Codex の側も、段ごとの既定が決まっている。

判断に任せているもの

主セッション（人が直接操作するセッション）のモデルは、規則ではなく人が決める。壁打ち、パイプラインの失敗の原因分析、ステアリングの作成、バグ修正と、その時の難しさに応じて Fable 5.1、Opus 5.5、Sonnet 5.5 を切り替える。49 時間のセッションでは、長いループを Sonnet 5.5 で回し、失敗の原因分析で Fable 5.1 に上げ、ステアリングの修正で Opus 5.5 を使い、ループに戻るときに Sonnet 5.5 へ戻していた。

数字に出た結果

Claude 側の定価換算の内訳は、次のようになった。

換算額の大半は、単価の安い Sonnet によるものである。Fable 5.1 の入力単価は Sonnet の 5 倍なので、長いループを最上位モデルで回していれば、この表はまったく違う形になる。

1 つ、正直に書いておく。「選択投入」の枠は、サブエージェントとしては一度も使われていなかった。9 月 1 日から 10 月 4 日までのサブエージェント起動 926 回に、モデルを指定した起動は 0 回である。Fable 5.1 が動いているのは、人が主セッションで選んだときだけだった。

⚖️ コストは単価ではなく、run の重さで決まる

モデルの単価を下げるより効いたのは、1 回の run を重くしないことだった。9 月後半からの実測を並べる。

消費が 9 倍になった原因は、単価ではなかった

9 月 19 日から 25 日の週、cts-ec の Codex 消費は前の週の 9 倍、約 6.4 億トークンになった。原因を分解すると、モデルの単価ではなく次の 2 つだった。

• run の本数が、1 日 14 本から 58 本に増えた
• 1 run の重さが、中央値で 30 万トークンから 434 万トークンに増えた

消費の 63% はキャッシュ入力、つまりターンごとの再送だった。それまでハーネスは実効モデルしか記録しておらず、この増加は機械では見えていなかった。v0.36.0 で、run ごとの総トークンを台帳に書くようにした。

設定が黙って書き換わり、6 日間 2.5 倍で走った

共有の設定ファイルのモデルが、いつの間にか Sol から最上位の Astra に書き換わっていた。cts-ec の実装 16 run が、単価 2.5 倍のまま 6 日間走った。実行後の記録には残っていたが、誰も突き合わせていなかった。記録は検出ではない。 v0.35.0 で、Codex を起動する前に設定のモデルを期待値と突き合わせ、食い違えば止めるようにした。

調査を Terra に下げた

調査の run は、実装の 2 倍の重さがあり、30 本中 27 本が既定の Sol で走っていた。v0.36.0 で調査の既定を Terra にした。その後の実測では、調査 1 run の消費はクレジット換算（Codex の消費単位）で 110 から 36 へ、67% 減った。所要時間の中央値は 13.0 分から 12.6 分で、遅くなっていない。

巨大な run を、起動前に止める

10 月 1 日、ある実装タスクの Codex run が、ツール呼び出し 619 回、コンテキスト圧縮 10 回、編集 149 ファイル、build 44 回、test 39 回、約 5,634 万トークンを使い、2 時間の上限で打ち切られた。続きの run と合わせて、この 1 タスクで週の利用率が 10 ポイント上がった。

ハーネスの規則は「タスクは小さく」という散文だけで、検査が無かった。v0.39.0 で、次を入れた。

• 編集するファイルの宣言を必須にした。 宣言が無い、または 30 ファイルを超える呼び出しは、Codex を起動する前に止まる。クレジットは使わない
• 着手前の見積もりを用意した。 シンボルの参照箇所を数えて、ビルドプロジェクト別に集計するスクリプトを足した
• 打ち切りを内側に置いた。 時間で打ち切るとき、変更は残したまま台帳と申し送りを書いて終わる。続きは、残りを範囲にした新しい run にする
• 打ち切られた run も台帳に残す。 外から止められた run も、消費を読んで 1 行書く

第 16 回の原則「承認はクレジットを使う前に置く」「再開経路の無い停止は入れない」を、Codex の実装 run に適用した形である。

分割を始めた後の cts-ec の実装 run 98 本（10 月 1 日〜4 日）では、ツール呼び出しが 120 回を超えた run は 0 本、圧縮が 2 回以上の run も 0 本だった。中央値はツール呼び出し 28.5 回、編集 7 ファイルである。台帳の 1 run あたりの中央値は、直前の 2 日間（9 月 30 日と 10 月 1 日）の約 310〜350 万トークンに対して、その後の 3 日間は約 110〜170 万トークンだった。ただし日ごとのばらつきは大きく、9 月 28 日にも約 100 万の日がある。

🔭 上限に達するのはどんなときか — 正直な限界

良い数字だけを並べると、誤解を生む。限界も書いておく。

1. 上限に達するのは、週 7 日・24 時間で回し続けた場合である。 上の画面のペースなら、金曜 22 時のリセットから水曜の夕方まで、約 116 時間回せる。稼働時間で比べると、週 40 時間（1 日 8 時間 × 5 日）の勤務の約 2.9 倍で、最初の 2 日（48 時間）で 40 時間を超える。水曜に止まっても、木曜と金曜を休みと考えれば週休 2 日と変わらない。上限が問題になるのは、週 7 日フルで回す場合に限られる。壁打ちやローカルでの部分修正を混ぜている週は、概ね範囲に収まる。なお 116 時間は画面の警告から計算した見込みで、ペースは作業の内容で変わる。比べているのは稼働時間であって、成果の量ではない
2. 止まる週がある。 10 月 2 日（金）は 9 時に上限に達し、22 時まで 13 時間止まった。1 週間 168 時間のうち 155 時間は回り、残りの 13 時間だけ止まったことになる。定額の代償は、この待ち時間である
3. 1 日の総消費は、大きくは下がっていない。 分割で 1 run は軽くなったが、10 月 3 日は 45 本走って合計約 9,460 万トークンだった。調査を Terra に切り替えた後に測った週の利用率の伸びも、約 10% の減少にとどまる
4. v0.39.0 の効果は、まだ測れていない。 2026-10-04 の時点で、cts-ec は v0.38.0 のままである。分割後の数字は、cts-ec が先に運用で始めた規則の結果で、v0.39.0 はそれを共通化した版にあたる。配布後の実測はこれからだ
5. 1 席の話である。 この費用は開発者 1 席あたりで、組織全体に同じ形が当てはまるとは限らない。プランの上限、価格、提供条件は変わる

🧾 まとめ

• 当社の AI 費用は、開発者 1 席あたり月約 5 万円の定額である。同じ量を API の定価で払うと、cts-ec の 1 プロジェクトだけで月約 176 万円、約 35 倍になる
• 定額プランの上限は、追加購入をしないと決めている限り、最も外側の停止条件として働く。使いすぎたときの結果は、請求ではなく待ち時間になる
• クロスファミリーの分業は、負荷を 2 つの枠に分ける。片方が切れそうなら、もう片方へ寄せる
• 枠の中では、サブエージェントと Codex の段は規則で、主セッションは人の判断でモデルを使い分ける。Claude 側の換算額の約 85% は Sonnet によるものである
• コストに最も効いたのは単価ではなく、run の重さだった。消費 9 倍の原因分解、設定の書き換わりの検出、調査の Terra 化、巨大 run の起動前停止を、2 週間で入れた
• 週 7 日・24 時間で回すと、画面のペースでは約 116 時間で上限に達する。稼働時間では、週 40 時間の勤務の約 2.9 倍にあたる。10 月 2 日までの 1 週間は、155 時間回って 13 時間止まった

費用にも、停止条件が要る。 止まる場所を先に決めておけば、失敗は請求ではなく待ち時間になる。そして待ち時間は、枠の分け方と run の重さで短くできる。

📚 シリーズ記事（ステアリング駆動開発・応用編）

第I部: クロスファミリー検証（全 6 回）

1. 総論 — マルチ LLM の 2 系統と見取り図
2. 裏取り編 — +18.1pt 論文の検証
3. 設計編 — finder/verifier 分業と逆順禁止
4. TDD×ハーネス編 — テスト保護と三層ゲート
5. 実装編 — Claude Code の中から Codex を動かす
6. モデル戦略編 — ティア割当と「買うか組むか」

本編終章

7. クロスファミリー検証の最終型 — 自分で正しさを測り直す

運用実録

8. CI テスト 29 分 → 5.6 分 — 検証エンジンの平時運用
9. GPT-5.6 sol 切替 — もう一つのデフォルト追従
10. 遊休 90% の枠に仕事を振る — Codex 上流調査と verifier バッチ化
11. ハーネスが単一プロジェクトを卒業する — プラグイン化と二層配布
12. 69分で5リリース — Opus 5 当日対応が暴いた共通ハーネスの死角

現在地と事業展開

13. 「最高品質ですか？」に Yes と答えないハーネス
14. 二度の「1か月」を繰り返さない — 技術的負債から育てる AI 駆動開発ハーネス【サービス化への現在地】
15. ステアリング駆動開発を、ループエンジニアリングで包む — 人の注意力で止めるから、機械の停止条件で止めるへ【v0.32.0】
16. 3 日で撤回した停止条件 — ループエンジニアリングは「止まった後」から設計する【v0.33.1】
17. 月 5 万円の定額で 24 時間ループを回す — サブスクの上限を最外周の停止条件にする【v0.39.1】（本記事）
18. 49 時間ループの実録 — ループエンジニアリング、いよいよ v1.0.0 前夜【v0.39.1】

関連記事

• 遊休 90% の枠に仕事を振る — 2 つの定額枠の偏りを、仕事の振り分けで埋めた実録
• モデル戦略編 — ティア割当の考え方と「買うか組むか」
• 3 日で撤回した停止条件 — 承認をクレジットを使う前に置く、という原則の出所

関連用語

• ループエンジニアリング — エージェントを回すループそのものを設計する手法
• ハーネスエンジニアリング — ループが繰り返し起動する対象となる制御レイヤー

参考リンク（2026-10-04 時点で確認）

• 1カ月3万ドルのAIトークン代の原因は、Claudeの設定のせいだった（Business Insider Japan、2026-07-27） — 冒頭の事例の出典
• Uber Spends Full 2026 AI Budget in 4 Months（Briefs、2026-04-17） — 二次報道。発言の一次資料は確認できていない
• Pricing（Anthropic 公式ドキュメント） — Claude の各モデルとキャッシュの定価
• OpenAI API Pricing — GPT-5.6 Sol / Terra の定価
• Loop engineering: Getting started with loops（Anthropic 公式ブログ） — トークン管理の原則