【Claude Code 連載第45回】チャネル（Channels）— 実行中のセッションに外からイベントを投げ込む

よっしー

こんにちは。よっしーです(^^)

背景
1. 一言でいうと何か
2. どういう場面で役立つか
3. 前提条件と、コマンドの実例
4. まとめ＋次回予告

背景

この連載では、Claude Codeの公式ドキュメントを1ページずつ読み解いていきます。公式ドキュメントは情報が網羅されている分、「結局どの機能を、どんな場面で使えばいいのか」は自分で考える必要があり、読むのに意外と時間がかかります。そこで、私が実務で使うために読み込んだ内容を「使う場面→実例コード」の順に整理して残していくことにしました。専門家の解説というより、一次情報を読んだ記録です。推測や動作を確認していない部分には、その都度そう書きます。

1. 一言でいうと何か

チャネルは、すでに動いている Claude Code のセッションに対して、外部から「イベント」を割り込ませるための MCP サーバーです。

Claude Code の通常の使い方は、あなたがターミナルの前に座り、プロンプトを打ち、返事を読む、という同期的なやりとりです。チャネルはこの前提を崩します。あなたがターミナルの前にいなくても、Telegram や Discord、iMessage から送ったメッセージ、あるいは CI やエラートラッカーから飛んできたウェブフックが、開きっぱなしのセッションに届く。Claude はそれを読んで、あなたのマシン上の実ファイルに対して作業し、必要なら同じチャネル経由で返信します。つまり双方向のチャットブリッジとして機能します。

ここで押さえるべき最重要の性質が2つあります。

ひとつは、イベントはセッションが開いている間しか届かないということ。チャネルはメールボックスではありません。セッションを閉じれば、その間に来たイベントは受け取れません。常時受け取りたいなら、Claude をバックグラウンドプロセスか永続的なターミナルで走らせておく必要があります。

もうひとつは、新しいセッションを作らないということ。ウェブ上の Claude Code や Slack の Claude は、リクエストのたびに新しいクラウドサンドボックスやセッションを生成します。チャネルは逆で、既存のセッションにイベントを届けます。だから Claude は「さっきまで開いていたファイル」「さっきまでデバッグしていた内容」を覚えたまま新しいイベントに対応できます。この「文脈が継続する」点が、他の連携機能との決定的な違いです。

なお、Claude がチャネル経由で返信したとき、ターミナルには受信メッセージは表示されますが、返信テキストそのものは表示されません。ターミナルに出るのはツール呼び出しと「送信済み」といった確認だけで、実際の返信内容は Telegram なり Discord なり、相手のプラットフォーム側に現れます。ターミナルを見ていて「返事が空だ」と焦らないための注意点です。

現時点でチャネルはリサーチプレビューです。段階的にロールアウト中で、--channels フラグの構文やプロトコルの取り決めはフィードバック次第で変わりえます。

2. どういう場面で役立つか

シーン1：外出先の電話から、自宅・職場のマシンを動かす

もっとも直感的な使い方がこれです。Telegram のボットに「あのバグの再現手順を試しておいて」と送ると、家に置いてある開発マシンの Claude Code セッションがそれを受け取り、実際のリポジトリのファイルに対して作業し、結果を同じ Telegram のチャットに返してきます。クラウドの隔離環境ではなく、自分のマシンの本物のファイルが対象になるところがポイントです。ローカルにしかない設定ファイル、ローカルの DB、ローカルでしか通らないテスト——そういうものを扱う作業を外から動かせます。

シーン2：CI やエラートラッカーのウェブフックを、作業中のセッションに流し込む

CI が落ちた、Sentry がエラーを吐いた、デプロイパイプラインが止まった。こうした通知は普通、Slack に飛んで、あなたが気づいて、ターミナルに戻って、Claude に状況を説明し直すところから始まります。チャネルを使うと、そのウェブフックがClaude がすでにそのコードを開いてデバッグしていたセッションに直接届く。説明のやり直しが要りません。「さっき直したところの CI が落ちた」という文脈を Claude が保持したまま、失敗ログを受け取れます。

シーン3：長時間タスクの見守りと軌道修正

大きなリファクタや移行作業を走らせているあいだ、席を外したい。チャネルを開けておけば、進捗を尋ねたり、途中で方針を変えたりを電話から行えます。ここで問題になるのが権限プロンプトです。Claude がターミナルを離れているあいだに権限確認にぶつかると、セッションはあなたが応答するまで一時停止してしまいます。これに対しては、権限リレー機能を宣言しているチャネルサーバーであれば、プロンプト自体を手元に転送してリモートで承認・拒否できます。完全無人で回したい場合は --dangerously-skip-permissions でほとんどのプロンプトをバイパスできますが、これは信頼できる環境限定です。しかもバイパスされないものが残ります——明示的な ask ルール、組織が ask に設定したコネクタツール、requiresUserInteraction が付いた MCP ツールは、依然としてプロンプトが出ます。

なお -p の非対話型モードでチャネルを走らせる場合は、複数選択質問や Plan Mode の承認といった「ターミナル入力を要求するツール」がそもそも無効化されるので、入力待ちで止まることはありません。

不要・向かないケース

ターミナルの前にいるとき。素直にターミナルで打つほうが速いです。チャネルは不在時のための仕組みです。
自己完結した非同期タスクを丸ごと投げたいとき。「このイシューを直して PR を出しておいて」のように、文脈の継続が要らず、あとで結果だけ確認すればいい作業は、ウェブ上の Claude Code のほうが適しています。クラウドで走るのでマシンを起動しっぱなしにする必要もありません。
Claude に外部システムを「読ませたい」だけのとき。これは普通の MCP サーバーの仕事です。Claude がタスクの途中で必要に応じてクエリする、という形で足ります。セッションに何かをプッシュする必要はありません。
手元のセッションを電話から「操縦」したいだけのとき。それはリモートコントロールの領分です。チャネルは Claude 以外のソースからイベントを流し込むための仕組みで、目的が違います。
Amazon Bedrock、Google Cloud の Agent Platform、Microsoft Foundry を使っているとき。チャネルは利用できません。Anthropic 認証（claude.ai か Console API キー）が必要です。
Team / Enterprise 組織で、管理者がまだ有効にしていないとき。ユーザー側では回避できません。

3. 前提条件と、コマンドの実例

前提条件（コマンドを打つ前に）

Claude Code がインストール・認証済みであること（claude.ai アカウントまたは Claude Console API キー）。前述のとおり Bedrock / Vertex 系 / Foundry では動きません。
Bun がインストールされていること。用意されているチャネルプラグインはすべて Bun スクリプトです。bun --version が通るか確認してください。
Team / Enterprise / 管理 Console 組織の場合、管理者がチャネルを有効にしていること。
そしてすべてのケースで共通：ユーザーが --channels でセッションごとにオプトインするまで、チャネルは動きません。プラグインを入れただけでは動かないという点は繰り返し強調されています。

まず fakechat で挙動を確かめる

いきなり Telegram のボットを作る前に、公式のデモチャネル「fakechat」で一連の流れを体験するのが安全です。localhost でチャット UI が立つだけで、認証も外部サービスの設定も要りません。

プラグインを入れる：

/plugin install fakechat@claude-plugins-official

「どのマーケットプレイスにも見つからない」と言われたら、マーケットプレイスが未追加か古い可能性があります。/plugin marketplace update claude-plugins-official で更新するか、未追加なら /plugin marketplace add anthropics/claude-plugins-official を実行してから、インストールをやり直します。

いったん Claude Code を終了し、フラグ付きで起動し直します：

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

fakechat サーバーが自動で立ち上がります。--channels にはスペース区切りで複数のプラグインを渡せます。

あとは http://localhost:8787 を開いて、何か打ち込むだけです：

hey, what's in my working directory?

このメッセージは Claude Code セッションに <channel source="fakechat"> イベントとして届きます。Claude がそれを読み、作業し、fakechat の reply ツールを呼ぶと、答えがブラウザのチャット UI に戻ってきます。この「イベントとして届く → 作業する → reply ツールで返す」という三段構えが、すべてのチャネルに共通する骨格です。

Telegram を例にした本番セットアップ

流れは fakechat とほぼ同じで、ボットの作成・トークン設定・ペアリングが加わります。

まず Telegram で BotFather に /newbot を送り、表示名と bot で終わる一意のユーザー名を決め、返ってきたトークンを控えます。

プラグインを入れ、設定コマンドを有効化します：

/plugin install telegram@claude-plugins-official

インストール後は /reload-plugins を実行して、プラグインの設定コマンドをアクティブにします。ここを飛ばすと次のコマンドが見つかりません。

トークンを渡します：

/telegram:configure <token>

これは ~/.claude/channels/telegram/.env に保存されます。Claude Code を起動する前にシェル環境で TELEGRAM_BOT_TOKEN を設定しておく方法もあります。

チャネルを有効にして再起動：

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

ここで Telegram を開き、ボットに何か送ります。ボットがペアリングコードを返してくるので、Claude Code に戻って承認します：

/telegram:access pair <code>

最後に、自分のアカウント以外を締め出します：

/telegram:access policy allowlist

ボットが無反応な場合は、--channels 付きで Claude Code が動いているかを確認してください。ボットはチャネルがアクティブな間しか返信できません。

Discord と iMessage の違い

Discord は手順の形がほぼ同じで、コマンドの telegram が discord に置き換わります（/discord:configure <token>、/discord:access pair <code> など）。違いは Discord 側の準備で、Developer Portal でアプリとボットを作り、Privileged Gateway Intents の Message Content Intent を有効にする必要があること、そして OAuth2 の URL Generator で bot スコープと、View Channels / Send Messages / Send Messages in Threads / Read Message History / Attach Files / Add Reactions の各権限を付けて招待することです。

iMessage は毛色が違います。macOS 限定で、ボットトークンも外部サービスも不要。~/Library/Messages/chat.db を直接読み、AppleScript で返信します。そのぶん OS の許可が要ります。初回読み取り時に macOS がフルディスクアクセスを求めるので Allow を押す（出ない/拒否した場合は System Settings > Privacy & Security > Full Disk Access で手動追加。これがないとサーバーは authorization denied で即終了します）。さらに Claude の最初の返信時に、ターミナルが Messages を操作してよいか尋ねる Automation プロンプトが出るので OK を押します。

iMessage はアクセス制御の考え方も違います。自分自身へのセルフチャットは設定なしでゲートを素通りします。他の連絡先を通したいときだけハンドルを追加します：

/imessage:access allow +15551234567

ハンドルは +country 形式の電話番号か、user@example.com のような Apple ID メールです。

セキュリティの考え方

承認済みチャネルプラグインはすべて送信者許可リストを持ちます。追加した ID からのメッセージだけが通り、それ以外は静かに捨てられます。Telegram と Discord はペアリング（ボットに送る → コードが返る → セッションで承認 → 許可リストに追加）でリストを立ち上げ、iMessage はセルフチャット + /imessage:access allow という形をとります。

その上に二重のゲートがあります。ひとつはセッションごとの --channels。もうひとつは組織レベルの channelsEnabled です。ここで効いてくるのが冒頭の注意点で、.mcp.json に書いてあるだけではメッセージをプッシュできません。--channels で明示的に名前を挙げる必要があります。

そして見落としやすい点：チャネルが権限リレーを宣言している場合、許可リストは権限プロンプトのゲートも兼ねます。つまりチャネル経由で返信できる人は誰でも、そのセッションのツール使用を承認・拒否できてしまう。許可リストに入れるのは、その権限を預けてよい相手だけにしてください。

管理者向けの設定

管理者は2つの管理設定で可用性をコントロールします。ユーザー側からのオーバーライドはできません。デフォルトは認証方法で変わります——claude.ai Team / Enterprise は Owner が有効にするまでブロック、Console と API キー認証はデフォルトで許可（管理設定をデプロイしている組織だけ、このキーの設定が必要）。組織に属さない Pro / Max ユーザーはこのチェックを丸ごとスキップします。

channelsEnabled：マスタースイッチ。true でないとチャネルはメッセージを配信しません。claude.ai の Admin console（Admin settings → Claude Code → Channels、Owner ロールが必要）のトグルか、管理設定で直接設定します。オフのときは開発フラグを含むすべてのチャネルをブロックします。
allowedChannelPlugins：チャネルが有効になったうえで、どのプラグインが登録できるか。設定すると Anthropic 管理のリストを置き換えます。channelsEnabled が true のときだけ効きます。

{
  "channelsEnabled": true,
  "allowedChannelPlugins": [
    { "marketplace": "claude-plugins-official", "plugin": "telegram" },
    { "marketplace": "claude-plugins-official", "plugin": "discord" },
    { "marketplace": "acme-corp-plugins", "plugin": "internal-alerts" }
  ]
}

各エントリはプラグイン名と、それが由来するマーケットプレイスの両方を指定します。社内マーケットプレイスの独自チャネルを承認する、公式プラグインの一部だけに絞る、あるいはその両方、といった使い分けができます。Anthropic のデフォルト許可リストに戻したいときは、この設定を未設定のままにします。空配列はすべてのチャネルプラグインをブロックしますが、--dangerously-load-development-channels で回避されうるので、開発フラグ込みで完全に止めたいなら channelsEnabled を未設定のままにするのが正解です。

設定が無効・未設定の場合の挙動も知っておくと切り分けが速くなります。**MCP サーバー自体は接続し、そのツールも動きますが、チャネルメッセージだけが届きません。**起動時に警告が出て、管理者に有効化を依頼するよう促されます。同様に、許可リストにないプラグインを --channels に渡した場合も、Claude Code は普通に起動して、チャネルだけが登録されず、起動時通知が理由を説明します。「起動はしたのにメッセージが来ない」ときは、まず起動時の通知を読んでください。

なお、まだプラグインが存在しないシステムに対応させたい場合は、自分でチャネルを構築できます。開発中のチャネルのテストには --dangerously-load-development-channels を使います。

4. まとめ＋次回予告

チャネルの要点を整理します。

実行中のセッションにイベントをプッシュする MCP サーバー。新しいセッションを作らないので、Claude は作業の文脈を保ったままイベントに対応できる。
セッションが開いている間しか届かない。常時受け取るならバックグラウンド or 永続ターミナルで走らせる。
有効化は二段階：プラグインをインストールし、--channels でセッションごとにオプトインする。.mcp.json に書くだけでは動かない。
Bun が必須、Anthropic 認証が必須、Bedrock / Agent Platform / Foundry では不可。
送信者許可リストが唯一の防壁で、権限リレーを使う場合はツール承認権限も兼ねる。追加する相手は慎重に。
リサーチプレビュー。フラグ構文もプロトコルも変わりうる。

使い分けの整理としては、「文脈を保ったまま外からイベントを受けたい」ならチャネル、「電話からセッションを操縦したい」ならリモートコントロール、「独立したタスクを丸投げしたい」ならウェブ上の Claude Code、「イベントを待つのではなくタイマーで回したい」ならスケジュール済みタスク、「Claude に外部システムを読ませたいだけ」なら普通の MCP サーバー、となります。

まずは fakechat で --channels の感覚を掴み、そのうえで自分がいちばん使うメッセンジャーのプラグインに進むのが最短ルートです。

次回予告（暫定）：チャネルリファレンス（channels-reference）を取り上げ、既製プラグインではなく自分でチャネルを構築する側の話——プロトコルの契約、権限プロンプトのリレー、ウェブフックレシーバーの作り方——を扱う予定です。