ベータ機能の「Claude Tag」を整理してみた
こんにちは、コンサルティング部のみゃんです！
最近Claude Enterpriseの組織設定コンソールを見ていてふと見慣れない機能がありました。
そう「Claude Tag」です。
安直にタグ付けの機能なのかなと思いきや、調べてみるとSlack上でClaudeが使える？？
何やら便利そう、面白そうな機能だなと思い、公式ドキュメントをもとに調べた内容を整理してみました。
前提としてこの記事では利用者はSlack上でClaude Tagを実際に使う人、管理者はClaude EnterpriseのOwner/PrimaryOwnerロールを持っている人のことを指します。
Claude Tagとは
Claude Tagは、Slackのチャンネルに @Claude とメンションするだけでタスクを渡せるエージェント機能です。渡されたタスクはAnthropicがホストするサンドボックス上で処理され、結果はスレッドに投稿されます。利用者側で何かをインストールする必要はありません（詳細は公式ドキュメントをご確認ください）。
提供プランはTeam・Enterprise限定で、Free/Pro/Maxの個人プランやサードパーティ提供では利用できません。また本記事執筆時点ではパブリックベータ機能のため、仕様は正式リリースまでに変更される可能性があります。前提条件の詳細は公式ドキュメントをご確認ください。
Claudeには他にもCoworkやClaude Codeがありますが、住み分けはシンプルで、「チームの共有作業はClaude Tag、個人の作業はCoworkやClaude Code」という整理になっています。Claude Tagはチャンネルの全員が同じサービスアカウント権限で動く一方、Cowork/Claude Codeは各個人のOAuthコネクタやローカル権限を使う点が大きな違いです（詳しい比較はこちら）。
課金面では、Slackへの追加自体にシート課金は発生しません。チャンネル・スレッドでの作業は組織の使用量残高（usage balance）から消費される形で、上限（spend limit）を設定できます。DM（個人チャット）は組織のspend limitとは別に、利用した個人のシート課金に従います。課金の仕組みの詳細は公式ドキュメントをご確認ください。
Claude Tagの権限の仕組み
ここからが本題です。Claude Tagを安心して導入するために押さえておきたいのが、「誰の権限で動くのか」「どこまでアクセスできる設定なのか」という権限の設定です。
Agent Identity: 個人の権限を引き継がない
Claude Tagがチャンネル内で外部サービスにアクセスする際、メンションしたユーザー個人の権限を引き継ぐことはありません。Slack上ではClaudeアプリ、GitHub上ではClaude GitHub App、それ以外の連携先では組織のOwnerが用意した専用のサービスアカウントとして振る舞います。
Claude Tagの利用を許可されているメンバーの間では、「誰がメンションしたか」によって外部サービスへのアクセス範囲が変わることはありません。同じチャンネルでは、Claude Tagはそのチャンネルに適用された共通のAccess Bundleを使います。
なお、Claude Tagを呼び出せるメンバー自体は、組織のMember Access設定で制限できます。
自分はClaude君という新入社員が入社してきて、Slackチャンネルに1社員として参加している、なぜかみんなからメンションされて色々な面倒ごとを依頼されてるんだなーというイメージで捉えています。（個人の妄想です。）
Access Bundleについて
権限は「Access Bundle」という単位でまとめて管理します。Access Bundleは、認証情報・許可ドメイン・リポジトリアクセス・プラグイン・手順をひとまとめにした名前付きのセットで、組織のOwnerが作成します。1つのバンドルを複数のScope（適用範囲）に使い回すこともできます。
Glossary - Claude.ai Documentation
認証情報タブでは、Claude Tagが接続する外部サービスを設定します。
各サービスごとに接続方法は異なります。
以下は「 Datadog」を選択した画面ですが、「API Key」と「application key」の入力する欄があります。
後述するように、Claude Tagは各外部サービスごとに専用アカウントを作成するため、DatadogにClaude専用のアカウントを作成し、上記2つのキーを取得して、登録する必要があります。
その他、各サービスごとの接続の仕方は公式がガイドを出しているので、ご確認ください。
Per-service connection guides - Claude.ai Documentation
リポジトリタブでは、AccessBundleにGitHubのリポジトリを紐づける際の設定画面です。
前提としてGitHubの組織所有者が、以下の手順に従ってGitHubとClaudeを接続する必要があります。
Configure GitHub access - Claude.ai Documentation
ドメインタブは、ClaudeTagがネットワークリクエストを送る際に、許可するホスト名を設定できます。
例：example.com
またサービス側が443番以外のポートで待ち受けている場合は、ポートの指定が必要となります。
事前に全ての通信を予測して、登録しておく必要はなく、リクエストがブロックされると都度スレッドにホスト名とブロックされた旨が通知されるので、必要に応じてドメインタブにホスト名を追加して、通信を許可すればOKです。
Give Claude access to your tools - Claude.ai Documentation
Give Claude access to your tools - Claude.ai Documentation
この他にもプラグインを追加したり、システムプロンプトを設定することができます。
AccessBundleはSlack上の次の3つの場所に紐づけることで、認証情報を分離することができます。
- 組織全体（Default Slack access)
- ワークスペース単位
- チャンネル単位
Security and data handling - Claude.ai Documentation
何が嬉しいのかというと、公開範囲を限定したい認証情報を含むバンドルを特定のプライベートチャンネルにのみ紐づけることで、認証情報を分離することができる点です。
Claude Tagはリクエストを送る利用者のアカウントではなく、接続先の各外部サービス後にClaude Tag専用のアカウントを作成し、前述のようにそのアカウントを使用して認証情報を取得、設定することで様々なサービスと連携させることが可能です。
接続する各サービスごとの専用アカウントの作り方は2パターンあり、Claude専用のメールアドレス（claude@yourcompany.com のようなもの）を作って各サービスに招待する方法と、サービス側が提供するサービスアカウント機能をそのまま使う方法があります。どちらを使うかはサービスの仕様次第です。
Agent Proxy: サンドボックスに鍵は渡らない
Claude Tagが実際にタスクを処理するサンドボックスには、認可情報（クレデンシャル）が一切置かれません。クレデンシャルは専用のクレデンシャルストアに保管されていて、リクエストが許可ルールに一致した時だけ、「Agent Proxy」というネットワーク境界のレイヤーがその場でクレデンシャルを注入します。モデル自身にも鍵は渡らない設計です。
また先ほども少し触れたように、ネットワークアクセスはデフォルトで拒否（default-deny）されており、コネクションの許可ホスト・バンドルのDomains設定・実行環境のネットワークアクセス設定のいずれかに一致しない通信先へは、そもそも到達できません。
監査ログでどこまで追跡できるか
権限モデルとあわせて気になるのが、「実際に何をしたか、あとから追跡できるのか」という監査ログの話です。公式ドキュメントによると、Claude Tagのアクティビティは以下の4か所で確認できます。
- 組織設定のAudit画面（Scheduled work / Memory / 有効化されていればNetwork eventsの3タブ）
- 各スコープのメモリファイル
- 接続先ツールでの各アクション（Slack投稿はClaudeアプリ名義、GitHubのコミット/PRはClaude GitHub App名義）
- 接続された各サービス自体の監査ログ（サービスアカウント名義で記録される）
Audit画面の3タブにそれぞれ何が記録されるかは以下の通りです。
| タブ | 記録される内容 | 記録の粒度・注意点 |
|---|---|---|
| Scheduled work | 組織内の全ルーチンの一覧。詳細表示・一時停止/再開・削除が可能 | ルーチン単位の記録。作成者（Created by）は確認できるが、単発タスク1件ごとに「誰が・いつ・何を依頼したか」を記録する逐次ログではない |
| Memory | 各スコープのメモリファイルへのリンク。保存内容を閲覧・編集・削除（Owner）可能 | スコープ単位。会話履歴やセッションそのものの完全な記録ではなく、Claudeが保存した「事実・メモ」の実体 |
| Network events | Agent Proxy経由の外向き通信のJSONエクスポート（1時間単位） | GitおよびMCP経由の通信は対象外。組織でこの機能が有効化されている場合のみ表示される（有効化にはアカウントチームへの申請が必要） |
画面のイメージです。（実際のログがどんな形なのかは確認次第、更新予定です。）
Network eventsタブの有効化条件など、各タブの詳細な仕様は公式ドキュメントをご確認ください。
ここで一点、実務でも誤解しやすいポイントがあります。Audit画面のページ自体には「誰が・いつ・何を依頼したか」を1件ずつ記録する逐次ログはありません。
There is no per-action log of every task and who asked.（タスクごと、およびタスクを依頼したユーザーごとのログはありません。）
一方でサポート記事には「各アクションは、発生したツールで追跡可能」とも書かれています。
- GitHubは、コミット/プルリクエストが起点となったSlackスレッドへの自動リンクを持っているため、そこから依頼のやり取りを辿れます。
- それ以外の連携先（Jira、Notionなど）は、アクションがClaude Tag専用のサービスアカウント名義で記録される、というところまでが公式に確認できる範囲です。依頼者とアクションを結びつけるには、Slackスレッドの閲覧や、接続先サービス側の監査ログとの手動の突き合わせが必要になります。
また、Claude Tagはチャンネルメモリとセッションのトランスクリプトを保持する仕様のため、Zero Data Retention（ZDR）を有効化している組織では利用できない点も、監査・データ保持の観点で押さえておきたいポイントです。詳細や最新の対応状況は公式ドキュメントをご確認ください。
導入するメリット
権限とログの話が長くなりましたが、Claude Tagそのもののメリットにも触れておきます。
前述の通り、Slackへの追加自体はシート課金の対象外です。管理者が一度Access Bundleを設定してチャンネルにアタッチすれば、そのチャンネルにいるメンバー全員が個別のセットアップなしですぐに使い始められます（詳細は公式ドキュメント）。
公式のユースケースライブラリには13種類のユースケースが掲載されていて、たとえば以下のような使い方が紹介されています。
- Catch up: スレッドやチャンネルの要約（追加の接続不要）
- Triage requests: 問い合わせの一次対応・重複検知・振り分け
- Turn threads into docs and tickets: 議論からドキュメント/チケットを自動生成
- Track projects and chase approvals: プロジェクト状況の定期報告・承認の催促
- Find answers in your docs: Google Drive/Notion/Confluence連携でのドキュメント検索
- Fix bugs: GitHub連携でのバグ再現・PR作成・CI追跡
- Watch monitors and alerts: Datadog/Sentry/PagerDuty連携での監視
- Pull deal and account state: Salesforce/HubSpot/Gong連携での商談状況確認
セキュリティ面でも、前段で紹介した通りサンドボックスは認可情報を一切保持せず、ネットワークアクセスはデフォルトで拒否され、チャンネルごとにクレデンシャルを分離できる設計になっています。権限・ログの仕組みを理解した上で導入すれば、チームの共同作業を安心して任せられる機能だと感じています。
まとめ
Claude Tagは「誰の権限で動くか」「どこまでログに残るか」を理解した上で導入すると、権限周りの不安をかなり解消できる機能だと感じました。ポイントを振り返ると以下の通りです。
- チャンネル内では個人の権限ではなく、専用のサービスアカウント（Agent Identity）として動作する
- 権限はAccess Bundleという単位でまとめて管理し、Slackの組織/ワークスペース/チャンネルにアタッチして配る
- サンドボックスに認可情報は置かれず、Agent Proxyが境界でのみクレデンシャルを注入する
- 監査ログは4か所に分散していて、依頼者単位の逐次ログはAudit画面には無い。GitHubは自動リンクあり、それ以外は手動の突き合わせが必要
パブリックベータの機能なので、今後仕様が変わる可能性は十分にあります。導入を検討される際は、都度公式ドキュメントで最新の仕様を確認することをおすすめします。今回の整理が、同じように導入を検討されている方の参考になれば幸いです。
参考情報
- https://claude.com/docs/claude-tag/overview
- https://claude.com/docs/claude-tag/admins/setup-overview
- https://claude.com/docs/claude-tag/concepts/how-it-works
- https://claude.com/docs/claude-tag/concepts/agent-identity
- https://claude.com/docs/claude-tag/concepts/glossary
- https://claude.com/docs/claude-tag/concepts/security-and-data
- https://claude.com/docs/claude-tag/admins/add-connections
- https://claude.com/docs/claude-tag/admins/audit
- https://claude.com/docs/claude-tag/users/use-cases
- https://support.claude.com/en/articles/15594475-what-is-claude-tag
