DeepSeek V4が$5で同じコーディングタスクをこなせるなら、 なぜ$100払ってClaude Codeを使う人がいるのか？
Redditのr/DeepSeekで、こんな問いが投げかけられました。
投稿は約300のupvoteを集め、多くの議論を呼んでいます。
コスト差が20倍もあれば、安い方を選ぶのが合理的に見えますよね。
しかし、開発者たちの返答はもっと込み入ったものでした。
本記事では、このスレッドで交わされた意見を整理します。
そして、コーディングAIの選び方に関する本質的な視点をお伝えします。
価格差を正当化する核心：誰のためのツールか
最も支持を集めたコメントには、印象的な対比がありました。
DeepSeekは「あなたを良い開発者にするためのツール」。
一方のClaudeは「あなたを開発者にするためのツール」。
この違いです。
つまりDeepSeekを使うには、自分が何をやっているか分かっている必要があります。
モデルを誘導し、出力を検証し、不足を補う知識が要るからです。
一方、ClaudeのOpusは違います。
こちらが細かく指示しなくても、考えて実装してくれる。
そう評価されていました。
別のコメントには、こんな要約がありました。
「Opusはバイブコーダー（雰囲気で書く人）に優しく、DeepSeekはデバッグが必要」と。
ただし同じ書き込みで「とはいえ$5と$100の差は大きい」とも付け加えていました。
ここから見えてくるのは、価格差の本当の意味です。
$95の差額は、AIに知能を肩代わりさせるか、自分の知能で補うかの違いを表しているわけです。
ハーネスという見落とされがちな要素
価格議論の中で頻繁に登場したのが「ハーネス（harness）」という言葉でした。
ハーネスとは、AIモデルとやり取りするインターフェースとエージェント機能のセットを指します。
Claude Codeは、Anthropicが自社モデル向けに統合した環境を提供しています。
一方、DeepSeekにはこうした純正環境がありません。
そのため、OpenCodeなどの外部ハーネスと組み合わせて使うのが一般的だと書かれていました。
ある投稿者は、「OpenCode + OpenSpecs + DeepSeek + serena」のような構成を日常的に使っていると共有しています。
共通認識はこうです。
「優れたハーネスと良いエージェントフローがあれば、DeepSeekでもClaudeに近い結果が出る」と。
ただし、この主張にも例外なく「自分が何をしているか分かっていれば」という条件がつきます。
別の投稿には、こんな指摘もありました。
ハーネスは開発者の能力を代替するものではない。 あくまでインターフェースとエージェントの機能セットであって、 プログラマーの実力を肩代わりするわけではない
5モデルを実際に比較した開発者の証言
特に詳細だった共有を一つ紹介します。
GitHub Copilot CLI経由でOpus 4.6〜4.7を使い込んでいた人の体験談です。
トークン課金への切り替え発表をきっかけに、代替を探し始めたとのこと。
そして最終的に、Opus 4.7、GPT-5.5、DeepSeek V4 Flash、DeepSeek V4 Pro、Kimi K2.6の5モデルを同じタスクで比較したそうです。
評価項目は、機能追加、デバッグ、コードレビューといった共通の作業でした。
結果はこうです。
- Kimi K2.6は実用には早い。ミスが多すぎる
- DeepSeek V4 Flashは速くて指示通りに動くが、自分でニュアンスを掴む力が弱い
- GPT-5.5は期待ほどではなく、DS Flashよりわずかに良い程度
- Opusは別格。問題の根本原因を即座に特定し、信頼できるコードを出す
- 意外な伏兵がDeepSeek V4 Pro（Max reasoning）。Opusの代替候補として現実味がある
この人の結論はこうです。
「V4 ProはOpusの80%くらいの能力」と。
AGENTS.mdの指示を調整する必要はあったとのこと。
それでも、現在のワークフローはきれいに落ち着いたそうです。
V4 Proで作業→V4 Proでレビュー→修正→Opusで最終レビュー、という流れです。
そして「Opusは8〜9割のケースでV4 Proの作業とレビューを承認する」と書かれていました。
つまり、実務で回るレベルまでコストを下げられる、という具体的な証言です。
複雑な仕事になるほど差が広がる
「DeepSeekはまだClaudeのレベルではない」という意見も目立ちました。
特に大規模なシステムでは、DeepSeekは混乱しやすいと指摘されています。
たとえば数千ファイルにまたがる変更や、GrafanaやPrometheusのログを横断する調査などです。
データ量が多くなると追従できなくなる、と。
別の投稿者は、具体的な実験を共有していました。
ClaudeとOpenCode上の4モデル（DeepSeek Flash/Pro、GLM 5.1、Qwen 3.6 Plus）に、同じGitHubのissueを修正させてみたそうです。
結果、根本原因を直したのはClaudeだけ。
他のモデルは「修正した」と主張するものの、実際にはガムテープで貼り合わせるような対症療法しかしていなかったとのことでした。
このスレッドの別の人は、もっと辛辣でした。
「DeepSeekはコードやアイデアをザッと出すのには良い。しかし、最後の仕上げと整理はClaudeかGPTにやらせる必要がある。同じ土俵にはない」と。
一方で「DeepSeekで十分」という声も
逆の体験談もちゃんとあります。
WordPressのページを静的なHTML/JS/CSSに変換する作業の話です。
DeepSeekは$1で素早く仕事を終えたそうです。
一方、同じ作業をClaude Sonnet 4.6にやらせたら、Proプランのクレジットを使い切ったうえ、追加で$15かかった、と。
しかも、何度も指示し直す必要があったとのことでした。
別の投稿者は、Flashモデルで月に8.9億トークン使ったそうです。
それで費用は$12だったと書いていました。
「DeepSeekに$100払えばほぼ無制限に使える。$100払ってClaudeを使うなんてあり得ない」と。
タスクの性質と使う人のスキル次第で、コスパの正解は変わるということです。
「時間 vs お金」というトレードオフ
議論の中で繰り返し出てきたのが、開発者の時間の価値という観点でした。
「高給のエンジニアが月$500のトークン代で生産性が1.5〜2倍になるなら、大した出費ではない」というコメントがありました。逆に、ヘビーユーザーや利益率の薄い案件をこなす人にとっては、DeepSeekのようなオープンモデルの方が合理的だと。
もっと厳しい視点もあります。
「優秀な開発者にとって、レベルの低いLLMを使うくらいなら、いっそ使わない方がマシ」と。
能力の足りない同僚と仕事をしているような状態になり、かえって時間を吸い取られる。
そういう理屈です。
逆の角度からの指摘もありました。
「違いが分からないなら、あなたにClaudeは要らない。安いモデルで十分。Claudeの本当の能力を引き出せていないだけだ」と。
同じ温度感で寄せられていた意見です。
賢い使い分け：複数モデルを役割分担で組む
実用的だったのが、複数モデルを役割で組み合わせるアプローチです。
たとえば、こんな流れです。
まず大きいモデルに計画を立てさせます。
次に、その計画を上位のモデルにレビューさせる（roastさせる）。
そして実装は、小型モデルにやらせる。
具体例として「Sonnetに計画させて、Opus advisorにダメ出しさせる」というやり方が挙がっていました。
別の人は、変わった使い方をしているそうです。
Claude Codeのコマンドプロンプト窓でDeepSeek V4 Pro APIを動かす。
同時にPowerShell窓でGPT-5.5 Codexを走らせる。
そして片方にもう片方をチェックさせたり、リードと補佐の役割を入れ替えたりする使い方です。
「両者が互いを補完しながら動く様子は見ていて圧巻」とのことでした。
冷静な指摘もありました。
「VCがコーディングを補助金漬けにしてくれている今こそ、複数ツールを補助金ルートで使い倒すのが最大のレバレッジ。APIは避ける」と。
VCマネーで安く使える時期を、開発者側が逆手に取っているわけです。
DeepSeekの現在の弱点
議論で挙げられたDeepSeekの限界も整理しておきましょう。
ひとつは画像対応がないことです。
Claudeのマルチモーダル機能と違って、視覚的なバグを画像で送って修正するような使い方ができません。
ふたつめはハルシネーション率です。
V4は、古いV3.2や小型のオープンモデルと比べてもハルシネーションが多いと感じる人がいるようでした。
「これは野放しレベル」とまで書いている人もいます。
最後に、速度とトークン消費の問題です。
クローズドなフロンティアモデルと比べると、DeepSeekは遅くてトークンを多く食う、と。
価格を計算する時、この点も折り込む必要があるわけです。
そしてもうひとつ、議論の中で何度も出てきた重要な助言があります。
どのモデルを使っていても、それを信用してはいけない。 最後は、あなたを満足させるよう訓練されたモデルにすぎない。 ウソをついたり手を抜いたりして、満足のいく答えを返してくることがある
まとめ
「同じことが$5でできるなら、なぜ$100払うのか」というRedditでの問いには、シンプルな答えがありません。
そもそも「同じことができる」かどうか自体が、タスクの複雑さと開発者のスキルによって変わるからです。
シンプルな変換作業ならDeepSeekで十分。
一方、複雑な大規模システムの改修ならClaude。
そういう棲み分けが現実的なようでした。
そして見落とせないのが、あなたの時間の価値です。
デバッグで何時間も消耗するなら、はじめから精度の高いツールに払った方が安く済みます。
逆に、自分の手で品質をコントロールできるスキルがあるなら、安いモデルを使い倒す方が合理的になります。
慣性、マーケティングの影響、中国製モデルへの不信感、選択肢への無関心。
こうした非技術的な要因も、価格差の説明として挙げられていました。
最後に印象的だったのは、複数モデルを役割で使い分けるという実務知です。
一つのモデルにすべてを背負わせるわけではありません。
計画は大きいモデルに、実装は小さいモデルに、レビューは別のモデルに、と分業させる。
コーディングAIの選択は、もはや「どのモデルか」ではなく「どう組み合わせるか」という段階に入っているのかもしれません。
Redditの議論は、その判断材料を整理する上で示唆に富んだものでした。
