※本記事は、AWSが公開している動画「AWS AI and Data Conference 2026 - Next Gen Agentic Search on AWS | AWS Events」の内容を基に作成されています。この動画は、2026年3月12日にアイルランド・キルケニーのLyrath Convention Centreで開催された第5回AWS AI and Data Conference 2026にて収録されたものです。登壇者は、AWS Solutions ArchitectのCanberk Keles氏と、Checkout.comのEngineering ManagerであるAnthony Roe氏です。本セッションでは、マネージドインフラによって運用負荷を抑えつつ大規模な検索を実現するAmazon OpenSearch Serviceについて紹介し、Checkout.comがElasticsearchからAmazon OpenSearch Serviceへ移行した実体験、その移行手法・克服した課題・本番環境での成果を扱い、さらにキーワードマッチングを超えた次世代のagentic search機能について解説しています。本記事では、動画の内容を要約しております。なお、本記事の内容は原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご覧いただくことをお勧めいたします。AWSのイベントに関する詳細は https://go.aws/events をご参照ください。
1. セッション概要とOpenSearchの基礎
1.1 登壇者紹介、アジェンダ、OpenSearchエンジンの概要とユースケース
Kamber： それでは始めましょう。何名か入ってこられていますが、キックオフします。皆さん、こんにちは。ここまでとても良いイベントを過ごされていることと思いますし、このトークの後も引き続き良い時間を過ごしていただければと思います。このセッションでは、AWS上でのOpenSearchの観点から、agentic searchにおける最新のイノベーションについてお話しします。そして今日はAnthonyとステージを共有できることを大変光栄に思っています。Anthonyにはcheckout.comの移行プロセスを語っていただきますので、実際の現場での移行ストーリーを聞いていただけます。アジェンダとしては、私がまず検索について手短に触れ、その後Anthonyが彼らの移行の道のりと、それによって得られたメリットを紹介します。そのうえで、agentic searchという領域で何が起きているのか、そしてオープンソースが皆さんのプロダクトラインにどう組み込まれていくのか、その未来についてお話しします。
Kamber： ご存じない方のために簡単に紹介しますと、OpenSearch自体はApache Luceneの上に構築された分散型の検索・分析エンジンです。ここでいう「分散型」とは、複数のノードにスケールさせることで大量のデータを処理できるという意味です。そして、ユースケースに応じて自分のデータに対して分析や検索を行うことができます。プロジェクト自体は非常に活発で、100を超えるパートナーがいて、現在も増え続けており、今日までに1万2千件以上のマージが行われています。OpenSearchが適合するユースケースはいくつかあります。最も分かりやすいのは、名前に「search」と入っているとおりテキスト検索です。ドキュメントを投入してフィールドを定義し、全文検索クエリを投げると、OpenSearchエンジンがそれを処理して関連性の高い結果を返してくれます。e-commerceなどはその良い例です。もう一つの特徴は、高い取り込みレートでストリーミングデータを取り込める能力です。ここではOpenSearchの分析機能を使って、ログやテレメトリデータ、メトリクスを対象としたオブザーバビリティエンジンを構築することもできます。そしてもちろん、今日の会話の焦点であるagenticな機能へと向かっています。OpenSearchはvector searchやセマンティック機能、agentic searchといった形でAIを活用した検索も提供しており、それらすべてをカバーしていきます。
1.2 データ構造・クエリの仕組み・運用課題・マネージドサービス・採用メリット
Kamber： 少し導入として仕組みをお話しします。OpenSearchに取り込むデータ構造はdocumentと呼ばれ、それをindexに取り込みます。indexそのものは複数のshardから構成され、さらにreplicaを持ちます。これがOpenSearchにおけるフォールトトレランスと高性能なデータ分析を提供する方法です。クエリ実行時に何が起きるかというと、クラスタ内のどのノードでもなり得るcoordinator nodeがそのクエリを受け取り、関連するshardにリクエストをルーティングします。データノード自体が実際の検索を行い、最後にcoordinator nodeが関連するスコアによって結果を統合してから、ユーザーに返します。
Kamber： ただ、分散エンジンであるがゆえに、運用面で管理するのは決して簡単ではありません。ですからインフラの管理や、活発なプロジェクトであるがゆえの数多くのイノベーション、アップグレードやパッチ適用、サポート、そしてクラスタで何か起きたときにどうするかといった運用面を考える必要があります。多くのビジネスはインフラ周りよりも自社のプロダクトラインに集中したいはずで、だからこそマネージドサービスが存在します。Amazon OpenSearch Serviceはマネージドサービスで、インフラ管理を心配することなくOpenSearchクラスタを動かせます。基本的にやるべきことは、クラスタを監視し、データ負荷に追いつける適切なリソースを持たせ、必要に応じてスケールさせることだけです。さらに、ただデータを取り込んで処理することだけに集中したいのであれば、OpenSearch Serverlessというもう一つの形態もあります。こちらはキャパシティ管理そのものもサービス側が行うため、クラスタのサイジング作業をする必要がありません。どちらを選ぶかはユースケースに大きく依存し、どんな機能をプロダクトに取り込みたいかに応じて相談すべき事柄です。
Kamber： この強力なエンジンについて触れておきたい点がいくつかあります。OpenSearchはオープンソースエンジンですので、ソリューションとして利用するうえでライセンスコストは発生しません。マネージドの提供形態を使えば、総所有コスト（TCO）を削減できる可能性もあります。また、agenticな領域も含めて非常に活発なコミュニティがあり、多くのイノベーションのスレッドが進行しています。最適化についても同様で、最新バージョンであるマネージドサービス上のOpenSearch 3.3は、最初のリリースと比べて10倍高速になっています。こうした性能面の最適化も進んでいるのです。それではここで、checkout.comが受けたメリットの一部を実演し、移行プロセスを語っていただくために、Anthonyをステージにお迎えしたいと思います。
2. checkout.com事例：背景・旧アーキテクチャと技術選定
2.1 会社概要、決済検索システムの役割、旧アーキテクチャ構成
Anthony： 皆さん、こんにちは。checkout.comとはどんな会社なのか、ということですが、私たちは顧客のために数十億件の決済を処理している会社です。グローバルな決済プロセッサーであり、それだけでなくカードの発行なども手がけています。つまり、かなり大きなプロバイダーだということです。私たちは数十億件のトランザクションを処理しており、グローバルな業界のリーダーたちから信頼されています。たとえばSpotifyのような企業が私たちの顧客です。そして継続的に成長を続けており、遠くない将来には数十億どころか数兆件のトランザクションを処理する存在になっていくと自分たちを捉えています。私たちは皆さんの多くにとってミッションクリティカルなインフラを担っています。決済は皆さんの生命線ですし、私たちはpayment performanceを信条としています。皆さんの決済は通る必要がある、できる限り頻繁に通らなければならない、それと同時に安全であり、不正チェックやその他の仕組みも整っていなければならない。これらはすべて皆さんにとって本当に不可欠で重要なことだと考えており、パフォーマンスは私たちの重要な原則の一つです。
Anthony： これは、私たちがもともとElasticsearchを使っていたシステムの一つを示したものです。このシステムが何をするのかというと、私たちの顧客、つまり皆さんが、オンラインのダッシュボードシステムを通じて、すべての決済、あの数十億件にのぼるトランザクションを検索できる機能を提供します。つまり、それらの決済を見つけたとき、その決済を分析したいかもしれませんし、なぜ失敗したのかを理解したいかもしれません。あるいは手動での返金やvoid（取り消し）といった操作をしたいかもしれない。私たちは、皆さんが望むどんな検索値に基づいてでも、すべてのトランザクションを検索して見つけ出せる機能を提供しています。たとえば、ご自身のApple Pay取引をすべて見つけたい、といったこともできるわけです。
Anthony： これをどう実現したかというと、checkout.comには非常に多くのドメインがあります。人々が行う必要のあることが本当にたくさんあるのです。それらのドメインはすべて、自分たちのprivate eventsを公開しています。ここの左側にいくつか例を挙げていますが、processing、authentication、disputes、fraud detectionといったものです。これらはすべてKinesisストリームを通じて私たちのシステムに届きます。それがAmazon SNSに入り、ファンアウトします。私たちは多数のLambdaを持っています。画面上の図は非常に簡略化したものです。トランザクション情報の一部の保存にはDynamoDBを使っています。というのも、決済の中には、かなり先の将来に何かが起こり得るものが多くあるからです。決済を行った後、ディスピュート（係争）が数年後に発生することもあり得ます。ですから、ここには永続性が必要です。そのため、永続的な情報を保持するためにDynamoDBを使っています。そして、このインデキシングのプロセスがあり、ここでも再びSNSトピックとSQSキュー、そしてLambdaを組み合わせて使い、私たちのデータを、この場合は旧インフラであるElasticsearchに送り込んでいます。Elasticsearchはその後、Search APIから提供・検索され、私たちのダッシュボードがこのAPIを呼び出して、皆さんのためにすべての情報を取得します。すでにお分かりのとおり、これはかなり複雑な構成です。多くのイベントストリームと、それらをすべて一つにまとめ上げて構築するための数多くのインフラが存在しているのです。
2.2 移行の動機、代替候補の検討、OpenSearch選定とトレードオフ
Anthony： 次のページですが、これが移行前に私たちが使っていたものです。Elasticsearch 7.10.2を使っていました。これはかなり古いバージョンのElasticsearchです。これは外部のベンダーが私たちのために提供していました。Kamberが言っていたように、OpenSearchでさえインフラに関して理解し管理しなければならないことが多くありますが、Elasticsearchについて言えば、それがおそらく何倍にもなります。自分でEC2インスタンスを用意しなければならず、Elasticsearchをインストールしなければならず、そうしたことをすべて自分でやらなければなりません。これは私たちに多くの運用上の負担をもたらしました。そして、これらのバージョンを更新するのが難しいこともありました。では私たちは何を望んだのか。私たちはこのインフラを自分たちで所有したいと考え、こうした複雑さを手伝ってもらうために雇うサードパーティに依存したくなかったのです。私たちはより速く機能を出荷したいと考え、あのプロバイダーに依存したくありませんでした。そして、インフラではなくプロダクトの面で革新したいと考えていました。古いバージョンのElasticsearchの機能の一部は、私たちが前進するのを助けてはくれなかったのです。
Anthony： ではOpenSearch以外に何を検討したのか。私たちはDynamoDBを、これを実現できるシンプルなNoSQLデータベースとして検討しましたが、これは私たちにとってうまくいくものではありませんでした。私たちは深い検索能力を必要としていて、DynamoDBはそれを提供してくれそうになかったのです。Azure AI Searchも検討しました。これは私たちが望む機能を提供してくれたはずですが、よりコストが高く、その新しいサービスへ実際に移行するにはおそらくより大きな労力がかかると分かりました。ほかにも多くのデータベースを検討しました。ここにいくつか例を示しているだけです。最終的に、私たちはOpenSearchに決めました。OpenSearchに決めた理由は、カスタムな最適化ができる点です。私たちのシステムには特有のティアリングがあります。データが一定の時点を過ぎると、コストを節約するためにより冷たい（コールドな）ティアに移動させるのです。OpenSearchはこの機能の一部を提供してくれます。これについては後ほど少しお話しします。また、私たちが持っていたものからOpenSearchへ移ることの移行の容易さもありました。OpenSearchは本質的にElasticsearchのオープンなバージョンですので、私たちにとっては容易でした。とはいえいくつかの課題はあり、それも後ほどお話しします。さらに、OpenSearchで見えていた将来の機能改善のいくつかも検討しました。それらはロードマップ上にあり、私たちの他の取り組みを推し進めることを可能にしてくれるものでした。
Anthony： これが私たちのトレードオフです。computeとstorageの結合に関していくつかのトレードオフをしました。OpenSearchではこれらを結合させなければならなかった一方、Elasticsearchを動かしていたときには少し分離させていました。私たちはある程度オーバープロビジョニングをしなければなりませんでした。オーバープロビジョニングをせざるを得なかった理由は、私たちのtiered storageのやり方が、最近までかなりカスタムなものだったからです。昨年の終わり頃まで、OpenSearchは私たちが望むやり方でのtiered storage、つまり決済データの段階的なストレージを十分にはサポートしていませんでした。主に、私たちはものをカスタムな基準で移動させたいからです。これは今ではサポートされていますが、当時はそういうトレードオフをしたということです。
3. checkout.comの移行プロセス・運用課題・今後の展望
3.1 移行手順と移行時・移行後に直面した課題
Anthony： ここからは、私たちが実際にどうやってこの移行を行ったのか、興味がある方のために移行プロセスのお話をします。私たちがここでやったのは、まずdual write（二重書き込み）から始めるということです。つまり両方のシステムに同時に書き込みを行い、その裏側でそれらの二重書き込みを検証していました。私たちはcheckerと呼んでいるシステムを持っていて、それはこの決済が両方のシステムに、私たちが期待するとおりまったく同じ状態で存在することをただチェックするものです。これによって、私たちの顧客は何も違いを感じることがありませんでした。それらの二重書き込みを検証し終えたら、新しいOpenSearchに移ってくる古いデータについてsnapshot restore（スナップショットからの復元）を行い、そのデータを検証してすべてが問題ないことを確認したうえで、read cut over（読み取りの切り替え）を行いました。つまり、新しいOpenSearchから読み取りを行い、書き込みは引き続き古いElasticsearchに対して行ったのです。これは、もしロールバックなどをしたくなった場合に、比較的簡単にそれができることを意味しました。そして最後にwrite cut over（書き込みの切り替え）を行い、ここで「もう古いElasticsearchへの書き込みは止める、すべて問題ない」と判断しました。顧客はすべてを新しいOpenSearchのプロセスから得ているわけです。このプロセスは昨年の終わり頃に完了しました。これが私たちの道のりであり、その過程を進めるためのプロセスでした。
Anthony： これらが、実際にこの移行を行ったときに直面した課題です。私たちはOpenSearchのバージョン2に移行しました。Kamberが今まさに3.3が出ているという話をしましたが、なぜバージョン2にしたのか。それは、私たちのレガシーなElasticsearchのバージョンが特定のLuceneのインデックスバージョンしかサポートしておらず、OpenSearch 3へ移るためにやらなければならなかったのは、すべてを再インデックス（reindex）することだったからです。私たちは今それを進めているところで、まもなくOpenSearch 3へアップグレードする予定です。これがレガシーなLuceneのバージョンの問題でした。また、移行した後、いくつかのP99レイテンシのスパイクが見られるようになりました。これは主に、人々が長い期間にわたって行うクエリによるものでした。たとえば2年前、3年前の決済が欲しい、といったケースです。これによってシステムが高いCPU負荷、高いメモリ負荷を抱えることが分かりました。その結果としてP99に悪影響が出ていたのですが、私たちはこれを最近実際に修正し、やり方にいくつかの最適化を加えました。ですから、これは実のところOpenSearchの問題ではなく、私たちが社内でシステムをどう使っていたかという問題でした。むしろこれは、私たちがよりパフォーマンスを出せるようになる助けになったのです。これらの問題はすべて、クエリの最適化と、ノードをより適切にライトサイジングすることで解決しました。私たちはOpenSearchのアンマネージドではなく、マネージドのアプローチを選びました。そして今、これらすべてがバージョン3への移行の準備につながっています。
3.2 今後の展望：OpenSearch 3、agentic dashboard、MCP連携
Anthony： 移行を終えた今、私たちにとっての未来とは何でしょうか。私たちにとっての未来は、まずOpenSearch 3に到達することだと考えています。それはより高いパフォーマンスを与えてくれますし、コスト面のメリットももたらしてくれます。OpenSearch 3への移行で実現できる最適化やコスト削減は数多くあります。これらは主に、tiered storage、agentic search、そして先ほどお話ししたような継続的な最適化に関わるものです。私たちはagentic dashboardも使いたいと考えています。これは新しいバージョンのOpenSearchが私たちに与えてくれるもので、自然言語によるクエリや複雑なクエリを、本物のDSLなしで実行できる能力です。たとえば誰かが「ここ3か月の自分のApple Pay決済すべてに何が起きたのか知りたい」と尋ねることができ、ダッシュボード上で大量のフィルターなどをいちいち使う必要がなくなります。これは私たちの顧客にとって、はるかに優れた体験をもたらすと感じています。さらに、私たちはMCPとも統合したいと考えています。今朝もMCPについては皆さんが多くを語っていましたが、私たちも他の皆さんと同じくらいこれに関心を持っています。私たちは他のagenticなエージェントも構築しており、また構築中です。これらのエージェントが、私たちがOpenSearch上に持っているデータと対話できるようにし、その非常に重要なデータソースを提供するためにMCPを使いたいのです。私からはおおよそ以上です。それでは、OpenSearchの未来についてより広く語ってくれるKamberにバトンを戻します。皆さん、ありがとうございました。
4. 検索の進化とAgentic Search
4.1 検索の進化のタイムライン：キーワードからセマンティック、ハイブリッド、agenticへ
Kamber： 素晴らしい、ありがとうAnthony。さてここからは、これから先に何があるのか、OpenSearchの未来、あるいは検索全般の未来についてお話ししたいと思います。ただ、その前に、私たちがどこから始まり、どこへ向かっているのかを示す、きちんとしたタイムラインが必要です。私たちが始まった地点はキーワードでした。誰もが知っていて、誰もが愛するものです。これは主要なストレージのソリューションで、基本的にBM25という完全な語句一致のアルゴリズムを使っていました。ここではドキュメントは、クエリが同じ語句を含んでいる場合にのみマッチします。もちろん同義語を使うことはできますが、しかし、もし誰かがクエリをある特定の言い回しで言い換えると、ドキュメントはマッチしなくなり、それが関連性スコアの低下につながってしまいます。つまり、キーワード検索にはユーザーの意図というものがまったく組み込まれていなかったのです。
Kamber： その次にセマンティック検索が登場します。AIの能力の進歩によって何が起きたかというと、今やクエリが何を意味しているのか、あるいはドキュメントが何を意味しているのかさえもエンコードできるようになり、それをn次元の空間に置いて、ユーザーが何を求めているのかという意味的な意図を捉えられるようになりました。これでキーワード検索が与えてくれなかったユーザーの意図を、実際に理解できるようになったわけです。しかし、検索サービスを使うペルソナにはさまざまな種類があります。基本的に、自分が何を探しているのかをはっきり分かっているペルソナがいます。典型的なe-commerceの例で言えば、写真について非常に詳しくて、特定のカメラを名指しで尋ねるような人です。一方で、写真をちょうど始めたばかりで、ただカメラが欲しいだけのユーザーもいます。彼らが投げるクエリは大きく異なります。そこで私たちが目にしているのは、組織がハイブリッドな構造へと移行していることです。つまり両方の良いところを取り、キーワード検索とセマンティック検索をスコアリングのアルゴリズムの中で組み合わせ、両方のペルソナに同時に対応できるようにするのです。そして今、私たちはagenticな機能へと向かっています。セマンティックなストレージから始まったこの流れは、RAG（retrieval augmented generation、検索拡張生成）の能力をもたらしました。なぜなら、LLMは効率的なデータ取得のアルゴリズムによって自らの回答を根拠づける必要があったからです。しかし、これはいわば「fire and forget（撃ちっぱなし）」のようなものです。そこにはreasoning（推論）が関わっておらず、意図は関わっているとはいえ、エージェントはユーザーからより多くの文脈を得ることでこれをより良くできます。
4.2 Agentic Searchの具体例とデータ準備・エージェント化
Kamber： メモリ、つまり文脈の中で、ユーザーはエージェントと複数回のやり取りをしてきたかもしれず、会話的なストレージの体験を提供します。エージェントは今や私というユーザーを知っているので、私が「自分のお気に入りの選手のアイテムを持ってきて」と言えば、私のお気に入りの選手が誰なのかを知っているわけです。これに加えてreasoningの能力が、検索体験をはるかに正確にしてくれます。一つ例を歩いて見ていきたいと思います。たとえば、私は昨夜の試合を観て、Steph Curryが履いていたのと同じシューズを履きたい、そして価格帯はだいたい200ドルくらいだとします。ここで私がやらなければならないことは数多くあります。もしこれを検索エンジンにそのまま投げても、正しい答えが返ってくる方法はまずありません。私はまず、あの試合は何だったのか、彼が実際に何を履いていたのかを知る必要があり、おそらく写真も手に入れる必要があり、そうして実際の商品を理解したうえで、ようやくアプリケーションでクエリを設計して投げることができます。それはマルチモーダルなクエリかもしれませんし、テキストのクエリかもしれませんが、いずれにせよ私自身がこうした作業を行い、web検索をして理解する必要があるのです。
Kamber： ここでできることは複数あります。やはりembeddingのようなものかもしれませんし、依然としてセマンティクスを使っているかもしれません。データ準備の面でできることはたくさんあります。私たちはユーザーの行動を分析し、ユーザーの行動に合致するドキュメントを作成します。そして価格タグに基づいてフィルタリングし、さらに私たちのパーソナライゼーションの経験に基づいてリランク（再ランキング）することもできます。では、このユースケースをagenticなユースケースに持ち込むと、今度はエージェントが真ん中の部分になります。エージェントが、いわばソフトウェアの形をした私であり、私の代わりにそうした作業をすべて行ってくれるのです。まず文脈を得ること。ここでも私は簡単に「お気に入りの選手のシューズを持ってきて」と言うだけでよく、私のお気に入りの選手が誰なのかは、エージェントが持っている文脈のおかげでエージェントが知っています。そしてエージェントは複数のツールにアクセスできます。web検索にアクセスでき、私の代わりにそのすべての検索を行い、すべてのデータを集めてくれます。reasoningの能力を使って、実際に結果、つまり私が欲しいシューズを提示する前に、異なるデータソースに対して異なるクエリを投げる必要があるかどうかを理解します。これが検索の未来です。今や私たちには、文脈を知り、ユーザーを知り、どのツールを使い、どのデータソースを使うべきかを知っているエージェントがいて、私たちに関連性の高い結果を持ってきてくれるのです。
4.3 OpenSearchのエージェントフレームワークとreasoningループによる精度向上
Kamber： OpenSearchの文脈で言うと、OpenSearch自体の中にagenticなフレームワークが組み込まれています。これは実際に皆さんのクラスタの中で動いています。OpenSearchのエージェントフレームワークには、3つの基礎的な柱があります。まず私たちが確実にしたいのは、外部でホストされているエージェントも、OpenSearchのサービスやエンジンが提供するツールとやり取りできるようにすることです。ですから、どこかでエージェントが動いていて、マルチエージェントのコラボレーションをしたいのであれば、OpenSearchのMCPサーバーを使って、list indices（インデックスの一覧取得）やvector DBの検索といったツール、さらにそれ以上のものにアクセスできます。次にメモリ。これは非常に重要な概念です。なぜなら、これがエージェントが文脈を知る方法であり、エージェントがユーザーから必要な情報を掴み取る方法であり、そしてエージェントが実際にユーザー自身になる方法だからです。OpenSearchの中にもメモリのユニットが組み込まれていて、long-term（長期）とshort-term（短期）の両方の会話を保存できます。そして最後の要素として、特化したエージェントがあります。私たちは異なるユースケースのために専用に作られた複数のエージェントを持っていて、確か5種類のエージェントがあります。ユースケースに応じて、どのエージェントの種類を使うかを選ぶことができます。これらはすべてOpenSearchの中に組み込まれていますが、MCPサーバーの統合があれば、このエージェントはAgentCoreのようなどこか別の場所で動かしつつ、それでもOpenSearch内のエージェント機能にアクセスすることができます。
Kamber： ですから、ユーザーがクエリを投げると何が起きるか。これは今やOpenSearchの中での話です。ユーザーのクエリがあり、エージェント自体がそのクエリを受け取ります。これは今や会話的なインターフェースであり、メモリという面での文脈と、データソースに保存しているものという面での文脈が必要になります。そしてエージェント自体がクエリプランニングを行います。Anthonyが言っていたように、curlのDSLを書く必要はありません。会話的なインターフェースが、indicesそのものへのアクセスとともに、それを提供してくれます。さらに、定性的・定量的なデータへのアクセスは依然として必要になりますので、エージェントの一部としてセマンティック検索の能力も引き続き使うことができます。OpenSearchでエージェントフレームワークを構築するうえでの構成要素の一つは、私たちが柔軟であろうとした点です。つまり、OpenSearchに組み込まれたMCPサーバーを使って、異なるエージェントとも統合できるようにしたかったのです。そして私たちが見てきたのは、このreasoningのループ全体を通じて起きていることとして、これがセマンティック検索の能力よりもはるかに正確だということです。なぜなら今やエージェントが実際に推論できるからです。「これが私が得た結果だが、本当に関連性があるのか。もっとやる必要があるか。ループを回してもう一度推論し、なるほど、ではクエリに対する正しい答えを得るためにはこうすべきかもしれない」と考えるのです。これがOpenSearchにおけるagentic searchの姿です。
5. まとめとQ&A
5.1 Call to Action、リソース、Q&A（DynamoDB選定・ガードレール）
Kamber： それでは、call to actionです。もしcheckout.comについてもっと知りたいということでしたら、彼らのpayment search APIに関する情報をまとめておきましたし、ケーススタディやニュースルーム、プレスリリースもあります。さらに、私たちのAWSの同僚が書いた本当に良いブログもあります。OpenSearch Serviceを使った会話的な検索（conversational search）の設計について書かれた、とてもおすすめのブログがあり、こうしたエージェントをどうやって構築するかが語られています。ドキュメントへのリンクもいくつかここに載せています。とても幅広く、とても大きなトピックであることは承知していますが、これらのリソースが、構築を始めるための十分な情報を皆さんに与えてくれることを願っています。これでプレゼンテーションは終わりです。それでは、私かAnthonyへのQ&Aの場を開きたいと思います。
Kamber： 質問を繰り返しますと、checkout.comの中でのDynamoDBとOpenSearchの選定プロセスについてのご質問でした。Anthony、お願いしてもいいですか。
Anthony： DynamoDBについて主に言えるのは、partition keyが分かっていて、自分が何を探しているのかを正確に分かっている場合には、本当に良いデータベースだということです。しかし、自分が何を探しているのか正確には分からない場合や、もう少し曖昧（fuzzy）なことをしたい顧客がいる場合には、DynamoDBはこうした状況ではあまり良い選択ではありません。通常、こうしたことをDynamoDBにやらせることは一応できると思いますが、実際にそれをやろうとすると、その処理はElasticsearchやOpenSearchでやるよりもおそらく遅くなってしまうでしょう。OpenSearchはこの種のファジーマッチングに本当に優れていて、これが私たちがその選択をした理由です。
Kamber： Anthonyが言ったことをそのまま繰り返す形になりますが、厳密なフィルターを探しているのであれば良いデータベースです。ただ、全文検索やlexical storage（語彙的なストレージ）はそれ以上のものです。そこには複数の言語が関わっていて、stemming（語幹処理）があり、stopper（ストップワード処理）があり、設定できるsynonym（同義語）があります。これらが、関連性の高い結果をユーザーに返す助けになります。一方DynamoDBにも、繰り返しになりますがそれを実現する方法はあるものの、全文検索という面では、OpenSearchが提供する言語アナライザほど幅広くはありません。
Anthony： その通りです。もしユースケースが満たされるのであれば、OpenSearchの本家バージョンでは使えるけれどもマネージドのOpenSearchでは使えない機能もいくつかありますが、ご自身のケースがそれで満たされるのであれば、本当に簡単に立ち上げられます。完全にマネージドですから、そういったことを心配する必要はありません。
Anthony： ガードレールについてのご質問は、要するに、OpenSearchを使う際にどうやって適切にガードレールを実装し、間違った決済情報を間違った人に渡してしまわないようにするのか、ということでした。OpenSearchは本来、そうしたガードレールを特にその中に置くためのものではありません。私たちはこれをどうしているかというと、具体的には私たちのAPIサービスの側でこれを行っています。認証・認可のやり方として、私たちのダッシュボードから届く呼び出しには、その顧客が誰なのかを明確に決定づける特定の値が含まれており、私たちはそれらの値を使って、データソース、この場合はOpenSearchから何を取得するかを決定します。ですから、この状況ではこれは少し切り離して扱っています。もしagentic AIのエージェントを使うのであれば、ガードレールはBedrockやAgentCoreの中に置かれることになるでしょう。それは少し違った状況になりますね。
Kamber： 他にもう質問はないようですね。それでは、改めて、お時間を割いていただきありがとうございました。イベントを楽しんでいただければと思います。