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

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

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

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

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

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

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

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

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

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

本ブログは 株式会社グレイプ様と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの田中です。 2024 年は、非常に多くのお客様に、生成 AI の活用にチャレンジいただいた一年でした。生成 AI を活用した文書要約やチャットボットなど、社内の業務効率化に繋がる多くのユースケースが生まれました。さらに喜ばしいことに、生成 AI 活用をコアビジネスの価値向上や成長加速に繋がる事例も増えてきています。 今回ご紹介するのは、生成 AI の活用をコアビジネスの成長加速に繋げた、チャレンジングな取り組みです。月間 1.8億 PV を誇るウェブメディア「 grape（グレイプ） 」を運営する 株式会社グレイプ様 が、AWS の生成 AI サービスである Amazon Bedrock を活用して、メディアビジネスの根幹である高品質なコンテンツ制作を加速させた事例をご紹介します。 グレイプ様の状況と経緯 「 grape（グレイプ） 」は、「心に響く」をコンセプトに、読者の共感を呼ぶコンテンツを提供し続けているウェブメディアです。近年、ユーザーの情報収集手段はますますオンラインへとシフトし、従来型のマス広告だけでなく、個々のユーザーの興味や関心に寄り添ったコンテンツマーケティングの重要性が高まっています。グレイプ様は、長年培ってきたウェブメディア運営のノウハウを活かしながら、より多くの価値ある情報をユーザーに届けるためにチャレンジをし続けています。 グレイプ様が日々公開するコンテンツは、数十件にも及びます。その一つ一つに、読者の心に響く質の高さが求められます。プロのライターたちは、生成 AI には真似できないクリエイティビティを発揮されつつ、魅力的なコンテンツを多く生み出していますが、一方では課題を抱えていました。 一つは記事の校正に関する課題です。記事の品質を担保するため、各記事は二名体制での校正を行っています。校正作業は、誤字脱字のチェック、語彙のゆらぎのチェック、表現のチェックなどに加えて、HTML タグの確認など技術的な要素も含まれるケースがありました。そのため、経験が豊富なライターに頼らざるを得ない校正がいくつかあり、そのための作業に時間が費やされていました。 二つ目はタグ付けに関する課題です。記事の適切な分類と発信のためにタグは不可欠ですが、このタグはライターの経験と勘をもとに付与されていました。似たような記事でも人によってつけるタグが違ったり、経験が浅いライターにとっては効果的なタグがどれかわからないなど、適切なタグ付けが難しい状況にありました。 ソリューション／構成内容 これらの二つ課題に対して、グレイプ様は、ライターの方々に記事のライティング業務に集中してもらうため、校正作業に生成 AI の力を活用できないか、という発想からプロジェクトがスタートしました。検討の結果、Amazon Bedrock を活用したアプリケーションの構築を決定しました。コンテンツ制作はビジネスの核となる部分であるため、入力したデータが基盤モデルの学習に使用されない点が、重要な選定理由となりました。 様々な基盤モデルを比較検討した結果、 Anthropic Claude 3.5 Sonnet (v1) を採用することにしました。この基盤モデルを選んだ理由として、1) 日本語の校正に特に高い精度を示したこと、2) 簡単な文書作成においてライターから見ても自然な日本語表現ができており今後さらなる活用につながる見込みがあること、3) 応答時間とコストが現実的な範囲に収まったこと、の三点が挙げられます。 開発したアプリケーションのもつ主要機能は、以下の二つです。 1.校正支援機能 記事作成の加速を目指し、生成 AI を活用した校正支援の仕組みを構築しました。まず、ライターが作成したドラフト文書に対して、基盤モデルが誤字脱字のチェックを実施します。さらに、グレイプ様では独自の表記ルールを持っているため、このルールに沿っていない表現を見つけた場合、基盤モデルが適切な表現への置き換えを提案します。加えて、記事のドラフトに含まれる HTML タグについても、基盤モデルがチェックを行い、不適切な記述があれば正しい表記への修正を行います。 2.タグ推薦機能 基盤モデルに記事の内容をインプットとして与えると、アウトプットとして適切なタグを提案してくれる機能を実装しました。基盤モデルに対しては、記事の内容とともに、JSON 形式のタグ使用実績データも一緒に与えるようにアプリケーション内で実装しました。これによって、基盤モデルがよく利用されているタグから適切なタグを提案することができるようになり、タグに一貫性をもたせることを可能にしました。また、実際に付与するタグはライターが付与するので、その選別の手助けとなるよう、選別したタグの推薦理由も提案するようにしました。 （実際のアプリケーション画面） これらの機能開発は、記事校正ツールの開発 2 週間、タグ推薦ツールの開発はわずか 3 日間、という速さで行われました。主に開発を担当された柳本様は、それまで AWS のご経験はありませんでしたが、インフラ運用のご経験を活かし、まずはイメージがつきやすい Amazon Elastic Compute Cloud(Amazon EC2) をご自身で構築され、その上でアプリケーションの開発を進めました。 また、柳本様は生成 AI の活用も初めてのご経験でしたが、積極的にプロンプトエンジニアリングにも挑戦されました。開発中に期待する精度が得られないケースも発生しましたが、それらの問題解決にも時に生成 AI を活用しながら、一つ一つ解決していきました。 さらに、システムのテスト公開後は、ユーザーからのフィードバックを即座に取り込める体制を整えました。具体的には、実際に使用して期待する結果が得られなかった場合に、ユーザーがすぐに報告できるインターフェースを用意しました。この仕組みにより、ユーザーのフィードバックを元に追加開発を行う PDCA サイクルを素早く回すことができ、結果としてユーザーの積極的な利用に繋がりました。 導入効果 Amazon Bedrock を利用したアプリケーションの導入により、以下の効果が得られました。 記事の校正に関わる作業工数が 60 ％削減 記事のタグ選定に関わる作業工数が 20 %削減 数字では表せない定性的な効果もあがっています。例えば、校正作業の品質が均一化され、一定水準以上の質が保たれるようになりました。また、タグ付けにおいても、より適切で一貫性のある記事分類が可能になりました。 導入を担当された柳本様からは「AWS・AI 初学者でも生成 AI を使ってコードを作成し、実務対応レベルのツールが作れました。自分になんてと思わず生成 AI を活用して社内の課題にまずは挑戦するという気持ちが大切です。」とコメントをいただいています。 まとめ 本事例は、文章コンテンツをコアビジネスとする企業が、生成 AI を活用してビジネスの加速に繋げることができた好例です。人しか出せない価値について理解を深めていたからこそ、効果的な生成 AI の活用ができたのではないかと思います。また、短時間での構築を実現した点も注目です。AWS では、サーバーレスな API 形式で提供される生成 AI に加え、仮想サーバーやコンテナ、サーバーレスといったコンピューティングサービスなど、お客様のスキルセットやビジネス要件に合うサービスを選択して組み合わせることができます。これらをうまく活用することで、迅速なサービスリリースにつなげることができます。 グレイプ様では、さらなる進化を目指しています。具体的には、プロンプトの継続的な改善や、RAG（Retrieval Augmented Generation）の活用を通じて、コンテンツの品質向上に取り組んでいく予定です。 生成 AI を活用したビジネスの促進、業務の効率化、AWS が提供する様々なサービスの選択肢にご興味をお持ちの方は、お気軽にお問い合わせください。 株式会社グレイプ : 技術開発部長 大槻 大作 様（中央右）、技術開発部 主任 柳澤 良介 様（中央左）、技術開発部 柳本 安利 様（中央） Amazon Web Services Japan : アカウントマネージャー 石井 美佑子（右端）、ソリューションアーキテクト 田中 里絵（左端） ソリューションアーキテクト 田中 里絵

本記事は 2024年11月25日に公開された「 Simplify global hybrid connectivity with AWS Cloud WAN and AWS Direct Connect integration 」 を翻訳したものです。 この投稿では、 AWS Cloud WAN の AWS Direct Connect アタッチメントを使用したハイブリッド接続アーキテクチャを構築する方法について解説します。また、オンプレミス環境とAWSクラウド間のシームレスな接続を実現するための、グローバルハイブリッドネットワークの設計におけるベストプラクティスや考慮事項についてご紹介します。 2024年11月25日より、AWS Cloud WAN は AWS Direct Connect ゲートウェイアタッチメントをネイティブでサポート しています。この統合により、中継点に AWS Transit Gateway を使用しなくても、グローバルなハイブリッドネットワークをより柔軟に設定できるようになります。AWS Direct Connect ゲートウェイが AWS Cloud WAN セグメントとオンプレミス環境間の経路を直接広報できるようにすることで、ルーティング管理を簡素化できます。 AWS Direct Connect ゲートウェイ を コアネットワーク に接続して、特定の AWS リージョン や Cloud WAN セグメントに応じたルーティング動作を実現できます。 この記事の最初のセクションでは、この新機能の仕組みについて解説するとともに、AWS Cloud WAN のグローバルネットワークに AWS Direct Connect を統合する際の代表的な3つの新規導入シナリオを紹介します。その後、現在 AWS Transit Gateway を介して AWS Cloud WAN と AWS Direct Connect を利用しているお客様向けに、推奨される移行方法を解説します。 前提条件 Amazon Virtual Private Cloud（Amazon VPC） 、AWS Direct Connect、AWS Transit Gateway、AWS Cloud WANといった AWS のネットワーク構成要素に精通していることを前提としています。これらのサービスの詳細な説明は行わず、それぞれの機能や取り上げるルーティングシナリオでの活用方法について説明します。この記事で紹介する移行のベストプラクティスに関する背景情報として、Transit Gateway を含むハイブリッドルーティングアーキテクチャを取り上げた以前の記事「 Advanced hybrid routing scenarios with AWS Cloud WAN and AWS Direct Connect 」をご覧になることをお勧めします。なお、本記事では AWS Cloud WAN のセグメンテーション戦略やコアネットワークセグメントの作成や管理方法については詳しく扱いません。これらについては、AWS Cloud WAN の ドキュメント をご参照ください。 基本構成 簡素化のために、AWS クラウドリソースを 3つの AWS リージョン （ap-southeast-2、us-west-2、us-east-1）にまたがって展開する基本構成（図1）を使用します。コアネットワークの各 AWS リージョンで、AWS Cloud WAN はコアネットワークエッジ (CNE) をデプロイ及び管理します。ワークロード用に Production, Development, Hybrid の3つのセグメントを設定しました。本記事で紹介する構成は、セグメント数、アタッチメントタイプ、および AWS リージョン数が異なる環境にも適用可能です。テスト環境として図示されたような AWS Cloud WAN コアネットワークを作成したと仮定しています。 ドキュメント には、図1のアーキテクチャに類似したセグメントを持つコアネットワークのポリシー例が記載されています。           図 1: 3つの AWS リージョンにわたる AWS Cloud WAN コアネットワークを示す基本構成 AWS Cloud WAN の Direct Connect アタッチメントを設定する方法について、3つのシナリオを解説します。簡素化させるために、各シナリオでは Cloud WAN コアネットワーク上で個別のセグメントを使用します。 最初の 2 つのシナリオでは、2 つの異なる AWS Direct Connect ゲートウェイを Development セグメントとProductionセグメントにそれぞれ接続し、AWS 環境とオンプレミス環境間のエンドツーエンドのセグメンテーションを実現します。 3 番目のシナリオでは、Hybrid セグメントを使用し、2 つの新しい Direct Connect ゲートウェイを使用してグローバルルーティングセグメンテーションを設定します。この例では、ハイブリッドセグメントはオンプレミスからのパートナー接続専用であり、Production および Development セグメントとは直接通信しません。 仕組み 1 つ以上の Direct Connect ゲートウェイを、コアネットワークリージョンの全てまたは一部に AWS Cloud WAN コアネットワークにアタッチできます。Direct Connect ゲートウェイをコアネットワークの一部のリージョンにのみ関連付けた場合、そのゲートウェイは関連付けられたリージョン内のローカル経路のみを受け取ります。 この統合 により、オンプレミスのルーターは、コアネットワークが Direct Connect ゲートウェイを通じて広報した経路の完全な BGP AS_PATH 属性を受け取れるようになります。これにより、グローバルネットワーク全体のルーティングの可視性が向上し、オンプレミス環境できめ細かいルーティング制御が可能になります。 Cloud WAN と Direct Connect の統合設定を、ステップごとに確認していきましょう。まず基本構成から始め、新しいDirect Connect ゲートウェイを作成し、それを Cloud WAN の3つのリージョンすべてにまたがる Development セグメントに接続します。 ステップ 1: Direct Connect コンソール に移動し、「 Direct Connect ゲートウェイ 」を選択して、「 Direct Connect ゲートウェイを作成する 」をクリックします。図 2 に示すように、Direct Connect ゲートウェイの 名前 と 自律システム番号 (ASN) を設定します。Direct Connect ゲートウェイ ASN は一意でなければならず、コアネットワークの ASN 範囲またはオンプレミス環境と重複してはなりません。「 Direct Connect ゲートウェイを作成する 」をクリックします。 図 2: Direct Connect Gateway の作成 ステップ 2: AWS Network Manager コンソール に移動し、 グローバルネットワーク を選択します。 コアネットワーク に移動し「 アタッチメント 」 を選択します。「 アタッチメントの作成 」をクリックします。アタッチメントには、以下を設定します。 (オプション) 名前 : アタッチメントの名前を入力します。 アタッチメントタイプ : Direct Connect エッジロケーション : コアネットワークの AWS リージョンの全てまたは一部をアタッチ対象として選択します。この例では、コアネットワークが設定されているすべての AWS リージョンを選択します。後述の「知っておくべきこと」のセクションで、AWS リージョンを選択するためのベストプラクティスを紹介します。 Direct Connect ゲートウェイ : ステップ 1 で作成した Direct Connect ゲートウェイを選択します。 タグ : Cloud WAN アタッチメントポリシーに合わせて適切な Key と Value のペアを設定します。 図 3: Cloud WAN Development セグメントへの Direct Connect Gateway アタッチメントの設定 Cloud WAN ポリシーでセグメントに対して「 require-attachment-acceptance: true 」が指定されている場合は、アタッチメントを承認し、正しいセグメントへの関連付けを確認してください。アタッチメントの状態が「 Available 」になると、各 AWS リージョンのセグメントルートテーブルで Direct Connect ゲートウェイから受信した経路を確認できます。オンプレミスルーターでは、選択した特定の AWS リージョンのローカル経路を Cloud WAN セグメントから自動的に受信します。 本投稿では、Direct Connect 仮想インターフェイスの設定手順は説明しません。詳細については、AWS Direct Connect の ドキュメント を参照してください。 シナリオ1: 単一のオンプレミス拠点が AWS Cloud WAN グローバルネットワークの Development セグメントに接続される場合 図4は、前述の「仕組み」のセクションで説明した設定手順を実施した後のアーキテクチャを示しています。Direct Connect ゲートウェイを Development セグメントに接続し、3つの CNE すべてに関連付けました。このサンプルアーキテクチャでは、2つの Direct Connect トランジット仮想インターフェース（VIF）を使用しており、それぞれ2本の物理的な Direct Connect 接続に分散されています。1本目の物理接続にはプライマリトランジット VIF（VIF-1）を、2本目にはセカンダリトランジット VIF（VIF-2）を設定しました。また、 Direct Connect BGP コミュニティタグ を設定し、アクティブ/パッシブ構成を実現しています。 簡略化のため、この例では AWS Direct Connect に対して高い冗長性を持つアーキテクチャは使用していません。 AWS Direct Connect でのアクティブ/パッシブ BGP 接続の構築  や、 AWS Direct Connect の回復性に関する推奨事項 について詳細を確認することをお勧めします。 図 4: シナリオ 1 – 2 つの AWS Direct Connect 接続と 2 つのトランジット仮想インターフェイスを備えた単一のオンプレミスロケーション 1.オンプレミスから AWS への経路広報 図 5 は、オンプレミスから AWS に広報された BGP 経路を示しています。 図 5: シナリオ 1 – オンプレミスから AWS への経路広報 (A), (B) – オンプレミスのルーターは、両方のトランジット VIF を通じて Direct Connect ゲートウェイに IPv4 および IPv6 のプレフィックスを広報します。BGP コミュニティタグを使用して、Direct Connect ゲートウェイの BGP ローカルプリファレンスを調整し、2つの VIF 間でアクティブ/パッシブルーティングを実現しています。 (C) – Direct Connect ゲートウェイは、すべての経路に自身の ASN を AS_PATH に追加し、関連付けられた CNE にすべてのプレフィックスを広報します。Direct Connect ゲートウェイは BGP コミュニティをそのまま保持しますが、これらの BGP コミュニティは AWS Cloud WAN の動作には影響しません。各 CNE は、Development セグメント用に最適な経路をルートテーブルに登録し、ネクストホップとしてDirect Connect ゲートウェイ Development を設定します。 (D) – 各 CNE は、Direct Connect ゲートウェイから受信した IPv4 および IPv6 経路に自身の ASN を AS_PATH として追加し、それらをリモートリージョンの他のすべての CNE に広報します。ただし、 CNE は他の CNE から受信したオンプレミス経路を優先しません。これは、Direct Connect ゲートウェイから直接受信した経路と比較して、他の CNE から受信した経路は AS_PATH 属性が長くなるためです。 2. AWS からオンプレミスへの経路広報 図6は、Cloud WAN から Direct Connect ゲートウェイを通じてオンプレミスに伝播される経路を示しています。AWS Cloud WAN に組み込まれた Direct Connect アタッチメントにより、 許可されたプレフィックスリスト の設定を必要とせず、経路が双方向で動的に伝播されます。 図 6: シナリオ 1 — AWS からオンプレミスへの経路伝播 (A) – すべての VPC プレフィックス（IPv4 および IPv6）は、アタッチメントポリシーの設定に基づいて、対応するセグメント内の CNE に自動的に伝播されます。また、コアネットワークには、 Connect や AWS Site-to-Site VPN といった他のアタッチメントタイプを使用することもできます。 (B) – CNE はセグメント内のすべてのローカル経路を互いに、そして関連付けられた Direct Connect ゲートウェイに広報します。 (C) – Direct Connect ゲートウェイは、自身の ASN を AS_PATH に追加し、すべてのプレフィックスを関連付けられたすべてのトランジット VIF に広報します。オンプレミスのルーターでは、2つのトランジット VIF（VIF-1 および VIF-2）間でアクティブ/パッシブルーティング動作を実現するために、BGP 属性を設定する必要があります。 3.トラフィックフロー VPC とオンプレミス間のトラフィックフローを図 7 に示します。 図 7: シナリオ 1 — AWS とオンプレミス間のトラフィックフロー AWS からオンプレミスへのトラフィックフロー : VPC はトラフィックをローカルリージョン内の CNE に転送します。CNE はトラフィックをローカルの Direct Connect ゲートウェイアタッチメントに送ります。ただし、Direct Connect ゲートウェイがすべてのリージョンに関連付けられていない場合、CNE はランダムにリモートの CNE を選択してトラフィックを転送します。そのため、最適なルーティングを確保するために、アタッチされたセグメントが存在するすべての Cloud WAN リージョンに Direct Connect ゲートウェイを関連付けることを推奨します。Direct Connect ゲートウェイはトラフィックをプライマリトランジット VIF-1 に転送します。 オンプレミスから AWS へのトラフィックフロー : オンプレミスから AWS へのトラフィックは、同じ経路を通って対称的に転送されます。 シナリオ2: 複数のオンプレミス拠点がユニークなプレフィックスを AWS Cloud WAN コアネットワークの Production セグメントに広報する場合 このシナリオでは、複数のオンプレミス拠点が Cloud WAN コアネットワークの Production セグメントに接続されており、それぞれが AWS に対してユニークな IP プレフィックスを広報していることを前提としています。各拠点は独自の IPv4 および IPv6 プレフィックスでアドレス指定されているため、すべてのトランジット VIF と Cloud WAN コアネットワークエッジに対して単一の Direct Connect ゲートウェイが必要です。Direct Connect ゲートウェイは、関連するリージョンからのトラフィック転送において、ユニークな IPv4 および IPv6 プレフィックスの広報を基に適切なオンプレミス拠点を判断します。簡潔さを考慮し、このシナリオでは Direct Connect に高可用性のアーキテクチャを使用せず、Direct Connect の冗長性に関する推奨事項の確認を推奨します。 このアーキテクチャは図8に示されています。この構成は、2つ以上のグローバルに分散したオンプレミス拠点に拡張することが可能です。 図8: シナリオ2 – 各オンプレミス拠点がユニークな IPv4 および IPv6 プレフィックスをコアネットワークの Production セグメントに広報 1.オンプレミスから AWS への経路広報 図9は、オンプレミスの拠点から Production セグメントに広報される IPv4 および IPv6 プレフィックスを示しています。Direct Connect ゲートウェイ Production に Direct Connect アタッチメントを設定し、すべての CNE をこれに関連付けました。これにより、コアネットワーク内のすべての Cloud WAN CNE が、Direct Connect ゲートウェイを介してオンプレミス拠点から広報された BGP 経路を直接学習できるようになります。 図9: シナリオ2 – オンプレミスから AWS への BGP 経路広報 オンプレミスからの経路広報には BGP コミュニティを使用し、各プレフィックスに対する Direct Connect ゲートウェイのプライマリおよびバックアップパスを制御しています。経路は Direct Connect ゲートウェイから AWS Cloud WAN に伝播され、シナリオ1で説明したのと同じ経路伝播メカニズムが適用されます。 2. AWSからオンプレミスへの経路広報 AWS からオンプレミスへの経路広報は、前述のシナリオ1と同様に行われます。すべてのオンプレミス拠点は、コアネットワーク内のすべてのリージョンで Direct Connect ゲートウェイに関連付けられたセグメントから、AWS Cloud WAN のプレフィックスを学習します。 3.トラフィックフロー 図10は、VPC と特定のオンプレミス拠点間のトラフィックフローを示しています。 図 10: シナリオ 2 — AWS とオンプレミス間のトラフィックフロー AWS からオンプレミスへのトラフィックフロー : シナリオ1と同様に、図10では VPC からローカルリージョン内の CNE へトラフィックが流れ、次にローカル Direct Connect アタッチメントを介して Direct Connect ゲートウェイに送信される流れを示しています。Direct Connect ゲートウェイは、特定の広報された経路と BGP コミュニティに基づいて最終的なルーティング決定を行います。この場合、パケットの宛先 IP アドレスに基づき、プライマリトランジット VIF（VIF-1 または VIF-3）を通じて適切なオンプレミス拠点にトラフィックを送信します。 オンプレミスから AWS へのトラフィックフロー : トラフィックは同じパス (VIF-1 または VIF-3 > Direct Connect ゲートウェイ Production > CNE > VPC) をたどって対称的に転送されます。 シナリオ3: 同一プレフィックスを AWS Cloud WAN コアネットワークのハイブリッドセグメントに広報する複数のオンプレミス拠点 前述のシナリオ 2 で示したように、各オンプレミス拠点から特定のプレフィックスを広報することをお勧めします。しかし、複数のオンプレミス拠点から同じ集約プレフィックスを AWS に広報する必要がある場合、複数の Direct Connect ゲートウェイを使用して Cloud WAN のルーティングを制御できます。これにより、Direct Connect ゲートウェイが集約プレフィックスの送信先としてどのオンプレミス拠点を選択するかを制御できます。 このシナリオでは、2つの Direct Connect ゲートウェイを使用して、トラフィックが AWS からオンプレミスの宛先に向かう際、地理的に最も近い AWS Direct Connect のポイントオブプレゼンス（POP）を経由するようにルーティングを行います。2つの Direct Connect ゲートウェイを Hybrid セグメントに接続し、それぞれを特定のルーティング動作を必要とする CNE に関連付けます。図11は、このシナリオのアーキテクチャを示しています。 図11: シナリオ3 – 複数の Direct Connect ゲートウェイをCloud WAN のハイブリッドセグメントに接続し、それぞれを特定の CNE に関連付け 1. オンプレミスから AWS への経路広報 図12は、2つの Direct Connect ゲートウェイを通じてオンプレミスから AWS への経路広報を示しています。両方の Direct Connect ゲートウェイは、オンプレミスから同じ集約プレフィックスを学習し、それを関連付けられた CNE に広報します。各 CNE は関連付けられた Direct Connect ゲートウェイから学習した経路と、コアネットワーク内の他の CNE から AS_PATH がより長い経路を受信します。 図12: シナリオ3 – オンプレミスから AWS への経路広報 2. AWS からオンプレミスへの経路広報 コアネットワークセグメントに接続された Direct Connect ゲートウェイは、関連する CNE が各セグメントのローカルアタッチメントから学習した経路のみをオンプレミスに広報します。このシナリオでは: Direct Connect ゲートウェイ1は、ap-southeast-2 および us-west-2 のコアネットワークリージョン内でコアネットワークの Hybrid セグメントに接続された VPC からの IPv4 および IPv6 プレフィックスのみを、関連付けられたトランジット VIF に広報します。 Direct Connect ゲートウェイ2は、us-east-1 のコアネットワークリージョン内でコアネットワークの Hybrid セグメントに接続された VPC からの IPv4 および IPv6 プレフィックスのみを、関連付けられたトランジット VIF に広報します。 3.トラフィックフロー AWS からオンプレミスへのトラフィックフロー :このシナリオでは、US 西部のオンプレミス拠点に地理的に近い CNE を Direct Connect ゲートウェイ1に関連付け、US 東部のオンプレミス拠点に近い CNE を Direct Connect ゲートウェイ2に設定しました。これにより、集約プレフィックスに対してどのオンプレミス拠点を使用するかを制御できます。CNE は、直接関連付けられた Direct Connect ゲートウェイを経由する最短の AS_PATH を持つ経路を選択します。そのため、CNE はトラフィックを関連付けられた Direct Connect ゲートウェイに転送します。Direct Connect ゲートウェイは、設定された BGP コミュニティタグに基づいて適切なトランジット VIF にトラフィックを送信します。トラフィックがいずれかのオンプレミス拠点に到達すると、オンプレミスネットワーク上で拠点間のルーティングが可能です。 オンプレミスから AWS へのトラフィックフロー :オンプレミス側のルーターでは、それぞれの Direct Connect ゲートウェイに関連付けられたリージョン内のコアネットワークセグメントからの経路を受信します。トランジット VIF 1と2上で、ap-southeast-2 および us-west-2 にローカルな Hybrid セグメントからの経路を受信します。一方、トランジット VIF 3と4上で、us-east-1 にローカルな Hybrid セグメントからの経路を受信します。オンプレミス側のルーターで BGP のベストパス選択アルゴリズムを調整することで、AWS へのトラフィックがプライマリトランジット VIF（1および3）を経由するような対称的なルーティングを実現できます。 移行のベストプラクティス この記事の後半では、AWS Cloud WAN と AWS Direct Connect を Transit Gateway 経由で利用しているアーキテクチャから移行する際に、ダウンタイムを最小限に抑えるための移行戦略を説明します。もし AWS Cloud WAN への移行を検討しているが、現在の AWS リソース（例: VPC）がまだ Transit Gateway に接続されている場合は、「 AWS Cloud WAN and AWS Transit Gateway migration and interoperability patterns 」に関するガイドラインに従うことをお勧めします。このガイドラインは、Transit Gateway を利用した Direct Connect によるハイブリッド接続を維持しつつ、AWS リソースを Transit Gateway から AWS Cloud WAN へ移行するのに役立ちます。その後、以下の手順に従って、Direct Connect を Transit Gateway から AWS Cloud WAN へ移行し、不要になった Transit Gateway を廃止することができます。 以下の移行におけるベストプラクティスを検討することをお勧めします。 Cloud WAN に接続するための新しい Direct Connect ゲートウェイを作成します。 Direct Connect ゲートウェイは無料で利用できます。新しいものを作成することでダウンタイムを最小限に抑え、移行やロールバックの手順を簡素化できます。 新しいトランジット VIF を作成し、新しい Direct Connect ゲートウェイに関連付けます。 これにより、トラフィックに影響を与えずに、既存の経路と新しい経路の広報を制御できます。この段階では、新しい BGP ピアがアクティブであることを確認しますが、まだオンプレミスからの経路を広報しないでください。 新しい Direct Connect ゲートウェイを、それぞれの AWS リージョンの AWS Cloud WAN の各セグメントにアタッチします。 このステップで、オンプレミスルーターは新しい Direct Connect ゲートウェイからコアネットワーク経路を自動的に受信します。これらの新しい経路の AS_PATH (AS_PATH = Direct Connect ゲートウェイ ASN、CNE ASN) は、古い Direct Connect ゲートウェイを経由する既存の経路 (AS_PATH = Direct Connect ゲートウェイ ASN) よりも長くなっています。この新しい Cloud WAN 統合では、Direct Connect ゲートウェイは自身の ASN で上書きする代わりに、AS_PATH 内のすべての ASN を保持します。このステップでは、オンプレミスルーターが AS_PATH の短い既存のトランジット VIF 経由で受信した経路を優先するため、ルーティングパスの変更は発生しません。 オンプレミスルーターが古い VIF と新しい VIF の両方から同じ経路を受信していることを確認します。 これにより、新しい経路設定が正しく構成されていることを確認できます。 新しい VIF 上でオンプレミスからテスト用の経路または一連の経路を広報します。 それらの経路が Cloud WAN で受信されていることを確認します。 新しい VIF 上で、古い VIF と同じオンプレミスのプレフィックスを広報します。同時に、オンプレミスルーターが新しい VIF 経由でトラフィックを優先的にルーティングするように設定します。これは、オンプレミスルーターで BGP ベストパス選択アルゴリズム（例: Local Preference の使用）を制御することで実現できます。 これにより、新しい Direct Connect ゲートウェイおよびトランジット VIF を介して、AWS Cloud WAN とオンプレミス環境間でトラフィックが対称的に流れるようになります。このステップで環境内でルーティングパスの変更が発生します。 これらの手順はすべて、計画されたメンテナンスウィンドウ中に実施することをお勧めします。ただし、既存のトラフィックフローに影響を与えるコアネットワーク内のルーティング変更が発生するのは、最後のステップのみです。ロールバックする場合は、新しい仮想インターフェイス上のオンプレミスから広報している経路を停止し、BGP のベストパス選択アルゴリズムを元に戻して古い VIF を優先するように設定します。これにより、Cloud WAN は Transit Gateway から受信したオンプレミス経路を再び優先するようになります。 知っておくべきこと Direct Connect ゲートウェイは1つの AWS Cloud WAN セグメントにしか関連付けることができません。ただし、同じセグメントに複数の Direct Connect ゲートウェイを関連付けることは可能です。また、異なる Cloud WAN セグメントに複数の Direct Connect ゲートウェイを関連付けることもできます。ただし、同じ Direct Connect ゲートウェイを複数のセグメントに関連付けることはできません。 Direct Connect アタッチメントを使用して Direct Connect ゲートウェイを AWS Cloud WAN セグメントに関連付ける際、Cloud WAN CNE 全体またはその一部を選択できます。シナリオ3で示されているような特定のルーティング要件がない限り、該当セグメントが設定されているすべての CNE にアタッチメントを関連付けることを推奨します。Direct Connect ゲートウェイアタッチメントを CNE の一部にのみ関連付けた場合、Direct Connect ゲートウェイは関連付けられた CNE のローカルアタッチメントからのみ経路を受信します。 Direct Connect BGP コミュニティタグ は Direct Connect ゲートウェイにのみ関連し、Cloud WAN コアネットワークのルーティング決定には影響しません。 Cloud WAN の経路評価アルゴリズムの詳細は こちら です。MED は AS 間を超えて伝播されないローカルな BGP 属性であるため、Direct Connect ゲートウェイは Cloud WAN に広報されるすべての経路で MED をリセットします。 AWS Cloud WAN の新しい Direct Connect アタッチメントでは、許可されたプレフィックスリストを使用する必要なく、経路を双方向に動的に伝播させることができます。ただし、Transit Gateway を Direct Connect ゲートウェイに関連付ける場合には、引き続き許可されたプレフィックスリストの使用が必要です。Direct Connect ゲートウェイを分離されたセグメントにアタッチした場合、VPC の経路はオンプレミスルーターに伝播されず、オンプレミス経路もコアネットワークセグメントには伝播されません。 ドキュメント に記載されている手順に従うことで、複数のアカウントから Direct Connect ゲートウェイを AWS Cloud WAN コアネットワークにアタッチすることができます。 コアネットワークセグメントから Direct Connect ゲートウェイアタッチメントに広報できる経路数、およびオンプレミス環境から Direct Connect 仮想インターフェイス上で広報できる経路数のクォータについては、 AWS Cloud WAN のドキュメント および AWS Direct Connect のドキュメント に詳しく記載されています。 まとめ この投稿では、 AWS Cloud WAN と AWS Direct Connect の統合機能 を活用して、ハイブリッド接続アーキテクチャを構築する方法について解説しました。AWS 上でグローバルなハイブリッドネットワークを設計し、オンプレミス環境と AWS クラウド間のシームレスな接続を可能にするためのベストプラクティスを解説しました。この統合により、中継点に AWS Transit Gateway を使用する必要がなく、グローバルなハイブリッドネットワークの構成においてより柔軟性が得られます。また、AWS Cloud WAN セグメントとオンプレミス環境間で経路を直接広報することで、ルーティング管理を簡素化できます。AWS Cloud WAN に関する詳細は、 ドキュメント をご確認ください。この投稿に関して質問がある場合は、 AWS re:Post で新しいスレッドを開始するか、 AWS サポート にお問い合わせください。 翻訳はテクニカルアカウントマネージャーの米山 京佑が担当しました。原文は こちら です。

このブログは、SAP の Senior Cyber Security Design Specialist である Amos Wendorff と共同で執筆されました。 はじめに: AWS では、お客様がクラウドサービスを安心して利用できるように、堅牢なセキュリティソリューションを提供することにコミットしています。 この記事では、SAP がお客様向けに AWS 上で実行している、安全で規制を遵守した RISE with SAP および SAP BTP (Business Technology Platform) 環境について説明し、AWS サービスを利用したセキュリティ監視およびアラート通知の自動化ソリューションの実装についても説明します。 RISE with SAP は、企業に ERP システムをトランスフォームしクラウドに移行する道筋を提供する包括的なオファリングです。SAP のインテリジェント エンタープライズ ソフトウェア、クラウド インフラストラクチャ、サービスを組み合わせることで、お客様は IT ランドスケープの簡素化、より速いイノベーション、デジタル トランスフォーメーションの推進が可能になります。RISE with SAP を採用することで、お客様は SAP S/4HANA など SAP アプリケーションのパワーを活用しながら、クラウドのスケーラビリティ、セキュリティ、コスト効率の恩恵も得られます。 背景: SAP が RISE with SAP と SAP BTP を急速に導入したことにより、SAP が使用する AWS アカウントの数が指数関数的に増加しました。SAP は現在 33 の AWS リージョンで運用しており、このブログ記事の執筆時点で 7,000 を超える AWS アカウントを管理しながら、新しいリージョンの立ち上げとともに展開地域を拡大しています。 これらの多数のアカウントを手動で監視およびセキュアに維持することは大変な課題となります。そこで SAP は、AWS の強力なセキュリティサービスを活用しながら、お客様のニーズに合わせてスケールできる、セキュアで自動化されたソリューションを必要としていました。 技術的な実装: SAP の Global Security & Cloud Compliance (SGSC) チームは、7,000 を超える AWS アカウントを対象に包括的なセキュリティを確保するため、AWS のサービスとサードパーティ製ツールを組み合わせた堅牢な「セキュアなデフォルト」フレームワークを構築しています。 このアーキテクチャの中核は、 Amazon GuardDuty です。 Amazon GuardDuty は、機械学習、異常検知、脅威インテリジェンスを活用して、AWS 環境における悪意のあるまたは不正な活動を継続的に監視し、リアルタイムの脅威検知を実現します。 すべての Amazon GuardDuty の検出結果とセキュリティログは、 Amazon S3 に集約されます。 Amazon S3 は、 AWS Organization 全体のログの中央リポジトリとして機能します。 このセットアップにより、SAP は膨大なクラウドインフラストラクチャの可視性と管理を維持できます。 大量のデータを処理するために、SAP は Splunk のような先進的な分析と可視化のための宛先へのルーティング前に、ログをフィルタリング、強化、正規化することで Cribl を使用します。これにより、セキュリティチームはデータを効率的に管理し分析して、脅威を迅速に特定し対応できます。さらに SAP は、アカウント所有者とセキュリティ対応者の連絡先情報を含むメタデータを保持する MasterData Cloud Database を維持しています。これにより、セキュリティ問題が検出された際に対象を絞った通知と対応が可能となり、明確な説明責任と迅速な対応能力を維持することが可能になります。 検出と分析に加えて、SAP は特定のセキュリティ上の問題を自動化して修正するための AWS Lambda 関数を利用しています。たとえば、GuardDuty がセキュリティポリシーに違反しているオープンポートを検知した場合、AWS Lambda 関数がトリガーされ、セキュリティグループルールの調整によってその問題を自動的に修正します。この自動化により、手動による介入の必要性を削減し、すべての AWS アカウントにおいてコンプライアンスを確実にします。RISE with SAP や SAP BTP のお客様の環境は SAP が運用しているため、この自動化アーキテクチャにより、クラウドリソースがこれらの厳格なセキュリティコントロールの下で継続的に監視・保護されるため、安心と継続的な運用が可能になります。 SAP のアプローチは、AWS ネイティブのセキュリティ機能を高度なデータ処理ツールと統合することで、AWS 上の SAP アプリケーションのニーズに特化した自動化、スケーラブル、かつセキュアなクラウド環境を実現しています。 セキュリティ制御の概要: SAP の「デフォルトで安全」な管理の対策には、AWS のネイティブなセキュリティ機能を利用して、安全なクラウド環境を確保するさまざまな対策が含まれています。その中には、すべてのアカウントを AWS の組織に組み入れてポリシーを統一的に適用すること、SAP Active Directory との統合、SAP ドメインユーザ以外のアクセスを防止すること、クラウド管理者に対する強制的な多要素認証の実施などがあります。 集中型のログ管理システムは、全アカウントを対象として、API の利用記録やストレージへのアクセス履歴を常時監視しています。これらのログデータは、セキュリティ分析基盤 (SIEM) に自動的に集約され、リアルタイムでセキュリティ監視と分析が行われる仕組みとなっています。このアプローチは、公開リソースや暗号化されていないデータなど一般的なクラウド設定のミスを防止するだけでなく、AWS の組織ガバナンス機能を活用して、特定のポートをブロックする高度なネットワーク管理や、安全な通信のための TLS 1.2 以上を強制するなどの対策を講じています。 デプロイメントリングを使ったフェーズドロールアウト: 新しい予防統制は、4 つのデプロイメントリングでロールアウトされます。 この段階的なアプローチにより、チームがポリシーをテストし、混乱を最小限に抑えることができます。 アカウントの所有者は、デプロイメントリングでのアカウントの配置を選択でき、ポリシーの施行の少なくとも 2 週間前に通知を受けることができます。 SAP は、潜在的な混乱を考慮し、特定の管理対象に対する例外または遅延を検討して、影響を最小限に抑えています。 通知と修復のプロセス: 自動化されたセキュリティ監視は、検出された管理違反の重大度に基づいて通知プロセスをトリガーします。 重大度の高い警告は、AWS Lambda を利用した SAP の自動化プロセスによって自動的に修復されます。 自動アカウントプロビジョニングとセキュリティ標準: SAP の自動アカウント プロビジョニング プロセスにより、新しい AWS アカウントはそのはじめから、予め定義されたセキュリティ標準とベストプラクティスを遵守することが保証されます。 これには、必要な IAM ロール、 AWS セキュリティツール の実装、および SGSC セキュリティポリシーへの準拠が含まれます。 このプロセスでは、高度な自動販売システムがアカウントのライフサイクルを自動的に管理します。セキュリティの第一層は、特定のアクションとリソースをブロックする Service Control Polices (SCP) によって実装されています。Amazon GuardDuty と AWS CloudTrail を使用して、検出メカニズムが導入されています。 Orca Security は、脆弱性、設定ミス、コンプライアンスリスクの自動化されたエージェントレススキャンと修復によって、SAP のクラウドセキュリティポスチャを強化します。 SAP は、SAP AWS 全組織にセキュリティを直接埋め込むことで、ライフサイクルの初期段階でリスクを特定し、軽減するプロアクティブなアプローチを採用しています。この統合により、お客様のワークロードに堅牢なセキュリティ基盤が確保され、攻撃対象領域を最小限に抑え、クラウドネイティブ環境のベストプラクティスに準拠します。 標準的なセキュリティ対策に加えて、SAP は RISE with SAP 環境のアカウントレベルのセキュリティを強化するために、AWS の複数の機能を活用しています: RISE with SAP のバックアップ用の EBS Snapshot Lock: クライアントのデータをより良く保護するため、SAP は Amazon Elastic Block Store (Amazon EBS) Snapshot Lock を採用しました。この機能は、1 日から約 100 年の範囲のロック期間を使用し、新規および既存の Amazon EBS Snapshot をロックします。これにより、保存されたデータが意図せず削除されるのを防ぎ、SAP のエンタープライズカスタマにより安心感を与えています。SAP は Amazon Data Lifecycle Manager を使用して、予め定義されたスケジュールと保持ガイドラインに基づいてスナップショットの作成、保持、削除を自動化します。そして、Amazon EBS Snapshot Lock を使って、これらのバックアップを厳格なコンプライアンス管理下に置きます。この機能のコンプライアンスモードでは、スナップショットが承認されたユーザによっても削除できないことを検証します。最大 72 時間のクーリングオフ期間を経た後は、スナップショットやロックはロック期間が切れるまで削除できず、モードも変更できません。SAP のお客様は、数週間から最大 2 年までの範囲で、スナップショットのロック期間をカスタマイズする選択肢もあります。 RISE with SAP での Bring Your Own Key (BYOK): お客様は、自身の AWS KMS customer master key (CMK) を使用して、RISE with SAP 環境のデータを暗号化することで、セキュリティを強化できます。お客様は同じリージョンで CMK を作成し、RISE with SAP AWS アカウントに権限を付与することで、EFS、データボリューム、バックアップ用の暗号化キーを利用できます。このアプローチでは、データ暗号化に対する制御を高め、キーアクセスの取り消しが可能であり、AWS KMS の 99.999 % の可用性サービスレベル SLA の恩恵を受けながら、暗号化要件を満たすことができます。 RISE with SAP 向け AWS WAF: AWS WAF (Web Application Firewall) は、RISE with SAP 環境の主要なセキュリティコンポーネントであり、Web アプリケーションと API を一般的な Web 攻撃やジオブロッキングによるリソース乱用から自動的に保護します。環境プロビジョニング時の自動デプロイと設定により、お客様の介入なく一貫した保護が確保されます。この設定により、RISE with SAP 環境の全体的なセキュリティポスチャにおいて、エンタープライズグレードの Web アプリケーションセキュリティが提供されます。 RISE with SAP 内の AWS ユーザ向け相互 TLS (mTLS) 検証: 相互 TLS (mTLS) 検証は、RISE with SAP 環境内の AWS のお客様向けの高度なセキュリティ機能です。この機能は、ネットワーク通信に対する認証とセキュリティの追加層を提供し、機密性の高いワークロードやアプリケーションに対するセキュリティ強化を図っています。mTLS の主な利点は、従来の TLS よりも強力な認証によるセキュリティ強化、許可されたクライアントのみがサービスに接続できるようクライアント検証、転送中のデータの機密性と整合性の維持による完全性の確保などです。さらに、mTLS は金融やヘルルスケアなどの業界における厳格な規制要件の遵守に役立ち、関連する基準を満たします。mTLS を導入することで、RISE with SAP のお客様は高度に安全で規制に準拠したクラウド環境の恩恵を受け、アプリケーションやワークロードの全体的なセキュリティポスチャを一層高めることができます。 RISE with SAP 向け SAP BTP Private Link Service: AWS PrivateLink に基づくサービスである SAP BTP Private Link Service は、SAP BTP と RISE with SAP 環境間の安全な プライベートネットワーク接続を確立し、トラフィックを AWS の内部ネットワークを介して送受信することで、パブリックインターネットへの公開を回避しながらも、低レイテンシーで高パフォーマンスな通信を実現します。 自動化ソリューションのメリット: 向上したセキュリティポスチャ: セキュリティ違反のリアルタイム検出と警告により、迅速な対処が可能になり、セキュリティインシデントを防ぐことができます。 スケーラビリティ: 数千の AWS アカウントにわたってセキュリティコントロールをスケーリングし、包括的な対応とセキュリティ保護を実現します。 自動化: セキュリティ監視の自動化により、手動での介入が不要になり、SAP のセキュリティ オペレーションの効率が向上します。 同様のアプローチを実装しようとしている企業にとって、重要な出発点は、クラウドネイティブのマインドセットを持ち、AWS 内蔵のセキュリティ機能を十分に活用することです。これには、AWS Organizations を使用して集中管理のためのアカウントを設定し、セキュリティガードレールとしてサービスコントロールポリシー (SCP) を適用することが含まれます。Amazon GuardDuty を利用した脅威検知、AWS CloudTrail を利用した監査ログ記録、AWS Key Management Service (KMS) を利用した安全な鍵管理など、クラウドネイティブツールを使うことで、組織はゼロトラストアーキテクチャを構築し、攻撃対象領域を大幅に削減し、全体的なセキュリティポスチャを強化することができます。暗号化基準を確保し、パスワードポリシーを施行し、すべてのアクセスポイントで多要素認証を有効にすることは実践すべき手順です。これらのセキュリティベストプラクティスの実装に関する包括的なガイダンスについては、組織は AWS Well-Architected Framework のセキュリティの柱の文書 を参照する必要があります。加えて、AWS Security Services と RISE with SAP の活用に関する具体的なガイダンスは、 AWS Security Considerations for RISE with SAP に記載されています。 結論: AWS の堅牢なセキュリティサービス、自動化機能、組織のポリシーエンジンを活用したクラウドネイティブのセキュリティ戦略を採用することで、SAP の「セキュア バイ デフォルト」ソリューションにより、AWS 上の RISE with SAP、SAP BTP、その他の SAP ソリューションを利用するお客様は、確かなセキュリティ態勢のもと、本来のビジネス目標に専念することができます。このアプローチには、ゼロトラストアーキテクチャ (ZTA) の原則が組み込まれており、ユーザーアクセスの継続的な検証、クラウドリソースの厳格な管理、そして AWS ネイティブツールによるコンプライアンスの徹底が最重要とされています。SAP は、リアルタイムの検知、アラート、自動修復を通じてリスクを最小限に抑えています。これにより、SAP のお客様は、AWS 上の包括的でスケーラブルなセキュリティフレームワークによって機密データとワークロードが確実に保護されているという安心感を持ちながら、クラウド投資の価値を最大限に引き出すことができます。 翻訳は Partner SA 松本が担当しました。原文は こちら です。

本記事は、2024 年 11 月 22 日に公開された “ Build a Travel Planner with React Native, AWS Amplify, and Amazon Bedrock Knowledge Base ” を翻訳したものです。翻訳は Solutions Architect の 吉村 が担当しました。 Amplify AI kit の発表により、 カスタム UI コンポーネント 、 会話の履歴 、 会話の流れに外部データを追加 する方法を学びました。この記事では、React Native を使用してトラベルプランアプリケーションを構築する方法を学びます。このアプリケーションは、 Knowledge Base に基づいて、Retrieval Augmented Generation (RAG) および Large Language Models (LLM) を使用して応答を生成します。 大規模言語モデル (LLM) に最新の独自情報を付与するには、RAG という手法を使用できます。これは、企業のデータソースからデータを取得し、プロンプトを強化することで、より関連性が高く正確な応答を提供できるようになります。Amazon Bedrock Knowledge Bases を使えば、会社のプライベートデータソースから FM とエージェントにコンテキスト情報を提供し、RAG がより関連性があり、正確で、カスタマイズされた応答を提供できます。 この記事のバックエンドの構築、Knowledge Base の作成、RAG の部分は、どのウェブフレームワークでも使用できます。 ただし、このチュートリアルでは React Native でアプリケーションを構築することを想定しており、それに応じてフロントエンドのコードを説明します。 Amplify アプリの構築 Amplify アプリケーションを作成するには、アプリケーションのルートフォルダで create-amplify コマンドを実行する必要があります。 npm create amplify@latest -y これにより、AWS Amplify に対してプロジェクトに必要な依存関係がインストールされます。IDE でプロジェクトを開くと、新しい amplify フォルダが表示されます。 このフォルダには、メール認証付きのシンプルな ToDo アプリケーションが含まれています。関連するカテゴリのリソースは、それぞれ専用のフォルダの下に定義されています。たとえば、認証については auth/resource.ts ファイルを更新します。 ユーザーにパーソナライズされた体験のためのサインアップ認証フローを追加しましょう。まず auth/resource.ts ファイルを開き、次のように更新します。 import { defineAuth } from "@aws-amplify/backend"; export const auth = defineAuth({ loginWith: { email: { verificationEmailSubject: "Welcome to Travel Advisor! Verify your email!", verificationEmailBody: (code) => `Here is your verification code: ${code()}`, verificationEmailStyle: "CODE", }, }, userAttributes: { preferredUsername: { mutable: true, required: true, }, }, }); これにより、ユーザー確認メールがカスタマイズされ、登録時にユーザー名の作成が求められます。次に、Amplify サンドボックスを介して、初期デプロイを行います。個人用のクラウドサンドボックス環境は、フルスタックアプリを迅速に構築、テストしていてレーションを回すことができる、分離された開発スペースを提供します。チームの各開発者は、クラウドリソースに接続された使い捨てのサンドボックス環境を使用できます。それでは最初のデプロイを行いましょう。その前に、 backend.ts を次のように更新してください。 import { defineBackend } from "@aws-amplify/backend"; import { auth } from "./auth/resource"; import { data } from "./data/resource"; /** * @see https://docs.amplify.aws/react/build-a-backend/ to add storage, functions, and more */ defineBackend({ auth, }); データリソースをコメントアウトしておくことで、データリソースをデプロイしないでおくこともできます。次のコマンドを実行して、認証用のサンドボックス環境を起動します。 npx ampx sandbox 次のステップはフロントエンドの実装です。これには、 Amplify UI コンポーネント を使用します。Amplify UI とは、アクセシビリティが高く、テーマ設定が可能で、高パフォーマンスなコンポーネントの集合体で、クラウドに直接接続することができます。わずか数行のコードで、複雑なタスクを些細なタスクに変えることができます。 まず、UI ライブラリを使うために必要なライブラリをインストールします。 npm install --force @aws-amplify/ui-react-native aws-amplify @aws-amplify/react-native react-native-safe-area-context @react-native-community/netinfo @react-native-async-storage/async-storage react-native-get-random-values React Native の最新バージョンと UI ライブラリが競合するため、forceフラグを追加しています。 iOS 向けに Pod をインストールして、ネイティブライブラリにライブラリをバインドします。 npx pod-install 次に、 App.tsx 内の App コンポーネントを次のように更新してください: import outputs from "./amplify_outputs.json"; Amplify.configure(outputs); const SignOutButton = () => { const { signOut } = useAuthenticator(); return ( <TouchableOpacity onPress={signOut}> <MaterialIcons name="exit-to-app" size={32} /> </TouchableOpacity> ); }; export default function App() { const [username, setUsername] = useState(""); useEffect(() => { const fetchUsername = async () => { const attributes = await fetchUserAttributes(); const username = attributes.preferred_username ?? ""; setUsername(username); }; fetchUsername(); }, []); return ( <Authenticator.Provider> <Authenticator> <SafeAreaView style={styles.container}> <KeyboardAvoidingView behavior={"height"} style={styles.container}> <View style={styles.header}> <Text style={styles.headerIcon}>✈</Text> <Text style={styles.headerText}>Travel Advisor</Text> <SignOutButton /> </View> </KeyboardAvoidingView> </SafeAreaView> </Authenticator> </Authenticator.Provider> ); } 以下は主な変更点です。 fetchUserAttributes を介して、定義した追加属性を取得しています。 useAuthenticator フックを使用して、signOut ボタンを呼び出しています。 Authenticator コンポーネントと Authenticator.Provider コンポーネントで、認証用の UI を作成し、認証フローを制御します。 認証フローはテストする準備ができました。次のステップは AI 機能を実装することです。 Amplify の新しい AI 機能により、生成 AI を使いやすくなりました。たとえばコンポーネントを生成する場合は、生成機能を使ってみると、どのようになるかを確認できます。 data/resource.ts ファイルを開き、次のように更新してください: import { type ClientSchema, a, defineData } from "@aws-amplify/backend"; const schema = a.schema({ generateDestination: a .generation({ aiModel: a.ai.model("Claude 3.5 Sonnet"), systemPrompt: ` You are an advanced travel assistant with comprehensive knowledge about global destinations, including their geography, climate patterns, historical significance, tourist attractions, and cost of living. Your task is to analyze the following information: {{input}} Based solely on this input, determine the single best city on Earth for the user. Your response should be concise and definitive, presenting only the chosen city along with comprehensive information about their geography, climate patterns, historical significance, tourist attractions, and cost of living and why it's the ideal match. Do not ask for additional information or clarification. Provide your recommendation based exclusively on the given details. `, }) .arguments({ input: a.string().required(), }) .returns(a.string().required()) .authorization((allow) => [allow.authenticated()]), }); export type Schema = ClientSchema<typeof schema>; export const data = defineData({ schema, authorizationModes: { defaultAuthorizationMode: "userPool", }, }); このおかげで、質問に対する回答を生成できます。 App.tsx ファイルを開き、どこからでも以下のように generateDestination を呼び出せば、目的地を生成できるようになりました。 const { data, errors } = await client.generations.generateDestination({ input: inputText, }); Knowledge Base の作成 (LLM に与える) 情報は、プロンプトの強さに大きく左右されます。また、情報は AI モデルとその特性に関するものです。しかし、Amazon Bedrock Knowledge Base を使えば、プロンプトにさらに情報を与えることができます。 以下のような基本的な Knowledge Base を作成します。 都市 国 人口 説明 金融ハブ 首都？ ランキング 東京 日本 973 万人 東京は日本の首都です。超近代的な高層ビルと歴史的な寺院と庭園が共存しています。独自のポップカルチャー、先進的な技術、そして絶品の料理で知られています。世界最大の魚市場と最も混雑した横断歩道があります。 はい はい 1 イスタンブール トルコ 1,546 万人 イスタンブールはボスポラス海峡に跨っており、ヨーロッパとアジアの境目に位置しています。歴史に富み、ビザンティンとオスマンの建築物が見られます。バザール、ハンマーム、様々な料理で有名です。アヤソフィアとブルーモスクは象徴的な建造物です。 はい いいえ 5 ベルリン ドイツ 370 万人 ベルリンはドイツの首都で、活気ある芸術シーンと現代的な建築物、複雑な歴史で知られています。世界トップクラスの博物館、多様な地区、ベルリンの壁の残骸があります。テクノクラブ、ストリートアート、多文化な料理で有名です。 いいえ はい 2 ニューヨーク アメリカ 880 万人 ニューヨーク市は金融、芸術、文化の世界的ハブです。自由の女神像やエンパイアステートビルなど有名な観光スポットがあります。多様な地区、ブロードウェイの劇場、世界トップクラスの博物館、食の多様性で知られています。植民地時代から現代までの豊かな歴史があります。 はい いいえ 4 プラハ チェコ共和国 130 万人 プラハはチェコ共和国の首都で、「百塔の都市」として知られています。プラハ城やカレル橋など中世の建築物で有名です。ビール文化、クラシック音楽の遺産、よく保存された旧市街広場で名高いです。 いいえ はい 3 Amazon S3 コンソール に移動し、 Create bucket ボタンをクリックします。 バケットに一意の名前を選び、他はデフォルトの選択のままにします。次に、ファイルを S3 バケットにアップロードします。 それでは Knowledge Base を作成しましょう。まず AWS コンソールを開き、 Amazon Bedrock ページへ移動します。ページにアクセスしたら、左側のメニューから Knowledge bases を選択してください。 Create knowledge base ボタンをクリックしてください。すべてのデフォルト値のままにして (S3 が選択されていることを確認) 次へをクリックします。次のページで、S3 バケットからデータソースを選択してください。 データを変換するための埋め込みモデルを選択してください。 お客様に代わって Amazon が Vector Store を作成するか、以前作成したストアを選択して、Bedrock がデータの埋め込みを格納、更新、管理できるようにします。これで Knowledge Base を作成する準備が整いました。 Amazon Bedrock Knowledge Base のデフォルトのセットアップは OpenSearch Serverless で、これは使っていない間もデフォルトのコストがかかります。注意していないと AWS から請求が来るかもしれません。もしこれをテストするだけなら、終了後に必ず OpenSearch Serverless インスタンスをオフにしてください。 既にコンソール上で Knowledge Base をテストし、データが期待通りに動作するかどうかを確認できます。 Knowledge Base をアプリケーションで使用する時が来ました。 作成した Knowledge Base の利用 まず、いくつか片付けをしましょう。 Knowledge Base に対応した会話を作成し、そのデータベースと通信するための AppSync リゾルバーに接続する必要があります。 data/resource.ts ファイルを次のように更新してください。 import { type ClientSchema, a, defineData } from "@aws-amplify/backend"; const schema = a.schema({ chat: a .conversation({ aiModel: a.ai.model("Claude 3 Haiku"), systemPrompt: `You are a helpful assistant.`, tools: [ a.ai.dataTool({ name: "DestinationKnowledgeBase", description: "A knowledge base to be checked about everything related to the cities.", query: a.ref("searchDestination"), }), ], }) .authorization((allow) => allow.owner()), searchDestination: a .query() .arguments({ input: a.string() }) .handler( a.handler.custom({ dataSource: "DestinationKnowledgeBaseDataSource", entry: "./bedrockresolver.js", }) ) .returns(a.string()) .authorization((allow) => [allow.authenticated()]), }); export type Schema = ClientSchema; export const data = defineData({ schema, authorizationModes: { defaultAuthorizationMode: "userPool", }, }); これにより、先ほど作成した Knowledge Base がツールとして conversation に追加されます。description は、LLM が Knowledge Base とやり取りするための説明テキストになります。js リゾルバーを追加するには、bedrockresolver.js というファイルを作成し、次のコードを貼り付けてください。 export function request(ctx) { const { input } = ctx.args; return { resourcePath: "/knowledgebases/<knowledge-base-id>/retrieve", method: "POST", params: { headers: { "Content-Type": "application/json", }, body: JSON.stringify({ retrievalQuery: { text: input, }, }), }, }; } export function response(ctx) { return JSON.stringify(ctx.result.body); } これにより、AppSync を通じて会話のコンテキストに指定した ID の Knowledge Base が取得されます。最後に、 backend.ts ファイルの Lambda からデータソースへのポリシーを更新する必要があります。 import { defineBackend } from "@aws-amplify/backend"; import { auth } from "./auth/resource"; import { data } from "./data/resource"; import * as iam from "aws-cdk-lib/aws-iam"; const backend = defineBackend({ auth, data, }); const KnowledgeBaseDataSource = backend.data.resources.graphqlApi.addHttpDataSource( "DestinationKnowledgeBaseDataSource", "https://bedrock-agent-runtime.<region>.amazonaws.com", { authorizationConfig: { signingRegion: "<region>", signingServiceName: "bedrock", }, } ); KnowledgeBaseDataSource.grantPrincipal.addToPrincipalPolicy( new iam.PolicyStatement({ resources: [ "arn:aws:bedrock:<region>:<user-id>:knowledge-base/<knowledge-base-id>", ], actions: ["bedrock:Retrieve"], }) ); 最後に、UI を次のように更新してストリーミングを処理します。 import React, { useEffect, useState } from "react"; import { StyleSheet, Text, View, TextInput, TouchableOpacity, SafeAreaView, KeyboardAvoidingView, FlatList, ActivityIndicator, } from "react-native"; import MaterialIcons from "@expo/vector-icons/MaterialIcons"; import { Authenticator, useAuthenticator } from "@aws-amplify/ui-react-native"; import { fetchUserAttributes } from "aws-amplify/auth"; import { Amplify } from "aws-amplify"; import { Schema } from "./amplify/data/resource"; import { generateClient } from "aws-amplify/data"; import outputs from "./amplify_outputs.json"; import { createAIHooks } from "@aws-amplify/ui-react-ai"; Amplify.configure(outputs); const client = generateClient<Schema>(); const { useAIConversation } = createAIHooks(client); const HomePage = () => { const [username, setUsername] = useState(""); const [inputText, setInputText] = useState(""); const [ { data: { messages }, isLoading, }, handleSendMessage, ] = useAIConversation("chat"); const handleSend = () => { handleSendMessage({ content: [{ text: inputText }], }); setInputText(""); }; useEffect(() => { const fetchUsername = async () => { const attributes = await fetchUserAttributes(); const fetchedUsername = attributes.preferred_username ?? ""; setUsername(fetchedUsername); }; fetchUsername(); }, []); return ( <SafeAreaView style={styles.container}> <KeyboardAvoidingView behavior={"height"} style={styles.container}> <View style={styles.header}> <Text style={styles.headerIcon}>✈</Text> <Text style={styles.headerText}>Travel Advisor</Text> <TouchableOpacity onPress={() => { const { signOut } = useAuthenticator(); signOut(); }} > <MaterialIcons name="exit-to-app" size={32} /> </TouchableOpacity> </View> <FlatList data={messages} keyExtractor={(message) => message.id} renderItem={({ item }) => item.content .map((content) => content.text) .join("") .trim().length == 0 ? ( <View style={styles.loadingContainer}> <ActivityIndicator /> </View> ) : ( <ChatMessage text={item.content .map((content) => content.text) .join("") .trim()} isUser={item.role == "user"} userName={item.role == "user" ? username : "Travel Advisor"} /> ) } contentContainerStyle={styles.chatContainer} ListEmptyComponent={() => ( <View style={styles.emptyContainer}> <Text style={styles.emptyText}> Start a conversation by sending a message below! </Text> </View> )} /> <View style={styles.inputContainer}> <TextInput style={styles.input} value={inputText} onChangeText={setInputText} placeholder="Describe your dream travel..." multiline={true} numberOfLines={3} /> <TouchableOpacity style={[styles.sendButton, isLoading && styles.sendButtonDisabled]} onPress={handleSend} disabled={isLoading} > <Text style={styles.sendButtonText}>Send</Text> </TouchableOpacity> </View> </KeyboardAvoidingView> </SafeAreaView> ); }; interface Message { text: string; isUser: boolean; userName: string; } const ChatMessage = ({ text, isUser, userName }: Message) => ( <View> <View style={[ styles.messageBubble, isUser ? styles.userMessage : styles.aiMessage, ]} > <Text style={styles.messageText}>{text}</Text> </View> <Text style={[styles.nameText, isUser ? styles.userName : styles.aiName]}> {userName} </Text> </View> ); export default function App() { return ( <Authenticator.Provider> <Authenticator> <HomePage /> </Authenticator> </Authenticator.Provider> ); } const styles = StyleSheet.create({ container: { flex: 1, backgroundColor: "#FFFFFF", }, header: { flexDirection: "row", alignItems: "center", padding: 15, borderBottomWidth: 1, borderBottomColor: "#E0E0E0", }, headerIcon: { fontSize: 24, marginRight: 10, }, headerText: { fontSize: 20, fontWeight: "bold", flex: 1, }, signOutIcon: { fontSize: 24, }, chatContainer: { padding: 10, }, messageBubble: { maxWidth: "80%", padding: 10, borderRadius: 20, marginBottom: 5, }, aiMessage: { alignSelf: "flex-start", backgroundColor: "#F0F0F0", }, userMessage: { alignSelf: "flex-end", backgroundColor: "#DCF8C6", }, messageText: { fontSize: 16, }, nameText: { fontSize: 12, marginBottom: 10, }, userName: { alignSelf: "flex-end", color: "#4CAF50", }, aiName: { alignSelf: "flex-start", color: "#666666", }, inputContainer: { flexDirection: "row", padding: 10, borderTopWidth: 1, borderTopColor: "#E0E0E0", }, input: { flex: 1, backgroundColor: "#F0F0F0", borderRadius: 20, paddingHorizontal: 15, paddingVertical: 10, fontSize: 16, }, sendButton: { backgroundColor: "#4CAF50", paddingHorizontal: 12, borderRadius: 20, justifyContent: "center", alignItems: "center", marginLeft: 10, }, sendButtonDisabled: { backgroundColor: "#A5D6A7", }, sendButtonText: { color: "#FFFFFF", fontSize: 24, }, loadingContainer: { alignSelf: "flex-start", marginBottom: 10, }, loadingText: { fontSize: 24, color: "#666666", }, emptyContainer: { flex: 1, justifyContent: "center", alignItems: "center", height: 500, }, emptyText: { fontSize: 16, color: "#666666", textAlign: "center", }, }); 上記のコードで最も重要な部分は以下の通りです。 const { useAIConversation } = createAIHooks(client); 会話情報を取得し、メッセージを受信・送信するための React フックを作成します const [ { data: { messages }, isLoading, }, handleSendMessage, ] = useAIConversation("chat"); メッセージを受信し、メッセージを送信します 全体として、このアプリは取得した情報をリアルタイムに取得して、画面に表示します。 サンドボックスを再デプロイすると、アプリケーションが提供された情報を使用して Knowledge Base を呼び出すことがわかります。それではアプリケーションを実行して、その様子を確認しましょう。 クリーンアップ このブログ記事では、Amazon Bedrock Knowledge Base を通して LLM を呼び出す方法を学びました。最後に、次のコマンドを実行して Amplify サンドボックス内のリソースを削除することを忘れずに行ってください。 npx ampx sandbox delete -y また、ベクトルデータベースは高価な場合があるので、アプリケーションのテストが終わったら、必ず Amazon OpenSearch Serverless ダッシュボードからインスタンスを削除してください。 おわりに このブログ記事では、 Knowledge Base の作成方法とアプリケーションでの利用方法を学びました。さらに詳しく知りたい場合は、 AI 入門ガイド をご覧ください。Amplify AI kit の使い方について詳しく説明しています。

2024 年 11 月 29 日、私たちはフルスタックの開発者が会話型検索やチャット、要約などの AI 機能を備えたウェブアプリを構築する最も早い方法である、AWS Amplify AI Kit の一般提供を開始しました。Amplify AI Kit を使えば、クラウドアーキテクチャや機械学習の経験がなくても、フルスタックの生成 AI 機能を構築することができます。リソースのプロビジョニングやセキュアなフロントエンドへのアクセスを心配する必要はなく、すべてがサーバーレスなので迅速なイテレーションが可能で、使った分だけの料金を支払えば済みます。 AWS Amplify では TypeScript を全面採用しており、 Amplify Gen 2 の場合、アプリのクラウドバックエンドのすべての部分が TypeScript で定義されています。認証バックエンド、データバックエンド、ストレージバックエンド、生成 AI 、これら全てを TypeScript で定義することができるのです。 このブログでは、Amplify AI Kit の中身とそれが Amplify および Amazon Bedrock を使って安全なフルスタック AI アプリケーションを構築する作業をどのように簡素化するかについて説明します。すぐに始めたい場合は、 入門ガイド または サンプルリポジトリ をご覧ください。 セットアップ ローカル開発用に セットアップ済みの AWS アカウント が必要で、使用したい Amazon Bedrock の基盤モデルにアクセスできる権限が必要です。 Amazon Bedrock コンソール に移動してアクセス権を要求できます。 フロントエンドのプロジェクトがセットアップされていない場合は、Next.js または Vite を使ってセットアップできます。その後、プロジェクトディレクトリ内で create amplify スクリプトを実行してください。 npm create amplify@latest 次のコマンドを実行すると、TypeScript で書かれたバックエンド定義が含まれる amplify フォルダが作成されます。 npx ampx sandbox これにより、Amplify サンドボックスが起動し、実際の AWS リソースを使ってテストできるクラウド サンドボックス環境が用意されます。 AI 機能の追加 Amplify AI Kit に AI 機能を追加するには、データモデルやカスタムクエリと同様に、Amplify データスキーマに AI ルートを定義します。AI ルートは、バックエンドの AI 機能と対話するための API エンドポイントのようなものです。現在、AI ルートには 2 種類あります。 Conversation: Conversation ルートはリアルタイム、マルチターンの API です。会話とメッセージは自動的に DynamoDB に保存され、応答がリアルタイムにクライアントにストリーミングされます。チャットベースの AI エクスペリエンスや会話型 UI などがこれにあたります。 Generation: シンプルなリクエスト・レスポンス API です。Generation ルートは、定義に従って構造化データを生成する AWS AppSync クエリです。一般的な用途は、非構造化入力から構造化データを生成したり、要約することです。 Amplify のデータリソース定義では、スキーマ定義内で AI ルートを定義できます: import { a, defineData, type ClientSchema } from '@aws-amplify/backend'; const schema = a.schema({ // This will add a new conversation route to your Amplify Data backend. chat: a.conversation({ aiModel: a.ai.model('Claude 3 Haiku'), systemPrompt: 'You are a helpful assistant', }) .authorization((allow) => allow.owner()), // This adds a new generation route to your Amplify Data backend. generateRecipe: a.generation({ aiModel: a.ai.model('Claude 3 Haiku'), systemPrompt: 'You are a helpful assistant that generates recipes.', }) .arguments({ description: a.string(), }) .returns( a.customType({ name: a.string(), ingredients: a.string().array(), instructions: a.string(), }) ) .authorization((allow) => allow.authenticated()), }); export type Schema = ClientSchema; export const data = defineData({ schema, authorizationModes: { defaultAuthorizationMode: "userPool", }, }); ここでは、2 つの AI ルートを作成しています。1 つは ‘chat’ という名前の Conversation ルート、もう 1 つは ‘generateRecipe’ という名前の Generation ルートです。コードを 1 ステップずつ見ていきましょう。 chat: a.conversation({ ここでは新しい「chat」という Conversation ルートを作成しています。ルートの名前は任意に付けられ、定義できる AI ルートの数の制限は、AWS AppSync スキーマのサイズの制限のみです。 aiModel: a.ai.model('Claude 3.5 Sonnet'), 次に、使用したい大規模言語モデル (LLM) を定義します。Amplify AI Kit は、ツール使用とストリーミングをサポートする Bedrock の任意の LLM をサポートしています。ここでは、Anthropic の Claude 3.5 Sonnet モデルを使用しています。 systemPrompt: 'You are a helpful assistant', システムプロンプトは、LLM に対して、その役割と応答の仕方を指示します。 .authorization((allow) => allow.owner()), Amplify Data には組み込みの認証方式があります。Conversation ルートの場合、特定の会話の所有者のみがアクセスできるようにしたいと思います。つまり、ユーザーは他のユーザーの会話履歴にアクセスできません。 generateRecipe: a.generation({ ここでは、generateRecipe と呼ばれる Generation ルートを作成しています。Generation は、入力に基づいて特定の型のデータを生成したい場合に使用する同期リクエスト/レスポンス API です。 .arguments({ description: a.string(), }) これにより、クライアントがレスポンスを受け取るためにどのような入力型を送る必要があるかを定義します。 .returns( a.customType({ name: a.string(), ingredients: a.string().array(), instructions: a.string(), }) ) これが生成したいデータの出力形式です。 Conversation と Generation のルートが定義できたので、Amplify クライアントライブラリで接続できます。 リアルタイム更新機能付きの型安全クライアント Amplify では、フルスタックアプリケーションのコードベースの中にある amplify フォルダにバックエンドリソースを定義します。これによって、データスキーマとフロントエンドクライアントが型を共有できるので、データスキーマと常に同期する型安全なクライアントを手に入れることができます。 import { generateClient } from "aws-amplify/api"; import type { Schema } from "../amplify/data/resource"; const client = generateClient(); // new generations / conversations namespace client.generations.generateRecipe({ }); // type-safe based on schema client.conversations.chat.create(); Amplify AI Kit には、React フックも含まれているので、ネットワーク要求や UI の状態を管理する心配はいりません。UI にフックするだけで、リアルタイム、セキュア、永続的な生成 AI との会話を利用できます。 import { generateClient } from "aws-amplify/api"; import { Schema } from "../amplify/data/resource"; import { createAIHooks } from "@aws-amplify/ui-react-ai"; const client = generateClient(); const { useAIGeneration, useAIConversation } = createAIHooks(client); function Chat() { const [ { data: { messages }, isLoading, hasError, }, sendMessage, ] = useAIConversation('chat'); //... } function RecipeGenerator() { const [ { data, isLoading }, handleGenerate] = useAIGeneration('generateRecipe'); //... } 生成 AI をデータとして活用 データに適切なアクセスができることは、意味のある生成 AI 機能を構築するために重要であり、私たちはデータを LLM に接続することをできるだけ簡単にしたいと考えました。Amplify では、データモデルを厳密に型付けされたスキーマで定義し、生成 AI 機能を追加することは、データモデルやカスタムクエリを追加するのと同じくらい簡単です。TypeScript でデータモデルとクエリの形状を定義しているため、Amplify AI Kit は、Bedrock の LLM がアクセスできるデータとそのアクセス方法を正確に知ることができるように、必要な部分をフックアップします。さらに、データスキーマで定義されたアクセス制御により、LLM はエンドユーザーがアクセスできるデータにのみアクセスできます。すべてのデータリクエストは、クライアントからのリクエストでも LLM からのデータリクエストでも、AWS AppSync を経由します。 「Post」というデータモデルを持つアプリケーションがあると仮定します。このデータにアクセスするには、Conversation ルートにツールを使用します。 import { a, defineData, type ClientSchema } from '@aws-amplify/backend'; const schema = a.schema({ Post: a.model({ title: a.string(), body: a.string() }) .authorization((allow) => allow.owner()), chat: a.conversation({ aiModel: a.ai.model('Claude 3 Haiku'), systemPrompt: 'You are a helpful assistant', // This allows the LLM to query for your data tools: [ a.ai.dataTool({ name: 'PostQuery', description: 'Searches for Post records', model: a.ref('Post'), modelOperation: 'list', }), ] }) .authorization((allow) => allow.owner()), //... }); このコードを分解しましょう。 tools: [ ツールは、LLM がデータを照会し、アクションを実行する手段です。Amplify AI Kit は、LLM へのリクエストでインプットを記述し、ツールの呼び出しと LLM への結果の送信を処理します。 a.ai.dataTool({ name: 'PostQuery', description: 'Searches for Post records', model: a.ref('Post'), modelOperation: 'list', }), LLM にスキーマで定義したデータモデルへのアクセスを提供できます。これにより、LLM はデータモデルの属性に基づいてレコードを照会できます。さらに所有者ベースの承認では、LLM はユーザーが作成したレコードにのみアクセスできます。LLM に カスタムクエリ の呼び出しも許可できます! サーバーレス AI アーキテクチャ Amplify AI スタックはフルマネージドのサーバーレスです。すばやくスピンアップでき、 Amplify サンドボックス を使えば、バックエンドのコードを反復しながら更新を実際のクラウド環境で確認できます。Amplify のサンドボックスを使うと、クラウドリソースにローカル開発環境を作れます。機能開発時にフロントエンドとバックエンドを同時に更新できるので、開発の分断なくエンドツーエンドの機能構築ができます。デプロイする準備ができたら、Amplify Hosting にブランチをプッシュすると、バックエンドとフロントエンドが同時にデプロイされます。 Amplify AI kit architecture AWS AppSync API: クライアントと安全にリアルタイム接続するための AI ゲートウェイ。AppSync API はハブとして機能し、すべてのデータリクエスト (クライアントまたは LLM からのリクエスト) が AppSync を通過します。 Lambda 関数: AppSync と Amazon Bedrock の間の橋渡し役。会話履歴を取得し、Bedrock のストリーミング会話 API を呼び出し、AppSync クエリに基づきツールの呼び出しをハンドリングします。 DynamoDB: 特定のアプリケーションユーザーに対する会話履歴とメッセージデータを保存します。 Generative UI の紹介 Amplify AI Kit でもう 1 つ行いたかったことは、生成 UI を構築することを簡単にすることでした。AI アシスタントが、テキストのみならず、カスタム UI コンポーネントで応答できるようにすることです。これにより、より豊かな体験が可能になり、会話型検索などの構築が可能になります。 Amplify AI Kit には、 <AIConversation /> React コンポーネントと useAIConversation React フックが用意されており、カスタマイズ可能なインターフェースを AI ルートで簡単に構築できます。このコンポーネントには、AI アシスタントが応答可能な responseComponents (コードで定義した React コンポーネント) を指定できます。コンポーネントの説明と props を定義すれば、Amplify AI Kit が残りの処理を行います。 function Chat() { const [ { data: { messages }, isLoading, }, sendMessage, ] = useAIConversation('chat'); return ( { return { city }; }, props: { city: { type: 'string', required: true, }, }, }, }} /> ); } 本番環境への移行 本番環境に移行する準備ができたら、Amplify コンソールで Git リポジトリを追加できます。ブランチにコードを push すると、フルスタックアプリケーション用の完全な継続的デプロイメントパイプラインが実行されます。アプリケーションが公開されると、アプリケーション内で会話データを確認できます。 クリーンアップ Amplify サンドボックスコマンドは ctrl + c で終了できます。その後、 npx ampx sandbox delete コマンドでクラウドサンドボックスリソースを削除できます。 まとめ 私たちは、Amplify AI Kit でみなさんが何を構築するのか非常に楽しみにしており、みなさんからのフィードバックを心待ちにしています。この 1 週間、毎日新しい記事を投稿し、Amplify AI Kit の異なる機能を紹介していきます。Amplify AI Kit の使用開始方法の詳細については、 docs.amplify.aws/ai をご覧ください。 問題がある場合は、 GitHub リポジトリ でお問い合わせいただくか、私たちのコミュニティ Discord で質問してください。 本記事は「 Build fullstack AI apps in minutes with the new Amplify AI Kit 」を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

フロントエンドの開発者は、アプリで永続的な会話型 AI チャット体験を開発するとき、しばしば複雑な API、複雑なリアルタイム UI の更新、設定が難しいアクセス許可を扱う必要があります。それに加えて、複雑なクラウド インフラストラクチャをセットアップしなければなりません。そういった理由から、私たちは AWS Amplify AI Kit とその会話型チャット体験をご紹介できて、大変嬉しいです。 わずか数行のコードで、TypeScript を使って会話型チャットを自分のフロントエンドアプリケーションに追加することができます。複雑なクラウド設定や追加の権限は必要ありません。作成したチャットには、さまざまな Amazon Bedrock モデルの 1 つを接続できます。それぞれのチャットに対して、お客様のユーザーアカウントに関連付けられた永続的な会話履歴が保持されます。また、アプリケーションのニーズに合わせてチャット体験をカスタマイズすることができます。 この機能は、バックエンドにルーティングする新しい conversation API によって動作します。Amazon Bedrock で動作する大規模言語モデル (LLM) を指定したり、お客様のニーズに合わせてカスタマイズしたシステムプロンプトを作成したりするオプションが用意されています。オプションとして、Amplify はツールの使用に対応しており、外部データや機能と対話して、必要に応じて正確に応答できるようになっています。 フロントエンドの Amplify では、 AIConversation コンポーネントと useAIConversation React フックを提供する新しい UI ライブラリがリリースされました。これらの API は、最小限の構成で React アプリケーションにドロップインすると、お客様が対話を開始できるチャット ウィンドウを表示できます。そのうえで、アプリケーションのルックアンドフィールに合わせてカスタマイズを行うこともできます。たとえば、アバター、表示テキスト、添付ファイルの許可、特定のレスポンス用コンポーネントの作成などができます。 このチュートリアルでは、アプリケーションに会話ルートを追加し、カスタマイズする方法を説明します。 前提条件 以下の手順を始める前に、アプリケーション内で AWS Amplify Gen 2 をセットアップする必要があります。これはアプリケーションのルートで create コマンドを実行するだけで簡単に行えます。 npm create amplify@latest これにより、プロジェクトのルートに新しい amplify フォルダが作成され、そこでバックエンドリソースを定義することができます。続行する前に、使用したい Amazon Bedrock モデル を有効にしてください。このチュートリアルでは、Claude 3 Haiku を使用します。さらに、必要に応じて、 ローカル開発用に AWS を設定する ことで、 クラウドサンドボックス環境 でローカルでテストができるようになります。 まだ Amplify AI Kit についてご覧になられていない方は 発表時のブログ記事 をご覧ください。この記事で紹介された機能のすべての使用例と、その他の例を見たい方は、 Amplify AI サンプルリポジトリ をご覧ください。 Conversation ルートの追加 Amplify AI Kit は、Amplify Data の規約に基づいています。この規約に従うことで、シンプルな TypeScript 対応の構文を使って、任意のデータソースに接続するためのデータモデルを作成できます。今回は、 data/resource.ts ファイルのスキーマ定義にある新しい a.conversation API を使用して、チャット会話のルートを構築します。 まず初めに、データリソースファイルに追加し、 chat という新しい会話を作成しましょう。 // data/resource.ts import { type ClientSchema, a, defineData } from "@aws-amplify/backend"; const schema = a.schema({ chat: a.conversation({ aiModel: a.ai.model("Claude 3 Haiku"), systemPrompt: "You are a travel advisor app. You help travelers find locations.", }).authorization(allow => allow.owner()), }); export type Schema = ClientSchema<typeof schema>; export const data = defineData({ schema, authorizationModes: { defaultAuthorizationMode: "userPool", }, }); Conversation API を利用するユーザーは認証が必要です。これはデフォルトで変更できません。慣例として、AWS Amplify Gen 2 を設定する際には、 auth カテゴリ を介して Amazon Cognito User Pool が作成されます。自分でテストする場合は、フロントエンドを Authenticator コンポーネントでセットアップすることをお勧めします。このコンポーネントは Amplify auth カテゴリを利用し、数行のコードでサインイン/サインアウトの UI を提供します。 チャットをセットアップする上で最も重要な部分の 1 つは、 aiModel と systemPrompt を定義することです。 aiModel には Claude 3 Haiku を選択しました。これは最新の Anthropic Claude 3 モデルの 1 つで、ユーザーからの質問に対応するための LLM として機能します。Claude 3 Opus、Claude 3 Haiku、Cohere、LLama、Mistral など、選択可能な複数のモデルがローンチ時に提供されています。 システムプロンプトは、LLM に期待する動作を定義します。この記事では、プロンプトをシンプルにしていますが、使用ケースによっては、より簡潔なプロンプトを試してみる価値があるかもしれません。Few-Shot プロンプティングなどの他の プロンプト 戦略を検討することで、より良い結果が得られる可能性があります。 オプションで、モデルの token 、 temperature 、 top P を設定するための inferenceConfiguration を追加できます。別のオプションとしてツールを追加することができます。ツールの利用は、関数呼び出しとも呼ばれ、対応するモデルが外部の関数やデータと対話できるようにします。たとえば、Amazon Bedrock Knowledge Base で検索拡張生成 (RAG) を使用したい場合は、カスタムリゾルバーでリソースファイルに追加することができます。このような例については、今後の記事でご紹介します。 ルートにある amplify フォルダ内の backend.ts ファイルは、この Conversation API を追加するための他の追加設定は必要ありません。新規プロジェクトから開始する場合、 data が defineBackend 関数呼び出しにインポートされます。さらなる IAM ポリシーの更新は必要ありません。裏側では、AWS AppSync リゾルバを構築し、Amazon Bedrock と直接やり取りする AWS Lambda 関数を作成するための AWS Cloud Development Kit (CDK) コードが生成されます。Amplify は必要な IAM ポリシーも作成し、ユーザーアカウントごとに会話履歴を永続化するための Amazon DynamoDB のデータソースを設定します。 ローカルでのクラウドサンドボックステスト 同じようにコードを実行したい場合は、アプリケーションのルートで npx ampx sandbox コマンドを実行してローカルでテストできます。このコマンドは amplify フォルダを読み込み、テスト環境としてクラウドリソースをプロビジョニングします。 フロントエンドの更新 バックエンドの定義が完了したので、次にフロントエンドのコードを追加します。Vite または Next.js で React アプリケーションを使用していると仮定します。 npm i @aws-amplify/ui-react-ai この ライブラリには、Amplify の新しい AI コンポーネントを使用するために必要なすべてが含まれています。 新しい Chat.tsx コンポーネントを作成し、次のコードを追加してください。 import { Avatar, View } from "@aws-amplify/ui-react"; ... <AIConversation messages={messages} handleSendMessage={sendMessage} avatars={{ user: { avatar: <Avatar src="erik.jpg" />, username: "Erik", }, ai: { avatar: <Avatar src="robot.jpg" />, username: "🤖", }, }} /> この新しいコンポーネントをアプリのエントリポイントファイルに追加します。テストする際は、ユーザーがすでにサインインしていることを確認してください。また、アプリケーションを Authenticator コンポーネントでラップすることをお勧めします。これにより、ユーザーがチャットにアクセスする前にサインインしてアカウントを作成する必要があります。 メインエントリをロードすると、使用可能なシンプルなチャットインターフェースが表示されます。 複数のチャット会話を追加する方法が気になるところでしょう。 useAIConversation フックを詳しく見て、オプションの id を追加しましょう。 const [ { data: { messages }, isLoading, }, sendMessage, ] = useAIConversation("chat", { id: "123" }); デフォルトでは、ユーザーは 1 つのチャットのみ持っています。 id を追加することで、その ID に基づいて、ユーザーごとに複数の個別のチャットを作成できます。各チャットは、システムにログインしているユーザーに紐付けられます。いつでも generateClient API を使用して、会話を取得、削除、あるいは更新できます。設定方法の完全な例については、 Amplify AI Examples リポジトリをご覧ください。 チャット体験のカスタマイズ AIConversation コンポーネントには、ユーザーへのチャット体験をカスタマイズするためのいくつかのプロパティがあります。ユーザー体験を向上させるためのいくつかのカスタマイズを見てみましょう。 アバターの更新 会話型チャットでは、ユーザーのアバターを表示することをしばしば求められますが、 avatars を設定することで設定できます。 import { Avatar, View } from "@aws-amplify/ui-react"; ... <AIConversation messages={messages} handleSendMessage={sendMessage} avatars={{ user: { avatar: <Avatar src="erik.jpg" />, username: "Erik", }, ai: { avatar: <Avatar src="robot.jpg" />, username: "🤖", }, }} /> avatars は user と ai オブジェクトを取ります。チャットでそれぞれに表示されるアバターとユーザー名を定義できます。この例では、 @aws-amplify/ui-react ライブラリからの Avatar コンポーネントを使用して画像を表示しています。AI に関しては、名前を絵文字に変え、新しいアバターを指定しています。 レスポンスコンポーネント response component を使うと、開発者は LLM から返された応答メッセージに基づいてカスタム応答を作成できます。アプリ開発者はコンポーネントを作成し、 responseComponents プロップに追加することで、これらのメッセージの出力を定義できます。たとえば、ユーザが休暇地についての情報を求めた場合、チャットはカスタムの場所カードに名前と説明を表示できます。 以下のコードでは、ユーザー向けのカードを作成するために LocationCard コンポーネントが使用されています。 import { LocationCard } from './LocationCard.tsx'; ... <AIConversation messages={messages} handleSendMessage={sendMessage} responseComponents={{ LocationCard: { description: "Used to display a location to the user", component: LocationCard, props: { name: { type: "string", description: "The name of the location", }, description: { type: "string", description: "The description of the location", }, }, }, }} /> この例では、地名と説明を整えられたカードに表示しています。 responseComponents プロパティは、ツールを介して会話ルートに接続された外部 API でも動作します。 添付ファイルの許可 必要に応じて、チャットウィンドウ内に直接ファイルを添付できます。この機能を有効にするには、ファイルを受け付ける LLM を使用する必要があります。この機能を有効にするには、 allowAttachments を追加してください。 <AIConversation messages={messages} handleSendMessage={sendMessage} allowAttachments /> この allowAttachments を追加すると、チャットウィンドウの下部にファイルを添付するボタンが表示されるようになります。 アップロードした全ての画像は Amazon DynamoDB に保存されますので、ご注意ください。上限は 400KB なので、400KB 以下の画像のみ追加できます。画像を添付したら、その画像に関する質問をし、LLM による回答を得ることができます。 メッセージレンダラ message renderer プロパティはテキスト出力のフォーマットを指定します。たとえば、出力を Markdown で表示したい場合を想像してください。ほとんどの LLM がマークダウンをサポートしているので、会話のメッセージでマークダウンを利用できると便利です。これは、 react-markdown ライブラリをインストールし、 ReactMarkdown コンポーネントを使用して、全ての出力を適切にフォーマットできます。 import ReactMarkdown from "react-markdown"; ... <AIConversation messages={messages} handleSendMessage={sendMessage} messageRenderer={{ text: ({ text }) => <ReactMarkdown>{text}</ReactMarkdown>, }} /> react-markdown を rehypeHighlight のような他のプラグインと組み合わせると、追加のコードハイライト機能が使えます。 これは、 messageRenderer でコードのテキストを表示するために、 rehypeHighlight プラグインを使用しているチャットの例です。 クリーンアップ サンドボックスを実行中の場合は、次のコマンドをターミナルで実行すると、サンドボックスとそれに作成された全てのバックエンドインフラストラクチャを削除できます。 npx ampx sandbox delete 次のステップ この記事では、Amplify AI Kit を使用してアプリケーションにセキュアな会話型チャットを追加する方法を見てきました。ユーザー向けにカスタムチャット体験を作成するために、新しい Amplify AI UI ライブラリを追加するのがいかに簡単かを確認しました。さらに、レスポンスコンポーネント、アバター、メッセージレンダラを使用してユーザー体験をさらに向上させることができることも確認しました。 詳しく学びたい方は、 AI のスタートガイド をご覧ください。Amplify AI Kit の使い方を詳しく説明しています。また Discord チャンネル に参加して、直接質問することもできます。 本記事は「 Create a Customized AI-Based Chat Interface With Your Application Data 」を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

AWS Amplify Hosting は、開発者が Web アプリケーションを保護し、さらにセキュリティを強化できる新しいファイアウォール機能を発表しました。これは AWS WAF との直接統合であり、開発者は Amplify Hosting にホストされたアプリケーションに Web ACL を直接 追加することができます。Web アプリケーションファイアウォールは、一般的な Web 攻撃からアプリケーションを保護し、セキュリティを強化し、コンプライアンスを確保するためには必要不可欠です。IP の許可/ブロック、地理的制限、Bot からの保護などの機能があります。WAF を提供することで、Amplify のお客様はアプリケーションのセキュリティ保護を大幅に向上させ、リスクを軽減し、データとユーザーエクスペリエンスの完全性を維持できます。 AWS WAF は、Webアクセスコントロールリスト（Web ACL）と呼ばれる一連のルールを設定できるサービスであり、お客様が定義したカスタマイズ可能な Web セキュリティルールと条件に基づいて、Web リクエストを許可、ブロック、または監視（カウント）することができます。Amplify Hosting と AWS WAF を統合することで、トラフィックをさらに制御できるようになります。AWS WAF の詳細については、開発者ガイドの AWS WAF の動作方法 をご覧ください。 AWS WAF を初めて利用する場合でも Amplify Hosting では開発者が簡単に設定できるようになっています。 IP アドレス 許可/ブロック – 指定の IP アドレス範囲からのリクエストを許可または拒否することで、Web トラフィックを制限します 地理的制限 – 特定の国からのアクセスを許可または拒否します ファイアウォール保護 – Web アプリケーションで最も一般的に見られる脆弱性から保護するための一般的なファイアウォール保護、Amazon の内部の脅威インテリジェンスに基づく潜在的な脅威からの IP アドレスブロック、および悪意のあるアクターがアプリケーションの脆弱性を発見するのを防ぐ保護 Amplify URL の無効化 – デフォルトの Amplify で生成された amplifyapp.com ドメインへのアクセスを制限します (カスタムドメインを追加した後、Bot と検索エンジンがそのドメインをクロールするのを防ぐのに便利です) Amplify コンソールで有効化された保護は、お客様の AWS アカウント内の Web ACL に適用されます。細かいルールセットが必要な場合、開発者は WAF コンソールのルールビルダーを活用できます。 スタートガイド アプリに WAF を関連付ける手順については、 ドキュメント を参照してください。 可用性と価格 ファイアウォールのサポートは、Amplify Hosting が運用されているすべての AWS リージョンで、プレビュー版としてリリースされています ( オプトインリージョンを除く )。この統合は、CloudFront と同様のグローバルリソースの WAF に分類されます。Web ACL は複数の Amplify Hosting アプリにアタッチできますが、同じリージョン内に存在する必要があります。 プレビュー中は、AWS WAF の利用料金のみが発生します。AWS WAF は Web ACL ごとに $ 5/月、ルールごとに $ 1 を請求するほか、他の課金もあります。詳細は WAF の料金 をご覧ください。1 つの Web ACL と 2 つのルールを想定すると、この統合で最低でも $ 7 の課金が発生します。 さらに、Amplify ファイアウォール 機能を利用するには、新しい Amplify Hosting の上位プランへの加入が必要になります。この上位プランには、リリース時にほかの機能も含まれます。プレビュー期間中に Amplify ファイアウォールを有効にすると、この上位プランに自動的に加入しますが、Amplify ファイアウォール機能が一般提供されるまでは追加料金はかかりません。いつでも Amplify ファイアウォールを削除すれば、一般提供後も料金が請求されることはありません。この上位プランの具体的な価格は一般提供時にお知らせします。コミットメントも前払い投資も不要です。 次のステップ アプリにファイアウォール保護を設定するには、 AWS Amplify コンソール にアクセスしてください。 本記事は「 AWS Amplify Hosting Adds Web Application Firewall Protection – Public Preview 」を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を支援しています。最近「 三菱電機グループエンジニアが作る新しい風 “Mitsubishi Electric AWS User Group (通称: MAWS-UG)” の軌跡 」を執筆しました。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

本記事は 2025 年 1 月 14 日に公開された “ Effortlessly execute AWS CLI commands using natural language with Amazon Q Developer ” を翻訳したものです。 CLI のつらみ コマンドラインツールは、インフラストラクチャや DevOps のワークフローを簡素化するためのものですが、実際には逆効果になることが多くあります。作業の効率化を図るはずが、膨大な数のコマンド、フラグ、構文により、CLI はまるでパズルのように感じられることがあります。生産性を向上させるためのツールのはずが、基本的なコマンドを見つけるためだけに、検索やフォーラム、ドキュメントをひたすら行き来する羽目になっています。 CLI の習得は、新しい言語を学ぶのと同様に、複雑で馴染みのない構文を理解する必要があります。現実世界ではコミュニケーションギャップを埋めるために翻訳者の助けを借りますが、これからは Amazon Q Developer があなたと CLI の翻訳者になってくれます！ この記事では、コマンドライン上での Amazon Q Developer のセットアップ方法を解説し、Amazon Q Developer が複雑なタスクをいかに簡単にしてくれるかをご紹介します。 はじめ方 スムーズに記事を読み進めるために、 AWS CLI がインストールされ、設定が完了している ことを確認してください。 CLI で Amazon Q Developer を使用するには、まず Amazon Q をインストール する必要があります。現在、Amazon Q の CLI 機能は macOS と Linux ユーザーのみが利用可能です。適切なプラットフォームを使用していることを確認してください。 Amazon Q Developer を使用するには、 AWS Builder ID を持っているか、 AWS IAM Identity Center インスタンスが設定された組織に所属している必要があります。 この記事では Amazon S3 と Amazon CloudFront を使用するため、AWS アカウントに必要な権限があることを確認してください: s3:CreateBucket s3:PutObject s3:PutBucketPolicy cloudfront:CreateDistribution cloudfront:CreateOriginAccessControl cloudfront:GetDistributionConfig cloudfront:UpdateDistribution ここまでの手順を完了すれば、Amazon Q Developer がどのようにして CLI ワークフローを簡素化できるのかを確認する準備が整います。それでは、始めていきましょう。 CLI 体験の変革 新しいターミナルウィンドウを開き、 q translate と入力し、続けて複雑なコマンドを実行するための自然言語プロンプトを入力します。Amazon Q Developer は入力を受け取り、Large Language Model (LLM) を通して処理し、対応する bash コマンドを生成します。 まずはシンプルで楽しい作業から始めてみましょう。ターミナルで10秒からカウントダウンしてみましょう: q translate "Count down from 10 second by second" (※Count down from 10 second by second : 訳者注: 10から1秒ずつカウントダウンして) コマンドを実行すると、Amazon Q が実行可能なシェルコマンドといくつかのアクション項目を提案します: Execute command: 提案されたコマンドをすぐに実行 Edit command: 提案されたコマンドを編集 Regenerate answer: 別のコマンドを提案 Ask another question: 新しいプロンプトを入力 Cancel: セッションを終了 ここではコマンドを実行して、その動作を確認してみましょう: AWS の CLI からウェブサイトを構築する 基本的な操作を理解したところで、実践的な作業に取り組んでみましょう。このチュートリアルでは、コマンドラインだけを使用して、AWS 上で静的ウェブサイトをホスティングする方法を説明します。 Step 1: ウェブサイトをホストする S3 バケットを作成する Amazon S3 は静的ウェブサイトのホスティングに最適です。まず、ウェブサイトのコンテンツファイルを保存する S3 バケットを作成する必要があります。Amazon Q Developer に「us-west-2 に ‘ai-generated-bucket’ という名前の S3 バケットを作成」するように指示するだけです: q translate "Create an S3 bucket called 'ai-generated-bucket' on us-west-2" (※Create an S3 bucket called ‘ai-generated-bucket’ on us-west-2 ：訳者注: ‘ai-generated-bucket’というS3バケットを us-west-2 に作って) 注：同じ名前のバケットがすでに存在する場合は、別の名前に変更してください。 Amazon Q Developer が正しくコマンドを生成したことが確認できます: aws s3 mb s3://ai-generated-bucket --region us-west-2 コマンドの内容が適切でない場合は、「Edit command」または「Regenerate answer」を試すことができます。ここでは、生成されたコマンドを実行し、 Amazon S3 コンソール で S3 バケットが実際に作成されたことを確認します。 Step 2: “Hello World” と書かれた HTML ファイルを作る 次に、基本的な HTML ファイルをバケットにアップロードする必要があります。手動で記述する代わりに、Amazon Q Developer に案内してもらいましょう。プロンプトはこちら: q translate "Create a simple index.html file with 'Hello World' message" (※Create a simple index.html file with ‘Hello World’ message：訳者注: ‘Hello World’ と書かれたシンプルな index.html ファイルを作って) Amazon Q Developer が提案した echo '<h1>Hello World</h1>' > index.html というコマンドは適切そうです。このコマンドを実行してみましょう。 Step 3: HTMLファイルを S3 にアップロードする では、 index.html ファイルを S3 バケットにアップロードしましょう: q translate "Upload index.html to the 'ai-generated-bucket' S3 bucket" (※Upload index.html to the ‘ai-generated-bucket’ S3 bucket：訳者注: index.html ファイルを ‘ai-generated-bucket’ にアップロードして) コマンドを実行したら、 Amazon S3 コンソール で index.html ファイルがバケットに正常にアップロードされたことを確認できます。 Step 4: CloudFront ディストリビューションを設定する デフォルトでは、Amazon S3 はアカウントとバケットへのパブリックアクセスをブロックします。本番環境での使用では、パブリックアクセスのブロックを有効にしたまま、 Amazon CloudFront を通じてサイトを安全に提供することをお勧めします。 Amazon CloudFront は、コンテンツを低レイテンシーと高速な転送速度で安全に配信するグローバルなコンテンツ配信ネットワーク（CDN）であり、静的ウェブサイトのホスティングに最適です。 Amazon Q Developer を使用して、 S3 バケット用の CloudFront ディストリビューションを作成しましょう: q translate "Create a CloudFront distribution for my S3 bucket 'ai-generated-bucket'" (※Create a CloudFront distribution for my S3 bucket ‘ai-generated-bucket’: 訳者注: ‘ai-generated-bucket’ のための CloudFront ディストリビューションを作って) うーん、これは正しくないようですね。 Amazon Q Developer は、指定されていない設定ファイルで --distribution-config を提供しようとしています。これを修正するには、CloudFront ディストリビューションの設定を手動で提供するか、Amazon Q Developer の力を最大限活用するかを選ぶことができます。 より適切な結果を得るために、 --distribution-config フラグを使用しないようにプロンプトを改善してみましょう: q translate "Create a CloudFront distribution for my S3 bucket 'ai-generated-bucket' without using the ‘—distribution-config' flag" (※Create a CloudFront distribution for my S3 bucket ‘ai-generated-bucket’ without using the ‘–distribution-config’ flag: 訳者注: ‘ai-generated-bucket’ のための CloudFront ディストリビューションを ‘—distribution-config’ のフラグを使わずに作って) ずっと良くなりました！ ‘X’ を実際のオリジンドメイン名に置き換える必要があるようです。この場合、S3 バケットのオリジンは以下の形式を使用します: bucket-name.s3.amazonaws.com CLI で「 Edit command 」オプションを選択し、 ‘X’ を置き換えてください。この場合、置き換える値は ai-generated-bucket.s3.amazonaws.com となります。コマンドを実行すると、成功時にコンソールに CloudFront の設定が表示されるはずです: 出力から “Id” をコピーしてください。次のステップで必要になります。 Step 5: パブリックアクセスの準備をする 作成した CloudFront ディストリビューションのデフォルトルートオブジェクトとして index.html を設定します。これにより、ユーザーがウェブサイトのルート URL にアクセスする際、URL で明示的に指定しなくても CloudFront が自動的に index.html ファイルを提供するようになります。 q translate "Update my CloudFront distribution CLOUDFRONT_ID to have 'index.html' as default root object without using the --distribution-config flag" (※Update my CloudFront distribution CLOUDFRONT_ID to have ‘index.html’ as default root object without using the —distribution-config flag: 訳者注: ‘—distribution-config’ フラグを使用せずに、 CloudFront ディストリビューション CLOUDFRONT_ID のデフォルトルートオブジェクトを ‘index.html’ に更新して) 前のステップで取得した Id で CLOUDFRONT_ID を置き換えることを忘れないでください。コマンドを実行すると、先ほどのステップと同様に、コンソールに CloudFront の設定が表示されるはずです。 次に、 HTML ファイルを安全に公開するために、以下の作業を行う必要があります: Origin Access Control (OAC) の設定 その OAC を CloudFront ディストリビューションに設定 S3 バケットポリシーの更新 まずは Amazon Q に OAC を生成してもらいましょう: q translate "Create an OAC named 'ai-generated-oac' for my CloudFront distribution CLOUDFRONT_ID" (※Create an OAC named ‘ai-generated-oac’ for my CloudFront distribution CLOUDFRONT_ID: 訳者注: CloudFront ディストリビューション CLOUDFRONT_ID 用に ‘ai-generated-oac’ という名前の OAC を作成して) コマンドを実行すると、以下のようなエラーが表示されます: An error occurred (MalformedXML) when calling the CreateOriginAccessControl operation: 1 validation error detected: Value 'origin-access-identity' at 'originAccessControlConfig.originAccessControlOriginType' failed to satisfy constraint: Member must satisfy enum value set: [s3, lambda, mediastore, mediapackagev2] このエラーメッセージをインターネットに頼らずにデバッグするのは難しいかもしれません。幸いなことに、Amazon Q Developer には q chat という、ターミナル上のチャットボットのような強力な機能があります。これを使ってトラブルシューティングを試してみましょう: q chat "@history An error occurred (MalformedXML) when calling the CreateOriginAccessControl operation: 1 validation error detected: Value 'origin-access-identity' at 'originAccessControlConfig.originAccessControlOriginType' failed to satisfy constraint: Member must satisfy enum value set: [s3, lambda, mediastore, mediapackagev2]. Help me resolve this error" (※ Help me resolve this error : 訳者注: このエラーの解決方法を教えて) プロンプトに @history を含めることで、シェルの履歴を Amazon Q に渡し、提供されたコンテキストに基づいて応答できるようになります。 ターミナル上で、ステップバイステップの手順と出典を含む詳細な AI 生成の応答が得られました！ @history タグを使用することで、 Amazon Q Developer はエラーメッセージを実行した正しいシェルコマンドに関連付けることができます（私たちが明示的に伝えなくても、 ai-generated-oac という名前で OAC を作成しようとしていることを理解しています）。 修正された bash コマンドを実行してみましょう: aws cloudfront create-origin-access-control \     --origin-access-control-config \     Name=ai-generated-oac,\     OriginAccessControlOriginType=s3,\     SigningBehavior=always,\     SigningProtocol=sigv4 今回は成功しました: Id フィールドをメモしておいてください。後で必要になります。 次に、生成された OAC を CloudFront ディストリビューションに設定する方法について、 q chat に尋ねてみましょう: q chat "@history Update my CloudFront distribution CLOUDFRONT_ID with the OAC we just generated, be specific" (※Update my CloudFront distribution CLOUDFRONT_ID with the OAC we just generated, be specific: 訳者注: 先ほど生成した OAC を使用して、CloudFront ディストリビューション CLOUDFRONT_ID を設定して、具体的に説明して) @history を使用することで、 Amazon Q が自動的に CLOUDFRONT_ID を補完してくれることに注目してください！ 指示に従って最後のステップを完了すれば、コンソールの出力に更新された CloudFront ディストリビューションが表示されるはずです: “Status” が “InProgress” と表示されています。次のステップに進むには、CloudFront のデプロイメントが完了するまで待つ必要があります。最新のステータスを取得する方法を Amazon Q Developer に尋ねてみましょう: q translate "Get the status of my CloudFront distribution with CLOUDFRONT_ID on us-west-2" (※Get the status of my CloudFront distribution with CLOUDFRONT_ID on us-west-2: 訳者注: us-west-2 で CLOUDFRONT_ID を持つ CloudFront ディストリビューションのステータスを取得して) $CLOUDFRONT_ID を実際のものに置き換えてコマンドを実行し、最新のステータスを確認しましょう。完了までに数分かかる可能性があるので、コーヒーを飲んだり、短い散歩に行ったりするのにちょうど良い時間です！ ステータスが Deployed になったら、 CloudFront ディストリビューションにパブリック読み取りアクセスを許可するように S3 バケットポリシーを更新できます: プロンプトはかなりあいまいなものを使用していますが、 @history のおかげで Amazon Q は役立つレスポンスを生成するのに十分なコンテキストを持つことができました。 指示に従うだけで、サイトにアクセスする準備が整います！ Step 6: サイトにアクセスする CloudFront ディストリビューションのパブリック URL を取得しましょう。 q translate "Get the public url of my CloudFront distribution CLOUDFRONT_ID" (※Get the public url of my CloudFront distribution CLOUDFRONT_ID: 訳者注: CloudFront ディストリビューション CLOUDFRONT_ID の Public URL を取得して) URL を取得したら、ブラウザで開いてください。「Hello World」が表示されるはずです！ まとめ この記事では、以下を実施しました: ウェブサイトファイルをホストするための S3 バケットの作成 「Hello World」メッセージを含む簡単な HTML ファイルの生成 HTML ファイルの S3 バケットへのアップロード ウェブサイトを安全に提供するための CloudFront ディストリビューションの作成 CloudFront ディストリビューション用の Origin Access Control (OAC) の設定 CloudFront からのアクセスを許可するための S3 バケットポリシーの更新 CloudFront URL を通じたウェブサイトへのアクセス これらすべてのステップは、 CLI 上の Amazon Q Developer を使用してターミナルで実行されました。 複雑な CLI コマンドを自然言語に変換できる手軽さを体験し、AWS がこれまで以上にアクセスしやすくなったことがお分かりいただけたと思います。しかし、これは始まりに過ぎません。ニーズが拡大するにつれて、Amazon Q もスケールし、より迅速なデプロイメント、生産性の向上、 AWS エコシステム全体へのシームレスなアクセスを提供します。 Amazon Q Developer が各ステップを簡素化してくれるので、まだ試していない AWS サービスもぜひ探索してみてください。ワークフローを効率化し、革新と成長のための新しい機会を開くことができます。 翻訳はApp Dev Consultantの宇賀神が担当しました。原文は こちら です。 著者について Xipu Li Xipu は AWS のソフトウェアエンジニアで、Amazon Q などの次世代開発ツールの開発に取り組んでいます。スタートアップ、スキー、ミームの作成に興味のある食通です。  

このブログは 2024 年 5 月 28 日に Alex Payne, Kartik Verma, Genta Watanabe によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 2016 年に設立された トヨタコネクテッドノースアメリカ は、トヨタとレクサスの車両向けの高度な技術とデータサービスの開発と提供に注力しています。トヨタコネクテッドの使命は、モビリティをすべての人にとってより身近でエキサイティングな、人間中心の体験にすることです。この目的のために、トヨタコネクテッドはデータ接続を利用して、北米の 800 万を超える小売顧客、数百のディーラー、および車両会社にサービスを提供しています。 トヨタコネクテッドのリアルタイムデータプラットフォームは、コネクテッドカーの数が劇的に増加したため、わずか発売以来 5 年間で指数関数的な成長を遂げました。ビッグデータ分析プラットフォームの要件は、市場の状況に基づいており不確実です。製品サイクルにおける電動化の増加など、企業のビジネスイニシアチブを実現するためには迅速に進化する必要があります。したがって、これらのプラットフォームのデータストレージコストは、トヨタコネクテッドの全体的な予算に大きく直結しています。 この投稿では、トヨタコネクテッドノースアメリカが、 Amazon S3 Intelligent Tiering ストレージクラス 、 Amazon S3 ライフサイクル 、 Amazon Athena などのマネージドサービスと機能を活用して、データ量が 4 % 増加したにもかかわらず、ビジネスをサポートするためにどのように月間 40 % 以上の節約を実現したかについて説明します。 データ分析とストレージの課題 トヨタコネクテッドのリアルタイムデータプラットフォームは、複数のレイヤーで構成されています。 Ingest レイヤーは、車両の何百ものセンサーからデータを受信します。 Decode レイヤーは、バイナリデータを使用可能な形式に変換します。 Transform レイヤーは、データを変換し、テレメトリ、ドライバースコア、衝突通知、安全サービスなどの多数のデータサービスを顧客に公開します。 Analyze / Consume レイヤーはビッグデータ分析プラットフォームであり、車両データを処理し、機械学習 / 人工知能（ ML / AI ）を適用して研究開発のための洞察を提供し、トヨタ車の品質を向上させ顧客満足度を提供します。 車両台数の増加に伴うコスト上昇に対処するため、チームは当初、 S3 ライフサイクル設定を使用して S3 Standard ストレージクラス から S3 Glacier Flexible Retrieval ストレージクラス にデータを移動する保存ポリシーを実装しました。このアプローチは、クラウド全体のコストを削減するために望んでいた節約をもたらしましたが、これらの節約をさらに改善する必要がありました。 課題は保存ポリシーが静的であることでした。これらのほとんどは、 30 日後にデータをあるストレージ階層から別のストレージ階層に移動するなどの単純なルールを使用していました。2 つ目の課題は、ビッグデータ分析プラットフォームのデータ要件が市場の状況に基づいている事による不確実性でした。たとえば、 Prime プラグインハイブリッドや bZ4X 電気自動車に関連するデータは、電動化などの拡大するトヨタの取り組みをタイムリーにサポートするため、より迅速に取得できる必要があります。 欠けていたのは、アクセス頻度の低いデータとは対照的に、どのデータが頻繁に使用またはアクセスされたかを判断するためのインテリジェンスでした。こうしたアクセスパターンの変化に伴い、トヨタコネクテッドは必要に応じてデータを動的に利用できるようにする方法を必要としていました。さらに、アクセス頻度の低いデータを S3 Glacier Flexible Retrieval や S3 Glacier Deep Archive などの低コストのストレージクラスに移動した場合でも、ビジネスニーズの変化に応じて分析ワークロードからすぐにアクセスできるようにする必要がありました。たとえば、 2023 年のアースデイでは、トヨタコネクテッドは、ノーマルモードとエコモードで走行する車両から CAN データをすばやく取得して、特定の期間におけるトヨタ所有車の二酸化炭素排出量を比較する必要がありました。チームは、オペレーションオーバーヘッドを追加したり、既存のワークロードやアプリケーションを完全に再設計したりすることなく、これらの課題に対する無駄のないソリューションを探しました。 ソリューション トヨタと AWS は、さまざまなデータセット、そのアクセスパターン、データ量、オブジェクト数を分析するためのフォーカスグループを結成しました。この分析の結果、特定のストレージアプローチからメリットが得られる可能性のある分類されたデータセットと、それらのアプローチによる潜在的なコスト削減のリストが提供されました。 S3 Storage Lens と S3 ストレージクラス分析 が役に立ちました。S3 Storage Lens では、合計ストレージ、オブジェクト数、ストレージクラスまたは S3 バケットごとの平均オブジェクトサイズなど、オブジェクトストレージの使用状況とアクティビティの概要を確認できました。S3 ストレージクラス分析は、「アクセス頻度が低い」ストレージの量を特定するのに役立ちました。 最適化によって最も恩恵を受けるバケットについては、AWS からの提案に従いました。一般に、これらのバケットは、他のバケットよりも多くのデータを格納し、平均オブジェクトサイズが大きく、一時的ではない永続的なオブジェクトを含むバケットでした。AWS チームと協力して、分析した各バケットでどれだけのコスト削減が見込めるかを正確に見積もりました。その後、 3 つの戦略を策定しました。 S3 ライフサイクル設定 分析の結果、アクセスパターンが予測可能な場合では、少数のオブジェクトが何度もアクセスされるシナリオと、多数のオブジェクトが 1 回だけアクセスされるシナリオを区別することが重要であることがわかりました。後者の場合、S3 Intelligent Tiering による節約額は S3 ライフサイクル設定を使用する場合よりも少なくなります。これは、S3 Intelligent Tiering では、オブジェクトのアクセスパターンを監視するための 監視および自動化に毎月少額の料金 がかかり、 30 日間連続してアクセスされていないオブジェクトは S3 低頻度アクセス層に自動的に移行されるためです。アクセスパターンが予測可能なデータについては、よりカスタマイズされたルールを適用するために S3 ライフサイクル設定をこれらのバケットに残しました。 S3 Intelligent-Tiering 次に、アクセスパターンが予測できないバケットについて、S3 Intelligent Tiering の使用による影響を測定したいと考えました。チームは、インスタントアクセス階層からデータを取得する際にレイテンシーの課題がないことを確認するために、 Amazon Athena や Amazon EMR などのダウンストリームアプリケーションの検証を含む広範な分析を行いました。さらに、これらの AWS サービスを使用する日次ジョブを監視し、オペレーション効率に悪影響がないことを確認しました。 予測不可能なアクセスパターンデータを S3 Intelligent Tiering に移動した後、チームは AWS Cost Explorer を使用してコストを確認しました。2023 年 2 月に最初に確認された直接的な変化は、Amazon S3 の新しい階層へのオブジェクトの初期移行料金が原因の約 1 日のコスト急騰でした。その後、価格は予想通り通常に戻りました。切り替えから約 30 日後、データ量は前月比で 4 % 増加し、1 か月あたり 40 % のコスト削減が見られるようになりました。これは、S3 Intelligent Tiering が、アクセス頻度の低いオブジェクトをより低コストのストレージ階層に自動的に移動したためです。 重複データの回避 ビッグデータ分析プラットフォームでのデータ分析とクエリ処理に関して、トヨタコネクテッドは Amazon Athena を使用して Amazon S3 のデータをクエリしました。データセットには、S3 Standard と S3 Glacier の両方のストレージクラスのファイルが含まれていました。Amazon Athena は S3 Glacier Flexible Retrieval や S3 Glacier Deep Archive などの S3 Glacier アーカイブストレージクラスから復元されたデータを直接クエリすることはできませんでした。しかし、アドホックなビジネスニーズへの対応や技術的な課題のトラブルシューティングを行うために、アーカイブされたデータにアクセスすることが必要な場合があります。 この課題を緩和し、クエリをシームレスに実行するために、回避策を実装しました。これには、復元されたオブジェクトを複製して、Amazon Athena がクエリを実行できるように、復元されたオブジェクトのコピーを S3 Standard ストレージクラスに追加作成する必要がありました。しかし、このアプローチは、データストレージの増大によるコストの増加という形で、意図しない結果をもたらしました。この諸経費が、分析ニーズに Amazon Athena を活用する組織にとっての懸念事項となったため、製品に関するフィードバックを AWS チームと共有しました。 2023 年 6 月 29 日、Amazon Athena は、追加のコピーを必要とせずに、復元された S3 Glacier ストレージクラスのデータを直接クエリする 新機能 をリリースしました。これにより、プロセスが合理化され、コストが大幅に削減されました。この強化は、 Amazon Athena に依存するデータ分析ワークフローの最適化において極めて重要な瞬間となりました。これにより、経費を抑えながら、データの可能性を最大限に引き出すことができました。このブログ 記事 では、この新機能の詳細を紹介しています。 結論 この投稿では、ストレージコストを最適化するための 3 つの戦略について説明しました。S3 Intelligent Tiering を実装することで、リソースを効率的に割り当てることができ、パフォーマンスを低下させることなくコストを最適化できました。S3 Intelligent Tiering を最大限に活用するには、アクセス頻度の異なるデータを含むバケットを特定することが不可欠です。これは、月当たり 40 % の節約につながりました。一方、S3 ライフサイクル設定は、予測可能なアクセスパターンを持つデータを含むバケットに、よりカスタマイズされたルールを適用するのに役立ちます。さらに、Amazon Athena を使用して S3 Glacier Archive クラスから復元されたデータを直接クエリすることで、オペレーションオーバーヘッドがなくなり、ストレージコストをさらに節約できます。 こうした最適化の取り組みは、コネクテッドカーの数が増え続けることで指数関数的な成長を遂げてきた、トヨタコネクティッドのリアルデータプラットフォームの持続可能な事業成長を促進しました。また、電動化やアースデイの外部エンゲージメントイニシアチブなど、データ要件が不確実であったり、今後も不確実なデータ要件が続く新しい戦略的事業計画を支援しました。 <!-- '"` --> TAGS: Amazon S3 Glacier storage classes , Amazon S3 Intelligent-Tiering , Amazon Simple Storage Service (Amazon S3) , AWS Cloud Storage Alex Payne Alex Payne は、トヨタコネクテッドノースアメリカのCAN（コントローラー・エリア・ネットワーク）取り込みプラットフォームのテクニカル・リードで、トヨタ車からのCANデータの取り込みを担当しています。余暇には、チェスをしたり、ピアノを弾いたりするのが大好きです。 Kartik Verma Kartik Verma はトヨタコネクテッドノースアメリカのシニアデータエンジニアで、AWS サービスの最適化、大幅なコスト削減につながる自動化フレームワークの設計、モビリティグループの製品運用の推進に情熱を注いでいます。余暇には、家族と充実した時間を過ごしたり、アウトドアスポーツに参加したりしています。 Genta Watanabe Genta Watanabe は AWS のシニアテクニカルアカウントマネージャーです。彼は戦略的な自動車業界のお客様との仕事に時間を費やし、お客様がオペレーション・エクセレンスを達成できるよう支援しています。彼の関心分野は機械学習と人工知能です。余暇には、家族と充実した時間を過ごしたり、旅行を楽しんだりしています。

このブログは 2024 年 1 月 29 日に Ron Kolwitz (Senior Solutions Architect)、Robert Fountain (Sr. EUC Specialist Solutions Architect)、Roy Tokeshi (EUC Specialist Solutions Architect) によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 お客様は Amazon AppStream 2.0 を使用して、仮想化されたデスクトップとアプリケーションのフリートをエンドカスタマーにデプロイし、無数の永続的なストレージソリューションをサポートします。AppStream 2.0 は組織のユーザに複数の一般的なストレージオプションですぐに使用できる機能を提供します。例えば Amazon Simple Storage Service (S3) 、 Amazon WorkDocs 、Google Drive for G Suite、OneDrive for Business などです。これらのストレージソリューションで動作する場合、AppStream 2.0 はユーザーセッションの開始時にファイルをダウンロードし、セッションの終了時にストレージプロバイダーと同期します。これらのサービスはほとんどのデスクトップワークロードに最適化されており、典型的なシステム要件に対するデファクトのアプローチとなっています。 AppStream 2.0 のお客様の中には、大規模なデータセット、数百から数百万のファイル、バックエンドストレージプロバイダーとの継続的な同期など、強化されたストレージ機能を必要とする厳しい要求をお持ちのお客様もいます。たとえば、AppStream 2.0 フリートインスタンスで作業する大規模な開発チームは、大規模なソフトウェアアプリケーションを構築するために、数千のファイルを共同でコンパイルする必要がある場合があります。このようなユースケースでは、マネージドストレージオプションである Amazon FSx ファミリーなどの AWS ストレージサービスとフリートを統合できます。たとえば、 FSx for ONTAP と組み合わせると、VPC 内で実行されるカスタマイズ可能な IOPS、スループット、キャッシュ機能を備えた独自の NetApp ONTAP ストレージ機能を活用する堅牢なソリューションをフリートに提供できます。マネージドサービスである Amazon FSx は、可用性や耐久性、パッチ適用、可視性を維持し、お客様をご自身のストレージソリューションの管理から解放します。 このブログでは、高性能なストレージを提供するストレージ共有ドライブとして Amazon FSx ファミリーを使用し Amazon AppStream 2.0 Linux ベースのフリートをデプロイする方法を紹介します。このソリューションは、AWS ネットワークバックボーンで提供されるキャッシュ、パフォーマンス、拡張可能なストレージすべての機能を管理する Amazon FSx を必要とするチームに役立ちます。Windows ベースのユーザーに対しては、同様の Windows ソリューションをセットアップする方法として 以前のブログ がございます。 読了までの時間 10 分 完了までの時間 30 分 学習レベル 上級 (300) 完了までの費用 (推定) 割り当てられた FSx ストレージと最新のフリートを設定するための AppStream 2.0 イメージビルダーインスタンスの利用時間に対してのみ料金が発生します。詳細については、 Amazon AppStream 2.0 の料金 と Amazon FSx for NetApp ONTAP の料金 を参照してください。 利用したサービス Amazon AppStream 2.0 Amazon FSx for NetApp ONTAP 前提条件 次の前提条件が必要です。 AWS アカウント 必要な権限を持つ AWS IAM ロールとポリシー 2 つ以上のプライベートサブネットを持つ Amazon Virtual Private Cloud (VPC) AppStream 2.0 フリート、スタック、イメージビルダー – セットアップの詳細については Amazon AppStream 2.0 の開始方法 を参照してください。 Amazon FSx for NetApp ONTAP ファイルシステム – セットアップの詳細については Amazon FSx for NetApp ONTAP の開始方法 を参照してください。新しいファイルシステムの FSxN の共有ポイントを書き留めます。 例: &lt;&lt;svm&gt;&gt;.&lt;&lt;fileshare&gt;&gt;.fsx.&lt;&lt;region&gt;&gt;.com:/&lt;&lt;volume&gt;&gt; ソリューションの概要 Amazon AppStream 2.0 を Amazon FSx ストレージと一緒に使用するには、セッション開始時に FSx ストレージをマウントするようにイメージビルダーを設定する必要があります。このアプローチは、ホームフォルダーあるいは共通のファイル共有としてユーザーごとにストレージをマウントするために使用できます。 次の図は、さまざまな AppStream 2.0 および Amazon FSx for NetApp ONTAP コンポーネントとそのデプロイメントを示しています。 実装 カスタムイメージを作成するには、まずイメージビルダーインスタンスを作成します。 AppStream 2.0 管理コンソール AppStream 2.0 管理コンソールから、 Images を選択します。 Image builder タブを選択し、 Launch image builder を選択します。 フィルターを使用して利用可能な Linux イメージを検索し、Linux イメージを選択します。 イメージの名前を入力し、利用可能なインスタンスタイプを選択します。この例では、IAM ロールと VPC エンドポイントのセクションはそのままにしておきます。 Next を選択します。 VPC、利用可能なサブネット、セキュリティグループを選択します。注意: VPC セキュリティグループは、Amazon FSx ファイルシステムへのアクセスを許可する必要があります。 Launch Image builder を選択します。 次のオプションは、Amazon AppStream 2.0 Linux ベースのフリートと FSx for ONTAP 永続ストレージを組み合わせる方法を示しています。 オプション 1 ) すべてのユーザーに対するホームフォルダードライブの提供 Amazon FSx を使用して、ユーザーごとにアタッチされたフォルダーを提供することができます。このデータは、ネットワークファイルシステム (NFS) プロトコルを使用してマウントされ、ユーザーの AppStream 2.0 インスタンスに直接接続され、継続的に同期されたネットワークストレージを提供します。 手順 AppStream 2.0 管理コンソール から、 Images を選択します。 Image builder タブを選択し、Image builder の横にあるラジオボタンを選択して、 Connect を選択します。 以前にメモした FSx 共有ボリュームを使用して、FSx ファイルシステムをイメージビルダーインスタンスにマウントし、各ユーザーのディレクトリを構築します。 sudo mkdir /fsx sudo mount -t nfs "&lt;&lt;svm&gt;&gt;.&lt;&lt;fileshare&gt;&gt;.fsx.&lt;&lt;region&gt;&gt;.amazonaws.com:/&lt;&lt;volume&gt;&gt;" /fsx # repeat below for each user sudo mkdir /fsx/&lt;&lt;username&gt;&gt; sudo chown 1002:1004 /fsx/&lt;&lt;username&gt;&gt; 起動時にマウントスクリプトを実行するには、SessionStart の executables セクションにある /opt/appstream/SessionScripts/config.json にエントリを挿入して更新します。 { &nbsp; &nbsp;"SessionStart": { &nbsp;&nbsp;&nbsp; "executables": [ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; …, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Context": "system", &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Filename": "/opt/appstream/SessionScripts/system-start-fsx-user.sh", &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Arguments": "", &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "S3LogEnabled": true &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } &nbsp;&nbsp;&nbsp; ], &nbsp;&nbsp;&nbsp; "waitingTime": 60 &nbsp; }, &nbsp; … } ユーザーごとの FSx 共有をマウントするため、 /opt/appstream/SessionScripts/system-start-fsx-user.sh に新しいマウントスクリプトファイルを作成します。NFS_SHARE 変数を、以前にメモした FSx 共有に更新します。このスクリプトは、 appstream_user_sh 環境変数の $AppStream_UserName を自動的に追加し、ボリューム上の Linux ユーザーのマウントディレクトリのみを一意にマウントします。 #!/bin/bash NFS_SHARE="&lt;&lt;svm&gt;&gt;.&lt;&lt;fileshare&gt;&gt;.fsx.&lt;&lt;region&gt;&gt;.amazonaws.com:/&lt;&lt;volume&gt;&gt;" HOMEFOLDER_BASE="$HOME/MyFiles/HomeFolder" # Load the appstream user variables if [ -f /etc/profile.d/appstream_user_vars.sh ]; then . /etc/profile.d/appstream_user_vars.sh fi&nbsp; # Mount FSX Storage for user session, create new directory if HomeFolder already exists (e.g. if S3 storage is already mounted) INDEX=”” while [ -d "$HOMEFOLDER_BASE$INDEX" ]; do &nbsp; ((INDEX++)) done HOMEFOLDER="$HOMEFOLDER_BASE$INDEX" mkdir "$HOMEFOLDER" chown as2-streaming-user:as2-streaming-user "$HOMEFOLDER" sudo mount -t nfs "$NFS_SHARE/$AppStream_UserName" "$HOMEFOLDER" スクリプトファイルの権限を実行可能に変更します。 sudo chmod 755 /opt/appstream/SessionScripts/system-start-fsx-user.sh イメージアシスタントを起動して新しいイメージを作成します。 新しく作成されたイメージを使用して AppStream 2.0 フリートを更新します。フリートを停止して起動します。 AppStream 2.0 ユーザーセッションを起動します。S3 または同様のバックアップストレージをオフにするまで FSx ネットワークストレージはユーザーの MyFiles/HomeFolder2 ディレクトリに表示されるため、チームは必要に応じて FSx ストレージにファイルを移行できます。必要ならば以前のストレージをオフにすることができ、その場合 FSx ストレージは MyFiles/HomeFolder として表示されます。希望する場合、FSx と AppStream 2.0 組み込みストレージメソッドの両方を共存させることができます。 オプション 2 ) ユーザー間のファイル共有の提供 FSx を使用すると、すべてのユーザーで必要な共通ファイルで共同作業するために組織内のユーザーに共有フォルダーの場所を提供できます。プロセスはオプション 1 と似ていますが、すべてのフリートユーザーインスタンス間で共通のポイントにマウントされ、共有されます。 手順 AppStream 2.0 管理コンソール から、 Images を選択します。 Image builder タブを選択し、Image builder の横にあるラジオボタンを選択して、 Connect を選択します。 FSx 共有ボリュームを使用して FSx ファイルシステムをイメージビルダーインスタンスにマウントし、共有利用のための共通ディレクトリを構築します。 sudo mkdir /fsx sudo mount -t nfs "&lt;&lt;svm&gt;&gt;.&lt;&lt;fileshare&gt;&gt;.fsx.&lt;&lt;region&gt;&gt;.amazonaws.com:/&lt;&lt;volume" /fsx sudo mkdir /fsx/common sudo chown 1002:1004 /fsx/common 起動時にマウントスクリプトを実行するには、SessionStart の executables セクションにある /opt/appstream/SessionScripts/config.json にエントリを挿入して更新します。 { "SessionStart": { &nbsp;&nbsp;&nbsp; "executables": [ &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; …, &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; { &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Context": "system", &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Filename": "/opt/appstream/SessionScripts/system-start-fsx-common.sh", &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "Arguments": "", &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "S3LogEnabled": true &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } &nbsp;&nbsp;&nbsp; ], &nbsp;&nbsp;&nbsp; "waitingTime": 60 &nbsp; }, &nbsp; … } ユーザー間で共通の共有フォルダーをマウントするには、 /opt/appstream/SessionScripts/system-start-fsx-common.sh の新しいマウントスクリプトファイルを作成します。NFS_SHARE 変数を、以前にメモした FSx 共有で更新します。 #!/bin/bash NFS_SHARE="&lt;&lt;svm&gt;&gt;.&lt;&lt;fileshare&gt;&gt;.fsx.&lt;&lt;region&gt;&gt;.amazonaws.com:/&lt;&lt;volume&gt;&gt;/common" COMMONFOLDER_BASE="/fsx/common" # Mount FSX Storage for common storage sudo mount -t nfs "$NFS_SHARE" "$COMMONFOLDER_BASE" ファイルの権限を実行可能に変更します。 sudo chmod 755 /opt/appstream/SessionScripts/system-start-fsx-common.sh イメージアシスタントを起動して新しいイメージを作成します。 新しく作成されたイメージを使用して AppStream 2.0 フリートを更新します。 フリートを停止および起動します。 AppStream 2.0 ユーザーセッションを起動します。Amazon FSx 共有ストレージが表示され、ユーザーは /fsx/common の下でデータを共有できるようになります。 クリーンアップ AWS アカウントで継続的な課金が発生しないようにするには、新しく作成されたすべての AWS リソースを削除します。 AWS マネジメントコンソール にログインして、フリート、イメージビルダー、FSx ファイルシステムなど、このデプロイメントの一部として作成した可能性のあるリソースを削除します。イメージの削除については、 AppStream 2.0 管理者ガイド を参照してください。FSx ストレージの削除については、 FSx for ONTAP ユーザーガイドの入門 リソースのクリーンアップ を参照してください。 まとめ Amazon AppStream 2.0 と Amazon FSx を使用すると、数千から数百万のファイルを継続的に同期する高性能ストレージのユースケースに対応できる仮想化デスクトップを構築できます。この例は、強化されたストレージ機能を必要とするハイエンドの共同開発でお客様にご利用いただいています。 適切な FSx ストレージ サービスの選択に関する詳細については、 Amazon FSx ファイルシステムの選択 の概要を参照してください。 高度なパフォーマンスチューニングの詳細については、 Amazon FSx for NetApp ONTAP パフォーマンス を参照してください。 翻訳はネットアップ合同会社の Sr. Cloud Solutions Architect for AWS の藤原様、監修は Cloud Support Engineer の戸松が担当しました。 Ron Kolwitz は、米国連邦政府科学部門の顧客をサポートするシニアソリューションアーキテクトです。顧客と連携して、エンタープライズクラウドの導入と戦略に関する技術ガイダンスを提供し、適切に設計されたソリューションの構築を支援しています。特に航空宇宙と量子ベースのコンピューティングに熱心に取り組んでいます。余暇には、水上スキー愛好家の家族と過ごすのが好きで、大自然を楽しんでいる姿をよく見かけます。 Roy Tokeshi は、IT コンサルティング、教育、アーキテクチャ設計の分野で 25 年以上の経験を持つ、熟練した技術愛好家です。彼の技術に対する愛情は、新しいトレンドの探求と包括的なコミュニティの構築に注力していることを示しています。彼は複雑な概念を簡素化し、すべての専門家が技術を利用できるようにします。Roy は、AWS サービス、CNC、レーザー彫刻機、IoT を使用して作成および構築することを楽しんでいます。チェスは下手ですが、あらゆる年齢や職業の人々に、ボード上やオンラインでチェスをプレイするよう勧めるのが大好きです。 Robert Fountain は、ペンシルバニア州を拠点とするシニア EUC スペシャリストソリューションアーキテクトです。Robert は 2020 年から AWS に勤務しており、現在 6 つの AWS 認定を取得しています。オフィスの外では、Robert はナショナル・スキー・パトロールのメンバーであり、妻と 2 人の息子、そして愛犬の Daisy と一緒に過ごすことを楽しんでいます。 &nbsp; &nbsp;