ガードレール、ポリシーエンジン、および人間による承認ワークフロー
貴社の財務チームが、月次決算プロセスを支援するためにエージェントの活用を開始したと想像してください。エージェントは例外を特定し、複数のシステムから証拠を収集し、コメントのドラフトを作成できます。パイロット段階ではすべてが順調に進んでいます。ところがある日、エージェントが誤って、マネージャーのレビューなしでは実行すべきではない重要な調整を転記してしまいました。財務報告の数値が変わります。チームはパニックに陥ります。
このような出来事は、AIモデル自体に問題があるからではありません。モデルは完璧に動作していた可能性があります。問題は制御にあります。つまり、エージェントがビジネスの状態を恒久的に変更するアクションを実行する前に、それを阻止するメカニズムが存在しなかったのです。
これは、すべての企業がエージェントに本番システムへのアクセスを許可する前に答えなければならない問いです。つまり、損害が発生する前に、エージェントが誤ったアクションを実行するのを防ぐにはどうすればよいかということです。前回の記事で説明したオブザーバビリティは、何かが発生した後にそれを確認し説明することしかできません。発生を未然に防ぐには、ガードレール、ポリシーエンジン、人間による承認ワークフローという、連携して機能する3つのコンポーネントが必要です。
多くの組織は依然としてガードレールをコンテンツフィルター、つまり危険な回答、機密ワード、不適切な応答をブロックするものと見なしています。それは重要ですが、エンタープライズにとっては、それは最外層にすぎません。エージェンティックAIの最大のリスクは、生成される文章ではなく、呼び出されるツール、取得されるデータ、そして変更されるビジネスの状態にあります。内部の質問に誤って答えるエージェントは確かに厄介です。しかし、返金処理を誤ったり、新しいベンダーを作成したり、設定変更を引き起こしたり、注文ステータスを変更したり、財務システムに指示を送信したりするエージェントは、はるかに危険です。
したがって、エージェンティックエンタープライズにおけるガードレールは、ポリシードキュメントやシステムプロンプトに書かれているだけでなく、ランタイム、つまり意思決定とアクションの近くに設置されなければなりません。
ガードレールは単なる出力フィルターではない
ガードレールを、プロセスの最後に設けられた検閲レイヤー、つまりモデルが回答を生成し、その後システムがその出力が安全かどうかをチェックするものと理解するのは、最も誤った考え方です。このアプローチは単純なチャットボットには十分かもしれません。しかし、エージェンティックシステムにとっては、手遅れです。エージェントが既にアクセスすべきでないドキュメントを取得したり、誤ったツールを呼び出したり、トランザクションを変更するアクションを実行したりした場合、最終的な出力をフィルタリングしても、もはや主要な問題は解決しません。
エンタープライズの実践において、ガードレールは少なくとも5つのポイントで機能する必要があります。第一に、入力です。システムは、ユーザーが何を要求しているか、またはトリガーイベントが何かをチェックする必要があります。これはコンテンツセキュリティのためだけでなく、意図がエージェントのユースケースと一致していること、リクエストが正式なプロセスを迂回しようとしていないこと、ワークフローを開始するのに十分な初期コンテキストがあることを確認するためです。例えば、調達において、リクエスターは、プロセスが本来、受付とカテゴリ分類から開始されるべきである場合に、エージェントを使用して直接発注書を作成することはできません。人事オペレーションにおいて、エージェントは、正式なルートなしに従業員データを変更するための自由な指示を受け入れるべきではありません。
第二に、コンテキスト検索です。ガードレールは、エージェントが取得できるドキュメント、データ、メモリを制御する必要があります。財務エージェントは関連する会計ガイダンスを取得できますが、エンティティ間の機密メモすべてを取得できるわけではありません。カスタマーサービスエージェントは、対応中の顧客のチケット履歴を表示できますが、意味的に類似しているという理由だけで他の顧客のデータを引き出すことはできません。法務受付エージェントは、該当する契約テンプレートを取得できますが、特権が制限されているすべての案件を取得できるわけではありません。
第三に、ツールアクセスです。利用可能なすべてのツールが、すべての状況で使用できるわけではありません。ガードレールは、どのエージェントが、どのワークフローで、どのようなパラメータで、どのツールを呼び出せるかを制限する必要があります。IT運用では、エージェントは診断ツールを実行しチケットを発行できますが、自動的に本番変更を実行することはできません。カスタマーオペレーションでは、エージェントは権利を確認し返金を準備できますが、一定のしきい値を超える返金を実行することはできません。
第四に、アクション実行です。これが最も重要なポイントです。ガードレールは、ビジネスの状態を変更するアクションが本当に許可されているかどうかをチェックする必要があります。新しいベンダーの作成、仕訳の転記、与信限度額の変更、支払いブロックの解除、インシデントの完了処理など、これらすべてに制御が必要です。ここで企業は、読み取り、推奨、ドラフト作成、実行を明確に区別する必要があります。多くのユースケースは、適切なランタイム制御なしにエージェントに実行権限が与えられるまで安全に見えます。
第五に、出力です。上記4つのポイントを経て初めて、出力フィルターが依然として有効になります。これは、機密データの漏洩を防ぎ、使用される言語が適切であることを確認し、最終的な応答に証拠によって裏付けられていない主張が含まれていないかをチェックするのに役立ちます。ただし、出力フィルターは最後のレイヤーとして理解されるべきであり、主要なガードレールではありません。
ガードレールはランタイムで動作しなければならない
多くの企業はすでに、標準業務手順書、承認マトリックス、アクセスポリシーを持っています。問題は、エージェントが人間のようにガバナンスドキュメントを読まないことです。制御を真に機能させるためには、ルールをランタイムメカニズム、すなわちツール呼び出し前のポリシーチェック、パラメータ検証、トランザクションしきい値、承認トリガー、意思決定のログ記録に変換する必要があります。ガードレールがガバナンススライドやシステムプロンプトの中にしか存在しない場合、エージェントがあいまいな状況に直面したとき、システムはアクションを停止または迂回させる正式な方法を持ちません。
財務決算において、エージェントは例外の特定、証拠の収集、コメントのドラフト作成を支援するかもしれません。健全なガードレールは、特定の決算データへの読み取りアクセス、コメントのドラフト作成、フォローアップのルーティングを許可します。しかし、同じガードレールは、エージェントが重要な調整を転記しようとしたり、十分な根拠なしに会計処理方法を選択しようとしたり、最小限の証拠なしに例外をクローズしようとしたりする場合には、拒否またはエスカレーションする必要があります。
認識すべきトレードオフがあります。ガードレールが厳格すぎると、エージェントが役に立たなくなる可能性があります。すべての小さなステップが承認を必要としたり、検証が多すぎたりすると、ユーザーは手動プロセスに戻ってしまうでしょう。したがって、ガードレールの設計はリスク階層に従う必要があります。内部ナレッジアシスタントのようなユースケースでは、ガードレールはより緩やかで構いません。トランザクション、顧客、または本番システムに影響を与えるユースケースでは、ガードレールははるかに厳格でなければなりません。
ポリシーエンジン：許可判断を一貫して行う場所
ガードレールが制御のレイヤーであるとすれば、ポリシーエンジンは、ランタイムにあるアクションが実行可能かどうかを判断するエンジンです。簡単に言えば、ポリシーエンジンは次のような質問に答えます。このエージェントは、このユーザーまたはワークフローのコンテキストにおいて、このビジネスオブジェクトに対して、このトランザクション金額で、このリスクレベルで、このツールを呼び出すことを許可されているか、そして先に進む前に人間の承認が必要かどうか。
ポリシーエンジンがなければ、エージェントの制御の多くは、プロンプト、アプリケーションコード、ツール設定、チームの習慣に分散することになります。その結果、一貫性がなく、監査が困難になります。
エンタープライズでは、ポリシー判断は通常、複数の要素の組み合わせを考慮する必要があります。第一に、役割と委任された権限です。エージェントは誰のために行動していますか？ユーザーの指示、正式なワークフロー、システムイベントのいずれに基づいていますか？その権限はまだ有効ですか？第二に、ビジネスコンテキストです。どのオブジェクトに触れていますか？ベンダー、請求書、注文、チケット、契約、従業員データなど。ドメインが異なれば、異なるルールが適用される可能性があります。第三に、トランザクション金額または重要性です。多くのアクションは低額では安全ですが、高額では安全ではありません。少額のグッドウィルクレジットは自動実行が許可されるかもしれませんが、多額の返金はスーパーバイザーの承認が必要です。標準的なカテゴリの購買依頼は一定の限度まで自動処理されるかもしれませんが、戦略的な購買は承認のために停止されなければなりません。第四に、リスクレベルです。一部のアクションは元に戻せますが、他のアクションは元に戻せません。一部は局所的な影響しか与えませんが、他のアクションはシステム全体に影響を与えます。ポリシーエンジンはこれらの違いを理解する必要があります。第五に、規制または統制要件です。特定のドメインでは、ルールは単なる内部の選好ではなく、職務分離、最小限の証拠、人間によるレビューの義務など、コンプライアンス上の義務です。
すべてのポリシーが同じ方法で作成される必要はありません。一般的に、3つのパターンがあります。決定論的ルールは、明確で厳格に定式化できる事項に最も適しています。つまり、一定のしきい値を超えるトランザクション金額、特定のベンダーカテゴリ、特定の時間帯の本番変更、アクセスすべきでない機密データなどです。その利点は、監査、テスト、説明が容易なことです。欠点は、ビジネスコンテキストが非常に多様な場合にすぐに複雑になることです。
よりあいまいな状況には、企業はモデルベースの分類器を使用して、リクエストの機密性、ケースのリスクレベル、不正の可能性、ユーザーの意図がスコープ外かどうかを評価できます。その利点は、厳格なルールとして記述するのが容易でないケースに対してより柔軟であることです。欠点は、説明が難しく、定期的な評価が必要であり、リスクの高いアクションに対する唯一の制御としては適さないことです。
通常、両方の組み合わせが最も健全なパターンです。分類器がコンテキストやリスクシグナルの評価を支援し、決定論的ルールが最終的な判断を下します。カスタマーオペレーションでは、分類器がケースが機密であるか、または紛争の可能性があるかを評価し、決定論的ルールが、機密ケースまたは一定のしきい値を超える金額のケースはすべて承認が必要であると判断します。
最も重要な原則の1つは、すべてのポリシー判断は監査可能な証跡を残さなければならないということです。企業は、どのポリシーが評価されたか、どのようなコンテキスト入力が使用されたか、結果が許可、拒否、エスカレーション、承認要求のいずれであったか、そしてその判断がいつ行われたかを説明できなければなりません。これは正式な監査のためだけでなく、日常業務にとっても重要です。ユーザーがなぜエージェントが特定のアクションを拒否したのか尋ねたとき、チームは「システムがダメと言ったから」と答えるべきではありません。彼らはその論理とコンテキストを示すことができなければなりません。
調達エージェントが購買リクエストを受け取ったと想像してください。ポリシーエンジンは、購買カテゴリ、ベンダーが承認済みかどうか、トランザクション金額、契約の有無、リクエスターの役割を評価します。結果は異なる可能性があります。承認済みベンダーからの低額の標準リクエストは許可、より高額の場合は承認が必要、デューデリジェンスを通過していないベンダーの場合は拒否、購買カテゴリがあいまいまたはポリシーが矛盾する場合はエスカレーション。ポリシー判断の記録がなければ、企業は一見似たような2つのリクエストが異なる扱いを受けた理由を説明するのに苦労するでしょう。
人間による承認ワークフロー：適切なポイントで人間が介入する
エージェンティックエンタープライズにおいて、ヒューマン・イン・ザ・ループとは、人間がすべてをチェックしなければならないという意味ではありません。それではエージェンティックAIの利点が損なわれます。必要なのは、選択的でリスクベースの人間による承認ワークフローです。
人間の承認は通常、アクションが高額、機密性が高い、元に戻せないまたは元に戻すのが難しい、または規制対象である場合に必要です。これはエージェントの失敗を示すものではありません。むしろ、企業が自律性の限界を健全に理解している証拠です。
ほぼ常に承認に値するいくつかのパターンとしては、重要なしきい値を超えるトランザクション、重要なマスターデータの変更、従業員の権利に影響する決定、紛争の可能性がある顧客アクション、リスクの高い本番変更、専門的な判断を必要とする決定などがあります。財務では、重要な調整、支払いブロックの解除、重大な影響を及ぼす例外処理。調達では、新しいベンダー、非標準契約、高額なカタログ外購入。カスタマーオペレーションでは、多額の返金、VIP顧客へのグッドウィルクレジット、法的な問題に発展する可能性のある苦情の解決。IT運用では、本番設定の変更、クリティカルサービスの再起動、ピーク時のデプロイメントのロールバック。
最も一般的な誤りの1つは、単に通知を送信するだけの承認ワークフローを作成することです。「エージェントがアクションXを推奨しています。承認しますか？」これは不十分です。レビュアーである人間は混乱し、多くのシステムを開く必要があったり、疲労のために盲目的に承認してしまったりするでしょう。健全な承認ワークフローは、レビュアーに十分な最小限のコンテキスト、すなわちエージェントの推奨、使用された証拠、関連するポリシー、主要なリスク、信頼度またはエスカレーションの理由、および可能な代替案を提供する必要があります。
顧客返金の承認リクエストを受け取ったスーパーバイザーは、返金額だけを見るべきではありません。顧客の履歴、返金理由、該当する権利、同様のケースが過去にあったかどうか、悪用の兆候がないか、そしてなぜエージェントが自動実行しなかったのかを確認する必要があります。このようなコンテキストがあれば、承認は形式的なものではなく、意味のある決定となります。
しかし、同様に重要なトレードオフがあります。あまりにも多くのケースが承認に回されると、サイクルタイムが悪化し、スーパーバイザーがボトルネックとなり、ユーザーは信頼を失い、エージェントは単なる新しいキュー作成マシンと化します。したがって、承認のしきい値は、過剰な安心感ではなく、リスク階層に基づいて設計されるべきです。健全なアプローチは通常、低リスクは監視付きで実行、中リスクは事後レビューまたはサンプリング付きで実行、高リスクは承認付きで実行、非常に高リスクは人間主導でエージェントはアシストのみ、というものです。これは、すべてのアクションを強制的に承認プロセスにかけるよりもはるかに効果的です。
承認が障害とならないようにするために、企業はいくつかの事項を明示的に決定する必要があります。すなわち、主要な承認者とそのバックアップ、承認のSLA、承認者が応答しない場合の対処、承認を委任できるかどうか、そして承認の決定がどのように記録され、今後の学習に活用されるかです。多くの組織では、ボトルネックはAIモデルではなく、適切に設計されていない承認キューにあります。
エスカレーションとロールバック：エージェントはいつ停止すべきかを知らなければならない
優れたエージェントとは、いつ行動すべきかを知っているだけでなく、いつ先に進むべきでないかを知っているエージェントです。エスカレーションは、エージェントが信頼度の低さ、データソース間の矛盾、ポリシーのあいまいさ、ツールの結果の不整合、事前に定義されたスコープ外の状況などの条件に直面した場合に必要です。このような状況では、正しい動作は「成功するまで試行し続ける」ことではなく、停止し、理由を説明し、人間または別のワークフローに引き継ぐことです。
財務決算において、エージェントが特定の例外処理に関して矛盾しているように見える2つのガイダンスソースを発見した場合。調達において、ベンダーマスターデータが有効な契約と一致しない場合。カスタマーオペレーションにおいて、顧客履歴が悪用のパターンを示しているが、正式な権利はまだ有効に見える場合。IT運用において、診断用ランブックが矛盾する結果をもたらし、本番環境への潜在的な影響が増大している場合。これらすべてのケースにおいて、境界のある自律性とは、エージェントが自身の限界を知っていることを意味します。
特定のアクションについては、制御は承認で終わりません。企業は、エージェントのアクションが誤っていた場合に何が起こるかについても考慮する必要があります。一般的なパターンは3つあります。第一に、ロールバックです。システムが直接的な取り消しをサポートしている場合、これが理想的です。誤って作成されたチケットの取り消し、非本番設定の復元、プロセスが続行される前の特定のステータスの取り消しなどです。第二に、補償アクションです。アクションを直接取り消せない場合、システムは補償アクションを必要とします。エージェントが誤ってベンダーに通知を送信した場合は、是正フォローアップが必要です。エージェントが顧客ケースを誤ってルーティングした場合は、再割り当てと再連絡が必要です。エージェントが誤ったプロセスステップをトリガーした場合は、それを無効化するアクションが必要です。第三に、手動による是正パスです。より複雑なケースについては、企業は明確な手動是正パス、つまり誰が引き継ぐのか、インシデントがどのように記録されるのか、そしてその教訓がどのようにポリシーやガードレールにフィードバックされるのかを準備する必要があります。
ロールバックや是正パスがなければ、組織は自律性を与えることを過度に恐れるか、あるいは逆に安全策なしで過信する傾向があります。
自律性マトリックス：エージェントのアクションの境界を決める実践的な方法
この議論を締めくくる最も実践的な方法は、自律性マトリックスを使用することです。すべてのユースケースが同じレベルの自律性である必要はありません。
アシストレベルでは、エージェントはコンテキストの検索、要約、インサイトの提供のみを支援します。あいまいなドメイン、データがまだ安定していない場合、または人間の判断に大きく依存するプロセスに適しています。
ドラフトレベルでは、エージェントは推奨事項、ドキュメント、またはアクションを準備しますが、人間が実行します。変革の初期段階、高い制御が必要なドメイン、または実行権限を与えずにプロセスを加速したい場合に適しています。
承認付き実行レベルでは、エージェントは人間の承認後にアクションを準備し実行できます。高額なアクション、規制対象のワークフロー、または正式な制御の証拠が必要な領域に適しています。
監視付き実行レベルでは、エージェントは明確なポリシーの範囲内で自動実行し、その後オブザーバビリティとサンプリングを通じて監視されます。大量処理、低～中リスク、元に戻せるアクション、およびポリシーが十分に成熟しているドメインに適しています。
このマトリックスは、企業が2つの極端、すなわち完全な自律性を早急に与えすぎることと、プロセスが実際に準備ができているにもかかわらずエージェントをアシストモードに長く留めすぎることを避けるのに役立ちます。
実践的な示唆
この記事を読んだ後、いくつかの決定を下す必要があります。第一に、ランタイムにおけるガードレールのポイントを決定することです。貴社のガードレールは出力のみをフィルタリングしていますか、それともすでに入力、検索、ツールアクセス、アクション実行、出力を制御していますか？第二に、ポリシーエンジンのアーキテクチャを決定することです。どのルールを決定論的にすべきか、どの領域で分類器の使用を許可するか、そしてポリシー判断を監査のためにどのように記録するか。第三に、リスク階層と承認のしきい値を定義することです。どのアクションを自動実行可能とし、どのアクションに監視が必要で、どのアクションに承認が必須で、どのアクションを人間主導のままにすべきか。第四に、真に使いやすい承認ワークフローを設計することです。承認者は、迅速かつ責任ある決定を下すために十分なコンテキスト、証拠、リスク、代替案を受け取ることになりますか？第五に、エスカレーションと是正のパスを準備することです。エージェントはいつ停止すべきか、誰にエスカレーションするか、そして結果が誤っていた場合にロールバックまたは補償アクションをどのように実行するか。
このトピックがスケールする準備ができていないことを示すいくつかの危険信号があります。エージェントはすでに本番ツールを呼び出せるが、ガードレールはプロンプトとコンテンツフィルターに限定されている。企業がランタイムポリシーを信頼していないため、ほぼすべてのケースで人間の承認が使用されている。アクションが許可、拒否、またはエスカレーションされた理由に関する正式な記録がない。レビュアーである人間は、十分な証拠なしに承認リクエストを受け取っている。エージェントがビジネスの状態を誤って変更した場合のロールバックパスがない。ビジネス、テクノロジー、リスク、監査の各チームが「自動化しても安全」の定義を異なっている。効率性へのプレッシャーから、制御と品質の証拠ではなく、エージェントの自律性が引き上げられている。
CIO、COO、CHRO、そして変革リーダーへの内省的な問いかけです。もし明日、貴社のエージェントが顧客、従業員、またはトランザクションに実際の影響を与える誤ったアクションを実行した場合、それを阻止すべきだったガードレールは何か、それを許可したポリシーは何か、誰が承認すべきだったか、そしてシステムがどのように回復するかを迅速に説明できますか？その答えがまだ明確でないのであれば、次の焦点はより多くのエージェントを追加することではなく、まず制御とランタイムガバナンスを強化することです。