- 重要な社内情報を生成AIで扱うために、何を管理すればよいか「入れる・入れない」の二択ではなく、契約・ID・データ分類・アクセス権・最小化・API/RAG・ログの7つを揃えて、許容できる水準まで管理する（FIG.01）。
- この情報を、この環境でAIに入力してよいか情報をLEVEL 1〜4に分類し（FIG.02）、環境の承認・法令と契約・LEVEL 4の有無・最小化・権限の順に確認する。迷ったら止まって確認する（FIG.04）。
- 契約書・コード・財務・問い合わせ対応で、どう使えば安全か用途ごとに使う環境・渡す前のデータ加工・事前に確認する契約と権限を決めてから使う（FIG.03）。
重要情報を生成AIで扱えるかは、モデルの性能ではなく、周囲の7つの管理が揃っているかで決まる
上の黒帯が判断の式。01〜07は「どの環境で → 誰が → 何を → AIが何を見るか → どこまで渡すか → どう渡すか → 後から確認できるか」の順。各項目の下段は、その管理が属する層
判断の式 ─ 情報の重要度 × AI環境 × 利用目的 × 管理方法
生成AI（モデル・チャット画面）の安全性だけでは守れない。契約・データ・ID権限・システム・運用の5層を、下の7つの管理で実務に落とす
AIサービス・契約
どの環境で使うか。学習利用の既定値、保持期間、管理者機能、DPAを確認する
層 ─ 契約
ID・アカウント
誰が使うか。会社管理アカウントに限定し、SSO・MFA、入退社時の停止を人事手続きに組み込む
層 ─ ID・権限
データ分類
何を入れてよいか。LEVEL 1〜4で線を引き、具体名で規程に書く（FIG.02）
層 ─ データ
アクセス権
AIが何を見られるか。社内データと接続する前に、全社共有・過剰権限を棚卸しする
層 ─ ID・権限
最小化・匿名化
どこまで渡すか。社名・氏名の仮名化、不要な列の削除、条項の抜粋で渡す量を減らす
層 ─ データ
API・RAG
どう渡すか。何をどう加工し誰の権限で渡すかを、個人の操作ではなくシステムで制御する
層 ─ システム
ログ・監査
後から確認できるか。誰が・いつ・何にアクセスしたか。ログ自体の閲覧権限と保存期間も決める
層 ─ システム・運用
- 「機密情報はAI禁止」の一文は業務価値を殺し、シャドーAIを生む。判断は「入れる・入れない」ではなく「情報の重要度 × AI環境 × 利用目的 × 管理方法」の掛け算で行う
- 中心は7つの管理＝契約・ID・データ分類・アクセス権・最小化・API/RAG・ログ。情報はLEVEL 1〜4に分類し、パスワードやAPIキー等のLEVEL 4は原則AIに入力しない
- 「法人版だから安全」ではない。2026年8月時点の各社公式仕様と契約を確認し、リスクをゼロにするのではなく許容できる水準まで管理する
1. 「機密情報はAIに入力禁止」の一文で、何が起きているか
生成AIの利用ガイドラインを作った会社の多くが、「機密情報を入力してはいけない」という一文を入れています。企業のAI導入を支援していて感じるのは、この一文がルールとして機能していないケースが多いことです。
理由は2つあります。1つ目は、現場が生成AIでやりたいことのほとんど──契約書のレビュー、商談履歴の分析、財務資料の読み込み、ソースコードの修正、社内資料の検索──が、何らかの形で機密情報に触れるからです。禁止の一文は、生成AIの業務価値の大部分を同時に禁止しています。
2つ目は、禁止しても利用は止まらないからです。会社が使える環境を用意しなければ、社員は個人アカウントのChatGPTで仕事を片付けます。いわゆるシャドーAIです。会社が把握も管理もできない場所で、最も無防備な形の利用が始まる。禁止はリスクをゼロにするのではなく、見えなくするだけです。
この記事では、「入れる・入れない」の二択ではなく、「情報の重要度 × AI環境 × 利用目的 × 管理方法」の掛け算で判断するための実務を整理します。なお、無料版と法人向けプランの違いそのものの入門整理は別記事「機密情報をChatGPTに入れて大丈夫？」にまとめています。本稿はその先、重要情報を実際に扱うための「管理体制」を扱います。
2. そもそも「機密情報」とは何か──一括りにできない
企業が扱う情報は、リスクの大きさがまったく違います。
- 公開情報（Webサイト、プレスリリース）
- 一般的な社内情報（議事録、マニュアル）
- 顧客情報・個人情報（氏名、連絡先、取引履歴）
- 契約書・見積書
- 未公開の経営情報・財務情報
- ソースコード
- 営業秘密（製法、ノウハウ、顧客リスト）
- 顧客から秘密保持義務を負って預かっている情報
- APIキー（システム同士の接続に使う認証の鍵）、パスワード、秘密鍵、決済認証情報
最後の行だけ性質が違います。APIキーや秘密鍵は「読まれると困る情報」ではなく「使われると侵入される鍵」であり、漏えいした瞬間に不正アクセスに直結します。一般的な議事録は漏れれば困りますが、事業は止まりません。顧客から預かった情報には、漏えいリスク以前に「自社の判断だけで外部サービスに処理させてよいのか」という契約上の問題があります。
「機密情報」という一括りでルールを作ると、この濃淡が消えます。議事録もAPIキーも同じ扱いになり、「全部禁止」か「全部黙認」のどちらかに倒れる。管理の出発点は、情報を分類することです（後述のLEVEL 1〜4）。
3. 全面禁止は最適解か
公平に言えば、全面禁止にはメリットがあります。AI経由の漏えい経路を構造的に絶てること、社員ごとの判断が不要になることです。扱う情報の大半が他社から預かった秘密情報である事業なら、合理的な選択にもなり得ます。
ただしコストも明確です。契約書レビューも社内データ分析もできず、コーディング支援は限定され、RAG（社内資料を検索して答えるAIの仕組み。詳しくは管理⑥）や社内検索の仕組みも作れません。業務効率化の範囲は「公開情報の要約」程度に縮みます。そして、シャドーAIが発生します。
特に最後の点は、禁止の目的そのものを裏切ります。会社管理の環境なら残せたはずのログも権限管理もない場所に、業務データが流れる。全面禁止は「リスクを取らない選択」に見えて、実際には「管理できないリスクへの置き換え」になりがちです。
だから問いを変えます。「機密情報だから禁止」ではなく、「この重要度の情報を、この環境で、この目的のために、この管理のもとで扱ってよいか」。以下の7つの管理は、この判断のための土台です。
4. 重要情報を生成AIで扱うための「7つの管理」
7つの管理とは、(1) AIサービス・契約の管理──どの環境で使うか、(2) ID・アカウントの管理──誰が使うか、(3) データ分類──何を入れてよいか、(4) アクセス権の管理──AIが何を見られるか、(5) データ最小化・匿名化──どこまで渡すか、(6) API・RAG（システム連携・社内資料検索型AI）の設計──どう渡すか、(7) ログ・監査──使われ方を確認できるか、です。構造としては、生成AIというモデルの周りを契約・データ・ID権限・システム・運用の5つの層が囲み、7つの管理がその層を実務の手順に落としている、と捉えると全体像がつかめます（FIG.01）。
01AIサービス・契約──個人向けと企業向けは別物
同じ製品名でも、個人向けと企業向けではデータの取り扱いが別物です。先に言葉を1つだけ補足します。「モデル学習に使われる」とは、入力した内容がAIそのものを賢くするための訓練データとして取り込まれ、自社の管理が及ばないところでAIの改善に使われる可能性がある、という意味です。この前提で、各社公式ドキュメントを整理すると次のようになります（2026年8月14日確認、2026年9月25日に再確認）。
- ChatGPT（OpenAI）——個人向け（Free/Plus）は既定で入力がモデル学習に使われることがある（設定でオプトアウト可能）。Business（2025年8月に「Team」から改称）とEnterpriseは既定で学習に使わない。SSO（会社のIDで各サービスにまとめてログインする仕組み）は両プラン対応だが、SCIM（入退社にあわせてアカウントを自動で作成・停止する仕組み）によるユーザー管理の自動化、監査ログ（誰がいつ何をしたかの操作記録）を取得するCompliance API、日本を含む保存地域の指定はEnterprise側の機能。APIも既定で学習に使われず、保持は不正利用監視のため最大30日（審査を経て保持なしを選べる場合がある）
- Claude（Anthropic）——個人向け（Free/Pro/Max）は、入力を学習に使うことを許可するかを利用者が設定で選ぶ方式（許可時のデータ保持は最大5年）。Team/EnterpriseとAPIは既定で学習に使わず、EnterpriseはSSO・SCIM・監査ログ・保持期間設定に対応。開発で使うClaude Codeも法人契約では学習に使われず、Amazon BedrockやGoogle Cloud経由で使う構成（自社が契約するクラウドの中でAIを動かす方式）が公式にサポートされている
- Gemini（Google）——個人向けはチャットの一部が人間のレビュアーに確認されることがあり、既定で学習にも使われる。Google自身が公式ヘルプで「機密情報を入力しないでください」と明記。Gemini for Google Workspaceは、許可なく自社ドメイン（自社のWorkspace環境）の外でモデル学習や人間レビューに使われないことが明示され、Workspaceの既存のデータ保護・管理コンソールでの利用制御・監査ログが適用される
- Microsoft 365 Copilot（2026年9月時点の公式ドキュメントでは「Microsoft Copilot」への名称変更が案内されています）——プロンプト（利用者がAIに入力する指示文）・応答・社内データは基盤モデルの学習に使われないと明記。ユーザーが閲覧権限を持つデータのみを参照し、対話はMicrosoft Purview（Microsoftの情報管理・監査ツール群）の監査ログに記録され、秘密度ラベル（ファイルに付ける「社外秘」等の電子的な印）やeDiscovery（調査時にデータを検索・保全する機能）など既存のコンプライアンス体系が適用される
構図は共通です。個人向けは「本人の設定次第」で学習に使われうるのに対し、企業向けは業務データを既定で学習に使わないことを各社が明示しています。ただし名称も仕様も頻繁に変わる分野です（ChatGPTのプラン改称、Microsoft 365 Copilotの名称変更のほか、Microsoftの共有対策機能の一つであるRestricted SharePoint Searchは提供終了が公表されています）。契約時は必ずその時点の公式ドキュメントを確認してください（記事末尾に各社の公式情報をまとめています）。
出典OpenAI Enterprise privacy／How your data is used to improve model performance／Identity and access for managed workspaces（BusinessはSSO可・単体ではSCIMなし）／Data residency（新規Enterprise/Eduと対象のAPI顧客、日本を含む）／Your data and the OpenAI API、Anthropic Claude Code: Data usage／Is my data used for model training?／What is the Enterprise plan?、Google Gemini アプリ プライバシー ハブ／Google Workspace の生成 AI に関するプライバシー ハブ、Microsoft Data, Privacy, and Security for Microsoft Copilot／Audit logs for Copilot and AI applications／Restricted SharePoint Search 確認日 2026-09-25
そして「有料版だから安全」という判断は成立しません。個人のPlus課金は会社の管理外ですし、法人契約でも設定と運用が伴わなければ管理されているとは言えません。確認すべきはプラン名ではなく、学習利用の既定値、保持期間と削除、管理者機能、SSO・MFA（パスワードに加えスマホ確認などを重ねる本人確認）・SCIM、監査ログ、データ保存場所とサブプロセッサ（AI事業者がデータ処理を再委託している先）、契約上のデータ利用条件（利用規約や、データの取り扱い条件を定めるDPAと呼ばれる契約）、そしてAPI利用時の条件（チャット画面とは異なる場合がある）です。
02ID・アカウント──退職者がAIにアクセスできる会社
原則はシンプルです。業務利用は会社管理アカウントに限定し、個人アカウントの業務利用を認めない。これができていないと、他のすべての管理が無効になります。実務では、SSOでの認証一元化とMFAの必須化、入退社・異動時のアカウント発行・停止の人事プロセスへの組み込み、四半期ごとの権限レビュー、管理者アカウントの分離保護、そして業務に必要な権限だけを付与する最小権限の原則です。
見落とされやすいのが退職者です。SSOに統合されていない単独契約のAIサービスは退職処理から漏れ、退職者のアカウントが社内データに接続されたAIにアクセスできる状態が残ります。昔からあるID管理の問題ですが、AIが社内データと接続されるほど影響が大きくなります。
03データ分類──LEVEL 1〜4で線を引く
社員が現場で判断できるように、情報を最低4段階に分類し、段階ごとに使ってよい環境を決めます（FIG.02）。
情報をLEVEL 1〜4に分け、レベルごとに「使ってよい環境」と「使う前の確認」を決めておく
行がLEVEL。左から、情報の例 → 使ってよい環境 → 使う前に確認すること → 5章の規程での区分
| LEVEL | 情報の例 | 使ってよい環境 | 使う前に確認すること | 規程での区分 |
|---|---|---|---|---|
| 1 公開情報 | Webサイト、プレスリリース、公開済み資料 | 承認済みのAI | 公開済みであること | 原則利用可能 |
| 2 社内情報 | 一般的な議事録、マニュアル、社内資料 | 会社管理下のAI環境。個人アカウントは不可 | LEVEL 3・4の情報が混ざっていないか | 条件付き利用 |
| 3 機密情報 | 顧客資料、契約書、未公開の財務、ソースコード、営業秘密 | 承認済みの企業向け環境のみ | 案件ごとに目的・アクセス権・契約条件（法令・顧客とのNDA・社内規程）を確認 | 条件付き利用 |
| 4 最重要情報 | パスワード、秘密鍵、APIキー、アクセストークン、決済認証情報 | 原則AIに直接入力しない | AI以前に、シークレット管理でコードや設定から分離する | 原則入力禁止 |
表は横にスクロールできます
右端の列は、5章の3区分とLEVEL 1〜4の対応の一例です。顧客からAIでの処理を禁止されている情報や、法令・契約上外部処理が認められていない情報は、LEVELにかかわらず原則入力禁止として扱います。
04アクセス権──AIは権限を破らない。権限の緩さを顕在化させる
生成AIをGoogle DriveやSharePoint、Notion、Slackと接続すると、AIはそのユーザーの既存アクセス権の範囲で情報を検索します。AIは権限を破りません。問題は、その既存アクセス権が適切に設計されているかです。
社員100人の会社で、本来は経営陣と経理の10人だけが見るべき財務フォルダに、過去の「とりあえず全社共有」の名残で50人がアクセスできるとします。人間だけの運用では誰もフォルダの奥まで探しに行かず、問題は表面化しません。しかしAI検索が入ると、権限上アクセスできる情報には数秒で到達します。AIが漏えいさせたのではなく、放置された過剰権限をAIが顕在化させたのです。
だから、社内データと接続するAIの導入前に、既存アクセス権を棚卸しします。確認するのは、「全社員」共有になっているフォルダ・サイトの一覧、グループ権限の中身が現在の組織と合っているか、外部共有や「リンクを知っている全員」設定の放置、退職者アカウントの残存と業務上不要になった過剰権限、そして最小権限への是正と定期的なアクセスレビューの仕組み化です。
これはeap独自の見解ではありません。マイクロソフト自身がCopilot導入企業向けに、過剰共有（オーバーシェアリング）を是正するための公式ガイダンスを公開しています。AIを売る側が「導入前に共有権限を整備してほしい」と言っているのです。どのベンダーを選んでも、権限設計の宿題は自社側に残ります。
出典Microsoft Learn「Secure & Governed Data Foundation for Microsoft Copilot - Foundational Deployment Guidance」（過剰共有の是正を柱の一つとする導入ガイダンス） 確認日 2026-09-25
05データ最小化・匿名化──そのまま渡す必要はあるか
重要情報をAIで扱うと決めた場合も、「元データをそのまま渡す必要があるか」は毎回問う価値があります。Before「株式会社ABC、担当者：山田太郎、年間売上3億円、契約金額2,000万円…」に対して、After「A社、担当者X、年間売上約3億円、契約金額約2,000万円…」。契約条件のリスクを洗い出したいだけなら、社名も担当者の実名も分析の役に立ちません。
目的によっては、氏名・メールアドレスの削除、顧客名の仮名化、不要な列の削除、数値のレンジ化、必要な条項だけの抜粋といった加工で、リスクを大きく下げられます。原則は1つ、AIに渡すデータは目的の達成に必要な最小限にする。個人情報保護の基本的な考え方とも一致しますし、万一の際の影響範囲を最初から小さくしておく設計でもあります。
06API・RAG──「画面に貼る」以外の選択肢
重要情報を大規模・継続的に扱うなら、設計の選択肢が変わります。社員が毎回ファイルをアップロードする方式は、何が渡るかが個人の操作に依存し、マスキングも人任せです。API（システム同士を直接つなぐ接続口。人が画面に貼る代わりに、システムがAIとやり取りする方式）・RAG・社内AIシステムなら、「どのデータを、どう加工して、誰の権限で渡すか」をシステム側で制御できます。
RAG（検索拡張生成）は専門用語に聞こえますが、仕組みは単純です。AIに会社の全データを覚えさせるのではなく、質問されたときに、その質問者が見る権限を持つ情報の中から必要な部分だけを検索してAIに渡し、回答させる。データは権限管理された社内基盤に置いたままです。
ただし「RAGにすれば安全」ではありません。検索対象の権限が緩ければ緩いまま答えますし、検索インデックス（検索を速くするための索引データ）という新しいデータの置き場にも権限・保持・削除の管理が必要で、外部AIモデルに渡す部分には契約・仕様の確認が要ります。RAGの価値は「安全になる」ことではなく、「何をどこまで渡すかを、個人の注意力ではなくシステムの設計で決められる」ことです。
07ログ・監査──「誰が・いつ・何を」を後から確認できるか
重要情報を扱う以上、「誰が、いつ、どのAIを使い、どのデータにアクセスしたか」を可能な範囲で確認できる状態が必要です。深夜の大量データアクセスなど異常利用の検知、退職予定者・異動者の権限確認、漏えいが疑われたときに何が渡った可能性があるかの特定、承認外サービス利用の把握──いずれもログがなければ調査のしようがありません。企業向けプランの監査ログ、SSOの認証ログ、社内システムのアクセスログを組み合わせれば、多くはカバーできます。
一方で逆説的な注意点があります。プロンプト（AIへの入力文）の全文を無制限に保存すると、そのログ自体が機密情報の集積地になります。契約書をレビューさせたログには、契約書の中身が入っているからです。ログにも「何のために取り、誰が見られ、いつまで保存するか」という、データと同じ管理が必要です。
5. 入力してよい情報・いけない情報を明文化する
「機密情報は入力禁止」では社員は判断できません。規程には具体名で書きます。
- 原則入力禁止——パスワード、APIキー、秘密鍵、アクセストークン、クレジットカード等の認証・決済情報、顧客からAIでの処理を禁止されている情報、法令・契約上外部処理が認められていない情報
- 条件付き利用（承認済み環境＋案件ごとの確認）——契約書、顧客資料、財務資料、営業情報、ソースコード、社内議事録
- 原則利用可能（承認済み環境で）——公開情報、機密情報を含まない一般的な文章作成・翻訳・要約
この3区分をLEVEL 1〜4と対応させておけば（FIG.02の右端の列）、社員は「この情報はどの区分か」だけを考えればよくなります。
6. ユースケース別──どう管理すれば使えるか
契約書レビュー、ソースコード、財務分析、顧客問い合わせ対応の4つで、よくある悪い例と、同じ業務を安全に進めるための条件を並べます（FIG.03）。
同じ業務でも、「使う環境・渡す前の加工・事前の確認」を決めれば、管理された形でAIに任せられる
行が用途。左の悪い例を、右の3列の条件に置き換える。最右列は主に効く管理（FIG.01の番号）
| 用途 | 悪い例 | 使う環境 | 渡す前の加工 | 事前に確認すること | 主な管理 |
|---|---|---|---|---|---|
| 契約書レビュー | 個人のChatGPTアカウントに、顧客とのNDAをそのままアップロード | 会社承認済みの企業向けAI環境 | 必要に応じて社名・担当者名をマスキング | そのNDA自体がAI利用を制約していないか | 01・03・05 |
| ソースコード | 本番環境のAPIキーやDB接続情報が埋め込まれたコードをそのまま貼る | 会社承認済みの開発用AI環境 | シークレットを環境変数やSecrets Managerでコードから分離 | LEVEL 4の情報がコードや設定に残っていないか | 01・03・06 |
| 財務分析 | 全社員がアクセスできる環境・共有フォルダに未公開の決算データを置く | 財務担当者と経営陣だけがアクセスできる環境 | 分析に不要な個人情報（給与明細の氏名等）を除去 | 利用者と参照範囲のアクセス権が適切か | 04・05 |
| 顧客問い合わせ対応 | 氏名・住所・電話番号・問い合わせ履歴を無条件で外部AIへ送信する仕組み | API・RAGで取得範囲を制御した仕組み | 回答生成に必要なデータだけを取得し、個人を特定する情報をマスキング | 送信先AIの契約条件（学習利用・保持期間）と、システム側の権限・ログ | 01・05・06・07 |
表は横にスクロールできます
この表は判断の一例で、実績を示すものではありません。個人情報や顧客から預かった情報の扱いは、個別の契約・法令によって変わります（8章）。
共通するのは、「AIに任せるか」ではなく「どの環境で、どのデータを、どう加工して任せるか」を設計している点です。
7. AI利用の判断フロー
社員と管理者が同じ判断を再現できるよう、フローにしておきます（FIG.04）。
「入力してよいか」は、上から順に6つの問いで決める。迷ったら止まって確認する
Q1から順に答える。「はい」なら右の結論（スマートフォンでは下）に従い、「いいえ」なら次の問いへ進む
- その情報は、すでに公開されている情報かはいの場合承認済みのAIで利用可。LEVEL 1として扱う
- 使おうとしているのは、個人アカウントや会社が承認していないAI環境かはいの場合利用しない。使いたい業務があれば、環境整備を申請する
- 法令・契約・NDA上、外部AIでの処理が認められていない、または認められているか不明かはいの場合利用しない。管理部門・専門家に確認する
- パスワード・APIキーなど、入力禁止情報（LEVEL 4）を含むかはいの場合除去・マスキングしてから、Q1に戻る
- 目的の達成に必要のないデータが含まれているかはいの場合データを削減し、必要最小限に絞ってから進む
- 利用者や参照先のアクセス権が、業務に必要な範囲を超えているかはいの場合権限を是正してから利用する
8. 法務面──「学習されない」と「入力してよい」は別の問題
技術や設定では解決しない論点があります。自社がそのデータを外部のAIサービスで処理する権限をそもそも持っているか、です。
AI事業者が「学習に使わない」と明示していても、それは事業者側の約束にすぎません。顧客とのNDAに外部処理の制限があれば、学習の有無にかかわらず、データを渡すこと自体が契約違反になり得ます。個人情報であれば、個人情報保護法上の第三者提供・委託（個人データを外部に渡す・預ける際に法律が求める整理）や、外国にある事業者への提供の扱いを確認する必要があります。営業秘密として法的保護を受けるには秘密として管理されている実態が必要で、無管理なAI利用はそれを損なう可能性もあります。
この記事は法的助言ではありません。顧客から預かった情報や大量の個人データを扱う場合など、判断に迷うケースでは弁護士等の専門家に確認してください。重要なのは、「AI事業者が学習しないと言っているから大丈夫」という一段だけの判断で止めないことです。
9. 経営者が最初にやるべきこと
7つを完璧にしてから使い始める必要はありません。最初の30日でやるべきことは3つです。
- 利用実態を把握する（1週目）。社員がすでに何をどう使っているかを、責めない前提で調査する。シャドーAIの実態が、ルール作りの出発点になります。
- 会社管理のAI環境を用意し、契約条件を確認する（2〜3週目）。「使ってよい場所」を先に作らないと、禁止だけが先行してシャドーAIが続きます。
- 入力禁止情報の具体名リストとLEVEL分類の第一版を出す（4週目）。完璧な規程を半年かけて作るより、1枚のルールを出して運用しながら改訂するほうが、現実の事故を早く減らせます。
アクセス権の棚卸しとログ・監査の整備は、社内データ接続型のAI（コネクタ＝AIとGoogle Drive等をつなぐ接続機能、RAG、Copilot等）を導入する前までに終える宿題として、並行して進めます。
30日の計画を立てる前に、最初に確認する3項目
- 業務で個人アカウントのAIが使われていないか責めない前提で、部署ごとに「何に・どのサービスを使っているか」を聞き取ります。使われていれば、禁止の強化より先に会社管理の環境を用意します（ID・アカウントの管理）。
- 「入力してはいけない情報」を具体名で答えられるか「機密情報」という言葉しか出てこなければ、まだ線は引けていません。FIG.02のLEVEL 4（パスワード・APIキー等）と、顧客からAIでの処理を禁止されている情報から書き出します。
- AIと接続する予定の共有フォルダに、「全社員」共有や外部共有が残っていないか財務・人事・契約のフォルダから、共有範囲の一覧を出して確認します。社内データと接続するAIを導入する前までに、是正を終えます。
10. まとめ──リスクは「管理できているか」に宿る
- 「機密情報はAI禁止」の一文は業務価値を殺し、シャドーAIを生む。管理されない利用が最大のリスク
- 情報はLEVEL 1〜4に分類する。パスワード・APIキー等のLEVEL 4は原則入力しない
- 個人向けと企業向けはデータの取り扱いが別物。ただし「法人版だから安全」ではなく、学習利用・保持・管理機能・契約条件を公式情報で確認する
- 社内データと接続するなら、AIより先に既存アクセス権を棚卸しする
- 渡すデータは目的に必要な最小限に。大規模に扱うならAPI・RAGでシステムとして制御する
- リスクはゼロにならない。技術・契約・権限・人・運用の組み合わせで、許容できる水準まで管理する
株式会社eapは、生成AIの導入を「ツールの契約」からではなく「設計」から支援しています。AI利用ガイドラインの策定、データ分類とアクセス権の整理、社内データと生成AIの連携、RAGやAIエージェントを含むシステム開発、業務フローへの組み込みまで、この記事に書いた内容を実際の企業で形にしてきました。最初にやるのは、ChatGPTを勧めることではありません。「どの業務をAIに任せると効果が大きいか」「そのために必要な情報はどのレベルか」「その情報を扱える環境と管理体制は何か」を、経営者と一緒に整理することです。
参考（2026年8月14日確認・2026年9月25日再確認の各社公式情報）：OpenAI「Enterprise privacy」「How your data is used to improve model performance」「Your data and the OpenAI API」、Anthropic「Commercial Terms of Service」「How long do you store my organization's data?」「Claude Code: Data usage」、Google「Gemini アプリ プライバシー ハブ」「Google Workspace の生成 AI に関するプライバシー ハブ」、Microsoft「Data, Privacy, and Security for Microsoft 365 Copilot」「Audit logs for Copilot and AI applications」「Secure & Governed Data Foundation for Microsoft Copilot」、OpenAI「Identity and access for managed workspaces」「Data residency and inference residency for ChatGPT」、Anthropic「What is the Enterprise plan?」。プラン名称・仕様は変更される可能性があるため、導入時は必ず最新の公式ドキュメントをご確認ください。