Hermes モデルの選び方：2026 OpenRouter で 70B・405B・旧版 Hermes を使い分ける実用ガイド

結論から：新規プロジェクトは 70B、重要タスクで 405B

「パラメータが大きいほど良い」という発想を、次の3層に置き換えてください。ベンチマークより、プロダクトのコストに直結します。

• デフォルトモデル：nousresearch/hermes-4-70b — 多くの新規プロジェクトはここから始め、パイプラインを通しつつ費用を抑える。
• 昇格モデル：nousresearch/hermes-4-405b — 複雑な推論、コードレビュー、長いチェーンの計画など、品質が単価より優先される場面で切り替え。
• 互換モデル：旧版 Hermes の slug — 古いプロンプト、出力スタイル、履歴プロジェクトの回帰テストのためだけに残す。

呼び出し回数が多いほど、1回の回答品質のわずかな差より、コストと遅延の影響が大きくなります。405B は高価値な少数リクエスト向けであり、すべてのトラフィックのデフォルトではありません。

まず現行 slug を確認：記憶で書かない

OpenRouter 上の Hermes slug は、モデルの追加・削除・プロバイダー変更に伴い変わります。古いチュートリアルの slug は、廃止・改名・地域で利用不可になっていることがあります。統合やリリースのたびに、OpenRouter のモデル一覧で Hermes を検索し、詳細ページから slug をコピーして次を確認してください。

• 入出力単価とコンテキスト長
• ツール呼び出し、JSON モード、reasoning などのパラメータ対応
• プロバイダーの稼働状況と、自分のアカウント残高で呼び出せるか

本文で触れる slug は執筆時点の一般的な表記です。公開当日は OpenRouter のモデルページを正とし、本記事の価格やコンテキスト上限を本番設定にハードコードしないでください。

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "nousresearch/hermes-4-70b",
    "messages": [{"role": "user", "content": "一文で自己紹介してください。"}]
  }'

Hermes 4 70B がデフォルトに向く場面

nousresearch/hermes-4-70b はコストが読みやすい日常の主力として位置づけられます。次のような用途で model の初期値に適しています。

• プロトタイプの汎用チャットや文章ドラフト
• 軽いコード補完、スクリプト書き換え、ドキュメント整形
• 要約・分類・タグ抽出など、高頻度かつ低単価のバッチ処理
• OpenRouter + Hermes の初回統合とプロンプト試行

70B は多くの場合、405B よりレイテンシとトークン単価で有利です。1日に数百〜数千回呼び出すアプリでは、最初から 405B にするより 70B デフォルトの方が持続しやすいことが多いです。

Hermes 4 405B が品質優先の場面で向く理由

nousresearch/hermes-4-405b は失敗コストが高く、リトライが痛いリクエスト向けです。明示的に 405B を指定するか、70B 失敗後の昇格先として使います。

• 多段推論、因果分析、複雑な意思決定ツリー
• 長いチェーンの計画（マルチターンのエージェント・ツール呼び出し、タスク分解）
• 大規模コードベースのレビュー、リファクタ提案、ファイル横断の依存分析
• 70B が連続で失敗したあと、人の確認に回す前の最終試行

405B は「すべてに勝つ」モデルではありません。「難しいタスクで1回少なくリトライできれば元が取れる」モデルです。単純で頻度の高い処理を 405B デフォルトにすると、請求と P95 レイテンシの両方が悪化しがちです。

旧版 Hermes を残す価値があるとき

旧版 Hermes（Hermes 3 系や、長年使ってきた slug）は、2026 年の新規開発のデフォルトには通常向きません。次のような場合に限り、一時的に残します。

• 旧モデル向けに長く調整したシステムプロンプトがあり、Hermes 4 だと口調や形式がずれる
• 回帰テストが過去ログと行単位で一致することを要求する
• 下流パーサーが旧フォーマット（句読点、リスト階層、ツール呼び出しの言い回し）に依存している

OpenRouter は旧版 Hermes の恒久提供を保証しません。古い slug に依存しているなら、並行して移行を進めてください。同じプロンプトセットを Hermes 4 70B で回し、出力を比較してから model を段階的に切り替えるのが現実的です。

タスク複雑度で振り分ける：簡単な Q&A から難しい判断まで

単純な Q&A、構造化抽出、コード生成、複雑な意思決定は、同じ model を使う必要はありません。アプリ層でタスク種別やリトライ回数に応じて振り分け、slug を1つに固定しない方が運用しやすいです。

コストと遅延で振り分ける：70B デフォルト、失敗時に 405B へ

モデル選定はプロダクト全体のコストに効くべきで、1回の回答が賢く聞こえるかだけを基準にしないでください。実務で使いやすい構成は次のとおりです。

• デフォルト層：未分類リクエストはすべて 70B。トークン数・レイテンシ・エラー率をログに残す。
• 昇格層：JSON パース失敗、ツール呼び出し形式の崩れ、業務ルール拒否が起きたら、同じプロンプトを 405B で再試行（回数上限を設け、コスト暴走を防ぐ）。
• 人の確認層：405B でもダメなら人に回すか UX を劣化させる。さらに大きいモデルを積み上げない。

OpenRouter の利用状況ページではモデル別の支出が見えます。405B の割合が突出しているなら、デフォルトが大きすぎるか、昇格条件が緩すぎる可能性があります。

reasoning・JSON・ツール呼び出しが選定に与える影響

次の3機能は、どの model を選ぶか、どのリクエストフィールドを送るかを変えます（現行の OpenRouter モデルドキュメントで要確認）。

• Reasoning：モデルページに拡張思考・reasoning 対応があれば、難しい推論で 405B が正当化されやすい。単純タスクで reasoning を常時オンにすると、遅延と出力トークンが増え、得が薄いことも多い。
• JSON / 構造化出力：判断基準はパラメータ規模ではなくパース成功率。多くの抽出ジョブは 70B で足りる。深いネストを持つスキーマだけ 405B をデフォルトに検討する。
• ツール呼び出し：エージェントチェーンでは、ツール名と引数 JSON の安定性が重要。70B がツール呼び出しを壊し続けるなら、405B へ昇格するか、ツールスキーマを絞る方が、システムプロンプトを延々伸ばすより効くことが多い。

統合前に、対象 slug が response_format、tools、reasoning などをサポートするかモデルページで確認してください。同名でもプロバイダーによって挙動が異なることがあります。

5つのテストプロンプトで最終判断する

同じプロンプトセットを 70B と 405B（必要なら旧版 Hermes も）で実行し、正答率・端到端レイテンシ・1回あたりコスト・JSON パース成功率の4指標を記録してください。次の5カテゴリをカバーします。

1. 事実確認 Q&A：検証可能な閉じた質問——ハルシネーション率を見る。
2. JSON 出力：厳格なスキーマ——JSON.parse 成功率を測る。
3. コード：バグや仕様を渡し、1ショットで実行可能か確認する。
4. 推論：多段ロジック——中間ステップの矛盾をチェックする。
5. 長コンテキスト：実運用に近い長さの文書を貼り、重要事実の欠落を見る。

例：JSON とコードのプロンプトで 70B がすでに約95% 許容できていれば、デフォルト model を 405B に上げる必要はありません。推論系だけ 70B で落ち続け、405B で明確に改善するなら、そのタスク種別だけ 405B にルーティングしてください。

推奨ルーティング：70B デフォルト、405B 昇格、非 Hermes をフォールバック

設定やコードでは、次のような構成が扱いやすいです（フィールド名は SDK により異なります）。

# アプリ層ルーティングの例 — 公開前に OpenRouter で slug を再確認
DEFAULT_MODEL = "nousresearch/hermes-4-70b"
UPGRADE_MODEL = "nousresearch/hermes-4-405b"
LEGACY_MODEL  = "nousresearch/hermes-3-llama-3.1-70b"  # 互換のみ。履歴に合わせて調整
FALLBACK_MODEL = "anthropic/claude-sonnet-4"           # 非 Hermes フォールバックの例

def pick_model(task_type, retry_count=0):
    if task_type == "legacy_regression":
        return LEGACY_MODEL
    if task_type in ("complex_reasoning", "code_review") or retry_count >= 1:
        return UPGRADE_MODEL
    return DEFAULT_MODEL

フォールバックは Hermes である必要はありません。レート制限、提供停止、タスク不適合のときは、Claude・GPT など別 API に切り替えた方が安定することが多いです。OpenRouter 全体のマルチモデル振り分けは、OpenClaw + OpenRouter 汎用選定マトリクスも参照してください。

Hermes を使わない方がよいとき

Hermes はオープンウェイト、スタイル調整、コスト管理に向きますが、すべてのジョブのデフォルトではありません。

• 厳格なコンプライアンスと監査：ベンダー SLA やデータ取扱条項が明確な商用 API を優先する。
• マルチモーダル重視：モデルページに画像・音声・動画対応がなければ、Hermes でできると決めつけない。
• 超長文＋超低ハルシネーション：Hermes 4 405B でも基準に届かないなら、プロンプトを無限に伸ばすより Gemini や Claude など長コンテキスト向けモデルを試す。
• アカウント・地域制限：OpenRouter 上の Hermes はすべてのアカウント・残高状態で呼べるとは限らない。403 や model unavailable なら、すぐフォールバックへ。

デフォルトモデルはプロダクト判断です。誰に届けるか、1日何リクエストか、失敗のコストはいくらか——model フィールドは一度決めたら忘れる定数ではなく、観測・変更できる設定として扱ってください。

Hermes 統合とエージェント検証は Mac mini 上が扱いやすい

70B / 405B の選定そのものは OpenRouter 上のクラウド呼び出しで行いますが、統合スクリプト、小規模受け入れテスト、エージェント用ゲートウェイは安定したホストが必要です。macOS なら curl、Python SDK、JSON 検証、ログ分析が追加設定なしで使えます。OpenRouter API キーは Keychain に置くのが自然で、launchd なら上記5カテゴリのプロンプトを定期回帰として回せます。

Mac mini M4 はアイドル時およそ 4W・ファンレスで、専用 API 検証マシンとして向いています。日常使いの Mac と切り離し、70B と 405B のレイテンシ・請求を並列比較できます。Apple Silicon のユニファイドメモリは、ゲートウェイ・ログ集約・ローカル補助ツールを同居させるときにも有利です。本記事のデフォルト＋昇格ルーティングを組み立てるなら、Mac mini M4 は 2026 年時点でコスト効率のよい統合・エージェント用ホストです。信頼できるハードの上で model 選定を反復しやすくなります。今すぐ Mac mini を手に入れ、このワークフローを本番に近い形で試してみてください。