DeepSeek on KnightLiブログ

DeepSeek-TUI：DeepSeek V4をターミナル上のコーディングAgentにする

Sat, 16 May 2026 22:41:41 +0800

DeepSeek-TUI は、DeepSeek V4をターミナル開発フローに接続するオープンソースプロジェクトです。単なるチャットの外枠ではありません。Claude CodeやCodex CLIに近い「コマンドラインのコーディングAgent」であり、ファイルを読み、コードを編集し、コマンドを実行し、ツールを呼び出し、TUI上でタスクを継続的に進められます。

すでにエディタとターミナルを行き来している開発者にとって、この種のツールの価値は分かりやすいものです。コードをWebチャットへ何度もコピーする必要がなく、プロジェクト構造を毎回手で説明する必要もありません。タスクを渡せば、現在のワークスペースからコンテキストを読み取り、手順を計画し、変更を実行し、結果をレビュー用に返してくれます。

DeepSeekの利用入口を補う

DeepSeekモデル自体は強い推論能力とコード能力を持っています。ただし、その能力を実際の開発フローに落とし込むには、工程化された外側のレイヤーが必要です。

Webチャットは質問には向いていますが、長時間のプロジェクト編集には向いていません。APIはシステム連携には向いていますが、個人開発者はツール呼び出し、コンテキスト管理、ファイル操作、権限制御を自分で組む必要があります。DeepSeek-TUIが補おうとしているのはこの層です。DeepSeek V4を、ターミナル内で働けるAgentとして包みます。

プロジェクト説明によると、主な機能は次の通りです。

ターミナルTUI;
DeepSeek V4向けの会話とタスク実行;
ツール呼び出しとファイル操作;
1Mコンテキスト対応;
Autoモード;
サブAgent;
サンドボックス実行;
永続タスクキュー。

これらの機能の目的は、モデルの返答をより人間らしくすることではありません。モデルを開発現場に入りやすくすることです。

長いタスクには純粋なCLIよりTUIが向いている

多くのAI CLIツールは、最初はプレーンテキストの対話から始まります。プロンプトを入力し、出力を待ち、コマンドをコピーしたり追加コンテキストを渡したりする方式です。これは単純ですが、タスクが長くなるとすぐ混乱します。

TUIの利点は、会話、ファイル、実行結果、タスク状態をより安定した画面に置けることです。コーディングAgentではこれが重要です。1つのコードタスクは、単なる一問一答ではないからです。多くの場合、次の流れを含みます。

プロジェクト構造を理解する。
関連ファイルを探す。
コードを変更する。
テストやコマンドを実行する。
エラーに基づいて修正を続ける。
変更内容をまとめる。

画面がログの羅列だけだと、ユーザーはAgentが今どこまで進んだのかを判断しにくくなります。TUIは少なくとも、観察し、必要なら引き継ぐための入口を提供します。

Autoモードは境界が明確なタスクに向く

DeepSeek-TUIが言及しているAutoモードは、境界が比較的明確な作業に向いています。たとえば小さなバグ修正、スクリプト追加、設定変更、文書整理、局所的な機能実装です。

こうしたタスクには共通点があります。目標が明確で、確認方法も明確で、影響範囲が制御できます。Agentは自分でファイルを調べ、編集し、コマンドを実行し、結果をユーザー確認に戻せます。

ただし、Autoモードは無制限の権限ではありません。実際のプロジェクトでは、ファイル削除、大規模リファクタリング、データベース移行、デプロイコマンドには明確な確認が必要です。コーディングAgentの効率は自動化から生まれますが、リスクも同じ場所から生まれます。コマンドを実行できるツールほど、サンドボックス、権限境界、人間によるレビューが必要です。

サブAgentの意味はタスク分割にある

サブAgentは新しい概念ではありませんが、コード作業では役に立ちます。

少し複雑なタスクでは、複数の種類の作業が同時に必要になります。コードを読む役、実装を変更する役、テストを確認する役、ドキュメントを整理する役です。従来のマルチAgentシステムが派手に見えるだけで終わりがちなのは、実際のツールやワークスペースを持たず、会話の中で相談しているだけだからです。

サブAgentがファイルシステム、コマンド実行、タスクキューと結びつけば、より現実的なタスク分割の仕組みになります。たとえば、あるサブAgentが依存関係を分析し、別のサブAgentが特定モジュールを変更し、メインAgentが結果を統合する、といった形です。これにより、1つのコンテキストに無関係な情報を詰め込みすぎる問題を減らせます。

もちろん、サブAgentには追加コストもあります。token消費、複雑な状態、追跡しにくい責任境界です。そのため、中程度以上の複雑さを持つタスクに向いており、すべての小さな修正に必要なものではありません。

1Mコンテキストは万能ではないが、プロジェクト理解には役立つ

1Mコンテキストは大げさに聞こえますが、コーディングでは単なる宣伝文句ではありません。

実際のコードベースのコンテキストは細かく分散しています。README、設定ファイル、型定義、テスト、呼び出しチェーン、過去の約束事、エラーログは、どれも1つの修正に影響します。長いコンテキストは、局所だけを見て手を動かす問題を減らし、モデルがより多くのプロジェクト制約を保持する助けになります。

ただし、コンテキストが長いことは判断が正しいことと同義ではありません。コードタスクには依然として検索、選別、検証が必要です。プロジェクト全体をコンテキストに詰め込むことが、関連ファイルを正確に読むことより良いとは限りません。良いコーディングAgentは、長いコンテキストをバッファとして使うべきであり、エンジニアリング判断の代替にすべきではありません。

向いているユーザー

DeepSeek-TUIは次のような人に向いています。

ターミナルでDeepSeekを使ってコード作業をしたい開発者。
ツール呼び出しやファイル操作の枠組みを自分で作りたくない人。
Claude CodeやCodex CLIに慣れており、DeepSeekモデルの入口も試したい人。
Web上のコード断片ではなく、ローカルプロジェクトのコンテキストが必要な人。
AIコーディングの流れをコマンドライン環境に入れたい人。

たまに関数の書き方を聞くだけなら、Webチャットで十分です。モデルに直接プロジェクト変更へ参加してほしいなら、ターミナルAgentの意味が大きくなります。

注意すべきリスク

この種のツールで特に注意すべきことは3つあります。

1つ目は権限です。ツールがファイルを読み書きし、コマンドを実行できるなら、デフォルトでどこにアクセスできるのか、ファイルを削除できるのか、ネットワークに出られるのか、危険なコマンドに確認が必要なのかを把握する必要があります。

2つ目はロールバックです。使う前にGitの作業ツリーをきれいにしておくと、Agentの変更を毎回 git diff で明確に確認できます。未コミットの変更が大量にある状態で、Agentに自動編集させるべきではありません。

3つ目は検証です。Agentがコードを書いたことは、タスク完了を意味しません。テスト、ビルド、lint、人間のreviewは残す必要があります。AIコーディングツールは進行を速めますが、最後のエンジニアリング確認を置き換えるものではありません。

まとめ

DeepSeek-TUIの意味は、また1つチャットクライアントが増えたことではありません。DeepSeek V4を、実際の開発作業に近いターミナル環境へ入れていることです。

開発者にとって、モデル能力は最初の一歩にすぎません。本当に体験を左右するのは、プロジェクトを読めるか、安全にファイルを変更できるか、検証コマンドを実行できるか、長いタスクで状態を保てるか、ユーザーがいつでも引き継げるかです。

DeepSeekを日常的なコード変更、プロジェクト読解、自動化された開発タスクに使いたいなら、DeepSeek-TUIは注目に値します。方向性も明確です。AIコーディングツールは「コードの質問に答える」段階から「プロジェクト実行に参加する」段階へ進んでいます。

DeepSeek 4 をローカルで動かす：Apple Silicon Mac における Antirez ds4 の試み

Mon, 11 May 2026 08:51:37 +0800

Antirez が新しいプロジェクト ds4 をオープンソース化しました。これは汎用 LLM フレームワークではなく、DeepSeek V4 Flash 向けのローカル推論エンジンで、Apple Silicon と Metal バックエンドに重点を置いています。

プロジェクト URL：https://github.com/antirez/ds4

ds4 とは

ds4 の目的は明確です。Mac 上で DeepSeek V4 Flash をローカル実行することです。

現在は、次の 3 つの使い方が用意されています。

対話型 CLI。
HTTP server。
実験的な Agent モード。

位置づけとしては、llama.cpp、Ollama、vLLM のような汎用ツールを置き換えるものではなく、特定のモデルに深く最適化した推論プロジェクトに近いものです。

なぜ注目に値するのか

この種のプロジェクトが注目に値する理由は主に 3 つあります。

第一に、作者が Redis の作者である Antirez であることです。彼は長く低レイヤーのシステム、性能、シンプルなツールに関心を持っており、プロジェクトの作風も比較的ストレートです。

第二に、DeepSeek V4 Flash は効率的な推論を指向するモデルです。ローカル実行の体験が十分によければ、Mac ユーザーにとってかなり魅力的です。

第三に、ds4 は Apple Metal を直接ターゲットにしています。最初にあらゆるプラットフォームをサポートしてから徐々に最適化する路線ではなく、明確な 1 つの場面を深く掘るプロジェクトに見えます。

誰に向いているか

ds4 は、次のようなユーザーに向いています。

Apple Silicon Mac を使っている。
DeepSeek V4 Flash をローカルで動かしたい。
Metal 推論性能に関心がある。
alpha 段階のプロジェクトを試すことに抵抗がない。
軽量な推論エンジンやモデル実行の細部を調べたい。

安定したデプロイ、クロスプラットフォーム実行、OpenAI API 互換のエコシステムが目的なら、現時点では第一候補ではないかもしれません。実験用ツール、または技術的な観察対象として見るのがよさそうです。

使い方

プロジェクト README にある基本的な流れは、まずビルドしてから実行するというものです。

1
2
3

git clone https://github.com/antirez/ds4.git
cd ds4
make

対話的に実行する場合：

./ds4

HTTP server を起動する場合：

`1`	`./ds4 --server`

Agent モード：

`1`	`./ds4 --agent`

具体的なパラメータやモデルファイルの準備方法は、プロジェクトがまだ速いペースで変化しているため、リポジトリの README を確認するのが確実です。

現時点のリスク

ds4 はまだ初期段階のプロジェクトなので、使う前に次の点を想定しておく必要があります。

機能が完全ではない可能性があります。
パラメータ、モデル形式、コマンドラインの挙動が変わる可能性があります。
互換性は主に Apple Silicon と Metal を中心にしています。
Agent モードは実験的な性格が強く、本番フローに直接使うには向いていません。
問題が起きた場合、自分で README、issue、ソースコードを読んで調べる必要があります。

つまり、現時点では一般ユーザー向けのワンクリックツールというより、試してみる価値のあるオープンソース実験です。

汎用推論ツールとの違い

汎用推論ツールは通常、モデル形式、プラットフォーム、バックエンド、API の広い互換性を目指します。ds4 の方向性はもっと狭く、DeepSeek V4 Flash と Metal によるローカル実行に絞られています。

この選択には利点と代償があります。

利点は、実装を集中させやすく、性能や体験を単一の目標に合わせて最適化しやすいことです。代償は、適用範囲が限られることです。さまざまなモデルを動かすための道具ではなく、完全なデプロイ基盤の置き換えにも向いていません。

すでに llama.cpp や Ollama を使っているなら、ds4 は既存のワークフローをすぐ置き換えるものではなく、補助的なテストツールとして見るのが自然です。

まとめ

ds4 の見どころは、「また 1 つローカル大規模モデルツールが増えた」ことではありません。DeepSeek V4 Flash、Apple Silicon、Metal、ローカル推論という狭い範囲に絞っている点です。

手元に適した Mac があり、初期段階のプロジェクトを触ることに抵抗がないなら、今後の性能、モデル対応の方法、server/agent 機能の進化を追う価値があります。本番環境については、インターフェイスと使い方が安定してから評価するのがよいでしょう。

参考

GitHub プロジェクト：https://github.com/antirez/ds4

AI コーディングツールの今回の波で、なぜ DeepSeek がコスト削減の鍵になったのか

Mon, 11 May 2026 04:59:00 +0800

今回の AI コーディングツール競争は、表面上はモデル性能、プラグインエコシステム、agent 自動化の競争に見える。しかし実際に使い始めると、最初にぶつかる問題はコストだ。

Claude Code、Codex、OpenClaw、Superpowers はどれも便利だが、共通点がある。複雑なタスクに入ると、とにかく token を消費する。プロジェクトを読み、計画を作り、ツールを呼び出し、コンテキストを要約し、結果を何度も確認し、場合によっては複数のサブタスクを起動する。モデルが賢くなり、ワークフローが自動化されるほど、請求額も静かに膨らみやすい。

だから今回、DeepSeek が重要になっている。単にコードを書けるからではない。長いコンテキストとキャッシュコストが、AI コーディングツールで最もお金が燃える部分にちょうど効いているからだ。

Agent ツールはなぜ token を大量に消費するのか

従来のチャット型コーディング支援は、基本的に一問一答だ。関数の書き方を聞くと、コード片が返ってくる。この形でも token は消費するが、まだ制御しやすい。

Agent ツールは違う。質問に答えるだけではなく、一時的なエンジニアのようにプロジェクトへ入っていく。

まずディレクトリと重要ファイルをスキャンする；
要件と既存アーキテクチャを理解する；
計画を作る；
ファイルを修正する；
コマンドやテストを実行する；
エラーに応じて修正を続ける；
最後に変更内容をまとめる。

この過程では、モデルが同じコンテキストを何度も読む。プロジェクト説明、コード片、ツール結果、過去の会話、計画、エラーログが繰り返しコンテキストに戻される。少し複雑なタスクになるだけで、数十万 token はすぐに消える。

さらに攻めたプラグインを入れると、コストはもっと目立つ。OpenCode や Claude Code の拡張ツールの中には、デフォルトで agent チームを組むものもある。小さな機能を一つ変えたいだけでも、計画、レビュー、実行、振り返りまで起動することがある。タスクはより「賢く」見えるが、token も増え続ける。

Superpowers の利点は必要なときだけ起動すること

Superpowers のようなツールの利点は、すべてのタスクで完全な agent フローを強制しないことだ。

普段は Claude Code、OpenCode、Codex を従来の方法で動かせる。ブレインストーミング、計画作成、計画実行、振り返りのような skill を明示的に呼び出したときだけ、より重い自動化フローに入る。

これはコスト面で重要だ。

AI コーディングでは、すべてのタスクに重装備を使うべきではない。設定を一行変える、エラーを一つ調べる、小さなスクリプトを書く程度なら、普通の対話で十分だ。複雑なリファクタリング、複数ファイルの変更、長文ドキュメント処理、多段階の検証だけが、完全な agent フローに値する。

ツールが強力になるほど、起動条件を制御する必要がある。そうしなければ、自動化が増えるほど無駄も増える。

DeepSeek の重要な強みはキャッシュが安いこと

DeepSeek がこの種の agent ツールに合う大きな理由は、キャッシュヒット時のコストが低いことだ。

AI コーディングタスクには、大量の反復プレフィックスがある。プロジェクト背景、システムプロンプト、ツール説明、ファイル内容、前の会話ターンは、後続リクエストに何度も現れる。モデルサービスが prompt cache をサポートしていれば、こうした反復部分はキャッシュヒット後にかなり安くなる。

多くのモデルでは、キャッシュヒット価格は未ヒットより少し安い程度で、たとえば三分の一前後という感覚だ。DeepSeek の強みは、ヒット後の価格差がもっと大きくなり得ることにある。長いコンテキスト、多段階呼び出し、プロジェクトの反復読み込みを行う agent ワークフローでは、この差が請求に直接出る。

つまり DeepSeek は、毎回の回答が必ず最強というわけではない。しかし「長いタスク、多いターン、コンテキストの反復読み込み」という場面では、コスト構造が AI コーディングに非常に向いている。

長いコンテキストは Claude Code を使いやすくする

Claude Code や類似ツールを DeepSeek V4 に接続すると、もう一つの明確な利点が長いコンテキストだ。

AI コーディングツールが最も嫌うのは、コンテキスト不足だ。コンテキストが足りなくなると、頻繁に圧縮が必要になる。圧縮が増えると、前に読んだ細部が失われることがある。モデルはプロジェクト構造、制約、あるファイルをなぜ変更したかを忘れ始め、その後の品質が落ちる。

DeepSeek V4 系列の長いコンテキスト能力は、コードリポジトリ、ドキュメントの一括処理、字幕翻訳、サイト記事整理に向いている。特に Claude Code や OpenClaw に接続する場合、設定が適切ならコンテキスト圧縮を遅らせ、より多くのプロジェクト詳細を保てる。

だから DeepSeek で動かすと「よく持つ」と感じるタスクがある。各ステップが必ずしも派手ではなくても、長時間、低コスト、反復呼び出しに耐えられる。

V4 Pro と V4 Flash の分担

DeepSeek V4 Pro と V4 Flash は混ぜて使うべきではない。

単純なタスクには DeepSeek V4 Flash が向いている。速く、安く、次のような場面ではたいてい十分だ。

字幕翻訳；
ドキュメント整理；
普通のスクリプト生成；
小規模なコード修正；
OpenClaw の軽量タスク；
簡単なサイトコンテンツ処理。

複雑なタスクでは DeepSeek V4 Pro を検討する。

大規模リファクタリング；
複数モジュールのコード理解；
複雑な推論；
長い agent チェーンのタスク；
高リスクなコード変更；
より強い計画能力が必要なエンジニアリングタスク。

最初から最強モデルを使いたがる人は多いが、それは割に合わないことも多い。AI コーディングツールの現実的な使い方は、タスクを層に分けることだ。安いモデルに大量の定型作業を任せ、高いモデルは重要な判断点だけに使う。

MiniMax、Doubao、DeepSeek は役割が違う

国内モデルやプランの中で、MiniMax、Doubao、Kimi、DeepSeek にはそれぞれ位置づけがある。

MiniMax の強みは、量が多く、安く、機能が広いことだ。最も賢いコーディングモデルではないかもしれないが、翻訳、軽い整理、一括処理には費用対効果が高い。字幕の一括処理、形式変換、簡単な校正などには、MiniMax 型のプランはかなり使いやすい。

Doubao の強みは、ツールエコシステムが広いことだ。画像、動画、検索、TTS、場合によっては STT や embedding までつなげられる。総合ツールボックスに近い。

DeepSeek の位置づけはもっと明確だ。テキスト、コード、長いコンテキスト、低コストキャッシュ。画像生成、音声、動画の完全なエコシステムはなく、弱点ははっきりしている。しかし AI コーディングと長文 agent ワークフローでは、長所が十分に長い。

だから誰が誰を置き換えるという話ではない。タスクを分け、それぞれに合う道具を使う話だ。

コスト削減の鍵は安いモデルを探すだけではない

AI コーディングでコストを下げるとは、すべてのリクエストを安いモデルに替えることではない。

有効な方法はいくつかある。

単純なタスクで重い agent を起動しない。
Flash で十分なタスクに Pro を使わない。
長いタスクではできるだけキャッシュを使う。
反復コンテキストを安定させ、意味のない変更でキャッシュを無効化しない。
大きなタスクは安いモデルに下書きと一括処理をさせ、強いモデルで重要レビューを行う。
agent に、事実を繰り返し説明せず、同じことを何度も要約しないよう明確に伝える。

特に最後の点は重要だ。AI ツールは冗長になりやすい。冗長さは読みやすさだけでなく、コストの問題でもある。プロンプトに「事実は一度だけ説明し、意見は一度だけ述べる」と入れると、文章品質と token 消費の両方を改善できる。

DeepSeek に向く AI コーディングワークフロー

DeepSeek は次のようなタスクに特に向いている。

長いコードリポジトリの読解；
複数ファイルの軽い修正；
ドキュメントの一括整理；
字幕の一括翻訳；
Hugo 記事の整理；
agent 計画の実行；
大量の反復コンテキストを含む低コスト自動化。

すべてのタスクに向くわけではない。特に強いフロントエンドの審美眼、複雑なプロダクト判断、クロスモーダル制作が必要なら、Claude、GPT、Gemini、Doubao などを組み合わせる必要がある。

しかしタスクが「長文、長いコンテキスト、反復呼び出し、コスト敏感」である限り、DeepSeek は第一候補になりやすい。

まとめ

今回の AI コーディングツールの波で、DeepSeek の価値は「国内モデルがコードを書ける」ことだけではない。agent ツールの最も現実的な痛点、つまり長いタスクが高すぎる問題を解いていることにある。

Claude Code、OpenClaw、Superpowers のようなツールは開発フローをますます自動化する。しかしその裏側には、大量のコンテキスト読み書きと多段階呼び出しがある。この部分のコストを下げられる人が、AI コーディングを「たまに気持ちよく使うもの」から「毎日使えるもの」に変えられる。

DeepSeek の長いコンテキスト、低いキャッシュコスト、V4 Flash / V4 Pro の階層的な使い分けは、まさにその位置にある。

今回の本当のコスト削減の鍵は、良いモデルを使わないことではない。良いモデル、安いモデル、キャッシュ、agent フローをうまく組み合わせることだ。この会計を理解できれば、AI コーディングツールは美しいが高価なおもちゃではなく、本当の生産性になる。

DeepSeek-TUI：ターミナルで DeepSeek コーディング Agent を動かす

Fri, 08 May 2026 13:41:15 +0800

DeepSeek-TUI はターミナルで動く AI コーディング Agent です。DeepSeek V4 モデルを中心に設計され、deepseek コマンドで起動します。TUI 内でファイルの読み書き、shell コマンド、web search、git、MCP server、sub-agent 協調を扱えます。

単なるチャット CLI というより、ターミナル上の作業台です。コードを読む、ファイルを編集する、コマンドを実行する、診断を見る、セッションを保存する、状態を戻す、という開発動作を 1 つにまとめます。

リポジトリは主に Rust で書かれ、MIT ライセンスです。

向いている人

DeepSeek-TUI は、ターミナル中心の開発者が DeepSeek モデルをローカル開発に組み込みたい場合に向いています。

DeepSeek でコード修正やプロジェクト分析をしたい。
フル IDE を開きたくない。
AI に workspace を読ませ、必要に応じて編集させたい。
Plan、Agent、YOLO を使い分けたい。
セッション保存、長時間タスク再開、rollback が必要。
MCP、LSP 診断、HTTP/SSE runtime API、skills を使いたい。

簡単な Q&A だけなら web や軽量 CLI で十分です。DeepSeek-TUI はモデルをローカル開発フローに入れたい人向けです。

インストール

npm:

1
2
3

npm install -g deepseek-tui
deepseek --version
deepseek --model auto

npm パッケージは事前ビルド済み Rust バイナリを取得する installer/wrapper で、Node.js >=18 が必要です。

Cargo:

1
2

cargo install deepseek-tui-cli --locked
cargo install deepseek-tui --locked

Homebrew:

1
2

brew tap Hmbown/deepseek-tui
brew install deepseek-tui

GitHub Releases から Linux x64/ARM64、macOS x64/ARM64、Windows x64 のバイナリも入手できます。

Docker:

docker run --rm -it \
  -e DEEPSEEK_API_KEY \
  -v "$PWD:/workspace" \
  ghcr.io/hmbown/deepseek-tui:latest

API Key

初回起動時に DeepSeek API key を入力し、以下へ保存します。

`1`	`~/.deepseek/config.toml`

手動設定：

1
2

deepseek auth set --provider deepseek
deepseek auth status

環境変数：

1
2

export DEEPSEEK_API_KEY="YOUR_KEY"
deepseek

診断：

`1`	`deepseek doctor`

保存済み key の削除：

`1`	`deepseek auth clear --provider deepseek`

Auto mode

`1`	`deepseek --model auto`

TUI 内:

`1`	`/model auto`

Auto mode はモデルと thinking を同時に選びます。

Model: deepseek-v4-flash または deepseek-v4-pro
Thinking: off、high、max

本番リクエスト前に小さな routing call を行い、最新の依頼と文脈からモデルと thinking を決めます。auto はローカル機能で、上流 API には具体的なモデル名が送られます。

ベンチマーク、厳格なコスト管理、固定挙動が必要な場合は明示的にモデルを指定します。

モード

モード	用途
Plan	読み取り専用の調査と計画
Agent	承認ゲート付きの通常モード
YOLO	信頼済み workspace で自動承認

YOLO は便利ですが危険も大きいため、信頼できる一時ブランチやテストディレクトリで使うべきです。

主な機能

ファイル操作、apply patch、shell、git、web search/browse、sub-agent、MCP、LSP 診断、セッション保存と再開、workspace rollback、永続 task queue、HTTP/SSE runtime API、skills system に対応します。

LSP 診断は編集後のエラーをモデルへ戻せる点が便利です。rollback は side-git snapshot を使い、/restore と revert_turn を提供します。ただし通常の git commit は引き続き重要です。

よく使うコマンド

deepseek
deepseek "explain this function"
deepseek --model deepseek-v4-flash "summarize"
deepseek --model auto "fix this bug"
deepseek --yolo
deepseek auth set --provider deepseek
deepseek doctor
deepseek doctor --json
deepseek models
deepseek sessions
deepseek resume --last
deepseek resume <SESSION_ID>
deepseek fork <SESSION_ID>
deepseek serve --http
deepseek serve --acp
deepseek pr <N>
deepseek mcp list
deepseek mcp validate
deepseek update

Zed / ACP

{
  "agent_servers": {
    "DeepSeek": {
      "type": "custom",
      "command": "deepseek",
      "args": ["serve", "--acp"],
      "env": {}
    }
  }
}

README によると、現在の ACP は新規セッションと prompt response を扱いますが、tool-backed editing と checkpoint replay はまだ公開されていません。

設定と provider

ユーザー設定：

`1`	`~/.deepseek/config.toml`

workspace overlay：

`1`	`<workspace>/.deepseek/config.toml`

api_key、base_url、provider、mcp_config_path などは workspace overlay で禁止されています。

OpenAI-compatible:

1
2

deepseek auth set --provider openai --api-key "YOUR_OPENAI_COMPATIBLE_API_KEY"
OPENAI_BASE_URL="https://openai-compatible.example/v4" deepseek --provider openai --model glm-5

Ollama:

1
2

ollama pull deepseek-coder:1.3b
deepseek --provider ollama --model deepseek-coder:1.3b

まとめ

DeepSeek-TUI は DeepSeek V4、TUI、tool call、LSP 診断、セッション再開、rollback、MCP、skills を 1 つの Rust ベースの作業環境にまとめたターミナル Agent です。軽量さよりも、ローカル開発フローへ深く入ることに価値があります。

参考資料

DeepSeek V4のローカル私有化デプロイ：国産チップとコンシューマーGPUクラスターの選び方

Fri, 08 May 2026 09:39:35 +0800

DeepSeek V4の公開後、多くの企業が一つの問題に注目し始めた。外部APIを使わず、自社のデータセンター、プライベートクラウド、専用クラスターにモデルを配置できるのか、という問題だ。

この需要は非常に現実的だ。金融、医療、政府・企業、製造、法務、研究開発チームは、社内文書、コード、契約書、チケット、顧客データをそのままパブリッククラウドのモデルへ送れないことが多い。こうした場面でDeepSeek V4が魅力的なのは、モデル能力だけではなく、企業に「制御可能なLLMインフラ」に近い選択肢を与える点にある。

ただし、DeepSeek V4のローカルデプロイは、モデルをダウンロードしてGPUを数枚用意すれば動く、という話ではない。特にProのような超大規模MoEモデルでは、総パラメータ規模、アクティブパラメータ、コンテキスト長、KV cache、同時実行数、推論フレームワークがそのままハードウェアコストを左右する。企業が本当にやるべきことは、フルスペック版を盲目的に追うことではなく、まず業務に必要なデプロイ形態を確認することだ。

まずデプロイ目標を明確にする

企業がローカル私有化デプロイを行う目的は、主に三つある。

データを域外に出さない：社内文書、コード、顧客資料、ログ、ナレッジベースを企業環境の外へ出さない。
安定して制御できる：モデルサービス、権限、監査、ログ、アップグレードのペースを企業自身が管理する。
長期コストを下げる：高頻度に呼び出す場合、ローカル推論は外部APIを長期購入するより制御しやすい可能性がある。

少数の従業員がたまに質問するだけなら、ローカルデプロイは必ずしも割に合わない。私有化に本当に向いているのは、高頻度で、安定していて、データが敏感で、フローが明確な場面だ。例えば次のようなものがある。

社内ナレッジベースQ&A。
コードレビューと開発アシスタント。
カスタマーサポートチケットの要約。
契約書、カルテ、レポートなどの文書分析。
データベース問い合わせアシスタント。
Agentワークフロー自動化。

これらの共通点は、データが敏感で、呼び出しが安定しており、権限とログを通じて企業ガバナンスに組み込めることだ。

最初からフルスペックのProを追わない

DeepSeek V4の一般的なバージョンにはProとFlashがある。公開資料では、Proはより強い推論や複雑なAgentタスク向け、Flashはコストと応答速度を重視するものとされている。企業が選定するとき、すべての業務をProに載せる前提にすべきではない。

タスクの複雑度に応じて分けるとよい。

簡単なQ&A、要約、分類、タグ生成：Flashまたはより小さいモデルを優先する。
社内ナレッジベースの検索拡張：Flashで多くの場面をカバーできる。むしろRAG、権限、検索品質が重要だ。
コードAgent、複雑な推論、長文コンテキスト分析：その段階でProを評価する。
高価値・低頻度タスク：Proを使ってよいが、高い同時実行数が必要とは限らない。
一般的なオフィスアシスタント：最も高価な推論リソースを長時間占有する必要はない。

MoEモデルの利点は、各推論で一部のパラメータだけをアクティブにすることだ。しかし、それはハードウェア負荷が小さいことを意味しない。重みの保存、エキスパート並列、ネットワーク通信、コンテキストキャッシュ、同時実行スケジューリングは依然として重い。特に1M token級の長文コンテキストでは、単一の回答よりも、長いコンテキスト、多人数同時利用、継続セッションがリソースを消費しやすい。

国産チップ路線：企業向けプライベートクラウドに向く

企業がすでに国産計算資源プールを持っている場合、または信創、コンプライアンス、サプライチェーン要件がある場合は、Ascend、Cambriconなどの国産チップ路線を優先的に評価できる。

この路線の利点は次の通りだ。

国産化とサプライチェーン制御の要件に合いやすい。
企業データセンター、専用クラウド、政府・企業向けプロジェクトに入りやすい。
権限、監査、リソース分離、運用を統一しやすい。
長期的に安定したサービスに向いている。

ただし、国産チップ路線では三つの現実的な問題を見る必要がある。

第一に、フレームワーク適配だ。モデルが動くかどうかは、チップの計算力だけでは決まらない。推論フレームワーク、演算子、通信ライブラリ、量化形式、MoEエキスパート並列、長文コンテキスト最適化が成熟しているかも重要だ。

第二に、エンジニアリング経験だ。企業が必要とするのは「起動に成功した」だけではなく、安定したサービスだ。マルチテナント、レート制限、監視、障害復旧、段階的リリース、ログ監査、権限分離をすべて補う必要がある。

第三に、エコシステム差だ。同じモデルでも、NVIDIA、Ascend、Cambriconなどのプラットフォームでは、性能、精度、量化対応、デプロイツールが完全には一致しない。本番投入前には、名目上の計算力だけでなく、実際の負荷テストが必要だ。

したがって、国産チップは、予算が明確で、コンプライアンス要件が高く、プラットフォームエンジニアリングに投資できる企業に向いている。最も手軽な路線ではないが、長期ガバナンスには最も合う可能性がある。

コンシューマーGPUクラスター：試験導入と中小チームに向く

まず業務価値を検証したいなら、コンシューマーGPUクラスターの方が始めやすい。RTX 4090、RTX 5090、RTX 3090、RTX 3060 12GBなどのGPUは、コミュニティツール、量化モデル、ローカル推論フレームワークの情報が多く、試行錯誤のコストが低い。

コンシューマーGPU路線が向くのは次のような場面だ。

研究開発チームの社内試験導入。
中小企業のナレッジベースQ&A。
低同時実行のコードアシスタント。
オフライン文書処理。
SLA要求が高くない社内ツール。

ただし、制約も明確だ。

VRAMが小さく、完全な大規模モデルを直接載せにくい。
マルチGPU通信が弱く、複数マシン間通信はさらに面倒になる。
コンシューマー向けハードウェアは、長期フルロード時の安定性がサーバー方案に劣る。
ケース、電源、冷却、ドライバ、運用が隠れたコストになる。
最初から企業級の高可用性を約束する用途には向かない。

より現実的なのは、まずコンシューマーGPUでFlash、蒸留版、量化版、小規模モデルを動かし、業務フローを通すことだ。その後、呼び出し量、効果、データガバナンスを検証してから、サーバーGPUや国産計算基盤へ移行するかを決める。

想定されるデプロイ構成

比較的安定した企業向け私有化構成は、六つの層に分けられる。

モデル層：DeepSeek V4 Pro、V4 Flash、またはタスクに応じて選ぶ小さな蒸留モデル。
推論層：SGLang、vLLM、llama.cpp、ベンダーNPU推論スタック、または企業の自社サービス。
ゲートウェイ層：統一認証、レート制限、監査、モデルルーティング、呼び出しログ。
ナレッジ層：ベクトルDB、全文検索、文書解析、権限フィルタリング、RAG。
アプリケーション層：カスタマーサポート、コードアシスタント、文書分析、レポートQ&A、Agentワークフロー。
運用層：監視、アラート、コスト集計、段階的リリース、ロールバック、セキュリティ監査。

ここで最も過小評価されやすいのは、ゲートウェイ層とナレッジ層だ。多くのプロジェクトが失敗するのは、モデルがまったく使えないからではなく、権限、検索、ログ、コンテキスト管理、プロンプトテンプレート、業務フローが整っていないからだ。

企業内でLLMをデプロイするときは、モデルを孤立したチャットページではなく、基礎能力として扱うべきだ。本当の価値は、モデルがフローに入り、企業自身のデータとタスクを安定して処理できるようになったときに生まれる。

ハードウェア選定の考え方

ハードウェアは「動くか」だけでなく、「安定してサービス提供できるか」も見る必要がある。

段階ごとに選ぶとよい。

検証段階

目的は、その業務に取り組む価値があるかを証明することだ。

1-4枚のコンシューマーGPUを使う。
Flash、小モデル、蒸留モデル、量化モデルを優先する。
同時実行要求は低くし、タスク完了率を見る。
高可用性は約束しない。

この段階で大規模ハードウェアを早く買いすぎない。まず従業員が本当に使うか、業務が本当に時間を節約できるか、回答がフローに入るかを確認する。

試点段階

目的は、一つの部門または一つの業務ラインで安定して使うことだ。

4-16枚のGPU、または国産NPUノード一式を使う。
統一ゲートウェイ、ログ、権限制御を追加する。
RAG、文書解析、モデルルーティング、キャッシュを作る。
token、同時実行、遅延、失敗率を記録し始める。

この段階では運用が重要になる。モデル効果は一部にすぎず、安定性、コスト、データガバナンスも同じくらい重要だ。

本番段階

目的は企業級サービスに入ることだ。

サーバーGPU、国産計算クラスター、またはプライベートクラウド資源プールを使う。
複数レプリカ、レート制限、フェイルオーバー、容量計画を整える。
タスクごとにモデルをルーティングする。簡単なタスクは軽量モデル、複雑なタスクはProに送る。
企業IDシステム、監査システム、セキュリティポリシーと接続する。

本番段階では、すべてのリクエストを最強モデルに送るべきではない。適切なモデルルーティングは、ハードウェアを積み増すよりもコストを抑えやすい。

推論フレームワークの選び方

DeepSeek V4のようなモデルは、推論フレームワークへの要求が高い。特にMoE、長文コンテキスト、スパースアテンション、量化、マルチGPU並列が関わる場合、フレームワークの成熟度が速度と安定性に直結する。

一般的な選択肢は次のように理解できる。

SGLang：高性能推論、Agent、多ターンのツール呼び出し、複雑なサービス編成を重視するチームに向く。
vLLM：エコシステムが成熟しており、汎用LLMサービスに向く。ただし具体的な対応はバージョンとモデル適配の進捗を見る必要がある。
llama.cpp：小モデル、量化モデル、エッジデプロイに向く。フルスペックの超大規模MoEを直接載せる用途には向かない。
国産NPU推論スタック：信創や国産計算環境に向くが、演算子、量化、長文コンテキスト対応を重点的に検証する必要がある。

フレームワーク選びではbenchmarkだけを見ない。企業は自社の実データで試すべきだ。社内文書の長さ、同時実行数、平均出力長、RAG命中率、Agentのツール呼び出し回数、失敗時のリトライ回数を見る必要がある。

データ安全性はモデルの外側で作る

私有化デプロイは自動的に安全になるわけではない。モデルをローカルで動かすことは、「データが企業の外へ出るか」という問題の一部を解決するだけだ。

さらに次を補う必要がある。

アカウントと権限：部門ごとに自分のナレッジベースだけを参照できるようにする。
ログ監査：誰が何を聞き、どのモデルを呼び、どの文書にアクセスしたかを記録する。
データマスキング：顧客情報、身分証番号、電話番号、契約金額などの機微情報を処理する。
プロンプト安全性：ユーザーがプロンプトで権限を回避したり、システムプロンプトを漏らしたりしないようにする。
出力レビュー：重要な場面では人手レビューまたはルールレビューを入れる。
データライフサイクル：アップロード文書、ベクトルインデックス、キャッシュ、会話記録を削除できるようにする。

企業がローカルLLMを作るとき、アルゴリズムチームだけに任せてはいけない。セキュリティ、法務、運用、業務責任者も参加する必要がある。そうしないと、リリース後にリスクが一気に露出する。

コストはGPUだけではない

ローカルデプロイのコストは過小評価されがちだ。GPUやNPU以外にも、次のものを計算に入れる必要がある。

サーバー、ラック、電源、冷却、ネットワーク。
ストレージとバックアップ。
推論フレームワーク適配とエンジニアリング開発。
運用監視と障害対応。
モデルアップグレード、ロールバック、互換性テスト。
セキュリティ監査と権限システム。
業務側のプロンプト、RAG、ワークフロー構築。

呼び出し量が少ないなら、外部APIの方が安い可能性がある。呼び出し量が多く、データが敏感で、フローが安定している場合に、ローカルデプロイはコストを薄めやすい。

比較的合理的なのはハイブリッド構成だ。

高機密データはローカルモデルへ送る。
低機密の汎用タスクは外部APIを使ってもよい。
簡単なタスクは小モデルへ送る。
複雑なタスクはDeepSeek V4 Proへ送る。
高頻度タスクでは、キャッシュ、検索、モデルルーティングを優先して最適化する。

推奨される導入手順

企業は次の順序で進めるとよい。

まず高価値な場面を2-3個選び、全社展開しない。
コンシューマーGPUまたは小規模計算資源でPoCを行う。
まずFlash、蒸留モデル、量化モデルを動かし、RAGと権限をつなぐ。
複雑なタスクにProを導入して比較テストする。
実際の呼び出し量、遅延、失敗率、人手削減時間を記録する。
その後、国産チップクラスターまたはサーバーGPUを調達するか決める。
本番前にゲートウェイ、監査、監視、レート制限、ロールバックを補う。

この手順は、最初から大規模クラスターを買うより安定している。企業にとって最も怖いのは、モデルが弱いことではなく、多くの費用を使った後で、業務フローがモデル能力を受け止められないと分かることだ。

まとめ

DeepSeek V4は、企業のローカル私有化デプロイに大きな想像余地を与えた。しかし、それは単なる「ローカル版ChatGPT」ではない。本当の難点はエンジニアリングにある。ハードウェア、フレームワーク、モデルルーティング、権限、RAG、監査、監視、コスト制御をまとめて考える必要がある。

国産チップ路線は、コンプライアンス要求が高く、長期的にプライベートクラウドを構築する企業に向く。コンシューマーGPUクラスターは、試験導入や中小チームの迅速な検証に向く。Proは複雑な推論とAgentに向き、Flashや小モデルは大量の一般タスクに向く。

一文だけ覚えるなら、DeepSeek V4の私有化デプロイはハードウェア調達から始めるべきではない。業務シーン、データ境界、呼び出し規模から始めるべきだ。まずシーンを通し、その後で大モデルを使うか、どれくらいの規模にするか、どの計算基盤に載せるかを決める。

参考資料

Cline で DeepSeek V4 Pro を呼び出す方法

Fri, 01 May 2026 20:59:06 +0800

Cline はすでに OpenAI Compatible Provider をサポートしています。 DeepSeek API も OpenAI SDK 風の呼び出しに対応しているため、deepseek-v4-pro を Cline に接続するのは難しくありません。OpenAI Compatible を選び、DeepSeek の Base URL、API Key、モデル名を入力すればよいだけです。

以下では、VS Code 拡張機能の画面と Cline CLI の 2 通りで整理します。

DeepSeek API Key を準備する

まず DeepSeek の開放プラットフォームで API Key を作成します。

必要な値は 3 つです。

項目	入力内容
Provider	`OpenAI Compatible`
Base URL	`https://api.deepseek.com`
Model ID	`deepseek-v4-pro`

DeepSeek の公式ドキュメントでは、V4 シリーズは既存の OpenAI 互換インターフェースを使い、base_url は https://api.deepseek.com のまま、呼び出し時に model を deepseek-v4-pro または deepseek-v4-flash に設定すると説明されています。

Cline 拡張機能で設定する

VS Code の Cline 拡張機能を使っている場合は、次の手順で設定できます。

VS Code サイドバーの Cline を開く。
Cline の設定またはモデル設定ページに入る。
Provider で OpenAI Compatible を選ぶ。
API Key に DeepSeek API Key を入力する。
Base URL に次を入力する。

`1`	`https://api.deepseek.com`

Model ID に次を入力する。

`1`	`deepseek-v4-pro`

設定を保存し、Cline のチャット画面に戻って簡単なタスクでテストする。

まずは低リスクな読み取り専用タスクを試すとよいです。

現在のプロジェクトのディレクトリ構造を読み取り、このプロジェクトがどの種類のものか要約してください。ファイルは一切変更しないでください。

正常に読み取りと回答ができれば、モデルの接続は通っています。

Cline CLI で設定する

Cline CLI を使う場合は、cline provider configure openai-compatible で対話式設定に入れます。

例：

`1`	`cline provider configure openai-compatible`

対話中に次を入力します。

1
2
3

API Key: sk-...
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-pro

設定後、読み取り専用タスクでテストできます。

`1`	`cline "Summarize this repository structure without changing files."`

まずコストを下げたい場合は、Model ID を一時的に次へ変更してもよいです。

`1`	`deepseek-v4-flash`

複雑な計画、事実確認、複数ツールの協調、高リスクなコード変更が必要になったら、deepseek-v4-pro に戻します。

推奨するモデルの使い分け

DeepSeek V4 Pro と Flash は、役割を分けて使うほうが向いています。

モデル	向いている場面
`deepseek-v4-flash`	日常的なコード読解、小さな修正の一括処理、スクリプト生成、コンテキスト整理、低リスクなフロントエンド修正
`deepseek-v4-pro`	アーキテクチャ設計、複雑な bug、複数ファイルのリファクタリング、事実確認、複数ツール呼び出し、高リスクな変更

Cline のような Agent ツールでは、主なコストは長いコンテキスト、繰り返しのファイル読み取り、計画生成、複数ラウンドのツール呼び出しから発生します。軽いタスクなら Flash で量をこなし、より強い判断が必要なときに Pro へ切り替えるのが現実的です。

コンテキスト長はどう設定するか

DeepSeek V4 Pro と Flash はどちらも長いコンテキストをサポートします。 Cline で context window を手動入力する必要がある場合は、DeepSeek 公式モデルページにある 1M コンテキストを目安にできます。

実際には、最初からすべてのファイルをコンテキストに入れることはおすすめしません。 Cline はタスクに応じてファイルを読み取るため、通常は次の流れがよいです。

まずディレクトリ構造を確認させる；
次に関連ファイルを特定させる；
最後に対象ファイルだけを中心に修正させる。

このほうが Token を節約でき、タスクの境界も明確に保ちやすくなります。

よくある問題

1. モデルが存在しないと表示される

まず Model ID が次のように書かれているか確認します。

`1`	`deepseek-v4-pro`

DeepSeek V4 Pro、deepseek-v4、その他の表示名を書かないでください。

2. 401 または認証失敗が出る

API Key を確認します。

完全にコピーできているか；
余計な空白が入っていないか；
Cline が現在使っている provider 設定に入力されているか；
DeepSeek アカウントに利用可能な残高があるか。

3. 接続失敗と表示される

Base URL を確認します。

`1`	`https://api.deepseek.com`

末尾に /v1/chat/completions を追加しないでください。 Cline の OpenAI Compatible Provider が互換インターフェースのリクエストを自分で組み立てます。

4. Cline の呼び出しが高くつく

日常タスクは deepseek-v4-flash に切り替え、複雑なタスクだけ deepseek-v4-pro を使うとよいです。

また、タスク説明はできるだけ明確に書きます。

ログインページ関連ファイルだけを修正してください。無関係なモジュールはリファクタリングしないでください。まず計画を提示し、確認後にコードを変更してください。

Agent タスクで最も危ないのは境界が曖昧なことです。境界が明確なほど、読むファイルが少なくなり、ツール呼び出しも減り、コストを制御しやすくなります。

5. reasoning_content must be passed back エラー

次のようなエラーが出る場合があります。

{
  "message": "400 The `reasoning_content` in the thinking mode must be passed back to the API.",
  "code": "invalid_request_error",
  "modelId": "deepseek-v4-pro"
}

これは通常、Key、残高、Base URL の問題ではありません。DeepSeek V4 Pro の thinking mode と、現在のクライアント側の複数ラウンドのツール呼び出し履歴が一致していないことが原因です。

DeepSeek の公式ドキュメントでは、次のように説明されています。

thinking mode はデフォルトで enabled；
thinking mode では reasoning_content が返る；
あるラウンドで tool call が発生した場合、以降のリクエストではその assistant message 内の reasoning_content を API に一緒に返す必要がある；
クライアントが正しく返さない場合、400 が返る。

Cline が OpenAI Compatible Provider 経由で接続している場合、現在のバージョンが DeepSeek の reasoning_content を完全に保持して返していないと、2 ラウンド目やツール呼び出し後にこのエラーが出ることがあります。

試す順序は次のとおりです。

まず Cline を最新版に更新する；
通常の OpenAI provider ではなく、OpenAI Compatible を使っていることを確認する；
Cline がカスタム request body をサポートしている場合、thinking mode を無効化してみる：

{
  "thinking": {
    "type": "disabled"
  }
}

Cline が追加 body パラメータをサポートしていない場合は、当面この問題を起こさないモデルまたは互換プロキシサービスを使う；
Cline が DeepSeek V4 の reasoning_content 返送に対応したら、deepseek-v4-pro に戻す。

注意点として、thinking mode を無効にすると複雑な推論能力の一部は落ちますが、クライアントが reasoning_content を返さない互換性問題は回避できます。

そのままコピーできる設定

Provider: OpenAI Compatible
API Key: sk-あなたの DeepSeek API Key
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-pro

低コストモードにする場合：

Provider: OpenAI Compatible
API Key: sk-あなたの DeepSeek API Key
Base URL: https://api.deepseek.com
Model ID: deepseek-v4-flash

まとめ

Cline で DeepSeek V4 Pro を呼び出す要点は 3 つだけです。

Provider で OpenAI Compatible を選ぶ；
Base URL に https://api.deepseek.com を入力する；
Model ID に deepseek-v4-pro を入力する。

設定後は、まず読み取り専用タスクでテストし、それから実際のコード変更を任せるのがおすすめです。 Agent タスクを頻繁に実行するなら、Flash と Pro を分けて使うとよいです。Flash は高頻度の軽量タスク、Pro は複雑な判断とフォールバックを担当します。

参考情報：

DeepSeek V4 の値下げは AI Agent のコストモデルをどう書き換えるか

Fri, 01 May 2026 19:47:47 +0800

DeepSeek V4 の発表は、特別に大きな話題を作ったわけではありません。大規模な発表会もなく、すべての競合を一目で圧倒するようなベンチマークの物語もありませんでした。しかし数日後、本当に業界へ影響する部分が見え始めました。連続的な値下げです。

今回の変化で重要なのは、「モデルが少し強くなった」ことではなく、「利用コストが別の水準まで下がった」ことです。 Token 価格が、普通の Agent タスクなら数毛から数元で完了できるほど低くなると、多くの Coding Plan や Token Plan のビジネスロジックは見直しを迫られます。

発表当日は爆発的ではなかった

DeepSeek V4 に対する最初の反応は、そこまで熱狂的ではありませんでした。多くの人は R1 のような強い衝撃を期待していました。ベンチマークの全面的なリード、国産計算資源の検証、マルチモーダルと Agent 能力の同時爆発です。しかし実際に発表されると、それは堅実なアップグレードに近いものでした。

V4 Pro は確かに強いモデルです。特にコード、数学、長文コンテキスト、agentic coding では良い性能を見せます。ただし、同種のモデルを一瞬で色あせさせるような製品ではありません。そのため発表当日の世論には少し気まずさがありました。褒めたいけれど、十分に爆発的な切り口が見つかりにくかったのです。

本当の転換点は発表当日ではなく、その後の価格調整でした。

連続値下げこそが重要

DeepSeek V4 の発表後、価格は連続して下がり始めました。 DeepSeek の公式価格ページと元記事の整理によると、当時のおおよその価格は次のとおりです。

DeepSeek V4 Flash：入力 100 万 Token あたり約 1 元。キャッシュヒット後は 100 万 Token あたり約 2 分；
DeepSeek V4 Pro：入力 100 万 Token あたり約 3 元。キャッシュヒット後は 100 万 Token あたり約 2.5 分；
全シリーズの入力キャッシュヒット価格は、初回価格の 1/10 に低下；
V4 Pro は一時 75% 割引期間にあり、割引は 2026 年 5 月 31 日 23:59 まで延長されました。

米ドルの API 価格で見ると、さらに直感的です。

モデル	キャッシュヒット入力	非キャッシュ入力	出力	コンテキスト
`deepseek-v4-flash`	$0.0028 / 100万 Token	$0.14 / 100万 Token	$0.28 / 100万 Token	1M
`deepseek-v4-pro` プロモーション価格	$0.003625 / 100万 Token	$0.435 / 100万 Token	$0.87 / 100万 Token	1M
`deepseek-v4-pro` 通常価格	$0.0145 / 100万 Token	$1.74 / 100万 Token	$3.48 / 100万 Token	1M

ここで注意すべき点が 2 つあります。

第一に、V4 Pro の $0.435 / $0.87 はプロモーション価格であり、長期的な通常価格ではありません。 DeepSeek の公式説明では、この 75% 割引は 2026 年 5 月 31 日 15:59 UTC まで延長されています。

第二に、Agent のコストモデルで重要なのはキャッシュヒット価格です。 Flash のキャッシュヒット入力は $0.0028 / 100万 Token まで低く、Pro のプロモーション期間中のキャッシュヒット入力は $0.003625 / 100万 Token です。これは、繰り返し使われるプロジェクトコンテキスト、ツール定義、システムプロンプト、履歴要約が、完全な入力価格で課金されなくなることを意味します。

この価格のもっとも重要な点は、多くのタスクで Token コストが「気になりにくくなる」ことです。以前の開発者は、1 回の Agent タスクが大量のコンテキストを消費し、コードを何度も読み書きし、ツールを頻繁に呼び出すことを心配していました。今はキャッシュヒット率が十分に高ければ、コストをかなり低く抑えられます。

GPT、Claude との価格比較

DeepSeek 自体の価格だけを見ても、差はまだ感じにくいかもしれません。同時期によく使われるクローズドモデルと並べると、違いはより明確になります。

モデル	入力	キャッシュ入力	出力	適した場面
`deepseek-v4-flash`	$0.14 / M	$0.0028 / M	$0.28 / M	高頻度 Agent、通常の coding、バッチタスク
`deepseek-v4-pro` プロモーション価格	$0.435 / M	$0.003625 / M	$0.87 / M	複雑な coding、計画、事実確認
`deepseek-v4-pro` 通常価格	$1.74 / M	$0.0145 / M	$3.48 / M	プロモーション終了後の Pro コスト基準
GPT-5.5	$5 / M	$0.50 / M	$30 / M	高品質な複雑タスク、汎用推論
GPT-5.4	$2.50 / M	$0.25 / M	$15 / M	プログラミングと専門タスクの中位選択肢
GPT-5.4 mini	$0.75 / M	$0.075 / M	$4.50 / M	低コストの汎用/サブタスクモデル
Claude Opus 4.7	$5 / M	$0.50 / M	$25 / M	高品質な執筆、複雑推論、長時間タスク
Claude Sonnet 4.6	$3 / M	$0.30 / M	$15 / M	プログラミング、Agent、総合タスク
Claude Haiku 4.5	$1 / M	$0.10 / M	$5 / M	軽量タスク、要約、分類

この表で最も目立つのは出力価格です。 Agent はコンテキストを読むだけでなく、計画、パッチ、説明、ログ、次のアクションを継続的に生成します。出力が多い場合、DeepSeek V4 Pro のプロモーション価格 $0.87 / M は、GPT-5.5 の $30 / M や Claude Sonnet 4.6 の $15 / M と比べて、差がどんどん広がります。

V4 Pro の通常出力価格 $3.48 / M で計算しても、GPT-5.4、GPT-5.5、Claude Sonnet / Opus より明らかに低い水準です。タスクを Flash で処理できるなら、出力価格はさらに $0.28 / M まで下がります。

キャッシュ入力の差はさらに極端です。 DeepSeek V4 Flash のキャッシュ入力は $0.0028 / M である一方、GPT-5.5 と Claude Opus 4.7 のキャッシュ入力はいずれも $0.50 / M です。これは同じ桁の話ではありません。同じコードリポジトリを繰り返し読む Agent にとって、この差は通常のチャットよりも重要です。

Agent タスクが特に影響を受ける理由

AI Agent は普通のチャットとは違います。普通のチャットはたいてい一問一答で、入力コンテキストは比較的限られています。 Agent タスクは、プロジェクトファイルを繰り返し読み、計画を生成し、ツールを呼び出し、結果を確認し、さらにコードを修正します。

この種のタスクには 2 つの特徴があります。

Token 消費が大きい；
繰り返しコンテキストが多い。

2 点目が非常に重要です。コードプロジェクトでは、モデルは同じファイル群、ディレクトリ構造、エラーログ、変更結果を何度も読みます。プラットフォームがキャッシュヒットをサポートしていれば、繰り返し入力のコストは大幅に下がります。

元記事では実際の体験として、DeepSeek V4 Pro と Flash を Claude Code のようなツールに接続し、プロンプトリポジトリを取得してローカル検索サイトを作らせた例が紹介されています。タスクは最終的に完了し、総コストは 8 毛強ほどで、そのうち Pro のキャッシュヒット率は 98.7% に達しました。

この例は現実的な問題を示しています。Agent タスクが「同じプロジェクトを中心に繰り返し作業する」ほど、キャッシュヒットの価値は高くなります。 Web サイト生成、bug 修正、フロントエンド修正が数毛から数元で済むなら、サブスクリプションプランの魅力は下がります。

簡略化したタスクで差を見積もることもできます。 1 回の coding agent タスクが次を含むと仮定します。

50 万 Token の入力。そのうち 80% がキャッシュヒット可能；
5 万 Token の出力；
ツール呼び出し、検索、プラットフォーム上乗せ分は計算せず、モデル Token コストだけを見る。

おおよそのコストは次のとおりです。

モデル	推定コスト
DeepSeek V4 Flash	約 $0.03
DeepSeek V4 Pro プロモーション価格	約 $0.09
DeepSeek V4 Pro 通常価格	約 $0.36
GPT-5.4 mini	約 $0.30
GPT-5.4	約 $1.01
GPT-5.5	約 $1.75
Claude Sonnet 4.6	約 $1.11
Claude Opus 4.7	約 $1.65

この見積もりは、DeepSeek がすべてのタスクで優れているという意味ではありません。モデル品質、ツール呼び出しの安定性、長文コンテキスト検索能力、コードスタイル、事実の信頼性は個別に評価する必要があります。ただしコスト面では、DeepSeek V4 は「Agent にもう数ラウンド走らせる」ことの限界コストをかなり低くしました。これにより開発者は、毎回 Token 請求を心配するのではなく、より長いワークフロー、より頻繁なセルフチェック、より多くの候補案を設計しやすくなります。

Coding Plan と Token Plan の違い

多くの AI 製品はいま、Coding Plan と Token Plan という 2 種類のプランを提供しています。

大まかな違いは次のとおりです。

Coding Plan は通常、主にプログラミング向け；
Token Plan は通常、STT、TTS、画像生成、検索、embedding、RAG など、より多くの機能を含む；
STT は音声から文字への変換；
TTS は文字から音声への変換；
Coding Plan はユーザーをプログラミング場面に制限しがちで、他の機能は別途購入が必要になることが多い。

ビジネスの観点では、Coding Plan はビュッフェに近いものです。ユーザーは固定料金を前払いし、ベンダーは大多数の人が枠を使い切らないことに賭けます。多く使う人も少なく使う人もいて、平均するとプラットフォームは利益を出せます。

しかし従量制の Token 価格が十分に低くなると、ユーザーは計算し始めます。なぜ必ずプランを買わなければならないのか。 1 か月の実際の利用コストが数元から十数元程度なら、40 元や 200 元のプランは必ずしも割に合いません。

値下げがサブスクリプションモデルを揺さぶる理由

サブスクリプションプランが成立するには前提があります。ユーザーが単発利用を高いと感じるか、毎回の呼び出しコストを計算したくないことです。 Token 価格が高いとき、プランは安心に見えます。 Token 価格がほとんど気にならないほど低くなると、従量課金のほうが自然になります。

DeepSeek V4 の値下げは、底のコストを見せたようなものです。

Agent タスクは非常に安くできる；
長文コンテキストは必ずしも使えないほど高くない；
キャッシュヒットでコストを大きく下げられる；
普通の開発者は固定サブスクリプションを必ずしも必要としない；
モデルの入口は「プラン型プラットフォーム」から「低価格 API」へ移り得る。

これは Coding Plan を提供するプラットフォームにとって不快な変化です。従量呼び出しのほうが安く自由だとユーザーが気づけば、ひとつのプラットフォームのプランに縛られる必要はありません。

Flash と Pro をどう選ぶか

DeepSeek V4 の実用的な考え方のひとつは、Flash と Pro を分担して使うことです。

Flash は高頻度、軽量、反復可能なタスクに向いています。

bug 修正；
フロントエンド作成；
スクリプト作成；
通常のコード理解；
長いコンテキスト内の一般的な情報整理；
大量のサブタスク実行。

Flash は安く、速く、同じく長いコンテキストをサポートします。日常的な coding agent では、多くのタスクで最初から Pro を使う必要はありません。

Pro は複雑な判断やフォールバックタスクに向いています。

複数ラウンドの計画；
複雑な Agent ワークフロー；
複数回の function call；
事実確認；
財務・経済リサーチ；
より強い知識と判断力が必要なコンテンツ生成；
高リスクなコード変更。

合理的な構成は、Flash が量をこなし、Pro がフォールバックを担当する形です。通常タスクはまず Flash で始め、長期計画、複雑な判断、事実確認、複数ツールの協調が必要になったら Pro に切り替える。こうすればコストを抑えつつ、モデル品質も保てます。

DeepSeek がこの価格を出せる理由

DeepSeek は多くの大手企業と事業構造が異なります。 EC、SNS、ショート動画、クラウドコンピューティング、スマートフォン、自動車、オフィススイート、OS、ブラウザ、大規模な企業向け SaaS エコシステムを持っていません。

つまり、ユーザーを完全なプラットフォーム内に閉じ込める必要がありません。安いテキストモデル能力だけを売ることができます。他の機能は、必要に応じてどこを呼び出してもよいのです。

大手企業のロジックは通常異なります。その Coding Plan や Token Plan を買うと、クラウド、検索、画像生成、音声、データベース、開発ツールのエコシステムへ引き込まれます。プランは単純にモデルを売るものではなく、ユーザーの入口を取りに行くものです。

DeepSeek の戦い方はより直接的です。テキストモデルの価格を下げ、Agent のデフォルトモデル入口になることを狙います。デフォルト入口を取れれば、多くの開発者とツールチェーンは自然にそれへ適応していきます。

オープンモデルとデフォルト入口

DeepSeek V4 がオープンモデル路線を維持するなら、サードパーティのクラウドベンダーやプラットフォームが自前でデプロイし、サービスを提供する可能性があります。 DeepSeek にとって、それは普及でもあり、同時に流量の分散でもあります。

低価格の公式 API の意味はここにあります。公式価格がすでに十分低ければ、他のプラットフォームがデプロイできたとしても、価格面で明確な優位を出すのは難しくなります。ユーザーは、デフォルトで安く安定した入口を直接使う傾向になります。

Agent ツールでは特にそうです。 Agent タスクは長文コンテキスト、キャッシュ、ツール呼び出し、安定したスループットに依存します。あるモデルがこれらの場面で十分安ければ、デフォルト選択肢になる可能性があります。

Coding Plan は完全に無用ではない

これは Coding Plan がすぐ消えるという意味ではありません。それに合うユーザーはまだいます。

もし一部のユーザーが本当に高頻度で、毎日プランの上限まで使うなら、固定サブスクリプションはまだ得かもしれません。ビュッフェと同じで、誰も元を取れないなら、ユーザーも買おうとはしません。

ただし問題は、ほとんどのユーザーがそのような極端な高頻度ユーザーではないことです。低頻度ユーザー、軽量な開発者、たまにスクリプトを書いたりプロジェクトを直したりする人には、従量課金のほうが向いています。 DeepSeek が従量コストを下げると、プランの魅力は弱まります。

今後は、より階層化された選択が起こりやすくなります。

高頻度のヘビーユーザーは Coding Plan を買い続ける；
普通のユーザーは低価格 API へ移る；
Agent ツールはタスクに応じて Flash / Pro を自動選択する；
プラットフォームのプランは、ワークフロー、IDE 統合、デプロイ、チーム管理、セキュリティ監査など、モデル以外の価値をより多く提供する必要がある。

まとめ

DeepSeek V4 の発表は、ベンチマークによって最大の衝撃を作ったわけではありません。本当に業界の期待を変えたのは、その後の値下げでした。

入力 Token とキャッシュヒット価格が非常に低くなると、AI Agent の利用コストは変わります。これまで高価に見えていた長文コンテキスト、コードプロジェクト分析、複数ラウンドのツール呼び出しが、今では数毛から数元の日常的な消費になる可能性があります。

これは Coding Plan と Token Plan のビジネスロジックを直接揺さぶります。ユーザーが従量課金で、モデルとツールを自由に組み合わせられ、さらにコストも十分低いなら、特定のプラットフォームプランに縛られる必要はありません。

DeepSeek V4 が今回本当に動かしたのは、モデル能力ランキングだけではなく、AI Agent のコスト構造とデフォルト入口をめぐる競争です。

参考情報：

free-claude-code：プロキシで Claude Code を OpenRouter、DeepSeek、ローカルモデルへ接続する

Fri, 01 May 2026 03:41:49 +0800

free-claude-code は、Claude Code 向けの Anthropic-compatible proxy です。

考え方は Claude Code を破解することでも、公式の無料 Claude サービスを提供することでもありません。ローカルで Anthropic API の形に互換性を持つプロキシサービスを起動し、Claude Code からのリクエストを他のモデルバックエンドへ転送します。README では NVIDIA NIM、OpenRouter、DeepSeek、LM Studio、llama.cpp、Ollama などが挙げられています。

簡単に言うと、Claude Code のターミナル体験は好きだが、モデルリクエストは別の provider やローカルモデルへ接続したい、という問題を解決するものです。

解決する問題

Claude Code の対話体験は開発タスクに向いています。

ターミナル内でコードを読み、ファイルを変更し、コマンドを実行し、プロジェクトコンテキストに基づいてタスクを進められます。ただし、多くのユーザーは常に同じモデルバックエンドを使いたいとは限りません。

OpenRouter 上の異なるモデルを試したい
DeepSeek のようなモデルでコストを下げたい
リクエストをローカル Ollama に接続したい
LM Studio や llama.cpp でローカルモデルを動かしたい
開発環境でプロキシ入口を統一したい
Claude Code ワークフロー内で異なるモデルの挙動を比較したい

free-claude-code の位置づけは、Claude Code とこれらのモデルサービスの間に互換プロキシを置くことです。

Claude Code は Anthropic 風にリクエストを送り続け、プロキシがそのリクエストを異なるバックエンドへ適配します。

仕組み

3 層構造として理解できます。

フロントエンドは Claude Code
中間層は free-claude-code プロキシ
バックエンドは OpenRouter、DeepSeek、ローカルモデル、または他のモデルサービス

Claude Code は、自分が Anthropic-compatible API にアクセスしていると考えます。

プロキシはリクエストを受け取り、設定に応じて target provider を選び、必要なフィールドを変換し、応答を Claude Code に返します。

この構造の利点は、Claude Code 自体を変更する必要がなく、すべてのモデルサービスが Claude Code をネイティブにサポートする必要もないことです。プロキシがインターフェースを合わせられれば、より多くのモデルを同じワークフローへ接続できます。

対応バックエンド

README に挙げられている方向は次のとおりです。

NVIDIA NIM
OpenRouter
DeepSeek
LM Studio
llama.cpp
Ollama

これらのバックエンドは、異なる利用スタイルを表しています。

OpenRouter はモデル集約入口に近く、さまざまな商用モデルやオープンソースモデルを試せます。

DeepSeek は、中国語能力、コード能力、コストを重視する人に向いています。

LM Studio、llama.cpp、Ollama はローカルモデル寄りです。自分のマシンや社内環境でモデルを動かし、外部 API 依存を減らし、オフライン実験をしやすくします。

NVIDIA NIM は、企業や GPU 推論デプロイの場面により向いています。

なぜ Anthropic-compatible proxy なのか

Claude Code はもともと Anthropic のインターフェースとモデル習慣を前提に設計されています。

他のモデルへ接続しようとすると、最初に問題になるのはインターフェースの違いです。

リクエストフィールドが違う
モデル名が違う
streaming 形式が違う
tool use の表現が違う
エラー応答形式が違う
token とコンテキスト制限が違う

プロキシ層の価値はここにあります。

Claude Code 側から見えるインターフェースを Anthropic に近い形に保ち、バックエンド側で適配します。ユーザーにとっては、一度プロキシを設定すれば、同じ Claude Code ワークフローの中で異なるモデルを試せます。

向いている場面

free-claude-code は次のような場面に向いています。

Claude Code のターミナルワークフローを使いたい
非 Anthropic モデルを Claude Code 内で試したい
モデル呼び出しコストを下げたい
Claude Code を OpenRouter に接続したい
DeepSeek などの互換モデルサービスに接続したい
Ollama、LM Studio、llama.cpp でローカルモデルを使いたい
チーム用に統一されたモデルプロキシ入口を用意したい

公式 Claude Code を普通に使っていて、モデル提供者、コスト、ローカルデプロイに特別な要求がないなら、この種のプロキシは必須ではありません。

しかし、頻繁にモデルを比較したり、Claude Code をローカルやサードパーティーモデルへ接続したいなら、この種のツールは便利です。

OpenRouter や Ollama を直接使う場合との違い

OpenRouter、Ollama、LM Studio を直接使う場合、通常はモデルとチャットするか、API 経由でモデルを呼び出します。

free-claude-code の目的はそれらのサービスを置き換えることではなく、Claude Code という開発ワークフローへ接続することです。

違いは次の点にあります。

Claude Code のターミナル体験をそのまま使える
AI がコードリポジトリを中心にタスクを実行できる
モデルバックエンドを別 provider に切り替えられる
ローカルモデルも Claude Code ワークフローへ入れられる
設定がプロキシ層に集中し、各ツールを個別に変えなくてよい

つまり、新しいチャットクライアントではなくブリッジに近いものです。

ローカルモデルで注意すべきこと

Claude Code をローカルモデルへ接続するのは魅力的ですが、現実的な制限もあります。

第一に、モデル能力の差です。

Claude Code のタスクは単なるチャットではありません。コード理解、変更計画、ファイル編集、コマンド出力処理を含みます。ローカルの小さなモデルがこれらを安定してこなせるとは限りません。

第二に、コンテキストウィンドウです。

コードタスクはコンテキストを多く使います。モデルのコンテキストが小さいと、ファイルを読み切れない、制約を見落とす、多段階タスクで背景を失う、といった問題が起きます。

第三に、tool use の互換性です。

Claude Code ワークフローはツール呼び出しと構造化動作に依存します。バックエンドモデルがチャットできても、ツール呼び出しプロトコルに従うのが得意とは限りません。

第四に、速度とハードウェアです。

ローカルモデルの速度はマシン構成、量子化方式、モデルサイズに依存します。コードタスクで応答が遅すぎると、体験は大きく下がります。

そのため、ローカルモデルは実験、低リスクタスク、特定場面に向いています。複雑なコードタスクでは、モデル能力を見て慎重に選ぶ必要があります。

利用上の境界

この種のプロジェクトはタイトルで誤解されやすいので、境界を明確にしておく必要があります。

第一に、これは公式 Claude Code の無料枠ではありません。

Claude Code のリクエストを他のモデルバックエンドへ転送するだけです。OpenRouter、DeepSeek、NVIDIA NIM、その他 API を使う場合は、それぞれの価格、クォータ、利用規約に従う必要があります。

第二に、認可を回避するためのツールではありません。

どのプロキシツールを使う場合でも、Claude Code、モデル提供者、プロジェクト自体のライセンスや利用規約を守るべきです。公式制限を回避する手段として理解しないでください。

第三に、プロキシはリクエスト内容を処理します。

コード、コマンド出力、プロジェクトコンテキストがプロキシとバックエンドサービスを通る可能性があります。デプロイ時にはログ、キー、ネットワーク、プライバシー境界を考える必要があります。会社コードや機密プロジェクトでは、制御された環境を使うべきです。

第四に、モデルごとの挙動差は大きいです。

同じ Claude Code 操作でも、モデルを替えるとまったく異なる動作になることがあります。すべてのモデルが Claude を置き換えられると考えない方がよいです。

LiteLLM などのプロキシとの関係

考え方として、free-claude-code は「互換インターフェースプロキシ」に属します。

この種のツールの共通目標は、上位アプリケーションと下位モデルサービスの結合を減らすことです。上位アプリケーションは比較的統一されたインターフェースだけを見ればよく、下位 provider は設定で切り替えられます。

プロジェクトによって重点は異なります。汎用モデルゲートウェイ寄りのものもあれば、OpenAI-compatible API 寄りのものもあり、Claude Code のようなツール向けに特化しているものもあります。

free-claude-code が注目に値するのは、汎用チャットプロキシではなく、Claude Code を直接ターゲットにしている点です。

向いているユーザー

ある程度自分で調整できるユーザーに向いています。

Claude Code に慣れている
API key と model provider の設定方法を知っている
プロキシサービスの起動と環境変数を理解できる
ネットワーク、ポート、モデル名、streaming 問題を調査できる
コードタスクで異なるモデルの挙動を比較したい

開箱即用だけを求めるなら、公式設定の方がたいてい簡単です。

プロキシを立て、モデルを切り替え、パラメータを調整し、Claude Code をより多くのモデル環境へ接続したいなら、このプロジェクトは研究する価値があります。

参考

Alishahryar1/free-claude-code

最後に

free-claude-code の価値は「free」という言葉ではなく、Claude Code とより多くのモデルバックエンドの間に橋を架けることです。

Claude Code の開発体験を保ちながら、OpenRouter、DeepSeek、ローカルモデル、企業向け推論サービスを試したいとき、このような Anthropic-compatible proxy は役に立ちます。

DeepSeek V4 Pro と GPT-5.5 を比較：フロントエンド・文章作成・コード実測で見えた想像以上の差

Sat, 25 Apr 2026 11:12:00 +0800

DeepSeek V4 Pro と GPT-5.5 の比較は、最近ますます話題になりやすくなっています。もはや問題は「使えるかどうか」ではなく、フロントエンド、文章作成、コードという3つの高頻度な場面で、どちらが主力として向いているのかに移っています。

この手の比較では、まず「どちらが強いのか」と聞きたくなりがちです。
しかし本当に価値があるのは、たいてい別の問いです。実際のタスクの中で、どちらがより安定し、コミュニケーションコストが低く、そのまま次に進める成果を出しやすいのか。

まず結論を簡単に言えば、だいたい次のように考えられます。

よりバランスの取れた出力や、完成度の高いプロダクト体験を求めるなら、多くの人はまず GPT-5.5 を見る
中国語環境での高頻度な反復、コスト意識の高さ、応答スピードを重視するなら、DeepSeek V4 Pro は有力な候補になる
実際の体験を決めるのは、モデル名そのものよりも、タスクの種類、プロンプトの与え方、そしてその後も修正を続けるかどうかであることが多い

以下、代表的な3つの比較シーンに分けて見ていきます。

1. フロントエンドタスク：見るべきは「ページを書けるか」ではなく、「その後も直し続けられるか」

フロントエンド作業は、結果が目に見えやすいため、モデル比較に向いているように見えます。
ページが動くか、見た目が良いか、構造が整理されているかは、すぐに判断できます。

しかし本当の差は、最初の版が書けるかどうかよりも、むしろ次のような点に現れます。

構造は十分に明確か
コンポーネント分割は自然か
一か所を直したときに別の場所まで壊れないか
複数ラウンドの指示でも同じ実装方針を保てるか

だからこそ、初回の見た目が派手なフロントエンドデモでも、実際のワークフローに入れると必ずしも優位とは限りません。

たとえば次のようなタスクなら、

動くページのプロトタイプを素早く作る
ランディングページの案をまず形にする
必要なスタイル、ボタン、カード、フォームなどを埋める

どちらのモデルでもかなり近いところまでは持っていけることが多く、差は出力スタイルに現れやすいです。

しかしタスクが次のように変わると、

UI を何度も継続的に修正する
既存コードを読みながら続きを直す
コンポーネント構成、スタイルの一貫性、保守性を同時に考える
静的ページから実際のプロジェクトコードへ段階的に進める

見るべき点は「初回でどちらが見栄えが良いか」ではなく、「5ラウンド後でもどちらが崩れにくいか」になります。

つまりフロントエンド比較で本当に見るべきなのは、ページを生成できるかどうかではありません。制約を追加し続けても、構造の安定性、命名の一貫性、修正コストの低さを保てるかどうかです。

2. 文章作成タスク：比べるべきは文字数ではなく、文体の安定性とリライトのしやすさ

文章作成は、特に見誤りやすい領域のひとつです。

というのも、最初の出力だけを見れば、どちらもそれなりによく見えることが多いからです。
構成は整い、段落もそろい、文体も滑らかで、一見すると大差がないように感じます。

しかし、そこで一歩先まで進めると差が出てきます。

想定読者を正確に理解できるか
同じテーマで文体を切り替えられるか
リライト時に元の要点を落とさないか
要約、膨らませる作業、タイトル変更、構成変更でも安定しているか

文章作成で怖いのは「書けないこと」ではなく、「書けたように見えるのに、結局かなり直す必要があること」です。

そのため、DeepSeek V4 Pro と GPT-5.5 を比べるときは、単に1本ずつ記事を書かせるより、次のような連続テストのほうが実用的です。

まず初稿を書く
別のトーンで書き直す
もっと短い版に圧縮する
クリックを取りやすい見出し向け、あるいは検索流入向けに組み替える

その数ラウンドでも要点が散らず、表現がぶれず、構成が崩れないなら、そのモデルは実際の文章作成ワークフローでより高い価値を持ちます。

つまり文章作成で本当に比べるべきなのは「文才」ではなく、リライト能力、指示への従いやすさ、継続的な協業感です。

3. コードタスク：本当の差は長い作業チェーンでの安定性に出る

コード関連の作業は、フロントエンドよりもモデルの実力を露呈しやすい分野です。なぜなら、単に出力するだけではなく、現実のプロジェクトと接続しなければならないからです。

すぐに次のような問題にぶつかります。

既存のプロジェクト構造を理解できるか
複数ファイルを同時に修正できるか
修正後に新しい問題を持ち込まないか
エラーやログを追ってデバッグを続けられるか
数ラウンド後でも、すでに何をやったか覚えているか

この種のタスクでユーザーが本当に気にするのは、単体のコード片が美しいかどうかではありません。作業を継続的に前へ進められるか、それとも後片付けを自分がしなければならないのかです。

だから DeepSeek V4 Pro と GPT-5.5 を比較するとき、本当に見るべきなのは単発のコード問題ではなく、次のような実務に近い流れです。

既存のリポジトリを読む
バグを見つける
関連する複数ファイルを修正する
エラーに基づいてさらに直す
最後に結果を整理して説明する

タスクがこのような連続進行型になるほど、コンテキスト保持力、実行の癖、説明の質、手戻り率は、単発の回答品質よりも重要になります。

そのため、コード作業では「ずっと1つのモデルだけを使う」という形ではなく、タスクの段階によって主力を切り替えるユーザーが多くなるのです。

4. 本当に比べるべきなのは勝敗ではなく、「どの種類のタスクを誰に任せると得か」

DeepSeek V4 Pro と GPT-5.5 を並べて、ただ総合チャンピオンを決めようとしても、結局は中身の薄い結論になりがちです。

現実のタスクは同じ問題ではないからです。

単発生成もある
複数ラウンドの協業もある
中国語での文章作成もある
エンジニアリング変更もある
速度重視もある
安定性重視もある
コスト重視もある

だから、実際の使い方に近いのは、タスクの目的ごとに考えることです。

より完成度の高い総合体験、成熟した対話、安定した汎用出力を求めるなら、まず GPT-5.5
中国語環境で高頻度に試行錯誤し、素早く反復し、費用対効果も重視するなら、DeepSeek V4 Pro を本格的にワークフローへ入れる価値がある
タスク自体が長いチェーン、多段階修正、複数人協業なら、初回結果だけで判断せず、5ラウンド後も安定しているかを見るべき

言い換えれば、本当に問うべきなのは「どちらが絶対的に強いか」ではなく、
フロントエンド、文章作成、コードという3種類のタスクで、いまの自分にとってどちらがより手になじむ道具かということです。

5. ちゃんと意味のある比較をするには

自分で DeepSeek V4 Pro と GPT-5.5 を試すなら、1ラウンドだけで判断するより、次のようなやり方のほうがずっと信頼できます。

両方に同じ初期要件を与える
制約条件をそろえる
3〜5ラウンド連続で追質問する
出力品質、脱線回数、手戻り量を記録する
最後に速度、コスト、最終的な使いやすさを比較する

こうして得た結果のほうが、「最初にどちらが派手だったか」よりも、実際の仕事に近い判断材料になります。

特にフロントエンド、文章作成、コードのような分野では、体験を決めるのはスタートの派手さではなく、最後まで一緒に仕事を進められるかどうかです。

6. まずはこう覚えておけばよい

ひとまず使える形で覚えるなら、次のようにまとめられます。

GPT-5.5：総合型で、製品として洗練された、標準的な作業台に近い
DeepSeek V4 Pro：中国語環境や高頻度な試行錯誤で、日常ワークフローに入れる価値が高い競争相手
本当の比較ポイント：初回の派手さではなく、複数ラウンド後の安定性と手間の少なさ

この種の比較で本当に重要なのは、決して「誰が勝ったか」だけではありません。
自分のフロントエンド、文章作成、コードのタスクにおいて、どちらを使うと継続的に前へ進みやすく、手戻りが少なく、安定して成果を出せるかです。

DeepSeek-V4 Preview 公開：1M コンテキスト、2 モデル構成、API 移行の注意点

Fri, 24 Apr 2026 22:39:46 +0800

DeepSeek は 2026-04-24 に DeepSeek V4 Preview Release を公開しました。公式ニュースページを見ると、今回の更新の軸はかなりはっきりしています。1M context、V4-Pro と V4-Flash の 2 モデル構成、Agent 向けの専用最適化、そして API 側のモデル移行です。

一言でまとめるなら、今回のリリースの本質は、DeepSeek が単に「より強いモデル」を目指しているだけではなく、超長コンテキストと Agent 能力をそのまま実運用に載せやすい形へ進めていることです。

1. 今回公開されたもの

公式ページによると、DeepSeek-V4 Preview は主に次の 2 つのラインで構成されています。

DeepSeek-V4-Pro
DeepSeek-V4-Flash

それぞれの公式説明も非常に分かりやすいです。

DeepSeek-V4-Pro：1.6T total / 49B active params
DeepSeek-V4-Flash：284B total / 13B active params

名前を見るだけでも、今回は単一モデルの更新ではなく、高性能側と高コスト効率側を同時に展開していることが分かります。

V4-Pro はより高い性能上限を重視しており、公式は世界トップクラスのクローズドモデルに競合できるとしています。一方の V4-Flash は、速度、効率、コストをより重視した位置づけで、レイテンシや API 料金に敏感な用途に向いています。

2. `1M context` が今回いちばん目立つポイント

公式ページで最も印象的な表現の 1 つが、「Welcome to the era of cost-effective 1M context length.」 です。

DeepSeek は今回、単に長コンテキスト対応をうたっているだけではありません。1M context をこの世代の標準能力として打ち出しています。ページでも次のように明記されています。

1M context は公式 DeepSeek サービス全体の標準になった
V4-Pro と V4-Flash はどちらも 1M context をサポートする

重要なのは、これが単に「より多くの token を詰められる」という話ではないことです。実際には次のような作業に直結します。

大規模コードベースの理解
長文書の Q&A や情報整理
複数ターンにまたがる Agent ワークフロー
複数ファイル、複数ツール、複数段階にまたがる複雑なタスク

コンテキストウィンドウが十分に大きければ、途中で文脈を落として何度も読み直すことが減ります。これは Agent コーディングや複雑な知識作業で特に重要です。

3. `V4-Pro` が主に強調していること

公式ページの表現を見ると、DeepSeek-V4-Pro が強く押し出しているのは次の 3 点です。

Agentic Coding 能力
世界知識
推論能力

ページでは、V4-Pro が Agentic Coding ベンチマークでオープンソース SOTA を達成したこと、世界知識では現行のオープンモデルの中で最上位クラスであり Gemini-3.1-Pro にのみ後れを取ること、さらに数学、STEM、コーディングで現行のオープンモデルを上回り、トップクラスのクローズドモデルに対抗できることが示されています。

つまり V4-Pro は、単純な質問応答モデルというより、高難度推論、複雑なコーディング、長いタスクの遂行に寄せた設計です。

4. `V4-Flash` は単なる縮小版ではない

もう 1 つ注目すべき点は、DeepSeek が V4-Flash を単なる廉価版として扱っていないことです。むしろ、実務的な多くのタスクでは十分に強いモデルであることを前面に出しています。

ニュースページによると、V4-Flash は：

推論能力が V4-Pro にかなり近い
シンプルな Agent タスクでは V4-Pro と同等の性能を持つ
パラメータ規模が小さく、応答が速く、API 価格も低い

つまり今回は、「1 つが旗艦、もう 1 つが入門」という極端に分かれた構成ではなく、次のような役割分担に近いです。

V4-Pro：より高い性能上限を狙う
V4-Flash：より低いレイテンシと優れたコスト効率を狙う

開発者にとっては、このほうが実際には使いやすい構成です。多くの本番タスクで必要なのは、理論上最強のモデルではなく、十分に強く、十分に速く、十分に安いモデルだからです。

5. Agent 最適化がかなり前面に出ている

今回の発表でもう 1 つ明確なのは、DeepSeek が V4 を Agent シナリオへ積極的に寄せていることです。

公式ページでは、DeepSeek-V4 が次のような主要 AI Agent とシームレスに統合されていると紹介されています。

Claude Code
OpenClaw
OpenCode

加えて、DeepSeek 自身も社内の agentic coding に V4 を使っていると述べています。

これは、対象が単なるチャットや通常の補完ではなく、コードを読み、構造を理解し、ツールを呼び出し、結果を生成し、その一連の流れをつなぐ長いワークフローになっていることを意味します。

最近 coding agent を追っているなら、この点は見逃しにくいです。モデル提供側の競争軸が、ベンチマークだけではなく「本当にワークフローに組み込めるか」へ広がっているからです。

6. 構造的な工夫は長コンテキスト効率のため

技術面では、公式ページは今回の構造的な工夫を次のようにまとめています。

token-wise compression
DSA (DeepSeek Sparse Attention)

方向性は非常に明快です。長コンテキストを、より安く、より高効率にし、計算コストとメモリコストをできるだけ抑えることです。

ニュースページでは完全な技術詳細までは踏み込んでいませんが、少なくとも DeepSeek が単純に計算資源を増やして長ウィンドウを支えているだけではなく、長コンテキスト効率のためのアーキテクチャ最適化も行っていることは読み取れます。

実際の利用者にとっては、単にコンテキスト数値が大きいことよりも、こちらのほうが重要な場合が多いです。なぜなら実用性を決めるのは、1M が使えるかどうかだけではなく、次のような点だからです。

速度が実用範囲に収まるか
コストが許容範囲に収まるか
長コンテキスト処理が実際に安定するか

7. API はすでに利用可能だが、モデル切り替えに注意

公式ページでは、今回の API が当日から利用可能であることも明記されています。

切り替え方法も比較的シンプルです。

base_url はそのまま
モデル名を deepseek-v4-pro または deepseek-v4-flash に変更する

さらに、両モデルが次をサポートするとされています。

1M context
Thinking / Non-Thinking の 2 モード
OpenAI ChatCompletions
Anthropic APIs

つまり、すでに DeepSeek API を使っているなら、移行の難しさはそれほど高くありません。主な作業はモデル名の差し替えと挙動確認です。

8. 旧モデルの終了時期も明確に書かれている

開発者にとって、この発表の中で見落とせない情報の 1 つが旧モデルの終了通知です。

公式には：

deepseek-chat
deepseek-reasoner

が 2026 年 7 月 24 日 15:59 UTC 以降に完全に廃止され、アクセス不能になると書かれています。

またページでは、現在この 2 つのモデルは実質的に deepseek-v4-flash の非思考 / 思考モードへルーティングされているとも説明されています。

そのため、もし今もプロジェクト内で deepseek-chat や deepseek-reasoner を直接参照しているなら、正式終了直前まで待つのではなく、今のうちに移行計画を進めるべきです。

9. この発表をどう読むべきか

今回の更新をいくつかの要点に圧縮すると、次のようになります。

DeepSeek は 1M context を高級機能ではなく標準機能へ変え始めている
2 モデル戦略がより明確になった。1 つは性能上限、もう 1 つは速度とコスト効率
Agent 能力がかなり中心的な位置に置かれている
API の移行経路は比較的シンプルだが、旧モデルの終了時期には早めの対応が必要

一般ユーザーにとっては、長文書、長いコード文脈、長い作業フローを 1 回のコンテキストに収めやすくなるのが分かりやすい変化かもしれません。
開発者にとってより重要なのは、すでに Agent、コードアシスタント、情報整理、複雑な自動化ワークフローを作っているなら、この世代のモデルは明らかにそうした用途を意識して設計されているという点です。

今回の DeepSeek の発表は、単なる通常のモデル更新というより、次の製品方向をより明確に示したものだと見たほうが自然です。超長コンテキスト、Agent 最適化、そして実用的な API 運用性です。