Claude が要らない作業を安いモデルに移す——217件の実測で17倍のコスト削減

Last updated at 2026-06-18Posted at 2026-05-05

Claude が要らない作業を安いモデルに移す。 217 件の実測で 17 倍のコスト削減 (5/5 海外投稿の検証)

TL;DR

海外の利用者が 3 週間で 217 件の機械的な作業を、 Claude (Sonnet) から DeepSeek V4 Flash に移譲した。合計の出費は 0.41 ドル、同じ作業を Sonnet で行うと約 7 ドルの見立て。全体の比は約 17 倍のコスト削減。
投稿者の中核の気づきは「Claude の利用の大部分は、そもそも Claude が要らない作業だった」こと。ファイルの分類、 JSON の整形、文書の要約、文字列の抽出。全部、安いモデルで足りる。
効いた仕組みは MCP サーバ 1 つ + CLAUDE.md の 1 行の否定形のルール。「これらに Claude を使うな」の表記は、「これらに DeepSeek を使え」の表記より確実に効いた (肯定形は 30 % の頻度で無視される)。

元の投稿

5 月 5 日朝、 Reddit の r/ClaudeAI に petburiraja さんの投稿が出た。タイトルは「Most of my Claude usage was on work that didn't need Claude. Cut my bill 60x on bulk tasks with a tiny side model.」。投稿時点で 81 票、 17 件の返信。

投稿者は最初に普通の対策を試している。

Haiku への切り替え (大量の作業では依然として無駄)
短いプロンプト (少しは効く)
/compact (問題を先送り)

これらは出費の形を変えなかった。効いたのは、別の安いモデルを「副の作業者」として動かして、 Claude には機械的な作業をやらせない設定だった。

何を移譲したのか

3 週間の実測の数字。

217 件の機械的な作業
DeepSeek の合計の出費: 0.41 ドル
同じ作業を Sonnet で行うと約 7 ドルの見立て
比は約 17 倍

「機械的な作業」の中身は次のようなもの。

ファイルの分類 (拡張子や中身の判定)
JSON の整形
文書の要約 (どうせ斜め読みするやつ)
文字列の特定の項目の抽出

どれも Sonnet の判断の力は要らない。同じ料金で動かしているのが「無駄」の正体。

仕組みの構造

道具は 1 つの MCP サーバだけ。 arizen-dev/deepseek-mcp (MIT、 Python 3.10+)。既定は DeepSeek V4 Flash (1M の文脈の窓、安価)。設定の 1 行で、 OpenAI 互換のどの場所でも使える。ローカルの ollama、 vllm、 lm studio も含む。

利用の形は「監督つきの作業者」。道具の呼び出しもファイルの読み書きもチェーンも無い。入力はテキスト、出力もテキスト、結果は人間が確認。待ち時間は 3 から 25 秒。これだけ。

要するに、別のエージェントではなく、 Claude が「機械的な作業の下請け」として呼び出す相手。 Claude 側は判断と統合に集中し、副の作業者は単純な作業を量で処理する。

CLAUDE.md の中の効くルール

投稿者の発見で最も実用的だったのが、 CLAUDE.md の指示の書き方の話。

肯定形 (「DeepSeek をこれらに使え」) は約 30 % の頻度で無視された。一方、否定形 (「Claude をこれらに使うな」 + 対象の一覧) は確実に効いた。

中身の例:

# 作業の振り分けのルール

次の作業に Claude を使わない。 deepseek-mcp に渡す。

- JSON や YAML の整形と pretty print
- 複数のファイルからの構造化された項目の抽出
- 私が斜め読みする予定のドキュメントの要約
- 拡張子や見出しによるファイルの分類
- 単純な文字列の置き換えの一括処理

判断や設計や統合の作業は Claude が行う。

否定形の効果は経験則だが、 5/5 朝の検証で具体の数字つきの実例として確立された。 Claude Code の利用の最適化の重要な発見。

なぜこの構造が効くのか

Claude Code は 1 つのモデルで全ての作業を扱う前提で出来ている。これは便利な一方で、「全ての作業に Sonnet (または Opus) の料金が乗る」という構造の問題を生む。機械的な作業の量が増えるほど、出費が判断の質に対して不釣り合いに膨らむ。

副の作業者の構造は、この問題を「役割の分割」で解く。 Claude は判断、副の作業者は実行。役割が分かれているので、同じ料金体系の中で価格性能が異なる作業を併走できる。

これは Migration Playbook の中で「Path B (併用)」と呼んでいる経路の現代の代表例。留まる (Path A) でも乗り換える (Path D) でもなく、 Claude を残しつつ機械的な作業を別の場所に流す。 4 月から 5 月にかけて、 Anthropic の値段の変更や週次の枠の構造の変更で、この経路の重みが上がっている。

自分が試す時の判定の点

petburiraja さんの数字は、投稿者の利用の形 (機械的な作業が多い) に依存している。 Claude の利用が全部判断の作業の場合は、削減の余地は小さい。

事前の確認で見るべき項目:

直近 1 週間の Claude のやりとりの中で、機械的な作業 (前掲の 5 種類) が何割を占めるか
それらの作業の手元での処理時間が 3 から 25 秒の待ちを許せるか (副の作業者の応答時間)
機械的な作業が「監督つき」で十分か、それとも結果を盲目的に使う必要があるか (盲目的は危険)

3 つとも該当するなら、副の作業者の構造は試す価値がある。設定の手間は 30 分から 1 時間ほど。

道具の代替

DeepSeek 以外の選択肢も実用の段階にある。

ローカルで動かす場合: ollama + Qwen2.5-Coder 7B か Llama 3.3 8B (CPU でも遅いが動く、 GPU なら速い)
別のクラウドの場合: Groq の Llama 3.3 70B (速度の優位、出費は DeepSeek より少し高い)
OpenAI 互換が無い場合: arizen-dev/deepseek-mcp の代わりに自前で MCP サーバを書く

deepseek-mcp の場合、設定の 1 行を変えればどれにでも切り替えられる。まず DeepSeek で動かして、用途が固まった段階で価格と速度の都合で乗り換えるのが現実の手順。

5/5 朝の市場の他の合図との関係

同じ朝の Reddit で、別の利用者の投稿 (1,665 票) も「Claude を要らない作業に使わない」系の主題だった。加えて、海外の話題の集まりの上位で「軽い書き方と本番の現実の乖離」の話題が 2,609 票を獲得し、半日で +222 票の継続の伸びを見せている。つまり、「Claude を全てに使う運用は本番では破綻する」という認識が、 5 月初めの英語圏で同時に複数の場所で広がっている。

5 月 5 日の時点で、副の作業者の構造は「実用的な手段」として認識される段階に来た。試すなら今が早い時期。