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 でどれだけ現実の成果を出せるかに現れる。
実務での落とし込み
実際に導入するなら、最初から大きな agent system を作る必要はありません。
まず一つの繰り返し業務を選び、入力、出力、合格条件、失敗時の扱いを明文化します。
次に、計画ノードと実行ノードを分けます。
計画ノードでは高性能モデルを使い、作業分解と判断基準を作ります。
実行ノードでは安価なモデルを使い、決められた範囲の変換、補完、検査を行います。
最後に、人間のレビュー結果を記録し、どのノードで失敗したかを測ります。
この小さな循環が回ると、token efficiency は抽象的なコスト削減ではなく、業務改善の指標になります。
評価を先に決める
モデルを切り替える前に、評価方法を決めておく必要があります。
テストが通ったか、レビュー指摘が減ったか、人間の手戻りが少ないか、作業時間が短くなったかを見るべきです。
単に token 単価が安いだけでは、品質が落ちたときに全体コストは上がります。
だから token efficiency は価格表ではなく、成果物と検証結果を一緒に測る指標です。