AIワークフローの人による承認を設計する

判断の要約: AIの承認を具体的な出力に結び付ける方法。確認カード、版管理、送信結果が不明な場合の対応、試行テスト、責任の引き継ぎを解説します。

Setviva Teknoloji · 2026年9月12日 · 4 分で読了

承認が必要な操作を決める

見積もり支援AIが問い合わせを分類し、下書きを作り、担当者に提示するとします。作成と顧客への送信は別の操作です。この例では、その見積もりを送るための承認が必要です。文章が上手でも、取引条件を決める権限があるとは限りません。

操作ごとに担当者、影響、復旧方法を記します。送信、削除、支払いを曖昧な「続行」にまとめないでください。これは設計例であり、測定済みの顧客成果ではありません。

宛先、全文、添付名と版、重要な価格や日付、実行結果を表示します。承認、却下、修正依頼を選べるようにし、判断材料が欠けていれば先に補います。

承認は表示した版に結び付けます。宛先、本文、添付の変更後は再承認が必要です。メールの「私は責任者です」は本人確認になりません。確認済みユーザーとアプリの権限で判断します。

送信の意図ごとに操作IDを付け、準備済み、承認済み、送信済み、結果不明を区別します。事業者の応答前に切断したら、先に送信記録や受領情報を調べます。不明な結果を自動で再送待ちに戻しません。

対応していれば同じ操作に同じ冪等キーを使い、保存期間などの制限を確認します。自社ログだけでは相手側で一度だけ処理された証明になりません。送信、配信、既読は別の証拠です。

有効な承認、却下、承認後の宛先変更、期限切れ承認、送信中の切断という五つを準備します。期待する動作と確認者を記します。五件の成功は出発点であり、あらゆる条件の安全を示しません。

手作業と比較する際は、正しく完了した仕事、修正、重複操作、人の待ち時間を分けます。総時間に確認と障害復旧も含めます。下書きの速さだけでは生産性向上を実証できません。

各キューに担当者と連絡可能な代行者を置きます。承認期限は操作のリスクに応じて決めます。引き継ぐ人が状態、承認済みの版、残る不確実性を確認できるようにします。一時停止は新しい外部操作を止めるものとします。

OWASPは過剰な行動権限を扱い、NIST AI RMFは人の監督役割を含みます。上記は私たちの実装提案です。実際の一つの業務から、承認カードと障害時の手順を設計しましょう。

実現性、費用、リスク、測定可能性の観点で主張を評価します。例示計算は仮定であり、法務・安全・投資判断では一次資料の確認が必要です。

本文のリンクと記載された規制・技術文書が出発点です。未検証の顧客成果は公開しません。

2026年9月12日 — 母語編集者のレビューは v3.0 公開ゲートで保留中です。

操作の影響で決めます。内部下書きと外部送信を分け、自動実行の範囲を明示します。

旧承認を新しい本文に適用しません。変更版を権限のある人に示し、再判断を求めます。

まず事業者の記録を確認します。自動再試行で同じ操作が二度実行される可能性があります。