塞げる穴と、
塞げない穴

「一度開けたら、止まらないのでは」

社内で AI 活用の話をすると、ほぼ必ずこの形の問いが出ます。 私自身も、最初は同じところで引っかかりました。要約すると、こうなります。

もっともな心配です。そしてこの懸念には、当たっている部分と外している部分が混ざっています。 外している部分を放置すると「だから禁止」という結論になり、 当たっている部分を放置すると本当に危ない経路が野放しになります。 どちらも困るので、順に切り分けます。

先に結論を置きます。論点は「Slackのアプリ承認設定」だけでは閉じません。

まず、別物を3つに分ける

議論が噛み合わない原因の大半は、名前が似ている別物を同じものとして話していることです。 データの流れる向きが違うので、統制のかけ方も変わります。

提供側は「管理者承認が前段」で設計している

Anthropic の公開情報を読むと、管理者承認を通ってから個人が認証するという順序が明記されています。

つまり「承認不要で個人契約が勝手に繋がる」という理解は、提供側の仕様上は当たりません。 権限の範囲も、そのユーザーが元々見られるチャンネルを超えません。 AIを繋いだからといって、見えないチャンネルが見えるようになるわけではない——ここは安心してよい部分です。

ただし、その前提が成立しているとは限らない

問題は次です。Slack 側のヘルプは、冒頭でこう書いています。

ここが本題です。Anthropic の言う「管理者承認が必要」は、 Slack 側で承認機能が有効になっていることを暗黙の前提にした記述です。 その前提が成立していなければ、アプリのインストール権限を持つメンバーが自分で追加できてしまいます。

したがって、冒頭の懸念はSlack のデフォルト設定については当たっているということになります。 取り違えやすいのは、これを「AI提供側の作りが緩い」と読んでしまうところです。 実際に緩いのは提供側ではなく自社の初期設定のほうで、 そのままなら統制は効いていない——ここが当たっていた部分でした。

ここは順番が逆だと結論も逆になります。提供側の問題だと読むと「使わせない」に向かい、 自社の設定の問題だと読むと「設定を直す」に向かいます。 そして後で見るとおり、効くのは後者だけです。

データが外部AIに届く経路は3つある

ここからが本題です。設定の話に見えていたものを、経路の話に置き換えます。 Slack のデータが外部のAIに届く道は、大きく3本あります。

経路 C が厄介なのは、悪意の有無と無関係に成立してしまうところです。 Slack から見れば、そこで起きているのは 「正規のユーザーが、正規の権限で、自分の画面を見ている」という事実だけです。 そもそもアプリですらないので、アプリ承認という仕組みが仲介する対象に入りません。

そして、いちばん見落とされる点。経路Cは、あなたが何も導入しなくても、すでに存在しています。 ブラウザと目とキーボードがあれば成立するからです。これがシャドーAIの本体です。

なぜ「設定で塞げる穴」と「塞げない穴」に分かれるのか

この分かれ方には名前がついています。Saltzer と Schroeder が 1975 年に書いた 「The Protection of Information in Computer Systems」という論文です。 欠陥のないシステムの作り方は誰も知らないので、代わりに欠陥の数と深刻さを減らす8つの設計原則に頼る—— という立て付けで、8原則が並んでいます。今回関係するのは2つです。

原則2: Fail-safe defaults（安全側に倒れる既定値）

Slack の既定（承認なしでインストール可）は、この原則に反した状態です。 ただしこれは設定で埋められる穴です。原則違反が明確なぶん、直し方も明確です。

原則3: Complete mediation（完全仲介）

アプリ承認という参照モニタは、OAuth の認可を与えるという一点にしか置かれていません。 経路 C はそこを通らないので、仲介の対象外です。 これは設定では埋められません。穴が空いているのではなく、 そもそも監視員が立っていない場所を通っているからです。

5問で、いまどの経路が開いているかを見る

ここまでの構造を、自分の組織に当てはめてみてください。 分からない項目は「分からない」を選んでください。 「分からない」は無回答ではなく、それ自体が結果です—— 誰も把握していない統制は、実務上は効いていないのと同じ扱いになります。

順番がある

社内提案の筋立て（案）

• 現状、Slack のアプリ承認は既定で無効の可能性が高く、統制が効いていない
• AI提供側は管理者承認を前提に設計しているが、その前提が自社で成立しているかは未確認
• まず「承認済みアプリを必須とする」を ON にし、承認権限者を明確化する（コスト小・即効）
• その上で、公式に承認したAI連携経路（法人契約経由）を用意する
• 経路C（個人端末・ブラウザ経由）は別レイヤーの統制課題として切り出し、エンドポイント統制側で議論する
• 禁止ではなく「監査可能な公式経路の提供」が、シャドーAIを抑制する最も実効的な手段である

Claude Tag の権限モデル

経路A に乗る bot 型（Claude Tag）を検討する場合、権限モデルは押さえておく価値があります。 「AIを入れる＝統制が緩む」とは限らないことが分かるからです。

• アクセス範囲は3階層で指定します——組織全体／ワークスペース（全パブリックチャンネル）／プライベートチャンネル個別。 上位を継承しつつ、下位で足せる形です。
• 記憶はチャンネルとワークスペース単位でスコープされます。 管理者はその記憶を閲覧・編集・削除できます。営業用に設定したものが、 エンジニアリング用に記憶を引き継ぐことはありません。
• トークン支出の上限を組織全体・チャンネル個別に設定でき、75%・95% で警告が出ます。 上限を超える作業は拒否されます（黙って途中で切られることはない）。
• 全行動ログを閲覧できます。組織内のすべての定期・単発タスクと、 エージェント固有の識別子で行われたネットワーク呼び出しが対象です。
• セットアップは Primary Owner または Owner のみ。Admin 権限では設定できません。 権限設計の話をするとき、ここを取り違えると「誰が決めるのか」で止まります。
• メンバーアクセスは3モード——Slackワークスペースの誰でも／AI組織のメンバー／ロールが許可するメンバーのみ。 3つ目のロールベースは Enterprise プラン。

見ての通り、ログ・上限・スコープという統制の道具は用意されています。 経路A は、統制が効かない道ではなく統制の道具が揃っている道です。 効かないのは、道具を使っていないときだけです。

ここから先は、自分の組織を見に行くしかない

この整理でできたのは論点の形を作るところまでです。 以下は公開情報では決まらず、自組織の実測でしか埋まりません。

• 自社 Slack の「承認済みアプリを必須とする」の現在の設定状態（推測せず、画面を見る）
• 自社の Slack プランが、その AI 連携の対象（有料プラン）か
• AI側の契約形態——法人契約か、個人契約が混在しているか
• 経路Cに対する現行のエンドポイント統制の実効範囲
• Slack のセッション管理・EMM 設定で、経路Cをどこまで狭められるか（プラン依存のため要確認）

一次情報