エージェントの実力は、モデルの重さではなく、モデルを取り囲む構造で決まる。私たちは今週、それを数字で確かめた。まったく同じモデルに記事を書かせたのに、構造を変える前は公開した50本のうち40本で細部の歪みが出ていて、変えた後は最初の公開から誤りが弾かれるようになった。モデルは一文字も変わっていない。変わったのはハーネスだ。
この記事は、その過程をそのまま書き起こした記録だ。ハーネスエンジニアリング(harness engineering)とループエンジニアリング(loop engineering)とは何か、なぜ今この分野の論文が相次いで出てくるのか、そして小さなチームが実務でどう使いこなせるのかを、自分たちの事例と論文3本で解きほぐした。
ハーネスとは、モデルの外側にあるすべてだ。Google Cloud AI Researchが今年出したRRSI論文は、ハーネスをこう定義している。「LLMエージェントの能力はハーネスによって大きく増幅される — すなわち、固定されたバックボーンモデルを取り囲むプロンプト、制御フロー、ツール、メモリ、コンテキスト管理」(arXiv:2609.24972)。同じモデルであっても、何を見せ、どんな順序で仕事をさせ、結果をどう検査し、失敗したらどこへ回すかによって、成果物はまるで変わってくるという話だ。
自動車にたとえるなら、モデルはエンジンで、ハーネスはそれ以外のすべてだ。トランスミッション、ブレーキ、計器盤、シートベルト。エンジンの出力が同じでも、トランスミッションが粗末なら車は遅いし、ブレーキがなければ事故になる。ここ数年はみなエンジンの馬力競争をしてきたが、今年出てきた論文を見ると、重心が目に見えてハーネス側へ移りつつある。
3本だけ取り上げよう。
| 論文 | 主張の核 | 私たちが注目した点 |
|---|---|---|
| NeoHorse-1 (arXiv:2609.08183) | 運用中のルーティングハーネスが残す実行記録そのものが、次の学習の材料になる | ハーネスは実行装置であると同時に観測装置でもある |
| SoL-Pi (arXiv:2609.20519) | ハーネス改善を自動リサーチループとして回し、スコア低下を数%以内に抑えつつトークン使用量を44.7〜49.0%削減した | ハーネス改善そのものをループにできる |
| RRSI (arXiv:2609.24972) | ハーネスの自己改善は過学習する。正則化の原理が要る | ループにはブレーキが要る |
NeoHorse-1チームの観察がとりわけ面白い。デプロイされたハーネスは、毎ターンどんな能力が要求されたか、どのモデル等級が選ばれたか、その後にどんな相互作用が起きたかを記録として残す。この記録こそが「モデルが今、何をできて何をできないのか」の証拠であり、その証拠を次のラウンドの学習へ戻していくことが再帰的自己改善(RSI)の出発点になる、というのだ。ハーネスをうまく作ると、実行が良くなるだけでなく、システムが自分自身を観察する目まで手に入る。
SoL-Piはもう一歩踏み込む。NVIDIA、NTU、MITの研究陣は、ハーネス改善という作業そのものをAIに任せた。基本ハーネスで課題を回し、リサーチAIが実行記録を覗き込んで改善候補を出し、能力ゲートと効率ゲートで候補をふるいにかける。このループを生き延びたメカニズム4つ(アクション融合、オンラインコンテキスト圧縮、観測パッキング、証拠を残した要約)を組み合わせたハーネスがSoL-Piで、51課題のベンチマークで既存ハーネスのスコアの94%前後を維持しながら、記録されたトークントラフィックを半分近く(44.7〜49.0%)削った。わずかなスコアを差し出してコストを大きく節約した取引であり、モデルにはまったく手を付けていない。
ところがRRSIが、ここに冷や水を浴びせる。ハーネスを繰り返し修正して良くなっているように見えるシステムが、実は訓練課題を丸暗記してしまっている場合が多い、というのだ。学習分布の中ではスコアが大きく上がるのに、分布の外のベンチマークへ持っていくと利得が縮んだり消えたりする。そこでこの論文は、ハーネスの進化に正則化をかける。修正は一度に少しずつしか許さず、根拠のない修正は棄却し、複雑さが増す修正にはペナルティを与える。人間でいえば「試験問題の解き方だけを暗記せず、原理を理解したかを別の問題で確かめろ」という話だ。
理論はこのくらいにして、私たちの話をしよう。
このブログは、毎日最新の論文を選んで解説記事を自動公開している。論文の選定から執筆、公開まで人手を介さずに回りはじめて1か月ほど経ったとき、公開済みの50本すべてを、別ベンダーのモデル2つで遡及的にファクトチェックしてみた。執筆したモデルが自分の記事を検査すると、自分の目の梁が見えない。だから検査官は必ず別会社のモデルに立てた。
結果は痛かった。50本のうち40本で指摘が出た。致命的な捏造ではなかったが、細部がずれていた。ベンチマークの数を11個と書いたのに、論文本文の表を数えると10個だった記事。論文が計算・記憶・帯域の3つをボトルネックに挙げているのに「本当のコストはメモリだ」と断定してしまった記事。異なる実験から出た3つのスコアを、一つの実験の成果のように束ねてしまった記事。
原因を掘ってみると、ハーネスの問題だった。執筆プロンプトが、論文のアブストラクトだけを渡していたのだ。アブストラクトは論文の予告編だ。予告編だけを見て映画のレビューを書けば、大筋は合っても場面描写から間違いはじめる。モデルが愚かだったのではなく、私たちが材料を足りない形で渡していたのだ。
そこでハーネスを3か所直した。
第一に、執筆段階に論文HTML全文の抜粋を注入した。予告編ではなく本編を読んで書かせたわけだ。
第二に、公開直前に二重の独立検証ゲートを立てた。執筆モデルとは別の2ベンダーのモデルが、それぞれ原文と突き合わせて判定し、両方を通過してはじめて公開される。ひとつでも引っかかれば、指摘事項を反映して修正し、もう一度検証する。
第三に、修正しても通らなければ公開を保留し、管理チャネルへ報告する。中途半端な記事を出すくらいなら、その回を飛ばすほうを選んだ。
直したハーネスで回した最初の公開で、さっそく効果が出た。新しい論文解説の初稿で、検証ゲートが「実測範囲の誇張」を捕まえた。初稿は両方の実験トラックとも5段階まで測定されたと書いていたが、原文と突き合わせるとトラックごとに測定範囲が違った。ゲートはこの指摘を修正段階へ回し、直された原稿が再検証を通ってはじめて公開された。人間は一度も介入していない。
既存の40本も同じループに載せた。指摘を反映して修正し、再検証を通った記事だけを載せ直した。2回直しても通らなかった記事は下げた。読者から見れば変わったところはないように見えるだろうが、いまこのブログの記事はすべて、2人の外部検査官を通った原稿だ。
この話では、ハーネスと同じくらい大事なのがループだ。検証ゲートは、一度判定して終わる扉ではなく、失敗を戻してもう一度試す循環構造として組んではじめて機能する。
私たちがループを組むとき、必ず入れる要素が4つある。
終了条件。 ループは必ず終わらなければならない。私たちの修正ループは2周までしか回らない。2回直しても検証を通らなければ、その記事は保留だ。終了条件のないループは、改善ではなく徘徊だ。RRSIがハーネスの進化に修正回数の制限と採択基準をかけるのも、同じ原理だ。
フォールバック経路。 主力の手段が塞がれたときに行く先を、あらかじめ決めておく。私たちの執筆段階は、主力モデルが上限に当たると予備モデルへ自動で切り替わる。これを作っておかないとどうなるかも経験した。以前のパイプラインは、モデルが上限の案内文を吐き出すと、それを本文だと思い込んで公開しようとし、3日連続で手ぶらに終わったことがある。フォールバックは贅沢ではなく、基本の配管だ。
再開可能性。 長いバッチ作業は、必ず途中から再開できなければならない。50本の遡及監査は1本あたり数分かかる作業なので、処理した記事の番号をファイルに残し、再実行すると残りだけを続けて回すようにした。40本目でネットワークが切れたら最初からやり直す構造なら、そのループは実戦向きではない。
失敗の記録と原状復帰。 失敗した回は、痕跡を消すのではなく記録を残して状態を戻す。私たちの公開ワーカーは論文を先取りしてから始めるが、公開に失敗すると先取りを解除して、次の回が同じ論文をもう一度試せるようにする。失敗がシステムをロックしてはいけない。
弱いループと強いループの違いを一行ずつ対比すると、こうなる。
文章は長くなったが、新しく入った単語のひとつひとつが、実際の障害状況ひとつずつを防いでいる。
大げさなフレームワークが要るわけではない。私たちのゲートも、核は「別のモデルに判定形式を決めて尋ね、答えをパースして分岐する」数十行のコードだ。始めるときの順序は、こう組めばいい。
ひとつ警告を。RRSIの教訓のとおり、ゲートの通過率が上がったからといって、無条件に喜んではいけない。検査官によく見せるコツだけを学習しただけかもしれない。私たちが検査官を2ベンダーに分け、原文との突き合わせをさせているのも、ひとりの検査官の好みに過学習するのを防ぐためだ。
ONTLEはAIプロジェクトマネージャーを派遣するサービスなので、上の原理がそのまま製品になる。顧客の依頼を受け付け、処理し、成果物を作り、報告する全過程が、ハーネスとループで組まれている。依頼が詰まれば監視ループが停滞を察知し、成果物は検証を経て出ていき、失敗した作業は記録とともに再試行の経路へ戻る。このブログの公開パイプラインは、その構造の縮図であり、新しいメカニズムを先に試してみる試験台でもある。
モデルはこれからも良くなっていく。しかし、どんなモデルが来ようと、そのモデルで何を安定して作り出せるかは、結局のところハーネスとループを設計する側の仕事として残る。私たちが今回、40本を直しながら学んだのはそれだ。
プロンプトはハーネスの部品のひとつだ。ハーネスエンジニアリングは、プロンプトに加えて制御フロー、ツール連携、メモリ、コンテキスト管理、検証ゲート、失敗経路まで、システム全体を設計する。私たちの事例でも、問題解決の核はプロンプトの言い回しではなく、入力材料(論文の全文)と検証構造だった。
同じモデル系列で検証すると、同じ盲点を共有する危険がある。また、ひとりの検査官だけに合わせていくと、その検査官の傾向に過学習するというのがRRSIの指摘する危険だ。私たちは、異なる2ベンダーのモデルの判定を両方通過してはじめて公開する、というルールを使っている。
作れる。核となるゲートは「判定形式を固定して別のモデルに尋ね、応答をパースして分岐する」程度のコードだ。最初から自動修正ループまで行く必要もない。公開前の判定をひとつ立てるだけでも、私たちの基準で80%あった細部の歪みが弾かれはじめる。
SoL-Piはハーネス改善を自動リサーチループとして回し、スコアを94%前後に保つ代わりにトークントラフィックを44.7〜49.0%削るメカニズムを見つけ出し、NeoHorse-1はハーネスの実行記録を次の学習の材料に使う経路を示した。ただしRRSIが示すとおり、無制限の自己改善は過学習するので、実務では採択基準や修正制限といったブレーキを一緒に設計しなければならない。