AI の 3 主体と責任の境界 — 利用者のつもりで提供者になっていないか

「AI 推進法ができたので対応が必要です」という説明を受ける機会が増えていますが、この表現は法的には正確ではありません。 日本の AI に関する規律は拘束力の異なる 3 つの層でできており、実際に企業を縛っているのは AI 推進法ではなく、既存の個人情報保護法と契約です。

本稿では、まず拘束力の地図を整理し、そのうえで AI 事業者ガイドラインが定める 3 つの主体（AI 開発者・AI 提供者・AI 利用者）の境界が、AI を業務システムに組み込むと実際にどこで動くのかを論じます。

拘束力の地図

AI に関する規律としてよく並べて語られる 3 つは、性質がまったく異なります。

この整理から導かれる実務上の優先順位は明快です。AI 固有の新法よりも、既存の個人情報保護法と、顧客との契約のほうが先に効きます。 AI 推進法とガイドラインは、守らなくても直ちに処分されるものではありませんが、事故が起きたあとに「何を基準に判断したのか」を説明する拠り所になります。罰則の有無ではなく、説明責任の観点から扱うのが妥当です。

一次情報は当社の AI 開発・運用ポリシー 第 10 項からも参照できるようにしています。

3 つの主体

AI 事業者ガイドラインは、AI の事業活動を担う主体を 3 つに大別しています。

第 1.2 版では、同一の事業者が複数の主体を兼ねる場合の整理が加えられました。実務ではむしろ兼ねるのが常態です。 そして誤解が生じるのは、ほぼ常に利用者と提供者の境界です。

境界が動く瞬間

「社内で AI を使っているだけ」であれば利用者です。しかし、その出力が自社の外に出た瞬間、提供者の側に移ります。 当社が携わった構成を例に、主体の連なりを整理します（個別の案件が特定されない範囲に抽象化しています）。

お問い合わせフォームに届いた質問に対して、一次回答を AI が生成する仕組みです。チャットサービス事業者の API を利用し、社内文書を検索して回答の根拠とする構成（RAG）で、その背後では汎用の大規模言語モデルが動いています。

この表で単一の主体に収まっているのは 1 行しかありません。そして注目すべきは 4 行目です。顧客企業は「AI を導入して使っている」つもりでいますが、その出力は自社の顧客に直接届いています。 ガイドラインの提供者の定義には「場合によっては業務外利用者に提供する事業者」が明記されており、この構成は文言どおり提供者に当たります。

つまり、AI の導入を検討する段階では利用者として議論していた企業が、実装の形を決めた時点で提供者になっている。この移動は契約書にも稟議書にも書かれず、多くの場合、誰も気づきません。

境界を判定する 4 つの問い

自社がどちらの側にいるかは、次の 4 点で判断できます。1 つでも「はい」であれば、提供者として扱うのが安全です。

1. AI の出力が、自社の外部（顧客・取引先・一般消費者）に届くか
2. その出力が、自社の回答・見解として受け取られる形で届くか
3. 社外に出力が届く構成を、単発ではなく業務として継続的に運用しているか
4. 出力の内容について、社外の受け手から自社が説明を求められうるか

先の例では 4 つすべてが「はい」になります。一方、社内の議事録要約に AI を使っているだけであれば、いずれも「いいえ」であり、利用者にとどまります。

提供者になると何が変わるか

主体が変われば、求められる事項が増えます。ガイドラインの 10 の共通の指針のうち、提供者側で特に重くなるのは次の 3 つです。

透明性：AI が関与していることを、受け手が把握できる状態にする必要があります。問い合わせの一次回答であれば、それが AI による回答であることの明示と、人間の担当者に引き継ぐ経路の提示が該当します。先の例では、回答が AI によるものであることを画面上で明示しています。当社はこの考え方を AI 開発・運用ポリシー 第 5 項として定めています。

アカウンタビリティ：誤回答が生じたときに、なぜその回答が出たのかを説明できる状態を保つ必要があります。RAG 構成であれば、どの文書を根拠に回答したかの記録が残っているかどうかで、事後の説明可能性が決まります。

人間中心：AI の一次回答で完結させず、人間へのエスカレーション経路を設計に含める必要があります。この設計論は 監修型の AI 協働 で扱っています。

責任の分界点

主体の区分は「誰が何に責任を持つか」を決めるためのものですが、実務ではその線がシステムの内側にも引かれます。

RAG 構成では、回答の質は 2 つの要素で決まります。何を根拠として与えるか（ナレッジベースに置く文書）と、それをどう探して組み立てるか（検索と生成の設計）です。前者は業務を持つ側でなければ判断できず、後者は構築する側の設計責任です。

先の例でも、ナレッジベースに何を載せ、いつ更新するかは顧客企業が管理し、当社はそれを検索・回答に結び付ける仕組みを設計しています。この分担は自然に見えますが、契約で明示しておかないと、誤回答が起きたときに原因の所在で揉めます。

• 参照した文書自体が古かったのか（ナレッジベースの管理）
• 正しい文書があったのに検索が拾えなかったのか（検索の設計）
• 文書は拾えたが要約の段階で歪んだのか（生成の設計）

この 3 つは切り分けが可能です。切り分けられる形で記録を残す設計にしておくこと自体が、分界を成立させる条件になります。記録がなければ、どれだけ契約に書いても事後には判定できません。

前節のアカウンタビリティは、この意味でも重要です。

個人情報保護法の線

拘束力の地図で確認したとおり、実際に効くのはこちらです。問い合わせフォームには、氏名・連絡先・契約状況といった個人情報が含まれます。それが AI サービスに送信される構成では、個人情報保護委員会の注意喚起が示す 2 点が直接に問題となります。

1. 利用目的の範囲内か：個人情報を含むプロンプトを入力する際は、あらかじめ特定した利用目的の達成に必要な範囲内であることを十分に確認する
2. 学習に利用されないか：本人の同意なくプロンプトに個人データを含める場合、当該 AI サービス提供者が機械学習に利用しないことを十分に確認する

2 点目は、事業者向けの API では学習に利用しない旨が定められていることが多いものの、利用規約と契約で確認すべき事項です。とりわけ本稿の例のように、モデル提供元とサービス事業者と自社が別々に存在する多層構成では、どの層の規約が最終的に適用されるのかを確認しないと判断できません。

あわせて、委託の連なりも整理が必要です。顧客企業から当社へ、当社からチャットサービス事業者へ、さらにモデル提供元へと処理が渡る場合、個人データの取扱いの委託がどこで発生し、誰が誰を監督する立場にあるのかを契約上明確にしておく必要があります。データの取扱いに関する当社の方針は AI 開発・運用ポリシー 第 2 項に定めています。

設計に落とす

以上を、実装前に確認する項目として整理します。

このうち契約前と記した 3 つは技術的な検討ではなく、契約と運用の設計です。実装が終わってから確認すると、構成の変更が必要になることがあります。

まとめ

AI 推進法には罰則がなく、AI 事業者ガイドラインに法的拘束力はありません。しかし、AI の出力が社外に届く構成を選んだ時点で、企業は利用者から提供者へ移動しており、透明性・アカウンタビリティ・人間中心の各観点で求められる水準が上がります。そして個人情報保護法と契約は、この移動とは無関係に、最初から効いています。

重要なのは、この移動が実装の形を決める段階で静かに起きるという点です。稟議の段階では「社内利用」だったものが、実装の都合で社外に出る。そのときリスク評価はやり直されないまま運用が始まります。

要件定義の時点で「この出力は誰に届くのか」を一度確認すること。それだけで、後から構成を変更する事態の多くは避けられます。

本稿の視点は、第三者としてベンダーの提案や構成を検証する 技術監修 の実務に基づいています。当社の方針は AI 開発・運用ポリシー に定めています。