社内資料を生成AIに渡してよいか迷う時は、資料の中身だけでなく、もともとの共有範囲と使う環境が判断を左右します。公開済みの商品説明、部署内の作業手順、顧客を含む議事録を同じ箱に入れると、機密情報や個人情報の扱いが見えにくくなります。
生成AIで社内データを扱う前には、学習に使われないことと保存されないことを分けて確認する必要があります。資料の種類、利用環境、必要な部分、更新と削除の担当を分ければ、送る前の確認を業務の表に落とし込めます。
生成AIへ渡す社内データとは何か
社内データは、会社の業務で作られ、共有範囲や更新責任を持つ資料や記録です。生成AIに渡す前の確認では、資料の内容だけでなく、どの範囲で見せてよい情報か、どの利用環境で処理されるかを分けて見ます。
資料の種類を先に分ける
最初に分けるのは、公開商品説明、社内の作業手順、顧客を含む議事録です。公開商品説明は社外に出ている情報を含みますが、古い版や社内向けの補足が混ざると、生成AIの出力に誤った根拠が入りやすくなります。社内の作業手順は部署や役割で共有範囲が決まり、外部へそのまま貼り付ける前に利用環境を確認する必要があります。
顧客を含む議事録は、参加者名、課題、契約条件、金額のような情報が混じる可能性があります。議事録を要約したい場合でも、実物を丸ごと渡すのではなく、目的に必要な部分と外す部分を先に分けます。IPAはAI利用者向けの注意として、クラウドAIに営業秘密を教えないことや、AIブラウザを社内用と社外用で分ける観点を示しています。(IPA AI利用のセキュリティ)
資料の分類は、危険度を一律に決める作業ではありません。同じ商品に関する資料でも、公開済みの説明、社内だけの作業メモ、顧客とのやり取りでは、共有できる相手と残すべきログが変わります。生成AIへ渡す前に、社内データを資料の種類ごとに分けると、機密情報や個人情報が混じる資料を同じ扱いにしない判断ができます。
利用環境で意味が変わる
利用環境は、生成AIを使う場所と条件の組み合わせです。一般向けチャット、法人向けチャット、RAG基盤、業務システムとの連携では、送信先、アクセス権限、保存、更新の扱いが変わります。同じ社内データでも、個人が試しに貼り付ける場合と、会社の契約や管理設定の中で使う場合を同じ前提にしないことが大切です。
Microsoft 365 Copilotは、ユーザーがアクセス権を持つメール、チャット、文書などのMicrosoft Graph内のコンテンツと文脈を使って回答を作る製品として説明されています。(Microsoft 365 Copi(公式))Microsoftは、Microsoft 365 Copilotで使われるプロンプト、応答、Microsoft Graph経由でアクセスされたデータは基盤モデルの学習に使われないと説明しています。ただし、同じ資料が見えるかどうかは、Microsoft 365側の権限モデルに左右されます。
RAG基盤では、社内文書を検索対象に入れ、必要な文書を取り出して回答に使う設計になります。(SynClip context-engi)検索対象は、AIが回答時に参照できる文書群のことで、入れた資料の範囲と権限が回答の前提になります。法人向けチャットやRAG基盤を使う場合でも、現在の契約、利用プラン、管理設定を確認し、特定の環境なら必ず安全だと決めつけない運用が必要です。
横にスクロールして比較できます
| 資料の種類 | 元の共有範囲 | 利用環境 | 先に見る条件 |
|---|---|---|---|
| 公開商品説明 | 社外公開済みの説明や仕様 | 法人向けチャットやRAG基盤 | 版と更新日と公開可否 |
| 社内作業手順 | 部署や役割で共有される手順 | 法人向けチャットや業務連携 | 権限とログと保持期間 |
| 顧客を含む議事録 | 関係者に限られる記録 | 閉じた環境や必要部分のみ | 個人情報と承認と削除責任 |
学習と検索と保存を分ける
学習利用は、入力や応答をモデルの訓練に使う扱いです。検索対象は、回答時に参照させる文書の範囲です。プロンプトに貼ることは、その時の入力として資料を渡す行為であり、保存は入力や応答の履歴がサービス内に残る扱いです。
Microsoft 365 Copilotでは、プロンプト、応答、Microsoft Graph経由でアクセスされたデータは基盤モデルの学習に使われない一方、ユーザーのプロンプトと応答を含むやり取りのデータは保存されると説明されています。(Microsoft 365 Copi(公式))つまり、学習に使われないことと保存されないことは別です。社内データを扱う担当者は、学習利用、検索対象、プロンプト入力、保存履歴を分けて確認すると、利用環境ごとのリスクを見落としにくくなります。
社内データを渡す前の確認の流れ
社内データを生成AIへ渡す前の確認は、資料そのものの危険度だけで決めるより、共有範囲、利用環境、必要部分、責任者、更新削除の順に分けると判断しやすくなります。必要部分とは、目的に対してAIへ見せる必要がある列、段落、添付、参照元だけに絞った範囲です。

元の共有範囲を見る
最初に見るのは、その資料が社外公開済みか、部署内だけで共有されているか、顧客や個人に関する記録を含むかです。公開済みの商品説明は、社外に出ている情報でも、古い版や社内向け補足が混ざれば扱いが変わります。部署内の作業手順は、社内で読める人が限られる前提で作られているため、一般向けのチャットへ丸ごと貼る前に利用環境を確認します。顧客を含む議事録は、参加者名、課題、金額、契約条件などが混じる可能性がある資料として、実物を渡す前に含まれる情報の項目を分類するところから始めます。
IPAはAI利用者向けのセキュリティ資料で、クラウドAIに営業秘密を教えないことや、社内用と社外用のAIブラウザを分ける観点を示しています。(IPA AI利用のセキュリティ)この考え方を業務に移すと、機密情報や個人情報が入る資料は、便利だから先に試すのではなく、利用環境、承認、権限を先に確かめる対象になります。生成AIへ社内データを渡す判断は、AIの性能より前に、元の資料が誰に見せる前提で作られたかを確認する作業です。
共有範囲の確認では、資料の置き場所だけでなく、作成時の前提も見ます。社外公開ページから取った説明でも、公開前の草案、価格改定前の表、営業担当だけに配られた補足が同じフォルダに残っていれば、AIへ渡す範囲は変わります。部署内手順では、担当者名、取引先名、例外対応の履歴が本文やコメントに入っていないかを見ます。議事録では、出席者、発言、課題、金額、契約条件をそのまま使うのではなく、目的に必要な分類情報へ置き換えられるかを先に判断します。
必要部分だけに絞る
必要部分を決める時は、AIに何をさせたいかから逆算します。要約なら対象の段落と判断に必要な前提だけを選び、分類なら列名、分類基準、対象行に絞ります。添付ファイルは、本文の判断に必要なものだけを対象にし、参考として置かれた古い資料や別案件の資料を同じ束に入れないようにします。
SynClipのコンテキスト設計の記事では、社内資料AIに渡す情報を、商品ID、資料の版、承認状態、適用範囲で選ぶ考え方を示しています。(SynClip context-engi)長い資料を広く入れる前に、対象商品、現行版、承認済み、用途に合う資料を分けるほど、AIへ渡す情報は小さくなります。資料を渡す前の確認では、共有範囲と利用条件を先に狭めます。
公開商品説明なら、最新版として使う段落、注意書き、更新日を残し、古いページの文言は外します。社内の作業手順なら、手順の名称、入力する項目、確認者の判断に必要な箇所へ絞り、個人名や不要な履歴を外します。顧客を含む議事録なら、実物を貼るのではなく、課題の分類、決定事項の有無、次に確認する担当のような分類例に置き換えます。必要部分を小さくすると、AIの回答の根拠を見直す時にも、どの資料を見たのか追いやすくなります。
社内資料を絞る時は、資料名だけで判断しない方が実務に合います。商品資料には仕様、注意点、禁止表現、更新履歴が同居しやすく、手順書には操作画面、例外処理、問い合わせ先、過去の暫定対応が混ざります。AIに渡す目的が問い合わせ分類なら、回答文の全体ではなく、分類基準、対象項目、判断に必要な状態だけで足ります。文章作成なら、商品事実と使える表現を残し、承認前の案、古い版、別商品の説明を外すと、出力後の確認も資料単位で戻しやすくなります。

責任者と更新削除を決める
更新責任とは、資料の版が変わった時に、どの資料を現行扱いにし、どの出力を見直すかを決める役割です。削除責任とは、不要になった資料、誤って共有された資料、権限を外すべき資料について、削除や権限変更を依頼する役割です。AIへ渡す前の確認では、利用可否を見る人、資料を更新する人、削除や権限変更を依頼する人を分けると、担当変更が起きても判断が残ります。
SynClipの要件定義記事では、AI開発の依頼前に、業務の入力、出力、人の確認、合格条件、止め方をそろえる考え方を示しています。(SynClip ai-developme)社内データを生成AIへ渡す場面でも、資料を渡す人だけでなく、出力を見て止める人、資料更新後に再確認へ戻す人を置く必要があります。責任者を一人にまとめるより、商品事実を見る人、利用環境を見る人、更新削除を扱う人を分ける方が、実務の確認点を残しやすくなります。
編集部の分担案として、資料管理者が現行版と共有範囲を決め、利用担当者が目的に必要な部分を選び、システム管理者が利用環境の権限と保存条件を確認する形を提案します。全員に広い管理権限を付けず、資料を見る人、AIへ渡す人、結果を承認する人、権限変更を依頼する人を決めます。担当者が異動した時は、資料の保管場所、AIの利用環境、出力履歴、削除依頼の窓口を見直します。
更新削除の担当は、平常時と変更時で分けておくと運用に残ります。平常時は、現行資料の版、利用できる範囲、AIへ渡した記録を確認します。変更時は、資料が更新された日、旧版を検索対象から外す依頼、過去の出力を再確認する範囲を見ます。削除では、元資料の削除だけでなく、AIへ入力した履歴、出力の保存場所、共有リンク、閲覧権限の変更先まで並べると、資料を消したつもりでも回答や履歴に残る状態を避けやすくなります。
生成AIに渡す社内データの3分類
生成AIに渡す社内データは、資料の名前だけでなく、元の共有範囲、利用する環境、必要部分、更新と削除の担当で扱いが変わります。公開商品説明、社内作業手順、顧客を含む議事録の三つに分けると、同じ文章作成や要約でも、渡してよい範囲と止める条件を見やすくなります。
公開商品説明
公開商品説明は、Webサイトや営業資料などで社外へ出せる前提の説明文です。元の共有範囲が広いため、機密情報そのものよりも、版の古さ、抜粋の誤り、現在の商品説明と違う表現が混ざることを先に見ます。公開済みの情報でも、古い版を生成AIへ渡すと、今は使わない仕様や訴求が出力に残る可能性があります。
公開商品説明を使う時は、全文をそのまま貼るより、使いたい目的に必要な段落と更新日を分けます。商品紹介の初稿を作るなら、商品名、主要な仕様、利用上の注意、公開してよい表現だけを渡し、キャンペーン条件や終了した表記は外します。確認担当は、文章の自然さを見る人ではなく、現在の公開情報と一致しているかを見られる人にします。
SynClipの要件定義の考え方では、AIに渡す資料や条件を入力、受け取りたい初稿や確認点を出力として分けます。(SynClip ai-developme)公開商品説明でも、出力を文章だけにせず、使った資料の版や確認点を残す形にすると、古い抜粋を採用した時に差し戻しやすくなります。公開情報だから自由に広げるのではなく、必要部分と更新日を合わせて扱うことが実務の確認になります。
社内の作業手順
社内作業手順は、部署内や担当者内で共有される手順書、チェックリスト、運用メモなどです。外部公開を前提にしていないため、一般向けチャットへ丸ごと貼る前に、利用環境と権限を確認します。IPAはAI利用者向けの注意として、クラウドAIに営業秘密を教えないことや、社内用と社外用のAIブラウザを分けることを挙げています。(IPA AI利用のセキュリティ)
法人向けの環境を使う場合でも、現在の契約、設定、利用プランを見ずに安全だと決めることはできません。Microsoft 365 Copilotは、Microsoft Graph内の文書、メール、チャット、会議、連絡先など、ユーザーがアクセス権を持つ組織データと文脈を使って応答を生成します。(Microsoft 365 Copi(公式))Microsoftは、Microsoft 365 Copilotのプロンプト、応答、Graph経由でアクセスされたデータは基盤LLMの学習に使われないと説明しています。
学習に使われないことと、利用履歴が保存されないことは別です。Microsoft 365 Copilotでは、ユーザーのプロンプトと応答を含むやり取りのデータが保存され、管理者はContent searchやMicrosoft Purviewで確認や保持ポリシーの設定に使えるとされています。(Microsoft 365 Copi(公式))社内作業手順を扱う時は、生成AIへ渡す前に、誰が閲覧できる資料か、やり取りの履歴を誰が管理するか、削除や保持の扱いをどの管理者が見るかを確認します。
手順書の必要部分は、作業順、例外時の連絡先、判断基準、更新日を分けて選びます。たとえば問い合わせ対応の手順なら、回答テンプレートの候補は使えても、担当者個人のメモ、未公開の障害情報、取引先固有の条件は同じ扱いにしません。法人向け環境であっても、既存権限で見える資料が多すぎると、本来はその担当者が使わない手順まで検索対象に入るおそれがあるため、権限と資料の置き場所を先に見直します。
顧客を含む議事録
顧客を含む議事録は、参加者名、所属、課題、金額、契約条件、未確定の要望などが一つの記録に混ざりやすい資料です。議事録の実物を生成AIへ貼る前に、要約したい目的に対して必要な部分だけを取り出します。編集部の確認案では、機密情報や個人情報が混じる資料は、公開商品説明や一般的な手順書と同じ扱いにしません。
分類例として、商談後の次回アクションを整理したい場合は、会社名や個人名をそのまま渡す必要があるかを先に見ます。課題の分類だけが目的なら、参加者名、連絡先、金額、契約条件は外し、課題カテゴリ、期限の有無、担当部署のような粒度にできます。契約条件や金額を含む場合は、利用環境、承認者、保持期間、削除の担当を確認してから扱います。
Microsoft 365 Copilotの説明では、各ユーザーが少なくとも表示権限を持つ組織データだけを表示し、SharePointなどMicrosoft 365サービスの権限モデルを使う重要性が示されています。(Microsoft 365 Copi(公式))この範囲はMicrosoft 365内の権限に基づく説明であり、すべての生成AI環境にそのまま当てはまる条件ではありません。顧客を含む議事録を使う場合は、製品名が似ていても、個人用の環境、法人向けの環境、社内RAG基盤、外部ツール連携の条件を混同しないことが重要です。
顧客を含む議事録では、生成AIに渡す目的を、要約、論点整理、タスク抽出、社内FAQ化のどれに近いかで分けます。要約なら発言の細部まで必要に見えますが、社内FAQ化なら顧客名や金額ではなく、問い合わせカテゴリと回答方針だけで足りる場合があります。必要部分だけに絞る判断表を持つと、議事録を丸ごと渡す前に、外す情報、残す情報、確認する担当を分けられます。
横にスクロールして比較できます
| 資料例 | 必要部分 | 使える環境の例 | 更新削除の担当 |
|---|---|---|---|
| 公開商品説明 | 現行版の商品説明と公開してよい仕様 | 公開情報を扱う法人向け環境や検証用環境 | 商品情報の確認担当と公開面の更新担当 |
| 社内作業手順 | 作業順と判断基準と更新日 | 権限と保存条件を確認した法人向け環境 | 業務責任者と手順書の管理担当 |
| 顧客を含む議事録 | 目的に必要な課題カテゴリと次の行動 | 承認と保持条件を確認した限定環境 | 顧客対応責任者と削除依頼の担当 |
この分類例は、公開済みか、社内限定か、顧客や個人を含むかを先に分けるためのたたき台です。実際の運用では、同じ資料名でも、古い版、未承認の追記、顧客固有の条件が混ざると扱いが変わります。生成AIへ渡す社内データは、資料の種類、利用環境、必要部分、更新削除の担当を同じ表で見て、渡す前の判断を残します。
渡す資料を減らすための確認表
生成AIに社内データを渡す量は、便利そうな資料を足して決めるのではなく、目的から逆算して減らします。文章生成、社内検索、問い合わせ対応では、同じ資料名でも必要な範囲と残す記録が変わります。確認表は、使う前の合意を増やすためではなく、不要な全文投入や権限の広げすぎを止めるために使います。
目的と必要部分を合わせる
文章生成では、出力したい初稿に必要な事実、禁止表現、確認点だけを選びます。社内検索では、利用者が探してよい資料群と参照元の表示を重視します。問い合わせ対応では、回答に使う範囲と人へ戻す条件を先に置くと、顧客情報や社内判断を丸ごと渡さずに済みます。
社内資料を扱うAIでは、資料を多く渡すほど安全になるとは限りません。SynClipの既存整理では、商品が同じか、現行版か、承認済みか、対象業務に使えるかを先に分けるほど、AIへ入る情報を小さくできると説明しています。(SynClip context-engi)生成AIで社内データを使う場面でも、目的に合う段落、列、添付だけを残す方が、古い版や別資料の混入を見つけやすくなります。
- 目的が文章生成なら根拠にする事実と避ける表現を残す
- 目的が社内検索なら検索対象と参照元を残す
- 目的が問い合わせ対応なら回答範囲と人へ戻す条件を残す
- 目的に不要な添付や全文履歴は渡す候補から外す
承認とログを確認する
承認者は、資料を生成AIへ渡してよいかを決める人です。ログは、誰がどの利用環境で何を入力し、どの出力や参照結果が残ったかを後から追う記録です。保持期間は、プロンプト、応答、検索履歴、活動履歴などをどれくらい残すかを運用上決める期間です。
IPAの「AI利用者のためのセキュリティ豆知識」の一覧には「クラウドAIに営業秘密は教えない」「RAG使用時は『混ぜるな危険』にご用心」などの見出しがあります。以下は、それらの見出しだけから詳細な要件を断定したものではなく、編集部が提案する確認の手順です。資料の機密性に加え、利用環境と検索対象に含める範囲を承認者に確認します。一般向けチャットに部署内資料を貼る場合と、法人向け環境で既存権限に沿って使う場合は、利用条件を別々に確認します。
Microsoft 365 Copilotは、Microsoft Graphを通じてユーザーがアクセス権を持つメール、チャット、文書などの組織データを使い、プロンプト、応答、Graph経由のデータは基盤LLMの学習に使われないと説明しています。(Microsoft 365 Copi(公式))一方で、ユーザーのプロンプトと応答を含む対話データは保存され、管理者はContent searchやMicrosoft Purviewで確認や保持ポリシーの設定に使えると説明されています。学習に使われないことと、入力や応答が保存されないことは別なので、現在の契約、設定、利用プラン、保持の扱いを利用前に確かめます。
横にスクロールして比較できます
| 確認項目 | 見る材料 | 決める人 | 次の扱い |
|---|---|---|---|
| 共有範囲 | 公開範囲と閲覧権限 | 業務責任者 | 対象外資料を外す |
| 利用環境 | 契約と設定とプラン | システム管理者 | 使える環境を限定 |
| 必要部分 | 段落と列と添付 | 利用担当者 | 最小範囲へ絞る |
| 承認 | 機密性と個人情報 | 承認者 | 未承認なら止める |
| ログ | 入力と応答と参照元 | 運用担当者 | 追える形で残す |
| 保持期間 | 保存先と保持設定 | 管理者 | 削除時期を決める |
| 更新 | 版と更新日 | 資料管理者 | 古い版を外す |
| 削除 | 削除依頼と権限変更 | 運用担当者 | 対象から外す |
本番化の前に見直す
試験で使えた資料を、そのまま本番の検索対象や入力候補へ広げると、更新担当、権限変更、削除依頼、出力確認の責任が曖昧になります。SynClipの要件定義整理では、AI開発の依頼前に対象業務、利用者、入力、出力、人の確認、失敗時の戻し方をそろえる考え方を示しています。(SynClip ai-developme)社内データを扱う生成AIでも、目的と運用条件を分けておくと、試験で見た便利さと本番で続ける責任を混同しにくくなります。
本番化の前は、資料が更新された時に誰が再確認へ戻すか、退職や担当変更で権限をどう見直すか、不要になった資料を誰が削除依頼するかを確認します。出力確認は、答えが自然かどうかだけでなく、使った資料の版、参照してよい範囲、回答しない条件を分けて見ます。試験の入力を広げる判断は、資料を増やすことではなく、業務で見続けられる確認点を増やすことです。
- 目的を一文で書き利用しない目的を外す
- 元資料の共有範囲と閲覧権限を見る
- 使う利用環境の契約と設定を確認する
- 必要な段落や列だけを選ぶ
- 承認者と権限の確認先を決める
- 入力と応答と参照元のログを残す
- 保持期間と削除依頼の担当を決める
- 更新日と古い版を外す条件を見る
自社の業務で試す
自社の業務でAIを試す方法を検討している方は、インパクトトライアルをご覧ください。最短1ヶ月でスピード検証する進め方と費用を紹介しています。
