一、冒頭：Chatbot が Agent になるとき

あなたが AI アシスタントにこう言ったとしよう。

「東京の来週の天気予報を調べて、結果を Obsidian のノートに保存し、同僚にメールで知らせて。」

伝統的な Chatbot ならこう答える。「分かりました。天気サイトを調べ、Obsidian の手動機能でメモし、メールクライアントで送ることをおすすめします。」——それは言うことしかできず、やることはできない。

だがこれが AI Agent なら、こう動く。

1. ブラウザで天気サイトを開く → 東京の来週の天気を取得
2. ファイルツールで Obsidian vault に Markdown ノートを作成
3. メールクライアントを呼び出して要約メールを送信

そのあいだ、あなたはキーボードに触る必要がない。

これが AI Agent と Chatbot の根本的な違いだ。Chatbot は問いに答え、Agent はタスクを実行する。それはもはや言語モデルだけではない——ツールを呼び、環境を操作し、自ら判断するデジタル従業員だ。

では、AI Agent の内部はいったいどう動いているのか。言語モデルを「話せる」から「仕事ができる」に変える仕組みは何か。

本稿では Hermes Agent（完全オープンソースの本番級 AI Agent フレームワーク）を解剖サンプルとして、Agent の中核原理を一歩ずつ分解する。Hermes は Nous Research が開発し、20+ のモデル提供者に対応、CLI / Telegram / Discord / Feishu など 20+ プラットフォームで動き、永続化記憶と自己進化スキルシステムを持つ——AI Agent のアーキテクチャを理解するのにこれ以上ない題材だ。

▲ Hermes Agent 完全システムアーキテクチャ：接続層 → コア層 → 能力層 → モデル層、四層分離設計

二、Agent コアループ：Think → Act → Observe

2.1 ReAct パラダイム

現代の AI Agent はすべて、一つの基底パラダイムの上に立つ。ReAct（Reasoning + Acting） だ。

2023年、Shinn と Yao らは画期的な論文 ReAct: Synergizing Reasoning and Acting in Language Models を発表し、こう問うた。なぜ LLM の推論（Reasoning）と行動（Acting）を分けずに、結びつけないのか。

ReAct の中核ループはきわめて簡潔だ。

Observe（環境／ユーザー入力を観察）
  → Think（推論し、次に何をするか決める）
  → Act（ツールを呼び出して行動する）
  → Observe（ツールが返した結果を観察）
  → Think（新しい情報に基づいて推論）
  → Act（行動を続けるか、最終回答を出す）
  → ...

このループは、Agent がタスク完了と判断するまで続く（つまりもうツールを呼ばず、テキスト返答を直接出す）。

2.2 Hermes の主ループ：run_conversation()

Hermes Agent では、このループの実装は agent/conversation_loop.py にあり、中核関数 run_conversation() は約 3900 行で、Agent の心臓部だ。

簡略化した疑似コード：

def run_conversation(agent, user_message, conversation_history):
    # 1. システムプロンプトを構築／復元（キャッシュされ、セッション内で一度だけ）
    active_system_prompt = restore_or_build_system_prompt(agent)
    
    # 2. メッセージリストを準備（system + history + 現在のユーザーメッセージ）
    messages = build_messages(active_system_prompt, conversation_history, user_message)
    
    # 3. 主ループ
    while api_call_count < max_iterations and iteration_budget.remaining > 0:
        
        # 3a. LLM を呼ぶ
        response = call_llm(messages, tools=agent.tool_definitions)
        
        # 3b. ツール呼び出しがあるか確認
        if response.has_tool_calls():
            for tool_call in response.tool_calls:
                # ツール呼び出しを振り分け
                result = handle_function_call(
                    name=tool_call.function.name,
                    args=tool_call.function.arguments
                )
                # 結果をメッセージリストに追記
                messages.append({"role": "tool", 
                                  "content": result, 
                                  "tool_call_id": tool_call.id})
            # ループを続け、LLM にツール結果を見せて次を決めさせる
            continue
        
        # 3c. ツール呼び出しなし → 最終返答を出し、ループ終了
        if response.has_text():
            final_response = response.text
            break
    
    return {"final_response": final_response, "messages": messages}

2.3 一回の Turn の完全なライフサイクル

ユーザーがメッセージを送ると、Agent 内部は次の段階を経る。

2.4 反復バジェット制御

Agent はツール呼び出しループを無限に回せない。Hermes には二層の保護がある。

• max_iterations（デフォルト 90 回）：絶対上限。超えたら強制終了
• iteration_budget：より細粒度の予算制御。各反復で一単位を消費し、尽きたら “grace call”（最後の一回）をトリガーしてから退出

ループが尽きると、Agent はユーザーに知らせるプロンプトを出す。

▲ 一回の Turn の完全ライフサイクル：Prologue → LLM 呼び出し → 判断ループ → 結果出力。橙色の破線枠内が中核の ReAct ループ。

三、ツールシステム：Agent の両手

ツールのない LLM は作文しかできない。ツールがあって初めて世界を操作できる。ツールシステムは Agent アーキテクチャでもっとも重要なエンジニアリング部品の一つだ。

3.1 ツール宣言と登録

Hermes では、各ツールは独立した Python ファイルで、registry.register() によりモジュール級で自己登録する。

# tools/example_tool.py
from tools.registry import registry

def my_tool(param: str) -> str:
    return json.dumps({"result": f"処理しました: {param}"})

registry.register(
    name="my_tool",
    toolset="example",
    schema={
        "name": "my_tool",
        "description": "これはサンプルツールです",
        "parameters": {
            "type": "object",
            "properties": {
                "param": {"type": "string", "description": "入力パラメータ"}
            },
            "required": ["param"]
        }
    },
    handler=lambda args, **kw: my_tool(param=args.get("param", "")),
    check_fn=lambda: True,  # 環境チェック。満たさなければ表示しない
    requires_env=["EXAMPLE_API_KEY"],  # 必要な環境変数
)

この設計の見どころ：登録は宣言的で、中央リストに手でツールを足す必要がない。

tools/registry.py の discover_builtin_tools() は tools/ 配下のすべての .py を走査し、AST 静的解析（import 実行ではない！）でトップレベルの registry.register() 呼び出しがあるかを判定し、それから本当に import する。

def discover_builtin_tools(tools_dir=None):
    for path in sorted(tools_path.glob("*.py")):
        source = path.read_text()
        tree = ast.parse(source)
        if any(is_registry_register_call(stmt) for stmt in tree.body):
            importlib.import_module(f"tools.{path.stem}")

💡 つまり新しいツールはファイル一つ + registry.register() 一行で足り、フレームワークが自動発見・読み込みする。

3.2 ToolEntry データ構造

登録後のツールは ToolEntry オブジェクトに包まれる。

class ToolEntry:
    __slots__ = (
        "name",          # ツール名。LLM はこの名前で呼ぶ
        "toolset",       # 所属ツールセット（例：web, terminal, file）
        "schema",        # OpenAI Function Calling 形式の JSON Schema
        "handler",       # 実際に実行する関数
        "check_fn",      # 可用性チェック関数
        "requires_env",  # 必要な環境変数リスト
        "is_async",      # 非同期かどうか
        "description",   # 人間可読の説明
        "emoji",         # 表示用 emoji
    )

この構造体は三か所で使われる。

1. tool_definitions の生成 → LLM API に tool schema として渡す
2. 実行の振り分け → handle_function_call() が handler を探して呼ぶ
3. UI 表示 → hermes tools list が利用可能ツールを表示

3.3 ツール振り分けフロー

LLM が tool_calls を返すと、model_tools.py の handle_function_call() が振り分ける。

LLM が返す: {function: "web_search", arguments: {query: "東京の天気"}}
     │
     ▼
1. パラメータ型の強制変換 (coerce_tool_args)
   └─ 文字列 "42" → 整数 42（schema 整合）
     │
     ▼
2. Tool Search Bridge チェック
   └─ tool_search / tool_describe ならカタログ照会パスへ
     │
     ▼
3. セキュリティミドルウェア検査
   └─ pre_tool_call hook → 権限検証 → コマンド承認
     │
     ▼
4. handler を呼ぶ
   └─ 実際の関数を実行 → JSON 文字列を返す
     │
     ▼
5. 結果の長さ制限 (max_result_size_chars)
   └─ 過長な結果がコンテキストを膨らませるのを防ぐ
     │
     ▼
6. post_tool_call hook
   └─ 監査ログ、性能追跡

3.4 Toolset グループ管理

Hermes のツールは機能ごとに toolsets に分かれ、設定でオン／オフできる。

各ツールセット内のツールは、条件を満たすときだけ LLM に公開される。check_fn で実現する。

# OPENROUTER_API_KEY が設定されているときだけ web_search が見える
def check_requirements() -> bool:
    return bool(os.getenv("OPENROUTER_API_KEY"))

3.5 他フレームワークとの比較

大半の Agent フレームワークのツールシステムは OpenAI Function Calling 形式の schema に従う。差は次にある。

• Hermes：ツールは Python 関数 + 宣言的登録。ゼロ設定で自動発見。各ツールの可視性を独立に制御できる
• Claude Code：ツールはバイナリにハードコード。ユーザーはカスタムできない
• Codex：Rust バイナリ。ツールは sandbox 権限システムで制御。MCP プラグインで拡張
• OpenClaw：プラグインシステムでツールを拡張

四、システムプロンプト工学：Agent の魂

システムプロンプト（System Prompt）は Agent の脳のオペレーティングシステムだ。LLM に、あなたは誰か、どんなツールが使えるか、利用可能な資源は何か、守るべき規則は何かを伝える。

4.1 三層アーキテクチャ

Hermes の build_system_prompt_parts()（agent/system_prompt.py）は、システムプロンプトを三層に分ける。

┌─────────────────────────────────────────────┐
│              Volatile（可変層）                │
│  - 記憶スナップショット（現セッションの最新記憶）   │
│  - ユーザープロファイル情報                      │
│  - タイムスタンプ（現在の日時）                   │
├─────────────────────────────────────────────┤
│              Context（コンテキスト層）            │
│  - AGENTS.md / .cursorrules プロジェクト文脈     │
│  - 呼び出し側が足したシステムメッセージ             │
├─────────────────────────────────────────────┤
│              Stable（安定層）                   │
│  - Agent 身元（SOUL.md またはデフォルト身元）      │
│  - ツール使用ガイド                             │
│  - Skills 索引（現在読み込まれたスキル）           │
│  - 環境ヒント（OS、ターミナル種別、プラットフォーム）  │
│  - モデル族の操作ガイド                          │
│  - タスク完了ガイド                             │
│  - 並列ツール呼び出しガイド                       │
└─────────────────────────────────────────────┘

4.2 プロンプトキャッシュ最適化

この三層構造の設計には一つの中核目標がある——プレフィックスキャッシュのヒット率を最大化すること。

現代の LLM API（Anthropic、OpenAI など）は Prompt Caching に対応する。コンテキスト先頭が前回リクエストと同じなら、キャッシュヒットで遅延とコストを 50–90% 節約できる。

Hermes の戦略は次だ。

• システムプロンプトはセッション寿命のあいだ一度だけ構築し、agent._cached_system_prompt にキャッシュする
• 途中でシステムプロンプトのどの部分も再構築・変更しない（キャッシュヒットの前提）
• キャッシュ無効化を起こす唯一の事象はコンテキスト圧縮（Context Compression）——圧縮後は新しい記憶状態を反映するためプロンプトを再構築する必要がある

def build_system_prompt(agent):
    """セッション開始時または圧縮後にのみ呼ぶ"""
    parts = build_system_prompt_parts(agent)
    return "\n\n".join([parts["stable"], parts["context"], parts["volatile"]])

def invalidate_system_prompt(agent):
    """圧縮後に呼び、次回の再構築を強制する"""
    agent._cached_system_prompt = None
    agent._memory_store.load_from_disk()

4.3 セグメント注入の条件論理

どのツールが存在するかに応じて、システムプロンプトの内容は変わる。

if "memory" in agent.valid_tool_names:
    tool_guidance.append(MEMORY_GUIDANCE)    # 記憶ツールの正しい使い方
if "session_search" in agent.valid_tool_names:
    tool_guidance.append(SESSION_SEARCH_GUIDANCE)  # 履歴セッションの検索方法
if "skill_manage" in agent.valid_tool_names:
    tool_guidance.append(SKILLS_GUIDANCE)    # スキル管理の方法

こうして現在利用可能なツールに関するガイドだけを読み込み、冗長テキストがコンテキスト窓を食うのを避ける。

五、記憶システム：セッションをまたぐ持続性

普通の Chatbot は毎回の対話で「記憶喪失」だ——窓を閉じればすべてゼロになる。Agent はあなたの好み、プロジェクト構造、過去の失敗と蓄積した経験を覚える必要がある。

5.1 記憶アーキテクチャ

Hermes の記憶システムは二系統制だ。

記憶ストア (SQLite / Honcho / Mem0 / ...)
├── memory（ツールノート）
│   └── 環境の細部、ツール使用のコツ、プロジェクトの取り決め
│   └── 例：「ユーザーは pytest でテストし、-n 4 並列が習慣」
│
└── user（ユーザープロファイル）
    └── 氏名、役割、好み、スタイル
    └── 例：「ユーザーは開発者、SwiftUI を好み、中国語でやり取り」

5.2 記憶の読み書きタイミング

記憶は毎回書き換えられるわけではなく、戦略的に管理される。

• 読み取り：新しいセッション開始時、記憶ストアが format_for_system_prompt() で現在の記憶をテキスト化し、システムプロンプトの Volatile 層へ注入する
• 書き込み：memory ツールがトリガーする。Agent が有用な情報（ユーザー好み、環境の細部、訂正内容）を見つけたら、自ら memory(action='add') を呼んで保存する
• 更新：情報が古くなったりユーザーが訂正したら、memory(action='replace') または memory(action='remove') で更新する

5.3 バックエンド差し替え可能

Hermes は複数の記憶バックエンドに対応する。

この差し替え可能な設計により、記憶システムは「単純なキー値ストア」から「関係グラフ + 意味検索」まで拡張できる。

六、スキルシステム：Agent の自己進化

記憶が Agent の「短期 RAM」なら、スキルはその「長期プログラムライブラリ」だ。ここが Hermes と他の Agent フレームワークのもっとも中核的な違いの一つである。

6.1 Skill とは何か

Skill は一つの SKILL.md ファイルで、YAML フロントマター + Markdown 本文の構造を持つ。

---
name: systematic-debugging
description: 4段階の根本原因デバッグ手法
tags: [debugging, python, workflow]
version: 1.2.0
---

# 系統的デバッグ

## トリガー条件
Bug の根本原因分析が必要なとき：

## 手順
1. **再現** — …
2. **隔離** — …
3. **根本原因** — …
4. **修復** — …

各 Skill は次を含む。

• メタデータ：名称、説明、タグ、バージョン
• 本文：Markdown 形式の完全なワークフロー
• 参照資源（任意）：スクリプト、テンプレート、参考資料

6.2 Skills の読み込み機構

読み込みフロー：

1. Hermes がツール一覧で skill_manage を発見 → システムプロンプトに Skills 使用ガイドを追加
2. 初期スキャン：skills_list が利用可能な全 Skill を検査 → <available_skills> ブロックとしてシステムプロンプトへ注入
3. タスクに基づく照合：Agent がユーザーの問いに応じてどの Skill を読むか判断
4. 能動読み込み：ユーザーも /skill <name> で手動読み込みできる

6.3 Skills と記憶の違い

6.4 自己改善ループ

これが Hermes のもっとも面白い特性だ——Agent は仕事の中で自己改善できる。

タスクを完了する
  → この流れに再利用価値があることに気づく
  → skill_manage(action='create') を呼んで Skill として保存
  → 次に似たタスクで自動読み込み
  → 問題や手順の更新を見つける → skill_manage(action='patch') で更新

七、タスク委譲とマルチ Agent 協働

すべてのタスクを主 Agent が自らやる必要はない。並列処理に向くものも、独立した環境が要るものもある。

7.1 delegate_task() の原理

Hermes の delegate_task ツールは、完全に隔離された子 Agent を作れる。

主 Agent（現在のセッション）
  │
  ├── タスク A → delegate_task()
  │   └── 子 Agent（独立セッション + 独立 terminal + 独立コンテキスト）
  │       ├── Research サブタスク
  │       └── 要約レポートを返す
  │
  ├── タスク B → delegate_task()
  │   └── 別の子 Agent
  │       ├── コードレビューサブタスク
  │       └── レビュー結果を返す
  │
  └── 二つの子 Agent の結果を集約し、ユーザーへ出力

子 Agent の特徴：

• 独立セッション：独自のメッセージ履歴とコンテキストを持つ
• 独立 terminal：独自の Shell 環境を持つ
• 限定ツールセット：デフォルトでは主 Agent のツールを継承
• 記憶アクセスなし：永続化記憶はなく、必要な情報は毎回 context 経由で渡す
• さらなる委譲不可：葉ノードは子を spawn できない

7.2 使用場面

7.3 マルチ Agent モードの比較

• Hermes：delegate_task による軽量委譲。短時間のサブタスク向き
• Claude Code：子エージェント対応だが、Hermes の委譲 API ほど構造化されたインタフェースはない
• Codex：Multi-Agent v2（2026年6月）。各サブスレッドに独立ランタイム
• OpenClaw：Gateway がネイティブにマルチ Agent を支え、各 Agent に独自 workspace、session、auth

八、コンテキスト管理

LLM にはコンテキスト窓の制限がある——最新の GPT-5.5 が 1M token 窓を持っていても、長時間走る Agent は天井に触れる。コンテキスト管理は Agent 工学で必ず解くべき問題だ。

8.1 能動圧縮

Hermes の圧縮方針は能動的だ——溢れてから動くのではなく、事前に検出する。

毎回の LLM 呼び出し後：
  token 使用量を検査 → 残窓を見積もる
  ├─ 閾値未満 → 何もしない
  └─ 閾値超過 → 圧縮をトリガー
       ├─ 現在の対話履歴を保存
       ├─ compress_conversation() を実行
       │  ├─ ツール呼び出し結果を精選（重要情報を残し、完全出力を落とす）
       │  ├─ 連続する non-tool ターンを統合
       │  └─ 対話の骨格を保持
       ├─ システムプロンプトを再構築（_invalidate_system_prompt をトリガー）
       └─ 「[Context compressed]」をユーザーに通知

8.2 受動復旧

API が 413 Payload Too Large やコンテキスト溢れエラーを返したとき：

1. Hermes はまず圧縮が有効か確認する（compression.enabled）
2. 有効なら → 履歴を自動圧縮して再試行
3. 無効なら → エラーを出し、ユーザーに手動 /compress または /new を促す

8.3 圧縮 vs 切り捨て

この違い：圧縮はメッセージリスト先頭からの単純切り捨てではない。切り捨ては初期の重要な判断情報を失う。Hermes は要約 + 骨格モードを採る。

圧縮前：
  [ユーザー] 「FastAPI のユーザー管理モジュールを書いて」
  [助手] → tool_call: terminal("fastapi new ...")
  [ツール] 返す: 完全出力 2000 行...
  [助手] → tool_call: write_file(...) → 返す: 成功
  [助手] 「完了しました。API エンドポイントは次のとおり...」
  [ユーザー] 「rate limiting を足して」
  ...

圧縮後：
  [ユーザー] 「FastAPI のユーザー管理モジュールを書いて」
  [助手] → tool_call: terminal("fastapi new ...")
  [ツール] 返す: [圧縮済み — コマンド成功、所要 3.2s]
  [助手] → tool_call: write_file(...) → 返す: 成功
  [助手] 「完了しました。API エンドポイントは次のとおり...」
  [ユーザー] 「rate limiting を足して」
  ...

ツール結果の長い出力は要約タグに置き換えられるが、対話フローと重要な判断は残る。

九、マルチプラットフォームゲートウェイ

Agent は端末の中だけに生きる必要はない。Hermes の Gateway アーキテクチャにより、複数プラットフォームで同時に動ける。

9.1 Core + Adapter アーキテクチャ

                        ┌──────────────┐
                        │  Agent Core  │
                        │  (LLM + ツール) │
                        └──────┬───────┘
                               │
                        ┌──────┴───────┐
                        │   Gateway    │
                        │   Router     │
                        └──────┬───────┘
                               │
          ┌────────────────────┼────────────────────┐
          │                    │                    │
   ┌──────┴──────┐    ┌───────┴───────┐    ┌───────┴──────┐
   │  Telegram   │    │   Discord     │    │   Feishu     │
   │  Adapter    │    │   Adapter     │    │   Adapter    │
   └─────────────┘    └───────────────┘    └──────────────┘
          │                    │                    │
   Telegram API          Discord API           Feishu API

各プラットフォームアダプタの責務：

1. 接続管理：WebSocket / Webhook の長寿命接続
2. メッセージ変換：プラットフォーム固有形式 ↔ 標準メッセージ形式
3. メディア処理：画像、音声、ファイルの変換
4. プラットフォーム特性への適応：Markdown 対応度の差、操作制限

9.2 クロスプラットフォームの課題

一つの Agent コアはアダプタ層ですべての差を処理するが、上層の LLM 呼び出しから見れば、見えるのは統一されたメッセージインタフェースだけだ。

9.3 プラットフォーム対応の広さ

2026年中時点で、Hermes Gateway は 20+ プラットフォームに対応する。Telegram、Discord、Slack、WhatsApp、Signal、Email、SMS、Matrix、Mattermost、Home Assistant、DingTalk、Feishu、WeCom、iMessage、WeChat、API Server、Webhooks など。

これが Hermes を他の Agent フレームワークから際立たせる顕著な強みだ——大半の枠組みは CLI か単一プラットフォームに集中する。

十、主流 AI Agent 横断比較

Agent の動作原理を理解したうえで、2026年主流の四つの Agent フレームワーク——Hermes Agent、Claude Code、OpenAI Codex、OpenClaw——を比較する。

10.1 総覧比較

10.2 深掘り：各社の長短

Hermes Agent — スイスアーミーナイフ

コアの位置づけ：汎用 AI Agent フレームワーク。どのモデルにも縛られず、どのプラットフォームにも配備できる。

強み：

• モデル自由：20+ 提供者に対応。DeepSeek Flash（節約）から Claude Opus 4（高品質）まで、いつでも /model で切替
• 自己進化：Skills システムは唯一無二——Agent が自らワークフローを記録・再利用し、使うほど強くなる
• マルチプラットフォーム：CLI から Telegram、Feishu、メールまで、同一 Agent コアがすべてのプラットフォームで一貫して動く
• 永続化記憶：導入直後から使えるクロスセッション記憶。追加サービス不要
• 自動化：内蔵 Cron 定時タスク + Webhook。データ収集、日報配信などの無人運用ができる
• Profile 隔離：複数の独立設定。仕事と個人環境が干渉しない

弱み：

• コード能力は中程度：位置づけは汎用 Agent で、コーディング場面に特化していない（ただし Claude Code に委譲してコードはできる）
• コミュニティが小さい：OpenAI／Anthropic 製品に比べ、規模とエコシステムはまだ成長中
• サンドボックスが弱い：権限審査は TIRITH 依存で、OS 級の強制サンドボックスはない
• 性能：Python コアは Codex の Rust より重く、高並行ではオーバーヘッドがある

最適場面：個人アシスタント、マルチプラットフォーム自動化、調査分析、知識管理、長期記憶とスキル蓄積が要る場面。

Claude Code — コードの専門家

コアの位置づけ：端末ネイティブのコーディング Agent。Anthropic 製、Claude モデル独占。

強み：

• トップ級コーディング能力：Claude 4 Opus／Sonnet は SWE-bench などで継続的にリード。複雑なリファクタ、大規模コードベース理解に強い
• 安全設計：内蔵のコマンド承認フロー。実行前の各 shell コマンドがユーザーに見える
• Claude エコシステムとの統合：Projects、Artifacts、MCP などが途切れなく繋がる
• 良いワークフロー：git 統合、PR フロー、コードレビュー対応

弱み：

• 厳しい枠制限：Pro ユーザーは重度利用でしばしばレート制限に当たる（コミュニティでは約 20 プロンプト／5時間窓後に制限が出ると報告¹）。大型タスクは計算ずくで——コミュニティ最大の不満点だ
• モデル固定：Claude モデルしか使えず、特定タスクに他モデルを使えない
• 単一プラットフォーム：CLI のみ。Telegram／Discord など多プラットフォーム不可
• 永続記憶なし：セッション間でユーザー好みや履歴を覚えられない
• 自動化スケジューリングなし：Cron／Webhook がなく、定時タスクができない
• クローズドソース：内部挙動をカスタム拡張できない

コミュニティの声：2026年初の枠縮小（約 20 プロンプトで 5h 枠を使い切る）は大量の GitHub Issue 苦情を呼び、「一つの機能を最後まで仕上げるのも難しい」という声が出た。Claude Code は質に強く、利用可能量に弱い。

最適場面：一回の深いコードタスク、複雑なリファクタ、コードレビュー。継続稼働、多プラットフォーム、モデル間の柔軟切替には向かない。

OpenAI Codex — 安全優先のコーディング基盤

コアの位置づけ：OpenAI 公式の端末コーディング Agent。オープンソースの Rust 実装。

強み：

• もっとも厳しいサンドボックス安全：macOS では Apple Seatbelt、Linux では Landlock + seccomp。カーネル級でファイルシステムとシステムコールを制限——すべての Agent 中でもっとも強い安全モデル
• コード能力は頂点級：GPT-5.5（400K コンテキスト）ベース。Terminal-Bench 2.0 SOTA 82.7%
• オープンソース + 大コミュニティ：Apache 2.0、128K+ GitHub Stars（2026-10 時点）、480+ コントリビューター
• 成熟したマルチ Agent：Multi-Agent v2。各サブスレッドが独立ランタイム状態を保つ
• 豊富な特性セット：MCP、プラグイン、Skills、Permissions システム、AGENTS.md プロジェクトガイド
• 頻繁な更新：ほぼ毎日新版（2026年10月時点で v0.162.x）

弱み：

• モデル固定：OpenAI モデル族（GPT-5.x）のみ。他提供者へ切替不可
• Rust コアの高複雑度：Star は多いが Open Issues も多い（執筆時約 8980）。貢献の敷居が高い
• 端末 + デスクトップ App のみ：Telegram／Feishu など多プラットフォーム非対応
• OpenAI 依存：ChatGPT Plus／Pro または API key が必要。利用コストあり
• 一部特性は実験的：Codex Cloud、一部 Sandbox 機能はまだ実験扱い

最適場面：ソフトウェア開発の完全ワークフロー（コーディング、デバッグ、レビュー、PR）、厳しい安全サンドボックスが要る環境、OpenAI エコシステムのユーザー。

OpenClaw — マルチ Agent プラットフォーム

コアの位置づけ：個人 AI アシスタント基盤。Gateway ネイティブのマルチ Agent アーキテクチャ。

強み：

• Gateway ネイティブアーキテクチャ：初日から Gateway-First。Agent は Gateway 経由でメッセージをルーティングし、自然にマルチ Agent ランタイムを支える
• 豊富な Channel 対応：Discord、Feishu、Google Chat、iMessage、Teams、QQ Bot、Signal、Slack、Telegram、WhatsApp など
• 完全なワークスペース管理：各 Agent に独立 workspace、session、auth
• スキルシステム：Skills 対応。Hermes の手順知識再利用に似る
• 現代的な onboarding：対話式セットアップウィザード（openclaw onboard）。UX が良い
• Crestodian 対話型運用：自然言語対話で設定を修復できる

弱み：

• ドキュメントが分散：docs.openclaw.ai と docs2.openclaw.ai の二ドメインで情報が割れる
• コア言語：TypeScript。一部の Python エコシステムユーザーにはやや不向き
• コミュニティ規模は中程度：Nous コミュニティ内の Hermes ほどの活気はない
• サンドボックス安全が弱い：権限ポリシー設定に依存し、OS 級強制サンドボックスなし
• 移行の複雑さ：Hermes からの移行には独立フロー（openclaw onboard --flow import）があるが、学習曲線はある

最適場面：マルチ Agent 協働環境、多プラットフォームで送受信する個人アシスタント、Ops 運用場面。

10.3 選定アドバイス

十一、まとめと今後

11.1 Agent の中核要素

Hermes Agent を解剖して見えた、本番級 AI Agent に必要な部品は次だ。

1. ReAct ループ — Think → Act → Observe の継続反復
2. ツールシステム — LLM を現実世界に繋ぐ自己登録・自己発見の仕組み
3. システムプロンプト工学 — キャッシュ親和の三層アーキテクチャ。安定性と即時性の両立
4. 永続化記憶 — セッションをまたぐ知識の蓄積
5. スキル／手順知識 — Agent の自己進化能力
6. 委譲と協働 — マルチ Agent の並列作業
7. コンテキスト管理 — 有限の窓の中で効率よく働く
8. マルチプラットフォーム適応 — 一つのコア、複数チャネル

11.2 現時点の限界

Agent は実本番で、まだ完全には解けていない問題に直面する。

• ツール実行の信頼性：LLM は形式誤りの tool_calls、幻覚パラメータ、呼ぶべきでないときの呼び出しを起こしうる
• エラー復旧コスト：一度の失敗 API 呼び出し → 再試行 → コンテキスト膨張 → さらに多くの token 消費
• コンテキスト窓は永遠に足りない：1M token でも長時間の自律タスクでは尽きる
• 安全と権限：Agent に自由に操作させつつ、やってはいけないことをさせない——このバランスはまだ完全には解けていない

11.3 潮流と方向

今後 1–2 年、AI Agent の明確な方向は次だ。

• 枠組みからオペレーティングシステムへ：Agent はますます自律 OS に近づく——プロセス（子エージェント）を管理し、資源（コンテキスト／演算能力）をスケジューリングし、状態を永続化する
• マルチ Agent 協働（MoA）：単一のより強い Agent ではなく、複数の専門 Agent がチームのように協働する
• 記憶はインフラになる：「任意機能」から「中核インフラ」へ。Web アプリにおけるデータベースに似る
• Agent-to-Agent 通信：異なる枠組みの Agent が互いに発見し、互いにタスクを委譲する（MCP はこの潮流の第一歩）
• 長期自律タスク：「数分のタスク」から「数日続くプロジェクト」へ——Hermes の Cron + Webhook + Skills はこの方向を指している

本稿の Hermes Agent ソース解析は NousResearch/hermes-agent プロジェクトに基づく。コアループは agent/conversation_loop.py、ツール登録は tools/registry.py、システムプロンプト構築は agent/system_prompt.py。