分析: OpenAIはハーネスを開源したのではなく、モデルを開源したのではなく、そしてそれが戦略である

この話には、ルーチン的なオープンソースリリースとして読めるバージョンと、OpenAIが市場に対してエージェントの価値が実際にあると考える場所を伝えていると読めるバージョンがある。後者の方がより近い。

8月20日、同社はCodexの背後にある仕組み、すなわちcodex execコマンドライン、app-server実行サービス、Codex SDKを、openai/codexリポジトリでApache-2.0ライセンスの下で公開した。モデル自体は移動しなかった。モデルを取り巻くすべてが移動した。

デモされない部分、ハーネス

ベンダーはモデルをデモする。チームはハーネスをリリースする。

ハーネスとは、テキスト補完を完了された仕事に変えるコードのことだ。それは、今回のターンでモデルが見るコンテキストを決定し、モデルが要求するツール呼び出しを実行し、発生した結果をストリーミングし、長いセッションがウィンドウをオーバーフローするのを防ぎ、人が実行中に中断できるようにし、不可逆的なアクションを承認ゲートの後ろに置く。

エージェントのプロトタイプを本番環境に投入したことがある人なら誰でも、この種のコードのいずれかのバージョンを書いたことがあるだろう。通常は2回、最初の時はひどい出来だっただろう。それが今、OpenAIが標準化し、無償で提供したものだ。

モデルがエンジンなら、ハーネスはシャーシ、ギアボックス、ブレーキだ。誰もエンジンだけを比較して車を買うことはない。そして、過去2年間のエージェント調達は、ほぼその通りだった。

みんなが引用する数字

OpenAIによると、ハーネスの変更だけでも — ステップ間で推論を保持し、コンテキストを圧縮する — 同じモデルでARC-AGI-3のスコアが13.3%から38.3%に向上し、トークン消費量が約6分の1に削減されたという。

これは印象的な数字であり、それが何を言っていて、何を言っていないのかを正確に理解する価値がある。

それが言っていること：足場は第一級の変数である。自分のハーネスを通して2つのモデルをベンチマークするチームは、3つのもの — 2つのモデルと1つの足場 — を測定しており、ほとんどの場合、足場を報告している。公開されたモデルスコアで、公開されたハーネスがないものは、この証拠に基づくと、ほとんど読めない。

それが言っていないこと：同じマージンがあなたの製品にもあるということ。ベンチマークに対して調整されたハーネスは、部分的にはそのベンチマークに対して調整されており、推論パズルセットは調整キューではない。

有用な読み方は、その中間に位置する。もし今日、最先端のモデルから悪い結果を得ているなら、モデルが悪いのではなく、あなたのループが間違っているという可能性をまず考えるべきだ。

ライセンスは発表である

Apache-2.0は脚注ではない。それが実質だ。

コピーレフトライセンスであれば、このハーネスは、ラップしたものを公開せずに商用製品にコンパイルしたい企業 — このローンチが構築された顧客層 — にとって、使用不可能になっていただろう。Ciscoは、Cisco Cloud Controlの一部であるApp Builder内でCodex SDKを実行している。GitHubとJetBrainsは、エージェントを開発者がすでに開いているエディタ内に配置しており、別のウィンドウではなく。Thrive HoldingsとCreteは、実務家のレビューをループに組み込んだ税務準備ワークフローを構築した。ローンチに関する報告では、約7,000件の申告で準備時間が約3分の1短縮されたとしている。

これらはチャットボットのデプロイメントではない。すべて同じエージェントループが、誰かのインターフェースを着用している。

そして、オープンになっていない部分はしっかりと閉じられたままだ：モデルだ。どうせコモディティ化されるレイヤーを開き、メーター付きレイヤーを閉じたままにするのは、よく使われる形だ — うまくいくからよく使われるのだ。組み込まれたハーネスはすべて、請求関係が付随したクライアントだ。

問題は統合から許可へと移行する

Model Context Protocolは、すでに多くのコネクタ作業を、各アプリケーションのカスタム接着剤から、一度メンテナンスされる再利用可能なサーバーへと移行させていた。標準的なオープンハーネスは、残りのほとんどを移行させる。

残ったものは、より小さな問題ではない。それは異なる問題であり、モデルを所有する者ではなく、製品を所有する者に属する問題だ：

• スコープ。 このエージェントは何を許可されているのか — 読み取り、書き込み、支出、送信、削除 — そしてそれはプロンプトで要求されるのではなく、ランタイムで強制されるのか？
• ゲート。 どの操作に人が必要で、その人は実際に判断するのに十分な情報を見ているのか、それとも要約に承認をクリックしているのか？
• 信頼できない入力。 顧客のメール、チケット本文、ウェブページ、プルリクエストのコメントを読むエージェントは、攻撃者が制御できるテキストを読んでいることになる。緩和策は、より良い指示ではなく、許可境界である。
• リコール。 インシデントの後、監査人の前で、「実際に何をしたのか」をログから回答できるか？

オープンハーネスはこれらの質問を早期に強制するため、改善である。しかし、それらの質問に答えることはない。

どこに広がり、どこで停滞するか

このリリースに伴う期待は、エージェントが開発者ツールからセキュリティ、サポート、営業、マーケティングコンソールへと移行することだ。その多くは起こるだろうし、その形はすでにうまくいっていることから予測可能だ。

定着するデプロイメントは、安価な検証を共有する。コーディングは、テストが自動的な判定を下すため、最初に行った。税務準備も同じ理由で適格だ：申告書は調整されるかされないかのどちらかであり、実務家は全体ではなく例外をレビューする。サポートのトリアージ、請求書の照合、証拠収集 — 同じファミリーだ。

停滞するものは、人がその出力全体を読んで、それが正しいかどうかを知る必要があるものだ。そこではエージェントはタイピングを節約したのであって、仕事を節約したわけではなく、どんなハーネスもそれを修正することはできない。

私たちが見ていること

• ポータビリティ。 チームが本当に非OpenAIモデルをこのループで実行するのか、それともデフォルトが静かに流通チャネルにするのか。
• ガバナンスのデフォルト。 デフォルトで出荷される承認ゲート、予算、ロギングは業界の最低ラインになる。デフォルトでオフで出荷されるものは、業界のインシデントレポートになる。
• 標準化が次にどこに着地するか。 MCPでツール公開が標準化された。実行は今標準化されている。許可と監査は明白な次のレイヤーであり、誰もそれを主張していない。
• スコアボード。 足場の変更が25ポイントの価値があるなら、ベンチマークテーブルはモデルと一緒にハーネスを報告し始めるか、モデルの結果として引用されるのをやめる必要がある。

ヘッドラインは、OpenAIがCodexのコアをオープンソース化したことだ。より持続的な変化は、「どのモデルか」という問題が先週よりも小さくなり、「何が許可されているか」という問題がより大きくなったことだ。