AI 承認ワークフロー：エージェントの操作を実行前に確認する

AI 承認ワークフローとは

AI 承認ワークフローという言葉は、2 つの意味で使われます。1 つは、請求書や休暇申請の回付など、通常の業務承認を AI で効率化する製品を指す場合です。このガイドで扱うのはもう 1 つの意味で、メッセージの送信、返金の実行、レコードの変更など、AI エージェントが提案した操作を、実行前に人がレビューするワークフローのことです。

人間参加型とは、担当者がエージェントの提案したアクションを確認したり、介入したりできることを意味します。これには、クライアントの確認、独立したレビュー、または運用上のチェックポイントが含まれる場合があります。これらのメカニズムは、さまざまなレベルの分離と強制を提供します。

MCP ツールの仕様では、機密性の高い操作についてはユーザーによる可視化と確認が推奨されています。 Durin は、書き込みポリシーで必要な場合に独立したレビューを追加します。別のアクティブな管理者が、特定のリクエストを続行するかどうかを決定します。

ワークフローのパターンを選ぶ

承認ワークフローは、誰が、いつレビューし、どこまで内容を確認できるかによって異なります。多くのチームは複数のパターンを組み合わせ、定型的な操作はルールに沿ってそのまま進め、影響の大きい操作だけが人の判断を待つようにしています。

Durin は、別の管理者による独立したレビューに対応しています。Slack を接続すればレビューの通知を Slack で受け取れるほか、繰り返し発生するリクエストには「承認履歴の活用」機能で対応できます。そもそもどのリクエストがレビュー担当者に届くかは、アクセスルールによって決まります。

• クライアントでの確認：エージェントを使う本人が、重要な操作をそのつど確認します。手軽ですが、申請者が自分のリクエストを自分でレビューすることになります。
• 独立したレビュー：別の担当者が、リクエストの正確な内容を見て判断します。時間はかかりますが、申請と承認を分けられます。
• 例外時のレビュー：定型的な操作はルールに沿って進め、金額が大きいものや外部の宛先へのものなど、通常と異なる操作だけをレビュー担当者に回します。
• 保存済みの判断：レビュー担当者が 1 件ずつ承認する代わりに、条件の一致する繰り返しのリクエストを一定期間許可します。
• 事後のサンプリングレビュー：担当者が、完了した操作の一部を抽出して確認します。品質の向上には役立ちますが、有害な操作を止めることはできません。

どのアクションに承認が必要かを決定する

アクションの結果をレビューの指針として使用します。実例となる外部メッセージ、一括更新、または支払いは、機密性の低い検索よりも精査する価値がある場合があります。読み取り専用ツールでも機密情報が漏洩する可能性があるため、アクセス チェックは依然として必要です。

これらはリスク評価の例であり、Durin に組み込まれたリスク区分ではありません。Durin では、ワークスペースのデフォルト設定でアクセスと変更操作の判定を決め、カスタムルールで特定の接続、ツール、リソース、環境、人、チームに対して承認を必須にできます。Durin は、ルールに基づいて特定の承認者にリクエストを振り分けることはしません。申請者以外のアクティブな管理者であれば、誰でもレビューできます。

• 影響: どのようなデータ、お金、または外部コミュニケーションが変化する可能性がありますか?
• 範囲: 1 回の呼び出しで影響を受けるレコードまたは受信者の数はどれくらいですか?
• 可逆性: 間違いをどのように検出して修復しますか?
• レビューの品質: レビュー担当者は決定を下すのに十分なコンテキストを持っていますか?

承認前に必要なチェックが行われる

Durin はまず、ID、メンバーシップ、接続とチームのアクセス、認証情報、レビュー済みのツール、リソース、検査結果をチェックします。承認では、失敗した必須チェックを修復したり、上流プロバイダーの権限を拡張したりすることはできません。

必要な確認をすべて通過した場合に限り、原則としてアクセスを許可します。管理者は、変更操作に別の管理者の承認を求めるか、変更操作をすべて拒否するよう設定できます。原則拒否にすると、ツールへのアクセスはブロックされます。サンドボックスでも本番環境でも、同じポリシーが適用されます。

未レビューのツールは、ツールのレビューが保留されるまでブロックされたままになります。ツール定義のレビューと特定の書き込みの承認は別の決定です。

承認を個別のリクエストにひも付ける

正確な許可には、申請者、組織、接続、認証情報コンテキスト、ツールとスキーマのバージョン、リソース、引数ダイジェスト、ポリシー バージョン、および失効状態が含まれます。そのコンテキストを変更すると、承認が無効になる可能性があります。

引数ダイジェストは、リクエストを照合するために使用されるフィンガープリントです。操作については読みやすい説明ではありません。 Durin のレビューでは、そのダイジェストと申請者ー、ツール、リソース、ポリシーとスキーマのバージョン、および有効期限が示されています。レビュー担当者は承認する前に、関連するビジネスコンテキストを必要とします。

許可には有効期限があり、使い捨てです。メンバーシップと権限は実行前に再度チェックされるため、早期に承認しても取り消し後のアクセスは保持されません。

承認と再試行を通じてリクエストに従ってください

サポートされているサンドボックス書き込み、許可されたフィクスチャ リソース、および 2 人の異なる管理者を使用して、ライフサイクルをテストします。次の段階に進む前に、各段階を確認してください。

• 承認を必要とするポリシーに基づいて書き込みを送信し、アップストリーム アクションが実行されていないことを確認します。
• 他の管理者に承認を開いて正確なリクエストを確認してもらいます。
• リクエストを承認し、承認だけではリクエストが実行されなかったことを確認します。
• 承認コンテキストがまだ有効な状態で、有効期限が切れる前に同じ呼び出しを再試行します。
• 実行結果を検査します。テストの拒否、有効期限、および変更された引数は別のフィクスチャ リクエストで処理します。

書き込みを重複させずに不確実性を処理する

接続先システムが変更をコミットした後、接続が失敗する可能性があります。応答がないからといって、何もアクションを起こさないわけではありません。承認、リクエスト送信、完了の確認は区別しておく必要があります。

Durin は、ガバナンスされた書き込みの前に必要な実行意図を記録し、完了する可能性のある書き込みを自動的に繰り返しません。新しいアクションが適切かどうかを判断する前に、記録された結果を検査し、プロバイダーと調整してください。

単回使用の承認により、許可の再利用が制限されます。これは、外部システム間で普遍的に 1 回だけ保証されるものではありません。不確実な結果をランブックに含め、それらを調整する所有者を割り当てます。