AI開発したアプリが“使えない”……根本にあるセキュリティ／ガバナンス問題を解消する「一体設計」手法

では、一体設計を実現するにはどんな仕組みが必要なのか？

　一体設計を具体化する仕組みとして、佐藤氏はAgent Evaluations（エージェント評価）とAgent Guardrails（エージェントガードレール）の2軸で解説した。これらの仕組みが、同社が提供するプラットフォームに採用されている。

　同じ問いに毎回同じ答えを返せるか。この再現性を担保するのがAgent Evaluationsという仕組みだ。決まりきったテストケースと期待される結果のセットを用意し、プロンプトやツールを変更するたびに同じベンチマークを再実行して、合格・不合格を可視化する。

　評価対象がAIエージェント部分だけでない点も押さえておきたい。佐藤氏は「サービスアクションという処理全体をまとめてテストすることによって、本番と同じ環境・経路で検証できる点が特徴だ」と続けた。

　評価の流れは5段階。入力と期待値をセットにしたデータセットをアップロードし、サービスアクションとして本番同等の経路で処理を実行する。その際、どのツールが呼び出され、どれだけトークンが使われ、どんな出力が返ったかを記録する。その結果をLLMジャッジが採点し、合格・不合格とスコア比較を含むレポートを出力する。採点基準は正確性、安全性、ガイドライン、ツール軌跡、クエリとの関連性の5項目だ。

　実際の例を通して考えてみよう。たとえば、メール対応のAIエージェントを作成するとする。まず、50件のメール文面と、このパターンならエスカレーション、このパターンなら返金処理といった期待値をセットで用意する。実行して47件が成功、3件が不合格なら、その3件はリグレッションしている。修正して再評価し、50件すべてが合格した段階でリリースするといった流れだ。

AIガードレールは、ステージごとに統制の強さを変える

　Agent Guardrailsは、本番に移行したアプリケーションが正しく制御されて動くことを保証する。エージェントとAIモデルの間に介在する安全・ガバナンス層として、ユーザー入力とモデル出力の双方を監視・強制する仕組みだ。主な機能は以下のとおり。

　ただし、エンドユーザーや業務の都合を考えずに、ただ制御を強力にするだけでは、開発現場に不都合が生じる場合がある。そこでOutSystemsは、ステージごとに制御の強さを変えられる設計を採っている。

　具体的には、開発ステージではプロンプト攻撃保護もPII露出フィルターも有害コンテンツフィルタリングも、ログを記録したうえで処理を継続する。検証ステージではプロンプト攻撃保護のみブロックし、PIIはマスクとログ記録、有害コンテンツはログ記録で継続。そして本番ステージでは、3種すべてをブロックし、エラーとして処理を止める。

　評価で品質を作り込み、ガードレールで安全を守る。佐藤氏は「この2つを取り揃えることで、本番運用レベルのエージェントが完成する」と強調した。