Token Efficiency on KnightLiブログ

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 でどれだけ現実の成果を出せるかに現れる。

MCPを捨てますか？ CLI がエージェントのデフォルトのツール層になりつつある理由

Fri, 10 Apr 2026 21:55:12 +0800

過去 1 年間、エージェントツールチェーンに関する議論は、次の 1 つの問題にますます集中してきました。

MCP (モデルコンテキストプロトコル) はツールの呼び出しを簡単にしますか? それとも、もともと単純だったものを複雑にしますか?

CLI は、ほとんどの日常的な開発タスクにとって、より実用的なデフォルトになりつつあります。

コストの違いは「経験の問題」ではなく、桁違いの問題です

MCP に対する実際の最大のプレッシャーはトークンのオーバーヘッドです。

一般的なシナリオでは、MCP は実際にタスクを実行する前に、多数のツールスキーマをロードする必要があります。 GitHub MCP サーバーを例に挙げると、初期化で数万のトークンが消費される可能性があります。長いタスクの場合、これはコンテキストバジェットを直接圧迫します。

コミュニティのベンチマークは、同じ結論を繰り返し示しています。

1 回の MCP 呼び出しのコストは、通常、CLI の数倍から数十倍になります。
失敗した再試行のコストも高くなります (接続の再構築とコンテキストの再ロード)。

これは「遅い」というギャップではなく、むしろ API 料金、レイテンシー、安定性の問題にまで拡大します。

モデルが自然に「CLI に精通している」理由

見落とされがちな事実は、トレーニングの分布です。

LLM は、トレーニング中にコマンド、出力、エラーレポート、スクリプト、マニュアルページなどの大量の端末テキストを確認しました。言い換えれば、CLI 対話モードは本質的にモデルの「母国語入力」に近いものになります。

それどころか、MCP の JSON-RPC とツールスキーマは、ここ 2 年間で大規模に登場したばかりの新しいパラダイムです。モデルは確かに学習できますが、親しみやすさと圧縮効率は通常、CLI などの歴史的コーパスほど良くありません。

これは、その理由を何度も説明するものでもあります。

目標は同じですが、CLI 命令は短くなります
出力は推論を直接続行するのにより適しています。
エラー回復パスの安定性が向上

安全と隔離：MCPにはまだ補講の余地があります

MCP がセキュリティを実現できないわけではありませんが、エコシステムはまだ初期段階にあります。

現在の一般的な懸念事項は次のとおりです。

ツール中毒
サービス動作のドリフト (ラグプル)
同名のツール「シャドウイング」

もちろん、CLI にもセキュリティの問題 (インジェクション、不正アクセス、パスのリスク) がありますが、そのプロセスモデル、権限の境界、監査リンクは数十年にわたるエンジニアリングの実践によって検証されています。本番環境では、この「予測可能性」が重要です。

これはMCPが無価値であるという意味ではありません

私はMCPを放棄すべきではないと思います。

より合理的な位置付けは次のとおりです。

CLI は実行層 (ローカル、低遅延、高頻度の呼び出し) を担当します。
MCP は接続層 (リモートサービスディスカバリ、統合認証、監査、マルチテナント) を担当します。

一般に、ハイブリッドアーキテクチャ: CLI + MCP Gateway とも呼ばれます。

多数のリモートシステムに接続し、統合された権限管理とコンプライアンス監査を実行する必要がある場合、MCP には依然として明白な価値があります。しかし、「エージェントが開発タスクを迅速に完了できるようにする」という点では、多くの場合、CLI ファーストの方が現在のモデルの機能の境界に沿っています。

今日のエンジニアリングの現実では、CLI はエージェントの母国語に似ています。 MCP は、唯一の実行プロトコルではなく、接続プロトコルとして適しています。