※本記事は、AWS re:Invent 2024「Control the cost of your generative AI services (COP203)」の内容を基に作成されています。このセッションでは、Amazon Q Business、Amazon Bedrock、Amazon SageMaker、およびセルフホストEC2インスタンスなどのAWS生成AIサービスのコスト監視と最適化について解説しています。セッションの詳細情報はhttps://go.aws/reinvent でご覧いただけます。本記事では、セッションの内容を要約・再構成しております。なお、正確な情報や文脈については、オリジナルの動画（https://www.youtube.com/watch?v=8suHtdvlvqA ）をご視聴いただくことをお勧めいたします。その他のAWSイベントについては、https://go.aws/3kss9CP をご参照ください。
1. イントロダクション
1.1. セッションの概要と目的
このセッションは「Control the cost of your generative AI services (COP203)」と題され、生成AIサービスのコスト管理と最適化に焦点を当てています。冒頭でAlex Headは、生成AIの力を活用しながらコストを抑える方法について参加者に提供することを目的としていると説明しています。具体的には、Amazon Q Business、Amazon Bedrock、Amazon SageMaker、そして自己ホスト型EC2インスタンスなどのAWS生成AIサービスのコスト監視と最適化の手法を網羅的に取り上げることが述べられています。
セッションでは、生成AIを初めて使用する人から、すでに最先端のソリューションを展開している人まで、あらゆるレベルの参加者がAIワークロードを効率的に実行するために必要な洞察を得られるよう設計されています。Alexは会場の参加者に対して、どれくらいの人がすでにAIを使って何かを構築しているか、また計画段階にある人がどれくらいいるかを質問し、それに基づいて説明の詳細度を調整することを述べています。
このセッションの主な目標は、参加者がAIの導入過程のどの段階にいるかに関わらず、実践的なコスト最適化戦略を身につけることです。そして、セッションを通じてさまざまなアプローチやサービスの比較が行われ、参加者自身のビジネスニーズに最適な選択肢を見つける手助けをすることが目的として示されています。
1.2. 発表者の紹介（Alex Head、Adam、Brent from Capital One）
このセッションには3名の発表者が登壇しています。まず司会を務めるAlex Headは、AWSのOpticsチームのリーダーとして自己紹介しています。彼のチームは顧客のコストと使用量データを実用的な洞察に変換し、節約や効率化を見つけるサポートをしています。Alexは過去1年間のAIコスト最適化の旅を最前線で見てきた経験を持ち、セッション全体を通して生成AIサービスのコスト最適化の全体像を提供しています。
2人目の発表者はCapital Oneに所属するBrentです。彼は20年間にわたるパブリッククラウド、プライベートクラウド、マルチクラウドでの業務経験を持ち、自己管理型のAIインフラを好むエンジニアとして紹介されています。セッションではCapital Oneでの実際の導入事例と、特に自己管理型のAIワークロードに関する知見を共有しています。
3人目の発表者はAlexのチームに所属するAdamで、最適化エンジニアとしての視点から話をしています。彼は完全な自己管理型ではなく、かといって完全管理型でもない中間的なアプローチを好み、特にサーバーレスインフラストラクチャと単純なAPIを提供するAmazon Bedrockを好んで使用していると述べています。セッションでは部分管理型と管理型のAIサービスについて詳しく説明しています。
この3名がそれぞれ異なる視点と専門知識を持ち寄り、生成AIサービスのコスト最適化についての包括的な見解を提供しています。
1.3. AIコスト最適化の旅
Alex：私は、AWSのOpticsチームのリーダーとして、この1年間のAIコスト最適化の旅を最前線で見てきました。この旅の経過を少し振り返ってみましょう。昨年のre:Inventでは、AIに関する大きな盛り上がりがありました。「AIバズ」と優しく表現するにとどめておきますが、非常に多くのAIに関する話題で溢れていました。そして、すべてのFinOpsチームは「これはいくらかかるの？どんな費用になるの？」という質問を受けるようになりました。
その後、私たちは「これは実際にかなり面白いかも」と思い始め、FinOpsの世界でAIを活用したものを構築し始めました。そして今、私たちは「待って、これらすべてを構築したけど、どうやって最適化すればいいの？このコストは一体何なの？」という段階に来ています。これが私たちを今日ここに集めた理由です。
AIの異なる構築方法とその最適化方法について説明していくと、少し理論的になりがちです。そこで、私は架空のAIアプリケーション「Cosmo」を例として使いながら、異なるステップを説明していきます。これにより、皆さんが構築しているものと関連付けて理解しやすくなるでしょう。
Cosmoは夢を解釈するAIコンパニオンです。雲の上に城を建てたい、火星にレストランを開きたい、そんな夢を持っているなら、Cosmoがサポートします。夢の計算機が必要でも、ビジネス上の課題を解決したいときでも、Cosmoはそのコストをコントロールするのを助けることができるはずです。
このようにして、私たちはAIの黎明期のバズから始まり、実際の構築フェーズを経て、今や最適化という段階に到達しています。この旅のどの段階にいるかに関わらず、今日のセッションで実践的な最適化戦略を身につけていただければと思います。
2. Cosmoの例：AI構築プロセスの概要
2.1. Cosmoの紹介：夢解釈AIコンパニオン
Alex：AIの異なる構築方法と最適化について説明していくと少し理論的になってしまうので、具体例を通して理解を深めていきましょう。そこで私は今日、架空のAIアプリケーション「Cosmo」を例として使っていきます。皆さんが構築中のものと関連付けて考えやすくなるはずです。
Cosmoは夢を解釈するAIコンパニオンです。例えば、雲の上に城を建てたいとか、火星にレストランを開きたいとか、そういった夢を持っているなら、Cosmoが皆さんをサポートします。夢の計算機が必要な場合でも、あるいは具体的なビジネス上の課題を解決したい場合でも、Cosmoは対応できますし、そのコストをコントロールする方法も提案できます。
この架空のAIアプリケーションを通して、実際のAIサービスを構築する際の様々なアプローチやコスト最適化の方法を探っていきます。Cosmoのような創造的なAIアプリケーションは、様々な方法で実装できますが、実装方法によってコスト構造や最適化の方法が大きく変わってきます。これからの説明では、自己管理型から完全管理型まで、異なるアプローチでCosmoを構築した場合のコスト最適化戦略を見ていきましょう。
2.2. AIの基本プロセス（トークン化、知識ソース参照、出力生成）
Alex：Cosmoの例を使って、AIアプリケーションがどのように機能するのか、基本的なプロセスを説明しましょう。例えば、「Hey Cosmo、虹色の城を建てよう」とリクエストしたとします。このとき、3つの重要なステップが発生します。
まず第一に、Cosmoはリクエストをトークンに分解します。トークンとは、テキストをかみ砕いた小さな単位と考えてください。単語全体の場合もあれば、単語の一部分の場合もあります。これがAIの基本的な処理単位となります。
次に、Cosmoは知識ソースを参照します。これには夢の解釈ガイド、色彩科学、城の建築様式など、様々な情報が含まれます。皆さんのAIアプリケーションであれば、どのような知識ソースを参照するのかは用途によって変わってきます。
最後に、Cosmoは様々な形式の出力を生成します。簡潔な回答かもしれませんし、火星のレストランの詳細な設計図かもしれません。あるいは視覚的なガイドかもしれません。出力の種類と範囲は非常に広いものになります。
このように、AIアプリケーションは基本的に「入力のトークン化」→「知識ソースの参照」→「出力の生成」という流れで処理を行います。この基本プロセスを理解することで、どの部分でコストが発生し、どこを最適化できるかを把握しやすくなります。
2.3. AIアプリケーションの主要評価指標（レスポンス速度、リソース効率、信頼性と柔軟性、品質と深さ）
Alex：Cosmoの仕組みがわかったところで、AIアプリケーションの成功を測る指標について考えてみましょう。顧客のAIアプリケーションを見ていると、特に重要な4つの指標があります。
まず第一に、レスポンス速度です。これはかなり直感的ですね。例えば、ユーザーがCosmoに虹色の城の建て方について質問した場合、どれくらい早く回答するのか、そしてその応答速度は重要なのかを考える必要があります。
次に、リソース効率です。これはコスト最適化の核心部分で、実際の価格タグに関わります。財務部門に報告する際のコストがどれくらいになるかという点です。
三つ目は、信頼性と柔軟性です。Cosmoはどんな要求にも対応できる準備ができていなければなりません。世界中のどこからでもCosmoを使用できるのか、特定のリージョンでしか使えないのか、どれくらい柔軟性があるのかという点も考慮すべきです。
最後に、品質と深さです。例えば、単に「ツリーハウスを建てる」という要求と、「太陽光パネルを備えた持続可能なツリーハウスを熱帯雨林に建てる」という要求では、必要な回答の深さが大きく異なります。
この4つの指標のバランスをどうとるかは、AIアプリケーションの目的や要件によって変わってきます。ステージ上の私たち3人も、それぞれ異なるアプローチでCosmoを構築するでしょう。私個人としては、財務、ビジネス、技術的な考慮事項のバランスを取るリーダーとして、完全管理型のサービスを選ぶ傾向があります。
Brent：私は20年間パブリッククラウド、プライベートクラウド、マルチクラウドを扱ってきた経験から、明らかに自己管理型を好みます。
Adam：私は構築する際に、パワーとカスタマイズ性のバランスを求めます。自己管理型の完全なカスタマイズ性は必要ありませんが、完全管理型ソリューションでは存在しないかもしれない一部の要素を変更できる柔軟性は必要です。そのため、主にBedrockを選ぶことが多いです。サーバーレスインフラストラクチャとシンプルなAPIがあるので、コストを抑えつつ柔軟性も確保できます。
2.4. 構築アプローチの多様性（自己管理型、部分管理型、完全管理型）
Adam：私たちの例に沿って考えると、あなたや組織がCosmoのようなソリューションを構築する場合、Alexが指摘したように、4つの異なるパスがあります。まずは、最も柔軟性が高く、最もカスタマイズ可能なパスである自己管理型から始めましょう。
自己管理型の環境を構築する場合、どのようなコンポーネントが必要かを考える必要があります。加速コンピューティングEC2インスタンスが必要で、何らかの独自モデルを持ち込むことになります。ソフトウェアや設定の責任も持ち、トレーニング、チューニング、推論もすべて自分たちのチームの責任となります。
多くの場合、AIやビッグデータの専門知識を持つチームが必要です。しかし、今日は「AIチームの構築方法」ではなく、「コストをコントロールし、このタイプのワークロードを効率的に実行する方法」について話します。
Brent：私の経験から言えば、自己管理型アプローチでは、インスタンス選択が特に重要です。一般的なPファミリー（P5、P4など）でよいのか、それともGravitonやTrainium、最新のTrainium2のような特殊用途向けインスタンスが必要なのか。どれが環境に最適かを知るには、テストが必要です。FMBenchツールを使えば、さまざまなインスタンスをサービングスタックとワークロード全体で分析し、最も適したインスタンスを見つけることができます。
Alex：私たちがこのセッションで注目すべき点は、3人の異なるアプローチによる構築方法です。自己管理型は完全な制御とカスタマイズが可能ですが、専門知識と管理負担が必要です。部分管理型のSageMakerは、AWSがインフラを管理する一方で、ユーザーはより高いレベルでの開発に集中できます。そしてBedrockはさらに抽象化レベルが上がり、単一APIで様々な基盤モデルにアクセスできます。最後に完全管理型のAmazon Q Businessでは、ほぼすべてのインフラ管理が不要になります。
それぞれのアプローチには独自の長所と課題があり、コスト最適化の戦略も異なります。Cosmoのような夢解釈AIを構築する場合でも、組織のニーズや技術的能力に応じて、最適なアプローチは変わってくるでしょう。これから各アプローチについて詳しく見ていきます。
3. 自己管理型AIサービスの最適化（Brent担当）
3.1. インスタンス選択の重要性
Adam：自己管理型アプローチについて考える際、まず最初に考えるべきことは、環境内でどのようなコンポーネントが必要かということです。加速コンピューティングEC2インスタンスが必要になり、何らかの独自モデルを持ち込むことになります。ソフトウェアと設定についても責任を負い、トレーニング、チューニング、推論まですべて自分たちのチームの責任となります。多くの場合、AIやビッグデータの専門知識を持つチームが必要です。しかし、今日は「AIチームの構築方法」ではなく、「コストをコントロールし、このタイプのワークロードを効率的に実行する方法」について話します。
インスタンス選択はその第一歩です。どのようなインスタンスを実行する必要があるでしょうか？P5、P4などのPファミリーのような汎用インスタンスが環境で機能するでしょうか？それとも、Graviton、Trainium、あるいは新しいTrainium2のようなより特定の目的に特化したものが必要ですか？どれが環境に最適かを知る最善の方法はテストすることです。
そのための最適なツールはFMBenchを使用することです。このツールを使えば、サービングスタックとワークロード全体でさまざまなインスタンスを分析し、環境に最も適したインスタンスを見つけることができます。適切なインスタンスタイプを決めることができれば、コスト最適化の重要な第一歩を踏み出したことになります。インスタンスの選択によって、必要なリソース量やコストが大きく変わってくるため、慎重に検討する必要があります。
3.2. 容量管理とODCR（オンデマンド容量予約）のモニタリング
Brent：インスタンスタイプについて理解したら、次のステップは容量管理について考えることです。どれだけのインスタンスを実行する必要があるでしょうか？常時実行する必要があるのか、それともスケジュールを設定できるのか？オンデマンド容量予約（ODCR）を使用しているのか？そして、ODCRを使用している場合、モニタリングしているかどうかが重要です。
ODCRを使用している方に向けて、少し脱線して私が確認しているいくつかのポイントをお伝えします。ODCRでは、使用されていないODCRの量を監視するのは比較的簡単です。Cost ExplorerとCost and Usage Reportsの両方に「Usage Type」というフィールドがあります。このフィールド内には、「UnusedBox」（すべて一語）または「Unused Res」と呼ばれるタイプがあります。これを時間単位の粒度でフィルタリングすると、次の2つのパターンのいずれかが見えてきます。
まず、未使用分がフラットなテーブルトップ型のグラフが表示されることがあります。これは、定期的に使用していない多くの容量を保護していることを示しています。これは、保護している容量を使用するためにインスタンスを起動する必要があるか、あるいは使用していない容量を保護しないようにODCRを縮小して費用を節約する必要があるかもしれないことを示唆しています。
もう一つ見られるかもしれないグラフのタイプは、スケーリングに伴って上下するサイン波のようなものです。おそらく一日の特定の時間帯により多くのインスタンスを使用しており、その間はODCRの未使用量が減少します。しかし、その谷の部分でさえ、保護しているが使用していない容量の量を示しています。先ほど述べたのと同じルールが適用されます。その容量を保護し続ける必要があるのか、それとも調整して削除できるのかを検討すべきです。
ODCRの話から少し離れて、別の重要な要素は、実行して一時停止したり、営業時間外に実行したり、中断される可能性のあるインスタンスやワークロードがあるかどうかです。もしあれば、Spotは一部のトレーニングで最大90%節約できる優れた方法です。適切なシナリオでSpotインスタンスを活用することで、大幅なコスト削減が可能になります。
3.3. Spotインスタンスの活用（最大90%の節約可能性）
Brent：自己管理型AIワークロードのコスト最適化において、ODCRのモニタリングに加えて考慮すべき重要な要素は、実行して一時停止できるワークロード、あるいは営業時間外にスケジュールできるワークロード、または中断されても問題ないワークロードがあるかどうかです。そのようなワークロードがある場合、Spotインスタンスは最大90%のコスト削減を実現できる優れた選択肢となります。
Spotインスタンスは、AWSの余剰容量を活用するため、通常のオンデマンドインスタンスよりも大幅に安い価格で提供されています。特にトレーニングワークロードのような、中断されても再開可能なタスクに適しています。例えば、モデルトレーニングの大規模なバッチジョブをSpotインスタンスで実行することで、通常のオンデマンド料金と比較して最大90%のコスト削減が可能です。
ただし、Spotインスタンスは需要が高まると自動的に終了する可能性があるため、チェックポイントを定期的に保存するなど、中断に対応できるようにワークロードを設計することが重要です。AIトレーニングワークロードでは、定期的にモデルの状態を保存しておくことで、中断された場合でも最初からやり直す必要がなく、中断されたポイントから再開できます。
これは自己管理型環境におけるコスト最適化の大きなレバーの一つです。インスタンスのタイプ、数量、スケジュールについての良い考えが得られたら、次はコミットメントについて考えましょう。
3.4. コミットメント戦略（インスタンスセービングスプランとコンピュートセービングスプラン）
Brent：インスタンスの種類と量、そして実行スケジュールについて理解したら、次に考えるべきは長期的なコミットメント戦略です。まず考えるべき重要な質問は、これらのワークロードを少なくとも今後1〜3年間維持するつもりかどうかです。次に考えるべきなのは、単一のインスタンスファミリーに固執するかどうかです。例えば、P5などのPファミリーを今後1年または3年間維持するつもりでしょうか？
もしそうなら、インスタンスセービングスプランが環境に最適かもしれません。これらは最大の割引を提供しますが、単一のファミリーに紐づけられます。一方で、前世代のインスタンスから切り替える柔軟性や、将来の世代のインスタンスに切り替える柔軟性が必要な場合は、コンピュートセービングスプランの方が適しています。
コンピュートセービングスプランは柔軟性を提供し、自動的に降順でインスタンスに最大の割引を適用するので、どのインスタンスにコミットするかを考える必要はありません。自動的にそれを処理してくれます。これら二つの間のもう一つの違いは、環境内でコミットメントをあまり行わない場合、インスタンスセービングスプランはリージョンに紐づけられることです。
一方、コンピュートセービングスプランはリージョンに紐づけられません。リージョン間で柔軟に移動でき、必要に応じてワークロードを異なるリージョン間で移動することができます。将来のロードマップで異なるリージョンに移行する可能性がある場合は、コンピュートセービングスプランの方が適しているかもしれません。
コミットメントを管理できるようになったら、使用量を最適化し、料金を最適化するものについて考えています。しかし、すでに実行しているインスタンスから同じインスタンスでより多くの価値を得られたらどうでしょうか？実行中の同じインスタンスから38〜40%のパフォーマンスや使用率を向上させられたらどうでしょうか？それが次に説明するGPU使用率の監視と最大化の重要性です。
3.5. GPUの使用率最大化（同じインスタンスから38〜40%多くの性能を引き出す方法）
Brent：コミットメントが管理でき、使用量と料金の最適化について考えているとき、次の重要な質問が生まれます。すでに実行しているインスタンスから、より多くの価値を引き出せないだろうか？同じインスタンスから38〜40%もの追加パフォーマンスや使用率を獲得できないだろうか？ここがGPU使用率の監視と最大化が重要になってくる理由です。
GPUインスタンスは非常に強力ですが、多くの場合、その能力を最大限に活用できていません。最適化されていないGPUの使用では、計算能力の半分以下しか使用していないケースもあります。GPUの使用率を正確に測定し、最大化することで、同じインスタンスから38〜40%多くのパフォーマンスを引き出すことが可能になります。
これはまるで同じ料金を払いながら、1台ではなく1.4台のGPUインスタンスを使用しているようなものです。特に高価なGPUインスタンスでは、この最適化による財務的インパクトは非常に大きくなります。
では、これらの戦略を実際に大規模に実装している人の話を聞いてみましょう。私たちCapital Oneでは、これらのトレードオフをどのように行っているのか、そしてそこから何を学んだのかについて共有したいと思います。
4. Capital Oneの事例研究（Brent担当）
4.1. テクノロジースタックの再構築経験
Brent：多くの方がCapital Oneの旅について既にご存じだと思いますので、あまり詳細には立ち入りません。ただ、これから話す内容を関連付けるために、ある程度の背景をお伝えしておきたいと思います。
私たちがプライベートクラウドからパブリッククラウドへ移行したとき、テクノロジースタックを完全に一から再構築する必要がありました。これは、スケーラビリティ、市場投入までのスピード、そして信じられないほどの回復力を持ったサービスを提供することに焦点を当てるためでした。
その規模の環境を再構築することは非常に大きな挑戦でしたが、私たちが学んだことは、最終的にはモダンなデータエコシステムの基盤となりました。このエコシステムは、これらのサービスを提供することができる能力を持っています。
この旅が、生成AIへのアプローチ方法と、それがもたらし続けるパラダイムシフトの基盤となりました。環境のスケールで再構築することは非常に困難でしたが、この経験が私たちに生成AIに対する基盤とアプローチ方法を与えてくれました。
私たちが大規模なテクノロジースタックを再構築する過程で得た知識と経験は、生成AIという新しい技術領域に直面したときに非常に価値があることがわかりました。特に、従来のコンピューティングとは大きく異なる加速コンピューティングの管理やコスト最適化において、この経験が役立っています。
4.2. 生成AIに関する3つの重要な発見
Brent：生成AIの道に進み始めたとき、私たちは最初に3つの重要な事実を観察しました。
第一に、加速インスタンスのコストと可用性は従来のインスタンスとは大きく異なるということです。特に最新の大型GPUインスタンスは、通常のコンピューティングインスタンスと比較して、調達が難しく価格も高いという特徴があります。
第二に、これらのインスタンスのコストとパフォーマンスを解釈する方法を変更する必要がありました。従来のCPUベースのインスタンスとは異なる評価指標が必要になったのです。
第三に、モデルタイプやモデルアーキテクチャなどの外部要因が、これらのインスタンスのパフォーマンスに大きな影響を与えることがわかりました。同じハードウェアでも、実行するモデルによって効率性が大きく変わってくるのです。
これらの発見についてこの後のスライドでもう少し詳しく説明し、これらの特殊性に対処するための戦略についてお話しします。
まず、コストと可用性に関して言えば、自己管理型インスタンスを調達しようとすると、特に大型の新しいインスタンスを入手することは時に困難であることに気づかれた方も多いでしょう。その結果、私たちが観察したのは、チームがこれらのインスタンスをプロビジョニングできると、不要になっても解放することを躊躇する傾向があるということです。
これにより、一部のクラスターでは大量の未使用キャパシティが存在する一方で、他のクラスターは必要なリソースの確保に苦労するという状況が生まれています。このような状況に対処するための一つの戦略は、GPUプールを作成することです。ここでは、インスタンスをクラスター間で移動させ、必要な場所に容量を提供し、必要なときにモデルをトレーニングできるようにします。
4.3. GPUプールの作成戦略
Brent：コストと可用性の課題に対処するために、私たちはGPUプールを作成する戦略を採用しました。特に高性能GPUインスタンスは入手が困難なため、チームがせっかく確保したインスタンスを解放したがらない傾向があることに気づきました。その結果、一部のクラスターでは大量の未使用キャパシティが存在する一方で、他のクラスターは必要なリソースの確保に苦労するという不均衡が生じていました。
このような状況を解決するために、GPUプールという概念を導入しました。これは、インスタンスをクラスター間で柔軟に移動させることができる仕組みです。例えば、あるチームがトレーニングを完了した後は、そのGPUリソースを必要としている別のクラスターに移動させることができます。これにより、リソースを常に最も必要とされている場所に提供し、モデルトレーニングを必要なときに実行できるようにします。
この戦略は、貴重なGPUリソースの効率的な共有を可能にし、組織全体のコスト効率を高めます。また、個々のチームがリソースを囲い込む傾向を軽減し、より協力的なリソース管理文化を促進します。これは特に大規模な組織では、高価なAIインフラストラクチャの最適化において重要な戦略となります。
GPUプールの導入により、私たちは全体的なGPU使用率を向上させ、不必要な追加インスタンスの調達を減らすことができました。しかし、GPUリソースを効率的に管理するためには、正確な使用率測定が不可欠であり、それが次のポイントにつながります。
4.4. GPU使用率測定の複雑さ
Brent：パフォーマンスを見るとき、加速インスタンスに伴うアーキテクチャの違いを理解することが重要です。従来の基本的なコンピューティングインスタンスでは、CPU自体が計算の主な作業を担っていました。しかし、加速インスタンスでは、実際の作業の大部分はGPU上のストリーミングマルチプロセッサによって行われています。
そこで課題となるのは、これらのリソースがどれだけ効率的に消費されているかを測定する方法です。利用可能なデータを見てみましょう。この場合、GPU特有の3つの異なる測定値があり、これらが使用率についての追加的な洞察を提供します。
GPUの効率的な使用を判断するために単一の統一指標だけを見るのではなく、実際にはリソースがどのように消費されているかを推測するために、これら3つの指標をすべて使用する必要があります。ここで見ていく3つの指標は、GPU温度、GPU電力消費、そしてGPU使用率です。
GPU使用率という用語はCPUの世界から来た場合には誤解を招くかもしれません。この文脈でのGPU使用率とは、GPU上のリソースが実際に使用されている時間だけを意味します。つまり、リソースがどれだけ効率的に消費されているかについての洞察を得るためには、GPUの閾値に対して電力消費と温度の両方を活用する必要があります。
ここで重要な注意点は、すべてのGPUが同じように作られているわけではないということです。それぞれのGPUには電力と温度に関する独自の上限があり、実際の使用率をその上限と比較して測定する場合は、それらの閾値がどこにあるかを認識する必要があります。
例えば、あるGPUの最大電力消費が300ワットであるのに対して、別のモデルでは500ワットかもしれません。同様に、安全な動作温度の上限も異なります。これらの制限を理解せずに使用率を測定すると、誤った最適化決定につながる可能性があります。
GPU使用率の正確な測定は複雑ですが、AIワークロードの最適化に不可欠です。この3つの指標を総合的に分析することで、リソースの効率的な使用についての正確な洞察を得ることができます。
4.5. 効率性の分析フレームワーク
Brent：パフォーマンスに影響を与える外部要因について話す際、効率性について議論したときに触れた内容を参考にしましょう。例えばNVIDIA A100の測定値を示すグラフでは、使用率と電力消費の間に強い線形相関があることが期待されます。つまり、この場合、使用率レベルが上昇するにつれて、リソースを効率的に消費していれば電力消費も同様に上昇するはずです。
しかし、グラフの右下隅には、いくつかの外れ値が目立ち始めているのがわかります。これは必ずしも問題を示すものではありませんが、追加の注意を必要とする興味深いデータポイントです。これはモデルをチューニングする機会かもしれませんし、単にインフラ自体のアーティファクトかもしれません。
まとめとして、インスタンスがどれだけ効率的に使用されているかを分類するための一般的なフレームワークと、理想的でないパフォーマンスに寄与する可能性のある条件をお伝えしたいと思います。このルーブリックは非常にシンプルですが、非効率性が発生する可能性のある場所を理解するための基盤を提供します。
もちろん、このアプローチは、追加のモデルのトレーニングや追加のインフラストラクチャの組み込みを通じて、時間とともに進化し続けることを認識しています。これらの開発はすでに、私たちが熱心にテストしたいと考えている新しいユースケースや新しい仮説を生み出し始めています。
このフレームワークを適用することで、パフォーマンスとコストのバランスを最適化するための体系的なアプローチを持つことができます。使用率と電力消費の関係における外れ値を分析することは、モデルやインフラストラクチャの調整の機会を特定するのに特に有用です。これらの調整により、同じハードウェアからより多くの価値を引き出し、総コスト効率を向上させることができます。
私たちの旅、そして途中で得られた重要な洞察について共有できて嬉しく思います。皆さんの旅にも期待しています。それでは、Adamにバトンを渡します。
5. 部分管理型ソリューション：SageMaker（Adam担当）
5.1. SageMakerの位置づけとメリット
Adam: SageMakerの最大の価値は、組織がCosmoのようなソリューションを構築したいけれども、すべてのインフラストラクチャを管理したくない、あるいは管理する能力がない場合に真価を発揮します。私の経験では、多くのチームがビジネス価値の構築と提供に集中したいと考えていて、特に小規模なチームではそれが全てのリソースを使い切ってしまうことも珍しくありません。
SageMakerを使用すると、AWSがインフラストラクチャの部分を担当してくれます。これは具体的には、ツール、ワークフロー、そして多くのソフトウェア構成などを意味します。SageMaker内の最適化レバーの多くは、先ほどBrentが説明した自己管理型のアプローチと類似していますが、いくつかの重要な違いがあります。
自己管理型の環境ではインフラストラクチャから運用までのすべてを自分たちで管理しなければなりませんが、SageMakerを使うとAWSがほとんどのインフラストラクチャ部分を管理してくれるため、MLライフサイクルの各段階を最適化することに集中できます。このアプローチでは、「自分たちが必ずやるべきこと」と「AWSが代わりに面倒を見てくれること」を明確に区別して考えることが重要です。
SageMakerの大きなメリットは、機械学習のフルライフサイクルをサポートしながらも、自己管理環境と比べて管理の手間を大幅に削減できる点です。特に、インスタンスの管理やスケーリング、ソフトウェアの更新などの煩雑な作業から解放されることで、データサイエンティストやML工学者は本来の仕事である価値創出に集中できます。私たちのチームでは、SageMakerを活用することで開発から本番環境へのデプロイまでの時間を約25%短縮できました。
これは、Cosmoの例で言えば、夢の解釈という核心的な部分に集中し、その背後にある複雑なインフラストラクチャの詳細にあまり時間を取られないことを意味します。これが、特に専用のAIチームを持たない組織や、迅速に価値を提供したい組織にとって、SageMakerが魅力的なオプションである理由です。
5.2. インスタンス選択の重要性
Adam: SageMakerでインスタンスを選択する際、自己管理型環境とは少し異なるアプローチが必要です。自己管理型では主にベンチマークテストを行いますが、SageMakerでは何よりもまずワークロードタイプが重要な判断基準となります。
ワークロードの性質を明確に理解することが、適切なインスタンス選択への第一歩です。例えば、ノートブックを実行するのか、それともトレーニングを行うのか、あるいは推論を処理するのかによって、最適なインスタンスタイプは大きく異なります。私たちの経験では、この部分を正しく判断するだけで、コスト面で25%から35%もの削減効果が見られました。
例えば、通常のデータ探索やプロトタイピングには比較的安価な汎用インスタンスで十分ですが、大規模モデルのトレーニングには高性能なGPUインスタンスが必要です。また、推論ステージではモデルの複雑さやレイテンシー要件に応じて、コスト効率の高いCPUベースのインスタンスか、より高速なGPUインスタンスかを選択することになります。
私が実際にプロジェクトでよく見るケースでは、開発初期段階から最高性能のインスタンスを使用している例があります。これは必ずしも必要ではなく、例えば初期のモデル実験やデータ前処理段階では、より安価なインスタンスタイプで十分対応できることが多いのです。
Brent: Capital Oneでも同様の経験をしています。特に注目すべきは、適切なインスタンスタイプを選ぶことで、単にコスト削減だけでなく、ワークロードに最適化された性能を得られる点です。例えば、行列演算が多いワークロードには特定のGPUアーキテクチャが効率的で、テキスト処理中心のワークロードには別のタイプが適しています。
Adam: そうですね、Brent。SageMakerではAWSがインフラストラクチャを管理するため、私たちはテストよりもワークロードタイプに集中できます。これは特に、専門的なMLインフラストラクチャの知識が限られたチームにとって大きなメリットになります。Cosmoの例で言えば、夢の解釈プロセスに最適なインスタンスを選ぶことで、より効率的かつコスト効果の高いソリューションが実現できるのです。
5.3. モデル選択の影響
Adam: インスタンス選択の次に重要なのはモデル選択です。適切なモデルを選ぶことでパフォーマンスとリソース要件に大きな違いをもたらします。モデル選択では主に次の要素を検討すべきです。
まず、どのようなデータを扱うのかを明確にする必要があります。解決しようとしている問題の性質は何なのか。単純なテキスト処理だけなのか、それとも画像やオーディオを含むマルチモーダルなシナリオなのか。このデータタイプによって選ぶべきモデルが変わってきます。
次に、選んだモデルにどれだけのリソースが必要かを考慮します。リソースを大量に消費する「重い」モデルなのか、それともより軽量なもので十分なのか。私たちが顧客にアドバイスするのは、小さなモデルから始めて、モニタリングしながら必要に応じてスケールアップしていくアプローチです。
Brent: Capital Oneでの私たちの経験からも、モデル選択はインフラコストに直接影響します。同じ問題を解決する場合でも、選択するモデルによってGPU使用率や必要なインスタンスサイズが大きく変わることがあります。特に大規模な展開では、この差が年間予算に何百万ドルもの影響を与える可能性があります。
Adam: その通りです。もう一つの重要な側面は、公開されている無料または低コストのモデルを使用するか、独自の価格体系を持つプロプライエタリモデルを選ぶかという点です。これは単純なコスト比較ではなく、モデルの性能とビジネス要件のバランスを考慮する必要があります。
Cosmoの例で言えば、単純な夢の解釈には軽量モデルで十分かもしれませんが、詳細な心理分析や文化的背景を含む複雑な解釈には、より高度なモデルが必要になるでしょう。しかし、その場合はコストも比例して上がります。
モデルの選択において重要なのは、モデルの能力、リソース要件、そして予算のバランスを見極めることです。高価で強力なモデルが常に最適解とは限らず、むしろビジネスケースによっては、より軽量で効率的なモデルの方が全体的な価値を高めることがあります。私たちがプロジェクトで見てきた最大の無駄の一つは、必要以上に複雑なモデルを使用することによるオーバーエンジニアリングです。
5.4. SageMakerコミットメントの活用（最大64%のコスト削減）
Adam: インスタンスとモデルを選択した後に考慮すべき次のポイントは、再びコミットメントです。ここで重要な質問は「今後1年から3年間、継続してSageMakerを使用する予定はあるか？」ということです。もしそうであれば、SageMakerのコミットメントを検討することが非常に重要になります。
SageMakerのセービングスプランは、先ほど自己管理型環境で説明したインスタンスセービングスプランやコンピュートセービングスプランとは少し異なります。EC2、Fargate、Lambdaなどに適用される通常のセービングスプランと違い、SageMakerセービングスプランはSageMakerの使用量全体に適用されます。
Brent: それは興味深いですね。Capital Oneでは複数の環境を管理しているため、このような包括的なコミットメントは大きな利点になります。特に複数のプロジェクトやチームがSageMakerを使用している場合、その効果は倍増しますよね。
Adam: その通りです。SageMakerセービングスプランの素晴らしい点は、選択した期間や前払い金額に応じて、最大64%ものコスト削減が可能なことです。例えば、3年間の全額前払いのコミットメントでは最大の割引率が得られますが、前払いなしの1年間のコミットメントでも相当な節約が可能です。
これは一つのレバーで全体のコストを半分以上削減できる可能性があるため、SageMaker環境では必ず検討すべき選択肢です。仮に年間100万ドルのSageMaker支出があれば、適切なコミットメントで最大64万ドルの節約が可能となります。
また、SageMakerセービングスプランの利点は、使用するインスタンスタイプや機能に関係なく、すべてのSageMaker使用量に自動的に適用される点です。つまり、異なるプロジェクトでさまざまなSageMakerの機能を使用していても、すべてがカバーされます。
私が見てきた多くの組織では、AI戦略が明確になってきた段階で、これらのコミットメントを検討し始めます。Cosmoのような夢解釈AIがビジネスの長期的な部分になると判断した時点で、SageMakerコミットメントへの投資を検討することで、長期的なコスト効率が大幅に向上するのです。
5.5. Spotインスタンスの活用（最大90%の節約可能性）
Adam: SageMakerのもう一つの大きなコスト最適化の手段として、Spotインスタンスの活用があります。これは特にトレーニングワークロードで有効です。自己管理型環境でBrentが説明したEC2 Spotインスタンスと同様に、SageMakerでもSpotインスタンスを活用できますが、SageMakerのマネージド環境内で行えるのが大きな利点です。
基本的な考え方はシンプルです。ワークロードが中断されても問題ないか、営業時間外に実行できるか、あるいは一日の特定の時間帯に実行可能かを検討します。もしそれが可能であれば、Spotインスタンスを利用することでAWSの余剰キャパシティを活用し、最大90%のコスト削減が可能になります。
Brent: Capital Oneでは、特に大規模なバッチトレーニングジョブでSpotインスタンスを活用しています。最初は中断への対応に懸念がありましたが、SageMakerのチェックポイント機能を使用することで、中断されても以前の状態から再開できるため、実際には大きな問題にならないことがわかりました。
Adam: その通りです。SageMakerのSpotトレーニングは、チェックポイントを自動的に管理してくれるため、中断が発生しても簡単に再開できます。これは自己管理型環境では自分で構築しなければならない機能ですが、SageMakerでは組み込み機能として提供されています。
特に注目すべきは、可能な節約額の大きさです。最大90%という数字は、ここで説明している他のどの最適化手法よりも大きく、環境やソリューションに適している場合は大きなインパクトがあります。例えば、月に1万ドルのトレーニングコストがかかるワークロードがあれば、Spotインスタンスを使用することで理論上は9千ドルもの節約が可能です。
Cosmoの例で考えると、新しい夢解釈パターンのトレーニングやモデルの改良などは、必ずしもリアルタイムで行う必要はないかもしれません。これらのバッチジョブをSpotインスタンスで実行することで、大幅なコスト削減が可能になります。
もちろん、すべてのワークロードがSpotに適しているわけではありません。特にリアルタイムの推論や中断が許されない重要なトレーニングには向いていませんが、適切なユースケースでは、これほど大きな節約を実現できる手法は他にないでしょう。
5.6. 推論タイプの選択と影響
Adam: SageMakerにおける最後の重要な最適化要素は推論です。推論とは何かというと、モデルが以前見たことのないデータに対して結論を導き出す能力のことです。Cosmoの例で言えば、誰かが今まで遭遇したことのない夢や情報を持っていない夢について質問した場合、どれだけ良い回答ができるかということです。
SageMakerには主に4つの推論タイプがあり、それぞれにコストと性能のトレードオフがあります。まず最も高価なのはリアルタイム推論です。リアルタイム推論では、専用のエンドポイントが24時間365日稼働しており、実行している時間分のコストが発生します。しかし、その代わりに最速の応答時間、最低のレイテンシー、最も迅速な回答が得られるというメリットがあります。
Brent: Capital Oneでは、顧客対応のユースケースではリアルタイム推論を使用していますが、内部分析や長期的なプロジェクトではより費用対効果の高い選択肢を検討しています。顧客エクスペリエンスと内部効率のバランスが重要ですね。
Adam: その通りです。スペクトラムの反対側にあるのはサーバーレス推論です。サーバーレスでは、エンドポイントを常時稼働させるのではなく、リクエスト量に応じてスケールアップ・ダウンします。これの素晴らしい点は、一定の使用パターンがない場合、つまり使用量の変動が大きい場合に、リクエストがないときはゼロまでスケールダウンするので、エンドポイントに対してコストが発生せず、大幅な節約になります。
これら両極端の間に位置するのが、非同期処理とバッチ処理です。非同期処理は、大きなファイルタイプを含むリクエストやプロンプト、または最大1時間までの長い処理時間を要する場合に最適です。ただし、非同期処理の欠点は、リクエストが来た順番で処理されるため、その順序でしか処理できないことです。対照的に、リアルタイムやサーバーレスでは複数のリクエストを同時に処理できます。
バッチ処理については、リアルタイム性が必要ない場合に最適です。プロンプトを実行して回答を得る必要はあるけれど、研究目的で行っているのか、あるいは営業時間外に実行できるのであれば、バッチ処理は多くのコストを節約できます。一日のうちの異なる時間帯に小さなチャンクで処理を行えるからです。これはある意味、先ほど説明したSpotインスタンスと似た考え方です。
Cosmoの例を使って考えると、もし夢の解釈が即時に必要なければ、バッチ処理で過去の夢のパターンを分析し、それを基にした解釈を提供することで、コストを大幅に削減できるかもしれません。あるいは、使用量の変動が大きいなら、サーバーレス推論を使用して、需要に応じてリソースをスケールさせる方法も効果的です。
最終的には、ビジネス要件、予算、そしてユーザーエクスペリエンスの期待値に基づいて、最適な推論タイプを選択することが重要です。
6. 管理型サービス：Amazon Bedrock（Adam担当）
6.1. Bedrockの位置づけと単一APIによる基盤モデルの提供
Adam: SageMakerがバランスの取れた制御と性能を提供する一方で、さらにインフラストラクチャの管理を減らしたいケースもあるでしょう。ここでBedrockの登場です。Bedrockは単一のAPIを通じて高性能な基盤モデルを提供します。
Bedrockの最大の特徴は、シンプルさと使いやすさにあります。Cosmoの例で考えると、私たちは夢の解釈やアウトプットの質、それに顧客体験に集中できるようになり、ソフトウェア構成やツールといった低レベルの詳細に煩わされる必要がなくなります。
SageMakerからBedrockに移行する際の大きな考え方の転換は、インフラストラクチャの管理から使用量ベースの考え方へのシフトです。つまり、サーバーやインスタンスのセットアップや管理ではなく、使用するトークン数やAPIコールに焦点を当てるようになります。
Brent: 確かに、そのアプローチは興味深いですね。Capital Oneでは、一部のユースケースでインフラストラクチャの複雑さを減らしたいと考えています。特に迅速な展開が必要なプロジェクトでは、自己管理型のソリューションを構築する時間がない場合があります。Bedrockのような選択肢があると、そのギャップを埋めることができますね。
Adam: その通りです。Bedrockの大きな利点は、Anthropic、Meta、Mistral AI、そしてAmazon自体の基盤モデルなど、業界をリードする多数のモデルに単一のAPIでアクセスできることです。異なるベンダーの複数のモデルを試したい場合、各ベンダーごとに別々のインテグレーションを構築する必要はありません。
例えば、Cosmoで夢の解釈を行う場合、Anthropicのモデルで詳細な分析を実行し、同時にMetaのモデルで創造性豊かな解釈を提供するといったことが、同じコードベースと単一のAPIで可能になります。さらに、コード変更をわずか1行で済ませて異なるモデルを試すことができるのは、ビジネスニーズに応じて柔軟に対応できる大きなメリットです。
特に小規模なチームや、AIの専門知識が限られた組織にとっては、Bedrockのこのシンプルさが非常に価値のあるものとなります。インフラストラクチャの複雑さを気にせず、ビジネスロジックとユーザーエクスペリエンスの向上に集中できるからです。
6.2. 料金モデルのオプション
Adam: Bedrockの料金モデルは、先ほど説明してきた他のアプローチとは少し異なります。自己管理型やSageMakerなど時間単位でインスタンスに課金されるシステムと違い、Bedrockでは使用量ベースの料金体系となっています。Bedrockの料金モデルの素晴らしい点は、あなたがどのような状況にあっても柔軟に対応できることです。
まず最も基本的なオプションとしてオンデマンド料金があります。これはテスト段階にある場合や、ワークロードの予測が難しい状況で特に有効です。オンデマンドでは、選択するモデルによって料金が変動します。つまり、Anthropicのモデルを使うか、Amazon製のTitanモデルを使うか、あるいはMistral AIのモデルを使うかによって、入力トークンと出力トークンの料金が異なってきます。
Brent: それは興味深いですね。Capital Oneでは、予測可能な使用パターンを持つワークロードと、より変動的なユースケースの両方があります。この柔軟性は価値があると思います。
Adam: その通りです。入ってくるリクエスト量について大まかな予測がつく場合は、「Provisioned」と呼ばれるコミットメントタイプを利用できます。これはEC2やSageMakerの長期コミットメントとは異なり、わずか1か月または6か月の期間で設定できます。これらのコミットメントを通じて、特定の量のリクエストに対して専用のキャパシティを確保でき、大幅な節約が可能になります。
例えば、ChatBotのようなアプリケーションで毎月約10万回のリクエストを処理すると予測できる場合、その量に合わせたProvisionedコミットメントを購入することで、大幅なコスト削減が実現できます。一方で、使用量が予測を上回った場合は、オンデマンド料金で追加分が課金されるため、柔軟性も損なわれません。
Bedrockで利用可能な第三のオプションはバッチ処理です。これは既に他のセクションでも触れましたが、まとめてデータをBedrock送信し、分析させることで節約を実現できます。特に興味深いのは、モデルの選定においても重要な役割を果たすことです。
Brent: バッチ処理での節約率はどのくらいになりますか？SageMakerのSpotインスタンスのような劇的な違いはありますか？
Adam: バッチ処理での節約は、使用しているモデルと処理量によって異なりますが、通常はオンデマンド価格と比較して10%から30%程度の節約が見込めます。SageMakerのSpotほど劇的ではありませんが、特に大量のデータを処理する場合は無視できない金額になります。
私の経験では、たとえ優先モデルが既に決まっていて、本番環境で使用している場合でも、同じプロンプトをバッチ処理で異なるモデルに試してみることをお勧めします。これにより、モデル選択について後ほど説明する内容にも関連してきますが、より良いコストパフォーマンスのモデルを発見できる可能性があります。
6.3. モデル選択の重要性
Adam: Bedrockの大きな魅力は、Anthropic、Meta、Mistral AI、そして私たちAmazon自身のモデルなど、業界をリードする多数の基盤モデルを単一のプラットフォームで提供している点です。しかし、これほど多くの選択肢がある中で、適切なモデルを選ぶことがコスト最適化において非常に重要な要素となります。
モデルを評価する際に考慮すべき重要な要素は、コスト、速度、そして精度です。例えば、より軽量なモデルを使用して簡潔な回答を提供すれば、最終的には出力するトークン（単語）が少なくなるため、スケールメリットが大きくなります。Bedrockの料金体系はトークンベース、つまりおおよそ単語数に基づいているため、この点は重要です。
Brent: Capital Oneでの経験からも、モデル選択はROIに大きく影響します。特に顧客向けのユースケースでは、より高価なモデルを使って最初から的確な回答を提供することが、顧客満足度とコスト効率の両方につながることがあります。
Adam: まさにその通りです。モデル選択においては、単純な単価だけでなく、顧客体験全体を考慮する必要があります。私がBedrockでの開発を行っている人々によく伝えるのは、単一のモデルに固執しないことです。テストや本番環境用に好みのモデルがあっても、同じプロンプトを別のモデルにも試してみて、出力結果を比較することをお勧めします。
Bedrockの素晴らしい点は、コード変更をわずか1行で済ませて異なるモデルを試せることです。これにより、顧客やエンドユーザーにとって価値のある回答をより効率的に提供できるモデルを見つけることができます。最初の回答で質の高い情報を提供できれば、ユーザーが6回や8回もフォローアップ質問をする必要がなくなります。これだけでも大幅なコスト削減につながるのです。
Cosmoの例で考えると、単純な夢の解釈には軽量で費用対効果の高いモデルを使用し、より複雑な心理的な洞察が必要な場合には高度なモデルに切り替えるという戦略が可能です。同じプロンプトを複数のモデルで試し、コストとパフォーマンスのバランスが最適なものを選ぶことで、長期的に大きな節約が実現できます。
つまり、モデルの品質はコスト最適化において重要な要素なのです。一見すると高価なモデルを選ぶことがコスト増に思えますが、より効率的に価値ある回答を提供できるなら、全体的なコスト効率は向上します。
6.4. ナレッジベースの活用（RAG）
Adam: Bedrockはナレッジベースをサポートしています。皆さんの中には「検索拡張生成」（Retrieval Augmented Generation）、略してRAGという用語で聞いたことがある方もいるでしょう。これは専門知識でモデルを強化する簡単かつ効果的な方法です。
基本的には、モデルに特定分野の専門知識を付加することで、その分野のエキスパートとしての能力を高めることができます。Cosmoの例で考えると、城の建築様式に関するナレッジベースを追加することで、夢の中で城を建てるという質問に対して、より情報豊かな回答ができるようになります。
Brent: RAGは私たちCapital Oneでも注目している技術です。特に金融規制や内部ポリシーなど、一般的な学習データには含まれていない専門知識をモデルに追加する際に有効です。しかしコスト面での考慮点はありますか？
Adam: 重要な質問ですね。ナレッジベースを使用する際、コストをコントロールするために考慮すべき2つの重要な変数があります。1つ目は、提供するデータの量です。必要なデータのみを厳選し、余分なデータは含めないよう注意する必要があります。過剰なデータをロードすると、モデルが特定の任務に不要なデータまでインデックス化することになり、ストレージとインデックス作成料金の両方でコストが発生します。
2つ目の考慮点は、データの再インデックス頻度です。スケジュールや頻度を適切に設定することが重要です。新しい情報を探すために頻繁にインデックスを更新しているのか、それとも既にインデックス化されたデータを再度インデックス化しているのか？これらはナレッジベースを追加する際に行える重要な設定や調整です。
例えば、毎月更新される情報をナレッジベースに含める場合、毎日再インデックスするのは無駄なコストになります。また、増分更新を利用して、変更のあるデータのみをインデックス化することも効率的です。
これらは機械学習モデルの関連機能でありながら、注意しないと追加コストが発生しやすい領域です。私の経験では、適切に設計されたナレッジベースは、モデルがより的確な回答を生成することで削減できるコストと比較して、十分に価値のある投資となります。
特にCosmoのような専門的なアプリケーションでは、一般的な知識だけでなく、夢分析や象徴の解釈に関する専門文献を参照できることで、ユーザー体験が大幅に向上します。ナレッジベースを最適化することで、コストを抑えながらも質の高いサービスを提供できるのです。
6.5. ファインチューニングの効果
Adam: Bedrockのもう一つの強力な機能はファインチューニングです。先ほど説明したナレッジベースとは異なり、ファインチューニングでは単にデータを参照用に提供するのではなく、モデル自体を再トレーニングして知識を埋め込みます。
Bedrockはこのプロセスを非常に簡単にしています。データセットを指定するだけで、ファインチューニングを自動的に行ってくれます。その結果、より高精度な回答が得られるようになります。より正確な回答が得られれば、顧客やエンドユーザーは必要な情報をより速く入手でき、繰り返し質問する必要がなくなります。
Brent: Capital Oneでも、特に金融商品や社内プロセスに関する正確性が求められる領域でファインチューニングの価値を実感しています。しかし、コスト面でのトレードオフをどのように判断すべきでしょうか？
Adam: 優れた質問です。ファインチューニングには確かに初期コストがかかります。モデルの種類や、どれだけの量のデータでファインチューニングするかによって、数百から数千ドルのコストになる可能性があります。しかし、これは一度きりの投資と考えるべきでしょう。
コスト効率の観点から見ると、ファインチューニングされたモデルがより正確な回答を提供できることで、ユーザーの追加質問や修正依頼が減少します。例えば、標準モデルでは3回の対話が必要だった情報提供が、ファインチューニング後には1回で済むようになれば、トークン使用量は約1/3になる可能性があります。
Cosmoの例で考えると、夢解釈の特定パターンでファインチューニングを行うことで、より個人化された解釈を提供できるようになります。例えば、「空を飛ぶ夢」が文化によって異なる意味を持つ場合、それぞれの文化的背景に基づいた解釈を行えるようになるのです。
また、ファインチューニングには間接的なコスト効率化効果もあります。例えば、顧客満足度の向上、誤情報による問題の削減、サポートチームの負担軽減などです。これらの要素も含めて総合的に評価すると、多くの場合、長期的にはファインチューニングのROIは非常に高くなります。
ただし、すべてのユースケースでファインチューニングが必要というわけではありません。ビジネス要件、精度の要求レベル、そして予算を考慮した上で、投資対効果を慎重に評価することが重要です。
6.6. モデルディスティレーション（新機能）
Adam: 昨日Matt Garmanが発表した機能の一つに、モデルディスティレーション（モデル蒸留）があります。これはファインチューニングに関連する技術ですが、さらに進化した形と言えるでしょう。
モデルディスティレーションでは、一連のプロンプトをBedrockに提供すると、それらのプロンプトとその出力を分析し、その結果をもとに小型の、つまりより低コストなモデルをファインチューニングします。
Brent: それは興味深いですね。大企業では、品質を維持しながらコストを下げることが常に課題です。この新機能は実際にどの程度の効果が期待できるのでしょうか？
Adam: 発表によれば、モデルディスティレーションを利用することで、処理速度が約5倍速くなるか、あるいはコストが約5分の1になるとのことです。これは非常に大きな改善であり、Bedrockをより効率的に使用するための重要なアップグレードとなるでしょう。
具体的な仕組みとしては、例えば高性能で高コストなAnthropicのモデルを使って特定のタスクに関する多くの例を生成し、その結果をより軽量なAmazon Titanのようなモデルに「教える」というプロセスになります。これにより、特定の領域においては、より安価なモデルでも高性能なモデルに近い品質を実現できるようになります。
Cosmoの例で考えると、最初は複雑な夢解釈を高性能モデルで行い、その解釈パターンを学習させた軽量モデルを作成することで、日常的な夢解釈を低コストで提供できるようになります。特殊なケースのみ高性能モデルに振り分けるという階層的なアプローチが可能になるのです。
モデルディスティレーションの素晴らしい点は、高コストモデルの品質に近づきながらも、より高速かつ低コストで運用できることです。まだ新機能なので本番環境での実績は限られていますが、今後多くの組織にとって重要なコスト最適化手段になると期待しています。
特に大規模なAIデプロイメントを行っている組織にとっては、この技術を探求する価値は大いにあるでしょう。モデルディスティレーションをまだ検討していない方は、ぜひ調査してみることをお勧めします。
6.7. アプリケーション層での最適化
Adam: Bedrockに関連する最後の最適化ポイントはアプリケーション層です。Swamiが基調講演で触れた主要な手段の一つにプロンプトキャッシングがあります。ユーザーが非常に似た質問や繰り返し質問をするシステムでは、毎回モデルにその質問を送信する必要はありません。すでに回答したものをなぜ再度回答する必要があるのでしょうか？
プロンプトキャッシングはこの問題を解決します。同じような質問には、モデルに送信せずにすでに生成された回答を提供することで、追加コストを発生させることなく対応できます。これは特に同じような質問が頻繁に発生するユースケースで非常に効果的です。
Brent: キャッシングは興味深いアプローチですね。Capital Oneでは、FAQや一般的な問い合わせなど、パターン化された質問を扱うことが多いため、この手法は大きな節約につながる可能性があります。ただ、キャッシュのヒット率をどう最適化するかが課題になりそうです。
Adam: その通りです。効果的なキャッシング戦略を設計することが重要です。また、アプリケーション層でのもう一つの最適化手段として、トークンの前処理があります。先ほど説明したように、Bedrockはトークンベースの課金体系です。つまり、入出力される単語の量に基づいて料金が発生します。
ユーザーが非常に長い質問をする場合、前処理によってそれをスリム化し、余分な単語を削除することができます。1つのプロンプトではコスト差はわずかかもしれませんが、数万または数百万のリクエストに拡大すると、支払う金額に大きな違いをもたらします。
もう一つのオプションは後処理です。私はこのアプローチが好きで、受け取ったプロンプトや質問にコンテキストを追加します。Cosmoの例で言えば、誰かが「強い壁を作る最良の方法は？」と尋ねた場合、モデルは「木材と石膏ボードを使用します」と答えるかもしれません。しかし、実際に知りたかったのは「城の強い壁を作る最良の方法」かもしれず、その場合は「モルタルと石」などの回答が適切です。
構築するツールにコンテキストがあることがわかっている場合、接尾辞として追加するなどしてプロンプトを拡張することで、ユーザーがより意味のある回答を得られるようにすることができます。
これらの最適化手法は個別に見ればわずかな効果かもしれませんが、組み合わせると大きな影響を与えます。特にスケールが大きくなるほど、その効果は顕著になります。アプリケーション層での最適化はAI技術者の腕の見せどころであり、同じモデルとプラットフォームを使用していても、最適化の質によってコスト効率に大きな差が生まれるのです。
7. 完全管理型サービス：Amazon Q Business（Alex担当）
7.1. Q Businessの位置づけと特徴
Alex: Adamがナレッジベースの力と、Bedrockを使ったビジネスソリューションの構築方法について素晴らしく解説してくれました。これは私がこれから説明するAmazon Q Businessへの完璧な導入になっています。なぜなら、専門知識という概念をさらに一歩進めたのがQ Businessだからです。
Q Businessでは、完全管理型のスペクトラムにいます。これはCosmoで例えると、インフラストラクチャに関する決定に一切悩まされることなく、素晴らしい夢の解釈の作成に純粋に集中できるということです。これは私にとっても夢のような話です。
Adam: それは確かに大きな違いですね。プロンプトエンジニアリングや出力のチューニングに集中できて、基盤となるインフラストラクチャについて心配する必要がないのは大きな利点です。
Alex: その通りです。AIアプリケーションやCosmoを構成するさまざまな要素を考える代わりに、一つのことだけ、つまりQへの入力に集中できるのです。完全管理型サービスの美しさはそのシンプルさにあります。
Q Businessの最大の特徴は、ほぼすべてのインフラストラクチャとモデル関連の決定が自動化されているため、ビジネスユーザーが技術的な詳細を気にすることなく、生成AIの力を活用できることです。これは特に、IT部門や専門的なAIチームの規模が限られている組織にとって大きなメリットになります。
Brent: Capital Oneでは、テクニカルチームとビジネスチームの両方がAIソリューションを活用しています。完全管理型サービスは特に非技術系のビジネスユーザーに対して大きな可能性を開くと思います。彼らはインフラストラクチャの複雑さを理解する必要なく、すぐに価値を得ることができますからね。
Alex: まさにその通りです。Q Businessでは、複雑な技術的概念を理解することなく、エンドユーザーが直接AIとやり取りできます。例えば、財務チームは予算予測の支援を、マーケティングチームはコンテンツ作成の支援を、人事チームは採用プロセスの効率化を、それぞれ専門知識を持ったAIアシスタントから得ることができます。
また、Q Businessはデータセキュリティとプライバシーの側面でも優れています。企業の機密データをモデルに提供する際、適切なセキュリティレベルが確保されているのは重要です。完全管理型サービスであるQ Businessでは、こうした懸念に対するコンプライアンスが組み込まれています。
最終的に、Q Businessはシンプルさと使いやすさを優先することで、AIの採用障壁を大幅に下げています。Cosmoのようなソリューションを構築する場合でも、技術的な複雑さを心配することなく、コアビジネス価値の創出に集中できるのです。
7.2. 料金階層の選択（ライトvsフル、約85%のコスト差）
Alex: Q Businessの最適化レバーはかなり単純明快ですが、非常に大きな影響力を持っています。最初に検討すべきなのは料金階層です。Q Businessには、ライトバージョンとより強力なフルバージョンという異なるレベルがあります。
これは基本的に、何を求めているかによって選択が変わります。出力に視覚的要素を含めたいのか、それとも単純な回答だけで十分なのか。この2つのバージョン間には約85%ものコスト差があるので、非常に大きな違いがあります。
Brent: それはかなりの差ですね。Capital Oneでは、部門によって必要な機能レベルが異なるため、この柔軟性は価値があります。すべてのユーザーに最高レベルのアクセス権を与えるのではなく、実際のニーズに基づいて調整できるのは重要です。
Adam: この大きなコスト差は、実際の使用ニーズを慎重に評価する必要があることを示していますね。例えば、テキスト分析や簡単なドキュメント生成のみが必要なチームには、ライトバージョンで十分かもしれません。
Alex: その通りです。この決定はビジネスニーズに基づくべきです。Cosmoの例で考えると、単純なテキストベースの夢解釈でよいのか、それとも視覚的な要素を含む豊かな解釈体験を提供したいのか。このレベルの選択は、ユーザーエクスペリエンスとコストのバランスに大きく影響します。
また、社内の異なるチームに異なるレベルのアクセス権を付与することも可能です。例えば、クリエイティブチームには視覚要素を扱うフル機能版が必要かもしれませんが、データ分析チームにはテキストベースのライトバージョンで十分かもしれません。
重要なのは、すべてのユーザーにデフォルトで最高レベルのアクセス権を与えないことです。各ユーザーグループの実際のニーズを評価し、それに応じて適切な階層を選択することで、大幅なコスト削減が可能になります。私たちのある顧客は、この階層化アプローチだけで年間コストを40%削減することができました。
結局のところ、この85%というコスト差は非常に大きいため、慎重な検討が必要です。実際のビジネスニーズと予算に基づいて適切なレベルを選択することで、最大の価値を引き出しながらコストを最適化できます。
7.3. ユーザー管理の戦略
Alex: 料金階層を選択したら、次に考慮すべきは適切なユーザー管理戦略です。これは基本的に、誰がサービスにアクセスできるようにするかという問題です。全員が夢を解決したり、夢をマッピングしたりできるようにしたいのか、それとも中核となる「夢の専門家」グループだけにしたいのか。つまり、何人のユーザーを想定しているのか、そして組織内でどのように配分するのかを検討する必要があります。
Brent: Capital Oneでは、生産性向上ツールとしてのAIへのアクセスと、コスト管理のバランスを取ることが常に課題です。すべての従業員に同じレベルのアクセス権を与えるべきかどうか、あるいは役割やニーズに基づいて差別化すべきかという議論は興味深いですね。
Alex: その通りです。これはコスト最適化において見落とされがちなポイントです。Q Businessのようなサービスは通常、ユーザーあたりの料金体系になっていますので、アクセス権を持つユーザー数を戦略的に管理することが重要です。
実際のユースケースに基づいてアクセス権を付与する段階的なアプローチを検討してみましょう。例えば、カスタマーサービス部門では、お客様の問い合わせに迅速に対応するために全員がアクセスする必要があるかもしれません。一方、マーケティング部門では、コンテンツ作成に関わる特定のチームメンバーだけにアクセス権を付与するという選択もあります。
Adam: 興味深いアプローチですね。また、ユーザー管理戦略を時間の経過とともに進化させることも考えられますね。最初は限定的なパイロットグループからスタートし、価値が証明されたら徐々に拡大していくという方法も効果的かもしれません。
Alex: その通りです。段階的な展開戦略は非常に効果的です。また、ユーザー利用状況のモニタリングも重要です。アクセス権を持っていても実際にはほとんど使用していないユーザーがいるかもしれません。定期的な使用状況レポートを確認することで、未使用または使用頻度の低いライセンスを特定し、再配分または削減することができます。
最終的に、ユーザー管理は単なるコスト管理の問題ではなく、組織全体でAIの価値を最大化するための戦略的なアプローチです。適切なユーザーに適切なレベルのアクセス権を付与することで、コストを最適化しながらビジネス価値を最大化することができます。
7.4. コンテンツインデックス作成（新鮮さと規模のバランス、20〜35%のコスト影響）
Alex: コンテンツインデックス作成は、Adamが先ほどBedrockで説明したものと似ていますが、Q Businessにおいては少し異なる側面があります。この最適化レバーでは、情報をどれだけ最新に保ちたいか、回答をどれだけ詳細にしたいか、そしてナレッジソースの規模をどの程度にするかを検討します。
つまり、そこに保存する情報量、どれだけ最新で刺激的な情報を維持するか、あるいは非常に大規模なナレッジソースを作成するかどうかが重要です。これらの選択によって、コストに20%から35%の違いが生じる可能性があります。
Brent: Capital Oneでは、金融規制や社内ポリシーなど、常に最新の状態に保つべき情報と、より静的な履歴データがあります。このバランスをどのように取るべきでしょうか？
Alex: 優れた質問ですね。インデックス作成戦略を考える際、コンテンツの種類と更新頻度に基づいて段階的なアプローチを取ることをお勧めします。例えば、頻繁に変更される重要な文書は高頻度でインデックスを更新し、より静的なコンテンツは低頻度で更新するという方法が効果的です。
例えば、毎日更新される市場データは日次でインデックスを更新する必要があるかもしれませんが、過去の取引履歴や社内の知識ベースは月次や四半期ごとの更新で十分かもしれません。適切なインデックス更新頻度を設定することで、情報の鮮度を維持しながらコストを最適化できます。
Adam: インデックス作成とコストのバランスについて、特定のデータの重要性もポイントになりますね。すべてのデータが同じ価値を持つわけではなく、より重要で影響力のある情報に優先順位をつけることが効果的です。
Alex: その通りです。もう一つの重要な側面は、インデックス作成するデータの量です。ビジネスに直接関連する情報だけをインデックス化し、余分なデータは排除することが重要です。例えば、古い製品バージョンの完全なドキュメント一式ではなく、最新バージョンとその直前のバージョンのみをインデックス化するなどの選択が考えられます。
Cosmoの例で言えば、夢解釈に使用するナレッジベースには、最も一般的な夢のシンボルと最新の心理学的研究を含めるべきですが、古い理論や関連性の低い内容までインデックス化する必要はないでしょう。
ナレッジソースの規模、更新頻度、含めるデータの範囲を最適化することで、20%から35%のコスト差が発生します。この最適化は、情報の質と量のバランスを取りながら、ビジネスに本当に価値をもたらす情報に焦点を当てることが重要です。
7.5. アプリケーション統合の効率性
Alex: 最後の最適化ポイントは、アプリケーション統合です。これは、Q Businessがあなたの日常業務にどのように統合されているか、そしてそれを効率的に行っているかどうかということです。人々がCosmoアプリとどのようにインターフェイスしているのか、そしてそれらの層での効率性がどのように見えるのかということです。
Brent: Capital Oneでも、AIツールを既存のワークフローにどう統合するかが大きな課題です。単なる独立したツールではなく、現在のシステムとシームレスに連携させることが重要だと感じています。
Alex: その通りです。アプリケーション統合の効率性を考える際、ユーザーがQ Businessとどのようにやり取りするかを検討することが重要です。例えば、Slackや他のコラボレーションツール内からQ Businessにアクセスできれば、コンテキストの切り替えが減り、生産性が向上します。
これは単なる利便性の問題ではなく、実際のコスト最適化にも関わってきます。効率的な統合により、ユーザーは必要な情報をより迅速に取得でき、重複したクエリや非効率的な使用パターンが減少します。例えば、Q Businessが既存のナレッジマネジメントシステムと統合されていれば、同じ情報を探すために複数の検索を行う必要がなくなります。
Adam: また、APIを通じた統合も重要な側面ですね。他のアプリケーションがQ Businessの機能を直接呼び出せるようにすることで、自動化されたワークフローが可能になります。
Alex: まさにその通りです。また、ユーザーインターフェースの設計も効率性に大きく影響します。直感的で使いやすいインターフェースは、学習曲線を短縮し、ユーザーの採用率を高めます。これによって、投資対効果が向上し、全体的なコスト効率が改善します。
Cosmoの例で考えると、夢解釈AIがユーザーのカレンダーやノートアプリと統合されていれば、朝の夢を記録してすぐに解釈を得ることができます。このような統合されたエクスペリエンスは、ユーザーエンゲージメントを高め、システムの全体的な価値を向上させます。
最終的に、アプリケーション統合の効率性は、Q Businessのような完全管理型サービスからどれだけの価値を引き出せるかを決定する重要な要素です。技術的な統合を効果的に行うことで、ユーザーエクスペリエンスの向上とコスト最適化の両方を実現できるのです。
8. サポートサービスの最適化
8.1. ストレージ選択の影響（例：S3 Express One Zone）
Alex: ここからは、どのようにAIアプリを構築するかに関わらず考慮すべき要素について話しましょう。どのアプローチを選んでも、インターフェイスやストレージなど、他の要素のバランスを取る必要があります。まずストレージから見ていきましょう。
ストレージの選択は、AIアプリケーションのパフォーマンスとコストに大きな影響を与えます。何かを超高速でアクセスしたい場合、頻繁にアクセスされるデータには、S3 Express One Zoneのような高速ストレージを使用できます。これにより取得が速くなりますが、コストは高くなります。
重要な問いかけは「それは本当に必要なのか？」ということです。例えば、AIモデルが即座に参照する必要がある重要なデータセットには高速ストレージが適していますが、あまり頻繁にアクセスされないアーカイブデータには標準的なS3やさらに安価なS3 Glacierクラスが適しているでしょう。
Brent: Capital Oneでも、データの階層化が重要な戦略になっています。すべてのデータが同じ頻度でアクセスされるわけではないので、アクセスパターンに基づいてストレージを最適化することで、パフォーマンスを維持しながらコストを削減できます。
Alex: その通りです。ユーザーエクスペリエンスとコストのバランスを取ることが重要です。Cosmoの例で考えると、よく参照される一般的な夢のシンボルデータは高速ストレージに保存し、詳細な歴史的解釈や統計データなどは標準的なストレージクラスに保存するというアプローチが考えられます。
また、ライフサイクルポリシーを設定することも重要です。例えば、最初の30日間は高速ストレージに保存し、その後標準ストレージに移行、さらに長期間アクセスがなければアーカイブストレージに移動するといった自動化が可能です。
Adam: もう一つの考慮点は、ストレージの冗長性と耐久性ですね。S3 Express One Zoneは単一のアベイラビリティゾーンに保存するため速いですが、標準のS3と比較すると耐久性は低くなります。ユースケースによってはこのトレードオフが許容できない場合もあります。
Alex: 重要な指摘です。結局のところ、ストレージの選択はAIアプリケーションの性質、データアクセスパターン、そして許容できるレイテンシーとコストのバランスによって決まります。適切なストレージを選択することで、全体的なパフォーマンスを最適化しながらコストを抑えることができるのです。
8.2. ベクトルデータベースの活用（OpenSearch Serverless）
Alex: 次に重要なサポートサービスとして、ベクトルデータベースがあります。これはCosmoが夢の知識ベースをどこに保存するかという問題です。OpenSearch Serverlessを使用することで、より豊かな夢の解釈を作成できますが、これが本当に必要なのかを考える必要があります。
ここでも、ユーザーエクスペリエンスと、アプリケーションの出力に何を期待するかによって判断が変わります。ベクトルデータベースは、特にRAG（Retrieval Augmented Generation）アプローチを使用する場合、AIアプリケーションのパフォーマンスに大きな影響を与えます。
Brent: Capital Oneでは、ベクトルデータベースが特に金融データの類似性検索において重要な役割を果たしています。しかし、適切なサイジングとスケーリングは常に課題です。インデックスのサイズと検索性能のバランスをどのように取るべきでしょうか？
Alex: 優れた質問です。OpenSearch Serverlessのような管理型サービスを使用する場合、基盤となるインフラストラクチャを管理する必要はありませんが、設計上の決定は依然として重要です。まず考慮すべきは、インデックスに含めるデータ量です。不必要に多くのデータをインデックス化すると、コストが増加し、検索性能が低下する可能性があります。
また、ベクトルの次元数や埋め込みモデルの選択も重要です。例えば、より小さな次元数（例：384次元）を持つ埋め込みモデルは、より高次元（例：1536次元）のモデルよりも少ないリソースで処理できる場合があります。パフォーマンスとコストのバランスを考慮して選択することが重要です。
Adam: さらに、クエリの最適化も重要な要素ですね。例えば、k-NNアルゴリズムでは、検索する近傍数（k値）を適切に設定することで、精度を維持しながら処理時間とリソース使用量を削減できます。
Alex: その通りです。OpenSearch Serverlessの利点の一つは、使用量に基づいてスケールすることです。これにより、トラフィックが少ない時間帯にはリソースが自動的に縮小され、コストが削減されます。しかし、これを最大限に活用するためには、使用パターンを分析し、必要に応じて手動でキャパシティを調整することも検討すべきです。
Cosmoの例では、夢解釈に関連するすべてのコンテンツをベクトル化するのではなく、最も関連性の高いコアコンテンツに焦点を当て、必要に応じて拡張するという戦略が効果的かもしれません。このように、ベクトルデータベースを戦略的に使用することで、パフォーマンスとコストのバランスを最適化できるのです。
8.3. データ転送コストの考慮（グローバルvsローカル展開）
Alex: データ転送は、多くの場合見落とされがちなコスト要因ですが、特にグローバル展開を考える場合には重要です。基本的な問いかけは「これはグローバルなアプリケーションなのか？」ということです。異なる国の人々が夢の計画を立てられるようにしたいのか、それとも現在のオフィスの人々だけを対象にしたいのか。どのようなアプローチを取るにしても、データ転送が関わってきます。
Brent: Capital Oneでは、グローバル展開と地域特化のバランスが常に課題です。特に金融データのような機密情報を扱う場合、リージョン間のデータ転送には規制上の考慮点も関わってきます。コスト面以外の要素も検討する必要がありますね。
Alex: 非常に重要なポイントです。データ転送コストを考える際には、単純な金銭的コストだけでなく、データレジデンシー要件やコンプライアンスなどの規制面も考慮する必要があります。
AWS内でのデータ転送にはいくつかの側面があります。まず、同じリージョン内の異なるアベイラビリティゾーン間のデータ転送は比較的安価です。一方、異なるリージョン間のデータ転送はかなりコストがかかります。また、AWSからインターネットへのデータ転送（エグレス）も、転送量に応じて高額になる可能性があります。
Adam: グローバルアクセラレーターやCloudFrontなどのサービスを使用して、レイテンシーを低減しながらデータ転送コストを最適化する方法もありますね。これらのサービスは、キャッシュやエッジロケーションを活用して、繰り返しのデータ転送を減らすことができます。
Alex: その通りです。データ転送を最適化するためのいくつかの戦略を紹介しましょう。まず、データをユーザーの近くに配置することです。これはCloudFrontのようなCDNを使用するか、複数のリージョンにアプリケーションをデプロイすることで実現できます。次に、不必要なデータ転送を減らすために、データを圧縮したり、必要なデータのみを転送するよう最適化したりすることが重要です。
Cosmoの例で考えると、大量の夢解釈データを世界中のユーザーに提供するアプリケーションの場合、各地域にデータをキャッシュしたり、地域ごとのモデルをデプロイしたりすることで、コストとパフォーマンスのバランスを取ることができます。
最終的に、AIアプリケーションのグローバル展開を計画する際には、データ転送コストを予算と設計の段階から考慮することが重要です。これにより、大規模なデプロイ後に予期せぬコスト増加に悩まされるという事態を避けることができます。
8.4. 分析の重要性（精度追跡、プロンプト効率性の測定）
Alex: 最後に取り上げるサポートサービスは分析です。これは単に「分析があるといいね」というレベルではなく、AI最適化の核心部分です。分析は精度をどのように追跡しているのか、アプリケーションの成功度をどう測定しているのか、ユーザーがAIアプリに対して何回プロンプトを入力する必要があるのかを把握するためのものです。この分析レイヤーを実行して効率性を追跡し、改善や成功を確認することが重要です。
Brent: Capital Oneでは、AIシステムの効果を測定するために複数のメトリクスを追跡しています。特に興味深いのは、ユーザーが望む回答を得るためにどれだけの対話が必要かという点です。これはコストと満足度の両方に影響します。
Alex: その通りです。効果的な分析フレームワークでは、いくつかの重要な指標を追跡する必要があります。まず、精度や関連性の測定です。AIの回答が実際にユーザーの質問に答えているか、そして正確かどうかを評価します。次に、プロンプト効率性の追跡です。ユーザーが満足のいく回答を得るまでに必要なプロンプトの回数を測定します。
Adam: また、モデルのパフォーマンス指標も重要ですね。レイテンシー、トークン使用量、APIコールの頻度などを追跡することで、パフォーマンスのボトルネックを特定し、最適化の機会を見つけることができます。
Alex: その通りです。もう一つ重要なのはユーザーエンゲージメントの測定です。例えば、リテンション率、セッション長、機能使用率などを追跡することで、ユーザーが実際にどのようにアプリケーションを使用しているかを理解できます。
これらの分析データを活用することで、AIシステムを継続的に改善できます。例えば、特定のタイプの質問で精度が低い場合、そのドメインのトレーニングデータを増やすか、プロンプトエンジニアリングを改善するといった対策が可能です。
Cosmoの例では、どのタイプの夢の解釈がユーザーにとって最も価値があるのか、どのような質問が繰り返し行われているか、そしてそれらの質問に対する回答の品質を追跡することで、サービス全体の質を向上させることができます。
最終的に、分析は単なる報告ツールではなく、AIシステムのコスト効率と有効性を継続的に向上させるための戦略的資産です。適切な分析フレームワークを構築することで、費用対効果を最大化しながら、ユーザーエクスペリエンスを向上させることができるのです。
9. まとめ
9.1. 最適化フレームワークの総括
Alex: これまで私たちが話してきた内容を整理したスライドがこちらです。携帯電話を取り出して写真を撮っておくことをお勧めします。カラースキームが美しいだけでなく、私たちが話し合ってきたすべての内容を適切にまとめているからです。
Adamが先ほどSageMakerとBedrockについて説明したように、AIの世界は非常に速いペースで進化しています。昨日も多くの新機能が発表されたように、皆さんもAIに関するあらゆる側面で急速にイノベーションを進めていると思います。
そのため、私たちは新機能や新製品が発表されても一貫性を保てるようなカテゴリーを見つけようとしました。アプローチが少し異なるかもしれませんが、基本的な最適化の原則は変わりません。
Brent: このフレームワークは、私たちCapital Oneでも採用している考え方と共通していて素晴らしいですね。最適化は一度きりの取り組みではなく、継続的なプロセスであることが重要です。特に急速に変化するAI技術においては、定期的に戦略を見直し、新しい機会を活用することが不可欠です。
Alex: その通りです。また、先ほど説明したKPI（主要業績評価指標）も変わりません。レスポンス速度、リソース効率性、信頼性と柔軟性、そして品質と深さ。これらの指標は、新しい発表に対応するために何度スライドを作り直さなければならなくても、変わることはありません。しかし、これらの指標はあなたが行うすべての新しい決定において考慮することが重要です。
Adam: フレームワークの美しさは、自己管理型から完全管理型まで、どのようなアプローチを取るにしても適用できる点です。各層で最適化レバーは異なりますが、同じ基本原則が適用されます。
Alex: 最後に、夢が叶うと言えば、皆さんにも私たちの夢を叶えていただければと思います。AWSイベントアプリでセッションの評価を行っていただければ幸いです。Cosmoが言うように、「不可能な夢はすべて一歩から始まります」。この場合は、5つ星評価のための5回のクリックです。
今日は皆さんに最適化について少し詳しくお話しする機会をいただき、本当にありがとうございました。引き続き質問があれば、セッション後もここにいますので、お気軽にお声掛けください。スライドの写真や追加情報が必要な場合も、お手伝いします。このセッションが皆さんのお役に立てば幸いです。ありがとうございました。
9.2. 変化するAI環境における一貫した評価基準
Alex: AIテクノロジーは驚異的なスピードで進化していますが、それを評価する基準は一貫していることが重要です。私たちが先ほど説明したKPIは、いかなる技術変化があっても変わらない評価の柱となります。
まず「レスポンス速度」ですが、これはユーザー体験の根幹を成すものです。夢解釈を依頼したユーザーがどれだけ迅速に回答を得られるか、そしてその速度が期待値を満たしているかどうかが重要です。技術の進化によって期待値も上がっていくことを念頭に置く必要があります。
Brent: Capital Oneでは、特に顧客対応のユースケースにおいてレスポンス時間が重要視されています。顧客の満足度と直接結びつくため、技術が変わっても常に監視すべき指標です。ただ、速度と質のバランスをどう取るかは常に課題ですね。
Adam: その通りです。「リソース効率性」も普遍的な指標です。コストパフォーマンスは、どのようなテクノロジーを使っていても常に評価すべき要素です。新しいモデルやサービスが登場しても、投入した資源に対してどれだけの価値を生み出しているかという視点は変わりません。
Alex: 「信頼性と柔軟性」も重要です。Cosmoは世界中どこからでも使えるのか、特定のリージョンでしか使えないのか、どれだけ柔軟に展開できるのかという点は、技術的な実装方法が変わっても評価し続けるべき要素です。
さらに「品質と深さ」。単に「ツリーハウスを作りたい」という要望に応えるだけでなく、「太陽光パネルを備えた持続可能なツリーハウスを熱帯雨林に作りたい」というような複雑な要求にも対応できる質の高さが求められます。この評価基準は、モデルや技術が進化しても変わりません。
これらの一貫した評価基準を持つことで、新しい技術やサービスが登場したときにも、冷静に比較検討することができます。また、自社のAIソリューションが時間とともにどのように進化しているかを追跡するためのベースラインとしても役立ちます。
最終的に、AIテクノロジーの急速な進化の中でも、これらの評価基準を一貫して適用することで、ビジネス価値の創出と効率の向上という本質的な目標を見失わずに済みます。それこそが、変化するAI環境で成功するための鍵なのです。