AWS re:Invent 2024 で事前に発表したように、 Amazon Bedrock の Luma AI Ray2 動画モデル を使用して、テキストから高品質の動画クリップを生成できるようになりました。静的なコンセプトから魅力的なモーショングラフィックを作成していただけます。AWS は Luma AI のフルマネージドモデルを提供する、最初かつ唯一のクラウドプロバイダーです。 2025 年 1 月 16 日、 Luma AI は Luma Ray2 を発表しました。これは、テキストによる指示を深く理解した上で、一貫性のある自然な動きを使用してリアルなビジュアルを作成できる、大規模な動画生成モデルです。Luma Ray2 は、Luma の新しいマルチモーダルアーキテクチャでトレーニングを受けた結果、高度な機能を発揮するようになりました。Ray1 の 10 倍の計算量までスケールできるため、540p と 720p の解像度で、一貫性のある高速な動き、非常にリアルなディテール、論理的なイベントシーケンスを表示する 5 秒または 9 秒の動画クリップを作成できます。 Luma Ray2 in Amazon Bedrock を使用すると、 生成 AI アプリケーションのテキストから生成された、すぐに使える高品質でリアルな動画を、単一の API を介して追加できます。Luma Ray2 動画モデルは、人、動物、物体の相互作用を理解します。また、最先端の自然言語による指示の理解と推論を通じて、一貫性のある物理的精度が高いキャラクターを作成できます。 Ray2 動画生成は、コンテンツ制作、エンターテインメント、広告、メディアのユースケースに使用することができ、コンセプトから実行までのクリエイティブプロセスを合理化します。各シーンの意図する感情に沿った、映画のようになめらかでリアルなカメラの動きを生成できます。さまざまなカメラアングルやスタイルをすばやく試して、建築、ファッション、映画、グラフィックデザイン、音楽などのクリエイティブなアウトプットを生み出すことが可能です。 Luma が公開している Luma Ray2 の 印象的な動画生成 をご覧ください。 Amazon Bedrock での Luma Ray2 モデルの開始方法 Luma モデルを初めて使用する場合は、使用を開始する前に Amazon Bedrock コンソール にアクセスして、左下のペインで [モデルアクセス] を選択してください。最新の Luma AI モデルにアクセスするには、Luma AI で Luma Ray2 へのアクセスをリクエストしてください。 Amazon Bedrock で Luma AI モデルをテストするには、左側のメニューペインの [プレイグラウンド] で [画像/動画] を選択します。 [モデルを選択] を選択し、カテゴリとして [Luma AI] を選択し、モデルとして [Ray] を選択します。 動画生成モデルには、生成されたすべての動画を保存するための Amazon Simple Storage Service (Amazon S3) バケットが必要です。このバケットはお客様の AWS アカウントで作成され、Amazon Bedrock にはそのバケットに対する読み取りおよび書き込み許可が付与されます。 [確認] を選択してバケットを作成し、動画を生成します。 ここではプロンプト用に、720P、24フレーム/秒、アスペクト比 16:9 の 5 秒の動画を生成します。 プロンプトと生成された動画の例を次に示します。これを S3 バケットに保存してダウンロードできます。 宇宙粒子の中を泳ぐザトウクジラ Ray2 モデルでできることを示す、もう 1 つの注目の例を次に示します。 プロンプト 1: ミニチュアの子猫が人間の指先の表面を歩いたり探検したりしている プロンプト 2: 逆光に照らされた森に浮かぶ巨大な水の球 プロンプト 3: サックスを演奏する男性 (作成者: @ziguratt ) プロンプト 4: 受粉中のミツバチのマクロクローズアップ その他の例と生成された動画を確認するには、 Luma Ray2 ページをご覧ください。 また、Bedrock コンソールで [API リクエストを表示] を選択すると、 AWS コマンドラインインターフェイス (AWS CLI) や AWS SDK でコードサンプルを使用してモデルにアクセスすることもできます。 luma.ray-v2:0 をモデル ID として使用できます。 AWS CLI コマンドのサンプルを次に示します。 aws bedrock-runtime invoke-model \ --model-id luma.ray-v2:0 \ --region us-west-2 \ --body "{\"modelInput\":{\"taskType\":\"TEXT_VIDEO\",\"textToVideoParams\":{\"text\":\"a humpback whale swimming through space particles\"},\"videoGenerationConfig\":{\"seconds\":6,\"fps\":24,\"dimension\":\"1280x720\"}},\"outputDataConfig\":{\"s3OutputDataConfig\":{\"s3Uri\":\"s3://your-bucket-name\"}}}" invoke-model-output.txt Converse API サンプル を使用し、 AWS SDK を活用して動画を生成し、さまざまなプログラミング言語を使用してアプリケーションを構築できます。 今すぐご利用いただけます Luma Ray2 動画モデルは、1 月 16 日、米国西部 (オレゴン) AWS リージョン の Amazon Bedrock で一般公開されています。今後の最新情報については、 詳細なリージョンリスト をご確認ください。詳細については、 Luma AI in Amazon Bedrock 製品ページと Amazon Bedrock の料金 ページをご覧ください。 Amazon Bedrock コンソール で Luma Ray2 を今すぐお試しいただき、 AWS re:Post for Amazon Bedrock に、または AWS サポートの通常の連絡先を通じて、ぜひフィードバックをお寄せください。 – Channy 原文は こちら です。

本記事は 2025 年 1 月 10 日に公開された “ Unlocking AWS Console: Diagnosing Errors with Amazon Q Developer ” を翻訳したものです。 はじめに 開発者や IT 運用者、場合によってはサイト信頼性エンジニア（SRE）は、インフラストラクチャとアプリケーションのデプロイと運用、そしてインシデントへの効果的かつタイムリーな対応と解決を担当しています。効果的なインシデント管理には、迅速な診断、根本原因の分析、そして是正措置の実施が必要です。分散環境に複数のリソースがデプロイされている現代のシステムにおいて、根本原因の診断は困難な場合があります。生成 AI を活用したアシスタントである Amazon Q Developer は、 AWS マネジメントコンソールで表示されたエラーを診断することで、このインシデント管理のプロセスの簡素化を支援できます。 Amazon Q Developer は、AWS 環境に関連する エラーの診断 を支援することで、本番環境の問題に対処する際の貴重な時間を節約できます。これらのエラーは、複数のリソースにまたがる設定ミスが原因である可能性があり、通常、根本原因を特定するために複数の AWS サービスコンソールの画面を行き来する必要があります。Amazon Q Developer は生成 AI を使用して、 AWS コンソールで発生するエラーの診断を自動化します。これにより、修復までの平均時間（MTTR）が短縮され、ビジネス活動・事業運営へのインシデントの影響を最小限に抑えることができます。 このブログ記事では、サポートされている AWS サービスを使用する際に、 Amazon Q Developer が AWS コンソールのエラーの診断 をどのように支援できるかを紹介します。この機能の仕組みを説明し、トラブルシューティングのガイダンスを提供します。また、この機能を支える処理の裏側も見ていきます。 Amazon Q による診断 Amazon Q による診断の機能は、 現在この機能でサポートされている AWS サービス のコンソールで発生する一般的なエラーのほとんどの診断に役立ちます。この機能は、 適切な権限 を持つユーザーがエラーメッセージの横にある「 Diagnose with Amazon Q 」（Amazon Q で診断）ボタンをクリックすると有効になります。 Amazon Q は、エラーの根本原因を分析し、自然言語で説明を提供します。「 Help me resolve 」（解決を手伝って）ボタンをクリックすると、 Amazon Q はエラー状態を解決するための手順を順序立てて表示します。完了後、 Amazon Q が提供した解決策が役立ったかどうかのフィードバックを提供できます。 Amazon Q Developer が Amazon EC2 インスタンス起動エラーの診断を支援し、エラー解決のための手順のガイダンスを提供する方法を示す実行例はこちら: Amazon Q による診断：EC2 インスタンス起動エラーに関連する IAM 権限 処理の裏側：Amazon Q が診断を生成する仕組み 概念を説明するために、2つの実践的な例を用いて説明します。 例1: 空ではない Amazon S3 バケットを削除しようとした場合。以下のエラーメッセージが表示されます: This bucket is not empty. Buckets must be empty before they can be deleted. To delete all objects in the bucket, use the empty bucket configuration. （※訳者注: このバケットは空ではありません。バケットを削除するには、事前に空にする必要があります。バケット内のすべてのオブジェクトを削除するには、バケットを空にする設定を使用してください。） 例2: 特定の S3 バケット内のオブジェクトを一覧表示しようとしたが、そのための AWS Identity and Access Management (IAM) 権限がない場合。以下のエラーメッセージが表示されます: Insufficient permissions to list objects. After you or your AWS administrator has updated your permissions to allow the s3:ListBucket action, refresh the page. Learn more about Identity and access management in Amazon S3. （※訳者注: オブジェクトを一覧表示するための権限が不足しています。あなたまたは AWS 管理者が s3:ListBucket アクションを許可するように権限を更新した後、ページを更新してください。 Amazon S3 のアイデンティティとアクセス管理についての詳細はこちら。） AWS マネジメントコンソールでエラーメッセージの横にある「 Diagnose with Amazon Q 」（Amazon Q で診断）ボタンをクリックすると、 Amazon Q はエラーの根本原因を自然言語で説明する Analysis （分析結果）を生成します。このステップは 大規模言語モデル (LLM) によってサポートされています。 LLM に提供されるコンテキスト情報には、コンソールに表示されるエラーメッセージ、トリガーとなるアクションの URL、 AWS コンソールにサインインしているユーザーの IAM ロールが含まれます。この機能は、常にコンソールでの操作時に付与されたロールの権限内で動作し、付与された権限を超えて動作することはありません。 分析結果を確認した後で「 Help me resolve 」（解決を手伝って）ボタンをクリックすると、 Amazon Q はエラーが発生した AWS アカウントのリソースの状態に関する追加情報を取得します。この段階で、システムは不足している情報を能動的に判断し、情報の不足を補うために、各サービスに対して情報の取得リクエストを発行します。上記の例1のような単純なエラーでは照会は必要ありませんが、コンテキストからの情報が不十分な、より複雑なエラーを解決するためには不可欠です。 コンテキスト、エラー分析、ユーザー権限、およびアカウント内部への問い合わせ結果を考慮して、 Amazon Q はステップバイステップの Resolution （解決手順）を生成します。このステップも LLM によってサポートされています。 コンソールでエラーを解決するために Amazon Q が提供した手順を実装し検証した後、エラー解決の体験についてフィードバックを提供することができます。 ユーザー、 AWS コンソール、および Amazon Q Developer 間の相互作用を示す図 コンテキスト情報 コンテキスト情報は、 LLM がより関連性の高い、十分な情報に基づいた出力を生成するのに役立ちます。コンテキストは、コンソールから Amazon Q に入力として自動的に提供されます。コンテキストはすべての分析と判断のための基礎として、できるだけ豊富な情報であるべきです。最低限、 Amazon Q はエラーメッセージ、トリガーとなるアクションの URL、およびサインインしているユーザーが引き受けている IAM ロールを取得します。システムはコンテキストから関連する識別子を自動的に抽出します。例1では、 URL が https://s3.console.aws.amazon.com/s3/bucket/my-bucket-123456/delete?region=us-west-2 である場合、 Amazon Q は aws_region = "us-west-2" と s3_bucket_name = "my-bucket-123456" を抽出します。 この最小限のコンテキストの他にも、Amazon Q はエラーが発生した時点でユーザーが画面上で見ているもの、たとえば現在の UI のテキストフィールドやウィジェットの内容など、コンソールから追加情報を取得できます。また、基盤となるサービスが提供する特定のコンテキストも利用できます。上記の例2の場合、バケット名は URL から、アクション s3:ListBucket はエラーメッセージから抽出されます。さらに、Amazon Q は IAM から関連するポリシーや許可・拒否ステートメントに関する追加情報を取得することもあります。 サインインしているユーザーアカウントの照会 Amazon Q による診断の機能は、単にコンテキスト情報を受動的に受け取るだけではありません。能動的に追加情報を要求する機能が組み込まれています。Amazon Q は、変更を加えない読み取り専用の問い合わせクエリを実行し、AWS アカウント内のリソース、それらのリソースの状態、およびエラーが発生している特定のリソースとの関係についてのより多くのコンテキストを収集するために使用されます。この関係についてのコンテキストを LLM に提供することで、エラーの診断における根本原因分析の精度が向上します。 Amazon Q は AWS Cloud Control API (CCAPI) を使用してサインインしているユーザーアカウントを照会し、アカウントで現在プロビジョニングされているリソースを検索します。 Amazon Q を利用する際、ユーザーが引き受ける IAM ロールに AmazonQFullAccess マネージドポリシー が添付されます。このマネージドポリシーには、 CCAPI の読み取りおよびリストのエンドポイントへのアクセスを提供する cloudformation:ListResources および cloudformation:GetResource の CCAPI IAM 権限が含まれています。 AmazonQFullAccess マネージドポリシーを添付したくない場合は、 cloudformation:ListResources および cloudformation:GetResource アクションを IAM ロールに直接追加できます。 例1 は空でない S3 バケットが原因でエラーが発生する単純なケースなので、エラーメッセージとコンソール URL に必要な情報がすべて含まれており、 AWS アカウントの能動的な照会は必要ありません。一方、例2の IAM 権限エラーの場合、エラーが発生しているリソースに関連する IAM ロールの権限を理解する必要があります。 Amazon Q は、ロールのアイデンティティレベルのポリシーと影響を受けるリソースのリソースレベルのポリシーを取得でき、それに基づいて内部 IAM サービスを使用してエラーの原因を診断できます。具体的には、例2の URL は https://s3.console.aws.amazon.com/s3/buckets/my-bucket-123456?region=us-west-2&bucketType=general&tab=objects のようになり、 Amazon Q はそこからリージョンと S3 バケット名を抽出します。また、エラーメッセージ自体から s3:ListBucket アクションを抽出することもできます。この情報をもとに、 Amazon Q は my-bucket-123456 のバケットポリシーや、ロールに適用されているアイデンティティレベルのポリシーを取得し、それらをスキャンして s3:ListBucket アクションの認可・不認可を確認したり、内部 IAM サービスを呼び出してアクセスが拒否された原因に関する追加情報を取得したりできます。 Amazon Q は、サインインしているユーザーのロールによって付与された権限の範囲内でのみ動作し、権限がユーザーの IAM ロールに割り当てられているものを超えて特権が昇格されることはありません。Amazon Q は、サインインユーザーの IAM ロールによって許可された権限を使用して CCAPI を呼び出します。 CCAPI はサインインユーザーの権限を引き継ぎ、ユーザーのアカウント内のリソースを照会できるのは同じレベルのアクセス権限内に限られます。たとえば、例2ではサインインしているユーザーが my-bucket-123456 のバケットポリシーにアクセスする権限を持っていない場合、 Amazon Q もアクセスできません。そして、すべての API 呼び出しは CloudTrail に記録 されます。これには、 Amazon Q による CCAPI の呼び出しや、 CCAPI がリクエストに応じてエンドサービス（例：S3、IAM）を呼び出す処理も含まれます。 ステップバイステップの解決手順の生成 Amazon Q は収集したすべての情報を統合し、有用で実行可能な解決手順を生成します。例として、検討中の例に対する可能なサンプル手順を以下に示します。モデルは時間とともに更新・改善されるため、応答は変更される可能性があります。 例1の場合のサンプル手順: S3 コンソールに移動し、「バケット」をクリックして、 my-bucket-123456 バケットを選択します 「空にする」ボタンをクリックします バケットに大量のオブジェクトが含まれている場合、ライフサイクルルールを作成してバケット内のすべて オブジェクトを削除する方が、より効率的な方法かもしれません テキスト入力フィールドに「完全に削除」と入力し、すべてのオブジェクトを削除することを確認します my-bucket-123456 S3 バケットの削除を再試行します 例2の場合のサンプル手順: IAM コンソールに移動します。 ReadOnly ロールに添付されている IAM ポリシーを編集します S3 バケット ARN arn:aws:s3:::my-bucket-123456 に対して s3:ListBucket アクションを許可します 更新された IAM ポリシーを保存します S3 コンソールページを更新して、バケット my-bucket-123456 内のオブジェクトを一覧表示します 手順には、プレースホルダーの代わりに、バケット名 my-bucket-123456 のようなコンテキストから推測された情報が含まれていることに注意してください。 Amazon Q による診断で返される手順は、追加の労力なしに実行できるよう、完全かつ詳細に記述されています。実際、このサービスは LLM を使用して解決手順を生成しますが、Amazon Q は後処理を行い、よくある誤りを修正します。例えば、上記の例 2 では、LLM が arn:aws:s3:<region>::<bucket_name> という形式で ARN を返した場合、それを適切な形式へ修正します。 上記の例2で返される手順は、ユーザーがオブジェクトを一覧表示できない原因が、 ReadOnly ロールにアタッチされているポリシーに Allow ステートメントがないことであると仮定しています。その他の根本原因として、 S3 バケットや ReadOnly ロールに添付されているポリシーの Deny ステートメントなどが考えられます。 Amazon Q による診断では、アカウントの照会を使用して正しい根本原因を特定し、適切な解決策を提案できます。上記の例では、 ReadOnly ロールにアタッチされているポリシーを取得して s3:ListBucket が実際に欠けているかどうかを確認したり、バケット bucket-123456 にアタッチされているポリシーを取得したりできます。 検証 Amazon Q による診断の目標の1つは、エラーが発生した場所で有用かつ実行可能なアドバイスを得られるよう、高い品質基準を維持することです。この目標を達成するためには、堅牢で柔軟な評価システムが重要な前提条件となります。生成 AI に基づくシステムの評価は、出力が自然言語であることによる広大な表現の可能性や、非決定的な動作といった特徴があるため、特有の課題があります。 簡単に言えば、私たちの検証システムは、各レコードが一定数のアノテーションを持つ大規模なエラーデータセットの構築に基づいています。各レコードには、テンプレート化されたエラーメッセージとコンソール URL（例えば、 bucket-123456 は {{s3_bucket_name}} に、 us-west-2 は {{aws_region}} に置き換えられたもの）が含まれています。アノテーションには、エラーのあるアカウントの状態とトリガーとなるアクションを記述した Infrastructure as Code（CloudFormation）の定義、および専門家による正解の応答データが含まれます。これらのレコードを活用することで、人間の介入なしに、システムのさまざまなバージョンの動作をシミュレーションでき、並列処理によってリアルタイムよりもはるかに高速に実行できます。また、Ground truth アノテーションとシステムの応答を比較する自動評価指標の開発も進めており、これに基づいて完全自動のオフライン評価を実施できるよう取り組んでいます。 この検証システムにより、新しいアイディアを現在の状態と比較しながら迅速に検証でき、さらに機能の低下も防ぐことができます。エラーレコードのアノテーションを入力するために専門家はまだ必要ですが、私たちはこの作業の効率化と簡素化を積極的に進めています。そのために、自然言語の手入力を避け、検証機能を組み込み、専門家が一から正解のアノテーションを入力するのではなくシステム出力を修正する形でアノテーションツールを構築しています。 まとめ Amazon Q Developer の「Amazon Q による診断機能」を使用すると、複数のサービスコンソール間を移動することなく、AWS コンソールでのエラーの原因を特定できます。AWS アカウントとエラーコンテキストに特化したきめ細かなステップバイステップの手順を提供することで、Amazon Q Developer は効率的なトラブルシューティングと問題解決を支援します。これにより、組織の運用効率の向上、ダウンタイムの削減、サービス品質の改善が実現し、貴重な人的リソースを解放して、より価値の高い活動に集中できるようになります。また、この機能を実現するために AI と機械学習の機能によって処理の裏側がどのように機能しているかについての詳細についてもご紹介しました。 翻訳はApp Dev Consultantの宇賀神が担当しました。 著者について Matthias Seeger Matthias Seeger は AWS の Principal Applied Scientist です。彼は確率モデルを用いたベイズ学習と意思決定、ガウス過程モデルの理論と実践、確率的予測、そして最近では大規模言語モデルと関連するデータ作成およびアノテーションの課題に関心を持っています。 Marco Frattallone Marco Frattallone は、パートナー支援に重点を置く AWS の Senior Technical Account Manager です。パートナーと緊密に協力し、 AWS 上でのソリューションの構築、デプロイ、最適化を支援し、ガイダンスを提供してベストプラクティスを活用しています。 Marco はテクノロジーに情熱を持ち、パートナーがイノベーションの最前線に立ち続けるよう支援しています。仕事以外では、アウトドアサイクリング、セーリング、新しい文化の探索を楽しんでいます。 Surabhi Tandon Surabhi Tandon は Amazon Web Services (AWS) の Senior Technical Account Manager です。戦略的な技術ガイダンスを提供することで、エンタープライズのお客様の運用の優れた実践の達成と AWS でのクラウドジャーニーを支援しています。 Surabhi は生成 AI 、自動化、 DevOps に関心を持つビルダーです。仕事以外では、ハイキング、読書、家族や友人との時間を楽しんでいます。

本記事は 2025 年 1 月 14 日に公開された AWS CDK is splitting Construct Library and CLI を翻訳したものです。翻訳は Solutions Architect の山崎 宏紀が担当しました。 AWS CDK は、クラウドインフラストラクチャをコードで定義し、 AWS CloudFormation を通じてプロビジョニングするためのオープンソースのソフトウェア開発フレームワークです。AWS CDK は主に 2 つのコンポーネントで構成されています。AWS CDK CLI と、AWS アプリケーションをモデル化するためにプログラミング言語から使用する CDK コンストラクトライブラリです。CDK コンストラクトライブラリはアプリケーションのモデルをローカルのディレクトリに「合成」し、AWS CDK CLI はそのディレクトリのファイルを読み取って AWS にアプリケーションをデプロイします。 2025 年 2 月より、AWS CDK CLI と CDK コンストラクトライブラリは同時リリースではなくなります。代わりに、それぞれが独自のリリースサイクルを持つようになり、バージョン番号も異なるものとなります。AWS CDK で利用する API やユーザーエクスペリエンスへの影響はありません。 これは AWS CDK の動作方法や AWS CDK の使用方法を根本的に変更するものではありません。最新バージョンの AWS CDK CLI は、それ以前の過去にリリースされたすべてのバージョンの CDK コンストラクトライブラリをサポートし続けます。ユーザーは引き続きいつでも自由に AWS CDK CLI を最新バージョンにアップグレードすることができます。この変更による最大の違いは AWS CDK CLI と関連コンポーネントのソースコードが新しい GitHub リポジトリに移行されることです。新しいリポジトリは https://github.com/aws/aws-cdk-cli (訳註: 2025-02-03 時点ではアクセス不可) となり、移行完了後に一般公開される予定です。 新しいバージョニング体系での AWS CDK CLI の最初の新バージョンは 2.1000.0 としてリリースされ、次のバージョンは 2.1001.0 に続きます。CDK コンストラクトライブラリは現在のバージョニング体系を継続し、 2.174.0 , 2.175.0 , 2.176.0 というように順次リリースされます。 変更の理由 AWS CDK CLI と CDK コンストラクトライブラリは元々別個のコンポーネントでした。これらは歴史的に同じリポジトリに配置されていましたが、これは私たちが迅速に反復開発を行うために役立ちました。AWS CDK が成熟するにつれて、異なるコンポーネントへの変更は異なるサイクルで進み、異なるテスト戦略が必要であることがわかりました。この変更により一方のサブプロジェクトのリリースサイクルを他方に影響を与えることなく変更できるようになり、プロジェクト全体により高い俊敏性をもたらすことができます。 AWS CDK CLI の基本的な互換性モデルは変わりません。AWS CDK CLI はそれと同時期またはそれ以前にリリースされたすべての CDK コンストラクトライブラリの出力を処理できます。これまでは CLI version >= Lib version が常に有効なバージョンの組合せであるというルールとして表現されていました。バージョンが同時にリリースされなくなるため、新しいルールは CLI release date >= Lib release date となります。バージョン番号だけでは一目でこの関係を把握することは難しくなりますが、CDK コンストラクトライブラリが必要とする最小限の AWS CDK CLI バージョンが cdk.out マニフェストに含まれます。エラーメッセージには必要なバージョンを表示し、各バージョンの互換性情報を GitHub に公開します。 バージョンの連続性の区切りを示すため、AWS CDK CLI のバージョン番号に大きな明確な区切りを設けます。 2.174.0 の後、AWS CDK CLI のバージョンは 2.1000.0 にスキップし、その後 2.1001.0 に進みます。これによりメジャーバージョン番号を変更することなく、AWS CDK CLI と CDK コンストラクトライブラリのバージョニング体系の関連性が途切れていることが明確になることを期待しています。 CDK コンストラクトライブラリは、 2.175.0 、 2.176.0 などのように、現在のバージョニング体系でリリースを継続します。 変更しない項目について メジャーバージョン番号は変更しません: バージョンの連続性が途切れていることを示す目的で AWS CDK CLI 3.x をリリースすることはありません。その理由は以下の 2 つです: ほとんどのお客様のプロジェクトには、 "aws-cdk": "^2.174.0" のような依存関係の範囲が設定されています。メジャーバージョン番号を 3.x に変更すると、これらのプロジェクトは AWS CDK CLI の更新を自動的に取り込まなくなり、次のスキーマ変更時に AWS CDK CLI の互換性エラーが発生することになります。メジャーバージョン 2 のままであれば新しいリリースは指定された依存関係の範囲に引き続き一致し、自動的にインストールされます。 この変更は "CDKv3" リリースを意味するものではないため、そのように解釈される可能性を避けるために AWS CDK CLI のメジャーバージョンを 3 に変更しません。これは AWS CDK CLI のメジャーバージョン番号を決して上げないという約束ではありません。将来、変更する正当な理由がある場合は結果的に変更する可能性があります。その場合は影響を最小限に抑える方法で実施します。少なくとも将来の AWS CDK CLI v3 は非推奨でない CDK コンストラクトライブラリの 2.x バージョンとの互換性を維持します。 issue を報告する場所は変更されません： AWS CDK CLI のコードは別のリポジトリに移動し、プルリクエストは別のリポジトリに対して行う必要がありますが、AWS CDK に関する問題は引き続きメインの aws/aws-cdk リポジトリに報告することができます。AWS CDK フレームワーク全体に関する問題を、その問題がどのコンポーネントから発生したかに関係なく 1 つの場所で簡単に報告できるようにしたいと考えています。AWS CDK チームは、すべてのリポジトリにわたって issue を監視し、必要に応じて issue を別のリポジトリに移動します。これは、jsii のような他の AWS CDK コンポーネントで採用している運用手順と同じです。 互換性モデルは変更されません: 互換性モデルに変更はありません。AWS CDK CLI はそれ以前の過去ににリリースされた非推奨でないバージョンの CDK コンストラクトライブラリによって生成されたすべての cdk.out ディレクトリを常に読み取ることができます。互換性を確保するために、CDK コンストラクトライブラリのバージョンをアップグレードする頻度と同じかそれ以上の頻度で npm upgrade を使用して AWS CDK CLI バージョンをアップグレードすることをお勧めします。 互換性を確保するために使用できるいくつかの有用なヒントを紹介します。従うべき簡単なルールは CLI release date >= Lib release date であれば確実に動作するということです。より複雑ではありますが、やはりライブラリリリース前の最新の AWS CDK CLI リリースは確実に動作し、それ以降のバージョンも同様に動作します。 cdk.out ディレクトリ内のファイル形式に変更がない場合、古いバージョンでも動作する可能性がありますが、その互換性は保証されません。 お客様への影響について AWS CDK ユーザーの皆様へ ： AWS CDK CLI と CDK コンストラクトライブラリのバージョンが異なることにお気づきになると思います。AWS CDK の日常的な使用経験に最も影響を与えるのは CDK コンストラクトライブラリのバージョンであるため、これを「AWS CDK のバージョン」として考えることをお勧めします。また、使用している CDK コンストラクトライブラリのバージョンをサポートする AWS CDK CLI バージョンを常に使用するために、AWS CDK CLI は最新バージョンに保つことをお勧めします。CDK コンストラクトライブラリと AWS CDK CLI の両方を単一の「AWS CDK バージョン」でインストールすることを前提としたスクリプトは書き直す必要があります。 # このスクリプトは今後正常に動作しません。aws-cdk と aws-cdk-lib は異なるバージョンを持つ場合があります。 $ CDK_VERSION=2.714.0 $ npm install aws-cdk-lib@$CDK_VERSION $ npm install aws-cdk@$CDK_VERSION # Do this instead (install the latest 2.x) $ npm install aws-cdk@^2 AWS CDK コントリビューターの方へ： AWS CDK CLI 関連の issue は引き続き aws-cdk リポジトリ に報告してください。ただし、プルリクエストは新しいリポジトリに対して行う必要があります。AWS CDK CLI と CDK コンストラクトライブラリの両方に関わる変更は両方のリポジトリに対して送り、個別にマージする必要があります。コンストラクトライブラリの PR をマージする前に AWS CDK CLI の変更をリリースする必要があります。具体的なワークフローについては、新しい https://github.com/aws/aws-cdk-cli リポジトリに記載されます。 まとめ この変更により AWS CDK をより速いペースで改善できるようになることを嬉しく思います。お客様側での準備やスクリプトの更新が必要になる可能性はありますが、ユーザーへの影響は最小限に抑えられると考えています。ご質問がある場合や、この変更に関する議論に参加したい場合は GitHub の該当 Issue をご覧いただくか、 AWS Support または Slack を通じて直接お問い合わせください。

1 月 20 日週以降、AWS から 40 件ほどの新規リリースがありました。リリースは通常のリズムに戻りました。サービスチームはお客様のフィードバックに耳を傾け、当社のサービスを使用する際のお客様の作業を容易にする小さな (または大きな) 変更を開発しています。AWS コンソールで複数のセッションをサポートする機能は、2025 年に入ってからのこれまでのところ、私のお気に入りです。 しかし、私たちのチームはそこで止まりませんでした。先週の新しいお知らせを見てみましょう。 1 月 20 日週のリリース 通常のリージョンレベルの拡張 (新しいリージョンで使用できるようになった新機能) の他に、私が注目したリリースをご紹介します。 Amazon EventBridge がクロスアカウントターゲットへの直接配信を発表 – Amazon EventBridge は、イベントをターゲットアカウントのデフォルトバスに最初に送信することなく、別の AWS アカウントのターゲットに直接配信できるようになりました。これにより、とても多くのアーキテクチャが簡素化されます! これは、 AWS Lambda 、 Amazon Simple Queue Service (Amazon SQS)、 Amazon Simple Notification Service (Amazon SNS)、 Amazon Kinesis 、 Amazon API Gateway など、 リソースベースのポリシー をサポートするすべてのターゲットをサポートします。 Amazon Corretto の四半期ごとの更新 – Amazon Corretto の長期サポート (LTS) および OpenJDK の機能リリース (FR) バージョンの四半期ごとのセキュリティおよび重要な更新を発表しました。Corretto 23.0.2、21.0.6、17.0.14、11.0.26、8u442 がダウンロードできるようになりました。Amazon Corretto は、OpenJDK の無料かつマルチプラットフォームの本番対応ディストリビューションです。更新は、 Corretto ホームページ からダウンロードできるほか、 apt-get または yum update と入力するだけでもダウンロードできます。 Amazon SNS FIFO トピック向けの高スループットモード – Amazon SNS は、SNS FIFO トピック向けの高スループットモードをサポートするようになりました。デフォルトのスループットは、すべてのリージョンの SNS 標準トピックと一致します。高スループットモードを有効にすると、SNS FIFO トピックはメッセージグループ内の順序を維持し、重複排除の範囲を メッセージグループレベル に縮小します。この変更により、米国東部 (バージニア北部) リージョンではデフォルトでアカウントあたり最大 30K メッセージ/秒 (MPS)、米国西部 (オレゴン) および欧州 (アイルランド) リージョンではアカウントあたり最大 9K MPS を活用でき、どのリージョンでも追加のスループットのためにクォータの引き上げをリクエストできます。 Amazon Connect エージェントワークスペースが、Citrix および Amazon WorkSpaces 仮想デスクトップの音声最適化のサポートを開始 – Amazon Connect エージェントワークスペースが、Citrix および Amazon WorkSpaces 仮想デスクトップインフラストラクチャ (VDI) 環境からカスタマーサービスエージェントのローカルデバイスに音声をリダイレクトする機能をサポートするようになりました。音声リダイレクトにより、仮想デスクトップで処理される音声通話の音声の質が改善され、レイテンシーが低減されるため、エンドカスタマーとエージェントの両方に優れたエクスペリエンスが提供されます。 Amazon Redshift がゼロ ETL 統合の履歴モードのサポートを発表 – この新しい機能により、コードを記述することなく、データベースの履歴データに基づいて Type 2 Slowly Changing Dimension (SCD 2) テーブルを Amazon Redshift ですぐに構築できます。履歴モードにより、履歴データの変更を追跡および分析するプロセスが簡素化され、時間の経過に伴うデータの進化から有益なインサイトを得ることができます。 最後に、 Amazon Bedrock からも一連のお知らせがあります。まず、 検索拡張生成 に投資しているお客様のために、Bedrock は Cohere Embed 3 Multilingual および Embed 3 English モデルを使用してマルチモーダルコンテンツをサポートするようになりました。これにより、埋め込みを作成して、テキストだけでなく画像もインデックス化できます。 次に、「 Luma AI’s Ray2 visual AI model now available in Amazon Bedrock 」をお読みください。Luma Ray2 は、滑らか、かつ、自然な動きでリアルなビジュアルを作成できる大規模な動画生成モデルです。Amazon Bedrock の Luma Ray2 を使用すると、シームレスなアニメーション、超リアルなディテール、自然言語プロンプトによる論理的なイベントシーケンスを含む、本番対応の動画クリップを生成できるため、技術的なプロンプトエンジニアリングが不要になります。Ray2 は現在、540p および 720p の解像度で 5 秒と 9 秒の動画生成をサポートしています。 そして最後に、 Amazon Bedrock Flows がマルチターン会話サポートのプレビューを発表しました 。 Amazon Bedrock Flows を使用すると、基盤モデル (FM)、 Amazon Bedrock Prompts 、 Amazon Bedrock エージェント 、 Amazon Bedrock ナレッジベース 、 Amazon Bedrock ガードレール 、および他の AWS サービスをリンクして、事前定義済みの生成 AI ワークフローを構築およびスケールできます。今週、チームは Flows のエージェントノード向けのマルチターン会話サポートのプレビューを発表しました。この機能により、自然な対話と同様に、ユーザーとフローの間で動的な会話が可能になります。 AWS からの発表の完全なリストについては、「AWS の最新情報」ページをご覧ください。 その他の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit のシーズンが始まります! 私は既に現地のチームと協力して、パリとロンドンの Summit のコンテンツを準備しています。Summit は、クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントです。公式 AWS Summit ウェブサイト にアクセスして最新情報を入手し、お住まいの地域内で開催されるイベントの登録開始時期を知るために通知にサインアップしましょう。 コラボレーションスペースで、没入型エクスペリエンスでもある AWS GenAI Lofts  は、クラウドコンピューティングと AI に関する AWS の専門知識を紹介し、AI 製品やサービスへのハンズオンアクセス、業界リーダーとの特別セッション、投資家や同業他社との貴重なネットワーキングの機会をスタートアップやデベロッパーに提供します。  お近くの GenAI Loft 開催地を見つけて 、忘れずに登録しましょう。 近日開催予定のすべての AWS 主導の対面およびバーチャルイベントは、こちら でご覧ください。 1 月 20 日週のニュースは以上です。1 月 27 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! — seb この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

本記事は 2024/03/19に投稿された Simplify private connectivity to Amazon DynamoDB with AWS PrivateLink を翻訳した記事です。翻訳は Solutions Architect 嶋田朱里が担当しました。 Amazon DynamoDB は、サーバーレス、NoSQL、完全マネージド型のデータベースで、あらゆるスケールでミリ秒単位のパフォーマンスを実現します。マルチリージョン、マルチアクティブ、高耐久性のデータベースで、組み込みのセキュリティ、バックアップ/リストア、メモリキャッシングを備えています。 お客様は VPC またはオンプレミスで実行されるワークロードから ゲートウェイエンドポイント を使用して DynamoDB にアクセスできます。オンプレミスのプライベートネットワークからゲートウェイエンドポイントに接続する場合、多くのお客様はプロキシサーバーまたはファイアウォールルールを設定して DynamoDB へのトラフィックをルーティングおよび制限しています。これはゲートウェイエンドポイントが AWS Direct Connect または AWS Virtual Private Network (AWS VPN) と互換性がないためです。この追加のインフラストラクチャ設定は運用負荷とコンプライアンスを複雑化させる可能性があります。お客様からは、追加のプロキシインフラストラクチャを必要とせずに、オンプレミスワークロードから DynamoDB にプライベートネットワーク接続を設定できるソリューションが求められていました。 私たちは DynamoDB 向けの AWS PrivateLink サポート を発表できることを喜ばしく思います。PrivateLink を使用すると、 インターフェイス VPC エンドポイント とプライベート IP アドレスを使って、オンプレミスのワークロードから DynamoDB へのプライベートネットワーク接続を簡素化できます。インターフェイスエンドポイントは、Direct Connect と AWS VPN に対応しており、エンドツーエンドのプライベートネットワーク接続が可能です。その結果、公開 IP アドレス、プロキシインフラ、ファイアウォールルールを必要とせずオンプレミスから DynamoDB にアクセスすることができ、コンプライアンスを維持できます。VPC 内のネットワークトラフィックにはゲートウェイエンドポイントを、オンプレミスのネットワークトラフィックにはインターフェイスエンドポイントを使用することで、DynamoDB への低コストのプライベートネットワーク接続を実現できます。 この投稿では、オンプレミス環境をエミュレートして、PrivateLink を使用したインターフェイス VPC エンドポイントをDynamoDB で利用する例を示します。PrivateLink でインターフェイスエンドポイントを使用する他の例については、 ユースケース例 を参照してください。 プライベート IP アドレスを使用した、オンプレミスから DynamoDB へのアクセス この投稿では、保険会社が、オンプレミスのメインフレームシステムに保存されているリスクスコアを再評価するために、DynamoDB に保存されている見積もりと請求データにアクセスする必要があるという想定で説明します。 オンプレミスのワークロードは、 AWS Client VPN を通じて us-west-1 リージョンの VPC に接続するローカルマシンで、PrivateLink のインターフェイスエンドポイントを使用して、プライベート IP アドレスで DynamoDB にアクセスします。次の図は、このアーキテクチャを示しています。 このソリューションには、以下の主要コンポーネントが含まれています。 AWS Client VPN エンドポイントが VPC に関連付けられている OpenVPN ベースの AWS Client VPN がローカルマシンに設定されている。AWS Client VPN エンドポイントを使用して VPC に接続できる DynamoDB 用 PrivateLink のインターフェイス VPC エンドポイントが作成され、VPC のサブネットに関連付けられている ローカルマシン上で実行されているオンプレミスアプリケーションは、インターフェイス VPC エンドポイントを使用して DynamoDB テーブルにプライベートにアクセスできる 次のセクションでは、この設定を構成し、新しい PrivateLink のインターフェイス VPC エンドポイントを作成します。 前提条件 始めるにあたり、以下のようにネットワークを設定していることを確認してください: ローカルマシンの AWS クライアント VPN で設定したリージョンに VPC があること インターフェイスエンドポイントのセキュリティグループが、オンプレミス環境と同じか、オンプレミス環境 (AWS Client VPN エンドポイント) からのトラフィックを受信するためのインバウンドルールが含まれている AWS Client VPN を使用する場合、AWS Client VPN エンドポイントの承認ルールが、インターフェイスエンドポイントが関連付けられているサブネットの CIDR ブロックへのトラフィックを許可している オプションで、ローカルマシンに Python3 と AWS SDK for Python (Boto3) がインストールされている ソリューションの設定 以下の手順で、us-west-1 リージョンの VPC 内に DynamoDB 用 PrivateLink のインターフェイス VPC エンドポイントを作成します。 Amazon VPC に移動し、ナビゲーションペインから Endpoints を選択します。 Create endpoint を選択します。 Name tag には、任意のタグを入力します。 Service category は AWS services を選択します。 DynamoDB のインターフェイスタイプのエンドポイントを検索して選択します。これは DynamoDB 用 PrivateLink の VPC エンドポイントです。 インターフェイスエンドポイントは VPC に関連付けられているため、対象の VPC、インターフェイスエンドポイントを関連付けたいサブネット、設定したいセキュリティグループを選択します。 インターフェイス VPC エンドポイントを使用して DynamoDB と接続する AWS Identity and Access Management (IAM) エンティティに対して、許可される DynamoDB アクションを制限するために、VPC エンドポイントポリシーを指定します。この記事では、 Full access を選択します。 最小特権のアクセス原則 に基づいて、このポリシー内のアクセスを絞り込むことをお勧めします。 Create endpoint を選択します。 エンドポイントの作成には数分かかる場合があります。 インターフェイス VPC エンドポイントが正常に作成されると、VPC 固有の複数の DNS 名が表示されます。DNS 名には、リージョナルエンドポイントである単一のエントリと、設定したサブネットが属する各アベイラビリティーゾーンに付与されるゾーナルエントリが含まれています。 VPC に接続されたローカルマシン上のアプリケーションからアクセスするために、リージョナル DNS 名をコピーします。 Boto3 SDK の DynamoDB クライアントを初期化する際、適切な region_name とともに、 endpoint_url にコピーしたリージョナル DNS 名を渡します。これは AWS SDK によって異なる場合があります。 import boto3 ddb_client = boto3.client( "dynamodb", region_name="us-west-1", endpoint_url="https://vpce-xxxx-yyyy.dynamodb.us-west-1.vpce.amazonaws.com", ) response = ddb_client.get_item( TableName="plays", Key={"pk": {"S": "64.0"}, "sk": {"S": "2014-01-02T09:44:24Z"}}, ) print(response["Item"]) Output: {'sk': {'S': '2014-01-02T09:44:24Z'}, 'data': {'S': '208356596'}, 'pk': {'S': '64.0'}, 'type': {'S': 'sample'}} リージョン間の DynamoDB アクセス (プライベート IP アドレスを使用) オンプレミスから AWS Client VPN を使用して VPC にアクセスするシナリオと同様に、PrivateLink のインターフェイス VPC エンドポイントを使用して、プライベート IP アドレスを介して別リージョンの DynamoDB リソースにプライベートにアクセスすることができます。これには 2 つの VPC をピアリングし、ルートテーブルを適切に更新する必要があります。このアーキテクチャを以下に示します。 この場合、us-east-1 リージョンに VPC ベースの AWS Lambda アプリケーションがあり、PrivateLink のインターフェイス VPC エンドポイントを使用して us-west-1 リージョンの DynamoDB テーブルにアクセスできます。Lambda 関数は、PrivateLink のインターフェイス VPC エンドポイントを使用して、リージョン間の DynamoDB リソースにアクセスできます。 プライベート IP アドレスを使用したリソースへのアクセス インターフェイスエンドポイントの主な利点は、関連付けられた VPC の特定のサブネット内のプライベート IP アドレスに解決されることです。たとえば、VPC の CIDR 範囲が 172.31.0.0/16 で 2 つのサブネットがある場合、インターフェイスエンドポイントはこの範囲内の IP アドレスに解決されるため、エンドポイントに関連付けられた各サブネットに少なくとも 1 つの IP アドレスが割り当てられます。次のコードを参照してください。 $ dig vpce-xxxx-yyyy.dynamodb.us-west-1.vpce.amazonaws.com ; <> DiG 9.10.6 <> vpce-xxxx-yyyy.dynamodb.us-west-1.vpce.amazonaws.com ... ;; QUESTION SECTION: ; vpce-xxxx-yyyy.dynamodb.us-west-1.vpce.amazonaws.com. IN A ;; ANSWER SECTION: vpce-xxxx-yyyy.dynamodb.us-west-1.vpce.amazonaws.com. 60 IN A 172.31.8.44 vpce-xxxx-yyyy.dynamodb.us-west-1.vpce.amazonaws.com. 60 IN A 172.31.16.71 DNS 名は公開されていますが、VPC のサブネットに属するプライベート IP アドレスに解決されるため、インターフェイスエンドポイントから DynamoDB にインターネット経由で接続することはできません。エンドツーエンドでプライベートアクセスが提供されます。オンプレミスの設定では、 AWS Direct Connect または AWS Client VPN を使用して VPC にルーティングされるトラフィックは、シームレスにインターフェイスエンドポイントにルーティングできるように構成できます。 オンプレミスネットワーク オンプレミスのアプリケーションで DynamoDB のインターフェイスエンドポイントを設定するには、Direct Connect または VPN ソリューションを使用して VPC との接続を確立する必要があります。さらに、インターフェイスエンドポイントが関連付けられている VPC の CIDR へのルートが設定されていることを確認してください。また、オンプレミスネットワークの CIDR からのインバウンドルールを含むように、インターフェイスエンドポイントのセキュリティグループを設定します。最後に、DynamoDB のパブリック DNS ドメイン内で解決可能なインターフェイスエンドポイントの DNS 名を解決するために、オンプレミスで DNS 設定が実装されていることを確認してください。ネットワークから VPC への接続に関する詳細は、 Network-to-Amazon VPC connectivity options を参照してください。 次の図は、PrivateLink のインターフェイス VPC エンドポイントが、オンプレミスのアプリケーションと AWS Cloud 内の DynamoDB テーブルとの接続を容易にする方法を示しています。このセットアップには、VPC 内のトラフィックをルーティングするためのゲートウェイエンドポイントも組み込まれています。 考慮事項 PrivateLink のインターフェイスエンドポイントを使用する際は、以下の点に注意してください。 DynamoDB のゲートウェイエンドポイントとインターフェイスエンドポイントのどちらを選択しても、ネットワークトラフィックは両方のシナリオで AWS ネットワーク内に留まります。単一の VPC 内、または VPC 間の通信にはゲートウェイエンドポイントの使用を推奨しますが、オンプレミスのデータセンターからの通信にはインターフェイスエンドポイントを使用することをお勧めします。現時点では、インターフェイスエンドポイントは IPv4 アドレスのみをサポートしています。 PrivateLink は、エンドポイントごとにアベイラビリティーゾーンあたり最大 100Gbps をサポートします。オンプレミスのデータセンターから DynamoDB インターフェイスエンドポイントへの 1 秒あたりのデータ転送量が AZ あたり 100Gbps を超える場合は、予想されるデータ転送要件に対応するために追加のインターフェイスエンドポイントを構成できます。 DynamoDB のゲートウェイ VPC エンドポイントの使用に関連するデータ処理料金や時間料金はありません。ただし、PrivateLink を使用したインターフェイスエンドポイントの場合は標準料金が適用されます。詳細については、 AWS PrivateLink 料金 を参照してください。 クリーンアップ このポストの一環で作成した AWS リソースを削除してください。 AWS Client VPN エンドポイント 、 インターフェイス VPC エンドポイント 、 Lambda 関数 、およびその他のリソースを削除してください。 結論 DynamoDB 用の PrivateLink を使用すると、オンプレミスのデータセンターまたは VPC 内の プライベート IP アドレスから DynamoDB への接続を確立することができ、ネットワークアーキテクチャを簡素化できます。PrivateLink では、オンプレミスの場所から DynamoDB にアクセスするために、パブリック IP アドレスの設定、ファイアウォールルールの設定、インターネットゲートウェイの設定が不要になります。この新機能は、すべての AWS 商用リージョン でご利用いただけます。 DynamoDB 用の PrivateLink バックエンドのインターフェイス VPC エンドポイントを使用し、コメントセクションでフィードバックを共有してください。 著者について Aman Dhingra はアイルランドのダブリンを拠点とする DynamoDB 専門のソリューションアーキテクトです。分散システムに情熱を持ち、ビッグデータ & 分析技術の経験があります。DynamoDB 専門のソリューションアーキテクトとして、DynamoDB をバックエンドとするワークロードの設計、評価、最適化をサポートしています。 Ashwin Venkatesh は、Amazon Web Services の Amazon DynamoDB のシニアプロダクトマネージャーで、カリフォルニア州サンタクララに拠点を置いています。25 年以上にわたるプロダクトマネジメントとテクノロジーの役割を経験し、顧客とのエンゲージメントを通じてビジネスユースケースを理解しています。戦略と長期的な顧客価値を提供する新機能を逆算して定義することや、同僚と技術について深く議論することに情熱を持っています。仕事の外では、旅行、スポーツ、家族行事を楽しんでいます。

エグゼクティブやそのチームに実用的で客観的なインサイトを提供する Gartner は、 2024 Gartner Magic Quadrant for Contact Center as a Service(CCaaS) を発表しました。AWS がリーダーに選ばれたのは 2 年連続で、私たちはこのリーダーへの選出は、柔軟で、AI を活用したクラウドコンタクトセンターソリューションである Amazon Connect の革新性を示すものだと考えています。また、あらゆる規模の企業が優れた顧客体験を低コストで提供可能にする私たちのコミットメントを反映していると考えています。 Gartner によると、AWS は実行能力とビジョンの完全性により CCaaS のリーダーと判断されました。Amazon Connect のバイスプレジデントである Pasquale DeMaio は、「わずか 7 年で、Amazon Connect は数万の顧客から信頼を得るまでに成長し、2 年連続でリーダーに位置付けられ、私たちはますます情熱をもっています。私たちは、あらゆる規模の企業に、柔軟で拡張性があり、インテリジェントなクラウドコンタクトセンターソリューションを提供するため、急速なイノベーションを続けています。私たちは、企業が測定可能な結果をもたらす、より意味のある、パーソナライズされた顧客とのやり取りを実現できることに焦点を当てています」と述べています。 現在、Capital One、Intuit、Hilton、Air Canada、DoorDash、National Australia Bank、 Amazon.com のような お客様 が、優れた顧客体験を提供するために Amazon Connect を活用しています。 Gartner のレポートは、お客様のビジネスに適したクラウドコンタクトセンターソリューションを評価する際の有益なガイダンスを提供しています。 このリンクより、 2024 Gartner Magic Quadrant for CCaaS のレポート に無料でアクセスいただけます。Amazon Connect についてさらに詳しく知るには : Amazon Connect のページをご覧ください Amazon Connect IVR についてもっと知りたいですか ? お客様のペースに合わせた柔軟な移行オプションをご用意しています re:Invent 2024 でのAmazon Connect のセッションにご興味がありますか ? Amazon Connect によるカスタマーエクスペリエンスガイド をご確認ください re:Invent 2024 の振り返りは AWS re:Invent 2024 recap: Amazon Connect の新しいアナウンス をご覧ください Amazon Connect で顧客サービス体験を変革する準備はできましたか？ お問い合わせ ください。 この図は、Gartner, Inc. が発行したより大きな調査文書の一部であり、文書全体の文脈で評価されるべきものです。 Gartner の文書は、 AWS にリクエストすることで入手可能です。 GARTNER および Magic Quadrant は、米国およびその他の国における Gartner および/またはその関連会社の登録商標であり、許可を得て使用しています。すべての権利は留保されています。All rights reserved. Gartner は、その調査出版物に記載されているいかなるベンダー、製品またはサービスも推奨するものではなく、また、テクノロジーユーザーに対して、最高の格付けまたはその他の指定を受けたベンダーのみを選択するよう助言するものでもありません。Gartner の調査出版物は、 Gartner の調査組織の見解で構成されており、事実の記述として解釈されるべきものではありません。ガートナーは、本リサーチに関して、商業性または特定目的への適合性の保証を含め、明示または黙示を問わず、一切の保証を行わないものとします。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

本記事は 2025 年 1 月 29 日に公開された Deploy DeepSeek-R1 Distilled Llama models in Amazon Bedrock を翻訳したものです。翻訳はソリューションアーキテクトの森下裕介が担当しました。 オープンな基盤モデル (FM) は 生成 AI イノベーションの要であり、それによりあらゆる組織はコストとデプロイ戦略をコントロールしながら AI アプリケーションを構築・カスタマイズすることができます。高品質でありオープンに利用可能なモデルを提供することで、AI コミュニティは迅速なイテレーション、ナレッジシェア、そして開発者とエンドユーザーの両方に利益をもたらす費用対効果の高いソリューションを促進しています。AI 技術の進歩にフォーカスしている研究開発企業である DeepSeek AI は、このエコシステムに大きく貢献しています。彼らの DeepSeek-R1 モデルは、コード生成から一般的な推論まで幅広いタスクを処理しながら、競争力の高いパフォーマンスと効率性を維持するように設計された大規模言語モデル (LLM) のファミリーを表しています。 Amazon Bedrock Custom Model Import を使用することで、Amazon Bedrock が提供する既存の基盤モデルと同様に、カスタマイズしたモデルを単一のサーバーレスかつ統一された API を通じてインポートし、利用することができます。インフラストラクチャを管理する必要なく、インポートしたカスタムモデルにオンデマンドでアクセスすることが可能です。また、Knowledge Bases、Guardrails、Agents のような Amazon Bedrock のネイティブなツールや機能とカスタムモデルを統合することで、生成 AI アプリケーションの開発を加速させることができます。 この記事では、Amazon Bedrock Custom Model Import を使用して DeepSeek-R1 の蒸留バージョンをデプロイする方法を探ります。これにより、最先端のAI 機能を安全でスケーラブルな AWS インフラストラクチャ内で効果的なコストで使用したい組織がアクセスできるようになります。 訳註：2025 年 1 月 31 日現在、オリジナルバージョンである DeepSeek-R1 は Amazon Bedrock Marketplace 経由にて Amazon Bedrock 上で利用することが可能です。詳細は こちらのブログ をご覧ください。 DeepSeek-R1 蒸留モデルのバリエーション DeepSeek-R1 をベースとして、DeepSeek AI は Meta Llama および Qwen のアーキテクチャに基づいて、15 億から 700 億のパラメータを持つ一連の蒸留モデルを作成しました。蒸留プロセスでは、より大きな DeepSeek-R1 モデルを教師として使用し、その動作と推論パターンを模倣するように、より小さく効率的なモデルを訓練します。6710 億パラメータモデルの知識と能力を、よりコンパクトなアーキテクチャに転移させるのです。結果として得られた DeepSeek-R1-Distill-Llama-8B (ベースモデル Llama-3.1-8B から) や DeepSeek-R1-Distill-Llama-70B (ベースモデル Llama-3.3-70B-Instruct から) などの蒸留モデルは、パフォーマンスとリソース要件の間で異なるトレードオフを提供します。蒸留モデルは元の 6710 億モデルと比較して推論能力がやや低下する可能性がありますが、推論速度を大幅に向上させ、計算コストを削減します。例えば、8B バージョンのような小さな蒸留モデルは、リクエストの処理が非常に速く、リソース消費が少ないため、本番環境でのデプロイにおいては費用対効果が高くなります。一方、70B モデルのような大きな蒸留バージョンは、元のモデルに近いパフォーマンスを維持しながらも依然として意味のある効率性の向上を提供します。 ソリューション概要 この記事では、Amazon Bedrock Custom Model Import を使用して DeepSeek-R1 モデルの蒸留バージョンをデプロイする方法をご紹介します。今回は現在サポートされている DeepSeek-R1-Distill-Llama-8B と DeepSeek-R1-Distill-Llama-70B にフォーカスします。これらは、パフォーマンスとリソース効率の最適なバランスを提供します。これらのモデルを Amazon Simple Storage Service (Amazon S3) または Amazon SageMaker AI モデルリポジトリからインポートし、Amazon Bedrock を通じてフルマネージドなサーバーレス環境にデプロイできます。以下の図は、エンドツーエンドのフローを示しています。 このワークフローでは、Amazon S3 に保存されたモデルアーティファクトが Amazon Bedrock にインポートされ、Amazon Bedrock がモデルのデプロイメントとスケーリングを自動的に処理します。このサーバーレスアプローチにより、インフラ管理の必要性がなくなり、エンタープライズグレードのセキュリティとスケーラビリティが提供されます。 GUI を使用してデプロイする場合は、Amazon Bedrock コンソールを使用し、以下のこの記事の手順に従って操作してください。または、Amazon Bedrock SDK によるプログラムによってデプロイしたい方は こちらのノートブック を参照ください。 前提条件 手順を進めるにあたっては以下の前提条件が必要となります。 Amazon Bedrock にアクセスできる AWS アカウント。 Amazon Bedrock と Amazon S3 の操作に必要となる AWS Identity and Access Management (IAM) ロールと権限。詳細については ドキュメント を参照してください。 カスタムモデルを保存するために準備された S3 バケット。詳細については ドキュメント を参照してください。 十分なローカルストレージスペース ( 8B モデルの場合は少なくとも 17GB、70B モデルの場合は 135GB ) 。 モデルパッケージの準備 1. モデルパッケージを準備するには、以下の手順を完了してください： デプロイしたいモデルに応じて、以下の Hugging Face のリンクのいずれかから DeepSeek-R1-Distill-Llama モデルアーティファクトをダウンロードします。 https://huggingface.co/deepseek-ai/DeepSeek-R1-Distill-Llama-8B/tree/main https://huggingface.co/deepseek-ai/DeepSeek-R1-Distill-Llama-70B/tree/main ダウンロードの詳細については、Hugging Faceの「 モデルのダウンロード 」または「 ハブからのファイルのダウンロード 」の手順を参照ください。 通常、以下のファイルが必要です。 モデル設定ファイル： config.json トークナイザーファイル： tokenizer.json 、 tokenizer_config.json 、 tokenizer.mode .safetensors 形式のモデルの重みファイル 2. これらのファイルを S3 バケット内のフォルダにアップロードします。Amazon Bedrock を利用する AWS リージョンと同じリージョンを使用してください。使用している S3 パスをメモしておきます。( 訳註：2025 年 1 月 29 日現在 Amazon Bedrock Custom Model Import をサポートしているのは、米国東部 (バージニア北部) リージョンおよび米国西部 (オレゴン) リージョンとなります。) モデルのインポート モデルをインポートするには、以下の手順を完了してください： 1. Amazon Bedrock コンソールにてナビゲーションペインの Foundation models の下にある Imported models を選択します。 2. Import model を選択します。 3. Model name にモデルの名前を入力します (インポートしたモデルを追跡するために、名前にバージョニングスキームを使用することをお勧めします) 。 4. Import job name にインポートジョブの名前を入力します。 5. Model import settings にて、インポートソースとして Amazon S3 bucket を選択し、先ほどメモした S3 パスを入力します ( s3://<your-bucket>/folder-with-model-artifacts/ の形式で完全なパスを提供してください）。 6. Encryption で、必要に応じて暗号化設定をカスタマイズすることができます。 7. Service access role で、新しい IAM ロールを作成するか、独自のロールを提供するかを選択します。 8. Import model を選択します。 モデルのインポートには、インポートされるモデルに応じて数分かかります (例えば、Distill-Llama-8B モデルの場合完了までに5〜20 分かかる可能性があります) 。 ステップバイステップのガイドについては、このビデオデモをご覧ください。 インポートしたモデルのテスト モデルをインポートした後、Amazon Bedrock Playground を使用するか Amazon Bedrock のモデル呼び出し API を直接使用してテストできます。Playground を使用するには、以下の手順を完了してください。 Amazon Bedrock コンソールで、ナビゲーションペインの Playgrounds の下にある Chat / Text を選択します。 モデルセレクターから、インポートしたモデル名を選択します。 必要に応じて推論パラメータを調整し、テストプロンプトを書きます。例えば、 <|begin▁of▁sentence|><|User|>Given the following financial data: - Company A's revenue grew from $10M to $15M in 2023 - Operating costs increased by 20% - Initial operating costs were $7M Calculate the company's operating margin for 2023. Please reason step by step, and put your final answer within \boxed{}<| Assistant|> Playground でインポートしたモデルを使用しているため、DeepSeek モデルのコンテキストを適切にフォーマットするために、”beginning_of_sentence” と “user/assistant” タグを含める必要があります。これらのタグは、モデルが会話の構造を理解し、より正確な応答を提供するのに役立ちます。ノートブック を用いてプログラムによるアプローチに従っている場合、これはモデルを設定することで自動的に処理されます。 4. モデルの応答とメトリクスを確認します。 注： モデルを初めて呼び出すときに、 ModelNotReadyException エラーが発生した場合、SDK はエクスポネンシャルバックオフを使用してリクエストを自動的に再試行します。復元時間は、オンデマンドフリートのサイズとモデルのサイズによって異なります。 AWS SDK for Python (Boto3) Config オブジェクトを使用して、再試行の動作をカスタマイズできます。詳細については、 こちらのドキュメント を参照してください。 モデルのインポートの準備ができたら、上記のステップバイステップのビデオデモを参考にしながら利用を開始してください。 料金 Custom Model Import を使用すると、サポートされているアーキテクチャのカスタムモデルの重みを Amazon Bedrock 内で使用でき、Amazon Bedrock の既存の基盤モデルと同様にフルマネージドな環境でオンデマンドモードにてモデルをサーブすることが可能となります。Custom Model Import はモデルのインポートに対して課金はなされません。推論に対して、「アクティブなモデルコピーの数」と「アクティビティ期間」の 2 つの要因に基づいて課金されます。 請求は、各モデルコピーの最初の成功した呼び出しから始まる 5 分間のウィンドウで行われます。モデルコピーあたりの 1 分あたりの価格は、アーキテクチャ、コンテキスト長、リージョン、コンピュートユニットバージョンなどの要因に基づいて変動し、モデルコピーのサイズによって階層化されています。ホスティングに必要なカスタムモデルユニットは、モデルのアーキテクチャ、パラメータ数、コンテキスト長に依存し、例えば Llama 3.1 8B 128K モデルの場合は 2 ユニット、Llama 3.1 70B 128Kモデルの場合は 8 ユニットとなります。 Amazon Bedrock は自動的にスケーリングを管理し、デフォルトでは使用パターンに基づいて 0 から 3 のモデルコピーを維持します (Service Quotas を通じて調整可能)。5 分間呼び出しがない場合、0 にスケールダウンし、必要に応じてスケールアップしますが、これには数十秒のコールドスタート遅延が伴う可能性があります。推論量が単一コピーの同時実行制限を一貫して超える場合、追加のコピーが追加されます。コピーあたりの最大スループットと同時実行性は、入/出力トークンの組み合わせ、ハードウェアタイプ、モデルサイズ、アーキテクチャ、推論の最適化などの要因に基づいてインポート時に決定されます。 料金の例を見てみましょう：アプリケーション開発者が us-east-1 リージョンで 128K シーケンス長・パラメータサイズ 8B のカスタマイズ済み Llama 3.1 タイプモデルをインポートし、1 ヶ月後にモデルを削除するケースです。これには、2 つのカスタムモデルユニットが必要となります。したがって、1 分あたりの価格は $0.1570 となり、モデルのストレージコストは 1 ヶ月で $3.90 となります。 詳細については、 Amazon Bedrock の料金ページ をご覧ください。 ベンチマーク DeepSeek は、モデルリポジトリで利用可能な、DeepSeek-R1 から蒸留された彼らのモデルとベースとなる Llama モデルを比較した ベンチマークを公開 しています。ベンチマークによると、タスクに応じて DeepSeek-R1-Distill-Llama-70B は元のモデルの推論能力の 80-90% を維持し、8B バージョンはリソース要件を大幅に削減しながら 59-92% のパフォーマンスを達成しています。どちらの蒸留バージョンも、特定の推論タスクにおいて対応するベースの Llama モデルよりも改善を示しています。 その他の考慮事項 Amazon Bedrock で DeepSeek モデルをデプロイする際は、以下の点を考慮してください。 モデルのバージョン管理が不可欠です。Custom Model Import は各インポートに対して固有のモデルを作成するため、異なるバージョンやバリエーションを追跡するためには、モデル名に明確なバージョニング戦略を実装してください。 現在サポートされているモデル形式は Llama ベースのアーキテクチャに焦点を当てています。DeepSeek-R1 の蒸留バージョンモデルは優れたパフォーマンスを提供しますが、AI エコシステムは急速に進化し続けています。新しいアーキテクチャやより大きなモデルがプラットフォームを通じて利用可能になる Amazon Bedrock のモデルカタログに注目してください。 ユースケースの要件を慎重に評価してください。DeepSeek-R1-Distill-Llama-70B のような大きなモデルはより良いパフォーマンスを提供しますが、8B バージョンは多くのアプリケーションに対して十分な能力を低コストで提供する可能性があります。 モニタリングと可観測性の実装を検討してください。 Amazon CloudWatch はインポートしたモデルのメトリクスを提供し、利用パターンとパフォーマンスを追跡するのに役立ちます。 AWS Cost Explorer を使用してコストを監視できます。 低い同時実行クォータから始め、実際の使用パターンに基づいてスケールアップすることを検討してください。アカウントあたり 3 つの同時モデルコピーというデフォルトの制限は、殆どのケースにおいて初期のデプロイメントに適しています。 結論 Amazon Bedrock Custom Model Import は、あらゆる組織が DeepSeek-R1 蒸留バージョンモデルなどの強力な公開モデルを使用しながら、エンタープライズグレードのインフラストラクチャの恩恵を受けることを可能にします。Amazon Bedrock のサーバーレスな特性により、モデルのデプロイメントと運用の管理の複雑さが解消され、チームはインフラストラクチャではなくアプリケーションの構築に集中できます。自動スケーリング、使用量に応じた料金設定、AWS サービスとのシームレスな統合などの機能により、Amazon Bedrock は AI ワークロードに対する本番対応の環境を提供します。DeepSeek の革新的な蒸留アプローチと Amazon Bedrock のマネージドインフラストラクチャの組み合わせは、パフォーマンス、コスト、運用効率の最適なバランスを提供します。組織は小さなモデルから始め、必要に応じてスケールアップしながら、モデルのデプロイメントを完全にコントロールし、AWS のセキュリティとコンプライアンス機能の恩恵を受けることができます。 Amazon Bedrock が提供する独自の基盤モデルとオープンな基盤モデルの選択肢により、組織は特定のニーズに最適化する柔軟性を得られます。オープンモデルは、モデルアーティファクトを完全に制御しながら費用対効果の高いデプロイメントを可能にし、カスタマイズ、コスト最適化、またはモデルの透明性が重要なシナリオに適しています。この柔軟性と、Amazon Bedrock の統一的な API およびエンタープライズグレードのインフラストラクチャを組み合わせることで、組織は要件の進化に適応できる耐久性のある AI 戦略を構築できます。 詳細については、 Amazon Bedrock ユーザーガイド を参照してください。 著者について Raj Pathak は、プリンシパルソリューションアーキテクトであり、カナダと米国の Fortune 50および 中堅金融サービス業 (銀行、保険、資本市場) のお客様の技術顧問を務めています。Raj は機械学習を専門とし、生成 AI、自然言語処理、インテリジェントドキュメント処理、MLOps の領域において高い専門性を持っています。 Yanyan Zhang は、Amazon Web Services のシニア生成 AI データサイエンティストです。生成 AI スペシャリストとして最先端の AI/ML 技術に取り組み、お客様が生成 AI を使用して望む成果を達成できるよう支援しています。Yanyan はテキサス A&M 大学で電気工学の博士号を取得しました。仕事以外では、旅行、運動、新しいことの探求を楽しんでいます。 Ishan Singh は、Amazon Web Services の生成 AI データサイエンティストで、お客様が革新的で責任ある生成 AI ソリューションと製品を構築するのを支援しています。AI/ML の強力な背景を持つ Ishan は、ビジネス価値を推進する生成 AI ソリューションの構築を専門としています。仕事以外では、バレーボールをしたり、地元の自転車道を探索したり、妻と犬の Beau と時間を過ごすことを楽しんでいます。 Morgan Rankey は、ニューヨークを拠点とするソリューションアーキテクトで、ヘッジファンドを専門としています。AWS エコシステム内で耐障害性のあるワークロードを構築するお客様の支援に優れています。AWS に入社する前は、Riskified のセールスエンジニアリングチームを IPO までリードしました。キャリアの始まりは、機械資産管理のための AI/ML ソリューションに焦点を当て、世界中の大手自動車会社にサービスを提供しました。 Harsh Patel は、クラウドネイティブソリューションを通じてデジタル変革を推進するため、米国全土の 200 以上の SMB のお客様をサポートするソリューションアーキテクトです。AI & ML スペシャリストとして、生成 AI、コンピュータビジョン、強化学習、異常検出に焦点を当てています。テクノロジーの世界以外では、ゴルフコースでリフレッシュしたり愛犬と一緒にハイキングに出かけたりしています。

本稿は 2025 年 1 月 27 日に公開された “ Introducing the GraphRAG Toolkit ” を翻訳したものです。 Amazon Neptune チームは 2025 年 1 月 21 日に GraphRAG Toolkit を リリース しました。これは、グラフデータベースを活用した検索拡張生成 (Retrieval Augmented Generation; RAG) ワークフローの構築を容易にするオープンソースの Python ライブラリです。このツールキットは、非構造化データから、ベクトル埋め込みを含むグラフを自動的に構築するフレームワークを提供します。ユーザーの質問に答える際に、構造的に関連する情報を取得するために、このグラフをクエリする質問応答戦略を組み立てることができます。 本稿では、GraphRAG Toolkit の使い方について説明します。まず、RAG アプリケーションにグラフを追加することのメリットについて説明します。次に、クイックスタート環境のセットアップ方法とツールキットのインストール方法を説明します。最後に、このツールキットのグラフモデルとコンテンツ取得アプローチに至った設計上の考慮点について説明します。 なぜ RAG アプリケーションにグラフを追加するのか？ 以下のような 架空の 物語を考えてみましょう。これは数週間にわたる、様々な架空のニュース記事、プレスリリース、業界出版物、アナリストレポートを集めたものであり、他の多くの文書と共に RAG ワークフローに投入されると想定しています。 Example Corp (人気の個人用ガジェットである “Widget” を製造する米国企業) は最近、国際的な輸送、保管、ラストマイル配送を提供する AnyCompany Logistics と提携することで、世界的な流通チャネルを拡大しました。“Widget” は、新世代の生成 AI テクノロジーによって会話機能を備えた AI 搭載のパーソナルデスクトップペットです。オースティンを拠点とする Example Corp の研究所で開発され、台湾で製造されています。 まだ 8 月であるにもかかわらず、英国のクリスマストップ 10 おもちゃの予測が既に発表されており、業界アナリストは Example Corp のおしゃべりデスクトップペット “Widget“ への大きな需要を予測しています。ロンドン、マンチェスター、その他の主要都市の小売業者は既に 100 万台以上 (1,500 万ドル相当) の注文を行っており、クリスマスまでの数ヶ月でその数字はさらに増加する見込みです。 AnyCompany Logistics は本日、最近開通した Fictitious Canal (架空の運河) を通じて全ての配送を行うことで、 2 週間かかっていた台湾から英国までの輸送時間を僅か 3 日に短縮すると発表しました。Fictitious Canal は、製造業者や流通業者がエネルギー消費とコストを削減するため、空輸から海運への移行を検討する中で、今後 5 年間で最も交通量の多い水路のひとつになる見込みです。 Fictitious Canal で地滑りが発生し、閉塞と遅延が続いています。現在、500 万トン以上の岩が南部水域を塞ぎ、コンテナ船を閉じ込め、国際サプライチェーンを混乱させています。ヨーロッパ向けの商品は数ヶ月の遅延が予想され、多くの小売業者のクリスマス在庫が危機にさらされています。 あなたがアナリストだとしましょう。どんなことを知りたいでしょうか？例えば、Example Corp の英国での販売見通しはどうか調査したいとします。 まず、ベクトルベースの主要な RAG アプリケーションに質問したところ、以下のような回答が得られました。 提供されたコンテキストに基づくと、 Example Corp の Widget 製品の英国での販売見通しは、きたるクリスマスシーズンに向けて非常に明るいものとなっています。業界アナリストは Widget おしゃべりデスクトップペットへの大きな需要を予測しており、クリスマスのトップ 10 おもちゃにもランクインしています。ロンドンやマンチェスターなど英国の主要都市の小売業者は既に 1,500 万ドル相当の 100 万台以上の注文を行っており、クリスマスが近づくにつれてさらに注文数は増加すると予想されています。このコンテキストは、 Example Corp が重要な年末商戦期間中、英国市場で Widget 製品の非常に高い販売量と収益を見込めることを示唆しています。 次に、 GraphRAG Toolkit を使用して構築されたアプリケーションに質問したところ、以下のような回答が得られました。 検索結果に基づくと、 Example Corp のおしゃべりデスクトップペット Widget の英国での販売見通しは当初非常に有望ですが、後にサプライチェーンの問題が販売を妨げる可能性があります。 検索結果によると、ロンドンやマンチェスターなど英国の主要都市の小売業者は、大きな需要を見込んで Widget 製品の 100 万台以上の注文を既に行っています。業界アナリストもこのおもちゃへの高い需要を予測しています。 この予想される需要に応えるため、 Example Corp は AnyCompany Logistics と提携して、英国を含む世界的な流通チャネルを拡大しています。 AnyCompany Logistics は、新たに開通した Fictitious Canal を経由して輸送することで、台湾から英国までの輸送時間を 2 週間から僅か 3 日に短縮する計画を発表していました。 しかし、 Fictitious Canal では地滑りによる大規模な閉塞が報告されており、500 万トン以上の岩が南部水域を塞ぎ、コンテナ船を閉じ込めています。これにより国際サプライチェーンが混乱し、英国を含むヨーロッパ向けの商品が数ヶ月遅延する可能性があります。 そのため、 Example Corp の Widget 製品の英国での初期の販売見通しは、予約注文と予想される需要に基づいて非常に有望に見えますが、状況が早急に解決されない場合、 Fictitious Canal の閉塞によるサプライチェーンの問題が今後数ヶ月間の需要への対応能力を妨げるリスクがあります。 なぜ回答にこれほどの大きな違いがあるのでしょうか？グラフアプローチは、ベクトルベースのアプローチにはない何を提供するのでしょうか？ ベクトル検索では、問われている質問に対して意味的に類似している、つまり言語的に近い情報しか取得できません。類似していない情報は、構造的に取得できません。この例では、 AnyCompany Logistics による Fictitious Canal の使用と、現在 Fictitious Canal を悩ませている閉塞に関する断片情報は、問われている質問との類似性が十分でないため、ベクトルベースのソリューションではコンテキストに取り込まれません。たとえそれらが、より正確で完全な回答を作成する上で極めて重要な情報であったとしてもです。 情報検索における 関連性 (relevancy) は 関係性 (relatedness) という観点で考えることができます。質問に関連するものは、直接的または間接的に、その質問と何らかの関係があります。関係性は 類似性 (similarity) よりも広い概念です。意味的類似性は、私たちが興味を持つものが互いに関係する方法のひとつに過ぎません。例えば、テキスト A と B は意味的に類似しているために関係があると言えるでしょう。しかし、物事が関係を持つ方法は他にもたくさんあります。時間や空間における連続性、因果関係、親子関係、部分-全体関係、あるいは社会的、組織的、法的、分類学的な関係など、このリストは無限に続きます。物事が関係する方法や、それらの関係の相対的な重要性、強さ、質は、業界ドメインによって異なりますが、「意味的に類似している」ことは RAG 検索ツールボックスのひとつのツールに過ぎないと言えます。 私たちのドメインをグラフとしてモデル化し、グラフのエッジを使って私たちにとって重要な異なるタイプの関係を表現することで、質問とは異なるものの、正確で完全な回答を作成する上で構造的に関連する情報へのアクセスを提供できます。 類似性に基づく検索は依然として重要な RAG 戦略であり、質問と意味的に類似したコンテキストは、しばしば良い回答の基礎となります。しかし、類似性に基づく検索だけでは、ニュアンスのある回答を生成するのに常に十分というわけではありません。多くの場合、比較、議論、要約を展開するためのより差別化されたコンテキストを質問応答プロセスに提示するために、ベクトル類似度検索では見つけられない情報を見つけて返す必要があります。グラフ内の関係は、検索プロセスがこのような追加の関連情報を見つけるための手段を提供します。 GraphRAG Toolkit すべての RAG アプリケーションは、インデックス化 (indexing) とクエリ処理 (querying) というふたつのコア機能を中心に構築されています。 GraphRAG Toolkit は、データをグラフとベクトルストアにインデックス化し、このグラフから関連コンテンツを取得する質問応答ソリューションを構築するために使用できるオープンソースの Python ライブラリです。 ツールキットの第 1 版では、非構造化および半構造化テキストコンテンツ (ウェブページ、PDF、JSON ドキュメントなど) を用いてグラフベースの RAG アプリケーションを構築することに焦点を当てています。ツールキットのセットアップと実行の詳細については、この投稿の後半にある「GraphRAG Toolkit のインストール」セクションをご参照ください。 インデックス化 コンテンツのインデックス化は、少量のコードで実現できます。 from graphrag_toolkit import LexicalGraphIndex from graphrag_toolkit.storage import GraphStoreFactory from graphrag_toolkit.storage import VectorStoreFactory from llama_index.readers.web import SimpleWebPageReader import nest_asyncio nest_asyncio.apply() doc_urls = [ 'https://docs.aws.amazon.com/neptune/latest/userguide/intro.html', 'https://docs.aws.amazon.com/neptune-analytics/latest/userguide/what-is-neptune-analytics.html', 'https://docs.aws.amazon.com/neptune-analytics/latest/userguide/neptune-analytics-features.html', 'https://docs.aws.amazon.com/neptune-analytics/latest/userguide/neptune-analytics-vs-neptune-database.html' ] docs = SimpleWebPageReader( html_to_text=True, metadata_fn=lambda url:{'url': url} ).load_data(doc_urls) graph_store = GraphStoreFactory.for_graph_store( 'neptune-db://my-graph.cluster-abcdefghijkl.us-east-1.neptune.amazonaws.com' ) vector_store = VectorStoreFactory.for_vector_store( 'aoss://https://abcdefghijkl.us-east-1.aoss.amazonaws.com' ) graph_index = LexicalGraphIndex( graph_store, vector_store ) graph_index.extract_and_build(docs) LexicalGraphIndex はコンテンツのインデックス化の主要な手段です。この例で示すように、連続取り込み方式で使用できます。コンテンツは一連の抽出とビルドのステージを通してパイプライン処理され、グラフはすぐにデータで埋められ始め、取り込みが続いている最中でもクエリを実行できるようになります。また、抽出とビルドのステージを別々に実行することもできます。1 回限りのジョブを実行する場合だけでなく、同じ抽出されたコンテンツを再利用してグラフを複数回構築したい場合にこの仕組みが役立ちます。 LexicalGraphIndex は、グラフストアとベクトルストアで構成されています。この例では、 Neptune Database グラフストアと Amazon OpenSearch Serverless ベクトルストアを使用しています。執筆時点で、このツールキットは Neptune Database と Neptune Analytics 、OpenSearch Serverless、およびコンテンツの抽出と埋め込みに使用される基盤モデル用の Amazon Bedrock をサポートしています。 前述の例では、インデックス化するコンテンツとして、 Neptune のドキュメントの複数ページを取り込んでいます。データをパースしてインデックスに取り込むために、 LlamaIndex の SimpleWebPageReader を使用しています。ソースデータの種類と場所に応じて、 SimpleDirectoryReader や JSONReader を含む他の LlamaIndex リーダーを使用してデータをインデックスにロードすることもできます。 クエリ処理 クエリ処理、つまり質問応答は、インデックス化と同じくらい簡単です。 from graphrag_toolkit import LexicalGraphQueryEngine from graphrag_toolkit.storage import GraphStoreFactory from graphrag_toolkit.storage import VectorStoreFactory import nest_asyncio nest_asyncio.apply() graph_store = GraphStoreFactory.for_graph_store( 'neptune-db://my-graph.cluster-abcdefghijkl.us-east-1.neptune.amazonaws.com' ) vector_store = VectorStoreFactory.for_vector_store( 'aoss://https://abcdefghijkl.us-east-1.aoss.amazonaws.com' ) query_engine = LexicalGraphQueryEngine.for_traversal_based_search( graph_store, vector_store ) response = query_engine.query('''What are the differences between Neptune Database and Neptune Analytics?''') print(response.response) クエリ処理は実際には 2 段階のプロセスです。基礎となるストレージから関連情報を取得することから始まり、その後、この情報を大規模言語モデルに渡して回答を生成します。 LexicalGraphQueryEngine はこの両方のステップをあなたに代わって実行します。 インデックス化の段階で LexicalGraphIndex を構成したときと同様に、ここでも、グラフストアとベクトルストアを引数にして LexicalGraphQueryEngine を構成しています。一見すると、これは少し冗長に思えるかもしれません。しかし、インデックス化とクエリ処理はそれぞれ異なるプロセスであり、異なる環境で、異なるマシン上で、異なる時間に実行される可能性があります。そのため、各プロセスを構成する際には個別にグラフストアとベクトルストアの URI を指定する必要があります。 GraphRAG Toolkit のインストール プロジェクトの GitHub リポジトリにあるクイックスタート用の AWS CloudFormation テンプレート を使用して、 GraphRAG Toolkit を使い始めることができます。このテンプレートは、 Neptune Database と OpenSearch Serverless コレクション、そしてサンプルコードを含む Amazon SageMaker ノートブックインスタンスを作成します。これらの例では、 Amazon Bedrock の基盤モデルを使用してコンテンツの抽出と埋め込み、および回答の生成を行います。 前提条件 テンプレートを実行する前に、 Amazon Bedrock で適切な基盤モデルへのアクセスを有効にしていることを確認してください。デフォルトのモデルは以下の通りです： anthropic.claude-3-sonnet-20240229-v1:0 cohere.embed-english-v3 クイックスタートの例で構成されているモデル以外でも、ツールキットを 構成する ことができます。 CloudFormation スタックは、これらのモデルを提供している AWS リージョンで実行する必要があり、ノートブック例を実行する前に モデルへのアクセスを有効にする 必要があります。 CloudFormation スタックのデプロイ 以下のスクリーンショットは、 CloudFormation テンプレートのスタックの詳細を示しています。 まず、スタック名を指定する必要があります。ほとんどのパラメータには適切なデフォルト値が設定されていますが、変更したい項目がいくつかあるかもしれません。 ApplicationId – Neptune クラスターとインスタンス、 OpenSearch Serverless コレクションを含むデプロイメント内のリソースの名前付けに使用される一意の識別子を指定する。 IamPolicyArn – SageMaker ノートブックインスタンスにアタッチされる追加の AWS Identity and Access Management (IAM) ポリシーの Amazon リソースネーム (ARN) を指定する。このカスタムポリシーには、特定の Amazon Simple Storage Service (Amazon S3) バケットや追加の Amazon Bedrock 基盤モデルなど、使用したい追加リソースへのアクセス権限を含めることができる。 なお、このテンプレートは以下のリソースを作成します。 3 つのプライベートサブネット、1 つのパブリックサブネット、およびインターネットゲートウェイを持つ仮想プライベートクラウド (VPC) 単一の Neptune サーバーレスインスタンスを持つ Neptune Database クラスター パブリックエンドポイントを持つ OpenSearch Serverless コレクション GraphRAG Toolkit のサンプルノートブックを含む SageMaker ノートブック スタックのデプロイメントが完了したら、 SageMaker サンプルノートブックを開くことができます (スタックの Outputs タブに、ノートブックインスタンスへのリンクを含む NeptuneSagemakerNotebook 出力パラメータがあります)。そして、コンテンツのインデックス化とクエリ処理を開始できます。 ノートブックの実行 ノートブック「 01 – Combined-Extract-and-Build 」は良い出発点です。各ノートブックの最初のセルでは、 GitHub リポジトリからツールキットをインストールします。なお、このインストールは、デプロイメントごとに 1 回だけ実行する必要があるもので、各ノートブックごとに実行する必要はありません。 インストールが完了したら、2 番目のセルを実行できます。これによりサンプルコンテンツのインデックスが作成されます。 インデックス化が完了したら、コンテンツへのクエリ処理を開始できます。 ノートブック「 04 – Querying 」では、ツールキットに含まれる異なるクエリ戦略を試すことができます。 リソースのクリーンアップ デプロイされたリソースはアカウントに課金されます。不要な料金 (米国東部 (バージニア北部) リージョンで約 1.5 ドル/時) が発生しないよう、使用し終わったら スタックを削除 することを忘れないでください。 独自のアプリケーションの構築 ツールキットを使用するためには必ずしもクイックスタート用の CloudFormation テンプレートを起動する必要はありません。独自の環境にツールキットをインストールし、他のライブラリやサービスとツールキットを組み合わせて独自の Python アプリケーションを構築できます (あらかじめ必要なグラフとベクトルストアのリソースをプロビジョニングし、適切な基盤モデルへのアクセスを事前に確保する必要はあります)。 ツールキットとその依存関係は pip を使用してインストールできます (現在、ツールキットは PyPi では配布されていませんが、プロジェクトの GitHub リポジトリ上で頻繁にリリースしています)。最新バージョンをインストールするには、プロジェクトのホームページにある インストール手順 に従ってください。 プロジェクトの ドキュメント には、 インデックス化 と クエリ処理 プロセスの設定と実行に関する多くの例が含まれています。これらの例を自分のアプリケーションで使用するように適応できます。ドキュメントの例はノートブック環境で実行するように書かれています。メインエントリーポイントを持つアプリケーションを構築する場合は、アプリケーションロジックをメソッド内に配置し、 if __name__ == ’__main__' ブロックを追加する必要があります： import os from graphrag_toolkit import LexicalGraphIndex from graphrag_toolkit.storage import GraphStoreFactory from graphrag_toolkit.storage import VectorStoreFactory from llama_index.readers.web import SimpleWebPageReader import nest_asyncio nest_asyncio.apply() def run_extract_and_build(): graph_store = GraphStoreFactory.for_graph_store( 'neptune-db://my-graph.cluster-abcdefghijkl.us-east-1.neptune.amazonaws.com' ) vector_store = VectorStoreFactory.for_vector_store( 'aoss://https://abcdefghijkl.us-east-1.aoss.amazonaws.com' ) graph_index = LexicalGraphIndex( graph_store, vector_store ) doc_urls = [ 'https://docs.aws.amazon.com/neptune/latest/userguide/intro.html', 'https://docs.aws.amazon.com/neptune-analytics/latest/userguide/what-is-neptune-analytics.html', 'https://docs.aws.amazon.com/neptune-analytics/latest/userguide/neptune-analytics-features.html', 'https://docs.aws.amazon.com/neptune-analytics/latest/userguide/neptune-analytics-vs-neptune-database.html' ] docs = SimpleWebPageReader( html_to_text=True, metadata_fn=lambda url:{'url': url} ).load_data(doc_urls) graph_index.extract_and_build(docs, show_progress=True) if __name__ == '__main__': run_extract_and_build() グラフモデルとクエリ戦略の設計 RAG ソリューションを設計する際は、特定のワークロードのニーズをサポートできる適切な検索と生成の戦略、および基盤となるインデックス化とストレージの仕組みを決定するために、Working Backwards (お客様を起点に考える) アプローチを採用するといいでしょう。ワークフローは、どのような質問応答やエンドユーザー、アプリケーションのデータニーズを満たすことを意図していますか？それらのニーズを満たすためにどのようなデータを取得する必要がありますか？どのような検索戦略がこのデータをコンテキストウィンドウに最も効果的に提供しますか？そして、どのようなインデックス構造やデータモデルがそのような検索を最も効率的に促進しますか？ GraphRAG Toolkit は、非構造化および半構造化テキストコンテンツに対する質問応答ワークフローをサポートするように設計されており、特に複数の潜在的に無関係なソースから、またはベクトルベースのソリューションのみでは構造的にアクセスできない情報から関連情報を取得する必要があるワークフローをサポートします。これらは 検索ベース のワークフローと呼ぶことができ、数値結果の計算を必要とする カウントベース や 集計ベース のワークフローとは異なります。 検索ベースのワークフローのニーズを満たすために、システムは質問応答プロセス、つまり基盤モデルに対して関連するテキストコンテンツの断片 (テキストのスニペット、または語彙単位 (lexical unit)) を渡す必要があります。これを念頭に置いて、最初に取り組まなければならない設計上の決定のひとつは、 基盤モデルに提供されるコンテキストの基礎となる語彙単位のサイズはどのくらいにすべきか、ということでした。多くの RAG アプリケーションでは、コンテキストの主要な単位はチャンクです。つまり、コンテキストウィンドウはコーパスから取得されたひとつ以上のチャンクで構成されます。異なるチャンク分割戦略は異なるサイズのチャンクを生成します (チャンクの万能な定義はありません) が、チャンクは通常、個々の文よりも大きく、文書全体よりも小さいものです。 GraphRAG Toolkit では、コンテキストの主要な単位はチャンクではなく、独立した主張や命題である ステートメント (statement) です。ソース文書はチャンクに分割され、これらのチャンクからステートメントが抽出されます。ステートメントは トピック (topic) ごとにテーマ別にグループ化され、 事実 (fact) によって裏付けられます。質問応答時に、ツールキットはトピックでグループ化された関連ステートメントのセットを取得し、基盤モデルのコンテキストウィンドウに渡します。 基盤モデルにステートメントの形で語彙単位を提供するという要件により、 語彙グラフ (lexical graph) モデルと、語彙グラフモデルをターゲットとする抽出プロセスを設計することになりました。この語彙グラフには 3 つの階層があります。 系統 (lineage) – ソース、チャンク、およびそれらの間の関係。下図の水色パート。 要約 (summarization) – トピック、ステートメント、およびステートメントを裏付ける事実。下図の緑色パート。 エンティティ-関係 (entity-relationship) – 基礎となるソースから抽出された個々のエンティティと関係。下図の赤色パート。 以下の図は、全体的な語彙グラフモデルを示しています。 このグラフモデルの詳細については、ツールキットの ドキュメント で確認することができます。このセクションでは、緑色で示されている「要約」階層についてより深く掘り下げます。 グラフモデルを設計する際、私たちはしばしばこのモデルを、興味のある物事を表現する能力という観点で考えます。もうひとつの、しかし補完的な視点は、モデルがサポートすることを意図しているアプリケーションとデータのニーズの文脈における、各モデル要素の役割や責任を考えることです。ツールキットのために特定した検索ベースのワークフローのニーズの文脈では、モデルは質問に直接または間接的に関連する離散的な語彙単位の取得をサポートする必要があります。モデルがこの関連性や接続性 (connectedness) をどのように示し適用するかが、検索戦略の効果を大きく決定します。単にすべてのものをすべてのものに結びつけてしまうと、無関係な情報の海の中から関連するコンテキストの単位を抽出することが難しくなります。一方、グラフ内の要素間の接続をほとんど許可しないモデルは、関連はあるものの意味的に異なる情報を発見する機会を減らします。よく設計されたグラフはバランスを取ります。関連性を薄めてしまう膨大な量の接続を避けながら、文脈的に重要だが明白でない関係を発見するのに十分な接続を確保します。 要約階層の要素は、いくつかの異なる責任を果たします。語彙単位の取得に関して、ステートメント (statement) は基盤モデルに返される主要なコンテキストの単位として機能します。接続性に関して、要約階層はローカルとグローバルの接続性を区別します。トピック (topic) は同じソースから派生したステートメント間のローカルな主題的接続を提供します。事実 (fact) は異なるソースから派生したステートメント間のグローバルな接続を提供します。また、トピックと事実には二次的な責任もあります。トピックはステートメントをグループ化する役割を果たし、事実はステートメントに注釈を付けたりより詳細な情報を提供したりします。ローカルとグローバルの接続性の責任のこの区分により、検索戦略はグラフの探索を制御できます。例えば、リトリーバー (retriever) はより遠い機会を試験的に探索しつつ、主にローカルに留まることを選択できます。あるいは、広く探索し始めてから、最も有望なトピックに絞り込むこともできます。 グラフからコンテンツを取得する際、検索戦略はまずひとつ以上の適切なエントリーポイントを見つけ、その後関連するステートメントに移動します。ベクトルストアはここでエントリーポイントを見つけるのに重要な役割を果たします。現在の語彙グラフの実装では、ステートメントとチャンクの両方が埋め込まれています。そのため、リトリーバーはチャンクレベルまたはステートメントレベルで質問と意味的に類似したエントリーポイントを見つけ、そこから近隣のローカルステートメントを探索し、より間接的に接続された遠いステートメントにホップすることができます。リトリーバーはまた、エンティティ-関係階層のエンティティに対してキーワード検索を実行し、そこからステートメントとトピックに移動することもできます。この方法は通常、より広範なステートメントのセットを生成します。 ツールキットには現在、 TraversalBasedRetriever と SemanticGuidedRetriever というふたつの異なる高レベルのリトリーバーが含まれています。 TraversalBasedRetriever は、ベクトル類似度検索を通じてチャンクを見つけ、これらのチャンクからトピックを通じてステートメントと事実に移動するトップダウン検索と、エンティティのキーワードベースの検索を実行し、事実からステートメントとトピックに進むボトムアップ検索を組み合わせて使用します。 SemanticGuidedRetriever は、ベクトルベースの意味検索と構造化されたグラフ走査を組み合わせます。意味検索とキーワード検索を通じてエントリーポイントを特定し、その後ビーム検索 (beam search) とパス分析 (path analysis) を通じてグラフをインテリジェントに探索し、再ランク付け (reranking) と多様性フィルタリング (diversity filtering) を使用して質の高い結果を得ます。このハイブリッドアプローチにより、正確なマッチングと文脈的な探索の両方が可能になります。 まとめ この記事では、 GraphRAG Toolkit の使い方について説明しました。このオープンソースの Python ライブラリは、構造的に関連する情報を取得するためにグラフを使用する RAG アプリケーションの構築を支援できます。 ぜひ、ご自身のユースケースで ツールキット を試してみて、フィードバックを共有してください。 著者について Ian Robinson は Amazon Neptune のプリンシパルグラフアーキテクトです。著書に「Graph Databases」と「REST in Practice」(いずれも O’Reilly 出版) があり、「REST: From Research to Practice」(Springer) と「Service Design Patterns」(Addison-Wesley) の共著者です。 Abdellah Ghassel は Amazon Neptune の機械学習エンジニアとしてインターンをしています。 本稿の翻訳は AWS Japan の機械学習スペシャリストソリューションアーキテクトの本橋が担当しました。

近年、企業や組織において、生成 AI を自社のプロダクトに組み込む取り組みが広がっています。生成 AI は、テキスト生成、画像や動画の生成、音声生成など、様々な分野で活用されるようになり、業務の効率化や新しい価値の創出などに期待が高まっています。 一方で、生成 AI を自社のプロダクトに組み込むにあたっては、セキュリティ面での課題にも十分に注意を払う必要があります。生成 AI は、機械学習や自然言語処理などの高度な技術を用いて構築されるため、従来のプロダクトとは異なる脆弱性が存在する可能性があります。例えば、生成 AI が不正に操作されて、偽のコンテンツを生成されたり、機微情報が漏洩したりするなど、深刻な影響が生じる可能性が指摘されています。 これらの脅威への対策は、生成 AI に関わるプロダクトを開発する企業や組織にとって重要な課題となっています。生成 AI のセキュリティ対策については、さまざまな組織や団体からセキュリティフレームワークが提案されてきています。このブログでは、OWASP が生成 AI アプリケーションにおける主要な 10 のセキュリティ脅威をまとめた OWASP Top10 for LLM Applications を参照しながら、AWS 上で生成 AI アプリケーションを設計・開発する方が考慮すべきポイントやリスクシナリオを概説します。 OWASP Top10 for LLM Applications は 2024 年 11 月にVersion 2025 が公開 されました。生成 AI の技術や活用が進むにつれて脅威も変化します。このブログでは、以前の Version との差分などに触れながら、具体的な事例や対策方法をご紹介します。生成 AI を安全に活用していくためのヒントが見つかるはずです。ぜひ最後までお読みください。 Amazon Bedrock を用いた基本的な生成 AI アプリケーションのアーキテクチャとコンポーネント AWS 上で構成される生成 AI アプリケーションをベースに OWASP Top 10 for LLM Applications の考慮事項を考えられるように、まずは基本的な生成 AI アプリケーションのアーキテクチャについて説明します。 図 1: 基本的な生成 AI アプリケーションのアーキテクチャの例 構成要素となるコンポーネントの例 以下で、図 1 の基本的な生成 AI アプリケーションのアーキテクチャで扱われているサービスをご紹介します。 Amazon Cognito ：ユーザーがアプリケーションを利用する前に認証を行います。 生成 AI アプリ：ユーザーに対してウェブのインターフェースを提供します。またユーザーのリクエストを処理するために、各コンポーネントとの一連のやり取りをオーケストレーションします。一例として静的コンテンツを Amazon Simple Storage Service (Amazon S3) へホスティングし Amazon CloudFront で配信し、動的コンテンツについては Amazon API Gateway で API としてリクエストを受け付けサーバーレスの AWS Lambda で処理をするように構成する場合があります。または仮想サーバーの Amazon Elastic Compute Cloud (Amazon EC2) やコンテナ実行環境の Amazon Elastic Container Service (Amazon ECS) を利用したウェブサーバやアプリケーションサーバを構成する場合もあります。 Amazon DynamoDB ：ユーザーの会話履歴を NoSQL のデータベースに保存します。 Amazon Bedrock ： 大規模言語モデル (Large Language Model：LLM)：ユーザーのリクエストを基に回答を生成する大規模言語モデルです。 ナレッジベース：LLM が事前学習していない (LLM 自体には学習させたくない) ユーザー固有の情報を生成 AI アプリケーションが利用できるようにするために、他のデータソースとの接続をマネージドに提供します。 埋め込みモデル：データソースに含まれるテキストなどの情報の埋め込みを行いベクトルデータに変換します。 ベクトルデータベース：埋め込みモデルで変換されたベクトルデータを保存し、ユーザからのリクエストに基づいてベクトルデータベース内を検索します。例として Amazon OpenSearch Service などがあります。 Amazon S3：LLM が事前学習していないユーザー固有の情報を生成 AI アプリケーションが利用できるようにするために、ユーザー固有の情報を保管するデータソースです。 生成 AI アプリケーションの動作 事前準備： a. 事前にアプリケーションで利用するユーザー固有の情報を S3 バケットへ格納しておきます。 b. ナレッジベースを S3 がデータソースとするように構成し、データを同期します。これにより S3 バケットに含まれる情報が埋め込みモデルによって処理されます。 c. 埋め込みモデルによって処理された情報はベクトルデータベースである OpenSearch Service へ保管されます。 アプリケーションのデータフロー： ユーザーはアプリケーションにアクセスすると Cognito にリダイレクトされ、認証を行います。 ユーザーはチャットベースのインターフェース上で、リクエストをプロンプトとして記入し送信します。 (過去のチャット履歴を参照するような処理をしている場合) アプリケーションは認証情報に含まれるユーザー ID から過去のチャット履歴を照会し、内容を取得します。 アプリケーションはユーザーのプロンプトに関連する情報を検索するために、プロンプトの文言をナレッジベースで検索します。この動作の過程でユーザーのプロンプトは埋め込みモデルでベクトル化され、ベクトルデータベース上で検索されます。これによりユーザーのプロンプトに関連性の高い情報を効率的に検索することが可能です。結果、アプリケーションはユーザーのプロンプトに関連性の高い情報と、その情報のメタデータ (ファイル名、ファイルのパスなど) を取得します。 アプリケーションは [2] で取得したユーザーのプロンプト、[3] で取得した会話履歴、[4] で取得した関連性の高い情報とそのメタデータを LLM に入力し、LLM の推論結果を取得します。 [5] で取得した LLM の推論結果をユーザーに返答します。 OWASP Top 10 for LLM Applications の概要と更新点 OWASP Top10 for LLM Applications では生成 AI アプリケーションの 10 の主要な脆弱性と、それぞれの脅威の概要やリスクシナリオが各項目ごとに示されています。2023 年 10 月に Version 1.1 が公開されていましたが、2024 年 11 月には Version 2025 がリリースされました。 前回の Version  と比べてどのような変更がなされたのでしょうか。図 2 に変更点を独自に整理した内容を記載します。 図 2: OWASP Top 10 for LLM Applications の Version 1.1 と Version 2025 の変更点比較 まず、注目すべきは順位の変化です。以前の Version では 6 位だった「機微情報の漏えい」が 2 位にランクアップしています。一方で、1 位の「プロンプトインジェクション」は変わっていません。 新たな項目として、「LLM07:2025 システムプロンプトの流出」、「LLM08:2025 ベクトル化と埋め込みの脆弱性」の 2 つが追加されました。「システムプロンプトの流出」は、ユーザーの入力のようなユーザープロンプトとは別に、本来は生成 AI アプリケーションの内部で制御に使用されるプロンプト (システムプロンプト) が不正に流出し、悪用される可能性のある脆弱性です。システムプロンプトには機微情報が含まれていたり、不適切な出力を生み出さないような出力を制御する内容が記載されている可能性があるため、システムプロンプトの適切な利用や管理が重要になります。 また、「ベクトル化と埋め込みの脆弱性」は、Retrieval Augmented Generation (RAG) を使用する生成 AI アプリケーションにおけるセキュリティリスクです。RAG では、事前学習済みの言語モデルとベクトル化された外部のデータソースを組み合わせることで、応答の性能と文脈の関連性を高めています。しかし、ベクトルや埋め込みの生成、保存、検索の方法に脆弱性があると、悪意のある行為 (意図的または非意図的) によって有害なコンテンツの注入、モデル出力の操作、機微情報へのアクセスなどが可能になる可能性があります。 OWASP Top 10 for LLM Applications の脆弱性と生成 AI アプリケーションとのマッピング OWASP Top 10 for LLM Applications の各脆弱性を AWS 上で構成する生成 AI アプリケーションで考えられるように、図2 のアーキテクチャ上にマッピングしてみましょう。 図 3: OWASP Top 10 for LLM Applications の各項目のマッピング 今回例示しているような生成 AI を活用したチャットボットのようなシンプルなアプリケーションであっても、各考慮事項がアーキテクチャ上のコンポーネントを幅広くとらえていることが図 3 からも分かります。 本ブログでは、この中から、特に Version 2025 で新たに追加された、LLM07:2025 システムプロンプトの流出と、LLM08:2025 ベクトル化と埋め込みの脆弱性について着目し深堀します。この 2 点以外も重要な観点であり Version 1.1 から内容もアップデートされていますが、引き続き「 OWASP Top 10 for LLM を活用した生成 AI アプリケーションの多層防御セキュリティ設計 」の内容が参考になります。必要に応じてご活用ください。  Version 2025 で追加された新たな考慮事項 LLM07:2025 システムプロンプトの流出 システムプロンプトの流出のリスクとは、モデルの動作を制御するために使用されるシステムプロンプトに、本来第三者に閲覧されるべきではない機微情報が含まれたり、システムプロンプトに記載されるルールやユーザーの役割や権限、フィルタリングなどのセキュリティ制御を他者に知られてしまうことです。開発者はシステムプロンプトに機微情報を含めるべきではなく、セキュリティ制御として使用すべきではないことを理解することが重要です。 システムプロンプトの例として、GitHub で公開されている generative-ai-usecases-jp (通称: GenU) のサンプル実装で記載されている いくつかのユースケースでのシステムプロンプト を例として確認してみましょう。 文章要約ユースケース あなたは文章を要約する AI アシスタントです。 最初のチャットで要約の指示を出すので、その後のチャットで要約結果の改善を行なってください。 翻訳ユースケース 以下は文章を翻訳したいユーザーと、ユーザーの意図と文章を理解して適切に翻訳する AI のやりとりです。 ユーザーは <input> タグで翻訳する文章と、<language> タグで翻訳先の言語を与えます。 また、<考慮してほしいこと> タグで翻訳時に考慮してほしいことを与えることもあります。 AI は <考慮してほしいこと> がある場合は考慮しつつ、<input> で与えるテキストを <language> で与える言語に翻訳してください。 出力は <output> {翻訳結果} </output>の形で翻訳した文章だけを出力してください。 それ以外の文章は一切出力してはいけません。 システムプロンプトの流出における、予防と緩和戦略は主に 2 点になります。1 つ目は、API キー、認証キー、データベース情報、アプリケーションの権限構造などの機微情報をシステムプロンプトに含めることを避けてください。権限を分離し、機微情報にモデルが直接アクセスしないよう外部で管理することが望ましいです。 Amazon Bedrock Converse API の Tool Use (function calling) では モデルが直接ツールを利用することなく、ユーザー側 (アプリケーション) でツールの実行を行うことが可能です。また Amazon Bedrock Agents では Action Group として Lambda 関数を指定し、モデルには関数の実行権限だけを与え、動的な処理を実装することも可能です。2 つ目は、モデルの厳格な動作の制御にシステムプロンプトを使用することは可能な限り避けることが推奨されます。システムプロンプトを明らかにしないように学習されたモデルもありますが、現時点でモデルが常にこれを遵守する保証はありません。モデルが期待に沿った動作をしているかどうかを判断するための独立した仕組みを用意することが望ましいです。これらは一般にガードレールと呼ばれ、例えば自社で開発する生成 AI アプリケーションが有害なコンテンツを生成していないかの検出と防止はモデルの外部で行うべきです。 Amazon Bedrock Guardrails のコンテンツフィルターでは、有害なコンテンツの判定が可能です。マルチモーダルにも対応しており、 テキストデータに加えて画像の検出にも活用可能 です。 (筆者注) Amazon Bedrock Guardrails は 2025 年 1 月 16 日時点で 公式には英語、スペイン語、フランス語のみをサポートしており 、他の言語でテキストコンテンツを評価すると、信頼できない結果になる可能性があります。テストデータで検証し、実装方法をご検討ください。 LLM08:2025 ベクトル化と埋め込みの脆弱性 RAG を使用する生成 AI アプリケーションの考慮事項として、不適切なアクセス制御や 反転攻撃 (モデルをリバースエンジニアリングする攻撃) によるデータの流出、ナレッジの競合、データの汚染、モデルの振る舞いへの影響などがあります。これらに対する予防・緩和戦略として 3 つの観点を掘り下げてみます。 アクセス制御： ユーザー固有の情報の保護のために適切なアクセス制御が必要です。ここでは AWS アカウントと RAG の 2 つの観点で考えてみましょう。まずは AWS アカウントについて、関係者を洗い出してみます。生成 AI アプリケーション開発者はもちろん、精度評価や改善を行うデータサイエンティスト、マルチアカウント環境の管理者や監査人などです。次にユーザー固有の情報が含まれるコンポーネントを特定します。S3 や OpenSearch、DynamoDB、またモデル呼び出しのログを記録する場合はログを格納する Amazon CloudWatch Logs や S3 などです。これらを踏まえ、アイデンティティベース、あるいはリソースベースのポリシーを活用し適切にアクセス制御を行います。厳格にアクセス制御を行うことが難しい場合、代わりに Amazon GuardDuty のような脅威検出サービスを使って S3 バケットへの異常な振る舞いや脅威を検知したり、 S3 や DynamoDB のデータに対するアクセスを AWS CloudTrail のデータイベントとして取得し、データに対するアクセスを追跡できるようにしておくことも考えられます。 続いて、ユーザーの所属する部署などに応じて参照可能なデータのみを RAG のコンテキストとして扱うケースを考えてみます。この場合、ユーザーやユーザーが所属する部署などの識別子を Cognito から取得したトークンから確認し、適切に参照する情報を制御できる必要があります。 ナレッジベースのマルチテナントに関する考察（英語） や メタデータを用いたフィルタリング をご参考いただいたり、ナレッジベースの代わりに ユーザーに応じたアクセス制御をサポートしている Amazon Kendra を利用することも考えられます。 データのバリデーションとデータソースのリスク評価： RAG で参照するデータのバリデーションを適切に行うことで、ユーザー固有の情報に含まれる個人情報などの流出から保護します。一例として、S3 にデータを格納する際に個人情報をマスクする前処理を行うパイプラインを構成しているケースがあります。データがアップロードされるとパイプラインが自動で起動し、文書の中から個人情報に該当する氏名や電話番号、メールアドレス、社員番号などの情報がマスクされてから、ナレッジベースが参照する S3 バケットにデータが格納されます。これにより、アプリケーションを通して個人情報が公開されるリスクを低減します。 またデータソースのデータが安全に利用できるものであるかリスク評価を行うことが重要です。例としてナレッジベースのデータソースタイプとして Web クローラーを活用する場合、参照先が信頼できる情報ソースなのか十分にリスク評価する必要があります。特に参照する Web サイトが任意の第三者が任意の記載を行うことができる場合、データの汚染を引き起こし、それが悪意あるプロンプトを含んでいる場合に間接的なプロンプトインジェクションが生じる可能性があります。 ログの取得と評価・分析： 悪意あるプロンプトやナレッジの競合などモデルの振る舞いに影響となる要因を特定し対処するために、ログの取得と評価や分析を行います。一例として、ナレッジベースに対して実行された処理にて、どのような情報を取得したかアプリケーションでログとして出力するように構成できます。また、ユーザーの入力と最終的にモデルが生成した出力は、アプリケーション上、あるいはモデル呼び出しのログ記録でログ取得ができます。アプリケーションが意図しない応答をしていることが分かった場合、ログを調査することでどのユーザーが行ったことなのか、意図しない応答を引き起こしたプロンプトがユーザーの入力と RAG で参照した情報のどちらに含まれていたのかを追跡できます。またアプリケーションの開発体制にデータサイエンティストが入ることで、ログの評価・分析を行う場合があります。 RAGAS などを用いて RAG の精度評価を行い、検索時と生成時のどちらに課題があるかを切り分け、分析に基づくパラメータのチューニングやアプリケーションの改修など RAG の改善活動を行います。 このような予防緩和戦略を取り入れ、図 1 のアーキテクチャの例をアップデートしたものが図 4 となります。 図 4: ベクトル化と埋め込みの脆弱性に対する予防緩和戦略の実装例 まとめ 本ブログでは生成 AI アプリケーションにおける主要な 10 のセキュリティ脅威をまとめた OWASP Top10 for LLM Applications で挙げられている脅威の概要について触れ、特に Version 2025 で新たに追加されたシステムプロンプトの流出とベクトル化と埋め込みの脆弱性について記載しました。本内容が生成 AI アプリケーションの開発に関わられている皆様の参考になれば幸いです。 著者について 片山 洋平 (Yohei, Katayama) は AWS Japan のパブリックセクターのソリューションアーキテクトです。主に医療機関をはじめとしたヘルスケア業界のお客様のソリューション構築の支援を行なっています。週末は登山を嗜んでいます。     藤浦 雄大 (Yuta Fujiura) は AWS Japan のプロフェッショナルサービス本部所属のセキュリティコンサルタントです。生成 AI セキュリティリードを担当し、生成 AI セキュリティや責任ある AI のトレーニング、アセスメント、ガイドライン策定などでお客様をご支援しています。また生成 AI に関するブログ翻訳も数多く担当しています。余暇はブロックでオリジナル作品を作っています。

お客様は常に AWS の支出をよりよく理解する方法を探しています。多くのお客様が、特定のチームがどのくらい支出をしているか、特定のアプリケーションの実行コストはどのくらいか、様々な組織的な取り組みにおける節約の機会はどのくらいあるかについて知りたがっています。リソースレベルのコストの透明性を提供できることは、AWS クラウドへの移行の大きなメリットです。このような詳細な可視化を実現するカギは、包括的かつ組織的なタグ付け戦略の実装と適用です。 コスト配分戦略を実装するためのツール この投稿では、組織のコスト意識を向上させるタグ付け戦略を定義・実装・適用するために使用できるツールと、その使用方法について紹介します。最初のツールは AWS Cost Explorer です。これは、組織の支出に関するより深い洞察をもたらす説得力のある可視化により、AWS のコストや使用状況の分析や管理を可能にしてくれます。Cost Explorer を使用すると、日次で更新される過去 12 か月間のコストデータを取得できます。日付範囲、アカウント、サービス、リージョンなど、様々なパラメーターでデータをフィルタリングできます。 コスト使用状況データを詳細にするために、リソースに「タグ」を適用することができます。タグはキーと値のペアで、AWS リソースにメタデータを追加したり、タグ値ごとにコスト使用状況データを要約したりすることができます。タグはキーと値のペアであるため、組織に合った名前 (キー) を作成したり、ビジネスにとって意味のある値を使ったりできるような柔軟性があります。たとえば、組織において “CostCenter” を使用してコストを追跡することができます。AWS では、CostCenter というキーのタグをリソースに割り当て、そこにそのリソースの課金先となる CostCenter を表す値 (例：CostCenter=12345) を割り当てることができます。 また、タグポリシーおよびサービスコントロールポリシーと呼ばれる、 AWS Organizations の 2 つの機能についても見ていきます。これらのポリシーは遡及的には機能しないため、過去に作成された “タグの付与されていないリソース” を識別しやすくするためには AWS Tag Editor (タグエディタ) を使用します。そして、 AWS Config は継続的な戦略のコンプライアンスをサポートします。 タグ付け分類の作成 タグを使用するとさらに詳細な情報を得られるため、組織レベルでのタグ付け戦略と、それを適用する方法を確立することが重要です。ベストプラクティスとしては、タグの分類を定義して、すべてのビジネスユニットに推奨されるタグを整理するところから始めるのがよいでしょう。タグは様々な目的でリソースに関連付けることができます。技術タグは識別情報を提供します。オートメーションタグは開始/停止時間をスケジュールしたり、リソースを自動的にバックアップする必要がある場合に役立ちます。ビジネスタグは所有者やビジネスコンテキストを追加し、セキュリティタグはデータセキュリティ上の懸念事項を定義するのに役立ちます。以下にこれらの例を示します。 図 1. タグの分類とタイプの例 すべてのビジネスユニットに適用されるタグ付け戦略を実装する際には、その戦略が適切にドキュメント化されているのを確認することが重要です。以下に組織で必須となるタグの詳細を記載したタグ分類ドキュメントの例を示します。 図 2. 必須タグ例のタグ分類 タグ付け戦略のアプローチ 組織は通常、タグ付け戦略を実装する際に 2 つの異なる方法に従います。すべてのポリシーをトップダウンで実装するか、子組織が自分でタグを定義できるようにするかのどちらかです。どちらにも長所と短所があります。トップダウン型のアプローチは、定義と設定に時間がかかりますが、組織全体のコストの可視性が向上する可能性があります。一方、子組織が自分でタグ付け要件を柔軟に決定できるようにすると、俊敏性は向上しますが、組織全体の AWS 支出を分析しようとする際に一貫性が失われる可能性があります。 これら 2 つの戦略を組み合わせることが、おそらく最も効果的なアプローチでしょう。たとえば、組織の最上位レベルでは、下の図に示すように、すべてのチームと組織ユニットが従うビジネスタグ付け戦略を適用できます。そのあとで、個々のユニットは自主性と柔軟性をもって追加となるビジネス固有のタグを実装することができます。 許容できるキー値を定義することで、タグ分類ドキュメント内のタグをさらに細かく指定できます。たとえば、今回の CostCenter タグの例では、ビジネスユニットまたは部門を表す “Two Digit Division (2 桁の部門)” を追加しました。また、コストを追跡するために、プロジェクト、アプリケーション、チーム、その他のグループを表す “Four Digit Code (4 桁のコード)” も追加しました。これにより、各ビジネスユニットは、リソースを適切に識別するための適切なタグ付け規則を明確に把握できます。タグ付け戦略を明確に定義してドキュメント化したら、適用に移ることができます。 図 3. CostCenter タグ例のタグドキュメント タグ付けポリシーの適用 タグ付け戦略が組織全体に浸透したら、AWS Organization 内で必須のタグの設定を開始できます。目標は、AWS リソースの作成時に、新たな標準化されたタグ付けポリシーを適用することです。ここでの例では、特定のタグに必須の ”事前定義済みの値“ がない場合、Amazon EC2 インスタンスの作成は拒否されます。今回は、カスタム CostCenter タグを使用します。 1. まず最初に、管理アカウントの AWS Organizations コンソールに移動し、[Policies (ポリシー)] を選択します。次に [Tag policies (タグポリシー)] をクリックします。 図 4. AWS Organizations ポリシーページのタグポリシー部分 2. 次に、上記の例で定義した値を使用して、CostCenter タグのタグポリシーを作成します。このポリシーを Amazon EC2 インスタンスに適用し、組織によって指定された値でなければ、CostCenter タグを使用してリソースを作成することを禁止するようにします。 画面上部のタグポリシーに名前を付けます。ポリシーの説明を追加することもできます。この画面の中央では、ポリシー自体にタグを追加して、誰がポリシーを作成したかを追跡できます (ポリシーが適用されるリソースではなく、ポリシー自体にタグを付けることに注意してください)。“Visual editor (ビジュアルエディタ)” タブ内でタグキーを定義できます。ここでの例ではそれを “CostCenter” としています。 CostCenter タグキーの下にある、大文字と小文字の区別を確認するボックスにもチェックを入れます。これにより、タグの大文字と小文字が区別される (case-sensitive) ため、タグキーフィールドで指定されたとおりに正確に入力する必要があります。 “Allowed values (許容される値)” セクションで、CostCenter タグキーに使用できる値を指定するボックスにチェックを入れます。次に、上記の例で定義した CostCenter 値のリストを追加します。 最後に、“Resource types enforcement” (リソースタイプの強制)” セクションで、”Prevent noncompliant operations for this tag (このタグの非準拠操作を防止します)” をクリックします。リストから “ec2:instance” を選択します。これにより、Amazon EC2 インスタンスに CostCenter タグが含まれていて、かつタグ付けポリシーに基づく有効な値がない場合には、Amazon EC2 インスタンスが起動されなくなります。 図 5. タグポリシー設定ページ 3. この新しく作成されたポリシーを組織全体で確実に適用するには、組織単位 (OU) にポリシーをアタッチする必要があります。そのためには、タグポリシーページに戻り、先ほど作成した “CostCenterTagPolicy” を選択します。次に “Actions (アクション)” を選択し、“Attach policy (ポリシーのアタッチ)” をクリックします。 図 6. 既存のタグポリシーページでのポリシーのアタッチ 4. 次の画面では、新しいタグポリシーが特定の組織単位 (OU) にアタッチされていることを選択して確認できます。 図 7. 組織単位 (OU) へのタグポリシーのアタッチ 5. それでは、Amazon EC2 コンソールに移動して、適切な CostCenter タグ値を指定せずに新しい Amazon EC2 インスタンスを起動してみましょう。 図 8. EC2 コンソールでのタグ付けポリシーのテスト 6. 必須のタグポリシー値を指定せずにこのインスタンスを起動しようとすると、エラーが表示されます。 図 9. 許可されていない CostCenter タグ値であることにより EC2 の起動に失敗 タグポリシーが設定されたため、タグポリシー内の CostCenter タグに設定した値パラメーターに従わないリソースを、組織が起動できなくなりました。ただし、これでは CostCenter タグキーそのものがない場合はリソースを起動できてしまいます。それを防ぐためには、サービスコントロールポリシー (SCP) を利用します。 タグの適用の強化 ユーザーが特定のタグを含めていない場合はリソースを起動できないようにするなど、タグ付けの適用に関するより厳しいポリシーが必要な場合は、 サービスコントロールポリシー (SCP) を使用できます。SCP により、組織内のすべてのアカウントで使用可能な最大権限を一元的に制御できます。SCP を使用すると、CostCenter タグなどの特定のタグが含まれていない場合に特定のアクションを拒否できます。 このタイプの SCP の例を以下に示します。作成すると、先程作成したタグ付けポリシーをアタッチしたのと同じように、特定の組織単位 (OU) にアタッチできます。 SCP を定義する には、管理アカウントの AWS Organizations ページに移動し、“ポリシー (Policies)” をクリックしてから “サービスコントロールポリシー (Service Control Policies)” をクリックします。 図 10. CostCenter タグを必要とするサービスコントロールポリシー (SCP) の例 注: SCP の使用は完全にオプションであり、特にタグコンプライアンスに関するガバナンスのレベルを高めることができます。ただし、SCP の使用は慎重に行うべきです。SCP の設定は既存のリソースに影響を与える可能性があります。たとえば、必須である CostCenter キーが設定されていないリソースのオートスケーリングプランでは、SCP がスケーリング動作を妨げる可能性があります。既存のリソースを持つ組織に SCP を導入する場合は、この点を必ず考慮してください。 タグコンプライアンスの理解 この新しいタグ付けポリシーのコンプライアンスを継続的に検証するには、AWS Config を使用できます。AWS Config には、AWS アカウントの AWS リソースの設定の詳細が表示されます。AWS Config ルール、特に “required-tags” ルールを使用すると、リソースに必要なタグがあるかどうかをチェックできます (つまり、Amazon EC2 インスタンスに、先程作成した CostCenter タグが付いていることを確認できます)。 タグコンプライアンスをモニタリングするには、AWS Config コンソールページに移動し、左側のナビゲーションメニューから “ルール (Rules)” を選択します。 図 11. AWS Config ルールセクション画面 新しいルールを追加する方法の詳細はこのブログの範囲外ですが、required-tags 組み込み設定ルールの使用方法の詳細は AWS Config ドキュメント に記載されています。AWS Config と SCP により、組織全体にタグ付けポリシーをさらに適用し、長期的なコンプライアンスを検証できます。 しかし、新しいタグ付けポリシーに準拠していない可能性のある既存のリソースについてはどうでしょうか？これらのリソースをコンプライアンスに準拠させるにはどうすればよいでしょうか？ タグエディタによるタグなしリソースの識別 タグ付けポリシー実装の最後のステップは、過去にタグなしでプロビジョニングされたリソースに対処することです。これはタグエディタを使うことで実行できます。 タグエディタを使用するには、AWS マネジメントコンソールに移動し、“Resource Groups & Tag Editor” を検索してクリックします。 次に、左側のナビゲーションにある “タグ付け (Tagging)” の下にある “タグエディタ (Tag Editor)” をクリックします。 タグエディタページで、まずリソースを検索したいリージョンを選択します。この例では “All regions” を検索します。 次に、検索するリソースタイプを設定します。この例では、Amazon EC2 インスタンスを検索します。 最後に、検索するタグを入力します。ここでは、CostCenter タグが付いていないすべての Amazon EC2 インスタンスを検索します。 条件を満たすリソースのリスト、つまり CostCenter タグのついていない、すべてのリージョンのすべての Amazon EC2 インスタンスのリストが表示されます。結果を CSV にエクスポートし、組織内の従業員に通知して対応を依頼できます。 図 12. タグエディタの設定画面 注: タグエディタは単一のアカウントでのみ実行でき、組織レベルでは実行できません。組織内の各アカウントでタグが付いていないリソースを識別するには、各アカウントでタグエディタを使用する必要があります。 コスト配分タグを有効化する 新しく実装したタグ付け戦略を使って Cost Explorer でのコスト分析を開始する前に、コストと使用状況に関するレポート作成用にタグを有効化する必要があります。“請求とコスト管理” コンソールを開いて “コスト配分タグ (Cost Allocation Tags)” を選択し、新しく作成した CostCenter タグを有効化します。リソースにタグを付けてタグを有効化するまで、AWS Cost Explorer にはこれらのタグを適用した結果は表示されません。 図 13. ”請求とコスト管理“ コンソールでのコスト配分タグの有効化 AWS Cost Explorer での支出の可視化と分析 タグ付け戦略を実装し、“請求とコスト管理” コンソールでタグを有効化すると、AWS Cost Explorer を使用して個々のコストセンターのコストを分析できます。この例では、個々のコストセンターの支出をサービスごとに表示できます。 図 14. Cost Explorer レポート (フィルターなし) Cost Explorer を使用してコストを確認する際、タグ付けされているはずなのに以前の期間のコストには反映されておらず混乱してしまうことがあるかもしれません。タグ付けは遡って適用されることはなく、(タグ付け以降の) 将来のコストと使用状況のレポートにのみ正確に反映されます。 Cost Explorer を使用すると、適切な CostCenter タグが関連付けられていないアカウントのうち、最も支出が多いアカウントを分析できます。これを行うには、ディメンションを “連結アカウント (Linked Account)”、タグのフィルターを “CostCenter”、およびタグ値を “タグキーがありません :CostCenter (No tag key: CostCenter)” に設定した Cost Explorer レポートを作成します。 図 15. Cost Explorer レポート (“タグキーがありません :CostCenter” フィルターを適用した場合) このようなレポートを使用すると、組織はこれらの (タグ付けされていないリソースのある) 特定のアカウントが新しいタグ付け戦略を実装できるよう支援できます。時間が経過とともに、コストセンター別に組織の AWS 支出の詳細な内訳を示す追加の Cost Explorer レポートを作成できるようになります。 図16. Cost Explorer レポート (ディメンションを “CostCenter” タグにした場合) まとめ このブログでは、AWS アカウント内のタグ付けされていないリソースの識別を含む、組織のタグ付け戦略の定義・実装・適用に役立つプロセスの概要を説明しました。これが完了すると、Cost Explorer を使用して、これらのタグを使用して AWS のコストと使用状況を可視化・理解・管理・レポートすることができます。その結果、組織のコストに対する可視性と認識が高まるだけでなく、個々のビジネスユニットのコストの結果責任が促進され、クラウドコストの最適化とビジネス価値の実現にプラスの影響を与えることができます。 TAGS: AWS Billing Console , AWS Cost Explorer , AWS Organizations , Tagging Policies , Track and Allocate Ryan Doty Ryan Doty は、ニューヨークを拠点とする AWS のソリューションアーキテクトです。革新的でスケーラブルなソリューションを設計するためのアーキテクチャガイドラインを提供することで、米国北東部のエンタープライズカスタマーが AWS クラウドの採用を加速できるよう支援しています。ソフトウェア開発とセールスエンジニアリングのバックグラウンドを持つ彼は、クラウドが世界にもたらす可能性にワクワクしています。仕事以外では、コンピューターゲームをしたり、リバプール FC を応援したりすることが大好きです。 Bert Zahniser, CISSP, CCSP Bert Zahniser は、フィラデルフィア地域を拠点とする AWS のシニアソリューションアーキテクトです。IT インフラストラクチャで 30 年以上の経験があり、情報セキュリティに重点を置いています。彼はクラウド採用の強力な提唱者であり、クラウド移行中のお客様がセキュリティとガバナンスを念頭に置いて AWS でソリューションを設計および実装できるよう支援しています。仕事以外では、野球やアイスホッケーが好きで、ゴルフやクラフトビールの醸造所を訪れるのが大好きです。 Vishal Manan Vishal Manan は、シアトルを拠点とする AWS のスペシャリストソリューションアーキテクトです。お客様が Graviton プロセッサ (クラウドでは arm64) を使用して、費用対効果やパフォーマンスが高く、持続可能な EC2 コンピューティングインスタンスを採用できるよう支援しています。プラットフォームソフトウェア開発のスキルとコンサルティングのバックグラウンドを AWS クラウドに活かせることに興奮しています。仕事以外では、父親であること、料理をすること、ゴルフをすること、ハイキングをすることが大好きです。 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文は こちら です。

2024 年 11 月 7 日に、デジタル庁主催で「AI ハッカソン、アイデアソン」が実施され、AWS も参加しました。デジタル庁から公開されているブログは以下をご覧ください。 デジタル庁記事 1 デジタル庁記事 2 デジタル庁記事 3 本イベントには 2 つの主要な目的がありました。1 つ目は、AI エンジニアと行政職員の間にある「生成 AI で実現できること」に対する認知ギャップを解消すること。2 つ目は、人口減少に伴う行政職員の人手不足に対して、AI 技術を活用した実用的なソリューションを開発し、行政サービスの質を維持・向上させることです。本イベントには、AWS の他に東京都、GovTech 東京、CSP 各社様が参加され、デジタル庁や、イベントに協力機関として参加した東京都の職員の方々から寄せられる要望に対して生成 AI を活用し、合計 38 個のプロトタイプを作成しました。 AWS の技術で実現する行政デジタルトランスフォーメーション (以降 DX) 私たち AWS のエンジニアチームは、Amazon Bedrock をはじめとする最新の生成 AI 技術を活用し、デジタル庁・東京都の行政職員から提示された業務上の課題に対するプロトタイプの開発に取り組みました。AWS は、GUI で AWS のサービスを操作できる AWS マネジメントコンソールや、 Generative AI Use Cases JP (略称：GenU) を用いることで、5 時間という短時間でも業務課題の解決可能性を検証できることが明らかになりました。 AWS が作成したソリューション AWS が作成したソリューションの内今回は 3 つのソリューションをご紹介します。 パワポの研修資料（デジタル庁風）を自動作成するアプリ (デジタル庁職員からの依頼) パワポの研修資料 (デジタル庁風) を自動作成するアプリ (デジタル庁職員からの依頼) 議会答弁案作成のサポート (東京都職員からの依頼) 1. パワポの研修資料 (デジタル庁風) を自動作成するアプリ 業務の課題 府省庁横断トレーニングではデジタル庁の職員が研修資料を自前で作成していますが、元の情報が頻繁に更新されたり新機能が追加されたりするので、その都度どこが変わったのかを確認し作り直しています。 AWS のソリューション 作りたい内容の説明書、または WEB サイトの URL をプロンプトに入れると、パワーポイントの研修資料を生成するソリューションです。生成する資料は、デジタル庁で現在使っている研修資料の構成・フォーマットを参考に作成するように調整しています。 デモ動画 より詳細な映像はこちら 再現方法 生成 AI に Marp というライブラリに従う形式で Markdown テキストを出力させています。アプリケーションのインターフェイスとして GenU を使用しています。 参考 システムプロンプトの例は以下を参照してください。 あなたはスライドを生成する Marp を支援する AI アシスタントです。与えられた文章とルールに従い、Marp が出力可能な Markdown を出力してください。 <rules> * 説明は一切不要です。これは絶対のルールです。冒頭に Here's the Markdown output based on the input: などの接頭語を指定してはいけません。 * \`\`\`yaml のような接頭語も一切不要です。 * Markdown のテキストだけ生成してください。 * --- によって、スライドが分割されます。適切な粒度で分割してください。 * 標準で gaia の theme を使用します。指定があればそれ以外も使用してください。 * 図、表などの構造化された文章、箇条書きの文章や数式、画像、アイコンを使用してください。 * 画像は全体のスライド数に対して３割程度の使用として多用しないでください。 * 背景画像は 100% の比率にします。 * ソースコードを記述する場合、1 ページあたり、15 行以内にしてください。 * 画像は上下左右、自由に配置してよいものとしますが、文脈に沿っており人間が見やすい配置を意識してください。 * 挿入する画像は以下のものを使用してください。 * アプリの画面説明の場合 <画像の URL> * 人が助け合うイラスト画像 (横幅 30% くらいで) <画像の URL> * 人がカードとスマートフォンを持っている様子のイラスト画像 (横幅 30% くらいで) <画像の URL> * 人がパソコンを使用しているイラスト画像 (横幅 30% くらいで) <画像の URL> * スマホに QR コードが写っているイラスト画像 (横幅 30% くらいで) <画像の URL> * サブタイトルには必ず「Amazon Bedrock によるスライド生成」を含めてください * 背景画像は指定されない限り白にしてください。 * １枚目は背景画像として<画像の URL> を使用します。 * 最後から 2 枚目のアンケートページの背景画像は<画像の URL> を使用します。文字は黒色にしてください。 * 最後のスライドでは背景画像として<画像の URL> を使用します。 * ２枚目のスライドには目次を入れてください。 * 最後のスライドには文字を一切記載してはいけません。最後から１つ前のスライドにまとめを書いてください。 * 重要な文字列はデジタル庁のブランドに従う青色 rgba (21,28,232,255) にしてください。 </rules> Markdown の先頭に書く theme などの Local directives のサンプルは以下のとおりです。 theme などはファイル全体に適用されます。スライド１枚ずつに記述してはいけません。 特に指定がなければ以下のフォーマットに従ってください。 <format> --- theme: gaia class: lead paginate: true backgroundColor: #fff ---  <!-- header: "スライドのテーマ" ---> ヘッダーを指定 # タイトル ### サブタイトル ---  <!-- header: "スライドのテーマ２" ---> ヘッダーを指定 ## タイトル 内容 --- <!-- header: "スライドのテーマ３" ---> ヘッダーを指定 ## タイトル 内容 </format> また、スタイルを変更する場合は以下のようにしてください。 <styling-example> --- theme: base --- <style> section { background: yellow; } </style> # Tweak style through Markdown You would see a yellow slide. </styling-example> スコープ付きスタイル また、<style scoped>を通じてスコープ付きインラインスタイルもサポートしています。 style 要素に scoped 属性がある場合、そのスタイルは現在のスライドページにのみ適用されます。 スライドページごとにスタイルを微調整したい場合に便利です。 <scoped-styling-example> <!-- Global style --> <style> h1 { color: red; } </style> # Red text --- <!-- Scoped style --> <style scoped> h1 { color: blue; } </style> # Blue text (only in the current slide page) --- # Red text </scoped-styling-example> 推奨される基盤モデル Claude 3.5 Sonnet (v1)、Claude 3.5 Sonnet (v2)、Claude 3 Sonnet、Claude 3 Haiku 担当した AWS ソリューションアーキテクト Daisuke Awaji、Shota Kishimoto 2. デザインガイドラインに準拠したイラストの自動生成 業務の課題 デジタル庁が元々もっているアイコンやグラフィックを少し変えたいときにデザインガイドラインに準拠したイラストの作成業務を生成 AI を活用して出来ないかという要望をデジタル庁職員から受けました。 AWS のソリューション Amazon Bedrock のイメージプレイグラウンドにてイラストを自動生成しました。 ソリューション① : より詳細な画像生成映像 1 はこちら ソリューション② : より詳細な画像生成映像 2 はこちら 再現方法 ソリューション① : 新規画像生成：Amazon Bedrock のイメージのプレイグラウンドより作成しました。以下のプロンプトを参考にしてください。 プロンプト例：illustration, QR code, smartphone, left hand, simple color, white background, device edge color #1D2A68, high contrast 3:1 ratio, user interface components visible, graphical objects clear, minimalist style, clean design, no background items, focus on essential elements ソリューション② : 既存画像からのバリエーション生成：同じくイメージのプレイグラウンドより、 デジタル庁で公開しているイラストレーション を既存画像としてアップロードして作成しました。 推奨される基盤モデル ①、②ともに、Amazon Titan Image Generator v2 担当した AWS ソリューションアーキテクト Naoki Miyaguchi、Yozo Suzuki 3. 議会答弁案作成のサポート 業務の課題 議会における答弁作成業務では、職員がこれまでの会議録や施策情報を手作業で確認・整理していますが、AI を活用することにより、業務の効率化が期待されています。例えば、過去の会議録やホームページから関連情報を自動抽出し、根拠資料を明確にした情報を AI が提示することで、職員が行う答弁案の作成に関する業務を AI がサポートし、より効率的で質の高い業務の実現に資することが考えられます。 AWS のソリューション Amazon Bedrock Agents でウェブ検索エージェント作成し、検索結果を元に回答を出力させました。 再現方法 GenU で「 検索エージェントのデプロイ 」を行い、SearchAgent を作成し、以下のプロンプトを実行します。 あなたは優秀な東京都のデジタルサービス局長のアシスタントです。 以下 3 つの作業を実施してください。 作業内容をすべて確認してから出力してください。 必ず"マークダウン形式"で出力してください。 1: 以下の「質問文」を解釈して、インターネット上にある東京都に関する情報から質問文に関連する以前の取り組みと事実確認を行なってください。 2: 1 で調査した内容を基に、局長が議会答弁の際に話す「これまでの取り組み」をまとめる必要があります。 調査した内容から「詳細」「簡潔」「フォーマル」の 3 パターンでそれぞれ 100 字以内でまとめてください。まとめる際には以下に示した「キーワード」を意識してください。 3: 局長の最終的なチェックを助けるために、情報源にしたリンクを提示してください。 キーワード：窓口改革 質問文：東京都は、二〇二五年度を目標に、デジタルガバメント都庁の基盤構築を目指し、シン・トセイ戦略を推進してきました。 この戦略の下で、これまでアナログ業務のデジタル化などを進め、業務プロセスの抜本的な見直しを図ってきたと認識しています。 行政のデジタル化は、都民がオンラインで簡単に行政手続を行える環境を整えることを目的としていますが、オンライン手続だけでなく、 窓口での対応も同様に重要であり、今後も、都民が便利で快適に行政サービスを利用できる環境の整備を進め、デジタル化と対面サービスの双方において質の高い行政運営を実現することが必要です。 デジタルをフルに活用し、窓口における利用者視点に立った改革を一層進めるべきと考えますが、見解を伺います。 推奨される基盤モデル Claude 3.5 Sonnet (v1)、Claude 3.5 Sonnet (v2)、Claude 3 Sonnet、Claude 3 Haiku 担当した AWS ソリューションアーキテクト Masahiro Tabuki、Yohei Katayama、Kohei Hayashi まとめ デジタル庁は、この AI ハッカソン、アイデアソンの経験を活かし、これを一過性のイベントではなく、組織に根付いた持続可能な取り組みへと発展させることを目指しています。具体的には、AI で業務改善を求める職員が即座に恩恵を受けられる環境の構築、AI エンジニアと現場ニーズの効果的なマッチング、そして職員の AI エンジニアスキル育成を重点的に進めていく計画です。また、今回開発されたプロトタイプについては、イベント限定のものとせず、職員に安定して届け、継続的に改善できる体制を整備する方針とのことです。 今回実証された生成 AI ソリューションの活用は、行政分野における業務効率化や品質向上に寄与するだけでなく、医療、教育、防災など他の幅広い分野への展開可能性も示唆しており、社会全体の DX を加速する重要な一歩となりました。AWS は、このようなデジタル庁の取り組みを技術面から継続的に支援し、行政サービスのデジタル変革を加速させることを目指しています。 補足 Generative AI Use Cases JP (略称：GenU) : 生成 AI の業務活用に興味はあるもの、「どのように始めれば良いのか」「セキュリティ面は大丈夫なのか」といった課題を抱えている方も多いのではないでしょうか。GenU は、そんな課題を解決するために AWS Japan の有志を中心に開発された生成 AI アプリケーションです。Amazon Bedrock や Amazon Kendra などの AWS のサービスを活用し、チャットボットや RAG (検索拡張生成)、画像生成など、簡単にすぐに業務で活用できるさまざまなユースケースを 1 つのアプリケーションとして提供しています。 著者について 岸本尚大 (Shota Kishimoto) AWS Japan の Prototyping Solutions Architect として、公共部門のお客様を担当しています。プロトタイピングという名前の通り、実際に動作するプロトタイプ (アプリケーション) を、AWS を用いて作成し、お客様に技術提供する形でご支援を行っています。

（この記事は Cross-region disaster recovery with Amazon FSx for NetApp ONTAP を翻訳したものです。） お客様にとって、データの保護は最優先事項です。地震などの自然災害や、特定の地域（リージョン）で発生する技術的災害による被害を軽減するために、複数のリージョンにデータを継続的に複製するようなディザスタリカバリ（DR）戦略を検討する必要があるかもしれません。 Amazon FSx for NetApp ONTAP は、NetApp ONTAP ファイルシステム上に構築されたフルマネージドファイルストレージサービスです。レプリケーションサーバーを別途構築することなく、AWS リージョン 間のデータのレプリケーションをすぐに利用できます。さらに、Amazon FSx for NetApp ONTAP は、AWS リージョン間のデータの非同期レプリケーションにも対応しており、パイロットライトとウォームスタンバイの両方の DR 戦略に適用することができます。これらの特性は、DR 戦略の最適化に役立ちます。 本ブログでは、 FSx for ONTAP ファイルシステム を利用したレプリケーションターゲットを、シングルアベイラビリティゾーン（AZ）構成にする場合とマルチ AZ 構成にする場合とで、それぞれのトレードオフについて説明します。また、ファイルシステム間のデータレプリケーションを実現する機能である NetApp SnapMirror の前提条件とパフォーマンスへの影響についても解説します。さらに、FSx for ONTAP の NetApp SnapMirror 機能を使用した、AWS リージョンをまたがる DR シナリオのデータレプリケーションについても説明します。SnapMirror は、複製されたデータの圧縮とデータ重複排除により、帯域幅とストレージの使用量を軽減することも可能です。本ブログでは、ビジネスクリティカルなデータの可用性とリカバリ速度を向上するための知識を、身につけていただくことを目的としています。 クロスリージョンデータレプリケーションのソリューション概要 FSx for ONTAP は、AWS またはオンプレミスで動作する Linux、Windows、macOS といった幅広いクライアントからアクセスできる、機能豊富で高速かつ柔軟な共有ファイルストレージを提供します。FSx for ONTAP は、AZ 間または AWS リージョン間でのデータの非同期レプリケーション機能によって、DR の要件を簡単に満たすことができます。詳細については オフィシャルドキュメント を参照してください。 デスティネーション（宛先）ファイルシステムは、ソース（送信元）のファイルシステムで発生した更新データを指定したスケジュールに従って反映・更新されるので、必要となればいつでも利用することができます。さらに、セカンダリ側の AWS リージョンのボリュームは、読み取り専用でマウントできます。レプリケーションは最短 5 分間隔にスケジュール設定できますが、実際のレプリケーション間隔は RPO（Recovery Point Objectives）、RTO（Recovery Time Objectives）、およびパフォーマンスの考慮に基づいて慎重に検討する必要があります。 シングル AZ FSx for ONTAP ファイルシステムへのクロスリージョンDR シングル AZ 構成の FSx for ONTAP は、AZ 内での高い可用性と耐久性を提供するように設計されています。シングル AZ ファイルシステムを構成する AWS 基盤は、単一の AZ 内の別々のフォールトドメインに存在しています。マルチ AZ オプションの場合と同様に、インフラストラクチャは継続的に監視され、必要に応じてコンポーネントの交換が自動的に行われ、フェイルオーバーは通常数秒以内に完了します。 マルチリージョンを採択した場合、セカンダリ AWS リージョンの FSx for ONTAP ファイルシステムをシングル AZ 構成にすることができます。この構成では、マルチ AZ オプションと同じ利便性とデータ管理機能を享受しつつ、ストレージコストを 50%、スループットコストを 40%、それぞれ削減できます。 図のように、シングル AZ のファイルシステムをセカンダリの AWS リージョンに 配置します 。そのうえで、プライマリ AWS リージョンにあるファイルシステムのソースボリュームと、セカンダリリージョンのシングル AZ ファイルシステムのデスティネーションボリュームとの間に SnapMirror 関係を確立します。 図1: セカンダリリージョンにシングル AZ ファイルシステムを配置して Snap Mirror DR を実現 マルチ AZ FSx for ONTAP ファイルシステムへのクロスリージョン DR マルチ AZ 構成の FSx for ONTAP は、データを複数のアベイラビリティゾーンにわたってレプリケートします。ファイルシステムは、単一 AZ の損失に耐えられるように設計されています。その上でさらに、RPO/RTO 要件に応じて、クロスリージョンを採択できます。この場合、アプリケーションは、マルチリージョンでアクティブ・アクティブ または ウォーム・スタンバイ方式で展開されます。 図2: セカンダリリージョンにマルチ AZ ファイルシステムを配置して Snap Mirror DR を実現 マルチ AZ のファイルシステムを、セカンダリの AWS リージョンに 配置します 。その上で、プライマリ AWS リージョンの FSx for ONTAP のソースボリュームと、セカンダリ AWS リージョンのマルチ AZ FSx for ONTAP のデスティネーションボリュームとの間に SnapMirror 関係を確立します。 マルチ AZ 構成とシングル AZ 構成の比較で考慮すべき点は、ビジネスに対する FSx for ONTAP の可用性です。マルチ AZ 構成では、アベイラビリティゾーン内での FSx for ONTAP に障害が発生しても、サービスにダウンタイムは発生しません。一方シングル AZ の場合は、ダウンタイムが発生する可能性があります。 プライマリ AWS リージョンでリージョン障害が発生してセカンダリAWS リージョンにフェイルオーバーする場合、セカンダリ AWS リージョンでデータを処理するために、運用チームがセカンダリAWSリージョンの FSx for NetApp ONTAP に対して手動で操作を完了する必要があります。したがって DR を採用する場合は、RPO 及びRTO に対するビジネス成果と、その成果を達成するためのコストも含めて検討する必要があります。 FSx for ONTAP の SnapMirror 概要と考慮事項 NetApp SnapMirror は、BCDR（Business Continuity and Disaster Recovery：事業継続性とディザスタ リカバリ）を目的として NetApp ONTAP に組み込まれたソリューションで、ONTAP スナップショットテクノロジーをベースにしています。SnapMirror を使用すると、ソース側の FSx for ONTAP ファイルシステムからデスティネーション側の FSx for ONTAP ファイルシステムにデータを複製できます。SnapMirror を使用すると、次のことが実行されます。 ソース側で、ボリュームのスナップショットが作成される ソース側のスナップショットが、ディスティネーション側にコピーされる。このプロセスによって、オンラインで、読み取り専用で、かつ最新更新時のソース側と同じデータをもつボリュームが作成される デスティネーション側のボリュームが、指定したスケジュールに従って、ソースの増分変更を反映して更新される SnapMirror 関係が確立されると、デスティネーションボリュームは、スナップショット、ボリューム設定、ONTAP ストレージ効率化機能がソースボリュームと同一なレプリカとなります。DR テストを実施する際は、フェイルオーバーにあたって SnapMirror 関係を解除します。これにより、デスティネーションボリュームは書き込み可能になりますが、プライマリ の ONTAP ボリュームには影響を及ぼしません。 ソースファイルシステムとデスティネーションファイルシステム間の SnapMirror 関係を構築する手順については、 Migrating to FSx for ONTAP using NetApp SnapMirror を参照してください。また、DR サイトでデスティネーションボリュームを読み書き可能な形でマウントする手順については、 Cutting over to Amazon FSx を参照してください。 SnapMirror レプリケーショントラフィック SnapMirror はクラスター間エンドポイントを使用して、ファイルシステム間でデータをレプリケートします。ファイルシステムを構成する各ノードに1つずつクラスター間エンドポイントが作成されますが、マルチ AZ 構成の FSx for ONTAP の場合、各クラスター間エンドポイントは、それぞれ異なる AZ に存在します。そのため、FSx for ONTAP ファイルシステムへのレプリケーション中にプライマリ側の単一の AZ で障害が発生した場合も、スタンバイ AZ 上のノードへフェイルオーバーが行われた後レプリケーションを継続することができます。このような動作によって、AZ 障害においてもプライマリの AWS リージョンでのファイルサービスは継続され、かつ DR を目的としたセカンダリ AWS リージョンへの SnapMirror レプリケーションへの影響もありません。 SnapMirror ネットワークの前提条件 SnapMirror ネットワークには、次の前提条件があります。 ONTAP のプライマリファイルシステムとセカンダリファイルシステム間のネットワーク接続性を確保する必要があります。これは、VPC ピアリング、または VPC を AWS Transit Gateway に接続することで実現できます。 SnapMirror では、ポート 10000、11104、11105 を使用します。FSx for ONTAP の ENI に関連付けられたセキュリティグループが、対向のファイルシステムからのトラフィックを許可する必要があります。 プライマリのファイルシステム上のすべてのクラスター間エンドポイントは、セカンダリのファイルシステム上のすべてのクラスター間エンドポイント と通信できる必要があります。 ソース側のファイルシステムの名前と IP アドレスは、デスティネーション側ファイルシステムの hosts テーブル（vserver services name-service dns hosts）にエントリーが存在する必要があり、その逆も同様です。DNS 名を使用してSnapMirror 関係を確立する場合は、相互に名前解決可能でなければなりません。 FSx for ONTAP ファイルシステム間の SnapMirror レプリケーションの互換性については、NetApp ONTAP ドキュメンテーションセンターの「 Compatible ONTAP versions for SnapMirror relationships 」の「 Unified Replication relationships 」のセクションを参照してください。 まとめ この投稿では、Amazon FSx for NetApp ONTAP が、異なる AWS リージョン間での非同期データレプリケーションによって、DR ソリューションを簡単に提供する方法について説明しました。また、デスティネーションファイルシステムに、シングル AZ とマルチ AZ 、それぞれの構成を使用する際の考慮点についても説明しました。ここで引用した設計に基づくと、シングル AZ 設計はよりコスト効率の高い設計ですが、マルチ AZ 設計と同レベルの耐障害性はありません。DR ソリューションを構築する場合は必ず、ビジネス要件とコストのトレードオフを踏まえて検討する必要があります。SnapMirror によるレプリケーションを使用すれば、RPO を最短5分、RTO を 10 分以内を実現できます。 Amazon FSx for NetApp ONTAP は、フルマネージドサービスのメリットをすべて享受できるため、データ管理が簡素化され、オンプレミスインフラストラクチャの運用コストを削減できます。さらに、NetApp の SnapMirror を使用してデータ保護戦略を強化すれば、エンタープライズレベルのデータ保護が実現し、データを確実に保護して利用できるようになります。ぜひ Amazon FSx for NetApp ONTAP のこれらの機能を活用して、運用を効率化していきましょう。 Joe Dunn Joe は、インフラ設計とビジネス基盤のクラウド移行に 20 年以上の経験をもった、金融サービスの AWS プリンシパル・ソリューション・アーキテクトです。AWS 製品やサービスを利用したソリューションを提供することで、金融サービスのお客様が AWS クラウド上でイノベーションを起こせるよう日々支援しています。 Amit Borulkar Amit は、耐障害性と拡張性の高いクラウドアーキテクチャの構築支援に従事する、AWS プリンシパル・ソリューション・アーキテクトです。また、ノースカロライナ州立大学でコンピュータサイエンスの修士号を取得しています。 翻訳は、ソリューションアーキテクトの田中が担当しました。

アマゾン ウェブ サービス ジャパン合同会社 : (左) 近藤 祐丞 、(右) 飯田 哲夫 みなさん、こんにちは。アマゾン ウェブ サービス ジャパン合同会社 AI / ML 事業開発チームの近藤 祐丞です。 AWS では生成 AI サービスの Amazon Bedrock を始めとして、お客様の生成 AI 活用を支援する様々なサービスや機能を提供しています。AWS の年次イベント AWS re:Invent 2024 においても、生成 AI 活用を支援する サービスアップデート を発表しました。 生成 AI は、様々な業界や業種のお客様へと徐々に浸透しており、今後もその流れは進んでいくと感じています。 本日は、金融領域の事業開発チームに所属する飯田 哲夫さんに、お客様と接する中で感じた「金融業界の生成 AI 活用動向」についてインタビューしていきます。 金融領域のお客様の生成 AI 活用の現状 近藤：お時間いただき、ありがとうございます。まずは飯田さんの現在のお役割をお聞きかせください。 アマゾン ウェブ サービス ジャパン合同会社 : 近藤 祐丞 飯田：はい、私は金融領域における事業開発として、金融ビジネスにインパクトがある AWS の使い方やユースケースをご提案しています。また、お客様がクラウドを活用する上で、コンプライアンスや規制に関する課題の払しょくも支援しています。 近藤：ありがとうございます。私も AI / ML の事業開発として仕事をしていますが接する業界は様々です。本日は飯田さんが専門的に関わっている金融領域における生成 AI の活用の現状についてお伺いさせてください。 飯田：まず 2023 年から振り返ると、金融領域のお客様が自然対話型 AI サービスの利用を通じて、 生成 AI の有用性、課題などを認識されたフェーズ だったと思います。認識された課題として、ハルシネーション (=事実に基づかない情報を生成する現象) が挙げられます。 2024 年では、いかに生成 AI を業務の中に組み込み、 組織として横断的に生成 AI を活用していくかを検討するフェーズ へと進まれた印象です。 Amazon Bedrock の観点では、サービスの機能が拡充したことから、 Anthropic 社の Claude モデルを中心に業務での活用が進みました。そうした中で、 セゾンテクノロジー様の事例 のように、 複数の生成 AI モデルから最適なものを選択する 流れも生まれたと思います。一方で、 生成 AI の活用を検証段階から実ビジネスへ進めようとされる中で、業務ユースケースの特定に悩まれる お客様は多かったと感じます。 近藤：2024 年は生成 AI 活用の観点で大きく動きが変わったということですね。飯田さんの仰る通り、2024 年は同様のことを私も感じています。AWS には、お客様のプロジェクトの加速を支援するために、システムのプロトタイプの開発を支援する Prototyping Program プログラムがあります。私は本プログラムを金融領域のお客様に提案する機会も多いのですが、2023 年と比較して 2024 年から金融領域のお客様でご活用いただくケースが大きく増えました。 元々 AWS 上でアプリケーション / システムを稼働いただいている金融領域のお客様は多いと思いますが、既存のシステムとの連携で AWS の生成 AI サービスを求める声は多いですか？ 飯田：はい、その観点でのご要望は非常に多いです。金融領域では AWS をクラウドの標準環境としているお客様が多くおられ、そうしたお客様は AWS 上でアプリケーションやデータ蓄積基盤を構築されています。業務アプリケーションと連携したり、業務データを活用する際には、AWS の環境に閉じているとコントロールしやすいため、そこから Amazon Bedrock をご利用いただくケースが多いです。 Amazon Bedrock であれば、複数の生成 AI モデルを API 経由で呼び出せるだけでなく、 複数モデルの評価機能 、 モデルのカスタマイズ 、 データのセキュリティ / プライバシーの担保 が実現可能です。そのため、 生成 AI 活用におけるプラットフォーム として、実ビジネスでご利用いただくケースが 2024 年後半くらいから増え、広がっていると思います。 近藤：正に Amazon Bedrock は生成 AI モデルを呼び出すだけでなく、生成 AI アプリの構築・運用をサポートする幅広い機能を提供するサービスです。生成 AI 活用のプラットフォームとしてご利用いただくケースは今後も増やしていきたいですね。 金融領域における生成 AI 活用のユースケース 近藤：金融領域のお客様の生成 AI 活用では、どういったユースケースが印象的ですか？ 飯田：特徴的なユースケースとしては、 営業支援、広告審査、コールセンター業務、不正取引検知 などは挙げられます。 アマゾン ウェブ サービス ジャパン合同会社 : 飯田 哲夫 営業支援では、企業情報の状況分析や過去の取引履歴の集約などを通じて、営業活動の生産性向上を支援 しています。具体的な事例としては、 三菱 UFJ 銀行様の事例 が挙げられます。法人顧客への営業活動で最適な提案を行うには、ニーズの断片的な把握、提案スキルのルール化の難しさから、個人の技量に依存する傾向になるという課題を三菱 UFJ 銀行様は抱えておられました。そこで法人顧客への営業活動に生成 AI を活用することで、多面的かつ複合的な企業情報の分析の実現に取り組まれています。また、各営業個人が保有しているナレッジもデータとして繋ぐことにより、組織的な提案力の強化も図っています。組織全体の営業生産性の向上に繋がっている事例です。 広告審査では 野村ホールディングス様の事例 が挙げられます。本事例では AWS を活用した生成 AI を広告審査業務に適用しています。野村ホールディングス様では広告物への審査を厳しくしている一方で、審査対応の業務負担は多く、対応する人材が不足するという課題がございました。そこに 生成 AI を活用することで、広告物が金融商品取引法やガイドライン、自社規定に沿っているかを生成 AI がチェック して、 業務負荷軽減を実現 しています。最終的に広告審査を通すかどうかは人が判断する運用にしていますが、生成 AI が業務効率化に貢献する素晴らしい事例だと思います。金融機関様の中には生成 AI の活用を慎重になる場面もあるかと思いますが、 生成 AI だけに全てを任せるのではなく、人の判断と生成 AI を組み合わせた参考になる事例 だと感じます。 コールセンター業務では、例えば SBI生命保険様の事例 が挙げられます。本事例では経験の浅いオペレーターでも経験豊富な方と同レベルのサービス提供をするために、生成 AI を用いて保険商品や契約関連の手続き書類を検索可能にする文書検索システムを構築しています。このシステムでは RAG (= 検索拡張生成) の構成が用いられており、回答の正確性を担保しています。金融機関様のコールセンターの業務では、オペレーターが大量の社内ドキュメントや金融商品の知識を基に正確な回答を提供することが求められので、 スムーズな顧客対応やオペレーターの教育期間の短縮化 に貢献しています。 不正取引検知では、海外事例にはなりますが、 Nasdaq 様の事例 では不正取引の検知およびその調査業務の中で生成 AI を利用しています。Nasdaq 様は IT 関連企業などの割合が多い Nasdaq 市場の証券取引所を運営しており、市場の公平性や信頼性の確保が求められます。そのための監視業務として、担当アナリストが不審な活動の自動アラートを受け取ると、レビューを行い、更なる詳細な調査が必要かどうかを判断します。一方で、アラートのレビューや詳細調査は、様々な外部データソースから膨大な情報を分析する必要があるため、非常に負担の大きいプロセスです。Nasdaq 様は本プロセスに生成 AI を活用することで、関連情報の分析を迅速に実施できるようにしています。 担当アナリストの調査時間などの短縮 に貢献している素晴らしい事例です。 また、 AWS パートナー様が自社のプロダクト/ソリューションに生成 AI を機能として組み込み、金融機関様の課題解決を支援するケース も増えています。例えばデータ分析サービスを提供する ナウキャスト様 は、証券・保険領域の営業活動とコンプライアンス業務を効率化する「Finatext Advisory Assist」を提供しています。本ソリューションの中に Amazon Bedrock  経由で呼び出した生成 AI を組み込むことで、商談におけるコンプライアンスのチェックや商談の振り返りを AI がサポートする機能を提供しています。 サービスを利用するユーザーの営業活動の効率化を支援 しており、プロダクト / ソリューションを通じた営業支援の事例です。 その他の事例では、 野村総合研究所様 がコンタクトセンター向けのプラットフォーム「CC@Home」の AI ソリューション 「TRAINA」 シリーズに、 Amazon Bedrock 経由で呼び出した生成 AI を組み込むことで機能強化を図っています。本ソリューションは主に金融業界を中心に展開されており、コールセンター業務の効率化を目的に提供されております。その中で「FAQ 検索・表示」「通話内容の要約」「VOC の分析」の機能を生成 AI 活用によって強化されています。こちらの事例も、AWS パートナー様の自社ソリューションへの生成 AI 組み込みを通じて、 コールセンター業務の効率化を支援 している事例です。 近藤：金融領域での特徴的なユースケースですね。金融領域では生成 AI にどういったことが求められますか？ 飯田：やはりセキュリティを気にされるケースは多いです。生成 AI のモデルがデプロイされているリージョンや生成 AI に用いるデータの保管場所が国内であることは重要です。それ以外にもデータへのアクセス制御や通信の暗号化、セキュリティポリシーなど、生成 AI を社内横断的に利用する際には高いセキュリティ水準が求められます。また、検証段階から実ビジネスに生成 AI の活用を進めていく動きに伴い、生成 AI 活用のユースケースごとのセキュリティ担保ではなく、 生成 AI 活用の標準基盤としてセキュリティの担保 が求められています。 Amazon Bedrock では国内リージョンが利用可能なことに加えて、 Amazon Bedrock Guardrails のような生成 AI 活用基盤としてセキュリティポリシーを担保する機能などが備わっており、よりクリティカルな業務領域で生成 AI 活用の検討を進める金融機関様が増えてきています。 近藤：生成 AI モデルやデータを活用する際のセキュリティが非常に重要ということですね。最近では様々な業界で業界特化型の生成 AI モデルを開発されるケースを聞く事が増えているのですが金融業界ではいかがでしょうか？ 飯田：今後の可能性として、 お客様独自の生成 AI モデル、もしくはお客様の独自データを用いたチューニング はケースとして増加すると思います。例えば一般的な QA のように、公開データを学習した生成 AI モデルをそのまま利用することで問題ない領域もありますが、一方で金融業界では特殊な用語や自社独自の背景を学習させないと価値を発揮しにくい特殊な業務も存在しますので、そうした領域ではお客様独自の生成 AI モデル、もしくはお客様の独自データを用いたチューニングが求められてくると思います。 お客様独自の生成 AI モデルを開発する場合は、「 AWS ジャパン生成 AI 実用化推進プログラム 」を始めとするプログラムや Amazon SageMaker HyperPod などのサービスでご支援可能です。AWS 独自のチップとして AWS Trainum や AWS Inferenentia などの選択肢を揃えており、これらをご利用いただくことで深層学習と生成 AI トレーニングのパフォーマンス向上やコストを抑えながら推論の高速化に貢献できます。また、お客様の独自データを用いたチューニングにおいても、 Amazon Bedrock ではモデルのカスタマイズを支援する機能が備わっています。 生成 AI の今後について 近藤： AWS re:Invent 2024 では Amazon Nova という生成 AI モデルも発表しており、 Amazon Bedrock 上で様々な生成 AI モデルを選択肢としてご提供しています。今後、世の中でも生成 AI モデルの選択肢が増える中で、金融領域ではどのような流れを予測していますか？ 飯田：生成 AI の利用が広がるにつれ、 業務目的に合わせた適切なモデル選択 と、 コスト最適化 の重要性が高まると思います。生成 AI はモデルによって性能やコストが当然異なるので、ユースケースによって生成 AI モデルを使い分ける形になるかと思います。また、生成 AI では エージェント という考えが広まってきており、それを活用した業務支援もユースケースとして出てくると思います。例えば、「ある領域における投資判断のための情報を集めてください」と生成 AI にお願いすると、アプリケーション / システム側ではこの指示を複数のタスクに分解して自動的に実行していくということが実現されると思います。 AWS では Amazon Bedrock Marketplace を発表しており、 100 を超える生成 AI のモデルにアクセス可能 になりますので、色々な選択肢の中から最適な生成 AI モデルを利用するという場面ではご支援できると思います。他にも Amazon Bedrock のエージェント が機能として実装されており、単なるモデル利用に留まらず、 生成 AI 活用を支援するプラットフォーム としてご支援できるかと思います。 近藤：ありがとうございます。これから生成 AI 活用を検討される金融機関様に対して、どのような観点でお話されていますか？ 飯田：これから生成 AI 活用を検討される金融機関様においては、 これまでに多くの金融機関様が行ってきた検証や実装例を参考にしながら、解決したいビジネス課題を明確にしていくこと をお薦めしたいと思います。 AWS ではユースケース特定からモデル選定、運用体制構築までを支援するサービスを提供していますので、生成 AI 活用の検討の際は是非ご相談いただければと思っています。 ——————————————————————————— 更なる生成 AI の情報をお探しの場合は こちら をご覧ください。 本ブログの執筆はアカウントマネージャー 尾形 龍太郎が担当しました。

本稿は、2024 年 12 月 3 日に AWS Migration & Modernization Blog で公開された “ Exporting network configuration data with Import/Export for NSX ” を翻訳したものです。 Import/Export for NSX は、新しい AWS オープンソースツールで、VMware Cloud on AWS (VMC-A) またはオンプレミスの VMware Cloud Foundation (VCF) の環境から、VMware NSX 構成を ZIP ファイルにエクスポートできます。エクスポートした ZIP ファイルを、 Amazon Q Developer transformation capabilities for VMware にインポートすることができます。Q Developer は、NSX 構成を、VPC、サブネット、セキュリティグループなどの AWS ネイティブな構成要素に変換します。このブログ記事では、NSX-T 構成のエクスポートプロセスについて説明します。また、Q Developer で新しくリリースされた VMware 機能については、 概要ブログ と 使用開始ガイド を公開しています。 Import/Export for NSX の前提条件 Python3 – ローカル環境に Python3 (バージョン 3.10 以上) を ダウンロードしてインストール します。 Import/Export for NSX – GitHub で利用可能 Git をご存知であれば、リポジトリをローカル環境にクローンします。 git clone https://github.com/awslabs/import-export-for-nsx.git 図 1 : git clone コマンドを表示したターミナルウィンドウ Git を利用していない場合は、 リリースページ から最新のリリースを ZIP 形式でダウンロードし、ローカル環境で解凍します。 Python3 をインストールした後は、Python の仮想環境を有効にすることを検討してください。必須ではありませんが、推奨されるベストプラクティスです。Python の仮想環境機能を使用することで、このプログラムで使用されるライブラリがローカル環境上の既存のバージョンと競合するのを防ぐことができます。初めて Python をインストールしたために競合がない場合でも、仮想環境の使用方法を学ぶことで、より多くの Python プロジェクトを使用する意欲が湧くかもしれません。仮想環境を使用することで、将来の技術検証がより容易になります。 cd import-export-for-nsx python3 -m venv .venv source .venv/bin/activate cd import-export-for-nsx python -m venv venv .\venv\Scripts\Activate.ps1 図 2 ： Python 仮想環境のコマンドを表示したターミナルウィンドウ 必要な Python ライブラリをインストールします。 pip3 install -r requirements.txt python -m pip install -r .\requirements.txt コマンドを実行すると、スクリーンショットでは出力が省略されていますが、このようにインストールされます： 図 3 ： Python ライブラリのインストール状況を示すターミナルウィンドウ 重要 ：VMware Cloud on AWS からエクスポートする場合は、次のセクションをお読みください。オンプレミスの NSX からエクスポートする場合は、その次のセクションにお進みください。 ステップ 1a – VMware Cloud on AWS から NSX 設定をエクスポートする VMware Cloud on AWS トークン を生成します。このトークンには、VMware Cloud on AWS Administrator ロールと VMware Cloud on AWS NSX Cloud Admin ロールが必要です。 VMware Cloud on AWS SDDC から組織 ID と SDDC ID を取得します。これらは SDDC のサポートタブで確認できます。 環境変数を作成します。 EXP_source_refresh_token="xxxxx" export EXP_source_refresh_token EXP_source_org_id="xxxxx" export EXP_source_org_id EXP_source_sddc_id="xxxxx" export EXP_source_sddc_id $env:EXP_source_refresh_token = "xxxxx" $env:EXP_source_org_id = "xxxxx" $env:EXP_source_sddc_id = "xxxxx" ステップ 1b – オンプレミス NSX から NSX 設定をエクスポートする /config_ini フォルダ内の vmc.ini を探します。 auth_mode の値を local に、 nsx_endpoint_type の値を nsx に変更します。 図 4 : vmc.ini 設定ファイルを表示している Visual Studio Code の画面 NSX Manager の URL を確認します。また、ツールに NSX Manager の認証情報を入力する必要があります。VMware Cloud on AWS とは異なり、オンプレミスの NSX からエクスポートを行う場合は、管理者権限が必要ありません。読み取り専用の NSX 監査ユーザーを使用することができます。 環境変数を作成します。 EXP_srcNSXmgrURL=https://nsxmgr.fqdn.com export EXP_srcNSXmgrURL EXP_srcNSXmgrUsername="admin" export EXP_srcNSXmgrUsername EXP_srcNSXmgrPassword="password-for-admin" export EXP_srcNSXmgrPassword $env:EXP_srcNSXmgrURL = “https://nsxmgr.fqdn.com” $env:EXP_srcNSXmgrUsername = "admin" $env:EXP_srcNSXmgrPassword = "password-for-admin" ステップ 2 – エクスポートの実行 VMware Cloud on AWS からエクスポートする場合でも、オンプレミスの NSX からエクスポートする場合でも、同じコマンドを実行します。 python3 nsx_import_export.py -o export python ./nsx_import_export.py -o export エクスポートコマンドの開始と終了： 図 5 ：エクスポートコマンドの開始を示すターミナルウィンドウ 図 6 ：エクスポートコマンドの終了を示すターミナルウィンドウ プログラムが _json-export.zip で終わる名前の圧縮ファイルを /json ディレクトリに配置します。このファイルを Amazon Q Developer transformation capabilities for VMware で使用することができます。Amazon Q Developer transformation capabilities for VMware の詳細については、こちらの テクニカルウォークスルー をご参照ください。 クリーンアップ 環境をクリーンアップするには、以下の手順を実行します： 認証情報をメモリから消去するため、ターミナルウィンドウを閉じます。 /json ディレクトリ内にある  _json-export.zip で終わる名前の圧縮ファイルを削除します。 ツールを再度使用する必要がない場合は、プロジェクトフォルダー全体とコンテンツ全体を削除することができます。 まとめ Import/Export for NSX は、AWS のオープンソースプロジェクトで、オンプレミスまたは VMware Cloud on AWS の NSX 構成をエクスポートできます。このブログ記事では、GitHub で利用可能な Import/Export for NSX ツールを使用して、NSX の構成をエクスポートするためのステップバイステップガイドを提供しています。このクラウド移行の重要な側面を効率化することで、Amazon は VMware ワークロードの AWS への移行を加速・簡素化する革新的な顧客中心のソリューションを提供することへのコミットメントを示し続けています。私たちの言葉を信じるだけでなく、今すぐツールを試してみてください！ Amazon ではお客様から逆算して考えているため、このツールを使用する中でのフィードバックをお待ちしています。お客様のご意見は、私たちが常に最高のエクスペリエンスを提供できるよう、継続的な改善とイテレーションに役立てさせていただきます。 Patrick Kremer パトリック・クレマーは、VMware ワークロードの移行に特化したシニアスペシャリストソリューションアーキテクトです。2022 年に AWS に入社し、15 年以上にわたる VMware の経験を活かしてお客様のマイグレーションとモダナイゼーションを支援しています。AWS 認定ソリューションアーキテクトプロフェッショナルの資格を保有しており、教育とブログ執筆に情熱を注いでいます。 翻訳をソリューションアーキテクトの Furuya が担当しました。原文は こちら です。

本稿では、VPC リソースに対する AWS PrivateLink サポートを使用して、VPC やアカウントの境界を越えて、さらにはオンプレミス環境からも、共有リソースへのプライベートで安全かつ効率的な接続を実現する方法について探ります。また、SaaS プロバイダーとそのクライアントに特化した、新しい AWS PrivateLink の機能を実装するための一般的なユースケースと実装のベストプラクティスについても検討します。 AWS PrivateLink を使用すると、AWS パートナーは自社の Software-as-a-Service (SaaS) 製品を数千のクライアントの AWS アカウントに安全に公開でき、セキュアでプライベートな接続が保証されます。AWS PrivateLink の VPC エンドポイントはほとんどの SaaS 接続ニーズに対応していますが、一部のユースケースでは、ロードバランサーを介さずに共有リソースに直接接続する必要があります。このようなシナリオに対応するため、AWS は VPC リソースへの接続サポートを追加することで PrivateLink の機能を拡張しました。これにより、追加の Elastic Load Balancing インフラストラクチャを必要とせずに、共有リソースへの直接的で安全な接続を構成できます。AWS PrivateLink の VPC エンドポイントか Amazon VPC Lattice を使用して、VPC リソースにアクセスできます。両方のオプションで、VPC リソースに対するクロスアカウント機能が統合されています。 前提条件 AWSのネットワーキングの概念や Amazon Virtual Private Cloud (VPC) や AWS PrivateLink、VPC エンドポイント、Amazon VPC Lattice、VPC ピアリング、 AWS Direct Connect などのサービスについて知っていることを前提としています。これらサービスの定義に焦点は当てませんが、これらサービスの機能と、その機能を使用して VPC リソース向けの新しい AWS PrivateLink サポートを設定する方法について概説します。AWS PrivateLink と Amazon VPC Lattice を SaaS アプリケーションに活用する方法の詳細については、「 Building SaaS Services for AWS Customers with PrivateLink 」および「VPC Lattice サービスネットワーク内での SaaS サービス接続」といった記事を確認することをお勧めします。 VPC リソース向け AWS PrivateLink のサポート VPC リソース向けのプライベート接続は、VPC やアカウントの境界、およびオンプレミスインフラストラクチャを超えて、個々のリソースへの安全で一方向の接続を提供するように設計されています。特定のリソースを別アカウントとプライベートに共有する必要があるリソース所有者は、ロードバランサーを使用せずにこの接続を設定できるようになりました。これは、共有するリソースがデータストア (例えば、単一のデータベースノードやデータベースノードのクラスター)、または負荷分散型アーキテクチャに適さないリソースのクラスターである場合に役立ちます。VPCリソース向けの AWS PrivateLink のサポートでは、クライアントとリソース間の通信にプライベート IP を活用し、VPC 内のどのリソースをリソース消費者に公開するかを細かく制御することができます。 ローンチパートナー 私たちは、この機能を自社ソリューションに組み込んでいるいくつかの ISV パートナーと協力できることを嬉しく思います。 Grafana Labs: How to query private network data without an agent using AWS and Grafana Cloud Palo Alto Networks: Announcing Palo Alto Networks Cloud NGFW Integration with AWS PrivateLink – resource VPC endpoint ClickHouse: ClickPipes supports cross-VPC resource access on AWS! Neo4j: AWS PrivateLink and VPC Lattice Improve Cross-Account Resource Sharing for Neo4j DataStax: Securely Connecting to Astra DB with AWS Starburst: How Starburst secures your data in flight with AWS Informatica: Informatica Announces Broad Innovation Agenda for Analytics and GenAI Solutions, Built on AWS Redis: AWS VPC endpoints on Redis Cloud 仕組み 以下のコンポーネントにより、VPC リソースにアクセスするための AWS PrivateLink と Amazon VPC Lattice のサポートを設定できます。 リソースゲートウェイ ：共有リソースにアクセスするために、リソース所有者の VPC へのイングレストラフィックポイントを提供する新しい VPC の構成概念。 リソースコンフィグレーション ：共有したいリソースを指定することができます。単一のリソースを指定して単一のリソースコンフィグレーションを作成することも、複数の子リソースコンフィグレーションを含むグループリソースコンフィグレーションを作成することもできます。VPC 内の1つのリソースゲートウェイに複数のリソースコンフィグレーションを関連付けることができます。リソースコンフィグレーションは、 AWS Resource Access Manager (AWS RAM) を使用して、AWS Organization 内外の他アカウントと共有することができます。 リソースエンドポイント ：リソース消費者が共有リソースにアクセスするために使用できる新しいタイプの VPC エンドポイント。 VPC Lattice サービスネットワーク ：VPC またはアカウント間の接続を可能にし、サービス間通信に共通のセキュリティポリシーを適用する方法を簡素化する論理的なグルーピングメカニズムです。アカウント内にサービスネットワークを作成し、AWS RAM を使用して AWS Organization 内外のアカウントと共有することができます。 サービスネットワークエンドポイントと VPC アソシエーション ：VPC Lattice サービスネットワークの VPC エンドポイントにより、リソース消費者は自身の VPC を VPC Lattice サービスネットワークに接続することができます。サービスネットワークへの接続には、サービスネットワーク VPC アソシエーションを使用することもできます。接続オプションの選択に関するベストプラクティスについては、本稿の「知っておくべきこと」セクションで詳しく説明します。 私たちは、SaaS プロバイダーとそのカスタマーがこれらのコンポーネントを活用できるユースケースに焦点を当てています。VPC リソースの接続設定に関する詳細な手順例については、 このトピックに関する Jeff Barr のブログ記事 と AWS PrivateLink のドキュメント をご覧ください。 VPC リソースの利点 AWS PrivateLink とVPC Lattice の VPC リソースサポートは、リソース所有者とリソース消費者の両方に対して、以下の主要な利点を提供します。 リソース消費者は以下のことができます。 インターネット接続なしで VPC リソースにプライベートにアクセス ：リソース消費者は、インターネット接続 (例えば、インターネットゲートウェイや NAT ゲートウェイ) を使用せずに、VPC やアカウント、オンプレミス環境を横断して共有リソースにアクセスできます。 消費者主導のアクセスを維持 ：接続は一方向であり、接続はリソース消費者の VPC からのみ開始できます。 重複した IPv4 アドレスを持つリソースに簡単に接続 ：AWS PrivateLink と VPC Lattice の VPC リソースアクセスサポートにより、クライアントとリソースは重複した IP アドレスを持つことができます。 異なる IP バージョン をサポート ：VPC リソースへのクライアントアクセスは IPv4 と IPv6 の両方で構成でき、リソース消費者とリソース所有者間で異なる IP バージョンを使用できます。 オンプレミスクライアントからのアクセスを簡素化 ：リソース消費者は、 AWS Direct Connect または AWS Site-to-site VPN 経由でオンプレミスノードから別の VPC のリソースにアクセスできます。 1対多のアクセスを確立 ：リソース所有者がグループリソースコンフィグレーションを使用してリソースのグループを共有する場合、リソース消費者は単一の VPC エンドポイントを通じてリソースにアクセスできます。 リソース所有者は VPC リソースへのアクセスを共有でき、次のことができます。 特定の VPC リソースを選択的に構成および共有することでアクセスを制御 ：リソース所有者は、自身の VPC から特定のリソースを共有し、消費者がそれらのリソースにのみアクセスできるようにすることができます。リソース所有者 VPC 内の他リソースは消費者に公開されません。 必要な場合にのみロードバランサーを使用 ：リソース所有者は、消費者とリソースを共有するためにロードバランサーを構成する必要はありません。 オンプレミスにデプロイされたリソースを共有 ：リソース所有者は、Direct Connect / VPN 接続を活用することで、オンプレミスのデータセンターにあるリソースを共有できます。 同じリソースゲートウェイを通じて複数のリソースへのアクセスを許可 ：リソース所有者は、単一のリソースゲートウェイに複数のリソースを関連付けることができます。リソースはリソースゲートウェイと同じ VPC にある必要はありません。ただし、リソースゲートウェイを含む VPC は、関連するリソースコンフィグレーション内のリソースへの IP 到達性を持っている必要があります。 アクセスパターンを監視し、アプリケーション通信フローを詳細に可視化 ：リソース所有者は、誰が共有リソースにアクセスしているかを監視し、リソースに送信しているバイト数や接続数などを確認できます。 SaaS プロバイダー向け VPC リソースの使用例 1. SaaS プロバイダーがクライアントの VPC またはオンプレミス環境内のデータストアにアクセスする SaaS プロバイダーは、サーバーレスオファリングを実現し、クライアントのデータやシステムと統合するために、クライアントの VPC やオンプレミス環境内のリソースへのアクセスを必要とすることがよくあります。AWS PrivateLink の VPC リソースサポートにより、クライアント (リソース所有者) は自身の AWS アカウントにリソースゲートウェイをデプロイし、特定のリソースを SaaS パートナーと選択的に共有することができます。これにより、SaaS プロバイダーはクライアント管理の Network Load Balancer (NLB) を必要とせずに、必要なクライアントのリソースにアクセスできるようになり、両者の統合プロセスが効率化されます。 SaaS プロバイダー (リソースコンシューマー) 側では、この共有リソースへの接続は、次の 3 つのオプションのいずれかを使用して設定できます。 サービスネットワークエンドポイントの使用 AWS PrivateLink リソースエンドポイントの使用 サービスネットワークへの VPC 関連付けの使用 オプション a ：図1は、SaaS プロバイダー (リソース消費者) が、サービスネットワークエンドポイントを使用して、クライアント (リソース所有者) が共有する VPC リソースにアクセスする方法を示しています。このオプションでは、サービスネットワークエンドポイントがリソース消費者の VPC を彼らの VPC Lattice サービスネットワークに接続します。リソース消費者は自身の VPC 内に複数のサービスネットワークエンドポイントを作成できます。各サービスネットワークエンドポイントは、異なるサービスネットワークへのアクセスを可能にします。 複数のサービスネットワークを活用することで、SaaS プロバイダーは異なるクライアントと共有するリソースを論理的に分離することができます。ただし、単一のサービスネットワークを使用して複数の共有リソースにアクセスすることも可能です。 図1. VPC Lattice サービスネットワークに接続されたサービスネットワークエンドポイントを介してリソースにアクセスする SaaS プロバイダー オプション b ：図2は、SaaS プロバイダー (リソース消費者) が AWS PrivateLink リソースエンドポイントを活用して、クライアント (リソース所有者) が共有するリソースにアクセスする方法を示しています。このオプションでは、リソースエンドポイントがリソース所有者のリソースゲートウェイに直接接続します。単一のリソース消費者の VPC 内に複数のリソースエンドポイントを持つことが可能です。各リソースエンドポイントは、単一のリソースコンフィグレーションへの接続性を提供します。 図2. リソースエンドポイントを介してリソースにアクセスする SaaS プロバイダー オプション c : リソース消費者の3つ目のオプションは、サービスネットワーク と VPC の関連付けを作成し、VPC エンドポイントを個別に作成することなく、自身の VPC 全体からサービスネットワーク内の共有リソースにアクセスすることです。このオプションを使用する場合、消費者 VPC には1つのサービスネットワークのみを関連付けることができます。サービスネットワークと VPC の関連付けでは、VPC CIDR から IP アドレスを使用しないため、IP 管理が簡素化され、IP 利用が最適化されます。図3 は、オプション c のアーキテクチャ例を示しています。 図3. リソース消費者 VPC が VPC Lattice サービスネットワークに直接関連付けられている場合に、サービスネットワークと VPC の関連付けを介してリソースにアクセスする SaaS プロバイダー 2. クライアントがSaaS プロバイダーのアカウントやオンプレミスで管理するクラスターにアクセスする VPC リソースへのプライベート接続により、SaaS プロバイダーはクライアントに代わって個々のリソースまたはリソースグループを自社の AWS アカウント内でホストできます。SaaS プロバイダーは、これらのリソースを消費者のアカウント内の VPC エンドポイントを通じてクライアントに公開できます。これにより、クライアントは VPC ピアリングや Site-to-Site VPN、またはパブリックインターネットなどの必要以上に広範なネットワークアクセスを提供する可能性のあるネットワーク構成を必要とせずに、SaaS 管理のリソースにアクセスできます。リソース向け VPC エンドポイントを活用することで、SaaS プロバイダーはクライアントの管理オーバーヘッドを大幅に削減できます。これにより、リソース消費者が異なるアカウントの VPC間や、オンプレミス環境間の基盤となる接続メカニズムを設定・維持する必要がなくなります。SaaS プロバイダーは、既存のハイブリッド接続 (AWS Direct Connect または VPN) を活用して、オンプレミスでホストされているリソースを共有する柔軟性も持っています。 このユースケースでは、SaaS プロバイダー (リソース所有者) がデータベースやインスタンス、クラスター、またはオンプレミスリソースなどの管理されたリソースをホストしています。クライアント (リソース消費者) は、利用可能な次の3つのオプションのいずれかを使用して、共有リソースに接続できます。 サービスネットワークエンドポイントの使用 AWS PrivateLink リソースエンドポイントの使用 サービスネットワークへの VPC 関連付けの使用 図4は、クライアント (リソース消費者) が SaaS プロバイダー (リソース所有者) によってホストされている管理リソースに接続するために使用できる3つの異なるオプションを示しています。 図4. SaaS プロバイダーが管理・ホストするリソースにアクセスするクライアント 3. クライアントが SaaS サービスにアクセスし、SaaS プロバイダがクライアントのリソースにアクセスする このユースケースでは、PrivateLink インターフェースエンドポイントと VPC リソースへのプライベート接続の両方を活用し、クライアントと SaaS プロバイダー間のセキュアな通信を可能にします。このアプローチにより、クライアントが SaaS サービスにプライベートにアクセスできることを確保しつつ、SaaS プロバイダーはクライアントの VPC 内のリソースにプライベートにアクセスすることが可能になります。 SaaS プロバイダーがクライアントリソースにアクセスするために、リソース消費者は3つのオプションのいずれかを選択できます。これらは他の2つのユースケースでも説明されています。簡略化のため、ここではリソースエンドポイントオプションの例のみを示しています。図5では、クライアントと SaaS プロバイダーがインターフェースエンドポイントとリソースエンドポイントの両方を利用し、各方向でプライベートで、ポイント型の一方向接続を実現している様子を示しています。 図5. クライアントと SaaS プロバイダーがインターフェースとリソースエンドポイントの両方を一緒に使用している 知っておくべきこと VPC エンドポイントとリソースゲートウェイの少なくとも1つのアベイラビリティーゾーンが重複している必要があります。 共有するリソースを指定するリソースコンフィグレーションを作成する際、リソースの IP アドレスまたはパブリックに解決可能なドメイン名 (DNS ホスト名) を使用できます。 Amazon Relational Database Service (Amazon RDS) などの特定のリソースタイプでは、オプションとして Amazon Resource Names (ARNs) を使用してリソースを指定することもできます。 リソースコンフィグレーションは、単一、グループ、または子の3つのタイプのいずれかになります。単一リソースコンフィグレーションは1つのリソースを指定するために使用されます。グループリソースコンフィグレーションは、子リソースコンフィグレーションのコレクションを指定するために使用され、各子リソースコンフィグレーションには単一のリソースが含まれます。 リソースゲートウェイはロードバランシング機能を提供しません。リソースゲートウェイの背後にあるリソースにロードバランシングを追加するユースケースがある場合は、NLB/ALB を追加し、そのドメイン名をリソースコンフィグレーションで指定することを検討してください。 VPC エンドポイントの料金 と VPC Lattice の料金 を確認してください。 VPC エンドポイントのデフォルトクォータ と VPC Lattice のデフォルトクォータ を参照してください。 まとめ 本稿では、VPC (Virtual Private Cloud) リソースに対する AWS PrivateLink サポートを使用して、VPC やアカウントの境界を越えて、さらにはオンプレミス環境からも、共有リソースへのプライベートで安全かつ効率的な接続を実現する方法について探りました。また、SaaS プロバイダーとそのクライアントに特化した、この AWS PrivateLink の新機能を実装するための一般的なユースケースと実装のベストプラクティスについても検討しました。VPC リソースに対するAWS PrivateLink サポートを活用することで、SaaS プロバイダーとそのクライアントは、お互いに広範なネットワークアクセスを提供することなく、選択的なリソース共有を可能にすることができます。この新機能についてさらに詳しく知るには、 AWS PrivateLink のドキュメント をご覧ください。 本稿は、2024年12月2日に Networking & Content Delivery で公開された “ Extend SaaS Capabilities Across AWS Accounts Using AWS PrivateLink support for VPC Resources ” を翻訳したものです。翻訳は Solutions Architect の武松が担当しました。

生成 AI の活用が様々な分野で広がる中、アプリケーション開発においても、コード生成や言語間の変換といったタスクでその力を発揮しています。今回ご紹介する事例は、これらの一般的なユースケースを超えた、よりチャレンジングな取り組みです。それは、 アプリケーションのモダナイゼーションプロセス全体に生成 AI を活用する という挑戦です。 アプリケーションのモダナイゼーションは、多くの企業が直面する重要な課題です。一般的に、このプロセスは二つの主要なアプローチで説明されます。一つは既存のアプリケーションをクラウドに「リフト & シフト」する方法で、もう一つはアプリケーションを「リファクタリング」し、クラウドネイティブなアーキテクチャで再構築する方法です。「リフト & シフト」は短期的には迅速ですが、クラウドの利点を最大限に活用できない可能性があります。一方、「リファクタリング」は理想的ですが、時間とリソースを大量に必要とします。 しかし、最終的な目標は同じです。それは、アプリケーションを真にクラウドネイティブなものへと進化させることです。スケーラビリティ、柔軟性、コスト効率の向上を実現し、ビジネスの俊敏性を高めることが、このモダナイゼーションの本質的な目的です。 図 1. モダナイゼーションの2つのパターン 東京海上日動システムズ株式会社（以下、東京海上日動システムズ）と AWS は、リファクタリングによるクラウドネイティブ化への道のりに、生成AIを積極活用しようと取り組みました。従来、高度な専門知識と膨大な時間を要するこのプロセスを、生成AIの力を借りてどこまで効率化・最適化できるのか、多くの企業の皆様にとって参考になると思います。 東京海上日動システムズの状況と課題 東京海上日動システムズでは、多くの基幹系システムをすでにAWSに移行していますが、一部のシステムはまだオンプレミス環境で運用されています。また、 AWS へ移行済みのシステムも多くはシンプルなリフト＆シフトのアプローチを採用したため、レガシーなアプリケーション構造をそのまま踏襲しています。 同社は、オンプレミスのサーバーや Amazon EC2 上で稼働しているレガシーなJavaアプリケーションをサーバーレスアーキテクチャへモダナイズすることを目指しています。 このモダナイゼーションプロセスを効率化させるため、同社は生成 AI の活用に着目しました。Java で構築されたモノリシックなアプリケーションを AWS Lambda を中心としたサーバーレスアーキテクチャへモダナイズする過程で、通常は高いスキルを持ったエンジニアを数多く投入する必要があります。この作業を生成 AI （Amazon Bedrock）を用いて効率化することを検討しました。 しかし、アプリケーションのモダナイゼーションは単なるコードの生成や変換といったタスクのみで実現できるものではなく、複雑な工程と高いスキルが求められる作業です。 AWS Prototyping Program の採用 この複雑で難解な課題に取り組むため、AWS は Prototyping Program  を提案しました。このプログラムでは AWS の Prototyping Engineer が、お客様の課題に合わせたシステムのプロトタイプを開発します。 AWS Prototyping Program は通常、お客様が実現したいシステムのプロトタイプをお客様に代わって、あるいはお客様と共に AWS の Prototyping Engineer が開発し、お客様の環境で AWS サービスがどのように動作するか、深い洞察や理解を得るためのものです。しかし今回のプロトタイピング活動では、お客様の業務システムを模したサンプルアプリケーションに対して生成 AI を使いながらサーバーレスアーキテクチャへモダナイズします。言うなればモダナイズされたサンプルアプリケーションがプロトタイプとなります。今回の活動では、作成されたプロトタイプそのものではなく、活動を通じて確立させた生成AIの活用プロセスと方法論を実践的に検証し、そのノウハウを蓄積することに焦点を当てました。 プロトタイピングのアプローチを選択した理由 生成 AI を活用したアプリケーションのモダナイゼーションは前例や実績が少ない新しい取り組みのため、試行錯誤しながら改善を繰り返す必要があります。また、アプリケーションのモダナイゼーションは単発作業ではなく今後繰り返し発生する作業であるため、単なる成果物にフォーカスするのではなく、そこに至るプロセスと方法論の理解が重要だと考えました。 また、生成 AI を活用したアプリケーションのモダナイゼーションは複数の技術領域に対する深い造詣が必要です。あらゆる業界やセグメントで活動実績があり、複数の技術領域や多種多様な AWS サービスを組み合わせ迅速にプロトタイプを構築できるプロトタイピングチームの参画は不可欠でした。 プロトタイピングの詳細 本プロトタイピングでは、Amazon Bedrock で利用できる Claude 3.5 Sonnet を広範囲に活用しました。アプリケーションのモダナイゼーションは複雑な作業です。単にプロンプトを工夫して入力すれば良いというものではなく、効果的な戦略を立てることが重要でした。 主なアプローチとして以下が挙げられます： タスクの分割：大規模なモダナイゼーションタスクを小さな単位に分割し、各タスクに対して最適なプロンプトを設計しました。例えば、生成 AI を使ってモダナイズ後のアプリケーションの REST API インターフェースを最初に定義することで後続タスクでやるべきことを明確に細分化できます。 段階的詳細化：アプリケーションコードは最初からいきなり生成させるのではなく、まずは必要となるコンポーネントや関数を生成 AI に列挙させ、その後にそれらの構成要素の中身を一つずつ実装させていく段階的詳細化のアプローチを採用しました。 共通タスクの前処理：DBアクセスやフロントエンドの Routing 処理など、ビジネスロジックから分離できる共通部品は予め用意しておき、プロンプトにそれら共通部品に関する情報を含めました。生成 AI が注力すべきスコープをビジネスロジックに集中させることで、ノイズの少ない生成 AI への入出力が期待できます。 コンテキストの維持：複数のステップにまたがるタスクでは、前のステップの出力を次のステップの入力として使用し、一貫性を保ちました。Anthropic Claude は 200,000 トークンのコンテキストウィンドウがあり、大量の情報を渡すことを可能にします。 人間によるレビューと修正：作業の大半は生成 AI に任せることができますが完全ではありません。生成AIの出力を人間が確認し、必要に応じて人手による修正またはプロンプトへの指示を追加することで品質を確保しました。 大規模アプリケーションの考慮：今回のプロトタイプ対象は小規模なサンプルアプリケーションであったため、アプリケーションソースコードの全量をプロンプトに含めることも可能でした。しかし大規模なアプリケーションのモダナイゼーションも考慮し、ソースコードの全量ではなくJSP や Controller のソースコードを中心に必要最低限のコードのみをプロンプトに与えても精度が落ちないように検証と改善を繰り返しました。 図 2. 変換作業の戦略 これらのアプローチを用いて、サンプルのJavaアプリケーションを対象に、以下のような成果を達成しました： アプリケーションの構造解析と依存関係の特定 フロントエンドとバックエンドを分離するための REST API インターフェースの定義 ステートレスな SPA(Single Page Application) へ変更するための DB スキーマの更新案の提案 バックエンドアプリケーション処理の抽出と AWS Lambda （今回は Python への変換も合わせて行いました）用のコードの生成 フロントエンドアプリケーション処理の抽出と Vue.js 用のコードの生成 図3. 変換前後のサンプルアプリケーションの画面イメージ お客様の評価と今後の展開 東京海上日動システムズはこのプロトタイピングの結果を高く評価し、プロトタイピングプログラムの成果物を使用して小規模な検証用アプリケーションに対してPoCを実施しました。95%以上は生成AIが生成したコードで動作し、発生したエラーについても多くは単純な修正で解消できました。一方で、一つのパッケージで完結しないJavaアプリケーションの場合やバリデーションチェック、エラーハンドリングについては作業プロセスやプロンプトの工夫によりさらなる改善の余地があると考えています。今回のPoCの総括として、アプリケーションのモダナイゼーションプロセスに生成 AI を活用する試みは一定の成果があったと判断しています。 東京海上日動システムズ デジタルイノベーション本部 デジタルイノベーション開発部 光岡様からは以下のコメントをいただいています。 AWS Prototyping Programは当社の難しい課題に対して有意義な知見を与えてくれました。今回の取り組みは非常にチャレンジングな領域なため当社社員だけだと推進が難しかったのですが、AWSの支援があってとても良い結果が出せました。今回の PoC の結果を受けて、来年度は実際のアプリケーションのモダナイズにも少しずつ活用していく予定です。そこで得た知見をもとにさらなる改善を繰り返しながら、将来的にはより複雑で規模の大きなアプリケーションのモダナイズへも展開していくことを目指しています。 まとめ 本事例を通じて、Amazon Bedrock および Anthropic Claude が複雑なアプリケーションモダナイゼーションタスクにおいても高い能力を発揮することが実証されました。特に、コードの解析、リファクタリング案の提示、アーキテクチャ変更の提案など、多岐にわたる領域で有用性が確認されました。 また、AWS Prototyping Program が、単なる成果物の提供にとどまらず、新しい技術やアプローチの実証と知見の共有に大きな価値を提供できることも示されました。この協働的なアプローチにより、お客様は自社の課題に即した形で生成 AI の活用方法を学び、実践する準備を整えることができました。 生成 AI を活用したアプリケーションモダナイゼーションは、まだ発展途上の分野です。しかし、本事例が示すように、適切な戦略と方法論を組み合わせることで、従来の手法よりも効率的かつ効果的にクラウドネイティブ化を進められる可能性があります。今後、さらに多くの企業が同様のアプローチを採用し、デジタルトランスフォーメーションを加速させることが期待されます。 ソリューションアーキテクト　小野 卓人、神部 洋介

この記事は 「 How generative AI and data are redefining retail experiences 」（記事公開日： 2024 年 10 月 22 日）の翻訳記事です。 小売業と消費財業界は、デジタルトランスフォーメーションを中核に据え、急激に変化しています。 小売業者と消費者ブランドは、このデジタル化へのジャーニーのさまざまな段階にあり、それぞれがビジネスを前進させようとカスタマイズされたソリューションを求めています。 デジタルトランスフォーメーションを推し進めるには、組織はデータに基づくインサイトを必要としており、それによってビジネスの成果を実現しようとしています。 こうした状況の中、データレイク、機械学習 (ML)、人工知能 (AI) などのテクノロジーにより、インサイトを得て、それに基づいて行動することがこれまでになく簡単になっています。 生成 AI で小売を新たな高みへ 小売業と消費財のダイナミックな世界では、生成 AI は変革をもたらす触媒として機能します。 企業が顧客と関わり、業務を管理し、成長を促進させる方法を変革します。 生成 AI の可能性は非常にエキサイティングで、Goldman Sachs は 10 年間で 世界の GDP が生成 AI によって 7% 増加し 、生産性が 1.5% ポイント向上すると予測しています。 商品マーケティングの自動化 小売業者や消費財ブランドは、 Amazon Bedrock 、 大規模言語モデル (LLM)、マルチモーダルモデルを使用することで、インテリジェントな商品分析や使用説明書用の文章作成を行うことができます。 こうしたモデルは、商品の正確性を保証するだけでなく、オンラインの商品カタログ全体で検索をかけた時にその商品がヒットするよう、使用説明書の文章の最適化も行います。 The Very Group (TVG) を例にとってみましょう。 英国の大手マルチブランドオンライン小売業者である TVG では、人気のある E コマース Web サイトを通じて、お客様は衣料品、家庭用品、電子機器などのカテゴリーにある何千もの商品ページにアクセスできます。また、 TVG で扱う商品の開発推進を目的とした生成 AI システムを開発することで、 商品開発プロセス も変革しました。 このシステムでは、Amazon Bedrock、LLM、マルチモーダルモデルを使用して商品を分析し、TVG のコピーライター向けのコンテンツを作成しています。 こうして開発処理時間が短縮され、質の高い商品説明の作成が容易になったため生産性が向上しました。 カスタマーサービスの強化 小売業者も、オンラインと店舗の両方での顧客体験の向上に努めています。 2021 年の Qualtrics の調査 では、調査回答者の 80% が、顧客体験が悪いために他のブランドに切り替えたと答えています。 一方で、AI を活用したチャットボットとカスタマーサービスソリューションとのやりとりを通じて、消費者はより自分に合ったサービスを享受できるようになりました。 アマゾンウェブサービス (AWS) のコンタクトセンターソリューションにより、企業はチャットボットを使用してウェブ上の顧客をほぼ瞬時に支援できるようになり、運用コストを削減しながら顧客満足度を向上させることができています。 また、 Amazon Q in Connect を使うと、生成 AI アシスタントが顧客からの問い合わせにどのように回答し、対応したらよいかを提案してくれるので、より迅速な問題解決と顧客体験の向上を実現しています。 Orbit Irrigation のカスタマーケア担当シニアマネージャーである Brian Dick 氏は 次のように述べています ：「お客様の問題を解決するために、当社のカスタマーケア担当者は 1 回の問い合わせにつき 2 ～ 3 分かけて、いくつものデータソースを検索しています… Amazon Q in Connect を使うと、問い合わせにかかる時間を 10 ～ 15% 節約できます。そのため 1 時間あたりに処理できる通話数が増えるので、Orbit のコスト削減に直接つながることが期待できます」。こうしたパーソナライズされたアプローチは、顧客満足度を高めるだけでなく、ロイヤルティの醸成にもつながります。 カスタマーサービスを活性化させているもうひとつの企業が DoorDash です。 2024 年の初め、DoorDash は自社の Amazon Connect コンタクトセンターに 生成 AI を活用したセルフサービス を導入しました。 DoorDash は生成 AI を活用して、特に Dashers と呼ばれる配送ドライバーへのカスタマーサポート体験を強化しようとしていました。 消費者、業者、Dashers からの大量のリクエストに直面した同社は、当時、セルフサービスという選択肢の改善を模索していました。 DoorDash は AWS とその Generative AI Innovation Center で協働し、音声で操作が可能なセルフサービスのコンタクトセンターソリューションをほんの 2 か月で開発しました。 DoorDash は Amazon Connect と Amazon Lex を使用してインタラクティブな音声応答システムを構築し、カスタマーケア担当者への転送を 49% 削減しました。 また、DoorDash は 1 回の通話で解決する割合を 12% 向上させたため、顧客体験の向上と年間 300 万ドルの運用コスト削減につながりました。 しかし、通話の多くは依然としてカスタマーケア担当者によるサポートを必要としていたため、DoorDash はセルフサービス機能をさらに強化する必要に迫られました。 Dashers は配達中の問い合わせでは迅速な対応を必要とするため、DoorDash は応答時間の短縮に取り組みました。 Amazon Bedrock を通じて生成 AI を実装したことで、よくある質問にすばやく回答できるようになり、セルフサービスの効率と信頼性が向上しました。 このイニシアチブは、サポートを合理化しただけでなく、3700 万人以上の消費者と 200 万人の Dasher からなるユーザーベースの市場の発展および顧客体験の向上の両方を目指す DoorDash の取り組みを強化するものでもありました。 消費者体験を高度にパーソナライズする Amazon Bedrock を使用することで小売業者は高度にパーソナライズされたショッピング体験を提供できます。これによって、かつてないほどの正確さと魅力的なアプローチでお客様が探している商品にたどりつけるようになります。生成 AI を活用するこうした企業は、よりカスタマイズされた商品レコメンデーション、動的なコンテンツ生成、インテリジェントな検索機能を提供することで、オンラインストアの常識を変革しています。 その影響は計り知れません。 McKinsey は 2021 年に、高度にパーソナライズされた体験を提供することで平均で 10 ～ 15% の収益増加が可能であり、そうしたイニシアティブを導入した企業の収益は 5 ～ 25 パーセント増加すると報告しました。 他にも素晴らしい事例があります。 Buy with Prime は、Amazon Bedrock 検索拡張生成 （RAG）を使って高度にパーソナライズされた体験の開発を追求しています。 RAG を使用して商品サポートの問い合わせを処理するチャットボットソリューションを改善し、従来のメールベースのサポートより優れた体験を提供しています。 こうしたイノベーションによって、企業は目覚ましい成果を生み出しています。B2B 体験をパーソナライズしている企業の 77% が市場シェアの拡大を報告しており、消費者の 4 分の 3 近くがパーソナライズなしではショッピングを完了できないと答えています。 さらに、パーソナライゼーションによって顧客獲得コストを 50% も削減できます。 こうした例と実績は、生成 AI の力と可能性を実証しています。 消費者はすでに、ショッピングジャーニー全体を通じてより魅力的で効率的でパーソナライズされたサポートを利用しており、その恩恵を受けています。 高度なデータインサイトによって小売業界を変革 Amazon Q や Amazon QuickSight などの生成 AI テクノロジーには、高度なデータインサイトの収集など、いくつかの機能があります。 小売業者や消費者ブランドは、これらのインサイトを活用してデータの可能性を最大限に引き出すことができます。 なぜこれが重要なのでしょうか？ 効果的なデータ管理と分析によって、小売企業や消費財企業は競争力を保つことができます。そこに AWS は、 Amazon S3 などのスケーラブルなストレージソリューションと強力な分析ツールを組み合わせた強固なフレームワークを提供しています。企業はこのAWS フレームワークを使用して、膨大な量の構造化データと非構造化データを安全に管理できます。こうしてデータ処理が効率化され、小売業者は実用的なインサイトを迅速に引き出すことができるのです。 Amazon QuickSight は、このエコシステムにおいて極めて重要なツールです。 超高速で並列性の高いインメモリ計算エンジンにより、大規模なデータセットを迅速に分析できるため、ユーザーは数十億行のデータを操作に応じてリアルタイムに視覚化できます。 この機能は、リアルタイムのデータ傾向に基づいて迅速な意思決定を行う必要がある小売業者にとって極めて重要です。 Amazon Q in QuickSight では、自然言語によるクエリもサポートしているため、ユーザーは質問をしたり、すぐにデータを視覚化してもらうことができます。 これによりデータへのアクセスが民主化され、技術的な専門知識がなくても、どの部門の従業員であっても複雑なデータセットを扱うことができます。 Amazon Q in QuickSight での自動データ準備機能は、セマンティック情報を推測してデータセットに追加することで、効率を大幅に向上させます。 これによって手作業によるデータ準備作業に費やす時間が減り、複雑なデータ管理から解放されてインサイトの抽出に集中できるようになります。 小売業者は、こうしたインサイトを、次のようなさまざまな用途に活用できます。 マーケティング戦略のパーソナライズ Amazon Q を利用すると、小売業者は自然言語によるクエリを通じて顧客の行動を迅速に分析できます。 たとえば、マーケティング担当者は「18 ～ 25 歳の顧客が先月購入した商品は何か」と尋ねることができます。そうしたデータがあれば、 販売キャンペーン を変更して改善できます。 生成 AI を統合することで、ユーザーの行動に基づいてマーケティングコンテンツをリアルタイムでカスタマイズできます。 マーケティングチームは Amazon Q を使用して販売キャンペーンのパフォーマンスに関する詳細を表示させることもでき、戦略を迅速に調整しやすくなります。 Amazon Personalize などのツールを QuickSight や Amazon Q と組み合わせると、コンテンツの作成と配信を強化できます。 さらに、Amazon Q のストーリー機能ではインサイトの共有が簡単になり、視覚的にわかりやすいレポートを作成し、チーム間のコラボレーションが向上します。 こうした機能により、マーケティングチームはトレンドに迅速に対応し、より効果的なキャンペーンを推進できます。 在庫管理 効果的な在庫管理には、コストを最小限に抑えながら最適な在庫レベルを維持することが不可欠です。 Amazon Q では、小売部門や消費財部門が簡単な自然言葉で過去の売上データをクエリできるため、正確な需要予測が容易になります。 例えば、小売業者は「過去の傾向に基づく次の四半期の売上予測はどれくらいか」と尋ねることができます。 これにより、企業は在庫レベルを積極的に調整し、人気商品の品切れを防ぎつつ過剰在庫を減らすことができます。 Amazon Q からのインサイトを活用した QuickSight の視覚化機能によって主要な在庫指標は継続的にモニタリングできるようになり、その結果、小売業者や消費者ブランドはサプライチェーンをタイムリーに調整できるようになるので、顧客満足度と業務効率が向上します。 業務効率 業務効率を最大化することは小売業者にとって不可欠です。Amazon Q は、対話型クエリを通じて動的に過去の主要業績評価指標の追跡ができ、一方で QuickSight はデータを静的に視覚化することに長けているので、QuickSight の強力な視覚化ツールを、Amazon Q の対話型クエリで補完し KPI を追跡することができます。 マネージャーは「今月は売上目標に対してどの程度達成しているか」といった質問をすることができます。 リアルタイムダッシュボードはパフォーマンスを継続的に監視し、ボトルネックを特定し、迅速な行動を促すためのインサイトを提供します。 こうした高度な機能を業務に統合することで、組織は情報に基づいたデータ主導の意思決定を迅速に行い、ビジネス目標をより早く達成できます。 さらに、生成 AI 機能を統合することで、チームはデータサイエンスの広範なトレーニングを受けなくても複雑な分析を行うことができます。 チームメンバーは Amazon Q in QuickSight に「先月の売上増加に貢献した要因は何か」と尋ねることができます。 また、主要な要因の概要を数秒以内に受け取ることができます。 この機能により、小売部門や消費財部門は表面下にある本質的な傾向を理解し、戦略を積極的に調整できるようになります。 Amazon Q と Amazon QuickSight は、小売企業や消費財企業が蓄積されたデータから実用的なインサイトを引き出すことを支援します。こうしたツールによってデータ管理プロセスが簡素化され、自然言語クエリによる可視化機能が強化されることで、企業は市場の変化に迅速に適応し、持続的な成長に向けて業務を最適化できるようになります。 まとめ 小売・消費財業界は、技術の進歩と消費者の期待の変化に促されて、急速に進化し続けています。 生成 AI の使用とデータ主導型戦略の採用は、よりパーソナライズされた体験の創出、業務の最適化、データに基づいた意思決定を目指す小売・消費財業界にあってはトレンドとなっています。 こうしたイノベーションを取り入れることで、小売業者や消費者ブランドは、成長を続けるデジタル市場において、顧客満足度を高め、プロセスを合理化し、競争力を高めることができます。 独自のソリューションを構築する際の、アーキテクチャの参照となるケースに関しては、AWS ソリューションライブラリの Generative AI Application Builder on AWS ページをご覧ください。 小売 および 消費財 分野のビジネスおよび技術ユースケース向けのさまざまな検証済みソリューションとガイダンスが紹介されています。 小売および消費財企業が、ソリューションを購入するか自社開発するかの選択に迫られた時でも、AWS には広範なパートナーコミュニティがあり、そのパートナー各社が業界ニーズに合わせて厳選したソリューションが AWS Marketplace の小売・消費財向けハブで提供されていますので Marketplace 上でいろいろと選べます。 その他のユースケースやトレンドの詳細については、 AWS for Retail and Consumer Goods ページをご覧ください。 お問い合わせはこちらへ AWSが提供する小売および消費財産業向けの充実したソリューションラインナップを見てみましょう。AWSで小売ビジネスをどのように変革できるかがわかります。 小売 と 消費財 テクノロジー を専門とする AWS パートナーとつながり、お客様固有の課題に対応する最高のツールと専門知識を入手しましょう。 イノベーションと成長へのジャーニーを始めるために、今すぐ AWS の担当者 に連絡してみましょう。 さらに読む Generative AI for Retail and Consumer Goods Intelligent Supply Chain Solutions from AWS Data Lake | AWS Solutions for Retail Demand Forecasting & Planning | AWS Solutions for Retail 著者について Anu Kaggadasapura Nagaraja Anu Kaggadasapura Nagarajaは、シアトルオフィス勤務のアマゾンウェブサービスのソリューションアーキテクトです。機械学習、AI、データ分析を専門としています。 エンタープライズグリーンフィールド小売店や 消費財のお客様と協力して、AWS プラットフォーム上で革新的なアプリケーションを設計および開発しています。テクノロジー強い信頼を寄せている Anu は、お客様がAWSを最大限に活用して、ビジネスの問題を解決できるよう支援することに力を注いでいます。 Brendan Jenkins Brendan Jenkins はソリューションアーキテクトで、AWS の企業顧客を対象に技術ガイダンスを提供し、ビジネス目標の達成を支援しています。 DevOps と機械学習テクノロジーを専門としています。 Esther Kang Esther Kang はAWS バージニアオフィス勤務のアソシエイトソリューションアーキテクトです。 AWS に入社する前、Esther はメリーランド大学で学び、コンピュータと情報科学の学士号を取得して卒業しました。 在学中にデータベースの設計とプログラミングのスキルを磨き、現在は AWS の職務でそのスキルを活かしています。 Parker Bradshaw Parker Bradshaw は AWS のエンタープライズ SA で、ストレージとデータテクノロジーを専門としています。 小売企業が大規模なデータセットを管理して顧客体験と商品品質を向上させるのを支援しています。彼はイノベーションと技術コミュニティの構築に情熱を注いでいます。休日は、家族と過ごす時間を大切にし、ピックルボールを楽しんでいます。 本ブログは CI PMO の村田が翻訳しました。原文は こちら 。

みなさん、こんにちは。2024 年 10 月 18 日に、AWS Japan 主催のコスト最適化関連イベントとなる、「 AWS 秋の Cost Optimization 祭り 2024 」を開催いたしました。本ブログでは、イベント内容概要の紹介と、イベントの中で各登壇者が発表した資料を公開いたします。 アジェンダ イベント当日は、90名以上のお客様にご参加いただき、約2時間にわたるイベントとなりました。オープニングに続き、AWS のカスタマーソリューションマネージャー 青木とテクニカルアカウントマネージャー 石王によるコスト関連セッションを実施。その後、日産自動車株式会社 吉澤様、株式会社ポーラ・オルビスホールディングス 北川様、株式会社 MIXI 木村様から、それぞれコスト最適化に関する貴重な事例をご紹介いただきました。最後に、ソリューションアーキテクト 柳のセッションを経てイベントを締めくくりました。各セッションの概要と発表資料は以下をご覧ください。 セッションの紹介 CFM フレームワーク概要 発表資料： AWS_秋のCost_Optimization祭り_2024_CSM青木_CFMフレームワークの概要 まずは、カスタマーソリューションマネージャーの青木より、「CFM フレームワーク概要」を紹介しました。Cloud Financial Management (CFM) とは、「可視化」、「最適化」、「計画・予測」と「FinOps」の 3 + 1 の柱から構成される、コスト最適化のためのフレームワークになります。セッションの中では、それぞれの柱の中でどのようなアクションを実施すべきかを説明しました。また、アクションの中で活用できる AWS サービスとして、 AWS Cost Usage and Reports (CUR), Amazon QuickSight , Cost Optimization Hub の使用方法も紹介しました。セッションの最後には、FinOps のアクションとして、IT 部門と財務部門が一体となることがクラウドのコスト最適化において重要であることをお伝えしました。 クイックウィン最適化 発表資料： AWS_秋のCost_Optimization祭り2024_TAM石王クイックウィン最適化 テクニカルアカウントマネージャーの石王より、「クイックウィン最適化」として、Cost Optimization Hub を使ったクイックウィン最適化の始め方を紹介しました。Cost Optimization Hubとは、AWS アカウントと AWS リージョン全体でコスト最適化に役立てることのできる、コスト管理機能になります。セッションの中では、Cost Optimization Hub の開始方法から始まり、AWS リソースのコスト削減余地や推奨アクションを確認するための一連の操作方法を説明しました。また、実際のマネジメントコンソールの画面をみながらデモンストレーションしたため、会場にご参加の皆様には具体的な操作イメージが伝わったのではないかと思います。 コスト最適化施策の歩みと壁（日産自動車株式会社様） 日産自動車株式会社様では、多くの業務システムを AWS 上で稼働させており、Cloud Center of Excellence (CCoE) を中心に組織的なコスト管理を行っています。コスト最適化の歩みとして、多くの削減余地に対してコスト削減施策が実行できていないこと、 AWS Savings Plans / Reserved Instance カバレッジ率の低下、RDS Reserved Instance 購入時負荷増大、各アプリのコスト削減推進不足という4つの課題それぞれに対する取り組みをご紹介いただきました。課題それぞれのお困りごとや、取り組みにより達成した成果を具体的にご説明いただきましたので、同様のお悩みを抱えておられるお客様には参考になる点も多いと思われます。今後は、コスト可視化ダッシュボードの刷新や AWS トレーニングの強化を通じて、さらなる最適化を目指すとのことでした。 複数OrganizationsのAWSコストをまとめて可視化してみた（株式会社 ポーラ・オルビスホールディングス様） 発表資料： AWS_秋のCost_Optimization祭り2024ポーラオルビスホールディングス様_複数OrganizationsのAWSコストをまとめて可視化してみた 株式会社ポーラ・オルビスホールディングス様では、コスト最適化を図るためのステップとして「可視化」「分析」「検討」「削減」の4 ステップを定義し、これらのステップを途切れず繰り返し行う「コストコントロールループ」をゴールと定められました。本セッションでは、コストの可視化についてご紹介いただきました。複数のリセラーからアカウントを調達していることから、複数の AWS Organizations コストの可視化を実現する、 AWS Cost Explorer API を使った独自のダッシュボードを作成されました。ダッシュボード作成により、各部署が好きなタイミングでコストを確認でき、また、コスト最適化を行うための月次ミーティングを実施することで、担当一人一人がコストコントロールの意識を持つことができるようになったとのことです。これらのコントロールループを実現するための具体的な課題と解決策をご紹介いただきました。 長期運用を支えるみてねの継続的なコスト最適化の取り組み（株式会社MIXI様） 発表資料： AWS_秋のCost_Optimization祭り2024_MIXI様⻑期運用を支えるみてねの継続的なコスト最適化の取り組み 株式会社 MIXI 様は、子供の写真や動画を家族と共有しコミュニケーションして楽しむ「みてね」というサービスを提供しています。本セッションでは、みてね SRE チームのコスト最適化への取り組みについてお話いただきました。Grafana を使ったコストの可視化やリソースのモニタリング、コスト最適化施策を実施する際のコスト削減効果と難易度のマトリックスのお話など、普段コスト最適化について意識されている点を具体的にご紹介いただきました。コスト最適化施策があるが実施するべきか悩まれている方には参考になるセッションだと思われます。 アーキテクチャ最適化 発表資料： AWS_秋のCost_Optimization祭り2024_SA柳_CFMフレームワークの概要アーキテクチャ最適化-Architect with cost in mind- 最後に、ソリューションアーキテクトの柳から、コスト最適化を考慮したアーキテクチャ最適化についてお話ししました。 このテーマに対するアプローチはベストプラクティスというものは無く、機能/非機能要件とのトレードオフで決定していくものであるという前置きのもと、データ取り込み、 Amazon CloudWatch 、Machine Learning を題材にケーススタディしました。データの取り込みでは、軽視されがちな Amazon S3 における API コストの考え方を、ストレージクラスごとに分類しご紹介しました。CloudWatch のコスト取り込みでは、ログの役割に応じて転送先を分けることで、よりコストを削減する構成について説明しています。そして最後に、生成 AI を活用することによって、コスト要因であったモデル作成・学習のプロセスそのものが変革されるのではないかと、提起しました。そして、総括として今までのやり方に捉われないことで根本的にコスト構造が変わりうると結んでいます。 まとめ 本イベントでは、コスト最適化にフォーカスして、AWS からの情報だけでなくお客様事例も交えて様々なトピックを紹介しました。 クラウドでは、コスト最適化に終わりはなく継続して実施することが重要です。本イベントから少しでもコスト最適化のヒントを持ち帰り、実践頂ければ幸いです。今後もこのようなイベントを通じて、お客様からの知見共有と AWS からコスト最適化の情報発信が出来ればと考えています。 本ブログは、Sr. Customer Solutions Manager の山下、Sr. Technical Account Manager の岡本により執筆いたしました。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 1 月 28 日（火）に AWS re:Invent Recap – インダストリー編 がオンラインで開催されます。インダストリー別に AWS の最新アップデートを紹介しますので、皆さんの業務に関連しそうなセッションにぜひご参加いただければと思います。 それでは、1 月 20 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「Amazon Q Developer の運用調査機能を始めよう」を公開 AWS re:Invent 2024 にて、生成 AI 技術を活用してインシデントの調査を支援する Amazon Q Developer の運用調査機能 を発表しました。このブログでは、セットアップ方法をステップバイステップで説明しています。また併せて インタラクティブデモ も公開されていますのでぜひご覧ください。 ブログ記事「Amazon Q Developer を活用し自然言語を使って簡単に AWS CLI コマンドを実行」を公開 この記事では、コマンドライン (CLI) 上での Amazon Q Developer のセットアップ方法と活用例を紹介しています。活用例では、S3 バケットの作成や CloudFront ディストリビューションの設定などの指示を自然言語で CLI 上に記述し、その内容に応じて Amazon Q Developer が生成した bash コマンドを実行してウェブサイト構築を行う例を紹介しています。 ブログ記事「新しい Amplify AI Kit で、フルスタックの AI アプリを数分で構築」を公開 この記事では、生成 AI 機能を持ったアプリケーションを Amplify AI Kit を使用して構築する方法について紹介しています。AI 機能の追加には、チャットを実現するConversation API もしくは文章生成を行う Generation API を使用します。それぞれの API の使い方と使用した際のアーキテクチャが解説されています。 ブログ記事「アプリケーションデータを使用して、カスタマイズされた AI ベースのチャットインターフェースを作成」を公開 この記事では、Amplify AI Kit を使用してアプリケーションに会話型 AI チャットを追加する方法を紹介しています。Amplify AI Kit を使い数行のコードを記載することで、会話型チャット・アバター・添付ファイル設定などをフロントエンドアプリケーションに追加することが可能です。コード例と共に紹介していますので、ぜひご覧ください。 ブログ記事「React Native と AWS Amplify、Amazon Bedrock Knowledge Base を利用したトラベルプランナーの構築」を公開 上記 2 つの記事ではアプリケーションから LLM をそのまま呼び出す方法を紹介しましたが、この記事では Amazon Bedrock Knowledge Bases で構築した RAG を Amplify AI Kit を使ってアプリケーションに実装する方法を紹介しています。 ブログ記事「【開催報告&資料公開】生成 AI と AWS Ad/Marketing Tech Services で実現する広告・マーケティングイノベーション」を公開 2024 年 10 月 17 日に、広告やマーケティングに携わる方々を主な対象としたオンラインセミナーを開催しました。こちらの記事は、そのセミナーの開催ブログです。生成 AI 含む AWS の Ad/Mktg Tech サービスの効果的な活用方法や AWS Clean Rooms のお客様事例を紹介しています。 サービスアップデート Amazon Q Business にて、チャットでアップロードされた画像のインサイト抽出機能に対応 生成 AI 搭載アシスタントである Amazon Q Business にて、チャットでアップロードされた画像に関する質問への回答とインサイトの抽出機能を提供開始しました。例えば、請求書の画像をアップロードして経費の分類を依頼したり、アーキテクチャ図を共有して設計に関する質問をしたりすることができます。この機能は、Amazon Q Business が利用可能なすべてのAWSリージョンで利用できます。 Amazon Bedrock にて Luma AI の Ray2 ビデオモデルが利用可能に Luma AI の新しいビデオ生成 AI 基盤モデルである Ray2 が、Amazon Bedrock で利用可能になりました。Luma Ray2 は、自然な動きを持つリアルな映像を作成できるビデオ生成モデルです。Ray2 は現在、540p もしくは 720p の解像度、5 秒 もしくは 9 秒のビデオ生成をサポートしています。現在オレゴンリージョンで利用可能です。 詳細はこちらのブログ をご覧ください Amazon Bedrock にて、Cohere Embed 3 Multilingual と Embed 3 English のマルチモーダルサポートを開始 埋め込みモデルである Cohere Embed 3 Multilingual と Embed 3 English にてマルチモーダルサポートを開始しました。マルチモーダルサポートにより、画像コンテンツを含むデータから重要な情報を引き出すことが可能になります。現在、東京リージョン含む 12 のリージョンでサポートされています Amazon Bedrock Flows にて、複数ターン会話のサポートを発表（プレビュー） Amazon Bedrock Flows は、LLM・エージェント・ナレッジベース・その他の AWS のサービスのワークフローを作成することが可能なサービスです。今回のアップデートで複数ターン会話がサポートされたことで、一連の処理に必要な情報が不足していた場合に、ユーザーに要求して引き出すことができるようになりました。これにより、ワークフローの処理に必要な情報を自然な会話を通じて取得できるようになります。 Amazon Neptune にて、オープンソースの GraphRAG ツールキットのサポートを開始 GraphRAG とはグラフデータベースを用いた RAG の技術を指します。今回発表された GraphRAG ツールキットは、非構造化データからグラフを自動構築し、このグラフに対してクエリを行って質問応答するための機能を提供します。詳細については、 ユーザーガイド をご覧ください。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成 AI と毎日戯れており、特にコード生成と LLM エージェントに注目しています。好きなうどんは’かけ’です。

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 過去にもご紹介した AWS re:Invent Recap – インダストリー編 がいよいよ今週開催です。 お見逃しないよう是非ご活用ください！ それでは、先週の主なアップデートについて振り返っていきましょう。 2025年1月20日週の主要なアップデート 1/20(月) アップデートはありませんでした 1/21(火) Amazon EventBridge announces direct delivery to cross-account targets Amazon EventBridge イベントバスが別アカウントのAWSサービスにイベントを直接配信できるようになりました。Amazon EventBridge イベントバスはサーバレスのイベントブローカーで、任意のアプリケーション、SaaSアプリケーション、AWSサービス間でイベントをルーティングしイベント駆動アプリケーションを作成できます。これまで、別アカウントのサービスを呼び出すにはLambda関数などを使って構築する必要がありましたが、今回のアップデートでこれらが不要になります。この機能は全ての商用AWSリージョンでご利用できます。詳細については ブログ 、もしくは ドキュメント をご確認ください。 Amazon Corretto January 2025 quarterly updates Amazon Corretto 長期サポート(LTS)バージョンと機能リリース(FR)バージョンの四半期ごとのセキュリティアップデートとクリティカルアップデートが発表されました。Amazon CorrettoはOpenJDKの無償のマルチプラットフォーム対応ディストリビューションです。最新のバージョンのCorretto 23.0.2、21.0.6、17.0.14、11.0.26、8u442は ホームページ 経由、もしくは Corretto AptまたはYumリポジトリ から利用できます。 Amazon Neptune now supports open-source GraphRAG toolkit オープンソースのGraphRag Toolkitが公開されました。このToolkitはデータソース、グラフストア、ベクターストアを設定することで、グラフストアにベクトル埋め込みが自動的に生成され、選択したグラフストア内のエンティティとその関係のグラフ表現を保存してくれるものです。グラフストアとしてAmazon Neptune DatabaseまたはNeptune Analytics、ベクターストアとしてAmazon OpenSearch Serverlessを選択できます。詳細についてはGithubにある ユーザーガイド をご確認ください。 1/22(水) CloudWatch provides execution plan capture for Aurora PostgreSQL Amazon CloudWatch Database InsightsがAurora PostgreSQL インスタンスで実行されている上位SQLクエリの実行計画を収集し、保管できるようになりました。この機能によりパフォーマンス低下等の原因を実行計画をもとに特定することが可能になります。この機能はCloudWatch Database InsightsのAdvancedモードでのみ使用できます。詳細については ドキュメント をご確認ください。 Amazon Redshift announces support for History Mode for zero-ETL integrations Amazon Redshift ゼロ ETL 統合に history(履歴) モードが追加されました。この機能によりコードを記述することなく、データベースの履歴データに基づいたデータモデリング手法の一つであるType 2 Slowly Changing Dimension (SCD 2)テーブルを作成できます。この機能によりAmazon DynamoDB、Amazon RDS for MySQL、Amazon Aurora MySQL、そして Amazon Aurora PostgreSQLのデータソースと重複したコピーを保持せずに、データ変更履歴を保存できるため、ストレージと運用の手間を削減しながら履歴データを扱えます。詳細については ドキュメント をご確認ください。 AWS Client VPN announces support for concurrent VPN connections AWS Client VPNが複数VPNへの同時接続をサポートしました。これまでは一度に1つのVPNプロファイルにしか接続できなかっため、別のネットワークに接続したい場合、その都度切断と別プロファイルでの再接続が必要でした。今回のアップデートのより切り替えなしで複数のVPNプロファイルへの接続が可能になります。この機能はAWSが提供するClient VPN クライアント version 5.0以降で利用できます。ダウンロード手順は こちら をご確認ください。 1/23(木) Luma AI’s Ray2 visual AI model now available in Amazon Bedrock Amazon BedrockでLuma AIの新しいビデオ生成人工知能基盤モデル(FM)であるRay2を利用可能になりました。Luma Ray2は、滑らかで自然な動きでリアルなビジュアルを作成できる大規模なビデオ生成モデルで、自然言語プロンプトをもとに540pおよび720pの解像度で5秒および9秒のビデオ生成をサポートしています。例えばコンセプトを視覚化、ビデオモックアップの作成などの場面で活用いただけます。Ray2はオレゴンリージョンで利用可能で、Luma AIのフルマネージドモデルの提供は現時点でAWSが最初で唯一です、ぜひお試しください！また、詳細は ブログ や ドキュメント をご確認ください。 Amazon CloudWatch allows alarming on data up to 7 days old Amazon CloudWatchのメトリクスデータ評価期間が24時間から7日間に延長されました。これにより複数日のデータを評価してアラームを出すなど、実行時間の長いプロセス、実行頻度の低いプロセスの監視がよりしやすくなります。この機能はGovCloud(米国)リージョンを含む全てのAWSリージョンで利用可能です。詳細については ドキュメント をご確認ください。 Amazon Bedrock Flows announces preview of multi-turn conversation support Amazon Bedrock Flowsは基盤モデル(FM)、プロンプト、Amazon Bedrock Agents、Amazon Bedrock knowledge base、Amazon Bedrock Guardrails、その他の AWS サービスを繋げAIワークフローを構築することができるサービスです。今回、Amazon Bedrock Flowsのマルチターン会話サポートがプレビュー発表されました。この機能ではエージェントがアクションを正常に完了するために必要な前提情報が揃っていない時に、エージェントノードはフローの実行を一時停止し、ユーザー固有の情報を要求します。ユーザーの応答に基づいてフローの動作を適応させることができるため、よりインタラクティブでコンテキストに応じた体験が可能になります。この機能はAmazon Bedrock Flowsが利用できる全てのリージョンで利用可能です。詳細は ブログ と ドキュメント をご確認ください。 1/24(金) Amazon EC2 I7ie instances now available in AWS Europe (Frankfurt, London), and Asia Pacific (Tokyo) regions Amazon EC2 i7Ie インスタンスが新たに東京、フランクフルト、ロンドンの３つのリージョンで利用可能になりました。I7ie は高密度ストレージ最適化インスタンスで、大規模なデータセットにアクセスする際に、非常に低いレイテンシーで、高いランダム読み取り/書き込み性能が必要なワークロードに最適です。最大 120 TB のローカル NVMe ストレージを提供し、前世代のI3en インスタンスと比較して最大 2 倍の vCPU とメモリを提供します。詳細については 製品ページ をご確認ください。 Amazon Aurora PostgreSQL Limitless Database now supports PostgreSQL 16.6 Amazon Aurora PostgreSQL Limitless DatabaseがPostgreSQL version 16.6をサポートしました。Aurora PostgreSQL Limitless Databaseはリレーショナルデータベースをワークロード増減に合わせて簡単にスケーリングできるサービスで、現在東京を含む10のリージョンで利用可能です。今回のアップデートにはPostgreSQL コミュニティによる製品改善、バグ修正のほかbtree_ginのサポートやAurora Limitless 固有の改善が含まれています。詳細については ドキュメント をご確認ください。 Amazon Bedrock now offers multimodal support for Cohere Embed 3 Multilingual and Embed 3 English Amazon BedrockでCohere Embed 3 MultilingualとCohere Embed 3 Englishのマルチモーダルサポートが提供されました。Cohereによると、Embed 3はテキストと画像の両方の検索機能をサポートし、100以上の言語（Embed 3 Multial言語）に対応しているため、グローバルアプリケーションに最適です。さまざまなデータセットを処理して解釈できるので、複雑なレポート、製品カタログ、設計ファイルなど様々なユースケースで効率向上に繋がります。マルチモーダルサポートのCohere Embed 3は 東京を含む12のリージョン で利用可能です。 それでは、また来週！ ソリューションアーキテクト 根本 裕規 著者について 根本 裕規(Yuki Nemoto) AWS Japan のソリューションアーキテクトとして、金融機関のお客様の AWS 活用や個別案件の技術支援を担当しています。過去には公共部門やモダナイゼーションのスペシャリストもしていました。好きなサービスは AWS CodeBuild です。週末はオフロードバイクのレースをしています！