Claude Code Channels 実機テスト：本当に OpenClaw を置き換えられるのか？セットアップ手順と徹底比較

2026 年 3 月、Anthropic が Claude Code Channels をリリースしました。開発者が Telegram や Discord からローカルの Claude Code セッションを直接操作できる機能です。発表と同時にコミュニティは大騒ぎとなり、「OpenClaw 終了」が合言葉になりました。

実際にテストした結論は、現実はそう単純ではないということです。Channels は公式レベルのセキュリティと統合度を提供しますが、「OpenClaw を置き換える」にはまだ超えるべきハードルがいくつもあります。本記事ではセットアップ教程の焼き直しではなく、実機テストと正直な比較で、どちらを使うべきか判断するお手伝いをします。

TL;DR

• Claude Code Channels は MCP プラグインアーキテクチャで Telegram・Discord からローカル Claude Code を操作可能。セットアップ約 15 分
• 3 層セキュリティモデルは OpenClaw より堅牢だが、リモート操作では権限確認のバイパスがほぼ必須。セキュリティと利便性に構造的な矛盾がある
• 「OpenClaw 終了」は感情であって事実ではない。Channels と OpenClaw は補完関係：Channels はセキュリティと公式サポート、OpenClaw はプラットフォームの広さと永続セッションで勝る
• 現在はリサーチプレビュー段階。フィーチャーフラグによるゲートがあり、全員が使えるわけではない

Channels とは？MCP プラグインアーキテクチャを理解する

まず、よくある誤解を解きましょう。Claude Code Channels は別のチャットボットではありません。MCP（Model Context Protocol）に基づくプラグインシステムで、外部イベントを実行中の Claude Code セッションに「プッシュ」する仕組みです。

Claude Code はもともとターミナル入力という「耳」が 1 つだけでした。Channels はそこにトランシーバーを追加するようなものです。Telegram のメッセージがトランシーバー経由で届き、Claude が処理して同じ経路で結果を返します。

技術的には、Channel は MCP server としてローカルでサブプロセスとして動作し、Telegram Bot API を継続的に監視します。メッセージを受信すると Claude Code セッションに直接プッシュし、Claude は処理結果を Telegram に返送します。コードはすべてローカル環境から出ません。

このアーキテクチャの利点は標準化です。MCP 上に構築されているため、将来は誰でも独自の channel プラグインを開発可能です（現在のリサーチプレビュー段階では公式ホワイトリストのプラグインのみ許可）。

15 分でセットアップ完了：Telegram と Claude Code の接続手順

始める前に、フィーチャーフラグのゲートに引っかかっていないか確認してください。Channels は段階的にロールアウト中で、バージョンを更新しても使えないアカウントがあります（詳しくはトラブル対策ガイドを参照）。まずセットアップを試して、bot がまったく応答しない場合はサーバー側のゲートの可能性が高いので、設定のデバッグに時間を費やさないでください。

前提条件：

• Claude Code v2.1.80 以上（claude --version で確認）
• Bun ランタイムがインストール済み（bun --version で確認。未インストールなら curl -fsSL https://bun.sh/install | bash を実行）
• claude.ai アカウントでログイン済み（API キーは非対応。現段階の制限です）

準備ができたら、以下の 7 ステップに従ってください：

Step 1：Telegram Bot を作成 Telegram で @BotFather を開き、/newbot を送信。表示名を選び、bot で終わるユーザー名を設定。BotFather が発行するトークンをコピーします。

Step 2：公式プラグインをインストール Claude Code セッション内で実行：

/plugin install telegram@claude-plugins-official

見つからない場合は、先に /plugin marketplace add anthropics/claude-plugins-official を実行してください。

Step 3：Bot トークンを設定 /telegram:configure を実行し、BotFather のトークンを貼り付けます。~/.claude/channels/telegram/.env に自動保存されます。

Step 4：Channels モードで再起動 現在のセッションを終了し、以下のコマンドで再起動：

claude --channels plugin:telegram@claude-plugins-official

ここが多くの人がつまずくポイントです。プラグインをインストールしただけでは Channels は有効になりません。--channels フラグの明示的な指定が必要です。

Step 5：ペアリング Telegram で bot に DM を送ると、6 桁のペアリングコードが返ってきます。

Step 6：ペアリング完了 Claude Code ターミナルに戻り、/telegram:access pair を実行してペアリングコードを入力。Telegram ID がホワイトリストに追加されます。

Step 7：アクセスをロック /telegram:access policy allowlist を実行し、ホワイトリストのユーザーのみが bot と対話できるようにします。

セットアップ完了です。Telegram から bot にメッセージを送れば、ローカルの Claude Code セッションで直接タスクが実行されます。

注意：Enterprise や Team プランのユーザーは、Channels がデフォルトで無効です。組織管理者が claude.ai Admin 設定から手動で有効化する必要があります。

実戦レビュー：スマホから Claude Code を指揮する本当の体験

セットアップ後の第一印象は確かにワクワクします。Telegram から「テストを実行して」と送ると、約 3〜5 秒でローカルの Claude が動き始めます。Telegram への結果返送までの完全なラウンドトリップはタスクの複雑さ次第で、シンプルなコマンド（テスト実行、ファイル確認）は通常 10〜30 秒、複雑なタスク（プロジェクトのビルド、大量ファイル操作）は数分かかることがあります。MacStories の実機レビューによると、Telegram 経由で iOS プロジェクトのビルド、記事の一括整理、ポッドキャストの文字起こしなど、複雑なタスクもリモートで完了できたとのことです。

ただし、これらはすべて Claude Code のトークンクォータを消費します。長時間の非同期タスクのトークンコストは無視できず、Pro プランのユーザーはレートリミットに注意して、1 つのリモートタスクで 1 日の枠を使い切らないようにしましょう。

ここで重要な認識のギャップがあります：コミュニティは「パソコンを持ち歩く必要がなくなった」と言いますが、実際は「パソコンは起動したままにする必要がある。ただし、その前に座っている必要はない」です。

このギャップはアーキテクチャの制限に起因します。Channels にはメッセージキューがありません。Claude Code セッションが常に起動している必要があり、オフライン中に送信されたメッセージは永久に失われます。

コミュニティが考案した回避策は、tmux と while ループでセッションを永続化する方法です：

tmux new -s claude-channels
while true; do claude --channels plugin:telegram@claude-plugins-official; sleep 5; done

セッションが予期せず中断しても自動で再起動します。外出前に tmux で起動し、スマホから操作、帰宅したら tmux attach -t claude-channels で復帰。完璧な 24 時間対応ではありませんが、「昼間は外出、夜は帰宅」というシナリオには十分です。

もう 1 つの体験上の課題はパーミッションの中断です。Claude がファイル書き込みやコマンド実行など権限確認が必要な操作に遭遇すると、ローカルのターミナルで承認するまでセッションが一時停止します。リモート操作時にはこれが大きな UX の断絶となり、MacStories も最大の課題として指摘しています。

3 層セキュリティモデルの詳細解説（そしてそのアキレス腱）

Channels のセキュリティ設計はアーキテクチャとして堅牢で、3 層構造です：

第 1 層：送信者ホワイトリスト ペアリングフローを完了した Telegram ユーザー（数値ユーザー ID で識別）のみがメッセージを送信可能。未承認のメッセージはエラー通知なしで静かに破棄されます。

第 2 層：セッションごとのオプトイン Claude Code を起動するたびに --channels フラグを明示的に追加する必要があります。これにより、知らないうちにチャネルが外部メッセージを受信することを防ぎます。

第 3 層：プラグインホワイトリスト 現在は Anthropic 公式のホワイトリストに登録されたプラグインのみ受け付けます。独自の channel をロードするには --dangerously-load-development-channels フラグが必要で、名前自体が警告になっています。

この設計は、OpenClaw が批判される「セキュリティレイヤーのバイパス」問題よりはるかに優れています。しかし、構造的な矛盾があります：

リモート操作の核心的な価値は「パソコンの前にいなくても Claude に作業させる」ことです。しかし Claude が権限確認を要求する操作に遭遇するたびに、ターミナルに戻って承認するまでセッションが一時停止します。無人でのリモート操作を実現するには、ほぼ確実に --dangerously-skip-permissions が必要ですが、これは Claude Code のすべての権限確認をバイパスします。

つまり、3 層セキュリティモデルは「誰が Claude にメッセージを送れるか」を保護しますが、「Claude がメッセージを受け取った後に何をするか」は保護できません。skip-permissions モードでは、ホワイトリストを通過したメッセージで Claude がローカル環境で任意の操作を実行できてしまいます。

実践的なアドバイスは状況に応じた使い分けです。監視できる状態なら標準モードで完全なセキュリティ保護を享受し、無人運用なら skip-permissions を使いつつ作業範囲を限定（特定のプロジェクトディレクトリのみで操作するなど）しましょう。二者択一ではなく、タスクのリスクレベルに応じて調整するものと考えてください。

Channels vs OpenClaw vs NanoClaw：どれを選ぶべきか？

コミュニティは一様に「OpenClaw 終了」と宣言しましたが、データは別のことを示しています。以下は 2026 年 3 月時点の実際の違いです（リサーチプレビュー段階のため、今後変更の可能性あり）：

比較項目	Claude Code Channels	OpenClaw	NanoClaw
メンテナー	Anthropic（公式）	コミュニティ（Peter Steinberger）	コミュニティ
対応プラットフォーム	Telegram、Discord	Telegram、Discord、iMessage、WhatsApp、Slack（一部の報道では Signal も対応とされる）	Telegram、Discord、WhatsApp、Slack、Signal
セキュリティモデル	3 層防御 + Enterprise 管理	セキュリティレイヤーのバイパスが批判される	Docker コンテナ分離
セッション永続性	起動したままにする必要あり	24 時間永続セッション	Docker コンテナで永続
セットアップ難易度	中（CLI コマンド）	高（セルフホスト）	中（Docker）
エコシステムの安定性	公式メンテナンス、単一バージョン	断片化（複数のコミュニティフォーク）	軽量で安定

この表からわかるように、Channels と OpenClaw のターゲットユーザーは実は異なります：

• 「たまにスマホから操作したい。セキュリティが重要」 → Channels。公式サポート、3 層セキュリティ、Enterprise 管理。企業ユーザーやセキュリティ重視の開発者に最適です。
• 「24 時間マルチプラットフォーム統合が必要。iMessage や WhatsApp は必須」 → OpenClaw。プラットフォームの広さが最大の利点ですが、セキュリティリスクと断片化したメンテナンスコストを負う必要があります。
• 「サンドボックス分離が欲しい。AI にホストのファイルシステムを触らせたくない」 → NanoClaw。Docker コンテナ分離がユニークな売りですが、Claude Code レベルのコーディングエージェントの深さは欠けます。

1 つだけ選ぶなら、Telegram だけ使うなら：Channels を選びましょう。公式サポート、セキュリティ、シンプルなセットアップ。「たまにリモート操作」のシナリオにはこれで十分です。iMessage/WhatsApp や本当の 24 時間永続セッションが必要な場合にのみ、OpenClaw が必要になります。

両方を維持する意欲があるなら：オフィスでは Channels（安全、公式）、クロスプラットフォームや永続運用が必要なときは OpenClaw に切り替えましょう。

トラブル対策ガイド：既知の制限とトラブルシューティング

Channels は現在リサーチプレビュー段階です。事前に知っておくべき落とし穴を紹介します：

1. フィーチャーフラグのゲート 最も混乱する問題です。v2.1.80 に更新しても、Channels が使えるとは限りません。Anthropic は tengu_harbor というサーバー側のフィーチャーフラグで段階的にロールアウトしています。アカウントがロールアウト範囲外の場合、プラグインはインストールできますがハンドラーが登録されず、bot は一切応答しません。設定の問題ではなく、サーバー側のゲートです。待つしかありません。

2. DISABLE_TELEMETRY の設定トラップ Claude Code の設定で DISABLE_TELEMETRY を設定したことがある場合、0（無効にしない）に設定しても Channels がブロックされます。解決策はキーを 0 にするのではなく、完全に削除することです。

3. オフラインメッセージの永久損失 メッセージキューがないため、セッションが閉じている間に送信されたすべてのメッセージが失われます。tmux で緩和できますが、根本的な解決ではありません。

4. 音声メッセージ非対応 画像（50MB 以内）やファイルは送信可能ですが、音声メッセージは非対応です。また、Telegram はデフォルトで画像を圧縮するため、元の画質が必要な場合（デバッグのスクリーンショットなど）は「ファイルとして送信」を使ってください。

5. メッセージ履歴なし Telegram Bot API はメッセージ履歴や検索機能を提供しません。bot はリアルタイムで届いたメッセージのみ確認できます。

6. リサーチプレビューの不安定性 --channels フラグの構文やプロトコルコントラクトは今後のバージョンで変更される可能性があります。この段階で Channels を重要な本番ワークフローに組み込むのは推奨しません。

導入のアドバイス：フィーチャーフラグのゲートに引っかかっていないことが確認できたら（bot が正常に応答する場合）、個人プロジェクトや重要度の低いタスクでの利用は十分合理的です。bot が応答しない場合は、設定のデバッグに時間を費やさないでください。サーバー側のゲートである可能性が高いです。

まとめ

Channels はリモート操作の需要に対する Anthropic の本気の回答であり、セキュリティと公式メンテナンスは現在の OpenClaw エコシステムにはない強みです。しかし「OpenClaw 終了」の結論は時期尚早で、プラットフォームの広さとセッション永続性のギャップは確かに存在します。

具体的なアクション：15 分かけてセットアップを試してみましょう。フィーチャーフラグのゲートに引っかかっていなければ、おめでとうございます。公式リモート操作を楽しんでください。ゲートに引っかかったら、当面は OpenClaw を使い、Anthropic のロールアウトを待ちましょう。

いずれにしても、まだ OpenClaw は削除しないでおきましょう。