Claude Tag管理者設定 — チャネル別アイデンティティとトークン支出制限
Claude Tagの管理者設定を、エージェントアイデンティティの仕組みからチャネル別アクセスの絞り込み、組織全体とチャネル単位の支出制限の設定手順まで解説します。
Claude Tag管理者設定は何を決める仕事か
Claude Tag(Slackの@Claude)の管理者設定は、大きく分けて2つの仕事です。1つはエージェントアイデンティティの設計 — Claudeがどのチャネルでどのツールに触れるかを決めること。もう1つは支出制限の設定 — Slackでの作業がいくらまで組織の利用残高を使えるかを決めることです。どちらもOwnerロールを持つ管理者がclaude.ai/admin-settings/claude-tagとclaude.ai/admin-settings/usage/claude-tagという別々のページで行います。
前提として、Claude TagはTeam・Enterpriseプラン向けの機能です。ただし管理者なら誰でも支出制限の設定ページにたどり着けるわけではありません。利用課金を有効にしていないトライアル組織、1席のTeamプラン、ハイブリッドのデスクトップ展開、請求を閲覧できないロールの管理者は、個人の利用設定へリダイレクトされます。請求をリセラー経由で行っている組織だけは利用ページ自体が使えず、利用残高はリセラー側で入金されます。
前提知識: エージェントアイデンティティの仕組み
Claude Tagはチャネルの中で、特定のユーザーの代わりにではなく、Claude自身のサービスアカウントとして動きます。SlackではClaudeアプリとして投稿し、GitHubではClaude GitHub Appとしてプルリクエストを作成し、その他の接続先では管理者が用意したサービスアカウントとして行動します。この身元はOwnerがセットアップ時に一度だけ発行し、以降はチャネルのメンバー全員が同じ権限で@Claudeを使います。
この設計には実務上の意味が3つあります。設定は1回で済み、チャネルのメンバー全員が同じ能力をすぐ使えます。誰が頼んだかによってClaudeにできることは変わりません。そして接続先のツールの監査ログには、管理者がすでに把握しているサービスアカウント名で記録が残ります。
ただし例外が1つあります。DM(ダイレクトメッセージ)ではこの仕組みが適用されません。DMにはチャネルという単位がないため、セッションはメッセージを送った本人のclaude.aiアカウントで動き、その人自身のコネクタと認証情報を使います。GitHubだけは例外で、DMからでもプルリクエストはClaude GitHub Appの名前で作成されます。DMを組織全体で無効にすることも可能です。
チャネルでの作業は、サンドボックス→Agent Proxy→接続先という経路をたどります。認証情報はサンドボックスにもモデルにも渡らず、Agent Proxyという境界でリクエストに注入される仕組みです。行き先が許可リストのどれにも一致しなければ、Claudeはブロックされたホスト名をスレッドで報告します。
ステップ1: チャネル別にアクセス範囲を絞る
Claude Tagの設定はスコープという単位で階層化されています。範囲が広い順に「Default Slack access(組織全体)」「ワークスペース」「チャネル」の3段階があり、狭いスコープは広いスコープの設定を継承したうえで上乗せします。
| スコープ | 適用範囲 | 典型的な使い方 |
|---|---|---|
| Default Slack access | 適用範囲全ワークスペース・全チャネル | 典型的な使い方全社共通で許可してよい接続(社内Wiki検索など) |
| ワークスペース | 適用範囲1つのSlackワークスペース内の全チャネル | 典型的な使い方部門単位で共通のツールを配る |
| チャネル | 適用範囲特定の1チャネル(公開・非公開とも) | 典型的な使い方機密データに触れる接続を1チャネルに閉じ込める |
Access bundle(アクセスバンドル)(接続情報・許可ドメイン・リポジトリ権限をまとめた単位)をどのスコープに紐づけるかで、実質的にチャネル別アイデンティティが決まります。あるチャネルが持つ権限は、Default Slack access・ワークスペース・チャネル自身に紐づいたバンドルの和集合です。狭いスコープは広いスコープを置き換えるのではなく、積み増します。
同じホストに対する認証情報が複数のバンドルに存在する場合は、最も狭いスコープのものが優先されます。フォールバックは無く、勝った認証情報が401や403を返してもClaudeは次の候補を試しません。同じスコープ内で認証情報が重複しないよう設計するのが安全です。
チャネル固有の指示(カスタム指示)は上書きではなく連結されます。Default Slack access→ワークスペース→チャネルの順で足されていくため、組織共通のルールを維持しつつチャネルごとの追加ルールを積める設計です。
まだclaude.ai/admin-settings/claude-tagの一覧に出てこないチャネルにバンドルを紐づける手順は次のとおりです。
- チャネルのスコープを作成する:
claude.ai/admin-settings/claude-tagのSlackタブでワークスペースを選び、Add channelからチャネルを指定します。公開チャネルは名前検索、非公開チャネルはSlack上のチャネルIDを貼り付けます。 - 保存してバンドルを紐づける: 保存すると新しいスコープが作られるので、そのスコープのAccess bundlesセクションでバンドルを選んで紐づけます。
非公開チャネルに機密性の高いバンドルを置く理由
公開チャネルに紐づけたバンドルは、そのチャネルに参加した全員に権限が及びます。多くのSlackワークスペースでは誰でも公開チャネルに参加できるため、実質的にはチャネルの参加ポリシーがそのままアクセス制御になります。金融データや人事情報に触れる接続は、非公開チャネルのスコープに限定するのが安全です。
スコープとバンドルの紐づけとは別に、Claude Tagにはチャネルへのアクセスそのものを絞る機能が4つあります。
| 機能 | できること |
|---|---|
| Restrict who can use Claude | できることTeamなら組織メンバーのみ、Enterpriseならロールで許可された人のみに@Claudeの利用を絞る |
| Limit Claude Tag to specific channels | できることパイロット導入などで、選んだチャネル以外ではClaudeを応答させない |
| Block or auto-join channels by name | できることチャネル名のパターンでブロック、または新規作成時に自動参加させる |
| Restrict guest channels | できることSlackゲストが含まれるチャネルでの応答を制限、または権限を絞った状態で許可する |
いずれもOwnerロールがclaude.ai/admin-settings/claude-tagで設定します。
Enterpriseプランでは、Owner以外にチャネルマネージャーという役割を割り当てられます。割り当てられたチャネルに限り、既定モデルやリポジトリ、認証情報・プラグインを管理できますが、バンドルの作成やスコープへの紐づけ自体はOwner専任のままです。
ステップ2: 支出制限(スペンドリミット)を設定する
チャネルでの作業は組織の利用残高に課金され、個々のユーザーの座席には課金されません。DMだけは例外で、送信者自身の座席の上限が適用されます。この区別は、既存のClaude Enterpriseのグループ支出上限が個人の座席単位の上限を扱うのに対し、Claude Tagの支出制限は組織の利用残高そのものを対象にする点で仕組みが異なります。Claude Code側の支出上限を確認したい場合はstatuslineのspend_limit表示が使えます。
Teamプランでは利用残高への入金が済むまでチャネルでClaudeは応答しないため、支出制限を設定する前に残高が入金済みかを確認する必要があります。Team・Enterprise向けのローンチプロモクレジットは入金済み残高として扱われるため、クレジットを別途購入する前に付与済みでないか確認します。Enterprise(請求書払い)では、支出制限を設定しない限り上限なしで請求書に積み上がるため、パイロット期間中の上限として設定することが推奨されています。
スペンドリミットの設定は次の2ステップです。
- 利用ページを開く:
claude.ai/admin-settings/usage/claude-tagにアクセスします。 - 組織の請求通貨で金額を入力する: 入力した上限は毎月初めにリセットされ、ペアリング済みの全ワークスペースに適用されます。金額はいつでも変更できます。
設定できる上限は3階層あります。
- 組織全体の上限: 全チャネル合計の支出に対する上限
- チャネルの既定上限: 個別の上限を持たないチャネルに適用される既定値
- チャネル別の上限: 特定のチャネルに個別に設定する上限。部門やチームごとにチャネルを分けていれば、そのままチームごとの予算として機能する
上限に達した作業は黙って打ち切られるのではなく、依頼者にスレッド上でその旨が伝えられます。依頼者は管理者に上限の引き上げを依頼できます。なお、スペンドリミットは定価で計算されるため、組織が値引き契約をしていても上限の判定には反映されません。値引きは請求時にだけ適用されます。
ユーザー別に費用を割り振る
利用ページで分かるのはチャネル単位の支出までです。Slackユーザー単位で費用を割り振るには、Enterprise Analytics APIを使います。この方法には2つの前提条件があります。Analytics APIが使えるのはEnterpriseプランの組織だけで、read:analyticsスコープを持つAPIキーは組織のprimary ownerしか発行できません。
curl --globoff "https://api.anthropic.com/v1/organizations/analytics/cost_report?\
starting_at=2026-09-01T00:00:00Z&\
ending_at=2026-09-08T00:00:00Z&\
group_by[]=claude_tag_user_id&\
products[]=claude-tag" \
--header "anthropic-version: 2023-06-01" \
--header "x-api-key: $ANALYTICS_API_KEY"claude_tag_user_idでグルーピングすると、依頼した人の投稿に基づいて支出が割り振られた行が返ります。誰の依頼でもない支出(他のbotが投稿したスレッドでClaudeが自発的に動いた場合など)はclaude_tag_user_idがnullの行にまとまるため、ユーザー別の合計はチャネル支出の総額より小さくなります。
よくあるつまずき
- レート制限とスペンドリミットを混同する: 支出制限に余裕があっても、多数のチャネルが同時に稼働していると「セッションのレート制限」に先に達することがあります。この場合はスペンドリミットを上げても解消しません。表示された待ち時間の後に再送信するのが正しい対処です
- プロモーションクレジットの表示を支出0円と誤読する: プロモーションクレジットで賄われている支出は利用ページ上で0円と表示されます。実際の定価ベースの支出を追うには、Analytics側の「Spend by channel」テーブルの「List price」列を見る必要があります
- モニタリングを課金対象と誤解する: Claudeが参加しているチャネルを読むだけの動作(誰にもタグ付けされていない状態での監視)は課金されません。課金されるのは、誰かに依頼された作業(Engaged)・Claudeが自発的に始めた作業(Proactive)・定期実行(Scheduled)の3種類です
- 個人単位の上限を探して見つからない: チャネル作業に個人ごとの支出上限を設定する機能は存在しません。上限は組織全体とチャネル単位にしかかけられず、個人の使いすぎを抑えたい場合はチャネルを分けて上限を割り当てる設計にする必要があります
- チャネルマネージャーがOwnerの認証情報を削除できてしまう: 相互TLSやAWS/GCPのサービスIDのような「Claudeの持つ識別情報」を使う認証情報は、チャネルマネージャーが新規作成・変更・ローテーションはできませんが、削除だけはできてしまいます。削除されるとOwnerが認証情報を戻すまでその接続先へのアクセスが失われます
まとめ
Claude Tagの管理者設定は、チャネル別アイデンティティ(誰が何にアクセスできるか)と支出制限(いくらまで使えるか)という独立した2つの軸で構成されています。前者はclaude.ai/admin-settings/claude-tag、後者はclaude.ai/admin-settings/usage/claude-tagと設定画面自体が分かれているため、どちらか一方だけ設定して終わったつもりになりやすい構造です。新しくチャネルを追加するたび、または新しい部門にClaude Tagを展開するたびに、この2つを両方確認する運用が安全です。
Claude Tagの機能自体の全体像はClaude Tagが登場、個人プラン向けの旧方式との違いはClaude TagとClaude Code in Slackの違い、設定の入口から使い方までの全体的な流れはClaudeとSlackの連携にまとめています。