はじめに

はじめまして。今回が、初めての技術ブログですが、書いているうちに書くことも増え、3部作としてまとまりつつあります。今回は第一部となります。

普段は社内で、AIに関する技術検証やサービス開発に取り組んでいます。
AIをめぐる技術の変化は速く、動向を追うだけでなく、実際に環境を構築して確かめることも大切だと感じています。

今回紹介する環境も、最初から完成図を描き、その通りに構築したものではありません。出発点は、NVIDIA DGX Spark上に、一体のHermes Agentを準備したことでした。

まずはローカルLLMを使ったAgent環境を動かしてみる。そこから、Hermes Agentとの対話を重ねながら、推論モデルを更新し、異なるモデルを追加し、やがて複数のAgentが議論する構成へと発展していきました。

この連載では、LLMへ状態、Tool、Policy、実行制御を加える層を Harness、複数のAgent Harnessを一段上から束ねる層を Meta-Harness としました。

LLM
└─ 推論を担う

Hermes Agent / Harness
└─ 推論、Tool実行、観測のループを回す

Omnigent / Meta-Harness
└─ 複数AgentのSession、役割、受け渡し、統合を扱う

ただし、ユーザーが見るUIから最奥のLLMまでの間に、Harnessが一層だけ存在するとは限りません。実際のAgentシステムでは、UI、アプリケーション、Meta-Harness、Agent Harness、推論Runtimeが重なることがあります。

この多層性は、Policy、交換可能性、障害分離をもたらします。一方、各層でSession準備、入力検査、Dispatch、応答回収、出力検査、記録が行われれば、その時間は最終応答へ積み上がります。

Harnessが多いほど安全になるとは限らない。責任境界が見えないHarnessは、遅延と複雑さを増やします。

1. Hermes Agentとは何か

Hermes Agentは、LLMへ質問を送るだけのチャット画面ではありません。目的に応じてToolを選び、結果を受け取り、次の判断へつなげるAgent Harnessです。

当初は、Ollama上のQwen3.6-27Bを利用する一体のHermes Agentから始めました。Agentは手順や変更案を提示し、人間が内容を確認して実行します。構築を支援するAgentと対話しながら、そのAgent自身が利用する環境を変えていく点が、従来の手順書とは異なりました。

図. HermesAgentのCLI

Hermes Agentへ、Qwen3.8-27bを使えるようにしたいと相談しました。Agentは既存のOllama環境を前提に、モデル導入、接続先変更、起動確認に必要な作業を整理しました。

今回試した範囲では、Qwen3.8-27bの最終回答の品質には手応えがありました。一方、最終回答へ至るまでのReasoningに時間を要する場面もありました。

ここで注意したいのは、ユーザーが感じる遅延をモデルだけに帰属できないことです。

総応答時間
= UI・通信
+ Session準備
+ AgentへのDispatch
+ LLMのReasoning  <---- 一要素に過ぎない。
+ Tool実行
+ 応答回収
+ Moderator統合
+ Policy評価
+ Trace・Memory処理
+ UIへの返却

Qwen3.8のReasoning時間は一要素です。回答が生成済みでも、Harnessが回収、統合、検査、表示を終えていなければ、ユーザーにはまだ処理中に見えます。

したがって、正確には「Qwen3.8が遅い」ではなく、最終回答までの経路のどこが時間を使っているかをEnd-to-Endで観測する必要があると考えました。

その上で、軽い確認や反論まで同じ深さのReasoningを使う必要があるのか、Hermes Agentへ相談しました。これが二体目のAgentを用意するきっかけになりました。

Qwen3.8-27bを軽量モデルへ全面的に置き換えるのではなく、深い分析と素早い別視点を分担させることにしました。

Gemma側には、llama.cpp上の gemma-4-26B-A4B-it-MXFP4_MOE を利用しました。26BクラスのMixture of Expertsモデルを、指示応答向け・MXFP4量子化の形で使う構成です。

二つの推論プロセスとモデル設定は分けますが、DGX SparkのGPUと統合メモリは共有します。完全隔離ではなく、管理と切り分けをしやすくするための「制御しやすい分離」です。

二体を用意しただけでは、回答が二つ並ぶだけです。そこで、Meta-HarnessであるOmnigentを使いました。

OmnigentはAgentをSessionとして扱い、Moderatorが各Sessionへ依頼を送り、結果を回収し、別Sessionへ渡して統合します。

当時確認したDebate例はGPTとClaudeを使う構成でしたが、Omnigentへ先に接続していたQwen3.8へ「ローカルの二体のHermesを議論させたい」と相談し、調整案を作ってもらいました。

独立したSessionを維持したまま、Moderatorがメッセージを仲介することが、討議の実体です。これにより、Omnigentに最初から専用Debateとして用意されていなかったローカルモデルも、Hermes Agentとして討議フローへ参加できました。

以下は、Omnigent上で、「この環境についてqwenとgeminiで相談してわかりやすく説明してください。」とするとそれぞれの意見が出力され、相違点や、まとめが最終的に出力されます。

図. OmnigentのGUI

現在の仕組みは、モデルが自律的に重みを書き換えるRSI(再帰的自己改善)ではありません。
そのため、「育成可能」よりも 検証・改善可能なAI × Harness と表現する方が、現在の到達点に合います。

Agentが自分で賢くなる基盤ではなく、Agentの働き方を検証し、改善を積み重ねられる基盤。

一体のHermes Agentから始まり、モデル更新、役割分担、二体目の追加、Sessionベースの討議へ進みました。

Agentと対話しながら、Agentが働くためのHarnessを組み上げる。

次に、二体のHermesへRikAI2との接続を相談すると、MCPでTool化する案が生まれました。第2部では、その接続を扱います。

【第2部】知性に新しい能力をつなぐ
動いていたREST API接続を、RikAI2-MCP Toolへ広げる
リンク