---
title: "常駐型AIエージェント基盤という選択肢｜コーディングエージェントとはレイヤーが違う"
excerpt: "サーバーに常駐し、20以上のチャットチャネルから指示を受け、定期実行もこなすOSSエージェント基盤を調査しました。価値は「運用の配管」が標準で揃っていること。監視・収集・定例配信のような高頻度タスクほど、ローカルモデル併用でコスト差が出ます。使い分けの判断軸をまとめています。"
author: "AI活編集部"
author_username: ai-katsu-editorial
published_at: 2026-06-05T00:00:00+00:00
verified_at: 2026-06-05T00:00:00+00:00
models: ["Claude Code"]
tools: ["MCP", "Browser Use"]
tasks: ["AIエージェント", "ツール検証"]
canonical_url: https://ai-katsu.jp/articles/hermes-agent
---
# 常駐型AIエージェント基盤という選択肢｜コーディングエージェントとはレイヤーが違う

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つのインターフェースが状態を共有する

この設計が特徴的です。

**同一のエージェントコア・同一の設定/セッション/スキル/メモリを、複数のフロントエンドから操作します。**

1.  **CLI / TUI** — ターミナルUI本体
2.  **Web Dashboard** — 設定/セッション/ログ/cronをGUI管理（**完全ローカル実行**）
3.  **Desktop App** — チャット中心のネイティブGUI
4.  **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エージェント導入を支援しています。ご相談は[お問い合わせフォーム](/contact)から、継続的な伴走支援については[AI参謀](/ai-sanbo)をご覧ください。