本稿は、2025 年 2 月 18 日に AWS Blog で公開された “ AWS for VMware at re:Invent 2024 Playlist ” を翻訳したものです。 AWS re:Invent の興奮も冷めやらぬ中、VMware から AWS への移行に関するオンデマンドセッションのプレイリストを厳選しました。このプレイリストには、エキスパートによる教育的なブレイクアウトセッション、実際の顧客事例、AWS ソリューションの Deep Dive が含まれており、お客様が自信を持って IT 変革を進めることができるように支援します。AWS の新機能の活用方法、セキュリティの強化方法、インフラストラクチャコストの最適化方法について学ぶことができます。 まずはここから：AWS での移行パスのオプションを決定 MAM103 | The future of your VMware-based workloads with AWS | Level 100 VMware ベースのワークロードに適したクラウドの移行先を選択することは、ビジネスにとって極めて重要です。このセッションでは、AWS がどのようにお客様と協力してこのジャーニーをナビゲートするかを学びます。AWS は実績のある移行パスを提供しています。これには VMware Cloud Foundations (VCF) 環境の AWS への移行を簡素化する Amazon Elastic VMware Service (Amazon EVS) や、クラウドジャーニーを支援する規範的なガイダンスを提供する目的別サービスが含まれます。現在および将来のビジネス目標を達成するために、移行、モダナイゼーション、イノベーションの適切な組み合わせを実現するためのオプションとパスを探ります。AWS と AWS パートナーが VMware 環境をシームレスに変革するためにどのように支援するかをご覧ください。 クラウドジャーニーの新しいオファリングを理解し、AWS 移行パスを Deep Dive する MAM238-INT | Automating migration and modernization to accelerate transformation (Innovation talk) | Level 200 多くの組織が、既存のアプリケーションとその中に閉じ込められたデータから価値を引き出すことに苦労しています。このセッションでは、AWS が最も複雑な移行とモダナイゼーションのタスクをどのように簡素化し、レガシーシステムの変革とクラウドイノベーションを加速しているかを説明します。アプリケーションの最新アーキテクチャへのアップグレード、リプラットフォーム、リファクタリングにおいて、チーム横断的な移行とモダナイゼーションの機会の発見、計画、実行方法を一新する革新的な AWS サービスについてご紹介します。また、ミッションクリティカルアプリケーションとデータをクラウドへ効率的に移行・改善する方法を学ぶことで、運用コストとライセンス費用の削減、イノベーションの加速、そしてレガシーコードベースのメンテナンス遅延によるリスクを軽減する方法をご覧ください。 DOP224-New | Accelerate modernization of VMware workloads using Amazon Q Developer Amazon Q Developer の新しい変換機能が、VMware 環境の AWS へのモダナイゼーションと移行をどのように簡素化・自動化するかについて学びませんか？このセッションでは、Amazon Q Developer が VMware 環境の Amazon EC2 への移行における発見、計画、リプラットフォーム、デプロイメントをどのように加速するかを紹介します。生成 AI を活用した機能が、VMware の AWS への移行を数ヶ月で効率化することで、スケーラビリティとイノベーションを高める方法をご紹介します。モダナイゼーションチームが差別化されていない重労働を削減し、生産性を向上させ、ビジネス価値をより迅速に提供する方法について洞察を得ることができます。 MAM119-New | New Launch – Amazon Elastic VMware Service: Start your modernization journey | Level 100 Amazon Elastic VMware Service (Amazon EVS) は、既存のスキルと使い慣れたソフトウェアを使用しながら、VMware ベースのワークロードを AWS に移行して実行するためのシンプルな方法です。主要機能について学び、Amazon EVS の提供するシンプルさ、柔軟性、セキュリティ、制御から仮想マシンがどのようなメリットを得られるかをご覧ください。このソリューションを構築したチームと共に、既存の VMware Cloud Foundation (VCF) サブスクリプション、VMware への投資、お好みのツールを活用しながら、クラウドのメリットを享受する方法を理解します。AWS 上で VCF 環境をデプロイする方法と、Amazon EVS がお客様のニーズにどのように対応できるかをご紹介します。 HYB201 | AWS wherever you need it: From the cloud to the edge | Level 200 ほとんどのワークロードはクラウドに移行できますが、低レイテンシー、ローカルデータ処理、デジタル主権のニーズにより、一部はオンプレミスまたはエッジに残るものもあります。このセッションでは、AWS Outposts、AWS Local Zones、AWS Dedicated Local Zones、AWS IoT などの AWS サービスが、マルチプレイヤーゲーム、高頻度取引、医療画像処理、スマート製造、データレジデンシー要件を持つ生成 AI アプリケーションなどのハイブリッドクラウドおよびエッジコンピューティングワークロードをどのようにサポートするかを学びます。 HYB308 | Migrating your VMware workloads with on-premises dependencies | Level 300 ほとんどの VMware ワークロードは簡単にクラウドに移行できますが、アプリケーションの相互依存性、データレジデンシー要件、またはタイムライン制約により、一部はオンプレミスに残す必要があります。このセッションでは、AWS Outposts や AWS Local Zones などの AWS ハイブリッドおよびエッジサービスが、その場での移行とお客様のペースでのモダナイゼーションをどのように可能にするかを学びます。Outposts を使用したさまざまな移行パスと、クラウドへの移行を簡素化・加速するために使用できる移行ツールやプログラムについて詳しく説明します。 KUB310 | Amazon EKS for edge and hybrid use cases | Level 300 製造、医療、通信、金融サービスなどの業界では特に、低レイテンシー、データ依存性、データ主権、その他の規制上の理由により、一部のワークロードをオンプレミス、エッジ、またはハイブリッドシナリオで実行する必要があります。データ依存のワークロードは、AWS サービスにデータが存在するまで完全な移行を待つ必要があるかもしれません。このセッションでは、Amazon EKS Anywhere と Amazon EKS Hybrid Nodes を使用してオンプレミスでコンテナワークロードを実行し、VMware ベースのワークロードのモダナイゼーションをサポートする本番環境対応のアーキテクチャを探ります。 顧客事例から学ぶ MAM104 | AWS for VMware migrations: Successes, roadmaps, & strategies | Level 100 オンプレミスの VMware 環境を AWS に移行しようとしており、適切なアプローチについてのガイダンスを求めていますか？このセッションでは、その経験を歩んできた移行の先駆者たちが集まります。さまざまなグローバル組織が計画から実行まで、どのようにしてクラウドジャーニーを加速したかを直接聞くことができます。講演者は、移行をスムーズにした信頼できるツール、戦略、教訓を共有し、お客様の移行の指針となる洞察を得られます。さらに、各社のモダナイゼーションロードマップとイノベーション戦略についても垣間見ることができます。クラウドへの移行を始めたばかりのお客様でも、ハードルを乗り越えているお客様でも、自社のクラウド変革を推進するための実用的な洞察を得ることができます。 MAM214 | Gilead Sciences’ AWS migration: From VMware to cloud transformation | Level 200 Gilead Sciences が AWS プロフェッショナルサービスとの協力を通じて、グローバルなデジタルトランスフォーメーションをどのように加速したかをご紹介します。オンプレミス VMware 環境から AWS ネイティブサービスへの 2,000 台以上のサーバーの移行と、1,400 台以上のシステムの廃止の事例について知ることができます。この取り組みを主導した Gilead のリーダーから、移行アプローチ、活用した AWS のツールとサービス、ワークロード選択と移行のベストプラクティスについて直接話を聞くことができます。AWS を活用することで、Gilead はモダナイゼーションとイノベーションを加速することができました。Gilead がどのようにデータを活用し、AI のような新しいテクノロジーを統合してビジネス目標を達成しているのか、洞察を得ることができます。 ライセンスの最適化方法を学ぶ XNT204 | Licensing commercial software on AWS | Level 200 AWS はエンタープライズワークロードのための様々な移行パスを提供していますが、すべてのライセンスオプションを把握するの困難です。このセッションでは、サポート終了を含む Microsoft ソフトウェアのライセンスオプション、Microsoft、VMware、Oracle ワークロードのための補完的な AWS 最適化およびライセンス評価（AWS OLA）、および VMware のような商用ハイパーバイザーの高コストへの対処方法について説明します。ソフトウェアライセンス製品やアプリケーションをオープンソースの代替製品やクラウド専用に構築された技術に置き換えることで、将来に備え、ライセンスコンプライアンスの業務から脱却しましょう。 チョークトークを振り返りたいですか？ここでスライドをご覧ください。 MAM102-R | An AWS guide for VMware administrators | Level 100 STG337 | Migrate any VMware workload from anywhere to improve your TCO | Level 300 MAM218 | Technical decisions for a seamless migration from VMware to AWS | Level 200 MAM237-NEW | New Launch – Deep dive into Amazon Elastic VMware Service | Level 200 次のステップ VMware の移行を AWS がどのように支援できるかの詳細については、 AWS for VMware をご覧ください。 ワークロードを評価し、クラウドへの最適なパスを決定する準備はできましたか？無料の AWS Optimization and Licensing Assessment を今すぐリクエストしてください。 この投稿の翻訳は Solutions Architect の澤が担当させていただきました。原文記事は こちら です。

コンタクトセンターにおける問い合わせ量とエージェントの数は、1 日の中で変動します。エージェントの対応可能数を上回る問い合わせがある場合、エージェントの応答待ちの問い合わせはキューで保持されます。すべての着信問い合わせを処理する単一のキューを構成すれば、サービスレベルを最大化でき、待ち時間を最小化できます。各エージェントがすべての種類の問い合わせを処理できるのであればこれは有効です。しかし、複雑な環境を想定すると、すべてのエージェントがすべての問い合わせを効果的に処理していくことは現実的ではありません。ですから、このような状況では、コンタクトセンターの管理者は着信問い合わせを複数のキューに分割するよう構成します。キューを分割する基準として、言語、事業部門、製品、機能、営業時間、顧客の優先順位付けなどが一般的に使用されます。 コンタクトセンターの新入エージェントは、数週間から数ヶ月にわたり研修を受け、着信問い合わせに対応するための複数のスキルを向上させます。企業は、エージェントが問い合わせ対応で活躍できるようになるまでの時間を短縮することと、新入社員にカリキュラムを修了させることとの間で苦心しています。つまり、運用管理者の観点からは、エージェントが研修期間中の早い段階でより簡単なタイプの問い合わせに対応できるよう、キューを細かく分ける必要があります。一方、過度に専門化されたキュー構成は、問い合わせタイプ間の量の変動によるルーティング制御と運用の非効率性をもたらすサイロ化された構造を作り出します。多数のキューは、IVR における問い合わせ分類のルールとロジックを複雑にします。これらのルールは時間とともに変化するので、誤った振り分けを引き起こし、結果コンタクトセンター内での不要な転送につながってしまいます。 Amazon Connect は、(コンタクトセンター単位の)キューと(エージェント単位の)習熟度を設定する機能を提供します。Amazon Connect では、キューは問い合わせのタイプに基づいてルーティング制御する方法を提供します。習熟度の設定により、そのキュー内の問い合わせに対するビジネスニーズに最も適合するスキルを持つエージェントへさらにルーティング制御します。このブログ記事では、ルーティング制御の要件と運用効率のバランスを取るための Amazon Connect におけるキューと習熟度の設計および設定のベストプラクティスを提供します。 概要 次の図は Amazon Connect のルーティングに関連するエンティティとその関係を示しています キューはエージェントが応答するまで問い合わせが保持される領域です。ビジネスに合わせた、サービスレベルのゴールや目標はキュー単位で設定されます ルーティングプロファイル は、エージェントが対応するように設定された問い合わせのキューのリストをまとめたものです エージェントは 1 つのルーティングプロファイルを持つことができます ルーティングプロファイル内の各キューには優先度(1 から 99)があり、このエージェントがキューに対応する順序を示します。例えば、エージェント A2 は、Tech Support キュー Q2 (優先度 3)の新しい問い合わせよりも、Billing キュー Q1(優先度 2)の古い問い合わせを優先して対応します 習熟度 は、特定の属性を持つ問い合わせに対するエージェントの専門性を示します。習熟度は、 事前定義された属性名 、その値、習熟レベルで構成されます。事前定義された属性を作成した後、エージェントに 1 つ以上の習熟度を割り当てることができます 事前定義された属性の各値について、エージェントはその習熟度における専門性のレベルである 習熟度レベル (1 から 5)を持ちます。エージェントは習熟度を得るために特定の学習パスを完了する必要があり、学習パスの進捗が習熟レベルに反映される可能性があります ルーティング条件 は、 1 つ以上の習熟度要件の組み合わせに基づいてエージェントを対象とするルールをまとめたものです エージェントに問い合わせをルーティングするためにはキューの使用が必要ですが、 習熟度 の使用はオプションです。エージェントの習熟度を使用したルーティングは、以下の 4 つのステップで設定します： ルーティングに関連する事前定義された属性を定義する エージェントに習熟度を割り当てる キュー内での問い合わせのルーティング方法を定義するために、コンタクトフローでルーティング条件を設定する キューに転送する ソリューションの構成 ビジネスプロセスアウトソーシング(BPO)企業の AnyCompany 社は、 1 つの Amazon Connect インスタンスで、 2 つの顧客をサポートしています。各顧客には異なるサービスレベル契約(SLA)があり、SLA を満たさない場合のペナルティが設定されています。彼らは世界中でより多くの顧客にサービスを提供するため、積極的な拡大計画を持っています。エージェントは規模による効率性を高めるために複数の顧客をサポートしています。彼らはエージェントに新しい言語のトレーニングを行わず、顧客対応に必要な言語スキル(または能力)を持つエージェントを雇用しています。また、エージェントは顧客が選択したチャネル(音声またはチャット)で対応します。他の BPO と同様に、AnyCompany はエージェントの離職率が高く、新しいエージェントのトレーニングと導入に多額の予算を費やしています。特に複雑な問い合わせタイプや重要顧客への対応に必要な高度な専門知識を身につけるためには時間がかかるため、顧客満足度が低くなっています。 両顧客(AnyManufacturer-1 と AnyManufacturer-2)は 4 種類のオーディオ機器(スピーカー、レシーバー、サウンドバー、ワイヤレス)を専門としています。各メーカーの問い合わせに対する生産性を上げるために、エージェントは各機器タイプに対して 4 日間のトレーニングと、各メーカーのサービス手順を知るための 4 日間のトレーニングを受けます。これにより、各メーカーの対応を行うためには、 4 週間のトレーニングが必要になります。 AnyManufacturer-1 への問い合わせは、北米の2つの国(米国とカナダ)の消費者からのもので、エージェントは 2 つの言語(英語とフランス語)のいずれかで対応する必要があります。BPO のエージェントは北米の営業時間中に AnyManufacturer-1 をサポートします。 AnyManufacturer-2 への問い合わせは、ヨーロッパの 3 つの国(イギリス、スペイン、フランス)のいずれかの消費者からで、エージェントは3つの言語(英語、スペイン語、フランス語)のいずれかで対応する必要があります。BPO エージェントはヨーロッパの営業時間中に AnyManufacturer-1 をサポートします。 エージェントの習熟度を使用した最適なルーティングソリューションは以下のようになります :  メーカー × 言語 × 機種の組み合わせに基づく 20 のキューにより、問い合わせをセグメント化 各キューに独自のサービスレベル(SL)目標と、リアルタイムおよび履歴の問い合わせ量の測定が存在 AnyManufacturer-1：2 つの言語 × 4 つの機器タイプ = 8 キュー AnyManufacturer-2：3 つの言語 × 4 つの機器タイプ = 12 キュー メーカー × 言語の組み合わせに基づく 5 つのルーティングプロファイルによるエージェントをセグメント化 AnyManufacturer-1 用の 2 つの言語と AnyManufacturer-2 用の 3 つの言語 = 5 つのルーティングプロファイル  この方法では、AnyCompany はエージェントが問い合わせ対応に参加する前に、各メーカーのすべての機器タイプについてトレーニングを行う必要があります。これによりエージェントが実際に本番の対応を行うまでの時間が長期化します 新しいメーカーの導入と追加言語のサポートという積極的な成長計画により、AnyCompany は将来的にさらに追加のキューとルーティングプロファイルが必要になります エージェントの習熟度を使用した最適なルーティングソリューションは以下のようになります : 習熟度は事前定義された属性と値を使用して構築されます 事前定義された属性は、専門的な習熟カテゴリー(言語など)を指し、値には対応可能な異なる言語のリスト(例：英語、スペイン語、フランス語)が含まれます エージェントには習熟度とそれぞれの習熟度レベルが割り当てられます。習熟度レベルは各習熟度におけるエージェントの専門性を示します(1 ～ 5 、5 が最高) エージェントが持っている能力や、業務を通じて学ぶ知識と専門性の分野である、言語と機器を習熟度として扱います 以下の表は AnyCompany で採用した習熟度を示しています : 事前定義された属性 値 種類 connect:Language （言語） connect:English, connect:Spanish, connect:French システム Manufacturer （メーカー） AnyManufacturer-1, AnyManufacturer-2 ユーザー EquipmentType （機器種別） speakers, receivers, sound bars, wireless ユーザー connect:Subtype connect:Chat, connect:SMS, connect: Telephony システム 次の図は、習熟度をどのように Amazon Connect コンソールで設定するかを示しています : 習熟度を導入することで、AnyCompany は以下の改善を実現できます : 新入社員は 1 つの機器タイプの研修を受けた後すぐに問い合わせ対応を開始できます。これにより、エージェントの業務開始までの時間を短縮し、オンボーディングプロセスの早い段階で理論を実践に移すことができます キューの詳細な分類の一部を習熟度で管理できます。問い合わせのセグメンテーションは、各メーカーに対して 2 つのキューに分かれ、AnyCompany は各顧客に対して個別のサービスレベルを維持し続けることができます。これにより、キューの数が 20 から 2 へと 10 分の 1 に削減されます エージェントのセグメンテーションは 1 つのルーティングプロファイルに集約されます。これはルーティングプロファイルの数が 5 分の 1 に削減されることを意味します。大規模で複雑な顧客の場合、これにより設定が簡素化され、管理のオーバーヘッドコストを削減できます 次に、AnyCompany におけるルーティングの 2 つのユースケースについて見ていきましょう。 ユースケース 1 アメリカから英語を話す顧客が AnyManufacturer-1 スピーカーの修理を依頼するために電話をかけてきました。まず顧客は、言語および製品について最高の習熟度を持つエージェントに転送されるべきです。最高の習熟度のエージェントにルーティングできなければ、次に、習熟度レベル 3 以上のエージェントが対象とされます。最後に、そのメーカーについて何らかの経験を持つすべてのエージェントが対象となります。 エージェントのターゲティング要件は、コンタクトフローの ルーティング条件の設定 (Set routing criteria)ブロックを使用して、以下のルーティング基準で実装できます。 ステップ 1 {connect:Language} connect:English >= 5 AND {connect:subType} connect:Telephony >= 5 AND {Manufacturer} AnyManufacturer-1 >= 5 AND {EquipmentType} speakers >= 5 Expire in 5 seconds ステップ 2 {connect:Language} connect:English >= 3 AND {connect:subType} connect:Telephony >= 3 AND {Manufacturer} AnyManufacturer-1 >= 3 AND {EquipmentType} speakers >= 3 Expire in 5 seconds ステップ 3 {connect:Language} connect:English >= 1 AND {connect:subType} connect:Telephony >= 1 AND {Manufacturer} AnyManufacturer-1 >= 1 このユースケースのルーティング条件は、ルーティング条件の設定ブロック内で設定されます。最後のステップ 3 にはタイマーがないため、ステップ 3 のルーティング条件が満たされるまで問い合わせは待機します。 ユースケース 2 スペインからスペイン語を話す顧客が、AnyManufacturer-2 のレシーバーのサービス状況を確認するためにチャットをしています。顧客はまず、各項目(AnyManufacturer-2、レシーバー、スペイン語)について最高の習熟度を持つエージェントにルーティングされるべきです。15秒後、レシーバーまたはスピーカーについて習熟度レベル 3 以上のエージェントが対象となります。さらに 20 秒後、任意のメーカーのチャットまたはSMSチャネルについて習熟度レベル 2 以上のすべてのエージェントが対象となります。さらに 30 秒後、このキュー内のすべてのエージェントが対象となります。 エージェントへのターゲッティング要件は、コンタクトフローの ルーティング条件の設定ブロック を使用して、以下のルーティング条件で実装できます。 ステップ 1 {Manufacturer} anyManufacturer-2>= 5 AND {EquipmentType} receivers >= 5 AND {Language} Spanish >= 5 Expire in 15 seconds ステップ 2 {EquipmentType} receivers >= 3 OR {EquipmentType} speakers >= 3 Expire in 20 seconds ステップ 3 {connect:subType} connect:Chat >= 2 OR {connect:subType} connect:SMS >= 2 Expire in 30 seconds Amazon Connect は AWS Lambda を使用して、外部からの動的なルーティング条件作成をサポートしています。Lambda 関数はルーティング条件をカプセル化した JSON オブジェクト を返します。前述の図は、外部の JSON オブジェクトにリンクする動的なルーティング条件の設定を示しています。前のユースケースとは異なり、このユースケースの最終ステップ 3 にはタイマーがあります。タイマーが終了すると、問い合わせは、ルーティングプロファイルにこのキューを持つ応答可能なすべてのエージェントに転送されます。より複雑なニーズを持つコンタクトセンターでは、ルーティング条件を実行時に生成することができます。ルーティングのルールは、エンタープライズルールエンジンやデータストアから出力できます。これらの条件は、Amazon Connect API から取得したコンタクトセンターのメトリクスのリアルタイム値に基づいて生成することもできます。 ベストプラクティス キューを使用する際のベストプラクティスは以下の通りです : サービスレベルの目標や運用時間など、固有の要件に対して新しいキューの設定を検討します 特定タイプの問い合わせのレポートを出力することのみを目的に、キューを作成しないでください キューを追加することによるキャパシティプランニング、スケジューリング、バックエンドでのレポート作成のコストを認識してください エージェントのグループ間で問い合わせの負荷分散を行うために、ルーティングプロファイルで優先順位と遅延を使用してください 習熟度を使用する際のベストプラクティスは以下の通りです : キュー内の特定のエージェントをターゲットにする追加制御を導入するために習熟度を使用します 同じ問い合わせタイプをサポートする際に、より高い専門知識を持つエージェントを優先し、その後他のエージェントにルーティングする必要がある場合、習熟度を使用します ルーティング基準のステップはタイマーを使用して設定できます。これにより段階的なエージェント選択アプローチが可能になります。最終ステップのタイマーはオプションです。最終ステップのタイマーが期限切れになると、このキューをルーティングプロファイルに持つすべてのエージェントがターゲットになります。最終ステップがタイマーなしで設定されている場合、ルーティング基準が満たされるまで問い合わせは待機します ルーティングの変更のために習熟度レベルを変更しないでください。習熟度は、エージェントの専門知識の増減の実態に沿って変更すべきです 習熟度は、エージェントが特定タイプの問い合わせを処理する経験を学び、発展させた能力を実証する方法です。エージェントのモチベーション向上や報償として、学習進度に基づいて習熟度を自動設定することを検討してください まとめ この記事では、架空の企業 AnyCompany の管理者が、単一の Amazon Connect インスタンス内で異なるルーティング要件を持つ 2 つの顧客向けにキュー、習熟度、ルーティング基準を設定する方法を説明しました。まず、習熟度を含まないキュー構造について詳しく説明しました。その後、設計に習熟度を導入し、習熟度によってキュー内の特定のエージェントをターゲットにする追加のコントロールが可能になることを説明しました。キューと習熟度を使用する際のメンタルモデルに関する考慮事項とベストプラクティスをいくつか挙げました。この記事を参考に、キュー設計を簡素化し、ルーティングエラーや誤送信を減らし、最適なエージェントへのルーティングとコンタクトセンターの効率性のバランスを取るエージェント選択アプローチを開発することができるでしょう。 Amazon Connect は、使用した分だけお支払いいただく従量料金を採用しています。前払い、長期契約、最低月額料金は必要ありません。設定にサポートが必要な場合は、 AWS プロフェッショナルサービス からサポートを受けることができます。また、世界中の Amazon Connect パートナー からもサポートを受けることができます。 Amazon Connect でカスタマーサービス体験を変革する準備はできましたか？ お問い合わせください。 筆者について Parind Poi は、AWS プロフェッショナルサービスのシニアプラクティスリーダーです。AWS におけるカスタマーエクスペリエンス(CX)に関する深い専門知識を持つ専門チームを率いています。Parind は、クラウドによるカスタマーエンゲージメントに関するワークロードのモダナイゼーションの支援に情熱を注いでいます。 Prashant Desaiは、AWS プロフェッショナルサービスのプリンシパルコンサルタントで、大規模なコンタクトセンターのクラウドへの設計と移行の経験を持っています。従来型およびクラウド型のコンタクトセンターにおいて合計 25 年以上の経験を有し、顧客ワークロードの最新化と顧客体験の簡素化のための革新的な方法を常に追求しています。 Balkrishna Nadkarniは、Amazon Connectのプリンシパルテクニカルプロダクトマネージャーです。Amazon Connect の顧客の毎日をよりよくするため、Amazon Connectのルーティングソリューションの構築を支援しています。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

2 月 20 日の AWS Developer Day にぜひご参加ください! このバーチャルイベントは、開発者とチームが最先端でありながら責任ある 生成 AI を開発ライフサイクル全体に組み込み、イノベーションを加速できるようにすることを目的としています。 基調講演では、AWS Evangelism の Vice President である Jeff Barr が、生成 AI に基づく次世代のソフトウェア開発、この変化する環境で成功するために必要なスキル、今後どのように進化していくかに関する考えを語ります。 Amazon Q Developer 、 AWS Amplify 、 GitLab Duo with Amazon Q に関するエキサイティングな技術の詳細情報と製品アップデートをぜひご覧ください。 Christian Bonzelet 氏 (AWS コミュニティビルダー)、 Hazel Saenz 氏 (AWS サーバーレスヒーロー)、 Matt Lewis 氏 (AWS データヒーロー)、 Johannes Koch 氏 (AWS DevTools ヒーロー) による実際のユースケース、ライブコーディングデモ、インタラクティブセッション、コミュニティスポットライトセッションをご体験いただけます。今すぐ このイベントにサインアップ してください! 2 月 10 日週のリリース 私が注目したいくつかのリリースをご紹介します。 AWS STS の AWS SDK デフォルトの更新 – アプリケーションの耐障害性とパフォーマンスを向上させるための AWS Security Token Service (AWS STS) グローバルエンドポイントに対する 今後の変更 についてお知らせしたとおり、2025 年 7 月 31 日に AWS Software Development Kit (AWS SDK) と AWS コマンドラインインターフェイス (AWS CLI) の 2 つのデフォルトを更新します。デフォルトの AWS STS サービスはリージョナルに、デフォルトの再試行戦略はスタンダードに変更されます。更新後に予期しない事態が発生しないように、リリース前にアプリケーションをテストすることをお勧めします。 AWS トラストセンターの紹介 – Amazon Web Services (AWS) の CISO である Chris Betz が、クラウドでお客様のアセットを保護する方法を説明する新しいオンラインリソース、 AWS トラストセンター を紹介しました。このリソースは、当社のセキュリティ対策、コンプライアンスプログラム、データ保護統制についての窓口であり、お客様の信頼を得るために当社が日々どのように取り組んでいるかを示すものです。 VPC エンドポイントをログに記録するための AWS CloudTrail ネットワークアクティビティイベント – セキュリティ体制の強化、潜在的な脅威の検出、VPC ネットワークトラフィックに関するより深いインサイトの取得を行うことのできる、強力なツールを提供します。この機能は、AWS 環境を包括的に可視化して制御する必要のあるお客様の重要なニーズに対応します。 非 HTTP リソースの AWS Verified Access のサポート – AWS Verified Access は、HTTP アプリケーションだけでなく、 Amazon Relational Database Service (Amazon RDS) データベースなどの非 HTTP リソースへの VPN レスの安全なアクセスの提供を開始しました。これにより、ウェブアプリケーションとデータベース接続の両方のセキュリティが向上し、ユーザーエクスペリエンスが改善されます。詳細については、「 Verified Access エンドポイント 」ページと 動画チュートリアル をご覧ください。 Network Load Balancer (NLB) の新しいサブネット管理 – NLB は今まで、新しい アベイラビリティーゾーン でのサブネットの追加のみに制限されていましたが、 Application Load Balancer (ALB) の機能と同様、サブネットの削除を含む完全なサブネット管理をサポートするようになりました。この強化により、組織はネットワークアーキテクチャをより細かく制御できるようになり、AWS ロードバランシングサービスの一貫性が実現します。 Amaz o n SageMaker JumpStart の Meta SAM 2.1 と Falcon 3 モデル – 最先端の動画および画像セグメンテーション機能を備えた Meta の Segment Anything Model (SAM) 2.1 を 1 つのモデルで使用できます。また、科学、数学、コーディング機能の強化に重点を置いて、10 億から 100 億のパラメータにわたる 5 つのモデルを備えた Falcon 3 ファミリーを使用することもできます。詳細については、「 SageMaker JumpStart 事前トレーニング済みモデル 」と「 Amazon SageMaker JumpStart の開始方法 」をご覧ください。 AWS のお知らせの詳細なリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース 興味深い他のニュース項目をいくつかご紹介します。 AWS ドキュメントの更新 – AWS ドキュメント、SDK、CLI チームのリーダーである Greg Wilson が、200 以上の AWS サービスの進捗状況、課題、技術ドキュメントの今後の予定について、洞察に満ちたブログ投稿を共有しました。この投稿では、特定のニーズに適したサービスの選択、コードサンプルを 2 倍にするなどの文書の読みやすさの最適化、ダークモードやトップグローバルナビゲーションコントロールによる自動候補表示などの使いやすさの向上に役立つ AWS 意思決定ガイド にも触れています。また、生成 AI を使用して技術文書を作成する方法についても学ぶことができます。 AWS Well-Architected for Enterprise – 大規模な AWS ソリューションを設計、構築、運用する技術専門家向けに設計された、新しい無料のデジタルコースです。この中級レベルのコースは、ビジネス目標に沿う形でクラウドアーキテクチャを最適化するのに役立ちます。このコースは修了までに約 1 時間かかります。最後には学習内容を強化するための知識チェックが含まれます。 AWS と .NET Aspire の統合 – AWS の .NET チームは、.NET アプリケーションを AWS リソースに接続するための統合に取り組んできました。クラウド対応アプリケーションを構築するオープンソースフレームワークである .NET Aspire 用 Aspire.hosting.AWS NuGet パッケージを使用して、AWS アプリケーションリソースを自動的にデプロイする方法をご覧ください。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Innovate: 生成 AI + データ – 生成 AI とデータイノベーションに焦点を当てた無料のオンラインカンファレンスにご参加ください。このカンファレンスは、APJC および EMEA (3 月 6 日)、北米 (3 月 13 日)、大中華圏 (3 月 14 日)、ラテンアメリカ (4 月 8 日) の複数の地域で開催されます。 AWS Summit – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。最寄りの都市のイベントにご登録ください: パリ (4 月 9 日)、 アムステルダム (4 月 16 日)、 ロンドン (4 月 30 日)、 ポーランド (5 月 5 日)。 AWS GenAI Lofts – GenAI Lofts は、スタートアップや開発者にコラボレーションスペースと没入型の体験をご提供します。 Built on Amazon Bedrock デモナイト (4 月 19 日)、 スタートアップ向け SageMaker Unified Studio デモ (4 月 21 日)、 Agentic Graph RAG を使用したハンズオンワークショップ (4 月 25 日) など、 GenAI Loft サンフランシスコ の実地イベントにご参加いただけます。 GenAI Loft ベルリン の Opening Day は 2 月 24 日で、3 月 7 日まで開催されます。 AWS Community Day – 世界中の AWS エキスパートユーザーや業界リーダーがリードする技術的なディスカッション、ワークショップ、ハンズオンラブなどが開催される、コミュニティ主導のカンファレンスにご参加ください: パキスタン・カラチ (2 月 22 日)、 イタリア・ミラノ (4 月 2 日)、 ベイエリア – セキュリティエディション (4 月 4 日)、 ルーマニア・ティミショアラ (4 月 10 日)、 チェコ共和国・プラハ (4 月 29 日)。 AWS re:Inforce – カレンダーを確認して、ペンシルバニア州フィラデルフィアで開催される AWS re:Inforce (6 月 16～18 日) にご参加ください。AWS re:Inforce は、AWS セキュリティソリューション、クラウドセキュリティ、コンプライアンス、アイデンティティに焦点を当てた学習カンファレンスです。今すぐイベントの最新情報にサブスクライブしてください! 近日開催予定の実地イベントやバーチャルイベントをすべてご覧いただけます。 2 月 17 日週はここまでです。2 月 24 日週の Weekly Roundup もお楽しみに! – Channy この記事は、 Weekly Roundup  シリーズの一部です。AWS からの興味深いニュースやお知らせを簡単にまとめたものを毎週ご紹介します! 原文は こちら です。

2 月 13 日、 AWS CloudTrail の Amazon Virtual Private Cloud (Amazon VPC) エンドポイントのネットワークアクティビティイベントの一般提供を発表できたことを嬉しく思います。この機能を使用すると、VPC エンドポイントを通過する AWS API アクティビティを記録および監視できるので、データ境界を強化し、より優れた発見的コントロールを実装するのに役立ちます。 以前は、潜在的なデータ漏洩を引き起こすための試みや、VPC エンドポイントを介したネットワーク内のリソースへの不正アクセスを検出することは困難でした。VPC エンドポイントポリシーを設定して外部アカウントからのアクセスを禁止することができますが、拒否されたアクションをログに記録したり、外部認証情報が VPC エンドポイントで使用されたことを検出したりする組み込みのメカニズムはありませんでした。TLS トラフィックを検査および分析するためのカスタムソリューションを構築するという選択肢もありましたが、運用面でのコストがかかり、暗号化された通信のメリットが損なわれる可能性がありました。 この新機能により、VPC エンドポイントを通過するすべての AWS API アクティビティをログに記録するようオプトインできるようになりました。CloudTrail はこれらのイベントをネットワークアクティビティイベントと呼ばれる新しいイベントタイプとして記録し、VPC エンドポイントを通過するコントロールプレーンとデータプレーンの両方のアクションをキャプチャします。 CloudTrail に記録されるネットワークアクティビティイベントには、次のような主なメリットを提供します。 包括的な可視性 – アクションを開始した AWS アカウントに関係なく、VPC エンドポイントを通過するすべての API アクティビティがログに記録されます。 外部認証情報の検出 – 組織外の認証情報を使用して VPC エンドポイントへのアクセスが行われたときを特定します。 データ漏洩の防止 – 不正なデータ移動の潜在的な試みを検出して調査できます。 セキュリティモニタリングの強化 – TLS トラフィックを復号化する必要なく、VPC エンドポイントでのすべての AWS API アクティビティのインサイトを取得できます。 規制へのコンプライアンスの可視性 – 通過するすべての API アクティビティを追跡することで、規制要件を満たす能力を向上させることができます。 ネットワークアクティビティイベントでの VPC エンドポイントログの開始方法 ネットワークアクティビティイベントを有効にするには、 AWS CloudTrail コンソールに移動し、ナビゲーションペインで [証跡] を選択します。 [証跡の作成] を選択して新しい証跡を作成します。 [証跡名] フィールドに名前を入力し、イベントログを保存する Amazon Simple Storage Service (Amazon S3) バケットを選択します。CloudTrail で証跡を作成するとき、既存の Amazon S3 バケットを指定するか、証跡のイベントログを保存する新しいバケットを作成することができます。 [ログファイルの SSE-KMS 暗号化] を [有効] に設定する場合、 [新規] を選択して新しい AWS Key Management Service (AWS KMS) キーを作成するか、 [既存] を選択して既存の KMS キーを選択します。 [新規] を選択する場合、 [AWS KMS エイリアス] フィールドにエイリアスを入力する必要があります。CloudTrail は、この KMS キーでログファイルを暗号化してポリシーを追加します。KMS キーと Amazon S3 は同じ AWS リージョンにある必要があります。この例では、既存の KMS キーを使用します。このデモでは、 [AWS KMS エイリアス] フィールドにエイリアスを入力し、残りの設定はデフォルトのままにします。 [次へ] を選択して次のステップに進みます。 [ログイベントの選択] ステップでは、 [イベント] で [ネットワークアクティビティイベント] を選択します。 [cloudtrail.amazonaws.com] 、 [ec2.amazonaws.com] 、 [kms.amazonaws.com] 、 [s3.amazonaws.com] 、 [secretsmanager.amazonaws.com] などの AWS のサービスのリストからイベントソースを選択します。このデモでは、2 つのネットワークアクティビティイベントソースを追加します。最初のソースには、 [ec2.amazonaws.com] オプションを選択します。 [ログセレクターテンプレート] では、一般的なユースケース用のテンプレートを使用するか、特定のシナリオ用にきめ細かいフィルターを作成することができます。例えば、VPC エンドポイントを通過するすべての API アクティビティをログに記録するには、 [すべてのイベントをログに記録する] テンプレートを選択できます。ここでは、 [ネットワークアクティビティアクセス拒否イベントをログに記録] テンプレートを選択して、アクセス拒否イベントのみをログに記録します。オプションで、 [セレクター名] フィールドにログセレクターテンプレートを識別する名前を入力できます (「 Amazon EC2 のネットワークアクティビティイベントを含める 」など)。 2 番目の例として、 [カスタム] を選択して [eventName] や [vpcEndpointId] などの複数のフィールドにカスタムフィルターを作成します。特定の VPC エンドポイント ID を指定するか、結果をフィルターして特定の条件に一致する VPC エンドポイントのみを含めることができます。 [高度なイベントセレクター] で、 [フィールド] から [vpcEndpointId] を選択し、 [次と等しい] を [オペレーター] として選択して VPC エンドポイント ID を入力します。JSON ビューを展開すると、指定したイベントセレクターが JSON ブロックとして表示されます。 [次へ] を選択し、選択内容を確認した後に [証跡の作成] を選択します。 設定が完了すると、CloudTrail は VPC エンドポイントのネットワークアクティビティイベントのログ記録を開始するので、このデータを分析して必要な対応を取ることができます。AWS CloudTrail ネットワークアクティビティイベントを分析するには、CloudTrail コンソール、 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS SDK を使用して関連するログを取得できます。 CloudTrail Lake を使用して、ネットワークアクティビティイベントをキャプチャ、保存、分析することもできます。Trails を使用している場合は、 Amazon Athena を使用して、特定の条件に基づいてこれらのイベントをクエリおよびフィルターできます。これらのイベントを定期的に分析することで、AWS でセキュリティを維持し、規制に準拠してネットワークインフラストラクチャを最適化することができます。 今すぐご利用いただけます VPC エンドポイントをログに記録するための CloudTrail ネットワークアクティビティイベントは、セキュリティ体制の強化、潜在的な脅威の検出、VPC ネットワークトラフィックのより深いインサイトの取得を行うことのできる強力なツールを提供します。この機能は、AWS 環境を包括的に可視化して制御する必要のあるお客様の重要なニーズに対応します。 VPC エンドポイントのネットワークアクティビティイベントは、すべての商用 AWS リージョンで利用できます。 詳細については、「 AWS CloudTrail の料金 」をご覧ください。 CloudTrail ネットワークアクティビティイベントの使用を開始するには、 AWS CloudTrail にアクセスしてください。CloudTrail とその機能の詳細については、 AWS CloudTrail のドキュメント を参照してください。 – Esra 原文は こちら です。

このブログは 2025 年 1 月 31 日に Emma Fu（Senior Technical Product Manager）と Matt Luttrell（Principal Solutions Architect）によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 Amazon Elastic Block Store（ Amazon EBS ）スナップショットを使用して、業務では新しいボリュームを作成する際のベースライン基準となるアプリケーションデータボリュームのポイントインタイムコピーを取得します。これにより、異なる AWS リージョン でアプリケーションのワークロードを迅速に起動したり、データ保護や災害復旧の要件を満たすことができます。ユーザーが異なる AWS リージョンやアカウント間で AWS ワークロードを移行する際、セキュリティと規制コンプライアンスは依然として最優先事項であり、きめ細かなアクセス制御を可能にする API コールのリソースレベルアクセス制御が求められます。 今回、Amazon EBS は CreateVolume アクションのリソースレベル権限を強化し、ボリューム作成時にソーススナップショットの AWS Identity and Access Management（IAM） ポリシーでリソースレベルの追加権限を指定できるようになりました。この機能強化によりユーザーは、どの AWS IAM 認証情報がソーススナップショットから Amazon EBS ボリュームを作成できる か制御したり、ソーススナップショットを Amazon EBSボリューム の作成に使用できる条件を定義することができます。 この記事では、リソースレベル権限における変更を説明し、その実装ユースケースを検討し、この改善された権限モデルを採用することの重要性について議論します。また、以前のリソースレベル権限モデルから移行するための計画も提供します。 何が変わったのでしょうか？ ソーススナップショットからボリュームを作成または復元する場合、AWS IAM ポリシーを使用して、CreateVolume アクションを実行する権限を付与する必要があります。以前は、AWS IAM ポリシーの CreateVolume アクションには、作成されるボリュームの権限が必要であり、ソーススナップショットは AWS IAM ポリシーの CreateVolume アクションのリソースコンテキストに含まれていませんでした。今回のアップデートにより、作成されるボリュームとソーススナップショットの両方に対してリソースレベルの権限を強制できるようになりました。また、ソーススナップショットの特定の権限要件を満たすために、 Amazon Elastic Compute Cloud（Amazon EC2） 固有の5つの条件キー（ec2:Encrypted、ec2:VolumeSize、ec2:Owner、ec2:ParentVolume、ec2:SnapshotTime）も使用できます。さらに、AWS IAM ポリシーでソーススナップショットの グローバル条件キー を使用することもできます。作成するボリュームに Amazon Resource Name（ ARN ）を使用してリソースステートメントを既に追加している場合は、スナップショットのリソースステートメントも明示的に指定する必要があります。以下の例を見てみましょう。 以前のポリシー: ボリュームリソースの作成を許可するポリシーが必要でした。 { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": "arn:aws:ec2:*:*:volume/*" } 今回のアップデート後に必要なポリシー: ボリュームとソーススナップショットの両方を許可するポリシーが必要になりました。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": "arn:aws:ec2:*:*:volume/*" }, { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": "arn:aws:ec2:*:*:snapshot/*" } ] } ソーススナップショットのリソースレベルの追加権限で何ができますか？ 新しいリソースレベル権限モデルへ移行すると、2 つのメリットがあります: 1/ アクセス制御の粒度が強化 ソーススナップショットのリソースレベルの権限は、ボリュームの作成に使用できるスナップショットをきめ細かく制御します。条件を指定することで、個々のスナップショットまたはカテゴライズされたスナップショットに対して、権限を設定できます。例えば、特定の AWS アカウントが所有する機密データを含むワークロードの定期的なバックアップとして Amazon EBS スナップショットを取得する場合、この新しい権限モデルを使用して、許可されたユーザーが所有するスナップショットだけにボリュームの作成を制限することができます。 ポリシーの例: 1. 自分の組織に所属するスナップショットからのボリュームの作成のみを許可します。 { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": [ "arn:aws:ec2:*:*:volume/*", "arn:aws:ec2:*::snapshot/snap-1234567890abcdef0" ], "Condition": { "StringEquals": { "aws:ResourceOrgId": "&lt;your organization ID&gt;" } } } 2. 自分のアカウントに所属するスナップショットからのボリュームの作成のみを許可します。 { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": [ "arn:aws:ec2:*:*:volume/*", "arn:aws:ec2:*::snapshot/snap-1234567890abcdef0" ], "Condition": { "StringEquals": { "aws:ResourceAccount": "&lt;your account ID&gt;" } } } 3. 特定のタグを持つスナップショットからのみボリュームの作成を許可します。 { "Statement": [ { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": [ "arn:aws:ec2:*::snapshot/*" ], "Condition": { "StringEquals": { "aws:ResourceTag/classification": "not-sensitive", "aws:ResourceOrgId": "&lt;your organization ID&gt;" } } }, { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": "arn:aws:ec2:*:*:volume/*" } ] } 2/ リソースとコストの最適化 この追加された権限は、セキュリティとコンプライアンス要件を強化するだけでなく、リソースの優先順位付けとコスト最適化のための強力なツールにもなります。スナップショットの取得時期や暗号化の状態などの条件を指定することで、ボリュームを作成する際にどのスナップショットを優先するかを制御できます。例えば、より新しいスナップショットや暗号化されたスナップショットを、他のスナップショットよりも優先させることができます。これにより、リソースの使用をビジネスの優先順位に合わせながら、セカンダリリージョンのボリュームをリストアするなどのバックアップ戦略を合理化することができます。 ポリシーの例: 1. 暗号化されたスナップショットからのボリュームの作成のみを許可します。 { "Statement": [ { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": [ "arn:aws:ec2:*::snapshot/*" ], "Condition": { "Bool": { "ec2:Encrypted": "true" } } }, { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": "arn:aws:ec2:*:*:volume/*" } ] } 2. 2025-01-01 00:00:00 以降に取得したスナップショットからのボリュームの作成のみを許可します。 { "Statement": [ { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": [ "arn:aws:ec2:*::snapshot/*" ], "Condition": { "DateGreaterThan": { "ec2:SnapshotTime": "2025-01-01T00:00:00Z" } } }, { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": "arn:aws:ec2:*:*:volume/*" } ] } 今回のアップデートに対してどのような準備が必要ですか？ ほとんどの AWS ユーザーは今回のアップデートの影響を受けません。今回のアップデートによる影響を受けるポリシーが適用されていることを検出した場合、電子メールと AWS Health ダッシュボードを利用してお知らせしています。影響を受けるアカウントは現在許可リストに登録されており、2025 年 2 月 17 日までは以前のポリシーが適用されます。2025 年 2 月 17 日から、AWS IAM ポリシーを更新したアカウントを AWS はその許可リストから除外し始めます。そして、2025 年 5 月 17 日がすべてのアカウントが新しい許可モデルに移行する最終期限となります。2025 年 5 月 17 日以降、AWS IAM ポリシーの更新を行わなかった場合、CreateVolume API の呼び出しが拒否される可能性があります。 タイムライン: 2025 年 2 月 17 日より、AWS IAM ポリシーを更新したアカウントから順に、AWS は許可リストから削除し始めます。 2025 年 5 月 17 日が、すべてのアカウントが新しい権限モデルに移行する最終期限となります。 影響を受けるポリシーを特定し、更新します: AWS CloudTrail のログを確認するか、IAM get-account-authorization-details CLI コマンドを実行して、CreateVolume アクションなどのすべての AWS IAM ポリシーを一覧表示し、関連するポリシーを特定することができます。一般的に、更新が必要なポリシーは以下の 2 つのカテゴリに分類されます。 カテゴリ 1: スナップショットリソースの許可ステートメントがありません。 ポリシーの Resource 要素でボリュームのみ許可している場合、スナップショットリソースも許可する必要があります。次のコード例を見てください。 { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": "arn:aws:ec2:*:*:volume/*" } 更新後のコードブロックは次のようになります。 { "Statement": [ { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": "arn:aws:ec2:*:*:volume/*" }, { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": "arn:aws:ec2:*::snapshot/snap-1234567890abcdef0" } ] } 同様の AWS マネージドポリシーの例として、 AWSElasticDisasterRecoveryServiceRolePolicy があります。 カテゴリ2: Resource 要素でボリュームとスナップショットの両方が許可されていますが、Condition はボリュームにのみ適用されます。 ポリシーの Resource 要素にボリュームとスナップショットの両方に一致するワイルドカードが使用されており、特定のボリュームに関する Condition 要素が含まれている場合は、 Resource 要素をボリュームにのみ適用するように変更し、スナップショットを許可する新しいステートメントを追加する必要があります。 以下は以前のポリシーのうち、今回のアップデート後に機能しなくなる例です。 { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": "*", "Condition": { "StringLike": { "aws:RequestTag/CSIVolumeName": "*" } } } ポリシーを機能させるには、以下のように変更します。 { "Statement": [ { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": "arn:aws:ec2:*:*:volume/*", "Condition": { "StringLike": { "aws:RequestTag/CSIVolumeName": "*" } } }, { "Effect": "Allow", "Action": "ec2:CreateVolume", "Resource": "arn:aws:ec2:*::snapshot/snap-1234567890abcdef0" } ] } 同様の AWS マネージドポリシーの例として、 AmazonEBSCSIDriverPolicy があります。 DryRun モードを使用し更新を検証します AWS IAM ポリシーが正しいかどうかを検証する必要がある場合、DryRun モードを使用してテストします。DryRun モードでは、実際には許可リストに含まれ API が古い権限モデルに従う場合でも、新しい権限モデルでの認可結果を確認することができます。DryRun モードを使用するには、AWS Command Line Interface（AWS CLI）コマンドまたは Amazon EBS CreateVolume API コールで -dry-run パラメータを指定します。DryRun モードを使用する CreateVolume API コールは常に エラー を返します。DryRunOperation を伴うエラーが返された場合は、AWS IAM ポリシーが新しい権限モデルで動作することを意味します。UnauthorizedOperation を伴うエラーが返された場合には、AWS IAM ポリシーを更新する必要があります。DryRun モードの詳細については、 AWS CLI のドキュメント を参照してください。 まとめ リソースレベルの権限に関するアップデートは、セキュリティ、制御、および運用の柔軟性を強化します。現在、古いアクセス許可モデルを使用しており、引き続きそれを使用する必要がある場合は、AWS サポートに連絡してユースケースへの対応を求めることができます。2025 年 2 月 17 日までに新しい許可ポリシーに移行する準備ができている場合は、AWS サポートに許可リストから削除するように依頼することもできます。今回の変更は、CopySnapshot のような他のアクションでも同様の許可を可能にする、より広範な取り組みの一部です。 サポートされている条件キーの詳細については、 ドキュメント .を参照してください。この投稿に関するフィードバックがある場合は、コメント欄で送信するか、AWS サポートに連絡してください。Amazon EBS ボリュームとスナップショットの詳細については、 Amazon EBS ユーザーガイド を参照してください。 <!-- '"` --> TAGS: Amazon EBS , Amazon EC2 , Amazon Elastic Block Storage (Amazon EBS) , AWS Identity and Access Management (IAM) Emma Fu Emma Fu は Amazon EBS チームの Senior Technical Product Manager です。バックアップ、セキュリティ、AI における新たなユースケースの探求に情熱を注いでいます。仕事以外では、家族と過ごす時間、料理、ワインテイスティングを楽しんでいます。 Matt Luttrell Matt は AWS Identity Solutions チームの Principal Solutions Architect です。子供を追いかけまわしている時間以外は、スキー、サイクリング、そして、たまにビデオゲームも楽しんでいます。

お客様は常に 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 &amp; 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 クラウドに活かせることに興奮しています。仕事以外では、父親であること、料理をすること、ゴルフをすること、ハイキングをすることが大好きです。 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文は こちら です。

この記事は、 Cost Optimized Vector Database: Introduction to Amazon OpenSearch Service quantization techniques を翻訳したものです。 生成 AI アプリケーションの台頭により、セマンティック検索と自然言語検索を実装する必要性が高まっています。これらの高度な検索機能は、企業のコンテンツリポジトリから概念的に関連する文書を検索し、生成 AI モデルのプロンプトとして取得するのに役立ちます。テキスト、画像、音声、動画などの様々なソースリポジトリ内の生データは、埋め込みモデルを使用して、セマンティック検索と自然言語検索を支える標準的な数値表現である ベクトル に変換されます。組織がより高度な大規模言語モデルと基盤モデルを活用して生成 AI アプリケーションを強化するにつれ、補助的な埋め込みモデルも大規模で高次元のベクトル埋め込みを処理できるように進化しています。ベクトル量が拡大するにつれ、メモリ使用量と計算要件が比例して増加し、運用コストが高くなります。この問題を軽減するために、メモリ使用量と計算効率を最適化するための様々な圧縮技術を使用できます。 量子化は、計算量とメモリ使用量を削減し、特に大規模データワークロードのコストを下げることを目的とした、非可逆圧縮技術です。データの種類と量に応じて、様々な圧縮手法があります。一般的な手法は、無限の値 (または比較的大きな有限値のリスト) をより小さな離散値にマッピングすることです。ベクトル圧縮には、主に直積量子化とスカラー量子化の 2 つの手法があります。直積量子化の手法では、元のベクトル次元の配列を複数のサブベクトルに分割し、それぞれのサブベクトルを固定ビット数でエンコードして元のベクトルを表現します。この方法では、元のベクトルではなく、エンコードされたサブベクトルのみを保存し、検索する必要があります。スカラー量子化では、入力ベクトルの各次元が、32 ビット浮動小数点表現からより小さなデータ型にマッピングされます。 Amazon OpenSearch Service は、ベクトルデータベースとして、スカラー量子化と直積量子化の手法をサポートし、メモリ使用量を最適化して運用コストを削減します。 ベクトルデータベースとしての OpenSearch OpenSearch は、分散型の検索および分析サービスです。OpenSearch の k 最近傍 (k-NN) プラグインを使用すると、ベクトルのインデックス作成、保存、検索できます。ベクトルは knn_vector 型の 32 ビット浮動小数点数配列として OpenSearch に保存され、1 ベクトルあたり最大 16,000 次元までサポートしています。 OpenSearch は、スケーラブルなベクトル検索を提供するために、近似最近傍検索を使用します。近似 k-NN アルゴリズムは、与えられたクエリベクトルに最も近いベクトルを推定して結果を取得します。近似 k-NN を実行する主な手法として、グラフベースの Hierarchical Navigable Small-World (HNSW) とクラスターベースの Inverted File (IVF) の 2 つがあります。これらのデータ構造は、最初のベクトル検索操作中に構築され、メモリにロードされます。ベクトルの量が増加すると、データ構造と検索処理に必要なメモリも比例して増加します。 例えば、32 ビットの浮動小数点データを使用する各 HNSW グラフは、約 1.1 * (4 * d + 8 * m) * num_vectors バイトのメモリを消費します。ここで、 num_vectors はインデックス化するベクトルの総数を表し、 d はベクトルを生成するために使用する埋め込みモデルによって決定される次元数、 m は HSNW グラフの辺の数で、パフォーマンスを調整するためのインデックスパラメータです。この式を使用すると、384 次元で m が 16 の構成におけるベクトル格納のメモリ要件は次のようになります。 100 万ベクトル: 1.830 GB (1.1 * (4 * 384 + 8 * 16) * 1,000,000 バイト) 10 億ベクトル: 1830 GB (1.1 * (4 * 384 + 8 * 16) * 1,000,000,000 バイト) 近似最近傍検索は、数十億ものベクトルを含む大規模データセットを効率的に処理するように最適化できますが、検索処理中に 32 ビットの完全な精度のベクトルをロードするためのメモリ要件が非常に高くなる可能性があります。この問題を緩和するために、OpenSearch Service では次の 4 つの量子化手法をサポートしています。 バイナリ量子化 バイト量子化 FP16 量子化 直積量子化 これらの手法は、前述のスカラー量子化とプロダクト量子化の広範なカテゴリに含まれます。この投稿では、OpenSearch Service でベクトルワークロードを最適化するための量子化手法について、メモリ削減とコスト効率に焦点を当てて説明します。メモリにロードせずにディスクに保存されたベクトルを効率的にクエリできる、新しいディスクベースのベクトル検索アプローチを紹介します。この手法は、 on_disk モードや compression_level パラメータなどの主要な設定を備え、量子化手法とシームレスに統合されています。これらの設定により、インデックス作成時に組み込みのスカラー量子化がすぐに利用できます。 バイナリ量子化 (最大 32 倍の圧縮) バイナリ量子化 (BQ) はスカラー量子化の一種です。OpenSearch は FAISS エンジンのバイナリ量子化を活用し、インデックス作成時に最大 32 倍の圧縮を可能にしています。この手法では、デフォルトの 32 ビット浮動小数点からベクトルを 0 と 1 に圧縮することで、ベクトル次元を 1 ビットのバイナリに削減します。OpenSearch はバイナリベクトルのインデックス作成、保存、検索をサポートしています。また、下の例に示すように、目的の圧縮率に応じて、各ベクトル次元を 1、2、または 4 ビットでエンコードすることもできます。圧縮率は bits 設定で調整できます。2 の値では 16 倍の圧縮、4 の値では 8 倍の圧縮になります。デフォルト設定は 1 です。バイナリ量子化では、インデックス作成時に自動的に学習が行われるため、追加の前処理ステップは不要です。 バイナリ量子化を実装するには、ベクトル型を knn_vector と定義し、 encoder を binary に指定して、エンコードするビット数 bits を指定します。encoder パラメータは、インデックスに格納する前にベクトルデータを圧縮する方法を指す点に注意してください。パフォーマンスを最適化するために、 space_type 、 m 、 ef_construction パラメータを使用します。近似 k-NN の基盤となる設定の詳細については、 OpenSearch のドキュメント を参照してください。 PUT my-vector-index { "settings": { "index.knn": true }, "mappings": { "properties": { "my_vector_field": { "type": "knn_vector", "dimension": 8, "method": { "name": "hnsw", "engine": "faiss", "space_type": "l2", "parameters": { "m": 16, "ef_construction": 512, "encoder": { "name": "binary", "parameters": { "bits": 1 } } } } } } } } FAISS-HNSW を使用したバイナリ量子化の実装におけるメモリ要件はこのようになります。 1.1 * (bits * (d/8)+ 8 * m) * num_vectors バイト 圧縮率 エンコードビット数 10 億ベクトルのメモリ要件 (d=384, m=16, GB単位) 32x 1 193.6 16x 2 246.4 8x 4 352.0 バイナリ量子化の詳細な実装手順については、 OpenSearch のドキュメント を参照してください。 バイト量子化 (4 倍の圧縮) バイト量子化は、32 ビットの浮動小数点次元を -128 から + 127 の範囲の 8 ビット整数に圧縮し、メモリ使用量を 75% 削減します。OpenSearch では、バイトベクトルのインデックス作成、格納、検索がサポートされており、取り込む前に 8 ビット形式に変換する必要があります。バイトベクトルを実装するには、インデックスマッピングで k-NN ベクトルフィールドの data_type を byte と指定します。この機能は Lucene エンジンと FAISS エンジンの両方と互換性があります。バイト量子化ベクトルのインデックスを作成する例を次に示します。 PUT /my-vector-index { "settings": { "index": { "knn": true, "knn.algo_param.ef_search": 100 } }, "mappings": { "properties": { "my_vector": { "type": "knn_vector", "dimension": 3, "data_type": "byte", "space_type": "l2", "method": { "name": "hnsw", "engine": "faiss", "parameters": { "ef_construction": 100, "m": 16 } } } } } } この方法では、バイト量子化ベクトルを OpenSearch に取り込み、k-NN ベクトルフィールド (バイト型) に直接格納する必要があります。しかし、最近導入されたディスクベースのベクトル検索機能により、外部ベクトル量子化の必要がなくなりました。このブログの後半で、この機能について詳しく説明します。 FAISS-HNSW でバイト量子化を実装するためのメモリ要件はこのようになります。 1.1 * (1 * d + 8 * m) * num_vectors バイト 詳細な実装手順については、 OpenSearch のドキュメント を参照してください。精度、スループット、レイテンシーに関するパフォーマンスメトリクスについては、 OpenSearch のバイト量子化ベクトル を参照してください。 FAISS FP16 量子化 (2 倍の圧縮) FP16 量子化は、16 ビットの浮動小数点スカラー表現を使用する手法で、メモリ使用量を 50% 削減します。各ベクトル次元は 32 ビットから 16 ビットの浮動小数点に変換され、メモリ要件が実質的に半分になります。圧縮されたベクトル次元は [-65504.0、65504.0] の範囲内でなければなりません。FP16 量子化を実装するには、k-NN ベクトルフィールドでインデックスを作成し、以下を構成します。 k-NN ベクトルフィールドのメソッドを HNSW に、エンジンを FAISS に設定します。 エンコーダーパラメーターを定義し、 name を sq 、 type を fp16 に設定します。 32 ビット浮動小数点ベクトルを OpenSearch にアップロードすると、スカラー量子化 FP16 (SQfp16) が自動的に取り込み時にそれらを 16 ビット浮動小数点ベクトルに量子化し、ベクトルフィールドに格納します。次の例は、FP16 量子化ベクトルを量子化して格納するためのインデックス作成方法を示しています。 PUT /my-vector-index { "settings": { "index": { "knn": true, "knn.algo_param.ef_search": 100 } }, "mappings": { "properties": { "my_vector1": { "type": "knn_vector", "dimension": 3, "space_type": "l2", "method": { "name": "hnsw", "engine": "faiss", "parameters": { "encoder": { "name": "sq", "parameters": { "type": "fp16", "clip": true } }, "ef_construction": 256, "m": 8 } } } } } } FAISS-HNSW を使用して FP16 量子化を実装するためのメモリ要件は以下のようになります。 (1.1 * (2 * d + 8 * m) * num_vectors) バイト 前述の FP16 の例では、 clip というオプショナルな Boolean パラメータが導入されています。これはデフォルトで false に設定されています。false の場合、範囲外の値 (-65504.0 から + 65504.0 の範囲外の値) を持つベクトルは拒否されます。clip を true に設定すると、範囲外のベクトル値がサポートされる範囲内に丸められます。実装手順の詳細については、 OpenSearch のドキュメント を参照してください。精度、スループット、レイテンシーに関するパフォーマンスメトリクスについては、 Optimizing OpenSearch with Faiss FP16 scalar quantization: Enhancing memory efficiency and cost-effectiveness を参照してください。 直積量子化 直積量子化 (PQ) は、圧縮レベルを大幅に高めることができる高度な次元削減手法です。従来のスカラー量子化手法は通常 32 倍までの圧縮しか実現できませんが、PQ では最大 64 倍の圧縮が可能なため、ストレージとコストの最適化においてより効率的なソリューションとなります。OpenSearch は、FAISS エンジンの IVF および HNSW の両方の手法で PQ をサポートしています。直積量子化は、ベクトルを m 個のサブベクトルに分割し、各サブベクトルをコードサイズで決まるビット数でエンコードします。結果として得られるベクトルのメモリ使用量は m * code_size ビットになります。 FAISS における直積量子化のプロセスは、以下の 3 つの主要なステップで構成されます。 PQ モデルを構築するためのトレーニングインデックスを作成し、データを投入して精度を最適化する。 トレーニングインデックスに対して _train API を実行し、量子化モデルを生成する。 ベクトルインデックスを作成し、kNN フィールドを準備した量子化モデルで構成する。 以下の例では、直積量子化のセットアップ手順を 3 つのステップで説明します。 ステップ 1: トレーニングインデックスを作成します。トレーニングインデックスの仕様と次元数が合うように、適切なデータセットでトレーニングインデックスを構築します。トレーニングインデックスには最低 256 件のドキュメントが必要であることに注意してください。 PUT /train-index { "settings": { "number_of_shards": 1, "number_of_replicas": 2 }, "mappings": { "properties": { "train-field": { "type": "knn_vector", "dimension": 4 } } } } ステップ 2: 先ほど作成したトレーニングインデックスに対して _train API を実行し、my-model という名前の量子化モデルを作成します。 name が pq と定義された encoder では、ネイティブのベクトル量子化が適用されます。エンコーダーの他のパラメーターには code_size と m があります。FAISS-HNSW では code_size を 8 に設定し、少なくとも 256 ( 2^code_size ) 件のドキュメントからなるトレーニングデータセットが必要です。パラメーターの詳細な仕様については、 PQ パラメータ を参照してください。 POST /_plugins/_knn/models/my-model/_train { "training_index": "train-index", "training_field": "train-field", "dimension": 4, "description": "My test model description", "method": { "name": "hnsw", "engine": "faiss", "parameters": { "encoder": { "name": "pq", "parameters": { "code_size":8, "m":2 } }, "ef_construction": 256, "m": 8 } } } ステップ 3: ベクトルインデックスに量子化モデルをマッピングします。 PUT /my-vector-index { "settings": { "number_of_shards": 1, "number_of_replicas": 2, "index.knn": true }, "mappings": { "properties": { "target-field": { "type": "knn_vector", "model_id": "my-model" } } } } 新しく作成したインデックス my-vector-index にデータセット全体を取り込みます。エンコーダーは、受け取ったベクトルを自動的に処理し、量子化モデルの設定で指定された圧縮パラメータ（ code_size と m ）に基づいてエンコードおよび量子化を適用します。 FAISS-HNSW を使用した直積量子化を実装するためのメモリ要件はこのようになります。 1.1 * (((code_size / 8) * m + 24 + 8 * m) * num_vectors バイト ここで code_size と m はエンコーダーパラメータ内のパラメータ、 num_vectors はベクトルの総数です。 量子化処理では、各トレーニングベクトルは設定可能な値 m で定義された複数のサブベクトルまたはサブスペースに分割されます。各サブベクトルをエンコードするビット数は、パラメータ code_size によって決まります。次に、各サブベクトルは k-means クラスタリングを実行してそれぞれ圧縮・量子化されます。この際、クラスタの数 k は 2^code_size と定義されます。この手法では、ベクトルは約 m * code_size ビットで圧縮されます。 直積量子化の詳細な実装手順や設定可能なパラメータについては、 OpenSearch ドキュメント を参照してください。FAISS IVF を使用した PQ の精度、スループット、レイテンシーに関するパフォーマンス指標については、 OpenSearch における 10 億規模のユースケースに適した k-NN アルゴリズムの選定 を参照してください。 ディスクベースのベクトル検索 ディスクベースのベクトル検索は、圧縮されたベクトルをメモリ内で使用しながら、完全な精度のベクトルをディスク上に保持することで、クエリの効率を最適化します。このアプローチにより、OpenSearch は大規模なベクトルデータセットをメモリに完全に読み込む必要がなくなり、スケーラビリティとリソースの効率が向上します。この機能は、インデックス作成時に設定できる mode と compression level という 2 つの新しい構成オプションによって実装されます。OpenSearch 2.17 以降では、インデックス作成時に mode パラメータを in_memory または on_disk に設定できます。これまで説明した手法はデフォルトで in-memory モードになります。この構成では、ベクトルインデックスがグラフ (HNSW) またはバケット (IVF) 構造を使用して構築され、検索操作時にネイティブメモリにロードされます。この方法は優れた再現率を提供しますが、メモリ使用量に影響を与え、大量のベクトル処理に対するスケーラビリティが低下する可能性があります。 on_disk モードは、インデックス作成時にリアルタイムのネイティブ量子化を使用しながら、完全な精度のベクトルをディスクに保存することで、ベクトル検索の効率を最適化します。調整可能な圧縮レベルと組み合わせることで、圧縮されたベクトルのみをメモリにロードするため、メモリおよびリソースの利用効率が向上し、検索パフォーマンスが改善されます。以下の圧縮レベルは、前述の様々なスカラー量子化手法に対応しています。 32 倍: バイナリ量子化 (1 ビット次元) 4 倍: バイトおよび整数量子化 (8 ビット次元) 2 倍: FP16 量子化 (16 ビット次元) この手法は、in_memory モードでは利用できない 16x や 8x などの他の圧縮レベルもサポートしています。ディスクベースのベクトル検索を有効にするには、次の例のように mode を on_disk に設定してインデックスを作成します。 PUT /my-vector-index { "settings" : { "index": { "knn": true } }, "mappings": { "properties": { "my_vector_field": { "type": "knn_vector", "dimension": 8, "space_type": "innerproduct", "data_type": "float", "mode": "on_disk" } } } } モードを on_disk に設定するだけでは、デフォルトの構成が適用され、FAISS エンジンと HNSW メソッドが使用され、32 倍の圧縮レベル (1 ビット、バイナリ量子化) が使用されます。インデックス作成時の待ち時間を最適化する ef_construction のデフォルト値は 100 です。より細かい微調整を行う場合は、次の例のように、これらの k-NN パラメータを上書きできます。 PUT /my-vector-index { "settings" : { "index": { "knn": true } }, "mappings": { "properties": { "my_vector_field": { "type": "knn_vector", "dimension": 8, "space_type": "innerproduct", "data_type": "float", "mode": "on_disk", "compression_level": "16x", "method": { "name": "hnsw", "engine": "faiss", "parameters": { "ef_construction": 512 } } } } } } 量子化は非可逆圧縮の手法なので、圧縮率が高くなるほど再現率が低下する傾向があります。量子化時の再現率を改善するには、次の例のように、検索時の設定パラメータ ef_search と oversample_factor を使って、ディスクベースのベクトル検索を 2 段階で実行するよう設定できます。 GET my-vector-index/_search { "query": { "knn": { "my_vector_field": { "vector": [1.5, 2.5, 3.5, 4.5, 5.5, 6.5, 7.5, 8.5], "k": 5, "method_parameters": { "ef_search": 512 }, "rescore": { "oversample_factor": 10.0 } } } } } 最初の段階では、メモリ内の量子化ベクトルから oversample_factor * k 個の結果を取得し、スコアを近似計算します。次の段階では、その oversample_factor * k 個の結果の完全な精度ベクトルをディスクからメモリにロードし、完全な精度のクエリベクトルと比較してスコアを再計算します。その後、結果は上位 k 個に絞られます。 リスコア用の oversample_factor は、インデックス作成時に設定された次元数と圧縮レベルによって決まります。次元が 1,000 未満の場合、係数は 5 に固定されます。1,000 を超える次元の場合、デフォルトのファクターは圧縮レベルに基づいて変わり、次の表のようになります。 圧縮レベル リスコア用の oversample_factor のデフォルト値 32x (デフォルト) 3 16x 2 8x 2 4x デフォルトのリスコアリングなし 2x デフォルトのリスコアリングなし 前述のように、 oversample_factor は検索時に動的に調整できます。この値は、精度と検索効率の間の重要なトレードオフを表します。高い値を設定すると精度は向上しますが、メモリ使用量が比例して増加し、検索スループットが低下します。ディスクベースのベクトル検索と oversample_factor の適切な使用方法を理解するには、 OpenSearch のドキュメント を参照してください。 量子化手法のパフォーマンス評価: メモリ使用量、再現率、クエリレイテンシーの検証 OpenSearch の近似 k-NN 検索に関するドキュメント は、ベクトル類似度検索を実装する際の出発点となります。さらに、 OpenSearch における 10 億規模のユースケースに適した k-NN アルゴリズムの選定 では、本番環境で数十億規模のベクトルを扱うための効率的なベクトルワークロードの設計に関する貴重な洞察が得られます。この記事では、メモリ使用量を削減し、コストを抑える手法として、直積量子化技術を導入することを提案しています。 次の表は、さまざまな量子化手法を使用して 10 億ベクトルを保存および検索する際のメモリ要件を示しています。この表は、HNSW を使用した完全な精度ベクトルのデフォルトのメモリ消費量と、量子化されたベクトルのメモリ消費量を比較しています。この分析で使用されたモデルは sentence-transformers/all-MiniLM-L12-v2 で、384 次元で動作します。生のメタデータは 100GB 以下と想定されています。 量子化なし (GB 単位) 直積量子化 (GB 単位) スカラー量子化 (GB 単位) FP16 ベクトル バイトベクトル バイナリベクトル m 16 16 16 16 16 pq_m、code_size – 16, 8 – – – ネイティブメモリ消費量 (GB) 1830.4 184.8 985.6 563.2 193.6 合計ストレージ = 100 GB + ベクトル 1930.4 284.8 1085.6 663.2 293.6 前の表を見直すと、10 億ベクトルのデータセットに対して、32 ビットの完全な精度のベクトルを使用する HNSW グラフでは約 1830 GB のメモリが必要になることがわかります。直積量子化などの圧縮技術を使えば、これを 184.8 GB に削減できます。一方、スカラー量子化では、さまざまなレベルの圧縮が可能です。次の表は、圧縮手法とコスト削減、再現率、クエリレイテンシーなどの主要パフォーマンス指標への影響の相関関係をまとめたものです。この分析は、上記のメモリ使用量の評価に基づいており、要件を満たす圧縮手法を選択する際の助けとなります。 この表には、2 つの主要な検索メトリクスが示されています。90 パーセンタイル (p90) での検索レイテンシーと、上位 100 件における再現率です。 検索レイテンシー@p90 – 90% の検索クエリがその特定のレイテンシー時間以内に完了することを示します。 recall@100 – 上位 100 件の正解となる近傍点のうち、返された 100 件の結果に含まれる割合です。 量子化なし (GB 単位) 直積量子化 (GB 単位) スカラー量子化 (GB 単位) FP16 量子化 [mode=in_memory] バイト量子化 [mode=in_memory] バイナリ量子化 [mode=on_disk] 前提条件/データセット すべてのデータセットに適用可能 再現率は学習データの性質に依存 次元値が [-65536 から 65535] の範囲内で動作 次元値が [-128 から 127] の範囲内で動作 次元数 &gt;= 768 の場合に適している 前処理の必要性 なし あり (前処理/学習が必要) なし なし なし リスコアリング なし なし なし なし あり 再現率 @100 &gt;=0.99 &gt;0.7 &gt;=0.95 &gt;=0.95 &gt;=0.90 p90 クエリレイテンシー (ms) &lt;50 ms &lt;50 ms &lt;50 ms &lt;50 ms &lt;200 ms コスト (ベースライン $X) $X $0.1*X (最大 90% の削減) $0.5*X (最大 50% の削減) $0.25*X (最大 75% の削減) $0.15*X (最大 85% の削減) 10 億ベクトルのサンプルコスト $20,923.14 $2,092.31 $10,461.57 $5,230.79 $3,138.47 10 億ベクトルのサンプルコストの見積もりは、コストを最適化された構成に基づいています。ただし、実際の削減額は、ワークロードの要件と選択した構成のパラメータによって異なる可能性があることにご注意ください。特に表では、直積量子化を使用すると、ベースラインの HNSW グラフベースのベクトル検索コスト ($X) と比較して最大 90% のコスト削減が可能です。スカラー量子化も同様に、圧縮されたメモリ使用量に応じて 50% から 85% の比例的なコスト削減をもたらします。圧縮手法の選択には、コスト効率、精度、パフォーマンスのバランスが関係し、精度やレイテンシーに影響を与えます。 結論 OpenSearch の量子化手法を活用することで、組織はコスト効率、パフォーマンス、再現率のバランスを考慮した選択が可能になり、最適な結果を得るためにベクトルデータベースの操作を微調整できるようになります。これらの量子化手法は、メモリ要件を大幅に削減し、クエリの効率を向上させ、シームレスな圧縮のための組み込みエンコーダーを提供します。大規模なテキスト埋め込み、画像特徴量、その他の高次元データのいずれを扱う場合でも、OpenSearch の量子化手法はベクトル検索の要件に対する効率的なソリューションを提供し、コスト効率が高く、スケーラブルで高性能なシステムの開発を可能にします。 ベクトルデータベースプロジェクトを進める際は、以下のことをお勧めします。 OpenSearch の圧縮手法を詳しく検討する。 特定のユースケースに適した手法の適用可能性を評価する。 再現率と検索レイテンシーの要件に基づいて適切な圧縮レベルを決定する。 精度、スループット、レイテンシーに基づいてコスト削減効果を測定し比較する。 この分野は急速に進化しているため、最新の技術動向を常に把握し、さまざまな量子化技術を試すことで、コスト・パフォーマンス・精度の最適なバランスを見つけることが重要です。

この記事は、 OpenSearch Vector Engine is now disk-optimized for low cost, accurate vector search を翻訳したものです。 OpenSearch ベクトルエンジンは、OpenSearch 2.17 以降のドメインで、従来の 3 分の 1 のコストでベクトル検索を実行できるようになりました。k-NN (ベクトル) インデックスをディスクモードで実行するように設定し、メモリに制約のある環境に最適化することで、数百ミリ秒単位で応答する低コストで正確なベクトル検索が可能になりました。ディスクモードは、 一桁ミリ秒に近いレイテンシー を求めない場合、従来のメモリモードの経済的な代替手段となります。 本記事では、この新機能の利点、基本的な仕組み、お客様の成功事例、そして始め方についてご紹介します。 ベクトル検索と OpenSearch ベクトルエンジンの概要 ベクトル検索は、機械学習 (ML) モデルによってベクトル (数値エンコーディング) にエンコードされたコンテンツに対して類似性検索を実行することで、検索の精度を向上させる手法です。これによりセマンティック検索のようなユースケースが可能になり、キーワードだけでなくコンテキストや意図も考慮した、より関連性の高い検索結果を提供できます。 OpenSearch ベクトルエンジンは、ベクトル化されたコンテンツに対してインデックスを作成することで、数十億のベクトルを超えるリアルタイムのベクトル検索を可能にします。これにより、質問、キーワード、または ML モデルによってエンコードされた画像・音声クリップ・テキストなどのコンテンツに対して、最も類似する上位 K 件のドキュメントを検索できます。 OpenSearch ベクトルエンジンのチューニング 検索アプリケーションには、速度、品質、コストに関してさまざまな要件があります。例えば、e コマースのカタログでは、購買体験を向上させるために、できるだけ短い応答時間と高品質な検索が求められます。しかし、検索の品質とパフォーマンスを最適化するには、追加のメモリやコンピューティングリソースが必要となり、コストが発生します。 速度、品質、コストの適切なバランスは、ユースケースとお客様の期待することによって異なります。OpenSearch ベクトルエンジンには包括的なチューニングオプションが用意されているため、独自の要件に応じた最適な結果を得るためのトレードオフのバランスを柔軟に調整できます。 以下のチューニングオプションを利用できます。 アルゴリズムとパラメータ – 以下が含まれます。 Hierarchical Navigable Small World (HNSW) アルゴリズムと、 ef_search 、 ef_construct 、 m などのパラメータ Inverted File Index (IVF) アルゴリズムと、 nlist 、 nprobes などのパラメータ Exact k-nearest neighbors (k-NN)、別名 brute-force k-NN (BFKNN) アルゴリズム エンジン – Facebook AI Similarity Search (FAISS)、Lucene、Non-metric Space Library (NMSLIB) 圧縮手法 – スカラー (バイト、半精度など)、バイナリ、直積量子化 類似度 (距離) 指標 – 内積、コサイン類似度、L1 距離、L2 距離、ハミング距離 ベクトル埋め込みタイプ – 可変次元の密ベクトルと疎 (スパース) ベクトル ランキングとスコアリング手法 – ベクトル検索、ハイブリッド検索 (ベクトルと Best Match 25 (BM25) スコアの組み合わせ)、マルチステージランキング (Cross-encoder や Personalizer など) これらのチューニングオプションを適切に組み合わせることで、ニーズに最適化された速度、品質、コストのバランスを実現できます。以下の図では、サンプル構成の大まかなパフォーマンスプロファイルを示しています。 ディスク最適化のチューニング OpenSearch 2.17 以降では、k-NN インデックスをディスクモードで実行できるようになり、インメモリのパフォーマンスと引き換えにレイテンシを高めることで、高品質かつ低コストなベクトル検索を実現できます。ユースケースの要件が 90 パーセンタイル (P90) のレイテンシー 100 〜 200 ミリ秒の範囲で満たされる場合、ディスクモードはコスト削減を実現しながら高い検索品質を維持するのに最適なオプションです。次の図は、さまざまなエンジン構成の中でのディスクモードのパフォーマンス特性を示しています。 ディスクモードは、すぐに利用できるように設計されており、メモリモードと比較して メモリ要件を 97% 削減 しながら高い検索品質を提供します。ただし、圧縮率とサンプリング率を調整することで、速度、品質、コストを調整できます。 以下の表は、ディスクモードのデフォルト設定におけるパフォーマンスベンチマークを示しています。最初の 3 つのテストには OpenSearch Benchmark (OSB) を使用し、最後の 2 つのテストには VectorDBBench (VDBB) を使用しました。最適な結果を得るために、 パフォーマンスチューニング のベストプラクティスを適用しています。小規模テスト (Tasb-1M と Marco-1M) は、1 つのレプリカを持つ単一の r7gd.large データノードで実行しました。その他のテストは、1 つのレプリカを持つ 2 つの r7gd.2xlarge データノードで実行しました。コスト削減率は、デフォルト設定と同等の適切なサイズのインメモリモードでのデプロイメントと比較して計算されています。 データセット Recall@100 (検索精度) p90 レイテンシー (ms) 次元数 ベクトル数 (百万) コスト削減率 モデル ソース Cohere TREC-RAG 0.94 104 1024 113 67% Cohere Embed V3 前処理済み Tasb-1M 0.96 7 768 1 83% msmacro-distilbert-base-tas-b 未処理 Marco-1M 0.99 7 768 1 67% msmarco-distilbert 未処理 OpenAI 5M 0.98 62 1536 5 67% text-embedding-ada-002 生成済み LAION 100M 0.93 169 768 100 67% CLIP 生成済み これらのテストは、ディスクモードが様々なデータセットとモデルで 32 倍の圧縮を実現し、目標レイテンシー (P90 200 ミリ秒未満) を維持しながら高い検索品質を提供できることを示すために設計されています。なお、これらのベンチマークは ML モデルの評価を目的としたものではありません。モデルが検索品質に与える影響は、データセットを含む複数の要因によって変わります。 ディスクモード最適化の仕組み ディスクモード で k-NN インデックスを実行するように構成すると、OpenSearch は自動的に量子化手法を適用し、ベクトルを圧縮しながらロードして圧縮インデックスを構築します。デフォルトでは、ディスクモードは、数百から数千の次元からなる完全な精度のベクトル (各次元が 32 ビット数値として格納されている) を、各次元を 1 ビットで表すバイナリベクトルに変換します。この変換により、32 倍の圧縮率が得られ、完全な精度のベクトルで構成されるインデックスと比較して 97% 小さいインデックスを構築できます。適切なサイズのクラスターであれば、この圧縮されたインデックスをメモリ内に保持できます。 圧縮によってベクトルエンジンのメモリ要件が削減されるため、コストは低くなりますが、その代償として精度が低下します。ディスクモードは、精度と検索品質を維持するために、2 段階の検索プロセスを使用しています。クエリ実行の最初の段階では、メモリ内の圧縮インデックスを効率的に走査して、候補となるベクトルを検索します。2 番目の段階では、これらの候補をもとに、対応する完全な精度のベクトルをオーバーサンプリングします。これらの完全な精度のベクトルは、I/O を削減し、ディスク検索の速度と効率を最適化するように設計されたフォーマットでディスクに格納されています。その後、この完全な精度のベクトルのサンプルを使用して、フェーズ 1 の検索結果を補強し、再スコアリング ( exact k-NN を使用) を行うことで、圧縮による検索品質の低下を防ぎます。ディスクモードのレイテンシがインメモリモードよりも高くなるのは、この再スコアリング処理によるものです。このプロセスでは、ディスクアクセスと追加の計算が必要となるため、相対的に処理時間が長くなります。 初期のお客様の成功事例 ベクトルエンジンのディスクモードは、すでに多くの企業で導入されています。ここでは、初期導入企業の事例を紹介します。 Asana は、OpenSearch のベクトルエンジンを通じてセマンティック検索機能を段階的に導入することで、ワークマネジメントプラットフォームにおける検索品質を向上させています。当初は 直積量子化 を使用してインデックスを 16 倍に圧縮することでデプロイを最適化しましたが、ディスク最適化構成に切り替えることで、検索品質とレイテンシーの目標を維持しながら、さらに 33% のコスト削減が可能になりました。このコスト構造の改善により、Asana は数十億ものベクトルにスケールし、プラットフォーム全体でセマンティック検索を民主化することが可能になりました。 DevRev は、顧客対応チームと開発者を直接つなぐことで、ソフトウェア企業の根本的なギャップを解消します。AI 中心のプラットフォームとして、顧客からのフィードバックから製品開発への直接的な経路を作り、1,000 社以上の企業が正確な検索、高速な分析、カスタマイズ可能なワークフローを活用して成長を加速できるようサポートしています。大規模言語モデル (LLM) と OpenSearch のベクトルエンジン上で実行される Retrieval Augmented Generation (RAG) フローに基づいて構築された DevRev は、インテリジェントな会話体験を実現します。 「OpenSearch のディスク最適化されたベクトルエンジンを使用することで、16 倍の圧縮を実現しつつ、検索品質とレイテンシーの目標を達成しました。OpenSearch は、当社の数十億ベクトル規模の検索において、スケーラブルで経済的な選択肢を提供してくれます。」 – Anshu Avinash, Head of AI and Search, DevRev OpenSearch ベクトルエンジンのディスクモードを利用開始する まず、インデックスをホストするために必要なリソースを決定する必要があります。デフォルトの 32 倍の圧縮率を使用したディスク最適化 k-NN インデックスをサポートするために必要なメモリを、次の式を使って見積もります。 必要なメモリ (バイト) = 1.1 x ((ベクトル次元数)/8 + 8 x m) x (ベクトル数) 例えば、 Amazon Titan Text V2 のデフォルト設定を使用する場合、ベクトルの次元数は 1024 になります。ディスクモードでは HNSW アルゴリズムを使用してインデックスを構築するため、「m」はアルゴリズムのパラメータの 1 つで、デフォルトは 16 です。10 億個のベクトルを持つコーパスを Amazon Titan Text でエンコードしてインデックスを作成する場合、必要なメモリは 282 GB となります。 高スループットのワークロードを扱う場合は、ドメインに十分な IOPS と CPU が確保されているかを確認する必要があります。デプロイのベストプラクティスに従えば、インスタンスストアとストレージ最適化インスタンスタイプを利用でき、一般的には十分な IOPS が得られます。高スループットワークロードの場合は必ず負荷テストを実施し、IOPS や CPU の要件を考慮して初期見積もりを調整してください。 今すぐ、ニーズに合わせて適切なサイズに設定された OpenSearch 2.17 + ドメインをデプロイできます。 k-NN インデックスを作成 する際に、 mode パラメータを on_disk に設定してから、 データを取り込んで ください。すでにデフォルトの in_memory モードで k-NN インデックスを実行している場合は、モードを on_disk に切り替えた後、 reindex 処理を実行することで変換できます。インデックスの再構築が完了したら、それに応じてドメインのサイズを調整してください。 結論 この記事では、OpenSearch ベクトルエンジンをディスクモードで実行することのメリット、お客様の成功事例、および導入の手順について説明しました。これで、従来のコストの 3 分の 1 まで抑えながら OpenSearch ベクトルを運用できる準備が整いました。 詳細は、 ドキュメント を参照してください。

今日、 AWS Amplify Hosting は、AWS Amplify アプリケーションの IAM Compute Roles を導入しました。これにより、コンピュート実行時から AWS サービスへの安全なアクセスを可能にし、サーバーサイドレンダリング機能を拡張できるようになりました。IAM Compute Roles を使えば、開発者はサーバーサイドレンダリングアプリに特定の権限を付与でき、Amplify が他の AWS サービスへの承認された呼び出しを行えるようになります。この新機能により、セキュリティのベストプラクティスを維持しながら、開発プロセスを加速できます。 主な機能 IAM Compute Roles を使えば、以下のことができるようになりました。 Next.js API ルートから AWS Secrets Manager と AWS Systems Manager Parameter Store を使用して、ランタイムで機密設定データにアクセスできます。 SSR アプリを Amazon RDS 、 Amazon DynamoDB などの AWS データベースに直接接続できます。 AWS Identity and Access Management (IAM) ポリシーを使用して、コンピューティング環境に細かい権限を定義できます。 サーバーサイドコードから任意の AWS サービスに対して、安全な認証済みの呼び出しができます。 チュートリアル 始める前に、IAM コンピューティング ロールを作成し、それを Amplify Next.js アプリケーションに関連付ける次の手順に従ってください。 前提条件 始める前に、以下がインストールされていることを確認してください。 Node.js (v18.x 以降) npm または npx (v10.x 以降) git (v2.39.5 以降) AWS CLI IAM Compute Roles の作成 Amplify Hosting の SSR コンピューティングサービスが、ロールの権限と信頼関係に基づいて、AWS リソースに安全にアクセスできるように、IAM ロールを作成しましょう。この例では、Amazon Simple Storage Service (Amazon S3) バケットに安全にアクセスします。 AWS マネジメントコンソールにサインインし、 IAM コンソール に移動します Access Management タブの下で、Roles を選択し、 Create role を選びます Custom trust policy を選択し、Amplify がこのロールを引き受けることができるように、以下のポリシーを入力します: { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "amplify.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] } AWS 管理の AmazonS3ReadOnlyAccess 権限ポリシーをロールに追加し、 Next を選択します ロールに amplify-compute-role という名前を付け、 Create Role を選択します Amplify が他の AWS サービスに接続するために引き受けることができるコンピュートロールを正常に作成しました。 セキュリティのベストプラクティス : 最小特権の原則を実施し、特定のユースケースに必要な権限のみを付与してください。 Amazon S3 バケットの作成 Next.js アプリが IAM Compute Roles を使用して安全にアクセスできる、プライベートの Amazon S3 バケットを設定します。Amazon S3 オブジェクトを公開したり、アクセスキーを管理するのではなく、Amplify Hosting の IAM Compute Roles を使って Amazon S3 からプライベートコンテンツを安全に取得します。 AWS マネジメントコンソールにサインインし、 Amazon S3 コンソール に移動します Create bucket &nbsp;を選択し、一意のバケット名を入力します ACL を無効 にし、 Block all public access を有効にしたままにします。 デフォルトの設定のままで、 Create bucket &nbsp;を選択します。 バケットへ移動し、 Upload &nbsp;を選択します。 画像 (例: amplify-logo.png) をアップロードします。 セキュリティの検証 : S3 バケットが完全にロックダウンされていることを確認するには、次の get-public-access-block AWS CLI コマンドを実行してください: // Note: Replace amplify-compute-role-demo with your specific bucket name aws s3api get-public-access-block --bucket amplify-compute-role-demo 出力結果は次のようになるはずです。 { "PublicAccessBlockConfiguration": { "BlockPublicAcls": true, "IgnorePublicAcls": true, "BlockPublicPolicy": true, "RestrictPublicBuckets": true } } これらの設定は以下を保証します。 パブリック ACL の作成はできません 既存のパブリック ACL は無視されます パブリックバケットポリシーはブロックされます バケットへのパブリックアクセスが制限されます Next.js アプリの作成 次に、API ルートを使用して Amazon S3 バケットからプライベートコンテンツの画像にセキュアにアクセスできる Next.js アプリを作成します。 新しい Next.js 15 アプリを TypeScript と Tailwind CSS で作成します。 npx create-next-app@latest compute-role-demo --typescript --tailwind --eslint cd compute-role-demo JavaScript 用の AWS SDK の S3 Client パッケージをインストールします。 npm install @aws-sdk/client-s3 Amazon S3 Image API のルートを作成します。Amplify Hosting へのアプリケーションのデプロイ // app/api/image/route.ts import { S3Client, GetObjectCommand, S3ServiceException } from "@aws-sdk/client-s3"; import { NextResponse } from 'next/server'; const s3Client = new S3Client({}); const BUCKET_NAME = 'amplify-compute-role-demo'; const IMAGE_KEY = 'amplify-logo.png'; export async function GET() { console.log(`[S3 Image Request] Starting - Bucket: ${BUCKET_NAME}, Key: ${IMAGE_KEY}`); try { console.log('[S3 Image Request] Creating GetObjectCommand...'); const command = new GetObjectCommand({ Bucket: BUCKET_NAME, Key: IMAGE_KEY }); console.log('[S3 Image Request] Sending request to S3...'); const response = await s3Client.send(command); console.log('[S3 Image Request] Received S3 response:', { contentType: response.ContentType, contentLength: response.ContentLength, metadata: response.Metadata }); console.log('[S3 Image Request] Converting response to byte array...'); const buffer = await response.Body?.transformToByteArray(); if (!buffer) { console.error('[S3 Image Request] No buffer received from S3'); throw new Error('No image data received from S3'); } console.log('[S3 Image Request] Successfully processed image:', { bufferSize: buffer.length, contentType: response.ContentType }); return new NextResponse(buffer, { headers: { 'Content-Type': response.ContentType || 'image/png', 'Cache-Control': 'public, max-age=31536000, immutable' } }); } catch (error) { if (error instanceof S3ServiceException) { console.error('[S3 Image Request] AWS S3 Error:', { message: error.message, code: error.name, requestId: error.$metadata?.requestId, statusCode: error.$metadata?.httpStatusCode }); } else { console.error('[S3 Image Request] Unexpected error:', error); } return NextResponse.json({ success: false, error: 'Failed to load content' }, { status: 500 }); } finally { console.log('[S3 Image Request] Request completed'); } } クライアントコンポーネントを作成します。 // app/components/S3Component.tsx 'use client'; import { useState } from 'react'; import Image from 'next/image'; export default function S3Component() { const [imageError, setImageError] = useState(false); const [isRevealed, setIsRevealed] = useState(false); return ( &lt;div className="absolute inset-0 top-[88px] flex items-center justify-center"&gt; &lt;div className="w-full max-w-2xl rounded-2xl mx-4"&gt; &lt;div className="flex flex-col items-center justify-center min-h-[400px] p-8"&gt; {!isRevealed ? ( &lt;button onClick={() =&gt; setIsRevealed(true)} className="px-8 py-4 bg-[rgb(117,81,194)] text-white text-lg rounded-xl hover:bg-[rgb(107,71,184)] transition-colors" &gt; &lt;span className="flex items-center gap-2"&gt; Access Private S3 Bucket &lt;span className="text-xl"&gt;⚡&lt;/span&gt; &lt;/span&gt; &lt;/button&gt; ) : ( &lt;div className="space-y-8 w-full"&gt; {!imageError &amp;&amp; ( &lt;div className="relative h-64 w-full"&gt; &lt;Image src="/api/image" alt="Amplify Logo" fill unoptimized priority onError={() =&gt; setImageError(true)} className="object-contain" sizes="(max-width: 768px) 100vw, (max-width: 1200px) 50vw, 33vw" /&gt; &lt;/div&gt; )} &lt;div className="text-center"&gt; &lt;p className="text-gray-400 text-sm"&gt; This content is securely served from S3 using an IAM Compute Role. &lt;/p&gt; &lt;/div&gt; &lt;/div&gt; )} &lt;/div&gt; &lt;/div&gt; &lt;/div&gt; ); } ホームページを更新して、クライアントコンポーネントをレンダリングします。 import S3Component from './components/S3Component'; export default function HomePage() { return ( &lt;div className="relative min-h-screen bg-[rgb(0,0,0)]"&gt; &lt;h1 className="text-2xl font-bold text-white py-8 text-center relative z-10"&gt; Amplify Hosting Compute Role Demo &lt;/h1&gt; &lt;S3Component /&gt; &lt;/div&gt; ); } 変更を git リポジトリにプッシュします。 新しい GitHub リポジトリを作成します 変更内容を Git ブランチに追加してコミットします リモート オリジンを追加し、変更内容をアップストリームにプッシュします git add . git commit -m "initial commit" git remote add origin https://github.com/&lt;OWNER&gt;/amplify-compute-role-demo.git git push -u origin main Amplify Hosting へのアプリケーションのデプロイ AWS マネジメントコンソールにサインインし、 Amplify コンソール に移動します。 Create new app を選び、リポジトリソースとして GitHub を選択します。 Amplify が GitHub アカウントにアクセスできるように認証します。 作成したリポジトリとブランチを選択します。 アプリの設定を確認し、 Next を選択します。 全体の設定を確認し、 Save and Deploy を選択します。 IAM Compute Roles を Amplify アプリに割り当てる Amplify コンソールでアプリを選択し、「App settings &gt; IAM roles」に進みます コンピュート ロールのセクションで Edit &nbsp;を選択します ロールメニューから amplify-compute-role を選択し、 Save を選んでください ブランチごとに固有のコンピュートロールを使うようにブランチ上書きを設定することもできます。これは開発、ステージング、プロダクションなど、さまざまな Git 環境間で特に役立ちます。 Next.js アプリへのアクセス Amplify コンソールのアプリの Overview タブに移動し、ブラウザ上で Amplify が生成したデフォルトの URL を開いてください。 次に、 Access Private S3 ボタンを選択してください。Amazon S3 バケットにアップロードされた画像が表示されるはずです。 ホスティングコンピューティングのログのレビュー アプリのホームページから、[Hosting] &gt; [Monitoring] に移動し、 Hosting compute logs タブを選択してください。 Amazon CloudWatch の Log Streams URL に移動し、最新のログストリームを確認してください。ログには Amazon S3 からの画像リクエストが含まれるはずです: おめでとうございます！ Amplify Hosting の Next.js SSR アプリケーションに、IAM Compute Roles を正常に作成して割り当てました。これで、プライベート Amazon S3 バケットからコンテンツを安全に取得できるようになりました！ クリーンアップ AWS Amplify アプリを削除するには、[ アプリ設定 ] &gt; [ 全般設定 ] に移動し、[ アプリの削除 ] を選択します。 Amazon S3 バケットを削除するには、S3 コンソールから [ バケットを選択 ] &gt; [ 削除を選択 ] &gt; 削除を確認するためにバケット名を入力します。 IAM ロールを削除するには、IAM コンソールから [ ロールを選択 ] &gt; amplify-compute-role 名を探し &gt; [ 削除を選択 ] &gt; 削除を確認するためにロール名を入力します。 まとめ AWS Amplify Hosting は現在、サーバーサイドレンダリング (SSR) アプリケーションの IAM Compute Roles をサポートし、AWS サービスへのセキュアなアクセスの課題を解決しています。以前は、開発者が環境変数を介して手動で認証情報を管理していました。しかし、IAM Compute Roles を使えば、開発者は SSR アプリに直接 IAM アクセス許可を割り当てられるため、サービスの統合が簡単になり、セキュリティが強化されます。 SSR アプリに IAM Compute Roles を追加するには今日、Amplify ドキュメント をご覧ください。 本記事は「 IAM Compute Roles for Server-Side Rendering with AWS Amplify Hosting 」を翻訳したものです。 著者について Jay Raval Jay Raval is a Solutions Architect on the AWS Amplify team. He’s passionate about solving complex customer problems in the front-end, web and mobile domain and addresses real-world architecture problems for development using front-end technologies and AWS. In his free time, he enjoys traveling and sports. You can find Jay on X @ _Jay_Raval_ Matt Auerbach Matt Auerbach is a NYC-based Product Manager on the AWS Amplify Team. He educates developers regarding products and offerings, and acts as the primary point of contact for assistance and feedback. Matt is a mild-mannered programmer who enjoys using technology to solve problems and making people’s lives easier. B night, however … well he does pretty much the same thing. You can find Matt on X @ mauerbac . He previously worked at Twitch, Optimizely &amp; Twilio. 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を支援しています。年明け 4 kg 太ったので、ダイエットに励んでいます。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

PART3：Oracle DatabaseからAmazon&nbsp;Auroraへの移行 -運用編- PART1 では、農林中央金庫が Amazon Aurora の採用に至った経緯・評価点を解説しました。 PART2 では、農林中央金庫とNTT データで Amazon Aurora の採用に伴う非互換対応や性能試験に実施された内容を解説しました。PART3では、Amazon Aurora へ移行した後の実運用経験を踏まえ、これから Amazon Aurora へ移行検討されている方に向けて農林中央金庫・NTT データのコメントをご紹介させて頂きます。 Amazon Aurora で運用してみた感想 AWS および Amazon Auroraを活用することで、以下のような点で対応が楽になり、便利に感じられています: 基本的にパラメータはデフォルト設定で運用可能であり、特別なチューニングの必要性を感じていない テスト利用として、特にポイントインリカバリやバックアップ・リストア機能が便利 AWS 移行によってクラウド上の他システムとの接続・連携が格段に容易になり、データ活用につながっている 運用上アドホックなクエリを流すタイミングがあるが、SQL単位でのメモリ使用量をトラッキングする仕組みがなかった為、問題のあるアドホッククエリの特定が難しかった。 (※ Aurora PostgreSQL 15.4 以降の 15 バージョン、14.9 以降の 14 バージョンにて対応済 ) Amazon Aurora&nbsp;への移行を検討されている方へ 本プロジェクトを通じた気づきとして、Amazon Aurora への移行には大きなメリットがある一方で、注意点もいくつか明らかになりました。Amazon Aurora への移行をご検討される際は、以下の点に留意されることをおすすめします。 システム構成（特にAZを跨ぐ構成）について、その性能や可用性への影響を十分に見極めて設計する オンライン処理の性能確認は更改前の実測値を基準とし、準リアル処理においても実測値を基準としつつ、 本番の業務に相当するワークロードを仮想的に実行する仕組みを用意し、処理集中を意識した確認を行うことが必要 ※本プロジェクトでは、SQLの規約が整備されていたことで、想定外の事象が少なかったと考察 システム全体を見渡した上で、本番環境に近いトランザクション量での試験走行を実施することが重要 これらの点に留意しつつ、Amazon Auroraの大きなメリットを最大限に活かせるよう、移行検討を進めていただければと思います。 関連情報 本件の導入事例ページ https://aws.amazon.com/jp/solutions/case-studies/nochu-bank/ NTTデータの支援プログラムのページリンク あすぽす | デジタルテクノロジーディレクター® (ndigi.tech) &nbsp;

PART2：Oracle DatabaseからAmazon&nbsp;Auroraへの移行 -移行作業編- PART1 では、農林中央金庫がコスト削減の重要なポイントである Amazon Aurora の採用に至った経緯や、ベンダーの NTTデータとどのような点を評価していったかを解説しました。 PART2 では、Amazon Aurora の採用に至った後、移行フェーズにおいて実際に Oracle Database から Amazon Aurora へ移行する際にどのような非互換対応を実施したのか、性能試験時に考慮したポイントについて、お客様の声をご紹介させていただきます。 非互換対応について データベース選定時に実施した非互換調査では、いくつかの対応が必要な部分が存在することを認識していました。しかし、ロックの取得範囲の違いによる障害など、発生タイミングに依存して有無が変わる事象については、机上では影響範囲を網羅するのが難しい部分がありました。そのため、試験を通じて詳細な確認を行いました。非互換対応として実施したものの一部をご紹介します。 項番 概要 内容 1 暗黙の型変換 DB定義とSQLクエリでカラムのデータ型の不一致がある場合、Oracleは自動的にデータ型が変換され正常終了するが、PostgreSQLではエラーとなる 2 サブクエリやTBLの別名定義 OracleとPostgreSQLで、表の別名の使用ルールが異なる（OracleはFrom句のサブクエリに別名を使用しなくても良いが、PostgreSQLでは必須など） 3 集約関数のネスト 集約関数（avg、max、sumなど）をネストして使用する場合、Oracleは正常終了するがPostgreSQLではエラーとなる。 また、上記の他に対応に苦慮した非互換としては次のものがあり、それぞれ以下の表の通り対応を進めました。 項番 概要 内容 1 Database Link(異なるインスタンスを跨ぐ更新) 同一処理において複数のDBインスタンスに対して更新を行うような処理に対しては、Database Linkによる参照ではなく、「DB①に対する接続情報」、「DB②に対する接続情報」を定義し、これらを使い分けてDB更新するような対応が必要となり影響も大きかった。 2 PL/SQLのトランザクション制御（エラー制御の変更） 処理内のとあるSQLで一意制約が発生し、その後管理テーブルにSTSを書き込むといったような処理がある場合、トランザクションを分割させる必要がある。（同一トランザクションで処理しようとすると、後発のSQL（管理テーブルへの書き込み）が必ずエラーになる。） 3 空・Nullの扱いの差 PostgreSQLでは、NULLと空文字の違いが区別されるため、例えば「SELECT * FROM テーブル１ WHERE KEN_CD = ”」という構文においてOracleでは取得出来ていたレコードが取得できなくなってしまう。影響の大きかった非互換のひとつ。 これに対する対応として、移行時にDBデータを空文字⇒NULLに変換する対応と、AP（JAVA）-DB（SQL）間のオブジェクト変換時に空文字⇒NULLへのコンバータ処理を新たに作成して対応している。） 試験方法・方針について 本プロジェクトでは品質を最優先としており、本番データをマスク化した上で活用しながら、全機能の十分な試験を実施しました。本番データの活用によって、ほぼ全ての SQL について現行環境と新環境の比較を行うことができました。また、合わせて影響度合いに応じてチューニングを検討しました。さらにテスト効率の向上を目的として、テストデータの準備や現行・新環境の比較などの定型作業の自動化を図り、作業効率の向上に努めました。 試験時のポイント： 全ての SQL について空振りがない形で現行・新環境の比較を実施し、機能単体の正当性を確認 日々の全更新データを本番環境から流用し、データの網羅性を担保 想定されるピーク時のワークロードをツールで再現し、性能試験を実施 現行本番との比較確認やデータの準備を自動化・定型作業化することで効率化 また、試験においては製造・試験の生産性なども確認し、事前の想定から大きな乖離はありませんでした。さらに、NTT データに即時のチューニングが可能な体制を構築していただいたため、パフォーマンスが劣化する SQL があった場合も、業務要件上必須の性能が満たせるよう、迅速にチューニングを施すことで影響を最小限にしつつ対応する事ができました。 性能試験について 性能試験では、不適切な実行計画が選択されることによるパフォーマンス劣化が多くみられました。特に、数百万行以上の大規模テーブル同士の結合クエリでは、そうした傾向が顕著でした。そのため、ヒント句を活用して最適な実行計画を選択させる対応を行いました。また、アプリケーション側で大量の SQL を発行するような Loop 処理についても、1回あたりの通信時間の増加によって処理時間が伸びる傾向があったため、SQL 発行回数を減らすといった、アプリケーション側でのチューニングも実施する場面がありました。 Part 3 に続く。

PART1：Oracle DatabaseからAmazon&nbsp;Auroraへの移行 -検討編- 農林中央金庫は、農林水産業を支える全国金融機関として、金融業務をはじめとした経営健全性確保に向けた指導など、多岐に渡って日本の農林水産業の発展に貢献されています。また、JA・信農連(信用農業協同組合連合会)・農林中央金庫で構成されたJAバンクは、1 つの金融機関として機能するよう運営されており、貯金量 100 兆円超、店舗数 6,000 超、ATM 10,000 台超を誇る巨大金融グループです。 JAバンクの基幹システムである「JASTEM システム」は、2002 年に勘定系と情報系の 2 つで構成されて構築されました。情報系は、勘定系で処理した取引情報や顧客情報を蓄積し、JA 職員が渉外活動やデータ分析等で利用することがメインの役割です。 この度、経営環境の変化に伴うコスト削減要求の高まりや、ビジネスの加速に対応するため、2018 年から 2022 年にかけて、全国 6,493 店舗(2022 年 3 月時点)の JASTEM 情報系システムを Amazon Web Services(AWS)に移行する大規模プロジェクトを実施しました。データベースを Oracle Database から Amazon Aurora に更改したことによるライセンスコスト削減や、ハードウェア費用の削減により、13 年間で 100 億円以上の TCO 削減が見込まれています。 本ブログでは、コスト削減の大きなポイントである Amazon Aurora への移行について、移行検討から移行後の効果までをお客様の声とともにご紹介します。 AWSへの移行を決定した背景 当初はメインフレームの COBOL 環境で運用していた JASTEM 情報系システムは、2010 年のオープン化、2014 年の仮想化、2018 年の IA サーバーへの基盤更改といった形で、計画的にオープン系アーキテクチャへの移行を進めてきました。これにより、いわゆる「技術負債(レガシー技術)」の解消を図ってきました。 一方で、約 4 年ごとの周期で行う基盤更改に、検討から本番までに長い時間がかかっていた事が課題でした。そのため、基盤更改の効率化とコスト削減・合理化を図るべく、クラウド移行の検討を始めました。 この移行プロジェクトでは SI ベンダーの NTT データに支援を仰ぎながら、AWS を含む主要クラウドベンダーを複数の観点から比較しました(図 1 参照)。その結果、現行プログラムプロダクトとの親和性が高く、インフラ導入費用のみならず、長期的な運用コストを含めた TCO (トータルコスト)ベースでも高いコスト削減効果が期待できたことから、AWSの採用に至りました(図 2 参照)。 図1:評価・検証のポイント 図2:AWS移行によるコスト効果 Amazon Aurora PostgreSQLへの移行を決断した背景 JASTEM 情報系システムではこれまで、Oracle Database を利用していました。しかし、主に以下の 3 つの観点から Amazon Aurora の評価を行い、非機能要件(特に性能面)を落とさずにコスト削減が可能であると判断し、Amazon Aurora への移行を決断しました。 コスト競争力 Amazon Auroraはライセンス費用が不要な分、従来比で3割程度の削減が実現できると見込みました。アプリケーションの改修コストも相当程度発生するものの、全体としては安価になると分かりました。ただし、小規模システムではコスト効果が限定的になる可能性があるため、移行対象システムの規模感が重要であると認識しました。 可用性の高さ 3つのアベイラビリティーゾーン（AZ）に渡り、6つのデータコピーを保持するため、エンタープライズ利用に耐えうる可用性があることから、現行環境と同等の可用性の高さが実現可能と判断しました。 ベンダーロックインリスクの低減 Amazon Aurora は、OSS の PostgreSQL との互換性を持っているため、ベンダーロックインのリスクが低いことを評価しました。 一方で、アプリケーションの非互換改修や処理結果の確認といった開発リスクが伴う点は認識していました。 移行対象データベースの概要 DBエンジン：Oracle Database Enterprise Edition データ量：最も大きなクラスタで約3TB、全体で約25TB SQL数：約15,000本 プロシージャ数：351本(※非互換のみ) 可用性要件：99.99% Enterprise Editionオプション製品：Oracle Partitioning, Oracle Diagnostics Pack, Oracle Tuning Pack NTTデータの支援体制 本プロジェクトでは、NTT データが提供するプロフェッショナルサービス「あすぽす(※1)」を活用し、アセスメントから実装まで一気通貫で支援いただきました。 ＜※1 お客様のシステムに最適なデータベースの選定から、移行・導入までを一気通貫で行うプロフェッショナルサービス。PostgreSQLのコミッターも在籍しており、多くのマイグレーション実績を持つ。＞ ご参考：&nbsp; あすぽす | デジタルテクノロジーディレクター® (ndigi.tech) データベースエンジンを選定する際に実施した内容 Oracle Database と PostgreSQL の非互換に関する情報を収集した上で、机上確認・実機検証を通して実現性を見極めました。具体的には、SQL*Loader やシノニムといった、Oracle Database 固有の機能に依存した設計となっているアプリケーションの有無を確認しました(※図 3 参照)。また、SQL の変換のみで対応可能な場合であっても、単純な置き換えレベルで対応可能か・作り替えが必要となるか、といった基準で「修正難易度」の精査(※図 4 参照)を行い、試験の検討・検証方法の策定を実施しました。 図3:機能面・非機能面での精査 図4:影響調査のアウトプットイメージ 更に NTT データの過去プロジェクト実績や、NTTグループの OSS ノウハウ、社外 PGECons 活動報告などを活用して、現行環境に対する非互換調査を協力しながら行いました。具体的には、Oracle 固有のヒント句の利用箇所やパーティション利用箇所の有無などを確認し、本プロジェクトの性能要件に対する影響度合いを踏まえて、十分対応可能と判断しました。 Part 2 に続く。

今日のグローバルサプライチェーンの複雑な状況において、正確な需要予測は極めて重要ですが、それだけでは十分ではありません。企業は予測精度を向上させ、最適な在庫を実現するために、高度な分析能力や機械学習（ML）の導入に投資を行ってきました。しかし、これらの広範な取り組みにもかかわらず、2021年以降、 在庫売上高比率 は上昇を続けており、需要と供給の変動に対応するために過剰在庫を抱えていることを示しています。この事実は、予測の改善と実際のビジネス価値の実現との間に、まだ重要な要素が欠けていることを示唆しています。 サプライチェーンの混乱が深刻な時期には、企業間の業務知識がより一層重要になります。効果的なステークホルダーとのコミュニケーションがなければ、どんなに高度な予測でも急速に陳腐化し、ビジネス価値が低下し、組織は急激な市場の変化に対して脆弱な状態に置かれてしまいます。 サプライチェーンの真の価値を引き出す鍵は、最先端の需要予測と効果的なステークホルダーの協働を組み合わせることにあります。この投稿では、 AWS Supply Chain の革新的なソリューションが、機械学習を活用した高品質な予測を実現するだけでなく、有意義な協働を促し、重要なビジネスインサイトを捉え、あらゆる市場環境で経済的価値を最大化する需要計画を作成する方法について探ります。 高付加価値な需要計画の構築 従来の需要計画は、過去のデータを元に可能な限り正確な予測を生成することのみに焦点を当てた単一ステップのプロセスです。今日のような非常に変化が激しい環境では、過去の出来事から同じ結果が生じない可能性があり、専門家からの追加的な意見も重要であるため、そのようなやり方では限定的な成功しか得られません。 AWS Supply Chain は、真に価値のある需要計画には 2 段階のアプローチが必要であることを認識しています。 Step 1: 機械学習を使用して強力なベースライン予測を構築する 最初のステップでは、需要プランナーは AWS Supply Chain の高度な分析・機械学習機能を活用して、ベースライン予測を生成します。次に予測モデルの分析機能が組織のデータセットで実行され、プランナーが最適な機械学習モデルを選択する際に支援を行い、外部要因と製品の切り替えを考慮に入れて初期精度を最大化します。例えば、DeepAR+ のようなアルゴリズムは、数百項目におよぶ時系列の特徴量データを含む大規模なデータセットで動作し、将来の関連する時系列のデータ項目とメタデータの項目を元に予測出力を生成します。 Step 2: ステークホルダーとの協働を推進し、合意に基づく需要計画を構築する 2 番目の重要なステップは、協調的な改善プロセスです。プランナーは AWS Supply Chain の直感的なユーザーエクスペリエンスを活用して、ベースラインとなる予測をステークホルダーと共有し、洞察を収集し、重要な業務上の前提条件を把握します。このプロセスにより、ベースラインに対する必要な上書きや調整が可能となり、最終的な計画が業務の全体感や整合性を保ったものになることが担保できるようになります。 従来、需要計画プロセスがビジネス価値を生み出しているかの評価は、平均絶対誤差率（MAPE）や加重平均絶対誤差率（WAPE）などの精度指標に頼ってきました。これらの指標は全体的なパフォーマンスを評価する上で依然として重要ですが、2 段階プロセスの各ステップで付加される価値を測定する上では不十分です。これらは実績値からの予測の乖離のみに注目するため、協業の過程で与えられる重要な情報や、行われ調整を見落としてしまいます。 ここで、 予測価値付加（FVA） の概念が重要となります。FVA は機械予測と人的介入の有効性を予測プロセスにおいて個別に測定し、組織がどの活動が本当に価値を生み出し、どの活動がノイズやバイアスを生む可能性があるかを特定するのに役立ちます。FVA を分析することで、企業は最も重要な部分に努力を集中させ、需要計画プロセスを最適化できます。例えば、 世界的な寝具メーカーのテンパー・シーリー・インターナショナルや RS コンポーネンツ は、FVA を成功裏に導入し、どの入力が本当に予測を改善し、どれがノイズを生んでいるかを理解することで恩恵を受けています。 AWS Supply Chain の統合ソリューションは、この 2 段階プロセスを促進し、実績値をナイーブ予測や合意予測と比較し、2 段階プロセスの各ステップでの価値付加を評価するための FVA を計算するためのレポーティングおよび分析ツールを提供します。これにより、組織は単なる精度指標を超えてビジネス価値を最大化する需要計画を作成することが可能になります。 ただ予測するのではなく、自分の未来を切り開け 需要計画は精度だけの問題ではありません。それは実際のビジネス価値を生み出すことです。AWS Supply Chain の 2 段階アプローチは、最先端の ML 予測と強力なコラボレーションツールを組み合わせることで、このプロセスを支援します。データに基づく分析と人間の専門知識の両方を活用することで、組織は未来を予測するだけでなく、それを形作る需要計画を作成できます。今日の変動の激しい市場では、これは単なる優位性ではなく、必要不可欠なものです。AWS Supply Chain で、需要計画をビジネスを前進させる戦略的優位性に変えましょう。以下のステップから始めてください： 現在のプロセスを評価する：予測精度と協調的なインプットのバランスを組織がどのように取っているか評価します。両者の価値を本当に最大限に活用できていますか？ AWS Supply Chain を検証する：アカウント管理者に デモをリクエスト し、統合された ML 予測とコラボレーションツールがどのように需要計画を変革できるかをご覧ください。 技術概要を把握する： AWS Workshop Studio で自己ペースの技術的なウォークスルーを体験してください。インスタンスの作成、データの取り込み、ユーザーインターフェースのナビゲート、インサイトの作成、需要計画の生成方法を学べます。 <!-- '"` --> 本ブログはソリューションアーキテクトの水野 貴博が翻訳しました。原文は こちら 。 <!-- '"` --> 著者について Amit Shah Amit Shah は、AWS Supply Chain のプリンシパル スペシャリスト ソリューション アーキテクトです。彼の役割は、サプライチェーンの幹部や技術アーキテクトと協力し、顧客の問題を理解し、意図したビジネス成果を達成するために顧客のサプライチェーンを変革することです。彼はリーン・シックス・シグマ ブラックベルト認定を受けており、メディカルテック製造、テクノロジー、E コマース、クラウドインフラストラクチャなど、フォーチュン 500 企業の幅広い業界で、ビジネスとプロセスの変革を推進する 18 年以上の業界経験を持っています。Amit は、サンフランシスコ湾岸地域を拠点としています。

サプライチェーン管理の領域では、経済の変動や多様化する顧客ニーズにより、常に変化にさらされています。このような環境下では、効率性と適応力が極めて重要です。多くの企業では、手作業のプロセスを削減し、効率性を高め、全体的なパフォーマンスを向上させるため、自動化ソリューションを求めています。 前回 お伝えした通り、AWS Supply Chain ソリューションは、可視性の向上とコスト最適化および俊敏性を促進する実用的な分析情報という利点を提供します。このソリューションは、需要計画、供給計画、インサイトなどの機能を提供し、中核的なサプライチェーン機能を効率化し、企業が市場環境に適応するのを支援します。新しいソリューションの採用にはそれに伴う課題があり、このブログではそれらを探ります。既存のワークフローとの統合から、業務を中断することなくニーズに対応することまで、組織はソリューションの可能性を十分に実現するために、これらの複雑さに自信を持って対処する必要があります。 導入における課題の軽減 新しいサプライチェーンソリューションの導入は重要な決定であり、多くの場合、実践的な考慮事項が伴います。例えば、そのソリューションが既存の組織プロセスにどの程度うまく統合されるか、特定の運用ニーズに対応できるか、また実装が現在のワークフローを妨げないかといった点です。実際に導入を決定する前の段階で、ソリューションの真価を見極めることは容易ではなく企業にとって、それが本当に自社の目標、リソース、プロセスに適合するかを評価することを難しくしています。 これらの一般的な導入課題に対応するため、AWS Supply Chain の新しいテストドライブ機能は、スピーディーで使いやすい実践的な試用環境を提供します。テストドライブにより、組織は AWS Supply Chain に素早く親しみ、様々な設定を試し、シナリオを実行し、ユーザーインターフェースを評価することができます。 この対話型エクスペリエンスにより、顧客はデータ取り込みから需要と供給の計画、そしてインサイトの生成まで、AWS Supply Chain の一連の機能を確認することができます。テストドライブは、企業がソリューションのメリットを実感することを可能にします： 簡素化されたセットアップ : 自動車、医療、小売、公共事業業界向けの事前に準備されたデータセットにより、組織はデータ収集、準備、ソリューション設定を必要とせず、すぐにソリューションのテストを開始できます。これにより、お客様は AWS Supply Chain の価値評価に直ちに集中することができます。 レスポンシブな体験 : AWS Supply Chain のテストドライブは、アクセスした日に応じて調整されるライブのような環境を提供します。つまり、予測日、在庫予測、補充スケジュールが自動的に更新され、実世界の計画タイムラインをシミュレートします。このレスポンシブな設定により、現実的なシナリオベースの洞察が生まれ、プランナーは実際の業務で行うような意思決定プロセスを、あたかも今日実施しているかのように体験できます。 没入型の検証 : テストドライブは、企業が AWS Supply Chain モジュールを直接体験できる、安全でインタラクティブな環境を提供します。ユーザーはインターフェースにアクセスし、設定をテストし、データ処理ワークフローを理解することで、AWS Supply Chain の機能について洞察を得ることができます。この実践的な経験により、ユーザー体験とソリューション設定にすでに慣れているため、本格的な実装へのスムーズな移行が可能となり、チームは自社の特定の業務に対するソリューションの適合性と価値に自信を持つことができます。 テスト実施ガイド この記事を進めるにあたり、以下の前提条件があります： AWS アカウントと AWS Supply Chain インスタンスがセットアップされていること ポリシーとアクセス許可を作成するための AWS Identity and Access Management (IAM) ロールを作成および変更する権限があること テストドライブ機能は、簡単な操作で開始できるよう設計されており、ワンクリックで利用を開始できます。 Step 1：テストドライブにアクセスします。 ログイン後、AWS Supply Chain のランディングページに移動し、 テストドライブ スイッチをクリックします。 Step 2: 業種を選択します。 自動車、医療、公共、小売などの事前に用意された業種データセットから選択してください。 Step 3: モジュールを確認します。 テストドライブは、企業が AWS Supply Chain モジュールを直接体験できる、安全でインタラクティブな環境を提供します。ユーザーはインターフェースにアクセスし、設定をテストし、データ処理ワークフローを理解することで、AWS Supply Chain の機能について洞察を得ることができます。この実践的な経験により、ユーザー体験とソリューション設定にすでに慣れているため、本格的な実装へのスムーズな移行が可能となり、チームは自社の特定の業務に対するソリューションの適合性と価値に自信を持つことができます。 需要計画 : &nbsp; シミュレーションされた業界の需要パターンに基づいて予測を生成し、予測を調整をしてみることで、AWS Supply Chain がお客様固有の需要計画ニーズをどのようにサポートできるかを確認できます。 供給計画 : 原材料と完成品の購買計画、および補充推奨事項を確認するために、補充タイムラインを生成し、供給ルールをカスタマイズします。AWS Supply Chain がお客様のビジネスニーズに合わせてどのように在庫を管理するかを評価します。 在庫分析 : 業界シナリオに基づいた在庫予測、ネットワークの可視化、リードタイムの変動、およびリスク評価にアクセスし、詳しく調べることができます。これらのインサイトが業務ニーズにどのように適合するかを評価し、AWS Supply Chain があなたのビジネスに適しているかを判断できます。 これらの簡単な操作手順と実践的なシナリオテスト機能により、テストドライブを通じて AWS Supply Chain の機能を実際に体験し、自社のビジネスでの活用方法を具体的にイメージすることができます。 まとめ AWS Supply Chain は、たとえば小売業の需要予測から医薬品の在庫計画、自動車業界のサプライチェーンリスク評価、公益事業のサプライヤー管理まで、幅広い業界とサプライチェーン機能に対応しています。ワンクリックのオファリングとして、AWS Supply Chain のテストドライブ機能は、サプライチェーン業務を近代化したい組織にとって簡単な出発点を提供します。テストドライブ機能は、企業が AWS Supply Chain の潜在的な導入を迅速かつ容易に探索することを支援します。事前設定されたデータセットと業界固有のモジュールを備えた柔軟な環境を提供することで、テストドライブは顧客が最小限の準備と既存の業務と並行して、サービスの可能性を体験できるようにします。テストドライブは完全な導入の代替とはなりませんが、評価段階を簡素化し、企業が AWS Supply Chain がニーズに合うソリューションかどうか を判断するのに役立ちます。 AWS Supply Chain は、前払いのライセンス料や長期契約なしで利用できます。テストドライブ機能は、既存の AWS Supply Chain の顧客と初めて AWS Supply Chain を検証する組織の両方に、ハンズオンの試用環境を提供することで、この柔軟性を拡張します。詳細情報の入手と開始、およびセルフペースの技術的ウォークスルーについては、 AWS Supply Chain ウェブサイトと&nbsp; ワークショップ をご覧ください。 本ブログはソリューションアーキテクトの水野 貴博が翻訳しました。原文は こちら 。 著者について Jyothi Bodas Jyothi Bodas は、AWS Supply Chain でベテランのソフトウェア開発マネージャーであり、戦略的な見識と技術的な専門知識を通じて、会社の成功に大きく貢献しています。AWS Supply Chain のデータオンボーディングシステムの創設メンバーの1人として、重要なアプリケーションの戦略、アーキテクチャ、ソリューションの開発に重要な役割を果たしています。UPS とAmazon Web Services（AWS）での15年以上にわたるエンジニアリングとリーダーシップの役割を通じて、Jyothi は豊富な知識と専門性をもたらしています。顧客のニーズの変化に合わせて調整された革新的で信頼性の高いソリューションを提供する情熱に、卓越性と顧客満足への彼女のコミットメントが表れています。インドのオスマニア大学でコンピュータサイエンスとエンジニアリングを専攻して卒業しました。専門的な取り組みの外では、Jyothi はサプライチェーンマネジメントや AI、ML などの新興技術に関する継続的な学習に時間を捧げ、ハイキングやその他のフィットネス活動を通じて活動的な生活を送っています。 <!-- '"` -->

はじめに 2024 年 12 月、リテールメディアにおけるデータコラボレーションワークショップを開催しました。本記事では、本ワークショップの開催背景と当日の内容をご紹介いたします。 Retail Media は「第3の広告」として注目され、2019年頃からアメリカを中心に市場を牽引しています。しかし、日本ではまだまだこの市場はアーリーステージにあります。本領域が加速しない原因の一端として、異業種間のデータコラボレーションによるCustomer360 の実現というデジタルマーケティングのノウハウにとどまらず、実店舗の購買体験向上に向けたオフライン施策にまで踏み込む難しさが存在します。この市場を加速させるため、AWSはCyberAgent Inc.（以下CA 社）と共同でワークショップを開催しました。Retail Media に高い興味を持つ日本を代表する企業にお集まりいただき、AWS Clean Rooms を活用したデータコラボレーションのユースケースの議論を実施しました。加えてCA 社のSolution を組み合わせることで、実店舗でも十分活用可能な協業に踏み込んだアクションプランを策定できる場を提供することを目指しました。 開催概要 参加者 5 社 / 36名 参加企業様 イオン様 アダストリア様 SIROK 様 オンデーズ様 ヴィンクス様 アジェンダ 開会のご挨拶 / 参加企業ご紹介 CA のRetail Media サービスの紹介 AWS コラボレーションテクノロジーのご紹介 テーブル別ディスカッション Next Step のご案内 / 閉会のご挨拶 前半をセミナー、後半をディスカッションと分けて開催いたしました。後半のディスカッションでは、各企業ごとにデータコラボレーションする際の協業内容について議論を行いました。 データコラボレーションの基本 データコラボレーションとは 本ワークショップのメインテーマであるデータコラボレーションと、それを支える AWS のサービスについてご説明します。まず、データコラボレーションとは、複数の組織が保有するデータを安全かつ効果的に共有・統合・分析し、単独では得られない洞察や価値を生み出す取り組みです。例えば、小売業とメディア企業が匿名化された顧客データをコラボレーションすることで、より精緻なマーケティング戦略の立案や新サービスの開発が可能になります。重要なのは、各組織のデータプライバシーとセキュリティを維持しながら、必要な情報のみを共有することです。これにより、安全性を確保しつつデータの価値を最大化することができます。 なぜ今データコラボレーションが注目されているのか データコラボレーションの注目が高まっている背景には、デジタル化の加速、消費者行動の複雑化、個人情報を含むデータの保護に関する規制環境の整備があります。さらに 1st party data (自社で直接収集したデータ) の重要性が増していることも大きな要因です。サードパーティ Cookie の廃止や個人情報保護の厳格化に伴い、企業は自社の顧客データをより効果的に活用し、同時に他社のデータと安全に連携する必要性が高まっています。このデータ活用と連携が、企業の競争優位性を生み出す鍵となっています。実際、多くのグローバル企業がデータコラボレーション強化を推進しており、日本においても今後のビジネス戦略において重要な役割を果たすことが予想されます。 各セッションのハイライト CAのRetail Mediaサービスの紹介 CyberAgent, Inc. AI 事業本部 AI POS カンパニー プロダクト責任者 早川 裕太氏 CA 社早川氏より、Retail Media を取り巻くマーケットの状況とCA社の取り組みをご紹介いただきました。CA 社は創業期よりインターネット広告事業を展開してきました。近年では、広告効果最大化を実現する中で培ったノウハウや、約100名規模のAI研究者の技術力などを活かすことで、協業によるパートナー企業のDX推進および広告事業の創出等を行っております。Retail Media においては、消費者、小売、広告主の三方良しを目指した技術の価値転換を図っており、デジタルサイネージ（ミライネージ）をはじめとしたいくつかのサービスをすでに展開しています。お客様の購買体験向上に向けて、コンサルテーションからソリューション提供まで一気通貫して協業が可能な旨を語られました。 AWS のコラボレーションテクノロジー アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 黒澤 蓮 アマゾン ウェブ サービス ジャパン 黒澤より、データコラボレーションを AWS 上で実現する方法についてご説明を行いました。まずはデータコラボレーションを支える AWS Clean Rooms というマネージドサービスについてご紹介しました。主な特徴として、暗号化技術によるセキュアなデータ共有、SQL を用いた柔軟な分析環境、実行する SQL の制御機能、緻密なアクセス制御、大規模データセットに対するスケーラビリティがあります。このサービスにより、企業は自社データを保護しつつ、連携先企業とのデータコラボレーションを実現し、新たなビジネス機会を創出できます。これに加えて新機能で企業間で類似セグメントの作成を支援する AWS Clean Rooms ML、名寄せのサービスである AWS Entity Resolution のご説明をいたしました。 テーブル別ディスカッション ワークショップのメインとなったテーブル別ディスカッションでは、具体的なデータコラボレーションのユースケースについて活発な議論が交わされました。参加企業の皆様には事前に各社のデータ資産や活用課題を伺った上で、実践的なユースケースを準備したことで、より深い議論が可能となりました。イオン様、アダストリア様のテーブルでは、グループデータ戦略としてどのようにデータを活用するかの話と、それが実現した上でのポイント戦略や広告効果の測定など幅広いテーマについて、個別課題の解決に向けた議論を実施しました。オンデーズ様、SIROK 様は新規ユーザーをどのように増やしていくかの課題感に対して、Retail Media を通じた顧客開拓の戦略を議論されました。最後にヴィンクス様は、CA 社と両社の強みを活かし、リテールのお客様のビジネス成長に寄与するためのデータ活用における協業の新たな可能性を見つけることができました。 お客様の声 本ワークショップは、Retail Media におけるデータコラボレーションの可能性を探る貴重な機会となりました。参加企業の皆様からは、「事業領域の異なる企業間でのディスカッションが想像以上に有意義な時間でした」「自分たちだけでは想像もできないアイディアがたくさん出てきた」といった前向きな声を多数いただきました。ワークショップ後のアンケートでは、参加者のCSAT が4.8/5.0 と本ワークショップに対してポジティブなフィードバックを頂き、データコラボレーションに対する高い期待が伺えます。 おわりに 本ワークショップを通じて、Retail Media 実現に向けた大きな可能性と、参加企業の皆様の熱意を肌で感じることができました。ここに改めて、ご参加いただいた企業の皆様、そして共催であるCyberAgent 社の皆様に心より感謝申し上げます。AWS は、今後もこの様なデータコラボレーションを推進する取り組みのご支援や、皆様に役立つ情報をセミナーやブログで発信していきます。どうぞよろしくお願い致します。 本ブログは、Customer Solutions Managerの池田 飛鳥が担当しました。

この記事は Raja GT, Shing Poon, Vedanth Srinivasan により作成された「 Building a Manufacturing Digital Thread using Graph and Generative AI on AWS 」を翻訳した内容です。 製造業の大多数の組織がデジタルトランスフォーメーションの取り組みを受け入れる中、戦略的資産としてのデータの役割がますます重要になってきています。製品ライフサイクル全体を通じてデータを効果的に活用することで、製造業は全体的なコスト削減、製品品質の向上、サプライチェーンの合理化、そして顧客への差別化されたソリューションの提供につながる重要な洞察を引き出すことができます。しかし、データ駆動型の変革を実践に移すことは容易ではありません。 アクセンチュアの調査 によると、経営幹部の 73% が、レガシーデータ、資産、および業務からデータに基づく洞察を得ることができないと報告しています。 ほとんどの製造業組織において、製品ライフサイクルデータは通常、製品ライフサイクル管理 (PLM) 、企業資源計画 (ERP) 、製造実行システム (MES) 、顧客関係管理 (CRM) 、およびその他の企業アプリケーションといった企業システムに保存されています。企業インフラが分断されていることにより、生成されたデータは多くの場合断片化し、使用されないままとなっています。 Seagate の委託 を受け、IDC が実施した調査によると、企業が生成するデータの 68% が活用されていないことが明らかになりました。また、この報告書はデータの提供者と利用者の間のデータがつながっていないことを指摘しています。 製品ライフサイクルの様々な段階にわたるデータを活用し、製造業の関係者がより良い意思決定を行うことができるよう支援することが、ビジネス変革の必須事項となっています。しかし、製品ライフサイクル全体でのデータ管理とコンテキスト化は、データの表現方法や使用パターンが、それを扱う特定の担当者のペルソナに応じて変化するため、困難が伴います。製造業の企業がデータを統合しコンテキスト化するために用いる一つのアプローチが、 デジタルスレッド (Digital Thread) の構築です。これにより、製品のライフサイクル全体を通じて生成される信頼できるデータ (要件、製品情報、製品コスト、文書、サプライチェーン、品質、欠陥、保守など) のシームレスで相互接続された流れを確立します。製品が構想から設計、製造、現場運用に至る複数のライフサイクル段階を経る中で、デジタルスレッドは多様なデータソースを接続し、ある時点での製品性能を分析し、データ駆動型のビジネス成果を推進する筋道を確立します。 デジタルスレッドのためのナレッジグラフと生成 AI 異種の企業システム間の統合を確立するには、データソース間のポイントツーポイント統合など、いくつかのアプローチがありますが、デジタルスレッドを確立するための実用的な方法の一つは、ナレッジグラフ (知識グラフ) を使用して製造データとその関係性を表現することです。 ナレッジグラフを用いることで、様々なデータソースからの接続されたデータの繋がりを作成し、オブジェクト間の非常に複雑な関係性を表現することができます。ナレッジグラフは、複雑な関係性を効率的に保存、検索、可視化することでデータを整理できるように設計されています。さらに、データを関係者にとって利用しやすくし、より良い意思決定を行うための知識獲得を支援します。 製品の企画から廃棄までのライフサイクル全体にわたってデータを接続するデジタルスレッドは、依存関係を追跡し、エンドツーエンドの追跡可能性を確保する能力を必要とします。ナレッジグラフは、分散したデータを接続することでこれらのセマンティックレイヤーを実現し、企業全体でシームレスなデータ接続性を可能にします。 図 1: 製造デジタルスレッド – ナレッジグラフ 図 1 に示すグラフでは、企画、製品データ、生産指示書などのエンティティがノード (頂点) として表現され、それらの間のセマンティックな接続がエッジ (辺) として表現されています。このデジタルスレッドグラフにより、相互に接続された製造企業のデータをシームレスにナビゲートすることができ、複雑な関係性を容易に理解することができます。例えば、部門横断チームや意思決定者が部品と関連する欠陥や要件との関係を理解するのに役立ち、品質の向上や設計プロセスの改善につながります。ナレッジグラフのクエリは、企業内の様々な関係者の意思決定プロセスに不可欠な、コンテキスト固有の視点や関連情報の抽出を容易にします。 ナレッジグラフはデジタルスレッドの開発に理想的ですが、グラフクエリの自動化や自然言語テキストの生成には課題が生じる可能性があります。ユーザー体験を向上させるために、大規模言語モデル (LLM) を活用して複雑なグラフデータを解釈し、関係性を分析してクエリを生成し、デジタルスレッドグラフに基づいて自然言語で結果を提供することができます。 このブログでは、 Amazon Neptune と Amazon Bedrock の機能を組み合わせて、製造業のデジタルスレッドアプリケーションを作成する方法について説明します。グラフと生成 AI テクノロジーを組み合わせることで、ビジネス関係者が会話形式で素早く洞察を得ることができるようになります。 デジタルスレッドソリューションフレームワーク 様々な製品ライフサイクルプロセス (Design, Manufacture, Operation) から得られるデータが、このデジタルスレッドソリューションフレームワークの基盤を形成しています。次の層は、PLM、ERP、MES などの中核的な企業システムを包含しており、これらは企業内の人、プロセス、エンジニアリング、製造データなどの特定の側面を管理します。その次の層はナレッジグラフで構成されます。ナレッジグラフがこれらのシステムからのデータを接続して関係性を確立し、洞察を導き出し、相互に接続された製造企業データの包括的な理解を促進します。最後に、大規模言語モデルがナレッジグラフと統合され、高度なグラフクエリの作成と自然言語機能を可能にします。 図 2: 製造デジタルスレッドソリューションフレームワーク 図 2 に示すように、このソリューションは、様々なシステムからのデータをシームレスに接続し、製造業のデジタルスレッドフレームワークを通じて洞察を得られるようにすることで、イノベーションを加速することを目指しています。このフレームワークは、データが相互に接続されたインテリジェントな構造を確立し、製造業の関係者の意思決定プロセスを強化します。 ソリューションアーキテクチャ 製造業のデジタルスレッドソリューションアーキテクチャは、フルマネージド型のグラフデータベースサービスである Amazon Neptune と、フルマネージド型の生成 AI サービスである Amazon Bedrock を必須要素として統合することで実装されています。さらに、これらのコンポーネントは様々な AWS サービスによって強化され、デジタルスレッドのための包括的なソリューションを構築しています。 図 3: 製造デジタルスレッドソリューションアーキテクチャ 図 3 に示すように、このソリューションは 15 を超える AWS サービスを活用し、デジタルスレッド機能の開発をサポートするための 10 の重要な機能を提供します。 1. 製造組織における主要な関係者を特定する デジタルスレッドの取り組みを開始するには、製造組織内の主要な関係者を特定することが不可欠です。例えば、システムエンジニアリング、設計エンジニアリング、製造エンジニアリング、サプライチェーン、運用、品質チームが含まれます。彼らの固有のビジネス上の関心事やユースケースを理解することにより、デジタルスレッドの基盤の構築が可能となります。 2. デジタルスレッドを構築するためのデータソースを特定する 包括的なデジタルスレッドを構築するために必要なデータソースを特定します。これらには、PLM、ERP、CRM、MES/MOM、およびその他の社内企業アプリケーションが含まれる場合があります。主要なビジネス上の課題、提供元システム、およびデータを特定することで、企業は業務の全体的な視点を得るために不可欠なデータを確実に取り込むことができます。 3. データ統合 特定されたデータソースを AWS Data Migration Service (DMS) や、大規模なデータセットの移動には AWS DataSync を使用して AWS クラウドに取り込みます。 4. S3 にデータをアップロード データの取り込みが成功したら、そのデータを Amazon Simple Storage Service (Amazon S3) にロードします。 5. バルクローダーを使用して Amazon Neptune グラフデータベースにデータをロード Amazon Neptune のバルクローダー機能を活用して、Amazon S3 に保存されたデータを Amazon Neptune に取り込みます。Amazon Neptune で作成されたグラフのエッジとノードが、グラフベースのクエリの基礎となります。 6. 生成 AI モデルを使用 Amazon Bedrock から基盤モデルを選択します。Amazon Bedrock は、単一の API を通じて主要 AI 企業と Amazon の高性能な基盤モデルの選択肢を提供する、フルマネージド型サービスです。また、生成 AI アプリケーションを構築するための幅広い機能セットも備えています。 7. ナレッジグラフと LLM の接続を確立し、LangChain を使用して統合 Amazon Bedrock (Claude 3.5 Sonnet) と Amazon Neptune の間のリンクを確立し、LangChain を使用してそれらをシームレスに統合します。これにより、基盤モデルからクエリを生成し、ナレッジグラフに対してクエリを実行し、結果を自然言語でユーザーに返すプロセスを調整します。 8. アプリケーションレイヤーの作成 以下の要素を組み合わせてアプリケーション層を作成します: Streamlit アプリケーション コンテナ化されたアプリケーションの実行のための AWS Fargate コンテナイメージ管理のための Amazon Elastic Container Registry トラフィック分散のための Elastic Load Balancing (ELB) 安全なユーザー認証のための Amazon Cognito AWS Copilot CLI を通じてデプロイされるこのセットアップは、デジタルスレッドデータとの関係者のシームレスな対話のための、スケーラブルで安全なユーザーインターフェースを確保します。 9. セキュリティ Amazon VPC を活用して、デジタルスレッドアプリケーションを安全かつ隔離されたネットワークで運用します。 AWS Identity and Access Management (IAM) によってアクセス制御を強化し、 AWS Certificate Manager (ACM) で証明書を管理し、 AWS WAF で Web アプリケーションのセキュリティを確保します。 10. 管理とガバナンス AWS CloudTrail を活用してアクティビティを追跡し透明性を高め、 Amazon CloudWatch でリソースを監視し、 AWS CloudFormation でデジタルスレッドアプリケーションのリソースデプロイメントを自動化します。 詳細については、 GitHub リポジトリで提供されている ガイダンス 、 ワークショップ 、サンプルコードを参照してください。 図 4: 製造デジタルスレッドアドバイザー 図 4 は、PLM、MES、ERP、CRM システムからの企業データを組み合わせ、自然言語による問い合わせを通じてインテリジェントな洞察を提供する、対話型デジタルスレッドアドバイザーを示しています。 デジタルスレッドのユースケース ナレッジグラフと生成 AI に基づく製造業のデジタルスレッドを使用することで、組織はシームレスなデータ統合を通じて効率性とイノベーションを引き出すことができます。主要なユースケースには以下が含まれます: 要件から品質へのトレーサビリティ: 製品要件と品質の間のトレーサビリティの維持が難しい課題となる場合があります。製造業のデジタルスレッドを活用することで、組織は初期要件が最終製品の品質にどのように影響するかについてはっきりと見ることができます。このアプローチにより、関係者は重大な問題を引き起こす前に、積極的に課題を特定し、対策を提案することが可能になります。 製品開発におけるサプライヤーコラボレーションの効率化: 複数のサプライヤーとの協力や設計仕様の管理は、製品開発プロセスを複雑にする可能性があります。ナレッジグラフと生成 AI を活用することで、組織は製品とサプライヤーの情報をシームレスに接続できます。この統合により、サプライヤーの選択が最終製品にどのように影響するかについてリアルタイムの洞察が得られ、より多くの情報を基に意思決定が可能になり、開発プロセス全体が効率化されます。 サステナビリティのためのサプライチェーンの最適化: サプライチェーンにおけるサステナビリティの実現は、現代の製造業にとって重要な目標です。デジタルスレッドを活用することで、組織は製品、サプライヤーから物流に至るまで、サプライチェーンのあらゆる観点を接続することができます。総合的な視点を持つことで、カーボンフットプリントやその他のサステナビリティ指標に関する洞察が得られ、組織は炭素排出量を削減するための戦略を策定することが可能になります。 文脈を踏まえた洞察による顧客サポートの強化: 効果的な顧客サポートを提供するには、製品の全体的なジャーニーを深く理解する必要があります。設計、製造、顧客フィードバックを含む接続されたデジタルスレッドを活用することで、サポートチームは大局的な視点から洞察を得ることができるようになります。これにより、問題をより迅速かつ正確に解決することが可能となり、最終的に顧客満足度とロイヤルティの向上につながります。 さらに、グラフと生成 AI を使用した製造業のデジタルスレッド機能は、上記で言及したユースケースを超えて、製品ライフサイクル全体および産業全体にわたって業務を変革する機会を提供します。 まとめ この投稿では、AWS でナレッジグラフと生成 AI を使用してデジタルスレッドを構築する方法について検討しました。ナレッジグラフと LLM は、接続された製造業のデジタルスレッドを作成する上で不可欠です。グラフは複雑な製造プロセスをナビゲートするために必要なデータの接続性と追跡可能性を提供し、一方で LLM はグラフから価値ある洞察を抽出し、それらを自然言語で提示します。ナレッジグラフと生成 AI の力を活用することで、製造業の組織はデータのアクセシビリティや、コラボレーション、追跡可能性、効率性を向上させ、より迅速なデータ駆動型の意思決定プロセスを実現します。 この記事はソリューションアーキテクトの村松 謙が翻訳しました。原文は こちら 。 Raja GT Raja GT は、アマゾンウェブサービスのワールドワイドシニアパートナーソリューションアーキテクトです。製造パートナーと緊密に連携して、技術戦略を策定し、戦略的パートナーが AWS で業界ソリューションを構築して拡大できるよう支援しています。航空宇宙、自動車、ヘルスケア、エネルギー業界で 20 年以上の経験を持ち、製品ライフサイクル管理、サプライチェーン、スマートマニュファクチャリング、革新的なクラウドソリューションの構築を専門としています。 Shing Poon Sing Poonは、メルボルンのアマゾンウェブサービスのシニアテクニカルアカウントマネージャーで、小売およびサプライチェーン業界を専門としています。2022 年にソリューションアーキテクトとして AWS に入社して以来、データと AI に関する専門知識を活かして、顧客との複雑なビジネス課題を解決してきました。Shingは、公益事業、グローバルサプライチェーン、製造部門にわたる豊富な経験を持ち、安全で信頼性が高くスケーラブルなソリューションを通じてデジタル変革を推進しています。テクノロジー以外にも、彼は熱心なコーヒー醸造家であり、2人の息子のために専任のTAMを務めています。 Vedanth Srinivasan Vedanth Srinivasan は、アマゾンウェブサービスのエンジニアリング&amp;デザインおよび市場開拓 (GTM) 向けソリューションの責任者です。業界横断型ソリューションに重点を置いているのは、ハイパフォーマンスコンピューティング (HPC) や製品ライフサイクル管理 (PLM) などのコンピュータ支援エンジニアリング (CAE)、製品ライフサイクル管理 (PLM) のほか、モデルベースシステムエンジニアリング (MBSE)、デジタルスレッド、デジタルツインソリューションなどの高次ワークロードです。自動車、航空宇宙、防衛、石油・ガス、ヘルスケア業界にわたる高度なエンジニアリング・ワークフローの開発と展開において 20 年以上の経験があります。

本記事は、2025 年 1 月 29 日に公開された Generative AI operating models in enterprise organizations with Amazon Bedrock を翻訳したものです。 生成 AI は、お客様や従業員のエクスペリエンスを向上させる革新的なアプリケーションの創出を可能にし、革命をもたらします。 インテリジェントなドキュメントの処理 、翻訳や要約、カスタマーサポートのエージェントを支援する柔軟で洞察に富んだ応答、パーソナライズされたマーケティングコンテンツ、画像やコードの生成などは、生成 AI を使用したユースケースの一例であり、実運用されているものです。 大規模な組織では、複数の事業部門 (LOB) が存在し、中央で管理する組織が存在することが多く、 Amazon Web Services (AWS) のマルチアカウント戦略と共に AWS Organizations を適用するのが一般的です。 ランディングゾーン を導入して、セキュアなアカウント作成を自動化し、ログ、監視、監査など、アカウント全体にわたる管理を合理化します。 LOB は独自のアカウントやワークロードを運用しますが、 Cloud Center of Excellence (CCoE) などの統括チームが、アイデンティティ、ガードレール、アクセスポリシーを管理しています。 生成 AI の導入が進むにつれ、企業は生成 AI のオペレーティングモデルを確立していく必要が生じてきます。オペレーティングモデルは、事業運営を駆動する組織設計、コアプロセス、テクノロジー、役割や責任、ガバナンス体制、そして財務モデルを確立するものです。 本記事では、適用可能な生成 AI のオペレーティングモデルを考察します。 オペレーティングモデルのパターン 俊敏性、ガバナンス、統制などの優先事項に応じて異なる生成 AI のオペレーティングモデルを採用することができます。生成 AI のガバナンスとは、この技術の責任ある開発、導入、利用を促進するフレームワーク、ポリシー、プロセスを意味します。 リスクを軽減し、説明責任を果たし、生成 AI システムと倫理原則や組織目標との整合性を図るためのさまざまな方策を包含するものです。次の図に示すように、3 つの代表的なオペレーティングモデルのパターンは、分散型 (Decentralized) 、中央集権型 (Centralized) 、そして連携型 (Federated) です。 分散型モデル 分散型では、生成 AI の開発や導入は、各 LOB が独自に主導し管理します。LOB は、それぞれの AWS アカウントの AI のワークフロー、モデル、そしてデータを独自に管理します。 これにより、各 LOB はニーズに応じた生成 AI のソリューションを迅速に試行し導入することができるため、市場投入までの時間が短縮され、俊敏性を高めることができます。しかし分散型であっても多くの場合は、LOB は全社的なガバナンス管理と整合性を図り、本番環境への導入にあたっては CCoE チームの承認を得る必要があります。アクセスポリシー、モデルのリスク管理、データプライバシー、コンプライアンス体制などについて、グローバルなエンタープライズの基準に則る必要があるため、ガバナンスが複雑になりえます。 中央集権型モデル 中央集権型では、生成 AI に関連する取り組みは生成 AI/ML を統括するチームが行い、全社にわたる AI のワークフロー、モデル、そしてデータをエンドツーエンドで導入から管理まで行います。 LOB は、AI に関するニーズを統括するチームに伝え、迅速性や市場投入までの時間はトレードオフとなりますが、より強力なトップダウン型のガバナンスを実現します。中央集権型では、市場投入までの時間がボトルネックとなる可能性があるため、LOBからのニーズに効率的に対応できるよう、チームに十分な人員や自動されたプロセスを適切に導入する必要があります。チームの規模を拡大できない場合、中央集権型のアプローチのメリットはガバナンスですが、デメリットの方が大きくなる可能性があります。 連携型モデル 連携型は、生成 AI のプロセスのうち主要なアクティビティを中央の生成 AI/ML プラットフォームチームが管理することで、バランスを取るものです。 LOB が AI のユースケースを開発する一方で、中央のチームがガードレール、モデルのリスク管理、データプライバシー、そしてコンプライアンス体制を整備します。これにより、LOB の迅速なイノベーションを実現しながら、中央がガバナンス領域を監視することができます。 生成 AI のアーキテクチャのコンポーネント オペレーティングモデルのパターンについて説明する前に、このセクションでは、アーキテクチャで使用されるコンポーネントと AWS のサービスの概要について簡単に説明します。 大規模言語モデル (LLM) 大規模言語モデル (LLM) は、数十億のパラメータを含み、膨大なデータで事前学習された大規模な ML モデルです。LLM は、ハルシネーション、つまり LLM が確信を持って回答しているものの、実際には不正確な回答を提供するということが起こる可能性があります。さらに、LLM の学習に使用したデータが古くなっている可能性もあり、不正確な回答につながることがあります。LLM が不正確な情報を提供する可能性を軽減する 1 つの方法は、 Retrieval Augmented Generation (RAG) と呼ばれる技術を使用することです。RAG は、ナレッジの検索とテキスト生成モデルを組み合わせた高度な自然言語処理技術です。RAG は、事前学習済みの言語モデルと検索ベースのアプローチを組み合わせ、より情報量が多く正確な応答を生成します。RAG を設定するには、関連するソースドキュメントをモデルに提供するベクトルデータベースが必要です。RAG を使用すると、関連するドキュメントのセグメントやその他のテキストが検索され、LLM に共有され、コンテンツの品質と関連性を高めた的確な応答が生成されます。 Amazon Bedrock は、AI21 Labs、Anthropic、Cohere、Meta、Mistral AI、Stability AI、Amazon といった AI 業界をリードする企業が提供する高性能な 基盤モデル (FM) を、単一の API を使用して選択できるフルマネージドサービスです。また、セキュリティ、プライバシー、責任あるAIを備えた生成 AI アプリケーションを構築するために必要な機能も幅広く備えています。 Amazon SageMaker JumpStart では、AI21 Labs、Cohere、LightOn などのサードパーティプロバイダーの独自 FM へのアクセスを提供します。さらにAmazon SageMaker JumpStart は、Hugging Face などのサードパーティソースからのオープンソース FM の導入や管理も行えます。 データソース、埋め込み、ベクトルストア コンテキストや関連情報を提供する組織固有のデータは、通常、内部データベース、データレイク、非構造化データリポジトリ、またはドキュメントストアに存在し、これらを総称して組織データソースまたは独自データストアと呼ばれます。 ベクトルストアは、効率的な最近傍探索アルゴリズムと適切なインデックスにより、大量のベクトルを保存し、検索するためのシステムです。 組織のデータの埋め込み（ベクトル形式でのデータの数学的表現）だけでなく、データの生のテキストもチャンク単位で含まれます。これらのベクトルは、専用の埋め込み生成 LLM によって生成され、組織のテキストチャンクを処理して数値表現（ベクトル）を作成し、ベクトルストアにテキストチャンクと共に保存されます。ベクトルストアや埋め込みについて詳しく知りたい場合は、「 生成 AI アプリケーションでベクトルデータベースが果たす役割 」を参照ください。 Amazon Bedrock Knowledge Bases を使用すると、Amazon Bedrock の FM を企業のデータに安全に接続して RAG を実現できます。Amazon Bedrock Knowledge Bases は、さまざまなサポート対象のデータソースからのデータ取り込みを容易にし、データのチャンク処理、パース処理、埋め込みを管理し、ベクトルストアに追加します。これらの機能が提供されるため、Amazon Bedrock Knowledge Bases は、RAG を使用して強力な会話型 AI システムを構築するための、フルマネージド型のサーバーレスの選択肢として考えることができます。 ガードレール コンテンツフィルタリングのメカニズムは、望ましくない有害なコンテンツを最小限に抑えることで、アプリケーションの要件や責任ある AI のポリシーに準拠し、ユーザーと AI のやり取りを制御するためのセーフガードとして実装されています。ガードレールは、ユーザーからの入力と FM からの出力を確認し、安全性が確保されていないトピックをフィルタリングもしくは拒否したり、個人を特定できる情報 (PII) を削除したりすることで、生成 AI のアプリケーションにおけるコンテンツの安全性とプライバシーを強化することができます。 Amazon Bedrock Guardrails は、Amazon Bedrock の機能であり、セーフガードを講じるために使用できます。貴社のポリシーに基づいて、何を条件とするかを決定します。これらのセーフガードは、フレームワークに依存しません。特定のユースケースに合わせて構成を変更した複数のガードレールを作成できます。Amazon Bedrock Guardrails の詳細については、「 Guardrails for Amazon Bedrock は、お客様のユースケースと責任ある AI ポリシーに合わせてカスタマイズされたセーフガードの実装に役立ちます 」、「 新しい安全フィルターとプライバシーコントロールを備えた Amazon Bedrock のガードレールが利用可能になりました 」を参照してください。 オペレーティングモデルのアーキテクチャ このセクションでは、3 種類のオペレーティングモデルについて概要を説明します。 分散型モデル 分散型モデルでは、LOB が AWS アカウントを所有し管理します。各 LOB はそれぞれの AWS アカウントで生成 AI のコンポーネント、共通機能、アプリケーション、Amazon Bedrock の構成を設定し管理します。このモデルでは LOB が Amazon Bedrock の機能を活用しながら独自の要件に応じて生成 AI のソリューションをカスタマイズすることができます。 このモデルでは、LOB は LLM やガードレールなどのコアコンポーネントを設定し、Amazon Bedrock のサービスアカウント (図中の “Amazon Bedrock Service Account”)&nbsp; でホスティング、処理、そしてインターフェイスのエンドポイントのプロビジョニングといったことを管理します。そのエンドポイントを通じて、LOB は Amazon Bedrock のサービスにアクセスし、やりとりできます。 LOB は、 Amazon CloudWatch Logs および AWS CloudTrail を使用してニーズに合わせてログの取得、分析、監査を行い、アカウントで構成した Amazon Bedrock のサービスの監視や監査を行います。Amazon Bedrock のコストや利用状況は、LOB の AWS アカウントに記録されます。分散型モデルを採用することで、LOB は生成 AI のソリューションを分散型の構成で管理しながら、Amazon Bedrock のスケーラビリティ、信頼性、セキュリティのメリットを享受できます。 次の図は、分散型モデルのアーキテクチャを示しています。 中央集権型モデル 中央の AWS アカウントが、再利用可能なエージェント、プロンプトフロー、共有ライブラリといった生成 AI のコア機能の構成や管理を行う中心的なハブとして機能します。 LOB チームは中央のチームに事業固有の要件やユースケースを提供し、中央のアカウントで要件に沿うように生成 AI のコンポーネントを統合しオーケストレーションします。 生成 AI のソリューションの設定やオーケストレーションは、中央のアカウントで保持されます。しかし一般的には、LOB 固有のリソースやサービスとの連携が必要になり、それを容易にするために、中央のアカウントは LOB の AWS アカウントの API ゲートウェイやその他の連携ポイントを利用します。連携ポイントを通じて、中央の生成 AI のオーケストレーションと、 LOB の業務に特化したアプリケーション、データソース、サービスとの間で、安全で統制されたやりとりが可能になります。この中央集権型のオペレーションモデルは、組織全体における生成 AI のソリューションの共通化、ガバナンス、スケーラビリティを促進します。 中央のチームは、共通の標準、ベストプラクティス、組織のポリシーを順守しながら、生成 AI のコンポーネントの効率的な共有や再利用を可能にします。さらに、LLM やガードレールといった Amazon Bedrock のコアコンポーネントについては、Amazon Bedrock のサービスアカウントで AWS がホストや処理を担い、安全でスケーラブルでハイパフォーマンスな実行環境を確保します。この中央集権型モデルでは、Amazon Bedrock の監視や監査は中央のアカウントで実行できるため、生成 AI のすべてのアクティビティや構成の包括的な監視、監査、分析が可能になります。Amazon CloudWatch Logs は、組織全体における生成 AI のオペレーションの包括的な可視化を実現します。 生成 AI のソリューションの設定やオーケストレーションを中央のアカウントに集約し、同時に LOB 固有のリソースとの安全なインテグレーションを可能にすることで、このオペレーティングモデルは生成 AI の運用における標準化、ガバナンス、集中管理を促進します。AWS のマネージドのインフラストラクチャやサービスのスケーラビリティ、信頼性、セキュリティ、一元化された監視の機能を活用しながら、LOB 固有の要件やユースケースとの統合も可能にします。 以下は、中央集権型オペレーションモデルのアーキテクチャです。 連携型モデル 連携型モデルでは、Amazon Bedrock により、LOB チームがそれぞれの AWS アカウントで、生成 AI の共通機能を開発し、コントリビューションできる協働的なアプローチが可能になります。再利用可能なエージェント、プロンプトフロー、共有ライブラリなどの共通機能を、専任チームまたは CCoE が管理する中央の AWS アカウントに移行することができます。 中央の AWS アカウントは、生成 AI の共通的なコンポーネントを統合しオーケストレートするためのハブとして機能し、アクショングループやプロンプトフローの統一されたプラットフォームとなります。生成 AI のソリューションの設定やオーケストレーションは、LOB の AWS アカウントで保持されますが、LOB は中央のアカウントの Amazon Bedrock エージェント、プロンプトフロー、そしてその他の共有コンポーネントを使用することができます。 この連携型モデルにより、LOB は生成 AI のソリューションの主導権を維持し、中央で管理されるコンポーネントを再利用するといったメリットを享受しながら、特定の事業要件に合わせてカスタマイズすることができます。中央のアカウントは、生成 AI の共有コンポーネントの共通化、ガバナンス、スケーラビリティを維持し、組織全体のコラボレーションや標準化を促進します。 Payment Card Industry (PCI)、PII、 General Data Protection Regulation (GDPR) 、 Health Insurance Portability and Accountability Act (HIPAA) に関連するような機密データは、LOB の AWS アカウントで保持される傾向があります。このアプローチでは、LOB がベクトルストアでセンシティブなビジネスデータを管理できるようにし、適切なガバナンスやセキュリティ対策なく中央のチームや CCoE がアクセスできないようにすることができます。 連携型モデルは、分散型の開発、中央集権型の連携、中央集権型の監視を組み合わせたものです。このオペレーティングモデルは、コラボレーション、再利用性、標準化を促進すると同時に、LOB が 生成 AI のソリューションを管理できるようにします。AWS のマネージドインフラストラクチャとサービスのスケーラビリティ、信頼性、セキュリティ、中央でのモニタリング機能を使用し、自律性とガバナンスの調和のとれたバランスを促進します。 以下は、連携型オペレーションモデルのアーキテクチャです。 コスト管理 全社的に Amazon Bedrock の利用状況や、LOB 毎のコストを分析したい場合があるかもしれません。各 LOB の AWS アカウントの基盤モデルのコストや利用状況を追跡するに、LOB 毎のモデルの呼び出しを記録するソリューションを実装できます。 Amazon Bedrock は現在、 推論プロファイル を使用したモデル呼び出しのリソースをサポートしています。推論プロファイルを定義して、Amazon Bedrock の利用状況のメトリクスを追跡したり、モデル呼び出しのリクエストを監視したり、スループットを向上させるためにモデル呼び出しのリクエストを複数の AWS リージョン にルーティングしたりすることができます。 推論プロファイルには 2 つのタイプがあります。Amazon Bedrock にあらかじめ定義されている クロスリージョン推論プロファイル は、モデルのリクエストをルーティングできる複数の AWS リージョンを含んでいます。もう 1 つは アプリケーション推論プロファイル で、これはオンデマンドのモデル呼び出しのリクエストを送信する際に、コストとモデルの使用状況を追跡するためにユーザーが作成するものです。コスト配分タグなどのカスタムタグをアプリケーション推論プロファイルに添付することができます。プロンプトを送信する際には、推論プロファイル ID または Amazon リソース名 (ARN) を含めることができます。この機能により、さまざまな LOB、コストセンター、もしくはアプリケーションのコストの追跡や監視をすることができます。アプリケーション推論プロファイルの詳細については、「 Amazon Bedrock を使用した生成 AI のコストと使用状況の追跡、配分、管理 」を参照してください。 結論 生成 AI のオペレーティングモデルは中央集権型モデルから始めることが多いですが、生成 AI の技術開発の急速な発展、俊敏性の必要性、そして価値を迅速に獲得したいという要求の高まりにより、連携型モデルへと向かっていく傾向があります。 連携型のオペレーティングモデルでは、LOB は専門知識や事業課題を精通しているといった利点を活かして、生成 AI のソリューションを用いたイノベーションや実験を進めていくための自由度を獲得することができます。 データアクセスの方針、モデルのリスク管理、コンプライアンスの監視といった AI のワークフローにおける重要な要素は、中央のクラウドガバナンスチームによって管理されます。LOB が開発し、成功を収めた生成 AI ソリューションは、中央のチームによって全社的な再利用が推進され、展開されます。 この連携型モデルは、ドメインの問題に最も精通している LOB からのイノベーションを加速させると同時に、中央のチームは、組織のポリシーに準拠したソリューションを管理、強化、拡張し、それらを効率的に他の関連する事業分野に展開することができます。 このオペレーティングモデルを維持するために多くの場合、LOB と協働するビジネスオーナーを擁した専任のプロダクトチームを設置します。このチームは、LOB の変化するニーズに対応し、LLM やその他の生成 AI 技術の急速な進歩に遅れを取らないよう、生成 AI のサービスの継続的な進化、リファクタリング、強化を担当していきます。 連携型モデルは、完全に分散化された取り組みの場合に生ずるリスクを軽減しながら、過度に中央集権化されたアプローチで生ずるボトルネックを最小限に抑えるといったバランスをとるものです。 中央のチームの調整によってビジネスの俊敏性を向上させ、AI の状況が進化する中で、イノベーションのゴール、リスクの許容、迅速な価値の創出といったニーズに応じ、かつコンプライアンスに準拠しながら品質の高い生成 AI の機能の実現を加速することができます。 企業が生成 AI による革命を活用する場合、Amazon Bedrock は、組織のニーズに合わせた柔軟なオペレーティングモデルを構築する理想的な基盤となります。中央集権型、分散型、連携型のいずれのアプローチから始める場合でも、AWS は生成 AI のライフサイクル全体をサポートする包括的なサービスを提供しています。 Amazon Bedrock を試して、組織に適したオペレーティングモデルをどのように実装していくか、フィードバックをお寄せください。 著者について Martin Tunstall は、AWS のプリンシパルソリューションアーキテクトです。金融業界で 30 年以上の経験を持ち、グローバルな金融および保険業界のお客様が Amazon Web Services (AWS) の可能性を最大限に引き出せるよう支援しています。 . . Yashar Araghi は、AWS のシニアソリューションアーキテクトです。インフラおよびアプリケーションのセキュリティソリューションの設計と構築で 20 年以上の経験があります。政府、教育、金融、エネルギー、インフラなど、さまざまな業界のお客さまと仕事をしてきました。AWS での過去 6 年間では、お客様が AWS で安全で信頼性が高く、パフォーマンスに優れ、コスト最適化されたクラウドソリューションの設計、構築、運用できるよう支援してきました。 . 翻訳者について 川口賢太郎 (Kentaro Kawaguchi) と 白木文香 (Ayaka Shiraki) は、AWS プロフェッショナルサービスのシニア CS&amp;O アドバイザリーコンサルタントとシニア PT でアドバイザリーコンサルタント、デジタル戦略立案とそれに即した組織の変革に注力しています。 CCoE や AI CoE などの xCoE の組成支援などに従事しています。

本ブログは 2025 年 1 月 13 日に公開された Blog “ AWS re:Invent 2024: Security, identity, and compliance recap ” を翻訳したものです。 AWS re:Invent 2024 は、12 月 2 日から 6 日までラスベガスで開催され、54,000 人以上の参加者が 2,300 以上のセッションとハンズオンラボに参加しました。AWS が主催するこのイベントは、世界中のクラウドコンピューティングコミュニティにとって、革新的な技術と知見を共有する場となりました。 このブログでは、 オンデマンドセッション と、カンファレンスの前後で発表された主要なセキュリティ、アイデンティティ、コンプライアンスに関する発表内容を取り上げます。イベントを見逃した方や、重要なポイントを振り返りたい方のために、AWS のセキュリティに関する主要なアップデートを包括的に解説します。今年のイベントでは、ゼロトラスト、生成 AI を活用したセキュリティ、アイデンティティとアクセス管理、DevSecOps、ネットワークとインフラストラクチャのセキュリティ、データ保護、脅威検出とインシデント対応のベストプラクティスに重点が置かれました。 主な発表内容 ID とアクセス管理に関して、AWS Organizations 全体で権限管理を規模拡大するのに役立つ複数の新機能をリリースしました。 リソース コントロール ポリシー (RCP) – RCP は、組織内の AWS リソースに対して予防コントロールを一元的に作成および適用するために使用できる、新しいタイプの組織ポリシーです。RCP を使用することで、AWS でワークロードをスケールする際に、AWS リソースに対して許可される最大の権限を一元的に設定できます。 ルートアクセスの一元管理 – ルートアクセスの一元管理により、ルート認証情報を一元的に管理し、認証情報の監査を簡素化し、AWS Organizations で管理される AWS メンバーアカウント全体で、範囲を限定した特権的なタスクを実行できるようになりました。 宣言型ポリシー – 宣言型ポリシーは、組織内の AWS サービスのベースライン構成など、意図した設定を強制する方法を簡素化します。 Amazon Cognito は 4 つの新機能を発表しました。 機能ティア – Amazon Cognito は、Essentials と Plus の 2 つのユーザープールの機能ティアを開始しました。Essentials ティアは、包括的で柔軟なユーザー認証とアクセス制御機能を提供し、安全でスケーラブル、かつカスタマイズされたサインアップとサインインエクスペリエンスの実装を支援します。Plus ティアは、アプリケーションに対して高度なセキュリティニーズを持つお客様向けに、不審なサインインに対する脅威保護機能を提供します。 開発者向けコンソール – Amazon Cognito は、クイックウィザードとユースケース固有の推奨事項を備えた、合理化された導入手順を提供するようになりました。このアプローチにより、これまで以上に迅速かつ効率的に設定を行い、エンドユーザーに提供することができます。 Managed Login – この機能は、お客様の企業やアプリケーションのブランディングに合わせてパーソナライズできる、フルマネージド型のホステッドサインインおよびサインアップエクスペリエンスです。Managed Login / マネージドログインは、パスワードレス認証やローカライゼーションなどの共通の手間のかかる作業の設計と保守を軽減します。 パスワードレス認証 – パスワードレス認証により、パスキー、メール、テキストメッセージを使用してアプリケーションへのユーザーアクセスを保護できます。ユーザーがパスキーを使用してサインインすることを選択した場合、Apple MacBook の Touch ID や PC の Windows Hello 顔認証などの組み込み認証機能を使用できます。 環境内のセキュリティ問題を発見するために、 Amazon GuardDuty は Extended Threat Detection を開始しました。これは、AWS アカウント、ワークロード、データを標的とする高度な多段階の脅威を特定するために使用できる機能です。新しい攻撃シーケンスの検出結果を使用することで、長期間にわたる複数のリソースとデータソースをカバーできるようになり、一次分析にかける時間を減らし、ビジネスへの影響を最小限に抑えるために重大な脅威への対応により多くの時間を費やすことができます。 Amazon OpenSearch Service が Amazon Security Lake との zero-ETL 統合 を提供開始し、OpenSearch Service を通じてセキュリティデータをその場で直接クエリおよび分析できるようになりました。この統合により、これまでコストが高く分析が困難だった大量のデータソースを効率的に分析できるようになり、セキュリティ調査の合理化とセキュリティ環境の包括的な可視化が可能になります。データを選択的に取り込める柔軟性があり、複雑なデータパイプラインを管理する必要がないため、分析コストを削減しながら効果的なセキュリティ運用に集中できるようになりました。 AWS Security Incident Response は、環境内のセキュリティ問題への対応を支援する新しいサービスです。このサービスは、自動化された監視と調査、迅速なコミュニケーションと連携、そして AWS カスタマーインシデントレスポンスチーム (CIRT) への 24 時間 365 日のアクセスを組み合わせることで、セキュリティインシデントへの準備、対応、復旧を迅速に行うことができます。 ゼロトラスト の分野では、 AWS Verified Access と Amazon VPC Lattice の両方が、非 HTTPS リソースへのアクセスのサポートを開始しました。Verified Access を使用すると、TCP、SSH、RDP などのプロトコルを介して、VPN を使用せずに社内アプリケーションへの安全なアクセスを提供できます。Amazon VPC Lattice 向け VPC リソースのローンチにより、VPC Lattice サービスネットワークを通じてアプリケーションの依存関係にアクセスできるようになりました。TLS、HTTP、HTTPS、そして新たに TCP を含む追加プロトコルを使用して、異なる VPC、アカウント、オンプレミスでホストされているアプリケーションに依存する各種リソースにアクセスできます。AWS Verified Access を使用して非 HTTP(S) プロトコルでゼロトラストアクセスを有効にする方法については、 オンデマンドセッション をご覧ください。 Amazon Route 53 Resolver DNS Firewall は、高度な DNS 脅威に関連する不審な DNS トラフィックを監視およびブロックするために使用できる新機能を備えた、新しい高度なファイアウォールルール機能の提供を開始しました。 Amazon Virtual Private Cloud は、 ブロックパブリックアクセス 機能をリリースしました。これは、管理者が各 VPC のインターネットトラフィックを確実にブロックするために、一元的に実装できるワンクリックの一括設定機能です。 生成 AI ワークロードを本番環境にデプロイするお客様が増えるにつれて、適切なセキュリティ制御が重要になってきています。 Amazon Bedrock では、これを支援する 2 つの新機能をリリースしました 自動推論チェック – 自動推論チェックは、ハルシネーションを検出し、大規模言語モデルのレスポンスが正確であることを検証可能な証明を提供します。自動推論チェックにより、ドメインエキスパートは、運用ワークフローや組織の人事方針などの分野における知識を要約した自動推論ポリシーと呼ばれる仕様をより効率的に構築できます。Amazon Bedrock ガードレールのユーザーは、生成されたコンテンツを自動推論ポリシーと照合して不正確な点や明示されていない前提を特定し、記述が正確である理由を検証可能な方法で説明できます。 マルチモーダル有害コンテンツの検出 (プレビュー) – Amazon Bedrock ガードレールは、画像コンテンツに対するマルチモーダル有害コンテンツの検出をサポートするようになり、組織が画像にコンテンツフィルターを適用できるようになりました。パブリックプレビューで利用可能なこの機能により、独自の画像データ保護機能を構築したり、手間がかかり間違いやすい手動評価に時間を費やしたりする必要がなくなります。 AWS は、お客様の成功を支援するため、引き続きパートナーと密接に連携しています。 AWS re:Invent では、3 つの新しいパートナープログラムが開始されました AI セキュリティカテゴリー – AWS セキュリティコンピテンシーの AI セキュリティカテゴリーは、AI 環境のセキュリティ確保と高度な脅威からの AI ワークロードの防御に関する深い経験を持つ AWS パートナーを特定するのに役立ちます。このカテゴリーのパートナーは、機密データの漏洩防止、インジェクションの脅威の防止、セキュリティ態勢管理、責任ある AI フィルタリングの実装などの分野での能力が検証されています。 AWS Security Incident Response スペシャライゼーション – 現在、AWS のお客様は、社内のセキュリティインシデント対応能力をサポートするために、さまざまなサードパーティのツールやサービスを利用しています。お客様とパートナーの双方をより良くサポートするため、AWS はセキュリティイベントの準備、対応、復旧を支援する新しいサービス AWS Security Incident Response を導入しました。認定された AWS パートナーと共に、AWS Security Incident Response は、Amazon GuardDuty やその他の脅威検出ツールからの優先順位付けされたセキュリティ調査結果を AWS Security Hub を通じて監視、調査、エスカレーションします。AWS Security Incident Response は、優先度の高いインシデントのみを特定してエスカレーションするように設計されています。 Amazon Security Lake Ready スペシャライゼーション – このスペシャライゼーションは、Amazon Security Lake と統合するソフトウェアソリューションを技術的に検証し、お客様への導入実績を示した AWS パートナーを認定するものです。これらのソリューションは、AWS パートナーソリューションアーキテクトによって、アーキテクチャの妥当性と実証済みのお客様の成功が技術的に検証されています。 オンデマンドでコンテンツを体験 現地で参加できなかった方や、セッションをもう一度視聴したい方は、 オンデマンド で利用可能なセッションをご覧いただけます。 Matt Garman による CEO キーノート では、AWS がお客様とパートナーの皆様により良い未来を構築していただくために、基盤となる構成要素を再構築し、まったく新しい体験を開発している様子をご覧いただけます。また、 re:Invent 2024 の他のキーノート も視聴できます。 AWS CISO の Chris Betz による Security Innovation Talk をご覧いただき、最新の AWS イノベーションがどのようにお客様の迅速な対応とセキュリティの維持を支援しているかをご確認ください。AWS がどのように組織のセキュリティを製品、サービス、プロセスに統合・自動化し、セキュリティチームがビジネスに最大の価値をもたらす業務に集中できるようにしているかをご紹介します。また Chris は、AWS がセキュリティイノベーションをスケールし、セキュリティコミュニティに投資することで、インターネットをより安全にする取り組みについても共有します。 以下のような重要なトピックについて学ぶため、AWS のセキュリティ、アイデンティティ、コンプライアンスに関する分科会や新機能発表のトークを オンデマンド で視聴できます How AWS scales active defense (AWS がアクティブディフェンスを拡張する方法) Building a resilient and effective culture of security (レジリエントで効果的なセキュリティ文化の構築) How to maintain and automate compliance on AWS (AWS でのコンプライアンスの維持と自動化の方法) The AWS approach to secure generative AI (生成 AI に対する AWS のセキュリティアプローチ) Generative AI for security in the real world (実世界におけるセキュリティのための生成 AI) Digital sovereignty: Overcome complexity and enable future-readiness (デジタル主権：複雑さを克服し、将来に備える) 6 月 16 日から 18 日にフィラデルフィア (ペンシルベニア州) で AWS re:Inforce 2025 が開催されます。このイベントにぜひ参加して、現地でセキュリティ学習の機会を得ることをご検討ください。みなさまとお会いできることを楽しみにしています！ これらの新しい発表がお客様の組織のセキュリティポスチャの改善にどのように役立つかについて話し合いたい場合は、AWS がお手伝いします。今すぐ お問い合わせ から AWS アカウントチームにご連絡ください。 このブログに関する質問がある場合は、 AWS Security, Identity, &amp; Compliance re:Post で新しいスレッドを開始するか、 AWS Support にお問い合わせください。 Marshall Jones Marshall は AWS のワールドワイドセキュリティスペシャリストソリューションアーキテクトです。エッジ、脅威検知、コンプライアンスなどの様々なセキュリティ領域に焦点を当てた AWS コンサルティングとセキュリティアーキテクチャの経験を持ちます。現在は、セキュリティの有効性を高めリスクを低減するため、エンタープライズの AWS ユーザーによる AWS セキュリティサービスの導入と運用を支援することに注力しています。 Apurva More Apurva は AWS セキュリティ、ID、およびコンプライアンスチームのメンバーで、スタートアップから大企業まで、グローバルなプロダクトマーケティングにおいて 13 年の経験を持っています。市場ポジショニング、競合分析、カスタマーインサイトの専門家として知られ、製品ビジョンと市場ニーズ、ビジネス目標を整合させるため、部門を超えて協働しながら、ターゲット層に響く製品を展開し、収益成長を推進してきました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

昨年12月の AWS re:Invent に現地参加いただいた製造業のお客様を対象に、2025年2月7日(金)に「AWS re:Invent 2024 製造業のお客様向け 現地参加業 Meet-up」を開催しました。AWS re:Invent で学習いただいた内容を振り返りつつ、それを受けて各社で行っている活動内容をご共有いただき、今後の社内活動の発展につなげるネットワーキングの場としてしていただくことを目的としています。ご参加いただいた皆さまには、改めて御礼申し上げます。本ブログでは、当日のレポートをお届けします。 当日のアジェンダ オープニング AWS re:Invent Recap AWS re:Invent 2024 参加企業によるピッチコンテスト ピッチコンテスト表彰式・懇親会 クロージング AWS re:Invent Recap アマゾン ウェブ サービス ジャパン 技術統括本部 自動車・製造グループ 本部長 岡本 京 AWS re:Invent で発表された最新情報や製造インダストリーでの取組みについて、アマゾン ウェブ サービス ジャパン 技術統括本部 自動車・製造グループ 本部長 岡本よりダイジェストレポートをお届けしました。冒頭はクイズを実施し、re:Invent は昨年何回目だったか？、re:Invent 2024 で提供されたセッションの数は？と歴史や規模を振返りました（13回目、2,300セッションです！）。新しい Building Block として Inference (推論) が加わり、 Amazon Nova や Amazon Bedrock の数学的手法を使った新しいガードレール機能、複数 AI エージェントのオーケストレーションを容易にする機能のアップデートなどを振返りました。また、製造業のお客様事例をピックアップして紹介しました。イタリアの産業用車両メーカーである Iveco Group では、AWSと戦略的パートナーシップを提携し、車両ソフトウェア開発環境の整備、技術文書管理システム、図面解析システムを構築し、例えば技術図面の検索時間90%短縮、技術文書の誤りを75％削減しています( PRO202 )。イギリスのミールキット会社の Gousto は、工場のダウンタイム検知システムを構築し、稼働率目標を98％達成、スループットも10％向上しています( MFG202 )。製薬会社の Moderna はサプライチェーン管理プラットフォームを4ヶ月で構築し、配送時間短縮、在庫管理の改善を実現しています( BIZ220 )。エレベーター企業の KONE は生成AIを活用した技術者支援アプリを開発し、250人のフィールドサービス担当者に展開中です( AIM302 )。その他、エッジコンピューティング活用事例として Wiwynn 社が AWS Outposts を利用してアプリのデプロイ時間を90％削減している例などを紹介しました( HYB201 )。 AWS re:Invent 2024 参加企業によるピッチコンテスト 実際に現地参加いただいたお客様から、AWS re:Invent での学びと経験を自社に持ち帰り具体的に何を実現されようとしているのか、今後の活動見込みをご紹介いただきました。 三菱電機株式会社 AI戦略プロジェクトグループ 塚田 真規 様 お客様資料 ピッチコンテストのトップバッターは三菱電機株式会社 AI戦略プロジェクトグループ 塚田様に務めていただきました。AI戦略プロジェクトグループは、生成AI関連の取り組みを主導し、全社的な検証環境の提供や開発加速化支援を行っています。また、エンジニア同士のつながりを重視し、「 Serendie Bootcamp コミュニティ」（1,400人以上が参加）や「 MAWS-UG 」といったコミュニティを運営しています。これらのコミュニティを活用し、事前交流会や事後報告会など、様々なイベントを実施しています。生成AIの具体的な活用事例として、生産ラインのトラブル対応の効率化プロジェクトを紹介していただきました。Amazon Bedrock の Multi-agent collaboration 機能と Model Dilsillation (蒸留) 機能を活用し、属人性の高い作業の自動化と運用コストの削減を目指しています。最後に、AWS re:Invent の現地参加の意義として、登壇者との直接交流を通じた「しこう」（考える思考とトライアルの試行）に触れることができる点を挙げ、そこで得た知見を社内で共有することの重要性を強調しました。 株式会社ＤＮＰ デジタルソリューションズ コミュニケーションプロセス開発本部第１部 IPS オフショア課 Nguyen Dinh Hoang 様 続いて、株式会社ＤＮＰ デジタルソリューションズ コミュニケーションプロセス開発本部第１部 IPS オフショア課の Hoang 様より、参加報告をいただきました。ＤＮＰ 社からは熱意のあるメンバー4名で参加され、AWS 関連サービスのキャッチアップ、現地でしか体験できないハンズオンセッションへの参加と Expo での交流を目的としていました。特に印象的だったのは、世界中から6万人が集まる規模感と、セッションの質の高さ、基礎から応用まで実務に即した内容で、開発者と直接対話できたことでした。また、AWS re:Invent で知った AWS Builders Cards (カードゲーム形式の学習教材) にインスピレーションを受け、同社のIPS (Information Processing Service) 業務の改善に向けて、社内向けにアレンジした教材を独自に開発しています。これにより、リモートワーク環境下でのコミュニケーション活性化や、新フレームワークの理解促進につながっています。 得られた知見を活かした自己成長と、より効率的な学習教材の開発という具体的な成果を挙げ、「行って良かった」と締めくくりました。 ダイキン工業株式会社 テクノロジー・イノベーションセンター 主任技師 前川 博志 様 三社目は、ダイキン工業株式会社 テクノロジー・イノベーションセンター 前川様からの参加報告です。AWS re:Invent でインパクトが大きかったことの1つとして、Amazon CTO Dr. Werner によるキーノートから「Simplexity」という言葉を挙げました。システムはどんどん複雑になっていくので、自分たちで扱える単位に分割して、ある部分を他者に委ねることが重要と考え、例えば Amazon Aurora DSQL のようなものを自分たちで作ろうとすると複雑になりコストも掛かるが、AWS のサービスをうまく使うことで、自分たちで複雑なシステムを開発・管理する負担をオフロードしていけるのではないか、と述べました。また、敢えてこの時代に AWS re:Invent に現地参加したことの意義について触れ、Chalk Talk や Code Talk といったホワイトボーディングやソースコードを見ながらのセッションが非常に多く、日本では考えられないほど大盛況になっていたのに驚き、現地で対面で話すことの意義が大きいと感じています。自社に帰ってからは、社内コミュニティに AWS メンバーを巻き込んだり、他社コミュニティとの共同イベント実施の企画、社内の RAG システム戦略を Amazon Bedrock を最大限活用するものにアップデートしています。 コニカミノルタ株式会社 技術開発本部 システム技術開発センター アーキテクチャ開発部 第1グループ 井田 匠海 様 最後に、コニカミノルタ株式会社 技術開発本部 システム技術開発センター アーキテクチャ開発部 第1グループ 井田様より、初めて参加した AWS re:Invent でのご経験を共有いただきました。先端技術と熱気に触れることで当事者意識が芽生え、モチベーションが向上したこと、言語の壁を超えて、自然とコミュニケーションが生まれていったことを現地参加の効果として挙げています。また、ぜひ取り入れていきたい新サービスとして、 Amazon Q Developer 、 AWS Transfer Family Web Apps 、 Centrally managing AWS IAM root access を挙げ、その理由とともに紹介しました。また、 AWS GameDay にも参加し、57チーム中22位という成績を収め、グローバルな技術レベルを体感できた点についても触れました。最後に、AWS初心者や英語が苦手な人でも、グローバルな基準を実際に見られる貴重な機会として、イベントへの参加を強く推奨しました。一週間という集中的な学習期間で、専門分野を超えた人との繋がりや、新しい技術への知見を得られる機会として、非常に有意義な経験だったとの報告でした。 ピッチコンテスト表彰式・懇親会 コンテストはご参加いただいた約30社の皆さまで投票を行い、見事第1位に選ばれたのは、三菱電機株式会社 塚田様の発表でした。おめでとうございます！その他3社の皆様も、ご登壇いただきありがとうございました。懇親会では、登壇された方を囲むようにして質問をされる方が続いたり、それぞれの AWS re:Invent 体験談の共有、各社のコミュニティ事情について意見交換し合ったりなど、積極的な交流がされていました。 まとめ AWS re:Invent の期間中には日本企業向けの Meet-up もありますが、開催後にフォローアップの Meet-up イベントを AWS 主催で行うのは実は初めてのことでした。AWS re:Invent に現地参加された方々は、最新技術のキャッチアップや活用、社外との交流に意欲的なだけでなく、学んだことを自社に持ち帰って、自社のサービスや業務改善に素早く取り入れたり、より多くの仲間に体験を共有し、コミュニティを活性化することで同じ経験を広げていきたいとするモチベーションが高い方ばかりでした。「2ヶ月前の熱気を思い出せてとても満足だった」「現地は人が多すぎて、製造業同士で交流するチャンスがなかったので、大変ありがたいです」「ぜひ大阪などでも開催いただきたいです！」「他社の参加された方が持ち帰った内容や、自社での共有、活用方法をお聞きでき、とても参考になった。ぜひ来年も開催していただきたい。」などのコメントが寄せられました。また1年後も、さらにスケールアップした Meet-up が開催できるのを楽しみにしています。 本ブログはソリューションアーキテクトの中山 七美が執筆しました。

みなさん、初めまして。今週から週刊生成AIを担当する、AWS ソリューションアーキテクトの野間です。AWSや生成AIにあまり詳しくない方にも分かりやすいブログにしたいと思いますのでよろしくお願いします。 先週に引き続いてのご案内となりますが、2025 年 3 月 6 日 に&nbsp; AWS Innovate: Generative AI + Data &nbsp;がオンラインで開催されます。最新の AWS の生成 AI サービスとお客様事例を通じたユースケースを学ぶことができるイベントとなっています。アジェンダも公開されていますのでご覧の上ぜひご登録ください！ 早速今週も盛りだくさんの内容になっています。2 月 10日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「Benchmark Education社、AWSの生成AIで採点を加速し学生へのフィードバックを強化」 教育関連企業のBenchmark Educationは、先生方の採点業務の負担を減らすため、AWSと協力してAIを活用した採点支援ツールを開発しました。このツールは、生徒の記述式の回答を自動で採点し、フィードバックを提供します。先生はAIの採点結果を確認し、必要に応じて修正することができます。導入後、未採点の課題が減少し、先生方は生徒と直接関わる時間を増やすことができるようになりました。このように、AIを活用することで、教育現場での業務効率化と生徒へのサポート向上を実現しています。 ブログ記事「Amazon Bedrockインラインエージェントを使用した動的なロールベースAIエージェントの構築」 Amazon Bedrockの「インラインエージェント」について説明しています。インラインエージェントは、ユーザーの役割や状況に応じて動的に機能を変更できるAIアシスタントを作成できる機能です。例として、HR（人事）アシスタントを構築し、従業員と管理者で利用できる機能を動的に変更する方法が紹介されています。従業員は休暇申請や経費精算などの基本的な機能を、管理者はそれらに加えて人事評価などの追加機能を利用できます。この機能により、複数のエージェントを作成することなく、1つのAIアシスタントで柔軟な対応が可能になります。 ブログ記事「Amazon Bedrock AgentsによるSAPインスタンス管理の活用」 このブログは、AWSのAmazon Bedrock Agentsを使用してSAPシステムの管理を効率化する方法について説明しています。Amazon Bedrock AgentsとLambda関数を組み合わせることで、従来は手作業で行っていたSAP管理タスクを自動化することができ、管理者の作業効率が向上します。SAPの管理者は、自然言語を使ってSAPシステムの起動・停止、パラメータの確認、ログファイルの分析などの作業を実行できるようになります。また、Knowledge Base機能を使用することで、大量のログファイルから必要な情報を素早く見つけることも可能です。 ブログ記事「Amazon Bedrockで学習データを自動生成し、質問応答システムのファインチューニングを実現」 このブログは、Amazon Bedrockを使用して大規模言語モデル(LLM)のファインチューニングを行う方法について説明しています。特に、データが不足している場合に、より大きな言語モデル（教師モデル）を使って合成データを生成し、それを使って小さなモデル（生徒モデル）をファインチューニングする手法を紹介しています。この方法により、限られたデータでもモデルのパフォーマンスを向上させることができます。実験結果も紹介されていますので是非ご参照ください。 ブログ記事「Amazon SageMaker AIでMedusa-1を使用したLLM推論の高速化を実現」 このブログは、大規模言語モデル(LLM)の推論速度を向上させるMedusaというフレームワークについて解説しています。Medusaは、モデルに追加のヘッドを付け加えることで、複数のトークンを同時に予測できるようにし、約2倍の速度向上を実現します。Amazon SageMakerを使用して、まずLLMのファインチューニングを行い、その後Medusaヘッドを追加して学習させる方法が説明されています。モデルの品質を維持したまま処理速度を向上させることができるので、リアルタイムの文章生成や会話システムなどの低遅延が求められるアプリケーションに有効です。 ブログ記事「Amazon Bedrockモデル評価における判定者としてのLLM」 このブログは、Amazon Bedrockで提供される「LLM-as-a-judge」という新機能について説明しています。この機能は、大規模言語モデル（LLM）の性能を自動的に評価するためのツールです。従来は人手で行っていたAIモデルの評価を、別のAIモデルが評価者（ジャッジ）となって自動的に行うことができ、評価にかかる時間とコストを大幅に削減できます。品質、ユーザー体験、指示への従順性、安全性など、様々な観点からモデルの性能を評価することができ、AWSのコンソールやPythonのSDKを使って簡単に利用することができます。企業がAIモデルの性能を効率的に評価し、最適なモデルを選択するのに役立つソリューションとなっています。 ブログ記事「概念から現実へ：RAGの実証実験から本番環境への移行ガイド」 このブログは、RAG（Retrieval Augmented Generation）を、実験段階から本番環境へ移行する際の重要なポイントについて解説しています。RAGを本番環境で運用する際には、品質、コスト、レイテンシーのバランスを取ることが重要で、Amazon Bedrockを活用することで効率的に実装できます。また、データの取り扱い方や分割方法、セキュリティ対策、システムの評価方法など、実用化に向けた具体的な最適化手法についても説明されています。RAGシステムを本番環境で活用したい開発者やエンジニアにとって、実践的なガイドラインとなる内容となっています。 ブログ記事「行政サービスの効率化に向けたAI活用のリーダーシップ」 このブログは、政府機関におけるAI活用とクラウド技術の重要性について説明しています。米国政府のデジタル変革において、セキュリティや効率性を確保しながら、政府機関がAIやクラウド技術を活用することで、より良い公共サービスを提供できることが示されています。例えば、米国空軍では予測メンテナンスにAIを活用し、航空機の運用効率を向上させています。また、シンガポールや英国などの事例も紹介され、世界中の政府機関がAWSを活用してデジタル変革を進めていることが分かります。 ブログ記事「Amazon SageMaker JumpStartでFalcon 3モデルが利用可能に」 Amazon SageMaker JumpStartでFalcon 3モデルファミリーの提供を開始しました。Falcon 3は、アブダビのTechnology Innovation Institute（TII）が開発した、科学、数学、コーディング能力に特化したオープンソースの言語モデルです。現在、SageMaker JumpStartでは、1Bから10Bまでの様々なサイズのモデルが利用可能で、ユーザーはUIを使用した簡単な操作か、PythonのSDKを使用したプログラミングのどちらかの方法でモデルをデプロイすることができます。このサービスにより、機械学習の専門家でなくても、高度な言語モデルを簡単に利用することが可能になりました。 ブログ記事「Amazon Bedrock Agentsを使用したバーチャル気象予報士の構築」 このブログは、Amazon Bedrock Agentsを使用して、天気予報に関する質問に答えることができるAIバーチャル気象予報士を構築する方法について説明しています。このソリューションでは、ユーザーが自然な言葉で天気に関する質問をすると、AIが適切な回答を提供します。システムの構築には、Amazon Bedrock Agents、AWS Amplify、AWS Lambda、Amazon Cognitoなどの複数のAWSサービスが使用されており、ユーザー認証から天気情報の取得まで、すべての機能が統合されています。例えば「今日ダラスでバーベキューができますか？」といった質問に対して、天気状況を考慮した回答を提供することができます。 ブログ記事「Amazon Pharmacy、生成AIで処方箋処理時間を90%改善」 Amazon Pharmacyをご存じでしょうか？、Amazonが提供するオンライン薬局サービスです。このブログでは、Amazon PharmacyがAWSの生成AIを活用して処方箋処理を改善した事例を紹介しています。Amazon Pharmacyは、生成AIを処方箋の受付、保険確認、処理、配送まで全体のプロセスに組み込むことで、処方箋の処理時間を90%削減することに成功しています。また、HIPAA準拠のチャットボットを導入することで、お客様は従来の対面式の薬局よりも素早く必要な情報を得られるようになりました。開発期間も9ヶ月から3ヶ月に短縮され、データ管理とテストを重視した開発アプローチが成功の鍵となりました。このケースは、生成AIが医療分野の顧客体験を大きく向上させる例を紹介しています。 ブログ記事「AWSの生成AIを活用したHansenによる通信事業者向け製品カタログの最適化」 このブログは、HansenとAWSが中心となり開発した、AIを活用した製品ライフサイクル管理ソリューション紹介しています。このソリューションは、Amazon Bedrockの生成AIを使用して、通信サービスプロバイダー（CSP）の製品カタログを分析し、最適化するためのレコメンデーションを提供しています。従来は手作業で時間がかかっていたカタログ分析や製品の最適化が、AIアシスタントによって数秒で実行できるようになりました。 ブログ記事「Amazon Bedrockにおける最小権限アクセスの実装」 このブログは、Amazon Bedrockにおける最小権限アクセスの実装方法について説明しています。最小権限アクセスとは、ユーザーやプログラムに必要最小限の権限のみを付与するセキュリティの考え方です。ブログでは、モデルの選択から運用までの各段階で、どのようにアクセス制御を実装すべきかを具体的に解説しています。 ブログ記事「最新のコミュニケーションハブを使用したAI駆動の顧客体験の構築」 このブログは、SMSやWhatsApp、メールなどの複数のコミュニケーションチャネルを一元管理し、そこにAmazon Bedrockなどの生成AIサービスを組み合わせることで、パーソナライズされた顧客対応を実現する方法を紹介しています。顧客とのやり取りデータを一元管理し、分析できる仕組みも紹介されており、効果的な顧客対応実現の参考になります。 ブログ記事「Amazon Q Business、企業のナレッジベースの大規模統合を簡素化」 このブログは、企業の大規模なデータを効率的に取り込み、処理する方法を紹介しており、特にAWSのサポートエンジニアリングチームでの実際の活用事例を基に解説しています。Amazon Q Businessを使用することで、社内の文書やデータを安全に統合し、自然な会話形式で必要な情報にアクセスできるようになります。このソリューションにより、企業は業務効率を向上させ、より迅速な情報アクセスと意思決定が可能になります。 ブログ記事「国防総省のためのゼロトラスト構築：国防総省CIOゼロトラストプログラム管理室長Les Callからのインサイト」 このブログは、米国国防総省(DoD)のゼロトラスト戦略の実装に関する内容を解説しています。従来のセキュリティモデルでは十分な対応が難しくなってきている中、DoDはAWSと協力してゼロトラストアーキテクチャの導入を進めています。組織全体での相互運用性の確保や、AIを活用した予防的なセキュリティアプローチの採用など、様々な取り組みが行われています。 ブログ記事「Rich Data CoとAWSの生成AIによる与信判断の変革」 このブログは、Rich Data Co (RDC)という企業がAWSの生成AIを活用して、クレジット審査の意思決定を改善する取り組みについて説明しています。Amazon Bedrockを活用してデータサイエンスチームをサポートする「データサイエンスアシスタント」と、ポートフォリオマネージャーや分析者をサポートする「ポートフォリオアシスタント」という2つのAIアシスタントを開発・構築され、複雑な質問への回答やコード生成、データベース検索などの機能を提供しています。 ブログ記事「Amazon BedrockとAppianの生成AIスキルによるビジネスプロセスの革新」 このブログは、AmazonのBedrockとAppian社の生成AIスキルを組み合わせたビジネスプロセス改革についての取り組みを紹介しています。特に住宅ローン処理の期間短縮や、金融サービスでのデータ抽出時間の削減、法的文書のレビュー効率化などの事例が紹介されています。 ブログ記事「DeepSeek-R1、CrewAI、Amazon SageMaker AIを使用したエージェントAIソリューションの構築」 このブログは、Amazon SageMaker AIとDeepSeek-R1、CrewAIを組み合わせて、AIエージェントシステムを構築する方法について説明しています。研究を行うエージェントと文章を作成するエージェントの2つを連携させて動作させる実践的な例を紹介しています。 ブログ記事「Crop.photoとAmazon Rekognitionによる一括画像編集の自動化」 このブログは、AWSのパートナーであるEvolphin Software社が提供する「Crop.photo」というサービスについて説明しています。Crop.photoは、AIを活用した画像の一括編集ツールで、主にEコマースやスポーツ業界向けに開発されました。Amazon Rekognitionと連携することで、大量の商品画像やスポーツ選手の写真を自動で効率的に処理することができます。例えば、ある小売業者では画像編集の生産性が70%向上し、数日かかっていた作業が数秒で完了できるようになりました。 ブログ記事「コンソール上の Amazon Q からベストプラクティスを学ぼう」[翻訳記事] このブログは、Amazon Qの活用方法について説明しています。Amazon Qは、AWSコンソール上で開発者やIT担当者の作業をサポートする便利なツールです。具体的には、AWSサービスの学習支援、コードスニペットの生成、システム設計のアドバイス、コスト分析などができます。質問をすると自然な会話形式で回答が得られ、AWSの知識が少ない方でも簡単に利用できます。また、プロンプトの書き方のコツもなど、より良い回答を得るためのヒントも記載されています。 ブログ記事「20 Minutes 社がAmazon Bedrock で生成 AI を活用してジャーナリストを支援し購読者を惹きつけている方法」[翻訳記事] このブログは、フランスの主要メディア「20 Minutes」が、ジャーナリストの作業効率を向上させるため、記事の要約作成や関連タグの提案、ニュース通信社からの記事の書き直しなどの作業を生成AIを利用して自動化しています。また、広告主向けに記事のブランドセーフティ（広告掲載に適しているかどうか）を自動評価する機能も実装しました。その結果、1記事あたり平均8分の時間短縮を実現し、ジャーナリストが本来の取材・執筆業務に集中できるようになりました。 ブログ記事「AWS が生成 AI で E コマースにおけるショッピングアシスタントを強化」[翻訳記事] このブログは、AWSが提供する新しいAIショッピングアシスタントについて紹介しています。このAIアシスタントは、オンラインショッピングをより便利で楽しいものにするために開発されました。例えば、DIYプロジェクトのための建材選びなど、商品選択に迷う顧客に対して、パーソナライズされたアドバイスを提供します。Amazon Bedrockなどの最新のAI技術を活用し、顧客の質問に自然な対話で応答しながら、最適な商品を推薦することができます。 サービスアップデート Amazon Q Developer now supports upgrade to Java 21 Amazon Q Developerは、Java 21へのアップグレードをサポートするようになりました。開発者は安全にシステムを最新化することができ、性能向上やセキュリティ強化といったメリットを得ることができます。この機能は、Visual Studio CodeやIntelliJ IDEAといった一般的な開発ツールで利用可能です。 Amazon Q generative SQL is now available in additional regions Amazon Q generative SQLの提供リージョンを拡大し、米国東部（オハイオ）とアジア太平洋（ソウル）でも利用可能になりました。Amazon Q generative SQLは、Amazon Redshiftのウェブベースのクエリエディタで使用できる機能で、自然言語を使用してSQLクエリを作成できます。この機能により、SQLの専門知識に関係なく、ユーザーは会話形式でデータベースに対してクエリを実行することができます。 AWS HealthScribe now supports GIRPP note template for behavioral health AWS HealthScribeの新機能として、メンタルヘルスに関する診療記録をGIRPP形式で自動生成する機能をリリースしました。この機能は、医師と患者の会話を生成AIが自動的に文書化することで、医療従事者の記録作成の時間を大幅に削減することができます。この機能は米国東部（バージニア北部）リージョンで利用可能となっています。 Anthropic’s upgraded Claude 3.5 Sonnet now available in the Asia Pacific (Sydney) Region Anthropicの最新モデル「Claude 3.5 Sonnet」がアジアパシフィック（シドニー）リージョンで利用可能になりました。 以上、今週も盛りだくさんでしたが、さらにもう一つだけ。 AWSのBIサービスである Amazon QuickSight に生成AIアシスタントである Amazon Q の機能が追加され、自然言語で質問や分析ができるのはご存じでしょうか？その生成AIの機能を簡単に試していただけるデモサイトが こちら にあります。Amaon Q in QuickSight は正式には日本語サポートをしていないのですが、すでにかなり日本語を解釈するようになっています。デモサイトには日本語のサンプル質問文がありますので、ぜひ試してみてください。 それでは、また来週お会いしましょう！ 著者について 野間 愛一郎(Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近は自宅焼き鳥で串打ちにハマっています。