Hermes Agentのモデル選び｜高性能モデルを常用しない運用設計
朝 8 時の自動処理が、モデル設定の変更を検知して止まりました。高性能なモデルへ切り替えたこと自体は問題ではありません。ジョブが古い設定を前提にしていたため、安全側に倒れたのです。
この出来事は、AI エージェントのモデル選びをよく表しています。大切なのは、最も強いモデルを常用することではありません。仕事ごとに必要な精度を決め、失敗時の逃げ道まで用意することです。
高性能モデルを使う仕事
私は、結果の良し悪しを機械だけで判定しにくい仕事に高性能モデルを使います。
- 日本語の記事をゼロから書く
- 複数の資料を突き合わせて判断する
- リポジトリ全体をまたいで修正する
- 失敗の原因を追い、別の手段で完遂する
- 外部公開や Git への反映まで進める
この種の仕事は、途中の判断を一度誤ると手戻りが増えます。安いモデルで 3 回やり直すより、最初から強いモデルに任せる方が、時間も費用も抑えられる場合があります。
私の環境では、記事作成やコード変更に openai-codex の高性能モデルを割り当てています。モデル名は省略せず、ジョブ側にも明示します。デフォルト値が変わっても、定期処理の挙動が変わらないためです。
軽量モデルで十分な仕事
一方、入力と出力の型が決まっている仕事に大きな推論能力は要りません。
たとえば、100 件の記事を 3 分類する処理があります。判定基準と出力形式が固定されていれば、軽量モデルで先に処理できます。曖昧な記事だけを高性能モデルへ回す方が合理的です。
ほかにも、次の処理は分離しやすい領域です。
- 短い要約
- タグ付け
- 画像の説明
- 会話履歴の圧縮
- 定型レポートの整形
- 監視結果の一次判定
Hermes Agent には、画像認識や圧縮などの補助処理に別モデルを指定する設定があります。通常の会話モデルを変えずに、補助処理だけを速いモデルへ寄せられます。
モデルより先に失敗条件を決める
モデル比較では、回答精度ばかりを見がちです。しかし、自動運用では失敗時の振る舞いが重要です。
確認する項目は 4 つあります。
| 項目 | 確認する内容 |
|---|---|
| 固定 | 定期ジョブがモデルIDを明示しているか |
| 代替 | 主系統が止まったときの別プロバイダーがあるか |
| 上限 | タイムアウトや利用額の境界があるか |
| 検証 | 出力をテストやビルドで判定できるか |
Hermes Agent は複数の推論プロバイダーに対応し、フォールバック先も設定できます。ただし、代替モデルへ切り替われば同じ文章や同じ判断になるとは限りません。公開処理では、モデルの成功ではなく、品質ゲートの成功を完了条件にします。
私が使う二段構成
運用は複雑にしすぎない方が保守しやすいです。今は次の二段で考えています。
主モデルには、執筆、調査、コード修正、公開判断を任せます。ここでは精度とツール操作の安定性を優先します。
補助モデルには、分類、要約、圧縮、監視を任せます。ここでは速度と費用を優先します。
さらに、主モデルが利用できないときだけ別プロバイダーへ逃がします。フォールバック後も、テスト、静的解析、ビルドを省きません。
切り替えは設定ではなく運用の変更
モデルを変えると、文章の癖、ツールの呼び方、慎重さが変わります。設定ファイルの 1 行だけを変えたつもりでも、実際には作業者を交代させています。
そのため、定期ジョブではモデルを明示し、変更後の初回は手動で実行します。出力差を確認してから次の自動実行へ進めます。この一手間で、朝に大量の誤公開が起きる事故を避けられます。
高性能モデルは必要です。ただし、すべての処理に必要ではありません。判断が難しい場所へ能力を集中し、単純な処理は軽くする。この分け方が、AI エージェントを長く運用する土台になります。
参照資料
