Token Efficiency とは何か：DeepSeek V4 から見る大モデルの計画と小モデルの実行

Fri, 15 May 2026 08:59:33 +0800

AI コーディングで次に重要になる指標は、最強モデルを使うことではなく、より少ない token、低いコスト、安定したプロセスで、より多くの検証可能な仕事を終えることかもしれない。

それが Token Efficiency の価値だ。

多くの人は Token Efficiency を、安いモデル、長いコンテキスト、安い cache hit と考える。しかしそれは基礎条件にすぎない。本当に生産性に変えるのは、モデルの役割分担、タスク編成、コンテキスト予算、評価体系だ。

DeepSeek V4 の位置づけ

DeepSeek V4 は単に強いモデルを出しただけではない。Token Efficiency に必要な二つの能力を V4 Pro と V4 Flash に分けた。

V4 Pro は計画、推論、アーキテクチャ判断、重要レビューに向く。V4 Flash は高頻度実行、バッチ書き換え、コード補完、資料整理、agent ループ内の通常ノードに向く。

AI コーディングでは次のように使える。

V4 Pro: planner / consultant。要件分解、技術設計、複雑な bug 分析、アーキテクチャレビュー、最終受け入れ。
V4 Flash: executor。ファイル走査、単純実装、テスト補完、文書整理、候補生成、反復タスク。

DeepSeek の API 文書では、V4 Flash と V4 Pro はどちらも 1M context、JSON Output、Tool Calls、Chat Prefix Completion、FIM Completion をサポートする。価格ページでは cache hit input が別価格で、input cache hit 価格が公開時の 10 分の 1 になったことも示されている。

1M context は複雑な agent タスクの圧縮問題を減らす。低い cache hit 価格は、長い system prompt、プロジェクト文書、コード片、履歴を繰り返し入れるコストを下げる。Flash / Pro の分離は、全ステップを高価なモデルで走らせるか、不安定な小モデルだけで走らせるか、という二択を避ける。

DeepSeek V4 の意味は、別のモデル選択肢ではなく、「consultant model + executor model + harness orchestration」の現実的なコスト構造を提供することにある。

最強モデルにすべてをさせない

従来は最も賢いモデルに、要件分析、実装、テスト、まとめを全部任せがちだった。

しかし多くの作業は最高レベルの推論を必要としない。高価なモデルは、重要な判断点だけに出る consultant、architect、planner のように使うべきだ。

大モデルは問題分解と重要判断。
小モデルは実行、バッチ処理、反復修正。
tool と harness はプロセス、状態、コンテキスト、検証。
人間は製品定義、受け入れ、取捨選択。

これで最先端推論を機械的な実行に浪費しにくくなる。

コンテキストは大きければよいわけではない

coding agent では、コード、文書、会話履歴、テスト出力、ログがコンテキストを消費する。上限に近づくと圧縮、忘却、誤判断が起きやすい。

しかし長いコンテキストは、すべてを詰め込んでよいという意味ではない。

各タスクは、必要ファイル、判断に関係する文書、現在段階に必要な履歴、明確な入出力、次ノードへ渡す構造化要約だけを持つべきだ。

安い context は無関係な情報を入れたくさせる。だがノイズはモデルを賢くしない。

Harness が単体モデルより重要

Claude Code、Codex、その他の coding agent を安いモデルにつなぐだけでは十分ではない。小モデルは長いタスクでずれやすく、強いプロセス制御が必要だ。

harness は調度システムであり、タスク分割、ノード実行、モデル選択、結果検証、失敗時の再試行、コンテキスト受け渡しを決める。

この層がなければ、小モデルは安いだけだ。この層があると、小モデルはレバレッジになる。

DAG でタスクを分ける

複雑なタスクは DAG に分けられる。たとえば機能開発は、要件確認、技術設計、タスク分解、実装、テスト補完、Code Review、修正、PR 提出にできる。

各ノードは独立した agent にできる。役割、prompt、tool 権限、出力形式を分け、長い会話ではなく構造化結果を渡す。

これによりノードは短くなり、小モデルで完了しやすくなり、どこが失敗しているかも測りやすくなる。

タスクは複数回走らせてもよい

token が十分安ければ、同じタスクを一度だけ走らせる必要はない。異なるモデル、prompt、編成で複数回走らせ、最良の結果を選ぶ、または有用部分を統合できる。

向いているのは設計案、文章、テストケース、bug 仮説、リファクタリング案、Code Review だ。共有状態を変える作業や外部副作用がある作業には向かない。

目的は運試しではなく、比較可能なサンプルを得て、編成とモデル選択を改善することだ。

評価体系が必要

Token Efficiency は価格だけでは測れない。安くても失敗率が高ければ、人間の時間を食って高くつく。

タスク完了率、人間の介入回数、tool call 失敗率、テスト通過率、review 指摘数、タスクごとの token コスト、時間、手戻り回数、モデル組み合わせの差を記録する。

このデータがあって初めて、小モデルでよい作業、大モデルが必要な作業、人間が判断すべき作業を分けられる。

業務フローを原子化する

全員が harness を自作する必要はない。しかし自分の業務を原子ノードに分解することは今からできる。

コンテンツ制作なら、企画、調査、アウトライン、初稿、ファクトチェック、スタイル調整、SEO タイトル、多言語翻訳、公開チェック。

ソフトウェア開発なら、要件確認、技術設計、データ構造、API 変更、単体テスト、実装、移行スクリプト、文書、Review。

各ノードは入力、出力、受け入れ条件、コンテキストを明確にする。harness が成熟すれば、そのまま接続できる。

ハードウェアは最優先ではない

Token Efficiency の話はすぐローカルデプロイや GPU に向かう。しかし多くの人にとって最初の選択は API でよい。

経済モデルが通る前に高価なハードを買うのは、コストの前払いにすぎない。まず API で workflow を通し、評価とコストを記録し、高頻度の実行ノードを見つけてから、ローカル化を検討すべきだ。

まとめ

Token Efficiency の本質は、高いモデルを安いモデルで置き換えることではない。AI workflow を設計し直すことだ。

大モデルが重要判断をし、小モデルが大量実行し、harness が調度と検証を行い、人間が目標と受け入れを決める。この四層が揃って初めて token は生産性に変わる。

将来の差は、最強モデルを呼んだかではなく、同じ token でどれだけ現実の成果を出せるかに現れる。

Small Models on KnightLiブログ