はじめに 多くのお客様は今日、SAP RISE を通じて SAP S/4HANA を実装することで、SAP ランドスケープを変革しています。しかし、まだ SAP RISE に移行していないお客様も多数おり、AWS 上で SAP システムをネイティブにホストしています。彼らは、厳しい可用性とパフォーマンス要件を満たし、改善するために、SAP システムの運用効率を最適化することを常に検討しており、その目標を達成するために AWS Systems Manager for SAP の機能を活用してきました。このブログでは、最新の機能強化により、HANA データベースを使用した SAP NetWeaver ABAP アプリケーションの開始/停止操作を自動化する方法を学びます。 AWS Systems Manager for SAP は、AWS 上の SAP アプリケーションを管理および運用するための自動化機能です。AWS サービスと AWS 上で実行される SAP アプリケーションとのシームレスな統合を提供します。HANA データベースに基づく NetWeaver ABAP アプリケーションをサポートするために、先月 AWS Systems Manager for SAP に 2 つの新機能がリリースが発表されました。お客様は、SAP HANA データベースを使用したSAP NetWeaver ABAP アプリケーションをAWS Systems Manager for SAP に登録できるようになりました。これにより、シングル構成、分散構成、高可用性（HA）構成のいずれの場合でも、アプリケーションの起動と停止を自動化することが可能になります。この機能強化により、S/4HANA や BW/4HANA などの幅広い SAP アプリケーションがカバーされ、追加のアプリケーションサーバーとウェブディスパッチャコンポーネントのサポートが拡張されます。この新機能により、複雑な SAP ランドスケープの管理が簡素化され、運用効率が向上し、高可用性と分散構成のサポートが強化されます。 SAP NetWeaver アプリケーションは、AWS Systems Manager Application Manager コンソールまたは AWS コマンドラインインターフェイス (CLI) で登録および管理できます。 AWS Systems Manager for SAP は追加費用なしでご利用いただけます。SAP 環境を管理および運用するために、プロビジョニングした AWS リソースの料金のみお支払いいただきます。 では始めましょう このブログでは、HANA データベースに基づく SAP NetWeaver ABAP アプリケーションを登録し、AWS Systems Manager Application Manager コンソールを使用してその開始/停止操作を自動化する方法について詳しく説明します。 次のステップに進む前に、以下にリストされているすべての前提条件を完了してください。 前提条件 1 – AWS Systems Manager for SAP の開始方法 前提条件 2 – SAP HANA データベースを AWS Systems Manager for SAP に登録する SAP NetWeaver ABAP ベースのアプリケーション登録 1. AWS Systems Manager コンソール を開きます。 2. 左側のナビゲーションペインで、[Application Manager] を選択します。 3. [Create Application] を選択し、[Enterprise Workload] を選んでください。 4. SAP アプリケーションタイプの下にある SAP ABAP -new を選択します 5. SAP ABAP アプリケーション の下に、例えば “ ABAPSSMTEST ” というアプリケーション名を入力します。 6. Browse instances ボタンを選択して、プライマリ SAP ABAP ワークロードのインスタンス ID を選択します。AWS Systems Manager for SAP は、HA およびディストリビューテッドトポロジーに関わるすべてのインスタンスを自動的に検出するため、すべてのインスタンスを添付する必要はありません。 7. SAP NetWeaver ABAP インスタンスの SAP システム識別子 (SID) を入力してください 8. SAP ABAP アプリケーションに関連付けられている SAP HANA データベースの Amazon Resource Name (ARN) を Browse databases を選択して指定してください。 9. (オプション) 「Connected Web Dispatcher components」の下で、アプリケーションで使用している SAP Web Dispatcher リソースの詳細を最大 5 つ入力できます。SAP Web Dispatcher リソースは、これらの詳細を入力した後に Systems Manager for SAP で検出可能になります。 「SAP System Identifier (SID)」は、SAP Web Dispatcher リソースの SAP システム識別子 (sapsid) です。 「Instance ID」は、SAP Web Dispatcher が現在実行中の Amazon EC2 インスタンス ID です。「Browse instances」を選択してインスタンス ID を検索できます。 10. (オプション) 「Application tags」の下で、リソースに関連付ける 100 個のタグを追加できます。 11. Create  を選択します。 12. 登録が成功すると、アプリケーションの一覧にあなたのアプリケーションが表示されます。アプリケーションをクリックすると、そのアプリケーションの次のタブが表示されます。 13. Database をクリックすると、ABAP アプリケーションに接続されているデータベースが表示されます。 14. トポロジを確認するには、 Resources タブをクリックし、下部パネルで ABAP システムの Topology を確認してください。 操作の停止 15. 画面の右側にある Actions メニューから Stop application を選択してください SAP NetWeaver ABAP アプリケーションを停止する際、 追加オプション の下にある SAP HANA アプリケーションを停止する と SAP ABAP および SAP HANA コンポーネントをホストする EC2 インスタンスを停止するためのこのオプションを有効にする のオプションをチェックすることで、接続された SAP HANA アプリケーションと/または SAP NetWeaver ABAP と SAP HANA アプリケーションが実行されている関連する EC2 インスタンスを停止することができます。AWS Systems Manager for SAP はアプリケーションを認識しており、EC2 インスタンスをシャットダウンする前に、すべての SAP コンポーネントを適切な方法で停止します。 16. Stop を選択してアプリケーションを停止します。 17. フラッシュバナーに表示される 操作 ID をクリックするか、 アクション メニューから 操作の表示 を選択することで、操作の状況を監視できます。 イベントの下では、アプリケーションコンポーネントが停止される順序と、操作の現在の進行状況を確認できます。これらの操作イベントは、SAP アプリケーションサーバー、ASCS、ERS、Web ディスパッチャー、データベースなど、個々の SAP コンポーネントの粒度で表示されます。障害が発生した場合、停止に失敗したコンポーネントを簡単に特定でき、そのコンポーネントの問題をさらに特定できます。 18. 操作が正常に完了すると、アプリケーションが正常に停止されたというメッセージが表示されます。 19. ページを更新 し、 Resource タブに移動して、Topology の下にアプリケーションの Status を確認してください。 操作を開始 20. 画面の右側にある Actions メニューから Start application を選択してください。 21. Start を選択してアプリケーションを開始します。 22. フラッシュバナーに表示される 操作 ID をクリックするか、 アクション メニューから 操作の表示 を選択することで、操作の状況を監視できます。 イベントの下では、アプリケーションサーバーの起動順序と操作の現在の進行状況を確認できます。これらの操作イベントは、SAP アプリケーションサーバー、ASCS、ERS、Web ディスパッチャー、データベースなどの個々の SAP コンポーネントの粒度で表示されます。障害が発生した場合、お客様は起動に失敗したコンポーネントを簡単に知ることができ、そのコンポーネントをさらにトラブルシューティングできます。 23. 操作が正常に完了すると、アプリケーションが正常に開始されたというメッセージが表示されます。ページを 更新 し、Resource タブに移動すると、Topology  の下にアプリケーションの Status が表示されます。 結論 このブログでは、HANA データベースに基づく SAP NetWeaver ABAP アプリケーションの登録方法と、 AWS Systems Manager for SAP を使用して開始/停止操作を自動化する方法を学びました。詳細については、AWS Systems Manager for SAP の詳細なドキュメントをご覧ください。 本ブログはパートナーソリューションアーキテクトの松本が翻訳しました。原文は こちら です。

(この記事は、 Improve PostgreSQL performance: Diagnose and mitigate lock manager contention を翻訳したものです。) ワークロードが拡張するにつれて、データベースの読み取り操作が予期せず遅くなっていませんか？PostgreSQL ベースのシステムを運用している多くの組織では、すぐには明らかにならないパフォーマンスのボトルネックに遭遇する事があります。多数のパーティションやインデックスを持つテーブルに対して多くの同時読み取り操作がアクセスすると、 PostgreSQL の高速パスロック機能 を使い果たし、システムが共有メモリロックを使用せざるを得なくなることがあります。高速パスから共有メモリロックへの切り替えは、ロックマネージャーにおいて軽量ロック ( LWLock ) の競合を生み出し、読み取り専用操作であってもデータベースのパフォーマンスに影響を与えます。 本投稿では、読み取り集約型のワークロードが、高速パスロックの制限を超えることによって LWLock 競合を引き起こす仕組みを探求します。これは、PostgreSQL エンジンとそのロック機構に基づく任意のシステムで発生する可能性がある問題です。デモンストレーション目的で本投稿では Aurora PostgreSQL 互換エディション を使用します。実際的な実験を通じて、パーティションスキャン、インデックスの使用、複雑な結合がロック動作にどのような影響を与えるかを実演します。また、ワークロードが低速パスロックに移行するタイミングを特定する方法と、より良いパフォーマンスのためにクエリ設計とスキーマ構造を最適化する具体的な技術を実装する方法も示します。 読み取り集約型のワークロードが増加するにつれて、データベース管理者 (DBA) は、データベースを健全に保つために LWLock 競合を監視し、対処する必要があります。同様に、開発者は過度の競合を引き起こすパターンを避けなければなりません。データベースが高速パスから低速パスロックに移行すると、スループットは大幅に低下する可能性があります (本投稿のテストでは最大 34 パーセントのパフォーマンス差を示しています)。このスループット低下は、 LWLock:lock_manager などの待機イベントを監視し、 pg_locks ビューを確認してワークロードを実行している バックエンドプロセス の高速パススロットが枯渇しているかどうかを確認することで特定できます。これらのボトルネックに対処するには、効果的な パーティションプルーニング 、慎重なインデックス管理、PostgreSQL のバックエンドプロセスあたり 16 スロットの高速パス制限内にワークロードを収めるシンプルな結合パターンなどの戦略が必要です。 LWLock 競合の理解 LWLock は、共有メモリ構造へのアクセスを調整するために PostgreSQL で使用される同期の仕組みです。 ヘビーウェイトロック ( ユーザー主導のデータベースオブジェクトレベルのロック) とは異なり、LWLock は軽量で高パフォーマンスに最適化されており、共有データへの同時アクセスを管理しながら低いオーバーヘッドを提供します。 LWLock 競合は、複数のプロセスが共有メモリ内の ロックデータ構造 上の同じ LWLock を取得しようと競合する際に発生し、遅延を引き起こします。この競合は通常、多くのバックエンドプロセスが次のような頻繁に共有されるリソースにアクセスする必要がある場合に発生します。 Buffer Manager – 読み取り/書き込み操作中に共有バッファを保護する Lock Manager – ロック関連のデータ構造へのアクセスを調整する WAL management – 先行書き込みログ ( WAL ) への書き込みを同期する LWLock 競合は、同時データベース接続数が増加するにつれて増大する可能性があります。 これは特に、Aurora PostgreSQL 互換エディションが、高並列処理、多数のパーティションを持つテーブル、または多数のインデックスを持つテーブルを含むワークロードの高スループット環境で顕著です。 テーブルに対して SQL クエリを実行する際、PostgreSQL はそのテーブルと関連するインデックスに対してロックを取得しようとします。これがパーティションテーブルの場合、SQL クエリによってアクセスされるテーブルパーティションに対してロックが取得されます。ロックをより高速かつ効率的にするため、システムが他のロックとの競合がないことを迅速に確認できる場合、制限の少ない弱いロック ( AccessShareLock 、 RowShareLock 、 RowExclusiveLock など) に対して高速パスロックが使用されます。 高速パスロック: 動作メカニズム PostgreSQL では、高速パスロッキング機構により、競合しない操作は共有メモリロックハッシュテーブルとそれに関連する LWLocks をバイパスすることができます。高速パスロッキングは、最も一般的な使用例、即ち、同じリレーションに競合する強力なロックが存在しない限り、弱いロックを取得する頻繁な同時クエリ向けに設計されています。 高速パスロックの動作は以下の通りです。 セッション別キャッシュ – 各バックエンドプロセスは、高速パスロックを格納するために、プライベート PGPROC 構造内に最大 16 個のスロット (デフォルトで FP_LOCK_SLOTS_PER_BACKEND = 16 ) を割り当てます。 迅速な高速パス適格性チェック – SELECT * FROM my_table; を実行すると、PostgreSQL は小さなバックエンド別の LWLock ( MyProc->fpInfoLock ) を取得して、現在の SQL クエリに高速パスロック機構が使用できるか、以下の項目をチェックします。 ロックモードが適格な弱いモードであること 他のセッションが競合するロックを保持していないこと バックエンドがローカルバックエンドメモリ配列の 16 スロットをすべて使用していないこと ローカル許可 – 上記の高速パス適格性チェックがパスすると、 FastPathGrantRelationLock() がバックエンドのローカルキャッシュにロックを格納します。共有メモリベースのロックハッシュテーブルを保護する共有メモリベースの LWLock は取得されず、関数は成功して即座にリターンします。 実際には、これはトランザクションがアクセスする最初の 16 個の一意のテーブル (またはインデックス) では、ロックマネージャーのオーバーヘッドはほぼゼロになることを意味します。 高速パスキャッシュは小さく、16 個のロックを超えたり、より強いロックモードを要求したりすると、PostgreSQL は低速パスにフォールバックしなければなりません。 既に取得済みの 16 個の高速パスロックを超える高速パスロックのすべての要求は、 FastPathTransferRelationLocks() を使用して共有ロックテーブルに移行されます ロックタグ（リレーション OID とロックモードを含む）は、共有メモリロックハッシュテーブルの 16 個のロックパーティションのうちの 1 つにハッシュ化されます PostgreSQL は次に、パーティション LWLock ( LWLockAcquire(partitionLock, LW_EXCLUSIVE) ) を取得し、共有ハッシュテーブルを更新し、LWLock を解放します それ以降、テーブルからインデックスまでの追加のロック取得は、ロックマネージャーを通じて行われ、同時実行下で LWLock:LockManager 待機イベントを生成します。 高速パス最適化から低速パス競合への移行を理解することで、高速パスの制限内に留まるクエリとスキーマを設計し、ロックマネージャーのボトルネックを完全に回避できます。 実験概要 以下のセクションでは、3 つの実験を通じて LWLock 競合の詳細を説明します。 パーティション化されたテーブルでのロックを観察する 使用されていない、または不要な複数のインデックスを持つパーティション化されていないテーブルでのロックを観察する マルチ結合クエリでのロック動作を観察する それぞれの実験では、スキーマのセットアップ、ワークロードの実行、PostgreSQL システムビューによるロック監視、および pgbench を使用した同時実行の影響分析を実演します。すべての実験は、db.r7g.4xlarge インスタンスを使用して Aurora PostgreSQL 互換エディション (PostgreSQL 16.6 と互換性あり) で実施しました。 前提条件 実験を開始する前に、以下が必要となります。 Aurora PostgreSQL データベースへのアクセス権を持つ AWS アカウント AWS Management Console へのアクセス権 Aurora PostgreSQL インスタンスへの接続性を持つ Amazon Elastic Compute Cloud (Amazon EC2) インスタンス Amazon EC2 インスタンス上にインストールされた PostgreSQL クライアント (psql など) Amazon EC2 インスタンス上にインストールされた pgbench Aurora PostgreSQL クラスターを作成・管理するための AWS Identity and Access Management (IAM) 権限 実験 1 : パーティション化されたテーブルでのロックを観察する この実験では、3 つの主要なテストシナリオを実行し、パーティション化されたテーブルを扱う際の PostgreSQL のロック動作を調査します。 orders テーブルのすべてのパーティションをクエリして、PostgreSQL がパーティション全体にわたってロックをどのように処理するかを観察します 特定のパーティションにアクセスするためにパーティションプルーニングを使用して、より的を絞ったアプローチを検証します 実世界のワークロードをシミュレートするため に pgbench を使用して、高い同時実行下で両方のアプローチをストレステストします これらのクエリを通じて、PostgreSQL の高速パスロック最適化がどのように動作するか、高速パススロットが枯渇したときに何が起こるか、および同時実行ワークロード下でパーティションプルーニングがいかにパフォーマンスを改善できるかを実演します。 order_ts タイムスタンプ列を使用して月単位でデータがパーティション化された orders テーブルを使用します。 この実験では、以下の点について重要な洞察が明らかになります。 PostgreSQL が読み取り専用操作中にロックをどのように管理するか 高速パスと低速パスロックの影響 パーティションプルーニングがどのようにロック競合を軽減できるか 高並行性環境におけるパフォーマンスへの影響 スキーマ準備 好みの PostgreSQL クライアント (psql など) を使用して、EC2 インスタンスから Aurora PostgreSQL インスタンスに接続し、12 の月次子パーティションを持つ orders テーブルを作成します。以下の SQL コードを実行してください。 -- Create the schema CREATE SCHEMA experiment_1; SET search_path TO experiment_1; -- Create the partitioned parent table CREATE TABLE orders ( id int NOT NULL, order_ts timestamp NOT NULL, customer_id int, amount numeric, PRIMARY KEY (id, order_ts) ) PARTITION BY RANGE (order_ts); -- Create child partitions (example: Jan 2025 - Jun 2025) DO $$ DECLARE month int := 1; partition_name text; from_date date; to_date date; BEGIN WHILE month <= 12 LOOP partition_name := 'orders_2025_' || to_char(month, 'FM00'); from_date := make_date(2025, month, 1); to_date := from_date + interval '1 month'; EXECUTE format( 'CREATE TABLE %I.%I PARTITION OF %I.%I FOR VALUES FROM (%L) TO (%L)', 'experiment_1', partition_name, 'experiment_1', 'orders', from_date, to_date ); month := month + 1; END LOOP; END $$; テスト 1 : Orders テーブルの全パーティションをクエリして、ロック動作を観察する それでは、トランザクションを開始し、パーティション化された orders テーブルのすべてのパーティションに対してクエリを実行します。パーティションプルーニング無でクエリを実行すると、PostgreSQL はすべてのパーティションにアクセスする必要があり、ロックのオーバーヘッドが大幅に増加します。このテストを開始するには、Aurora PostgreSQL データベースへの新しい接続を開き、以下のコマンドを実行します (これをセッション 1 と呼びます) 。 postgres=> set search_path to experiment_1; SET postgres=> begin; BEGIN postgres=*> select count(*) from orders; count ------- 0 (1 row) 上記のSQL ステートメントは、12 のパーティションすべてをスキャンするトランザクションを開始します。 COMMIT 、 ROLLBACK または End コマンドを実行せず、トランザクションを開いたままにしてロックを維持してください。 セッション 1 のトランザクションが開いたままの状態で、2 番目のセッション (これをセッション 2 と呼びます) を開き、データベース内のロックの状態を確認するために次の SQL クエリを実行してください。 postgres=> SELECT n.nspname AS schema, c.relname AS table, l.locktype, l.mode, l.fastpath FROM pg_locks l JOIN pg_class c ON l.relation = c.oid JOIN pg_namespace n ON c.relnamespace = n.oid AND n.nspname <> 'pg_catalog'; schema | table | locktype | mode | fastpath --------------+---------------------+----------+-----------------+---------- experiment_1 | orders_2025_07_pkey | relation | AccessShareLock | t experiment_1 | orders_2025_07 | relation | AccessShareLock | t experiment_1 | orders_2025_06_pkey | relation | AccessShareLock | t experiment_1 | orders_2025_06 | relation | AccessShareLock | t experiment_1 | orders_2025_05_pkey | relation | AccessShareLock | t experiment_1 | orders_2025_05 | relation | AccessShareLock | t experiment_1 | orders_2025_04_pkey | relation | AccessShareLock | t experiment_1 | orders_2025_04 | relation | AccessShareLock | t experiment_1 | orders_2025_03_pkey | relation | AccessShareLock | t experiment_1 | orders_2025_03 | relation | AccessShareLock | t experiment_1 | orders_2025_02_pkey | relation | AccessShareLock | t experiment_1 | orders_2025_02 | relation | AccessShareLock | t experiment_1 | orders_2025_01_pkey | relation | AccessShareLock | t experiment_1 | orders_2025_01 | relation | AccessShareLock | t experiment_1 | orders_pkey | relation | AccessShareLock | t experiment_1 | orders | relation | AccessShareLock | t experiment_1 | orders_2025_11 | relation | AccessShareLock | f experiment_1 | orders_2025_09 | relation | AccessShareLock | f experiment_1 | orders_2025_09_pkey | relation | AccessShareLock | f experiment_1 | orders_2025_11_pkey | relation | AccessShareLock | f experiment_1 | orders_2025_08_pkey | relation | AccessShareLock | f experiment_1 | orders_2025_10 | relation | AccessShareLock | f experiment_1 | orders_2025_08 | relation | AccessShareLock | f experiment_1 | orders_2025_10_pkey | relation | AccessShareLock | f experiment_1 | orders_2025_12_pkey | relation | AccessShareLock | f experiment_1 | orders_2025_12 | relation | AccessShareLock | f (26 rows) 前述の出力の最後の 10 行で fastpath 列の値が t (True) と f (False) のうち、f になっていることに注目してください。また、返された行の総数は 26 です。値 t は、16 の高速パススロットが使い果たされ、残りのパーティション/インデックスの AccessShareLock が共有メモリロックハッシュテーブル (低速パス) に移行されたことを意味します。トランザクションが完了すると、これらのロックは解放されます。 テスト 2 : 注文テーブルの特定のパーティションをクエリし、ロック動作の変化を観察する セッション 1 として、以下に示すように、新しいトランザクション内でパーティションプルーニングアプローチを使用するクエリを実行します。より多くのパーティションにアクセスし続けると、追加の高速パスロックが獲得されます。 postgres=> set search_path to experiment_1; SET postgres=> begin; BEGIN postgres=*> SELECT * FROM orders WHERE order_ts <= '2025-01-01'; id | order_ts | customer_id | amount ----+----------+-------------+-------- (0 rows) postgres=*> SELECT * FROM orders WHERE order_ts <= '2025-02-01'; id | order_ts | customer_id | amount ----+----------+-------------+-------- (0 rows) postgres=*> SELECT * FROM orders WHERE order_ts <= '2025-03-01'; id | order_ts | customer_id | amount ----+----------+-------------+-------- (0 rows) セッション 1 のトランザクションが開いたままの状態で、前回のテストで利用したセッション 2 で以下の SQL 文を実行して、データベース内のロックの状態を確認してください。 postgres=> SELECT n.nspname AS schema, c.relname AS table, l.locktype, l.mode, l.fastpath FROM pg_locks l JOIN pg_class c ON l.relation = c.oid JOIN pg_namespace n ON c.relnamespace = n.oid AND n.nspname <> 'pg_catalog'; schema | table | locktype | mode | fastpath --------------+---------------------+----------+-----------------+---------- experiment_1 | orders_2025_03_pkey | relation | AccessShareLock | t experiment_1 | orders_2025_03 | relation | AccessShareLock | t experiment_1 | orders_2025_02_pkey | relation | AccessShareLock | t experiment_1 | orders_2025_02 | relation | AccessShareLock | t experiment_1 | orders_2025_01_pkey | relation | AccessShareLock | t experiment_1 | orders_2025_01 | relation | AccessShareLock | t experiment_1 | orders_pkey | relation | AccessShareLock | t experiment_1 | orders | relation | AccessShareLock | t (8 rows) この出力は、すべてのロックが高速パスロックであることを示しており、 fastpath 列の値が t (True) になっています。これにより、低速パスロックを取得する必要がなくなります。 これは高速パスの最適化を示していますが、同時実行を伴うシナリオについては説明していません。同時実行を伴うシナリオでは、各バックエンドが高速パススロットを使い切るか、16 スロットの制限内に留まるかのいずれかになります。この特定のシナリオを詳しく見ていきましょう。pgbench を使用してマルチユーザーワークロードをシミュレートします。 テスト 3.1 : Orders テーブルの全パーティションに複数クエリを同時実行し、ロック動作の変化を観察する パーティションプルーニングせずにパーティションにアクセスする複数の読み取りワークロードをシミュレートするには、以下の pgbench コマンドを使用します。このコマンドは複数のスレッドにわたって SELECT count(*) FROM orders クエリを継続的に発行します。このテストでは、トランザクションが高速パススロットを使い果たし、メインロックマネージャーを通じてロックの獲得を強制する ( LWLock:LockManager の待機をトリガーする) 高い並列度の下で、PostgreSQL の高速パスロック最適化がどのように動作するかを評価します。 pgbench -c 100 -j 10 -n -f transaction.sql -T 900 pgbench では、 -c と -j オプションを使用してベンチマークワークロードの同時実行性と並列性を制御します。-c オプションは同時クライアント数を指定し、同時にアクティブになるシミュレートされたユーザーセッションまたはデータベース接続の数を意味します。この数値によって、PostgreSQL データベースに適用される負荷のレベルが決まります。 -j オプションは pgbench がこれらのクライアント接続を管理するために使用するワーカースレッドの数を定義します。各スレッドは全クライアントの一部を処理し、ワークロードはスレッド間で均等に分散されます。これにより pgbench はマルチコアシステムをより効率的に使用し、クライアント側のボトルネックを回避できます。 実行時に認証情報を入力せずに pgbench コマンドを実行するには、次の環境変数を設定します： PGHOST (Auroraクラスターのエンドポイント)、 PGPORT (ポート番号、例えば 5432)、 PGDATABASE (データベース名、例えば postgres)、 PGUSER (データベースユーザー)、および PGPASSWORD (データベースユーザーのパスワード)。 上記の pgbench コマンドは、transaction.sql で定義されたトランザクションを実行する 100 の同時クライアント ( -c 100 ) を 15 分間または 900 秒 ( -T 900) シミュレートします。 transaction.sql ファイルには、 experiment_1 スキーマへの検索パスの設定とともに、次の SQL が含まれています。 set search_path to experiment_1; DO $$ DECLARE random_date date; last_day date; sql text; BEGIN random_date := date '2025-01-01' + floor(random() * 365)::int; last_day := (date_trunc('month', random_date) + interval '1 month - 1 day')::date; sql := format('SELECT COUNT(*) FROM orders'); EXECUTE sql; END $$; 前回のテストのセッション 1 ターミナルから、次の pgbench コマンドを実行してください。このコマンドは 15 分で完了します。このコマンドの実行中、 Amazon CloudWatch Database Insights のデータベースの待機イベントを監視します。 sh-5.1$ pgbench -c 100 -j 10 -n -f transaction.sql -T 900 transaction type: transaction.sql scaling factor: 1 query mode: simple number of clients: 100 number of threads: 10 duration: 900 s number of transactions actually processed: 42005251 latency average = 2.143 ms tps = 46672.159856 (including connections establishing) tps = 46672.894164 (excluding connections establishing) このワークロードでは、1 秒あたりの平均トランザクション数 (tps) は 46,672 に達し、テスト時間の 15 分間で 4,200 万のトランザクションが処理されました。 CloudWatch Database Insights の以下のスクリーンショットは、アクティブなセッションがインスタンスの CPU 容量を超え、著しいロック競合を伴う高負荷を経験しているデータベースを示しています。 上のスクリーンショットは、db.r7g.4xlarge インスタンスで実行されている Aurora PostgreSQL 16.6 クラスターが、CPU 使用率とロック競合の両方による高いデータベース負荷を示しています。平均アクティブセッション (AAS) は約 21 で維持されており、これはインスタンスの 16 vCPU 容量よりも高い値です。負荷の 66 パーセントは CPU 使用率に起因していますが、34 パーセントは LWLock:LockManager の待機に費やされており、PostgreSQL 内部ロック構造の競合を示しています。 次に、パーティションプルーニングを使用してパフォーマンスを評価します。 テスト 3.2 : パーティションプルーニングを使用して、Orders テーブルの特定のパーティションに複数クエリを同時実行する パーティションプルーニングを使用していない前回のテストと対比するために、ここではパーティションプルーニングがどのようにパフォーマンスを向上させるかを実証します。このワークロードでは、この実験に使用される transaction.sql ファイルには PL/pgSQL が含まれています。これは単純な SQL クエリの代わりに使用され、パーティション分割されたテーブルと実行時に生成される値を処理する際に、PostgreSQL で効率的なパーティションプルーニングを提供します。以下のクエリのように SQL を使用することもできますが、 order_ts に対するフィルターは共通テーブル式 (CTE) 内のランダムに生成された日付から派生しており、最適な実行計画を作成するクエリプランナーは、クエリ計画時に order_ts 値を決定できません。その結果、PostgreSQL はすべてのパーティションを考慮する必要があり、すべてのパーティションの不必要なロックとスキャンにつながります。しかし、ランダムな日付を計算し EXECUTE を使用してクエリを動的に構築する PL/pgSQL ブロックに切り替えることで、実際の日付値が SQL 文字列に直接注入されます。これにより、クエリプランナーの観点からフィルターが定数に変換され、効果的なパーティションプルーニングが可能になり、関連するパーティションのみがアクセスされロックされることが保証されます。 以下は、上記で説明した CTE ベースの SQL クエリで、すべてのパーティションをロックする可能性があります。 WITH rand_date AS ( SELECT (date '2025-01-01' + (floor(random() * 365))::int) AS dt ), last_day AS ( SELECT dt, (date_trunc('month', dt) + interval '1 month - 1 day')::date AS last_day FROM rand_date ) SELECT dt AS random_date, last_day, ( SELECT COUNT(*) FROM orders WHERE order_ts >= last_day.last_day AND order_ts < last_day.last_day + interval '1 day' ) AS order_count FROM last_day; 上記で説明した効果的なパーティションプルーニングを実現するために、以下の PL/pgSQL アプローチを使用した SQL を使用してください。 set search_path to experiment_1; DO $$ DECLARE random_date date; last_day date; sql text; BEGIN random_date := date '2025-01-01' + (floor(random() * 365))::int; last_day := (date_trunc('month', random_date) + interval '1 month - 1 day')::date; sql := format('SELECT count(*) FROM orders WHERE order_ts = %L', last_day); EXECUTE sql; 前回のテストと同じ手順に従い、セッション 1 のターミナルから pgbench コマンドを実行してください。このコマンドは 15 分でテストを完了し、コマンドの実行中、CloudWatch Database Insights のデータベースの待機イベントを監視します。 sh-5.15 pgbench -c 100 -j 10 -n -f transaction.sql -T 900 transaction type: transaction.sql scaling factor: 1 query mode: simple number of clients: 100 number of threads: 10 duration: 900 s number of transactions actually processed: 53240775 latency average = 1.690 ms tps = 59255.673468 (including connections establishing) tps = 59156.616479 (excluding connections establishing) 上記の pgbench 出力に示されているように、このワークロードは 1 秒あたり平均 59,255 トランザクションを達成し、15 分間のテスト期間中に約 5,330 万トランザクションが処理されました。ロック競合がない状態では、システムは 1,100 万トランザクションを追加で処理出来た事になります。 CloudWatch Database Insights の以下のスクリーンショットは、パーティションプルーニングを実装した後の改善されたデータベースパフォーマンスを示しており、安定した負荷パターンとロック競合がないことがわかります。 前述のワークロードにパーティションプルーニングを導入したことで、Aurora PostgreSQL 16.6 クラスターのパフォーマンスは大幅に向上しました。以前は、ワークロードは CPU 使用率と並んでデータベース負荷の約 34 パーセントを消費する LWLock:LockManager の待機イベントによって特徴付けられていました。 対照的に、現在のワークロードパフォーマンスはバランスの取れたワークロードを示しています。平均アクティブセッション (AAS) は最大 vCPU 閾値を下回っており、待機は Timeout:SpinDelay のごく一部が観測されているのみです。CPU は最適化された OLTP システムでは予想される通り、負荷の主要な要因となっています。そしてロック競合は大幅に減少しました。これは、パーティションプルーニングによって取得されるロックの数を削減し、各セッションが関連するパーティションとセッションごとの高速パスロックのみにアクセスするようになり、同時実行性が大幅に向上したことを意味します。パーティションプルーニングにより、AAS は最大 vCPU 閾値を下回ったままでした。 実験 2 : 複数の未使用または不要なインデックスを持つ非パーティションテーブルのロックを観察する この実験では、PostgreSQL が複数の B-tree インデックス を持つ非パーティション化テーブルでのロック動作をどのように処理するかを調査します。ここでは、使用されていないまたは不要なインデックスの影響に焦点を当てるためにパーティション化されていないテーブルを使用しています。E コマースまたは在庫システムを表す items テーブルを使用して、2 つの重要なテストシナリオを探ります。 まず、インデックスのみのスキャンを使用して単純なクエリを実行し、以下を観察します PostgreSQL が複数の未使用または不要なインデックス全体でロックをどのように管理するか 高速パススロットが使い果たされた場合に何が起こるか 20 個の B-tree インデックスを持つことがロック取得に与える影響 次に、高い同時実行性の下でシステムのストレステストを行い、以下を実証します 過剰なインデックスがロックマネージャーの動作にどのように影響するか 複数のインデックスによるロック競合のパフォーマンスへの影響 インデックス数と LWLock:LockManager の待機の関係 これらのテストを通じて、インデックス関連のロックオーバーヘッドに関する重要な洞察を明らかにし、高い同時実行性の環境におけるインデックス管理のための実践的なガイダンスを提供します。 スキーマ準備 以下の SQL コードを使用して、Aurora PostgreSQL データベースに items テーブルスキーマとそれに関連するインデックスを作成してください。 -- Create Schema CREATE SCHEMA IF NOT EXISTS experiment_2; SET search_path TO experiment_2; CREATE TABLE items ( item_id SERIAL PRIMARY KEY, sku TEXT NOT NULL, barcode TEXT, name TEXT NOT NULL, description TEXT,category TEXT, subcategory TEXT, vendor_id INT, vendor_region TEXT, brand TEXT, model TEXT,price NUMERIC(10,2), cost NUMERIC(10,2), discount NUMERIC(5,2), margin NUMERIC(5,2), quantity_in_stock INT, reorder_level INT, lead_time_days INT, rating NUMERIC(2,1) ,num_reviews INT, available BOOLEAN DEFAULT true, warehouse_location TEXT, is_active BOOLEAN DEFAULT true,last_restocked TIMESTAMP, created_at TIMESTAMP DEFAULT now(), updated_at TIMESTAMP DEFAULT now() ); CREATE INDEX idx_items_sku ON items(sku); CREATE INDEX idx_items_barcode ON items(barcode); CREATE INDEX idx_items_name ON items(name); CREATE INDEX idx_items_category ON items(category); CREATE INDEX idx_items_vendor_id ON items(vendor_id); CREATE INDEX idx_items_brand ON items(brand); CREATE INDEX idx_items_model ON items(model); CREATE INDEX idx_items_price ON items(price); CREATE INDEX idx_items_cost ON items(cost); CREATE INDEX idx_items_quantity ON items(quantity_in_stock); CREATE INDEX idx_items_rating ON items(rating); CREATE INDEX idx_items_num_reviews ON items(num_reviews); CREATE INDEX idx_items_created_at ON items(created_at); CREATE INDEX idx_items_updated_at ON items(updated_at); CREATE INDEX idx_items_vendor_category ON items(vendor_id, category); CREATE INDEX idx_items_sku_available ON items(sku, available); CREATE INDEX idx_items_barcode_active ON items(barcode, is_active); CREATE INDEX idx_items_category_subcategory_price ON items(category, subcategory, price); CREATE INDEX idx_items_vendor_region_brand ON items(vendor_region, brand); CREATE INDEX idx_items_brand_model ON items(brand, model); 上記の SQL コードは、商品の詳細 ( SKU 、 price 、 inventory など) 用の 26 カラムを持つ E コマースの items テーブルと、よく検索されるカラムやカラムの組み合わせに対する 20 個の B-tree インデックスを作成します。 テスト 1 : 複数のインデックスを持つ非パーティションテーブルをクエリする 過剰なインデックスが PostgreSQL のロック動作にどのように影響するかの調査を始めるために、最初のテストとして items テーブルに対してクエリを実行しましょう。単純な名前検索クエリを実行して、ほとんどのインデックスがこのクエリには不要であるにもかかわらず、PostgreSQL が 20 個すべてのインデックスにわたってロック管理をどのように処理するかを観察します。これにより、過剰なインデックスを維持することで生じる基本的なロックオーバーヘッドを理解するのに役立ちます。トランザクションを開始し、インデックスアクセスパスを使用して items テーブルの特定のカラムにクエリを実行します。 postgres=> set search_path to experiment_2; SET postgres=> EXPLAIN SELECT name FROM items WHERE name = 'test'; QUERY PLAN ---------------------------------------------------------------- Index Only Scan using idx_items_name on items (cost=0.14..8.16 rows=1 width=32) Index Cond: (name = 'test'::text) (2 rows) postgres=> BEGIN; BEGIN postgres=> SELECT name FROM items WHERE name = 'test'; name ------ (0 rows) 前述の SQL クエリに対して、クエリプランナーはインデックスのみのスキャンパスを選択しました。この SQL では items テーブルから name カラムのみを選択しています。別のセッションで、ロック動作を観察します。 以下の出力で、 items テーブル、主キー、およびクエリ実行のためにプランナーが使用したインデックス ( idx_items_name ) とは別に AccessShareLock を獲得したインデックスに注目して下さい。返された行の総数は 22 で、高速パススロットは使い果たされ、6 つのロックが共有メモリロックテーブルに移動しました。このテーブルにさらにインデックスがあった場合、それらのインデックスも AccessShareLock を必要とし、高速パススロットが使い果たされているため共有メモリロックテーブルに配置されるでしょう。このテーブルに対して高い並行ワークロードが発生すると、共有メモリロックテーブルで競合が発生するため、パフォーマンスは低下する事が想定されます。 postgres=> SELECT n.nspname AS schema, c.relname AS table, l.locktype, l.mode, l.fastpath FROM pg_locks l JOIN pg_class c ON l.relation = c.oid JOIN pg_namespace n ON c.relnamespace = n.oid AND n.nspname <> 'pg_catalog'; schema | table | locktype | mode | fastpath --------------+--------------------------------------+----------+-----------------+---------- experiment_2 | idx_items_updated_at | relation | AccessShareLock | t experiment_2 | idx_items_created_at | relation | AccessShareLock | t experiment_2 | idx_items_num_reviews | relation | AccessShareLock | t experiment_2 | idx_items_rating | relation | AccessShareLock | t experiment_2 | idx_items_quantity | relation | AccessShareLock | t experiment_2 | idx_items_cost | relation | AccessShareLock | t experiment_2 | idx_items_price | relation | AccessShareLock | t experiment_2 | idx_items_model | relation | AccessShareLock | t experiment_2 | idx_items_brand | relation | AccessShareLock | t experiment_2 | idx_items_vendor_id | relation | AccessShareLock | t experiment_2 | idx_items_category | relation | AccessShareLock | t experiment_2 | idx_items_name | relation | AccessShareLock | t experiment_2 | idx_items_barcode | relation | AccessShareLock | t experiment_2 | idx_items_sku | relation | AccessShareLock | t experiment_2 | items_pkey | relation | AccessShareLock | t experiment_2 | items | relation | AccessShareLock | t experiment_2 | idx_items_vendor_region_brand | relation | AccessShareLock | f experiment_2 | idx_items_brand_model | relation | AccessShareLock | f experiment_2 | idx_items_vendor_category | relation | AccessShareLock | f experiment_2 | idx_items_barcode_active | relation | AccessShareLock | f experiment_2 | idx_items_sku_available | relation | AccessShareLock | f experiment_2 | idx_items_category_subcategory_price | relation | AccessShareLock | f (22 rows) テスト 2 : 高い同時実行性のもとで、複数のインデックスを持つ非パーティションテーブルをクエリする これらの不要なインデックスがパフォーマンスにどのように影響するかを理解するために、高い並行性の下でパーティション化されていない items テーブルのストレステストを行いましょう。パーティション化されたテーブル (実験 1) での実験と同様に、pgbench を使用して複数の同時ユーザーが同時にテーブルにアクセスすることをシミュレートします。 最初の実験と同じ pgbench コマンドを使用して、セッション 1 のターミナルから以下を実行します。このテストは 5 分間実行されます。テスト実行中、CloudWatch Database Insights のデータベースの待機イベントを監視します。 pgbench -c 100 -j 10 -n -f transaction.sql -T 300 transaction.sql ファイルには、前回のテストと同じ items テーブルに対する名前検索 SQL クエリが含まれています。 CloudWatch Database Insights の以下のスクリーンショットは、 items テーブルの過剰なインデックスによって、 LWLock:LockManager の待機時間が増加し、データベース負荷と CPU 使用率が増加する様子を示しています。 ここで観察された LWLock:LockManager 待ちは、主に items テーブルの過剰なインデックスによって引き起こされています。データが無い場合でも、PostgreSQL はクエリの計画と実行中に 20 個すべてのインデックスを調べ、関連するロックを取得し、カタログメタデータにアクセスする必要があるため、オーバーヘッドが発生します。高い並行性のため、多数のロックが関与し、データベースセッションは高速パスロックを使い果たし、バックエンドプロセスがメインロックマネージャーに頼らざるを得なくなり、追加の競合が発生しました。これにより、繰り返されるカタログスキャンによる CPU 使用率の増加と、ロック取得のオーバーヘッドによるデータベース負荷の上昇が生じました。不要なインデックスの数を減らすことは、クエリプランニングの複雑さを減少させるだけでなく、高速パスロッキングを維持するのに役立ち、高い並行性のワークロードの下でシステム効率を向上させるでしょう。 実験 3 : 複数結合クエリでのロック動作を観察する この実験では、PostgreSQL が複数の関連テーブルにまたがる複雑なクエリを実行する際にどのようにロックを管理するかを調査します。実際的な E コマースデータベーススキーマを使用して、2 つの重要なテストシナリオを探ります。 まず、単一のマルチ結合クエリを検証します ユーザーのカート内容、アイテム価格、注文状況、および支払い詳細を単一の読み取り専用操作で取得します 6 つの相互関連テーブル ( users 、 carts 、 cart_items 、 items 、 orders 、 payments ) を接続します PostgreSQL が複数のテーブルとそのインデックスにまたがるロックをどのように処理するかを実証します このクエリは、複数のテーブル結合が累積的なロックのフットプリントにどのように影響するかを観察する機会を提供します。各テーブルには独自の主キーと外部キーのインデックスがあるため、PostgreSQL はこれらの単純な読み取りに高速パスロックを使用できる可能性があり、共有メモリロックテーブルにエントリを取得するオーバーヘッドを回避できます。 次に、高い並行性の下でシステムのストレステストを行います 複雑な結合を実行する複数のセッションがロック管理にどのように影響するかを観察します 複数のインデックス付きテーブルにまたがるロック取得のパフォーマンスへの影響を測定します 結合の複雑さが CPU 使用率とロック競合の両方にどのように影響するかを実証します これらのテストを通じて、以下に関する重要な洞察を明らかにします。 複雑な相互接続されたテーブル構造におけるロック管理 テーブル結合、インデックス、およびロックオーバーヘッドの関係 高い並行性環境におけるマルチ結合クエリのパフォーマンスに関する考慮事項 スキーマ準備 以下の SQL コードを使用して、6 つの相互接続されたテーブル ( users 、 carts 、 cart_items 、 items 、 orders 、および payments ) とそれらに関連するインデックスおよび外部キー制約を含む E コマーススキーマを作成してください。このスキーマは、実際の E コマースデータベースをシミュレートするために、テーブルごとに複数のインデックスと適切な参照整合性制約を含む包括的な設計になっています。 -- Create Schema CREATE SCHEMA IF NOT EXISTS experiment_3; SET search_path TO experiment_3; -- USERS table CREATE TABLE users ( user_id SERIAL PRIMARY KEY, name TEXT NOT NULL, email TEXT UNIQUE NOT NULL, phone TEXT, role TEXT DEFAULT 'customer', is_active BOOLEAN DEFAULT TRUE, is_deleted BOOLEAN DEFAULT FALSE, created_by INT, updated_by INT, created_at TIMESTAMP DEFAULT now(), updated_at TIMESTAMP DEFAULT now(), deleted_at TIMESTAMP ); -- Indexes for USERS CREATE INDEX idx_users_name_created_at ON users(name, created_at); CREATE INDEX idx_users_email_active ON users(email, is_active); CREATE INDEX idx_users_role_active ON users(role, is_active); CREATE INDEX idx_users_created_at ON users(created_at); -- ITEMS table CREATE TABLE items ( item_id SERIAL PRIMARY KEY, name TEXT NOT NULL, description TEXT, sku TEXT UNIQUE, category TEXT, price NUMERIC(10,2) NOT NULL, discount NUMERIC(5,2) DEFAULT 0.00, stock_quantity INT NOT NULL, restock_threshold INT DEFAULT 10, is_active BOOLEAN DEFAULT TRUE, is_deleted BOOLEAN DEFAULT FALSE, created_by INT, updated_by INT, created_at TIMESTAMP DEFAULT now(), updated_at TIMESTAMP DEFAULT now(), deleted_at TIMESTAMP ); -- Indexes for ITEMS CREATE INDEX idx_items_price_stock ON items(price, stock_quantity); CREATE INDEX idx_items_category_active ON items(category, is_active); CREATE INDEX idx_items_name_price ON items(name, price); CREATE INDEX idx_items_created_at ON items(created_at); -- CARTS table CREATE TABLE carts ( cart_id SERIAL PRIMARY KEY, user_id INT REFERENCES users(user_id) ON DELETE CASCADE, status TEXT DEFAULT 'open', is_deleted BOOLEAN DEFAULT FALSE, expires_at TIMESTAMP, created_by INT, updated_by INT, created_at TIMESTAMP DEFAULT now(), updated_at TIMESTAMP DEFAULT now(), deleted_at TIMESTAMP ); -- Indexes for CARTS CREATE INDEX idx_carts_user_created ON carts(user_id, created_at); CREATE INDEX idx_carts_user_status ON carts(user_id, status); CREATE INDEX idx_carts_status_expires ON carts(status, expires_at); CREATE INDEX idx_carts_created_at ON carts(created_at); -- CART_ITEMS table CREATE TABLE cart_items ( cart_item_id SERIAL PRIMARY KEY, cart_id INT REFERENCES carts(cart_id) ON DELETE CASCADE, item_id INT REFERENCES items(item_id) ON DELETE RESTRICT, quantity INT NOT NULL CHECK (quantity > 0), price_at_addition NUMERIC(10,2), is_deleted BOOLEAN DEFAULT FALSE, added_at TIMESTAMP DEFAULT now() ); -- Indexes for CART_ITEMS CREATE INDEX idx_cart_items_cart_item ON cart_items(cart_id, item_id); CREATE INDEX idx_cart_items_item_deleted ON cart_items(item_id, is_deleted); CREATE INDEX idx_cart_items_cart_added ON cart_items(cart_id, added_at); CREATE INDEX idx_cart_items_added_at ON cart_items(added_at); -- ORDERS table CREATE TABLE orders ( order_id SERIAL PRIMARY KEY, user_id INT REFERENCES users(user_id), cart_id INT REFERENCES carts(cart_id), status TEXT NOT NULL CHECK (status IN ('pending', 'paid', 'shipped', 'cancelled', 'refunded')), shipping_address TEXT, billing_address TEXT, tracking_number TEXT, payment_due_date TIMESTAMP, is_deleted BOOLEAN DEFAULT FALSE, total NUMERIC(10,2), created_by INT, updated_by INT, created_at TIMESTAMP DEFAULT now(), updated_at TIMESTAMP DEFAULT now(), deleted_at TIMESTAMP ); -- Indexes for ORDERS CREATE INDEX idx_orders_status_created ON orders(status, created_at); CREATE INDEX idx_orders_user_status ON orders(user_id, status); CREATE INDEX idx_orders_user_created ON orders(user_id, created_at); CREATE INDEX idx_orders_tracking ON orders(tracking_number); -- PAYMENTS table CREATE TABLE payments ( payment_id SERIAL PRIMARY KEY, order_id INT REFERENCES orders(order_id) ON DELETE CASCADE, payment_method TEXT NOT NULL, payment_status TEXT DEFAULT 'initiated', transaction_id TEXT UNIQUE, currency TEXT DEFAULT 'USD', amount NUMERIC(10,2) NOT NULL, is_refundable BOOLEAN DEFAULT FALSE, paid_at TIMESTAMP DEFAULT now(), refunded_at TIMESTAMP ); -- Indexes for PAYMENTS CREATE INDEX idx_payments_method_paid_at ON payments(payment_method, paid_at); CREATE INDEX idx_payments_method_status ON payments(payment_method, payment_status); CREATE INDEX idx_payments_order_status ON payments(order_id, payment_status); CREATE INDEX idx_payments_currency_paid ON payments(currency, paid_at); テスト 1 : 複数のインデックステーブルにわたるマルチ結合クエリを実行する PostgreSQL が複雑な結合操作中にロックをどのように処理するかの調査を開始するために、ユーザーのショッピングカート情報を取得するマルチ結合クエリを使用して最初のテストを実行しましょう。このクエリは、PostgreSQL が複数のテーブルとそれらに関連するインデックスにわたってロックをどのように管理するかを示します。セッション 1 で、トランザクションを開始して次のクエリを実行します。 postgres=> SET search_path TO experiment_3; BEGIN; SELECT u.user_id, u.name AS user_name, c.cart_id, i.name AS item_name, ci.quantity, i.price, (i.price * ci.quantity) AS line_total, o.order_id, o.status, p.payment_method, p.amount FROM users u JOIN carts c ON c.user_id = u.user_id JOIN cart_items ci ON ci.cart_id = c.cart_id JOIN items i ON i.item_id = ci.item_id LEFT JOIN orders o ON o.cart_id = c.cart_id LEFT JOIN payments p ON p.order_id = o.order_id WHERE u.user_id = (1 + floor(random() * 10))::int; SET BEGIN user_id | user_name | cart_id | item_name | quantity | price | line_total | order_id | status | payment_method | amount ---------+-----------+---------+-----------+----------+-------+------------+----------+--------+----------------+-------- (0 rows) セッション 1 で上記のトランザクションを開いたままにして、セッション 2 で以下のクエリを実行し、PostgreSQL がマルチ結合クエリに関わるすべてのテーブルとインデックスにわたってロックをどのように管理しているかを調べてください。 postgres=> SELECT n.nspname AS schema, c.relname AS table, l.locktype, l.mode, l.fastpath FROM pg_locks l JOIN pg_class c ON l.relation = c.oid JOIN pg_namespace n ON c.relnamespace = n.oid AND n.nspname <> 'pg_catalog'; schema | table | locktype | mode | fastpath ---------------+------------------------------+----------+----------------+---------- experiment_3 | idx_carts_status_expires | relation | AccessShareLock | t experiment_3 | idx_carts_user_status | relation | AccessShareLock | t experiment_3 | idx_carts_user_created | relation | AccessShareLock | t experiment_3 | carts_pkey | relation | AccessShareLock | t experiment_3 | idx_users_created_at | relation | AccessShareLock | t experiment_3 | idx_users_role_active | relation | AccessShareLock | t experiment_3 | idx_users_email_active | relation | AccessShareLock | t experiment_3 | idx_users_name_created_at | relation | AccessShareLock | t experiment_3 | users_email_key | relation | AccessShareLock | t experiment_3 | users_pkey | relation | AccessShareLock | t experiment_3 | payments | relation | AccessShareLock | t experiment_3 | orders | relation | AccessShareLock | t experiment_3 | items | relation | AccessShareLock | t experiment_3 | cart_items | relation | AccessShareLock | t experiment_3 | carts | relation | AccessShareLock | t experiment_3 | users | relation | AccessShareLock | t experiment_3 | idx_cart_items_item_deleted | relation | AccessShareLock | f experiment_3 | idx_orders_user_status | relation | AccessShareLock | f experiment_3 | idx_cart_items_cart_item | relation | AccessShareLock | f experiment_3 | idx_payments_order_status | relation | AccessShareLock | f experiment_3 | idx_carts_created_at | relation | AccessShareLock | f experiment_3 | idx_cart_items_cart_added | relation | AccessShareLock | f experiment_3 | idx_items_created_at | relation | AccessShareLock | f experiment_3 | orders_pkey | relation | AccessShareLock | f experiment_3 | payments_pkey | relation | AccessShareLock | f experiment_3 | idx_items_name_price | relation | AccessShareLock | f experiment_3 | idx_payments_method_status | relation | AccessShareLock | f experiment_3 | payments_transaction_id_key | relation | AccessShareLock | f experiment_3 | idx_items_category_active | relation | AccessShareLock | f experiment_3 | items_pkey | relation | AccessShareLock | f experiment_3 | idx_orders_status_created | relation | AccessShareLock | f experiment_3 | idx_items_price_stock | relation | AccessShareLock | f experiment_3 | idx_cart_items_added_at | relation | AccessShareLock | f experiment_3 | idx_orders_tracking | relation | AccessShareLock | f experiment_3 | idx_payments_currency_paid | relation | AccessShareLock | f experiment_3 | cart_items_pkey | relation | AccessShareLock | f experiment_3 | items_sku_key | relation | AccessShareLock | f experiment_3 | idx_orders_user_created | relation | AccessShareLock | f experiment_3 | idx_payments_method_paid_at | relation | AccessShareLock | f (39 rows) 上記の出力では、PostgreSQL が合計 39 個のロックを取得したことがわかります。 fastpath 列を見ると、23 行が f (false) を示しており、これらのロックは高速パスの代わりに共有メモリロックテーブルを通じた、低速パスを使用する必要があったことを示しています。これは、一見単純なネスト結合クエリでも、高速パススロットが使い果たされると著しいロック競合が発生する可能性があることを示しています。 テスト 2 : 高い同時実行性でマルチ結合クエリを実行する 上記の SQL クエリにおける複雑な結合が大規模環境でどのように実行されるかを理解するために、高い並行性の下で E コマーススキーマのストレステストを実施しましょう。前回の実験と同様に、pgbench を使用して複数の同時ユーザーが同時にマルチ結合クエリを実行することをシミュレートします。 前回の実験 (実験 1 と 2) と同じ pgbench コマンドを使用して、セッション 1 のターミナルから以下を実行します。このテストは 5 分間実行されます。 pgbench -c 100 -j 10 -n -f transaction.sql -T 300 transaction.sql ファイルには、前のテストと同じマルチ結合 SQL クエリが含まれています。テスト実行中、CloudWatch Database Insights でデータベース待機イベントを監視します。 CloudWatch Database Insights の以下のスクリーンショットは、多数のインデックスが付いたテーブル間のマルチ結合クエリが、アクティブセッションの 20 パーセントを消費する LWLock:LockManager 競合と、80 パーセントで飽和に近づく CPU 使用率という二重のパフォーマンス影響をもたらすことを示しています。 データベース負荷グラフは、複数のインデックスを持つテーブル間でのマルチ結合クエリによる著しい LWLock:LockManager 競合 (AAS の 20 パーセント) と高い CPU 使用率 (80 パーセント) を示しています。各結合は、PostgreSQL がインデックスに対して AccessShareLock ロックを取得することを強制し、高速パスロックを使い果たし、より遅いメインロックマネージャーに頼ることになります。クエリプランニング中の繰り返しのカタログスキャンにより、CPU 使用率は飽和に近づいています。このロックマネージャーのボトルネックは、結合プランニング中に複数のインデックス付きテーブル全体でロックを維持することの複合的なオーバーヘッドに起因しています。冗長なインデックスを減らし、結合パターンを簡素化することで、ワークロードで見られるロック競合と CPU 圧力の両方が軽減されるでしょう。 PostgreSQL のロック競合を管理するための主な緩和戦略 PostgreSQL のロック競合を軽減するための以下の主要な対策を検討してください。 パーティション化されたテーブルへの最適化されたアクセス パーティションプルーニングを有効にする – フルテーブルスキャンの代わりに明示的な日付範囲 ( WHERE order_ts BETWEEN X AND Y ) を使用します。 PostgreSQL のドキュメント からパーティションプルーニングについて詳細を学んでください。 定数のない動的 SQL を避ける – プルーニングを強制するため、本投稿の最初の実験のように CTE を PL/pgSQL ブロックに置き換えます。 パーティション数を制限する – 可能な場合はパーティションを減らし (例えば、月次パーティションの代わりに四半期パーティションを検討)、高速パスの制限内に収めます。 インデックスの合理化 未使用のインデックスを監査し削除する – pg_stat_user_indexes を使用して使用頻度の低いインデックスを特定します。 冗長なインデックスを統合する – 単一カラムのインデックスを複合インデックスに置き換えます (例えば、3 つの個別インデックスの代わりに( category , subcategory , price ))。 過剰なインデックス付けを避ける – OLTP にとって重要でない限り、テーブルあたりのインデックス数を制限します (例えば、10 以下)。 スキーマ設計の調整 不必要なパーティション化を避ける – 100GB を超えるテーブルまたは明確なアクセスパターンがあるテーブルのみをパーティション化します。テーブルパーティション化をいつどのように実装するかについての詳細なガイダンスは、「 Improve performance and manageability of large PostgreSQL tables by migrating to partitioned tables on Amazon Aurora and Amazon RDS 」を参照してください。 カバリングインデックスを使用する – テーブルアクセスを避けるために INCLUDE 列を追加します (リレーションロックを減らします)。カバリングインデックスとインデックスのみのスキャンの実装についての詳細は、 PostgreSQL のドキュメント を参照してください。 高並行性テーブルを正規化する – 幅広いテーブル (例えば、 items ) を分割してインデックスの拡散を減らします。 クエリの最適化 結合を簡素化する – マルチ結合クエリをマテリアライズドビューまたはステージドクエリに分割します。マテリアライズドビューの実装については、 PostgreSQL のドキュメント を参照してください。 小さな読み取りをバッチ処理にする – 小さな検索 (例えば、 IN (...) 句) を組み合わせてロック頻度を減らします。 PostgreSQL のチューニング max_locks_per_transaction を調整する – パーティション化が避けられない場合 (メモリを監視)、および余分なロックが共有メモリロックハッシュテーブルに移動される場合は増やします (例えば、256 から 512 へ)。 高速パスの使用状況を監視する – pg_locks を追跡してスロットの使い果たしを特定します。 クリーンアップ 本投稿のソリューションを実装することに関連した将来の料金が発生しないようにするには、作成したリソースを削除してください。 実験で作成したテストスキーマとテーブルを削除します テスト用に専用の Aurora PostgreSQL クラスターを作成した場合は、それを削除します 不要になった関連スナップショットを削除します 結論 PostgreSQL の読み取り負荷の多いワークロードにおける LWLock の競合は、高速パスロッキングの制限を超えることから生じます。これは、パーティションプルーニングの未実装、冗長なインデックス、および複雑な結合によって引き起こされます。本投稿の実験では、以下のことが実証されました。 パーティションプルーニングはロックのオーバーヘッドを削減し、ロックを高速パススロットに限定することで、34 パーセントのパフォーマンス向上 (46,000 tps から 59,000 tps へ) をもたらしました 使用されていない各インデックスはロック負荷を増加させ、空のテーブルでも低速パスへのフォールバックを強制します マルチ結合クエリは競合を増幅し、テストされたシナリオでは 60 パーセントのロックが低速パスに溢れました パーティションを意識したクエリの優先、厳格なインデックスの管理、および結合の簡素化によって、高速パスの効率を維持し、Amazon Aurora PostgreSQL とAmazon RDS for PostgreSQL で線形な読み取りスケーラビリティを提供できます。データベースが成長するにつれ、これらの最適化はロックのボトルネックなしで AWS の弾力性を活用するための基礎となります。 Aurora でのパフォーマンスチューニングとスケーラブルな PostgreSQL ワークロードの設計についての詳細は、「 Aurora PostgreSQL チューニングの基本概念 」を参照してください。 翻訳はテクニカルアカウントマネージャーの西原が担当しました。原文は こちら をご覧下さい。

本記事は米国時間 8 月 7 日に公開された「 Understanding Kiro’s Pricing: Specs, Vibes, and Usage Tracking 」を翻訳したものです。Kiro の最新情報は、 https://kiro.dev/  をご覧ください。 先週 Kiro の新しい価格設定階層 を発表して以来、提案された価格モデルについて多くの質問をいただきました。主要な 3 つの質問が浮かび上がりました。 「Spec リクエスト」と「Vibe リクエスト」の違いは何ですか？ ユーザーはより明確な定義と例を求めています。 使用量をどのようにトラッキングできますか？ 現在のエディターには使用量トラッキングがないため、私たちのプランがニーズに合うかどうかユーザーが分からない状況です。 階層制限を超えた場合はどうなりますか？ Pro+（$40）を使用していて、より多くの容量が必要な場合、Power（$200）にジャンプする必要がありますか？ このブログ記事では、これら 3 つの質問すべてに答え、皆さんが求めていた追加の明確性を提供します。 「Specリクエスト」と「Vibeリクエスト」の違いは何ですか？ 多くのユーザーから、なぜ Spec と Vibe リクエストを分けているのか、そしてこれらのリクエストが使用量の観点で正確に何を意味するのかという質問をいただきました。私たちが Spec と Vibe モデルを選んだのは、Kiro の実際の使用パターンを反映し、コストを予測可能な方法で理解できるようにするためです。これらのリクエストが何なのかを詳しく見てみましょう。 Spec リクエスト は、Kiro の構造化された開発ワークフロー内でタスクを実行する際のものです。動作の仕組みは次の通りです。まず Vibe リクエストを使用して要件と設計ドキュメントを作成します。それらが生成された後、Kiro はプロジェクトの構築を開始するためのタスクリストを提示します。これらのタスクの 1 つ 1 つが大まかに 1 つの Spec リクエストに相当しますが、複雑さによって変動することがあります。 平均的な複雑さの Spec タスクを想定した場合のシナリオをいくつか示します。 「Start task」をクリックしたり「タスク 1 を実行」と言ったりすると 1 つの Spec リクエストになります。 複数のタスクを同時に実行する場合（例：「タスク1-3を実行」）、実行される各タスクが 1 つの Spec リクエストになります。 サブタスクの実行（タスク 2 にサブタスク 2.1 と 2.2 がある場合＝ 2 つの Spec リクエスト）は 2 つの Spec リクエストになります。 Vibe リクエスト は、Spec タスクの実行を含まない Kiro でのすべてのエージェント操作をカバーします。Vibe リクエストは、Kiro との 1 回のチャット相互作用を表します。通常は 1 つのユーザープロンプトとそれに対応する応答です（ただし、プロンプトの複雑さによって増加する可能性があります）。私たちはリクエストのサイズを調整して、1 つの Vibe リクエストが通常あなたからの 1 つのメッセージまたはプロンプトに等しく、1 つの Spec リクエストが 1 つのタスクの実行に等しくなるようにしました。 平均的な複雑さの Vibe リクエストを想定した場合のシナリオをいくつか示します。 Kiro で「このコードを説明して」のようにチャットすることは 1 つの Vibe リクエストです。 Spec やステアリングドキュメントの作成と改良は 1 つの Vibe リクエストになります。 エージェントフックのトリガーは 1 つの Vibe リクエストになります。 「X を行う API を作って」のような複雑な Vibe プロンプトは、完了するまでに複数の Vibe リクエストを要する可能性があります。 これら 2 つの次元を提供することで、相互作用やトークンを推定するよりも使用量をより明確に理解できます。また、Kiro の仕様 (Spec) 駆動開発アプローチを奨励するよう階層を設計しました。これにより、開発者がより高速に動作し、適切な問題を解決するための適切なコードを書くのに役立つと考えているからです。研究によると、開発段階で問題に対処することは、ソフトウェア開発ライフサイクルの計画段階で解決するよりも 5 〜 7 倍コストが高くなることが示されています。この原則は AI エージェントでも当てはまります。計画段階で Kiro と要件と設計について時間をかけて話し合うとき、1 つの Spec リクエストで、実装中に複数の Vibe リクエストが必要になるであろうことを達成できることが多いのです。 Kiro の使用量をどのようにトラッキングしますか？ フィードバックの 2 つ目の領域は、有料プランにコミットする前の詳細な使用量トラッキングと透明性の要求でした。今月後半に価格設定が開始される際、すべてのユーザーは各リクエスト後に更新される使用量ダッシュボードを利用できるようになります。 以下に示す IDE ダッシュボードを通じて、Vibe と Spec リクエストの使用量の両方を監視し、超過分を追跡し、現在の請求サイクルでの残り割り当てを確認できます。この透明性により、プラン選択について十分な情報に基づいた決定を行い、使用パターンを最適化できます。有料階層の加入者の場合、ダッシュボードは潜在的な超過料金の見積もりも提供し、コストをより適切に管理するのに役立ちます。 アカウント名、推定使用量（リセット日付付き）、プラン名、Spec/Vibe リクエスト数（プランでカバーされる合計の内訳）、超過分のトグルを示すスクリーンショット 階層制限を超えた場合はどうなりますか？ フィードバックの 3 つ目の領域は、Kiro プランで受け取るリクエスト数と、Pro+（$40）と Power（$200）階層の間のギャップに関するものでした。皆さんの中には、使用パターンとより良く合致する手頃な中間オプションへの関心を表明された方もいます。 私たちの解決策は、柔軟な超過オプションを通じてこれに対処します。Kiroの有料階層のいずれかをご利用の場合、$0.20/Specリクエストまたは$0.04/Vibeリクエストの料金で追加リクエストを支払うことを選択できます。これにより、階層間の柔軟性が提供され、より高いプランレベルにすぐにアップグレードすることなく、使用量を拡張できます。 Kiro の体験を最大限に活用する これらの回答が、Kiro から最大の価値を得る方法をより良く理解し、あなたの働き方に合った適切なオプションを見つけるのに役立つことを願っています。 近日中に、サブスクリプションの仕組みについての FAQ を詳しく説明する別のブログ記事と、コスト面から見た仕様（Spec）駆動開発のメリットを実演するビデオを公開する予定です。 Discord に参加して議論を続けましょう！

8 月 6 日、 AWS re:Invent 中にプレビューした 新しい Amazon Bedrock のガードレール ポリシーである自動推論チェックの一般提供が開始されたことをお知らせします。自動推論チェックは、 基盤モデル (FM) によって生成されたコンテンツの正確性をドメインの知識に照らして検証するのに役立ちます。これは、AI のハルシネーションを理由とする事実誤認を防ぐのに役立ちます。このポリシーは、数学的ロジックと形式検証の手法を用いて正確性を検証し、AI の応答の正確性をチェックするための明確なルールとパラメータを提供します。 このアプローチは、結果に確率を割り当てることで不確実性に対処する確率的推論手法とは根本的に異なります。実際、自動推論チェックは最大 99% の検証精度を実現し、AI のハルシネーションの検出において証明可能な保証を提供すると同時に、モデルの出力について複数の解釈が可能である場合の曖昧性の検出にも役立ちます。 一般提供の開始に伴い、次の新特徴量をご利用いただけます: 1 回のビルドにおける、最大 80,000 トークンの大規模ドキュメントのサポート – 膨大なドキュメントを処理します。これは、最大 100 ページ分のコンテンツに相当します 簡素化されたポリシー検証 – 検証テストを保存して繰り返し実行します。これにより、時間が経過する中でポリシーを維持および検証することがより容易になります シナリオの自動生成 – 定義からテストシナリオを自動的に作成することで、カバレッジをより包括的なものとしながら、時間と労力を削減できます 強化されたポリシーフィードバック – ポリシーの変更に関して自然言語での提案を提供することで、ポリシーの改善を簡素化します カスタマイズ可能な検証設定 – 特定のニーズに合わせて信頼スコアのしきい値を調整することで、検証の厳密さをより細かく制御できます これが実際にどのように機能するのかを見てみましょう。 Amazon Bedrock のガードレールでの自動推論チェックの作成 自動推論チェックを使用するには、まずナレッジドメインのルールを自動推論ポリシーにエンコーディングしてから、そのポリシーを使用して生成されたコンテンツを検証します。このシナリオでは、誰が住宅ローンの利用資格を得ることができるかを評価する AI アシスタントを保護するための住宅ローン承認ポリシーを作成します。AI システムの予測が、住宅ローンの承認用に確立されたルールとガイドラインから逸脱しないことが重要です。これらのルールとガイドラインは、自然言語で記述されたポリシードキュメントに含まれています。 Amazon Bedrock コンソール で、ナビゲーションペインから [自動推論] を選択してポリシーを作成します。 ポリシーの名前と説明を入力し、ポリシードキュメントの PDF をアップロードします。名前と説明は単なるメタデータであり、自動推論ポリシーの構築には役立ちません。ソースコンテンツの説明を入力して、それを形式ロジックにどのように変換すべきかについてのコンテキストを追加します。例えば、AI アシスタントからのサンプル Q&A を含め、アプリケーションでポリシーをどのように使用することを計画しているのかを説明します。 ポリシーの準備ができたら、概要ページに移動し、ポリシーの詳細と、テストおよび定義の概要を表示します。ドロップダウンから [定義] を選択して、自動推論ポリシーを確認します。このポリシーは、自然言語ポリシーを形式ロジックに変換するために作成されたルール、変数、および型で構成されています。 [ルール] は、ポリシー内の変数がどのように関連し、生成されたコンテンツを評価する際にどのように使用されるのかを記述します。例えば、この場合においては、適用するしきい値と、いくつかの決定が行われる方法です。追跡可能性を確保するために、各ルールには一意の ID が付与されます。 [変数] は、元の自然言語ドキュメントで使用されている主要な概念を表します。各変数は、1 つ以上のルールに関係しています。変数を使用すると、複雑な構造を理解しやすくなります。このシナリオでは、一部のルールで頭金やクレジットスコアを確認する必要があります。 カスタム [型] は、ブール値と数値のいずれでもない変数のために作成されます。例えば、限られた数の値しか取れない変数のために作成されます。この場合、ポリシーには保険付き住宅ローンと従来型住宅ローンの 2 種類の住宅ローンが含まれています。 これで、テストを通じて、初期の自動推論ポリシーの質を評価できます。ドロップダウンから [テスト] を選択します。ここで、入力 (任意) と出力 (顧客と AI アシスタントのやり取りにおける質問とその考えられる回答など) で構成されるテストを手動で入力できます。その後、自動推論チェックから期待される結果を設定します。期待される結果は、有効 (回答が正しい)、無効 (回答が正しくない)、または前提次第で成立する (具体的な前提によって回答が真にも偽にもなる) のいずれかです。また、クエリ/コンテンツのペアを自然言語からロジックに変換するための信頼度しきい値を割り当てることもできます。 テストを手動で入力する前に、定義からシナリオを自動生成するオプションを使用します。これはポリシーを検証するための最も簡単な方法であり、(ロジックのエキスパートでない限り) ポリシー作成後の最初のステップにすべきです。 生成されたシナリオごとに、それが起こり得る (前提次第で成立する) か、起こり得ないか (無効) を示す、期待される検証を提供します。起こり得ない場合は、定義を更新するために使用できる注釈を追加できます。生成されたシナリオをより深く理解するために、 SMT-LIB 構文を使用してテストの形式的なロジック表現を示すことができます。 シナリオ生成オプションを使用した後、いくつかのテストを手動で入力します。これらのテストでは、異なる期待される結果を設定します。ポリシーに従っているため有効なもの、ポリシーに違反しているため無効なもの、特定の前提に依拠しているため前提次第で成立するものなどがあります。 その後、 [すべてのテストを検証] を選択して結果を確認します。ここでは、すべてのテストに合格しました。これで、ポリシーを更新する際に、これらのテストを使用して、変更によってエラーが発生していないことを検証できます。 各テストについて、検出結果を確認できます。テストに合格しなかった場合は、テストの失敗を引き起こし、期待される結果に反する矛盾を生み出したルールを確認できます。この情報を使用して、注釈を追加すべきか、ポリシーを改善すべきか、またはテストを修正すべきかを判断できます。 テストに満足したので、新しい Amazon Bedrock ガードレールを作成 (または既存のガードレールを更新) して、最大 2 つの自動推論ポリシーを使用して AI アシスタントの応答の有効性を確認できます。ガードレールによって提供される 6 つのポリシーはすべてモジュール式で、併用することも、個別に使用することもできます。例えば、自動推論チェックは、コンテンツフィルタリングやコンテキストグラウンディングチェックなどの他のセーフガードと併用できます。ガードレールは、 ApplyGuardrail API を介して、Amazon Bedrock が提供するモデル、または任意のサードパーティーのモデル (Open AI や Google Gemini など) に適用できます。また、 Strands Agents などのエージェントフレームワークでガードレールを使用する こともできます。これには、 Amazon Bedrock AgentCore を使用してデプロイされたエージェント が含まれます。 ポリシーの設定方法を確認したので、自動推論チェックが実際にどのように使用されるのかを見てみましょう。 お客様の導入事例 – ユーティリティのサービス中断時の対応管理システム 停電時には、一分一秒が重要です。そのため、ユーティリティ企業はサービス中断時の対応管理システムを改善するために AI ソリューションを活用しています。当社は、このスペースにおいて、 PwC とともにソリューションを開発しました。 自動推論チェックを使用することで、ユーティリティ企業は、次を通じてオペレーションを効率化できます: 自動プロトコル生成 – 規制要件を満たす標準化された手順を作成します 計画のリアルタイム検証 – 対応計画が確立されたポリシーに準拠しているようにします 構造化されたワークフローの作成 – 定義された対応目標に基づき、重大度ベースのワークフローを開発します このソリューションの中核では、インテリジェントなポリシー管理と、最適化された対応プロトコルを組み合わせています。自動推論チェックは、AI によって生成された応答を評価するために使用されます。応答が無効であるか、または前提次第で成立すると判断された場合、回答を書き換えたり、強化したりするために、自動推論チェックの結果が使用されます。 このアプローチは、AI が従来のユーティリティのオペレーションをどのように変革し、効率性、信頼性、顧客ニーズへの対応力を高めることができるのかを示しています。数学的な精度と実用的な要件を組み合わせることで、このソリューションは、ユーティリティ分野におけるサービス中断時の対応管理における新たな基準を確立します。その結果、対応時間の短縮、精度の改善、ユーティリティと顧客の双方にとってのより良い成果が実現されます。 PwC の Global and US Commercial Technology and Innovation Officer である Matt Wood 氏は次のように述べています: 「PwC では、クライアントが自信をもって AI のパイロットから本番に移行するのをサポートしています。特に、一歩間違えればコストが金銭的な損失では済まない、規制の厳しい業界においてはなおさらです。自動推論チェックでの AWS とのコラボレーションは、責任ある AI における画期的な進歩です。数学的に評価された安全対策が、Amazon Bedrock のガードレールに直接組み込まれるようになったのです。弊社は AWS のリリースコラボレーターとして、信頼が単なる特徴量ではなく必須要件となる、製薬、ユーティリティ、クラウドコンプライアンスなどの分野において、このイノベーションを実現できることを誇りに思います」 知っておくべきこと Amazon Bedrock のガードレール の自動推論チェックは、本日より、米国東部 (オハイオ、バージニア北部)、米国西部 (オレゴン)、欧州 (フランクフルト、アイルランド、パリ) の AWS リージョン で一般提供が開始されました。 自動推論チェックでは、処理したテキストの量に基づいて料金をお支払いいただきます。詳細については、「 Amazon Bedrock の料金 」をご覧ください。 詳細を確認し、セキュアかつ安全な AI アプリケーションを構築するには、 技術ドキュメント と GitHub コードサンプル をご覧ください。 Amazon Bedrock コンソールに直接アクセスするには、こちらのリンク をクリックしてください。 このプレイリストの動画 には、自動推論チェックの概要、詳細なプレゼンテーション、ならびにポリシーの作成、テスト、および改良に関する実践的なチュートリアルが含まれています。これはプレイリストの 2 番目の動画で、私の同僚の Wale がこの機能についてわかりやすくご紹介しています。 原文は こちら です。 – Danilo

AWS は、業界で最も先進的な 基盤モデル (FM) の提供に努めており、業界をリードする AI イノベーターによる画期的なモデルをより幅広く採用できるように注力し続けています。これにより、常に最新の進歩を活用してビジネスの成長を促進することができます。 8 月 5 日、 Amazon Bedrock と Amazon SageMaker JumpStart で 2 つの新しい オープンウェイトの OpenAI モデル が利用可能になったことを発表できることを嬉しく思います。OpenAI gpt-oss-120b および gpt-oss-20b モデルは、テキスト生成と推論タスク向けに設計されており、開発者や組織がインフラストラクチャとデータを完全に制御して AI アプリケーションを構築するための新しいオプションを提供します。 オープンウェイトモデルは、コーディング、科学的分析、数学的問題解決に優れており、主要な代替モデルと同等のパフォーマンスを発揮します。どちらのモデルも 128K のコンテキストウィンドウをサポートし、特定のユースケース要件に合わせて調整可能な推論レベル (低/中/高) を提供します。モデルは外部ツールをサポートして機能を強化でき、たとえば Strands Agents のようなフレームワークを使用して、エージェントワークフローで利用することが可能です。 AWS では、Amazon Bedrock と Amazon SageMaker JumpStart を利用することで、OpenAI のオープンウェイトモデルを含む主要な AI 企業の数百もの FM にアクセスして、自由にイノベーションを起こすことができます。モデルの豊富なラインナップにより、いつでも最適なモデルの AI ワークロードを選ぶことができます。 Amazon Bedrock を利用すると、コードを書き換えることなく、さまざまなモデルを試したり、機能を組み合わせたり、プロバイダーを切り替えたりできます。これにより、 モデルの選択 を戦略的な利点に変え、新しいイノベーションの登場に合わせて AI 戦略を継続的にアップデートすることができます。提供開始時から、新しいモデルは OpenAI と互換性のあるエンドポイントを介して Bedrock で利用可能です。OpenAI SDK をこのエンドポイントに接続するか、Bedrock InvokeModel や Converse API を使用して利用できます。 SageMaker JumpStart を使用すると、ユースケースに合わせてモデルを迅速に評価、比較、カスタマイズできます。その後、SageMaker AI コンソールまたは SageMaker Python SDK を使用して、元のモデルまたはカスタマイズされたモデルを本番環境にデプロイできます。 実際にどのように機能するか見てみましょう。 Amazon Bedrock における OpenAI のオープンウェイトモデル入門 Amazon Bedrock コンソール では、ナビゲーションペインの [ 設定と学習 ] セクションから [ モデルアクセス ] を選択します。次に、このページに表示されている 2 つの OpenAI モデルに移動し、アクセスをリクエストします。 アクセスできるようになったので、 チャット/テスト のプレイグラウンドを使用してモデルのテストと評価を行っています。カテゴリとして OpenAI を選択し、次に gpt-oss-120b モデルを選択します。 このモデルを使用して、次のサンプルプロンプトを実行します。 ある家族が来年の休暇のために 5,000 USD を貯金します。年間 2% の利息が付く普通預金口座、または年間 4% の利息で休暇まで預金を引き出すことができない定期預金口座に預金することができます。その年の急な出費として 1,000 USD を確保しておく場合、休暇用の資金を最大限に活用するためには、2 つのオプションの間で資金をどのように分配すべきでしょうか。 このプロンプトは、結果の生成に使用された一連の考え方を含む出力を生成します。 モデルを OpenAI SDK で使用するには、API エンドポイント (ベース URL) を設定し、認証に Amazon Bedrock API キー を使用します。たとえば、米国西部 (オレゴン) の AWS リージョンのエンドポイント ( us-west-2 ) と Amazon Bedrock API キーを使用するように次の環境変数を設定しました。 export OPENAI_API_KEY="<my-bedrock-api-key>" export OPENAI_BASE_URL="https://bedrock-runtime.us-west-2.amazonaws.com/openai/v1" 次に、OpenAI Python SDK を使用してモデルを呼び出します。 client = OpenAI() response = client.chat.completion.create( messages=[{ "role": "user", "content": "Hello, how are you?" }], model="openai.gpt-oss-120b-1:0", stream=True ) for item in response: print(item) AI エージェントを構築するには、Amazon Bedrock API または OpenAI API をサポートする任意のフレームワークを選択できます。たとえば、Amazon Bedrock API を使用する Strands Agents の開始コードは次のとおりです。 from strands import Agent from strands.models import BedrockModel from strands_tools import calculator model = BedrockModel( model_id="openai.gpt-oss-120b-1:0" ) agent = Agent( model=model, tools=[calculator] ) agent("Tell me the square root of 42 ^ 3") コード ( app.py ファイル) を保存し、依存関係をインストールして、エージェントをローカルで実行します。 pip install strands-agents strands-agents-tools python app.py エージェントに問題がなければ、 Amazon Bedrock AgentCore が提供する機能 (フルマネージド型のサーバーレスランタイム、メモリおよび ID 管理など) を使用して本番環境にデプロイできます。 Amazon SageMaker JumpStart における OpenAI のオープンウェイトモデル入門 Amazon SageMaker AI コンソール では、 SageMaker Studio で OpenAI のオープンウェイトモデルを使用できます。初めてこれを行う際には、SageMaker ドメインを設定する必要があります。よりシンプルなシングルユーザー向けまたは組織用に設定するオプションがあります。これらのテストでは、シングルユーザー設定を使用します。 SageMaker JumpStart モデルビューでは、 gpt-oss-120b モデルまたは gpt-oss-20b モデルの詳細な説明にアクセスできます。 gpt-oss-20b モデル を選択し、そのモデルをデプロイします。次のステップでは、インスタンスタイプと初期インスタンス数を選択します。数分後、デプロイによってエンドポイントが作成されることで、SageMaker Studio での呼び出しや、任意の AWS SDK の使用が可能になります。 詳細については、AWS AI ブログの OpenAI の GPT OSS モデルが SageMaker JumpStart で利用可能に をご覧ください。 知っておくべきこと 新しい OpenAI のオープンウェイトモデル は米国西部 (オレゴン) AWS リージョン の Amazon Bedrock で利用可能になりました。一方、 Amazon SageMaker JumpStart は、これらのモデルを米国東部 (オハイオ、バージニア北部) とアジアパシフィック (ムンバイ、東京) でサポートしています。 各モデルには、思考過程をすべて出力する機能が備わっており、モデルの推論プロセスを詳細に把握できます。この透明性は、解釈可能性や検証の水準が高いアプリケーションにおいて、特に役立ちます。 これらのモデルでは、特定のニーズに合わせて自由に変更、調整、カスタマイズできます。この柔軟性により、独自のユースケースに合わせたモデルのファインチューニング、既存のワークフローへの統合、さらにこれを基に構築した業界やアプリケーションに合わせた新しい特殊なモデルの作成が可能になります。 これらのモデルには、包括的な評価プロセスと安全対策が施されており、セキュリティと安全性が核となっています。モデルは標準の GPT-4トークナイザーとの互換性があります。 どちらのモデルも、Amazon Bedrock のサーバーレスエクスペリエンスを使用する場合でも、SageMaker JumpStart の広範な 機械学習 (ML) 開発機能を使用する場合でも、お好みの環境で使用できます。モデルとサービスの使用に関連するコストについては、 Amazon Bedrock の料金表 と Amazon SageMaker AI の料金表 ページを参照してください。 詳細については、Amazon Bedrock のドキュメントにある モデルのパラメータ や チャット補完 API を参照してください。 Amazon Bedrock コンソール または Amazon SageMaker AI コンソール で AWS で OpenAI のオープンウェイトモデルを今すぐ利用開始しましょう。 – Danilo 原文は こちら です。

8 月 5 日、 Amazon Elastic VMware Service (Amazon EVS) の一般提供開始の開始を発表します。これは、 VMware Cloud Foundation (VCF) 環境を Amazon Virtual Private Cloud (Amazon VPC) 内で直接実行できるようにする新しい AWS サービスです。Amazon EVS を利用すると、ガイド付きワークフローを使用して、わずか数時間で完全に機能する VCF 環境をデプロイできます。また、認定された Amazon Elastic Compute Cloud (Amazon EC2) ベアメタルインスタンスで VMware ワークロードを実行し、 Amazon FSx for NetApp ONTAP などの AWS サービスとシームレスに統合できます。 オンプレミスで VMware ワークロードを実行している多くの組織は、改善されたスケーラビリティ、信頼性、クラウドサービスへのアクセスから恩恵を享受するためにクラウドへの移行を望んでいますが、これらのワークロードの移行には、アプリケーションとインフラストラクチャの設定の大幅な変更が必要になることがよくあります。Amazon EVS を利用すると、お客様は、アプリケーションを再設計したり、確立されたプラクティスを変更したりすることなく、既存の VMware の専門知識とツールを引き続き使用できます。そのため、移行プロセスが簡素化されると同時に、AWS の規模、信頼性、幅広いサービスへのアクセスも提供されます。 Amazon EVS を利用すると、Amazon VPC で VMware ワークロードを直接実行できます。これにより、AWS インフラストラクチャ上にいながら、環境を完全に制御できます。オンプレミスネットワークを拡張し、IP アドレスや運用ランブックを変更することなくワークロードを移行できるため、複雑さとリスクが軽減されます。 主な機能と特徴量 Amazon EVS は、VMware ワークロードの移行と管理のエクスペリエンスを効率化するために設計された包括的な一連の機能を提供します。このサービスは、リプラットフォームやハイパーバイザーの変更を必要とせずにワークロードのシームレスな移行を可能にするため、AWS に移行しながら、既存のインフラストラクチャに対する投資を維持できます。 AWS マネジメントコンソール での直感的なガイド付きワークフローを通じて、EVS 環境を効率的にプロビジョニングおよび設定できるため、AWS へのワークロード移行の複雑さが大幅に軽減されます。 Amazon EVS を利用すると、AWS 上で実行される完全に機能する VCF 環境を数時間でデプロイできます。このプロセスにより、従来のデプロイ中に頻繁に発生する多くの手動ステップと潜在的な設定エラーが排除されます。さらに、Amazon EVS を利用すると、AWS 上の仮想化スタックを最適化できます。VCF 環境は VPC 内で実行されるため、環境と関連付けられた管理アプライアンスに対する完全なルートアクセスが付与されます。また、 Amazon FSx for NetApp ONTAP や Pure Cloud Block Store などの外部ストレージ、 Veeam Backup and Replication などのバックアップソリューションなど、サードパーティーソリューションを統合することも可能です。 このサービスでは、自己管理することも、AWS パートナーと連携して環境を構築、管理、運用することもできます。これにより、全体的な目標に合わせてアプローチを柔軟に調整できます。 新しい VCF 環境のセットアップ 組織は、新しい VCF 環境を作成する前に必要なすべての前提条件が確実に満たされているようにすることで、セットアッププロセスを合理化できます。これらの前提条件には、アクティブな AWS アカウントがあること、適切な AWS Identity and Access Management (IAM) 許可が設定されていること、十分な CIDR スペースと 2 つの Route Server エンドポイント (各エンドポイントに独自のピアがある必要があります) を備えた Amazon VPC がセットアップされていることが含まれます。さらに、お客様は、VMware Cloud Foundation ライセンスキーを用意し、i4i.metal インスタンス専用の Amazon EC2 キャパシティ予約を確保するとともに、VLAN サブネット情報の計画を準備する必要があります。 円滑なデプロイプロセスを実現するのに役立つよう、EVS ホームページからアクセスできる 開始方法ハブ を提供しているほか、 ドキュメント では包括的なガイドをご覧いただけます。これらの準備ステップに従うことで、セットアップの遅延を回避し、環境を正常に構築できます。 Amazon EVS を利用して新しい VCF 環境をセットアップするプロセスを順に見ていきましょう。 VCF ライセンスを購入する際に Broadcom によって割り当てられたサイト ID と、ライセンスキーを提供する必要があります。初期デプロイを成功させるには、少なくとも 256 コアをカバーするのに十分なライセンスを有していることを確認する必要があります。これは、少なくとも 4 つの i4i.metal インスタンス (各インスタンスは 64 個の物理コアを提供します) を意味します。 このライセンス要件は、最適なパフォーマンスを維持し、必要なインフラストラクチャ仕様を環境が満たしているようにするのに役立ちます。これらの要件を事前に確認することで、デプロイの遅延を回避し、円滑なセットアッププロセスを実現できます。 必要な詳細をすべて入力すると、ホストの詳細を指定するように求められます。これらは、VCF 環境がデプロイされる基盤となる Amazon EC2 インスタンスです。 各ホストインスタンスの詳細を入力したら、ネットワーキングと管理アプライアンスの DNS の詳細を設定する必要があります。Amazon EVS で新しい VCF 環境を作成する方法の詳細については、 こちらのドキュメント をご覧ください。 VCF 環境を作成すると、AWS コンソールを通じてすべてのホストと設定の詳細を確認できます。 知っておくべき追加情報 Amazon EVS は現在、VCF バージョン 5.2.1 をサポートしており、i4i.metal インスタンスで実行されます。今後のリリースでは、デプロイのためにより高い柔軟性が提供されるよう、VCF バージョン、ライセンスオプション、およびインスタンスタイプのサポートが拡張される予定です。 Amazon EVS は柔軟なストレージオプションを提供します。Amazon EVS のローカルインスタンスストレージは、VMware の vSAN ソリューションを利用しており、複数の ESXi ホストにまたがるローカルディスクを単一の分散データストアにプールします。ストレージをスケールするために、外部の Network File System (NFS) または iSCSI ベースのストレージソリューションを活用できます。例えば、Amazon FSx for NetApp ONTAP は、NFS データストアまたは iSCSI 経由の共有ブロックストレージとして使用するのに特によく適しています。 さらに、Amazon EVS を利用すると、オンプレミス環境を AWS に簡単に接続できます。Direct Connect 接続またはトランジットゲートウェイを終端とする VPN を使用して、オンプレミスの vSphere 環境から Amazon EVS に接続できます。また、Amazon EVS は、VLAN サブネットから VM への基盤となる接続を管理します。 AWS は、Amazon EVS によってデプロイされるすべての AWS サービスについて包括的なサポートを提供し、直接的なカスタマーサポートを提供するとともに、高度なサポートニーズについては Broadcom と連携します。お客様は、サービスを実行しているアカウントで AWS ビジネスサポート を維持する必要があります。 利用可能なリージョンと料金 Amazon EVS は現在、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、欧州 (フランクフルト)、欧州 (アイルランド)、アジアパシフィック (東京) の AWS リージョン で一般提供されています。近日中に他のリージョンでもご利用いただけるようになる予定です。料金は、使用した Amazon EC2 インスタンスと AWS リソースに基づいて算出され、最低料金や初期費用はありません。 詳細については、 Amazon EVS の製品ページ にアクセスしてください。 原文は こちら です。

このブログは 2025 年 7 月 15 日に Channy Yun によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 本日、 Amazon S3 Vectors のプレビュー版を発表します。これは、ベクトルのアップロード、保存、クエリの総コストを最大 90 % 削減できる、耐久性に優れたベクトルストレージソリューションです。Amazon S3 Vectors は、大規模なベクトルデータセットの保存をネイティブにサポートし、1 秒未満のクエリパフォーマンスを実現する初めてのクラウドオブジェクトストアです。これにより、企業が AI 対応データを大規模に低コストで保存できるようになります。 ベクトル検索は、 生成 AI アプリケーションで使用されている新しい手法で、距離または類似度メトリックを使用してベクトル表現を比較することにより、特定のデータに類似したデータポイントを検索します。ベクトルは 埋め込みモデル から作成された非構造化データを数値で表現したものです。ドキュメント内のフィールドの埋め込みモデルを使用してベクトルを生成し、ベクトルを S3 Vectors に保存してセマンティック検索を行います。 S3 Vectors では、ベクトルバケットが導入されました。ベクトルバケットは、インフラストラクチャをプロビジョニングせずにベクトルデータを保存、アクセス、クエリするための専用の API セットを備えた新しいバケットタイプです。S3 ベクトルバケットを作成すると、ベクトルデータをベクトルインデックス内に整理し、データセットに対して類似検索クエリを簡単に実行できるようにします。各ベクトルバケットには最大 10,000 個のベクトルインデックスを含めることができ、各ベクトルインデックスには数千万個のベクトルを格納できます。 ベクトルインデックスを作成した後、ベクトルデータをインデックスに追加するときに、メタデータをキーと値のペアとして各ベクトルに添付して、日付、カテゴリ、ユーザー設定などの一連の条件に基づいて今後のクエリをフィルタリングすることもできます。時間の経過とともにベクトルの書き込み、更新、削除を行うと、S3 Vectors は、データセットが拡大したり進化したりしても、ベクトルストレージのコストパフォーマンスが可能な限りベストになるように、ベクトルデータを自動的に最適化します。 S3 Vectorsは、 Amazon SageMaker Unified Studio を含む Amazon Bedrock Knowledge Bases ともネイティブに統合されており、費用対効果の高い Retrieval-Augmented Generation (RAG) アプリケーションを構築できます。 Amazon OpenSearch Service との統合により、クエリ頻度の低いベクトルを S3 Vectors に保存することでストレージコストを削減でき、需要が高まったときにそれらを OpenSearch にすばやく移動したり、リアルタイムで低レイテンシーの検索操作をサポートすることができます。 S3 Vectors を使用すると、画像、動画、ドキュメント、音声ファイルなどの大量の非構造化データを表すベクトル埋め込みを経済的に保存できるようになり、セマンティック検索、類似検索、RAG、ビルドエージェントメモリなどのスケーラブルな生成 AI アプリケーションが可能になります。また、ベクトルデータベースの管理に伴う複雑さやコストをかけずに、パーソナライズされた推奨事項、自動コンテンツ分析、インテリジェントな文書処理など、さまざまな業界のユースケースをサポートするアプリケーションを構築できます。 S3 Vectors の動作 ベクトルバケットを作成するには、 Amazon S3 コンソール の左側のナビゲーションペインで Vector buckets を選択し、 Create vector bucket を選択します。 ベクトルバケット名を入力し、暗号化タイプを選択します。暗号化タイプを指定しない場合、Amazon S3 は新しいベクトルの暗号化の基本レベルとして Amazon S3 管理キー (SSE-S3) を使用してサーバー側の暗号化を適用します。 AWS Key Management Service (AWS KMS) キー (SSE-KMS) を使用してサーバー側の暗号化を選択することもできます。ベクトルバケットの管理の詳細については、Amazon S3 ユーザーガイドの S3 ベクトルバケット をご覧ください。 これで、ベクトルインデックスを作成して、作成したベクトルバケット内でベクトルデータを保存およびクエリできます。 ベクトルインデックス名と、インデックスに挿入するベクトルの次元を入力します。このインデックスに追加されるすべてのベクトルは、完全に同じ数の値を持つ必要があります。 Distance metric では、 Cosine または Euclidean を選択できます。ベクトル埋め込みを作成する場合、より正確な結果を得るには、埋め込みモデルの推奨された距離メトリックを選択してください。 Create vector index を選択すると、ベクトルの挿入、一覧表示、クエリを行うことができます。 ベクトル埋め込みをベクトルインデックスに挿入するには、 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS SDKs 、または Amazon S3 REST API を使用できます。非構造化データ用のベクトル埋め込みを生成するには、Amazon Bedrock が提供する埋め込みモデルを使用できます。 最新の AWS Python SDK を使用している場合は、次のコード例を使用して Amazon Bedrock を使用してテキストのベクトル埋め込みを生成できます。 # Generate and print an embedding with Amazon Titan Text Embeddings V2. import boto3 import json # Create a Bedrock Runtime client in the AWS Region of your choice. bedrock = boto3 . client ( "bedrock-runtime" , region_name = "us-west-2" ) # The text strings to convert to embeddings . texts = [ "Star Wars: A farm boy joins rebels to fight an evil empire in space" , "Jurassic Park: Scientists create dinosaurs in a theme park that goes wrong" , "Finding Nemo: A father fish searches the ocean to find his lost son" ] embeddings = [ ] #Generate vector embeddings for the input texts for text in texts : body = json . dumps ( { "inputText" : text } ) # Call Bedrock's embedding API response = bedrock . invoke_model ( modelId = 'amazon.titan-embed-text-v2:0' , # Titan embedding model body = body ) # Parse response response_body = json . loads ( response [ 'body' ] . read ( ) ) embedding = response_body [ 'embedding' ] embeddings . append ( embedding ) Python これで、ベクトル埋め込みをベクトルインデックスに挿入し、クエリー埋め込みを使用してベクトルインデックスのベクトルをクエリできるようになりました。 # Create S3Vectors client s3vectors = boto3 . client ( 's3vectors' , region_name = 'us-west-2' ) # Insert vector embedding s3vectors . put_vectors ( vectorBucketName = "channy-vector-bucket" , indexName = "channy-vector-index" , vectors = [ { "key" : "v1" , "data" : { "float32" : embeddings [ 0 ] } , "metadata" : { "id" : "key1" , "source_text" : texts [ 0 ] , "genre" : "scifi" } } , { "key" : "v2" , "data" : { "float32" : embeddings [ 1 ] } , "metadata" : { "id" : "key2" , "source_text" : texts [ 1 ] , "genre" : "scifi" } } , { "key" : "v3" , "data" : { "float32" : embeddings [ 2 ] } , "metadata" : { "id" : "key3" , "source_text" : texts [ 2 ] , "genre" : "family" } } ] , ) #Create an embedding for your query input text # The text to convert to an embedding. input_text = "List the movies about adventures in space" # Create the JSON request for the model. request = json . dumps ( { "inputText" : input_text } ) # Invoke the model with the request and the model ID, e.g., Titan Text Embeddings V2. response = bedrock . invoke_model ( modelId = "amazon.titan-embed-text-v2:0" , body = request ) # Decode the model's native response body. model_response = json . loads ( response [ "body" ] . read ( ) ) # Extract and print the generated embedding and the input text token count. embedding = model_response [ "embedding" ] # Performa a similarity query. You can also optionally use a filter in your query query = s3vectors . query_vectors ( vectorBucketName = "channy-vector-bucket" , indexName = "channy-vector-index" , queryVector = { "float32" : embedding } , topK = 3 , filter = { "genre" : "scifi" } , returnDistance = True , returnMetadata = True ) results = query [ "vectors" ] print ( results ) Python ベクトルインデックスへのベクトルの挿入、ベクトルの一覧表示、クエリ、削除の詳細については、Amazon S3 ユーザーガイドの S3 ベクトルバケット と S3 ベクトルインデックス をご覧ください。さらに、S3 Vectors embed コマンドラインインターフェイス (CLI) を使用すると、Amazon Bedrock を使用してデータのベクトル埋め込みを作成し、1 つのコマンドで S3 ベクトルインデックスに保存してクエリすることができます。詳細については、 S3 Vectors Embed CLI GitHub リポジトリ を参照してください。 S3 Vectors を他の AWS サービスと統合 S3 Vectors は、Amazon Bedrock、Amazon SageMaker、Amazon OpenSearch Service などの他の AWS サービスと統合することで、ベクトル処理機能を強化し、AI ワークロード向けの包括的なソリューションを提供します。 S3 Vectors を使用して Amazon Bedrock ナレッジベースを作成 Amazon Bedrock ナレッジベースで S3 Vectors を使用すると、RAG アプリケーションのベクトルストレージのコストを簡素化および削減できます。 Amazon Bedrock コンソール でナレッジベースを作成する場合、ベクトルストアのオプションとして S3 ベクトルバケットを選択できます。 Step 3 では、 Vector store creation method を選択して S3 ベクトルバケットとベクトルインデックスを作成するか、以前に作成した既存の S3 ベクトルバケットとベクトルインデックスを選択できます。 詳細な手順については、Amazon Bedrock ユーザーガイドの Create a knowledge base by connecting to a data source in Amazon Bedrock Knowledge Bases を参照してください。 Amazon SageMaker Unified Studio を使用する Amazon Bedrock を使用して生成 AI アプリケーションを構築すると、Amazon SageMaker Unified Studio で S3 Vectors を使用してナレッジベースを作成および管理できます。SageMaker Unified Studio は次世代の Amazon SageMaker で利用でき、Amazon Bedrock ナレッジベースを使用する生成 AI アプリケーションの構築やテキスト送信など、データと AI の統合開発環境を提供します。 生成 AI アプリケーションを構築する時に、Amazon Bedrock で作成された S3 Vectors を使用してナレッジベースを選択できます。詳細については、Amazon SageMaker Unified Studio ユーザーガイドの Add a data source to your Amazon Bedrock app をご覧ください。 S3 ベクトルデータを Amazon OpenSearch サービスにエクスポートする 長期的に利用するベクトルデータを Amazon S3 にコスト効率よく保存する一方で、優先度高く利用したいベクトルを OpenSearch にエクスポートしてリアルタイムのクエリパフォーマンスを実現する階層型戦略を採用することで、コストとパフォーマンスのバランスを取ることができます。 この柔軟性により、組織は OpenSearch の高パフォーマンス (高 QPS、低遅延) を利用して、製品の推奨や不正検出などの重要なリアルタイムアプリケーションにアクセスでき、時間的制約の少ないデータを S3 Vectors に保存できます。 ベクトルインデックスをエクスポートするには、 Advanced search export を選択し、次に Amazon S3 コンソールで Export to OpenSearch を選択します。 次に、OpenSearch ベクトルエンジンに S3 ベクトルインデックスをエクスポートするためのテンプレートを含む Amazon OpenSearch サービス統合コンソール が表示されます。事前に選択した S3 ベクトルソースとサービスアクセスロールを使用して エクスポート を選択します。 これで、新しい OpenSearch Serverless コレクションを作成し、S3 ベクトルインデックスから OpenSearch k-NN インデックスにデータを移行する手順が開始されます。 左側のナビゲーションペインで Import history を選択します。S3 ベクトルインデックスのベクトルデータを OpenSearch Serverless コレクションにコピーするために作成された新しいインポートジョブが表示されます。 ステータスが Complete に変わったら、 新しい OpenSearch Serverless コレクションに接続して 、 新しい OpenSearch knn インデックスをクエリできます 。 詳細については、Amazon OpenSearch サービス開発者ガイドの Creating and managing Amazon OpenSearch Serverless collections をご覧ください。 今すぐご利用いただけます Amazon S3 Vectors 、および Amazon Bedrock、Amazon OpenSearch Service、Amazon SageMaker との統合は、現在、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、ヨーロッパ (フランクフルト)、およびアジアパシフィック (シドニー) の各リージョンでプレビュー段階にあります。 今すぐ Amazon S3 コンソール で S3 Vectors を試してみて、 AWS re:Post for Amazon S3 か通常の AWS サポートの連絡先を通じてフィードバックを送ってください。 この記事を読んでいただきありがとうございました。 翻訳はクラウドサポートエンジニアの黒川が担当しました。

この記事は Resolve imperfect data with advanced rule-based fuzzy matching in AWS Entity Resolution (記事公開日 : 2025 年 7 月 30 日) を翻訳したものです。 様々な業界の企業は、顧客情報を正確に把握することで、パーソナライズされた顧客体験と最適化された広告キャンペーンの提供を目指しています。しかし、断片化され、一貫性がなく、しばしば乱雑なデータセット間でレコードを確実にマッチングすることは、困難で複雑な作業です。 従来のルールベースのマッチング技術を使用して完全一致のレコードを照合しようとする組織は、名前、メールアドレス、住所のわずかな違い (例 : Jon Smith と Jonathan Smith、または 123 Main St., Apt. 4B と 123 Main Street #4B) により、重要なつながりを見逃してしまうことがあります。このようなミスマッチは、キャンペーンのパフォーマンス低下、オーディエンスリーチの制限、広告費の無駄遣いにつながる可能性があります。 これらの課題に対応するために、企業は AWS Entity Resolution を使用して、複数のアプリケーション、チャネル、データストアにまたがる関連レコードのマッチング、リンク、情報の付加を行っています。これにより、顧客をより良く理解し、エンゲージメントを高めるためのデータ品質が向上します。AWS Entity Resolution は、ルールベースのマッチングと機械学習 (ML) ベースのマッチングを含む、複数の柔軟で設定可能なマッチング技術を提供します。 ルールベースのマッチング は、複数のフィールドにわたる厳密な条件を使用して、決定論的なロジックを定義します。例えば、メールアドレスと姓でマッチングを行うようなルールを設定することができます。この手法は高い精度と完全な透明性を提供し、事前に定義されたルールによる説明可能性が重要なユースケースで特に好まれます。 機械学習ベースのマッチング は、事前に学習させたモデルを活用し、データ内のパターンを自動的に学習して、データにノイズがある場合や一貫性がない場合、あるいは主要な識別子が不足している場合でも、適切なマッチングを特定することができます。この手法は設定の手間を軽減し、様々なタイプのデータに適応できる特徴があり、決定論的なルールでは見落としてしまう可能性のあるケースでも、より高い検出率を実現します。 本日、AWS Entity Resolution で高度なルールベースファジーマッチング機能を 発表しました 。これにより、Levenshtein Distance (レーベンシュタイン距離)、Cosine Similarity (コサイン類似度)、Soundex (サウンデックス) などのファジーマッチングアルゴリズムを使用してレコードをマッチングできるようになります。 この機能は、表記の揺れや入力ミスに対する許容性を持たせることで、特別な前処理を必要とせずに、より正確で柔軟な本人確認を可能にします。マーケターにとってこれは、マッチング率の向上、パーソナライゼーションの強化、そして効果的なクロスチャネルでのターゲティングやリターゲティング、効果測定のために必要な統合的な顧客視点の構築を実現できることを意味します。 業界のユースケース 高度なルールベースファジーマッチングは、様々な業界のお客様が直面する複雑なデータ統合の課題解決に役立ちます。具体的には以下のような例があります : 広告・マーケティング分野 : 識別子が不完全であったり、わずかなズレがある場合でも、異なるデータセット間でレコードをマッチングすることで、リーチや頻度分析の精度を向上させることができます。 小売・消費財分野 : 顧客関係管理 (CRM) データ内の誤字や異なる表記を含むレコードを紐付けることができます。 金融サービス分野 : 本人確認 (KYC) の検証、不正検知、またはマーケティング目的のために、本人確認データの解決を行うことができます。 高度なルールベースファジーマッチングの概要 AWS Entity Resolution の高度なルールベースファジーマッチングは、ルールベースと機械学習ベースのアプローチの間のギャップを埋めるものです。従来の厳密なルールベースの枠組みに確率的なマッチングを導入し、ユーザーがファジーマッチングアルゴリズム (レーベンシュタイン距離やコサイン類似度など) を使用して文字列フィールドの類似度のしきい値を設定できるようにします。これにより、ルールの説明可能性とコントロール性を保ちながら、確率的マッチングの柔軟性を実現する中間的なアプローチを提供します。 AWS Entity Resolution では、以下のファジーマッチングアルゴリズムを利用できます : レーベンシュタイン距離 : タイプミスや文字の小さな編集を検出し、名前やメールアドレス、スペルミスのあるエントリーをマッチングします (例 : john@gmail.co と jon@gmail.com の比較) 。 サウンデックス : 音声的な類似性を評価し、似た発音だが異なるスペルの名前をマッチングします (例 : Mary と Marie の比較) 。 コサイン類似度 : 単語やトークンの重なりに基づいて類似性を測定します。これは会社名や、語順が異なる、または部分的に一致するフリーテキストフィールドのマッチングに使用されます (例 : Acme Inc. と Acme Corporation の比較) 。 お客様は、ノイズを含むデータや一貫性のないデータ間でより柔軟で正確なマッチングを可能にするために、アルゴリズムを使用してカスタムの類似度のしきい値を定義できるようになりました。これは、ルールベースシステムのコントロール性と、機械学習ベースの近似マッチングの適応性を組み合わせたもので、説明可能性を損なうことなくマッチング率を向上させることができます。 お客様は、関連するファジーマッチングアルゴリズムでルール条件を設定し、必要に応じて適切なしきい値を設定することができます (図 1 参照) 。 図 1 : 高度なマッチングアルゴリズム 仕組み AWS Entity Resolution の新機能をソリューションで使用するには、まず、複数のアプリケーション、チャネル、データストアにまたがるレコードがデータレイク (Amazon Simple Storage Service ( Amazon S3 ) バケット) で利用可能な状態になっていることを確認します。 AWS Glue crawler を使用して Amazon S3 のデータの内容を自動的に判別し、 AWS Glue Data Catalog 内のメタデータテーブルを更新します。 AWS Entity Resolution は、サービス内で定義したルールを使用して、データセットを適切なマッチンググループに解決します。AWS Entity Resolution からの出力は Amazon S3 バケットで利用可能です。図 2 は、このソリューションを示すハイレベルのアーキテクチャ図です。 図 2 : ハイレベルアーキテクチャ 使用例の説明 AWS Entity Resolution のファジーマッチングルールを説明するために、テストデータセットを作成しました。このデータセットは架空の顧客情報で構成されており、CSV ファイル形式で Amazon S3 バケットにアップロードされています。 図 3 : サンプルデータセット 図 3 のデータセットには 4 つの個別のエンティティが含まれています。ただし、これらの個別エンティティには、名前、住所、電話番号フィールドが変更された複数のバリエーションも含まれています。 サンプルデータの問題を解決するために、以下の手順を実行しました : AWS Entity Resolution でサンプルデータのスキーマを解決するには、まず AWS Glue crawler を使用して AWS Glue Data Catalog テーブルを作成する必要があります。このテーブルは、入力されるクリックストリームデータを保持する Amazon S3 バケットを指します。 AWS Entity Resolution 内で スキーママッピング を定義し、サービスにデータの解釈方法を指示する必要があります。 スキーママッピング作成画面で、ソースデータを表す適切な AWS Glue データベースとテーブル を選択します。この例では、”fuzzymatchingaerdemo” を含むデータベース “fuzzymatchingdemo” を使用します。このデータベースのテーブルは、サンプルデータセットを含む Amazon S3 バケットで AWS Glue crawler を実行した際に作成されました。 図 4 : スキーママッピング – セットアップ ドロップダウンから一意の ID ( Unique ID ) を選択します (図 5 参照) 。一意の ID カラムは、データの各行を個別に参照する必要があります。これはデータベースの主キーカラムのようなものと考えてください。この場合、CSV ファイル内の uniqueid がそれに該当します。 下にスクロールし、解決に必要な 入力フィールド を選択します (図 5 参照) 。この場合、address (住所) 、first_name (名) 、last_name (姓) 、phone の各カラムが選択されています。 図 5 : スキーママッピング – 入力データフィールド セットアップ 次に、選択した入力フィールドを適切なデータタイプとマッチキーにマッピングします。入力タイプ (名前、メール、住所など) を指定することで、AWS Entity Resolution に各カラムのデータの解釈方法を指示し、必要に応じてそのカラムに適用する正規化ルールを設定できます。 マッチキー は、どのフィールドが類似しているか、そしてマッチング処理中に単一のユニットとして扱う必要があるかを決定します。 図 6 : スキーママッピング – フィールドのマッピング 「 次へ 」をクリックしてグループの作成に進みます。グループとは、単一の「名前」カラムの下にある関連する入力フィールド (名と姓など) のセットです。これにより、AWS Entity Resolution はマッチングや類似度の計算時に、個別ではなくまとめて比較することができ、より正確なマッチングが可能になります。 図 7 : スキーママッピング – グループフィールド グループの設定が完了したら、「 次へ 」をクリックして確認と作成画面に進みます。 すべての設定を確認し、「 スキーママッピングの作成 」をクリックします。これによりスキーママッピングが作成されます。 スキーママッピングが作成されたら、次はマッチングワークフローを作成します。マッチングワークフローは、ソース間でレコードをマッチングおよびリンクするために必要な入力、関連するマッチング手法、ルール、または機械学習を定義するのに役立ちます。マッチングワークフローを作成するには、左側のメニューにあるワークフローのドロップダウンから「 マッチング 」を選択し、「 マッチングワークフローの作成 」をクリックします。マッチングワークフローの詳細指定画面でワークフロー名を追加します。この例では「Fuzzymatchingdemo」としています。データ入力エリアで、前のステップで作成した適切な AWS Glue データベーステーブルとスキーママッピングを選択する必要があります (図 8 参照) 。 図 8 : マッチングワークフロー マッチング手法では、「 ルールベースマッチング 」を選択し、ファジーマッチングアルゴリズムを使用するためにルールタイプとして「 Advanced-new 」を選択します。 図 9 : マッチング手法 マッチングルールセクションでは、マッチングの目的に合わせて、ドロップダウンリストからマッチングアルゴリズムと適切なしきい値を選択し、ルールと条件を定義できます (図 10 参照) 。高度なマッチングルールビルダーでは、特定のフィールドに複数のマッチングアルゴリズムを適用することができます。「OR」条件を使用して2つの異なるアルゴリズムを組み合わせることで、マッチング解決の精度を最大化することができます。例えば、「名前」属性に対してサウンデックスとコサインの両方のアルゴリズムを適用することで、異なる種類の表記のバリエーションを捉えることができます。図 11 は、サンプルデータセットの重複を効果的に排除するために使用したルールを示しています。 図 10 : ファジーマッチング手法 セットアップ 図 11 : ファジーマッチングルール 最後のステップとして、ワークフローを作成する前に、すべての設定がマッチングの要件を正確に反映しているか確認し、「 作成して実行 」をクリックします。これによりマッチングワークフローが作成され、最初の処理が開始されます。 ジョブの完了までしばらく待つと (図 12 参照) 、ジョブメトリクスに処理された入力レコードの数と生成された一意のマッチ ID の数が表示されます。出力結果は設定された Amazon S3 バケットに書き込まれます。指定された出力用 S3 の場所に移動して出力ファイルをダウンロードし、結果を分析することができます。 図 12 : ファジーマッチングのジョブメトリクス 出力データ (図 13 参照) では、出力データの各レコードに AWS Entity Resolution が割り当てた MatchID が付与されます。マッチングレコードは、MatchRule で定義された条件を満たすデータセットから重複が排除されたエントリーを表します。MatchRule フィールドは、各マッチングレコードセットの生成に適用された具体的なルールを示しています。 図 13 : ファジーマッチングワークフローの出力 このチュートリアルで示したサンプルデータセットでは、AWS Entity Resolution のファジーマッチングワークフローは、関連するレコードをグループ化する 4 つの一意のマッチキーを生成しました。マッチングワークフローは、名前、住所、電話番号フィールドにバリエーションを含むレコードの重複を正常に排除し、4 つの個別のエンティティとして解決しました。 まとめ AWS Entity Resolution の高度なルールベースファジーマッチングは、カスタムコードを書くことなく、ファジーロジックを使用して現実世界の不完全なデータをマッチングするための柔軟性を提供します。広告、小売、金融、医療など、どの分野で働いているかに関わらず、この機能はデータに隠された関係性を見つけ出すのに役立ちます。お客様は、マッチングのためのファジーロジックに対して適切なしきい値を管理および設定することができます。 これは、ルールベースシステムのコントロール性と、機械学習ベースの近似マッチングの適応性を組み合わせたバランスの取れたマッチングアプローチです。説明可能性を損なうことなく、マッチング率を向上させることができます。 開始するには、 AWS Entity Resolution コンソール にアクセスし、高度なルールベースファジーマッチングを有効にして、今すぐインテリジェントなワークフローの構築を始めるか、 AWS の担当者 に連絡して、ビジネスの加速化に向けた支援方法についてご相談ください。 追加リソース AWS Entity Resolution Resources AWS Entity Resolution と Amazon Neptune を使用して顧客の 360 度ビューを作成 AWS Entity Resolution: Match and Link Related Records from Multiple Applications and Data Stores AWS Entity Resolution Workshops 顧客の統一ビューを構築する方法 Sid Patel Sid は、AWS 応用 AI (Applied AI) ソリューション内の顧客データ・インサイトチームのプロダクトリードです。AWS Entity Resolution や Amazon Connect Customer Profiles などのサービスを通じて、顧客アイデンティティとデータ統合に注力しています。 Archna Kulkarni Archna は、金融サービスとデータ変換技術を専門とする AWS のシニアソリューションアーキテクトです。AWS に入社する前は、フォーチュン 100 の金融サービス組織でデジタルトランスフォーメーションのエグゼクティブとして働いていました。Archna は AWS Entity Resolution、AWS Clean Rooms、Amazon Connect Customer Profiles などの AWS サービスを活用して、お客様のデータ統合と変革の取り組みを支援しています。 本稿の翻訳は、ソリューションアーキテクトの髙橋が担当しました。原文は こちら 。

このブログは “ Amazon Aurora DSQL for gaming use cases ” を翻訳したものです。 オンラインゲーム業界は、プレイヤーが即応的で、中断のないゲームプレイ、そして地理的に分散した地域間でのゲーム状態のシームレスな同期を期待するリアルタイムでグローバルに接続されたエコシステムへと進化しています。 現代のオンラインゲームは、何百万人もの同時接続プレイヤーをサポートし、リアルタイムのゲーム内取引を処理し、リーダーボード、マッチメイキング、プレイヤーのインベントリが常に最新の状態であることを保証する必要があります。これらすべてを低レイテンシーと強力な一貫性を維持しながら実現しなければなりません。 これらの要求に応えるため、ゲームバックエンドには、簡単にスケールするだけでなく、グローバルに分散した ACID 保証、高可用性、結合や集計などのリッチなリレーショナルクエリのサポートを提供するデータベースが必要です。 既存のリレーショナルデータベースや NoSQL データベースはスケーラビリティと可用性を提供していますが、これらの機能をグローバルな一貫性とトランザクションの整合性と組み合わせると、アーキテクチャの複雑さが増すことがよくあります。 Aurora DSQL は、グローバルに接続されたゲーム向けに、マルチリージョン間の整合性を標準で備え、SQL サポート、シームレスなスケーラビリティを備えた分散型サーバーレスリレーショナルデータベースを提供することで、この状況をシンプルにします。 本記事では、 Amazon Aurora DSQL がスケーラビリティ、強力な一貫性、そしてマルチリージョン高可用性を組み込みで提供することで、リアルタイムなマルチプレイヤーインタラクションからグローバルに一貫性のあるリーダーボードまで、現代のゲームのユースケースをどのように強化するかをご紹介します。 ゲームデータベースに対する高まる要求 オンラインゲームが複雑さとグローバルな展開を拡大するにつれて、バックエンドインフラストラクチャは高い同時実行性、リアルタイムの応答性、トランザクションの整合性をサポートするように進化する必要があります。 リレーショナルデータベースや NoSQL データベースは多くのゲームのニーズ（セッション管理、キャッシング、イベントトラッキングなど）に対応し続けていますが、一部のユースケース（グローバルなゲーム状態、プレイヤーインベントリ、ゲーム内購入など）では、地理的に分散したプレイヤー間で、より強力な一貫性と広範な連携が求められます。 予測不可能な負荷に対するスケーリング – 多くのシステムでは、プレイヤーアクティビティの大規模な急増に対応するために、事前計画、手動シャーディング、またはプロビジョニングが必要であり、ライブイベントやゲームのリリース時に運用上のオーバーヘッドが発生します。 一貫性とトランザクション保証 – 結果整合性は、リーダーボードやインベントリ更新のような速いペースのシナリオで問題を引き起こす可能性があります。これらのシナリオではタイミングと精度がユーザーエクスペリエンスに直接影響します。 リージョン間の可用性 – グローバルで中断のないゲームプレイを提供するには、高可用性を維持するためのカスタムフェイルオーバー戦略と慎重なレプリケーション設計が必要になることがよくあります。 Amazon Aurora DSQL は、グローバルに分散した ACID トランザクション、高可用性、豊富な SQL サポートを単一のサーバーレスアーキテクチャで組み合わせることで、これらの進化する要件に対応します。これにより、開発者はインフラストラクチャをシンプルにしながら、スケールに応じた一貫性のある応答性の高いゲームプレイ体験を提供できます。 Amazon Aurora DSQL アーキテクチャ Amazon Aurora DSQL は、スケーラビリティ、一貫性、可用性のバランスを取るように設計されており、ゲームアプリケーション向けの最適なデータベースソリューションとして位置づけられています。この主張を裏付ける Amazon Aurora DSQL のアーキテクチャの詳細を見ていきましょう。 次のアーキテクチャ図は、Amazon Aurora DSQL マルチリージョンのアクティブ-アクティブクラスターを示しています。 設計上、Amazon Aurora DSQL は、クラスターがデプロイされているすべてのリージョンでの読み取りと書き込みの両方をサポートし、すべてのデータが強力な一貫性を保ち、完全に ACID 準拠であることを保証します。 このアーキテクチャにより、ゲーム業界はユーザーのログイン場所に関係なく、エンドユーザーに均一な体験を提供でき、プレイヤーのアクション、対戦結果、インベントリの更新をリージョン間でリアルタイムに同期することが可能になります。 次のアーキテクチャ図は、内部コンポーネントを含む Amazon Aurora DSQL シングルリージョンデータベースを示しています。 スケーラビリティの観点から、Amazon Aurora DSQL のクエリ処理レイヤー、コンピュートレイヤー、コミットレイヤー、ストレージレイヤーを含むすべてのコンポーネントは、ワークロードの需要に基づいて独立してスケールします。 これにより、ゲームはデータベースのシャーディングやインスタンスのサイズ変更の複雑な対応をせずに、ローンチ時、ライブイベント時、または季節的なアップデート時のスパイクに対応できます。 このセットアップは、単一リージョンで 99.99%、マルチリージョンで 99.999% の可用性を確保し、ゲームアプリケーション向けの信頼性の高いスケーラブルなソリューションを提供します。 Amazon Aurora DSQL アーキテクチャについて詳しく知りたい場合は、 Introducing Amazon Aurora DSQL を参照してください ゲーム向け Amazon Aurora DSQL の主な利点 Amazon Aurora DSQL は、モダンなゲームの一貫性とスケーリングのニーズに合わせたサーバーレスでクラウドネイティブなデータベースを提供します。 以下の機能により、開発者は信頼性とスケーリングを犠牲にすることなく、マルチリージョンで同期された耐障害性のあるゲーム体験を構築できます。 マルチリージョンのアクティブ-アクティブ書き込み – Amazon Aurora DSQL では、プレイヤーはマルチリージョンクラスター内のリンクされた 2 つのリージョンのいずれからでもデータの読み取りと書き込みが可能で、同時書き込みの競合解決はデータベースが処理します。これにより、プレイヤーのアクション、対戦結果、インベントリの更新をリージョン間でリアルタイムに同期できます。 スケールに対応した ACID 準拠トランザクション – 強力な一貫性により、リーダーボード、ゲーム内購入、マッチメイキングなどの重要なゲーム操作における競合状態、重複トランザクション、データ競合を防止します。 簡単なスケーリングと高可用性 – Amazon Aurora DSQL は、事実上無制限の水平スケーリングを提供し、ワークロードの需要に基づいて読み取り、書き込み、コンピューティング、ストレージを独立してスケーリングします。これにより、ゲームはローンチ時、ライブイベント時、季節的なアップデート時の大規模なスパイクに対応できます。データベースのシャーディングやインスタンスのアップグレードの複雑さなしに、単一リージョンで 99.99%、マルチリージョンで 99.999% の可用性を維持します。 PostgreSQL 互換 – ゲーム開発者は、既存の PostgreSQL インスタンスベースのデータベースを最小限の変更で Amazon Aurora DSQL 分散データベースに移行できます。 ゲーム向け Amazon Aurora DSQL の使用 Amazon Aurora DSQL がゲームバックエンドに実際の価値をもたらす方法を示すために、このセクションではゲームステート管理からリアルタイムインタラクション、リーダーボードまでの主要なユースケースを探り、Amazon Aurora DSQL がグローバル規模で信頼性の高いプレイヤー体験を提供する方法を強調します。 これらの課題はゲームに特有のものに見えるかもしれませんが、一貫性の維持、同期更新の確保、グローバルに分散したユーザー間のトラフィック処理など、より広範なシステムの問題を表しています。 ゲーム状態管理 領土制圧、ステージ解除/エリア解放、協力型のワールド進行など、永続的かつ進化し続ける世界を維持するゲームでは、一貫性と高可用性の確保が不可欠です。Amazon Aurora DSQL を使用することで、開発者はアクティブ-アクティブ機能を持つ複数の AWS リージョンにわたって、この共有されるゲーム状態を管理できます。これにより、リンクされたどのリージョンからも読み取りと書き込みの両方が可能になります。プレイヤーの移動や戦闘などのリアルタイムな操作を目的としたものではありませんが、Amazon Aurora DSQL は強力な一貫性と組み込みの競合解決機能を提供し、リージョンの障害が発生した場合でも、プレイヤーが引き起こす世界の変化が正確かつ永続的に維持されることを保証します。これにより、非同期マルチプレイヤー体験や可用性と継続性を優先するゲームに適しており、複雑なシャーディングや手動フェイルオーバーなしに、世界中のプレイヤーが統一されたゲーム世界とインタラクションできるようになります。 ゲーム内取引、ゲーム内仮想通貨、プレイヤーインベントリ ゲーム内仮想通貨やアイテムベースの報酬によって支えられる堅牢なゲーム内経済では、不正行為、アイテムの複製、購入アイテムの紛失を防ぐためにトランザクション保証が必要です。プレイヤーがアイテムを購入したり、戦利品を獲得したり、他のプレイヤーと取引したりする際、基盤となるシステムはウォレット残高とプレイヤーのインベントリを不可分かつ一貫して更新する必要があります。Amazon Aurora DSQL の ACID 準拠のトランザクションにより、これらの操作はグローバルデータベースクラスターの両方にリンクされたリージョンにおいて、高い同時実行性の下でも安全かつ確実に処理されます。 ライブイベント ライブイベントは、しばしばプレイヤーのアクティビティの急激な増加を引き起こし、データベースが増加した負荷に対応するために動的にスケールする必要があります。 Amazon Aurora DSQL のサーバーレスアーキテクチャにより、リソースをリアルタイムで自動的にスケールし、手動介入なしでトラフィックの急増に対応することができます。 その高可用性により、大規模なイベント中でも継続的な稼働時間が確保され、プレイヤーの没入感と満足度を維持し、途切れることのないスムーズなゲーム体験を提供します。 グローバルリーダーボード 競争性の高いゲームでは、プレイヤーが新しいスコアやマイルストーンを達成するたびにリアルタイムで更新されるリーダーボードが特徴となっています。Amazon Aurora DSQL のアクティブ-アクティブレプリケーションと強力な一貫性により、マルチリージョンクラスター内のリンクされた両方のリージョンでリーダーボードデータの正確性と最新性が確保されます。これにより、場所に関係なくすべてのプレイヤーが同じリーダーボード結果を見ることができ、公平な競争を促進し、プレイヤーの成果をリアルタイムに反映することでエンゲージメントを維持します。 リアルタイムプレイヤーインタラクション リアルタイムチャット、チームベースの連携、共有ワールドイベントなどのソーシャル性や協力要素を備えたゲームでは、リージョンをまたいだプレイヤー間のリアルタイムなやり取りが必要です。さらに、マッチメイキングシステムは、スキルレベル、レイテンシー、ゲームモードの好みに基づいてプレイヤーを効率的にペアリングし、公平で競争力のある対戦を確保する必要があります。Amazon Aurora DSQL のアクティブ・アクティブ分散アーキテクチャにより、メッセージの送信、チーム形成、マッチメイキングキューへの参加などのプレイヤーアクションをリージョン間でリアルタイムにレプリケーションできるため、データの不整合を最小限に抑え、グローバルなプレイヤー間のやり取りをより迅速にサポートすることができます。 Amazon Aurora DSQL のアーキテクチャは、プレイヤー間のコミュニケーション（チャット、招待、グループプレイ）を同期させ、中断のないリアルタイムのマルチプレイヤー体験を提供します。 アクティブ-アクティブ書き込みは、競合状態を防ぎ、リアルタイムデータに基づく公平なプレイヤーのペアリングを可能にすることで、グローバルに一貫したマッチングを維持します。 Amazon Aurora DSQL は自動的にスケールし、ライブイベントやピーク時のマッチメイキングリクエストの急増にも対応できます。 また、ローカルな読み取り処理と複雑なクエリにより、リアルタイムゲームロジックのための低レイテンシーな意思決定が可能になります。 インタラクションデータが増加しても、Amazon Aurora DSQL はストレージを自動的に管理し、その料金体系はプレイヤーのアクティビティが変動するゲームのコスト効率をサポートします。 組み込みの暗号化と IAM ベースのアクセス制御により、機密性の高いプレイヤーデータや仮想資産をさらに保護します。 まとめ 本稿では、Amazon Aurora DSQL がマルチリージョンのアクティブ-アクティブアーキテクチャ、ACID トランザクション、そしてサーバーレススケーラビリティを通じて、グローバルに一貫性があり、高度にスケーラブルな体験を実現することで、現代のゲームバックエンドが直面する特有の要求にどのように対応しているかをご紹介しました。 詳細については、 Amazon Aurora DSQL ドキュメント をご覧いただくか、Aurora DSQL を使用してグローバルにスケーラブルなゲームバックエンドの構築を今すぐ始めてください。 著者について Naveen Kantamneni Naveen は AWS のシニアスペシャリストソリューションアーキテクトであり、ゲーム業界のお客様がモダナイゼーションを推進し、運用効率を向上させ、世界水準のプレイヤー体験を実現できるよう支援しています。スタートアップから大規模スタジオまで、さまざまなゲーム企業の信頼できるアドバイザーとして、ビジネス課題の解決や、ミッションクリティカルなワークロードにおける AWS サービスの最適化に取り組んでいます。 Rajesh Kantamani Rajesh はシニアデータベーススペシャリストソリューションアーキテクトです。スケーラビリティ、セキュリティ、パフォーマンスに焦点を当てながら、顧客と協力して Amazon Web Services 上のデータベースソリューションの設計、移行、最適化を行っています。分散データベースに情熱を持ち、組織のデータ基盤のモダナイゼーションを後押ししています。 Raluca Constantin Raluca は AWS のシニアデータベースエンジニアで、Amazon Aurora DSQL を専門としています。彼女の 18 年にわたるデータベース分野の経験を持ち、Oracle、MySQL、PostgreSQL からクラウドネイティブソリューションまで幅広い技術に精通しています。特に、スケーラビリティ、パフォーマンス、リアルタイムデータ処理を中心に取り組んでいます。

本記事は米国時間 7 月 31 日に公開された “ Overcome development disarray with Amazon Q Developer CLI custom agents ” を翻訳したものです。 ワークフローを強化するために Model Context Protocol (MCP) の力を受け入れてきた開発者として、 Amazon Q Developer CLI にカスタムエージェント が追加されたことを心より嬉しく思います。この新しい機能は、私が信頼してきた能力を全く新しいレベルに引き上げ、異なる開発コンテキストをシームレスに管理し、簡単に切り替えることを可能にしてくれます。 前回の投稿 では、MCP サーバーが AWS サービスやデータベース、その他の重要なツールとの関わり方にどのような革命をもたらしたかについて説明しました。 Amazon Q Developer の MCP 統合によって、データベーススキーマのクエリ、インフラストラクチャにおけるデプロイの自動化、その他多くのことができるようになりました。しかし、複数のプロジェクトを掛け持ちするようになり、それぞれに独自の技術スタックや要件があるため、これらの多様な開発環境を管理するために、より構造化されたアプローチが必要であることに気づきました。 そこで、カスタムエージェントの登場です。この新しい機能により、開発段階に適したタスクのために、特定のツール、プロンプト、コンテキスト、ツール許可をまとめることで、カスタムエージェントを作成・使用することができるようになりました。 背景 私が多層ウェブアプリケーションに取り組んでいるとしましょう。このアプリケーションには、TypeScript で書かれた React フロントエンドと Python で書かれた FastAPI バックエンドがあります。チームには私の他に、Figma を使用するデザイナーとPostgreSQL データベースを管理するデータベース管理者がいます。そこには、デザイナーとデータベース管理者とのコミュニケーション方法に微妙な違いがあります。例えば、私がデザイナーと「テーブル」について議論するとき、それは HTML テーブルとそのページがどのように構成されているかを指している可能性が高いです。しかし、私がデータベース管理者と「テーブル」について議論するときは、SQL テーブルとデータの格納方法について話すことが多いです。 以前、私の環境では、 Figma Dev Mode MCP サーバー と Amazon Aurora PostgreSQL MCP サーバー の両方を設定していました。これにより、フロントエンドとバックエンドのどちらのコードでも簡単に作業できるようになりましたが、いくつかの課題も発生しました。もし私が Amazon Q Developer に「テーブルはいくつありますか？」と尋ねたら、Amazon Q Developer は私が HTML テーブルについて話しているのか SQL テーブルについて話しているのかを推測しなければならないでしょう。もし HTML に関しての質問であれば、Figma サーバーを使用すべきです。もし SQL に関しての質問であれば、Aurora サーバーを使用すべきです。これは技術的な制限ではなく、言語の制限です。私がデザイナーやデータベース管理者と話すために前提を調整しなければならないのと同じように、Amazon Q Developer も同じ調整をしなければなりません。 そこで、Amazon Q Developer CLI カスタムエージェントの登場です。カスタムエージェントを使用することで Amazon Q Developer の設定をシナリオごとに最適化することができます。私のフロントエンドとバックエンドの構成を見て、その影響を理解してみましょう。 フロントエンドエージェント 私のフロントエンドカスタムエージェントは React と Figma を使用したフロントエンドウェブ開発用に最適化されています。以下のコード例は、 ~/.aws/amazonq/agents/front-end.json に格納されている私のフロントエンドエージェントの設定です。それでは、この設定の主なセクションについて説明しましょう。 mcpServers – ここでは Figma Dev Mode MCP サーバーを設定しました。ローカルにインストールされた Figma Web Design App と通信するだけです。これは、 ~/.aws/amazonq/mcp.json に保存されていた MCP 設定を置き換えることに注意してください。 tools と allowedTools – この 2 つのセクションは関連しているため、一緒に説明します。 tools は Amazon Q Developer が利用可能なツールを定義し、 allowedTools は信頼できるツールを定義します。言い換えると、Amazon Q Developer は設定されたツールを使用することができ、 fs_read や fs_write 、 @Figma を使用するために私に許可を求める必要がありません。 @Figma は、Amazon Q Developer が許可を求めることなく、すべての Figma ツールを使用することができます。 resources – ここではコンテキストに追加するファイルを設定しました。README.md (プロジェクトフォルダに格納されている) と、React に関する私自身の設定 (プロファイルに格納されている) を含めました。詳しくは、 コンテキスト管理とプロファイル を参照してください。 hooks – リソースに加えて、フックも用意しました。このフックはコマンドを実行し、実行時にそれをコンテキストに追加します。この例では、現在の git status を追加しています。詳しくは、 コンテキストフックの使用 を参照してください。 { "description": "Optimized for front-end web development using React and Figma", "mcpServers": { "Figma": { "command": "npx", "args": [ "mcp-remote", "http://127.0.0.1:3845/sse" ] } }, "tools": ["*"], "allowedTools": [ "fs_read", "fs_write", "report_issues", "@Figma" ], "resources": [ "file://README.md", "file://~/.aws/amazonq/react-preferences.md" ], "hooks": { "agentSpawn": [ { "command": "git status" } ] } } バックエンドエージェント 私のバックエンドカスタムエージェントは Python とPostgreSQL を使用したバックエンド開発に最適化されています。以下のコード例は、 ~/.aws/amazonq/agents/back-end.json に格納されている私のバックエンドエージェントの設定です。先ほどのようにセクションを説明するのではなく、フロントエンドとバックエンドの違いに焦点を当てます。 mcpServers – ここでは Amazon Aurora PostgreSQL MCP サーバー を設定しました。これにより、Amazon Q Developer が私の開発用データベースにクエリを発行し、スキーマを知ることができます。誤ってデータベースを更新しないように、読み取り専用の接続を設定していることに注意してください。 tools と allowedTools – 今回も Amazon Q Developer ですべてのツールを使用可能にしました。しかし、信頼できるツールについては、より制限しています。Amazon Q Developer は、 fs_write や @PostgreSQL/run_query の使用許可を求める必要があります。Figma でやったように MCP サーバー全体を許可することもできますし、ここでやったように特定のツールを許可することもできます。 resources – ここでも、README.md (プロジェクトフォルダに格納されている) と Python と SQL に関する私自身の設定 (どちらも私のプロファイルに格納されている) を含めました。ここで glob パターンを使用可能なことに注意してください。例えば、 file://.amazonq/rules/**/*.md には Amazon Q Developer IDE プラグインによって作成されたルールが含まれます。 hooks – 最後にフロントエンドとバックエンド用のフックも用意しました。フロントエンドには npm run 、バックエンドには pip freeze のようにプロジェクト固有のオプションを含めることもできます。 { "description": "Optimized for back-end development with Python and PostgreSQL", "mcpServers": { "PostgreSQL": { "command": "uvx", "args": [ "awslabs.postgres-mcp-server@latest", "--resource_arn", "arn:aws:rds:us-east-1:xxxxxxxxxxxx:cluster:xxxxxx", "--secret_arn", "arn:aws:secretsmanager:us-east-1:xxxxxxxxxxxx:secret:rds!cluster-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxx-xxxxxx", "--database", "dev", "--region", "us-east-1", "--readonly", "True" ] } }, "tools": ["*"], "allowedTools": [ "fs_read", "report_issues", "@PostgreSQL/get_table_schema" ], "resources": [ "file://README.md", "file://~/.aws/amazonq/python-preferences.md", "file://~/.aws/amazonq/sql-preferences.md" ], "hooks": { "agentSpawn": [ { "command": "git status" } ] } } カスタムエージェントの使用 エージェントの本当の力は、これらの異なる開発コンテキストを切り替える必要がある時に明らかになります。React と Figma で作業しているときは q chat --agent front-end を、Python と SQL で作業しているときは q chat --agen``t back-end を実行するだけです。Amazon Q Developer は私の好みに合わせて適切なエージェントを設定してくれます。 以下の画像は、Amazon Q Developer CLI における設定を見ることができます。フロントエンドエージェントには Figma という追加のツールがあり、バックエンドエージェントには PostgreSQL という追加のツールがあることに注目してください。さらに、フロントエンドエージェントは fs_write とすべての Figma ツールを信頼しますが、バックエンドエージェントは fs_write の使用許可を求め、2 つの PostgreSQL ツールのうち 1 つだけを信頼します。 同様に、フロントエンドエージェントとバックエンドエージェントのコンテキスト設定を見てみましょう。以下の画像では、フロントエンド開発用の React の設定とバックエンド開発用の Python と SQL の設定を含めています。 このように、カスタムエージェントを使用することで Amazon Q Developer CLI をタスクごとに最適化することができます。もちろん、フロントエンドとバックエンドのエージェントはただの一例です。開発やテストのエージェント、データサイエンスや分析のエージェントなどがあるかもしれません。カスタムエージェントを使用することでほとんどのタスクに対応した構成にすることができます。 おわりに Amazon Q Developer CLI カスタムエージェントは、複雑な開発環境を管理する上で重要な改善となります。開発者が異なるコンテキスト間をシームレスに切り替えられるようにすることで、異なるタスクのためにツールや権限を手動で再設定する認知的なオーバーヘッドを排除します。開発ワークフローを合理化する準備はできましたか？今すぐ Amazon Q Developer を始めましょう 。

本稿は、2025 年 8 月 5 日に AWS Migration &amp; Modernization Blog で公開された “ Run VMware your way: Amazon Elastic VMware Service is now generally available ” を翻訳したものです。 VMware 上でミッションクリティカルなワークロードを実行している企業にとって、クラウドへの移行は既存の投資を維持するか、イノベーションを受け入れるかの選択を迫られることが多くありました。本日、それが変わります。Amazon Elastic VMware Service (Amazon EVS) が 6 つの AWS リージョンで一般提供を開始し、VMware Cloud Foundation (VCF) ユーザーに AWS のスケール、柔軟性、パフォーマンス、セキュリティを提供します。 Amazon EVS が提供するもの 完全な VCF 環境を数週間ではなく数時間でデプロイ クラウド内の VMware スタックを完全にコントロール 既存の VMware スキルとツールを活用 リファクタリングなしで 200 以上の AWS サービスにアクセス ニーズに基づいてリソースを動的にスケール Amazon EVS が組織のクラウドジャーニーで直面する主要な課題にどのように対処するかを探ってみましょう。 課題 推定では、 企業ワークロードの 75% が現在もオンプレミスで稼働しており 、重要なアプリケーションが依然として VMware 上で実行されています。これらのアプリケーションは、顧客取引から製造業務まですべてを管理し、収益と顧客満足度に直接影響を与えています。これらのアプリケーションはクラウドの恩恵を受けられるはずですが、既存の複雑な依存関係や統合のため、移行が困難になっています。 これにより、お客様のような組織にとって差し迫った課題が生じています。オンプレミスのデータセンターには多額の設備投資と継続的なメンテナンスが必要であり、イノベーションのためのリソースが制限されます。一方で、ビジネスにおける俊敏性、スケーラビリティ、コスト最適化に対する要求は高まり続けています。業務を中断したり、大規模な再設計を必要とせずに、VMware ワークロードにクラウドの利点をもたらす方法が必要です。これらの課題に対処するため、VMware と AWS の長所を組み合わせたソリューションを開発しました。Amazon EVS は、VMware の移行とモダナイゼーションパスウェイの包括的なポートフォリオへの最新の追加となるもので、ワークロードをクラウドに移行し、モダナイゼーションの旅を始めるための選択肢をさらに増やします。 Amazon EVS の違い：コントロール、柔軟性、選択肢 私たちは、クラウド上で VMware を実行するためのより多くの選択肢を提供する必要性に応えるため Amazon EVS を構築しました。多くのお客様が Broadcom の VMware Cloud on AWS マネージドサービスの恩恵を受けている一方で、Amazon EVS は選択肢を拡大し、AWS ネイティブサービスならではのコントロール、選択、柔軟性を提供します。 Amazon EVS の核心は、AWS Nitro を搭載した EC2 ベアメタルインスタンス上で、Amazon Virtual Private Cloud (VPC) 内で VCF をネイティブに実行することです。完全な VCF 環境のセットアップは、ステップバイステップの設定ワークフローを使用する場合でも、自動デプロイメント機能を備えた AWS Command Line Interface (CLI) を使用する場合でも、わずか数時間で完了します。この迅速なデプロイメントにより、ワークロードを AWS に素早く移行し、老朽化したインフラストラクチャを廃止し、運用リスクを軽減し、データセンターからの撤退などの重要なタイムラインを達成することができます。このコントロールと柔軟性が組織にとってどのような実践的なメリットをもたらすのか見ていきましょう。 クラウド上でのアーキテクチャ制御と、任意のソリューションとの統合 Amazon EVS を使用すると、クラウド内の VMware ワークロードのアーキテクチャを完全に制御できます。vSphere、NSX Manager、SDDC Manager への完全な管理アクセスにより、ビジネスニーズに応じて仮想化スタックを最適化できます。このサービスは VCF 5.2.1 をサポートし、 Amazon FSx for NetApp ONTAP や Pure Cloud Block Store などの外部ストレージソリューション、あるいは Veeam Backup and Replication などのバックアップソリューションなど、すでに信頼しているアドオンやサードパーティソリューションを統合できます。 コストを最適化するための柔軟性 技術的な機能に加えて、私たちはビジネスニーズを考慮して Amazon EVS を設計しました。ライセンスと消費の柔軟性がビジネス計画にとって重要であることを理解しています。そのため、Amazon EVS では、 ライセンスポータビリティエンタイトルメントを通じて既存の VCF ライセンスを持ち込むことができ 、オンデマンド、1 年、3 年の期間を含む柔軟な消費オプションから選択できます。さらに、Amazon EVS は Migration Acceleration Program (MAP) の対象となり、移行コストの削減と AWS への移行の加速を支援します。 環境管理方法の選択肢 社内の専門知識を活用したいか、専門的なサポートが必要かに関係なく、Amazon EVS は組織のニーズに適応します。セルフマネージドによりコントロールを最大化し、既存のスキルを活用することも、マネージドサービスや移行の専門知識を提供する広範な AWS パートナーと協力することもできます。これらのパートナーには、 Pellera Technologies 、 Kyndryl 、 DXC Technology 、 Xtravirt 、 Accenture 、 AHEAD 、 Effectual 、 Presidio 、 CDW 、 富士ソフト などの業界リーダーが含まれます。 これらのパートナーは、Amazon EVS での成功を支援する実証済みの専門知識を提供します。例えば、Converge は現在、お客様向けに EVS (Elastic VMware Service) IQ Migrate サービス を提供しています。Pellera Technologies のクラウドプラットフォーム担当副社長である Rochelle Manns 氏は次のように説明しています：「Amazon EVS の機能と当社のインテリジェントサービスを組み合わせることで、複雑さや妥協なしに、AWS 上の VMware 環境の評価、移行、運用への明確な道筋を顧客に提供しています。パートナー主導のアプローチのシンプルさと、自分のペースでモダナイゼーションを進められる柔軟性を兼ね備えています。」 同様に、DXC Technology は DXC Migration and Managed Services for Amazon EVS を開始しました。DXC Technology のクラウド＆インフラストラクチャオファリング責任者である Andrew Haigh 氏は、Amazon EVS を検討しているお客様にとってのパートナーの価値を強調し、次のように述べています：「Amazon EVS の開始は、VMware の信頼できる VCF プライベートクラウドプラットフォームと革新的な AWS クラウドネイティブサービスを組み合わせた、AWS 上の企業にとって魅力的なソリューションを提供します。DXC の仮想化ワークロードの移行と運用における数十年の経験により、お客様は迅速かつ確実にクラウド導入戦略を実行し、ビジネス価値を実現することができます。」 さらに、富士ソフトのソリューション事業本部副本部長 兼 インフラ事業部事業部長執行役員である山本祥正氏は、このサービスがお客様の移行ジャーニーにどのように支援するかを強調しました：「この新たなサービスは、VMware 環境をお客様の AWS クラウドジャーニーとシームレスに統合し、インフラストラクチャの移行とモダナイゼーションを加速させる画期的なソリューションであると確信しております。富士ソフトは、Amazon EVS によって、お客様のクラウドジャーニーにおいて新たな価値創造の機会が生まれることを期待しております。」 これらの AWS パートナーと Amazon EVS 向けのソリューションについて詳しく知るには、 AWS Marketplace をご覧いただくか、AWS 担当者にお問い合わせください。 スケーラブルな企業インフラストラクチャ Amazon EVS 上で実行することで、アプリケーションは世界中の数百万ものお客様にサービスを提供している実績のあるグローバルインフラストラクチャと同じメリットを享受できます。スタートアップから Fortune 500 企業まで、組織はピーク時の需要に対応するための拡張性と、通常運用時のコスト最適化を実現するために AWS を信頼しています。ワークロードはリファクタリングやリプラットフォームなしで AWS サービスをシームレスに活用でき、移行とモダナイゼーションの過程を加速することができます。 実際のお客様の成功事例 AWS re:Invent 2024 で Amazon EVS を発表して以来、私たちは顕著なお客様の成功事例を目にしてきました。その中でも際立つ例が、200 万人以上の住民にサービスを提供するコロンビア第 3 の地方自治体である Alcaldía de Cali です。彼らの目標は、200 万人以上の住民により良いデータ駆動型の公共サービスを提供することでした。Amazon EVS を使用することで、24 時間以内に環境を展開し、移行期間中も公共サービスを中断することなく維持することができました。 この勢いは続いており、Aeroméxico や Huron Consulting Group などの組織が、私たちの公式プレスリリースで Amazon EVS への期待を表明しています。 今日から AWS へのジャーニーを開始 Amazon EVS は現在、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アイルランド) で利用可能です。戦略的なデータセンターの撤退を計画している場合でも、運用コストの削減を検討している場合でも、クラウドイノベーションを活用する準備ができている場合でも、Amazon EVS は VCF ベースのワークロードのためのシンプルなパスを提供します。 次のステップ 詳細を学ぶ： 製品ページ 、 AWS News Blog 、 プレスリリース をご覧ください 開始する： Amazon EVS コンソール にアクセス 詳しく学ぶ： 技術ドキュメント を確認し、Amazon EVS の詳細を学習 移行とモダナイゼーションオプションを探索： AWS for VMware ページ をご覧いただき、AWS で VMware を移行・モダナイゼーションするすべてのオプションを発見 計画を開始： AWS 担当者に連絡するか、 お問い合わせ ください <!-- '"` --> Steven Jones EC2 の Commercial Applications の General Manager として、SAP、VMware、Red Hat Open Shift on AWS の製品戦略、エンジニアリング実行、カスタマーサクセスをリードしています。AWS 内のこれらのビジネス領域により、企業は最も要求の厳しいワークロードをクラウド上で実行できます。AWS で 13 年の経験を持ち、革新的なソリューションの提供、パフォーマンスのスケーリング、複数のセグメントや業界にわたる成長の推進において確かな実績があります。AWS を最もお客様中心のクラウドプラットフォーム、そしてビジネスクリティカルなワークロードを実行するための最適な場所にすることに情熱を注いでいます。AWS における SAP 技術戦略の推進役であり、ハイパースケールプラットフォーム上での SAP ワークロードの一般サポートや、大容量メモリ SAP HANA ワークロードを支えるクラウドネイティブなインフラストラクチャなど、業界初の取り組みを数多く市場に送り出してきました。また、VMware ビジネスも統括し、お客様が VMware ベースの環境をシームレスに AWS へ移行および拡張できるよう支援しています。創造的なアイデア、抽象化、システムパフォーマンスに関するスキルを活かし、お客様、パートナー、AWS に価値をもたらしています。 Bianca Velasco AWS の Product Marketing Manager として、AWS 上の VMware ベースワークロードの移行と変革に焦点を当てています。マーケティングとテクノロジーで 7 年以上の経験を持ち、複雑なテクノロジーを意味があり親しみやすいものにする物語を作ることに情熱を注いでいます。AWS 以外では、Bianca はボランティア活動、ダンス、ボルダリングを楽しんでいます。 Andy Reedy EC2 Commercial Applications の Product Management の Sr. Manager として、VMware、SAP、Red Hat OpenShift ワークロードに焦点を当てたチームを率いています。IT インフラストラクチャ、ネットワーキング、セキュリティ、クラウド戦略、エンタープライズソフトウェア分野で 25 年以上の経験を持ち、ビジネスクリティカルなアプリケーションの移行やモダナイズをお客様が実現できるよう支援することに情熱を注いでいます。 翻訳はパートナーソリューションアーキテクト 豊田が担当しました。原文は こちら です。

こんにちは、AWS ソリューションアーキテクトの上野です。2025年6月17日、7月4日に、AWS 主催のハッカソンイベントを開催しましたので、その取り組みについてご紹介させていただきます。本イベントは、通常のハンズオンとは異なり、短期集中型の支援を通じて実務で即活用できる機能開発を実現し、お客様のビジネスを加速させることを目指しています。 イベントの流れ 2日間のイベントを軸に進めていきます。初日となる Day 1 では、まず開発で利用する AWS サービスの基礎を学んでいただき、その後、実際に開発する機能の要件整理や設計に取り組んでいきます。AWS のエキスパートが終日同じテーブルにつき、一緒に考え、技術面でのアドバイスを提供させていただきます。 Day 1 で整理した内容を持ち帰っていただいた後は、実際の開発フェーズに入ります。開発中に疑問点や課題が出てきた際には、随時技術相談会を開催し、スムーズな開発をサポートさせていただきます。 締めくくりとなる Day 2 では、参加者の皆様に開発した機能についてご発表いただきます。技術的な工夫だけでなく、開発中の試行錯誤など、貴重な経験の共有の場となっています。 参加企業様の素晴らしい取り組み それではここからは、ご参加いただいた企業様のご登壇の様子をご紹介していきます。 株式会社クリエイティブ・ウェブ 片桐　翼 氏（写真右）、藤井　龍生 氏（写真中央）、大皿　綾馬 氏（写真左）らは、電話による問い合わせの一次対応をAIで行い、問い合わせ内容を仕分けして担当者に通知する仕組みを開発されました。システム・PCサポート・WEB サイト・EC 関連の問い合わせに対して、最初に受電した方が内容を聞いて、担当者に取り次ぐ必要があり、問い合わせる側の待ち時間および、対応をする側の工数にそれぞれ課題がありました。これらの課題を解決するためにまず、問い合わせ内容の仕分けを生成 AI で行い、適切な担当者に振り分ける機能を開発することで、一次対応する方の負荷を削減されております。また問い合わせをした方は、一度、問い合わせ内容を電話で伝えた後、担当者から折り返し電話がかかってくる仕組みのため、電話越しに長時間を待つ必要がなくなります。すでに社内ではベータ版としてリリースされており、今後は問い合わせ内容の仕分けだけではなく、AI と顧客の会話まで実現させ、一次対応の完全自動化を目指していかれるとのことです。 株式会社BTM 瀬﨑　優太朗 氏は、システムトラブルに伴う調査依頼を生成 AI と MCP サーバーの組み合わせで効率化する仕組みを開発されました。調査を行う上で、複数の関係者が存在するため、調査に必要な情報が不足している場合、再度確認を行うなどのコミュニケーションコストが多く発生している点や、調査作業として都度、状況に応じたクエリを考えてデータベースに対して実行する必要があるなどの課題があったとのことです。今回は、問い合わせ内容をもとに生成 AI が実行すべきクエリを考え、MCP サーバー連携によりデータベースにクエリを実行するという仕組みを Strands Agents を軸に開発されております。また開発においては AI コーディングエージェントも利用されており、技術的にも非常に興味深い取り組みをされております。今後はレスポンスタイムの向上と、情報不足時にチャットで聞き返えしができるようにするなど、さらにブラッシュアップをされていくとのことです。 AZAPAエンジニアリング株式会社 鬼頭　肖太 氏（写真左）、清水　凌太 氏（写真右）らは、本イベント の中で、既存の駐車場解析システムの構成をモダナイゼーションされました。映像解析処理は複数の工程に分かれており、それぞれの処理が一つのサーバーの中で順番に実行されるという構成をとられていました。しかし、工程ごとに処理の規模は異なり、必要なリソース量も変わる中で、最大規模の処理にあわせてサーバーのサイジングが必要なっていることから、コストに課題を持たれておりました。また１台のサーバーではリソースにも限度があり、処理速度にも課題が出てきている状況でもあったとのことです。今回は、一つのサーバー内で行われていたフローを AWS Step Functions に置き換えることで、工程別に必要な分だけのマシンリソースで処理を実施できる構成にモダナイゼーションされました。これによってコスト47%削減、処理速度3倍という検証結果が出ており、課題解決に向けた大きな一歩を本イベントで踏み出されたと実感いただいています。コスト面では、Lambda、スポットインスタンスを利用することでさらなる改善が見込め、処理速度とコストのパッケージに幅を持たせることが可能になりました。 まとめ 今回のイベントでも、参加された全てのお客様が、実務で使える機能を見事に開発されました。「ディスカッションを通して、アイデアの着想から掘り起こしまでできてとてもよい時間となった」、「短い時間であるからこそ集中的に開発ができた」など、うれしい声を多数いただき、本イベントがお客様のビジネスを加速させる場になっていることを改めて感じることになりました。また各企業様、それぞれまったく色の違う開発内容でありましたが、とある企業様の開発tipsが別の企業様の今後の開発効率化につながりそうであるなど、知見のシェアにもつながる素晴らしい場になったと感じています。これからもお客様のビジネスの発展により一層貢献できるよう、イベント内容の改善を重ねてまいります。

はじめに データベース技術は日々進化し、クラウド環境においてもその重要性は増す一方です。特に、AWSのデータベースサービスは昨今、多くの企業にとって不可欠なツールとなっています。こうした背景において、AWSは2025年8月から9月にかけてAWS データベースに関する学習機会をまとめて提供予定です。これらのセミナーやコンテンツを活用し、AWSのデータベースサービスについての理解を深めていただけたらと考えています。 本ブログでは、この期間に開催される注目のセミナーや、直近新たにBlackbeltとして公開した資料をご紹介します。特にAWSのデータベースサービスを最大限に活用したい方、最新の動向を把握したい方にとって、貴重な情報源となることでしょう。 それでは、具体的に見ていきましょう！ セミナーのご紹介 ■ (2025/8/25) AWS Database 開発チーム Meet-up 2025 AWSのデータベースサービス(Amazon Aurora DSQL、Amazon Aurora、AWS DynamoDB)の開発チームメンバーが登壇します。 各チームの特徴やサービスの最新アップデートに関する紹介と、質疑応答においては直接開発者にご質問いただくことが可能です。データベース技術に興味がある人、AWSデータベースサービスの詳細を知りたい人にお勧めなセミナーです。 申込先 : https://aws.amazon.com/startups/events/database-meetup-20250825 ■ (2025/9/25) MariaDB at Loft 本イベントでは、データベースパフォーマンスの最適化をテーマに、MariaDB と AWS の専門家が実践的な知見を共有します。前半の MariaDB ゲストセッションでは、データベースのベンチマーキング手法や、最新のベクトルインデックス機能など、パフォーマンスに直結する技術トピックスについて詳しく解説します。後半の AWS セッションでは、Amazon RDS を活用したマネージドデータベースへの移行戦略などをご紹介します。データベース管理者やアプリケーション開発者の方々におすすめの内容です。 申し込み先： https://aws.amazon.com/startups/events/mariadb-meetup-20250925 AWS Black Belt Online Seminar コンテンツのご紹介 ■ Amazon Aurora 概要編 Amazon Aurora は、リリース以来、10年以上にわたってAWSのマネージド型リレーショナルデータベースとして進化を続けてきました。この間、パフォーマンス最適化機能やセキュリティ強化、新しいデータベースエンジンの追加など、数多くの機能拡張が行われ、現在では世界中の多くのお客様のミッションクリティカルなワークロードを支えています。 本コンテンツでは、すでにAmazon RDSをご利用いただいているお客様向けに、改めてサービスの特長をご紹介すると共に、これからAuroraの利用をご検討されている方々に向けて、サービスの基本的な概要をわかりやすく解説しています。 Overview https://www.youtube.com/watch?v=lFvzuPVgXus 可用性 – 前半 https://www.youtube.com/watch?v=n14BOc-AgLM 可用性 – 後半 https://www.youtube.com/watch?v=tm-D7nITG_g 性能とスケーラビリティ https://www.youtube.com/watch?v=ctnpUjW97CQ コスト最適化 https://www.youtube.com/watch?v=kjdOuMyGjZQ 移行支援プログラム・サービス https://www.youtube.com/watch?v=NDFkegqRkuQ 以上は概要編になりますが、現在詳細編のリリースを準備していますので、ご期待ください！ ■ AWS Database Migration Service (DMS) AWS Database Migration Service（AWS DMS）は、データベースの移行を効率的かつ安全に行うためのAWSのマネージドサービスです。2016年の一般提供開始以来、AWS DMSは世界中の多くの企業のデータベース移行プロジェクトを成功に導いてきました。本コンテンツでは、AWS DMSの概要、主要な機能、そして効果的な活用方法について解説していきます。加えて、普段多くのお客様システムの安定稼働を支援しているAWSサポートメンバーから、実際のお客様からのお問い合わせに基づいた知見をベストプラクティスとしてご紹介しています。 既にDMSをご利用の方には新たな視点を、初めて検討される方には基礎から応用までの幅広い知識をお届けします。 DMS 概要 https://www.youtube.com/watch?v=oopjz4vu9CY DMS ベストプラクティス – 計画編 https://www.youtube.com/watch?v=teaU4tWraXE DMS ベストプラクティス – 実践編 https://www.youtube.com/watch?v=2tE9uCGrk6M DMS トラブルシューティング編 公開準備中。近々に公開予定。 以上

はじめに データベース技術は日々進化し、クラウド環境においてもその重要性は増す一方です。特に、AWSのデータベースサービスは昨今、多くの企業にとって不可欠なツールとなっています。こうした背景において、AWSは2025年8月から9月にかけてAWS データベースに関する学習機会をまとめて提供予定です。これらのセミナーやコンテンツを活用し、AWSのデータベースサービスについての理解を深めていただけたらと考えています。 本ブログでは、この期間に開催される注目のセミナーや、直近新たにBlackbeltとして公開した資料をご紹介します。特にAWSのデータベースサービスを最大限に活用したい方、最新の動向を把握したい方にとって、貴重な情報源となることでしょう。 それでは、具体的に見ていきましょう！ セミナーのご紹介 ■ (2025/8/25) AWS Database 開発チーム Meet-up 2025 AWSのデータベースサービス(Amazon Aurora DSQL、Amazon Aurora、AWS DynamoDB)の開発チームメンバーが登壇します。 各チームの特徴やサービスの最新アップデートに関する紹介と、質疑応答においては直接開発者にご質問いただくことが可能です。データベース技術に興味がある人、AWSデータベースサービスの詳細を知りたい人にお勧めなセミナーです。 申込先 : https://aws.amazon.com/startups/events/database-meetup-20250825 ■ (2025/9/25) MariaDB at Loft 本イベントでは、データベースパフォーマンスの最適化をテーマに、MariaDB と AWS の専門家が実践的な知見を共有します。前半の MariaDB ゲストセッションでは、データベースのベンチマーキング手法や、最新のベクトルインデックス機能など、パフォーマンスに直結する技術トピックスについて詳しく解説します。後半の AWS セッションでは、Amazon RDS を活用したマネージドデータベースへの移行戦略などをご紹介します。データベース管理者やアプリケーション開発者の方々におすすめの内容です。 申し込み先： https://aws.amazon.com/startups/events/mariadb-meetup-20250925 AWS Black Belt Online Seminar コンテンツのご紹介 ■ Amazon Aurora 概要編 Amazon Aurora は、リリース以来、10年以上にわたってAWSのマネージド型リレーショナルデータベースとして進化を続けてきました。この間、パフォーマンス最適化機能やセキュリティ強化、新しいデータベースエンジンの追加など、数多くの機能拡張が行われ、現在では世界中の多くのお客様のミッションクリティカルなワークロードを支えています。 本コンテンツでは、すでにAmazon RDSをご利用いただいているお客様向けに、改めてサービスの特長をご紹介すると共に、これからAuroraの利用をご検討されている方々に向けて、サービスの基本的な概要をわかりやすく解説しています。 Overview https://www.youtube.com/watch?v=lFvzuPVgXus 可用性 – 前半 https://www.youtube.com/watch?v=n14BOc-AgLM 可用性 – 後半 https://www.youtube.com/watch?v=tm-D7nITG_g 性能とスケーラビリティ https://www.youtube.com/watch?v=ctnpUjW97CQ コスト最適化 https://www.youtube.com/watch?v=kjdOuMyGjZQ 移行支援プログラム・サービス https://www.youtube.com/watch?v=NDFkegqRkuQ 以上は概要編になりますが、現在詳細編のリリースを準備していますので、ご期待ください！ ■ AWS Database Migration Service (DMS) AWS Database Migration Service（AWS DMS）は、データベースの移行を効率的かつ安全に行うためのAWSのマネージドサービスです。2016年の一般提供開始以来、AWS DMSは世界中の多くの企業のデータベース移行プロジェクトを成功に導いてきました。本コンテンツでは、AWS DMSの概要、主要な機能、そして効果的な活用方法について解説していきます。加えて、普段多くのお客様システムの安定稼働を支援しているAWSサポートメンバーから、実際のお客様からのお問い合わせに基づいた知見をベストプラクティスとしてご紹介しています。 既にDMSをご利用の方には新たな視点を、初めて検討される方には基礎から応用までの幅広い知識をお届けします。 DMS 概要 https://www.youtube.com/watch?v=oopjz4vu9CY DMS ベストプラクティス – 計画編 https://www.youtube.com/watch?v=teaU4tWraXE DMS ベストプラクティス – 実践編 https://www.youtube.com/watch?v=2tE9uCGrk6M DMS トラブルシューティング編 公開準備中。近々に公開予定。 以上

本記事は米国時間 7月 31 日に公開された「 Implementing Defense-in-Depth Security for AWS CodeBuild Pipelines 」を翻訳したものです。 最近のセキュリティ研究により、 AWS Security Bulletin AWS-2025-016 で文書化されているように、 CI/CD パイプライン設定の重要性が注目されています。この投稿では、既存のガイダンスと推奨事項を一つのガイドにまとめます。 継続的インテグレーションと継続的デプロイメント（ CI/CD ）の実践は、開発チームが効率的かつ確実にソフトウェアを提供するのに役立ちます。 AWS CodeBuild は、GitHub、GitLab、その他のソースコード管理（ SCM ）システムなどのソースコードリポジトリと統合するマネージドビルドサービスを提供します。このガイドでは GitHub の例を使用していますが、セキュリティの原則と Webhook 設定のアプローチは、サポートしている他のソースコード管理システムにも適用できます。 ただし、特定の設定には注意深い配慮が必要です。 適切なセキュリティ制御と脅威モデルの明確な理解なしに、信頼できないリポジトリのコントリビューターからの自動プルリクエストビルドを使用しないことを強く推奨します。 この設定により、信頼できないコードがリポジトリの認証情報や環境変数にアクセスできる状態でビルド環境内で実行される可能性があります。Webhook 設定は、どのリポジトリイベントがビルドをトリガーし、ビルドプロセス中にどのコードが実行されるかを決定します。 CI/CD を価値あるものにする自動化の利点を維持しながら、適切なセキュリティ境界を維持するためには、これらの設定を理解することが不可欠です。 セキュリティチームと DevOps エンジニアは、これらの実用的なアプローチを使用して、開発速度を維持しながらセキュリティ目標を満たすように AWS CodeBuild を設定できます。脅威モデルの評価、最小権限アクセス、パイプライン設定の継続的な監視を重視した、 Webhook 設定、信頼境界、実装戦略について説明します。 パイプラインのセキュリティに関する考察 責任共有モデル では、 AWS が基盤となる AWS CodeBuild インフラストラクチャのセキュリティを管理する一方で、お客様はパイプラインの設定、アクセス制御、およびビルド環境内で実行されるコードのセキュリティに責任を負います。このような共有の責任は、パイプライン自体のセキュリティを考える上で重要です。 AWS CodeBuild がプルリクエストを自動的に処理する際には、リポジトリの認証情報、環境変数、機密性の高い可能性のある情報にアクセスできる環境でコードをビルドします。これにより、パイプラインのセキュリティに関する特定の考慮事項が生じます： リポジトリアクセス: &nbsp; AWS CodeBuild プロジェクトは、ソースコードの読み取りと Webhook の作成のためにリポジトリの認証情報を必要とします。これらの認証情報は、設定に基づいて異なる特定の権限を提供します。 ビルドの実行: ビルドプロセスでは、取得したソースコードを実行します。これには、ビルドスクリプト、依存関係の定義、プルリクエストからのテストファイルなどが含まれる場合があります。 ビルド環境: &nbsp; AWS CodeBuild 環境は、ビルドプロセスに必要な環境変数、AWS 認証情報、またはその他の設定データにアクセスできる場合があります。 信頼境界の確立 効果的なパイプラインのセキュリティは、さまざまなタイプのコードのコントリビューションに対する信頼境界を明確に定義することから始まります： 内部のコントリビューター : 組織のアクセス管理プロセスを通じて検証された、リポジトリへの書き込みアクセス権を持つチームメンバー。 外部のコントリビューター : フォークされたリポジトリからプルリクエストを送信する、組織外のコントリビューター。 自動処理 : ビルドプロセスの一部として手動レビューなしで実行されるコード。 これらの信頼境界は、特定の環境の脅威モデリングの基礎となります。 内部および信頼できる環境 では、コントリビューターのフィルタリングと最小権限制御を使用して、自動化により多く依存することができます。 パブリックおよびオープンソースプロジェクト では、信頼できないコントリビューションを処理する固有のリスクがあるため、より厳格な制御が必要です。これらの環境では、より厳格なWebhookフィルタリング、包括的な承認プロセス、または後で説明するセルフホスト GitHub Actions ランナーのアプローチが有効です。 重要な原則は、特定のリスクプロファイルとコントリビューターの信頼レベルに基づいて、セキュリティ制御と開発速度の間の適切なバランスを見つけることです。これらの考慮事項を念頭に置いて、現在の AWS CodeBuild Webhook 設定を評価および設定する方法を見ていきましょう。 セキュアな Webhook の設定 Webhook は、外部イベントが AWS CodeBuild プロセスをトリガーする際に推奨されるメカニズムです。適切に設定されると、Webhook はリポジトリの変更に応答してビルドプロセスを自動化する強力で効率的な方法を提供します。ただし、不適切な Webhook 設定は、信頼できないコードが特権環境で実行されることを許可してしまい、セキュリティの脆弱性が生じる可能性があります。 Webhook 設定のセキュリティは、どのイベントがビルドをトリガーするか、それらのビルドがどのレベルのアクセス権を持つか、ビルドプロセス中にどのコードが実行されるかをどれだけ正確に理解しているかにかかっています。このセクションでは、セキュアな Webhook 設定の作成、評価、設定、および維持に対する包括的なアプローチを提供します。 現在の Webhook の設定の評価 既存の AWS CodeBuild プロジェクトを確認して、現在の Webhook 設定を理解することから始めましょう。以下の AWS CLI コマンドを使用すると、この情報を体系的に収集することができます。： # リージョン内のすべてのCodeBuild プロジェクトを一覧表示 aws codebuild list-projects --region us-west-2 # 詳細な設定情報を取得して分析 aws codebuild batch-get-projects --region us-west-2 \ --names $(aws codebuild list-projects --region us-west-2 \ --query 'projects[*]' --output text | tr '\n' ' ') これらのコマンドを実行する際は、出力の webhook セクションに特に注意してください。このセクションには、どのリポジトリイベントがビルドをトリガーするかを正確に決定する filterGroups 設定が含まれています。 現在の設定を確認する方法を理解したところで、一般的な設定パターンとそのセキュリティへの影響を見ていきましょう。 Webhook 設定パターン 一般的な Webhook の設定パターンを理解することで、潜在的なセキュリティ上の懸念点を素早く特定し、適切な改善を実装できるようになります。以下のパターンは、 Webhook の設定に対するさまざまなアプローチを表し、それぞれに特定のセキュリティへの考慮事項があります。 注: これらのパターンを利用することは推奨されません。注意が必要な設定を特定するための参考として紹介しています。 見直しが必要な設定 – プルリクエストの自動処理 { "webhook": { "payloadUrl": "https://codebuild.us-west-2.amazonaws.com/webhooks", "filterGroups": [ [ { "type": "EVENT", "pattern": "PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED,PULL_REQUEST_REOPENED", "excludeMatchedPattern": false } ] ] } } この設定により、プルリクエストを作成できるコントリビューターがビルド環境でのコード実行をトリガーできるようになります。信頼できないリポジトリのコントリビューターからのプルリクエストの自動ビルドは利用しないことを強く推奨します。 即座に確認が必要な設定 – イベントフィルタリングなし { "webhook": { "payloadUrl": "https://codebuild.us-west-2.amazonaws.com/webhooks", "filterGroups": [] } } フィルタリングを行わないので、この設定では幅広いリポジトリイベントでビルドがトリガーされる可能性があります。 推奨されるセキュアな Webhook 設定 以下の設定は、自動化の利点と適切なセキュリティ制御のバランスを取るセキュリティのベストプラクティスを表しています。これらのパターンは、CI/CD の価値である開発速度を維持しながら、セキュリティリスクを軽減するのに役立ちます。 プッシュベースのビルド（ほとんどのユースケースで推奨） プッシュベースのビルドは、リポジトリへの書き込みアクセス権を持つユーザーのみがビルドをトリガーできることを確実にします。これは、コントリビューターがリポジトリのアクセス制御メカニズムを通じてすでに検査されていることを意味します。 { "webhook": { "payloadUrl": "https://codebuild.us-west-2.amazonaws.com/webhooks", "filterGroups": [ [ { "type": "EVENT", "pattern": "PUSH", "excludeMatchedPattern": false } ] ] } } 外部からのオープンソースコントリビューションに大きく依存している組織では、このアプローチは制限が厳しすぎる場合があります。例えば、外部のコントリビューターから毎日数十件のプルリクエストを受け取る人気のオープンソースプロジェクトでは、ビルドが実行される前に各コントリビューションを手動でマージする必要があり、コントリビューションのレビュープロセスが大幅に遅くなってしまいます。そのような場合、コントリビューターでフィルタリングされたビルドや、セルフホスト型の GitHub Actions ランナーのアプローチがより適切かもしれません。 コントリビューターによるビルドのフィルタリング（信頼できるコントリビューターのみ推奨） { "webhook": { "payloadUrl": "https://codebuild.us-west-2.amazonaws.com/webhooks", "filterGroups": [ [ { "type": "EVENT", "pattern": "PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED", "excludeMatchedPattern": false }, { "type": "GITHUB_ACTOR_ACCOUNT_ID", "pattern": "^(12345678|87654321|11223344)$", "excludeMatchedPattern": false } ] ] } } この設定により、特定の信頼できるコントリビューターからのプルリクエストのビルドが可能になります。 重要: フィルタリングは GitHub のアカウント ID に適用され、リポジトリの所有権には適用されません。フォークされたリポジトリから作業するコントリビューターは、ビルド環境で実行される信頼できないコードを引き続き持ち込める可能性があります。 環境でこれらの設定を実装する前に、スムーズな移行を促進するのに役立つ以下の重要な要素を検討してください。 Webhook 設定の実装手順 以下のWebhook セキュリティ対策を実装する際は、次のようなより広範なプラクティスを考慮してください： 脅威モデリング: アプローチを選択する前に、特定のリスクプロファイルを評価します。 Infrastructure as Code : 本番環境の実装には Infrastructure as Code（IaC）ツールを使用します。 段階的な実装: 観察期間を設けて変更を段階的に実装します。 テストとロールバック: 非本番環境で最初に変更を検証します。 以下の実装アプローチは、最も制限的なものからより自動化された設定へと移行します。組織のリスク許容度と運用要件に最も適したアプローチを選択してください。 この3段階のプロセスは、セキュリティコントロールを維持しながら最も制限的なアプローチからより自動化された設定へと移行します。各ステップは前のステップに基づいて構築され、パイプラインを保護するための多層的なセキュリティ対策を作成します。 注: 以下の例は、 AWS CLI を使用して説明します。同様の設定手順は、 AWS CodeBuild のプロジェクト設定から AWS マネジメントコンソールを使用して実行することも可能です。 ステップ1: プッシュのみのビルドを設定 プッシュベースのビルドは、検証されたコントビューターのみがビルドをトリガーできることを確実にします。このアプローチは、コントリビューターがコードをプッシュする前に、リポジトリのアクセス制御メカニズムを通じてすでに検査されている必要があるため、より安全です。 プッシュイベントでのみトリガーされるように Webhook を設定します： aws codebuild update-webhook \ --project-name your-project-name \ --filter-groups '[ [ { "type": "EVENT", "pattern": "PUSH", "excludeMatchedPattern": false } ] ]' ステップ2: ブランチベースのフィルタリングを実装 ブランチベースのフィルタリングは、特定のブランチへの変更に対してのみビルドがトリガーされることを確実にすることで、さらにセキュリティの層を追加します。このアプローチは、リポジトリ内のすべてのブランチが同じセキュリティ要件やリスクプロファイルを持つわけではないことを考慮しています。 例えば、 main や本番ブランチへの変更は、通常、フィーチャーブランチや開発ブランチへの変更よりも厳格なセキュリティ制御を必要とします。ブランチベースのフィルタリングを実装することで、各ブランチの重要性や公開範囲に基づいて、適切なセキュリティ対策を適用できます。 特定のブランチに対するフィルタリングを設定します： aws codebuild update-webhook \ --project-name your-project-name \ --filter-groups '[ [ { "type": "EVENT", "pattern": "PUSH" }, { "type": "HEAD_REF", "pattern": "^refs/heads/(main|develop|release/.*)$" } ] ]' ステップ3: コントリビューターのフィルタリングを設定 コントリビューターフィルタリングは、信頼できるコントリビューターに対しては自動化を許可し、その他のコントリビューターに対しては手動レビューを要求することで、プルリクエストのビルドを管理できます。このアプローチは、コントリビューターごとにリスクプロファイルが異なることを考慮し、それに応じた対応を行うものです。 コントリビューターフィルタリングを実装する最初のステップは、信頼できるコントリビューターの GitHub のユーザー ID を特定することです。 信頼できるコントリビューターの GitHub ユーザー ID を取得します： curl -H "Authorization: token YOUR_GITHUB_TOKEN" \ https://api.github.com/users/trusted-username 信頼できるコントリビューターのユーザー ID を取得したら、これらのコントリビューターに対してのみ自動ビルドを許可するように Webhook のフィルタリングを設定できます： aws codebuild update-webhook \ --project-name your-project-name \ --filter-groups '[ [ { "type": "EVENT", "pattern": "PULL_REQUEST_CREATED,PULL_REQUEST_UPDATED" }, { "type": "GITHUB_ACTOR_ACCOUNT_ID", "pattern": "^(1234567|2345678|3456789)$" } ] ]' 重要: コントリビューターの許可リストは、チームメンバーの変更に応じて継続的なメンテナンスが必要です。バージョン管理で Webhook の設定とコントリビューターリストを管理するために、 CloudFormation の例 のような Infrastructure as Code テンプレートの使用を検討してください。 Webhook フィルタリングは、どのイベントがビルドをトリガーするかを制御することで、最初のセキュリティレイヤーを提供します。ただし、包括的なパイプラインセキュリティには、ビルドが実行時に利用可能な権限と認証情報に関する追加の制御が必要です。次のセクションでは、適切なアクセス制御と認証情報管理を通じて多層的なセキュリティを実装する方法について説明します。 アクセス制御と認証情報管理 このセクションでは、ビルドプロセスで利用可能な権限を制限し、リポジトリアクセストークンに適切に権限範囲を設定し、潜在的なセキュリティ問題を封じ込めるための分離環境を作成する具体的なアプローチについて説明します。これらのプラクティスは、自動化された CI/CD ワークフローの運用上のメリットを維持しながら、多層的なセキュリティ対策を実装するために連携して機能します。 最小権限アクセスの実装 AWS CodeBuild プロジェクトは、ビルドプロセス中に AWS リソースにアクセスするために IAM サービスロールが必要です。最小権限の原則では、各ロールは意図された機能を実行するために必要な最小限の権限のみを持つべきです。異なるタイプのビルドに対して、目的に応じた個別の IAM ロールを作成することで、ビルド環境への不正アクセスの潜在的な影響を軽減できます。 以下の例は、異なるビルドシナリオに対する最小限の IAM ロールを構造化する方法を示しています。これらの例は、特定の要件に基づいてカスタマイズし、ビルドが実際に必要とする権限のみを追加する出発点として機能します。 サービスロール設定 特定のビルドタイプに必要な権限のみを提供する最小限の IAM ロールを作成します： テスト/検証ビルドロール { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "logs:CreateLogGroup", "logs:CreateLogStream", "logs:PutLogEvents" ], "Resource": "arn:aws:logs:*:*:log-group:/aws/codebuild/test-*" }, { "Effect": "Allow", "Action": [ "s3:GetObject" ], "Resource": "arn:aws:s3:::your-test-artifacts-bucket/*" } ] } リリースビルドロール（テスト用とは別に作成） { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject", "s3:GetObject" ], "Resource": "arn:aws:s3:::your-production-artifacts-bucket/*" }, { "Effect": "Allow", "Action": [ "ecr:BatchCheckLayerAvailability", "ecr:GetDownloadUrlForLayer", "ecr:BatchGetImage", "ecr:PutImage" ], "Resource": "arn:aws:ecr:*:*:repository/your-production-repo" } ] } CodeBuild セキュリティのための IAM Access Analyzer の活用 AWS IAM Access Analyzer は、ビルド実行時の実際の CloudTrail アクティビティに基づいて、 AWS CodeBuild サービスロールの最小権限ポリシーを生成できます。これはビルドが行う特定のAWS API呼び出しを分析することで、必要な権限を予測するための推測で行う作業を排除します。 CodeBuild プロジェクトを一定期間実行した後、 Access Analyzer のポリシー生成機能を使用して最適化されたポリシーを作成します。このアプローチは、必要な権限がすぐにはわからない複雑なビルドプロセスに特に価値があります。 詳細な実装手順については、 IAM Access Analyzer のドキュメント を参照してください。 認証情報の権限範囲と送信元認証 外部からのコントリビューションを処理する際、リポジトリアクセストークンに対する最小権限の原則が重要になります。不正なユーザーが信頼できないビルドを通じてトークンにアクセスした場合、トークンが適切に権限範囲設定されていれば、ビルドプロセスに必要な権限のみに潜在的な影響を制限できます。 このリスクを軽減するために、最小限の権限で GitHub のFine-grained Personal Access Token を設定します。不適切にアクセスされた場合でも、適切な権限範囲を持つトークンは、ソースコード（プルリクエストを通じてすでにアクセス可能）の読み取りとステータスメッセージの書き込みのみが可能です。コードのプッシュ、リポジトリ設定の変更、または他のリポジトリへのアクセスはできません。 以下の権限は、外部からのプルリクエストを処理するために必要な最小限のアクセスを表し、トークンの権限範囲を必須の操作のみに制限する方法を示しています： contents:read – リポジトリソースコードへの読み取り専用アクセス（プルリクエストを通じてすでにアクセス可能） statuses:write – コミットステータスメッセージの書き込みのみ（コードや設定の変更は不可） metadata:read – 基本的なリポジトリ情報（名前、説明、公開ステータス）へのアクセス 重要: 対象リポジトリのみに制限された Fine-grained Personal Access Token を使用してください。そうしないと、ビルドプロセスに必要な範囲を超えて他のリポジトリへのアクセスを許可してしまう可能性があります。 この権限範囲を設定するアプローチにより、トークンが不適切にアクセスされた場合でも、その潜在的な影響は、すでにアクセス可能な情報の読み取りとステータスメッセージの書き込みに限定されます。このトークンは、コードのプッシュ、リポジトリ設定の変更、Webhookの作成、または他のリポジトリへのアクセスはできません。 認証情報の保存とローテーション 以下の例は、AWS Secrets Manager を使用してこれらのトークンを安全に保存および参照する方法を示しています。 AWS Secrets Manager は、自動ローテーション機能、保存時および転送時の暗号化、ビルドログや設定ファイルでトークンが公開されることを防ぐきめ細かなアクセス制御を提供します。このアプローチにより、トークンアクセスの監査証跡を維持しながら、複数の CodeBuild プロジェクト間での一元的なトークン管理も可能になります。 # Fine-grained トークンをAWS Secrets Managerに保存 aws secretsmanager create-secret \ --name "codebuild/github-pat-limited" \ --description "Limited GitHub PAT for external PR processing" \ --secret-string '{"token":"ghp_your_limited_token_here"}' # 権限範囲が設定された認証情報で CodeBuild プロジェクトを作成 aws codebuild create-project \ --name external-pr-processor \ --source '{ "type": "GITHUB", "location": "https://github.com/your-org/your-repo.git", "sourceCredentialsOverride": { "serverType": "GITHUB", "authType": "PERSONAL_ACCESS_TOKEN", "token": "{{resolve:secretsmanager:codebuild/github-pat-limited:SecretString:token}}" }, "reportBuildStatus": false }' \ --service-role arn:aws:iam::account:role/minimal-test-build-role 一元化されたストレージにより、認証情報のローテーションが可能になり、インフラストラクチャの更新が必要なハードコードされたトークンと比較して、露出期間を最小限に抑えることができます。 ビルド環境の分離 適切なビルド環境のセキュリティ管理を確立することで、パイプラインの完全性を維持できます。このアプローチの基礎となるのは、テストビルドとリリースビルドの分離を実装することです。これにより、認証情報の権限昇格を防ぎ、潜在的な不正アクセスの範囲を制限することができます。 ネットワーク分離は、もう一つの保護層です。外部コードを処理するビルド専用の VPC を、慎重に制限されたアウトバウンドアクセスを持つ専用のセキュリティグループを作成して設定します。これらのセキュリティグループは、正当な依存関係をダウンロードするための HTTPS トラフィックなど、必要な接続のみを許可し、信頼できないコードによって悪用される可能性がある不要なネットワークアクセスをブロックする必要があります。 AWS CodeBuild プロジェクトを更新し、指定されたサブネットと制限されたセキュリティグループを含む適切な VPC 設定を使い、このネットワーク分離を活用するようにします。 人によるレビューゲートを持つマルチステージパイプラインセキュリティ 複数のパイプラインステージにわたるセキュリティコントロールの実装は、特に外部からのコントリビューションを処理する際に、適切な検証と承認プロセスを提供するのに役立ちます。このアプローチは、自動スキャンと人による監視を組み合わせて、本番環境に到達する前に問題を特定します。 コード検査の統合 ビルドプロセス中に Automated Security Helper などのセキュリティツールを自動的に実行するようにビルド仕様を設定しましょう。これらのツールは、コードセキュリティ問題と依存関係の問題をスキャンし、レビュー用の詳細なレポートを生成します。 すべてのスキャンが完了できるように、問題が見つかった場合でもビルドを最後まで続行するように構成した上で、対応が必要なセキュリティ上の問題が含まれるビルドは自動的に失敗させるようにします。すべてのスキャンの成果物を保存して、セキュリティチームに承認判断のための詳細情報を提供します。 手動承認によるゲート コードが自動セキュリティスキャンに合格した後、最終検証のために人間のレビュアーを関与させる手動承認ゲートを設定します。これにより、機密性の高い環境に進む前に適切な人間によるレビューを確保できます。 このセクションで解説されたアクセス制御と認証情報管理のプラクティスは、 AWS CodeBuild のパイプラインの多層防御セキュリティを実装するための具体的で実用的なアプローチを提供します。これらの制御は連携して複数の保護層を作成し、 CI/CD による自動化を価値あるものにする運用上の利点を維持します。 代替アプローチ – GitHub Actions のセルフホステッド ランナー AWS CodeBuild の GitHub Actions セルフホステッドランナー機能は、リポジトリ認証情報をビルド環境から分離し、 AWS CodeBuild Webhook 処理の代わりに GitHub Actions の実行フレームワークを使用することで、このガイドで説明した設定の問題に対処します。 外部からのコントリビューションを自動的に処理する必要がある組織では、適切なアクセス制御でランナーを設定し、永続的なアクセスを最小限に抑えるために一時的なランナーを使用し、ランナー管理の標準的なセキュリティ対策を適用してください。 設定の詳細は、 AWS CodeBuild ドキュメント をご覧ください。追加の実装ガイダンスについては、 AWS CodeBuild Managed Self-Hosted GitHub Action Runners のブログ投稿 をご参照ください。 監視とコンプライアンス 前のセクションで説明したセキュリティコントロールは、ビルド時の保護を提供しますが、包括的な多層防御セキュリティには、パイプラインのアクティビティと設定変更への継続的な可視化が必要です。監視とコンプライアンスの追跡は、セキュリティフレームワークの最終層として機能し、設定の逸脱の検出、アクセスパターンの監査、長期的なセキュリティ体制の維持に役立ちます。 AWS CloudTrail は、AWS CodeBuild を含む AWS サービスに対して行われた API 呼び出しの詳細なログを提供します。CloudTrail ログを有効にすることで、環境内のすべてのビルド関連アクティビティの包括的な監査証跡を作成できます。 AWS Config は、AWS CodeBuild プロジェクトの構成を時系列で追跡し、プロジェクトのインベントリと設定変更の完全な履歴を提供します。これには、Webhook の変更、リソースの関係性、環境全体でのコンプライアンス追跡が含まれます。AWS Config を設定して、AWS CodeBuild プロジェクトを監視し、Webhook フィルターなどのセキュリティ上重要な設定が変更されたときに通知を受け取るようにすることができます。 詳細については、AWS CodeBuild のドキュメントにあるAWS Config のサンプル をご参照ください。 結論 AWS CodeBuild パイプラインの多層防御のセキュリティ対策を実装するには、さまざまなセキュリティ考慮事項に対処する階層化された制御が必要です。最も効果的なアプローチは、Webhook フィルタリング、アクセス制御、認証情報管理、監視を組み合わせて包括的な保護を提供することです。このガイドで説明したこれらの多層的なプラクティスを実装することで、堅牢なパイプラインセキュリティを確立しながら開発速度を維持できます。 覚えておくべき重要な原則： まず脅威モデルを評価する – 異なるプロジェクトには異なるセキュリティアプローチが必要です 異なるタイプのコントリビューター間で明確な信頼境界を確立する Webhookフィルタリングを使用してビルドがトリガーされるタイミングを制御する ビルド環境に最小権限アクセスを実装する AWS Config とCloudTrail を使用して設定を定期的に監視および監査する AWS Secrets Manager または SSM Parameter Store にシークレットを保存し、ローテーションを有効にする AWS CodeBuild は、パイプラインを価値あるものにする運用上のメリットを維持しながら、これらのセキュリティ対策を実装する柔軟性を提供します。特定のリスクプロファイルと運用要件に基づいて、このガイドの設定と軽減策を適用してください。組織のニーズが進化する中でパイプラインのセキュリティを維持するために、定期的な設定の確認と更新が役立ちます。 CI/CDセキュリティベストプラクティスを実装するための追加の実用的なガイドにご期待ください。この投稿について質問やフィードバックがある場合、最も役立つトピックの提案を含めて、 re:Post : Begimher で新しいスレッドを開始するか、 AWS サポートにお問い合わせ ください。 翻訳は、ソリューションアーキテクトの金森が担当しました。原文は こちら です。 Daniel Begimher Danielは、クラウドセキュリティ、アプリケーションセキュリティ、インシデント対応ソリューションを専門とする Global Services Security 組織のシニアセキュリティエンジニアです。AWS Security and Compliance Technical Field Community 内の Application Securityフォーカスエリア を共同リードし、すべてのAWS認定を保持し、オープンソースのコードスキャンツールである Automated Security Helper（ASH） を作成しました。

8 月 4 日週は、生成 AI 機能から基盤サービスの強化まで、さまざまなイノベーションをご紹介します。これらのアップデートは、AI を活用したアプリケーションの構築、データベースの管理、クラウドインフラストラクチャの最適化など、より高度で堅牢かつ柔軟なアプリケーションの構築に役立ちます。 7 月 28 日週のリリース 私が 7 月 28 日週に注目したリリースを以下に記載しました: Amazon DocumentDB – Amazon DocumentDB サーバーレスが利用可能になりました 。これにより、オンデマンドでフルマネージドの MongoDB API 互換のドキュメントデータベースサービスが提供されます。詳細については、 Channy の投稿 をご覧ください。 Amazon Q Developer CLI – カスタムエージェントを作成 できるようになりました。これにより、コードレビューやトラブルシューティングなどの特殊なタスクを実行する際に、より効果的に CLI エージェントをカスタマイズできます。 このブログで詳細をご覧ください 。 Amazon Bedrock Data Automation – ドキュメント処理用の DOC/DOCX ファイルと、ビデオ処理用の H.265 エンコードビデオファイルをサポート するようになりました。これにより、マルチモーダルデータ分析パイプラインの構築が容易になります。 Amazon DynamoDB – Amazon DynamoDB データモデリングのモデルコンテキストプロトコル (MCP) ツール を導入しました。これによりは、アプリケーション要件を DynamoDB データモデルに変換するための構造化された自然言語主導のワークフローが提供されます。 AWS Lambda – レスポンスストリーミングが、デフォルトの最大レスポンスペイロードサイズの 200 MB をサポートするようになりました 。これは以前の 10 倍になります。Lambda レスポンスストリーミングは、レスポンスペイロードをクライアントにプログレッシブにストリーミングして戻すアプリケーションを構築するのに役立ちます。これにより、最初のバイトまでの時間 (TTFB) パフォーマンスを短縮することで、レイテンシーの影響を受けやすいワークロードのパフォーマンスを向上させます。 AWS 用 Powertools – Powertools for AWS Lambda (Java) の v2 をご紹介します 。これは、サーバーレスのベストプラクティスを実装するのに役立ち、 AWS Well-Architected の推奨事項を直接翻訳できる開発者ツールキットです。 Amazon SNS – 3 つの追加のメッセージフィルタリング演算子 をサポートするようになりました: ワイルドカードの一致、ワイルドカード以外の一致、およびプレフィックス以外の一致。SNS が標準トピックのメッセージグループ ID もサポートするようになりました。これにより、サブスクライブされた Amazon SQS 標準キューのフェアキュー機能が有効になります。 Amazon CloudFront – オリジンのタイムアウト制御を強化する 2 つの機能を提供 するようになりました: レスポンス完了タイムアウトと、Amazon S3 オリジンのカスタムレスポンスタイムアウト値のサポート。これらの機能により、遅いオリジンや応答しないオリジンの処理方法をより細かく制御できます。 Amazon EC2 – シャットダウン状態で停止している EC2 インスタンスを強制終了 できるようになりました。 Amazon EC2 Auto Scaling – AWS Lambda 関数を EC2 Auto Scaling ライフサイクルフックの通知ターゲットとして使用 できるようになりました。例えば、これを使用して、インスタンスが待機状態になったときにカスタムアクションをトリガーできます。 Amazon SES – 単一の SES アカウント内に独立したテナントをプロビジョニング し、自動レピュテーションポリシーを適用して E メール送信を管理できるようになりました。 AWS マネジメントコンソール – コンソールナビゲーションバーのサービスメニューに AWS アプリケーションを表示 できるようになりました。このビューでは、すべてのアプリケーションを表示でき、アプリケーションを選択して、関連付けられたすべてのリソースを表示できます。 Amazon Connect – Amazon Connect UI ビルダーは、構造化されたワークフローを構築する際の複雑さを軽減するために、 ユーザーインターフェイスを更新しました 。また、 新しい UI エクスペリエンスによって予測編集が簡素化され 、計画の精度が向上しました。 連絡先コントロールパネルのユーザーインターフェイスが更新され、より直感的になりました 。Amazon Connect では、 エージェントワークスペースに新しいアクションとワークフローも導入されました 。これらのアクションは、バックグラウンドで実行されているサードパーティアプリケーションを活用しています。 AWS Clean Rooms – Clean Rooms のステータス変更に関するイベントを Amazon EventBridge に公開 するようになりました。これにより、企業とそのパートナーは互いの基盤となるデータを公開したりコピーしたりすることなく、集合データセットを分析して共同作業する方法がさらに簡素化されます。 AWS Entity Resolution – Levenshtein Distance、Cosine Similarity、および Soundex アルゴリズムを使用したルールベースのファジーマッチング を導入しました。これにより、断片化され、一貫性がなく、不完全であることが多いデータセット全体でコンシューマーレコードを解決できるようになります。 その他のアップデート その他の興味深いプロジェクト、ブログ記事、ニュースをいくつかご紹介します: Amazon Strands Agents SDK: エージェントアーキテクチャとオブザーバビリティに関する技術的な詳細情報 – シングルエージェントアーキテクチャとマルチエージェントアーキテクチャを構築するためのわかりやすい概要です。 Strands Agents SDK と Tavily を使ってダイナミックなウェブリサーチエージェントを構築 – 新しいツールをいかに簡単に追加できるかを示しています。 Amazon Nova による構造化された出力: ビルダー向けガイド – デコードが制限されたネイティブツールの使用に加えて実装された優れたヒントです。 Amazon Bedrock Data Automation を使用して配布資料ノートの作成を自動化 – ウェビナーの記録を包括的な配布資料に変換するための自動化されたサーバーレスソリューションを構築するソリューションです。 Amazon Q Developer CLI と MCP を使用して、ベストプラクティスに従って最新のサーバーレスソリューションを構築 – AWS サーバーレス MCP サーバーを追加します。 Amazon Bedrock AgentCore ブラウザツールのご紹介 – AI エージェントがウェブサイトとシームレスに対話できるようにするこのツールの詳細です。 Amazon Bedrock AgentCore コードインタープリターのご紹介 – 隔離されたサンドボックス環境で AI エージェントがコードを安全に実行できるようにする完全マネージド型サービスです。 近日開催予定の AWS イベント 近日開催予定のイベントにサインアップできるように、カレンダーを確認してください: AWS re:Invent 2025 (2025 年 12 月 1 日〜5 日、Las Vegas) — AWS の主力年次カンファレンスでは、ピアツーピア学習、専門家主導のディスカッション、貴重なネットワーキングの機会を通じて、共同イノベーションを提供します。 AWS Summits – クラウドコンピューティングコミュニティが集まり、交流し、協力し、AWS について学ぶことができる無料のオンラインイベントと対面イベントに参加してください。最寄りの都市、 メキシコシティ (8 月 6 日) および ジャカルタ (8 月 7 日) で開催されるイベントにご登録ください。 AWS Community Days – 世界中のエキスパート AWS ユーザーと業界リーダーがリードするテクニカルディスカッション、ワークショップ、ハンズオンラボが盛り込まれたコミュニティ主導のカンファレンスにぜひご参加ください。日程は、 オーストラリア (8 月 15 日)、 アドリア (9 月 5 日)、 バルト諸国 (9 月 10 日)、 アオテアロア (9 月 18日) です。 AWS Builder Center に参加して、AWS コミュニティのビルダーを学び、構築し、交流しましょう。&nbsp;今後開催される追加の 対面イベント と デベロッパー向けのバーチャルイベント をこちらでご覧ください。 8 月 4 日週のニュースは以上です。8 月 11 日週の Weekly Roundup もお楽しみに! – Danilo 原文は こちら です。

AWS のデベロッパーアドボケイトとして、私は複数の AWS リージョン にまたがって重要なアプリケーションを運用している多くのエンタープライズ組織と協業してきました。これらの組織がしばしば共有する重要な懸念事項は、自社のリージョンフェイルオーバー戦略への信頼の欠如です。すなわち、必要なときに機能するかどうか、すべての依存関係が特定されているかどうか、チームが手順を十分に練習しているかどうかについて、自信が持てないのです。従来のアプローチでは、リージョンレベルの切り替えに向けた準備状況が不明確になることがよくあります。 8 月 1 日、 Amazon Application Recovery Controller (ARC) のリージョン切り替えを発表します。これは、組織が自信をもってリージョン切り替えを計画、練習、オーケストレートできるようにし、リージョン間のリカバリオペレーションに関する不確実性を排除する、可用性の高いフルマネージド機能です。リージョン切り替えは、AWS 上のマルチリージョンアプリケーションのリカバリをオーケストレートするのに役立ちます。ある AWS リージョンから別の AWS リージョンにアプリケーションの運用を切り替える必要がある場合に、AWS のサービスとアカウント全体でリカバリタスクを調整および自動化する一元化されたソリューションを提供します。 多くのお客様は、可用性の要件を満たすために、ビジネスクリティカルなアプリケーションを複数の AWS リージョンにデプロイしています。あるリージョンのアプリケーションに運用イベントが影響する場合、運用を別のリージョンに切り替えるには、コンピューティング、データベース、DNS など、異なる AWS サービス間で複数のステップを調整する必要があります。この調整には通常、アプリケーションの進化に合わせて定期的なテストと更新が必要となる複雑なスクリプトの作成と維持が必要です。さらに、複数のアプリケーション間でのリージョン切り替えの進行状況をオーケストレートおよび追跡し、コンプライアンスのためにリカバリが正常に完了したことについての証拠を提供するには、多くの場合、手作業によるデータ収集が必要になります。 リージョン切り替えは、リージョンレベルのデータプレーンアーキテクチャ上に構築されており、リージョン切り替えプランはアクティブ化されるリージョンから実行されます。この設計により、切り替え中に影響を受けるリージョンへの依拠が排除され、実行は切り替え元のリージョンから独立しているため、より回復力の高いリカバリプロセスが実現します。 ARC リージョン切り替えを利用したリカバリプランの構築 ARC リージョン切り替えを使用すると、リージョン間でアプリケーションを切り替えるために必要となる具体的なステップを定義するリカバリプランを作成できます。各プランには、AWS リソースに対するアクションを表す実行ブロックが含まれています。リリース時点では、リージョン切り替えは 9 種類の実行ブロックをサポートしています: ARC リージョン切り替えプラン実行ブロック – 他のリージョン切り替えプランを参照することで、複数のアプリケーションが、アクティブ化するリージョンに切り替える順序をオーケストレートすることを可能にします。 Amazon EC2 Auto Scaling 実行ブロック – ソースリージョンのキャパシティの指定された割合に合わせて、ターゲットリージョンの Amazon EC2 コンピューティングリソースをスケールします。 ARC ルーティングコントロール 実行ブロック – ルーティングコントロールの状態を変更し、DNS ヘルスチェックを使用してトラフィックをリダイレクトします。 Amazon Aurora Global Database 実行ブロック – Aurora Global Database のために、データ損失の可能性があるデータベースフェイルオーバー、またはデータ損失ゼロのスイッチオーバーを実行します。 手動承認実行ブロック – リカバリワークフローに承認チェックポイントを追加し、チームメンバーが続行する前に確認および承認できるようにします。 カスタムアクション AWS Lambda 実行ブロック – アクティブ化または非アクティブ化するリージョンで Lambda 関数を実行することで、カスタムリカバリステップを追加します。 Amazon Route 53 ヘルスチェック実行ブロック – フェイルオーバー中にアプリケーションのトラフィックをリダイレクトするリージョンを指定できるようにします。リージョン切り替えプランを実行すると、Amazon Route 53 ヘルスチェックの状態が更新され、DNS 設定に基づいてトラフィックがリダイレクトされます。 Amazon Elastic Kubernetes Service (Amazon EKS) リソーススケーリング実行ブロック – リカバリ中に、ソースリージョンのキャパシティの指定された割合に合わせて、ターゲットリージョンの Kubernetes ポッドをスケールします。 Amazon Elastic Container Service (Amazon ECS) リソーススケーリング実行ブロック – ソースリージョンのキャパシティの指定された割合に合わせて、ターゲットリージョンの ECS タスクをスケールします。 リージョン切り替えは、30 分ごとにリソース設定と AWS Identity and Access Management (IAM) の許可をチェックすることで、プランを継続的に検証します。実行中、リージョン切り替えは各ステップの進行状況をモニタリングし、詳細なログを提供します。実行ステータスは、リージョン切り替えダッシュボードと、実行の詳細ページの下部を通じて確認できます。 コストと信頼性のバランスをとるのに役立つよう、リージョン切り替えは、スタンバイリソースを柔軟に準備できる機能を提供します。リージョン切り替えのスケーリング実行ブロックを使用して、リカバリ中に宛先リージョンでターゲットとすることを希望するコンピューティングキャパシティの割合を設定できます。リカバリ中にトラフィックの急増が見込まれる重要なアプリケーションでは、100% を超えるキャパシティにスケールすることを選択できます。また、割合を低く設定すると、全体的な実行時間を短縮するのに役立ちます。ただし、スケーリング実行ブロックのいずれかを使用してもキャパシティが保証されるわけではなく、実際のリソースの可用性はリカバリ時における宛先リージョンのキャパシティに依存することにご留意ください。可能な限り最良の結果を得るために、リカバリプランを定期的にテストし、スタンバイリージョンで適切な Service Quotas を維持することをお勧めします。 ARC リージョン切り替えには、企業およびリージョン全体のリージョン切り替えプランのステータスをモニタリングするために使用できるグローバルダッシュボードが含まれています。さらに、現在のコンソールリージョン内の実行のみを表示するリージョンレベルの実行ダッシュボードがあります。このダッシュボードは、各リージョン全体で高可用性を実現するように設計されているため、運用イベント中に使用できます。 リージョン切り替えを使用すると、リージョン切り替えプランを含むアカウントとは別のアカウントでリソースをホストできます。プランが、プランをホストしているアカウントとは異なるアカウントのリソースを使用する場合、リージョン切り替えは executionRole を使用して crossAccountRole を引き継ぎ、それらのリソースにアクセスします。さらに、リージョン切り替えプランは AWS Resource Access Manager (AWS RAM) を使用して一元管理し、複数のアカウント間で共有できるため、組織全体でリカバリプランを効率的に管理できます。 仕組みを見てみましょう リージョン切り替えプランを作成および実行する方法を説明します。このデモは 3 つの部分で構成されています。まず、リージョン切り替えプランを作成します。その後、ワークフローを定義します。最後に、トリガーを設定します。 ステップ 1: プランを作成する AWS マネジメントコンソール の Application Recovery Controller のセクションに移動します。左側のナビゲーションメニューで [リージョン切り替え] を選択します。その後、 [リージョン切り替えプランを作成] を選択します。 プランに名前を付けたら、 [マルチリージョンリカバリアプローチ] (アクティブ/パッシブまたはアクティブ/アクティブ) を指定します。[アクティブ/パッシブ] モードでは、2 つのアプリケーションレプリカが 2 つのリージョンにデプロイされ、トラフィックはアクティブなリージョンにのみルーティングされます。パッシブリージョンのレプリカは、リージョン切り替えプランを実行することでアクティブ化できます。 その後、 [プライマリリージョン] と [スタンバイリージョン] を選択します。オプションで、 [必要な目標復旧時間 (RTO)] を入力できます。サービスはこの値を使用して、リージョン切り替えプランの実行にかかる時間に関するインサイトを、希望する RTO との関係で提供します。 [プラン実行 IAM ロール] を入力します。これは、実行中にリージョン切り替えが AWS サービスを呼び出すことを許可するロールです。選択したロールに、サービスによって呼び出されるための許可が付与されており、ARC が動作するために必要な最小限の一連の許可が含まれていることを確認します。詳細については、ドキュメントの IAM 許可のセクション をご覧ください。 ステップ 2: ワークフローを作成する 2 つの [プランの評価ステータス] の通知が緑色になったら、ワークフローを作成します。開始するには、 [ワークフローを構築] を選択します。 プランを使用すると、リージョン切り替え実行ブロックを使用してアプリケーションを復旧する特定のワークフローを構築できます。複数のアプリケーションまたはリソースがアクティブ化するリージョンにリカバリする順序をオーケストレートするために、順次または並行して実行される実行ブロックを含むワークフローを構築できます。プランは、特定のリージョンをアクティブ化または非アクティブ化できるようにするこれらのワークフローで構成されます。 このデモでは、グラフィカルエディタを使用してワークフローを作成します。ただし、ワークフローを JSON で定義することもできます。この形式は、オートメーションや、ワークフロー定義をソースコード管理システム (SCMS) や AWS CloudFormation などの Infrastructure as Code (IaC) ツールに保存する場合に適しています。 [ワークフロービルダー] のタイトルの横にある対応するタブを選択すると、 [設計] ビューと [コード] ビューを切り替えることができます。JSON ビューは読み取り専用です。グラフィカルエディタを使用してワークフローを設計し、JSON に相当するものをコピーして IaC プロジェクトファイルと一緒に保存しました。 リージョン切り替えは、30 分ごとに評価を開始し、リカバリ戦略を検証します。ワークフローで定義されたすべてのアクションが実行時に成功するかどうかを定期的にチェックします。このプロアクティブな検証では、アカウントおよびリージョン全体の IAM 許可やリソースの状態など、さまざまな要素を評価します。これらの依存関係を継続的にモニタリングすることで、リージョン切り替えは、リカバリプランの実行可能性を維持し、実際の切り替えオペレーションに影響が及ぶ前に潜在的な問題を特定するのに役立ちます。 ただし、テストされていないバックアップは信頼できるバックアップではないのと同様に、テストされていないリカバリプランは真に検証済みとみなすことはできません。継続的な評価は強固な基盤を提供しますが、プランの有効性を検証し、実際のリカバリ時間を把握するとともに、チームがリカバリ手順に精通しているようにするために、テストシナリオで定期的にプランを実行することを強くお勧めします。この実践的なテストは、ディザスタリカバリ戦略における信頼性を維持するために不可欠です。 ステップ 3: トリガーを作成する トリガーは、作成したワークフローをアクティブ化する条件を定義します。これは、一連の CloudWatch アラームとして表現されます。アラームベースのトリガーはオプションです。手動トリガーでリージョン切り替えを使用することもできます。 コンソールのリージョン切り替えページから、 [トリガー] タブを選択し、 [トリガーを追加] を選択します。 プランで定義した各リージョンについて、 [トリガーを追加] を選択し、リージョンをアクティブ化するトリガーを定義します。 最後に、リージョン切り替えがリージョンのアクティブ化をトリガーするために使用するアラームとその状態 ([OK] または [アラーム状態]) を選択します。 これで、リージョン切り替えを使用してリージョンを切り替えるプランの実行をテストする準備が整いました。アクティブ化するリージョン (ワークフローのターゲットリージョン) からプランを実行し、その特定のリージョンのデータプレーンを使用することが重要です。 AWS コマンドラインインターフェイス (AWS CLI) を使用してプランを実行する方法は次のとおりです: aws arc-region-switch start-plan-execution \ --plan-arn arn:aws:arc-region-switch::111122223333:plan/resource-id \ --target-region us-west-2 \ --action activate 料金と利用可能なリージョン リージョン切り替えは、すべての商用 AWS リージョンで、プランごとに 70 USD/月でご利用いただけます。各プランには最大 100 個の実行ブロックを含めることができます。また、親プランを作成して最大 25 個の子プランをオーケストレートすることもできます。 マルチリージョンリカバリソリューションの構築と維持に費やすエンジニアリングの労力を直接見てきた私は、お客様にとって、リージョン切り替えがこのプロセスの自動化にどのように役立つのかを目にするのを楽しみにしています。ARC リージョン切り替えの使用を開始するには、 ARC コンソールにアクセスして、最初のリージョン切り替えプランを作成してください 。リージョン切り替えの詳細については、 Amazon Application Recovery Controller (ARC) のドキュメント にアクセスしてください。また、マルチリージョンアプリケーションのためのリージョン切り替えの使用に関するご質問は、AWS アカウントチームまでお問い合わせください。 マルチリージョンアプリケーションの回復力を高めるためにリージョン切り替えをどのように使用しているのかについて、ぜひお聞かせください。 – seb 原文は こちら です。

教育業界において生徒一人ひとりに最適化された学習体験の提供や、教員の業務効率化が重要な課題となっています。近年の生成 AI の登場は、これらの課題に対する有効なソリューションとして期待されています。特に生成 AI を取り巻く技術は目覚ましい発展を遂げており、教育分野での活用可能性はますます拡大しています。こうした状況を踏まえて、2025 年 6 月 25 日・26 日に開催された AWS Summit Japan 2025 において生成 AI 技術を活用した教育業界向けのソリューションのデモ展示をいたしました。AI エージェントを活用した「Education AI Assistant」と、RAG を用いて個別最適な学習計画を作成する「Teaching Plan Personalizer (TP2)」の 2 つのデモを通じて、現在の生成 AI 技術が教育分野でどのような可能性を秘めているかをご紹介しました。 当日は教育業界の関係者を中心に多くの来場者の皆様にお越しいただき、熱心にご覧いただくとともに、活発な議論を交わすことができました。また教育機関での活用だけでなく、企業内研修や人材育成の観点からも高い関心をお寄せいただき、今回のデモの幅広い応用可能性を実感いたしました。 本ブログでは、Summit 会場にてご紹介したデモの詳細を解説し、現在の生成 AI 技術が個別最適な学習の実現にどのように貢献できるかを、より多くの皆様にお伝えしたいと思います。以下では、2 つのデモの展示内容について詳しくご紹介いたします。 図 1: AWS Summit Japan 2025 教育チーム出展ブースの当日の様子。 デモ展示 1 : Education AI Assistant Education AI Assistant は教員が利用するシステムを想定して開発されたデモです。主に 2 つの機能を持ち、1 つは教育ダッシュボード画面に埋め込まれた成績データ分析エージェント機能で、もう 1 つは教材作成に特化したエージェント機能です。またこれらがマルチエージェントシステムとして動作するチャット画面も実装しました。これらはいずれも AI エージェントという技術を使って実現されています。AI エージェントは単にテキストを生成するだけでなく、ツールを関連づけることでタスクに対して適切なツールを選択し自律的に考え実行をします。Education AI Assistant は教育業界の課題に対する、AI エージェントの仕組みを用いたソリューションデモとなっています。 以下では成績データ分析エージェントおよび教材作成エージェントの詳細をご紹介します。 図 2 : Education AI Assistant のアーキテクチャ図。 成績データ分析エージェント 解決したい課題 個別最適な学習を実現する上で、学習者のデータに基づいた現状の把握が欠かせません。そのため学習者の成績や学習履歴といったデータを収集することがまずは重要になります。データを集めたのちに、データを適切に分析し解釈し次のアクションに繋げてようやくデータの価値が生まれます。しかしこのようなデータ分析はスキルや経験を要する作業です。 生成 AI を活用したソリューションアプローチ 上記課題を踏まえて、今回のデモでは生成 AI を用いてデータ分析を実行する機能を実装しました。成績データの保存されたデータベースに対して生成 AI が自然言語から SQL 文を生成し、SQL クエリを実行します。AWS の生成 AI サービスである Amazon Bedrock には RAG 機能を実装するための Amazon Bedrock ナレッジベース という機能があり、自然言語から構造化データを取得する機能をサポートしています。この機能を活用することで、データ分析が可能となります。ユーザーがデータ分析を開始するボタンを押すと、AI エージェントにデータ分析に関するリクエストが送られます。AI エージェントはデータ分析のプランを立てます。そしてそれに基づきナレッジベースを使って自然言語から適切な SQL クエリを生成し実行します。十分に分析が完了するまで必要な SQL クエリの生成・実行を AI エージェントは繰り返します。こうしてデータ分析が完了すると、最後に人が読んでわかりやすい形式に文章として分析結果を生成します。（図 3） 図 3 : 成績データ分析エージェントのデモ。ユーザーはまず生徒名でデータをフィルタリングする。その後、分析を行うボタンをクリックすると AI エージェントが呼び出される。AI エージェントは自身が考えたプランに従って成績データに対し SQL 分析を実行する。最終的な分析結果が、基本情報・成績推移・強み・課題といった項目に分かれて表示される。 成績データ分析エージェントがもたらす価値 AI エージェントと自然言語クエリを組み合わせることで、SQL 文の生成やクエリの実行、さらにクエリの結果に基づいた更なるクエリの実行を生成 AI が自律的に実施します。これにより必ずしも高度なデータ分析スキルがなくとも、生徒のデータからインサイトを得ることができます。分析クエリを AI エージェントが得られた結果に基づいて考えるため、定型的な分析のフローよりも柔軟な分析が可能になります。さらに今回のデモでは、得られた結果から次に取り組むべきアクションの提案まで表示させています。データを分析し結果を解釈し次のアクションに繋げるという一連のフローをサポートする機能になっている点も本デモのポイントとなります。 アーキテクチャ・技術的詳細など 図 4 : 成績データ分析エージェントの構成。構造化 RAG のナレッジベースと、SQL 静的解析ツールのアクショングループを紐づけている。 成績データ分析エージェントの実装では、Amazon Bedrock のエージェント機能である Amazon Bedrock Agents を利用しています。また、自然言語から SQL クエリを生成する部分では構造化データに対するナレッジベースを利用しています。これはデータソースとして Amazon Redshift をサポートしているため、成績データを Amazon Redshift に保存しています。また生成されるクエリの精度を高める工夫として SQL 静的解析ツールをアクショングループとして作成しています。アクショングループとは Bedrock Agents が使えるツールのことで、実装は AWS Lambda を用いています。SQL 静的解析ツールでは、SQL の文法チェックやデータベーススキーマ（テーブル名、カラム名など）との整合性の検証を行い、実行前に SQL クエリの正確性を確保しています。これらアクショングループやナレッジベースをエージェントに紐づけることでエージェントはタスクに応じて適切なツールを選択し実行します。 発展/展望 今回のデモでは生徒の成績データを対象にデータ分析を行い、クラス全体の傾向を掴んだり個別最適な学習に活かせることをお見せしました。今回は成績データを Amazon Redshift に保存していましたが、実際には Amazon Relational Database Service (Amazon RDS) などその他のデータベースに保存されていることも考えられます。AI エージェントが利用可能なツールの情報や仕様をやり取りするプロトコルとして MCP (Model Context Protocol) があります。利用したい API や実行したいアクションを MCP Server として構築することで、AI エージェントが利用できるようになります。AWS サービスに接続するための MCP Server も公開されており、例えば Amazon Aurora や Amazon DynamoDB などのデータベースに AI エージェントがアクセスできます。このように Amazon Redshift 以外のデータソースにも自然言語クエリを実行できるツールを作成することができます。こうしたものをエージェントに紐づけることで多様なデータソースに対して分析可能な AI エージェントが実装可能です。また活用すべきデータは成績データにとどまりません。出席状況や体調に関わるデータなどもユースケースに応じては活用すべきです。他にも授業の様子など生徒の活動記録といった非構造化データも活用の余地があります。このように今後の発展として、様々な角度から生徒の状況を理解するためにさらに多様なデータを扱える AI エージェントの実現が挙げられます。 教材作成エージェント 次に Education AI Assistant のもう一つの機能である、教材作成エージェントをご紹介します。 解決したい課題 個別最適な学習を提供する上で、生徒一人ひとりに合った教材の作成は欠かせません。2025 年 6 月にデジタル庁・総務省・文部科学省・経済産業省から公開された 教育 DX ロードマップ においても子供たちを取り巻く背景として、自分らしい学びの実現に課題があると言及されています。生徒の興味関心や理解度に応じて、教材の内容や形式を柔軟に変えられることができれば個別最適学習の実現に近づきます。一方で一人ひとりに対して教材をカスタマイズすることは時間のかかる作業であり現実的とはいえません。 生成 AI を活用したソリューションアプローチ 上記の課題に対して、生成 AI を用いた教材作成機能のデモを開発しました。生成 AI を用いることで個別の要件も柔軟に教材に反映させることができます。一方で単に生成 AI に教材を作らせようとすると、知識に限界があったり計算間違いの可能性を孕んでいたりと課題があります。そこで本デモでは AI エージェントに Web 検索や計算(四則演算)のツールを組み合わせることを考えました。これにより、生成 AI が知らないトピックでも Web 検索によって知識を獲得でき、計算が必要な教材作成では計算ツールを使って正しい結果を得ることができます。さらに学習指導要領に則った教材を作成するために、学習指導要領をデータソースとした RAG 機能も組み合わせています。 図 5 : 教材作成エージェントのデモ。ここでは英語の会話の練習をテーマに設定している。また詳細な指示として、「直近 1 ヶ月の日本の行事やイベントをテーマにすること」と指示を与えている。指示が AI エージェントに送られ、AI エージェントは要件を満たす教材作成を行う。行事やイベントの情報を取得するために Web 検索をしながら英語の教材が生成されている。 教材作成エージェントがもたらす価値 教材作成エージェントを用いることで、要点を押さえつつ生徒一人ひとりに合わせた教材が作成可能です。特に教員はいくつかの入力項目を埋めるだけであとは自動的に作成されるため、カスタマイズされた教材を効率よく作成できます。また四則演算ツールは生成された問題の検算や計算問題の解答生成に活用できます。 Web 検索ツールを使うことでリアルタイムな情報やより専門的な情報にもアクセスすることができます。加えて学習指導要領の RAG と組み合わせる事で、問うべきポイントを重視した教材生成も可能になります。このように生成 AI にいくつかのツールを組み合わせることで教材の質向上にもつながっています。最後に、本デモでは出力形式を HTML のソースコードとしました。これをレンダリングすることでそのまま教材として使えるようなビジュアルでのアウトプットを可能にしています。 アーキテクチャ・技術的詳細など 図 6 : 教材作成エージェントの構成。ナレッジベースを利用した学習指導要領に対する RAG と、四則演算などのアクショングループを組み合わせている。 教材作成エージェントの実装においても、Bedrock Agents を利用して AI エージェントを構築しました。利用可能なツールとして日時取得・四則演算・Web 検索といったツールを組み合わせています。これらは AWS Lambda 上で実装され、アクショングループとしてエージェントに紐づけています。また、学習指導要領をデータソースとした RAG に関しては Amazon Simple Storage Service (Amazon S3) にデータを保存しています。ナレッジベースを利用して、ベクトル化したデータを Amazon OpenSearch Serverless に取り込んでいます。教材作成エージェントは必要に応じてナレッジベースを使ってベクトル検索を実行し、学習指導要領のコンテキストを取得し、それを基に適切な教材を生成します。 発展/展望 本デモではデータソースとして学習指導要領を用いましたが、これに加えて教科書や問題集のデータとの連携が今後の発展として考えられます。教科書と連携すれば生徒が実際に勉強した内容に沿った問題作成が可能になります。また問題集や過去問題などと連携することで類題生成も可能になり、試験対策に活用可能です。また、実際のデモではスーパーバイザーエージェントを介したデータ分析エージェントと教材作成エージェントのコラボレーションも実装しました。データ分析エージェントがデータ分析を実施して得意分野や苦手分野を把握し、結果に基づいて教材作成エージェントが得意を伸ばす教材や苦手をフォローする教材を作成する、というフローが実現できます。 デモ展示 2: Teaching Plan Personalizer (TP2) 図 7 : TP2 のデモ。生徒の習熟度や家庭環境などを選択する。その後指導計画を作成するためのプロンプトが生成される。生成されたプロンプトを確認したのちに、指導計画作成のボタンを押す。生成 AI がデータソースを参照しながら指導内容や指導の手立てを生成する。 解決したい課題 「 教育データの利活用に係る論点整理(中間まとめ)概要 」において、きめ細かい指導・支援が目的として掲げられています。教員・子供・保護者視点で個別最適化された指導や支援は理想的である一方で、教員視点で以下の課題が発生しうると考えています。 生徒ごとの状況を加味した指導・支援計画作成の負荷増大 学年、科目ごとの習熟度や家庭環境など生徒ごとにきめ細やかに対応する必要が出てくる 教員による計画の品質差異 新任と中堅教員では経験による計画内容の品質や計画作成に割く時間に差異が出る 中堅以上の教員のレビュー時間(回数)増加 個別最適化された計画ごとのチェックを中堅以上の教員が担う可能性があり現状よりレビューする時間と回数が増加する 生成 AI を活用したソリューションアプローチ (TP2) TP2 は特別支援学校向けソリューションで生徒に応じたカスタマイズ可能な UI/UX に加えて、上記の指導計画に関する課題解決のため以下のソリューションアプローチをとっています。 学習指導要領の RAG 検索により一定水準の品質を保った計画作成を支援 学習指導要領を RAG のデータソースとして利用する事で一定水準の計画内容を担保。また、学年と科目ごとのメタデータフィルタリングを利用することで関連性の高いドキュメントを検索。 Excel 及び校務データの生徒情報と RAG 検索結果を元に個別最適化された計画を生成 指導要領の内容に加えて生徒ごとの習熟度や家庭環境などの情報を追加することで個別最適化された計画を生成 AI が作成。また、計画作成だけでなく手立ての評価(確認)ポイントも提示。 一定水準の品質を保った計画生成により中堅以上の教員の負担軽減 生成 AI を活用して計画の品質を向上することで中堅教員のレビュー時間と回数を軽減。 TP2 がもたらす価値 上記のソリューションアプローチにより個別最適化された指導計画作成の効率化に加えて、計画作成にあたり根拠となった指導要領の内容も UI 上に表示されるため、指導要領の検索時間も短縮可能です。また、現場では計画の紙ベースの保管も加味しExcel ファイルのデータ表示と編集をUI実装しており、TP2 で生成された計画内容だけでなく元の内容も加筆修正可能です。 TP2 を利用する中で計画のフォーマットや記載すべきポイントなど教員ごとに生成 AI へ指示する Prompt をカスタマイズしたいニーズも視野に入れ、Prompt の内容の表示と編集可能なUI実装となっています。 アーキテクチャ・技術的詳細など 図 8 : TP2 のアーキテクチャ図。 Amazon Bedrock ナレッジベース、&nbsp; Amazon Aurora Serverless と Amazon S3 で RAG を構成しています。今回のブースデモではデータ量とコスト観点でベクトルデータベースとして Amazon Aurora Serverless を利用しましたが、TP2 は AWS Cloud Development Kit (AWS CDK) で IaC 化されておりユースケースに応じて Amazon OpenSearch Serverless をデプロイ時に選択することも可能です。 指導計画と評価の生成は Amazon Bedrock と Amazon Nova を利用しています。AWS と校務システムが連携できた場合を想定して擬似校務データベースとして Amazon DynamoDB に生徒情報を格納し、Excel 記載の学生の氏名から家庭環境などの情報を取得しています(学籍番号など一意になる情報推奨)。 フロントエンドは React を利用して、 Amazon CloudFront と Amazon S3 でシングルページアプリケーション (SPA) をデプロイしています。 発展/展望 個別最適化された計画生成の精度向上の観点では、卒業生などの蓄積された指導計画のデータソースを活用することで精度向上が期待できます。例えば、同傾向の卒業生のデータをもとに効果が高い計画を生成できる可能性があると考えます。 TP2 は個別最適化された指導計画生成に焦点を置いていますが、評価の高かった過去の計画をもとに生成 AI で作成した計画のレビューを追加実装することで中堅以上の教員の負荷軽減も可能だと考えています。 まとめ 本ブログでは AWS Summit Japan 2025 にて教育業界向けブースで展示をした 2 種類のデモについてご紹介しました。 今回ご紹介したデモが、教育業界の課題解決に役立てられれば幸いです。 最後に、本ブログでご紹介したデモに関して、ご興味・ご質問をお持ちのお客様は お問い合わせフォーム もしくは担当営業までご連絡ください。また会場で投影しておりました資料を こちら からダウンロードいただけます。 本ブログは、 アマゾン ウェブサービス ジャパン合同会社 パブリックセクター のソリューションアーキテクト、田村健祐、小泉秀徳が執筆しました。

あらゆる業界の役員会議室で、経営幹部は重要な疑問に直面しています。 ――AI をどのように活用すれば、コスト削減とビジネスの成長を同時に実現できるのか ? AI は、すべての顧客接点を成長のきっかけに変える、変革の機会を顧客体験の責任者に提供します。AI は、まず効果的なセルフサービスを可能にし、続いて人間の介入が必要な場合にもパーソナライズされた応答とアクション推奨でエージェントをサポートすることで、カスタマージャーニーを強化します。継続的にインタラクションを分析することで、AI は一般的な問題と成功した解決策の両方のパターンを特定し、自動化システムとエージェントガイダンスを自動的に改善します。この接続されたインテリジェンスは運用計画にまで拡張され、スタッフィングとトレーニングを最適化して、すべてのチャネルでのインタラクションごとにより賢くなる統合学習システムを構築します。重要なことに、AI は複数のインタラクション間でコンテキストを維持し、切り離された接触を継続的な会話に変換して、より深い顧客関係を構築します。このように、継続的に改善されるエクスペリエンスを通じて売上を向上させ、顧客を喜ばせることができます。 しかし、顧客体験全体にわたって AI の潜在能力を最大限に実現するためには、重要な統合の課題が立ちはだかります。多くの組織では断片的なアプローチを採用し、コンタクトセンター内でケースバイケースで AI ソリューションを実装しています。この手法は的を絞った改善をもたらしますが、互いに効果的に連携しない、切り離されたツールの寄せ集めを作り出し、統合、保守、管理のコストを増加させます。あるいは、一部の企業では AI の実装をエージェント支援などの単一領域に制限し、より広範な顧客体験を向上させる機会を逃しています。これらの断片化された戦略は、しばしば導入への不安や限定的な採用につながり、組織は予測不可能なコスト、実装の複雑さ、不確実な投資収益率への懸念により、AI に完全にコミットすることをためらいます。この慎重さは、組織がインタラクションから継続的に学習する真にインテリジェントで応答性の高いシステムを構築することを妨げています。つまり、統合の複雑さ、データサイロ、予測不可能なコストによって阻まれているといえます。 そのため、これらの課題に直接対処する次世代の Amazon Connect (Amazon Connect と無制限の AI) を私たちは発表しました。 次世代の Amazon Connect Amazon Connect は、すべてのチャネルにわたり、ファーストパーティ AI を提供し、AI の使用量ではなく基本的なチャネル使用量にのみ基づいて、将来の AI 機能が継続的に利用できるバンドル型の AI 価格設定を提供します。Amazon Connect の次世代版により、あらゆる規模の組織が、すべてのタッチポイントで AI を活用しやすくなり、コストが原因の妥協をすることなく、顧客体験の改善に集中できるようになります。Amazon Connect を選択することで、AI ジャーニーが本格的に始まり、都度、追加の意思決定、実装作業、コストを必要とせずに、AI モデル、トレーニング手法、新しいエージェント機能の継続的な改善から自動的に恩恵を受けられます。このアプローチにより、AI 導入における財務的な障壁を排除しながら、テクノロジーの進化に伴い、顧客体験を最先端に保つことができます。 Amazon Connect は AWS 上に構築されており、複数のサードパーティソリューションを必要とすることなく、お客様の環境内で AI サービスをネイティブに活用できます。Amazon Bedrock の最先端モデルを活用、コンタクトセンター全体のエクスペリエンスにシームレスに統合されます。コンタクトセンターのリーダーは、初期のセルフサービスでのやり取りからエージェントサポート、顧客の感情やトレンドを明らかにする会話分析まで、カスタマージャーニー全体を通じてこれらのネイティブ AI 機能を簡単に有効化、最適化、管理できます。この統合された製品は、セルフサービス、エージェント支援、分析などの異なる機能に対するシステムの分断という一般的な問題を解消し、すべての顧客接点を、売上向上と継続的な学習による顧客満足度向上の機会に変えます。 チャネルベースの料金体系による、カスタマーエクスペリエンス全体にわたる包括的な AI 機能 次世代の Amazon Connect は、シンプルで予測可能な料金体系を通じて AI ネイティブ機能をあらゆる規模の組織が誰でもアクセスできる環境を提供しています。組織はもはや、どのインタラクションが AI 活用に値するかについて、コストと複雑さを潜在的な利益と比較検討して困難な決定を下す必要がありません。新しいバンドル料金は AI の使用量ではなく、基盤となるチャネル使用量（音声通話時間やチャットセッションの使用量など）に直接結び付けられており、以下の機能の無制限利用が含まれているため、組織はコスト主導のトレードオフなしに、すべてのタッチポイントで AI 拡張されたカスタマーエクスペリエンスを自信を持って提供できます。 顧客によるセルフサービス : 25 以上の言語で、顧客のニーズに適応し待機時間を短縮する AI を活用したセルフサービス体験を、音声およびデジタルチャネル全体で大規模に提供します。 エージェント支援 : Amazon Q in Connect は顧客の問題を検出し、顧客情報、ナレッジリポジトリ、および Web コンテンツに基づいてパーソナライズされた応答と推奨アクションを提供します 会話分析 : 機械学習を活用した会話分析と品質管理機能により、通話とチャットのトランスクリプトを検索し、感情を分析し、問題を特定し、エージェントのパフォーマンスを監視します。SMS と電子メールについては近日公開予定です 画面記録 : 会話分析とパフォーマンス評価と組み合わせることで、スーパーバイザーは問い合わせの品質とエージェントのパフォーマンスを監視、評価、改善できます コンタクト後の要約 : AI を活用した顧客とのやり取りの要約により、エージェントのアフターコールワークを短縮します。これらの要約は通話が転送される際にコンテキストを保持し、顧客が再度電話をかけてきた際に即座に背景情報を提供し、繰り返しの質問を排除します パフォーマンス評価 : すべての顧客とのやり取りをレビューして学習し、コーチングの機会を特定し、ベストプラクティスを発見し、コンプライアンスリスクを軽減し、評価をより効率的に完了します 予測、キャパシティプランニング、スケジューリング : AI を活用した人員管理により、スプレッドシートと推測作業を排除し、リアルタイムで変化するパターンに調整しながら、スーパーバイザーの介入なしにエージェントのリクエストを自動的に処理します Amazon Connect のお客様の声 次世代の Amazon Connect に対し、業界を問わず組織からポジティブな反応をいただいています。 Amazon Connect で、6 つの地域にまたがる VMO2 のコンタクトセンターを変革し、10,000 人以上のエージェントをサポートしています。Amazon Connect の機能を使用することで、顧客のやり取りパターンを特定し、初回コンタクトでの解決率を向上させ、セルフサービスを好む顧客のデジタルのチャネルへの適合を増加させることができました。さらに、生成 AI を活用したコンタクト後の要約を実装して手作業を削減し、一貫した自動化されたプロセスを通じてコンプライアンスと品質管理を強化しています。苦情解決の迅速化、NPS スコアの向上、処理時間の短縮といった結果を達成し、同時にエージェントの効果性を向上させています。私たちのエージェントも、より力を与えられ、より効果的だと感じています。業界をリードする顧客体験を提供し、カスタマーサービスのさらなる卓越性を達成するために、Amazon Connect でさらに多くの AI 活用による可能性が広がることを楽しみにしています。 – Alan Stott 氏、Virgin Media O2 カスタマーコンタクト部門ディレクター Genpact はこの Amazon Connect のローンチと、大規模な顧客体験を革新するその能力を称賛します。AWS Premier ティアパートナーとして、私たちの戦略的コラボレーションは継続的に深まっており、Amazon Connect を活用してクライアントをエージェント AI の未来に向けて加速させることにわくわくしています。Amazon Connect 上に構築された Genpact のソリューションは、10,000 人以上のカスタマーサービスエージェントを抱える 150 社以上において、平均処理時間を最大 35% 削減し、顧客満足度スコアと初回コール解決率を向上させることが実証されています。Amazon Connect と Genpact の深い業界専門知識を組み合わせることで、私たちは共に企業により大きな価値を提供し、顧客体験を改善し、リスクを軽減することができます。 – Sameer Dewan 氏、Genpact 金融サービス担当グローバルビジネスリーダー グローバルなデジタル変革企業として、富士通は包括的な技術製品、ソリューション、サービスを提供しています。富士通の 8 つのグローバルデリバリーセンターの 1 つである富士通コスタリカでは、当社のコンタクトセンターは 5 年間、完全に Amazon Connect で運用されており、450 社以上の企業の顧客にサービスを提供する 5,000 人以上のエージェントを管理しています。私たちは、ライブエージェント支援による顧客インタラクションとセルフサービス機能、 Amazon Connect のオムニチャネルコミュニケーション、Connect の会話分析、自動評価、キャパシティプランニング、エージェントスケジューリングにより運用を大幅に改善しました。例えば、イントラデイ予測で 96% 以上の精度を実現し、パイロットプログラムでは各国固有の労働法への準拠を改善しました。また、自動化されたパフォーマンス評価により品質保証において 15% の効率向上を実現し、インタラクション中のリアルタイムな顧客感情に基づいてエージェントが行動を取れるようにすることで顧客満足度を 10% 向上させています。次世代の Amazon Connect だけが提供する機能は、AI を活用した顧客体験をグローバルに標準化し継続的に最適化するのに役立ち、 すべてのコミュニケーションチャネルにわたる、あらゆるインタラクションでの強力な機能を提供してくれることを嬉しく思います。 – Alex Sanchez 氏、富士通 グローバルオファリングテクノロジー・GDC ネットワーク責任者 DXC では、テクノロジーをシームレスに機能させ、組織が最大限の可能性を実現できるよう支援しています。Amazon Connect を活用した DXC Customer Experience は、効率性の創出、運用の最適化、顧客体験の向上により、コンタクトセンター分野に革命をもたらします。この変革により、クライアントが最も得意とすることに集中する時間が生まれ、大幅なコスト削減と高いチーム満足度につながります。次世代の Amazon Connect により AI 強化エージェント機能を拡張し、クライアントがさらに優れた成果を上げられるよう支援できることを嬉しく思います。 – Chris Drumgoole 氏、DXC Technology グローバルインフラストラクチャサービス部門プレジデント AI を活用したカスタマーエクスペリエンスのビジョン実現に向けて この次世代の Amazon Connect は、組織が AI の潜在能力を最大限に活用することを妨げてきた統合の課題と断片的なアプローチに直接対処します。AI の使用量ではなく、基盤となるチャネル使用量のみに価格を連動させ、無制限の使用と包括的な AI 機能を統合して提供することにより、Amazon Connect は、AI の採用を制限してきた散在するツールの統合、予測不可能なコスト、実装の複雑さを排除します。あらゆる規模の組織が、これまで障壁となっていた財政的制約や技術的制限なしに、カスタマーエクスペリエンス全体で AI を活用しながら、コストを削減し、自信を持ってビジネスを成長させることができるようになりました。 Amazon Connect 内で直接提供される自動更新や新機能により、お客様のコンタクトセンターは追加の実装作業を必要とすることなく、カスタマーサービステクノロジーの最先端を維持します。組織はコーディングを必要とせずに高度な AI 機能を実装でき、技術的な障壁なしに戦略的な改善を行うことができます。これにより、顧客の期待と AI テクノロジーが進化する中でも、お客様の顧客体験は継続的に改善され、将来にわたって運用を維持できます。また、技術的な統合ではなくビジネス成果に集中することができます。 AWS アカウントを登録あるいはコンソールにアクセス して、ワンクリックで次世代の Amazon Connect を開始しましょう。Amazon Connect のコア機能を引き続き使用したい組織は、そのまま使用を続けることができます。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

こんにちは！AWS ISV/SaaS ソリューションアーキテクトをしているさばみそです。 2025 年 7 月 17 日に「SaaS ビジネス成功の鍵 – メトリクス設計からつなげるデータドリブンな SaaS 組織への転換」と題したイベントを AWS Startup Loft Tokyo で開催いたしました。 Software as a Service (SaaS) モデルでのビジネスが従来のパッケージ販売のモデルと比べて大きく異なる点は、ストック型で売上が積み上がり続けるという点です。この特性から、契約を獲得してからできるだけ長く使ってもらえるか、つまり LTV（Life Time Value、顧客生涯価値）をできるだけ高めることが重要です。「売ってからが始まり」であり、利用者がプロダクトから得られる価値を継続して提供する必要があります。 では、「利用者がプロダクトから得られる価値」を利用者が正しく得られているかを、どの様に判別/計測すれば良いでしょうか？ その際に必要となってくるのが、プロダクトにおけるメトリクス設計です。 本イベントでは、パッケージビジネスから SaaS ビジネスへの移行が加速する中、多くの企業が直面している SaaS プロダクトにおけるメトリクス設計と活用の課題に焦点を当て、実践的な知見を共有させていただきました。 イベント概要 近年、多くの企業様がパッケージビジネスからSaaSビジネスへと移行する中で、適切なメトリクス設計の重要性が増しています。本セミナーでは、以下のような課題に対する解決策を、実践的な内容とともにご紹介させていただきました。 SaaS ビジネス特有のメトリクスの理解 リカーリングビジネスの健全性測定 データを活用したプロダクト戦略の立案 チーム間でのKPI認識の統一 セッション紹介 ゲストセッション 小城 久美子 様：プロダクト戦略の成果を測る NSM とは？ その必要性と策定方法 [資料] 「プロダクトマネジメントのすべて」の共著者である小城久美子様より、プロダクト戦略の成果を効果的に測定する NSM（North Star Metric）について具体的な策定方法と重要なポイントが紹介されました。NSM の選定には、ビジョンや顧客価値、事業収益との連動性、AARRR（Pirate Metrics）との整合性、測定可能性など、5つの重要な基準があることを解説いただきました。特に注目すべきは、NSM の作成ステップが「価値の言語化」「価値提案の道筋整理」「NSM の選定」という 3 つの明確なフローで示されており、実践的なアプローチを学ぶことができる点です。プロダクトマネージャーやビジネス戦略担当者にとって、成果指標の設定に悩む課題を解決するヒントが詰まった、実務で即活用できる内容となっています。 お客様事例 株式会社ExaMD 牛越 洵也 様 : メトリクスで価値を可視化する データ駆動プロダクト開発の実践 [資料] 株式会社ExaMD 牛越様より、株式会社ExaMD が取り組む、データ駆動型のプロダクト開発アプローチについて、具体的な事例とともに紹介いただきました。医療分野における多彩なプロダクト展開を基に、データ分析基盤の構築からメトリクス設計、そして実際に得られた成果まで、体系的に解説されています。特に、医療という専門性の高い領域でいかにデータを活用し、プロダクトの価値を可視化していくのか、その実践的なノウハウが詰まっています。医療×テクノロジーの最前線で、データドリブンな意思決定がどのように行われ、どのような成果を生み出しているのか、プロダクト開発に携わる方必見の内容となっています。 NSM – KPI ツリー作成ワークショップ体験版 AWS 福本より、SaaS ビジネスの成功に不可欠なメトリクス設計を 1.5 時間で実践的に学べるワークショップを実施しました。エレベータピッチの作成から始まり、インプットメトリクスの洗い出し、因果関係の発見と NSM（North Star Metric）の探索、そして KPI ツリーの作成まで、段階的に理解を深められる構成となっています。特に、ユーザー価値を起点としたメトリクス設計のアプローチをとることによって、利用者がプロダクトから得られる価値と向き合うことができます。 パートナーセッション 株式会社アンチパターン ⽮ヶ崎 哲宏 様：SaaS メトリクスの取得と分析⼿法 [資料] 株式会社アンチパターン 矢ヶ崎様より、SaaS ビジネスにおける効果的なメトリクス収集と分析手法を包括的に解説をしていただきました。特に SaaS アプリケーションプレーンとコントロールプレーンにおける多様なデータポイント（行動履歴、API ログ、アクティビティログなど）の活用方法について具体的にお話しいただきました。顧客の利用状況を「幅（Breadth）」「深さ（Depth）」「頻度（Frequency）」「効率（Efficiency）」という複数の観点から分析し、データレイクから BI ツールまでの一貫した分析基盤の構築方法も紹介されています。さらに、生成 AI と MCP サーバーを組み合わせた最新の分析手法まで網羅されており、SaaS ビジネスの成長に不可欠なデータ活用の取り組みについても学んでいただける内容となっております パートナーセッション 株式会社primeNumber 坂本 竜輝 様：データカンパニーが実践する SaaS ビジネスを加速させるデータ分析 [資料] 株式会社primeNumber 坂本様より、「あらゆるデータをビジネスの力に変える」をミッションとする primeNumber が実践する、最新のデータ分析アプローチを紹介いただきました。従来の課題であったデータ出力の遅延や探索的分析の困難さを解消し、データエンジニアからビジネスリーダーまで、多様なユーザーが効果的にデータを活用できる次世代の分析基盤について解説いただいております。特に、自動スケーリングが可能でセルフサービス型の分析環境の構築方法や、運用効率の向上からイノベーション加速まで、実践的なユースケースを交えた内容となっています。 AWS で実現するデータドリブン型組織 [資料] 最後に、AWS 安達より、AWS サービスを活用した SaaS メトリクスの収集・分析基盤の構築方法と、データドリブン型組織への転換に向けたベストプラクティスを紹介させていただきました。セッションの中では、従来の手作業による CSV 分析からクラウド BI を活用した自動化された最新のデータ分析基盤への進化についても解説しました。また、AWS を活用したモダンデータアーキテクチャの実現方法や、データ推進チームの発足、チャンピオン制度の導入など、組織文化の転換に向けた具体的なステップについても紹介しました。 まとめ 本セミナーでは、SaaS ビジネスにおけるメトリクス設計の重要性から具体的な実装方法まで、包括的な内容をお届けしました。また、AWS では本イベントのような支援だけでなく、 AWS SaaS 支援プログラム を通じて、日本の SaaS ビジネスのさらなる成長のための様々な支援も行っており、 こちら からご応募いただけます。 皆様の SaaS ビジネスの成功に向けて、本セミナーの内容が少しでもお役に立てば幸いです。 このブログの著者 安達 翔平 (さばみそ) アマゾン ウェブ サービス ジャパン合同会社 ISV/SaaS ソリューションアーキテクト Web 系の自社サービス、請負開発を経験後、ISV/SaaS 領域のお客様をメインにアーキテクトしてます。 趣味は、サウナ、ロックフェス、スノーボードです。ホームサウナは、ニューウィング錦糸町です。