0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

RTX 4070でローカルLLMの電気代を24時間計測した結果と、Claude Code Maxの本当のコスト比較

0
Last updated at Posted at 2026-06-04

RTX 4070ローカルLLMの電気代計測結果

「ローカルLLMはタダで動く」という言説をたまに見ます。

確かにAPI課金は発生しません。けれど、24時間動かしっぱなしのGPUは黙って電気代を吸い続けます。Claude Code Maxの月額 $200 (約¥30,000) と比較したとき、本当にローカルのほうが安いのか。私はこれを実際に計測してみるまで確信を持てませんでした。

この記事では、RTX 4070 + Ollamaで24時間連続推論を回し、SwitchBotプラグミニで電力を1分間隔で記録した結果を公開します。電気代単価は関西電力・東京電力・北海道電力の3エリアで計算し、稼働率10%/30%/50%/100%の4シナリオで Claude Code Max とのクロスオーバーポイントを示します。

結論を先に言うと、電気代だけ見ればローカルの圧勝でした。けれど、「同等の処理品質を得るための実コスト」という軸で見ると、勝者が逆転するシナリオが存在します。

検証設計

まず実験の前提を明示します。後から数字だけ拾われると都合のいい結論に持っていかれがちなので、設計から開示します。

ハードウェア

  • GPU: NVIDIA RTX 4070 (TDP 200W、VRAM 12GB)
  • CPU: Ryzen 7 7700 (TDP 65W)
  • RAM: DDR5-5600 32GB
  • 電源: 750W Platinum

ワットモニター: SwitchBotプラグミニ (1分間隔ログ)

ソフトウェア

  • OS: Ubuntu 24.04 LTS
  • Ollama: 0.5.4
  • モデル: Qwen3-Coder-14B (Q4_K_M)、Gemma-3-12B (Q4_K_M)、Phi-4-14B (Q4_K_M)

計測シナリオ

24時間連続で以下のループを動かします。

import ollama
import time

prompts = load_prompts("eval_set_500.jsonl")  # 500件の実コード生成タスク

while True:
    for p in prompts:
        ollama.generate(model="qwen3-coder:14b", prompt=p, options={"num_ctx": 8192})
        # 入力500トークン、出力1500トークン平均

500件を1セットとして、24時間ループ。総トークン量とランタイム電力を同時に記録します。

計測結果: PCの実消費電力

24時間ログから得られた電力プロファイルです。

状態 消費電力 (実測) 占有時間
アイドル (LLMなし) 約 65W 0% (24h推論)
推論中 (GPU使用率 95%+) 約 245W 約 92%
モデルロード中 約 180W 約 5%
待機 (リクエスト間) 約 90W 約 3%

24時間の平均消費電力は 約 232W でした。GPU公称TDP 200WにCPU 35W程度が乗り、システム全体としては200Wを越えます。

24時間の総消費電力:

232W × 24h = 5.568 kWh/日

月換算 (30日):

5.568 × 30 = 167.04 kWh/月

エリア別の月間電気代

3エリアの2026年5月時点の単価で計算します。

エリア 単価 (円/kWh) 月額電気代
関西電力 (従量Aの低圧) 22.67 ¥3,787
東京電力 (従量B 30Aの第3段階) 40.49 ¥6,765
北海道電力 (従量電灯B 第3段階) 45.43 ¥7,590

最大の北海道電力でも、24時間100%稼働で月¥7,590です。Claude Code Max ¥30,000/月の4分の1以下でした。

これは「PC全体」の消費電力です。GPU単独のTDP 200Wに加え、CPU・メモリ・ファン・電源変換ロスを含むホールシステム値です。「200W × 24h で計算したらいい」という単純化はGPU専用機ですら2割程度誤差が出ます。

稼働率シナリオ別の比較

「24時間100%動かす」のは非現実的です。実際の利用シーンに近い4シナリオで見直します。

稼働率 関西電力 東京電力 北海道電力 Claude Code Max
10% ¥567 ¥1,012 ¥1,135 ¥30,000
30% ¥1,239 ¥2,213 ¥2,482 ¥30,000
50% ¥1,911 ¥3,414 ¥3,829 ¥30,000
100% ¥3,787 ¥6,765 ¥7,590 ¥30,000

稼働率10%でもMaxの30分の1〜50分の1の電気代です。

「タダ」ではないことは確かです。けれど、Maxの月額に届くには、月3〜4台のRTX 4070を24時間動かす必要があります。普通の個人開発者には起きないシナリオです。

ところが、ここで話が逆転する

電気代だけ見ればローカルの圧勝です。

けれど、私はこれを公開する前に 「同等品質の処理を得るための実コスト」 の軸で見直しました。エンジニア向けのコスト比較で、ここを抜かすのはフェアではありません。

軸を「電気代」から「品質あたりコスト」に変える

Claude Code Max ¥30,000/月で得られるのは、Claude Sonnet 4.6 (またはOpus 4.7) の出力品質と高速レスポンスです。一方、RTX 4070のローカルLLMで得られるのは、Qwen3-Coder-14B 等の出力品質と RTX 4070性能の推論速度です。

両者は同等ではありません。

計測項目: 1タスクあたりの実所要時間

500件の実コード生成タスクで、それぞれの完了時間を比較しました。

環境 平均トークン生成速度 平均所要時間 (1タスク) 24時間で消化できるタスク数
RTX 4070 + Qwen3-Coder-14B (Q4) 約 22 tok/s 約 75 秒 約 1,150件
Claude Sonnet 4.6 (Max plan) 約 80 tok/s 約 20 秒 約 4,300件

Claude Sonnet 4.6 のほうが約 3.7倍 速いです。

機会損失を時給で換算する

エンジニアの平均時給を ¥4,000 (年収¥720万を想定) とします。

ローカルでの待ち時間が1タスクあたり55秒 (= 75 - 20秒) 多いとして、月100タスクを処理するなら:

55秒 × 100タスク = 5,500秒 = 約1.5時間
1.5時間 × ¥4,000/時 = ¥6,000/月の機会損失

月100タスクは私個人の体感では少なめです。日常的にAIに頼っているエンジニアなら月500タスクは普通に超えます。500タスクなら ¥30,000/月相当の機会損失です。

ここで電気代 (関電¥3,787) + 機会損失 (¥30,000) = ¥33,787 で Maxを上回ります

品質差は時間差より大きい

さらに、コード生成の品質差を加えると話がもう一段変わります。

ローカルLLMが Claude Sonnet 4.6 のコード品質に届かないタスクが一定の割合で発生します。「Claudeなら一発で通ったコードが、ローカルだとデバッグ往復が必要になる」というケースです。

私の体感では、Claude Code Max の場合に1発合格するタスクが、Qwen3-Coder-14B では2〜3回の再生成が必要になることがあります。再生成は3〜5倍の時間とトークン消費を意味します。

これは「Qwen3-Coderが悪い」という話ではありません。14BパラメータでClaude Sonnet 4.6 (推定数兆パラメータ) と勝負していること自体が驚異です。「同等」を求めるなら、土俵が違うと認識すべき、という意味です。

クロスオーバーポイント

ここまでの計算をまとめると、ローカル vs Max のコスト逆転は次の条件で起きます。

月間タスク数 ローカル総コスト (電気代+機会損失) Max総コスト 勝者
50 ¥3,787 + ¥3,000 = ¥6,787 ¥30,000 ローカル
100 ¥3,787 + ¥6,000 = ¥9,787 ¥30,000 ローカル
300 ¥3,787 + ¥18,000 = ¥21,787 ¥30,000 ローカル
500 ¥3,787 + ¥30,000 = ¥33,787 ¥30,000 Max
1000 ¥3,787 + ¥60,000 = ¥63,787 ¥30,000 Max

月500タスク前後がクロスオーバーポイントです。

私の結論

  • 月100タスク程度の軽い利用 → ローカルが経済的に圧勝
  • 月500タスク以上の重い利用 → Claude Code Maxが経済的にも逆転する
  • それ未満の中間域は「品質に対する許容度」で判断が分かれる

私自身は、Claude Code Max契約を継続しつつ、ローカルLLMは「APIに送りたくない機密データの処理」と「夜間バッチ」に限定して使い分けています。

正直に書くと、計測する前は「ローカル組んだしMax解約していいだろ」とちょっと思っていました。けれど数字を並べた結果、月500タスク超えで簡単に逆転することが見えて、解約は取り下げました。RTX 4070の購入費 (約¥100,000) を電気代で回収する計画は最初から崩れていた、ということです。

補足: APIの従量課金との比較

Maxではなく、Anthropic API従量課金 (Sonnet 4.6: input $3/M tokens, output $15/M tokens) と比較するケースもあります。

月500タスク (入力500トークン、出力1500トークン平均) の場合:

入力: 500 × 500 = 250,000 tokens → $0.75 (≒ ¥112)
出力: 500 × 1500 = 750,000 tokens → $11.25 (≒ ¥1,687)
合計: 約 ¥1,799/月

月500タスクなら API従量課金が圧倒的に安いです (¥1,799 vs Max ¥30,000)。

Maxが経済的に意味を持つのは、月数千タスク以上で API従量課金が ¥30,000 を超えるユースケースだけ、と言えます。

Anthropic Cookbookの料金計算ツール (api.anthropic.com/v1/messages/count_tokens) を使うと、自分の実プロンプトに対する正確なトークン消費が分かります。プランを選ぶ前に1ヶ月だけ従量課金で計測すると、適切なプランが見えてきます。

ローカルLLMが「圧勝」するシナリオ

電気代+機会損失の総額で見ると微妙な領域もありますが、ローカルLLMがほぼ無条件で勝つシナリオもあります。ここまで「ローカル不利」っぽい流れでしたが、ちゃんと勝てる場所はあります。

  1. 機密データの処理: 顧客の個人情報、社内コード、未公開ドキュメントを外部APIに送れないケース
  2. 大量バッチ処理: 何百万件のテキスト分類・要約をオフラインで処理する場合
  3. オフライン環境: 飛行機内、地方出張、サーバールーム内など
  4. 学習・実験: モデルの挙動を制御して再現可能な検証をしたい
  5. API停止リスクのヘッジ: クラウドサービスの障害・課金変更に対する保険

私の結論 (再掲)

ローカルLLMはタダではない。月¥3,000〜¥8,000の電気代がかかる。けれど、Claude Code Max ¥30,000/月との比較では、月500タスクが分水嶺になる。

この数値は、自分のユースケースを実測してから判断すべきものです。私自身、計測する前は「ローカルなら全部タダで済むのでは」と楽観していました。実際にSwitchBotプラグミニのログを並べてみて、ようやく自分のワークフローのコスト構造が見えました。

なお、私のローカルLLM検証パイプライン全体はClaude Code 完全ガイドでも詳しく紹介しています。Claude Codeとローカルモデルのハイブリッド運用、APIキー管理、検証スクリプトのテンプレートまで載せています。

まとめ

  • RTX 4070 + Ollama を24時間連続稼働させると、PC全体で平均232W (月167kWh)
  • 関電単価で月¥3,787、東電単価で月¥6,765、北電単価で月¥7,590
  • Claude Code Max ¥30,000/月と比較すれば、電気代だけ見ればローカルの圧勝
  • 「タダ」ではない (確実に毎月数千円かかる) のは事実
  • 同等品質の出力を得るための実コスト (電気代+機会損失) で見ると、月500タスク以上でMaxが逆転
  • 機密データ、大量バッチ、オフライン環境ではローカルがほぼ無条件で勝つ

「自分の数字を測れ」が結論です。電気代は5分でわかる。クロスオーバーポイントは1ヶ月実測すればわかる。SwitchBotプラグミニは3,000円弱で、計測の元は取れています。

面白くいきましょう。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?