不可逆化前の実効的人間拒否を既存レビューへ入れるために
Version: v0.1
Status: 実務補助資料 / 非公式・非認証・非安全保証
Scope: AI導入レビュー、調達確認、セキュリティレビュー、内部監査、事故・準事故レビューへの追加確認
目的
この文書は、LUMINA-30を既存制度の代替として提示するものではありません。既存のAIガバナンス、法務、監査、調達、セキュリティレビューの中に、LUMINA-30の中核条件を挿入するための実務用マップです。
中心となる確認は次の1問です。
このAI媒介プロセスが不可逆化する前に、責任ある人間は実効的に拒否・停止・保留できるか。その根拠となる権限・証拠・停止手順はあるか。
LUMINA-30を名指し採用しなくても、既存レビューにこの確認が明確に入り、実際に運用されるなら、LUMINA-30の中核条件は機能的に吸収されています。
これはLUMINA-30の失敗ではありません。中核条件が既存制度へ吸収された成功形です。
この文書は、EU AI Act、NIST AI RMF、ISO/IEC 42001、各組織のAIガバナンス、監査、調達、セキュリティ手順を否定・上書き・格下げするものではありません。具体的な法律条文番号、規格条項番号、義務内容を断定するものでもありません。以下は、代表的な挿入位置の例です。
1. このマップの使い方
このマップは、既存レビューを置き換えるためではなく、既存レビューの中に1問を挿入するために使います。
使い方は次のとおりです。
- 組織にすでにあるレビューを特定する。
- そのレビューの中で、不可逆化前の判断時点に最も近い場所を探す。
- 次の境界確認を追加する。
- 不可逆化前に、責任ある人間が拒否・停止・保留できるか。
- その人間は、必要な情報、権限、停止手順を持っているか。
- YES / NO / 不明 の根拠が記録されているか。
- YES / NO / 不明 を記録する。
- NO / 不明 の場合は、導入・接続・自動実行・権限拡張をそのまま不可逆化へ進めない。
このマップは、法務、監査、セキュリティ、調達、AIガバナンス担当者が、自組織の既存手順へ最小追加するための補助資料です。
ここで争うべき点は、「既存制度で十分か」ではありません。実務上の問いは、「既存制度のどこにこの確認を入れるか」です。
このマップの利用は、公式準拠、認証、安全保証、法的助言、またはLUMINA-30による安全確認を意味しません。
2. 既存レビュー別の挿入位置
| 既存レビュー | 通常確認されること | 追加すべき境界確認 | 記録すべき証拠 |
|---|---|---|---|
| AI導入レビュー | 利用目的、想定リスク、人間監督、承認プロセス、影響範囲 | AIが不可逆的な操作や判断へ接続される前に、責任ある人間が拒否・停止・保留できるか。<br>その時点は不可逆化の前にあるか。<br>判断者は必要な情報と停止権限を持つか。 | 承認フロー、停止手順、権限設定、ログ閲覧権限、YES / NO / 不明 判定結果 |
| 調達・ベンダー確認 | ベンダーの説明、セキュリティ対策、契約条件、データ取扱い、サポート体制 | AIが実行できる操作範囲は何か。<br>人間が承認・拒否できる時点はどこか。<br>緊急停止・ロールバック権限は誰にあるか。<br>ベンダー側の自動実行や権限変更が人間拒否を迂回しないか。 | 契約条項、管理画面設定、権限一覧、ログ仕様、緊急停止手順、ベンダー回答 |
| セキュリティレビュー | 認証、権限、ログ、外部接続、変更管理、インシデント対応 | AIエージェントが認証情報変更、本番操作、外部送信、削除、権限実行に関与する前に人間が止められるか。<br>停止が間に合う速度と経路があるか。<br>ログは事後説明だけでなく、事前判断に使えるか。 | 権限設定、監査ログ、停止テスト記録、ロールバック手順、通知・承認フロー |
| 内部監査・リスクレビュー | 手続き遵守、承認記録、リスク評価、責任分界、再発防止 | 「人間監督あり」が、不可逆化前の実効的拒否として機能しているか。<br>承認者は実際に覆せる立場にあるか。<br>NO / 不明 が放置されていないか。<br>YESの根拠が記録されているか。 | YES / NO / 不明 判定ガイドの記録、NO / 不明 対応シート、再確認期限、暫定措置、承認者・担当者記録 |
| 事故・準事故レビュー | 何が起きたか、影響範囲、原因、再発防止、責任分担 | 不可逆化前に止める機会はあったか。<br>その時点で誰が止める権限を持っていたか。<br>判断材料やログは利用可能だったか。<br>AI判断や自動処理が人間拒否を迂回していなかったか。 | タイムライン、承認・拒否・保留記録、ログ閲覧可否、権限設定、停止手順の有無、事故前の境界レビュー記録 |
3. 対象レビュー別の実務確認
3.1 AI導入レビュー
通常確認されることの例:
- 利用目的
- 想定リスク
- 人間監督
- 承認プロセス
- 影響範囲
追加すべき境界確認:
- AIが不可逆的な操作や判断へ接続される前に、責任ある人間が拒否・停止・保留できるか。
- その時点は不可逆化の前にあるか。
- 判断者は必要な情報と停止権限を持つか。
記録すべき証拠:
- 承認フロー
- 停止手順
- 権限設定
- ログ閲覧権限
- YES / NO / 不明 判定結果
3.2 調達・ベンダー確認
通常確認されることの例:
- ベンダーの説明
- セキュリティ対策
- 契約条件
- データ取扱い
- サポート体制
追加すべき境界確認:
- AIが実行できる操作範囲は何か。
- 人間が承認・拒否できる時点はどこか。
- 緊急停止・ロールバック権限は誰にあるか。
- ベンダー側の自動実行や権限変更が人間拒否を迂回しないか。
記録すべき証拠:
- 契約条項
- 管理画面設定
- 権限一覧
- ログ仕様
- 緊急停止手順
- ベンダー回答
3.3 セキュリティレビュー
通常確認されることの例:
- 認証
- 権限
- ログ
- 外部接続
- 変更管理
- インシデント対応
追加すべき境界確認:
- AIエージェントが認証情報変更、本番操作、外部送信、削除、権限実行に関与する前に人間が止められるか。
- 停止が間に合う速度と経路があるか。
- ログは事後説明だけでなく、事前判断に使えるか。
記録すべき証拠:
- 権限設定
- 監査ログ
- 停止テスト記録
- ロールバック手順
- 通知・承認フロー
3.4 内部監査・リスクレビュー
通常確認されることの例:
- 手続き遵守
- 承認記録
- リスク評価
- 責任分界
- 再発防止
追加すべき境界確認:
- 「人間監督あり」が、不可逆化前の実効的拒否として機能しているか。
- 承認者は実際に覆せる立場にあるか。
- NO / 不明 が放置されていないか。
- YESの根拠が記録されているか。
記録すべき証拠:
- YES / NO / 不明 判定ガイドの記録
- NO / 不明 対応シート
- 再確認期限
- 暫定措置
- 承認者・担当者記録
3.5 事故・準事故レビュー
通常確認されることの例:
- 何が起きたか
- 影響範囲
- 原因
- 再発防止
- 責任分担
追加すべき境界確認:
- 不可逆化前に止める機会はあったか。
- その時点で誰が止める権限を持っていたか。
- 判断材料やログは利用可能だったか。
- AI判断や自動処理が人間拒否を迂回していなかったか。
記録すべき証拠:
- タイムライン
- 承認・拒否・保留記録
- ログ閲覧可否
- 権限設定
- 停止手順の有無
- 事故前の境界レビュー記録
4. 既存フレームワークへの吸収文言
以下は、LUMINA-30という名称を出さずに既存レビューへ挿入できる文言です。組織内の用語、法務表現、監査様式に合わせて調整してください。
4.1 AI導入レビューへの挿入文言
本AIシステムが認証情報変更・本番操作・外部送信・削除・ロールバック困難化を実行する前に、責任ある担当者が承認・拒否・保留できる時点が設計上存在することを確認し、その権限の根拠と停止手順を記録する。
4.2 調達チェックへの挿入文言
ベンダーに対して、AIが実行できる操作の範囲、人間が承認・拒否できる時点、緊急停止・ロールバックの権限と手順、およびその証拠となるログ・設定・契約条項を開示させる。
4.3 セキュリティレビューへの挿入文言
AIエージェントが権限実行・状態変更・外部接続に関与する場合、不可逆化の前に人間が介入できる経路が実装されていることを、設計図・ログ設定・テスト記録で確認する。
4.4 内部監査・リスクレビューへの挿入文言
人間監督、承認者、監査ログ、停止手順が存在するだけでなく、それらが不可逆化前の実効的な拒否・停止・保留として機能した根拠を記録する。YES / NO / 不明 を判定し、NO / 不明 が残る場合は暫定措置、責任者、再確認期限を記録する。
4.5 事故・準事故レビューへの挿入文言
事故または準事故の発生前に、責任ある人間が介入できた時点、利用可能だった判断材料、停止権限、停止手順、ログ閲覧可否を確認する。人間拒否が形式上存在しただけで実効的に機能しなかった場合は、その理由を再発防止の対象として記録する。
5. 誤用防止
このマップは、以下を意味しません。
- LUMINA-30が既存フレームワークより優れている。
- LUMINA-30が公式標準である。
- LUMINA-30が法的準拠や認証を提供する。
- LUMINA-30を使えばAIシステムが安全になる。
- 既存制度はLUMINA-30なしでは機能しない。
- この確認を行えば事故が防げる。
- LUMINA-30確認済みであれば安全である。
- LUMINA-30の名称を使うこと自体が準拠、採用、承認を意味する。
このマップの目的は、既存制度の中に、不可逆化前の実効的人間拒否を確認する欄を追加しやすくすることです。
6. 実効的人間拒否・判定対応アドオンとの接続
このマップは、既存レビューのどこに境界確認を挿入するかを示します。YES / NO / 不明 の判定や、NO / 不明 への対応は、実効的人間拒否・判定対応アドオン側の資料へ接続します。
- YES / NO / 不明 の判定には、「実効的人間拒否 判定ガイド」を使います。
- NO / 不明 が出た場合は、「境界ギャップ対応シート」を使います。
- 外部説明には、「公開用・境界チェック宣言キット」を使います。
この接続により、既存レビューは次の流れになります。
- 既存レビューのどこに入れるかを、このマップで決める。
- 実効的人間拒否 判定ガイドで YES / NO / 不明 を判定する。
- NO / 不明 があれば、境界ギャップ対応シートで暫定措置・担当者・期限を記録する。
- 組織外に説明する場合は、公開用・境界チェック宣言キットの文例を使う。
7. 名称なしで吸収された場合の扱い
既存のAI導入レビュー、調達確認、セキュリティレビュー、内部監査、事故レビューに、次の確認が明確に入り、実際に運用されるなら、LUMINA-30の中核条件は名称なしで吸収されています。
このAI媒介プロセスが不可逆化する前に、責任ある人間は実効的に拒否・停止・保留できるか。その根拠となる権限・証拠・停止手順はあるか。
この場合、重要なのはLUMINA-30という名称の採用ではありません。重要なのは、不可逆化前の実効的人間拒否という条件が、形式的な人間監督や事後承認へ薄まらず、実務上の確認・証拠・対応手順として残ることです。