※本記事は、AWS AI and Data Conference 2026「Building Safe AI Agents」セッションの内容を基に作成されています。本セッションでは、AIエージェントが発言できる内容と実行できる行動の両面を制御する仕組みが紹介されており、エージェントの入出力コンテンツをフィルタリングするAmazon Bedrock Guardrailsと、エージェントの行動にルールを適用するAmazon Bedrock AgentCore Policyについて解説されています。顧客対応エージェントや社内自動化の構築、エージェントの安全性評価手法の検討に取り組む方に向けた内容となっています。登壇者は、AWSのプリンシパルソリューションアーキテクトであるAmit Lulla氏、AWSのシニア応用科学者であるBenjamin Kiesl-Reiter氏、Genesysのエンジニアリングマネージャー(AI/ML)であるJohn Sexton氏の3名です。本セッションは、2026年3月12日にアイルランド・キルケニーのLyrath Convention Centreで開催された第5回AWS AI and Data Conference 2026にて収録されました。本記事では、セッションの内容を要約しております。なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご視聴いただくことをお勧めいたします。AWSイベントの詳細については、https://go.aws/events をご参照ください。
1. イントロダクション
1.1 登壇者紹介と問題提起
Amit: 皆さん、こんにちは。私はAmit Lulaと申します。AWSでプリンシパルソリューションアーキテクトを務めております。本日は応用科学者のBenと、そしてGenesysのJohnにもご登壇いただきます。Johnには、プロトタイプから本番環境へと至った彼らの実際の旅路についてお話しいただく予定です。本題に入る前に、皆さんに一つ質問をさせてください。皆さんの組織で、AIエージェントや生成AIを活用したものを本番環境で構築されている方は挙手をお願いします。ありがとうございます、多くの方が手を挙げてくださいました。それでは、そのまま手を挙げ続けてください。もし、皆さんのセキュリティチームやコンプライアンスチームが、それを正式に承認しているという方だけ手を挙げたままにしてください。ご覧の通り、ここでかなりの数の手が下がりました。まさにこれが、私たちが本日ここに集まった理由です。「動くこと」と「承認されること」は、まったく別の話なのです。
1.2 本番導入と承認のギャップ
Amit: 皆さんが構築したソリューションを顧客の前に出すとき、そのアプリケーションが本来意図した通りの振る舞いをすることを保証しなければなりません。先ほどの挙手の結果が示す通り、多くの組織では「動作するプロトタイプを作ること」自体はそれほど難しくありません。しかし、それをセキュリティチームやコンプライアンスチームの審査に通し、実際に顧客の手に渡せる状態にすることには、また別の困難が伴います。この「動くけれど承認されない」というギャップこそが、本日私たちが取り組むべきテーマです。
1.3 セッションの3つの柱
Amit: 本日は大きく3つのことについてお話しします。1つ目は、皆さんが設定可能な安全網、つまりガードレールです。2つ目は、宣言的なルールです。こちらについてはBenが、ポリシーという仕組みを通じて詳しくご案内します。そして3つ目には、Genesysの事例を通じて、実際に現場でこれらがどのように機能するのか、いわば「机上の議論が実際の道路に着地する瞬間」を皆さんにお見せします。今朝すでに私たちのAIポートフォリオ全体についてはご紹介済みですので、本日はその中でも特にガードレールとポリシーという層に焦点を絞ってお話しします。AIを使って何が作れるかについては既にお話ししましたが、ここからは、AIを使って作ったソリューションが、安全な形で、皆さんが求める通りに動作することを保証する方法についてお伝えしていきます。
2. Guardrailsによる安全網
2.1 生成AIアプリの基本構造とリスク
Amit: ここからは、皆さんが思い浮かべることのできる最もシンプルな生成AIアプリケーションについてお話しします。それは3つの基本要素から成り立っています。アプリケーションロジック、プロンプト、そしてモデルです。では、これを実際に顧客の前に出したとき、何が起こるでしょうか。私が最近、ある顧客と交わした会話をご紹介したいと思います。その顧客はカスタマーサービス向けのチャットボットを構築していました。デモにたどり着くまでにかかった期間はわずか2週間でした。そのデモをチーム全体、CEOも含めて披露したところ、CEOはそのデモを大変気に入り、すぐにでも本番展開したいという意向を示しました。しかし、その後にセキュリティレビューが行われることになりました。
2.2 顧客事例:セキュリティレビューでの発覚
Amit: そのセキュリティレビューの中で、非常に興味深い事実が明らかになりました。このアプリケーションを実際にユーザーの手に渡したとき、あるユーザーが「投資アドバイスをください」といった内容を入力しようとしたのです。これはコンプライアンス上のリスクにほかなりません。また、もしエンドユーザーが自分のパスポート番号をチャットボットに入力してしまったらどうなるでしょうか。これはデータセキュリティおよび保護の問題です。さらに、ユーザーがプロンプトをうまく操作して、何らかの不快な内容を生成させてしまう可能性もあります。これはブランドに関わるリスクです。こうした問題が明らかになったことで、顧客はそもそも自分たちでこうしたソリューションを一から構築すべきなのか、それとも既製のサービスを活用すべきなのかを検討することになりました。そして、まさにこれこそが私たちがここにいる理由なのです。アプリケーションコードを保護し、それが本来意図された通りに動作するようにすることができます。プロンプトはハイジャックされる可能性がありますし、これもまた一つの攻撃手法です。そしてモデルはハルシネーションを起こす可能性があります。しかし、こうしたコンポーネントの3つの側面をこの層でカバーすることによって、アプリケーションを正しい形で振る舞わせることができるのです。では、なぜこれを実現するのがそれほど難しいのでしょうか。ここで私たちがどのようにお手伝いできるかをご紹介します。
2.3 Guardrailsの仕組みと独立利用
Amit: Guardrailsは私たちのマネージドサービスであり、セキュリティに関するあらゆるコンポーネントと機能をそのまま提供します。これにより、皆さんはこうした差別化要因にならない作業ではなく、自分たちのアプリケーションロジックやビジネスロジックに集中することができます。仕組みは非常にシンプルです。先ほどのチャットボットの例に戻りましょう。まず、ユーザー入力があります。皆さんはその会話に対してガードレールIDを設定します。アプリケーションに組み込むと、ユーザー入力はガードレールを通過します。それが通過し検証されれば、モデルへと渡されます。モデルは応答を生成しますが、これについても再度保護、あるいは検証を行いたい場合があります。ハルシネーションを起こしていないか、事実でない応答を顧客に返していないかを確認するためです。それも通過すれば、最終的な結果がユーザーに届く、という流れです。非常にシンプルな仕組みですが、実はもう一つ、多くの顧客が活用していないにもかかわらず、本来活用すべきシナリオがあります。皆さんがBedrockを生成AIアプリケーションで使っているかどうかに関わらず、皆さんのアプリケーションから独立してGuardrailsを呼び出し、評価に利用することができるのです。例えば、社内文書を公開する前に、PIIがきちんとマスクされていることを確認したい場合もあるでしょう。あるいは、今では多くのコーディングエージェントを利用されていると思いますが、公開前にシークレット情報や環境変数が漏洩していないかを確認したい場合にも活用できます。このように、この基本フロー以外の場面でも、Guardrailsは独立して利用することができるのです。
2.4 フィルタ設定とモード制御
Amit: Guardrailsに何が含まれているかについてお話しします。多数のフィルタが用意されており、ここでは6種類をご紹介します。ヘイト、侮辱、そのほかにも性的な内容、暴力、不正行為、プロンプト攻撃といったものが含まれます。顧客向けのアプリケーションであれば、これらのフィルタそれぞれの感度レベルを最大に設定したいと考えるかもしれませんし、逆に社内向けのアプリケーションであれば、プロンプト攻撃に対する感度は非常に重要視する一方で、他の項目についてはやや緩めに設定したいということもあるでしょう。つまり重要なのは、アプリケーションごと、シナリオごとに、これらを個別に自由に設定できるという点です。設定できるのはこうした感度だけではありません。通過しようとする内容をブロックするモードにするか、あるいは検出モード、つまりモニタリングモードにするかを選ぶこともできます。アプリケーションを最初にリリースする段階では、まず検出モードに設定することをお勧めします。これは、内容を分析・確認しつつも、ブロックはせずに皆さんに通知するというモードです。そして、アプリケーションにとって適切な感度レベルを調整できたところで、ブロックモードへと切り替え、本番環境へと展開していくことになります。ユーザーからの入力内容をブロックしたり、モデルが生成する出力を検証したりするだけでは十分ではありません。だからこそ、評価の対象を入力の一部にするか、出力の一部にするか、あるいはそのすべてにするかについても設定を行えるようにしています。つまり、入力と出力の両方に対して、どこまで制御するかを皆さんがコントロールできるということです。
2.5 決定論的/確率論的制御と階層タイプ
Amit: ここで、皆さん全員にぜひ持ち帰っていただきたい重要なポイントをお伝えします。それは2つの制御方法があるということです。1つ目は決定論的な制御です。同じ入力に対しては常に同じ出力が返ります。監査可能であり、証明可能なものです。2つ目は確率論的な制御です。これは複雑な自然言語理解が必要な場面で用いられます。アプリケーションが評価すべきすべてのシナリオを一つひとつ定義することは現実的ではありません。だからこそ、確率論的な制御が必要になるのです。しかし現実には、この2つは一方だけでなく両方が必要になります。ワードフィルターや、PIIが確実にマスクされているかの確認、投資アドバイスといった特定のトピックをアプリケーション内で扱わないようにすること、あるいは特定のシナリオのみに限定し、ドキュメントに基づいた応答のみを返すようにすること、こうした場面ではまさに両方の組み合わせが求められます。そして、Guardrailsの優れた点は、この2つの制御を同じ呼び出しの中で組み合わせて使うことができるという点です。別々に扱う必要はありません。次に機能面についてお話しします。Guardrailsには2つのティアがあります。Classicとstandardです。速度を求めるのであればClassic、より多くの言語サポートや精度を求めるのであればstandardということになります。顧客のユースケースに合わせて、これら2つを組み合わせて使うこともできます。
2.6 コーディングエージェントへの応用
Amit: 皆さんの多くはすでにKiroやClaude Codeといったコーディングエージェントを利用されていると思います。これらは人間が検証できるスピードをはるかに超える速さでコードを生成します。これもまた、Guardrailsを活用すべき領域の一つです。AIが皆さんのコードのために生成した出力、つまり変数、メソッド、関数、そして数多くのクラスが定義された内容についても、プロンプトの漏洩がないか、あるいはPIIが生成されていないか、あるいは皆さんの組織固有のエンティティに関する文脈が含まれていないかを検証すべきです。こうした検証にもGuardrailsを活用することができます。
2.7 スケール課題と適用レベル
Amit: 先ほどご紹介した顧客との会話に話を戻します。セキュリティレビューを終えて展開の準備が整った際、彼らはこう言いました。「これは素晴らしいのですが、私たちには定期的にこうしたコードを展開する15のチームがあります」と。これはまさにスケールの問題です。私たちが話しているのは2つや3つのガードレールを適用するという話ではなく、組織全体のスケールで、15もの異なるチームについて考えなければならないという話なのです。そこで、Guardrailsは3つのレベルで適用することができます。まず、アプリケーションレベルです。個々のアプリケーションに合わせて構成されたガードレールを設定できます。次に、アカウントレベルで一定のガードレールを定義することができます。そのアカウントで実行されるあらゆるワークロードは、これらのガードレールを必ず通過することになります。そして最後に、AWS組織全体のレベルで一定のルールとガードレールを設定することができます。これはつまり、組織として「生成AIアプリケーション内のあらゆる種類のPIIはマスクされるべきである」といったルールを定めることができるということです。これは組織レベルで適用することが可能です。ここまで、Guardrailsを用いた設定可能な安全網についての制御についてお話ししてきましたが、では、確実性が必要な場合はどうすればよいのでしょうか。証明可能なルール、つまり宣言され、常に同じ振る舞いをするルールです。この点については、Benにバトンをお渡しして、ポリシーについて説明してもらいたいと思います。ありがとう、Ben。
3. 自動推論とポリシー
3.1 自動推論の定義と基本概念
Ben: 皆さん、こんにちは。私はBenと申します。AWSの自動推論グループで応用科学者を務めております。先ほどAmitが申し上げた通り、ここからは確実性についてお話しします。確実性というテーマにおいて、自動推論というアプローチは多くの場面でその確実性を得るための助けとなります。私は、自動推論こそが証明可能な保証を通じて本番運用可能なエージェントへの道筋を提供すると考えています。ここで重要なのは、まさにこの「証明可能である」という点、つまり証明可能性そのものです。この点について、これから詳しくご説明していきます。まず自動推論の定義からお話ししましょう。ここで自動推論とは何かについて講義をすべてお伝えすることはできませんが、その考え方をぜひ皆さんにお伝えしたいと思います。まず、私たちのグループを率いる著名な科学者であるByron Cookの言葉を引用したいと思います。彼は「自動推論とは、新しい数学的証明をアルゴリズムによって探索することである」と述べています。この言葉にはいくつかの要素が含まれています。名前の通り「推論」という部分があり、そして引用の中にもある通り「数学」という部分もあります。これは数理論理学を用いて前提から結論を導き出すという営みだからです。つまり私たちは数学を行っているのですが、それを自動化された方法で行っている、というのが「自動」の部分です。大規模な探索空間を高速に探索する専用のアルゴリズムが存在し、前提から結論を導出するこの過程を担っています。そして最も重要な部分が証明可能性です。なぜなら、皆さんが独立して検証できる証明が得られ、それによって、単にテストしたケースだけでなく、無限の入力に対する正しさの保証が得られるからです。最高レベルの保証を求める場合、テストは良い出発点ではあります。入力空間のある部分についてはカバーできますし、あらゆる種類のテストを活用することができます。しかし、入力空間全体について本当に主張をしたいのであれば、そこで自動推論の出番となるのです。これは、先日のre:Inventカンファレンスで、私たちのシニアバイスプレジデントであるPeter DeSantisが自動推論について話している際の写真です。彼がこのテーマを取り上げたのには理由があります。AWSにおいて自動推論はこれまで長年にわたり非常に大きな注目を集めてきており、この分野において世界的に著名な専門家がAWS社内に在籍しています。例えば、AIが競技数学の問題を解く際に使われている対話型定理証明系Leanについて耳にされたことがあるかもしれません。Leanの開発者たちは、私たちの自動推論グループの一員です。私たちはこれまで、自動推論が顧客にとって本当に役立つさまざまな製品を生み出してきました。その理由は、顧客がセキュリティ、プライバシー、コンプライアンス、整合性、可用性といったものを私たちに求めているからです。そして、こうしたテーマにおいては、最高レベルの保証こそが決定的に重要であり、自動推論がまさにその答えとなり得るのです。
3.2 AWSでの実績と製品事例
Ben: 先ほど「無限の入力、単なるテストケースではない」ということについて触れましたが、これが実際にはどういうことを意味するのか、いくつか例を挙げてご説明します。例えば、ある顧客はこう尋ねるかもしれません。「私のバケットポリシーは、無制限の公開アクセスを決して許可していないだろうか」「私のデータは常に保存時にも転送時にも暗号化されているだろうか」「あらゆる認可リクエストにおいて、denyは常にallowよりも優先されるだろうか」「PCIタグが付与された私のインスタンスは、アカウントの管理下にない外部のマシンから決して到達可能にならないだろうか」「私の鍵は決してアカウントの管理下の外に漏洩しないだろうか」。ご覧の通り、「決して」「あらゆる」「常に」といった普遍的な表現が数多く使われています。こうした主張について、単に「このテストケースで試してみた、なんとなくうまくいっているようだ、エッジケースはすべてカバーしたと思う、大丈夫だろう」というレベルではなく、普遍的な主張、つまり証明をしたいというニーズがあるのです。自動推論を用いて私たちがリリースした製品の例をいくつかご紹介します。AWS IAM Access Analyzerは、どのデータやリソースがどこからアクセス可能かというアクセス制御に関する問いに答えるものです。Reachability Analyzerは、VPC内の特定のデータベースが外部から到達可能かどうかという問いに答えます。S3 Block Public Accessは、皆さんのS3バケットが本当に安全であるか、本当にプライベートであるか、あるいは公開アクセス可能になっていないかを確認するものです。また、AWS社内では暗号化アルゴリズムの検証にも取り組んできており、成功を収めています。一度実装が検証されれば、その実装が正しく、意図した通りに動作するという保証があるため、非常に速いスピードで開発を進めることができます。さらに、AWSの認可ロジックそのものの正しさについても、社内で証明が行われています。これらはほんの一例に過ぎませんが、ここまで聞いて、これがエージェントとどう関係するのか疑問に思われている方もいるかもしれません。
3.3 ニューロシンボリックAI
Ben: ここで関係してくるのが、近年注目を集めているニューロシンボリックAIというアプローチです。ニューロシンボリックAIとは、ニューラルアプローチ、つまり機械学習やLLMと、自動推論、つまりシンボリック推論とを組み合わせたものです。ご存知の通り、ニューラルアプローチは創造性、パターン認識、柔軟性、データからの学習に非常に優れていますが、その代償としてハルシネーションのリスクが伴います。先ほどの別のセッションでどなたかがおっしゃっていたように、ハルシネーションはバグではなく機能だという意見もあります。確かに創造性とともに生まれてくるものではありますが、正直なところ、常にハルシネーションが欲しいわけではありません。一方、自動推論は、私が先ほど申し上げた通り、論理的な演繹、形式的な検証、精度、決定論的な性質、証明可能な保証をもたらします。そしてもちろんハルシネーションはありません。なぜなら、これらは明確なアルゴリズムに基づいて数学的に推論する決定論的なシステムだからです。この2つを組み合わせると、両方の長所を兼ね備えたものが得られます。つまり、ニューラルアプローチによる創造的な生成と、検証済みの出力とが組み合わさり、柔軟性と信頼性の両方を得ることができ、その結果として信頼できるAIが実現するのです。これが実際にどのように機能するかの一例をご紹介します。皆さんがLLM、あるいはエージェントに対して、何らかのコードを生成するようリクエストを送るとします。LLMは最初のコードを生成し、それを自動推論の検証器に送ります。すると検証器からフィードバックが返ってきます。検証器は「いいえ、これはこの性質を満たしていません」というように応答するかもしれません。そしてまたフィードバックが提供されます。LLMはそのフィードバックを踏まえてコードを再生成します。これを繰り返すループの中で、ある時点で自動推論検証器が「これで良い、出荷しよう」と判断します。そして、そのコードは求められていた性質が満たされているという保証とともにユーザーへ返されるのです。ここまでで自動推論が理論的に何を提供できるかについての基本をお伝えしましたので、次にエージェントを堅牢にするために私たちがどのようにこれを活用しているか、2つの例をご紹介します。1つはAmazon Bedrockのガードレールにおける自動推論チェックです。これは、エージェントが何を発言できるかを制御するものです。もう一つは、Agent Coreにおけるポリシーで、こちらはエージェントが何を実行できるかを制御するものです。そして、この両方に自動推論が組み込まれています。
3.4 自動推論チェックの仕組みと検証例
Ben: まず自動推論チェックからご説明します。考え方は次の通りです。あるチャットボットがあるとします。ある人が質問をします。この例では、会社の休職制度について尋ねています。「私はバンド3で、この会社で7年間働いています。有給の休職を取得する資格はありますか」と尋ねたとします。すると、そのチャットボットは考え、「はい、あなたは有給の休職を取得する資格があります」という回答を返してくるかもしれません。さて、ここで問題になるのは、この回答は正しいのか、特に、会社の休職に関するポリシーに照らして正しいのかという点です。これこそが本質的な問いなのです。では、自動推論チェックはこの正しさをどのように検証するのでしょうか。ここに簡略化した休職ポリシーがあるとします。実際にはこうしたポリシーは複数ページにわたることもありますし、文書リポジトリの中にPDFとして保存され、「もし何々ならば、何々である」という形で、多くの場合非常に論理的な形で記述されています。ここでは簡単な例として、「在籍年数が6年を超え、かつバンド3以上、あるいはバンド5以上の従業員は、有給の休職が認められる」というポリシーを想定します。自動推論チェックがこれに対して行うのは、これを論理形式、つまり数理論理学の形式に変換するということです。ここがまさにニューロシンボリックの部分であり、LLMがこの文章を受け取り、論理へと変換します。皆さんが論理を理解している必要はありません、おおよそのイメージは掴んでいただけると思います。つまり、変換された論理式は「在籍年数が6より大きく、かつバンドが3以上、あるいはバンドが5以上であれば、資格がある」という形になります。これがそのポリシーの論理的な表現です。自動推論チェックが可能にするのは、人間の専門家がこのポリシーを見直し、正しく変換されているかを確認できるということです。専門家が確認する必要は必ずしもありませんが、自然言語には曖昧さが含まれることがあり、専門家だけがそれを解消できる場合があります。専門家が「いや、私たちが本来意図していたのはこちらであって、そちらではない」と指摘できるということです。しかし、いったんこの表現ができあがれば、それを決定木のようなものとして見ることもできます。同じものを別の形で解釈しているだけです。そして、これを用いて実際の回答を検証していきます。先ほどの例では、この人はバンド3だと言っていますので、これも論理に変換します。バンド=3です。そして、7年間この会社で働いていると言っていますので、在籍年数=7です。この場合、資格があるということになります。なぜなら、エージェントが述べているのは基本的に「バンド3で在籍年数が7であれば、有給の休職の資格がある」ということだからです。ここで自動推論チェックは、形式化されたポリシーを持ち込み、この2つを比較し、自動推論を行い、この場合には「これは妥当な主張である」という結論に達します。そして、これが正しい回答であると承認するのです。では、これを少し変えてみましょう。今度は同じくバンド3ですが、在籍年数は4年だとします。それでも回答は「はい」だったとします。この場合、なされている主張は「バンド=3かつ在籍年数=4であれば、休職の資格がある」というものになります。この場合、自動推論チェックは「いいえ、これは無効です。これはポリシーに照らして正しい回答ではありません」と判断し、これをフラグとして示します。これが自動推論チェックの概要です。ここからポリシーの話に移りたいと思います。自動推論チェックはエージェントが何を発言できるかを制御するものでしたが、ポリシーはエージェントが何を実行できるかを制御するものです。
3.5 Agent Coreのポリシーとcedar言語
Ben: あるエージェントがあり、それが世界と相互作用しているとします。そのエージェントは在庫データベースに書き込みを行うかもしれませんし、社長宛にメールを送るかもしれませんし、500ドルの返金処理を行うかもしれませんし、あるいは20ドルの返金処理を行うかもしれません。さて、こうした行為の中には、皆さんが起こしてほしくないと考えるものもあるはずです。もう少し慎重になり、「エージェントには一定のことは許可するけれど、すべてを許可するわけではない」と言いたい場面があるでしょう。まさにそこにポリシーが登場します。ポリシーとは基本的に、エージェントの周りに巻きつけられた盾のようなものであり、エージェントが実際に世界と相互作用する際に何ができるかを制御するものです。つまりポリシーは「在庫データベースへの書き込みはまったく問題ない、20ドルの返金処理も問題ない、しかし社長宛のメール送信や500ドルの返金処理は許可されない」と定めることができます。そして、エージェントはそれを行うことができなくなるのです。ここで問題となるのは、こうしたポリシーをどのように定義するかということです。エージェントに何を許可し、何を許可しないかをどのように定義するのか。ここでCedar言語が登場します。Cedar言語は、何が許可されるかを正確に指定することを可能にします。後ほど見ていく通り、この言語はAWSにおいて自動推論のために開発されたものです。この例を見ていきましょう。何が、いつ許可されるかを記述することができます。この例では、誰が許可されるか、つまりAgent Coreのオフユーザーが何をすることを許可されるのか、返金処理を実行することを許可されるのか、どこで、つまり返金ツールに関連する特定のAWSリソース上で、そしてどのような条件下でかというと、ユーザー名がrefund agentであり、かつ処理される金額が500ドル未満である場合に、これが許可されるという形で記述します。そして先ほど申し上げた通り、Cedarの興味深い点は、これがAWSにおいて自動推論のために構築されたものだという点です。こうしたポリシーを定義した際には、Cedar Analyzerと呼ばれるツールを使ってこれらのポリシーを分析し、皆さんのポリシーセットについて一定の保証や確証を提供する主張をすることができます。皆さんはこのような疑問を持つかもしれません。「私のポリシーは広すぎないだろうか」「このポリシーには決して適用されない、つまり不可能な条件が含まれていないだろうか」「私のポリシー同士が互いに矛盾していないだろうか」。ポリシーのセットを作成する中で、意図せずして矛盾するものを作ってしまうことがあります。Cedar Analyzerはそれを教えてくれます。「このポリシーセット全体があらゆるものを許可、あるいは拒否する状態になっていないだろうか」。これについてもCedar Analyzerが教えてくれます。これが、私たちのAIポートフォリオにおける2つの例、すなわちガードレールとポリシーについてのご紹介でした。ここからは、Genesysから来ていただいたJohnに、Genesysが実際にこれらをどのように活用して本番運用可能なエージェントを実現しているかについてお話しいただきます。ありがとうございました。
4. Genesysの実装事例
4.1 Genesys Cloudと Co-pilot導入背景
John: どうもありがとうございます、Benjamin。皆さん、こんにちは。私はJohn Saxonと申します。Genesysでエンジニアリングマネージャーを務めております。本日は、Genesys Cloudにエージェント層を追加してきた私たちの取り組みについてお話しします。Genesys Cloudは、コンタクトセンターおよびカスタマーエクスペリエンスのプラットフォームです。これがどういうことかと申しますと、私たちには数多くの製品がありますが、最も基本的なレベルでは、音声やメッセージングプラットフォームを通じて、コンタクトセンターのエージェントと顧客とをつないでいます。また、顧客企業がボットを設定し、それを顧客との最初の接点として機能させることも可能にしています。これにより、必ずしも毎回人間のエージェントにエスカレーションする必要がなくなります。スーパーバイザーや管理者は、コンタクトセンター全体を分析・モニタリングし、どのエージェントがオンラインであるかを確認したり、他のエージェントのパフォーマンスを見たり、コンテインメント率、つまりボットとの最初のやり取りの後にエージェントへエスカレーションした人の割合といったKPIをモニタリングしたりしています。また、コンタクトセンターの稼働中のフローについても設定を行います。例えば、スペイン語の顧客対応キューがあり、キューにおける顧客の滞在時間、つまりハンドルタイムが1時間前は5分だったのに、今では10分から15分に増えてしまった場合、私たちは積極的にスペイン語対応可能な人材を見つけ出し、そのキューに配置する必要があります。そこで「もし10人のスペイン語話者を異なるキューから見つけ出したら、コンタクトセンター全体にどのような影響が出るだろうか」「特定のキューから10人を引き抜いたら、そのキューは滞ってしまわないだろうか」「そのキューにはそれだけの余力があるだろうか」といったことを検討する必要があります。これが、スーパーバイザーや管理者が行う、複雑な深い業務へとつながっていきます。これが複雑である理由は、こうしたことをすべて把握し分析するために、いくつものUIパネルを行き来しなければならないことが想像していただけると思うからです。そこで登場するのが、Genesys Cloud Co-pilotです。これは、Genesys Cloudの上に乗るエージェント層であり、定型的かつ複雑なタスクを加速させ、データ分析やリアルタイムでのトラブルシューティングを支援し、複雑な設定作業の負担を軽減します。そして最も重要な点は、皆さんが気づいていないようなボトルネックがあったとしても、それに気づかせることなく設定を最適化できるということです。例えば「もしこの部分を並べ替えれば、フローを最適化できます」といった提案をしてくれるのです。私たちは、エージェント、スーパーバイザー、管理者という3つの主要なペルソナそれぞれに対応するAIエージェントを用意しました。これは日々の業務において信頼できる会話のパートナーです。先ほど申し上げた通り、私たちはこのエージェントをモジュール化しました。誰もがオーケストレーターと対話しますが、組織内での役割に応じて、例えばキューへのユーザーの追加や削除ができるようにしたい場合もあれば、単なるエージェントであれば自分の休暇情報を確認できたり、より多くのナレッジやドキュメントにアクセスできたりすることを望む場合もあります。そして、これはすべての従業員を後押しするものであり、彼らのパフォーマンスを向上させ、Genesys Cloud内でのフォースマルチプライヤーとなることを目指しています。
4.2 安全性の重視点とKPI運用
John: Genesys Cloud Co-pilotを開発するにあたって設定した主要な目標についてお話しします。私たちは1,000を超えるツールをサポートすること、16の異なるリージョンへの展開、15の異なる言語への対応を目指しました。また、レイテンシはメッセージあたり5秒を超えないこと、そしてメッセージあたり約5,000トークンの使用を目標としました。こうした目標はどれも重要ですが、それと同時に安全性についても考慮しなければなりません。まず考えるべきは、セキュリティがどれだけしっかりと適用されているかという点です。通常のCo-pilot、あるいはGenesys Cloud UIを見たとき、私たちはCo-pilot内でGenesys Cloudにおける権限以上の権限を持たせたくありませんでした。次に、ハルシネーションを排除したいと考えました。Co-pilotに不完全な情報しか提供されなかった場合に、それを勝手に作り上げて空白を埋めることは望んでいません。ユーザーと共に空白を埋め、正しく動作してほしいのです。そして最後に、入力と出力がきちんと規制されており、ユーザーとエージェントの双方が互いに誤った内容を発言しないようにしたいと考えました。そして、そのためのKPIが100%のエージェント評価合格率です。開発の過程で、私たちはテストケースとして機能するモデル会話を作成しています。Co-pilotの新しいバージョンを作成する際には、それを下位環境にデプロイし、これまでに数百件にのぼる会話を蓄積したエージェント評価を実行します。これは毎時間バックエンドと相互作用し、本番環境にデプロイする前に、24時間にわたって一件の失敗もなく完走することが求められます。
4.3 アーキテクチャとエージェント設計
John: それでは、Genesys Cloud Co-pilotのアーキテクチャについて見ていきましょう。ユーザーのリクエストはパブリックAPIを経由してルーティングされ、Lambdaを実行するサーバーレスバックエンドへと転送されます。エージェント側にはStrands Agentsフレームワークが使われています。まずS3から会話履歴を取得し、それをBedrockのモデルランタイムへとルーティングします。すべての入力と出力はBedrock Guardrailsによって規制されます。また、Genesysに関するドメイン固有の知識が必要な場合には、公開されているすべてのドキュメントがナレッジベースに保存されているため、そこから取得することができます。そして最終的に、WebSocketサービスを通じて非同期にユーザーへ応答を書き戻します。単にメッセージを返すだけでなく、進捗の更新も返すことができます。例えば「ユーザーのプロファイルを取得しています」「キューに追加しています」といった具合です。処理を進める中で、こうした更新を都度返していきます。ここからは、もう少し踏み込んで、エージェントがどのように設計されているかを見ていきましょう。私たちには、ユーザーと直接対話する単一のオーケストレーターエージェントがあります。ユーザーと直接対話するのはこのエージェントだけです。オーケストレーターは会話コンテキストとツール実行の履歴を保持し、ドメイン固有のタスクをスキルエージェントへと委譲します。スキルエージェントとはツール呼び出しを通じてのみやり取りします。これはつまり、ユーザーの役割や権限に応じてエージェントを組み込んだり外したりできるということです。オーケストレーターは特定のドメインに深く結びついていません。オーケストレーターとドメイン固有のタスクとの間には明確な分離点があります。オーケストレーターはスキルエージェントと接続していますが、スキルエージェントはあくまでオーケストレーターに対してツールとしてのみ相互作用し、実際の顧客と直接やり取りすることは決してありません。スキルエージェントはステートレスであり、以前の呼び出しを一切保持しません。そのため、以前のコンテキストはすべてオーケストレーターに依存する形になっています。これにより、使用するトークン数を抑えられるだけでなく、すべての情報がどこを流れているかを一箇所で把握できるという利点もあります。各スキルエージェントには、ドメイン固有の小規模なツール群が用意されています。例えば管理者であれば、ユーザーの管理、追加・削除、キューの作成などができるようにしたいでしょう。しかし単なるエージェントであれば、自分のタイムシートを見たり、多少のナレッジにアクセスしたりできれば十分です。ここで一例として、1回のやり取りをご覧いただきます。ユーザーからのリクエスト、「こんにちは、John Sextonのプロファイルに管理者ロールを追加したいのですが」というものです。このリクエストはオーケストレーターを通じて届き、オーケストレーターは「ユーザー管理スキルに委譲できる」と判断します。ユーザー管理スキルには、それ自体の保護層も備わっています。そのスキルはユーザーの権限を取得し、それを特定のツールにマッピングします。そして「ロールをプロファイルに追加するツールが利用可能であり、実行して問題ない」と判断します。その後、応答はユーザー管理エージェントを通じてオーケストレーターへと戻り、さらにユーザーへと返されます。
4.4 Guardrails運用の気づき
John: それでは、安全性についてお話ししましょう。安全性の課題についてです。Benjaminが述べた通り、エージェントの世界において私たちが主に気にかけるべきことは2つあります。一つは、ユーザーとエージェントが互いに何を発言できるかという点です。私たちが注意を払っている内容は、職場にふさわしくないコンテンツ、プロンプト攻撃、そしてブランドにそぐわない応答です。エージェントがユーザーを侮辱するようなことは望んでいません。そして、これはすべてのモデルの入力と出力に対して適用されなければなりません。このために使用しているサービスは、BenjaminやAmitが述べた通り、Amazon Bedrock Guardrailsです。Guardrailsを最初に使い始めた際、私たちはClassic層を使用していました。しかし言語サポートを拡大していく中で、Classic層は3言語しかサポートしていないことに気づきました。そこで、60以上の言語をサポートするstandard層と比較検討することになりました。また、毎時間、24時間にわたってエージェント的なテストを実行する中で気づいたことがあります。プロンプトやガードレールの設定が精密でないと、テストがやや不安定になりがちだということです。例えば英語の場合、私たちのテストに基づくと、Classic層は93.5%程度のカバー率にとどまるのに対し、standard層はほぼ100%に近い数値を示しました。私たちのエージェント評価において、誤検知率がかなり高い状態にあることに気づきました。テストの中には不安定なものがありました。「admin」や「remove」といった特定の単語が、10回に1回程度誤って検知されてしまうことがあったのです。これは、19時間もの良好なテスト結果を積み上げたにもかかわらず、そこで失敗してまた最初からやり直さなければならなくなるため、非常にもどかしいものでした。もう一つ考慮すべき点として、Classic層からstandard層へ移行する場合、Classic層は広範なリージョンをサポートしている一方で、standard層は一部の小規模なリージョンではCrisエンドポイント経由でのみ利用可能だということです。これは、データプライバシー法が非常に厳格な小規模リージョンに展開している場合には、考慮すべき点となります。
4.5 独自権限管理システムの構築
John: それでは、権限管理、つまりユーザーが何を実行できるかという点に話を移しましょう。私たちが開発を始めた当時、Amazon Agent Core Policyという選択肢はまだありませんでした。そのため、独自の、いわば手作りのソリューションを構築する必要がありました。しかし、それをどのように適用したかをご覧いただくことは、参考になると思います。これは、ユーザーとCo-pilotとの間のモデル会話の例です。「John Sextonのプロファイルを閲覧したいのですが」と書かれています。初期化の段階で、私たちはユーザーの権限を取得し、それを許可されたツールと禁止されたツールにマッピングします。ここで重要なのは、あるツールが禁止されているというだけで、それをコンテキストから完全に取り除いてしまうのでは不十分だということです。私たちは「これらのツールは利用可能だが、使うことはできない」という形にする必要がありました。もしユーザーがプロファイルを取得しようとして、その権限を持っていなかった場合、Co-pilotが「そのユーザーを取得するツールがありません」と答えてしまうと、ユーザーは「では、そもそもこの機能にどんな意味があるのか」と思ってしまうでしょう。最初のリクエストは許可されたツールであるため、ユーザーのプロファイルを取得して返します。次に、ユーザーはそのプロファイルの削除を依頼しますが、これは許可されていない操作です。私たちはここで「そのツールがありません」とは言わず、「そのツールは確かにありますが、それを実行する権限がありません」と伝えます。そして次に自然に出てくる問いが「ユーザーを削除する権限を得るにはどうすればよいか」というものです。私たちは公開されているすべてのドキュメントをナレッジベースに保持しているため、ユーザーに対して、自分自身の権限を引き上げるための具体的な手順を返すことができます。
4.6 今後のアーキテクチャ構想
John: それでは、もし今日改めてこれを一から開発するとしたら、どのようなアーキテクチャになるかを見てみましょう。これを実現するために私たちが構築した独自のソリューションは数多くありますが、今作るとしたらどうなるでしょうか。ユーザーのリクエストは、まずAgent Core Gatewayを経由してルーティングされ、Agent Core Runtimeへと転送されます。会話コンテキストはAgent Core Memoryから取得しますが、これには長期記憶という機能もあり、これは私たちのこれまでのアーキテクチャでは考慮していなかった機能です。権限についてはAgent Core Policyから取得し、それをアクションやツール実行にマッピングすることができます。ナレッジベースやGuardrailsとのやり取りについては、これまでと同様の形で行います。そして、メッセージについても、これまでと同様にWebSocketを通じて非同期にユーザーへ返します。以上をもちまして、私からのお話は終わりです。どうもありがとうございました。