re:Invent 2025: AIソリューション構築のためのデータ処理アーキテクチャ
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
re:Invent 2025 の書き起こし記事については、こちらの Spreadsheet に情報をまとめています。合わせてご確認ください
📖 re:Invent 2025: AWS re:Invent 2025 - Data Processing architectures for building AI solutions (ANT328)
この動画では、Sakti MishraとRadhika RaviralaがAIソリューション構築に必要なデータ処理アーキテクチャについて解説しています。89%のCDOがgenerative AIを優先する一方、半数以上がデータ基盤のAI対応に課題を感じている現状を指摘し、agentic AI HRオンボーディングシステムを例にAIにおけるデータの役割を説明します。既存エンタープライズデータをAIエージェントに公開する方法として、Retrieval Augmented GenerationとModel Context Protocolを紹介し、Amazon BedrockやAmazon EMRを活用したリアルタイムパイプラインの実装を実演します。さらに、Amazon Q Developerによるコード自動生成やvisual ETLパイプラインの構築デモを通じて、データパイプライン開発の生産性向上を示します。後半ではTrusted Identity Propagation、S3 Access Grants、Lake Formationのきめ細かいアクセス制御など、セキュリティ機能の強化について詳述し、SageMaker NotebooksやSpark Upgrade Agentといった新機能も紹介しています。
※ こちらは既存の講演の内容を最大限維持しつつ自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますのでご留意下さい。
本編
セッション導入：AIに対応できていないデータ基盤の現状
皆さん、こんにちは。まず初めに、ご参加いただきありがとうございます。皆さん、re:Inventを楽しんでいらっしゃることと思います。 私の名前はSakti Mishraです。Principal Data and AI Solutions Architectとして働いており、本日はAmazon EMRのPrincipal Product ManagerであるRadhika Raviralaと一緒に登壇しています。今日は、AIソリューションの構築に役立つデータ処理アーキテクチャについてお話しします。
始める前に、簡単なクイズから始めましょう。 いいですか？皆さんの組織のデータ基盤がAIに対応できていると感じている方は手を挙げてください。なるほど、手を挙げている方は非常に少ないですね。皆さん、このトピックに共感していただけると思います。では、始めましょう。
これが本日カバーする非常にハイレベルなアジェンダです。まず、AIにおけるデータの役割とは何かを明らかにします。 次に、モダンなデータ基盤の基礎的な柱とは何かを再確認します。そして、AIエージェントのために既存のエンタープライズデータをどのようにアンロックするかについて深く掘り下げます。その後、Radhikaがセキュリティと生産性に関連するAWSデータ処理エンジンに対して私たちが行った機能強化について深く掘り下げます。
Harvard Business Reviewによると、89%のCDOが 組織内でgenerative AIイニシアチブを優先していますが、インタビューした半数以上が、自分たちが持っているデータ基盤がまだAIに対応できていないと感じています。さて、これは何を意味するのでしょうか？これは、AIの状況を変革したいデータアナリティクスのデータ実践者として、私たちは一歩下がって、新鮮な視点で見直し、AI戦略を支える基礎的な決定を見る必要があるということを意味します。
AIエージェントとデータの役割：HRオンボーディングシステムの事例
では、実際のユースケースを使って、AIにおけるデータの役割を理解しましょう。 agentic AI HRオンボーディングシステムがあり、そこでAmyを採用したばかりなので、オンボーディングを開始してくださいというメッセージを送信すると仮定しましょう。そうすると、supervisorエージェントまたはorchestrationエージェントを通じて、エージェントのネットワークが起動されます。最初のエージェントはtask planningエージェントで、Amyのためにカスタマイズされたオンボーディングプランを構築します。2番目はonboarding buddyエージェントで、Amyのプロフィール、役割、バックグラウンドに基づいて、同僚と会うことを推奨します。そして3番目はexception handlingエージェントで、何かが計画通りに進まない場合に起動されます。例えば、Amyの入社日が遅れたり、Amyのデバイスが遅れたりした場合です。その場合、exception handlingエージェントは承認を再実行し、エージェントを更新して、すべてが計画通りに進むようにします。HR onboardingエージェントが効果的に機能するためには、適切なレベルのセキュリティとガバナンスを備えた構造化データセット、非構造化データセット、ベクトルストア、リアルタイムストリーミングデータセットへのアクセスを取得する必要があります。
それでは、お客様が直面している課題について理解していきましょう。主に3つの優先事項が考えられます。 1つ目は、人材と展望に関連するものです。組織内にはさまざまなエンジニアリングの役割がありますが、AIの状況が広がる中で、これらの役割間の明確な境界線が曖昧になり始めています。データエンジニア、機械学習エンジニア、データサイエンティスト、そしてAIエンジニアが、AIソリューションを構築するために密接に協力する必要が出てきているのです。2つ目は、お客様が現在のデータプラットフォームを構築するために何年もの投資を行ってきており、それをAI対応にするためにアジャイルである必要があるということです。しかし、既存のものを置き換えるのは簡単ではありません。では、どうすれば効率的な方法でAIエージェントに公開できるように、既存のものを拡張できるようにするのでしょうか？そして3つ目は、データを生データレイヤーから一連の変換を通じてレイクハウスに移行する従来のデータ処理方法がありますが、データ処理レイヤー自体に効率性をもたらし、効率と生産性を向上させるにはどうすればよいのでしょうか？
では、 AI向けのデータアーキテクチャの進化について深く掘り下げる前に、モダンデータ基盤の基礎的な柱とは何かを振り返ってみましょう。 まず第一に、複数のソースからデータソースをオンボードすることがわかっています。これには構造化、半構造化、非構造化データセットが含まれます。データセットが利用可能になったら、 データクレンジング、データエンリッチメント、そして一連の変換を経ます。さて、このAI時代において変化しているのは、基本的にデータクレンジングと変換レイヤーにおいて、データパイプライン開発を加速し、効率性を高めることができるAIをどのように取り入れるかということです。
データが 変換されたら、技術的メタデータとビジネスメタデータの両方を含むメタデータレイヤーが必要になります。そしてメタデータが利用可能になったら、 エンドユーザーがデータを見つけ、共有し、理解し、アクセスし、そしてデータに基づいて行動して、複数のアナリティクスとAIユースケースを構築できるような、複数のユースケースを実現できます。
Amazon SageMaker Unified Studio上のモダンデータ基盤アーキテクチャ
それでは Amazon SageMaker Unified Studio上に構築されたモダンデータ基盤を示す、ハイレベルなリファレンスアーキテクチャを見ていきましょう。 このアーキテクチャの中心には、ストレージレイヤーがあります。これにはレイクハウスが含まれており、Amazon S3またはS3テーブル上に構築されたデータレイク、あるいはAmazon Redshift上に構築されたデータウェアハウスまたはデータマートがあります。
レイクハウスレイヤーができたら、さまざまなメカニズムを通じてデータセットをオンボードする必要があります。1つ目はバッチインジェスションメカニズムで、複数のソースからデータセットを取得するスケジュールされたジョブを持つことができます。または、Amazon MSKやKinesisを統合できるリアルタイムストリーミングパイプラインを持つこともできます。そして、以前に発表した新機能であるZero-ETLメカニズムがあり、これによって複数のAWSデータソースだけでなく、非AWSデータソースもオンボードできます。しかし、データをAWSランドスケープにコピーしたくないというシナリオもあるかもしれません。むしろ、クエリフェデレーションを使用できるライブクエリメカニズムを通じて、データまたはデータのサブセットをクエリしたい場合もあります。
さて、レイクハウスにデータを格納したら、次に必要になるのが統合カタログです。ここでAmazon SageMaker Catalogを統合することができます。これは技術カタログとビジネスカタログの両方の機能を提供します。そしてこれを使用することで、データ品質、データリネージ、データ共有など、複数のガバナンス機能を導入することができます。これでデータプラットフォームの準備が整いましたので、複数の分析とAIのユースケースを導入できます。分析について言えば、ビジネスインテリジェンスのユースケースにはAmazon QuickSightを統合できますし、ダウンストリームシステム向けにデータをさらに変換するためにAWS GlueやAmazon EMRを統合することもできます。また、検索分析にはAmazon OpenSearchを統合したり、Amazon Bedrockを使用した生成AIアプリケーション開発を統合することもできます。
エンタープライズデータのAIエージェント公開：RAGによる最新情報の補強
さて、これで強固なデータ基盤ができましたね。では、これをAI対応にするために、どのように拡張または改善していけばよいでしょうか。 AI向けにデータレイヤーを変革する際、これを2つのパートに分類したいと思います。最初のパートは、エンタープライズデータがすでにあると仮定しましょう。それをAIエージェントに公開したい場合です。複数のメカニズムが考えられますよね。1つは、APIゲートウェイを通じてデータのサブセットを公開する方法です。2つ目は、データのサブセットをベクトルに変換し、それらのベクトルストアをナレッジベースとして利用可能にすることで、Retrieval Augmented Generationアーキテクチャが機能するようにする方法です。
あるいは別の方法として、データレイクやデータウェアハウスが利用可能な状態で、それをAIエージェントへのツールとして公開し、クエリを実行したりジョブを実行したりできるようにする方法もあります。MCPとRAGについては、今後のスライドで詳しくお話しします。デモもあります。では、2つ目のパートについてお話ししましょう。すでにエンタープライズデータがあり、それをAIエージェントにどう公開するかについてお話ししました。2つ目のパートは、データがレイクハウスに到着する前に、データパイプライン自体の設計にどのように効率性をもたらすかということです。
どうやってSparkコードを自動生成できるでしょうか。どうやってビジュアルETLパイプラインを自動生成できるでしょうか。どうやってデータ品質やデータリネージのジョブを自動化できるでしょうか。では、最初のパート、つまり既存のエンタープライズデータをAIエージェント向けにアンロックすることについて触れていきましょう。 これを理解するために、実際のユースケースを見ていきましょう。銀行のカスタマーサービスチームが構築している顧客向けAIチャットアシスタントがあると仮定しましょう。彼らは過去のデータに基づいてモデルをファインチューニングしており、エンドユーザーがやってきて、「今日の30年固定住宅ローン金利はいくらですか」と尋ねます。
さて、AIモデルは少し前にトレーニングされたものです。最新の情報を持っていないため、古い情報を自信を持って提供し、「今日の住宅ローン金利は6.7%です」と答えてしまいます。では、既存のAIモデルをリアルタイムデータで拡張する方法があったらどうでしょうか。そうすれば正しい情報を使って答えることができます。データを拡張しようとする際、住宅ローン金利が変更されるたびにベクトルストアやナレッジベースを更新できるリアルタイムパイプラインを持つこともできるでしょう。
さて、これを構築できれば、AIモデルは今日、2025年12月4日時点で、当社の30年固定住宅ローン金利は適格な借り手に対して6.25%であり、このレートは今朝更新されましたが、お客様の信用スコアと頭金によって変動する可能性があります、と答えられるようになります。このように、AIモデルに追加情報を補強することをretrieval augmented generationと呼びます。では、その利点について理解していきましょう。
RAGの利点とリアルタイムパイプラインの技術アーキテクチャ
先ほど説明したように、RAGは最新情報でプロンプトを構築または補強するのに役立ち、いくつかの利点を提供します。その一つが精度の向上で、これは先ほどお話ししたことです。二つ目はハルシネーションの削減です。AIモデルは時々、実際の情報を持っていない場合に誤った情報を提供しようとすることがあります。最新情報を提供することで、そのリスクを軽減できます。
次の利点は、ドメイン適応のための柔軟性をもたらすことができる点です。例えば、金融業界向けのユースケースを構築しようとしているとしましょう。金融業界専用に設計されたAIモデルがない場合、金融業界のデータでナレッジベースを作成することで、モデルがその金融データを使用してドメイン固有の回答を提供できるようになります。
利点を理解したところで、RAGを実装するAWSエコシステム上に構築された技術アーキテクチャを見ていきましょう。これはリファレンスアーキテクチャです。ご覧のように、ここではAmazon Bedrockを統合しています。これは完全マネージド型のサービスで、高性能なモデルの選択肢を提供し、それを使ってエージェントを構築およびデプロイできます。また、Amazon Bedrockナレッジベース、ガードレールなどの追加機能も提供しています。
Amazon OpenSearchやS3 vectorsを含むいくつかのAWSベクトルストア、さらにRedis Enterprise Cloud、MongoDBなどのいくつかの非AWSベクトルストアとのネイティブ統合を提供しています。お話しした特定のユースケースでは、Amazon Bedrockナレッジベースの背後にあるナレッジベースとしてAmazon OpenSearchまたはS3 vectorを統合していることを強調していますが、お持ちのレイテンシー要件に応じて、どちらかを選択するオプションがあります。
さて、ご覧のように、Amazon Bedrockの背後にはナレッジベースがあり、それはAmazon OpenSearch S3ベクトルです。問題は、住宅ローン金利が変更されたときに、どのようにしてそれを最新の状態に保つかということです。アーキテクチャでご覧いただけるように、ステップ1から3では、上流のアプリケーションがあります。この上流アプリケーションは、住宅ローン金利が変更されるたびにイベントを受信し、それをAmazon MSKにプッシュします。
MSKはそれをイベントとして受信し、そしてAmazon EMRで実行されているSparkストリーミングジョブがストリームコンシューマーとして機能します。それがその増分データを処理し、Bedrockからベクトル埋め込みモデルを呼び出すことでベクトルに変換し、最終的にそれらのベクトルをナレッジベースに保存します。次にステップ4でユーザークエリが来たときには、ナレッジベースが最新の情報で拡張できるようになり、モデルは正しい答えを提供できるようになります。
Model Context Protocol（MCP）によるデータレイクへのアクセス
では、ユースケースを拡張してみましょう。AIモデルがエンドユーザーに答えました、現在の住宅ローン金利は6.25%で、あなたの信用履歴と支払う頭金によって変わる可能性があります、と。さて、信用履歴はエンタープライズデータの中にあり、データレイクやデータウェアハウスに保存されているかもしれません。AIモデルがデータレイクやデータウェアハウスにアクセスできるようにするには、どうすればよいでしょうか？そこで、Model Context Protocolサーバー、つまりMCPサーバーという概念を導入します。
これらのMCPサーバーは、AIエージェントのツールとして登録され、AIエージェントはSQLクエリの実行や、データレイクやデータウェアハウスで実行されるジョブを呼び出します。レスポンスを受け取り、エンドユーザーのクエリに答えます。Model Context Protocolとは何か、そしてそのメリットは何かを理解しましょう。
Model Context Protocolは、Amazon QやKiroのようなAIアシスタントがリアルタイムデータにアクセスできるようにするために開発されたオープンソース標準です。最近、私たちはデータ分析サービス向けに多くのMCPサーバーをリリースしました。データ処理MCPサーバーも含まれています。それにはAWS Glue、Amazon EMR、そしてAmazon Athenaが含まれます。
これにはいくつかのメリットがあります。ご覧のように、3つのサービスが単一のMCPサーバーに統合されており、統合のための単一のAPIを提供します。これにより統合の複雑さが軽減され、開発が加速されます。また、データパイプラインのパフォーマンスを最適化するためのAI駆動のインサイトも提供します。さらに、データ処理サービスの可観測性とコスト追跡を簡素化する方法も提供します。
それでは、MCPの高レベルアーキテクチャを見てみましょう。ここでご覧いただけるように、エンドユーザーはMCPホストとやり取りしています。 MCPホストは、Amazon Q developer CLIやKiro CLI、クラウドデスクトップ、または皆さんが構築したカスタムエージェントなどが該当します。エージェントはクライアントを通じてMCPサーバーとやり取りしようとしています。MCPサーバーは複数存在することができます。私はデータ処理MCPサーバーについてお話ししました。
同様に、Redshiftとやり取りしようとする場合は、Redshift MCPサーバーがあります。S3テーブルとやり取りしたい場合は、S3テーブルMCPサーバーがあります。しかしそれだけでなく、他のサービスにカスタムMCPサーバーを統合する柔軟性もあります。さて、このアーキテクチャは先ほど申し上げたようにAWSアナリティクスサービスの一部をハイライトしていますが、アナリティクスサービスに限定されるものではありません。MCPサーバーを定義することで、API経由でサードパーティのモデルを呼び出すこともできます。
Amazon Q Developerによるコード自動生成とビジュアルETLのデモ
前のスライドを思い出していただくと、AI向けのデータ変換を2つのカテゴリーに分類しました。1つは、すでに企業データがあり、それをAIエージェントに公開する場合で、MCPとRAGを通じてそれをどのように行うかについてお話ししました。次に2つ目の部分ですが、データパイプライン自体を構築する際に、どのように生産性を向上させるかについて触れていきましょう。生産性を向上させる方法については多くのユースケースがありますが、時間の都合上、そのうちの2つだけに触れます。1つは単一のプロンプトを通じてコードを自動生成したりコード提案を得ること、そして2つ目はビジュアルETLでデータパイプラインを構築することです。両方を見ていきましょう。
最初にお話しした1つ目は、Amazon Q Developerによって実現されるローコード、ノーコードエクスペリエンスです。Amazon Q Developerは、ソフトウェア開発やデータ実務者が日々使用するスタジオに統合された、最も有能な生成AIアシスタントです。自然言語プロンプトでQに質問することができ、AWSサービスの機能、ベストプラクティス、技術アーキテクチャに関する回答を得ることができますし、クエリの失敗やSparkジョブの失敗のトラブルシューティングを支援することもできます。 これは、SageMaker Unified StudioのJupyter Labノートブックに統合されたQチャットアシスタントのスクリーンショットです。Radhikaがこれについてより深く掘り下げていきます。
これが私が強調した2つ目のユースケースで、データパイプラインを構築しようとしているところです。Pythonベースのdag設計を使用するオプションもありますし、インターフェース上でドラッグアンドドロップ設計を使用することもできますが、このAIチャットアシスタントはクイックスタートを提供してくれます。ここでは、これが私のソースです、これがターゲットです、そしてこれらが私が望む変換です、というプロンプトを与えると、単一のプロンプトで、自動的にETLパイプラインが生成されるのを見ることができます。では、両方のデモを見てみましょう。
最初にお見せするデモは、基本的にデータ処理MCPサーバーです。覚えていらっしゃると思いますが、これはAmazon Qチャットアシスタントのツールとして追加できることを強調しました。画面の左側は、追加するデータ処理サーバーのパラメータを指定するフォームを示しています。右側は、ノートブックを作成するためにチャットアシスタントに実際に与えるプロンプトです。デモを見てみましょう。
このデモを動作させるために、私は糖尿病データセットを参照しています。すでにそれをローカルシステムにダウンロードしており、corporateというSageMaker Unified Studioドメインをすでに作成しています。 ドメインURLをクリックすると、SageMaker Unified Studioポータルに移動します。 ポータルで、データをオンボードしたいプロジェクトを選択し、次にデータに移動します。 Addをクリックし、次にcreate tableを実行します。すでにローカルシステムにデータセットがあります。それを参照すると、CSVファイルで、自動的にCSVファイルを検出し、名前を検出して、Nextをクリックします。
データをスキャンし、自動的にスキーマを導出します。検証できるスキーマのプレビューが表示され、Create Tableをクリックします。 create tableを実行すると、カタログを更新できます。lakehouseを展開し、次にAWS Data Catalogに移動すると、sales marketingというデータベースが表示され、次に作成されたdiabetes dataテーブルが表示されます。 データのプレビューをクリックすると、Athenaクエリが実行され、10レコードのサンプルが表示されます。
データがオンボードされたことを確認したら、Buildの下のメニューをクリックして、Jupyter Lab notebookに移動できます。Jupyter Lab notebookには、Qチャットアシスタントがあり、上部にMCPサーバーを設定するオプションが表示されます。それをクリックし、次にAddアイコンをクリックすると、フォームが表示されます。前のスライドでお見せしたのを覚えていらっしゃると思いますが、ここでMCPサーバーを追加しています。 名前を指定します。最新のものをプルするコマンドと引数を指定します。Saveをクリックすると、MCPサーバーがアクティブになります。また、持っているツールのリストも表示され、検証できます。Glueデータベースであったり、Glueテーブルのリスト、または接続などです。
それを確認したら、戻ると、データ処理MCPサーバーがすでにツールとして追加されているのが確認できます。
では、これを閉じてチャットアシスタントに移動しましょう。そして、実行するために示したプロンプトをコピーしましょう。 プロンプトには、サンプルノートブックがあります、ノートブックを使用して、糖尿病データを参照し、MCPツールを使って 新しいノートブックを生成してください、と書かれています。
さて、今Qチャットアシスタントが与えられたコマンドをスキャンしています。それを複数のタスクに分解していて、 下部に、ステップバイステップで進んでいるのが見えます。まず、ノートブックを作成する必要があるため、ローカルディレクトリをリストしています。 次に、Glue接続のリストを試みます。人間の許可を求めています。実行を実行しています。その後、AWS Glueデータベースのリストを実行するよう求めてきます。 それをクリックすると、データベースがリストされます。
次に、データベース内で、糖尿病データテーブルが利用可能かどうかを見つけようとします。それを見つけたら、 ノートブックを作成する必要があるため、ローカルファイルシステムにディレクトリを作成する許可を求めてきます。今、ノートブックを作成しています。その後、README.mdファイルを作成し、 requirements.txtファイルを作成しました。すべてを作成した後、プロジェクト構造、アクティビティ、生成したコード、 などの観点から、実行した内容を要約しています。
すべてを確認したら、ローカルディレクトリに移動して、ノートブックがすでに利用可能であることを確認します。 そして、各セルを実行して出力を確認できます。では、2つ目のデモを見てみましょう。 シンプルなプロンプトを与えることで、ビジュアルETLパイプラインを自動生成できることを強調したいと思います。上部が私たちが与えるプロンプトで、下部がQチャットアシスタントに作成してもらいたいものです。デモを見てみましょう。
ビジュアルETLパイプライン自動生成の実演
さて、このデモを動作させるために、いくつかのデータセットを用意する必要がありました。すでにAmazon S3に作成されているもので、基本的には顧客行動のCSVと顧客ディメンションのCSVです。これら2つのCSVが利用可能であることを確認したら、Amazon SageMaker Unified Studioに移動します。すでにコーポレートドメインが作成されていますので、Amazon SageMaker Unified Studioポータルに移動します。事前にこのステップを実行しており、まずプロジェクトを選択し、次にビルドの下でvisual ETL jobsに移動します。
そのページに移動したら、Create Visual ETL Jobをクリックします。ここではドラッグアンドドロップインターフェースでパイプラインを作成するオプションもありますが、このプロンプトを使って生成AI機能をお見せします。このプロンプトでは、1つのデータセットを顧客行動として使用し、2つ目のデータセットを顧客ディメンションとして使用し、型変換、変更、または列名の変更によって少し変換を行い、次にこれら2つのデータセットを州で結合します。そして、2つの集計列、つまり合計購入金額と合計ページビューを作成し、最後にそれを新しいターゲットテーブルに保存します、と強調しています。
submitをクリックすると、プロンプトを分析するのに少し時間がかかり、その後自動的にノードが作成されます。各ノードをクリックして編集する柔軟性があります。さて、パイプラインが作成されました。ご覧のとおりです。説明したように、各ノードをクリックして編集、確認、更新ができます。まず、これが顧客行動のCSVであることを確認します。区切り文字としてカンマを指定し、またこのCSVにはヘッダーがあることを指定します。
さて、それができたら、利用可能なデータセットのプレビューが表示されます。このプレビューでは、ページビューと購入金額の列が文字列型になっていることに気づくでしょう。これを整数型にしたいと思います。そこで、変換用のノードをクリックします。これは具体的には列の型を変更するためのものです。ご覧のように、ソース列名、ターゲット列名を選択し、その型を指定しています。型を整数として指定しています。
では、購入金額についても同じステップを繰り返します。ご覧のように、ページビューは今データ型として整数を表示しており、購入金額フィールドについても同じステップを追加します。さて、それができたら、データセットのプレビューが表示され、購入金額も今データ型として整数を表示しています。
それでは、次のステップはこれら2つのデータセットを結合することになりますが、その前に、2つ目のデータセットを検証します。これは顧客ディメンションのCSVです。ここでも、デリミタとしてカンマを指定し、ヘッダーがあることを指定しています。そうすると、適切な列名が表示されるようになります。そして最後に、次のステップは基本的にjoinを通じてデータセットを結合することで、共通の列として顧客IDを使用しています。そして次は集計です。集計を行う際には、stateごとに集計を行い、
page viewsとpurchase amountという2つの列を作成し、sum集計関数を使用します。それができたら、追加のノードを加えるオプションもあります。例えば、これらの列をtotal page viewsやtotal purchase amountのようにリネームしたい場合は、aggregationの後にplusノードを追加して、rename column機能を探して適用すればいいのです。そして最後に、それを保存してジョブとして実行します。
それでは、ここでデモをまとめて、Radhikaに引き継ぎ、AWSデータ処理エンジンで行った機能強化について話してもらいます。Radhika、お願いします。
データ処理エンジンのAI対応強化：アイデンティティとアクセス制御の課題
ありがとうございます、Sakti。ここまで、RAGを使用してデータアーキテクチャを強化する方法と、いくつかの素晴らしいデモをご覧いただきました。私からは、プロダクトチームとして、Amazon EMR、AWS Glue、Amazon Athenaを含むデータ処理エンジンを、皆さんが独自のアプリケーションを構築できるようにAI対応にするために、どのように強化しているかについて、プロダクトの観点からお話ししたいと思います。
その前に、お客様がどのようにAIアプリケーションを構築しているかについて、簡単におさらいさせてください。ここでは、エンドユーザーが生成AIアプリケーションと対話し、通常は質問を投げかけます。アプリケーションは関連するコンテキストと会話履歴を読み込みます。さて、これが起こる前に、ユーザーが質問を投げかけると、実際にはそれに適用できるプロンプトテンプレートを読み込みます。1つのテンプレートの場合もあれば、複数のテンプレートの場合もあり、それらのテンプレートはQ&Aなのか、コード補完タスクなのか、要約タスクなのか、といったことを参照します。
これが完了すると、ユーザーがすでにこのトピックについてgenerative AIアプリと対話していた場合、すべての会話履歴が読み込まれます。会話履歴が読み込まれると、ユーザーが投げかけた質問は、ユーザープロファイルに基づいてさらに追加のコンテキストを取得するために使用されます。ユーザー自身は、好み、特定の権限、そしてユーザーが所属するプロジェクトや適用する必要がある追加のビジネスルールなど、状況に応じた他の設定を持つことができます。これらすべての状態情報は、DynamoDBなどのデータストアに保存されており、その一部はSaktiが先ほど話していたデータストアから取得されます。
会話履歴を読み込み、関連するコンテキストを取得したら、アプリケーションはこの元の質問をトークン化します。トークン化するために、例えばAmazon Titan embeddingsやOpenAI embeddingsに送信します。元の質問がトークン化されると、そのベクトル表現が導出され、S3 vectorsやOpenSearchなどのベクトルストアに送り返されます。そして、これらの元の質問のembeddingsを使って、アプリケーションはベクトルデータストアで類似性検索を実行します。これは何らかの形式の近似最近傍探索アルゴリズムを使用しています。
これを適用すると、多数の結果が返され、上位の主要な結果またはドキュメントチャンクと呼ばれるものを使用します。これらすべてのデータが利用可能になったら、元のテキストコンテンツと組み合わせ、データが統合されてプロンプトがエンジニアリングされます。これがLLMに送信される最終的なプロンプトです。LLMはそのプロンプトと、生成されたすべてのembeddingsと元のテキストコンテンツを使用して、リクエストを処理し、レスポンスを送り返します。
レスポンスは会話履歴に送り返されます。関連する他のデータストアにも送り返され、最終的にレスポンスがエンドユーザーに送信されます。
つまり、これらがAIクエリを実行する際に、舞台裏で、つまりエンドユーザーパスで発生しているすべてのステップなんですね。
それでは、舞台裏で何が起こっているのか見ていきましょう。左側に表示されているすべてのプロセスは、エンドユーザーのクリティカルパスに含まれています。さて、エンドユーザーのクエリを強化するために、舞台裏では多くのプロセスが実行されており、これらはこのようなアプリケーションを可能にするために皆さんが構築してきたデータ処理アーキテクチャです。お客様に、このようなアプリケーションを構築するために必要だと感じていることや、このようなAIアプリケーションの構築を可能にするために既存のデータアーキテクチャを強化するために必要なことについて尋ねたところ、フィールドとお客様の両方から多くのことが挙げられました。その中には、大量のデータの取り込みと処理の必要性が含まれています。
ご存知のように、AIワークロードは通常、ペタバイト規模のトレーニングデータを処理します。AIモデルはデータ品質の問題に敏感であり、また、その速度で取り込む必要のある多様なデータも必要とします。つまり、データ品質の要求があり、多様性の課題があり、速度の要件があり、そしてそれらのアイデンティティに基づいてアイデンティティとアクセス制御を適用したいということです。そして、このアイデンティティは、ユーザーID、ユーザー属性、またはグループの関連付けである可能性があります。
それに加えて、リアルタイム処理とバッチ処理について考える必要があります。これは、イベントが生成される際に重要です。AIはかなりおしゃべりです。ユーザーインタラクションのチャットが大量のデータを生成しますし、デバイスやストリームなどから生成される多くのイベントから得られるデータもあります。また、これらのアプリケーションを開発できるAI/ML環境を統合する方法も必要です。多くのデータサイエンティストは、統合されたAI/ML環境を求めており、さらに、モデルのトレーニングと推論パイプラインの要件もあります。これには、膨大な量のデータでモデルをトレーニングするための計算能力が含まれます。推論パイプラインを通じた低レイテンシーのサービング提供などが必要です。
そして最後に、構築しているツールやアプリケーションに生成AI体験を組み込みたいということもあります。お客様と話をすると、このリストから出てきたトップ3は、アイデンティティとアクセス制御、統合されたAI/ML環境、そして生成AI体験の構築です。では、これが現在お持ちの既存のアーキテクチャのコンテキストで何を意味するのか理解していきましょう。
シンプルなデータレイクを例に取りましょう。皆さんの組織は長年にわたってデータレイクを構築してきました。データサイエンティストやアナリストはS3の生データにアクセスしますが、この環境にはいくつかの課題があります。この例を見ると、3人の異なるユーザーがいます。データアナリストのAl、データサイエンティストのJoe、そしてBIグループに属するユーザーグループです。これらのユーザーは皆、基本的に異なるアプリケーションを構築しており、中央のデータガバナンスアカウントのデータにアクセスしようとしています。そのために、彼らは皆、異なるロールを使用しています。ここでの課題は、ロールが爆発的に増加することです。なぜなら、ユーザー数が増えるにつれて、そのロールに必要な権限セットに基づいて追加のロールを追加しなければならないからです。
そして、ユーザーベースが増加するにつれて、複数のロールにアクセスし、複数のアプリケーションにアクセスできるようにすることも重要になります。ここで大きな転換が起こっています。データサイエンティストのJoeは、例えばピンクのデータやグリーンのデータにアクセスするために、複数のAWSアカウントを経由して異なるロールを引き受けなければならないのです。さらに、誰がいつどのデータにアクセスしたかを証明することは非常に難しく、特に機密データの場合はなおさらです。
そのため、ここにはAI対応の障壁が存在します。データサイエンティストは、モデルを構築するためのデータの検索、アクセス、準備に80%の時間を費やしているのです。さて、この例をトランザクショナルなデータレイクやBIアプリケーションで構築しているレイクハウスに拡張すると、さらに多くの課題が出てきます。オープンテーブルフォーマットをサポートし、異なるカタログを管理できるようにする必要があります。それはGlue Data Catalogかもしれませんし、UnityやHorizonカタログのようなサードパーティのカタログにフェデレーションしたい場合もあるでしょう。
そして、さらにデータメッシュ環境に進むと、ここでも分散型の所有権シナリオがあることがわかります。フェデレーテッドガバナンスが必要で、ピアツーピアの共有ができるようにしたい、そしてこの複雑なドメイン固有の環境でユーザーへのアクセスを承認できるセルフサービスアーキテクチャを持ちたいと考えるでしょう。
そうですね、これまで見てきた既存のデータアーキテクチャのすべての課題を見ていくと、いくつかのテーマが浮かび上がってきました。それにはアイデンティティとアクセス制御が含まれます。お客様は、きめ細かなアクセス制御を備えたシームレスなシングルサインオン機能を求めており、アイデンティティベースのアクセス制御ができるようにしたいと考えています。包括的な監査機能を備えたオープンテーブルフォーマットのサポートを望んでおり、エンドユーザーのアクションを追跡できるようにしたい、そしてデータ処理アーキテクチャでのすべてのタスクを実行する際に、非常に優れた統合されたAI体験を求めています。では、これらの機能の一部を有効にするために、データ処理エンジンとどのように連携しているかを、次のスライドで見ていきましょう。
Trusted Identity PropagationとLake Formationによるきめ細かいアクセス制御
では、アイデンティティから始めましょう。数年前、私たちはTrusted Identity Propagationという機能を導入しました。これはAWS IAM Identity Centerの機能で、管理者がユーザーIDやグループの関連付けなどのユーザー属性に基づいて権限を付与できるようにするものです。OAuth 2.0プロトコル上に構築されており、既存のIAMロールにコンテキストを追加することができます。そして、埋め込まれたアイデンティティコンテキストを持つIAMロールは、ダウンストリームのアプリケーションやサービスに渡すことができ、それらはそのアイデンティティを伝播するか、または承認を行うエンドサービスである場合は、そのアイデンティティに基づいて承認を行うことができます。
それでは、これがどのように機能するかをご説明します。ユーザーのAliceがいて、彼女がユーザー向けアプリケーションに認証を行っています。これはSageMaker Unified Studioでも構いませんし、皆さんが構築したカスタムポータルでも構いません。そのカスタムポータルをIDCと統合して、ユーザーにそのカスタムポータルへの認証を行わせることができます。そして、そのカスタムポータルは、EMR、Athena、Redshift、AWS Glueといった分析エンジンと連携し、Aliceのアイデンティティをこれらの分析サービスに渡すことができます。そして分析サービスは、Aliceの認証情報を使用してデータにアクセスできるようになります。
この機能がもたらすメリットをいくつか見てみますと、企業がSSOのような体験を構築できることがわかります。データエンジニアやサイエンティストが、SageMaker Unified StudioのJupyter Lab NotebookでApache Sparkセッションにアクセスする際に、IAMロールではなく、組織や企業の認証情報を使用できるようになります。これにより、別々の認証情報が不要になり、認証ワークフローが効率化されます。ユーザーアクションのエンドツーエンドのトレーサビリティが実現され、包括的なAWS CloudTrailログが、インタラクティブなJupyter Labセッションから、EMR、Glue、Athenaで実行されているバックグラウンド処理ジョブまで、すべてのアクティビティをキャプチャします。
集中型のセキュリティ管理があり、管理者はLake Formationからきめ細かいアクセス制御を実装し、それに基づいて権限を適用できます。これらの権限は細かいレベルまで設定できます。
これにより、コンプライアンスモデルが簡素化され、特に規制された業界にいる場合は実装できます。複数のデータサイエンスチームや環境で作業したい場合や、すべてのAWSサービスへのシングルサインオンアクセスを有効にしたい場合など、これらすべてのシナリオで非常に有用です。
SageMaker Unified Studioのコンテキストでどのように機能するかをご説明します。CharlieとElleというSageMaker Unified Studioのユーザーがいます。彼らはSageMaker Unified Studioポータルにログインし、彼らの認証情報はプロジェクトロールから、例えばSageMakerトレーニングジョブに渡されます。EMRジョブでも構いません。そして、CharlieとElleの認証情報は、彼ら自身の認証情報を使用してS3バケットにアクセスしようとする際に、さらに下流に渡されます。ここで何が起こっているかというと、CharlieがSageMaker Unified Studioにログインすると、SageMaker Unified StudioはIdentity Centerとの統合を通じて、トークン、つまり彼らのジョブトークンまたは企業のアイデンティティプロバイダーから取得したトークンを使用してCharlieを認証できます。そのトークンはIdentity Centerトークンと交換され、プロジェクトロールに埋め込まれ、分析サービスに渡される際に下流に渡されていきます。
それでは、認証についてお話ししました。次に、このシナリオにおけるデータアクセス制御がどのように機能するかを見ていきましょう。繰り返しになりますが、お客様とお話しする中で、お客様がさまざまなタイプのデータアクセスを必要とする多くのユースケースを耳にしてきました。最も一般的で広く使われている最初のタイプは、S3ロケーションに対する粗粒度のアクセス制御です。粗粒度のアクセス制御を有効にするために、S3ロケーション用のS3 Access Grantsがあり、そこでSQLライクなグラントを指定できます。S3プレフィックスやバケットに対してSQLライクなグラントを定義し、それらのパーミッションを使用してSparkジョブやAthenaクエリにS3ロケーションクレデンシャルを返すことができます。
S3 Access Grantsの背後にある考え方は、シンプルなIAMポリシーやバケットポリシーが制限に達しているシナリオやユースケースにおいて、S3 Access Grantsに切り替えることでそれを克服できるということです。バケットポリシーの制限を克服し、SQLライクなグラントを使用するだけで、アプリケーションのためのユーザーからデータセットへのパーミッションマッピングを大幅に簡素化できます。
さて、これがS3 Access GrantsがSparkセッションとどのように連携するかです。これはバージョン6.15以降のすべてのEMRデプロイメント、およびバージョン5.0以降のAWS Glueで動作します。動作の仕組みは、ユーザーがSparkジョブを送信します。SparkジョブはEMRまたはGlue上で実行され、Sparkジョブが実行されると、クレデンシャルをリクエストしますが、これがS3 Access Grantsによってインターセプトされます。S3 Access Grantsは、ジョブを実行しているそのロールのパーミッションを評価し、ジョブがアクセスしようとしている特定のプレフィックスまたはロケーションのみにアクセスできるようにスコープダウンされたクレデンシャルを返します。ジョブ、つまりEMRエンジンは、実際にそれらのスコープダウンされたクレデンシャルを使用してS3内のデータにアクセスします。
さて、S3を超えて構造化データを使用したい状況があります。例えば、Glue Data Catalogに保存しているテーブルなどです。そのようなシナリオでは、Glue Data Catalog内にあるデータにSparkセッションからアクセスできるようにしたいわけです。それがSageMaker Unified Studioを通じたインタラクティブセッションであっても、あるいはバッチジョブを実行している場合でも。そのデータにアクセスでき、Lake Formationによってガバナンスされるようにしたいのです。そのようなシナリオでは、EMR 7.9でローンチしたフルテーブルアクセス機能を使用できます。この機能の背後にある考え方は、例えばデータサイエンティストが部分的なアクセスではなくフルテーブルへのパーミッションを必要とする多くのユースケースがあるということです。
データを処理する必要があり、フルテーブルを読み取ってLake Formation登録済みテーブルに書き込む必要がある自動化されたETLワークフローがある状況があります。または、ユーザーがselect、insert、updateを実行できるようにテーブルに対してフルパーミッションを単純に与えたいシンプルなパーミッションモデルが必要なアプリケーションを実行している場合です。そのようなシナリオでは、EMRやGlue上で実行されているSparkジョブからLake Formationでフルテーブルアクセスを使用できます。これは、実行しているクラスターやEMR serverlessアプリケーション上でLake Formationを有効にする必要さえないより迅速な実装です。
それでは、フルテーブルアクセスがどのように機能するかを説明します。まず管理者がLake Formationで、対象となるテーブルに対してフルテーブルパーミッションを有効にします。ユーザーがジョブを送信すると、EMRまたはAWS Glueジョブは認証情報を取得するためにLake Formationに問い合わせます。ここで重要なのは、これらのジョブは直接S3にアクセスしないということです。認証情報はLake Formationによって提供されるため、これらのジョブはLake Formationに問い合わせます。Lake FormationはそのEMRジョブのランタイムロールの認証情報を確認し、そのユーザーまたはジョブロールに必要なスコープダウンされた認証情報を発行します。その後、これらの認証情報がEMRエンジン、つまりSparkエンジンによって使用され、S3からデータを読み取り、結果をユーザーに返します。
さて、組織が保護したい機密データを持っているという、よりニッチなケースがあります。そのようなシナリオでは、きめ細かいアクセス制御を使用したいと考えるでしょう。きめ細かいアクセス制御では、テーブルに対して列レベル、行レベル、さらにはセルレベルでパーミッションを付与することができます。きめ細かいアクセス制御の背後にある考え方は、提供できるこれらのデータフィルターを通じてデータの露出を最小限に抑えることで、テーブル内の機密情報を保護できるということです。これはマルチテナント環境や、異なる機能的役割を持つ複数のテナントがアクセスしようとする状況で非常に有用です。また、厳格なガイドラインやポリシーに従うことが求められる規制産業においても、この機能は非常に役立ちます。
それでは、どのように機能するかを説明します。管理者がユーザーまたはグループにパーミッションを付与します。先ほどtrusted identity propagationについてお話ししたことを覚えていますか。Lake Formationもtrusted identity propagationと統合されているため、管理者はユーザーレベルでパーミッションを付与できます。Lake Formationでパーミッションが付与されると、同じユーザーがSparkジョブを送信したときに、EMRはユーザーのアイデンティティを含むジョブロールを取得し、認証情報を取得するためにLake Formationに問い合わせます。Lake Formationはそのユーザーのポリシーを評価し、そのユーザーまたはそのグループの関連付けに対してテーブル上のスコープダウンされた認証情報を返し、データをフィルタリングします。そしてS3に問い合わせ、データを読み取り、データをフィルタリングして、結果をエンドユーザーに返します。
つまり、きめ細かいアクセス制御のシナリオでは、一連の多くのアクティビティが発生しており、その結果、EMRクラスター上できめ細かいアクセス制御ジョブを実行する方法には厳格な要件があります。その結果、フィルタリング自体がEMRエンジン、つまりEMR Sparkエンジン上で行われるため、フィルタリングフリートまたはフィルタリング操作を実行するコンテナの領域または部分を保護する必要があります。その結果、ここにはいくつかの制限があります。フィルタリングフリートのセキュリティを侵害する可能性のあるRDDなどは許可していません。そのため、きめ細かいアクセス制御を使用する際には、いくつかの考慮事項があります。
RDDは使用できません。デバッグのサポートは限定的であり、カスタムJARやUDFもこのシナリオではサポートされていません。ですので、きめ細かいアクセス制御を使用したい場合には考慮すべき点であり、これらは将来的に対処したいと考えている制限事項の一部です。
これらは、EMRの将来のバージョンで対処したいと考えている制限事項の一部です。
SageMaker NotebooksとSpark Upgrade Agentによる生産性向上
それでは、別のトピックに移りましょう。統合されたAIとML体験でデータアーキテクチャを充実させることについてです。さて、先ほどSageMakerからいくつかのデモをご覧いただきました。それらはSageMaker Jupyter IDEで実行されていました。私たちはまた、SageMaker Notebooksもローンチしました。これは、データサイエンティスト、データアナリスト、そして数秒で始めたいサーバーレスファンの皆さんのための没入型の体験です。これは複雑なワークフローをインテリジェントに計画し実行します。タスクに最適な言語を選択する機能を持ち、ワークロードを簡単にスケールすることができます。
これが何を意味するのか、少しお話しさせてください。Jupyter IDEの体験には、企業が必要とする完全な機能セットがあります。これには、Trusted Identity Propagationを備えたIdentity Center、作業を整理できる完全なプロジェクト構造、そして他にも多数の機能が含まれています。しかし、数分で始めたいと考えるお客様も多くいらっしゃいます。そのようなお客様にとって、SageMaker Notebooksは始めるための素晴らしいツールです。データ処理インフラストラクチャを事前にプロビジョニングすることなく、すぐに始めることができます。
このノートブックは、データエンジニアやデータサイエンティストの皆さんに、SQLクエリの実行、Pythonコードの実行、大規模データジョブの処理、機械学習ワークロードの実行、そしてツール間を切り替えることなく可視化を作成する場所を提供します。これらのノートブックは、Athena Sparkによって動作しており、これはSparkバージョン3.5.6をベースにしていて、Spark Connectをサポートしています。皆さんの中には、クライアントとサーバーが分離されたSpark Connectの分離アーキテクチャにすでに精通している方もいらっしゃると思います。つまり、クライアントコードはIDE自体の中に存在することができ、クライアントは単にEMRなどのクラスター上で実行されているリモートのSparkに、あるいはEMRサーバーレスアプリケーションに対してコマンドを発行することができます。
このSpark Connectの使用により、ノートブックはエンジニアの皆さんがノートブックを非常に素早く始められるようにし、Sparkのパワーを活用して異なるセルに異なるタイプのコードを書くことができます。また、組み込みのAIエージェントも備えており、自然言語プロンプトからコードやSQL文を生成することで開発を加速させ、ユーザーをプロセス全体を通じてガイドします。従来のツールは通常、コード補完や提案機能を持っていますが、データディスカバリーを支援せず、マルチステップの計画や推論が、皆さんが目にするいくつかのツールでは欠けています。しかし、SageMaker Notebooksは、ここでご覧いただけるように、右側にエージェントがあり、これは実際にGlue Data Catalogにどのようなテーブルがあるか、ノートブックのコンテキストは何かをすでに検出しており、Pythonノートブックを実行するのに十分なコンテキストを提供することができます。
それでは、Gen AI体験でデータアーキテクチャを強化することについて少しお話しさせてください。この分野では、Spark Upgrade Agentを導入しました。これはEMR on EC2とserverlessで利用可能な新機能で、PythonとScalaのSparkジョブに対応しています。MCPベースのツールを会話型インターフェースを通じて使用し、Sparkをたとえば2.4から3.5にアップグレードします。計画からコード編集まで複数のステップがあり、実際にエラー駆動の検証ループとデータ品質ガードレールを備えており、アップグレードを完全かつ正確に行うことができます。
Spark upgrade agentのワークフローは次のように動作します。計画とオーケストレーションフェーズ、ビルドと依存関係フェーズ、コード修正フェーズ、そしてデータ品質ガードレールフェーズがあります。これをSamを通じて実際に見てみましょう。Samは重大なセキュリティ脆弱性が発見された後、本番環境のScalaベースのSparkアプリケーションをバージョン2.4から3.5に緊急にアップグレードするタスクを任されました。通常、これは完了するまでに数週間または数ヶ月かかります。agentがいかに迅速にアップグレードするかを見てみましょう。
時間の都合上、これを非常に速く進めていきます。ご覧のように、アップグレードが必要なサンプルアプリケーションを見ています。ここに表示されているのは2.4用のMavenファイルです。次に、2.4ベースのキャスティングメカニズムを持つサンプルコードを見ています。そして、agentが2.4のSparkと3.5の違いを検出し、自動的に正しいAPIを使用する様子を見ていきます。
質問をqueue agentに投稿しました。MCPを起動し、以前と同様にMCPサーバーをアクティベートするステップを実行し、質問を投げかけました。ご覧のように、アップグレードのステップを進めるための計画を非常に迅速に構築しています。ここには複数のステップがあり、依存関係のアップグレード、すべてのユニットテストと統合テストの実行、EMR on EC2での検証が含まれ、完全なアップグレードサマリーを生成します。
それが完了すると、まずMavenでのビルド設定のビルドアップデートを行うことで、それぞれのステップを実行していく様子が見えます。そのステップが完了すると、各Sparkバージョンの主要なバージョンが何であるかを表示し、さらに3.5に移行する際にどのバージョンにアップグレードされるかも表示します。ご覧のように、Mavenビルドファイルの違いをハイライトすることを含め、必要なアップグレードの全体像を表示しています。
そして、Sparkのバージョンだけでなく、基盤となる依存関係が満たされていることを確認するために、一連のステップを経ていきます。 これらの依存関係をそれぞれアップグレードする際、各依存関係には追加のステップやタスクの実行が必要になります。 例えば、Javaでは追加の引数を渡す必要があり、Javaの内部モジュールにアクセスする必要がある箇所に追加の引数が加えられていることがわかります。 つまり、不足していたコードがすべてここに追加されるわけです。
そして検証テストを実行し、ビルドまたは検証が失敗すると、 Sparkアップグレードのステップが実際にそれらのエラーを一つずつ修正していき、クリーンなビルドに到達するまで続けます。 2.4で動作するのとまったく同じように3.5でも動作するサンプルテストを実行します。このデモの詳細については、私たちのWebページやブログでご覧いただけます。他の多くのセッションでもご覧いただけます。
ただ、時間の都合上、私たちがローンチした他のいくつかの機能について簡単にまとめさせていただきます。 最速のSparkです。現在、私たちはオープンソースのApache Sparkと比較して4.4倍から4.5倍高速です。 書き込みについては、オープンソースのSparkとIcebergと比較して2倍優れています。 また、EMR Serverlessストレージプロビジョニングと呼ばれるものも導入しました。この背景にある考え方は、外部のリモートシャッフルストレージを提供することで、EMRジョブがディスクのボトルネックやディスク不足エラーを解消できるようにすることです。
私たちがローンチした機能は複数あります。これは今年ローンチしたもののほんの一部です。カタログフェデレーション、マテリアライズドビューなど、さまざまな他のトークやブログ投稿でご確認いただけます。それでは、ご来場いただきありがとうございました。これらの機能をぜひお試しいただき、フィードバックを共有していただければと思います。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用し、元動画の情報をできる限り維持しつつ自動で作成しています。
Discussion