サムネイル

Claude Tagとは何か——SlackでAIがチーム常駐し、65%のコードを生み出す新アーキテクチャ

  • 0

こんにちは。

もるふぉです。

「このバグ調べて」とSlackに書いたら、AIが勝手にコードを読みに行き、原因を特定し、関連スレッドまで拾い上げて返してくる。

しかもチームメンバー全員が同じAIと会話できる。

そんな話が、ベータとはいえ正式機能として降ってきました。

Anthropicが2026年6月23日に発表した「Claude Tag」の話です。

「Anthropic社内ではプロダクトコードの65%がこの仕組みから生まれている」という一文があります。

65%という数字、インパクトがあるんですが、エンジニア視点で読むとここに本当の設計思想が透けて見える。

今日はその構造を解きほぐします。

Claude Tagとは——SlackでClaudeが「チームメンバー」として常駐する

旧Claude in Slackアプリ(1人vs Claudeの1on1)と新Claude Tag(1チャンネル=1Claude、チーム全員が共有)の対比図

Anthropic公式の発表を整理すると、Claude TagはSlackチャンネルにClaudeが常駐し、@メンションでタスクを受け取り、自律的に遂行して、完成物をスレッドに返してくる仕組みです。

対応モデルはOpus 4.8、対象プランはClaude EnterpriseとTeam(ベータ)。

これまでのチャットAIとの一番の違いは「常駐している」こと。

AIに毎回コンテキストを説明するのではなく、AIがチャンネルにいて、会話を見ていて、必要なときに動く。

発想がチャットボットではなくチームメンバーなんですよ。

旧「Claude in Slack」アプリとの決定的な違い

ここ、勘違いしている人が多そうなので最初に整理しておきます。

旧Claude in Slackアプリは2026年8月3日にClaude Tagへ自動で切り替わる予定です。

旧アプリは基本的に「1人 vs Claudeの1on1スレッド」でした。

DMでClaudeと話す感覚に近い。

チャンネルに入れても、結局は呼んだ人とClaudeの個別やり取りでした。

Claude Tagは「1チャンネル=1Claudeインスタンス」で、チャンネル参加者全員が同じClaudeと会話します。

途中で同僚が割り込んでも、Claudeは同じ文脈で受け止めて返答する。

この「共有された1人」の設計が、機能上の差分以上にチーム運用を変えます。

旧アプリ利用者は8月3日の移行前に、このあとのセクションで触れる権限・情報設計を確認しておいてください。

Claude Tagの4つのコア機能を技術視点で読む

Claude Tagの4つのコア機能(マルチプレイヤー/文脈学習/アンビエント動作/非同期遂行)を整理した機能マップ

公式が打ち出しているコア機能はマルチプレイヤー、文脈学習、アンビエント動作、非同期遂行の4つです。

それぞれを技術視点で読み解きます。

マルチプレイヤー——1チャンネル=1Claudeで引き継ぎが成立する

チャンネル単位で1つのClaudeインスタンスが立ち上がるという設計が、引き継ぎ運用を変えます。

たとえばインシデント対応チャンネルで、最初に気づいた人が「@Claude このエラーログ調べて」と投げる。

1時間後に交代でオンコールに入った別のメンバーが「さっきの件、どこまで進んだ?」と聞くと、Claudeは同じ文脈で答えられる。

今までは引き継いだ人間側の説明コストが必ず発生していました。

これがゼロにできる、というのが構造的な意味です。

引き継ぎのたびに「経緯を共有する時間」が発生するあの煩雑さを、想像してみてください。

そこへの答えです。

チャンネルから文脈を蓄積する仕組み

Claudeはチャンネルの会話履歴を継続的に取り込みます。

毎回「うちのプロダクトは〜」「あの顧客は〜」と説明する必要がない。

さらに権限を付与すれば、他のSlackチャンネルや外部データソースからも学習する(公式機能として確認済み)。

技術的には、コンテキストウィンドウに収まらない過去ログをどう扱うかが鍵です。

公式は詳細アーキテクチャを開示していないので推測ですが、直近の会話をフルコンテキストに、過去の要約・埋め込みを別レイヤーで持つRAG的な構成だと思います。

実務で効くのは、新規参画者の立ち上がりが速くなる点ですね。

「このチャンネルのClaudeに聞けば、過去の議論を踏まえた答えが返ってくる」状態は、オンボーディング資料を更新し続けるより現実的です。

アンビエント動作——非同期エージェントの完成形

ここが個人的に一番面白いポイントです。

アンビエント動作とは「@メンションを待たずに、Claudeが自発的に動く」仕様。

放置されたスレッドを自分からフォローアップしたり、チャンネル全体から「いま関連しそうな情報」を拾って提示したりします。

実はこの設計、Zenn上で「アンビエントエージェント」として個人開発者が先行実装していたパターンです。

Slackのイベントをトリガーにclaude -pを発火させて、独自のメモリと判断ロジックで自律動作させる。

それを公式が実装したのがClaude Tagだと読めます。

エンジニア視点で言うと、これは「リアクティブなチャットボット」から「プロアクティブなエージェント」への明確な移行です。

非同期メッセージング+イベント駆動+ステートフルAIの組み合わせで、自前で組むと相当しんどい領域。

これが標準機能で来たのは、正直かなり大きいと思っています。

タスク分解と完成物返答までの流れ

@メンションで投げられたタスクを、Claudeは段階分解してツールを使いながら遂行します。

公式によれば数時間から数日にわたる長期タスクも自律遂行可能とのこと。

流れとしては、タスク受領→サブタスク分解→ツール呼び出し(コード実行・データ取得・外部API)→中間結果の検証→完成物のスレッド返答、というシーケンスです。

「数日にわたる自律遂行」が本当にできるのかは、正直まだ確信が持てません。

プロダクション運用してみないと、どこで人間の介入が必要になるかが見えない。

ここはベータ期間の早期導入者の検証待ちです。

Anthropic社内での「プロダクトコードの65%」という実績を文脈化する

Anthropic社内でClaude Tagが生成するコード65%と、人間が担う仕様設計/アーキ判断/テスト設計などの35%の対比インフォグラフィック

Anthropic社内ではプロダクトチームのコードの65%が社内版Claude Tagで生成されている、と公式が明言しています。

営業メトリクスの追跡、サポートチケットの対応にも使われている。

この数字、すごいで終わらせると勿体ないです。

読むべきは「65%が自動化」ではなく「100%自動化されない理由」の方です。

残り35%にエンジニアの仕事が残る理由

残り35%の中身はこういう種類のタスクです。

  • 仕様設計(何を作るかの定義)
  • アーキテクチャ判断(どう作るかの大方針)
  • テスト設計(何が正しい振る舞いかの定義)
  • セキュリティ・パフォーマンスの最終確認
  • ステークホルダー調整

AIに任せられる65%は「仕様が明確になった後の実装」が中心のはずです。

Claudeにタスクを任せる前段で、人間が問題を構造化する仕事は減らない。

むしろこの設計工程こそがエンジニアの仕事の中心になっていきます。

「コードを書かないエンジニア」という言い方が成り立つのも、書く部分をAIに渡せるからこそ、設計と判断に時間を使えるという話です。

書ける人が書かなくなった、というニュアンスは65%の数字とちゃんと整合します。

この構造が腑に落ちると、Claude Tagの各機能が「なぜ設計されたのか」が見えてきます。

Claude Tag管理者が考えるべきチャンネル別アイデンティティ設計

ここは管理者・テックリード向けの話です。

Claude Tagは管理者がチャンネル別に異なるClaudeアイデンティティを作成できます。

さらにトークン支出の上限設定も可能。

設計対象
検討ポイント
アイデンティティ
チャンネルごとの役割(エンジ向け/営業向け/サポート向け)に応じた指示・トーン
権限分離
営業データはエンジニアチャンネルから参照不可、など情報の壁を設計
トークン上限
暴走防止と予算管理。重要チャンネルだけ上限を緩める運用も可能
メモリ範囲
過去ログをどこまで参照させるか、機密チャンネルは短期メモリのみ等

雑にチャンネルに突っ込むと、機密情報を持つClaudeが別チャンネルで情報を漏らすリスクがあります。

デフォルト設定で導入する前に、情報設計を1回必ず通したほうがいい。

特にEnterpriseプランで複数チャンネルに展開するなら、この設計を後回しにすると後で詰みます。

Claude CodeとClaude Tag、どう使い分けるか

Claude Codeを既に使っている人にとって、Claude Tagは「乗り換え」ではなく「併用」が正解だと思います。

観点
Claude Code
Claude Tag
操作起点
ローカル開発環境(CLI)
Slackチャンネル
使う人
個人(エンジニア)
チーム(複数人+AI)
主用途
コード実装・リファクタ・テスト
レビュー依頼・障害対応・進捗管理・チーム会話起点のタスク
文脈
リポジトリ・ローカルファイル
チャンネル履歴・チーム共有情報

私の現場での使い分け仮説はこうです。

ローカルで黙々と実装するのはClaude Codeで継続。

Slackで「これレビューして」「この障害の原因調べて」「あの仕様まとめて」というチーム発生型のタスクはClaude Tagに振る。

同じClaudeでも、操作起点と文脈源が違うので役割が分かれます。

実装はClaude Codeで完結させて、チーム連携と進捗管理はClaude Tagで巻き取る。

この組み合わせが現時点では合理的な配置だと思っています。

使い分けの感覚は、実際に触れてみると一瞬でわかります。

Claude Tag導入条件と今のベータ制約

  • 対象プラン: Claude Enterprise / Team(ベータ)
  • 個人向けのProプランは現時点で対象外
  • 対応モデル: Opus 4.8
  • 提供開始: 2026年6月23日
  • 旧Claude in Slackアプリは2026年8月3日にClaude Tagへ切り替わる予定
  • 管理者によるチャンネル別アイデンティティ作成・トークン支出上限設定が可能

ベータなので機能・料金体系が変わる可能性は高いです。

本格運用に入れる前にPoCチャンネルを1つ立てて、自社の情報設計と合うか試すのが安全です。

EnterpriseまたはTeamプランを使っているなら、まずPoCチャンネルを1つ作って投げ込んでみてください。

「引き継ぎのたびに説明が発生するチャンネル」が最初のターゲットとして最適です。

個人で触ってみたいエンジニアは、まずはClaude Codeで「AIにタスクを任せる感覚」を身につけておくのがいいと思います。

Claude Tagがチームに来たときに、設計と指示の質で生産性差が出るのは、たぶんこの感覚を持っているかどうかですね。

会員登録して機能を使おう

この機能を利用するには、無料の会員登録が必要です。
お気に入りの記事を保存して、あとで読み返しましょう!