ChatGPT Businessを士業事務所で契約する前に確認しておくこと

所員の方が個人向けの商用AIチャットツールを使って業務を回すうちに、契約の見直し時期に「事務所として法人プランに移したい」 という話になる。BusinessにするかEnterpriseにするかを、 最初は価格と席数で比較していても、IDプロバイダ連携・監査ログ・DPAの論点が出てきたところで、 ベンダー選定そのものより先に決めておくべきことが見えてくる、 という流れになりやすい場面です。

2026年に入ってから、 士業事務所でAIの契約形態を見直す相談が増えています。所員数人から十数人の事務所では、 個人プランを束ねていた状態からBusinessへの移行が進んでいます。中規模以上の事務所では、SSO・SCIM・監査ログの要件からEnterpriseの検討が現実的な選択肢として出てきます。同時に、 所員が個人アカウントで業務情報を入れてしまう運用 (= シャドー AIと呼ばれる形) を可視化したいという声も、 内部統制サイドから増えています。所員が顧問先データを個人アカウントに入力していた場合、 その時点で税理士法38条・弁護士法23条の守秘義務、 個人情報保護法23条の安全管理措置義務との整合が問題になりうるため、 契約検討以前に事実確認・被害範囲特定・関与先への報告要否の検討が優先されます。

商用AIチャットツールの法人プラン (Business / Enterprise) では、 個人プランと異なり、 学習除外の契約条件、SSO・SCIM・監査ログなどの管理機能、DPA (= データ処理契約) の締結、 サブプロセッサの開示、SOC 2やISO 27001などの第三者監査レポートの提示が、 業務利用を前提に整理されています ¹。

一方、 法人プランを契約すれば全部解決するわけではありません。価格は人数ぶん効いてきますし、 法人プランには最小ライセンス数の条件が置かれています。SSOやSCIMを有効にするには事務所側のIDプロバイダの整備が前提になりますし、 監査ログを取得しても、 誰がいつレビューするかを決めていないと、 ログがあるだけで活用に結びつきません。

本稿では、 商用AIチャットツールの法人プラン (Business / Enterprise / API) の位置づけを並べたうえで、 士業事務所として契約前に確認しておくべき論点を、 個人情報保護法・士業各法・所属団体の指針とあわせて整理します。プランの仕様・価格は変更されうるため、 契約直前には公式ドキュメントの最新版を確認する前提です。

税理士・弁護士事務所視点でのBusiness / Enterprise / APIの位置づけ

商用AIチャットツールの主要事業者は、 業務利用向けに「Business」「Enterprise」 のプランと、 開発者向けにAPI Platformを提供しています。各社の信頼性ポータルでは、 これらが第三者監査レポートのスコープ (= 対象範囲) として明示されています ¹。なお、OpenAIについては2025-08-29に旧「Team」プランが「Business」にリネームされ、 現在はTeamという独立SKUは存在しません ²。

おおまかな違いは次のとおりです (= プラン構成は変更されうるため、 最新は公式ドキュメントでご確認ください)。

• Businessは、小〜中規模チーム向けで、 学習除外・基本的な管理コンソール・SSO・DPAを含みます (OpenAIの場合、2席から契約可能)
• Enterpriseは、SSO/SAMLに加えてSCIM自動プロビジョニング、 詳細な監査ログ (Compliance API等) 、 データ保持期間の管理者制御、 個別SLA、 ドメイン認証を提供します (概ね数十〜100席規模以上・年間契約が前提とされる場面が多く、 個別見積で下限を確認)
• API Platformは、 自社システムから直接呼び出す用途で、 プログラム経由の利用が前提です

観点別の比較は次のとおりです (= 条件は変更されうるため、 契約直前は公式ドキュメントで要確認 ³)。

個人向けChatGPT (Free / Plus / Pro) は既定で学習利用の対象で、 設定からopt-outが必要です。業務向けプラン (Business / Enterprise / API) は既定で除外されるという点が、 個人プランとの明確な差になります。

士業事務所での検討は、 次のような場面に分かれます。

• 所員数人から十数人で、 商用AIチャットツールのUIをそのまま使う場面では、Businessが候補に挙がります
• 大規模事務所・複数支店で、IDプロバイダ統合とログ集約 (SCIM自動プロビジョニング・Compliance APIによる監査ログ) を必要とする場面では、Enterpriseが現実的な選択肢になります
• 顧問先管理システムや文書管理システムにAIを組み込む場面では、APIを選び、 必要に応じてEnterprise契約と組み合わせます

UIだけ見るとどれも近く見えますが、 契約条件・管理機能・サブプロセッサ開示の粒度といった裏側で差が出ます。特にSCIMとCompliance API相当の詳細監査ログはEnterprise以上でしか提供されないため、 士業事務所の退職時アクセス権自動剥奪・内部統制上の詳細ログをBusiness前提で設計すると、 契約後に必要な粒度が取れないことになります。

学習除外とデータ保持は別の論点として扱う

契約条件を見ていくときに混同されやすいのが、「データが学習に使われるか」 と「データがサーバに保持されるか」 を同じものとして扱ってしまう場面です。この二つは別の論点として扱っておくと、 後で齟齬が出ません。

主要な商用AIチャットツール事業者は、 業務利用向けプラン (Business / Enterprise / API) について、 顧客のビジネスデータを基盤モデルの学習に使わない方針を公式に説明しています ³。一方、 ログ保持 (= retention) は別の軸の話で、 不正利用検知やサポート対応のために一定期間サーバ側に残ります。

保持期間の制御は、 プランごとに仕組みが異なります。ChatGPT EnterpriseはWeb UI側の会話履歴保持期間を管理者が設定 (最小90日〜) できます。API側のZero Data Retention (= ZDR) は別の仕組みで、 既定では30日のabuse検知用ログが保持されるため、ZDRを有効化するには対象エンドポイントごとにOpenAI営業経由の申請・承認が必要になります ⁴。「Enterprise契約 = ZDRが自動で付いてくる」ではないため、 士業実務で保持ゼロを前提にする場合は営業経由の申請・承認プロセスを織り込む必要があります。

個人情報保護委員会が令和5年6月2日に公表した「生成AIサービスの利用に関する注意喚起等」 が、 この場面で参照される文書です ⁵。

個人情報取扱事業者が、 あらかじめ本人の同意を得ることなく生成AIサービスに個人データを含むプロンプトを入力し、 当該個人データが当該プロンプトに対する応答結果の出力以外の目的で取り扱われる場合、 当該個人情報取扱事業者は個人情報保護法の規定に違反することとなる可能性がある。そのため、 このようなプロンプトの入力を行う場合には、 当該生成AIサービスを提供する事業者が、 当該個人データを機械学習に利用しないこと等を十分に確認すること。

「学習に利用しないこと等を十分に確認すること」 という言い回しが要で、 ベンダーがそう言っていたはず、 という認識だけでは足りません。利用するプランの契約条件・ドキュメントで確認したうえで、 自社の運用に落とし込む必要があります。同注意喚起は「あらかじめ本人の同意を得ることなく」を条件文に置いているため、 士業実務では、 顧問先・依頼者からAI利用について書面 (または電磁的方法) で個別同意を取得する運用が現実的な選択肢になります。既存関与先には契約変更同意書の送付、 新規契約では委任契約書・関与契約書のひな型にAI利用条項を追加する事務所も増えています。

士業事務所の業務利用では、 顧問先や依頼者の情報がプロンプトに含まれる場面が出てきます。「学習除外」「保持期間」「アクセス権」 を別々に確認したうえで、 そもそも入力してよい情報の線引きを上流に置いておく設計をしている事務所もあります。加えて、 弁護士・監査法人の実務では事務所内の情報バリア (= Chinese Wall) 維持も論点になるため、SSO / SCIMで全所員を単一のワークスペースにまとめる前に、 利益相反案件・独立性維持の観点から、 ワークスペース/プロジェクト分離、 会話履歴の共有範囲、 管理者による横断閲覧権限を設定・運用面で確認しておく必要があります。

管理機能 (SSO・SCIM・監査ログ・DLP)

法人プランを選ぶ実務上の意味は、「学習に使われない」 という契約条件以上に、 管理機能の有無に出てきます。プランごとに提供範囲が異なるため、 士業事務所の要件と直接照合する必要があります ³。

• SSO / SAMLはBusiness / Enterpriseで提供され、 事務所のIDプロバイダに統合してサインインを一元化できます
• SCIM (人事システムからの自動プロビジョニング・デプロビジョニング) はEnterprise専用機能です。BusinessではSSOまでは提供されるものの、 ユーザーのプロビジョニング/デプロビジョニングは手動運用になります。退職時のアクセス権自動剥奪を運用に組み込みたい場合はEnterpriseが前提です
• MFA (= 多要素認証) は、IDプロバイダ側のポリシーに従わせることで、 強度を統一できます
• 監査ログの粒度はプランで大きく異なります。Businessは管理コンソール上での利用状況ダッシュボードにとどまり、 イベント単位の詳細ログ (Compliance API / Compliance Logs Platform、SIEM連携、admin auditのエクスポート) はEnterprise / Edu専用機能です。プラットフォーム側のログ保持は30日程度で、 長期保持は顧客側での継続エクスポートが必要になります
• データ保持期間の制御では、Enterpriseで会話履歴の保持期間を管理者側で設定できます (最小90日〜)
• 管理コンソールで、 所員のアカウント棚卸し、 利用状況のダッシュボード、 ドメイン認証などが扱えます

これらの機能は「存在すること」 と「事務所内で運用されていること」 が別の話になります。SSOを契約しても、 事務所側のIDプロバイダが整備されていないと有効に使えませんし、 監査ログを取得しても、 月次レビューの担当者と頻度を決めていないと、 事故発生時に追いきれません。

DLP (= 情報漏洩防止) や統合監査基盤との接続が必要な場面では、 対応範囲がプランによって差があるため、 事務所側で必要な要件を先に整理してからプラン選定に入る事務所もあります。

契約条件 (DPA・サブプロセッサ・賠償)

業務利用の場面では、 機能比較と並んで契約条件の確認が論点になります。確認の対象は、DPA・サブプロセッサ・賠償条項の三つです。

データ処理契約 (= DPA) は、 ベンダーが顧客のデータを「処理者 (= プロセッサ)」 として扱うことを定める契約です。DPAは自動適用ではなく、 商用AIチャットツール各社の専用フォームから会社名・組織ID・EEA/スイス所在の場合の契約主体 (OpenAI Ireland Ltd.等) を入力し、 メール経由で電子署名する能動的な締結プロセスが必要です。個人アカウントでは締結できず、Business / Enterprise / APIの有償アカウントが前提になります ¹。DPAの中身としては、 データの所在地、 暗号化、 サブプロセッサ一覧、 監査権限、 データ削除手順、 インシデント通知の時限などが含まれます。

士業事務所の場合、DPAは選択肢ではなく、 個人情報保護法上の委託先監督義務を果たすための実務上の最低要件になります。同法27条5項1号は「委託に伴って個人データが提供される場合」を第三者提供の例外として位置づけていますが、 委託元には同法25条により「必要かつ適切な監督」義務が課されており、 個人情報保護委員会通則ガイドラインは監督の内容として「適切な委託先の選定」「委託契約の締結」「委託先における取扱状況の把握」を挙げています。DPA (実質的な委託契約) の締結は、 この監督義務の実装のひとつになります。

海外のAIベンダーを利用する場合、 同法28条 (外国にある第三者への提供の制限) が正面から論点になります。本人同意を得るか、 基準に適合する体制 (相当措置の継続的実施を確保するための取扱い基準を満たす契約や、 認定を受けたグローバル体制) を整備する必要があり、 単にDPAを締結しただけでは28条の要件を満たさない場面が出てきます。米国事業者のサービスを利用する場合、 サブプロセッサの所在国と併せて28条の対応方針 (本人同意か、 基準適合体制か) を事前に整理しておくべき論点になります。

サブプロセッサは、 ベンダーが裏側で利用しているクラウドインフラ事業者・運用ベンダーの一覧です。各社の信頼性ポータルからサブプロセッサ一覧の公開ページに到達できます (OpenAIの場合はhttps://openai.com/policies/sub-processor-list/ )。「どこの国のどの事業者にデータが渡る可能性があるか」 を把握しておくと、28条対応の判断材料になり、 顧問先や監督官庁から問われたときの説明可能性を担保できます。

賠償・責任範囲については、 サービス利用規約・商用契約に賠償上限や免責条項が含まれる場合があります。「事故が起きたときに、 誰がどこまで責任を負うのか」 は、 士業事務所の守秘義務との整合の場面で論点になります。具体的な条項解釈は弁護士マターになるため、 リーガルレビューを組み込んでいる事務所もあります。

士業各法・所属団体の指針との整合

個人情報保護法とあわせて、 士業事務所のAI利用は、 各士業法の守秘義務と所属団体の指針との整合が論点になります。個人情報保護法とは別レイヤーの規制であり、 本人同意で解除できない場面がある点に注意が必要です。

• 税理士: 税理士法38条 (秘密を守る義務、 違反時は同法59条により2年以下の懲役または100万円以下の罰金)。日本税理士会連合会の会則・関連指針との整合を要します
• 弁護士: 弁護士法23条 (秘密保持の権利および義務)、 弁護士職務基本規程23条・27条・28条 (守秘義務および利益相反)、 刑法134条 (秘密漏示罪)。日本弁護士連合会が2025年9月に公表した「弁護士業務における生成AIの利活用等に関する注意事項〜適切な利活用に向けた5つのポイント」 ⁶ は、 本稿と論点が重なる直接的な参考文書です
• 公認会計士: 公認会計士法27条 (秘密を守る義務)。日本公認会計士協会「テクノロジー委員会研究文書第11号 監査におけるAIの利用に関する研究文書」 ⁷ が業務利用の考え方の参考になります

これらの士業法上の守秘義務は、 顧問先本人の同意があっても解除されない場面があり、 個人情報保護法レンズだけでは士業固有の守秘義務論点を捕捉しきれません。契約前の要件整理では、 個人情報保護法と士業各法・所属団体の指針を並列に確認する必要があります。

士業事務所規模で見る 価格と最小ライセンス

価格は時期により変動し、 為替の影響も受けるため、 本稿では具体的な金額は扱いません。最新は各事業者の料金ページでご確認ください。

契約検討の場面で意識される論点は次のとおりです (= 具体条件は変更されうるため、 契約直前に要確認です)。

• Businessには最小ライセンス数の制約が置かれています (OpenAIの場合2席から契約可能)
• 年間契約と月次契約で単価が異なる場面があります
• Enterpriseは個別見積もりが基本で、 概ね数十〜100席規模以上・年間契約が前提とされる場面が多く、 個別見積で下限を確認する運用になります
• APIは従量課金が中心で、Web UI型プランとは課金体系が異なります

費用対効果を見るときは、 単月コスト × 所員数だけでなく、 シャドー AI (= 所員が個人アカウントで業務情報を入れてしまう運用) を可視化・統合することで得られる管理上の意味も合わせて見る事務所もあります。個人プランを各人が個別に契約している状態は、 事務所として把握も棚卸しもしにくく、 後から問題が顕在化したときに修正に時間がかかります。

検討の流れ

商用AIチャットツールの法人プラン契約検討は、 次のような流れで進めます。

• 所員が現在どのAIサービスを使っているか (= 個人プランのチャットAI、 業務統合型AI等) と、 誰がどのアカウントを持っているかを棚卸しします
• シャドー AIで顧問先情報が個人アカウントに入っていた場合は、 契約検討に進む前に事実確認・被害範囲特定・関与先への報告要否を検討します
• AIに入れてよい情報・入れてはいけない情報の線引き (= 顧問先情報、 マイナンバー、 案件詳細等) を、 業務範囲として定義します
• 顧問先・依頼者からのAI利用に関する書面同意の取得方針 (契約変更同意書・委任契約ひな型へのAI利用条項追加) を整理します
• SSO必須かどうか、SCIM (退職時アクセス権自動剥奪) 必須かどうか、Compliance API相当の詳細監査ログ必須かどうか、API連携の必要性、 シート数の見込みなどの要件を確定します
• Business / Enterprise / APIのどれが要件に合うかを比較します
• DPAを能動的に締結し、 サブプロセッサ一覧を確認、 個人情報保護法28条 (外国にある第三者への提供) の対応方針を決めます (= 必要に応じて弁護士レビューを挟みます)
• 少人数で1〜2ヶ月、 想定ユースケースを実際に流してPoC (= 試験運用) を行います
• 所員研修、 ガイドライン文書化、 月次レビューの仕組みを整えて、 日々の業務に組み込んだ運用へ移行します

「商用AIチャットツールを買う」 場面というよりも、「事務所のAI運用基盤を設計する」 場面として捉えると、 ベンダー選定より先に「何を入れていいかの線引き」 と「誰が管理者をやるか」 を決めておくと、 後の段取りが楽になります。

セキュリティ・コンプライアンスの場面では、 第三者監査レポートの状況も確認の対象になります。商用AIチャットツール各社の信頼性ポータルでは、SOC 2 Type 2やISO/IEC 27001系の規格、GDPR / FedRAMP関連の整理が提示されています ¹。これらは「あること」 が直ちにリスクをゼロにする性質のものではないものの、 契約前のデューデリジェンスの場面で、 第三者監査が継続的に行われているかどうかは確認の対象になる指標です。

加えて、 個人情報保護委員会の注意喚起は一般利用者向けにも次のように示しています ⁵。

生成AIサービスの利用者においては、 生成AIサービスを提供する事業者の利用規約やプライバシーポリシー等を十分に確認し、 入力する情報の内容等を踏まえ、 生成AIサービスの利用について適切に判断すること。

事務所として、 ベンダーが整備しているものを確認するだけでなく、 自社側で運用に落とせているかも併せて点検する、 という流れになります。

契約より先に動くもの

2026年に入ってからの相談動向を見ると、 契約条件の比較から入った事務所より、 まず現状の棚卸しから入った事務所のほうが、PoC以降の移行がスムーズに進んでいます。

契約以前に決まっていると後が楽になる論点は次のとおりです。

• AIの管理者を誰が担うか (= AIの管理者はパートナー級の責任者に置く事務所が増えています)
• 何を入れてよいかの上限ライン (= 顧問先名・マイナンバー・原本データの扱い)
• 顧問先・依頼者からのAI利用同意の取得プロセス (= 委任契約書・関与契約書ひな型へのAI利用条項追加、 既存関与先への契約変更同意書)
• 個人情報保護法28条対応方針 (= 本人同意か、 基準適合体制か)
• いつ見直すか (= 半年〜1年に1回、 ベンダーポリシーの改訂を点検する運用)

ここが決まっていると、Business / Enterprise / APIのどれを選ぶかは、 要件マッチングの作業に落ちます。逆に、 ここが曖昧なまま価格表とにらめっこをしても、 契約後に「使いこなせない」 「形曝化する」 場面が出てきます。冒頭の事務所は、BusinessとEnterpriseの比較を後回しにして、 まずAI管理者をパートナーの一人に決め、 入れてよい情報の線引きと顧問先同意の取得方針を整理してから、 プラン比較に入りました。ベンダー選定の3週間より、 その前の3週間のほうが記事全体の主張になります。

本記事はベンダー別連載のChatGPT Business編です。他のベンダーを検討中の方はあわせてどうぞ:

• 税理士・弁護士事務所がClaude Team / Enterpriseを業務に入れる前に確認しておくこと
• 税理士・弁護士事務所がMicrosoft 365 Copilotを検討する前に、事務所の現在地を確認する