生成AIの申請が増えるほど、承認者ごとの判断差が目立ちやすくなります。ある案件は通り、似た案件は差し戻される状態が続くと、現場も承認者も疲弊します。
生成AIの承認基準は、「承認」「条件付き承認」「差し戻し」「非承認」の4つの結果を、入力データ、外部公開の有無、人の確認の有無という3つの条件で決めると、承認者ごとの判断のずれを減らせます。公開情報だけを社内で使う申請は承認、顧客情報を使うが匿名化や人の確認を約束できる申請は条件付き承認、必要な情報が書かれていない申請は差し戻し、ルールで禁じたデータや用途を含む申請は非承認、というように条件と結果を対応させます。
要点
- 生成AIの承認基準は、承認、条件付き承認、差し戻し、非承認の4つの結果を分け、それぞれに当てはまる条件を決めておくと運用しやすくなります。
- 判定は入力データ、外部公開の有無、人の確認の有無の3条件で決め、禁じたデータや用途は非承認、情報不足は差し戻しと区別します。
- 条件付き承認の条件は、削除するデータ項目や最終確認者のように、守られたかを後から確認できる形で書きます。
承認基準の結論は「4つの判断結果を分けること」
申請が来たときの判断は、通すか止めるかだけではありません。すぐ承認できる案件もあれば、匿名化やレビュー条件付きなら承認できる案件もあります。情報が足りず差し戻す案件と、そもそも認めない案件もあります。
この4つを分けるだけで、承認の透明性が上がり、現場にとっても次に何を直せばよいかが分かりやすくなります。
承認か非承認かの二択で運用すると、「条件を付ければ進められる申請」まで非承認になり、申請者は何を直せばよいか分からないまま再申請することになります。条件付き承認と差し戻しを分けると、止める理由と進めるための条件が申請者に伝わります。
4区分の判断は、「入力データに個人情報が含まれるか」を最初の分岐点にすると整理しやすくなります。含まれない場合は承認の可能性が高く、含まれる場合は匿名化条件付き承認か差し戻しへ誘導します。この1点だけでも、承認者間の判断ばらつきを大幅に減らせます。
承認基準の役割は、止めることではなく、何を満たせば進めるかを明らかにすることです。
| 判断結果 | どういう状態か |
|---|---|
| 承認 | そのまま進めてよい |
| 条件付き承認 | 条件を守れば進めてよい |
| 差し戻し | 情報不足で再提出が必要 |
| 非承認 | 現時点では認めない |
どの条件ならどの結果になるかの具体的な判定例は、次の表で示します。
データ・外部公開・人の確認で決まる判定例
次の表は、入力データ、外部公開の有無、人の確認の有無の組み合わせごとに、どの判定にするかを示した記入例です。自社の利用ルールで決めたデータ区分に置き換えて使います。
| 申請の例 | 入力データ | 外部公開 | 人の確認 | 判定 | 判定の理由・付ける条件 |
|---|---|---|---|---|---|
| 公開情報をもとにした業界動向のまとめ | 公開情報 | 社内だけ | 利用者本人 | 承認 | 条件なし。出典を残すよう案内する |
| 社内規程を要約した社員向けFAQ | 社内資料 | 社内だけ | 規程の担当部署 | 承認 | 会社が契約したツールを使う |
| 商談メモをもとにした顧客向けメールの下書き | 顧客情報 | 特定の顧客 | 送信者本人 | 条件付き承認 | 会社が契約したツールに限る。送信前に宛先・金額・日付を確認する |
| 問い合わせ履歴を分析した改善レポート | 個人情報を含む履歴 | 社内だけ | 分析担当 | 条件付き承認 | 氏名・連絡先を除いてから入力する |
| 製品紹介のWeb記事の作成 | 社内資料 | 公開 | 広報の確認 | 条件付き承認 | 公開前に広報の確認を通し、数字には出典を付ける |
| 保存先とログの取得方法が書かれていない新ツールの申請 | 未記入 | 未記入 | 未記入 | 差し戻し | 入力するデータの区分、保存先、確認者を書けば再審査できる |
| 顧客向け資料の申請で最終確認者が申請者本人 | 顧客情報 | 特定の顧客 | 申請者のみ | 差し戻し | 申請者以外の最終確認者を書けば再審査できる |
| 取引先から預かった秘密情報を個人契約のツールに入力 | 取引先の秘密情報 | 社内だけ | — | 非承認 | 会社が管理できないツールへの入力は利用ルールで禁止 |
| AIの出力だけで採用の合否を決める | 応募者の個人情報 | 社内だけ | なし | 非承認 | 人の権利に関わる判断をAIの結果だけで決める用途は認めない |
条件付き承認の条件文の書き方
条件付き承認は、条件が守られたかを後から確認できる形で書きます。「注意して使うこと」のような曖昧な条件では、守られたかを確かめられません。
- 入力前に、氏名・メールアドレス・電話番号を削除すること
- 社外に出す前に、申請書に書いた最終確認者が内容を確認すること
- 申請書に書いた業務以外には使わないこと
- 生成物に含まれる数字には、元の資料の名前を付けること
承認時に見るべき5つの観点
- 入力データに個人情報や機密情報が含まれるか
- 出力用途が社内利用か顧客共有か公開か
- 保存先とログ取得が決まっているか
- 代替手段があり、AI利用の必要性が説明できるか
- 責任者と最終確認者が決まっているか
これらの項目を申請書でどう聞くかは生成AI利用申請書の作り方で整理しています。
この5観点は、承認フォームの必須項目として設計すると判断の標準化が進みます。特に「出力用途」は選択肢を「社内確認のみ」「顧客への共有」「外部公開」の3択にするだけで、承認者の見るべき重みが自動的に変わります。公開物の案件は法務確認を必須にするトリガーとして機能させると、見落としが減ります。
申請書の「最終確認者」の欄が空欄のままだと、誰が出力の責任を持つのかが決まりません。申請者本人が自己確認することを認めない設計にするだけで、責任の明確化が進みます。特に顧客向け資料では、一段上の上長が最終確認者になることを必須とする運用が有効です。
差し戻しと非承認を混同しない理由
差し戻しは、情報が揃えば再判断できる案件です。一方、非承認は現時点のルールでは許容しない案件です。この違いを明確にしないと、現場は『なぜ止まったのか』を理解できず、再提出の質も下がります。
条件付き承認を用意しておくと、完全に止めなくても安全側へ寄せる運用が取りやすくなります。
差し戻しの通知文には、「何が不足しているか」「どう修正すれば再審査できるか」の2点を必ず書くことが実務では重要です。「情報不足のため差し戻し」だけでは、申請者は同じ間違いを繰り返します。差し戻し通知のテンプレートを用意し、理由コード（例：D-01 入力データ区分未記入、D-02 保存先未確定）で分類すると、差し戻し率のモニタリングと改善が格段にやりやすくなります。
非承認が多い場合は、基準を変える前に、禁止しているデータや用途が利用ルールで伝わっているかを確認します。
承認基準を運用に載せる進め方
- 差し戻しが多い案件を先に集める。
- 判断理由を4区分へ分類する。
- 条件付き承認で使う条件文を定型化する。
- 月次レポートで承認率と差し戻し理由を見る。
- 四半期ごとに基準を更新する。
承認にかかった日数や差し戻しの理由を定期的に見る方法は、AI運用の承認フローで整理しています。
よくある質問
条件付き承認は甘い運用になりませんか？
条件を明文化して再確認する前提なら、むしろ完全な二択より運用しやすくなります。条件が守られたかを確認できる書き方にすることが前提です。
差し戻し理由はどこまで書くべきですか？
次回の再提出で何を直せばよいかが分かる程度まで書く方が、手戻りを減らしやすくなります。
承認基準は部門ごとに変えるべきですか？
基本の判断観点は共通化し、公開リスクやデータ区分が強く違う部門だけ補足条件を足す方が管理しやすくなります。
誰が承認基準を更新するべきですか？
事務局が運用データを集め、責任部門が最終更新を決める形が現実的です。
個人情報を含む申請は、すべて非承認にすべきですか？
すべてを非承認にする必要はありません。氏名や連絡先を除いてから入力する、会社が契約したツールに限る、といった条件で進められる申請は条件付き承認にします。会社が管理できないツールへの入力や、人の権利に関わる判断をAIだけで決める用途は非承認にします。
