Claude TagをSlackに入れる前に、情シスが握るべき「権限はチャンネルに付く」という話
- ▶ Claude TagがこれまでのSlack連携と決定的に違う点（権限が「人」ではなく「チャンネル」に付く）
- ▶ 情シスが導入前に必ず握っておくべき4つの設計ポイント
- ▶ 50〜300名規模で事故を起こさずに始めるパイロットの回し方
- ▶ コスト上限（spending limit）はセキュリティ機能ではない、という整理
2026年6月23日、AnthropicがSlack向けに「Claude Tag」を出した。チャンネルに @Claude でメンションすると、そのスレッドで実際に仕事をして結果を返してくれる——という、いわば「Slackに常駐する同僚」だ。
触ってみると確かに便利だ。だが情シスとして導入を任される立場なら、「便利そう」で終わってはいけない。このプロダクトは権限設計の考え方が今までと根本的に違っていて、そこを理解せずにチャンネルへ招待していくと、後から確実に事故る。この記事では、その「違い」と、導入前に握るべきポイントを実務目線で整理する。
▼Claude Tagとは何か（3行で）
Claude Tagは、Slackのチャンネルに常駐するAIエージェントだ。誰かが @Claude でタスクを投げると、Claudeはそれを段階に分解し、接続されたツールを使って作業を進め、進捗のチェックリストをスレッドに出しながら結果を返す。やり取りはチャンネル全員に見える。
現時点ではClaude EnterpriseとClaude Teamプラン向けのbeta（リサーチプレビュー）で、Slackのみ対応。2025年10月から提供されていた旧「Claude in Slack」は、2026年8月3日にこのClaude Tagへ移行する。つまり既に旧連携を使っている会社は、放っておいても乗り換えが発生する。ここが今この話を整理しておくべき理由でもある。
▼一番のキモ：権限が「人」ではなく「チャンネル」に付く
ここが旧連携との最大の違いで、情シスが最初に頭を切り替えるべきポイントだ。
旧「Claude in Slack」は、タグした本人の権限で動いていた。あなたが @Claude すれば、Claudeはあなたの接続アカウント・あなたの権限でツールを叩く。誰の権限で動くかが「タグした人」で決まる、ごく素直なモデルだ。
Claude Tagはこれを捨てた。Anthropicが「エージェントアイデンティティ（Agent Identity）」と呼ぶ仕組みで、Claudeは誰の代理でもなく、自分自身のアカウント（サービスアカウント）でツールを叩く。Slackには「Claudeアプリ」として、GitHubには「Claude GitHub App」として投稿・操作する。借りログインではない。
「このユーザーは何ができるか？」ではなく、「このエージェントはこのチャンネルという区画の中で何ができるか？」で権限が決まる。権限スコープの単位が、人からチャンネルに移った。
管理者はまずワークスペース単位でベースとなるアイデンティティ（どのツールに繋ぐか、どんなスキルを持つか）を定義する。各チャンネルはそれを既定で継承し、必要に応じてチャンネル単位で上書きできる。たとえばエンジニアリングのチャンネルだけGitHubとデータウェアハウスへの書き込みを許可し、CRM接続はある1つのプライベートチャンネルに閉じ込める、といった具合だ。
クレデンシャルの持ち方も理解しておく価値がある。接続したツールの認証情報は「Agent Proxy」という仕組みが別管理していて、外部へリクエストが出る瞬間にネットワーク境界で注入され、許可されていない宛先への通信はそこで遮断される。モデル本体も、タスクを動かすサンドボックスも、生のクレデンシャルそのものは持たない設計になっている。
▼「便利そう」で終わる人と、ここで身構える情シスの差
この「権限がチャンネルに付く」という設計は、よくできている。個人クレデンシャルを借りないので、共有チャンネルが誰かの個人ドキュメントへの抜け道になることが構造的に起きない。情報の区画化（コンパートメント化）が効く。
ただし、よくできた設計ほど「設定した通りにしか守ってくれない」。便利さだけ見て雑にチャンネルへ招待していくと、こうなる。
権限がチャンネルに付くということは、そのチャンネルに招待された瞬間、招待された人や場には、そのチャンネルに紐づくアクセス権がそのまま乗るということだ。「とりあえず全チャンネルに入れとくか」をやると、本番デプロイ系のツールに繋がったエージェントが、雑談チャンネルや社外を含むチャンネルでも同じ権限で動ける状態が生まれる。招待のハードルと権限のハードルがズレる。
情シスとして握るべきは、この一点に尽きる。チャンネル＝権限スコープ。だから招待ルールを先に決める。これを後回しにすると、権限の棚卸しが地獄になる。
▼導入前に握るべき4つの設計ポイント
| ポイント | なぜ重要か | 具体アクション |
|---|---|---|
| ① チャンネル単位でスコープを絞る | 全チャンネル一律の広い権限は、攻撃面そのもの。サポートチャンネルに本番デプロイ権限はいらない。 | チャンネルごとに「その仕事に必要なツールとデータだけ」を割り当てる。ベースは最小、必要なところだけ上書きで広げる。 |
| ② チャンネル履歴に何が流れているか | Claudeは会話のコンテキストを読む。過去ログに秘密情報・顧客PII・認証情報が流れていると、それも読める。 | エージェントを入れる前に、そのチャンネルの履歴に機微情報が含まれていないか確認する。含まれるなら入れない、もしくは履歴を整理する。 |
| ③ リポジトリ接続＝書き込み権限 | リポジトリを繋ぐと、Claudeはそこに対して操作（PR作成等）ができる。読むだけではない。 | ブランチ保護とレビュー必須の設定が、Claudeが出す成果物にもちゃんと効いているか確認する。直pushできる状態にしない。 |
| ④ アンビエントモードは絞ってON | 能動的にチャンネルを監視・通知するモードは、入れる場所を間違えるとただのノイズ製造機になる。 | 全体ONにせず、効果が出るチャンネルだけ個別にONにしてチューニングする。 |
①〜④に共通するのは「広く繋いでから絞る」のではなく「最小から必要な分だけ広げる」という順番だ。Anthropic自身は「最初から寛大にアクセスを与えると価値が複利で効く」とも言っているが、これは監査ログを常時見られる体制が前提の話だ。情シスが少人数で回す中小企業では、先に絞っておくほうが事故が少ない。
▼50〜300名規模での、事故らない始め方
いきなり全社展開しない。情シスがひとりか少人数で運用する規模なら、次の順番で回すのが安全だ。
STEP1：プライベートチャンネルでパイロット
#claude-pilot のようなプライベートチャンネルを作り、2〜3人とClaudeだけを入れる。スレッド要約、常設の指示出し、アンビエントモードのトリガーなど、現実的なタスクを数件試す。
STEP2：監査ログで「想定通りか」を見る
Claude Tagは、どのクレデンシャルがいつ使われたか、誰が頼んだ作業かが監査ログに残る。パイロット期間中はこれを毎日見て、Claudeが想定したツールとデータにしか触っていないかを確認する。
- 接続スコープ：すべてのツール呼び出しが、許可したコネクタの範囲内だったか。範囲外（whitelist外のDriveフォルダ、対象外のリポジトリ等）への呼び出しが1件でもあれば、それは「なんとなく問題なさそう」では済まさず、ハードな失格として接続を見直す。
- チャンネルごとの利用量が、設定した上限の範囲に収まっているか。
- アンビエントモードの通知が、ノイズになっていないか。
STEP3：チャンネル招待ルールを文書化してから広げる
「どういうチャンネルに、どのアイデンティティを、誰の承認で入れるか」を1枚にまとめてから横展開する。このブログでは一貫して「ポリシーは運用が固まってから文書化する」という立場を取っているが、Claude Tagに関しては招待＝権限付与という性質上、運用ルールだけは展開より先に最低限決めておくべきだ。
▼コスト上限（spending limit）はセキュリティ機能ではない
導入時、組織の月次の利用上限（spending limit）を設定する。$100からUnlimitedまで選べて、既定は$1,000だ。$250〜$500あたりがパイロットの現実的なレンジになる。
ここで誤解しないでほしいのは、この金額はセキュリティのための数字ではないということ。セキュリティを担保するのはチャンネル単位の上限と監査ログであって、spending limitはあくまで「全社員が一斉にタグし始めたら請求がどこまで行くか」を止める財務上のサーキットブレーカーだ。安く設定したから安全、ではない。役割を分けて理解しておく。
▼まとめ
- ▶ Claude Tagは権限が「人」ではなく「チャンネル」に付く。ここの頭の切り替えが全て。
- ▶ 招待＝権限付与。だから招待ルールを展開より先に決める。
- ▶ ベースは最小権限。必要なチャンネルだけ上書きで広げる。
- ▶ チャンネル履歴の機微情報、リポジトリの書き込み権限、アンビエントの通知範囲を確認する。
- ▶ プライベートチャンネルでパイロット→監査ログで検証→招待ルール文書化→横展開。
- ▶ spending limitは財務のブレーキで、セキュリティ機能ではない。
AIエージェントをチャンネルに落とすこと自体は、もう驚くほど簡単になった。難しいのはその先——安全に、かつ実際に仕事を前に進める状態に組み上げるところだ。そしてそこは設計で決まる。便利さの裏で権限がどう動いているかを最初に握れる情シスがいる会社は、こういうツールを強みに変えられる。