国内最大規模の学習型ITカンファレンスである AWS Summit Japan が、6 月 25 日（水）、26 日（木）の二日間に渡り幕張メッセで開催されました。今年はさらにブース展示が拡充され、ヘルスケア・ライフサイエンス（HCLS）ブースでは、ライフサイエンスから３つ、ヘルスケアから２つの展示を行い、お陰様で大勢のお客様にご来場いただきました。展示内容としては、生成AIに加えてAIエージェントがより複雑で多岐にわたる業務を効率化し、さらに実験装置や医療機器などとも連携するデモを紹介しました。開催報告のブログはヘルスケアとライフサイエンスに分かれており、このブログはライフサイエンスに関する報告です。ヘルスケアに関しては こちら をご覧ください。 AI エージェントが切り拓く創薬研究の自動化デモ ( スライド ) こちらのデモブースでは、AI エージェントを活用した業務変革の一例として、創薬研究領域におけるDMTA (Design – Make – Test – Analyze)サイクルの各プロセスを研究員がエージェントへ対話的に指示することで自律的に実行するデモを展示しました。今回展示したデモは、抗体配列の生成モデル、抗体の特性を予測するモデルおよび予測スコアをもとに抗体配列を選定するモデルを利用し抗体配列のデザインを行い、合成および評価を行なって機械学習モデルの更新を行う、抗体のリード最適化サイクルを想定したデモのシナリオをとなっています。 まず、研究員がDMTAサイクルの計画をエージェントへ指示すると、エージェントは自律的に過去に実施されたDMTAサイクルの情報を取得して必要なコンテクストを補完しながら一連のDMTAサイクルの詳細が記載されたドキュメントを作成します。続けて、D, M, T, Aそれぞれのタスクに対して担当の研究員がエージェントへ指示を行うと、エージェントは自律的に必要な情報を検索し取得する、計算やドキュメント作成等のタスクを実行する、データの保存や結果の記録等を行います。 今回のデモの注目点は、コンピュータ上で完結するタスクだけでなく、MakeやTestといった実際に実験室での作業が必要な専門的な工程の実行もAI エージェント実行のシナリオに含めている点です。今回はMakeはエージェントが研究員をサポートする形で実験は研究員が実施、TestはLab Automationにより完全に自動化されており、その指示をエージェントが実行可能であるという仮定をしたシナリオでデモを実施しています。 Lab Automationの実現にはハードウェア、ソフトウェア領域共に様々な課題がありますが、特にソフトウェア領域の課題の一つは、非定型業務において一連の実験機器を動かす実験のプロトコルを、いかにロボットや機器への指示へと落とし込むかです。今回のデモでは、自動分注機である  OT-2  をエージェントが操作可能な形で接続し、エージェントが自律的に自動分注機のプロトコルをPythonスクリプトとして作成し指示をすることで、エージェントによる自律的な実験を実現しています。 しかし、実際の実験プロセスは分注だけでは完結しません。試薬の取り出し、分注、測定、記録といった一連のプロセスを行う必要があります。このような一連のタスクをエージェントによって実現するにはどのような工夫が必要でしょうか？考えられるアプローチの一つはエージェントのタスク実行の精度を高めるためのデータの蓄積と、適切なエージェントのツールアクセスの整備です。例えば、実験機器の仕様が記載されたドキュメントにエージェントがアクセスできるようになっていれば、エージェントはその仕様に従って適切な機器への指示が期待されます。しかし、仕様には記されていない研究員独自のノウハウや工夫を必要とする動作をエージェントに期待するのは、少なくとも現在のLLMの性能からは現実的ではありません。そこで、機器のドキュメントだけでなく、過去の実験の詳細な記録やその際の研究員の暗黙知にまでエージェントがコンテクストとして取得させることで、より賢く自律的なエージェントによるタスクの実行が期待されます。今回のデモ展示では、研究の各プロセスをエージェントと研究員が協調しながら進めることで、研究員を補佐しつつもデータを蓄積し、その蓄積されたデータによりエージェントの精度や自律性が向上していくという長期的な展望と、その入り口としてのデモという形での展示を行いました。 また、実装にあたってはエージェントの実装に Strands Agents SDK を利用し基盤モデルには Amazon Bedrock  を利用しています。エージェントはAgent as Tools構成でのマルチエージェント構成で実装しており、Design, Make, Test, Analyzeや計画、実験機器操作など専門知識が必要とされるタスクはサブエージェントが実行するアーキテクチャとなっています。サブエージェントを利用することで、複雑な判断が必要とされるタスクのためのシステムプロンプトやツールをリードエージェントから分離し、全体のコンテクストウィンドウを節約しつつ複雑なタスクの実行精度を上げる工夫をしています。 創薬研究 ( スライド ) Life Sciences Agents Toolkit on AWS における R&D 領域の活用デモ Life Sciences Agents Toolkit on AWS はライフサイエンスのワークフローを Amazon Bedrock エージェント を使用して 構築するためのベストプラクティスです。このソリューションは GitHub にオープンソースとして公開 されており、誰でもご自身の AWS アカウントに展開可能で、独自にカスタマイズしてそのままご利用頂くこともできます。 (注意：このソリューションの実行中に使用した AWS サービスのコストはお客様の負担となります。ご自身でデプロイされる場合はご了承のうえ、ご利用ください。) ソリューションには PubMed や ClinicalTrials.gov  などのパブリック API、社内データを想定したサンプルデータを格納する Amazon Neptune 、 AWS HealthImaging や Amazon Redshift などのリソース、 Amazon SageMaker でカスタムコンテナや、その他の特殊な生物学基礎モデルをサポートするツールなどがあります。今回のブース展示では実装されている 3 つの AI エージェントのうち R&D 領域向けの Biomarker supervisor のデモを実施しました。 バイオマーカーとは病気の有無や進行状態、治療の効果などを評価するための指標となるものであり、具体的には血液検査で測定されるタンパク質や遺伝子、血圧や心拍数などです。Biomarker Supervisor はがんのバイオマーカー分析とインサイトを支援することを目的としたマルチエージェントシステムです。 このデモでは、がん患者の調査として体の中にあるタンパク質の一つである GDF15 (Growth Differentiation Factor 15) の量が少ないがん患者を検索し、その患者の腫瘍の形状について調査することを想定しています。 Biomarker-discovery-assistant はスーパーバイザーとして質問に対するマルチステップタスクを定義し、コラボレーターである Biomarker Database Analyst (データベースへの SQL クエリ生成と実行を担う) や Medical Imaging Expert (医療画像の処理と分析) にタスクを委任して、アウトプットを最終的な回答にまとめます。このようなマルチエージェントコラボレーションにより、専門的なスキルを必要とする複雑なマルチステップタスクを、複数の AI エージェントを連携することで、取り組むことが可能です。 第一三共株式会社様事例：創薬研究クラウドプラットフォームにおけるモダナイゼーションの取り組み 第一三共株式会社ではハイパフォーマンスコンピューティング (HPC) 環境を構築・運用し、研究環境の効率化とスピードアップを実現しています。一方で HPC 環境の継続的な利用においては運用作業が負担となり、将来的なスケーラビリティに影響するため、創薬研究クラウドプラットフォームにおけるモダナイゼーションの取り組みを　AWS が提供する新しいマネージドサービス AWS Parallel Computing Service (AWS PCS) の試験構築に着手しました。詳細はこちらの AWS ブログ を参照ください。 臨床開発 ( スライド ) 臨床開発ブースでは、5月に米国で開催されたAWSライフサイエンス・シンポジウムで発表されたソリューションを中心に3つのデモを紹介しました。 1つ目が「Life Sciences Generative AI Portal」です。このポータルは、臨床開発だけでなく、創薬研究や製造、コマーシャルなどライフサイエンス分野の30以上の生成AIアプリケーションを提供し、各企業でのPoC(概念実証)を加速することを目的としています。臨床開発においては、臨床試験データの分析、臨床統計のアシスト、プロトコルデザインの支援など、臨床開発に特化したアプリケーションも用意されており、ブースでは臨床試験情報をチャット形式で検索でき、通常のキーワード検索に比べて業務の効率化が図られるデモを紹介しました。 2つ目は創薬研究でもご紹介した「 Life Science Agent Toolkit 」です。これは、 Amazon Bedrock Agents を活用したライフサイエンス向けのワークフロー構築ベストプラクティスを提供する、オープンソースのツールキットです。臨床試験に特化したエージェントも用意されており、マルチエージェントによる連携も可能で、より複雑で抽象的な依頼にも柔軟に対応します。デモでは、「BRCA変異を有する卵巣がん患者を対象とした新規PARP阻害剤のフェーズII臨床試験プロトコルの作成してください」のような依頼をスーパーバイザーエージェントにすると、まずは回答作成のための作業計画を立案し、その計画に従って臨床試験情報検索とプロトコル作成の二つのサブエージェントが連携して、公開データベースから関連情報を収集し、また所定の書式に従ったドラフト作成まで実施する様子を紹介しました。通常、多くの人手と時間をかけて実施されるこのような作業がAIエージェントにより効率化できる可能性に驚かれた方も多く、オーブンソースであることからすぐに試せると大きな反響をいただきました。 最後の「Clinical Trial Transformation」は、臨床試験の業務効率化を目指したプラットフォームです。臨床開発業務はデータマネージャー、統計プログラマー、医学コーディング担当者などの各ペルソナ別の業務システムによりサイロ化が進み、進捗が見えにくかったり、ペルソナをまたいだワークフローが非効率であるといった課題があります。このソリューションでは各ペルソナ向けに最適化されたインターフェースを提供しつつも、データの一元管理と自動化されたワークフローによって業務の効率化を実現します。デモでは、複数試験の進捗状況の可視化、統計処理のためのCDASHからSDTMへのデータ変換のリネージとカスタマイズ、生成AIを活用したコーディング支援やリスク予測などの機能を紹介しました。5月のシンポジウムで発表された米国メルク社の同様の取り組みについても紹介しました。 臨床開発の業務は複雑で作成する文書の量も多いことから、これらのデモを通じて生成AIによる効率化の可能性が高いことを感じていただくことができました。 著者について 原田 裕平 (Yuhei Harada) エンタープライズ技術本部 ヘルスケア＆ライフサイエンス部 ソリューションアーキテクト AWSでは主にヘルスケア・ライフサイエンス業界のお客様を支援をしているソリューションアーキテクトです。 中島 丈博 (Takehiro Nakajima) ハイテク＆ヘルスケア・ライフサイエンス部 シニアソリューションアーキテクト ヘルスケア・ライフサイエンスのお客様を中心にクラウド利用の技術支援をしており、ユースケースの紹介やお客様のご要望を具現化するための活動をしています。週末は旅の予定に思いを巡らせています。 松永 徹人 (Tetsuto Matsunaga) ヘルスケア・ライフサイエンス ビジネスユニット シニアソリューションアーキテクト 国内外のヘルスケア・ライフサイエンスのお客様のクラウド利用を支援しています。SIerやコンサルティングファーム、製薬企業にてライフサイエンス業界へのITサービス提供の豊富な経験があります。

国内最大規模の学習型ITカンファレンスである AWS Summit Japan が、6 月 25 日（水）、26 日（木）の二日間に渡り幕張メッセで開催されました。今年はさらにブース展示が拡充され、ヘルスケア・ライフサイエンス（HCLS）ブースでは、ライフサイエンスから３つ、ヘルスケアから２つの展示を行い、お陰様で大勢のお客様にご来場いただきました。展示内容としては、生成AIに加えてAIエージェントがより複雑で多岐にわたる業務を効率化し、さらに実験装置や医療機器などとも連携するデモを紹介しました。開催報告のブログはヘルスケアとライフサイエンスに分かれており、このブログはヘルスケアに関する報告です。ライフサイエンスに関しては こちら をご覧ください。 医療現場の DX ( スライド ) 医療現場の DX ブースでは、パブリックセクターのお客様と実際に検証を進めているソリューションを紹介しました。 生成 AI による読影レポートのサマリー 医師が読影を行う際、その患者の過去の読影レポートの記録から今回確認すべきポイントを整理するのに時間がかかっており、生成 AI によるサマリーが行えるか検証しています。患者の読影レポート一週間分を入力とし、生成 AI にて読影レポートのサマリーを生成します。患者の情報、過去の実施事項、これまでの所見時確認ポイント、診断履歴、今回の所見時確認ポイントを過去データに基づいてレコメンドするよう、生成 AI に対して、プロンプトにて指示を与えています。デモ環境には Dify を使っており、容易に検証が行える環境となっています。 音声入力による SOAP 文章 ( 医療や介護現場で患者の情報を記録するフォーマット ) 生成 医師は患者を診察した後、電子カルテに診療録を記載するのに多くの時間がかかっており、診察時の音声から生成 AI を使って診療録のドラフトが作成できないかを検証しています。音声から Amazon Transcribe による文字起こしを実施し、SOAP ( Subject、Object、Assessment、Plan)  文章を生成するデモアプリケーションを開発しました。医師と患者のマイクを別々に設定することができ、医師と患者の会話をリアルタイムに分離、文字起こしすることができます。医師、患者の分離を最初から行うことができるため、会話の途中でも、SOAP 文章やフォローアップ文章を生成することができます。また、完成した SOAP 文章から、候補となる ICD10 コード ( WHOが定義した国際疾病分類コード ) をリストアップすることができます。こちらは、予め Amazon Aurora に登録された ICD10 データに対してベクトル検索を実施しています。更に AWS HealthLake と統合し、患者、診察記録、観察結果等のリソースを HL7 FHIR 形式 ( 医療情報の交換を効率的に行うための国際標準規格   ) にて保存することができます。 AI エージェントによる看護業務支援 看護師は日々の患者の状態を確認し、最適な入院ベッドの選定に多くの時間を費やしています。本業務を改善するために、患者の状態を入力すると、褥瘡ガイドラインを用いて症状に応じた最適なマットレスの種類を検索、またそのマットレスの病院内空き状況を確認した上で、推奨マットレスを回答するエージェントを開発しました。 Amazon Bedrock Knowledge Base を使い、褥瘡ガイドラインに対してベクトル検索を実施、デモ用にベッド空き状況を Amazon DynamoDB に保存し、検索用の AWS Lambda を Amazon Bedrock Agent で呼び出しています。ユーザインターフェースには、 Generative AI Use Cases (GenU) を利用しました。 生成 AI によるデータ分析 健診センターでは健診事業拡大へ向け様々なデータ分析を行っていますが、データ集計や可視化に多くの時間を費やしています。分析の効率を向上させるために、健診センターの実績ダッシュボードを Amazon QuickSight  にて作成、そこから Amazon Q in QuickSight の 3 つの機能（ データストーリー、データ Q&A 、シナリオ ) を使い、健診事業拡大へ向けた様々な戦略検討を行っています。まずは、 データーストーリー を使い、全体的な傾向を把握、そこから地域に着目し、 データ Q&A を使って特定地域のオプション健診平均単価から、テコ入れすべき健保を割り出します。最後に シナリオ を使い、テコ入れすべき施策の詳細分析を実施していきます。 生成 AI による医療求人マッチング 医療現場では求人と職員のミスマッチが大きな課題となっています。本課題への対策案の 1 つとして、医療系求人情報をベクトル化して保存、応募者のプロフィール情報を基に精密なマッチングを行い、推薦求人をリストアップしてくれるデモアプリケーションを開発しました。非構造データを含む求人データは、10 個のエンティティを LLM により抽出、ベクトル化して保存しています。そして、応募者プロファイルから 10 個のエンティティを LLM により抽出、カテゴリごとの重み付け ( 例えば、職種、資格の優先度を上げる ) を実施した後、求人データとの類似度を計算し、スコアの高い順に推薦求人を表示します。アプリケーション開発には、 Amazon Q Developer を使っています。 医療機関や、ヘルスケア関連企業のお客様にデモを見て頂き、医療現場の業務に対して、生成 AI の活用が有効であることを感じてもらうことができました。 生成 AI による医療データ利活用 （ スライド ） 生成 AI による医療データ利活用ブースでは、医療関係のお客様が医療情報や医用画像で抱える課題に対する、生成 AI デモを紹介しました。 医療業界では、データの標準化と活用において重要な課題を抱えています。デジタルで蓄積された医療データは、施設やベンダごとに形式が異なり、医療データ交換の標準である  HL7 FHIR  への変換には多大な労力を要します。また、画像診断装置の高度化に伴う画像検査の頻度や撮影枚数による医師の読影負担の軽減など、増え続ける診療情報の有効活用や効率的なデータ活用のための技術革新と運用改善が求められており、以下のような課題があります. 医療データの構造化／標準化 医療現場ではデジタルの普及により大量のデータが蓄積されていますが、データの多くが独自形式でシステム内に保存されており、施設内と施設間での相互運用性に課題があります。特に診療記録の自由記述やベンダシステムのデータ形式の違いが、 FHIR 等の国際標準規格への変換を困難にしています。効率的な医療サービスの提供や臨床研究の推進のため、データの構造化・標準化の実現が急務と言えます。 専門性の高い画像診断技術 医用画像診断技術の発展により、より詳細な病変の検出が可能となっていますが、画像の解釈には高度な専門知識と経験が必要です。 CT や MRI の画像データは、検査あたりの画像枚数が膨大であり、放射線科医の読影レポート作成業務にかかる負担が増大しています。 AI 技術の導入により診断支援システムの開発が進んでいるものの、手技や部位により解釈の精度にばらつきがあり、より幅広いモデル開発が進められています。 医療データを活用するツール 医療データの活用ニーズが高まっている一方で、医師や研究者が容易にデータを分析・活用できるツールを開発するプログラマが不足しています。特に臨床研究や診療支援において、データの可視化や統計解析を実現するプラットフォームの整備が求められており、医療特有の複雑なデータ構造や用語体系に対応し、かつセキュリティを担保した分析環境の構築が課題です。 デモの構成は以下のような流れとなります。「血液検査装置」と「画像検査装置」で出力した検査結果を患者管理システムからクラウドの  Amazon S3 に独自フォーマットのままデータをアップロードし、  Amazon Bedrock （LLMはClaude 3.7 Sonnet）でFHIRに変換をし、 FHIR Repository である  AWS HealthLake に格納しています。 Amazon SageMaker AI  にデプロイされた胸部X線画像の機械学習モデルで画像分類を行い、分類結果を数値で出力します。その項目毎の数値を胸部X線画像と共に再度、 Amazon Bedrock に元データとして渡し、読影レポートドラフトを作成し FHIR に変換し、 AWS HealthLake に格納します。患者情報、血液検査情報、画像検査情報、読影レポートドラフトはAWS HealthLakeに一元管理されます。  Amazon Q Developer  などの AI コーディングエージェントを活用して自然言語で開発された、ブラウザベースのアプリケーションであるマトリックスビューワでは、それらFHIRによる医療データを検索、表示することができます。また、チャットによる対話で「XXさんの過去の検査履歴を表示してください」等の質問には血液検査と画像検査双方のデータに基づく回答が得られます。 <Fig.1 デモの構成図> <Fig.2 アーキテクチャー図> ①独自フォーマットのデータからFHIRへの変換では、従来のルールベースのマッピングによる実装ではなく、生成 AI /LLMを用いてFHIRマッピングをしています。プロンプトエンジニアリングで、日本におけるFHIR拡張である JP Core を参考に、FHIRのリソースを選択しています。血液検査情報を構成する「Patient」、「Observation」と「ServiceRequest」にマッピングを行い、画像検査情報を構成する「Patient」、「ServiceRequest」、「ImagingStudy」と「Media」にマッピングを行っています。レポートドラフトの所見と診断も「DiagnosticReport」にマッピングします。 <Fig.3 患者・検査情報・画像の FHIR マッピング自動化> ②読影レポートドラフト作成では、胸部単純X線画像を直接LLMに入力しても、学習していない画像に対して、十分な精度による画像診断を行うことはできません。そこで、胸部単純X線画像の事前学習済みモデルを提供するオープンソースライブラリの TorchXrayVision を用いて、肺炎の検出や胸部疾患の分類を行っています。その分類結果を元にLLMがレポートドラフトを作成しています。 <Fig.4 生成 AI を活用した読影レポートドラフト作成> ③自然言語によるアプリケーション開発では、 Amazon Q Developer とオープンソースのAIコーディングエージェントである Cline  を用いています。これらを利用することで、対話的にコードの生成と補完に加え、AWSサービスの環境構築まで行うことができます。このアプリケーションでは FHIR Repository へのリアルタイムのアクセスに対応した「医療データ AI Agent Assintant」も実装されているため、新たな検査情報や処方情報などが FHIR として登録されても、柔軟に医療データを取得したり、複数の医療データから考察を得たりすることができます。 <Fig.5 自然言語によるアプリケーション構築> <Fig.6 医療データ AI Agent Assistant> ここまで3つのユースケースと解決方法を紹介してきました。会場では、「データ標準化」、「AI画像診断」、「アプリ開発」にお困りの様々な立場のお客様から強い関心をもっていただきました。ソリューションや生成AIによるそれぞれの課題解決の詳細について関心を持たれたら、 弊社営業担当もしくは AWS 問い合わせ窓口 へお問い合わせください。 著者について 松浦 靖 (Yasushi Matsuura) パブリックセクター技術本部 ソリューションアーキテクト 公共分野の医療機関やヘルスケア企業のお客様へ、クラウド活用のための技術的支援を実施しています。また、BI を活用したデータ分析に興味があり、Amazon QuickSight を活用した様々なデータ分析、解析手法に関しても支援を実施しています 窪田 寛之 (Hiroyuki Kubota) エンタープライズ技術本部 ソーシャルソリューション＆サービスグループ ハイテク＆ヘルスケア・ライフサイエンス部 ソリューションアーキテクト HL7 や DICOM の標準化活動の経験から、医療情報・医用画像を扱うお客様のクラウド利用に関する技術支援をしています。最近は新しい医療データ標準の HL7 FHIR を格納する AWS HealthLake や医用画像を格納する AWS HealthImaging などを提案しています。 松永 徹人 (Tetsuto Matsunaga) ヘルスケア・ライフサイエンス ビジネスユニット シニアソリューションアーキテクト 国内外のヘルスケア・ライフサイエンスのお客様のクラウド利用を支援しています。SIerやコンサルティングファーム、製薬企業にてライフサイエンス業界へのITサービス提供の豊富な経験があります。

本稿は、2025年3月20日に AWS for industries で公開された “ Distributed inference with collaborative AI agents for Telco-powered Smart-X ” を翻訳したものです。 はじめに 人工知能（AI）アプリケーションは、分散推論パイプラインへと進化しています。これにより、デバイスエッジからAWSクラウドまでの複数のレイヤーでモデルを実行し、遅延、帯域幅、プライバシーの最適化が可能になります。 すべての生データをAWSに送信する代わりに、協調的なAI推論は、デバイスエッジ、ファーエッジ、ニアエッジ（多くの場合5Gマルチアクセスエッジコンピューティングサイト – MEC）、およびAmazon Web Services（AWS）リージョンで実行でき、通信事業者は、AIコンピューティングハブとして重要な役割を果たします（図1）。AIおよびエージェント型ワークフローの観点から、エッジはもはや単なる受動的なデータ中継点ではなく、AIエージェントがタスクを動的にオーケストレーションし、レイヤー間で協調し、リアルタイムで推論実行を最適化するインテリジェントな意思決定レイヤーとなっています。通信事業者によるSmart-Xとは、AIによって強化され、通信ネットワークによって接続されたスマートインフラストラクチャ（スマートシティ、スマート交通など）を指します。この記事では、エッジとAWSクラウドがシームレスに共存し、多層アーキテクチャ全体に知能を分散させることで、実世界の課題に取り組む可能性について探ります。「交差点安全」問題を新たな視点で見直し、このハイブリッドアプローチがいかにより迅速で効率的なソリューションを実現するかを示します。ここで議論するアーキテクチャは、様々なSmart-Xドメインに広く適用可能です。 図1：Smart-X向けの分散コンピューティングの場所とその応用の範囲 アーキテクチャとテクノロジースタック 分散AIパイプラインを構築するには、ファーエッジ（デバイス、センサー、ゲートウェイ）からニアエッジ（Telco エッジ/MEC）を経て、AWSリージョンまでの統合されたネットワークアーキテクチャが必要です。各レイヤーには明確な責任があり、特定のAWSテクノロジーを使用します。 ネットワーキングレイヤー： ネットワークインフラストラクチャは、分散推論アーキテクチャの重要なバックボーンを形成します。それはファーエッジ、ニアエッジ、およびAWSクラウドレイヤーを、信頼性が高く、安全で、低遅延の通信経路で接続します。ファーエッジでは、デバイスは、時間的制約の厳しいAIワークロードのサービス品質を保証する専用スライスを介して5Gネットワークに接続します。これらのネットワークスライスは、帯域幅、遅延、信頼性に関する構成可能なパラメータを備えた、5Gインフラストラクチャの分離された仮想化された部分を提供します。AIハードウェアに統合された5G PCIeモジュールは、10ms未満の応答時間で超高信頼性低遅延通信（URLLC）を可能にします。これは、交差点監視などの安全が重要なアプリケーションに不可欠です。ファーエッジとニアエッジの間では、プライベートネットワークアクセスポイント名（APN）が、機密性の高いビデオデータを公共インターネットへの露出から保護する安全なトンネルを確立します。一方、 AWS Outposts Service Linkは、オペレーターのニアエッジデプロイメント（AWS Outpostsファミリー）と AWSリージョン サービス間のプライベート接続を作成します。この接続ファブリックは、最適化されたルーティングパスを通じて、コントロールプレーンメッセージ（低帯域幅のデバイス管理とモデルアップデート）とデータプレーンのトラフィック（高帯域幅のビデオストリームと推論結果）の両方をサポートします。 AWS IoT Core は、永続的な双方向接続のためのMQTT over WebSocketsを備えたメッセージングバックボーンを提供し、短い接続の中断が発生した場合でもセッション状態を維持します。ネットワークパス全体で、 AWS IoT Device Defender による相互TLS認証と証明書ベースのID管理によるエンドツーエンドの暗号化が実装され、承認されたデバイスのみが推論パイプラインに参加できるようになっています。さらに、ネットワークテレメトリは、 Amazon CloudWatch および AWS IoT SiteWise を通じて継続的に監視され、トラフィックパターンのリアルタイム最適化と、推論遅延や信頼性に影響を与える可能性のあるボトルネックの予防的特定を可能にします。この複数レイヤーのネットワーキングアプローチは、主要な交通事故や自然災害時のネットワーク輻輳などの困難な条件下でも、スマート交差点安全システムが動作し続けることを確保する回復力のある基盤を作成します。 図2：ネットワーキングとテクノロジースタックを示す機能アーキテクチャ ファーエッジレイヤー： これは、データが生成される場所です。たとえば、交差点にあるIPカメラやスマートセンサーなどです。これらのデバイスは、CPUおよびGPUハードウェアの異種アーキテクチャを使用してオンボードAI機能を活用し、オーディオ、ビデオ、画像理解にわたるマルチセンサー処理を可能にします。ベンダーの多様性を持つ共有インフラストラクチャを採用することで、このアプローチは、さまざまなハードウェアプラットフォームにわたるスケーラビリティ、柔軟性、相互運用性を保証します。オンボード視覚言語モデル（VLM: Vison Language Models）は、ビデオフィードで直接実行され、シーンをリアルタイムで解釈します。つまり、カメラは、現場で数ミリ秒以内に車両、歩行者、または異常を検出できます。ファーエッジデバイスは、AWS接続なしで単純な推論またはコマンドアンドコントロールタスクを実行するための反射エージェントも実行します。これらのモデルは、デバイスのコンピューティング/メモリ制約内で動作できるように、エッジ展開用に最適化されています（量子化やモデル蒸留などの技術を通じて）。この記事は、コンピュータビジョンのより広範な問題を解決することを目的としていません。オブジェクトの動的性質、オクルージョン、2Dビジョンベース推論の制限により、衝突検出が本質的に困難であることを認識しています。 ニアエッジ（Telcoエッジ/MEC）レイヤー： サービスプロバイダーのエッジ（多くの場合、5G マルチアクセスエッジコンピューティングサイト（MEC）サイト）は、中間レイヤーとして機能します。このニアエッジレイヤーは、AWS Outpostsファミリーなど、オンプレミスにデプロイされたAWSコンピューティングノードで構成されます。アーキテクチャでは、ニアエッジノードは、都市全体のビューを取得するために複数のカメラからのフィードを集約したり、高度なマルチモーダルモデルを実行するなど、ファーエッジレイヤーでは負荷がかかりすぎる重いAIタスクを実行します。AWS のサービスは通信事業者のエッジにまで拡張され、 AWS IoT Greengrass コンポーネントが、ローカル推論の調整とデータのキャッシュを行います。AWS IoT Greengrassフレームワークにより、小規模言語モデル（SLM：Small Language Models）および AWS Lambda 関数をエッジハードウェアで直接デプロイおよび実行できます。これによってMECサイトでは、最小限の遅延でロジックを実行することが可能になります。ニアエッジは、コラボレーションポイントとして機能します。複数のファーエッジハードウェアからアラートまたはデータを受信し、検証（より大きなVLMモデルを使用した二次的な衝突検出）を実行し、必要かつ高度な情報のみをAWSリージョンに転送します。 AWSリージョン： AWSリージョンは、システムの中央の頭脳および長期リポジトリです。高度なAIサービスと連携ロジックをホストし、知覚後の分析と意思決定を実行します。これには、リアルタイムアラートのストリーム処理、モデルの微調整のバッチ処理が含まれ、外部システム（ダッシュボードと緊急サービス）と統合するためのREST APIが公開されます。AWSリージョンは、 Amazon Bedrock および Agents for Bedrock を介したプライマリオーケストレーションを担当します。Amazon Bedrockは、インフラストラクチャを管理する必要なく、 Amazon Nova などのAWSからの大規模な基盤モデル、および主要なプロプライエタリモデルとオープンソースモデルへのアクセスを提供します。Amazon Bedrockの上で、エージェント機能により、異なるモデルとAPIを呼び出してタスクを計画および実行できる自律AIエージェントを作成できます。これらのエージェントは、大規模言語モデル (LLM: Large Language Models)を使用して目標を解釈し、ツールまたは他のモデルを呼び出してそれらの目標を達成します。設計では、AWS上のAmazon Bedrock Agentが、ファーエッジとニアエッジからの結合された入力を分析するコーディネーターAI（プライマリオーケストレーター）として機能します。エージェントは、外部APIまたはAWSサービスを呼び出すことによって、より多くのコンテキストを照会します。これにより、アラートのトリガーやモデルの更新など、高レベルのアクションを決定します。 交差点安全ユースケースの実装 交差点は、依然として道路上で最も危険な場所の1つです。数十年にわたる研究とパイロットプログラムにもかかわらず、交差点の安全性は、受動的な / 遅い介入、限られた検知と監視、路側無線装置（RSU）の不均一な展開、資金調達のハードル、およびレガシーシステムの技術的な制限により、依然として差し迫った課題です。より安全な交差点のための構成要素は存在しますが、これらの課題により、広範な実装が停滞しています。AWSとTCSは、「交差点安全」問題を再考するために提携し、ハイブリッドアプローチが既存の分散インフラストラクチャとAIエージェントを使用して、より迅速で効率的なソリューションをどのように実現するかを実証しています。 これを具体的にするために、協調AIエージェントによる分散推論が、現実世界のスマートシティ/交通ユースケースである交差点安全システムをどのように強化できるかを説明します。カメラと接続されたインフラストラクチャが実装され、衝突を防止および対応するために連携する、交通量の多い都市部の交差点を考えてみましょう。左折衝突を描いた30秒のサンプルビデオを使用します（図3）。 図3：視認性の高い交差点での左折衝突 エッジ処理はRSUから始まり、カメラがリアルタイムの交通データを収集します。RSUは、IPカメラ、LiDAR、レーダー、V2X通信モジュールなどの複数の検知およびコンピューティング機能を統合して、状況認識を向上させるインフラ構成要素として機能します。CPU/GPU駆動のローカル推論は、衝突などの重大なイベントを検出します。検出されると、オンボード反射エージェントがアクションをトリガーし、インシデントデータをMQTT経由でAWSリージョン内の自律エージェントオーケストレーターとニアエッジの半自律エージェントに送信します。次に、インシデントの処理済みビデオデータは圧縮され（H.265エンコード）、さらなる分析のためにニアエッジ（モバイルコアデータセンター）に送信されます。ニアエッジでは、5Gコントロールプレーンとユーザープレーン機能（UPF）により、RSUとAWSサービス間の低遅延接続が保証されます。AWS Outpostsで実行されている半自律エージェントは、受信メタデータを処理し、より高性能なSLMによって計画された一連のタスクを通じてイベント検出を強化します。オンボードVLMは、ローカルの意思決定をさらに改善し、誤検知を減らし、検出の精度を向上させます。メタデータは、コンプライアンスのためにローカルデータベースに保存されます。より多くのコンテキストが必要な場合、エージェントはAWSリージョンのプライマリエージェントオーケストレーターをトリガーします。ここでは、Amazon Bedrock AgentsとLLMが、交通事故に関するより広範なコンテキストを持つ高度なメタデータを受信します。 Amazon Kinesis Video Streams は、リアルタイムのビデオ取り込みを管理し、 Amazon S3 に匿名化された映像を保存して、より詳細な分析を行います。AWS IoT CoreとAWS IoT SiteWiseは、フリート管理、モニタリング、デバイスオーケストレーションを可能にし、プライベートエンドポイントは、ニアエッジとAWSリージョン間の安全で低遅延の接続を保証します。 図4：インテリジェントな交差点安全のためのエンドツーエンド分散推論アーキテクチャ このセクションでは、分散推論ロジックと、このユースケースのマルチエージェント連携ワークフローについて説明します。 1. ファーエッジ推論: カメラはビデオをRSUにストリーミングし、VLM推論がインシデント（衝突、動作不能な車両、違法駐車、破片、またはくぼみなど）を検出し、インシデントデータをJSONとして、保存された画像/ビデオキャプチャとともに生成します。次に、データは、オンボード反射エージェントに送信されて即時処理が行われると同時に、さらなる分析と応答調整のためにTelcoエッジとAWSリージョンにも送信されます。 a. 単純反射エージェント: インシデントデータは、推論のためにオンデバイスSLMによって駆動される単純反射エージェントをアクティブにします。これは、「if-condition, then-action」ロジックに従う静的エージェントワークフローです。受信コンテキスト（インシデントデータ）をスキャンし、固定ガイドライン（検出精度 > 60％）と比較し、事前に決定されたアクション（緊急派遣通知）を実行します。まだ実装されていませんが、V2Xを介して近くの接続された車にアラートを直接ブロードキャストしたり、交差点の信号機を管理したりできます。 2. ニアエッジ推論: Telco エッジは、受信画像とビデオフィードをインシデント通知とともに受信し、都市全体の視点のために複数のカメラからのデータを集約します。より大きなVLMを使用して、通知の精度と報告された衝突の重大度を検証します。近くの交差点デバイスを参照して、道路状況、交通パターン、および発生しているインシデントを検出し、リアルタイムモニタリングを開始します。 a. 半自律エージェント: Telco エッジは、半自律エージェントの推論を強化する、より高度なSLM/LLMを備えており、意思決定を強化するためにヒューマンインザループ検証を組み込んでいます。これは、意思決定にメモリを使用する目標ベースの推論エージェントです。複数のファーエッジデバイスからのインサイトを集約し、必要な、高度な情報のみをAWSリージョンに転送することで、複雑なシナリオを処理できます。その目標追求の性質により、予想される道路閉鎖、輻輳レベル、および近くの交差点での信号機の状態を推測できます。 3. AWSリージョン推論: AWSリージョンは、エッジデバイスをAWSサービスに接続し、強力なハイブリッドアーキテクチャを作成することにより、集中制御、連携、スケーラビリティを可能にします。AWSリージョンに集約されたデータは、交差点安全マップ、オンデマンドビデオアクセス、およびアラート概要を提供します。さらに、既存の都市交通管理システムと統合されています。また、知覚後の分析と情報に基づいた意思決定のための連携ロジックも含まれています。 a. 自律エージェント: Amazon Bedrockを搭載したAWSリージョンベースの自律エージェントは、プライマリオーケストレーターとして機能します。可能な限り最良の結果のためにトレードオフを評価することにより、学習エージェントを使用して意思決定を最適化します。AWSリージョンのLLMによって駆動されるエージェントは、インタラクションから継続的に学習して、時間の経過とともにパフォーマンスを向上させます。さまざまなモデルとAPIを呼び出すことでタスクを計画および実行し、ファーエッジデバイスとニアエッジデバイスの両方からの結合された入力を分析します。外部APIとAWSサービスにコンテキストインサイトを照会し、緊急アラートのトリガー、インシデントのクリアランス時間の推定、および公的通知の発行などの高レベルのアクションを可能にします。 図5：交差点安全のためのエージェントワークフロー さまざまなフレームワークにわたるLLM搭載エージェント間の相互運用性は、標準化された通信レイヤーを作成し、エージェント間のコンテキスト共有を可能にするエージェントプロトコルを通じて実現できます。これにより、構造化データと非構造化データの両方にアクセスして処理し、外部サービスと対話し、適応可能で連携的なAIエコシステムのために効率的に意思決定を調整できます。自律エージェントの実行は、長期実行型、バースト性、および場合によっては信頼性の低い性質により、インフラストラクチャの課題をもたらします。これらのエージェントは、動的なワークロードを処理し、信頼性を維持するために、スケーラブルなコンピューティングリソースを必要とします。AWSは、オンデマンドスケーリング、フォールトトレランス、および分散処理を提供することで、これらの課題に対処し、自律エージェントを実行するための理想的な環境にしています。AWSインフラストラクチャを活用することで、分散推論アーキテクチャはワークロードを効率的に管理し、リアルタイムの意思決定のための継続的な運用と適応的なリソース割り当てを保証できます。エージェントAI通信は、API、イベント駆動システム、ダイレクトメッセージング、連合学習、知識グラフ、ブラックボード、およびブロックチェーンを通じて行うことができます。最適なアプローチは、エージェントの役割、リアルタイム処理の要件、およびセキュリティの考慮事項によって異なります。 再考された交差点安全ユースケースは、分散AI推論のパイプラインを示しています。即時の知覚と瞬時の物理的アクションのためのファーエッジコンピューティング、簡潔なアラートを伝達する通信ネットワーク、および多面的な応答を調整するAWSリージョンのAIエージェントです。この種のシステムは、効果的にAI搭載の24時間365日の交差点守護者を作成し、衝突を予測、防止、および対応できます。AWS IoT CoreとGreengrassを使用すると、エッジコンポーネントとAWSコンポーネントが確実に同期され、断続的な接続下でも通信できます。一方、Amazon Bedrock Agentsは、従来は直接センサーネットワークであったものに高度な推論をもたらします。このオンサイト認識とAWSクラウドインテリジェンスの融合により、緊急対応時間を劇的に短縮し、事故後の交通の流れを改善し、最終的には人命を救うことができます。 今後の展望 交差点は、ネットワークの拡張になり、通信事業者はそれらをサポートするための統合サービス（接続とエッジコンピューティング）を提供できます。これらは、AI交差点システムに必要な結合組織と分散コンピューティング環境を提供します。これらは、超低遅延リンク（5G/光ファイバー/衛星経由）とエッジコンピューティングノード（MEC）を提供して、リアルタイムの都市全体へのデプロイメントを可能にします。マネージドサービスとネットワークAPIを提供することで、通信事業者は採用を加速できます。その結果、都市はこれらの複雑なネットワークを自ら構築または統合する必要がなく、サービスに加入できます。 交差点にエッジAIをデプロイするには、都市が管理できる、堅牢で安全な、耐候性のあるインフラストラクチャが必要です。既存の筐体（デジタルキャビネット）は、洗練されたコンピューティングを街角に配置することを可能にする保護ハウジングとして機能でき、環境要因や故意に物を壊す人により安全ミッションが損なわれないことを確保します。物理的およびサイバーセキュリティに最初から対処することで（耐候性筐体、バックアップ電源、改ざんアラーム、安全なアクセス制御）、都市と通信事業者は、ダウンタイムや侵入のリスクを最小限に抑えて、多くの交差点にAIハードウェアを自信を持って展開できます。 AWSの接続性は、エッジベースの交差点安全システムの機能を飛躍的に強化します。各交差点をAWSコントロールプレーンに接続することにより、統合管理、集合学習（各交差点がシステム全体の改善に貢献）、および他のサービスとの統合を実現します。 AWS Outposts Family 、 AWS Local Zones 、 AWS Wavelength から、さらにはIoTやAI管理サービスなどのAWSインフラストラクチャは、このような接続されたアーキテクチャを構築するためのツールキットを提供します。その結果、レジリエントでスケーラブルなスマート交差点のネットワークが構築され、街路レベルではミリ秒単位の応答が可能になり、都市レベルではAWSクラウドのインテリジェンスを活用しながら、IoTデバイスの群れのように容易に管理できるようになります。 分散推論の将来は、複雑なマルチノードAIインフラストラクチャをローカルに感じさせるソフトウェア抽象化を提供することにより、エンジニアの開発を簡素化することにもあります。開発と移行の複雑さを軽減することで、開発者は基盤となるハードウェアを気にせずに自律エージェントを構築およびデプロイできます。このアプローチにより、CPU、GPU、およびNPU全体で異種コンピューティングが可能になり、ベンダーロックインを回避しながら、市場投入までの時間を短縮し、より幅広い採用を保証します。標準化されたAPIとAWSクラウドネイティブフレームワークは、スケーラビリティと相互運用性をさらに推進し、AIデプロイメントをよりアクセスしやすく、効率的にします。 結論 協調AIエージェントによる分散推論は、スマートシティ、スマート産業、つまりローカルアクションとグローバルインテリジェンスが連携する必要があるすべての「Smart-X」シナリオで、次世代アプリケーションを可能にする強力なアーキテクチャパターンです。AWS、エッジサービス、および通信ネットワークを使用することで、開発者と設計者は、高速でインテリジェントでスケーラブルなシステムを構築できます。重要なのは、適切なAI機能を適切な場所に分散させることです。今後、設計者は分散を考慮して設計する必要があります。遅延のために重要な推論をエッジにプッシュし、集約された学習のためにAWSクラウドを使用し、エージェントを使用してすべてを結び付けます。これにより、Smart-Xソリューションの可能性を最大限に引き出し、技術的なパフォーマンスの向上だけでなく、接続された世界での安全性、効率、および生活の質の具体的な改善も実現できます。AIの未来は分散型かつ協調型であり、エッジとAWSクラウドの相乗効果によって実現されます。そして、それは私たちの目前に迫った魅力的な未来なのです。 TCS — AWSパートナーの紹介 「企業は、デバイス、エッジAIインフラストラクチャ、通信データセンター、およびクラウド間のシームレスな統合を提供する、真のAIエコシステムの適応性を必要としています。データを自律的に処理し、他のAIエージェント、モデル、およびエンタープライズアプリケーションと連携するエッジのAIエージェントは、リアルタイムのビジネスアプリケーションを多数実現します。分散推論の採用は、最適化されたコストとパフォーマンスで効率的でスケーラブルなデータ処理への道を開きます」– Sujatha Gopal、CTO – Communications Media & Information Services Business Group、TCS TCSは、AWSアドバンストテクノロジーパートナーおよびAWSコンピテンシーパートナーであり、インドに本社を置き、55か国で事業を展開し、さまざまな業界の企業にデジタルトランスフォーメーションおよびテクノロジーサービスを提供することで知られる、ITサービス、コンサルティング、およびビジネスソリューションを提供しています。 その他のリソース TCSへの問い合わせ パートナー概要 AWS Marketplace   Subhash Talluri Subhash Talluriは、AWSのテレコム業界ビジネスユニットのリードAI/MLソリューションアーキテクトです。彼は世界中のテレコム顧客とパートナー向けの革新的なAI/MLソリューションの開発をリードしています。彼は、AWSでクラウド最適化アーキテクチャを通じてスケーラブルで安全かつコンプライアントなAI/MLソリューションの構築を支援するために、エンジニアリングとコンピューターサイエンスの学際的専門知識を提供しています。 Ajay Rane Ajay Raneは現在、Amazon Web ServicesのWW IoTビジネス開発責任者です。彼のチームは、主要な通信サービスプロバイダーと協力してIoTビジネスを変革し、成長を促進しています。Ajayは、イノベーションを通じて価値を提供する実績を持つ、電気通信および半導体業界の顧客志向のベテランです。以前、AjayはSigfoxでビジネス開発担当VPとしてIoTエコシステムパートナーを管理し、MBit Wirelessでマーケティングおよびビジネス開発担当VPとしてLTEチップセットの製品管理をリードしました。Ajayは、11年間にわたってフラッシュメモリ、サーバー、WiMAX、Wi-Fiビジネス内で責任を増大させる職位を歴任したIntelでキャリアをスタートしました。 Awaiz Khan Awaiz Ahmad Khanは、UMTS、LTE、LTE-A、CBRS、5Gにわたる15年以上のRANアーキテクチャ、プライベート5G、スペクトラムイノベーションの経験を持つワイヤレステクノロジーリーダーです。彼は、CBRSと共有スペクトラムモデルを活用して、企業および産業アプリケーション向けのプライベート5Gソリューションの開発において重要な役割を果たしました。AwaizはWin Forumの積極的な貢献者であり、スペクトラム共有フレームワークと相互運用性標準の形成に携わりました。CI/CD自動化、AI駆動RAN最適化、クラウドネイティブ展開における彼の仕事は、複数の業界賞とワイヤレステクノロジーの特許を獲得しています。彼は電気工学の修士号と学士号を取得しています。 Jad Naim Jad Naimは、大規模WANの構築から世界中のモバイルオペレーター向けのOSSおよび計画プラットフォームの設計と実装まで、18年以上の電気通信経験を持っています。AWSでは、Jadはプライベート5Gネットワークの展開、およびローカルブレイクアウト用のローミングゲートウェイに焦点を当てています。JadはIoTと、安全性を向上させ、怪我を防ぐための洞察を提供するためにエッジでインテリジェンスを注入する方法に焦点を当てています。 Ravi Devarasetti Ravi Devarasettiは、TCSの通信・メディア・情報サービス事業グループのCTOオフィスにおいて、新興技術とイノベーション憲章をリードするコンサルティングパートナーです。Raviは通信・IT分野で25年以上の経験を持ち、米国およびヨーロッパの複数のCPSとMSOに対してアーキテクチャ、コンサルティング、E2Eソリューションエンゲージメントに取り組んできました。Raviは、パイロット実行、実現可能性、ビジネスケース準備中の革新的な設計思考を通じて、技術活用と孵化の初期段階で顧客と関わります。彼は革新的技術を成功したビジネスに転換し、エコシステムとパートナーシップを構築することに長けています。彼はOpen Groupのメンバーであり、AEA Coloradoチャプターの議長を務めています。新興技術愛好家を超えて、彼は旅行と新しい場所の探索を愛しています。 この記事はアマゾン ウェブ サービス ジャパンの渡部 勝博が翻訳を担当しました。

本記事は 2025/07/03に投稿された SQL to NoSQL: Modeling data in Amazon DynamoDB を翻訳した記事です。 翻訳はソリューションアーキテクトの Kenta Nagasue が担当しました。 この投稿では、既存のデータベース構造とアクセスパターンを分析した パート1 の内容を基に、効果的な Amazon DynamoDB データモデルの設計に焦点を当てます。DynamoDB は、アプリケーションの特定の要件と使用パターンに合わせた異なるデータモデリングアプローチを提供しています。 適切に設計されたデータモデルは、DynamoDB における最適なパフォーマンスとコスト効率をサポートします。ソーシャルメディアプラットフォームの例を通じて、異なるモデリングアプローチがアプリケーションのパフォーマンスと運用コストの両方にどのような影響を与えるかを示しています。 この投稿では、エンティティの特定、テーブル設計の決定、リレーションシップのモデリングアプローチなど、DynamoDB のデータモデルを設計するための戦略について説明します。特定のシナリオを使用してさまざまなモデリング手法を比較し、ユースケースに応じた適切な判断を行えるようにします。 エンティティの特定 DynamoDB のアイテム、属性、および対応するデータ型を定義します。これらは一般的に既存のデータベーススキーマと一致しているはずですが、DynamoDB のモデリングパターンに合わせて調整してください。現在のスキーマ構造を正確に反映させるのではなく、アプリケーションのアクセスパターンに合わせて最適化することに重点を置いてください。以下の点を考慮してください： コアエンティティ – アプリケーションがデータにアクセスし管理する方法に基づいて、主要なビジネスエンティティをリストアップします。例えば、ソーシャルメディアアプリケーションの場合、投稿、ユーザー、コメントなど、アプリケーションが頻繁に操作する中心的なデータ要素を表すエンティティが含まれます。 サポートエンティティ – アプリケーションの機能をサポートするために必要な追加エンティティを特定します： メトリクスやカウントを追跡するためのエンティティ アプリケーションの状態を管理するためのエンティティ 特定のアクセス要件をサポートするためのエンティティ 属性 – 各エンティティについて、既存のテーブル構造ではなく、アプリケーションのニーズに基づいて必要な属性をリストアップします。アプリケーションにおける属性の特性、データ型、使用方法を理解することで、DynamoDB での表現方法を計画するのに役立ちます。例えば、日時フィールドは、クエリとソートの要件に基づいて、ISO 文字列またはエポック番号のいずれかにマッピングする必要があります。 テーブル設計の決定 DynamoDB のアイテムを特定した後、シングルテーブル設計とマルチテーブル設計のどちらを使用するかを評価しました。多くのアプリケーションでは、実装が簡単なマルチテーブル設計から始めることをお勧めします。しかし、私たちのソーシャルメディアアプリケーションでは、要件分析に基づいてマイクロサービスごとにシングルテーブル設計を選択しました： アプリケーションの特性 – データの関連性が非常に高く、関連アイテムを一緒に取得する必要が頻繁にあります。例えば、投稿を表示する際には、同じ操作で関連するコメントとユーザー詳細を取得する必要があります。アプリケーションは主にトランザクションデータを扱い、監査、履歴、分析データの量は多くありません。これらの特性は、自然とシングルテーブルアプローチと適合しています。 パフォーマンスとコストの分析 – シングルテーブル設計では、すべてのデータが 1 つのテーブルに格納されるため、関連アイテムを含む複雑なクエリに対して一貫したパフォーマンスを提供します。キャパシティ管理については、自動スケーリングと簡素化された運用により、ほとんどのワークロードで推奨されるオンデマンドモードで開始しました。使用パターンを分析し、予測可能なワークロードを確立した後、コスト最適化のためにプロビジョンドモードを評価しました。シングルテーブル設計における関連データアクセスの統合されたキャパシティプランニングと効率的な RCU/WCU の割り当ては、プロビジョンドモードのメリットを最大限に活用するのに役立ちました。ストレージの観点からは、データの特性上、テーブル分割することに対して正当化するような顕著な非効率性はありませんでした。 運用上のメリット – サービスごとに単一のテーブルを管理することで、監視、キャパシティプランニング、データモデルの発展が簡素化され、運用上の作業負荷が削減されました。 テーブル設計の選択による影響は、アクセスパターンとデータ特性によって異なります。ユースケースにおけるパフォーマンスとコストへの影響を正確に評価するため、両方のアプローチを代表的な処理量でテストすることをお勧めします。詳細については、 Amazon DynamoDB におけるシングルテーブル vs マルチテーブル設計 をご参照ください。 パーティションキーとソートキーの定義 SQL クエリ分析から得られた知見を使用して、データの主要なアクセスパターンを特定します。これにより、DynamoDB テーブルの適切な パーティションキー を決定するのに役立ちます。SQL クエリの ORDER BY 句と TOP 句から得られた情報を使用して、複数レベルでのソートが必要な場合には対応する複合ソートキーの使用をするなど、ソートキーの選択を行います。 エンティティ関係のモデリング DynamoDB の柔軟なスキーマは、従来のリレーショナルデータベースとは異なるアプローチを可能にしますが、DynamoDB におけるデータモデリングの戦略とその最適な戦略の評価方法について、いくつか検討する価値があります。 単一アイテム DynamoDB の単一アイテムアプローチは、エンティティと関連データが 1 つのアイテム (最大 400 KB) に収まる場合に効率的です。このモデルでは、関連するデータをすべてまとめて保存することで、高速な読み取りが可能になります。ただし、このアプローチは書き込み操作に影響を与えます。変更を加えるたびにアイテム全体を更新する必要があり、書き込みコスト (WCU) が増加します。書き込みの頻度が高くなるほどコストが上がり、データの整合性を維持する複雑さも増します。このアプローチは、親データと子データが同時にアクセスされることが多く、読み取りコスト (RCU) の削減メリットが書き込みコストの増加を上回るような、読み取り量の多いアプリケーションに特に適しています。子データの読み取りと書き込みの比率を評価し、メリットがデメリットを上回ることを確認することが重要です。 単一アイテム内の子アイテムコレクションのフィルタリングは、フィルター式またはクライアントサイドのフィルタリングでのみ可能です。ただし、DynamoDB はフィルターを適用する前にアイテム全体を読み取るため、RCU の消費量は減りません。 これらのトレードオフを理解し、アクセスパターンを慎重に評価することで、高速な読み取りと、書き込みコストの増加やフィルタリングの複雑さのバランスを取りながら、このデータモデリングパターンがユースケースに適しているかどうかを判断できます。 垂直パーティショニング DynamoDB の 垂直パーティショニング は、特定の属性に対する絞り込みクエリに有用です。このパターンでは、同じパーティションキーと異なるソートキーを持つ隣接するアイテムに関連データを保存します。 主なメリットには以下のようなものがあります: クエリの柔軟性 – 子アイテムを単独で、または親アイテムと一緒に効率的に取得できます 書き込みのきめ細かい制御 – 親アイテムを書き換えることなく、個々の子アイテムを更新できます ただし、このアプローチでは、エンティティ間のフィルタリングがより複雑になります。親と子の属性の両方でフィルタリングを行うには、一部の親の属性を非正規化して子アイテムにする必要があります。親の属性が頻繁に変更される場合、書き込みコストを増加させる可能性があります。例えば、アクティブユーザーのすべての動画投稿を検索したい場合を考えてみましょう。これには 2 種類のフィルタリングが必要です。1つはアクティブユーザー（親エンティティ）の検索で、もう1つはユーザーの投稿のうち動画であるもの（子エンティティ）の検索です。1 つの解決策は、ユーザーのステータスを各投稿レコードに直接追加して非正規化することです。これによりクエリは簡単になりますが、欠点もあります。ユーザーのステータスが変更されるたびに、そのユーザーのすべての投稿でステータスを更新する必要があります。これにより書き込み操作が増加し、結果として運用コストが上がります。このようなクエリの簡素化と書き込み効率のトレードオフは、DynamoDB の設計パターンでよく考慮される点です。 重要なのは、アクセスパターンを慎重に分析し、クエリの柔軟性、書き込み管理、エンティティ間のデータ非正規化のコストのバランスを取ることです。 ユーザーが複数の投稿を作成できるソーシャルメディアプラットフォームを想像してみてください。次の図は、ユーザーと投稿の関係を示しています。このシナリオでは、アクセスパターン、使用統計、アイテムサイズを慎重に分析することで、DynamoDB の最適なデータモデリングアプローチを決定する方法を探ります。この包括的な評価により、特にソーシャルメディアアプリケーションのニーズに合わせた、パフォーマンス、コスト効率、スケーラビリティのバランスを取る戦略を選択する際の指針になります。 アイテムサイズに関する注意事項 DynamoDB のデータモデルを設計する際は、アイテムのサイズを見積もってください。DynamoDB では 1 アイテムあたり 400 KB の制限があるため、データの平均サイズと最大サイズの両方を把握しておくと便利です。 ソーシャルメディアアプリケーションのユーザーと投稿モデルについて、以下の点を考えてみましょう： ユーザーのプロファイルデータの平均サイズを見積もります ユーザーあたりの投稿の平均数と、その一般的なサイズを計算します これらの見積もりは、意思決定の指針となります。RCU と WCU はアイテムサイズに比例するため、最適なデータモデリング戦略を設計するには、平均アイテムサイズを評価することが重要です。 アクセスパターン アプリケーションのアクセスパターンを理解することは、効率的な DynamoDB モデルを設計する上で重要です。以下の点を考えてみてください： 投稿に適用されたフィルターに基づいてユーザーを取得する必要がありますか？ 一部のクエリでユーザープロファイルデータと投稿の両方を同時にフィルタリングする必要がありますか？ ユーザーの最新 N 件の投稿への迅速なアクセスが必要ですか？ コメントの多い N 件の投稿を取得する必要がありますか？ これらのアクセス要件は、最適なパフォーマンスを実現するためのパーティションキー、ソートキー、およびセカンダリインデックスに関する決定に影響を与えます。フィルター条件は、単一アイテムアプローチの実現可能性を判断する際にも役立ちます。例えば、投稿フィルターに基づいてユーザーを特定する必要がある場合、単一アイテムアプローチは効率的ではない可能性があり、別のデータモデリングアプローチを検討する必要があるかもしれません。 使用状況メトリクス データの読み取りと書き込みのパターンを分析して、最適な戦略を決定します。読み取りと書き込みの比率を理解するために、以下の点を考えてみてください： 投稿とユーザープロファイルデータが一緒に参照される頻度はどのくらいですか？ 投稿の更新頻度は、ユーザープロファイルの変更頻度と比較してどれくらいですか？ ユーザープロファイルと投稿において、最も頻繁に変更される属性は何ですか？ 投稿カウンター（いいねやシェアなど）の読み取り頻度はどのくらいですか？ 投稿カウンターの更新頻度は、投稿コンテンツの更新頻度と比較してどうですか？ データモデリング戦略の選択 アイテムサイズ、アクセスパターン、使用状況のメトリクスに関する情報を収集したので、次のセクションでは、これらのデータポイントを使用して、DynamoDB のソーシャルメディアアプリケーションに最適なデータモデリング戦略を評価し、選択する方法を説明します。 シナリオ1 ：1 対 N の関係 次の表は、ユーザー情報 (各 20 KB) と投稿コンテンツ (各 5 KB) の 1:N の関係を、単一のアイテムとして保存した場合と垂直パーティションした場合を比較したものです。 単一アイテム 垂直パーティション 30 件の投稿のアイテムサイズ ユーザーと投稿: 20 KB + 30*5 KB = 170 KB ユーザーアイテム = 20 KB 1 番目の投稿アイテム = 5 KB 2 番目の投稿アイテム = 5 KB . . 30 番目の投稿アイテム = 5 KB ユーザー情報を含むユーザーの上位 10 件の投稿を取得するための DynamoDB API コール数: 1,000 読み取り/時間 1,000 2,000* ユーザー情報を含むユーザーの上位 10 件の投稿を読み取るための RCU (結果整合性のある読み込み): 1,000 読み取り/時間 170 KB/4 KB = 42.5 * 0.5 RCU = 21.25 ~ 21.5 RCU 1000 *21.5 RCU = 21,500 RCU ユーザー情報: 20 KB ~ 2.5 RCU 10 件の投稿: 50 KB/4 KB = 12.5 * 0.5 RCU = 6.25 RCU ~ 6.5 RCU 1000 * 6.5 RCU + 1000 *2.5 RCU = 9000 RCU ユーザーメールアドレスを更新するための WCU: 10 書き込み/時間 170 WCU (170 KB のデータを更新) 10*170 WCU = 1,700 WCU 20 WCU (20 KB のユーザーアイテムのみ更新) 10*20 WCU = 200 WCU * 必要な API コールの総数は、アプリケーションの構造、特にデータアクセスフレームワーク、DynamoDB テーブル設計、クエリパターンによって異なります。この特定のユースケースでは、前述の考慮事項により、必要なデータを取得するために読み取り操作ごとに 2 回の個別の API コールが必要です。 シナリオ2 ：1 対 1 の関係 次の表は、1 つのアイテムとして保存された投稿 (各 4 KB) と投稿カウンター (0.5 KB) の 1:1 の関係を、垂直パーティションと比較したものです。 単一アイテム 垂直パーティション 投稿あたりのアイテムサイズ 投稿 + 投稿カウンター: 1 KB + 5 KB = 6 KB 投稿アイテム = 5 KB 投稿カウンターアイテム = 1 KB 投稿カウンター付きの投稿を読み取るための DynamoDB API コール数: 1,000 読み取り/時間 1,000 2,000* 投稿カウンター付きの投稿オブジェクトの読み取り: 1,000 読み取り/時間 6KB ~ 1 RCU 1000 * 1 RCU = 1,000 RCU 投稿: 5KB ~ 1 RCU 投稿カウンター: 1 KB ~ 0.5 RCU 1000 * 0.5 + 1000 * 1 = 1,500 RCU 投稿カウンターの更新: 10 更新/時間 6 KB ~ 6 WCU 10 * 5 = 60 WCU 1 KB ~ 1 WCU 10 * 1 WCU = 10 WCU 投稿カウンターの更新: 1,000 更新/時間 6 KB ~ 6 WCU 1,000 * 5 = 6,000 WCU 1 KB ~ 1 WCU 1,000 * 1 WCU = 1,000 WCU * 必要な API コールの総数は、アプリケーションの構造、特にデータアクセスフレームワーク、DynamoDB テーブル設計、クエリパターンによって異なります。この特定のユースケースでは、前述の考慮事項により、必要なデータを取得するために読み取り操作ごとに 2 回の個別の API コールが必要です。 この分析では、DynamoDB における 1:N の関係 (ユーザーと投稿) と 1:1 の関係 (投稿とカウンター) の両方について、単一アイテムと垂直バーティションを比較しています。1:N のシナリオでは、垂直パーティションは API コール数が増加しますが、RCU/WCU のコストを大幅に削減します (読み取りの場合は 21,500 RCU から 9,000 RCU へ、書き込みの場合は 1,700 WCU から 200 WCU へ)。同様に、1:1 の関係では、垂直パーティションにより API コール数は 2 倍になりますが、特に頻繁な更新において大幅な WCU の削減 (6,000 WCU から 1,000 WCU へ) を実現します。ただし、これらの結果は、ここで議論されたユースケース特有のものであることを理解することが重要です。ここで収集したデータを異なるシナリオに適用する前に、慎重な検討することをお勧めします。 結果 評価した特定のユースケースについて、以下のことが判明しました。 1:1 の関係 (投稿と投稿カウンター): 単一アイテム設計では、読み取りの API コールと RCU が少なくなりましたが、更新時の WCU 消費が増加しました 垂直パーティション設計では、より多くの API コールが必要でしたが、特に頻繁な更新において WCU の使用がより効率的でした 1:N の関係 (ユーザーと投稿): 単一アイテム設計では、API コールは少なくなりましたが、アイテムサイズが大きくなることで RCU の消費量が大幅に増加し、更新時の WCU コストも大幅に増加しました 垂直パーティション設計では、API コールの数は 2 倍になりましたが、RCU と WCU 両方の消費量を大幅に削減でき、スケールした際の費用対効果が高まることがわかりました。 まとめ 重要なポイントは、具体的な結果だけでなく、これらの結論に至るまでの分析プロセスにあります。どのようなユースケースでも、パフォーマンスのニーズとコストに関する考慮事項のバランスを取った最適なデータモデル戦略を定義するには、同様の綿密な分析と思考プロセスが不可欠です。更新頻度、読み取りパターン、データスケーリング要件、エンティティ間の関係の特性など、さまざまな要因を慎重に評価する必要があります。 パート 3 では、アプリケーションのデータアクセスレイヤーをこれらのデータモデルで効果的に動作するように適応させ、DynamoDB の機能を活用できるようにする方法を探ります。 著者について Ramana Kiran Mannava Ramana は、AWS プロフェッショナルサービスのリードコンサルタントであり、.NET ワークロードの最新化と AWS 上のクラウドベースソリューションの構築に関する専門知識を持っています。彼はデータベース技術とクエリ最適化にも情熱を持っています。 Akber Rizwan Shaik Akber は、 AWS プロフェッショナルサービスのリードコンサルタントです。彼はクラウドベースのソリューションを使用して、お客様の .NET ワークロードを AWS に移行し、最新化するのを支援しています。 Mahesh Kumar Vemula Mahesh は、AWS プロフェッショナルサービスのリードコンサルタントです。彼はサーバーレス愛好家であり、クラウドベースのソリューションを用いて顧客の .NET ワークロードの最新化を支援しています。

はじめに ビルド、テスト、デプロイのプロセスを自動化することは、モダンなソフトウェア開発とデリバリーの基本的な要素です。継続的インテグレーション (CI)、継続的テスト (CT)、継続的デプロイ (CD) の強力なパイプラインを実装することで、組織は効率を高め、市場投入までの時間を短縮します。 このブログ記事では、柔軟な環境でコンパイルと機能同等性テストを自動化する継続的インテグレーション、継続的テスト、継続的デリバリー (CI/CT/CD) パイプラインを紹介します。これにより、本番環境にあるようなプレッシャーや制約を受けることなく、問題を特定し、アプリケーションのコア機能を検証することができます。検証後、パイプラインはマネージド環境にアプリケーションをデプロイし、受け入れテストや本番稼働前の動作確認を行います。 AWS Blu Age でリファクタリングされたアプリケーションに対する CI/CT/CD の実装 CI/CT/CD を実装すると、ソフトウェア開発とデプロイプロセスに付加価値が組み込まれます。その価値は、ソフトウェア開発ライフサイクルを速く回し、コード品質を向上させ、開発およびデプロイプロセスの全体的な効率と信頼性を高めることにあります。AWS Blu Age でリファクタリングされたアプリケーションは、Java Spring Boot (バックエンド) と Angular (フロントエンド) アプリケーションへの変換により、メインフレームアプリケーションをモダナイズしたものです。AWS Blu Age ツールを使用すると、COBOL、PL/I、RPG/400 で記述されたレガシーアプリケーションをモダンなアプリケーションに自動的に変換できます。このアプローチにより、既存のビジネスロジックへの投資を抑えながら、次のようなメリットが得られます。 新しいテクノロジーの使用によるアジリティの向上 モダンスタックに精通した開発者から成る幅広い人材プールへのアクセス モダナイゼーションプロジェクトの加速 リファクタリングプロセスにより、基盤となるデータベースとデータモデルが最新の形式に変換され、アプリケーションの機能と互換性が強化されます。 継続的テストの実践により CI/CT/CD パイプラインを確立することは、モダナイズされたシステムの機能をレガシーシステムと同等に保つために不可欠です。テストはモダナイゼーションプロジェクトの労力と予算の 60 ～ 70% を消費する可能性があるため、ビジネス価値を迅速に実現するためにはテストの自動化が不可欠です。 CI/CT/CD パイプラインステージ パイプラインは次の 5 つのステージで構成されています。 アプリケーションソースコードの取得 アプリケーションビルド アプリケーションの機能同等性テスト 手動承認 マネージド環境でのデプロイ CI/CT/CD パイプラインのアーキテクチャとデプロイ 図 1 は、 AWS CodePipeline を使用してモデル化された CI/CT/CD パイプラインの 5 つのステージの概要を示しています。関連するインフラストラクチャは AWS CloudFormation によってプロビジョニングされます。 CloudFormation は、インフラストラクチャのプロビジョニング、再利用性、一貫性、信頼性を実現する強力な IaC (Infrastructure as Code) サービスです。これにより、アプリケーションの実行に必要なリソースをモデル化します。 AWS CodePipeline は、継続的インテグレーションと継続的デリバリーのサービスであり、ソフトウェアリリースプロセスをモデル化して自動化します。パイプラインはワークフローを定義し、開発段階とデプロイ段階でコード変更がどのように進行するかを記述します。パイプラインの各ステージは、コードのビルドやテスト環境へのデプロイなどの一連のアクションで構成されています。 図 1 — CI/CT/CD パイプラインのアーキテクチャ図 アーキテクチャ図に示されている各ステージのタスクについて、次のセクション以後で説明します。 ステージ 1 — アプリケーションコードの取得 前提条件 開発チーム用に Git リポジトリが作成され、設定されていること AWS Blu Age Transformation Center から生成されたアプリケーションソースコードが Git リポジトリにロード済であること AWS CodePipeline は、Git リポジトリのメインブランチへのコミット時にアクティブ化されるようセットアップと設定が完了していること 開発プロセス 開発者は Git リポジトリをローカルの開発環境に複製します。 開発者は機能やバグの修正用に新しいブランチを作成します。 開発者は、チームのコーディング標準とベストプラクティスに従って、必要なコード変更を行います。 開発者はローカルテストを実施してコードの品質と機能を確認します。 開発者は、コミットメッセージに説明を記述して、変更をローカルブランチにコミットします。 開発者はブランチを Git リポジトリにプッシュします。 AWS CodePipeline のアクティベート メインブランチにマージすると、AWS CodePipeline が自動的にアクティベートされます。 ステージ 2 — アプリケーションのビルド AWS CodePipeline は CI/CT/CD パイプラインの一部として AWS CodeBuild ステップを開始します。このステップでは、AWS CodeBuild は AWS Blu Age Build ツールを使用して、レガシー言語からの変換によってモダナイズされた Java アプリケーションをビルドします。 ビルドプロセス CodeBuild はパイプラインの前段のステージからソースコードを取得します。 CodeBuild は AWS CodeArtifact に接続して、必要な AWS Blu Age ランタイムライブラリをダウンロードします。 2 つの異なる WAR (Web Application Archive) ファイルが生成されます。 HTML、JavaScript、CSS ファイルなどの静的 Web サイトアセットで構成されるフロントエンドアプリケーション: この構造により、柔軟なデプロイオプションが可能になります。フロントエンドは Apache HTTP Server や Amazon CloudFront などのさまざまなコンテンツ配信ネットワーク (CDN) ソリューションでホストできるため、コンテンツ配信とユーザーエクスペリエンスが最適化されます。 バックエンドアプリケーション CodeBuild は WAR ファイルを Amazon S3 に安全に保存します。 このアプローチにより、フロントエンドコンポーネントとバックエンドコンポーネントを明確に分離しやすくなり、各階層の独立したスケーリングと管理が可能になります。また、フロントエンドをエッジロケーションにデプロイしてレイテンシーを短縮し、バックエンドをより制御された環境でホストしてセキュリティとデータ管理を強化することもできます。 ステージ 3 — アプリケーションの機能同等性テスト レガシーメインフレームアプリケーションと AWS クラウド上のモダナイズされたメインフレームアプリケーションが機能的に同等であることを検証するために、 AWS Mainframe Modernization Application Testing が使われます。このテストフレームワークは、モダナイゼーションプロセス全体を通じて機能の一貫性を検証するように設計されています。 前提条件 テストチームは AWS Mainframe Modernization Application Testing 内で以下のアーティファクトを作成します。 テストケース: テストアクションの最小単位です。テストケースを作成する際に、移行元のシステムと移行先のシステムの間の機能的な同等性を確認できるよう、ユーザーは比較対象のデータ型を識別します。 テストスイート: 一連のテストケースを順番に実行します。 テスト環境設定: これには、反復可能なテストを実施するために必要なすべてのパラメーターとリソースが含まれます。CloudFormation テンプレートは、テスト環境で反復可能なテストを実行するために必要な初期データおよび設定パラメーター (リソース) の設定に使用されます。このアプローチにより、テストを繰り返しても一貫性と再現性が保証されます。 テストプロセス テストプロセスには主に 3 つの段階があります。 Record ユーザーは各テストケースの参照データをメインフレーム上に作成します。 この参照データには、ソースメインフレームのアーティファクト、データセット、リレーショナルデータベースの Change Data Capture (CDC) ジャーナルが含まれます。 Record ステージは通常、プロジェクトの開始時に 1 回実行して、必要な参照データをすべて収集します。 Replay 本機能により、移行先の環境でテストスイートを実行します。 個々のテストケースで生成されたデータセット、データベース変更、3270 画面をキャプチャします。 Compare 本機能は、移行元のテストの参照データと移行先のリプレイデータを一通り比較します。 結果は、同一データ、異なるデータ、同等データ、または欠損データとして分類されます。 Compare の出力は Amazon S3 に保存され、指定された承認者による審査を受けます。 CI/CT/CD パイプラインは、Replay および Compare の各ステージを自動的に開始し、開発プロセス全体を通して一貫性のある反復可能なテストを保証します。 このテストの主な目的は、モダナイズされたアプリケーションがメインフレームアプリケーションと同じように動作することを検証することです。左記は、参照データとリプレイデータの不一致を綿密に特定することで達成されます。これにより、モダナイゼーションプロセスが確実に成功し、信頼できるものになります。 ステージ 4 — 手動承認 パイプラインの一時停止 機能同等性テストが完了すると、AWS CodePipeline は手動承認段階で自動的に停止し、本番前または承認環境にデプロイされます。 承認プロセス AWS CodePipeline は、プロジェクトマネージャ、品質保証 (QA) リーダー、個別に設定したレビュー担当者などの関係者に保留中のレビューを通知します。 レビュー担当者は Amazon S3 に保存されている比較レポートにアクセスします。これらのレポートには次のものが含まれます。 参考データ 再生データ レビュー担当者はレポートを審査して承認します。これで AWS CodePipeline が再開されます。 ステージ 5 — マネージドランタイム環境でのアプリケーションの展開 最後のステージは、承認されたアプリケーションを AWS Mainframe Modernization Automated Refactor のマネージドランタイムにデプロイすることです。AWS CodeBuild は、AWS Cloud Development Script (AWS CDK) を活用したスクリプト (Python スクリプトなど) を呼び出すために使用されます。このスクリプトは次のシナリオに基づいてタスクを実行します。 シナリオ 1: AWS Mainframe Modernization 環境が存在しないことを、AWS Systems Manager (SSM) Parameter Store を使用して確認しました。このときの AWS CodeBuild のステップ: AWS Mainframe Modernization のマネージドランタイム環境を作成し、環境 ID を SSM に保存します。 Mainframe Modernization アプリケーションを作成し、アプリケーション ID を SSM に保存します。 アプリケーションをマネージドランタイムにデプロイします。 アプリケーションを起動します。 シナリオ 2: AWS Mainframe Modernization 環境とアプリケーションは既に存在します。このときの AWS CodeBuild のステップ: 実行中のアプリケーションを停止します。 アプリケーションを更新して、AWS Mainframe Modernization マネージドランタイム環境に新しいバージョンを作成し、新しいアーカイブファイルを反映します。 アプリケーションを起動します。 環境とアプリケーションの可用性をほぼ 100% にするには、ブルー/グリーンデプロイメントを使います。ブルーは現在のアクティブなインスタンス、グリーンは新しいインスタンスを表します。テスト完了後、トラフィックはグリーンのインスタンスにリダイレクトされ、問題が発生した場合はブルーのインスタンスにトラフィックをリダイレクトしてロールバックできます。これは以下のように実装されます。 シナリオ 1: AWS Mainframe Modernization 環境が存在しないことを、SSM Parameter Store を使用して確認しました。このときの AWS CodeBuild のステップ: 2 つの AWS Mainframe Modernization マネージドランタイム環境 (ブルーとグリーン) を作成し、その環境 ID を SSM に保存します。 Mainframe Modernization アプリケーションを作成し、アプリケーション ID を SSM に保存します。 作成したマネージドランタイム環境の 1 つにアプリケーションをデプロイします。これを (ブルー環境の) 環境 ID として SSM 内でマークします。 アプリケーションを起動します。 シナリオ 2: AWS Mainframe Modernization 環境とアプリケーションは既に存在します。このときの AWS CodeBuild のステップ: 新しいアーカイブファイルを反映する新しい Mainframe Modernization アプリケーションを作成します。 新しいアプリケーションを、AWS Mainframe Modernization のグリーン環境にデプロイします。 アプリケーションを起動します。 Amazon Route 53 のアプリケーション参照を更新し、新しいアプリケーション属性を反映するようにバッチ実行することで、トラフィックをグリーン環境に切り替えます。 シナリオ 2 では、CI/CT/CD パイプラインを続行する前に手動承認が必要です。このステップにより、SSM では前のアプリケーションが停止/削除され、グリーンの環境がブルーに更新され、その逆の環境が更新されます。 AWS Mainframe Modernization サービス内で Infrastructure as Code (IaC) を使用するメリット Infrastructure as Code には、開発者やビジネスオーナーに役立つ複数の機能があります。主なメリットは以下のとおりです。 ネットワーク、コンピューティング、データベース管理などのインフラストラクチャーのプロビジョニングを自動化し、迅速化します。コードを使用して手順を簡素化し、チームの効率とスピードを向上させます。 手動によるインフラストラクチャーのプロビジョニングと構成における人為的ミスを軽減します。標準化され、文書化された手順とログが提供されるため、新メンバーのオンボーディングが容易になります。 人為的ミスや非互換性を減らし、リソースの浪費やダウンタイムを防ぐことで、導入と構成の一貫性を高めます。 繰り返し使用可能で、事前定義された環境仕様を維持することで、同じ構成での再導入が可能になり、構成のずれを自動的に修正できます。 サービスのプロビジョニングとセキュリティ標準の導入を標準化し、自動化することによってセキュリティを強化し、頻繁なセキュリティレビューや承認の必要性を減らします。 まとめ 本ブログでは、既存のビジネスロジックを維持しながら、レガシーアプリケーションをモダンなアプリケーションにリファクタリングするサービスである AWS Mainframe Modernization を使用する利点について概説しました。左記のサービスを AWS Mainframe Modernization Application Testing および CI/CT/CD パイプラインと組み合わせて、ソフトウェアの開発とデプロイを加速します。CI/CD パイプラインは自動テストと統合されているため、レガシーシステムとモダナイズされたシステムの機能が同等であることが保証され、コア機能の効率的な検証とマネージド環境へのスムーズなデプロイが可能になります。このアプローチは俊敏性を高め、運用効率を高め、より幅広い開発者の人材プールへのアクセスを可能にし、モダナイゼーションプロジェクトの成功に貢献します。詳細については、 AWS Mainframe Modernization のページ をご覧ください。 著者 <!-- '"` --> Yann Kindelberger Yann Kindelberger は、アマゾンウェブサービスの Principal Solution Architect です。Yann は 23 年以上メインフレームに携わり、IBM で 20 年以上メインフレームアーキテクトとして勤務しました。彼はメインフレームの AWS クラウドへの移行とモダナイゼーションに取り組んでいるワールドワイドなチームの一員です。彼は 2021 年に AWS に入社し、ソリューションアーキテクトとして、お客様のメインフレームの移行とモダナイゼーションを支援し、助言し、サポートしています。 Sairam Rajagopalan AWS の Partner Solutions Architect である Sairam Rajagopalan は、メインフレームのモダナイゼーションを専門としています。Sairam は、メインフレーム関連の提案やプロジェクトで 20 年以上の経験を持ち、過去 10 年間はレガシーシステムの変革に専念してきました。AWS では、グローバルシステムインテグレーター (GSI) のパートナーと協力して、顧客のメインフレームワークロードをモダナイズし、デジタルトランスフォーメーションの複雑さを乗り越えられるよう支援しています。 Santosh Singh Santosh Singh は、AWS プロフェッショナルサービスの Mainframe Modernization Architect です。メインフレームシステムとクラウドの分野で 18 年以上の経験があり、メインフレームの移行とモダナイゼーションに重点を置いています。現在の役職では、Santosh はお客様と緊密に連携してメインフレーム環境を評価し、移行戦略を策定し、AWS クラウドへの移行を成功させています。Santosh は、メインフレームモダナイゼーションの活動に加えて、生成 AI テクノロジーに焦点を当てた AWS の製品チームやサービスチームとも協力しています。

AWS Summit Japan は、クラウドによるイノベーションを追求する全ての方々のための年に一度のイベントです。2025年は6月25日と26日に開催され、延べ3万6千人以上の来場者で賑わいました。今回も未来を共に創造するビルダーたちが一堂に会し、アマゾン ウェブ サービス (AWS) について学び、ベストプラクティスを共有し、情報交換を行う場となりました。 ここでは、グローバル各国で毎年開催されるAWS Summitの中でも初めての展示となり注目を集めた、AWS認定デバイスウォールについてご紹介したいと思います。 手短に展示内容を把握したい方は、以下の写真をクリックして2分弱の 紹介動画 を御覧ください。各展示デバイスのクローズアップ・ショットを含めてご覧になれます。 AWS 認定デバイスウォール 現代のデジタル変革において、AWSのクラウドソリューションは単独で機能するだけではなく、オフィス・工場・家庭に設置される、カメラ・エッジサーバー・ゲートウェイ・産業用 PC・PLC・シンクライアントなど様々なデバイスと有機的に連携することで、その真の価値を発揮します。この展示では、19社のパートナーから28種類の多種多様なAWS認定デバイスを一堂に集めることで、AWSが実現する『クラウドからエッジまでの統合されたソリューション』の可能性を体感いただきました。 AWS 認定デバイス 今回展示させていただいたデバイスはいずれも AWS の デバイス認定プログラム によって認定を取得したデバイスであり、デバイスパートナーによってAWSのIoTサービスとの接続性が確認されています。これらのデバイスは AWS Partner Device Catalog にリストされており、その数は2025年6月現在、グローバルで494が登録されています。お客様はこのカタログからニーズにあった動作確認済みのデバイスを 検索 して購入することで、すぐにプロジェクトを開始することができます。 展示デバイス一覧 今回展示したデバイスおよび認定されているAWSサービスの一覧を掲載します（アルファベット順）。今回は展示スペースの関係で、パートナあたり最大2台の展示となりましたが、 AWS Partner Device Catalog には展示しきれなかったデバイスも多く登録されています。今回の展示デバイスに興味をもたれましたら、表中のリンクから詳細を確認してみてください。 カテゴリ パートナ名 デバイス名 認定サービス カメラ Axis Communications AB P1465-LE Bullet Camera Amazon Kinesis Video Streams P3265-LV Dome Camera Amazon Kinesis Video Streams i-PRO Co., Ltd. i-PRO moduca Lens Trial Kit Amazon Kinesis Video Streams エッジゲートウェイ インダストリアルエッジ Advantech Co., Ltd. AIR-030 AWS IoT Greengrass ECU-1251 V2 AWS IoT Greengrass Belden Belden OpEdge-8D AWS IoT Greengrass CloudRail.Box Max AWS IoT Core Contec Co., Ltd DX-U1220 AWS IoT Greengrass HARMONIX Co., Ltd. SOCAN-AG4-JPN AWS IoT Core AWS IoT Greengrass Mitsubishi Electric Corporation MELIPC MI2012-W AWS IoT Greengrass OMRON SOFTWARE Co., Ltd. OMRON NYB55 Series Industrial Box PC AWS IoT Greengrass Siemens Digital Industries Software SIMATIC_IPC PX-39A AWS IoT Greengrass SIMATIC_IPC BX-59A AWS IoT Greengrass Takebishi corporation DeviceGateway DGW-C10 AWS IoT Core DeviceGateway DGW-W710 AWS IoT Core PLC Yokogawa Electric Corporation e-RT3 Plus (F3RP70-2L) AWS IoT Greengrass LoRaWAN デバイス/ゲートウェイ Oi Electric Co.,Ltd. BRICK eIoT LoRaWAN + AWS Starter Kit (OiNET-937B) AWS IoT Core for LoRaWAN Semtech LoRa Edge Tracker Reference Design AWS IoT Core Device Location マイコン Atmark Techno, Inc. Armadillo-IoT Gateway A9E Cat.1 bis+WLAN model AWS IoT Greengrass Armadillo-IoT Gateway G4 LTE+WLAN model AWS IoT Greengrass CORE CORPORATION GR-ROSE FreeRTOS Espressif Systems (Shanghai) Co., Ltd. ESP32-WROOM-32 DevKitC FreeRTOS ESP32-C3 AWS IoT ExpressLink Module AWS IoT ExpressLink Renesas Electronics Corporation da16k-ckra6m5 AWS IoT Core Renesas CK-RX65N v2 (Wi-Fi) FreeRTOS STMicroelectronics STM32L4+ Discovery Kit IoT Node FreeRTOS B-U585I-IOT02A Discovery Kit FreeRTOS Ublox USB-NORA-W256AWS AWS IoT ExpressLink まとめ AWS IoT と AWS 認定デバイスは、PoC からエンドツーエンドの商用ソリューションにわたって、IoT システムの複雑さを取り除きつつ、お客様の実際のビジネスに役立つソリューションをサポートします。今後もAWSは、パートナー企業の皆様と連携しながら、クラウドとエッジを統合したイノベーティブなソリューションの創出を支援させていただきます。 展示チーム 川崎 裕希 ソリューションアーキテクト AWSにてソリューションアーキテクトとして、製造業のお客様のIT活用によるお困り事解決を支援しています。 市川 純 プロトタイピングソリューションアーキテクト AWS では IoT に関連するプロトタイピングを支援する、ソリューション アーキテクトとして、お客様の IoT 関連案件を支援しています。 渡邉 聡 プロトタイピングソリューションアーキテクト AWS では IoT、AI などを活用したプロトタイピング支援を行うソリューションアーキテクトとして、主に製造業のお客様を中心に支援しています。 山本 直志 Industry Specialist Solutions Architect 製造業のワークロードを担当する Specialist SA として、お客様が AWS クラウドを活用し、今までにないソリューションを提供するお手伝いをしています。 井上 昌幸 IoT Specialist Solutions Architect Internet of Things と Robotics 界隈で面白い事を探しながら、今日もこつこつリアルな世界とクラウドを繋いでいます。あなたのとっておきのアイデアを AWS と一緒にカタチにしましょう。 &nbsp;

本記事は 2025/07/03に投稿された SQL to NoSQL: Planning your application migration to Amazon DynamoDB を翻訳した記事です。 翻訳はソリューションアーキテクトの Kenta Nagasue が担当しました。 リレーショナルデータベースから Amazon DynamoDB に移行する組織は、データモデルとアクセスパターンを再設計する際に課題に直面することがよくあります。アプリケーションの機能を維持しながら最適なパフォーマンスを実現するためには、クエリ機能、データモデリングアプローチ、アプリケーションアーキテクチャの根本的な違いを理解することが不可欠です。 実際の例でこれらの課題を説明します。急成長している SNS プラットフォームでは、リレーショナルデータベースが複数のテーブル間の結合が必要な複雑なクエリに苦戦しており、特に人気の投稿や有名人とのやりとりなどのコンテンツで顕著です。ユーザー数が今後大幅に増加すると予測されており、既存のアーキテクチャのスケーラビリティに懸念が生じています。数千人の同時ユーザーがいるバイラルイベントでは、人気コンテンツの複雑な結合クエリに負荷がかかり、現在のアーキテクチャではプラットフォームの成長に伴うスケーラビリティニーズを満たせない可能性があることを示唆しています。 この記事は SQL から DynamoDB に移行する際の効果的な移行方法を解説するシリーズの第1回目です。DynamoDB データモデル設計に役立つデータベーススキーマの分析、クエリパターン、使用状況のメトリクスに焦点を当てて、既存のデータベース構造とアクセスパターンを分析して移行の準備方法を検討します。今後の記事では、データモデリング戦略とデータアクセスレイヤーの最新化について説明します。 リレーショナルデータベースと NoSQL データベースの比較 アプリケーションを従来のリレーショナルデータベースから DynamoDB に移行する際、リレーショナルデータベース同士の移行とは大きく異なる点がいくつかあります。これらの違い (次の表を参照) を理解することが、モダナイゼーションの成功には不可欠です。 項目 リレーショナルデータベース Amazon DynamoDB クエリ言語 構造化されたクエリパターンを使用する SQL を使用 最適化されたパーティションキーとソートキーへのアクセスにより、一貫した一桁ミリ秒のレイテンシーを提供する API ベースの操作を提供 データモデル 確立された正規化されたデータ構造を使用 パフォーマンスとスケーラビリティを最適化した柔軟な非正規化データモデリングを提供 データアクセスフレームワーク Entity Framework や Hibernate などの成熟した ORM フレームワークを使用 馴染みのあるオブジェクト指向パターンを維持しながら、複数のプログラミング言語に対して包括的かつ高パフォーマンスを実現する専用ライブラリを備えたネイティブ SDK を提供 リレーショナルデータベースから別のリレーショナルデータベースへの移行は、基本的な構造やアクセスパターンが類似するため、データアクセス層への影響は比較的小さいです。DynamoDB への移行では、その強力な NoSQL 機能を活用する異なるアプローチが導入されます。データモデル、クエリ言語、アクセスパターンの変更により、アプリケーションは DynamoDB の高いパフォーマンスとスケーラビリティを活用できるようになります。チームは DynamoDB の設計原則に合わせてデータアクセス層を適応させ、一貫したパフォーマンスと効率性を最適化できます。 さらに、従来のリレーショナルデータベースの移行では、データベースチームが主にデータベース設定を担当しますが、アプリケーションチームの関与は限られていることがよくあります。しかし、DynamoDB に移行する場合、アプリケーションチームとデータベースチームの協力が重要になります。アプリケーションチームは、データベース専門家と密接に協力して、アプリケーションのデータアクセス要件に合わせた最適な DynamoDB データモデルを設計する必要があります。この協力体制が、DynamoDB NoSQL データベースへの移行を成功させる鍵となります。 データモデリングのための分析 リレーショナルデータベースから DynamoDB への移行では、パフォーマンスとコスト効率を最適化するために、慎重な計画が必要です。まず、要件を定義するために、既存のリレーショナルデータベースの複雑さを評価します。この評価に基づいて、ワークロードに合わせて効果的にスケーリングできる適切な DynamoDB データモデルを設計します。入念な初期評価により、DynamoDB への移行がスムーズになります。移行プロセスでは、現在のデータ構造を分析し、アクセスパターンを特定し、DynamoDB のキーと値のデータモデルに最適化します。 ソーシャルメディアプラットフォームのユースケース この記事を通して概念を説明するために、ユーザーが投稿を作成し、投稿に対してコメントや「いいね」をつけられるソーシャルメディアプラットフォームを使用します。次の図に示すように、主要なエンティティには、投稿を作成するユーザー、投稿に関連するコメント、「いいね」をつけたユーザの機能が含まれます。このプラットフォームは、ユーザーカウンターと投稿カウンターのエンティティを通じてメトリクスを追跡し、ユーザーあたりの投稿総数や投稿毎のエンゲージメント指標などの統計を維持しています。この図は、現在のリレーショナルモデルにおける主要な関係を示しています。 ユーザーと投稿 (1 対多の関係) 投稿からコメント (1 対多の関係) ユーザーとそれぞれのカウンターへの投稿 (1 対 1 の関係) ユーザーと「いいね」 (多対多の関係)による投稿では、ユーザーは複数のポストに「いいね」をしたり、複数のユーザーから投稿に対して「いいね」を受けられる スキーマ分析 既存のデータベース構造を徹底的に調査することから始めてください。この分析により、どのテーブルを移行するかを判断し、DynamoDB でのデータモデリングの複雑さを理解するのに役立ちます。 データベース構造の分析 まず、現在のデータベースアーキテクチャを調査してください。 テーブル (トランザクション、分析、監査ログなど) とそれらの関係を特定する データ型 (文字列、数値、日時、GUID、空間データなど) を分析し、DynamoDB の 同等のデータ型 を特定する DynamoDB の 1 アイテムあたり 400 KB のサイズ制限を考慮しながら、テーブルサイズと増加パターンをドキュメント化する アプリケーションがさまざまなデータ型をどのように使用しているかを理解することは、DynamoDB でのおけるそれらの表現方法を導くことになります。日時フィールドは、クエリとソートの要件に基づいて、ISO 文字列またはエポック数にマッピングする必要があります。複数のフィールドを単一のアイテムに非正規化できる場合は、TEXT フィールドのサイズを評価する必要があります。この分析により、データの整合性を維持しながら効率的なクエリをサポートするデータモデルの設計に役立ちます。 マイクロサービスに関する考慮事項 マイクロサービスアーキテクチャでモダナイズする場合は、各サービスのテーブル依存関係を特定してください。 サービスごとに必要なテーブルを一覧にする サービス間のデータ依存関係をドキュメント化する 非正規化の戦略を立てる データ整合性の要件を評価する サービス間でデータを共有およびアクセスする必要性を検討してください。たとえば、投稿サービスではユーザー名とプロフィール画像の表示が必要になる一方で、通知サービスではアラート配信のためにユーザー設定が必要になる場合があります。このようなサービス間のデータ依存関係は、DynamoDB のモデリング決定に影響します。アクセスパターンと更新頻度に基づいて、厳格なサービス分離とデータ非正規化のトレードオフを評価してください。サービス間の呼び出しによるパフォーマンスへの影響を考慮し、アプリケーションパターンの変化に伴ってサービス境界の調整が必要になる状況に備えてください。 部分的な移行分析 一部のテーブルのみを DynamoDB に移行する場合は、移行したテーブルと移行していないテーブルの関係を理解する必要があります。 移行範囲と依存関係を特定する パフォーマンスへの影響を評価する アプリケーションの変更を計画する データ整合性戦略を設計する 将来の移行フェーズを定義する 投稿やコメントなどの頻繁にアクセスされるデータは DynamoDB に移行し、履歴分析データはリレーショナルデータベースに残すシナリオを考えてみましょう。以前はテーブル間のトランザクション整合性に依存していた操作を処理するデザインパターンを計画します。クロスデータベースクエリによる潜在的なレイテンシーへの影響を検討し、適切なデータ同期メカニズムを実装する必要があります。この理解は、移行中と移行後のデータ整合性とアプリケーションのパフォーマンスを維持するための効果的な戦略を立てるのに役立ちます。 スキーマオブジェクトの評価 DynamoDB の設計で SQL スキーマオブジェクトの機能をどのように実装するかを評価してください: SQL ビューとそのアプリケーション使用方法をドキュメント化する 共通テーブル式 (CTE) を含む、ストアドプロシージャの複雑さを分析する トリガーベースのビジネスロジックの移行を計画する 移行対象外のテーブルへの参照を評価する 複雑な分析クエリの代替案を検討する 大規模なデータ変更を計画する テーブル全体でエンゲージメント指標を集計する SQL ビュー、時間ウィンドウ付きデータを使用してトレンドコンテンツを計算するストアドプロシージャ、投稿数などの派生データを管理するトリガーは、DynamoDB 向けに再設計する必要があります。SQL 操作に依存せずに効率的なアクセスパターンをサポートするようにデータモデルを設計してください。大規模なデータ変更にはバッチ処理アプローチを検討し、従来はデータベースプロシージャやトリガーで処理されていた操作をアプリケーションロジックでどのように処理するかを計画してください。入念なスキーマ分析と慎重な計画を行うことで、チームは実装要件を予測し、クエリパターンを最適化し、効果的なデータ整合性戦略を策定できます。この理解は、モダナイゼーションの取り組みに不可欠であり、チームがアプリケーションで DynamoDB の機能を最大限に活用できるようにするための鍵となります。 クエリ分析 アプリケーションで使用される SQL クエリ (インラインの SQL、ORM 生成のクエリ、その他の動的クエリを含む) を分析します。この分析により、DynamoDB データモデルの適切なパーティションキー、ソートキー、リレーションシップを選択するための情報が得られます。SQL クエリの各コンポーネントを次のように調査します。 SELECT 句の分析 SELECT 句を調べることで、アプリケーションがデータをどのように消費する方法と、さまざまなエンティティ間の関係について洞察を得ることができます。SELECT 句を分析する際には、次の重要な側面を考慮してください: サブクエリ – 既存のアクセスパターンの中で、通常は集約、複雑な条件に基づくフィルタリング、関連エンティティの詳細の取得、または最新のレコードの取得を行うサブクエリを探します。たとえば、ユーザープロファイルのクエリではサブクエリを使って総投稿数やフォロワー数を計算し、投稿のクエリでは最新のコメントを取得するかもしれません。これらのパターンを理解することで、DynamoDB で非正規化するデータと、事前計算した値として維持する属性を特定するのに役立ちます。 -- User profile with total posts count SELECT u.name, u.profile_pic, (SELECT COUNT(*) FROM posts WHERE user_id = u.user_id) as post_count FROM users u WHERE u.user_id = '123' 複数テーブルのカラム選択 – クエリが複数のテーブルのカラムを組み合わせる方法を分析し、頻繁に一緒にアクセスされるデータを示します。典型的な投稿表示クエリは、1 回のフェッチで、コンテンツ、著者の詳細、エンゲージメント統計を組み合わせます。この分析により、異なるエンティティからどの属性を 1 つのアイテムに非正規化して、DynamoDB での効率的な読み取り操作をサポートできるかを判断できます。 -- Post with author details SELECT p.content, p.created_at, u.name, u.profile_pic FROM posts p JOIN users u ON p.user_id = u.user_id WHERE p.post_id = '456' ユーザー定義関数 – クエリでデータを変換または計算するユーザー定義関数の使用状況を確認してください。複数のエンゲージメント要因を時間ベースの重み付けで組み合わせてトレンドスコアを計算する関数は、クエリでの計算が複雑になります。これらの計算を理解することで、事前に計算して格納すべき属性と、DynamoDB でこれらの計算値を効率的に更新できるようにデータモデルを構造化する方法を特定するのに役立ちます。 派生列 – 複数のフィールド値を組み合わせたり、ビジネスロジックを適用してクエリ内の計算または条件付きの列を調査してください。多くの場合、クエリでは全体的なエンゲージメント指標を導出し、インタラクションのしきい値に基づいてコンテンツのステータスを判断します。この分析により、アイテムに計算済みの属性を維持するかどうか、および DynamoDB でこれらの派生値を最新に保つための効率的な更新パターンを設計するうえでの判断材料となります。 -- Derived engagement score and post status SELECT post_id, content, (like_count + comment_count) as total_engagement, CASE WHEN like_count &gt; 1000 THEN 'TRENDING' WHEN like_count &gt; 100 THEN 'POPULAR' ELSE 'NORMAL' END as post_status FROM posts WHERE created_at &gt; DATEADD(year, -1, GETUTCDATE()) JOIN 句の分析 SQL クエリの JOIN 句を調べると、さまざまなエンティティ間の関係と、アプリケーションが複数のテーブルからどのようにデータを結合しているかがわかります。この分析により、DynamoDB での最適なデータモデル戦略を決定するのに役立ちます。JOIN 句を分析する際は、次の重要な側面を考慮してください。 エンティティの関係 – クエリでどのテーブルがよく結合されているかを分析します。投稿の表示クエリでは、投稿、コメント、いいね、ユーザーテーブルのデータを組み合わせることがあり、この操作ではこれらのエンティティが一緒にアクセスされることが多いことを示しています。これらの組み合わせを理解することで、効率的にアクセスするために DynamoDB で非正規化またはモデル化する必要があるデータの特定に役立ちます。 結合条件 – テーブル間の関係の条件と多重度を評価します。たとえば、投稿はコメントと一対多の関係になる可能性がありますが、ユーザープロファイルとは一対一の関係になります。結合条件には、単純なキーの一致以外にも、日付範囲やステータスフラグが含まれる場合があります。この多重度を理解することで、データをアイテム内に埋め込むか、別のアイテムを維持するかなど、適切なモデリング戦略を決定するのに役立ち、さまざまなモデリング手法のパフォーマンスとコストの影響を見積もるのに役立ちます。 -- Post with its comments SELECT p.*, u.*, c.comment_text, c.created_at FROM posts p JOIN comments c ON p.post_id = c.post_id AND c.created_at &gt; DATEADD(hour, -24, GETUTCDATE()) JOIN users u ON p.user_id = u.user_id WHERE p.post_id = '456' サービス間およびハイブリッドアーキテクチャの結合 – 異なるサービスに属するテーブル、または移行が計画されていないテーブルを含む結合を確認します。たとえば、投稿データが別のサービスによって管理されるユーザープロファイルデータと結合する場合や、リレーショナルデータベースに残る分析データと結合する場合などです。このようなパターンはデータモデリングの決定に影響します。この分析により、サービス境界を越えたデータアクセス戦略や、異なるデータベースに対する戦略の指針となります。 WHERE 句の分析 SQL クエリの WHERE 句を調べると、アプリケーションがデータをどのようにフィルタリングしてアクセスしているかを知ることができます。この分析は、DynamoDB で効率的なアクセスパターンを設計する上で役立ちます。WHERE 句を分析する際は、次の点に留意してください。 単一値フィルター – クエリで頻繁に使用される単一値フィルターを特定します。たとえば、特定のユーザー ID で投稿をフィルタリングしたり、ステータス別に投稿を取得したりするパターンです。これらのパターンは、DynamoDB のベーステーブルまたはグローバルセカンダリインデックス (GSI) の潜在的なパーティションキーを特定するのに役立ち、さまざまなアクセスパターンでデータを効率的に取得できるようになります。 -- Single value filter SELECT * FROM posts WHERE user_id = '123' AND status = 'ACTIVE' 範囲ベースのフィルター – エンティティ識別子と範囲条件を組み合わせたクエリを探します。ユーザー ID と日付範囲で投稿をフィルタリングするクエリは、DynamoDB で複合キーを構造化する方法を示しています。これらのパターンを理解することで、パーティション内の効率的な範囲クエリをサポートする適切なソートキーを決定するのに役立ちます。 -- Getting user's recent posts SELECT * FROM posts WHERE user_id = '123' AND created_at &gt; DATEADD(year, -1, GETUTCDATE()) ORDER BY created_at DESC 複数値フィルター – 属性に対して複数の値が存在する条件を調査します。たとえば、あるユーザー ID グループによる投稿の検索や、特定のハッシュタグを含む投稿の検索などです。これらのパターンは、DynamoDB のデータモデリングの決定に影響を与えます。たとえば、複数のユーザーによる投稿を取得する場合は、ユーザー ID をパーティションキーとする GSI を使って個別のクエリを実行する必要がありますが、ハッシュタグによる投稿の検索では、ハッシュタグをパーティションキーとし、関連する投稿 ID を集合として格納する、逆インデックス構造が有益かもしれません。 -- Finding posts with specific hashtags SELECT DISTINCT p.* FROM posts p JOIN post_hashtags ph ON p.post_id = ph.post_id WHERE ph.hashtag IN ('#POPULAR', '#TRENDING') クロスエンティティフィルター – SQL クエリ内で複数のエンティティにまたがるフィルターを特定します。たとえば、投稿属性とユーザー属性 (ユーザーの場所やユーザータイプなど) の両方に基づいて投稿を検索するクエリは、DynamoDB モデルの非正規化の決定に影響を与える関係を示しています。これらのフィルターに、異なるマイクロサービスによって管理されるエンティティ、または DynamoDB に移行されないエンティティを含む場合は、クライアントサイドのフィルタリングとサービス境界を越えたデータ取得のパフォーマンス影響を分析します。 -- Finding active user posts with high engagement SELECT p.post_id, p.content, FROM posts p JOIN users u ON p.user_id = u.user_id WHERE u.status = 'ACTIVE' AND p.like_count &gt; 100 ORDER BY p.created_at DESC ORDER BY 句と TOP/LIMIT 句の分析 ORDER BY 句と TOP/LIMIT 句を調べると、アプリケーションでのデータのソートとページネーションの要件が明らかになります。この分析は、DynamoDB での効果的なソートキーの設計を決定するのに役立ちます。以下の点を考慮してください: ソート要件 – データの並べ替えに使用される属性と属性の組み合わせを特定します。たとえば、最新の投稿を表示するために作成日でソートする、または人気のコンテンツを表示するためにエンゲージメント指標でソートするなどです。一部のクエリでは、日付でソートした後、各日付内でいいね数でソートするなど、複合ソートが必要になる場合があります。これらのパターンを把握することで、必要なソート機能をサポートする適切な DynamoDB のソートキー構造を決定するのに役立ちます。 ページネーション要件 – TOP/LIMIT 句とソートを使用するクエリを分析します。最新の投稿を制限付きで取得するクエリや、エンゲージメント指標に基づいて人気の投稿を取得するクエリは、ページネーションが必要であることを示しています。これらのパターンを理解することで、DynamoDB の limit 機能と LastEvaluatedKey 機能を使って効率的なページネーション戦略の設計に役立ちます。 GROUP BY 句の分析 GROUP BY 操作を調査することで、アプリケーションで集約が必要な部分を明らかにできます。この分析により、DynamoDB データモデルで維持する必要がある指標やカウンターを特定できます。以下の点を考慮してください: 集約パターン – クエリ内のグループ化と集約操作を特定します。たとえば、ユーザーごとの投稿数のカウント、投稿ごとの合計いいね数の計算、投稿タイプごとのエンゲージメント指標の要約などです。これらのパターンを理解することで、アイテムに事前計算された値として維持する必要がある属性なのか判断するのに役立ちます。 -- Posts count by user SELECT user_id, COUNT(*) as total_posts FROM posts GROUP BY user_id 更新頻度 – これらの集計値がどのくらいの頻度で変化するかを分析します。投稿へのいいね数は、ユーザーの操作に応じて頻繁に更新されますが、ユーザーの投稿総数は投稿を作成または削除したときにのみ変化します。このようなパターンを把握することで、書き込みパターンと、事前計算された値を維持する上での影響を評価するのに役立ちます。 アプリケーション使用状況の分析 アプリケーションの使用統計情報 (時間ごとの HTTP リクエスト頻度など) を収集します。ビジネス上の重要度と使用状況のメトリクスを、以下の目的で分析します。 特別な注意を要するエッジケースに優先順位をつける。例: 有名人が最新情報を投稿した場合、システムはその投稿を数百万人のフォロワーのフィードに即座に配信する必要がある。 口コミで広まった投稿には、数分以内に突然多くの「いいね」やコメントが付く可能性がある。 移行すべき主要なモジュールを特定する。 このデータ駆動型のアプローチでは、アプリケーションの最も重要で頻繁に使用される部分が移行プロセス中に優先されるため、リソースの割り当てが最適化され、コア業務機能への潜在的な中断が最小限に抑えられます。次の目標で、テーブルの平均行サイズ、読み取り/書き込み比率、予測成長率を分析します。 エンティティ関係を構築する最適なアプローチを決定する。たとえば、単一アイテム戦略と垂直パーティショニングのどちらを選択するか 読み取りと書き込みのキャパシティを正確に見積もり、割り当てる 結論 現在のデータベース構造、アクセスパターン、使用状況メトリクスを分析することで、DynamoDB への移行の基盤を構築できます。この理解は次のフェーズである DynamoDB のデータモデルの設計を形作るのに役立ちます。これについては、このシリーズの パート 2 で説明します。この構造化されたアプローチに従うことで、移行戦略が現在のニーズと将来のスケーラビリティ要件の両方に合致していることを確認できます。 著者について Ramana Kiran Mannava Ramana は、AWS プロフェッショナルサービスのリードコンサルタントであり、.NET ワークロードの最新化と AWS 上のクラウドベースソリューションの構築に関する専門知識を持っています。彼はデータベース技術とクエリ最適化にも情熱を持っています。 Akber Rizwan Shaik Akber は、 AWS プロフェッショナルサービスのリードコンサルタントです。彼はクラウドベースのソリューションを使用して、お客様の .NET ワークロードを AWS に移行し、最新化するのを支援しています。 Mahesh Kumar Vemula Mahesh は、AWS プロフェッショナルサービスのリードコンサルタントです。彼はサーバーレス愛好家であり、クラウドベースのソリューションを用いて顧客の .NET ワークロードの最新化を支援しています。

この記事は How to create a unified view of your consumer (記事公開日: 2025 年 6 月 13 日) を翻訳したものです。 はじめに 今日の競争の激しいビジネス環境において、顧客の 360 度ビューを構築することは、顧客体験の向上、運用戦略の最適化、そしてマーケティング効率の改善につながります。顧客の行動は、従来の実店舗での対面取引から、データに基づくオンラインでの個別対応へと変化しています。企業は、情報の中から必要なものを整理することで、顧客についてより多くのことを学ぶことができます。顧客の統一ビューとは、企業が顧客と持つすべての接点やデータソースから得られる、様々な異なる情報を統合し連携させる能力を指します。これには、取引履歴、ロイヤルティプログラムの会員情報、ウェブサイトやモバイルアプリの訪問記録、カスタマーサービスとのやり取りなどが含まれます。これらすべてのデータソースには顧客の行動に関する貴重な洞察が含まれていますが、それぞれ異なる顧客データの要素と紐づいており、連関のないシステムに分散して保存されています。顧客は、ウェブサイト、モバイルアプリ、実店舗、様々なマーケティングキャンペーンを通じてブランドと接触し、それぞれの接点で独自の記録が生成されます。 Amazon Connect Customer Profiles と AWS Entity Resolution を使用してこれらの断片化されたデータポイントを単一の一貫したプロファイルに統合することで、企業は顧客をより深く理解し、真にパーソナライズされた体験を提供できるようになります。 ある銀行の顧客であるシャーリーさんの例を考えてみましょう。長年にわたって、シャーリーさんは当座預金口座を開設し、クレジットカードを申し込み、住宅ローンを申請し、銀行のリワードプログラムに登録し、カスタマーサポートチームに何度も連絡を取っています。しかしながら、このデータは断片化されています。 後に買収された地方銀行で口座を開設していた 住宅ローンは現在住んでいない住所と関連付けられている 個人口座と法人口座を異なる請求情報で開設している これらの要因により、銀行はシャーリーさんとの関係について部分的な把握しかできていない可能性があります。その結果、以下のような機会を逃すかもしれません。 過去の履歴に基づくオーダーメイドのオファー提供 過去の行動パターンに基づくニーズの予測 カスタマーサービス連絡時の効率的な問題解決 しかし、AWS Entity Resolution を活用することで、銀行はシャーリーさんのすべての記録とやり取りを連携させ、顧客としての包括的な理解を得ることができます。そして、Amazon Connect Customer Profiles を使用してシャーリーさんの統一された信頼できる記録を作成し、銀行とのやり取りがあるたびにリアルタイムで更新されるシステムを構築できます。 主な課題 シャーリーさんのような顧客に、より良い体験を提供するために、企業は以下のような課題に対処する必要があります： データの断片化 ：顧客データは、異なるスキーマ、形式、場所、アクセス方法を持つ相互に関連のないアプリケーションに分散しており、一元化が困難になっています。 一貫性のない顧客プロファイル ：企業は結果的に、一貫性がなく、不完全で、時には矛盾する顧客情報を抱えることになります。これにより、各個人について明確で正確な理解を築くことが困難になります。 パーソナライゼーションの困難さ ：統一された顧客ビューがなければ、真にパーソナライズされた体験を提供することはほぼ不可能になります。企業は再訪問した顧客を認識できず、関連性の高い推奨事項を提供できず、複数の接点にわたってシームレスな体験を提供できなくなる可能性があります。 マーケティングと営業の最適化不足 ：断片化されたデータは、企業が意味のある洞察を得て、購買ジャーニーをマッピングし、ターゲットを絞った効果的なマーケティングキャンペーンを実行する能力を阻害します。これにより、マーケティング予算の無駄遣いや営業機会の損失につながる可能性があります。 コンプライアンスとプライバシーのリスク ：GDPR (一般データ保護規則) や CCPA (カリフォルニア州消費者プライバシー法) などの現代のデータプライバシー規制では、企業が各顧客について収集・保存する個人データを包括的に理解し、アクセス要求、監査、オプトアウト、削除に使用することが求められています。断片化されたデータでは、このような規制への準拠が困難になります。 これらの課題に対処し、顧客データを統一ビューに統合することで、企業は顧客体験の向上、成長の促進、競争優位性の維持のための豊富な機会を得ることができます。 このブログでは、Amazon Connect Customer Profiles と AWS Entity Resolution を使用して顧客の統一ビューを作成する方法について説明します。 ソリューション Amazon Connect Customer Profiles は、連絡先情報や取引履歴からサポートでのやり取りや設定まで、すべての関連する顧客情報を統合・保存し、単一の統一された顧客プロファイルにまとめて実用的な洞察を作成します。これらのプロファイルには、最も重要な連絡先情報、最新のやり取り、その顧客に関するその他の計算された洞察が含まれています。Amazon Connect Customer Profiles は、主要な顧客データシステムとノーコードで統合でき、データを自動的に取り込んで、整理・保存します。保存したデータは、Amazon Connect 内ですぐに検索やアクセスのために利用できます。AWS Entity Resolution とシームレスに統合することで、Amazon Connect Customer Profiles は各プロファイルが重複排除された顧客エンティティにリンクされることを保証し、一貫性のない断片化されたデータのリスクを排除します。 AWS Entity Resolution は、企業が複数のアプリケーション、チャネル、データストアに保存されている関連する顧客、製品、ビジネス、またはヘルスケア記録をマッチング、リンク、拡張するのに役立ちます。このサービスは、ルールベースと機械学習ベースのマッチング技術を活用することで、断片化された消費者データの課題に対処します。AWS Entity Resolution は、異なるソースから消費者記録を取り込み、重複を排除し、一意の消費者エンティティを特定します。同じ消費者に属するすべての記録に一意の matchID を割り当てることで、このサービスは分析とセグメンテーションのために統合できるすべてのデータソースの鍵となる、人を表す共通キーを作成します。AWS Entity Resolution は、アイデンティティ解決パイプラインの構築に必要な重い作業 (データ正規化、大規模データセットでのペア生成、比較分散、ID 一貫性、クラスタリング、分割) を取り除くため、複雑なデータエンジニアリングソリューションを構築する代わりに、設定しやすいマッチング技術を使用できます。ルールベースマッチングの開始方法がわからない場合、ML ベースマッチングは個人識別情報 (PII) ベースのデータに対して業界最高水準の精度を提供し、設定が不要です。 企業は、AWS Entity Resolution で処理されたデータ基盤を基に、Amazon Connect Customer Profiles を使用することで、各顧客の包括的で実用的な 360 度ビューを構築することもできます。 この統合ソリューションの主要なメリット : 統一された顧客インテリジェンス ：企業は、すべての接点とやり取りを通じて、各顧客の属性、行動、興味、課題点を含む包括的な理解を得ることができます。 パーソナライズされた体験 ：顧客の完全なビューがあることで、組織は高度にパーソナライズされた製品、サービス、コミュニケーションを提供し、顧客ロイヤルティと満足度を向上させることができます。 よりパーソナライズされたマーケティング ：断片的または重複した記録をマーケティングや広告キャンペーンに使用すると、マーケティング予算の無駄遣い、キャンペーン結果の悪化、冗長なメッセージングによる顧客への迷惑につながる可能性があります。 パーソナライズされたカスタマーサポート ：カスタマーサービス担当者は、顧客の履歴や過去のやり取りの全体像に素早くアクセスでき、より迅速で効果的なサポートを提供できます。 クロスセルとアップセルの改善 ：顧客の全体的なジャーニーと製品・サービス利用状況を理解することで、企業は関連性の高いクロスセルとアップセルの機会を特定し、収益成長を促進できます。 コンプライアンスとプライバシー規制への対応 ：GDPR や CCPA などの現代のデータプライバシーポリシーでは、企業が各顧客について収集・保存することが許可されている個人データを包括的に理解する必要があります。また、オプトアウトや記録削除の要求をすべての規制基準に従って適切に実行する必要があります。 連絡設定の尊重 ：顧客が電話やメールでの連絡を希望しない場合、複数の電話番号やメールアドレスを持っていても、その意志を尊重することで企業はより良い体験を提供できます。 Amazon Connect Customer Profiles と AWS Entity Resolution の力を組み合わせることで、企業は消費者の包括的な 360 度ビューを実現し、顧客理解とビジネスインパクトの新たなレベルを実現できます。 仕組み 以下のリファレンスアーキテクチャは、Amazon Connect Customer Profiles と AWS Entity Resolution が顧客データを統合して、顧客離脱の削減、パーソナライゼーションの向上、カスタマーサービスの改善などに使用できる 360 度ビューを作成する方法を概説しています。 Amazon Connect Customer Profiles and AWS Entity Resolution reference architecture 消費者の記録とやり取りを含むデータソースは、重複排除、マッチング、リンクのために AWS Entity Resolution に送信されます。これらのソースには通常、消費者の個人識別情報 (PII) が含まれており、ロイヤルティ登録システムや CRM システムが良い例です。AWS Entity Resolution のマッチングロジックと設定により、顧客は複数の接点や複雑なロジック、あいまいなアルゴリズムを活用するルールを構築できます。また、機械学習ベースのマッチングモデルを使用することで、複雑なルールを使用せずに PII を用いて正確なデータマッチングを行うことも可能です。 その後、Amazon Connect Customer Profiles は、マーケティングオートメーション、コールセンターのやり取りの記録、ユーザー設定などの他のデータソースを取り込んで、顧客に関する実用的な洞察を作成できます。これらのソースは同じロジックを必要とせず、通常はアカウント ID などの特定のキーや識別子を使用して、既知のユーザー / エンティティに紐づけられます。 このようにデータソースを分離することで、アーキテクチャは各 AWS サービスの使用を最適化できます： AWS Entity Resolution は、主要な記録システムから顧客識別子へ顧客 ID を解決・リンクするという中核タスクに集中します。 Amazon Connect Customer Profiles は、解決された顧客データを追加のエンゲージメントデータと集約して、各顧客識別子の総合的な 360 度ビューを提供します。 このアプローチにより、効率的なデータ処理が保証され、パーソナライズされた体験、ターゲットを絞ったマーケティング、強化された顧客インサイトをサポートする包括的で統合された顧客ビューの作成が可能になります。 顧客への理解を深めるにつれて顧客データは時間の経過とともに変化するため、企業はプロファイルの変化に応じて成長・進化できる柔軟なアーキテクチャを計画する必要があります。多くの消費者は、匿名の訪問者と既知の訪問者の両方として、様々なチャネルを通じて企業とやり取りします。チャネル間でのこのようなデータの断片化は、同一人物に対して複数のプロファイルが作成される原因となることが多く、その瞬間に個人を特定することが困難になります。この問題に対処するための一般的なアプローチは、AWS Entity Resolution のルールベースと機械学習ベースのマッチングを活用することです。不完全な情報により、最初のルールベースマッチングでは別々のプロファイルが作成される可能性がありますが、AWS Entity Resolution の機械学習を活用したマッチング機能を時間をかけて適用することで、これらの異なるプロファイル間でより堅牢なリンクを提供できます。このような方法で顧客データを統合することで、組織はより総合的で統一された消費者ビューを獲得し、やり取り全体でよりパーソナライズされたシームレスな体験を提供する力を得ることができます。 プロファイルが作成され、顧客データフィードが Amazon Connect Customer Profiles に送られてプロファイルを充実させるようになると、企業は Amazon Connect Customer Profiles を顧客データファブリックとして使用し、複数のチャネルを通じてセグメンテーション、分析、パーソナライゼーションを行うことができます。 Amazon Connect Outbound Campaigns を使用して、企業はアウトバウンドメール、SMS、プッシュ通知イベント用のオーディエンスセグメントを作成したり、顧客プロファイルの属性をカスタマーサービスアクション、アウトリーチ、体験のトリガーとして使用できます。さらに、ユーザーは統合された顧客ビューを、Adobe や Salesforce を含む任意の顧客データプラットフォームにおいて、統合された豊富で最新の顧客ファブリックとして使用できます。 顧客成功事例 United Airlines (ユナイテッド航空) などの顧客は、AWS Entity Resolution と Amazon Connect Customer Profiles を使用して統一された顧客ビューを構築することで、最終顧客満足度とマーケティング予算の ROI を大幅に改善しました。 ユナイテッド航空は、AWS Entity Resolution を使用して、ルールベースマッチングによる確定的 ID と、ML ベースマッチングモデルによる確率的 ID の両方を作成しました。ML ベースとルールベースの両方のマッチングを適用することで、ユナイテッド航空は 90％ を超えるマッチング精度を達成しました。 「AWS Entity Resolution を使用することで、すべての予約に対して、リアルタイムでその顧客に正しい確率的 ID を関連付けることができます」と、ユナイテッドのカスタマートラベルエクスペリエンス担当マネージング・ディレクターの Mahesh Veda 氏は述べています。「これにより、顧客の全体的なジャーニーの統一ビューが作成されます。」 ユナイテッド航空は、旅行者とゲストのデータを連携させて洞察を得て、パーソナライゼーションを推進しています。このソリューションを使用することで、予約データベースや CRM ソフトウェアなど、14 の基幹システムとレガシーシステムからデータを取り込んでいます。新しいソリューションにより、ユナイテッド航空は重複する顧客記録を 35％ 削減し、インフラストラクチャの統合により運営コストを 30％ 削減しました。そして最も重要なことは、顧客が旅行体験の違いを実感したことです。 「ネットプロモータースコアが 15％ 向上しました」と Veda 氏は述べています。「お客様は『この方法で予約して戻ってきても、あなたたちは私のことを覚えてくれている』と言って喜んでいます。」 まとめ 企業は多くのチャネルから顧客の断片化されたデータを収集していますが、そのデータを正確に統合することに苦労しています。Amazon Connect Customer Profiles と AWS Entity Resolution は、多くのソースからのデータを統合し、重複するプロファイルをマージして、よりパーソナライズされた体験を提供するために使用できる統一されたビューを作成します。AWS の担当者にお問い合わせいただくか、 Amazon Connect Customer Profiles と AWS Entity Resolution を使用して顧客の統一ビューを構築し、より良い洞察と顧客へのパーソナライズされた体験を実現する方法について、オンラインで詳細をご確認ください。 Punit Shah Punit は、Amazon Web Services のシニアソリューションアーキテクトとして、顧客がクラウド上でデータと分析戦略を構築するのを支援することに注力しています。現在の役割では、AWS Entity Resolution や Amazon Connect などの AWS サービスを使用して、強固なデータ基盤層の構築を顧客に支援しています。大規模なデータレイクの構築において 15 年以上の業界経験を持っています。 Travis Barnes Travis は AWS Entity Resolution のシニアプロダクトマネージャー (テクニカル) として、高度なアイデンティティ解決技術を通じて顧客がデータの価値を最大化できるよう支援しています。アイデンティティと Adtech 分野での革新的な製品開発において 10 年以上の経験を持ち、実際のビジネス成果を生み出す複雑なデータの課題解決に情熱を注いでいます。 本稿の翻訳は、ソリューションアーキテクトの髙橋が担当しました。原文は こちら 。

こんにちは、Amazon Connect ソリューションアーキテクトの坂田です。 2025年5月のアップデートまとめ はご覧いただけましたでしょうか。また、6月25日、26日には AWS Summit Japan 2025 が開催されましたが、お楽しみいただけましたでしょうか？大雨が降ったりとっても暑かったりでしたが、二日間ともたくさんのお客様にご来場いただくことができ、大変嬉しく思っております。7月11日まで オンデマンド配信中 ですので、見逃した方はぜひご視聴くださいませ。 さて、今月は以下の情報をお届けします。皆様のお役に立つ内容があれば幸いです！ 注目のアップデートについて 2025年6月のアップデート一覧 AWS Contact Center Blog のご紹介 1. 注目のアップデートについて Amazon Connect アウトバウンドキャンペーンが3つの新しい AWS リージョン(東京リージョン含む)で利用可能に Amazon Connect アウトバウンドキャンペーンがアジアパシフィック（ソウル）、アジアパシフィック（東京）、アジアパシフィック（シンガポール）で利用可能になりました。これにより、お客様は適切なチャネルを通じて、カスタマーエクスペリエンス全体を通じて最適なタイミングでリアルタイムのサービスアップデート、プロモーションオファー、製品使用のヒント、予約リマインダーなどの積極的なアウトバウンドコミュニケーションを開始できるようになります。 Amazon Connect のアウトバウンドキャンペーンは、セグメンテーション、オムニチャネルオーケストレーション、コンテンツのパーソナライゼーション、組み込み分析などの主要な機能を通じて、ターゲットを絞った効果的なアウトリーチ戦略を作成する機能を企業に提供します。アウトバウンドキャンペーンは、予測型および段階的な音声ダイヤリング、AI 駆動の通話分類、コンタクト結果に基づくリトライ戦略、タイムゾーン検出、通信制限をサポートしています。これらの機能により、企業は規制要件と顧客の好みに準拠しながらアウトリーチを最適化できます。さらに、企業はオーディエンスセグメントを微調整し、メッセージテンプレートをパーソナライズし、音声や SMS、メールなどのデジタルチャネルでイベントベースのキャンペーンを開始できます。これらの機能を活用することで、企業は顧客エンゲージメント戦略を大幅に強化し、全体的なコミュニケーションの効果を向上させることができます。 Amazon Connect のアウトバウンドキャンペーンでは、音声（エージェントまたは自動音声）、Eメール、SMS をサポートしています。 音声（エージェント）を選択した場合、プレディクティブとプログレッシブの二つのダイヤルモードを選択することが可能です。 「通話の進捗を確認」ブロックを使用することで、顧客への接続状況に応じてフローを分岐させることも可能です。これによって、エージェントの生産性をさらに向上させることが可能です。例えば、「呼び出しが応答された」場合はエージェントにルーティング、「ボイスメール」の場合は「プロンプトの再生」を使ってメッセージを残す。などの分岐が可能になります。 Amazon Connect アウトバウンドキャンペーンを始めるには、 管理者ガイド にそって設定を開始してください。また、 AWS Workshop Studio で詳しく学習することも可能です。 関連リンク 管理者ガイド 製品ページ 料金ページ AWS Workshop Studio 2. 2025年6月のアップデート一覧 エージェントのパフォーマンスを評価する際に、サードパーティアプリケーションのエージェント活動を含めることができるように – 2025/06/30 Amazon Connect で、サードパーティアプリケーションのエージェントアクティビティを Amazon Connect のタスクとして統合できるようになりました。 サードパーティアプリケーション（アプリケーション処理、ソーシャルメディア投稿など）からのアクティビティを Amazon Connect の完了済みタスクとしてプログラムで取り込み、パフォーマンス評価に関連する詳細をタスク属性として記録できます。マネージャーはこれらの外部アクティビティをネイティブのAmazon Connect 上の操作と共に評価し、Amazon Connect のダッシュボード内でエージェントのパフォーマンスを統合的に確認することができます。 この機能は、Contact Lens のパフォーマンス評価がすでに利用可能なすべてのリージョンで利用できます。 関連リンク 管理者ガイド 東京リージョンと大阪リージョン間の Amazon Connect インスタンスのレプリケーションをサポート – 2025/06/30 Amazon Connect で、アジアパシフィック（大阪）に、アジアパシフィック（東京）環境のチャネル構成とサービスクォータを反映する同期されたインスタンスを維持できるようになりました。アジアパシフィック（大阪）にレジリエンシーインスタンスを設置することで、ユーザー、ルーティングプロファイル、フローなどの Amazon Connect 設定をレプリケートし、トラフィック分散設定を構成して、アジアパシフィック（東京）とアジアパシフィック（大阪）間でユーザーグループと電話番号を事前に定義し、リージョンの切り替え後に新規の着信トラフィックをレジリエンシーインスタンスで処理できるようになります。 この機能を利用するためには、事前のお申し込みが必要です。AWS のアカウントチーム、テクニカルアカウントマネージャー、または Amazon Connect ソリューションアーキテクトまでお問い合わせください。 関連リンク AWS Blog – Amazon Connect Global Resiliency で実現するマルチリージョン高可用性 Amazon Connect アウトバウンドキャンペーンが 3 つの新しい AWS リージョンで利用可能に – 2025/06/26 「 注目のアップデート 」をご参照ください。 Amazon Connect がアウトバウンドキャンペーンの通信制限を強化 – 2025/06/13 Amazon Connect アウトバウンドキャンペーンは、複数のキャンペーンにわたって顧客とのエンゲージメント頻度を設定する際により大きな柔軟性を提供する、新しいインスタンスレベルの通信総数制限管理を提供するようになりました。また、重要なキャンペーンについては制限管理をオプトアウトする機能も提供します。これらの新機能により、より効率的でターゲットを絞った顧客エンゲージメント戦略が可能になります。 新しいインスタンスレベルの総数制限設定により、企業は米国電話消費者保護法（TCPA）などの規制に準拠しながら、すべてのキャンペーンにわたるアウトバウンド通信制限を管理できます。この機能は通信頻度を一元的に管理する方法を提供し、顧客への過度な連絡を避け、顧客満足度を潜在的に向上させることができます。特定のキャンペーンについてこれらの制限をオプトアウトする機能により、不正警告や悪天候時のサポートなどの重要な通信が最も必要な時に顧客に届くようになり、アウトバウンド通信の全体的な効果を高めます。 関連リンク 管理者ガイド Amazon Lex、LLM 支援の NLU を使用して会話の精度を向上 – 2025/06/12 Amazon Lex では、 英語とスペイン語のロケール のインテント分類とスロット解決機能を向上させるために、大規模言語モデル (LLM) を利用した自然言語理解 (NLU) が提供されるようになりました。この機能により、大規模言語モデル (LLM) を活用して標準 NLU で問題が発生したときの精度を向上させることができます。これにより、ボットの応答、定義されたインテント、スロットを完全に制御しながら、より自然で耐障害性の高い会話体験を提供できます。例えば、複雑な発話や長い発話の解釈、スペルミスがあっても正確さを維持すること、冗長な入力からスロットを抽出すること、最小限のトレーニングデータでより良い結果が得られること、アクセス許可や統合設定を変更する必要がないなどです。 関連リンク Amazon Lex デベロッパーガイド Amazon Connect Customer Profiles が旅行・ホスピタリティ業界向けに対応 – 2025/6/10 旅行・ホスピタリティ業界のお客様が、業界固有のソースシステムから Amazon Connect カスタマープロファイルへのデータの取り込みとマッピングをよりシームレスに行い、エンドカスタマーの統合的で包括的なビューを作成できるようになりました。 関連リンク AWS Contact Center Blog – Your unified view of travelers and guests from Amazon Connect Customer Profiles Amazon Connect に統合的な顧客ビューのためのプロファイルエクスプローラーを追加 – 2025/06/09 Amazon Connect Customer Profiles の統合的でカスタマイズされたビューにアクセスできる新機能、プロファイルエクスプローラーを提供開始しました。この直感的なインターフェースにより、組織はすべての接点で顧客をより良く理解し、エンゲージメントを図ることができ、顧客情報、対話履歴、AI によるインサイトへのリアルタイムユーザーアクセスを提供することで、既存の Amazon Connect Customer Profiles サービスを強化します。 プロファイルエクスプローラーを使用することで、ユーザーはメール、電話番号、予約参照番号など、複数の識別子を同時に使用してエンドカスタマーをリアルタイムで検索し、見つけることができます。カスタマーサービスチームは、人口統計データ、コミュニケーション履歴、行動パターン、セグメントメンバーシップなど、特定のニーズに最も関連性の高い情報を強調表示するようにビューをカスタマイズできます。プロファイルエクスプローラーはまた、主要なパターンを強調し、パーソナライズされた行動インサイトを提供する AI が生成する顧客サマリーを提供し、組織が顧客体験を改善しロイヤルティを促進するためのデータ駆動型の意思決定を支援します。 関連リンク 製品ページ 管理者ガイド Amazon Connect Customer Profiles の計算属性を強化 – 2025/06/09 Amazon Connect Customer Profiles は、タイムスタンプコントロール、過去データのバックフィル、および改善された制限を備えた強化された計算属性を提供し、企業が顧客データを実用的なインサイトに変換できるようになりました。顧客は今後、将来の日付のイベントを含むデータにタイムスタンプを指定し、制限が拡大された状態で過去のデータ情報を処理できるようになりました。Amazon Connect Customer Profiles は、エンジニアリングリソースを必要とせずに、顧客の行動データ（連絡、注文、ウェブ訪問など）を、プロアクティブなアウトバウンドキャンペーン、動的ルーティング、IVR のパーソナライズを推進するための顧客の優先チャネルなどの実用的なインサイトに変換する計算属性を提供します。新機能により、顧客は計算に使用されるタイムスタンプを制御し、取り込み順序に関係なく適切な時系列順序を確保することで、より正確で関連性の高い計算属性を作成できるようになりました。新しい過去データ計算機能により、新しい属性を作成する際に以前に取り込まれたデータが自動的に含まれ、顧客エンゲージメントに関する有意義なインサイトを得るための待ち時間が不要になります。これらの機能強化により、今後の予約の追跡、長期的な顧客行動パターンの分析、顧客生涯価値の評価、顧客とのやり取りの前にエージェントが関連するコンテキストを準備できることを確保するなど、高度なユースケースが可能になります。 関連リンク 管理者ガイド API リファレンス Amazon Connect のマルチパーティコールの保留時間追跡を強化 – 2025/06/06 Amazon Connect は、コンタクトレコードの新しいエージェント開始保留時間フィールドを通じて、マルチパーティ通話シナリオにおける個々のエージェントが開始した保留の時間を追跡できるようになりました。この新しいフィールドにより、コンタクトセンターのマネージャーは、顧客とのやり取り中の個々のエージェントレベルでの保留パターンについてのインサイトを得ることができます。 関連リンク 管理者ガイド Amazon Connect の外部音声転送が 5つの追加 AWS リージョンで利用可能に – 2026/06/05 Amazon Connect の外部音声転送が、アジアパシフィック（シドニー）、アジアパシフィック（東京）、カナダ（中部）、ヨーロッパ（フランクフルト）、ヨーロッパ（ロンドン）の AWS リージョンで利用可能になりました。外部音声転送により、Amazon Connect から公衆電話網を使用せずに、音声通話とメタデータを他の音声システムに直接転送できます。これにより、既存の音声システムの手前で Amazon Connect の電話機能とインタラクティブ音声応答（IVR）を使用することができ、顧客体験の向上とコスト削減に役立ちます。 関連リンク 管理者ガイド 3. AWS Contact Center Blog のご紹介 組織全体で Amazon Connect のフロー操作を監査する方法 (日本語翻訳記事) コンタクトセンター運営における包括的な監査証跡の取得と一元的な可視性の維持は、セキュリティ、コンプライアンス、および運用のベストプラクティスの観点で重要です。以前のブログ記事「 AWS CloudTrail と Amazon Athena による組織内の Amazon Connect API アクティビティの調査 」では、お客様が AWS CloudTrail と Amazon Athena を活用して、Amazon Connect のコンタクトセンター環境の中で行われる様々な API 呼び出しの可視性と監査可能性を実現する方法について説明しました。これは、組織がコンタクトセンター運営の監視および調査をできるようにするための重要な第一歩でした。 Amazon Connect は、さらに一歩進んだ AWS CloudTrail サポートとして、 Amazon Connect コンソールのフロー管理ページのアクティビティに対応 しました。これは、ユーザーがフローを追加、更新、または削除するたびに、そのアクティビティの記録が CloudTrail ログに取得されることを意味します。この新機能により、コンタクトセンターチームはさらなる可視性、レポーティング、およびコンプライアンスの利点を得ることができます。この、続編となるブログ記事では、お客様が AWS 環境全体で Amazon Connect のフロー管理のアクティビティを一元的に分析および監査する方法について、より詳しく説明します。 The future of customer service is here: From contact centers to experience hubs (英語記事) Amazon Connect は、従来のコンタクトセンターを AI を活用した体験ハブへと変革し、カスタマーサービスでのやり取りを革新しています。このプラットフォームは 1日 1,000万件以上のコンタクトセンターでのやり取りをサポートし、単なる問題解決ではなく、意味のある関係構築に重点を置いています。この変革は、受動的な問題解決から積極的な顧客エンゲージメントへの転換を表しており、人間の共感と AI の知能を組み合わせて、大規模なパーソナライズされた体験を提供します。このブログではこうした変革を実現するための要点と実例をご紹介します。 Your unified view of travelers and guests from Amazon Connect Customer Profiles (英語記事) Amazon Connect Customer Profiles は、旅行・ホスピタリティ企業向けに、よりパーソナライズされた顧客体験を提供するための新しい業界特化型機能を発表しました。この解決策は、75 以上のソースからのデータを自動化されたプロセスで統合し、旅行者やゲストの統合的なビューを提供することで、断片化した顧客データの課題に対応します。このサービスには、旅行・ホスピタリティのユースケース向けに事前設定されたデータモデルが含まれており、実用的な洞察を生み出し、顧客行動を予測するための生成 AI 機能で強化されています。このブログでは、旅行会社やホスピタリティ企業が Amazon Connect Customer Profiles を使用して、旅行者とゲストの統一されたプロファイルを作成し、マーケティングキャンペーン、パートナーシップ、測定のためのデータコラボレーションを改善し、生成 AI を使用してよりパーソナライズされたエンゲージメントとサービスを提供する方法について説明します。 今月のお知らせは以上です。皆さんのコンタクトセンター改革のヒントになりそうな内容はありましたでしょうか？ぜひ、実際にお試しいただき、フィードバックをお聞かせ頂けますと幸いです。 シニア Amazon Connect ソリューションアーキテクト 坂田 陽一郎

本ブログは 2025 年 6 月 17 日に公開された Blog “ Improve your security posture using Amazon threat intelligence on AWS Network Firewall ” を翻訳したものです。 お客様は AWS Network Firewall を使用して、一般的なセキュリティ脅威からワークロードを保護できます。しかし、 アクティブな脅威 (active threat) から保護する場合に、AWS ワークロードへの脅威検出が限られたサードパーティの脅威フィードやスキャナーに依存せざるを得ないことがよくあります。従来のご自身で脅威インテリジェンスフィードを取得してカスタムルールでセキュリティを管理するアプローチでは、対応が遅れ、AWS ワークロードに関連するアクティブな脅威にさらされる可能性があります。お客様は、自動的に脅威が分析され複数のセキュリティ制御ポイントで対策が展開されるマネージド型アプローチを求めており、一貫した防御を確立し、クラウドインフラストラクチャ全体でアクティブな脅威から迅速に保護できる統合された AWS ネイティブソリューションを望んでいます。 このブログでは、Network Firewall の新しい機能のアクティブ脅威防御 (active threat defense) を紹介します。アクティブ脅威防御は、AWS のワークロードに関連するアクティブな脅威から保護でき、マネージドルールグループで提供されます。AWS のグローバルインフラストラクチャで観測された広範な脅威インテリジェンスを活用して、自動化されたインテリジェンス駆動型のセキュリティ対策を提供します。この機能は、Amazon の脅威インテリジェンスシステム MadPot を使用しており、マルウェアをホストする URL、ボットネットのコマンド＆コントロールサーバー、暗号通貨マイニングプールなどの攻撃インフラストラクチャを継続的に追跡し、アクティブな脅威の侵害指標 (IOC) を特定します。 アクティブ脅威防御は、Active Threat Defense ルールグループ AttackInfrastructure として提供され、検出された攻撃インフラストラクチャとの通信をブロックすることで悪意のあるネットワークトラフィックから保護します。マネージドルールグループをファイアウォールポリシーで構成すると、Network Firewall は自動的に、コマンド＆コントロール (C2)、マルウェアステージングホスト、シンクホール、アウトオブバンドテスト (OAST)、マイニングプールなどの指標カテゴリに対する悪意のある IP、ドメイン、URL へのトラフィックをブロックするようになります。TCP、UDP、DNS、HTTPS、HTTP などの様々なプロトコルに対する受信トラフィックと送信トラフィックの包括的なフィルタリングを実装し、特定の検証済み脅威指標を使用して高い精度を実現し、誤検知を最小限に抑えます。 アクティブ脅威防御を備えた Network Firewall は、以下のメカニズムを使用して AWS ワークロードを保護します。 脅威防止 : Amazon の脅威インテリジェンスを使用して AWS のワークロードを標的とするアクティブな脅威を特定し、防止することで、悪意のあるトラフィックを自動的にブロックします 迅速な保護 : 新たに発見された脅威に基づいて Network Firewall のルールを継続的に更新し、それらに対する即時の保護を可能にします 合理化された運用 : 脅威リスト名「Amazon Active Threat Defense」でマークされた GuardDuty の検出結果は、Network Firewall でアクティブ脅威防御が有効になっている場合に自動的にブロックできるようになりました 集団防御 : ディープ脅威検査 (DTI) により脅威インテリジェンスの共有が可能になり、アクティブ脅威防御のマネージドルールによる保護が向上します 図 1 は、Network Firewall での アクティブ脅威防御マネージドルールグループの使用を示しています。 MadPot から収集された脅威データを使用して、AWS マネージドルールグループにステートフルルールが自動的に作成される様子を示しています。 図 1: アクティブ脅威防御を備えた Network Firewall 開始ガイド アクティブ脅威防御マネージドルールグループは、AWS マネジメントコンソール、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS SDK を使用して、Network Firewall 内で直接有効にすることができます。その後、マネージドルールグループを Network Firewall ポリシーに関連付けることができます。ルールグループは、新しい脅威指標とシグネチャで定期的に更新され、非アクティブまたは期限切れのシグネチャは自動的に削除されます。 前提条件 アクティブ脅威防御を備えた Network Firewall を使い始めるには、Network Firewall コンソールにアクセスするか、 AWS Network Firewall 開発者ガイド を参照してください。アクティブ脅威防御は、AWS GovCloud (米国) リージョンと中国リージョンを含め、Network Firewall が現在利用可能なすべての AWS リージョン でサポートされています。 Network Firewall を初めて使用する場合は、以下の前提条件を完了していることを確認してください。すでにファイアウォールポリシーとファイアウォールがある場合は、このセクションをスキップできます。 ファイアウォールポリシーを作成する ファイアウォールを作成する アクティブ脅威防御 (Active Threat Defense) マネージドルールグループの設定 前提条件が整ったら、アクティブ脅威防御マネージドルールグループを設定して使用できます。 マネージドルールグループの設定 AWS Network Firewall コンソールで、ナビゲーションペインの ファイアウォールポリシー を選択します。 既存のファイアウォールポリシーまたは前提条件として作成したポリシーを選択します。 図 2: Network Firewall ポリシーの選択 下にスクロールして ステートフルルールグループ を表示します。右側で アクション を選択し、 マネージドステートフルルールグループを追加 を選択します。 図 3: ルールグループの追加 マネージドステートフルルールグループを追加 ページで、下にスクロールして Active Threat Defense を表示します。ルールグループ AttackInfrastructure を選択します。 ディープ脅威検査 の要件に基づいて、Network Firewall にサービスログを処理させたくない場合はオプトアウトできます。 ポリシーに追加 を選択します。 図 4: ポリシーへのルールグループの追加 次のページで、マネージドルールグループがポリシーに追加されたことを確認できます。 図 5: マネージドルールグループがポリシーに追加されたことの確認 料金 アクティブ脅威防御の料金については、 AWS Network Firewall の料金 をご覧ください。 考慮事項 最初の考慮事項は、TLS インスペクション機能をアクティブ脅威防御マネージドルールグループと併用することで、Network Firewall が HTTPS トラフィックに関連する脅威の検出と緩和においてより効果的になることです。TLS インスペクションにより、アクティブ脅威防御は暗号化された接続の実際のコンテンツを分析できるようになり、検出されずに通過する可能性のある悪意のある URL を特定してブロックすることができます。このプロセスでは、トラフィックを復号し、既知の悪意のある URL パターンや動作がないかコンテンツを検査し、安全と判断された場合はトラフィックを再暗号化します。TLS インスペクションに関する考慮事項の詳細については、 TLS インスペクションの考慮事項 をご覧ください。組織はセキュリティ上の利点と潜在的な遅延の導入のバランスを取り、復号された機密データを適切に処理するための適切な制御を確保する必要があります。 もう一つの考慮事項は、誤検知の緩和です。このマネージドルールグループをファイアウォールポリシーで使用する場合、 ルールグループのアラート設定 を編集して、緩和戦略の一環として誤検知を特定することができます。詳細については、 誤検知の緩和 をご覧ください。 最後の考慮事項は、マネージドルールグループの使用が各ポリシーのステートフルルールの制限にどのようにカウントされるかです。詳細については、 AWS Network Firewall のクォータ および AWS Network Firewall でのルールグループ容量の設定 をご覧ください。 まとめ このブログでは、AWS Network Firewall のアクティブ脅威防御マネージドルールグループを使用して、アクティブな脅威からワークロードを保護する方法を説明しました。 Amit Gaur Amit は AWS のクラウドインフラストラクチャアーキテクトであり、テクノロジーへの情熱と知識共有をネットワーキングコミュニティにもたらしています。ネットワークアーキテクチャ設計を専門とし、お客様が AWS 上で高度にスケーラブルで回復力のある環境を構築するのを支援しています。技術的なガイダンスとアーキテクチャの専門知識を通じて、Amit はお客様がシステムのスケールと信頼性を確保しながら、クラウド導入の旅を加速できるようにします。 Tim Sutton Tim は AWS のシニアクラウドインフラストラクチャアーキテクトであり、テクノロジーにおける 20 年以上の経験と、クラウドテクノロジー、エンタープライズアーキテクチャ、ビジネス変革における豊富な経験を持っています。Tim は、お客様がスケーラブルなクラウドソリューションを設計・実装し、テクノロジーを通じてビジネス目標を達成するのを支援することに情熱を持っており、次世代のクラウドプロフェッショナルの指導も行っています。 Prashanth Kalika Prashanth は、ネットワーキング、セキュリティ、クラウドのユースケースに対する革新的でスケーラブルなソリューションの開発において 20 年以上の経験を持っています。現在は、お客様がクラウドワークロードをより適切に保護できるよう、AWS Firewall の高度な脅威インテリジェンス機能の開発に注力しています。Prashanth は、組織が堅牢なネットワーク防御を維持しながら進化するサイバー脅威に先んじることを支援するセキュリティソリューションの構築に情熱を注いでいます。 Saleem Muhammad Saleem は AWS Network &amp; Application Protection のシニアマネージャー (プロダクトマネジメント) です。ミッションクリティカルなワークロードを保護するためのソリューション構築に情熱を注いでいます。AWS 以前は、サンフランシスコベイエリアの複数の数十億ドル規模の IT 製品・サービス企業でインキュベーションプロジェクトに携わっていました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 6 月 16 日に公開された Blog “ How AWS improves active defense to empower customers ” を翻訳したものです。 AWS ではセキュリティが最優先事項であり、本日は AWS をあらゆるワークロードを実行するための最も安全な場所にするという目標に向けた取り組みについてご紹介します。このブログの以前の投稿では、 MadPot (グローバルハニーポット) 、 Mithra (ドメイングラフニューラルネットワーク) 、 Sonaris (ネットワーク脅威緩和) などの内部のアクティブディフェンスシステムの詳細を共有しました。AWS では脅威インテリジェンスと自動対応の効果を高め、攻撃の検出と防止に向けた新たな手法を開発し続けています。今回は、マルウェア、ソフトウェアの脆弱性、AWS リソースの設定ミスに関連するアクティブディフェンスの進歩についてご紹介します。前述のブログ投稿でご紹介したシステムと同様に、これらは、AWS をご利用している全てのお客様に自動的に適用され、常に改善されているセキュリティ機能です。これらのトピックについては、 re:inforce 2025 Innovation Talk SEC302 でより詳しく説明します。 マルウェアの拡散阻止 金銭的な動機を持つ脅威アクターは、ネットワーク化された幅広い資産へのアクセスを獲得しようとします。脅威アクターが制御するリソースが多いほど、隠れる場所が増え、不正な操作から利益を得られる期間が長くなります。そのため、脅威アクターのマルウェアには、新しいターゲットをスキャンし、ネットワーク経由で自身のコードを他のシステムに複製し、感染を拡大させる機能がよく含まれています。このような急速に拡散する動作を放置すると、ネットワークの輻輳、サービスの可用性の喪失、データの破壊につながるリスクがあります。AWS はこのような振る舞いを可能な限り阻止したいと考えています。 AWS が採用している効果的な戦略の一つは、脅威アクターがマルウェアを集中管理している主要インフラを特定することです。多様な技術を使用して、脅威インフラの特定、検証、追跡、妨害を行っています。さまざまなセンサー位置から得られたネットワークトラフィックログ、ハニーポット活動記録、マルウェアの検体を分析して、その情報を活用して、ボットネット、不正プロキシ、マシン間で直接拡散するマルウェアを阻止しています。過去 12 か月間で、AWS は 31.5 万以上の異なる Amazon Elastic Compute Cloud (Amazon EC2) インスタンスへ試みられた 400 万件以上のマルウェア感染を阻止しました。これらのマルウェア感染からワークロードを保護することで、AWS のネットワークとお客様だけでなく、さらなるマルウェアの拡散からインターネット全体も保護しています。 現在、AWS はネットワークルーティングレベルでお客様にアクティブディフェンス対策を適用しています。場合によっては、これらのクラウドネットワークルーティングの変更の規模が正当なお客様ワークロードに影響を与える可能性があるため、対策を講じないことを決定することもあります。このような場合、お客様固有のワークロードに対して AWS Network Firewall によるセキュリティ制御を提供します 。Amazon 脅威インテリジェンスを使用する新しい アクティブ脅威防御マネージドルールグループ により、AWS のグローバルインフラストラクチャ全体で観測された脅威活動から Amazon Virtual Private Cloud (Amazon VPC) ワークロードを保護することができます。有効にすると、マネージドルールの設定、一致するトラフィックの侵害指標の表示、コマンド＆コントロール通信、埋め込み URL、悪意のあるドメインなど、脅威アクターのインフラストラクチャに関連する不審なトラフィックの自動ブロックが可能になります。 脅威ハンティングとソフトウェア脆弱性の緩和における進歩 Amazon では、 バグバウンティ 、 脆弱性開示 、 オープンソース貢献 のプログラムでソフトウェア脆弱性研究をサポートしていることを誇りに思っています。また、Amazon が提供するソフトウェアとサービスの CVE 番号付与機関 (CNA) になることで、CVE プロセスのより積極的な参加者になりました。公開 CVE データベースのおかげで、脆弱性研究は加速しており、報告された CVE は 2013 年以降、前年比 21% 増加し、2024 年には 4 万件以上の CVE が公開されています。脆弱性を発見して解決するこの好循環は、時間の経過とともにサイバーセキュリティを向上させますが、AWS は脅威アクターが未解決の脆弱性を探して無許可でリソースにアクセスしようとしているのを観測しています。 AWS は MadPot と Sonaris を拡張して、より広範囲の悪意のある脆弱性スキャンと攻撃活動の特定・ブロックし、すべての AWS のお客様を脆弱性の露出から保護しています。実際の攻撃を特定するために、MadPot に何百もの新しい検出機能とサービスをエミュレートする機能を追加しました。可視性を拡大するにつれて、AWS は AWS ネットワーク全体で毎日何億もの CVE を悪用する試みをブロックし続けています。 これらのアクティブディフェンスシステムが CVE 悪用の攻撃を阻止する能力を向上させるにつれて、図 1 に示すように、過去 12 か月間で攻撃の総数は 55% 以上減少しました。この観測結果には AWS の制御外の要因も影響していますが、CVE 悪用の攻撃が減少していることを嬉しく思います。この傾向は、2025 年に行った検出、リージョン化、レイテンシー、ガードレールの改善と一致しています。すべてを阻止できるシステムはないため、悪用の試みが少ないということは、幅広いワークロードにわたるリスクが低減されることを意味します。 図 1: グローバルな悪意のある脆弱性悪用試行の減少を示すグラフ 実際の既知の悪用を特定するこの取り組みは、 Amazon Inspector の脆弱性インテリジェンス のユーザーに直接恩恵をもたらします。これにより、セキュリティ強化リソースをどこに投入するかを優先順位付けするための Amazon Inspector スコアがお客様に提供されます。これには、観測された悪用試行の最新日付、攻撃活動に関連する MITRE ATT&amp;CK 手法、標的とされた業界が含まれます。 AWS 上に構築されたアーキテクチャの保護 AWS はお客様のコンピューティングおよびネットワークリソースを積極的に防御しています。また、お客様が依存する AWS ネイティブリソースも防御しています。AWS アクセスキー認証情報は、お客様のアカウントへのアクセスを可能にする重要なリソースです。 AWS Identity and Access Management のベストプラクティス では、お客様が認証情報を悪用から守るための実証済みの手法を共有しています。アクティブディフェンスを通じて、AWS はこれらのベストプラクティスをまだ採用していないお客様をさらに支援しています。 AWS は毎日平均 1 億 6,700 万件の悪意のあるスキャン接続から、意図せず公開された AWS アクセスキーペアを保護しています。アクセスキーが他の手段で発見された場合に備えて、お客様が管理する IAM 認証情報の保護を拡張しました。脅威インテリジェンス分析により、お客様が管理する認証情報が脅威アクターに知られていることが判明した場合、高い権限を持つ操作へのアクセスを制限する対策を講じます。また、認証情報がどのように公開されたかを特定するためのカスタマイズされた通知をお客様に送信します。これらの取り組みは毎日お客様に成果をもたらしています。以下は、定期的に寄せられるお客様からのフィードバックの例です。 これは、数週間前に AWS からの別のアラームに基づいて既にローテーションしたアクセスキーです。新しくローテーションしたアクセスキーが、AWS からの 2 回目のアラームに含まれていたことがわかりました。つまり、アクセスキーにリンクされていたアプリがまだそれを漏洩させていたということです。 そこで月曜日に開発チームと一緒に調査し、アプリがどこからシークレットを漏洩させていたかを見つけ、修正し、公開されていたすべてのシークレット (IAM アクセスキー以外にもありました) をローテーションし、アプリに追加のセキュリティを組み込みました。 これらのアラートに再度感謝します。非常に貴重です。 – AWS のお客様 2024 年 11 月と 12 月の特定の脅威活動の事例では、お客様から Amazon Simple Storage Service (Amazon S3) ストレージ内のオブジェクトに対するランサムウェア活動が報告されました。これらの身代金要求の脅威が、公開されたお客様管理の IAM アクセスキーと高い相関関係があることが判明しました。AWS は公開されたアクセスキーを隔離し、お客様の通常の運用が安全に継続できるよう配慮しました。攻撃のリスクが高まっていたため、公開されている可能性の高いアクセスキーについて、お客様に積極的な通知を再送信しました。この期間中、AWS はお客様と協力して 3 万件以上の公開された認証情報を無効化しました。この脅威活動が始まって以来、AWS は 9 億 4,300 万件以上の悪意のあるお客様の Amazon S3 オブジェクト暗号化の試みを防止してきました。 これらの認証情報公開の検出は Amazon GuardDuty 拡張脅威検出 に取り込まれ、最新のクラウド環境における脅威検出と対応オペレーションを簡素化します。 より良い協力関係 AWS のアクティブディフェンスの取り組みは、システム基盤の各層に複数のセキュリティ対策を配置し、脅威インテリジェンスを積極的に活用することでリスクを減らしています。この多層防御アプローチは、クラウドセキュリティを効果的に強化しています。AWS はサービスに追加コストなしでアクティブディフェンスを組み込むことで、お客様が幅広い脅威から保護されるようにしています。 AWS はお客様の保護を常に改善し続けていますが、お客様のワークロード内部を見ることはないため、私たちの取り組みの一部は本質的に確率的なものです。検出が曖昧な状況では、お客様の本番システムに影響を与える可能性があるため、アクティブディフェンスを適用しません。安全を確保するために、お客様は自身の防御を決して怠るべきではありません。 AWS Identity and Access Management (IAM) 、 AWS Shield Advanced 、 AWS WAF 、 AWS Network Firewall 、 Amazon GuardDuty 、 Amazon Inspector などの AWS セキュリティサービスは、お客様が独自のニーズに合わせて設定できる予防、検出、対応を提供します。良いニュースは、協力することで、私たちは皆にとってインターネットをより安全にしているということです。 Stephen Goodman Amazon アクティブディフェンスのシニアマネージャーとして、Stephen はデータ駆動型のプログラムを主導し、AWS のお客様とインターネットを脅威アクターから保護しています。 Tom Scholl AWS VP および Distinguished Engineer の Tom は、悪意のあるアクターからのトラフィックをその発生源で追跡することで、サイバー攻撃を阻止するために世界中のネットワークと協力しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 6 月 17 日に公開された Blog “ How AWS is simplifying security at scale: Four keys to faster innovation from AWS re:Inforce 2025 ” を翻訳したものです。 私がセキュリティ分野でキャリアを始めた当時は、システムを保護することは生産性を犠牲にするという事実を多くの人が受け入れていました。当時からそうである必要はなく、現在は確実にそうではありません。クラウド、特に AWS クラウドがその大きな理由です。しかし、テクノロジーが進化し、システムがより複雑になるにつれて、大規模な運用にはセキュリティへの新しいアプローチが求められます。私たちはお客様のセキュリティを最優先事項として考え、組織が安心して積極的なイノベーションを推進し、迅速にビジネスを拡大できるようなガードレールを構築しています。 AWS CISO としての新たな役割において、私は日々これが実現されているのを目の当たりにしています。お客様と会うと、生成 AI のようなテクノロジーへの期待と同時に、複雑な環境の保護や新しいタイプのリスク管理に関する質問が寄せられます。彼らはイノベーションに熱心ですが、その意欲的な取り組みをセキュリティ基盤がしっかりと支えられるという安心感を必要としています。セキュリティを損なうことなくビジネスを迅速に前進させたいと考えているのです。 本日 2025 年 6 月 17 日、 re:Inforce で、AWS がこれらのニーズからさかのぼって考え、クラウドでのセキュリティをスケールする方法を根本的に変革する取り組みについて共有しました。すべては 4 つの重要な柱に基づくセキュリティ基盤から始まります。アイデンティティとアクセス管理、データとネットワークセキュリティ、監視とインシデント対応、そしてマイグレーション・モダナイゼーション・パッチ適用の継続的な作業です。これらの柱全体で成熟したセキュリティモデルを持つ組織が、最も速くビジネス変革やイノベーションを実現しています。これらの各領域において、AWS はお客様が新しいテクノロジーを採用し、革新的な取り組みに自信を持って挑戦できるようなセキュリティ機能の提供に注力しています。 クラウドのためのアイデンティティのスケーリング お客様がクラウド運用を急速に拡大する中で、複雑な環境全体でのアイデンティティとアクセスの管理がますます困難になっていると伺っています。彼らは強力なセキュリティを維持しながらビジネスとともに成長できるソリューションを必要としています。アイデンティティとアクセス管理はクラウドセキュリティのあらゆる側面の基盤であり、この分野での成功には厳格な認証コントロールとアクセス権限への包括的な可視性の両方が必要です。 本日、 AWS IAM Access Analyzer の新しい内部アクセス検出結果を発表できることを嬉しく思います。この機能は、組織が大規模に機密データへのアクセスを管理する方法を変革し、お客様が成長するにつれて直面する複雑さに対応します。自動推論のテクノロジーを使用して、多様なポリシータイプにわたる複雑な権限レイヤーを分析し、セキュリティチームに組織内の誰がどのリソースにアクセスできるかについての包括的な可視性を提供します。新しく付与されたアクセスの日次監視と通知により、最も複雑な環境でも自信を持って最小権限アクセスを実装できるよう支援しています。これにより、お客様はクラウドでスケールする際にビジネスが求める俊敏性を維持しながら、重要なリソースのアクセスコントロールを強化するための可視性を得ることができます。 データとネットワークセキュリティを通じた変革の実現 お客様はビジネスを変革することに意欲的ですが、急速なイノベーションに対してセキュリティ対策もしっかりと対応できるという安心感が必要とされています。これは特に大規模なネットワークとデータの保護に関して言えることです。基調講演では、Comcast の CISO である Noopur Davis 氏が、彼女の組織がどのように広大なネットワークと顧客データを保護しながら、急速なイノベーションを可能にしているかを共有しました。何百万人もの顧客が彼らのサービスに依存している中で、Comcast のアプローチ「セキュリティは単に防御するだけでなく、変革を可能にするべき」に私は共感しました。 AWS はこのビジョンを、大規模なセキュリティを簡素化する新機能で実現しています。本日、 AWS Certificate Manager が ACM 発行の公開証明書とその秘密鍵を AWS 内外で使用するためにエクスポートできるようになったことを発表しました。これにより、ワークロードのセキュリティ確保に役立つ柔軟性を備えた自動証明書管理が可能になります。また、 AWS Shield を拡張し、ネットワークセキュリティ分析を実行して構成の問題を特定し、修復の推奨事項を提供する強化されたネットワークおよびアプリケーション保護機能を追加しています。AWS の生成 AI 搭載アシスタント Amazon Q Developer を使用して、シンプルな自然言語で実用的な洞察を得ることもできます。これらのイノベーションにより、チームは環境がより複雑になっても、データを保護し、進化する脅威に先んじることができます。 脅威検出と対応の向上 お客様からは、特にクラウド運用の規模が拡大するにつれて、日々進化するセキュリティ脅威に対応し続けることの難しさが共通の課題として挙げられています。従来の自動化は増大する複雑さを管理するのに役立ちますが、AI はセキュリティ運用を変革するさらに強力な機会を表しています。慎重に実装すると、AI は複雑な攻撃パターンを特定し、誤検知を減らし、大規模な対応を自動化する能力を劇的に向上させます。 本日 re:Inforce で、2 つの重要なセキュリティイノベーションを発表しました。 Amazon GuardDuty 拡張脅威検出の機能拡張と、これらのニーズに直接対応する強化された AWS Security Hub です。これらのサービスを組み合わせることで、大規模なセキュリティの簡素化を支援します。GuardDuty は AWS がトレーニングした AI と機械学習 (AI/ML) モデルを使用して、高度な多段階の脅威を検出し、実用的な洞察を提供します。一方、Security Hub はセキュリティシグナルを自動的に分析して相関付け、明確で優先順位付けされたアクションに変換することで、重要なセキュリティ問題を優先順位付けします。このアプローチにより、チームは AWS 環境全体でセキュリティリスクを効率的に検出・対応できるという安心感を持ちながら、自信を持って運用の規模を拡大することができます。 より良いセキュリティへの道のりの加速 AI や自動化などの高度な機能がセキュリティ運用を強化する一方で、セキュリティは基盤が最も重要です。クラウドへの移行は、オンプレミス環境では実現困難なレベルの、より強固なセキュリティ基盤を構築できる大きな変革のチャンスとなります。AWS に移行することで、物理的なインフラストラクチャセキュリティを管理する必要性が減少し、継続的に更新・維持される組み込みの保護機能を活用することができます。 クラウドの採用を成功させるには、単純なリフト＆シフトを超える必要があります。モダナイゼーションがこれらの利点を実現するための鍵です。 AWS Lambda 、 Amazon Simple Storage Service (Amazon S3) 、または AWS Key Management Service (AWS KMS) などのマネージドサービスを使用するためにスタックの上位にソリューションを移行することで、後付けではなく組み込まれたセキュリティコントロールの恩恵を受けることができます。これらのサービスは AWS によって継続的にパッチが適用され維持されるため、チームはお客様のためのイノベーションに集中できます。結局のところ、より良いセキュリティへの最速の道は、コアとなる保護機能がすでに組み込まれている道なのです。 セキュリティ成功のためのパートナーシップ セキュリティ変革は組織が単独で取り組む必要のある旅ではありません。私はキャリアを通じて、適切なパートナーシップが成功を加速させ、複雑な課題に新しい視点と深い専門知識をもたらすことを目の当たりにしてきました。AWS のセキュリティパートナーは、ID ソリューションの実装からセキュリティ運用の最新化まで、本日ご紹介した 4 つの柱全体にわたってお客様を支援しています。彼らは技術的な複雑さとクラウドでのセキュリティをスケールするビジネス上の現実の両方を理解しており、多くの場合、各業界に特化した専門知識を持っており、これによりお客様は自信を持ってイノベーションをより迅速に加速することができます。 今後の展望 クラウドでの運用をスケールする際、AWS の目標は強力なセキュリティコントロールを維持しながら迅速に進む自信をお客様に提供することです。セキュリティがビジネスと共に自然にスケールすると、チームはインフラストラクチャの管理ではなく、次の構築に集中できます。 AWS が前例のない規模でセキュリティを設計、構築、運用する方法についてさらに詳しく知るために、 re:Inforce でのイノベーショントーク にぜひご参加ください。これらの 1 時間のセッションでは、最新のクラウドセキュリティの主要な柱の、セキュアな基盤、回復力のあるアーキテクチャ、AI を活用したイノベーション、大規模な脅威インテリジェンスについて探求します。 AWS CISO としての役割に就くにあたり、私は今後の機会に活力を感じています。AWS は約 20 年間、急速に革新しながらも安全に提供できるユニークなセキュリティ文化を維持してきました。生成 AI と急速な技術変化の環境を進む中で、お客様の信頼を獲得するということは、イノベーションのペースに追いつくだけでなく、それをさらに成功させるお手伝いをすることを意味します。この使命を前進させることに、これ以上ないほどの興奮を感じています。 Amy Herzog Amy は AWS の副社長兼最高情報セキュリティ責任者 (CISO) であり、セキュリティが最優先事項である企業において、クラウドセキュリティの専門家からなるグローバル組織を率いています。AWS に入社する前は、Amazon のデバイスとサービス、メディアとエンターテイメント、広告事業の CISO を務め、Alexa+ や Ring などの消費者向けテクノロジー製品のセキュリティを監督し、低軌道衛星を通じて世界中の顧客とコミュニティに高速で信頼性の高いブロードバンドを提供する Amazon のイニシアチブである Project Kuiper の安全な開発において重要な役割を果たしました。Amy のキャリアは、サイバーセキュリティ、イノベーション、企業変革の交差点で 20 年以上にわたります。彼女は MITRE Corporation で 15 年間を過ごし、政府と産業界にまたがる複雑なセキュリティ課題に対する最先端のソリューションを開発しました。また、Pivotal Software、VMware、Travelers Insurance でリーダーシップの役割を担い、テクノロジー主導のビジネス変革に焦点を当てた 2 つのスタートアップを共同設立しました。Amy は Pomona College で数学の学士号を、MIT の Sloan School of Management で MBA を取得しています。また、複数の出版物の著者であり、2 つの特許を保有しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

Amazon Redshift は、クラウドで提供される完全マネージド型のペタバイト規模のデータウェアハウスサービスです。MPP (Massively Parallel Processing) アーキテクチャにより、クエリをコンピュートノード全体に分散してデータを処理します。各ノードは、割り当てられたデータに対して同一のクエリコードを実行し、並列処理を実現します。 Amazon Redshift は、データベーステーブルにカラムナーストレージを採用し、全体的なディスク I/O の必要量を削減しています。このストレージ方式は、クエリ時のデータ読み取りを最小限に抑えることで、分析クエリのパフォーマンスを大幅に向上させます。データは多くの組織にとって最も価値のある資産となり、データウェアハウスでのリアルタイムまたはニアリアルタイムの分析への需要を増加させています。この需要に応えるには、クエリのパフォーマンスを維持しながら、同時にデータをロードできるシステムが必要です。この投稿では、Amazon Redshift の同時データ取り込みオペレーションにおける主要な改善点をご紹介します。 書き込みワークロードにおける課題と問題点 データウェアハウス環境では、データへの同時アクセスの管理が重要でありながら、課題となっています。Amazon Redshift を使用するお客様は、さまざまなアプローチでデータを取り込んでいます。例えば、一般的に INSERT や COPY ステートメントを使用してテーブルにデータを読み込む方法があり、これらは 純粋な書き込み オペレーションとも呼ばれます。データの鮮度を最大化するために、低レイテンシーでの取り込みが要件となることがあります。これを実現するために、同じテーブルに対して同時にクエリを実行することができます。これを可能にするため、Amazon Redshift はデフォルトで スナップショット分離 を実装しています。スナップショット分離は、複数のトランザクションが同時に実行されている場合のデータ整合性を提供します。スナップショット分離は、各トランザクションがトランザクション開始時点のデータベースの一貫したスナップショットを参照することを保証し、データの整合性を損なう可能性のある読み取りと書き込みの競合を防ぎます。スナップショット分離により、読み取りクエリを並列に実行できるため、データウェアハウスが提供する完全なパフォーマンスを活用できます。 しかし、純粋な書き込みオペレーションは順次実行されます。具体的には、純粋な書き込みオペレーションはトランザクション全体で排他ロックを取得する必要があります。このロックは、トランザクションがデータをコミットした時点でのみ解放されます。このような場合、純粋な書き込みオペレーションのパフォーマンスは、セッション間での書き込みの直列実行速度によって制限されます。 これをより深く理解するために、純粋な書き込みオペレーションがどのように機能するかを見てみましょう。すべての純粋な書き込みオペレーションには、同じテーブルに対するスキャン、ソート、集計などの取り込み前のタスクが含まれます。取り込み前のタスクが完了すると、データの一貫性を維持しながらテーブルにデータが書き込まれます。純粋な書き込みオペレーションは直列に実行されるため、並列性がないことにより取り込み前のステップも直列に実行されていました。つまり、複数の純粋な書き込みオペレーションが同時に送信された場合、取り込み前のステップでさえ並列化されることなく、1 つずつ順番に処理されます。同一テーブルへの取り込みの並列性を向上させ、取り込みの低レイテンシー要件を満たすため、お客様はしばしばステージングテーブルを使用する回避策を採用しています。具体的には、ステージングテーブルに INSERT ... VALUES(..) ステートメントを送信します。その後、 ALTER TABLE APPEND を使用してターゲットテーブルにデータを追加する前に、ファクトテーブルや ディメンションテーブルなどの他のテーブルとの結合を実行します。このアプローチは、ステージングテーブルを維持する必要があり、 ALTER TABLE APPEND ステートメントの使用によるデータブロックの断片化により、より大きなストレージ容量が必要になる可能性があるため、望ましくありません。 まとめると、INSERT 文と COPY 文の同時実行は、排他的なロック動作のため、Amazon Redshift でのデータ取り込みワークフローのパフォーマンスと効率を最大化する際に課題となります。これらの制限を克服するには、追加の複雑さとオーバーヘッドを伴う回避策を採用する必要があります。次のセクションでは、Amazon Redshift が同時挿入の改善によってこれらの課題にどのように対処したかを説明します。 同時挿入処理とそのメリット Amazon Redshift の パッチ 187 では、同時挿入のサポートによりデータ取り込みの同時実行性が大幅に向上しました。これにより、COPY や INSERT ステートメントなどの純粋な書き込みオペレーションの同時実行が改善され、Amazon Redshift へのデータロードにかかる時間が短縮されます。具体的には、複数の純粋な書き込みオペレーションが同時に進行し、スキャン、ソート、集計などの取り込み前のタスクを並列で実行できるようになりました。 この改善を視覚化するために、異なるトランザクションから同時に実行される 2 つのクエリの例を考えてみましょう。 以下はトランザクション 1 のクエリ 1 です。 INSERT INTO table_a SELECT * FROM table_b WHERE table_b.column_x = 'value_a'; 以下は、トランザクション 2 のクエリ 2 です。 INSERT INTO table_a SELECT * FROM table_c WHERE table_c.column_y = 'value_b' 次の図は、同時挿入機能のない場合の純粋な書き込みオペレーションを簡略化して視覚化したものです。 同時挿入機能がない場合、主要なコンポーネントは以下の通りです。 まず、純粋な書き込みオペレーション (INSERT) は、それぞれ table b と table c からデータを読み取る必要があります。 ピンク色のセグメントはスキャンステップ (データの読み取り) で、緑色のセグメントは書き込みステップ (実際のデータの挿入) です。 「同時挿入前」の状態では、両方のクエリが順次実行されます。具体的には、クエリ 2 のスキャンステップは、クエリ 1 の挿入ステップが完了するのを待ってから開始されます。 たとえば、異なるトランザクションで同じサイズのクエリを 2 つ実行する場合を考えてみましょう。両方のクエリは同じ量のデータをスキャンし、ターゲットテーブルに同じ量のデータを挿入する必要があります。両方のクエリが午前 10 時に発行されたとします。まず、クエリ 1 は午前 10 時から午前 10 時 50 分までデータをスキャンし、午前 10 時 50 分から午前 11 時までデータを挿入します。次に、クエリ 2 はスキャンと挿入の量が同じなので、午前 11 時から午前 11 時 50 分までデータをスキャンし、午前 11 時 50 分から午後 12 時までデータを挿入します。両方のトランザクションは午前 10 時に開始されました。エンドツーエンドの実行時間は 2 時間です（トランザクション 2 は午後 12 時に終了）。 次の図は、前の例と異なり、同時挿入機能が使用できる場合の純粋な書き込みオペレーションを簡略化して示したものです。 同時挿入機能が有効な場合、クエリ 1 とクエリ 2 のスキャンステップを同時に実行できます。いずれかのクエリがデータを挿入する必要がある場合は、順次実行されます。異なるトランザクションで同じサイズの 2 つのクエリを使用した同じ例を考えてみましょう。両方のクエリは同じ量のデータをスキャンし、ターゲットテーブルに同じ量のデータを挿入する必要があります。ここでも、両方のクエリが午前 10 時に発行されたとします。午前 10 時に、クエリ 1 とクエリ 2 が同時に実行を開始します。午前 10 時から午前 10 時 50 分まで、クエリ 1 とクエリ 2 は並行してデータをスキャンできます。午前 10 時 50 分から午前 11 時まで、クエリ 1 がターゲットテーブルにデータを挿入します。次に、午前 11 時から午前 11 時 10 分まで、クエリ 2 がターゲットテーブルにデータを挿入します。両方のトランザクションの合計実行時間は 1 時間 10 分に短縮され、クエリ 2 は午前 11 時 10 分に完了します。このシナリオでは、両方のクエリの取り込み前のステップ (データのスキャン) を同時に実行でき、前の例と同じ時間 (50 分) で完了します。ただし、ターゲットテーブルへの実際のデータ挿入は順次実行され、クエリ 1 が最初に挿入を完了し、その後クエリ 2 が続きます。これは Amazon Redshift の同時挿入機能のパフォーマンス上の利点を示しています。取り込み前のステップを同時に実行できるようにすることで、この機能が導入される前の順次実行と比較して、全体の実行時間が 50 分短縮されます。 同時挿入により、取り込み前のステップを並行して進めることができます。取り込み前のタスクには、スキャン、ソート、集計などの単一または複数の組み合わせがあります。クエリのエンドツーエンドの実行時間において、大幅なパフォーマンス向上が達成されます。 メリット サービスが自動的に同時挿入処理を行うため、追加の設定なしでこれらのパフォーマンス改善の恩恵を受けることができます。同時挿入の改善には複数のメリットがあります。同じテーブルに書き込む際のインジェストワークロードのエンドツーエンドのパフォーマンスが向上します。社内のベンチマークでは、同じテーブルへの同時挿入トランザクションにおいて、エンドツーエンドの実行時間が最大 40% 改善されることが示されています。この機能は、特にスキャン処理の多いクエリ (データの書き込みよりもデータの読み取りに時間を要するクエリ) に効果的です。クエリにおける scan:insert の比率が高いほど、より大きなパフォーマンスの改善が期待できます。 この機能は、 データ共有によるマルチデータウェアハウス書き込み のスループットとパフォーマンスも向上させます。データ共有を通じたマルチウェアハウス書き込みにより、専用の Redshift クラスターまたはサーバーレスワークグループ全体で書き込みワークロードをスケールでき、リソース使用率を最適化し、ETL (抽出、変換、ロード) パイプラインのより予測可能なパフォーマンスを実現できます。具体的には、データ共有を通じたマルチウェアハウス書き込みでは、異なるウェアハウスからのクエリが同じテーブルにデータを書き込むことができます。同時挿入により、リソースの競合を軽減し、クエリを同時に進行させることで、これらのクエリのエンドツーエンドのパフォーマンスが向上します。 次の図は、同時挿入における内部テストのパフォーマンス改善を示しています。オレンジ色のバーはデータ共有を通じたマルチウェアハウス書き込みのパフォーマンス改善を、青色のバーは同一ウェアハウスでの同時挿入のパフォーマンス改善を示しています。グラフが示すように、INSERT オペレーションに対して SCAN オペレーションの割合が高いクエリは、この新機能により最大 40% のパフォーマンス向上が得られます。 同時挿入を使用してインジェストパイプラインを管理することで、さらなるメリットを得ることができます。 ALTER TABLE APPEND ステートメントを使用する回避策ではなく、同時挿入の利点を活用して同じテーブルに直接データを書き込むことで、ストレージ使用量を削減できます。これには 2 つの利点があります。1 つは一時テーブルの排除、もう 1 つは頻繁な ALTER TABLE APPEND ステートメントによるテーブルの断片化の軽減です。さらに、複雑な回避策を管理する運用上のオーバーヘッドを避け、頻繁なバックグラウンドでの自動実行および手動実行の VACUUM DELETE オペレーションにより一時テーブルをターゲットテーブルに追加することによって引き起こされる断片化を軽減できます。 考慮事項 Amazon Redshift の同時挿入機能の強化は大きなメリットをもたらしますが、スナップショット分離環境で発生する可能性のあるデッドロックシナリオに注意することが重要です。具体的には、スナップショット分離環境では、同じテーブルで同時書き込みトランザクションを実行する際に、特定の条件下でデッドロックが発生する可能性があります。スナップショット分離のデッドロックは、同時実行される INSERT 文と COPY 文がロックを共有して処理を進めている際に、別のステートメントが同じテーブルに対して排他ロックを必要とするオペレーション (UPDATE、DELETE、MERGE、または DDL オペレーション) を実行しようとする場合に発生します。 以下のシナリオを考えてみましょう。 トランザクション 1: INSERT/COPY INTO table_A ; トランザクション 2: INSERT/COPY INTO table_A; &lt;UPDATE/DELETE/MERGE/DDL statement&gt; table_A 共有ロックを持つ同じテーブルで INSERT および COPY オペレーションを含む複数のトランザクションが同時に実行され、そのうちの 1 つのトランザクションが純粋な書き込みオペレーションの後に UPDATE、MERGE、DELETE、DDL ステートメントなどの排他ロックを必要とするオペレーションを実行する場合、デッドロックが発生する可能性があります。このような状況でデッドロックを回避するには、排他ロックを必要とするステートメント (UPDATE、MERGE、DELETE、DDL ステートメント) を別のトランザクションに分離することで、INSERT および COPY ステートメントを同時に進行させ、排他ロックを必要とするステートメントをその後に実行することができます。あるいは、同じテーブルに対して INSERT および COPY ステートメントと MERGE、UPDATE、DELETE ステートメントを含むトランザクションの場合、アプリケーションにリトライロジックを組み込むことで、潜在的なデッドロックに対処することができます。デッドロックの詳細については、 単一のテーブルが関連する同時書き込みトランザクションの考えられるデッドロック状況 を参照し、同時実行トランザクションの例については 同時書き込みの例 を参照してください。 まとめ このブログ記事では、Amazon Redshift が単一のテーブルへの同時データ取り込みパフォーマンスの向上という重要な課題にどのように対処したかを説明しました。この機能強化により、最新データへのアクセス時の低レイテンシーとより厳格な SLA の要件を満たすことができます。このアップデートは、お客様のフィードバックに基づいて Amazon Redshift に重要な機能を実装するという私たちのコミットメントを示すものです。 著者について Raghu Kuppala は、データベース、データウェアハウス、分析の分野で経験豊富なアナリティクス スペシャリスト ソリューションアーキテクトです。仕事以外では、様々な料理を試したり、家族や友人と時間を過ごすことを楽しんでいます。 Sumant Nemmani は AWS のシニアテクニカルプロダクトマネージャーです。Amazon Redshift のお客様が、機械学習とインテリジェントなメカニズムを活用した機能を利用できるよう支援することに注力しています。これらの機能により、サービス自身によるチューニングと最適化が可能となり、お客様の利用規模が拡大しても Redshift の価格性能比を維持することができます。 Gagan Goel は AWS のソフトウェア開発マネージャーです。顧客中心のソリューションを提供するためにチームの優先順位付けとガイダンスを行い、顧客のワークロードに対するクエリパフォーマンスの監視と向上を通じて、Amazon Redshift の機能が顧客のニーズを満たすことを確実にしています。 Kshitij Batra は Amazon のソフトウェア開発エンジニアで、レジリエントでスケーラブル、高性能なソフトウェアソリューションの構築を専門としています。 Sanuj Basu は AWS のプリンシパルエンジニアで、Amazon Redshift を次世代のエクサバイトスケールのクラウドデータウェアハウスへと進化させる取り組みを主導しています。Redshift のコアデータプラットフォーム (マネージドストレージ、トランザクション、データ共有を含む) のエンジニアリングをリードし、お客様がシームレスなマルチクラスター分析とモダンなデータメッシュアーキテクチャを実現できるようにしています。Sanuj の取り組みは、Redshift のお客様が限界を突破するのを支援しています。 翻訳はソリューションアーキテクトの小役丸が担当しました。原文は こちら です。

この記事は Improving Amazon ECS deployment consistency with SOCI Index Manifest v2 (記事公開日 : 2025 年 7 月 3 日) の翻訳です。 Seekable OCI (SOCI) は、コンテナイメージ全体をダウンロードする前にコンテナを起動すること (遅延読み込み) で、 Amazon Elastic Container Service (Amazon ECS) タスクの起動時間を短縮します。Amazon ECS では、 ソフトウェアバージョンの一貫性 によって特定の ECS デプロイメント 全体で同一のコンテナイメージが使用されることを保証し、信頼性の高いデプロイメントを実現します。しかし、SOCI を用いて ECS タスクを実行する場合、SOCI インデックスはコンテナイメージとは独立しているため、デプロイメントの途中で SOCI インデックスを変更または削除した場合に「一部のタスクは遅延読み込みされるものの、他のタスクはイメージ全体のダウンロードを必要とする」など、起動時間が予測できなくなる可能性がありました。この問題を解決するために、私たちは新しく SOCI Index Manifest v2 を導入しました。これにより、コンテナイメージと SOCI インデックスの間に明示的な関連付けを構築し、SOCI を用いた場合でも一貫したデプロイメントを実現できるようになります。 背景 SOCI を用いてコンテナイメージを遅延読み込みする場合、コンテナランタイムは SOCI インデックスを使用して「各ファイルがコンテナイメージ内のどこに格納されているか」を特定します。 SOCI の内部動作に関するブログ記事 で説明されているように、SOCI インデックスはコンテナイメージとは独立したアーティファクトであり、イメージレイヤーごとのファイルのインベントリを含みます。以下の図は、SOCI インデックス内の Subject メタデータフィールドを介して、SOCI インデックスとコンテナイメージが関連付けられていることを表しています。この実装を SOCI Index Manifest v1 と呼び、コンテナイメージを変更せずに SOCI インデックスを作成することを可能としていました。 図 1 : コンテナイメージマニフェストと SOCI Index Manifest v1 の関係性 SOCI Index Manifest v1 では、コンテナイメージと SOCI インデックスの関連付けが一方向な設計によるいくつかの制約がありました。まず、 crane や Skopeo などのイメージレプリケーションツールが、リポジトリ間でコンテナイメージを複製する際に SOCI インデックスを見落とすことがよくありました。そのため、SOCI インデックスを個別にプッシュする必要がありました。また、デプロイメントの途中で SOCI インデックスを変更または削除した場合に「一部のタスクは遅延読み込みされるものの、他のタスクはイメージ全体のダウンロードを必要とする」など、デプロイメントの一貫性が損なわれる可能性がありました。 SOCI Index Manifest v2 SOCI Index Manifest v2 では、 イメージインデックス を用いて SOCI インデックスとコンテナイメージを関連付けます。イメージインデックスは、マルチアーキテクチャイメージにおける複数プラットフォーム (amd64 や arm64 など) のコンテナイメージを関連付けたり、メタデータを付与するために使用されます。 以下の図は、SOCI Index Manifest v2 において、SOCI インデックスとコンテナイメージが、イメージインデックスのアノテーションを介して相互に関連付けられていることを表しています。 図 2 : コンテナイメージマニフェストと SOCI Index Manifest v2 の関係性 コンテナイメージと SOCI インデックスの新たな関連付けにより、一貫性のあるコンテナの実行が可能となります。イメージインデックスを削除または更新しない限り、SOCI インデックスを削除・更新することはできません。また、様々なアーキテクチャにおけるコンテナイメージと SOCI インデックスはすべて、イメージインデックス内で関連付けられるため、SOCI インデックスの大規模な管理が可能となります。これにより、削除やレプリケーションといったライフサイクル管理も合理化されます。 ウォークスルー SOCI Index Manifest v2 は、 soci convert コマンドを使用して作成できます。このウォークスルーでは、Linux 環境でコンテナイメージを操作します。ここでは、まず Finch を使用してコンテナイメージをビルドし、SOCI CLI を使用して SOCI インデックスを作成します。その後、2 つのアーティファクトを Amazon Elastic Container Registry (Amazon ECR) にプッシュします。 1. まず、コンテナイメージをビルドするための Dockerfile を作成します。ここでは、Amazon Linux 2023 のベースイメージを使用して、nginx をインストール・実行するように設定します。 cat &lt;&lt;EOF &gt; Dockerfile FROM public.ecr.aws/amazonlinux/amazonlinux:2023-minimal RUN dnf install -y nginx CMD ["nginx", "-g", "daemon off; error_log /dev/stdout info;"] EOF 2. 続いて、コンテナイメージをビルドします。以下の例では Finch を使用していますが、 containerd イメージストア にアーティファクトを保存する任意のコンテナイメージビルダーを使用できます。 export ACCOUNT_ID=$(aws sts get-caller-identity --query "Account" --output text) export AWS_REGION=us-east-1 sudo finch build \ --tag $ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/nginx-demo:latest . 3. soci convert コマンドを使用して、SOCI インデックスを作成します。SOCI CLI は SOCI Snapshotter リポジトリ からダウンロードできます ( convert サブコマンドは v0.10.0 以降で利用可能です)。このとき、お使いのコンテナイメージビルダーに合わせて、適切な名前空間を指定する必要がある点に注意してください。例えば Docker を利用する場合は、 containerd イメージストアを利用するように設定 した上で --namespace moby を指定してください。 sudo soci --namespace finch convert \ $ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/nginx-demo:latest \ $ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/nginx-demo:soci-latest 4. AWS CLI を使用して、Amazon ECR リポジトリを作成します。 aws ecr create-repository \ --repository-name nginx-demo \ --region $AWS_REGION 5. Finch を使用して、コンテナイメージと SOCI インデックスを Amazon ECR リポジトリにプッシュします。 sudo finch image push \ $ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com/nginx-demo:soci-latest 認証エラーが出る場合は、Amazon ECR にログインしていることを確認してください。 aws ecr get-login-password --region $AWS_REGION | \ sudo finch login \ --username AWS \ --password-stdin $ACCOUNT_ID.dkr.ecr.$AWS_REGION.amazonaws.com 6. Amazon ECR リポジトリのアーティファクトを一覧表示するには、Amazon ECR コンソールまたは AWS CLI を使用できます。 aws ecr describe-images \ --repository-name nginx-demo \ --region $AWS_REGION 上記コマンドの出力から、リポジトリ内に 3 つのアーティファクト (コンテナイメージ、SOCI インデックス、イメージインデックス) が存在することを確認できます。 { "imageDetails": [ { "registryId": "1234567890", "repositoryName": "nginx-demo", "imageDigest": "sha256:2a2d5af449c44f1658005ed6c2f0f9ee1e99d4013eab9ca572713ed7822cf5c3", "imageSizeInBytes": 129069250, "imagePushedAt": "2025-05-30T18:01:06.613000+00:00", "imageManifestMediaType": "application/vnd.oci.image.manifest.v1+json", "artifactMediaType": "application/vnd.oci.image.config.v1+json" }, { "registryId": "1234567890", "repositoryName": "nginx-demo", "imageDigest": "sha256:e9b498d30d84cbb10985a08554a6fff7e6b2bf3edeeaa8bc3a29c35fb6e0fb20", "imageSizeInBytes": 3590218, "imagePushedAt": "2025-05-30T18:01:06.624000+00:00", "imageManifestMediaType": "application/vnd.oci.image.manifest.v1+json", "artifactMediaType": "application/vnd.amazon.soci.index.v2+json" }, { "registryId": "1234567890", "repositoryName": "nginx-demo", "imageDigest": "sha256:98dbde520076de139d3f8e9589364daf2ed246edc686f1fd6e47dd3fbadc45a6", "imageTags": ["soci-latest"], "imageSizeInBytes": 129069250, "imagePushedAt": "2025-05-30T18:01:06.887000+00:00", "imageManifestMediaType": "application/vnd.oci.image.index.v1+json" } ] } 7. イメージインデックスを取得して、コンテナイメージと SOCI インデックスの新しい関係性を確認しましょう。 aws ecr batch-get-image \ --region $AWS_REGION \ --repository-name=nginx-demo \ --image-ids imageTag=soci-latest \ --query 'images[0].imageManifest' \ --output text | jq -r '.' イメージインデックスは SOCI Index Manifest v2 に従い、コンテナイメージと SOCI インデックスがアノテーションを介してお互いを参照していることを確認できます。 { "schemaVersion": 2, "mediaType": "application/vnd.oci.image.index.v1+json", "manifests": [ { "mediaType": "application/vnd.oci.image.manifest.v1+json", "digest": "sha256:2a2d5af449c44f1658005ed6c2f0f9ee1e99d4013eab9ca572713ed7822cf5c3", "size": 699, "annotations": { "com.amazon.soci.index-digest": "sha256:e9b498d30d84cbb10985a08554a6fff7e6b2bf3edeeaa8bc3a29c35fb6e0fb20" }, "platform": { "architecture": "amd64", "os": "linux" } }, { "mediaType": "application/vnd.oci.image.manifest.v1+json", "digest": "sha256:e9b498d30d84cbb10985a08554a6fff7e6b2bf3edeeaa8bc3a29c35fb6e0fb20", "size": 1038, "annotations": { "com.amazon.soci.image-manifest-digest": "sha256:2a2d5af449c44f1658005ed6c2f0f9ee1e99d4013eab9ca572713ed7822cf5c3" }, "platform": { "architecture": "amd64", "os": "linux" }, "artifactType": "application/vnd.amazon.soci.index.v2+json" } ] } これで、 ECS タスク定義 でこのコンテナイメージのタグまたはダイジェストを参照し、 AWS Fargate 上でコンテナイメージを遅延読み込みできるようになりました。SOCI を使用してコンテナイメージを遅延読み込みするために、ECS タスク定義や ECS サービス定義 にフラグやパラメーターを追加する必要はありません。 後片付け 余分なコストの発生を防ぐために、Amazon ECR リポジトリを削除しましょう。 aws ecr delete-repository \ --repository-name nginx-demo \ --region $AWS_REGION \ --force 考慮事項 SOCI Index Manifest v2 のリリースに関して、いくつかの考慮事項があります。 SOCI Index Manifest v2 は、 SOCI Snapshotter v0.10 以降、および AWS Fargate プラットフォームバージョン 1.4.0 でサポートされています。 AWS Fargate で初めて SOCI を使用するお客様は、SOCI Index Manifest v2 のみを使用できます。この場合、AWS Fargate は SOCI Index Manifest v1 に関連付けられたコンテナイメージを遅延読み込みせず、コンテナイメージ全体をダウンロードしてからコンテナを起動します。 過去に AWS Fargate で SOCI を使用したことがあるお客様は、引き続き SOCI Index Manifest v1 を使用できます。ただし、v2 への移行を強く推奨します。この場合、AWS Fargate は SOCI Index Manifest v1 または v2 のいずれかに関連付けられたコンテナイメージを遅延読み込みします。 SOCI Index Manifest v1 から v2 に移行するには、ウォークスルーで説明した手順に従って SOCI インデックスマニフェストを作成、プッシュし直す必要があります。 AWS Fargate が使用する snapshotter (soci または overlayfs) は、 ECS タスクメタデータエンドポイント で公開されます。この値は amilazy init コンテナ を使用してログに出力し、一元的に管理できます。 SOCI Index Manifest v2 を作成すると、SOCI インデックスに関連する アノテーション が追加され、コンテナイメージマニフェストが変更されるため、コンテナイメージダイジェストも再生成されます。このとき、コンテナイメージのイメージレイヤーの内容は変更されません。 コンテナイメージがすでにコンテナイメージリポジトリに保存されている場合、SOCI インデックスを作成後、コンテナイメージをプッシュし直す必要があります。このとき、すでにレポジトリに存在するイメージレイヤーのアップロードはスキップされるため、イメージレイヤー重複によるストレージコストの増加は発生せず、新しいマニフェストファイルのみがアップロードされます。 SOCI インデックス作成の自動化ソリューションである SOCI Index Builder を使用している場合、最新バージョンにアップデートすることで SOCI Index Manifest v2 を利用できます。 最新情報については、 Amazon ECS ドキュメント または SOCI Snapshotter リポジトリ をご確認ください。 まとめ Seekable OCI (SOCI) は、コンテナイメージを遅延読み込みすることで AWS Fargate のタスク起動時間を短縮します。今回導入された SOCI Index Manifest v2 によって、SOCI を使用する際の ECS デプロイメントの一貫性について、より高い信頼性を提供するようになりました。コンテナイメージと SOCI インデックスの明示的な関連付けにより、SOCI インデックスの大規模な管理も容易になります。AWS Fargate 上の ECS タスクにおいて SOCI を利用開始するには、 Amazon ECS 開発者ガイド および SOCI Toolbox をご確認ください。また、SOCI プロジェクトと SOCI Index Manifest v2 の詳細については、 SOCI Snapshotter プロジェクト をご覧ください。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 今年も半分が終わりましたね (焦り)。残りの半年で生成 AI がどんな進化を遂げるのか楽しみです。 2025 年 7 月 31 日 (木) に AWS Builders Online Series というオンラインイベントが開催されます。生成 AI もテーマに含まれていますので、ぜひ登録してみてください。 先日 2つの新しいプランを追加した「 AWS ジャパン生成 AI 実用化推進プログラム 」も非常に多くの申し込みをいただいています。引き続き募集中ですのでよろしくお願いします。 それでは、6 月 30 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ「ユーザックシステム株式会社様のAWS 生成 AI 活用事例「非定型の受注業務の自動化に生成AI活用」」を公開 ユーザックシステム株式会社様は、企業の業務プロセスの自動化・効率化を支援するビジネスに取り組まれています。一方で、取引先ごとに独自ルールが存在するケースやFAXやメールで注文書のやり取りを行うケースでは、効率化が難しく、新たな方法による生産性向上が求められていました。そこで生成 AI と RPA を組み合わせて非定型の受注業務の完全自動化を目指すソリューション「Knowfa 受注AIエージェント」を Amazon Bedrockを使って開発しました。これまで RPA で対応できなかった受注業務の 80% の自動化に成功したとのことです。AWSのマネージドサービスの活用により、エンジニア 3 名とプロジェクトマネージャー 1 名という少人数体制で、約 4 ヶ月という短期間で β 版開発を実現できました。今後は、対応可能な業務範囲の拡大を目指しています。 【GENIAC】グローバル生成AIモデルプロバイダ訪米記録 2025 年 5 月 12 日 〜 16 日に、経済産業省が推進するプログラム『 Generative AI Accelerator Challenge(GENIAC) 』の採択者と共に、米国ベイエリアおよびシアトルの米大手モデルプロバイダーを訪問し、技術交流セッションを実施しました。本ブログでは、AWS、Anthropic、Meta、Cohere、NVIDIAや現地で挑戦する日本人起業家たちとディスカションした様子をレポートしています。 Amazon Nova 理解モデルにおけるパフォーマンスの最適化 本ブログでは、Amazon Nova 理解モデルのパフォーマンスを最適化する方法について説明しています。最適化のポイントは、明確な指示で構造化されたプロンプトを反復的に改善すること、Tool use において Greedy Decoding を使用する設定を行うことです。記事内にプロンプト例があるので是非参考にしてみてください。 Amazon Q Developer から Claude Sonnet 4 がアクセス可能に 先日、 Amazon Q Developer が CLI で Claude Sonnet 4 のサポートを開始し、追加コストなしで高度なコーディングと推論機能を開発プロセスに導入できるようになりました。本ブログでは、Q Developer CLI で Claude Sonnet 4 をモデルとして選択する方法と簡単なデモを紹介しています。複雑なコードリファクタリングから効率的なドキュメント作成まで便利に使えますので、まだ使ってない方は是非お試しを！ 【開催報告】 消費財業界向け Amazon Q in QuickSight ワークショップ ～生成 AI で加速するインテリジェントデータ分析～ 2025 年 6 月 9 日、AWS 目黒オフィスにて消費財業界向け Amazon Q in QuickSight ワークショップを開催しました。本ブログはそのイベントの開催報告記事です。BI に興味ある方はデータ分析ダッシュボード設計の進め方などぜひ参考にしてみてください。 Amazon Q のコスト最適化 本ブログではAmazon Q Business と Amazon Q Developerそれぞれの料金プランと機能の違いについて説明しています。いづれのサービスの最大の利点の 1 つは、予測可能なコスト構造です。コアビジネスの目標に焦点を当てながら、経費を正確に予測できますので、ご興味ある方はぜひブログを参照ください。 Amazon Nova Canvas update: Virtual try-on とスタイルオプションが一般公開 画像生成を行うモデル Amazon Nova Canvas に、 Virtual try-on 機能機能とスタイルオプションが追加 されました。このブログでは、それぞれの機能の解説・デモ・サンプルコードを紹介しています。Virtual try-on 機能は顧客体験の向上に繋がる可能性がある機能ですので、サンプルコードを参考にお試しください！ サービスアップデート Amazon Q in Connect がプロアクティブな推奨事項機能に対して 7 言語をサポート Amazon Q in Connect の、音声・チャット対応で顧客意図を検出し「プロアクティブな推奨事項を提供する機能」が、英語に加えて、スペイン語、フランス語、ポルトガル語、中国語、日本語、韓国語でも利用可能になりました。多言語対応により、グローバル企業のカスタマーサービス担当者が各国の顧客とより効率的にやり取りできるようになり、問題解決の精度とスピードが向上します。詳細は こちらのドキュメント をご参照ください。 Q-Index がシームレスなアプリケーションレベル認証をサポート Amazon Q-Index の SearchRelevantContent API で、シームレスなアプリレベル認証がサポートされました。従来、サードパーティアプリで Q-Index を使う際、ユーザーは自分のアプリにログイン後、企業コンテンツを取得するために AWS IAM への再認証が必要でした。今回のアップデートにより、Trusted Token Issuer 機能を使って一度のログインだけで企業コンテンツから回答を取得できるようになり、ユーザー体験が大幅に向上します。バージニア北部、オレゴン、アイルランド、シドニーリージョンで利用可能です。詳細は こちらのドキュメント をご参照ください。 Amazon Q Business がレスポンスのカスタマイズ機能を開始 Amazon Q Business で新機能「レスポンスカスタマイゼーション」が提供開始されました。従来は AI の回答スタイルが固定でしたが、今回のアップデートで企業の要望に合わせて回答の口調、長さ、詳細度を自由に設定できるようになりました。例えば、カジュアルな表現で短い回答にしたり、フォーマルで詳細な回答にしたりと、組織のコミュニケーションスタイルに統一できます。詳細は こちらのドキュメント をご参照ください。 Amazon Bedrock で Claude モデル向けの Citations API と PDF サポートが利用可能に Amazon Bedrock の Claude モデルで Citations API と PDF サポートが追加されました。Citations API により AI 回答に根拠文書の引用が自動付与され、信頼性向上が実現します。PDF サポートでテキスト抽出やチャート分析も可能になり、法的研究や学術執筆での活用が期待されます。詳細は こちらの API ドキュメント をご参照ください。 &nbsp; Amazon Nova Canvas にVirtual try-on 機能とスタイルオプションを追加し、画像生成機能を強化 Amazon Nova Canvas に「Virtual try-on 機能」と「スタイルオプション機能」が追加されました。Virtual try-on 機能では人物画像と商品画像をアップロードするだけで、服を着た姿や家具配置をリアルに生成できます。スタイルオプションでは 8 つのスタイルから選択可能で、プロンプト指定が不要になります。バージニア北部、東京、アイルランドリージョンで利用可能です。詳細は こちらのブログ記事 をご参照ください。 Amazon SageMaker HyperPod トレーニングオペレーターの発表 Amazon SageMaker HyperPod の新しいトレーニングオペレーターが一般提供開始されました。これは Kubernetes 上で大規模な AI モデルトレーニングの耐障害性を向上させる拡張機能です。従来は 1 つのプロセスが失敗すると全ノードで完全再起動が必要でしたが、今回のアップデートにより影響を受けた部分のみを選択的に再起動する「surgical recovery」が可能になりました。詳細は こちらのドキュメント をご参照ください。 AWS Neuron 2.24 の新機能には PyTorch 2.7 と推論機能の強化が含まれます AWS Neuron 2.24 がリリースされ、AI モデルの推論処理が大幅に高速化されます。PyTorch 2.7 に対応し、大規模言語モデルの実行時間短縮を実現する prefix caching や、長い文章処理に適した context parallelism などの新機能を搭載しています。これにより Inferentia や Trainium インスタンスでの AI ワークロードがより効率的になり、コスト削減と性能向上を同時に達成できます。詳細は こちらのドキュメント をご参照ください。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は生成 AI と毎日戯れており、特にコード生成と LLM エージェントに注目しています。好きなうどんは’かけ’です。

本ブログは 2025 年 7 月 5 日現在の内容を元に記載しております。記載内容については今後変更される可能性があります。 こんにちは ! テクニカルインストラクターの室橋です。本ブログでは、現在注目を集めている生成 AI について無料で利用できる学習コンテンツ「AWS SimuLearn」についてご紹介いたします。 AWS SimuLearn とは？ AWS SimuLearn は、生成 AI を搭載した仮想顧客とのチャットを通じて実践的な AWS スキルを身につけられる新しい学習プラットフォームです。顧客の課題をヒアリングし、最適なソリューションを提案するプロセスを体験した後、実際の AWS アカウントを使用したハンズオンラボで技術スキルを向上させることができます。 AWS SimuLearn で無料プレイできるラボ一覧 このたび、AWS SimuLearn において生成 AI に関するラボと、クラウドの基礎 (Cloud Practitioner) に関するラボが無料かつ日本語対応で提供開始されました。これにより、コース内から起動可能な AWS アカウントを使用した演習環境をどなたでも利用できます。AWS を活用して生成 AI アプリケーションの開発を学びたい方や、AWS Certified AI Practitioner (AIF) 認定の取得を目指している方にとって、最適な学習機会となるでしょう。 以下に、現在無料で利用可能な SimuLearn の生成 AI 関連コースの一覧をご紹介します。なお、下記の 10 コースは「 AWS SimuLearn: Generative AI Practitioner (日本語) 」という学習プラン (コースをセットにして学習しやすくしたもの) に登録することにより、一覧性のあるページより学習の開始が可能です。 AWS SimuLearn: Generative AI Practitioner コース一覧 課題名 シナリオ 目標 クラウド、はじめの一歩 島の安定化システムは故障しており、システムのコンピューティングモジュールの信頼性と可用性を高める必要があります。 AWS グローバルインフラストラクチャの利点を特定する AWS リージョンとアベイラビリティーゾーンについて説明する Amazon EC2 インスタンスを複数のアベイラビリティーゾーンにデプロイする方法を説明する クラウドコンピューティングの基本 シティのウェブポータルチームは、自社の海岸波サイズ予測ウェブページの信頼性を高めるソリューションを求めています。 AWS クラウドコンピューティング環境の特徴を確認する AWS の製品とサービスを使用する主な利点を確認する AWS クラウドのサービスとオンプレミスのインフラストラクチャを比較し、対比する Amazon S3 を使用して静的ウェブページをホストする方法を説明する 生成 AI を使い始める AnyCompany Software は、生成AIのためのプロンプトエンジニアリング技術をスタッフに学ばせたいと考えています。ソフトウェア開発の速度と品質を向上させることで、同社は競争の激しい技術市場で優位性を保ち、クライアントに優れた製品を提供することを目指しています。 Amazon SageMaker JumpStart を使用して LLM モデルをデプロイする方法を説明する Jupyter ノートブックで Amazon SageMaker Python SDK を使用してモデルをデプロイする方法を示す プロンプトエンジニアリング技術を使用してモデルの応答を改善する方法を説明する AI スマートアシスタントを作成する 人事部門は、毎日 500 件を超える従業員からの情報要求に対応するのに苦労しています。要求の大部分は、ポリシー、福利厚生、手続きに関するものです。また、現在、要求は営業時間内にのみ処理でき、同時に返信できる数も限られています。これには即座対応が必要です。 Amazon Bedrock を使用して自動化された顧客サービスソリューションを作成する方法を決定する Amazon Bedrock エージェントをナレッジベースで設定する方法を決定する Amazon Bedrock エージェントにアクショングループを追加する方法を示す Amazon Q でコードを構築し理解する 子供向け教育出版社は、キャラクター名、テーマ、設定などのユーザー入力に基づいてパーソナライズされた短編ストーリーを生成する自動ストーリー生成システムを作成したいと考えています。 Amazon Bedrock FM を使用してテキストコンテンツを生成する方法を有効化し、使用する方法を示す AWS Lambda 関数を他の AWS サービスと統合して設定およびテストする方法を決定する Amazon Q を使用してコード提案を生成し実装する方法を決定する AWS サービスを使用するサーバーレス AI 駆動のストーリー生成ワークフローの主要コンポーネントを特定する Amazon Bedrock プレイグラウンドを探索する AnyCompany のビジネスチームは、顧客サービスのチャットベースの AI エクスペリエンスに最適な AI モデルを見つける任務を負っていますが、明確な評価方法が欠けています。彼らは、顧客との会話中にテキストと画像の両方をサポートする異なるモデルを徹底的に比較したいと考えています。 Amazon Bedrock プレイグラウンドを使用して AI モデルの評価方法を決定する 安全で管理された環境で異なる基盤モデルをテストし比較する方法を決定する モデルパラメータの調整と最適化の実践経験を積む さまざまな AI モデルからの出力を評価し比較する方法を示す ガードレールによる安全な対話型 AI AnyCompany の人事部門は、従業員の質問に答えるのに役立つチャットベースの AI アシスタントを選択したいと考えています。会社は、機密の人事問題を避け、従業員データのプライバシーを保護し、一貫した福利厚生とポリシーの回答を提供するなど、AI アシスタントが専門的でポリシーに準拠した回答のみを提供することを懸念しています。 Amazon Bedrock Guardrails 機能を説明する ガイドレールの設定とカスタマイズ方法を示す ガードレールをテストして、セーフガードポリシーを検証する方法を示す エンタープライズナレッジアシスタントを作成する 営業部門は過去および現在の販売データへの迅速なアクセスが不足しており、類似の販売問い合わせに対して様々な解釈や回答が生じています。これにより、営業担当者が上級管理職に注力すべき販売製品や人気が高まっている製品を報告するまでの解決時間が長くなっています。 Amazon Bedrock の主な機能と特徴を説明する Amazon Bedrock ナレッジベースの作成と設定方法を決定する テキスト対テキストモデルとテキスト対ベクトルモデルを比較する 検索拡張生成 (RAG) の概念を説明する Amazon SageMaker で AI サービスを利用する グローバルコンサルティング企業は、現在手動プロセスで年間 150 万ドルのコストがかかり、15 パーセントのエラー率を示し、20 人以上のフルタイム従業員が1ドキュメントあたり最大 48 時間かかる 10,000 件以上の多言語クライアントコミュニケーションとドキュメントを毎日処理しています。同社は、運用コストを削減し、精度を向上させ、処理時間を短縮しつつ、グローバルなクライアントサービス提供を強化する包括的な自動化ソリューションを望んでいます。 Amazon SageMaker AI ノートブックインスタンスをドキュメント処理ワークフロー用にセットアップおよび使用する方法を説明する Boto3 SDK を使用して複数の AWS AI サービスを統合する方法を決定する AWS AI サービスを使用して、テキスト抽出、感情分析、言語翻訳、音声サービスの使用方法を示す AWS サービスの統合とデータ処理のためのノートブックセルを順次実行する方法を示す ウェブページのコードを生成する マーケティング部門は、特に外部クライアントとコンテンツを共有するための Amazon EC2 上のウェブサーバーの管理において、ウェブホスティングのニーズに課題を抱えています。チームは、現在過剰な時間とリソースを消費しているウェブコンテンツとコードの更新を効率化するソリューションを求めています。彼らは、生成 AI の機能を活用し、AWS の専門知識が最小限の従業員でもウェブコンテンツの更新を効果的に管理できる、ユーザーフレンドリーなアプローチを実装したいと考えています。 Amazon Bedrock のチャット/テキストプレイグラウンドの使用方法を説明する チャットモードとシングルプロンプトモードの違いを特定する Amazon Bedrock を使用してアプリケーションを構築する方法を決定する Amazon EC2 で実行中のアプリケーションを更新する方法を示す また、SimuLearn では生成 AI 以外にも、無料でクラウドの基礎をハンズオンで学習することができるコースも合計 12 コース提供しております。是非 AWS Skill Builder にアクセスしてコースを検索してみてください。なお、コース検索の際は Skill Builder トップページ上部の検索窓に何もいれずに Enter キーを押すと「フィルタ」の画面に遷移しますので、そこから「学習スタイル」を「没入型ソリューション構築」、「料金」を「無料」にして検索していただくと、無料の SimuLeran コースが検索しやすくなります。 AWS Skill Builder のトップ画面にある「トレーニングカタログを検索」と書かれた検索窓にカーソルを合わせ、何も入れずに検索 フィルタの画面に遷移します。「没入型ソリューション構築」「無料」のフィルタを設定いただくと SimuLearn の無料コースが表示されます。 SimuLearn 学習の流れ 1 : モード選択 ここからは SimuLearn を使用した際の学習の流れについて簡単にご紹介します。 学習開始時には、まずモードの選択を行います。モードは「スクリプトモード」と「自由会話モード」の 2 つから選択できます。「スクリプトモード」では AI との対話はなく、学習者はあらかじめ用意された会話のシナリオに沿って学習目標を確認し、課題に進みます。「自由会話モード」では、対話形式の画面を通じて、生成 AI 搭載の仮想顧客とビジネス課題の解決に向け、学習者自ら内容を考えて会話を行います。学習者は最適なソリューションを構築するため、適切な AWS サービスを提案します。このモードでは、生成 AI が学習者の回答に基づいて、コミュニケーション能力、問題解決力、お客様志向、意思決定能力、技術的な知識戦略的思考を評価します。「自由会話モード」は現在英語のみ対応となっています。どちらを選択しても、会話後のハンズオンパートには影響を及ぼすことはありません。 画像はモード選択画面です。どちらのモードを選択しても後のフェーズの構築で行う内容は変わりません。 現在「スクリプトモード」は日本語で確認いただくことが可能です。こちらは予め用意された会話のやり取りを確認することによって、顧客のニーズと、それに対する回答を読み取り、次のフェーズに進んでいく流れとなります。 スクリプトモードでは「あらかじめ決められた会話内容」より、顧客からのニーズを確認します。 顧客役の生成 AI と適切に会話を行うことにより、学習者のスキルが評価されます。現在は英語のみの対応となります。英語に自信がある方は是非自由会話モードで学習をしてみてください。英語を使うお客様とのやり取りを想定して、翻訳ツールを使用しながらチャレンジしていただくのも面白いかもしれません。 自由会話モード画面です。顧客との会話により満足度を高め、アーキテクチャ図を完成させましょう。 なお、SimuLearn が日本語が表示されない場合は「画面右上にある三本線メニュー」より、言語 (Language) で「Japanese」を選択してください。 画面右上の言語切り替えメニューより言語の変更が可能です。 SimuLearn 学習の流れ 2 : 学習 ～ 実践 ～ DIY のハンズオンパート お客様との会話が終了した後、次のフェーズに進みます。課題は「学習」「実践」「DIY」の 3 つのパートに分かれています。 課題は上記の 3 フェーズで進行します。 まず、学習パートで「この課題の中ではどのようなソリューションが求められているか ?」「どのように構築するのか ?」を理解します。このパートでは概要を説明する動画を確認することも可能です。動画の音声は英語のみサポートされており、日本語は字幕で表示することが可能です。 学習パート内で求められるソリューションやサービスについての学習を行います。 次の実践パートでは、学習セクションで得た知識を実際の AWS 環境で実践できます。ステップバイステップの詳細な解説とスクリーンショットが用意されており、SimuLearn 専用の AWS アカウントを使用することにより、料金発生や環境の削除忘れ、設定ミスなどの心配をすることなく、安心して学習に集中できます。この理論と実践を組み合わせた学習アプローチにより、AWS サービスへの理解を深めながら、実務で活かせる実践的なスキルを効率よく身につけることができます。 実践パートで「実際の AWS アカウント」を使用しながら、ハンズオンでの学習を行います。 「学習パート」及び「実践パート」で学習した事が身についているかを確認するため、DIY パートでは「詳細な手順やスクリーンショットなしで、要件にそった環境が構築できるかどうかの検証」を行います。DIY の目標で示されたソリューションを構築後「検証」ボタンを押し、検証が成功すれば無事に課題は終了となります。 要件に沿った環境を構築した後、検証フォーム内に求められた内容を入力し、検証を行います。 見事検証が成功すると、クリア画面が表示されます！ AWS SimuLearn で生成 AI、クラウドの学習を加速させましょう！ 以上のように、AWS SimuLearn では「生成 AI の基礎」や「クラウドの基礎」を無料で学習可能です。最大の魅力は「実際の AWS アカウントを使用したハンズオン形式の学習が、料金の心配なく行える点」にあります。「AWS アカウントの作成は不安」「予期せぬ料金が発生するのでは」と迷っていた方にとって、SimuLearn は理想的な入門環境となるのではないでしょうか。また、SimuLearn には今回ご紹介した無料コンテンツ以外にも数多くの課題が用意されています。「生成 AI の基礎」が学習可能な 8 コースや「クラウドの基礎」が学習できる 12 コース」で基本を学んだ後、さらに知識を深めたい方は AWS Skill Builder のサブスクリプションへの登録をご検討ください。サブスクリプションに登録することで、より専門的で幅広い課題にチャレンジできるようになり、クラウドスキルを次のレベルへと引き上げることができます。サブスクリプションに関する詳細は こちらのページ をご確認ください。 また、AWS Skill Builder では、SimuLearn 以外にも様々な学習リソースが提供されています。ゲーム感覚で AWS が学べる「AWS Cloud Quest」、実践的なラボ環境に特化した「Builders Lab」、そして多数の無料学習コースなど、学習スタイルや目的に合わせて選べるコンテンツが豊富に揃っています。現在、クラウド技術の習得は多くの業界で求められるスキルとなってきています。AWS Skill Builder を活用して、自分のペースでスキルアップを図り、キャリアの可能性を広げましょう。

みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 2025年7月31日(木) に AWS Builders Online Series が開催されます。AWS Builders Online Series は、基礎から実践までの実用的な AWS クラウドスキルを身につけることを目的とした初心者向けオンラインイベントです。今回は、「アプリケーション開発」、「既存システムの移行」、 「生成 AI」、 「AWS の実用に向けた基礎知識」の 4 つのテーマにフォーカスし、デモを見ながら業務上のよくある課題の解決法やすぐに実践できる知識を学ぶことが出来ます。ぜひ、ご登録ください！ それでは、先週の主なアップデートについて振り返っていきましょう。 2025年6月30日週の主要なアップデート 6/30(月) Amazon Redshift Serverless now supports 4 RPU Minimum Capacity Option Amazon Redshift Serverless の最小容量設定を4 RPU (Redshift Processing Units) に設定できるようになりました。Amazon Redshift Serverless はデータウェアハウス容量を RPU で測定し、RPU として稼働するワークロードの時間に対して利用料が発生します。以前は Amazon Redshift Serverless を実行するために必要な最小基本容量は 8 RPU でしたが、今回のリリースによって 4 RPU で稼働させることができるようになったことで、 1 時間あたり約 1.98ドルという低価格で利用をはじめることができます。 Amazon Connect now supports instance replication between Asia Pacific (Tokyo) and Asia Pacific (Osaka) Amazon Connect の機能として、Amazon Connect Global Resiliency (ACRR) が一般提供開始となりました。大阪リージョンにレジリエンスインスタンスを設置することで、東京リージョンのインスタンスから、ユーザー、ルーティングプロファイル、フローなどの Amazon Connect 構成をレプリケートし、フェイルオーバーできるようになりました。これにより、データを日本国内に保持しながら、地域的な災害や障害が発生した場合のダウンタイムを最小限に抑えることで、コンタクトセンターの可用性を高めることができます。詳しくは ブログ をご確認ください。 Amazon DynamoDB global tables with multi-Region strong consistency is now generally available Amazon DynamoDB グローバルテーブルはマルチリージョン強整合性をサポートするようになりました。DynamoDB グローバルテーブルは、完全マネージド型のサーバーレスなマルチアクティブデータベースです。今回、マルチリージョンの強整合性を備えたことで、アプリケーションが常に利用可能で、どのリージョンからでも最新のデータを読み取ることができる最高レベルのアプリケーション回復力を提供するとともに、今まで必要であった、強整合性のレプリケーション管理という作業が不要となります。日本において、東京リージョンと大阪リージョンでのマルチリージョン構成で利用可能です。 Citations API and PDF support for Claude models now in Amazon Bedrock Amazon Bedrock は、Anthropic のClaude モデル向けに Citations API (引用)と PDF サポートを提供しました。Citations APIにより、Claude モデルは回答生成に使用された具体的な引用元を提供します。これにより、高い精度と透明性を必要とするアプリケーションにとって、より信頼性の高い出力が可能となります。また、PDFサポートでは PDF ドキュメントからテキストを抽出し、チャート分析や視覚的なコンテンツを理解できるようになったことで、企業が保持する PDF ドキュメントライブラリなどから、より効率的な洞察を得ることが可能です。 7/1(火) Amazon Aurora now supports PostgreSQL 17.5, 16.9, 15.13, 14.18, and 13.21 Amazon Aurora で PostgreSQL 17.5、16.9、15.13、14.18、および 13.21 のバージョン をサポートしました。このアップデートには PostgreSQL コミュニティの改善とバグ修正が含まれているだけでなく、クラスターアップグレード中のダウンタイムを削減するための読み取りレプリカの最適化、 Babelfishの新機能 、セキュリティの改善などの Aurora 固有の機能強化もされています。 Amazon QuickSight launches Trusted Identity Propagation (TIP) for Athena Direct Query Amazon QuickSightは、Amazon Athena に対するダイレクトクエリ向けに、Trusted Identity Propagation（TIP: 信頼できるID伝播）をサポートしました。TIP を使用することで、Author はクエリによって返されるデータの行と列レベルでの制御ができ、同じダッシュボードを顧客や部門間で使用することができます。詳細についてはこちらの ユーザガイド をご確認ください。 Amazon Q in Connect now supports 7 languages for proactive recommendations Amazon Q in Connect で日本語を含む 6 つの言語を新たにサポートするようになりました。Amazon Q in Connect は、カスタマーサービス向けの生成 AI を活用したアシスタントで、コールセンターのオペレーターが問い合わせを迅速かつ正確に解決するための推奨事項を提供します。今まで、言語としては英語のみのサポートとなっていましたが、スペイン語、フランス語、ポルトガル語、中国語、日本語、韓国語での、音声およびチャットのやり取りを検出し、オペレーターへの支援が可能です。 Amazon Aurora MySQL and Amazon RDS for MySQL integration with Amazon SageMaker is now available Amazon Aurora MySQL と Amazon RDS for MySQL が Amazon SageMaker とのゼロETL統合をサポートしました。これにより、MySQL テーブルからデータが自動的に抽出、およびレイクハウスにロードされ、分析ワークロード向けのほぼリアルタイムのデータ可用性が実現できます。また、レイクハウスに同期されたデータは Apache Icebergと互換性があり、SQL、Apache Spark、BI、AI/ML ツールなど、お好みの分析ツールやクエリエンジンを使用できます。 7/2(水) Amazon QuickSight supports 2B row SPICE dataset Amazon QuickSight Enterprise Edition において、最大 20 億行のデータを SPICE (Super-fast Parallel In-memory Calculation Engine) のデータセットに読み込むことができるようになりました。このアップデート前の容量の 10 億行から 2 倍のデータを読み込むことが可能となったことで、取り込み速度やクエリ性能を低下させることなく、より多くのビジネスデータを分析してビジネスインサイトを得ることができます。 Amazon Nova Canvas adds virtual try-on and style options for image generation Amazon Nova Canvas でバーチャル試着とスタイルオプションの機能がリリースされました。バーチャル試着機能により、人物やスペースを示す画像と商品画像の2つをアップロードするだけで、商品を着用した人物の画像や、リビングスペースに配置された商品家具の画像を生成できます。また、スタイルオプションにより、事前に設定した画像スタイル (デザインスケッチ、フォトリアリズムなど) をもとに、一貫した画像を生成することができます。 7/3(木) Amazon Aurora DSQL is now available in additional AWS Regions Amazon Aurora DSQL がソウルリージョンで利用可能になりました。また、今まで北米 (バージニア、オハイオ、オレゴン) のみでサポートされていたAurora DSQL のマルチリージョン構成でしたが、今回のサポートリージョンの拡大に伴い、アジアパシフィック地域として大阪、東京、ソウルでのマルチリージョンクラスターの構成が可能になりました。また、ヨーロッパ地域（アイルランド、ロンドン、パリ）内のマルチリージョンクラスターも同様にサポートされています。 Amazon Aurora PostgreSQL database clusters now support up to 256 TiB of storage volume Amazon Aurora PostgreSQL の最大ストレージ容量が 256 TiB となりました。このアップデート以前の最大容量 128 TiB から倍増し、単一のAuroraデータベースクラスター内でさらに大きなデータセットを保存および管理できるようになりました。今回の拡張されたストレージを利用するためには、クラスターをサポートされているデータベースバージョンにアップグレードする必要があります。サポートされているデータベースのバージョンについては、 こちらのユーザガイド をご確認ください。 7/4(金) この日に発表されたアップデートはありませんでした。 AWS re:Inforce 2025 が先月に開催されました。キーノートをはじめ、セキュリティサービスに関する多数の機能アップデートをキャッチアップできる re:Cap イベントが 7/24(木) に予定されています。ぜひ ご登録 ください！ それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

本記事は 2024年6月11日に公開された ” Simplify global security inspection with AWS Cloud WAN Service Insertion ” を翻訳したものです。 AWS Cloud WAN は、データセンターやブランチオフィス、 Amazon Virtual Private Cloud (Amazon VPC) VPC を接続する広域ネットワーク (WAN) の構築・運用に使用できるマネージド型の WAN サービスです。ネットワークポリシーを使用して、ネットワーク管理とセキュリティタスクを一元的に設定・自動化し、グローバルネットワークの完全な可視性を得ることができます。 サービス開始 以来、グローバルネットワークの作成とリソース間の接続を容易にする機能により、AWS Cloud WAN の認知度は高まっています。しかし、この接続性を重視したことに伴い、AWS ネイティブまたはサードパーティのファイアウォールを使用する際のセキュリティ検査機能の必要性が高まっています。お客様は、ネットワークの検査と保護の方法を求めており、AWS Cloud WAN を使用した安全なグローバルネットワークの設計に関するガイダンスを必要としています。お客様の理解を深めていただくため、AWS Cloud WAN を使用した安全なグローバルネットワークの設計方法について、すでにいくつかの ブログ記事 を公開しています。 従来のセキュリティ検査アプローチにおける課題 既存の検査アーキテクチャパターンには多くの利点がありますが、特に AWS Cloud WAN で大規模に展開する際に、お客様はいくつかの課題に直面してきました。 インスペクションセグメントが共有されているため、Classless Inter-Domain Routing (CIDR) を使用する VPC ルートは、各 VPC アタッチメントをネクストホップとして、インスペクションセグメントのルートテーブルに動的に伝播されます。そのため、それぞれのファイアウォールにトラフィックをルーティングするためには、新しく追加された VPC ごとに、AWS Cloud WAN のインスペクションセグメントルートテーブルに静的ルートを設定する必要がありました。 マルチリージョンネットワークのための AWS Cloud WAN による最適なルーティングの実現 で説明されているような、マルチ AWS リージョンの地域分散型検査アーキテクチャは複雑さを伴います。 1 つのグローバルインスペクションセグメントでは、既存のソリューションで各リージョンのファイアウォールを経由してトラフィックを強制的にルーティングする方法がありませんでした。各 AWS リージョンでトラフィックを検査するという要件を満たし、対称的なルーティングを維持するために、顧客は各リージョンまたはエッジロケーションに固有のグローバル共有インスペクションセグメントを作成する必要がありました。 それぞれの共有インスペクションセグメントは、コアネットワークごとのセグメントの クォータ としてカウントされます。 このブログ記事では、AWS Cloud WAN Service Insertion (Service Insertion) という新機能について説明します。この機能を使用すると、中央ポリシードキュメントを使用して AWS および他社のネットワークおよびセキュリティサービスを AWS Cloud WAN に組み込むことができ、運用の簡素化を実現できます。この機能を使用することで、シンプルなポリシーステートメントを定義するか AWS マネジメントコンソールを使用して、VPC 間、インターネットエグレス、ハイブリッド環境のトラフィックをネットワークまたはセキュリティアプライアンスに容易に振り分けることができます。また、この機能は、East-West (VPC 間) および North-South (インターネットエグレス) のセキュリティ検査のためにインスペクション VPC にデプロイされた AWS Network Firewall や Gateway Load Balancer などの AWS サービスへのポリシーベースのトラフィック誘導もサポートしており、セキュリティインフラストラクチャを AWS Cloud WAN デプロイメントの他の部分とシームレスに統合できます。 Service Insertion のメリット お客様は AWS Cloud WAN を使用して一元化されたセキュリティアーキテクチャをデプロイすることで、セキュリティリソースを統合し、管理の負担を軽減し、セキュリティインフラストラクチャのコストを削減できます。セキュリティ検査機能には、East-West、North-South、またはハイブリッド環境の保護が含まれます。 Network Service Insertion のためのルーティングの簡素化： お客様は、VPC 間、VPC からインターネット、またはオンプレミスへのトラフィックを、ネットワークファイアウォールやロードバランサーなどのネットワークアプライアンスを経由させる必要がよくあります。AWS Cloud WAN Service Insertion により、複雑なルーティング設定を作成・管理したり、サードパーティの自動化ツールを使用したりすることなく、VPC にデプロイされたネットワークやセキュリティアプライアンスに対象のネットワークトラフィックを簡単に転送できます。 マルチリージョンのセキュリティ検査の容易なデプロイ： ほとんどの AWS Cloud WAN のお客様は、リージョン拡張や災害復旧のユースケースに対応するため、マルチリージョンネットワークをデプロイしています。Service Insertion 機能により、マルチリージョンのデプロイが簡素化され、複雑なマルチリージョンネットワーク設定を必要とせずに、リージョン内およびリージョン間のトラフィックをセキュリティインフラストラクチャ経由に振り分けることができます。 主要な概念 このブログ投稿では、 AWS Cloud WAN のコンポーネント であるグローバルネットワーク、コアネットワーク、コアネットワークポリシー、アタッチメント、コアネットワークエッジ、ネットワークセグメントについて理解していることを前提としています。 上記で説明した概念に加えて、このブログ記事で説明するアーキテクチャを理解するためには、AWS Cloud WAN Service Insertion 機能の新しいコンポーネントである Network Function Group (NFG) を理解することが重要です。 Network Function Group (NFG) NFG は、内部的には、NAT、ファイアウォール (AWS Network Firewall や Gateway Load Balancer、またはサードパーティサービス)、侵入検知・防止システム、データ損失防止など、グローバルな AWS Cloud WAN ネットワークの一部として展開される特殊なネットワークやセキュリティ機能を指すコアネットワークアタッチメントの集合で構成される単一のセグメントです。 NFG を使用すると、AWS Cloud WAN に接続された VPC やオンプレミスネットワークにデプロイされたネットワーク機能 (Network Function) を使用して、同一セグメント間または異なるセグメント間のトラフィックを自動的に制御できます。ネットワーク機能が存在するコアネットワークアタッチメント (VPC、Site-to-Site VPN、Connect、Transit Gateway ルートテーブル) のセットを含む NFG を指定できます。さらに、トラフィックをネットワーク機能にリダイレクトする必要があるセグメントまたはセグメントペアを指定できます。AWS Cloud WAN は、それぞれの NFG に対して指定されたコアネットワークアタッチメントを通じて、セグメント間のネットワークトラフィックを自動的にリダイレクトします。このリダイレクトは、コアネットワーク上の同一リージョン (リージョン内) およびクロスリージョン (リージョン間) のトラフィックの両方で機能します。AWS Cloud WAN の コアネットワークポリシードキュメント を使用して、以下のように主要な設定項目を指定できます： 1 つまたは複数のネットワーク機能を表す NFG。 NFG の一部であるコアネットワークアタッチメント。 ネットワーク機能を使用して制御する必要がある、セグメント間またはセグメント内のトラフィックを持つセグメント (シナリオ 2 のアタッチメント)。 Cloud WAN のネットワークセグメントと NFG の主な違いを理解することも重要です。 コアネットワークセグメント コア Network Function Group (NFG) セグメントは独立したルーティングドメインで、セグメント内外のルーティングを完全に制御しながらアタッチメントを関連付けることができます。例えば、セグメント内でルートの追加や削除、セグメント間でのルートの共有が可能です。 NFG は独自のルートテーブルを持ち、これらのルートはポリシードキュメントの Service Insertion 設定に基づいて（ネクストホップの転送先とともに）自動的に伝播されます。これらのルートを確認することはできますが、NFG 内でのルートの追加、削除、共有はできません。 Cloud WAN セグメントにアタッチメントを関連付けると、VPC の CIDR やダイナミックルートが、それぞれのセグメントルートテーブルに伝播されます。 NFG にアタッチメントを関連付けても、VPC の CIDR やダイナミックルートは NFG ルートテーブルに伝播されません。 トラフィックを制御するために、NFG は以下の セグメントアクション を導入します。 ‘ send-via ‘: NFG のアタッチメントを介して、同一セグメントまたは異なるセグメント間のワークロード間のトラフィックを、ネクストホップを上書きして制御します。 ‘single hop’ : 優先されるソースまたはデスティネーションリージョンを使用して、トラフィックは単一の中間アタッチメントを通過します。使用するリージョンのリストを設定でき、優先的に使用するリージョンを設定することもできます。 ‘dual-hop’ : トラフィックは、ソースとデスティネーションの両方のコアネットワークエッジに挿入されたアタッチメントを通過します。このオプションでは、インスペクションアタッチメントは、Service Insertion が有効化された各セグメントのすべてのリージョンに配置される必要があります。 ‘ send-to ‘: NFG のアタッチメントを介して、セグメントに関連付けられたワークロードからのエグレストラフィックを、デフォルトルート (0/0, ::/0) を使用してインターネットまたはハイブリッドに転送するために使用します。 これらの概念の詳細については、 AWS Cloud WAN ドキュメント をご参照ください。 図 1: Service insertion NFG アーキテクチャ ここでは、以下の 3 つのシナリオに焦点を当てます。 リージョン内、セグメント間のインスペクション リージョン間、セグメント間のデュアルインスペクション リージョン間、セグメント間のシングルインスペクション シナリオ 1 – リージョン内、セグメント間のインスペクション 次の図 (図 2) は、シナリオ 1 を示しています。このシナリオでは、同一リージョン内の異なるセグメントにあるアタッチメントが、インスペクションアプライアンスを介してのみ相互に通信する必要がある場合を示しています。たとえば、開発チームが本番環境にエンジニアリング変更をプッシュする必要がある場合です。Prod VPC (10.1.0.0/16) と Dev VPC (10.11.0.0/16) は同じリージョン (リージョン 1) にありますが、それぞれ Prod セグメントと Dev セグメントに関連付けられています。Inspection VPC 1 (100.64.1.0/24) も同じリージョンに存在します。 図 2: リージョン内、セグメント間のインスペクション 同一リージョン内の Prod VPC 1 から Dev VPC 1 へのトラフィックパスに NFG を挿入するために必要なステップを見ていきましょう： Step 1: 以下に示すサンプルポリシーを使用して、InspectionNFG Network Function Group (NFG) を作成します。 "network-function-groups": [ { "name": "InspectionNFG", "require-attachment-acceptance": false } ], Step 2: 以下に示すサンプルの アタッチメントポリシー を使用して、Inspection VPC 1 アタッチメントを InspectionNFG NFG に関連付けます。 "attachment-policies": [ { "rule-number": 100, "condition-logic": "or", "conditions": [ { "type": "tag-exists", "key": "stage" } ], "action": { "association-method": "tag", "tag-value-of-key": "stage" } } ] Step 3: segment-actions を設定してネットワーク機能 (すなわち Inspection VPC 1) をトラフィックパスに組み込む前に、Inspection VPC 1 アタッチメントが作成され、InspectionNFG に関連付けられていることを確認する必要があります。以下に示すサンプルの AWS CLI を使用してアタッチメントを作成できます。 aws networkmanager create-vpc-attachment \ --core-network-id "&lt;core-network-id&gt;" \ --vpc-arn "&lt;vpc-arn&gt;" \ --subnet-arns "&lt;subnet1-arn&gt;" "&lt;subnet2-arn&gt;" \ --tags Key=stage,Value=InspectionNFG Step 4: Inspection VPC 1 アタッチメントを作成し、Inspection NFG に関連付けたので、以下に示すサンプルの segment-actions を使用して、セグメント間トラフィックに InspectionNFG NFG を組み込みます。 "segment-actions": [ { "action": "send-via", "segment": "prod", "mode": "single-hop", "when-sent-to": { "segments": "*" }, "via": { "network-function-groups": [ "InspectionNFG" ] } } ], “when-sent-to ” の配下の “segments”: “*” はすべてのセグメントを意味します。つまり、Prod と他のセグメント (例えば、Dev、Test、Stage、QA など) の間で送信されるすべてのトラフィックが対象となります。”*” は、分離されたセグメントに対してセグメント内でのサービス挿入も提供します。 Inspection VPC 1 ネットワーク機能を通信経路に組み込むと、Prod セグメントと Dev セグメント間 (または、コアネットワークに存在する他のセグメント間) のすべてのトラフィックは、タグキー stage とタグ値 InspectionNFG を持つコアネットワークアタッチメントを使用して、Inspection VPC 1 のファイアウォールを経由して自動的に経路制御されます (図 3)。AWS Cloud WAN は以下の処理を行います: すべてのワークロードセグメントからのルートを、適切なワークロードアタッチメントにリダイレクトするネクストホップとともに、InspectionNFG ルートテーブルに伝播します。同一リージョン内で伝播されるルートは、そのネクストホップがローカルの NFG アタッチメントにリダイレクトされます。 注意： 後述のシナリオで説明するリージョン間ルーティングの場合、異なるリージョンからのルートは、ユーザー設定またはシステムデフォルトで設定された優先リージョンの NFG アタッチメントにネクストホップがリダイレクトされます。 ポリシーで指定されたすべてのセグメントペアについて、対応するワークロードセグメントルートテーブルにルートを伝播し、ネクストホップをローカルの NFG アタッチメントとして設定します。 図 3: リージョン内のセグメント間インスペクショントラフィックフロー Packet walkthrough: 以下のステップでは、同一リージョン内の Prod VPC 1 のリソースが Dev VPC 1 のリソースと通信する際のパケットの流れについて説明します。 (A) Prod VPC 1 のリソースが Dev VPC 1 のリソースへの接続を開始すると、Prod VPC 1 のルートテーブルを参照します。パケットはデフォルトルートエントリにマッチし、ターゲットとしてコアネットワークの Amazon リソースネーム (ARN) が指定されているため、パケットはコアネットワークにルーティングされます。 (B) パケットがコアネットワークに到達すると、Prod VPC 1 は Prod セグメントに関連付けられているため、Region 1 をエッジロケーションとして Prod セグメントのルートテーブルを参照します。パケットは Dev VPC 1 CIDR エントリにマッチし、Inspection VPC 1 アタッチメントがターゲットとなっているため、パケットは Inspection VPC 1 にルーティングされます。 (C) Inspection VPC 1 のファイアウォールが、設定されたセキュリティポリシーに基づいてトラフィックを検査し許可した後、パケットはコアネットワークに戻されます。 (D) パケットがコアネットワークに到達すると、Inspection VPC 1 は InspectionNFG に関連付けられているため、Region 1 をエッジロケーションとして InspectionNFG ルートテーブルを参照します。パケットは Dev VPC 2 CIDR エントリにマッチし、Dev VPC 1 アタッチメントがターゲットとなっているため、パケットは Dev VPC 1 にルーティングされます。 戻りトラフィックは、同じパスを逆方向にたどります。 シナリオ 2 – リージョン間、セグメント間のデュアルインスペクション 次の図 (図 4) はシナリオ 2 を示しています。シナリオ 2 はシナリオ 1 と似ていますが、Prod VPC と Dev VPC が異なるリージョンに配置されている点が異なります。Prod VPC 1 (10.1.0.0/16) はリージョン 1 に配置され、Prod セグメントに関連付けられています。一方、Dev VPC 2 (172.25.0.0/16) はリージョン 2 に配置され、Dev セグメントに関連付けられています。 異なるセグメント間のアタッチメント間を流れるトラフィックを検査する必要性に加えて、各 AWS リージョンを個別の保護された環境として扱う必要がある場合もあります。これを実現するために、各リージョンには独自の Inspection VPC があり、リージョン 1 には Inspection VPC 1 (100.64.1.0/24)、リージョン 2 には Inspection VPC 2 (100.64.2.0/24) があります。シナリオ 1 (Step 1-3) と同様に、InspectionNFG NFG を作成し、両方の Inspection VPC を InspectionNFG に関連付けます。 図 4: リージョン間、セグメント間のデュアルインスペクション 以下に示す segment-actions モードの dual-hop を使用して、リージョン間、セグメント間のトラフィックパスに InspectionNFG NFG を挿入します。これにより、各リージョンの Inspection VPC にトラフィックを振り分けすることが可能になります。 "segment-actions": [ { "action": "send-via", "segment": "prod", "mode": "dual-hop", "when-sent-to": { "segments": "*" }, "via": { "network-function-groups": [ "InspectionNFG" ] } } ], Inspection VPC 1 と Inspection VPC 2 のネットワーク機能を通信経路に挿入すると、Prod セグメントと Dev セグメント間 (または、コアネットワークに存在する他のセグメント間) のすべてのクロスセグメントトラフィックは、タグキー stage とタグ値 InspectionNFG を持つコアネットワークアタッチメントを使用して、それぞれ Inspection VPC 1 と Inspection VPC 2 のファイアウォールを経由して自動的にルーティングされます。これを図 5 で示します。 図 5: リージョン間、セグメント間のデュアルインスペクションのトラフィックフロー Packet walkthrough: 以下のステップは、Prod VPC 1 のリソースが Dev VPC 2 のリソースと通信する際のパケットの流れについて説明します。 (A) Prod VPC 1 のリソースが Dev VPC 2 のリソースへの接続を開始すると、Prod VPC 1 のルートテーブルを参照します。パケットはターゲットとしてコアネットワーク ARN を持つデフォルトルートエントリに一致し、パケットはコアネットワークにルーティングされます。 (B) パケットがコアネットワークに到着すると、Prod VPC 1 が Prod セグメントに関連付けられているため、Region 1 をエッジロケーションとして Prod セグメントのルートテーブルを参照します。パケットは、ターゲットとして Inspection VPC 1 アタッチメントを持つ Dev VPC 2 CIDR エントリに一致し、パケットは Region 1 の Inspection VPC 1 にルーティングされます。 (C) Inspection VPC 1 のファイアウォールが、設定されたセキュリティポリシーに基づいてトラフィックを検査し許可した後、パケットはコアネットワークに戻されます。 (D) パケットがコアネットワークに到着すると、Inspection VPC 1 が InspectionNFG に関連付けられているため、Region 1 をエッジロケーションとして InspectionNFG ルートテーブルを参照します。パケットは、ターゲットとして Inspection VPC 2 アタッチメントを持つ Dev VPC 2 CIDR に一致し、パケットは Region 2 の Inspection VPC 2 にルーティングされます。 (E) Inspection VPC 2 のファイアウォールが、設定されたセキュリティポリシーに基づいてトラフィックを検査し許可した後、パケットはコアネットワークに戻されます。 (F) パケットがコアネットワークに到着すると、Inspection VPC 2 が InspectionNFG に関連付けられているため、Region 2 をエッジロケーションとして InspectionNFG ルートテーブルを参照します。パケットは、ターゲットとして Dev VPC 2 アタッチメントを持つ Dev VPC 2 CIDR エントリに一致し、パケットは Dev VPC 2 にルーティングされます。 戻りトラフィックは、同じパスを逆方向にたどります。 シナリオ 3 – リージョン間、セグメント間のシングルインスペクション リージョンペアの場合、Service Insertion により、セグメント間のトラフィック検査を行うリージョンを選択できます。リージョン間およびセグメント間のトラフィック検査に使用するリージョンを選択するために、デフォルトで 順序付きリスト を使用します。以下に示す segment-actions モードの single-hop を使用して、リージョン間およびセグメント間のトラフィックパスに InspectionNFG NFG を挿入します。 "segment-actions": [ { "action": "send-via", "segment": "prod", "mode": "single-hop", "when-sent-to": { "segments": "*" }, "via": { "network-function-groups": [ "InspectionNFG" ] } } ], 図 6 に示すように、Region 1 と Region 2 のペアにおいて、Region 1 は us-east-1、Region 2 は us-west-2 であり、 順序付きリスト に従って、Region 1 (us-east-1) がインスペクションのデフォルトリージョンとして選択されています。そのため、Prod VPC と Dev VPC 間のすべてのリージョン間トラフィックは、インスペクションのために Region 1 の Inspection VPC 1 を経由してルーティングされます。 図 6: リージョン間、セグメント間のシングルスペクションのトラフィックフロー Packet walkthrough: 以下のステップでは、Prod VPC 1 のリソースがシングルインスペクションを使用して Dev VPC 2 のリソースと通信する際のパケットの流れについて説明します。 ステップ (A) から (C) は、シナリオ 2 で説明したものと同じですが、以下の点が異なります。 (D) パケットがコアネットワークに到着すると、Inspection VPC 1 が InspectionNFG に関連付けられているため、リージョン 1 をエッジロケーションとして InspectionNFG ルートテーブルの検索を行います。パケットは Dev VPC 2 CIDR エントリと一致し、リージョン 2 をエッジロケーションとして InspectionNFG ルートテーブルの検索を実行するように要求します。 (E) リージョン 2 をエッジロケーションとして InspectionNFG ルートテーブルの検索を行います。パケットは、Dev VPC 2 アタッチメントをターゲットとする Dev VPC 2 CIDR エントリに一致し、Inspection VPC 2 ではなく、パケットは Dev VPC 2 にルーティングされます。 戻りトラフィックは、同じパスを逆方向にたどります。 考慮事項 NFG はグローバルな性質を持ち、コアネットワークに属するどの AWS リージョンからでもアタッチメントを追加できます。たとえば、コアネットワークが 3 つの AWS リージョン (us-east-1、eu-west-1、ap-west-1 など) にまたがって運用されている場合、これら 3 つのリージョンのいずれからでも、単一の NFG にインスペクションまたはファイアウォール VPC を追加できます。 NFG は、コアネットワークごとの AWS Cloud WAN セグメントの クォータ から、1 つのグローバルセグメントを消費します。 ワークロードセグメントと NFG の両方で、すべてのアタッチメントタイプ (VPC、VPN、connect、transit gateway) がサポートされています。 このブログ投稿の執筆時点では、動的アタッチメント (VPN、connect、transit gateway peering) を通じて NFG にアドバタイズされた動的ルートは、NFG ルートテーブルにインストールされません。また、Service Insertion を機能させるためには、デフォルトルート (0/0、::/0) を動的アタッチメントを通じて NFG にアドバタイズする必要があります。詳細については、AWS Cloud WAN のドキュメントを参照してください。 コアネットワークごとに複数の NFG がサポートされていますが、セグメントペア内のインサーションごとに単一の NFG のみが許可されます。アタッチメントはセグメントまたは NFG のいずれかに関連付けることができますが、両方に関連付けることはできません。通常、ワークロードアタッチメント (ワークロード VPC) はセグメントに関連付けられ、インスペクション VPC (ファイアウォール、侵入検知システム、侵入防止システムアプライアンスをホスト) は NFG に関連付けられます。 同じコアネットワークで複数の NFG を設定できます。ただし、同じセグメントまたはセグメントペアに複数の NFG を挿入することはできません。 同じセグメントに接続されたリソース間のトラフィックを検査する必要がある場合は、該当するワークロードセグメントの分離モードを有効にします。この設定により、挿入が必要なネットワーク機能をバイパスすることなく、セグメントに関連付けられたアタッチメント間の直接接続を防止します。 AWS Cloud WAN の アプライアンスモード は、Service Insertion とは独立しており、VPC 内のセキュリティインフラストラクチャを通じてステートフルインスペクションを確実に行いたい場合に必要です。特定のネットワークフローの双方向のトラフィックが同じアベイラビリティーゾーンに、そして結果として同じセキュリティアプライアンスにステートフルインスペクションの目的で転送されるようにするには、インスペクション VPC アタッチメントでアプライアンスモードを有効にする必要があります。 AWS Cloud WAN は IPv4 と IPv6 の両方をサポートしています。 通常の AWS Cloud WAN の料金 以外に、Service Insertion の使用に関する追加料金はありません。 業界をリードするパートナー AWS Cloud WAN Service Insertion のローンチにおいて、業界をリードするパートナー企業と協力できたことを嬉しく思います。パートナー企業の素晴らしい取り組みとコメントをご紹介します： Aviatrix ブログ Check Point ブログ Cisco ブログ F5 ブログ Fortinet ブログ Netskope ブログ Palo Alto Networks ブログ 1 ブログ 2 まとめ このブログ記事では、AWS Cloud WAN Service Insertion について説明しました。これは、中央のポリシードキュメントを使用して AWS および他社のネットワークとセキュリティサービスを AWS Cloud WAN にシームレスに挿入できる新機能です。この機能を使用すると、シンプルなポリシーステートメントを定義するか、コンソールを使用することで、VPC 間または VPC とオンプレミス間のトラフィックをネットワークまたはセキュリティアプライアンスを通じて簡単に制御できます。また、この新機能を使用したリージョン内およびリージョン間のインスペクションアーキテクチャについても説明しました。詳細については、 AWS Cloud WAN のドキュメントをご参照ください。 更新情報: 2024 年 6 月 28 日: 図 5 とそれに続くパケットの説明に修正を加えました。 2024 年 11 月 25 日: 業界をリードするパートナーとして Fortinet が追加されました。 著者について Pratik Mankad Pratik は、AWS の Network Solutions Architect です。彼はネットワーク技術に情熱を持ち、お客様の問題解決を支援するためにイノベーションを生み出すことを愛しています。彼はソリューションの設計と技術的なガイダンスの提供を通じて、お客様やパートナーが技術的・ビジネス的な目標を達成できるよう支援することを楽しんでいます。 Shridhar Kulkarni Shridhar は Amazon Virtual Private Cloud（VPC）チームの一員であり、AWS Cloud WAN サービスのプロダクトマネジメントをリードしています。彼は、クラウド、SAAS、モバイル、SD-WAN、仮想化、WAN 最適化、SDN、データネットワーキング（L1-L7）、VoIP、ケーブル、FTTH、x86 ハードウェアプラットフォームに関する専門知識を持つ、強力で多様な技術的バックグラウンドを有しています。また彼は、世界中のクラウド、エンタープライズ、サービスプロバイダー、中小企業の顧客向けに最先端のハイテク製品やサービスを提供してきた実績があり、コンピュータサイエンスの修士号と UCLA アンダーソン経営大学院のMBAを取得しています。 Rizwan Mushtaq Rizwan は AWS の Principal Solutions Architect です。彼はお客様が AWS サービスを使用して革新的で耐障害性が高く、コスト効率のよいソリューションを設計することを支援しており、ウィチタ州立大学で電気工学の修士号を取得しています。 翻訳は Solutions Architect の疋田 洋一が担当しました。原文は こちら です。

商品を購入する前に、新しい服が自分にどのように似合うかをすばやく確認できたらいいのに、と思ったことはありませんか？あるいは、リビングに置いた家具はどう見えるか、気になったことはありませんか？本日、このような商品画像生成の課題に対応する Amazon Nova Canvas の新しい Virtual try-on 機能を紹介できることを嬉しく思います。さらに、スタイルの一貫性を向上させるための 8 つの新しいスタイルオプションが、text-to-image ベースのスタイルプロンプトに追加されました。これらの機能により、Nova Canvas AI を活用した画像生成機能が拡張され、顧客体験を向上させるリアルな製品の視覚化や、定型化された画像の作成作業がこれまでになく簡単になります。 今すぐ使い始める方法を簡単に見てみましょう。 Getting started まず、通常の方法で Nova Canvas モデルにアクセスできることを確認します。 Amazon Bedrock コンソール で [モデルアクセス] を選択し、 アカウントの Amazon Nova Canvas を有効にして 、ワークロードに適したリージョンを選択していることを確認します。モデルアクセスの有効化方法については、ブログ「 Amazon Bedrock のモデルアクセスの有効化や制限値の引き上げができない時の対応方法 」をご覧ください。すでに Nova Canvas にアクセスして使用している場合は、新機能が自動的に利用可能になるので、すぐに使い始めることができます。 Virtual try-on 最初のエキサイティングな新機能は Virtual try-on です。この機能を使用して、2 枚の写真をアップロードして Amazon Nova Canvas に依頼すると、現実的な仕上がりとなるようにそれらの画像が合成されます。これらの画像は、アパレル、アクセサリー、家具、および、多様な衣類を含む、様々な種類のその他の製品の写真が想定されます。たとえば、ソース画像として人物の写真、参照画像として衣服の写真を指定すると、Amazon Nova Canvas が同じ人が衣服を着ている新しい画像が作成されます。これを試してみましょう。 私はまず、2 つの画像を選択することから始めました。服の交換にぴったりだと思うポーズをしている私の写真と、AWS ブランドのパーカーの写真を 1 枚選びました。 Nova Canvas への入力画像は、最大 410 万ピクセル（2,048 x 2,048 に相当）であることに注意してください。(詳細要件は Amazon Nova ユーザーガイド(英語) を参照) 必要に応じて、これらの制限に合わせて画像のサイズを調整してください。また、この記事で取り上げた Python コードを実行したい場合は、Python 3.9 以降と Python パッケージ boto3 と pillow がインストールされていることを確認してください。 このパーカーを私の写真に適用するには、Amazon Bedrock ランタイムの invoke API を使っています。この API のリクエストとレスポンス構造の詳細については、 Amazon Nova ユーザーガイド(英語) をご覧ください。コードは単純で、必要な推論パラメータはごくわずかです。私は "VIRTUAL_TRY_ON" という新しい taskType を使用しました。次に、 virtualTryOnParams オブジェクトを使用して必要なパラメータをいくつか設定し、ソースイメージと参照イメージの両方を含め、必要な設定を指定しました。どちらのイメージも Base64 文字列に変換する必要があることに注意してください。 import base64 def load_image_as_base64(image_path): """Helper function for preparing image data.""" with open(image_path, "rb") as image_file: return base64.b64encode(image_file.read()).decode("utf-8") inference_params = { "taskType": "VIRTUAL_TRY_ON", "virtualTryOnParams": { "sourceImage": load_image_as_base64("person.png"), "referenceImage": load_image_as_base64("aws-hoodie.jpg"), "maskType": "GARMENT", "garmentBasedMask": {"garmentClass": "UPPER_BODY"} } } Nova Canvas はマスキングを使用して画像を操作します。これは、マスキングテープを使用してペイントしたくない領域を保護するのと同様に、AI 画像生成で画像の特定の領域または領域に焦点を合わせながら、他の領域は保存できるようにする手法です。 マスキングには、3 種類のマスキングモードを使用できます。 maskType を適切な値に設定することで選択できます。今回は、日本語で衣料品を示す言葉である "GARMENT" タイプを使っているので、同時に、体のどの部分をマスクしたいかを指定する必要があります。私は "UPPER_BODY" を使用していますが、特に足をターゲットにしたい場合は "LOWER_BODY" や、 "FULL_BODY" 、 "FOOTWEAR" など他のものを使用してもかまいません。オプションの全リストは Amazon Nova ユーザーガイド(英語) を参照してください。 次に invoke API を呼び出し、これらの推論引数を渡して、生成されたイメージをディスクに保存します。 # Note: 上記の inference_params 変数が以下で参照されています。 import base64 import io import json import boto3 from PIL import Image # Create the Bedrock Runtime client. bedrock = boto3.client(service_name="bedrock-runtime", region_name="us-east-1") # Prepare the invocation payload. body_json = json.dumps(inference_params, indent=2) # Invoke Nova Canvas. response = bedrock.invoke_model( body=body_json, modelId="amazon.nova-canvas-v1:0", accept="application/json", contentType="application/json" ) # Extract the images from the response. response_body_json = json.loads(response.get("body").read()) images = response_body_json.get("images", []) # Check for errors. if response_body_json.get("error"): print(response_body_json.get("error")) # Decode each image from Base64 and save as a PNG file. for index, image_base64 in enumerate(images): image_bytes = base64.b64decode(image_base64) image_buffer = io.BytesIO(image_bytes) image = Image.open(image_buffer) image.save(f"image_{index}.png") 非常にエキサイティングな結果を得ました！ このように、私は AWS ブランドのパーカーを着ることができ、誇りに思います！ "GARMENT" mask type に加えて、 "PROMPT" や "IMAGE" マスクも使用することができます。 "PROMPT" では、ソース画像と参照画像も提供する必要がありますが、ソース画像のどの部分を置換するかを自然言語のプロンプトで指定します。これは、Nova Canvas の "INPAINTING" と "OUTPAINTING" タスクの仕組みと似ています。独自のイメージマスクを使用する場合は、 "IMAGE" mask type を使用し、マスクとして使用する白黒画像を指定します。黒はソースイメージで置き換えたいピクセルを示し、白は維持したいピクセルを示します。 この機能は小売業者にとって特に便利です。これを利用して、購入前に商品の見た目を確認することで、顧客がより適切な購入判断を下せるようになります。 Style options アニメのスーパーヒーローになったらどんなふうになるのだろうといつも思っていました。以前は、Nova Canvasを使って自分の画像を操作できましたが、それを適切に行うには、優れたプロンプトエンジニアリングスキルに頼らざるを得ませんでした。 現在、Nova Canvasには事前にトレーニングされたスタイルオプションが付属しており、それを画像に適用して、お好みの芸術的スタイルに沿った高品質の結果を得ることができます。3Dアニメーションファミリーフィルム、デザインスケッチ、フラットベクターイラスト、グラフィックノベル、マキシマリズム、ミッドセンチュリーレトロ、フォトリアリズム、ソフトデジタルペインティングなど、8つのスタイルが用意されています。 それらの適用は、Nova Canvas API に追加のパラメーターを渡すのと同じくらい簡単です。例を試してみましょう。 「3D アニメーションファミリーフィルム」スタイルを使って AWS のスーパーヒーローのイメージを生成したいと思います。そのためには、 "TEXT_IMAGE" という taskType と、 text と style の 2 つのパラメータを含む textToImageParams オブジェクトを指定します。 text パラメータには、作成したい画像を説明するプロンプトが含まれています。今回は「大きな AWS ロゴとケープが付いた黄色い衣装のスーパーヒーロー」と指定しています。 style パラメータは、定義済みのスタイル値の 1 つを指定します。ここでは "3D_ANIMATED_FAMILY_FILM" を使用していますが、全リストは Amazon Nova ユーザーガイド(英語) に記載されています。 inference_params = { "taskType": "TEXT_IMAGE", "textToImageParams": { "text": "a superhero in a yellow outfit with a big AWS logo and a cape.", "style": "3D_ANIMATED_FAMILY_FILM", }, "imageGenerationConfig": { "width": 1280, "height": 720, "seed": 321 } } 次に、前の例と同じように invoke API を呼び出します。(ここでは簡潔にするためにコードを省略しています)。そしてその結果は？さて、皆様ご判断いただければと思いますが、AWS のスーパーヒーローが、私の好きな色を、私が思い描いていた 3D アニメーションのファミリーフィルムのスタイルにあわせて着ています。とても満足していると言わざるを得ません。 本当に素晴らしいのは、コードとプロンプトをまったく同じにしたまま、スタイル属性の値を変更するだけで、まったく異なるスタイルの画像を生成できることです。これを試してみましょう。 style を PHOTOREALISM に設定しました。 inference_params = { "taskType": "TEXT_IMAGE", "textToImageParams": { "text": "a superhero in a yellow outfit with a big AWS logo and a cape.", "style": "PHOTOREALISM", }, "imageGenerationConfig": { "width": 1280, "height": 720, "seed": 7 } } そして、その結果は印象的なものとなりました！私が説明したとおりのフォトリアリスティックなスーパーヒーロー。これは前に生成されたアニメスタイルとは全く異なるものとなり、必要な作業は、1 行のコードを変更することだけでした。 知っておくべきこと 利用可能なリージョン – Virtual try-on とスタイルオプションは、US East (N. Virginia)、Asia Pacific (Tokyo)、 Europe (Ireland) の Amazon Nova Canvas で利用いただけます。Amazon Nova Canvas の既存ユーザーは、新しいモデルに移行しなくてもすぐにこれらの機能を使用できます。 料金 – Amazon Bedrock 料金ページ をご覧ください。 Virtual try-on は簡単に試すことができます。 nova.amazon.com (http://nova.amazon.com/) へアクセスし、人物と衣服の画像をアップロードして、様々な服の着せ替えを楽しんでください！ 始める準備ができたら、Nova Canvas ユーザーガイドを確認するか、AWS コンソールにアクセスしてください。 Matheus Guimaraes | @codingmatheus Matheus Guimaraes Matheus Guimaraes (@codingmatheus) は .NET と microservice のスペシャリストで、インターナショナル キーノートスピーカーです。また、AWS の開発者支援者25 年以上技術に携わってきた彼は、ジュニアゲームプログラマーから CTO、スタートアップの創設者まで、さまざまな役職を歴任してきました。Matheus は、あらゆる規模の企業のシステムの近代化と拡張を支援し、デジタルトランスフォーメーションを主導し、クラウドネイティブアーキテクチャを設計してきました。現在、彼は講演、ブログ、ビデオを通じて専門知識をグローバルに共有し、業界で他の企業の成長を支援することに情熱を注いでいます。テクノロジー以外にも、彼はゲーマー、スイマー、ミュージシャンであり、創造性とコードの強力な融合を信じています。

本稿は、2024年4月15日に AWS Cloud Operations Blog で公開された “ Automate incident reports from AWS Systems Manager Incident Manager ” を翻訳したものです。 システムの信頼性を維持し、予期せぬインシデントに迅速に対応するためには、効果的なインシデント管理が最も重要です。AWS Systems Manager の機能である Incident Manager は、自動対応機能を提供することで、これらのインシデントの緩和と復旧を支援します。以前の Incident Manager に関するブログでは、エスカレーションメカニズムの設定、対応計画の作成、AWS Systems Manager Automation ランブックを使用した修復の自動化について説明しました。詳細については、 AWS Systems Manager Incident Managerで連絡先、エスカレーションプラン、対応プランを作成する をご覧ください。 インシデントライフサイクルの一環として、組織がインシデントの過去データを収集し、振り返って事後分析を行うことが重要です。お客様は AWS SDK を使用して、これらすべてのインシデントに関する情報をプログラムで収集してエクスポートすることができます。お客様からは、このレポート生成プロセスを自動化し、これらのレポートを一元化された場所に定期的にエクスポートする方法についてよく質問を受けます。 このブログでは、スケジュールに従って Incident Manager のレポートを生成し、Amazon Simple Storage Service (Amazon S3) に保存する方法を説明します。これらのレポートは、関係するリソース、頻発する問題、修正に要する時間などに基づいてインシデントを確認し、並べ替えるのに役立ちます。これらは、運用エンジニア、システム管理者、IT マネージャーに重要な気づきを与えます。過去のデータを掘り下げることで、アプリケーションやインフラストラクチャの異常を発見できます。 前提条件 このウォークスルーを行うには、以下の前提条件が必要です AWS アカウント シングルアカウントまたはマルチアカウント、マルチリージョンで設定された Incident Manager ワークフロー このソリューションは、以下のサービスによって実現されています。 AWS CloudFormation Amazon S3 AWS Identity and Access Management (IAM) AWS Systems Manager の機能である Automation AWS Systems Manager の機能である State Manager AWS Systems Manager の機能である Incident Manager 図1: Incident Manager レポート生成ソリューション CloudFormation テンプレートは GitHub リポジトリ にホストされています。CloudFormation は、このソリューションで使用される必要なコンポーネントをデプロイします。これには、S3 バケット、Automation ランブック、State Manager アソシエーション、必要な IAM 権限が含まれます。Automation は Incident Manager API に接続して必要な情報を抽出し、CSV ファイル形式で S3 バケットにアップロードします。 ソリューションを実行するたびに、新しいレポートが生成されます。オプションとして、スケジュールでソリューションを実行することを選択した場合、CloudFormation テンプレートは、CloudFormation スタックの作成時にパラメータとして指定されたスケジュールで実行される State Manager アソシエーションを作成します。 Automation ランブックには、Python スクリプトを実行してレポートを生成および保存する&nbsp; aws:executeScript アクションが含まれています。Python スクリプトは ListIncidentRecords API を呼び出して、現在のリージョンのすべてのインシデントを取得します。次に、スクリプトはインシデントごとに&nbsp; ListRelatedItems API を実行して、関連するすべてのアイテムを取得します。収集したインシデントは CSV ファイルに保存され、 IMReport-{Current Date}-{Time in UTC} の形式で名前が付けられます。この CSV ファイルは、ダウンロード用の S3 バケットにアップロードされます。さらに、このソリューションをカスタマイズして、各レポートを S3 へアップロードした時に SNS 通知を送信することができます。詳細については、 Amazon S3 イベント通知 を参照してください。 ソリューションの手順 単一のアカウントまたはマルチアカウントおよびマルチリージョンのインシデント管理では、インシデントはすべてのアカウントとレプリケーションセットリージョンに複製されます。したがって、目的のアカウントとリージョンに CloudFormation テンプレートをデプロイして、インシデントとそれに関連するアイテムを取得できます。 ソリューションのデプロイ CloudFormation テンプレート をダウンロードします。 レポートを生成したい AWS アカウントの CloudFormation コンソール に移動します。 Create Stack で、with new resources (standard) を選択します。 Prepare template で、Choose an existing template を選択し、Template source で Upload a template file を選択します。Choose file をクリックし、ステップ 1 でダウンロードしたテンプレートを選択します。 Next をクリックします。 Stack name に、スタック名 ( 例: incident-manager-reporting ) を入力します。 Parameters エリアで以下の操作を行い、Next をクリックします。 ‘RunOnSchedule’ にて、定期的にレポートを生成する場合は true を選択し、レポートを手動で生成する場合は false を選択します。 false を選択した場合、この CloudFormation テンプレートをデプロイした後、 Generating OnDemand reports セクションを参照して、Automation ランブックを手動で実行する必要があります。 ‘AssociationSchedule’ ( RunOnSchedule が true に設定されている場合のみ必要 ) では、CRON 式を入力します。デフォルトでは、毎週日曜日の 02:00 AM UTC に自動で実行されます。サポートされている CRON 式の詳細については、 リファレンス を参照してください。 Configure stack options ページで I acknowledge that AWS CloudFormation might create IAM resources. を選択し、Next をクリックします。 Review and create ページで、Submit をクリックします。 テンプレートがデプロイされた後、図 2 に示されているように Outputs を選択して以下の値を確認してください。 AWSSystemsManagerAutomationExecutionRole S3Bucket SystemsManagerAutomationDocument 図2：CloudFormation の出力リソース オンデマンドレポートの生成 注意 – CloudFormation テンプレートをデプロイする際に `RunOnSchedule` パラメータを true に設定した場合は、このセクションをスキップして S3 コンソールからレポートをダウンロード のセクションに進んでください。 Systems Manager Automation に移動します。 Execute runbook をクリックします。 Owned by me を選択し、Outputs で確認した SystemsManagerAutomationDocument の Value に表示されていたランブック名 (incident-manager-reporting-SystemsManagerAutomationDocument-*) を選択します。Next をクリックします。 図 3: Automation ランブック Simple execution を選択します。 Input parameters エリアの AutomationAssumeRole には、 図 4 に示されているように CloudFormation スタックから出力された AWSSystemsManagerAutomationRole の Value を入力します。S3BucketName には、CloudFormation スタックから出力された S3Bucket の Value を入力します (これがデフォルト値になります)。 図 4: Automation Assume Role と S3 Bucket の入力 Execute をクリックします。 Automation ランブックがアカウントのすべてのインシデントに関する情報を収集します。図 5 に示されているように、Executed steps で Step ID をクリックし、 OutputPayload の Amazon S3 バケットと CSV ファイル名を確認します。 図 5: Systems Manager Automation の出力 S3 コンソールからレポートをダウンロード S3 console に移動し、バケットを見つけて IM Report CSV をダウンロードします。図 6 に示されるように、ファイル名にはレポートが生成された日時 (UTC) が含まれています。 図 6: レポートファイルの IMReport CSV をダウンロード 図 7: Incident Manager レポートファイルの例 クリーンアップ CloudFormation で作成したリソースをクリーンアップする: S3 バケット内に生成されたオブジェクトを手動で削除 AWS S3 コンソールを開き、CloudFormation で生成された S3 バケットを見つけます。 すべてのオブジェクトを選択し、Delete をクリックします。 削除を確定するには、テキスト入力フィールドに permanently delete と入力します。 ‘Delete objects’ をクリックします。 CloudFormation スタックを削除 Open the AWS CloudFormation コンソール を開き、ナビゲーションペインで Stacks を選択します。 作成した CloudFormation スタックを選択し、 Delete をクリックした後、確認画面で Delete をクリックします。 まとめ このブログ記事では、Incident Manager API と AWS Systems Manager Automation および State Manager Association を使用して、全てのインシデントとそれに関連するアイテムをスケジュールに従って定期的に保存するレポート生成ソリューションについて説明しました。このソリューションでは以下のことができます: レポート生成の自動化: 手作業は不要 – プロセスを合理化し、レポートを Amazon S3 に安全に保存します。 貴重な傾向の発見: 頻繁に発生する問題、脆弱なリソース、解決時間を特定します。 効率と安全性の向上: ボトルネックを事前に解消し、再発を防止し、クラウド環境を最適化して最大限の回復力を実現します。 著者について: Ali Alzand Ali は、Amazon Web Services の Microsoft スペシャリストソリューションアーキテクトです。Ali は、グローバルな顧客と連携し、Microsoft ワークロードの AWS クラウドへの移行、近代化、最適化を支援しています。専門は、AWS Systems Manager、Amazon EC2 Windows、PowerShell です。仕事以外では、バーベキュー、アウトドア活動、さまざまな食べ物に挑戦することを楽しんでいます。 Raviteja Sunkavalli Raviteja Sunkavalli は、Amazon Web Services のシニアクラウドサポートエンジニアです。Ravi は、グローバル顧客のクラウド移行と集中運用の効率化をサポートしています。専門は、AWS Systems Manager と EC2 Windows サービスです。テクノロジー以外では、クリケットをプレーしたり、新しいレシピに挑戦したりすることを楽しんでいます。 翻訳は SA 渡邊が担当しました。 TAGS: AWS Systems Manager , Cloud Operations , Operations Integrations , Systems Manager Automation , Systems Manager Incident Manager