24時間のAI開発でクラウド課金が増え続ける —— 判断と実装を自前のローカルLLMに移してコストを下げた

上原正吉（EarthLink Network Co., Ltd.）。Claude Codeを開発の主体に据え、20を超えるプロダクトを1人で同時に開発・運用しています。これは、その現場の実測記です。

24 時間の AI 開発でクラウド課金が増え続ける —— 判断と実装を自前のローカル LLM に移してコストを下げた

24 時間の AI 開発でクラウド課金が増え続ける —— 判断と実装を自前のローカル LLM に移してコストを下げた

2026 年 6 月末から 7 月にかけて、開発の実行基盤を自前のローカル大規模言語モデル(LLM)に組み替えました。きっかけはコストです。

AI に開発を任せるほど、タスクの振り分け判断も、実際のコード生成も、そのたびにクラウドの AI に投げることになります。24 時間止めずに回せば、その従量課金は毎月、使った分だけ積み上がります。しかも、毎月ずっと払い続けるものです。

そこで、一度ハードを買い、その先の実行を自前のローカル LLM に寄せることにしました。タスクの振り分け判断(この記事では「オーケストレーター」と呼びます)と実務の多くを、クラウドの AI から自前のローカル LLM へ移す。そのために NVIDIA DGX Spark を 1 台買い、手元の Mac 4 台と組み合わせて、開発タスクを流す実行基盤を作りました。実務は AI に任せ、人間は判断だけに残す。この配分を進めた先が、人がループの外に出る Human-Out-Of-The-Loop（HOOTL）です。

これは「◯◯円削減できた」という金額の証明ではありません。従量課金という継続コストを、設計で消せる分だけ消す。その組み方の記録です。

結論を先に置きます。

  • 継続課金を、設計で消せる分だけ消した — 判断も実務もまずローカルで受け、クラウドに出すのは本当に必要な分だけにした
  • 買う前に判断基準を ADR(設計判断の記録)で縛った — 「欲しいから買う」を排除し、速度の実測だけで購入を判断した
  • どのモデルをどこに置くかは、速度とコストの実測で役割ごとに決めた — 振り分け判断は 14B、実務のコード生成は課金ゼロの 72B レーン
  • 1 モデル 1 ホストで運用した — 載せ替えのコストを避け、ローカルとクラウドの分担を数字で見えるようにした

決めることは 3 つに絞られました。①自前ハードを買うか、買うならどれか。②どのモデルをどの仕事に置くか。③複数台をどう並べるか。順番に書きます。

期間はこう分かれます。購入の判断は、ベンチ結果だけで即決でした(2026 年 6 月末)。そこから DGX Spark が届いて(7 月 10 日)、基本形ができるまでが約 2 週間。そのあと、7 月下旬に障害が起きます。購入の判断からここまでで、約 1 か月の記録です。

買う前: 継続課金を消すために、まず「自前ハードを買うか」を実測で決めた

判断を自前のローカル LLM に寄せたい理由は 2 つあります。1 つは継続コスト。もう 1 つは、判断そのものを外部課金に依存させたくないことです。

振り分け判断は、24 時間動き続ける中心の処理です。ここをクラウド任せにすると、中心の処理のコストが使った分だけ毎月かさみ、外部サービスの都合で止まれば開発全体が止まります。だからオーケストレーターにはクラウド LLM を置かない。これは local-commander(この開発オーケストレーターの名前です)の設計原則にしています。

クラウドのコストは二つの形で開発を止めます。無料枠なら利用制限に達して止まり、従量課金なら使った分だけ積み上がる。どちらも、うちでは実際に起きています。組織の GitHub Actions は、無料枠の上限の疑いで 2026 年 4 月から止まりました。

試算もしました。CI を GitHub Actions の標準ランナー(Linux 2 コア・$0.008/分)で 2 台ぶん、稼働率を半分(1 日 12 時間)に見積もっても、月 約 ¥5.5 万。対して ci サーバーは 1 台 ¥13 万、2 台で ¥26 万の一度きりです。約 5 ヶ月で元が取れて、その先は継続課金がかかりません。

ただし、判断をローカルに寄せるには速度が要ります。手元の MacBook Pro (M3) で 31B クラスのモデルを動かすと、実効 5 tok/s、1 判断に 60〜200 秒。これでは 24 時間の自律運用に速度が届きません。

そこで、買う前に ADR(Architecture Decision Record。設計判断を残す文書)で判断基準を固定しました。

ADR-0003: DGX 購入判断は PoC(概念実証)ベンチマークの結果のみでゲートする

そのうえで 16 ケースの分類ベンチを実施しました。結果はこうです。

  • システムの最終分類は 16 件中 16 件一致(100%)、危険側の誤分類は 0 件(qwen3.6-35b)
  • ただしこの 100% は「LLM 単体が完璧」という意味ではありません。生 LLM の JSON 整形成功は 69%(fallback 31%)で、崩れた出力はコード側の決定的な安全オーバーライドが吸収し、最終判断を 100% に引き上げています。100% はモデルの賢さではなく、壊れても安全側に倒す仕組みの成果です
  • ボトルネックは速度だけ(M3 で 1 判断 60〜200 秒)

最終判断の正しさと安全性は、LLM が壊れてもコード側の安全規則で担保できます。足りないのは速度だけで、速度はハードで解決できる。この実測が揃った翌日、購入を決断しました。

ハードは一度買えば終わりです。その先の実行には、トークンあたりの課金がかかりません。毎月の従量課金を、一度きりの出費に替える。そのための買い物だと位置づけました。判断に使った PoC レポートと ADR は、すべてリポジトリに残っています。

届いた日: ssh して最初にやったこと

2026-07-10、DGX Spark が稼働開始。ssh dgx した最初のセッションがこれです。

DGX Spark に初 ssh したときのバナー（実端末画面・ホスト名/IP のみ匿名化）

GNU/Linux 6.17 の aarch64、ストレージ 3.67TB。届いた日から、モデル選定のベンチを回し始めていた

この記事の端末・ダッシュボード画像は、実際の画面から製品名・ホスト名・IP などの文字だけを匿名のダミーに差し替えたものです（レイアウト・数値は実データ、数値は検証済みのものだけ）。一部の画面はレイアウトを再構成した匿名図にしています。

このマシンは、毎月の従量課金を置き換える実行基盤の中心に据えるつもりで買った 1 台です。だから届いた初日から、local-commander を動かす前提でセットアップを始めました（最初に置いたのが、その初期起動を許可する .lc-bootstrap-allow というマーカー）。

選定: 「大きいモデルほど賢い」は分類では成立しなかった

DGX のメモリは 121GiB。72B クラスも余裕で載ります。ここでも実測で選びました。オーケストレーターの仕事(タスク分類)で 14B / 32B / 72B を同一ケースで比較した結果がこれです。

モデル分類精度1 判断の時間
qwen2.5-coder:14b100%4.4 秒
qwen2.5-coder:32b88%(中間)
qwen2.5:72b100%22.8 秒

14B と 72B が精度で同点、72B は 5 倍遅い。そして中間の 32B だけが JSON 整形の崩れで 88% に落ちるという結果でした。分類というタスクでは「大きいほど賢い」は成立しません。だからオーケストレーターは 14B に決めました。

では 72B は無駄か。いいえ。72B は、実務のコード生成を回す「課金ゼロの作業レーン」に回しました。実務をクラウドに投げれば従量課金がかかりますが、すでに DGX に載っている 72B で回せば、トークンあたりの課金はかかりません。

念のため補足します。72B を実務に回したのは「72B の方がコード生成で賢いから」ではありません。生成ベンチでは 14B と 72B は成功率 57% で同点、72B は約 6 倍遅く、一次資料でも「72B 昇格は見送り」と結論づけています。それでも 72B レーンを配線したのは、すでにハードに載っている資産を、トークンあたり課金ゼロで使い回せるからです。14B のほうが速いのに 72B を作業に回すのは、14B の Mac 4 台が分類でつねに埋まっていて空きがなく、DGX には最初から 72B が載っているからです(このホストの分け方は次章)。用途は local-ok(ローカルで安全に完結できると分類されたもの)の低リスクなタスクに限定し、失敗したらクラウド(Claude)へ昇格させます。この前提なら 72B の遅さは許容できて、課金のかからないレーンが 1 本増えます。

構成: DGX は 72B 専用機、Mac は 14B 分類機

最終的な構成は「1 モデル 1 ホスト」です。

  • DGX Spark: qwen2.5:72b (111.4GB) 専用機。トークンあたりの課金がかからない「作業レーン」として、低リスク(local-ok)のコード実装タスクを 6 並列で処理し、失敗時はクラウドへ昇格
  • Mac 4 台 (M4 / M3 ほか): qwen2.5-coder:14b の分類機プール。weighted ロードバランサ(重み付きで負荷を振り分ける仕組み)で束ねる。Apple Silicon は GPU とユニファイドメモリで、もともと LLM 推論に向く。そのうえ CI ランナーにもなり、iPhone アプリの割高なクラウドビルド(macOS ランナー)課金も浮く
  • クラウド (Claude / Codex): ローカルで完結しないタスクだけが、人間の承認ゲートを通って流れる
  • CI サーバー: 上記とは別に、オーケストレーター（local-commander）を止めないための CI サーバーも導入している（コストの試算は前掲）。可用性（HA）や構成の詳細は別記事で書く

この分け方の狙いは、継続課金がかかるクラウドに、本当にクラウドが要るタスクだけを流すことです。振り分け判断も実務も、まずローカルで受ける。ローカルで完結しない分だけが、クラウドに出ていきます。

これを管理画面で見ると、こうなります。

local-commander の実行レーン画面

実行レーン: クラウド (Claude) は待機、分類 14B は Mac 4 台が全機 busy、作業 72B (DGX) も待機。振り分けの判断だけが絶え間なく動いている

1 台に複数モデルを載せない理由は単純です。モデルの載せ替え(ロード/アンロード)が一番高くつくからです。Grafana(計測結果を可視化するツール)で tok/s を常時計測すると、DGX 24.27 tok/s、M4 16.09 tok/s。この数字を見ながら、「どのタスクをどのレーンに流すか」を勝率とコストで決める配分表を育てています。

運用: 管理画面で見る 24 時間

構成が形になると、開発タスクは受信箱(INBOX)に流れ込み、振り分けられ、各レーンで実行され、PR(プルリクエスト)になって複数のレビューゲートを通り、人間の承認を待ちます。この流れが 24 時間回り始めます。

INBOX とプロダクト別キュー、直近 24H の INSIGHTS

ある日の実行状況: 判断待ちが積み上がり、複数プロダクト分のキューが並ぶ。直近 24 時間で 237 万トークン・ジョブ 102 件・参考換算で約 $15.76

直近 24 時間で 237 万トークン、ジョブ 102 件。管理画面に出る $15.76 は、登録済みの単価表(token-rates.json)から算出した 24 時間分の参考換算額であって、クラウドの実請求額そのものではありません(単価不明のモデルが混ざると、既知分だけの下限値になります)。

この $15.76 には、72B レーン(DGX)で回した分が一切乗っていません。継続課金がかかるのは、クラウドに出したタスクだけです。ローカルで受けた分は、トークンあたりの課金がかかりません。

もちろん、DGX のハード代と電気代は別にかかります。ゼロ円で動いているわけではありません。ただ、使った分だけ毎月増えていく従量課金を、一度きりのハード代と固定的な電気代へ置き換えられた。その分担が数字で見えるようになったことが、この基盤を組んだ収穫です。

順調なことばかりではありません

7 月下旬には、分類クラスタが連鎖的に止まりました。肥大した分類プロンプト(4,251 トークン)にリトライが集中し、1 ノードの 4 スロットが全部 37 秒の直列キューになって沈黙。真因にたどり着くまで、ダッシュボードの読み違いで 3 日誤診しています。対策は co-primary 化(2 ノードにトラフィックを 50/50 で分散する)と、プロンプトの bounded 化(サイズに上限をかける)です。

これはクラウドの従量課金が暴走した障害ではありません。一度買ったハードの上で、自分が起こして自分で直せる障害です。課金を気にせず真因を追えたのは、実行を自前に寄せたことの副産物でもあります。障害の詳細は別記事で書きます。

まとめ

  • 継続課金を、設計で消せる分だけ消す — 判断も実務もまずローカルで受け、クラウドに出すのは本当に必要な分だけにする。毎月の従量課金を、一度きりのハード代へ置き換える発想
  • 買う前に判断基準を ADR で縛る — 「欲しいから買う」を排除し、速度の実測だけで購入を判断した
  • モデルは役割ごとに実測で選ぶ — 振り分け判断は 14B で十分(72B と精度同点で 5 倍速い)。32B だけ劣化する罠もある。実務のコード生成は、課金ゼロの 72B レーンに限定して回す
  • 1 モデル 1 ホストで運用する — 載せ替えコストを避け、tok/s を常時計測して配分を決める
  • 記録を残す — ADR・ベンチレポート・ポストモーテムが全部リポジトリにあるから、この記事が書ける

この置き換えの根っこにあるのは、実務は AI に回し、人間は最終承認=判断に専念する、という進め方です。いまは承認ゲートに人が残る Human-in-the-loop（HITL）で、その承認まで仕組みに寄せていけば、人がループの外に出る HOOTL に近づきます。判断の中心(オーケストレーター)を自前に置いて外部の従量課金から切り離すのは、その土台を安く、長く回すための一手でした。

筆者について

上原正吉。EarthLink Network Co., Ltd. でAI開発をしています。2025年からClaude Codeを開発の主体に据え、今は20を超えるプロダクトを1人で同時に開発・運用しています。この連載では、その現場で実際に起きたこと（うまくいったことも、失敗も）を、数字と一緒に書いていきます。

また、AIで業務や開発を組み替えたい会社・チーム向けに、AI活用のコンサルティングも受け付けています。ご相談は www.eln.ne.jp からどうぞ。