
Claude Tagは、AnthropicがSlack向けに提供するAIチームメイトだ。「結局いくらかかるのか?」という問いへの正直な答えは、座席単位の価格を提示できる人はいない、なぜならそんなものは存在しないからだというものになる。課金はトークン使用量ベースで、管理者が支出上限を設定でき、利用できるのはClaude EnterpriseとTeamプランのみだ。
軟着陸の仕組みもある。Hacker Newsで報告されたローンチクレジットでは、Enterprise組織に25,000ドル、Team組織(10席以上)に2,500ドルが付与され、初期利用のかなりの部分をカバーする。それを使い切った後は、Claude Tagの請求は実質的にトークンの請求であり、常時稼働してチャンネルを一日中解析し続けるエージェントのコストプロファイルは、まだ誰も大規模な形で検証していない。
eeselで長年「SlackにAIエージェントを組み込む」ための仕組みを構築してきた立場からの見解を言えば、社内のエンジニアリングやオペレーション業務であれば、このモデルは悪くない。支出は実際の業務量によって自然と制限される。一方、顧客対応のサポート業務では、トークン使用量ベースの課金は形として合わない。スプレッドシートに書き込めるチケット単位の価格のほうが、いつでも優位に立つ。
Claude Tagの料金についての簡単な答え
細かい話に入る前に、まず表にまとめておく。ネット上で語られる「料金」のほとんどは、実は4つの異なる数字がごちゃ混ぜになったものだからだ。
| 実際に支払っている対象 | 数字 | 補足 |
|---|---|---|
| Claude Tag機能自体のライセンス | 0ドル(固定) | 座席単位・機能単位の公開料金なし |
| Claude Tagが消費するトークン | 使用量ベース | API利用と同様に課金され、管理者の支出上限で制限される |
| その土台となるプラン | EnterpriseまたはTeam | ベータ版はこの2つのプランに限定 |
| ローンチクレジット(初期の助走) | 2万5,000ドル / 2,500ドル | Enterprise組織 / 10席以上のTeam組織(HN情報による) |
つまり、誰かが「Claude Tagっていくら?」と聞いてきたときの正しい答えは、「今のClaudeのサブスクリプションに加えて、チームがどれだけ使い込むかに完全に左右されるトークン料金」ということになる。これはZendeskのAI料金や、座席単位の定額制AIコパイロットとは大きく異なる話で、導入前に理解しておくべき最も重要なポイントだ。

実際に何にお金を払っているのか
1. 機能自体には値札がない
ここで多くの人がつまずくので、はっきり言っておく。Anthropicは、Claude Tagの座席単位やトークン単位の価格を公開していない。現在ベータ版であり、ローンチ時の資料は機能について語るだけで、料金表については触れていない。購入できる「Claude Tagプラン」というものは存在しない。Slack自体のプラン階層のような料金ページを探しても、まだ見つからないはずだ。
2. 支払いはトークン単位、API利用と同じように課金される
ここが実際に重要なモデルだ。Claude Tagはトークン使用量ベースの課金で動く。チャンネルを読み、文脈を記憶し、タスクを実行するたびにトークンを消費し、その分が請求される。管理者は組織単位・チャンネル単位の両方で支出上限を設定し、それを制御できる。あるHacker Newsのユーザーはこれを的確にまとめている。
"Claude integration to Slack is now billed as API usage."
別のユーザーは端的に「nailed it(まさにその通り)」と返信した。これが押さえておくべき考え方だ。Claude Tagの料金は、Slackの姿をしたAPI型の使用量課金にすぎない。すでにClaude APIのコストを予算に組み込んでいるなら、これは同じ費目であり、自分で書いたスクリプトの代わりに、今度はチームの雑談によって動かされているだけだ。
3. 土台としてEnterpriseまたはTeamプランが必要
Claude TagはClaude EnterpriseとClaude Teamのプランに限定されており、ローンチ時点ではSlack専用だ。つまり実質的な初期コストは、これらいずれかの座席単位のサブスクリプションに、上乗せされるトークン支出を足したものになる。Enterprise契約者は、誰が@Claudeを呼び出せるかを制御するロールベースのアクセス制御も利用できる。エージェントが実システムにアクセスできる以上、これは重要なポイントだ。チームがMicrosoft Teamsで動いているなら、今は待つしかなく、もし本来Teams向けのITサポートボットが必要な状況なら、この対応範囲の欠落自体がそのまま実質的なコストになる。
4. ローンチクレジットは太っ腹だが、あくまで一時的
現在出回っている唯一の具体的な金額は、Hacker Newsで引用されたローンチクレジットの一文からのものだ。Enterprise組織には2万5,000ドル、有料10席以上のTeam組織には2,500ドル。これは本物の助走期間であり、軽度から中程度の利用であれば、請求書を見ることなく数か月は過ごせるだけの額だ。しかし、これはあくまでクレジットであり、価格ではない。この「無料に感じる」期間を延長トライアルだと捉え、それを使い切った後の月に何が起きるかを試算しておくべきだ。それこそが、Claude Tagの安定運用時の実際の料金だからだ。

自分のClaude Tagトークン支出を見積もる
料金表が存在しない以上、私が提供できる有用なものは、桁感を確認する手段だ。AnthropicはClaude TagをClaude Opus 4.8上で動かしているので、Opus水準のトークン料金と、自分のチャンネルの実際の活動量を入力してみてほしい。以下のウィジェットは大まかなモデルであって見積もりそのものではないが、「使用量ベース、詳細は不明」という状態を、反応できる具体的な数字に変えてくれる。
チャンネル数とタスク数を、活発なエンジニアリング組織に近い水準まで上げてみると、数字は一気に跳ね上がる。これは技術の欠陥ではなく、常時稼働するエージェントに対する使用量ベース課金の性質そのものだ。ここから、私自身が実際に経験してきた話につながる。
なぜ料金モデルこそがすべてなのか
私はeeselでインテグレーションと課金の仕組みを構築していて、料金モデルを読み解くことを生業にしている。Claude Tagについて繰り返し指摘したくなるのは、料率そのものではなくその形だ。使用量ベースのトークン課金は、コストが自分では完全にコントロールできない活動量に連動することを意味する。騒がしいローンチ週、おしゃべりなチャンネル、大量のメモリを圧縮しようとするエージェント。あるHNユーザーはこの懸念を率直な言葉で表現している。
"Wowza this will be a token guzzler. Assuming Claude is parsing every message posted on multiple slack channels, compacting knowledge etc."
同様のSlackボットを構築したことのある開発者は反論し、実際のセッションは短く収まるため、コストは十分に管理可能だと述べた。どちらも真実でありうる。正直なところ、まだ誰もあなたの規模でこれを運用したことはなく、ベータ期間中はあなた自身が予測リスクを引き受けることになる。
購入側でまさにこの力学が働くのを見たことがある。あるeeselの営業電話で、非常に大量のやり取りを扱うオペレーターが、インタラクション単位の請求をモデル化しようとして混乱し、価格の話が終わる前にスケール時で月額およそ3万ドルという試算を出してしまった。製品の有用性を損なわずには上限を設定できないような利用量に応じてメーターが回る場合、購入者は不安になる。それは当然だ。これはClaude Tag固有の欠陥ではなく、使用量ベースの課金がスプレッドシートに対して行うことそのものだ。だからこそ、私たちはeeselを顧客対応側では予測可能なチケット単位のコストへと移行させた。顧客対応では利用量の急増が例外ではなく常態だからだ。
社内業務であれば、リスクは小さくなる。エンジニアリングやオペレーションのタスクは実際の人的な引き継ぎによって自然に制限され、管理者はチャンネルごとの支出に上限を設定できる。使用量ベースの課金を受け入れるには妥当な領域だと言える。

その支出で何が得られるのか
料金に対して公平を期すために、トークンが何を買っているのかを見ておこう。社内業務にとっては、能力の高い製品であることは確かだ。

- マルチプレイヤー型のエージェント。 チャンネルごとに共有される1つのClaudeを、チーム全員が操作できる。1人1つの個別チャットではない。あるAnthropicのエンジニアはHacker Newsで、Claudeはスレッドの開始者とその後の参加者を区別すると説明しており、同僚が勝手にあなたのタスクを乗っ取ることはできない。
- 非同期でアンビエントな作業。 タスクを渡してその場を離れれば、Claudeは何時間もかけて作業を続け、自分でフォローアップの予定を組み、動きが止まったものにはフラグを立てる。これはエージェントの生産性向上のためのAIやSlackのエンタープライズ検索についての当社のガイドと同じ発想だ。
- エージェントのIDとスコーピング。 Claudeはあなたの認証情報ではなく、チャンネルごとのサービスアカウントの下で自分自身として振る舞い、すべてのアクションが記録される。これは、実システムの近くにエージェントを置くどんなチームでも求めるべき権限と確信度のスコーピングであり、この製品の中で最も設計が優れている部分だ。
- EnterpriseでのRBAC。 管理者は、誰が
@Claudeを呼び出せるか、そして各チャンネルのエージェントが何にアクセスできるかを制御する。
Anthropicは印象的な社内数値でこの価値を裏付けている。プロダクトリードのCat Wu氏は、チームが社内版を通じて製品PRの65%をマージしていると述べた。分母も期間も公開されていないため慎重に扱うべき数字だが、このツールがエンジニアリングの現場でその価値を証明していることを示している。あなたの組織の利用があなたのトークン請求を正当化するかどうかは、上の見積もりツールが答えの糸口を示してくれるだけの問いだ。
代わりに定額のチケット単位価格が勝るのはどんなときか
ここで線を引くとすればこうだ。Claude Tagの使用量ベース価格は、業務が社内的かつ限定的である限りは問題ない。相手が顧客になった瞬間、それは間違ったツールになる。
理由は2つ、どちらもコストの形に関わるものだ。
- サポートの利用量の急増はコントロールできない。 製品障害やバイラルな出来事は、一夜にしてチケット量を5倍に膨らませかねない。トークンベースの課金では、最悪の週がそのまま最もコストのかかる週になり、しかもそれはサプライズを最も許容できないタイミングだ。解決件数単位または定額のモデルなら、11月の請求書と3月の請求書を並べても読み解けるままにでき、AIとオフショアサポートのコスト比較は、その予測可能性がどれほどの価値を持つかを示している。
- 導入前にコストをシミュレーションできない。 Claude Tagには、過去のチケットを再生して、それが実際にどれだけのコストで解決できていたかを見せる方法がない。サポート向けに構築されたAIヘルプデスクエージェントならそれができるため、請求書で初めて数字を知るのではなく、導入前からその数字を把握したうえで進められる。
だからこそ、顧客対応に関わる部分については、社内向けのSlackチームメイトではなく、ヘルプデスク向けに構築されたツールを勧めたい。私がまとめたClaude Tagの代替ツールの記事は両方の側面をカバーしており、Slackが実際のサポートの現場であるなら、より絞り込んだリストであるSlackサポート向けの最良のAIを見てほしい。
より広い購入者視点としては、Slack連携に優れたヘルプデスクのまとめ記事も一読の価値があり、より大きなチームはエンタープライズ向けの最良のヘルプデスクガイドを読んでおくべきだろう。
予測できる請求額で使える、Slack向けのAIチームメイト
もしあなたが求めているのが、サポートチケットのクローズもできるSlack向けAIチームメイトなら、まさにそれこそ私が構築しているものだ。eeselはSlackとあなたのヘルプデスクの両方に接続し、あなた自身の過去のチケットとヘルプセンターで学習し、消費したトークン単位ではなく解決したチケット単位で課金する。実際にライブで応答させる前に過去のチケットでシミュレーションできるため、解決率とコストを事前に把握でき、ベータ期間中の価格の当て推量とは無縁だ。これは、Claude Tagが未解決のまま残している予測の課題そのものに対する、予測可能なコストでの答えだ。
eeselを無料で試す、またはSlackサポート向けのAIについて詳しく知る。
Claude Tagの料金についての結論
Claude Tagには、そのまま引用できるような価格は存在せず、あるのはモデルだ。EnterpriseまたはTeamのサブスクリプションに、トークン使用量ベースの課金を上乗せし、序盤は本物のローンチクレジットで和らげられる。社内のエンジニアリングやオペレーションにとっては妥当な取引であり、製品自体もよく作り込まれている。一方、顧客サポートにとっては、使用量ベースのトークン課金は形として合わず、予測でき、シミュレーションでき、上限を設定できるチケット単位の価格のほうが、より役に立つはずだ。
導入を検討しているなら、品質面の評価についてはClaude Tagのレビュー全文を、仕組みについてはClaude Tagの解説記事を、トークン請求に不安があるなら代替ツールのまとめを読んでみてほしい。
そして、あなたのAIチームメイトが社内ヘルプデスクやTeams向けのITサポートボットでも活躍する必要があるなら、その対応範囲の欠落分も、実際のコストとして織り込んでおくべきだ。