生成AIツールを法人契約する前に、情報システム／DX担当が確認すべきセキュリティ観点をチェックリスト化。学習利用の有無、データ保管場所と期間、アクセス管理、監査ログ、SSO／SCIM、API鍵管理、委託先管理までを一般論として整理し、各社の最新仕様確認の勘所を示します。
生成AIの業務利用は、多くの企業で「現場が先に使い始め、管理部門が後から追いかける」という順序で広がってきたと考えられます。ブラウザさえあれば無償で高性能なモデルに触れられるため、情報システム部門やDX推進の担当者が全体像を把握する前に、各部署が個人アカウントで使い始めているというケースは珍しくないと考えられます。この「野良利用（シャドーAI）」の状態は、便利さと引き換えに、どのデータがどこへ渡っているのかを誰も説明できないという統制上の空白を生みます。
こうした状況で法人契約への切り替えを任されると、担当者は「何を、どの順番で、どこまで確認すればよいのか」という問いに直面します。ベンダー各社のドキュメントは頻繁に更新され、プランの階層（無償・個人・チーム・法人）によってデータの扱いが異なることも多く、断片的な情報だけで判断すると後から前提が崩れる可能性があります。生成AIの業務利用に対する漠然とした不安については、ChatGPT業務利用のセキュリティ不安でも整理していますが、本記事ではその不安を「契約前に確認すべき具体的な項目」へ落とし込むことを狙いとしています。
セキュリティ確認というと、リスクを列挙して利用を制限する方向に傾きがちです。しかし全面的な禁止は、かえって統制の効かない個人利用を水面下に押しやる結果になりやすいと考えられます。目的は利用を止めることではなく、確認すべき観点を明確にして、説明可能な状態で使えるようにすることだと位置づけるのが実務的だと考えます。本記事のチェックリストも、導入を妨げるためではなく、導入判断の根拠を残すための道具として使っていただくことを想定しています。
生成AIサービスの仕様・料金・データ取り扱いは短い周期で更新される領域です。したがって本記事に書かれた個別の挙動を「常にこうである」と受け取るのではなく、確認すべき問いのリストとして参照し、実際の可否は必ず各ベンダーの最新の公式情報とご自身の契約条件で確かめる、という使い方を推奨します。数値や仕様を断定できないのは情報の限界ではなく、この領域を扱ううえで避けられない前提だと考えられます。
以降では、確認観点を「学習利用」「データ保管」「アクセス管理と認証」「監査ログ」「API鍵と外部連携」「委託先・再委託」という順で解説し、最後に導入判断を支えるチェックリストの組み立て方と落とし穴を整理します。情報システム／DX推進の担当者が、経営層や法務、各事業部に対して「なぜこのツールを、この条件で契約するのか」を説明できる状態を作ることを到達点とします。
法人利用の文脈で最初に確認すべき観点は、入力したプロンプトやアップロードしたファイルが、モデルの再学習（トレーニング）に利用されるかどうかだと考えます。ここが曖昧なまま利用が広がると、社内の機密情報や取引先の情報が、意図せず学習データとして取り込まれる可能性を排除できません。多くの法人向けプランでは、業務データを既定で学習に使わない、あるいは管理者設定でオフにできると案内されていますが、この扱いは契約形態によって差があり得るため、思い込みで判断しないことが重要だと考えられます。
同じサービス名でも、無償版・個人サブスク・チーム／法人プラン・API利用とで、データの学習利用に関する既定値が異なる場合があります。一般論として、法人向けの上位プランやAPIでは学習利用を伴わない、あるいは明示的に制御できるよう設計されていることが多いと考えられますが、無償版や個人プランでは利用規約に基づいて改善目的で利用され得ると案内されているケースもあります。したがって「このサービスは安全」ではなく「この契約形態のこの設定では、こう扱われる」という粒度で確認するのが実務的だと考えます。
学習利用を止められるとしても、それが利用者側で明示的にオプトアウトする方式なのか、法人契約では既定でオフになっているのかは区別して確認したい点です。オプトアウト方式の場合、設定を有効化し忘れた期間のデータがどう扱われるかという論点が残ります。管理コンソール上の設定項目名・適用範囲（組織全体か個人単位か）・反映のタイミングまで含めて、実際の管理画面で確認することを推奨します。
この観点は、生成AIに対する現場の不安の中核でもあります。「入力した情報がどこかに残って学習される」という懸念は、ChatGPT業務利用のセキュリティ不安で扱っているテーマとも重なります。契約前に扱いを明文化しておくことは、現場に安心して使ってもらううえでの前提になると考えられます。
次の観点は、入力・出力データがどこに、どれくらいの期間、どのような保護のもとで保管されるかです。学習に使われないとしても、サービスの提供上、一定期間データが保持される設計になっていることは一般的だと考えられます。ここを確認せずに契約すると、社内規程や取引先との秘密保持契約（NDA）で求められる保管条件と食い違う可能性があります。
データが保管される国・地域は、適用される法令やデータ主権の観点で重要になります。国内保管が要件となる情報を扱う場合、保管リージョンを選択できるか、あるいは既定でどこに保管されるかを確認する必要があると考えられます。海外リージョンでの保管が前提となるサービスもあるため、扱う情報の機微度と照らして、そもそも入力してよい情報の範囲を先に決めておく設計が現実的だと考えます。
会話履歴・アップロードファイル・ログが、いつまで保持され、どのように削除されるかは、確認の優先度が高い項目です。不正利用検知などの目的で一定期間保持されると案内されている場合もあり、その期間・目的・削除方法（利用者からの削除要求への対応可否を含む）を確認しておくと、後の説明責任を果たしやすくなります。契約終了時にデータがどう扱われるか（返却・削除の手続き）も併せて確認したい点です。
通信経路（転送時）と保管時のそれぞれで暗号化が行われているか、鍵管理はどうなっているかは基本的な確認項目です。加えて、ベンダー側の運用担当者がデータにアクセスし得る条件（サポート対応時など）や、その際のアクセス記録の有無も確認しておくと、内部・外部を問わず「誰がデータに触れ得るか」を整理できます。閉じた環境でAIを扱う設計思想については、クローズド環境でのAIエージェント運用も参考になると考えます。
データの扱いと並んで確認したいのが、「誰がそのツールを使えるか」を管理する仕組みです。個人アカウントの寄せ集めではなく、組織として利用者を管理できる状態にすることが、統制の出発点になると考えられます。特に、入退社や異動の多い組織では、アカウントの発行・停止を人手で追いかける運用は破綻しやすく、認証基盤との連携が現実的な選択肢になると考えます。
既存のIDプロバイダと連携できるSSOに対応しているかは、法人利用における基本的な確認項目です。SSOを利用すれば、退職・異動時に認証基盤側でアカウントを止めるだけで生成AIツールへのアクセスも遮断でき、パスワードの個別管理も不要になります。対応している認証方式（SAML／OIDCなど）と、対応がどのプラン以上で提供されるかを確認するとよいと考えられます。
SSOがログインの仕組みであるのに対し、SCIMは利用者アカウントの発行・更新・停止を自動化する仕組みです。入社時に自動でアカウントが作られ、退職時に自動で無効化される状態は、アカウントの取り残し（オーファンアカウント）を防ぐうえで有効だと考えられます。SCIM対応の有無と、グループ単位での権限割り当てができるかを確認しておくと、規模が大きくなったときの運用負荷を抑えやすくなります。
管理者・一般利用者といったロールの分離、管理コンソールでできること（利用状況の確認、設定の強制、データの管理など）の範囲は、導入後の統制を左右します。最小権限の原則に沿って、誰にどこまでの権限を与えるかをあらかじめ設計しておくことが望ましいと考えます。この考え方は、AIエージェントに社内システムへの権限を与える場面にも通じます。権限設計の全体観についてはAIエージェントのガバナンスとリスクも併せて確認いただくと、整理しやすいと考えられます。
導入後に「誰が、いつ、どのように使っているか」を確認できないと、統制は絵に描いた餅になります。監査ログと利用状況の可視化は、インシデントが起きたときの調査だけでなく、平時の運用改善や、経営層への説明のためにも重要な観点だと考えられます。
監査ログとして、ログイン履歴・管理設定の変更・メンバーの追加や削除といった管理操作が記録されるかは、基本的な確認項目です。会話の内容そのものまで管理者が閲覧できるかどうかは、統制の観点とプライバシーの観点の両面から論点になり得るため、記録される範囲と閲覧できる主体を確認しておくことが望ましいと考えます。ログの保持期間や、外部のログ基盤（SIEMなど）へ連携できるかも、監査体制を持つ組織では確認したい点です。
部署別・利用者別の利用量や、どの機能が使われているかを把握できると、契約の席数設計や、活用が進んでいない部署への支援に役立てられます。導入したツールが結局使われないという問題は珍しくなく、これは導入したAIツールが社内で使われない理由とも関わります。監査ログは統制のためだけでなく、活用状況を把握して定着を促す材料にもなると考えられます。
大量のデータ入力や通常と異なる利用パターンなど、リスクの兆候を検知して通知できる仕組みがあるかも、規模によっては確認したい点です。すべてのサービスが同等の機能を備えているわけではないため、自組織のリスク許容度に照らして、どこまでの監視が必要かを先に定義しておくと、過剰な要求にも過小な確認にもならずに済むと考えます。
生成AIを画面から使うだけでなく、API経由で社内システムや自動化ワークフローに組み込む段階になると、確認すべき観点が一段増えます。API鍵（アクセスキー）は、それ自体が「その組織として生成AIを呼び出せる権限」を持つ機密情報であり、その管理の巧拙がそのままセキュリティの水準を左右すると考えられます。
API鍵を誰が発行でき、どこに保管し、どのように失効させるかは、あらかじめルール化しておくことが望ましいと考えます。鍵をソースコードや設定ファイルに直接書き込む（ハードコードする）運用は、リポジトリの共有や流出を通じて鍵が漏れる典型的な経路になり得るため、秘密情報管理の仕組み（シークレットマネージャなど）で扱うのが基本だと考えられます。鍵の定期的なローテーション（更新）と、不要になった鍵の速やかな失効も、運用として組み込みたい点です。
API鍵ごとに利用できる機能や上限を絞れるか、利用元のIPアドレスなどで制限できるかは、万一の流出時に被害を局所化するうえで有効だと考えられます。用途ごとに鍵を分け、それぞれ最小限の権限に絞っておくと、どの鍵で何が起きたかを追いやすく、失効時の影響範囲も限定できます。従量課金のAPIでは、鍵の悪用が想定外のコストにつながる可能性もあるため、利用量の上限やアラートの設定も検討したい点です。
APIを介して社内システムや外部サービスと連携させる場合、生成AIやその上に組むエージェントに「何をさせるか」だけでなく「何をさせないか」を設計することが重要だと考えます。特に、データを書き換えたり外部へ送信したりする操作は、影響が大きいため慎重な権限設計が求められます。社内システムとの連携やクローズドな環境での運用設計については、クローズド環境でのAIエージェント運用で扱う考え方が参考になると考えられます。
生成AIサービスは、単一のベンダーだけで完結しているとは限りません。基盤となるクラウドや、モデルを提供する別の事業者など、複数の委託先・再委託先が関わっていることは一般的だと考えられます。自社が直接契約する相手だけでなく、その先でデータがどう扱われるかまで含めて確認することが、委託先管理の観点になります。
入力したデータが、契約先からさらに別の事業者（インフラ提供者やモデル提供者など）へ渡る場合、その範囲と扱いを確認しておきたい点です。ベンダーが公開するセキュリティ関連の資料（第三者認証の取得状況、データ処理に関する付帯契約など）は、この確認の材料になります。取引先から預かった情報を入力する可能性がある場合は、再委託に関する自社の契約条件と矛盾しないかという観点も重要だと考えられます。
情報セキュリティに関する第三者認証の取得状況や、監査報告書の提供可否は、ベンダーの管理水準を推し量る材料になります。ただし認証の有無だけで安全と断定するのではなく、自組織が求める要件に対して、どの範囲がカバーされているかを読み解く姿勢が求められると考えます。認証名を確認するだけで満足せず、対象範囲と有効期限まで見ることを推奨します。
これらの落とし穴の多くは、技術というより運用・ルールの設計に起因します。統制の全体像を組み立てるうえでは、AIエージェント社内導入の全体像で示す導入プロセスの考え方も、生成AIツールの導入に応用できると考えられます。
ここまでの観点を、実際の導入判断で使えるチェックリストにまとめます。重要なのは、項目を並べることそのものではなく、各項目を「自組織の要件」と「そのツールの実際の設定・仕様」の両方に照らして埋め、判断の根拠を残すことだと考えます。以下は一般的な確認観点の骨子であり、個別の可否は各社の最新の公式情報とご自身の環境での確認を前提としてください。
チェックリストを効果的に使うには、ツールの機能一覧から入るのではなく、自組織が扱う情報の機微度と、社内規程・取引先契約から要件を先に固めることが望ましいと考えます。要件が定まっていれば、各ツールが要件を満たすかを一貫した基準で評価でき、複数候補の比較もぶれにくくなります。逆に要件が曖昧なままだと、機能の多寡に目移りして、本来重要な項目を見落としやすいと考えられます。
全社一斉に導入するのではなく、限定した部署・用途で小さく始め、設定値と運用の実態を記録しながら段階的に広げる進め方が、統制と定着の両面で現実的だと考えます。最初の範囲で「入力してよい情報」「設定の適用状態」「利用ログの確認方法」を確立できれば、それを他部署へ展開する際の型になります。生成AIを安全に定着させるには、ツールの選定と並行して、利用者側の理解を育てることも欠かせないため、ChatGPT業務利用のセキュリティ不安で触れた不安の解消と、ルール・教育の設計を組み合わせることを推奨します。
私たちNsightは、産業用の画像検査・VLM／AIの領域で、現物・現場での検証を通じて「仕様上できること」と「実際の環境で成り立つこと」の差を埋めてきました。元キーエンス画像処理事業部出身の監修者の知見は、カタログ値をそのまま信じず、自分たちの条件で確かめることの重要性という点で、生成AIのセキュリティ確認にも通じると考えています。生成AIツールのデータ取り扱いも、公開情報を鵜呑みにするのではなく、実際の管理画面と自組織の要件を突き合わせて確かめることが前提になると考えます。
本記事は一般的な確認観点の整理であり、各サービスの仕様は変わり得ます。自社の状況に合わせたチェックリストの具体化や、生成AI・AIエージェントを安全に社内へ根づかせる設計については、AI導入・業務自動化・内製化支援の文脈でご相談を承ります。導入の全体像を先につかみたい場合は、AIエージェント社内導入の全体像も併せてご覧いただくと、検討の順序を組み立てやすいと考えられます。
一般論として、法人向けの上位プランやAPIでは業務データを学習に使わない、あるいは管理者設定で制御できるよう設計されていることが多いと考えられます。一方、無償版や個人プランでは改善目的で利用され得ると案内されている場合もあります。ただし扱いはサービスと時期によって変わり得るため、「このサービスは安全」ではなく「この契約形態のこの設定ではこう扱われる」という粒度で、各社の最新の公式情報を確認することを推奨します。
まず自組織が扱う情報の機微度と、社内規程・取引先との契約から「要件」を先に固めることをおすすめします。要件が定まれば、学習利用・データ保管・アクセス管理・監査ログ・API鍵管理・委託先管理という観点を、一貫した基準で評価できます。ツールの機能一覧から入ると重要項目を見落としやすいため、要件を先に、ツールを後に、という順序が実務的だと考えます。
組織の規模や入退社の頻度によります。人数が多く異動が頻繁な組織では、SSOでアクセスの遮断を認証基盤に一元化し、SCIMでアカウントの発行・停止を自動化することで、取り残しアカウントのリスクを抑えやすくなると考えられます。小規模で手動管理が回る段階では優先度が下がることもあります。将来の拡大を見越して、対応可否を契約前に確認しておくと、後の移行が滑らかになると考えます。
生成AIサービスの規約やデータ取り扱いは更新される周期が短い領域です。契約時点で確認しても、その後に仕様が変わる可能性があるため、定期的な再確認を運用に組み込むことが望ましいと考えます。また、設定が「できる」ことと「適用済み」であることは別なので、管理画面での実際の設定値の確認と記録を、継続的に行うことを推奨します。
技術的な統制は重要ですが、それだけでは十分でないと考えます。ツール側の設定が万全でも、利用者がプロンプトに機密情報を安易に入力すれば効果は薄れます。入力してよい情報の区分を定めた利用ルールと、利用者への教育を組み合わせる「両輪」が現実的だと考えられます。統制と活用のバランスをどう取るかは、自組織の状況に応じた設計が必要になるため、必要に応じてご相談ください。
チェックリストの具体化から、利用ルールの設計、社内AIエージェント基盤の内製化まで、貴社の状況に合わせて伴走します。現物・現場での検証を前提に、公開情報を鵜呑みにせず、自社の条件で確かめる進め方をご提案します。
AI導入・内製化について相談する