Claude Code ChannelsとOpenClawを比べてみた

2026年3月、Anthropic が Claude Code に「Channels」という新機能をリリースしました。Telegram や Discord から、ローカルで動いている Claude Code のセッションにメッセージを送れるようになる、というものです。

この話を聞いたとき、真っ先に頭に浮かんだのは OpenClaw でした。OpenClaw は 2025 年末からチャットプラットフォーム経由で AI を操作する体験を提供していて、WhatsApp・Telegram・Discord・Slack をはじめ 20 以上のプラットフォームに対応しています。Claude Code Channels は、ある意味でこの流れに追いついた形です。

この記事では、両者のアーキテクチャと設計思想を比較して、それぞれどんな場面に向いているのかを整理してみます。Claude Code Channels の公式ドキュメントはこちらです。
https://code.claude.com/docs/en/channels

そもそも何が違うのか

一言でまとめると、Claude Code Channels は「開発ツールへのイベント注入口」、**OpenClaw は「チャットネイティブな AI アシスタント基盤」**です。

Claude Code Channels は、すでにターミナルで動いている Claude Code セッションに対して、外からメッセージを押し込む仕組みです。CI の失敗通知を受け取ったり、外出先から Telegram でコードの質問を投げたりできます。あくまで Claude Code という開発ツールの拡張であり、セッションが閉じればチャネルも止まります。

一方の OpenClaw は、Gateway と呼ばれる常駐プロセスが中心にあり、複数のチャットプラットフォームと複数の AI エージェントを仲介します。開発ツールではなく、「いつでもどこでも応答する個人 AI アシスタント」を実現するための基盤です。

以下の図で全体像を比べてみます。

この図を見るだけでも、両者のスケール感の違いが伝わるかと思います。

通信モデル

Claude Code Channels では、チャネルは MCP サーバーとして実装されます。Claude Code が起動時にこのサーバーを子プロセスとして生成し、stdin/stdout で通信します。

# Telegramチャネルを有効にして起動
claude --channels plugin:telegram@claude-plugins-official

チャネルサーバー側は claude/channel という capability を宣言し、notifications/claude/channel というイベントを発行することで、Claude Code のセッションにメッセージを届けます。

// チャネルサーバーの核心部分（公式ドキュメントより）
const mcp = new Server(
  { name: 'webhook', version: '0.0.1' },
  {
    capabilities: {
      experimental: { 'claude/channel': {} }
    },
    instructions: 'Events arrive as <channel source="webhook">...',
  },
)

仕組みとしてはシンプルで、MCP の知識があればすぐに理解できます。ただし、セッションが閉じるとチャネルも停止するため、24 時間動かしたい場合はバックグラウンドプロセスとして走らせる必要があります。

OpenClaw の場合は、Gateway が常駐のデーモンプロセスとして動き続けます。

# Gatewayを起動（systemd/launchdでデーモン化も可能）
openclaw gateway --port 18789 --verbose

Gateway は各プラットフォームの API に常時接続し、メッセージの受信・ルーティング・送信をすべて管理します。システム再起動後も自動的に復帰できるように設計されています。

チャネル対応の幅

対応プラットフォームの差は現時点でかなり大きいです。

	Claude Code Channels	OpenClaw
公式対応	Telegram, Discord	Telegram, WhatsApp, Discord, Slack, Signal, iMessage, Google Chat, IRC, LINE
プラグインで拡張	MCP Server を自作可能	MS Teams, Matrix, Feishu, Mattermost, Nostr, Twitch など 20+
デモ用	fakechat（localhost）	WebChat（ブラウザ UI）

Claude Code Channels は Research Preview の段階で、現在は Anthropic が管理するホワイトリストに載ったプラグインしか --channels で有効にできません。自作チャネルをテストするには --dangerously-load-development-channels フラグが必要です。

OpenClaw は MIT ライセンスのオープンソースで、プラグイン SDK を使えば新しいチャネルを比較的自由に追加できます。各チャネルプラグインは config・security・outbound・actions といったアダプターを実装する形になっており、機能の粒度が細かいです。

ルーティングとマルチエージェント

設計思想の違いが最も顕著に出るのがここです。

Claude Code Channels にはルーティングの概念がありません。メッセージは、今開いているセッションにそのまま届きます。1 セッション = 1 チャネルの入口、というシンプルな構造です。

OpenClaw は、1 つの Gateway で複数のエージェントを運用でき、受信メッセージをルールに基づいて振り分けます。

// OpenClawのルーティング設定例
{
  "bindings": [
    {
      "match": { "channel": "slack", "teamId": "T123" },
      "agentId": "support"
    },
    {
      "match": { "channel": "telegram",
                 "peer": { "kind": "group", "id": "-100123" } },
      "agentId": "dev-assistant"
    }
  ]
}

たとえば「Slack の特定チームからのメッセージはサポート用エージェントに」「Telegram の特定グループは開発アシスタントに」といった振り分けが可能です。ルーティングの優先順位は 8 段階あり、厳密な peer マッチから channel 単位のワイルドカードまで対応しています。

個人で使う分には Claude Code Channels のシンプルさで十分ですが、複数のユースケースを 1 つの基盤で管理したい場合は OpenClaw の方がはるかに柔軟です。

メッセージ操作の幅

Claude Code Channels で Claude が外部に対してできることは、基本的にテキストの返信です。チャネルサーバーが reply ツールを公開していれば、Claude はそれを呼んで返信を送ります。

// Claude Code: reply toolの定義（公式ドキュメントより）
tools: [{
  name: 'reply',
  inputSchema: {
    type: 'object',
    properties: {
      chat_id: { type: 'string' },
      text: { type: 'string' },
    },
    required: ['chat_id', 'text'],
  },
}]

OpenClaw はチャネルごとに豊富なアクションが定義されています。Discord の例を見てみると、send に加えて react・poll・edit・delete・pin・search・thread-create・sticker など、プラットフォームの機能をかなり網羅しています。

つまり、Claude Code Channels は「外からの問い合わせに答える」ことに特化していて、OpenClaw は「チャットプラットフォーム上で自然に振る舞う」ことを目指している、という違いがあります。

権限承認の仕組み

AI に実行権限を与える際のフローも異なります。

Claude Code では、ファイル編集やコマンド実行の前に権限の承認が必要です。Channels 経由で作業していると、この承認プロンプトがターミナルに出たまま止まってしまう問題がありました。v2.1.81（3 月 21 日）で「permission relay」が導入され、チャネルサーバーが permission capability を宣言していれば、承認プロンプトをチャット側に転送できるようになりました。ただし、まだ導入されたばかりの機能です。

OpenClaw の Telegram 拡張には、より成熟した exec-approvals システムがあります。エージェントがコマンドを実行しようとすると、Telegram のインラインボタン（Allow Once / Allow Always / Deny）でその場で承認・拒否できます。

// OpenClaw: Telegram exec-approvals設定例
{
  "channels": {
    "telegram": {
      "accounts": {
        "default": {
          "execApprovals": {
            "enabled": true,
            "approvers": ["123456789"],
            "agentFilter": ["dev-assistant"],
            "target": "dm"
          }
        }
      }
    }
  }
}

エージェント単位やセッション単位でフィルタリングできるなど、運用に必要な細かい制御が揃っています。

セキュリティの観点

両者ともセキュリティには配慮していますが、アプローチが異なります。

Claude Code Channels は、sender allowlist とペアリングコードによる認証、組織レベルの channelsEnabled 設定、Research Preview 期間中のプラグインホワイトリストといった多層的な制御があります。閉じたエコシステムであることが、ある意味でセキュリティ上の利点になっています。

OpenClaw はオープンソースゆえの課題もあります。2026 年初頭に RCE 脆弱性（CVE-2026-25253）が発見され、インターネット上に 13 万以上のインスタンスが露出していたことが報告されました。また、コミュニティが共有するスキルの約 12% に悪意のあるコードが含まれていたという調査結果もあります。自由度が高い分、セルフホスティング環境のセキュリティは自分で担保する必要があります。

どちらを選ぶか

判断の軸をざっくり整理すると、こうなります。

Claude Code Channels が向いているケース：

• すでに Claude Code を日常的に使っている
• CI/CD の失敗通知やモニタリングイベントをセッションに流したい
• チーム環境で企業レベルのアクセス管理が必要
• セットアップに時間をかけたくない

OpenClaw が向いているケース：

• WhatsApp や iMessage など、幅広いプラットフォームで AI を使いたい
• 複数のエージェントを用途別に運用したい
• 24 時間 365 日、常時応答する基盤がほしい
• 自前のインフラで完結させたい

もちろん、排他的な選択ではありません。Claude Code Channels でコーディング作業を効率化しつつ、OpenClaw で日常のコミュニケーション用アシスタントを動かす、という併用も十分ありえます。

まとめ

Claude Code Channels は「開発者が手元のセッションをもっと便利に使うための窓口」、OpenClaw は「チャットプラットフォームを通じて AI と暮らすためのインフラ」。同じ「チャネル」という言葉を使っていますが、解決しようとしている問題のスケールがかなり違います。
両方とも急速に進化しています。半年後にはまた景色が変わっていそうですが、今の時点でのスナップショットとして参考になれば幸いです。