重要な社内情報を生成AIで扱うには？
経営者が押さえるべき「7つの管理」

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というモデルの周りを5つの層が囲むイメージで捉えると全体像がつかめます。

Control 01AIサービス・契約──個人向けと企業向けは別物

同じ製品名でも、個人向けと企業向けではデータの取り扱いが別物です。先に言葉を1つだけ補足します。「モデル学習に使われる」とは、入力した内容がAIそのものを賢くするための訓練データとして取り込まれ、自社の管理が及ばないところでAIの改善に使われる可能性がある、という意味です。この前提で、2026年8月時点の各社公式ドキュメントを整理すると次のようになります。

• 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——プロンプト（利用者がAIに入力する指示文）・応答・社内データは基盤モデルの学習に使われないと明記。ユーザーが閲覧権限を持つデータのみを参照し、対話はMicrosoft Purview（Microsoftの情報管理・監査ツール群）の監査ログに記録され、秘密度ラベル（ファイルに付ける「社外秘」等の電子的な印）やeDiscovery（調査時にデータを検索・保全する機能）など既存のコンプライアンス体系が適用される

構図は共通です。個人向けは「本人の設定次第」で学習に使われうるのに対し、企業向けは業務データを既定で学習に使わないことを各社が明示しています。ただし名称も仕様も頻繁に変わる分野です（ChatGPTのプラン改称のほか、Microsoftの共有対策機能には提供終了が予定されているものもあります）。契約時は必ずその時点の公式ドキュメントを確認してください（記事末尾に各社の公式情報をまとめています）。

そして「有料版だから安全」という判断は成立しません。個人のPlus課金は会社の管理外ですし、法人契約でも設定と運用が伴わなければ管理されているとは言えません。確認すべきはプラン名ではなく、学習利用の既定値、保持期間と削除、管理者機能、SSO・MFA（パスワードに加えスマホ確認などを重ねる本人確認）・SCIM、監査ログ、データ保存場所とサブプロセッサ（AI事業者がデータ処理を再委託している先）、契約上のデータ利用条件（利用規約や、データの取り扱い条件を定めるDPAと呼ばれる契約）、そしてAPI利用時の条件（チャット画面とは異なる場合がある）です。

Control 02ID・アカウント──退職者がAIにアクセスできる会社

原則はシンプルです。業務利用は会社管理アカウントに限定し、個人アカウントの業務利用を認めない。これができていないと、他のすべての管理が無効になります。実務では、SSOでの認証一元化とMFAの必須化、入退社・異動時のアカウント発行・停止の人事プロセスへの組み込み、四半期ごとの権限レビュー、管理者アカウントの分離保護、そして業務に必要な権限だけを付与する最小権限の原則です。

見落とされやすいのが退職者です。SSOに統合されていない単独契約のAIサービスは退職処理から漏れ、退職者のアカウントが社内データに接続されたAIにアクセスできる状態が残ります。昔からあるID管理の問題ですが、AIが社内データと接続されるほど影響が大きくなります。

Control 03データ分類──LEVEL 1〜4で線を引く

社員が現場で判断できるように、情報を最低4段階に分類します。

Control 04アクセス権──AIは権限を破らない。権限の緩さを顕在化させる

生成AIをGoogle DriveやSharePoint、Notion、Slackと接続すると、AIはそのユーザーの既存アクセス権の範囲で情報を検索します。AIは権限を破りません。問題は、その既存アクセス権が適切に設計されているかです。

社員100人の会社で、本来は経営陣と経理の10人だけが見るべき財務フォルダに、過去の「とりあえず全社共有」の名残で50人がアクセスできるとします。人間だけの運用では誰もフォルダの奥まで探しに行かず、問題は表面化しません。しかしAI検索が入ると、権限上アクセスできる情報には数秒で到達します。AIが漏えいさせたのではなく、放置された過剰権限をAIが顕在化させたのです。

だから、社内データと接続するAIの導入前に、既存アクセス権を棚卸しします。確認するのは、「全社員」共有になっているフォルダ・サイトの一覧、グループ権限の中身が現在の組織と合っているか、外部共有や「リンクを知っている全員」設定の放置、退職者アカウントの残存と業務上不要になった過剰権限、そして最小権限への是正と定期的なアクセスレビューの仕組み化です。

これはeap独自の見解ではありません。マイクロソフト自身がCopilot導入企業向けに、過剰共有（オーバーシェアリング）を是正するための公式ガイダンスを公開しています。AIを売る側が「導入前に共有権限を整備してほしい」と言っているのです。どのベンダーを選んでも、権限設計の宿題は自社側に残ります。

Control 05データ最小化・匿名化──そのまま渡す必要はあるか

重要情報をAIで扱うと決めた場合も、「元データをそのまま渡す必要があるか」は毎回問う価値があります。Before「株式会社ABC、担当者：山田太郎、年間売上3億円、契約金額2,000万円…」に対して、After「A社、担当者X、年間売上約3億円、契約金額約2,000万円…」。契約条件のリスクを洗い出したいだけなら、社名も担当者の実名も分析の役に立ちません。

目的によっては、氏名・メールアドレスの削除、顧客名の仮名化、不要な列の削除、数値のレンジ化、必要な条項だけの抜粋といった加工で、リスクを大きく下げられます。原則は1つ、AIに渡すデータは目的の達成に必要な最小限にする。個人情報保護の基本的な考え方とも一致しますし、万一の際の影響範囲を最初から小さくしておく設計でもあります。

Control 06API・RAG──「画面に貼る」以外の選択肢

重要情報を大規模・継続的に扱うなら、設計の選択肢が変わります。社員が毎回ファイルをアップロードする方式は、何が渡るかが個人の操作に依存し、マスキングも人任せです。API（システム同士を直接つなぐ接続口。人が画面に貼る代わりに、システムがAIとやり取りする方式）・RAG・社内AIシステムなら、「どのデータを、どう加工して、誰の権限で渡すか」をシステム側で制御できます。

RAG（検索拡張生成）は専門用語に聞こえますが、仕組みは単純です。AIに会社の全データを覚えさせるのではなく、質問されたときに、その質問者が見る権限を持つ情報の中から必要な部分だけを検索してAIに渡し、回答させる。データは権限管理された社内基盤に置いたままです。

ただし「RAGにすれば安全」ではありません。検索対象の権限が緩ければ緩いまま答えますし、検索インデックス（検索を速くするための索引データ）という新しいデータの置き場にも権限・保持・削除の管理が必要で、外部AIモデルに渡す部分には契約・仕様の確認が要ります。RAGの価値は「安全になる」ことではなく、「何をどこまで渡すかを、個人の注意力ではなくシステムの設計で決められる」ことです。

Control 07ログ・監査──「誰が・いつ・何を」を後から確認できるか

重要情報を扱う以上、「誰が、いつ、どのAIを使い、どのデータにアクセスしたか」を可能な範囲で確認できる状態が必要です。深夜の大量データアクセスなど異常利用の検知、退職予定者・異動者の権限確認、漏えいが疑われたときに何が渡った可能性があるかの特定、承認外サービス利用の把握──いずれもログがなければ調査のしようがありません。企業向けプランの監査ログ、SSOの認証ログ、社内システムのアクセスログを組み合わせれば、多くはカバーできます。

一方で逆説的な注意点があります。プロンプト（AIへの入力文）の全文を無制限に保存すると、そのログ自体が機密情報の集積地になります。契約書をレビューさせたログには、契約書の中身が入っているからです。ログにも「何のために取り、誰が見られ、いつまで保存するか」という、データと同じ管理が必要です。

5. 入力してよい情報・いけない情報を明文化する

「機密情報は入力禁止」では社員は判断できません。規程には具体名で書きます。

• 原則入力禁止——パスワード、APIキー、秘密鍵、アクセストークン、クレジットカード等の認証・決済情報、顧客からAIでの処理を禁止されている情報、法令・契約上外部処理が認められていない情報
• 条件付き利用（承認済み環境＋案件ごとの確認）——契約書、顧客資料、財務資料、営業情報、ソースコード、社内議事録
• 原則利用可能（承認済み環境で）——公開情報、機密情報を含まない一般的な文章作成・翻訳・要約

この3区分をLEVEL 1〜4と対応させておけば、社員は「この情報はどの区分か」だけを考えればよくなります。

6. ユースケース別──どう管理すれば使えるか

契約書レビュー。悪い例は、社員が個人のChatGPTアカウントに顧客とのNDAをそのままアップロードすること。改善例は、会社承認済みの企業向けAI環境を使い、そのNDA自体がAI利用を制約していないかを確認したうえで、必要に応じて社名・担当者名をマスキングしてレビューさせることです。

ソースコード。悪い例は、本番環境のAPIキーやDB接続情報が埋め込まれたコードをそのままAIに貼ること。改善例は、シークレット（パスワードやAPIキー等の秘密情報）を環境変数やSecrets Manager（秘密情報を保管する金庫のような専用サービス）でコードから分離し（これはAI利用の前提となる開発衛生です）、会社承認済みの開発用AI環境でコードを扱うことです。

財務分析。悪い例は、全社員がアクセスできるAI環境・共有フォルダに未公開の決算データを置いて分析させること。改善例は、財務担当者と経営陣だけがアクセスできる環境に限定し、分析に不要な個人情報（給与明細の氏名等）を除去してから渡すことです。

顧客問い合わせ対応。悪い例は、顧客の氏名・住所・電話番号・問い合わせ履歴を無条件で外部AIへ送信する仕組みを作ること。改善例は、回答生成に必要なデータだけを取得して個人を特定する情報はマスキングし、送信先AIの契約条件（学習利用・保持期間）とシステム側の権限・ログを確認して運用することです。

共通するのは、「AIに任せるか」ではなく「どの環境で、どのデータを、どう加工して任せるか」を設計している点です。

7. AI利用の判断フロー

社員と管理者が同じ判断を再現できるよう、フローにしておきます。

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等）を導入する前までに終える宿題として、並行して進めます。

10. まとめ──リスクは「管理できているか」に宿る

• 「機密情報はAI禁止」の一文は業務価値を殺し、シャドーAIを生む。管理されない利用が最大のリスク
• 情報はLEVEL 1〜4に分類する。パスワード・APIキー等のLEVEL 4は原則入力しない
• 個人向けと企業向けはデータの取り扱いが別物。ただし「法人版だから安全」ではなく、学習利用・保持・管理機能・契約条件を公式情報で確認する
• 社内データと接続するなら、AIより先に既存アクセス権を棚卸しする
• 渡すデータは目的に必要な最小限に。大規模に扱うならAPI・RAGでシステムとして制御する
• リスクはゼロにならない。技術・契約・権限・人・運用の組み合わせで、許容できる水準まで管理する

株式会社eapは、生成AIの導入を「ツールの契約」からではなく「設計」から支援しています。AI利用ガイドラインの策定、データ分類とアクセス権の整理、社内データと生成AIの連携、RAGやAIエージェントを含むシステム開発、業務フローへの組み込みまで、この記事に書いた内容を実際の企業で形にしてきました。最初にやるのは、ChatGPTを勧めることではありません。「どの業務をAIに任せると効果が大きいか」「そのために必要な情報はどのレベルか」「その情報を扱える環境と管理体制は何か」を、経営者と一緒に整理することです。

参考（2026年8月14日確認の各社公式情報）：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」。プラン名称・仕様は変更される可能性があるため、導入時は必ず最新の公式ドキュメントをご確認ください。