Slack のチャンネルで「自分のカレンダー」が使えるようになった。Claude Tag が個人コネクタに対応

要約

Anthropic は 2026-09-24、Claude Tag がチャンネル内でも個人コネクタ（personal connectors）を使えるようになったと発表しました。

Claude Tag は Slack で @Claude に仕事を渡す仕組みです。これまでチャンネルとダイレクトメッセージ（DM）では、Claude が使える道具がまったく別でした。チャンネルでは、管理者がそのチャンネルに紐づけた「接続（connections）」だけが使えます。Claude はサービスアカウントとして動き、誰が頼んでも同じ権限で動きます。対して DM では、自分の claude.ai アカウントに設定したコネクタ（カレンダー、受信箱、課題管理など）が使え、Claude は自分の名前で動きます。

この分離には理由がありました。チャンネルは複数人が見ている場所なので、「誰が頼んだかで Claude のできることが変わる」と予測がつかなくなる。だから権限をチャンネルに固定し、監査ログもサービスアカウントに寄せる、という設計でした。

今回の更新は、その原則を崩さずに例外を1つ作るものです。チャンネル内であっても、自分が出したリクエストに限っては、自分の個人コネクタを Claude が使える。 「@Claude 木曜のローンチレビューを自分のカレンダーに入れて」という依頼が、チームチャンネルの中で完結します。他の人が同じチャンネルで頼んでも、その人のコネクタが使われるだけで、あなたのカレンダーには触れません。

安全側の仕掛けは確認プロンプトです。 Claude が個人コネクタを使おうとすると、本人にだけ見えるプロンプトが出ます。選択肢は3つ。Allow は、Claude が応答をそのまま投稿します（投稿前に機微に見えるものを自動検査して保留しますが、公式は「この検査は取りこぼしうる」と明記しています）。Allow with review は、すべての応答を本人が承認してから投稿します。Don’t allow は、そのリクエストでは個人コネクタを使いません。Enterprise プランでは、組織の Owner が Allow の2択のうち片方を取り上げられるため、全件レビュー必須を組織方針として強制できます。

何が変わったか

• チャンネル内で、自分のリクエストにだけ自分の個人コネクタを使わせられるようになった
• 使用前に本人にだけ見える確認プロンプトが出る（Allow / Allow with review / Don’t allow）
• Allow でも投稿前に機微な内容の自動検査が入るが、公式は「取りこぼしうる」と明記
• Enterprise では Owner が Allow の片方を削除でき、全件レビュー必須にできる
• 管理者は「共有ツールを agent identity で提供する」「個人コネクタだけに寄せる」をツール単位で選べる
• 個人コネクタ経由の操作は本人のアカウント配下に記録される（DM と同じ扱い）。チャンネルの共有接続は従来どおりサービスアカウント配下
• Team プランで先行ロールアウト、Enterprise が後続
• 対象は監督つきの協働作業のみ。 スケジュール実行の routine や無人での Claude の動作は、従来どおりチャンネル側の接続を使う

業務インパクト（一般企業向け）

いちばん大きいのは「頼む場所を選ばなくてよくなった」ことです。 これまでは、チームで議論している最中に自分のカレンダーや受信箱が必要になると、DM に移るか、手作業に戻るしかありませんでした。会話の文脈がチャンネルにあるのに、道具が DM にしかない。この分断が消えます。

一方で、管理者にとっては設定の見直しが発生します。 これまで「チャンネルで使える道具 = 管理者が決めたものだけ」という一本の線でした。今後はツールごとに3つの選択肢があります。共有接続としてサービスアカウントで提供するか、個人コネクタに任せるか、両方許すか。

判断の軸はシンプルで、**「誰がやったかを記録に残したいか」**です。共有接続だと、操作はすべてサービスアカウント配下に記録されます。チームの誰が依頼したかは Slack のスレッドを見ればわかりますが、連携先ツールの監査ログには残りません。個人コネクタなら、連携先の監査ログに本人の名前が残ります。課題管理やカレンダーのように「誰の予定か」「誰が更新したか」が意味を持つツールは個人コネクタ寄り、社内データベースやコードリポジトリのように「Claude がやった」で十分なものは共有接続寄り、という整理が現実的です。

制限として押さえるべきは、無人実行が対象外である点です。 スケジュールで動く routine や、Claude が自分で判断して動くケースは、従来どおりチャンネル側の接続を使います。つまり「自分のコネクタで毎朝レポートを作らせる」はできません。 個人コネクタは、人がその場で見ていて、確認プロンプトに答えられる状況でしか動かない設計です。これは制約ですが、同時に「個人の権限が自分の知らないところで動くことはない」という保証でもあります。運用設計をするときは、自動化したい処理は共有接続側に寄せる必要がある、と覚えてください。

確認プロンプトの運用も決めておくべきです。 Allow は速いですが、公式が「自動検査は取りこぼしうる」と書いている以上、機微な情報を扱うチャンネルでは Allow with review を既定にすべきです。Enterprise なら Owner が組織方針として強制できるので、個人の判断に任せずに、まず全件レビュー必須で始めて、問題がないことを確認してから緩める順序をおすすめします。

副業・個人活用視点

個人事業や小規模チームでは、この更新は「Slack を作業台にできるか」という話になります。

これまで、Slack で Claude に頼める仕事は「そのチャンネルに接続された道具でできること」に限られていました。自分の Google カレンダー、自分の Gmail、自分が契約している SaaS は、DM に移らないと使えない。結果として、チャンネルは相談の場、DM は作業の場という使い分けが生まれていました。今後は1つの場所で完結します。

具体的な使い方としては、「自分だけのチャンネル」を作るやり方が効きます。 公式ドキュメントでも紹介されている運用で、自分と Claude だけの Slack チャンネルを作り、そこを作業拠点にします。チャンネルなのでメモリ（Claude が学習した文脈）が蓄積され、routine もスケジュールできます。そこに個人コネクタが加わると、「文脈は蓄積される、道具は自分のもの」という状態が作れます。DM だと文脈の蓄積とスケジュール実行が弱く、共有チャンネルだと自分の道具が使えなかった。その両方が埋まります。

クライアント案件に持ち込むなら、説明の順序に気をつけてください。 「Slack で AI が自分のカレンダーを触れる」という言い方をすると、情報システム部門の反応はほぼ確実に否定的です。先に権限の話から入るべきです。 ①チャンネルの共有接続は従来どおりサービスアカウント、②個人コネクタは本人のリクエストにだけ、③使う前に本人だけに見える確認が出る、④Enterprise なら管理者が全件レビュー必須を強制できる、⑤無人実行では使えない。この5点を並べると、これは権限を広げる機能ではなく、権限の線を細かく引けるようにする機能だと伝わります。

提案材料としての注意点もあります。 2026-09-24 時点で Team プランに先行ロールアウト中で、Enterprise は後続です。Enterprise 契約の大企業に「もう使えます」と言うと外します。導入検討の相談を受けたら、まず対象プランと展開状況を公式ページで確認してから話を進めてください。