re:Invent 2024: New York LifeのAWSベースLakehouseとGen AI活用事例
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - New York Life: Data platform modernization to generative AI innovation (FSI324)
この動画では、米国最大の相互保険会社であるNew York Lifeのデータ基盤とAI活用の取り組みが紹介されています。同社のLead ArchitectのScott Symankさんは、レガシーなHadoopデータレイクからAWSベースのLakehouseアーキテクチャへの移行について解説し、Boris Simanovicさんは、MLOpsプラットフォームの構築とGen AIの活用事例を共有しています。特に、Claims Managerの業務効率化のために導入したLLMベースのレター生成システムは、数時間かかっていた作業を15秒程度に短縮することに成功しました。また、AWSのExperience-based accelerationという手法を12回以上実施し、組織全体のイノベーション能力を高めた点も注目に値します。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
New York Lifeのデータ戦略とAIプラットフォームの概要
New York Lifeのリードアーキテクトを務めるScott Symankさんと、同社でMSを統括するBoris Simanovicさんをお迎えしています。Scottさんは最初にNew York Lifeの紹介と、同社が何を目指しているのか、そしてデータ戦略についてお話しします。その後、レガシーシステムからデータプラットフォームをどのように変革したかについて説明します。続いてBorisさんが、構築したAIとGen AIプラットフォームについて、そしてそれがクレームマネージャーにどのような実際の影響をもたらしたかについて話します。さらに、New York LifeとAWSのパートナーシップ、そしてそれによってイノベーションをどのように加速できたかについても説明します。最後に、この journey を通じて得られた教訓と、何が役立ち、何が役立たなかったかについてまとめます。
Scott Symankが語るNew York Lifeのデータ変革の旅
こんにちは。New York LifeのAIおよびデータ組織のドメインアーキテクトを務めるScott Symankです。製薬業界で25年以上の経験を積んだ後、New York Lifeに入社して約7年半になります。New York Lifeについて簡単にご説明しますと、私たちは米国最大の相互保険会社です。これは、Wall Streetではなく、保険契約者に対して責任を負っているということを意味します。先ほど触れましたように、私たちは179年の歴史を持つ企業で、経済の好不況を乗り越えて繁栄してきました。私たちは、エージェントと保険契約者の双方に卓越した体験を提供するため、テクノロジー、データ、AIを積極的に活用しています。
約1年前、Chief Data and Analytics Officerを採用し、AIとデータ組織を立ち上げました。そして新しいデータ戦略とミッションを開始しました。私たちの戦略は、エンタープライズAIとデータプロダクトを通じてNew York Lifeのデータの力を活性化し、意味のあるビジネスインパクトを生み出すことです。この戦略は4つの柱で構成されています。第一の柱は、エンタープライズデータプロダクトを構築するためのデータ基盤とテクノロジーを拡張することです。第二の柱は、AIと分析を通じてデータインテリジェンスを向上させることです。第三の柱は、データに基づいて意思決定が導かれる文化への変革に焦点を当てています。そして最後の柱は、エージェントと保険契約者の双方にプロアクティブでパーソナライズされた体験を提供することです。
このブレイクアウトセッションはモダナイゼーションの取り組みについてですので、私たちがどこからスタートしたのかを見てみましょう。私たちは約100の異なるソースからデータが流入するオンプレミスのHadoopデータレイク環境を持っていました。データの標準化と整理のレベルを設定し、IBM BigIntegrate（実質的にはHadoop用のDataStage）を使用してデータウェアハウスを構築しました。その上にTableauを配置してビジネス分析とダッシュボードを実現していました。このテクノロジーが古くなるにつれて、多くの課題に直面しました。最初の課題は、ベンダーのHadoop 3.6.4のサポート終了により、サポートが非常に限定的になったことでした。そして、HortonworksとClouderaの合併により、彼らがCDPアプローチに全面的に移行し、レガシーHortonスタックを放棄したため、限定的なサポートから非推奨プラットフォームとなってしまいました。
New York Lifeでは、クラウドを重視しクラウドファーストな企業になるという新しいコンピュート戦略を進めていました。レガシープラットフォームには改善が必要な多くの機能があることを認識していました。データパイプラインのパフォーマンスを向上させるためのACID機能を持っていませんでした。レイクに流入するデータが増えるにつれて、より良いインサイトを得るためにデータにアクセスしたい新しいペルソナの要件が出てきました。私たちはS3をデータレイクとして、Redshiftをデータウェアハウスとして使用するLakehouseアーキテクチャの構築を決定しました。クラウドへの移行は、多くのコンポーネントの再設計と再エンジニアリング、そして一部コンポーネントのリフト＆シフトを組み合わせて行いました。
New York Lifeの AWS における運用方法についてご説明します。まず基盤となるのが Enterprise Cloud Platform チームです。ウェディングケーキに例えると、彼らは最下層として New York Life の AWS 運用の基礎を担っています。アカウントの作成や Service Control Policy、Transit Gateway のルール設定などを担当しています。また、承認されたサービスを利用可能にするプロセスも管理しています。AWS が新しいサービスをリリースして一般提供を開始しても、それが自動的に New York Life で利用可能になるわけではありません。そのサービスを使用するための適切なセキュリティポリシーとガードレールを確実に整備する必要があります。Cloud Enterprise チームとの密接な連携があり、需要のあるサービスにのみ焦点を当てています。私たちの取り組みの中で、Glue、Lambda、Redshift などのさまざまなサービスの使用承認を得る必要がありました。
私たちの取り組みにおける2番目の重要なチームは、SRE（Site Reliability Engineer）です。これらは部門やorganizationに配置された信頼性エンジニアで、Platform Engineer として機能します。彼らはインフラ全体を管理し、Terraform コーディングを担当し、クロスアカウントアクセスや IAM プリンシパルの開発を担っています。彼らは企業全体やプロジェクトレベルではなく、部門レベルで活動しています。3番目の要素は、組織のエンジニアリングチームで、データパイプラインの構築、データ取り込み、そしてウェアハウスにドメインモデルを構築するための ETL または ELT を担当しています。最後の層は、日々増加しているデータを利用したいコンシューマーやペルソナで構成されています。これには、分析エンジニア、データサイエンティスト、MLOps の専門家、探索的データ分析を行いたい人々が含まれます。
New York Life では、AWS の Well-Architected Framework に沿ったマイクロアカウント戦略を実装しています。このアプローチは、異なるコンプライアンスやセキュリティ要件により、ビジネスアプリケーションを分離し、異なるアプリケーションへのアクセスに明示的な許可を必要とする境界を確立します。これは、適切な人が適切なサービスにアクセスすることを保証する、実証済みの安全なアプローチです。私たちは一連のアーキテクチャのベストプラクティスと原則を開発しました。その第一は、すべてを HIPAA インジェストアカウントを通じて実行することです。すべてのデータパイプライン活動は、HIPAA アカウントにデータを格納します。生命保険申込において PII（個人識別情報）と PHI（個人健康情報）を扱うため、データ取り扱いに関して厳格なセキュリティを維持しています。
HIPAA アカウントへのアクセスはプロセスや人に許可せず、すべてのデータは HIPAA アカウントから外部へプッシュする必要があります。異なる役割には異なる権限が設定されています。データを取り込むインジェストデータ取得部分はランディングバケットへの適切なアクセス権を持ち、データを読み取って処理するプロセスはそのバケットへの読み取り権限のみを持ち、他のバケットへの書き込み権限を持ちます。これにより、同じバケットに対して複数の役割が書き込み権限を持つことを防いでいます。すべての平文はランディングバケットに書き込まれる必要があります。データレイクへのアクセス権限を管理するために AWS Lake Formation を実装中です。ユーザーがデータレイクにアクセスまたはクエリを実行したい場合、Redshift を通じて行われるように、Redshift 外部テーブルを使用します。可能かつコスト効果的な場合はサーバーレス機能を使用することを目指していますが、ETL および ELT 作業用のメイン Redshift クラスターは、ほとんどの時間稼働しているため、プロビジョニングされたクラスターを使用しています。上下するコンシュームクラスターには、通常サーバーレスアプローチを使用します。クロスアカウントアクセスは信頼ポリシーを通じて実装しているため、侵害が発生した場合、IAM アクセスを変更する代わりに、単に信頼ポリシーを切断してクロスアカウントアクセスを防ぐことができます。
最後に、デトークン化機能は LDP グループによって管理されています。データレイク内で PII データを難読化するために Protegrity というツールを使用しています。これは可逆的ですが、LDA を通じて管理される適切な権限が必要です。これは Redshift とその特定の機能を処理できる Redshift ユーザー定義関数に流れていきます。
Boris SimanovicによるMLOpsプラットフォームの構築と運用
パイプラインの作業について説明する際、まず各アカウントの概要を説明し、その後詳細に入っていきます。基本的には、ML Opsアカウントを除くすべてのアカウントについて説明します。ML OPSのアーキテクチャーと戦略については、Borisが彼のプレゼンテーションで説明します。最初の部分では、私たちが「インジェスション/データパイプライン」と呼んでいる部分に焦点を当てます。具体的には、Ingestionアカウント、Data Lakeアカウント、Data Governanceアカウントについて説明します。
アーキテクチャーを見ていただくと分かるように、Data Lakeには様々なソースからデータが流入しています。図ではSFTPとDMSのみを示していますが、実際にはAWS Full Replication用のメッセージベースのシステム、AWS DMS CDC、その他多様なパターンのデータがLandingバケットに入ってきています。個別のインジェストソリューションを構築する代わりに、Amazon Auroraのメタデータリポジトリを使用してデータを取り込むためのパターンを持つGlueフレームワークを構築しました。フルインジェスト用にDatabase Migration Servicesを使用する場合、適切なメタデータでデータベースを読み込むと、Glueジョブが自動的に生成されます。ポイントツーポイント型のインジェストは構築せず、ファイルインジェストでもメッセージベースでも、すべてフレームワークを通じてLandingバケットにデータを取り込んでいます。
Landingバケット内のデータは、ソースシステムと全く同じ形で、一切の変換は行われていません。私たちは1つのパイプラインプロセスを構築したので、データがLandingバケットにどのように到達するかに関係なく、次のステップはメタデータリポジトリの内容に応じて同一です。変更点を送信できない場合に備えて、独自のデルタ検出を行っています。AWSは計算量に応じて課金されるため、変更のないデータを継続的に計算することは、パイプラインのパフォーマンスを低下させるだけでなく、コストも増加させてしまいます。そのため、このプロセスの可能な限り早い段階でデルタを特定するようにしています。その後、日時フォーマットの標準化、Address Doctorを使用した住所の標準化など一連の標準化ステップを実施し、ここでPIIフィールドのトークン化にProtegrityを使用します。このデータはIngestionアカウント内のRawバケットに書き込まれます。
Rawバケットには、標準化されトークン化された変更データのみが格納されています。その後、これらの変更をData Lakeに適用します。Data Lakeは別のアカウントにあり、エンドユーザーがデータを利用できる最初のレイヤーとなっています。Data Lakeではすべてのタイプ2履歴を保持しているので、例えば30-40年間保険契約者だった人が4-5回引っ越しをした場合、それぞれの住所とその期間が記録されています。Lake内には約4000のテーブルを変換しています。クラウドに移行して最初に稼働した時は、すべてParquetでしたが、分析の結果、1200から1400のテーブルがIcebergに移行することで恩恵を受けられることが分かりました。約500のテーブルをIcebergに変換し、25から40%のパフォーマンス向上を実現しています。Icebergへの移行は約3分の1が完了し、さらに700のテーブルが残っています。小さなテーブルの変換は効果が薄いことが分かったので、更新と書き込みの大きなパフォーマンスに焦点を当てています。ここでLake FormationでのGlue Data Catalogingを処理しています。
下部にData Governanceアカウントが表示されています。Hadoopからクラウドに移行した当初は、100%構造化データとソースでした。その後、非構造化データを扱う生成AIの道に進みました。同じアーキテクチャーを使用してデータの取り込み、処理、Lakeへの移動を行うことができました。違いは、適切なモデルで使用するためにドキュメントにタグを付けるData Governanceを追加する必要があった点です。ドキュメントがLakeにあるからといって、特定のモデルの目的に適しているとは限らないため、ドキュメントの所有者が異なる生成AIモデルでの使用に適しているかどうかタグ付けを行います。
それでは、消費側について説明します。Transform Account、IMC Account、Warehouse Account、そしてTableauについてです。これまでの説明のほとんどは再アーキテクチャと再エンジニアリングに関するものでしたが、Transform Accountはリフト＆シフトを表しています。つまり、DataStageをクラウドで実行し、Redshiftデータウェアハウスを生成するETL作業を行っています。現在、これをETLとELTの両方の機能を持つIMC Informaticaに移行中です。Platform SREチームは、DataStageを水平方向にスケールさせ、コスト削減のためにシャットダウンすることができます。クラウドに最適化されていないツールなので、詳細なエンジニアリング作業が必要ですが、ETL作業の完全な移行を待たずに、ユーザーがRedshiftを早期に利用できるようにしたかったのです。4ヶ月後にここに戻ってくれば、Transform Accountは停止されているはずです。
また、一連のRedshiftクラスターがあります。私たちのドメインモデルを計算するすべてのETLとELTが実行される大規模なプロビジョニング済みクラスターが1つあります。その他のクラスターの多くはServerlessで、データシェアを通じて相互に読み取りができます。データサイエンティストがModel-ready Datasetを構築するために本番データにアクセスする必要がある場合、彼らのクラスターにデータシェアがありますが、これにより計算リソースが分離され、彼らの計算やモデル実行が私たちのETLやELTジョブと競合することはありません。探索的データ分析を行う人々は独自のクラスターにいるため、同じ正確な本番データを使用しながら、計算リソースを分離することができます。
また、Operational Data Storeとして機能するAmazon AuroraデータベースであるProducer 2.0も表示されています。これには多くのエージェント情報が含まれており、ほぼリアルタイムで更新されます。今週中に発表される予定のpost-AuroraでゼロETLを目指しているため、これはWarehouse Accountに配置されています。このデータの分析もRedshiftを通じて行いたいと考えています。私たちの目標は、Producer 2.0のデータをRedshiftクラスターで利用可能にし、1つの場所ですべてのデータを照会できるようにすることです。消費アカウントとしてはTableauのみを表示していますが、現在では多くのユーザーがRedshiftを通じて私たちの環境に接続しています。それらのクラスターごとに外部テーブルを定義する必要がありましたが、最近AWSは外部テーブルをデータ共有プロセスの一部にできるようにリリースしました。
私たちのデータは生成AIをどのように実現したのでしょうか？データサイエンティストのために、高品質で信頼性の高いデータを一元化する同じデータレーク構造を使用したいと考えました。データサイエンティストとその生成AIアプリケーションが、データを探したり、異なるソースを探し回ったりする必要がないようにしたいのです。そのデータを彼らが簡単に利用できるようにしたいと考えています。非構造化データを取り込む機能も備えています。取り込みに関する初期のユースケースでは、Salesforce、Adobe、SharePointなどのプラットフォームなど、さまざまなデータソースに対応する独自のフレームワークを構築しました。そのデータを取り込むために使用できる汎用的なフレームワークを構築しました。これにより、AWSとデータレークのスケーラビリティを活用してデータアクセスとスケーラビリティが向上します。
データガバナンスとコンプライアンスは重要です。先ほど説明したデータガバナンスアカウントについては、適切なデータが適切なモデルに使用されていることを確認するためのタグ付けが主な役割です。追跡とデータプロベナンスがあるため、BIレポートと同様に、ソースシステムからレイクを経由してBIレポートまでのリネージを持っています。現在、MLとGenAIプロジェクトについては、どのデータがどの環境で使用されているかを、ソースからGenAIモデルまで追跡できます。
Gen AIを活用したクレーム管理の革新
それでは、MLOpsの世界について詳しくお話しいただくBorisに引き継ぎたいと思います。ありがとうございます、Scott。皆様、本日はお時間をいただき、ありがとうございます。私はBoris Simonovicと申します。New York Lifeでは、データの活用からモデルの構築、本番環境へのML Engineering、そしてAIソリューションとそれに必要なプラットフォームまで、すべてを含むMLOpsチームを率いています。プラットフォームの詳細に入る前に、私たちがプラットフォームを構築する際に用いている指針についてお話ししたいと思います。以前にこのようなプラットフォームを持っていなかったため、私たちはゼロからスタートしたことを覚えておいてください。
アーキテクチャの原則の一つは、スケーラビリティでした。ソフトウェア開発の経験がある方なら、これは標準的なSDLCの要素だとお分かりでしょう。私たちは望むように拡張できるプロバイダーを必要としていました。そのため、Kubernetesは明確な選択肢であり、私たちはEKSを使用しています。また、自動化も必要でした。開発環境から本番環境まで、完全なCI/CDパイプラインが必要です。MLOpsにおいて、本番環境への展開は私たちが構築し自動化するすべてを意味します。その理由は再現性を確保するためです。実行される実験や構築されるものすべてを、最初から最後まで再現できるようにしたいのです。すべてのものはGitHubでバージョン管理され、DockerからECRへと進んでいきます。
私たちは規制対象の組織であり、ガバナンスに多くの時間を費やしています。パイプラインを完全に再現可能で自動化したい理由の一つは、特定のモデルをどのように構築したか、特定のソリューションにどのように到達したかを規制当局に示せるようにするためです。そのためにも、モニタリングが必要です。これらの概念の多くは、何十年も存在してきた標準的なDevOpsの原則ですが、AIやGenAIソリューションには特有の要件があります。もう一つの原則はモジュール性でした。インフラストラクチャ、アプリケーション、モデル、LLMなど、すべてを望むように拡張できるようモジュール化したいと考えました。
セキュリティは、コードとDockerコンテナの両方に対する標準的なセキュリティスキャンを含め、私たちが慣れている分野です。また、Scottが話したように、データの保護も重要視しています。LLMの保護、IP保護、そしてLLMにデータを送信した際にそのデータがどこに行くのかということも気にかけています。最後になりますが、現在も取り組み続けている重要な点として、民主化があります。私たちはNew York Life全体にサービスを提供する中央集権的なチームであり、分散型のデータサイエンスチームを持っています。モデルやAI、GenAIソリューションをホストするすべてのデータサイエンスツールとプラットフォームを、会社の全員が利用できるようにしたいと考えています。
まず、非常に高レベルな開発アーキテクチャから始めましょう。左側にあるのは、データチームが管理するData Lakeアカウントです。ここには、Scottが言及したデータセットが存在し、構造化・非構造化を問わず、すべてのデータが集まってきます。そして、探索的データ分析にはSageMaker Studioを活用しています - これは、データサイエンティストが実験に使用するNotebookです。
私たちのML Engineerは、モデルを本番環境に展開するため、少し異なるツールを使用しています。全ての実験はGitHubに格納されます。GitHubでは、ML Engineerたちが実験コードを全てラップしてDockerize化し、MLパイプラインにプッシュするためのテンプレートを作成しました。このパイプラインが、私たちのサーバーであるEKSにデプロイされます。振り返ってみると、この図に入れ忘れた点として、SageMakerはBedrockにもアクセスできます。Data Scientistの実験のために、モデリングデータセットとBedrockへの全てのアクセス権を持っています。これが開発環境の説明です。
では、どのように運用化するのでしょうか？全てがGitHubでバージョン管理されています。その多くは標準的なSDLCの原則とパイプラインです。私たちはモジュラーアーキテクチャを採用しており、特定のテクノロジーチームがUIを担当します。UIチームがUI、AIソリューション、Gen AIソリューションを構築します。ちなみに、これらは全て同じように扱われます - 全てDockerize化され、REST APIを持っています。内部のKubernetesサーバーでモデルをホストする場合でも、Foundation Modelを使用する場合でも、アーキテクチャ的には全てのソリューションが全く同じ方法でラップされています。
Gen AIについては、いくつかの追加コンポーネントが必要でした。OpenSearchデータベース（ベクターデータベース）が必要で、オープンソースのサーバーレスを使用しました。先ほど少し監視について触れましたが、アプリケーション監視だけが必要な通常のソフトウェアとは異なる点があります。インフラ監視は全て行いますが、モデルではアプリケーションパフォーマンス監視も必要です。さらにモデルメトリクスも必要です。ガバナンスの理由と内部運用のために、モデルが入出力する全てのデータを保存する必要があります。これにより、Data Scientistは任意のモデルのパフォーマンスを再生、確認し、次のバージョンで製品を改善することができます。
そのためにDynamoDBを使用し、全てを記録しました。というのも、私たちは自分たちが何をしているのか、正直なところ全てを把握していなかったからです。新しく始めたばかりで、学習中でしたし、今でも学び続けています。これは全て一つの旅路です。私はAIとMLを10年以上やっていますが、日々新しいことを学んでいます。DynamoDBには、全てのプロンプト、完了結果、開始時間と終了時間、トークン長など、取得できる情報は全て保存しました。何が重要になるか分からなかったからです。後でこれらの情報をレビューするData Scientistたちは、Bedrockにアクセスできました。スケーリングの観点から、Bedrockは多くの面でスケールを可能にしてくれました。これは本当に良い選択でした。多くのモデルにアクセスでき、自前のモデル、つまりオープンソースモデルを立ち上げることも、Foundation Modelを使用することもできました。
なぜこれら全てを行うのでしょうか？Scottがデータの旅について話しましたが、私はプラットフォームについて話しています - これら全ては顧客のためのソリューションを開発するためにあります。顧客と言うとき、それは社内の顧客やビジネスパートナー、そして最終的には実際の顧客や保険契約者を助けるものを指します。1年以上前、ビジネスパートナーが私たちに問題を持ち込みました。非常に複雑な医療記録に基づいてカスタムレターを生成しなければならない保険金請求管理の経験について話してくれました。全て手動で生成されているため、多くの問題点がありました。プロセスが存在しないのです。これは以前のAIでは解決できなかった非常に複雑な問題でした。私たちが構築した全てのツールは、そのためのものでした。問題は、それが非常に手作業だったことです。これらのレターは全て人によって作成されているため、法的なリスクもありました。人には人の数だけ異なる書き方があります。数学のように一意ではなく、英語の授業を思い出してみると、様々な採点がされた作文があり、なぜそうなったのかを常に理解できるわけではありませんでした。そこで、私たちは標準化を目指しました。
私たちは、これらのレターの生成方法を標準化したいと考えていました。レターの生成には非常に時間がかかり、レターの内容や理由が不明確な場合もあったため、カスタマーエクスペリエンスを改善したいと考えました。また、生成されるすべての内容が事実に基づき、特定の基準に従って作成され、法的リスクも軽減されることを確実にしたいと考えました。クレーム否認の際に、メールの中で誤った言葉を書いてしまい、それが誤解を招く可能性がある場合、法的リスクが生じる可能性があるからです。
従来のClaims Managerの業務では、特定の医療クレームに関する決定を下すために、Nurse Case Managerのメモ、クレームノート、その他必要なメモなどの文書を確認する必要がありました。これらの文書をすべて確認した後、承認か否認かを判断し、そしてすべてのデータを論理的に整理してレターを作成するという面倒な作業が始まります。この部分は1日の大半を占め、誰もが最も好まない作業でした。レターの下書きが完了すると、通常は上司などによるレビューを経て、顧客に送付されます。
私たちはこのプロセスを改善する方法を検討しました。良かったのは、すでにHuman in the Loopがあったことです。私たちはリスク回避型の組織で、創業179年の歴史があり、New York Timesの一面を飾るようなことは避けたいので、レビュープロセスは重要でした。違いは、レターの生成にLLMを使用したことで、何時間もかかっていた作業が数秒で完了するようになったことです。Claims Managerの一人が初めての実験で、半日かかっていた作業が約15秒で生成されるのを見たときの表情をお見せできたらよかったのですが。
LLMを採用することで、一貫性を構築することができました。モデルは非常に一貫性があり、特定の読解レベルでデータを生成できるため、すべてが読みやすくなります。これらのレターの中には非常に複雑なものもあり、理解するために弁護士が必要になるようなことは避けたいと考えていました。このプロセスを通じて、プロンプトを使用してレターを作成することで、Claims Managerの業務体験を改善しました。Data Scientistたちがこのプロンプト作業のすべてを行い、先ほどSagemakerのアーキテクチャーをお見せした際に説明したように、それが主な作業でした。もちろん、抽出やチャンキングなどのパイプライン作業も行っています。
すべてが自動化され、作業時間が数時間から数分に短縮されたことで、効率が向上しました。プロンプトによってリスクも軽減されました。LLMに依頼すること - モデルに指示を出すことに慣れているので「依頼する」という言葉を使うのは面白いのですが、これらのモデルにはアシスタントのように話しかけます - の一つは、特定のトーンを維持することです。特に否定的な結果を受け取る顧客に対して、モデルが適切な表現を使用することを確認したいと考えました。カスタマーエクスペリエンスを改善したいと考え、それは事実に基づく生成によって実現されました。Large Language Modelは理解レベルの作業が得意で、適切なトーンで特定のレベルで構築されていることを確認しました。私が非常に高いレベルで要約している数十の指示がありましたが、これらによってカスタマーエクスペリエンスがいくつかの面で改善されました。
私たちは現在、手紙を以前よりも早く、より迅速に、より簡潔に、そして先ほど述べた他の特性を備えて生成できるようになりました。振り返ってみると、このアプリケーションの構築自体はそれほど難しくありませんでしたが、私たちにとって初めての取り組みだったため、大きな学びの機会となりました。当時は乗り越えられないように思えました。単純に分類したり、特定の単語を抽出したりする標準的なアルゴリズムの問題ではなく、固有表現認識のような問題でもありません - 手紙を生成するという課題だったのです。そのため、問題をどのように分解するかを考える必要がありました。
最初に、デザインに関する協力から始めました。データチーム、ビジネスパートナー、AWS Managementと協力し、組織全体で非構造化データを含むデータプラットフォームの最適化を含むロードマップを計画しました。Scottが話したことすべてには、プラットフォームとツール類の構築も含まれており、そのためにはCEOレベルでの経営陣の賛同が必要でした。幸いなことに、当時のCEOには「最高の遺伝子関連企業の一つになる」という明確な方針がありました。これは次にJimmyが話す内容ですが、私にとって、この全体の成功を一言で表すとすれば、それは経験に基づく加速化でした。
私たちは最初、問題にどうアプローチすればいいのか分かりませんでした。しかし、それこそが問題を分解し、様々な方法でテストする助けとなりました。AWSは専門家を派遣して、すべてのテストを支援し、最終的に優れたソリューションを提供するのを手伝ってくれました。Experience-based accelerationは、AWSで私たちが使用している開発を加速させるメカニズムです。私たちが見てきた経験では、プロジェクトが遅延したり失敗したりする主な理由は、技術的な問題ではなく、人間の働き方にあります。主に組織的な問題です - お互いにコミュニケーションを取らず、組織内にサイロが存在し、十分な協力ができていないのです。
これは、お客様がAWSで私たちが行っているような方法でイノベーションと協力を確実に行えるようにするための方法です。これは、ビジネスの利害関係者、開発者、意思決定者を一つの部屋に集めて実際に構築を行う変革的な手法です。重要なのは構築することと、障害が発生した際に素早く決定を下せるよう、適切な意思決定者を部屋に配置することです。これにより、イノベーションのための組織能力が生まれ、開発の加速が促進され、AWSの専門家と同じ部屋で適切なガイダンスを受けながら開発を行うことで、ビルダーたちの能力が強化されます。
これは3〜6週間のプロジェクトで、実際の構築は3日間で行われます。最初のパートは経営陣との連携構築です。チームがこのプロジェクトに取り組めるよう、経営陣の賛同が必要だからです。成功基準を定義し、加速フェーズで何を行うかを特定します。複数のワークストリームを定義し、開発を加速させるために並行して作業を進めます。その後、実際の3日間の取り組みを行います。パンデミック以降、リモートでも実施しており、リモート、ハイブリッド、対面のいずれでも機能します。全員が同じ部屋またはZoomの会議に参加して開発を行います。意思決定者がおり、決定が必要な場合のエスカレーション方法も用意されており、その3日間で構築を行います。
New York Lifeでは、これは非常に効果的な仕組みだということが分かりました。少なくとも12回以上のEBSを実施してきました。最初は労力がかかるため抵抗があるものですが、一度その成果を目にし、デリバリーがどれだけ加速され、イノベーションを促進し、組織の能力を高めるかを実感すると、New York Lifeにとって日常的な取り組みとなりました。今では完全に定着しています。Cloudチームが週末にプロダクション環境でEBを実施したという話も聞きました。彼らにとってはもう日常的な活動となっているのです。重要なのは、これがAWSからの投資であり、専門家を無償で派遣してイノベーションを支援してくれるということです。
データとAIの journey から得た教訓と今後の展望
このデータとAIの journey を通じて、数多くの教訓を得ました。皆さんにも、何をすべきで何をすべきでないかを持ち帰っていただきたいと思います。私たちが学んだのは、常にスケールを考慮して設計すべきだということです。North Star（明確な目標）を念頭に置きながら、しかし反復的に構築していく必要があります。一度にすべてを行うことはできません。小さな単位で構築し、早期に失敗し、必要に応じて方向転換することが重要です。アーキテクチャレビューを優先すべきです。データ変革の過程でこれらの教訓を学びましたが、そのアーキテクチャの小さな部分を実装する際には、必ずアーキテクチャレビューを行い、AWSのベストプラクティスに従い、適切なツールを使用しているかを確認するためにAWSにアーキテクチャのレビューを依頼してください。
Foundation Modelはもはやコモディティ化しています。世界中の誰もが同じFoundation Modelにアクセスできます。重要なのはデータです。それこそが他の組織との差別化要因となります。常に強固なデータ基盤を構築し、そのデータに適したモデルを持ち込むことが大切です。データをモデルに合わせるのではなく、モデルをデータに合わせるのです。繰り返しになりますが、早期に失敗することが非常に重要です。これがAmazonでの私たちの働き方です。早期に失敗し、方向転換し、変更を加えます。スピード感を持って意思決定を行い、早期に失敗し、必要な場合は変更を加えることを心がけてください。
先ほども触れましたが、大企業には多くのサイロが存在します。私は20年以上にわたって大企業と仕事をしてきましたが、そういったサイロを目にしてきました。部門間のコミュニケーションが不足しており、メールやTeams、Zoomを通じてしか会話がありません。これを打破する必要があります。Amazonでは、ビジネス側のステークホルダーと技術側のステークホルダーが一緒に働く小規模なチームで運営しています。私たちはこれを「Two-pizzaチーム」と呼んでいます。具体的な成果を出す小規模なチームを作ることが重要です。そして最後に、ビジョンに対しては揺るがない姿勢を持つことです。繰り返しになりますが、North Starを念頭に置き、それに対しては揺るがない姿勢を持ちつつ、その達成方法については柔軟に対応し、必要に応じて軌道修正を行うことが大切です。
私たちの時代を代表するイノベーターの一人の言葉で締めくくりたいと思います。変化を恐れるべきではありません。変化は常に存在するものです。私たちは、特にAIに関して、これほどの技術革新が起きている時代に生きることができて、とても幸運です。それを受け入れ、吸収し、そして素早くイノベーションを起こしていきましょう。その変化を受け入れ、新しいものを作り出し、魔法を起こしましょう。以上で私からの説明を終わります。必ずレビューを行うようにしてください。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion