生成AIの情報漏洩を防ぐ法人プランとAPI設定の実務

生成AIの業務利用における情報漏洩対策は、入力が学習に使われるか、ログに残るか、誰がアクセスできるかという3層で捉えるとです。
無料版が部署単位で広がるシャドーAIの状態では、学習設定だけを見ても不十分で、まず棚卸しをして統制下に戻すところから始める必要があります。
Team/Business、Enterprise、APIでは既定の扱いが異なり、学習に使われないこととログが一切残らないことは別物だと押さえておくべきでしょう。
契約、設定、運用の3点をそろえて初めて、DLPや入力マスキング、承認フローまで含む実効的な対策になります。

情報漏洩の正体：学習・ログ保持・アクセス制御の3層に分けて考える

情報漏洩は、まず「入力が学習に使われるか」、次に「入力・出力がログとして残るか」、そして最終的に「誰がその情報へ触れられるか」という3層で考えるとです。
読者がいちばん警戒しやすいのは学習利用ですが、契約や設定で抑えられるのは主に1層目と2層目です。
実際に漏洩が起きやすいのは3層目、つまり人とアクセス権の設計であり、ここを外すと制度上の安全策は効きません。

『学習に使われる』と『ログに残る』は別問題

業務向け製品のTeam/Business、Enterprise、APIは既定で入力をモデル学習に使用しません。
だからといって「何も残らない」と考えるのは早計で、標準APIでは不正利用監視のため入力・出力が最長30日保持され、その後に削除されます。
学習利用とログ保持は技術的に別経路なので、学習オフだけで安心すると、外部監査でログ保持期間やアクセス権限の管理を問われたときに答えが詰まります。
統制の論点は、学習の有無だけでなく、保持の有無と保持中に誰が見られるかまで含めて確認することです。

危険なのは、無料・個人プランでの利用です。
既定で入力が学習に使われ得るうえ、組織としてオプトアウトや回収を強制しづらく、退職時の管理も崩れやすいからです。
法人利用でTeam/BusinessやEnterpriseが選ばれるのは、単に「学習しない」からではなく、SSO、監査、入退社連動、保持設定を組織側で持てるためでしょう。
学習の不安を消すだけでなく、監査可能性まで作ることが実務上の基準になります。

ゼロデータ保持(ZDR)とは何か

ゼロデータ保持(ZDR)は、応答返却後にデータを保存しない最上位の保護です。
法令遵守や不正利用対策で必要な場合を除き、入力も出力も保存されません。
標準APIの30日保持よりさらに厳しい設計で、情報を残したくない要件が強い組織ではこの差がそのまま運用設計の差になります。

ただし、ZDRは標準プランに含まれず、申請と審査が必要です。
承認後に組織またはプロジェクト単位で有効化する位置づけなので、「学習オフ」と同列に語ると誤解します。
保持を最小化したいのか、そもそも保存をなくしたいのかで選ぶべき設定は変わりますし、委託先との契約でもその差を明確にしておく必要があります。
保存しない設計は強力ですが、前提として業務要件と申請フローを通す段階から管理対象になるのです。

最大のリスクはシャドーAIとアクセス権の過剰付与

実際の漏洩は、技術設定より運用のほころびから起きます。
従業員が個人アカウントで勝手に使うシャドーAI、退職者のアカウントが残ったままになる状態、権限が広すぎて誰でも機密プロジェクトに入力できる構造、こうした人的・権限的要因が主因です。
禁止令を出したのに現場が個人スマホで生成AIを使い続け、かえって管理外の入力が増えた、という場面は珍しくありません。
統制下で解禁して可視化した方が漏洩が減るのは、このためです。

だから後半のアクセス制御章では、SAMLによるSSO、SCIMによる入退社連動、最小権限設計、利用ログ監査、IP制限、ゼロトラストをどう組み合わせるかが焦点になります。
学習オフでも機密の入力自体は止まりません。
入力ブロック、マスキング、承認フロー、外部委託先への設定申告まで含めて初めて、3層のうち1層目から3層目までがつながるでしょう。

なぜ個人プランは危険か：無料版・有料個人版のデータ既定値

無料・個人版は便利ですが、業務データを入れた瞬間に統制の外へ出やすいのが弱点です。
既定で入力が学習に使われるサービスでは、利用者自身がオプトアウト設定をしない限り、安全側に倒れません。
しかも、その設定は個人ごとの操作に依存するため、1人の漏れが組織リスクに直結します。

既定で学習に使われる無料・個人版

無料・個人プランは、入力データが学習に使われ得る設計を前提にしている場合があります。
ここで誤解しやすいのは、「使っている本人が悪意なく入力しただけ」でも、サービス側の既定値が学習寄りなら、その時点で社外利用の前提に乗ってしまうことです。
業務で扱う提案書の下書きや顧客名、要件メモが混ざると、情報は本人の感覚より先に仕組みへ吸い込まれます。
安全に寄せるには、利用者が自分でオプトアウト設定を行うしかありません。

オプトアウト設定は『漏れ』が前提リスク

問題は、オプトアウトがあっても組織として「全員が必ずやった」と保証できない点にあります。
実務では「学習オフにしたはず」が、実際には履歴オフと学習オフを取り違えていた、という場面が起こります。
履歴を消す設定と、入力を学習に回さない設定は別物のサービスがあり、前者だけでは学習対象のまま残ることがあるのです。
本人は守ったつもりでも、設定画面の意味を誤読した瞬間に漏れが生まれる。
ここが個人運用の脆さでしょう。

個人契約は一元管理できないから危険

個人契約では、管理者がポリシーを一括で強制し、監査し、退職時に回収する流れを組めません。
たとえば、社員が個人の有料プランを便利に使っていて、退職後もそのアカウントに業務プロンプト履歴が残ったままになると、会社は権限も記録も取り戻せないままになります。
ログが個人に紐づいた状態では、有事に誰が何を入力したかを会社側で追跡できず、監査証跡も崩れます。
1人の設定漏れが組織全体の事故になるので、業務利用を法人プランに寄せる論理はここで成立します。

法人プランの選び方：Team/Business・Enterprise・APIで何が変わるか

法人プランは、まず「社内で安全に使う」段階と、「統制を制度として組み込む」段階を分けて考えるとです。
Team/Businessは2名から始められ、1ユーザー月25ドル前後で学習オフとSSOまで押さえられるため、最小構成で早く展開したい企業に向いています。
EnterpriseはここにSCIM、監査ログ、DLP連携、データ保持期間のカスタムが加わり、要件主導で選ぶプランになります。

Team/Business：最小構成で学習オフ＋SSO

Team/Businessは、まず安全に全社展開するための入り口です。
入力の学習利用を既定でオフにしつつ、SSOとSOC2対応まで含めて、現場の利便性と管理側の安心感を両立しやすい構成になっています。
高価な統制機能をいきなり全部そろえるのではなく、利用ルールと権限設計でリスクを抑える発想に向いているため、少人数の部門導入や初期の全社展開では十分な選択肢になります。

実務では、150名に届かない中堅企業がEnterpriseを希望しても、規模条件と年間契約の壁でTeam/Businessに着地することが少なくありません。
その場合は、入力範囲の制限や社内ガイドラインの整備を組み合わせることで、機能不足を運用で補う形になります。
価格は1ユーザー月25ドル前後が目安なので、まず導入して定着させるという順番を取りやすいでしょう。

Enterprise：SCIM・監査・DLP・データ保持カスタム

Enterpriseは、Businessの延長ではなく、統制要件に合わせて管理を拡張する層です。
SCIM自動プロビジョニングで入退社の権限付与を省力化でき、データ保持期間のカスタムやデータレジデンシーの指定によって、保管場所や保存期間まで管理対象にできます。
さらにDLP連携、Compliance API、専任サポートが加わるため、利用者の利便性よりも監査証跡と統制の厳密さを優先する企業に合います。

監査部門から「データの保存場所を国内に」と要件が出た場面では、Enterprise一択になります。
こうした条件は、単に機能の多寡ではなく、社内規程、取引先要件、監査対応まで含めて決まるからです。
概ね150ユーザー以上・年間契約が目安で、1ユーザー月45〜75ドル、中央値約60ドルという相場を見ても、導入判断はコストより要件充足の比重が大きいと考えるのが自然です。

API：自社システム組み込み向けの最終形

APIは、SaaSの管理画面を使うのではなく、自社システムに組み込んで使う最終形です。
既定で学習非対象という点は安心材料ですが、保持やアクセス制御は自社実装が前提になります。
つまり、利用ルールをサービス側に預けるのではなく、認証、保存、ログ、権限制御を自社の設計として持つ必要があるわけです。

そのため、APIはWebアプリで完結したい企業よりも、自社プロダクトや社内基盤に生成AIを埋め込みたい企業に向いています。
後章で扱うZDR申請やゲートウェイ層のDLPと組み合わせると、SaaSでは満たしにくい統制要求にも対応しやすくなります。
逆に言えば、運用設計を自前で持てないなら選ぶ理由は薄いでしょう。

API設定の実務：学習オフ・30日保持・ゼロデータ保持の使い分け

APIを自社アプリに組み込むときは、「学習に使われない」ことと「ログが残らない」ことを分けて考える必要があります。
標準設定では入力・出力は学習対象外ですが、不正利用監視のために最長30日保持され、その後に削除されます。
つまり、機密性の議論をするときは学習可否だけで判断せず、保持期間と監査可能性まで含めて設計するのが実務です。

APIの既定値：学習オフ＋30日保持

APIは業務向け扱いで、既定では入力・出力を学習に使いません。
ただし、不正利用監視のために標準で30日保持されるため、「学習されないから記録も残らない」とは言い切れないのです。
自社チャットボットへAPIを組み込んだ際、この点を見落としてZDRの申請を本番直前に始めた結果、承認待ちのリードタイムを織り込めず公開日がずれた、という話は珍しくありません。
設計の初期段階で保持の前提を押さえておくと、後戻りが減ります。

ゼロデータ保持(ZDR)の申請と適用単位

保持そのものを消したいなら、ゼロデータ保持(ZDR)が必要です。
ZDRは管理画面で誰でも即座に切り替えられる設定ではなく、申請と審査を経て承認された後に、組織単位またはプロジェクト単位で有効化します。
この手続き上の制約があるため、要件定義の段階で法務・セキュリティ・開発の3者をそろえておくと、申請書類の差し戻しを減らせます。
中間案として、保持を抑えた修正版の不正利用監視(Modified Abuse Monitoring)を選べる場合もあり、完全ゼロほど厳しくなく、監視の実効性と秘匿性の折り合いをつけやすい選択肢です。

ログ保持と監査要件のトレードオフ

保持を減らすほど、外部から見える記録は少なくなり、不正利用監視も自社のトラブル調査も難しくなります。
これは単なるセキュリティの話ではなく、障害対応の速度や再現性に直結する運用上の問題です。
全社一律でゼロを選ぶと、問い合わせ対応で「何を送ったか」が追えず、原因切り分けが長引くことがあります。
そこで、コンプライアンス要件と追跡可能性を天秤にかけ、機密性の高い案件だけZDRやModified Abuse Monitoringを使い、その他は標準保持を残すほうが現実的です。
おすすめです。

アクセス制御の設計：SSO・SCIM・権限・ログ・IP制限

SAMLによるSSOを先に整えると、生成AIの利用は個人アカウントの寄せ集めではなく、自社のIDソースにぶら下がる統制された業務機能になります。
退職者の即時無効化や多要素認証をまとめて効かせやすくなり、法人プラン契約後にまず固める土台としても扱いやすい構成です。
SCIMまで入れると入社・異動・退社のたびに付与と剥奪が連動し、半年放置された退職者アカウントが棚卸し監査で初めて見つかるような典型的な漏洩経路を、手作業ではなく仕組みで塞げます。

アクセス制御は、学習利用とログ保持の違いも分けて考える必要があります。
業務向け製品(Business/Enterprise/API)では既定で入力・出力をモデル学習に使いませんが、標準APIは不正利用監視のため入力・出力を最長30日保持し、その後削除します。
ゼロデータ保持(ZDR)は、応答返却後にデータを保存しない運用を指し、法令遵守や不正利用対策で必要な場合を除いて痕跡を残さない設計です。
つまり、何が学習に使われるか、何が一時保管されるか、何が残らないかを分けて見ないと、安心材料を取り違えます。

SSO(SAML)とSCIMで認証・棚卸しを自動化

SAMLによるSSOは、生成AIの入口を自社のID基盤に一本化する仕組みです。
アカウントが部署ごとに乱立している状態では、退職者の無効化や多要素認証の適用漏れが起きやすくなりますが、SSOなら既存の認証ポリシーをそのまま流し込めます。
法人プラン契約後にまず構成すべきなのは、派手な活用ルールではなく、この入口の統制だと考えてよいでしょう。

SCIMは、入退社や異動に合わせてアカウントの付与と剥奪を自動化します。
手動運用では、退職者の権限が残ったまま半年が過ぎ、棚卸し監査でようやく発覚することがあります。
こうした失敗は珍しくありません。
Enterprise相当で使える機能として扱われることが多く、監査対応を後追いにしないための実務装置になります。
学習利用の可否とは別に、そもそも誰が使えるかを自動で整えるのが第一段階です。

最小権限：誰が・何に・どこまで

権限設計は、「誰が、どのワークスペースやプロジェクトに、どこまで触れてよいか」を役割ベースで絞るところから始まります。
読み取り・書き込み・実行を分けずに全社員へ同一権限を付与すると、誰でも機密案件のワークスペースへ入力でき、誤送信や不適切な参照がそのまま事故になります。
実際に同一権限で運用していた現場では、機密プロジェクトの領域を限定メンバーのみに組み直しただけで、運用の見通しが大きく改善しました。

最小特権のポイントは、データソース単位まで落とすことです。
ワークスペースに入れるだけではなく、どのデータに対して読み取りだけ許すのか、編集を許すのか、実行系の操作まで許すのかを分けると、シャドーAIのような無秩序な利用も抑えやすくなります。
人的リスクは技術より先に現れるので、役割と責任の線引きを先に作るほうが、あとで監査ログを眺めるより筋がよいのです。

利用ログ・IP制限・ゼロトラスト

利用ログと監査ログは、「誰が、いつ、何を入力したか」を後から追えるようにするための記録です。
ログがなければ、問題が起きても経路を再現できず、統制は感覚論になります。
加えて、IPアドレス制限やゼロトラストの考え方を組み合わせれば、社外端末からの利用をその場で絞れます。
都度認証と端末検証を通さない接続を許さないことで、正規アカウントの盗用にも強くなります。

ここで効いてくるのが、検知と統制の両輪です。
ログで異常を見つけても、接続元が野放しなら再発を止められませんし、制限だけあっても、何が起きたか分からなければ運用は続けにくいでしょう。
おすすめは、まずSSOとSCIMで入口を固め、次に最小権限で面を狭め、最後にログとIP制限で出口と監視を重ねる順序です。
そうして初めて、3層のリスクを切り分けて扱えるようになります。

DLPと入力ガードレール：学習オフでも防げない『うっかり入力』対策

DLPと入力ガードレールは、学習オフやZDRを設定しただけでは止められない「入力そのもの」の漏えいを抑えるための層です。
社外秘や個人情報は、送信した時点で外部サービスに渡るため、先に入口で検知し、必要ならマスキングや承認を通してから使う設計にしないと守れません。
現場では、議事録要約に使うつもりで参加者名や取引条件をそのまま貼り付け、DLPがブロックして初めて気づく場面が起きます。

DLPで『入れてはいけない情報』を入口で止める

DLPの役割は、学習に使われるかどうかを気にする前に、そもそも送ってはいけない情報を止めることにあります。
個人情報、機密語、マイナンバーやカード番号のような特定パターンを検知対象にしておけば、利用者が悪意なく貼り付けた場合でも、送信前の段階で遮断できます。
ここを外すと、設定は守れても入力は守れないままになり、最初の1回で情報が外に出るリスクが残るのです。

実装の考え方は2通りです。
Enterpriseの連携機能でアプリ側にポリシーを持たせる方法と、APIの前段に専用ゲートウェイ層を置いて通過点で判定する方法です。
前者は利用部門の導入が速く、後者は複数ツールを横断して統一制御しやすい。
どちらでも、検知ルールを曖昧にせず、固有表現や定型パターンを具体的に持たせることが肝になります。

入力マスキングと承認フロー

DLPで止めるだけでは、業務が止まりすぎることがあります。
そこで有効なのが、入力前のマスキングや匿名化です。
固有名詞を役割名に置き換え、金額や日付をレンジに丸めてから送れば、要約や下書きの精度を保ちながら、漏えい面を小さくできます。
機密度の高い案件は申請制にし、どの範囲までAIに渡すかを先に決めておくと、現場の迷いが減ります。

この発想は、AIを使うか使わないかではなく、どこまでなら使ってよいかを線引きする運用です。
たとえば契約書のたたき台を作る場面でも、社名や取引条件を伏せた版だけを通す、最終稿は人手で戻す、といった流れにすると、利便性を保ったまま事故の入口を狭められます。
おすすめです。
運用の負荷は少し増えますが、漏えい後の説明コストと比べれば軽い負担で済みます。

外部委託・シャドーAIへの統制

外部委託先がAIを使うなら、「どのツールを、どの設定で使うか」を事前申告させて相互に合意する設計が欠かせません。
無料版を学習オンのまま使っていたことが契約見直しで発覚した事例のように、設定の認識ずれは現場で起こりやすいからです。
だからこそ、ツール名と設定、使う業務範囲を申告させ、契約条件に落としておく必要があります。

禁止だけを先に出すと、利用は見えない場所に移ります。
シャドーAIが増えれば、ログも残らず、統制も効きません。
サムスン型の全面禁止から段階解禁へ移る流れを念頭に、統制下で認め、利用ログで見える化したほうが、結果として漏えいは減ります。
おすすめの進め方は、先に禁止する範囲を定義し、そのうえで使える場面を解禁していく方法でしょう。
管理部門と委託先が同じ前提を持てば、現場も動きやすくなります。

導入5ステップ：選定から運用・監査までのロードマップ

導入は、機能を比べて終わりではなく、誰が何をどのアカウントで使っているかを先に掘り起こすところから始めます。
そこを飛ばすと、契約はしたのに現場では個人版が残り、統制もコストも二重になるからです。
棚卸し、選定、設定、監査という順序で進めると、情報漏洩対策は机上の方針ではなく運用に落ちます。

Step1-2：棚卸しとプラン選定

まずは現状把握です。
誰がどの生成AIを、個人アカウントか法人アカウントかのどちらで、どの業務に使っているかを洗い出します。
ここで見つかるのが、契約書の外側で使われているシャドーAIです。
営業の提案文、開発の調査、管理部門の文面作成まで用途が広がるほど、利用実態は見えにくくなります。
棚卸しを省いてプラン契約から入ると、現場の個人版利用が温存され、支払先だけ増えて統制は弱いまま、という順序ミスが起きやすくなります。

次にプラン選定です。
2名〜で安全に展開するならTeam/Business、150名規模や監査・データレジデンシー要件があるならEnterprise、自社プロダクトに組み込むならAPI、という判断基準で整理すると迷いが減ります。
ポイントは、単なる価格比較ではなく、前章の比較表で見た管理粒度と要件をそのまま当てることです。
小規模でも権限分離やログ確認が必要ならTeam/Businessが現実的ですし、部門横断で統制を効かせたいならEnterpriseのほうが運用は揃えやすいでしょう。

Step3-4：学習オフ・ZDR・アクセス制御の構成

設定段階では、技術設定とアクセス制御を分けずに一気に固めます。
最初に学習オフの確認を行い、必要があればZDRや最小保持を申請します。
ここは「入力した情報がどこまで残るか」を決める土台なので、後から権限やDLPを足すより先に確認しておくべきです。
保持期間や学習の扱いが曖昧なままだと、便利さの裏で機密が広く残る構造になりかねません。

そのうえで、SSO、SCIM、役割ベース権限、DLP、利用ログを順に構成します。
SSOとSCIMは退職者や異動者の権限を揃えやすくし、役割ベース権限は部署ごとの利用範囲を明確にします。
DLPは入力ガードレールとして機密の持ち込みを抑え、利用ログはあとで監査するための記録になります。
学習・保持と、アクセス制御・入力ガードレールをこの段でまとめて固めておくと、導入後に例外対応へ追われにくくなります。

Step5：継続監査・教育・追従

運用で差が出るのは、導入直後ではなく数か月後です。
利用ログを定期レビューし、新しいAIツールの無断利用や、付けっぱなしになった権限を早めに見つけます。
四半期ごとのレビューを定例化した運用では、部門が勝手に増やしたツールと、退職・異動後も残っていた権限を早く拾えるようになりました。
設定変更があったときも、ログが残っていれば影響範囲を追いやすいので、是正の順序を決めやすくなります。

教育も並行して回します。
機密を入力しないこと、承認フローを通すこと、使ってよい用途とだめな用途を分けることを、入社時だけでなく節目ごとに繰り返します。
おすすめなのは、棚卸し→選定→設定→監査の流れをそのまま社内ルールにしてしまうことです。
しましょう。
しましょう。
生成AIの安全運用は一度設定して終わりではなく、利用実態に追従し続ける仕組みで完成します。