Claude TeamとEnterpriseはどう選ぶ？利用枠・管理・連携要件で比較

会社でClaudeを使うときも、人数だけでは契約を決められません。誰を管理し、何を記録し、いつデータを消す必要があるかを書き出すと、Teamで足りる範囲が見えてきます。

Teamは2〜150人向けで、SSO、中央請求、管理、Standard / Premium席の混在を利用できます。Teamで仕事と管理の両方を満たせるなら候補にし、監査・保持・細かな権限に不足があるならEnterpriseを確認しましょう。 Enterpriseは、席料金に加えて利用量も予算へ入れる契約構造です。

Teamで始められるか、普段の仕事から確かめる

まず、利用する人と作業を書き出してみてください。文章を整える人、資料を調べる人、Claude Codeで開発する人では、利用の量や必要な席が変わります。Teamの主な機能と方針は次のとおりです。

• Standard / Premium席
• Claude Code
• 中央請求と管理
• 組織・利用者単位の支出上限
• SSO
• 組織内検索
• コネクターの管理者制御
• コンテンツを既定でモデル学習へ使わない方針

2〜150人の組織で、共通認証、請求の集約、接続先の管理をそろえて始めたいなら、Teamが候補になります。全員を同じ席にする前に、Standard / Premiumを誰へ割り当てるかと、利用量が増えたときの支出管理を決めておきましょう。

Standardで始め、枠が足りない担当者をPremiumへ

StandardにもClaude CodeとCoworkが含まれ、Premiumは同じ機能をより多く使うための席です。全員へPremiumを割り当てる前に、まず担当者ごとの使う量を見ます。

Teamの席	月払い／年払いの月換算	Pro比のセッション枠	選ぶ目安
Standard	25米ドル／20米ドル	1.25倍	文章・検索・開発を通常の頻度で行う人
Premium	125米ドル／100米ドル	6.25倍	長い資料やClaude Codeを集中的に使い、Standardの枠が不足する人

条件：米国向け税別価格、2026年10月24日確認。年払いは年間契約です。利用回数の保証ではなく、入力の長さやモデルで実際にできる作業量は変わります。Team公式案内に基づきます。

各席には全モデル共通の週次上限もあり、枠はメンバー間で移せません。更新時刻は本人の Settings > Usage で確認します。上限後も続ける場合は、Ownerが有効化した追加のusage creditsを使います。従来の席課金Enterpriseにもこの追加枠がありますが、利用量課金のEnterpriseには最初から含有利用枠がなく、最初のトークンからAPIレートで課金されます。追加利用の対象契約を、自社の見積もりと照合してください。

連携は、探したい資料と接続を許す管理者を決める

TeamにもGoogle Drive、Gmail、Google Calendar、GitHub、Microsoft 365、Slackなどのコネクターがあります。たとえば議事録・メールを横断して回答したいならDriveやGmail、社内会話と文書を探すならSlackやMicrosoft 365、開発資料を参照したいならGitHubを候補にします。連携名があるだけで、必要な全操作や書き込みまでできるとは判断しません。

管理者が接続先を許可しても、各利用者の接続と参照権限の確認は必要です。導入試験では「管理者が対象接続を許可する→担当者が認証する→閲覧を許された資料を質問する→引用元を開く」の順に確認します。Teamで接続先を満たせるなら、連携のためだけにEnterpriseを選ぶ必要はありません。監査・保持・ネットワーク制限も必要な場合に上位契約を照合しましょう。

ただし、これらがあることだけで、自社の管理要件を満たしたとは判断できません。たとえば「ログインできる人を管理する」ことと「退職日に利用者を自動停止する」ことは、必要な仕組みが違います。

SSOだけでなく、入退社の管理まで必要？

SSOは、会社で使う認証を通してログインする仕組みです。Teamにもあるので、次のようには決められません。

SSOが必要
= すぐEnterprise

まず、使っている認証基盤とTeamのSSOで必要なログイン条件を満たせるか確認します。それに加えて、入社・異動・退職に合わせた利用者情報の自動連携が必要なら、SCIMの提供条件も確かめます。アカウントの作成・更新・停止を同期するための機能です。

TeamはJITによる初回ログイン時のユーザー作成に対応しますが、SCIMには対応しません。 公式プロビジョニング手順は、SCIMをEnterpriseと対象Console組織に限定し、Teamは対象外と明記しています。TeamでもSSOでログインできることと、SCIMで利用者を自動削除できることは別です。

JITではIdP側の割り当てを外すとログインできなくなりますが、Claudeのメンバー一覧と席には残るため、管理者の削除が必要です。退職に合わせた自動削除まで必須ならEnterpriseを選び、対象のIdP、役割・席種の割り当て、停止後に残る接続やセッションを導入試験で確かめましょう。

Enterpriseの管理機能を、自社の困りごとへ当てる

Anthropicの料金ページでは、Enterpriseの追加機能として次が案内されています。用語だけで選ぶより、それを使って誰のどの作業を管理したいかまで決めてみてください。

• 細かなロールベースアクセス制御（RBAC）：管理者・利用者などの役割ごとに、操作できる範囲を分ける
• SCIM：会社の利用者情報に合わせて、入退社時のアカウント作成・更新・停止を同期する
• 監査ログ：誰が何を操作したかを後から調べる記録
• Compliance API：監視や監査対応に使う情報を、プログラムから取得するための窓口
• カスタムデータ保持
• ネットワークレベルのアクセス制御
• IP許可リスト
• HIPAA対応オプション

たとえば、利用者と管理者で許す操作を細かく分けたいならRBAC、接続元を限定したいならIP許可リストやネットワーク制御を確認します。案内されている機能名に加え、何を制御できるか、どの記録が取れるかを、採用する製品と契約へ照らします。

支出上限はTeamにもあります。その有無だけでEnterpriseへ進むより、必要な制御単位や、次の監査・保持の条件に不足があるかを見ると判断しやすいです。

「監査ログが必要」を、調べたい出来事まで具体化する

監査の担当者へ「何かあったとき、何を追いたいですか」と聞いてみましょう。ログがあっても、必要な操作が記録されなければ目的を満たせないからです。少なくとも次をそろえておきます。

• 誰がログを見るか
• 何を記録したいか
• 何日保持するか
• 複数サービスのログを集めて照合・調査するSIEMへ送るか
• 法務対応で電子記録を探し、保全するeDiscoveryが必要か
• インシデント時に何を追うか

この必要な証跡をTeamで取得できないなら、Enterpriseの監査ログやCompliance APIの対象を確認します。取得方法だけでなく、社内で受け取り、保管し、調べる担当まで決めておくと、導入後の運用につながります。

保持期間は、契約前に決めておく

会話をいつまで残すかも先に整理します。たとえば自社方針が次のように分かれるなら、それをそのまま確認条件へ使えます。

• 通常の業務チャットは90日
• 必要な記録は1年
• 法務保全対象のみ長期

これは保持方針の例で、Claudeの既定期間を示す数字ではありません。Enterpriseはカスタム保持を特徴として案内していますが、必要なデータと例外にまで適用できるかは契約時に確認します。法務要件で決まる保持を、導入後の設定調整だけで解決する前提にしないようにしましょう。

料金は、席の金額と使った量を分けて比べる

管理要件がそろったら費用です。TeamはStandard / Premiumの固定席料金が中心なので、各席の人数を分けて予算化します。多く使う人だけPremiumへ変更する構成も検討できます。

一方、この記事で確認した新しいEnterpriseの料金構造は、席料金に加え、利用量をAPIレートに基づいて課金するものです。Teamとの比較でEnterpriseの席単価だけを取り出すと、実際の利用分が抜けてしまいます。

比べる費用・条件	Team	Enterprise
固定費	Standard / Premiumの人数ごとに計算	席料金と契約形態を確認
利用量	必要な席と枠、追加支出の条件を確認	実利用量を席料金と別に見積もる
支出の管理	組織・利用者単位の上限	必要な制御単位と組織の支出上限を確認
管理の要件	含まれる管理で十分かを見る	高度な統制の範囲も一緒に設計

見積もりには、利用者数だけでなく、資料の長さ、作業の種類、利用頻度を伝えてください。APIレートに基づく課金という説明を、開発者向けAPIの契約まで同じものだと読み替えず、自社のEnterprise見積書で支払う範囲を確かめます。

作業の例には、最初の依頼だけでなく、読み直しや修正依頼も含めます。「長い仕様書を読み、質問へ答え、担当者が原文を確認する」までを一組にして、通常月と忙しい月の量を伝えると、利用量の仮定が見える見積もりになります。上限へ達したときに仕事を続ける方法と、追加利用を許可する人も決めておきましょう。

要件を一枚にまとめて、候補を残す

ここまでの違いを、契約前に確認する表へまとめると次のようになります。表の「要件確認」は、必要な内容を使えると確認できた意味ではありません。

要件	Team	Enterprise
Standard / Premium混在	対応	契約形態を確認
SSO	対応	対応
SCIM	非対応。JITは利用できるが削除は管理者が実施	対応。IdPと自動停止の範囲を確認
中央管理	対応	より高度
支出上限	組織・利用者単位	必要な制御単位を契約時に確認
RBAC	基本管理	細かな権限
監査ログ	要件確認	追加機能
Compliance API	-	追加機能
カスタム保持	要件確認	追加機能
IP許可リスト	-	追加機能
課金	席中心	席 + 利用量

Teamから始めやすいのは、2〜150人で、SSOとStandard / Premiumの混在で運用でき、高度な監査・保持やネットワーク制御を必須にしていない場合です。小さい範囲で実際の仕事を通し、利用枠と管理方法が足りるかを確かめましょう。

試す前に、担当者ごとの仕事、使う資料、見てはいけない資料、確認する人を一行ずつ書いておくと、試験後の判断に使えます。回答を直して完成させる時間が減り、必要な情報だけを参照でき、想定した利用枠で続けられるかを見ます。枠だけが不足するなら席の配分や追加利用を見直し、監査や保持の必須条件が足りないならEnterpriseの相談へ進みます。

反対に、SCIMによる入退社の自動同期、150人を超える展開、細かなRBAC、監査ログやCompliance API、カスタム保持、IP許可リストやネットワーク制御が必須なら、先にEnterpriseの条件を確認します。Teamの支出管理では必要な制御単位を満たせない場合や、個別の契約・コンプライアンス要件がある場合も同じです。

最初にすることは、利用者一覧と、外せない管理要件を一枚に書くことです。Teamで満たせる条件と、契約窓口へ確かめたい条件を分ければ、「上位だから安心」ではなく、自社で運用できる理由を持って選べます。購入時には公式料金、実際の管理画面、見積書を合わせて確認してください。