AIエージェントというと、IDEの中でコードを書く補助ツールを思い浮かべます。しかし別の系統があります。自分のサーバーに常駐し、複数のチャットチャネルから指示を受け、定期実行もこなすタイプです。
この調査では、そうしたOSSエージェント基盤を公開ドキュメントから精読し、既存のコーディングエージェントとの位置づけの違いを整理しました。
この調査の概要
調査日 | 2026年6月5日 |
|---|---|
対象 | Hermes Agent（Nous Research）v0.15.2／MITライセンス |
方法 | 公開ドキュメント全文（約61,000行）を取得・精読する机上調査（実インストールは未実施） |
本体費用 | 0円（OSS）。かかるのは接続したLLMのAPI課金のみ |
判定 | 条件付きで導入可（★4.0/5・机上調査時点） |
本記事は公開ドキュメントに基づく調査記録です。実機での精度・安定性・運用負荷は未実測のため、公称値ベースの記載を含みます。
結論：レイヤーが違う
この調査で最も重要な整理です。
Hermesは「コーディングエージェント」ではなく「サーバー常駐の汎用業務エージェント基盤」です。
設計思想で割り切ると、こう整理できます。
ツール | 正体 |
|---|---|
Hermes | 運用フレームワーク（常駐型・汎用業務エージェント基盤） |
Claude Code / Codex | コーディングエージェント本体 |
エッジ系のAgents SDK | エージェントを「作る」土台（サーバーレス前提） |
同じ「AIエージェント」でも、比較すべき軸が違います。コーディング品質で比べても意味がありません。
4つのインターフェースが状態を共有する
この設計が特徴的です。
同一のエージェントコア・同一の設定/セッション/スキル/メモリを、複数のフロントエンドから操作します。
- CLI / TUI — ターミナルUI本体
- Web Dashboard — 設定/セッション/ログ/cronをGUI管理（完全ローカル実行）
- Desktop App — チャット中心のネイティブGUI
- Messaging Gateway — 20以上のチャネルに単一プロセスで接続
CLIで開始してDesktopで再開する、といった相互レジュームが可能です。作業の続きを別の場所から拾えます。
「運用の配管」が標準で揃っている
この基盤の本質的な価値はここにあります。
機能 | Hermes | コーディングエージェント |
|---|---|---|
常駐のしやすさ | ◎ コマンド一つでOS常駐 | △ 自前で常駐ループ実装 |
スケジューリング（cron） | ◎ 標準装備（自然言語cron） | ✕ 自作 |
メッセージング連携 | ◎ 20以上のチャネル標準 | ✕ 自作 |
永続メモリ/スキル | ◎ 標準装備 | ◎ あり |
セルフホスト | ◎ | × |
コーディング品質/IDE統合 | ○（汎用） | ◎ |
「配管をほぼ書かなくていい」——これが差になります。定期実行、チャネル接続、通知配信、記憶の保持を自前で実装すると、それだけで相応の工数がかかります。
ロックインを避けられる構造
もう1つの特徴です。
LLMはOpenAI互換APIなら何でも接続可能。各社のクラウドAPIから、ローカル実行のモデルまで選べます。
これが効くのは、コスト面です。
ローカルモデルを使えばランニングコストをゼロ化できます。監視や収集のような「軽いが高頻度」なタスクほど、この差が積み上がります。
誠実な但し書き
調査中に見つかった、注目すべき記述があります。
提供元は自社モデルについて「チャット/推論向けでツールコールのループには不向き」と公式に明言しています（エージェント用途には非推奨）。
エージェント基盤とモデルを分離して考える設計思想が明確に示されています。自社製品を無条件に推さない姿勢は、判断材料として信頼できます。
主な機能
- 永続メモリ＆スキル — メモリ＝事実、スキル＝手順。類似タスク時に自動想起。オープン標準互換
- スケジュール自動化 — 自然言語またはcron式で定期実行。結果を任意のチャネルへ配信
- サブエージェント委譲 — 独立コンテキスト・制限付きツールセットを持つ子エージェントを生成（既定3並列）
- サンドボックス — local / docker / ssh 等から選択。コンテナはread-onlyルートFS・全capability drop等でハードニング
- MCP接続 — 任意のMCPサーバーをstdio/HTTPで接続し、既存の社内ツールをハブ化できる
- チェックポイント/ロールバック — ファイル変更前に自動スナップショット
スキルの「progressive disclosure」によるトークン節約や、プロンプトキャッシュが常時ONで設定不要といった細部も作り込まれています。
使い分けの判断軸
この調査が示す結論は明快です。
監視・収集・定例配信などの運用反復タスク → 常駐型エージェントに任せる（ローカル/安価モデルでコスト最小）
コードを書く・難しい判断の実装タスク → コーディングエージェント（必要に応じてフロンティアモデル）
判断の根拠も整理されています。
- コーディングエージェントのSDKで書く場合：常駐・スケジューラ・チャネル接続・通知配信・記憶DBを自分で実装する必要がある。加えてLLMのAPI従量課金が必ず発生する
- 常駐型が効く理由：配管が設定だけで揃う／ローカルモデルでコストをゼロ化できる／マルチユーザー共有と権限分離が標準／モデル差し替えでロックインしない
- コーディングエージェントが勝つ場面：タスクの中身が「コードを書く・直す・PRを出す」で、推論品質が成果を左右する用途
「高頻度で軽いタスク」ほど、API従量課金が積み上がります。ここがコスト構造の分かれ目です。
懸念点
- コーディング特化のIDE統合は専用ツールに一日の長がある
- OSS常駐＝サーバー・セキュリティ・アップデート管理は自己責任
- 実機での精度・安定性・運用負荷は未実測
- ドキュメント上、Windows環境の記述に混在がある
2つ目が実務上の判断ポイントです。本体が無料でも、運用の責任は自分側に来ます。
安全設計の推奨も記録されています。常駐運用では必ず許可リスト/ペアリングを設定し、承認スキップ系のオプションは信頼環境のみで使う。
調査手法の発見
この検証は机上調査ですが、その手法自体に発見がありました。
公式が /llms.txt と /llms-full.txt（全文ダンプ）を公開しており、AIエージェントによる調査が極めて容易でした。SPA相手でも、公開のテキストダンプがあれば全機能を網羅できます。
ここから一般化できるTipsがあります。
任意のサイトを調査する際は、まず /llms.txt・/llms-full.txt・/sitemap.xml・/robots.txt を確認すると、ブラウザ巡回せずに全体像を取得できる場合があります。
AIに読ませる前提のファイルを用意しておくことは、提供する側にとっても調査される機会を増やすことになります。LLMO/AIOの観点でも参考になる実装です。
よくある質問
コーディングエージェントと何が違いますか？
レイヤーが違います。コーディングエージェントは「コードを書く本体」、常駐型エージェント基盤は「運用フレームワーク」です。常駐・cron・チャネル連携・記憶が標準で揃っている点が差になります。
費用はかかりますか？
本体はMITライセンスで0円です。かかるのは接続したLLMのAPI課金のみで、ローカルモデルを使えばゼロ化も可能です。
どんなタスクに向いていますか？
監視・収集・定例配信などの運用反復タスクです。コードを書く・難しい判断が必要な実装タスクは、コーディングエージェントのほうが適しています。
導入時の注意点は？
OSS常駐なので、サーバー・セキュリティ・アップデート管理は自己責任になります。常駐運用では許可リストとペアリングの設定が必須です。
まとめ
- 常駐型エージェント基盤はコーディングエージェントとレイヤーが違う。比較軸を間違えない
- 価値は「運用の配管」が標準で揃っていること——常駐・cron・チャネル連携・記憶
- OpenAI互換APIなら何でも接続可能。ローカルモデルでランニングコストをゼロ化できる
- 提供元が自社モデルを「エージェント用途には非推奨」と明言している。基盤とモデルを分離する思想
- 使い分けは運用反復タスク→常駐型、実装タスク→コーディングエージェント
- 本体無料でも運用責任は自分側。許可リスト設定は必須
- 調査時は
/llms.txt・/sitemap.xml・/robots.txtを先に確認すると全体像が速く取れる
AIエージェントの選定では、何ができるかより「どの層のツールか」を見ると混乱しません。同じ名前でも、担当する範囲がまったく違うことがあります。
株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のAIエージェント導入を支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。