やぎちゃん、OpenClaw 化ロードマップ

By mattn February 12, 2026
足りないあれやこれや

OpenClaw 化ロードマップ

yagi-discord-bot を OpenClaw のような自律エージェントに改造するための計画。

現状の強み

  • yagi engine によるツールループ（tool call → 実行 → 再入力の自動繰り返し）
  • yaegi によるプラグイン機構（.go ファイルでツール追加可能）
  • MCP（Model Context Protocol）対応
  • セッション管理（ユーザーごとの会話履歴の永続化）
  • メモリ（key-value 形式の学習情報）
  • コーディング系ツール一式（run_command, read_file, edit_file, search_files, glob 等）
  • コンテキスト圧縮（長い会話の自動要約）

足りないもの

Phase 1: 安全性と基盤（最優先）

1. サンドボックス実行

  • 現状: run_command がホスト上で直接実行される
  • 課題: Discord 経由で不特定多数が使う場合、任意コマンド実行は危険
  • 対策: Docker コンテナ内でコマンド実行する仕組み
    • ユーザーごとに隔離されたコンテナ
    • ファイルシステムのマウント制御
    • ネットワークアクセスの制限
    • タイムアウトとリソース制限

2. 構造化プロンプト

  • 現状: IDENTITY.md 一本のみ
  • 課題: 人格・制約・ツール規約が混在しがち
  • 対策: OpenClaw 方式の分離
    • SOUL.md — 人格・トーン（どう話すか）
    • AGENTS.md — 制約・ルール（何をしてよいか）
    • TOOLS.md — ツール利用規約（どうツールを使うか）
    • 動的コンテキスト組み立て（ターンごとに合成）

3. Human-in-the-Loop ゲート強化

  • 現状: ToolApprover インターフェースはあるが Discord bot 側では未使用
  • 課題: 危険な操作（削除、外部通信、支払い等）が無承認で実行される
  • 対策: Discord 上でリアクションやボタンで承認/拒否する UI

Phase 2: 自律性（次に欲しい）

4. Heartbeat / Cron 機構

  • 現状: ユーザーのメッセージがないと動かない
  • 課題: 定期監視・自律タスク実行ができない
  • 対策:
    • Cron 式スケジューラ（0 9 * * * で毎朝9時に実行等）
    • セッションに対してメッセージを注入する仕組み
    • 実行結果を Discord チャンネルに通知

5. Webhook / 外部トリガー

  • 現状: Discord メッセージのみがトリガー
  • 課題: GitHub イベント、メール着信等でエージェントを起動できない
  • 対策:
    • HTTP エンドポイント（/webhook/:id）
    • イベントをセッションメッセージに変換
    • GitHub, Gmail 等のアダプタ

6. ブラウザ自動化

  • 現状: fetch_url と web_search のみ（HTML 取得まで）
  • 課題: JS レンダリングが必要なページ、フォーム操作、スクリーンショット等ができない
  • 対策:
    • Playwright / chromedp ベースのツール追加
    • ページ操作（クリック、入力、スクロール）
    • スクリーンショット取得

Phase 3: 記憶と制御（拡張）

7. セマンティックメモリ

  • 現状: key-value 形式のみ（saveMemoryEntry / getMemoryEntry）
  • 課題: 過去の会話から文脈的に関連する情報を想起できない
  • 対策:
    • Embedding ベースのベクトルストア
    • 会話ログの自動インデックス
    • 類似度検索による関連記憶の動的注入

8. WebSocket 制御 API

  • 現状: Discord 専用、外部制御手段なし
  • 課題: Web UI やモバイルアプリから制御できない
  • 対策:
    • WebSocket サーバー（:18789 等）
    • セッション一覧・メッセージ送受信・設定変更の API
    • Web UI フロントエンド

9. マルチチャネル対応

  • 現状: Discord アダプタのみ
  • 課題: Telegram, Slack, WhatsApp 等に対応できない
  • 対策:
    • チャネルアダプタの抽象化（共通メッセージ形式）
    • アダプタごとのパッケージ分離
    • セッションのチャネル横断統合

Phase 4: マルチエージェント（将来）

10. セッション間連携

  • 現状: ユーザーごとに独立したセッション
  • 課題: エージェント同士が協調できない
  • 対策:
    • sessions_list — アクティブセッション一覧
    • sessions_send — 他セッションへメッセージ送信
    • sessions_spawn — 新セッションの生成（タスク委譲）
    • sessions_history — 他セッションの履歴参照

11. Skill Registry

  • 現状: ローカルの skills/ ディレクトリのみ
  • 課題: スキルの発見・共有・自動インストールができない
  • 対策:
    • スキルレジストリ（ClawHub 相当）
    • SKILL.md フォーマットの標準化
    • エージェント自身がスキルを検索・インストールするツール

実装の優先順位

Phase 1 (安全性・基盤)     Phase 2 (自律性)    Phase 3 (記憶・制御)    Phase 4 (マルチ)
┌─────────────────────┐  ┌──────────────────┐  ┌──────────────────┐  ┌──────────────────┐
│ 1. サンドボックス   │→│ 4. Heartbeat     │→│ 7. セマンティック│→│ 10. セッション   │
│ 2. 構造化プロンプト │  │ 5. Webhook       │  │    メモリ        │  │     間連携       │
│ 3. 承認 UI          │  │ 6. ブラウザ自動化│  │ 8. WebSocket API │  │ 11. Skill        │
│                     │  │                  │  │ 9. マルチチャネル│  │     Registry     │
└─────────────────────┘  └──────────────────┘  └──────────────────┘  └──────────────────┘
No comments yet.