Ethycaで同意をAIの参照に効かせる｜目的外を止める線

「お客様から同意をもらっているデータなのだから、社内のAIに読ませても問題ないはず」「でも、何に使うと説明して集めたデータなのか、AIを作る側は誰も知らない」——顧客データを抱える企業のAI導入担当と個人情報の担当の間で、すれ違いが起きやすい二つの声です。前者の考え方は分かりやすいのですが、半分しか当たっていません。同意や通知は、それ単体ではなく「何のために使うか」という利用目的とセットで意味を持ちます。AIがデータを読むその時に、その読み出しが目的の内か外かを判定しなければ、同意を取っていても目的外の利用は起きます。問いは「同意を取ったか」から「取った同意をAIの参照時にどう守らせるか」に変わりました。この記事では、米国の Ethyca が2026年8月に出した Astralis を例に、目的の書き方・参照時の判定・目的外の読み出しを止める判断を誰が持つかを整理します。

Ethyca は何をする会社で、Astralis は何を止める製品か

Ethyca は、企業の個人データの管理を仕組みにする米国の会社です。2026年10月時点の公式サイトでは、データの所在を見つけて分類する機能、同意と好みの管理、本人からの削除などの請求への対応、データの種類と使い道を記述する語彙の4つを柱にしており、200を超える世界のブランドが使っているとしています（提供元の説明）。報道では2018年の創業とされています。

その土台にあるのが、2021年に公開したオープンソースの語彙 Fides です。Fides は、データの種類（連絡先・購買履歴など）、データの使い道（サービスの提供・広告・分析など）、データの主体（顧客・従業員など）を、階層のある決まった名前で書き表すための共通の言葉です。「どのデータを、どの目的で使ってよいか」を、人が読む文書ではなく仕組みが読める形で書くことが、この会社の出発点になっています。

2026年8月4日に発表した Astralis は、この語彙をAIの読み出しに当てる製品です。公式の発表では、データの使われ方を「意図した使い道」で統制し、管轄の法令、顧客の意向、契約、自社の約束に照らして判定すると説明しています。判定を当てる場所として、データの倉庫、データベースを問い合わせる道具、分析のノートブック、BIのダッシュボード、大規模言語モデル、MCP サーバーが挙げられています。

つまり Astralis が止めるのは、人の閲覧権限では止まらない種類の読み出しです。権限のうえでは読めるデータでも、読む目的が許されていなければ、その読み出しを止めるという考え方です。同じ便で扱ったデータの区分で止める製品（前日の MIND の記事）とは、止める物差しが「データの種類」ではなく「使う目的」である点が違います。

国内でまだ知られていない理由

日本語で Ethyca を紹介した記事は、2026年10月時点でほとんど見当たりません。理由は確かめた範囲で3つあります。一つは、公式サイトが英語のみで、扱う法令として欧州の一般データ保護規則、米国カリフォルニア州の消費者プライバシー法、欧州のAI法などが挙がっている一方、日本の個人情報保護法への言及が見当たらないことです。

二つめは、対象の規模です。報道では、提供元の説明として米国の大手金融機関が毎秒6,000件の読み出しの判定を Astralis で処理していると紹介されています。公式サイトで Fides の利用者として名前が挙がるのも、ニューヨーク・タイムズ、コンデナスト、法人カードのランプといった、データの量が多く規制の目が厳しい企業です。年に数件のAI案件を審査する規模の会社が、そのまま入れる前提の製品ではありません。

三つめは、国内では「同意の管理」と「AIの統制」が別の部署・別の製品で語られてきたことです。同意の管理は広告や計測の文脈で、AIの統制は情報システムやリスク管理の文脈で扱われることが多く、両方をつなぐ製品はまだ選ぶ対象として意識されていません。

日本語の管理画面や国内の窓口の有無は、公式サイトでは確かめられませんでした。日本の法令の目的の考え方に合わせて使えるかは、自社で確かめる前提になります。それでも取り上げるのは、この製品が示す「読む瞬間に目的を確かめる」という設計が、国内の企業がAIに顧客データを読ませるときの論点をそのまま形にしているからです。

2026年8月の発表で確かめられたことと、確かめられなかったこと

新しい製品を検討するときは、公式で確かめられたことと、まだ分からないことを分けて持つのが安全です。Astralis については、発表文・製品ページ・報道を読んだ範囲で、次のように整理できます。

項目	2026年10月時点で確かめた内容	出所
提供の状態	設計パートナー向けに提供してきたものを、8月4日から誰でも申し込める形に開いた	公式の発表
判定の中身	規制とリスクを学ばせた言語モデルが実際の使われ方を推定し、Fides で書いた方針を実時間で当てる	公式の発表
判定を当てる場所	データの倉庫、問い合わせの道具、ノートブック、BI、大規模言語モデル、MCP サーバー	公式の発表・製品ページ
判定の性質	決定的で再現でき、判定ごとに記録が残る。監督当局に出せる証跡を作るとしている	製品ページ
動く場所	自社の基盤か専用の環境の中で動き、規制対象のデータの処理者にはならないとしている	製品ページ
止めたあとの扱い	例として示されているのはエージェントの問い合わせを止めることだけ。伏せ字にする・人に回すといった扱いは記載なし	製品ページ（記載なし）
目的の決め方	利用目的を誰がどう定義するかの手順は記載なし	確かめられず

報道では、従来は1件に40〜60時間かかっていたプライバシーとAIの評価が20〜40分になったと紹介されていますが、これは提供元の説明で、独立した検証は見つかっていません。また、判断に追加の情報が要るときは社内の専門家に知らせる動きをするとも報じられています。

表の下の2行が、導入を考える側にとって一番大事な空白です。止めたあとに業務をどう続けるか、目的を誰が定義するかは、製品が答えてくれる部分ではなく、使う会社が決める部分だからです。次の節からは、この空白を自社で埋めるための考え方を見ていきます。

「同意があればAIに使える」が外れる3つの場面

最初に、目的外の読み出しが実際にどんな形で起きるかを見ておきます。典型は、広告の配信のために同意をもらった閲覧履歴を、社内の分析用のAIエージェントが別の用途で読む場面です。エージェントに与えた権限は分析のデータ全体を読めるので、履歴のテーブルも読めてしまいます。読む理由は「解約しそうな顧客を探す」で、これは広告の配信とは別の目的です。

二つめは、問い合わせの窓口で受け取った内容を、営業の提案文を作るAIが読む場面です。問い合わせへの回答のために預かった内容が、本人の知らないところで営業の材料に変わります。社内では「同じ会社の中の話」と受け止められやすいのですが、本人に示した目的から見れば、窓口の対応と営業の提案は別の使い道です。

三つめは、AIを作り直すときです。社内のAIの精度を上げるために、過去の顧客とのやり取りを学習や評価の材料にまとめる。データを集めた時点では、AIの学習に使うことは目的として書かれていなかった、という形です。生成AIが社内に広がる前に集めたデータほど、この形になりやすくなります。

3つに共通するのは、読む側のAIに悪意はなく、権限の設定も間違っていないことです。権限は「誰が読めるか」を決めますが、「何のために読むか」は決めません。人の担当者なら、異動のときの研修や上長の目で使い道のずれに気づく機会がありますが、エージェントは与えられた権限の範囲で黙って読みます。

目的外の読み出しは、なぜ気づかれないまま起きるのか

こうした読み出しが問題として表に出るのは、たいてい後になってからです。顧客からの問い合わせ、本人からの開示の請求、取引先の監査、あるいは社内の点検で、ようやく「このデータは何の目的で集めたものだったか」が問われます。

気づかれない理由は、読み出しが起きる場所と、目的が書かれている場所が離れていることにあります。目的は、プライバシーポリシーや同意の画面、契約書に書かれています。読み出しは、データの倉庫やAIの実行環境で起きます。目的を書いた文書と、データを読む仕組みの間に、つなぐ線がないのが普通の状態です。

事前の審査で補おうとしても、AIの案件では追いつきません。読み出しの組み合わせは実行のたびに変わり、エージェントは呼び出す先やデータをその場で選びます。案件を始める前に一度審査しても、運用中に読み出しの中身が変わっていきます。Ethyca が Astralis を「定期的な点検の置き換え」と位置づけているのも、この点を指しています。

ここから先は、原因を3つに分けて見ます。どれか1つだけを手当てしても、残りの2つから目的外の読み出しは起きます。それぞれの原因に、誰が持つべきかを対応させて考えるのがこの記事の進め方です。

原因1：同意の記録と、AIの読み出しが別の仕組みにある

多くの会社では、同意の記録は同意の管理の道具か、顧客の管理の仕組みの中にあります。誰が、いつ、どの目的に同意したか、あとから撤回したか、という情報です。一方、AIが読むのは、分析用に集めたデータの倉庫や、そこから切り出した表です。

この二つは、たいてい自動ではつながっていません。分析用の表に写すときに、同意の状態が列として一緒に運ばれていなければ、表を読むAIからは、その行の本人がどの目的に同意しているかが見えません。撤回があっても、写した表には反映されないまま残ります。

Ethyca が公式サイトで、同意と好みの管理を「モデルやエージェントにも当てる」と説明しているのは、この断絶を埋めるためです。ただ、同意の記録を判定に使うには、本人を識別する鍵が両方でそろっていることが前提になります。会員の番号と広告の識別子が別々に管理されていると、つなぐ前に照合の作業が要ります。

導入を考える前に、自社で一度確かめておきたいのは、AIが読む表の1行から、その本人の同意の状態までたどれるかです。たどれないなら、どんな製品を入れても判定の材料が足りません。最初の作業は、製品の選定ではなく、鍵の対応表づくりになります。

原因2：利用目的の文言が、AIの用途を想定していない

二つめの原因は、目的の書き方です。プライバシーポリシーの利用目的は、多くの場合「サービスの提供のため」「マーケティングのため」「サービスの改善のため」といった広い言葉で書かれています。人が読む文書としては十分でも、AIの読み出しを判定する物差しとしては粗すぎます。

たとえば「サービスの改善のため」は、AIに過去のやり取りを学習させることを含むのか。解約しそうな顧客を探すことは「マーケティング」なのか「サービスの改善」なのか。広い言葉のままでは、判定の仕組みはどちらにも決められず、結局すべてを通すか、すべてを止めるかになります。

Fides の語彙が、使い道を「サービスの提供」の下に「運用」「その中のサポート」と階層で細かく書けるようにしているのは、この問題への答えです。粗い目的を、仕組みが判定できる粒度まで分けて書き直す。そのうえで、公表している目的のどれに当たるかを対応させておきます。

ここで注意したいのは、細かく書き直すことと、目的を広げることは別だという点です。日本の個人情報保護法は、利用目的をできる限り特定し、本人の同意を得ずに特定した目的の範囲を超えて扱うことを原則として禁じています。社内の分類を細かくしても、本人に示した目的の外に出てよいことにはなりません。目的を変える場合の条件は別の記事（集めた名簿を別の用途に使う条件）で扱っているので、ここでは立ち入りません。

原因3：目的外の読み出しを止めると決める人がいない

三つめの原因は、持ち主の不在です。AIの案件はAI導入の担当が進め、データの倉庫は情報システムが管理し、同意と利用目的は法務や個人情報の担当が持つ。それぞれの持ち場は決まっていても、「この読み出しは目的の外なので止める」と言える人が決まっていないことがよくあります。

持ち主がいないと、判定の仕組みを入れても運用が回りません。止まったときに誰に知らせるのか、止まった案件を誰が見直すのか、例外として通すなら誰が承認するのかが決まっていなければ、現場は止まった理由が分からず、仕組みを外す方向に動きます。

もう一つの落とし穴は、止める判断と例外を認める判断を、同じ人に持たせることです。AI導入の担当が両方を持つと、案件を進めたい立場から例外が増えていきます。逆に法務がすべてを持つと、承認の待ちが積み上がります。止める基準は個人情報の担当、例外の承認は個人情報の担当と業務の責任者の二人、というように分けておくと、どちらにも偏りにくくなります。

なお、AIの案件全体をどの部署が受け止めるかという体制の話は、別の記事（プライバシーガバナンスとAI）で扱っています。この記事で見るのは、もっと狭く、読み出しの1件を止めるか通すかを決める人の置き方です。

原因と手当ての対応表

ここまでの3つの原因を、起きること、手当て、手当ての持ち主の順に並べると次のようになります。手当ての中身は次の節から順に見ます。

原因	放っておくと起きること	手当て	持ち主
同意の記録と読み出しが別の仕組み	撤回した人のデータもAIが読み続ける	本人の鍵をそろえ、同意の状態を判定の材料として渡す	情報システム（鍵）と個人情報の担当（同意の状態）
目的の文言が粗い	判定がすべて通すか、すべて止めるかに偏る	用途ごとに使い道を書き分け、公表した目的との対応を残す	個人情報の担当と法務
止める持ち主がいない	止まった理由が分からず、仕組みが外される	止めたときの知らせ先と、例外の申請と承認の道を決める	個人情報の担当（基準）と業務の責任者（例外の共同承認）

表で一番右の列が空欄のままなら、製品の導入はまだ早い段階です。Astralis のような製品が担えるのは、真ん中の列の一部、つまり判定と停止と記録です。目的の書き分けと、止めたあとの判断の道は、製品が作ってくれるものではありません。

社内のAIの台帳を別の仕組み（たとえば OneTrust のAIガバナンス）で持っている会社なら、台帳の各案件に「読む目的」の列を足し、この表の持ち主とつないでおくと、判定の結果を台帳の側から追えるようになります。

手当て1：用途ごとに使い道を書き分ける

最初の手当ては、目的の書き分けです。進め方は、社内のAIの用途を先に並べ、それぞれがどの使い道に当たるかを決めていく順番が向いています。法務の文書から始めると、言葉の議論で止まりやすいからです。

たとえば、問い合わせの回答の下書き、解約の兆しの検出、広告の配信先の選定、社内のAIの評価用のデータ作り、といった用途を並べます。それぞれに「サービスの提供のうちサポート」「分析のうち顧客の維持」「広告」「AIの開発」のような使い道の名前を当て、どの公表済みの目的に入るかを、根拠の文言と一緒に1行ずつ残します。

この作業で、どの公表済みの目的にも入らない用途が見つかることがあります。それは仕組みで止めるべき候補であり、同時に、目的の変更や同意の取り直しを検討すべき候補でもあります。どちらにするかの判断はこの記事の範囲を超えるので、法務と専門家に確かめてください。

書き分けた使い道の一覧には、決めた人と日付と、根拠にした文言を必ず付けます。一覧は判定の物差しそのものなので、後で「なぜこの用途は通ったのか」と聞かれたときに、ここから答えられる状態にしておく必要があります。

手当て2：読む瞬間に判定させ、判定の記録を残させる

二つめの手当ては、判定の場所を読み出しの時点に置くことです。事前の審査は残したうえで、実行のたびに「このAIは今、何の目的でこのデータを読もうとしているか」を確かめます。Astralis が判定をデータの倉庫やMCP サーバーの手前に置くと説明しているのは、この位置です。

判定の材料は、少なくとも3つ要ります。読もうとしているデータの種類、読もうとしているAIの用途、そしてデータの本人の同意の状態です。3つのうち1つでも欠けたら、通さずに止める側に倒すのが基本の設計です。材料が欠けたまま通す設定にすると、仕組みを入れた意味がなくなります。

判定の記録は、止めたものだけでなく通したものも残します。監査や本人からの請求で問われるのは、たいてい「このデータは何に使われたか」で、止めた記録だけでは答えられません。製品ページでは判定ごとに記録が残るとされていますが、保存の期間や取り出しの形式は記載がないため、契約の前に確かめる項目になります。

もう一つ確かめたいのは、判定の結果をAIの側がどう受け取るかです。止められたエージェントが、別の経路で同じデータを取りに行かないか。止めた読み出しを、エージェントが言い換えて取り直せない設計になっているかは、試行の段階で実際に確かめておく価値があります。

手当て3：止めたときの知らせと、例外の申請の道を決める

三つめの手当ては、止めたあとの運用です。止めたこと自体はゴールではなく、止まった業務をどう続けるかまで決めて初めて、現場が仕組みを外さずに使い続けられます。次の順番で道を作っておくと、止まるたびに議論をやり直さずに済みます。

この道の中で、AIに任せてよいのは、止めたことの通知と記録、代わりの表の候補の提示までです。例外を認めるか、目的を見直すかの判断は人が持ちます。顧客に説明が必要になった場合も、その説明を書いて出すのは人です。

目的を推定するAIに、どこまで任せるか

Astralis の特徴の一つは、判定の材料である「読み出しの目的」そのものを、規制とリスクを学ばせた言語モデルが推定すると説明している点です。人がすべての案件に目的のラベルを付けて回るのは現実的ではないので、推定で補うという考え方は理にかなっています。

ただ、推定は推定です。AIが「この問い合わせは顧客の維持の分析だ」と推定しても、その推定が正しいかを確かめる手段を持っておかないと、目的の判定そのものが、誰も検証していないAIの判断になります。判定が決定的で再現できるとされているのは、方針を当てる部分の話で、推定の当たり外れとは別に考える必要があります。

• 推定された目的を、人が一度も抜き取りで確かめないまま本番の判定に使う
• 推定が外れて止まった案件を、現場の判断で例外として通し続ける
• 推定の結果を、利用目的の定義や公表の文言の代わりとして扱う
• 判定の記録を「AIが判断した」とだけ残し、推定の根拠を残さない

任せ方の線は、推定と判定と記録はAI、推定が正しいかの抜き取りと、推定が使う物差し（使い道の一覧）の定義は人、です。導入の初めは、推定された目的と人が付けた目的を並べて記録し、ずれる用途を洗い出してから判定に使う範囲を広げてください。

導入の前に決めること：配る範囲・外に出るもの・費用・止め方

ここまでの論点を、製品を入れるかどうかの判断に落とします。まず配る範囲です。最初から全社のAIに判定を当てるのではなく、顧客データを読む案件のうち、目的のずれが起きやすい分析と営業支援の2つ程度から始めるのが現実的です。

次に、何が外に出るかです。製品ページでは、Astralis は自社の基盤か専用の環境の中で動き、規制対象のデータの処理者にはならないと説明しています。その説明が自社の構成で本当に成り立つか、判定のために提供元へ送られる情報が何かは、契約の前に書面で確かめる項目です。推定を行う言語モデルがどこで動くかも同じです。

費用は、判定の件数と、つなぐ読み出しの場所の数で増える形になると考えておくのが安全です。エージェントは人よりはるかに多く読み出しを行うので、試行の規模で見積もった費用が、本番の展開で一桁変わることがあります。料金の体系は公式サイトで公表されていないため、増え方の条件を提供元に確かめてください。

最後に止め方です。判定の仕組みが止まったとき、読み出しを全部止めるのか、全部通すのかを先に決めておきます。仕組みが落ちたら読み出しも止まる側に倒すのが原則ですが、それでは止まる業務もあります。止まる業務の一覧と、そのあいだの代わりの手順を、導入の前に書いておきます。

よくある質問

同意を取り直せば、AIに何でも読ませてよくなりますか

同意を取り直す場合も、何の目的に同意してもらうかを具体的に示す必要があります。「AIに使います」という広い同意で何でも読めるようになるわけではなく、目的の書き分けは結局必要です。法的に足りる書き方かどうかは、専門家に確かめてください。

Fides の語彙だけを使って、製品を入れずに始められますか

Fides はオープンソースとして公開されているので、使い道の書き分けの型として参考にすることはできます。ただし、判定を読み出しの時点で当てる仕組みは別に必要です。まず語彙で使い道の一覧を作り、判定の仕組みは後から選ぶ、という順番は取れます。

日本の個人情報保護法に合わせた判定ができますか

2026年10月時点の公式サイトには、日本の法令への言及は見当たりませんでした。判定の方針は自社で書く部分なので、日本の法令に沿った目的の一覧を自社で作れば当てること自体はできると考えられますが、対応の範囲は提供元に確かめる必要があります。

同意の管理の道具をすでに入れていますが、二重になりませんか

同意の管理の道具は、同意を取って記録するところまでを担います。読み出しの時点で判定するのは別の役割です。既存の道具の記録を判定の材料として渡せるかが、選ぶときの一番の確認点になります。

まとめ

同意を取っていることと、AIがそのデータを読んでよいことは同じではありません。同意や通知は利用目的とセットで意味を持ち、AIが読むその時に目的の内か外かを判定しなければ、権限の設定が正しくても目的外の読み出しは起きます。原因は、同意の記録と読み出しが別の仕組みにあること、目的の文言がAIの用途を想定していないこと、止める持ち主がいないことの3つです。Ethyca の Astralis は、読み出しの時点で目的を判定して止め、判定を記録する製品として2026年8月に一般に開かれましたが、止めたあとの扱いや目的の定義の手順は公式の資料では示されていません。判定・停止・記録はAIに任せ、利用目的の定義・例外の承認・顧客への説明は人が持つ。まずはAIが読む表の1行から本人の同意までたどれるかを確かめ、用途ごとの使い道の一覧を作るところから始めてください。

• 製品の機能と提供状況は、Ethyca の公式サイト・Astralis の発表文と製品ページ・Fides の公開リポジトリを2026年10月23日に確かめた範囲と、2026年8月4日の報道に基づきます
• 料金の体系、日本語の管理画面と国内の窓口、日本の法令への対応、止めたあとの扱いの種類は公式の資料で確かめられなかったため、契約の前に提供元に直接確かめてください
• 利用目的の特定や変更が法的に足りるかの判断は、この記事では行っていません。弁護士などの専門家に確かめてください

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。