AIエージェントを業務フローに組み込むとき、暴走や誤操作をどこで止めるかを事前に決めておかないと、想定外の処理が実行されてから初めて問題に気づくことになりかねません。ガードレールという言葉は目にしても、それが入力から出力までのどこを、どこまでカバーする仕組みなのかがはっきりしないまま導入を進めてしまう場面は少なくないはずです。
ガードレールは、入力、出力、ツール呼び出しという3つの異なる地点でエージェントの処理を検証する仕組みです。地点ごとに検証できる範囲は異なり、どこにも届かない部分は人間による承認と組み合わせて埋める必要があります。
AIエージェントのガードレールとは何か
AIエージェントのガードレールは、エージェントの実行と並行して、またはその前後にユーザー入力とエージェントの出力を検証するチェック機構です。役割は明確で、有害な出力や、コストの大きい無駄な処理をモデル呼び出しの前後で防ぐことにあります。
エージェントが自律的に判断し、外部のツールを呼び出しながら処理を進める設計になるほど、想定していない入力や意図しない出力がそのまま次の処理へ渡ってしまうリスクは高まります。ガードレールは、このリスクを個別のルールで後から手当てするのではなく、処理の入口と出口にあらかじめ検証点を置くことで扱う仕組みです。
入力・出力・ツールガードレールは何を検証するのか
ガードレールは、検証するタイミングと対象によって、入力ガードレール、出力ガードレール、ツールガードレールの3種類に分かれます。3種類とも検証して止めるという役割は共通していますが、どの地点で、何を対象に検証するかが異なります。この違いを理解しておくと、自社のエージェント構成でどこに検証点を置く必要があるかが見えてきます。
入力ガードレール：最初のエージェントに入る前に検証する
入力ガードレールは、ワークフロー内の最初のエージェントに対してのみ実行され、既定ではエージェントの処理と並列に実行されます。
検証の途中で問題を検知すると、トリップワイヤーが発火してInputGuardrailTripwireTriggered例外が送出され、以降の処理はそこで止まります。ユーザーが入力した時点で問題のある内容が含まれていれば、そこから先の処理には進みません。ワークフローの入口を絞る検証だといえます。
出力ガードレール：最終出力だけを検証し並列実行できない理由
出力ガードレールは、ワークフロー内の最後のエージェントが生成した最終出力に対してのみ実行されます。入力ガードレールとの違いは、エージェントの処理が完了してから検証を始める点です。
途中の出力はまだ確定していないため検証対象にできず、入力ガードレールのように処理と並行して走らせることはできません。エージェントが結論を出し終えるのを待ってから、その結論を渡してよいかどうかを確認する仕組みです。
ツールガードレール：個別の呼び出しを許可・書き換え・例外で制御する
ツールガードレールは、function_tool()で作成した関数ツールを呼び出す前後に挟む検証です。呼び出し前を検証するToolInputGuardrailは、許可、拒否メッセージの返却、例外の送出という3通りの振る舞いから選べます。呼び出し後を検証するToolOutputGuardrailは、許可、ツール出力の書き換え、例外の送出という3通りから選べます。
ただし、適用される対象には限りがあります。対象はfunction_tool()で作成された関数ツールに限られ、hosted tool、handoff、組み込みの実行ツールは含まれません。エージェントが外部のAPIやシステムを呼び出すたびに検証したいと考えても、呼び出しの種類によってはこの仕組みだけでは検証しきれない場合があります。
ガードレールを組み合わせる利点はどこにあるか
入力、出力、ツールという3種類のガードレールを組み合わせる利点は、有害な出力やコストの大きい無駄な処理を、処理の各段階で防げる点にあります。入力は最初の関門として問題のある依頼を止め、ツールは処理の途中で個々の外部呼び出しを検証する役割を持ち、出力ガードレールは、最後に結論そのものを検証する役割です。入口、途中の呼び出し、出口という三つの検証点。どこか一箇所だけを固めても、別の地点から想定外の処理が漏れる可能性は残ります。
実務では、これを入力・処理・出力という3つのフェーズに分けて防御線を配置する整理も使われています。入力段階では有害な内容の遮断や機密情報のマスキング、処理段階ではサンドボックス実行やAPIの許可リストの管理、高リスクな操作への人間承認、出力段階ではハルシネーションの抑制やトーンの管理といった形で、対策を分担させる考え方です。SDKの入力・出力ガードレールとツールガードレールも、この3フェーズに検証点を置くための部品にあたりますが、処理段階の対策全体を代替する仕組みではない点に注意が必要です。
エージェントレベルのガードレールが届かない範囲はどこか
入力ガードレールと出力ガードレールは、どちらもワークフロー内の最初と最後のエージェントにしか作用しません。複数のエージェントが連なるマネージャー型の構成では、この2つだけでは対応しきれない場面が出てきます。
マネージャー役のエージェントが複数のサブエージェントへ処理を振り分け、それぞれが個別にツールを呼び出す構成を考えると、途中のツール呼び出しで発生する副作用は、最初と最後にしか作用しないエージェントレベルのガードレールの対象から外れます。途中のツール呼び出しで副作用が発生しても、入力ガードレールと出力ガードレールだけでは気づけない可能性があります。この空白を埋めるには、各ツール呼び出しの直前直後に、個別の検証や人間承認を挟む設計が必要です。
人間承認とガードレールはどう役割分担するのか
取消、編集、シェルコマンドの実行、機微なMCPアクションのように、実世界への影響が大きい操作は、自動化されたガードレールだけに任せず、人間による承認と組み合わせる設計が向いています。具体的には、ツール呼び出しの実行を一時停止し、人間が内容を確認して承認または却下してから処理を再開する仕組みです。
どちらに向くかを分ける軸は、判定の性質と操作の重さです。定型ルールで可否を判定できる入力、最終出力、function_tool()の呼び出しは自動ガードレールに向き、取消が難しい操作や影響範囲が大きい操作は人間承認に向きます。ガードレールは、あらかじめ定義したルールに沿って機械的に検証し、問題があれば処理を止める役割を担います。取消できない操作や影響が読みにくい操作については、ルールだけで判断を完結させず、人が内容を見て最終判断を下す設計にしておくと、エージェントレベルのガードレールが届かない部分も補えます。
