提案書のモデル名ばかり見ている方へ

AIエージェントの開発を検討していて、提案書の「GPT-5.6を使用」「Claude対応」といったモデル名で品質を判断しそうになっている方に向けて書いています。

結論を先に言うと、エージェントの品質はモデルとハーネスの掛け算で決まります。ハーネスは聞き慣れない言葉だと思いますが、この1語を押さえるだけで、提案を評価する軸が1つ増えます。冒頭の数字は、その軸がどれだけ効くかを示しています。

ハーネスとは実行の仕組みのことです

ハーネス(harness)は、プロンプトとモデルの間にあるソフトウェアの層です。エージェントは「モデルに指示を出したら勝手に動くもの」ではありません。タスクを分解し、ファイルを読み、コマンドを実行し、失敗したらやり直し、危ない操作の前に人間へ確認する。この一連の実行を回すシステムがハーネスです。

ハーネスが担う機能 内容
会話状態の管理 何度もやり取りをまたいで作業を続ける
ツール呼び出し 検索・ファイル操作・外部システムをモデルから使えるようにする
サンドボックス 決めた範囲の外に出ないよう実行環境を隔離する
承認 影響の大きい操作の前に人間の判断を挟む
失敗処理 エラー時のリトライ・代替手段・停止を決める
コンテキスト管理 履歴が長くなったとき何を残し何を要約するか決める

Claude CodeやCodexといったコーディングエージェントの「本体」は、実はこの層です。モデルはAPIの向こう側にあり、手元で動いているのはハーネスです。OpenAIは2026年8月19日のブログで、Codexのアプリ・CLI・IDE拡張はすべて同じハーネスの利用形態にすぎないと説明し、そのハーネス自体を製品に組み込める部品として位置づけました。

同じモデルでスコアが約3倍になりました

冒頭の数字の中身です。同じブログによると、ゲーム環境で汎用能力を測るARC-AGI-3ベンチマークで、GPT-5.6 Solというモデルのスコアが13.3%から38.3%へ上がりました。モデルは同じです。変えたのはハーネス側の2点だけです。

しかも出力トークンは6分の1に減っています。性能が上がって、消費は減った。実行側の設計だけでこの幅が動きます。

この数字には限界もあります。OpenAIが自社ブログで示した自社測定の値で、第三者による再現や詳細な条件は公開されていません。それでも「モデルを据え置いたまま、実行側の設計で結果が大きく変わる」という事実関係は、発注側が知っておくべきものです。逆に言えば、優れたモデルを選んでも、ハーネスの設計が悪ければその性能は出ません

モデル名だけで仕様を書くとどうなるか

エージェント開発のRFPや仕様書には、モデル名が書かれていることがほとんどです。「GPT-5.6以上を使用すること」「Claudeの最新モデルに対応すること」。一方で、ハーネス側の要件が書かれている仕様書はまず見かけません。

しかし本番で結果を分けるのは、次のような実行側の設計です。

同じモデルを使った2社の提案でも、ここの設計次第で本番の挙動は別物になります。モデル名は書いてあるのに、結果を左右する側が仕様に入っていない。これがモデル名だけで書かれた仕様書の穴です。

主要各社はハーネスを公開し始めています

2026年8月時点で、この層は各社の競争の中心になっています。OpenAIはCodexのハーネスをApache-2.0ライセンスで公開し、その上に自社製品を作れると宣言しました。GoogleのGemini CLIも同じくオープンソースです。DeepSeekは2026年8月13日に、すべてをプラグインとして差し替えられる設計のハーネスを公開しました。

一方Anthropicは、Claude Codeのハーネス本体を公開せず、Agent SDKという組み込み用ライブラリを通じて使わせる方針です。公開の仕方に各社の戦略の違いが出ており、どれを土台に選ぶかは費用とロックインの論点になります。この選定の話は稿を改めます。

ここで押さえてほしいのは1点だけです。ハーネスは特定ベンダーの秘伝ではなく、中身を確認できる公開されたソフトウェアになったということです。つまり開発会社に「どのハーネスを使い、何を自作しているのか」と聞くことは、答えられて当然の質問になりました。

開発会社に聞く5つの質問

モデル名の代わりに、実行側の設計を確認する質問です。

エージェント開発の提案を受けたときの5つの質問

  • どのハーネスを使い、何を自作していますか: 公開されたハーネスやSDKが土台なのか、独自実装なのか。独自なら、会話状態・失敗処理・承認をどう検証したかまで聞きます
  • コンテキストが溢れたときの方針は何ですか: 要約するのか、分割するのか、止まるのか。長い業務プロセスで性能が落ちる主因はここです
  • 影響の大きい操作の承認はどの層で挟みますか: プロンプトで「確認してください」と頼むのは承認ではありません。実行側のコードで強制されているかを確認します
  • ツールの失敗をどう扱いますか: リトライ・代替・停止の設計。デモでは失敗が起きないので、ここは聞かないと分かりません
  • モデルを入れ替えたら何が壊れますか: ハーネスとモデルの結合度は、将来モデルを乗り換える余地をそのまま決めます

RFPの技術要件や、提案比較の質問表にそのまま使えます

現場メモ

この記事の調査で、SNSで広く読まれていたハーネスの技術解説2件を一次情報と突き合わせたところ、2件とも誤りを含んでいました。1件は元記事に存在しない他社事例の数字が混ざり、もう1件は開発元が「本番では使うな」と明記している通信方式を標準として紹介していました。新しい言葉ほど、二次情報は汚れます。私たちは記事の数字を、公式ブログ・リポジトリ・公式ドキュメントの原文で裏を取ってから書いています。

発注側にとっての意味

エージェント開発の広告はモデルの新しさを語ります。しかし本番で動き続けるかどうかは、この記事で見たとおり実行側の設計で決まります。導入の進め方を現場で量産する路線と基幹業務へ組み込む路線に仕分けたうえで、組み込む路線を選ぶなら、ハーネスの設計とあわせてエージェントに与える権限をコードで絞る設計まで確認してください。

自社の業務にエージェントを組み込む構想があり、モデル選定の手前で実行側の設計から整理したい場合は、お問い合わせからご相談ください。ハーネスの選定と承認の設計から入ります。