2026年6月23日、Anthropic（AI の Claude を作っている会社）が、Slack の中で Claude に仕事を頼める「Claude Tag」を出した。チャンネルで @Claude と呼びかけると、そのスレッドで実際に作業をして結果を返してくれる——いわば「Slack に常駐する同僚」だ。
触ってみると確かに便利だ。だが導入を任される立場なら、「便利そう」で終わってはいけない。この道具は「誰の権限で動くか」の考え方が今までと根本的に違っていて、そこを理解せずにチャンネルへ入れていくと、雑談のチャンネルからでも社内のシステムを書き換えられる、といった状態が知らないうちにできて、後から困る。
この記事は発表の翌日（2026年6月24日）に公開したものを、10月に書き直した。前半は IT に詳しくない総務・経営者の方でも読めるように書き、仕組みの名前や設定画面の話は後半の「担当者向け」にまとめた。6月から変わったことと、6月の本文の誤りは、「担当者向け」の手前にまとめている。
- ▶ Claude Tag で何ができるか（Slack のチャンネルで AI に仕事を頼む道具）
- ▶ これまでの Slack 連携と決定的に違う点（権限が「人」ではなく「チャンネル」に付く）と、その例外
- ▶ 入れる前に会社で決めておく4つ
- ▶ 50〜300名規模で事故を起こさずに小さく始める順番と、初期設定のままだと小さく始まらない点
- ▶ 月の上限額は「使いすぎ止め」で、安全のための設定ではないこと
▼何ができる道具か：Slack のチャンネルで頼むと、作業して結果を返す
Claude Tag は、Slack のチャンネルに常駐する AI だ。誰かが @Claude で仕事を頼むと、Claude はそれを段階に分け、会社が Claude につないだツール（Google ドライブや、プログラムのコードを置く GitHub など）を使って作業を進め、進み具合のチェックリストをスレッドに出しながら結果を返す。やり取りはチャンネルの全員に見える。
使えるのは Claude の法人向けプラン（Claude Team と Claude Enterprise）で、まだベータ版、対応しているのは Slack だけだ（10月時点）。Microsoft Teams には「近日対応」と予告されているが、時期は出ていない。
前からあった旧「Claude in Slack」は、2026年8月3日に Claude Tag へ切り替わった。Claude の契約と紐付けた Slack では、10月5日以降、旧アプリはチャンネルで返事をしない。旧連携のデータやツールのつなぎ込みは引き継がれず、管理者がつなぎ直すことになっている。旧連携を使っていた会社も、次の章の「新しい考え方」で設定し直すことになる。
▼今までと何が違うか：権限が「人」ではなく「チャンネル」に付く
ここが旧連携との最大の違いで、導入を任された人が最初に頭を切り替えるべきところだ。
旧「Claude in Slack」は、頼んだ本人の権限で動いていた。あなたが @Claude すれば、Claude はあなたがつないだアカウントで、あなたに見られる範囲・できる範囲でツールを操作する。誰の権限で動くかが「頼んだ人」で決まる、ごく素直な形だ。
Claude Tag はこれを捨てた。チャンネルでの作業では、Claude は誰かの代理ではなく、Claude 専用のアカウントでツールを操作する。Slack には「Claude アプリ」として投稿し、GitHub には「Claude 用の GitHub アプリ」として操作する。誰かのログインを借りるわけではない。
「この人は何ができるか？」ではなく、「Claude はこのチャンネルという区画の中で何ができるか？」で権限が決まる。権限の単位が、人からチャンネルに移った。
ただし10月時点では、例外が1つある。頼んだ本人が許可すれば、Claude はその人が自分の Claude につないだツール（カレンダーやメールなど）を、その人の依頼に限って使える。ほかの人の依頼でその人のツールが使われることはない。ただ、結果はチャンネルの全員に見える。Team プランでは最初から使える状態で、会社としてまとめて止める設定はない。
管理者はまず、会社の Slack 全体で「Claude をどのツールにつなぐか、何ができるか」の基本を決める。各チャンネルはそれを受け継ぎ、必要なチャンネルにだけ追加でつなぐ。たとえば、エンジニアのチャンネルだけに GitHub やデータの置き場への書き込みを許し、顧客管理のツール（CRM）は1つの非公開チャンネルだけに閉じ込める、といった形だ。
パスワードなどの「鍵」の扱いも知っておく価値がある。つないだツールの鍵は別の場所に保管されていて、Claude が外へ通信する瞬間にだけ差し込まれる。許可していない宛先への通信はそこで止まる。Claude 本体も、作業をする場所も、鍵そのものは持たない作りになっている。
▼便利さの裏で起きること：チャンネルに入れる＝権限を渡す
この「権限がチャンネルに付く」作りは、よくできている。管理者がつないだツールは誰かの個人の鍵ではないので、ほかの人が Claude を通して誰かの個人ファイルをのぞく、ということは仕組みの上で起きない（個人のツールは、その本人の依頼にしか使われない）。情報を区画ごとに分けて守れる。
ただし、よくできた仕組みほど「設定した通りにしか守ってくれない」。便利さだけ見て雑にチャンネルへ入れていくと、こうなる。
権限がチャンネルに付くということは、Claude がそのチャンネルに入った瞬間、そのチャンネルにいる人は、そのチャンネルに付いた権限を Claude を通して使えるということだ。しかも Claude をチャンネルに招待するのは、管理者でなくてもできる。「とりあえず全チャンネルに入れとくか」をやると、本番の環境を変えられるツールにつながった Claude が、雑談チャンネルでも同じ権限で動ける状態が生まれる。招待のハードルと、権限のハードルがずれる。
公開チャンネルなら、あとから入ってきた人も、入った瞬間から同じ権限を使える。強い権限は非公開チャンネルにだけ付ける。
社外のゲストがいるチャンネルや、他社と共有しているチャンネルでは、Claude は最初から返事をしない設定になっている（管理者が変えれば動く）。社外がからむチャンネルは、この初期の設定を変えるかどうかを、管理者が決める場面になる。
押さえるべきは、この一点に尽きる。チャンネル＝権限の範囲。だから「どのチャンネルに入れるか」のルールを先に決める。これを後回しにすると、「どこで何ができる状態か」の棚卸しが大変になる。
▼入れる前に会社で決めること：つなぐ範囲・過去のやり取り・コードの承認・自動の返事
① チャンネルごとに、つなぐ範囲を絞る
全チャンネルに同じ広い権限を持たせると、Claude が読んだ文章にまぎれた悪い指示に従ってしまったとき、被害の及ぶ範囲もそのまま全チャンネル分になる。問い合わせ対応のチャンネルに、本番の環境を変える権限はいらない。チャンネルごとに「その仕事に必要なツールとデータだけ」をつなぐ。会社全体の基本は最小にして、必要なチャンネルにだけ足していく。注意したいのは、10月時点では、最初につないだツールは何もしなければ全チャンネルで使える状態になることだ。つなぐときに、使えるチャンネルを先に絞る。
② そのチャンネルの過去のやり取りに、何が流れているか
Claude はチャンネルの会話を読んで仕事をする。過去のやり取りに秘密の情報・お客様の個人情報・パスワードなどが流れていれば、それも読める。Claude を入れる前に、そのチャンネルの過去のやり取りを確かめる。含まれているなら入れないか、先に整理する。もう1つ、Claude は自分が入っていない公開チャンネルも、キーワードで検索できる。Claude を入れるチャンネルだけでなく、公開チャンネル全体にパスワードなどが流れていないかも見ておく。
③ ソースコードの置き場をつなぐ＝書き込める
ソースコードの置き場（GitHub のリポジトリ）をつなぐと、Claude は読むだけでなく、変更の提案（プルリクエスト）まで出せる。「人のレビューを通らないと本番のコードに入らない」という設定が、Claude の出す変更にもちゃんと効いているかを確かめる。Claude が直接書き込める状態にはしない。
見落としやすいのは、変更の提案が Claude の名前で出ることだ。頼んだ本人は「他人の提案」として自分で承認できるので、「承認は1人でよい」設定のままだと、頼んだ人が1人で本番に入れられる。Claude の出す変更には、頼んだ人とは別の人の承認を求める設定にする。
④ 呼ばれなくても動く機能は、要るチャンネルだけに
Claude は、呼ばれていない投稿にも自分から返事をすることがある。この「自動で応答する」設定は、チャンネルごとにあり、最初からオンだ。オンのチャンネルでは、Claude はチャンネルの投稿を読み、答えを持っているときなどに自分から返事をする。入れる場所を間違えると、ただのノイズ製造機になる。だから、入れたチャンネルごとに「自動の応答を残すか、切るか」を決める。読むだけならお金はかからないが、呼ばれずに Claude が作業を始めると、その分は会社の利用額に入る。決まった時間の作業やチャンネルの見張りは、これとは別の機能（ルーティン）だ。
6月の公開時点では、この動きは「有効にすると動く」ものとして紹介されていて、この記事も「全体でオンにせず、効果が出るチャンネルだけ個別にオンにする」と書いた。今は最初からオンなので、「オンにする場所を選ぶ」から「切る場所を決める」に考え方が変わっている。
①〜④に共通するのは、「広くつないでから絞る」のではなく「最小から、必要な分だけ広げる」という順番だ。公式の使い方のコツには「チャンネルに広くつなぐほど、Claude が情報を組み合わせられて役に立つ」という趣旨の項目もある。だがそれは、Claude が何に触ったかをこまめに追える体制が前提の話だ。しかも10月時点では、Claude がした作業と頼んだ人を1か所で見られる記録はない。情シスがいない、あるいは少人数で回す会社では、先に絞っておくほうが事故が少ない。
▼小さく始める順番：非公開チャンネルで試す → 記録を見る → ルールを書いてから広げる
いきなり全社に広げない。情シスがひとりか少人数で回す規模なら、次の順番で進めるのが安全だ。
STEP1：非公開チャンネルで試す
#claude-pilot のような非公開チャンネルを作り、2〜3人と Claude だけを入れる。スレッドの要約、いつも同じ指示を出す作業、呼ばれなくても動く機能など、実際の仕事に近いことを何件か試す。
ただし、初期設定のまま導入すると、小さくは始まらない。導入の最後の画面では公開チャンネルを最低1つ選ぶ必要があり、「メンバーに知らせる」も最初からオンで、導入した瞬間に Claude が Slack の全員に「使えるようになった」と個別にメッセージを送る。試す段階では知らせる設定を切り、Claude が返事をするチャンネルを、管理者が選んだものだけに絞っておく（絞り方はプランで違う。後半に記載）。
STEP2：記録で「想定どおりか」を見る
試している間は毎日、Claude が想定したツールとデータにしか触っていないかを記録で確かめる。
10月時点の公式ドキュメントでは、Claude Tag の管理画面で見られるのは、決まった時間に動く作業・Claude が覚えている内容・外への通信の記録で、作業と依頼した人を一覧で見られる記録はない、とされている。だから、Claude の管理画面の記録に加えて、つないだ先のツール側の記録（Claude 専用のアカウントの名前で残る）と、Claude が出した変更の提案から元の Slack のスレッドへのリンクをたどって確かめる。
- Claude の操作が、すべて許可したツールとデータの範囲に収まっていたか。範囲外への操作が1件でもあれば、「なんとなく問題なさそう」で済まさず、不合格としてつなぎ方を見直す。
- チャンネルごとの利用額が、決めた上限の範囲に収まっているか。
- 呼ばれなくても動く機能の通知が、ノイズになっていないか。
STEP3：チャンネルに入れるルールを1枚にしてから広げる
「どういうチャンネルに、どの権限を、誰の承認で付けるか」を1枚にまとめてから横に広げる。このブログでは一貫して「ルールは運用が固まってから文書にする」という立場を取っているが、Claude Tag に関してはチャンネルに入れる＝権限を渡すという性質上、運用のルールだけは広げる前に最低限決めておくべきだ。
▼月の上限額：使いすぎ止めで、安全の設定ではない
導入するとき、会社として Claude Tag に月いくらまで使うか、の上限額を決める。チャンネルごとの上限も決められる。
何も変えずに進むと、上限は月 $2,500 になる。選択肢は $500 から上限なしまでで、好きな額も入れられる。お金の流れはプランで違う。Team プランは先にクレジットを買う前払いで、買うまで Claude はチャンネルで動かない。請求書払いの Enterprise プランは、上限を決めない限り請求に天井がない。試す間は上限を低めの額に決めておき、チャンネルごとの使用額を見ながら直す。額は導入する時点の画面で確かめてほしい。
ここで誤解しないでほしいのは、この金額は安全のための数字ではないということだ。安全を守るのは、チャンネルごとに絞った権限だ。記録は、その範囲が守られているかを後から確かめる道具になる。上限額はあくまで「全社員が一斉に Claude に頼み始めたら、請求がどこまで行くか」を止める、お金のブレーカーだ。安く設定したから安全、ではない。役割を分けて考えておく。
▼まとめ：自分の会社で確かめること
- ▶ 旧「Claude in Slack」を使っていたか。使っていたなら、Claude Tag で誰が何をつなぎ直したか
- ▶ Claude が入っているチャンネルの一覧と、それぞれに何がつながっているか（最初につないだツールが全チャンネルで使える状態のままになっていないか）
- ▶ Claude を入れたチャンネルと公開チャンネルの過去のやり取りに、パスワードやお客様の個人情報が流れていないか
- ▶ ソースコードの置き場で、Claude の出す変更に「頼んだ人とは別の人の承認」が要る設定になっているか
- ▶ 個人のツールをチャンネルで使うとき、投稿の前に本人が結果を確かめる使い方にしているか
- ▶ 導入時に「全員に知らせる」を切ったか。Claude が返事をするチャンネルを、管理者が選んだものに絞っているか
- ▶ 「自動で応答する」を、どのチャンネルで残して、どこで切るか
- ▶ 「どのチャンネルに、どの権限を、誰の承認で付けるか」のルールが、広げる前に1枚になっているか
- ▶ 月の上限額が決まっているか。そしてそれを「安全の設定」と取り違えていないか
AI をチャンネルに入れること自体は、もう驚くほど簡単になった。難しいのはその先——安全に、かつ実際に仕事を前に進める状態に組み上げるところだ。そしてそこは設計で決まる。便利さの裏で権限がどう動いているかを最初に押さえられる人がいる会社は、こういう道具を強みに変えられる。
6月の本文の誤り・確かめられなかったもの
・6月は「リサーチプレビュー」と書いたが、公式の表記は「ベータ版（Public Beta）」だった。10月時点もベータ版のままだ。
・6月は Anthropic が「最初から寛大にアクセスを与えると価値が複利で効く」と言っている、と書いたが、この言い方の出典は確かめられなかった。近いのは、公式の使い方のコツにある「広くつなぐ」という項目だ。
・6月に書いた上限額の選択肢・最初の額と、「試すならこのくらい」という額は、出典・根拠を確かめられなかったので外した。今の額は前半に書いた。
6月より後に変わったこと
・旧「Claude in Slack」は、6月は「8月3日に移行する」という予告の段階だった。8月3日に切り替わり、10月5日以降、紐付けた Slack では旧アプリはチャンネルで返事をしない。
・呼ばれなくても動く機能は、6月は「有効にすると動く」ものとして紹介され、この記事も「絞ってオンにする」と書いた。10月時点では、チャンネルごとの「自動で応答する」設定が最初からオンだ。
・10月時点では、社外のゲストがいるチャンネルや他社と共有しているチャンネルでは、Claude は最初から返事をしない（6月の本文は、事故の例に社外を含むチャンネルを挙げていた）。
・10月時点では、頼んだ本人の許可で、本人の個人のツールをチャンネルで使える（6月の本文は触れていなかった）。
6月の発表文と今のドキュメントが食い違うもの
・作業の記録。6月の Anthropic の発表文には「Claude がしたことすべてと、それぞれを誰が頼んだかの記録を管理者が見られる」とあり、6月の本文はそれをもとに書いた。10月時点の公式ドキュメントでは、作業と依頼した人を一覧で見られる記録はない、とされている。
▼担当者向け：仕組みと設定の詳細
ここから先は、実際に設定する担当者向けに、正式な名前と10月時点の公式ドキュメントの内容をまとめる。出典は Anthropic の発表（2026-06-23）、Claude Tag のドキュメント（claude.com/docs/claude-tag）、Claude のヘルプセンター、Claude for Slack の製品ページ（claude.com/claude-for-slack）。確認は2026年10月29日。製品はベータ版なので、画面や額は変わりうる。
前半の言い方と、実際の名前
| 前半の言い方 | 実際の名前 |
|---|---|
| ベータ版 | Public Beta（6月の本文の「リサーチプレビュー」は誤り） |
| 旧連携 | Claude in Slack（2025年10月提供開始。ドキュメントでは Legacy アプリ） |
| Claude 専用のアカウントで動く | agent identity（エージェントアイデンティティ）。Slack は Claude アプリ、GitHub は Claude GitHub App、他のツールは管理者が用意したサービスアカウント |
| 本人の個人のツールをチャンネルで使う | Personal connectors in channels |
| 会社全体の基本／チャンネルごとに足す | スコープ（Slack 全体・ワークスペース・チャンネルの3階層）と、そこに付ける接続（connection）・bundle |
| 鍵（パスワードなど） | クレデンシャル（認証情報） |
| 外へ通信する瞬間にだけ鍵を差し込む仕組み | Agent Proxy |
| 作業をする場所 | サンドボックス（環境） |
| Claude が読んだ文章にまぎれた悪い指示 | プロンプトインジェクション（prompt injection） |
| 社外のゲストがいるチャンネル／他社と共有しているチャンネルでは最初から返事をしない | 「How should Claude work in channels with guests」の既定値 Restrict／Slack Connect のチャンネル |
| 変更の提案／頼んだ人とは別の人の承認 | プルリクエスト（PR）／「Require a second approval on Claude’s pull requests」 |
| 呼ばれなくても動く機能／自動で応答する | チャンネルごとの「Respond automatically」（既定オン）。6月の本文では「アンビエントモード」と書いた |
| 決まった時間の作業・チャンネルの見張り | routine |
| メンバーに知らせる | 「Let members know they can now tag Claude」（既定オン） |
| Claude Tag の管理画面の記録 | Activity ページ（Owner のみ） |
| 月の上限額 | spend limit（6月の本文では spending limit と書いた）。チャンネルごとの上限と、新しいチャンネル向けの Default spend limit もある |
対応プランと提供状況
10月時点で Public Beta。対象は Claude Team と Claude Enterprise で、Free / Pro / Max は対象外。対応は Slack のみ。Microsoft Teams は、Claude for Slack の製品ページ（claude.com/claude-for-slack）に「Coming soon to Microsoft Teams」とあり、waitlist の受付がある（時期の記載はない）。ZDR（ゼロデータ保持）・CMEK（顧客管理の暗号鍵）・Claude Code / Cowork 向けの HIPAA 設定のいずれかがある組織は使えない。
旧 Claude in Slack からの切り替え
- 6月の発表では「管理者は30日以内にオプトインできる」とあった。ヘルプセンターの記事（9月24日更新）では、8月3日に Claude Tag へ切り替わった、とされている。
- 2026年10月5日以降、Claude の組織とペアリング済みの Slack ワークスペースでは、旧アプリはチャンネルで応答せず、廃止の通知を出す。DM は影響を受けない。ペアリングしていないワークスペースでは、Pro / Max のユーザーは今もチャンネルで旧アプリの応答を受けられる。
- 旧アプリのデータは移行されない。GitHub などの接続も、旧アプリで各ユーザーがつないだものは引き継がれず、管理者がつなぎ直す。
誰の名義で動くか
チャンネルでの作業は agent identity で動く。Slack には Claude アプリとして投稿し、GitHub には Claude GitHub App として PR を出し、他のツールには管理者が用意したサービスアカウントで入る。旧アプリは各ユーザーが自分の claude.ai アカウントを連携し、その人の権限で動いていた。なお10月時点のドキュメントでは、Claude との1対1の DM は今もその人自身の claude.ai アカウントで動く（PR だけは Claude GitHub App 名義）。前半の「専用のアカウントで動く」はチャンネルでの作業の話だ。
個人のツール（Personal connectors in channels）
- 本人の依頼のときだけ、本人の許可（Allow／Allow with review／Don’t allow）のあとで、本人の権限で動き、本人の名前で記録される。ほかの人の依頼や、routine など Claude が自分で始めた作業には使われない。
- 結果はチャンネルの全員に見える。投稿の前に機密らしい内容を止める確認はあるが、ドキュメントは「a screen, not a guarantee」としている。
- Team プランは管理者の設定なしで有効。Enterprise は「すべての結果を本人が確認してから投稿」を強制できる。組織としてこの機能自体を止める設定はない。止めたいサービスは、組織のコネクタ設定でそのサービス自体を管理する。
設定の重なり方（スコープ）
6月の本文では「ワークスペース単位でベースを定義し、各チャンネルが継承して、チャンネル単位で上書きできる」と書いた。10月時点のドキュメントでは、スコープは Slack 全体（ベースライン）・ワークスペース・チャンネルの3階層で、設定は上に積み上がる（足し合わせ）。同じ宛先（ホスト）向けの認証情報が重なったときだけ狭いほう（チャンネル）が優先され、カスタム指示はつながり、モデルだけは置き換わる。
- Claude をチャンネルに入れるのは一般メンバーでもできる（
/invite @Claude。Slack 側で招待が制限されている場合は「Channel details > Agents & apps」から）。メンバーが入れただけのチャンネルには、Slack 全体とワークスペースの設定が乗る。 - チャンネルに接続や bundle を付けられるのは Owner と Claude Tag admin（Enterprise で、カスタムロールに付ける権限）。Owner が指名したチャンネルマネージャーも、担当のチャンネルなら付けられる。
- Connectors タブで最初に追加したサービスの認証情報は、保存した時点で Slack 全体（全ワークスペース・全チャンネル）に有効になる。Owner が絞らなければ、メンバーが入れたチャンネルにも乗る。前半①の「最初につないだツールは全チャンネルで使える状態になる」はここの話だ。
- 公開チャンネルに付けた bundle の権限は、参加した人全員に及ぶ。ドキュメントも、強い権限の認証情報は非公開チャンネルに置くよう注意している。
- Claude は自分が入っていない公開チャンネルも、キーワードで検索できる。
社外のゲストがいるチャンネル
「How should Claude work in channels with guests」で決める。Restrict（既定。返信しない）／Channel only（返信するが、ゲストがいる間はチャンネル自身に付けた接続・指示だけを使い、上の階層から受け継いだものは使わない）／Full access（スコープの権限をすべて使う）の3つ。Restrict と Channel only は Owner と Claude Tag admin が選べ、Full access にできるのは Owner だけ。Slack Connect（他社と共有）のチャンネルも同じ設定で決まり、Full access にしても Channel only 相当に制限される。
試すときの初期設定
- 導入（Launch）の手順で、チャンネルの一覧が出る場合は公開チャンネルを1つ以上選ばないと Launch できない。
- 「Let members know they can now tag Claude」は既定オンで、Slack の全メンバーに DM が届く（Enterprise Grid を丸ごとペアリングした場合を除く）。試す段階では切る。
- 返事をするチャンネルの絞り方：Enterprise などで「Respond in all channels」がある場合は、それを切って、選んだチャンネルの「Enable Claude Tag in this channel」だけオンにする（後から誰かが招待しても返事をしない）。Team プランで「Respond in channels」の単一スイッチの場合はこの方法が使えないので、Blocked channel patterns（チャンネル名のパターン）で締め出す。
- Claude を使える人も絞れる。既定は Slack の全員が使える。「Restrict to your organization」（Team）／「Restrict to roles with Claude Tag access」（Enterprise）で、自社の Claude アカウントを持つ人に絞れる。
GitHub の承認
Claude の PR は Claude GitHub App 名義で出るので、頼んだ本人もレビュアーとして承認できる。必要な承認が1人のブランチ保護だと、依頼者が1人で入れられる。ドキュメントの「Require a second approval on Claude’s pull requests」に沿って、Claude の PR には依頼者以外の承認を求める設定にする。
Agent Proxy（鍵の差し込み）
認証情報は別の保管庫に置かれ、サンドボックスにもモデルにも渡さず、Agent Proxy が外向きのリクエストの境界で差し込む。認証情報ごとの宛先のルール・許可したドメイン・環境のネットワーク設定のどれにも合わない宛先は遮断される（既定で拒否）。プロキシが扱うのは HTTP / HTTPS だけで、SSH やデータベースへの直接の接続は通らない。GitHub の API と git の操作は、別の GitHub 用プロキシを通る。
記録（監査）
6月の Anthropic の発表文には「Claude がしたことすべてと、それぞれを誰が頼んだかの記録を管理者が見られる」とあり、6月の本文は「どの認証情報がいつ使われたか、誰が頼んだ作業かが監査ログに残る」と書いた。10月時点のドキュメントでは、Activity ページ（Owner のみ）で見られるのは、定期の作業（routine）・メモリ・ネットワークイベントの3つ。ネットワークイベントは、Agent Proxy を通った外向きのリクエストを1時間ごとの JSON で書き出したもので、Git と MCP の通信は含まれない。ドキュメントには「全タスクと依頼者の一覧のログはない」と書かれている。代わりに追う手段として、つないだ先の各サービスの監査ログ（Claude 用のサービスアカウント名義で残る）と、PR から Slack スレッドへのリンクが挙げられている。前半の STEP2 で「毎日見る」のは、この3か所だ。
自動で応答する（Respond automatically）と routine
6月の発表では、有効にすると、見ているチャンネルやツールの関連情報を先回りして知らせ、止まったスレッドやタスクを追いかける「ambient」な動きとして紹介されていた。10月時点のドキュメントには「ambient mode」という名前の設定はなく、該当するのはチャンネルごとの「Respond automatically」で、既定はオン（ワークスペースや組織でまとめて切る設定はなく、チャンネルごとに持つ）。オンのチャンネルでは、Claude はトップレベルの投稿とスレッドの返信を読み、返信するかを自分で判断する（答えを既に持っているときや、その種の作業を拾うよう指示されているとき）。10日間メンションも投稿もないと、読むのをやめる。読む・判断する・短く返すだけなら課金されず、自分から始めた作業は Proactive として課金される。決まった時間の実行や「このチャンネルを見張って」は、別機能の routine。一般メンバーも Respond automatically のオン・オフはできる（Owner がチャンネルメンバーの編集を Block にしていない場合）。
月の上限額（spend limit）
- 10月時点のセットアップ画面：プリセットは $500 / $1,000 / $2,500 / $5,000 / Unlimited / Custom（最大 $1,000,000）。$2,500 が選ばれた状態で出る（すでに上限を設定していれば、そちらが優先）。
- 使用クレジットの購入ステップが出る組織（Team プランなど）では、セットアップで上限の選択画面自体が出ない。起動後に利用状況のページで決める。Team プランはクレジットを買うまで、Claude はチャンネルで返事をしない。
- 請求書払いの Enterprise は、上限を決めない限り請求に上限がない。
- チャンネルごとの上限と、新しいチャンネル向けの Default spend limit がある。上限に達すると Claude は処理を止めて依頼者に伝える。上限は定価で数え、毎月初めにリセットされる。
パイロットのチェックの細部
前半の「範囲外への操作」は、たとえば許可リストにない Google Drive のフォルダや、対象外のリポジトリへの呼び出しのこと。1件でもあれば、接続を見直す。10月時点では、Activity ページのネットワークイベント（Git と MCP 以外の外向き通信）と、接続先の各サービスの監査ログで確かめる。
「広くつなぐ」の出典
6月の本文では Anthropic が「最初から寛大にアクセスを与えると価値が複利で効く」と言っている、と書いたが、この言い方は一次情報で確かめられなかった。近いのは、ドキュメントの使い方のコツ（Good habits）にある「Grant broad access」（チャンネルにつながるものが多いほど、Claude が情報源を組み合わせられて役に立つ、という趣旨）。前半はこちらに合わせて直した。