※本レポートは、AWS re:Invent 2024のセッション「Data engineering for ML and AI with AWS analytics (ANT405)」の内容を基に作成されています。セッションの詳細情報は https://go.aws/reinvent でご覧いただけます。本レポートでは、セッションの内容を要約・整理しております。なお、本レポートの内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルのセッション動画をご視聴いただくことをお勧めいたします。

セッション登壇者：

• Uday Narayanan (AWS Principal Solutions Architect)
• Tim Kraska (AWS Director of Applied Sciences & MIT教授)
• Moe Haider (Nexthink Engineering Leader)

より多くのAWSのイベント情報は https://go.aws/3kss9CP でご覧いただけます。また、AWSの最新動画は http://bit.ly/2O3zS75 、イベント関連動画は http://bit.ly/316g9t4 にて配信されています。

1. はじめに

1.1. 発表者の紹介

Uday Narayanan

• AWS Principal Solutions Architectとして従事
• 本セッションの主進行を担当
• AWSのアナリティクスサービスを活用したデータ戦略の構築と実装について解説

Tim Kraska

• AWS Director of Applied Sciencesとして所属
• MIT教授を兼任
• 機械学習とシステムの接点に関する研究が専門
• RedshiftのQuery Editor v2における生成的SQL機能の開発を主導
• 本セッションでは自然言語からSQLへの変換に関する新機能を発表

Moe Haider

• Nextthinkの Engineering Leader
• CTOオフィスのprincipal staffとして従事
• アイデアの実現を担当
• デジタルワークプレイスプラットフォームを提供するNextthinkにおける以下の実例を共有
• 大規模データプラットフォームの構築事例
• 生成AIを活用したサービス開発事例

これら3名の専門家は、AWS技術責任者、学術研究者、実務者という異なる視点から、データエンジニアリングの重要性と実装方法について包括的な知見を提供しています。

1.2. セッションの概要と目的

本セッションは、AI/MLシステムの性能と精度が、データの品質、関連性、整合性に直接依存していることを前提に、効果的なデータエンジニアリングの重要性について解説するものです。特に、モデルのトレーニングデータや、生成AIアシスタントで使用される検索拡張生成（RAG）システムにおけるデータの品質が、システムの成功に直結することに焦点を当てています。

データエンジニアリングの役割として、以下の3つの主要な機能を提供することが重要であることを示しています：

1. 高品質なデータの可用性の確保
2. データへのアクセシビリティの保証
3. AI/ML実装のためのデータの使用可能性の担保

これらの機能により、AIモデルが効果的に学習し、推論を行い、適切なアクションを取ることが可能になります。このセッションでは、これらの目的を達成するためのAWSアナリティクスサービスの活用方法について、具体的な実装方法を解説します。

具体的には、以下の内容について詳しく説明が行われます：

• データの取り込みから保存、処理、統合までの完全なエンジニアリングソリューション
• 生成AIチャットアシスタントのためのデータアクセシビリティの確保
• その他のAI/MLアプリケーションへのデータ提供方法

セッションの特徴として、理論的な説明だけでなく、Nextthinkの実例を通じて実践的な知見も共有され、参加者が自社での実装に活かせる具体的な方法論を学ぶことができる構成となっています。

2. データ戦略の重要性

2.1. AI/MLアプリケーションの現状と利用事例

Uday Narayanan：今回のセッションでは、まず会場の皆さんに簡単な質問をさせていただきました。「組織内でAI/MLアプリケーションを運用している方はどのくらいいらっしゃいますか？」遅い時間帯ということもあり、挙手は予想より少なかったのですが、実際には多くの組織でAIとGen AI、特に後者への関心が非常に高まっています。

その理由として、以下の3つの主要な効果が期待されているためです：

1. カスタマーエクスペリエンスの変革
2. 従業員の生産性向上
3. ビジネスオペレーションの全体的な改善

現在、Gen AIの活用事例は多岐にわたります。これから詳しくお話しする仮想チャットアシスタントの他にも、テキスト要約やコード生成といった従業員の生産性を向上させる用途があります。また、従来型のAI/MLユースケースとして、小売需要予測、予測分析、感情分析なども依然として重要な位置を占めています。

これらのアプリケーションを成功させ、顧客に採用してもらうためには、いくつかの重要な要素があります。しかし、最も重要なのは、機械学習モデルのトレーニングに使用する高品質なデータが利用可能で、アクセス可能であることです。なぜなら、データこそが、顧客に個別化された体験を提供する上での重要な差別化要因となるからです。このような質の高い顧客体験こそが、アプリケーションの採用率を高め、最終的な成功につながるのです。

2.2. データ戦略の基本構成要素

Uday Narayanan：今日のデータ環境では、構造化・非構造化を問わず、様々なデータソースが存在しています。データ戦略を構築する上で、最初のステップは、これらすべてのデータを中央の場所に取り込むことです。これはバッチ処理でもストリーミング処理でも構いません。

私たちの推奨事項として、データは生のフォーマットでエンタープライズデータレイクに取り込むことを勧めています。この理由は、将来データを再処理する必要が生じた場合に、元のデータが利用可能な状態を保持できるためです。

取り込んだデータは、ETLツールを使用して処理されます。ここでETLロジックを構築し、データ変換を実施します。この変換されたデータは、下流のアプリケーションが容易に消費できる構造に整理されます。

次のステップとして、変換されたデータをカタログ化し、データガバナンスルールを適用します。ここで重要なのは、データのプライバシーとアクセス制御です。データへのアクセスが必要なシステムやユーザーにのみアクセス権を付与し、不要なユーザーにはアクセスを制限する必要があります。つまり、最小権限の原則を確実に遵守することが重要です。

このデータは組織内のビジネスユニットや他のユーザーが利用可能となり、以下のような様々なデータ処理パイプラインを構築することができます：

• 機械学習用のトレーニング・検証データセットの生成
• データ変換
• Gen AIユースケース用のベクターデータストアへのデータロード
• 特徴量エンジニアリング

最後に、トレーニングと検証のデータセットはAIモデルで利用可能となり、これらを基にモデルのトレーニングとアプリケーションの構築が行われます。

さらに、ユーザーがアプリケーションと対話する際に得られる貴重な情報をフィードバックループとしてデータレイクに送り返し、将来のモデルチューニングや微調整に活用することも可能です。

2.3. AWSサービスを用いたデータ戦略の実装

Uday Narayanan：では、これまでお話しした内容をAWSのサービスを使ってどのように実装するのか、具体的に見ていきましょう。

まず、様々なデータソースからのデータ取り込みについては、AWS Glueを使用することで70以上の異なるデータソースに接続することができます。これはGlueコネクタを通じて実現されます。

ストリーミングのユースケースでは、二つの選択肢があります。Amazon Managed Streaming for Apache KafkaとKafkaコネクタを使用する方法と、よりAWSネイティブなソリューションとしてAmazon Kinesis Data Streamsを使用する方法です。

オンプレミス環境にデータが存在するシナリオについては、AWS Data Syncを活用することで、オンプレミスのデータストアに接続し、データレイクにデータを取り込むことができます。

これらのサービスを使用して取り込んだすべてのデータは、先ほど説明したように、Amazon S3上のデータレイクに生の形式で保存されます。その後、AWS GlueやAmazon EMRを使用してデータ処理パイプラインやデータ処理ジョブを構築し、データのクリーニング、検証、データ品質チェックを実施します。特にAWS Glueでは、ETLパイプラインの一部としてデータ品質機能が組み込まれています。

変換されたデータは、AWS Glue Data Catalogでカタログ化され、AWS Lake Formationを使用して細かいアクセス制御を構築します。また、アナリストや非技術系ユーザーがビジネスセマンティクスやビジネスの意味、コンテキストを使用してデータを容易に見つけられるように、ビジネスカタログを上層に構築することを推奨しています。このビジネス層の構築にはAmazon Data Zoneを使用することができます。

下流のアプリケーションでのデータ処理には、AWS Glue、Amazon EMR、あるいは機械学習の専門家がSageMakerですべてを完結させたい場合はSageMaker Data Wranglerを使用することができます。この処理過程でトレーニングおよび検証データセットが生成されます。また、Gen AIベースのユースケースでRAGを使用する場合は、Amazon AuroraやAmazon OpenSearchなどのベクターストアにデータを保存することも可能です。

このトレーニングおよび検証データセットは、SageMaker AIやGen AIのユースケースではAmazon Bedrockでモデルをトレーニングするために使用されます。そして、これらのモデルを使用したGen AIベースのアプリケーションが構築され、顧客がそれと対話することになります。

最後に、ユーザーとの対話において、フォローアップの質問が行われる際にセッション情報とコンテキストを維持する必要がある場合は、Amazon DocumentDBやAmazon DynamoDBなどにセッション情報とコンテキストを保存することができます。

3. データサービスのベストプラクティス

3.1. ストリーミングサービス（Amazon Kinesis, MSK）

Uday Narayanan：これらのサービスについて、より詳しく見ていきましょう。まずAmazon Kinesis Data Streamsについてお話しします。これはサーバーレスソリューションで、数秒でギガバイト規模のデータをストリーミングできます。サーバーレスサービスですので、使用した分だけを支払う形式となっています。

Amazon Kinesis Data Streamsを使用する際の重要な推奨事項の一つは、データを書き込む前に集約して圧縮することです。これを簡単に実現するために、Kinesis Producer Libraryを使用できます。これには集約機能が組み込まれています。

消費者側では、Kinesis Consumer Libraryを使用して簡単にデータを解凝集できます。同時に、このライブラリはチェックポイントと障害対応機能も提供します。つまり、ストリーミングアプリケーションが停止して再起動した場合でも、どこから再開すべきか、あるいはどこで中断したかを把握できます。

Kinesisでは、ストリームは複数のシャードに分割され、各シャードは消費者あたり2メガバイト/秒のスループットを持っています。複数の消費者がいる場合、この2メガバイト/秒/シャードは消費者間で共有されます。そのため、複数の消費者がKinesisストリームから読み取る場合は、Enhanced Fan-Out Consumersの使用を推奨しています。Enhanced Fan-Out Consumersを使用すると、各消費者がシャードごとに専用の2メガバイト/秒のスループットを得られます。これにより、消費者を追加したときに既存のジョブが遅くなるという問題を回避できます。

Kinesisでは、オンデマンドモードまたはプロビジョンドモードを選択できます。推奨事項として、まずはオンデマンドモードで開始し、トラフィックパターンを理解した後、予測可能なパターンがある場合にプロビジョンドモードに移行することをお勧めします。

Amazon Managed Streaming for Apache Kafkaについては、クラスターのCPU使用率を60%前後に維持することを確認してください。これは、運用上の問題やブローカーの障害が発生した場合の回復に十分な余裕を確保するためです。

MSKでは、各ノードタイプには対応可能な最大スループットが設定されています。ここでも推奨事項として、サポートされているCPUの最大値の80%前後を維持するようにしてください。

可用性の高いクラスターを構築するには、MSKクラスターを3つのアベイラビリティーゾーンにわたって展開し、レプリケーション係数3で、つまりすべてのデータとトピックが3つのアベイラビリティーゾーンにレプリケートされるようにします。最小同期レプリカを2に設定することで、1つのブローカーが停止しても、クラスターは問題なく通常通り運用を継続できます。

最後に、約3週間前にMSK用のExpress Brokersを発表しました。これは通常のブローカーと比較して、より高いスループットと迅速なスケーリングを提供します。現在MSKを使用しているか、使用を検討している場合は、このExpress Brokersをユースケースでテストすることをお勧めします。

3.2. データ統合（AWS Glue）

Uday Narayanan：AWS Glueを使用する際の重要なベストプラクティスについて説明します。

まず、ワーカーの適切なサイジングが重要です。Glueには異なるワーカータイプがあり、各ワーカータイプはエグゼキュータあたりのCPUとメモリ量が異なります。適切なサイジングを行うための最良の方法は、Spark UIにアクセスしてエグゼキュータの使用状況と活用状況を分析することです。Glueでは、Spark UIへのワンクリックアクセスが提供されているので、この分析が容易に行えます。

次に、時間的な制約がないジョブに対してはFlex Executionの使用を推奨します。Flexは予備の処理能力を活用するもので、ジョブの開始に若干の遅延が生じる可能性がありますが、その分コスト削減が可能です。開始の遅延があるため、時間に余裕のないジョブには適していません。

増分処理が必要な場合は、ジョブブックマークを使用することを推奨します。ジョブブックマークを使用すると、どのデータが既に処理されたかを追跡でき、次回ジョブが実行される際には、中断したポイントから処理を再開できます。

一般的なSparkの最適化として、シャッフルの最適化と述語プッシュダウンを実装することで、ネットワーク上で転送されるデータ量を最小限に抑えることができます。これらの最適化は、ジョブの全体的なパフォーマンスを向上させる重要な要素となります。

3.3. データ品質管理

Uday Narayanan：データ品質は、機械学習モデルのトレーニング時に極めて重要な要素です。なぜなら、高品質なデータでトレーニングすることが不可欠だからです。

AWS Glueのデータ品質機能を使用すると、パイプラインの異なる段階でデータ品質ルールを構築することができます。具体的な実装方法を説明します。まず、異なるデータソースからGlueコネクタを使用してデータを取得し、そのデータをGlue Data Catalogの中でカタログ化します。このGlue Data Catalogの中で、データ品質ルールを設定できます。これらのルールは、データの更新が行われるたびに実行され、新しいデータが期待する品質レベルを維持しているかを確認します。

さらに、Glueでは、ETLジョブの一部としてインラインでのデータ品質チェックも実行できます。この機能により、GlueのETLジョブ内にデータ品質トランスフォーメーションを組み込むことができます。このトランスフォーメーションは、設定されたデータ品質ルールに基づいてデータをチェックします。

チェックの結果、データ品質ルールを満たすデータはデータレイクに書き込まれます。一方、品質基準を満たさないデータは別のセクションに書き込まれます。このように分離されたデータは、レビューを行い、問題がないことを確認した後で、データレイクに書き込むことができます。

このように、データ品質管理には複数のアプローチがあり、組織のニーズに応じて適切な方法を選択することができます。

3.4. データガバナンス

Uday Narayanan：データガバナンスに関して、以下のベストプラクティスを共有します。

まず、所持しているすべてのデータは必ずテクニカルデータカタログ内でカタログ化する必要があります。Glue Data Catalogを使用する際、大量のパーティションを持つテーブルでは通常パフォーマンスの低下が見られます。この問題に対処するため、Glueパーティションインデックスとパーティションフィルタリングを使用して、期待するパフォーマンスレベルを維持することを推奨します。

また、統計情報の実行も重要なポイントです。なぜなら、AthenaとRedshiftのコストベースオプティマイザーはこれらの統計情報を使用してクエリの最適な実行プランを構築するからです。そのため、Glueテーブルに対して定期的に統計情報を収集・実行することを確実に行ってください。

Lake Formationで細かいアクセス制御を設定する際は、タグベースのアクセス制御を使用することを推奨します。これは、Lake Formationの管理や細かいアクセス制御の管理をスケールさせるのに役立ちます。タグベースのアクセス制御の仕組みは以下の通りです：

テーブルにタグを割り当て、Lake Formation内でアナリストユーザーが特定のタグを持つテーブルにアクセスできるように設定します。この方法では、新しいテーブルが追加された場合、個々のテーブルごとに細かいアクセス制御を設定する必要はありません。代わりに、特定のタグを付けてテーブルを作成するだけで、すでにLake Formationでそのタグに対する権限が付与されているため、アナリストユーザーは新しいテーブルにアクセスできるようになります。

最後に、前述した通り、ビジネスカタログを用意することを確実に行ってください。これにより、アナリストやビジネスユーザーなどの非技術系ユーザーが、分析に必要なデータを見つけやすくなります。

4. 構造化データとGen AIの統合

4.1. 自然言語からSQLへの変換の課題

Tim Kraska：それでは、構造化データをジェネレーティブAIアプリケーションの一部として活用する方法について説明します。私は機械学習とシステムの接点に関する研究を行っており、例えば私のチームはRedshiftのクエリエディタv2における生成的SQLなどの機能を開発しました。

文書やRAGとは異なり、構造化データを扱う場合はより複雑な課題があります。なぜなら、単一の文書には通常、答えが直接含まれていないからです。代わりに、一般的なケースでは正規化されたスキーマがあり、複数のテーブルにわたってデータが分散しています。例えば「先月の収益は？」という質問に答えるには、適切なクエリを生成して必要な情報を取得する必要があります。

ここでの重要な洞察は、自然言語からSQLへの変換プロセスが、構造化データにおけるRAGインフラストラクチャに相当するということです。つまり、データベースからデータを統合する場合、リクエストに基づいてクエリを生成する必要があります。

この過程には多くの課題があります。例えば、「100人未満のテスト受験者がいる国の学校数を数えてください」という質問に対して、大規模言語モデルはクエリを生成しますが、それは特定のスキーマとは無関係かもしれません。実際には、その回答を得るために必要なテーブルの結合は、まったく異なる方法で行う必要があるかもしれません。

また、「チェコ共和国のガソリンスタンドでの取引の商品説明をリストアップする」という質問では、モデルが既にスキーマについて学習していたとしても、国名が「CZ」や他の略称でエンコードされている可能性があります。これは非常に一般的な問題です。例えば、カリフォルニアの収益を見たい場合、それが「California」、「CA」、郵便番号、あるいは完全に異なる方法でエンコードされているかを知る必要があります。

さらに、各データベースには独自の動作や構文の違いがあります。SQLは標準化されていますが、実際の実装では微妙な違いがあります。例えば、Redshiftでは曖昧な列名の処理が他のエンジンとは異なる場合があります。

このように、構造化データをジェネレーティブAIアプリケーションの一部として利用可能にするには、これらすべての課題に対処し、解決策を構築する必要があります。これは独自の研究分野となっており、多くの論文が書かれ、さまざまな提案がなされています。今では、誰が最良の解決策を持っているかを判断するためのベンチマークも存在します。これらの課題は私たちの顧客にとって大きな障壁となっています。なぜなら、正しく実装するには多くのML専門家が必要だからです。

4.2. Amazon Bedrock Knowledge Basesの紹介

Tim Kraska：本日のSwami氏の基調講演で発表された新サービス、Amazon Bedrock Knowledge Bases for Structure Data Storesについて説明します。このサービスは、Bedrockプラットフォームの一部として、自然言語からSQLへの変換を簡単にセットアップできる知識ベースを提供します。

私たちはこれまでの全てのベストプラクティスをパッケージ化し、さらに高精度を実現するための追加機能を組み込んでホステッドサービスとして提供します。このサービスの主な特徴は以下の通りです：

• 構造化データへの迅速なアクセス
• シンプルなセットアップ
• 高い精度
• 豊富なカスタマイズオプション

また、SQLインジェクションなどに対するセキュリティ対策も組み込まれています。これにより、従来のフローが次のように変更されます：

1. リクエストが生成AIアプリケーションに入力される
2. 自然言語SQLエンジンにリクエストが転送される
3. 生成されたクエリがデータベースに送信される
4. 結果が返される
5. 必要に応じて、従来の知識ベースからドキュメントを取得することも可能
6. これらすべてが会話履歴とともにモデルに送られ、最終的な回答が生成される

このプロセスは全てBedrockプラットフォームの一部として提供されます。

一見魔法のように見えるかもしれませんが、実際にはいくつかの重要な技術が背後で動作しています。最大の課題の一つは、リクエストが入ってきた時に適切なテーブル、カラム、その他の要素を選択することです。私たちが発見したのは、クエリが頻繁に繰り返されること、そしてクエリ履歴から多くのことを学べるということです。そこで、私たちの「魔法の武器」の一つとして、過去のクエリパターンを分析し、どのカラムが最も頻繁に使用され、どのように結合されているかを把握することで、高い精度を実現しています。

4.3. 実装デモンストレーション

Tim Kraska：Amazon Bedrockでの知識ベース作成プロセスについて、実際の手順をご説明します。まずAmazon Bedrockにアクセスし、knowledge basesセクションで、新しいオプションとして「構造化データによる知識ベースの作成」を選択します。

セットアップの最初のステップでは、Amazon Redshiftを選択し、必要なクレデンシャルを入力します。ここでは2つの選択肢があります：

1. 使用したいRedshiftインスタンスのタイプ（サーバーレスまたはプロビジョンド）
2. 接続したRedshiftエンドポイントまたはGlueカタログから使用するカタログの選択

次に、様々なカスタマイズオプションを設定できます。例えば、テーブルに対して追加のセマンティック注釈を提供できます。これは、暗号的なテーブル名がある場合に、それについてより多くの情報を提供することで、より適切なクエリが生成されるようになります。また、特定のテーブル名やカラムの包含や除外を設定したり、典型的なユースケースのクエリ例を提供することもできます。

知識ベースを作成した後、次のステップは、選択したRedshiftのテーブルにアクセスするための適切な権限を設定することです。これは、知識ベースが実際にテーブルを選択して作成できるようにするために必要な重要なステップです。

「Sync」機能は、すべてのメタデータを取り込み、クエリ履歴分析を開始するための強制メカニズムです。これは自動的に行われますが、手動で強制することもできます。

最後に、プロンプト生成に使用するモデルを選択します。ここで重要な点は、生成的SQLの生成にも内部的にモデルとジェネレーティブAIを使用していますが、ここで選択するモデルは、主にLLMに送信する最終的なプロンプトに使用されるということです。

このデモ全体は実際には2分半程度で完了できる簡単なプロセスですが、今後さらに多くの機能が追加される予定です。

5. Nextthinkの事例研究

5.1. データプラットフォームの要件と構築

Moe Haider：私はNextthinkからスイスより参加しています。CTOオフィスのエンジニアリングリーダー／プリンシパルスタッフとして、アイデアの実現を担当しています。

Nextthinkは、従業員のテクノロジー体験をシームレス、効率的、より良いものにすることをミッションとしています。私たちは、従業員がデバイスやアプリケーション、テクノロジー全般をどのように使用しているかを監視・分析するデジタルワークプレイスの観測・自動化プラットフォームを提供しています。このプラットフォームは、生産性に影響を与える前に問題を検出し、修正や自動化のためのツールを提供し、ITシステムを最適化するためのインサイトを提供しています。

データプラットフォームを構築する際、いくつかの重要な要件がありました。まず、データ取り込みの高成長への対応です。プラットフォーム立ち上げ時には100万エンドポイントからのデータ送信に対応する必要がありましたが、1-2年以内に3000-4000万エンドポイントへのスケールが必要でした。

また、様々なユースケースと製品をサポートするための高頻度なデータ検索が必要でした。すべての時系列クエリについて、サブセカンドでのクエリ速度を実現する必要がありました。これは非常に野心的な要件でした。さらに、最小限の労力でリアルタイムユースケースを実現できるようにする必要がありました。チームがリアルタイムユースケースを実装するたびにゼロから作り直す必要がないようにしたかったのです。

最後に、特にAIアプリケーション向けに、チームがデータを必要とする際に迅速に移動できるようにすることが重要でした。

現在の規模感をお伝えすると、2000万以上のエンドポイントから毎秒500万以上のレコードがデータプラットフォームに送信され、取り込まれ、データベースに保存されています。執筆時点で、時系列データベースには2.5兆行以上のデータが格納されており、100テラバイト以上のデータ量となっています。様々なユースケースと製品が、このデータに対して毎分100万回以上のクエリを実行しています。

5.2. MSKの大規模運用における知見

Moe Haider：私たちのデータプラットフォームでは、MSKが非常に重要な役割を果たしています。現在、MSKでの処理量は以下の規模に達しています：

• トラフィック：1-3ギガバイト/秒で変動
• メッセージ数：毎秒100-200万メッセージを処理
• クラスター構成：本番環境で13のGraviton3ベースのクラスターを運用
• 各クラスター：24のブローカー、3,000-4,000のトピック、16,000パーティション
• データ保持：トピックに対して12-24時間の保持要件があり、一部のトピックは1週間で5テラバイト以上に成長

このような大規模な運用を効率的に行うため、過去1-2年間で以下の改善を実施してきました：

まず、Graviton3インスタンスへの移行を行い、コストとパフォーマンスの両面で15%の改善を達成しました。

次に、Rack awarenessを実装しました。これにより、消費者が最も近いブローカー（理想的には同じアベイラビリティーゾーン内）に接続できるようになり、ネットワークコストを大幅に削減することができました。完璧な状況では、アベイラビリティーゾーン間のコストを発生させることなく運用が可能です。

今年は、MSKでティアードストレージを有効化しました。これは、ブローカーのストレージをコールドストレージとホットストレージに分割する機能です。データの中には1回の処理で十分なものもありますが、信頼性と災害復旧のために保持が必要です。このようなデータをコールドストレージに移動し、新鮮なデータのみをホットストレージに保持することで、MSKのストレージコストを削減し、パフォーマンスと運用の改善も実現しました。

また、MSKの最新バージョンへの追随も重視しています。新しいバージョンではパフォーマンス向上やバグ修正、新機能の追加が行われており、私たちは新リリースを積極的に活用しています。

特に重要な教訓として、MSKでは事前対応型のモニタリングが非常に重要です。私たちは様々なMSKメトリクスに基づくダッシュボードを構築し、サービスを監視し、必要に応じて事前にスケーリングができるようにしています。

このように、MSKは私たちにとって良いソリューションとなっています。小規模なチームでこれらの改善を実施できており、他のプロバイダーと比較すると3分の1のコストで運用できています。私たちの規模では、これは数百万ドルのコスト削減につながっています。

5.3. Autopilotサービスの開発

Moe Haider：Nextthinkの製品の一つであるAutopilot for Service Deskについて説明させていただきます。従来、この製品はAmplifyという名前でしたが、現在Autopilotにリブランドされています。

この製品が解決する典型的なシナリオをご説明します。例えば、職場でSAPにアクセスできない問題が発生したとします。従来は、ITチケットを作成し、サービスデスクのオペレータがそのチケットを開いて問題解決を試みます。オペレータはNextthinkのAmplify（現Autopilot）を使用して、問題、アプリケーション、ネットワークなどに関する様々なデータにアクセスし、診断を行い、サービスデスクシステム上で直接修正を行います。

これは、生成AI技術を活用してサービスデスクオペレータの作業をより簡単、迅速、効率的にするための完璧な機会でした。Amplify Autopilot for Service Deskは、システムに入ってくる各チケットに対して、リアルタイムでオペレータの作業を支援し、必要な作業を最小限に抑えます。

具体的には、以下の機能を提供しています：

1. 問題の要約と可能性のある症状のリスト化（例：SAPにアクセスできない場合、ローカルネットワーク、VPN、グローバルサービスの停止など、考えられる原因を列挙）
2. これらの症状に対する直接的な解決計画の提供（Nextthinkの機能であるリモートアクションやワークフローを使用した自動化を含む）
3. 問題が解決されない場合のインサイトや類似チケットのリストの提供

このように、Nextthinkの持つ豊富なデータと生成AIの能力を組み合わせることで、サービスデスクの運用を大幅に効率化し、問題解決時間を短縮することが可能となりました。

5.4. NL2NQLの実装における課題と解決策

Moe Haider：このシステムの生成機能において、データプラットフォームを活用して問題と症状を生成する方法についてご説明します。チケットがMSKに流れ込むと、Gen AIアプリケーションチームがMSKを通じてチケット作成イベントを監視し、プロンプトエンジニアリングを使用してGen AIアプリケーションを構築します。そして、NQLを使用してこの問題に関連するすべてのデータ（デバイス、ネットワークなど）を取得し、それを基に問題と症状のリストを生成します。

しかし、この製品の開発と展開を通じて、大きな課題に直面しました。大量のデータを基盤モデルに送信すると、モデルの集中力が低下し、プロンプトのフォーカスが影響を受ける可能性があることがわかりました。この問題に対処するため、すべてのクエリに対して前処理パイプラインを実行するようにしました。具体的には、クエリを取得し、基盤モデルに渡してデータを要約し、最も重要なデータポイントを抽出します。その後、これらの重要なデータポイントをプロンプトに渡すことで、プロンプトがより簡潔で的確になり、基盤モデルからの回答の精度が向上しました。

IT問題は非常に断片的で、多くのカテゴリーがあります。デバイスの問題、グローバルな問題、または「キーボードと椅子の間の問題」（ユーザーエラー）など、様々です。最後の問題は残念ながら解決できませんが、他の問題に対しては、まずユースケースのサブセットに焦点を当て、これらのケースに必要なNQLクエリを事前定義することから始めました。

この方法が機能することを確認した後、システムをより柔軟にし、より多くのユースケースをカバーするために反復を重ねました。その結果、チケットの問題に基づいてNQLを生成するようになりました。例えば、問題がアプリケーションやWebアプリケーションに関連している場合、システムはそのカテゴリーに関連するNQLクエリのセットを生成します。

この実現のために、内部で「NL2NQL」という技術を開発しました。これはTimが説明したものと非常に似ていますが、私たちの独自のクエリ言語に特化しています。この技術では、問題の説明や質問を入力すると、ワークフローがそのクエリを生成します。

しかし、基盤モデルはNQLで訓練されておらず、SQLは知っていてもNQLや私たちのクエリの特性は知りません。この課題を解決するため、SageMakerを使用してCode Llamaモデルをベースとした小規模なNQL生成専用モデルを構築しました。このモデルは、より小規模で、より優れた性能を発揮し、より簡潔です。指示が不要で、構文をよく理解し、スキーマを把握しており、50,000以上の私たちのデータセットの例を記憶しています。

特筆すべきは、すべてを自動化した後のファインチューニングプロセスが2時間未満で完了することです。チームは2-3週間ごとにモデルのファインチューニングを行うというリズムを確立し、新しいベースモデルへの移行やアップグレード、データセットの追加などを行っています。これにより、より正確で改善されたファインチューニングモデルを定期的にリリースできるようになりました。

6. データレイクの集中管理

6.1. クロスカスタマーデータの統合

Moe Haider：Autopilotのインサイト機能について、もう少し詳しく説明させていただきます。インサイトは、機械学習技術、データパターンの異常検出、統計分析、そしてGen AI技術を用いて生成される知見です。良質なインサイトを生成するためには、より多くのデータが必要です。そのため、クロスカスタマーデータは私たちにとって非常に重要でした。

しかし、私たちのセル型アーキテクチャにより、これは単純な課題ではありませんでした。私たちは顧客を異なるリージョンに配置し、データのローカリティを尊重する必要がありました。例えば、ドイツの顧客は米国に接続したくないし、その逆も同様です。そのため、私たちは異なるリージョンにスタンドアロンのセルを展開し、顧客のリージョンに基づいてトラフィックを適切なセルにルーティングしています。

この構造は、データが複数のセルに分散され、単一の場所にまとまっていないという課題を生みました。この問題を解決するため、私たちはデータレイクでデータを一元化する方法を採用しました。各セルからのデータを、個人情報を元のソースに残したままセキュアに中央のデータレイクアカウントに移動させています。

この集中型のデータレイクにS3上で全てのデータを集約することで、より包括的なインサイトの生成が可能となりました。これにより、複数の顧客のデータを横断的に分析し、より価値の高いインサイトを提供できるようになりました。

6.2. データセキュリティとコンプライアンス

Moe Haider：一元化されたデータレイクを構築する際、セキュリティとコンプライアンスは最重要の課題でした。

まず、個人情報の取り扱いについて、私たちは厳格な方針を採用しています。個人を特定できる情報は決してソースのリージョンから外に出さないようにしています。これは、各地域の規制要件を遵守し、顧客のプライバシーを保護するために不可欠な対応です。

データの移行プロセスにおいては、セキュリティを最優先事項として設計しました。各セルからデータレイクアカウントへのデータ移行は、安全な通信チャネルを通じて行われ、データの整合性と機密性を確保しています。

また、AWSのIAMを活用して、きめ細かいアクセス制御を実装しています。これにより、各チームやユーザーが必要な最小限のデータにのみアクセスできるように制御しています。この制御は、AWS CloudFormationを使用して適切に管理され、必要なアクセス権限が適切に付与されるようにしています。

このように、セキュリティとコンプライアンスの要件を満たしながら、データの価値を最大限に活用できる環境を構築しています。

6.3. 分析ツールの提供

Moe Haider：S3上に集中化されたデータレイクを構築した後、私たちは社内ユーザーにこのデータレイクへのアクセスを提供することを決定しました。これは、データの価値を最大限に活用するための完璧な機会でした。

技術的な知識が少ないユーザー向けには、Amazon QuickSightのダッシュボードを提供しています。これにより、データを視覚的に確認し、基本的な分析を行うことができます。

より技術的なユーザー、特に開発者向けには、Amazon Athenaを提供し、より複雑なクエリを実行できるようにしています。これにより、必要に応じて詳細なデータ分析を行うことが可能です。

データへのアクセスについては、AWS CloudFormationを活用して適切なアクセス権限制御を実装しています。これにより、各ユーザーが適切なデータにのみアクセスできるようにし、セキュリティとコンプライアンスを確保しています。

このように、ユーザーの技術レベルや役割に応じて適切な分析ツールを提供することで、組織全体でデータ駆動の意思決定を促進しています。