AI運用の承認フローとは？承認者・期限・差し戻しの記入例で設計する
AI活用が広がるほど、「誰がどこで確認するのか」が曖昧なまま運用されやすくなります。最後にまとめて上長確認を入れるだけでは、レビュー待ちが詰まり、現場は結局個別運用へ戻りがちです。
AI運用の承認フローは、1回の大きな承認ではなく、「入力データ」「設定・プロンプト」「生成結果」「実行前」の4段階に分け、申請の種類ごとに必要な段階だけを置くと機能します。各段階には、承認者、回答期限、差し戻しの条件、例外のときの記録を決めておきます。社内メモの要約なら生成結果の確認だけ、顧客への一括送信なら入力データ・生成結果・実行前の3段階、というように、取り消しにくい操作ほど段階を増やします。
本記事のポイント
- AI運用の承認は、入力データ、設定・プロンプト、生成結果、実行前の4段階に分け、申請の種類ごとに必要な段階だけを置くと機能します。
- 各段階には、実際に判断できる承認者と代理、回答期限、差し戻しの条件を決め、差し戻しには何を直せば再申請できるかを書きます。
- 例外で進めた場合は、飛ばした段階、理由、代わりの確認者、事後確認の期限を記録し、同じ理由が続けば通常フローを見直します。
承認フローは「誰が何を見て止めるか」を分けるほど機能する
同じ承認という言葉でも、見ているものは異なります。入力データが適切か、プロンプトや設定が妥当か、生成結果が正しいか、実際に送信・公開してよいかは別の論点です。
これらを一つのレビューに押し込むと、確認者の負担が増え、責任も曖昧になります。営業やマーケのAI運用では特に、導入手順 と 運用定着 の中で、どの段階にどの承認を置くかを決めておくと定着しやすくなります。データの確認と表現の確認は見る人の専門が違い、設定の誤りは出力を見ても気づきにくく、送信や公開は取り消せないため、段階を分けます。
たとえばAIでメール文面を作る場合、生成結果だけを確認していると、元にした顧客リストが誤っていても気づけません。文面が自然に見えても、入力データが違えば別の顧客の情報を含んだメールが送られる可能性があります。入力データを確認する段階を別に置くのは、このような見落としを防ぐためです。
承認フローの4段階を全業務に一律適用する必要はありません。社内メモ作成なら「生成結果」の確認のみ、顧客向けメール送信なら「入力データ」「生成結果」「実行前」の3段階、プレスリリースや公開Webコンテンツなら全4段階という優先度設計が現実的です。事故コストに比例して承認段階を増やすイメージで設計すると、現場の負担と安全性のバランスが取りやすくなります。
| 承認段階 | 確認内容 | 向いている承認者 |
|---|---|---|
| 入力データ | 使ってよいデータか、匿名化が必要か | データ責任者、部門管理者 |
| 設定・プロンプト | 意図した出力になる条件か | 運用責任者、AI推進担当 |
| 生成結果 | 内容や表現に問題がないか | 実務担当、レビュー担当 |
| 実行前 | 送信・更新・公開してよいか | 最終責任者 |
承認の回数を増やすことより、事故コストの高い地点に適切な承認を置くことの方が重要です。
承認フロー設計における業務別リスク分類
承認フローを適切に設計するには、業務ごとの「事故コスト」を先に分類することが有効です。事故コストは「影響範囲の広さ」と「回復のしにくさ」の2軸で評価できます。顧客送信メールは送信後に取り消せないため回復しにくく、受信者が数百名なら影響範囲も広い。これは事故コストが最も高い領域です。一方、社内Slack投稿の要約は誤りがあっても訂正が容易で影響範囲も限定的です。
どの業務を自己判断にし、どの業務を要申請や禁止にするかは、AI活用範囲のマトリクスで先に決めておきます。承認フローでは、その分類に応じて、どの段階に承認を置くかを決めます。
申請内容別の承認フロー記入例
次の表は、よくある申請の種類ごとに、どの段階で誰が確認するかを書いた記入例です。承認者は肩書きではなく、実際に判断できる人を置き、不在時の代理も決めておきます。回答期限の日数は、自社の業務の速さと配信・公開の予定日から逆算して決めます。
| 申請内容 | 置く段階 | 承認者（代理） | 回答期限の決め方 | 差し戻しの条件 |
|---|---|---|---|---|
| 社内会議の議事録要約 | 生成結果 | 会議の主催者 | なし（利用者が自分で確認） | 差し戻しなし。誤りは利用者が直す |
| 顧客への個別メールの下書き | 生成結果 | 送信する担当者本人（上長は抜き取り確認） | 送信前 | 顧客名・金額・日付が元データと合わない |
| 顧客リストへの一括メール送信 | 入力データ → 生成結果 → 実行前 | 入力データ: 部門のデータ責任者／生成結果: 担当者／実行前: 部門長 | 配信予定日から逆算し、段階ごとに決める | 配信リストの抽出条件が書かれていない、配信停止者が除かれていない、テスト送信の結果がない |
| Webサイト・プレスリリースの公開 | 入力データ → 設定・プロンプト → 生成結果 → 実行前 | 入力データ・生成結果: 広報担当／設定: AI推進担当／実行前: 広報責任者（法務は条件付き） | 公開予定日から逆算し、法務確認の時間も含めて決める | 出典のない数字や事例がある、他社名・製品名の扱いを法務が確認していない |
| CRMの一括更新を行う自動処理 | 設定・プロンプト → 実行前 | 設定: CRM管理者／実行前: 営業企画責任者 | 実行予定日から逆算して決める | 更新対象の件数と項目が書かれていない、元に戻す手順がない |
| 新しいAIツールや外部連携の追加 | 入力データ → 設定 | 情報システム部門（個人情報を含む場合は個人情報保護の責任者も） | 情報システム部門の審査期間に合わせて決める | 入力するデータの区分、保存先、ログの取得方法が書かれていない |
差し戻すときに書くこと
差し戻しは「不可」ではなく「直せば進められる」状態です。申請者が同じ誤りを繰り返さないよう、差し戻しの連絡には次の3点を必ず書きます。
- どの段階で止めたか（入力データ／設定・プロンプト／生成結果／実行前）
- 何が足りないか（例：配信リストの抽出条件が書かれていない）
- 何を直せば再申請できるか（例：抽出条件と除外条件を追記し、テスト送信の結果を添付する）
差し戻しと非承認の分け方、条件付き承認の条件文の書き方は、生成AIの承認基準で整理しています。
例外で進めたときの記録
急ぎの顧客返信や障害時の告知など、通常の段階を飛ばして進める場面は必ず出てきます。例外を禁止するより、例外で進めたことを後から確認できるよう、次の項目を記録します。
| 記録する項目 | 記入例 |
|---|---|
| 日時と申請者 | 送信した日時と、申請した担当者の部署・氏名 |
| 飛ばした段階 | 実行前の部門長確認 |
| 例外にした理由 | 障害のお知らせを当日中に送る必要があったため |
| 代わりに確認した人 | 同じチームのリーダー |
| 事後確認の期限と担当 | 本来の承認者が、いつまでに送信内容を確認するか |
| 再発時の扱い | 同じ理由の例外が繰り返されたら、通常フローの段階や期限を見直す |
例外の記録が同じ理由で続く場合は、例外ではなく通常フローの設計に問題があると考え、段階や期限を見直します。
承認フロー運用で見るべき指標
承認フローは重くしすぎると定着しません。安全だけでなく、レビュー滞留も一緒に見る必要があります。
| 指標 | 意味 | 見方 |
|---|---|---|
| 承認リードタイム | 依頼から承認までの時間 | 長すぎるなら分担が重い |
| 差し戻し率 | 承認前の不備の多さ | どの段階で多いかを分けて見る |
| 公開後修正率 | 承認精度の不足 | 承認が形骸化していないかを見る |
| 例外承認件数 | 通常フロー外の多さ | 設計漏れを示すことが多い |
| 利用継続率 | 現場がフローを守っているか | 重すぎると利用が落ちる |
AI運用の承認フローを作る手順
ステップ1. 承認対象を分解する
まずは入力データ、設定、出力、実行の4つに分け、何を確認するかを書き出します。承認対象を分けるだけで、誰に何を頼むべきかが見えやすくなります。
ステップ2. 事故コストの高い操作を特定する
顧客送信、サイト公開、CRM更新、価格判断のように、誤りの影響が大きい操作に優先して承認を置きます。軽い下書きまで同じ強さで止める必要はありません。どの業務を要申請にするかの線引きは、活用範囲のマトリクスで決めた分類を使います。
ステップ3. 承認者を実務に合わせて決める
肩書きだけで承認者を置くと、忙しい時に止まります。実際に判断できる人、または代替できる人に寄せてフローを作る方が現実的です。
ステップ4. 差し戻し理由を蓄積して見直す
承認フローは作って終わりではありません。差し戻し理由が同じなら、テンプレートやプロンプト、入力条件を修正して再発を減らしていく必要があります。
承認フローで失敗しやすいポイント
最後にまとめて全部確認する
確認対象が多すぎると、レビュー品質が落ちます。承認は分散した方が実務では機能します。
承認者が実務を知らない
ルールだけ知っていて現場を知らない人が承認すると、差し戻しが増えて利用率が下がります。確認の観点ごとに担当を分ける方が自然です。
例外時の処理がない
緊急時の扱いがないと現場はフロー外で動くため、上の「例外で進めたときの記録」を先に決めておきます。
よくある質問
プロンプトも承認対象に入れるべきですか？
影響の大きい業務では入れるべきです。少なくともテンプレート化されたプロンプトや接続設定は、初回レビューしておく方が安全です。
承認者が多すぎると現場が止まりませんか？
止まります。段階ごとに確認する人を1人に絞り、不在時の代理と回答期限を決めておくと、承認待ちで止まりにくくなります。
軽いメモ作成にも承認は必要ですか？
通常は不要です。事故コストが高い送信、更新、公開のような操作に絞る方が現実的です。
承認フローはツールで自動化できますか？
一部はできますが、まずは誰がどこで止めるかを決めるのが先です。設計が曖昧なまま自動化すると形骸化しやすくなります。
回答期限を過ぎたら承認したものとみなしてよいですか？
社内メモなど取り消しやすい作業なら、期限切れで進める運用もありえます。顧客への送信や公開のように取り消せない操作では、期限切れで進めず、代理の承認者に回す方が安全です。
