Claude Code Channels組織管理 — 有効化と許可プラグインの制限
Team・EnterpriseでChannelsを有効化するchannelsEnabledと、使えるプラグインを絞るallowedChannelPluginsの設定方法・既定値・空配列の落とし穴をまとめます。
Claude Code Channels組織管理でできること
Channelsは、Webhookやチャットのメッセージをメンバーの実行中セッションに直接push(送信)する機能です。Team・Enterprise組織では、Ownerが管理コンソールで有効化するまでメンバーは一切使えません。組織管理の要点は2つのmanaged settingです。channelsEnabled がチャンネル配信そのものを許可するマスタースイッチで、allowedChannelPlugins が「どのプラグインを使わせるか」を絞る許可リストです。
この記事は組織側の設定を行う管理者向けです。個々の開発者が自作チャンネルをplugin化して配布する手順は、別記事「Claude Code Channelsプラグイン化 — 自作チャンネルの配布手順」にまとめています。
Channelsが実際にメッセージを届けるまでには、3段階のゲートを順番に通過する必要があります。どれか1つでも欠けると、メッセージは届きません。
メッセージが届くまでの3つのゲート
- 1
①組織の許可(Owner・管理者)
channelsEnabledをtrueにします。未設定またはfalseなら、この先はすべて無効です。 - 2
②プラグインの絞り込み(管理者・任意)
allowedChannelPluginsで使えるプラグインを限定します。設定しなければAnthropicの既定リストが適用されます。 - 3
③セッションでの有効化(メンバー本人)
起動時に
--channelsフラグでプラグインを指名します。.mcp.jsonに書いてあるだけでは届きません。
管理者が①②を整えても、メンバーが③を付け忘れれば何も届きません。逆に③を付けていても①が無効なら、Claude Code自体は起動してもチャンネルからのメッセージは届きません。
前提条件
- Team・Enterprise組織のOwnerロール(有効化操作に必要)
- managed settingsを配布する仕組み(claude.ai管理コンソール、または
settings.jsonを組織全体に配るMDM等の運用) - 対象メンバーがどの認証方式でClaude Codeにサインインしているか(claude.ai認証かConsole APIキー認証かで、既定値が変わります)
ステップ1: 認証方式ごとの既定値を確認する
設定を触る前に、自組織の既定値がどちらに寄っているかを把握します。既定値は認証方式で分かれます。
認証方式ごとの既定値
claude.ai Team・Enterprise
Ownerが有効化するまで、チャンネルは動きません。
Anthropic Console(APIキー認証)
managed settingsを配布していなければ、そのまま使えます。配布している組織は channelsEnabled の設定が必要です。
managed settingsを配布しているのに channelsEnabled を設定していなければ、Console認証でもチャンネルはブロックされます。「うちはConsole認証だから何もしなくていい」と決めず、managed settingsの配布有無で判断します。
組織に属さないPro・Maxの個人ユーザーは、channelsEnabled と allowedChannelPlugins のチェック自体がありません。セッションごとに --channels を付けるだけで使えます。
Amazon Bedrock、Google CloudのAgent Platform、Microsoft Foundry経由の利用はChannelsの対象外です。これらのクラウド経由でClaude Codeを配っている組織は、managed settingsを整えても動きません。
ステップ2: channelsEnabledで有効化する
claude.ai Team・Enterprise組織のOwnerは、claude.ai → Admin settings → Claude Code → Channelsから有効化します。managed settingsで直接指定する場合は次のように書きます。
{
"channelsEnabled": true
}有効化を忘れたままメンバーがプラグインをインストールすると、MCPサーバー自体は接続しツールも動くのに、チャンネルのメッセージだけが届きません。起動時に警告が出て、管理者に設定を依頼するよう案内されます。「pluginは入ったのに何も届かない」という問い合わせが来たら、まずここを疑います。
channelsEnabled が false または未設定のときは、--dangerously-load-development-channels を含めてすべてのチャンネルがブロックされます。開発中のテストだからといって個々の開発者側の工夫で回避することはできません。
ステップ3: allowedChannelPluginsで使えるプラグインを絞る
channelsEnabled を有効にしただけでは、Anthropicが管理する既定allowlist(claude-plugins-official のチャンネルプラグイン群)がそのまま適用されます。使えるプラグインを制限したい、あるいは社内独自のプラグインを許可したい場合は allowedChannelPlugins を設定します。
{
"channelsEnabled": true,
"allowedChannelPlugins": [
{ "marketplace": "claude-plugins-official", "plugin": "telegram" },
{ "marketplace": "claude-plugins-official", "plugin": "discord" },
{ "marketplace": "acme-corp-plugins", "plugin": "internal-alerts" }
]
}各エントリは marketplace と plugin の組で1件を指定します。公式プラグインを一部だけ残しつつ、社内マーケットプレイスのプラグインを1件加える、といった組み合わせが可能です。この設定を一度でも書くと、Anthropicの既定allowlistは丸ごと置き換わります。公式のTelegram・Discordを残したいなら、それぞれ明示的にリストへ書き足す必要があります。
Enterpriseプラグインマーケットプレイスには、アップロード・編集時に第三者製プラグインを検査するスキル・プラグインのセキュリティスキャンがあります。Ownerが有効化でき、2026年10月2日から、未設定のEnterprise組織では既定でオンになります。ただしMCPサーバーとフックは検査対象外です。channelの本体はMCPサーバーなので、このスキャンではその安全性は担保されません。
メンバーが allowedChannelPlugins に無いプラグインを --channels に渡した場合、Claude Codeは通常どおり起動しますが、そのプラグインだけ登録されず、起動時の通知で「組織の承認リストに無い」旨が案内されます。
空配列にしてもdevelopment-channelsは止まらない
allowedChannelPlugins を空配列 [] に設定すると、allowlist経由のプラグインはすべてブロックされます。ここでよくある誤解が、「空配列にすれば社内でチャンネルを完全に止められる」という思い込みです。空配列が塞ぐのはallowlistを経由する起動だけです。開発者が --dangerously-load-development-channels を使えば、依然としてローカルの開発中チャンネルを動かせてしまいます。
チャンネルを止める方法は3通りあり、効く範囲が違います。
止め方と効く範囲
channelsEnabledを未設定にする
開発用フラグを含めて、すべての経路がブロックされます。完全に止めたいときはこれだけです。
allowedChannelPluginsを空配列にする
allowlist経由のプラグインだけが止まります。
--dangerously-load-development-channelsは通ります。特定のプラグインをリストに書かない
そのプラグインだけ登録されません。Claude Code自体は通常どおり起動します。
権限リレー対応のプラグインを許可する前に確認すること
allowedChannelPlugins は「どのプラグインを動かせるか」の設定に見えますが、権限リレーに対応したプラグインを加えると意味が一段重くなります。権限リレーとは、ツール実行の許可ダイアログを外部チャンネルにも並行して出し、そこからの承認・拒否を受け付ける仕組みです。詳しい仕様は権限リレーの解説にあります。
チャンネル経由で返信できる人は誰でも、そのセッションのツール実行を承認・拒否できます。管理者がリレー対応のプラグインを許可するということは、そのプラグインのsender allowlistを管理する人に、組織メンバーのセッションでの承認権限を実質的に委ねることです。sender allowlistの側の設計はチャンネルの送信者ゲートで扱っています。
リレーは組織の制御の内側に置かれています。v2.1.234以降のClaude Codeは、そのセッションでチャンネルとして登録したサーバーにしか許可リクエストを送りません。channelsEnabled が無効なら、リレーも動きません。一方、プロジェクトの信頼確認やMCPサーバーの同意ダイアログはリレーされず、ローカルのターミナルにしか出ません。
社内独自のチャンネルを許可リストに加える前に、作成者へ次の2点を確認しておく選択肢があります。
- 権限リレー機能(
claude/channel/permission)を宣言しているか。宣言していなければこの節は関係ありません - sender allowlistの管理者が誰で、どういう基準で送信者を追加しているか
公式のTelegram・DiscordはペアリングでsenderのIDを登録します。iMessageは自分宛てのメッセージだけが自動で通り、他の連絡先は /imessage:access allow で1件ずつ追加する方式です。許可リストに加えるプラグインごとに、この登録経路を見ておきます。
プロトコルネゴシエーション設定との相互作用
MCP_PROTOCOL_NEGOTIATION を auto にしてv2のMCPクライアントランタイムを使っている組織では、allowlistの設定が正しくてもチャンネルが登録されないことがあります。protocol revision 2026-07-28で通信しようとするサーバーを、Claude Codeがチャンネルとして登録しない仕様があるためです。allowlistの設定を何度確認しても解決しない不具合報告を受けたら、この設定も併せて確認します。
「届かない」と言われたときの切り分け
症状ごとに、どのゲートで止まっているかを見ます。
- MCPツールは動くのにメッセージだけ届かない: ①が未設定か
falseです。起動時に管理者へ依頼するよう促す警告が出ます - 公式のTelegramだけ使えなくなった: ②で既定allowlistが丸ごと置き換わっています。公式プラグインを残すなら、リストに書き足します
--channelsに渡したプラグインだけ登録されない: ②のリストに無いか、そのプラグインがインストールされていません。起動画面のチャンネル通知の下に、原因を示す警告が出ます- allowlistは正しいのに登録されない:
MCP_PROTOCOL_NEGOTIATIONがautoのv2ランタイムを疑います - 社内マーケットプレイスの読み込み時に
untrusted sourceと出る: Channels固有ではなく、マーケットプレイス名がAnthropic公式用の予約名と衝突している場合のエラーです。「untrusted source」エラーの対処を先に確認します
--help に出ないフラグを手元で確かめる
チャンネル関連のフラグは、プレビュー中は claude --help に載りません。Claude Code v2.1.285で確認すると、次のとおり1行も出ませんでした。
claude --version
claude --help | grep -i channelclaude --version は 2.1.285 (Claude Code) を返し、grep は該当行なしで終了コード1になりました。フラグが存在しないのではなく、一覧に出ていないだけです。メンバーに「--help に無いから使えない」と誤解されたときは、この点を伝えます。
まとめ
持ち帰る判断は2つです。有効化の前に、自組織の認証方式とmanaged settingsの配布有無から既定値を確かめること。完全に止めたいときは、空配列ではなくchannelsEnabledを未設定にすることです。