OneTrustのAI台帳に入れる項目一覧｜同意管理の次に持つ管理

「社内で使っているAIの一覧を作れと言われたので、表計算で作った。でも半年たったら誰も更新していない」「クッキーの同意の管理には OneTrust を使っているが、AIの管理は別の道具を探すものだと思っていた」——AIの利用が広がった会社の情報システム部門や個人情報の担当から、よく聞く声です。AIの台帳は、列を増やせば使えるようになると考えられがちです。また、同意の管理とAIの管理はまったく別の仕事だと思われがちです。けれども本当は、台帳が止まる原因は列の不足ではなく、個人情報の台帳と別々に持たれて、更新のきっかけを失うことにあります。この記事では、OneTrust のAIガバナンスの機能を例に、AIの台帳を同じ基盤で持つかどうかと、持つなら入れる項目と更新の回し方を整理します。

OneTrustのAIガバナンスは何をする機能か

OneTrust は、ウェブサイトのクッキーの同意の管理や、個人情報の管理の道具で知られる会社です。その製品群の一つとして、社内で使うAIを管理する AIガバナンス の機能を提供しています。2026年10月時点の公式の製品ページでは、AIのシステム、モデル、エージェント、データセット、提供元、案件、使い道を一か所に集め、それぞれの依存関係と持ち主まで台帳にすると説明されています。

台帳に載せたAIについては、受付、承認、利用者による確認、承認の署名までの流れを組めるとされています。リスクと業務の文脈に応じて、確認する担当に振り分ける仕組みもあります。リスクの評価には、欧州のAI法、米国国立標準技術研究所のAIリスク管理の枠組み（AI RMF）、ISO/IEC 42001 に沿ったひな形が用意され、自動でリスクの区分を付ける機能も案内されています。

さらに製品ページには、稼働中のAIの監視、指示文と出力に対する歯止め（ガードレール）、エージェントの動きを継続して見張る Guardian Agents といった、台帳の外側の機能も並んでいます。つまりこの製品は、一覧を作る道具であると同時に、承認の流れと稼働中の監視までを1つの基盤に寄せる道具です。どこまでを使うかは、導入する側が決めることになります。

国内でまだ知られていない理由と、提供元の発表

OneTrust の名前は、クッキーの同意のバナーで目にしたことがある人も多いはずです。ただ、AIガバナンスの機能を日本語でまとまって解説した記事は、2026年10月時点でほとんど見当たりません。製品ページや発表が英語などの海外向けの言語で書かれていること、連携先として並ぶのが大手のクラウドやデータ基盤であることから、AIを自社で作り、複数の基盤で動かしている大きな組織を主な相手にしていると読むのが自然です。

提供元の発表では、2026年6月に公表されたガートナーのAIガバナンスの基盤の評価（マジック・クアドラント）で、OneTrust はビジョナリーに位置づけられました。発表によれば、この市場を対象にしたガートナーのマジック・クアドラントはこれが初めてです。ただし、これは評価機関の位置づけを提供元が紹介したもので、自社に合うかどうかを示すものではありません。発表の中でもガートナーが特定の製品を推奨しない旨が添えられています。

国内の会社にとっての意味は、評価の順位よりも、同意の管理や個人情報の管理と同じ提供元が、AIの管理まで製品として出しているという点にあります。すでに OneTrust を契約している会社にとっては、新しい道具を探す前に、手元の基盤を延ばす選択肢があるということです。社内のAIが何を答えてしまうかを測る検査は、同じ便の Knostic の記事で扱います。

「AIの台帳は表計算で足りる」という誤解

AIの台帳を作るとき、最初に出てくる意見は「表計算で十分」というものです。たしかに、項目を並べて一覧にするだけなら、表計算で作れます。数十件のAIを管理するのに専用の基盤が要るのか、という疑問はもっともです。

問題は、作った後です。表計算の台帳は、誰かが開いて書き換えない限り変わりません。新しいAIの道具が入ったとき、既存の業務の道具にAIの機能が足されたとき、モデルが入れ替わったとき、それを台帳に書く手続きがどこにも無いのです。結果として、作った日の状態のまま、半年後には実態と合わない一覧が残ります。

一方で、個人情報の台帳は、業務の新設や委託先の変更のたびに、手続きの中で更新される仕組みになっている会社が多いはずです。AIを使う業務の多くは、個人情報を扱う業務と重なります。AIの台帳を、個人情報の台帳が開かれる手続きと同じ流れに載せれば、更新のきっかけを借りられます。同意管理の道具とAIの管理を「別物」と考えないほうがよい理由は、ここにあります。

同じ基盤で持つか、分けて持つか

AIの台帳の持ち方は、大きく3つです。表計算で別に持つ形、AIの管理に特化した別の道具を入れる形、すでに使っている OneTrust のような個人情報の管理の基盤で一緒に持つ形です。3つを、運用が続くかどうかに効く軸で並べます。

比べる軸	表計算で別に持つ	AI専用の別の道具	個人情報の管理の基盤で一緒に持つ
更新のきっかけ	人が思い出したとき	道具の受付の流れ	個人情報の手続きと同じ受付に載せられる
個人情報の台帳とのつなぎ	手で書き写す	連携の有無を確かめる	同じ基盤の中で結べるかを確かめる
承認の記録	メールやチャットに散る	道具の中に残る	道具の中に残る
未登録のAIの見つけ方	申告に頼る	道具の検出の範囲による	連携できる基盤の範囲による
費用の増え方	人の手間が増える	席や対象の数で増える	既存の契約に機能や対象の数を足す形で増える
やめたときに残るもの	表がそのまま残る	書き出せる範囲を確かめる	書き出せる範囲を確かめる

表で見ると、一緒に持つ形の強みは更新のきっかけを個人情報の手続きから借りられることに尽きます。逆に、個人情報の担当と情報システム部門の仕事の分け方が決まっていない会社では、同じ基盤に寄せても、誰も受付を見ない状態が移るだけです。

費用については、2026年10月時点で確かめた製品ページに金額の掲示はありませんでした。契約の単位が、対象にするAIの数なのか、利用者の数なのか、機能の組み合わせなのかを営業担当に確かめ、AIの数が増えたときにどう増えるかを、見積もりの段階で書面に残しておきます。

台帳に入れる単位を決める

項目を決める前に、台帳の1行を何にするかを決めます。OneTrust の製品ページでは、システム、モデル、エージェント、データセット、提供元、案件、使い道を台帳の対象とし、それぞれの依存関係を持たせると説明されています。ここで迷うのは、どれを行にし、どれを行に結びつく部品にするかです。

おすすめは、1行を「使い道」にし、モデル・提供元・データセット・エージェントを、その行に結びつく部品として登録する形です。たとえば「問い合わせの返信の下書き」という使い道の行に、使う対話のAIの製品、その提供元、読ませる問い合わせの記録を結びつけます。同じAIの製品を3つの部署が別々の使い道で使っていれば、行は3つになり、部品の製品は1つで済みます。

この形にしておくと、提供元の規約が変わったときに部品の側から影響する使い道を一度に引けますし、使い道ごとに持ち主を置けます。使い道の切り方とリスクの点の付け方は、AIのリスク評価を進める工程を扱った別の記事で整理しているので、ここでは台帳の単位の話にとどめます。部品だけを並べた一覧は、誰が何に使っているかが見えないため、承認にも棚卸しにも使えません。

エージェントの扱いには少し注意が要ります。エージェントは、複数の道具や社内のシステムにつながり、使い道を1つに絞れないことがあります。その場合は、エージェントを部品として登録したうえで、エージェントが触れる業務ごとに使い道の行を分けると、どの業務の持ち主が承認するかがはっきりします。MCP のサーバーそのものの台帳は、ToolHive を扱った別の記事で整理しているので、ここではエージェントを使い道に結びつける点だけを押さえておきます。

台帳に入れる項目一覧

1行を使い道にしたうえで、入れる項目を決めます。項目は多ければよいわけではありません。登録する人が答えられない項目を並べると、空欄のまま承認に回り、台帳の信頼が落ちます。次の12項目を基本にし、登録する人が書く欄と、承認する人が書く欄を分けます。

項目	書く中身	書く人
使い道の名前	何の業務の、どの工程に使うか	登録する部署
持ち主	使い道に責任を持つ部署と担当者	登録する部署
使うAIの部品	製品・モデル・提供元・エージェント	登録する部署
読ませるデータ	入力する情報の種類と置き場所	登録する部署
個人データの有無	扱う個人データの種類と、個人情報の台帳の該当業務	登録する部署（確認は個人情報の担当）
外に出る先	提供元への送信、学習への利用の有無、保存の場所	情報システム部門
出力の使われ方	社内だけか、顧客や社外に出るか	登録する部署
人の確認	出力を誰がどの段で確かめるか	登録する部署
リスクの区分	社内の物差しでの判定と理由	承認する人
承認者と日付	誰がいつ、どの条件で認めたか	承認する人
次の見直し日	期限と、見直しを早める変化	承認する人
止め方	使用を止めるときの担当と手順の置き場	情報システム部門

このうち、空欄のまま承認に回してはいけないのは、個人データの有無、外に出る先、人の確認の3つです。この3つが埋まらない使い道は、評価の前に差し戻します。反対に、規制の枠組みのどの条文に当たるかといった細かな対応は、最初の登録の段階では空欄でも構いません。承認する側が後から書き足せます。

個人情報の台帳とつなぐ列

項目の中で、同じ基盤で持つ意味が最も大きいのが「個人データの有無」の列です。個人情報の台帳には、業務ごとに扱う個人データの種類、利用の目的、委託先、保存の場所がすでにまとまっているはずです。AIの台帳でそれを書き直すのではなく、個人情報の台帳の該当業務を参照する形にしておくと、二重に書く手間と、書き写しのずれが消えます。

ただし、2026年10月時点の公開の製品ページでは、AIガバナンスの台帳と、同じ提供元の個人情報の台帳やデータの所在の台帳が、どのように結びつけられるかは詳しく説明されていませんでした。案内の上でも、同意の管理や個人情報の業務の自動化は、AIガバナンスとは別の解決策として並んでいます。同じ会社の製品だから自動でつながる、と思い込まないことが大切です。

導入を検討するときは、試用の段階で、AIの台帳の1行から個人情報の台帳の業務をたどれるか、個人情報の台帳の側で業務が変わったときに、関係するAIの行に知らせが届くかを確かめます。つなげられない場合は、少なくとも業務の番号を共通の鍵として両方に書き、片方を変えたらもう片方を見る手続きを決めておきます。個人データの置き場所そのものを洗い出す工程は、個人データの所在の台帳を扱った別の記事を参照してください。

誰が登録し、誰が承認するか

台帳の運用で最初に決めるのは、登録と承認の分担です。OneTrust の製品ページでは、受付・承認・利用者の確認・承認の署名の流れを組み、リスクと業務の文脈に応じて確認する担当に振り分けられると説明されています。ただし、業務の部署が自分で登録する形を想定しているかどうかは、公開の資料からは読み取れませんでした。分担は道具に任せず、社内で先に決めます。

次の4段で置くと、登録の負担と承認の質の釣り合いを取りやすくなります。

4段のうち、判定と承認は、AIにも道具の自動の区分にも任せないと決めておきます。自動の区分は、承認する人が見る順番を決める手がかりとして使い、結論は人が出します。承認する人が区分を変えたときは、変えた理由を必ず残すようにすると、後の監査や見直しで判断の筋をたどれます。

評価の物差しを規制のひな形に寄せすぎない

OneTrust には、欧州のAI法、米国の AI RMF、ISO/IEC 42001 に沿った評価のひな形が用意されています。海外の規制に対応する必要のある会社には、条文との対応を一から作らずに済む点で助かる機能です。

一方で、国内の会社がひな形をそのまま使うと、自社の業務に当てはまらない質問が並び、登録する部署が答えに困る場面が出てきます。まず自社の物差し（何が起きたら困るか、どこまでなら許せるか）を決め、ひな形はその物差しの抜けを探すために使う順番が現実的です。規格や枠組みそのものの読み方は、ISO 42001 や AI RMF を扱った別の記事で整理しています。

また、ひな形の質問に答えた結果は、規制に対応できたことの証明にはなりません。どの法令がどの使い道に当てはまるかの判断は、法務の担当者が原文に当たって決める工程として残します。台帳の上では、法務の確認が済んだかどうかと、その日付を残せば十分です。

未登録のAIをどう見つけるか

台帳の弱点は、登録されたものしか載らないことです。OneTrust の製品ページでは、変わり続ける環境の中でAIを継続して見つけ、正式な確認を経たかどうかを示すと説明され、シャドーAIの検出も掲げられています。連携先としては、Amazon の Bedrock、Azure のAI開発の基盤、Google の Vertex、Databricks とその Unity Catalog、Python で組み込む開発用の部品、MCP の環境などが挙がっています。

ここで押さえておきたいのは、見つけられる範囲は、つないだ基盤の範囲に限られるということです。自社のクラウドで作ったモデルやエージェントは連携で拾える見込みがありますが、社員が個人の判断で使い始めたウェブのAIの道具や、既存の業務の道具に後から足されたAIの機能まで拾えるかは、製品ページからは読み取れませんでした。検出の方法そのものの説明も、公開の資料にはありません。

そのため、検出の機能は、未登録の候補を挙げる下ごしらえとして使い、候補を台帳に載せるか、止めるかは人が決めます。社員の利用の見つけ方そのものは、許可外のAI利用の見つけ方を扱った別の記事で整理しています。検出で何も出なかったことを、未登録のAIが無いことの証明として扱わないことも、決めておきたい線です。

検出の機能が届かない範囲は、手続きで補います。購買の申請や経費の精算でAIの道具の名前が出てきたら台帳の受付に知らせる、業務の道具の更新でAIの機能が足されたら情報システム部門が受付に出す、といった形です。道具の検出と、購買や更新の手続きからの申告の2つの入口を持っておくと、片方の取りこぼしをもう片方で拾えます。

稼働中の監視まで同じ基盤に持たせるか

OneTrust のAIガバナンスは、台帳と承認にとどまらず、稼働中のモデルとエージェントの監視、指示文と出力のふるい分け、方針に反する動きの検知、Guardian Agents によるエージェントの見張りまでを製品ページに並べています。提供元の発表でも、台帳の管理から、稼働中の制御へと範囲を広げる方向が示されています。

ここは、台帳とは別の判断として切り分けたほうが安全です。稼働中の監視は、AIの通り道に部品を差し込む仕組みになるため、情報システム部門や開発の側の設計の問題になります。個人情報の担当が持つ台帳の延長で決めてよい話ではありません。まず台帳と承認の流れを回し、監視を足すかどうかは、自社で作ったAIやエージェントが増えた段階で、開発の側と一緒に判断します。

どちらを先にするにしても、台帳の行と、監視の対象が同じ名前で結びついていることが前提です。監視で問題が見つかったとき、どの使い道の、どの持ち主に知らせるかが台帳から引けなければ、監視の結果は宙に浮きます。

AIに任せる下ごしらえと、人が決める判定

台帳の運用は、手間のかかる作業の連続です。AIに手伝わせてよい作業は多くあります。たとえば、部署から届いた説明文から台帳の項目の下書きを起こす、提供元の規約や説明の資料から、学習への利用や保存の場所に関わる記述を拾い出す、といった作業です。

規制の条文と、使い道の説明との突き合わせの下読みも、AIに向いています。どの条文が関係しそうかの候補を挙げさせ、根拠になる原文の箇所を必ず示させます。未登録のAIの候補を、利用の記録や購買の記録から洗い出す作業も、下ごしらえとしては有効です。

一方で、次の判断はAIに任せません。リスクの区分の判定、承認と見送り、承認の条件、法令の当てはめ、止める判断です。AIの下書きを使った項目は、どこをAIが書いたかが分かるようにしておき、承認する人が原文に当たって確かめます。AIが拾い出した規約の記述も、提供元の原文と日付で確かめてから台帳に書きます。

AIに下書きを任せるときに見落としやすいのが、台帳そのものに書かれた情報をAIに渡してよいかという点です。台帳には、社内の業務の中身や、扱う個人データの種類、未公表の取り組みが並びます。台帳の下書きや突き合わせに使うAIも、台帳の1行として登録し、外に出る先と学習への利用の有無を確かめてから使う、という順番にしておくと筋が通ります。

棚卸しの間隔と、見直しのきっかけ

台帳は、定期の棚卸しと、変化をきっかけにした見直しの2本立てで回します。OneTrust の製品ページでも、モデル、エージェント、データセット、使われ方が大きく変わったときに再評価する考え方が示されています。

定期の棚卸しは、リスクの区分ごとに間隔を変えるのが現実的です。顧客や社外に出力が出る使い道や、個人データを扱う使い道は半年ごと、社内だけで使う下書きの用途は1年ごと、といった形です。棚卸しでは、使い道がまだ続いているか、持ち主が変わっていないか、部品の製品や規約が変わっていないかを確かめます。

棚卸しで見落としやすいのが、使われなくなった使い道の行です。試しに承認したまま誰も使っていない行が残ると、台帳の件数が実態より多く見え、見直しの手間だけがかかります。棚卸しのたびに、持ち主に「続ける・止める・条件を変える」のどれかを答えてもらい、止めた行は閉じた日付を付けて残します。消さずに閉じておくと、過去にどんな使い道を認めていたかを後からたどれます。

見直しを早めるきっかけは、台帳に書いておきます。たとえば、提供元の規約の変更、モデルの入れ替え、読ませるデータの追加、出力を社外に出し始めたとき、持ち主の異動です。これらを、個人情報の台帳の変更の手続きや、購買の手続きと同じ受付に載せておくと、思い出した人が書く台帳から、手続きが書かせる台帳に変わります。

台帳が止まる典型

同じ基盤で持っても、運用の決めごとが欠けていると台帳は止まります。よくある崩れ方を挙げます。

• 個人情報の担当と情報システム部門のどちらが受付を見るかを決めず、届いた登録が放置される
• 部品（製品）だけを並べた一覧にして、誰が何に使っているかが分からない
• 登録する部署に規制のひな形の質問を全部答えさせ、空欄のまま承認に回る
• 自動のリスク区分をそのまま結論にし、承認の理由が残らない
• 検出で見つからなかったことを、未登録のAIが無いことの証明として報告する
• 棚卸しの日だけを決め、規約の変更やモデルの入れ替えで見直す手続きが無い

どれも道具の機能では防げない崩れ方です。道具を入れる前に、受付を見る人、空欄で差し戻す項目、承認の理由の残し方を決めておくと、同じ基盤に寄せた効果が出やすくなります。

導入前に確かめる項目

すでに OneTrust を使っていて、AIの台帳まで広げるかを検討する場合は、試用か商談の段階で次の点を確かめます。英語の資料だけで判断せず、自社の実際の使い道を3〜5件登録して試すのが確実です。

• AIの台帳の1行から、個人情報の台帳の該当業務をたどれるか
• 個人情報の台帳の側の変更が、関係するAIの行に知らされるか
• 受付の画面と質問を、日本語で、自社の物差しに合わせて組めるか
• 承認の理由と、自動の区分を人が変えた記録が残るか
• 未登録のAIの検出が、自社で使っている基盤とウェブの道具のどこまでを拾えるか
• 契約の単位と、AIの数が増えたときの費用の増え方
• やめるときに、台帳と承認の記録をどの形式で書き出せるか

確かめた結果は、「できた」「できなかった」「書面で確かめる」の3つで記録し、個人情報の担当、情報システム部門、法務で共有します。できなかった項目を人の手続きで補えるかどうかが、同じ基盤に寄せるかの分かれ目になります。

よくある質問

OneTrust を使っていない会社でも、この項目一覧は使えますか

使えます。12の項目と、登録と承認の分担は道具に依存しません。表計算で始める場合も、個人情報の台帳の業務の番号を共通の鍵として書き、変更の手続きと同じ受付に載せることで、更新のきっかけを作れます。

ガートナーの評価が高いなら、選んでおけば安心ですか

評価の位置づけは提供元の発表で紹介されたもので、自社の業務に合うかどうかは別の話です。個人情報の台帳とのつなぎ方、日本語での受付の組みやすさ、費用の増え方を、自社の使い道で確かめてから判断します。

台帳を作れば、AIの利用規程は要りませんか

要ります。台帳は、何をどの条件で認めたかの記録で、社員が守る決まりそのものではありません。決まりの中身と置き場所は別に定め、台帳の承認の条件から決まりの該当箇所を参照する形にしておきます。

まとめ

OneTrust のAIガバナンスは、社内のAIを使い道・モデル・提供元・データとともに台帳にし、受付から承認、評価、稼働中の監視までを1つの基盤に寄せる機能です。すでに同意の管理や個人情報の管理で OneTrust を使っている会社には、手元の基盤を延ばす選択肢になります。ただ、台帳が止まる原因は列の不足ではなく、更新のきっかけを失うことです。1行を使い道にし、個人情報の台帳と同じ手続きに載せ、登録と承認の分担を先に決める。下書きや候補出しはAIに任せ、リスクの判定と承認は人が持つ。この順番で、同じ基盤に寄せるかどうかを判断してください。

• 製品の機能・連携先・評価のひな形は、OneTrust の公式の製品ページと解決策のページを2026年10月16日に確かめた範囲に基づきます。機能や条件は更新されることがあるため、利用前に最新の原文を確かめてください
• ガートナーの評価は、OneTrust の公式の発表（2026年6月22日）で紹介された内容です。法令の当てはめや個人情報の扱いは、実際の運用に合わせて法務の担当者と確かめてください

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