harness 非依存のエージェント：あらゆるフロンティアモデルを自分のマシンで動かす

harness はかつて製品そのものだった

最高のコーディングエージェントを使いたければ、ひとつの束を受け入れる必要があった。特定のモデルは特定のインターフェースに包まれ、特定のツール群を備え、誰か他の人のサーバー上で動いていた。モデル、harness、ホスティングは一つのものとして売られ、どれか一つを切り替えることはすべてを切り替えることを意味した。

10月の動きは、その束がほどけつつあることを示した。トレンド上位に上がった一連のオープンソースプロジェクトは、ひとつの前提を共有している。モデルが知能であり、harness は配管であり、両者は同じパッケージに同居する必要はない。いったんそう受け入れれば、エージェントの使い方に関する多くの思い込みがゆるみ始める。

プロジェクトは実際に何をするのか

最も明快な例は、すでに気に入っているインターフェースをそのまま使い、アクセスできる任意のモデルに向けるものだ。あるプロジェクトはそれ自体がトレンド入りしており、マルチ harness・マルチモデルの構成を提供し、ターミナル、エディタ、ブラウザセッションから動かせて、音声サポートも備える。その売りは、作業を始めるときに特定ベンダーのモデルに縛られないことだ。

別のプロジェクトはその発想をさらに押し進め、共有インフラを完全に取り除く。売りは、インストールごとに独自のローカル設定、独自のワークスペース許可リスト、独自のトークンで動くことだ。中央リレーも、共有アカウントも、あなたのトラフィックを見ている中間の運用者もいない。これは Model Context Protocol 上に築かれたプロバイダー中立の実行レイヤーで、フェイルクローズのセキュリティモデルを採る。ローカルのみの HTTP バインド、すべてのリクエストに対するトークン認証、そしてあなた固有の資格情報なしにはリモートの呼び出し元がワークスペースに到達する手段はない。

第三のアプローチは部品はそのままに、組織の単位を変える。単一のエージェントではなく、小さく持続的なチームを組み立てる。役割が定義され、コンテキストを共有し、作業の一部をそれぞれが担うエージェントを、複数の異なる harness から同時に引き出すのだ。長期プロジェクトでは、仕事には形があり、その形が強制されるため、構造化された普通のエージェントのチームが単独の賢いエージェントを上回る、という賭けだ。

なぜ「スタックを自分で持つ」が突然具体的になったのか

長年、AI における「スタックを自分で持つ」は願望の言葉だった。プロンプトは持ててもモデルは持てず、価値の大半はモデルにあった。オープンモデルとオープンウェイトモデルの近年の成熟が、コーディングエージェントというカテゴリの成熟と同時にこの等式を変え、その組み合わせが、これらのプロジェクトを時期尚早ではなく可能にしている。

有能なモデルがローカルで動くか、プロバイダー中立の API から到達できるなら、harness は販売チャネルであることをやめ、差し替え可能なツールになる。これは主導権を誰が握るかという点で意味のある転換だ。ワークフローを書き直さずにモデル間を移れるチームは、値上げ、廃止、能力のサプライズに、四半期ではなく一午後で対応できる。

これらのツールのセキュリティアーキテクチャは、じっくり読む価値のある部分だ。そこに本当の設計上の主張があるからだ。あなたのマシンで動き、あなたの資格情報を保持するツールは、その境界の分だけしか信頼できない。勢いを得ているのは、ネットワークを敵対的とみなし、既定でアクセスをローカルに留め、何かを露出させるには明示的な設定を要求するプロジェクトだ。これは、コードを自社サーバーに送り、その分離を信頼するよう求めるクラウド優先のエージェントプラットフォームとは異なる姿勢だ。

誰も解決していない緊張

プロバイダー中立の狙いには明らかな弱点があり、率直に言う価値がある。それはモデルベンダーがそれを許容することに依存している。ユーザーが他社のインターフェースを通じてあるベンダーのモデルを動かせるようにするツールは、そのベンダーが是認するかしないかわからない領域で動いている。設定が利用規約に親和的であるよう設計されていると明言するプロジェクトもある。逆に、まさにその緊張からエネルギーを生むものもある。「プロバイダー中立」と「想定されたチャネルの迂回」の線は、ベンダーごとに引き方が異なり、しかも動く。

その脆さは、このカテゴリを切り捨てる理由にはならない。スタックのどのレイヤーに依存しているのかを理解する理由になる。すでに自分が持っているローカルモデルを編成するツールは、非正統的な手段でフロンティアモデルへのアクセスを得ることだけが売りのツールとは、リスクの性質がまったく違う。どちらも有用だ。ただ、耐久性があるのは片方だけで、たいていは刺激的なほうではない。

これが働き方にとって意味すること

今日すでにエージェントを使っている人にとっての実際的な結論は、自分の頭の中でレイヤーを分け始めることだ。ツール側はすでに分けているからだ。モデルはひとつの決定。harness はまた別の決定。ツール、メモリ、権限、実行環境はすべて別々の選択であり、それらを束として扱うことがあなたを縛る。

レイヤーで考えるようになると、コミュニティの取り組みは、競合するプロジェクトの山ではなく、ひとつのスタックとして見えてくる。あるレイヤーはコマンドを安全に実行する。別のレイヤーはコンテキストとメモリを管理する。さらに別のレイヤーはエージェントをチームに組織する。もう一つはワークフローのエクスポートとインポートを扱い、それらが一つの製品に閉じ込められないようにする。一つひとつは小さい。合わせると、ベンダーのものではなく、動かす人のものになるエージェントを描き出す。

その所有の代償は保守だ。借りている束は、動かし続けるのは他人の問題だ。自分で組み立てたスタックは、あなたのものだ。モデルが更新されれば、テストする。プロトコルが変われば、移行する。プロジェクトはゼロから作るよりこれを楽にするが、無料にはしない。理念を取り入れても保守の予算を取らないチームは、疲れ果てて束へ戻っていくことが多い。自由は本物だ。請求書も本物だ。

方向

最もありそうな未来は、これらのプロジェクトのどれかが勝ち、ベンダーが負けることではない。レイヤーが吸収されることだ。ベンダーはコミュニティが作った機能のファーストパーティ版を出し続ける。それがプラットフォームというものだからだ。その間、コミュニティのプロジェクトが提供するのは交渉材料だ。束が任意であることの証明と、ベンダーが条件を変えたりエンドポイントを廃止したりする日のための、いくつかの脱出口である。

それは控えめな種類の勝利であり、正直な勝利だ。harness 非依存のエージェントは革命ではない。保険であり、あなたが借りている知能と、それを動かすマシンは同じ決定であるべきではない、という主張だ。動画モデル一家が固定された日に丸ごと廃止されるのを一か月見つめたばかりの分野にとって、保険は小さなものではない。