※本記事は、AWS Databases担当ディレクターのTobias Ternstrom氏による講演「Agentic AI with Commercial Databases」の内容を基に作成されています。本講演は、2026年3月12日にアイルランド・キルケニーのLyrath Convention Centreで開催された第5回AWS AI and Data Conference 2026にて収録されたものです。商用データベースは数十年にわたり利用され、企業にとって最も価値あるデータを保持してきました。それらをクラウドへ移行することは、Agentic AIを活用したイノベーションや新たな顧客体験を生み出す大きな機会となります。本講演では、AWSが商用データベースの利用をいかに容易にし、データパイプラインやエージェント型ワークフローを通じて革新的な体験を実現するかが解説されています。本記事では、講演の内容を要約しております。なお、本記事の内容は原著作者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご視聴いただくことをお勧めいたします。AWSのイベントに関する詳細情報は https://go.aws/events でご覧いただけます。
1. イントロダクションとエージェント革命のインパクト
1.1 登壇者紹介とセッション構成
Tobias： あらためまして、皆さんこんにちは。Tobias Tosterud と申します。私は Seattle にある AWS で働いておりまして、いくつかのデータベースサービスを担当しています。出身は Sweden です。アイルランドの皆さんに向けて言うと、私たちは過去に何度か London を焼き払うのをお手伝いしたことがありますので、もしそれがお役に立つようでしたら。
Tobias： まず最初にお断りしておきたいのですが、本日お話しする内容の一部は、すでにキーノートで触れたものになります。今回はもう少し時間をかけてお話ししますが、一部はキーノートの繰り返しになる点をご了承ください。そのうえで、最後にはアーキテクチャの説明と、実際にこれが現場でどのように見えるのかをお見せするために私たちが構築したデモで締めくくりたいと思っています。そして、できれば質疑応答のための時間もたっぷり残せればと考えています。
1.2 アプリ構築とスケールの激変、二大関心事（セキュリティとコスト／価格性能）
Tobias： まず冒頭で申し上げたいのは、エージェントが私たちの考え方をどれほど変えるか、という点について、私たちはいまだに過小評価していると思う、ということです。エージェントはアプリケーションを構築すること、そしてスケールさせることを格段に容易にします。そしてそれは、この部屋にいる私たちのような人間にとって、一連の新しく興味深い問題を生み出すことを意味します。
Tobias： もちろん、その一部は素晴らしいチャンスであり、とても楽しいことなのですが、同時に「この新しく大量に生まれるアプリケーションをどうやって支えるのか」という問題でもあります。というのも、もしアプリケーションが1000倍に増えるとしたら、これは決して誇張ではないと私は思っているのですが、というのも突然、会社にいる誰もが「これは繰り返しの作業だな、いつも同じことをやっているな。よし、アプリを作ろう」と言えるようになるからです。誰もがこれをできるようになるのです。ですから、アプリケーションを構築する規模そのものが変わっていきます。
Tobias： このことに関連して、私が思うに、システムやデータベースの観点から最も興味深いトピックが2つあります。1つはセキュリティ、そしてもう1つはコストと価格性能です。これだけ大量のデータベースを動かすことを、どうやって管理していくのか。この点については後ほどもう少し詳しくお話ししますが、ここが間違いなく私たちの注力している領域です。
2. AIインフラ、データ、アクセスパターンの変化
2.1 クラウドでしかスケールできないAIインフラとAPI経由接続の前提
Tobias： このAI革命、あるいはエージェント革命と呼んでもよいものを見ていくと、当然ながらAIインフラが必要になります。そしてそれは主にクラウドで利用可能なものです。よく言われるのは、エージェントのテストや構築はオンプレミスでも、あるいは自分のノートパソコン上でもできる、ということです。しかし、AIを本当にスケールさせることはオンプレミスでは非常に難しい。それができるインフラを持っている企業はごくわずかです。次に必要になるのが、モデルを動かすための推論プラットフォームです。そして、皆さんのデータが必要になります。私はこれを「データとアプリケーション」だと考えています。
Tobias： キーノートでも申し上げたように、皆さんはエージェントを自分たちのデータに接続することになりますが、おそらく直接接続することはないでしょう。つまり、「エージェントがあって、MCPサーバーがあって、そのMCPサーバーがクエリを生成してデータベースに送る」という構成にはならない、ということです。そうではなく、エージェントはMCPサーバーを使い、そのMCPサーバーは皆さんのアプリケーションが公開している何らかのAPIを指し示すのです。そしてそのAPIもまた、もちろんエージェントによって構築されうるものですが、それこそが、この一連のやり取りを可能な限り効率的かつ安全にするための要となるものなのです。
2.2 データ爆発と予測不能なエージェント利用パターン
Tobias： ですから、私たちが懸念しているのは、これから起ころうとしているデータの爆発的増加です。1つには、扱うデータが桁違いに増えるということ。しかしそれだけでなく、システムがデータベースとやり取りする方法そのものが完全に変わってしまう、という点が重要です。というのも、今日の私たちは、アプリケーションを構築する際にアプリケーションロジックを書き、それがある程度の数のクエリをデータベースに送る、という形に慣れています。そしてそれがどのような姿になるか、過去20年、30年かけて私たちは見慣れてきました。ですから、経験豊富な人ほど、この種の利用パターンに合わせて最適化したり、計画を立てたりするのが上手なのです。
Tobias： しかし、エージェントはまったく違います。これから生み出される膨大な数のエージェントが、皆さんのシステムをどのように使うのか、私たちの誰にとっても予測するのは非常に困難です。ここで私たちが目指しているのは、これを皆さんにとって可能な限り手間のかからないものにすることです。
3. トークン消費とエージェント効率化の新しい課題
3.1 MIPSとの類比、自然言語→SQL変換によるトークン浪費
Tobias： ここで非常に興味深くなる例を挙げてみましょう。エージェントを使い始めると、まず意識し始めるのがトークンを消費するということです。これはちょうど、メインフレームの時代にMIPSを消費していたのと非常によく似ています。トークンを使って計算処理をしているわけです。ですから、これをスケールさせていくと、ある時点で「自分はどのようにトークンを使っているのか」ということが気になってくるのです。
Tobias： たとえば、これは非常に実践的な話になりうるのですが、私たちが提供しているMCPサーバーがあるとします。これは皆さんのデータベースへの接続を手助けし、クエリを生成したりといったことができます。しかし、たとえばエージェントが何かをするとして、エージェントに何かを頼むたびに、たとえば「注文を1つ取得してほしい」と頼むたびに、エージェントが自然言語からSQLへの変換を行うとしたら、そのたびに大量のトークンを消費することになります。そしてクエリを実行し、その後また誰かが同じ質問をすれば、また同じようにトークンを消費し、同じクエリを生成することになるのです。
Tobias： ですから、こうした多くのことが時間とともに高くつくようになります。そこで、エージェントが使うツールをいかに効率的にするか、ということを考えなければならないのです。
3.2 自律エージェント間ジョインの非効率化という気づき
Tobias： そしてキーノートでもお話ししたように、皆さんは完全に自律的なエージェントも持つことになります。彼らは自分たちで動き回って物事を行い、他のエージェントと話し、自分たちの代わりに何かをするよう他のエージェントに頼みます。それは最終的には皆さんの代わりにということです。ですから、これが効率的であることが極めて重要になります。
Tobias： よい例がジョインです。ご存じのとおり、すべてのリレーショナルデータベースはジョインをサポートしています。たとえば、注文と顧客をジョインしたいとします。これはおそらく非常に効率的に行われるでしょう。適切なインデックスなどが用意されていて、クエリを実行するわけです。ところが、もしそのジョインがエージェントを介して行われたらどうなるでしょうか。あるエージェントが特定の地域のすべての顧客を要求し、別のエージェントに注文を尋ねて、そのエージェントが走り回って注文を取得してくる。すると、以前はデータベースの奥深くで非常に効率的に行われていたこのジョインが、エージェントのレベルで行われることになり、当然ながらはるかに非効率的で、性能も劣るものになってしまうのです。
Tobias： ですから、こうした新しい種類の問題が出てくるので、私たちはそれについて考えておかなければなりません。もちろんこれはチャンスでもあります。解決が難しいわけではありませんが、考えておくとよいことです。エージェントが自律的になればなるほど、どうやってコストを管理し、どうやって彼らをますます効率的にしていくかを理解したくなるからです。
4. AWSマネージドデータベースの歴史とデータベースの選び方
4.1 RDSとサーバーレスサービスの歩み
Tobias： マネージドデータベースについてお話しすると、私たちがこれを始めたのは、たしか15年と少し前のことでした。正確には17年前に Amazon RDS for MySQL をローンチしました。その後、私たちはますます多くのマネージドサービスを世に出してきました。Aurora をローンチし、Oracle のサポートを、SQL Server のサポートを、Postgres、MariaDB のサポートをローンチしました。そして RDS に最後に加えたのが DB2 です。これらのサービスで私たちが注力しているのは、こうした管理の手間をすべて引き受けて、皆さんに代わって自動化することです。私たちはこれを非常に長い間続けてきましたので、こうした作業の自動化はかなり得意になってきたと思いますし、皆さんが信頼して使える高可用性のシステムを確実に提供できるようになっています。
Tobias： さらに私たちはその先へ進み、サーバーレスのサービスを構築しました。まず Amazon DynamoDB、続いて Amazon Aurora for MySQL が登場し、その後 Amazon Aurora for Postgres が続きました。そして Amazon ElastiCache for Valkey があります。現在では、これら3つすべてをプロビジョンド型としても、自動でスケールアップ・ダウンするサーバーレス型としても提供しています。
4.2 既存アプリ原則、キャッシュ用途とValkeyの経緯、機能性スペクトラム
Tobias： ここで少し時間をかける価値があると思うのが、「データベースをどう選ぶか」という点です。皆さんのアプリケーションにどのデータベースを使うべきか、私たちはどう考えているのか。一般的に、最初の選択は非常にシンプルです。すでにデータベース foo を使っているアプリがあるなら、使うべきはそのデータベースです。コストなどの理由で別のデータベースに切り替えたい場合もありますが、基本的にはそれを使うことになります。だからこそ、私たちはこれほど多くのデータベースをサポートしているのです。皆さんの既存アプリケーションを確実に支えたいからです。
Tobias： では、新しいアプリケーションを構築する場合はどうか。私たちはこれを大きく3つの選択肢として考えています。1つ目は簡単なもので、キャッシュシステムの場合です。キャッシュに何を使うべきか。それには Amazon ElastiCache for Valkey があります。ちなみに Valkey は、私たちが提供する完全に Redis 互換のサービスです。これは Redis がソースコードのライセンスについてある方針を取ったことを受けて、私たちと他のいくつかの企業が一緒になって立ち上げたオープンソースプロジェクトで、誰でも使えるオープンなライセンスになっています。オンプレミスでも、自分のノートパソコン上でも、私たちのマネージドサービス上でも、あるいは他社のマネージドサービス上でも動かすことができます。これがキャッシュ用途です。
Tobias： そして、どのデータベースを使うかを典型的に決定づける、もう1つの興味深いスペクトラムがあります。それは「どれだけのことをできるか」というものです。スペクトラムの一方の端には、ケイパビリティ、つまり機能性があります。データベースが皆さんに代わって多くのことをやってくれる、ということです。その完璧な例がリレーショナルデータベースです。私たちが提供する、多くの機能を備えた高機能なデータベースが Amazon Aurora です。そして今日、新しいアプリケーションは最もよく Postgres の上に構築されます。Postgres は今日、新規アプリケーションにとって最も人気のあるデータベースなのです。2番目に人気があるのはおそらく MongoDB で、これに対しては私たちは MongoDB 互換の Amazon DocumentDB を提供しています。これが機能性の側の話です。
5. スケーラビリティの限界とDynamoDBの位置づけ
5.1 単一マシンの書き込み限界とDynamoDBの単一目的特化
Tobias： さて、スペクトラム上のもう一方の選択肢、つまりデータベースで実現するのが非常に難しいことについてです。皆さんの多くもご存じだと思いますが、ジョインだの何だのと多くのケイパビリティ、多くの機能を持っていると、その上にスケールを構築するのが非常に難しくなります。たとえば Amazon Aurora の場合、私たちは単一マシンが処理できる範囲まで書き込みのスケーリングをサポートしています。つまり、48XL のモンスターマシンを動かせば、それがそのデータベースの書き込みを処理するマシンになります。その上で、読み取りのスループットをスケールアウトするのを助ける、たくさんのリードレプリカを作成できます。
Tobias： しかし根本的に、単一マシンが処理できる以上の書き込みをしたい場合には、複数のデータベースを持たなければなりません。つまり、アプリケーションをパーティション分割し、シャーディングする必要があるということです。これは、こうしたデータベースのケイパビリティを複数のマシンにまたがって展開しつつ性能を維持することが、非常に難しいからです。すべてが遅くてよいのなら簡単な問題です。しかし、性能、しかも予測可能な性能も必要となると、これは非常に難しいのです。
Tobias： そこで登場するのが DynamoDB です。DynamoDB は私たちのキーバリューデータベースで、1つのことしかしませんが、それを非常にうまくやります。それは、あらゆる書き込みスループット、あらゆる読み取りスループットを、一桁ミリ秒のレイテンシで処理できる、ということです。それがこのデータベースの存在意義のすべてであり、それ以外には何もありません。その上で、私たちはいくつかのサービスを提供しています。皆さんのデータを失わないこと。データを複数のリージョンで同期コミット付きで利用可能にできるので、こちらで書き込んだものが、もしこのリージョンに何かあっても、あちらで確実に利用可能になっていること。変更をストリーミングで送り出すサポートなどもありますが、これらは持っていて当然の基本的なものです。
5.2 「最後の手段のDB」、開発速度のトレードオフ、「5つ以下」という経験的観察
Tobias： しかし DynamoDB はたとえばジョインをしません。Dynamo チームへのよくある要望が「これをサポートしてくれたらいいのに」というものです。ところがそうすると、「では中でプログラムを動かすことになる」という問題に陥ります。私たちが皆さんに約束した根本的な約束は、一桁ミリ秒以内に返すということです。ケイパビリティを拡張し始めると、その約束ができなくなるのです。機能を広げれば広げるほど、その上にアプリを構築するのが難しくなります。うまくいくときもあれば、いかないときもある、速いときもあれば、遅いときもある、となってしまうからです。私の昔の上司だった Raju Gulabani はよく「DynamoDB は最後の手段のデータベースだ」と言っていました。スケーリングの問題を抱えているとわかっているときに使うもので、そのときには本当に気に入るはずだ、と。しかしその問題がないなら、別のものを使うことになる、というわけです。
Tobias： ではなぜ常に DynamoDB を選ばないのか。もし私たちが成功してスケールを手に入れたとして、その代償は明らかに開発速度です。皆さんに代わってやってくれることが少ないデータベースの上にアプリケーションを構築するには、より多くの時間がかかります。DynamoDB のテーブルがあってレポートを作りたいとしても、これはフィルタリングしかしません。ジョインや集計のようなことをしたければ、それをアプリ側で構築しなければなりません。もちろんそれは可能ですが、構築には時間がかかります。
Tobias： ここがエージェントによって非常に興味深く変わる点です。今ではエージェントにそれを頼めますし、もちろん正しく動いているか検証するためのテスト生成も頼めます。とはいえ、ここで下すべき主要な判断はそれです。そして実のところ、それはそれほど難しくありません。アプリケーションを見てみると、たとえば100個のテーブル、100個のエンティティがあったとして、実際にあの DynamoDB のスケールを必要とするのはごく一部です。多くのお客様と話してきた感触では、典型的には片手の指の数以下、つまり5つ以下のテーブルが、書き込みスループットなどを捌くためにあの巨大なスケールを必要とする部分です。それ以上ではありません。もちろんエッジケースはありますが、それは非常にまれです。これは考え方の枠組みとしてよいものだと思います。
6. アイデアの速度で構築する／エージェントとデータの近接性
6.1 即時利用可能性と「10秒未満」の要件
Tobias： こうしたことはすべて、皆さんがアイデアの速度で構築できるようにしたい、という思いに行き着きます。キーノートでも申し上げたように、私たちが取り組んできたことの1つが、これらのサービスをすぐに利用可能にすることです。エージェントがプロトタイプを構築したりするので、待たせたくないのです。エージェントに何かを構築するよう頼んで、エージェントがデータベースを作成しに行くのに、データベースができるまで数分待たなければならない、という状況は避けたい。皆さんにとっては、それはおそらく世界の終わりというほどのことではないでしょう。少しいらいらして「なぜ待たされるんだ」と思うかもしれませんが、2分待てばそこにあるわけです。
Tobias： しかしエージェントの場合は、10秒未満で待たせたいのです。これもまた、新しいアプリケーションやエージェント的なユースケースをターゲットにしたサービスをどう構築するか、という点で変わってきていることの1つです。これらは非常に素早く作成でき、そして非常に素早く削除できなければなりません。なぜなら、エージェント的なフローの中では、エージェントは何かを作成し、テストし、そしてまたそれを取り除くからです。
6.2 LLMとデータの組み合わせ、API経由と分析用途の例外
Tobias： キーノートでも申し上げたように、エージェントを動かす LLM があり、エージェントは LLM と皆さんのデータの組み合わせによって動かされます。これを効率的にし、スケールさせるためには、エージェントを皆さんのデータの隣に置きたいのです。ここで「データ」と言っていますが、これは皆さんのデータとアプリケーションのことです。というのも、一般的には、エージェントにデータベースと直接やり取りさせるのではなく、皆さんが構築した何らかの API を経由させたいからです。その API がビジネスロジックやセキュリティなどを扱い、エージェントとデータの間に位置するのです。
Tobias： ただし、常にそうとは限りません。たとえば分析のユースケースでは、エージェントに何らかの分析サービスと直接やり取りさせたい場合の方が多いでしょう。それはデータベースかもしれませんが、Amazon Athena や Redshift のようなものかもしれません。そこではエージェントがクエリを生成し、結果を受け取る、という形になります。
7. エージェントの3つのペルソナとデータベースの役割
7.1 ビルダー／アナリティクス／オペレーショナルとオペレーショナルへの関心集中
Tobias： ここで、私が挙げた3つのペルソナがあります。1つ目はビルダーです。アプリケーションを構築していて、その中でエージェントを使っている、というユースケースです。2つ目は分析のユースケースで、エージェントが何かを解明しようとしている、皆さんに代わって調査をしている、というものです。そして3つ目がオペレーショナルのユースケースです。たとえば、誰かがサポートに電話をかけてきて、エージェントがそのサポート案件に対応しようとしている。サポートケースを取得し、詳細を更新し、何が起きているかを書き留め、「これは問題だな、では自動的にお客様に何らかの割引やクレジットを返金しよう」といったことを行うかもしれません。さまざまなシステムとやり取りする、これがオペレーショナルのユースケースです。
Tobias： そして、エージェントへの関心が最も集まっているのが、このオペレーショナルのユースケースだと私は思います。これはごく自然なことです。まずは分析のユースケースから始めて学んでいく、これは非常に有用なユースケースです。アプリケーションの構築も同様です。しかし、本当に多くの組織が行っている不要な重労働を取り除き、本業の中核により集中できるようにしてくれるのは、まさにオペレーショナルのユースケースなのです。
7.2 エージェントメモリの保存先とベクトルデータベースの動向
Tobias： データの側、私たちの視点からのデータベースには、もう1つの側面があります。1つは皆さんのアプリケーションのためのデータベースであるということで、これは皆さんのアプリの構築方法が変わる以外には、それほど変わりません。しかしもう1つのユースケースが、エージェントを支えることです。たとえばエージェントはメモリを持っていて、そのメモリをどこかに保存する必要があります。それをデータベースに保存するわけです。これがもう1つのユースケースです。
Tobias： そしてたとえばベクトルデータベース。これは1年から3年ほど前にすべての話題をさらっていたものですが、「データベースの中にベクトルを保存する必要がある、高速な検索が必要だ」というものでした。そして多くのスタートアップがベクトルデータベースを構築しました。しかしそうすると、管理しなければならないデータベースがもう1つ増えることになります。しかも、こうしたベクトルは通常、皆さんのデータベース内の他のデータと関連しているのです。たとえば注文テーブルや商品テーブルを取って、その中のテキストをベクトルに変換し、RAG を使って効率的に検索できるようにする、というわけです。そのデータを本当に別のデータベースに保存したいでしょうか。そしておそらく、それらの間でトランザクションを実行したいかもしれません。すると、新しい問題を抱えることになります。
Tobias： ですから、これは非常に明確な方向性として見えてきています。世に出ているほぼすべてのデータベースが、データベース内にネイティブにベクトルのサポートを追加しているのです。SQL Server であれ、Postgres であれ、DynamoDB であれ。DynamoDB については私たちが検討中のものですが。そして S3 Tables もベクトルのサポートを持っています。ですから、ベクトルは今日人気のあるほぼすべてのデータベースで、ネイティブな構成要素になっていくと予想されます。
8. MCPの仕組みと本番運用での設計指針
8.1 APIのリストとしてのMCPと自然言語→SQL直接生成の非推奨理由
Tobias： さて、これが標準的な構成です。LLM によって動かされるエージェントがあり、それが MCP サーバーを使っています。これは Model Context Protocol のことです。MCP は非常にシンプルな事実上の標準で、基本的にはただの API のリストです。つまり、エージェントが何かと、それがどんなツールであれ、やり取りするために使える API のことです。たとえば、注文のための MCP サーバーがあるとして、1つのツールは「新しい注文を追加する」、別のものは「注文を更新する」「注文を検索する」といった具合です。そしてそれらは、エージェントが使える API を指し示している、API を記述しているだけなのです。ですから、これはエージェントから API へのマッピングにすぎません。実際にはもう少し色々ありますが、おおむねマッピングだと考えてよいでしょう。
Tobias： そして申し上げたように、エージェントがデータベースと直接話すことは、おそらく望ましくないと私は考えています。つまり、自然言語で質問をすると、MCP サーバーが SQL Server、Oracle、Postgres、Dynamo などへの接続方法を知っていて、SQL クエリを生成する、という構成です。これはおそらく起こりにくいシナリオです。もちろん例外はあって、おそらく分析の側ではありうるのですが、起こりにくい理由が2つあります。1つは、エージェントが皆さんのデータに対して実際に何ができるのか、これを非常に慎重に、しっかり制御したいからです。もう1つは、繰り返しになりますが、そのクエリを生成するために必要なトークンを、何度も何度も費やしたくないからです。
Tobias： もちろん、これをキャッシュする方法を考えることはできます。ですが私たちは皆、キャッシュが非常に難しい問題だと知っています。ほぼ正しいものをキャッシュした場合、それを再利用できるのか、といった問題です。ですから、これは留意しておく価値のあることだと思います。エージェントで遊んでみる、特に最初の段階では完璧なやり方ですが、本番のユースケースには向きません。本番のユースケースでは、ハード化された API を経由させることになります。
8.2 Gartner予測と既存APIのMCP公開
Tobias： これは過小評価されている価値だと思います。Gartner は、2028年までにエンタープライズソフトウェアアプリケーションの33%がエージェント型 AI を含むようになる、と考えています。つまり、もう2年後のことです。私はその数字でも低すぎると思っていて、実際にはもっとずっと高くなる可能性が非常に高いと考えています。
Tobias： そして非常に興味深い問題になるのが、皆さんは大量の既存アプリケーションを抱えている、という点です。それらの既存アプリケーションを、どうやってエージェントに公開するのか。これはそれほど難しくないと私は考えています。というのも、それらのほとんどはおそらくすでに API を公開しているからです。ですから、エージェントが消費しやすい API を用意し、それを MCP サーバーを通じて公開すればよいのです。これでエージェントは皆さんの既存システムとやり取りできるようになります。そして皆さんは、エージェントがどんな操作をできるのかを正確に把握できるのです。
9. オンプレミスワークロードとクラウド移行戦略
9.1 オンプレ接続の課題と緊急移行を避けたい顧客の声
Tobias： さて、私たちが1つわかっているのは、多くのワークロードがいまだにオンプレミスにある、ということです。はっきりさせておきたいのですが、AWS や他のどのクラウド上で動いているエージェントからでも、オンプレミスにある皆さんのデータに対して接続して動作させることは、間違いなく可能です。ただし、そこで直面する、留意しておかなければならない問題が、セキュリティと性能です。というのも、想像できるとおり、非常に多くのリクエストが発生することになりますし、皆さんのシステムとクラウドの間の接続の信頼性も問題になります。
Tobias： ここで非常に興味深い点があります。もし皆さんがこれを見て「よし、スケールさせよう、エージェントとデータベースを同じ場所に置けるように、多くのアプリケーションをクラウドに移そう」と考えているなら、まずはクラウドからデータセンターへのリンク経由で始めることができます。つまり、API がどうなるのか、どう動くのか、といったことを検討するのを、移行が済むまで待つ必要はないのです。今日から始められます。信頼性とレイテンシの問題は、特にこうしたものをスケールさせ始めると問題になってきますので、なおさらです。
Tobias： かなり多くのお客様から私が聞いているのは、彼らはこれがビジネスにとって非常に重要なものになった段階で、信頼性の問題や性能の問題が出始め、そこから何らかの移行を急がなければならなくなる、という事態に陥りたくない、ということです。また、移行する際に、アプリケーションをどの順番で移していくかを見極めるのは、かなり簡単だとも申し上げておきます。
9.2 移行アプリの4分類とAWSの中立的立場
Tobias： ですから私たちにとって非常に重要なのが、皆さんがこうした既存アプリケーションを私たちのマネージドサービス上で動かせる、ということです。だからこそ私たちは RDS for Oracle、RDS for SQL Server、RDS for DB2、そしてもちろん MySQL、Postgres、MariaDB も提供しているのです。そしてはっきりさせておきたいのですが、私たちはこれに長い間取り組んできました。キーノートでも申し上げたように、RDS for Oracle をローンチしたのは15年以上前、16年前だったか、いずれにせよかなり前のことです。私たちは Oracle 自身が自社のクラウドで Oracle サービスを運用してきたよりも、ずっと長く Oracle サービスを運用してきたのです。これは私たちにとって極めて重要な投資です。
Tobias： そして、こうしたデータベースとともにクラウドへ移行したいアプリケーションは、4つのクラスに分かれることを私は知っています。1つ目は、皆さんが自分で構築したカスタムアプリケーションで、何らかの理由、おそらくコストのために、できるだけ早く Oracle や SQL Server から抜け出したい、というものです。ただ、こうしたものはそれほど多くないと思います。なぜなら、それらはおそらくすでに Postgres のようなものに移行済みだからです。2つ目のクラスは、同じくカスタムアプリケーションですが、「SQL Server や Oracle はここでは必要ないだろう、移行すべきだが、緊急ではない。たぶん数年かけて移していくよ」というものです。
Tobias： 3つ目のクラスは、ISV アプリケーションです。皆さんが購入した何らかのアプリケーションで、そのソースコードを持っていないため、どのデータベースエンジン上で動くかを本当には制御できない、というものです。そして最後のアプリケーションクラスは、そのアプリに関しては SQL Server や Oracle が大好きだ、というものです。素晴らしいと思っていて、切り替えたくない。切り替えるのは不要なリスクでしかない。それらのデータベースを動かすためにお金を払う価値がある、というわけです。
Tobias： 私たちがはっきりさせておきたいのは、私たちはこれらのユースケースすべてが好きだ、ということです。皆さんがどう考えていようと、皆さんを支えたい。Oracle アプリケーションを移行してきて、翌日には別のデータベースに変換したいと思っていても、あるいは Oracle や SQL Server のアプリケーションを移行してきて、少なくとも10年は動かすつもりでも、そのどちらに対しても、ここをこうしたアプリを動かす最良の場所にしたいのです。
Tobias： そして私たちにとって少し違う点は、皆さんが切り替えるかどうかについて、私たちには利害関係がない、ということです。Oracle から切り替えたいアプリケーションは私たちにもたくさんありますし、amazon.com でも実際にそれをやりました。ですから、キーノートで触れたように、アプリケーションを書き換えるのを助ける AWS Transform のような、Oracle や SQL Server から、典型的には Postgres へ移行するのを助ける能力を、私たちはたくさん持っています。移行する準備ができたら、喜んでお手伝いします。アプリを決して移行したくないのであれば、それも大歓迎です。どちらの場合でも私たちは皆さんを支えます。組織が大きくなればなるほど、こうしたアプリのクラスをすべて抱えることになります。ISV アプリは留まらざるをえない、これは切り替えても意味がないから切り替えたくない、そしてこれは時間をかけて Postgres のようなものへ移したい、といった具合です。
10. RDSの機能強化、価格改定、節約プラン
10.1 機能強化、SQL Server値下げとライセンス分離、第7世代推奨
Tobias： 私たちはこうしたサービスのために、より多くの能力を毎年大量に投資して構築しています。たとえば、マルチAZ のサポートがありますし、クロスリージョンのリードレプリカもあります。ストレージは最大256テラバイトまでサポートしていて、これはたとえば Azure が自社の SQL Server ベースのデータベースサービスでサポートしている容量よりも多いものです。そしてキーノートでも申し上げたように、RDS for SQL Server の価格を最大50%引き下げました。これは re:Invent でローンチしたものです。
Tobias： さらにそこで、価格を分離しました。RDS for SQL Server で SQL Server を動かすと、これまでは1つの価格があって、請求書には「RDS for SQL Server」として表示されていました。これには RDS の部分と SQL Server のライセンスが含まれていたのです。re:Invent でローンチしたのは、第7世代のインスタンスタイプについて、これらを分離するというものです。これにより、請求書ではライセンス部分と RDS 部分が別々に表示されるようになります。そしてこれが、私たちの価格引き下げを実現するのに役立ったことの1つでもあります。ライセンスについては、そのまま皆さんに引き渡すかたちです。
Tobias： もう1つローンチした興味深いものが Developer Edition です。RDS で SQL Server Developer Edition をサポートするようになったので、Developer Edition を使えるすべての開発・テストのユースケースで、それを RDS 上で使えるようになりました。これはつまり、それらについてはライセンス部分のコストがなくなり、AWS の部分、RDS の部分のコストだけを払えばよくなる、ということです。
Tobias： それから、価格の引き下げ、この最大50%というのは、新しいインスタンスタイプ、つまり M7 や R7 のインスタンスタイプに対するものです。ですから、今日 RDS for SQL Server を動かしているなら、できるだけ早く第7世代に切り替えるべきだと私は思います。お金を節約できますから。しかも必要なのはそれだけです。インスタンスを停止し、インスタンスタイプを切り替え、また起動する。これで新しい価格が適用されます。RDS は15年以上前から存在していて、マルチAZ、自動パッチ適用などをサポートしています。もしまだ RDS に触れていないなら、ぜひ見てみてください。
10.2 Database Savings Planの割引・横断適用・注意事項
Tobias： Database Savings Plan についても触れました。re:Invent でローンチしたものです。これは EC2 で提供している Compute Savings Plan に似たもので、データベースに対して最大35%の割引を提供します。割引率について申し上げると、ドキュメントを見ていただければ、データベースのタイプによって割引率が変わるのがわかります。より高い割引率、この35%はサーバーレスに対するものです。どの割引率がどのデータベースエンジンに適用されるかは、ドキュメントで正確に確認できます。
Tobias： そして、Savings Plan を1つ買えばよいだけで、それが皆さんの DynamoDB、ElastiCache、ElastiCache for Valkey、RDS、Aurora などの利用にまたがって適用されます。私たちは、最も大きい割引が何であれ、その割引を適用します。ですから、今日データベースを動かしていて RI を使っていないのであれば、もちろんこれらの一部にはリザーブドインスタンスの価格設定がないものもありますが、今日これを見てみるべきだと私は強く思います。
Tobias： ただし、確認しておくべき細かい注意事項があります。1つは、これが新しいインスタンスタイプに対するものだということです。たとえば RDS for SQL Server では第7世代のインスタンスには適用されますが、第6世代には適用されません。そしてこれが、SQL Server についてライセンス価格を分離しなければならなかった理由の1つでもあります。当然ながら、Microsoft の価格に対して割引をすることはできないからです。ですから、これは RDS の部分に適用され、ライセンスの部分には適用されません。皆さんはぜひこれを見てみるべきです。細かい注意事項を見て、どのサービスが含まれるか、どのインスタンスタイプがサポートされているかを確認し、それらのインスタンスタイプに移行すれば、簡単にかなりの節約が得られます。
Tobias： ちなみに私はとても嬉しかったのですが、re:Invent でこれをローンチしたとき、最も大きな拍手をいただきました。これは Matt のキーノートのデッキの最後のスライドだったのです。正確にはこのスライドそのものではありませんが。そして現在、私たちは1年のコミットメントを提供しています。より長期のコミットメントのサポートも検討中ですが、まずは1年から始めました。たとえば Compute Savings Plan には3年のコミットメントもあります。
11. Oracle Database at AWS（Exadata）とZero ETL連携
11.1 Exadata提供、責任分担、AZ展開と現場での学び
Tobias： それでは Oracle Database at AWS に戻りましょう。これは私たちが Oracle と提携して、私たちのデータセンター内で Exadata のサポートを提供するものです。これはマーケットプレイスの提供形態になっていて、皆さんは基本的にマーケットプレイスを通じて Oracle から購入することになります。ですから、Oracle の営業担当などと話をしていただくかたちです。そのうえで、私たちのデータセンター内でこのサービスを使い始めることができます。これは標準的な Oracle Exadata を私たちのデータセンター内で動かすものです。何か特別な建物などに置かれているわけではありません。私たちが電力とスペースを提供し、もちろんネットワークと、私たちのサービスとの統合を提供します。そして Oracle が自社のソフトウェアとハードウェアを提供します。
Tobias： ここでの大きなポイントは、Exadata のワークロードをそのままの状態で AWS にリフト＆シフトできるようになった、ということです。これらのために低レイテンシのネットワークを用意していて、さらに低いレイテンシを実現することが、私たちのロードマップで取り組んでいることの1つです。現在はおよそ0.5ミリ秒のレイテンシですが、これをさらに下げようと取り組んでいます。そしてこれもマーケットプレイスを通じて利用可能です。
Tobias： キーノートで触れたように、Ireland で最初のアベイラビリティゾーンをローンチしたばかりです。皆さんがご覧になっているこれらすべてのリージョンについて、私たちが行っているのは、2つのアベイラビリティゾーンをローンチして、Oracle Exadata を使ってマルチAZ の可用性を実現できるようにすることです。Ireland では最初のアベイラビリティゾーンが稼働していますが、2つ目はまだです。私たちの見方としては、最初のアベイラビリティゾーンが利用可能になればすぐにテストを始められる、というものです。そして本番のユースケースでは、皆さんの構成次第ではありますが、典型的には2つのAZ に置きたいと思うでしょう。オンプレミスのシステムとクラウドの間で何かを行うこともできますが、完全に AWS で動かしたいのであれば、ワークロードによっては2つのAZ に置きたくなるはずです。とはいえ、数週間のうちに Ireland でも2つ目のAZ をローンチします。
Tobias： これらすべてのリージョンについて、私たちは Oracle と協力して、今年中にローンチすべく取り組んでいます。その多くは、上半期に最初のアベイラビリティゾーンが稼働すると思います。ただ、いくつか注意点はあると申し上げておきます。ときには地面の中を見てみると、本来そこにあるはずのファイバーがあるはずだったのに、実際にはファイバーがなかった、ということもあるのです。ですから、いくつか興味深い学びもあります。とはいえ、全体としては非常にうまく進んでいますし、私たちは Oracle とこの件で実に良好な協業関係を築いています。毎週ミーティングをして問題を1つずつ解決し、こうしたサービスをローンチし続けています。これらにはかなり多くの関心が寄せられていると申し上げておきます。
11.2 8つの新規Zero ETL接続とCPU負荷オフロードの価値
Tobias： キーノートで触れたように、8つの新しい Zero ETL の接続もあります。これは単純に、私たちのデータベースサービスから Redshift への複製です。Oracle、SQL Server、それから通常の Postgres と MySQL のサポートを追加しました。そして、これも EC2 からのものです。ですから、私たちのマネージドサービスを使う必要はなく、セルフマネージドの EC2 からでも実行できます。この Zero ETL を、オンプレミスのワークロードからでも、別のクラウドからでも実行できるのです。
Tobias： ここでの狙いは、運用システムからデータを取り出して分析システムに入れるのを、とても簡単にすることです。そしてこれは、おそらく皆さんご存じだと思いますが、運用システムの負荷を軽減する非常に良い方法でもあります。高価な CPU サイクルが、運用システム上で動いていたものを、分析システム側へ移すことができるからです。
12. 移行とモダナイゼーションの推奨アプローチ
12.1 エージェント近接という基本方針と段階的移行
Tobias： さて、私たちがこれをどう捉えているか、そして私たちの推奨ですが、皆さんはデータベースをエージェントの近くに来るように移行したいはずだ、ということです。繰り返しになりますが、開発したり学んだりするのを待つ必要はありません。それはオンプレミスにある運用データと、クラウドにあるエージェントで、まったく問題なくできます。しかし、エージェントをスケールさせたくなったら、おそらくアプリケーションとデータベースを互いの隣で動かしたくなるはずです。
Tobias： ですから、まずはデータベースをそのままの状態で移行します。そしてエージェントでスケールし始めます。そのうえで、モダナイズできる、そしてモダナイズしたいと思えるアプリケーションについては、モダナイゼーションを行う、というのが私の考えです。おそらく Aurora Postgres のようなもの、あるいは Postgres、DynamoDB、ElastiCache の組み合わせへ移行する、ということです。それは AWS Transform のようなものを使って、時間をかけて行えます。
12.2 継続利用とPostgres移行の両支援という立場
Tobias： そして私たちは、それを喜んでお手伝いします。ここで非常に明確にしておきたいのですが、もし皆さんが特定のワークロードを Oracle や SQL Server でずっと動かし続けたいのであれば、私たちはそれが大好きですし、皆さんを支えます。一部のワークロードを Postgres のようなものへ移したいのであれば、それもお手伝いします。これらのユースケースのどちらについても、私たちは皆さんを可能な限り最善のかたちで支えたいと考えていますし、それらのワークロードは AWS 上で素晴らしく動くはずです。
13. デモ：エージェント型バンキングアプリケーション
13.1 Vladの高速開発逸話とアーキテクチャ・データベース構成
Tobias： それではデモです。これは私たちのソリューションアーキテクトの1人が、非常に素早く組み上げたアプリケーションです。彼がどれほど速くやったか、ほとんど怖いくらいです。彼の名前は Vlad といいます。Vlad は素晴らしい人物ですので、ぜひ Vlad に話しかけてみてください。Vlad が戻ってきて「作りました」と言ったとき、私の頬には一筋の涙が伝っていました。とても幸せでした。
Tobias： ここで私たちが構築したのは、金融アプリケーション、つまり銀行のアプリケーションの例です。皆さんがお持ちのどの銀行であれ、ログインすると自分の口座などが見える、というものです。そして彼らは、そこにエージェント的な体験を追加したいと考えました。「皆さんの活動を分析するエージェントがあって、『おや、高利回りの貯蓄口座を使ったほうがいいかもしれませんよ』とか『こちらにもっと安いクレジットカードがありますよ』といったことを見てくれる」というわけです。これがその背後にある発想です。
Tobias： デモをお見せする前に、こちらがその背後にあるアーキテクチャです。少しクモの巣のように見えますが、それほど複雑ではありません。まず、アプリケーションのいわば枠組みの部分はすべて、ただの HTML です。これは CloudFront 上でホストされていて、ファイルそのものは S3 から出てきます。これがアプリケーションの中核が動いている場所です。そして API Gateway があって、これがそれらの API をすべて公開しています。これが実際のアプリケーションです。たとえばプロファイルサービスやマーケットサービスです。
Tobias： この例では、DynamoDB が、この例の銀行が発生するマーケットイベントをすべて保存するために使っているデータベースで、それを銀行アプリケーションの中で見せたり使ったりしたいわけです。ですからそれは DynamoDB に保存されていて、DynamoDB と話す何らかの API があります。次にバンキングサービスがあって、彼らはサービスの一部を Postgres に移しています。ですからそれは Aurora Postgres で動いていて、商品カタログなどはすべて Postgres にあります。そしてそれらのサービスの一部、この場合はコアバンキングが SQL Server で動いています。これは RDS for SQL Server です。
Tobias： ですから、これらの Lambda、つまり API の上のほうのセットが、皆さんが使う標準的なバンキング API で、これがモバイルバンキングアプリやウェブバンキングアプリが、私がクリックして回るときに呼び出しているものです。そしてこちらにエージェントサービスの API があって、これは Agent Core Memory を使っています。Agent Core Memory は、何が起きていたかをエージェントが覚えておくためのメモリで、長期メモリと短期メモリがあり、それは内部では DynamoDB に保存されています。そして Agent Core Gateway があって、これがこれらの MCP ツールをすべて公開しています。これがまた別の API のセットです。これが、私たちがエージェントにできるようにしてほしいことです。
Tobias： エージェントは、提案をするためにユーザープロファイルとマーケットデータを見られる必要があります。これがいわばリサーチの部分です。商品カタログを見られる必要があり、それによって「この、より低コストのクレジットカードを使うべきですよ」といった提案ができます。それからバンキングデータを見て、バンキングシステムと話せる必要があります。たとえば、私がそれを見て「では、このクレジットカードの1枚が欲しい」と言ったら、エージェントはそれを私のために作成できるべきです。ですから、そのシステムと話せる必要があります。そしてこちらに、このメモリの一部があります。会話のどこにいるのか、エージェントとのワークフローのどこにいるのか、それをどこかに保存しておく必要があって、それに DynamoDB が使われています。これが、エージェントが動作するために必要な部分です。
13.2 ワークフロー実行、課題検出と推奨アクション、同意フローと総括
Tobias： では、アプリケーションを見てみましょう。ここに私のアカウントがあります。彼は実は Amazon のシングルサインオンも追加していて、まだ試していないのですが、Vlad は時間を持て余しているんじゃないかと思います。彼がログインすると、すべてをセットアップします。基本的にシステムをリセットするので、まるで一度もログインしたことがないかのようにログインし、自分の口座などが見えます。これはすべて RDS for SQL Server や Dynamo などでライブに動いています。
Tobias： そしてここをクリックすると、エージェントが何をしているのかが見えます。これはエンドユーザーには見えないもので、デバッグ目的のためのものです。ここで見えるのは、エージェントが起動したことです。私がログインしたので、ワークフローが起動して「エージェント、これを見てきてくれますか」と頼んだわけです。そしてデータを取得してきました。SQL Server から口座の概要を取得し、Dynamo からユーザープロファイルを、現在のマーケット状況などを取得しました。そして Aurora Postgres にあったバンキング商品をすべて取得しました。これらはすべて API を経由しています。SQL クエリを生成しているのではなく、Vlad が構築した、Lambda として公開された API を使っているのです。
Tobias： そしてエージェントは進んでいって、いくつかの評価を行い、いくつかの重大な問題を見つけました。「おや、キャッシュフローがマイナスだ。使いすぎているな」と。これは静的なものでも何でもありません。Vlad に頼んでいるのですが、残念ながらこのデモのコードはまだ共有できないものの、共有してほしいと頼んでいます。これはすべてエージェントから出てきているものです。エージェントは「よし、利用できる適格なアクティブなバンキング商品があるな」と見つけ、財務を評価して、推奨を提示します。ここに推奨されるアクションがあります。「アップグレードすべきです」。これはとてもアメリカ的ですね。「プレミアム特典付きクレジットカードへアップグレードしましょう、成長投資口座を開設しましょう、緊急資金のバッファを設定しましょう」と。これが、これらのデータソースを見て、それらの MCP ツールを使って、エージェントが導き出したものです。
Tobias： そして私はそれを実行できます。この場合、「プレミアム特典付きクレジットカードへアップグレードしたい」とします。このボタンをクリックすると、エージェントに「彼がプレミアム特典付きクレジットカードへアップグレードしたがっている」というリクエストが返されます。クリックすると、少し時間がかかるのがわかります。そのあとエージェントがすることは、このリクエストを見て、私に許可を求めることです。「これが私のやろうとしていることです。これでよろしいですか」と。「はい」と言えば、エージェントはそれを実装しに行きます。ワークフローを実行します。ほら出ました。「続行にはあなたの同意が必要です」。そしてこの素敵なワークフロー ID を皆が暗記しなければ……いや、やめておきましょう。切り替えを行っていて、年間686の便益を見積もっています。完璧です、進めてください。これでエージェントがそのワークフローを実行しに行きます。
Tobias： これらはすべて Kiro で構築されました。そして RDS for SQL Server、Aurora Postgres、DynamoDB を使っています。これらのデータベースをすべて使う必要はありませんし、これらのデータベースである必要もありません。これはあくまで一例です。ですが、アーキテクチャに戻っていただくと、興味深い点があると思います。一見すると少しごちゃごちゃして見えますが、実は非常に理にかなっています。過度に複雑ではありません。アプリケーションが標準的なバンキング業務を行うために使う、高度に決定論的な API があります。これが皆さんがすでに今日持っているものです。そしてそこに、エージェントが利用できるツールを、MCP サーバーというかたちで追加しただけです。それでエージェント的な体験が手に入ったのです。
Tobias： ということで、これで私たちが取り組んでいることについて、少しでも知見を得ていただけたなら幸いです。質問のために少し残りますので、よろしくお願いします。本当にありがとうございました。