Claude Team・Enterpriseの選び方｜人数・管理機能・データの扱いで決める

法人でClaudeを導入するとき、多くの担当者が最初に迷うのがTeamとEnterpriseの選択です。検索上位の解説を眺めると、その答えを利用人数に求めているものが目立ちます。たとえば、50名を境にEnterpriseへ移る、あるいは100名以上ならEnterprise以外にない、といった決め方です。

先に答えを示すと、社員数だけでは適切なプランを決められません。20名の組織でもEnterpriseが不可欠な場合がある一方、120名いてもTeamで要件を満たせることがあります。見るべき分岐点は人数ではなく、社内外から書面で課されている条件の有無です。監査記録の保存、従業員情報との自動連携、会話データの機械的な取得などが、規程や監査上の指摘に明記されていれば、規模を問わずEnterpriseを検討します。反対に、そのような要求が存在しないなら、より高い席単価を負担する根拠は薄くなります。

もうひとつ注意したいのは、検索で見つかる比較記事の料金表や機能表が、現時点の公式情報と一致するとは限らないことです。本稿では第三者の記事から数値を転載せず、公式サイトで直接確かめた情報を、参照した日付とともに整理します。

料金と機能を調べる際は、Claudeの公式料金ページ、Anthropicヘルプセンターの「What is the Enterprise plan?」、プライバシーセンターの「商用製品のデータ利用」を一次情報として確認しました。確認日は2026年9月4日です。為替変動で記載がすぐ古くなることや、経理上の換算レートが曖昧になることを避けるため、金額は円に直さず米ドルで示します。料金、プラン構成、利用できる機能は今後変更される場合があります。契約時には、公式サイトに掲載された最新の条件を必ず確かめてください。導入実務に関する記述は当社や支援先で得た経験を土台にしていますが、個人を識別できる情報、具体的な企業名、個別契約の金額は伏せています。

上位記事を読んで見つけた食い違い

執筆に先立ち、「Claude Team Enterprise 違い」や「Claude 法人プラン 選び方」などで検索し、上位に現れるページを確認しました。比較表だけでなく、社内調整や移行の進め方まで詳しく説明した記事が多く、内容も丁寧です。中には1万5千字を超える解説や、導入支援の経験をもとにしたケース紹介もあり、読み物としてよく練られていました。

ところが、公式サイトの現在の表示と照合すると、整合しない説明が複数見つかりました。とくに選定へ影響するのは、以下の3点です。

最初の相違はTeamを利用できる最少人数です。いくつかの記事は開始条件を「5名から」としていますが、公式料金ページの対象は「2〜150名のチーム」です。下限が5名だと受け取れば、3名の組織は契約できないものと思い、候補から外してしまうでしょう。公式表示では2名から利用可能です。

次の相違はSSOの位置づけです。SSOとは、社内の認証システムを使って各サービスへのログインを一元化する仕組みです。これをEnterprise限定とする解説もありますが、公式比較表ではTeamの機能にもSSOが含まれています。この認識違いは余計な支出につながりかねません。SSOが必要という理由だけでEnterpriseを前提に起案すると、必要のない価格差まで負担する可能性があります。

最後は用意されている席種の違いです。現在の公式料金ページを見ると、Teamにはスタンダードシートとプレミアムシートがあり、利用量に合わせて選べる設計です。それに対し、検索上位には全席を単一種類として計算している比較表が少なくありません。全員が同一の席を使う前提では、実際の利用に即した見積りになりません。

ここで強調したいのは、既存の記事の品質を責めているわけではないということです。クラウドサービスでは料金やプランの仕組みが年に何度も更新される場合があります。公開時に正確だった記事でも、閲覧時には事情が変わっていることがあります。したがって、ウェブ記事の表を確認せず稟議資料へ転用するのは避けましょう。契約前に公式ページで料金と機能を再確認し、その日付も資料に記録することが、情報の陳腐化による誤りを防ぎます。

当社でも過去に、Claudeとは異なるサービスの見積りを、検索上位に出てきた料金表から作ったことがあります。提出前に一次情報を調べたところ、公式価格とは一致していませんでした。その経験以降、外部サービスの価格を扱うときは、確認日の記録と公式ページの画面保存を一組にしています。

公式ページで確認した事実

ここでは、2026年9月4日に公式サイト上で確認できた情報をまとめます。あくまで当日に掲載されていた条件であり、将来も同じとは限りません。閲覧時点の最新情報と照らし合わせてください。

Teamプランの概要です。公式には2〜150名のチームを対象とし、席種は2つあります。スタンダードシートは、年払いなら1席につき月$20、月払いなら月$25です。プレミアムシートは、年払いで1席あたり月$100、月払いでは月$125です。ヘルプセンターでは、Teamのどの席でもClaude Codeを利用できると案内されています。組織向け機能として、請求の集約、SSO、管理者による連携機能の制御、業務端末への展開、利用分析、組織内へのスキル配布が挙げられています。

Enterpriseプランの概要です。営業担当者を介さないセルフサービス契約では最低20席、営業経由の契約では最低50席とされています。選べるのは年払いのみです。料金は「各席$20に加え、API相当レートの使用量課金」という構成です。ヘルプセンターの説明によれば、席料金はプラットフォームに入るための費用であり、Claude、Claude Code、Coworkの利用分はすべて標準APIレートで別途発生します。また、席単位の使用上限も、初めから含まれるトークン枠も設定されていません。

Enterpriseに限定される機能も確認します。公式比較表でTeamにはなくEnterpriseに提供されるものは、SCIM、監査ログ、コンプライアンスAPI、カスタムデータ保持、ドメインキャプチャです。SCIMは人事システムなどの在籍データと連動し、入退社に伴うアカウント作成や停止を自動化します。ドメインキャプチャは、会社のドメインを使って登録されたアカウントを組織管理下へ取り込む仕組みです。さらにヘルプセンターでは、顧客自身が管理する暗号鍵、推論処理を米国内に限る選択肢、きめ細かな権限を割り当てられる役割ベースのアクセス制御も紹介されています。

この機能群から読み取れるのは、Enterpriseの価値が主に操作の証拠を残すことと、従業員アカウントを自動で統制することにあるという点です。個人の作業速度を直接高めるための追加機能ではありません。第三者へ管理状況を説明しなければならない組織を支える仕組みと捉えると分かりやすいでしょう。説明先には監査法人、親会社、認証機関、セキュリティ質問票を送る顧客などがあります。そうした相手がいない組織では、これらを導入しても日常作業が1分短くなるわけではありません。

人数で決めると、なぜ間違えるのか

「50名を超えたらEnterprise」という目安が浸透する背景は単純です。社員数なら簡単に把握できるからです。社内の要求事項を探すには時間が必要ですが、在籍人数は総務に尋ねれば5秒ほどで判明します。

ただし、人数だけを物差しにすると、方向の異なる2種類の誤りが生じます。

ひとつは、求められていない上位機能に費用を払うことです。社員が60名いても、監査記録を求める部署や外部関係者がおらず、年間の入退社が数名なら、総務による手作業でもアカウントを管理できます。それでも50名を超えたという理由だけでEnterpriseにすると、席料金だけでなく利用量に応じた課金も受け入れることになります。さらに、Enterpriseには最低席数があり、支払いは年単位に限られます。運用開始後にTeamで足りたと判明しても、契約年度の途中では切り戻せません。

もうひとつは、本来必要な統制機能が足りなくなることです。社員25名の会社が上場準備を進め、内部統制を整備しているとします。監査法人から生成AIの利用履歴をどのように保存するか質問された場合、組織が25名でもTeamだけではその要求を満たせません。監査ログとコンプライアンスAPIがEnterpriseだけの機能だからです。「25名ならTeamで足りる」と人数だけで結論を出せば、監査対応が迫ってから不足へ気づく恐れがあります。

導入相談の現場では、必要な機能への気づきが遅れる後者の例がとくに目立ちます。当社は最初に人数を尋ねるのではなく、過去1年の間に情報システムの利用実態について外部から照会を受けたかを確認します。照会された経験がある企業は、小規模であっても説明に必要な証拠を取り出せる体制が安全です。これまで要求がなく、近い将来にも見込まれないなら、現段階でその機能へ支払う必然性はありません。

順番1｜文書で出ている要件だけを集める

ここからは、選定を4つの段階に分けて解説します。進める順序も重要で、途中で選択が確定したなら、残りの段階を無理に実施する必要はありません。

初めに、関係部署が求める条件を集約します。ここでは対象を厳密にし、書類上で確認できる要求だけを採用してください。口頭で出た懸念や漠然とした心配、「念のため欲しい」といった希望は、この段階の要件には含めません。

調査対象になるのは、主に以下の資料です。

• 情報資産管理規程や情報セキュリティ規程——社外サービスについて、利用者の識別方法やログの保存期間が定められているかを調べる
• 内部監査・監査法人による指摘の記録——生成AIだけでなく、SaaSの統制全般に関する改善要求がないかを確認する
• 取引先から届いたセキュリティ確認票——過去1年分を対象に、アクセス記録の保管や再委託先管理へどう回答したかを見直す
• 直近の審査結果とISMS・Pマークの適用範囲——認証取得済みの企業では、具体的条件を見つける有力な資料になる
• 人事システム導入に関する計画書——従業員データとの自動同期が決定済みなら、SCIMを必要条件に含める

この確認には1〜2週間を割くのが適切です。短期間で終わらせようとすると、安心のために全機能を付けるという結論へ傾きます。当社の支援では、要求を1枚の一覧にまとめ、それぞれの出典として資料名と掲載ページを記入します。根拠欄を埋められない項目は要件ではなく懸念として扱い、選定条件から一度外します。

SCIM、監査ログ、コンプライアンスAPI、カスタムデータ保持、ドメインキャプチャというEnterprise固有の5機能の中に、出典を示せる要求がひとつでもあれば、その時点でEnterpriseを選択肢として具体的に検討します。該当項目がなければ、Teamから始めても問題ありません。この判断に社員数は影響しません。

外部への説明責任がある企業向けの設計範囲は、Claude Codeのセキュリティ設計で、情報の分類や保護方法とともに紹介しています。必要条件の抽出が進まないときは、先にこちらを参照すると整理しやすくなります。

順番2｜席を使い方で3つに分ける

要求事項を照合してTeamで対応可能と分かったら、必要な席を見積もります。在籍者の総数をそのまま購入席数にするのは避けましょう。公式に2種類の席が用意されているため、全員へ同じ種類を割り当てる必要はありません。

当社では利用者を次の3群に分けています。

第一は日常的に利用する人です。ローカルファイルを直接処理させる人、定型作業を組み立てる人、長文を生成する人などが当てはまります。利用量が大きくなりやすいため、上位の席が適しています。公式案内でも、プレミアムシートはより多く使える選択肢として説明されています。

第二は週に何度か利用する人です。調査、資料の要点整理、文案作成といった限定的な用途が中心です。この層には標準の席で十分でしょう。

第三は当面利用しない人です。この区分を設けることが重要です。全社員への一斉配布は、導入で生じやすい失敗の代表例です。学習機会を与えないまま席だけ付与すると、ログインされずに利用料だけが発生します。未使用の席は、点検しなければ放置され続けます。

ある支援先では、導入から半年後に確認すると、割り当てた席の3割以上が一度も利用されていませんでした。全社員へ配れば自然に利用が広がるという方針で開始していたためです。アカウントの付与は、実際の活用を保証しません。対象者が使える状態になるまでの展開方法は、情シスのためのClaude Code導入設計で順を追って解説しています。

購入時には、初回から全社員分を確保しないことを勧めます。毎日使う層と週に数回使う層だけで開始し、利用状況を確かめて追加します。Teamは契約後でも席を増やせます。増席しやすく減席しにくいという違いを織り込んで、最初の数量を抑えるのが基本です。

順番3｜費用の「形」が変わることを知る

検索上位の解説で十分に扱われていなかったのが、課金構造です。TeamとEnterpriseの差は金額だけではなく、固定される費用と変動する費用の組み合わせにもあります。

Teamの支出は、購入する席数と定額料金の掛け算です。各席の月額が決まっているため、席数さえ確定すれば年間予算も算出できます。利用が増えても請求額は動かず、稟議書にも年間費用を明記できます。

Enterpriseでは、席そのものの費用とは別に、使用量に応じた金額が加算されます。公式表示では各席$20にAPI相当レートの利用料を足す方式です。ヘルプセンターも、席料金はアクセス権の対価で、実際の利用には別料金がかかると説明しています。そのため、契約前に年間の総額を完全に確定することはできません。

従量課金を導入すると、経理部門と情報システム部門に管理業務が生まれます。利用額が変動する以上、消費状況を継続的に確認する担当者が必要です。月ごとの進み方を追い、想定以上なら原因を調査します。利用が特定部署へ偏っていないか、誤った反復処理が走っていないかも点検対象です。監視の責任者を置かないまま始めれば、請求時に初めて予算超過を知ることになりかねません。

もちろん、使用量に連動する方式には長所もあります。利用の少ない時期は請求も小さくなります。席単位の上限がないため、大量処理を行う部門は上限による中断を避けられます。会計上は、予測しやすい固定費から利用に応じる変動費へ性格が変わると理解してください。優劣ではなく、自社の予算統制で扱いやすい方式かどうかが選択の焦点です。

年度の支出額を1円単位まで先に承認する企業では、変動費を受け入れるための社内調整が必要です。当社の支援先でも、技術評価よりこの調整に長くかかった例がありました。情報システム側が導入に合意しても、経理側が上限不明の費用を稟議に載せられないと判断したためです。最終的には、内部上限を先に定め、到達時に利用を止める監視方法を用意して解決しました。必要なのは製品設定だけでなく、費用を管理する運用です。

導入効果を社内で示す方法は、Claude Codeの費用対効果を社内で説明するで測定の考え方をまとめています。価格を比較する前に、どの成果を効果として評価するかを合意すると、意思決定が進みやすくなります。

順番4｜途中で席を減らせるかを確認する

選定手順の最後では、契約期間の途中で購入席を減らせるかを確認します。公式ヘルプセンターには、この条件がはっきり示されています。

セルフサービス型のEnterprise契約については、年次契約が続いている間の減席はできないと説明されています。追加の席は随時購入できるものの、席を減らす申請が有効になるのは次回更新時です。

具体例で影響を考えてみましょう。4月に30席で利用を開始し、6月に2名が退職、9月に3名が異動して利用対象から外れたとします。空席は合計5つになりますが、次年度の更新までは30席分の料金が続きます。途中返却はできません。

入退社や配置換えが頻繁な組織ほど、この条件は予算に響きます。最低席数で開始するか、将来分を見込んで余分に買うかは慎重に決めるべきです。当社では、必要最小限から始め、不足が生じた時点で追加する考え方を採用しています。増席はいつでも可能だからです。

また、この契約条件があるからこそ、後述する定期的な席の見直しが欠かせません。期中に削減できなくても、更新時の適正数を判断できるよう、利用実績を前もってそろえます。それが棚卸しの目的です。

管理者からは何が見えて、何が見えないか

Enterpriseの導入を検討すると、社員からほぼ必ず、会話内容を上司が閲覧できるのかと質問されます。

この疑問への伝え方は、導入後の活用度を大きく左右します。説明が曖昧なら、従業員はリスクを避けるため利用そのものを控えます。見られる可能性を恐れて無難な情報しか扱わなければ、導入効果は得られません。

公式情報では、Enterpriseに監査ログとコンプライアンスAPIが提供されます。ヘルプセンターによると、監査ログには利用者の操作、システム上の出来事、データへのアクセスに関する重要情報が残る仕組みです。コンプライアンスAPIを使えば、プログラムから利用データを取得し、対象ユーザーや期間で結果を絞れます。

組織が必要に応じて記録を抽出できる状態になる、という点は明確に伝える必要があります。事実を曖昧にしてはいけません。

当社が導入を支援する際には、利用開始より前に書面で従業員へ知らせるよう提案しています。説明事項は以下の3つです。

• 保存される情報の範囲——サービス利用の履歴を組織が取得できる状態になると明示する
• 閲覧する人と発動条件——常時監視ではなく、事故対応や監査など必要な場面で、所定の手続きに沿って確認すると定める
• 記録を持つ目的——顧客や監査関係者に管理状況を説明するためだと共有する

事前説明を実施した組織と省いた組織では、利用開始後の定着に明確な差が出ます。説明がない現場では、導入から数か月たっても、何を入力してよいのかという問い合わせが繰り返されます。迷いが解消されない限り、ツールを配っても仕事の処理時間は縮まりません。

Teamを採用する場合にも、情報の見え方を説明しておくべきです。監査ログが提供されないことと、利用記録が一切存在しないことは同義ではありません。Teamにも利用状況の分析や請求の集約があるため、利用者ごとの使用量に相当する情報は組織が把握できます。会話本文と利用量を区別し、内容は見えない一方で使用状況は見えると正しく案内しましょう。

入力可能な情報の境界については、Claude Codeで情報漏洩を防ぐで、許可するデータと禁止するデータを整理しています。プラン決定と同時に、社内の入力基準も文章にすることを推奨します。基準がないままアカウントだけ渡すと、利用者は安全な範囲が分からず慎重になりすぎます。

入力した内容は学習に使われるのか

モデル学習へのデータ利用も、社内承認で高い確率で問われる論点です。憶測ではなく、公式文書の説明に沿って整理します。

プライバシーセンターでは、Claude for WorkやAPIなど商用製品への入力および出力は、初期設定の状態ではモデル学習へ使われないと説明されています。ただし、利用者が親指の上下ボタンなどから明示的に意見を送信した場合や、データ利用へ同意した場合は例外となり、会話が学習対象になることがあります。フィードバックとして送られたデータについては、保護された環境で最長5年間保存し、学習利用の前にユーザーと顧客を識別する情報から分離するという案内もあります。

運用へ落とすと、取るべき対応は明快です。稟議に初期設定では学習へ使われないとだけ書いて終えるのは不十分です。評価操作が例外になる以上、社内の利用規則にも注意事項を1行加えましょう。

当社の研修では、業務情報を含むやり取りでは評価ボタンを操作しないよう必ず案内します。システム設定で禁止できない行為は、利用者教育によって統制する必要があります。

なお、これはTeamとEnterpriseのどちらを選ぶかとは別の問題です。既定のデータ取扱いも必要な注意も、両プランで変わりません。学習利用への懸念だけを理由にEnterpriseを採用するのは適切な判断ではありません。このリスクは上位プランではなく、社内教育とルール整備によって抑えます。

支払い方法という、意外な決定要因

必要な技術機能が同じでも、決済に関する社内規程によって選択が変わる企業があります。検索上位の記事でも支払い方法には触れられていましたが、実務での影響は説明以上に大きい論点です。

公式ヘルプセンターの案内では、セルフサービスでEnterpriseを申し込む場合、クレジットカードまたは銀行振替を使い、米ドルでクレジットを前払い購入します。営業担当経由なら、請求書払い、複数の通貨、月末締めによる後払いを利用できます。

日本企業では、この違いだけで契約方法が決まることがあります。社内規程でクレジットカードの月間利用限度額が定められている会社は珍しくなく、年間費用の一括前払いをカードで処理できない場合もあります。外貨決済を禁止している企業であれば、セルフサービス契約はそもそも選べません。

当社が関わった案件でも、情報システム部門が選定を終えた後、経理部門から決済条件を理由に差し戻されたことがありました。こうした手戻りは、最初の要求確認で経理へ短く質問すれば防げます。外貨建て、年間前払い、カード決済を承認できるか、早い段階で確認してください。これだけで終盤の再検討をひとつ減らせます。

ただし、営業担当を通す契約では、公式情報上の最低席数が50席へ上がります。請求書でなければ支払えない一方、必要数が50席未満の組織は、決済要件を変更するか、Teamで運用するかを選ばなければなりません。この制約を初期段階で共有しておけば、成立しない条件で交渉を続けずに済みます。

席の棚卸しを四半期で回す

ここからは契約開始後の管理について考えます。検索上位で確認した記事には、この運用まで解説したものがありませんでした。選定方法は詳しくても、導入後に席を適正化する方法は抜け落ちがちです。

当社は四半期ごとに、以下の5項目を点検しています。

1. 過去30日間にログインしていない席。退職後も残ったアカウント、異動後に不要になったアカウント、付与後一度も使われなかったアカウントが、この確認によってまとめて見つかります。契約中に席を返せない場合でも、更新時の必要数を決める資料になります。

2. 利用負荷が高い席。標準の席では不足している利用者を見逃していないか確認します。上限へ頻繁に達し、作業が止まっていれば、その時間だけ導入効果が失われています。上位席への変更が妥当な人を、管理側から特定します。

3. 利用実績がない人。未使用だからといって、すぐに席を解除してはいけません。使わない主な理由は、操作方法を知らないこと、または入力可能な情報の範囲が分からないことです。まず研修や説明の対象とし、その後も利用しない場合に割り当てを見直します。当社の経験でも、個別に案内すると利用を始める人が一定数います。

4. 管理者権限の保有者。特権を持つ利用者は追加されやすい反面、不要になっても削除されにくい傾向があります。一時対応のために与えた権限が、作業後も残り続けるためです。四半期ごとに保有者を実名で一覧化し、現在も業務上必要かを個別に判断します。

5. 契約の次回更新日。減席の機会が更新時に限られるなら、その日から逆算して準備します。更新日の1か月前までに必要席数を確定できるよう、あらかじめ予定を設定します。

これら5項目を単一の表へまとめ、四半期ごとに更新します。確認作業に必要なのは30分程度です。点検を習慣化していないと、更新期限の直前になって適切な席数を判断できず、慌てることになります。

当社が席をどう配っているか

参考として、一次情報である当社の運用方法も紹介します。当社は小規模なので、すべての企業へ同じ形が当てはまるわけではありませんが、考え方は規模を問わず応用できます。

当社では、営業や経理、人事、総務などバックオフィス全般をAIで支援しています。席を設計するとき、初めに利用者を毎日使う層と、それ以外の層へ分けました。全員へ画一的な席を渡さない方針です。

続いて、利用権限を設計しました。席種とは切り離して、許される操作と禁止する操作を設定ファイルによって強制しています。メールを例にすると、送信に必要な権限そのものを与えていません。文案は作成できますが、そのまま送ることはできない構造です。利用者の注意力に頼らず、設定で禁止を実効化している点が重要です。

この方針はプラン選びにも関係します。サービスの管理機能と、個々の作業を制限する設定では、担う範囲が異なります。前者は組織全体に対する大枠の統制であり、後者は作業単位の細かな統制です。大枠の機能だけで安全性を確保しようとすれば、必要以上に高い席を選び続ける結果になりかねません。先に細部の権限制御を整えることで、上位プランが不要になる場合もあります。

設定ファイルと自動ブロックの実装例は、Claude Codeの権限設計を実例でに掲載しています。プラン比較と並行して、作業レベルの権限も設計しましょう。片方だけを整えても、費用と安全の両方を最適化することはできません。

加えて、当社では評価用のフィードバックボタンを使わないと定めています。すでに説明したとおり、通常は学習に利用されなくても、明示的な評価送信は例外です。業務データが含まれる会話から評価を送信しないという決まりを、設定ではなく行動規範に記し、全員へ共有しています。

切り替えで起きる3つの失敗

TeamからEnterpriseへ変更する場合と、導入当初からEnterpriseを選ぶ場合の両方で起こりやすい失敗を、3つに整理します。

失敗1｜社内条件の確認より先に見積りを依頼する。よくあるのが、営業担当者から価格提示を受けた後に、必要な機能を社内で調査する進め方です。この順序では、提示された構成の各機能が本当に必要か判断する根拠を持てません。結果として提案された内容を丸ごと受け入れやすくなります。先に根拠のある要求を整理し、それを満たす最小構成を問い合わせましょう。

失敗2｜将来を見越して余分な席を購入する。後で増やす手間を避けたいという理由で、多めに契約する例があります。契約期間中に減席できない以上、使わない席の先買いはそのまま不要な支出になります。公式には随時追加できると案内されています。増やせても減らせないのであれば、初期数を小さくするほうが合理的です。

失敗3｜利用者への告知を契約後に行う。設定を完了してから社員へ説明すると、その時点で初めて履歴取得を知った利用者は警戒します。告知は契約前に済ませてください。記録される範囲、閲覧する担当者、確認が行われる条件を具体的に示します。先に理解を得ておけば、提供開始日から迷わず利用してもらえます。

プラン以外も含む導入時の障害は、Claude Code法人導入でよくある失敗10で別の視点から解説しています。開始前に目を通すと、選定後のやり直しも抑えられます。

稟議に載せるときの書き方

採用するプランが決まったら、社内承認の手続きへ進みます。ここでは、決裁者が判断に使う情報と、情報システム担当者が詳しく説明したい内容の違いを意識しましょう。

情シス側は機能を網羅した比較表を用意しがちですが、決裁者が押さえたい要点は次の3つです。

• 年間支出と上限の予測可能性。Teamは固定費として総額を示せます。Enterpriseについては席料金と従量利用料の組み合わせだと記し、利用上限を監視する方法も併記します。金額を予測できないという説明だけでは、承認判断が止まります
• 選定したプランでなければならない根拠。最初の手順で集めた、文書上の要求と出典を示します。該当する規程の条文や監査指摘の時期まで記載できれば、必要性が明確になります。出典が存在しない機能は、必要性を裏付けられません
• 利用を終了する際の条件。契約の期間、期中解約の扱い、減席が反映される時期を記載します。導入方法だけで撤退条件を示さない稟議ほど、慎重な承認者には通りにくくなります

また、価格は米ドル表記を維持し、調査した日付も必ず記載してください。円換算額を示すと、承認までの数週間に為替が変わり、使用したレートの時点を確認されます。「$◯／席・月（公式ページの確認日：2026年◯月◯日。価格改定および為替により変動）」のように書けば、金額に関する追加質問を抑えられます。

法人向けプランの選定や費用根拠の作り方は、Claude Codeの料金は？法人プランの選び方と費用対効果の考え方でも詳しくまとめています。本稿で候補を絞った後、その内容を起案へ落とし込む際に参照してください。

この判断で見てはいけない指標

最後に、選定を誤った方向へ導きやすい数字や考え方を確認します。

他社における導入企業数。多数の企業が利用しているという実績からは、自社に合うプランを判断できません。事例に登場する企業と自社が、同じ監査要件や運用条件を持つとは限らないためです。

搭載機能の個数。比較表で対応項目の多いプランを選んでも、利用しない機能への支払いが増えるだけです。機能数ではなく、文書から抽出した自社の要件を満たせるかだけを確認してください。

第三者の記事にある削減率や成果の数値。一次情報をたどれない数字を承認資料に使うべきではありません。根拠を質問されたとき、出典を説明できないからです。効果を数値で示すなら、小規模な試行から自社データを取得するほうが早く、説得力も高まります。

周囲の企業がEnterpriseを採用しているという雰囲気。客観的な指標ではありませんが、意思決定へ強く影響しがちです。必要条件がないまま上位契約へ変更しても、増えるのは安全性ではなく費用です。セキュリティはプラン名ではなく、権限管理と社内規則の組み合わせで作ります。

よくある質問

Teamの対象上限である150名へ近づいた時点で、Enterpriseへの変更は必須でしょうか。
公式料金ページはTeamを2〜150名向けとしているため、上限に近い組織では次のプランを検討する時期になります。ただし、社員数だけを理由に切り替える前に、必要機能を改めて調べてください。150名規模であれば、監査対応やアカウント管理に関する要求が、すでに社内文書などに存在するケースも多いでしょう。見つからない場合は、要件の収集から始めます。人数条件は変更される可能性があるため、最新の公式表示をご確認ください。

Claude Codeの利用にはプレミアムシートが必要ですか。
2026年9月4日に参照したヘルプセンターでは、Teamの全席にClaude Codeが含まれると説明されています。一方、利用できる量は席種によって異なる位置づけなので、負荷の高い用途には上位席が適します。機能を利用可能かという点と、制限を気にせず使えるかという点は分けて考えましょう。標準席から運用し、実際に上限へ達する人だけを変更する進め方が無駄を抑えます。

運用途中でTeamからEnterpriseへ変更できますか。また、移行にはどの程度の手間がかかりますか。
ヘルプセンターにはプラン移行の手順が掲載されています。見落としやすいのは、システム上の操作よりも、組織内の調整に時間がかかることです。認証環境の構築、経理処理の変更、従業員への説明し直しが必要になり、完了まで数週間を要する場合があります。切り替えを予定するなら、契約更新日から逆算し、2か月ほど確保すると安心です。

監査ログはどれくらいの期間保存されますか。
設定内容や契約条件によって保持期間が異なるため、ここでは特定の日数を提示しません。Enterpriseにはカスタムデータ保持があり、保存期間を調整できる機能として位置づけられています。文書上の要件に◯年分の保存とある場合は、その期間を満たせるか契約前に営業担当者へ確認しましょう。最終的な根拠になるのは解説記事ではなく、契約書へ明記される条件です。

最低席数を満たさない小規模企業が、Enterprise相当の監査要件へ対応するにはどうすればよいでしょうか。
率直に言えば、製品機能だけでは充足できない要件が生じます。その不足は運用ルールによって補完します。利用可能な業務を限定し、入力してよい情報を文書化し、社外へ影響する操作権限を最初から渡さないといった方法です。操作後の証跡へ依存する代わりに、証跡を求められる操作自体を実行不能にする設計と考えます。監査や審査で求められる説明は組織ごとに異なるので、実際の要求文をもとに対策を組み立ててください。

最初に着手すべき作業は何でしょうか。
まず1〜2週間を確保し、社内外の要件を集約します。価格を問い合わせるのは、その作業を終えてからです。資料名とページという出典を記載できる条件だけを残しましょう。Enterprise固有の5機能の中に、根拠資料から必要と判断できるものがあるかを確認します。この問いへ答えられれば、選定作業のおよそ8割は完了です。

まとめ

• 社員数を決定基準にしないこと。20名でもEnterpriseが必須になる組織がある一方、120名でもTeamで対応できる場合があります。判断を分けるのは、監査ログ、SCIM、コンプライアンスAPI、カスタムデータ保持、ドメインキャプチャのどれかが、根拠文書によって求められているかです
• 検索上位の比較表をそのまま社内資料へ転記しないこと。公式情報と照らすと、最低人数、SSOの位置づけ、席種について相違が確認できました。料金体系は更新されます。必ず公式サイトを再確認し、調べた日付も記録しましょう
• 選定は4段階で進めること。①書面にある要求を抽出する、②利用方法に応じて席を3分類する、③固定費か従量費かを比較する、④契約中の減席条件を調べる、という順です。途中で答えが確定すれば、後続の検討は省けます
• 価格の大小に加え、課金構造を確認すること。Teamは席数に定額を掛けるため年間予算を決められます。Enterpriseは席料金へ利用料が加わるので、使用状況の監視担当を置かなければ、請求時に想定との差が発覚します
• 初回の購入席数は抑えること。公式案内では、セルフサービス型Enterpriseは年次契約中に減席できず、変更は更新時に有効になります。追加は容易でも削減は難しいという条件を、見積りへ反映してください
• 管理側が把握できる情報を、契約前に従業員へ文書で知らせること。事前告知がなければ、導入後も入力可否への不安が現場に残ります。迷って使えない期間は、業務改善も進みません
• データの学習利用はプラン差ではないこと。公式説明上、商用サービスの入出力は初期状態で学習へ使われませんが、明示的なフィードバックは例外です。評価ボタンを使わないという注意は、システム設定ではなく研修で周知します
• 決済要件が選択を左右する可能性を見込むこと。外貨払い、年間の前払い、カード決済を社内経理が認めるか、検討初期に確認しましょう。承認直前の差し戻しを避けられます
• 導入後は四半期ごとに30分の点検を実施すること。未ログイン席、高負荷な席、未利用者、管理者権限の保有者、次回更新日という5項目を、ひとつの管理表で追います
• 導入企業の数、搭載機能の多さ、根拠を追えない削減率に引っ張られないこと。組織の安全性を作るのは上位プランの名称ではなく、適切なアクセス制御と社内ルールです

TeamかEnterpriseかを決める作業は、どちらの機能が優れているかを競わせるものではありません。自社が第三者への説明責任を負っているかを確認する工程です。説明が必要なら、証拠を残せる機能を採用します。要求がなければ、差額を研修や運用整備へ振り向けたほうが、実際の業務改善につながります。最初の1〜2週間は、書面で確認できる要件の収集に使ってください。出典つきの一覧が完成すれば、プラン選びの大部分は済んでいます。

部署別にAIを導入する業務の順番を決めたい場合は、職種別のAI実践研修もご参照ください。

当社は、エンジニア職ではない社員がClaude Codeを日々の仕事へ安全に取り入れられるよう、初期設計から社内定着まで支援しています。必要条件の整理、適正席数の算定、権限ルールの構築、従業員向け説明資料、四半期点検のひな型を、それぞれの企業の組織体制や規程に合わせて設計します。初回相談には費用がかかりません。

自社の条件に合うプランを一緒に見極めます
初回相談とお見積もりは料金不要です

無料相談について詳しく見る →