本記事は 2026 年 7 月 9 日 に公開された「 Diagnose and resolve replica lag in Amazon RDS for Oracle replicas – Part 2 」を翻訳したものです。 本記事は、Amazon Relational Database Service (Amazon RDS) for Oracle リードレプリカのレプリケーション遅延を減らす方法を扱う 2 回シリーズの後編です。 Part 1 では、REDO 圧縮とレプリカ遅延を最適化する設定オプションを紹介しました。 本記事では、次の内容を説明します。 Amazon CloudWatch メトリクスとデータベースビューを使ったレプリカ遅延の監視。 待機イベント分析による一般的な根本原因の特定。 パフォーマンス問題を解消するための段階的なトラブルシューティング手法。 Amazon RDS for Oracle の リードレプリカ でレプリカ遅延が発生した場合、迅速な診断と解消が欠かせません。遅延は、災害対策 (DR) の準備態勢の維持に影響し、リードレプリカ上で実行されるレポート用ワークロードでのデータ提供を遅らせ、データベースのメジャー / マイナーバージョンアップグレードといった通常のメンテナンス作業を遅くする可能性があります。 問題の原因が設定、アプリケーションのワークロードパターン、リソース制約のいずれであっても、根本原因を特定し、的を絞った対策を実施するための体系的な手法を紹介します。 前提条件 始める前に、次の条件を満たしていることを確認してください。 Oracle Enterprise Edition (EE) — レプリケーションを担う Oracle Data Guard は Enterprise Edition でのみ利用できるため、リードレプリカではプライマリインスタンスに Enterprise Edition が必要です。 2 つ以上の vCPU を持つ DB インスタンスクラス — レプリケーションプロセスが正しく機能するには十分なコンピューティングリソースが必要です。 適切なライセンス — 読み取り専用モードには Active Data Guard ライセンスが必要ですが、マウントモードのレプリカには不要です。バージョンやライセンスに関する具体的な制限は、「Requirements and considerations for RDS for Oracle replicas」で確認してください。 Amazon RDS for Oracle のレプリケーション遅延のトラブルシューティング 本セクションでは、遅延の特定方法と一般的な原因を扱います。遅延の存在を特定できたら、以降のセクションの手法を使って根本原因を突き止め、対策を実施できます。 レプリカ遅延を特定する方法 レプリカ遅延は、 Amazon CloudWatch メトリクスを使うか、Oracle のデータベースビューを直接クエリして特定できます。CloudWatch メトリクスでは遅延を素早く特定でき、データベースビューではより詳細な診断情報が得られます。 Amazon RDS for Oracle では、ReplicaLag CloudWatch メトリクスはリードレプリカインスタンスでのみ利用できます。CloudWatch メトリクスの粒度について詳しくは、 CloudWatch metrics のドキュメントを参照してください。 Amazon CloudWatch メトリクス – ReplicaLag ReplicaLag CloudWatch メトリクスは、リードレプリカでの REDO 適用の遅延を表示します。適用遅延が大きい場合は、リードレプリカ側のリソース制約 (CPU、I/O) や、適用プロセスに影響する同様の問題を示しています。 このメトリクスを表示するには、次の手順に従います。 リードレプリカインスタンスの [Monitoring] タブに移動します。 [CloudWatch] セクションで「ReplicaLag」を検索します。 データベースレベルでの現在のレプリカ遅延を確認します。 注 : RDS はリードレプリカに非同期の REDO 転送を使用するため、データベースアクティビティがない場合でもレプリカ遅延が 1 秒と表示されることがあります。 V$ ビューやアプリケーションテーブルに対して手動でデータベースクエリを実行し、データベースの変更が同期しているか検証できます。 Amazon CloudWatch メトリクス – ReplicaTransportLag ReplicaTransportLag CloudWatch メトリクスは、プライマリデータベースからリードレプリカへの REDO 転送の遅延を測定します。転送遅延が大きい場合は、通常、ネットワークの問題やプライマリ側のボトルネックを示しています。 このメトリクスを表示するには、次の手順に従います。 リードレプリカインスタンスの [Monitoring] タブに移動します。 [CloudWatch] セクションで「ReplicaTransportLag」を検索します。 データベースレベルでの現在のレプリカ遅延を確認します。 2 つのメトリクスを比較すると、遅延が転送の遅れによるものか、適用プロセスのボトルネックによるものかを判断できます。 標準的なデータベースクエリ レプリカ遅延に関するより詳細な診断情報を得るには、Oracle のデータベースビューを直接クエリできます。 公開ドキュメント に記載されているとおり、次のビューがレプリカ遅延の診断に役立ちます。 V$ARCHIVED_LOG 。 V$DATAGUARD_STATS 。 V$DATAGUARD_STATUS 。 V$ARCHIVE_GAP 。 遅延に関連するビュー ( V$DATAGUARD_STATS 、 V$DATAGUARD_STATUS 、 V$ARCHIVE_GAP ) をリードレプリカインスタンスでクエリすると、遅延の状態を取得できます。 V$ARCHIVED_LOG はプライマリとリードレプリカの両方でクエリでき、インスタンス間のログ状態を比較して特定できます。 注: Amazon RDS for Oracle の マウントモードのリードレプリカ では、データベースがクエリのためにアクセスできないため、リードレプリカ上でデータベースビューをクエリできません。ReplicaLag と TransportLag の CloudWatch メトリクスが遅延の監視情報を提供します。さらに、アラートログをダウンロードして確認することで、レプリケーション遅延や適用の問題を特定できます。 レプリカ遅延を引き起こす一般的な要因 レプリカ遅延の特定方法を理解したところで、本セクションでは一般的な原因を掘り下げます。Amazon RDS for Oracle のレプリカ遅延は、設定の問題、アプリケーションのワークロードパターン、外部要因という 3 つの主要なカテゴリから生じます。 設定の問題 インフラストラクチャとデータベースの設定は、レプリケーションのパフォーマンスに重要な役割を果たします。一般的な設定の問題としては、REDO ログやスタンバイログのサイズが不足または過小であること、メモリ設定が想定水準に達していないこと、プライマリやリードレプリカのデータベースワークロードを処理するにはコンピューティングやストレージのリソースが不十分であることが挙げられます。 アプリケーションのワークロードパターン アプリケーションがデータベースとやり取りする方法は、レプリケーションのパフォーマンスに大きく影響します。バッチジョブや高並行性ワークロードといった大量の処理は過剰な REDO を生成し、レプリカが追従する能力を圧倒することがあります。同様に、リードレプリカ上で実行される読み取り集約型のクエリは、コンピューティングとストレージのリソースを大量に消費し、適用プロセスを遅くする可能性があります。 データベース設計の選択も遅延の一因になります。過剰なコミットは REDO 生成を増やし、 特権ユーザー (SYS、SYSTEM、RDS_DATAGUARD、rdsdb) の操作を制限するトリガー は内部のレプリケーションプロセスを妨げる恐れがあります。 外部要因 ネットワークレイテンシーもレプリカ遅延の一因になり、特にリージョン間リードレプリカで顕著です。本シリーズの Part 1 では、ネットワークレイテンシーに関連する遅延への対処方法を詳しく説明しています。 レプリカ遅延のトラブルシューティング 前述の方法でレプリカ遅延の存在を特定できたら、次のステップは根本原因の判断です。根本原因はプライマリインスタンスまたはリードレプリカインスタンスのいずれかで生じます。 Amazon RDS for Oracle でレプリカ遅延のトラブルシューティングや根本原因の特定を行う際は、プライマリとリードレプリカの両方のインスタンスで CloudWatch Database Insights (DBI) と 拡張モニタリング (EM) を 1 秒粒度で有効にすることをお勧めします。これらのツールを使うと、システム負荷をほぼリアルタイムで能動的に検証でき、CloudWatch メトリクスの 1 分粒度よりも細かい情報が得られます。 通常、レプリカ遅延の根本原因は、遅延が増加し始めた時点で発生していたイベントに関係しています。その時間帯 (5～10 分以内) の DBI と EM のグラフを評価すると、システムで何が変化したかが明らかになることがよくあります。データベースの待機イベントとリソース競合を相関させることで、問題を特定し、緩和または解消するための適切な対策を講じられます。 注: 遅延が増加したときに固有の異常が見当たらない場合は、遅延のある期間とない期間で Active Session History (ASH) または Automatic Workload Repository (AWR) レポートを比較し、差分を特定します。リードレプリカ向けの AWR レポートの生成方法については、 Generate AWR reports for Amazon RDS for Oracle read replicas を参照してください。 レプリカ遅延のトラブルシューティングでは、データベースの待機イベントを特定すると根本原因を突き止めやすくなります。待機イベントは、期待されるデータベースアクティビティがないのに、データベースがどこで時間を費やしたりリソースを保持したりしているかを示します。次の待機イベントは、レプリカ遅延と関連することが多いものです。 Data Guard プロセスの待機イベント これらの待機イベントは、 V$DATAGUARD_PROCESS をクエリして監視できます。 Log Network Server (LNS) wait on SENDREQ または ARCH wait on SENDREQ。 Managed Recovery Process (MRP) wait on archivelog arrival または WAIT_FOR_LOG。 セッションレベルの待機イベント これらの待機イベントはデータベースセッションに影響し、 V$SESSION をクエリして監視できます。 log file sync。 db file sequential read / db file scattered read / db file parallel write。 CPU 関連の待機、または高い DB CPU 時間。 これらの待機イベントは、直接的または間接的にレプリカ遅延と関係しています。特定した根本原因に基づき、適切な対策を講じてこれらの待機イベントを排除 / 減少させ、レプリケーション遅延を減らしてください。 一般的な原因と解決策 REDO ログのサイズが不十分 archive_lag_target パラメータは、ログスイッチの発生頻度を制御します。このパラメータは、ログスイッチが強制されるまでの最大時間 (秒) を指定します。Amazon RDS for Oracle では最大値は 300 秒で、Oracle 本来の最大値である 7200 秒 (2 時間) とは大きく異なります。この Amazon RDS for Oracle 固有の制限により、1 時間あたり少なくとも 12 回のログスイッチが発生します。REDO ログがワークロードに対して小さすぎると、ログスイッチが頻繁に発生しすぎます。頻繁なログスイッチにより、チェックポイントの増加と I/O スパイクが生じ、プライマリとリードレプリカの両方を圧迫する可能性があります。 次のクエリを使って、1 時間あたりのアーカイブログ生成量を特定します。 alter session set nls_date_format = 'DD-MON-YYYY HH24:MI:SS'; select trunc(COMPLETION_TIME,'HH') TIME, round(sum(BLOCKS*BLOCK_SIZE)/1024/1024/1024) REDO_GENERATED_IN_GB, count(*) GENERATION_COUNT from v$archived_log group by trunc(COMPLETION_TIME,'HH') order by 1 ; このクエリは、1 時間あたりの REDO 生成量とログスイッチ頻度を時系列で示し、ピーク時間帯を特定して、現在の REDO ログサイズが適切かどうかを判断するのに役立ちます。 注: Amazon RDS for Oracle インスタンスでは ALTER SYSTEM/DATABASE コマンドが制限されているため、 Oracle DB インスタンスで一般的なログ関連タスクを実行する AWS ドキュメントに従い、RDSADMIN パッケージを使って必要な REDO ログ関連の作業を行ってください。 ワークロードに対するシステム構成の不足 リソースのスロットリングは、コンピューティングレベル (CPU、メモリ、ネットワーク帯域幅) やストレージレベル (IOPS/スループット) で発生する可能性があります。プライマリやリードレプリカに十分なリソースがないと、レプリケーションプロセスが他のデータベース操作と競合し、遅延を引き起こします。 注: スループットのスロットリングはネットワークレベルでも発生し得るため、ワークロード向けに選択したコンピューティングが、アプリケーションのワークロードを支えるベースライン帯域幅を備えているか確認してください。 ストレージレベルのリソーススロットリングが発生している場合、通常は読み取り / 書き込みのレイテンシーが 10 ミリ秒を超えます。スロットリングされている値に応じて IOPS/スループットを増やせば、問題を緩和 / 解消できます。 DBI で CPU 使用率が割り当て済みの最大 vCPU を超えていないか確認してください。また、前述の待機イベントがソースまたはターゲットのいずれかで DBI に現れていないかも確認します。プライマリとリードレプリカが同じコンピューティングおよびストレージ構成であることを確認してください。これにより、レプリカがソースからのピーク負荷を処理できるようになります。 注: 高い CPU 使用率は、直接的な負荷から生じることもあれば、リソースのスロットリングから間接的に生じることもあります (たとえば、 Amazon Elastic Block Store (EBS) の IOPS 上限によりサーバープロセスが待機し、CPU 使用率が上がる場合など)。したがって、関連する根本原因を修正すれば、CPU 消費を割り当て済み vCPU 以下に抑えられます。 シナリオ: レプリカ遅延を段階的にトラブルシューティングする 次のシナリオでは、増加するレプリカ遅延の原因を特定し、絞り込む方法を示します。 ステップ 1: CloudWatch でレプリカ遅延を確認し、遅延の開始時刻を特定する リードレプリカインスタンスの [ Monitoring ] タブに移動して、ReplicaLag メトリクスを表示します。「ReplicaLag」グラフで [Maximize] を選択し、正確な開始時刻を特定します。 この例では、スナップショットは 1 月 5 日の 18:00 UTC に取得されました。グラフを見ると、レプリカ遅延は 17:50 UTC 頃から増加し始めています。遅延は数分前に始まり、現在 9.15 秒に達しています。 ステップ 2: プライマリで DBI を確認する AWS マネジメントコンソールでプライマリデータベースインスタンスに移動します。 [Monitoring] → [Database Insights] を選択します。デフォルトのビューには直近 3 時間が表示されます。 右上隅の [Custom] を選択し、分析に適した時間範囲を選びます。 ステップ 3: 転送遅延と適用遅延を比較する 「レプリカ遅延を特定する方法」セクションで説明したとおり、AWS マネジメントコンソールでリードレプリカのモニタリングセクションにある ReplicaLag と ReplicaTransportLag の遅延メトリクスを確認します。 CloudWatch メトリクスで ReplicaTransportLag と ReplicaLag のメトリクスを比較し、ボトルネックがどこにあるかを判断します。 シナリオ 示す内容 TransportLag が高く、ApplyLag が同程度 問題は REDO の送信であり、適用ではない TransportLag が正常で、ApplyLag が高い レプリカでの適用プロセスのボトルネック 両方のメトリクスが高いが値が異なる 詳細な分析が必要 このシナリオでは、Transport Lag と Apply Lag がほぼ同じであり、ボトルネックが適用プロセスではなく REDO の生成 / 送信にあることを示しています。 ステップ 4: リードレプリカで MRP プロセスの状態を確認する リードレプリカで V$MANAGED_STANDBY をクエリして、Managed Recovery Process の状態を確認します。 SQL> SELECT PROCESS, STATUS, SEQUENCE#, BLOCK# FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0'; PROCESS STATUS SEQUENCE# BLOCK# --------- ------------- ----------- ---------- MRP0 APPLYING_LOG 15844 259554 現在、MRP プロセスの状態を見ると、ログを適用中であることが示されています。次のステップとして、プライマリで生成されたログシーケンスを確認する必要があります。 SQL> select thread#,max(sequence#) from v$log_history group by thread#; THREAD# MAX(SEQUENCE#) --------- -------------- 1 15863 ここで、適用済みのログとプライマリで生成されたログを比較すると、19 のログシーケンスのギャップがあることがわかります。これは REDO の大量生成が原因である可能性があります。過去 1 時間に生成された REDO を確認して、生成状況を把握する必要があります。 SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YYYY HH24:MI:SS'; Session altered. SQL> SELECT TRUNC(COMPLETION_TIME, 'HH24') AS COMPLETION_TIME, SUM(BLOCKS * BLOCK_SIZE) / (1024 * 1024 * 1024) AS GENERATED_GB, COUNT(*) AS LOG_COUNT FROM V$ARCHIVED_LOG WHERE DEST_ID = 1 AND COMPLETION_TIME >= SYSDATE - 1/24 GROUP BY TRUNC(COMPLETION_TIME, 'HH24') ORDER BY 1; COMPLETION_TIME GENERATED_GB LOG_COUNT --------------------- -------------- ---------- 05-JAN-2026 17:00:00 2.54819012 21 05-JAN-2026 18:00:00 40.2287965 326 SQL> これは、過去 1 時間に 40 GB の REDO が生成されたことを示しています。分析に応じて COMPLETION_TIME フィルターを適宜変更してください。 注: アラートログが、ORA-16055: FAL request rejected や ORA-16401: archivelog rejected by RFS のように、レプリカ遅延が発生している理由に関する重要な手がかりを与えてくれることがあります。そのような場合は、関連する My Oracle Support ノートを確認して次のステップを判断してください。 ステップ 5: プライマリインスタンスのメトリクスを分析する 1 月 5 日 17:50～18:00 UTC のこのシナリオでは、DBI アラームが自動的に次を捕捉しました。 読み取りおよび書き込みレイテンシーが 10 ミリ秒を超過。 DB Load Analysis は、最も CPU (5 vCPU) を消費している UPDATE ステートメントを示しています。 Top Waits セクションは、レプリカ遅延が始まった時間帯にデータベースで発生した上位 2 つの待機イベントとして、log file switch (checkpoint incomplete) と log file switch completion を示しています。 Database Telemetry Metrics は、17:55 UTC 頃に I/O 操作が大きくスパイクしたことを示しています。 CloudWatch メトリクスは、読み取り + 書き込み IOPS が Amazon RDS プライマリデータベースに割り当てられた 3,000 IOPS を超えていることを裏付けています。 ステップ 6: Database Insights でリードレプリカを分析する 1 月 5 日 17:50～18:00 UTC のリードレプリカを DBI で確認します。 上位の SQL は unknown と表示されています。これは通常、リソースを消費しているプロセスが SQL_ID を持たない場合に発生します。このような状況では、リソースを消費している OS プロセスのプロセス ID (PID) を特定し、そのプロセスが何を実行しているかを調べられます。 ステップ 7: CPU を最も消費しているプロセスを特定する 消費しているプロセスを特定するには、次の手順に従います。 [Database Telemetry] → [OS Processes] に移動します。 CPU % で並べ替えます。 このシナリオでは、CPU を最も消費しているプロセスは ora_pr00_ORCL で、プロセス ID は 751957、CPU を 3.31% 消費しています。このプロセス名は、ターゲット上で REDO ログの変更を並列に適用する Parallel Recovery (PR) ワーカープロセスであることを示しています。 ステップ 8: 問題を修正または緩和するための推奨アクション ストレージ負荷に対応するため EBS IOPS を増やす。 ログスイッチ頻度を減らすため REDO ログサイズを増やす。 バースト処理に必要であれば REDO ログループを追加する。 変更を実施する前に、アプリケーションチームおよびビジネスチームと連携して負荷パターンを確認する。 シナリオ: リードレプリカでの適用側のボトルネック 次のシナリオでは、プライマリやネットワークではなく、リードレプリカの適用パスのボトルネックによって生じるレプリカ遅延を特定する方法を示します。この例では、プライマリで大量の UPDATE ワークロードが実行されており、それがリードレプリカでの適用 I/O 需要を押し上げています。 ステップ 1: ReplicaLag と ReplicaTransportLag を比較する リードレプリカインスタンスの [Monitoring] タブに移動し、同じ時間帯の ReplicaLag と ReplicaTransportLag を並べて表示します。 この例では、ReplicaLag は 2026-05-02 15:00 UTC に増加し始め、約 2 時間まで拡大する一方で、ReplicaTransportLag は終始 35 秒未満にとどまっています。前のシナリオの比較表によれば、このパターン (TransportLag が正常で ApplyLag が高い) は、リードレプリカでの適用プロセスのボトルネックを示しています。 ステップ 2: データベースレベルで遅延パターンを確認する リードレプリカで V$DATAGUARD_STATS をクエリして、CloudWatch のビューを裏付けます。 SQL> SELECT NAME, VALUE, DATUM_TIME FROM V$DATAGUARD_STATS 2 WHERE NAME IN ('transport lag', 'apply lag'); NAME VALUE DATUM_TIME --------------- ----------------- ------------------- transport lag +00 00:00:00 05/03/2026 03:23:47 apply lag +00 02:01:05 05/03/2026 03:23:47 転送遅延がゼロである一方で適用遅延は 2 時間を超えており、ボトルネックが適用側にあることを裏付けています。 プライマリの現在のログシーケンスと、リードレプリカで MRP が適用しているシーケンスを比較します。 -- On the primary SQL> SELECT thread#, MAX(sequence#) FROM v$log_history GROUP BY thread#; THREAD# MAX(SEQUENCE#) --------- -------------- 1 97565 -- On the Read Replica SQL> SELECT PROCESS, STATUS, SEQUENCE#, BLOCK# 2 FROM V$MANAGED_STANDBY WHERE PROCESS = 'MRP0'; PROCESS STATUS SEQUENCE# BLOCK# --------- ------------- ----------- ---------- MRP0 APPLYING_LOG 97540 90708 MRP はプライマリより 25 のログシーケンス遅れており、 V$DATAGUARD_STATS が報告する 2 時間の適用遅延と一致します。 ステップ 3: Database Insights でリードレプリカの待機イベントを分析する Database Insights でリードレプリカを開き、同じ時間帯の Waits で分割した Database load を確認します。 15:00 UTC 以降、平均アクティブセッションは約 6 に跳ね上がり、I/O 関連の待機が大半を占めています。control file sequential read、checkpoint completed、db file async I/O submit、parallel recovery read buffer free、Data Guard server operation complete などです。これらはすべて適用 / メディアリカバリのパス上にあり、リードレプリカが REDO の変更を十分な速さで永続化できていないことを示しています。 ステップ 4: リードレプリカのストレージメトリクスを確認する ReplicaLag が増加し始めたのと同じ時刻の、リードレプリカボリュームの BurstBalance と WriteIOPS を確認します。 BurstBalance は 14:59 UTC に 0% まで低下し、WriteIOPS は 15:00 UTC 以降、約 300 で頭打ちになっています。ReplicaLag も同じ分に上昇し始めます。gp2 ボリュームがバーストクレジットを使い果たし、ベースライン IOPS にスロットリングされたため、MRP と並列リカバリワーカーはすべての書き込みで待機せざるを得なくなっています。 ステップ 5: 根本原因 REDO はリードレプリカに正常に送信されていますが (ReplicaTransportLag は低い)、ボリュームがバーストクレジットを使い果たすと、レプリカのストレージが適用 I/O に追従できなくなります。このため、未適用の REDO によるバックログが増大します。 ステップ 6: 問題を修正または緩和するための推奨アクション リードレプリカのストレージを、持続的な適用ワークロードに合わせてサイジングしたプロビジョンド IOPS を備える gp3 または io1/io2 に切り替えるか、gp2 ボリュームのサイズを増やしてベースライン IOPS をレプリカの適用レート以上に引き上げます。 リードレプリカのストレージをプライマリとは独立してサイジングします。持続的な適用には、プライマリのワークロードと同等かそれ以上の書き込みスループットが必要になることがあります。 BurstBalance と ReplicaLag に CloudWatch アラームを設定し、クレジットが枯渇する前に通知を受け取れるようにします。 クリーンアップ 本記事に沿って AWS リソースをデプロイしたり設定を変更したりした場合は、それらの変更を必ず削除または元に戻してください。 まとめ Amazon RDS for Oracle リードレプリカのレプリケーション遅延は、アプリケーションのパフォーマンスと災害対策の準備態勢に影響を与える可能性があります。Database Insights と拡張モニタリングを有効にし、一般的な待機イベントを理解し、本記事で説明したトラブルシューティングの手法に従うことで、根本原因を素早く特定し、適切な対策を実施できます。これらの手法で解決しない複雑なシナリオについては、AWS Support または Oracle ベンダーサポートに連絡して追加の支援を受けてください。 著者について Jobin Joseph トロントを拠点とするシニアデータベーススペシャリストソリューションアーキテクトです。リレーショナルデータベースエンジンを専門とし、お客様のデータベースワークロードの AWS への移行とモダナイゼーションを支援しています。Oracle Certified Master であり、Oracle データベースに関して 25 年以上の経験を持っています。 Manoj Ponnurangam Amazon Web Services のシニアクラウドデータベースエンジニアです。Amazon RDS for Oracle、Amazon RDS for PostgreSQL、Amazon Aurora for PostgreSQL、AWS DMS の Subject Matter Expert です。リレーショナルデータベースに関して 15 年の経験を持ち、さまざまなデータベースおよび移行プロジェクトでお客様にガイダンスと技術支援を提供しています。 Deepak Mani AWS のシニアテクニカルアカウントマネージャーで、データベース技術に関してお客様と協働してきた業界経験が 17 年以上あり、そのうち 6 年以上を AWS でネットワーキング、ストレージ、データベースを担当してきました。Amazon RDS for Oracle と Amazon RDS インフラストラクチャの Subject Matter Expert として、エンタープライズのお客様と連携し、戦略的なガイダンスと予防的なサポートを通じて、運用の卓越性の推進、耐障害性の向上、クラウドジャーニーの加速を支援しています。 この記事はSolutions Architect の 矢木 覚 が翻訳しました。

本記事は 2026 年 6 月 25 日 に公開された「 Centralized traffic inspection for Oracle Database@AWS 」を翻訳したものです。 前回の記事「 Implement network connectivity patterns for Oracle Database@AWS 」では、3 つの接続パターンを紹介しました。アプリケーション VPC と Oracle Database@AWS ネットワーク間の直接ピアリング、 AWS Transit Gateway を使用した単一リージョン接続、 AWS Cloud WAN を使用したマルチリージョン接続の 3 つです。アプリケーション VPC、オンプレミスネットワーク、Oracle Database@AWS ネットワーク間のトラフィックや、インターネット向けの送信トラフィックのいずれも検査が必要です。本記事では、トラフィックを宛先に到達する前に専用の検査 VPC を経由させる 2 つの集中検査パターンを説明します。1 つは AWS Transit Gateway を使用するパターン、もう 1 つは AWS Cloud WAN のサービス挿入を使用するパターンです。 Oracle Database@AWS は、AWS データセンター内の専用 Oracle Exadata インフラストラクチャ上で Oracle Cloud Infrastructure (OCI) が管理する Oracle Exadata Database Service と Oracle Autonomous Database へのアクセスを提供するサービスです。金融、ヘルスケア、官公庁などの規制産業では、侵入検知・防止 (IDS/IPS)、データ損失防止 (DLP)、ドメインフィルタリングなどの目的でデータベースとの間を流れるネットワークトラフィックの検査が求められることがあります。 前提条件 前回の接続パターンの記事 で解説した ODB ネットワーク、ODB ピアリング、ピアリングされた CIDR、ODB トランジット VPC の概念を理解しておく必要があります。AWS Transit Gateway または AWS Cloud WAN に接続されたトランジット VPC にピアリングされた ODB ネットワークが必要です。また、 AWS Cloud WAN サービス挿入の概念 や、 Amazon Virtual Private Cloud (Amazon VPC) のルートテーブル、サブネット、 NAT ゲートウェイ 、インターネットゲートウェイといった概念にも精通している必要があります。 重要: 現時点では、ODB トランジット VPC にファイアウォールエンドポイントを直接デプロイできません。トランジット VPC 自身の CIDR 外のアドレス宛てのトラフィックは、サブネットルートテーブルの検索を完全にバイパスして Transit Gateway または AWS Cloud WAN アタッチメント経由で直接転送されます。一部のユースケースでは個別のアプリケーション VPC にファイアウォールエンドポイントをデプロイできますが、この分散型アプローチはルートテーブル設定のオーバーヘッドが増大し、すべての VPC で繰り返す必要があるため、大規模環境では集中検査が実用的な選択肢です。 パターン 1: AWS Transit Gateway による集中トラフィック検査 図 1 のように、このパターンでは ODB ネットワーク、ODB ネットワークとピアリングされた ODB トランジット VPC、アプリケーション VPC、集中検査 VPC (ファイアウォールエンドポイント、NAT ゲートウェイ、インターネットゲートウェイ)、オンプレミスネットワークを Transit Gateway にアタッチメントとして接続します。オンプレミス接続には AWS Direct Connect または AWS Site-to-Site VPN を使用します。Transit Gateway は 2 つのルートテーブルでトラフィックを制御します。検査前ルートテーブルはスポークアタッチメント (アプリケーション VPC、オンプレミス、ODB トランジット VPC) に関連付けられ、デフォルトルート (0.0.0.0/0) が検査 VPC アタッチメントを指します。検査後ルートテーブルは検査 VPC アタッチメントに関連付けられ、アプリケーション VPC CIDR、オンプレミス CIDR、ODB ネットワーク CIDR への個別ルートがそれぞれのアタッチメントを指します。 図 1: Transit Gateway と集中検査 VPC を使用した東西・南北トラフィック検査 東西トラフィックフローのパケットウォークスルー 以下は東西トラフィックフロー (図 1 の ‘a’ / オレンジ色) の手順です。 アプリケーション VPC 内の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスが Oracle データベースのホスト名を解決し、ODB ネットワーク CIDR 内の IP アドレスで接続を開始します。 アプリケーション VPC のサブネットルートテーブルには ODB ネットワーク CIDR (またはデフォルトルート) が Transit Gateway を指すルートがあります。パケットはアプリケーション VPC アタッチメント経由で Transit Gateway に転送されます。 Transit Gateway は検査前ルートテーブル (アプリケーション VPC アタッチメントに関連付けられたもの) でルートテーブル検索を実行します。デフォルトルートが検査 VPC アタッチメントを指しているため、パケットは検査 VPC に転送されます。 検査 VPC の Transit Gateway アタッチメントサブネットにパケットが到着します。サブネットルートテーブルにより、パケットは検査のためファイアウォールエンドポイントにルーティングされます。 検査アプライアンスがセキュリティポリシーに従ってパケットを処理します。検査を通過した場合、サブネットルートテーブルにより検査後のトラフィックは Transit Gateway に戻されます。 Transit Gateway は検査後ルートテーブル (検査 VPC アタッチメントに関連付けられたもの) を参照します。ODB ネットワーク CIDR への個別ルートが ODB トランジット VPC アタッチメントを指しており、パケットはそこに転送されます。 ODB トランジット VPC のサブネットルートテーブルがパケットを ODB ピアリング接続にルーティングします。パケットは ODB ピアリングを経由して ODB ネットワークに入り、Oracle データベースに到達します。 ODB ネットワークからのレスポンストラフィックは対称的な逆パスをたどります。 南北トラフィックフロー (インターネット送信トラフィック) のパケットウォークスルー Oracle データベースワークロードがインターネットアクセスを必要とする場合、インターネットに出る前に集中検査 VPC 経由でトラフィックをルーティングできます。ODB@AWS からのインターネットエグレスは OCI 側または AWS 側のいずれかで可能です。本記事では AWS 側のエグレスパターンを扱います。このパターンでは、ODB ネットワーク上のピアリングされた CIDR プレフィックスリストに特定の宛先 CIDR を設定する必要があります。詳細は「 Oracle DB@AWS Internet Outbound Traffic blog 」を参照してください。 以下は南北トラフィックフロー (図 1 の ‘b’ / 緑色) の手順です。 ODB ネットワークからのインターネット宛てトラフィックが、OCI 側のピアリングされた CIDR プレフィックスリストで設定されたルートに一致し、次のホップとして ODB ピアリング接続にパケットを転送します。パケットは ODB トランジット VPC に入ります。 パケットは ODB トランジット VPC アタッチメント経由で Transit Gateway に転送されます。 Transit Gateway は検査前ルートテーブルでルートテーブル検索を実行します。デフォルトルートが検査 VPC アタッチメントを指しているため、パケットは検査 VPC に転送されます。 パケットは検査 VPC に到着し、検査のためファイアウォールエンドポイントにルーティングされます。 検査後、パケットは NAT ゲートウェイにルーティングされ、ソースアドレス変換が行われます。 NAT ゲートウェイがパケットをインターネットゲートウェイに転送し、インターネットに送出します。 インターネットからの戻りトラフィックは、インターネットゲートウェイ、NAT ゲートウェイ、ファイアウォール、Transit Gateway を経由し、ODB トランジット VPC を通じて ODB ネットワークに戻る逆パスをたどります。 パターン 2: AWS Cloud WAN による集中トラフィック検査 図 2 のように、アプリケーション VPC とオンプレミスネットワークは AWS Cloud WAN コアネットワークにアタッチされ、それぞれのセグメント (App VPC と Hybrid) にマッピングされます。検査 VPC アタッチメントは ネットワーク機能グループ (NFG) にマッピングされます。Transit Gateway は TGW ルートテーブルアタッチメントを介して ODB トランジット VPC と AWS Cloud WAN コアネットワーク間の接続を提供します。ODB ネットワーク CIDR への静的ルートが Transit Gateway 上の ODB トランジット VPC アタッチメントを指しており、この TGW ルートテーブルは Cloud WAN TGW ルートテーブルアタッチメントに関連付けられています。これにより ODB CIDR が BGP 経由で Cloud WAN のセグメントおよび NFG ルートテーブルに動的に伝播されます。 この構成により、Cloud WAN のサービス挿入アクションがトラフィックを検査 NFG 経由で制御します。東西フローには send-via アクション、南北フローには send-to アクションを使用します。以降のセクションで詳しく説明します。 東西トラフィックフロー (send-via アクション) 図 2: AWS Cloud WAN のサービス挿入を使用した東西トラフィック検査 send-via アクションは ODB Network セグメントと App VPC セグメント (およびオンプレミストラフィック用の hybrid セグメント) の間に、検査 NFG を経由するよう設定されます。 以下は東西トラフィックフロー (図 2 の ‘c’) の手順です。 アプリケーション VPC 内の Amazon EC2 インスタンスが Oracle データベースのホスト名を解決し、データベース接続を開始します。 アプリケーション VPC のサブネットルートテーブルには ODB ネットワーク CIDR が AWS Cloud WAN コアネットワークアタッチメントを指すルートがあります。パケットは AWS Cloud WAN コアネットワークに転送されます。 App VPC セグメント (またはオンプレミストラフィックの hybrid セグメント) と ODB Network セグメント間に send-via アクションが設定されています。AWS Cloud WAN のルーティングテーブルがパケットを NFG アタッチメント経由で検査 VPC に転送します。 パケットは検査 VPC に到着し、検査のためファイアウォールエンドポイントにルーティングされます。 検査後、パケットは検査 VPC を出て NFG アタッチメント経由で AWS Cloud WAN コアネットワークに再入します。 AWS Cloud WAN は検査後のトラフィックを Transit Gateway ルートテーブルアタッチメントにルーティングします。Transit Gateway から BGP で動的に伝播された ODB ネットワーク CIDR がそこに存在します。 Transit Gateway がパケットを ODB トランジット VPC に転送します。ODB トランジット VPC のサブネットルートテーブルがパケットを ODB ピアリング接続経由で ODB ネットワークにルーティングし、Oracle データベースに到達します。 戻りトラフィックは対称的な逆パスをたどります。send-via アクションは双方向で、ODB ネットワークからのトラフィックもアプリケーション VPC に到達する前に同じ検査 VPC を通過します。 オンプレミストラフィックも同じパターンに従います。hybrid セグメントで Direct Connect または AWS Site-to-Site VPN アタッチメントを通じて AWS Cloud WAN に入り、ODB ネットワークに到達する前に検査 VPC を通過します。 南北トラフィックフロー (インターネット送信トラフィックの send-to アクション) 図 3: AWS Cloud WAN のサービス挿入を使用した南北インターネット送信トラフィック検査 図 3 のように、ODB Network セグメントに検査 NFG を指す send-to アクションが設定されています。ODB@AWS からのインターネットエグレスは OCI 側または AWS 側のいずれかで可能です。本記事では AWS 側のエグレスパターンを扱います。ODB ネットワークからのインターネット宛てトラフィックは検査 VPC に誘導され、検査後に NAT ゲートウェイとインターネットゲートウェイを経由してインターネットに出ます。パターン 1 と同様に、ピアリングされた CIDR プレフィックスリストに特定の宛先 CIDR を設定する必要があります。 以下はこのフロー (図 3 の ‘d’) の手順です。 ODB ネットワークからのインターネット宛てトラフィックが、OCI 側のピアリングされた CIDR プレフィックスリストで設定されたルートに一致し、次のホップとして ODB ピアリング接続にパケットを転送します。パケットは ODB トランジット VPC に入ります。 ODB トランジット VPC がパケットを Transit Gateway に転送します。Transit Gateway は TGW ルートテーブルアタッチメント経由で AWS Cloud WAN コアネットワークにパケットを送信します。 ODB Network セグメントに send-to アクションが設定されているため、AWS Cloud WAN のルーティングテーブルがインターネット宛てパケットを NFG アタッチメント経由で検査 VPC に転送します。 パケットは検査 VPC に到着し、検査のためファイアウォールエンドポイントにルーティングされます。 検査を通過したパケットは NAT ゲートウェイに転送されます。NAT ゲートウェイがソース NAT を実行し、インターネットゲートウェイにパケットを転送してインターネットに送出します。 インターネットからの戻りトラフィックはインターネットゲートウェイに到着し、NAT ゲートウェイでアドレス変換を経てファイアウォールに戻り検査されます。検査後、パケットは NFG アタッチメント経由で AWS Cloud WAN コアネットワークに再入します。NFG ルートテーブルには TGW ルートテーブルアタッチメントを指す ODB ネットワーク CIDR の伝播ルートがあり、パケットは Transit Gateway、ODB トランジット VPC を経由して ODB ネットワークに戻ります。 これらのパターンはマルチリージョンデプロイメントにも拡張できます。リージョン VPC、Transit Gateway、検査インフラストラクチャを同じ AWS Cloud WAN コアネットワークにアタッチすることで、追加リージョンをオンボードできます。 考慮事項 Oracle Database@AWS のネットワーク検査を実装する際は、以下の考慮事項を念頭に置いてください。 ODB ピアリングされた CIDR – ピアリングされた CIDR リストは、ピアリング接続を通じて ODB ネットワークと通信可能なすべての CIDR を定義します。東西トラフィックの場合、アプリケーション VPC CIDR (プライマリおよびセカンダリ) とオンプレミスネットワーク CIDR を含めます。AWS 経由で出る南北インターネット宛てトラフィックの場合、データベースが到達する必要がある特定のインターネット宛先 CIDR を含めます。本記事の執筆時点では 0.0.0.0/0 エントリは許可されていないため、ピアリングされた CIDR の制限に準拠する個別の CIDR 範囲にインターネット宛先を分割する必要があります。検査は透過的でオリジナルのソース IP を保持するため、検査 VPC CIDR を含める必要はありません。ピアリングされた CIDR の設定と制限については「 Oracle DB@AWS Internet Outbound Traffic 」を参照してください。 フロー対称性のためのアプライアンスモード – 検査 VPC の Transit Gateway アタッチメント (パターン 1) または AWS Cloud WAN アタッチメント (パターン 2) で アプライアンスモード を有効にしてください。有効にしないと、往路と復路が異なるアベイラビリティゾーンを通過し、ステートフル検査が破綻する可能性があります。 AWS Network Firewall ネイティブ Transit Gateway アタッチメント – AWS Network Firewall は専用の検査 VPC なしで東西検査を行うネイティブ Transit Gateway アタッチメントをサポートしています。南北の送信トラフィックには NAT ゲートウェイを備えた別の VPC が引き続き必要です。 DNS トラフィックパス – ODB ネットワークへの DNS クエリはデータトラフィックと同じ検査パスを通ります。ファイアウォールルールで考慮するか、検査をバイパスするために ODB トランジット VPC に Amazon Route 53 Resolver アウトバウンドエンドポイントを配置してください。 マルチリージョンデプロイメント – クロスリージョンのレイテンシーとデータ転送コストを回避するため、各リージョンに検査 VPC をデプロイしてください。パターン 2 では、AWS Cloud WAN の機能 (シングルホップモード) でどのリージョンの検査 VPC を使用するかを制御できます。 まとめ 本記事では、Oracle Database@AWS に対する集中ネットワークトラフィック検査を実装する方法を紹介しました。単一リージョンデプロイメントでは AWS Transit Gateway と集中検査 VPC を、マルチリージョンアーキテクチャでは AWS Cloud WAN のサービス挿入を使用します。ODB トランジット VPC はインライン検査をサポートしないため、どちらのアプローチも専用の検査 VPC 経由でトラフィックをルーティングします。詳細は「 AWS Network Firewall のドキュメント 」、「 AWS Cloud WAN サービス挿入のドキュメント 」、「 Oracle Database@AWS ユーザーガイド 」を参照してください。 著者について Sameer Malik Sameer は、AWS のプリンシパルデータベースソリューションアーキテクトです。RDS と Aurora に注力し、23 年以上にわたりリレーショナルデータベースに携わってきました。多数のお客様のデータベースワークロード移行・モダナイゼーションを支援しています。 Anvesh Koganti Anvesh は、AWS のソリューションアーキテクトで、ネットワーキングを専門としています。高いスケーラビリティとレジリエンスを備えた AWS ネットワーキングアーキテクチャの構築を支援しています。 Shubham Singh Shubham は、AWS のシニアネットワークスペシャリストソリューションアーキテクトです。AWS サービスを活用した革新的でレジリエントかつコスト効率の高いソリューション設計を支援しています。ネットワーキングとセキュリティ分野でのソリューション構築に注力し、Northeastern 大学でコンピュータネットワーキング専攻のテレコミュニケーションシステム管理修士号を取得しています。 Vihar Kodakandla Vihar は、AWS のドメインスペシャリストエンジニアです。UOps のお客様に対し、オンボーディング、コンテキスト構築、Critical Workload Review を通じたプロアクティブなメカニズムの提供に注力しています。複雑な技術的課題のトラブルシューティングや、AWS ネットワーキングサービス全体のレジリエンスとオブザーバビリティ向上の機会特定を支援しています。 この記事は Solutions Architect の 矢木 覚 が翻訳しました。

本記事は 2026 年 6 月 11 日 に公開された「 Provision Oracle Database@AWS resources using Terraform 」を翻訳したものです。 本記事では、 Terraform を使用して Oracle Database@AWS の主要コンポーネント（ ODB ネットワーク 、 Oracle Exadata インフラストラクチャ 、 Exadata VM クラスター 、 Autonomous VM クラスター ）をプロビジョニングする方法を紹介します。 Oracle Database@AWS （ODB@AWS）は、 Oracle Cloud Infrastructure（OCI） が管理する Oracle Exadata インフラストラクチャを AWS データセンター内から提供するサービスです。Oracle Database@AWS を使用すると、Oracle データベースを AWS に移行しながら、Exadata の高パフォーマンス、スケーラビリティ、高度な機能を活用できます。Oracle Database@AWS は、 Amazon Simple Storage Service（Amazon S3） 、 zero-ETL パイプライン、 AWS Key Management Service（AWS KMS） などの AWS サービスと密に統合されています。Oracle データベースは、Amazon Elastic Compute Cloud（Amazon EC2）、Amazon Elastic Container Service（Amazon ECS）、Amazon Elastic Kubernetes Service（Amazon EKS）などにデプロイされたアプリケーションと並行して動作します。この密な統合により、データフローが簡素化され、セキュリティが強化され、多様なコンピューティング環境でのアプリケーション開発が加速します。 現在、Oracle Database@AWS では以下の Oracle Database サービスが提供されています： Oracle Autonomous AI Database on Dedicated Exadata Infrastructure （ADB-D） Oracle Exadata Database Service on Dedicated Infrastructure （ExaDB-D） Infrastructure as Code（IaC）は、構成ファイルを通じてアプリケーションのインフラストラクチャをプロビジョニング・管理するプロセスです。IaC を使用すると、インフラストラクチャ管理を一元化し、リソースを標準化し、迅速にスケールできます。新しい環境を再現可能で、信頼性が高く、一貫性のある状態で構築できます。Oracle Database@AWS のリソースは、 Terraform や AWS CloudFormation などの IaC ツールでデプロイできます。 HashiCorp Terraform は、クラウドとオンプレミスのリソースを、バージョン管理・再利用・共有が可能な人間が読める構成ファイルで定義できる IaC ツールです。一貫したワークフローで、ライフサイクル全体を通じてインフラストラクチャをプロビジョニング・管理できます。 本ウォークスルーは、Oracle Database@AWS のプロビジョニングを自動化したいデータベース管理者や DevOps エンジニアを対象としています。 ソリューション概要 Oracle Database@AWS を使い始めるには、 AWS Marketplace のリスティングを確認します。サービスを利用するには、 オンボーディング と呼ばれるプロセスで AWS アカウント内の構成を行います。オンボーディングを開始するには、Oracle の担当者に連絡してプライベートオファーをリクエストします。価格、利用条件に合意した後、AWS Marketplace で購入を完了します。購入完了後、AWS アカウントと OCI テナンシーをリンクします（マルチクラウドリンク）。要件に応じて、 エンタイトルメント共有機能 を使用して、同じ AWS Organization 内の AWS アカウント間で ODB@AWS の AWS Marketplace エンタイトルメントを共有できます。オンボーディング完了後、Exadata Database Service on Dedicated Infrastructure および Autonomous AI Database on Dedicated Exadata Infrastructure 用の Oracle Database@AWS システムリソースのプロビジョニングを開始できます。プロビジョニングは ODB ネットワークと Exadata インフラストラクチャの作成から始まります。ワークロードと要件に基づいて、Exadata VM クラスターまたは Autonomous VM クラスターを作成します。Exadata VM クラスターは Oracle Exadata Database Service をサポートし、Autonomous VM クラスターは Autonomous AI Database on Dedicated Exadata Infrastructure をサポートします。 Oracle Database@AWS の利用を開始するには、Oracle Database@AWS コンソール、AWS Command Line Interface（AWS CLI）、または API を使用して以下のリソースを作成します： ODB ネットワーク Oracle Exadata インフラストラクチャ Exadata VM クラスターまたは Autonomous VM クラスター ODB ピアリング接続 次の図は Oracle Database@AWS のアーキテクチャを示しています。 以下のセクションでは、Oracle Database@AWS のアーキテクチャと主要コンポーネントについて説明します。 Amazon Virtual Private Cloud とサブネット ： Amazon Virtual Private Cloud（Amazon VPC）では、定義した仮想ネットワークに AWS リソースを起動できます。この仮想ネットワークは、自社データセンターで運用する従来のネットワークと同様ですが、AWS のスケーラブルなインフラストラクチャを活用できます。VPC を作成した後、サブネットを追加できます。サブネットは Amazon VPC 内の IP アドレス範囲です。特定のサブネットに Amazon EC2 インスタンスなどの AWS リソースを作成できます。 OCI Virtual Cloud Network（VCN）とサブネット ： Virtual Cloud Network（VCN）は、指定した Oracle リージョン内の OCI テナンシーに設定するカスタマイズ可能なプライベートネットワークです。コンピュートインスタンス、データベース、ストレージなどの OCI リソースをデプロイ・管理するための、安全でスケーラブルなネットワーク環境を提供します。VCN により、論理的に分離されたネットワーク内でクラウドリソースを隔離・セグメント化し、セキュリティと管理性を向上できます。Oracle マルチクラウドアーキテクチャでは、AWS リージョン内にクライアントサブネットとバックアップサブネットを持つ ODB ネットワークを作成すると、対応する OCI VCN とサブネットが OCI テナンシーに自動的に作成されます。VCN はペアリングされた OCI リージョンに作成されます。詳細については、「 Overview of VCNs and Subnets 」を参照してください。 OCI リージョン（親サイト）： OCI リージョンは、アベイラビリティドメインと呼ばれる 1 つ以上のデータセンターがある地理的エリアです。Oracle マルチクラウドモデルでは、ペアリングされた AWS リージョンに接続された OCI リージョンを親サイトと呼びます。ODB@AWS は「 Regional Availability 」で説明されているリージョンでのみ利用可能です。 OCI 子サイト ： OCI 子サイトは、OCI アベイラビリティドメイン（AD）を AWS リージョン内のアベイラビリティゾーン（AZ）に拡張するデータセンターです。OCI 子サイトモデルでは、Oracle Database@AWS で使用される Exadata インフラストラクチャは物理的には AWS データセンター（AWS リージョン内の AZ）に配置されますが、論理的には OCI リージョンとそのネットワークコンポーネントにマッピングされます。 ODB ネットワーク ： ODB ネットワークは、指定した AWS アベイラビリティゾーン（AZ）内で Oracle Exadata VM クラスターと Autonomous VM クラスターをホストするプライベートで分離されたネットワークです。ODB ネットワークは IP アドレスの CIDR 範囲で構成されます。ODB ネットワークは OCI 子サイト内のネットワークに直接マッピングされ、AWS と OCI 間の通信を実現します。Oracle マルチクラウドアーキテクチャでは、ODB ネットワークが Oracle Database@AWS サービスの OCI コンポーネントにネットワーク接続を提供します。 ODB ネットワークの作成時に、以下の情報を指定します： アベイラビリティゾーン — ODB ネットワークは特定の AZ に紐づきます。サポートされるリージョンとアベイラビリティゾーンの最新リストは「 Regional Availability 」を参照してください。アカウント内の論理 AZ 名と物理 AZ ID のマッピングを確認するには、次のコマンドを実行します。 aws ec2 describe-availability-zones \ --region us-east-1 \ --query "AvailabilityZones[*].{ZoneName:ZoneName, ZoneId:ZoneId}" \ --output table クライアント CIDR アドレス — ODB ネットワークには、Exadata VM クラスターと Autonomous VM クラスター用の クライアントサブネット CIDR が必要です。 バックアップ CIDR アドレス — ODB ネットワークには、VM クラスターのマネージドデータベースバックアップ用の バックアップサブネット CIDR が必要です。バックアップサブネットは Exadata VM クラスターではオプションです。 AWS サービス統合 — Amazon S3 や Amazon Redshift との zero-ETL など、AWS サービス統合用のネットワークパスを構成できます。詳細については「 AWS service integrations 」を参照してください。CIDR 要件の詳細については「 ODB Network creation 」を参照してください。 Oracle Exadata インフラストラクチャ ： Oracle Exadata インフラストラクチャは、Oracle データベースを実行するために設計された高パフォーマンスの統合ハードウェア・ソフトウェアプラットフォームです。Oracle マルチクラウドアーキテクチャでは、Exadata インフラストラクチャは Oracle Exadata Database Service と Oracle Autonomous AI Database の両方の基盤ハードウェアです。 Oracle Database@AWS で Exadata インフラストラクチャを作成する際に、以下の情報を指定します： データベースサーバーの総数 ストレージサーバーの総数 Exadata システムモデル（X11M） インフラストラクチャをホストする AZ（「 Supported Regions for Oracle Database@AWS 」を参照） 詳細については「 Exadata Infrastructure 」を参照してください。 Exadata VM クラスター ：Exadata VM クラスターは、密結合された Exadata VM のセットです。各 VM には、Oracle Real Application Clusters（Oracle RAC）や Oracle Grid Infrastructure などの Oracle Enterprise Edition の機能を含む、完全な Oracle データベースインストールがあります。VM クラスター上に 1 つ以上の Oracle Exadata データベースを作成できます。 VM と VM クラスターのアーキテクチャ図については「 Exadata Database Service on Dedicated Infrastructure Technical Architecture 」を参照してください。 VM クラスターの作成時に、以下の情報を指定します： ODB ネットワーク Oracle Exadata インフラストラクチャ クラスター内の VM を配置するデータベースサーバー 使用可能な Exadata ストレージの合計容量 詳細については「 Exadata VM Cluster 」を参照してください。 Autonomous VM クラスター ：Autonomous VM クラスター（AVMC）を使用すると、物理的な Exadata クラスター（マシン）を複数の仮想クラスターにパーティション分割できます。アクセスルール、ネットワーク構成、コンピューティング・メモリ・ストレージリソースのカスタマイズにより、データベースワークロードごとに環境を分離できます。Autonomous VM クラスターの作成時に、VM あたりの ECPU コア数、CPU あたりのデータベースメモリ、データベースストレージ、Autonomous コンテナデータベースの最大数を構成できます。詳細については「 Create Autonomous VM Cluster 」を参照してください。 ODB ピアリング ： ODB ピアリングは、Amazon VPC と ODB ネットワーク間でトラフィックをプライベートにルーティングするネットワーク接続です。Oracle マルチクラウドアーキテクチャでは、VPC 内のアプリケーションと ODB ネットワーク内の Oracle データベース間のトラフィックは、パブリックインターネットを経由せず ODB ピアリングを通じてプライベートにルーティングされます。詳細については「 creating ODB peering connection 」を参照してください。 Oracle Exadata データベース ：Oracle Database@AWS では、AWS コンソールを使用して Exadata データベースをホストする Oracle Exadata インフラストラクチャと VM クラスターを作成します。その後、OCI API を使用して Oracle データベースを作成・管理します。データベースの作成方法の詳細については「 Exadata Database 」および「 Autonomous Database 」を参照してください。 Oracle Database@AWS のコンポーネントの詳細については「 Architecture 」を参照してください。 上記リソースの作成手順の詳細については「 creating resources in your Oracle Database@AWS 」を参照してください。 前提条件 開始する前に、以下の前提条件を確認してください： Terraform の基本的な理解 Oracle Database@AWS の概要の理解 「 Onboarding to Oracle Database@AWS 」の手順の完了。Oracle Database@AWS を使用するにはプライベートオファーを受け入れている必要があります。 AWS Identity and Access Management（IAM）プリンシパルに「 Allow users to provision Oracle Database@AWS resources 」に記載されたポリシー権限を付与。Oracle Database@AWS を使用するにはこれらの権限が必要です。 以下の Terraform テンプレートを使用して、Oracle Database@AWS のさまざまなリソースをプロビジョニングできます。ビジネス要件に応じてパラメータをカスタマイズしてください。テンプレートを適用する前に、各パラメータの意味と許容値を理解してください。 Oracle Database@AWS リソースのプロビジョニング用に以下のテンプレートが利用可能です。最新情報については「 Provisioning Oracle Database@AWS through Terraform 」を参照してください。 ステップ 1：ODB ネットワークの作成 以下の Terraform 構成を使用して、 Oracle Database@AWS で ODB ネットワークを作成 します。 # Create an ODB Network without AWS service integrations resource "aws_odb_network" "example" { display_name = "odb-my-net" availability_zone_id = "use1-az6" client_subnet_cidr = "10.2.0.0/24" backup_subnet_cidr = "10.2.1.0/24" s3_access = "DISABLED" zero_etl_access = "DISABLED" tags = { "env" = "dev" } } # Create an ODB Network with AWS service integrations resource "aws_odb_network" "example" { display_name = "odb-my-net" availability_zone_id = "use1-az6" client_subnet_cidr = "10.2.0.0/24" backup_subnet_cidr = "10.2.1.0/24" s3_access = "ENABLED" zero_etl_access = "ENABLED" tags = { "env" = "dev" } } IP アドレス要件の詳細については「 Planning IP address space in Oracle Database@AWS 」を参照してください。 ステップ 2：Oracle Exadata インフラストラクチャの作成 以下の Terraform 構成を使用して、 Oracle Database@AWS で Oracle Exadata インフラストラクチャを作成 します。 # Create an Exadata Infrastructure resource "aws_odb_cloud_exadata_infrastructure" "example" { display_name = "my-exa-infra" shape = "Exadata.X11M" storage_count = 3 compute_count = 2 availability_zone_id = "use1-az6" customer_contacts_to_send_to_oci = [{ email = "abc@example.com" }, { email = "def@example.com" }] database_server_type = "X11M" storage_server_type = "X11M-HC" maintenance_window { custom_action_timeout_in_mins = 16 days_of_week = [{ name = "MONDAY" }, { name = "TUESDAY" }] hours_of_day = [11, 16] is_custom_action_timeout_enabled = true lead_time_in_weeks = 3 months = [{ name = "FEBRUARY" }, { name = "MAY" }, { name = "AUGUST" }, { name = "NOVEMBER" }] patching_mode = "ROLLING" preference = "CUSTOM_PREFERENCE" weeks_of_month = [2, 4] } tags = { "env" = "dev" } } ステップ 3：Exadata VM クラスターまたは Autonomous VM クラスターの作成 以下の Terraform 構成を使用して、Oracle Database@AWS で Exadata VM クラスター または Autonomous VM クラスター を作成します。 # Create Exadata VM cluster with minimum parameters resource "aws_odb_cloud_vm_cluster" "with_minimum_parameter" { display_name = "my_vm_cluster" cloud_exadata_infrastructure_id = "<aws_odb_cloud_exadata_infrastructure_id>" cpu_core_count = 6 gi_version = "23.0.0.0" hostname_prefix = "apollo12" ssh_public_keys = ["public-ssh-key"] odb_network_id = "<aws_odb_network_id>" is_local_backup_enabled = true is_sparse_diskgroup_enabled = true license_model = "LICENSE_INCLUDED" data_storage_size_in_tbs = 20.0 db_servers = ["db-server-1", "db-server-2"] db_node_storage_size_in_gbs = 120.0 memory_size_in_gbs = 60 data_collection_options { is_diagnostics_events_enabled = false is_health_monitoring_enabled = false is_incident_logs_enabled = false } } # Create Exadata VM cluster with all parameters resource "aws_odb_cloud_vm_cluster" "with_all_parameters" { display_name = "my_vm_cluster" cloud_exadata_infrastructure_id = "<aws_odb_cloud_exadata_infrastructure_id>" cpu_core_count = 6 gi_version = "23.0.0.0" hostname_prefix = "apollo12" ssh_public_keys = ["my-ssh-key"] odb_network_id = "<aws_odb_network_id>" is_local_backup_enabled = true is_sparse_diskgroup_enabled = true license_model = "LICENSE_INCLUDED" data_storage_size_in_tbs = 20.0 db_servers = ["my-dbserver-1", "my-db-server-2"] db_node_storage_size_in_gbs = 120.0 memory_size_in_gbs = 60 cluster_name = "julia-13" timezone = "UTC" scan_listener_port_tcp = 1521 tags = { "env" = "dev" } data_collection_options { is_diagnostics_events_enabled = true is_health_monitoring_enabled = true is_incident_logs_enabled = true } } # Create Autonomous VM cluster with minimum parameters resource "aws_odb_cloud_autonomous_vm_cluster" "avmc_with_minimum_parameters" { cloud_exadata_infrastructure_id = "<aws_odb_cloud_exadata_infrastructure_id>" odb_network_id = "<aws_odb_network_id>" display_name = "my_autonomous_vm_cluster" autonomous_data_storage_size_in_tbs = 5 memory_per_oracle_compute_unit_in_gbs = 2 total_container_databases = 1 cpu_core_count_per_node = 40 license_model = "LICENSE_INCLUDED" # ids of db server. refer your exa infra. This is a mandatory field. Refer your cloud Exadata infrastructure for db server id db_servers = ["<my_db_server_id>"] scan_listener_port_tls = 8561 scan_listener_port_non_tls = 1024 maintenance_window { preference = "NO_PREFERENCE" } } # Create Autonomous VM cluster with all parameters resource "aws_odb_cloud_autonomous_vm_cluster" "avmc_with_all_params" { description = "my first avmc" time_zone = "UTC" cloud_exadata_infrastructure_id = "<aws_odb_cloud_exadata_infrastructure_id>" odb_network_id = "<aws_odb_network_id>" display_name = "my_autonomous_vm_cluster" autonomous_data_storage_size_in_tbs = 5 memory_per_oracle_compute_unit_in_gbs = 2 total_container_databases = 1 cpu_core_count_per_node = 40 license_model = "LICENSE_INCLUDED" db_servers = ["<my_db_server_1>", "<my_db_server_2>"] scan_listener_port_tls = 8561 scan_listener_port_non_tls = 1024 maintenance_window { days_of_week = [{ name = "MONDAY" }, { name = "TUESDAY" }] hours_of_day = [4, 16] lead_time_in_weeks = 3 months = [{ name = "FEBRUARY" }, { name = "MAY" }, { name = "AUGUST" }, { name = "NOVEMBER" }] preference = "CUSTOM_PREFERENCE" weeks_of_month = [2, 4] } tags = { "env" = "dev" } } ステップ 4：ODB ピアリング接続の作成 以下の Terraform 構成を使用して、 ODB ピアリング接続を作成 します。 resource "aws_odb_network_peering_connection" "example" { display_name = "example" odb_network_id = "my-odb-network-id" peer_network_id = "my-vpc-id" tags = { "env" = "dev" } } Terraform を使用した ODB@AWS スタックの作成 Terraform でリソースをプロビジョニングするには、以下の手順を完了します。この Terraform テンプレートは以下のリソースを作成します： VPC インターネットゲートウェイ パブリックサブネット 2 つ プライベートサブネット 2 つ パブリックルートテーブル プライベートルートテーブル パブリックルート 4 つのサブネットすべてのルートテーブル関連付け ODB ネットワーク ODB ピアリング接続 Exadata インフラストラクチャ Exadata VM クラスター Autonomous VM クラスター デプロイ前にテンプレートをよく確認してください。不要なリソースがある場合は、テンプレートを適宜修正してください。 GitHub リポジトリ をローカルマシンにクローンするか、AWS Samples からスクリプトをダウンロードします。 git clone https://github.com/aws-samples/sample-odb-launch-using-terraform GitHub README に従って前提条件を確認し、Terraform スタックをデプロイします。 terraform apply を実行する前に terraform plan を実行して、提案されたすべての変更を確認します。適用前にプラン出力で destroy や replace アクションがないか慎重に確認してください。 スタックデプロイの完了を確認します。 重要： Terraform リソースの特定のプロパティ（CpuCoreCount や DbServers など）を変更すると、Terraform はインプレース更新ではなくリソース全体を置き換えます。既存リソースを変更する前に、 Terraform ドキュメント で置き換えをトリガーするプロパティの完全なリストを確認してください。 リソースの作成後、VPC と ODB ネットワーク間の接続を構成します。以下の手順を完了してください： OdbPeeringConnection 用の VPC ルートテーブルの構成 Oracle Database@AWS 用の DNS 構成 アウトバウンドエンドポイント： ODB ネットワークに DNS クエリを送信するために必要です。 リゾルバールール： Amazon Route 53 Resolver が ODB ネットワークの DNS に転送する DNS クエリのドメイン名を指定するルールです。 詳細については「 network configuration 」を参照してください。 クリーンアップ 継続的な課金を避けるため、作成したリソース（ODB ネットワーク、Exadata インフラストラクチャ、VM クラスター）を削除してください。 Terraform スタックの一部として起動されたその他のリソースを削除するには、 GitHub README に記載された手順に従い terraform destroy を実行してください。 ODB ネットワークの削除時は、 delete_associated_resources を true に設定してください。このパラメータのデフォルトは false です。 true に設定しない場合、以前の ODB ネットワークにマッピングされた OCI VCN はそのまま残ります。 まとめ 本記事では、Terraform を使用して ODB ネットワーク、Exadata インフラストラクチャ、Exadata VM クラスター、Autonomous VM クラスターなどの Oracle Database@AWS リソースをプロビジョニングする方法を説明しました。Terraform による Infrastructure as Code を採用することで、デプロイを自動化し、環境全体で一貫性を維持し、Oracle Database@AWS スタックの管理を効率化できます。 詳細については「 Getting started with Oracle Database@AWS 」を参照してください。 著者について Javeed Javeed は、Amazon Web Services のシニアデータベーススペシャリストソリューションアーキテクトです。Amazon RDS チームで Oracle や Db2 などの商用データベースエンジンを担当しています。AWS Cloud でのリレーショナルデータベースワークロードの設計、デプロイ、最適化の支援に情熱を注いでいます。 Sharath Chandra Kampili Amazon Web Services のデータベーススペシャリストソリューションアーキテクトです。AWS RDS チームで Oracle などの商用データベースエンジンを担当しています。AWS のお客様と直接協力し、データベースプロジェクトに関するガイダンスと技術支援を提供しています。 この記事は Solutions Architect の 矢木 覚 が翻訳しました。

本記事は 2026 年 6 月 8 日 に公開された「 Oracle Database@AWS decoded: Determining the right fit for your Oracle workloads 」を翻訳したものです。 AWS は 15 年以上にわたり、Oracle ワークロードを実行するための豊富な選択肢を提供してきました。マネージドでシンプルな Amazon RDS for Oracle から、Amazon EBS io2 Block Express、gp3、 Amazon FSx for NetApp ONTAP といった複数のストレージオプションを持つ完全に柔軟な Amazon Elastic Compute Cloud (Amazon EC2) までさまざまです。これらのサービスは、Oracle Database ベースのアプリケーション (Oracle E-Business Suite、PeopleSoft、Siebel、JD Edwards)、Oracle Database 上に構築されたカスタムアプリケーション、ミドルウェアプラットフォーム (Oracle WebLogic、Oracle Fusion Middleware)、Oracle Database をデータ層とする ISV アプリケーションなど、幅広い Oracle デプロイメントで多くの組織に活用され続けています。 2025 年 7 月に一般提供が開始された Oracle Database@AWS (ODB@AWS) は、このポートフォリオに新しい選択肢を追加し、AWS アベイラビリティゾーン内に物理的にホストされる Exadata Database Service (ExaDB) と Autonomous Database (ADB) を提供します。 本記事では、AWS 上で Oracle ワークロードを運用する組織にとって Oracle Database@AWS が有力な選択肢となる主な理由を解説します。ビジネス、技術、ライセンスの各面での利点と、Amazon RDS for Oracle や Amazon EC2 といった既存の AWS の選択肢をどのように補完するかを説明します。 ODB@AWS がワークロードに適しているかを判断する 5 つの質問 詳細に入る前に、次の 5 つの質問を確認してください。いずれかに「はい」と答えられるなら、ODB@AWS を検討する価値があります。 パフォーマンスと将来への備え – 現在のワークロードは Oracle Exadata プラットフォームの機能を使用していますか、または活用できる可能性がありますか？ 事業継続性とリスク – Oracle Real Application Clusters (Oracle RAC) は、複数のサーバーが単一のデータベースにアクセスしながら Oracle Database ソフトウェアを実行できるようにし、フォールトトレランスと水平スケーラビリティを提供します。重要な業務を維持するために、フォールトトレランスとローリングパッチによるゼロダウンタイムを実現する Oracle RAC がアプリケーションに必要ですか？ キャパシティとコスト効率 – 季節的な需要に合わせて、コストの不均衡な増大なしにデータベースのキャパシティをスケールする必要がありますか？ Oracle データベースライセンスの柔軟性 – 従来の先行ライセンス費用ではなく、ワークロード需要に応じてスケールする Enterprise Edition データベースの従量課金制ライセンスモデルをお探しですか？ 注: ODB@AWS は、License Included (LI)、Bring Your Own License (BYOL)、またはワークロードごとの併用を提供しています。BYOL のお客様は、ライセンスあたり 2 倍のコアエンタイトルメントを利用できます。ODB@AWS は OCPU ベースのライセンス (コア係数 0.5) を採用しているため、Processor ライセンス 1 つで 2 OCPU (4 vCPU) をカバーでき、標準的な vCPU ベースのクラウドデプロイメントと比べてライセンス要件が半分になります。License Included では、Oracle RAC、Advanced Data Guard、Multitenant、Diagnostics & Tuning Pack を含むすべての Enterprise Edition フィーチャーパックが、追加費用なしで時間あたりの OCPU 料金にバンドルされています。 AWS 上の Oracle データベースでホストされる Oracle アプリケーションに対する明示的な認定 – 事業部門として、商用オフザシェルフ (COTS) アプリケーションとそれをホストする基盤インフラストラクチャを含めた Oracle の明示的な認定が必要ですか？Oracle Database@AWS は、Oracle E-Business Suite (Oracle EBS)、PeopleSoft、Siebel、JD Edwards EnterpriseOne、Oracle Enterprise Performance Management、Oracle Retail Applications、そして WebLogic や Fusion Middleware などの Oracle ミドルウェアプラットフォームを含む主要な Oracle エンタープライズアプリケーション向けの認定リファレンスアーキテクチャを提供しています。たとえば Oracle EBS 12.2 は、アプリケーション層を Amazon EC2 で、データベース層を ODB@AWS の Exadata で実行する構成で Oracle Database 26ai on Exadata の認定を受けています。この 認定 はこれらのデプロイパターンに対する Oracle の完全なサポートを確認するもので、COTS アプリケーションとその基盤インフラストラクチャが Oracle のサポート要件を満たしていると確信できます。詳細は Oracle AI Database@AWS FAQ を参照してください。 これらの質問は、Oracle 戦略の中で ODB@AWS がどこに位置づけられるかを評価する実践的な出発点になります。それでは、理由を詳しく見ていきましょう。 ビジネス面の利点 AWS 上で Oracle ワークロードを運用する組織にとって Oracle Database@AWS が魅力的な選択肢となる、5 つのビジネス上の利点を紹介します。 #1 – 200 以上の AWS サービスと並行して Oracle ワークロードを実行 AWS はエンタープライズ Oracle ワークロードに対して包括的な幅と深さを提供します 。コンピューティング、ストレージ、ネットワーキング、分析、AI/ML、セキュリティにわたる 200 以上のネイティブ統合されたサービスがあります。Oracle Database@AWS は技術的にはサードパーティのマネージドサービスですが、AWS Management Console、AWS Command Line Interface (AWS CLI)、AWS CloudFormation、そして Amazon Redshift (zero-ETL)、Amazon Bedrock、Amazon SageMaker AI などのサービスとのネイティブ統合が非常に深く、ファーストパーティの AWS サービスとほぼ変わらない操作性を実現しています。拡大を続けるグローバルインフラストラクチャと実績あるコンプライアンスフレームワークにより、AWS はミッションクリティカルな Oracle アプリケーションが求める信頼性とデータレジデンシーの選択肢を提供します。zero-ETL 分析から生成 AI まで続く AWS の継続的なイノベーションにより、Oracle への投資は競争力を保ち、将来にも対応できます。 #2 – AI Vector Search を備えた Oracle Database 26ai ODB@AWS は、データベースエンジンに AI Vector Search をネイティブに搭載した Oracle Database 26ai をサポートしています。AI アプリケーションを構築する組織は、別のベクトルデータベースを用意することなく、リレーショナルデータと並べてベクトル埋め込みを保存・検索できます。Exadata AI Smart Scan はベクトル処理をストレージサーバーにオフロードすることでベクトル操作を高速化し、AI ワークロードに高いパフォーマンスを提供します。詳細は Accelerate generative AI use cases with Amazon Bedrock and Oracle Database@AWS を参照してください。 Retrieval Augmented Generation (RAG) – ドキュメントの埋め込みをトランザクションデータと同じデータベースに保存し、AI の回答をエンタープライズデータに基づかせます。 セマンティック検索 – キーワードマッチングを超えて、意味と文脈に基づいてレコードを検索します。 レコメンデーションエンジン – ベクトル距離計算を使った類似度ベースのレコメンデーションを構築します。 異常検知 – ベクトル表現を使ってトランザクションデータの異常なパターンを特定します。 大規模言語モデル (LLM) を選択できる柔軟な AI アーキテクチャ Oracle Database 26ai のネイティブベクトル機能は AWS の包括的な AI/ML サービスと統合でき、ユースケースに合った大規模言語モデル (LLM) を柔軟に選択できます。Oracle AI Vector Search を Amazon Bedrock、Amazon SageMaker AI、Amazon Quick でホストされる LLM に接続し、セマンティック検索や Retrieval Augmented Generation (RAG) などのユースケースを実現できます。 Amazon Bedrock – 多様な基盤モデルにアクセスして生成 AI アプリケーションを構築できます。 Amazon SageMaker AI – オープンソース LLM を含む独自のカスタムモデルを、トレーニングデータとモデルの動作を完全にコントロールしながらデプロイ・ファインチューニングできます。 Amazon Quick – Oracle データベースを含むエンタープライズデータソースに接続し、チームが自然言語で組織のデータを照会・活用できるようにします。 エンタープライズ AI の基盤 このアーキテクチャは、次のようなエンタープライズ AI の基盤を作ります。 Oracle データは Exadata に留まる – ミッションクリティカルなトランザクションデータは、AI Smart Scan がベクトルデータをメモリ速度で処理する実績ある高性能インフラストラクチャに残ります。 AI アプリケーションは AWS で実行 – AWS の伸縮自在なコンピューティング、マネージド AI サービス、グローバルインフラストラクチャを活用できます。 ベクトル埋め込みはトランザクションデータと共存 – データ移動が不要になり、運用ワークロードと AI ワークロード間の一貫性を維持できます。 AI スタックを自分でコントロール – ベンダーロックインなしに、要件に合った LLM、フレームワーク、ツールを選択できます。 ERP データに基づくカスタマーサービスチャットボット、取引パターンを分析する不正検知システム、インテリジェントなドキュメント処理パイプラインのいずれを構築する場合でも、ODB@AWS 上の Oracle Database 26ai がデータ基盤となります。AWS は、ビジネス目標に最も合った AI テクノロジーを選択してデプロイする柔軟性を提供します。 #3 – ライセンスオプションによる財務の柔軟性 ODB@AWS は AWS Marketplace で単一の請求書により購入でき、財務計画とベンダー管理の両方が効率化されます。 AWS のコミット済み支出にカウント – ODB@AWS の購入は既存の AWS 商用契約に適用でき、Oracle データベースへの支出が AWS のコミットメントに寄与する可能性があります。 Bring Your Own License (BYOL) – ODB@AWS で Exadata Database Service または Autonomous Database をデプロイする際、既存の Oracle Database ライセンス (Enterprise Edition または Standard Edition 2) を利用できます。この柔軟性により、新規プロジェクトや新環境には License Included (LI) を、既存ワークロードには BYOL を使い分けられ、ライセンス制約によるプロジェクトの順次実施の制限を回避できます。 License Included – Oracle ライセンスをサービス料金に含めることで、Oracle サポート契約を別途維持する必要がなくなります。Oracle サポートコストの簡素化を戦略に含めているなら、このオプションが明快な道筋になります。 Oracle Support Rewards – Oracle Database@AWS は Oracle の Support Rewards プログラムの対象で、サービスへの支出 1 ドルごとに 0.25 ドル (Unlimited License Agreement のお客様は 1 ドルあたり 0.33 ドル) のクレジットが貯まります。このクレジットは、Oracle Database、Oracle Applications、WebLogic などの製品を対象とする年間の Oracle テクノロジーサポート費用の相殺に利用できます。さらに、ODB@AWS は OCI と同等の Support Rewards が貯まるため、OCI で運用した場合と同じ特典スケジュールの恩恵を受けられます。 従量課金スケーリング – 従来の先行ライセンス調達に代わり、ワークロード需要に応じてスケールする Enterprise Edition データベースキャパシティを利用できます。 単一請求書 – 別途 Oracle インフラストラクチャの請求を照合する必要がありません。 Autonomous Database のライセンスの柔軟性: ODB@AWS 上の Oracle Autonomous Database は、包括的な機能 (RAC、Exadata 機能、自動化) を単一のオファリングに含みます。既存の Standard Edition 2 (SE2) ライセンスを持つお客様は、Autonomous Database のデプロイ時に BYOL プログラムでそのライセンスを利用するか、License Included モデルを採用してサブスクリプションベースのライセンスにすることで、個別のライセンス管理と Oracle サポート契約の管理を不要にできます。 料金は OCI の Oracle Exadata Database Service と揃っています。既存の Oracle ライセンス投資がある組織は、BYOL によりそのエンタイトルメントを ODB@AWS で活用できます。運用のシンプルさを求める組織には、既存のエンタイトルメントを必要としない License Included モデルが効率的な調達手段となります。 #4 – クラウド移行の障壁と塩漬け資産の解消 ODB@AWS は、Oracle のお客様が今日直面している最も差し迫ったインフラストラクチャ課題の 1 つ、すなわち最近の仮想化ライセンス変更と仮想化コストの高騰によって深刻化した塩漬け資産 (stranded assets) の問題にも直接対処します。多くの組織はオンプレミスの仮想化環境内またはその周辺に大規模な Oracle ワークロードを抱えており、劇的なコスト増によって運用継続が財務的に持続不可能になりつつあります。 Oracle Exadata ワークロードにクラウドホスト型のネイティブな移行パスを提供することで、ODB@AWS はこうした組織が制約のあるインフラストラクチャから脱却し、再設計なしにワークロードを AWS に移行しながら、既存の Oracle 投資の価値を引き出せるようにします。これにより、これまで塩漬けになっていた Oracle 資産に対して明確でコスト効率の良い移行パスが生まれ、負債がクラウド活用可能な資産に変わります。 #5 – グローバルで 20 以上の AWS リージョンへ拡大中 ODB@AWS はグローバルに拡大を続けており、すでに 12 を超える AWS リージョンで利用できます。このグローバルなフットプリントにより、ユーザーとアプリケーションの近くで ODB@AWS を実行し、データレジデンシー要件を満たしながらレイテンシーを最小化できます。複数リージョンで Oracle E-Business Suite などの Oracle アプリケーションを運用する多国籍企業にとって、この拡大は世界中で一貫したアーキテクチャを可能にします。 リージョンの提供状況は Oracle Region Availability Link で確認できます。 技術面の利点 Oracle Database@AWS が AWS 環境内で高性能なデータベース運用を実現する 8 つの技術的な機能を紹介します。 #6 – Exadata と Oracle RAC の機能を AWS 内でネイティブに利用 一部の Oracle ワークロードは、Exadata プラットフォーム固有の機能に依存しています。マルチノードの耐障害性を実現する Oracle RAC、ストレージレベルのクエリオフロードを行う Exadata Smart Scan、 ベクトル処理向けの Exadata AI Smart Scan 、ハイブリッドカラムナ圧縮、ストレージインデックスなどです。多くのミッションクリティカルなアプリケーションにとって、これらは好みの問題ではなくアーキテクチャ上の要件です。 ODB@AWS はこれらの機能を、Oracle が管理し AWS アベイラビリティゾーン内に物理的に設置された専用 Exadata ハードウェア上で提供します。 Oracle RAC – 複数のデータベースノードにわたる水平スケーラビリティ、最大稼働時間/ゼロダウンタイム、フォールトトレランスを提供します。 Exadata Smart Scan – クエリ処理をストレージサーバーにオフロードし、データベース層に必要なコンピューティングを削減できる可能性があります。 Exadata AI Smart Scan – AI Vector Search ワークロードのベクトル操作をストレージサーバーにオフロードし、ベクトルデータをメモリ速度で処理して AI アプリケーションのパフォーマンスを向上させます。 ハイブリッドカラムナ圧縮 – 分析データとアーカイブデータの保存を最適化します。 ストレージインデックス – ストレージ層で不要な I/O を排除します。 Exadata X11M インフラストラクチャ – 現行モデルとして提供され、最大 32 台のデータベースサーバーと 64 台のストレージサーバーを構成できます。 #7 – Oracle Autonomous Database ODB@AWS には Oracle Autonomous Database on Dedicated Exadata Infrastructure が含まれています。機械学習を使ってパッチ適用、チューニング、スケーリング、セキュリティを自動化する、完全に自己管理型のデータベースです。 Autonomous Database は、従来は複雑だった運用タスクを人手を介さず処理します。 自動インデックス作成 : ワークロードを継続的にモニタリングし、インデックスの作成、削除、再構築を行います。 Auto Scaling : 需要に応じて CPU とストレージのリソースを調整します。 自動パッチ適用 : ゼロダウンタイムのローリングアップデートを実施します。 自動チューニング : SQL 実行プランをリアルタイムに最適化します。 Autonomous Database により、データベース管理者 (DBA) はビジネス価値を生む戦略的な取り組みに集中でき、定常的なメンテナンスの自動化によってチームはイノベーションとビジネス目標の達成を加速できます。また、先行のキャパシティプランニングを必要とせず、実際のワークロード需要に応じてスケールする従量課金モデルもサポートしています。 VM クラスター構成: ODB@AWS は、ExaDB-D と ADB-D のいずれかを選択できる柔軟なデプロイをサポートし、ワークロードに合わせてリソースを細かく設定できます。 Exadata VM クラスター (Oracle Exadata Database Service 用): VM ごとに CPU コア、メモリ、ローカルストレージを設定できます。Oracle RAC と Oracle Grid Infrastructure をサポートします。ピーク容量に合わせた過剰なプロビジョニングではなく、ワークロード要件に合わせたコンピューティングの適正サイジングが可能です。 Autonomous VM クラスター (Oracle Autonomous Database on Dedicated Exadata Infrastructure 用): VM あたりの ECPU コア数、CPU あたりのデータベースメモリ、データベースストレージ、Autonomous Container Database の最大数を設定できます。機械学習 (ML) と AI を使ってプロビジョニング、セキュリティ確保、更新、バックアップ、チューニングを自動化し、定常的なデータベース管理タスクに人手を必要としません。 #8 – 迅速なリフトアンドシフトによるクラウド移行 ODB@AWS は Oracle ネイティブのツールチェーン一式を使った移行をサポートしており、最小限のリスクと最大限のスピードでリフトアンドシフトを実現できます。移行先が正真正銘の Exadata ハードウェアであるため、再設計や機能の廃止を必要とせず、完全な機能互換性を維持したまま移行できます。 Oracle ネイティブの移行ツール: Oracle Zero Downtime Migration (ZDM) – Oracle 純正の自動移行ツールで、ODB@AWS への移行を完全サポートしています。 RMAN – ブロックレベルのバックアップとリストアによる、信頼性が高く一貫した移行を実現します。 Oracle Data Guard – フィジカル/ロジカルスタンバイによるゼロダウンタイムのカットオーバーが可能です。 トランスポータブルテーブルスペース – 最小限のダウンタイムでスキーマレベルの高速移行を実現します。 Oracle Data Pump – スキーマとデータの論理エクスポート/インポートによる移行を行います。 Oracle GoldenGate – リアルタイムの双方向レプリケーションにより、ほぼゼロダウンタイムのカットオーバーが可能です。 #9 – Oracle Autonomous Recovery Service: 包括的なランサムウェア対策とイミュータブルバックアップ Oracle Autonomous Recovery Service (ARS) は、ランサムウェアへの防御に特化した機能を備え、Oracle Database@AWS の包括的なデータ保護と事業継続を支援します。このフルマネージドサービスは、AWS ネイティブのバックアップソリューションを補完する包括的なバックアップ・リカバリ機能を提供します。 1 秒未満の RPO を実現するリアルタイムデータ保護 Autonomous Recovery Service は REDO ログをサービスに継続的にストリーミングするリアルタイムデータ保護を提供し、1 秒未満の目標復旧時点 (RPO) を実現します。データ損失のリスクをほぼゼロに抑え、壊滅的な障害やランサムウェア被害が発生しても、発生時点から 1 秒以内の状態にデータベースを復旧できます。 保持ロックによるイミュータブルバックアップ保護 ARS は保持ロック機能によるイミュータブルバックアップ保護を提供し、保持期間中のバックアップの変更や削除を防ぎます。有効化後は、保持期間が終了するまで特権ユーザーであってもバックアップを変更・削除できません。ランサムウェア、内部の脅威アクター、誤削除に対する重要な安全装置となり、ライフサイクル全体を通じてデータの安全性とコンプライアンスを確保します。 主な機能と利点: 自動バックアップオーケストレーション – バックアップのスケジューリング、実行、ライフサイクル管理を完全自動化し、運用負荷を軽減して一貫した保護を実現します。 継続的なバックアップ検証 – バックアップが改ざんされていないことを継続的に検証し、リカバリ資産が常に利用可能であるという確信を提供します。 最適化されたリカバリワークフロー – 効率化されたリカバリプロセスにより、最小限の手作業で任意の時点への迅速かつ予測可能なリカバリを実現します。 ポリシーベースのライフサイクル管理 – 保護ポリシー (Bronze、Silver、Gold、Platinum、またはカスタム) で 14〜95 日の保持期間を定義でき、バックアップを AWS または OCI リージョンに柔軟に保存できます。 職務の分離 – バックアップ管理をデータベース管理者から分離し、バックアップデータへの不正アクセスや改ざんを防止します。 増分永続 (incremental forever) 戦略 – 初回のフルバックアップ以降は増分変更のみを取得し、ストレージ消費とバックアップウィンドウを最適化します。 柔軟なデプロイオプション Oracle Database@AWS のデプロイメントでは、データベースと同じクラウドプロバイダーのロケーションにバックアップを保存するよう Autonomous Recovery Service を設定できます。保護ポリシーで Store backups in the same cloud provider as the database オプションを有効にすると、バックアップは AWS 内に留まり、データレジデンシーとコンプライアンスの要件への対応が簡素化されます。 保護ポリシー ARS はビジネス要件に合わせた事前定義の保護ポリシーを提供します。 Bronze : 保持期間 14 日。 Silver : 保持期間 35 日 (デフォルト)。 Gold : 保持期間 65 日。 Platinum : 保持期間 95 日。 ユーザー定義 : 保持期間 14〜95 日。 ランサムウェアレジリエンス ランサムウェア被害が記録的なペースで続く時代において、Autonomous Recovery Service は強力な防御機能を提供します。イミュータブルバックアップ、保持ロック、継続的な検証、リアルタイムデータ保護の組み合わせにより、ランサムウェア被害の後でも Oracle データベースを迅速かつ完全に復旧できることを保証します。 Autonomous Recovery Service が有力な選択肢である理由 Autonomous Recovery Service は、1 秒未満の RPO、保持ロックによるイミュータブル保護、継続的な検証、自動化されたライフサイクル管理を兼ね備えています。Oracle Database@AWS のデプロイメントに高いレベルのデータ保護、規制コンプライアンス、ランサムウェアレジリエンスを求める組織にとって有力な選択肢です。 #10 – AWS コンソールと API のネイティブ統合 ODB@AWS のリソースは使い慣れた AWS ツールでプロビジョニング・管理できるため、別の運用モデルを新たに習得する必要はありません。 AWS Management Console – ODB ネットワーク、Exadata インフラストラクチャ、VM クラスターを作成する専用の ODB@AWS ダッシュボード。 AWS CLI と API – 裏側で対応する OCI API を呼び出すプログラマティックアクセス。 AWS CloudFormation – 再現可能で監査可能なデプロイのための Infrastructure as Code。 AWS Resource Access Manager (AWS RAM) によるマルチアカウントでの Exadata インフラストラクチャ共有: AWS Resource Access Manager (AWS RAM) を使うと、組織内の複数の AWS アカウントで単一の Exadata インフラストラクチャを共有でき、チームや事業部門をまたいだコスト削減と管理の簡素化を実現できます。AWS RAM により、Exadata インフラストラクチャと ODB ネットワークを同じ AWS Organization 内の複数の AWS アカウント間で共有できます。 所有者アカウントが Exadata インフラストラクチャをプロビジョニングし、信頼されたアカウントを指定したリソース共有を作成します。 信頼されたアカウントは共有インフラストラクチャ上に独自の VM クラスターとデータベースを作成できますが、基盤となる Exadata インフラストラクチャや ODB ネットワークは削除できません。 信頼されたアカウントは、共有リソースを使用する前に ODB@AWS サービスを初期化する必要があります。 リソースは同じ AWS Organization 内、同じリージョン内で、特定の AWS アカウント ID とのみ共有できます。 リソース共有は作成後に変更できず、リソースを別の購入者アカウントと共有することもできません。 これにより、インフラストラクチャの一元的な所有、Exadata キャパシティの共有によるコスト最適化、データベースチーム間の論理的な分離を、すべて AWS アカウントのガバナンスモデルの中で実現できます。 AWS Identity and Access Management (IAM) – 既存の ID フレームワークを使った認証と認可。 Amazon CloudWatch – VM クラスター、コンテナデータベース、プラガブルデータベースの AWS/ODB 名前空間のメトリクス。 AWS CloudTrail – コンプライアンスとガバナンスのための完全な API 監査ログ。 Amazon EventBridge – データベースライフサイクルイベントによるイベント駆動の自動化。 既存の AWS 運用ランブック、モニタリングダッシュボード、セキュリティポリシーは ODB@AWS に自然に拡張できます。クラウド運用チームは使い慣れたツールで作業できます。 クロスアカウント共有のベストプラクティスの詳細は、 Best practices and architecture patterns for cross-account sharing in Oracle Database@AWS を参照してください。 ネットワーク接続パターン : ODB@AWS は、スケールとトポロジーの要件に応じて 3 つの接続パターンをサポートします。 パターン 1: VPC 直接ピアリング (1 対多): 最もシンプルなネットワークパスです。ピアリングされた VPC がアプリケーション VPC として ODB ネットワークに接続します。Oracle データベースが主に単一 VPC 内のアプリケーションにサービスを提供する場合に最適です。 現在は最大 45 の VPC 接続をサポートしています。 パターン 2: AWS Transit Gateway による単一リージョンスケール: ピアリングされた VPC が ODB トランジット VPC として動作します。トラフィックは Transit Gateway 経由で ODB ネットワークに転送され、単一 AWS リージョン内の複数の VPC から ODB@AWS リソースにアクセスできます。 パターン 3: AWS Cloud WAN によるマルチリージョンスケール: ピアリングされた VPC がトランジット VPC として動作します。トラフィックは AWS Cloud WAN のコアネットワーク経由で転送され、複数の AWS リージョンとオンプレミスネットワークから ODB@AWS への接続が可能になります。 パターン 4: クロスリージョン接続のための OCI VCN ピアリング: クロスリージョンの災害復旧 (DR) やハイブリッドクラウドのシナリオでは、ODB ネットワークを Local Peering Gateway (LPG) を使って OCI Virtual Cloud Network (VCN) に接続できます。各 ODB ネットワークは、お客様のリンクされた OCI テナンシー内の OCI VCN と 1:1 でマッピングされます。これにより、OCI VCN ピアリングを介して異なる AWS リージョンの ODB@AWS デプロイメント間の接続が可能になり、複数リージョンにまたがる Oracle Data Guard 構成などのユースケースをサポートします。 技術的な考慮事項: ODB ネットワークは最大 45 の ODB ピアリング接続をサポートします。ODB ネットワークの CIDR には IP アドレス空間の計画が必要です。VPC ルートテーブルは ODB ネットワークの CIDR に合わせて手動で更新する必要があります。DNS 解決には、ピアリングされた VPC に Amazon Route 53 Resolver のアウトバウンドエンドポイントをデプロイする必要があります。Oracle アプリケーションとデータベースが同一 AZ 内にある場合、データ転送料金は発生しません。 強化されたセキュリティコントロール: IAM、Amazon CloudWatch、AWS CloudTrail、Amazon EventBridge に加えて、ODB@AWS は以下を提供します。 SSL/TLS 暗号化 – ODB@AWS へのすべての接続は転送中に暗号化されます。 AWS Key Management Service (AWS KMS) – AWS CloudFormation とマネージド統合を使った暗号化キー管理との統合。 ネットワーク分離 – ODB ネットワークはプライベートでパブリックインターネットに公開されず、すべての接続は AWS ネットワークファブリック内で ODB ピアリング、AWS Transit Gateway、または AWS Cloud WAN を使用します。 ODB@AWS は AWS インフラストラクチャ層のコンプライアンス認証 (SOC、ISO、PCI DSS、HIPAA 対応) を継承し、Exadata とデータベースソフトウェア層のコンプライアンスは Oracle が維持します。 #11 – Amazon Redshift との Zero-ETL 統合 図 1: Amazon Redshift への Zero-ETL 統合 Amazon Redshift との Zero-ETL は、ETL パイプラインの構築や管理なしに、またネットワーク間のデータ転送コストなしに、Oracle のトランザクションデータを Amazon Redshift にレプリケートします。これにより以下が可能になります。 リアルタイム分析 : Amazon Redshift のカラムナエンジンを使った Oracle トランザクションデータの分析。 ML と AI のワークロード : Amazon Redshift に接続した Amazon SageMaker AI の活用。 クロスソース分析 : Oracle データと、すでに Amazon Redshift にある他の AWS ソースのデータの結合。 ビジネスインテリジェンス : ほぼリアルタイムの Oracle データを使った Amazon QuickSight ダッシュボード。 図 2: Zero-ETL と分析サービスの統合 Oracle E-Business Suite (Oracle EBS)、PeopleSoft、Siebel などの Oracle エンタープライズアプリケーション環境では、これが特に重要です。Oracle EBS は財務、サプライチェーン、製造、人事にわたる膨大な量のトランザクションデータを生成します。Zero-ETL により、財務チームは GL 仕訳の分析、サプライチェーンチームは在庫移動の分析、調達チームは発注支出の追跡を、別途 ETL インフラストラクチャなしでほぼリアルタイムに実行できます。 Amazon VPC Lattice による AWS サービス接続 – AWS Glue Zero-ETL やその他の AWS 分析統合は、ODB ネットワークから AWS サービスへのネイティブアクセスを提供する Amazon VPC Lattice によって実現されます。 VPC Lattice 経由の Amazon S3 – Oracle 管理のバックアップを、パブリックインターネットを経由せず Amazon S3 (99.999999999%、イレブンナインの耐久性設計) に直接保存できます。 Amazon Bedrock と Amazon SageMaker AI – Oracle データが Amazon Redshift や Amazon S3 に流れることで、Amazon Bedrock の基盤モデル (FM) や Amazon SageMaker AI を使い、予知保全、需要予測、Oracle トランザクションデータに対する LLM ベースの分析といったユースケースの生成 AI・ML パイプラインを構築できます。 注: マネージド統合には標準の VPC Lattice データ処理料金が適用されます。統合自体に時間あたりの料金はかかりません。 #12 – Oracle アプリケーション向けの認定アーキテクチャ Oracle は ODB@AWS 上に Oracle エンタープライズアプリケーションをデプロイするためのリファレンスアーキテクチャを公開しており、 Oracle E-Business Suite (Oracle EBS) が最初の認定デプロイパターンです。アプリケーション層を AWS で、データベース層を Exadata で、すべて同一 AWS リージョン内で実行するサポート対象の構成です。 Oracle E-Business Suite のリファレンスアーキテクチャ: Amazon EC2 上の Oracle アプリケーション層 – Web、フォーム、コンカレント処理、管理サーバー。 ODB@AWS の Exadata 上のデータベース層 – 同一アベイラビリティゾーン内の低レイテンシーネットワーキングで ODB ピアリング接続。 AWS Transit Gateway – 複数の VPC、ODB ネットワーク、オンプレミス拠点を接続するハブアンドスポークネットワーキング。 Amazon FSx for NetApp ONTAP – 共有 APPL_TOP ファイルシステム。SnapMirror による本番・非本番環境間のクローンをサポート。 AWS Direct Connect – オンプレミスデータセンターへのハイブリッド接続。 Oracle EBS のアプリケーションコードは変更不要です。RAC、Data Guard、ASM、RMAN を含むデータベース機能はすべて、オンプレミスとまったく同じように動作します。Oracle EBS 12.2 は Oracle Database 26ai on Exadata の認定を受けているため、ODB@AWS で Oracle EBS を実行しながら 26ai の機能を活用できます。 その他の Oracle アプリケーションのサポート: ODB@AWS は、 PeopleSoft 、Siebel、JD Edwards EnterpriseOne、Oracle Enterprise Performance Management、Oracle Retail Applications などの他の Oracle エンタープライズアプリケーションもサポートしています。これらのアプリケーションは、アプリケーション層を Amazon EC2、データベース層を ODB@AWS の Exadata とする同様のアーキテクチャパターンに従い、同じ低レイテンシー接続と AWS サービス統合の利点を維持します。 WebLogic や Fusion Middleware などの Oracle ミドルウェアプラットフォームもこのアーキテクチャと統合でき、Oracle Database 上に構築された ISV アプリケーションも同じデプロイパターンに従うことができます。 EBS を ODB@AWS にデプロイするリファレンスアーキテクチャ は、Oracle EBS のアプリケーション層を AWS で、データベース層を Exadata で、すべて同一 AWS リージョン内で実行するサポート対象の構成です。 Amazon EC2 上の EBS アプリケーション層 – Web、フォーム、コンカレント処理、管理サーバー。 ODB@AWS の Exadata 上のデータベース層 – 同一アベイラビリティゾーン内の低レイテンシーネットワーキングで ODB ピアリング接続。 AWS Transit Gateway – 複数の VPC、ODB ネットワーク、オンプレミス拠点を接続するハブアンドスポークネットワーキング。 Amazon FSx for NetApp ONTAP – 共有 APPL_TOP ファイルシステム。SnapMirror による本番・非本番環境間のクローンをサポート。 AWS Direct Connect – オンプレミスデータセンターへのハイブリッド接続。 Amazon S3 – イレブンナインの耐久性を持つデータベースバックアップ。 Oracle EBS のアプリケーションコードは変更不要です。RAC、Data Guard、ASM、RMAN を含むデータベース機能はすべて、オンプレミスとまったく同じように動作します。Oracle EBS 12.2 は Oracle Database 26ai on Exadata の認定を受けている ため、ODB@AWS で Oracle EBS を実行しながら 26ai の機能を活用できます。 #13 – Oracle ワークロードごとに適切な AWS の選択肢を選ぶ AWS は現在、Oracle ワークロード向けに 3 つの有力な選択肢を提供しています。適切な選択は、どのサービスが「優れているか」ではなく、ワークロードの要件によって決まります。 ワークロード要件 最適な選択肢 マネージド Oracle DB、共同管理の運用、自動メンテナンス、標準機能 Amazon RDS for Oracle、または ADB-D OS へのフルアクセス、カスタム設定、特定のパッチ適用ニーズ Amazon EC2 上の Oracle、または ExaDB-D Exadata 機能、Oracle RAC のフォールトトレランス、Autonomous DB Oracle Database@AWS – ExaDB-D Autonomous Database、自己管理型の運用、自動メンテナンス Oracle Database@AWS – ADB-D EE の License Included による Oracle サポートコストの排除 Oracle Database@AWS (ExaDB-D または ADB-D) ストレージ効率によるコスト最適化 Oracle Database@AWS (ExaDB-D または ADB-D) – 圧縮なしの Exadata で GB あたり 0.025 USD 多くの組織は、Oracle 資産全体で複数の選択肢を併用することになるでしょう。開発・テスト用データベースは Amazon RDS for Oracle で、カスタム Oracle 設定が必要なアプリケーションは RDS Custom for Oracle で、ミッションクリティカルな Oracle EBS 本番環境は Oracle Database@AWS で運用する、といった形です。これらの選択肢はポートフォリオとして連携します。 始め方 Oracle Database@AWS の検討を始めるには: AWS Management Console にアクセス – AWS Management Console の Oracle Database@AWS ダッシュボード サービスページで、サービスと利用可能な構成を確認します。 プライベートオファーをリクエスト – AWS または Oracle のアカウントチームに連絡するか、 AWS Marketplace から直接リクエストします。 ワークロードを評価 – Oracle AWS Optimization and Licensing Assessment (OLA) を使って、Oracle 資産、ライセンス状況、移行の準備状況を評価します。前述の判断フレームワークを適用して、各ワークロードに適した ODB@AWS のサービスティア (ExaDB または ADB) を決定します。 ドキュメントを確認 – Oracle Database@AWS ユーザーガイド と Oracle のドキュメント に、セットアップ、設定、移行の詳細なガイダンスがあります。 パートナーと連携 – AWS Oracle コンピテンシーパートナー が、ZDM ベースの移行計画と実行を含む ODB@AWS 環境の設計、デプロイ、管理を支援します。 まとめ 本記事では、Oracle Database@AWS が AWS 上で Oracle を実行するための選択肢のポートフォリオをどのように拡張するかを解説しました。このソリューションは、Exadata のパフォーマンス、RAC のフォールトトレランス、Autonomous Database の自動化、柔軟なライセンスモデルを AWS にもたらし、ネイティブなコンソール統合、zero-ETL 分析、Oracle Database 26ai による AI 機能も備えています。 Exadata の機能、事業継続性のための Oracle RAC、ストレージコストの最適化、Enterprise Edition の従量課金ライセンス、Oracle サポートコストの簡素化が必要であれば、ODB@AWS は詳しく検討する価値があります。うまく機能しているものを置き換える話ではありません。すべての Oracle ワークロードに適切な選択肢を持つということです。 Oracle Database@AWS がクラウド戦略にどう組み込めるか、また特定の Oracle ワークロード要件にどう応えられるかをぜひ検討してください。ODB@AWS の実際の効果を確認する準備はできましたか？AWS Optimization and Licensing Assessment (AWS OLA) をリクエストしてください。AWS と Oracle のエキスパートが協力して現在の Oracle 資産を評価し、最適化の機会を特定し、Oracle Database@AWS への移行・モダナイゼーションのロードマップをお客様に合わせて設計する包括的なエンゲージメントです。 今すぐ AWS OLA をリクエスト して、AWS 上での Oracle ワークロード最適化への道を歩み始めてください。 コメント欄でご意見をお聞かせいただくか、Oracle Database@AWS が組織のニーズをどのようにサポートできるか、私たちのチームまでお気軽にご相談ください。 著者について Simon Cunningham Simon は、プリンシパルパートナーソリューションアーキテクトで、Oracle ワークロードのサポートとアプリケーション・データベースの AWS 移行において 25 年以上の経験を持っています。 Raghu Soma AWS のシニアパートナーソリューションアーキテクトです。お客様とパートナーとともに、Oracle Database@AWS や Oracle アプリケーション (COTS) を含む AWS 上の Oracle ワークロードの設計とデプロイに取り組み、コスト削減、レジリエンス向上、クラウドネイティブ機能の活用を支援しています。 Karthik Gopalakrishnan AWS の Extended Support、ODB@AWS、Db2 を担当するシニアプロダクトマネージャー (テクニカル) です。 この記事は Solutions Architect の 矢木 覚が翻訳しました。

本記事は 2026 年 4 月 23 日 に公開された「 Best practices and architecture patterns for cross-account sharing in Oracle Database@AWS 」を翻訳したものです。 Oracle Database@AWS (ODB@AWS) は、Amazon Web Services (AWS) データセンター内で Oracle Cloud Infrastructure (OCI) が管理する Oracle Exadata インフラストラクチャにアクセスできるサービスで、Oracle Cloud Infrastructure (OCI) と AWS の間で統一された体験を提供します。オンプレミスデプロイメントと同等の機能、アーキテクチャ互換性、パフォーマンスを維持しながら、Oracle Exadata ワークロードの AWS クラウドへの移行を簡素化します。 Oracle Database@AWS は現在、以下の OCI サービス を提供しています。 Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D) Oracle Autonomous AI Database on Dedicated Exadata Infrastructure (ADB-D) Oracle Database Autonomous Recovery Service (ARS) Oracle Database@AWS は、環境のライフサイクル管理とガバナンスを改善しながら、ビジネスユニット間で Oracle データベースを運用するモデルを定義する複数の方法を提供します。本記事では、AWS アカウント間で Oracle Database@AWS (ODB@AWS) リソースを共有するためのオプションを解説します。あわせて、一般的なクロスアカウントアーキテクチャパターン、ベストプラクティス、重要な考慮事項も紹介します。これにより、AWS アカウント全体で効率的な ODB@AWS アーキテクチャを設計できます。本記事で使用する主要な用語の確認は、記事末尾の「主要な概念」セクションを参照してください。 クロスアカウントのリソース共有とデプロイオプション パート 1: リソース共有オプション 同一 Organization 内のアカウント間で ODB@AWS リソースと Marketplace サブスクリプションを共有するための大まかなアプローチは以下のとおりです。 AWS Resource Access Manager (AWS RAM) によるリソース共有。 AWS Resource Access Manager (AWS RAM) 共有では、同じ AWS Organization 内の複数の AWS アカウント間で Exadata インフラストラクチャと ODB ネットワークリソースを共有できます。 AWS License Manager を使った AWS Marketplace エンタイトルメント共有によるサブスクリプションの他アカウントとの共有。 エンタイトルメント共有では、購入者アカウント (グランター アカウント) が、同じ AWS Organization 内の複数の AWS アカウント (グランティー アカウント) に Oracle Database@AWS のエンタイトルメントを共有できます。各グランターまたはグランティーアカウントは、集中管理されたサブスクリプションを利用しながら、自身の AWS アカウント内で ODB@AWS をプロビジョニング・運用し、独立したネットワーキング、セキュリティ境界、運用管理を維持します。 パート 2: リソース共有のデプロイパターン (リソースモデリング) 同一 Organization 内の単一または複数の AWS アカウントにリソースをモデリング・デプロイする際に使える一般的なアーキテクチャパターンは以下のとおりです。 単一アカウント (購入者アカウントのみ) のデプロイ Exadata インフラストラクチャまたは ODB ネットワークのクロスアカウントリソース共有 リソース分離のためのクロスアカウントサブスクリプション共有 サブスクリプション共有とリソース共有を組み合わせたクロスアカウントハイブリッドモデル クロスアカウントハイブリッドモデル – グランティーアカウントが RAM 共有を実施 クロスアカウントハイブリッドモデル – 信頼されたアカウントとグランティーアカウントの両方を兼ねるアカウント AWS Resource Access Manager (AWS RAM) によるリソース共有 Oracle Database@AWS は AWS Resource Access Manager (AWS RAM) を使い、安全で制御されたリソース共有を実現します。チームやビジネスユニット間でガバナンスとセキュリティ境界を維持しながら Oracle データベースインフラストラクチャのコストを最適化したい組織に有用です。このオプションでは、AWS 購入者アカウントがプロビジョニング済みの Exadata インフラストラクチャまたは ODB ネットワークを他の信頼された AWS アカウントと共有できます。信頼されたアカウントは、自身のアカウント内で VM クラスターまたは Autonomous VM クラスターと CDB/PDB を作成できます。信頼されたアカウントは Exadata インフラストラクチャや ODB ネットワークを作成できません。信頼されたアカウントはトランジット Amazon Virtual Private Cloud (Amazon VPC) を作成し、共有された ODB ネットワークとピアリングできます。次のアーキテクチャパターンでは、購入者アカウントが ODB ネットワークと Exadata インフラストラクチャの両方をプロビジョニングし、信頼されたアカウント 1 と 2 に共有しています。信頼されたアカウントは共有インフラストラクチャ上に VM クラスターを作成し、アプリケーション VPC とピアリングできます。 購入者アカウントと信頼されたアカウント間のリソース共有を有効にする手順は以下のとおりです。 AWS License Manager による Marketplace エンタイトルメント共有 AWS Marketplace のセラープライベートオファー機能を使うと、Oracle から Oracle Database@AWS の料金と EULA 条件を受け取ることができます。AWS Marketplace での ODB@AWS のリクエストと購入の手順は オンボーディングセクション を参照してください。Marketplace エンタイトルメント共有オプションでは、同じ AWS Organization 内の AWS アカウント間で Oracle Database@AWS のサブスクリプションとエンタイトルメントを共有できます。購入者 (グランター) AWS アカウントが AWS License Manager を通じてグランティー AWS アカウントにエンタイトルメントを共有します。グランティーアカウントは、自身のアカウント内で独自の ODB ネットワーク、Exadata インフラストラクチャ、VM クラスター、Autonomous VM クラスター、データベースをプロビジョニングします。 次のアーキテクチャ図では、グランター (購入者) アカウントがグランティーアカウント 1 と 2 にエンタイトルメントを共有し、グランティーアカウントが独自の ODB ネットワークと Exadata インフラストラクチャを作成できるようにしています。 グランターアカウントとグランティーアカウント間のエンタイトルメント共有を有効にする手順は以下のとおりです。 リソースモデリングのユースケース 単一アカウント (購入者アカウントのみ) のデプロイ このケースでは、単一の AWS アカウントに Oracle Database@AWS リソースをデプロイします。マルチクラウドリンク設定の一環として、各 AWS アカウントは リンク された OCI テナンシー内に専用のコンパートメントを持ちます。購入者アカウントは任意の Oracle Database@AWS サービスをデプロイできます。 次のアーキテクチャパターンでは、ODB ネットワーク、Exadata インフラストラクチャ、VM クラスター、データベースを含む ODB@AWS リソースが、Marketplace オファーを受諾した購入者アカウントによってデプロイ・所有されています。図 1 では、Oracle データベースに接続するアプリケーションは同一アカウント内の複数の VPC にあり、ODB ピアリングで直接ピアリングされています。 図 1: 同一アカウント内の複数アプリケーション VPC との直接 ODB ピアリング 次のアーキテクチャ図では、Oracle データベースに接続するアプリケーションは、AWS Transit Gateway を経由するハブアンドスポークアーキテクチャで接続しています。図 1 と図 2 のアーキテクチャは、アプリケーション、データベース、ODB@AWS Marketplace オファーが単一アカウントにあるユースケース向けの最もシンプルなパターンです。 図 2: 同一アカウント内で Transit Gateway を経由した複数 VPC から ODB@AWS への接続 Exadata インフラストラクチャまたは ODB ネットワークのクロスアカウント共有 このパターンでは、AWS RAM を使って複数の AWS アカウント間で Exadata インフラストラクチャと ODB ネットワークを共有します。信頼された各 AWS アカウントは、データベースをデプロイするための専用 VM クラスターまたは AVM クラスターを持てます。単一の Exadata インフラストラクチャまたは ODB ネットワークを複数の信頼された AWS アカウントと共有できます。複数の事業部門やチームで Exadata インフラストラクチャを共有することで、コストを削減できます。次の図のように、購入者 AWS アカウント (アカウント 1) はコンパートメント A を持つ OCI テナンシーにリンクされています。Exadata リソースは購入者アカウントから信頼されたアカウント 2 と信頼されたアカウント 3 に共有されています。信頼された各アカウントは、同じ OCI テナンシー配下の OCI 側に対応するコンパートメントを持ちます。 ODB ネットワークとアプリケーション/トランジット VPC 間のクロスアカウントピアリングでは、次の図のように、購入者アカウントから信頼されたアカウントに ODB ネットワークを共有し、信頼されたアカウント内の VPC とピアリングできます。 注: 購入者アカウントの ODB ネットワークを、信頼されたアカウントから AWS RAM で共有された VPC サブネットと直接ピアリングすることはできません。 次の図のように、ODB ネットワークに加えて Exadata インフラストラクチャも信頼されたアカウントと共有できます。非本番と本番のワークロードを別々の AWS アカウントに分離するのに適したアプローチです。 リソース分離のためのクロスアカウント Marketplace サブスクリプション 次のパターンでは、同一 Organization 内の複数の AWS アカウントに Oracle Database@AWS を分離しつつ、各アカウントが独立して独自の Oracle Database@AWS リソースをプロビジョニングし、そのライフサイクルを完全に管理できるようにします。アカウント A は License Manager を使ってアカウント B とアカウント C にサブスクリプションのエンタイトルメントを共有します。このアプローチは、複数の事業部門にまたがる大規模なデータベースデプロイメントの管理や、ソフトウェア開発ライフサイクル (SDLC) 間でインフラストラクチャを共有しないというコンプライアンスやガバナンスの要件への対応に役立ちます。 サブスクリプション共有とリソース共有を組み合わせたクロスアカウントハイブリッドモデル このパターンは、AWS License Manager によるサブスクリプション共有と AWS Resource Access Manager によるリソース共有を組み合わせたクロスアカウントハイブリッドモデルです。次の図では、AWS グランター (購入者) アカウントが AWS License Manager を使ってグランティーアカウントにサブスクリプションを共有しています。購入者アカウントとグランティーアカウントの両方が独自の Exadata インフラストラクチャと ODB ネットワークを作成します。購入者アカウントはさらに、Exadata インフラストラクチャと ODB ネットワークを複数の信頼されたアカウントに共有し、各アカウントは本番/非本番ワークロードのホスティングやアプリケーションごとの分離のために独自の VM クラスターを持ちます。 クロスアカウントハイブリッドモデル – グランティーアカウントが AWS RAM 共有を実施 次のパターンは、前のパターンを発展させた複雑なクロスアカウントハイブリッドモデルで、グランターとグランティーの両アカウントが AWS RAM を使って自身の信頼されたアカウントに ODB@AWS リソースを共有します。次のアーキテクチャ図のように、グランターとグランティーの両アカウントが独自の Exadata インフラストラクチャと ODB ネットワークをデプロイし、これらの ODB@AWS リソースを複数の信頼されたアカウントに共有しています。サブスクリプション共有と AWS RAM 共有を組み合わせることで、インフラストラクチャ・ODB ネットワークレベルと VM クラスターレベルの 2 段階で分離できます。 クロスアカウントハイブリッドモデル – 信頼されたアカウントとグランティーアカウントの両方を兼ねるアカウント 次のパターンは、1 つの AWS アカウントが信頼されたアカウントとグランティーアカウントの両方の役割を担う構成です。このユースケースでは、購入者アカウント A が AWS アカウント 2 に対して AWS RAM 共有とサブスクリプション共有の両方を有効にします。アカウント 2 は、アカウント 1 から共有された Exadata と ODB ネットワーク上にリソースをデプロイできます。同時に、アカウント 2 はアカウント 1 から分離された独自の Exadata と ODB ネットワークもデプロイできます。本番ワークロード用に専用 Exadata を持ち、非本番ワークロード用に Exadata を共有するシナリオで有用なパターンです。 次の表は、各 AWS アカウントタイプが実行できる操作をまとめたものです。 ✓ ✓✓✓ AWS RAM 共有 エンタイトルメント共有 ODB ネットワークの作成 Exadata インフラストラクチャの作成 Exa-VMC/AVMC の作成 購入者/グランター ✓ ✓ ✓ ✓ ✓ 信頼されたアカウント グランティー ✓ 考慮事項 ODB@AWS で AWS RAM 共有とエンタイトルメント共有の機能を使い始める前に考慮すべきベストプラクティスは以下のとおりです。あわせて、ODB@AWS の エンタイトルメント共有 と AWS RAM 共有 の制限事項も参照してください。 AWS RAM でアカウント間のリソースを共有する場合、リソース所有者アカウントがリソースのライフサイクルを完全にコントロールします。 信頼されたアカウントは、付与された権限に基づいて共有リソースを使用できますが、削除はできません。 購入者アカウントには、管理アカウントではなく AWS メンバーアカウントの使用を推奨します。 信頼されたアカウントは、1 つの購入者アカウント (1 つのオファー) からの共有リソースのみ使用できます。したがって、2 つの購入者アカウントが同じ信頼されたアカウントにリソースを共有することはできません。 グランティーアカウントは、1 つのグランター (購入者) アカウントからのみライセンス (エンタイトルメント) 付与を受諾でき、同時に有効な付与は 1 つだけです。 エンタイトルメントは、同じ AWS Organization 内の AWS アカウントとのみ共有できます。 組織単位 (OU) 全体や Organization 全体とエンタイトルメントを共有することはできません。 グランターまたは購入者アカウントは、別のグランターまたは購入者アカウントとエンタイトルメントを共有できません。 AWS License Manager でのエンタイトルメント付与操作は、バージニア北部 (us-east-1) AWS リージョンからのみ実行できます。ODB@AWS のアクティベーションは OCI テナンシーのホームリージョンで行われ、us-east-1 とは異なる場合があります。 主要な概念 本記事で使用した主要な概念を振り返ります。 AWS Organizations : AWS Organizations は、AWS リソースの成長とスケールに合わせて環境を一元管理・統制するのに役立ちます。Organizations を使うと、アカウントの作成とリソースの割り当て、ワークフローを整理するためのアカウントのグループ化、ガバナンスのためのポリシー適用、アカウントの支払い方法の一本化による請求の簡素化ができます。Organizations は他の AWS サービスと統合されているため、組織内のアカウント全体で中央設定、セキュリティメカニズム、監査要件、リソース共有を定義できます。 購入者アカウント (Buyer account): AWS Marketplace のサービスオンボーディング、AWS アカウントとサービスのリンク、リソースのプロビジョニング、信頼されたアカウントとのリソース共有を担当する AWS アカウントです。Oracle Database@AWS のプライベートオファーをリクエストして受諾するアカウントです。このアカウントは AWS Organization の メンバーアカウント である必要があります。 所有者アカウント (Owner account): 特定のリソースを作成した AWS アカウントは、そのリソースの所有者アカウントとみなされます。たとえば、Exadata インフラストラクチャリソースを作成したアカウントは、そのリソースの所有者アカウントです。通常、Oracle Database@AWS の初期デプロイでは、購入者アカウントが最初の Exadata インフラストラクチャリソースをデプロイするため、そのリソースの所有者アカウントにもなります。2 番目のアカウントがそのインフラストラクチャリソースを使って Exadata VM クラスターを作成した場合、2 番目のアカウントがその VM クラスターの所有者アカウントです。インフラストラクチャリソースの所有者アカウントは、VM クラスターのプロビジョニングに使用する 2 番目のアカウントに対して、リソースへのアクセスを明示的に許可する必要があります。 信頼されたアカウント (Trusted account): IAM ロールを通じて別のアカウント (「信頼する」アカウント) のリソースへのアクセスや操作の実行を許可されたアカウント、または AWS Organization 内で組織を代表してサービスが動作することを許可するアカウントを指します。所有者アカウントから特定のリソースへのアクセスを付与されたアカウントです。Oracle Database@AWS では、所有者アカウントが Exadata インフラストラクチャや ODB ネットワークなどのリソースを、同じ AWS Organization のメンバーである他の AWS アカウントと共有できます。 グランターアカウント (Grantor account): Oracle Database@AWS のサブスクリプションを所有し、AWS License Manager を通じてグランティーアカウントに共有する AWS アカウントです。グランターアカウントは通常、AWS Marketplace で Oracle Database@AWS のプライベートオファーを受諾したアカウントです。AWS License Manager で グラント を作成することで、グランターアカウントは同じ AWS Organization 内の 1 つ以上の AWS アカウントに Oracle Database@AWS サブスクリプションを共有できます。 グランティーアカウント (Grantee account): AWS License Manager を通じてグランターアカウントから Oracle サブスクリプションのグラントを受け取る AWS アカウントです。グラントが受諾・有効化されると、グランティーアカウントは共有サブスクリプションを使って、独立して Oracle Database@AWS リソースのプロビジョニング、管理、更新、削除ができます。グランティーアカウントは、自身が作成したリソースのライフサイクルを完全にコントロールします。グランティーアカウントは、一度に 1 つの グランターアカウント からのみサブスクリプショングラントを受諾できます。 Exadata インフラストラクチャ : Oracle Exadata インフラストラクチャは、Oracle データベース実行用に設計された高性能で統合されたハードウェア・ソフトウェアシステムです。Oracle Exadata データベースを実行するデータベースサーバーとストレージサーバーの基盤アーキテクチャで、AWS アベイラビリティゾーン (AZ) 内に存在します。 ODB ネットワーク: ODB ネットワークは、AWS アベイラビリティゾーン (AZ) 内で OCI インフラストラクチャをホストするプライベートな分離されたネットワークです。ODB ネットワークは IP アドレスの CIDR 範囲で構成されます。ODB ネットワークは OCI Child Site 内のネットワークに直接マッピングされ、AWS と OCI 間の通信手段となります。 トランジット Virtual Private Cloud (VPC): ODB ネットワークと直接ピアリングされ、Transit Gateway を通じて他の VPC への接続を仲介する VPC です。 OCI マルチクラウドリンクコンパートメント: クラウドプロバイダーのエンティティに対応する OCI コンパートメントです。リンクされたコンパートメントのデフォルト名はパートナークラウドによって異なります。AWS のコンパートメントには AWS アカウント ID のプレフィックスが付きます。 まとめ 本記事では、AWS アカウント間で ODB@AWS リソースを共有するためのさまざまなオプションを解説しました。あわせて、一般的なクロスアカウントアーキテクチャパターン、ベストプラクティス、重要な考慮事項も紹介しました。ご質問やフィードバックがあれば、コメント欄にお寄せください。 著者について Yamuna Palasamudram Yamuna は、AWS のプリンシパルデータベーススペシャリストソリューションアーキテクトです。AWS のリレーショナルデータベースチームで Oracle などの商用データベースエンジンを担当し、アーキテクチャガイダンス、テクニカルアドバイザリー、データおよび AI 戦略の支援を通じてお客様と協業しています。 Javeed Mohammed Javeed は、AWS のシニアデータベーススペシャリストソリューションアーキテクトです。Amazon RDS チームで Oracle や Db2 などの商用データベースエンジンを担当し、お客様の AWS でのリレーショナルデータベースワークロードの設計、デプロイ、最適化を支援しています。 Nishanth Sodum Nishanth は、Oracle のシニアプリンシパルソリューションアーキテクトで、Oracle Cloud Infrastructure プロダクトマネジメント組織に所属しています。マルチクラウドソリューションの推進と Oracle Database @ Hyperscalers の成長に注力しています。 この記事は Solutions Architect の 矢木 覚 が翻訳しました。

本記事は 2026 年 4 月 20 日 に公開された「 Getting started with the Oracle Database@AWS high performance networking 」を翻訳したものです。 Oracle Database@AWS (ODB@AWS) は、AWS データセンター内で Oracle Cloud Infrastructure (OCI) が管理する Oracle Exadata インフラストラクチャへのアクセスを提供します。Oracle Exadata インフラストラクチャは物理的に AWS データセンター内に設置されており、同一アベイラビリティゾーン内で稼働する Amazon Elastic Compute Cloud (Amazon EC2)、 Amazon Elastic Container Service (Amazon ECS)、Amazon Elastic Kubernetes Service (Amazon EKS) などの AWS サービスへの低レイテンシーネットワーク接続を実現します。アプリケーション層は、EC2 ネットワーキング上の TCP/IP 経由で Oracle の SQL*Net プロトコルを使ってデータベース層と通信します。 トレーディングシステムや高スループットの OLTP ワークロードなど、レイテンシーに敏感なオンプレミスデプロイメントのアプリケーション要件を満たすため、 ODB@AWS 高性能ネットワーキング を発表しました。この機能は、EC2 上のアプリケーションとデータベース間で安定かつ予測可能なサブミリ秒のネットワークラウンドトリップレイテンシーを提供します。ODB@AWS データベースへの接続に最適化されたプレイスメントを使用する EC2 インスタンスに追加料金はかかりません。 本記事では、Oracle Database@AWS の高性能ネットワーキング機能を解説し、設定とデプロイのステップバイステップガイドを提供します。 仕組み この機能は、サポートされるリージョンとアベイラビリティゾーンで 2026 年 4 月 1 日以降に作成された新しい Oracle Database@AWS ネットワーク (ODB ネットワーク) でのみ利用可能です。リージョンの可用性の詳細は、 Oracle Database@AWS ユーザーガイド の Unsupported Availability Zones を参照してください。 ODB@AWS 高性能ネットワーキングは、Amazon EC2 プレイスメント グループを使い、AWS アベイラビリティゾーン (AZ) 内で Oracle Exadata インフラストラクチャの物理的に近い場所にアプリケーションインスタンスを配置します。この近接性によりネットワークホップが最小化され、レイテンシーのばらつきが減少します。Oracle クライアント (EC2/ECS/EKS 上のアプリケーション) と ODB@AWS 上の Oracle Database サーバー間の SQL*Net トラフィックに対して、安定かつ予測可能なネットワークパフォーマンスを実現します。 高性能ネットワーキングはすべての ODB@AWS ユーザーに自動的に利用可能です。データベース用の ODB ネットワークを作成すると、プレイスメントグループが自動的にプロビジョニングされ、新しく作成された ODB ネットワークに関連付けられます。AWS Command Line Interface (AWS CLI) またはコンソールでプレイスメントグループを取得し、Amazon EC2 インスタンスの起動時に指定できます。プレイスメントグループは、新しい EC2 インスタンスの起動や EC2 On-Demand Capacity Reservation によるコンピューティング容量の予約を含む既存の Amazon EC2 API と統合されます。主な特徴は以下のとおりです。 プレイスメントグループの自動プロビジョニング – 新しい ODB ネットワーク (ODBN) ごとにプレイスメントグループが自動的に作成・関連付けされます。 安定したレイテンシー – EC2 インスタンスと ODB@AWS データベース間で安定したサブミリ秒のネットワークラウンドトリップレイテンシーを実現します。 既存の EC2 ワークフローとの互換性 – 標準 EC2 API、AWS Management Console で動作し、Amazon EC2 On-Demand Capacity Reservations (ODCR)、AWS Savings Plans、Reserved Instances をサポートします。 追加コストなし – 高性能ネットワーキングは追加料金なしで利用できます。起動したインスタンスには標準の EC2 使用料が適用されます。 アーキテクチャの概要 次のアーキテクチャ図は、ODB@AWS の一部として OCI リージョン (Parent Site) が AWS リージョンのアベイラビリティゾーン (Child Site) と OCI 管理ネットワークを介して接続する仕組みを示しています。Amazon EC2/ECS/EKS にデプロイされたアプリケーションサーバーは、ODB ピアリングを通じて ODB@AWS にデプロイされた Oracle データベースに接続します。 始め方 ステップ 1: ODB@AWS ネットワークの作成 AWS Management Console または AWS CLI を使って ODB@AWS ネットワークを作成します。ODB ネットワーク作成のワークフロー完了後、プレイスメントグループが自動的に作成され ODB ネットワークに関連付けられます。 AWS CLI の例: aws odb create-odb-network \ --display-name "mcpg-blog-odbn" \ --availability-zone-id "use1-az4" \ --client-subnet-cidr "X.X.0.0/24" \ --backup-subnet-cidr "Y.Y.0.0/24" \ --tags Key=Project,Value=mCPG-blogpost 出力: { "displayName": "mcpg-odbawsblog", "status": "PROVISIONING", "odbNetworkId": "odbnet_jt85an3z4u"} ステップ 2: プレイスメントグループ ID の取得 ODB ネットワーク作成後、 GetODBNetwork API またはコンソールからプレイスメントグループ ID を取得します。 オプション 1: AWS CLI を使用する方法 ステップ 1 で作成した ODB ネットワークを照会して EC2 プレイスメントグループ ID を取得します。 aws odb get-odb-network --odb-network-id odbnet_jt85an3z4u 出力 (簡潔にフォーマット): { "odbNetwork": { "odbNetworkId": "odbnet_jt85an3z4u", "displayName": "mcpg-odbawsblog", "status": "AVAILABLE", "odbNetworkArn": " arn:aws:odb:us-east-1::odb-network/odbnet_jt85an3z4u" "ec2PlacementGroupIds": ["pg-0e6faa731d3df801e"] } } オプション 2: AWS コンソールを使用する方法 ODB@AWS コンソールに移動し、ODB ネットワークを選択して、ネットワーク詳細セクションでプレイスメントグループ ID を確認します。 ステップ 3: プレイスメントグループを使って EC2 インスタンスを起動する アプリケーション用の Amazon EC2 インスタンスを起動する際、ステップ 2 で取得したプレイスメントグループ ID を指定します。これにより、ODB@AWS データベースの近くにインスタンスが配置され、最適なレイテンシーが実現されます。 AWS CLI の例: aws ec2 run-instances \ --placement GroupId=pg-0e6faa731d3df801e \ --instance-type r6i.large \ --tag-specifications 'ResourceType=instance,Tags=[{Key=Name,Value=ec2-mcpg-odbawsblog}]' \ --image-id <value> \ --count 1 \ --key-name <value> \ --security-group-ids <value> \ --subnet-id <value> EC2 インスタンスのプレイスメントグループ割り当てを確認します。 aws ec2 describe-instances \ --filters "Name=tag:Name,Values=ec2-mcpg-odbawsblog" \ --query 'Reservations[].Instances[].{Name:Tags[?Key==`Name`].Value|[0], PlacementGroup:Placement.GroupId}' \ --output table 出力: +------------------------------------------------------+ | DescribeInstances | +------------------------+-----------------------------+ | Name | PlacementGroup | +------------------------+-----------------------------+ | ec2-mcpg-odbawsblog | pg-0e6faa731d3df801e | +------------------------+-----------------------------+ オプション 2: AWS コンソールを使用する方法 AWS アカウント間でのプレイスメントグループの共有 同じ AWS Organization 内で AWS Resource Access Manager (AWS RAM) を使い、ODB@AWS プレイスメントグループを他の AWS アカウントと共有できます。これにより、異なる AWS アカウントを使用するアプリケーションチームが、ODB@AWS データベースへの低レイテンシー接続に最適化されたプレイスメントで EC2 インスタンスを起動できます。現在、AWS License Manager によるクロス Organization のエンタイトルメント共有は ODB@AWS ではサポートされていません。そのため、プレイスメントグループは同じ AWS Organization 内でのみ共有できます。詳細は 共有プレイスメントグループ を参照してください。 ネットワークレイテンシーの計測 EC2 インスタンスと Oracle Database@AWS (ODB@AWS) 間のネットワークレイテンシーを計測・検証するには、 qperf または iperf3 の使用を推奨します。これらは VM クラスターの Exadata OS イメージにデフォルトで含まれています。アプリケーションをホストする EC2 インスタンスには qperf または iperf3 をインストールする必要があります。これらのツールの使い方の詳細は Oracle Exadata のドキュメントを参照してください。 代替手段として、オープンソースの TCP レベルレイテンシー計測ツールである sockperf も使用できます。sockperf は以下に役立つ補完的なネットワークメトリクスを提供します。 継続的なモニタリングのためのネットワークパフォーマンスベースラインの確立 インフラストラクチャ変更前後のパフォーマンスメトリクスの比較 サブミリ秒のレイテンシー目標が一貫して達成されていることの検証 包括的なパフォーマンス評価には、qperf/iperf3/sockperf の計測と以下の Oracle データベースパフォーマンスツールの組み合わせを推奨します。 Automatic Workload Repository (AWR): 過去のパフォーマンス分析 Active Session History (ASH): リアルタイムのセッションモニタリング SQL Trace: 詳細な SQL 実行分析 ODB@AWS 高性能ネットワーキングのベストプラクティス: プレイスメントグループは選択的に使用する – ODB@AWS はマルチクラウドサービスです。そのため、ネットワーク接続は一般的なオンプレミスデプロイメントとは根本的に異なり、通常は SQL*Net レイテンシーが若干追加されます。一部のワークロードではこの追加レイテンシーは無視できる程度です。他のワークロードでは大きなパフォーマンス低下を引き起こす可能性があります。そのため、プレイスメントグループの使用は安定したサブミリ秒のレイテンシーが本当に必要なワークロードに限定してください。 On-Demand Capacity Reservations (ODCR) を使用する – キャパシティ不足例外 (ICE) の発生リスクを最小化するため、ODB@AWS プレイスメントグループとともに ODCR を使って事前にキャパシティを予約してください。 まとめ 本記事では、Oracle Database@AWS の高性能ネットワーキング機能の使い始めに必要なステップバイステップガイドを提供しました。 ネットワークレイテンシーはアプリケーションパフォーマンスに直接影響し、特にレイテンシーに敏感なアプリケーションで顕著です。AWS アベイラビリティゾーンは複数の物理データセンターにまたがるため、仮想マシン間の物理的な距離がネットワークレイテンシーとアプリケーションパフォーマンスに影響する可能性があります。 ODB@AWS 高性能ネットワーキングは、EC2 プレイスメントグループを自動プロビジョニングし、EC2 上のアプリケーションインスタンスを Oracle Exadata インフラストラクチャの物理的に近い場所に配置することで、この課題に対処します。Oracle クライアント (EC2 上のアプリケーション) と ODB@AWS 上の Oracle Database サーバー間の SQL*Net トラフィックに対して、予測可能なネットワークパフォーマンスを実現します。 著者について Sameer Malik Sameer は、リレーショナルデータベース分野で 23 年以上の経験を持ち、AWS のプリンシパルデータベースソリューションアーキテクトとして Oracle Database@AWS、Amazon RDS、Amazon Aurora を担当しています。多くのお客様のデータベースワークロードの AWS への移行とモダナイゼーションを支援してきました。 Kevin Closson Kevin は、AWS の RDS Commercial Engines グループに所属するプリンシパルデータベースエンジニアです。データベースプラットフォームのパフォーマンスに精通し、Amazon RDS を含むさまざまなプラットフォームの I/O 性能テストに広く使われている SLOB (Silly Little Oracle Benchmark) ツールの作成者です。 この記事は Solutions Architect の 矢木 覚 が翻訳しました。

本記事は 2026 年 4 月 6 日 に公開された「 Navigating backup and recovery options for Oracle Database@AWS 」を翻訳したものです。 Oracle Database@AWS (ODB@AWS) は、 Oracle Cloud Infrastructure (OCI) が管理する Oracle Exadata インフラストラクチャを Amazon Web Services (AWS) データセンター内で直接提供します。Exadata の高性能、スケーラビリティ、高度な機能を活かしながら Oracle データベースを AWS に移行できます。エンタープライズワークロードの運用では、堅牢なデータ保護の維持が重要な課題です。本記事では、ODB@AWS の 2 つのサービス、Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D) と Oracle Autonomous AI Database on Dedicated Exadata Infrastructure (ADB-D) で利用できるバックアップとリカバリのオプションを解説します。 バックアップカテゴリの理解 サービスごとの設定を見る前に、ODB@AWS で利用できる 4 つの主要なバックアップカテゴリを理解しましょう。 自動バックアップ : 設定に基づいて Oracle が完全に管理するバックアップです。一度設定すれば、指定したバックアップ先にデータベースバックアップが自動的に取得されます。 手動 (スタンドアロン) バックアップ : OCI の自動化を使ってユーザーが開始するオンデマンドバックアップです。Exadata Cloud (ExaDB-D) では、保存先が Object Storage または Amazon Simple Storage Service (Amazon S3) の場合、手動バックアップは常に特定時点のフルバックアップになります。保存先が Autonomous Recovery Service の場合は増分バックアップです。Autonomous Database Dedicated (ADB-D) では、手動バックアップがフルバックアップになることはありません。Object Storage または Amazon S3 を使用する場合は常に累積増分バックアップ、Autonomous Recovery Service が保存先の場合は増分バックアップになります。 ユーザー管理バックアップ : dbaascli ユーティリティ、 RMAN 、またはサードパーティツールを使ってユーザーが開始するオンデマンドバックアップです。ただし、これらのバックアップはコントロールプレーンと同期されず、OCI API とも統合されません。 長期バックアップ : 設定に基づいて Oracle が完全に管理するバックアップで、最小 90 日から最大 10 年までの長期保持に使用されます。 バックアップ先の選択 ODB@AWS は自動バックアップ用に 3 つの保存先をサポートしており、それぞれに独自の利点があります。 Amazon S3 : AWS リージョン内にバックアップを保持できるオプションです。S3 は年間 99.999999999% の耐久性と 99.99% の可用性を実現するよう設計されており、 サービスレベルアグリーメント に裏付けられています。 OCI Object Storage : Oracle Object Storage は高い耐久性を持つよう設計されており、年間 99.999999999% (イレブンナイン) の耐久性を提供します。 99.9% の可用性 を実現するよう設計されています。このオプションでは、バックアップは OCI の親リージョンに保存されます。 Autonomous Recovery Service : バックアップの保存先として AWS または OCI リージョンを選択できます。Autonomous Recovery Service は Oracle Cloud Service Descriptions で定義されている月間 99.9% の稼働率コミットメントを提供します。リアルタイムデータ保護により、1 秒未満の RPO を実現し、データ損失の可能性を最小化できます。 次の表は、前述の各 Oracle データベースサービスでサポートされるバックアップオプションをまとめたものです。 Oracle データベースサービス 自動バックアップ 手動バックアップ ユーザー管理バックアップ 長期バックアップ Oracle Autonomous AI Database on Dedicated Exadata Infrastructure 対応 対応 非対応 対応 Oracle Exadata Database Service on Dedicated Infrastructure 対応 対応 対応 非対応 アーキテクチャ: Oracle Database@AWS の基本コンポーネントは アーキテクチャ を、ネットワーク設計は Network Design with Oracle Database@AWS を参照してください。 次のアーキテクチャ図は、バックアップオプションを含む Oracle Database@AWS のトポロジーを示しています。 次の表は、Oracle Database@AWS の両データベースサービスにおけるバックアップオプション、サポートされるバックアップ先、保持期間をまとめたものです。   サービス バックアップタイプ バックアップ先 保持期間 Oracle Autonomous AI Database on Dedicated Exadata Infrastructure 自動 Amazon S3 (デフォルト) (保持ロックとクロスリージョンリストアをサポート) 7〜95 日 OCI Object Storage (クロスリージョンバックアップコピー、クロスリージョンリストア、保持ロックをサポート) 7〜95 日 Autonomous Recovery Service (保持ロックをサポート)、AWS 内で利用可能 7〜95 日 手動 Autonomous Container Database の作成 ステップで選択した自動バックアップ先と同じバックアップ先。 Autonomous Container Database のバックアップ保持設定から継承。 長期バックアップ 自動バックアップが S3 または Autonomous Recovery Service で設定されている場合、長期バックアップはデータベースから Amazon S3 に直接送信されます。自動バックアップ先が Object Storage の場合、長期バックアップは Object Storage に保存されます。 90 日〜10 年 Oracle Exadata Database Service on Dedicated Infrastructure 自動 Amazon S3 (デフォルト) (クロスリージョンリストアをサポート) 7〜60 日 OCI Object Storage 7〜60 日 Autonomous Recovery Service (保持ロックをサポート)、AWS と OCI の両方で利用可能 保護ポリシー Bronze: 14 日 Silver: 35 日 (デフォルト) Gold: 65 日 Platinum: 95 日 ユーザー定義: 14 日〜95 日 手動 Exadata データベースの作成 ステップで選択した自動バックアップ先と同じバックアップ先に保存。 スタンドアロンバックアップは自動バックアップの保持ポリシーの対象外です。削除するまで選択したバックアップ先に保持されます。 ユーザー管理バックアップ Amazon S3、 Amazon FSx 、 Amazon EFS 、Rubrik、Data Domain、Commvault、NetBackup など ユーザー管理 長期バックアップ 現在非サポート 該当なし それでは、各オプションを詳しく見て、前述の両 Oracle データベースサービスでの設定方法を確認しましょう。 Exadata Database Service on Dedicated Infrastructure Exadata Database Service には、Oracle データベースのバックアップとリカバリ操作に以下のオプションがあります。これらのオプションは排他的です。 オプション 1: 自動バックアップ 自動バックアップは、Amazon S3、OCI Object Storage、Autonomous Recovery Service と統合された Oracle 管理のバックアップで、OCI によって完全に管理されます。自動バックアップはデフォルトで有効ですが、不要な場合はデータベースのプロビジョニング時またはその後いつでも無効化できます。AWS と Oracle は、データベースに Oracle 管理の自動バックアップの使用を推奨しています。 Oracle Database@AWS では、OCI コンソールから Oracle Exadata Database Service on Dedicated Infrastructure の自動バックアップを設定する際、以下の 3 つのバックアップ先を選択できます。これらのオプションは排他的です。 Amazon S3 OCI Object Storage Autonomous Recovery Service Exadata データベース 作成時に、前述の各保存先に対する自動バックアップの設定方法を見ていきましょう。 Amazon S3 ODB ネットワークを作成すると、Oracle Database@AWS は Amazon S3 への Oracle 管理バックアップ用のネットワークアクセスを自動的に設定します。OCI が必要な DNS エントリとセキュリティリストを設定し、OCI Virtual Cloud Network (VCN) と Amazon S3 間のトラフィックを可能にします。 OCI コンソールから Amazon S3 への自動バックアップを有効にする方法は Backup Exadata Database を参照してください。 Object Storage OCI コンソールから Object Storage への自動バックアップを有効にする方法は Backup Exadata Database を参照してください。 Autonomous Recovery Service Autonomous Recovery Service はリアルタイムデータ保護を提供し、保護対象データベースから REDO を継続的にサービスへストリーミングすることで 1 秒未満の RPO を実現し、データ損失のリスクを最小化します。リアルタイムデータ保護はオプションの追加コスト機能です。さらに、自動バックアップオーケストレーション、継続的なバックアップ検証、最適化されたリカバリワークフロー、ポリシーベースのライフサイクル管理を提供します。これらの機能により運用負荷が軽減され、信頼性の高い一貫したデータベース保護を実現します。 Autonomous Recovery Service は Oracle Database@AWS をサポートし、データベースが存在するのと同じクラウドプロバイダーのロケーションにバックアップを保存する柔軟性を提供します。Autonomous Recovery Service はデフォルトで保護対象データベースと関連バックアップを OCI に作成しますが、Oracle Database@AWS ではこのデフォルト動作をオーバーライドできます。 保護ポリシー で「Store backups in the same cloud provider as the database」オプションを有効にすると、ポリシーに紐づく保護対象データベースとバックアップは、Oracle データベースがプロビジョニングされているのと同じクラウドプロバイダーのロケーションに保存されます。たとえば Oracle Database@AWS では、保護ポリシーでこのオプションを選択している場合、Autonomous Recovery Service は関連する保護対象データベースのバックアップを AWS 内に保存します。Autonomous Recovery Service を使った自動データベースバックアップで Backup Exadata Database に進む前に、 前提条件 セクションで必要なポリシーの作成とその他の要件を確認してください。これらの前提条件は、Oracle Database@AWS での Autonomous Recovery Service の一般提供 (GA) 開始日である 2025 年 10 月 7 日より前に作成された Oracle Database@AWS デプロイメントにのみ適用されます。GA 後に作成されたデプロイメント (ODB ネットワーク) では、これらの前提条件はデプロイ時に自動的に設定されます。 保護ポリシーで「Store backups in the same cloud provider as the database」オプションを選択しない場合、ポリシーに紐づく保護対象データベースとバックアップは OCI に保存されます。 OCI コンソールから Autonomous Recovery Service への自動バックアップを有効にする方法は Backup Exadata Database を参照してください。 オプション 2: 手動バックアップ スタンドアロンバックアップは、 Exadata データベースの作成 ステップで選択した自動バックアップ先と同じバックアップ先に保存される Oracle データベースバックアップです。Object Storage または Amazon S3 に保存されるスタンドアロンバックアップは、自動バックアップの保持ポリシーの対象外で、削除するまで選択したバックアップ先に残ります。Autonomous Recovery Service を保存先とする場合、スタンドアロンバックアップは保護ポリシーで定義された保持期間に従います。 OCI コンソールから手動バックアップを作成する方法は Backup Exadata Database を参照してください。 オプション 3: Oracle Database@AWS での Amazon S3 へのユーザー管理バックアップ Oracle Database@AWS では、データベースのユーザー管理バックアップ (オンデマンドバックアップ) を作成できます。 dbaascli または RMAN を使ってデータをバックアップし、Amazon S3 バケット、Amazon FSx、Amazon Elastic File System (Amazon EFS)、Object Storage、ローカルファイルシステム、その他の NFS マウントに保存できます。Oracle Database@AWS のマネージドサービスの利点を維持しながら、バックアップスケジュール、保持ポリシー、ストレージコストを完全にコントロールできます。 バックアップは、システムの 設定 に応じて、ローカルファイルシステム、OCI Object Storage、NFS マウントなどさまざまな保存先に送信できます。ユーザー管理バックアップは、Oracle Database@AWS が提供する AWS マネージドバックアップソリューションを補完します。コンプライアンス要件、クロスリージョン災害復旧、既存のバックアップ管理ワークフローとの統合に手動バックアップを活用できます。ユーザー管理バックアップを有効にする方法は Backing up in Oracle Database@AWS を参照してください。 例: dbaascli database backup \ --dbname <DB_NAME> \ --start \ --level0 Oracle Database@AWS では、NetApp、CommVault、Rubrik などのサードパーティツールを使い、RMAN 経由で Exadata Database Service 上のデータベースをバックアップすることもできます。 データベースのリストアオプション このセクションでは、前述のバックアップからのさまざまなデータベースリストアオプションを見ていきます。Exadata Database on Dedicated Infrastructure には以下のリストアオプションがあります。 コンテナデータベース (CDB) のポイントインタイムリストア プラガブルデータベース (PDB) のポイントインタイムリストア 自動またはスタンドアロンバックアップからのリストア リストア先は以下から選択できます。 最新へのリストア: 可能な限りデータ損失を抑えて、データベースを既知の正常な最新状態にリストアします。 タイムスタンプへのリストア: 指定したタイムスタンプにデータベースをリストアします。 SCN へのリストア: 指定した SCN を使ってデータベースをリストアします。SCN は有効である必要があります。 クロスリージョンリストア : Exadata データベースのクロスリージョンリストアでは、Amazon S3 ベースの自動バックアップを使って AWS リージョンをまたいだデータベースリストアを実行できます。 Oracle データベースサービス 方式 最新へのリストア タイムスタンプへのリストア SCN へのリストア インプレース/アウトオブプレースリストア Oracle Exadata Database Service on Dedicated Infrastructure コンテナデータベース (CDB) のポイントインタイムリストア 対応 対応 対応 インプレース プラガブルデータベース (PDB) のポイントインタイムリストア 対応 対応 非対応 インプレース 自動またはスタンドアロンバックアップからのリストア (すべてまたは選択した PDB) 該当なし 該当なし 該当なし アウトオブプレース S3 ベースの自動バックアップからのクロスリージョンリストア 対応 該当なし 該当なし アウトオブプレース アウトオブプレースリストアでは、同一テナンシー内であれば、同じまたは異なるコンパートメント、Exadata インフラストラクチャ、VM クラスターを選択できます。 Autonomous AI Database on Dedicated Infrastructure Autonomous AI Database on Dedicated Exadata Infrastructure は、データベースを自動的にバックアップします。自動バックアップの保持期間は、 Autonomous Container Database (ACD) で選択したバックアップ保持ポリシーに基づき最大 95 日です。この保持期間内の任意の時点にデータベースをリストア・リカバリできます。 Autonomous AI Database は自動バックアップと手動バックアップの両方をサポートします。ACD レベルで定義されたバックアップ保持ポリシーを超えて保持される長期バックアップも作成できます。バックアップ中もデータベースは完全に機能しますが、ライフサイクル管理操作は許可されません。たとえば、バックアップ中のデータベース停止はできません。Autonomous Database を終了しても、Object Storage、Amazon S3、Autonomous Recovery Service に保存されたバックアップは削除されません。自動バックアップは最低 72 時間、または選択した保持期間の全期間にわたって保持されます。長期バックアップは、明示的に削除されるか期限切れになるまで、また ACD の保持ロックが有効な場合は期限切れ後にのみ削除されます。 オプション 1: 自動バックアップ 自動バックアップはデフォルトで有効ですが、Oracle Cloud Infrastructure (OCI) コンソールから ACD のプロビジョニング時に無効化できます。自動バックアップを有効にしてプロビジョニングを完了した後は、ACD の自動バックアップを無効化できません。 AWS と Oracle は、データベースに Oracle 管理の自動バックアップの使用を推奨しています。 Oracle Database@AWS では、OCI コンソールで Autonomous Database on Dedicated Infrastructure の バックアップ先 として以下の 3 つを選択できます。 Amazon S3 (デフォルト) OCI Object Storage Autonomous Recovery Service Amazon S3 OCI コンソールから Amazon S3 への自動バックアップを有効にする方法は Backup Autonomous AI Database を参照してください。 Object Storage OCI コンソールから Object Storage への自動バックアップを有効にする方法は Backup Autonomous AI Database を参照してください。 オプション 2: 手動バックアップ Autonomous Database が自動的に作成するバックアップに加えて、Oracle Cloud Infrastructure (OCI) コンソールからオンデマンドの手動バックアップも作成できます。たとえば、大きな変更の前にバックアップを取得しておくと、リストアとリカバリを高速化できます。これらのバックアップは、ACD で選択したバックアップ保持ポリシー (期間) に応じて 最大 95 日 保持されます。手動バックアップは、最後のフルバックアップ以降のすべての増分バックアップを含む累積増分バックアップです。手動バックアップは一般に、必要時のリストア・リカバリの高速化やデータベースクローン (開発/テスト) のため、本番稼働開始などの大きな節目の前に取得します。 オプション 3: 長期バックアップ 通常のオンデマンドバックアップとは別に、OCI コンソールの Autonomous Database の詳細ページから長期バックアップも作成できます。長期バックアップは、ACD のバックアップが S3 または Autonomous Recovery Service で設定されている場合はデータベースから Amazon S3 に直接、ACD のバックアップが Object Storage を使用する場合は Object Storage に直接送信される Oracle データベースバックアップです。長期バックアップは、ACD レベルで定義されたバックアップ保持ポリシー (期間) を超えて保持されます。長期バックアップの作成時に、90 日から 10 年の範囲で保持期間を指定できます。 Oracle Database@AWS は、Autonomous Database on Dedicated Infrastructure のユーザー管理バックアップをサポートしていません。OCI コンソールから長期バックアップを有効にする方法は Backup Autonomous AI Database を参照してください。 バックアップの種類 バックアップの種類は、データベースサービスと保存先によって異なります。フル、増分、累積増分の各バックアップの違いを理解すると、ユースケースに最適なオプションを選択しやすくなります。 フルバックアップ : バックアップ時点のデータベース内のすべてのデータブロックを取得するバックアップ。 増分バックアップ : 直近のバックアップ (フルまたは増分) 以降に変更されたブロックのみを取得するバックアップ。 累積増分バックアップ : 間に何回増分バックアップが取得されたかにかかわらず、最後のフルバックアップ以降に変更されたすべてのブロックを取得するバックアップ。 プラットフォーム バックアップ操作 バックアップ先 バックアップタイプ RPO ADB-D 自動 Object Storage 週次フル、日次増分、アーカイブログは 15 分ごと 15 分 Amazon S3 週次フル、日次増分、アーカイブログは 15 分ごと 15 分 Autonomous Recovery Service 初回フル、以降は増分のみ、アーカイブログは 15 分ごと。 15 分 手動 Object Storage 累積増分 該当なし Amazon S3 累積増分 該当なし Autonomous Recovery Service 増分 該当なし 長期バックアップ Object Storage フル 該当なし Amazon S3 フル 該当なし ExaDB-D 自動 Object Storage 週次フル、日次増分、アーカイブログはデフォルトで 30 分ごと (15 分に短縮可能)。 30 分 Amazon S3 週次フル、日次増分、アーカイブログはデフォルトで 30 分ごと (15 分に短縮可能)。 30 分 Autonomous Recovery Service 初回フル、以降は増分のみ、アーカイブログは 30 分ごと。リアルタイムデータ保護を有効にすると REDO ログがリアルタイムでストリーミングされ、1 秒未満の RPO を実現 リアルタイムデータ保護ありの場合、RPO は 1 秒未満。なしの場合は 30 分。 手動 Object Storage フル 該当なし Amazon S3 フル 該当なし Autonomous Recovery Service 増分 該当なし 長期バックアップ 非サポート 該当なし 該当なし ADB-D でのデータベースクローン: Autonomous Database は柔軟なクローン機能を提供しており、ソース環境に影響を与えることなく、開発、テスト、分析、データ移動のシナリオ向けに新しいデータベースインスタンスを迅速に作成できます。クローンは、既存データベースの状態に基づきつつ論理的に独立した新しい Autonomous Database を作成します。 フルクローン : すべてのデータ、メタデータ、設定を含むソースデータベースの完全なコピーを作成し、オリジナルとまったく同じように動作する完全なレプリカを作成します。 メタデータクローン : 一方、メタデータクローンは、オブジェクトに保存されているデータを含めず、データベースのメタデータ (スキーマ、テーブル、ユーザー、ロール、その他の構造定義) のみをコピーします。メタデータクローンは、ストレージ消費とクローン作成時間を最小限に抑えつつ、開発やテスト用のスキーマのみの一貫した環境を迅速に作成するのに最適です。 Oracle データベースサービス 方式 データベースインスタンス バックアップのポイントインタイム リストからのバックアップ 最新バックアップのタイムスタンプ Oracle Autonomous AI Database on Dedicated Exadata Infrastructure ADB フルクローン 対応 対応 対応 対応 ADB メタデータクローン 対応 非対応 非対応 非対応 ACD フルクローン ACD 内のすべての ADB 非対応 非対応 対応 データベースのリストアオプション このセクションでは、前述のバックアップからのさまざまなデータベースリストアオプションを見ていきます。Autonomous Database on Dedicated Infrastructure には以下のリストアオプションがあります。 自動バックアップからのリストア 手動バックアップからのリストア 以下のいずれかのオプションでデータベースをリストアできます。 特定のバックアップを使ったデータベースのリストア OCI コンソールからタイムスタンプを使ったポイントインタイムリカバリ OCI コンソールから特定の System Change Number (SCN) を使ったデータベースのリストア リストア実行中、データベースは使用不可 (unavailable) 状態になります。この状態のデータベースには接続できません。使用不可状態でサポートされるライフサイクル管理操作は終了 (terminate) のみです。リストア操作が完了すると、データベースはリストア前と同じ状態で開かれます。3 種類のリストア (SCN 指定、タイムスタンプ指定、特定バックアップ指定) のいずれでも、リストア完了時に SCN が返されます。 Oracle データベースサービス 方式 選択したバックアップへのリストア タイムスタンプへのリストア SCN へのリストア インプレース/アウトオブプレースリストア Oracle Autonomous AI Database on Dedicated Exadata Infrastructure 自動バックアップからのリストア (PITR をサポート) 対応 対応 対応 インプレース 手動バックアップからのリストア 対応 該当なし 該当なし インプレース 長期バックアップからのリストア 対応 該当なし 該当なし アウトオブプレース Amazon S3 および OCI OSS ベースの自動バックアップからのクロスリージョンリストア 対応 該当なし 該当なし アウトオブプレース 組み込みのセキュリティと暗号化 Transparent Data Encryption (TDE) は、データベースのデータファイルだけでなく、データベースから作成されるすべてのバックアップも保護します。TDE はデフォルトで有効であり、Autonomous Database と Exadata Database では必須です。OCI Object Storage、Amazon S3、Autonomous Recovery Service のいずれに保存されるバックアップも、データベースを保護するのと同じ TDE マスター暗号化キーで自動的に暗号化されます。TDE マスターキーは以下の 2 つの方法のいずれかで管理できます。 Oracle 管理キー カスタマー管理キー : OCI Vault AWS Key Management Service (AWS KMS) (ExaDB-D のみサポート) Oracle Key Vault (OKV) Oracle 管理キー Oracle 管理キーでは、データベースブロックとバックアップの暗号化に使用される TDE マスターキーを Oracle が自動的に作成、ローテーション、保護します。 バックアップへの影響: Object Storage、S3、Recovery Service に保存されるすべてのバックアップは、デフォルトで完全に暗号化されます。 Oracle 管理の TDE マスターキーへのアクセスなしにバックアップデータを復号することはできません。 キーのライフサイクル管理の運用負荷をゼロにしたいお客様に最適です。 すべてのバックアップ先で機能します。 カスタマー管理キー (OCI Vault または AWS KMS) OCI Vault、Oracle Key Vault (OKV)、または AWS KMS を使って TDE マスターキーを自分で管理することもできます。 バックアップへの影響: データベースは、お客様が管理する TDE マスターキーですべてのバックアップデータを暗号化します。 バックアップへのアクセスには Vault または KMS キーへのアクセスが必要となり、暗号化、ローテーション、無効化、削除を完全にコントロールできます。 キーを無効化または削除すると、関連するすべてのバックアップが即座に読み取り不能になります。コンプライアンスには有効ですが、慎重なガバナンスが必要です。 強力な監査性とエンタープライズセキュリティポリシーへの準拠を実現します。 料金 各バックアップ先のバックアップコストの最新の料金情報は、 Oracle Database@AWS の料金 ページを参照してください。 Amazon S3 をバックアップ先とする場合、 VPC Lattice 経由のデータ転送コストが発生します。詳細は Amazon VPC Lattice の料金 ページを参照してください。 Recovery Service は消費量の計算に virtualized GB (vGB) を使用します。これは、暦月中に週次フルバックアップ、日次増分バックアップ、アーカイブ REDO ログバックアップが使用するストレージ消費量の合計です。 ベストプラクティス Oracle は、運用効率のため、特に本番環境では自動バックアップの設定を推奨しています。 ビジネス要件に応じてバックアップ保持期間を設定し、保持期間を定期的に見直して必要に応じて調整してください。 ExaDB-D デプロイメントでは、パフォーマンスへの影響を軽減するため、システムのアクティビティが最小限になる業務時間外にバックアップウィンドウをスケジュールしてください。 厳格なバックアップの不変性 (イミュータビリティ) 要件には、保持ロック付きの保護ポリシーを使い、作成から保持期間の終了までバックアップを保護してください。Recovery Service をバックアップ先とする Exadata Database Service on Dedicated Infrastructure では、特権ユーザーであっても早期削除の可能性を排除できます。 Autonomous AI Database では、組み込みの クローン機能 (フルクローンまたはメタデータクローン) を使って非本番環境をリフレッシュしてください。 ExaDB-D デプロイメントでは、手動およびユーザー管理バックアップを見直し、不要であれば削除してください。 90 日から 10 年の長期保持が必要なデータには 長期バックアップ を取得してください。 Oracle データベースでほぼゼロの RPO を実現するには、Autonomous Recovery Service の リアルタイムデータ保護 機能を使用してください。データベーストランザクションと REDO ログをリアルタイムで Recovery Service に継続的に転送し、潜在的なデータ損失を 1 秒未満に抑え、任意の時点への迅速なリカバリを可能にします。リアルタイムデータ保護は追加コストのオプションです。 Autonomous AI Database では、OCI Object Storage を使った低コストの DR (災害復旧) ソリューションとして クロスリージョンバックアップ を有効にしてください。 保持ロックを有効にすると、すべての ACD および Autonomous AI Database のバックアップ (長期バックアップを含む) が保持期間の全期間にわたって保持されます。保持期間が終了するまでこれらのバックアップは削除できません。この設定の無効化には 14 日間の猶予期間があります。 Exadata Database Service on Dedicated Infrastructure で Data Guard を使って Maximum Availability Architecture Gold 以上を構成している場合、ベストプラクティスとしてコスト最適化のためスタンバイインスタンスのバックアップを無効化してください。ストレージコストの重複を回避でき、バックアップはプライマリインスタンスから取得できます。また、プライマリとスタンバイの両インスタンスでバックアップ先を同一にする必要があります。 まとめ 本記事では、Oracle Exadata Database Service on Dedicated Infrastructure と Oracle Autonomous AI Database on Dedicated Exadata Infrastructure の両方で利用できる Oracle Database@AWS (ODB@AWS) のバックアップとリカバリ機能を包括的に解説しました。自動、手動、ユーザー管理、長期の各バックアップオプションと、Amazon S3、OCI Object Storage、Autonomous Recovery Service といったサポートされるバックアップ先について説明しました。 また、保持ポリシー、リストアシナリオ、ポイントインタイムリカバリ (PITR) のオプションも確認しました。これにより、組織の RPO と RTO の目標に合わせた堅牢なデータ保護と災害復旧 (DR) 戦略を設計できます。AWS ネイティブ統合と Oracle 管理の自動化を活用することで、運用のシンプルさとスケーラビリティを維持しながら、データの耐久性、セキュリティ、事業継続性を高められます。 まずはワークロード要件に最適なバックアップオプションを設定し、リストアプロセスを検証し、環境でのリカバリパフォーマンスを評価してみてください。経験、フィードバック、学びをコメント欄でぜひ共有してください。 著者について Javeed Mohammed Javeed は、Amazon Web Services (AWS) のシニアデータベーススペシャリストソリューションアーキテクトです。Amazon RDS チームで Oracle や Db2 などの商用データベースエンジンを担当し、お客様の AWS でのリレーショナルデータベースワークロードの設計、デプロイ、最適化を支援しています。 Nishanth Sodum Nishanth は、Oracle のシニアプリンシパルソリューションアーキテクトで、Oracle Cloud Infrastructure プロダクトマネジメント組織に所属しています。マルチクラウドソリューションの推進と Oracle Database @ Hyperscalers の成長に注力しています。 Karthik Gopalakrishnan Karthik は、AWS のシニアテクニカルプロダクトマネージャーとして、エンジニアリング、GTM、セールス・マーケティングの各チームと連携し Oracle Database@AWS の提供を担当しています。お客様のニーズと課題を製品ソリューションに変えることに情熱を注いでいます。 この記事は Solutions Architect の 矢木 覚が翻訳しました。

本記事は 2026 年 1 月 12 日 に公開された「 Provision Oracle Database@AWS stack using AWS CloudFormation 」を翻訳したものです。 Oracle Database@AWS (ODB@AWS) は、 Oracle Cloud Infrastructure (OCI) が管理する Oracle Exadata インフラストラクチャを AWS データセンター内から提供します。Exadata の高性能、スケーラビリティ、高度な機能を活かしながら Oracle データベースを AWS に移行できます。Oracle Database@AWS は、 Amazon Simple Storage Service (Amazon S3)、 zero-ETL パイプライン、 AWS Key Management Service (AWS KMS) などのネイティブ AWS サービスとの深い統合を提供します。Oracle データベースは Amazon Elastic Compute Cloud (Amazon EC2)、Amazon Elastic Container Service (Amazon ECS)、Amazon Elastic Kubernetes Service (Amazon EKS) などにデプロイされたアプリケーションと並行して実行できます。この緊密な統合によりデータフローが簡素化され、セキュリティが強化され、多様なコンピューティング環境全体でのアプリケーション開発が加速します。 Oracle Database@AWS は現在、以下の Oracle Database サービスを提供しています。 Oracle Autonomous AI Database on Dedicated Exadata Infrastructure (ADB-D) Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D) Infrastructure as Code (IaC) は、構成ファイルを使ってアプリケーションのインフラストラクチャをプロビジョニング・管理するプロセスです。IaC はインフラストラクチャ管理の一元化、リソースの標準化、迅速なスケールを可能にし、新しい環境を再現可能で信頼性が高く一貫したものにします。Oracle Database@AWS のリソースは、 Terraform や AWS CloudFormation などの IaC ツールを使ってデプロイできます。 AWS CloudFormation は、AWS およびサードパーティのリソースを簡単にモデル化、プロビジョニング、管理できる IaC サービスです。AWS リソースのモデル化とセットアップを支援し、リソース管理に費やす時間を減らして AWS 上のアプリケーションに集中できるようにします。 本記事では、 AWS CloudFormation テンプレート を使って、 ODB ネットワーク 、 Oracle Exadata インフラストラクチャ 、 Exadata VM クラスター 、 Autonomous VM クラスター など Oracle Database@AWS の主要コンポーネントをセットアップする方法を説明します。 ソリューションの概要 Oracle Database@AWS を始めるには、 AWS Marketplace でリスティングを確認します。サービスを利用するには、AWS アカウント内で オンボーディング と呼ばれるプロセスで設定します。オンボーディングを開始するには、Oracle の担当者に連絡して Private Offer をリクエストします。料金と条件に合意した後、AWS Marketplace で購入を完了します。購入完了後、AWS アカウントと OCI テナンシーをリンクします。これをマルチクラウドリンクと呼びます。要件に応じて、 エンタイトルメント共有機能 を使い、同じ AWS Organization 内の AWS アカウント間で ODB@AWS の AWS Marketplace エンタイトルメントを共有できます。オンボーディング完了後、Exadata Database Service on Dedicated Infrastructure および Autonomous AI Database on Dedicated Exadata Infrastructure 向けに Oracle Database@AWS のシステムリソースのプロビジョニングを開始できます。プロビジョニングは ODB ネットワークと Exadata インフラストラクチャの作成から始まります。ワークロードと要件に応じて、Oracle Exadata Database Service 用の Exadata VM クラスター、または Autonomous AI Database on Dedicated Exadata Infrastructure 用の Autonomous VM クラスターを作成します。 Oracle Database@AWS の使用を開始するには、Oracle Database@AWS コンソール、AWS CLI、または API を使って以下のリソースを作成します。 ODB ネットワーク Oracle Exadata インフラストラクチャ Exadata VM クラスターまたは Autonomous VM クラスター ODB ピアリング接続 次の図は Oracle Database@AWS のアーキテクチャを示しています。 詳細に入る前に、Oracle Database@AWS のアーキテクチャと主要コンポーネントを理解することが重要です。 Amazon Virtual Private Cloud とサブネット : Amazon Virtual Private Cloud (Amazon VPC) は、定義した仮想ネットワーク内に AWS リソースを起動できます。この仮想ネットワークは自社データセンターで運用する従来型ネットワークに似ていますが、AWS のスケーラブルなインフラストラクチャを利用できます。VPC を作成した後、サブネットを追加できます。サブネットは Amazon VPC 内の IP アドレス範囲です。特定のサブネットに Amazon EC2 インスタンスなどの AWS リソースを作成できます。 OCI Virtual Cloud Network (VCN) とサブネット : Virtual Cloud Network (VCN) は、指定した Oracle リージョン内の OCI テナンシーにセットアップするカスタマイズ可能なプライベートネットワークです。コンピュートインスタンス、データベース、ストレージなどの OCI リソースをデプロイ・管理するための安全でスケーラブルなネットワーク環境を提供します。VCN はサブネット、ルートテーブル、ゲートウェイなどの主要コンポーネントを含む従来型ネットワークの仮想版です。VCN により、論理的に分離されたネットワーク内でクラウドリソースを分離・セグメント化し、セキュリティと管理性を向上できます。VCN はサブネットに分割され、リソースのセグメント化とトラフィック制御をより細かく行えます。サブネットはパブリック (パブリック IP アドレスとインターネットアクセスを許可) またはプライベート (直接のインターネットアクセスを制限) にできます。Oracle マルチクラウドアーキテクチャでは、AWS リージョンにクライアントサブネットとバックアップサブネットを持つ ODB ネットワークを作成すると、ペアリングされた OCI リージョンの OCI テナンシーに対応する OCI VCN とサブネットが自動的に作成されます。 OCI リージョン (Parent Site): OCI リージョンは、アベイラビリティドメインと呼ばれる 1 つ以上のデータセンターを持つ地理的エリアです。Oracle マルチクラウドモデルでは、ペアリングされた AWS リージョンに接続する OCI リージョンを Parent Site と呼びます。ODB@AWS は リージョン可用性 で説明されているリージョンでのみ利用できます。各 OCI リージョンは他のリージョンとは独立して動作し、耐障害性と災害復旧機能を提供します。各リージョンは 1 つ以上のアベイラビリティドメインで構成されます。OCI アベイラビリティドメイン (AD) は OCI リージョン内の 1 つ以上のデータセンターです。複数の AD があるリージョンでは、AD は物理的に分離されています。インフラストラクチャ、電源、冷却、内部ネットワークを共有しないため、1 つの AD の障害が同じリージョン内の他の AD に影響する可能性は低いです。 OCI Child Site : OCI Child Site は、OCI アベイラビリティドメイン (AD) を AWS リージョン内のアベイラビリティゾーン (AZ) に拡張するデータセンターです。OCI Child Site モデルでは、Oracle Database@AWS に使用される Exadata インフラストラクチャは物理的には AWS データセンター (AWS リージョン内の AZ) に存在しますが、論理的には OCI リージョンとそのネットワークコンポーネントにマッピングされます。 ODB ネットワーク : ODB ネットワークは、指定した AWS アベイラビリティゾーン (AZ) 内で Oracle Exadata VM クラスターと Autonomous VM クラスターをホストするプライベートな分離されたネットワークです。ODB ネットワークは IP アドレスの CIDR 範囲で構成されます。ODB ネットワークは OCI Child Site 内のネットワークに直接マッピングされ、AWS と OCI 間の通信を可能にします。Oracle マルチクラウドアーキテクチャでは、ODB ネットワークは Oracle Database@AWS サービスの一部である OCI コンポーネントへのネットワーク接続を提供します。ODB ネットワーク作成時に指定する情報は以下のとおりです。 アベイラビリティゾーン — ODB ネットワークは特定の AZ に紐づきます。本記事執筆時点では、以下の AWS リージョンで Oracle Database@AWS を利用できます。 US East (N. Virginia) 物理 ID use1-az4 および use1-az6 の AZ を使用できます。 US West (Oregon) 物理 ID usw2-az3 および usw2-az4 の AZ を使用できます。 Asia Pacific (Tokyo) 物理 ID apne1-az1 および apne1-az4 の AZ を使用できます。 US East (Ohio) 物理 ID use2-az1 および use2-az2 の AZ を使用できます。 Europe (Frankfurt) 物理 ID euc1-az1 および euc1-az2 の AZ を使用できます。アカウント内で上記の物理 AZ ID にマッピングされる論理 AZ 名を確認するには、次のコマンドを実行します。 aws ec2 describe-availability-zones \ --region us-east-1 \ --query "AvailabilityZones[*].{ZoneName:ZoneName, ZoneId:ZoneId}" \ --output table クライアント CIDR アドレス — ODB ネットワークには、Exadata VM クラスターと Autonomous VM クラスター用の クライアントサブネット CIDR が必要です。 バックアップ CIDR アドレス — ODB ネットワークには、VM クラスターのマネージドデータベースバックアップ用の バックアップサブネット CIDR が必要です。バックアップサブネットは Exadata VM クラスターではオプションです。 AWS サービス統合 — Amazon S3 や Amazon Redshift との zero-ETL など、AWS サービス統合のネットワークパスを設定できます。詳細は AWS サービス統合 を参照してください。CIDR 要件の詳細は ODB ネットワークの作成 を参照してください。 Oracle Exadata インフラストラクチャ : Oracle Exadata インフラストラクチャは、Oracle データベース実行用に設計された高性能で統合されたハードウェア・ソフトウェアプラットフォームです。Exadata は事前構成・事前テスト済みのフルスタックプラットフォームであり、必要なハードウェアとソフトウェアコンポーネントがすべて統合・最適化されシームレスに連携します。Exadata はスケールアウトアーキテクチャを採用し、データベースサーバーとインテリジェントストレージサーバーを変化するワークロード要求に応じて個別にスケールできます。Exadata ストレージサーバーは従来型ストレージを超え、独自の CPU と専用ソフトウェアにより、SQL クエリ処理などのデータベース操作をデータの近くで実行できます。Exadata は高帯域幅・低レイテンシーのネットワークファブリック (RDMA over Converged Ethernet / RoCE など) を使ってデータベースサーバーとストレージサーバーを接続し、高速なデータアクセスと転送を実現します。Oracle マルチクラウドアーキテクチャでは、Exadata インフラストラクチャは Oracle Exadata Database Service と Oracle Autonomous AI Database の両方の基盤ハードウェアです。Oracle Database@AWS で Exadata インフラストラクチャを作成する際に指定する情報は以下のとおりです。 データベースサーバーの合計数 ストレージサーバーの合計数 Exadata システムモデル (X11M) インフラストラクチャをホストする AZ ( Oracle Database@AWS のサポートリージョン を参照) 詳細は Exadata インフラストラクチャ を参照してください。 Exadata VM クラスター : Exadata VM クラスター は、密結合された Exadata VM のセットです。各 VM には Oracle Real Application Clusters (Oracle RAC) や Oracle Grid Infrastructure など Oracle Enterprise Edition のすべての機能を含む完全な Oracle データベースインストールがあります。VM クラスター上に 1 つ以上の Oracle Exadata データベースを作成できます。VM と VM クラスターのアーキテクチャ図は Exadata Database Service on Dedicated Infrastructure Technical Architecture を参照してください。 VM クラスター 作成時に指定する情報は以下のとおりです。 ODB ネットワーク Oracle Exadata インフラストラクチャ クラスター内の VM を配置するデータベースサーバー 使用可能な Exadata ストレージの合計量 作成方法の詳細は Exadata VM クラスター を参照してください。 Autonomous VM クラスター : Autonomous VM クラスター (AVMC) は、物理的な Exadata クラスター (マシン) を複数の仮想クラスターに分割できます。個別のアクセスルール、ネットワーク設定、カスタマイズ可能なコンピュートメモリやストレージリソースにより、異なるデータベースワークロードの環境を分離できます。AVMC は、Autonomous Container Database が構築される 4 層データベースアーキテクチャモデルのインフラストラクチャコンポーネントの 1 つです。Exadata Infrastructure (EI) リソース内に 1 つ以上の AVMC がプロビジョニングされ、EI とデプロイ内の Autonomous Container Database リソースを接続します。Autonomous VM クラスター作成時に VM あたりの ECPU コア数、CPU あたりのデータベースメモリ、データベースストレージ、Autonomous Container Database の最大数を設定できます。詳細は Autonomous VM クラスターの作成 を参照してください。 ODB ピアリング : ODB ピアリングは、Amazon VPC と ODB ネットワーク間でトラフィックをプライベートにルーティングするためのユーザー作成のネットワーク接続です。Oracle マルチクラウドアーキテクチャでは、VPC 内のアプリケーションと ODB ネットワーク内の Oracle データベース間のトラフィックは、パブリックインターネットを経由せず ODB ピアリングを通じてプライベートにルーティングされます。詳細は ODB ピアリング接続の作成 を参照してください。 Oracle Exadata データベース : Oracle Database@AWS では、AWS コンソールを使って Exadata データベースをホストする Oracle Exadata インフラストラクチャと VM クラスターを作成します。Oracle データベースの作成と管理には OCI API を使用します。データベースの作成方法の詳細は Exadata データベース と Autonomous Database を参照してください。 Oracle Database@AWS のコンポーネントの詳細は アーキテクチャ を参照してください。 上記リソースの作成手順の詳細は Oracle Database@AWS でのリソース作成 を参照してください。 前提条件 開始前に、以下の前提条件を満たしていることを確認してください。 CloudFormation とテンプレートの使い方 の基本的な理解 Oracle Database@AWS サービスの理解 Oracle Database@AWS へのオンボーディング の手順を完了していること。Oracle Database@AWS を使用するには Private Offer を受諾済みである必要があります。 Oracle Database@AWS リソースのプロビジョニングを許可するポリシー権限 を IAM プリンシパルに付与していること。Oracle Database@AWS の使用にはこれらの権限が必要です。 以下の AWS CloudFormation テンプレートを使って Oracle Database@AWS のさまざまなリソースをプロビジョニングできます。ビジネス要件に応じてパラメータをカスタマイズしてください。各パラメータの意味と許容値を理解することが重要です。 本記事執筆時点で利用可能なテンプレートは以下のとおりです。最新情報は AWS CloudFormation による Oracle Database@AWS のプロビジョニング を参照してください。 ステップ 1: Oracle Database@AWS に ODB ネットワークを作成する Type: AWS::ODB::OdbNetwork Properties: AvailabilityZone: String AvailabilityZoneId: String BackupSubnetCidr: String ClientSubnetCidr: String CustomDomainName: String DefaultDnsPrefix: String DeleteAssociatedResources: Boolean DisplayName: String S3Access: String S3PolicyDocument: String Tags: - Tag ZeroEtlAccess: String IP アドレス要件の詳細は Oracle Database@AWS での IP アドレス空間の計画 を参照してください。 ステップ 2: Oracle Database@AWS に Oracle Exadata インフラストラクチャを作成する Type: AWS::ODB::CloudExadataInfrastructure Properties: AvailabilityZone: String AvailabilityZoneId: String ComputeCount: Integer CustomerContactsToSendToOCI: - CustomerContact DatabaseServerType: String DisplayName: String MaintenanceWindow: MaintenanceWindow Shape: String StorageCount: Integer StorageServerType: String Tags: - Tag ステップ 3: Oracle Database@AWS に Exadata VM クラスター または Autonomous VM クラスター を作成する Type: AWS::ODB::CloudVmCluster Properties: CloudExadataInfrastructureId: String ClusterName: String CpuCoreCount: Integer DataCollectionOptions: DataCollectionOptions DataStorageSizeInTBs: Number DbNodes: - DbNode DbNodeStorageSizeInGBs: Integer DbServers: - String DisplayName: String GiVersion: String Hostname: String IsLocalBackupEnabled: Boolean IsSparseDiskgroupEnabled: Boolean LicenseModel: String MemorySizeInGBs: Integer OdbNetworkId: String ScanListenerPortTcp: Integer SshPublicKeys: - String SystemVersion: String Tags: - Tag TimeZone: String Type: AWS::ODB::CloudAutonomousVmCluster Properties: AutonomousDataStorageSizeInTBs: Number CloudExadataInfrastructureId: String CpuCoreCountPerNode: Integer DbServers: - String Description: String DisplayName: String IsMtlsEnabledVmCluster: Boolean LicenseModel: String MaintenanceWindow: MaintenanceWindow MemoryPerOracleComputeUnitInGBs: Integer OdbNetworkId: String ScanListenerPortNonTls: Integer ScanListenerPortTls: Integer Tags: - Tag TimeZone: String TotalContainerDatabases: Integer ステップ 4: ODB ピアリング接続を作成する Type: AWS::ODB::OdbPeeringConnection Properties: DisplayName: String OdbNetworkId: String PeerNetworkId: String Tags: - Tag CloudFormation スタックの作成 AWS CloudFormation でリソースをプロビジョニングするには、以下の手順を実行します。この CloudFormation テンプレートは以下のリソースを作成します。 VPC インターネットゲートウェイ パブリックサブネット 2 つ プライベートサブネット 2 つ パブリックルートテーブル プライベートルートテーブル パブリックルート 4 つのサブネットすべてへのルートテーブルアソシエーション ODB ネットワーク ODB ピアリング接続 Exadata インフラストラクチャ Exadata VM クラスター Autonomous VM クラスター デプロイ前にテンプレートをよく確認し、不要なリソースがあればテンプレートを適宜修正してください。 ローカルマシンに GitHub リポジトリ をクローンするか、AWS Samples からスクリプトをダウンロードします。 git clone https://github.com/aws-samples/sample-odb-launch-using-cfn GitHub の readme に従って前提条件を確認し、CloudFormation スタックをデプロイします。 スタックのデプロイが完了したことを確認します。 重要: AWS CloudFormation で ODB@AWS をデプロイする際、特定のリソースプロパティの変更はインプレース更新ではなく完全なリソース置換が必要になることに注意してください。CpuCoreCount や DbServers の設定などのプロパティを変更すると置換がトリガーされます。変更を実装する前に、置換が必要なプロパティの完全なリストについて AWS CloudFormation ドキュメント を確認してください。 リソースの作成が完了したら、以下の方法で AWS Virtual Private Cloud (VPC) と Oracle Database@AWS の ODB ネットワーク間の接続を設定します。 OdbPeeringConnection 用の VPC ルートテーブルの設定 Oracle Database@AWS 用の DNS の設定 アウトバウンドエンドポイント — ODB ネットワークに DNS クエリを送信するために必要です。 リゾルバールール — Route 53 Resolver が ODB ネットワークの DNS に転送する DNS クエリのドメイン名を指定します。 詳細は ネットワーク設定 を参照してください。 クリーンアップ このセットアップが不要になり将来の課金を避けたい場合は、セットアップで作成した ODB ネットワーク、Exadata インフラストラクチャ、VM クラスターのリソースを削除できます。AWS CloudFormation スタックの一部として起動したその他のリソースをすべて削除するには、以下の手順を実行します。 AWS CloudFormation コンソールのナビゲーションペインで スタック を選択します。 作成したスタックを選択し、 削除 を選択します。 プロンプトが表示されたら スタックの削除 を選択します。 詳細は AWS CloudFormation コンソールでのスタックの削除 を参照してください。 まとめ 本記事では、AWS CloudFormation を使って Oracle Database@AWS のリソースをデプロイする方法を紹介しました。 開始方法の詳細は Oracle Database@AWS の開始方法 を参照してください。 著者について Javeed Mohammed Javeed は、AWS のシニアデータベーススペシャリストソリューションアーキテクトです。Amazon RDS チームで Oracle や Db2 などの商用データベースエンジンを担当し、お客様の AWS クラウドでのリレーショナルデータベースワークロードの設計、デプロイ、最適化を支援しています。 Sharath Chandra Kampili Sharath は、AWS のデータベーススペシャリストソリューションアーキテクトです。Amazon RDS チームで Oracle などの商用データベースエンジンを担当し、お客様のデータベースプロジェクトに対するガイダンスと技術支援を直接提供しています。 Kai Sawamoto Kai は、Oracle Database@AWS チームのソフトウェア開発エンジニアです。ODB と CloudFormation の統合を担当し、CloudFormation との追加機能統合のメンテナンスと提供に取り組んでいます。 この記事は Solutions Architect の 矢木 覚 が翻訳しました。

2026年6月25日〜26日、幕張メッセで開催された AWS Summit Japan 2026 にて、AWSの鉄道ブースで業界向けに2つの展示を行いました。本ブログではその展示内容をご紹介します。 会場の「AWS for Railway/Logistics」展示エリアで、多くの来場者をお迎えしました。 今回は以下の2つの展示を行いました。 展示①：鉄道設備保全プラットフォーム — AIエージェントと地理情報システム（GIS）を統合した保全の仕組み 展示②：「クローズド」をクラウドで読み解く — 国土交通省ガイドライン第6版から考えるOT/IT設計アプローチ 展示① 鉄道設備保全プラットフォーム 本展示は、2025年11月の鉄道技術展2025（ ブログ ）で展示した鉄道保全ソリューションを、いただいたフィードバックを踏まえさらに発展させたものです。 鉄道保全の現場が直面する課題 鉄道設備の保全現場では、構造的な課題が深刻化しています。 保全の担い手の減少 — 生産年齢人口の減少に伴い、鉄道設備のメンテナンスに従事する技能労働者が減少しています。ベテランが退職していく中で、その現場ノウハウをどう残し、どう伝えるかが喫緊の課題です。 保全対象機器の増加 — 従来の鉄道機械に加え、ホームドアなどの旅客サービス向上のための新機器が増加しています。「省力化」のために導入した機械が、逆にメンテナンス対象を増やしていくというジレンマが生じています。 情報資産の複雑化 — 作業記録、設備マニュアル、保守履歴といった非構造化データが各所に散在し、個別最適を繰り返した結果、業務システムがサイロ化しています。 人が減り、保全対象は増え、情報は散らばる。この三重の課題に対し、AWSが提案するのは 「聞けば、必要な情報が集まり、やるべきことが分かる」 保全の仕組みです。 ソリューションの全体構成 以下が本ソリューションの全体像です。 駅設備群や変電所からセンサーデータを収集し、異常を検知すると通知を配信します。同時に保全AIエージェントが起動し、チャットを通じて原因調査から作業指示書の生成までを支援します。また、時系列基盤モデル Chronos-2 を応用した予兆検知を日次で実行し、故障の予兆を地図上に可視化します。保全担当者はこれらすべての情報に、地図・ダッシュボード・AIチャットのいずれからでもアクセスできます。 以降、この構成の中核となる2つの柱について詳しくご紹介します。 コンセプト：誰もが使える、鉄道設備保全プラットフォーム 今回の展示では、特定の担当者向けではなく、立場の異なる誰もが直感的に使えることを目指したデモソリューションをご紹介しました。2つの柱で構成されています。 各柱はブースで実際に手を動かして体験でき、来場者が自分の業務に置き換えてイメージできる構成にしました。 柱1：AIエージェントによる異常対応フロー 異常の発生から対応完了まで、AIエージェントが自律的に伴走します。入口は AIチャットひとつ です。やりたいことに応じて、地図UI・ダッシュボード・AIエージェントへ自然につながります。 以下が実際のデモ画面です。左側に地図UIと3Dビューア、右側にAIチャットとダッシュボードが統合されています。 柱1のデモ画面。異常を起点にAIエージェントが横断調査し、対応を提案します（表示内容はすべて架空のデータです） 保全AIエージェントは、問い合わせ内容に応じて最適な画面・機能へ自動的につなぎます。 異常対応の4ステップ ① 異常を検知 — 設備のセンサー値から異常をリアルタイムに検知します。 AWS IoT Core でデータを受信し、 AWS IoT SiteWise で328アセット・13モデルとして構造化された設備情報から異常を判定します。 ② AI調査を自動起動 — 異常検知と同時に地図画面が該当設備に自動フォーカスし、AIエージェントへの問い合わせが自動で開始します。担当者へのメール通知も並行して行われ、検知から調査開始までのタイムラグを最小化します。 ③ 原因と対応計画を提示 — AIエージェントが保守履歴・設備マニュアル・センサーの数値データを横断的に調査し、原因の手がかりと対応計画を生成します。ベテランが経験に基づいて「あのとき似たことがあった」と思い出すプロセスを、AIが瞬時に再現します。 ④ 作業指示書を出力 — 対話の内容を基に、作業指示書をExcel帳票として出力します。チャットで深掘りし、情報が揃った段階で「指示書にまとめて」と言えば完成します。 技術的構成 Amazon Bedrock AgentCore + Strands Agents — AIエージェントの実行基盤と、Amazonが開発したオープンソースのAIエージェントフレームワーク。エージェントが実行する個別機能を「Agent Skill」として実装 Amazon Bedrock Knowledge Bases — 設備マニュアル・保守履歴に対するRAG（検索拡張生成） Amazon Bedrock AgentCore Memory — 会話・作業履歴を保持し、文脈を踏まえた継続的な対話を実現 Amazon Location Service — 鉄道設備の位置と状態を地図上にリアルタイム表示 Grafana（ Amazon Elastic Container Service 上） — センサー値の時系列可視化。チャットからダッシュボードを呼び出す仕組みも実装 柱2：学習不要の予知保全 — Chronos-2の応用 従来の予知保全が抱えていた課題 予知保全は鉄道保全の効率化に大きな可能性を持ちますが、従来のアプローチには大きなハードルがありました。設備ごとにモデルを構築し、定期的に再学習する運用が必要で、新設備が増えるたびに追加のモデル開発コストが発生します。 保全の担い手が減っている中で、モデルの運用まで手が回らない。結果として、予知保全は「やりたいけど始められない」ものになりがちでした。 Chronos-2 が変えること 今回の展示では、 Amazon Scienceが開発したオープンソースの時系列基盤モデル Chronos-2 を活用した、学習不要（ゼロショット）の予知保全をご紹介しました。 鉄道保全での活用 国内鉄道事業者様にご提供いただいた変電所のセンサーデータを元に生成したデータを使用し、日次で自動予測を実行するデモを構築しました。 本デモでの予兆検出の仕組みは以下の通りです。毎日の始まりに、Chronos-2が最新のセンサーデータを基に将来の値を予測し、信頼区間とともに算出します。その後、実際のセンサーデータが取得されるたびに予測の信頼区間と比較し、実測値が信頼区間から逸脱した場合に予兆として警告を発出します。 毎日、最新データから翌日以降の値と信頼区間を予測 実測値が信頼区間から逸脱した場合に予兆として警告 予兆が検出された設備は地図上でステータスが変化し、予測グラフを重畳表示 柱2のデモ画面。Chronos-2を応用した予測を地図とグラフで可視化します（実データを元に生成した合成データを使用。表示内容は架空です） 設備ごとのモデル構築が不要なことで、予知保全を始めるハードルを大きく下げられる可能性があります。鉄道保全における時系列基盤モデルの活用は新しいアプローチであり、本展示ではその可能性を具体的なデモとしてお見せしました。 活用AWSサービス Amazon SageMaker AI — Chronos-2モデルの推論エンドポイント Amazon EventBridge + AWS Step Functions — 日次バッチでの予測実行オーケストレーション Amazon Simple Storage Service （Amazon S3） — 時系列データ・予測結果の格納 AWSの詳細構成図 最後に、ここまで紹介した仕組みを支えるAWSの詳細構成を示します。設備エミュレーターからのデータ取り込み、異常検知、目的別の通知パイプライン、保全AIエージェント、Chronos-2を応用した予兆検出までを1枚に集約したものです。通知パイプラインは目的別に複数存在し、それぞれ独立して動作します。 展示② 「クローズド」をクラウドで読み解く — 国土交通省ガイドライン第6版から考えるOT/IT設計アプローチ 鉄道の制御系システム（信号・CTC・ATS・連動装置など）は、重要インフラとして高い安全性が求められます。国土交通省「 鉄道分野における情報セキュリティ確保に係る安全ガイドライン 」第6版はその設計指針を示す重要な規範です。 本展示では、このガイドラインの要件をクラウド上で実現するための設計アプローチをパネルで紹介しました。 「クローズド ≠ 安全」という認識転換 物理的に隔離された環境であっても、USBメモリ等を介した侵入は起こり得ます（ 参考：IPA 制御システムのセキュリティリスク分析ガイド ）。重要なのは「切り離す」ことではなく、システム全体のリスクを継続的に管理することです。 また、「クラウド」＝「インターネット」ではありません。 AWS Direct Connect を使うことで、インターネットを経由せずに閉域網を介してクラウドサービスを利用できます。 ガイドラインが求めるセキュリティを、自前で維持し続ける難しさ ガイドライン第6版では、脅威環境の変化に追従する「継続的なリスク対処」が求められています。具体的には、脅威の検知、監査証跡の管理、脆弱性への対応を組織として継続的に運用する必要があります。 しかし、これらを自前のオンプレミス環境で維持し続けることは、鉄道事業者にとって大きな負荷となり得ます。セキュリティ人材の確保、監視基盤の構築・更新、脅威インテリジェンスの追従 — いずれも専門性が高く、継続的な投資を要する領域です。 AWSのセキュリティリソースを活用する意義 ここで有用だと考えているのが、 責任共有モデルに基づき責任範囲を明確にした上で、AWSが担う領域のセキュリティ運用をマネージドサービスに任せる というアプローチです。 Amazon GuardDuty — 脅威検知をマネージドで提供。自前で監視基盤を構築・運用する負荷を軽減 AWS CloudTrail — 監査証跡を自動で記録・保存。ガイドラインで求められる操作ログの管理を支援 AWS Security Hub — セキュリティ状況を一元的に可視化。継続的な改善サイクルの基盤に クローズドな閉域網接続（AWS Direct Connect）を前提とすることで、インターネットを介さずにこれらのセキュリティリソースを活用できます。もちろん、 Amazon Bedrock 等のAIリソースもクローズドな状態で利用可能ですが、ガイドライン準拠という観点で最も直接的なメリットは、 責任共有モデルのもと、AWSのマネージドサービスでセキュリティ運用の負荷を軽減できること にあると考えています。 設計の3原則 原則1：論理的境界も有効 ガイドラインは「クローズド環境構築」を求めますが、その手段を物理に限定していません。IEC 62443やNIST CSF 2.0の考え方に基づき、 Amazon Virtual Private Cloud （Amazon VPC）による論理的な境界の分離も有効な手段です。 原則2：境界の明確化と片方向通信 例えば、制御系（OT）と業務系（IT）を別のVPCに分離し、中継ストレージ（Amazon S3）で片方向通信を強制するといったパターンが考えられます。制御系VPCはクラウド内のインターネットからも隔離されたネットワーク上に構築し、データの逆流が起きない設計とします。 原則3：継続的なリスク対処をAWSでオフロード NIST CSF 2.0の「統治」機能を踏まえ、組織レベルで継続的な改善サイクルを構築します。前述のAWSセキュリティサービスを活用することで、脅威環境の変化への追従を自前で抱え込まずに実現できます。 鉄道ユースケースへの展開 このアーキテクチャパターンにより、セキュリティを確保しながら制御系データの利活用が可能になります。 データを活用した業務変革はIT領域に閉じるものではありません。制御系のセキュリティドメイン内にAI推論リソースを配置することで、制御系データをIT側に出すことなくOT領域内でAI活用を行うことも可能です。また、OTからITへの片方向データ連携により、運行ダッシュボードを構築できます。IT系では需要予測や遅延予測など、ドメインの境界を明確にした上でデータの価値を引き出す設計も可能です。 来場者の反応 展示ブースには2日間を通じて多くの方にお越しいただきました。 保全プラットフォームのデモでは、地図とAIチャットが連動して動く様子に多くの方が足を止めてくださいました。デモが具体的でイメージを持ちやすいとの反応をいただく一方で、「この仕組みを活かすためには、設備データをどう取得するかという長期的な戦略が前提になる」という本質的な指摘もありました。私たちにとっても、ソリューション単体ではなくデータ戦略とセットで提案していく必要性を再認識する機会となりました。 Chronos-2を応用した予知保全については、「学習不要」というコンセプトへの関心が想定以上に高く、鉄道に限らず幅広い業界の方から質問をいただきました。既に類似の取り組みを進めている方からも前向きな反応があり、実用化への期待の高さを感じています。 セキュリティ設計のパネル展示も、保全デモとは異なる層の来場者に関心を持っていただきました。AI関連の展示が多い中で、制御系ネットワークの設計という具体的なテーマが来場者の課題に合致したようです。 まとめ 鉄道は社会インフラの根幹を支える産業です。しかしその保全現場は、人手不足・設備増加・情報の散在という構造的課題に直面しています。 今回の展示を通じてお伝えしたかったのは、テクノロジーは人を置き換えるためではなく、人がやるべきことに集中できるようにするために使うものだということです。 ベテランの知見はAIが引き出す。人は判断と意思決定に集中する モデルの構築・運用に追われない。時系列基盤モデルにより予知保全を始める選択肢が広がる クローズド前提のシステムであっても、クラウドをセキュリティ運用・データ活用・AI活用に取り入れることで、人が本来注力すべき判断や改善に集中できると考えている AWSは、鉄道業界のデジタルトランスフォーメーションを支援し、安全で持続可能な鉄道サービスの実現に貢献してまいります。 展示内容にご興味をお持ちの方は、ぜひお気軽にお問い合わせください。 著者 堀 竜慈 アマゾンウェブサービスジャパン合同会社 技術統括本部　ソリューションアーキテクト 西部 信博 アマゾンウェブサービスジャパン合同会社 技術統括本部 シニアカスタマーソリューションマネージャー 稲田 崇志 アマゾンウェブサービスジャパン合同会社 技術統括本部 ソリューションアーキテクト 矢形 拓也 アマゾンウェブサービスジャパン合同会社 技術統括本部　シニアソリューションアーキテクト 鈴木 真史 アマゾンウェブサービスジャパン合同会社 技術統括本部　シニアソリューションアーキテクト 宮﨑 知洋 アマゾンウェブサービスジャパン合同会社 技術統括本部　ソリューションアーキテクト  

本記事は 2025 年 11 月 19 日 に公開された「 Accelerate generative AI use cases with Amazon Bedrock and Oracle Database@AWS 」を翻訳したものです。 Oracle Database バージョン 26ai では、ベクトル埋め込みの保存と、キーワードではなくセマンティクスに基づくデータ検索が可能になり、音声アシスタント、チャットアシスタント、言語翻訳、レコメンデーションシステム、異常検知、動画検索・認識などの生成 AI アプリケーションを開発できます。Oracle AI Database 26ai の AI Vector Search を使うと、大規模言語モデル (LLM) を再学習することなく、重要なコンテキストを活用した Retrieval Augmented Generation (RAG) アプリケーションを構築できます。コンテキストは Oracle AI Database 26ai に保存・検索・取得され、LLM に渡すことで、プロンプトに対して正確で最新かつ的確な回答を生成します。Oracle AI Database 26ai の AI Vector Search と LLM を組み合わせた RAG により、社内のビジネス情報を安全に活用して重要なビジネス上の質問への回答やさまざまなユースケースのコンテンツ生成が可能です。 Oracle AI Database 26ai は VECTOR データ型 をサポートし、データベース内にビジネスデータと並べてベクトル埋め込みを保存する基盤を提供します。埋め込みモデルを使えば、非構造化データをベクトル埋め込みに変換し、ビジネスデータに対するセマンティック検索に活用できます。ベクトル埋め込みは Oracle Database の外部で生成でき、 Amazon Bedrock でホストされる事前学習済み埋め込みモデル、オープンソースの埋め込みモデル、または独自の埋め込みモデルを利用できます。AWS では、ユースケースや要件に応じて Amazon OpenSearch Service 、 Amazon Aurora PostgreSQL-Compatible Edition 、 Amazon DocumentDB など、さまざまなベクトルデータベースの選択肢があります。本記事では、 Oracle Database@AWS (ODB@AWS) と Amazon Bedrock を統合し、Amazon Bedrock の Amazon Titan 埋め込みモデルと Oracle AI Database 26ai に保存されたベクトルを使って RAG アシスタントアプリケーションを構築する手順を解説します。 ODB@AWS では、AWS データセンター内で Oracle Cloud Infrastructure (OCI) が管理する Oracle Exadata インフラストラクチャにアクセスできます。オンプレミスの Exadata と同等のパフォーマンスと機能を維持しながら、Oracle Exadata ワークロードを AWS に移行できます。ODB@AWS は Exadata Database Service および Autonomous Database Service on Dedicated Infrastructure で Oracle Database 19c と 26ai の両バージョンをサポートしています。Amazon Redshift との Zero-ETL 連携、バックアップ用の Amazon S3 連携、モニタリング用の Amazon CloudWatch、Amazon Bedrock、 Amazon SageMaker AI などの生成 AI サービスとの統合により、生成 AI アプリケーションを構築できます。 Oracle AI Database 26ai のベクトル機能の概要 Oracle AI Database 26ai は AI Vector Search 機能を通じてベクトル機能を提供し、ODB@AWS 上で AI ワークロードを実行できます。主な機能は次のとおりです。 ネイティブ VECTOR データ型と操作 Oracle AI Database 26ai は新しい VECTOR データ型を導入し、テーブルカラムに高次元ベクトルを直接保存できます。単一の統合データベース環境内でベクトルデータの保存、クエリ、分析操作を実行できます。AI Vector Search 機能がネイティブに統合されており、類似検索、ベクトルとリレーショナルデータを組み合わせた ハイブリッドクエリ 、外部サービスを必要としない高度な分析が可能です。 ベクトルは、SecureFiles LOB に保存されたドキュメント、PDF、画像などの非構造化データ、メタデータやコンテキスト用の JSON データ、高度な分析や AI ベースのレコメンデーション用のグラフデータや空間データと共存できます。複雑性を低減しセキュリティを向上させつつ、セマンティック検索とビジネスコンテキストを組み合わせたハイブリッドクエリを実現します。 柔軟なベクトル生成 Oracle は Python や REST API を通じて外部の埋め込みモデルや LangChain 、 LlamaIndex などの RAG フレームワークと柔軟に統合できます。また、事前学習済み埋め込みモデルを ONNX 形式 で直接データベースにインポートし、データベース環境内でベクトル埋め込みを生成することも可能です。ただし、データベースへの性能負荷が増加し、モデルの更新やメンテナンスも必要になります。 AI Smart Scan (Exadata 最適化) Oracle Database@AWS は Exadata 上で動作するため、 AI Smart Scan を使ってベクトルデータを照会し、ベクトル操作を Exadata ストレージサーバーにオフロードします。帯域幅を最適化し、データベース層の CPU 使用率を削減するため、リアルタイムのセマンティック検索やレコメンデーションエンジンなど、大規模な AI/ML アプリケーションに最適です。 専用メモリ割り当て Oracle は vector_pool と呼ばれる専用メモリ領域を割り当て、Hierarchical Navigable Small World (HNSW) ベクトルインデックスと関連メタデータをデータベースバッファキャッシュとは別に保存します。この領域は Inverted File Flat (IVF) インデックスの作成や、IVF インデックスを持つベーステーブルに対する DML 操作の高速化にも使用されます。トランザクション処理に影響を与えることなく、AI ワークロードの予測可能なパフォーマンスを実現します。 開発とデータ管理の簡素化 開発者は標準 SQL を使って単一の環境内でリレーショナルデータとベクトルデータの両方を扱えるため、学習コストを低減しアプリケーション開発を効率化できます。 PL/SQL パッケージ を使ったベクトル操作も可能です。汎用データベースにベクトル機能を統合することで、Oracle AI Database 26ai はセキュリティ、高可用性 (RAC など)、パーティショニング、シャーディング、災害復旧などの既存のエンタープライズ機能を活用できます。 ベクトルデータの外部テーブルサポート Oracle AI Database 26ai のベクトル向け外部テーブルサポートにより、外部ファイルから直接埋め込みを保存・検索でき、コストと柔軟性の面で有利です。ベクトルデータの探索やステージング、リレーショナル情報とベクトル情報を混合した類似検索やハイブリッドクエリの実行、大規模な外部データセットに対する概念実証の分析を、本格的な取り込みの前に行うのに適しています。Amazon S3 上にベクトルデータを持つ外部テーブルを作成し、セマンティック検索を実行できます。 ソリューションの概要 本記事では、Oracle AI Database 26ai をベクトルデータストア、LangChain フレームワーク、Amazon Titan 埋め込みモデル、Amazon Bedrock でホストされる Anthropic Claude LLM モデルを使って RAG AI アシスタントアプリケーションを構築する方法をデモします。 次の図では、ODB@AWS にデプロイした Oracle AI Database 26ai をベクトルストアとして使用しています。AI チャットアシスタントアプリケーションは、 ODB ピアリング で ODB ネットワークとピアリングした VPC 内の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスにデプロイされています。ODB ネットワークは、AWS アベイラビリティゾーン内の Oracle インフラストラクチャをホストするプライベートな分離されたネットワークです。標準的な VPC とは異なり、ODB ネットワークにはインターネット接続がなく、ODB@AWS リソースのみをサポートします。ODB ピアリングは ODB ネットワークと Amazon VPC 間のプライベートネットワーク接続を確立し、同一ネットワーク上にあるかのようにアプリケーションから Oracle データベースに通信できるようにします。 ODB ピアリング は AWS と Oracle の環境を橋渡しし、ピアリングされた VPC に接続された特定の AWS サービスからのトラフィックが ODB ネットワークに到達できるルーティング機能をサポートします。Amazon Bedrock の Amazon Titan 埋め込みモデルでベクトル埋め込みを作成します。Anthropic Claude LLM はセマンティック検索のために Amazon Bedrock から呼び出されます。Amazon Bedrock へのアクセスは、EC2 インスタンスに関連付けられた AWS Identity and Access Management (IAM) ロールを通じて付与されます。 デモのエンドツーエンド RAG ワークフローは、次の大まかなステップで構成されます。 データ取り込み (本デモでは PDF): アプリに PDF を取り込み、テキストコンテンツを読み取って抽出します。 テキストチャンキング : 抽出したテキストを効率的に処理できるよう、小さな チャンク に分割します。テキストのチャンキングは検索品質とレートリミット対策の両面で重要です。 埋め込み生成 : アプリケーションは Amazon Bedrock の Amazon Titan Text Embeddings v2 モデルを使い、テキストチャンクのベクトル表現である埋め込みを生成します。 ベクトルストア : Oracle Database@AWS の Oracle AI Database 26ai (Oracle AI Vector Search) にベクトルとメタデータを保存します。 ユーザーの質問 : ユーザーがチャットボットに自然言語で質問を入力します。 類似度マッチング : ユーザーが質問すると、アプリはテキストチャンクと比較し、セマンティックに最も類似したチャンクを特定します。 RAG : Streamlit UI 上に構築されたアプリケーションを通じて、Amazon Bedrock の Anthropic Claude 3 Sonnet モデルで検索拡張型 Q&A を実行します。 レスポンス : LLM が PDF の関連コンテンツに基づいて回答を生成します。 完全なコードは GitHub リポジトリ を参照してください。 前提条件 このソリューションを実装するにあたり、以下の前提条件を満たし、必要なリソースを作成しています。 AWS リージョンで Amazon Bedrock にアクセスできる AWS アカウント。Amazon Bedrock では、API を使ってモデルを呼び出す前に、基盤モデル (FM) へのアクセスをリクエストする必要があります。生成 AI アプリケーションを構築・実行するには、Amazon Bedrock で モデルアクセス を設定する必要があります。Amazon Bedrock は AI21 Labs、Anthropic、Cohere、Meta、Stability AI、Amazon など複数のプロバイダーからさまざまな FM を提供しています。 ベクトルストアとして使用する Oracle Database@AWS 上の Oracle AI Database 26ai。本デモのアーキテクチャでは、ODB@AWS の Exadata Database Service に 26ai をデプロイしています。 Oracle Database@AWS サービスをホストする ODB ネットワークと ODB ピアリングされた VPC にデプロイされた EC2 インスタンス。クライアントとして使用する EC2 インスタンスから ODB@AWS 上の Oracle Database へのネットワーク接続を確認してください。 Amazon Bedrock モデルと SageMaker AI サービスへのアクセスを許可するポリシーがアタッチされた IAM ロールを EC2 インスタンスに関連付けます。以下はポリシーの例です。完全なポリシー JSON ドキュメントは GitHub を参照してください。 { "Version": "2012-10-17", "Statement": [ { "Sid": "AllowBedrockInvoke", "Effect": "Allow", "Action": [ "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream" ], "Resource": "*" }, { "Sid": "AllowSageMakerStudioDiscovery", "Effect": "Allow", "Action": [ "sagemaker:ListDomains", "sagemaker:ListUserProfiles", "sagemaker:ListApps", "sagemaker:DescribeDomain", "sagemaker:DescribeUserProfile" ], "Resource": "*" { "Sid": "AllowSageMakerStudioPresignedUrls", "Effect": "Allow", "Action": [ "sagemaker:CreatePresignedDomainUrl" ], "Resource": "*" } ] } アプリケーションの構築 以下の手順に従い、Oracle 26ai をベクトルストアとして使用し、Amazon Bedrock の埋め込みモデルと LLM モデルを統合した、Streamlit ベースの AI チャットアシスタントを含むエンドツーエンドの RAG ワークフローを構築します。 GitHub で公開されている完全なコードを再利用することもできます。GitHub からコードをデプロイして実行する手順は「デモ」セクションを参照してください。 ライブラリのインポート: import sys import os from pathlib import Path from typing import Dict, List import logging from dotenv import load_dotenv import time from concurrent.futures import ThreadPoolExecutor import numpy as np from PIL import Image import base64 import boto3 import oracledb import streamlit as st from PyPDF2 import PdfReader from langchain_aws import BedrockEmbeddings, ChatBedrock from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_core.documents import Document from langchain_community.vectorstores.oraclevs import OracleVS from langchain_community.vectorstores.utils import DistanceStrategy from langchain.chains import ConversationalRetrievalChain ドキュメントの取り込み: 本ユースケースでは PDF 形式のドキュメントを使用します。PDF ドキュメントを読み込み、各ページをテキストに変換します。   def extract_text_from_pdf(pdf_file) -> str: """Extract text content from a PDF file.""" try: pdf_reader = PdfReader(pdf_file) text = "" for page in pdf_reader.pages: text += page.extract_text() return text except Exception as e: logger.error(f"Error extracting text from PDF: {e}") raise 注: この例ではローカルデスクトップから PDF ドキュメントをアプリに読み込んでいますが、データソース (PDF ドキュメント) は Oracle Database 内 (BLOB としての PDF) や、Amazon S3 バケットなどデータベース外部に配置することも可能です。 テキストのチャンキング: 抽出したテキストを、LangChain の RecursiveCharacterTextSplitter モジュールで小さなチャンクに分割します。チャンクサイズ、オーバーラップなどのパラメータは処理効率を最適化するよう設定します。 def chunk_text(text: str) -> List[str]: try: splitter = RecursiveCharacterTextSplitter( separators=["\n\n", "\n", ".", " "], chunk_size=MAX_CHUNK_SIZE, chunk_overlap=100, length_function=len ) return splitter.split_text(text) except Exception as e: logger.error(f"Error chunking text: {e}") raise 以下の create_documents 関数は、テキストチャンクのリストを受け取り、メタデータ付きの Document オブジェクトに変換します。各テキストチャンクに対して ID とページリンクをメタデータとして割り当てた Document オブジェクトを作成し、リスト内包表記で効率的に処理します。 def create_documents(chunks: List[str]) -> List[Document]: """Create document objects with metadata from text chunks.""" return [ Document( page_content=text, metadata={'id': str(i), 'link': f'Page {i}'} ) for i, text in enumerate(chunks) ] process_chunk_with_delay 関数は、レートリミット対応としてタイムディレイを挿入しながら、単一のドキュメントチャンクを処理します。まず time.sleep で一定時間待機し、次にエンベッダーを使ってドキュメントの内容をベクトル埋め込みに変換します。 def process_chunk_with_delay(chunk: Document, embedder) -> np.ndarray: """Process a single chunk with rate limiting.""" time.sleep(RATE_LIMIT_DELAY) return embedder.embed_documents([chunk.page_content])[0] batch_process_embeddings 関数は、レートリミットを維持しながら複数のドキュメントの埋め込み生成を並列処理で管理します。 ThreadPoolExecutor を使って最大 MAX_CONCURRENT_REQUESTS 個のドキュメントを並行処理し、各ドキュメントを process_chunk_with_delay 関数でレートリミットを守りつつ埋め込みを生成し、生成された埋め込みのリストを返します。 def batch_process_embeddings(docs: List[Document], embedder) -> List[np.ndarray]: """Process embeddings in batches with rate limiting.""" with ThreadPoolExecutor(max_workers=MAX_CONCURRENT_REQUESTS) as executor: embeddings = list(executor.map( lambda doc: process_chunk_with_delay(doc, embedder), docs )) return embeddings ベクトル埋め込みの保存: 次に、amazon.titan-embed-text-v2 モデルを使ったベクトル埋め込みをベクトルデータベースとして Oracle Database@AWS にロードします。テキストチャンクを入力として受け取り、Amazon Titan Embeddings を使ってベクトルストアを作成します。次のスクリーンショットのように環境変数から設定できます。データベースの構成に合わせて変更してください。 def get_oracle_connection(): """Create and return Oracle connection.""" try: if not hasattr(st.session_state, 'oracle_connection') or st.session_state.oracle_connection is None: connection = oracledb.connect( user=os.getenv('ORACLE_USER'), password=os.getenv('ORACLE_PASSWORD'), dsn=f"{os.getenv('ORACLE_HOST')}:{os.getenv('ORACLE_PORT', '1521')}/{os.getenv('ORACLE_SERVICE')}" ) st.session_state.oracle_connection = connection logger.info("New Oracle connection established successfully") return st.session_state.oracle_connection except Exception as e: logger.error(f"Error creating Oracle connection: {e}") raise def check_connection(): """Check if the Oracle connection is healthy and reinitialize if needed.""" try: connection = st.session_state.get('oracle_connection') if connection is None: st.session_state.oracle_connection = get_oracle_connection() return try: with connection.cursor() as cursor: cursor.execute("SELECT 1 FROM DUAL") except Exception as e: logger.warning(f"Connection test failed: {e}") try: connection.close() except Exception: pass st.session_state.oracle_connection = get_oracle_connection() except Exception as e: logger.error(f"Error checking connection: {e}") raise def safe_close_connection(): """Safely close the Oracle connection.""" if hasattr(st.session_state, 'oracle_connection') and st.session_state.oracle_connection is not None: try: if st.session_state.oracle_connection.ping(): st.session_state.oracle_connection.close() logger.info("Oracle connection closed successfully") except Exception as e: logger.warning(f"Error during connection cleanup: {e}") finally: st.session_state.oracle_connection = None 上記のコードは、Streamlit アプリケーションで Oracle データベース接続を 3 つの関数で管理しています。 get_oracle_connection() はセッション状態に接続がなければ新しいデータベース接続を作成し、 check_connection() は既存の接続が正常かどうかを検証して必要に応じて再作成し、 safe_close_connection() は不要になったデータベース接続を適切にクローズします。これらの関数により、接続リークを防止しエラーを適切に処理しながら、安定したデータベース接続を提供します。 def initialize_bedrock_embeddings(): """Initialize and return Bedrock embeddings.""" try: client = boto3.client("bedrock-runtime", 'us-east-1') return BedrockEmbeddings( model_id="amazon.titan-embed-text-v2:0", client=client ) except Exception as e: logger.error(f"Error initializing Bedrock embeddings: {e}") raise 上記のコードは、Amazon Titan モデルを使ってテキストをベクトル (埋め込み) に変換する Amazon Bedrock 埋め込みサービスを初期化します。 us-east-1 リージョン用の Amazon Bedrock クライアントを作成し、Amazon Titan 埋め込みモデルで BedrockEmbeddings オブジェクトを設定します。初期化中にエラーが発生した場合はログに記録して例外を再送出します。 embedder = initialize_bedrock_embeddings() embeddings = batch_process_embeddings(docs, embedder) vectorstore = OracleVS.from_documents( docs, embedder, client=st.session_state.oracle_connection, table_name="ORAVSEMBEDDING", distance_strategy=DistanceStrategy.DOT_PRODUCT ) 上記のコードは、ドキュメント埋め込みワークフローで 3 つの操作を実行します。 先ほど定義した関数で Amazon Bedrock 埋め込みサービスを初期化します。 ドキュメント (docs) のバッチを処理し、エンベッダーを使ってベクトル埋め込みを作成します。 ドキュメントと埋め込みを Oracle Database (OracleVS) にベクトルストアとして保存します。ベクトル間の類似度指標としてドット積を使い、ORAVSEMBEDDING というテーブルに格納します。 次のステップでドキュメントのベクトル類似検索が有効になります。 会話チェーンの作成: 会話型 AI モデル (Anthropic Claude v1) と前の関数で作成したベクトルストアを使って会話チェーンを作成します。このチェーンにより、生成 AI アプリケーションが対話型のやり取りを行えるようになります。 def create_conversation_chain(vectorstore): """Create a conversation chain for Q&A.""" try: llm = ChatBedrock( model_id="us.anthropic.claude-3-sonnet-20240229-v1:0", client=boto3.client("bedrock-runtime", 'us-east-1') ) return ConversationalRetrievalChain.from_llm( llm=llm, retriever=vectorstore.as_retriever(), return_source_documents=True ) except Exception as e: logger.error(f"Error creating conversation chain: {e}") raise 質問処理関数の作成: ユーザーの入力質問を処理し、AI アシスタントからの回答を生成する関数です。 # Questions Section st.markdown("### Ask Questions") question = st.text_input("Enter your question:") if question: if st.button("Ask", type="primary"): try: if not st.session_state.vectorstore: st.warning("Please process documents first!") else: check_connection() if st.session_state.conversation is None: st.session_state.conversation = create_conversation_chain( st.session_state.vectorstore ) with st.spinner("Thinking..."): response = st.session_state.conversation.invoke({ "question": question, "chat_history": st.session_state.chat_history }) st.session_state.chat_history.append((question, response['answer'])) display_chat_history() except Exception as e: st.error(f"Error processing question: {e}") if st.session_state.chat_history: if st.button("Clear Chat History"): st.session_state.chat_history = [] st.rerun() Streamlit コンポーネントの作成: Streamlit は、ML やデータサイエンス向けのカスタム Web アプリケーションを簡単に作成・共有できるオープンソースの Python ライブラリです。数分で強力なデータアプリケーションを構築しデプロイできます。以下のコードで Streamlit コンポーネントを作成します。   def main(): """Main application function.""" set_custom_style() init_session_state() display_sidebar() st.markdown('<h1 class="main-header">? OracleRAG: AI-Powered Knowledge Navigator</h1>', unsafe_allow_html=True) # Document Upload Section st.markdown("### Document Upload") uploaded_files = st.file_uploader( "Choose PDF files", type="pdf", accept_multiple_files=True ) if uploaded_files: total_size = sum(file.size for file in uploaded_files) st.info(f"Total upload size: {total_size/1024/1024:.2f} MB") if st.button("Process Documents", type="primary"): try: for pdf_file in uploaded_files: if pdf_file.name not in st.session_state.processed_files: with st.spinner(f"Processing {pdf_file.name}..."): text = extract_text_from_pdf(pdf_file) chunks = chunk_text(text) docs = create_documents(chunks) show_processing_progress(len(docs)) embedder = initialize_bedrock_embeddings() embeddings = batch_process_embeddings(docs, embedder) vectorstore = OracleVS.from_documents( docs, embedder, client=st.session_state.oracle_connection, table_name="ORAVSEMBEDDING", distance_strategy=DistanceStrategy.DOT_PRODUCT ) st.session_state.vectorstore = vectorstore st.session_state.processed_files.add(pdf_file.name) st.session_state.total_chunks_processed += len(docs) st.success("All documents processed successfully!") except Exception as e: st.error(f"Error during processing: {e}") デモ 生成 AI アシスタントアプリケーションのコードが完成したら、Streamlit でアプリケーションを実行します。以下の手順で GitHub からコードをデプロイしてください。 GitHub リポジトリをクローンします。 git clone https://github.com/aws-samples/sample-chatbot-bedrock-oracle-on-aws/ クローンしたリポジトリのフォルダに移動します。 cd ./sample-chatbot-bedrock-oracle-on-aws プロジェクトディレクトリに .env ファイルを作成し、Oracle Database@AWS の接続情報を追加します。 .env ファイルは以下のようになります。 Oracle Database Configuration ORACLE_USER=<username> ORACLE_PASSWORD=<password> ORACLE_HOST=<Oracle-VM-HOSTNAME> ORACLE_PORT=1521 ORACLE_SERVICE=<ORACLE-SERVICE-NAME> AWS Configuration AWS_DEFAULT_REGION=<REGION> クローンした GitHub リポジトリには、AI アシスタントアプリケーション構築に必要なライブラリが記載された requirements.txt ファイルが含まれています。次のコマンドでライブラリをインストールします。 pip install -r requirements.txt クローンしたリポジトリのフォルダで次のコマンドを実行します。 streamlit run odbapp.py --server.port 8080 アプリケーションが起動し、ブラウザウィンドウで URL が開き、以下のようにアプリケーションが表示されます。 Browse files を選択して PDF ファイルをアップロードします。 この例では Oracle 26ai ユーザーガイド を PDF 形式でアップロードしています。 Process Documents を選択します。 質問を入力して Ask を選択します。 AI アシスタントが RAG ワークフローを通じて質問を処理し、以下のスクリーンショットのように回答を生成します。 クリーンアップ 不要になった場合は、課金を避けるためにテスト用にプロビジョニングしたリソースを必ず削除してください。Streamlit アプリケーション、EC2 インスタンス、および使用しない Exadata Database Service 上の Oracle AI Database 26ai を手動で削除できます。 まとめ 本記事では、Oracle Database@AWS 上の Oracle Database 26ai のベクトル機能を解説し、Amazon Bedrock と Amazon SageMaker を ODB と統合して生成 AI アプリケーションを構築する方法をデモしました。 著者について Yamuna Palasamudram Yamuna は、AWS のプリンシパルデータベーススペシャリストソリューションアーキテクトです。Oracle などの商用データベースエンジンを担当し、アーキテクチャガイダンス、テクニカルアドバイザリー、データおよび AI 戦略の支援を通じてお客様と協業しています。 Sharath Chandra Kampili Sharath は、AWS のデータベーススペシャリストソリューションアーキテクトです。Amazon RDS チームで Oracle などの商用データベースエンジンを担当し、お客様のデータベースプロジェクトに対するガイダンスと技術支援を直接提供しています。 Archana Sharma Archana は、AWS のシニアデータベーススペシャリストソリューションアーキテクトとして、ワールドワイドパブリックセクターのお客様を担当しています。リレーショナルデータベースの豊富な経験を持ち、データベースの移行とモダナイゼーションを中心に、お客様の AWS クラウドへの移行を支援しています。 この記事は Solutions Architect の 矢木 覚 が翻訳しました。

本記事は 2026 年 1 月 13 日 に公開された「 Best practices for creating and reorganizing data with additional storage volumes in Amazon RDS for Oracle 」を翻訳したものです。 Amazon Relational Database Service (Amazon RDS) for Oracle は、クラウド上で Oracle データベースのセットアップ、運用、スケーリングを容易にするフルマネージドな商用データベースです。プロビジョニング、バックアップ、ソフトウェアパッチ適用、モニタリング、ハードウェアスケーリングといった時間のかかるデータベース管理タスクを Amazon RDS が担うため、お客様はイノベーションとアプリケーション開発に集中できます。 Amazon RDS の追加ストレージボリュームを使うと、データのニーズに合わせてストレージ性能を細かく調整しながら、合計ストレージ容量を拡張できます。RDS インスタンスに最大 3 つの追加ストレージボリュームを追加することで合計 256 TiB までプロビジョニングでき、利用可能な容量は実質 4 倍になります。各ボリュームは異なるストレージタイプと性能特性で個別に設定できるため、アクセス頻度の高いデータを高性能なストレージに配置し、アクセス頻度の低いデータをよりコスト効率の良いボリュームに移動できます。また、追加ストレージボリュームは個別かつ並行してスケールできます。 Amazon Elastic Block Store (Amazon EBS) のストレージ変更操作は、インスタンスレベルではなく各ストレージボリューム単位になりました。 本記事では、追加ストレージボリュームを使って RDS for Oracle のストレージ容量を 64 TiB を超えて拡張する方法を紹介します。あわせて、追加ストレージボリュームのユースケースと、利用時のベストプラクティスも解説します。 追加ストレージボリュームの追加 追加ストレージボリュームは、 AWS Management Console 、 AWS CLI 、 AWS SDK から新規または既存の RDS インスタンスに追加できます。追加後は、これらのボリューム上に新しいデータベースファイルを作成したり、性能要件に応じて既存データを移動したりできます。バックアップやリストアなどの一般的なデータベース操作にも対応しており、Amazon RDS の管理機能は追加ボリュームにも自動的に適用されます。各ボリュームのパフォーマンスメトリクスは Amazon CloudWatch でモニタリングでき、ニーズの変化に応じてボリューム設定を調整できます。 RDS for Oracle インスタンスの変更による追加ストレージボリュームの追加 既存の RDS for Oracle インスタンスに追加ストレージボリュームを追加するには、 modify-db-instance コマンドで additional-storage-volumes パラメータを指定します。次のコードスニペットでは、4,000 IOPS の 5,000 GiB gp3 ボリューム rdsdbdata2 と、25,000 IOPS の 6,000 GiB io2 ボリューム rdsdbdata3 の 2 つを追加しています。 aws rds modify-db-instance \ --db-instance-identifier my-asv-demo1 \ --region us-east-1 \ --additional-storage-volumes '[ { "VolumeName":"rdsdbdata2", "StorageType":"gp3", "AllocatedStorage":5000 "IOPS":4000}, { "VolumeName":"rdsdbdata3", "StorageType":"io2", "AllocatedStorage":6000 "IOPS":25000} ]' \ --apply-immediately 追加ストレージボリュームを持つ新規 RDS for Oracle インスタンスの作成 次のコードスニペットは、追加ストレージボリュームを 2 つアタッチした新規 RDS for Oracle インスタンスを作成します。1 つ目の追加ボリュームは io2 ストレージタイプで 8,000 GiB の rdsdbdata2 、2 つ目は gp3 ストレージタイプで 5,000 GiB の rdsdbdata3 です。 aws rds create-db-instance \ --db-instance-identifier "asv-demo2" \ --master-username masteruser --master-user-password password \ --db-instance-class db.r5b.2xlarge --allocated-storage 50 --storage-type gp3 \ --engine oracle-ee --engine-version 19.0.0.0.ru-2025-07.rur-2025-07.r1 \ --backup-retention-period 1 \ --multi-az \ --additional-storage-volumes '[ { "VolumeName":"rdsdbdata2", "StorageType":"io2", "AllocatedStorage":8000 “IOPS”:20000}, { "VolumeName":"rdsdbdata3", "StorageType":"gp3", "AllocatedStorage": 5000} ]' \ --region us-west-2 インスタンス作成後は、Amazon RDS コンソールの 設定 タブで追加ストレージボリュームを確認するか、 describe-db-instance でボリュームのステータスを確認できます。ボリュームステータスが「 Not in use 」の場合、ボリュームは正常にアタッチされていますが、まだデータベースでは使用されていません。 データベースファイルの作成 ボリュームの追加が完了したら、その場所に新しいデータベースファイルを作成できます。Amazon RDS for Oracle では、ストレージ上のデータベースファイル配置に Oracle Managed Files (OMF) を使用します。新しいデータベースファイルの作成時に場所を直接指定することはできず、 db_create_file_dest パラメータの現在の設定から決定されます。このパラメータはセッションレベルまたはインスタンスレベルで変更できます。 インスタンスレベル – DB インスタンスに割り当てられたパラメータグループで db_create_file_dest パラメータを更新して適用します。詳細は、 RDS for Oracle の初期化パラメータ と Amazon RDS の DB パラメータグループのパラメータの変更 を参照してください。 セッションレベル – ALTER SESSION 文を実行して、目的の追加ストレージボリュームをパラメータに設定します。レプリカ構成で追加ストレージボリュームを使う場合は、プライマリインスタンスとレプリカインスタンスの動作を一致させるため、セッションレベルの変更ではなくパラメータグループでデータファイルの場所を管理することをお勧めします。 SHOW PARAMETER db_create_file_dest NAME TYPE VALUE ------------------------------------ ----------- ------------------------- db_create_file_dest string /rdsdbdata/db ALTER SESSION SET db_create_file_dest = '/rdsdbdata2/db'; Session altered. SHOW PARAMETER db_create_file_dest NAME TYPE VALUE ------------------------------------ ----------- ------------------------- db_create_file_dest string /rdsdbdata2/db db_create_file_dest パラメータを設定した後は、SQL コマンドで追加ストレージボリューム上にテーブルスペースを作成できます。 ALTER SESSION SET db_create_file_dest = '/rdsdbdata2/db'; Session altered. CREATE TABLESPACE mynewtablespace2 DATAFILE SIZE 10G; Tablespace created. SELECT tablespace_name,file_id,file_name FROM dba_data_files WHERE tablespace_name = 'MYNEWTABLESPACE2'; TABLESPACE_NAME FILE_ID FILE_NAME ------------------------- ---------- ------------------------------------- MYNEWTABLESPACE2 7 /rdsdbdata2/db/ORCL_A/datafile/o1_mf_mynewtab_n563b2kn_.dbf 追加ストレージボリューム利用時の考慮事項 以下の点に注意してください。 次のデータベース構造はプライマリストレージボリュームに保存され、追加ストレージボリュームへ移動できません。 SYSTEM テーブルスペース RDSADMIN テーブルスペース REDO ログファイル アーカイブログファイル 制御ファイル 追加ストレージボリュームは、プライマリボリュームが 200 GiB 以上の新規および既存の RDS for Oracle インスタンスで利用できます。追加ストレージボリュームのサイズは 200 GiB 以上である必要があります。 追加ストレージボリュームのストレージタイプは gp3 または io2 です。プライマリボリュームは任意のストレージタイプを使用できます。 追加ストレージボリュームには次のボリューム名を使用する必要があります。 rdsdbdata2 rdsdbdata3 rdsdbdata4 DB インスタンスの変更で追加ストレージボリュームを作成する場合、スケジュール変更の設定にかかわらず、Amazon RDS はストレージボリュームを即座に作成します。ストレージボリュームの追加はオンライン操作であり、データベースの性能には影響しません。 Oracle Enterprise Edition (EE) では、 move_datafile プロシージャを使って既存テーブルスペースのデータファイルをボリューム間で移動できます。この操作はオンラインで実行できます。同様に、Oracle EE の ALTER TABLE や ALTER INDEX コマンドの ONLINE 句を使うと、テーブル、インデックス、パーティションをオンラインで移動できます。 Oracle Standard Edition 2 (SE2) でもテーブルやインデックスのデータをボリューム間で移動できますが、オフライン操作となり、移動中はテーブルまたはインデックスがロックされます。 追加ストレージボリュームを持つ DB インスタンスの RDS for Oracle レプリカを作成すると、Amazon RDS はレプリカにも追加ストレージボリュームを自動的に設定します。ただし、その後プライマリ DB インスタンスのストレージボリュームに加えた変更は、レプリカには自動反映されません。 追加ストレージボリュームのユースケース このセクションでは、追加ストレージボリュームのさまざまなユースケースを紹介します。 64 TiB を超えるアクティブデータへのストレージ拡張 データベースの成長に伴い、追加ストレージボリュームを追加することでストレージを 64 TiB を超えて拡張できます。追加ストレージボリュームはそれぞれ最大 64 TiB までスケールでき、最大 3 つまで追加できるため、RDS for Oracle インスタンスの最大ストレージサイズは 256 TiB になります。RDS for Oracle インスタンスのプライマリボリュームは rdsdbdata という名前で、追加ボリュームは rdsdbdata2 、 rdsdbdata3 、 rdsdbdata4 です。新しいボリュームを追加する際は、性能要件に合わせてストレージタイプとボリューム特性を選択できます。追加ストレージボリュームは io2 と gp3 の両方のボリュームタイプをサポートし、1 ボリュームあたりの最小サイズは 200 GiB です。 アクティブデータとアクセス頻度の低いデータの分離配置 追加ストレージボリュームには、ストレージ拡張以外にも独自の利点があります。たとえば、アクティブデータと履歴データを分離することでデータベース性能を改善できます。アクセス頻度の低いデータを General Purpose SSD ストレージ (gp3) の追加ボリュームに移動し、アクセス頻度の高いデータを Provisioned IOPS SSD ストレージ (io2) に保持する、といった構成が可能です。さらに Oracle のオンライン再配置機能 (Oracle EE) を使えば、アプリケーションを稼働させたままボリューム間でデータを移動できます。 別のシナリオとして、20 TB のデータベースワークロードがあり、そのうち約 5 TB がアクセス頻度の低い履歴データとして別スキーマに格納されているケースを考えます。このワークロードには読み書き合わせて合計 80,000 IOPS が必要だとします。従来この要件を満たすには、io2 ストレージタイプで 20 TB、80,000 プロビジョンド IOPS の RDS for Oracle インスタンスをプロビジョニングする必要があり、us-east-1 リージョンのストレージ 料金 は月額約 21,120 USD でした。 追加ストレージボリューム機能を使うと、アクティブデータ用に 60,000 IOPS の 15 TB io2 ボリュームをプロビジョニングし、アクセス頻度の低いスキーマを 5 TB の gp3 ボリュームに移動するという 2 ボリューム構成に分割でき、RDS ストレージコストは月額約 17,017 USD (15,840 USD + 1,177 USD) になります。 データロード用の一時ストレージ RDS for Oracle インスタンスでは、データロードやエクスポート/インポートのダンプファイル、あるいは トランスポータブルテーブルスペース (XTTS) のデータファイルを置くステージング領域として、一時ストレージが必要になることがあります。追加ストレージボリュームを使えば、一時データのステージング用に新しいボリュームを作成し、移行やエクスポート/インポートの作業完了後にボリュームを削除できます。縮小できないプライマリボリュームに余分なストレージを割り当てずに済むため、コスト管理に役立ちます。 追加ストレージボリュームでのデータベース管理操作 このセクションでは、追加ストレージボリュームを使った一般的なデータベース管理操作を説明します。 追加ストレージボリュームでの Oracle Data Pump の利用 Oracle Data Pump 用のディレクトリを追加ストレージボリューム上に作成するには、次のコードを使用します。 BEGIN rdsadmin.rdsadmin_util.create_directory( p_directory_name => 'DATA_PUMP_DIR2', p_database_volume_name => 'rdsdbdata2'); END; / Oracle Data Pump を使用したインポート に記載の手順に従って、新しいディレクトリでデータのエクスポートとインポートを実行します。 作業完了後は、ファイルを削除し、必要に応じてボリュームも削除できます。 追加ストレージボリュームでのトランスポータブルテーブルスペースの利用 移行やエクスポート/インポートでトランスポータブルテーブルスペース (XTTS) を使用する際に、追加ストレージボリュームをダンプファイルのステージング領域として使う手順は次のとおりです。 追加ストレージボリュームを持つターゲットデータベースに XTTS テーブルスペースをインポートする前に、セッションレベルで db_create_file_dest パラメータを設定します。 ALTER SESSION SET db_create_file_dest = '/rdsdbdata2/db'; VAR x CLOB; BEGIN :x := rdsadmin.rdsadmin_transport_util.import_xtts_tablespaces( p_tablespace_list => 'TBTEST1', p_directory_name => 'XTTS_DIR_DATA2', p_platform_id => 13); END; / PRINT :x; XTTS インポートのステータスを確認します。 ALTER SESSION SET nls_date_format = 'DD.MM.YYYY HH24:MI:SS'; COL xtts_operation_start_utc FORMAT A30 COL xtts_operation_end_utc FORMAT A30 COL xtts_operation_state FORMAT A30 COL xtts_operation_type FORMAT A30 SELECT xtts_operation_start_utc, xtts_operation_type, xtts_operation_state FROM rdsadmin.rds_xtts_operation_info; XTTS テーブルスペースのインポートが完了したら、XTTS メタデータをインポートします。 BEGIN rdsadmin.rdsadmin_transport_util.import_xtts_metadata( p_datapump_metadata_file => 'xttdump.dmp', p_directory_name => 'XTTS_DIR_DATA2'); END; / 追加ストレージボリュームでの Amazon S3 の利用 追加ストレージボリューム上にデータベースディレクトリを作成し、ファイルのステージング用に Amazon Simple Storage Service (Amazon S3) と統合する手順は次のとおりです。この統合により、Amazon S3 と追加ストレージボリューム間でファイルのダウンロードとアップロードができます。 追加ストレージボリューム上に Oracle ディレクトリを作成します。 exec rdsadmin.rdsadmin_util.create_directory('ASVDIRECTORY', 'rdsdbdata2'); Amazon S3 から追加ストレージボリュームにファイルをダウンロードします。 SELECT rdsadmin.rdsadmin_s3_tasks.download_from_s3( p_bucket_name => '<bucket_name>', p_directory_name => ' ASVDIRECTORY') AS TASK_ID FROM DUAL; 追加ストレージボリュームから Amazon S3 にファイルをアップロードします。 SELECT rdsadmin.rdsadmin_s3_tasks.upload_to_s3( p_bucket_name => '<bucket_name>', p_prefix => '<file_name_to_upload>', p_s3_prefix => '', p_directory_name => 'ASVDIRECTORY') AS TASK_ID FROM DUAL; ボリューム間でのデータとデータファイルの移動 データファイルとデータベースオブジェクトは、プライマリボリュームと追加ストレージボリュームの間で移動できます。移動前に次の要件を確認してください。 移動元と移動先の両方のボリュームに十分な空き領域が必要です。移動するファイルのサイズを確認し、移動先ボリュームに十分な空きがあることを確認してください。 データ移動操作は両方のボリュームで I/O を消費します。移動元と移動先の両方で IOPS の Amazon CloudWatch メトリクスをモニタリングし、競合が見られる場合は IOPS を引き上げてください。CloudWatch メトリクスには ReadIOPS 、 WriteIOPS 、 ReadIOPS_rdsdbdata2 、 WriteIOPS_rdsdbdata2 があります。 大規模なデータ移動はデータベース性能に影響する可能性があります。 スナップショットからリストアしたデータベースでは、遅延ロード (lazy loading) の影響でボリューム間のデータ移動に時間がかかる場合があります。詳細は Prewarm an Amazon RDS for Oracle database to reduce the impact of lazy loading を参照してください。 データファイルは RDSADMIN.RDSADMIN_UTIL.MOVE_DATAFILE プロシージャを使ってオンラインで移動できます。オンラインでのデータファイル移動機能は Oracle EE でのみ利用できます。 PROCEDURE MOVE_DATAFILE Argument Name Type In/Out Default? ------------------------------ ----------------------- ------ -------- P_DATA_FILE_ID NUMBER IN P_LOCATION VARCHAR2 IN このプロシージャのパラメータは次のとおりです。 P_DATA_FILE_ID は移動するデータファイルの file_id です P_LOCATION はデータファイルの移動先ストレージボリュームです (例: rdsdbdata2 )。 プライマリボリュームから追加ボリュームへのテーブルスペースの移動 次のコードでは、テーブルスペースをプライマリボリューム rdsdbdata から新しい追加ストレージボリューム rdsdbdata2 へ移動します。 SELECT tablespace_name,file_id,file_name FROM dba_data_files WHERE tablespace_name = 'MYNEWTABLESPACE'; TABLESPACE_NAME FILE_ID FILE_NAME ------------------------- ---------- ------------------------------------- MYNEWTABLESPACE 6 /rdsdbdata/db/ORCL_A/datafile/o1_mf_mynewtab_n563b2kn_.dbf EXECUTE rdsadmin.rdsadmin_util.move_datafile( 6, 'rdsdbdata2'); PL/SQL procedure successfully completed. SELECT tablespace_name,file_id,file_name FROM dba_data_files WHERE tablespace_name = 'MYNEWTABLESPACE'; TABLESPACE_NAME FILE_ID FILE_NAME ------------------------- ---------- ------------------------------------- MYNEWTABLESPACE 6 /rdsdbdata2/db/ORCL_A/datafile/o1_mf_mynewtab_n56cdlw2_.dbf テーブルデータとインデックスのボリューム間移動 追加ストレージボリューム上にテーブルスペースを作成し、特定のデータベースオブジェクト (テーブル、インデックス、パーティション) をそのテーブルスペースに移動することで、データベースストレージを最適化できます。次の例のように標準的な Oracle コマンドを使います。このアプローチは、アクセスパターンの異なるデータが混在するデータベースの性能チューニングに有効です。これらのコマンドは Oracle EE と Oracle SE2 の両方で使えますが、オンライン操作でのデータベースオブジェクト移動は Oracle EE でのみ可能です。たとえば、アクセス頻度の高い業務データを高性能なストレージボリュームに配置し、アクセス頻度の低い履歴データを低コストのストレージボリュームに移動するといった使い方ができます。 追加ボリューム上に新しいテーブルスペースを作成します。 ALTER SESSION SET db_create_file_dest = '/rdsdbdata2/db'; CREATE TABLESPACE new_tablespace DATAFILE SIZE 10G; CREATE TABLESPACE historical_data DATAFILE SIZE 10G; テーブルをオンライン操作で追加ストレージボリュームに移動するには (Oracle EE のみ)、次のコードを使用します。 ALTER TABLE employees MOVE TABLESPACE new_tablespace ONLINE; テーブルパーティションをオンライン操作で追加ストレージボリュームに移動するには (Oracle EE のみ、パーティショニングも EE の機能)、次のコードを使用します。アクセス頻度の低いデータを、追加ボリューム上の historical_data テーブルスペースに移動します。 ALTER TABLE orders MOVE PARTITION orders_2022 TABLESPACE historical_data ONLINE; インデックスをオンライン操作で追加ストレージボリュームに移動するには (Oracle EE のみ)、次のコードを使用します。 ALTER INDEX employees_idx REBUILD ONLINE TABLESPACE new_tablespace; データ移動の進捗をモニタリングするには、次のクエリを使用します。 長時間操作のあるアクティブセッションを確認します。 SELECT sid,opname,sofar,totalwork,time_remaining,elapsed_seconds FROM v$session_longops WHERE time_remaining > 0; テーブルスペースの使用量を確認します。 SELECT tablespace_name, used_percent FROM dba_tablespace_usage_metrics ORDER BY used_percent DESC; 追加ストレージボリューム利用のベストプラクティス Amazon RDS for Oracle で追加ストレージボリュームを使用する際のベストプラクティスを以下にまとめます。 BLOB や CLOB オブジェクトを含むテーブルが大容量のストレージを消費しているが、アクセス頻度が低い場合は、追加ストレージボリューム上に LOB データ用テーブルスペースを作成し、ラージオブジェクトを移動することで最適化できます。 Amazon RDS ストレージサイズを縮小するには、追加ストレージボリューム上のオブジェクトとテーブルスペースを移動・削除した後に、追加ストレージボリュームを削除します。プライマリボリューム ( rdsdbdata ) は削除できません。追加ボリュームは中身が空の場合にのみ削除できます。 本番環境で実施する前に、開発環境でプライマリから追加ストレージボリュームへのデータ移動操作をテストし、所要時間と性能のベースラインを把握してください。所要時間はオブジェクトのサイズ、IOPS、データベースの負荷状況に依存します。 v$session_longops のクエリやテーブルスペース使用量のモニタリングでデータ移動の進捗を監視してください。 Amazon RDS のストレージ操作は 追加ストレージボリューム では各ボリュームが独立して動作するため、仕組みが異なります。たとえば、io2 ストレージタイプで 45 TiB のプライマリボリューム ( rdsdbdata ) と、gp3 ストレージタイプで 10 TiB の追加ストレージボリューム ( rdsdbdata2 ) を持つ RDS for Oracle インスタンスでは、各ボリュームに対して同時にストレージ変更操作をトリガーできます。プライマリボリュームの IOPS を上げる操作を実行中に、 rdsdbdata2 のボリュームを 2 TiB スケールアップするなど、別の変更操作をトリガーできます。各操作は別々のボリューム上で行われるため、複数のストレージ変更操作を同時に実行できます。 追加ストレージボリュームを持つ RDS インスタンスのスナップショットには、すべてのボリュームが含まれます。特定のボリュームだけのスナップショットは取得できません。 スナップショットからリストアする際は、新しい追加ストレージボリュームを追加したり、既存の追加ストレージボリュームを変更したりできます。ポイントインタイムリカバリ (PITR) でも同様です。 データファイルの移動操作が完了した後は、必ずスナップショットを取得し、正しいファイルの場所が最新のスナップショットに反映されるようにしてください。 リードレプリカを持つ RDS for Oracle インスタンスで追加ストレージボリュームを使用する場合は、プライマリインスタンスとレプリカインスタンスの動作を一致させるため、セッションレベルの変更ではなくパラメータグループ設定でデータファイルの場所を管理することをお勧めします。 Oracle にはデータをアーカイブするためのソリューションが複数あります。Oracle In-Database Archiving (IDA)、Oracle Data Pump Access Driver、Oracle Partitioning などがあり、これらに限定されません。Oracle のアーカイブは Oracle Information Lifecycle Management (Oracle ILM) でも実装できます。Oracle ILM ではデータクラスを定義し、異なるストレージ層に配置できます。Oracle ILM は、データパーティショニング、Advanced Row Compression、Hybrid Columnar Compression、Automatic Data Optimization (ADO)、Heat Map、Direct NFS Client、Clonedb、SecureFiles、In-Database Archiving、Database File System (DBFS) などの Oracle 機能も活用できます。追加ストレージボリュームを持つ RDS for Oracle インスタンスで Oracle ILM を実装できます。データベースでのデータ移動の ILM 戦略を実装するには、Heat Map と ADO 機能を使用してください。詳細は Using Heat Map を参照してください。 Multi-AZ が有効な RDS for Oracle インスタンスで追加ストレージボリュームを使用する場合、各ボリュームはスタンバイインスタンスに並行してレプリケーションされます。書き込みのレプリケーション帯域幅が増加するという利点があります。 追加ストレージボリュームでは、I/O 関連の CloudWatch メトリクスにボリュームごとの新しいメトリクスが追加されます。 FreeStorageSpace WriteThroughput ReadThroughput WriteIOPS ReadIOPS WriteLatency ReadLatency DiskQueueDepth たとえば、ボリュームレベルの WriteIOPS は CloudWatch コンソールで「WriteIOPS (per volume)」と表示されます。 より正確には、ボリュームレベルのメトリクスは CloudWatch のディメンション (DbInstanceIdentifier, VolumeName) で取得できます。 プライマリストレージボリューム (rdsdbdata) 向けに 拡張モニタリング で収集されていたメトリクスは、追加ストレージボリュームでも収集されるようになりました。これらの OS メトリクスは Amazon RDS コンソール の モニタリング タブで 拡張モニタリング を選択して確認できます。拡張モニタリングメトリクスの一覧と説明は 拡張モニタリングの OS メトリクス を参照してください。 まとめ 本記事では、Amazon RDS for Oracle に導入された追加ストレージボリューム機能の概要、ユースケース、主な利点を紹介しました。あわせて、追加ストレージボリュームを使用する際のベストプラクティスと考慮事項も解説しました。ご質問やフィードバックがあれば、コメント欄にお寄せください。 著者について Yamuna Palasamudram Yamuna は、AWS のプリンシパルデータベーススペシャリストソリューションアーキテクトです。AWS のリレーショナルデータベースチームで Oracle などの商用データベースエンジンを担当しています。お客様の AWS 上でのリレーショナルデータベースワークロードの設計、デプロイ、最適化を支援し、技術ガイダンスを提供しています。 Amit Grover Amit は、リレーショナルデータベース分野で 20 年以上の経験を持ち、現在は RDS Commercial Engines のプリンシパルエンジニアとして勤務しています。マルチテナントデータベースの設計、ストレージおよび I/O サブシステムの再設計に取り組んでいます。 この記事はSolutions Architect の 矢木 覚が翻訳しました。

本記事は 2026 年 5 月 21 日に公開された Mike George 氏の “ Test Driven Development (TDD) with Kiro: this is how it should feel ” を翻訳したものです。 私のキャリアの初期に、所属していた組織は、コード品質の向上と自信を持ってリファクタリングできる体制づくりのために、本格的にユニットテストを導入するという正しい判断を下しました。私たちは テスト駆動開発（TDD） の導入を試みました。その利点は理解していたものの、TDD を実践する作業自体が負担に感じられ、エンジニアたちにこの手法を一貫して適用してもらえませんでした。私自身、TDD というアイデアは大好きでしたが、実際の作業は嫌いでした。本記事では、Kiro を使って TDD を実践する方法を紹介し、red-green-refactor サイクルに沿ったテストを手作業で書くという苦痛を伴うことなく、TDD の恩恵を受ける方法をお見せします。 テスト駆動開発（TDD）の概要 テスト駆動開発の基本的な考え方は次のとおりです。 構築する新機能ごとに、その新機能の振る舞いを特定します。 新しい振る舞いそれぞれに対して、もしその振る舞いが存在すればパスするはずのテストを書きます。 テストを実行します。振る舞いがまだ存在しないため、すべてのテストは失敗するはずです。 新しいテストをパスさせるもっともシンプルなコードを書きます。 すべてのテストがパスし続けることを確認しながら、必要に応じてリファクタリングします。 これが red-green-refactor サイクルと呼ばれるものです。書いたテストが失敗し（red フェーズ）、テストをパスさせるためにコードを書き（green フェーズ）、必要に応じてリファクタリングを続ける（refactor サイクル）という流れです。TDD は高品質なコードを生み出すのに役立ちますが、時間がかかると見られがちで、プロセスを一貫して守るためにかなりの規律が求められます。 私は TDD のアイデアは大好きでしたが、テストコードと実装コードの間を行き来するためのコンテキストスイッチが嫌いでした。どのテストを書いたかを管理することも好きではなく、率直に言って、TDD をきちんと実践するために必要なすべてのテストを書く単調さも嫌でした。TDD の経験について他の人と話すと、自分だけがそう感じているわけではないことがよくわかります。 Kiro のようなエージェント型開発ツールは、TDD のこうした欠点をうまく扱ってくれます。Kiro は仕様駆動開発をサポートしています。これは、Kiro が正しいものを正しい方法で正しいアーキテクチャに沿って構築できるよう導く、3 つのフェーズからなる開発プロセスです。各 spec は次の 3 つのフェーズで構成されます。要件フェーズでは、Kiro がユーザーストーリーと受け入れ基準の定義と承認を支援します。設計フェーズでは、技術アーキテクチャと実装アプローチを定義します。タスクフェーズでは、元の要件を満たすコードを生み出すための実行可能な実装タスクを定義します。 Kiro は仕様駆動開発に加えて、 hooks もサポートしています。hooks は、IDE で特定のイベントが発生したときに自動的に実行される自動化ツールです。たとえば、ファイルが保存されるたびにコードを lint する hook を作成したい場合などです。要するに、仕様駆動開発が全体的なエンジニアリングのアプローチを構造化するのに役立つ一方、hooks は TDD のような特定のプラクティスの徹底を可能にします。 私の場合は、TDD の取り組みを支援するために Kiro hook を作成しました。 本番環境での利用におけるセキュリティ上の考慮事項 このチュートリアルは、教育目的で例示プロンプトを使用して Kiro の TDD 機能を紹介しています。本番システム向けにこのアプローチを適用する場合は、次の点に留意してください。 デプロイ前に、 AI が生成したコードのセキュリティ脆弱性を必ずレビューしてください 。とくに、認証、認可、入力検証、データ処理ロジックには注意が必要です。コードが正しく動作することを確認するため、さまざまなシナリオでテストしてください。 この例では簡潔さのために認証なしのオープンな API を使っていますが、 本番環境のデプロイには包括的なセキュリティ対策が必要です 。具体的には、認証と認可、HTTPS/TLS 暗号化、保存時の暗号化、入力検証、レート制限、包括的なロギング、認証情報のシークレット管理などです。 AI 開発ツールを採用する組織は、アクセス制御、コード品質モニタリング、検証プロセスに関する ガバナンスポリシーを確立する 必要もあります。 包括的なセキュリティガイダンスについては、所属組織のセキュリティチームに相談し、 AWS のセキュリティのベストプラクティスに関するドキュメント を参照してください。 Kiro と TDD の統合 Kiro 内で hook を作成するには、Kiro タブに移動し、 agent hooks ウィンドウの「+」ボタンをクリックして manually create a hook を選択します。表示されたウィンドウで、以下を入力します。 Title ： TDD: Test First Description ： 本番コードを書く前に、失敗するテストを書くよう促すことでテスト駆動開発を徹底します。red/green/refactor サイクルに従います。すなわち、失敗するテストを書き（red）、それをパスさせる最小限のコードを書き（green）、その後リファクタリングします。 Event ： Pre Tool Use Tool name ： write Action ： Ask Kiro Instructions for Kiro agent （以下は和訳です。原文は英語で記述されています）： 待ってください！ あなたは今コードを書こうとしています。TDD に従い、まずテストを書いてください。 必要なアクション: 1. これがテストファイル（*test*.py、*.spec.* など）の場合 — 続行する 2. これが例外（設定ファイル、ドキュメント、.kiro/）の場合 — 続行する 3. 対応するテストファイルが存在し、かつ実行した結果すべてのテストが失敗（RED フェーズ）していることが確認できている場合 — 続行する 4. それ以外の場合 — 中断し、まずテストファイルを書く: a. test_<filename>.py（または同等のもの）を作成する b. （単なる import ではなく）実際のアサーションで失敗するテストを書く c. テストを実行し、すべてがアサーションエラーで失敗することを確認する d. その後、戻ってこの実装を書く TDD サイクル: - RED: まず失敗するテストを書く（新しいテストはすべてアサーションで失敗しなければならない） - GREEN: テストをパスさせる最小限のコードを書く - REFACTOR: テストが green のままになるようにしつつコードを整理する RED フェーズの要件: - すべてのテストは AssertionError またはテスト失敗で失敗しなければならない - RED フェーズでいずれかのテストがパスする場合、そのテストは弱い／中身がない - RED フェーズでテストがパスするのは、空のループ、アサーションの欠落、テスト内のロジックエラーを意味する 正しい RED フェーズ: すべてのテストが AssertionError で失敗している 不正な RED フェーズ: 一部のテストがパスする、ImportError、ModuleNotFoundError、構文エラー 例外（テストなしで続行してよいもの）: - テストファイル: *test*.py、*.spec.*、*.test.*、test_*.py、*_test.go - 設定: package.json、tsconfig.json、.eslintrc、webpack.config.js、vite.config.ts、jest.config.js、pytest.ini、setup.py、pyproject.toml、requirements.txt、Dockerfile、docker-compose.yml、.env、.gitignore - .kiro/ ディレクトリ内のファイル - 型定義: .d.ts ファイル、Protocol クラス - ドキュメント: .md、.txt、.rst、LICENSE、README、CHANGELOG - データファイル: .json、.yaml、.yml、.xml、.csv、.sql、.html、.css、.scss（ロジックを含まないもの） - ビルド成果物: dist/、build/、__pycache__/、*.pyc、node_modules/ 先にテストを必要とするもの: - 関数／クラスを含む Python ファイル（テストパターンに一致しない .py） - ロジックを含む JavaScript／TypeScript（テストパターンに一致しない .js、.ts、.jsx、.tsx） - 実行可能なロジックを含むすべてのソースコード（Go、Java、C#、Ruby など） 重要な確認: テストを実行し、すべてのテストが失敗したことを確認しましたか？ スタブ実装でいずれかのテストがパスした場合は、まずテストを修正してください。すべてのテストが失敗する適切な RED フェーズが得られたときにのみ続行してください。 画面の一番下までスクロールし、 Create Hook をクリックします。 この hook は、Kiro がファイルを保存しようとするたびに実行されます。コードを書いている過程で red-green-refactor サイクルが守られているかをチェックします。 簡単なテストとして、 モンティ・ホール問題 を示すプログラムを書くよう Kiro に依頼してみました。Kiro はユニットテストを書き、それらは失敗します。次に Kiro は、対応するモジュールがまだ存在しないためにテストが失敗していることに気づきます。hook によれば、テストはアサーションの失敗によって失敗しなければなりません。そこで Kiro は基本的なモジュールを作成し、テストがアサーションエラーで失敗することを確認します。その後、テストをパスさせるための最小限のコードを書きます。 このシンプルな例で hook が機能していることがわかりますが、もう少し現実的なもの、つまり本番環境向けの REST ベースの API の構築でどう動くか見てみましょう。 REST ベースの API を構築する 実際のコードを書くため、私は Kiro の spec セッション を開始し、タスク管理システム用の REST ベースの API を構築するための要件を入力しました。最終的な要件ドキュメント（以下は和訳です。原文は英語で記述されています）は以下のとおりです。 # 要件ドキュメント ## はじめに タスク管理システム用の REST API です。この API は、永続化のための リレーショナルデータベースまたは組み込みデータベース（PostgreSQL や SQLite など）を備えた Python の Web フレームワーク（Flask や FastAPI など）を使って構築します。アプリケーションは Docker コンテナ としてパッケージ化されるため、コンテナをサポートする任意の プラットフォームにデプロイできます。この API はオープン（認証・認可 なし）です。タスクに対する完全な CRUD 操作をサポートし、クライアントが タスクを作成・読み取り・更新・削除できるようにします。フロントエンドは ありません。これは API のみのサービスです。 ## 用語集 - **API_Server**: HTTP リクエストを受け取り、適切なリクエスト ハンドラーへルーティングする Python の Web フレームワーク アプリケーション（Flask や FastAPI など） - **Task_Service**: タスク関連のビジネスロジックの処理を担う、 コンテナ内で動作するアプリケーションロジック - **Task**: 一意の識別子、タイトル、説明、ステータス、 タイムスタンプといったプロパティを持つ作業単位 - **Task_Store**: タスクが格納・取得されるリレーショナル データベースまたは組み込みデータベース（PostgreSQL や SQLite など） - **Client**: API に HTTP リクエストを送信する外部システム またはユーザー - **Dockerfile**: アプリケーションとその依存関係をポータブルな Docker イメージにパッケージ化する、コンテナのビルド定義 - **Container**: API_Server と Task_Service をホストする、 Docker イメージの実行中インスタンス - **Standard_Error_Format**: すべての API エラーレスポンスで 使われる一貫した JSON エラーレスポンス構造。 `{"error": "<説明的なメッセージ>"}` の形式 ## 要件 ### 要件 1: タスクの作成 **ユーザーストーリー:** クライアントとして、API を通じて 新しいタスクを作成したい。作業項目を追跡できるようにするためである。 #### 受け入れ基準 1. WHEN クライアントが title と description の両方を含む有効な リクエストボディとともに `/tasks` へ POST リクエストを送信する、 THE Task_Service SHALL Task_Store に新しい Task を作成し、 一意の識別子を持つ作成済みの Task を HTTP ステータス 201 とともに返す 2. WHEN クライアントが必須フィールド（title または description）が 欠落したリクエストボディとともに `/tasks` へ POST リクエストを 送信する、THE Task_Service SHALL Standard_Error_Format の エラーメッセージとともに HTTP 400 レスポンスを返す 3. THE Task_Service SHALL 新しく作成された各 Task に、一意の識別子、 `createdAt` タイムスタンプ、`updatedAt` タイムスタンプを割り当てる 4. THE Task_Service SHALL 新しい Task の初期ステータスを "pending" に設定する ### 要件 2: 単一タスクの取得 **ユーザーストーリー:** クライアントとして、識別子を指定して 特定のタスクを取得したい。その詳細を閲覧できるようにするためである。 #### 受け入れ基準 1. WHEN クライアントが有効なタスク識別子とともに `/tasks/{taskId}` へ GET リクエストを送信する、 THE Task_Service SHALL 一致する Task を HTTP ステータス 200 とともに返す 2. WHEN クライアントが Task_Store に存在しないタスク識別子とともに `/tasks/{taskId}` へ GET リクエストを送信する、 THE Task_Service SHALL Standard_Error_Format の エラーメッセージとともに HTTP 404 レスポンスを返す ### 要件 3: 全タスクの一覧取得 **ユーザーストーリー:** クライアントとして、すべてのタスクを 一覧表示したい。追跡中の全作業項目の概要を確認できるように するためである。 #### 受け入れ基準 1. WHEN クライアントが `/tasks` へ GET リクエストを送信する、 THE Task_Service SHALL Task_Store のすべての Task のリストを HTTP ステータス 200 とともに返す 2. WHEN Task_Store に Task が 1 つも存在しない、 THE Task_Service SHALL 空のリストを HTTP ステータス 200 とともに返す ### 要件 4: タスクの更新 **ユーザーストーリー:** クライアントとして、全体を置き換える形で 既存のタスクを更新したい。タイトル、説明、ステータスを変更できるように するためである。 #### 受け入れ基準 1. WHEN クライアントが有効なタスク識別子と、すべての必須フィールド （title、description、status）を含むリクエストボディとともに `/tasks/{taskId}` へ PUT リクエストを送信する、 THE Task_Service SHALL Task_Store 内の一致する Task を完全に 置き換え、更新後の Task を HTTP ステータス 200 とともに返す 2. WHEN クライアントが Task_Store に存在しないタスク識別子とともに `/tasks/{taskId}` へ PUT リクエストを送信する、 THE Task_Service SHALL Standard_Error_Format の エラーメッセージとともに HTTP 404 レスポンスを返す 3. WHEN クライアントが必須フィールド（title、description、status） のいずれかが欠落したリクエストボディとともに `/tasks/{taskId}` へ PUT リクエストを送信する、THE Task_Service SHALL Standard_Error_Format のエラーメッセージとともに HTTP 400 レスポンスを返す 4. THE Task_Service SHALL Task が変更されるたびに `updatedAt` タイムスタンプを更新する ### 要件 5: タスクの削除 **ユーザーストーリー:** クライアントとして、タスクを削除したい。 不要になった作業項目を完全に除去できるようにするためである。 #### 受け入れ基準 1. WHEN クライアントが有効なタスク識別子とともに `/tasks/{taskId}` へ DELETE リクエストを送信する、 THE Task_Service SHALL Task_Store から Task を完全に削除し、 HTTP ステータス 204 を返す 2. WHEN クライアントが Task_Store に存在しないタスク識別子とともに `/tasks/{taskId}` へ DELETE リクエストを送信する、 THE Task_Service SHALL Standard_Error_Format の エラーメッセージとともに HTTP 404 レスポンスを返す ### 要件 6: リクエストの検証 **ユーザーストーリー:** クライアントとして、不正なリクエストに 対して明確なエラーレスポンスがほしい。API 呼び出しの問題を 修正できるようにするためである。 #### 受け入れ基準 1. WHEN クライアントが無効な JSON ボディを含むリクエストを送信する、 THE API_Server SHALL Standard_Error_Format の エラーメッセージとともに HTTP 400 レスポンスを返す 2. WHEN クライアントが未定義のルートへリクエストを送信する、 THE API_Server SHALL HTTP 404 レスポンスを返す 3. WHEN クライアントが定義済みのルートに対してサポートされていない HTTP メソッドを使ってリクエストを送信する、THE API_Server SHALL HTTP 405 レスポンスを返す ### 要件 7: 入力長の検証 **ユーザーストーリー:** クライアントとして、API に妥当な入力長を 強制してほしい。過度に大きな入力が拒否されるようにするためである。 #### 受け入れ基準 1. WHEN クライアントが 100 文字を超える `title` フィールドを含む リクエストを送信する、THE Task_Service SHALL title が長すぎる ことを示す Standard_Error_Format のエラーメッセージとともに HTTP 400 レスポンスを返す 2. WHEN クライアントが 1000 文字を超える `description` フィールドを 含むリクエストを送信する、THE Task_Service SHALL description が 長すぎることを示す Standard_Error_Format のエラーメッセージと ともに HTTP 400 レスポンスを返す 3. THE Task_Service SHALL 作成（POST）操作と更新（PUT）操作の 両方で入力フィールドの長さを検証する ### 要件 8: タスクのデータモデル **ユーザーストーリー:** クライアントとして、一貫したタスクの データ構造がほしい。API レスポンスを確実にパースできるように するためである。 #### 受け入れ基準 1. THE Task_Service SHALL 各 Task を次のフィールドを持つ JSON オブジェクトとして表現する: `id`（string）、`title`（string）、 `description`（string）、`status`（string）、 `createdAt`（ISO 8601 タイムスタンプ）、 `updatedAt`（ISO 8601 タイムスタンプ） 2. THE Task_Service SHALL Task の status フィールドとして次の値を 受け入れる: "pending"、"in-progress"、"completed" 3. IF クライアントが受け入れ可能な集合に含まれない status 値を 指定する、THEN THE Task_Service SHALL Standard_Error_Format の エラーメッセージとともに HTTP 400 レスポンスを返す ### 要件 9: JSON シリアライズのラウンドトリップ **ユーザーストーリー:** クライアントとして、シリアライズと デシリアライズを通じて API がタスクデータを忠実に保持してほしい。 データが失われたり破損したりしないようにするためである。 #### 受け入れ基準 1. FOR ALL 有効な Task オブジェクトについて、Task を JSON へ シリアライズし、その JSON を再び Task へデシリアライズすると、 同等の Task オブジェクトが得られる SHALL（ラウンドトリップ特性） 2. THE Task_Service SHALL すべてのリクエストボディとレスポンス ボディの唯一のデータ交換形式として JSON を使用する 3. THE Task_Service SHALL すべてのレスポンスに `Content-Type: application/json` ヘッダーを含める ### 要件 10: 標準エラーレスポンス形式 **ユーザーストーリー:** クライアントとして、すべてのエラー レスポンスが一貫した JSON 構造に従ってほしい。エラーを確実に パースして処理できるようにするためである。 #### 受け入れ基準 1. THE Task_Service SHALL すべてのエラーレスポンスを Standard_Error_Format で返す: `{"error": "<説明的なメッセージ>"}` 2. THE Task_Service SHALL すべてのエラーレスポンスに `Content-Type: application/json` ヘッダーを含める 3. THE Task_Service SHALL 各エラーレスポンスの `error` フィールドに 人間が読めるエラーの説明を提供する ### 要件 11: コンテナの構成 **ユーザーストーリー:** 開発者として、妥当なデフォルト値を備えた Docker コンテナとしてアプリケーションをパッケージ化したい。 システムがポータブルで、任意のプラットフォームに簡単にデプロイ できるようにするためである。 #### 受け入れ基準 1. THE Dockerfile SHALL API_Server と Task_Service を、必要なすべての 依存関係とともに単一の Docker イメージにパッケージ化する 2. THE Dockerfile SHALL イメージサイズを最小化するため軽量な Python ベースイメージを使用する 3. THE Container SHALL API_Server が HTTP リクエストを受け付けるための 設定可能なポート（デフォルトは 8000）を公開する 4. THE Container SHALL データベース接続設定とサーバーポートについて、 環境変数による構成をサポートする 5. THE Dockerfile SHALL API_Server が稼働しているときに HTTP ステータス 200 を返すヘルスチェックエンドポイントを `/health` に含める ### 要件 12: データベースの移植性 **ユーザーストーリー:** 開発者として、アプリケーションに標準的な リレーショナルデータベースを使ってほしい。デプロイ環境に合った データベースバックエンドを選べるようにするためである。 #### 受け入れ基準 1. THE Task_Service SHALL SQL ベースのデータベースアクセスを使用し、 Task_Store を SQLite、PostgreSQL、その他の SQL 互換データベースで 支えられるようにする 2. THE Task_Service SHALL 外部データベース接続が構成されていない場合、 Task_Store としてデフォルトで SQLite を使用する 3. WHEN 環境変数を通じて外部データベース接続文字列が提供される、 THE Task_Service SHALL Task_Store として指定されたデータベースに 接続する 4. THE Task_Service SHALL 起動時にテーブルが存在しない場合、必要な データベーステーブルを自動的に作成する 要件が揃ったら、Kiro はそれらを設計ドキュメントに、最終的にはタスクリストへとまとめ上げてくれます。各タスクを実行するたびに、TDD hook が Kiro に red-green-refactor サイクルでの作業を強制します。 例として、API の GET /tasks/{task_id} のルートハンドラーを構築するタスクを Kiro に実行させてみました。Kiro は、この機能をサポートするコードを書く前に、まず失敗するテストを書かなければならないと判断します。 Kiro はテストを構築し、それらが失敗することを確認します。これは red フェーズが正常に完了したことを意味します。次にコードを修正してテストを再実行し、テストがパスすることを確認します。これにより green フェーズが正常に完了したことが確認できます。新しいテストがパスしたら、Kiro は既存のすべてのテストを再実行し、それらが引き続き正しく動作することを検証します。 まとめ 長年の間、私は TDD と格闘してきました。コード品質の向上、バグの減少、リファクタリングへの自信といった利点を信じてはいましたが、現実は疲れるものでした。絶え間ないコンテキストスイッチ、red-green-refactor サイクルを守り続けるために必要な規律、そして実装の前にテストを書くことの苦痛が、TDD を有益なプラクティスというより負担に感じさせていました。 Kiro はこの状況を完全に変えてくれます。シンプルな hook を使うことで、TDD に必要な規律を自動化できました。hook があれば、Kiro はステップを飛ばしたり近道をしたりすることを許しません。私が意識しなくてもサイクルを守らせてくれます。コンテキストスイッチの負担、プロセスを守り続けるための規律、良いテストを書くことの単調さといった重荷を背負うことなく、TDD の恩恵を受けられるのです。本記事で示したように、モンティ・ホール問題のような単純なデモであっても、数十もの要件を持つ本番環境向けの REST API であっても、hook が TDD のプロセスを徹底してくれます。 私にとって、これこそが TDD のあるべき姿です。Kiro は、負担なしですべての恩恵を与えてくれます。 このアプローチをご自身で試してみたい方は、本記事の hook 設定をコピーして、ご自身の Kiro プロジェクトで使ってみてください。小さなプロジェクトから始めて、感触を確かめ、自分のやり方に合うように hook の指示を調整してみてください。これまで TDD で苦労してきた方や、コード品質を向上させる方法を探している方は、Kiro の hook を使った TDD をぜひ試してみてください。

みなさん、こんにちは。ソリューションアーキテクトの吉川です。FIFA ワールドカップ 2026 がいよいよ佳境を迎えていますね！先月号では「さあ、キックオフです！」とお伝えしましたが、決勝トーナメントの熱戦が続く中、もうひとつの熱い戦いの結果をお届けします。そう、6 月 25-26 日に幕張メッセで開催された AWS Summit Japan 2026 です。製造ブースには多くの方にお越しいただき、大盛況で幕を閉じました！今月の「月刊 AWS 製造」では Summit 特集として、製造ブースの展示レポートと、関連するセッション動画・ブログをまとめてお届けします。なお、リンク先には英語の記事も含まれていますが、解説を加えていますのでぜひご覧ください。 ピックアップトピック : AWS Summit Japan 2026 — 製造ブース展示レポート 6 月 25 日（水）〜 26 日（木）の 2 日間、幕張メッセ Hall 7 の AWS Industries Zone に設けられた製造業向け展示エリアが大盛況のうちに終了しました。「 AI で加速する製造業のルネッサンス 」をテーマに、未来の製造業を体感できる Highlight 展示 と、「すぐに使える」テクノロジーを実機デモで体感できる Industry 展示 の 2 エリアで構成しました。多くの来場者にお立ち寄りいただき、ありがとうございました。ここでは各展示の見どころを振り返ります。展示エリア全体の概要は「 AWS Summit Japan 2026 製造業向け展示の見どころ紹介！ 」で詳しくご紹介しています。 Highlight 展示 — 3 つのデモで体感する未来の製造 ① サプライチェーン最適化 — AI エージェントが需要急変に数分で対応 需要変動や供給遅延が発生した際に、AI エージェントが在庫枯渇の予測・生産計画への影響分析・代替調達の選択肢・対応方針案を数分で導き出す一連の流れをデモで体験いただきました。Amazon Bedrock AgentCore と時系列基盤モデル Chronos-2 による多変量需要予測、Amazon Bedrock Knowledge Bases によるサプライヤー情報検索を組み合わせ、従来数時間かかっていた意思決定を大幅に短縮します。詳しくは「 AWS Summit 2026 Supply Chainブースのご紹介 」をご覧ください。 図: サプライチェーン。市場の変化に応じて、生産計画に反映できる需要予測を行う AI エージェント ② 生産ラインの未来（スマートマニュファクチャリング） — デジタルツイン × AI で自律的に最適化 ナレッジグラフと IoT リアルタイムデータを活用し、AI エージェントが生産ラインを自律的に最適化するデモを展示しました。インパクト分析・ボトルネック検出・改善提案を AI が行い、PLC プログラムの修正案まで自動生成。後述のソフトウェア定義工場の展示と合わせて、デジタルツインで検証した上で本番環境に適用するという「生産ラインの CD（Continuous Delivery）」を実現するアーキテクチャをご紹介しました。詳しくは「 AWS Summit Japan 2026 ブース紹介 生産ラインの未来 」をご覧ください。 図: 生産ラインの未来。デジタルツインとナレッジグラフを元に AI エージェントがボトルネックを特定し、かつ、改善案まで実装する ③ ソフトウェア定義型ファクトリー — PLC を仮想化し、生産ラインをコードで制御 物理 PLC を仮想化し「ソフト PLC」として動作させることで、生産ラインの制御ロジックをソフトウェアとして管理するデモを展示しました。AI コーディングエージェントが自然言語の指示をもとにソフトウェア PLC の CODESYS 上の制御プログラム（ST プログラム）を修正し、NVIDIA Isaac Sim を用いた仮想環境でシミュレーション検証した上で実機に適用します。Git リポジトリによるバージョン管理とエッジからクラウドまでの一気通貫アーキテクチャにより、生産ラインの変更を安全かつ迅速に実現できることをお伝えしました。詳しくは「 AWS Summit Japan 2026 ブース紹介 ソフトウェア定義型ファクトリー 」をご覧ください。 図: ソフトウェア定義型ファクトリー。仮想化された PLC の制御ロジックで、物理工場を動かす Industry 展示 — 「すぐに使える」テクノロジーを実機デモで体感 Product Engineering（製品設計開発） AI コーディングエージェント Kiro を活用し、自然言語による 3D モデル生成、CAE シミュレーション実行、Physical AI の強化学習トレーニングまでをコーディングなしで実現するデモを展示しました。詳しくは「 AWS Summit Japan 2026 ブース紹介 — 生成 AI 時代の製品設計開発 」をご覧ください。 図: Kiro で 3D 形状作成 & シミュレーション実行。すべて自然言語で Kiro が生成 — 人間が書いたコードは 0 行 Engineering Development Hub（EDH） CAD/CAE アプリケーション向けの仮想デスクトップ・HPC 環境を AWS 上で提供するフレームワークです。エンジニアがオンデマンドで高性能コンピューティングリソースにアクセスできる環境を体験いただきました。 図: Engineering Development Hub。設計開発で使用するワークステーションならびに HPC クラスタ環境を簡単に展開、管理、実行する、AWS CloudFormation ベースのソリューション。 Smart Products and Services（スマート製品開発・運用） Kiro による AI 駆動ソフトウェア開発の加速と、Amazon Quick を用いたデータドリブンな製品改善サイクルのデモを展示。部門横断のデータ分析を AI が支援し、スマート製品の SDLC 全体を加速するアプローチをご紹介しました。詳しくは「 Accelerating Smart Product SDLC with AI Agent Workshop のご紹介 」をご覧ください。   図: AI エージェントによるスマート製品開発の加速ワークショップ   図: Amazon Quick によるアフターマーケット分析ワークショップ AWS 認定デバイスウォール 日本で認定された 248 以上の IoT デバイスの中から 10 デバイス実機を一堂に展示。AWS IoT サービスとシームレスに連携するカメラ、ゲートウェイ、産業用 PC などを実際にご覧いただけるエリアでした。IoT 関連の展示全体については「AWS Summit Japan 2026 -AWS IoT サービスを活用した展示の一部をご紹介-」もあわせてご覧ください。  写真: AWS 認定デバイスウォール Physical AI（ロボット × AI エージェントの自律オペレーション） FANUC CRX-20iA/L 協働ロボットと Amazon Bedrock AgentCore 上の AI エージェントを組み合わせ、「調査→判断→復旧」を自律的に完走するデモを展示しました。AI エージェントが現実世界の物理的な操作を伴うオペレーションを遂行する仕組みを体感いただけるエリアでした。詳しくは「 Physical AI — AI エージェントが現実世界で「見て、考えて、動かす」自律オペレーションの実現 」をご覧ください。 写真: Physical AI 展示 AWS Summit セッション動画のご紹介 AWS Summit Japan 2026 のセッション動画がオンデマンドで公開されています。製造業に関連するセッションをピックアップしてご紹介します。 AWS Summit Japan 2026 オンデマンド動画 AWS Summit Japan 2026 の全セッション動画がオンデマンドで視聴可能です。260 を超えるセッションの中から、気になるテーマを選んでご覧いただけます。 基調講演 AI エージェントが実現できることの限界を押し広げる今、AWS がエージェントの構築・デプロイ・スケーリングをいかに容易にしているかをご覧いただけます。登壇者: 長﨑 忠雄 氏（OpenAI Japan）、歌門 正師 氏（東京海上日動火災保険）、横路 隆 氏（フリー）、デイブ・ブラウン（AWS）、白幡 晶彦（AWS Japan）。 情報を集め、判断し、行動する時代へ：データ基盤・AI エージェント・エッジ AI で変わる製造現場 製造設備や産業用製品が自ら情報を収集し、判断・行動する自律的な仕組みの実現に向けた設計指針と実装パターンを、デモとともに紹介するセッションです。前半では生成 AI を活用した予知保全や品質異常検知のユースケースと、OT/IT シームレス連携を実現するデータ正規化の手法を解説。後半ではエッジコンピューティング上での AI 活用により、プライバシー保護と低レイテンシーを両立するアプローチを紹介しています。登壇者: 深澤 真愛（ソリューションアーキテクト）。 Physical AI における学習・運用での AWS 活用方法 ロボットが「見て、考え、学び、行動する」Physical AI を AWS で実現するための実践的アプローチを紹介するセッションです。IoT Core・Greengrass・Strands Agents によるデータ収集と制御から、SageMaker でのモデル学習、実機デプロイまでを解説しています。登壇者: 大前 遼（ソリューションアーキテクト）。 クラウドと AI で創る製造業の未来 ― コニカミノルタ × FPT の挑戦 ― 製造業における大規模クラウド移行と AI 活用を成功に導く実践事例を紹介するセッション（FPT スポンサー）です。コニカミノルタ、FPT、AWS のシナジーで技術者不足やナレッジの属人化といった課題を乗り越えたプロセスを解説。さらに共同開発中の次世代 3 層アーキテクチャ自立型エージェント基盤も紹介されています。登壇者: 前野 好太郎 氏（FPT ジャパンホールディングス 執行役員）、岩本 博史 氏（コニカミノルタ FPT ソリューションラボ 代表取締役 CEO）。 AWS Summit New York City 2026 — AI エージェントに「コンテキスト」を与える新発表 6 月 17 日にニューヨークで開催された AWS Summit NYC 2026 では、AWS VP of Agentic AI の Swami Sivasubramanian による基調講演が行われ、AI エージェントの構築・運用に関する重要な新機能が多数発表されました。テーマは「 AI エージェントにコンテキストを与え、信頼できる意思決定を実現する 」こと。製造業の現場でも、設備データ・品質データ・サプライヤー情報など散在するデータをエージェントが横断的に理解できるかが鍵となるため、今回の発表は注目に値します。 主な発表のうち、製造業に関連性の高いものをピックアップします： AWS Context（Coming soon） — 組織内のデータ間の関係性をナレッジグラフとして自動マッピングし、AI エージェントがランタイムでガバナンス付きのデータ関係・ビジネスルール・ドメイン知識にアクセスできる新サービスです。製造現場では設備マスタ、BOM、品質基準、サプライヤー情報など複数システムにまたがる関係性を AI が理解する基盤として活用が期待されます。Apache Iceberg 形式で公開されるため、既存のデータレイク基盤ともシームレスに連携可能です。 Amazon Bedrock AgentCore ハーネス（GA） — エージェントのモデル・ツール・スキル・設定を定義するだけで、オーケストレーションループをコーディングすることなくプロダクショングレードの AI エージェントを数分で構築・実行できるようになりました。Summit Japan の製造展示でも中核技術として活用されていた AgentCore が、さらに使いやすくなりました。 Amazon Bedrock Managed Knowledge Base — エンタープライズ RAG パイプラインをマネージドで構築可能に。ネイティブデータコネクター、マルチフォーマット対応のスマート解析、エージェンティックリトリーバーを備えています。製造業の設計文書・作業手順書・品質マニュアルなど大量のドキュメントを AI に活用させたい場合に有効です。 Amazon S3 Annotations（GA） — S3 オブジェクトに最大 1 GB のリッチなコンテキストを直接アタッチし、クエリ可能にする機能が一般提供開始。IoT データや設備ログに対してメタデータを付与し、AI エージェントが自律的にデータを発見・理解するための基盤として活用できます。 Kiro for iOS（Gated Preview） — エージェント型 IDE「Kiro」のネイティブ iOS アプリが発表されました。スマートフォンからセッションの開始・監視・差分確認・変更承認が可能に。現場を飛び回る製造エンジニアにとって、移動中でも開発状況を確認できるのは嬉しいアップデートです。 詳細は以下のブログをご覧ください： ニューヨークで開催される 2026 年の AWS Summit に関する主要なお知らせ Context intelligence for your data and AI agents at scale （英語） 最後まで読んでいただきありがとうございました。ワールドカップも AWS Summit Japan も熱い夏でしたね。来月も引き続き製造業の皆さまに役立つ情報をお届けしていきます。来月も 月刊 AWS 製造ブログ をよろしくお願いします。それでは、また来月お会いしましょう！ 著者について Kohei Yoshikawa ソフトウェア開発者およびシステムインテグレーターとして 20 年以上従事した後、2020 年から AWS Japan で活動中。エンタープライズ事業本部で、日本の多くの製造業や SI 事業のお客様の AWS 活用を支援してきた。スマートプロダクトのためのサービス開発に興味を持ち、最近は AI 開発エージェントを用いた製品開発ライフサイクルの加速に取り組んでおり、お客様との会話のネタが尽きない毎日を送っている。趣味は週末のサイクリング、冬はスキー。風を切る乗り物がとにかく好き。 TAGS: AWS Manufacturing Monthly

2026年6月11日（木）、12日（金）の2日間、AWS 麻布台オフィスにて AI 駆動型ハッカソンイベント「AWS GenAI Catapult! 」を開催いたしました。本イベントは、生成 AI 活用を前提にAmazon のイノベーション創出メカニズム「Working Backwards」手法を用いて顧客起点で生成 AI ユースケースを創出し、プロトタイプ開発まで行うコンテスト形式のイベントです。 前回 に続く2回目の開催となる今年は、創出したユースケースを AI コーディングエージェント「Kiro」でプロトタイピングし、アイデアを「動くもの」に変えるところまでを2日間で一気通貫に体験するという新たな挑戦を加えました。金融領域の13社12チーム（47名）の皆様にご参加いただき、活発な議論と創造的なアイデア創出、プロトタイプ開発、そして各社それぞれの工夫を凝らした内容で熱のこもった発表が行われました。本記事では、企画の背景から当日の様子、参加者の声までをお届けします。 前回開催からの進化 — アイデア創出から「動くプロトタイプ」へ 昨年7月の「AWS GenAI Catapult! 」は、Working Backwards によるアイデア創出を中心とし、プロトタイプの提示は任意（加点要素）、発表は初日から約3週間後に別日を設けて実施する形式でした。今年は昨今の生成 AI の進化に伴い次の3点を大きくアップデートして、「考える」から「作る」まで地続きで体験できるようにしたことが、今年最大の特徴です。 連続2日間で完結：学び・アイデア創出・開発・発表までを途切れさせずに2日間でやり切る構成に変更 Kiro によるプロトタイプ開発を本格導入：アイデアを構想で終わらせず、その場で動くアプリケーションとして形に 発表は「動くデモ」付き：プレスリリースに加えてプロトタイプのデモを披露 企画の背景 日本企業の生成 AI 活用の現状 — AI活用の方針は前進、しかし「使いこなし」はこれから 総務省の 令和7年版 情報通信白書 によると、日本企業で生成 AI の活用方針を「定めている」とした比率は 49.7% （前回の調査の 42.7% から増加）と着実に前進しました。一方で、調査した他国と比較すると依然として低い水準にとどまっています。実際の利用面でも、何らかの業務で生成 AI を利用している企業は日本で 55.2% 、「メールや議事録、資料作成等の補助」での利用は 47.3% と、いずれも他国より低い割合でした。導入に際しての懸念事項として日本企業が最も多く挙げたのは「 効果的な活用方法がわからない 」で、次いで社内情報の漏えい等のセキュリティリスク、ランニングコスト、初期コストが続きます。生成 AI を「どう自分たちの価値創出につなげるか」という具体的な適用イメージを描けていないことが、依然として大きな壁になっていると考えられます。 「業務効率化」の先へ — 顧客起点のイノベーションという課題 同白書では、生成 AI 活用による自社への影響について、日本企業は「 業務効率化や人員不足の解消につながる 」を最も多く挙げました。これに対し、米国・ドイツ・中国の3か国では「ビジネスの拡大」「新たな顧客獲得」「新たなイノベーション」を多く挙げる傾向が見られます。つまり日本では、生成 AI が業務効率化の手段にとどまりがちで、新たな顧客価値の創造へと踏み込めていない構図がうかがえます。金融業界でも、技術起点のアプローチに偏り、顧客価値創出に課題を抱えるケースは少なくありません。 「AWS GenAI Catapult! 」は、まさにこの「業務効率化の先」へ一歩踏み出すための場です。顧客起点でユースケースを発想し、その価値をその場で検証する体験を通じて、生成 AI 活用を効率化からイノベーション創出へと引き上げることを狙いました。 Amazon 流・顧客起点のイノベーション創出メカニズム「Working Backwards」 Amazon が実践してきたイノベーション創出のメカニズム「Working Backwards」手法 は、Amazon Echo、Amazon Prime、AWS などのサービス開発に活用されてきたアプローチです。顧客の理想的な体験から逆算してサービスを設計することで、顧客が本当に求める価値に焦点を当てた開発を可能にします。具体的には、企画段階から顧客体験をプレスリリースという形に詰め込むことで実現します。「Working Backwards」は知識として学ぶだけでは習得できません。実際にプレスリリースを書き、発表しフィードバックを受ける体験を通して、はじめて身につきます。 コーディングエージェントの進化が、「作る」のハードルを下げた 今年プロトタイプ開発まで踏み込んだ最大の理由が、AI コーディングエージェントの急速な進化です。 Kiro に代表されるコーディングエージェントは、自然言語の対話から要件定義・設計・実装・テストまでを支援できるまでに進化し、エンジニアでなくとも、アイデアを短時間で「動くもの」に落とし込めるようになりました。 これにより、「顧客起点で何を作るべきかを考える力（Working Backwards）」と「それを素早く形にする力（AIコーディングエージェント Kiro）」が地続きになり、アイデアの価値を構想で終わらせず、その場で動かして検証できるようになりました。昨年はアイデア創出が中心でプロトタイプ開発は任意でしたが、こうした技術の進化を背景に、今年は「考える」から「作る」までをやり切る2日間へと踏み切りました。 イベント概要 項目 内容 開催日時 2026年6月11日（木）、12日（金） 会場 AWS 麻布台オフィス（麻布台ヒルズ 森JPタワー） 参加者数 47名 参加企業 金融関連企業 13社（12チーム） AWS GenAI Catapult! とは 「AWS GenAI Catapult!」は、顧客起点での生成 AI ユースケースを創出し、世に送り出すための発射台（カタパルト）としての位置づけで、その意図をイベント名の「Catapult」に込めています。生成 AI の学習・スキル習得に留まらず、ユーザーの課題や体験に焦点を当て、Amazon 流のイノベーション文化を理解し、「Working Backwards」手法による実践的なユースケース創出につなげることを目指しています。今年はさらに、創出したユースケースを Kiro でプロトタイピングし、動くアプリケーションとして発表するところまでを2日間で体験いただきました。企業横断の交流セッション「World Café」も実施し、参加者同士の学びの共有とネットワーキングの機会も提供しました。 イベント開催報告 参加企業・チーム 金融領域の事業会社・サービサーなど 13社にご参加いただき、12チームを編成して臨みました。各社が個性豊かなチーム名で参加しています。 チーム名 会社名 Masult 株式会社アイフィスジャパン 麴町 Squad 株式会社オリエントコーポレーション TQQQ 株式会社QUICK 東池袋 4+1 株式会社クレディセゾン やる KIRO 満々 株式会社ジェーシービー しんぷれこ シンプレクス株式会社 NEXT BAMBOO 株式会社セゾンテクノロジー えぇアイをつくる会 CHEER証券株式会社 TMN Sei-katsu-sha AI Lab 株式会社トランザクション・メディア・ネットワークス AIに任せ隊 株式会社Finatext / 株式会社ナウキャスト P:AI プレミアグループ株式会社 ほか、1社 AWS GenAI Catapult! 1日目 Amazon Culture of Innovation Session / Working Backwards Experience Workshop 1日目は、Amazon のイノベーションを支えるカルチャーとテクノロジーの紹介から始まりました。Amazon は「地球上で最もお客様を大切にする企業であること」を使命とし、徹底したお客様志向、あくなき挑戦、辛抱強さを基本理念としています。お客様から逆算して考える「Working Backwards」というメカニズム、「Every day is still Day One」という心構え、小さく権限委譲された「Two-pizza チーム」という組織構造、そして変化に対応できるアーキテクチャが、イノベーションを生み出す源泉であることが説明されました。失敗を恐れず Builder 精神を持った社員が、顧客中心主義に基づいて新しい顧客体験を創造している——その文化が共有されました。 Working Backwards 体験ワークショップでは、参加者は各社チームに分かれ、生成 AI を活用したユースケースの創出に取り組みました。「Customer Obsession（お客様へのこだわり）」「Think Big（広い視野で考える）」「Bias for Action（行動へのこだわり）」というリーダーシッププリンシプルに基づき、まず「お客様は誰か」を特定し、課題を明確化。続いて課題を解決するソリューションとその目玉機能を考案し、最終的にプレスリリース形式でアイデアをまとめます。完成したプレスリリースは他チームに発表し、建設的なフィードバックを受けることで、アイデアをさらに洗練させていきました。 参加者からは「要件定義ではなく“体験定義”をするという観点が非常に勉強になった」「プレスリリースから物事を考えること自体が新鮮だった」という声が多く聞かれました。 AWS GenAI Service Introduction / AWS Dojo Hands-on [ Kiro ] 続いて、AWS Session で AWS の生成 AI サービスの全体像を学び、続くAWS Dojo Session ではいよいよ AI コーディングエージェント Kiro のハンズオンに取り組みました。AWS のワークショップ「Kiroで学ぶ：AI駆動開発」を教材に、まず講師が Vibe モード（AI と会話しながら探索的に実装を進める使い方）をデモで実演。続いて参加者自身が Spec モード（仕様駆動開発）を実践し、要件を Kiro の Spec に落とし込み、そこから自動生成される設計ドキュメントを確認しました。Vibe（素早く作る）と Spec（要件→設計→タスクに構造化する）の両方をここで体験することで、翌日のプロトタイプ開発で両者を使い分けるための確かな助走となりました。 AWS GenAI Catapult! 2日目 Prototyping Workshop with Kiro 今年最大の挑戦が、AI コーディングエージェント Kiro を用いたプロトタイプ開発です。Working Backwards で描いた顧客体験を、構想で終わらせずに「動くもの」へと変えていきます。Kiro は、次の３つの機能をうまく活用頂くことで効率良く開発を進めていくことができます。 Spec（仕様）：自然言語の対話から、要件定義・設計ドキュメント・実装タスクを構造化 Steering（制約）：Steering ファイルで規約やアーキテクチャ制約を AI に教え、チームの意図に沿った実装へ誘導 Coding（実装）：タスクリストに沿って AI が実装。必要に応じて Vibe コーディングで素早く形にする 開発をスムーズに始められるよう、運営からは Working Backwards やアプリ雛形の生成などのスキルと、規約・アーキテクチャ制約を定義したステアリングを同梱した「スターターキット」を配布しました。各チームはまず Day1 で作った PR/FAQ を Spec に落とし込み、アプリの雛形を生成。生成 AI 部分はモックと実モデルを切り替えられる構成（Mock/Real 切替）にしておくことで、ネットワークやモデルに左右されずデモのシナリオを安定させる工夫も共有されました。実装は「頼む → 動かす → 確認する → 次へ」という小さなループ（黄金ループ）を回し、迷子にならずに少しずつ完成へ近づけていきます。 「雑な自然言語からでも仕様書やモックを作成してくれる」「開発未経験でもここまで作れるのかと驚いた」「要件定義からテストまで1〜2時間で実行できた」——短時間で完成度の高い成果物が生まれていく様子と、会場のあちこちで驚きの声を聞くことができました。 参加チーム プレスリリース発表 & デモ & QA 2日目午後、いよいよ発表の時。今年は プレスリリースに加えて、Kiro で作り上げた動くプロトタイプのデモ を披露するスタイルです。12チームを4チーム×3ブロックに分けて予選を行い、各ブロックの1位が決勝に進出するトーナメント形式で実施しました。各チームが顧客課題に深く向き合い、生成 AI ならではの新しい顧客体験を提案。単なる業務効率化に留まらず、顧客体験を根本から再定義するような大胆な提案が並び、Q&A では他チームの提案を積極的に理解しようとする姿が印象的で、会場は熱気に包まれました。 AWS World Café [AI 活用推進] 生成 AI 活用をテーマにした参加者交流セッション「World Café」を開催しました。少人数グループで「ホスト」と「旅人」の役割を交代しながらメンバーの組み合わせを変え、対話を深めていく独自の形式です。結論や合意形成を目的とせず、多様な意見の共有と相互理解の深化を重視。「同じ課題に直面していることがわかって安心した」「他業種の取り組みが参考になった」など、業界や立場を超えた対話から多くの共感と気づきが生まれました。 Networking Party & Awards Ceremony *表彰式 セッション終了後、会場は和やかなネットワーキングパーティーへ。参加者は2日間の学びを共有し合い、企業の垣根を越えた新たな繋がりが次々と生まれました。表彰式では、AI審査員を加えた5名による厳正な審査の結果、以下の3チームがAWS Awardsを受賞しました。 優勝：TMN Sei-katsu-sha AI Lab ( 株式会社トランザクション・メディア・ネットワークス ) 準優勝：P:AI （ プレミアグループ株式会社） 3位：TQQQ （ 株式会社QUICK ） さらに、プレスリリースの完成度を称える特別賞「Kiro賞」を、しんぷれこ（シンプレクス株式会社）／AIに任せ隊（株式会社Finatext・株式会社ナウキャスト）／やる KIRO 満々（株式会社ジェーシービー） の3チームが受賞しました。受賞チームには記念トロフィー・メダルと AWS クレジットが贈られ、参加者全員にも AWS オリジナルグッズが配布されました。会場は受賞チームへの祝福と拍手に包まれ、和やかな雰囲気の中で締めくくられました。 参加者の声 本イベントの参加者アンケート（回答47件）では、総合満足度（CSAT） 4.8 / 5.0 と昨年（CSAT 4.6）を上回る非常に高い評価をいただきました。また、Working Backwards × 生成 AI によるサービス創出プロセスの有用性も 4.76 / 5.0、今後も Kiro を業務で使いたい と回答した方は約94%にのぼりました。参加者からは、次のような声が寄せられました。 「要件定義ではなく“体験定義”をするという観点が非常に勉強になった」 「雑な自然言語からでも仕様書やモックを作ってくれるのがすごくよい」 「開発をしたことがない人間でも、ここまで作れるのかと興奮した」 「他社の AI 活用のリアルな実情やアイデアを聞ける、貴重な交流の場だった」 「‘それは私たちの仕事ではありません、と言わない’を自分の信条にしたい」 運営の工夫 — イベント運営そのものも生成 AI と 今年は、イベントの「中身」だけでなく「運営」にも AI コーディングエージェントを活用しました。参加者に Kiro での開発を勧める私たち運営自身が、その Kiro を使って運営の仕組みを作り上げる——これもまた、今年のイベント開催における裏テーマでした。 イベントポータルサイトの開発 当日の参加者体験を一元化するため、専用の イベントポータルサイト を内製しました。参加者はこのポータルから、当日のアジェンダ・各セッションのガイド、開発チートシート、FAQ／トラブルシューティングを確認でき、完成した成果物（PR/FAQ・発表スライド・プロトタイプ・デモ動画）をカテゴリ別にアップロードできます。 技術構成はフロントエンドに React + Vite + TypeScript、バックエンドに AWS Amplify Gen2（認証は Amazon Cognito、ストレージは Amazon S3、ホスティングは Amplify Hosting）を採用。チーム単位のアカウントを運営が事前発行し、各チームの成果物は S3 上で IAM により相互に隔離（他チームからは参照不可、運営のみ横断アクセス可）しました。参加者が金融機関であることを踏まえ、全ページ認証必須・S3 のパブリックアクセス全ブロックと暗号化・成果物の一定期間後の自動失効といった、セキュリティとデータ保護の作り込みも行っています。 アプリ開発用スターターキットの準備と配布 コーディングエージェントを初めて使う参加者でも、半日で動くアプリを作り切れるように、運営が事前に「スターターキット」を配布しました。0 から作るのではなく、これを起点に開発できるようにする狙いです。 キットには、Working Backwards の PR/FAQ・ストーリーボードの生成、発表資料づくり、コーディングエージェントの「運転ガイド」、Spec / Vibe の使い分け、生成 AI アプリの雛形生成、HTML スライド作成といった用途別の スキル群 と、毎回守ってほしい制約を定義した ステアリング（共通ガードレール）、そして開発中に手元で見る 1 ページの早見表やトラブルシュートを同梱しました。これにより、初心者がつまずきやすい「曖昧に大きく頼んで迷子になる」「動作確認せずに進む」「生成 AI 連携部分を自力で組めない」「Spec を巨大にして破綻する」といった落とし穴を、あらかじめ吸収できるよう設計しています。 Kiro と AI 駆動型開発 特筆すべきは、ポータルサイトもスターターキットも、コーディングエージェント Kiro を使って開発したことです。とりわけポータルサイトは、Kiro の Spec モード（仕様駆動開発） を用い、要件定義（requirements）→ 設計（design）→ タスク分解（tasks）という流れで開発しました。これはまさに、当日参加者に体験いただいた開発プロセスそのものです。 「考える」から「作る」までを生成 AI で地続きにする——その手応えを、運営は準備段階から自ら検証していました。参加者に届けた体験は、私たち自身が有効性を確かめたうえでお渡ししたもの、と言えます。 まとめ 「AWS GenAI Catapult! 」は、単なる技術セミナーではなく、顧客起点でのイノベーション創出プロセスを学び、実践する場です。今年は Working Backwards による「考える」体験に、Kiro による「作る」体験を加え、アイデアを2日間で動くプロトタイプにまで昇華させる挑戦を行いました。生成 AI という革新的技術を真に価値あるものにするためには、技術の可能性を理解しつつ、常に顧客価値を中心に据えたアプローチが不可欠です。そして今、その顧客価値を「素早く形にして検証する」ことが、誰の手にも届く時代になりました。参加者の皆様がこの本質を体感し、自社での実践に活かしていただけることを心から願っています。 最後に、2日間にわたり熱心にご参加いただいた皆様、そして革新的なアイデアとプロトタイプを生み出してくださった各チームの皆様に、心より感謝申し上げます。皆様の挑戦が、日本の生成 AI 活用を加速し、新たな顧客価値の創造へとつながることを確信しています。AWS では今後もお客様のイノベーション創出を支援するプログラムを継続的に提供してまいります。

AWS Builder Center は 2026年 7 月 6 日週、提供開始から 1 周年を迎えました。2025 年 7 月 9 日にリリースされたこのプラットフォームは、ウィッシュリストの投票、コミュニティプロファイル、ツールボックスを備えたコミュニティハブから、サンドボックス環境、ワークショップ、スペース、Builders’ Library を備えた完全なエコシステムへと発展を遂げました。この度、1 周年を記念して、Rick Suttles が過去 1 年間にリリースされた全機能を網羅した 機能タイムライン を公開しました。内容としては、リージョン別の AWS 機能 (37 のリージョンにおける 1,500 以上のサービスに対応)、スペース (コミュニティの目的に応じて作成できるグループ)、ワークショップのフィルター機能 (カテゴリーや難易度で検索可能)、バッジとストリーク、記事シリーズ、視聴回数、保存済みアイテム、学生ステータス、可用性通知、GitHub と Amazon へのサインイン、サンドボックス環境などが挙げられます。 Jeff Barr は、Builder Center の 1 年を総括する レトロスペクティブ を公開しました。リリース以降、5,548 人の著者が計 6,448 本の記事を公開しており、合計ページビュー数は 1,040 万回を超えています。2026 年 3 月にバッジシステムが導入されて以降、ビルダーが獲得したバッジの総数は 99,226 個に達しています。また、コミュニティメンバーからは 565 件のウィッシュが提出され、そのうち 10 件はすでに実装されており、さらに 20 件が直近のロードマップに組み込まれています。 コミュニティのトップ記事である「 Building an AWS Study Buddy with MCP + Strands Agents SDK 」(Dineshraj Dhanapathy 著) は、5 万回以上閲覧されています。これに続き、「 Migrating an EOL Linux Server to AWS in 8 Hours with Kiro 」(Chris Miller 著) は 4 万 5,000 回以上、さらに「 AIdeas: NeuroVoice – Multimodal AI for Early Screening of Neurological Diseases 」(Yash Aggarwal 著) は 3 万 8,000 回以上閲覧されています。 7 月 13 日週の目玉となる追加機能は、 サンドボックス環境 (Rick Suttles 著) です。サンドボックスでは、事前にプロビジョニングされた AWS アカウントを無料で利用して、ワークショップの演習を実施することができます。サンドボックス環境の有効期間はそれぞれ 8 時間であり、その後アカウントとそのすべてのリソースが自動的にプロビジョニング解除されます。アクティブにできるサンドボックスは一度に 1 つまでで、リクエストできるのは週に 1 回までです。個人の AWS アカウントやクレジットカード、手動によるクリーンアップは不要です。 2026年 7 月 6 日週のリリース その他、7 月 13 日週に発表された事項をご紹介します。 AWS Security Hub でのネットワークスキャン導入 – Security Hub にネットワークスキャンが導入されました。これは、パブリックインターネットからアクセス可能な環境内のリソースを特定する機能です。ネットワークスキャンは、インターネットからリソースを調査して実際の到達可能性を検出することで、リソースがアクセス可能になり得る設定を特定する、Security Hub における従来のネットワーク到達可能性の検出結果を補完するものです。この機能では、AWS および Azure 環境全体におけるパブリック IP アドレス、仮想マシン、ロードバランサーが検出され、アクセス可能なポートと、その背後で実行されているサービスが特定されます。アクセス可能なポートが見つかるたびに、検出されたポートとサービスの証拠を含む Security Hub の検出結果が生成されます。その後、Security Hub Exposure (露出) でこれらの検出結果が他の検出結果やリソース設定と自動的に関連付けられ、広範なリスクが特定されます。既存のお客様は、個々のアカウントやリージョン、または組織全体 (設定ポリシー経由) でネットワークスキャンを有効にできます。新規のお客様の場合、ネットワークスキャンはデフォルトで有効になっています。この機能は Security Hub Essentials に含まれており、追加料金なしでご利用いただけます。 Security Hub の統合セキュリティ管理が Microsoft Azure にも拡張 – Security Hub で Microsoft Azure のリソースをモニタリングできるようになり、両方のクラウドで一貫したポスチャ管理、脆弱性管理、セキュリティ対応が提供されるようになりました。これにより、Azure VM、コンテナイメージ、Function Apps、アイデンティティが自動的に検出され、設定ミスやインターネットへのエクスポージャー、ソフトウェアの脆弱性の有無が評価されます。AWS と Azure の検出結果は、同一の優先順位付けされたビューに、共通のフォーマットと自動化ワークフローで表示されます。 Amazon SageMaker Studio と Hugging Face の統合により、ワンクリックでのモデルデプロイとカスタマイズが可能に – Hugging Face でのモデル発見から SageMaker Studio でのモデル活用までをワンクリックで行えるようになりました。Hugging Face でサポート対象の任意のモデルを選択し、[Customize on SageMaker AI] (SageMaker AI でカスタマイズ) または [Deploy on SageMaker AI] (SageMaker AI にデプロイ) を選択すると、そのモデルがプリロードされた状態で、対応するワークフローページに直接アクセスできます。新規のお客様については、サーバーレスモデルカスタマイズ (強化学習用のカスタム報酬関数によるファインチューニングなど)、モデル評価、SageMaker や Bedrock エンドポイントへのデプロイ向けの権限が事前設定された Studio 環境が数秒で作成されます。検証済みのお客様は、クォータの引き上げをリクエストすることなく、デフォルトの GPU インスタンス (G5、G6、G4dn) を利用できます。また、クォータの利用状況は Studio 環境内で直接確認することができます。 Amazon EKS Auto Mode と Amazon ECS マネージドインスタンスの GPU 管理料金が最大 60% 引き下げ – 2026 年 7 月 1 日より、EKS Auto Mode および ECS マネージドインスタンスにおいて、アクセラレーテッドインスタンスタイプの管理料金が引き下げられます。G シリーズの料金は 35%、P シリーズおよび AWS Trainium の料金は 60% の引き下げとなります。値下げは既存のクラスターに自動的に適用されるため、お客様による対応は一切必要ありません。どちらのサービスにも、ワークロードを高速化するための機能が組み込まれています。EKS Auto Mode は、ローカル NVMe ストレージを備えた GPU インスタンス上での自動並列イメージプルや、アクセラレータ対応ノード修復を提供します。ECS マネージドインスタンスは、Amazon CloudWatch Container Insights を通じた GPU メトリクスの提供や、GPU ハードウェア障害の自動ヘルスモニタリングを備えています。 Amazon Aurora DSQL 変更データキャプチャ (CDC) の一般提供を開始 – Aurora DSQL CDC は、挿入、更新、削除操作の結果を変更イベントとして Amazon Kinesis Data Streams にストリーミングする機能です。これにより、マイクロサービス間でのデータ同期、Lambda 関数のトリガーのほか、Amazon Data Firehose を介した S3、Redshift、OpenSearch Service への変更データの転送が可能になります。CDC ストリーミングは、データベースのワークロードパフォーマンスに影響を与えないように設計されており、インフラストラクチャを管理する必要も一切ありません。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 AWS のその他のニュース お客様に役立つ可能性のある記事をさらにいくつかご紹介します。 「 Building secure AI agents at scale: Introducing Loom for AWS 」– Loom は、AWS Strands Agents を使用してエージェントを構築し、Amazon Bedrock AgentCore Runtime 上にデプロイするための、オープンソースのエンタープライズプラットフォームです。ID プロバイダーの統合、スコープベースの認可、マルチペルソナのナビゲーション、そしてエージェント、メモリ、MCP サーバー、エージェント間連携の完全なライフサイクル管理を備えた、統合管理 UI およびバックエンド API を提供します。さらに Loom は、自動リソースタグ付けによるコスト配分、マルチテナントセキュリティのための RBAC および ABAC の実装、標準化されたブループリントに基づくエージェントデプロイ、委任アクターチェーンによる ID 伝播の管理、AWS Agent Registry との統合による検出とガバナンスを実現するほか、機密性の高いアクションを実行する前の人間参加型レビューをサポートします。プロジェクトは GitHub の AWS ラボで公開されています。 「 Introducing Claude apps gateway for AWS 」– Claude アプリゲートウェイは、組織が Claude Code や Claude Desktop のアクセス、コスト、ポリシーを一元管理できるようにするセルフホスト型のコントロールプレーンです。このゲートウェイは、任意の OIDC 準拠の ID プロバイダーに接続し、すべてのリクエストに対してマネージド設定を適用します。また、推論を Amazon Bedrock または Claude Platform on AWS にルーティングするほか、ユーザーやグループごとに、利用料金の上限を設定できます。ゲートウェイは、プライベートネットワーク内でステートレスコンテナとして動作し、PostgreSQL データベースを基盤として一時的なサインイン状態を実現します。開発者のマシンに存続期間の長いシークレットが保存されることはありません。Amazon Bedrock を通じてデプロイすることでデータを AWS のセキュリティ境界内に保持することも、Claude Platform on AWS を通じてネイティブな Claude プラットフォームエクスペリエンスを得ることも可能です。 「 Introducing OAuth support for AWS MCP Server 」– AWS コンソールや CLI で使用するのと同じ認証情報を使用して、ブラウザベースの OAuth 経由でエージェントを AWS MCP サーバーに接続できるようになりました。この新しいサインインパスは、IAM フェデレーション、AWS IAM アイデンティティセンターのほか、ルートユーザーや IAM ユーザーをサポートしています。AWS サインインでは、有効期間の短いアクセストークンと更新トークンが発行され、トークン管理が自動的に行われるため、開発者は再起動後も認証状態を維持することができます。ヘッドレスのユースケースでは、非インタラクティブなフローにより、既存の AWS 認証情報を持つアプリケーションであれば create-oauth2-token-with-iam API を通じて OAuth アクセストークンを取得できます。新たなガバナンスコントロールには、OAuth 固有の IAM 条件キー、トークンのイントロスペクションと取り消し、動的クライアント登録、CloudTrail の監査要素が含まれます。 AWS のブログ記事一覧については、 AWS ブログ ページをご確認ください。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit – ビルダーやイノベーターが学び、発想を広げ、新たなつながりを築くための無料の対面イベント。開催予定: 台北 (7 月 15 日)、 ボゴタ (7 月 30 日)、 ジャカルタ (8 月 6 日)、 シウダー・デ・メヒコ (8 月 12 日)、 ヨハネスブルグ (8 月 19 日)、 チューリッヒ (9月2日)。 AWS Community Days – コミュニティリーダーが企画および提供するコミュニティ主導のカンファレンス。イベント開催予定: カメルーン、ヤウンデ (7 月 25 日)、 インド、アフマダーバード (7 月 25 日)、 ブラジル、ベロオリゾンテ (8 月 22 日)、 カナダ、オタワ (8 月 22 日)、 米国、タルサ (8 月 22 日)、 カナダ、トロント (8 月 29 日)。 AWS Builder Center にアクセスして、他のビルダーと交流したり、ソリューションを提供したり、構築を継続するのに役立つリソースを見つけたりしましょう。 充実した素敵な夏休みをお過ごしください。開発、学習、そしてリフレッシュ。皆様がそのすべてを満喫できるよう願っています。ちなみに私は、数週間スカンジナビアで過ごし、暑さを逃れて涼しい気候と白夜を楽しむつもりです。7 月 20 日週もまた新しいニュースをお届けしますので、お楽しみに。 – Esra 原文は こちら です。

はじめに 2026年6月25日（木）・26日（金）の2日間、千葉・幕張メッセにて AWS Summit Japan 2026 が開催されました。 AWS Expo エリア内の AWS Industries Zone では、流通小売・消費財・飲食業界向けブースとして「AI エージェントが業務の主役になる日」をテーマに6つのデモと2社のお客様事例を展示しました（ 事前告知ブログ ）。本ブログでは、そのうちサプライチェーン領域の展示「AI エージェントで危機対応 — 小売×消費財の混乱を AI と人が即座に解決」にフォーカスし、デモの技術的な仕組み、来場いただいたお客様の反応、そして「今日から始められる」次のステップをご紹介します。 デモで展示した内容 デモのコンセプト 台風による広域配送停止、ドライバー不足、SNS でのバイラル化による需要急増、そして石油由来製品の調達難。サプライチェーンの現場では、いつ「想定外」が起きてもおかしくありません。商品そのものだけでなく包装資材やプラスチック容器など、石油由来の原材料に依存する消費財メーカーにとって、調達コストの急変動は今まさにリアルな脅威です。従来、こうした外乱への対応は担当者の経験に依存し、検知から実行まで数時間〜数日を要していました。 本デモでは、「AI エージェントが外乱を検知し、影響を分析し、代替案を探索・提示し、人間が承認したうえで実行と通知までを一気通貫で行う」この一連のオペレーションを、ライブで実演しました。お客様の業種に合わせて、小売シナリオ（店舗の在庫不足に対する最適な振替ルートの提案）と消費財シナリオ（原材料供給停止時の代替サプライヤー探索）の2パターンをご覧いただきました。 図1: デモ画面。上部: AI エージェントの提案に対し、人間が承認・拒否を実施した結果、判断によって守ることができた売り上げ高と回避された遅延違約金を表示。下部: AI が作成した先方へのメールや発注書のドラフトなどを表示 システム構成 図2: サプライチェーン危機対応デモのシステム構成図 本デモのアーキテクチャは以下の要素で構成されています。 レイヤー サービス / コンポーネント 役割 フロントエンド Amazon S3 + Amazon CloudFront + AWS WAF + Amazon Cognito ユーザー認証とWebアプリ配信 リアルタイム通信 AWS AppSync Events AI の思考プロセス (Chain of Thought) やツールの呼び出しをリアルタイムにストリーミング可視化 エージェント基盤 Amazon Bedrock AgentCore Runtime + Strands Agents SDK マルチエージェントのオーケストレーションと実行 データアクセス MCP サーバー（各シナリオごとに6つ、計12種類のツール） 遅延出荷取得、在庫インパクト計算、財務インパクト計算、転送オーダー作成など データストア Amazon Aurora DSQL サプライチェーンデータの格納（在庫、出荷、サプライヤー、BOM等） 安全性 Amazon Bedrock Guardrails エージェントの出力に対するガードレール適用 セッション管理 Amazon S3 Human-in-the-Loop の承認状態を保持 全体の流れはシンプルです。ユーザーはフロントエンドから指示を出し、その指示をエージェント基盤上のマルチエージェントが受け取ります。各エージェントは MCP サーバーを介して Amazon Aurora DSQL 上のサプライチェーンデータ（在庫・出荷・サプライヤー・BOM など）にアクセスし、分析や提案を行います。そして、エージェントの出力には Amazon Bedrock Guardrails を適用し、安全性を最優先に担保しています。 このアーキテクチャで特に工夫したポイントが2つあります。 工夫ポイント① 人間による承認の必須化（Human-in-the-Loop） 本デモでは、AI エージェントがどれだけ優れた分析や提案を行っても、人間の明示的な承認なしには転送オーダーやワークオーダーの発行といった実行系のアクションを一切実行できない設計としています。これは「AI が勝手に発注してしまう」「意図しない振替が走る」といった現場の懸念に正面から応えるものです。 技術的には、Strands Agents SDK の Interrupt 機能を活用しています。Supervisor Agent が実行サブエージェントを呼び出す直前で Hook がセッションを一時停止（Interrupt）し、フロントエンドに承認リクエストを送信します。ユーザーが承認すればセッションを再開して実行サブエージェントを呼び出し、却下すればその呼び出しはスキップされ、対象の発注や振替アクションは実行されません。会話コンテキストは Amazon S3 上のセッションマネージャーに永続化されるため、中断・再開が可能です。なお、Supervisor Agent のプロンプトには「実行エージェントを必ず呼び出し、”pending approval” と書いてスキップすることは禁止」と明記し、AI がこの承認フローをバイパスしないよう制御しています。 工夫ポイント② 思考プロセスの可視化（Chain of Thought） AWS AppSync Events による WebSocket 通信では、今どのステップを実行中か、何を分析しているかといった AI エージェントの思考プロセスをリアルタイムにフロントエンドへストリーミングし、可視化しています。デモではこの思考プロセスのログをリアルタイムに表示することで、承認を求められた際に「なぜこの提案に至ったか」の根拠が見える状態を作り、来場者の皆さまにも納得感を持ってデモの流れを追っていただくことができました。 マルチエージェント設計 本デモでは、1つの Supervisor Agent（サプライチェーン管理エージェント）が全体のオーケストレーションを担い、4つのサブエージェントに作業を委譲する構成を採っています。 Retail シナリオ: 在庫移動分析サブエージェント — 振替元候補の探索と実現可能性の評価（分析のみ） 転送オーダー実行サブエージェント — 承認された振替の実行（実行のみ） CPG シナリオ: 代替サプライヤー探索サブエージェント — リードタイムが最短の代替を優先的に探索（分析のみ） ワークオーダー実行サブエージェント — 承認された発注の実行（実行のみ） 「分析」と「実行」を明確に分離している点がポイントです。分析エージェントは実行すべきアクション（推奨案）を生成するだけで、実際のオーダー作成は行いません。実行エージェントは、分析エージェントが提案したアクションを忠実に実行します。この分離により、Human-in-the-Loop の承認ステップを自然に挟み込むことができます。 プロンプト設計 本デモで最も多くご質問いただいたのが「AI にどうやって業界固有の制約を守らせているのか」という点です。答えは、判断ロジックをコードではなくプロンプトとデータで定義していることにあります。 ワークフローの明示的な定義 Supervisor Agent のプロンプトには、7つのステップが明確に定義されています: ステップ1: 遅延出荷の取得 ステップ2: 在庫インパクト計算 & プロモーションデータ取得（並列実行） ステップ3: 在庫移動オプション評価（並列実行） ステップ4: 財務インパクト計算（並列実行） ステップ5: 転送オーダー実行（並列実行） ステップ6: 通知生成（メール + チャット） ステップ7: サマリー 各ステップで呼び出すツール、入出力のフォーマット、並列実行のルールが具体的に記述されています。 並列実行の指示 パフォーマンスを最大化するため、独立したツール呼び出しを同一ターンで並列実行するよう明示的に指示しています: ## CRITICAL PERFORMANCE RULE — PARALLEL TOOL CALLS You MUST call independent tools in the SAME response turn so they execute concurrently. - Steps 2 and 3 are independent — call retail_calculate_inventory_impact AND get_promotion_data for ALL shipments in ONE turn. これは「互いに依存しないツールは、同じ応答ターン内でまとめて呼び出して並列実行せよ」という指示です。例に挙がっている在庫インパクト計算（retail_calculate_inventory_impact）とプロモーションデータ取得（get_promotion_data）のように、独立した処理を1度のターンで同時に走らせることで、逐次実行に比べて待ち時間を短縮しています。 業界固有制約のプロンプト化 小売・消費財業界でよくある制約条件を、プロンプト内のルールとして記述しています: コールドチェーン対応 — 温度区分（常温/冷蔵/冷凍）に合わない輸送候補を除外 賞味期限管理 — 賞味期限に対し、リードタイムが短すぎる候補を除外 コスト閾値警告 — 代替サプライヤーのコストが20%以上高い場合に警告フラグを付与 使用期限チェック — 在庫の使用期限が30日以内の場合は新規調達を優先 これらはすべてプロンプト上のルール記述とデータベースのカラムの組み合わせで実現しており、ハードコーディングは行っていません。つまり、開発者でなくても業務担当者が自然言語のプロンプトを通してルールを記述し、改善していくことが可能です。 デモを通してお客様にお伝えしたこと 既存システムへの外付けアプローチ AI を業務に取り入れるには、既存システムの大がかりな刷新が必要だと思われがちです。しかし本デモでお見せしたのは、既存の資産を活かすアプローチでした。既存のデータ（在庫・出荷・サプライヤー情報）をそのまま活用し、MCP サーバー経由でエージェントに接続するだけで、AI がシミュレーションを実行できます。既存のシステムを置き換える必要はなく、AI による分析の仕組みを「外付け」できることがこのアーキテクチャの強みです。 段階的に上げられる自動化レベル 本デモでは「AI エージェントによる自動化レベル」を5段階で定義し、レベル 1〜3 を実演しました: レベル AI に任せること 概要 1 シミュレーション データ読み取り・分析のみ。BCP訓練に活用 2 アクションプラン作成 通知・発注書を自動生成。人間が確認して実行 3 承認付き自動実行 AI が提案→人間が承認→実行。財務インパクト事前表示 4 ルールベース自動実行 ポリシー（金額閾値等）で自動承認 5 学習型自動実行 過去の承認パターンを学習し自動判断 ただし、レベル 5 が必ずしもゴールではありません。業務特性やリスク許容度に応じて最適なレベルを柔軟に選べるのがこの設計の強みで、「まずは レベル 1 のシミュレーションから始める」というのが、私たちがこのブースでのデモを通してお伝えしたかったことです。レベル 1 は既存データを AI に与えて業務影響を分析するだけなので、実業務のプロセスを変更せずに今日からでも始められます。「もし明日、台風で広域配送が5日間停止したら？」といった問いを既存データに投げかけ、避難訓練のように繰り返すことで対応プロセスの練度を上げ、効果を実感してから次のレベルに進めば良いのです。 来場いただいたお客様の反応 2日間のブース展示を通じて、多くのお客様と対話させていただきました。展示員の振り返りからいくつかの共通テーマが浮かび上がりました。 BCP 訓練という普遍的な課題 「サプライチェーンの混乱を、AI と人が即座に解決する」がこのブースのメッセージですが、いざという時に即応するには日頃の備えが欠かせず、本デモではその備えをシミュレーションから小さく始められることをお見せしました。ブースを訪れたお客様のほぼ全員が、その備えとなる危機管理や BCP 訓練を「やりたいがリソースや手段がなくてできていない」とおっしゃっていました。大雪や台風など実際に困っている企業様からは「これまで担当者が各所に何本も電話をかけて対応していた。AI が初動を担ってくれるだけでもありがたい」という声をいただきました。危機対応は業種や規模を問わず共通の悩みであり、既存の業務を止めずに試せる手軽さへの共感とともに、AI エージェントへの期待の高さを肌で感じました。 AI エージェント活用の具体的なイメージ 「AI エージェント」という言葉は浸透しつつある一方、具体的に何ができるのか、自社ではどう使えるのかをイメージできていないお客様が多くいらっしゃいました。エージェントの思考プロセスを可視化し、Human-in-the-Loop で人間が介在するポイントを示したことで、「具体的なイメージが湧いた」「エージェントの処理を見て初めて理解できた」というフィードバックを多くいただきました。 データ整備の課題への気づき 興味深いことに、本デモをきっかけに「自社には AI に渡せる整理されたデータがない」と気づかれるお客様が少なくありませんでした。データが正規化されていない、必要な情報が構造化されたDBに入っていない、といった課題です。しかし実際には、フォーマットの異なる Excel ファイルが散在しているような状態でも、AI は人間が思う以上にデータを理解・整理し、人が気づきにくいインサイトまで引き出してくれます。完璧なデータ基盤が整うのを待つ必要はなく、まずは今あるデータから始めて AI と壁打ちしながら、ワークロードの成長と並行して育てていけばよい。この考え方に共感いただけたケースも多くありました。 AgentCore のモジュラー性への評価 Amazon Bedrock AgentCore 自体をまだ触ったことがないお客様が大半でしたが、機能がモジュラーな部品として提供されている点に好意的な反応をいただきました。たとえば、さまざまな認証・認可を統合管理してくれる Amazon Bedrock AgentCore Identity や、エージェントに短期・長期の記憶を持たせる Amazon Bedrock AgentCore Memory といった部品です。特に、既存の REST API や Lambda 関数をマネージドで MCP 化してくれる Amazon Bedrock AgentCore Gateway には「すばらしい」という声が上がりました。すぐに使いたい、アセットはあるか、という質問も複数いただき、そうしたお客様には後述のハンズオンワークショップをご案内しました。 導入コストへの反応 「一回のシミュレーションでどのくらいコストがかかるのか」という質問に対しては、本デモの構成では1回あたり数百円程度でシミュレーションを実行できることをお伝えすると、想像より安いと好意的に受け止められました。 Amazon Bedrock や Amazon Bedrock AgentCore の従量課金モデルなら固定費用や初期投資なしで始められる点も、大きな安心材料になるとの反応をいただきました。「使っていない間も費用が発生するのではないか」という懸念に対しても、サーバーレスで使った分だけの課金となり、待機コストを気にせず導入できる点をご評価いただきました。コストのハードルが低いことは、まず小さく試して効果を確かめたいというニーズにも合致します。 リアルタイムなデータ連携の重要性 有事の際には代替先に各社から注文が集中するため、AI が判断に使う情報にリアルタイムでアクセスできることが重要だという、現場ならではの指摘もいただきました。だからこそ、AI が MCP サーバー経由でリアルタイムにデータを取得し、瞬時に選択肢を提示できることに価値があります。人間だけで動くよりも早く初動を打てることこそが、AI エージェントを危機対応に活用する最大のメリットです。 — これらのご意見を通じて改めて感じたのは、サプライチェーンの領域は個社ごとに商流・物流の構造や制約が異なり、画一的なソリューションでは対応しきれない複雑さがあるということです。自社の業務に合ったエージェントの在り方を見極めるには、実際に手を動かして仕組みを理解することが近道です。次のセクションでは、本デモと同じシナリオを題材にしたハンズオンワークショップをご紹介します。 おすすめのはじめ方 ハンズオンワークショップ 本デモとよく似たサプライチェーンのシナリオを題材に、Amazon Bedrock AgentCore を段階的に学べるハンズオンワークショップ「 Amazon Bedrock を使用した AI 駆動型サプライチェーン管理の構築 」を公開しています。Jupyter ノートブック形式で、約65分で実施できます。 ワークショップでは、Strands Agents SDK を使ったカスタムツールの作成から始まり、それらのツールを AgentCore Gateway にデプロイして複数エージェント間で共有する方法、MCP サーバーを介したデータベース接続、AgentCore Runtime への本番エージェントのデプロイ、そして React フロントエンドとの統合までを一通り体験できます。プロトタイプとして手元で動かしたエージェントを、システムの残りの部分を変更せずに本番グレードの基盤へ移行する流れを掴むことができます。 マネージドサービス Amazon Connect Decisions 「自社でエージェントを一から構築するのではなく、すぐに使えるサプライチェーン計画ソリューションが欲しい」というお客様には、 Amazon Connect Decisions をご紹介します。Amazon Connect Decisions は、次世代のサプライチェーン計画・インテリジェンスソリューションです。需要予測、供給計画、異常検知といった領域で AI チームメイト（AI エージェント）がチームの一員として稼働し、需要シグナルの統合からコンセンサス予測の生成、業務制約を考慮した供給計画の立案、オペレーションの継続的な監視と問題解決までを支援します。自社の業務手順やルールに適応し、担当者の判断から学習して継続的に改善していくため、導入初日から実用的な推奨を得られる点が特長です。 おわりに AWS Summit Japan 2026 の会場でお話しさせていただいた皆さま、ありがとうございました。2日間を通じて強く感じたのは、サプライチェーンの危機対応は「やりたいけれど手が付けられていない」普遍的なテーマであり、AI エージェントがその最初の一歩を後押しできるということです。ご来場いただけなかった皆さまも、本ブログでご紹介したワークショップや資料をぜひお試しください。ご質問やワークショップ、本デモに関するご相談がありましたら、ぜひ AWS の担当者までお気軽にご相談ください。皆さまの現場で AI エージェントが動き始めることを楽しみにしています。 参考リンク AWS Summit Japan 2026 事前告知ブログ — 流通小売・消費財・飲食業界向けブースのご案内 ハンズオンワークショップ — Amazon Bedrock を使用した AI 駆動型サプライチェーン管理の構築 Amazon Bedrock AgentCore Amazon Connect Decisions 著者 吉田 英史 は、東海地方を中心に小売・消費財業界のお客様を支援しているアマゾンウェブサービスのソリューションアーキテクトです。身の回りの生活に欠かせない様々なビジネスをクラウドで加速するお手伝いができることを、何より嬉しく感じています。

「セキュリティは大丈夫だろうか」 「障害が起きたときに復旧できるだろうか」 「このアーキテクチャはベストプラクティスに沿っているだろうか」 AWS 上にシステムを構築・運用する中で、このような漠然とした不安を感じたことはないでしょうか。 例えばよくある Web 3 層構成 のアーキテクチャにおいて、アーキテクチャ図は一見問題ないように見えても、実運用に入ると以下のような問題が顕在化するケースが考えられます。 運用者全員で管理者権限の IAM ユーザーを使い回しており、意図しない操作/変更が行われる 操作・変更履歴を取得しておらず、障害時に原因追跡ができない アプリケーションのデプロイの失敗時、切り戻しを考慮しておらずサービス復旧に時間がかかる データベースの認証情報がハードコーディングされている 退職者の IAM アカウントが放置され、不正利用される サーバーやデータベースの性能不足によりサービス影響が発生する 図1 : Web 3 層構成をもとにしたリスク例 こうした潜在的リスクを体系的に炙り出し、改善していくためのフレームワークとして有用なのが AWS Well-Architected Framework です。 6 つの柱（運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率性、コスト最適化、サステナビリティ）に基づくベストプラクティスに沿ったレビューを実施することで、ワークロードの品質を継続的に向上できます。 AWS Well-Architected Frameworkの概要については「 AWS Well-Architected Framework 入門編【AWS Black Belt】 」をご参照ください。 しかし、Well-Architected Framework レビュー（WAFR） の実施には「フレームワークの内容を理解するのが難しい」「いつでも気軽に相談できるアドバイザーが欲しい」「時間がなくてレビューを実施できない」という悩みの声を耳にします。 そこで本記事では、AI を活用して WAFR を加速する 3 つのアプローチを紹介します。 2026 年 6 月に開催された AWS Summit Japan 2026 の Well-Architected ブースで展示した内容です。 ( 配布資料ダウンロードリンク ) 3 つの AI レビューアプローチ ニーズに応じた 3 つの方法をご紹介します。 図2 : 3 つの AI レビューアプローチ 1. Well-Architected Quick Advisor — チャットで気軽に Well-Architected について相談 Amazon Quick のチャットエージェント機能を活用して構築する Well-Architected の専門性を持ったアドバイザーです。 技術レベルを問わず誰でも AWS Well-Architected Framework に関する質問を気軽に行えます。 図3 : Amazon Quick チャットエージェントで WAFR を AI に手助けしてもらう例 チャットエージェントの作成方法 エージェント作成時のプロンプト例： AWS Well-Architected Framework について、なんでも相談できる AI エージェントを作ってほしいです。質問者のレベルに合わせて相談にのってあげてください。レビューの支援を求められたら支援してください。最新情報は AWS Knowledge MCP Server を利用してください。 AWS Knowledge MCP Server と連携することで、常に最新のベストプラクティス情報を参照できます。 また、ブラウザ拡張機能として利用すれば、AWS Well-Architected Framework ホワイトペーパーを読みながら不明点をその場で質問することも可能です。 図4 : Amazon Quick ブラウザ拡張でホワイトペーパーの理解を AI に手助けしてもらう例 2. Well-Architected Skills & Steering — コーディングエージェントに Well-Architected の能力を付与する Well-Architected Framework の知識をコーディングエージェント（IDE）に組み込むサンプルスキル・ステアリング集です。 開発フローの中で自然に WAFR を実施できます。 GitHub: https://github.com/aws-samples/sample-well-architected-skills-and-steering 対応コーディングエージェント （2026/7/15 ブログ執筆時点） Kiro Kiro Power (recommended for Kiro users) Claude Code Cursor Codex (OpenAI) Windsurf GitHub Copilot Gemini CLI Antigravity Junie (JetBrains) Amp OpenClaw Cline AWS DevOps Agent インストール 1 コマンドでインストールできます。使用中の AI ツールを自動判別します。 npx skills add aws-samples/sample-well-architected-skills-and-steering 出力例 例えば、 あるゲームアプリケーション に対してレビューを実施すると、以下のようなスコアカードや改善計画が出力されます。 図5 : 各柱のスコア 1-5とハイリスクレポートの出力例 3. Well-Architected IaC Analyzer — 生成 AI による自動レビュー 生成 AI を使用して Infrastructure as Code（IaC）ファイルや設計書を AWS Well-Architected Framework のベストプラクティスに照らして自動レビューする Web アプリケーションです。 GitHub: https://github.com/aws-samples/well-architected-iac-analyzer 図6 : Well-Architected IaC Analyzer 画面 使い方 Step 1: ドキュメントをアップロード 単一または複数の IaC ファイル IaC プロジェクト（zip） アーキテクチャ図（PNG/JPEG）や設計書（PDF） Step 2: レビュー対象の柱を選択 Step 3: レンズを選択（オプション） 例：Generative AI Lens、Financial Services Industry Lens など Step 4: レビューを開始 分析結果の活用 ① ベストプラクティス準拠状況の一覧 準拠していない観点とその理由が一覧表示されます。 各項目には優先度（Priority）・重大度（Severity）・複雑度（Complexity）の 3 段階スコアが付与され、判定理由も確認できます。 図7 : Well-Architected IaC Analyzer 分析結果の出力例 ② 優先順位付けマトリクス リスクの重大度（影響の大きさ）と実装の労力（複雑さ）の 2 軸で 4 象限に分類し、アクション優先順位を可視化します。 「クイックウィン」（高影響 × 低労力）に分類された項目から優先的に対応することで、効率的にセキュリティや信頼性を向上できます。 図8 : 優先順位付けマトリクス ③ アナライザーアシスタント 各ベストプラクティスの詳細画面から「アナライザーアシスタントに質問」ボタンをクリックすると、具体的な実装ステップや修正コード例まで確認できます。 図9 : アナライザーアシスタント Well-Architected IaC Analyzer アーキテクチャ 図10 : Well-Architected IaC Analyzer アーキテクチャ図 Amazon Cognito によるユーザー認証、Amazon ECS / AWS Fargate によるアプリケーション実行、Amazon Bedrock による生成 AI 分析、そして Amazon Bedrock Knowledge Bases を活用した RAG（Retrieval Augmented Generation）構成により、常に最新の Well-Architected ベストプラクティスに基づいたレビューを提供します。 まとめ Well-Architected Framework レビュー（WAFR）は、クラウドワークロードの品質を継続的に高めるための重要な活動です。 AI を活用することで、従来のレビューに対するハードルを大幅に下げ、より多くのチームが日常的にベストプラクティスに沿った開発・運用を実践できるようになります。 まずは気軽に Well-Architected Quick Advisor で相談するところから始め、開発チームには Well-Architected Skills & Steering を導入し、定期的なレビューには Well-Architected IaC Analyzer を活用する——といった形で、ご自身のチームに合ったツールから活用頂ければ幸いです。 AI と共に Well-Architected な開発・運用を目指しましょう。 参考資料 : AWS Well-Architected Framework AWS Well-Architected Framework 入門編【AWS Black Belt】 Well-Architected Skills & Steering for AI Coding Agents（GitHub） Well-Architected IaC Analyzer（GitHub）

本ブログは 2026 年 7 月 14 日現在の内容を元に記載しております。記載内容については今後変更される可能性があります。 こんにちは ! テクニカルインストラクターの室橋です。今年も半分が終わり、ついに 7 月ですね。皆様、AWS のご利用、学習の状況はいかがでしょうか ? さて、今回は AWS をシミュレーションベースで学習することができる AWS SimuLearn のアップデートについてご案内いたします。 AWS SimuLearn に学習プランができました ! AWS クラウドをシミュレーションベースで学習できるコンテンツである「 AWS SimuLearn 」はご利用いただいておりますでしょうか ? SimuLearn は「AI を利用した顧客シミュレーション」と「実際の AWS アカウントを使用したハンズオン」を通じて、ソフトスキルと技術スキルの両方を向上させることができる学習コンテンツです。SimuLearn を初めて聞いた方は、 こちらのブログ にて詳しくご案内しておりますので、是非ご確認ください。 さて、この度 SimuLearn に学習プランが追加されました。 学習プランとは、特定のロールや業界に合わせて複数のコースをまとめた学習パス です。体系的にスキルを身につけたい方にぴったりの学習方法になっています。SimuLearn 学習プランでは、以下の包括的なハンズオン学習に取り組むことができます。 顧客シミュレーション – 各コース内の仮想の顧客との対話を通じて、要件ヒアリングや顧客対応スキルを練習 (自由会話モードは英語のみ対応) ガイド付きハンズオンラボ – 実際の AWS アカウントを使用して、AWS ソリューションを構築 DIY 検証ステップ – 少ないヒントで指示された内容を設定、構築し、自分のスキルを検証する この一連の学習により、実践的なクラウドスキルを体系的に身につけることができます。 利用可能な学習プラン 2026 年 7 月現在、以下の学習プランが利用可能です。 「Cloud Practitioner」と「AI Practitioner」の 2 つの学習プランは無料でご利用いただけます。 それ以外の学習プランには AWS Skill Builder の有償サブスクリプションが必要です。サブスクリプションについての詳細は こちらのページ をご確認ください。 無料でご利用いただける学習プラン: AWS SimuLearn – Cloud Practitioner （無料） AWS SimuLearn – AI Practitioner （無料） サブスクリプションが必要な学習プラン: AWS SimuLearn – Solutions Architect AWS SimuLearn – Serverless Developer AWS SimuLearn – Generative AI Architect AWS SimuLearn – Machine Learning AWS SimuLearn – Security AWS SimuLearn – Networking AWS SimuLearn – Data Analytics Industry Quest で提供されていたコースも SimuLearn 形式で学習プランに ! さらに、英語版でのみ提供されていた業界特化型のゲームベース学習コンテンツ Industry Quest シリーズ のハンズオンも、SimuLeran 形式のハンズオンとして、学習プランで提供されています。この学習プランでは、特定の業界における AWS 活用シナリオを実践的に学ぶことができます。なお、こちらの学習プランにも有償サブスクリプションが必要となります。 AWS SimuLearn – Healthcare AWS SimuLearn – Manufacturing and Automotive AWS SimuLearn – Financial Services 学習プランを完了するとデジタルバッジが獲得できます 学習プラン内のすべてのコースを完了すると、 Credly 経由で検証可能なデジタルバッジ が自動発行されます。獲得したバッジは LinkedIn やその他のネットワークなどで共有することができ、ハンズオンを実際に完了させたクラウドスキルの証明としてご活用いただけます。 なお、既に学習プランに含まれるコースを一式完了されている方には、遡ってバッジが発行されます。 始め方 AWS Skill Builder にサインイン SimuLearn の学習プランを検索、または こちら から閲覧 学習プランに登録し、アサインメントを開始 すべてのアサインメントを完了すると、バッジが自動的に Credly 経由で発行されます まとめ SimuLearn に学習プランが登場し、ロールや業界に合わせた体系的な学習が可能になりました。業界特化の Industry Quest シリーズのコースも学習プランとして利用でき、それぞれの学習プランを完了すると Credly 経由でデジタルバッジが発行されます。顧客シミュレーション、ハンズオンラボ、DIY を含む包括的な学習の完了を証明するバッジを、ぜひ獲得してみてください。SimuLearn の学習プランが、皆様のクラウドスキル向上のお役に立てれば幸いです。 参考リンク AWS SimuLearn Badges Launch Blog (英語) AWS SimuLearn Badge Collection on Credly AWS Skill Builder SimuLearn ページ AWS SimuLearn 紹介ページ AWS SimuLearn Trailer (YouTube)

本ブログは ハイテクインター株式会社 様と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。ソリューションアーキテクト 伊勢田氷琴です。 地方都市の中心市街地活性化は、多くの自治体が直面する共通の課題です。従来、通行者数の調査は単発的に実施されることが多く、年間を通じた傾向把握や詳細な属性分析が困難でした。このブログでは、ハイテクインター様が開発した VIX（Video Information eXchange）クラウドと AI カメラを活用し、富山市が北陸地区で初めて常設 AI カメラによる通年人流計測を実現した事例をご紹介します。AWS のサービスを活用することで、コスト削減と性能向上を両立し、さらにオープンデータとして一般公開することで地域経済の発展に貢献しています。 地方都市が直面する中心市街地活性化の課題と背景 富山市では、富山市スマートシティ推進ビジョンに基づき富山市中心市街地活性化基本計画を策定し、中心市街地の活性化に取り組んでいます。しかし、新規出店等のマーケティングに活用できる詳細なデータが不足していました。従来の調査方法では、単発的な実施に留まり、年間を通じた平日休日別や時間帯別の通行者データ、さらには性別・年齢といった属性情報を継続的に取得することが困難でした。 この課題を解決するため、富山市は地元企業の株式会社 CHRONOX（以下クロノクス）に委託し、スマートシティの情報基盤となる都市 OS 上に AI カメラを活用した人流観測プラットフォームを構築、2023 年 4 月 1 日より運用を開始しました。クロノクスは富山駅周辺および総曲輪地区に 52 台の AI カメラを設置し、ハイテクインターの VIX クラウドと常設 AI カメラによる人流計測を北陸地区で初めて実現しています。 図1: 富山市に設置された AI カメラの様子 AWS サービスの採用理由：コスト削減と性能向上の両立 ハイテクインター様は、情報通信・映像機器の企画・開発から輸入・販売・サポート、さらにはシステムの構築・設置設定・保守管理まで一貫して手がける企業です。同社が開発した VIX クラウド（Video Information eXchange Cloud）は、クラウド上でカメラから取得した映像を AI 解析し、目的に合った情報に変換する情報交換プラットフォームです。 AWS サービスの採用にあたり、ハイテクインター様は以下の点を重視しました。 まず、コスト効率の高い処理基盤の構築です。映像ストリーム処理と AI 推論を別々のインスタンスで行っていた従来構成では、台数分のコストと運用負荷が課題でした。 Graviton プロセッサ 搭載の Amazon EC2 インスタンスであれば、Arm ネイティブの処理性能を活かして両方の処理を 1 台に集約でき、約 4 割のコスト削減が見込める点が採用の決め手となりました。 次に、顔属性認識の精度とコストです。人流データに性別・年齢などの属性を付加するにあたり、 Amazon Rekognition を採用しました。他社製品比で約 2 割のコスト優位があることに加え、表情の認識粒度が細かく、データの付加価値を高められる点を評価しています。 図2: VIX クラウドの概念図 ソリューションの概要：VIX クラウドによる人流データの可視化 VIX クラウドは、マルチベンダーカメラからの映像取得、各種 AI エンジンの搭載、静止画および動画配信機能を備えた統合プラットフォームです。主な機能として、以下を提供しています。 人流・交通流計測 AI 機能 では、カメラから送られてきた画像から車両識別（大型・小型・二輪車）、人流および人属性（年齢・性別）を計測し、グラフ化します。車種別認識率は昼夜問わず 97% 以上を実現しており、時間ごと、曜日ごとの集計が可能です。 危険地域侵入検知機能 では、工事現場などでの危険地域立ち入りを検知し、LINE への発報やパトランプとの連携が可能です。スマートフォンで危険領域を設定できる利便性も備えています。 その他、水位異常解析など、多様な用途に対応できる拡張性を持っています。 ソリューションの構成：AWS サービスを活用した効率的なアーキテクチャ 富山市の人流観測プラットフォームは、以下の AWS サービスを中心に構成されています。 IP カメラからの映像ストリームは、Amazon EC2 上で稼働する VIX クラウドに連携されます。ストリーム映像からのエリア検知には Amazon EC2 の Graviton プロセッサを活用し、性能向上とコスト削減を同時に達成しました。従来は i3 インスタンスで変換処理を行い g4dn インスタンスで AI 処理を実行していましたが、G5g インスタンス 1 台でストリーム処理と AI 処理の両方を処理できるように最適化した結果、約 4 割のコスト削減を実現しています。 顔属性認識には Amazon Rekognition を利用しています。他社製品と比較して約 2 割のコスト削減を達成しただけでなく、より豊かな表情認識が可能になりました。 図3: 富山市人流観測プラットフォームの AWS アーキテクチャ AI カメラは「人間」「車両」「顔」の検出が可能で、52 台のカメラが富山駅周辺および総曲輪地区に設置されています。 通年データ取得から始まる都市計画の最適化 富山市中心市街地活性化に向けて、年間を通じた平日休日別や時間帯別の通行者の人数・滞留時間・属性（性別・年齢）をデータ化することに成功しました。従来単発的に実施されていた調査データを通年で取得することにより、これまで以上に最適化された都市計画の立案に寄与しています。 特筆すべきは、このデータをオープンデータとして一般に公開している点です。 富山市の人流データダッシュボード では、誰でも人流データにアクセスできます。これにより、新規出店を検討する事業者がマーケティングに活用したり、研究機関がデータ分析に利用したりと、地域経済の発展を多角的に支援しています。 AWS のサービスを活用することで、約 4 割のインフラコスト削減と約 2 割の顔属性認識コスト削減を実現し、持続可能な運用基盤を構築できました。 今後の展開：スマートシティの更なる進化 ハイテクインター様と富山市は、今回構築した人流観測プラットフォームを基盤として、さらなるスマートシティの実現を目指しています。通年で蓄積されたデータを活用した詳細な分析や、他の都市 OS 機能との連携により、より高度な都市計画の立案が期待されています。 また、VIX クラウドの持つ拡張性を活かし、水位異常解析など、防災や環境保全の分野への応用も検討されています。オープンデータとして公開されている人流データは、民間企業や研究機関による新たなサービス開発や学術研究にも活用され、地域経済のエコシステム形成に貢献していくことが期待されます。 お客様の声 本プロジェクトにおける VIX クラウドの開発と AWS 基盤の設計を主導したハイテクインター株式会社 映像開発部 AI クラウド開発 Gr. 課長 高橋 亨氏は、今回の取り組みを振り返り次のようにコメントしています。 「富山市人流計測システムの開発においては、AWS を基盤とするクラウドネイティブなアーキテクチャを採用し、スケーラビリティとリアルタイム性を両立できる実行基盤を構築しました。特に、映像入力から推論、属性抽出、集計、可視化までを疎結合に設計することで、処理負荷の変動に対しても柔軟に追従できる構成とした点が、本システムの技術的な特徴です。AI 処理については、最新の Graviton プロセッサのインスタンスを活用することで、映像データに対する推論処理の高速化を図り、現場で求められるリアルタイム応答性を実現しました。また、Amazon Rekognition による顔属性取得機能を組み合わせることで、単純な通行人数の把握にとどまらず、属性情報を含めた多面的な人流分析を可能にしています。これにより、都市空間における人の流れを定量的かつ即時的に把握できるシステムとして、運用面・分析面の双方で高い有効性を持つ構成に仕上げることができました。開発側の観点では、本取り組みは、マネージドサービスと高性能な推論基盤を適切に組み合わせることで、開発効率と運用性を確保しながら、実用レベルの精度と応答性能を実現できた点に大きな意義がありました。加えて、機能拡張や処理対象の追加にも対応しやすい構成として設計しているため、今後の横展開や類似ユースケースへの適用可能性も高いと考えています。」 また、富山市 活力都市創造部 まちづくり推進課 管理振興係 副主幹・係長 五十嵐祐子氏は、AI カメラを活用した人流データの計測の導入効果について次のように述べています。 「富山市では、中心市街地のにぎわい創出に向けた取り組みを進める中で、これまで単発の調査では把握しきれなかった人流の実態を、継続的にデータとして把握する必要があると考えていました。本システムの導入により、年間を通じて通行者数や滞留状況、時間帯・曜日ごとの変化に加え、年代や性別といった属性情報も継続的に取得できるようになり、中心市街地の活性化施策や都市計画の検討に活用できる基盤が整いました。また、本データはオープンデータとして公開しており、市民や事業者、研究機関など多様な主体が自由に利用できる環境を整えています。実際に大学による人流分析の研究にも活用されるなど、データの新たな活用が広がり始めています。今後は、これまでに蓄積してきた人流データをさらに活用し、AI などの技術による高度な分析も取り入れながら、データに基づいたまちづくりを推進していきたいと考えています。」 まとめ ハイテクインター様が開発した VIX クラウドと AI カメラを活用し、富山市は北陸地区で初めて常設 AI カメラによる通年人流計測を実現しました。Amazon EC2 の Graviton プロセッサと Amazon Rekognition を活用することで、約 4 割のインフラコスト削減と約 2 割の顔属性認識コスト削減を達成し、持続可能な運用基盤を構築しています。 通年で取得された詳細な人流データは、都市計画の最適化に貢献するだけでなく、オープンデータとして一般公開されることで、地域経済の発展を多角的に支援しています。この取り組みは、地方都市におけるスマートシティ実現のモデルケースとして、今後の展開が期待されます。 AWS の生成 AI サービスや IoT サービスについて詳しく知りたい方は、 AWS のスマートシティソリューション をご覧ください。 ソリューションアーキテクト 伊勢田氷琴

みなさん、こんにちは。AWS ソリューションアーキテクトの池田です。 AI エージェントの活用に取り組む企業が増える中、「どこまで任せるか」「どう統制するか」というガバナンスの問いは多くの企業に共通する関心事になっています。本ブログでは、村田製作所様に寄稿いただき、その実践例をご紹介します。 AWS Summit Japan 2026 でも発表いただいた内容 であり、同様の検討を進めている方にとって参考になるはずです。 全社 3 万人規模の生成 AI 活用から、責任ある AI エージェント活用基盤へ 株式会社村田製作所は、スマートフォン、自動車、通信機器、医療機器など、電気で動くあらゆる製品に使われる電子部品を提供する総合電子部品メーカーです。AI サーバーの普及はデータセンター向け電子部品の需要を飛躍的に拡大しており、当社は小型化・大容量化・高性能化を追求した電子部品の供給を通じて AI インフラを支えながら、自社でも AI を活用して変革を加速しています。 その中核を担うのが、生成 AI CoE がユーザー部門と共創しながら内製開発している全社生成 AI プロダクト「Murata Coworker」です。資料作成、翻訳、調査、社内データを活用した RAG/Agent などを統合的に提供するプラットフォームで、現在では累計約 3 万人が利用し、1 人あたり月約 3 時間の工数削減に加え、コミュニケーション品質の向上、知識共有の促進といった効果が確認されています。 本記事では、この Murata Coworker を「個の能力拡張」から「責任ある AI エージェント活用基盤」へと進化させていく取り組みを紹介します。 生成 AI 活用を、個の能力拡張から企業変革へ 村田製作所が目指す DX は、単なるデジタルツールの導入ではありません。当社では、ムラタ内外の人・組織・業務をデジタルでつなぎ、プロセスを短く・早く・見えるようにすることで、顧客価値と競争力の向上を継続的にドライブすることを DX と定義しています。 特に重視しているのが「デジタルツインサイクル」という考え方です。村田製作所はものづくりの会社であり、現場の力と現場の改善こそが競争力の源泉です。一方で昨今の AI は情報・サイバーの領域で急速に進化しています。当社は、このサイバーとフィジカルの 2 つの領域を結び、最適化・予測を現場に適用し、現場の知見を再びサイバーに持ち帰って次の最適化に活かす――このサイクルをいかに速く回せるかを、AI 活用における最大のミッションと捉えています。 デジタルツインをはじめとする Murata Coworker の内製開発の舞台裏や将来展望については、 プロダクトマネージャーが語る、生成AIプロダクト「Murata Coworker」内製開発の舞台裏と将来展望（村田製作所 技術記事） もあわせてご覧ください。 この実現に向けて、生成 AI CoE は「独自データ × 生成 AI」によるビジネス価値創出をミッションに掲げ、戦略立案、技術開発、イネーブルメント、ガバナンス、プロダクト提供、基盤構築までを横断的に支援しています。攻め（AI 活用推進）と守り（統制）を同じ目線でバランスよく進めている点が、当社の特徴です。 知識創造プロセスを支援する Murata Coworker 村田製作所では、生成 AI を「個の能力拡張ツール」にとどめず、知識創造プロセスそのものを支援する仕組みとして位置づけています。経験者へのヒアリング、会話や議事録の要約、情報の探索・抽出・統合、関連性の発見、パーソナライズ学習など、知識の共同化・表出化・連結化・内面化の各プロセスに AI を組み込むことで、属人化、個別最適化、適応硬直化といった課題の緩和を目指しています。AI は人の業務を置き換えるものではなく、人が本質的な業務に集中できるよう知識創造プロセスを加速・高度化するものと捉えています。 Murata Coworker は、汎用的なチャット機能に加え、用途特化型の機能を継続的に拡充しています。なかでも社内で急速に普及しているのが資料作成支援機能です。リリース後、パワーポイント資料を一から作る人が激減したほど、実務への浸透が目覚ましい機能です。翻訳機能も単なる汎用翻訳にとどまらず、村田製作所の独自用語や社内略語をあらかじめ保持し、それに準拠した翻訳を実現することで、グローバル展開する当社の多言語コミュニケーションの品質向上に大きく貢献しています。このほか、ヘルプデスク支援など業務に即したアプリケーション群を提供しています。 AWS を活用した AI エージェント基盤への拡張 生成 AI の活用が進むにつれ、企業における価値の源泉は、汎用チャットの利用から、独自データと業務プロセスを組み合わせた AI エージェント活用へと移行しつつあります。村田製作所では、Murata Coworker を AI エージェント活用基盤へ拡張し、Amazon Bedrock AgentCore を中心に、社内外データを活用した調査、ナレッジ検索、業務プロセス支援、システム連携を担う基盤として発展させています。Murata Coworker は単なるチャットボットではなく、村田製作所の知識・データ・業務プロセスを活用するための統合インターフェースへと進化しています。 AI エージェント活用基盤のアーキテクチャー アーキテクチャ面では、AI エージェントの実行環境とツール利用の統制を中核に据え、独自データの参照、基盤モデルの活用、細やかな認証認可、ガードレール、監査・可観測性を組み合わせた構成を採用しています。基盤は AWS 上に構築し、Amazon Bedrock を通じて複数プロバイダーのモデルを用途・コスト・処理速度に応じて使い分けるマルチモデル構成としています。可観測性には Langfuse を活用し、全 LLM 呼び出しのトレース蓄積と可視化を実現しています。また、外部モデルや SaaS、社内データ基盤、Microsoft Entra ID を活用した認証基盤とも連携し、AI エージェントが業務で必要な情報やシステムに安全にアクセスできるよう設計しています。これにより、開発スピードを維持しながら、全社で再利用・拡張可能な AI エージェント活用基盤の構築を進めています。 社内外の知識をつなぐ Knowledge Hub AI エージェント活用の重要な取り組みの一つが、社内外の知識を横断的に活用するための Knowledge Hub です。これは単なる調査支援ツールではなく、社内に蓄積された技術文書、市場調査レポート、特許情報、業務ナレッジなどを AI エージェントが安全かつ効率的に参照し、組織知として再利用できる状態にすることを目指すものです。個人や部門に閉じがちな知識を全社で活用可能なナレッジ資産として接続し、意思決定や業務遂行の質とスピードを高めることを狙っています。 1st リリースでは、OSS の gpt-researcher をベースに Deep Research Agent を構築し、社内外情報を活用した調査業務の効率化に取り組みました。しかし、利用するツールや参照先データが増えるにつれ、OSS の内部構造が複雑化し、ツールの追加・変更のたびに OSS 側の実装に踏み込む必要が生じるなど、ツール管理や安定性の面で運用上の課題が浮き彫りになりました。 そこで 2nd リリースでは、Amazon Bedrock AgentCore の一般提供開始（2025.10）を機に、フルマネージドの構成へ移行しました。AgentCore Gateway では、ツールを MCP（Model Context Protocol）経由で標準化された形で登録・管理できるため、gpt-researcher ベースでは都度必要だったツール連携の作り込みから解放され、ツールの追加・切り替えを設定ベースで安全に行えるようになりました。現在は、Web サイト検索、市場調査レポート検索、社内技術文書システム、特許システム、ITSM 検索の 5 種類を MCP サーバーとして独立したコンテナで実装し、社内外の情報を活用した調査・探索業務の効率化と、企業利用に必要な統制を両立しています。結果として、安定性、ツール利用の統制、可観測性が劇的に向上しました。 さらに、今後接続するデータソースやツールを段階的に拡充していくことを見据え、Semantic Search によるツール選択とコンテキスト圧縮を前提とした拡張性のある構成としています。ツール数が増えても、全ツール定義を毎回コンテキストに載せるのではなく、ユーザーの依頼内容に応じて必要なツールを動的に選択することで、トークン消費やレイテンシを抑えながら回答精度を維持・向上できる設計です。 ヘルプデスク業務を支援する ITSM Agent もう一つの取り組みが、ヘルプデスク業務を支援する ITSM Agent です。Agentic RAG とオブザーバビリティを組み合わせ、社内 IT サービスに関する問い合わせ対応やナレッジマネジメントの効率化を進めています。ユーザーからの問い合わせに対し、ナレッジベースやチケット管理システムを参照しながら回答を生成し、その回答が適切だったか否かのフィードバックを日々蓄積します。 具体的には、Langfuse を活用した全 LLM 呼び出しのトレース管理、回答品質のスコアリング、データセット管理、Amazon CloudWatch によるコスト可視化などを通じて、継続改善ループを構築しています。蓄積したフィードバックとトレースをもとに、低評価だった回答や誤った参照を定期的にレビューし、原因をナレッジ不足・検索精度・プロンプト・ツール選択などに切り分け、その結果を評価用データセットに反映。プロンプトや検索設定を改善した際の回答品質を、このデータセットに対するスコアリングで回帰的に確認する運用を回しています。 ITSM のように対話の品質が重要な領域では、単に回答を返すだけでなく、フィードバックを継続的に溜めて改善し続ける仕組みこそが重要です。AI エージェントの企業導入では、回答の正確性だけでなく、監査性、トレーサビリティ、継続的な改善ループが不可欠であり、Amazon Bedrock AgentCore と Langfuse を組み合わせたオブザーバビリティ基盤を活用することで、開発・運用の省力化と品質改善を同時に実現しています。 責任ある AI エージェント活用を支えるガバナンスとガードレール AI エージェントは、従来の RAG やチャットボットとは異なり、タスクの計画、ツール利用、外部システムとの連携、メモリ活用、複数エージェントの協調といった要素を持ちます。そのため企業利用においては、意図しない権限行使、許可していないサイトへのアクセス、想定外のツール利用、高コスト化、低品質な出力、機密情報漏洩、メモリ汚染、破壊的挙動、責任分界の曖昧化といったリスクへの対応が不可欠です。 AI エージェント特有のリスクを体系化したガイドライン 村田製作所には、もともと RAG をベースとした生成 AI ガバナンスガイドラインが存在していました。しかし AI エージェントの活用を本格化させる中で、既存ガイドラインが AI エージェント特有のリスクをカバーしきれていないことが明らかになりました。そこで AWS Generative AI Innovation Center のアドバイザリー支援を活用し、まずガイドラインの不足点を洗い出し、AI エージェントの知見を持つ AWS と協働して観点ごとにリスクと対策を体系化しました。 このガイドラインでは、自律性と権限委譲、AI エージェントの評価、Input リスク、推論プロセスリスク、メモリリスク、マルチエージェントおよび自律実行リスク、ツール利用リスク、業務プロセスへの影響リスクなどを体系的に整理しています。AI エージェントは推論を行い、短期・中期など複数のメモリを活用し、複数エージェントが協調して動作します。それぞれの段階にリスクが存在し、対策が必要だからです。あわせて、リスクレベル判定基準、HITL（Human-in-the-Loop）の実装方針、評価データセット設計、モニタリング・監査体制、Must-Not 行動の定義なども整備しています。 策定・展開にあたっては、いくつかの苦労もありました。当初はリスクを網羅的に洗い出したことで対策項目が膨大になり、そのまま現場に適用すると活用のハードルが上がりすぎてしまうという課題に直面しました。そこで、リスクレベル判定基準を導入し、リスクの高いユースケースに対策を重点配分する形へ整理し直すことで、すべてのリスクに一律で対応するのではなく、必要最低限の対策を絞り込む考え方を採用しました。また、ガイドラインを一度に完成させて配布するのではなく、実際に AI エージェントを開発・利用する社内ユーザーに使ってもらいながら、現場のフィードバックを受けて継続的に改訂していくアプローチを採ることで、実効性と現場の納得感を両立させています。 このガイドラインは AI エージェントの活用を制限するためのものではなく、安全に広げるための共通ルールです。生成 AI CoE では、各部門が自律的に活用を進められるようにしながら、最低限必要なガードレール、認証認可、モニタリング、評価、HITL の仕組みを共通基盤として整備し、全社統制と現場の自律性を両立する「ミドルアウト」の推進を目指しています。 二重構造で柔軟性と堅牢性を両立するガードレール ガードレールについても、企業活動の多様なユースケースに対応するため、柔軟性・堅牢性・冗長性を備えた多層設計を重視しています。汎用ガードレールだけでは業務固有のセキュリティ要件に対応しきれないという課題から、当社は Amazon Bedrock のガードレール機能と NVIDIA NeMo Guardrails を組み合わせた二重構造を採用しています。NeMo Guardrails ではプロンプトで検査対象を調整できるため、ユースケースごとに逆質問ポリシー、回答ポリシー、ツール呼び出し制限などをエージェント単位で細かく制御しています。 この二重構造には、チューニングコストを抑える狙いもあります。基盤モデルは月次以上の頻度でアップデートが発生し、そのたびに単一のガードレールだけで安全性を担保しようとすると、モデル特性の変化に合わせた細かな再調整が必要になります。Amazon Bedrock のガードレール機能でモデルに依存しない共通的な安全対策を担保しつつ、業務固有の制御は NeMo Guardrails 側でプロンプトベースに調整できる構成とすることで、モデル更新時に一方の層だけを見直せばよくなり、チューニングの手間を分散・軽減できます。結果として、モデル更新に振り回されずに安定したプロダクト提供を実現しています。 「人 → Agent → ツール/データ」の認可チェーンを設計する AI エージェント活用において、もう一つ重要なのが認証認可の設計です。従来の基幹システムでは「ユーザーからデータ」または「ユーザーからシステム」への認証認可を設計すれば足りましたが、AI エージェント時代には「人 → Agent → ツール/データ」という認可チェーンを考慮する必要があります。エージェントがユーザーに代わって処理を行い、さらに別のツールやシステムを呼び出す際には、権限が段階的に受け渡されていきます。加えて、あるエージェントが別のエージェントやツールを呼び出す再委任も前提となるため、単一の認可判定ではなく、権限委譲が連鎖する経路全体を「認可チェーン」として設計することが不可欠です。 村田製作所では、Application Load Balancer の OIDC 認証（ALB OIDC）と Microsoft Entra ID を組み合わせた認証基盤の上に、業務固有の細やかな認可設計を実装しています。Amazon Verified Permissions によるポリシーベースの認可判定を導入し、アプリケーションへのアクセス可否や編集権限など、アクション単位での制御を実現しています。RBAC（ロールベースアクセス制御）と ABAC（属性ベースアクセス制御）を組み合わせ、Cedar Policy Language を用いて認可ルールを記述。Microsoft Entra ID が保持する会社・部署などの属性、アプリ固有のユーザー属性、データ属性、例外許可、システム固有ロジックを Amazon DynamoDB で管理し、これらを組み合わせてユーザーが特定データへアクセスできるかを判定します。 こうした属性ベースの判定を、単発のアクセス制御としてではなく「人 → Agent → ツール/データ」の各ホップで評価することで、エージェントが処理を再委任する場面でも、その時々の主体と対象に応じた最小権限を適用できます。人の権限を単純にコピーするのではなく認可チェーンとして扱うことで、最小権限、職務分掌、条件付き許可、監査説明性を確保しやすくしています。エンタープライズ向け AI エージェントアーキテクチャにおいて、こうしたきめ細かな認証認可は必須の要件と考えています。 セキュリティと AI 活用を両立する「Trade-on」へ 村田製作所の取り組みの特徴は、AI 活用とガバナンスを対立関係として捉えていない点です。セキュリティを理由に活用を止めるのでも、活用を優先して統制を後回しにするのでもなく、両者を同時に高める「Trade-on」の考え方を重視しています。 その実現を支えているのが AWS のマネージドサービスです。Amazon Bedrock AgentCore による実行基盤、Amazon Verified Permissions による認可判定、Amazon Bedrock を活用した基盤モデル利用、Amazon CloudWatch によるオブザーバビリティを組み合わせることで、開発スピードを落とすことなく、企業向け AI エージェント活用に求められる安全性・拡張性・運用性を両立しています。 村田製作所では、Murata Coworker を単なる社内向け PoC ではなく、全社で日々利用される生成 AI 中核システムとして運用しています。内製開発を選択しているのは、アーキテクチャの設計、ガバナンスの運用、ユーザーとの共創を通じて蓄積される技術・業務ノウハウが、そのまま企業の競争優位につながると考えているからです。 今後は、Murata Coworker を AI エージェント活用基盤としてさらに拡張し、社内外システム連携、オペレーション再構築、そしてデジタルツインの実現へとつなげていく構想です。将来的にはフィジカル AI との接続・拡大も視野に入れており、サイバーとフィジカルの融合によって知識創造サイクルをさらに加速させることを目指しています。 当社が目指すのは、人と AI の好循環による創発型の経営変革です。人が価値ある問いを立て、Murata Coworker が全体最適を支援し、共創によって新たな価値創造につなげていく――生成 AI の活用を、個人の能力拡張からチーム、組織、企業全体の変革へと進化させる取り組みが進んでいます。村田製作所は AWS とともに、生成 AI と AI エージェントを安全かつ実践的に活用するための基盤づくりを進め、企業知性のデジタルツイン化に向けた挑戦を続けていきます。 関連リンク AIM308 村田製作所の知を活かす AI エージェント統制 （ セッション資料 | 動画 ） プロダクトマネージャーが語る、生成AIプロダクト「Murata Coworker」内製開発の舞台裏と将来展望（村田製作所 技術記事） 執筆者 鈴木 健太 株式会社村田製作所 データ戦略推進部 / 生成 AI CoE シニアマネージャー 総合電機メーカーを経て村田製作所に入社。データサイエンティストとして業務に従事する傍ら、生成AI CoEの立ち上げとリードを担当。現在もその推進を担いながら、生成AI関連プロダクト開発組織のマネジメントを務め、社内のAI活用高度化に取り組んでいる。 小金井 雄貴 株式会社村田製作所 データ戦略推進部 / 生成 AI CoE プロダクトマネージャー 大手食品メーカー、AIベンチャーを経て、2024年5月に村田製作所に入社。食品・エンタメ・消費財・広告・電子機器など様々な業界におけるデータ・AI戦略の策定から実行までをリード。現在は、内製開発生成AIプロダクトMurata Coworkerのプロダクトマネージャーを務める。