※本記事は、2026年3月12日にアイルランドのキルケニーにあるLyrath Convention Centreで開催された第5回AWS AI and Data Conference 2026にて収録された、AWSによるセッション「Building an AI-Ready Data Foundation」の内容を基に作成されています。本セッションでは、最新の生成AIおよびエージェンティックなワークフローが十分に機能するためには、その土台となるデータプラットフォームが安全で、強固で、コンプライアンスに準拠している必要があるという観点から、ハードウェア、推論、データプラットフォーム、ツールに至るAWSのサービスがいかに一体となってお客さまのジャーニーを可能にするかが語られています。登壇者は、AWSのPrincipal PMT-ESであるVinay Kumar氏、AWSのPrincipal Analytics SA LeaderであるImtiaz (Taz) Sayed氏、ならびにパートナーであるTines社のSusan氏です。本記事では、セッションの内容を要約しております。なお、本記事の内容は原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご覧いただくことをお勧めいたします。AWSのイベントの詳細情報は https://go.aws/events でご覧いただけます。
1. オープニング：エージェント時代のビルダーの変化
1.1 セッションとスピーカーの紹介、エンドツーエンドの視点
Vinay： 皆さん、おはようございます。本セッションへようこそ。本日は、皆さまのようなパートナーやお客さまが、AIに対応したエージェントとデータの基盤をどのように構築していけるのか、私たちがどう取り組み、どう支援しているのかをお話しします。ここで強調したいのは、私たちが単にデータだけを切り取って見ているのではない、ということです。インフラストラクチャから始まって、どのようにエージェントを構築し、どのようにデプロイし、さらに新しく登場しつつあるコーディングフレームワークとどう連携していくのか、その全体像をエンドツーエンドの視点で捉えています。
Vinay： 私はVinay Kumarと申します。データおよびAIサービスの戦略的エンゲージメントを担当しています。本日は2人の共同スピーカーと一緒に進めます。1人はTazで、アナリティクス領域のテックリーダーであり、ソリューションアーキテクトのリーダーを務めています。もう1人は、私たちのパートナーであるTines社のSusanです。彼女からは、Tinesがお客さまに提供している、AWSを基盤としたAIプラットフォームについてお話しいただきます。
1.2 ビルダーの定義と開発速度の変化、「アイデアの速度で構築する」概念
Vinay： 世界が変わりつつある中で、エージェントはますます身近な存在になっています。私たちが見据えているのは、人間が担ってきた多くのタスクをエージェントが次々と引き受けていく、そう遠くない未来です。そこでは人間はむしろ、それらのエージェントを生み出し、タスクを遂行するよう方向づけることに、より多くの時間を割くようになります。この変化は、2つの根本的な意味でゲームチェンジャーだと考えています。
Vinay： 1つ目は、「誰がビルダーなのか」という問いです。正直なところ、私自身はキャリアの最初の4か月のインターンを除けば、人生で一度もコードを書いたことがありません。それでも今は、こうしたエージェントを使えば、背後にある言語の構文も、APIも、基盤となるインフラも理解することなく、コードを生み出すことができます。これは、私たちが今日テクノロジーと関わる方法そのものにおける、大きな変化です。
Vinay： 2つ目は、構築のスピードです。エージェントによって、これまで数週間から数年を要していた開発が、開発するものにもよりますが、数日から数週間にまで短縮されるようになりました。これ自体が大きな変化であり、そこから生まれてくるのが、本質的に「アイデアの速度で構築する」という概念です。ビジネス要件を持ち寄り、自然言語でエージェントと対話を始めれば、エージェントが、求めている成果のためのアプリケーションを組み上げてくれる。そういう時代になりました。それでは、共同スピーカーのSusanを壇上にお招きしたいと思います。彼女からは、TinesがパートナーとしてどのようにAWSのテクノロジーを活用し、AIにおける選択肢を提供するプラットフォームを実現しているのかをお話しいただきます。ありがとうございました。
2. Tinesのプラットフォームとセキュリティ・選択の哲学
2.1 Tinesの紹介とインテリジェント・ワークフロー・プラットフォーム
Susan： Vinay、ありがとうございます。そして皆さま、本日はこの場にお招きいただき、ありがとうございます。まずは基本の基本からお話しさせてください。私は誰なのか、Tinesとはどんな会社なのか、そしてなぜ私がここに立っているのか。何より大切なこととして、私たちTinesは、お客さまにとって最も重要なワークフローを実現することに誇りを持っているテクノロジー企業です。
Susan： Tinesは2018年に、2人のアイルランド人セキュリティ実務者によって設立されました。アイルランドは私たちの母国であり、そのことを非常に誇りに思っています。同時に、あらゆる規模のお客さまと信頼関係を築き、パートナーになれたことも誇りです。会社のライフサイクルを通じて、10億ドルを超える資金調達も実現してきました。
Susan： では、なぜお客さまは私たちを利用し、なぜ投資家は私たちを信じてくれるのか。それは、私たちが「インテリジェント・ワークフロー・プラットフォーム」と呼ぶものを提供しているからです。私たちにとってこれは、決定論的なワークフローを構築し、必要なデータポイントと連携して正しい文脈を得るだけにとどまらず、その上にAIを適用できるようにすることを意味します。これによって、非常に高い複雑性を持つワークフローから、連邦政府のお客さま向けにゼロトラスト環境で動作するワークフローまで構築できるようになります。その結果、私たちはTinesプラットフォーム上で週次10億件のアクションを処理する規模にまで成長してきました。
2.2 ワークフローの進化とエージェンティックAIによるグレーゾーンの処理
Susan： 私はワークフローやプラットフォームについて繰り返し話していますが、では「プラットフォーム」とは実際に何を意味するのでしょうか。私たちにとってそれは、あらゆる種類のワークフローを支えられるということです。最初に存在したワークフローという言葉を思い浮かべてみてください。それは、目の前に1枚の紙を置いた人間が、「AをしてB、C、Dをやりなさい」と指示される、というものでした。すべてはそこから始まりました。
Susan： その世界では、人間が完全に主導権を握っていました。人間は目の前のすべての情報を取り込み、何が本当に起きているのかを理解し、判断を下すことに長けています。ただ、人間はどうしても遅い。一方で遅くないのは、決定論的なワークフローを組み、同じやり方で処理を回せる場合です。AをしてB、Cをする。大量にこなす必要があるタスクには最適です。コンプライアンスチームはこの種のワークフローを好みます。予測可能だからです。ただし、これは非常に白黒がはっきりしていて、期待した形の応答が返ってこないと、システムは「どこへ進めばいいか分からない」とお手上げになり、最終的にはエラーメッセージを受け取った人間が対処することになります。
Susan： 生成AIと大規模言語モデルの登場によって、私たちはこのギャップを埋め、エージェンティックAIへと進めるようになりました。物事が白でも黒でもなく、グレーであるとき、エージェンティックAIはそのグレーな領域を扱うことに長けています。期待どおりの応答が得られなかったとしても、では何が返ってきたのか、それは何を意味しうるのか、追加の文脈が必要か、与えられたツールを使って別のツールに問い合わせ、色を塗り足してもう少し白黒に近づけられないか、と考えていきます。そして、もしそれが非常に明快で、エージェントが取っても安全なアクションであれば、エージェント自身がそれを実行します。そうでなければ、最も重要な場所、つまり人間に立ち返り、人間に判断を委ねるのです。私たちはこれらすべてを1つにまとめています。
2.3 Private and Secure by DesignとAWS Bedrock・PrivateLink
Susan： 理論上は、これは本当に素晴らしく聞こえます。ただ、私たちが最初にプラットフォームへAIを導入し始めたとき、一部のお客さまは胸を躍らせてくれましたが、それ以上に多くのお客さまは少し怖がっていました。私たちはセキュリティチームやSecOpsチームと多く仕事をしています。彼らは「AIに渡すとはどういうことだ。それはどこへ行くのか。誰に食わせるのか。一体ここで何が起きているんだ」と反応しました。
Susan： ですから私たちは初日から、Tines内でAIに関して行うことはすべて、設計段階から私的かつ安全である(private and secure by design)と決めていました。その方針が、AWS Bedrockとのパートナーシップにつながりました。Bedrockは、私たちが全お客さまに提供するデフォルトのモデルです。とはいえ、それを押し付けるわけではありません。お客さまは引き続き自分自身のモデルを持ち込めますし、実際多くの方が自分のAWS Bedrockモデルを持ち込み、それを接続しています。ただ、私たちの側にAWS Bedrockがあること、そしてAWS PrivateLinkと組み合わせることで、完全に安全な環境を作り出せます。だからこそ私たちは、完全な自信と信頼をもってお客さまに、「Tinesプラットフォーム内で行うことはすべて、完全にテナントスコープに閉じている」と言えるのです。それは私的で、ステートレスで、決してそのリージョンの外には出ていきません。私たちは欧州の企業であり、他の多くの欧州企業も私たちのもとを訪れ、「それは素晴らしい代替案だが、自分のデータが、あなたが言うそのリージョンから出ていくのは困る」と言います。AWSとのパートナーシップを通じて、私たちはそれを保証できます。
Susan： お客さまには、学習(training)もなく、保存もなく、ログも残らないと伝えられます。特にサイバーセキュリティにおける学習に関しては、「エージェントをどこまで学習可能にしたいのか」という問いがあります。それは潜在的な責任(liability)になりうるのか、それとも、より良いものにしうるのか。私たちはまだ、その答えをすべて持っているわけではないと思っています。ですからTinesとしては、非常に明確に、AWSとパートナーを組むと決めました。これは絶対的に安全な基盤になります。もしお客さまがさらに踏み込んだことをしたいのであれば、AWS Bedrock経由、あるいは既存の他のモデルを通じて、引き続きその柔軟性が確保されています。ただ、私たちが標準で提供するものは、私的でセキュアであることを第一に据えます。
2.4 「選択肢」によるコスト最適化とTinesの立ち位置
Susan： これは間違いなく、スライディングスケール、つまり度合いの問題です。ワークフローについて語るとき、すべてがエージェンティックになるわけではありませんし、エージェンティックに動く部分の一部は、純粋に決定論的なワークフローによって支えられています。データソースに行き、必要な文脈をすべて取り込む。そのためにエージェントは要りません。エージェントは素晴らしいものですが、依然としてクレジットを消費します。モデルが異なれば、消費するコストも異なります。AWS Bedrockには非常に強力で高性能なモデルがありますが、では、あらゆるタスクにそれを使いたいか。おそらく違います。私が望むのは、何のタスクをしているか、どこへ向かい、何を使っているかに応じて選べる世界です。そうした非常に高度なモデルは、本当に必要なところに温存しておく。そここそが、お金を有効に使える場所だからです。一方で、エージェンティックAIをまったく使わず、クレジットを一切消費しない部分もありますし、その中間として、使うことに大きな意味がある場合にだけ実行する、という領域もあります。
Susan： ですから、Tinesにとって突き詰めると、私たちはお客さまに、今お話ししたような心配事のすべてを気にしなくてよい選択肢を提供したいのです。代わりにお渡しするのは、最終的な成果物、すなわちAIエージェントそのものです。お客さまはそこに行って文脈を引き込み、モデルを選び、エージェントが仕事をし、必要に応じて他の決定論的ワークフローも活用できます。私たちはいつも「ええ、もちろんすべてはAWS Bedrock上で動いています」と言いますが、最終的な結果として、お客さまはそれを気にする必要がありません。私たちが代わりにやります。パートナーとの強固なパートナーシップがあるからです。
Susan： 私たちがTinesとして、AIのエコシステムをどう捉えているかという原則について言えば、私たちは常に「自分たちが根本的なAIプロバイダーになることは決してない」と言っています。それは私たちの領域ではありません。それをはるかに上手にできる人たちがいて、さまざまなモデルがあり、膨大な複雑さがあります。ですから私たちは、市場に何があるのか、その複雑さを肩代わりしてくれる相手と誰と組めるのかを見極め、自分たちが最も得意とすることに集中できるようにしました。どうすればそれらのワークフローを実現できるのか、エージェントが最善の形で仕事をするにはどんな文脈が必要なのか、というところです。とはいえ、エージェントがどこで使われ、どこで力を発揮するかを語るとき、正直なところ、日によってはまだ少し物足りなさを感じます。「アラートを要約できます、メールを要約できます、素晴らしいでしょう」と言っている段階です。けれども私たちは、そこから次の一歩を踏み出し、私たちが「面倒な雑務(muck work)」と呼ぶものを実際にエージェントに担わせ、人間が本当にやりたい仕事に取り組めるようにしたいのです。それでは、Vinayにお返しします。ご清聴ありがとうございました。
3. エージェンティックAIジャーニーの4要素とインフラ・推論
3.1 技術はビジネス成果に従うべきという原則と4つの必須要素
Vinay： Susan、ありがとうございました。今のお話にもあったとおり、選択肢というのは非常に大きなテーマです。皆さまは、使うテクノロジーを、自分たちが目指すビジネス成果に合わせられるべきです。テクノロジーがビジネス成果を駆動するのではなく、ビジネス成果がテクノロジーを駆動すべきなのです。手元にあるテクノロジーによって、組織が達成しようとしていることを妥協させられるようなことがあってはなりません。これこそが、私たちがエージェントへと話を広げていくうえでの本質です。
Vinay： そこで問いになるのが、このエージェンティックAIのジャーニーを進むうえで、どうすればこれらのエージェントを機能させられるのか、ということです。これらのエージェントを構築し、訓練し、デプロイし、そのライフサイクルを管理するには、何が必要なのか。そのジャーニーを皆さまと一緒にたどり、Tinesのようなパートナーがどのように取り組み、この上に何を築いているのかを見ていきましょう。それは同時に、皆さまが目指す成果を実現する助けにもなるはずです。
Vinay： このジャーニーを進むうえで、必須となる構成要素は4つあります。1つ目はインフラストラクチャです。モデルを構築・訓練し、適切な価格性能で大規模にデプロイするためには、正しいAIインフラを備えていることが決定的に重要です。2つ目は推論(inference)です。3つ目はデータです。信頼でき、安全なデータ基盤がなければ、正しいAIの成果を得ることはできません。データこそが、これらのモデルの成果を駆動します。汎用的なデータではなく、皆さま自身のデータで訓練されてこそ、ビジネス成果につながるのです。そして最後の4つ目は、それらをどう構築し、スケーラブルにデプロイする仕組みを提供するか、です。エージェントがスケールしていくにつれて、何十万ものエージェントがデプロイされることになります。それらは、何をするかという点で人間よりも自律的に動きますから、追跡していく必要があります。その体験を、いかに安全で、スケーラブルで、信頼できるものにするか、ということです。
3.2 AIインフラ、Bedrockによる推論、データ基盤の重要性
Vinay： まずはAIインフラから始めましょう。AIインフラは、堅牢で、スケーラブルで、高い性能を備えている必要があります。私たちは常に選択肢を信条としてきました。だからこそ、NVIDIAのインフラを動かすうえで、私たちは群を抜いて最良のプラットフォームです。その一環として、私たちは継続的にイノベーションを重ねており、re:Inventでは、NVIDIAの最新のP6インスタンスを発表しました。これはGB300 NVL72システムをベースとしており、AIにおいて最も高性能なワークロードをデプロイできるものです。
Vinay： 加えて、私たちはネイティブな独自インフラプラットフォームであるTrainiumも提供しています。皆さまはご存じないかもしれませんが、実は大多数の方がすでにTrainiumを使っています。なぜなら、私たちが行うBedrockの学習の大部分は、Trainium上で実行されているからです。そしてre:Inventでは、Trainium 3サーバーを発表しました。これは、AIワークロードに対して最良の価格性能とスケーラビリティを提供します。
Vinay： 次に推論です。これらのモデルを開発し訓練していく中で、推論は、環境内のあらゆるアプリケーションを作り変えていくうえでの能力そのものになります。そのためには、正しいプラットフォームを持てることが必要です。私たちは、皆さまにとっての正しいLLM、正しいモデルという選択肢も信条としています。なぜなら、皆さまのモデルはビジネス要件に合致すべきであって、ビジネス要件のほうがモデルの選択肢に縛られるべきではないからです。だからこそ私たちはBedrockを作りました。Bedrockは、モデルの選択肢を提供するプラットフォームです。必要なモデルを選び、要件に合わせてカスタマイズし、自分自身のデータで訓練し、自分のデータと統合できます。ガードレールとセキュリティがシステムにあらかじめ組み込まれた状態で提供され、エージェントの運用・統合・実行を可能にします。私たちはこの領域でも継続的にイノベーションを重ねており、昨年はBedrockで利用できるモデルの数を倍以上に増やしました。GoogleやNVIDIAの新しいモデルもその中に含まれています。
Vinay： そして、エージェンティックな成果へと進むにつれて、最も重要になってくる要素が、データです。なぜなら、モデルに正しいデータを与えなければ、POCや初期のテストはうまくいったとしても、本番環境にデプロイする段階になると、その成果が、皆さまの持つビジネス目標と合致しなくなるからです。だからこそ、正しいエージェンティックなデータ基盤を持つことが決定的に重要なのです。モデルがますます普及していくにつれて、私たちが目にすることになるのは、モデルの大幅な増殖です。本日のキーノートでもご覧いただいたとおり、私たちは、1,000倍のコード、1,000倍のモデルが生まれると見込んでいます。それはつまり、皆さまが管理しなければならないデータの量も膨大になるということです。だからこそ、目指す成果を駆動するために、正しいエージェンティックデータ基盤を築くことが不可欠なのです。それでは、Tazに壇上に加わってもらい、私たちがどのようにエージェンティックを実現しているのか、その深掘りへと聴衆の皆さまをご案内しましょう。
4. エージェンティックAIアプリケーションの挙動とコンテキスト管理
4.1 ReActループの挙動とLLMの限界
Taz： ありがとう、Vinay。皆さま、おはようございます、そしてこんにちは。少しセットアップが難しいですね。画面に影が落ちているのに気づいたので、ここに身を固定しておきます。どのみち私の姿を見る必要はありません。声さえ聞こえれば大丈夫です。では始めましょう。疑いようもなく、エージェントはLLMから強力な推論能力を継承します。けれども、ここが肝心なのですが、エージェントは、皆さまが与えるデータの賢さの分だけしか賢くなれません。さらに言えば、データに関連する特定のエージェンティックな振る舞いを効率的に管理しなければ、コストと性能に実際の悪影響が生じます。そこを、AWS上でどう実現できるのか、少し深く掘り下げていきます。
Taz： ここでは、エージェンティックAIアプリケーションを簡略化した象徴的なリファレンスアーキテクチャを使って、コストと性能への打撃をどう緩和するかをお見せします。ここにあるのは、1つのエージェントとLLMが、MCPクライアントとサーバーを使って、外部とローカルの両方を含むさまざまな種類のデータソースからデータを統合している構成です。これを分解してみましょう。この象徴的なアーキテクチャの裏側に回り込むと、一般に「エージェンティックループ」あるいは「ReActループ」と呼ばれる振る舞いが観察できます。エージェントがMCPのAPI呼び出しを実行し、その結果をエージェントに返す。エージェントはその結果を受け取ってモデルに渡し、モデルはその結果を推論・解釈して、最終的な応答を返します。
Taz： 理想的にはそうあるべきなのですが、現実はそう簡単ではありません。ここをもう少し深く掘り下げます。実際に起きているのは、ユーザーがアプリケーションにタスクの完了を指示すると、ワークフローがループに入り、タスクが完了した、あるいは質問に答えられたとみなされるまで反復し続ける、ということです。この設計パターンはReAct、つまりreason（推論）plus act（行動）ループと呼ばれ、エージェンティックAIアプリケーションを構築する際の最も人気のある設計パターンの1つです。この基本アーキテクチャによって、AIエージェントやアプリケーションは、複数のループや反復を通じてタスクを成し遂げられます。ただ、よく聞いてください。これは、予測不可能な回数のモデル呼び出しへとつながり、制御不能な量の入力トークンと出力トークンを消費することになります。これがコストと性能の両方に影響します。驚くことではないですよね。では、良いデータ基盤がこの影響をどう最小化し、緩和できるのかを見ていきましょう。
Taz： 先ほど申し上げたとおり、AIエージェントはLLMから高度な推論能力を得ますが、2つの重要な制約に直面します。1つ目は、LLMはステートレスであり、過去のやり取りや情報を一切記憶できず、文脈を保持できないということです。2つ目は、有限の、つまり限られたコンテキストウィンドウしか持たず、各ステップで処理できるデータの量がごくわずかだということです。このコンテキストウィンドウが保持する必要のあるデータには、ユーザープロンプトやシステムプロンプトといった指示のほか、セッション状態、履歴、ユーザープロファイル、会話履歴などが含まれます。そして、先ほど触れたReActループを考え合わせると、このデータ量がいかに急速に膨らみうるか、想像がつくと思います。
4.2 エージェンティックメモリとナレッジベース・ベクトルストア
Taz： このコンテキストウィンドウという作業メモリは、1回のセッションの中である時点でモデルが考慮し、記憶できる最大の情報量、つまり入力データの量を指し、トークンで測られます。そして、ここが核心であり、オチでもあるのですが、コンテキストウィンドウは有限であり、トークンは高価です。AWSは、この限られた高価なコンテキストウィンドウを管理する方法をいくつも提供しています。
Taz： まずはエージェンティックメモリから始めましょう。もし皆さまの組織やチームが、必要なものをひとそろい提供してくれる、既製の(over-the-shelf)サービスやソリューションを好むタイプであれば、AWSの推奨はAmazon Bedrock AgentCoreです。これは、エージェントを本番に持っていくために必要なものすべてをそろえた、モジュラーなサービス群です。これを使えば、やり取りをまたいでエージェントの知識を維持する永続的なメモリによって、パーソナライズされた体験を素早く提供できます。一方で、エージェンティックアプリケーションの性質によっては、つまり、より複雑で、よりカスタムなものを構築する必要があるビジネスユースケースや事業者であれば、AWSにはエージェントが文脈のためのメモリを構築するのに使える選択肢が他にもいくつもあります。たとえば、インメモリの高性能キーバリューデータストアであるElastiCache for Valkey、分散NoSQLデータベースであるDynamoDB、知識グラフの動的な関係性を扱うNeptune Analyticsなどです。このようにして、エージェントは知識を保持し、問題を解決し、文脈を踏まえたインテリジェンスを提供できるのです。
Taz： コンテキスト管理に話を戻すと、その次に重要な要素がナレッジベースです。ここでは非構造化データが前面に出てきます。たとえば、非構造化のファイルとして存在している自社のポリシー文書を使い、Amazon S3上にナレッジベースを構築し、Amazon OpenSearchをベクトルストアとして用いてセマンティック検索を行い、意思決定を担うエージェントに正しいポリシーを適用させる、といったことができます。AWSでは、Knowledge Bases for Amazon Bedrockというサービスを使えます。これはエンドツーエンドのRAGワークフローを管理してくれます。やることは、データの場所を指定し、データをベクトル埋め込みに変換する埋め込みモデルを選ぶだけで、あとはAmazon BedrockがAmazon OpenSearch Serverless上にベクトルストアのナレッジベースを作成してくれます。エージェントはそこから文脈を取得し、それをLLMのコンテキストウィンドウに追加して、モデルがその情報をもとに推論し、行動できるようにします。
Taz： 次に、エージェンティックメモリと同様に、ベクトルストアについてもAWSには選択肢があります。ユースケースやビジネスモデル、複雑さ、必要なカスタマイズの度合いに応じて、AIアプリケーション向けにベクトルストアをデプロイする追加の選択肢があるということです。その1つがAmazon OpenSearchで、ベクトル埋め込みに基づいて非常に関連性が高く文脈に即した結果を提供し、セマンティック検索、ハイブリッド検索、類似検索を活用したAIアプリケーションを構築できます。最近私たちは、OpenSearchのベクトルエンジン向けにGPUアクセラレーションの一般提供を発表しました。ベクトル検索の計算をGPUにオフロードすることで、OpenSearchは速度面で10倍以上を達成しつつコストでも優位に立てます。これは、RAG（検索拡張生成）のアプローチを使うアプリケーションやレコメンデーションシステムにとって非常に有用です。同様にre:Inventでは、Amazon S3 Vectorsの一般提供も発表しました。これは、Amazon S3のスケールとコスト効率をベクトルにもたらすもので、お客さまは数兆のベクトルをコスト効率よく保存し、高速でインタラクティブなクエリを実行できます。
4.3 MCPサーバーの適材適所
Taz： コンテキスト管理に戻ると、次の要素はMCPサーバーです。ここで申し上げておきたいのは、MCPサーバーは常に万能の解(one-size-fits-all)ではない、ということです。従来のAPIのほうが向いている処理もあります。たとえば、MCP駆動のエージェントは、大量のデータを持ち帰ってくるような場面や、多くのカスタム変換を行うような場面とは、あまり相性がよくありません。同様に、決定論的、あるいは時間的にシビアな応答が求められるトランザクションについては、従来のAPI呼び出しのほうがうまく対応できます。
Taz： とはいえ、その一方で、MCPサーバーは、複数のAPIのSDKやフォーマットを管理するという重労働を肩代わりしてくれます。正直なところ、それは本番運用において典型的な悪夢です。ですから、状況に応じて毒を選ぶ、というわけです。MCPサーバーは、APIをLLMにとって扱いやすくする会話レイヤーを加え、異なるAIモデルやツールの間でカスタムな統合を必要としなくする、いわば共通言語として機能します。MCPは、従来のAPIよりも文脈効率が高く、冗長性が低くなるように設計されています。だからこそ私たちは、データおよびアナリティクスのサービス向けにMCPサーバーを構築しました。RedshiftやAuroraのMCPサーバーもその一例で、自然言語のリクエストをAPI呼び出しに変換することで、開発体験を加速させます。データベース、スキーマ、テーブル、カラムを探索し、読み取り専用モードでSQLクエリを実行できるため、安全性が組み込みで確保されています。さて、AWS上でデータに関連するエージェンティックな振る舞いを緩和するのに役立つ、いくつかのデータ基盤の構成要素を見てきましたので、ここで再びVinayを招き、エージェンティックAIのためにどうデータを「効率的(effortless)」にするのかを語ってもらいましょう。
5. データを効率化するSageMakerとカタログ・フェデレーション
5.1 共有データアーキテクチャと次世代SageMaker
Vinay： Taz、ありがとう。お聞きいただいたとおり、私たちが貫いているテーマは、アナリティクスであれ、データであれ、エージェンティックであれ、皆さまが成果のために正しいツール、正しいテクノロジーを選べる「選択肢」だということです。さて、エージェンティックがもたらす俊敏性とスピードにおいて、重要な点の1つは、皆さまが何かを構築し、デプロイし、それを動かすという本来のタスクに集中できるよう、いかに私たちが支援できるか、ということです。その成果にたどり着くまでの基盤となるインフラに時間を費やすのではなく、です。データへの洞察をどう提供するか、オペレーショナルデータや分析データをどう管理するか、そしてそこからどう価値を引き出すかという点で、皆さまの日々の営みをいかに「効率的(effortless)」にできるか。私たちが進めているイノベーションのいくつかをご紹介しましょう。私たちは、データの管理の仕方に効率性をもたらし、皆さまがお客さまや組織のために築こうとしている成果に、より集中できるようにしています。
Vinay： それを実現するうえで鍵となる側面の1つが、人間と、機械あるいはエージェントの双方が等しく活用できるデータアーキテクチャです。このジャーニーを進む中で、異なるコンポーネントや異なる概念を抱え込む必要がないようにする、ということです。これは、私たちが提供するデータベースとアナリティクスにまたがる共有アーキテクチャであり、皆さまは自分のデータがどこにあるのかを気にする必要がありません。私たちの目的は、皆さまが持つデータへの統一されたビューを提供し、その上に文脈を築き、その上にインテリジェンスを提供することです。そうして整えられたものを、アナリティクスサービスが洞察を届けるために活用し、AIサービスが期待される成果を出すために活用できるようにするのです。
Vinay： 私たちはそのジャーニーを2年前に始めました。次世代のSageMakerであるAmazon SageMakerを立ち上げたときです。それ以前は、特定の成果に対して最良の価格性能を提供する複数のサービスが個別に存在していました。Amazon SageMakerを立ち上げたとき、私たちの基本的な考え方は、それらのサービスを1つにまとめ、データへの統一されたビュー、カタログへのビュー、そして成果へのビューを得るための、非常にシンプルなインターフェースと仕組みを提供することでした。これには主要な構成要素が3つあります。1つ目は、どう消費し、どう体験を築くか、という部分です。データエンジニアリングであれ、クエリであれ、お客さま向けの没入的な体験の構築であれ、モデルの構築・訓練であれ、私たちがSageMaker Unified Studioと呼ぶ単一の統一インターフェースが、これらすべての体験にまたがって、チームに同じ体験を提供します。
Vinay： 2つ目として、私たちはそのSageMaker Unified Studioの中にビジネスカタログを組み込みました。これは、皆さまの技術的な情報や技術的なデータを翻訳し、セマンティクスを構築して文脈を適用し、それらをビジネス用語へと変換します。そうすることで、AIアプリケーションやエージェントがデータにアクセスする際に、文脈を踏まえた認識を持ち、皆さまが求める成果へと効率的に変換できるようになります。そして3つ目、最後になりますが重要なのが、すべてのデータを1つにまとめるレイクハウスアーキテクチャです。これは、データソースが何であれ単一のビューを提供します。なぜなら私たちは、皆さまのデータソースがRedshiftやS3といったAWSのデータウェアハウスだけに限られないことを十分に承知しているからです。
Vinay： さらに昨年のre:Inventでは、その体験を、プロビジョニング不要のノートブック体験を提供することで強化しました。SQLの分析を始められるうえに、自然言語インターフェースを使って対話を始められます。もちろん、従来からのコーディング機能やその豊かさもすべて備えたうえで、です。そして、組み込みのAIアシスタントが付いており、アナリティクスやモデルの開発・訓練に使えます。目的を自然言語で説明するだけで、それがタスクをこなしてくれます。このエージェントは、次のスライドでお話しするカタログに保存されたメタデータを使って、皆さまに文脈を踏まえた認識を与えてくれるのです。
5.2 SageMaker Catalogとフェデレーテッドカタログ
Vinay： そこで次に、SageMaker Catalogによってこの体験をさらに強化しました。これはSageMaker Unified Studioに含まれており、そのためのライセンス料を支払う必要はありません。支払うのはAPI呼び出しの分だけです。そして、これは単なるデータカタログではありません。私たちがSageMaker Catalogと呼ぶこのカタログは、データをカタログ化するだけでなく、AIアプリケーションをカタログ化し、機械学習モデルをカタログ化し、さらにはコンピュートまでカタログ化します。つまり、アプリケーションからデータに至るまで、皆さまのデータ資産全体を統一的に見渡せるビューなのです。皆さまは、すべてのデータ、AIモデル、機械学習モデルを、組織やグループ、手持ちのリソースと容易に共有できます。SageMaker Catalogを使えば、技術的なデータに対してAI駆動でビジネス上の文脈を自動生成できます。さらにデータ品質のような機能を備えることで、データ品質を保証できるだけでなく、データ品質まわりの問題が起きたときにトラブルシューティングを行うこともできます。そして最後に、皆さまの技術カタログをGlue Data CatalogからSageMaker Catalogへシームレスにオンボーディングできるよう、私たちは引き続き取り組みを進めています。
Vinay： このカタログの進化形として、私たちは、皆さまが組織内のアナリティクスのために複数のソリューションを使っているという現実を認識しています。AWSのエンジンを使っているかもしれませんし、SnowflakeやDatabricksといった私たちのパートナーのところにデータが置かれているかもしれませんし、その他のサードパーティソリューションを使っているかもしれません。そこで、今年私たちが立ち上げたイノベーションの1つが、フェデレーテッドカタログ(federated catalog)です。これによって、異なるカタログ、つまりIceberg対応のカタログをまたいで、データをその場に置いたまま(data-in-place)クエリできるようになりました。Databricks由来であれ、Snowflake由来であれ、あるいはIceberg対応であればどんなサードパーティのカタログであれ、です。これにより、エンジンとデータのどちらに着目するかに応じて、コストを適正化できるようになりました。たとえば、あるお客さまからは、データが特定のカタログにあるために、そのアプリケーションを使わざるを得ないが、それが高くつく、というフィードバックをいただいていました。ですが今やこのソリューションによって、AWSのアナリティクスエンジンを使うことも、Iceberg互換でありさえすればオープンソースのアナリティクスエンジンを使うこともでき、それでいて、データ資産全体にあるデータにアクセスできるのです。
5.3 レイクハウスによる真のデータ統一とZero-ETL
Vinay： さらに先へ進むと、レイクハウスアーキテクチャが、私たちのデータの統一を可能にします。これがまた私たちの持つもう1つの強みでもあるのですが、それは私たちがSageMakerの一部として、オープンなデータテーブルフォーマットとしてIcebergを採用したからです。これにより、複数のサードパーティのデータソースからデータを取り込めます。今日時点で、私たちは最大16のデータソースをサポートしています。その例として挙げられるのが、Salesforce、HubSpot、Adobe、Google BigQuery、そしてSAPです。これらは、皆さまがお持ちの最も一般的なデータソースの一部です。私たちはこの点でもイノベーションを続け、より多くのデータソースを追加し続けています。これによって、データの配置でも、性能でも、コストでも妥協する必要がありません。性能を心配することなくデータにアクセスできる、その両立が実現します。なぜなら、私たちがバックエンドでそれを自動化するからです。データをレイクハウスアーキテクチャに利用可能にしているのは、AWSのインフラであり、AWSの自動化なのです。
Vinay： では、皆さまのオペレーショナルデータはどうでしょうか。データベースに格納されたオペレーショナルデータは、皆さまが持つデータの大半を占めています。それはまた、最も重要なデータでもあります。なぜなら、皆さまのビジネスオペレーションが、そのデータの上で動いているからです。それなのに、データへの洞察を求めるときや、AIの成果を築くためにモデルを訓練するときに、なぜそれを除外してしまうのでしょうか。私たちが目にする実態として、このデータは、オンプレミスのSQLやOracle、その他のオープンソースデータベースに格納されていることもあれば、サードパーティのクラウドにあることも、私たちAWSのデータベースのいずれかにあることもあります。データがどこに格納されていようと、私たちは今や、データベースからレイクハウスアーキテクチャへのZero-ETL統合を、シームレスな形でサポートしています。ですから、オンプレミスのどこかにOracleデータベースがあり、AWSでAuroraを動かし、さらにGoogleやMicrosoftでデータベースを動かしている、といったことを心配する必要はありません。私たちが、それらのデータのビューをレイクハウスアーキテクチャへと自動的に取り込む作業を担います。これこそが、私たちが「真のデータ統一」と呼ぶものです。異なるソースから移行することなく、モデルを訓練しながらデータへのビューを保ち続けられるのです。
6. エージェント時代のデータベース・構築・デプロイとクロージング
6.1 即時性を求める時代のデータベースと消費モデル
Vinay： データベースの話を広げていくと、エージェンティックなジャーニーを進むうえで重要な側面の1つが、俊敏性と実行のスピードです。これまでは、作成したり接続したりするのに数分、あるいは数時間かかるデータベースがありました。その前には人間が座っていたので、それを許容する仕組みが成り立っていたわけです。けれども、エージェントがますます身近な存在になるにつれて、データベースは即座に利用可能であり、エージェントがタスクを遂行するためにすぐ使える状態であることが期待されるようになります。
Vinay： その一環として、DynamoDBを使えば、データベースの作成を始めてから数秒のうちにテーブルを作り始められます。昨年私たちは、active-activeの分散型でPostgresベースのSQLデータベースであるDSQLを発表しました。これはマルチリージョンに対応し、ファイブナイン、つまり99.999%の可用性を提供します。当初、私たちはデータ作成時間を2分未満で始めました。ですが、これはエージェンティックなエコシステムにとって最適とは言えないと考えました。そこで私たちはそれを、同じく数秒にまで短縮したのです。そして今後は、これを私たちが持つ他のデータベースにも広げていきます。Amazon Auroraは、皆さまが使うAmazonのデータベースの中でも最も人気のあるものの1つですが、このAmazon Auroraについても、数秒のうちに作成・接続できる機能を提供できるよう進めています。
Vinay： このことも寄与してくるのですが、人々はしばしば、実行のスピード、スケーラビリティ、そしてデータアクセスのシームレスさが、エージェントおよびエージェンティックな実行の鍵となる要素であるという事実を見落としがちです。そして、より多くのコーディングインターフェースが普及するにつれて、それらはデータへシームレスにアクセスする必要があります。私たちは、データをいったんレイクハウスで利用可能にし、それを特定のエージェントに利用可能にする、という複数のステップを踏みたくはないだろう、と気づきました。だからこそ私たちは、エージェントをさまざまなコーディングフレームワークに統合しています。AgentCoreであれば、たとえばLangGraphのチェックポイント用に、会話の状態をDynamoDBに保存しておけます。また、Neptuneを使えば、データの知識グラフを構築し、エージェンティックなメモリを築いて検索を改善できます。このように、異なるデータベースがそれぞれ異なる能力を提供しており、私たちはそれらをコーディングフレームワークと統合し拡張する取り組みを進めることで、データへのシームレスなアクセスを実現しています。
Vinay： そして、このシームレスさとスピードは、テクノロジーそのものだけにとどまりません。皆さまからいただいたフィードバックの1つに、「これだけ多くの選択肢があり、選べるのはよいが、その選択肢とやり取りし、それを消費するのに時間がかかる」というものがありました。それぞれ異なるライセンスモデルや、異なる消費モデルを持っているからです。そこで昨年のre:Inventで、私たちは全データベースを対象とするDatabase Savings Planを発表しました。これによって、どのインスタンスタイプを使っていても、異なるインスタンスタイプへ移る選択肢も、異なるリージョンへ移る選択肢も、異なるデータベースタイプへ移る選択肢も持てます。Database Savings Planでは、一定のコミットを行うと、その枠内でそうした選択肢がすべて視野に入り、特定のRI、特定のリージョン、特定のインスタンス、特定のデータベースタイプに縛られることなく、要件に応じてデータサービスの使い方を変えられます。これらのデータベースにまたがってDatabase Savings Planを利用でき、最大35%の節約を得ながら、どこで、何のインスタンスを使うかについて極めて柔軟に対応できるのです。
6.2 AgentCore・Kiroによる構築・デプロイとクロージング
Vinay： ご覧のとおり、私たちはデータに関して取り組み、イノベーションを重ねてきました。AIインフラについてもお話ししましたし、推論についても手短に概観しました。では次に、エージェントを構築し、デプロイし、管理していくために、私たちが何をしているのかを見ていきましょう。それを担うのが、Bedrock AgentCoreです。エージェンティックな文脈におけるAgentCoreの仕組みの詳細については、Tazが先ほど説明してくれたとおりです。AgentCoreは本質的に、オープンでモジュラーなインターフェースを提供します。Crew AIやLangChain、あるいは標準的なエージェントといった、どんなフレームワークでも接続できます。Bedrックのモデルでも、Bedrock外のモデルでも、AgentCoreの一部として使えるモデルを使えます。これは1つのビルディングブロックです。私たちは、皆さまに単一の道筋を強制することはしません。AgentCoreと連携させる必要のあるサービスを、皆さま自身が選び取れるようにしています。Amazon VPCを通じて、エージェントを私的かつ安全にデプロイするのも容易です。それは皆さまにとっての要件だからです。そして、AgentCoreサービスを使って、何千、何万ものエージェントへとスケールできます。最後になりますが、これは非常に高速にエージェントをデプロイできる手段でもあります。実際、1分未満でエージェントをデプロイし、実行を開始できます。
Vinay： エージェンティックな要素が入ってくることで、私たちは、ビルダーがシステムと関わる方法にも大きな変化が生じているのを目にしています。データを効率的にし、アナリティクスを効率的にすることにこれだけ投資してきた今、エージェントが登場し、開発のライフサイクルを短くしてくれています。その結果、ビルダーはより革新的な活動に集中でき、自分たちのためにより多くの成果を生み出すべく、テクノロジーと関わる新しい方法に取り組めるようになります。そして、ここで彼らが必要とするのが、それを駆動するための、さまざまなコーディングフレームワークや、さまざまなインターフェースです。
Vinay： そこで私たちが立ち上げたのがKiroです。これは、構造化されたAIコーディングのためのエージェンティックな開発環境です。Kiroは、AIコーディングのスピードを活かしつつ、より構造を持たせ、そのうえで皆さまが一歩一歩の運転手であり続けられるよう手助けします。単一のコンポーネントから複雑なプロジェクトまで、Kiroは開発者やチームと協働し、プロンプトを詳細な仕様(spec)へと変えていきます。そしてそれを使ってコードを書き、皆さまが求めているものを正確に作り上げられます。つまりKiroは、プロンプトの背後にある皆さまの意図を理解し、皆さまとそのチームが、求めている複雑な機能を実装するのを助けるツールなのです。さらに、開発者がKiroと関わる中で、より構造化され、目的に沿った成果を必要としていることも見えてきています。そのためKiroには、あらかじめ定義されたエージェントがいくつか備わっており、AWSからサブスクライブしてデプロイすることもできます。
Vinay： このように、私たちは皆さまを1つのジャーニーへとご案内してきました。ご覧のとおり、私たちは皆さまのエージェンティックなジャーニーを支えるべく、パートナーとして絶えずイノベーションを続けています。私たちは単一の選択肢を提供することだけに注力しているのではなく、選択肢を提供することに注力しており、同時に、皆さまが包括的な体験と包括的な成果を得るために必要となる、あらゆるレベルに目を向けています。私たちはこれからも皆さまとパートナーとして協働し、共に取り組み、前進しながらイノベーションを続けてまいります。ありがとうございました。