Claude Code Channels入門: 初心者が先に知るべきこと
Claude Code Channels入門: 初心者が先に知っておきたいこと
Claude Codeを使い始めると、こんな場面を想像することがあります。CIの失敗通知やチャットのメッセージ、Webhookのアラートが、いま開いている作業セッションにそのまま届いたら便利ではないか。Channels はまさにそのための機能です。
先に要点だけ言うと、Claude Code Channelsはいま動いているローカルのセッションに外部イベントを送り込む仕組みです。別のクラウド作業空間を新しく開くのではなく、すでに見ているファイル、ターミナルの文脈、会話履歴を保ったままClaudeが反応できます。
Channelsは外部イベントを実行中のClaude Codeセッションへ送ります。- 代表例はTelegram、Discord、Webhookです。
- イベントを受け取れるのは、セッションが開いている間だけです。
- 現在はResearch Previewなので、バージョンや組織ポリシーの制約があります。
Channelsとは何か
公式ドキュメントによると、Channels は実行中のClaude CodeセッションへイベントをプッシュするMCPサーバーです。通常のMCPサーバーは、Claudeが必要になったときに呼び出します。Channelsは逆です。外部システムが先にイベントを送り、Claudeがそのセッションの中で反応します。
初心者向けに言い換えるなら、こう考えるのがいちばんわかりやすいです。
Channelsの本質は、外で起きた出来事を、いま開いているClaude Codeセッションにそのまま届ける接続レイヤーです。
たとえば、こんな流れができます。
- CIジョブが失敗します。
- その失敗通知がChannel経由で送られます。
- Claudeは現在のセッションでそれを受け取ります。
- リポジトリやログを読み、すぐに調査を始められます。
重要なのは、Claudeが別の場所でゼロから始めるのではなく、いまのローカル作業文脈の中で反応するという点です。
なぜ初心者にも重要なのか
Channelsは一見すると高度な連携機能に見えます。でも実際には、Claude Codeの自動化がどう動くのかを理解するうえで、とてもわかりやすい機能です。
従来は、だいたい次のどちらかでした。
- 通知は来るが、コードの作業文脈とは切り離されている
- Claudeは賢いが、外部イベントを自分から受け取る仕組みはない
Channelsはこの二つをつなぎます。つまり、"何かが起きた" と "そのコードを見ているセッション" がひとつの流れになります。
たとえば次のような場面で便利です。
- ビルド失敗の通知が来た瞬間にClaudeに確認してほしいとき
- 自席を離れている間にスマホからClaudeへメッセージを送りたいとき
- 監視、デプロイ、エラー通知をそのまま作業セッションへ流したいとき
初心者がまず押さえるべきなのは、ChannelsはClaudeをより賢くする機能ではなく、Claudeが外部イベントをちょうどよいタイミングで受け取れるようにする仕組みだということです。
通常のMCPサーバーと何が違うのか
ここは混乱しやすいポイントです。
通常のMCPサーバー
通常のMCPサーバーは、Claudeが必要なときに呼び出します。Claudeが先にデータを取りに行く形です。
Channel
Channelは、外部システムが先にイベントをClaude Codeへ送ります。Claudeはそのイベントを現在のセッションで受け取り、反応します。
一文で言うならこうです。
通常のMCPはClaudeが情報を取りに行く仕組みで、Channelsは外部イベントがClaudeのところへ入ってくる仕組みです。
公式ドキュメントでも、ChannelsはWeb版Claude Code、Slack、通常のMCP、Remote Controlと比較されており、実行中のローカルセッションへ外部イベントをプッシュする機能として整理されています。
初心者が先に知っておきたい制約
期待値を先に合わせておくと理解しやすいです。現時点のドキュメントでは、いくつかの制約が明確に書かれています。
1. まだResearch Previewである
完全に安定した正式機能ではありません。ドキュメントでも、フラグやプロトコルの細部は変わる可能性があると案内されています。
2. バージョンとログイン条件がある
ドキュメントでは、ChannelsにはClaude Code v2.1.80以降が必要で、claude.ai ログインを前提としています。Console認証やAPIキー認証には対応していません。
3. セッションが開いていないと受け取れない
ここはとても大事です。イベントは常に開いているセッションに届きます。Claude Codeが閉じていれば何も受け取れません。継続運用したいなら、セッションを保つための運用が必要です。
4. Team / Enterpriseは組織ポリシーが必要
TeamやEnterpriseでは、管理者が channelsEnabled を有効にしないと動きません。MCPサーバーの設定が正しくても、このポリシーが無効ならメッセージは届きません。
いちばん簡単な理解方法はfakechatから始めること
公式ドキュメントでは、初心者向けの最初の入口として fakechat が紹介されています。最初からTelegramやDiscordをつなぐのではなく、ローカルのブラウザUIでメッセージを送って、Channelの流れを体験できます。
おおまかな流れはこうです。
- プラグインをインストールします。
--channelsオプション付きでClaude Codeを再起動します。- ローカルのブラウザUIからメッセージを送ります。
- そのメッセージが
<channel ...>イベントとしてClaude Codeに届きます。 - Claudeが反応し、必要なら返答もできます。
初心者にとってこれがよい理由ははっきりしています。
- いきなり実サービスの認証設定をしなくてよい
- Channelがどうイベントを流し込むのかを目で確認できる
- TelegramやDiscordの前に、仕組みそのものを理解しやすい
TelegramとDiscordのChannelはどうつながるか
現在の公式サポート例はTelegramとDiscordです。大まかな流れは共通しています。
- 各プラットフォームでBotを作成します。
- Claude Codeの公式プラグインをインストールします。
- トークンを設定します。
claude --channels ...でClaude Codeを再起動します。- Botへメッセージを送り、ペアリングコードを受け取ります。
- Claude Code内でそのペアリングを承認します。
- 最後にallowlistで許可した送信者だけ通します。
ここで初心者が覚えておきたい点は二つです。
- Channelは最初から誰にでも開いているわけではない
- 許可済み送信者だけを通す仕組みが前提になっている
ドキュメントでも、承認されたchannel pluginはsender allowlistを維持し、許可されていない送信者からのメッセージは静かに破棄されると説明されています。
Claudeは実際に何を受け取るのか
Channels referenceの文書は、この部分をかなり具体的に説明しています。Channelサーバーは notifications/claude/channel という形式でイベントを送り、Claude Code側ではそれが <channel> タグとして届きます。
たとえば次のような形です。
<channel source="webhook" severity="high" run_id="1234">
build failed on main: https://ci.example.com/run/1234
</channel>ここで見るべきポイントは三つです。
contentは実際のメッセージ本文になるmetaはタグ属性として入るsourceはどのChannelから来たかを示す
つまりChannelは、ただのチャット文字列ではなく、メタ情報つきの構造化イベントに近い仕組みです。
Channels referenceで初心者が必ず理解しておきたいのは、Channelイベントが単なるテキストではなく、content + meta の組み合わせでセッションへ入ってくるということです。一方向Channelと双方向Channel
ドキュメントでは、Channelは大きく二種類に分けて考えられます。
一方向Channel
Webhook、監視通知、アラートのように、情報が入ってくるだけのChannelです。Claudeはイベントを読み、セッション内で反応しますが、その経路を使って返答するわけではありません。
双方向Channel
TelegramやDiscordのようなチャットブリッジ型です。この場合、Channelサーバーが reply のようなツールを公開し、Claudeがメッセージを返せます。
実装の話は少し技術的ですが、概念だけならシンプルです。
capabilities.experimental['claude/channel']がChannelであることを示すtools: {}で返信用ツールを発見できるようにするinstructionsに、どんなイベントが届きどう返答するかを書く
簡単に言い換えるとこうです。
一方向Channelは通知パイプで、双方向Channelはチャットブリッジです。
自分で作るなら: カスタムChannelの最小構成
Reference文書には webhook.ts の例もあり、自作Channelの最小形が見えます。初心者はコードを丸ごと覚える必要はありません。構造だけつかめば十分です。
カスタムChannelの最小構成は、だいたい次の三つです。
- MCPサーバーを作り、Channel capabilityを宣言する
- HTTP POSTなどの外部イベントを受けて
mcp.notification()で転送する - 必要なら
replyツールを追加して双方向にする
つまりChannelsは、完全に別物の新機能というより、Channel用の契約を追加したMCPサーバーとして理解するのが自然です。
この見方は、MCPの基本を少し知っている人にとってかなり助けになります。
どんなときにChannelsを使うべきか
公式ドキュメントは、Channelsを近い機能と比較しています。初心者にはこの比較がかなり役立ちます。
Claude Code on the web
こちらは新しいクラウドサンドボックスで作業を始める用途に向いています。いま開いているローカルセッションへイベントを流し込む機能とは性格が違います。
Claude in Slack
チームの会話文脈で使うには便利ですが、現在のローカルセッションへ外部イベントを届ける用途とは別です。
通常のMCPサーバー
Claudeが必要なときに呼び出すためのものです。イベントプッシュが中心ではありません。
Remote Control
こちらは遠隔操作の色が強い機能です。Channelsは外部システムがセッションへ通知やトリガーを送ることに重点があります。
実用的な判断基準はこれです。
すでに動いているローカルのClaude Codeセッションが外部イベントに反応する必要があるなら、Channelsがもっとも合っています。
初めて使う人向けの現実的な順番
最初からTelegram Bot、Discord設定、カスタムWebhookを一気に進めると、かえって理解しづらくなります。おすすめは次の順番です。
- まず
fakechatで流れを体験する - 次にTelegramかDiscordのどちらか一つを試す
- ペアリングとallowlistの考え方を理解する
- 最後にCIや監視通知向けのカスタムWebhook Channelを考える
この順番がよいのは、最初に難しいのが設定ではなく概念理解だからです。"外部イベントがいまのセッションへ入る" という図が頭に入れば、その先は各プラットフォームごとの差分として見やすくなります。
初心者が見落としやすい注意点
最後に、実際によく見落とされるポイントをまとめます。
セッションが閉じていると何も届かない
Channelsは常時開いているセッションが前提です。継続運用したいなら、Claude Codeをどう維持するかも考える必要があります。
権限プロンプトで止まることがある
ドキュメントでも、ユーザー不在時に権限承認プロンプトが出るとセッションが停止する可能性があると説明されています。完全自動運用を考えるなら、この挙動は先に理解しておくべきです。
開発中のChannelには特別なフラグが必要な場合がある
Research Previewの段階では、カスタムChannelを試す際に --dangerously-load-development-channels のような開発用フラグが必要です。承認済みプラグインと自作中のChannelは同じ扱いではありません。
信頼できるソースだけをつなぐべき
Channelは、ライブの作業セッションにイベントを流し込みます。だからこそ、公式ドキュメントでもallowlistや組織ポリシーが強調されています。
まとめ
Claude Code Channelsは、外部のメッセージ、Webhook、アラートをいま実行中のClaude Codeセッションへ流し込む仕組みです。通常のMCPのようにClaudeが必要なとき情報を取りに行くのではなく、外部システムが先にイベントを送り、Claudeがすでに持っているローカル文脈の中で反応できます。
初めて触るなら、まず fakechat で仕組みを体験し、そのあとTelegramかDiscord、最後にカスタムWebhookへ広げるのが理解しやすい順番です。ドキュメントを読むときは、セッション中心の動き、プッシュ配信、一方向と双方向の違い、allowlist、Research Previewの制約、この五つを先に押さえると全体像が見えやすくなります。