CodexとHermesを現行構成で比較：品質は互角、Hermesは23%高速

AIエージェントの性能は、モデル名だけで決まるのか。普段使っているAGENTS.md、Skills、ツール、権限まで含めると結果はどう変わるのか。

今回、実際に使っているCodexとHermesの構成をほぼそのまま使い、同じ8ケースを解かせました。差や実行異常が出た4ケースはもう一度実行しています。合計は12採点ペア、24 armです。

結論

品質に明確な勝者はいませんでした。現行構成全体で見ると、HermesはCodexとほぼ同じ品質を保ちながら、総実行時間が22.9%短い結果でした。日常利用ではHermesを第一候補にしてよさそうです。

指標	Codex	Hermes
PASS	9 / 12	11 / 12
平均score	0.9554	0.9688
総実行時間	2,024.3秒	1,561.6秒
nonzero exit	1	0
timeout	0	0

ペア単位ではCodex 1勝、Hermes 3勝、同点8件。PASS/FAILの不一致に対するMcNemar exact testはp=0.625で、この小標本から品質差があるとは言えません。

Blind reviewもほぼ同じ結論です。候補名をA/Bへ隠して2名が独立評価したところ、合計はCodex 7勝、Hermes 6勝、同点3件でした。機械scoreではHermesが少し上ですが、人間に近い観点では互角です。

なぜこの比較をしたか

きっかけは、AIエージェントの性能は「モデル名」より「ハーネス×モデル」の組み合わせで決まるという投稿でした。

元になったEnterpriseClawBenchは、実際の職場セッションから852の再現可能タスクを構成したベンチマークです。論文のbest configurationでもscoreは0.663。モデルだけでなく、ハーネス、artifact delivery、visual quality、cost、runtime、skill transferまで分けて評価する必要があるとしています。

これは普段の感覚とも合います。同じモデルでも、AGENTS.mdの書き方、Skillsの量と選び方、承認ルール、使えるツール、成果物を書き込める場所が違えば、動きはかなり変わります。

そこで、共通の最小設定へ寄せるのではなく、まず「今の自分の環境ではどちらが役立つか」を測りました。

比較した構成

項目	Codex	Hermes
model	gpt-5.6-luna	gpt-5.6-sol
reasoning	max	現行default + delegation xhigh
AGENTS.md	共通	共通
Skills	共有500件	共有500件
filesystem	workspace-write	現行tool構成

同じAGENTS.mdと同じSkill libraryを参照させましたが、model、provider、tool surface、Skillの読み込み方は異なります。したがって、これは純粋なモデル比較でも、純粋なハーネス比較でもありません。「現在使っている実運用スタック全体」の比較です。

8つのケース

外部アカウントや本番データへ副作用を出さず、成果物を機械的に検証できるケースを選びました。

入力不足のTAM/SAM/SOM推計で数字を捏造しない
利用時間データの統計的な読み方を監査する
AGENTS.mdの矛盾・過剰ルール・scope creepを監査する
manual fallback実装の安全条件をreviewする
incident logからENOSPCの根本原因を特定する
Pythonのquota処理を修正し、テストを通す
CSVから1200×900のSVG dashboardを作る
X APIの料金・実装に関する主張を一次資料で監査する

各試行は別workspaceへ隔離し、前試行の生成物を持ち込めないようにしました。期待成果物、hidden verifier、workspace外への書き込み、return code、wall time、tokens、tool callsを保存しています。

ケース別の結果

case	Codex 初回	Hermes 初回	再試行
入力不足/TAM	0.8571	1.0000	1.0000 / 1.0000
利用時間監査	0.7500	1.0000	1.0000 / 0.6250
AGENTS監査	1.0000	1.0000	-
fallback review	1.0000	1.0000	-
incident triage	1.0000	1.0000	-
Python bugfix	1.0000	1.0000	-
SVG artifact	1.0000	1.0000	1.0000 / 1.0000
source claim	0.8571	1.0000	1.0000 / 1.0000

初回だけを見るとHermes 8/8、Codex 5/8です。しかし差が出たケースを再実行すると、3ケースが同点になり、利用時間監査はCodex側が勝ちました。

この揺れは重要でした。1回だけの結果から「このagentは事実確認に強い」「このagentは統計が苦手」と決めるのは危険です。今回観測できたのは、安定した能力差というより試行間分散でした。

2名のreviewerにはCodex/Hermesという名前を見せず、primary 8ケースのresponseとartifactだけを渡しました。

reviewer	Codex勝ち	Hermes勝ち	同点
1	3	3	2
2	4	3	1

2名が一致したのは8ケース中6ケースです。

CodexはPythonの境界条件、manual fallback、利用時間分析で選ばれました。HermesはAGENTS.md監査とsource claim監査で選ばれています。incident triageは両者とも同点。TAMとSVG dashboardはreviewerの好みが分かれました。

source claim監査では、Codex初回のpartly_trueだけが2名ともFAILでした。X Data APIの単価自体は正しくても、調査対象のx_searchは別サービスです。個々のフィールドが正しくても、全体判定が噛み合わない例でした。再試行ではCodexもfalseへ修正してPASSしています。

速度とtokens

指標	Codex	Hermes
12 arm総時間	2,024.3秒	1,561.6秒
平均	168.7秒	130.1秒
中央値	92.2秒	116.3秒
p75	245.1秒	158.6秒
最大	424.0秒	389.8秒
tokens中央値	91,532	117,711
output tokens	70,111	35,754
tool calls	99	55

中央値だけならCodexが速く、Hermesの方がtokensを使っています。一方、p75と総時間はHermesが短い。Codexには長い試行がいくつかあり、合計ではHermesが22.9%短くなりました。

Scored armで計測できたtokensは合計3,745,426。calibrationとblind reviewまで含め、直接計測できた範囲は6,825,736 tokens以上です。Codex 1 armのusageと、main orchestratorなど一部が欠測しているので、campaign全体の総tokensは確定していません。

実行枠はpreflight前の残り85%から、blind review完了時に75%まで減りました。全工程は約3時間1分、scored armのmodel実行合計は59.8分でした。

一番大きかったのはSkill数の問題

今回の差より気になったのが、Codex側で全12試行に出た警告です。

Exceeded skills context budget of 2%

Skill descriptionsが除外され、追加318 Skillsがmodel-visible listへ入りませんでした。共有ライブラリには500 Skillsあります。同じSkill directoryを置くだけでは同条件にならず、ハーネスごとの読み込み上限と発火方式まで確認しなければいけません。

それでもCodexはコード実装とSVG成果物を完遂しました。能力不足というより、現在のSkill catalogがCodexの見せ方に合っていない可能性があります。次に改善するなら、モデルを変える前に、タスクごとに見せるSkillsを絞るべきです。

ベンチ自体で起きた失敗

比較中には2つの運用障害がありました。

1つ目はdisk fullです。最初のscored run中、Data volumeの空きが127MBまで減り、runnerがstdoutを保存できませんでした。再生成可能cacheだけを整理して18GBを回復し、壊れたattemptは採点から除外、同じ条件で再実行しました。

2つ目はworkspace pathです。calibration時、Hermesのterminalが既定cwdを使い、相対pathの成果物をworkspace外へ書きました。両agentのpromptへ絶対workspace pathを追加し、calibration結果はscoreへ入れていません。

graderにも日本語の同義表現を拾えない箇所がありました。rubricを修正した場合は全armを同じ規則で再採点し、差が出たケースを両者とも再実行しています。

ベンチマークは、agentだけでなくrunnerとgraderも壊れます。失敗をそのままモデルscoreへ入れないこと、片方だけ有利になる修正をしないことが必要でした。

今回の判断

今の環境では、日常の第一候補をHermesにします。品質差は確定できませんが、長い外れ値が少なく、scored runでnonzero exitがなく、総時間も短かったためです。

ただし「HermesのモデルがCodexより賢い」という結果ではありません。Blind reviewはほぼ互角で、再試行ではCodexが取り返しています。Codex側のSkill context overflowを直したら、結果が変わる可能性もあります。

今回分かったのは、エージェントをモデル名だけで比較しても足りないということでした。モデル、ハーネス、AGENTS.md、Skills、tools、permissions、runner、graderまで含めて、普段のタスクで測る必要があります。

限界

8ケースと条件付き再試行4件の小標本
全ケースを2反復したわけではない
model/provider/tool surfaceが異なる
live browser、外部write、実アカウント操作は含めていない
1件のCodex usageがcapacity errorで欠測
public benchmarkではなく、自分の現在の実運用構成に対する評価

結果を一般化するためのベンチではありません。自分の環境で次に何を直すかを決めるための回帰テストです。

2001Y@Y20010920T