LangChain：モデルを変えずharnessだけ調整し、Nemotron 3 UltraのスコアをOpus 4.8に迫らせる。コストは約1/10、企業がクローズドソースAPIに大金を払う必要がないことを証明
- LangChainはNemotron 3 Ultraの重みを固定したまま、harness（システムプロンプト、ツール説明、ミドルウェア）だけを変更。モデルも温度などの生成パラメータも変えない。
- 手法は評価駆動のクローズドループ：評価 → 失敗トレースを読む → 行動をクラスタリング → 外殻を一箇所変更 → 再評価。まず小サンプルで絞り込み、通ったらフルセットへ。
- プロンプトは短い単一目標の指示ブロックを使う。ミドルウェアは強制実行と、つまずくポイントでのシグナル注入を担う。
- 核心メカニズム：同じルールでもツール説明に書くと効かず、ツールの返り値に埋め込むと効く。会話途中での注入は、システムプロンプトに常駐させるより安定する。
- 典型的には~0.80→0.84、最高0.86対Opus 4.8最高0.87。フルセットで約$4.48対$43.48、中央値のレイテンシはどちらも約10秒/問。
彼らが行ったこと
LangChainがNemotron 3 Ultra向けのharnessチューニング手引書を公開した。モデルには手を触れず、その外側の足場だけを変えて、オープンソースモデルがagentタスクでどこまで引き上げられるかを見た。
一言で言えば：同じオープンソースモデルでも、体に合った外殻に取り替えれば、最高スコアはClaude Opus 4.8に迫り、フルセット評価のコストはおよそ一桁低くなる。
なぜ見る価値があるか：同じ重みでも足場が違えばスコアは大きく変わり得る。彼らは以前、gpt-5.2-codexのTerminal-Bench 2.0のスコアをモデルを変えずに52.8から66.5まで引き上げた。今回は同じ発想をオープンソースモデルに適用し、Opusに近いコスト対比を示した。
生成パラメータはベンダー推奨のデフォルトのまま。本稿での向上は、temperatureを弄って「運任せ」で得たものではない。
外殻が合わないとき、馬力はどこへ消えるのか
オープンソースモデルはすでに実務のagentタスクをこなせる域にあり、価格は最先端APIのほんの一部だ。だがどれほど有能なモデルでも、自分向けに作られていないharnessに放り込まれれば、実力を出せなくなる。
モデルはエンジンで、harnessはシャシーとギアのようなもの。どれほど良いエンジンでも、ギアと伝動が噛み合わなければ、馬力は空転とスリップに無駄遣いされる。harnessを調整するのは、ギアと伝動を変えることであり、エンジンを載せ替えることではない。
彼らがNemotron 3 Ultraを選んだのは、NVIDIAが後段学習の段階で、単発の対話だけでなく複数のagent harnessを横断して安定した挙動を出すよう鍛えていたからだ。profileなしのベースラインは約0.80——床がすでに低くないからこそ、外殻を積み増す余地がある。
チューニングはクローズドループで、勘に頼らない
評価シグナルがなければ、それはただの勘だ。Agentの入力空間は広く、許容される出力も多い。一箇所直すとAが直ってBが壊れることもある。だから作業はクローズドループで進め、LangSmithのトレースを真実の源とする。
クラスタリングするのは失敗パターン（例えば「ファイルを半分読んだだけで答えてしまう」）であり、特定の設問の言い回しではない。ある一問のフレーズにだけスコアが乗る改修は捨てられる。
候補はまず代表性のある小サンプルを通し、通過してからフルセットへ進む。絞り込みに使うサンプルは異なる行動タイプを網羅する必要があり、そうしないと絞り込みで触れなかったタスクが軒並み後退しかねない。
プロンプト：ページ全体を書き直すな、失敗に対してピンポイントで書け
システムプロンプトは最も安上がりで、同時に最も過大評価されやすい。大幅な書き直しや「もっと良いagentを作る」的な指示はしばしば薄まってしまう。有能なモデルの本当の失敗点は、たいてい言い回しの問題ではないからだ。
タスクは完了したのに具体的な結果を報告しないとき、追加するのはこのブロックだけで、他は足さない：
<final_answer_completeness> After tool calls succeed, the final answer must report the concrete result, not just that the task is done. Include the key entity, action, identifier, title, recipient, service, status, or value that answers the user's request. If the user asked multiple questions, answer each one from its matching tool output. </final_answer_completeness>
同じ一文でも、置く場所が違うと結果はまったく逆になる
これは全文で最も注目に値するメカニズムだ。彼らが求めていたルールはこうだ——ファイル読み取りの返り値がちょうど1ページ分いっぱいだったら、まだ続きがあるとみなして読み続ける。
この一文をread_fileのツール説明に書き込むと、モデルは1ページ目を読んだだけで切り上げてしまう。一字も変えずにツールの返り値のそばへ移すと、モデルは読み続けるようになる。
モデルが実際に処理しているのは「今まさに目の前にあるその一段」だ。ルールがその内容から離れるほど、書かれていないも同然になる。その内容のすぐそばに貼り付けてはじめて、読み取られる。
ミドルウェアは何をしているのか：二種類のフック
「毎回必ず起きる」必要のある行動もあり、プロンプトだけでは足りない。ミドルウェアはモデル呼び出しとツール呼び出しの前後に掛かる：
会話途中での注入：システムプロンプトより安定する
Nemotronは「必要になったタイミングで現れる一言」の方が、システムプロンプトに常駐するルールより素直に従う。そこでミドルウェアはこのリズムで二回注入する：
何を残し、何を捨てるか
試したことの大半は生き残らない。成功だけを報告するチューニングループは、たいてい過学習を起こしている。
チューニング後、数字はどう変わったか
総合点だけでは良くなったか悪くなったかしか分からない。彼らはagentがよくこなす作業ごとに項目別採点をした：ファイル、ツール、検索、マルチターン対話、長文脈の要約。
profileなしのときは圧縮の指針がなく、圧縮すべきときにしなかったり、要約だけで会話に答えて退避させた履歴ファイルを読みに行かなかったりした。明示的な指針を補うとほぼ満点まで伸びた。
ツール失敗の多くは、どう説明するか、どうリトライするか、どう締めくくるかに起因していて、モデルが単に「ツールを使えない」だけではない。
素の状態からすでに強い（後段学習の痕跡）が、外殻の微調整でさらに掘り出せる。
長期にわたってバックエンドの状態を保持するような問題はほとんど動かない。彼らはこのためにprofileを歪めてスコアを稼ぐことはしない。
外殻はどの層まで締めると締まらなくなるのか
harnessの調整には天井がある。境界線を見極めることは、効果を見極めることと同じくらい重要だ。
二本目の線はharnessの内部に引かれる：何を「すべてのagentが共有するコア」に入れるべきか、何が単に「ある一つのモデルのprofile」にすぎないか。
プロジェクトの中で繰り返し問う価値がある一言：この改修は、正直に言って「コア」に少しでも寄せられるか？
When a failure doesn't respond to anything you change around the model, that's the signal it lives in the weights, and the fix is post-training, not another hook. LangChain · Tuning the harness, not the model
オープンソースAIをトップモデルに迫らせる：もっと強いモデルに替える必要はない → 外側の「外殻」を体に合わせて調整するだけ
LangChainは外殻だけを動かしモデルには触れず、オープンソースのNemotron 3 Ultraを最高スコアがClaude Opus 4.8に迫るまでチューニングした。一枚の図解で、どうやったのか、どれだけ安くなったのかを明快に伝える。
↓ 一枚で読み終わる · 動く図が一つあります
AI agent（自分でツールを呼び出し、一歩一歩仕事をこなせるAI。おしゃべりするだけのものとは違う）をもっと有能にしたいとき、多くの人がまず考えるのはもっと強いモデルへの乗り換えだ。この手引書が歩んだのは別の道だ——モデルの外側にはもう一層「外殻」（harness）があり、そこには冒頭の指示、各ツールの説明書、途中の各ステップで走る処理ロジックが含まれる。この外殻こそが、今回手を入れた場所だ。
✘ しかし自分向けに設計されていない外殻に放り込まれると、たちまち調子を崩す：同じ質問を繰り返す、仕事を終えないまま切り上げる、堂々巡りする
なぜか：外殻が与える指示とツール説明がこのモデルの気質と噛み合わず、力はすべて足場との格闘に費やされ、タスクには向かわない
発想はシンプルだ：モデルの重みは一バイトも変えず、外殻の三箇所——冒頭の指示、ツール説明書、途中の処理ロジック——だけを締め直す。一つのクローズドループで一箇所ずつ調整する：評価を一回走らせる（固定の設問で採点）→AIの各ステップの完全な記録（trace）を掘り起こす→どこでいつもつまずくかを見つける→外殻の一箇所だけを変える→再び評価を走らせてスコアが動いたか見る。まず小サンプルで安く絞り込み、通過してからフルセットへ進む。
最も基本的な一手：システムプロンプト（冒頭のルールを定める文言）はページ丸ごと書き直してはいけない。長く書くほどかえって埋もれてしまう。失敗に対しては、単一目標の小さなブロックだけを補う。
丁寧に計画し、あらゆる境界に気を配れ……"
→ 長く曖昧すぎて、薄まる
ツールが成功したら、答えは
具体的な結果を報告すること。「完了した」
とだけ言うな
</final_answer_completeness>
そのままコピーできる完全な原文ブロックは本文にある。だがこの手引書全体で最も直感に反する一点は、何を書くべきかではなく、どこに書くべきかだ。
彼らはAIに一つのルールを守らせたかった：ファイルを読むとき、返ってきた内容がちょうど1ページ分いっぱいなら、まだ続きがあるとみなして読み進める。同じ一文でも、ツールの説明書に書くとAIは1ページ目を読んだだけで切り上げてしまう。一字も変えずにツールの返り値のそばへ移すと、AIは素直にめくり続ける。
同じ理屈で、途中の処理ロジックはAIがまさに動き出そうとする直前に、会話へ「まず計画してから実行」という一言をその場で差し込むこともある。この「タイミングが来てはじめて現れる」注意喚起は、冒頭に固定で書かれた常駐ルールより効く。
同じDeep Agents評価（LangChain自前のagent採点用固定問題集）を走らせると、品質がほぼ並ぶ前提のもとで、両者の請求額は一桁違う。
- × 同じ質問を繰り返す
- × 終わらないまま切り上げる
- × 堂々巡り
外側の「外殻」だけを締め直す。
ルールを定める言葉
使い方
走るロジック
AIは1ページ目で切り上げる
AIはそのままめくり続ける