re:Invent 2025: YugabyteDBで実現するGen AIアプリケーションのウルトラレジリエント構築
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Beyond Vector Search: Ultra-Resilient GenAI Apps with AWS Bedrock (DAT202)
この動画では、YugabyteDBを用いたGen AIアプリケーション構築の簡素化について解説されています。AIによる指数関数的な開発速度の向上に対応するため、長期利用ではなく変化に備えた構築と日々の反復が重要だと強調されています。技術スタックの変化、データの多様性、パイプライン構築の複雑さという3つの課題に対し、PostgreSQL APIというオープンスタンダードの採用、RAG extensionによる1行SQLでのパイプライン構築、ラップトップから本番環境へのシームレスな移行が解決策として提示されています。さらに、マルチリージョン対応やウルトラレジリエンス、セキュリティ、エージェント的なデータベース操作への対応など、運用面での課題解決についても詳しく説明されています。実験から本番環境への迅速な移行と継続的な改善を可能にするインフラストラクチャの重要性が論じられています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
Gen AI時代の到来と反復開発の重要性：長持ちする構築から変化のための構築へ
皆さん、お腹は空いていないですよね？では始めましょう。おそらく多くの方がGen AIについてたくさんのピッチを聞いていると思いますが、私もGen AIについてお話しします。ただし、Gen AIでアプリケーションを構築することをいかにシンプルにするか、という点についてです。まず、YugabyteDBについて簡単にご紹介します。YugabyteDBは分散型Postgresデータベースで、Gen AIであろうとなかろうと、アプリケーション構築をシンプルにしています。データベースはそうあるべきですよね？開発者にとって完全なPostgres、真のクラウドネイティブ、そしてよりシンプルに。どのようにしているか見ていきましょう。
まず、私たちはまだGen AIによって推進される大爆発には至っていません。今は2025年です。Gen AIの影響は今後3年間で起こると予測されています。私たちはその時期にいるんです。つまり、今皆さんがやっていることは、昨年や一昨年やっていたこととそれほど変わりません。しかし3年後にやることと比べると、3倍から10倍の頻度で構築し、出荷することになるでしょう。
さて、どこを見てもみんながAIに投資しています。右側は私たちのユーザーやお客様で、彼らの投資先を示すチャートです。左側は様々なデータポイントですね。もちろん全部は説明しませんが、これは現実です。投資は本物です。
期待は非常に大きいです。どうやら3日間で、4日間で、1時間でアプリ全体を構築している人たちがいるそうです。ノーコードでコーディングして問題を解決したり、Gen AIが問題を解決したり、エージェントがエージェントと話し、さらにエージェントと話して問題を解決したり、といった具合です。これが私たちが自分たちのために築いた期待の時代なんです。
しかしこれが現実です。必要とされるレベルには達していません。ほとんどの人がAIをやっています。彼らはAIのために働いていますが、AIは彼らのために働いているでしょうか？ビジネス価値を引き出せているでしょうか？そうでもないんです。そして、データベース構築者として、私たちはアプリケーション構築と価値の引き出しをよりシンプルにしようとしています。ですから、これは私たちが注目していることの一つなんです。なぜでしょうか？
さて、これが根本的な違いです。AIはソフトウェアのビルドとデプロイのループを非常に速くします、それは指数関数的なんです。そして人間として、私たちは指数関数的なものを想像することができません。私たちはそれが得意ではないんです。そういう風にできていないので、よく、皆さんがどうかはわかりませんが、私はよく今日とか今週はたくさんのことができると思うんですが、1年でどれだけのことができるかは全く見当がつかないんですよね。大抵、1年ではもっと多くのことをやり遂げて、今日や今週は少なくなってしまう、そうでしょう？それが人間の性質なんです。では、想像できないものをどうやって構築するのか？どこに向かっているかわからないけれど、それが大きい、巨大だとわかっている。どうやってそこに到達するのか？
変えるべき原則が一つあります。その原則は、反復する、毎日反復するということです、いいですか。最終状態を視覚化しようとせず、ただ反復しながらそこに到達するんです、わかりますか。皆さんはどうかわかりませんが、私はソフトウェア業界に20年以上いて、開発者としてスタートしました。一つのルールを教えられました：長持ちするように構築しろ、と。もし構築するなら、最低でも2〜3年は使えるものでなければならない、もっと長いかもしれない。長く残れば残るほど、良い構築をしたということだ、と。でも、どうでしょう？それは全部窓の外に投げ捨てられました。私たちは変化するために構築しているんです。6ヶ月前には、MCPなんてありませんでした。その6ヶ月前には、RAGがバズワードでした。そのまた6ヶ月前には、えーと、Gen AIが起こっていました。誰が知っていましたか？6ヶ月ごとに全てが窓の外です。では、反復しなければならない時、どうやって構築するのか？どうやって構築するのか？そして明らかに、解決策は6ヶ月ごとにゼロから何かを構築することではありません。
ステートフルアプリケーション構築における3つの課題：オープンスタンダード、データ多様性、RAGパイプラインの簡素化
そのやり方では、どこにも行けません。これらが、ステートフルなアプリケーションを構築する際に私たちが見ている課題です、いいですか。課題は何でしょうか？ 一つ目、技術スタックが常に変化しているということです。オープンスタンダードが超重要です。自分が知っているものを選んでください。AIが魔法のように問題を解決してくれるわけではありません。AIはあなたが知っていることをより速くしてくれるんです。だからオープンスタンダードを選んでください。データベースの世界では、Postgres APIを選んでください。本当に繁栄していて、盛り上がっています。エコシステム全体にしっかりと接続されていることを確認してください。それが反復を可能にします。私たちにとって、YugabyteDBにとって、私たちは何をしているのか？Postgresの上に構築しています。その上にイノベーションを構築して、皆さんの生活をより簡単にし、すでに馴染みのあるものの上でより速く進めるようにしています。私たちは意図的にクラウド間で標準をもたらしています、いいですか。異なるクラウドがAIのために異なる種類のパワーアップを構築しています。Postgresはオープンスタンダードですが、それらのパワーアップは、ベクトル検索機能のように、それらのクラウドでのみ得られます。私たちはそれを民主化するんです、わかりますか。
二つ目の課題。データの多様性にどう対応するか？今日のアプリケーションは、一緒にいる理由がないデータを一緒にします。例えば、私たちはある銀行と話しています。彼らはMCPサーバーを作りたいと思っています。ユーザーはMCPサーバーに何を尋ねられるべきでしょうか？当座預金口座を開設するにはどうすればいいですか？
私の口座から友人の口座に10ドル送金できますか？これが彼の名前とメールと識別情報です。これを私のためにやってもらえますか？まあ、それはドキュメントには載っていませんでした。それは別の何かで、話をしなければなりません。そもそもその権限はあるんですか？まあ、二つのチャットボットを構築するつもりはないでしょう。一つを構築するつもりですよね？つまり、全てが単一の提供物に統合されなければならないということです、つまりより多くの場所、より多くのフォーマットです。あなたの当座預金口座の残高が、当座預金口座を開設する方法についてのドキュメントと連携する必要があります。それをどうやって実現するのか、そして迅速に？
さて、ここで私たちが行っていることの一つですが、これがまた Postgresの素晴らしいところなんです。異なるタイプのデータを接続したり、トランザクションデータ、オペレーショナルデータ、画像などのS3バケットに存在するデータを保存したりする際の、数多くのイノベーションがあります。皆さんも多くのベクトルストアプロバイダーの話を聞かれると思いますが、彼らには敬意を表します。彼らがやってきて、どうすればもっと良くできるか、もっと良くできるかと言っています。覚えておいてください、イテレーションできる必要があるんです。イテレーションはシンプルさから生まれます。何を改善する必要があるかを決定したら、それを改善しに行けばいい。でも、長く使えるように作る前に、イテレーションできるように作ってください。なぜなら、柔軟性について考えなければ、長く使えるように作ることだけが、あなたが達成できるすべてになってしまうからです。つまり、これは異なるタイプや場所にあるデータをまとめるのに本当に役立つんです。
3つ目の問題です。新しいデータソースや新しいLLM、あるいは新しいタイプのデータがあるたびにパイプラインを構築しているとしたら、例えば、ああ、画像を追加したから、今度は画像を動作させる方法を考えなきゃいけない。オーケー、動画だ、じゃあそれを考えよう。ドキュメントも入れたらどうだろう？オーケー、それも考えよう。それぞれが2週間から4週間のスプリントになります。そしてそのスプリントは、製品が実行可能かどうかを判断するために行われます。結局、2つのことが起こります。実行可能にするため、テストするために費やした労力の分だけ失敗し、最終的には本番環境に移行するのが非常に難しい寄せ集めのものができあがります。だから、すべてを捨ててゼロから始めなければならないんです。
では、ここで私たちは何をしているのでしょうか？パイプライン、RAGパイプラインをデータベースのセカンダリインデックスとして管理する方法を簡素化しようとしているんです。データベースに、ほら、データはここにあるよ、こういう風にパースしてほしい、これは画像だ、このパーサーを使ってパースしてほしい、あのLLMに行ってベクトル化して結果を保存してほしい、2時間かかるかもしれないけど、チェックするたびに進捗レポートをくれればいい、と伝えるだけです。準備ができたら、サーブできる状態にしてくれればいい。データを再インデックスしたい、インデックスタイプを変更したい、そうしたら新しいインデックスを作成して、インデックス間でABテストすればいいんです。RAGパイプラインを構築してABテストするんじゃありません。開発のイテレーション速度を速くするんです。
私たちがそれを実現している方法は、スライドにたくさんのクールなことが書いてあります。主に見ていただきたいのは、中央にあるものです。RAG extensionをRAGソーステーブルにインサートします。extensionにソースを渡すだけで、パイプラインを構築してくれます。パラメータを調整できます、どうチャンクするか、どうパーティションするか、いくつのチャンクを処理するか、そういったすべてのことです。シンプルにするんです。1行のSQLを使うだけで仕事を完了させます。専門的なものに投資する前に、まず動作することを確認してください。オーケー、できた。MVPができた。どうやって本番環境に移行しますか？
すべて私のラップトップで動いていて、マルチゾーンの高可用性環境で実行する必要があります、AWSかもしれないし、GCPかもしれないし、Kubernetesかもしれません。どうやってこれを動作させますか？まあ、それが私たちがやっていることの一つです。YugabyteDBは完全にオープンソースです。ラップトップで構築して、本番環境に持っていけます。そして、APIベースのエンドツーエンドのライフサイクル管理で管理をサポートします。RAGについて言えば、本番環境に入ったら、データ側で多くの管理が必要になります。なぜなら、もし軌道に乗れば、本当に軌道に乗るからです。急速に進みます。素早くスケールし、素早くスケールバックし、新しいインデックスを構築し、その場でテストし、といったことをしなければなりません。
プロトタイプから本番環境へ：ウルトラレジリエンスとマルチリージョン対応の実現
これを実現する方法ですが、ラップトップからこれらのあらゆるデプロイメント、マルチゾーン、マルチリージョン、マルチクラウド、ハイブリッドへと移行できます。これらはもはやバズワードではありません。実際に起きていることなんです。なぜなら、アプリケーションがますます重要になるにつれて、より一層レジリエントにしなければならないからです。そこには支払うべき代償と投資すべき労力があります。その労力を投資したくないですよね。ターンキーであってほしいわけです。ユーザーに「いいですね、戻ってきてスケールさせてマルチリージョンにしますよ。6ヶ月から9ヶ月ください」なんて言いたくないでしょう。彼らは待ってくれません。次のサービスに行ってしまいます。ですから、従量課金制であるだけでなく、より重要になるにつれてよりレジリエントにできるインフラストラクチャが必要なんです。これは重要なことです。
さて、タダのランチはありません。ですから考えなければならないのは、このカーブをどう進むかということです。アプリをよりレジリエントにするためにもっと支払う意思があるのか、それとも支払いを減らしてレジリエンスを下げる必要があるのか、そして理想的には労力をかけずにそれを実現できるかどうかです。
昔のチームは、大量のデータを扱っているとき、実際に私が話したあるチームがありました。このチームは何千ものデータベースをデプロイしていました。何千ものマイクロサービスとアプリケーションをサポートしていたからです。彼らが言うには、データベースのアップグレード、セキュリティパッチなどの一巡が終わるたびに、ほぼ6ヶ月が経過していて、もう二巡目をやる時期になっているということでした。その仕事がどれだけ楽しいか想像できますが、ソフトウェアにその仕事をやらせましょう。レジリエンスのレベルを表現するだけで、あとは誰かに任せればいいんです。
そこで私たちがやっているのは、多くの大企業と協力して、レジリエンスのさまざまな段階と、それに関連するコストとアーキテクチャを正確に伝えることです。私たちはこれをウルトラレジリエンスと呼んでいます。なぜなら、レジリエンスと言うと、皆さんのほとんどはマシンが故障したら別の場所で動作させようと考えていると思うんです。それも一部ですが、他にもたくさんあります。クラウド全体が停止したらどうなるか。例えば、アップグレードリクエストやセキュリティパッチが必要になったらどうなるか。ハードウェアが正常に機能しない場合、つまり故障はしないけれど正常に動作もしない場合はどうするか。グレーフェイルです。開発者が誤って本番環境のテーブルを削除してしまったらどうするか。
私はMetaで働いていたことがあるんですが、昔、こんな実際の事故がありました。インターンが来て言ったんです。「皆さん、本当にすみません、テーブルを削除してしまいました。300テラバイトでした。本番環境です。何か助けていただけますか?」まあ、ウルトラレジリエンスを導入していなければ、幸いにも導入していたんですが、古いテーブルを復元するのに10分で済みました。もしそうでなければ、みんなにとって悪夢のような一週間になっていたでしょう。そしてこれは意図的にやったわけではありません。速く動いているときは、ミスは起こるものです。そのレジリエンスを組み込むことが重要なんです。
そして、ピークイベントやフリークイベントについても同じことが言えます。私たちのユーザーの一つにParamount Plusがありますが、彼らがスーパーボウルの決勝戦やチャンピオンズリーグ、アカデミー賞、グラミー賞といった新しいコンテンツをリリースする際、どれだけの人がサインアップするのか本当にわからないんです。イベントの直前の1時間、どんなピークやフリークショーになるのか全く見当がつきません。なぜなら、予測できないからです。誰かが番組で誰かを叩いたら、みんなが即座にその番組を見ます。数件のツイートが出れば、みんながログインしてきます。そして私たちは認証・認可サービス、プロファイルサービスを提供しているので、瞬時にスケールする能力が必要なんです。これが現代のデジタルビジネスの本質なんです。
コンプライアンスについてですが、気づいているかどうかわかりませんが、ある国の企業が別の国の市民が利用するソフトウェアを第三国のデータセンターで運用している場合、多くの争いが起きていました。つまり、国1の企業が国2の市民に国3のデータセンターでサービスを提供する。データは誰のものなのか?これは難しい問題です。まあ、みんながそう考えて、「もういい。みんな自分の国にデータを保管しろ。自分の国の市民なら、自分の国に保管しろ」と言い出して、これが全面的に起きているんです。そしてこれはLLMでも起きています。自分の国なら、自分の国のLLMを使え。他のものは使いたくない、と。
つまり、個人データの扱い方について多くの規制が進んでいて、これをシンプルにしなければなりません。ユーザーにサービスを提供するためにアプリを構築するのにまた9ヶ月もかかるわけにはいきません。ですから、私たちはこれを透明でシンプルにし、Postgresをスーパーチャージするんです。
YugabyteDBのアーキテクチャと5つの重要ポイント：セキュリティとエージェント対応を含む包括的アプローチ
では、プロトタイプから本番環境に移行するために私たちは何をするのか?驚異的な運用のシンプルさを提供します。分散アーキテクチャとコントロールプレーン、そして組み込みのマネージドサービス提供。クラウド向けに構築されています。アーキテクチャ的に障害に耐えられるように構築されています。自動シャーディング、自動リバランシングにより、スケールが必要になったときに、どうすればいいか心配する必要がありません。自己修復機能により、障害などが自動的に処理されます。マルチAPIというのは非常に興味深いものです。私たちはPostgresだけでなく、Apache Cassandra、そして今はMongoもサポートしています。なぜなら、業界ではPostgresの上に他のAPIを構築する動きがあるからです。データベースの乱立を簡素化するために、Postgresの上でデータベースを模倣する傾向が進んでいるんです。
そして一貫性のあるPostgresです。100%標準のPostgresで、完全にオープンソースで、クラウドとKubernetesネイティブで、どこにでもデプロイでき、マルチクラウド、マルチリージョンなどに対応し、ゼロダウンタイムです。なぜNoSQLに移行するのか?スキーマ変更がゼロだからです。常にオンラインでいられます。まあ、今ではYugabyteDBを使えば、SQLでもNoSQLでもそれができます。そしてなぜPostgresに移行するのか?リレーショナル機能が得られ、エコシステムが付属し、多くの人々、多くのシステム、多くのソフトウェアがすでにPostgresを知っているからです。まあ、それも維持できるんです。
これは、私たちがどのようにお手伝いしているかを示す、ハイレベルな図のようなものです。
最上位のレイヤーは、PostgreSQLエコシステム自体を通じて起こっている、エミュレーション、エクステンション、そしてエコシステムで構成されています。中間レイヤーは、レプリケーション、フォールトトレランス、リバランシング、オートシャーディング、そしてパブリック、プライベート、マルチクラウド、ハイブリッドクラウドなど、あらゆるクラウドやインフラストラクチャ上で実行できる機能といった、クラウドネイティブな機能を処理する私たちのアーキテクチャです。私たちはPostgreSQLのクエリ処理エンジンを再利用しており、PostgreSQLがどのように進化しているかを考えると、私たちはPostgreSQLの上に構築することで、皆さんのAIパイプラインがよりシンプルになるようにしているのです。
ここには5つの重要なポイントがあります。まず、テックスタックを進化させ、 標準に従うことです。PostgreSQLだけの話ではありません、私がそれについて話しているとはいえ。覚えておいてください、標準的な形とコンポーネントがあれば、反復するのがはるかに簡単になります。カスタムなものを構築すると、反復するのが非常に困難になります。ですから、フレームワークを整備し、改善を測定できるようにし、指数関数的な成長に向けて反復していってください。
2つ目はデータの多様性です。何が変わったかというと、互いに関係がないはずのデータが、今では互いに関係を持つようになったということです。それらは隣り合って存在しています。時には大量のデータを移動しなければならないこともありますし、別の時にはデータを移動したくないこともあります。手作業でやるようなことはしないでください。フレームワークの中で、より標準的なものにするようにしてください。
3つ目は、パイプラインを手作業で構築しないことです。すべての実験が手作業のパイプラインのような作業になってしまいます。実験のための作業はしないでください。実験し、本番環境に移行し、本当の教訓を学び、そして投資対効果がわかった後に、やるべきことを何でもやってください。
4つ目は、もしプロダクションに移行できない場合、そしてプロダクションに移行した後に大胆に実験できない場合、実際には何も解決していないということを覚えておくことです。ラップトップ上で動作させることはできたかもしれませんが、その後はどうなるのでしょうか？多くの苦労を経て初めてプロダクションに投入しましたが、その後はどうなるのでしょうか？これを毎回、常にできるようにしなければなりません。なぜなら、1年後にどうなっているかは誰にもわからないからです。
そして最後に、運用面のことが邪魔にならないようにしておくことです。素晴らしいものを構築して反復作業をしているときに、突然Heartbleedのようなセキュリティバグに見舞われてOSパッチを適用しなければならなくなったり、新機能が欲しいのに多くのものをアップグレードすることに縛られたり、障害が発生して後始末に追われたりするのは避けたいですよね。基本的なことを最初に片付けておくようにしてください。開始時点でインフラストラクチャがプライムタイムに対応できる状態にしておくべきです。もちろん、過剰な費用を支払うべきではありませんし、それに合わせて設計する必要もありませんが、比較的容易に必要な場所へ連れて行ってくれる準備ができているべきです。
繰り返しになりますが、ここでの私たちのアプローチは、最初からデータをセキュアにバイデザインで保つことです。そして、生成AIの世界においてもセキュリティをさらに強化することができます。それでもセキュリティに対処しなければなりません。オブザーバビリティを持てるようにする必要があります。データがどこから来ているのか、特定のロールがそのデータを認可できるのかを言えるようにすべきです。これらすべてのセキュアなデータがあり、データベースとアプリケーションにロールベースのアクセス制御をすべて設定しました。しかし、もし私があなたのRAGやMCPサーバーにアクセスして、とても丁寧に「要約してください」と頼んだら、すべての機密データの非常にきれいな要約を提供してくれるでしょう。そのような状況に陥りたくはありませんよね。ですから、これらは事前に考えなければならないことであり、生成AIであろうとなかろうと、構築している人々と一緒に取り組んでいる問題なのです。
組み込みの暗号化と監査ログは基本的なものの一部です。これらを片付けなければなりませんし、必要なときにダイヤルを上げ続けなければなりません。エージェント的なデータベース操作は重要です。エージェントがデータベースに接続したときに何をするのでしょうか？データベース担当者のバージョンをお伝えしましょう：データベースが死ぬまで、そしてすべてのトークンが使い果たされるまで、同じことを何度も何度も尋ねてデータベースを徹底的に叩きます。そんなことは起こってほしくないので、データベースがエージェント的な操作を理解できるようにしたいのです。ですから、これらは私たちが取り組んでいることの一部です。
そして最後に、きめ細かいアクセス制御が完全に復活しています。なぜなら、人間がサービスアカウントを通じて行動し、それがMCPサーバーであり、それが今度はデータベース上で操作しているからです。ですから、対処しなければならない複数レベルのサービスアクセスと制御があり、PostgreSQLは素晴らしい仕事をしています。私たちがやっていることは、簡単にインターフェースできるようにお手伝いすることで、それを次のレベルに引き上げているだけです。
それでは、これらが私たちのユースケースの一部です。繰り返しになりますが、かなり横断的なものです、RAGのユースケース、レコメンデーションシステム、ナレッジベース、オペレーションやトランザクションシステムを実行するエージェントなど、様々なものがあります。もっと詳しく知りたい方は、ぜひ私たちに声をかけてください。ブース1436にいます、確か1436だったと思います。もし違っていたら、Yugabyteと覚えておいてください、検索してみてください。オンラインでもあちこちにいますし、紫色のシャツを着た人を探してください。質問があれば、バックステージのすぐ後ろでお会いしましょう。ありがとうございました。それでは、Karthikに大きな拍手を。ありがとうございます。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion