モデルではなくハーネス：同じLLMが適切な足場なしでは4倍のトークンを浪費する理由
モデルではなくハーネス：同じLLMが適切な足場なしでは4倍のトークンを浪費する理由
トークンコストの議論全体を再定義するチャートが出回っている。あるエンジニアが同じモデルで180個の同一なコード修正タスクを実行し、実行ごとに変えたのはたった一つ——ハーネス、つまりモデルを包む足場だけだった。素のままでは、モデルはそのうち6.7%を解いた。適切なハーネスを与えると68%——しかもそこに至るまでに4分の1のトークンしか使わなかった。
同じ重み。同じタスク。配線だけで成功率が10倍、コストが4倍も振れたのだ。
アナリストのAakash Guptaはビジネス上の意味をずばりこう表現した：「モデルは誰もが持っているコモディティだ。ハーネスはあなたの城を守る堀——競争優位性だ。」 この記事では、そのアイデアをこのブログが唯一こだわるレンズ、すなわちトークンを通して読み解く。なぜなら、ハーネスは精度が宿る場所であるだけでなく——請求書が宿る場所でもあるからだ。
これは LLMでトークンを節約する方法 の姉妹記事である。あのガイドが戦術のカタログだとすれば、こちらはそのすべての根底にある原理——そしてカタログ全体が結局のところハーネスエンジニアリングである理由を扱う。
1. 「ハーネス」が実際に意味するもの
モデルはエンジンだ：素の次トークン予測。ハーネスはそのエンジンを、仕事をやり遂げるエージェントに変えるための周辺すべてである：
- タスクがどう枠組みされているか（システムプロンプト、ツールのドキュメント、例）；
- どのツールを持ち、その結果がどう返ってくるか；
- リポジトリ／ファイル／履歴のどれだけを、どんな形で見るか；
- 失敗したときに何が起きるか——盲目的にリトライするのか、それとも軌道修正されるのか；
- ステップ間やセッション間で何を覚えているか。
Claude Code はハーネスだ。Cursorもそうだし、Codexもそうだし、手作りのエージェントループもそうだ。同一のモデルを駆動する2つのハーネスは、まったく異なる結果——そしてまったく異なるトークン代——を生む。なぜなら、そのモデルにまったく異なるコンテキストを与え、間違いからまったく異なる回復の仕方をするからだ。
2. なぜハーネスこそがトークンを燃やす場所なのか
ここがコストにとって重要な部分だ。エージェント的なタスクにおいて、トークン代は問題を解く唯一のきれいな軌跡によって支配されるわけではない。それは、道中でうまくいかなかったすべてによって支配される：
- リトライ。 曖昧なエラー、不正なツール呼び出し、間違った前提——それぞれの行き止まりは、入力（蓄積されたコンテキスト全体）と出力の丸ごと1ラウンドを、何も生み出さないまま満額支払うことになる。
- 再読み込み。 適切な30行をモデルに渡せないハーネスは、モデルに800行のファイル全体を読ませる——あるいはgrepし、失敗し、さらに3つのファイルを読ませる。
- もがき。 軌道修正がなければ、行き詰まったモデルは同じ失敗するアクションを少しだけ言葉を変えて繰り返し、その繰り返しごとにコンテキスト全体を再送する。
- コンテキストの腐敗（context rot）。 失敗した試みがウィンドウに積み上がるにつれて品質が落ち（トークンガイド の§3を参照）、それがさらなる失敗を招き、さらなるトークンを燃やす。悪循環だ。
これこそ、同じモデルが素のままだとハーネス付きより4倍もコストがかかりうる理由だ。68%成功のハーネスは単に賢いだけではない——もがきの分を支払わないのだ。最も安いトークンは、リトライで決して使わずに済むトークンである。ハーネスの品質とトークンコストは、二度測られた同じ軸だ。
3. 研究：モデルではなくインターフェースを適応させる
これは単なるインフルエンサーの枠組みではない——今や数字を伴った研究の方向性になっている。
Life-Harness
Life-Harness（Xu, Wen, Li — arXiv 2605.22166）は、このテーゼをそのタイトルに文字通り込めている：「モデルではなくインターフェースを適応させる」。 その主張は、ルールに支配された環境において、エージェントが失敗するのはモデルが愚かだからではなく、モデルと環境のインターフェースの不一致のためだ、というものだ。だから重みをファインチューニングする代わりに、実行時にハーネスを進化させる：観測された失敗を再利用可能な介入に変え、それを新しいタスクのために固定しておく。これは**訓練不要（training-free）**である——勾配更新も、新しい重みもない。
これは4つのランタイム層から構築されており、それぞれをトークン節約装置として見る価値がある：
| 層 | 何をするか | トークンの観点 |
|---|---|---|
| 環境コントラクト | タスクの本当の制約を前もって明示する | モデルがルールを破って初めて気づくリトライループを潰す |
| 手続き的スキル | 以前うまくいった蒸留された回復パターンを再利用する | エージェントが一度見つけた解を再導出するのを省く |
| アクション実現 | モデルの意図を有効な実行可能アクションに翻訳する | 不正な呼び出しの往復を取り除く |
| 軌跡制御 | 繰り返される失敗パターンを検出しブロックする | コンテキストをN回再送するもがきループを止める |
これら4つのすべてが、無駄なトークンのカテゴリを狙っている。結果は：7つの決定論的環境と18のモデルバックボーンにわたり、Life-Harnessは126設定中116を改善し、平均88.5%の相対的向上を達成した——そして1つのモデルで進化させたハーネスが他の17に転移した。MITライセンスのコードはGitHubにある。（論文が報告するのは成功率であり、トークンの見出しではない。「4分の1のトークン」の数字は上述の実務家の実験によるものだ——だがそのメカニズムは、良いハーネスがやることそのものだ：失敗する軌跡が少なく、トークンが少ない。）
Meta-Harness
Life-Harnessが失敗からハーネスを進化させるのに対し、Meta-Harness（Lee, Nair, Zhang, Lee, Khattab, Finn）はエンドツーエンドに進む：モデルには一切触れずに、ハーネスそのもの——タスク記述、プロンプト、評価基準——を学習可能なオブジェクトとして自動的に最適化する。その見出しは「ハーネス問題」だ：同一のタスクでも、枠組みが異なれば実質的に異なる結果を生む、そして体系的なハーネス最適化はモデルのアップグレードから得られる利得に匹敵、あるいはそれを上回りうる。意図検出、感情認識、コードタスクにわたってT-Bench 2でテストされた。
2つの論文、同じ四半期、異なる角度からの同じ結論：インターフェースは第一級のレバーであり、固定されたモデルにとってはそれが残された唯一のレバーだ。
4. これがあなたのClaude Codeの請求書にとって意味すること
Claude Codeユーザーにとってのオチはこうだ：トークン節約ガイド にあるすべてがハーネスエンジニアリングである。 「ハーネス」というラベルのついたツマミはないが、あなたは次のことをするたびにハーネスを構築している：
- 小さなコンテキストでサブエージェントに委譲する（§2）——失敗が子コンテキストに留まり、親を腐らせないように；
- MCPをスキルに置き換える（§5）——別名で言う手続き的スキルの層：再導出する代わりにオンデマンドで読み込まれる再利用可能なノウハウ；
- フックでツール出力をフィルタリングし、rtkでコマンドを圧縮する（§11, §13）——アクション実現：500行のログではなく、有効でコンパクトな結果；
- リポジトリ全体を読む代わりにグラフをクエリする——graphify、そして今や CodeGraph と Serena（ガイドの更新された§7/§13を参照）——「すべてを再読み込みする」税への最大の削減；
/rewind、/compact、/clearでセッションを管理する（§4）——軌跡制御：行き止まりの経路に請求を繰り返させない。
このリストをLife-Harnessの4つの層に照らして読むと、対応関係はほぼ一対一だ。学術的な枠組みは、コスト意識の高いエージェントユーザーがすでに本能でやっていたことに名前を与えたにすぎない。このスタックはトリックの寄せ集めではない——それはハーネスであり、各ピースが無駄なトークンのカテゴリを一つずつ取り除く。
5. より良いハーネスを手に入れる2つの方法：作るか、借りるか
作る。 これが claude-code-token-savers のセットアップがやっていることだ——rtk、graphify、caveman、そして今やpxpipe/headroomがClaude Codeに配線され、フラッグシップモデルを包むハーネスがもがきの分を支払わなくなる。Anthropicのモデルはそのまま使い、配線をアップグレードするのだ。
借りる。 ハーネスそのものを製品として売る製品もある。例えば commandcode.ai はClaude Codeのプロキシではない——それは、独自のハーネスの背後で安価なフルウェイトで量子化なしのオープンモデル（DeepSeek V4 Pro、MiniMax M3、MiMo V2.5 Pro）を走らせる独立したエージェント（月$1、$10の無料クレジット）だ。そして*「taste-1」*という学習システムが、あなたの承認／拒否／編集を監視し、プロジェクトレベルのスキルを自動生成する——手続き的スキルの層を製品化したものだ。その経済性は§6の手（安価なモデル）に加えて、使えば使うほど改善するハーネスである。カテゴリとして知っておく価値がある：ハーネスが十分に良ければ、それに乗ったコモディティモデルが素のフラッグシップモデルに勝つ——まさに6.7%対68%のチャートそのものを、サブスクリプションとして売っているのだ。（これはあなたのClaude Codeスタックへのアドオンではなく、代替エージェントである。）
どちらのルートも同じ賭けだ：モデルではなくハーネスに投資せよ。
まとめ
モデルはエンジンであり、エンジンはコモディティになった——DeepSeek、MiniMax、Qwen、Claude、どれも $1 のサブスクリプションや安価なOpenRouterのエイリアスで手が届く。同じタスクで$6のセッションと$42のセッションを分けるのはエンジンではない。それはハーネスだ：配線がどれだけうまくモデルをレールに乗せ続け、必要なコンテキストを正確に手渡し、同じ間違いに二度支払うことを拒むか、である。
Aakash Guptaはハーネスを堀と呼んだ。トークン代を気にする者にとっては、もっとシンプルだ：ハーネスこそが、あなたのトークンが使われるか節約されるかの場所である。 良いものを作れ——あるいは借りろ——そうすれば同じモデルが、4分の1のコストで10倍の仕事をこなす。
関連記事：LLMでトークンを節約する方法——実践的なClaude Codeガイド、この原理がその下敷きとなっている戦術ごとのカタログ。