生成AIを例外的に使いたい。期限付きの申請をどう承認するか

生成AIの例外申請を、「便利そうだから使わせるか」「ルール違反だから止めるか」の二択で処理すると、判断根拠が残りません。例外が必要な事業上の理由と、通常ルールでは達成できない事情を確かめ、リスクごとの代替措置を置き、それでも残るリスクを会社が許容できる場合に限って期限付きで承認します。

承認時には、有効期限と廃止条件まで決めます。有効期限を、更新・条件変更・終了を判断し直す日に設定します。廃止条件も申請時に、停止権限者が事実に基づいて判定できる言葉で書きます。

理由、対策、期限、停止条件を別々の欄として埋めても、承認の筋道は見えません。四つを一行でつなぎ、「この理由に対して、この措置を守る間だけ認め、この条件になれば止める」と読める判断表が必要です。

生成AIの例外申請に必要な判断材料

例外申請の対象は、既存の社内ルールでは認められていない生成AIの利用です。審査の起点は、例外を認めなければ達成できない業務上の目的です。申請者は、対象業務、扱う情報、生成物の使い道、通常ルールで進められない理由、検討した代替案を一組で示します。

2026年9月21日時点で、NIST AI RMF PlaybookのGOVERN 1.4は、AI関連文書の対象として、事業上の正当化理由、利用範囲、想定リスク、前提と限界、検討した代替案、導入・監視・変更管理の計画を挙げています。また、同PlaybookのMANAGE 1.1〜1.3は、負のリスクと便益を正式に比較し、リスク許容度に照らして、低減・移転・回避・受容などの対応を計画し文書化する考え方を示しています。

以下の判断表は、これらの観点を例外申請一件の審査へ落とすための実務上の提案です。NISTの公式資料は、自社向けの承認様式まで定めていません。

例外の理由・代替措置・有効期限・廃止条件を結ぶ申請判断表

申請内容、審査者の確認、最終判断は同じ表に残します。承認者は、左の条件から右の判定まで因果関係が通っているかを読みます。

事業上の理由の強さとリスクの大きさは別軸です。リスクごとの措置を実行した後に残るリスクが、自社の許容範囲内かが境目です。範囲を超えるなら、経営上の期待が大きくても却下または再設計とします。

各項目を確認した後は、四つの条件を次の判断へ結びます。

承認の一行目に進めるのは、理由の妥当性、措置後の残余リスク、再審査の準備、停止可能性がすべて確認できた申請です。一項目でも評価不能なら、承認者が推測で補わず差し戻します。

条件付きの記入例：公開済み資料だけを扱う一時利用

次は、判断表のつながりを確認するための非数値の記入例です。特定製品の仕様や安全性とは切り離した例であり、実際の承認には対象業務に応じた審査が要ります。

この例で「公開済み資料だけ」という制限を外すなら、同じ承認を使い回せません。入力情報が変わると、想定リスクと代替措置の対応も変わるからです。「担当者が注意する」という表現は、履行確認に必要な具体性を欠きます。何を入力しないか、何と照合するか、どこへ記録するかまで明記します。

社内ルール側に入力情報、承認ツール、相談先の線引きがない場合は、先に生成AIの社内ルール・利用ガイドラインの作り方【テンプレート付き】を整理します。例外申請が扱う範囲は、通常ルールから外れる一件に限定します。

有効期限は「再審査に必要な記録」とセットにする

期限だけをカレンダーへ入れても、判断材料がなければ惰性で延長されます。申請時に、期限まで何を記録するかを決めます。

• 利用した対象業務と、当初の範囲からの逸脱
• 問題報告と、その対応状況
• 代替措置を実行した記録と、その有効性
• 業務、データ、利用するモデルなど前提条件の変化

これらを確認し、更新、条件変更、終了のいずれかを再決定します。記録がなく対策の有効性を確認できないなら、それ自体を無条件更新しない理由として扱います。

2026年9月21日時点で、NIST AI RMF PlaybookのGOVERN 1.5は、リスク管理プロセスと結果の継続的監視と定期レビューを計画し、役割・責任とレビュー頻度を明確にすることを示しています。NISTの生成AIプロファイルも、最低性能・保証基準、定期レビュー、台帳、必要時の無効化、リスク対策の有効性監視を推奨しています。実務では、有効期限をこのレビューが必ず起動する日として使います。

初めての導入段階で、試行対象と継続条件を整理したい場合は、AI導入は何から始めるべきか｜中小企業の最初の90日も判断の前段として参照できます。導入計画の期間と例外承認の期限は別に扱い、後者は対象業務のリスクと再審査に必要な材料に合わせて個別に決めます。

廃止条件は「重大な問題」より判定できる言葉にする

「重大な問題が起きたら停止する」では、発生時に重大性の議論から始まります。承認基準からの逸脱、代替措置の不履行、対象業務・データ・モデルの変更、期限切れのように、事実の有無で判定できる条件へ置き換えます。さらに、検知する担当者、停止を命じられる責任者、停止後の記録先を決めます。

2026年9月21日時点で、NIST AI RMF PlaybookのGOVERN 1.7は、安全に廃止・段階的停止する手続を設け、依存関係、保存要件、移行などを考慮することに加え、問題を受けて利用を修正・制限・停止できる責任者と権限の確認を示しています。NISTの生成AIプロファイルも、定義済みの限界を外れたモデルの廃止または再訓練と、導入後の監視計画に異議申立て、上書き、廃止、インシデント対応、復旧、変更管理を含めることを推奨しています。

申請時に終了の道筋まで書くことで、承認の前提が崩れた後に過去の決裁だけで利用が続く状態を防げます。

承認者が最後に残す結論

最終記録は「承認」「却下」だけで終わらせません。承認するなら、認める業務と情報の範囲、必須の代替措置、残余リスクを許容すると判断した責任者、有効期限、廃止条件、停止権限者を一続きで残します。却下または再設計なら、どのリスクが許容範囲を超え、どの条件を変えれば再審査できるかを返します。

生成AIの例外申請では、「使いたい理由」に加えて、その理由に対応する措置を実行できるか、期限時に再判断できる記録が残るか、前提が崩れたときに止められるかを問います。四つの条件を判断表で結び、残余リスクを許容できる一件だけを期限付きで承認する。これが、通常ルール全体を曖昧にせず、必要な例外だけを管理する基準になります。