毎月新しいモデルが登場する。昨日も一つ発表された。ベンチマークは向上し、より長く複雑なタスクをより良くこなすという。喜ばしいことだ。しかし、そのモデルで数日作業してみると、頭に残る疑問は意外にも別のものだ。「このモデルがどれほど賢いのか」ではなく、「これをどこまで信頼し、任せられるのか。」
この二つの質問は全く異なる。そして、二つ目の答えはモデルの中にはない。モデルを包み込む構造 — 一般にハーネス(harness) と呼ばれるオーケストレーションの骨格 — の中にある。同じモデルであっても、どのようなハーネスで包むかによって、単独で暴走するおもちゃにもなれば、信頼して任せられる働き手にもなる。デモでそれらしく見えることと、実際の運用で事故なく機能することは全く別の話だ。
大手テクノロジー企業の競争が、モデルのパラメータからハーネスの設計へと移行した理由はここにある。モデルは部品であり、ハーネスは骨格だ。部品は毎月交換されるが、骨格は一度しっかり構築すれば長く使える。だから私たちは、新しいモデルを追いかける代わりに、骨格が「どこまで」可能なのかを直接追求してみた。その境界線を共有する。
第一の境界 — ウェブとローカルは非対称である
最初に直面するのは空間だ。最新機能はほぼ常にクラウドで最初に利用可能になる。新しいワークフロー、新しい自動化、新しい連携はすべてそちらから始まる。しかし、実際に制御したいもの — 自分のファイル、自分のサーバー、自分の環境 — はローカルにある。
ここで重要な事実が一つ。この壁は一方向にのみ堅固だ。 クラウドエージェントは、セキュリティ上の理由から、私のローカル環境に勝手にアクセスできない。逆に、ローカルエージェントはクラウドAPIをいくらでも呼び出せる。この非対称性が設計の答えを与えてくれる。中心軸をクラウドに置こうとすると壁にぶつかるが、中心軸をローカルに置き、クラウドの新技術を「呼び出して使う部品」へと格下げすれば、壁はなくなる。「クラウドが私の作業を指揮する」のではなく、「クラウドが信号を送り、ローカルが実行する」という構造だ。華やかなリアルタイムコラボレーションデモは諦めなければならないかもしれない。しかし、その代償として制御権を得られる。ほとんどの実務において、この交換は得策だ。
第二の境界 — すべてをモデルに任せるな
ハーネスを初めて構築する際、欲が出るものだ。賢いモデルがあるのだから、すべてのステップを任せたくなる。しかし、これは高価で、遅く、何よりも不安定だ。
原理は単純だ。パターンが確立された作業はコードで固定し、判断が必要な作業のみをモデルに任せる。 私たちはこれを冗談めかして「自動販売機」と呼んでいる。入力を与えれば決められた出力が出る、判断を伴わない決定論的な配線だ。フォーマット変換、スキーマ検証、チャネル分岐のような作業は毎回同じだ。モデルにさせるとトークンを消費し、時にはとんでもないことをするが、コードで組み込んでおけば無料で、永続的に、同じように機能する。
興味深いのは、ツール呼び出しでさえそうだということだ。「このステップではこのツール」と決まっているなら、モデルに選ばせるよりもコードが直接呼び出す方がはるかに堅牢だ。モデルはツールが存在するかどうかさえ知らなくてもよい。ただテキストを吐き出すだけで、コードがその出力を受け取り、決められたツールを実行する。不確実性はゼロになる。
判断をなくせと言っているのではない。判断を上位に持ち上げろということだ。自動販売機は神経ではなく脊髄反射だ。何をすべきかは上位で決定し、自動販売機は実行するだけだ。そして、自動販売機は小さいほど堅牢だ。巨大な自動販売機一つは壊れやすいが、小さな自動販売機を複数レゴのように連結する構造は、めったに崩れない。高価な判断を最小限に抑え、安価な実行を最大化するほど、ハーネスはより速く、より安く、より安定したものになる。
第三の境界 — 小規模ローカルモデルの真の役割
コストの話が出たので、小規模ローカルモデルを実際に動かしてみた経験も共有する。消費者向けGPU一台にオープンソースの軽量モデルをいくつか搭載し、同じタスクを試してみた。
結論は明確だった。長文の創作はまだ無理だ。 一つの記事を書かせると、言語が混ざり、主題から逸れ、同じ文章を無限に繰り返し、破綻した。小規模モデルに「主役」を任せると失望する。
しかし、同じモデルでも別の作業では役立った。コードから欠陥を見つける検証タスクでは大規模モデルに近いスコアを出し、短く定型化された問題では1秒台で正解を導き出した。つまり、小規模モデルの役割は生成ではなく、検証と分類、短い定型作業だ。主役ではなく脇役 — 検証者、分類器、自動販売機の部品として配置したときに輝く。重いハーネスを丸ごと小さなローカル環境に移そうとする試みは、システムプロンプトとツール定義だけでコンテキストが一杯になり失敗した。教訓は明らかだ。「丸ごとローカル化」ではなく、「軽量な自動販売機 + ローカルモデルノード」が正解だ。重いものはクラウドに、軽いものはローカルに。再び第一の境界に戻る。
第四の境界 — 最も強力なモデルも検証されるべきである
最後の境界が最も重要だ。私たちは最も強力な最新モデルで大規模な分析タスクを実行した。結果は印象的だった。しかし、その結果をそのまま鵜呑みにはしなかった。意図的に異なる環境の異なるエージェントたちに相互検証させたのだ。
理由は一つ。単一のエージェントは、自身の幻覚を自身でフィルタリングできない。 自分の目で自分の盲点が見えないのと同じだ。そして、モデルが新しく強力であるほど、もっともらしく間違えるリスクはかえって大きくなる。強さと信頼性は異なる軸だ。ベンチマークが高いからといって信頼できるわけではない。
実際に、一次分析には誤検知があった。ある環境で「ない」と判断されたものが、別の環境では問題なく存在していたのだ。一部しか見ていなかったエージェントが、全体的な文脈を見落としていたのである。相互検証がこれを即座に排除した。もしその一次報告をそのまま信頼していたら、問題のないものを問題と誤解したまま、事態を大きくしていたことだろう。
そのため、優れたハーネスには必ず検証ループがある。生成するエージェントと検証するエージェントを分離し、判断が不可逆的であるほど — 金銭が絡む場合や取り返しのつかない作業であるほど — 検証層をより厚く重ねる。ただし注意点が一つ。似たようなモデル同士は同じ盲点を共有するため、相互検証は異なる系統のモデルが担当して初めて効果を発揮する。全く同じ二つが互いに確認し合っても、両方とも同じ場所で間違えるからだ。
それで、どこまで可能なのか
再び最初の質問に戻る。Claudeハーネスはどこまで可能なのか。
答えは逆説的だ。ハーネスの「どこまで」は、モデルの知能ではなく構造が決定する。 より賢いモデルを待つ必要はない。現在のモデルでも、構造を適切に構築すれば驚くほど遠くまで到達できる。逆に構造がなければ、どんなに強力なモデルを投入しても、単独で暴走し事故を起こすだろう。
その構造の核心原理を一句でまとめるとこうなる。
エージェントで探索し、パターンが確立されたらコードで定着させる。
エージェントは永遠の働き手ではなく、偵察兵だ。その価値は、作業を際限なく繰り返すことにあるのではなく、作業のパターンを明らかにすることにある。パターンが見つかればその部分はコードで固定し、エージェントは解放されて次の未知の領域へと向かう。こうすることで、高価な知能は常に最前線に留まり、後方は安価で安定したコードが支える。
モデルは部品であり、ハーネスは骨格だ。部品は毎月交換される。昨日も新しいものが出たし、来月もまた出るだろう。そのたびに揺らがないためには、モデルを追いかけるのではなく、骨格を構築すべきだ。骨格が堅固であれば、新しい部品が来るたびに、ただより良くなるだけだ。ハーネスはモデルが賢い分だけではなく、構造を構築した分だけ遠くまで到達する。