著作権と個人情報を確認する生成AI導入の実務ガイド

前田拓郎法律事務所　弁護士　前田拓郎

社内のマニュアルや過去の提案書を生成AIから検索できるようにしたい。顧客との問い合わせ履歴を使い、回答案を自動で作りたい。こうした場面で検討されるのが、RAG（検索拡張生成）です。

ただ、導入の話が具体化すると、「会社が持っている資料なら取り込んでよいのか」「学習に使わないサービスなら顧客情報を送ってよいのか」「回答に出典を付ければ著作権の問題は解決するのか」といった疑問が出てきます。

判断の出発点は、資料を持っていることと、その資料を予定する方法で使えることを分けることです。RAGの法務では、データの出所、処理の目的、外部への送信先、回答を見せる相手を確かめます。そのうえで、権利の確認、契約の調整、システムの設定を組み合わせて、事業に必要な利用の範囲を定めていきます。

本記事では、企業の事業責任者、情報システム担当者、法務担当者、AIサービスの開発・提供事業者に向けて、その検討手順を説明します。本文の事例は検討用の架空事例であり、実際の相談実績や裁判例を示すものではありません。法令・公的資料の説明と、弊所が提案する運用上の工夫は区別して記載しています。

画像生成AIを広告や顧客への納品に使う場合の確認事項は、「画像生成AIを広告や顧客への納品に使うための法務ガイド」もご参照ください。本記事は、主に文章・社内文書を扱うRAGに焦点を当てています。

1．RAGの法務は「どこで、何のために資料を使うか」から考える

1-1．検索した資料を生成AIの回答に利用する仕組み

RAGは、質問に関係する情報を外部の資料群から検索し、その結果を生成AIに渡して回答を作る構成です。例えば、経費精算の質問に対して、社内規程の関連箇所を検索し、それを踏まえて手続を案内します。モデルが事前に持っている知識だけで答える場合に比べ、組織固有の資料を回答の根拠にできる点に特徴があります。[注1]

実装方法は一つではありません。文書を小さなまとまりに分割して検索する方法、文章を数値の並びに変換した「埋め込み」を使う方法、キーワード検索と組み合わせる方法などがあります。法務担当者がすべての技術を設計する必要はありませんが、どの資料が複製され、どこへ送られ、何が保存されるかは理解しておく必要があります。

ここで「学習」という言葉の使い方に注意してください。RAGのために資料を検索可能な状態にすることと、モデルの重みを更新する追加学習は、技術的には別の処理です。ただし、一つのサービスの中に両方が組み込まれていたり、入力や回答が別途サービス改善に使われたりする可能性はあります。「RAGなので学習しません」という説明だけでは、処理全体の確認にはなりません。

1-2．利用の流れを六つに分けて把握する

導入前の打合せでは、次のような表を作ると、確認すべき相手と資料が明確になります。これは典型的な構成をもとにした整理例です。実際には、外部の文書変換サービスや検索サービスが加わることもあります。

処理の段階	実際に行うこと	確認する事項
収集・取り込み	文書を集め、文字を抽出する	入手経路、利用権限、対象外資料
加工・保存	文書を分割し、検索用データを作る	保存先、埋め込み生成先、複製の範囲
検索	質問に関係する資料を選ぶ	利用者ごとの閲覧権限、検索対象
外部送信・生成	質問と検索結果をモデルへ渡す	送信先、利用目的、保存・再利用条件
回答の表示・利用	社員や顧客に回答を示す	表示範囲、原文の利用、確認責任
記録・削除	質問、回答、参照箇所を管理する	ログの閲覧権限、保存期間、削除方法

特に見落としやすいのは、回答を作るモデルとは別の事業者にデータが送られる場面です。文書の文字起こし、画像からの文字抽出、埋め込みの生成、検索順位の調整、障害解析の各処理で、異なるサービスを使うことがあります。契約先が一社でも、その先の再委託先まで含めて確認します。

この表を技術担当者と一緒に埋めると、「検索用データは国内にあるが、質問と抜粋は海外のサービスへ送っている」「原本は消せるが、検証用ログには残る」といった条件が見えてきます。データの流れが分かれば、法律上の評価と契約交渉の対象を絞れます。

1-3．利用場面を先に限定する

同じ社内資料でも、担当者の作業補助に使う場合と、顧客へ直接回答する場合では、確認の重さが変わります。例えば、営業担当者が提案書の候補を探す仕組みと、顧客が過去の取引条件を自由に検索できる仕組みは、公開範囲も誤回答の影響も異なります。

最初の企画書には、「誰が」「どの業務で」「どの資料を参照し」「回答をどう使うか」を書いてください。「社内の知識を活用する」だけでは、必要なデータの範囲を決められません。「商品サポート担当者が、承認済みの製品マニュアルを参照して回答案を作り、人が確認して送信する」とすれば、初期導入の条件を具体化できます。

2．自社が持っている資料でも、自由に使えるとは限らない

2-1．データを五つの種類に分ける

最初からすべてのファイルを一件ずつ精査するのは大変です。まずは出所と用途で分類し、判断が共通する資料群を作ります。次の表は、資料を取り込む前の検討例です。表の対応方針は一律の法的結論ではなく、確認の順序を示しています。

資料の種類	確認する権利・条件	導入時の対応例
自社作成の規程・マニュアル	著作権の帰属、第三者素材、閲覧範囲	管理部署が確認した最新版から開始
顧客から受領した資料	利用目的、秘密保持、再委託、個人情報	案件単位で利用条件と公開範囲を設定
外注先が作成した成果物	著作権の譲渡・許諾範囲、組込素材	発注契約と素材の利用条件を照合
購読記事・有料データベース	契約者、利用人数、機械処理、再提供	契約と提供元の利用許諾を確認
人事・問い合わせ・会議の記録	個人情報、機密性、取得時の説明	必要項目に限定し、権限を分離

どの分類にも当てはまらない資料を、便宜的に「その他」として一括投入しないことが大切です。出所不明のファイル、担当者が個人契約で購入した資料、コピー元が不明な画像などは、確認が終わるまで取り込み対象から外す運用が考えられます。

2-2．「代金を払った」と「著作権を取得した」は別の話

制作会社に費用を払ってマニュアルを作ってもらった場合でも、当然にすべての著作権が自社へ移るわけではありません。契約が利用許諾なのか権利譲渡なのか、どのような利用まで認められているかを確認します。譲渡契約でも、翻案権等の扱いには著作権法第61条第2項の規定があるため、契約の表現が重要です。[注2]

また、社員が作った資料なら必ず会社が著作者になるとも限りません。職務著作の成否は著作権法第15条の要件に沿って検討します。社内資料に掲載した外部の記事、写真、イラスト、他社の図表については、その資料全体の扱いとは別に確認が必要です。[注2]

実務上は、社内の資料名だけで判断せず、「自社が作った部分」「外注先が作った部分」「第三者から借りている部分」を区別します。これにより、資料全体の投入を止めずに、確認できていないページだけを除外する、といった調整がしやすくなります。

2-3．顧客から預かった資料を横断的な知識に変えてよいか

顧客から仕様書を受け取ったのは、その顧客の案件を遂行するためかもしれません。その仕様書を別の顧客への提案や、自社サービス全体の改善に使うと、当初の目的を超える問題が生じます。資料に著作物が含まれなくても、秘密保持や目的外利用禁止の契約は確認しなければなりません。

顧客別のRAGで検索できるようにすることと、全顧客共通の検索基盤に統合することも分けて考えます。後者は、他の顧客に回答が混ざらない設定だけでなく、共通基盤への取り込み自体が認められるかを確認する必要があります。匿名の事例集へ加工する場合にも、取引内容から顧客を推測できる情報が残らないか、契約が加工後の利用を認めているかを確認します。

3．RAGと著作権法第30条の4をどう考えるか

3-1．「AIに使う」という理由だけで適法になるわけではない

著作権法第30条の4は、著作物に表現された思想や感情の享受を目的としない利用について、必要と認められる限度で利用を認める規定です。情報解析はその例として挙げられています。ただし、著作権者の利益を不当に害する場合を除くという条件（同条但書）もあります。[注2]

この規定を検討する際には、「機械が処理するから情報解析である」と説明するだけでは足りません。その処理が、最終的に何を実現するために行われるのかを見る必要があります。例えば、文書の傾向を分析する処理と、特定の書籍の説明文を利用者に読ませるための処理は、同じ文章データを使っていても目的が異なります。

文化庁の「AIと著作権に関する考え方について」は、RAG用のデータベース作成等についても、既存著作物の創作的表現を出力する目的の有無を分けて検討しています。創作的表現の出力を目的とする場合には著作権法第30条の4が適用されないとの整理です。この資料は解釈の参考となりますが、個別事案の結論を確定する裁判所の判断ではありません。[注3]

3-2．「内容を知る」と「表現を利用する」を丁寧に分ける

著作権が保護するのは創作的な表現であり、単なる事実やアイデアそのものではありません。しかし、資料の内容を短くしたから必ず表現の利用ではなくなる、とはいえません。文章の構成や特徴ある説明が残る要約では、複製・翻案等の問題が生じ得ます。[注2]

例えば、製品番号と発売日の対応を検索して答える場合と、有料の解説書の章立てに沿って詳しい説明を再構成する場合では、参照する情報の性質も、回答に現れる表現も異なります。実際の評価には、取り込む資料と、利用者に出す回答の双方を確認することが必要です。

そのため、導入時にはシステムの構成図だけでなく、想定する質問と回答のサンプルを用意すると検討が進みます。「原文を何文字まで出すか」だけでなく、どの資料を、どの目的で、どの程度代替する回答を作るのかを説明できるようにすることが重要です。法的な検討に必要なのは、サービスの名前より、利用実態を検討する必要があります。

3-3．権利制限規定に依拠する場合は、前提を運用に残す

許諾が不要と判断する場合でも、その判断がどの条件に基づいているかを記録します。例えば、対象資料の範囲、出力の形式、原文の表示方法、利用者の範囲、想定している法的根拠です。「法務確認済み」という一行だけでは、後から機能が変わったときに、再確認が必要か分かりません。

当初は文書の所在を案内するだけだったシステムに、詳細な要約や長文の再現機能を追加することがあります。こうした変更によって、最初の判断の前提が変わり得ます。機能追加の審査では、新しい回答例を確認し、法務上の条件と技術上の制限が一致しているかを見直してください。

4．検索結果の表示、要約、引用には別の確認が必要

4-1．著作権法第47条の5の「軽微利用」は、一律の文字数基準ではない

著作権法第47条の5は、一定の検索や情報解析等に付随する著作物の軽微な利用を認めています。RAGの回答や、その準備のための利用について、この規定が検討対象になる場合があります。ただし、対象は、公衆への提供・提示等が行われた著作物で、公表または送信可能化されたものに限られます。未公表の顧客資料等にも当然に適用できるわけではありません。対象行為、必要な限度、軽微性、権利者の利益を不当に害しないことなどの要件に加え、政令で定める基準も確認する必要があります。[注2][注3]

「軽微」といえるかは、利用部分の割合や量、表示の精度などを踏まえる問題です。「何文字以下なら必ず適法」という共通の安全基準として扱うことはできません。短い著作物の大部分を表示する場合と、長い資料の所在を示すために一部を表示する場合を、文字数だけで同じように判断するのは適切ではありません。

また、質問を繰り返せば資料全体を順番に取り出せる設計では、一回ごとの回答が短くても、サービス全体としてどのような利用を可能にしているかが問題になります。実務上は、回答単位の制限に加え、連続質問による大量抽出、原文再現の指示、同じ資料への繰り返しアクセスも検証対象にするとよいでしょう。

4-2．出典リンクを付けるだけでは「引用」にならない

著作権法第32条第1項による引用には、公表された著作物であること、公正な慣行に合致すること、引用の目的上正当な範囲内であることが求められます。出所の明示も関係しますが、出典さえ書けばどのような転載でも許されるという制度ではありません。[注2][注4]

RAGの回答では、元資料の文章と生成AIが作った説明が、同じ文章の中に混ざることがあります。引用として表示するなら、引用部分と説明部分の区別、引用の必要性、分量、原典との関係を確認しやすい画面にすることが考えられます。AIが示したリンクが、実際にその回答を裏付ける箇所につながるかも確認します。

未公表の社内資料や顧客資料については、公表された著作物の引用という説明をそのまま使えません。自社に利用権限があるのか、許諾や別の根拠で利用できるのかを検討します。出典を表示することは、権利処理の代わりではなく、回答の根拠を確かめるためにも必要な機能として位置付けると整理しやすくなります。

4-3．購読サービスの契約も別に読む

新聞、専門誌、業界データベースなどには、利用者の範囲、機械的な取得、再配布、AIへの利用等に関する条件が定められている場合があります。担当者が画面を読めることと、会社のRAGに取り込み、他の社員へ回答を提供できることは同じではありません。

著作権法上の検討と、契約上の義務の検討は分けて行います。契約が誰との間で成立しているか、どの規約が組み込まれているか、対象行為をどこまで制限しているかを確認してください。規約に関係しそうな文言があるだけで直ちに結論を出すのではなく、具体的な取得・保存・表示の方法と対応させます。

許諾交渉をする場合は、「AIに使いたい」とだけ伝えるより、対象となる資料、利用人数、社内限定か顧客向けか、原文の表示範囲、保存期間を提示する方が話を進めやすくなります。全文を回答する必要がなければ、資料の所在と短い説明を示し、本文は契約済みの閲覧画面で読む構成も検討できます。ただし、その構成でも取得や加工の段階の確認は必要です。

5．顧客データを使う前に、利用目的を確認する

5-1．会社の情報の中にも個人情報は含まれる

法人名や法人の売上など、法人それ自体に関する情報は、それだけで個人情報になるわけではありません。一方、担当者の氏名やメールアドレス、個人事業主に関する情報、特定の個人に結び付く問い合わせ履歴などは、個人情報に該当し得ます。文書の表題が「企業向け案件」であっても、本文や添付資料まで確認する必要があります。[注5]

個人情報保護法上の「個人情報」と「個人データ」も区別してください。個人データは、個人情報データベース等を構成する個人情報をいいます。利用目的に関する規律と、第三者提供や安全管理に関する規律では、対象となる情報の整理が関係します。本記事でも、各規律の対象に合わせて言葉を使い分けています。[注5][注6]

RAGでは、従来は各部署のフォルダに分散していた記録を、一度に検索できるようにします。この結果、個人に関する情報を結び付けやすくなることがあります。氏名の列だけを点検するのではなく、自由記述欄、会議録、署名欄、添付画像に含まれる情報まで、対象資料の特徴に応じて確認します。

5-2．AIの導入そのものと、利用目的の変更を混同しない

個人情報保護法第17条・第18条では、利用目的の特定や、その達成に必要な範囲を超える取扱いの制限等が定められています。生成AIを使う場合も、まず、取得時に特定した利用目的との関係を確認します。[注5]

例えば、顧客対応のために取得した問い合わせ内容を、担当者が回答案を作るために使う場合と、顧客の関心を分析して別商品の営業に使う場合では、目的との関係が異なります。前者でも、利用する情報の範囲や外部提供の有無は検討が必要です。後者では、当初の利用目的の範囲内か、合理的な関連性のある変更に当たるか、同意等の対応が必要かを確認します。

AIを導入しただけで常に新たな同意が必要になるわけでも、プライバシーポリシーへ「AIを利用する」と追記すれば何でも可能になるわけでもありません。事業上何を行うかを先に特定し、その目的と取扱いを説明できることが重要です。本人の同意が必要な場面では、公表文を変更することだけで同意を代替することはできません。

5-3．最初からすべての顧客情報を渡さない

実務上は、RAGが答えるために必要な情報を先に絞ると、法務と開発の両面で検討しやすくなります。製品の不具合への対処を調べるだけなら、問い合わせをした人の住所や電話番号まで検索用データへ入れる必要があるでしょうか。一般的な回答例を探すのであれば、個別の顧客を識別する情報を切り離した資料で足りる場合があります。

一方、特定の顧客の契約内容を確認する業務では、顧客との対応付けが必要です。その場合は、顧客情報を全面的に削除するのではなく、案件担当者に検索権限を限定する、必要な項目だけを取得する、モデルへ送る情報を制御する、といった設計を検討します。業務に必要な情報を説明できる形で残すことが大切です。

なお、病歴等の要配慮個人情報が含まれる場合には、取得に関する特別の規律等も確認します。顧客が自由記述欄に書いた内容を、通常の製品情報と同じ扱いで取り込まないようにしてください。個人番号など別の法律による規律がある情報も、一般的なRAGの導入判断にまとめず、対象から分離して確認する必要があります。[注5][注6]

6．「学習に使わない」だけでは、外部送信の確認は終わらない

6-1．回答生成、保存、改善利用を分けて確認する

生成AIサービスへのデータ送信では、利用規約、個別契約、データ処理に関する条件、管理画面の設定を照合します。少なくとも、回答生成のための処理、障害や不正利用の調査、ログ保存、サービス改善、モデルの学習を分けて確認してください。

「学習に利用しない」という条件は、そのうち一部の処理を制限するものです。入力が一切保存されないこと、担当者が一切閲覧しないこと、他の事業者へ一切送られないことまで、当然に意味するわけではありません。保存が認められている場合には、目的、期間、アクセスできる者、削除の方法を確認します。

個人情報保護委員会は、生成AIへの個人情報の入力について利用目的との関係を確認すること、個人データを本人同意なく入力し、提供事業者が回答生成以外の目的で扱う場合には、法違反となる可能性があることを注意喚起しています。入力した情報が機械学習に利用されないこと等の確認も挙げています。[注7]

この注意喚起を踏まえても、「学習がない」という一点から、目的外利用や第三者提供、安全管理の検討がすべて不要になるという結論は導けません。実際の処理と契約を照合して、適用される規律を判断します。

6-2．外部サービスの利用が「委託」に当たるか

個人データの取扱いを、利用目的の達成に必要な範囲で委託することに伴う提供は、個人情報保護法第27条第5項第1号により、同条の第三者提供の規律との関係では第三者への提供に当たらないとされています。他方で、委託先に対する必要かつ適切な監督が求められます。[注5]

RAGの開発や運用を依頼する場合も、受託者が依頼された処理の範囲でデータを扱うのかを確認します。受託者が独自の目的で顧客データを利用する条件になっていれば、単に契約書の表題を「業務委託契約」としただけで、すべてを委託として整理できるわけではありません。

例えば、問い合わせ回答の作成を委託する条項とは別に、「受領した情報を他社向けサービスの開発に自由に利用できる」という条項がある場合には、その利用を個別に検討する必要があります。入力、回答、評価結果、利用ログのそれぞれについて、誰の目的で何に使うのかを整理します。

再委託先の選定・変更、事故時の連絡、取扱状況の確認も実務上の確認事項です。契約で監督の権利を定めても、連絡先や報告方法が決まっていなければ、必要な確認ができません。書面上の条件を実際の運用につなげる準備が必要です。

6-3．クラウドの「取り扱わない」整理を自動で当てはめない

個人情報保護委員会のQ&Aでは、クラウド事業者が保存された個人データを取り扱わないこととなっている場合、個人データの提供には当たらないと整理されています。契約上の取扱い禁止と適切なアクセス制御等が、その判断の例として示されています。[注8]

ただし、生成AIサービスだから、暗号化されているから、担当者が通常は見ないから、という事情だけでこの整理を当てはめることはできません。質問内容を処理して回答するサービス、内容を解析する機能、サポートのために内容へアクセスする機能など、対象となる機能ごとに契約と実態を確認します。

保存部分については「取り扱わない」と整理できても、別サービスへの送信や生成処理については検討が残ることもあります。一つのクラウド環境の中にあるという理由で、すべての処理を同じ評価にまとめないようにするなどの工夫が求められます。

7．国内サーバを選んだ場合も、海外との関係を確認する

7-1．サーバの場所と、情報を扱う者を分ける

サービスの「国内リージョン」は重要な選択条件ですが、それだけで外国にある第三者への提供に関する検討が終わるわけではありません。契約主体、情報を扱う事業者、サーバの所在地、保守担当者のアクセス元、再委託先を確認します。

個人情報保護委員会のQ&Aでは、外国事業者が個人データを取り扱う場合、国内サーバであっても外国にある第三者への提供に該当し得るとされています。一方、その事業者が日本国内で取り扱い、国内で個人情報データベース等を事業に用いていると認められる場合等の例外も説明されています。外国企業の名前があるだけで一律に結論を出さず、具体的な取扱いを確認する必要があります。[注9]

導入担当者は、提供会社へ「データは国内ですか」とだけ聞くより、「原文、質問、回答、ログはそれぞれどこに保存され、どの法人がどの国から取り扱いますか」と聞く方が、必要な回答を得やすくなります。埋め込みや検索順位の調整に使う外部サービスも対象にしてください。

7-2．委託なら外国への提供も自由、とはならない

外国にある第三者への個人データの提供については、個人情報保護法第28条の確認が必要です。国内の委託と同じ説明だけで済ませず、同条の本人同意による方法、法令上の対象国・基準に適合する体制等の取扱いを、実際の提供先に沿って検討します。[注5][注10]

本人同意を根拠とする場合には、同意取得時に提供すべき情報があります。相当措置を継続して講ずる体制に依拠する場合には、その実施を確保するための措置等も問題になります。契約を一度締結したら確認を終えてよいというものではありません。なお、外国提供の要件を満たしても、利用目的や委託先監督など、別の規律が当然に免除されるわけではありません。

また、クラウド事業者が個人データを取り扱わず、第三者への提供に該当しない場合でも、安全管理措置として外国の制度等を把握する必要がある場面があります。個人情報保護委員会は、国内サーバに保存される場合にも関係することを説明しています。[注11]

実務では、これらを「海外利用の同意」という一項目にまとめず、提供の有無、提供先の評価、選択する法的根拠、継続確認の方法を分けて記録していくことが重要です。区分けして記録することにより、利用するサービスや再委託先が変わった際に、どの部分を見直せばよいかが分かります。

8．名前を消した情報、埋め込み、ログも確認対象になる

8-1．伏せ字にしただけで匿名加工情報になるわけではない

氏名を削除しても、部署、役職、取引日、案件名などを組み合わせると、特定の人が分かることがあります。自社が持つ他の情報と容易に照合して識別できる場合も含めて、個人情報に該当するかを検討します。[注5]

個人情報保護法上の仮名加工情報・匿名加工情報には、それぞれ定義と加工基準、取扱いの規律があります。現場でいう「匿名化」は、単なる氏名のマスキングを指していることもあるため、その呼び方だけで法的な扱いを決めないようにしてください。特に、仮名加工情報は、第三者提供等に固有の制限があり、外部サービスへ自由に渡すための一般的な手段ではありません。[注18]

検証用データが必要であれば、架空の人物や案件で作ったデータを使う方法もあります。ただし、実際の顧客の履歴を加工して作った場合には、元の情報が残っていないかを確認します。「テスト用」というラベルは、情報の性質や契約上の条件を変えるものではありません。

8-2．数値に変換した情報も、自動的に規律の外にはならない

埋め込みは、文章の特徴を数値として扱う技術です。数値の並びになっているからといって、当然に個人情報でも秘密情報でもなくなるとはいえません。元の情報との対応関係、付随する識別子、他の情報との照合可能性、取り扱う主体等を踏まえて判断します。[注5]

実務では、埋め込みだけを単独で保存しているとは限りません。検索結果として原文を取り出せるように、元の文章、ファイル名、顧客ID、アクセス権限などを一緒に保存することがあります。契約のデータ定義を「アップロードしたファイル」に限定すると、加工後のデータが保存・削除条項の対象から漏れるおそれがあります。

そのため、原文、抜粋、埋め込み、付随情報、回答、ログを、契約と管理台帳の中で区別して列挙することを勧めます。すべてを同じ期間保存する必要はありませんが、何がどの条件で残るのかを説明できる状態にします。

8-3．ログは調査のために役立つ一方、新しい情報の集積にもなる

質問の履歴には、原資料にはなかった秘密情報が入力されることがあります。例えば、社員が「まだ公表していない買収計画と、この契約条件は両立するか」と尋ねれば、その質問自体に重要情報が含まれます。回答ログだけでなく、質問、検索された文書、エラーの記録も確認対象です。

事故調査や品質改善のために記録を残すことには意味があります。しかし、全内容を無期限に保存する設定が当然に適切とは限りません。必要な記録の項目、保存期間、閲覧できる担当者、顧客や本人への説明との整合を確認します。詳細な内容を保存せず、処理の識別子や結果だけで目的を達成できるかも検討してください。

9．秘密保持契約と、検索できる範囲を一致させる

9-1．秘密情報と営業秘密は同じ範囲とは限らない

不正競争防止法上の営業秘密には、秘密管理性、有用性、非公知性という要件があります。他方、秘密保持契約で保護する情報の範囲は、契約の定義によって決まります。営業秘密に該当するかだけで、顧客から受け取った情報を使ってよいかを判断することはできません。[注12]

RAGの導入では、顧客との契約にある利用目的、開示できる者の範囲、再委託、複製、返却・消去、事故報告の条項を確認します。「業務上必要な者に限り開示する」という条件があれば、全社員が検索できる仕組みとの整合が問題になります。クラウド利用が認められていても、別目的のデータ利用まで認められているとは限りません。

外部サービスを使うことで直ちに営業秘密性を失うと決まるわけではありませんが、誰がどの条件で情報に接触できるかは重要です。利用権限、秘密表示、委託先の取扱条件を一緒に見直し、管理の実態を説明できるようにしておきます。

9-2．原本の閲覧権限を、検索と回答にも引き継ぐ

元の共有フォルダでは、人事担当者だけが評価資料を読める設定になっていた場合において、その資料を共通のRAGへ取り込み、全社員が検索できるようにすれば、元の権限管理が実質的に失われます（秘密管理性の喪失）。利用者が原本を開けない場合でも、AIの回答から内容を知ることができれば、問題は残ります。

実装上は、利用者の権限に応じて検索対象を制限する方法があります。Microsoftの技術資料でも、文書単位のアクセス制御として、検索時のフィルター等が説明されています。ただし、利用する製品の対応機能、設定、バージョン等は個別に確認する必要があります。[注13]

弊所が導入時に確認を推奨するポイントは、元の権限情報が取り込まれるか、異動や退職が検索側に反映されるか、顧客別の区分を利用者が変更できないかという点です。回答の画面だけで隠すのではなく、権限のない情報が検索・生成の処理へ渡る前に制御できるかを、開発担当者と確認します。

また、過去の会話履歴や共有リンク、回答を一時保存するキャッシュにも注意してください。資料の閲覧権限を変更しても、過去に生成した回答から情報が見えることがあります。権限変更がどこまで反映されるか、既に作成された回答をどう扱うかを決めておく必要があります。

9-3．AIへの指示文だけを情報管理の根拠にしない

「秘密情報を出さないこと」と生成AIに指示しておくことには意味がありますが、それだけでアクセス制御を置き換えることはできません。検索対象の分離、利用者認証、権限の確認、出力の検査など、実際の仕組みと組み合わせます。

検索される文書に、回答の指示を変えさせる文章が含まれている場合もあります。OWASPは、外部文書等に含まれる指示によってモデルの動作が影響を受ける間接的なプロンプトインジェクションを説明し、RAGを使うことだけではこの問題を解消できないとしています。[注14]

これは「RAGを使うべきでない」という話ではありません。参照資料は回答のための情報として扱い、資料中の指示に従って送信先や権限を変えない構成にすることが重要です。メール送信や社内システムの更新まで行う場合には、検索して答える段階とは分けて、実行権限と承認手続を設定します。

10．導入契約で決めたい八つの事項

10-1．契約の対象と、各当事者が担当する作業

「RAGを構築する」という表現だけでは、完成すべきものが明確になりません。接続する文書管理システム、対象資料の形式、利用者数、検索の範囲、回答画面、権限管理、運用支援まで、担当する作業を分けて定めます。

特に、資料の整理と権利確認を誰が行うかを決めてください。発注者が資料を渡すだけでよいと思い、受注者は利用可能性の確認が済んでいると思っていると、後で作業が止まります。どちらかにすべての責任を抽象的に負わせるより、資料の提供、条件の説明、除外設定、確認結果の記録をそれぞれ割り当てる方が実行しやすくなります。

10-2．利用できるデータと、利用できる目的

契約では、入力資料、質問、回答、ログ、加工したデータを区別し、それぞれの利用目的を定めます。「サービス提供のために利用する」という条件だけで、他社向けの改善やモデルの追加学習まで含まれるのかが曖昧であれば、範囲を明確にします。

また、開発者が自社の技術や一般的なノウハウを再利用することと、顧客の資料・秘密情報を再利用することを分けると交渉しやすくなります。一般的なプログラム部品を再利用することは認めつつ、顧客の原文や顧客別の検索データの転用を制限するなど、対象を特定して調整します。

経済産業省も、AIの利用・開発に関する契約チェックリストを公表し、提供するデータの利用範囲や、サービス水準・生成物の利用条件等の検討を促しています。以下の契約項目は、同チェックリストの条項を転載したものではなく、RAGの運用に合わせた弊所の整理です。[注16]

10-3．成果物、利用権限、引継ぎに必要な情報

納品物には、ソースコードだけでなく、検索の設定、文書加工の手順、プロンプト、評価用の質問、運用手順書などが含まれ得ます。何が引き渡され、何を利用・修正できるかを具体的に定めます。データや設定のすべてについて当然に著作権が生じるわけではないため、権利帰属条項だけでなく、契約上の利用権限と引渡義務も確認します。

契約が終了した後に、別の事業者へ保守を依頼できるかも重要です。検索データを持ち出せるか、元資料との対応が残るか、権限情報を再現できるかを確認します。データを書き出せても、説明や設定がなく、実際には再利用できない状態を避けるためです。

10-4．検収と品質評価の方法

「高精度の回答ができること」だけでは、検収の判断基準が曖昧です。代表的な質問と望ましい回答、参照すべき文書、回答してはいけない情報、担当者へ引き継ぐ場面を用意して、どの状態を確認するかを合意します。

評価は正しい回答ができるかだけでは足りません。資料がない場合に断定を避けられるか、古い規程を参照しないか、権限のない資料を出さないかも確認します。評価用の質問と開発中に繰り返し調整した質問が同じものばかりになると、実際の利用場面を十分に確かめられないことにも注意が必要です。

検収の基準と、本番運用後に維持する水準は分けておくと整理しやすくなります。資料の追加やモデル変更によって回答が変わるため、運用中の再評価、対応する不具合、追加改修となる変更の区分も定めます。

10-5．誤回答や権利侵害が起きた場合の対応と責任

責任分担は、原因となる事実に沿って検討します。発注者が利用条件を説明せず資料を提供した場合、受注者が合意した権限設定を実装しなかった場合、外部サービスの条件変更を放置した場合では、問題の所在が異なります。

「AIの回答には責任を負わない」という免責条項がある場合は、その範囲を確認します。回答内容の不確実性に関する説明と、合意したセキュリティ機能を実装する義務、秘密保持義務、障害に対応する義務を混同しないことが大切です。損害賠償の上限、対象となる損害、例外、第三者からの請求への対応も、取引の実態に合わせて検討します。

契約で当事者間の負担を定めても、権利者や本人に対する責任がそのまま消えるわけではありません。問題が起きた際に、誰が事実調査をし、どのログを提供し、誰が対外説明を行うかまで決めておくと、初動が取りやすくなります。

10-6．再委託先・モデル・規約の変更

RAGの提供会社が利用する外部モデルやクラウドを変更すると、送信先、保存条件、回答の特性が変わることがあります。変更の通知、必要な説明、発注者が承認または異議を述べる方法、利用停止や解約の条件を定めます。

すべての軽微な変更に事前承認を要求すると運用が回らない場合があります。そこで、個人データの取扱国、学習への利用、秘密情報へのアクセス、料金や重要な機能に影響する変更など、再確認が必要な事項を特定する方法が考えられます。通知が届く窓口も、退職や異動で見られなくならないようにします。

10-7．保存、削除、バックアップ、契約終了時の対応

削除の条項では、原本だけでなく、分割文書、検索用データ、質問、回答、ログ、キャッシュ、バックアップを対象ごとに確認します。即時に消せるものと、所定の保存サイクルで消えるものを区別し、その間の利用制限と削除期限を明らかにしておくことが重要です。

「削除できます」という説明についても、画面から見えなくなるだけなのか、検索から除外されるのか、保存先から消去されるのかを確認します。誤投入が判明した際には、通常の契約終了時とは別に、検索と外部送信を速やかに停止できる必要があります。

もし追加学習にも利用する設計なら、データの削除と学習済みモデルからの影響除去が同じことではない点も踏まえます。実現できない削除を契約で約束するのではなく、利用開始前に、学習への使用の可否と終了時に実施できる措置を確認します。

10-8．利用者へ説明する内容と、実際の条件

顧客向けにサービスを提供する場合は、利用規約、プライバシーポリシー、営業資料、画面表示が整合しているかを確認します。外部ベンダーとの契約では一定期間のログ保存を認めているのに、顧客には「情報は一切残りません」と案内していないでしょうか。

「社内限定」「顧客別に完全分離」「学習に使わない」といった表現も、何を指すかを明確にします。営業担当者が説明しやすいように、使用できる表現と補足条件を整理しておくことが有効です。契約レビューは、提供する機能や販売時の説明と一緒に行うことで、実務に結び付きます。

11．誤回答を前提に、使う場面と確認方法を決める

11-1．出典が付いていても回答の正しさは別に確かめる

RAGが参照先を示していても、その資料が最新版とは限りません。また、資料の一部を読み落としたり、例外条件を省いたり、複数の資料を不適切につなげたりする場合を想定しておく必要があります。

例えば、「この契約はいつでも解除できるか」という質問に対し、一般条項だけを拾って答えると、別紙にある予告期間や個別契約の特約を見落とす可能性があります。これは出典リンクの有無だけでは解決しません。どの文書が優先されるか、関連する別紙も検索できるか、人が原文を確認できるかを検証します。

そのため、契約上の義務、支払条件、人事評価、個人に重大な影響を与える判断等では、回答を確認する担当者と確認の対象を明確にします。「必ず人が確認する」と書くだけでなく、確認に必要な原文や版情報が画面からたどれることが重要です。

11-2．回答しない条件も業務の仕様にする

根拠となる資料がない場合、資料同士が矛盾する場合、利用者に閲覧権限がない場合などには、無理に回答を作らず、担当部署へ案内する方法が考えられます。こうした条件は、使い勝手を損なう制限として後付けするより、業務の仕様として最初に決めておく方が運用しやすくなります。

顧客対応であれば、一般的な製品仕様の案内は自動回答にし、返金の約束や契約変更は担当者が対応する、といった切り分けができます。契約上の免責だけに依存せず、回答できる範囲を業務上の権限と一致させることが大切です。

RAGが回答を提案することと、会社として承諾や約束をすることを、画面と運用の双方で区別してください。社内向けの下書きを、そのまま顧客向けの自動回答へ変更する場合は、新たな利用場面として再確認します。

12．小さく導入し、本番利用へ進める手順

12-1．最初の対象は「確認しやすく、役に立つ資料」に絞る

実務上の提案として、初期導入では、権利関係と閲覧範囲が把握できる資料から始める方法を勧めます。例えば、承認済みの自社製品マニュアルや、社内手続の案内です。試しに全社のファイルをまとめて接続する方法は、何が検索され、どの権限が必要かを把握しにくくします。

小さく始める場合も、業務上の意味がある対象を選びます。使われない資料だけで実証しても、本番で必要な検索や回答の課題は見えません。現場担当者が繰り返し受ける質問を集め、その回答に必要な資料を選ぶと、検証の範囲を決めやすくなります。

12-2．法務・開発・現場が同じ確認表を使う

次の確認表は、本番利用へ進むかを決めるための例です。すべてが独立した法的義務という意味ではありません。法令上の義務を満たすための措置と、業務上望ましい措置を、案件に合わせて具体化するために使います。

確認項目	残しておく資料・結果	主な確認担当
対象データ	資料一覧、権利・秘密保持条件、対象外の範囲	業務担当・法務
データの流れ	処理ごとの送信先、保存先、再委託先	開発・情報システム
個人情報	利用目的、外部提供の整理、必要な対応	法務・管理担当
権限管理	部署・顧客・役割別の検索テスト	開発・業務担当
回答の品質	正答例、誤答例、回答を控える条件	業務担当・開発
契約条件	利用範囲、責任、変更、削除の合意	法務・事業責任者
事故対応	停止手順、連絡先、ログ確保の方法	情報システム・法務
運用継続	更新、権限変更、定期確認の担当	業務担当・管理担当

誰も担当していない項目があれば、システムの完成前に割り当てます。法務担当者だけで検索権限の実装を確認することは難しく、開発担当者だけで顧客との利用条件を判断することも難しいためです。

12-3．公開範囲を広げるときは改めて判断する

限定した社員で試した結果が良好でも、そのまま全社や顧客へ展開してよいとは限りません。資料の追加、部署の拡大、グループ会社での共用、顧客への公開、外部送信先の変更は、確認のきっかけになります。

実証時の合意が本番のデータ利用まで含むのか、実証用に一時的に認めたアクセスが残っていないかも確認します。特に、運用開始後に顧客から新たな資料を受け取る場合は、受領時に分類・確認する手順が必要です。最初の資料だけを確認しても、継続的な運用の条件にはなりません。

13．二つの導入例で考える、確認の順序

13-1．制作会社が過去の提案書を検索したい場合

ここでは架空の事例を用いてRAGの導入について検討したいと思います。

ケース1

制作会社A社は、提案作成の時間を短くするため、過去の企画書と提案書をRAGで検索する計画を立てました。資料には、自社が作った文章のほか、顧客の未公開の商品情報、外部の写真、購入した調査資料が含まれています。

この場合、「A社の提案書だから利用できる」とまとめると、複数の確認が抜けます。まず、自社が利用条件を把握している内容と、顧客や第三者の条件が付いた内容を分けます。案件の遂行に限って受領した資料を、別案件の企画に使うことが認められるかも確認します。

初期導入の選択肢としては、利用条件を確認できた自社の説明資料や、一般化した制作手順を対象にします。顧客固有の価格、未公表の製品情報、外部素材を含むページは、必要な確認が終わるまで検索対象から外します。顧客別に利用する必要がある資料は、その顧客の案件担当者だけが検索できるように区分します。

回答の使い方も決めます。過去の提案書の文章や画像をそのまま新しい提案へ転用するのではなく、担当者が参照先を確認し、今回の案件に使用できる部分を判断する運用が考えられます。別の顧客名が回答へ混ざらないか、連続して質問した場合にも区分が維持されるかを検証します。

このように、資料の利用条件に合わせて検索範囲と回答の使い方を決めれば、権利が不明な資料をすべて確認し終えるまで導入を止める必要があるかも、具体的に検討できます。優先して使いたい資料から確認することで、事業上の効果と確認作業の順序を合わせられます。

13-2．AI事業者が顧客別の問い合わせ支援サービスを提供する場合

ケース2

AI事業者B社は、複数の企業から問い合わせ履歴を受け取り、各企業のサポート担当者へ回答案を出すサービスを開発しています。顧客ごとの資料は分ける予定ですが、B社はサービス改善のために質問と回答のログを集めたいと考えています。

このケースでは、まず、顧客の業務を支援する処理と、B社独自の改善利用を分けます。顧客との契約で、問い合わせ履歴の取扱い、秘密情報の利用、改善の対象となるデータ、保存期間を確認します。個人データが含まれる場合は、顧客側の利用目的と提供の根拠、B社側の取扱いをそれぞれ検討します。

次に、顧客の識別を利用者の自由入力だけに任せず、認証されたアカウントと権限に基づいて検索範囲を決める設計を確認します。ログの分析画面から別顧客の情報が見えないか、サポート担当者が原文へアクセスする場合の手続があるかも対象です。

運用上は、製品ごとに共通する質問の分類件数だけで改善できるのか、個別の文章まで必要なのかを検討します。個別内容が必要なら、その目的とアクセス範囲を特定します。集計や加工をしたから自由に使えると決めず、契約と個人情報の評価を確認してください。

B社が顧客へ「データを学習に利用しない」と説明するなら、外部モデルの条件だけでなく、自社のログ分析や再委託先の処理も、その説明と整合している必要があります。技術仕様、契約、顧客向けの説明を同じ前提にそろえることが、このサービスを継続して提供するための基礎になります。

14．誤投入や漏えいの疑いが出たときに備える

14-1．検索と送信を止め、調査に必要な記録を確保する

権限のない顧客情報が回答に出た、禁止していた資料を取り込んだ、といった事態に備えて、停止する範囲と判断者を決めておきます。対象文書を検索から外す、外部APIへの送信を停止する、利用者の権限を一時的に制限するなど、構成に応じた手順が必要です。

同時に、原因や影響を調べるための記録を、アクセスを限定した状態で確保します。原文、質問、回答、参照文書、送信先、時刻、設定変更の履歴などを整理します。調査に必要な記録まで一括削除することと、問題のある情報を利用可能なまま残すことは、いずれも避ける必要があります。

14-2．「何人に見られたか分からない」で判断を止めない

個人データの漏えい等では、個人情報保護法第26条や個人情報保護委員会規則に基づく報告・本人通知の要否を検討します。報告対象は件数だけで決まるものではなく、要配慮個人情報、財産的被害のおそれ、不正な目的による行為等、事態の性質も関係します。報告対象となるおそれがある段階も含めて判断が必要です。[注5][注15]

また、個人情報に該当しなくても、顧客との秘密保持契約等に基づく連絡が必要なことがあります。法令上の報告、契約上の通知、利用者への説明を分けて整理します。判明した事実と未確認の事項を区別し、事実がそろうまで一切連絡しないという運用にならないようにしてください。

再開の際は、誤って取り込んだ資料を削除しただけで十分かを確認します。検索用データ、キャッシュ、過去の回答や共有リンクに情報が残っていないか、同じ設定で別の顧客にも影響しないかを確認し、必要な範囲で再テストします。

15．導入前によくある疑問

Q.社内だけで使うなら、著作権は問題になりませんか

社内限定であることだけで、著作権法上の確認が不要になるわけではありません。企業の業務利用は、通常、個人的・家庭内等の私的使用のための複製とは区別されます。許諾の範囲や適用できる権利制限規定を、実際の利用方法に沿って確認します。[注2]

Q.顧客から「AI利用可」と書いてもらえば十分ですか

その合意が、どの情報、どの処理、どの提供先を対象とするかを確認します。顧客が第三者の著作物や従業員等の情報を含む資料を提供する場合、顧客の一言だけですべての権利や個人情報の問題が解決するとは限りません。合意の内容と、顧客が認められる範囲を確認する必要があります。

Q.自社サーバで運用すれば確認は不要ですか

外部への送信を減らすことは検討上の重要な要素です。ただし、資料の利用権限、個人情報の利用目的、社内の閲覧権限、回答の使い方は残ります。また、自社サーバの構成でも外部APIや遠隔保守を利用していないかを確認してください。

Q.2026年の個人情報保護法改正で扱いは変わりますか

改正法は2026年7月17日に公布され、一部を除き、公布日から2年以内の政令で定める日に施行されるとされています。公布されたことと、新しい規律を直ちに利用できることは同じではありません。本記事は2026年10月3日時点の施行済みの規律を前提とし、未施行の改正による例外を利用可能なものとして扱っていません。公開時と実際の導入時には、施行日、政令・規則、ガイドラインの整備状況を改めて確認してください。[注17]

16．RAGを事業で使うために、最初に用意したい三つの資料

RAGの法務確認では、利用するサービス名だけから結論を出すことは難しく、具体的なデータと処理の説明が重要です。最初の相談には、次の三つがあると検討を進めやすくなります。

1. 利用場面の説明：誰が、どの業務で使い、回答を誰へ見せるのか。

2. 対象資料の一覧：出所、含まれる情報、利用条件が分かる資料と代表的なサンプル。

3. 構成と契約の資料：送信先・保存先が分かる構成図、利用規約、個別契約、委託先の説明。

すべてが確定してから相談する必要はありません。まだ決まっていない部分が分かれば、導入前に確認する事項、契約で調整する事項、運用で対応する事項を整理できます。技術担当者と法務担当者が同じ資料を見ながら、実現したい業務に必要な条件を具体化することが大切です。

前田拓郎法律事務所では、生成AI・RAGの開発や導入に関するデータ利用、著作権、個人情報、秘密保持、利用規約・取引契約の検討を支援しています。社内資料をどこまで使えるか、顧客のデータをどの条件で受け取れるか、既存の契約で足りるかなど、具体的な企画や運用に沿ってご相談いただけます。

画像生成AIによる制作・納品も行う企業の方は、生成AIの商用利用・納品に関する法務ガイドと併せて、入力する情報と出力の利用条件をご確認ください。

※注釈と参考資料

本文の注番号に対応する資料です。長文の直接引用は行わず、法令・資料の内容を要約または参照しています。確認日はすべて2026年10月3日です。公的な解釈資料、企業の技術資料、本文独自の実務提案を区別しています。

注1　Retrieval-augmented generation (RAG) in Azure AI Search

発行主体：Microsoft Learn

公表日・版：2026年8月4日更新

参照箇所：Classic RAG pattern for Azure AI Search／Content preparation for RAG

原資料URL：https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview

注2　著作権法（昭和45年法律第48号）

原資料URL：https://laws.e-gov.go.jp/law/345AC0000000048

注3　AIと著作権に関する考え方について

発行主体：文化庁文化審議会著作権分科会法制度小委員会

公表日・版：2024年3月15日

原資料URL：https://www.bunka.go.jp/seisaku/bunkashingikai/chosakuken/pdf/94037901_01.pdf

注4　著作権テキスト 令和8年度版

発行主体：文化庁 著作権課

公表日・版：2026年度版

原資料URL：https://www.bunka.go.jp/seisaku/chosakuken/seidokaisetsu/pdf/94383901_01.pdf

注5　個人情報の保護に関する法律（平成15年法律第57号）

原資料URL：https://laws.e-gov.go.jp/law/415AC0000000057

注6　個人情報の保護に関する法律についてのガイドライン（通則編）

発行主体：個人情報保護委員会

公表日・版：2016年11月策定／2026年6月一部改正

原資料URL：https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/

注7　生成AIサービスの利用に関する注意喚起等

発行主体：個人情報保護委員会

公表日・版：2023年6月2日

原資料URL1：https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/

原資料URL2：https://www.ppc.go.jp/files/pdf/230602_alert_generative_AI_service.pdf

注8　「個人情報の保護に関する法律についてのガイドライン」に関するQ&A Q7-53

発行主体：個人情報保護委員会

原資料URL：https://www.ppc.go.jp/all_faq_index/faq1-q7-53/

注9　「個人情報の保護に関する法律についてのガイドライン」に関するQ&A Q12-4

発行主体：個人情報保護委員会

公表日・版：2021年9月更新

原資料URL：https://www.ppc.go.jp/all_faq_index/faq1-q12-4/

注10　個人情報の保護に関する法律についてのガイドライン（外国にある第三者への提供編）

発行主体：個人情報保護委員会

公表日・版：2016年11月策定／2025年12月一部改正

原資料URL：https://www.ppc.go.jp/personalinfo/legal/guidelines_offshore/

注11　「個人情報の保護に関する法律についてのガイドライン」に関するQ&A Q10-25

発行主体：個人情報保護委員会

公表日・版：2021年9月追加

原資料URL：https://www.ppc.go.jp/all_faq_index/faq1-q10-25/

注12　不正競争防止法（平成5年法律第47号）／営業秘密〜営業秘密を守り活用する〜

原資料URL1：https://laws.e-gov.go.jp/law/405AC0000000047

原資料URL2：https://www.meti.go.jp/policy/economy/chizai/chiteki/trade-secret.html

注13　Document-level access control in Azure AI Search

発行主体：Microsoft Learn

公表日・版：2026年9月17日更新

原資料URL：https://learn.microsoft.com/en-us/azure/search/search-document-level-access-overview

確認日：2026年10月3日

注14　LLM01:2025 Prompt Injection

発行主体：OWASP Gen AI Security Project

公表日・版：2025年版

原資料URL：https://genai.owasp.org/llmrisk/llm01-prompt-injection/

注15　漏えい等の対応とお役立ち資料／個人情報保護法ガイドライン（通則編）

発行主体：個人情報保護委員会

公表日・版：対応案内は2026年10月3日参照／通則編は2026年6月一部改正版

原資料URL1：https://www.ppc.go.jp/personalinfo/legal/leakAction/

原資料URL2：https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/

注16　「AIの利用・開発に関する契約チェックリスト」を取りまとめました

発行主体：経済産業省

公表日・版：2025年2月18日公表

原資料URL：https://www.meti.go.jp/press/2024/02/20250218003/20250218003.html

注17　個人情報の保護に関する法律等の一部を改正する法律の公布資料・関連法令資料

発行主体：個人情報保護委員会

公表日・版：2026年7月17日公布／改正法特集ページは2026年10月1日更新分まで参照

原資料URL1：https://www.ppc.go.jp/news/press/2026/260717/

原資料URL2：https://www.ppc.go.jp/files/pdf/260717_houritsu.pdf

原資料URL3：https://www.ppc.go.jp/personalinfo/legal/r8kaiseihogohou/

注18　個人情報の保護に関する法律についてのガイドライン（仮名加工情報・匿名加工情報編）

発行主体：個人情報保護委員会

公表日・版：2016年11月策定／2026年4月一部改正

参照箇所：2-1「定義」、2-2「仮名加工情報取扱事業者等の義務」、3-1「定義」、3-2「匿名加工情報取扱事業者等の義務」

原資料URL：https://www.ppc.go.jp/personalinfo/legal/guidelines_anonymous/