Claude TagはSlack版Claude Codeなのか：試して分かった導入前の確認ポイント

はじめに

Anthropic が発表した Claude Tag を、Slack から少し試しました。

Slack のチャンネルで @Claude と呼び出すと、Claude がスレッドの文脈を読んで作業してくれる。さらに GitHub リポジトリを接続していると、Issue や Pull Request、コードベースを前提にした作業まで依頼できます。

最初に触った印象だけで言えば、「これは Slack から Claude Code のクラウド環境を呼び出す機能なのかな」と感じます。

ただ、試してみると少し違いました。

私の環境では GitHub 連携は使えましたが、Notion は連携候補として表示されませんでした。非公開の Notion ワークスペースを検索したり、仕様書を読ませたりすることはできませんでした。

ここが Claude Tag を理解するうえで大事なところです。

Claude Tag は、何でも読める万能な Slack ボットではありません。

チャンネルごとに、管理者がどのツールを許可しているかで、できることが変わります。GitHub が使える環境もあれば、Notion が使える環境もある。逆に、GitHub しか見えない環境もあります。

この記事では、私が実際に確認できた範囲をもとに、Claude Tag を導入する前に何を確認すべきかを整理します。

まず押さえたい結論

今回の整理を短くまとめると、次のようになります。

• Claude Tag は、Slack チャンネルに参加するチーム向け Claude エージェント
• GitHub が接続されていれば、Slack の会話から調査、Issue 化、draft PR 作成などに進められる
• 外部資料を見に行かなくてよい GitHub Issue なら、移動中にモバイル Slack から draft PR まで進められる可能性がある
• ただし、使える外部ツールは環境ごとに違う
• 私の環境では GitHub のみ使え、Notion は使えなかった
• Notion が使えないのは「Claude Tag が Notion 非対応」という意味ではなく、「この環境では Notion connection が設定されていない」という意味
• 導入前にまず確認すべきなのは、「このチャンネルの Claude は何にアクセスできるのか」

Claude Tag を試すときは、機能紹介だけを読むよりも、自分の Slack チャンネルで @Claude が実際に何を見られるのかを確認するほうが重要です。

私の環境では GitHub だけが使えた

今回、私が試した環境では、Claude が利用できる外部連携は GitHub だけでした。

Slack で @Claude を呼び出し、GitHub リポジトリに関する作業を依頼する。すると、Claude はリポジトリの Issue、Pull Request、コードベースを前提に作業できます。

たとえば、次のような依頼は自然に使えそうです。

@Claude このスレッドのバグ報告をもとに、原因を調査してください。
再現できたら draft PR まで作ってください。

または、

@Claude この PR の変更内容を読み、ユーザー影響がありそうな点を整理してください。

この体験は、かなり Claude Code に近いです。

実際、Anthropic の Claude Code in Slack ドキュメントでは、Slack の @Claude からコーディングタスクを検出し、Claude Code on the web のセッションを作成する流れが説明されています。GitHub アカウントやリポジトリが接続されていれば、Slack の会話から開発作業に入れるわけです。

ただし、ここで止まると誤解しやすい。

GitHub が見えたのは、GitHub が接続されていたからです。Claude Tag そのものが、最初からすべての社内ツールを読めるわけではありません。

Notion は使えなかった

次に気になったのが Notion です。

Slack から Claude を呼べるなら、Notion の仕様書や議事録も読めるのではないか。そう期待したくなります。

しかし、私の環境では Notion は使えませんでした。

Claude に確認すると、このセッションで利用できる外部連携は GitHub のみで、Notion 用のツールや API 接続は設定されていない、という状態でした。つまり、非公開 Notion ページの検索、読み取り、同期はできません。

これは、Claude Tag が Notion に対応していないという意味ではありません。

公式ドキュメントには Notion connection のガイドがあります。ただし、それを実際に使うには、対象のワークスペース、認証情報、チャンネル側の Access bundle などが設定されている必要があります。

読者として押さえるべきなのは、この違いです。

Claude Tag の機能として Notion 連携がある
      ≠
自分の Slack チャンネルの Claude が Notion を読める

非公開 Notion は認証が必要です。公開 URL なら通常の Web 取得で読める可能性はありますが、社内 Notion は別です。管理者が Notion connection を設定していなければ、Claude からは見えません。

Claude Tag は何をする機能なのか

Claude Tag を一言でいうと、Slack チャンネルでチームと一緒に働く Claude です。

従来の Claude は、基本的に個人がチャット画面で使うものでした。Claude Tag では、Slack チャンネルの中で @Claude を呼び、チームの会話文脈を使って作業を依頼できます。

ここで重要なのは、「個人の Claude」ではなく「チャンネルに設定された Claude」として動く点です。

管理者は、どのチャンネルの Claude が、どのツールにアクセスできるかを設定します。GitHub、Notion、Google Drive、Jira、Linear などの外部ツールを接続できるかどうかは、この設定に依存します。

つまり、Claude Tag は「Slack で Claude が返事する機能」ではなく、Slack チャンネルを入口にして、チームのツールやデータに接続する AI エージェント基盤と見るほうが近いです。

Slack 版 Claude Code と考えてよいのか

GitHub 連携だけを見れば、「Slack 版 Claude Code」と言いたくなります。

これは半分正しいと思います。

Slack のスレッドから、コード調査、修正案、draft PR 作成へ進める体験は、Claude Code のクラウド実行にかなり近いものです。開発チームにとっては、この使い方が最初に分かりやすいはずです。

ただし、Claude Tag は GitHub 専用ではありません。

GitHub は、Claude Tag が接続できる外部ツールの一つです。Notion や他の業務ツールが設定されていれば、開発以外の調査、要約、議事録整理、チケット化にも使えます。

そのため、より正確には次のように捉えるのがよさそうです。

Claude Tag は、Slack から Claude Code 的な開発作業も呼び出せるが、本質は Slack チャンネルで動くチーム共有型の Claude エージェントである。

この理解なら、GitHub だけが見える環境でも、Notion まで見える環境でも、説明がずれません。

読者が最初に確認すべきこと

Claude Tag を試すなら、最初に確認すべきことは 1 つです。

@Claude what can you access from this channel?

日本語なら、次のように聞いてもよいと思います。

@Claude このチャンネルからアクセスできる外部ツールを教えてください。
GitHub、Notion、Google Drive など、何が使える状態ですか？

この回答で、実際に使える範囲が見えます。

次に確認したいのは、次の 4 点です。

1. GitHub はどのリポジトリまで見えるのか

GitHub が使えるとしても、すべてのリポジトリにアクセスできるとは限りません。

対象リポジトリ、Issue、Pull Request、コードの読み取り、書き込み、draft PR 作成がどこまで許可されているかを確認します。

2. Notion や Drive は本当に接続されているのか

Notion の名前が公式ドキュメントにあるからといって、自分の環境で使えるとは限りません。

非公開ページを読ませたいなら、Notion connection が設定されているか、対象ワークスペースやページに権限があるかを確認します。

3. チャンネルで呼んでいるのか、DM で呼んでいるのか

チャンネルで呼ぶ Claude と、DM で使う Claude では、権限や請求、作業者の扱いが変わる場合があります。

特に GitHub 作業では、誰の権限で PR が作られるのかを確認しておいたほうがよいです。

4. どこまで自動でやらせるのか

Claude Tag は便利ですが、最初から merge や本番反映まで任せる必要はありません。

最初は、次のような境界にしておくと安全です。

• Issue 作成まで
• 調査メモ作成まで
• draft PR 作成まで
• CI 結果の確認まで
• merge と本番 deploy は人間が行う

AI エージェントは、できることが増えるほど「どこで止めるか」の設計が重要になります。

開発チームではどう使うとよさそうか

GitHub 連携が使えるなら、Claude Tag は開発チームの Slack とかなり相性がよいです。

特に便利そうなのは、Slack の議論を GitHub の作業単位へ変換する使い方です。

たとえば、バグ報告チャンネルで次のように依頼します。

@Claude このスレッドを GitHub Issue に整理してください。
再現手順、期待される挙動、実際の挙動、影響範囲、受け入れ基準に分けてください。

もう一歩進めるなら、

@Claude この Issue の原因を調査し、修正案を draft PR として出してください。
PR 本文には、原因、変更内容、検証方法、未確認事項を書いてください。

このように依頼すると、Slack の雑談や障害報告が、Issue や PR というレビュー可能な形に変わります。

ここで重要なのは、Claude に「いい感じに直して」と投げないことです。

Slack のスレッドを出発点にしても、最後は目的、制約、完了条件、検証方法を明確にする。これは AI仕様駆動開発と同じ考え方です。

移動中に、モバイル Slack から PR まで進める

今回試していて、一番実感が湧いたのはここでした。

外部連携が多いプロジェクトでは、AI に任せる前に Notion、Drive、社内 DB、管理画面など、どの情報にアクセスできるかを丁寧に確認する必要があります。

一方で、GitHub の中だけで完結する Issue もあります。

たとえば、誤字の修正、ドキュメントの追記、軽微な UI 文言の調整、テストで落ちている箇所の調査、既存 Issue の受け入れ基準に沿った小さな修正などです。こうした Issue は、必要な情報が Issue、PR、コードベース、テスト結果の中に閉じていることが多い。

その場合、Claude Tag の価値はかなり具体的になります。

移動中にスマートフォンで Slack を開き、気になっていた Issue を見つける。そこで @Claude にメンションして、次のように依頼する。

@Claude この Issue を確認して、GitHub 内の情報だけで進められる範囲を調査してください。
修正できそうなら draft PR まで作ってください。
外部資料が必要なら、どの情報が不足しているかだけ教えてください。

この依頼が成立するなら、PC を開けない時間でも、Issue を「あとで見る」から「PR でレビューできる状態」へ進められます。

もちろん、すべての作業をモバイルで完結させるという意味ではありません。差分の確認、テスト結果の判断、merge、本番反映は、人間が落ち着いて見るべき場面があります。

それでも、移動中に Slack から開発の初動を切れる意味は大きいです。

これまでなら、気になる Issue を見つけても、PC を開くまで作業は止まっていました。Claude Tag が GitHub とつながっていれば、その待ち時間に調査、方針整理、draft PR 作成まで進められる可能性があります。

この体験は、「Slack に AI がいる」というより、Slack が開発タスクの入口になる感覚に近いです。

AI仕様駆動開発から見た意味

AI仕様駆動開発では、AI に作業を任せる前に、仕様を明確にします。

目的は何か。どの範囲を触るのか。何をもって完了とするのか。どのテストや確認を通すのか。

Claude Tag が面白いのは、この仕様の入口が Slack に広がることです。

これまで Slack の議論は、人間が読み直して Issue や仕様書に転記する必要がありました。Claude Tag が適切に設定されていれば、スレッドの文脈をもとに、Issue 化、調査、draft PR 作成までつなげられます。

ただし、Slack の会話そのものは仕様ではありません。

会話には抜け漏れがあります。前提が曖昧なこともあります。だから、Claude Tag に任せるときは、Slack のスレッドをそのまま実装指示にするのではなく、Claude にまず作業指示書へ整理させるのがよいと思います。

@Claude このスレッドを作業指示書に整理してください。
目的、背景、対象範囲、非対象範囲、受け入れ基準、検証方法に分けてください。

この一手を挟むだけで、AI に任せる仕事の品質はかなり安定します。

導入するときの現実的な始め方

チームで使うなら、最初から全社の Slack や Notion に広げないほうがよいと思います。

まずは、次のような小さな範囲から始めるのが現実的です。

1. 1 つの開発チャンネルを選ぶ
2. 1 つか 2 つの GitHub リポジトリだけ接続する
3. Claude ができることを「Issue 整理」「調査」「draft PR」までに限定する
4. merge と本番 deploy は人間が行う
5. 何がうまくいったか、何が危なかったかをチームで記録する

Notion を接続する場合も同じです。

いきなり会社全体の Notion を読ませるのではなく、特定のプロジェクトページや仕様書だけを接続する。Claude がどの情報を見ているのか、チームが説明できる状態にしておく。

Claude Tag は、便利さよりも先に権限設計が必要な機能です。

今回の検証で分かったこと

今回の検証で分かったことは、機能のすごさというより、期待値の置き方です。

GitHub が接続されていれば、Slack から開発作業に入る導線はかなり自然です。バグ報告、仕様相談、PR レビュー、調査依頼を GitHub の作業に変換しやすくなります。

特に、GitHub 内で完結する小さな Issue なら、モバイル Slack から Claude を呼び、draft PR まで進めるという使い方が見えてきます。これは、移動中の空き時間を単なる確認時間ではなく、レビュー可能な差分を作る時間に変える可能性があります。

一方で、Notion は私の環境では使えませんでした。

これは残念というより、むしろ大事な確認ポイントです。Claude Tag を導入しても、管理者が接続していない情報源は見えません。Claude が何を見て、何を見ていないのかを確認しないまま使うと、期待外れにもなりますし、権限設計も曖昧になります。

Claude Tag は「AI が Slack に入ってくる」機能ではありますが、本当に重要なのはそこではありません。

重要なのは、Slack の会話、GitHub の Issue / PR、Notion の仕様書のようなチームの情報を、どの権限で AI に渡すかです。

まとめ

Claude Tag は、単なる Slack ボットではありません。

GitHub が接続されていれば、Slack の会話から Claude Code 的な開発作業へ進められます。Notion が接続されていれば、仕様書や議事録を前提にした調査もできる可能性があります。

ただし、実際に何ができるかは環境次第です。

私の環境では、GitHub は使えましたが、Notion は使えませんでした。そのため、今回の検証は「Slack から GitHub 連携された Claude Code 的な作業を呼び出す」範囲に限られます。

読者がまずやるべきことは、機能一覧を眺めることではありません。

自分の Slack チャンネルで、Claude にこう聞くことです。

@Claude このチャンネルから何にアクセスできますか？

そこから始めるのが、Claude Tag を安全に理解する一番早い方法だと思います。

参考

• Introducing Claude Tag — Anthropic 公式発表
• Work with Claude Tag — Claude Tag overview
• How Claude Tag works — Claude Tag のセッション、memory、権限モデル
• How agent identity works — チャンネル利用と DM 利用の権限差
• Connect Notion — Claude Tag の Notion connection guide
• Claude Code in Slack — Slack から Claude Code on the web にルーティングする仕組み