※本記事は、Francis Flannery氏(AWS Principal Solutions Architect)、Aris Tsakpinis氏(AWS Sr WW Specialist SA GenAI)、Somu Perianayagam氏(AWS Sr. Principal Engineer)による「AWS AI and Data Conference 2026 - Project Mantle in Amazon Bedrock」の内容を基に作成されています。本セッションは、2026年3月12日にアイルランド・キルケニーのLyrath Convention Centreで開催された第5回AWS AI and Data Conference 2026にて収録されたものです。動画の詳細情報は https://go.aws/events でご覧いただけます。本記事では、セッションの内容を要約しております。なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご視聴いただくことをお勧めいたします。
1. Agentic AI時代への変遷と失敗リスク
1.1 登壇者紹介とRPAからChatGPTへの転換
Francis： 私はAWSのプリンシパルソリューションアーキテクトとして、このAI and Dataカンファレンスには3年連続で登壇しておりまして、その前のコークでの開催も含めますと4年間このイベントに関わってきました。本日はAmazon Bedrockのworldwide specialistチームのAris、そしてBedrockのサービスチームに所属するSomuと一緒に、Bedrockがどのような設計思想のもとに構築されているのか、その舞台裏をお見せしたいと思います。
Francis： まず時間を巻き戻して、生成AIが存在しなかった時代の話をさせてください。当時、業務の自動化はロボティック・プロセス・オートメーション、いわゆるRPAによって行われていました。しかしこの手法には大きな課題がありました。自動化を組み上げるために人手による多大な労力が必要で、しかも非常に壊れやすい仕組みだったのです。UIが変更されたり業務プロセスが変わったりするたびに自動化が壊れてしまい、そのたびに追加の作業が発生していました。
Francis： そして2022年11月、世界が変わりました。ChatGPTがリリースされたのです。これにより人々は、自然言語を使って意図を伝え、タスクを実行させられることに気づきました。それが2022年の出来事です。
1.2 RAG・エージェント台頭からAgentic Systemsへ
Francis： 続く2023年から2024年にかけては、モデルの活用方法そのものが進化しました。Reason and Actionの考え方や、プランニング、そして自分たちのデータをモデルに持ち込むためのRetrieval Augmented Generation、いわゆるRAGが登場しました。さらに2024年から2025年にかけては、モデル自体の性能が向上したことでエージェントが台頭してきました。単一のタスクをこなすだけでなく、複雑な多段階の推論を積み重ねられるようになったのです。そして今、私たちは2025年以降のAgentic Systemsの時代に入っています。これは人間とエージェントが協働する時代であり、エージェント同士が対話し、人間とエージェントが対話しながらスケールを実現していく世界です。
1.3 モデルのコスト対知性とオープンウェイトモデルの台頭
Francis： こうした進化の土台となっているのがモデルそのものです。モデルの実行コストと知性の関係を示すグラフを見ますと、多くの方はグラフの右上にあるフロンティアモデルばかりに注目しがちですが、実際にはさまざまな知性とコストのポイントに位置するモデルが幅広く存在しており、ユースケースに応じてそれらを検討すべきです。たとえば上位に位置するGLM5やKimi K2.5はいずれもBedrockで利用可能なオープンウェイトモデルです。オープンウェイトモデルとは、自分たちで学習やファインチューニングを行えるモデルのことを指します。ここで重要な気づきとして、プロプライエタリモデルとオープンウェイトモデルの間の差が縮まってきているという事実があります。数年前にはオープンウェイトモデルでは実現できなかったことが、今では実現可能になっているのです。
Francis： そしてこれはモデル単体の話にとどまりません。ツールやフレームワークの領域でも爆発的な進化が起きています。具体的には、モデルの性能はおよそ6か月ごとに倍増しており、これに伴ってエージェントがこなせるタスクの複雑さもおよそ7か月ごとに倍増するという傾向が見られます。これはモデルだけの話ではなく、フレームワーク、オブザーバビリティ、サンドボックス化、そして設計思想全体に関わる話です。
1.4 Agenticプロジェクト失敗の3大要因
Francis： この点について、AWSのディスティングイッシュトエンジニアであり、Somuのチームにも所属するJoe Magmoffの個人ブログが非常に良い事例を示しています。彼はAIを使ってAIサービスを構築していく過程を綴っており、その中で明らかになったのは、モデルを活用することでコードの生産量は大幅に増える一方で、それ以外のあらゆるプロセスが機能しなくなってしまうという点です。開発の仕方、テストの仕方、チームの協働の仕方そのものを変えなければならないのです。
Francis： この変化に対応できなければ、多くのAgenticプロジェクトは失敗に終わります。Gartnerの予測によれば、2027年までにAgenticプロジェクトの40%が失敗するとされています。その要因として挙げられているのは、コストの超過、ビジネス価値が明確でないこと、そしてリスクとセキュリティに関する課題の3点です。
Francis： それでは、こうした課題に対してBedrockがどのように応えられるのか、Arisにバトンを渡したいと思います。
Aris： ありがとうございます、Francis。40%のプロジェクトが失敗する可能性があるというお話でしたが、なぜそうなるのか、そしてそれをどう乗り越えて組織の中でAIを本番環境へと成功裏に導入していけるのか、一緒に見ていきましょう。
2. AI統合の複雑性とBedrockの設計思想
2.1 シンプルなAPI呼び出しの理想と現実のギャップ
Aris： まず非常にシンプルなところから始めたいと思います。ソフトウェアスタックにAIを統合するというのは、根本的にはどのような形になるのか、一緒に見ていきましょう。最初のうちは本当にシンプルに見えます。皆さんのソフトウェアスタックがあり、boto3のようなライブラリやフレームワークをインポートして呼び出しを行う。モデルが応答を返してきて、それをソフトウェアスタックに戻す。それだけです。しかし、本当にそんなに単純なのでしょうか。私たちは皆、これを経験してきたと思いますが、実際にはまったくそうではありません。ガードレールやセキュリティについても考えなければなりませんし、私たちが構築しているアプリケーションはどんどん複雑になっています。
Aris： 私たちはエージェントを構築しており、それらは推論を行います。単なる同期的な短い呼び出しではなく、RAGやツールから動的にデータを引き込んでいます。つまり、当初は3行の同期呼び出しだったものが、モデル、エージェント、メモリといった要素だけでなく、デプロイメント、評価、本番環境でのモニタリングといった、フレームワーク全体を必要とするものへと進化しているのです。
2.2 オーケストレーション問題とプロトタイプ・本番間の溝
Aris： そうなると、私たちは複雑なオーケストレーションの問題に直面することになります。タスクが並行して実行され、複数の実行にまたがって状態を監視しなければならず、その他にも並行して対処すべきことが数多く出てきます。まさにこの点において、多くのエンジニアリングチームが苦労しているのを目にします。特にPoCを構築する段階だけでなく、本番環境へ移行する段階でつまずくのです。AWSではこれを「プロトタイプから本番への溝」と呼んでいます。これはまさに、この会場にいる多くの方が経験されてきたことを言い表していると思います。PoCの段階はいつも刺激的で、デモも見栄えが良く、経営層もすぐに乗り気になります。しかし、それを本当にビジネス価値へとつなげるために本番環境へ移そうとした瞬間、私たちエンジニアは厳しい課題に直面することになります。パフォーマンスへの配慮が必要になりますし、ビジネスクリティカルなアプリケーションであれば本番環境で失敗するわけにはいきません。スケーラビリティの面でも、本番環境ではトラフィックの急増に対応しなければなりませんし、ユーザー数もPoCの段階とは比較にならないほど多くなります。セキュリティについても、私たちの組織は一切妥協することができません。そして、半自律的、あるいは完全に自律的に動作するエージェントをどのようにガバナンスするかという課題も出てきます。
2.3 Bedrockの5つの設計原則
Aris： 幸いなことに、私たちAWSは、お客様がこうした課題について過度に思い悩む必要はないと考えていますし、そうあるべきではないとも考えています。むしろ、それらを私たちが引き受けることこそが私たちの使命の一部であり、それによってお客様にはビジネスにとって最も差別化につながる領域、つまり本来注力すべき分野でのイノベーションに集中していただきたいのです。基盤となるインフラについてあまり深く考える必要がないようにする。では、私たちはBedrockにおいて実際にこの課題にどう取り組んできたのでしょうか。それはBedrockの歩みの非常に早い段階から、意図的な意思決定として存在していました。クラウドインフラとその周辺サービスの構築における15年以上の経験の中で、私たちはこうした課題の多くを早い段階から見通しており、単なるシンプルなモデルAPIではなく、より包括的なプラットフォームを構築するという意図的な決断を下しました。それはお客様が本番環境への移行を確実に成功させられるよう、規模に応じてこれら多くの課題に対応するものです。
Aris： この決断は2023年春に行われ、私たちはBedrockを5つの設計原則に基づいてサービスとして根本から築き上げることを決めました。1つ目はモデル選択です。これについては既にお話ししましたように、特定のモデルにロックインされることはなく、選択の自由があります。2つ目は開発者体験です。これは開発者にとって快適であるだけでなく、結果として本番環境への迅速な移行にもつながる重要な要素です。3つ目はパフォーマンスです。レイテンシやスループットをはじめ、本番ワークロードが必要とする適切なパフォーマンス指標を常に備えていることを意味します。4つ目はグローバルフットプリントです。世界中に広がるさまざまな要件に応えながら、お客様が世界中の顧客にサービスを提供できるようにすることです。そして5つ目が、常に非常に重要となるセキュリティ、安全性、責任あるAIです。これは後付けの要素ではなく、ファーストパーティの設計原則として位置づけています。これから30分ほどの時間で、SomuとArisの2人で、これら5つの柱にわたって私たちがどのように革新を続けているのか、そしてそれが皆さんがBedrockという基盤の上に何かを構築していく上で実際にどのような意味を持つのか、順を追ってご説明していきたいと思います。
3. モデル選択とプラットフォームの技術的課題
3.1 モデル選択の思想と判断基準
Aris： それでは1つ目の設計原則であるモデル選択についてお話ししたいと思います。これは私たちにとって最も重要なものの1つです。ごく早い段階から、私たちは「世界を支配する唯一のモデル」というものは存在しないと考えてきました。そうではなく、柔軟性を提供することが重要だと考えたのです。特定のタスクや、あるいは包括的なユースケースに対して、最良のモデルを選択できるようにすることです。では、実際に今日のBedrockにおいてモデル選択とはどのようなものでしょうか。現在、Bedrockでは十数社を超えるモデルプロバイダーから提供される数百種類ものモデルの中から選択することができます。これは素晴らしいことですが、では実際にお客様はどのようにモデルを選んでいるのでしょうか。これだけ多くのモデルがある中で、タスクに最適なモデルをどう選べばよいのか。そこにはさまざまな判断要素が影響しています。おそらく最もよく挙げられる3つの要素は、まず品質です。これは当然ながらモデルがタスクをきちんとこなせるかどうかです。次にコストです。私たちは皆ビジネスを行っている以上、いずれ誰かがROIを問うことになります。そしてレイテンシです。なぜならこれは、私たちが構築している多くの生成AIアプリケーションにおいて、ユーザー体験と直接的に相関することが分かってきているからです。
3.2 新モデルの高頻度リリースと選定の継続性
Aris： そして、これは一度きりのことではなく、継続的なプロセスです。アプリケーションの開発を始める段階だけでなく、それを運用していく段階でも常に行うことになります。なぜなら、この分野でのイノベーションのペースはまさに前例のないものであり、新しいモデルが次から次へと登場してくるからです。では、これほど多くのモデルを同時にお客様にサポートし続けるために、エンジニアリングの側では実際に何をしているのでしょうか。
Somu： それは非常に良い質問ですね、Aris。私はBedrockチームのエンジニアで、Somuと申します。今日は私1人の仕事ではなく、多くのエンジニアリングチームが取り組んできた成果についてお話しします。Arisが言った通り、モデル選択の大きな部分は、お客様が求めるすべてのモデルを提供できることにあります。コスト効率が良いモデル、精度が高いモデル、レイテンシが異なるモデルなど、お客様はさまざまな観点から自由に選びたいと考えているからです。しかし、プラットフォームレベルでこの選択肢を実現することには、独自の課題があります。まず何よりも大きな課題は、イノベーションのスピードです。ほんの数年前まではチャットボットがLLM推論の最も一般的なユースケースで、単発のプロンプトが主流でした。しかし今では、過去60日だけを見ても信じられないペースで新しいモデルがリリースされています。過去3か月だけでもAnthropicから5つのモデルが登場し、さらに十数種類のオープンソースモデルをローンチしなければなりませんでした。そしてFrancisが述べたように、私たちは単発のプロンプトから、より推論やツールコールを伴うエージェント的なフレームワークへと移行しつつあります。話題になる新しいモデルが登場するたびに、それを統合しなければならない開発者がいるわけで、これは開発者にとって大きな負荷になります。加えて、なぜ新しいモデルに移行しなければならないのかという問いもあります。私自身はBedrockに来る前はデータベースの世界にいましたが、データベースの世界では物事が非常にゆっくりと進み、バージョンアップも慎重に行われるものでした。しかし新しいモデルが次々と登場する今、人々はできる限り早く新しいモデルに移りたいと考えます。モデルが次々に登場する中で、それらをどう立ち上げ、どう使い始めればよいのか、開発者としては目まぐるしい状況です。そして、モデルを利用する側のお客様も、モデルプロバイダー自身も、自分たちのペースで動けるプラットフォームを求めています。モデルプロバイダーは毎月のように新しいモデルをリリースしたいと考えており、私たちも当然それに追随してモデルを提供していきたいと考えています。さらに、あらゆる開発者、あらゆるアプリケーション、あらゆるエンタープライズが、新しいモデルのためのキャパシティも求めています。つまり、単に追いつくということ自体が、もはや戦略ではなくほぼフルタイムの仕事になっているのです。
3.3 インターフェースの断片化とキャパシティのサイロ化
Somu： なぜこれほど難しいのか。それは、これらのモデルの多くが異なる「言語」を話しているからです。同じAPIを話しているわけではありません。Messages APIをサポートするClaudeのようなモデルもあれば、Responses APIをサポートするOpenAIのモデルもあります。まるで異なる時間に異なる相手と会話しているようなものです。そのため、プラットフォームレベルですべてのモデルと対話するための単一の標準インターフェースが存在しないという状況は、非常に大きな課題になります。しかもセマンティクスも異なります。例えば推論の扱い方は、OpenAIのResponses APIとChat Completions API、そしてMessages APIとでまったく異なりますし、ツールコールのような概念についても違いがあります。こうしたインターフェースの氾濫が、高いペースでモデルをオンボーディングしていくことを非常に難しくしているのです。
Somu： さらに難しいのは、それぞれのモデルプロバイダーが独自のホスティングソリューションを持っているという点です。これは、すべてのモデルがよりエージェント的なループへと移行してきている今、非常に重要な問題になっています。ツールコールや推論など、さまざまな処理を行うために複数のマイクロサービスが内部で連携しており、そのオーケストレーションのフレームワークもプロバイダーごとに大きく異なります。つまり、それぞれが独自のホスティング戦略を持ち、要件も大きく異なるということです。あるモデルは推論のためにより多くのメモリ帯域幅を必要とする一方、そうでないモデルもあります。エージェント的なワークフローをサポートするために別の要素が必要なモデルもあります。ランタイムも実行パスもプロンプトや出力のスタイルもそれぞれ異なるため、結果としてキャパシティが分断されてしまいます。プロバイダーとしてモデルをホスティングし始めると、モデルごとにキャパシティをサイロ化せざるを得なくなるのです。例えばモデルAとモデルBという2つのモデルがあったとして、モデルBの採用が進んで非常に高い負荷がかかっている一方、モデルAには余剰キャパシティがあったとしても、それを簡単に融通することができません。つまりキャパシティが分断されてしまっているのです。
3.4 ツールコール時の非効率性と運用の複雑性
Somu： もう1つの課題は、ツールコールなどの導入に伴う非効率性です。ツールコールが発生すると、モデルは処理を止めて何もしない状態になってしまいます。具体的には、プリフィルを行い、生成を行い、ツールコールを発行し、その結果が返ってくるのを待ち、それからまた生成を行い、再びツールコールを発行し、さらに生成を行う、といった具合です。そして最終的に、Web検索やMCP呼び出しを行った場合のプロンプト出力が得られます。最後に、こうしたモデルの運用の複雑さも大きな課題です。モデルのデプロイやモニタリングは、ホスティングプラットフォームとして私たちが対処しなければならない非常に大きな課題でした。しかし、これはスケールの面で行き詰まっていたわけではありません。採用は非常に好調で、お客様はLLMの活用に本当に満足してくださっていました。そこで2025年半ば、私たちは第一原理に立ち返って考える必要があると判断しました。もし分散推論エンジンをゼロから構築するとしたら、どのように作るべきか、と。
4. Project Mantle:分散推論エンジンの刷新
4.1 第一原理からの再設計とローンチ経緯
Somu： 先ほどお話ししたように、Bedrockのスケールそのものが行き詰まっていたわけではなく、採用は非常に好調で、お客様はLLMの活用に本当に満足してくださっていました。それでも2025年半ば、私たちは第一原理に立ち返って考える必要があると判断しました。もし分散推論エンジンをゼロから構築するとしたら、どのように作るべきか、と。そうして昨年のre:Inventで私たちがローンチしたのがMantleです。Mantleが何をするかというと、先ほど挙げたような課題の数々を乗り越えるものであり、その中の重要な要素の1つがインターフェースの標準化です。
4.2 インターフェース標準化
Somu： 私たちがモデルと対話するために使うインターフェースを標準化しました。イメージとしては、トークンを入力してトークンを出力するという、単一の標準的なやり取りだと考えていただければと思います。これによって、モデルをより簡単にローンチできるようになりました。というのも、インターフェースに変更が生じないため、新しいインターフェースセットをサポートするために新たなコードを開発してデプロイする必要がなくなったからです。また、モデルのインターフェースが標準化されたことで、ハードウェアをまたいで1つのモデルから別のモデルへと切り替えることが容易になり、キャパシティを効率的に利用できるようにもなりました。
4.3 AIによるAIのための開発体制
Somu： 最後に、これはFrancisも触れていたことですが、Mantleは人手ではなく、AIによってAIのために構築されたという点も重要です。コードの多くはネイティブなAI開発によって書かれました。これは非常に興味深いプロジェクトで、約10名のエンジニアが76日間で、構想から本番稼働までこのサービスを立ち上げました。
4.4 キャパシティプール統合の効果
Somu： 私たちはこの仕組みによって、すべてのオープンソースモデルのプールを統合することができるようになりました。2つのモデルが稼働している場合、それらはプールを共有する形になり、一方のモデルの負荷が高くなっても、もう一方のプールからキャパシティを融通できるようになりました。つまり、もはやキャパシティがサイロ化することはなく、これによって私たちの運用は格段に楽になり、お客様にとってもキャパシティの確保が容易になりました。Mantle上で稼働するモデルについて言えば、キャパシティは標準で1億TPM、そして1万RPMという規模を最初から提供できています。これが可能になっているのも、キャパシティとモデルを柔軟に、そして容易に融通し合えるようになったからです。
5. 推論リクエストの進化と開発者体験
5.1 ステートレスからステートフルへの変化
Somu： 私はもともとDynamoDBの世界の出身で、そこではWebサーバーやリクエストは非常に定型的なものでした。毎秒数百万件のリクエストを、非常に予測可能なレイテンシで処理できる。この「予測可能」というのが重要なキーワードで、実は数年前の推論の世界でも同じことが言えました。2023年当時、推論はステートレスでした。チャットボットを使い、ステートレスな推論を行う。入力を与えれば出力が返ってくる、それだけです。しかし、推論リクエストはその頃から大きく進化しています。もはや単なるWebサービスやWebリクエストとは言えません。単一の推論リクエストが行っていることが格段に増えているからです。1回の推論リクエストの中に、実に多くの要素が組み込まれるようになりました。多くの推論リクエストにはメモリが関わってきますし、モデルに戻ってくるツールコールも行われ、モデルはそのツールコールの結果を使ってさらにプロンプトを生成します。つまり再帰的な性質を持つようになったのです。同様に、実行にかかる時間もかつてのように数秒で終わるものではなくなりました。
Somu： そのため、私たちは非同期リクエストをサポートする必要が出てきました。お客様がリクエストを送信し、出力を待つという能力です。皆さんの中でコーディングエージェントを使っている方はどれくらいいらっしゃいますか。おお、たくさんの方が手を挙げてくださいましたね。コーディングエージェントというのは時間がかかるものです。仕様を入力すると、Kiroのようなエージェントはしばらく考え込み、それから要件定義書や設計ドキュメントを出力してきます。つまり実行そのものが非同期になり、そこには多くの推論も伴うようになったということです。これはつまり、2023年当時に機能していたAPIの在り方が、2026年には通用しないということを意味します。1回のリクエストに関わる要素があまりに多くなり、リクエストは決して画一的なものではなくなったからです。従来型のWebサービスリクエストとはもはや呼べません。ですから、プラットフォーム自体が、こうした非伝統的なリクエストの形をサポートしていく必要があるのです。それでは、APIと顧客体験について、私たちがどのように考えているか、Arisからお話しいただけますか。
5.2 Invoke Model APIからOpenAI互換APIへ
Aris： はい。私たちが行っていることはすべて、お客様を起点に逆算して考えています。なぜこうした変化が起きているのかを突き詰めていくと、それは私たちが構築しているアプリケーションの性質そのものが、よりステートフルなものへと変化してきているからだということに行き着きます。つまりAPIも、それに合わせて進化しているのです。これによって開発者、つまり私たちのお客様にとって構築しやすい形になっていく。開発者体験は2つ目の柱として非常に重要な位置づけであり、私たちはここに継続的に投資を続けています。この会場にいらっしゃる開発者の皆さんも、なぜこれが重要なのか、きっと共感していただけると思います。
Aris： これを具体的に示すために、Somuが挙げた推論リクエストの性質という例を引き続き使いながら、過去3年間でこれがどう進化してきたかをご説明したいと思います。2023年にBedrockをローンチした際、私たちはInvoke Model APIという、比較的低レベルでシンプルなAPIとともにスタートしました。推論パラメータとプロンプトをまとめたJSONを組み立て、それをモデルに投げるだけです。応答もJSONで返ってきます。非常にシンプルでした。しかし、Bedrockに組み込まれるモデルが増えていくにつれ、開発者は抽象化を通じた安定性を求めるようになりました。つまり、一貫したAPIによって、Bedrock内であるモデルから別のモデルへ大きな手間をかけずに移行できるようにしたいというニーズです。これは推論だけでなく、ツールコールなど新たに登場してきた機能についても同様でした。そこで私たちはConverse APIをローンチしました。これはまさに、Bedrock内のすべてのモデルに対する推論やその他の側面を統一的に扱う単一のインターフェースです。しかし、それだけでは終わりませんでした。開発者が求めていたのは、Bedrock内の異なるモデル間の一貫性だけではなく、モデル推論を利用する際に使用しているBedrock以外のさまざまなプラットフォームをまたいだ一貫性でもあったのです。
Aris： そこで、Somuが先ほどご紹介した新しい推論環境であるMantleによって実現された形で、私たちは最近、まったく新しい2つのAPI、すなわちOpenAI互換APIをローンチしました。OpenAIの仕様であるChat Completions APIとResponses APIを実装したもので、これは皆さんの多くがすでに大きく投資してこられたAPIかもしれません。これはドロップイン・リプレイスメントとして機能し、コードの変更を最小限に抑えながら、アプリケーションをそのままBedrockに移行できるというものです。
5.3 既存ツールとの互換性と移行の容易さ
Aris： これによって得られるのは、5つの柱すべてにわたる将来性とイノベーションです。エンタープライズグレードの環境をそのまま活用しながら、アプリケーションを単純に移行するだけでホストできるようになります。とはいえ、互換性というのは単にAPIだけの話ではありません。私たちは日々、他にも数多くのツールやフレームワークを利用しています。この2つの新しいAPIの最も強力な側面の1つは、皆さんが今日すでに利用しているツールやフレームワークのエコシステム全体と、Bedrockがいかにシームレスに統合されるかという点にあります。LiteLLMのようなLLMゲートウェイを使っている場合でも、人気のオープンソースのオーケストレーション・エージェントフレームワークを使っている場合でも、さらにはこれらのAPIを基盤に構築されたクローズドソースのツールも数多く存在します。Bedrockへの移行がこれほど容易になったことはこれまでありませんでした。私たちは皆さんにこれまで築き上げてきたものを何も捨ててほしいとは思っていません。むしろ、皆さんが今いる場所に私たちの方から合わせに行くという考え方です。
Aris： どれほど簡単かをお見せするために、1つ例をご用意しました。OpenAI SDKを使ってモデルを呼び出す数行のコードです。Bedrockに移行するために変更が必要なのは5行目と6行目、たった2行だけです。当然Bedrockを指す別のベースURLを指定する必要がありますし、APIキーも変更する必要があります。それでたった2行です。それほど複雑なものではありません。しかし、このたった2行のコードによって得られるものは非常に大きく、モデル選択、セキュリティ、スケーラビリティ、グローバルなスケールなど、これらすべての柱をそのまま享受できるのです。私はこれが非常に大きな意味を持つと考えています。なぜならそれは、イノベーションが通常AWSの中で起きるだけでなく、オープンソースなど別の場所でも起きているということを意味するからです。つまり、そのイノベーションをどこであろうと試すことができ、もし気に入って、最小限の労力で動作するのであれば、エンタープライズグレードのBedrockへと移植し、本番環境のアプリケーションでその価値を活用することができるのです。
5.4 OpenAIとの戦略的パートナーシップ
Aris： これによってBedrockは、あらゆるエージェント的なワークロードにとっての自然な拠点になります。そしてこれが、私たちが発表したもう1つの非常にエキサイティングな話題につながります。たしか先週か2週間前だったと思いますが、AmazonとOpenAIの間で複数年にわたる戦略的パートナーシップが発表されました。これはすべて、私たちがOpenAIと共同で構築している、いわゆるステートフル・ランタイム環境と呼ばれるものに関わっています。これらはOpenAIのモデルによって動作し、Bedrockを通じて提供される予定で、現在も開発を進めているところです。
Aris： ステートフル・ランタイム環境とは何かと疑問に思われる方もいらっしゃると思いますので、簡単にご説明します。これは基本的に、アプリケーションの性質が変化してきたのと同じ道筋をたどっています。つまり、推論リクエストがステートレスからステートフルへと変化してきたのと同様に、ランタイム環境についても同じことが起きているのです。長時間実行されるタスクを実行する際にコンテキストを保持し続けるランタイム環境であり、そのためTrainiumのようなモデル向けのインフラや、AgentCore、その他のAWSインフラサービスといったインフラコンポーネントと統合されます。これにより、皆さんは現在AWS上ですべてのワークロードを実行している環境の中で、エージェント的なワークロードをステートフルな形で実行できるようになります。こうして、お客様がすでに信頼している安全でスケーラブル、かつエンタープライズグレードのプラットフォームを通じて、フロンティアAIの能力を改めて皆さんにお届けすることになるのです。
6. パフォーマンスの柱とワークロード管理
6.1 当初の仮説とAdmission Controlの限界
Aris： 私たちはモデル選択について、開発者体験について、そしてエキサイティングな新しいパートナーシップについてお話ししてきました。これらはすべて、私たちが作り上げてきたプラットフォームの一部です。しかし、こうしたプラットフォームを構築することは、話の半分に過ぎません。もう半分は、お客様が本番ワークロードにおいて必要とする水準で、実際にパフォーマンスを発揮できるようにすることです。では、お客様のこうした期待にどのように応えているのか、Somuに聞いてみましょう。
Somu： 良い質問ですね。私がBedrockに来て最初に取り組んだ課題の1つが、お客様がスロットリングされてしまうという問題でした。お客様をスロットリングさせるべきではない、と言われたのです。私は最初、これはキャパシティの問題だと考えました。しかし、それは少し間違っていました。今日、Bedrockを支えているのは大規模な推論ワークロード管理システムです。その理由は先ほどと同じで、これはもはや単一のWebサービスリクエストではないということです。アドミッションコントロールだけでは十分ではありません。お客様がBedrockから最大限のパフォーマンスを引き出せるようにするには、アドミッションコントロール以上の仕組みが必要なのです。
Somu： そこで私たちはアドミッションコントロールシステム、スケジューラー、そしてトレンド分類器を用意しました。なぜかというと、ワークロードにはさまざまな種類があるからです。今日ではワークロードは単一の種類ではありません。チャットボットのようなレイテンシに敏感なワークロードがあり、これらは即座に推論結果を返してもらう必要があります。即座の満足以外に選択肢はありません。次に要約のようなワークロードがあります。これは6分から7分待つことができるものです。お客様の中には、即座の結果は求めていない、リクエストを保持しておいて、キャパシティが空いたときに処理してくれればよい、という方もいらっしゃいます。それが要約系のワークロードです。さらにバッチワークロードを抱えるお客様もいます。大きなワークロードをBedrockに載せたいが、オンデマンド推論を使わずにどう載せればよいか、というものです。
Somu： このようにワークロードの種類が異なることに私たちは気づきました。DynamoDBの世界から来た私たちにとって、アドミッションコントロールは良い解決策に思えました。まずはアドミッションコントロールから始めたのです。具体的には、レイテンシに敏感でないワークロードには、レイテンシに敏感なワークロードよりも小さいキャパシティを割り当てるという方法を取りました。しかしこのグラフをご覧いただくと分かる通り、縦軸はフリートの使用率、横軸は時間です。これはうまく機能していました。すべてのオンデマンドリクエストは問題なく処理されていたのですが、あるとき、小さなバッチワークロードがフリートの使用率を100%をわずかに超えるところまで押し上げてしまい、そこからオンデマンドとバッチの両方のリクエストが無差別にスロットリングされ始めてしまったのです。本来であればバッチは4時間かけて分散させることもできたはずなのに、それがわずか2時間の中に集中してしまいました。これは決して良いお客様体験とは言えませんでした。ですから私たちは、オンデマンド推論リクエストを送るお客様には、良い体験をしていただけるようにする必要があったのです。
6.2 スケジューラーと分類器による解決
Somu： 次に直面したのは、Bedrockをローンチした当初、まだチャットボットやLLM推論が主流だった頃の話です。当時私たちは、リクエストは非常に均一なものになるだろうと考えていました。すべて同じようなものになるだろう、と。実際、大部分についてはその通りで、数秒の誤差の範囲に収まっていました。しかし現実には、リクエストはもはやそのような均一なものではなくなっています。リクエストの処理時間は、そのリクエスト自体が何を行っているかによって変わってきます。入力コンテキストが長いリクエストは数秒かかることもありますし、推論を行うために出力がより大きくなるリクエストもあります。さらに、ツールコールを行い、その結果を取得し、それを踏まえてまた処理を続ける、といった大規模なリクエストも存在します。つまりリクエストは多様化しているのです。
Somu： リクエストごとにかかる時間が異なるということは、アドミッションコントロールだけでは不十分だということを意味していました。なぜなら、ワークロードがどのようにパフォーマンスしているかを追跡する仕組みがなかったからです。ワークロードが異なればレイテンシも異なりますし、それをコストの観点でどうインセンティブ設計するかという課題もありますが、まずはスケジューラーの問題をどう解決するかが重要でした。そこで現在、Bedrockには非常に高度なスケジューラーが備わっており、ワークロードの種類に基づいて優先順位付けを行えるようになっています。これが皆さん、この会場にいらっしゃるエンドカスタマーの皆さんにとって何を意味するかと言いますと、このスケジューラーは、モデルの背後にあるキャパシティの状況と、お客様から送られてくる受信リクエストの状況の両方を踏まえて、インテリジェントなスケジューリングの判断を下せるということです。
Somu： しかし、これだけではまだ十分ではありませんでした。というのも、重要な点として、非常に予測可能なワークロードというものが存在するからです。例えば、1日を通してオンデマンド推論リクエストを送り続けるお客様もいれば、毎時の終わりにまとめて要約リクエストを送るお客様もいます。こうした予測可能なジョブと、異常なトラフィックとを区別する必要があります。なぜなら異常なトラフィックは、予測可能なトラフィックがすでに使用していたキャパシティを奪ってしまう可能性があるからです。そこで私たちは、予測可能なトラフィックがその良い振る舞いに対してきちんと報われるようにしたいと考えました。そのために、過去数週間、数か月、数時間にわたって特定のワークロードのトラフィックがどのように推移してきたかに基づいてワークロードを分類する、高度な分類器も用意しました。
6.3 5種類の推論ティア体系
Somu： これらすべてによって実現できるのが、先ほどArisがパフォーマンスの柱として触れていた、皆さんのワークロードが必要とする要件と、この場合で言えばレイテンシと、コストの柱とを組み合わせることです。これが皆さんにとって何を意味するかというと、私たちは選択可能な、いわゆる推論ティアを提供できるということです。私たちは2023年、Bedrockのローンチ時に3つの異なる推論ティアからスタートしました。標準ティアは、その名の通り日々のワークロード向けの標準的なティアです。バッチティアは、レイテンシに敏感でないバッチワークロード向けです。そしてリザーブドティアは、固定のレイテンシとトークン単価を固定価格で必要とする場合のためのものです。これらが最初にローンチした3つの異なるティアであり、非常に強力なものでした。
Aris： これらはうまく機能していましたが、時間とともに、さらに多様化できる余地があることが分かってきました。リザーブドと標準の間にも1つの世界があり、標準とバッチの間にももう1つの世界があったのです。そこでMantleによって、私たちは今やバックグラウンドで非同期処理の能力とSomuがお話ししたインテリジェントなキューイングを持てるようになったため、2つの新しい推論ティアを導入することができました。フレックスティアは、レイテンシについてはやや柔軟だが、コストを抑えたいというワークロード向けのものです。そしてプライオリティティアは、私たちが持つキューの仕組みを活用し、優先的なキューイングを行うものです。これは空港でセキュリティの列をスキップするようなもので、常に最良のレイテンシで実行されることを重視するアプリケーション向けのものです。
Aris： これら5つのティアは、市場において最も包括的なツールセットであり、皆さんのアプリケーションのパフォーマンス要件を、コストのフットプリントと正確に一致させることができます。これを少し具体的にお伝えするために、1つ例を挙げたいと思います。皆さんにも馴染みのある、開発環境、テスト環境、本番環境という異なるデプロイ環境があると思います。多くの方がこのような形で運用されているのではないでしょうか。では、これらの環境に対して、これらのティアをどのように即座に適用できるでしょうか。開発環境やテスト環境は、基本的に何が機能して何が機能しないかを試行錯誤する環境です。モデルを試し、プロンプトを試し、アプリケーションロジックを試す場です。多くの場合、これはそれほどレイテンシにクリティカルではありませんので、フレックスティアを利用することで、コストを最大50%節約することができます。一方、実際の顧客にサービスを提供する本番環境、リアルタイムのチャットボットやリアルタイムAPIを扱う環境では、多くの場合レイテンシが非常に重要になります。ここではプライオリティティアが優れた選択肢となり、出力トークンのスループットを最大25%向上させることができます。そして何より素晴らしいのは、これが単なる設定変更であり、コードの変更が一切不要だという点です。ですから、皆さんはセッション終了後、あるいは今日にでも、これをすぐに実行することができます。そしてすぐにコストを削減しながら、本番環境のレイテンシを改善し、それによってエンドカスタマーのユーザー体験も向上させることができるのです。
7. グローバルフットプリントとセキュリティ
7.1 全リージョン展開とキャパシティ利用の課題
Aris： それでは視点を広げて、4つ目の柱であるグローバルフットプリントについて見ていきましょう。ご存じの通り、AWSはリージョンとアベイラビリティゾーンを中心に構築されており、それらは世界中に広がっています。Bedrockは現在、すべてのAWSリージョンで利用可能です。ですから皆さんは、データレジデンシー要件、コンプライアンス要件、そしてパフォーマンス要件を満たしながら、生成AIによるイノベーションを進めることができます。しかし、Bedrockを世界中にスケールさせていく中で、私たちは利用率に関して興味深い事象を目にすることになりました。
Aris： 世界中でキャパシティを追加していく中で分かってきたのは、世界各地でキャパシティの利用に非効率が生じているということでした。季節性、タイムゾーンの違い、その他の運用上の理由など、さまざまな要因によって、非常に混雑しているリージョンがある一方で、同じ時間帯に別のリージョンでは多くのアイドルキャパシティが存在するという状況が見られたのです。そしてこれは、混雑しているリージョンにいるお客様が、ピーク時にスロットリングやレイテンシの増加に直面してしまう可能性につながります。そこで私たちはこの課題について検討し、クロスリージョン推論という仕組みを導入しました。これは、私たちが持つ膨大な情報をもとにしたデータドリブンなインテリジェントルーティングの仕組みであり、私たちがグローバル規模でお客様により良いサービスを提供することを可能にしてくれるものです。
7.2 クロスリージョン・インテリジェント・スピルオーバー
Aris： ここまでお話ししてきましたが、皆さんお客様としては、これが実際に裏側でどのように動いているのか、より詳しく知りたいところだと思います。
Somu： それは良いところですね。時間も押していますので、ここは高いレベルにとどめて、スライドを少し駆け足でご説明します。これは私がBedrockに参加した際に解決を任されたもう1つの課題でした。お客様は、モデルがどのリージョンにあるかを意識するといった差別化につながらない負荷の高い作業をしたくない、という声がありました。それを踏まえて、お客様がこの点を気にしなくて済むソリューションを考案できないかと考えました。そこで生まれたのが、クロスリージョン・インテリジェント・スピルオーバーです。仕組みとしては、クロスリージョン推論プロファイルを使用し、皆さんのアプリケーションスタック全体が置かれているローカルリージョンにリクエストをルーティングします。そのリージョンが、どこにキャパシティがあるかを判断し、リクエストが確実に処理されるよう適切にルーティングする責任を引き受けます。
Somu： この図では、お客様からのリクエストがUS East 1に到達し、US East 1がそれをUS West 2にルーティングするという判断を下しています。では、どのようにこの判断を下しているのでしょうか。クロスリージョン推論リクエストを受け取った際に、どのリージョンにルーティングするかを決める基準は3つあります。1つ目はキャパシティがどこにあるかです。キャパシティのある場所に応じてリクエストをルーティングします。しかし、単にキャパシティがあるというだけでは十分ではありません。キャパシティがあっても利用率が高い場合があるからです。これは皆さんもよくご存じの、いわゆるサンダリングハード問題です。キャパシティがあると思って全員が同じリージョンにリクエストをルーティングしてしまうと、結果としてレイテンシが増加してしまいます。そこで私たちは利用率も追跡しています。そして最後に、キャッシュ認識です。Bedrockは多くのモデルでプロンプトキャッシングを標準でサポートしていますので、すでにキャッシュされているプロンプトが効率的に活用されるようにする必要があります。そのため、リクエストをどこにルーティングするかを判断する際にキャッシュ認識も利用しているのです。
Somu： この仕組みの優れている点は2つあります。1つは、リージョンをまたぐ際のネットワーク帯域幅コストを、皆さんが一切支払う必要がないということです。それは完全に裏側で隠蔽されています。2つ目は、皆さんはモデルがどこにあるかを一切気にする必要がないということです。皆さんが気にすべきなのは、自分たちのアプリケーションスタックがどこにあるか、そしてそこにクリスプロファイルのサポートがあるかどうかだけです。しかも、皆さんのアプリケーションスタックがあるリージョンにキャパシティが存在している必要すらありません。それがこの仕組みの美しいところです。他の場所でキャパシティを見つけ出し、モデルが利用可能などこかへリクエストをルーティングすることで、皆さんのリクエストが確実に処理されるようにしてくれるのです。
7.3 検証可能なセキュリティとアテステーション
Somu： 最後になりますが、私たちAWSはセキュリティを非常に重視しており、それは責任共有モデルに基づいています。皆さんのデータは常に保管時に暗号化されており、通信時にも暗号化されています。そのほかにもさまざまなコンプライアンス関連の対応がありますが、ここは駆け足でご説明します。ガードレールについても後ほど触れますが、Simoneが述べていた通り、本日この後にガードレールに関する専用のセッションがありますので、ご興味のある方はぜひそちらにご参加ください。
Somu： ここでお話ししたいのは、Mantleによって私たちがセキュリティの基準をさらに引き上げたという点です。基準を引き上げるとはどういうことかと言いますと、Mantleにおいてセキュリティは「信じてください」というものではなく、「検証可能」なものになっているということです。EC2のNitro TPMをご存じの方はどれくらいいらっしゃいますか。ありがとうございます、多くの方がご存じですね。EC2にはこの機能があり、あるインスタンス上で動作しているソフトウェアが、実際にどのように動作しているかを証明し、検証することができます。私たちが行ったのは、Mantleで動作しているかどうかを検証できるようにするために、そのボックス上で動作するソフトウェアに対して、オペレーターがそのボックスにアクセスする手段を一切与えないようにするということです。SSHやセッションマネージャーなど、オペレーターがボックスにログインするために必要だったすべての手段を取り除きました。そしてこれは実行時にアテステーションされます。このアテステーションが成功して初めて、モデルの重みをダウンロードするための暗号鍵、そしてリクエストを復号するための暗号鍵が渡される仕組みになっています。
Somu： つまりMantleは、モデルが稼働しているボックスに対してオペレーターが一切アクセスできないことを保証しており、これは単に「信じてください」というセキュリティではなく、検証可能なセキュリティ態勢を提供するものです。私たちはこの点を非常に誇りに思っています。ここまで多くのことをお話ししましたが、これらはすべてリソースとしてまとめてありますので、この後はFrancisに、本日の内容をまとめていただきたいと思います。
8. まとめ
8.1 失敗リスクへの回答とビジネス価値
Francis： ここまでSomuからたくさんお話をいただきましたので、皆さんにはQRコードを手元でスキャンしていただければと思います。そしてこの後すぐにアンケートへの回答をお願いしますので、カメラをお手元に準備しておいてください。
Francis： それでは、冒頭でお話しした「2027年までにAgenticプロジェクトの40%がコストを理由に失敗する」という話に戻りたいと思います。まず私たちはモデル選択についてお話ししました。そしてBedrock内で利用できるティアモデルについてもお話ししました。もう1つの観点はビジネス価値です。ビジネス価値を考える際に重要なのは、今日構築する必要があるものだけでなく、明日構築する必要があるものも見据えるということです。例えば、ステートフルなAPI、すなわちステートフル・レスポンス・エンドポイントを使えるようにしておくという能力がこれにあたります。
8.2 セキュリティの位置づけと次セッションへの案内
Francis： そして最後にセキュリティと責任あるAIです。皆さんはBedrock Guardrails、Automated Reasoning、そしてAgentCore Policyを活用することができます。本日この後、Automated Reasoningチームに所属するBenが、この点について詳しく掘り下げたセッションを行います。
Francis： どうもありがとうございました。それでは、アンケートへのご回答をよろしくお願いいたします。