AIワークフローの人間承認ゲート：実践的な7つの設計

本当のゲートを定義し、形だけの承認を排除する

ゲートは状態遷移を技術的に止める

有効な判断が存在するまで、対象動作に必要な資格情報、判断トークン、状態遷移をワークフローが取得できない構造にします。モデルが実行可能なツールを保持したままなら、プロンプトで「承認を待つ」と指示しても強制力はありません。

通知はゲートではない

メッセージ送信、ダッシュボード表示、リアクション依頼だけでは何も止まりません。通知到達、承認者の確認、構造化された判断、実行認可は別々のイベントとして扱います。

人の確認が常に十分な情報に基づくとは限らない

承認者には、正確な効果、重要な証拠、不確実性、代替案、制限が必要です。変更を隠す画面、過負荷なキュー、流暢な要約だけの表示は、確認を追認作業に変えてしまいます。

承認があっても禁止される動作はある

承認は法令、同意、データ主体の権利、契約、技術権限、組織方針を上書きできません。ゲートは許された判断経路を統制するもので、禁止動作を許可に変える仕組みではありません。

監査可能な承認記録を作る

判断対象

正確な動作、対象、パラメータ、内容、金額、宛先、添付の版または暗号学的ダイジェストを保存します。同値は同じ表現になり、意味のある変更は検出できる正規化規則を定めます。

承認者の権限

承認者の本人性、認証セッション、現在の役割、範囲、委任元、相反検査、定足数上の位置を記録します。秘密情報自体は保存せず、権威あるID・方針判定を参照します。

証拠パケット

参照元、検証結果、リスク、可逆性、代替案、未解決の不確実性、関連方針、予想される下流影響を示します。機密証拠にはアクセス制御を設け、承認者が実際に見た版を記録します。

判断のライフサイクル

承認、却下、修正要求を理由、時刻、期限、取消とともに扱います。修正要求は準備状態へ戻し、古い判断対象を無効にします。既存承認の裏で対象を編集してはいけません。

実行との連結

ブローカーは対象ハッシュ、権限、有効性、未使用状態を検証してから一つの動作を解放します。操作IDと権威ある状態を照合し終えて初めて、承認を履行済みにします。

利便性ではなく結果の重大性からゲートを選ぶ

影響と不可逆性を評価する

情報開示、対外連絡、金銭、雇用、アクセス、法務、セキュリティ、運用への影響を明示的に分類します。損害が大きく元に戻しにくいほど、早い段階で強いゲートが必要です。

決定論的な境界と人の判断を分ける

金額上限、宛先集合、スキーマ、本人性、期限、役割相反はコードで検査します。人は方針が委任した文脈判断を担います。システムで強制できる統制を承認者の注意力で補わせてはいけません。

審査能力と遅延コストを測る

処理できないほど大きなキューは、迂回や機械的承認を招きます。到着率、確認時間、担当範囲、ピーク負荷、安全な期限を見積もり、低リスク業務ではしきい値型や例外型を検討します。

十分な中で最も単純なパターンを選ぶ

設計時の手動確認（manual）から始め、ネイティブ機能（native）や決定論的フローへ進み、その後に統制された自動化（automation）とAIエージェント（agent）による証拠準備支援を追加します。権限と状態遷移を説明できる場合だけ複数パターンを組み合わせます。

パターン1：実行前承認

適する場面

規制対象の連絡、重要アクセス変更、資金確約、顧客に見える判断など、不可逆・外部向け・機密・高影響な動作に適します。権限ある判断が記録されるまで実行不能にします。

前提条件

判断対象、承認役割、証拠、選択肢、期限、取消、下流ブローカー、失敗経路を定義します。重要な全フィールドと添付を承認者が確認できなければなりません。

技術的な強制

実行資格情報または状態遷移をモデルの外に置きます。承認後、対象ハッシュ、依頼者、ツール、テナント、期限に結び付いた一回限りの認可を発行・検証します。

承認者の体験

提案動作と予想効果を先に、リスク、証拠、不確実性、代替案を続けて示します。準備後の変更を強調し、承認だけでなく却下と修正要求を安全に選べるようにします。

主な失敗

要約は正しくても、隠れたペイロード、宛先、添付が異なる、または承認後に書き換えられる失敗です。ハッシュで固定し、重要な変更後は新しく審査します。

停止・エスカレーション条件

対象を正規化できない、権限元が利用不能、証拠不足、リスクが範囲外、実行状態が不明なら停止し、統制責任者へ引き上げます。

パターン2：決定論的しきい値承認

適する場面

金額、件数、データ区分、地域、対象者、リスク等級で方針を表せる反復動作に適します。境界内は継続し、越えた場合だけ権限者を待ちます。

前提条件

しきい値に正式な方針、版、適用範囲、所有者を持たせます。集計期間、通貨、単位、境界値の扱い、欠損値、競合規則を明記します。

技術的な強制

信頼できる実行層でしきい値を計算し、モデル自身に「上限内」と宣言させません。入力不足、方針競合、計算失敗は安全に停止します。

承認者の体験

発火した規則、観測値、しきい値、計算期間、情報源を示します。承認者は機械的計算をやり直すのではなく、例外を認める文脈を判断します。

主な失敗

一回の金額だけを見て、累積、関連対象、短時間の分割を見逃すことです。集約軸と回避防止規則を加えて修正します。

停止・エスカレーション条件

方針版が不明、単位比較不能、意図的な分割、関連対象の解決不能、リスク分類の変更があれば停止し、方針所有者へ送ります。

パターン3：例外時だけの承認

適する場面

検証済みで境界が明確、通常経路が反復的なフローに適します。構造検証失敗、低い確信、方針競合、新分類、結果の逸脱だけを人のキューに送ります。

前提条件

説明可能な正常範囲、例外トリガー、基準サンプル、監視指標、退避経路を用意します。例外検出自体にも版、試験、誤検知レビューが必要です。

技術的な強制

実行前に決定論的チェッカーまたは統制された検出サービスですべてのトリガーを評価します。検査欠落、タイムアウト、不明は例外として扱います。

承認者の体験

最初に「なぜ例外か」を示し、正常基準、差分、証拠、対応候補を続けます。一回の承認で恒久的に方針を書き換えないようにします。

主な失敗

モデルの確信スコアだけを使い、自信のある誤りを正常扱いすることです。業務規則、データ完全性、権限、ドリフト、結果照合を組み合わせます。

停止・エスカレーション条件

例外率急増、基準失効、分類器・ツール版変更、キュー容量超過、不明状態の蓄積があれば自動経路を止め、再検証します。

パターン4：二者承認

適する場面

一人の誤りや不正が深刻な結果を生む動作に使います。独立し資格を持つ二人が、同じ対象について別々に判断しなければなりません。

前提条件

必要な役割の組合せ、独立性、順序、拒否権、代行、期限、修正要求後の状態を定義します。二つの承認枠は同じ対象版を参照します。

技術的な強制

ブローカーが異なる有効な二つの本人性、役割資格、相反規則、対象ハッシュ、未取消判断を検証します。二人目が、一人目の見た対象を上書きしてはいけません。

承認者の体験

各承認者に完全な証拠を示し、他者判断の可視範囲を決めます。同調を避ける必要がある場面では、二人目が独立判断を提出するまで一人目の結論を隠します。

主な失敗

共有アカウント、同じ委任本人、同一支配者が二つの枠を埋めることです。ユーザー名だけでなく、有効な支配関係を比較します。

停止・エスカレーション条件

独立性を証明できない、判断が対立、いずれかが期限切れ・取消、対象変更、定足数不足なら停止を維持し、指定された裁定者へ送ります。

パターン5：職務分離承認

適する場面

アクセス変更、支払い、機密データ出力、重要設定の公開など、依頼、準備、承認、実行を同じ有効支配者が完結してはいけない場面に適します。人数より、相互牽制する責務が重要です。

前提条件

誰が起案、証拠準備、承認、実行、結果照合を担えるか役割表を作ります。委任、一時役割、サービスアカウント、所属、利益相反を有効本人性モデルへ含めます。

技術的な強制

判断時と実行時に、依頼者、対象作成者、承認者、実行本人を方針エンジンが比較します。禁止された組合せは拒否し、自己申告に頼りません。

承認者の体験

なぜ当該承認者が適格か、どの参加者が分離されるか、委任・代行があるかを示します。相反警告は対処可能にしつつ、不要な個人情報は開示しません。

主な失敗

アカウントIDだけを比較し、同じ人が複数アカウントや委任を使う状況を見逃すことです。AG096のD23はこの拒否条件に失敗したため、演習全体を有効化できません。

停止・エスカレーション条件

有効支配関係が不明、ディレクトリ同期が古い、委任が循環、緊急権限が未審査、相反方針を評価不能なら動作を止め、ID・統制責任者へ送ります。

パターン6：時間・条件を限定した承認

適する場面

保守時間帯、一時的データアクセス、上限付き公開、暫定例外など、短い期間、特定環境、固定上限、参照状態だけで有効な動作に使います。

前提条件

開始・終了、タイムゾーン、許可条件、最大使用回数、状態版、取消トリガー、期限後の安全状態を定義します。時計と条件情報源は信頼でき、監査可能でなければなりません。

技術的な強制

実行時に時間、条件、対象版、認可状態、使用回数を再検証します。承認時のスナップショットだけを信じず、期限切れや条件変更後はトークンを使用不能にします。

承認者の体験

開始、終了、許可動作、最大回数、即時失効条件を明確に示します。無期限の例外を「一時承認」として見せてはいけません。

主な失敗

参照状態が変わった後も承認を利用する、またはタイムゾーン不一致で期間が延びることです。AG096のD36は変更後のペイロードへ古い承認を使った二つ目の拒否条件違反です。

停止・エスカレーション条件

時計不整合、条件元停止、版不一致、使用回数不明、取消未伝播、境界外要求なら実行を拒否し、新しい承認を求めます。

パターン7：限定され可逆な作業の実行後検証

適する場面

低リスク、上限付き、観測可能、確実に戻せる動作だけに使います。実行前の許可ではなく、逸脱を早く見つけ、次の自動化を止め、回復へ進む監督パターンです。

前提条件

小さいバッチ上限、許可範囲、完全ログ、権威ある結果確認、取消方法、自動停止しきい値、審査期限を定義します。本当に戻せない動作には使えません。

技術的な強制

各動作は決定論的方針を満たし、操作IDを持ちます。件数、時間、リスクで確認を発火し、期限超過、異常、取消失敗時には残りを自動停止します。

承認者の体験

予測要約ではなく実結果、差分、影響対象、回復状態、次バッチ範囲を示します。受容、修正、ロールバック、範囲縮小、停止を選択可能にします。

主な失敗

期限、停止、回復のない「後で誰かが見る」を事後ゲートと呼ぶことです。審査結果を次バッチの解放に結び付け、連続実行を防ぎます。

停止・エスカレーション条件

不可逆な影響、取消失敗、異常率超過、権威ある結果の読取不能、審査滞留、リスク上昇があれば直ちに止め、実行前承認へ切り替えます。

完全な架空承認ゲート演習：AG096

固定したシステムと42の判断対象

Meridian Workshop GroupのHarbor Gateチームが、顧客、決済、本番ID、実外部システムにつながない架空環境で7パターンを評価しました。A11、GP06、ID08、DO04、AS03、EB05、K04、X01–X07、RG03を固定し、D01–D42を各パターン6件ずつ割り当てました。

ライフサイクル、審査、拒否条件違反

データには63のライフサイクルイベントと42の人手審査があり、34件合格、8件失敗です。D23は同じ委任本人による職務分離違反を許し、D36は重要変更後に古い承認を使いました。どちらも必須の拒否条件です。

ダウンロードとリリース状態

最終状態はNOT_ENABLED、外部副作用は0です。これは教育用テストデータで、顧客結果、認証、ベンチマーク、OpenMax性能測定ではありません。日本語ワークシートと日本語AG096証拠パケットをダウンロードできます。

AG096の7指標を再計算する

ペイロード結合完全率：38/42 = 90.48%

全42対象のうち、審査対象と実行対象が正確に一致した38件を分子にします。隠れた変更や古い対象の利用を失敗として残し、未完了を分母から除外しません。

権限検証通過率：37/42 = 88.10%

37件が判断時に現在の本人性、役割、範囲、委任、相反を通過しました。残る5件は、キュー開始時だけの権限検査が不十分であることを示します。

期限強制率：9/10 = 90.00%

期限・条件境界用に事前指定した10件のうち9件を正しく停止または再承認へ送りました。この指標の分母は全42件ではなく、対象となる10件です。

職務相反防止率：7/8 = 87.50%

8つの相反シナリオ中7つを阻止しました。D23は同じ委任本人を見逃したため失敗です。拒否必須項目なので、87.50%を「ほぼ利用可能」と解釈できません。

一回限り実行率：11/12 = 91.67%

重複送信、再生、使用回数を試す12件中11件が単一効果を維持しました。残る失敗は承認トークンとツール操作IDの結合不足を示します。

判断証拠完全率：35/42 = 83.33%

35件に対象版、承認本人、理由、証拠版、判断時刻、実行関連、最終状態がそろいました。重要な連結が一つでも欠ける対象は分子に含めません。

実行後回復成功率：5/6 = 83.33%

限定的で可逆な6件中5件が、期限内に検出、停止、取消、権威ある確認を完了しました。一件の回復失敗は、このパターンの拡大を止める根拠になります。

承認ゲートを統制プログラムとして実装する

1. 動作と結果を棚卸しする

エージェントが読取、生成、送信、変更、削除できる動作を列挙し、外部影響、機密性、範囲、可逆性、誤りのコストで分類します。画面のボタンから設計を始めません。

2. 判断対象とゲート契約を定義する

対象、パラメータ、内容、添付、参照状態、予想効果を安定した構造にし、承認者、選択肢、証拠、期限、取消、重要変更、失敗状態を契約化します。

3. 本人性、状態、実行をプロンプト外で強制する

権限あるID・方針系を参照し、実行資格情報をブローカーの後ろに置きます。モデルの自己申告や指示遵守に高影響動作を委ねません。

4. 迂回と変更経路を演習する

正常、却下、修正、期限切れ、権限変更、対象変更、重複、下流不明、回復を隔離環境で試します。成功例だけでなく全分母を固定します。

5. 審査、修正、再実行する

業務・統制・技術責任者が失敗と拒否項目を確認し、狭い範囲で再試験します。低量の試行を監視し、モデル、ツール、方針、ID、画面、データが変わるたびに再検証します。

人による審査と運用ガバナンス

追認作業を前提に設計しない

到着量、審査時間、ピーク、却下、修正要求、連続した高速承認を監視します。ただし速さを品質とみなさず、全失敗、拒否必須項目、不明状態、分母を標本審査します。

承認者とそのセッションを守る

最小権限、強い認証、セッション保護、アクセスログ、保持期限、機密証拠のマスキングを適用します。承認者のアカウント侵害は、ゲート全体の侵害になり得ます。

安全な非承認経路を維持する

本人確認、方針、通知、下流が停止したときは、安全に停止、代行、インシデントへ移ります。緊急経路は狭い範囲、明確な期限、独立した事後審査を必須にします。

OpenMaxが承認ワークフローを支援できる範囲

適切な調整役

構成と権限が許す範囲で、OpenMaxは限定ワークフローの一時停止、許可された証拠準備、承認タスクのルーティング、判断記録を支援できます。実能力は現在のテナント構成と公式情報で確認します。

決定論的な権限は外部に残る

IDディレクトリ、組織方針、法的権限、業務台帳、最終実行システムが権威を保持します。OpenMaxが要約や作業項目を作成しても、それらの承認権を自動取得するわけではありません。

単純なツールの方が合う場合

件数が少なく規則が固定なら、手動チェックリストや既存システムのネイティブ承認の方が説明・保守しやすい場合があります。対象固定、実行阻止、結果照合ができない組織は、先に基礎統制を整えます。

人間承認ゲートの限界

人の判断も誤る

承認者は証拠を誤読し、時間圧力や疲労で追認することがあります。明確な方針、訓練、容量管理、標本審査、使いやすい却下経路が別途必要です。

結合は下流のすべての層に依存する

有効な判断でも、ツールがタイムアウトし、状態不明、重複、部分完了になる可能性があります。操作ID、冪等性、照合、回復を承認とは別に設計します。

実行後審査ですべてを戻せるわけではない

外部への開示、不可逆な意思決定、時間依存の影響は、後から完全に取消できません。予測要約を唯一の証拠にせず、重大な動作には実行前の強いゲートを使います。

よくある承認ゲートの失敗と修正

動作ではなく要約を承認する

失敗：隠れた宛先、添付、ツール引数が異なります。修正：正規化対象を表示して結び付け、重要な変更で承認を失効させます。

承認者を早すぎる時点で検証する

失敗：キューを開いた時点では適格でも判断時には役割が変わっています。修正：判断時に現在の本人性、役割、範囲、相反を確認し、必要に応じ実行時も検証します。

再試行や新しい意図に承認を再利用する

失敗：一判断が反復効果や変更後の操作を許します。修正：使用回数、操作ID、期限、照合を実行前に定義します。

同じ有効本人が複数役割を埋める

失敗：委任、共有アカウント、サービスセッションが独立性を迂回します。修正：アカウント名ではなく、本人とセッションをまたぐ有効支配を方針で評価します。

無応答を同意として扱う

失敗：タイムアウトで実行を再開します。修正：安全な停止、代行、インシデント状態へ期限切れさせ、キューが遅いことを権限拡大の理由にしません。

実装チェックリストと次の手順（Next step）

ゲートを有効にする前

判断対象スキーマ、正規化、承認役割、相反、選択肢、期限、取消、実行ブローカー、権威ある結果、失敗経路を確認します。強制を検証するまで対象ツールを利用不能にします。

自律範囲を拡大する前

AG096型の全ケースと二つの拒否失敗を確認し、重要変更、誤役割、古い承認、再生、実行後回復を試します。責任者が残余リスクを明示的に受け入れます。

運用中

キュー負荷、判断時間、却下、変更、権限失敗、期限、ペイロード不一致、再生、下流差異、取消、損害を監視し、重要変更後は演習を再実行します。

よくある質問（FAQ）

すべてのAI動作に承認が必要ですか？

いいえ。結果、可逆性、範囲、検証済み統制で分類します。高影響動作には実行前ゲート、有界な低リスク作業には決定論的、標本、実行後の統制を使えます。

一つの承認でバッチ全体を許可できますか？

構成員、上限、許可操作、参照状態、変更規則が可視化・固定されている場合に限ります。新しい構成員や重要変更には新しい判断が必要です。

何が承認を無効にしますか？

ペイロード、対象、宛先、金額、添付、参照事実、権限、方針、リスク、本人性、使用回数、有効条件の変化は、ゲート契約に従い承認を失効させ得ます。

実行後審査は本当のゲートですか？

実行前提ではなく、監視と回復のパターンです。上限付き、観測可能、可逆な低リスク作業だけに使い、自動停止を備えます。

承認で危険な再試行を安全にできますか？

できません。承認は判断対象への人の権限を確立するだけです。再試行の安全性は操作ID、提供側の意味論、冪等性、コミット状態、照合に依存します。

演習スコアが高ければ本番を許可できますか？

できません。拒否失敗、記名審査、実システム証拠、セキュリティ審査、責任あるプロダクト承認を別々に満たす必要があります。AG096はNOT_ENABLEDのままです。

OpenMaxはどこに位置しますか？

設定された範囲で、限定された一時停止、許可された証拠準備、承認ルーティング、判断記録を支援できます。本人性、方針、業務実行の権威は外部に残ります。

情報源と編集方法

OpenMaxの製品情報

• OpenMax：AIワークフロー自動化コンプライアンス — 統制ワークフロー、審査、コンプライアンスの製品背景。
• OpenMax：AIエージェントプラットフォーム — 役割、ツール、権限、ログ、審査、運用の背景。

ガバナンス、アクセス、セキュリティ情報

• NIST：生成AIプロファイル — ガバナンス、人の監督、プライバシー、セキュリティ、情報完全性リスク。
• NIST SP 800-53 Rev. 5：AC-5 職務分離 — 職務分割の統制背景。
• NIST SP 800-53 Rev. 5：AC-6 最小権限 — 認可アクセス制限の背景。
• OWASP：LLM06:2025 Excessive Agency — 最小機能、最小権限、利用者文脈での実行、高影響な人間承認。
• OWASP：LLM01:2025 Prompt Injection — 信頼できない外部内容と間接インジェクション境界。

編集方法

OpenMax編集チームは2026年9月5日に上記の公式・一次情報を確認し、出典に基づく統制・製品背景と独自の運用上の整理を区別しました。AG096は完全に架空で、対象、イベント、審査、割合はベンチマーク、認証、顧客結果、OpenMax性能測定ではありません。公開前には有資格者と実テナントによる審査が必要です。