2026 年 3 月 24 日に公開された “ Building a modern network for your VMware workloads using Amazon Elastic VMware Service ” を翻訳したものです。 組織がクラウド移行を加速させようとする中で、多くのお客様は既存の VMware ワークロードを Amazon Web Services (AWS) にリフトアンドシフトする方法を求めており、アプリケーションのリファクタリングやスタッフの再トレーニングのオーバーヘッドを避けたいと考えています。 Amazon Elastic VMware service (Amazon EVS) は、VMware Cloud Foundation (VCF) を Amazon Virtual Private Cloud (VPC) 内で直接実行でき、VMware ワークロードを AWS で移行・運用するための最も迅速な方法を提供します。 VMware ワークロードを AWS に移行する際にお客様が課題として挙げるのが、クラウドでのネットワーク接続とアーキテクチャ設計です。Amazon EVS のネットワークモデルは、一般的なオンプレミスの VMware デプロイメントとはいくつかの違いがあります。本稿では、Amazon EVS のネットワークモデルを解説し、実証済みのアーキテクチャパターンをご紹介し、Amazon EVS の計画と導入を成功させるための重要な考慮事項をご説明します。 Amazon EVS ネットワークコンポーネント Amazon EVS は、図 1 に示すように、AWS インフラストラクチャ上で VCF ワークロードをデプロイし、運用するために構築された AWS マネージド自動化フレームワークです。Amazon EVS は、VCF の Software-Defined Data Center (SDDC) スタック (vSphere, vSAN, NSX) を Amazon VPC に完全に統合し、VMware ツールと API を保持しながら、シームレスなハイブリッドクラウド運用を可能にします。Amazon EVS ネットワークは、Amazon VPC ネットワークを分離する 2 層モデルに従い、お客様が VMware NSX Software-Defined Networking を使用できるようにします。 アンダーレイ層 (VPC infrastructure) : Amazon VPC, サブネット, ルートテーブル, およびお客様が選択したサブネット内で実行される ENI 接続 ESXi ホストで構成されます。この層はホストマネジメントトラフィック (vSphere, vSAN) を処理し、デフォルトまたはメイン VPC ルートテーブルを通じて IP 接続を実現します。 オーバーレイ層 (NSX Software-Defined Networking) : NSX Manager はマネジメントワークロードドメイン内にデプロイされ、ロジカルスイッチ (セグメント), T0/T1 ゲートウェイ, およびサービス (NAT, Load Balancing, DHCP) をオーケストレーションします。NSX マイクロセグメンテーションとポータブルネットワークポリシーが有効化され、アンダーレイ VPC ネットワークから抽象化し、お客様のワークロードはオーバーレイセグメント上でのみ実行されます。 図 1: ルートサーバーエンドポイントを使用した Amazon EVS と Amazon VPC の統合 主要コンポーネントの詳細 vSphere クラスター: Amazon EVS は統合された VCF アーキテクチャ (vCenter, NSX Manager, vSAN) をデプロイし、お客様が 1 つ以上のワークロードドメインを作成できるようにします。ESXi ホストは、お客様所有の VPC とサブネット内で Amazon Elastic Compute Cloud (Amazon EC2) ベアメタルインスタンス (例: i4i.metal) として起動されます。SDDC Manager と vCenter は、SDDC と vSphere クラスターコンポーネントの管理を担います。これらのコンポーネントは、管理ドメインとも呼ばれる最初の SDDC クラスター内で実行されます。さらに、3 つのクラスター化された NSX Manager が SDDC クラスター内で実行され、一元化されたネットワークポリシーオーケストレーションを可能にします。コントロールプレーンは、オーバーレイトランスポートゾーン、セグメントプロファイル、ゲートウェイファイアウォールルールを設定します。 NSX Edge ノード: 2 つの Edge ノードが最初のクラスターまたは管理ドメイン内の Edge クラスターにデプロイされます。T0 Gateway は各 AWS アベイラビリティーゾーン (AZ) サブネット内の VPC ルートサーバーエンドポイントと eBGP ピアリングを確立し、オーバーレイ CIDR をアドバタイズします。T1 Gateway (テナント/ワークロードごとに 1 つ) はセグメントを接続し、ステートフルサービスを提供します。NSX Edge はレジリエンシーのためにアクティブ-スタンバイ構成です。 VPC ルートサーバーエンドポイントと BGP ピアリング: Amazon EVS は Amazon VPC ルートサーバー をアンダーレイ BGP ネイバーとして使用します。各 T0 Edge は VPC ルートサーバーエンドポイントに接続し、アンダーレイ ENI 上で eBGP セッションを確立します。VPC のデフォルトまたはメインルートテーブルのみが変更されます。Amazon EVS はアウトバウンドトラフィック用に T0 ENI を指す 0.0.0.0/0 を注入し、オーバーレイプレフィックスをインバウンドに伝播します。この設計により、カスタムルートテーブルの拡散が排除され、自動化が合理化されます。 ネットワークアーキテクチャの計画 Amazon EVS の導入を成功させるには、導入前のネットワーク計画が重要です。特に CIDR 割り当て、サブネット分離、DNS 解決に関する計画が必要です。Amazon EVS では、運用の安定性、スケーラビリティ、他の AWS サービスとの統合を提供するための厳格な制約があります。これらの領域での設定ミスは、導入失敗の主要な原因となっています。 CIDR の計画と制約 Amazon EVS では、インフラストラクチャとワークロードのネットワークに専用の重複しない CIDR ブロックが必要です。AWS では、この情報をまとめるためのツールをお客様に提供しています。 このツール は、アカウント、VPC、CIDR、DNS の情報を含むスプレッドシートで、オンボーディング中の計画に使用し、プロビジョニング前の実現可能性を検証します。 VCF では、図 2 に示すように、用途毎 (マネジメント, vSAN, NSX インターフェース, アプライアンスなど) に異なるサブネットを使用します。Amazon EVS では、適切なサブネットデプロイメントを提供するオーケストレーションを提供します。アンダーレイインフラストラクチャには VPC あたり最小 /24 CIDR が必要で、Amazon EVS マネジメントサブネットではお客様のワークロード (踏み台ホストや監視エージェントを含む) を起動することはできません。これらは VCF コンポーネント専用です。 VCF 以外のサブネットは、同じ VPC 内にデプロイして使用できます。Amazon EVS VPC に他のワークロードを追加する際には、 AWS Well-Architected のベストプラクティスを考慮してください。 Amazon EVS のサブネットの最大サイズは /24 です。host-vtep ネットワークはホストあたり 2 つのアドレスを消費するため、/24 では最大 112 台のホストをホストできます。 図 2: オーバーレイネットワーク用の EVS VLAN サブネット オーバーレイセグメント設計と VM ネットワーク: これらはオーバーレイセグメントに階層的に CIDR を割り当てます (例：アプリケーションティアごとに /24)。成長とワークロード数の増加を想定し、ルートテーブルの効率化のために、ルート集約を検討してください。 CIDR が重複しないこと: すべてのオーバーレイ CIDR は以下と重複してはいけません。 VPC プライマリ CIDR オンプレミスネットワーク ( AWS Direct Connect と AWS Transit Gateway 用) 同じ AWS アカウント内の他の Amazon EVS ワークロードドメイン。Amazon EVS は BGP プレフィックスアドバタイズメントを使用し、重複はサイレントトラフィックブラックホールを引き起こします。 NSX ネットワークセグメント内での重複サブネットは、テスト目的のワークロードを隔離するのに良い方法です。 DNS DNS 解決は Amazon EVS のデプロイメント前に設定と検証を行う必要があります。DNS 解決が適切に行われていない場合やタイプミスがある場合、Amazon EVS (VCF) のデプロイメントは失敗します。 Amazon EVS は DNS 解決に Amazon Route 53 Resolver を使用できます。vCenter と NSX Manager アプライアンスには DNS フォワーダーが事前設定されており、Route 53 Resolver インバウンドエンドポイント (VPC にデプロイ) にクエリを送信できます。 Amazon EVS は Microsoft DNS、Infoblox、その他のサードパーティソリューションなど、他の DNS サービスも使用できます。 Amazon EVS の起動前に外部ホストから nslookup や dig -x でテストを行うことで、時間のかかる潜在的にコストの高いデプロイメント失敗を防ぐことができます。 前提条件 この 前提条件チェックリスト を参照して、デプロイメントを成功させるための情報収集と整理を行ってください。これは、前述した スプレッドシート と併用できます。適切な事前計画により、Amazon EVS ネットワークデプロイメントの問題の 90% を解決できます。このチェックリストでは、以下の項目について触れています。 VPC CIDR Amazon EVS (VCF) サブネット Route 53 Resolver エンドツーエンドで検証された正引き / 逆引き DNS 一般的なネットワークパターン このセクションでは、デプロイメントで検討すべき一般的なアーキテクチャについて説明します。 パターン 1: Transit Gateway と AWS Cloud WAN を使用した Amazon EVS VPC から他の VPC およびオンプレミスネットワークへの接続 図 3: Transit Gateway を使用した Amazon EVS VPC から他のネットワークへの接続 図 3 に示すこのパターンは、Amazon EVS オーバーレイセグメントから複数の VPC、オンプレミス/外部ネットワーク、および他の AWS リージョンへの一貫性のあるスケーラブルな接続が必要な場合に使用します。 このパターンでは以下の点が重要です: 本稿の執筆時点 (2026/3) では、VPC ピアリングはサポートされていません。Amazon EVS VPC から他の VPC への接続には Transit Gateway や AWS Cloud WAN が必要です。 Transit VIF を使用した Direct Connect や AWS Site-to-Site VPN は、Amazon EVS アンダーレイ VPC ではなく、Transit Gateway / AWS Cloud WAN で終端する必要があります。Amazon EVS は Private VIF や VGW ベースの Site-to-Site VPN をサポートしていません。 NSX オーバーレイプレフィックスは BGP を通じて VPC ルートサーバーによって学習され、VPC ルートテーブルに伝播されますが、Transit Gateway と AWS Cloud WAN はこれらのルートを自動的にインポートしません。そのため、各 NSX オーバーレイ CIDR 範囲について、Amazon EVS VPC アタッチメントを指す静的ルートを Transit Gateway/AWS Cloud WAN ルートテーブルに追加する必要があります (図 3 参照)。AWS Cloud WAN の場合、これらの静的ルートはコアネットワークポリシーで設定します。 より多くの AWS リージョンに拡張する際は、モダンなポリシー駆動型のグローバルネットワークを提供するAWS Cloud WAN を検討してください。これにより、手動での Transit Gateway ピアリングが不要になり、AWS リージョンと VPC 間の動的ルーティングが可能になります。 パターン 2: AWS PrivateLink を使用した Amazon EVS から AWS および非 AWS サービスへのプライベート接続 図 4: Amazon EVS VPC から AWS および非 AWS サービスへのプライベート接続 NSX オーバーレイセグメント上のワークロードが、インターネットを経由することなく、AWS サービス ( Amazon Simple Storage Service (Amazon S3) や Amazon DynamoDB など)、お客様が管理するサービス、またはサードパーティ ISV サービスをプライベートに利用する必要があるパターンです。 インターフェースエンドポイント : AWS サービスへの接続には、インターフェース VPC エンドポイントを使用します。インターフェースエンドポイントは、Amazon EVS VPC 内の非 Amazon EVS サブネットに配置するか、 Transit Gateway / AWS Cloud WAN 経由でアクセス可能な別の共有サービス VPC に配置 します。Amazon EVS オーバーレイから T0 を通じてエンドポイントへトラフィックをルーティングします。2026/3 時点では、S3 ゲートウェイエンドポイントは Amazon EVS でサポートされていません。Amazon EVS ワークロードからの Amazon S3 アクセスには、インターフェースエンドポイントを使用する必要があります。 プライベート DNS : VPC DNS 属性を有効にする必要があります。プライベート DNS でインターフェースエンドポイントを使用する場合は、スプリットホライズン DNS シナリオに対して適切な Route 53 Resolver 転送ルールを設定します。 サービスネットワークエンドポイントとリソースエンドポイント : サービス間またはリソース接続でゼロトラストな接続に VPC Lattice を使用したい場合は、サービスネットワークエンドポイントまたはリソースエンドポイントを使用できます。Lattice サービスネットワークエンドポイントとリソースエンドポイントは、T0 を通じて VPC への NSX オーバーレイネットワークからアクセスできます。2026/3 時点では、Lattice サービスネットワーク関連付けは Amazon EVS でサポートされておらず、接続にはエンドポイントの使用が必要です。 ベストプラクティス: Amazon EVS 専用の VPC Amazon EVS VPC は Amazon EVS リソース専用とすることを検討してください。共有サービスやその他の Amazon EVS 以外のワークロードは、Transit Gateway または AWS Cloud WAN を通じて接続された VPC に配置します。このアプローチにより、より明確な障害範囲の境界、より良いコスト配分とチャージバック、コンプライアンスとセキュリティ監査が提供されます。 セキュリティポリシーの適用 Amazon EVS におけるセキュリティには多層防御アプローチが必要で、複数のレイヤーでポリシーを適用します。 NSX Distributed Firewall (DFW) vDefend の DFW は、ハイパーバイザーカーネル内の VM のネットワークインターフェースに直接適用される L2 – L7 ファイアウォール機能を提供します。また、DFW はマイクロセグメンテーションを可能にし、以下のような機能を持っています。 NSX 論理セグメント間の East-West トラフィック制御 タグベースの動的セキュリティグループ vDefend を通じた IDS/IPS 機能や、アプリケーション対応フィルタリングなどのその他のセキュリティ機能 現在の VCF NSX ライセンスオプションについては、Broadcom VMware アカウントチームにご相談ください。 AWS セキュリティコントロール AWS セキュリティグループは Amazon EVS VLAN サブネット上の Amazon EVS ENI には適用されません。ただし、セキュリティグループを使用して、インターフェースエンドポイントや Amazon EVS 以外のサブネット内の他のワークロードへのトラフィックを制御できます。 Amazon EVS VLAN サブネット上でアンダーレイのアクセス制御においては Network ACL (NACL) を使用して、DNS, SSH, オンプレミスへのハイブリッド接続用の Hybrid Cloud Extension (HCX), VPC ルートサーバーピアリング用の BGP などのプロトコルのトラフィックを許可することができます。 以下の用途で、VPC の Ingress / Egress ポイントに AWS Network Firewall またはパートナーファイアウォールソリューション ( Gateway Load Balancer 経由) の導入を検討してください。 North-South トラフィックの検査・制御 Amazon EVS 環境に出入りするトラフィックの IDS/IPS URL フィルタリング, 脅威インテリジェンス, コンプライアンス・監査ログなどのセキュリティ機能 モニタリング VPC Flow logs などの AWS モニタリングサービスは、Amazon EVS ENI のアンダーレイトラフィックのみを確認でき、NSX オーバーレイトラフィックは確認できません。オーバーレイのモニタリングは、Aria operations for Networks、NSX Traceflow などの VMware ツールを使用してください。 考慮事項 NSX トランスポート MTU 設定が Amazon EC2/VPC アンダーレイ機能と一致していることを確認してください。現世代の EC2 インスタンスは最大 9001 バイトのジャンボフレームをサポートし、Transit Gateway は最大 8500 バイト、Direct Connect は Transit VIF で最大 8500 バイトをサポートします。NSX 内の MTU 制限を考慮してください。 NSX Edge T0 ゲートウェイは、サイズが不十分な場合にスループットのボトルネックになる可能性があります。NSX Edge データパスメトリクスを監視し、Edge のサイジングとチューニングに関する VMware のパフォーマンスガイダンスに従ってください。 Amazon EVS では、同一アベイラビリティーゾーン内でのレジリエンシーのために 2 つの VPC ルートサーバーエンドポイントが必要です。2 つの NSX Edge T0 ノードは Active/Standby モードで動作し、各エッジは 1 つの VPC ルートサーバーエンドポイントとピアリングします。 アクティブな T0 エッジがすべての North-South トラフィックを処理します。フェイルオーバー時間を監視し、障害シナリオをテストして、アプリケーションが Edge ノードフェイルオーバーイベントに対応できることを確認してください。 Amazon EVS は IPv4 のみをサポートします。執筆時点 (2026/3) では IPv6 は利用できません。 Amazon EVS は、ピアの生存確認にデフォルトの BGP キープアライブメカニズムをサポートします。Multi-hop Bidirectional Forwarding Detection (BFD) はサポートされていません。 作成時、VLAN サブネットは VPC のメインルートテーブルに暗黙的に関連付けられます。デプロイ後、Amazon EVS VLAN サブネットをカスタムルートテーブルに明示的に関連付けることができます。NSX 接続用にカスタムルートテーブルを作成することをお勧めします。 セキュリティグループは Amazon EVS ENI には適用されません。アンダーレイのアクセス制御には NACL を使用してください。Amazon EVS ワークロードにステートフルなセキュリティポリシーを提供するために、より多くの NSX セキュリティオプションを検討してください。 本稿の情報は、今後の Amazon EVS サービスのアップデートにより変更される可能性があります。 まとめ Amazon Elastic VMware Service (Amazon EVS) は、VMware Cloud Foundation スタックを VPC 内に直接配置し、AWS での VMware テクノロジーの制御と柔軟性を提供します。デプロイメントを成功させるには、事前に十分な計画を立て、適切なルーティングパターンを選択し、適切なレイヤーでセキュリティを実装してください。これらの原則に従うことで、VMware ワークロードを AWS インフラストラクチャ上で実行し、確立されたネットワーク、セキュリティ、運用パターンを適用し、モダナイゼーションとイノベーションのための幅広い AWS サービスを活用することができます。 著者について Victor Babasanmi Victor は AWS のシニアネットワークスペシャリストソリューションアーキテクトです。彼はベストプラクティスを使用したソリューションの計画と構築に関する技術的なガイダンスをお客様に提供し, AWS 環境を運用面で健全に保つことに積極的に取り組んでいます。仕事以外では、サッカーやワークアウト、新しいことに取り組んでいます。 Craig Herring Craig Herring は AWS でシニアスペシャリストソリューションアーキテクトを務めており、インフラストラクチャの移行とモダナイゼーションを専門としています。2021 年に入社して以来、Craig は 35 年にわたる豊富な業界経験を活かして、お客様が AWS ソリューションへの移行とその効果の最大化を支援しています。仕事以外では、Craig は妻の Lindy と 8 人の子供と 3 人の大家族との時間を大切にしています。個人的な興味は友人との交流、ドライブ、アクティブなライフスタイルの維持、オーディオ機器の製作など多岐にわたります。 翻訳はソリューションアーキテクト齋藤が担当しました。原文は こちら です。

はじめに 皆さんこんにちは、InsightEdgeのDataScientistのSugaです。最近は徒歩圏内にサウナが新しく出来たのでリフレッシュのため、そこにばっかりに通っています。 さて、今回は最近話題のブロードリスニングについての記事です。 「ブロードリスニング」とは、大量の意見データを AI で構造化・分析し、全体像を俯瞰する手法です。従来のアンケート分析やインタビューでは拾いきれない多様な声を、LLM（大規模言語モデル）とクラスタリング技術を組み合わせて一気に可視化します。 本記事では、 乾燥機付きドラム洗濯機 をサンプルテーマに取り上げ、以下の3ステップで分析を行いました。 意見（VOC）の生成とクラスタリング分析 — 1000件の消費者意見を AI で生成し、論点を抽出・クラスタリング ペルソナ推定とクラスタリング分析 — 各意見からペルソナを推定し、10タイプに分類 マーケティング検証 — 推定したペルソナに対してアンケート・購買判断・購入理由の分析を実施 使用技術 項目 技術 LLM Azure OpenAI GPT-5.2 Embedding text-embedding-3-large（3072次元） 次元削減 UMAP クラスタリング HDBSCAN + BERTopic + SpectralClustering / KMeans 日本語トークナイザ janome 可視化 matplotlib, Next.js（インタラクティブ散布図） 1. 意見（VOC）の生成とクラスタリング分析 1.1 意見データの生成 まず、分析対象となる消費者の意見データ（VOC: Voice of Customer）を用意します。今回は LLM を使って、乾燥機付きドラム洗濯機に関する 1000件の意見 を生成しました。 各意見は実際のクチコミに近い形で、購入動機・使い方・満足点・不満点などが含まれています。 例: 「共働きで小学生2人。体操服と給食エプロンを毎日乾燥まで回している。夜21時に予約して朝6時に取り出せるのが助かる。ただ、電気代が月3000円くらい上がった気がする。フィルター掃除は週1でやっているが面倒…」 1.2 論点の抽出 1000件の意見を直接クラスタリングするのではなく、まず各意見から 独立した論点 を抽出します。1つの意見には複数の論点（時短、電気代、騒音など）が含まれるためです。 GPT-5.2 で各意見から2〜5個の論点を抽出し、合計 5,447件の論点 を得ました。 1.3 クラスタリングの処理フロー 抽出した論点に対して、以下のパイプラインでクラスタリングを行います。 論点テキスト → text-embedding-3-large → 3072次元ベクトル → UMAP（2次元に削減） → HDBSCAN + BERTopic → SpectralClustering → ラベル付け → 要約 → 散布図レポート この結果、 15個の主要クラスタ に分類されました。 1.4 クラスタリング結果 ID ラベル #0 花粉雨雪でも外干し不要で臭い減少 #1 共働き育児介護で洗濯増え時短導入 #2 乾燥の電気代増と手入れ負担の不満 #3 乾燥フィルターと排水口の掃除負担と怠ると不調 #4 夜間中心に週3〜5回洗濯乾燥を回す習慣 #5 賃貸での搬入経路狭さと設置追加費用問題 #6 夜回して朝には乾く時短と段取り安定 #7 縦型や部屋干しで乾かず洗濯が回らない悩み #8 乾燥で衣類のシワ縮み傷みが気になる #9 夜間運転の騒音振動で近隣に気を遣う #10 来客前の寝具カバー類を即日洗乾燥できる便利さ #11 花粉アレルギーや部屋干し臭対策の導入理由 #12 洗剤自動投入と投入口のぬめり詰まり掃除負担 #13 ドアパッキンの水滴残りと臭い掃除負担 #14 夜間予約で毎日洗濯乾燥し朝完了運用 VOCクラスタリングの散布図 1.5 VOCクラスタリングからわかったこと 全体の傾向を一文でまとめると: 乾燥まで自動で完結し、雨雪・梅雨・花粉でも外干し不要で時短と快適さが高評価。共働き・育児介護や賃貸で夜回して朝仕上げる運用が定番。一方、電気代増や騒音振動、搬入設置の難しさが不満。さらにフィルター・排水口・パッキン等の掃除負担やシワ縮み対策など手入れ前提が目立つ。 クラスタリングの結果を大きく分類すると、以下の4つのテーマに整理できます。 満足・導入理由（#0, #1, #6, #7, #10, #11, #14） - 花粉・梅雨・雪でも外干し不要 → 生乾き臭からの解放 - 「夜回して朝に乾く」段取りの安定性 - 共働き・育児・介護で洗濯量が増えた家庭の時短ニーズ - 縦型や部屋干しから乗り換えた人の満足感が高い 不満・課題（#2, #3, #8, #9, #12, #13） - 乾燥の電気代増（月2000〜3000円の上昇感） - フィルター・排水口・ドアパッキンの定期清掃の手間 - 衣類のシワ・縮み・傷み - 夜間運転の騒音・振動（集合住宅での近隣配慮） 使い方の工夫（#4, #14） - 週3〜5回の高頻度運転が一般的 - タオル・寝具は乾燥まで、デリケート衣類は洗いのみと使い分け 設置の壁（#5） - 賃貸では搬入経路の狭さや設置追加費用が障壁 1.6 生成AIによる意見生成についての考察 今回は LLM を使って1000件の消費者意見を生成しました。この手法にはいくつかの論点があります。 なぜ実データではなく生成データを使ったのか 本記事の目的は「ブロードリスニングの分析手法を検証すること」であり、分析パイプラインの構築と検証が主眼です。実際のクチコミデータを使う場合、収集・クレンジング・匿名化などの前処理が必要になりますが、生成データであればすぐに分析パイプラインの検証に着手できます。 また、実データには偏りがつきものです。特定の ECサイトのレビューだけを集めると、そのサイトの購買層に偏った意見になります。LLM による生成では「こういう属性の人はどういう意見を持つか」というシナリオを幅広く網羅できるため、分析手法の検証には適しています。 生成データの限界 一方で、LLM が生成する意見には「きれいすぎる」という問題があります。実際のクチコミは文法が崩れていたり、複数の話題が混在していたり、感情的な表現が含まれていたりします。LLM 生成の意見はそれらに比べると整った文章になりがちで、論点抽出やクラスタリングが実データよりうまくいく可能性があります。 また、LLM の学習データに含まれる情報に基づいて生成されるため、学習データに存在しない新しいトレンドや、ニッチな使い方（例: 特定の地域特有の事情）は反映されにくい傾向があります。 実務での使い分け 実務では、以下のような使い分けが現実的です。 手法の検証・プロトタイピング : 生成データで分析パイプラインを構築・検証し、実データへの適用前にワークフローを固める 実データの補完 : 実データが少ないセグメント（例: 介護世帯やペット世帯）の意見を生成データで補い、クラスタの偏りを軽減する 仮説生成 : 「こういう層はこういう意見を持つのではないか」という仮説を生成し、実データで検証する 生成AIによる意見データは「答えそのもの」ではなく、「分析の出発点」として位置づけるのが適切です。 2. ペルソナ推定とクラスタリング分析 2.1 ペルソナ推定の考え方 VOCのクラスタリングでは「何が語られているか（論点）」を分析しました。次のステップでは、 「誰が語っているか（ペルソナ）」 に焦点を当てます。 各意見から、以下の4つの観点でペルソナを推定します。 購買価値観 — 何を重視して選ぶか 嗜好 — どんな製品・ブランドを好むか ライフスタイル — 日常の生活パターン ライフステージ — 家族構成・年代・住居形態 GPT-5.2 で1000件の意見それぞれから300〜500文字のペルソナテキストを生成し、同じパイプライン（embedding → UMAP → KMeans）で 10クラスタ に分類しました。 2.2 ペルソナクラスタリング結果 ID ラベル 件数 C0 退職後シニアの省力家事と外干し回避ニーズ 91 C1 単身若手の時短家事自動化ニーズ層 111 C2 夜間運転の静音性と花粉冬対策重視層 119 C3 ペットの毛対策と時短を求める30〜40代層 74 C4 花粉アレルギー対策で外干し回避する家庭 79 C5 賃貸集合住宅で夜回し時短と節約両立層 74 C6 子育て共働きの夜洗濯乾燥で朝支度時短層 142 C7 花粉外干し回避と夜洗乾の共働き層 115 C8 介護で増える汚れ物を夜間に洗乾完結したい層 78 C9 子育て期のひとり親多世代の時短洗乾燥需要層 117 2.3 各ペルソナクラスタの特徴 C0: 退職後シニア（91件） 40〜70代の退職後世帯（単身・夫婦）で、体力低下や外干しの負担から「洗い〜乾燥で完結」を求める実用派。ブランド信頼性を重視し、電気代や手入れ負担には敏感だが、乾燥は雨・冬・花粉期中心に使い分ける冷静な運用を行う。 C1: 単身若手（111件） 20〜40代の単身〜同棲前後の多忙層。干す手間やコインランドリー通い、部屋干しの生乾き臭を解消したい「時短・実用」志向が中心。集合住宅では騒音・振動への配慮が必要で、電気代増にも敏感。 C3: ペット同居世帯（74件） 犬猫などペットと暮らす30〜40代。毛がフィルターにまとまる点、部屋干しゼロ、朝までに乾く点に満足。ただし騒音/振動、パッキンの毛掃除などの手入れ負担に不満も。 C6: 子育て共働き（142件・最大クラスタ） 30〜40代の共働き・子育て世帯が中心で、洗濯量増と干し場不足から「夜回して朝完了」を狙う。雨・花粉のストレス解消と生活空間の整頓を評価するが、騒音・振動や電気代には敏感。 C8: 介護世帯（78件） 在宅介護を担う40〜60代中心。洗濯回数増・突発汚れ・天候不安から「干す工程を消して朝までに乾かす」時短と衛生を最優先。便利さは高評価だがコストとメンテ負荷に揺れる。 C9: 子育て期のひとり親・多世代（117件） 30〜40代の子育て世帯（共働き・ひとり親・三世代同居）。洗濯量増と時間不足から「夜に回して朝に乾いている」確実性と時短を最優先する。 2.4 ペルソナ分析からわかったこと VOCの論点クラスタリングでは「時短」「電気代」「騒音」といったテーマ別の分類でしたが、ペルソナクラスタリングによって 同じ「時短」でもライフステージによって意味が異なる ことが見えてきます。 C1（単身若手）の時短 = コインランドリー通いの代替。干す手間からの解放 C6（子育て共働き）の時短 = 夜に予約→朝回収の段取り。家事全体の最適化 C8（介護世帯）の時短 = 突発的な汚れ物への即応。衛生と時短の両立 C9（多世代子育て）の時短 = 大量洗濯物のまとめ処理。確実に朝までに乾く安心感 また、 C3（ペット層） や C4（花粉アレルギー層） のように、特定の生活課題がドラム洗濯機導入の強い動機になっているセグメントも明確になりました。 2.5 生成AIによるペルソナ推定の可能性 従来のペルソナ設計は、マーケターやリサーチャーが定性調査の結果をもとに手作業で行うものでした。「30代共働き夫婦」「単身社会人」といった典型像を数パターン作り、それをチーム内で共有するのが一般的です。この手法には、作成者の主観やバイアスが入りやすく、またペルソナの数が限られるという課題がありました。 LLM によるペルソナ推定が変えること 今回の手法では、1000件の意見それぞれに対して LLM がペルソナを推定しています。つまり、1000人分の個別ペルソナが存在し、それをクラスタリングすることで「データから浮かび上がるペルソナ像」を得ています。これは従来の「仮説としてのペルソナ」とは根本的に異なるアプローチです。 この手法の特徴は以下の通りです。 網羅性 : 人手では見落としがちなニッチセグメント（例: ペット世帯、介護世帯）が自動的に浮かび上がる 粒度の柔軟性 : クラスタ数を変えることで、粗い分類（5タイプ）から細かい分類（20タイプ）まで自在に調整できる 再現性 : 同じ入力データに対して同じパイプラインを実行すれば、類似の結果が得られる スケーラビリティ : 1000件でも10万件でも、処理時間は増えるが手法は同じ 従来手法との組み合わせ LLM によるペルソナ推定は、従来の定性調査を代替するものではなく、補完するものです。LLM が推定したペルソナクラスタを「仮説」として使い、その仮説を実際のインタビューやアンケートで検証するというワークフローが有効です。 例えば、今回の分析で「C3: ペットの毛対策」というクラスタが浮かび上がりました。従来のマーケティング調査では「ペット世帯」を独立したセグメントとして設計しない可能性がありますが、データからこのセグメントの存在が示唆されたことで、追加調査の方向性が明確になります。 応用の可能性 この手法は洗濯機に限らず、以下のような分野に応用できます。 商品開発 : 大量のユーザーフィードバックからペルソナを推定し、未充足ニーズを発見する コンテンツマーケティング : SNS上の投稿からペルソナを推定し、セグメント別のコンテンツ戦略を設計する カスタマーサポート : 問い合わせ内容からペルソナを推定し、FAQ やチャットボットの応答をセグメント別に最適化する 政策立案 : 市民の意見データからペルソナを推定し、政策の影響を受けるグループを事前に把握する ペルソナ推定の自動化により、「誰の声を聞いているのか」を構造的に理解できるようになります。これは意見データの分析精度を上げるだけでなく、施策の優先順位付けにも直結する重要な技術です。 3. マーケティング検証 ペルソナが推定できたので、次はそのペルソナを使って 具体的な製品に対するマーケティング検証 を行います。対象製品は 乾燥機付きドラム洗濯機 BD-STX130M （洗濯13kg/乾燥7kg）です。 (※特定の製品の方が説明がしやすかったので、製品を限定しましたが、本来の分析としてはどのような製品でも問題ありません) 主な特徴: - 乾燥フィルターレス + 3つの自動おそうじ（洗濯槽・乾燥経路・ドアパッキン） - ヒートポンプ式「らくはや 風アイロン」乾燥（洗濯〜乾燥7kg 約93分） - ナイアガラ循環2段シャワー（高濃度洗剤液で洗浄） - 省エネ効果: 消費電力約26%減、水量約24%減 3.1 アンケート分析（1000件） 1000件の各ペルソナに対して、洗濯機購入時に重視する10項目の重要度（1〜5のスケール）を LLM で回答させました。 アンケート項目と全体平均 # 項目 全体平均 Q1 本体価格の安さ（初期費用） 2.87 Q2 ランニングコストの低さ（電気代・水道代） 3.99 Q3 洗浄力（汚れ落ち） 4.33 Q4 乾燥の仕上がり（生乾き・シワの少なさ・ふんわり感） 4.77 Q5 洗濯〜乾燥までの所要時間（時短） 4.83 Q6 静音性・振動の少なさ 4.13 Q7 お手入れの楽さ（フィルター掃除・槽洗浄など） 4.16 Q8 容量（洗濯kg・乾燥kgの大きさ） 3.91 Q9 設置・使い勝手（サイズ・操作性など） 4.21 Q10 信頼性・サポート（故障しにくさ・ブランド安心感） 4.34 Q5（時短）が4.83で最も高く、Q1（本体価格）が2.87で最も低い という結果は、乾燥機付きドラム洗濯機のユーザーが「価格よりも機能・時短」を重視していることを示しています。 クラスタ別の特徴的な差異 クラスタ別 洗濯機購入価値観ヒートマップ まず前提として、Q4（乾燥の仕上がり）と Q5（時短）は 全クラスタで4.4〜4.9の高スコア です。これは乾燥機付きドラム洗濯機を検討する層に共通するニーズであり、クラスタ間での差が小さい項目です。 一方で、Q3（洗浄力）、Q8（容量）、Q10（信頼性）などはクラスタ間で0.5〜1.0以上の差があり、ペルソナごとの特性が反映されています。以下の表では、 他クラスタとの比較で特徴的な項目 を取り上げています。 クラスタ 他クラスタと比較して特徴的な傾向 C0（シニア） Q5（時短）が4.4で全クラスタ中最低 。退職後で時間に余裕があるため、時短への切迫感が薄い。一方 Q10（信頼性）は4.6 で、ブランド安心感を相対的に重視する C1（単身若手） Q8（容量）が3.4で全クラスタ中最低 。一人暮らしでは大容量は不要。また Q1（本体価格）が3.2で全クラスタ中最高 で、価格感度が最も高い C3（ペット層） Q3（洗浄力）が4.6で全クラスタ中トップタイ 。ペットの毛・汚れへの強いニーズ。また Q1（本体価格）が2.6で全クラスタ中最低 で、価格より機能を優先する傾向 C4（花粉アレルギー） Q4（乾燥の仕上がり）が4.9で全クラスタ中最高 。花粉対策として「確実に室内で乾く」仕上がり品質を最重視 C8（介護） Q10（信頼性）が4.8で全クラスタ中最高 。介護中の故障は致命的なため、信頼性・サポートを最重視。 Q3（洗浄力）も4.6でトップタイ C9（子育て期） Q8（容量）が4.5で全クラスタ中最高 。大家族のまとめ洗い需要が反映されている クラスタ別 洗濯機購入価値観アンケート（平均値） レーダーチャートを見ると、全クラスタで「Q4 乾燥の仕上がり」「Q5 時短」が突出して高い一方、「Q1 本体価格」だけが全体的に低いことがわかります。これは乾燥機付きドラム洗濯機のユーザーが、価格よりも機能性を重視する層であることを裏付けています。 注目すべきは、Q4・Q5 のような「共通して高い項目」ではなく、Q3・Q8・Q10 のような「クラスタ間で差が開く項目」です。これらの差分こそが、ペルソナごとに異なるニーズを示しており、マーケティング訴求を出し分ける根拠になります。 3.2 製品購買判断（1000件） 各ペルソナに対して、BD-STX130M の製品情報を提示し、「この製品を購入するか（Yes/No）」を判断させました。 BD-STX130M 購入判断（1000件集計） 全体結果: 購入する 719件（71.9%）、購入しない 281件（28.1%） クラスタ別 BD-STX130M 購入率 クラスタ別購入率 クラスタ ペルソナ 購入率 C9 子育て期のひとり親多世代の時短洗乾燥需要層 87% C3 ペットの毛対策と時短を求める30〜40代層 85% C8 介護で増える汚れ物を夜間に洗乾完結したい層 81% C2 夜間運転の静音性と花粉冬対策重視層 80% C6 子育て共働きの夜洗濯乾燥で朝支度時短層 78% C4 花粉アレルギー対策で外干し回避する家庭 68% C7 花粉外干し回避と夜洗乾の共働き層 65% C5 賃貸集合住宅で夜回し時短と節約両立層 64% C0 退職後シニアの省力家事と外干し回避ニーズ 59% C1 単身若手の時短家事自動化ニーズ層 50% 購入率が高いクラスタ（80%以上）の共通点: - 洗濯量が多い （子育て・介護・ペット） - 乾燥フィルターレスの価値を感じやすい （毛・汚れ・手入れ負担の軽減） - 13kg大容量が活きる 購入率が低いクラスタ（50〜64%）の共通点: - C1（単身若手）: 価格帯が高すぎる＆大容量がオーバースペック - C0（シニア）: 操作の複雑さやサイズへの不安 - C5（賃貸）: 設置スペースの制約 3.3 購入/非購入理由のクラスタリング（1000件） 購買判断の「理由」そのものもテキストデータとして価値があります。1000件のペルソナそれぞれについて購入/非購入の理由を LLM で生成し、その理由テキストを embedding → クラスタリングして 10個の理由クラスタ に分類しました。 理由クラスタはペルソナクラスタ（C0-C9）と区別するため、 R0-R9 と命名しています。 BD-STX130M 購入/非購入理由 クラスタ散布図 BD-STX130M 購入/非購入 散布図 散布図を見ると、右側に固まっている赤い点（非購入）のクラスタと、左側に広がる緑の点（購入）のクラスタがはっきり分離しています。 理由クラスタ一覧 理由クラスタ別 購入/非購入比率 ID ラベル 購入率 概要 R0 三世代の大量洗濯を大容量洗乾で時短 100% 三世代同居・共働きの大量洗濯に13kgが活きる R1 日立指名の信頼感で選ぶ時短省エネ乾燥 62% 日立ブランドで購入する層がいる一方、パナ/東芝指名で見送りも R2 花粉寒冷地の外干し回避で夜洗乾時短 100% 花粉・雪・梅雨で外干し不可。室内完結で解消 R3 夜回して朝乾く93分洗乾と手入れ軽減 100% 93分の時短＋フィルターレスで手入れも楽 R4 夜回し中心の時短洗乾と手入れルール化 99% 自動投入・通知で家事をルール化。振動は懸念 R5 高価格大容量で設置騒音不安の見送り 0% 非購入理由が集中。価格高・サイズ大・騒音不安 R6 大家族の大量洗濯を夜に洗乾で時短完結 100% 体操服・寝具のまとめ洗い。梅雨・花粉対策 R7 介護で毎日洗乾を時短完結し手入れも省力化 100% 介護の汚れ物に大容量＋自動おそうじが有効 R8 時短段取り化と省エネで洗乾ストレス軽減 100% 共働き・介護の段取り化。賃貸では設置・振動が懸念 R9 ペット毛とアレルギー対策の洗乾完結需要 99% ペット毛・花粉対策で室内完結。フィルターレスで集約 3.4 マーケティング検証からわかったこと BD-STX130Mの強み（購入理由の分析から） 「93分で洗乾完結」の時短訴求が最も刺さる （R3, R4）。夜回して朝に取り出す生活パターンと完全に合致 乾燥フィルターレスが差別化要因 （R3, R7, R9）。特にペット毛や介護の汚れ物で手入れ負担が減る点が高評価 13kg大容量が大家族・三世代に有効 （R0, R6）。体操服・寝具のまとめ洗いに対応 花粉・寒冷地対策として「確実に乾く」安心感 （R2）。外干し回避のニーズに合致 BD-STX130Mの課題（非購入理由の分析から） R5（購入率0%）に非購入理由が集中 : 本体価格が高い（上位機のため） 幅630×奥行720mm のサイズが賃貸に収まらない 夜間運転の騒音・振動の不安（スペック上の根拠が弱い） 単身・夫婦には13kgがオーバースペック R1（購入率62%）にブランド競合の影響 : パナソニック・東芝・シャープの指名買い層では決め手に欠ける 他ブランドの独自機能（除菌・空気ケアなど）との比較 ペルソナ×購買判断のクロス分析 アンケート結果と購買判断を重ねると、マーケティング施策のヒントが見えます。 ターゲット 購入率 施策の方向性 C9 子育て期（87%） 既に高い 「13kg大容量＋93分」の時短訴求を継続 C3 ペット層（85%） 既に高い 「フィルターレスで毛が集約」をペット向けに訴求 C1 単身若手（50%） 改善余地大 小容量モデルの展開 or コストパフォーマンス訴求 C0 シニア（59%） 改善余地あり 操作の簡便さ・ブランド信頼性の訴求 C5 賃貸（64%） 改善余地あり 設置サイズの明示・防振対策の訴求 3.5 推定ペルソナに対するアンケート調査のメリット 今回の分析では、LLM で推定した1000件のペルソナに対してアンケートや購買判断を「回答させる」という手法を用いました。この「AIペルソナへの調査」は、従来のアンケート調査とは異なるメリットを持っています。 従来のアンケート調査の課題 従来の消費者アンケートには、以下のような構造的な課題があります。 コスト : パネル調査やインタビュー調査には1件あたり数百円〜数千円のコストがかかる。1000件のアンケートを実施するだけで数十万円〜数百万円の費用が発生する 時間 : 調査設計・配信・回収・集計に数週間〜数か月を要する 回答バイアス : 「社会的に望ましい回答」をする傾向や、報酬目的の不誠実な回答が混入する セグメント不足 : 特定のニッチセグメント（介護世帯、ペット世帯など）の回答者を十分に集められない AIペルソナ調査のメリット 推定ペルソナに対する調査は、これらの課題を以下のように緩和します。 高速な仮説検証 : 調査設計からクラスタ別集計まで、数時間で完了する。「この訴求はどのセグメントに刺さるか」という仮説を即座にテストでき、アンケート項目や訴求文言の試行錯誤が容易になる セグメント別の深堀り : 1000件のペルソナがクラスタに分類されているため、「C3（ペット層）は洗浄力をどれだけ重視するか」といったセグメント別分析が自動的に得られる。従来の調査ではクロス集計のために追加のサンプル数が必要だった 製品コンセプトの事前スクリーニング : 実際の製品を消費者に提示する前に、AIペルソナに対して複数の製品コンセプトを評価させることで、有望なコンセプトを絞り込める。今回の BD-STX130M の購入率が50%〜87%とペルソナクラスタごとに大きく異なったことは、ターゲティングの精度を上げるための有力な示唆となった 非購入理由の構造化 : 従来の調査では「なぜ買わないか」を自由記述で聞いても、回答の質にばらつきがある。AIペルソナはペルソナの文脈に基づいた具体的な理由を生成するため、理由のクラスタリング（R0-R9）のような構造化分析が可能になる 注意点と限界 AIペルソナへの調査は、あくまで「LLM が推定した消費者像に基づくシミュレーション」であり、実際の消費者の回答とは異なる可能性があります。特に以下の点に注意が必要です。 LLM は学習データに含まれる消費者行動パターンをもとに回答を生成するため、新製品カテゴリや革新的な機能に対する反応は実態と乖離する可能性がある 価格感度やブランド選好は、地域・時期・経済状況によって変動するため、LLM の回答が現在の市場を正確に反映しているとは限らない 回答の分布が実際の消費者調査と一致するかどうかは、別途検証が必要である 実務での位置づけ AIペルソナ調査は、従来の消費者調査を「代替する」ものではなく、「準備段階で仮説を磨くためのツール」として位置づけるのが適切です。具体的なワークフローとしては以下が考えられます。 AIペルソナ調査で仮説を構築（どのセグメントに何を訴求するか） 仮説に基づいて本調査のアンケート設計を最適化（無駄な質問を減らし、深堀りすべきポイントを絞る） 本調査の結果とAIペルソナ調査の結果を比較し、AIペルソナの精度を検証・改善する このサイクルを回すことで、調査の精度と効率を同時に向上させることが可能になります。 4. まとめ 本記事では、ブロードリスニングとペルソナ推定分析を組み合わせて、乾燥機付きドラム洗濯機の消費者インサイトを3段階で深掘りしました。 Step 1: 意見のクラスタリング → 「何が語られているか」 1000件の意見から5,447件の論点を抽出し、15個のクラスタに分類。 時短・外干し不要の満足 と 電気代・騒音・手入れの不満 という二極構造が明確になりました。 Step 2: ペルソナのクラスタリング → 「誰が語っているか」 同じ意見をペルソナ視点で再分析し、10タイプのペルソナに分類。 同じ「時短」ニーズでも、単身若手・子育て共働き・介護世帯ではその意味と優先度が異なる ことが可視化されました。 Step 3: マーケティング検証 → 「どう製品を届けるか」 推定したペルソナに対してアンケート・購買判断・理由分析を実施。 全体の71.9%が購入意向を示す中、ペルソナごとに50%〜87%の幅 がありました。購入率の高いセグメント（子育て期・ペット層・介護世帯）への訴求強化と、低いセグメント（単身若手・賃貸）へのアプローチ改善という具体的な施策の方向性が得られました。 ブロードリスニングの手法を使えば、大量の消費者の声から 構造的なインサイト を効率的に抽出し、ペルソナ推定と組み合わせることで 誰に・何を・どう伝えるか というマーケティング戦略に直結する分析が可能になります。

この記事は、 Building a Credit Card Payment Processing Platform on AWS を翻訳したものです。 金融サービス業界（FSI）は大きな変革のただ中にあり、デジタル化が果たす重要な役割を考慮すると、電子決済はこの変革の中心的存在です。決済のキャッシュレス化が進展する中、業界がインクルージョン（包摂性）を促進する役割は重要な優先事項となっています。デジタル経済の革新と発展は、世界経済の安定した基盤として機能する決済によって支えられています。カード決済取引の裏側では多くの処理が行われており、クレジットカード処理の仕組みを明確に理解することは、企業が業務をより効果的に管理する上で役立ちます。本ブログ記事では、AWS上でクレジットカード決済処理プラットフォームを構築する方法を解説します。また、クレジットカード決済のオーソリゼーションにおけるアクワイアリング側とイシュアリング側の2つの高レベルなリファレンスアーキテクチャを紹介します。 ベネフィット 決済処理システムをクラウド上でモダナイズすることで、以下の目的が達成されます： 季節的な需要急増に対応するための迅速かつ効率的なスケーリング 高可用性を維持しつつ、年々増加するスループットをサポートし、厳格なセキュリティ要件に対応 データ居住要件や規制要件を遵守しながら市場へ展開し、グローバルビジネスを支援 新製品開発のための迅速なプロトタイピングを実現 クレジットカード決済処理では、金融機関が高可用性とスループットのSLAを満たすと同時に低遅延を実現する必要があります。 AWSは、 Amazon API Gateway 、 Amazon Managed Streaming for Apache Kafka (MSK) 、 Amazon DynamoDB などのツールとサービスを提供し、クラウド上で最新の分散型決済処理プラットフォームを構築し、毎秒数千件のトランザクションにスケールアップしたいお客様を支援します。AWSのお客様は、コンテナ化を強力な技術として活用し、アプリケーションの依存関係を持ち運び可能な方法で分離・管理することで、決済処理システムの可用性を大幅に向上させています。 組織が Amazon Elastic Kubernetes Service（EKS） を活用すると、需要やリソース可用性に応じてコンテナ化ワークロードのスケーリングと管理を自動化できます。また、AWSのネットワークセキュリティサービスと統合することで、さらに高い可用性と回復力を実現できます。さらに、自動化された監視・アラートツールをコンテナオーケストレーションプラットフォームと統合することで、決済処理システムの健全性とパフォーマンスをリアルタイムに可視化し、ユーザーに影響が出る前に先制的に問題へ対応することが可能になります。 AWSクラウドは、厳格なセキュリティ要件を満たすID管理を備えた、多層的なセキュリティを提供します。また、潜在的なセキュリティ設定ミス、脅威、または予期せぬ動作を特定するための脅威検知および対応サービスが利用可能です。AWSは、 Amazon Virtual Private Cloud（VPC） や AWS PrivateLink などの最新のネットワーク機能を提供し、メッセージがパブリックインターネットを経由せずに決済事業者間で通信することを可能にします。グローバルな顧客は、複数のAWSアベイラビリティゾーンおよびリージョンを使用して新規市場に拡大することができます。さらに、顧客は AWS Artifact のコンプライアンスレポートや認証、ベンダーデューデリジェンスメカニズムを活用し、AWSが責任を負う統制を理解・立証できます。また、AWSのサービスやリソースを活用して堅牢な統制環境を構築することで、現地市場におけるコンプライアンス要件への準拠を実証することが可能です。 開発者は、AWSのツールやサービスを活用することで、コンプライアンス、セキュリティ、インフラストラクチャ・アズ・コードの標準化と自動化を実現できます。また、技術プロダクトマネージャーは開発チームと連携して顧客と迅速にプロトタイプを作成し、新たなユースケースの解決に役立てます。AWS DevOpsは開発者が新機能を迅速にリリースできるようにし、運用チームがアプリケーションを本番環境に投入するまでの時間を短縮します。 AWS Config Rules 、 Service Catalog （ガバナンス・アズ・コード、セキュリティおよびIAMポリシー、バックアップ保持ポリシー、ロギング・モニタリングポリシー）、 CloudFormation Guard などのツールにより、中央管理チームは分散開発チームを容易に統制でき、コンプライアンスとクラウドのベストプラクティスを維持しながら迅速な開発を実現します。 クレジットカード決済処理の構成要素 クレジットカード決済は通常、3つの主要なステップで構成されるメッセージ取引として処理されます。最初のステップは取引の「オーソリゼーション（信用照会）」です。オーソリゼーションはリアルタイムで行われ、発行銀行に照会してカード所有者の口座に資金が存在することを確認します。また、発行銀行は取引を承認するか拒否するかの判断も提供します。第2のステップは取引の「決済」です。決済では、オーソリゼーション済み取引をまとめて発行銀行に送付し、照合が行われます。第3段階である「清算」では、資金を加盟店の銀行口座へ移動します。 次に、クレジットカード決済における主要なプレイヤーの概要を見ていきましょう。これにより、クレジットカード決済のバリューチェーンの一部を説明し、アクワイアラー処理と発行者処理のリファレンスアーキテクチャを提示します。 加盟店には、企業、起業家、個人事業主およびその間のあらゆるタイプの事業者が含まれます。加盟店が決済取引プロセスにおいて基盤的な役割を果たすのはカード決済受入ツールを活用するためです。具体的には、カード取引用のクレジットカード端末またはPOSシステム、決済ゲートウェイを備えた安全なe コマースウェブサイト、あるいは拡大を続けるアプリケーション群に統合された決済手段などがあります。 決済ゲートウェイは、決済ポータル（ウェブサイト、携帯電話、音声応答サービスなど）と決済処理業者（アクワイアラー）間の情報転送を通じて、決済取引を仲介します。 決済処理業者は、加盟店およびその取引銀行に代わってクレジットカード・デビットカード取引を処理する企業です。クレジットカードライフサイクルに関わるすべての関係者を結びつける決済処理業者は、単なる処理機能を超え、事業成長を支援する包括的な決済関連サービスを提供するように進化しています。 アクワイアラー（加盟店契約会社または加盟店管理会社）は、加盟店口座を開設・管理する機関です。加盟店口座とは、企業が電子決済カード取引を受け付け処理できるビジネス口座の一種です。クレジットカードやデビットカード決済を受け付けるすべての企業は、アクワイアラー銀行や独立系販売組織（ISO）などの機関を通じて加盟店口座を開設できます。また、決済代行業者などを通じて、サブ加盟店口座（別の企業が代わりに加盟店口座を提供する形態）を開設することも可能です。カード決済取引中、アクワイアラーまたはその処理業者は、加盟店とカードネットワーク間で取引リクエストと認証データをやり取りします。 カードネットワーク（ブランドネットワーク）は、顧客、加盟店、発行銀行、アクワイアラーを結びつけます。カードネットワークは、決済処理の統括機関として機能し、主要なカードネットワークには、アメリカン・エキスプレス、ディスカバー、マスターカード、銀聯（ユニオンペイ）、VISAなどがあります。カードネットワークはインターチェンジ料率を設定し、イシュアーとアクワイアラー間を仲介し、安全で迅速かつ効率的な決済を促進することに努めています。 イシュアー（カード発行銀行またはカード発行会社）は、クレジットカードを発行する機関であり、消費者を金融システムに接続して事業者への取引資金調達を促進するという、重要なサービスを提供しています。この資金調達プロセスは、事業者が存続し繁栄するための財務的な原動力となっています。 消費者（カード保有者）は、対面（カード提示）または非対面（カード非提示）の方法で支払い認証情報を提供し、カード取引を開始します。取引金額は金融機関に記録され、口座の種類に応じて貸方または借方として処理されます。カード決済取引のライフサイクルはさまざまな要因で変動しますが、オーソリゼーション・決済・清算という基本プロセスは固定されています。本稿ではカード取引ライフサイクルの第1段階である「オーソリゼーション」について、イシュアーとアクワイアラー双方のリファレンスアーキテクチャを用いて解説します。 オーソリゼーション クレジットカードライフサイクルの最初のステップはオーソリゼーションです。顧客は、対面または安全な通信を通じて加盟店に支払いカードの認証情報を提示します。カード提示取引の場合、カードの詳細情報は、カードチップの挿入、タッチ決済、カードのスワイプ、または手動でのカード入力などの方法を通じてPOS端末に伝達されます。物理的なPOS取引では、EMVカードまたはデジタルウォレットと端末間で通信する際に、アプリケーション識別子（AID）とカード所有者認証方法（CVM）が決定されます。カード非提示取引では、カード情報が加盟店プラグインや利用可能な決済ウォレットなどの複数のオプションを通じて提供されます。決済サービスプロバイダー（PSP）は、チェックアウト時にカード情報をトークン化する機能を提供し、加盟店によるカード認証情報の保存を防止します。カード情報は、適切な決済処理業者へルーティングするために、暗号化されて決済ゲートウェイに送信されます。決済処理業者はカードBIN（カード番号の最初の6 桁または8 桁）または口座情報を確認して、取引に適用すべきサービス（不正スコアリングやアカウント更新サービスなど）を決定します。アカウント更新サービスは、カード紛失・盗難時にカードライフサイクルにおける最新カード番号を非対面取引向けに提供するために利用されます。プロセッサーは決済スイッチと連携して取引をルーティングすべきカードネットワークを決定します。また、ネットワーク送信前に適切なメッセージ形式（ISO 8583、ISO 20022など）とレイアウトに変換する責任を負います。 Acquiring Processor Authorization Flow カードネットワークがネットワークメッセージを受信すると、必要に応じて支払い情報をデトークン化し、カードの種類・取引タイプ・支払いチャネルに応じて、不正利用のスコアリングや支出管理、データ変換、デジタル認証、その他の検証サービスといった関連する代行サービスを実行します。 Issuer Processor Authorization Flow カードネットワークは、発行銀行またはプロセッサーにメッセージを送信し、承認または拒否の応答を返す前に、リスク管理・カード制御・残高・チップ・住所・利用頻度・ポリシー・その他の必要なチェックを実行します。応答メッセージには承認の場合は「0-承認」などの理由コード、拒否の場合は「05-承認不可」または「62-制限付きカード」などの理由コードが提供されます。カードまたはトークンの種類および各取引のチャネルに応じて、カードネットワークまたは発行者はカード取引用に一意に生成される動的情報を検証します。 AWS におけるオーソリゼーションのためのリファレンスアーキテクチャ 以下のアーキテクチャ概要図は、AWS 上に構築されたオーソリゼーションシステムの主要コンポーネントと、異なるチャネルおよび各種スキーム間の通信モデルを示しています。 フローは、さまざまなチャネルが暗号化されたカード情報を、セキュアな通信回線を通じて Amazon API Gateway に送信するところから始まります。 AWS WAF を有効化することで、SQLインジェクションやクロスサイトスクリプティング（XSS）攻撃といった一般的なWeb攻撃からAPI Gateway APIを保護できます。API Gatewayは Amazon Cognito と統合されているため、許可されたユーザーのみがAPIにアクセスでき、リソースを不正アクセスから保護できます。 承認済み決済トランザクションは、ネットワークロードバランサー経由で Amazon Managed Streaming for Apache Kafka（MSK） に送信されます。PCIではカード所有者データの転送中と保存時における暗号化が義務付けられています。Amazon MSKはデフォルトでTLS 1.2を使用し、MSKクラスターのブローカー間で転送されるデータを暗号化するために、TLS 1.3の使用を推奨しています。 転送中のTLS暗号化（クライアント-ブローカー間、ブローカー間）、 TLSベースの証明書認証 、 SASL/SCRAM認証 は、 AWS Secrets Manager の支援によって実現できます。Kafkaトピック内のトランザクションは、AWS Fargateコンテナによってリアルタイムで消費されます。 AWS Fargate は Amazon ECS と組み合わせて使用できます。これにより、Amazon EC2インスタンスのサーバーやクラスターを管理せずにコンテナを実行できます。 Amazon ECR プライベートリポジトリを使用すれば、Amazon ECSタスクがプルするコンテナイメージやアーティファクトをホストできます。 コンテナはデータを決済用HSM（ハードウェア・セキュリティ・モジュール）に渡し、復号化されたデータを受け取ります。決済用HSMは、新たに提供が開始されたAWSのフルマネージド型決済HSMサービスである「 AWS Payment Cryptography 」を通じてプロビジョニングできます。また、 DynamoDBクライアントサイド暗号化ライブラリ を使用すれば、原文を暗号化して、その暗号テキストを暗号されているデータベースに保存できます。トークン応答は、内部アプリケーション操作のためにアプリケーションデータベースに保存されます。 Amazon ElastiCache for Redis 上のサブミリ秒レイテンシのインメモリデータキャッシュを使用することで、カードネットワークからのカード利用可能リクエストに即座に対応できます。トークン化された情報を、 AWS Step Functions を使用して様々なビジネスフローに適用すると、カードと取引タイプに基づくBINチェック、リスクチェック、アカウントチェック、不正検知チェック、その他の付加価値サービスを検証できます。検証後、応答はISO形式にフォーマットされ、消費のためにイグレスAmazon MSKに送信されます。複数のKafkaリスナーがカードネットワークに接続できます。 AWSにおけるイシュアーオーソリゼーションのリファレンスアーキテクチャー イシュアー処理フローにおいて、カードネットワークはソケット接続を介してペイロードを送信し、発行銀行またはプロセッサー（IBP）へオーソリゼーションリクエストを中継します。オンプレミスまたはコロケーション施設に設置された決済ネットワークインターフェースプロセッサー（PNIP）は、カードネットワークからのTCP/IPトラフィックを受信します。IBPは AWS Direct Connect を利用して内部ネットワークから標準イーサネット光ファイバーケーブル経由で、AWS Direct Connectロケーションに接続できます。AWS Direct Connectと AWS Transit Gateway の組み合わせは、複数のVPCとオンプレミスネットワークを接続するネットワークトランジットハブを構築するのを支援します。 オーソリゼーションリクエストのトラフィックは、AWS Transit Gateway経由でNetwork Load Balancerを介してトークナイゼーションVPCにルーティングされます。Network Load Balancerは接続レベル（レイヤー4）で動作し、IPプロトコルデータに基づいて顧客VPC内のターゲットコンテナへ接続をルーティングします。トークナイゼーションVPCは機密カード情報をトークン化します。カードデータに対する検証や確認といった暗号処理は、AWS Payment Cryptographyのようなスケーラブルで耐障害性の高いサービス上で実行する必要があります。情報は暗号化されたデータベースに保存されますが、データベースに依存せずAmazon ElastiCacheから取得することができます。 リクエストはオーソリゼーション決済処理VPCに転送され、さらに処理されます。オーソリゼーションコンテナは Amazon Elastic Kubernetes Service（EKS） と統合でき、アプリケーションをデプロイすることができます。 オーソリゼーションコンテナは、カード種別に基づくビジネス検証チェックのため、承認リクエストに追加情報を付加します。ビジネスプロセスワークフローエンジンは、カード種別に応じた不正検知・リスク・取引頻度・口座情報およびチップ・PIN・トークン・限度額・現金取引などのさまざまなポリシーに基づく複数のチェックを実行します。ビジネス検証応答は Amazon Managed Streaming for Apache Kafka (MSK) のトピックにストリーミングされます。オーソリゼーションコンテナが応答を処理して、 Amazon DynamoDB に情報を保存します。その後、IBPはオーソリゼーション応答（承認または拒否応答など）をカードネットワークに送信します。この応答は、アクワイアリングプロセッサーを経由して最終的に加盟店端末に戻ります。 決済事業者は、貴重な顧客データを保有しています。このデータは、 Amazon Comprehend を使用して、感情分析や商品レビュー分析といった顧客インサイト導出に活用できます。また、 Amazon Personalize を活用すれば、商品ランキングや特定商品の推奨、カスタマイズされたダイレクトマーケティングといった、リアルタイムなパーソナライズドレコメンデーションを実現できます。 まとめ クレジットカードは、店頭決済と非対面決済の両方において重要な決済手段であり続けています。キャッシュバックやカード特典、航空会社のポイントなどは、顧客がクレジットカードで支払う理由の一部でしかありません。2022年、米国の大手クレジットカード発行会社では、旅行・娯楽支出の増加に伴い、クレジットカードの利用が大幅に増加しました。また、クレジットカード分野では、デジタルファーストのクレジットソリューションによる革新も進んでいます。この革新により、顧客の申し込みが承認されるとすぐに仮想カードやトークンが利用可能になり、カード情報をデジタルウォレットに即座に追加できるようになります。 顧客はクレジットカード決済が数秒で処理されることを期待しています。本稿では、AWSのサービスを活用し、安全かつリアルタイムに処理でき、高い耐障害性を備え、ピーク時の決済量急増にも対応可能なクラウド決済処理ソリューションの構築方法について説明しました。また、クラウドベースの決済システムでは、AWSのツールとサービスを用いて PCI DSS に準拠した堅牢なセキュリティ対策を実現できます。フィンテック企業により、加盟店が自社ブランド（別名プライベートラベル）クレジットカードを容易に発行し、顧客セグメントの独自のニーズやライフスタイルに基づいた報酬をカスタマイズできるようになったことで、イノベーションはクレジットカード市場を活性化し続けています。 AWSとの連携方法や、世界中の決済顧客が決済処理を実行するのを当社がどのように支援しているかについての詳細は、AWSアカウントマネージャーにお問い合わせいただくか、 AWS Financial Services – Payments をご覧ください。 免責事項： 本投稿におけるリファレンスアーキテクチャに関する記述は、説明を目的とした参考情報であり、公開時点での情報に基づいています。記載の手順や推奨事項は教育目的および初期概念実証を意図したものであり、企業全体向けの完全なソリューションではありません。組織に適したアーキテクチャ設計についてはお問い合わせください。 本稿はソリューションアーキテクト畑が翻訳を担当しました。