Hermes Agent の Mixture of Agents (MoA) を試してみた

はじめに

こんにちは、クラスメソッド製造ビジネステクノロジー部の森茂です。

Nous Research の Hermes Agent に Mixture of Agents (MoA) という機能が追加されました。「複数の LLM に同じ問いを投げて、その意見をもう 1 つの LLM が合成する」という、論文としては 2024 年からある発想のようですが、いま再注目されている理由を実機で触りながら見ていきたいと思います。

結論を先に書いておくと、HermesBench という Nous 社内ベンチマーク上で Claude Opus 4.8 単体比 +7.82% の品質改善を主張する一方、自分の手元では OpenRouter での実コストが Opus 単体比およそ 80 倍という極端な数値が確認できました。「払う価値があるか」を読者自身が判断できる材料を、実機データを集めて整理します。

なぜ今 MoA が再注目されているのか

MoA という発想自体は新しくありません。Together.ai が 2024 年 6 月に Mixture-of-Agents Enhances Large Language Model Capabilities で論文化したのが起点で、「N 個の reference モデルが意見を出し、1 つの aggregator モデルが合成する」というパターンとして知られています。

それが 2026 年のこのタイミングで再び話題に上がっている背景には、フロンティアモデルへのアクセスが段階的に絞られている構造変化があります。直近では 2026 年 6 月 12 日に、米国政府の輸出規制を受けて Anthropic の Fable 5 と Mythos 5 が全顧客に対して利用停止になりました。米国内外、外国人非外国人問わず、API も Web インターフェースも含めた全 deployment method がいきなり切られる、というかなり重い対応でした。Claude Opus 4.8 や GPT-5.5 の rate limit と価格上昇、Sakana Fugu のような「裏側で複数モデルを束ねるクローズドな orchestration system」の登場とあわせて、最強モデルは段々と「選ばれた少数」のものになってきている印象です。

そんな空気の中、Nous Research が公式 X で次のように発信しました。

The strongest models are gated and access is granted only to a select few. Hermes Agent now exposes MoA presets as virtual models, giving you capabilities beyond the publicly available frontier: 8% higher than Opus 4.8 and 11% higher than GPT 5.5 on our upcoming benchmark.

これは「最強モデルが特定の人しか触れないなら、複数のモデルを束ねて frontier を超える」という MoA の本質を、いまの業界状況に重ねた発信だなと感じます。Teknium 氏も「open source モデルの組み合わせで Opus 相当を狙いたい」と続けており、合議パターンの選択肢として MoA が再び現実解になってきたといえそうです。

Hermes Agent における MoA の位置付け

MoA は Hermes Agent に「virtual model provider」として組み込まれていて、/moa コマンドや --provider moa 指定で一発呼び出しできるようになっています。

複数 LLM を束ねるパターン自体は他にもいくつかあり、それぞれ思想が違います。自分が直近で触ってきたものと並べると、こんな整理になります。

Hermes MoA はこの 3 つ目で、reference と aggregator の構成をユーザーが直接編集できる透明性が個人的には一番面白いところでした。

MoA の仕組み（reference + aggregator）

公式 docs では MoA を次のように説明しています。

Use MoA when a hard task benefits from multiple model perspectives but still needs Hermes' normal agent loop: tool calls, follow-up iterations, interrupts, transcript persistence, and the same session context as any other message.

「複数モデルの視点が効きそうな難しいタスクに使ってね、でも Hermes の通常 agent loop（tool 呼び出しやセッション継続）はそのまま維持されるよ」という案内です。

図にすると次のようなフローになります。

ポイントとしては、最終的に tool を呼び出すのが aggregator 側だけというところです。reference 側にも tool state は渡されていて、tool 文脈を踏まえた意見を返してから aggregator がそれらを束ねて tool を呼ぶ、という流れになります。これが後ほど tool calling を試したときの latency に効いてきます。

HermesBench での主張値

冒頭で触れた数値の根拠について、公式 docs にはこんな表が出ています。HermesBench は Nous 社内ベンチマークで、leaderboard 自体はまだ公開されていません。

絶対値で +0.0595、Opus 4.8 単体比で +7.82%、GPT-5.5 単体比で +10.66% です。公式 X が発信した「8% higher than Opus 4.8 and 11% higher than GPT 5.5」と整合しているので、この 3 数字が一旦の依拠点になります。

この辺り leaderboard が公開されればもっと詳細な評価軸が見えてくるはずですね。

環境構築・前提

検証中の Hermes Agent のバージョンは v0.17.0 (2026.6.19) · upstream 88b3d863 です。

hermes --version
# Hermes Agent v0.17.0 (2026.6.19) · upstream 88b3d863

hermes moa list

一つ気をつけておきたいのが、リリースされた v0.17.0 の tag と公式 docs の間に約 1 週間ぶんのギャップがあることです。hermes update --check を叩くと「1003 commits behind origin/main」と返ってきて、MoA の本体機能（hermes moa サブコマンドや moa://local の billing 経路）は tag 後の commits でまとめて入ったことが分かります。docs は最新 origin/main 同期で書かれているため、tag 直後にインストールした状態だと「docs 通りやっても動かない」という現象が起きます。

hermes update --check
# ⚕ Update available: 1003 commits behind origin/main.

hermes update --yes --backup
# git pull + 依存再ビルド + skill 同期 + config v29→v30 migrate

hermes update は内部で git pull origin main を回すので、これを通せば docs 通りの挙動になります。hermes --version の表示文字列は次の tag bump まで v0.17.0 のままですが、upstream <commit-hash> の部分が main 最新と同期しているかを確認すれば OK です。

default preset で動かしてみる

まずは公式 docs と同じ default preset で動作を確認します。hermes moa list で内容を見ると、こんな構成になっています。

* default
  Reference models:
    1. openai-codex:gpt-5.5
    2. openrouter:deepseek/deepseek-v4-pro
  Aggregator: openrouter:anthropic/claude-opus-4.8

公式 docs に載っている YAML 例と一致していて、「設定例」と書かれているものは実機 default の中身と同様でした。Active in config: (off) の表示は、hermes moa configure で carve-out するまで ~/.hermes/config.yaml に moa: セクションが書き込まれない、という意味のようです。

呼び出しは hermes -z PROMPT --provider moa --model default で oneshot 実行できます。これを軽い質問（80 字以内で MoA を要約）と軽い推論（リンゴ 3 個・ミカン 4 個の公平な分け方）の 2 プロンプト × 4 構成で叩いて、subprocess の wall-clock と hermes sessions export の usage を compare.py でまとめました。

数字を眺めて気づいたことが 3 つあります。

1 つ目、latency が単体比でおよそ 6 倍に伸びていること。「MoA という概念を 80 字で要約してください」みたいな軽い質問でも、moa-default は 40.60 秒かかっています。Opus 単体が 6.84 秒、GPT-5.5 単体が 11.94 秒だったので、wall-clock では N+1 倍 call が直撃する設計だと体感できました。reasoning 寄りの問いだと逆に 9.26 秒で返ってきたケースもあり、reference の応答長次第で振れ幅は大きいです。

2 つ目、input_tokens が一貫して 41K 前後で張り付いていること。reference 2 モデルの意見が aggregator の context に注入される設計なので、input がこの規模に膨らむのは公式仕様どおりです。opus-4.8-single の input が 2 token しかカウントされていないのは、openrouter provider を直叩きするときに agent loop の context が乗らない経路だからで、比較対象としては極端な値です。それを差し引いても、moa 経由は通常の hermes-default（24K）と比べてさらに 1.7 倍くらい大きい input を毎回飲み込んでいる計算になります。

3 つ目、cost_status: unknown で返ってくること。Hermes 側からは MoA の実コストが見えないということです。billing_provider: moa / billing_base_url: moa://local という独自スキーマで内部処理されていて、actual_cost_usd も estimated_cost_usd も null で返ってきます。「いくら使ったか」を後追いするには別経路が必要になります。

応答品質の方は MoA と GPT-5.5 単体で差が出ました。reasoning 寄りの問いに対して MoA は「リンゴはまず 2 個を 1 個ずつ配り、残り 1 個を半分に切って 1/2 個ずつ。ミカンは 4 個を 2 個ずつ配ります。結果、各自リンゴ 1.5 個・ミカン 2 個で公平です。」と手順を丁寧に示してきた一方、GPT-5.5 単体は「リンゴは 1 個ずつ配り、残り 1 個を半分に切る。ミカンは 2 個ずつ。これで公平です」と最短で済ませてきます。どちらが好みかは人によるかもしれません。

custom preset を作って実コストを覗いてみる

先ほど引っかかった「Hermes 側から cost が見えない」という制約を、OpenRouter Management API で外側から押さえに行きます。reference をすべて OpenRouter 経由に揃えてしまえば、/api/v1/credits の total_usage 差分で「検証中に OpenRouter でいくら消費したか」が外側から読めるという算段です。

custom preset は ~/.hermes/config.yaml の末尾に追記して登録します。

moa:
  presets:
    openrouter-only:
      reference_models:
        - provider: openrouter
          model: openai/gpt-5.5
        - provider: openrouter
          model: anthropic/claude-sonnet-4.6
        - provider: openrouter
          model: deepseek/deepseek-v4-pro
      aggregator:
        provider: openrouter
        model: anthropic/claude-opus-4.8
      reference_temperature: 0.6
      aggregator_temperature: 0.4
      max_tokens: 4096
      enabled: true

hermes moa list で openrouter-only が読まれていることを確認したら、検証直前に OpenRouter の credit を snapshot し、hermes -z PROMPT --provider moa --model openrouter-only で 2 プロンプト走らせ、終了後にもう一度 credit を取って差分を出します。

latency は 23〜27 秒で安定。input は default と同じく 41K で揺るがず。reference を 2 個から 3 個に増やしたぶん時間がもう少し延びるかなと思いましたが、思ったほどではありませんでした。

肝心の OpenRouter 側コストはこうなりました。この 4 リクエスト（2 分間）で total_usage の差分が $0.483842。OpenRouter 公式 pricing（Opus 4.8 が $5/M input + $25/M output）を元に Opus 単体 2 リクエスト分を概算すると $0.006 程度なので、残りの $0.478 を MoA openrouter-only の 2 リクエストが消費したことになります。

HermesBench で「+7.82% の品質改善」と主張される一方、OpenRouter の credit メーターを覗くと同じプロンプトを叩くだけでおよそ 80 倍のコストを払っているという計算になります。reference を 3 モデル走らせ、それぞれの意見をすべて aggregator の context に流し込んだうえで Opus 4.8 で合成する、という仕組み上避けられない構造的なコストです。

「+7.82% の品質を 80 倍のコストで買うか」と問われると、ユースケースによって答えはバラバラかなと思います。法務文書のドラフトや重要な意思決定の壁打ちなら払う価値もありそうですが、毎日 100 回叩く chatbot 用途では正直つらい数字です。読者の皆さんが自分のワークロードで「ここなら払える、ここは払えない」の線引きをするための材料として、この 80 倍を頭の片隅に置いておいてもらえれば、と思っています。

tool calling の挙動を確かめる

「MoA でも tool calling がちゃんと動くのか」という気になる点も確認しておきます。code_execution toolset を -t code_execution で指定し、「Python で 17 × 23 を計算して結果だけ返してね」というプロンプトを 4 つの構成で叩きました。

全 config が tool_call_count: 1 で正解の 391 を返してきていて、MoA でも tool calling は問題なく成立しています。注目したいのは MoA の latency で、Opus 単体（6.75 秒）に対して 28〜30 秒と 4 倍以上に伸びています。reference それぞれが tool 文脈を読み込んだうえで意見を返すぶん、応答時間がそのまま wall-clock に乗ってくる形ですね。input_tokens の方も MoA は 18K まで膨らんでいて、Opus 単体の 104 token と比べると 170 倍以上の差です。

api_call_count: 2 という構造自体は単体 Opus と同じで、tool 文脈を踏まえた合議のうえで aggregator 側が tool を呼ぶ流れがそのまま成立していました。

ついでに気づいたのが、tool calling 経路だと MoA の input が 41K から 18K へほぼ半減していることです。-t code_execution で toolset を絞ったぶん、profile のシステムプロンプトや関係ない context が剥がれた結果のようです。

公式 docs ではこのほかに「reference の認証失敗時にエラーが context に注入される」「recursive MoA（aggregator に別の moa preset を指定する）は無限ループ防止で禁止」という仕様が明記されていますが、今回はそこまでの破壊的検証はしませんでした。気になる方は ~/.hermes/config.yaml のバックアップを取ったうえで、ぜひ手元で踏み抜いてみてください。

既存の合議パターンとの比較

ここまでの実機データを踏まえて、複数 LLM を束ねるアプローチを横並びで整理してみました。社内で「結局どれを使えばいいの」と聞かれることも多いので、自分の頭の整理も兼ねた表です。aggregator 系の Hermes MoA だけ、コスト透明性が Hermes 側から見えないのがやや異質ですね。

使い分けの感覚は次のような振り分けが現実的かなと思っています。安く速くまわしたい場面ならルーター系の LLM Router v3、裏側のロジックは任せて賢さだけ欲しいならコーディネーター系の Sakana Fugu、reference の構成から自分でチューニングしてベンチで frontier を超えに行きたいなら aggregator 系の Hermes MoA、複数 provider を agent から横断的に呼びたいなら MCP route 系の OpenRouter MCP、という具合です。

LLM Router v3 や Sakana Fugu の詳しい話は別記事で書いているので、リンク先で深掘りしてみてもらえればと思います。

おわりに

Hermes Agent の MoA を実機で 1 日触ってみて、いくつか確認することができました。

ベンチマーク上では HermesBench で Opus 4.8 単体比 +7.82% / GPT-5.5 単体比 +10.66% という主張がある一方、OpenRouter Management API で測った実コストは Opus 単体比およそ 80 倍。品質改善とコストのトレードオフがかなり極端という、ちょっとピリッとした結果になりました。leaderboard の公開はまだ先のようなので、続編で改めて踏み込めればと思います。

tool calling は MoA でも問題なく成立して、reference が tool 文脈込みで意見を返し、aggregator が tool を呼んで合成するという流れでした。ただ Hermes 内部の billing は cost_status: unknown のままなので、コスト追跡は OpenRouter 側で別途持っておくのが現実解です。今回手を出せなかった Nous Portal credit を hermes proxy 経由で reference に組み込む構成は、続編で試したい候補として残しておきます。

環境面では、公式 docs は最新 origin/main 同期で書かれている一方リリース tag は遅れて打たれる運用になっています。本記事の検証中も Hermes 本体は活発に更新されていたので、手元で再現するときには hermes update --check で最新を確認してから取り掛かるのを強くおすすめします。

Teknium 氏の「open source モデルの組み合わせで Opus 相当を狙いたい」という発信が現実解になれば、80 倍コストが 10 倍くらいまで下がってきて、もっと普段使いしやすくなりそうです。フロンティアモデルへのアクセスが今後さらに絞られる流れが続くなら、aggregator 系の合議パターン全体がもう一段育っていく予感があるので、HermesBench の leaderboard 公開後に改めて検証できればと思っています。

参考リンク

• Mixture of Agents — Hermes Agent docs
• Mixture-of-Agents Enhances Large Language Model Capabilities (arxiv 2024.06)
• Statement on the US government directive to suspend access to Fable 5 and Mythos 5 — Anthropic
• Sakana Fugu (GA) をサブスクリプションプランで試してみた
• PLaMo 3.0 Prime を試してみた
• OpenRouter の MCP Server を試してみた
• NVIDIA LLM Router で LLM の用途別使い分け環境を構築してみた（基礎編）
• NVIDIA LLM Router を自分のペルソナに合わせて再訓練してみた（訓練編）