re:Invent 2024: AWSとNew RelicによるGenerative AI製品戦略
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Making great products with generative AI (SEG102)
この動画では、AWSのHead of Worldwide ISV Product Management TransformationのJeffrey HammondとNew RelicのGroup Vice President of Engineering Telemetry Data PlatformのSuraj Krishnanが、Generative AIの製品戦略について解説します。企業がGenerative AIを活用する際の2つのアプローチ（業務改善と製品組み込み）を紹介し、New Relicの事例では1日7ペタバイトのデータ処理を行う中でのAI活用方法を具体的に説明します。特に、Developer Productivity向上による15%の生産性向上や、クラウドコスト最適化による年間400-500万ドルの節約など、具体的な成果が示されています。また、Foundation Modelの構築やFine-tuningではなく、Prompt EngineeringやRAGから始めることの重要性など、実践的な知見が共有されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWSのJeffrey HammondとNew RelicのSuraj Krishnanによる自己紹介
みなさん、こんにちは。Jeffrey Hammondと申します。AWSのHead of Worldwide ISV Product Management Transformationを務めております。私の仕事は、お客様である製品開発チームと協力して、彼らが設計する体験について多くの時間を費やすことです。ご想像の通り、その多くの体験は、製品戦略の一部としてGenerative AIを活用することに関連しており、本日はそれについてお話しさせていただきます。
また、こちらのSurajをご紹介させていただきます。「みなさん、こんにちは。お会いできて光栄です。Suraj Krishnanと申します。New RelicのGroup Vice President of Engineering Telemetry Data Platformを務めております。」Surajは、Generative AIを適用する際の個別企業の製品体験について、より詳しくご説明させていただきます。
ソフトウェア企業におけるGenerative AIの活用戦略
まずは、少し広い視点からお話しさせていただきます。先ほど申し上げたように、私は様々なお客様とお話をする機会に恵まれています。今日は、多くのソフトウェア企業がGenerative AIにどのようにアプローチし、それを製品戦略の一部としてどのように活用しているのかについて、私たちの見解をお伝えしたいと思います。 私が行っているユースケースに関する会話の中で、よく見られる傾向として、ほとんどのソフトウェア企業が2つの異なるタイプのユースケースを見出し、それらを全く異なる方法で扱っているということがあります。
まず、最適化の取り組みについてお話ししましょう。これは、企業自体がビジネスを推進する製品を効果的に提供する方法の業務改善に焦点を当てています。業務改善に関して、よく見られる投資対象としては、カスタマーセルフサービス、Revenue Operationsの改善、販売する製品のマーケティング戦略やGo-to-Market機能の一部となるコンテンツの作成などがあります。また、リード開発業務や全般的なソフトウェア製品開発においても、Generative AIが活用されているのを目にします。
Generative AI技術を始めたばかりの企業の多くは、これらのユースケースに注力する傾向にあります。実は、これらの投資からの見返りは他の選択肢と比べて低めになる傾向があるのですが。これは、多くのユースケースが比較的リスクが低いためです。Generative AIをどのように活用できるのか、どのように取り組めるのかを理解しようとする初期段階では、人間が介在することで、お客様が突然の課題やハルシネーション（AI の誤った出力）にさらされるリスクを軽減できるため、このアプローチは理にかなっています。
Amazonの例から始めましょう。これは一見思いつかないかもしれませんが、合成テストデータの生成についてです。Amazon Oneをご存知ない方のために説明すると、これは手のひらの静脈を読み取って店舗での会計を可能にするサービスです。この技術を実用的なものにするために必要な耐久性とミッションクリティカルなレベルに到達するには、文字通り何百万もの手のひらのデータでテストを行う必要があります。100万の手のひらのデータを見つけ出し、キャプチャーして、テストスイートの一部として利用可能にするために必要な時間と労力を想像できますか？
最近、金融サービス分野のお客様と仕事をしていた際、彼らが言及していたのは、顧客が数百万人規模の顧客基盤と、場合によっては1日に数千万件のトランザクションまでスケールできるインフラを求めているということでした。彼らは、現在取引している企業顧客にこれが可能だということを証明するために、このインフラを構築し、テストを実行し、そして解体するための環境を整える必要があります。これは合成テストデータを使用する生成的テスト技術の理想的な適用例であり、テストデータ生成の問題とDevOpsおよび自動化の課題が組み合わさったものです。
もう一つの例は、Amazon Q Developerによる開発の高速化です。自社のソフトウェア開発プラクティスをより効果的にする能力は、これらの例で見てきたように非常に重要です。このプレゼンテーションを通じてお気づきかもしれませんが、 re:Inventから戻ってきてこれらのプレゼンテーションがウェブサイトに公開されると、下部にたくさんのリンクが表示されます。
これらのリンクをクリックすることで、これらのユースケースについてより深く掘り下げることができます。内部の業務改善に焦点を当てたこれらの取り組みでは、開発速度が25%向上し、開発者の生産性が最大40%向上し、開発者のコード受け入れ率が37%向上し、反復的なタスクの自動化が12%向上するという結果が出ています。これは、社内での実践方法を学ぶにつれて、自社製品にこれらのテクノロジーを組み込むことを考える際に非常に重要になってきます。Evidenの場合、レガシーコードを数分で近代化し、自社製品の開発・販売にかかる運用コストを全体的に削減することができます。
これも興味深い話ですが、製品チームの視点からより戦略的なユースケースは、これらのテクノロジーを自社の製品に組み込み、全体的な製品戦略の一部とすることです。私はこの点についてチームと深い議論を交わすことが多いです。その適用例には、生成的テクノロジーを活用して既存の強みをさらに特別なものにする差別化への投資、ChatbotやCopilotのような新製品による成長の創出、ユーザーエクスペリエンスの効率化などがあります。よく耳にするフレーズに「Toil reduction（作業負荷の削減）」があります。私たちは顧客の顧客が抱える作業負荷を自動化によって削減し、その削減された作業負荷を通じて、顧客にとってより差別化された体験を生み出すことができます。これについては後ほど例を見ていきます。また、自動化の改善、運用データの要約、さらには最近多くの企業が注目し始めているダークデータの活用なども含まれます。
製品戦略におけるGenerative AIの実践的応用
Appianは興味深い事例です。彼らが最初にSemantic Searchの開発に取り組んだとき（これは私たちがよく目にする生成技術のユースケースの1つです）、自社のドキュメントとカスタマーサポート資料を活用しました。これは運用面でのユースケースの1つと考えられますが、彼らはその経験を活かして、その情報を製品に組み込み、さらに製品自体からのデータで補強することで、より強力なハイブリッド検索機能を作り上げました。これにより、顧客がデータとAnalyticsを効果的に活用する方法を選択できるようになりました。
もう1つの例がAlidaです。Alidaについてご存じない方のために説明すると、彼らは衣料品小売店のような実店舗製品を持つ顧客にサービスを提供しています。顧客が製品についてコメントし、製品の良い点や問題点を指摘すると、Alidaはその情報を要約してインサイトを作成し、Alidaの顧客である企業のProduct Managerに提供します。これにより、顧客満足度に関する潜在的なトレンドや問題、課題を特定することができます。この素早い要約機能により、Product Leaderが顧客の視点から何が問題なのかを理解するために膨大な情報を確認しなければならない手間を大幅に削減できます。
また、私が実行可能なアーティファクト生成と呼ぶものへの投資も増えてきています。SnapLogicはその良い例です。実行可能なアーティファクトというと、PythonやJavaなどのプログラミング言語によるコードを思い浮かべがちですが、製品に強力なメタモデルやデータ型の定義がある場合、実行可能なアーティファクトを生成し活用する能力は、顧客にとって非常に強力な成果をもたらすことができます。SnapLogicの場合、その実行可能なアーティファクトはパイプラインであり、製品がそれを実行して、他の組織との統合のスピードを加速することができます。
これらの様々なテクニックを組み合わせることで、非常に効果的な製品戦略を作り出すことができます。Greenhouseはその素晴らしい例で、リンク先で彼らのCEOが生成技術の活用方法について語っています。求人情報の生成から始まり（これは自然言語生成です）、テストや面接の質問の生成（これも自然言語生成ですが、より高度になります）、提出された履歴書の意図を評価する（これは自然言語理解です）といった具合です。
DEIの成果を向上させ、履歴書を匿名化する技術は、より良い採用結果につながります。これは、Responsible AI実践を投資に適用した良い例です。自然言語による質疑応答機能により、採用の意思決定者は候補者に関する情報に素早くアクセスでき、これは作業負担削減の良い例です。採用プロセスにおける面接のスケジューリングを自動化し、その手間を省く機能は、実行可能なアーティファクト生成の好例です。
あらゆる製品において、次のような問いかけをすることができます：NLGの機会はどこにあるのか？NLUの機会はどこにあるのか？製品構築の基盤となるメタモデルの中で、実行可能なアーティファクトはどこにあるのか？タスクを自動化し、作業負荷を軽減し、未活用データを活用するために、責任ある方法でこれらを実現する必要があります。 成果を生み出すためにこれらのテクノロジーを製品に組み込むことを考える際、この journey で先行している企業は大きな進展を見せています。McKinseyによると、これらのテクノロジーは15〜40%の追加的な経済効果をもたらす可能性があります。また、20社に1社が、Generative AIへの投資によって税引前利益が約10%増加したと報告しています。
Generative AI導入に必要なスキルとデータ管理の重要性
これらのISVはどのようにしてそれを実現しているのでしょうか？どのような投資を行っているのでしょうか？ スキルの観点から見ると、まず誰もが必要とする能力から始まります。最も明白なのは、優れたPrompt Engineeringを行う能力です。ほとんどのC-levelの方々は、自社の製品設計にどのような影響を与えるかを考えられるよう、適切なプロンプトを書けるようになるべきだと考えています。その上に補完的なスキルがあります。「この回答は正しく見えるか？」といった質問ができる必要があります。価値のある回答を提供しているかどうかを理解しようとする際には、批判的思考力が求められます。
その他の一般的なスキルには、データを価値に変換する能力、作業負荷の削減とタスク自動化のためにプロセスを再設計・最適化する能力、そして成功的な変更管理プロセスを通じて変更を実装する能力が含まれます。これは大きな変革であり、これらのプロセスを管理できない場合、多くの企業が苦戦し始めることがわかっています。 実装の一つの方法として、Community of PracticeやCenter of Excellenceモデルがあります。このモデルは、HRやFinanceなどの組織でよく見られます。これらは専門の組織ですが、ソフトウェア企業の全員が、問題を起こさず適切に収益を報告できるよう、FinanceとHRについて十分な知識を持っている必要があります。
Center of Excellenceは、ベストプラクティスが組織全体に組み込まれることを保証します。現在、Generative AIでも同様の動きが見られ、異なるLLMやマルチモーダルルーター、個別のデータストアを接続したり、開発の一部として使用できる単一のData Lakeにデータを取り込んだりする機能など、多くの共通サービスを担当するコアチームが存在します。これらのテクノロジーは、共有サービスモデルを使用して個々のプロダクトチームに組み込まれています。設計の観点からも、これらのテクノロジーを製品に組み込む際には、異なる設計パラダイムを採用する可能性があります。ここで、全く異なる2つの例を紹介したいと思います。どちらも間違いではありません。ただし、お客様が皆さんの投資をどのように活用するかという点で、異なる結果をもたらします。
まずCanvaから始めましょう。Canvaは、私が没入型アプローチと考えるものを採用しており、Generative AI機能を主力製品に融合させています。これから約1分間再生しますので、Generative AI機能が登場する箇所の数を数えていただきたいと思います。
ここで簡単な挙手をお願いしたいと思います - Generative AIの機能が5つ以上あったと気づいた方は？ ほとんどの方が手を挙げていますね。では10個以上見つけた方は？ おそらく半分くらいですね。私は通常10個か11個くらいカウントします。重要なポイントは、顧客がGenerative AIを使うために別の体験をする必要がなく、製品の一部となって製品自体を強化しているということです。
なぜこれが重要なのでしょうか？皆さんが作っている製品の価格設定を考える際、いずれはGenerative AIへの投資に必要なコストを正当化する必要が出てきます。主力製品でそれを行うのでしょうか？それとも別製品として販売しようとするのでしょうか？そして、Go-to-Market戦略を組み立てる際に、それがどのように成功に影響するのでしょうか？
これは私たちがよく目にする、より一般的なものです - ブランド化されたCopilotやSalesforce Einstein、会計分野であればJust Ask ZeroやJaxといったものです。Copilotの場合は、ペアプログラミングの体験により近く、アシスタントが私をサポートしてくれます。これらの体験は、インタラクションの面でよりテキスト的な傾向があります。私がCopilotに何かを依頼すると、それを実行してくれ、会話的な要素が含まれています。このように、皆さんが実装を検討する際は、自社の顧客基盤を見て、これらの体験のうちどれが、製品に求める機能と差別化を実現できるかを考えてください。
New RelicにおけるGenerative AIの社内活用事例
Generative AIの体験をデザインする際に私たちが発見しているもう一つのことは、組織が非常に早い段階で、使用したいデータに関する問題に直面するということです。考えてみてください。Generative AIで差別化を図りたい場合、データに差別化の要素があります。なぜなら、そのデータはユニークで、競合他社が入手するのは困難だからです。そして、顧客が持つユニークなデータの活用を支援できれば、それを使って差別化を図ることができます。私が関わっているある顧客は、その顧客企業が数十年分の建設図面や設計図をファイルキャビネットに保管しており、新規顧客向けの新しいデザインに取り組む際に、それらすべてにAIの活用可能性があります。現在のデザイナーやCAD技術者の前に在籍していた全てのデザイナーの知見を活かすために、どのようにしてそのデータを価値あるものにできるでしょうか？
したがって、Generative AIで成功するためには、データを確実に管理し、テクノロジー自体が使用できる状態にする必要があります。そのためには、ソフトウェア企業には多くの機能が必要だということが分かってきています。
ソフトウェア企業には、データを収集し、クリーニングし、その品質を維持する能力が必要です。汚れたデータからは、AIのハルシネーション（幻覚）が生じてしまいます。特に実行可能なアーティファクトに使用する場合は、データにアノテーションを付け、Generative AIテクノロジーにその意味を教える必要があります。製品に含まれる要素の文法を教える必要があるのです。さらに、バージョン管理を行い、適切なデータの系統を確保する必要があります。これらの条件が整って初めて、Generative AI戦略を効果的に展開できる態勢が整うのです。
ここで、組織が成功するために必要な技術的スキルについて考えてみましょう。 データに関して考慮すべき重要な点の一つは、共通のデータプラットフォームやデータレイクを構築する際に適用する基本原則を確立することです。まず最初に必要なのは、データ自体を一つのプロダクトとして扱い始めることです。この点については、特に金融サービス業界で頻繁に議論しています。
金融サービスのトレーディングプラットフォームが取得する膨大なデータと、それが他の組織にどのように活用できるかについて考えてみてください。しかし、ここで基本的な疑問が生じます：そもそも彼らはそのデータを使用できる態勢が整っているのでしょうか？データプロダクトを販売できる体制は整っているのでしょうか？そもそもデータの所有権は彼らにあるのでしょうか、それとも顧客のものなのでしょうか？これらの課題を解決する必要があります。顧客がデータを所有している場合、プライバシー、同意、機密性を尊重し、どのデータセットが異なる視点や製品を生み出すために使用できるのかを理解する必要があります。
天候データは良い例です。数週間前に農業分野の顧客と話をしていましたが、彼らの顧客が得る全てのデータと、農業産業における気象結果に基づいて情報に基づいた意思決定を行う可能性について考えると、その影響は非常に大きいものです。そして、「ノー」とは言わず、適切な条件付きで「イエス」と言えるガバナンス体制をどのように構築するかという課題があります。
ソフトウェア企業にとって、Generative AI戦略には特に注意を払うべき細かな点があります。データプライバシーの問題を解決し、誰が何を所有しているかを理解することは、組織が克服しなければならない最初の課題の一つです。その直後によく話題に上がるのが、複数のモデルを使用する能力です。例えば、数週間前にオーストラリアのある顧客と仕事をしていた際、彼らにとって非常に重要だったのは、ユースケースで特定の精度レベルに到達することでした。なぜなら、その精度に達しなければ、顧客にとって有用なものにならないからです。
異なるモデルによって、それぞれの状況で異なる精度レベルを達成することができます。すべての個別のユースケースに対して、一つのサイズですべてに対応できるわけではありません。これは、より先進的なソフトウェア企業が、プロダクトチーム向けの共通サービスとして、このようなマルチモデルインフラストラクチャを構築し始めている理由の一つです。柔軟性も重要な考慮事項です。プロトタイピングでは、Amazon Bedrockのようなツールを使用することで、組織は非常に迅速に進展を図ることができます。しかし、スケールアップを始め、機能が製品に組み込まれていく中で価格が重要になってくると、時には組織がAmazon SageMakerのようなより低レベルのアプローチに移行し、スケールでの運用コストをより柔軟にコントロールできるようにすることがあります。
一般的に、ISVが行っているのは、このピラミッドの最上部から始めることです。つまり、Prompt Engineeringを使用して、目指すユースケースを実現し、必要な精度レベルを達成することです。そこから、Retrieval Augmented Generationのような手法へと進むのは自然な一歩で、データを活用して精度と差別化を向上させることができます。しかし、このピラミッドを下に進んで、Generative AIモデルのFine-tuningや独自のAIモデルのトレーニングに至ると、コストと複雑さが増加する傾向にあります。結果として、多くのソフトウェア企業がこれを行っているのを見かけますが、慎重に検討する必要があります。なぜなら、そこから始めると、多くの問題に直面する可能性があるからです。
成功するGenerative AIユースケースのバランスを取る際に重要なのは、まず精度です。個々のユースケースを考える際には、顧客が成功した結果だと考えるために、モデルはどの程度の精度が必要なのかを自問する必要があります。90%が必要でしょうか？95%が必要でしょうか？そこから、その精度レベルに到達するために何をする必要があるのか、どのくらいのコストがかかるのか、どれだけ早く実現できるのかを検討し始めることができます。速くて安価であっても、精度が低ければ、製品戦略の一部として価値のある有用なものにはならない可能性があります。これらすべてのバランスを取る必要があり、そこで複数のモデル、複数の技術、複数のアプローチが、Generative体験をスケールする際の異なる側面のバランスを取るのに役立ちます。
一般的に、Fine-tuningは精度を向上させることができます。Pre-trainingも同様に精度を向上させることができます。推論の観点からは、実行時にどれだけのコンテキストが必要になるかも考慮する必要があります。なぜなら、それもコストを押し上げる要因となるからです。現在のモデルは巨大なコンテキストウィンドウを持っているのは素晴らしいことですが、コストのバランスを取るためには、個々の推論に投入するコンテキストの量を過剰にしないよう注意する必要があります。とはいえ、現時点でそのトライアングルのバランスを取ることができない状況もあるかもしれません。しかし、そのアイデアを完全に捨てる必要はありません。
それが示唆しているのは、数ヶ月待つか、内部でプロトタイピングを始めて、どのように実現するかを理解することが必要かもしれないということです。なぜなら、過去2年間で、Generative LLMの推論コストは急激に低下しており、同様のコスト低下が今後も続くと考えられるからです。そのため、現時点でスケールにおいて財務的に実現可能でないユースケースでも、6ヶ月後や12ヶ月後には状況が異なっている可能性があります。
AWSの観点から、私たちはこれらの意思決定をサポートするためにさまざまな取り組みを行っています。独自のモデルを構築するために必要な低レベルのインフラ（今週たくさん耳にすることになると思います）から、プロダクトチームが独自のユースケースを構築できる共有サービスを備えた組織を構築するためのツール、さらにはAmazon Q DeveloperやQuickSight Qのような、自然言語クエリや自然言語生成、実行可能なアーティファクト生成のために製品に組み込むことができる高レベルのユースケースまで、幅広く提供しています。
しかし、製品だけではありません。 ISVセグメントのお客様向けに、私たちはこの journey を加速するためのプログラムも提供しています。例えば、Generative AI Acceleratorは、AWSの専門家との1〜2日間のイベントで、特定のユースケースの理解を深め、それらをどのように推進していくか、そして経営陣の合意を得るためのサポートを行います。また、Experience-Based Accelerationは、クラウド機能を活用したアジャイルな没入型の取り組みで、ジェネレーティブAIの機会におけるビジネス価値を加速させることができます。さらに、Generative AI Incubatorでは、自動化や作業削減のためのソリューションを特定し活用するために、私たちのAI/ML専門家とのブレインストーミングセッションを活用することができます。もちろん、自分のペースで進めたい場合は、Builder Labsや自習型ラボなども用意しています。
New Relicの製品におけるAI活用戦略
以上で私の説明を終わり、New RelicのSajに引き継ぎたいと思います。彼らが様々なニーズのバランスを取りながら、どのような journey を歩んできたのかについてお話しいただきます。Saj、ありがとうございます。Jeffreyから様々な企業のユースケースについてお聞きいただきましたが、私からは実践的な内容についてお話ししたいと思います。New Relicが社内でAIをどのように活用し、製品にどのように組み込んでいるのかについてご紹介します。その前に、 New Relicについて少し背景をお話しさせてください。皆さんご存知だと思いますが、私たちはAPM市場セグメントを創造した企業です。そして現在は、完全にAIファーストのObservabilityプラットフォームとなっています。
私たちのプラットフォームには3つの重要な機能があります。1つ目は、オンプレミス、クラウド、あらゆるタイプのクラウドに存在するすべてのテレメトリーデータを収集するインテリジェントモニタリングです。アプリケーションやサードパーティからすべてのデータを収集し、お客様にインテリジェントなレスポンスを提供するデータプラットフォームを構築しています。最後に、現在保有しているデータから得られるインサイトを提供し、スライドに示されているすべてのペルソナに価値を届けています。
私たちは1日に約7ペタバイトのデータを処理し、数十億のイベントがこのプラットフォームに送られています。これがNew Relicのプラットフォーム全体のインフラストラクチャの規模です。これは、Observabilityの観点から私たちがお客様のために行っていることの文脈を示しています。約85,000のお客様が、自社のミッションクリティカルなアプリケーションのシステム運用、インターネット管理、スケーラビリティ、信頼性のために、New Relicをミッションクリティカルな形で利用しています。
Gen AIに関する当社の背景について、お話ししたい重要な点が2つあります。1つ目は、New Relicが社内でGen AIを活用して業務効率を向上させた方法についてです。当社は全体で3000人以上の従業員を抱えています。重要なポイントとして、私たちは、まだAgentについて誰も語っていなかった約2年前にこの取り組みを開始しました。非常にシンプルなアプローチから始め、POCではなく、価値の実証にこだわりました。
重要なのは、Gen AIはどのようなユースケースにも活用できるということです。実は今朝、面白い漫画を見ました。顔を自動で拭いてくれる自律型ナプキンの話でしたが、そういったものにAIは必要ありません。すべてにコストがかかるのです。私たちの最初の重要な焦点は、開発者の生産性を向上させることでした。なぜなら、開発者は社内で最も希少なリソースだからです。開発者の生産性全般を見ると、コードレビューが最大のボトルネックとなっています。Principal EngineerやSenior Engineerの対応を待つことで、時には数日から数週間かかることもあります。次に、私たちには素晴らしいエンジニアリング基準とコーディング基準がありますが、新人開発者が入社した際に、Senior Engineerの時間を費やして全てを学んでもらうわけにはいきません。
3つ目の側面はコード生成についてです。コード生成は本当に優れているのか、そしてエンジニアがコード生成の上でどれだけの作業を行う必要があるのかということです。私たちは古いコードのリファクタリングにおいて、コード生成が最も価値があることを発見しました。重要なのは、これが実際にもたらした価値を測定することです。左側のグラフを見ていただくと、P1、P2、P3というエンジニアのレベルが表示されています。P1は大学を卒業して2年程度の経験を持つ人、P2は4～5年の経験を持つエンジニア、そしてP3エンジニアがいます。私たちの仮説では、Gen AIは上級エンジニアよりも、むしろ経験の浅いエンジニアにとって最も有用になるだろうということでした。
実際に、P1、P2、P3のコホートだけで最適化を行いました。Gen AIによるコード生成とテスト生成の実装の前後で評価を行ったところ、平均して生産性が約15%向上しました。これは私たちが求めていた非常に重要な部分です。皆さんのユースケースは異なるかもしれませんが、これこそが私たちが言う価値の実証です。2つ目は、Agentに関することです。当時から私たちの見方は、複数のAgentが存在し、それぞれが独自のドメイン専門知識を持つだろうということでした。
この図は、まだAgentが一般的ではなかった約14ヶ月前に私が作成したものですが、今では誰もがAgentについて語っています。企業内で50のAgentを走らせることはできませんので、エンドユーザーには1つのAgentしか見えないようにしています。現在、私たちはAmazon Qとの統合を行っており、また私たちが使用しているSalesforceなどの他の製品もあります。これらはすべて独自のAgentを持っていますが、エンドユーザーは1つの特定のAgent、つまり社内で開発しているNeural AgentのNOVAと対話することになります。
Agentには2つの機能があります。1つ目は、Co-pilotモードで動作するAgentで、ユーザーが呼び出して何かを依頼するタイプです。2つ目は、呼び出す必要がない - つまりワークフローに組み込まれていて自動的に関与するタイプです。例えば、Pull Requestを行うと、Agentが自動的に参加してコードレビューを実施します。重要なのは、ChatGPTのように単にAgentを呼び出すだけというのは、ほんの始まりに過ぎないということです。プロダクトの成熟度を高めるには、ワークフローへの統合が必要なのです。
最も重要な点の1つは、チャットAgentを呼び出すのは、Agent連携の最も単純な形態に過ぎないということです。私たち全員にとって変化するのは、日々のワークフローがどう進化していくかということです。ワークフロー全体を100％Agentが管理するわけではありません - Agentが一部の作業を行い、人間も介在するという形になります。エンジニアリングには、エンジニアが1週間オンコール担当となる「Hero Work」という概念があります。私たちはすべてのアクティビティとチケットを分類し、Agentが支援できる5つのユースケースを特定しました。エンジニアが質問すると、Agentはそれを認識し、非同期で作業を実行し、結果を返します - それが5分かかろうと、1時間かかろうと、あるいは他のチームへのPull Requestの作成が必要であろうと関係ありません。
3つ目の側面はインシデント管理です。私たちのような重要なミッションを持つ環境では、インシデント管理が極めて重要です。過去のインシデントから学び、新たなインシデントを防ぐほど、プロダクトは良くなっていきます。私たちはChatOps Agentを持っており、アラートを相関分析し、自動的にRCAを作成し、選択可能な複数のオプションを提供します。それらの実装を望む場合は、別のAgentが実装を担当できます。コストを効果的に管理するために、ユースケースごとに異なるモデルを使用できます。すべてにLarge Language Modelを使用するのはコストが高すぎるため、場合によっては人間を活用する方が賢明です。
クラウドコスト最適化に関して、これは非常に有用でした。以下が私たちのクラウドコスト監視方法です。クラウドで使用するものはすべて、チームとリソースでタグ付けされています。AIを使用して一般的なベンチマークを確認し、異常が見つかった場合、該当チームにアラートが送信されます。これを最初に実装した時は、1ドルの増加でもアラートが発生してエンジニアたちを困らせたため、しきい値の調整が必要でした。
最後のポイントはConvertible RIsについてです。大規模なAWSユーザーであれば、ワークロードとインスタンスタイプに基づいてConvertible RIsを創造的に活用できます。私たちはこの分野で広範にAIを活用しており、Convertible RIsの適切な使用、Bin Packingの確保、プラットフォームの一部としてのConvertible RIsの売買を通じて、年間400万から500万ドルの節約を実現しています。これらすべては、本番環境に投入された数多くの実験の結果です。
Generative AI導入から得られた教訓と実践的アドバイス
これらは、Developer Productivity、Incident Management、 Cost Management、そして関連分野において、私たちが社内で達成してきた成果の一部です。ここでは、私たちの製品における Generative AI の活用方法についてお話ししたいと思います。
先ほど申し上げたように、私たちのプラットフォームは非常に大規模で、世界最大級の Kubernetes クラスターを運用しており、最大規模のストリーミングプラットフォームを持っています。私たちは Neural Database という独自のデータベースを持っており、これは S3 をバックエンドとする相関データベースです。この独自のアーキテクチャは、1日に7ペタバイトものデータを処理する私たちにとって非常に重要です。お客様がクエリを実行した後に待たされるようなことは許されません。私たちは NRQ（または N）と呼ばれる独自の SQL ライクな言語を持っており、お客様にも好評ですが、NRQ を学びたくない新規のお客様向けのソリューションが必要でした。
プラットフォームの観点から見ると、AI の活用には3つの重要なコンポーネントがあります。最下層には、すべての入力データを収集する層があります。私たちが構築した Knowledge Platform は、確率的エンジンと決定論的エンジンの両方を含む Platform of Intelligence をサポートしています。決定論的エンジンは特定の入力に対して具体的な出力を提供し、確率的エンジンは確率に基づく出力を提供します。これらのエンジンは相互に連携することができます。その上には Platform of Action があり、ここで異常検知とレコメンデーションを行っています。
N を学ぶ必要のない新規のお客様は、自然言語でクエリを実行でき、内部的には適切な Prompt Engineering を通じて NRQ に変換されます。また、Amazon Q との統合も実現しており、AWS のお客様であれば、複数のエージェントを使用する代わりに、1つのエージェントですべてのリソースに対してクエリを実行できます。これが、Platform of Record、Platform of Intelligence、Platform of Action からなる私たちの AI に関する全体的な考え方です。
さて、これが NRAI Monitoring です。私たちは、お客様の AI の実際の運用をモニタリングし、パフォーマンスに焦点を当てています。Jeffrey は、パフォーマンス とコストに関する考慮事項について説明しました。モデルは静的なものではなく、より優れたモデルが登場し、 コストが低下するにつれて、継続的な改善が必要です。より良い Prompt Engineering も可能なので、作って終わりというわけにはいきません。この画面 では、モデルが期待される状態から逸脱していないか、ユーザーが経験している遅延はどの程度か、どのようなドリフトが発生しているかを確認できます。あるモデルと別のモデルを比較することもでき、これがすぐに使える AI モニタリングの機能です。
インシデント管理とRoot Cause分析に関してもう一つ興味深い側面があります。Observabilityにおける一般的な問題の一つは、大量のアラートを受け取るものの、インシデント発生時に本当に必要なアラートが存在しないことです。New Relicの観点からは、まず最初にアラートを最適化して誤検知と見逃しを減らし、質の高いアラートを確保します。その後、Agentが人手を介さずに自動的にアラートを設定できます。アラートが発生すると、別のAgentが環境内の潜在的な問題を調査し、現在のシステム全体のイベントと過去のイベントの両方を確認してRoot Cause分析を実行します。実装のためのソリューションを提案し、アクションを要約した上で、ユーザーである皆さんがそれを実装するかどうかを判断することができます。
提案されたソリューションをクリック一つで実装するか、システムに自動実装させるかを選択できます。Change Trackingについても同様です。システムをデプロイする際、システム内にChange Trackingマーカーが記録されます。イベント発生時に、プラットフォーム上でこの時点からあの時点までに何が変更されたかを確認でき、実際に発生した変更と、直面する可能性のある潜在的な問題を把握することができます。
活用できるユースケースは数多くあります。これから学んでいただけることの一つは、これらが生み出す価値が非常に大きいということです。ただし、何を追求するかを見極める必要があります。どの企業にも、達成したい優先度の高いユースケースがいくつかあります。実行可能なことは何百とありますが、それらすべてを実行するためのリソースやキャパシティがあるかどうかを考慮する必要があるため、これを念頭に置く必要があります。本当に取り組む必要があることを選んで優先順位をつける必要があります。
これまでの経験から学んだことについて、少し時間を取って説明したいと思います。まず重要なのは、Proof of Valueが非常に重要だということを理解することです。Proof of Conceptで止まらないでください。過度なエンジニアリングは全体的にコスト効率が悪くなります。次に重要なのは、これらすべてから得られる実際の価値を測定できるようにすることです。これは私たちが求めているものにとって極めて重要です。
常にGenerative AIのことばかり考えるのではなく、従来型の機械学習アプローチも活用できます。というのも、私たちのほとんどがこれらのアプローチを十分に活用できていないからです。私たちのプラットフォームはセルラーアーキテクチャを採用しており、各セルは一定の容量を維持する必要があるため、新しいセルを追加するタイミングやセルを廃止するタイミングを判断する際に、容量エンジニアリングの観点から学んだことの一つがあります。この場合、従来型の機械学習が役立ちます。Generative AIモデルを使用するよりも、シンプルで影響力があり、コストも抑えられるのです。
実験とプロトタイピングは必須です。これらを多く行えば行うほど、組織におけるイノベーションを推進することができます。プロトタイプの作成に何ヶ月もかける必要はありません。2〜3週間で作成し、その上で改良を重ねていけばいいのです。イテレーションを受け入れる姿勢が重要です。初日から完成品ができるわけではないのですから。ユースケースの範囲は実際に必要なものに絞ることが大切で、広すぎる範囲に設定してしまうと、期待されるAIの機会や成果が得られず、人々を失望させることになってしまいます。
AIから得られる収益への関心は企業によってさまざまです。生産性の向上だけを目指す企業もあれば、実際のコスト削減を目指す企業、そしてCanvaのようにマーケティングを通じた収益増加を目指す企業もあります。AIはこれらの多くの側面に革新をもたらしています。AIに関する最大のハイプは「すべての仕事を奪う」というものですが、それは違います。AIを使う人が、使わない人の仕事を奪うのです。これが人類の進化の過程なのです。AIは人間にできることを排除するのではなく、私たちを強化し、多くの単調な作業から解放してくれるのです。
もう一つ強調したいのが、コンテキストの重要性です。Foundation Modelの構築は非常にコストがかかり、ほとんどの企業には手が出ません。Fine-tuningも高額で、非常に専門的なドメインモデルが必要な場合を除いて、私なら実施しません。RAGの実装（Knowledge GraphsやGraph RAGなど、RAGの世界では多くの進展があります）は、ほとんどのシナリオで素晴らしく機能する事前学習モデルにコンテキストを設定します。実装に6〜12ヶ月かかり、何百万ドルもかかる大規模プロジェクトに取り組むのではなく、コスト効率が良く、迅速に結果を出せるこれらの領域を試してみることをお勧めします。これらは私たちが学んだこと、そして今も学び続けていることの一部です。
現在、私たちは40〜50のユースケースを実験中で、そのうちおそらく15個は非常に強力で、実際に製品化できるでしょう。また、いくつかは学びとなりますが、実際に実装するには成熟度が足りないものもあり、実装に時間がかかるものもあります。
Generative AI戦略の成功に向けた総括と今後の展望
では、Jeffreyに引き継ぎたいと思います。ありがとうございます、Saj。New Relicでの独自の取り組みであっても、私たちが話し合ったテーマ、つまり運用面と製品組み込み面のテーマが存在していることは素晴らしいですね。そこには、顧客のための作業負荷の削減や、新しいアラートの特定にかかる時間の短縮、必ずしもやりがいのある作業ではないものを減らしていくという考えがあります。追加の自動化のレベル、コストとパフォーマンスと精度のバランスを取る必要性。つまり、お客様に提供する製品が何であれ、これらの要素を活用して、独自の成功する市場をリードするGenerative AI戦略を描いていくことを考えてみてください。
優先度の高いユースケース、価値を生み出すユースケースは何か、そしてそれらに確実に焦点を当てるにはどうすればよいのでしょうか？まずは、あなたのビジネスの独自性、プロセスの独自性、データの独自性から始めて、それらを基に高価値なユースケースを特定していきましょう。将来、どのような機能がコモディティ化すると考えられますか？そうすれば、その機能を自社で構築する時間を費やす必要はなく、私たちや他のプロバイダーから入手できます。モデル自体は、継続的に改善され、コストも下がっています。本当に自社でモデルのチューニングや構築にコストをかける必要があるでしょうか？まずは Prompt Engineering と RAG から始めて、高価値なユースケースに対してそれらが機能しないかどうかを確認することが重要です。
データを軽視せず、既存の生成系テクノロジーで消費できる形式にデータを変換するために何が必要かを理解しましょう。そして、組織がそのデータを使用可能な形式で提供することに対して報われるような基準を確立しているか確認してください。また、適切な人材は揃っていますか？AI プラットフォームについて言及されましたが、組織の残りの部分に機能を提供するコアプラットフォームに、社内育成と外部調達を組み合わせたスキル構築のリソースが配置されていることを前提としています。
Jeff さんが先ほどのスライドで触れていたように、私たちの従業員は AI 対応である必要があります。すべての従業員や技術者が一定レベルの社内トレーニングを受ける必要があります。しかし同時に、社内にない専門知識を外部から取り入れ、徐々にその領域を成長させる必要があるかもしれません。私のような Finance 専攻でも、Natural Language Generation や Natural Language Understanding、Natural Language Query、Executable Artifact Generation といった一般的な技術を理解することはできます。ビジネス部門の意思決定者にこれらの技術について教育することで、高価値なユースケースを特定するのに役立つ質問をしてもらえるようになります。もう一つ付け加えると、AWS の GAI Competency Center は素晴らしいリソースです。可能な限り最大限活用することをお勧めします。
ありがとうございます。私たちは常にソフトウェア企業であるお客様からのフィードバックを基に進めています。本日はご参加いただき、ありがとうございました。ソフトウェア企業向けに提供しているリソースをご存知ない方は、AWS for Software Companies の QR コードをご確認ください。少しの間表示させていただきます。Saj さん、本日は一緒に登壇していただき、ありがとうございました。素晴らしい時間でした。質問がある方のために、このまま会場に残らせていただきます。ありがとうございました。良い一日をお過ごしください。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion