生成 AI 学習データ開示のプリンシプル・コードとは｜AI を組み込んだサービス提供企業が備えるべきこと
「うちは AI モデルを開発しているわけではない。API を呼んでいるだけだ」
2026年8月に策定されたプリンシプル・コードの話題が出たとき、自社の SaaS やサービスに生成 AI を組み込んでいる企業の多くは、そう受け止めたのではないでしょうか。
2026年8月25日、知的財産戦略本部（事務局：内閣府知的財産戦略推進事務局）は、生成 AI 事業者に対し、知的財産権の保護とデータ取得方法などの透明性確保を求める基本原則を公表しました。正式名称は「生成 AI の適切な利活用等に向けた知的財産の保護及び透明性に関するプリンシプル・コード」です。① 使用モデル・学習データ・アカウンタビリティの概要と、知的財産権保護のための措置の開示、② 権利者からの照会への回答、③ AI 利用者からの照会への回答、という3つの原則で構成されています。法的拘束力はなく、原則を実施するか、実施しない場合はその理由を説明する「コンプライ・オア・エクスプレイン」の手法が採られました。
（出典：内閣官房「生成 AI の適切な利活用等に向けた知的財産の保護及び透明性に関するプリンシプル・コード」 ／ 同「概要開示対象事項 具体例」 ／ ITmedia AI＋「政府、AI 事業者向け『知財保護ルール』策定 対象範囲・運用方針は？」2026年8月25日）
このコードが対象とするのは、OpenAI や Google のような大手モデル開発企業だけではありません。自社のサービスに生成 AI を組み込み、公衆に向けて提供している企業も「生成 AI 提供者」として対象になり得ます。画像生成機能を持つデザインツール、文章生成を組み込んだ CMS、AI を活用したクリエイティブ制作サービス。こうしたサービスを提供する企業にとっては、対岸の火事ではありません。
本記事では、生成 AI の機能を組み込んだサービスを提供する企業に向けて、プリンシプル・コードが自社にどう関わるのか、顧客企業から何を求められるようになるのか、そして今から備えるべき対応を解説します。
「API を呼んでいるだけ」でも対象になり得る理由
プリンシプル・コードが対象とする「生成 AI 提供者」の範囲を正確に理解することが出発点です。
このコードが対象としているのは、生成 AI の機能を公衆に向けて提供する事業者です。基盤モデルの開発を自社で行なっているかどうかは、対象の判定基準ではありません。API 経由で外部のモデルを呼び出し、自社のデータや機能と組み合わせてサービスとして提供している場合でも、「公衆に向けた生成 AI の提供」に該当すれば対象となり得ます。
特に注意すべきは、原則1で開示が求められる「学習データ関係」の項目に、RAG（検索拡張生成）で用いるデータの種類が明記されている点です。モデル自体のファインチューニングは行なっていなくても、自社のデータベースや外部ソースを RAG で参照させてサービスを提供している場合、そのデータの種類や取得方法が開示対象に含まれます。
一方で、公衆への提供を行なっていない自社グループ内だけの基盤や、特定の1社から提供を受けたデータのみに基づいて生成する仕組みを当該1社にのみ提供するカスタム開発は、原則として対象外と整理されています。ここで注意したいのは、対象外となるのは「提供先が1社であること」ではなく「その1社のデータのみに基づき生成する構成であること」が条件だという点です。汎用モデルの一般的な知識も使って生成している場合は、提供先が1社でも対象になり得ます。
まずは自社のサービスが「公衆向け提供」に該当するかを法務部門と連携して確認する必要があります。BtoB の SaaS であっても、不特定多数の企業がアカウントを取得して利用できる形態であれば、公衆向けに該当する可能性が高いと考えるのが妥当です。
顧客企業の調達基準が変わり「選ばれなくなる」リスク
プリンシプル・コードへの対応が求められる理由は、法的な義務だけではありません。より実務的なリスクは、顧客企業の調達基準が変わることです。
大手企業やグループ会社が AI サービスを導入・継続利用する際、法務・知財部門が「このベンダーはプリンシプル・コードに準拠しているか」を確認するケースが今後増えてくると考えられます。準拠していないと判断された場合、技術的な優位性があっても選定で不利に働く可能性があります。既存顧客であっても、契約更新時に準拠状況の確認を求められる場面は想定しておくべきです。
特にクリエイティブ生成機能（画像生成、テキスト生成、動画生成など）を持つサービスは、生成物が既存の著作物と類似するリスクが他の AI 機能より高いため、顧客企業の法務部門による確認がより厳格になることが想定されます。
内閣府知的財産戦略推進事務局は、届出のあった生成 AI 事業者の一覧と、各社が公表したコーポレートサイト等のリンクを公表するとしています。ただし届出の受付開始時期は「別途お知らせします」とされており、2026年9月2日時点では未確定です（報道では今秋をめどとする見方が出ています）。一覧の公表が始まれば、そこに載っていないことが顧客との商談や契約更新で不利に働く可能性はあります。逆に言えば、早期に対応を整えて受入れ表明を行なうことは、競合サービスに対する営業上の差別化ポイントにもなります。
（出典：内閣官房「AI 時代の知的財産権検討会」 ／ 時事通信「AI 学習データ開示促す 政府、知財保護で基本指針」2026年8月25日）
プリンシプル・コードに備える5つの対応
プリンシプル・コードへの受入れ表明に向けて、サービス提供企業が整備すべき事項を5つに整理します。
ポイント① 自社サービスの該当判定を行なう
自社のサービスが「公衆向けの生成 AI 提供」に該当するかを確認します。判定の分岐点は、サービスの提供先が不特定多数かどうかです。複数企業に利用されている SaaS であれば該当する可能性が高い一方、特定の1社から提供を受けたデータのみに基づき生成する仕組みを当該1社にのみ提供している受託開発は、対象外と整理されます。自社のプロダクトラインが複数ある場合は、サービスごとに判定が必要です。
ポイント② 学習データと RAG データの開示情報を整備する
原則1の開示項目は、「使用モデル関係」「学習データ関係」「アカウンタビリティ関係」の3分類に加えて、知的財産権保護のための措置への対応状況で構成されています。侵害生成物を防ぐフィルタリング機能などは、この知的財産権保護のための措置に位置づけられています。自社でモデルを開発していない場合でも、利用している API のモデル情報と、RAG で参照しているデータソースの種類・取得方法は整理する必要があります。これらをコーポレートサイトやサービスの利用規約上で公開できる形にまとめることが、受入れ表明の土台になります。
ここで重要なのは、開示の粒度です。「モデルの種類は LLM です」という記載と、「〇〇社の△△（バージョン x.x）を API 経由で利用し、自社の〇〇データベースを RAG のデータソースとして参照しています」という記載では、顧客企業の法務部門に与える信頼度が全く異なります。
ポイント③ 権利者・利用者からの照会に対応する窓口を整備する
原則2（権利者からの照会）と原則3（利用者からの照会）への対応体制が必要です。ここで押さえておきたいのは、原則2の照会を行なえるのが、訴訟提起・調停申立て・ADR などの法的手続を現に行なっている、または準備している権利者とその代理人に限られる点です。あらゆる権利者からの問い合わせに無条件で回答することを求めるものではありません。想定される照会は、権利者からは「自分の著作物の URL が学習データの取得源に含まれているか」、利用者からは「生成物と類似するコンテンツの URL が学習データに含まれているか」といった内容です。
照会の実数がゼロであっても、窓口と回答プロセスが存在すること自体が、顧客企業の調達審査における安心材料になります。問い合わせフォームや専用メールアドレスの設置、回答期限の目安の明示、対応フローの文書化を進めておくことが実務的な対応です。
ポイント④ 生成ログの保持ポリシーを設計する
原則3では、利用者が照会を行なう際の条件として、生成物と、その生成に用いたプロンプトの提示が定められています。照会に対応するためには、サービス提供者側でも必要な範囲で生成ログを保持する設計が求められます。保持期間、保持するデータの範囲、保管場所と削除ルールを定めておくことで、照会対応と個人情報保護の両立が可能になります。
クリエイティブ生成機能を持つサービスの場合、生成された画像やテキストが既存の著作物と類似しているかどうかの確認が照会の中心になるため、入力プロンプトと出力結果の対応関係を追跡できる形でのログ保持が重要です。
ポイント⑤ モデル更新と連動した開示情報の見直しサイクルを設計する
プリンシプル・コードは、受入れ表明を行なった事業者に対して、その内容を原則として毎年見直し・更新することを期待するとしています。加えて、利用している API のモデルがバージョンアップされた場合、学習データの構成が変わっている可能性があります。
モデルの更新を検知し、開示情報を連動して見直す仕組みを開発・運用プロセスに組み込んでおく必要があります。API 提供元のリリースノートの定期確認や、モデルバージョンの変更をトリガーにした開示内容のレビューフローが実務的な対策になります。
よくある失敗パターンと注意点
失敗① 「API を呼んでいるだけだから対象外」と判断してしまう
基盤モデルの開発元が開示を担うのだから自社は対象外、という整理は、RAG で自社データを組み合わせている場合やファインチューニングを行なっている場合には通用しない可能性があります。特に、自社独自のデータセットでファインチューニングを施したモデルを公衆向けサービスに組み込んでいる場合、自社が「学習を行なった主体」として開示を求められ得ます。
失敗② 形式的な開示で済ませ、顧客の期待値に届かない
プリンシプル・コードの最低限の要件を形式的に満たしても、顧客企業の法務部門が求める粒度に達していなければ「不十分」と判断されます。届け出の有無だけでなく、開示内容の具体性が契約継続や新規商談の成否を左右します。顧客側は「この AI サービスのデータの取り扱いを、自社の法務に説明できるか」という基準で見ていることを意識する必要があります。
失敗③ モデル更新時に開示情報を更新し忘れる
API 提供元のモデルがバージョンアップされた際に、自社の開示情報を更新し忘れるケースです。顧客企業が「導入時に確認した条件」で利用を続けている中、実際にはモデルが変わっているという状態は、信頼関係を損なう要因になります。モデルバージョンの変更を検知できる仕組みがない場合、気づかないうちに開示内容と実態が乖離するリスクがあります。
まとめ・次のステップ
プリンシプル・コードは、AI モデルを「作る」企業だけでなく、AI を「組み込んで提供する」企業にも対応を求めています。特にクリエイティブ生成機能を持つ SaaS やサービスを提供している企業は、顧客企業の法務・知財部門の確認対象になる可能性が高く、早期の対応が競合との差別化にもつながります。
まず確認すべきは、自社のサービスがプリンシプル・コードの対象に該当するかどうかです。該当する場合は、学習データ・RAG データの開示情報の整備、照会対応窓口の設置、生成ログの保持ポリシー設計を進め、モデル更新と連動した見直しサイクルを開発・運用プロセスに組み込みます。
KDDIアイレットでは、Google Cloud の Vertex AI や Amazon Bedrock を活用した生成 AI 基盤の設計・構築において、入力プロンプトと出力結果の対応関係を追跡できる形でのログの保持設計やアクセス制御を含めたアーキテクチャの構築を支援しています。「自社サービスがプリンシプル・コードの対象になるか整理したい」「既存の AI 機能にログ保持の仕組みを追加したい」という段階から、ご相談ください。