入口を決め（第1回）、データの通り道を決めた（第2回）。最後に残るのが、「誰と、どんな契約で結ぶか」です。Claude を法人で正式導入するとき、選択肢は大きく Team（チーム） と Enterprise（エンタープライズ） の2つ。
多くの方が「人数と値段の違いでしょ？」と思っていますが、本質はそこではありません。大きな違いは、ポリシーと契約、そして管理者が組織をどこまで統制できるか（ガバナンス機能）です。今回はその判断軸を整理して、シリーズを締めくくります。
「人数の違い」だと思うと選び方を間違える
Team と Enterprise を「少人数向けか大人数向けか」とだけ捉えると、判断を誤ります。本当の分かれ目は、「その導入に、情シス・法務・セキュリティ部門の関与が必要かどうか」です。
たとえるなら、会議室を借りるのか、フロアごと契約するのかの違いです。会議室（Team）は予約すればすぐ使える。フロア（Enterprise）は、入退室の管理、鍵の権限、利用記録まで自社のルールで縛れる代わりに、契約も導入も重くなります。規模ではなく「どこまで自社の統制を効かせたいか」で決まります。
2つのプランを観点ごとに整理する
| 観点 | Team（チーム） | Enterprise（エンタープライズ） |
|---|---|---|
| 位置づけ | 部署・チーム単位で素早く使い始める | 全社規模で、統制下に正式導入する |
| 契約・ポリシー | 標準的な利用規約ベース。手続きは軽い | 個別契約・条件交渉の余地。法務審査に耐える形にしやすい |
| ID 管理 | 管理者がメンバーを招待・管理（SSOも利用可能） | SSOに加え、SCIM（入退社にあわせた利用者の自動追加・削除）で全社の認証基盤に統合しやすい |
| 権限・統制 | 基本的な管理者／メンバーの区分 | より細かい権限管理・利用範囲の制御 |
| 監査・可視化 | 限定的 | 監査ログなど、利用状況を組織として追える仕組みが手厚い |
| データの扱い | 業務利用前提（学習に使わないのが基本） | 保持期間など、データ取り扱いをより細かく制御・取り決めしやすい |
本質は「ポリシーと契約」にある
機能表だけ見ると「Enterprise は高機能版」に見えますが、企業導入の現場で効いてくるのは契約の中身です。とくに次の3点は、Enterprise でなければ満たせないことが多い。
- 法務が審査できる契約形態か：標準規約への同意だけでなく、自社の基準に沿った条項で結べるか
- データ取り扱いの取り決め：保持期間・処理場所・再学習不使用などを、契約として明文化できるか
- 責任範囲とサポート：問題が起きたときの窓口・対応・責任分界が定義されているか
つまり Enterprise の価値は「使える機能が多い」より、「セキュリティ部門と法務が首を縦に振れる状態をつくれる」こと。全社展開で本当に効いてくるのはここです。
ガバナンス機能 ― 管理者にとっての違い
もう一つの軸が、管理者（情シス）が組織をどこまで統制できるかです。Enterprise 側で手厚くなる典型は次のようなもの。
- SCIM（入退社の自動連携）：入退社にあわせて利用者を自動で追加・削除。退職者のアクセスを確実に止められる（SSO自体はTeamでも使えます）
- 権限の細分化：誰が何をできるかを役割で制御する
- 監査ログ：誰がいつログインし、誰が設定を変えたかといった「組織の操作」を追える。社内監査や説明責任に効く（AIとのやり取りの中身までは記録されません）
- データ保持の制御：ログやデータの保持方針を組織方針に合わせて設定する
では、どちらを選ぶか
シンプルな目安はこうです。
| こんな状況 | 向いているプラン |
|---|---|
| まず一部の部署・チームで効果を確かめたい／導入を急ぎたい | Team |
| 情シス・法務・セキュリティの承認を前提に、全社へ広げたい | Enterprise |
| 監査ログ・SCIM・契約上のデータ取り決めが必須要件 | Enterprise |
| 規制業種で、説明責任・統制が厳しく求められる | Enterprise |
現実的な進め方としては、Team で小さく始めて成果と勘所をつかみ、全社展開のタイミングで Enterprise に切り替えるのが王道です。最初から重い契約を結ぶより、「効くと分かってから統制を固める」ほうが、社内の合意も取りやすくなります。
よくある質問
Q. 人数が少なければ Team で十分？
人数だけで決めるのは危険です。たとえ少人数でも、機密情報を扱う・監査ログが必要・契約上の保証が要る、といった事情があれば Enterprise が必要になります。「何人で使うか」ではなく「どんなポリシーと契約が要るか」で判断してください。
Q. まず Team で始めて、後から Enterprise に移れる？
移行自体は可能です。ただし、全社展開のあとでガバナンス要件が不足していると分かると、運用が止まりやすくなります。扱う情報の機密度が高い、または今後高くなる見込みなら、最初から Enterprise を検討するほうが結果的にスムーズです。
Q. 結局、契約形態は誰が決めるべき？
現場の使い勝手だけでも、情報システム部門の都合だけでも決められません。利用者・情シス・法務・経営が、ポリシーと契約の観点を持ち寄って判断するのが理想です。判断材料が多く動く領域なので、外部の知見を借りるのも近道です。最初の契約形態の選定を丁寧に行うことが、その後の全社展開を左右します。
シリーズのまとめ ― 入口・基盤・契約の3点セット
3回にわたって、Claude を会社で使うための土台を整理しました。あらためて並べると、検討すべきは次の3点です。
- 入口（第1回）：Chat・Cowork・Code を、やりたいことで使い分ける
- 基盤（第2回）：データの通り道を見て、社外に出さない経路を選ぶ
- 契約（第3回）：統制の必要度で、Team か Enterprise を選ぶ
この3点がそろって初めて、AI は「便利な実験」から「業務に根づいた仕組み」に変わります。どれか一つでも曖昧なまま全社展開すると、たいてい途中で止まります。逆に言えば、ここを丁寧に設計すれば、AI 導入は驚くほどスムーズに進みます。
このシリーズ（企業導入編・全3回）
- 入口を選ぶ ― Chat・Cowork・Code の使い分け
- データを外に出さない ― Bedrock・Vertex AI・Azure
- 法人契約の選び方 ― Team と Enterprise（この記事）