12. ガードレール¶

12.1. ガードレールで確かめること¶

ガードレールの設計は、何を検知したいかを決めてから検査位置を選ぶ、という順番で進めます。検査位置によって検査できる対象が決まっているためです。検知したときの動作（止める／記録する）は、そのあとに決めます。すべてを塞ごうとするのではなく、実際に起きうる失敗（規程にない金額の送信、機微情報の出力など）から逆算して、必要な検査位置と動作を選びます。

設定はエージェント定義の「ガードレール」セクションに、検査位置ごとに追加していきます。1 件ずつ有効・無効を切り替えられるため、動作を確かめたい設定だけを残して他を一時的に無効にする、という調整もできます。

12.2. 検査位置を選ぶ¶

検査位置は、入力・ツール入力・ツール出力・出力の 4 か所から選びます。同じ入出力でも、検査するタイミングによって止められるものが異なります。

外部への送信を止めたいならツール入力に、AI モデルへ送る前の内容を確認したいなら入力に置く、というのが基本的な選び方です。同じ判定スクリプトでも、どの検査位置に置くかによって ctx.tool（ツール名。ツール入力・ツール出力以外の位置では空文字）などの値が変わるため、複数の検査位置で使い回す場合は、この違いを踏まえてスクリプトを書きます。

ツール入力・ツール出力フィルタが検査するのは、通常のツール呼び出しだけです。ナレッジ検索・スキルの読み込みは別の経路で実行されるため、この 2 つの検査位置では検査されません。また、ツール出力フィルタが検査するのは、戻り値の先頭 100,000 文字までです。超えた部分に機微情報があっても、このフィルタでは検知できません。戻り値そのものは切り詰められず、全文が LLM へ渡ります。大きな戻り値を返すツールを検査したい場合は、この上限を踏まえて設計します。

応答の返し方には、実行完了後に結果をまとめて返す「同期実行」と、生成中の文字を順に送る「逐次応答」があり、どちらになるかはエージェントの呼び出し方によって決まります。例えば、ロジックフローの「エージェント実行」タスクは同期実行で、エージェント編集画面のテスト実行は逐次応答です。ガードレールの設定で切り替える項目はありません。

出力フィルタが検査する範囲は、応答の返し方によって異なります。

• 同期実行では、ツール呼び出しを含まない最終応答だけを検査します。LLM がツールを呼び出したラウンドの応答（途中経過）は検査されません。
• 逐次応答では、途中経過を含め、利用者へ送る文字をすべて検査します。送出前にウィンドウ単位で検査し、通過した分だけ送出します。

構造化出力を使う場合は、整形した結果を別に検査します。同期実行では、整形前の本文は検査されません。逐次応答では、整形前の本文も送出前に検査します。

12.3. 動作を選ぶ¶

動作には、止める（BLOCK）・記録する（LOG）・何もしない（PASS）の 3 択があります。どの検査位置でも共通です。最初から止めるのではなく、まず記録するで様子を見てから、必要に応じて止めるへ引き上げる運用を推奨します。

ただし、記録する・何もしないの判定結果は監査ログには残りません。監査ログに記録されるのは、止めると判定した場合だけです。記録するの件数を確認したい場合は、トレース（「実行を追う（トレース）」）でエージェントごとの検査結果を見ます。

ツール入力・ツール出力の検査位置で止めた場合も、そのツール呼び出しだけでなく、実行全体が中止されます。1 回の応答で複数のツールを呼び出している途中でも同様です。

同一の検査位置に複数のガードレールを設定した場合、登録順に評価されます。いずれかが止めると判定した時点で打ち切り、それ以降は評価されません。

12.4. 判定スクリプトを書く¶

判定は、function run(input, ctx) { ... }の形式で書く判定スクリプトによって行います。構文はあらかじめ検証されないため、書いたら必ずテストします（「保存前にテストする」）。

判定スクリプトは、IM-LogicDesignerのユーザ定義スクリプトと同じ処理系・同じ API で動きます。テナント DB の参照・更新、ストレージへのアクセス、メール送信、外部通信など、業務用スクリプトと同等の操作が行え、実行時間の上限もありません（上限があるのは命令数だけです。「失敗したときの扱い」）。判定スクリプトは検査のためだけに使い、副作用のある操作は書かないようにします。

function run(input, ctx) {
  var words = ["機密", "社外秘"];
  for (var i = 0; i < words.length; i++) {
    if (input.indexOf(words[i]) !== -1) {
      return { action: "BLOCK", message: "社外秘の語が含まれています" };
    }
  }
  return { action: "PASS" };
}

12.5. 逐次応答の検査設定¶

逐次応答（ストリーミング）では、出力を一定の文字数ずつに区切って検査してから利用者へ送出します。区切り方はエージェントに 1 組だけの設定です（検査位置ごとではありません）。

ウィンドウサイズ（一度に検査する文字数）は 64〜8192 文字の範囲で指定でき、既定値は 512 です。オーバーラップ（区切り目をまたぐ語を見落とさない量）は 0 以上、かつウィンドウサイズの半分（小数切り捨て）以下で指定でき、既定値は 128 です。この上限を超える値は保存できません。

ウィンドウサイズ分の文字が溜まるまでは検査も送出も行われないため、ウィンドウサイズを大きくするほど、最初の応答が画面に表示されるまでの時間は長くなります。

見つけたい語や句がオーバーラップの文字数より長いと、区切り目をまたいだときに検出できないことがあります。長い語句を確実に検知したい場合は、オーバーラップを広げます。

オーバーラップの部分は、前後 2 つのウィンドウの両方で検査されます。この範囲に記録する（LOG）条件に合う語があると、発動が 2 回記録されることがあります。

逐次応答では、あるウィンドウで止めると判定しても、それより前のウィンドウはすでに利用者の画面に送信済みです。この送信済みの内容を取り消すことはできません。

12.6. 保存前にテストする¶

保存前にテスト機能で動作を確認できます。検査文字列（入力・出力フィルタの場合は文章がそのまま渡る、ツール入力・ツール出力フィルタの場合はツールの引数を模した JSON 文字列が渡る）とツール名を指定し、判定スクリプトをその場で 1 回だけ実行します。結果には、動作（止める／記録する／何もしない）、文言、所要時間（ミリ秒）が表示されます。

図：ガードレールのテスト画面。判定スクリプトに対して検査文字列を渡し、動作・文言・所要時間を確認できる。

テスト実行はサーバ側で判定を 1 回動かすだけで、エージェント自体は動きません。想定した入力に対して、意図した動作が返るか、messageが期待どおり表示されるかを確かめてから保存します。

12.7. 発動状況を確認する¶

止める（BLOCK）と判定した場合だけが監査ログに記録されます。記録する（LOG）の発動件数は監査ログでは追えないため、トレースのガードレールの検査結果で確認します。

12.8. 困ったときの確認¶