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つでも欠けると、メッセージは届きません。
| 段階 | 誰が制御するか | 設定 |
|---|---|---|
| ①組織の許可 | 誰が制御するか組織のOwner・管理者 | 設定channelsEnabled |
| ②プラグインの絞り込み | 誰が制御するか組織の管理者(任意) | 設定allowedChannelPlugins |
| ③セッションでの有効化 | 誰が制御するかメンバー本人 | 設定--channels フラグ |
管理者が①②を整えても、メンバーが③を付け忘れれば何も届きません。逆に③を付けていても①が無効なら、Claude Code自体は起動してもチャンネルは沈黙したままです。問い合わせ対応では、この3段階のどこで止まっているかを順に確認します。
前提条件
- 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を配布している組織のみ、このキーの設定が必要) |
Console認証の組織でも、managed settingsを配布していない限りは既定のまま許可されています。逆に、managed settingsを配布しているのに channelsEnabled を設定していなければ、Console認証でもチャンネルはブロックされます。「うちはConsole認証だから何もしなくていい」と思い込まず、managed settingsを配布しているかどうかで判断します。
組織に属さないPro・Maxの個人ユーザーは、この節の話がまるごと関係ありません。channelsEnabled や allowedChannelPlugins のチェック自体をスキップし、セッションごとに --channels を付けるだけでチャンネルを使い始められます。
ステップ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プラグインマーケットプレイス経由で配る場合、アップロード・編集のタイミングでスキル・プラグインのセキュリティスキャンが自動で動き、悪意あるコードの混入をチェックします(Enterpriseプラン限定のベータ機能)。allowedChannelPluginsにそのマーケットプレイスのプラグインを加える前段の安全網として働きます。
メンバーが allowedChannelPlugins に無いプラグインを --channels に渡した場合、Claude Codeは通常どおり起動しますが、そのプラグインだけ登録されず、起動時の通知で「組織の承認リストに無い」旨が案内されます。
空配列にしてもdevelopment-channelsは止まらない
allowedChannelPlugins を空配列 [] に設定すると、allowlist経由のプラグインはすべてブロックされます。ここでよくある誤解が、「空配列にすれば社内でチャンネルを完全に止められる」という思い込みです。空配列が塞ぐのはallowlistを経由する起動だけです。開発者が --dangerously-load-development-channels を使えば、依然としてローカルの開発中チャンネルを動かせてしまいます。
チャンネルを完全に止めたい場合の設定
チャンネルを開発中のものも含めて組織全体で完全に禁止したいなら、allowedChannelPlugins を空配列にするのではなく、channelsEnabled 自体を未設定のままにします。
{
}channelsEnabled が未設定またはfalseの状態は、--dangerously-load-development-channels を含むすべての経路をブロックします。空配列での制限とは効果の範囲が違う点に注意します。
権限リレー対応プラグインを許可する前に確認すること
allowedChannelPluginsは「どのプラグインを動かせるか」だけの設定に見えますが、そのプラグインが権限リレーに対応している場合はもう一段重い意味を持ちます。権限リレーとは、Claude Codeの許可ダイアログを外部チャンネル越しに承認・拒否できる仕組みです。
sender allowlistに登録された送信者は誰でも、そのチャンネル経由でツール実行を承認できます。つまり管理者が権限リレー対応のプラグインをallowedChannelPluginsに加えるということは、そのプラグインのsender allowlistを管理している人・チームに、組織メンバーのセッションでのツール承認権限を実質的に委ねることを意味します。
社内独自のチャンネルを許可リストに加える前に、次の2点を作成者に確認しておくと安全です。
- 権限リレー機能を実装しているか(実装していなければこの節は関係ありません)
- sender allowlistの管理者が誰で、どういう基準で送信者を追加しているか
公式のTelegram・Discord・iMessageプラグインは、ペアリングや自己送信によるsender allowlistの仕組みを備えていますが、権限リレーへの対応可否はプラグインごとに異なります。「公式だから安全」と一律に判断せず、許可リストに加える個別のプラグインごとに確認します。
プロトコルネゴシエーション設定との相互作用
MCP_PROTOCOL_NEGOTIATION を auto にしてv2のMCPクライアントランタイムを使っている組織では、allowlistの設定が正しくてもチャンネルが登録されないことがあります。protocol revision 2026-07-28で通信しようとするサーバーを、Claude Codeがチャンネルとして登録しない仕様があるためです。allowlistの設定を何度確認しても解決しない不具合報告を受けたら、この設定も併せて確認します。
よくあるつまずき
- channelsEnabledを設定したのにブロックされたまま: managed settingsの配布経路(claude.ai管理コンソールvs手動配布のsettings.json)が競合していないか確認します。複数の設定ソースがある場合は、実際に適用されている値をメンバー側で確認してもらいます
- 公式のTelegramだけ使えなくなった: allowedChannelPluginsを設定した時点でAnthropicの既定allowlistは丸ごと置き換わります。公式プラグインを残したいなら明示的にリストへ加えます
- 空配列にしたのに開発中チャンネルが動いている: 想定どおりの挙動です。development-channelsフラグごと止めたいなら
channelsEnabledを未設定にします - Console認証なのにチャンネルが動かない: managed settingsを配布している組織では、Console認証でも
channelsEnabledの明示設定が要ります。既定許可が効くのは、managed settingsを配布していない組織だけです - 社内マーケットプレイスの追加自体で
untrusted sourceと出る: これはChannels固有の問題ではなく、マーケットプレイス名がAnthropic予約枠と衝突している場合に出るエラーです。命名を変えるか、「untrusted source」エラーの対処を先に確認します
まとめ
Channelsの組織管理は「配信を許可するかどうか」のchannelsEnabledと「どのプラグインを許可するか」のallowedChannelPluginsという、役割の異なる2つの設定で成り立っています。既定値は認証方式とmanaged settingsの配布有無で変わるため、有効化前に自組織がどちらに当たるかを確認します。完全に止めたいときは空配列でなくchannelsEnabledを未設定にする、という一点だけ覚えておけば、設定ミスによる問い合わせの大半は避けられます。