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 を検討する前に、事務所の現在地を確認する