Claude Code Channelsとは — 常駐セッションにイベントを届ける仕組み

Claude Code Channelsとは

Claude Code Channelsは、開いたままのセッションへ外部のイベントを送り込む研究プレビュー機能です。仕組みの正体は、MCPサーバーを経由したpush(送信)です。CIの結果や監視アラート、Telegramなどのチャットメッセージを、ターミナルの前にいなくてもClaudeへ転送できます。

常駐の条件は1つだけです。イベントが届くのはセッションが開いている間だけなので、常時受け付けたいなら、バックグラウンドプロセスか常駐ターミナルでセッションを開いたままにします。

対応チャットアプリの一覧と個別のセットアップ手順は対応アプリと研究プレビューの制約にまとめました。本記事はChannelsという仕組み自体の動き方と、他の遠隔操作系機能との違いに絞ります。

Channelsはどう動くか

チャネルの正体は、自分のマシンで動くMCPサーバーです。Claude Codeが子プロセスとして起動し、標準入出力(stdio)でやり取りします。TelegramやDiscordのプラグインはBot APIへ新着メッセージを取りに行くので、公開URLを用意する必要はありません。CIや監視向けの自作サーバーは、ローカルのHTTPポートで待ち受けます。

Channelsはclaude.aiまたはConsoleのAPIキーによる認証が前提です。Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundryでは使えません。プラグインとしてインストールし、自分の認証情報(Botトークンなど)で設定します。研究プレビューではTelegram・Discord・iMessageの3つに加え、動作確認用のfakechatが用意されています。プラグインはBunで動くスクリプトで、iMessageはmacOS専用です。

返信そのものはターミナルに表示されません。ターミナルにはツール呼び出しと「送信済み」のような完了確認だけが出て、実際の返信テキストは相手のチャットアプリ側に届きます。ログを追う場所と、会話を追う場所が分かれます。

チャネルを有効にするには、セッション起動時に--channelsフラグでプラグイン名を渡します。

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

.mcp.jsonにサーバーを登録しただけではメッセージは届きません。--channelsで名指ししたプラグインだけがイベントを受け取れます。この2段の指定が、意図しないチャネルからの割り込みを防ぐ最初の防御線です。

このフラグは研究プレビュー中、ヘルプに載りません。Claude Code v2.1.289で次のコマンドを実行しても、出力は空で終了コードは1でした。

claude --help | grep -i channel

フラグが無いわけではなく、一覧に出ていないだけです。--dangerously-load-development-channelsも同じ扱いです。

モデルに届くイベントの形と届き方

Channels経由のメッセージは、地の文ではなく<channel>タグ付きのイベントとしてモデルに渡ります。webhookチャネルの例だと、次の形です。

<channel source="webhook" path="/" method="POST">
build failed on main: https://ci.example.com/run/1234
</channel>

sourceにはサーバー名が入り、metaに渡した各キーが属性になります。キーに使えるのは英数字とアンダースコアだけです。ハイフンを含むキーは、エラーにならず黙って捨てられます。プラグイン経由のチャネルでは、sourceがplugin:fakechat:fakechatのようにプラグイン名とサーバー名を並べた形になります。

ターミナル側には1行の要約が出ます。fakechatなら← fakechat · web: メッセージ内容のように、送信元とテキストが並びます。

届け方には、設計に効く癖が3つあります。

• Claude Codeはイベントを受け取っても応答を返さないので、チャネル側は処理されたかどうかを知れません
• セッションがチャネルとして読み込んでいない場合や、組織のポリシーで止められている場合、イベントはエラーなしで捨てられます
• Claudeが処理中に届いたイベントは順番に溜まり、次のターンでまとめて渡されます

独立したイベントの流れを並行で処理したいときは、セッションを分けます。配送確認が必要なら、チャネル側で状態を持ち、replyツールで報告させる設計が考えられます。

--channelsには複数のプラグインをスペース区切りで渡せます。Telegramで個人の質問を受けつつ、別のサーバーでCIのWebhookも受信する、といった組み合わせが1つのセッションで成立します。

非対話モード(-p)では、選択式の質問やplanモード承認のように端末入力を要するツールが無効化されます。応答待ちでセッションが固まらない設計なので、無人稼働のパイプラインに組み込むときはこの挙動を前提にします。

使えるようになるまでの3段階のゲート

どれか1つでも欠けると、MCPサーバー自体は起動していてもメッセージはセッションに届きません。組織側が未設定でもMCPサーバーへの接続は成功し、ツールも一見動きます。止まるのはチャネル経由のメッセージだけで、起動時の警告が管理者への有効化依頼を促します。

既定値は認証方式で分かれます。claude.aiのTeam・Enterpriseは有効化されるまでブロックです。APIキー認証のConsoleは、managed settingsを配布していなければ既定で許可されます。配布している組織は、channelsEnabledが設定されるまでブロックです。組織側の手順はClaude Code Channels組織管理にまとめています。

管理者はallowedChannelPluginsで、使えるプラグインの一覧を自前のものに差し替えられます。一覧にないプラグインを--channelsに渡すと、Claude Code自体は普通に起動しますが、チャネルは登録されません。起動時の通知に、組織の承認済み一覧にないことが出ます。

自作チャネルを試す--dangerously-load-development-channelsは、許可リストだけを飛ばします。組織のchannelsEnabledは飛ばせません。効くのは指定した項目ごとで、--channelsの項目には及びません。

MCPクライアントの実行環境(v2ランタイム)では、プロトコルのリビジョン2026-07-28を交渉するチャネルサーバーは登録されません。stdioサーバーへMCP_PROTOCOL_NEGOTIATIONをlegacyにすれば、従来のハンドシェイクのままにできます。v2.1.285以降では、フィーチャーフラグを取得するセッションでstdioサーバーにも新リビジョンを問い合わせる設定が、既定で有効になっていく段階です。登録されない原因を探すときの切り分け材料になります。なおlegacyの指定は、特定のサーバーではなく全サーバーを従来のハンドシェイクにします。

誰がメッセージを送れるか — 送信者の許可リスト

承認済みのチャネルプラグインは、それぞれ独自の送信者許可リストを持ちます。TelegramとDiscordはペアリングでリストに登録します。自分のBotへ何かメッセージを送るとペアリングコードが返るので、Claude Codeのセッション側でそのコードを承認すると、送信者IDが加わります。

iMessageだけは方式が違います。自分自身にテキストすると許可チェックを自動でバイパスし、ほかの相手は/imessage:access allowで個別に許可します。

許可の単位は、部屋ではなく送信者のIDです。グループチャットでは両者が別物になり、部屋単位で許可すると、そのグループにいる誰でもセッションへ入力を差し込めてしまいます。

権限確認プロンプトをチャネル経由で承認できる「permission relay」に対応したプラグインでは、この許可リストがプロンプトの承認権限にもなります。対応にはv2.1.234以降のClaude Codeと、サーバー側のclaude/channel/permissionの宣言が要ります。転送先は、--channelsか開発フラグで指名したサーバーだけです。誰が承認できるかを増やす操作でもあるため、許可リストの管理はセキュリティ設計の中核です。

relayの動きは次のとおりです。ターミナルのダイアログは開いたままで、スマホ側にも同じプロンプトが並行して届き、先に返ってきた答えが採用されます。リクエストIDは、lを除く小文字5字です。スマホで打ち間違えにくくするためです。プロジェクトの信頼確認とMCPサーバーの同意ダイアログはrelayされず、ターミナルにだけ出ます。詳しい防御パターンはChannelsセキュリティ設計で扱っています。

他の遠隔操作系機能とどう違うか

Claude Codeには、ターミナルの外から作業に関わる手段がChannels以外にも複数あります。何が「新しいセッションを起動する」のか、何が「今のセッションに割り込む」のかで役割が分かれます。

たとえばデバッグの途中でCIの失敗通知が届けば、Claudeはすでに開いているファイルとやり取りの文脈を保ったまま反応できます。

似た用途に見えるScheduled Tasksとは、pushかpollかが違います。

Channelsが向く作業

ユースケースは大きく2つです。ひとつはチャットブリッジで、外出先からTelegramやDiscord経由でClaudeに質問を送ります。返事は同じチャットに届き、実際の処理は自分のマシン上で実ファイルを見て進みます。もうひとつはWebhook受信で、CIパイプラインやエラー監視サービス、デプロイパイプラインからのWebhookを、Claudeがファイルを開いてデバッグの文脈を覚えているセッションへ届けます。

Remote Controlとの違いは、動かす主体にあります。Remote Controlは自分がスマホから操縦する能動的な手段で、Channelsは何もしなくてもイベント発生時に自動で反応します。CIが落ちたら気づいて直す、という受け身の作業はChannelsの設計に分があります。今どこまで進んだかを見ながら次の指示を出したいなら、Remote Controlのほうが向いています。

いずれの用途でも、Claudeが権限確認プロンプトに当たるとセッションはいったん停止します。permission relay対応のチャネルなら、そのプロンプトをチャットへ転送して遠隔から承認・拒否できます。対応していないチャネルでは、ターミナルに戻るまで停止したままです。無人運用が前提なら--dangerously-skip-permissionsでほとんどのプロンプトを回避できますが、信頼できる環境に限る運用が前提です。

Telegram・Discord・iMessage以外のシステムをChannelsに繋ぎたい場合は、自分でMCPサーバーを書いて独自のチャネルを作れます。必要なのは、claude/channelの宣言、通知の送出、stdio接続の3点です。CIやモニタリングサービスからのWebhookを受け取るサーバーの自作手順はClaude Code ChannelsでWebhook受信サーバーを自作するにまとめています。

まとめ

Channelsは、新しい作業を始める機能ではなく、いま開いているセッションの文脈に外部の出来事を差し込む機能です。スマホからClaude Codeにアクセスする他の経路との比較はClaude Codeをスマホから使う4つの経路の選び方にまとめています。