re:Invent 2025: data meshから生成AIまでのマルチクラウドソリューション設計とアーキテクチャパターン
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Architecting multicloud solutions from data mesh to generative AI (HMC210)
この動画では、Don SimpsonとDeevanshu Budhirajaが、マルチクラウド環境におけるデータ戦略とアーキテクチャパターンについて解説しています。M&Aや差別化された機能といったマルチクラウドの主要ドライバーを説明し、data gravityやデータガバナンスといった課題に対処するため、materialized viewsやfederated queriesなどの技術的アプローチを紹介します。data meshアーキテクチャの利点とトレードオフ、federated query engineのコアコンポーネントについて詳述し、生成AIの文脈ではRAG、structured RAG、graph RAGといった複数のパターンを提示します。さらに、Model Context Protocolを活用したエージェントによるマルチクラウドデータアクセスや、LLM gateway routerを用いたモデル選択の最適化についても言及し、実践的なマルチクラウドソリューションの設計指針を提供しています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
セッション概要とアジェンダ：データメッシュから生成AIまでのマルチクラウドソリューション
よろしいですか、皆さん聞こえていますか？素晴らしい。もし何か問題があれば、後ろにいる誰かに声をかけてください。手伝ってくれますよ。まず最初に、本日はこのセッションにお越しいただき、本当にありがとうございます。私たちは、データメッシュから生成 AI まで、マルチクラウドソリューションのアーキテクチャについてお話しします。私の名前は Don Simpson で、私たちのクラウドと AI イノベーションチームのプリンシパルテクノロジストです。私たちのチームは、マルチクラウド、データメッシュ、生成 AI など、多くのことに焦点を当てています。
同僚の Deevanshu に自己紹介をする機会を与えたいと思います。皆さん、こんにちは。私の名前は Deevanshu Budhiraja で、金融サービス顧客向けのシニアソリューションアーキテクトとして働いています。私は多くの金融サービス顧客と保険顧客を扱ってきており、彼らはマルチクラウド環境にいて、効果的なデータ戦略を構築したいと考えていました。ですから、私たちは今日、それをお手伝いするためにここにいます。
では、始めましょう。いくつかの期待値を設定したいと思います。本日は、クラウドに依存しないパターンに多く焦点を当てます。次に、私たちが議論しているパターンに関連する AWS サービスについて二次的にお話しします。そして最後に、これはサイレントセッションなので、その後、ご質問があれば、廊下でお話しする機会があります。
最初にお話ししたいのは、私たちのアジェンダです。データ戦略の概要を説明します。レベルセットを行います。顧客の声、つまり顧客から聞いている内容についてお話しします。シナリオと課題についてお話しし、その後、推奨設計とアーキテクチャパターンについて説明します。最後に、生成 AI コンポーネントを含めずにはいられないと思うので、このセッションの最後の部分はマルチクラウド生成 AI についてになります。
マルチクラウドの定義とクラウド成熟度モデル：主要ドライバーと組織的課題
まず最初に、マルチクラウドが何を意味するのかについてレベルセットしたいと思います。AWS でマルチクラウドについて話すとき、私たちが考えることがいくつかあります。1 つは、複数のワークロード、IT ソリューション、またはアプリケーションが複数のクラウドサービスプロバイダーで実行されている場合です。私たちは必ずしも SaaS のようなものをそれに含めるわけではないので、私たちがその理解を持つことは良いことだと思います。
もう一つは、私たちが今日お話しする内容の理解の基盤となっているのが、クラウド成熟度モデルです。これは私たちのオープンアライアンス・フォー・クラウド・アドプションの一部です。また、マルチクラウドの主要なドライバーと二次的なドライバーを理解することも重要です。主要なドライバーの例としては、M&A、つまり合併・買収が挙げられます。多くの場合、お客様がマルチクラウド運用環境を持つようになるのは、買収または複数の買収が原因です。こうした買収には、しばしば突然の予期しない移行が伴い、デューデリジェンスから統合への移行の際に、お客様が直面する移行上の課題があります。
もう一つは、お客様がマルチクラウドを差別化された機能、つまり差別化されたサービスのために検討しているケースです。また、規制の観点からも見られます。これはデータ主権またはクラウド集中リスクの可能性があります。これらは規制当局を通じてお客様から聞く事項です。では、このマルチクラウドの定義について話しているので、ここで会場の皆さんに簡単に手を挙げていただきたいのですが、複数のクラウドにまたがるデータを持っている方、そしてそれがサイロ化されているか、統合・相関させようとしている方はいますか？そして、その最初の質問に「はい」と答えた方で、実際にそれが複数のクラウドに分散しているために、ビジネス成果を達成するのに課題がある方はいますか？最初に手を挙げた人のほぼ全員です。
さらに、さっき言及したマルチクラウドアプローチを見ると、クラウド成熟度モデルは、人、プロセス、テクノロジーに焦点を当てています。私たちは、データを戦略的資産として、または運用効率もしくは追加のビジネス価値のいずれかによって生み出される価値として作成するというトップダウンのビジョンと戦略が非常に重要だと考えています。人の観点から見ると、お客様が苦労している領域の一つはマルチクラウドスキルギャップです。人の観点からは、従業員をアップスキルし、agentic AI と AI アシスタンスで補強することが重要です。プロセスの観点から見ると、成熟度モデルは、組織が Cloud Center of Excellence、つまり CCOE をどのように構築しているかに基づいて、特化の観点から組織を見ています。
個々のクラウドサービスプロバイダーレベルでの特化があるかどうかを見ています。アーキテクチャ、プラットフォームエンジニアリング、テクノロジーなどの特定の領域にわたってです。私たちはテクノロジーを最初に見る傾向があります。なぜなら私たちはテクノロジストだからです。しかし、マルチクラウドアーキテクチャ、マルチクラウドサービス、そして私たちが先ほど発表した Interconnect for multi-cloud のような最近の発表は、AWS がお客様がこれまで以上にマルチクラウド環境で運用できるようにするサービスを提供するために取っているステップです。
データ戦略の定義と顧客の声：M&A、差別化された機能、そして意図的なアプローチ
ここで定義をいくつか説明させていただきます。この 2 つの定義を並べるのが好きなのは、互いに補完し合っていると思うからですが、同時に十分に異なっています。最初は Gartner からのもので、このデータ戦略の定義は本当に重要なことをいくつか説明しています。これは非常にダイナミックなプロセスを説明しており、私たちは皆これを経験していると思います。今日何かを構築すると、明日追加の要件があることに気づいたり、何かが変わったりします。この定義はデータの取得、整理、分析、提供に焦点を当てる傾向があります。つまり、それは本当にそのプロセスについてのものです。
ここで示されている AWS の定義では、人、プロセス、テクノロジー、ルールといった似たようなテーマが見られます。これについて考えると、一つはより高いレベルのもので、もう一つはテクノロジーに深く入り込んでいます。これは後ほどの議論の中で見えてくると思います。data mesh やフェデレーテッドクエリといったパターンについて掘り下げていきます。 顧客の声を交えた例をいくつか使ってお話しします。このケースでは、これらの引用に関連していると思われる部分をハイライトしています。
さっき M&A についてお話しして、統合フェーズについて触れました。顧客からよく聞く話なのですが、この統合の部分で本当に苦労しているんです。企業を買収して、見方によってはゼロデイまたは初日の状態から始まるわけですが、プロセスを開始しています。M&A に関連した多くのビジネスプロセスがあります。例えば、ワークロード配置戦略—自分のワークロードはどこに置くのか。買収した企業の中に、あるクラウドサービスプロバイダー上にあるワークロードがあります。それらをマイグレーションするのか。それとも目的を変えるのか。リプラットフォームするのか。どうするのか。
その次は、テクノロジー統合のような話になります。例えば、買収した企業を統合するための特定の統合パターンを持っているかどうか。例えば、AWS PrivateLink を使って、2 つの組織間でネットワークアクセスを完全に付与することなく、安全にデータを転送できます。ここで最も重要なのは、プロアクティブな戦略を持つことです。ワークロード配置のようなことについて触れましたが、買収する際に意図を持つことで、統合方法についてプロアクティブに対応できるようになります。
次に焦点を当てる領域は、マルチクラウドアーキテクチャです。これは差別化された機能です—適切なデータとテクノロジーを適切なクラウドに配置することです。ここには言及されていないけれども、実際に存在するものがあります。例えば、データグラビティです。これは本当の課題です。特定の場所に持つデータが多いほど、その場所に引き寄せられるデータ、アプリケーション、サービスが増えます。これは複数のクラウドを扱う際に私たちにとって課題になり、差別化された機能を活用することについてです。
差別化された機能について考える際には、何かをしている理由についてしっかりした理解を持って進めたいと思います。マルチクラウドについて考える際、これは非常に重要だと思います。最後のこの引用は興味深い観察で、クラウドからクラウドへ動的に移動したり、コンピュートをスケールアップ・ダウンしたりすることについて多くの話がありますが、これは過度に誇大評価されています。現実は、いくつかのワークロードとある業界ではこれでいいかもしれませんが、高度に規制された顧客にとっては、これが正しい戦略ではないかもしれません。
よく、みんなやってるからうちもやらなきゃいけないんじゃないかって話を聞きますよね。でも私たちは、まずは良い意図から始めましょうっていうことを言いたいんです。つまり、あなたが達成したいビジネス成果は何なのか、そこから逆算して考えましょうということです。そして、根拠のあるガイダンスを確保してください。つまり、ちゃんと調査をして、これが自分たちにとって本当に正しい戦略なのかを確認してから進めるということです。では、ここで Deevanshu Budhiraja に、マルチクラウドのデータシナリオと課題についてお話しいただきたいと思います。ありがとうございました。
マルチクラウドデータシナリオと課題：data gravityからガバナンスまで、そして解決のための機能
Don が言及したように、マルチクラウドの定義、データに関連するシナリオと課題、そしてそれらの課題をどのように解決するのかについてお話しします。まずはシナリオについて議論しましょう。
さっき data gravity について話しましたが、これはマルチクラウドにとって本当に大きな課題なんです。複数のクラウドを使いたい理由はいろいろあります。コストの問題かもしれませんし、地域的な利用可能性かもしれませんし、あるいは最高のサービスを選びたいからかもしれません。でも現実は、データには重力があるんです。主要なアプリケーションがあるクラウドに、すべてのデータが引き寄せられていくんです。この data gravity の課題があるから、マルチクラウドを効果的に活用することが難しくなるわけです。だからこそ、こういった課題をどう解決するかについて話し合う必要があるんです。
複数のクラウドを使う場合、データガバナンスとコントロールの課題も出てきます。これには、ガバナンスとセキュリティポリシーをどう実装するか、そしてコントロールをどう実装するかが含まれます。なぜなら、クラウドごとに異なるやり方があり、異なる API があるからです。Don も M&A について言及しましたが、私はこれを、たとえあなたがそれを望まなかったとしても、強制されたマルチクラウド状況と呼ぶこともあります。買収した企業から最高のものを得たいという意図はあるんですが、その企業から抽出したいデータと、そのデータを実現したり収益化したりするまでの時間が課題になることがあります。なぜなら、2 つのクラウドに対応した適切なデータアーキテクチャやコントロールがないからです。
さっき議論したシナリオと課題には、一対一の関係がないんです。例えば、M&A は右側に見えるすべての課題、つまり gravity やガバナンスなど、そういったものの原因になる可能性があります。実は、シナリオと課題の間には一対一のマッピングがないんです。これらのシナリオのどれもが、ここに列挙されている問題を引き起こす可能性があるんです。では、これらの課題に対処するための機能についていくつか話しましょう。
まず、皆さんに聞きたいのですが、materialized views（マテリアライズドビュー）やfederated queries（フェデレーテッドクエリ）について聞いたことがある人はいますか？何人かはいるでしょう。それは素晴らしいことです。知らない人のために、materialized viewsを理解するための実世界の例え話をしたいと思います。私は事前調理済み食事の例えが好きです。日曜日の夜に一週間分の食事を調理しておくので、月曜日、火曜日、その後の日々に再度それらの材料や食材を集めて調理する必要がないわけです。
マルチクラウドとmaterialized viewsの場合、異なるクラウドに生データがあります。異なるソースからデータを計算して結合する代わりに、そのデータを事前計算して事前結合し、それをそのデータのスナップショットと呼びます。そのデータを参照する必要があるときはいつでも、これらのクラウドに再度アクセスする必要がなく、すべてを再計算する必要もありません。なぜなら、データへのアクセスには計算が必要だからです。その処理を節約するために、事前計算してmaterialized viewを作成します。これにより、時間を節約できるという利点が得られます。事前計算されたデータを保存する必要があるため、ある程度のスペースコストがかかりますが、コストと時間のバランスを取る必要があります。実際のところ、ほとんどの場合、時間が重要です。
Federated queriesは、data gravity問題を解決するもう一つの方法です。Booking.comやClearTripのようなブッキングアプリを考えてみてください。Booking.comは、データを中央の場所に移動することなく、異なる航空会社プロバイダーとホテルプロバイダーからデータを取得します。APIまたは使用するメカニズムを通じてこれらすべてのデータソースをクロールできるfederation層が作成されており、データを移動することなくデータを提供します。data gravity問題があっても、それを修正するために反data gravity的なことをしたり、プライマリクラウドとして指定したクラウドからデータを移動する必要はありません。
大量の往復移動をすることなく、データにアクセスする能力を持つことができます。データガバナンスとデータマネタイゼーション、time to valueと加速を解決するために、別の効果的な方法は分散アーキテクチャを構築することです。そして、それについてさらに詳しく掘り下げていきます。分散アーキテクチャをどのように構築できるのか？それを行うための異なるアーキテクチャパターンは何か？ある意味では、複数のクラウドに分散されたデータがあり、これらの異なるソースと効果的に通信できるガバナンス層、データアクセス層をどのように作成するかということです。
データリネージをキャプチャするために、これは非常に重要です。なぜなら、データがどこから発信されているのか、そのデータをどのように信頼するのかを知る必要があるからです。複数のクラウド全体でdata lineageの問題を解決するために、効果的なメタデータ戦略と管理が必要です。私が今話していた概念の一つはfederated queryで、これはmaterialized viewsの基盤として機能し、場合によっては分散アーキテクチャの基盤としても機能します。Federated queryはこれらのアーキテクチャパターンを可能にします。
Materialized viewsとdata meshアーキテクチャ：実装パターンとトレードオフ
では、materialized views の実践的な例についてお話しします。今日、クラウドプロバイダーによって materialized views を定義する方法が異なります。例えば、Google Cloud には BigQuery Omni があり、materialized views を定義できます。Amazon には S3 と Athena という materialized views をサポートするものがあります。また Apache Iceberg tables のサポートもあり、materialized views をリフレッシュできます。Athena Federated Query を使用して Federated query も作成できます。その際、Google BigQuery 用の組み込みコネクタがあります。
BigQuery をデータソースとして Amazon 内で定義して、実際に選択することができます。Athena コネクタを使用すれば、AWS クラウドにいながら Google Cloud からそのデータを移動させることなくアクセスできます。Google Cloud でも同じことができます。これはどちらかを選ぶ選択肢で、プライマリクラウドが何か、セカンダリクラウドが何か、そしてデータアーキテクチャがどこにあるか、つまりデータの大部分がどこに置かれているかによって異なります。分散型アーキテクチャについて話していたように、data mesh や data fabric という言葉を聞いたことがあるかもしれません。
Data mesh は、異なるクラウドプロバイダー間または異なるデータソース間でデータを共有する方法を定義しており、data domain owners を作成し、データを製品として扱います。各ドメインオーナーが独自のデータ製品を作成します。その data mesh アーキテクチャを通じてそのデータ製品を消費する消費者がいます。次のスライドでもう少し詳しく説明します。メタデータカタログは、先ほど話したように、異なるクラウドプロバイダー間でデータを効果的に管理する方法です。サイズ、出所、アクセス方法など、そのデータのメタデータを追跡する必要があります。異なるクラウドネイティブツールまたは複数のクラウドで機能するサードパーティツールを使用して追跡します。
では、data mesh アーキテクチャについてもう少し詳しく掘り下げてみましょう。典型的な data mesh アーキテクチャでは、data marketplace、つまり中央のマーケットプレイス、中央のデータマーケットプレイスを作成します。データの生産者はデータセットを作成します。保険会社の例をもう一度使わせてください。保険会社の顧客と多く取引しているからです。保険会社が data mesh を作成したいと考えてみてください。データプロデューサーを、顧客データ、ポリシー、クレームの管理を担当するチームの 1 つと考えてください。彼らは顧客と保険ポリシーについて大量のデータを作成しています。
その後、右側には、そのデータの消費者、おそらく価格設定チーム、おそらくマーケティングチームがいます。彼らはそのデータを消費して、新しい地域、新しい顧客ベースに保険ポリシーをどれだけ効果的に販売できるかを見たいと考えています。中央のチームは、プロデューサーとコンシューマーの両方に data marketplace を通じてサポートを提供し、すべてのチームが境界なくデータを共有できるようにします。データが異なるクラウドや異なるソース、またはオンプレミスに置かれていても、data mesh で作成する抽象化レイヤーにより、境界のないデータ共有が可能になります。
このアーキテクチャパターンにはいくつかのトレードオフがあります。明らかに利点と欠点があり、正しく実装されていない場合は問題が生じます。 self-service BI、または data mesh を通じた self-service データアクセスの自律性は利点ですが、時にはデータサイロのコストが伴う可能性があります。なぜなら、前の例の顧客関係管理チームやポリシー、引受チームのような異なるドメインオーナーが、既に存在する重複したデータセットを作成することがあり、時には厳格なコンプライアンス上の問題により他のチームが使用できないデータセットを作成することもあるからです。
data mesh を設計する際には、データセットをどのように作成し、どのように共有するかについて合意されたプリンシプルと合意された標準を持つことが非常に重要です。データを生成するチームが生成したデータを他のチームが消費することが、技術的または体系的な課題になってはいけません。そうしないと、重複する可能性のある多くのデータセットを作成してしまい、サイロを生み出してしまいます。同様に、標準化に関しても、data mesh はデータの作成、共有、生成のための標準を作成し、マーケットプレイスなどすべてのものが、最初から多くの事前エンジニアリングの複雑性を必要とします。多くの場合、リーダーシップと技術サポートからのサポートが不足しており、機能に関する制限があります。これらすべてのことは、data mesh 戦略を開始する前に検討する必要があります。
data mesh は、IT チームに依存する中央データアーキテクチャと比較して、作成する際に多くの制御と柔軟性を提供します。この制御と柔軟性は、ドメインオーナーまたはデータオーナーとしてあなた自身がデータセットを定義し、独自のデータセットを作成し、他のチームがそれらにアクセスできるようにすることができるという利点がある一方で、異なるデータチームと異なるデータオーナー間での実装の不一貫性のコストが伴う可能性があります。なぜなら、あるチームはセキュリティコントロールや暗号化を作成したいと考えるかもしれませんが、別のチームは独自の制限により、それらのコントロールに従うことができないかもしれないからです。
Federated queryエンジンの仕組み：コアコンポーネントと実装上の考慮事項
それでは、federated query という別のアーキテクチャパターンについて話しましょう。federated query の場合、federated query エンジンにクエリを送信します。そのエンジンにはいくつかのコアコンポーネントがあります。 例えば、メタデータ管理とディスカバリーは主要なコンポーネントの 1 つです。 このクエリエンジンは、メタデータ、つまりあなたのデータセットに関する技術的なデータを保持しています。データがどこに存在するか、データのサイズはどのくらいか、データにどのようにアクセスできるかといったことです。これらすべてのことがここで定義されています。この情報が既に federated query に存在しているため、あなたのクエリは実際にそのデータをどのようにフェッチするかを知っています。
同様に、データアクセスとセキュリティレイヤーも備えています。このレイヤーでは、例えば、私の主要なワークロードが Amazon にあり、セカンダリなワークロード、または Google Cloud などの別のクラウドにプッシュしたいデータ分析関連のワークロードがある場合、Google Cloud と Amazon に適切なコントロールを設定する必要があります。例えば、適切なキーと証明書、API キーなど、このレイヤー内に設定することで、手動による介入を行わずに、また IT チームに権限を手動で設定してもらう依存性なしに、シームレスにデータにアクセスできます。
federated query engine の最後のレイヤー、つまり最後のコアコンポーネントは、最適化 とパフォーマンスです。これは非常に重要で、特に multi-cloud の場合はそうです。なぜなら、ネットワークを通じてデータが行き来することが多くあるからです。データがより速く、そして最も費用効果的な方法で移動できるようにするために、適切な設定が必要です。multi-cloud で federated query を有効にしたい場合、egress コストとネットワークコストを削減する必要があります。
その結果、query がこれらのコアコンポーネントを通じて移動すると、これらのコアコンポーネントは互いに連携して機能し、query の結果が得られます。Athena connector for Google BigQuery でこれを試してみることを強くお勧めします。シームレスで簡単に設定できます。
federated query の特性と、このパターンの利点を理解していただけると思います。 すべてのアーキテクチャパターンと同様に、これには独自の長所と短所があります。正しく設定されていない場合、federated query ではデータ移動が少なくなります。なぜなら、リモートソースからデータを引き出すだけで、そのソースからデータをコピーしないからです。しかし、このデータ移動の少なさは、ネットワークの観点から正しく設定されていない場合、高いレイテンシーを伴う可能性があります。Amazon と Google Cloud 間のネットワーク接続を発表したばかりなので、この新しく立ち上げられた機能を活用することを強くお勧めします。このセッション後に、ご質問があれば、この新しく立ち上げられた機能についてお話ししたいと思っている専門家がここにいます。
catalog を作成するとき、その catalog に入るメタデータには、メタデータ同期の問題が発生することがあります。例えば、別のクラウドで何かを削除した場合、プライマリクラウドでは、削除したときのテーブルの定義、または定義を変更したときの定義が、メタデータカタログで同期されていないかもしれません。federated query engine はデータが変更されたことを知りません。メタデータを同期するメカニズムがない場合、query が不正確な結果を返すか、ランタイムエラーが発生する状況に陥る可能性があります。
同じことがアクセス制御にも当てはまります。データソース間でアクセス許可が変更される場合、それらのアクセス許可セットを更新するメカニズムが必要です。認証情報を管理し、証明書をローテーションし、キーをローテーションし、キーを更新することは、複雑な場合があります。federated query アーキテクチャパターンを作成する前に、これらすべての要因を考慮する必要があります。 この時点で、AI の観点からデータ拡張についてお話しします。Don に引き継ぎます。
マルチクラウド環境における生成AI：RAG、Graph RAG、MCPサーバー、そしてLLMゲートウェイの活用
ありがとうございます。まず、ここで認識を合わせたいと思います。RAG、つまり Retrieval Augmented Generation が何かについて、すでにご存知の方も多いかもしれません。ご存知でない方のために説明すると、ステップ1でユーザーのクエリを受け取ります。実際にそのクエリのベクトル埋め込みを行って、ナレッジベースに対してセマンティック検索を実行します。コサイン距離またはユークリッド距離に基づいて類似度検索を行い、関連するドキュメントチャンクを取得します。これらをコンテキストに事実として入力でき、最終的に RAG エンジンから拡張されたプロンプトが出力されます。このディスカッションでは、その RAG エンジンを AI アプリケーション RAG エンジンと考えることができます。これが最初にお伝えしたい基本的な概念です。
次に、これがマルチクラウド環境ではどのようになるかについて話し始めたいと思います。これらのパターンについて話すときは、常にセキュリティが最優先事項であるという背景から始めたいと思います。考慮する必要があることは、セキュリティとパフォーマンス、そして先ほど述べたネットワークレイテンシーです。これらは設計の観点から考慮したいことです。これを見ると、取ることができるアプローチの1つは、CSP1 に AI アプリケーションまたは RAG エンジンがある場合、ナレッジベースを CSP2 に配置することです。データグラビティのため、必ずしもデータを移動したくない、または移動できないため、それを CSP2 に保つことができます。ただし、認識する必要がある重要な考慮事項があります。1つは、クラウド全体で使用している埋め込みモデルの一貫性です。次に、ベクトルストアがあります。必ずしも同じである必要はありませんが、高可用性システムと復元力を考えるときに、ベクトルストアをレプリケートできる機会があります。同じ CSP 上の同じベクトルストアにそのデータストアをレプリケートするか、S3 vectors のようなものをベクトル保存のコスト効率的なメカニズムとしてレプリケートすることができます。これは潜在的なソースまたは宛先の1つです。
データ移動の最小化は、フェデレーテッドクエリアプローチで使用する戦略と同様に重要です。ただし、ネットワークレイテンシーとセキュリティなどの考慮事項を考慮する必要があります。重要なことに、2つのクラウドサービスプロバイダー全体で一貫した埋め込みモデルを維持する必要があります。さらに、ベクトルストアのレプリケーションと潜在的なシャーディングを通じた復元力を考慮する必要があります。
他の追加の RAG タイプについて、いくつか説明しましょう。まず、構造化 RAG、しばしば SRAG と呼ばれるものについて説明します。この場合、以前に説明したのと同様のフローに従います。ユーザーのクエリが構造化 RAG システムに入ります。この場合、テキストから SQL への変換を実行します。現在、1つの例として、フェデレーテッドクエリエンジンを通じてアクセスできるデータベースとデータウェアハウスがあります。今日、Bedrock は、ナレッジベースが Redshift を使用した構造化 RAG をサポートしている例です。これは実装できる特定のサービスを表しています。
このシナリオでは、クエリを実行してレコードを取得します。その後、これらの結果から拡張されたプロンプトを作成します。ここには大きなメリットがあります。非構造化データに対してセマンティック検索を実行するだけでなく、エンタープライズから構造化データを取り込むことができるようになりました。また、データベース資産に対して行った投資を活用しています。このデータを必ずしも移動する必要がなく、これは M&A のようなシナリオで特に価値があり、実験を始めるための1つのメカニズムを提供します。もちろん、セキュリティ、ネットワークの信頼性、パフォーマンスは引き続き重要な考慮事項です。
もう一つの RAG パターンについてお話ししたいのですが、それが graph RAG です。このアプローチの興味深い点は、グラフ内の概念にアクセスできることで、これらの概念が異なるドキュメントチャンク間で関連付けられ、ドキュメントのスコープを超えて広がることができるということです。ホップを実行したり、関係を反復処理したり、接続をトラバースすることができます。Structured RAG と同様に、ユーザークエリが入ってきて、それをグラフクエリにアタッチします。このグラフクエリは Cypher、Gremlin、または SPARQL である可能性があり、グラフデータベースに対して実行します。AWS では、グラフデータベースとして活用できる Amazon Neptune があります。現在、これは Bedrock knowledge bases でサポートされており、Neptune をベクトルストアとして使用して Graph RAG を使用する機能を提供しています。その後、グラフを取得して、augmented prompt に移ります。
マルチクラウド graph RAG の状況で考慮すべきもう一つのシナリオは、グラフ、その概念、およびそれが含む関係です。必ずしもすべてのデータを移動する必要はありません。これは、顧客が時々 semantic layer と呼ぶものを作成することと考えることができます。異なるクラウドサービスプロバイダーに存在しないデータ間に接続組織を構築するのです。これは、データが存在する場所に残したまま、この機能を実現したい特定のユースケースにとって、本当に良い実装とパターンを表しています。主な利点には、エンティティと関係をトラバースする能力が含まれます。金融サービスのシナリオ、例えば anti-money laundering や know-your-customer チェックに適用できる関係をスパンして反復処理することを考えることができます。そこでは個人から関連する身元、銀行口座、場所、および他の接続情報をトラバースして、分析を根拠付けます。
これらのアプローチ全体で一貫性のある重要な考慮事項が残っています。同じ考慮事項が繰り返し現れる傾向があります。ネットワーク信頼性とパフォーマンスについて話すとき、そして私たちはこれを少なくとも2回言及しました、もう一度言います。マルチクラウドシナリオでは、私たちの interconnect 製品とネットワークの信頼性が重要な要因です。
そのパフォーマンスは、私たちが顧客にとって非常に重要で有益だと考えているものです。では、マルチクラウドについて少しお話しします。これを構築しました。非常に構造化された方法で、データがエージェントにとって重要であり、正確な結果を生成し、ハルシネーションを減らす能力という観点からです。
エージェントが tools を活用できるようにするための標準、非常に人気のある標準として、Model Context Protocol についてお話しします。MCP は、あなたの多くが聞いたことがあるものです。このシナリオでは、いくつかのことを想定しましょう。以前 federated query について話しました、そしていくつかのトレードオフについても話しました。しかし、トレードオフの一つであり、考慮する必要があることは、データソースが federated query でサポートされていない場合はどうするかということです。例えば、federated query を実行できる Amazon Athena に、特定のデータベースのデータコネクタがないとしましょう。そのシナリオでは、カスタムコネクタを構築するか、別の方法として MCP サーバーを検討することができます。それは tools を実装し、データソースからデータを公開できるようにします。
左側にですね、ここで少し絵を描き足していきたいと思います。 エージェントがあって、Strands をエージェント フレームワークとして使うことができます。MCP サーバーがあって、この場合は MCP サーバーを近い場所に配置しています。ローカライズして効率を最適化したい、ネットワーク境界が近い、同じパーティション内にあるという利点を活かしたいわけです。CSP 1 に関連して、MCP サーバーがあって、ここにもう 1 つあるとしましょう、MCP サーバー 2 ですね、これはデータ ストア 2 に関連しています。
MCP にはクライアントがあって、それぞれに対してクライアントがあります。ここで想像できるのは、エージェントが MCP を活用して、実際にそのデータへのアクセスをフェデレートできるようになるということです。そのツールはデータへのアクセスだけに留まりません。他のこともできますが、この文脈では本当にデータへのアクセスを得ることについて話しています。読み取りでも書き込みでも、MCP サーバーによって異なります。プロトコルを活用することで、ほぼすべてのエージェントが MCP をサポートするようになります。ですからアクセスがあって、相互運用性があって、さらにストリーム可能な HTTP トランスポートを活用しています。ここにあるものはすべて標準的で、MCP サーバーの最高のものと、多くの異なるクラウド サービス プロバイダー全体で得られる幅広いサポートを活用しています。
いくつかの課題を見ていきましょう。 データ グラビティについて話しました。これが私たちの制約であり、ここで回避しようとしているものです。データ ソースの互換性について少し話しました。もう一歩進めると、例えば、データ型のサポートに関して不一致がある可能性があります。一方が blob をサポートしていないかもしれません、例えばです。これらは、他のことを検討する必要があるかもしれないシナリオです。この場合、エージェントは関連するデータにアクセスできます。これにより、その MCP サーバーで何が起こるかについて制御できます。
利点の観点からは、 私が言及したように、標準的で広く採用されているプロトコル、ローカリティ最適化、そして私たちが呼ぶところのフェデレーテッド ツール実行と処理があります。では次に、 Bedrock の AWS でサポートされていないかもしれないモデルがあるシナリオについて話したいと思います。特定のリージョンではサポートされていないかもしれません、または容量の問題があるかもしれません。そのため、別のクラウド サービス プロバイダーでそのLLM へのアクセスを得たいのです。 ここで、マルチクラウド コンテキストで LLM ゲートウェイとルーターがどのように役立つかについての概念を導入しています。この LLM ゲートウェイとルーターは、実際に入力側、リクエスト側で標準的な統一インターフェースを提供するつもりです。一般的に、OpenAI が標準として見られます。LiteLLM と Agent Core ゲートウェイもあります。ですから、ここで活用できるいくつかの異なるシナリオとものがあります。それらはサービスです。
エージェントが実際に異なる LLM と異なるモデル と通信して活用しており、それらは異なるクラウド サービス プロバイダーで実行されています。私が言及したように、これらが駆動要因です。モデル選択、可用性、容量が重要な考慮事項です。1 つが利用できない場合、様々な LLM に対してラウンド ロビン することもできます。スロットリングと他のメカニズムを使って、別の LLM にリクエストを送ることができます。これらがその特定のプロトコルの主な利点です。
統一されたリクエストフォーマット仕様に対して1つの統一された書き込みを持っていて、その後、それを翻訳してもらっています。優先順位付けとルーティングを行っているので、このゲートウェイで実現できる他のことの1つは、どの程度の機能をそこに入れたいかによって、コストベースのルーティングを導入することです。コストとリクエストに基づいて、異なる機能と能力に基づいて、それを別々にルーティングすることができます。その後、先ほど述べたように、動的ロードバランシングがあります。
全体像をまとめると、LLM gateway router と MCP クライアント・ツー・サーバー通信（前のスライドで説明した ）の両方が、すべてエージェントによって利用されることができます。次のステップとリソースについて、いくつかお話しします。利用可能なセッションは多数あります。マルチクラウドの観点からのベストプラクティスから始まるワンオンワンセッションがあります。また、より深掘りしたセッションもあります。今日は200レベルの会話ですが、生成AIとエージェンティックAIに関して、今ちょうど説明した内容についてさらに詳しく掘り下げる300レベルのセッションがあります。
セキュリティのベストプラクティスとネットワークのベストプラクティスのセッションもあります。エキスポホールにキオスク があり、訪問することができます。デモとユースケースの深掘りがあり、皆さんとの会話をすることができます。マルチクラウドプログラムの一環として、皆さんのようなお客様とマルチクラウド戦略についてお話しする時間を多く費やしているので、アカウントチームを通じて皆さんと関わることができて嬉しいです。お気軽にお問い合わせください。ご質問があれば、廊下でお答えする準備ができています。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion