午前3時です。あなたが寝ている間、あなたのエージェントはサポートチケットのキューを処理していました。あるチケットはエスカレーションのようだったので、エージェントは要約を作成し、それをあなたの上司にメールで送りました。要約は正確で、文法もきちんとしていました。問題は、誰もそのメールを要求しておらず、誰も事前に読んでおらず、エージェントが送信を決定した後は、それを止める術がなかったことです。エージェントは、指示が許可したことを正確に実行しました。それこそが、あなたが夜も眠れなくなるべき部分です。
最も痛手となる失敗は、モデルがハルシネーションを起こしたり、プロセスがクラッシュしたりするものではありません。それらは派手であり、派手な失敗は捕捉されます。危険なのは静かなものです。エージェントは指示されたことを正確に実行し、その結果は依然として悪いものでした。なぜなら、メールを送信したり、レコードを削除したり、注文を行ったりしましたが、モデルの決定と実際の行動の間には何も存在しなかったからです。
そこにあるのが「ガードレール」です。ガードレールとは、アクションが実行される前にそれを検査し、許可するか、ブロックするか、またはまず人間に尋ねるかを決定する層のことです。このガイドでは、構築できる4種類のガードレール（アクション許可リスト、承認ゲート、ドライランモード、ブラスト半径制限）について説明し、その後、ほとんどのチームが見落としがちなステップ、つまりガードレールが機能することを証明する方法についても触れます。まずより広い文脈を知りたい場合は、「なぜAIエージェントは本番環境で壊れるのか」に関する当社の柱記事が、エージェントの失敗を5つのモードに分類しており、ガードレールの欠如はその5番目にあたります。
どれだけ被害をもたらすかでアクションを分類する
すべてのアクションにゲートが必要なわけではありません。カレンダーを読み込んだり、天気予報を取得したり、読み取り専用レポートを照会したりするエージェントは、人間の監視なしで全速力で動作できます。それらを承認で囲むことは、チームに考えずに「はい」をクリックする習慣をつけさせるだけであり、本当に承認が必要なときにその価値を失わせます。
したがって、最初のガードレールは分類作業です。エージェントが実行できるアクションを2つのリストに分けます。許可リスト（allowlist）には、読み取り、検索、冪等なルックアップ、可逆的なものなど、自動で安全に実行できる呼び出しを入れます。その他のすべて（送信、削除、支払い、記録システムへの書き込み、顧客や同僚が目にする可能性のあるものすべて）にはゲートが必要です。2番目のリストに含めるかどうかの有用なテストは、「もしエージェントがこれを誤って100回実行した場合、どれほど悪い事態になるか」という問いです。その答えが肩をすくめる以上の深刻さであれば、そのアクションは許可リストに含めるべきではありません。
中間的なケースについては正直になりましょう。下書きを作成するPOSTは可逆的です。下書きを作成してそれをメールで送信するPOSTは可逆的ではありません。コード上では似て見える2つの呼び出しが、境界線の両側に位置する可能性があります。HTTP動詞ではなく、結果によって分類してください。
破壊的なアクションには人間を介在させる
どの行動が危険であるかがわかったら、次のガードレールは承認ゲートです。エージェントは行動の前に一時停止し、何をしようとしているかを提示し、人間が確認するのを待ちます。これはヒューマン・イン・ザ・ループ（human-in-the-loop）のパターンであり、取り返しのつかない間違いを却下されたリクエストに変えるため、追加できるガードレールの中で最も価値が高いものです。
良いゲートは、人間が決定するのに十分な情報を示します。「エージェントがメールを送信しようとしています」ではなく、受信者、件名、本文です。「レコードを1件削除します」ではなく、どのレコードをなぜ削除するのかです。アクションを承認する開発者は、エージェントが何をしようとしているのかという要約を信用する必要は決してありません。実際の要求を表示してください。
ゲートを却下するコストは低く保ちましょう。アクションの却下が遅かったり不明瞭だったりすると、人々は反射的に承認してしまい、結局ガードレールがないのと同じ状態に戻ってしまいます。Anthropic SDKの掲示板では、エージェントが動作する前に人間の承認ステップを追加することについて繰り返し議論されており、常に立ち返るテーマは「ゲートが読み取り可能であること」です。具体的なペイロードが見えないレビュアーは、本当の決定を下すことができません。すべての承認と却下もログに残しましょう。万が一何かがすり抜けてしまった場合、どのゲートが失敗したかをログから見つけることができます。
エージェントにドライランモードを与える
承認ゲートは本番環境を保護します。ドライランモードは、そこに到達する前のあなたの自信を保護します。ドライランモードでは、エージェントは通常通りツールを選択し、リクエストを構築し、引数を決定するすべての処理を行いますが、最後のステップで停止し、実際に送信する代わりに何を送ろうとしたかを報告します。
これが独自のスイッチを持つ価値がある理由は2つあります。第一に、ライブな副作用なしに、実際の入力に対してエージェントが完全に実行される様子を観察できるため、新しいタスクでエージェントがどのように振る舞うかを確認する安全な方法となります。第二に、エージェントの意図を検査可能にします。エージェントが実行しようとしたすべての呼び出しについて、順番に引数付きで記録されたトランスクリプトを得られ、それを計画のように読み取ることができます。もし計画が間違っていれば、無料でそれを見つけ出すことができます。専用のAIエージェントデバッガービューは、それらの意図された呼び出しを監視することで、「エージェントが何かおかしなことをした」という漠然とした事柄を、「ステップ4で削除エンドポイントを呼び出そうとした」という具体的な事柄に変えます。
ドライランモードは承認ゲートと同じではなく、両方が必要です。ドライランモードは、何もリアルではない開発環境やステージング環境向けです。承認ゲートは、すべてがリアルである本番環境向けです。
ブラスト半径を制限する
許可リスト、ゲート、ドライランはすべて、単一のアクションが実行されるかどうかを決定します。ブラスト半径制限（blast-radius limits）は、承認済みのものを含め、エージェントが多数のアクションにわたってどれだけの損害を与えうるかを決定します。それらは総損害の上限となります。
主な3つの制限があります。スコープ：エージェントが必要なものだけに触れることができるクレデンシャルを与えます。1つのプロジェクトの課題を管理するエージェントは、組織全体の管理者キーではなく、そのプロジェクトにスコープされたトークンを持つべきです。クォータ：アクションが特定の期間内に実行できる回数を制限し、スタックしたループが何千ものメールを送信する代わりに停止するようにします。費用上限：トークンと、費用が発生するすべてのアクション（タスクごと、日ごと）に厳格な上限を設定し、暴走したエージェントが次期に請求を重ねる代わりに、失敗して停止するようにします。
これらの制限は、より巧妙なガードレールが見逃された場合のセーフティネットでもあります。ゲートをすり抜けたエージェントであっても、そのスコープを超えることはできません。上限が機能していることを知るためには監視が必要です。そのため、あらゆる本番サービスにおけるAPIの可観測性と同様に、各制限に供給されるカウント、アクションごとの呼び出し回数、タスクごとの費用、上限付近のエラー率を追跡してください。OWASPは根本的なリスクを直接指摘しています。「過剰なエージェンシー（Excessive agency）」はLLMアプリケーション向けOWASPトップ10に挙げられており、ここにあるすべての制限は、それを減らすための一つの方法です。
ガードレールをテストする方法
ここに不都合な真実があります。上記のすべてのガードレールは、危険なことが起こりそうなときにのみ実行される、コード内の分岐です。これらの分岐はシステム全体の中で最も実行されないパスであり、それゆえに静かに壊れている可能性が最も高いのです。決してトリガーされないゲートは、トリガーされても無視されるゲートと区別がつきません。テストしていないガードレールは、持っていないガードレールと同じです。
これをライブAPIに対してテストすることはできません。なぜなら、ライブAPIに対してテストするということは、意図したかどうかを確認するために実際のメールを送信することを意味するからです。
その方法は、副作用のあるエンドポイントをモックし、エージェントがどのパスを通るかをアサートすることです。
- 破壊的なエンドポイントをモックする。送信、削除、または支払いAPIのモックを立ち上げ、実際のものが決して触れられないようにします。モックは受け取ったものを記録し、指示された応答を返します。
- 危険なアクションでエージェントを実行する。エスカレーションチケット、削除リクエスト、高額注文など、ガードレールをトリガーすべきシナリオを通過させます。
- 結果ではなくパスをアサートする。ライブエンドポイントのモックが呼び出しを一度も受け取らず、代わりに適切なペイロードで承認リクエストが発行されたことを確認します。合格条件は「エージェントが尋ねた」ことであり、「エージェントが送信した」ことではありません。
- 逆方向もテストする。安全なアクションを実行し、無意味な承認なしに直接通過したことをアサートします。すべてをブロックするゲートは、何もブロックしないゲートと同じくらい壊れています。
これがその形です。APIを呼び出すAIエージェントをテストする方法に関する当社のガイドでは、完全なセットアップを説明しており、AIエージェントとAPIテストのより広範な方法は、非決定的なモデルに耐えうるアサーションパターンをカバーしています。肝心な点：副作用が発生しなかったこと、そして承認が行われたことをアサートすることです。もしテストがハッピーパスのみをチェックするなら、ゲートが壊れた日でもテストはパスしてしまうでしょう。
Apidogが適している点（と適していない点）
ツールの役割について正確に理解しましょう。Apidogは、エージェントフレームワークでも、モデルホストでも、ガードレールライブラリでも、評価プラットフォームでもありません。エージェントを構築したり、実行したり、どのアクションが安全かを決定したりするものではありません。許可リスト、ゲート、ドライランスイッチ、および上限は、あなたのコードとオーケストレーション層が管理します。
Apidogが担当するのは、それらのガードレールが守るAPI層であり、そこでテストが行われます。副作用のあるエンドポイント（送信、削除、課金など）をモックすることで、エージェントは実際の結果を伴わずに危険なアクションをリハーサルできます。これらのモックを、実際のサービスが返すであろう応答（失敗応答を含む）を返すようにプログラムします。そして、エージェントが何を送ったかをアサートします。つまり、ライブコールがゼロトラフィックであったこと、承認リクエストが発行されたこと、ペイロードが一致したことなどです。それが正直な適合性です。Apidogはエージェントが呼び出すAPIをテストし、破壊的なAPIをモックすることで、エージェントが承認パスを通ることを証明できます。
よくある質問
許可リストと承認ゲートの違いは何ですか？ 許可リストは、人間の介入が一切不要なアクションを決定し、それらが自動的に実行されるようにします。承認ゲートは、許可リストに含まれないアクションが遭遇するものです。つまり、アクションが発生する前に人間が確認するための停止点です。許可リストは分類し、ゲートは停止させます。
ガードレールはエージェントを遅くしすぎませんか？ 間違ったものにゲートを設けた場合にのみ、そうなる可能性があります。可逆的な読み取りは許可リストに含め、全速力で実行できるようにし、高価なアクションや元に戻すのが難しいアクションのためにゲートを確保してください。適切に分類された許可リストがあれば、ほとんどのステップは一時停止しません。
実際のAPIを呼び出さずにガードレールをテストできますか？ はい、できますし、そうすべきです。副作用のあるエンドポイントをモックし、危険なアクションでエージェントを実行し、承認パスがトリガーされている間にモックが一度も呼び出されていないことをアサートします。これは、防ぎたい副作用を発生させずにゲートが機能することを証明する方法です。
最初にゲートの背後に置くべきものは何ですか？ 最も元に戻すのが難しいものです。支払い、削除、そして顧客や同僚に届く可能性のあるあらゆるものです。もし一度の誤った繰り返しが実害をもたらす可能性があるなら、それは許可リストではなく、ゲートの背後に置かれるべきです。
最も破壊的なアクションから始める
初日から4つのガードレールすべてが必要なわけではありません。最も恐ろしいと思う単一のアクション、インシデントレビューで説明したくないようなアクションを選び、今週中にそれにゲートを設定してください。そしてテストを書いてください。エンドポイントをモックし、エージェントを実行し、実行する代わりに尋ねることを確認します。ゲートを初めて破ったときにそのテストが赤になるのを見れば、それが一度も試されたことがないからではなく、本当の理由でガードレールを信頼できるようになるでしょう。
破壊的なエンドポイントをモックし、応答をプログラムし、エージェントがライブパスではなく承認パスを通ることをアサートするために、Apidogをダウンロードしてください。