human-in-the-loop

ヒューマン・イン・ザ・ループ

リスクを左右する意思決定の時点に、人間の判断を介在させます。確認ダイアログだけでは監督とは言えません。承認された意思決定を、理解可能で変更不能なアクションに結び付け、何が起きたかを示す証拠を保持してください。

入力

以下を収集または推定し、仮定にはその旨を明記してください。

• エージェントの目標、ワークフローの状態、提案または実行可能なすべてのアクション
• 影響の種類、可逆性、価値、影響を受ける人々、信頼できる最悪の影響
• データの機密性、規制上または契約上の義務、組織のリスク許容度
• 依頼者と承認者の安定した主体ID、役割の割り当て、ポリシー所有者、職務分離ルール、対応可能時間
• 必要な応答時間、タイムアウト時の動作、エスカレーション先、可用性目標
• 承認者が必要とする証拠（出所、不確実性、代替案を含む）
• 既存のID管理、ポリシー、監査、チケット管理、通知システム
• 失敗、再試行、キャンセル、補償、インシデント対応の経路

承認者の権限や組織のポリシーを捏造しないでください。重要なアクションに影響する情報が不足している場合は、ポリシー案を提示し、所有者の承認が必要であることを明記してください。

出力契約

以下を提出してください。

1. アクション一覧と、各アクションのリスクティアを裏付ける根拠
2. 検証済みの述語、承認資格を持つ役割と別個の主体、定足数、証拠、有効期限、タイムアウト、構造化されたエスカレーション、監査機能停止時の動作、実行時の再認可、補償、緊急時の特例、職務分離を定義したゲートポリシー
3. 準備、レビュー、意思決定、実行、失敗、復旧の状態機械
4. 正確なアクション、重大な影響、不確実性、出所、代替案、安全な却下・編集の方法を示す承認エクスペリエンス
5. 追記専用の意思決定記録スキーマと、保持・マスキング要件
6. 実装またはファイル単位の計画と、ポリシーおよび並行実行のテスト
7. 検証の証拠、未解決のポリシー上の判断、残存リスク、運用上の復旧計画

機械可読なポリシーが役立つ場合は、assets/approval-policy-template.json から始めてください。scripts/validate_gate_policy.py で検証してください。リスクティアと状態機械の指針については、references/gate-design-guide.md を参照してください。

ワークフロー

1. 意思決定と影響を一覧化する

各エージェントのアクションと、その影響を受ける対象を列挙します。下書き、プレビュー、推奨、読み取りを、確定、送信、公開、購入、削除、アクセス権の付与、コードの実行、重大な意思決定から区別します。

可逆性、規模、機密性、外部からの可視性、金銭的価値、時間的制約、影響を受ける権利、誤ったアクションを封じ込められるかどうかを記録します。

2. 必要十分な最小限の監督を割り当てる

リスクごとに、次の制御を1つ選択します。

• 監査付き自律実行： 範囲が限定され、可逆で、影響が小さいアクション
• アクション後に通知： 迅速な把握で十分な、影響の小さいアクション
• アクション前にレビュー： 重大なアクション、または外部から見えるアクション
• 追加承認： 価値、機密性、確信度、異常、または範囲がしきい値を超える場合
• 二者統制： 重大、不可逆、特権的、または規制対象のアクション。原則として、別個の承認者主体を少なくとも2つ要求します
• 禁止： アクションがポリシーを超える場合、または許容できる安全性を確保できない場合

取るに足らないすべての手順にゲートを設けないでください。過剰な確認は、ユーザーに反射的な承認を習慣づけます。レイテンシ目標を達成するために、必要なゲートを決して取り除かないでください。重要なアクションに対する単独統制と、依頼者自身による承認は、原則として無効として扱います。いずれかを認める場合は、対象となるゲートと例外の種類を明記した期限付きの免除に限ります。さらに、ポリシー所有者の安定した主体IDと承認参照を含め、理由と補完的な統制を記録し、その免除をゲートから明示的に参照する必要があります。

3. 決定パッケージを提示する

承認者に次の情報を提示します。

• 平易な言葉での意図と、ゲートが作動した理由
• 対象の識別情報と正規化されたパラメーター
• 変更前後の差分、または提案するペイロードの正確な内容
• 予想される影響、影響を受ける当事者、コスト、可逆性
• 証拠の情報源、来歴、新しさ、不確実性、既知の不足事項
• ポリシーの根拠、代替案、拒否・編集・タイムアウト時の動作

秘密情報を隠し、個人データを最小限に抑えます。拒否・キャンセルの主要な経路も、承認と同じくらい使いやすくします。

4. 識別情報と承認をアクションに紐付ける

承認者を認証し、その役割をモデルとは独立して認可します。モデルの役割と、安定した承認者の主体を別々に扱い、2つの役割が必要な場合に、気付かないうちに1人で要件を満たすことがないようにします。実行者、テナント、アクション、対象、重要なパラメーター、ポリシーバージョン、有効期限、nonce の正規表現またはダイジェストを作成します。承認は、その変更不可能な提案にのみ適用されます。

重要な編集、有効期限切れ、ポリシー変更、対象変更、または関連する状態変更の後は、承認を無効にします。職務分掌が適用される場合は、自己承認を防止します。沈黙、メッセージの受信、または一般的な過去の同意を承認として扱ってはいけません。

5. 安全な状態マシンを実装する

次のような明示的な遷移を使用します。

prepared -> pending_review -> approved | rejected | expired | cancelled

approved -> executing -> completed | failed | compensation_pending

遷移はアトミックかつ冪等にします。実行直前に認可と前提条件を再確認します。ワンタイム承認は正確に1回だけ消費します。承認者の同時操作、重複したコールバック、古い画面、再試行、下流での部分的な障害に対処します。

6. エスカレーションと復旧を追加する

機械可読なリマインダー、エスカレーション先の主体または役割、最大試行回数、最大待機時間、上限到達時の動作、不在時の対応を定義します。タイムアウト時は承認ではなく、拒否、キャンセル、またはエスカレーションをデフォルトとします。監査ストアの停止時にフェイルクローズとするか、短期間有効な署名付きバッファーを使用するかを明記します。重要なアクションはフェイルクローズとします。実行直前に、識別情報、役割、ポリシー、提案ダイジェスト、対象の状態、有効期限を再認可します。

補償処理が、自動、手動、必要だが利用不可、または該当なしのいずれであるかを定義し、担当者と手順への参照を指定します。緊急用の例外経路は、強力な認証を必要とする別個の経路として扱います。少なくとも2人の氏名が特定された主体、限定された適用範囲、短い有効期限、理由の記録、即時通知、事後レビューを必須とします。

拒否時は、提案と理由を保存し、実行しません。実行に失敗した場合は、安全でない再試行を停止し、実際の状態を記録し、テスト済みの補償アクションがある場合は実行し、担当者に通知して、機密情報を除いた証拠を保存します。

7. 制御を検証する

次の項目をテストします。

• 各アクションが想定されたリスク階層とゲートに分類されること
• 権限のない実行者、別テナントの実行者、自己承認する実行者が拒否されること
• パラメーター、対象、状態、ポリシー、有効期限が変更された後に承認が失敗すること
• 重複した承認やコールバックによって二重に実行されないこと
• 拒否、編集、キャンセル、タイムアウト、エスカレーション、承認者不在時の経路
• 同時に決定が行われた場合の定足数、主体の識別性、自己承認、担当者による免除、職務分掌の動作
• 実行時の再認可と前提条件の変更
• エスカレーション上限到達、監査ストレージの停止、部分的な障害、補償処理、緊急用例外経路、インシデント通知
• 決定記録に必要な証拠が含まれ、秘密情報が含まれないこと
• 理解度やエラー率を含め、代表的な承認者が使いやすいこと

コマンド、シミュレーション、観測結果を報告します。ポリシーロジックと承認エクスペリエンスの両方を実際に検証せずに、人によるレビューが有効だと主張してはいけません。

認可と安全性の境界

• ゲートを設計しても、基盤となるアクションが認可されるわけではありません。別途認可されていない限り、実行、送信、公開、デプロイ、購入、削除、アクセス権の付与を行わないでください。
• モデルが人間の承認を捏造、偽装、推測することは決して許可しないでください。
• モデルが生成したテキストの外部で、本人確認、認可、定足数、承認の紐付けを強制してください。
• 承認者、ログ、通知、テスト用フィクスチャに、シークレットや不要な個人データを公開しないでください。
• 高リスクのアクションでは、本人確認情報の欠落、述語の曖昧さや形式の不正、状態の古さ、承認または免除の期限切れ、テナントの不一致、定足数の無効性、異なる対象者の数の不足、監査ストレージの利用不可がある場合は、安全側に倒して処理を拒否してください。
• ダークパターン、承認の事前選択、緊急性をあおる操作、実質的に異なるアクションを隠す一括承認を避けてください。
• 差別的、違法、またはその他禁止されている判断を正当化するために、人間によるレビューを利用しないでください。

現実的な例

返金エージェント

確認済みの二重請求に限り、50ドル未満の返金を自動で許可します。50ドルを超える場合はサポートマネージャーの承認を必須とし、1,000ドルを超える場合は財務部門とサポート部門の両方の承認を必須とします。注文履歴、ポリシー上の根拠、金額、返金先、不正利用の兆候を表示します。承認を注文、金額、返金先、ポリシーのバージョンに紐付け、二重請求、変更された支払い先、タイムアウト、決済処理の部分的な失敗をテストします。

コミュニケーションエージェント

エージェントによる顧客向け更新情報の下書き作成は許可しますが、正確な宛先、件名、本文のダイジェスト、添付ファイル、送信時刻について、アカウント所有者の承認を必須とします。編集があれば、承認は無効になります。却下された下書きは編集に戻し、期限切れの承認では送信できないようにします。添付ファイルの内容を判断ログに保存せず、判断を監査できるようにします。

完了チェック

すべての重大なアクションに文書化されたポリシーがあり、述語が構造的に検証され、承認者のロールから十分な数の異なる対象者が特定され、オーナーが承認した有効な免除がない限り、重要な単独管理や自己承認が拒否され、承認が再利用されたり、気付かれないまま適用範囲が拡大されたりせず、エスカレーション／監査停止／再認可／補償／緊急時対応の経路が機能し、監査証跡と残存リスクが明示されている場合にのみ、完了としてください。