- 公開日
AI Control Libraryを運用に使うには、統制の名前を並べるだけでなく、何を防ぐために、誰が何を行い、どの証拠で確かめるかを一組にします。共通の統制カードと、用途ごとの適用記録を分けると、同じ対策を再利用しながら、適用しない理由や未確認の条件も残せます。カードが登録されていることと、その用途で対策が働いていることは別です。
対策の一覧があるのに責任が曖昧になる理由
「アクセス制御あり」「出典を付ける」「更新を管理する」という一覧だけでは、誰の権限で何を検索するのか、出典が誤っていたら誰が直すのかが決まりません。一覧を各部署がコピーすると、同じ名前なのに実施内容が違う、古い版だけが残る、といった問題も起きます。
ここでいう統制は、リスクを扱うために組み込むルール、技術的制約、確認手順などです。AI Control Libraryは、それらの目的と実施内容を共通化した一覧を指します。特定の製品名やプログラミング用ライブラリではなく、組織の管理記録として説明します。専用ツールがなくても、版と担当者を追える表や文書から始められます。
NISTのSP 800-53 Rev. 5は、情報システムと組織のためのセキュリティ・プライバシー統制を、柔軟に調整できるカタログとして提供しています。この考え方は統制を整理する参考になりますが、その全項目をすべてのAI用途へ一律に課すという意味ではありません。以下のカード名や記録様式は、本記事の設計例です。公式ページには2025年8月公開のRelease 5.2.0も案内されています。実際のカードへ規格を引用する際は、文書名だけでなく採用する版と該当箇所まで固定します。国内では、総務省・経済産業省のAI事業者ガイドライン（第1.2版）の別添7にあるチェックリストも、統制の候補を洗い出す際の点検観点として使えます。チェックリストの項目をそのままカードにするのではなく、用途ごとに適用するかを判断して記録します。
まず「どの問題を管理するのか」を決め、次に必要な対策を選びます。規程名を列挙するだけではなく、例えば「閲覧権限のない規程が検索結果や回答に現れる」という問題と「検索時の認可」を対応させます。こうすると、対象システムが変わった際も、同じ製品機能があるかより先に、同じリスクをどう扱うかを検討できます。
共通カードと用途の記録を分ける
共通カードには、複数の用途で使い回す目的、適用条件、実施内容、確認方法を置きます。用途の記録には、その用途に適用するか、実装先はどこか、具体的な担当者は誰か、何を確認したかを置きます。一つのセルへすべてを詰め込むより、共通の定義と現場の実態を対応させやすくなります。
カードの共通項目は、例えば次のように揃えられます。
| 項目 | 記録する内容 | 曖昧な記載を避けるための問い |
|---|---|---|
| 識別子と版 | 同じ統制を追える名前、版、改定日 | 用途側がどの版を参照しているか |
| 目的と対象リスク | 防ぎたい事象と影響する対象 | 「安全のため」より具体的に何を防ぐか |
| 適用条件 | 対象となる機能・情報・操作 | どの条件なら必要で、何が変わると再検討するか |
| 実施内容 | 設定、実行時の制約、人の確認 | いつ、どの境界で、誰が実施するか |
| 責任と実施主体 | 統制の責任者、設定・運用を行う役割 | 設定漏れや不合格を誰が是正するか |
| 確認証拠 | 設定記録、対象版、試験・運用記録の参照 | 何が確認でき、何までは分からないか |
| 不合格・未確認時 | 利用制限、照会、是正と再確認 | 確認できるまで何を保留するか |
| 見直し条件 | 機能、資料、権限、運用の変更 | 期限前でも再確認する変化は何か |
識別子は関連付けるためのものです。「認可第2版」と書いてあっても、実装が第2版に対応している証拠にはなりません。用途側の記録に設定対象と確認時点を残し、カードの更新と現場への反映を別々に追います。
責任者と実施担当者を同じ人が兼ねることはできます。ただし、問題が見つかったときに判断する役割と、日々の設定作業をする役割は記録上区別します。NISTのAI RMF Playbook・GOVERNも、役割、委任された権限、文書化と見直しを扱っています。役職名を置くだけでなく、その人が判断に必要な資料と権限を持つかが運用上の確認点です。
社内検索AIへ三つのカードを当てはめる
架空の会社が、従業員向けに社内規程を検索するAIを導入する場面を考えます。対象は全社員向けの旅費規程と、経理担当者だけが閲覧できる処理手順です。認証済みの利用者が自分に許可された文書を検索し、回答と参照箇所を受け取ります。決済、申請の承認、メール送信の機能は持たない前提です。
規程を取り込むサービス、保存先、利用目的については、組織の情報管理上の許可を確認していると仮定します。「社内にある資料」という理由だけで、任意のサービスへ入力できるわけではありません。ここでは許可された経路に対して、検索時の認可、出典表示、更新管理をどう対応させるかに絞ります。
| 共通カード | 目的と実施内容 | この用途での適用理由 | 担当と確認証拠の例 |
|---|---|---|---|
| 認可 | 利用者に許可された範囲に検索と情報提供を限定する。利用者の権限を検索先へ引き継いで検査する | 全社員向け文書と経理限定文書が混在するため適用 | システム担当が設定。権限対応表、検索条件の設定版、許可・拒否ケースの確認記録 |
| 出典表示 | 回答を根拠文書へ戻して照合できるようにする。文書名・版・該当箇所を回答へ付ける | 規程上の条件や例外を利用者が確かめるため適用 | 文書所有者が内容の是正を判断、回答設計担当が表示を実装。回答と原文の対応を確認した記録 |
| 更新管理 | 失効した規程の継続利用を抑える。適用日、取り込み版、旧版の扱いを管理する | 規程の改定と検索データの更新が別工程なので適用 | 文書所有者が改定通知と内容の是正を判断、運用担当が反映。改定通知、索引更新記録、反映後の照合記録 |
表の証拠は、導入前に揃えるものの例で、実際に試験した結果ではありません。「設定版」と「許可・拒否ケースの確認記録」を分けたのは、設定内容を読むことと、その設定で想定どおり処理されるか確かめることが違うためです。
認可とは、本人だと確認できたことに加え、その人が対象の情報や操作へアクセスしてよいかを判断することです。ログインできた社員だから全規程を見せてよい、とはなりません。検索文書、回答、参照リンクから権限外の内容を漏らさないよう、実際の経路に応じて制御を配置します。
OWASPのLLM06:2025 Excessive Agencyは、必要な権限に限定し、下流システムで認可を実施することを挙げています。「経理限定の資料を見せないで」というプロンプトだけに任せず、利用者の権限に合う取得範囲をシステムで強制する設計へつなげます。
出典表示にも限界があります。実在する文書のリンクがあっても、その文書が回答を裏付けるとは限りません。このカードでは「リンクが表示されたか」と「その箇所が回答の条件を支えるか」を分けて確認します。詳しい評価の手法をカードへすべて書き込む必要はありませんが、何を証拠として求めるかは省けません。
非適用と未確認を同じ欄にしない
用途別の記録では、少なくとも「適用」「非適用」「未確認」を分けます。適用は、その用途で必要と判断した状態であり、実装済みという意味ではありません。非適用は、対象条件に当たらないと根拠を持って判断した状態です。未確認は、必要な情報が足りず、どちらとも判断できない状態を示します。
社内検索AIに対する決済承認の統制なら、「読み取りと回答のみで、決済API・決済権限・決済処理への連携がない」と構成資料と権限設定から確認できた場合に、非適用と記録できます。「検索AIなので不要」とだけ書くより、後から何を確認し直すかが明確になります。
ただし、利用サービスの管理画面を見ておらず、決済連携があるか分からないなら未確認です。担当者へ設定資料を依頼し、確認できるまで決済機能を使う運用を認めない、と次の対応も記します。証拠がないことを機能がないことに置き換えません。
また「認可は共通基盤が担当している」場合も、認可を非適用にはしません。適用する統制の実施先が共通基盤にある、と記録します。その基盤がこの検索経路にも適用されること、利用者の権限が途中で失われないこと、担当者と確認記録へたどれることを確かめます。
費用や人員の都合でまだ実装できない対策も、非適用とは区別します。必要なら「適用・実装未完了」として、利用範囲の縮小、代替の手順、期限、承認者を残します。必要な認可の実装・作動が未確認なのに「低リスクだから後回し」として全社員へ開放する、といった扱いは避けます。検索対象を全社員向けの文書に限る場合だけ利用を認めるなど、条件を満たす範囲で適用する判断なら、「条件付き適用」として条件と見直しの契機を書きます。
一つの記録から判断と証拠をたどれる形にする
適用表と証拠の保管場所が別なら、参照を結びます。次は、社内検索AIの認可について、一つの用途別記録に残す内容の例です。資料名や版はすべて架空です。
| 記録項目 | 記入例 |
|---|---|
| 用途と対象版 | 社内規程検索・構成第3版、従業員アカウントで利用 |
| 統制と適用判断 | 認可カード第2版を適用。閲覧範囲の異なる規程が混在するため |
| 実施箇所 | 文書検索時の権限フィルター、回答に使用する文書の受け渡し箇所 |
| 責任者・実施者 | 情報システム責任者が是正判断、検索基盤担当が設定・反映 |
| 確認者と証拠 | 権限管理担当。権限対応表第4版、設定変更票、確認ケースの記録を参照 |
| 実装・確認の状態 | 設定反映済みという報告あり。拒否ケースの記録は未入手で、動作確認は未完了 |
| 未確認時の扱い | 権限境界を確認できるまで、経理限定文書を含む利用の開始を保留 |
| 次の判断 | 確認者が証拠を照合し、責任者が条件充足を確認して対象範囲の利用可否を決める |
ここで「反映済みという報告あり」は、動作確認済みとは書き換えません。証拠を入手したら、その対象版が現在の構成に一致するかを確認します。古い構成の合格記録があるだけでは、現在の構成の確認を終えたことになりません。
証拠の参照には、対象、版、確認日、確認者、結果を添えると追跡しやすくなります。どこかにログがあるという説明だけでは、その統制と何が対応するか不明です。一方、会話全文や機密文書を台帳へ複製する必要もありません。必要な記録へのアクセスを管理し、確認に必要な範囲を示します。
適用の判断者は業務責任者、技術的な確認者はシステム担当、情報の公開範囲は文書所有者、という分担も考えられます。これは組織設計の例であり、役割を分けた人数をそろえることが目的ではありません。担当が不在になったときの引き継ぎ先も含め、判断を止めたまま放置しない仕組みにします。
更新はカードと利用先の両方で確認する
カードの改定だけでは、利用先の設定は変わりません。どの用途が旧版を参照しているかを一覧にし、変更内容が各用途へ及ぶかを確認します。改定理由、影響する条件、対応する担当者、反映予定、確認結果を結ぶと、更新通知を送っただけで対応済みにする誤りを避けられます。
社内検索AIへ「経費を申請する」機能を追加するなら、読み取り専用だった前提が変わります。既存の認可・出典表示・更新管理に加え、申請対象と本人の権限、実行前の確認、結果不明時の扱いなどを再検討します。申請と決済が別なら、申請機能の追加だけで決済統制が適用になると決め付けず、実際の連携と権限を調べます。
同じように、規程の共有範囲変更、検索サービスの変更、認証方式の変更、事故や苦情も見直しの契機になります。非適用を判断した根拠が変わったときには、その判断をやり直します。定期点検の日程が決まっていても、重要な条件変更を次の点検日まで待つ理由にはしません。
一覧を増やし過ぎると、内容を読まずに印を付けるだけになり、運用担当の負担も増えます。まず実際の用途について、管理すべき問題と対策を対応させ、共通化できる部分をカードへまとめます。ただし、記録を小さくするために必須の制限や判断根拠を削ってはいけません。法令、契約、社内規程から必要になる統制は、その適用条件も確認します。
統制ライブラリの最初の成果物は、網羅的な対策集である必要はありません。一つの用途について、選んだ統制、選ばなかった理由、担当者、確認証拠、未完了時の扱いがつながっていれば、運用の抜けを具体的に話せます。その後は実態に合わせて更新し、記録の存在だけでなく実際の作動を別の点検で確かめていきます。
用途ごとのリスク区分の決め方と、区分に応じたプロンプト・権限の切り替えはAIの用途別リスク分類は、業務への影響から統制を選ぶで扱っています。AIエージェントに任せる範囲から動作確認までの順番はAIエージェントの安全設計で整理しています。
基本から確認する：この記事の前提になる考え方は、「AIを使う前の安全確認チェックリスト（AIKYで確かめる12項目）」にまとめています。
