本稿は、2026 年 10 月 2 日に公開された “ Architect highly available Oracle Database on Amazon EVS and FSx for ONTAP ” を翻訳したものです。 VMware Cloud Foundation (VCF) への既存投資がある企業は、アプリケーションの再設計や運用チームの再教育を行うことなく、Oracle データベースを AWS に移行したいと考えています。 Amazon Elastic VMware Service (Amazon EVS) 上の Oracle は、既存の VMware 運用ワークフローを維持しながら、サブミリ秒のストレージレイテンシー、スナップショットベースのバックアップ、クロスリージョンディザスタリカバリ (DR)、および独立したストレージスケーリングを活用できます。 この記事では、 Amazon FSx for NetApp ONTAP を使用して Amazon EVS 上に Oracle Database 環境を設計する方法を紹介します。使い慣れた VMware 運用ツールを維持しながら、ストレージ、コンピューティング、ネットワーキング、ディザスタリカバリの各レイヤーがどのように連携して高可用性、クロスリージョン DR、サブミリ秒のストレージレイテンシーを実現するかを学びます。 この記事では、以下の方法を学びます。 VMware Cloud Foundation 9.1 が稼働する Amazon EVS 上の Oracle Database アーキテクチャの設計 Oracle ワークロードに最適な EC2 ベアメタルインスタンスタイプと VM サイジングの選択 Oracle のデータボリュームおよびログボリューム用の NFS データストアとして FSx for ONTAP を使用したストレージの設計 クロスリージョン DR のための SnapMirror レプリケーション計画 既存の Oracle ワークロードをオンプレミスの VMware から Amazon EVS に移行するための移行オプションの評価 Amazon EVS は、 Amazon Virtual Private Cloud (Amazon VPC) 内の Amazon Elastic Compute Cloud (Amazon EC2) ベアメタルインスタンス上で VMware Cloud Foundation (VCF) 環境を直接実行します。VCF 9.x では、Amazon EVS がベアメタルインフラストラクチャと VLAN サブネットをプロビジョニングし、その後 Broadcom の VCF Installer を使用して VCF をデプロイします (セルフデプロイモデル)。VCF 9.x は評価モードもサポートしているため、ライセンスキーを適用する前に設計を検証でき、Solutions for Amazon EVS GitHub リポジトリでは段階的な VCF 9 デプロイメントを自動化する AWS CloudFormation および Terraform テンプレートが提供されています。FSx for ONTAP は、NFS、SMB、iSCSI、および NVMe over TCP アクセスを備えたマネージド ONTAP ストレージを提供します。FSx for ONTAP は、サブミリ秒の応答時間、数 GBps のスループット、およびファイルシステムあたり最大 80,000 IOPS を実現できます ( FSx for ONTAP のパフォーマンス を参照)。 詳細については、 FSx for ONTAP の機能 を参照してください。 プロビジョニング、ストレージ設定、Oracle のインストール、SnapMirror のセットアップを含むデプロイメント手順については、関連記事「 Amazon EVS と FSx for ONTAP における Oracle Database のデプロイステップ 」を参照してください。 ソリューションアーキテクチャ このセクションでは、2 つの AWS リージョンにまたがる Amazon FSx for ONTAP ストレージを使用した、Amazon EVS 上の高可用性 Oracle Database デプロイメントについて説明します。図 1 は、オンプレミスからハイブリッド接続を経由して本番 Amazon EVS 環境およびクロスリージョン DR に至るデータフローを示しています。 図 1: FSx for ONTAP とクロスリージョン SnapMirror DR を使用した Amazon EVS 上の Oracle Database このアーキテクチャは 8 つの機能コンポーネントで構成されており、次のセクションで説明します。 アーキテクチャコンポーネント 以下の項目は、図に示されたデータフローに対応しています。 ハイブリッドリンク — オンプレミスデータセンターは、 AWS Direct Connect を通じて AWS に接続し、低レイテンシーの専用帯域幅を確保します。 トランジットルーティング — AWS Transit Gateway が本番 VPC、DR リージョン、オンプレミスネットワーク間のトラフィックをルーティングします。 ワークロードランディング — トラフィックは、VCF 9.1 を搭載した i7i.metal-24xl Amazon EC2 ベアメタルインスタンス上で稼働する EVS データベースクラスターに到達します。 ライブマイグレーション — VMware HCX (Hybrid Cloud Extension) が、Replication Assisted vMotion または Bulk Migration を使用して、オンプレミスの VMware から Amazon EVS へ Oracle VM をほぼゼロダウンタイムで移行します。 NFS データパス — 各 ESXi ホストは FSx for ONTAP を NFS データストアとしてマウントします。Oracle VM は、データベースボリュームにブロックデバイス (NFS データストア上の VMDK) としてアクセスし、サブミリ秒のレイテンシーと最大 80,000 IOPS を実現します。各ホストは FSx for ONTAP への独立した NFS パスを持ち、クラスター全体で帯域幅を分散します。 クロスリージョン DR — SnapMirror が FSx for ONTAP ボリューム (データ、ログ、バイナリ) を、設定可能な目標復旧時点 (RPO) で DR リージョンに非同期でレプリケートします。 ダイナミックルーティング — NSX Tier-0 ゲートウェイが BGP を介して Amazon VPC Route Server とピアリングします。これは一方向の BGP です。Route Server は NSX によってアドバタイズされたルートをリッスンして VPC ルートテーブルに書き込みますが、VPC ルートを NSX に戻してアドバタイズすることはありません。 DR フェイルオーバー — フェイルオーバー時、Transit Gateway は DR リージョンにルーティングし、そこで事前にプロビジョニングされたスタンバイ Oracle VM が SnapMirror レプリカボリュームをマウントします。 Amazon EVS 上の Oracle Database デプロイメントで考慮すべき要素 デプロイメントを開始する前に、利用可能なインフラストラクチャオプションに対して Oracle ワークロードの要件を評価してください。インスタンスタイプ、VM サイジング、ストレージアーキテクチャについて行う決定は、データベースのパフォーマンス、コスト、運用の複雑さに直接影響します。 Oracle ライセンスに関する考慮事項: インスタンスタイプの選択は Oracle のライセンスコストに影響するため、考慮すべき重要な要素です。さらなるガイドラインについては、 AWS Optimization and Licensing Assessment (AWS OLA) のリクエストをお勧めします。 ESXi ホスト向けの EC2 インスタンスタイプの選択 Amazon EVS は現在、ESXi ホスト向けに 3 つのベアメタルインスタンスタイプをサポートしています。選択は、コアあたりのコンピューティング速度 (i7i) を優先するか、ホストあたりのメモリとストレージ密度 (i4i) を優先するか、また単一ホストを垂直方向にどの程度スケールしたいかによって異なります。ほとんどの新規 Oracle デプロイメントでは、Oracle のクエリパフォーマンスが CPU の命令スループットとストレージ IO レイテンシーに敏感であるため、i7i がより良い選択です。 i7i.metal-24xl (推奨デフォルト): 96 vCPU (48 コア)、768 GiB RAM。第 5 世代 Intel Xeon は改善されたコンピューティングパフォーマンスを提供します。第 3 世代 AWS Nitro SSD は、vSAN 向けに、強化されたリアルタイムストレージパフォーマンスと低い IO レイテンシーを提供します。 i7i.metal-48xl: 24xl と同じ第 5 世代 Intel Xeon ですが、ホストあたりの容量は 2 倍 (192 vCPU、96 コア、1,536 GiB RAM、最大 100 Gbps のネットワークおよび 60 Gbps の Amazon Elastic Block Store (Amazon EBS) 帯域幅)。大規模な SGA、高いコア数、または VMware のホストあたりライセンスを削減するためのより少なく高密度なホストなど、単一の Oracle ホストを垂直方向にスケールしたい場合に選択します。24xl と同じコアあたりのパフォーマンスプロファイルを維持します。 i4i.metal: より高いホストあたり密度 (128 vCPU、1,024 GiB RAM、30 TB NVMe) で、より少なく大きなホストを必要とする環境に適しています。 VCF 互換性: 3 つのインスタンスタイプすべてが ESXi 9.1 (ビルド 9.1.0.0100.25433460) を備えた VCF 9.1 をサポートします。VCF 5.2.2 (ESXi 8.0U3g) は引き続き利用可能ですが、サポート終了に向かっているため、新規デプロイメントはデフォルトで 9.x を使用すべきです。Amazon EVS 環境はクラスターあたり 4〜32 ホストをサポートします。同じ SDDC 内のクラスター間でインスタンスタイプを混在させることができます。 Oracle Database ゲスト向けの VM サイジング 以下のワークロード特性に基づいて Oracle Database VM をサイジングします。 Oracle の CPU_COUNT パラメーターに一致する vCPU 数を割り当てます。 SGA + PGA + OS オーバーヘッド向けにメモリをサイジングします (通常、割り当てられた VM メモリの 75〜85% を SGA に)。 VM スワップを vSAN データストア上に設定します (NFS ではない)。vSAN は 1 桁ミリ秒のレイテンシーを持つローカル NVMe を使用します。 単一ソケットのコア数を超える VM には NUMA 対応の VM 配置を使用します。 追加コストなしで 1 桁ミリ秒のレイテンシーを得るために、OS スワップと Oracle の一時表領域を vSAN データストア上に配置します。 ストレージアーキテクチャ: vSAN + FSx for ONTAP 推奨される設計では、ストレージの役割を 2 つの階層に分割します。 vSAN (各 ESXi ホスト上のローカル NVMe ドライブで構成) は、低レイテンシーで非レプリケーションのワークロードを処理します。 ( VM ブートディスク、OS スワップ、Oracle 一時表領域) FSx for ONTAP は、スナップショットベースのバックアップとクロスリージョンレプリケーションを必要とする Oracle データファイルと REDO ログを処理します。ESXi ホストは FSx for ONTAP ボリュームを NFS データストアとしてマウントし、Oracle VM はそれらのデータストア上の標準 VMDK にアクセスします。 この分離により、一時的な IO にはローカル NVMe の速度を提供しつつ、永続的なデータベースファイルにはスナップショット、クローン、SnapMirror の機能を追加できます。 なぜゲスト内 NFS (dNFS) ではなく NFS データストア (ホストレベル) なのか？ ゲスト内 NFS では、すべての Oracle NFS トラフィックが FSx for ONTAP に到達する前に NSX オーバーレイと NSX Edge ノードを経由します。これにより単一の Edge ボトルネックが生じます。NFS データストアでは、各 ESXi ホストが自身のネットワーク帯域幅を使用して FSx for ONTAP と直接 NFS で通信します。Edge ボトルネックも余分なレイテンシーホップもありません。 FSx for ONTAP のサイジングに関する考慮事項 重要: Oracle には 100% SSD を使用します。 Oracle データベースボリュームにはキャパシティプールの階層化を使用しないことをお勧めします。すべての Oracle ボリュームで階層化ポリシーを none に設定したままにしてください。 重要: SSD の容量を計画します。 SSD 階層が容量いっぱいになると、FSx for ONTAP は書き込みをブロックします。SSD 使用率を監視し、余裕 (最低 20% の空き) を確保してください。 重要: 読み取り/書き込みスループットは非対称です。 6 GB/s のファイルシステムでは、読み取りスループットは 6 GB/s に達することができますが、書き込みスループットは約 1 GB/s に制限されます。Oracle の書き込みワークロード要件に基づいてスループット容量をサイジングしてください。この書き込み上限は高可用性 (HA) ペアごとに適用されます。単一の HA ペアを超えて書き込みスループットをスケールするには、複数の HA ペアを持つファイルシステムをデプロイし、追加のアグリゲート全体に Oracle ボリュームを分散させて、書き込みがペア間で分散されるようにします。この配置は自動ではないため、書き込みの多いデータセットのバランスを保つために、事前にレイアウトを計画してください。 ネットワークアーキテクチャ Amazon EVS は、トラフィックをセグメント化するために VLAN サブネット (環境作成時に定義され、後から変更不可) を使用します。 VPC Route Server は、VPC 内の静的ルートを置き換えます。NSX Tier-0 ゲートウェイは BGP を介して Route Server エンドポイントとピアリングします。これは一方向の BGP です: Route Server は NSX からのルートをリッスンして VPC ルートテーブルに書き込みますが、VPC ルートを NSX に戻してアドバタイズすることはありません。VPC の外側では、Transit Gateway のルートは静的なままです。 Oracle 向けの NSX-T セグメンテーション 本番データベースセグメント (DB サブネット) 専用の Tier-1 ゲートウェイ。 アプリケーション層 (App サブネット) とペリメーターネットワーク用に別の Tier-1。 分散ファイアウォールルールが、Oracle リスナーアクセス (TCP 1521) を認可されたアプリケーションセグメントのみに制限。 Oracle インスタンス間のマイクロセグメンテーションが、ラテラルムーブメントを防止。 重要: セキュリティグループルールは VLAN サブネットインターフェイスでは適用されません。トラフィック制御にはネットワーク ACL と NSX 分散ファイアウォールを使用してください。 高可用性とディザスタリカバリ SnapMirror レプリケーションの頻度が RPO を決定します。ビジネス要件に基づいて設定します。 目標復旧時間 (RTO) を短縮するために、DR クラスターにスタンバイ Oracle VM を事前にプロビジョニングします。 復旧中に Oracle のインストールが不要になるように、バイナリボリュームをレプリケートします。 ヒューマンエラーを減らすために、Ansible/SnapCenter でフェイルオーバーを自動化します。 DR に関する Oracle ライセンスの考慮事項: DR レプリケーションの実装方法に基づいてライセンスへの影響があります。ライセンスに関する質問がある場合は、 AWS Optimization and Licensing Assessment (AWS OLA) のリクエストをお勧めします。 Oracle のライセンス規則に準拠するための代替案として、NetApp SnapMirror を通じて Oracle VM を本番環境から DR にレプリケートする方法があります。Oracle の二重ライセンスを回避するため、フェイルオーバーイベントが宣言されるまで、DR のレプリケートされたボリュームを DR ホスト上で NFS データストアとしてマウントせず、データ保護 (DP) ボリュームとして保持してください。フェイルオーバーイベントが宣言された時点ではじめて、SnapMirror を解除し、DR ホスト上で NFS データストアをマウントし、VM の電源を入れます。VM の電源が入っていなくても SnapMirror ボリュームをデータストアとして事前にマウントすることは、それらのホスト上で Oracle バイナリにアクセス可能になることを意味し、Oracle はこれを DR クラスター全体でライセンスを必要とする「インストール」とみなす可能性があります。 オンプレミス VMware から Amazon EVS へのデータベース移行 以下の表は、オンプレミス VMware から Amazon EVS への移行オプションを比較しています。 オプション 方法 最適な用途 ダウンタイム 1 VMware HCX ライブマイグレーション 既存のオンプレミス VMware ほぼゼロ (vMotion) または計画的な一括移行 2 SnapMirror ONTAP-to-ONTAP NetApp ONTAP 上のオンプレミス Oracle 数分 (最終同期の切り替え) 3 Oracle PDB リロケーション PDB/CDB マルチテナントモデル 短時間 (最終切り替えのみ) 4 RMAN バックアップ/リストア 非 ONTAP のオンプレミス (汎用) 数時間 (バックアップ + リストア + 適用) 各移行オプションの詳細な手順については、関連記事「 Oracle Database Deployment on Amazon EVS and FSx for ONTAP: Best Practices 」を参照してください。 セキュリティ Amazon EVS 上の Oracle のセキュリティは、ネットワーク分離からデータベースレベルの暗号化まで、複数のレイヤーにまたがります。以下の表は、各レイヤーのセキュリティコントロールをまとめたものです。 レイヤー コントロール ネットワークセグメンテーション NSX-T Tier-1 ゲートウェイが DB/App/ペリメーターのネットワークセグメントを分離 East-West トラフィック NSX 分散ファイアウォール : TCP 1521 を認可されたアプリケーションセグメントに制限 North-South トラフィック ingress/egress フィルタリング用の FortiGate または同等のインスペクション VPC 保管時の暗号化 AWS Key Management Service (AWS KMS) で暗号化された FSx for ONTAP ボリューム 転送時の暗号化 NFS トラフィック用の VPC 暗号化、および SnapMirror クロスリージョン用の IPsec データベース暗号化 追加の保護のための Oracle TDE (Transparent Data Encryption) 管理アクセス VMware 管理コンソール向けのゼロトラストアクセス (例: Banyan または Zscaler) VLAN サブネットセキュリティ ネットワーク ACL (VLAN インターフェイスではセキュリティグループは適用されない) コスト最適化 Amazon EVS 上の Oracle のコスト最適化は、インフラストラクチャ容量をワークロード需要に合わせることと、AWS の料金モデルを使用することに重点を置いています。以下の表は、コンピューティング、ストレージ、ネットワーキング、Oracle ライセンスにわたる主要な戦略をまとめたものです。さらなるガイドラインについては、 AWS Optimization and Licensing Assessment (AWS OLA) のリクエストをお勧めします。 コンポーネント 戦略 EC2 ベアメタルホスト Compute Savings Plans または リザーブドインスタンス (最大 54% の節約) インスタンスタイプの選択 i7i.metal-24xl は i4i.metal に対して価格性能が約 10% 向上 FSx for ONTAP のスループット 書き込みワークロードに合わせて適正なサイジングを行い、臨機応変に調整 FSx for ONTAP のストレージ Oracle には 100% SSD、非本番環境にはストレージ効率化 データ転送 FSx for ONTAP を EVS クラスターと同じ AZ に配置 SnapMirror レプリケーション RPO に基づいて頻度をスケジュール (頻度が低い = 低コスト) Oracle DR ライセンス NetApp SnapMirror を通じて Oracle VM を本番環境から DR にレプリケートし、Oracle の二重ライセンスを回避するため、フェイルオーバーイベントが宣言されるまで DR のレプリケートされたボリュームを DR ホスト上で NFS データストアとしてマウントせずデータ保護 (DP) ボリュームとして保持。フェイルオーバーイベントが宣言された時点で、SnapMirror を解除し、DR ホスト上で NFS データストアをマウントし、VM の電源を入れる。さらなるガイドラインについては AWS Optimization and Licensing Assessment (AWS OLA) のリクエストを推奨。 非本番環境 より少ないホストを使用し、開発/テストデータに階層化を適用 まとめ FSx for ONTAP を使用した Amazon EVS 上での Oracle データベースのデプロイメントは、VMware の運用一貫性と AWS クラウドの経済性を組み合わせながら、高可用性、クロスリージョン DR、サブミリ秒のストレージレイテンシーを提供します。 パフォーマンス: i7i.metal-24xl は最大 23% 優れたコンピューティングと 50% 低い IO レイテンシーを提供。FSx for ONTAP は最大 80,000 IOPS でサブミリ秒のレイテンシーを提供。詳細は AWS GovCloud (US) リージョンの Amazon EC2 i7i インスタンス を参照。 可用性: vSphere HA、SnapMirror クロスリージョンレプリケーション、およびオプションの Oracle Data Guard。 管理性: データベースサイズに関係なく数秒でバックアップ、クローン、復旧を行う SnapCenter。 移行の柔軟性: HCX (ライブ)、SnapMirror ( ONTAP-to-ONTAP )、PDB リロケーション (マルチテナント)、RMAN (汎用)。 セキュリティ: NSX マイクロセグメンテーション、AWS KMS 暗号化、ゼロトラストアクセス。 コスト効率: i7i による価格性能の向上、臨機応変なスループット調整、AWS Savings Plans。 このアーキテクチャは、使い慣れた VMware の運用ツールと手順を維持しながら、Oracle RAC や Data Guard の機能に類似した高可用性、クロスリージョン DR、ストレージベースのバックアップとクローンを提供します。 次のステップ このデプロイメントを始めるには: 対象リージョンに Amazon EVS 環境をプロビジョニングします。セットアップ手順については Amazon EVS ユーザーガイド を参照します。 EVS クラスターと同じ VPC およびアベイラビリティーゾーンに FSx for ONTAP ファイルシステムをデプロイします。 NFS データストアのマウント、Oracle VMDK の作成、SnapMirror DR の設定については、関連記事のステップバイステップ手順に従います。 まず非本番環境でテストし、その後本番の Oracle ワークロードを移行します。 その他のリソース Amazon EVS ユーザーガイド Amazon EVS がサポートする VCF バージョンとインスタンスタイプ Amazon EVS を使用した FSx for ONTAP Amazon EVS の料金 AWS News Blog での Amazon EVS の紹介 Amazon EVS と FSx for ONTAP における Oracle Database のデプロイステップ (関連記事) 著者について Satish Bhoi Satish Bhoi は AWS Enterprise Support のテクニカルアカウントマネージャーであり、お客様のクラウドソリューションの設計と最適化を支援しています。20 年以上の業界経験を持ち、クラウドアーキテクチャを専門とし、クラウドコンピューティングのアプリケーションを探求することに情熱を注いでいます。仕事以外では、Satish はリーグクリケットをプレイし、若い選手を指導し、旅行と冒険を楽しんでいます。 Ben Lipman Ben Lipman は、あらゆる規模の企業の仮想化、ストレージ、ネットワークを管理してきた 25 年にわたる IT インフラストラクチャエンジニアリングのバックグラウンドを持っています。過去 10 年間 AWS に在籍し、現在はワールドワイドの VMware テクニカルリーダーを務めています。 Sudhir Balasubramanian Sudhir Balasubramanian は AWS のシニア SA データベーススペシャリストであり、Oracle ACE、VMware vExpert、Nutanix NCP、スピーカー、ブロガー、著者、テクノロジスト、エバンジェリスト、パートナー＆カスタマーアドボケイトです。Sudhir は個人ウェブサイト vracdba.com で頻繁にブログを書いています。Sudhir は、お客様やパートナーと協力して、複雑な問題を解決しカスタマーエクスペリエンスを向上させる創造的なソリューションを構築することが大好きです。仕事以外では、Sudhir はハイキング、ウォーキング、料理、そしてクラシックロックとメタルを聴くことが好きです。 翻訳はソリューションアーキテクト 齋藤が担当しました。原文は こちら です。

本稿は、2026 年 10 月 2 日に公開された “ Deploy Oracle Database step by step on Amazon EVS with FSx for ONTAP ” を翻訳したものです。 この記事では、NFS データストアストレージとして Amazon FSx for NetApp ONTAP を使用して、 Amazon Elastic VMware Service (Amazon EVS) 上に Oracle Database をデプロイするためのステップバイステップの手順を紹介します。ストレージボリュームのプロビジョニング、NFS データストアのマウント、Oracle のインストール、そしてクロスリージョンディザスタリカバリのための SnapMirror レプリケーションの設定を行います。 VMware 上で Oracle データベースを稼働させている企業は、再設計や再教育を行うことなく既存の運用ワークフローを維持できる AWS への移行パスを求めています。関連記事「 Amazon EVS と FSx for ONTAP 上で高可用性の Oracle Database を設計する 」では、 Amazon Elastic Compute Cloud (Amazon EC2) ベアメタルインスタンスの選択、VM のサイジング、vSAN と FSx for ONTAP 間でのストレージの分割、クロスリージョン DR のための SnapMirror レプリケーションの計画など、環境を設計する方法を説明しました。 この記事は、アーキテクチャ編の続きです。Oracle VM のプロビジョニングと FSx for ONTAP ボリュームの作成から、NFS データストアのマウント、Oracle 19c のインストール、SnapMirror と SnapCenter の設定まで、スタック全体をデプロイするためのステップバイステップの手順を紹介します。また、既存のオンプレミス Oracle ワークロードを Amazon EVS に移行するための 4 つの移行パスと、スナップショットバックアップ、ポイントインタイムリカバリ、データベースクローニングを含む Day 2 運用についても説明します。 アーキテクチャの決定、インスタンスタイプの選択、ストレージ設計の根拠、高可用性の計画については、関連記事「 Amazon EVS と FSx for ONTAP 上で高可用性の Oracle Database を設計する 」を参照してください。 ステップバイステップのデプロイメント手順 このセクションでは、Oracle VM のプロビジョニング、FSx for ONTAP ストレージボリュームの作成、vSphere での NFS データストアのマウント、Oracle 19c のインストール、クロスリージョン DR のための SnapMirror の設定まで、エンドツーエンドのデプロイメントワークフローを説明します。まず前提条件を完了してから、ステップ 1 から 8 を順番に実行してください。 前提条件 Amazon EVS 環境がデプロイ済み (VCF 9.1、ESXi 9.1。VCF 9.x では、Amazon EVS がベアメタルインフラストラクチャと VLAN をプロビジョニングし、お客様が Broadcom の VCF Installer を使用して VCF をデプロイします)。 クラスターあたり最低 4 ホスト。Oracle には専用の DB クラスターを推奨。 Amazon VPC Route Server エンドポイント、 AWS Transit Gateway 、 AWS Direct Connect が設定された Amazon Virtual Private Cloud (Amazon VPC) 。 FSx for ONTAP プロビジョニングのための AWS Identity and Access Management (IAM) 権限。 VCF ライセンスエンタイトルメント (Broadcom からの BYOL)。 ステップ 1: Amazon EVS 上に Oracle VM をデプロイする Amazon EVS の vCenter に接続された vSphere Client にログインします。 本番 DB クラスターに新しい仮想マシンを作成します。 ゲスト OS: Red Hat Enterprise Linux 8 (64 ビット) または Oracle Linux 8 vCPU: Oracle ワークロードに応じてサイジング (一般的に 8〜32 vCPU) メモリ: SGA/PGA 要件に基づいて 32〜256 GiB ディスク: vSAN データストア上に 100 GiB (OS + Oracle Home + スワップ + 一時表領域) ネットワーク: prod-trusted Tier-1 ゲートウェイ上の DB セグメントに接続 VM の電源を入れ、ゲスト OS を設定します。 # ホスト名を設定 hostnamectl set-hostname ora-db1 # vSAN データストア上のディスクにスワップを作成 (ローカル NVMe、1 桁ミリ秒のレイテンシー) # vSAN データストアは VM のプライマリディスクとして既に利用可能 # スワップ用に専用のパーティションまたは LV を割り当て lvcreate -L 16G -n swap vgos mkswap /dev/vgos/swap swapon /dev/vgos/swap echo "/dev/vgos/swap swap swap defaults 0 0" >> /etc/fstab # Oracle の前提条件をインストール sudo yum install -y oracle-database-preinstall-19c python3 HA/DR については、DR クラスターに別途ライセンスを取得したインスタンスを維持するのではなく、Oracle VM 全体をレプリケートすることを検討してください (関連記事「 Amazon EVS と FSx for ONTAP 上で高可用性の Oracle Database を設計する 」の「DR に関する Oracle ライセンスの考慮事項」を参照)。 Oracle ライセンスに関する考慮事項: インスタンスタイプの選択は Oracle のライセンスコストに影響します。これは考慮すべき重要な要素です。さらなるガイドラインについては、 AWS Optimization and Licensing Assessment (AWS OLA) のリクエストをお勧めします。 ステップ 2: FSx for ONTAP をプロビジョニングする Amazon FSx コンソールを開き、 [ファイルシステムの作成] を選択し、 [Amazon FSx for NetApp ONTAP] を選択します。 [標準作成] を選択して設定します。 設定 値 デプロイメントタイプ シングルアベイラビリティーゾーン (AZ)。Amazon EVS では必須 SSD ストレージ容量 Oracle データ + ログ + 20% の余裕に合わせたサイズ スループット容量 512〜2,048 MB/s (書き込みワークロードに合わせたサイズ。非対称性の注記を参照) IOPS 自動 (3/GiB) またはユーザープロビジョニング (最大 80,000) VPC Amazon EVS 環境と同じ VPC サブネット Amazon EVS サービスアクセスサブネット、DB クラスターと同じ AZ セキュリティグループ Amazon EVS マネジメント VLAN からの NFS (TCP 2049、111、635) を許可 fsxadmin パスワードを設定します (ONTAP CLI 自動化に必須)。 vsadmin パスワードで SVM (Storage Virtual Machine) を作成します。 自動日次バックアップを無効にします。代わりに Oracle 対応のスケジューリングには SnapCenter を使用します。 作成後、[SVM] を選択し、[エンドポイント] を選択して、NFS DNS 名をコピーします。 ステップ 3: Oracle データベースボリュームを作成する SSH ( ssh fsxadmin@management-endpoint ) を使用して FSx for ONTAP クラスターに接続し、ボリュームを作成します。 # Oracle バイナリボリューム vol create -volume oradb1bin -aggregate aggr1 -size 50G \ -state online -policy default -tiering-policy none \ -junction-path /oradb1bin # Oracle データボリューム vol create -volume oradb1data -aggregate aggr1 -size 500G \ -state online -policy default -tiering-policy none \ -junction-path /oradb1data # Oracle ログボリューム (REDO + アーカイブ) vol create -volume oradb1log -aggregate aggr1 -size 250G \ -state online -policy default -tiering-policy none \ -junction-path /oradb1log すべてのデータを SSD 階層に固定するために -tiering-policy none を設定します。ログボリュームは 24 時間分のアーカイブログに合わせてサイジングします。 ステップ 4: vSphere で FSx for ONTAP を NFS データストアとしてマウントする vSphere Client で、[DB クラスター] を選択し、[設定] > [ストレージ] > [新しいデータストア] を選択します。 [NFS] を選択し、[NFS 3] を選択します。 以下を入力します。 サーバー: svm-id.fs-id.fsx.region.amazonaws.com フォルダー: /oradb1data データストア名: fsx-ora-db1-data バイナリ ( /oradb1bin ) およびログ ( /oradb1log ) ボリュームについても繰り返します。 3 つすべてのデータストアがクラスターストレージビューで正しい容量を表示していることを確認します。 ステップ 5: FSx for ONTAP データストア上に Oracle VMDK を作成する NFS データストアを ESXi ホストレベルでマウントした状態で (ステップ 4)、これらのデータストア上に Oracle 用の仮想ディスクを作成します。 vSphere Client で、Oracle VM を選択し、[設定の編集] を選択してから、[新しいデバイスを追加] > [ハードディスク] を選択します。 以下の VMDK を作成します。 VMDK データストア サイズ ゲストマウント 用途 Hard Disk 2 fsx-ora-db1-data 500 GiB /u02 Oracle データファイル Hard Disk 3 fsx-ora-db1-log 250 GiB /u03 Oracle REDO + アーカイブログ Hard Disk 4 fsx-ora-db1-bin 50 GiB /u01 Oracle Home バイナリ データおよびログ VMDK には Thick Provision, Eager Zeroed を選択します (Oracle でベストなパフォーマンスを得るため)。 Oracle Database は Oracle ASM またはファイルシステム (ローカル/NFS) 上に作成できます。この手順では、ローカル XFS ファイルシステム上に Oracle データベースを作成します。 Oracle VM ゲスト OS 内で、新しいディスクをパーティション分割してマウントします。 # 新しいディスクを識別 lsblk # 各ディスクにファイルシステムを作成 (例: データ用に /dev/sdb) mkfs.xfs /dev/sdb mkfs.xfs /dev/sdc mkfs.xfs /dev/sdd # マウントポイントを作成 mkdir -p /u01 /u02 /u03 # マウント mount /dev/sdd /u01 # Oracle Home (バイナリ) mount /dev/sdb /u02 # Oracle データファイル mount /dev/sdc /u03 # Oracle REDO + アーカイブログ # /etc/fstab に永続化 cat >> /etc/fstab <<EOF /dev/sdb /u02 xfs defaults,noatime 0 0 /dev/sdc /u03 xfs defaults,noatime 0 0 /dev/sdd /u01 xfs defaults,noatime 0 0 EOF # 所有権を設定 chown -R oracle:oinstall /u01 /u02 /u03 重要なポイント: Oracle VM は /u02 と /u03 にローカル XFS ブロックデバイスとしてアクセスします。基盤となるストレージが FSx for ONTAP 上の NFS データストアであることを認識していません。すべての NFS 通信は ESXi ホストレベルで行われ、各ホストは FSx for ONTAP へ個別のネットワークパスを使用します。 ステップ 6: Oracle 19c をインストールして設定する # oracle ユーザーとして export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1 cd $ORACLE_HOME ./runInstaller -silent -responseFile /path/to/db_install.rsp データを /u02 に、ログを /u03 に配置してデータベースを作成します。 CREATE DATABASE orcl DATAFILE '/u02/oradata/orcl/system01.dbf' SIZE 1G LOGFILE GROUP 1 '/u03/oralogs/orcl/redo01.log' SIZE 512M, GROUP 2 '/u03/oralogs/orcl/redo02.log' SIZE 512M, GROUP 3 '/u03/oralogs/orcl/redo03.log' SIZE 512M; Oracle は /u02 と /u03 にローカル XFS ファイルシステムとしてアクセスします。標準の Oracle ASM またはファイルシステムベースのストレージ管理が適用されます。NFS レイヤーは ESXi ハイパーバイザーによって抽象化されているため、NFS 固有の Oracle 設定は必要ありません。 ステップ 7: クロスリージョン DR のために SnapMirror をセットアップする クラスターをピアリングします (本番 → DR)。 cluster peer create -peer-addrs <dr-cluster-intercluster-ip> \ -username fsxadmin -initial-allowed-vserver-peers * SVM をピアリングします。 vserver peer create -vserver svm-prod -peer-vserver svm-dr \ -peer-cluster FSxDR -applications snapmirror DR 側の FSx for ONTAP 上に DP ボリュームを作成します。 vol create -volume oradb1bin -aggregate aggr1 -size 50G -state online -type DP vol create -volume oradb1data -aggregate aggr1 -size 500G -state online -type DP vol create -volume oradb1log -aggregate aggr1 -size 250G -state online -type DP SnapMirror を作成して初期化します。 snapmirror create -source-path svm-prod:oradb1data \ -destination-path svm-dr:oradb1data -throttle unlimited \ -policy MirrorAllSnapshots -type DP snapmirror create -source-path svm-prod:oradb1log \ -destination-path svm-dr:oradb1log -throttle unlimited \ -policy MirrorAllSnapshots -type DP snapmirror create -source-path svm-prod:oradb1bin \ -destination-path svm-dr:oradb1bin -throttle unlimited \ -policy MirrorAllSnapshots -type DP # 初期化 snapmirror initialize -destination-path svm-dr:oradb1data snapmirror initialize -destination-path svm-dr:oradb1log snapmirror initialize -destination-path svm-dr:oradb1bin 重要: DR 戦略を計画する際は、Oracle のライセンス要件を考慮してください。代替案として、NetApp SnapMirror を通じて Oracle VM を本番環境から DR にレプリケートする方法があります。Oracle の二重ライセンスを回避するため、フェイルオーバーイベントが宣言されるまで、DR のレプリケートされたボリュームを DR ホスト上で NFS データストアとしてマウントせず、データ保護 (DP) ボリュームとして保持してください。その時点ではじめて、SnapMirror を解除し、DR ホスト上で NFS データストアをマウントし、VM の電源を入れます。SnapMirror ボリュームを (VM の電源が入っていなくても) データストアとして事前にマウントすることは、それらのホスト上で Oracle バイナリがアクセス可能になることを意味し、Oracle はこれを DR クラスター全体でライセンスを必要とする「インストール」とみなす可能性があります。さらなるガイドラインについては、 AWS Optimization and Licensing Assessment (AWS OLA) のリクエストをお勧めします。 ステップ 8: SnapCenter バックアップを設定する SnapCenter Server をデプロイします (または SnapCenter SaaS を使用)。 クラスター管理 IP を使用して FSx for ONTAP ストレージシステムを追加します。 各 Oracle VM に SnapCenter Plugin for Oracle をインストールします。 バックアップポリシーを作成します。 ポリシー スコープ 頻度 SnapMirror 更新 フル DB バックアップ データ + 制御ファイル + アーカイブログ 4〜6 時間ごと はい アーカイブログ アーカイブログのみ 10〜15 分ごと はい リソースグループを作成し、ポリシーを割り当て、スケジュールを設定します。 オンプレミス VMware から Amazon EVS へのデータベース移行 オプション 1: VMware HCX ライブマイグレーション 既存のオンプレミス VMware を持つ企業向け: オンプレミスに HCX Connector を、Amazon EVS に HCX Cloud Manager をデプロイします。 サイトペアリングとネットワーク拡張 (L2 ストレッチ) を作成します。 HCX vMotion (ゼロダウンタイム) または Bulk Migration を使用して Oracle VM を移行します。 移行後: スナップショット/レプリケーション機能のために、Oracle VMDK を vSAN から FSx for ONTAP NFS データストアへストレージ vMotion します。 オプション 2: SnapMirror ONTAP-to-ONTAP オンプレミスの Oracle が既に NetApp ONTAP ストレージを使用している場合: オンプレミス ONTAP と FSx for ONTAP 間で SnapMirror を確立します。 切り替えまで増分でレプリケートします。 切り替え時: Oracle を休止し、アーカイブログをフラッシュし、最終 SnapMirror 同期を行い、ミラーを解除します。 Amazon EVS 上の Oracle VM に FSx for ONTAP ボリュームをマウントし、データベースをリカバリし、サービスを開始します。 オプション 3: Oracle PDB リロケーション (マルチテナント) Oracle データベースが既に PDB/CDB マルチテナントモデルにある場合: FSx for ONTAP ストレージを使用して Amazon EVS 上にターゲット CDB を作成します。 PDB ホットクローンを使用して、オンプレミス CDB から AWS 上の CDB へ PDB をリロケートします。 サービス中断は最小限です。最終切り替えのみ短時間の停止が必要です。 オプション 4: RMAN バックアップ/リストア (非 ONTAP オンプレミス) Oracle がオンプレミスで非 ONTAP ストレージ上で稼働している場合: RMAN バックアップを作成し、 AWS DataSync または AWS Direct Connect を使用して Amazon Simple Storage Service (Amazon S3) に一時保管します。 Amazon EVS 上に Oracle VM をプロビジョニングし、FSx for ONTAP ボリュームをマウントします。 RMAN バックアップからリストアし、アーカイブログを適用します。 データベースを開始し、アプリケーションをリダイレクトします。 Day 2 運用 スナップショットバックアップ SnapCenter は、フルデータベーススナップショットをストレージレイヤーの操作として管理し、効率的なバックアップ機能を提供します。 ポイントインタイムリカバリ SnapCenter で、SCN またはタイムスタンプを選択し、ログスナップショットをマウントし、データスナップショットをリストアし、アーカイブログを適用し、RESETLOGS で開きます。 データベースクローニング SnapCenter FlexClone は、スペース効率の良いデータベースコピーを作成します。クローンは変更されていないブロックをソースと共有し、差分に対してのみストレージを消費します。開発/テスト、パッチ検証、レポーティングに使用します。 HA フェイルオーバー手順 DR ボリューム上の SnapMirror を解除します。 SnapMirror ボリュームを DR ESXi ホスト上に NFS データストアとしてマウントし、Oracle VM の電源を入れます。 利用可能な最後のアーカイブログまでリカバリします。 データベースを開きます。DNS/接続先を更新します。 クリーンアップ このデプロイメントのテスト後に料金が発生しないようにするには、以下のリソースをこの順序で削除します。 Oracle VM — Oracle データベース VM を停止し、vSphere インベントリから削除します。 NFS データストア — vSphere で ESXi ホストから FSx for ONTAP データストアをアンマウントします。 SnapMirror 関係 — DR 側の FSx for ONTAP ファイルシステム上の SnapMirror 関係と DP ボリュームを削除します。 FSx for ONTAP ファイルシステム — Amazon FSx コンソールから本番および DR の両方のファイルシステムを削除します。この操作により、それらのファイルシステム上のすべてのボリュームとデータが削除されます。 Amazon EVS 環境 — Amazon EVS コンソールから Amazon EVS 環境を削除します。これにより、基盤となる EC2 ベアメタルインスタンスが終了します。 ネットワーキング — このデプロイメントのためだけに作成された場合は、Transit Gateway アタッチメント、VPC Route Server 設定、Direct Connect 接続を削除します。 重要: FSx for ONTAP ファイルシステムを削除すると、すべてのデータが完全に削除されます。続行する前に、必要なデータをバックアップ済みであることを確認してください。 まとめ この記事では、NFS データストアストレージとして FSx for ONTAP を使用して、Amazon Elastic VMware Service (Amazon EVS) 上に Oracle Database をデプロイする手順を説明しました。Oracle VM をプロビジョニングし、FSx for ONTAP ボリュームを作成し、vSphere で NFS データストアをマウントし、Oracle 19c をインストールし、クロスリージョンディザスタリカバリのための SnapMirror と Oracle 対応バックアップのための SnapCenter を設定しました。また、既存のオンプレミス Oracle ワークロードのための 4 つの移行パスと、バックアップ、ポイントインタイムリカバリ、クローニングのための Day 2 運用についても説明しました。 始めるには、 Amazon EVS ユーザーガイド と「 FSx for ONTAP で Amazon Elastic VMware Service を使用します 」を確認してから、Amazon EVS 上に最初の Oracle VM をデプロイしてください。このデプロイメントの背後にあるアーキテクチャの決定については、関連記事「 Amazon EVS と FSx for ONTAP 上で高可用性の Oracle Database を設計する 」を参照してください。フィードバックやご質問はコメント欄でお寄せください。 その他のリソース Amazon EVS ユーザーガイド Amazon EVS がサポートする VCF バージョンとインスタンスタイプ FSx for ONTAP で Amazon Elastic VMware Service を使用します Amazon EVS の料金 Amazon EVS の紹介 — AWS Blog 著者について Satish Bhoi Satish Bhoi は AWS Enterprise Support のテクニカルアカウントマネージャーであり、お客様のクラウドソリューションの設計と最適化を支援しています。20 年以上の業界経験を持ち、クラウドアーキテクチャを専門とし、クラウドコンピューティングのアプリケーションを探求することに情熱を注いでいます。仕事以外では、Satish はリーグクリケットをプレイし、若い選手を指導し、旅行と冒険を楽しんでいます。 Ben Lipman Ben Lipman は、あらゆる規模の企業の仮想化、ストレージ、ネットワークを管理してきた 25 年にわたる IT インフラストラクチャエンジニアリングのバックグラウンドを持っています。過去 10 年間 AWS に在籍し、現在はワールドワイドの VMware テクニカルリーダーを務めています。 Sudhir Balasubramanian Sudhir Balasubramanian は AWS のシニア SA データベーススペシャリストであり、Oracle ACE、VMware vExpert、Nutanix NCP、スピーカー、ブロガー、著者、テクノロジスト、エバンジェリスト、パートナー＆カスタマーアドボケイトです。Sudhir は個人ウェブサイト vracdba.com で頻繁にブログを書いています。Sudhir は、お客様やパートナーと協力して、複雑な問題を解決しカスタマーエクスペリエンスを向上させる創造的なソリューションを構築することが大好きです。仕事以外では、Sudhir はハイキング、ウォーキング、料理、そしてクラシックロックとメタルを聴くことが好きです。 翻訳はソリューションアーキテクト 齋藤が担当しました。原文は こちら です。

本記事は 2026 年 6 月 29 日 に公開された「 Implementing Responsible AI in Contact Centers with Connect AI Agents Guardrails 」を翻訳したものです。 コンタクトセンターへの AI の導入は、カスタマーサービスに大きな変革をもたらしました。応答時間の短縮、サポート品質の均一化、エージェントの生産性向上などが実現しています。一方でこの変革には、AI システムが安全かつ倫理的に、規制要件に準拠して動作する責任も伴います。 Amazon Connect Customer の AI ガードレールは、コンタクトセンターにおける責任ある AI 導入を大きく前進させます。Amazon Connect Customer のネイティブ機能として提供され、AI を活用した顧客対応が安全でコンプライアンスに準拠し、組織の価値に沿ったものにするよう、エンタープライズグレードの保護メカニズムを備えています。パフォーマンスや顧客体験を犠牲にすることもありません。 従来のソリューションとの違い 複雑さやレイテンシーを増加させる後付けのソリューションとは異なり、AI ガードレールはプラットフォームのコアに組み込まれており、パフォーマンスや顧客体験を損なうことなくリアルタイムの保護を実現します。 本記事では、Amazon Connect Customer の AI ガードレールを活用した責任ある AI の実装について包括的に解説し、各コンポーネントの詳細、実装ガイダンス、実際の導入効果を紹介します。Amazon Connect Customer のネイティブ機能により、優れたカスタマーサービスの基盤となる人間中心のアプローチを維持しながら、倫理的な AI 導入を実現する方法を見ていきましょう。 AWS の責任ある AI フレームワーク AWS では、AI システムの開発と導入の指針となる 8 つの基本的な側面で責任ある AI を定義しています。 公平性: 顧客の属性、コミュニケーションスタイル、背景に関係なく、AI が全ての顧客を公平に扱うこと。 説明可能性: AI が特定の判断や推奨を行う理由と仕組みを明確に理解できること。 プライバシーとセキュリティ: 堅牢な暗号化、アクセス制御、データ最小化の実践により顧客データを保護すること。 安全性: 包括的なガードレールにより、有害なシステム出力を削減し、悪用を防止すること。 制御性: AI システムの動作をリアルタイムで監視・制御するメカニズムを維持すること。 正確性と堅牢性: 予期しない入力や敵対的な入力に対しても、正確で信頼性の高い出力を実現すること。 ガバナンス: 明確な責任体制のもと、AI サプライチェーン全体にベストプラクティスを組み込むこと。 透明性: ステークホルダーが AI システムとの関わり方について十分な情報に基づいた選択をできるようにすること。 AI ガードレールはこれら全ての原則を体現し、本番環境のコンタクトセンターにおける責任ある AI の実践的な実装を提供します。 Amazon Connect における責任ある AI の基盤 技術的な機能の詳細に入る前に、コンタクトセンターにおける責任ある AI の基本原則とAI ガードレールの関係を理解しておきましょう。 Amazon Connect における責任ある AI の原則 AI ガードレールは、カスタマーサービスにおいて AI が人間の判断を置き換えるのではなく強化することを確実にする、5 つの基本原則に大きく分類できます。 1. コンタクトセンターにおける人間中心の AI Amazon Connect は、エージェント支援型とセルフサービス型の両方の顧客対応をサポートしています。AI ガードレールは全てのインタラクションモデルで責任ある AI の導入を実現します。 エージェント支援型のインタラクション向け: 人間による監視の維持: エージェントが顧客対応の最終的な制御権を維持 人間の能力の強化: AI がインテリジェントな補助を提供しつつ、最終判断は人間が実施 透明性のある AI の動作: ガードレールがいつ、なぜ発動するかをエージェントが把握 シームレスなエスカレーション: AI の対応範囲を超えた場合は、人間の専門家へのスムーズな引き継ぎ セルフサービス型のインタラクション向け: 責任ある自動化: 人間の監視がなくても、AI が定められた倫理的な範囲内で動作 インテリジェントなエスカレーション: 人間の判断が必要な状況では自動的にエージェントへルーティング 制限事項の透明性: 顧客に AI の能力と制限について明確に説明 フォールバック保護: 複雑なシナリオでも適切な応答を保証する堅牢なセーフガード 2. 公平性とインクルーシブな顧客体験 AI ガードレールは全ての顧客層に対する公平な対応を確保します。 バイアスの防止: AI 応答における差別的パターンの継続的な監視 文化的配慮: 多様な顧客の背景やコミュニケーションスタイルに対応するガードレール 均等なアクセス: プロファイルに関係なく、全ての顧客に一貫した高品質な AI アシスタンスを提供 インクルーシブな言語: 全ての顧客に対して敬意あるコミュニケーションを促進するコンテンツフィルター 3. 透明性と説明可能な AI Amazon Connect Customer の AI エージェントとのネイティブ統合により、かつてない透明性を実現します。 明確な意思決定: 特定のガードレールが発動した理由をエージェントが理解 監査証跡: Amazon Connect Customer の分析機能を通じた AI の意思決定プロセスの完全な可視化 顧客へのコミュニケーション: AI の制限に達した際の透明性を持った説明 規制遵守: コンプライアンス監査や規制要件に対応する完全なドキュメント 4. プライバシーファーストのデータ保護 AI エージェントはプライバシー・バイ・デザインの原則を実装しています。 リアルタイム保護: 会話中に PII の検出と保護を即座に実施 安全な処理: 全ての AI 処理が Amazon Connect Customer の安全なインフラストラクチャ内で実行 5. 説明責任とガバナンス Amazon Connect Customer は包括的なガバナンス機能を提供します。 明確な責任分担: コンタクトセンター運用における AI 監視の役割を定義 継続的な監視: AI のパフォーマンスと倫理的コンプライアンスのリアルタイム追跡 定期的な評価: 顧客体験への AI の影響を評価する組み込みツール 適応的な改善: 実際のパフォーマンスとフィードバックに基づく継続的な改善 ネイティブ統合が責任ある AI に重要な理由 Amazon Connect Customer の AI ガードレールが Amazon Connect Customer にネイティブに統合されていることは、パフォーマンスだけでなく、責任ある AI の導入にとって根本的に重要です。 統一されたガバナンス: AI ガバナンスの全てが使い慣れた Amazon Connect Customer コンソール内で完結し、一貫した監視と管理を実現します。 コンテキストの理解: ガードレールが Amazon Connect Customer のインタラクションの全コンテキストを理解し、より適切で細やかな AI 動作を可能にします。 人間と AI のコラボレーション: シームレスな統合により、優れたカスタマーサービスを支える AI アシスタンスと人間の専門知識の自然な連携を維持します。 コンプライアンスの継続性: ガードレールは Amazon Connect の既存のコンプライアンスおよびセキュリティフレームワーク内で動作し、規制への適合を維持します。 Amazon Connect Customer の AI ガードレールの理解 AI ガードレールは、顧客対応中にリアルタイムで動作する組み込みの AI に対する安全メカニズムです。外部のコンテンツフィルタリングソリューションとは異なり、AI エージェントプラットフォームにネイティブに統合されているため、会話の流れや顧客体験に影響を与えることなくシームレスな保護を提供します。 ネイティブ統合の主なメリット コンテキストの理解: 会話のコンテキストを理解する高度な自然言語処理 シームレスな管理: 使い慣れた Amazon Connect Customer コンソール、CLI、API による設定と監視 エンタープライズ向けのスケーラビリティ: 大規模なコンタクトセンター業務に対応する設計 コンプライアンス対応: 規制要件と監査証跡を考慮した設計 コスト効率: 追加のインフラストラクチャやライセンスコストが不要です。コストは AI エージェントの料金に含まれます ガードレールの主要コンポーネント Connect AI Agents Guardrails のインターフェースに基づくと、責任ある AI の導入を保証するために連携する 7 つの主要コンポーネントがあります。多層防御戦略を構成するコンポーネントは以下の通りです。 ┌────────────────────────────────────────────────────────────┐ │ 顧客インタラクション 　　 │ ├────────────────────────────────────────────────────────────┤ │ 入力処理パイプライン　　　　　 │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ プロンプト │→│ ワード │→│ 機密情報　　　│ │ │ │ 攻撃 │ │ フィルター　 │ │ フィルター │ │ │ └─────────────┘ └─────────────┘ └─────────────┘ │ ├────────────────────────────────────────────────────────────┤ │ AI 処理およびレスポンス生成 │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ 拒否トピック │→│ コンテンツ │→│コンテキスト │ │ │ │ │ │ フィルター │ │グラウンディング│ │ │ └─────────────┘ └─────────────┘ └─────────────┘ │ ├────────────────────────────────────────────────────────────┤ │ 出力検証と配信 │ │ ┌─────────────────────────────────────────────────────────┤ │ │ ブロック時メッセージ │ │ └─────────────────────────────────────────────────────────┤ └────────────────────────────────────────────────────────────┘ ガードレールの差別化ポイント 複雑さとレイテンシーを増加させる後付けのソリューションとは異なり、AI ガードレールは Amazon Bedrock Guardrails と同じ実績ある技術を活用し、プラットフォームのコアにネイティブに統合されています。 主な差別化要因: ネイティブ統合: Amazon Connect Customer に直接組み込まれ、レイテンシーへの影響は最小限 (100 ミリ秒未満) エンタープライズグレードの AI: Amazon Bedrock と同じ高度なモデルを使用 統一された管理: 全てのガードレール設定を単一のコンソールで管理 多言語サポート: 50 以上の言語に対応 コンプライアンスファーストの設計: 包括的な監査証跡ときめ細かな制御 保護の 7 つの柱 AI ガードレールは、7 つの統合コンポーネントにより包括的な保護を提供します。 1. プロンプト攻撃の検出 ジェイルブレイクやプロンプトインジェクション攻撃による悪意ある操作から AI の動作を保護します。 仕組み: 入力パターンを分析して操作の試みを検出 AI が処理する前に不審なプロンプトをブロック セキュリティレビューのためにインシデントを記録 敵対的な条件下でも AI の整合性を維持 導入効果: ある金融サービス企業では、導入初月に 127 件のプロンプトインジェクションの試みを防止し、機密性の高い顧客データを保護、システムの整合性を維持しました。 2. コンテンツフィルタリング ヘイト、侮辱、性的内容、暴力、不正行為の 5 つのカテゴリで有害コンテンツをフィルタリングします。 設定可能な強度レベル: None: フィルタリングなし Low: 明らかに不適切なコンテンツに対する基本的なフィルタリング Medium: 中程度の感度でバランスの取れたフィルタリング High: 最大限の保護による包括的なフィルタリング 二重フィルタリングシステム: 入力フィルタリング: AI が処理する前に顧客メッセージを分析 出力フィルタリング: AI が生成した応答を配信前に検証 ヘルスケアの例: 設定: - 入力ヘイト: Medium (医療用語は許可、差別はブロック) - 入力暴力: High (脅迫は即座にエスカレーション) - 出力性的内容: Medium (専門的な医療コミュニケーション) - 出力暴力: High (AI 応答では一切許容しない) 結果: 自然な医療に関する会話を維持しつつ、不適切なコンテンツによる インシデントを 94% 削減 3. 拒否トピック 専門的な資格や特殊な専門知識を必要とする分野で AI がアドバイスを提供することを防止します。 一般的な拒否トピック: 金融サービス: 投資アドバイス、税務ガイダンス、保険の推奨 ヘルスケア: 医療診断、治療の推奨、処方に関するアドバイス 法務: 法的助言、契約解釈、規制ガイダンス インテリジェントなリダイレクト: 単にブロックするのではなく、適格な専門家へ顧客をスムーズに案内します。 顧客: 「退職に向けてどの株を買うべきですか?」 AI 応答: 「退職後の資産計画にご関心をお持ちですね。お客様の状況と 目標に合わせた個別のアドバイスをご提供できる、資格を持つ ファイナンシャルアドバイザーにおつなぎいたします。」 金融サービスでの効果: 顧客満足度 4.6/5 を維持しながら、コンプライアンス違反を 87% 削減しました。 4. ワードフィルター コンテキストを考慮したマッチングにより、不適切な単語、フレーズ、冒涜的な表現をブロックします。 2 層構造のシステム: 冒涜フィルター: 事前構築された包括的なデータベース カスタムワード: 組織固有の用語 (競合他社名、内部コード、機密用語) コンテキスト認識: 正当な使用と不適切な使用を区別します。 医療コンテキストでの「がん」: 許可 侮辱としての「がん」: ブロック 薬の「薬物」: 許可 違法行為の「薬物」: ブロック 5. 機密情報フィルター (PII) 個人を特定できる情報をリアルタイムで自動的に検出・保護します。 保護対象の情報タイプ: 金融情報: クレジットカード番号、銀行口座番号、社会保障番号(SSN)、税務 ID 個人情報: メールアドレス、電話番号、住所、運転免許証、パスポート 医療情報: 医療記録番号、保険 ID、生体認証データ カスタム: 正規表現による組織固有のパターン 3 つの保護モード: ANONYMIZE — データを保護しながら会話の流れを維持: 元の入力: "レシートを John.doe@example.com に送って" 処理後: "レシートを [EMAIL_ADDRESS] に送って" AI の理解: 顧客のメールアドレスに領収書を送信することを認識 顧客体験: シームレス、中断なし BLOCK — 高度な機密データの最大限の保護: 顧客: "私の社会保障番号は 123-45-6789" システム: SSN を AI 処理からブロック エージェントへのアラート: 「顧客が SSN を提供 — セキュアな認証プロセスを使用してください」 REDACT — コンプライアンスに特化したログ記録: ログ: "顧客は [REDACTED] からアカウントを呼び出しました" 監査証跡: 何がマスキングされ、その理由を記録 復元可能: 権限を持つ担当者が元のデータにアクセス可能 通信業界での成果: シームレスな顧客体験を維持しながら、PII 漏洩インシデントを 94% 削減しました。 6. コンテキストグラウンディングチェック AI の応答が事実に正確で、信頼できるソースに基づいていることを保証します。 仕組み: ナレッジベースに対して応答を検証 グラウンディングの信頼度をスコアリング (0.0〜0.99 の閾値) 顧客の質問との関連性を確認 閾値を下回る応答をブロック 設定例: グラウンディング閾値: 0.75 (高い信頼度が必要) ナレッジソース: 製品ドキュメント、トラブルシューティングガイド、FAQ データベース 関連性閾値: 0.80 (関連性の高い応答のみ) シナリオ: 顧客がソフトウェアのインストールについて質問 ✓ 許可: 具体的な手順を含むインストールガイドを引用した応答 ✗ ブロック: 公式ドキュメントに基づかない一般的な応答 ✗ ブロック: 正確だが別の製品に関する無関係な応答 テクニカルサポートでの効果: 誤った情報の提供を 40% 削減、初回解決率を 25% 向上させました。 7. ブロック時メッセージ ガードレールが発動した際に、透明性があり敬意あるコミュニケーションを提供します。 カスタマイズ可能なメッセージ: ブロック時プロンプトメッセージ: 顧客の入力がブロックされた場合 ブロック時レスポンスメッセージ: AI の応答がブロックされた場合 実装例: ブロック時プロンプト: 「お問い合わせにお答えしたいと思います。本日は アカウントやサービスについてどのようにお手伝いできるか、お話しさせて ください。専門的なサポートが必要な場合は、適切なチームメンバーに おつなぎいたします。」 ブロック時レスポンス: 「お探しの情報を的確にご提供することが難しい 状況です。お客様のご要望により適切に対応できる専門スタッフに おつなぎいたします。」 責任ある AI の実装: 8 つの側面の実践 AI ガードレールが AWS の責任ある AI フレームワークの各側面をどのように実装しているかを見ていきましょう。 側面 1: 公平性 — 全ての顧客への公平な対応 目標: 顧客の属性、コミュニケーションスタイル、背景に関係なく、AI が一貫した偏りのないサービスを提供すること。 実装: コンテンツフィルターで差別的な言語パターンを監視 ワードフィルターでインクルーシブなコミュニケーションを促進 コンテキストグラウンディングにより、偏った推測ではなく事実に基づいた応答を保証 顧客セグメント全体でのバイアスの定期監査 小売業の例: ある大手小売企業が公平性の監視を導入した結果、AI が英語を母国語としない話者に対して短い応答を返していることが判明しました。調整後、全ての言語グループで顧客満足度スコアが 18% 向上しました。 側面 2: 説明可能性 — AI の判断を理解する 課題: ガードレールが発動する理由や AI が推奨を行う根拠を明確に説明すること。 実装: エージェントへの明確なガードレール発動通知 判断根拠の詳細なログ記録 ポリシー参照ドキュメント 代替アクションの提案 金融サービスでの効果: エージェントの信頼度が 35% 向上し、コンプライアンス研修時間が 50% 短縮されました。 側面 3: プライバシーとセキュリティ — 顧客データの保護 課題: パーソナライズされた AI 補助を提供しながら、機密性の高い顧客情報を責任を持って取り扱うこと。 実装: PII の自動検出と保護 保存時と転送時の暗号化 ロールベースのアクセス制御 データ最小化の原則 包括的な監査証跡 ヘルスケアでの成果: HIPAA 準拠のコンタクトセンターで、200 万件以上のインタラクションを処理しながら 18 か月間プライバシー違反ゼロを達成しました。 側面 4: 安全性 — 有害な出力の削減 課題: AI が有害、不適切、または危険なコンテンツを生成するのを防止すること。 実装: 多層的なコンテンツフィルタリング (入力と出力) プロンプト攻撃の検出 危機介入プロトコル 脅威の評価とエスカレーション メンタルヘルスの危機検出: トリガーフレーズ: "自分を傷つけたい", "自殺を考えている", "生きていたくない" 即時アクション: 1. AI 処理を一時停止 2. 危機対応カウンセラーに即座に接続 3. 国の自殺防止ライフラインの番号を案内 4. スーパーバイザーとメンタルヘルス専門家にアラート 5. フォローアップケアのために記録 フォローアップ: - 安全計画の策定が必要 - 24 時間以内の専門家への紹介 - 48 時間以内のフォローアップ電話 ヘルスケアでの効果: 危機的状況の 100% を適切にエスカレーションし、早期介入により潜在的には 12 名の命を救った可能性があります。 側面 5: 監視 — AI 動作のモニタリングと制御 課題: 数千のインタラクションにスケールしても、横断して効果的な監視を維持すること。 実装: リアルタイム監視ダッシュボード 設定可能なアラート閾値 バージョン管理 (ドラフト / 公開済み) 緊急オーバーライド機能 パフォーマンスメトリクスの追跡 監視ダッシュボード: リアルタイムメトリクス: - ガードレール発動: 本日 127 回 (前日比 ↓ 15%) - コンテンツフィルタリング: 43 件 (ヘイト: 12, 暴力: 8, 性的内容: 23) - PII 検出: 89 件 (SSN: 23, クレジットカード: 34, メール: 32) - 拒否トピック: 18 件 (金融: 12, 医療: 6) - グラウンディング失敗: 7 件 (0.75 閾値未満) アラート: 高: プロンプト攻撃の異常な急増 中: グラウンディング閾値が厳しすぎる可能性 ✓ 正常: その他のメトリクスは全て期待範囲内 エンタープライズでの効果: インシデント対応が 60% 高速化し、継続的なチューニングにより誤検知が 40% 削減されました。 側面 6: 正確性と堅牢性 — 精度の確保 課題: 予期しない入力に対しても、一貫して信頼性の高い正確な結果を提供すること。 実装: ナレッジベースに対するコンテキストグラウンディング 全ての応答のソース検証 ハルシネーションの検出と防止 敵対的入力のテスト グラウンディング検証プロセス: 顧客の質問: 「電子機器の返品ポリシーを教えてください」 AI 処理: 1. LLM から応答を生成 2. 応答から主要な主張を抽出 3. 各主張をナレッジベースに対して検証 4. グラウンディングスコアを算出: 0.92 (0.75 の閾値を超過) 5. 質問との関連性を検証: 0.88 (0.80 の閾値を超過) 6. ソース帰属付きで応答を配信 応答: 「電子機器は購入後 30 日以内であればレシートをお持ちいただければ 返品可能です。商品は元のパッケージに入った未開封の状態である必要があり ます。[出典: 返品ポリシー v3.2, セクション 4.1]」 小売業での成果: 製品情報の精度 95% を達成し、確認のための再問い合わせが 30% 減少しました。 側面 7: ガバナンス — 組織的な説明責任 課題: AI システムに対する明確な所有権、プロセス、説明責任を確立すること。 実装: 役割と責任の明確化 ポリシーの定期的なレビューと更新 コンプライアンス委員会による監視 意思決定プロセスの文書化 継続的な改善サイクル ガバナンス体制: エグゼクティブスポンサー: - 戦略的監視とリソース配分 - AI 倫理ポリシーの最終決定権 - 責任ある AI の成果に対する説明責任 技術委員会: - AI システムの設計と実装 - パフォーマンスの監視と最適化 - 技術的なリスク評価 倫理委員会: - 倫理ガイドラインの策定 - バイアスの検出と防止 - 公平性とインクルージョンの監視 コンプライアンス委員会: - 規制要件の解釈 - 監査とドキュメントの監督 - リスク管理と軽減 レビューサイクル: - 週次: 運用パフォーマンスと緊急課題 - 月次: トレンド分析と戦術的調整 - 四半期: 戦略レビューとポリシー更新 - 年次: 包括的な評価と計画 側面 8: 透明性 — ステークホルダーへの情報提供 課題: 顧客、エージェント、規制当局が AI の機能と制限を理解できるようにすること。 実装: AI の使用に関する明確なコミュニケーション ガードレール発動時の透明なメッセージ 機能に関する公開ドキュメント 定期的な透明性レポート 顧客の選択権と制御権 顧客へのコミュニケーション例: 「この会話では、より迅速で正確なサービスをご提供するために AI 技術が エージェントを支援しています。お客様のプライバシーは自動化された セーフガードにより保護されており、会話は常に人間のエージェントが 管理しています。AI アシスタンスなしでエージェントとお話しになりたい 場合は、いつでもお申し付けください。」 重要な注意事項と考慮点 技術的な注意事項 言語とコンテキストの理解: AI システムがコンテキストや意図を誤って解釈する場合がある 複雑なシナリオでは人間の判断が必要になる場合がある 文化的・言語的なニュアンスが精度に影響する可能性がある 有効性を維持するためにモデルの定期的な更新が必要 誤検知と検出漏れ: 過度な制限設定は正当なインタラクションをブロックする可能性がある 保護が不十分だと不適切なコンテンツを許容してしまう可能性がある パフォーマンスを最適化するために継続的なチューニングが必要 エッジケースでは人間の監視が不可欠 運用上の考慮事項 エージェントのトレーニング要件: ガードレール機能に関する包括的なトレーニング エスカレーション手順の理解 システムの制限と機能に関する知識 機能進化に伴う定期的な更新 顧客体験への影響: ブロックされたインタラクションが顧客の不満につながる可能性がある 制限が適用される際の明確なコミュニケーションが重要 代替の支援手段をすぐに利用できるようにする必要がある 保護とサービス品質のバランスが求められる コンプライアンスと法的な考慮事項 規制遵守: ガードレールはコンプライアンスプログラムを補完するものであり、置き換えるものではない 設定の定期的な法的レビューが必要 文書化と監査証跡が不可欠 業界固有の要件が適用される場合がある データプライバシー: PII の検出と取り扱いがプライバシー法に準拠する必要がある データ処理に関する顧客の同意への配慮 越境データ転送への影響 保持と削除ポリシーの整合 ガードレールの計画と設計 ステップ 1: ガードレール要件の定義 ブロックすべき機密トピックの特定 (PII、不適切なコンテンツなど) 許可/ブロックするコンテンツカテゴリの定義 応答フィルタリング基準の策定 コンプライアンス要件の文書化 ステップ 2: コンテンツポリシーの設計 以下に対するコンテンツフィルターを作成します。 ヘイトスピーチと有害表現 暴力と自傷行為 性的コンテンツ 不正行為と違法行為 ビジネスに固有のブロックトピックを定義します。 AI エージェント を使用したガードレールの設定 Amazon Connect Customer コンソールに移動します。 左側の AI agent Designer に移動し、 ガードレール を選択します。   AI ガードレールを作成 をクリックし、名前とわかりやすい説明を入力して、作成をクリックします。 コンテンツフィルター → 有害カテゴリ に移動して有効化します。プロンプトとレスポンスのフィルターを設定します。 プロンプト攻撃 についても同様の設定を行います。 拒否されたトピック を定義します。 単語フィルター と冒涜フィルターを設定します。 PII タイプと正規表現パターンを含む 機密情報フィルター を設定します。 最後に、 ブロックされたプロンプト と ブロックされたレスポンス のメッセージを設定します。 ガードレールの実装により、AI を潜在的なリスク要因から信頼できるビジネス資産へと変え、エンタープライズ規模で AI を活用したカスタマーサービスを自信を持って展開できるようになります。 今後の展望: コンタクトセンターにおける責任ある AI の未来 生成 AI の進化に伴い、コンタクトセンターでの責任ある実装のアプローチも進化していきます。AWS では、新たなニーズと課題に対応するため、AI ガードレールの継続的な進化に取り組んでいます。 継続的に開発を進めている主な分野は以下の通りです。 AI の意思決定プロセスの透明性を高める説明可能性機能の強化 特定の顧客セグメントやシナリオに対する、よりきめ細かな制御オプション 新たなリスクやコンテンツの懸念に対する高度な検出機能 技術者以外のユーザー向けのガードレール設定・テストツールの簡素化 組織全体のガバナンスおよびコンプライアンスフレームワークとの統合 これらの機能への継続的な投資を通じて、責任と信頼の最高水準を維持しながら、生成 AI の可能性を最大限に活用できるよう組織を支援していきます。 まとめ: イノベーションと責任のバランス コンタクトセンターにおける生成 AI の導入は、顧客体験と業務効率を変革する大きな機会です。しかし、そのメリットを実現するには、イノベーションと責任のバランスを取る慎重なアプローチが必要です。 AI ガードレールは、このバランスを効果的に実現するためのツールを組織に提供します。明確な境界を定義し、適切な制御を実装し、人間による監視を維持することで、組織の価値観、ポリシー、顧客の期待に沿った形で AI の力を活用できます。 コンタクトセンターで生成 AI の活用を始める際には、ガードレールを制約ではなく、信頼と持続可能なイノベーションの推進力と捉えることをお勧めします。最初から責任ある AI のプラクティスを実装することで、顧客、従業員、組織全体に利益をもたらす長期的な成功の基盤を構築できます。 開始方法 コンタクトセンターに AI ガードレールを導入する準備はできましたか？ Amazon Connect Customer コンソールにアクセスして、利用可能なオプションと設定をご確認ください。責任ある AI のプラクティスと実装ガイダンスの詳細については、 https://aws.amazon.com/jp/products/connect/customer/ai-agents/ のドキュメントとリソースをご覧ください。 ソリューションアーキテクトと AI スペシャリストのチームが、お客様固有のニーズとユースケースに合わせた責任ある AI アプローチの設計と実装を支援いたします。コンサルテーションのスケジュールについては、AWS の担当者にお問い合わせください。 筆者について Shabi Abbas Sayed は、Amazon Web Services (AWS) の Amazon Connect & Applied AI 担当シニアスペシャリストソリューションアーキテクトです。コンタクトセンター技術、クラウドアーキテクチャ、会話型 AI の分野で 18 年以上の経験を持ちます。Amazon Connect Customer を専門とし、AI 駆動のスケーラブルなソリューションを活用した顧客体験プラットフォームのモダナイゼーションを支援してきました。AWS イベントでの登壇実績があり、生成 AI や音声技術に関するソートリーダーシップにも積極的に貢献しています。 Naga Bhargav は、Amazon Connect、コンタクトセンター、レガシーマイグレーション、生成 AI ソリューションを専門とする AWS のテクニカルアカウントマネージャーです。豊富なエンタープライズ経験を活かし、組織の戦略的なクラウドイニシアチブを推進し、安全でスケーラブルかつコスト効率の高いソリューションの構築を支援しています。 Abilashkumar P C は、ロンドンを拠点とする AWS の Applied AI 担当シニアスペシャリストソリューションアーキテクトです。サーバーレス技術を活用したコンタクトセンター向けの回復力のある AI 搭載ソリューションの設計・構築を支援しています。カオスエンジニアリング、マルチリージョンアーキテクチャ、オペレーショナルエクセレンスに情熱を持っています。仕事以外では、クリケットやドライブを楽しんでいます。 翻訳はテクニカルアカウントマネージャーの高橋が担当しました。