COLUMNS

TOP > COLUMNS
Slack常駐AIで生産性を上げるには、権限設計を先にすべき
2026.06.24 AIガバナンス

2026年6月23日、AnthropicがSlackで動くAIエージェント「Claude Tag」を発表しました。@Claudeと打てば呼び出せるだけでなく、指示が無くてもチャンネルをまたいで情報を集め、止まった作業に自分から追いつきます。同じ時期、Claude Codeのサブエージェントは5階層まで分岐できるようになりました。どちらも業務を速くします。ただ、常駐させる前に利用企業が決めることがあります。誰の権限で、どこまで読み、何を実行したかを、後から追えるかどうかです。

指示なしで動くAIが業務に入る

これまでのAIアシスタントは、人が質問して初めて動きました。Claude Tagはそこが変わります。Anthropicの説明では、ambientモードのClaudeは、チームに最新状況を伝え、組織の各所から関連する話題を拾い上げ、放置されたスレッドや作業に自分から追いつきます。

管理者が許可すれば、Claude Tagは複数のチャンネルから事実を自動で集めます。人が見ていない時間に、人が指示していない範囲で、AIがメッセージを読み、まとめ、投稿するということです。

これは構想ではありません。Anthropicの公式発表は「現在、当社プロダクトチームのコードの65%は、社内版のClaude Tagが生成している」と書いています。コードだけでなく、製品指標やデータの確認、サポートチケットの処理、バグの原因究明にも@Claudeを使うと説明します。タグ付けが、社内で仕事を進める主要な手段になっています。

Claude Tagとサブエージェント、確認できる二つの仕様

Claude TagはClaude EnterpriseとClaude Teamのベータとして提供されています。チャンネルを横断した情報収集は管理者の許可が前提で、どのツールやチャンネルに各Claudeがアクセスできるかは管理者が決めます。読める範囲を決めるのは利用企業です。

管理側の手当ても用意されています。公式発表によれば、管理者は組織単位とチャンネル単位でトークン消費の上限を設定でき、「@Claudeが行ったすべての操作のログを、誰が各タスクを依頼したかと併せて」確認できます。操作ログはプラットフォーム側に既にあります。問題は、それを使う前提でアクセス範囲を絞っているかどうかです。

もう一方のサブエージェントは、開発の現場で似た構造を作ります。メインの会話の下に専門のサブエージェントを置き、そのサブエージェントがさらに別のサブエージェントを呼びます。Claude Code公式ドキュメントによれば、v2.1.172以降、この入れ子は深さ5まで届きます。

ここで運用に直結する一文があります。ドキュメントは「中間の出力はメインの会話に届かない。あなたに返るのは最上位サブエージェントの要約だけ」と書いています。さらに「深さ5のサブエージェントはAgentツールを受け取らず、それ以上分岐できない。この上限は固定で変更できない」と続きます。

深さ5で打ち止めなのは、際限なく分岐するのを止める仕組みです。一方で、それより浅いところでは、各サブエージェントが何を読みどう判断したかが上位の要約に圧縮され、手元に来にくくなります。

人が見ていない時間と、追えない中間判断

二つの仕様は、業務に同じ落とし穴を持ち込みます。人が見ていない時間に動くことと、判断の途中がログに残りにくいことです。

Claude Tagでは、人が指示しなくてもAIがチャンネルを横断します。経理の議論を読んだAIが、別チャンネルの未公開の数字を「関連する事実」として要約に混ぜることが起こります。意図した共有ではなく、アクセス設定の甘さが情報の流れを作ります。誰がどの情報を見られるかの線引きを、AIに肩代わりさせた結果です。

サブエージェントでは、5階層の委譲で実装を走らせ、返るのは要約だけです。途中のサブエージェントがどのファイルを書き換え、どんな前提で判断したかは、要約に畳まれます。レビューしたいのは途中の判断ですが、そこが手元に来ません。

「うちは小さいから関係ない」と考える現場もあります。ただ、規模が小さいほどチャンネルの権限設計は雑になりがちで、AIに広く読ませがちです。常駐させる範囲が狭いうちに線を引くほうが、後から絞るより楽です。

絞ったチャンネルの中身が、そもそも見えていない

読める範囲を絞るとき、たいていは「どのチャンネルを見せるか」で考えます。ただ、チャンネルを選んでも、その中に何が積もっているかは別の話です。Slackには何年分ものやり取りが溜まります。契約書の写し、取引先の名前、まだ公開していない数字、パスワードらしき文字列が、スレッドの奥やDM、添付ファイルに紛れています。どのチャンネルにどんな機密が入っているかを、運営側が答えられないことがあります。

実際に相談を受けた現場でも、ここで止まりました。AIをSlackに繋ぐ話は進むのに、そのSlackに何が入っているかは誰も答えられません。理想は、過去ログを全部引き出して中身を検査し、機密の含まれるチャンネルを仕分けることです。ただ、量が多く、形式もメッセージ・スレッド・添付・DMとばらばらで、全部を洗うのは容易ではありません。何が入っているかを管理できていない状態のまま、AIだけが先に全部を読みます。

そのため「チャンネル単位で権限を絞った」だけでは、絞ったことになりません。現実的には、常駐AIを既存のSlack全体に向けず、入るものを自分で管理できる新しい範囲(専用チャンネルやワークスペース)に寄せ、過去の蓄積は棚卸しが済むまで読ませない、という切り分けになります。

常駐の前に決める三つ

自律的に動くこと自体を止める必要はありません。動かす前に、利用企業が三つを決めておきます。

  • 読める範囲を絞る:Claude Tagに見せるチャンネルを、全社一律ではなく業務単位で許可します。「とりあえず全部読ませる」を初期設定にしない。見せると決めたチャンネルも、中身に何が積もっているかを棚卸ししてから繋ぎます。
  • 実行に人の承認を挟む:外部への投稿やコードの反映、データの書き換えなど、後戻りしにくい操作は、AIの自律判断で完了させず、人の確認を一段入れます。
  • 残っているログを実際に使う:Claude Tagは「誰が依頼し、@Claudeが何をしたか」のログを持っています。記録があることと、それを定期的に見て異常を拾うことは別です。誰がいつ点検するかを決めて、初めて記録が監査に効きます。要約しか返らないサブエージェントでは、なおさら手前の操作ログが頼りです。

これらはツールの欠陥ではなく設計です。アクセス範囲もログもベンダーが代わりに決めません。利用企業が設定しなければ、初期値のまま動きます。自律化を、ツール選定ではなく自社の運用設計の問題として持てるかどうかが分かれ目です。

参考・一次ソース

■お問い合わせ

自律的に動くAIを業務に常駐させる前に、どのチャンネルまで読ませるか、どの操作に人の承認を挟むか、誰が何をしたかをどう記録するか。この線引きを自社の運用にどう落とすか手が回らないときは、アハクラフトにご相談ください。

お問い合わせ