海外のRedditで、興味深い投稿が話題になっていました。
長年Claudeを愛用してきた10年選手のソフトウェアエンジニアが、DeepSeekへ乗り換えたという内容です。
この記事は、LLMツール選びに迷っている方にとって、判断材料の一つになるでしょう。
投稿者の背景
投稿者は現役のソフトウェアエンジニアです。
バックエンドを中心としつつ、フロントエンド、Windowsデスクトップアプリ、インフラまで幅広く手がけているといいます。
経験は約10年。
LLMツールの位置づけは、あくまで補助的なものだそうです。
「使う必要があるから使う」のではありません。
「もう一人分の手として、作業を速くするために使う」というスタンスです。
この距離感は、ツール選びにも影響しているように感じました。
長らくClaude Maxの5xプランを契約していたとのこと。
ただし、5時間枠の70%すら使い切った経験がないらしい。
同僚と認証情報をシェアして試したくらいの余裕ぶりだったといいます。
なぜ乗り換えを決めたのか
満足していたはずの環境を捨てた理由は、複数ありました。
一つは、Claudeが「エリートモデル」化していく流れへの違和感です。
Copilot ProプランからClaudeが外れました。
さらに、Claude Code以外との組み合わせが不便になっていったといいます。
投稿者の言葉を借りれば、ベンダーロックインされそうな感覚があったとのこと。
もう一つは、純粋なコスト感覚です。
月$100相当の価値を実感できていなかったと書いています。
投稿者は2010年からのLinuxユーザー。
いつでも荷物をまとめて移れる自由を大切にしてきた人物です。
この価値観が、乗り換えの決定的な後押しになったように見えます。
別ツールを試した経緯
Claudeを解約した後、まずOpencode Goを月$5で契約しました。
最初に試したのはKimi K2.6。
しかし、動作が遅く、頻繁に詰まる印象だったといいます。
次にOpencode上でDeepSeek v4を動かしてみました。
ところが、結果は似たりよったり。
タスクは進むものの、もたつきが目立ったようです。
ここで投稿者は「ハーネスを変える」という決断をします。
Pi(pi.dev)をセットアップしました。
すると、明らかに速度の違いを体感したと記しています。
最終的にDeepSeek v4 Proに落ち着き、現時点では満足しているとのこと。
DeepSeekを使ってみての所感
実際に個人サイトのUI改修をDeepSeekに任せたそうです。
すると、期待を超える出来栄えだったといいます。
リファクタの方向性も、自分が書いたであろうコードに近かったらしい。
SonnetやOpusとの比較については、投稿者は「気にしていない」とはっきり書いていました。
この価格帯で得られている結果に納得しているからです。
興味深かったのは、投稿者が普段から非常に具体的な指示を出すスタイルだという点。
具体的に伝える項目は、次のようなものだそうです。
- 何をすべきか
- 関連コードがどのファイルにあるか
- 他にどこを参照すべきか
Context7のCLIも頻繁に併用しているといいます。
ある日、あえて曖昧なタスクを投げてみたそうです。
すると、DeepSeekは「とりあえずこれでやってみて、違ったらユーザーが直してくれる」と判断して進めたといいます。
この振る舞いを、投稿者は好意的に受け止めていました。
「ワンショット」評価への違和感
投稿者の主張で印象的だったのが、「モデルをワンショット能力で評価するのは違う」という指摘です。
10年のキャリアを持つ自分でも、何かを一発で完成させることはほぼない。
本人はそう語ります。
DockerやKubernetesの書籍まで執筆した人物です。
それでも、Dockerfileやdocker-compose.ymlを書くたびに、何かしら間違えると言うのです。
人間ですらこうです。
LLMにワンショットでの完成を求めるのは、実態に合っていません。
コメント欄でも、似た声が複数寄せられていました。
1970年代からコードを書いている開発者がいます。
さらに、60年代から関わったMULTICSの作り手を名乗る人物まで登場しています。
皆、ワンショットでは何も決まらないという認識で一致していました。
「完璧」ではなく「進捗」を求める姿勢。
これがベテランたちに共通する視点のようです。
既存コードベースでの実力こそ重要
もう一つ、投稿者が強調していたポイントがあります。
「既存コードベースでどれだけ機能するか」の重要性です。
ゼロから何かを作る能力は、もはや多くのモデルが備えています。
本当に問われるのは別の点です。
人間や複数人のチームが書いた既存コードへ、適切に介入できるかどうか。
ある実タスクでは、DeepSeekがGPT 5.5を上回る結果を出したそうです。
この観点はコメント欄でも補強されていました。
1300以上のマイクロサービスを抱える企業の閉じたコードベースで、作業している開発者がいたのです。
その方の報告では、DeepSeekだけが安定して動いたとのこと。
他のモデルは作業中に文脈を見失ったそうです。
一方、DeepSeekは1Mのコンテキストウィンドウを使い切る局面でも、劣化が少なかったといいます。
別のコメントでも興味深いエピソードが紹介されていました。
複雑なバグ対応の場面です。
Opusは過剰に複雑な解決策を提案し続けたそうです。
一方で、DeepSeek V4 Flashは直接的でシンプルな修正を提示したといいます。
ハルシネーション対策の実践
DeepSeekの懸念点として「ハルシネーション」を挙げるコメントもありました。
これに対する投稿者の対処法は、特別なものではありません。
セッションをこまめに切り替える、というシンプルなアプローチです。
具体的なタイミングを掘り下げた質問もありました。
投稿者の答えは「コンテキスト使用量が50%に達したあたり」が目安。
ただし、固定的なルールではないとのこと。
タスクは小さな単位に分割するそうです。
そして、それぞれを独立してテストできる形にします。
一つ片付けたらセッションをクリアして、次へ進む。
10%程度の使用量でも、新しいセッションに切り替える場合があるといいます。
特に印象的だったのは、複数のタスクを同一セッションで処理しないという徹底ぶりです。
例えば、バグが2件あった場合を考えてみます。
AIには1件だけを伝えて、もう片方は完全に伏せておくそうです。
汚れた文脈で作業させるより、新鮮な文脈を与え直すほうがコストが低い、という判断でした。
コストパフォーマンスの実例
コスト面の具体例として、コメントの中に印象的な数字がありました。
Opencodeの最低限のCLIハーネス上で、DS4 FlashをAPIキー経由で運用している方の報告です。
月の最初の7日間で、9,600万トークンを消費。
それでいて費用は$1.05という結果でした。
別のコメントでも興味深い事例が紹介されていました。
Open InterpreterからDS4 Flashを使い、キャッシュを併用しているケースです。
1レスポンスあたり1セントの数百分の1という単価を実現しているそうです。
運用面では、別の組み合わせも話題に上がっています。
DeepSeekをワーカーモデルとし、Claudeをプランナーとして使うやり方です。
あるユーザーは、GeminiやGPTを含む複数モデルでパートナー実験を行ったといいます。
その結果、DeepSeekの徹底ぶりとダブルチェック性能が、最も高品質な出力をもたらしたと報告していました。
ビジョン機能の不足について
DeepSeek自体にはビジョン機能がありません。
この点について、投稿者は当初不便さを感じたそうです。
しかし、現在は気にしていないと書いています。
UIの実装結果が思った通りでなかった場合、関係しそうなファイルを特定する。
そして、モデルに直接そのファイルを指し示せばよい。
こうした割り切りです。
コメント欄では、別のアプローチも紹介されていました。
Piの拡張機能ページから「ビジョンプロキシ」を導入する方法です。
これによって、別モデル経由でビジョン機能を擬似的に補完できるそうです。
まとめ
長年Claudeを使ってきたベテランエンジニアが、DeepSeekへ乗り換えました。
そして、その判断に満足している。
これが投稿の核心でした。
この投稿が示しているのは、ツール選びの本質です。
価格や機能だけではありません。
「ツールとの距離感」も含めた選び方の重要性です。
投稿者はベンダーロックインを避け、自分のスタイルに合うものを選び抜いていました。
投稿とコメントから得られた知見をまとめると、次の3点になります。
- ワンショット評価ではなく、既存コードベースでの実力を見る視点
- セッション分割によるハルシネーション対策
- ハーネス選びによる体感速度の改善
これらは、どのモデルを使う方にとっても応用できる視点です。
LLM選びに正解はありません。
それでも、実体験ベースの情報は自分の選択を見直すきっかけになります。
気になるモデルがあれば、まずは試してみる。
これに勝る判断材料はないでしょう。
