※本記事は、AWS AI and Data Conference 2026のセッション「Agentic AI at Sage with AgentCore」の内容を基に作成されています。本セッションは、2026年3月12日にアイルランド・キルケニーのLyrath Convention Centreで開催された、第5回AWS AI and Data Conference 2026にて収録されたものです。動画の詳細情報は AWS Events(https://go.aws/events)でご覧いただけます。本記事では、セッションの内容を要約しております。なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご視聴いただくことをお勧めいたします。
本セッションには、AWSよりOmar Elkharbotly氏(Senior GenAI/ML Specialist SA)、Shubhankar Sumar氏(Senior Solutions Architect ISV)、そしてSage社よりCheyne Ravenscroft氏(AI Lead Architect)が登壇しています。
1. オープニングとエージェンティックAIの進化
1.1 導入・登壇者紹介とセッションのアジェンダ
Omar： 皆さん、こんにちは。本日はエージェンティックAIをテーマにしたこのセッションにお集まりいただき、ありがとうございます。始める前に一つ質問させてください。皆さんの中で、エージェンティックAIのソリューションをPOC(概念実証)やプロトタイピングの段階から本番環境へ移行する際に、何らかの問題に直面した経験のある方はいらっしゃいますか。挙手をお願いします。……なるほど、やはり多くの方が経験されているようですね。それであれば、今日は皆さんにとって非常に有意義な場になると思います。本日はAmazon Bedrock Agent Coreが、プロトタイピングから本番環境への移行をどのように加速させるのかについてご説明し、さらにSage社が実際にAmazon Bedrock Agent Coreをどのように活用して、より迅速にエージェンティックAIソリューションをプラットフォーム上で提供しているのかを事例としてご紹介したいと思います。
改めて自己紹介をさせてください。私はOmarと申します。GenAI専門のソリューションアーキテクトを務めております。本日は同じくAWSのソリューションアーキテクトであるShubankerと共に登壇いたします。また、Sage社からはAIエンジニアのDiego、そしてアナリティクス・AIエンジニアリング担当のマネージャーであるShaneにもお越しいただいており、後ほど彼らの製品について詳しくお話しいただく予定です。
本日の流れとしましては、まずエージェンティックAIがこれまでどのように進化してきたのか、その歩みを振り返るところから始めます。私たちがどこから出発し、どのようにして現在の地点にたどり着いたのかを整理します。続いて、AWSがAIスタックやサービスにおいてどのような取り組みを行っているのか、そしてAWSが皆さんのエージェンティックAIワークロードを本番環境へより迅速に移行させるために、どのようなお手伝いができるのかをお話しします。最後に、Agent Coreについて少し掘り下げた後、Sageチームにバトンを渡し、彼らがAgent Coreをどのように採用してエージェンティックAIソリューションを前進させているのかを詳しくご紹介いただきます。
1.2 エージェンティックAIの進化の歴史とGartnerによる2028年予測
Omar： それでは、エージェンティックAIの進化についてお話しします。皆さんも覚えていらっしゃると思いますが、初期の頃は、ただメッセージを送って回答を受け取り、それで満足するといった、単純に対話するだけのサービスやソリューションでした。そこから、公開されているウェブサイトに基づいてリンクを取得し、最新の情報を回答として返すような、Web検索に関連した機能が加わるようになりました。そしてこれがさらに進化し、GenAIアシスタントと呼ばれる存在になりました。この段階になると、利用者がアクセスを許可したツールに基づいて、思考し、反応しながら、単一のゴールに向かって作業を進められるようになったのです。
そして現在私たちがいるのは、まさに自律的なエージェンティックAIの世界です。人間の介入をほとんど必要とせずに、非常に複雑なタスクをエンドツーエンドで実行し続けるエージェンティックAIソリューションが登場しています。わずか2年という期間でここまで技術が急速に進化してきたことは、実に驚くべきことだと感じています。
そして、これは単なる一過性のトランスフォーメーションではなく、まさに未来そのものであるという点を強調したいと思います。これは「これから来るもの」ではなく、「今まさにここにあるもの」なのです。実際、Gartnerの調査によれば、2028年までに企業の33%がエージェンティックAIソリューションを採用する見込みだとされています。つまり、わずか2年後には、企業の3社に1社が何らかの形でエージェンティックAIソリューションを導入し、いずれかの業務を支援している状態になるということです。想像してみてください。さらに、2028年までには日々の業務タスクや業務上の意思決定のうち15%が、エージェンティックAIによって自律的に行われるようになるとも言われています。ですから、この進化はロードマップ上の未来の話ではなく、まさに今ここで起きている現実なのです。
そこで次に問うべきは、AWSがこの流れの中で皆さんをどのように支援できるのか、という点です。皆さんがエージェンティックAIのユースケースにより迅速に取り組めるようにするために、私たちに何ができるのか。この問いへの答えとして、まずAWSのエージェンティックAIにおける最先端の科学技術についてお話ししたいと思います。
2. AWSのAIスタック戦略とBedrockによるオーケストレーション層
2.1 AWSのAIスタック全体像
Omar： 皆さんもご存知かと思いますが、私たちはNovaシリーズのモデルやNova Forgeといったサービスに力を注いでおり、皆さんがより迅速にエージェンティックAIのユースケースに取り組めるよう、多くのエージェンティックAIソリューションやモデルの開発にエンジニアリングチームが取り組んでまいりました。その一例が、昨年のre:Inventで発表され、現在は一般提供が開始されているNova 2 Liteモデルです。
しかし、私たちが提供しているのはモデルだけではありません。エージェントを構築し、実行し、管理するためのインフラストラクチャも併せて提供しています。私たちは、お客様がエンタープライズ向けの強力なAIエージェントを大規模に構築できるよう、いくつかのパラメータを整備しようとしています。その一つが、Agent Coreを通じて提供している、コーディング部分に対する非常に細やかな制御です。これはエージェンティックAIソリューションを生成する際に活用いただけます。
一方で、コーディングにあまり深く関わりたくない方向けには、Amazon Quickというサービスを通じて、ローコードのプリミティブも提供しています。さらに私たちはこの取り組みを一歩進め、DevOpsエージェントやAWSセキュリティエージェントのように、特定のペルソナに特化したエージェントの構築も行っています。これらは、皆さんが頼りにできる、非常に焦点を絞った特定のユースケースに対応するために作られたものです。
そして、こうした基盤部分の提供を終えた段階で、私たちはさらに、さまざまなお客様のニーズに合わせてよりカスタマイズ可能な、ファーストパーティのエージェントの構築へと展開していきます。こうした背景を踏まえて、皆さんに私たちのAIポートフォリオとサービススタックの全体像をご紹介したいと思います。ここからは、下から上へと順を追って説明していきます。
まず基盤となるインフラストラクチャの部分ですが、チップに関してはInferentiaとTrainiumがあり、多くのエンタープライズ企業が大規模言語モデルや基盤モデルの学習にこれらを活用しています。もちろんAWS上で利用可能なGPUも併せて用意しています。そして、こうしたモデルを学習させ、特定のタスクに対応できるようカスタマイズするためのSageMakerプラットフォームもあります。
その一段上にはAmazon Bedrockがあり、これは複数の機能を担う中核的なサービスです。まず、数百に及ぶモデルがホストされている基盤サービスとしての役割があり、皆さんはこれらをワンクリックでデプロイして利用することができます。さらに、これらのモデルとやり取りするための複数のAPIに加え、ガードレールやカスタマイズのソリューション、そして頼りにしていただけるRAGソリューションも提供しています。
そして最近、昨年半ばにAmazon Bedrock Agent Coreを発表いたしました。これは、皆さんのエージェントをプロトタイピングから本番環境へと、より快適かつ容易に移行できるようにすることを目指したものです。さらにその上の層には、オープンソースのStrands Agent SDKを導入しています。これを使えば、文字通りわずか2行のコードでエージェントのPOCを作成することができます。
そして最後に、最近私たちが導入したアプリケーションやエージェントとして、Quick Suite、Transform、Connect、AWS Marketplace、DevOpsエージェント、セキュリティエージェント、そしてソフトウェア開発プロセスがAIによってどのように進化しているかを体現するAI IDEであるQiroなどが挙げられます。ただ、ここで一歩立ち返って考えていただきたいのですが、エージェンティックAIソリューションを構築する際、皆さんがまず最初に考えるべきなのはオーケストレーション層です。
2.2 オーケストレーション層としてのBedrockの役割
Omar： エージェンティックAIソリューションを構築する際にまず必要になるのは、皆さんのニーズを理解し、その裏側で作業を委任し、実行していく「頭脳」にあたる部分です。この点において、Amazon Bedrockを活用していただくことができます。現在私たちが提供している数百に及ぶモデルの中から、それぞれのLLMが持つ基盤や能力を試し、確認していただくことで、実現したいユースケースに最も適したモデルを選んでいただくことができます。
私たちはこれをコストとレイテンシーの両面で最適化しています。そのため、大規模なモデルから小規模なモデルまで、複数の価格帯・複数のモデルを取り揃えており、それぞれ特定のタスクの達成に活用いただけます。そして最後に、私たちが特に力を入れているのがセキュリティの側面です。ガードレールと自動推論(Automated Reasoning)を導入することで、皆さんのエージェンティックAIソリューションに入ってくるプロンプトや、そこから出力されるコンポーネントが、必ず一定のガードレールの範囲内に収まるようにしています。
この自動推論やガードレール、責任あるAIに関するテーマについては、後ほど別のセッションで詳しく取り上げる予定がありますので、ご興味のある方はぜひそちらにもご参加ください。現在Amazon Bedrock上で利用可能なモデルは100種類を超えており、昨年導入したオープンウェイトモデルから、Anthropic、Cohere、Amazon、Nvidia、OpenAIといった各社が開発したプロプライエタリなモデルまで、幅広く網羅しています。
つまり、モダリティやタスク、思考プロセスの違い、あるいは小規模なタスクをこなすための軽量モデルまで、あらゆるユースケースに対応できるモデルが揃っているということです。そしてこれこそが、皆さんのエージェンティックAIソリューションを前進させるためのオーケストレーション層となります。
次の層で問われるのは、そうしたエージェントをどのように計画し、ホストし、スケールさせていくか、そしてメモリに関する文脈管理や、対話のやり取りをどのように管理していくか、という点です。ここからは、Amazon Bedrock Agent Coreがこうしたタスクをどのように扱うのかについて、Shubankerからより詳しくお話しさせていただきます。
3. Amazon Bedrock Agent Coreの全体像と主要サービス
3.1 本番移行時の課題とAgent Core誕生の背景、9つのコアサービスの全体構成
Shubanker： 皆さん、こんにちは。私たちは皆さん、すでに多くのエージェントを構築されており、POCについてはある程度マスターされている状況だと思います。ただ、いざ本番環境へ持っていこうとすると、その製品を本番に乗せるためには、さらに多くの要素が必要になってきます。そのため、常にこうした疑問が浮かんでくるのではないでしょうか。パフォーマンスをどう管理するのか。どうスケールさせるのか。本番環境に移行する段階では、おそらく数百、あるいは数千に及ぶエージェントを抱えることになります。そうした状況で、セキュリティやガバナンスをどう管理するのか、そして後から監査できるように、オブザーバビリティや監査可能性をどう担保するのか、といった点です。
こうした課題に対応するために、多くのお客様からもフィードバックをいただいており、「複数のフレームワークを使ってエージェントを構築したい」という声を多くいただいてきました。私たちはこうしたお客様の声に耳を傾け、その結果としてAmazon Agent Coreをリリースいたしました。
Agent Coreが高いレベルで実現しているのは、より速く価値を届けられるようにすることです。具体的には、サーバーレスインフラストラクチャを提供しますので、皆さんはエージェントがどのようなインフラ上で動作しているかを気にする必要がなくなります。その部分はAgent Coreが面倒を見てくれます。また、任意のフレームワークを使用できる点も特徴です。先ほどのスライドでStrandsについて触れましたが、それ以外にもLangGraphやCrewAIなど、皆さんが使いたいと考えるどのフレームワークでもエージェントを構築していただけます。そうして構築したエージェントを、Agent Core上にデプロイすることができます。そしてもちろん、Agent Coreにはセキュリティやオブザーバビリティに関する要素が基本的な機能として組み込まれています。
こうした点について、これから一つずつ順を追ってご説明していきますが、まず全体像として、Agent Coreには9つのコアサービスがあります。皆さんはこれらのサービスを一つだけ使うことも、複数を組み合わせて使うこともでき、それによってエージェントを構築し、デプロイすることができます。必ずしもすべてを使う必要はなく、エージェントで何を実現したいかに応じて、一つ、あるいは複数の要素を選んで活用していただければと思います。
これらのサービスがどのように連携しているかを整理しますと、まずエージェントを構築する段階ではツールやメモリを使用します。次に、それらをデプロイする段階ではランタイム、アイデンティティ、ポリシーを使用します。そして最終的には、オブザーバビリティを用いて、これらのエージェントのリアルタイムでの評価も行うことになります。こうした一連のプロセスの中で、先ほど申し上げた通り、異なるフレームワークを使用することができますし、MCPやエージェント間通信(Agent-to-Agent)のプロトコル、あるいはオブザーバビリティのためのOpenTelemetryといった、さまざまなプロトコルも活用いただけます。
それでは、Agent Coreの中身を具体的に見ていきましょう。まずその中核にあるのがランタイムです。ツールやエージェントが使用するさまざまなプロンプトを用いてエージェントを構築し、それをランタイムにデプロイします。そして、本番環境でエージェントを使用する際に重要になってくるのが、コンテキストをどう管理するかという点です。このコンテキスト管理のために、Agent Coreのメモリを使用します。
ここまででエージェントとメモリが揃いましたが、次にバックエンドと接続する必要があります。組織内にはすでに多くのAPIやMCPサーバー、Lambda関数、あるいはサードパーティ製品のMCPサーバーが存在しているはずです。これらとどう接続するか、という部分でゲートウェイを使用します。そして、メモリを持ち、バックエンドシステムと接続できた段階で、標準的なセキュリティプロトコルやアイデンティティ管理の標準に従っているかを確認する必要があります。そのためにアイデンティティの機能があります。
その次に来るのがポリシーです。お客様からは「ここまでの機能はどれも良いのですが、実行時にビジネスポリシーを適用したい」というご要望をいただいてきました。例えば、融資の承認や自動返金を行うエージェントがあるとします。この場合、1,000ポンドあるいは1,000ユーロを超える返金については、手動の承認プロセスに回すようにしたい、といったケースが考えられます。こうした制御をどのように適用するか。その答えがポリシーです。同様に、融資審査においても、ゲートウェイのレベルでさまざまなビジネスルールを適用することができます。つまり、バックエンドのAPIやツールが呼び出される前の段階で、ゲートウェイのレベルでこれらのポリシーが適用され、その結果として承認か否認かの判断が返されるという仕組みです。
このほかにも、ブラウザツールと呼ばれる機能があります。アプリケーションのテストを自動化するためにヘッドレスブラウザを使いたい場合や、コードインタープリターを使用したい場合に活用いただけます。そして、これらすべてを組み合わせた上で欠かせないのが、オブザーバビリティの層です。エージェントがどのように振る舞っているのか、どのようなプロンプトが送られたのか、どのような判断が下されたのかを把握する必要があります。そして最後に、しかし決して軽視できないのが評価です。他の機械学習モデルと同様に、皆さんのエージェンティックソリューションが実際にきちんと機能しているかどうかを確認する必要があります。具体的には、定期的にエージェントを評価すること、つまりプロンプトを取得し、返ってきたレスポンスがどのようなものかを分析することが求められます。これは、さまざまなモデルを使って実施することが可能です。
3.2 RuntimeとGatewayの詳細
Shubanker： それでは少し視点を変えて、Agent Coreのランタイムについて詳しく見ていきましょう。Agent Coreのランタイムとは何かと言いますと、これは事実上、数十万規模のマイクロVM、あるいはセッションと呼んでもよいと思いますが、そこまでスケールできるサーバーレスインフラストラクチャです。皆さんがエージェントとやり取りするたびに、たとえば数千人のユーザーが同時にシステムに対して質問を投げかけているような状況を想像してみてください。ランタイムはそうした数千のセッションを、それぞれ独立した形で開始し、独立して実行します。ここで「独立している」と申し上げているのは、あるセッションとあるセッションの間でコンテキストが共有されないということです。それぞれが独立しており、十分にセキュアな状態が保たれ、セッション間で情報が共有されることはありません。
ランタイムへのデプロイに関しては、コンテナ経由、あるいはファイル経由のいずれかでコードをデプロイすることができます。また、先ほど申し上げた通り、VPCやPrivateLinkのサポートと併せて、セキュリティ面の対応も整っています。全体の流れとしては、まずBedrockのモデル、あるいは外部のモデルを使ってエージェントを構築します。そして、先ほどお話ししたStrands、CrewAI、LangGraphといったフレームワークのいずれかを使用します。構築したエージェントは、DockerコンテナまたはZIPファイルのいずれかを使ってAgent Coreにデプロイします。そして、それをランタイムにデプロイした後、最終的にアプリケーションがそれらのエージェントを呼び出すという流れになります。
続いてゲートウェイについてお話しします。ゲートウェイはAgent Coreの中でも基本的な要素の一つです。これが果たす役割は、皆さんのツールとやり取りするための単一のインターフェースを提供することです。ここで言う「ツール」とは、既存のLambda関数やAPI、MCPサーバー、あるいはサードパーティのアプリケーションを指します。皆さんのエージェントに、こうしたツールごとに異なるコードを書かせたくはないはずです。求められているのは単一のインターフェースです。そこでゲートウェイが、こうしたバックエンドシステムを統一されたインターフェースを通じて公開する機能を提供します。そしてもちろん、ゲートウェイはこれらのツールに対する検索機能も備えており、エージェントのコンテキストに応じて適切なツールセットを取得できるようになっています。
具体例を挙げますと、Eコマースの中で特定の商品を検索しているケースを想像してみてください。皆さんのエンタープライズシステムの中には、数千に及ぶツールが存在しているかもしれません。もしゲートウェイが、その数千のツールの中から、特定のテキストやコンテキスト、つまり皆さんのプロンプトに対して文脈的に適したツールを一つひとつ見つけ出そうとすれば、非常に時間がかかってしまいます。そこでゲートウェイは、コンテキストに基づいた検索機能を備えており、数千あるツールの中から、たとえば顧客が求めている内容に非常に近い10個程度のツールだけを絞り込み、それをエージェントに渡す、といったことが可能になっています。そして、そのエージェントがそのツールを使って作業を進め、その一つのツールだけが確実に呼び出されるようにする、という仕組みです。つまり、バックエンドとのやり取り全体を最適化しているということです。
流れとしては、MCPクライアントやエージェント、あるいはアプリケーションがAgent Coreのゲートウェイに接続します。そしてゲートウェイは、バックエンドのAPIやRESTfulサービスをツールとして公開します。同時に、Lambda関数もツールとして公開します。したがって、ほとんど、あるいはまったくコードを変更することなく、皆さんが持っているLambda関数やAPI、MCPサーバーをツールとしてゲートウェイに公開し、エージェントがそれをシームレスに呼び出せるようになる、というわけです。
3.3 Identity・Policy・その他のツールとオブザーバビリティ・評価機能
Shubanker： 最後に焦点を当てたいのが、アイデンティティです。ご存知の通り、あらゆるエンタープライズシステムにとって、アイデンティティは基本的な中核要素です。適切な人、適切なコンテキストが、適切なエージェントを呼び出していることを確実にする必要があります。そのために、また別のカスタムソリューションを構築したいとは誰も思わないはずです。そこでAgent Coreは、中核となるアイデンティティサービスを提供しており、これによりAWSのサービスやサードパーティのサービスを標準的なプロトコルを用いて呼び出すことができます。IAMによるアイデンティティ管理をサポートしているほか、OAuthに準拠したOkta、Cognito、あるいはMicrosoftのEntraといった、あらゆるアイデンティティプロバイダーもサポートしています。
これにより、皆さんが既にお持ちのアイデンティティフレームワークやバックボーンに従いながら、それをエージェンティックソリューションの中で活用することが保証されます。また、トークンリポジトリの機能も提供しており、特定のサードパーティサービスを呼び出す際に、何度も認証を行う必要がないようになっています。
ここまでランタイム、ゲートウェイ、アイデンティティという3つについてご説明してきましたが、Agent Coreにはこのほかにもさらに6つのサービスがあります。本日はすべてについて詳しくお話しする時間はありませんので、それについてはまた別のセッションで取り上げられればと思います。それでは、Sage社がAgent Coreを実際にどのように活用して、エージェンティックソリューションを構築しているのかを見ていきましょう。ここからはDiegoにバトンタッチしたいと思います。
4. Sage社の導入背景とSage Nexus構想
4.1 Sage社の概要とグローバル展開に伴うデータガバナンスの課題
Diego： 皆さん、こんにちは。私はDiegoと申します。Sage社でデリバリーマネージャーを務めております。私はエンタープライズアナリティクス・AIチームに所属しており、これはIT部門内の中央機能を担うチームです。本日は、Sage Nexusについて皆さんにご紹介させていただきます。後ほど、Nexusの内部構造についてはShaneから概要を説明してもらう予定です。
まず私からは、私たちのこれまでの歩みについてお話しさせていただきます。ただ、その前に、Sage社をご存知ない方のために簡単にご紹介しますと、Sageはグローバルに事業を展開する会計・給与計算ソフトウェアのプロバイダーです。本社はイングランド北東部のニューカッスルにあり、現在従業員数は11,000人を超えており、20カ国以上で事業を展開しています。興味深い事実として、英国の就労者の4分の1は、私たちのソフトウェアを通じて給与の支払いを受けています。
こうした背景を踏まえて、私たちがGenAIアプリケーションに関してどのような判断を下す必要があったのか、その文脈としてまずご説明したいと思います。私たちが置かれている状況を踏まえると、グローバルなデータの状態という観点で何を意味するのか。私たちは複数の地域で事業を展開しているため、当然ながら規制要件や運用要件も多様なものになります。また、データドメインについても、財務、給与、人事、そしてアナリティクスといった領域にまたがっており、それぞれが異なるデータモデルを持っています。そしてもちろん、Sageにとってコンプライアンスは極めて重要な要素です。GDPRをはじめとする各種の金融規制への対応が求められます。
こうした文脈の中でGenAIを捉えたとき、私たちの環境においてエージェントがハルシネーションを起こすということは、非常に大きな問題につながりかねません。こうした状況が、私たちがいくつかの重要な判断を下すきっかけとなり、AWSを採用するに至った理由でもあります。
4.2 導入前の課題認識とSage Nexus構想
Diego： 2024年後半から2025年前半にかけて、Sage社内では多くのチームがそれぞれAIの実装に取り組み始めていました。しかし、私たちが目にしたのは、それらのチームがバラバラに分断されているという状況でした。各チームがサイロの中で個別に活動しており、セキュリティの水準も一貫性を欠いていました。チーム同士が連携して活動できる場所も存在していませんでした。それに伴い、デプロイされているエージェントやソリューションに対する明確な所有者も定まっておらず、コストやライフサイクル管理に対する統制も効いていない状態でした。本日、他のセッションやキーノートでも触れられていたかもしれませんが、POCのうち実際に本番環境まで到達するものはごくわずかです。こうした状況の中で、ガバナンスとコンプライアンスに関する懸念が高まっていきました。これは、このまま進んでいけば私たちのデータがどのような姿になってしまうかを示す、一種の警鐘のような状態でした。当然ながら、私たちはそうした状態を望んではいませんでした。
そこで私たちが気づいたのは、必要なのはさらに多くのエージェントではなく、一つのプラットフォームだということでした。ここで強調しておきたい重要な点は、エージェント自体は短期的な課題を解決してくれるものの、エンタープライズという文脈においては、かえって特定のリスクを増幅させてしまう可能性があるということです。私たちが求めていたのは、Sage全体で一貫した方法により、GenAIを構築し、デプロイし、統治し、そしてスケールさせていくことでした。
この構想を練っていた段階での、私たちのプラットフォームに対するシンプルな捉え方を申し上げますと、私たちはSageのビジネス部門や同僚たちには、引き続きアイデア創出のプロセスを担ってもらい、GenAIが私たちのアプリケーションをどのように支援できるかを考え続けてもらいたいと考えていました。そして、そうしたアプリケーションを確実にエンドユーザーへ届けたいとも考えていました。しかし、私たちが抱えていた課題は、その両者の間に存在するギャップでした。これが、私たちが構想していたソリューションの、簡略化されたイメージです。私たちは、SageにおいてGenAIがどのように適用され得るのかを民主化したいと考えていました。そのために、すべての開発者が共に活動できる場所を用意し、ベストプラクティスを共有し、標準化された方法でこれらのGenAI技術ソリューションを開発できるようにしたいと考えたのです。
そして、この上にガバナンスを整備するとともに、これらのユースケースの価値を評価し、アセスメントする仕組みも必要だと考えました。これこそが、Sage Nexusです。Sage Nexusは、私たちのエンタープライズ・オーケストレーション・プラットフォームです。具体的には、BedrockおよびAgent Core上のエージェントを対象とした、一元化されたライフサイクル管理の仕組みです。Sage Nexusには、評価、モニタリング、そしてコストの可視化機能が組み込まれており、これらはステークホルダーにとって重要な要素です。私たちのAWS環境内では、タグベースの分離が行われているため、どのチームがどのコストを生み出しているのかを把握することができます。そしてもちろん、このプラットフォームは、複数チーム・複数ドメインでの採用を前提として設計されています。
4.3 ハイブリッド運用モデル、デリバリーフレームワーク、得られた知見と成果
Diego： 先ほどお見せした図をもう一度振り返っていただきたいのですが、ここで注目していただきたいのが、Sage Nexusの中核をなす部分です。実際にこれを実装しようとした際に、本番環境に至るまでの道筋として何が必要になるのかを考えました。もしすべてを中央集権化してしまえば、イノベーションの芽を摘んでしまう可能性があります。つまり、ビジネス側が本来求めているスピード感を損なってしまうということです。一方で、すべてを分散化してしまえば、先ほどお見せしたような、非常に混乱した状態に逆戻りしてしまいます。それは私たちが決して望んでいないことでした。
そこで私たちが選んだのは、ハイブリッドなアプローチでした。中央集権的なアプローチと、分散的なアプローチの両方を併せ持ち、後者については「シチズンデベロッパー」と呼んでいるプログラムを通じて運用しています。中央集権化するか分散化するかは、ユースケースに基づいて判断されます。会社の複数の部門にまたがるようなユースケースについては中央集権化され、IT部門によって中央で管理されます。
一方で、より特定の機能領域に限定された、より垂直的で個別性の高いユースケースについては、シチズンデベロッパーのルートに進みます。シチズンデベロッパーとは、Sage内の技術力を持つ他のチームが、Nexusの中で、私たちのフレームワークに沿って活動できるようにするためのプログラムです。この一環として、私たちはこうしたチームに対して、カスタムビルドや、Sage内での運用方法に関するドキュメンテーションを提供し、Skill Builderを技術的なイネーブルメントの一環として活用してもらっています。これにより、これらのチームがAWSの各種サービスをどのように使いこなせばよいかを理解できるようになります。もちろん、中央集権的なアプローチと分散的なアプローチが、それぞれ勝手に異なる方法で運用されてしまっては意味がありません。これこそが、Sageにおけるデリバリーフレームワークの目的です。
先ほど申し上げた、POCの多くが本番環境に到達しないという状況に立ち返りますと、私たちが実現したかったのはこういうことです。私たちはプロセスの中にループを組み込み、当初のアイデアが本当に価値のあるものかどうかを、本番環境に到達した後ではなく、プロセス全体を通じて継続的に評価できるようにしています。このスライドで皆さんに最も理解していただきたいポイントは、バリューチェックポイントです。各段階において、そのユースケースに対して私たちが望んでいた価値が、実際にその段階で実現されているかどうかをダブルチェックします。
もし実現されていなければ、前のループに戻ります。もし私たちが期待していたすべての条件を満たしている、あるいはほぼ満たしていると判断できれば、次のループへと進み、最終的にはスケールと最適化の段階に到達します。バリューチェックポイントの一環として、ビジネス面での準備状況と技術面での準備状況が、評価すべき重要な要素となります。
ここで私たちが学んだことについてお話ししたいのですが、特に「想定していなかったこと」に焦点を当てたいと思います。まず、ガバナンスに関する議論は早期に始めなければならない、ということです。これは私たちが学び、現在すでに実装している点です。スケールを目指す方にとって、ガバナンスはGenAIの中核をなす要素です。一見するとスピードを鈍らせるように感じられるかもしれませんが、長期的に見れば、決してそうはなりません。
そしてもちろん、私たちは開発者たちが活動できる場を作りたいと考えていました。より多くのチーム、より多くの開発者が、同じコンテキストの中で活動できるようにしたいと考えたのです。これまでのところ見えてきた成果として、現在Nexusの中では複数のチームが活動しています。アイデアから本番環境への到達までにかかる時間は、確実に短縮されました。このフレームワークのモデルの中で、各チームは迅速に活動できるようになり、価値がないと判断されたアイデアについては、キューに留めておくこともできるようになりました。そして、コストのガバナンスと所有権も明確になりました。コストがどこに向かっているのか、そしてNexusの中で物事がどのように動いているのかを、私たちは把握できるようになっています。
Shaneにバトンタッチして、Nexusの内部構造について詳しく説明してもらう前に、私たちのEVP(エグゼクティブ・バイス・プレジデント)の言葉を皆さんにご紹介したいと思います。特に強調したいのは、「人間の可能性を増幅する」という言葉です。私たちSageは、GenAIを通じて、同僚たちが業務プロセスを発展させ、私たちの働き方そのものを高めていけるようにしたいと考えています。私からは以上です。それではShaneにバトンタッチし、Nexusの内部構造について説明してもらいたいと思います。
5. Sage Nexusのアーキテクチャとデモ
5.1 Nexusの3層アーキテクチャとBedrock・Agent Core採用の4つの理由
Shane： 皆さん、こんにちは。Diego、ありがとうございます。私はShaneと申します。Nexusのリード・エンジニアを務めております。まず最初に行いたいのは、Nexusのアーキテクチャの全体像をご説明し、なぜ私たちがこのようなアーキテクチャを採用したのかをお話しすることです。
Nexusには大きく分けて3つの層があります。まず一つ目は体験層(エクスペリエンス・レイヤー)で、これは事実上フロントエンドにあたる部分であり、Amplifyによって構築されています。すべてのAI関連サービスは複数のAPIゲートウェイを通じて提供されており、これらもコントロールプレーンを通じてセキュリティが確保され、管理されています。アイデンティティについてはCognitoでセキュアに管理されており、実際の開発環境における権限についてはIAMによって管理されています。これらすべては、OpenTelemetryを用いたCloudWatch上のオブザーバビリティによって、いわば包み込まれるような形で可視化されています。そして、内部の機能の大部分はLambdaを通じて実行されています。
ただ、こうした構成の中でも特に重要なのが、データ・AIプレーンと呼んでいる部分です。当初、私たちはBedrockの利用に大きな期待を寄せていました。それは、Bedrockがこれらすべてを非常に整理されたインターフェースにまとめ上げてくれるからです。そして、Agent CoreがBedrockを土台として拡張されて登場したとき、これはさらに私たちを興奮させるものでした。というのも、それによって私たちにとっての可能性がさらに広がったからです。システム全体の状態管理については、AuroraとDynamoのテーブルを通じて管理しており、エンタープライズデータをシステムに取り込むための複数のデータパイプラインも備えています。
それでは、なぜ私たちがBedrock、そしてより具体的にはAgent Coreを選んだのか、その理由をお話しします。一つ目の理由はトレーシングです。BedrockとAgent Coreの両方において、トレーシングは統一されており、非常に見やすい形で提供されています。しかも、開発者だけでなくステークホルダーにも提示できるよう、構造化された形になっているため、実際に裏側で何が起きているのかが明確に伝わります。ツールが呼び出されたときのインストルメンテーションなども含め、すべてが非常に明快で、理解しやすいものになっています。
二つ目の理由はオーケストレーションです。Bedrockでは、オーケストレーションはBedrock側で管理・保持されており、私たちにもそれを編集する権限はあります。しかし、Agent Coreにおいて特に魅力的だと感じているのは、マイクロVMランタイムを備えているため、実際に何が起きているのかについて私たちが完全な制御権を持てるという点です。私たちは、Strandsを使うのかLangGraphを使うのか、どのオーケストレーションサービスを使うかを自ら選ぶことができ、プランがどのように分解されるか、ツールがどのように呼び出されるか、といった点についても自分たちで判断できます。これにより、私たちはより素早く前進することができるようになりました。
そしてこれに関連して、ツールの構成とインストルメンテーションについても触れておきたいと思います。AWSのスタック内でのツールの構成とインストルメンテーションは、私たちが必要としている要件に対して、非常に優れたものだと感じています。Bedrockでは、ツールをアクショングループとして構成することができ、これは昨年の時点でも私たちが取り組みを始める上で非常に有用なインターフェースでした。これにより、Lambda関数を記述し、その関数についての説明を書くだけで、エージェントは私たちが記述した仕様に基づいて、それらの関数の使い方を理解できるようになりました。そして、Agent Coreに移行してからは、この点がさらに向上しました。再利用可能なツールをGatewayでホストし、エージェントが特定のタスクに対してどのツールを使うべきかをセマンティック検索できるようになったからです。そして、エージェントがこうした判断をより上手に行えるようになるにつれて、私たちはより長時間にわたるタスクにおいても、エージェントが正しい判断を下してくれると、より信頼できるようになってきています。
最後に挙げたいのが、セッション状態管理です。これはBedrockの段階から標準で機能しており、Agent Coreに移行した後も、若干異なる仕組みではあるものの、引き続き機能しています。Agent Coreでは、メモリの機能を備えており、短期的なセッションメモリと、長期的な永続メモリの両方を持っています。私たちはこれらのメモリの塊(ブロブ)が何であるかを自分たちで制御できるため、ユースケースに応じて、個々のユーザー単位やプロジェクト単位でスコープを設定することができ、これは非常に有用だと感じています。
5.2 Nexusのデモ紹介
Shane： 次にお見せしたいのは、実際に私たちが構築してきたものを紹介するいくつかの動画です。これらについては私が説明を加えていきたいと思います。まずご覧いただくのがNexusです。Nexusは、事実上、私たちのエンタープライズグレードのエージェンティック・サービング・プラットフォームです。先ほどご説明したプレーン上で、複数のファーストパーティ・アプリケーションを提供しており、チャットインターフェースのようなものも備えています。この画面の中では、推論の過程やツールの呼び出し、ナレッジベースの検索といった、標準的な要素をすべて確認することができます。
しかし、Nexusを構築していく中で、Diegoも先ほど触れていた通り、私たちが早い段階で気づいたのは、裏側で実際に何が起きているのかを可視化することが、非常に重要だということでした。そこで私たちは、モニタリングスイートを用意し、すべての会話を、使用されたトークン数やツールの使用状況といった観点で分解し、さらに実際の生のトレースデータを直接調査できるようにしています。
加えて、私たちは評価スイートも構築しています。これは、Diegoが先ほど話していた、ループ状の構造とも関連するものです。エージェントの技術的な準備状況は、この評価スイートによって判定されます。つまり、あるエージェントが開発段階からパイロット段階、そして本番環境へと進んでいくためには、私たちが用意した一連のテスト群を通過する必要があるということです。
具体的には、ジェイルブレイク、ハルシネーション、有害性(トキシシティ)、そしてPII(個人情報)の漏洩に関して、数百件に及ぶテストを実施し、これらのエージェントに適用しています。今からその様子をお見せしますが、ここでは「Lunar」という名前のエージェントをテスト対象として、ハルシネーション、ジェイルブレイク、PII漏洩の観点でどのように振る舞うかを確認していきます。
これらのテストはすべて、バックエンドにあるSQSキューを使って並列に実行されます。そして、その結果が集約され、エージェントにスコアが付けられます。私たちのCI/CDは、こうした記録と連携しており、あるエージェントが開発環境からプリプロダクション環境、そして本番環境へと進んでいくためには、この評価において合格の記録を持っている必要があります。私たちはこうしたIDをすべて紐づけており、何が起きたのかについて一連の連続性を保てるようにしています。
そして、これらの評価の実行結果の中には、質問(クエスチョン)、正解となるゴールデンレコード、そしてエージェントの実際の回答が含まれています。さらに、その回答を確認する評価者(エバリュエーター)が存在し、もし何か問題があった場合にはそれが何であったのか、逆にうまくいった場合には何が良かったのかを判定します。こうした情報はすべて、バックエンドのアプリケーション状態管理として、Auroraの中に記録されています。
5.3 ユースケース:Neural Nexus(マーケティングダッシュボード)
Shane： ここまでがNexusの主要な部分についてのご説明になりますが、次にお見せしたいのは、私たちが現在本番環境への移行を進めているユースケースの一つ、Neural Nexusです。これは、社内向けにお客様向けのマーケティングを支援するための、マーケティング向けダッシュボードスイートです。
具体的には、ユーザーがエグゼクティブ向けのダッシュボードを閲覧できる、エージェント駆動の体験を提供しています。ここでは、特定の期間内におけるセッション数や、カートの完了数といった情報を確認することができます。そして、画面上に表示されているすべてのデータを対象として、ユーザーはAIに対して評価を依頼することができます。例えば、特定の商品群について、特定の期間、特定のパラメータでフィルタリングした上で、「何が起きていると考えられるか、洞察を教えてほしい」と尋ねることができるのです。バックエンドには、このデータをより詳細に調査するための、複数のツールを備えたエージェントが存在しており、こうしたインサイトを生成したい場合には、それを実行することができます。
生成されたインサイトは、そのユーザーに紐づく状態として保存されます。そのため、ユーザーは後からその画面に戻り、なぜそうした事象が起きたのかを振り返ることができ、マーケティングにおいて特定の出来事がなぜ起きているのかについて、いわば時系列や物語(ナラティブ)を構築していくことができます。
さらに、この画面にはチャット機能も備わっており、画面上に表示されている内容についてエージェントと対話することができます。実際に画面上のドメインオブジェクトレイヤーにある情報は、エージェントに渡されるようになっているため、エージェントは画面の状態をほぼ認識している状態にあります。そのため、現在のフィルター条件に基づいて「何が起きているか」を尋ねると、エージェントがそれに答えてくれます。
これに加えて、マーケティングインテリジェンスと呼んでいる部分もあります。これもすべてAIによって支えられていますが、価格やプロモーションに関するデータ、ニュースデータ、Trustpilotなどからのレビュー、そして競合他社のオファーといった情報を収集しています。例えば、競合他社の一社が3カ月間の価格キャンペーンを実施していた場合、それが私たちの該当する商品群における提供内容とどのように比較されるのかを確認し、私たちがより良い提案を行うための潜在的な機会について、インサイトを得ることができます。これもすべて、バックエンドのAgent Coreのランタイムとゲートウェイによって支えられています。
ニュースの部分では、外部のニュース記事にクリックしてアクセスすることも可能です。これらの情報はすべて社内のナレッジベースに格納されており、エージェントがそれを参照できるようになっています。そのため、このダッシュボードが積み上がっていくにつれて、エージェントが持つナレッジベースの範囲も時間とともに拡張していくことができます。このユースケースについては、大まかにはこのような内容になります。
また、この会話部分の中では、次に尋ねるべき質問を提案する機能も備えています。現在の会話の状態に基づいて、Strandsのエージェントフレームワークが、次に尋ねるべき最適な質問を提示してくれる仕組みになっています。これがNeural Nexusのご紹介になります。
6. コントロールプレーンの詳細、今後の展望とクロージング
6.1 Agent CoreのRuntime/Gatewayコントロールプレーンの詳細
Shane： 次にご紹介したいのが、Agent Coreのランタイムとゲートウェイに関する、コントロールプレーンのバックエンドコンソールがどのような見た目になっているのか、という部分です。先ほど申し上げた通り、Agent Coreのランタイムは、基本的にサーバーレスのマイクロVMコンテナです。これにより、私たちはAgent Coreをこのコンテナ上にプッシュし、エージェントを一貫した方法で記述することができるようになっています。
こちらにあるのが、私たちのコンテナです。これはLangGraphを用いたエージェントで、いくつかの処理を行うものです。この中には、バージョニングの機能があります。これは非常に重要な要素で、私たちはエージェントに対してバージョン管理を行うことができます。特定のバージョンのエージェントを呼び出すこともできますし、万が一何か問題が発生した場合には、以前のバージョンに巻き戻すことも可能です。これらはすべて、コントロールプレーンの実際のアプリケーションを通じて呼び出す、エンドポイントARNを介して呼び出されます。
ランタイムは、その後、一つまたは複数のゲートウェイに接続されます。ゲートウェイは、事実上、ランタイムのためのツールカタログおよびサーバーとしての役割を果たします。ランタイムは通常、質問という形でプロンプトを受け取ります。これは、先ほどお見せしたようなインタラクティブなアプリケーションを通じたものであったり、チャットサービスを通じたものであったりします。
ランタイムは、そのプロンプトがどのようなものであるべきかを分解し、プランへと落とし込みます。そして、そのプランを完了させるためにどのツールを呼び出す必要があるかを判断します。その後、実際に意図した通りに動作しているかを確認するための、再帰的な推論チェックが複数回行われます。ここで使用されているツールはすべて、現時点ではLambda関数であり、ツールエンドポイントとして構成されています。
そして、これらはゲートウェイ上でのセマンティック検索によって検索される仕組みになっています。ランタイムの話に戻りますが、ランタイムが私たちにとって非常に優れている理由の一つは、すべてのランタイムが、発生したすべての事象について、OpenTelemetry準拠のOpenAIトレースログを出力してくれるという点です。そのため、どの段階においても、ユーザーの入力が何であったか、エージェントの応答がどのようなものであったか、ツールが呼び出されたタイミング、そしてそのツールの入力と出力が正確に何であったか、といった情報のログをすべて保持することができます。
これにより、アプリケーション内で何が起きているのかについて、非常に大きな制御力と把握力を得ることができています。そして、私たちが今後実現したいと考えているのは、こうしたログを取得し、それを先ほどご紹介した評価サービスと連携させることです。それによって、何か問題が発生した際に、実際に何が原因だったのか、なぜそれが起きたのかを、私たちが確認できるようにしたいと考えています。以上が、Agent Coreのバックエンドについての簡単なご紹介になります。
6.2 Sage社の今後の計画とクロージング
Shane： それでは最後に、このプラットフォームの今後について簡単にご紹介したいと思います。まず私たちが取り組みたいと考えているのが、Agent Coreにおけるセマンティックキャッシングとプロンプトキャッシングの両方を実装することです。また、Neptuneを用いたグラフRAGのエージェントを実現したいとも考えています。これが実現できれば、私たちにとって非常に大きな成果になると思います。
さらに、現在提供しているゲートウェイの機能を拡張し、エンタープライズ全体にまたがるツールカタログへと発展させたいと考えています。これにより、プラットフォーム上のユーザーが、ローコードあるいはノーコードに近い形でエージェントを作成できる体験を実現したいと考えています。具体的には、ユーザーがエージェントとしてどのようなものを作りたいかというアイデアを入力すると、それをもとに、必要なゲートウェイ上のツールと接続された形で、Agent Coreのランタイムへと自動的に組み上げてくれるようなウィザードを想定しています。これが、私たちが年内に到達したいと考えている理想の状態です。それでは、Omarにお戻ししたいと思います。
Omar： Shane、ありがとうございました。皆さんがAgent Coreをどのようにスケールさせ、さまざまなユースケースに活用できるのかがよく分かる、素晴らしい事例だったと思います。Agent Coreを始めるにあたって役立つリソースをご用意していますので、よろしければ、こちらの画面を写真に撮っていただければと思います。ドキュメンテーションからコードサンプル、そしてブログ記事まで、幅広くご用意しています。それでは、これで本日のセッションを終了とさせていただきます。本日はご参加いただき、誠にありがとうございました。それでは、また次のセッションでお会いしましょう。