投稿者 投稿日: カテゴリー AIニュース
ハーネスとは、AIモデルを実際に動かす実行環境やエージェント基盤のことです。
2026年に入って、モデル同士のスコア比較が意思決定の役に立たなくなりました。理由は単純で、同じモデルを載せるハーネスが違えば、成功率も速度もコストも変わってしまうからです。実測では、同一モデルを4つのエージェント基盤に載せたとき、成功タスク1件あたりの単価が0.073米ドルから0.195米ドルまで、約2.7倍の開きが出ています。EC事業者がツールを選ぶとき、比較すべき対象は「モデル」ではなく「モデルとハーネスの組み合わせ」に変わりました。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル（うるチカラ運営）が、選定基準として整理します。
同じモデルなのに、単価が2.7倍違った実測
まず数字から入ります。AIツール企業のComposioが、DeepSeek V4 Flashという同一モデルを4つのエージェント基盤に載せ、Gmail、GitHub、Slack、Notionといった実際のツールを使う30タスクで比較しました。The Decoderが伝えた結果は、順位が項目ごとにばらばらというものでした。
成功タスク1件あたりの単価が最も安かったのはOpenCodeで0.073米ドル。最も速かったのはClaude Codeで1タスクあたり122秒でしたが、単価は0.195米ドルと最も高く、安いほうと比べて約2.7倍でした。興味深いのは、Claude Codeがツール呼び出し回数が最も少なく、出力トークンも最少だったにもかかわらず単価が最高だった点です。成功率で見ると最も高かったのはOh My Piの30タスク中17件でしたが、1タスクあたり272秒と最も遅い結果でした。
つまり、速さ、安さ、成功率のどれを取るかで答えが変わり、しかもモデルは全部同じです。この結果が示しているのは、性能の相当部分がモデルではなくハーネス側で決まっているという事実です。ツール呼び出しの設計、コンテキストの詰め方、再試行の戦略、並列化の有無。これらはすべてハーネスの実装であり、モデルカードには書かれていません。
EC業務に置き換えると、この差は無視できません。商品説明文の一括生成、レビューの分類、在庫データの突き合わせ。いずれもツール呼び出しを伴う多段の処理であり、ハーネスの設計がそのまま処理時間とAPI料金に効きます。モデル単体のトークン単価だけで比較して「こちらが安い」と判断すると、実運用で逆転する可能性があります。
複数モデルの併用を前提にコストを設計する話はマルチモデルのルーティング設計とAPIコストで扱っていますが、今回の論点はその一段手前、比較の土俵そのものが揺らいでいるという話です。
ベンダー公表スコアが読めなくなった3つの構造
第1の構造は、モデルとハーネスの共同最適化です。2026年8月にMetaがベータ公開したMuse Codeでは、評価がMeta自身のハーネス上で実施されており、Meta自身が「自社のハーネスは第三者モデル向けに調整されていない可能性がある」と注記していると報じられています。この注記は誠実ですが、裏を返せば、公表スコアはモデルの実力だけでなく、モデルとハーネスの噛み合わせの良さを測っていることになります。
実際、利用者からは自社ハーネス外での性能低下が報告されています。Digital Appliedがまとめた開発者コミュニティの反応では、Muse Sparkを別のCLIや集約サービス経由で試したところ単純なタスクを完了できず、検索系のツール呼び出しを延々と繰り返して止まったという報告が出ています。この読みが一般化するなら、ベンダー自社ハーネスでのスコアは、他社環境での挙動をほとんど説明しません。
第2の構造は、スコアの検証可能性です。同じくMuse Spark 1.2の評価は、Terminal-Bench 2.1の全89タスク、DeepSWEの113タスク、実際の社内プルリクエスト由来の440タスクという規模で実施されたと報じられています。規模としては十分ですが、スコア自体はチャート画像として公開されており、機械可読な数値が読み取れません。第三者が再計算して比較することが構造的にできない形です。
第3の構造は、ベンチマーク名の同一性の崩壊です。同じ名前のベンチマークでも、バージョンとハーネスによって測っているものが違います。デスクトップのGUI操作を測るものと、コマンドライン作業を測るものが、いずれも「エージェントの能力」として並べられる。比較する前に、そのスコアがどのバージョンのどのハーネスで測られたかを確認しないと、数字の意味が揃いません。
現場感覚では、この3つが重なった結果として、ベンダー公表スコアは「そのベンダーの環境で最適化した場合の上限値」として読むのが実態に近くなっています。自社での実測値の予測には使えません。
EC事業者が自分で測るための評価タスク設計
結論を先に書くと、公表スコアの読み解きに時間を使うより、自社業務から20タスクを切り出して実測するほうが早く正確です。所要時間は準備を含めて2日、費用は数千円規模で足ります。
評価タスクの作り方には型があります。まず、自社の定型作業から代表的なものを5系統選びます。商品説明文の生成、レビューの分類、問い合わせの要約、在庫データの異常検出、競合ページの要約。この5系統それぞれについて、実際のデータを使った具体的なタスクを4本ずつ用意すれば20タスクになります。
重要なのは、正解を先に定義することです。生成系のタスクは正解が一意に決まらないので、「合格条件」の形で書きます。商品説明文なら「冒頭80字以内に商品の要点が入っている」「最大級表現を含まない」「指定した3つの訴求がすべて含まれている」といった、はい・いいえで判定できる条件に分解します。この分解ができていないと、比較結果が担当者の好みに左右されます。
測る項目は4つです。合格したタスク数、1タスクあたりの所要時間、1タスクあたりのAPI料金、そして人手による修正が必要だった箇所の数です。4つ目を入れるのは、合格ラインぎりぎりで通ったものと余裕を持って通ったものを区別するためです。実運用では、この差が担当者の負担に直結します。
同じ20タスクを、候補となる2つから3つの組み合わせに対して流します。組み合わせとは、モデルとハーネスのペアです。同じモデルを別のハーネスで、あるいは同じハーネスに別のモデルを載せて。この2軸で回すと、性能差がどちら側から来ているかが切り分けられます。モデル選定の考え方そのものはQwen3.8 Maxの誤答率から見るEC選定視点でも整理しています。
実測と乗り換え判断のためのプロンプト5本
以下の5本で、評価タスクの設計から乗り換え判断までを回せます。
プロンプト1：自社業務から評価タスク20本を切り出す
あなたはAIツールの評価設計に詳しいコンサルタントです。
以下のEC業務から、AIツールの比較評価に使うタスクを20本設計してください。
自社の業務内容：
- 取扱ジャンル：{ジャンル}
- 出店モール：{楽天／Amazon／Yahoo!／Shopify／自社EC}
- SKU数：{数}
- AIに任せたい定型作業：{作業1、作業2、作業3、作業4、作業5}
設計条件：
1. 5系統の作業から各4本、合計20本
2. 各タスクに「合格条件」を、はい／いいえで判定できる形で3つ以上定義する
3. 生成系のタスクは、正解を1つに固定せず合格条件で判定する形にする
4. 実データを使う前提で、必要な入力データの種類を明記する
5. 1タスクの想定所要時間を記載する
出力形式：タスク番号、系統、タスク内容、合格条件、必要な入力データ、想定所要時間
プロンプト2：ハーネスとモデルの組み合わせを設計する
以下の候補から、比較すべき組み合わせを設計してください。
候補モデル：{モデルA、モデルB、モデルC}
候補ハーネス／ツール：{ツールA、ツールB、ツールC}
自社の制約：
- 月間予算：{金額}円
- 社内にエンジニアが{いる／いない}
- 扱うデータの機密度：{高／中／低}
- 既存の業務スクリプトの有無：{あり／なし}
出力してほしい内容：
1. 比較すべき組み合わせを3つ以内に絞り、その理由
2. 各組み合わせで、モデル側とハーネス側のどちらの寄与を測ろうとしているか
3. 除外した組み合わせと、除外理由
4. 比較の前に確認すべき契約・規約上の項目
注意：候補を全部試そうとしないこと。組み合わせ数が増えると評価が終わらなくなります。
プロンプト3：評価結果を採点表にまとめる
以下の実測結果を、意思決定に使える形に整理してください。
実測結果：
{組み合わせごとの、合格タスク数・所要時間・API料金・修正箇所数}
出力してほしい内容：
1. 4指標それぞれの順位と、1位と最下位の差の倍率
2. 総合順位を出さず、「速度優先ならこれ」「コスト優先ならこれ」「品質優先ならこれ」の形で提示
3. 指標間でトレードオフになっている箇所の指摘
4. 20タスク中、どの組み合わせでも失敗したタスクがあれば列挙（AIに任せるべきでない作業の候補）
5. サンプル数20に対して、統計的に差があると言い切れるか否かの注記
注意：総合スコアで1位を決めないでください。用途によって答えが変わることを前提に整理してください。
プロンプト4：ロックインの度合いを診断する
現在使っているAIツール構成について、ベンダーロックインの度合いを診断してください。
現在の構成：
- 使用ツール：{ツール名}
- 使用モデル：{モデル名}
- 蓄積している資産：{プロンプト集／手順書／スキル定義／カスタムGPT／自動化スクリプト}
- 資産の保管場所：{ツール内のUI／自社のGitリポジトリ／クラウドストレージ}
診断してほしい観点：
1. ツールを解約した場合に失われる資産はどれか
2. 資産をテキストとして書き出せるか、書き出せないか
3. 別ツールへ移行する場合に書き直しが必要な割合の見積もり
4. モデルを差し替えた場合に壊れる可能性がある箇所
5. ロックイン度合いを高・中・低で判定し、理由を明記
出力後、ロックインを下げるために今週できる行動を3つ提案してください。
プロンプト5：乗り換えの損益分岐を計算する
現行ツールから候補ツールへの乗り換えについて、損益分岐を計算してください。
現行：
- 月額固定費：{金額}円
- 月間の従量課金：{金額}円
- 月間の作業時間：{時間}時間
候補：
- 月額固定費：{金額}円
- 月間の従量課金見込み：{金額}円
- 実測での作業時間見込み：{時間}時間
移行にかかるもの：
- プロンプト・手順書の書き直し工数：{時間}時間
- 検証期間：{週}週
- 社内教育の工数：{時間}時間
- 移行期間中の二重契約費用：{金額}円
計算してほしい内容：
1. 移行の初期コスト合計（人件費は時給{金額}円で換算）
2. 月次で削減できる金額
3. 投資回収までの月数
4. 回収が18か月を超える場合、移行を見送るべき理由
5. 金額に表れないリスク要因を3つ
注意：計算過程を省略せず、置いた仮定をすべて明示してください。
現場で起きる失敗と回避策
第1の失敗は、公表ベンチマークの1位を根拠に採用を決めることです。前述のとおり、公表スコアはベンダー自社ハーネスでの上限値である可能性が高く、自社環境での結果を予測しません。しかも自社業務のタスク構成は、ベンチマークのタスク構成と一致していません。ECの定型作業は、コーディングベンチマークが測っている能力とは別の能力を要求します。
第2の失敗は、評価タスクを多く作りすぎることです。100本用意すると測るだけで1週間かかり、途中で頓挫します。20本でも、組み合わせ3つなら60回の実行になります。まず20本で回して、判断がつかなかった系統だけ後から追加するのが現実的な進め方です。
第3の失敗は、合格条件を「良い感じか」で判定することです。担当者が変わると結果が変わり、比較の意味がなくなります。はい・いいえで答えられる条件に分解する作業は面倒ですが、ここを飛ばすと後の議論が全部感想になります。
第4の失敗は、ハーネス内のUIにだけ資産を貯めることです。プロンプト、手順書、スキル定義をツールの管理画面の中だけに書いていると、解約と同時に消えます。テキストファイルとして自社側に持ち、ツールにはそれを読み込ませる構成にしておけば、乗り換えコストが大きく下がります。この考え方はスキル資産の管理と共通で、Agent Skillsマーケットプレイスの比較と審査観点でも同じ結論に行き着いています。
第5の失敗は、乗り換えを頻繁にやりすぎることです。新しいモデルが出るたびに移行していると、検証と教育のコストが削減額を上回ります。移行の判断基準を「実測で3割以上の改善が出た場合のみ」といった形で先に決めておくと、話題性に振り回されずに済みます。
ロックイン回避の5原則
ここまでの整理を、実務で使える5つの原則にまとめます。
第1に、資産はテキストで自社に持つ。プロンプト、手順書、判断基準、チェックリストのすべてをMarkdownなどのプレーンテキストで保管し、バージョン管理下に置きます。ツールはそれを読み込む実行環境として扱います。
第2に、比較は組み合わせで行う。モデル単体の比較には意味が薄いので、モデルとハーネスのペアで測ります。差が出たとき、どちら側の寄与かを切り分けられる設計にしておきます。
第3に、評価は自社データで行う。公表スコアは参考情報にとどめ、採用の根拠にはしません。20タスクの実測を、四半期に1回程度は回し直します。
第4に、契約とデータ取り扱い条件を先に読む。安価な料金帯には利用データが製品改善に使われる条件が付くことがあります。仕入先や原価を含むデータを扱う場合は、この条件が採否を決めます。ベンダー依存のリスクについてはマイクロソフトCEOがAI一社依存に警告した件の3原則も参考になります。
第5に、移行の判断基準を先に決める。実測での改善幅、投資回収期間、検証にかけられる工数の3点で閾値を決めておき、それを満たさない乗り換えはしません。
費用と工数の目安
評価そのものにかかる費用は小さく収まります。20タスクを3つの組み合わせで回すと60回の実行になりますが、EC業務のタスクは1回あたりのトークン量が限られるため、API料金の合計は数百円から数千円の範囲に収まる見込みです。定額プランのツールを比較する場合は、1か月分の契約料が加わります。
工数のほうが実質的なコストです。評価タスクの設計に半日、合格条件の定義に半日、実行と記録に1日、結果の整理に半日。合計で2日程度が目安になります。この2日を「面倒だから公表スコアで決める」に置き換えたときの損失は、選定を1年間引きずることを考えれば安いものです。
継続的な運用としては、四半期に1回の再評価を推奨します。モデルの世代交代が数か月単位で起きている状況では、年1回では追いつきません。逆に月1回では評価疲れを起こすので、四半期がちょうどよい間隔です。
比較の土俵は、いずれ誰かが作り直す
見立てを書いておくと、この状況は放置されません。機械可読なスコアを、複数のハーネスにまたがって公開する第三者の評価基盤が出てくるはずです。すでにモデル配信サービスが料金と性能を横並びで載せる形は定着しており、ハーネス込みの比較がそこに乗るのは時間の問題だと考えます。
ただし、その基盤が整ったとしても、EC事業者が自社タスクで実測する必要はなくなりません。理由は、汎用ベンチマークのタスク構成が自社の業務構成と一致しないからです。商品説明文の生成、レビュー分類、在庫の異常検出という組み合わせは、どの汎用ベンチマークにも入っていません。第三者評価は候補を絞るために使い、最終判断は自社データで下す。この二段構えは、比較基盤が整備されても変わらないと判断します。
競合が書けていない論点をもう1つ挙げると、ハーネスの乗り換えコストは、モデルの乗り換えコストより高くつきます。モデルは差し替えれば済みますが、ハーネスを変えると、承認フロー、権限設定、ログの形式、社内教育まで全部が変わります。にもかかわらず、選定の議論はモデルの話に偏りがちです。EC事業者が本当に慎重に選ぶべきは、モデルではなくハーネスのほうです。この非対称性を意識するだけで、選定の重心が正しい場所に移ります。
実測の2日間を、具体的にどう進めるか
抽象論のままだと着手されないので、2日間の進め方を時間割の形で示します。
1日目の午前は、評価タスクの選定です。過去1か月に実際に発生した作業から、頻度の高いものを拾います。ここで大事なのは、実際のデータを使うことです。サンプルデータで測ると、自社の商品名の表記ゆれや、モール独自の項目名にどう反応するかが分かりません。商品説明文の生成なら実際の新商品、レビュー分類なら実際に投稿されたレビューを使ってください。
1日目の午後は、合格条件の定義です。ここが最も時間を食います。20タスクそれぞれに3つ以上の条件を、はい・いいえで判定できる形で書きます。「読みやすい」は不可、「1文が60字を超えていない」は可。「訴求が伝わる」は不可、「指定した3つの訴求語がすべて含まれている」は可。この書き換え作業を通じて、自社が何を求めているかが言語化されるという副次的な効果もあります。
2日目の午前は、実行です。組み合わせを3つに絞っていれば60回の実行になります。1回3分としても3時間ですが、並行して回せるものは同時に進めれば短縮できます。記録は、タスク番号、組み合わせ、合格した条件数、所要時間、修正が必要だった箇所数の5列で十分です。
2日目の午後は、集計と判断です。4指標それぞれで順位を出し、用途別に推奨を分けます。総合1位を決めようとしないでください。速度優先、コスト優先、品質優先で答えが違うのが正常な結果であり、無理に1つにまとめると判断材料が失われます。
この2日で得られる最大の成果は、順位そのものより「どのタスクはどの組み合わせでも失敗したか」の情報です。全滅したタスクは、いまの技術水準ではAIに任せるべきでない作業を示しています。この線引きが分かるだけで、無駄な自動化への投資を止められます。
選定基準を社内文書に落とす
実測が終わったら、判断を文書に残してください。残さないと、半年後に新しいモデルが出たときに同じ議論を最初からやり直すことになります。
文書に書くべき項目は6つです。第1に、いつ、どの組み合わせを、どの20タスクで測ったか。第2に、4指標の結果。第3に、採用した組み合わせと、その理由。第4に、採用しなかった組み合わせと、除外理由。第5に、次に見直す時期。第6に、見直しの引き金になる条件です。
第6の項目が特に重要です。「実測で3割以上の改善が出た場合」「月額が現行の半額以下になった場合」「現行ツールに重大な障害が3か月で2回以上発生した場合」といった条件を先に書いておくと、話題性で動くことを防げます。逆に条件を満たしたときには迷わず再評価に入れます。
この文書は、社内の説得材料としても機能します。AIツールの選定は「なんとなく良さそう」で決まりがちで、後から費用の妥当性を問われたときに説明できないことが多い領域です。20タスクの実測結果と判断理由が1枚の文書になっていれば、経営層への説明も、担当者交代時の引き継ぎも、格段に軽くなります。
ある食品ジャンルの中規模店舗の事例では、この文書を作ったことで、新しいツールの提案が来るたびに「うちの20タスクで測ってから判断します」と返せるようになり、検討にかかる時間そのものが減りました。選定基準を持つことの効用は、正しい選択をすること以上に、選択に費やす時間を減らすことにあります。
よくある質問
ハーネスとモデルはどう違いますか
モデルとは文章や判断を生成する部分のことで、ハーネスとはそのモデルを実際に動かし、ツールを呼び出し、結果を受け取って次の行動を決める実行環境のことです。同じモデルでもハーネスが違えば、成功率も速度もコストも変わります。
公表ベンチマークは全く参考にならないのですか
いいえ、候補を絞る用途では役に立ちます。ただし採用の最終根拠にはできません。ベンダー自社のハーネスで測られている可能性が高く、自社業務のタスク構成とも一致しないためです。候補を3つ程度に絞る段階までの参考情報として使ってください。
同じモデルでコストが2.7倍違うのはなぜですか
ハーネスによってツール呼び出しの回数、再試行の戦略、コンテキストの詰め方が違うためです。実測では、ツール呼び出し回数が最少で出力トークンも最少だった基盤が、成功タスク単価では最も高くなるという結果も出ています。トークン単価だけでは実コストを予測できません。
評価タスクは何本くらい用意すべきですか
20本が現実的な出発点です。5系統の業務から各4本という配分にすると、系統ごとの得意不得意が見えます。組み合わせを3つ比較すると60回の実行になり、記録を含めて1日から2日で終わります。
乗り換えの判断基準はどう決めればよいですか
実測での改善幅、投資回収期間、検証にかけられる工数の3点で閾値を先に決めてください。目安としては、実測で3割以上の改善が出て、移行の初期コストが18か月以内に回収できる場合に限る、といった形です。基準を先に決めておかないと、話題性で動くことになります。
ロックインを完全に避けることはできますか
いいえ、完全な回避は現実的ではありません。目指すべきは、乗り換えコストを許容範囲に収めることです。プロンプトと手順書をテキストで自社に持ち、ツール固有の設定に依存する部分を最小化しておけば、乗り換え時の書き直しは大幅に減らせます。
社内にエンジニアがいなくても実測できますか
はい、可能です。商品説明文の生成やレビュー分類といったタスクは、ツールの画面から実行して結果を記録するだけで測れます。所要時間と修正箇所数は手作業で記録できます。API料金の把握だけは管理画面の確認が必要ですが、定額プランのツール同士であればそこも不要です。
今週着手するなら、この順番で
最後に、今週から動く場合の順番を示します。初日は、いま使っているAIツールで実際に発生している定型作業を5系統書き出すだけで構いません。作業そのものではなく、系統の名前を書くだけです。2日目に、各系統から代表的なタスクを4本ずつ選び、実データを添えて20本のリストにします。3日目に合格条件を書き、4日目と5日目で実測と集計を回す。この配分なら1週間で結論が出ます。
先に手を付けるべきでないのは、新しいツールの情報収集です。候補が増えるほど組み合わせが爆発し、評価が終わらなくなります。いま使っている構成を1つ目の候補として固定し、比較対象は2つまでに絞ってください。現行構成が勝つ結果になったなら、それは「乗り換えなくてよい」という価値のある結論です。
著者：齋藤竹紘（株式会社オルセル 編集長／5,000社以上のEC支援実績／書籍3冊）
参考文献
- The Decoder・Claude Code is the fastest agent framework but costs nearly three times more than the cheapest rival
- Digital Applied・Inside Muse Code: Subagent Fan-Out, Skills, Event Logs
- Digital Applied・OSWorld vs Terminal-Bench: What Agent Scores Really Mean
- Firecrawl・Best AI Coding Agents in 2026: Harness, Cost, and Accuracy Compared
※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/
【監修】齋藤竹紘（株式会社オルセル代表 / 19年・5,000社のEC支援実績）
株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。
この記事を読んだ人は、こんな記事も読んでいます
