title: "Claude TagがSlackに常駐｜AIを社内チームの一員にする導入設計と権限・ガバナンスの勘所" description: "Anthropicが2026年6月23日に発表したClaude Tagは、@ClaudeでSlackに常駐し永続メモリと管理者定義のツールアクセスで非同期に働くAIエージェントである。チャンネル別権限、データ境界、監査、旧Slackアプリ終了(8/3)の移行注意まで、社内導入のガバナンス設計を実務目線で整理する。" keyword: "Claude Tag Slack AIエージェント 社内導入 権限 ガバナンス 監査" slug: "claude-tag-slack-resident-ai-governance-20260625" date: "2026-06-25" updatedAt: "2026-06-25" category: "AI・DX" tags: ["Claude Tag","AIエージェント","Slack","ガバナンス","社内導入"] author: "GXO株式会社" lead_summary: "SlackにClaude Tagが常駐する時代の本丸は便利さではなく、どのチャンネルで何を見て何を実行できるかの権限・情報境界・監査の設計である。旧アプリは8/3終了。"
Claude TagがSlackに常駐｜AIを社内チームの一員にする導入設計と権限・ガバナンスの勘所
結論：Claude Tagの本質は「便利なボット」ではなく「権限を持つ社内の一員」である
2026年6月23日、AnthropicはSlackに常駐するAIエージェント「Claude Tag」を発表した（公式発表「Introducing Claude Tag」）。チャンネルで @Claude とメンションすると、AIが会話を追い、過去の文脈を覚え、タスクを受けて非同期で作業する。チャットで質問に答えるだけのこれまでのAIとは設計思想が違う。
導入で最初に決めるべきは、モデルの賢さでも回答精度でもない。Claude Tagが「どのチャンネルに入り、どのデータを見て、どのツールを呼び、何を組織のアイデンティティで実行してよいのか」 という権限と情報境界の設計である。
押さえるべき1点：Claude TagはSlackに常駐する「メンバー」である。だから入社時の権限付与と同じ発想で、アクセス範囲・実行できる操作・監査ログを先に決める。
常駐型AIを「便利だから先に全社へ」ではなく、本番運用に耐える形で入れたい場合は、ガードレールや権限設計の実装まで伴走するFDE+による社内AI導入の伴走・体制構築が出発点になる。
Claude Tagの機能要点（公式発表ベース）
| 項目 | 内容 |
|---|---|
| 起動方法 | Slackチャンネルで @Claude とメンションして依頼 |
| 共有（マルチプレイヤー） | チャンネル内に1つのClaudeが存在し、誰もが作業状況を見て会話を引き継げる |
| 永続メモリ | 在籍するチャンネルの関連情報を覚え、毎回ゼロから説明しなくてよい |
| 組織アイデンティティ | ユースケース別にアクセス範囲とメモリを分けた、組織管理下のClaudeを持てる |
| 管理者定義のツールアクセス | どのツール・データに、どのチャンネルでアクセスできるかを管理者が指定 |
| 非同期作業 | タスクを渡すと、利用者は別作業をしている間にClaudeが進める |
| 能動的挙動（ambient） | 有効化すると、必要そうな情報の通知や、止まったスレッドの追いかけを自発的に行う |
| 提供範囲 | Claude EnterpriseおよびTeamプラン向けにベータ提供（Slackのみ） |
AI ASSESSMENT
PoC の前に「そもそも使えるか」を30分で見極めませんか？
情シス部門の稟議書作成をサポートする無料の30分壁打ち。費用対効果 試算シート・失敗要因チェックリストをその場で共有します。
なぜ「権限・情報境界の設計」が先で、活用は後なのか
従来のSlackボットは、呼ばれたときだけ単発で応答する道具だった。Claude Tagは違う。チャンネルに常駐し、過去ログを記憶し、接続したツールを介して実際に作業する。つまり、情報を「見続ける」存在であり、操作を「実行できる」存在 になる。
ここで企業のリスク構造が変わる。
| 論点 | 従来のSlackボット | Claude Tag（常駐エージェント） |
|---|---|---|
| 存在 | 呼ばれたときだけ起動 | チャンネルに常駐し会話を継続的に追う |
| 記憶 | セッション内のみ（ステートレス） | チャンネル・ワークスペース単位で永続メモリ |
| 情報の見え方 | その場の入力のみ | 在籍チャンネルの履歴・接続データを参照 |
| 実行 | 定型応答 | 管理者が許可したツールで実際に作業 |
| 境界 | アプリ権限で固定 | チャンネル設計とツール許可で都度変わる |
この変化を踏まえずに「とりあえず全社チャンネルに入れる」と進めると、機密チャンネルの文脈や、特定部署しか見てはいけない情報が、AIの永続メモリと作業範囲に流れ込む。情シス・セキュリティ・法務が本番審査で見るのは回答の賢さではなく、情報境界・権限逸脱・ログの再現性 である。だから設計が先、活用は後になる。
Claude Tagのガバナンスを支える公式の統制機能
Claude Tagは、常駐型ゆえのリスクに対して管理機能を用意している。公式ヘルプセンターで確認できる主な統制は次のとおり。
| 統制カテゴリ | 公式に確認できる内容 |
|---|---|
| 3段階のアクセス権限 | 組織全体の認証情報・リポジトリ／ワークスペース単位（組織権限を継承）／プライベートチャンネル単位（機微な接続を隔離）の3レベルで到達範囲を設定 |
| 組織アイデンティティ | Claudeは組織管理下の認証情報で「自身のアイデンティティ」のもとに動作。チャンネルでの作業は組織に、ダイレクトメッセージは個人アカウントに課金 |
| 監査追跡 | 活動は監査ログと、GitHubやSlackなど元ツール側の記録で追跡可能 |
| メモリ管理 | チャンネル・ワークスペース単位でメモリを保持。管理者は保存メモリを閲覧・編集・削除でき、Claude.aiの会話履歴とは分離 |
| ロールベースのアクセス | Enterpriseプランでは、ロールに応じて利用可否を制御（「Claude in Slack」権限を付与したカスタムロール経由） |
| 支出上限 | 組織全体のハードキャップとチャンネル別上限。75％／95％で閾値アラート、上限超過の作業は無言で打ち切らず明示的に拒否 |
| 設定権限 | セットアップはPrimary OwnerまたはOwnerロールのみ可能（一般Adminでは設定不可） |
これらは「機能がある」ことと「正しく設計して運用する」ことが別物だ。AIアセスメントや権限/境界の設計を伴走で行いたい場合は、AIアセスメントによる権限・情報境界の整理から着手すると、本番審査に耐える前提が固まりやすい。
設計チェックリスト：チャンネル別権限・データ境界・監査
社内導入の前に、最低限ここを決める。Claude Tagの設定画面で「埋める枠」を、自社の統制ルールに翻訳する作業である。
1. チャンネル別の権限設計
| 決めること | 具体例 | 失敗した場合 |
|---|---|---|
| どのチャンネルに入れるか | 業務支援・開発・サポートなど用途別に限定 | 機密チャンネルの文脈がメモリに混入 |
| ユースケース別アイデンティティ | 開発用Claudeと営業用Claudeを分離 | 1つのClaudeに権限とメモリが集中 |
| プライベートチャンネルの扱い | 人事・法務・経営は隔離または非接続 | 限定情報がAIの作業範囲に流入 |
| ロールベース制御 | 利用を許可するロールを限定（Enterprise） | 想定外の社員が高権限ツールを起動 |
2. データ境界とツールアクセス
| 決めること | 具体例 | 失敗した場合 |
|---|---|---|
| 3段階のどの層で許可するか | 組織／ワークスペース／チャンネルを使い分け | 不要に広い範囲へ認証情報を露出 |
| 接続するツールの最小化 | 必要なリポジトリ・SaaSのみ許可 | 不要な更新・外部送信が可能になる |
| メモリのスコープと保持 | 覚えてよい情報と消すべき情報を定義 | 機密が永続メモリに残り続ける |
| 個人情報・機密項目 | 顧客個人情報や金額の取り扱いを明文化 | 回答に見せてはいけない情報が混ざる |
3. 監査・上限・停止
| 決めること | 具体例 | 失敗した場合 |
|---|---|---|
| 監査ログの確認手順 | 監査ログとGitHub/Slack側記録の突合 | 事故時に「誰の依頼で何をしたか」追えない |
| 支出ハードキャップ | 組織・チャンネル別の上限と閾値アラート | 費用が想定外に膨らむ |
| 能動的挙動の可否 | ambientを有効化する範囲を限定 | AIが想定外のスレッドへ自発介入 |
| 権限・メモリの棚卸し | 退職者・異動・古い接続を定期点検 | 古い権限と記憶が残る |
重要：これらの「枠」を埋めるのは管理画面の操作だが、何を入れるべきかは自社の統制ルールに依存する。チャンネル設計・データ分類・承認フローは、ツール導入の前段で決める。
AIエージェントを業務システムに本格接続する設計に踏み込む場合は、AIエージェント開発と業務連携の設計、社内導入の体制づくりを伴走で進めるならFDE+による社内AI導入の伴走・体制構築が出発点になる。
旧「Claude in Slack」アプリ終了（8/3）の移行注意
公式ヘルプセンターによると、既存の「Claude in Slack」アプリは2026年8月3日にClaude Tagへ切り替わる。管理者はClaude Tag提供開始から30日の移行ウィンドウ内でオプトインする必要がある。
ここで注意すべきは、旧アプリと新Claude Tagでは設計が根本的に違う点だ。
| 観点 | 旧「Claude in Slack」 | Claude Tag |
|---|---|---|
| セッション | 個人ごとの単発・ステートレス | チャンネル共有・永続メモリ |
| 文脈 | 共有なし | チャンネル/ワークスペースで蓄積 |
| 実行 | 主に応答 | 管理者定義ツールで作業 |
| アイデンティティ | 個人利用中心 | 組織アイデンティティで動作 |
つまり「同じものの後継」ではなく、情報の見え方と実行範囲が広がる別物への移行 である。何も設計せずにそのまま有効化すると、これまで共有されていなかった文脈やツールアクセスが一気に常駐エージェントへ開く。移行前に、入れるチャンネル・接続ツール・メモリ範囲・ロール制御・支出上限を決めておくこと。逆に、移行ウィンドウ内に判断と設定が間に合わないと、旧アプリ停止後にSlack上のClaude利用が途切れる可能性がある。
移行の勘所：8/3の切り替えは「設定し直し」の機会である。便利さで急がず、権限・境界・監査の設計を済ませてからオプトインする。
FAQ
Q. Claude Tagはどのプランで使えますか。 A. 公式発表では、Claude EnterpriseおよびTeamプランの顧客向けにベータ提供。現時点ではSlack上での提供です。
Q. 永続メモリに会社の機密が残り続けるのが不安です。 A. メモリはチャンネル・ワークスペース単位でスコープされ、管理者は保存メモリの閲覧・編集・削除が可能とされています。さらに、機微なチャンネルは接続しない、プライベートチャンネルの接続を隔離する、といった境界設計を組み合わせます。
Q. 「誰の依頼で何をしたか」は追えますか。 A. 公式ヘルプセンターによると、活動は監査ログおよびGitHubやSlackなど元ツール側の記録で追跡可能とされています。チャンネルでの作業は組織に、ダイレクトメッセージは個人アカウントに課金されます。
Q. 費用が暴走しませんか。 A. 組織全体のハードキャップとチャンネル別上限を設定でき、75％／95％で閾値アラート、上限超過の作業は無言で打ち切られず明示的に拒否されるとされています。
Q. 「製品チームのコードの65％が社内版Claude Tagで生成」は本当ですか。 A. これはAnthropicが自社の社内利用について述べた主張です（Anthropic公式発表）。自社環境での再現性を保証するものではないため、自社のPoCで効果を測定してください。
Q. 設定は誰でもできますか。 A. セットアップはPrimary OwnerまたはOwnerロールのみが可能で、一般のAdminでは設定できないとされています。社内の権限保有者と情シスの連携が前提です。
この記事を読むべき人
- SlackにClaude Tagを入れたいが、権限・情報境界の設計から不安がある情シス・セキュリティ担当
- 旧「Claude in Slack」を使っており、8/3の移行で何を設定し直すか整理したい管理者
- AIを「社内チームの一員」として定着させたいが、ガバナンスの説明責任を求められている部門責任者
- PoCで便利さは確認したが、永続メモリ・監査・支出上限など本番運用の統制で止まっている担当者
GXOに相談するタイミング
- Claude Tagをどのチャンネル・どのツール範囲で許可するか、自社の統制ルールに落とせていない
- 永続メモリと情報境界の設計で、機密チャンネルの扱いに確信が持てない
- 8/3の旧アプリ終了までに、移行設計（権限・監査・上限）を間に合わせたい
- 社内にAIを「一員」として定着させる運用ルールと体制づくりまで伴走してほしい
GXOでは、社内AI導入の伴走・体制づくり（FDE+）、AIアセスメントによる権限・情報境界の整理、AIエージェント開発と業務連携を組み合わせ、「便利だが統制が効かない」状態を避けたAI常駐運用を支援します。まずは自社の準備度を測りたい場合は、AI導入診断（AIレディネス）や、本番接続前の準備度を点検するPoC・本番化レディネス診断から着手できます。常駐型AIを社内に広げる前に押さえるべき論点の全体像は、連載：AIエージェント導入前チェックリストで確認できます。
関連リンク
関連記事
- MCPにエンタープライズ認可レイヤが標準化｜AIエージェント本番化を阻むSSO・監査・per-request認可を解く
- 自律型AIエージェントの事故を横断レビューして導くガバナンス原則
- AIエージェントに社内システムを触らせる前に必要な認可・監査ログ・実行権限設計
参考資料
- Anthropic「Introducing Claude Tag」(2026-06-23) https://www.anthropic.com/news/introducing-claude-tag
- Claude Help Center「What is Claude Tag?」 https://support.claude.com/en/articles/15594475-what-is-claude-tag
本記事は2026年6月25日時点の公開情報をもとに作成。Claude Tagはベータ提供であり、仕様・提供範囲・移行スケジュールは変更される可能性がある。導入前に各社公式情報と自社の監査・統制要件を必ず確認すること。
SlackにAIを常駐させる前に、権限・境界・監査を設計しませんか
GXOでは、Claude Tagのような常駐型AIを社内に入れる前のチャンネル別権限、データ境界、監査ログ、支出上限の設計、そして「社内チームの一員」として定着させる体制づくりまで伴走します。
FDE+｜社内AI導入の伴走を見る 導入・ガバナンスを相談する
※ 情シス・セキュリティ・業務部門の同席歓迎 | 旧Slackアプリからの移行設計も相談可
