米国ラスベガスで2025年12月1日-5日に開催された AWS re:Invent 2025 では、デジタル庁様がユーザー事例ブレイクアウトセッションに登壇されました。 デジタル庁様の大規模かつ効率的な統制のあり方を説明したこのセッションの内容は日本の一般企業のガバナンスにも参考になるものと思います。 このブログでは日本のお客様向けに日本語でセッションの内容をご紹介します。英語ではありますが YouTubeに上がっているセッション動画 もぜひご覧ください。 セッション概要 タイトル： [COP349] Balancing Agility & Compliance feat. The Digital Agency of Japan（俊敏性とコンプライアンスのバランス – 日本のデジタル庁を迎えて） セッション概要： 規制業界は、クラウドにおける厳格なセキュリティとコンプライアンス要件に対応しながら、俊敏性を持ってイノベーションを推進するという課題に直面しています。このセッションでは、日本政府が各省庁と1,700以上の地方公共団体にわたってクラウド導入のための集約型ガバナンスモデルを成功裏に実装し、5,000以上のアカウントをシームレスに管理できるようにした事例を学びます。AWS Control Tower、AWS Config、AWS Security Hubなどの AWS クラウドガバナンスサービスにより、規制業界や公共部門は運用を合理化し、ガバナンスを強化し、進化するコンプライアンス要件を満たして、中央制御と地方の自律性のバランスを取ることができます。 登壇者： デジタル庁, Chief Cloud Officer 山本 教仁 様 AWS, World Wide Cloud Governance Principal Specialist Nivas Durairaj AWS Japan, Manager, Specialist Solutions Architect 大村 幸敬 AWSガバナンスのベストプラクティス 最初に AWS Cloud Governance Specialistの Nivas よりAWSにおけるガバナンスのベストプラクティスについて解説しました。 公共部門、ヘルスケア、金融業界といった機微な情報を扱う規制業種では、俊敏性とコンプライアンスという大きく２つのニーズがあります。俊敏性では、生成AIのようなイノベーションの活用、そして変化に追従して迅速に成果を出すことが求められます。コンプライアンスでは、セキュリティルールへの適合、および中央の管理者が統制しつつも多数の利用者（開発者）がスケーラブルに利用できることが求められます。 これを開発者と中央の管理者という観点で言い換えてみます。開発者は技術的な意思決定を自由に行って実験を繰り返せる環境を使って、イノベーションと迅速なリリースを実現したいと思っています。一方で中央管理者は運用効率化のために環境の標準化を求め、組織全体にわたってセキュリティとコンプライアンス統制の可視化を実現したいと思っています。 ここに、俊敏性とコンプライアンスという反対方向に働く緊張が発生することになります。この２つをAWS上ではどのようなバランスで実現するのか、というのがこのセッションのキーポイントです。 AWSではクラウドガバナンスを「組織がベストプラクティスに準拠するよう導く、ルール、プロセス、およびレポートの集合」と定義しています。 詳細はQRコードに示した、 AWSのウェブサイトをご覧ください 。 ベストプラクティスとしては、環境に関するベストプラクティス、コントロール（統制）に関するベストプラクティスの２つがあります。 環境のベストプラクティスはこの４つです。（詳細はセッション資料を参照してください） システムごとにアカウントを使用する（マルチアカウント管理を行う） アカウントの作成とカスタマイズを自動化する すべてのアカウントの活動を記録する 強力なID管理基盤を実装する コントロール（統制）のベストプラクティスは次の3つです。（詳細はセッション資料を参照してください） コントロール（統制）の目的をセキュリティフレームワークに適合させる 予防的統制の前に発見的統制を適用する コントロールを継続的に監視しテストする これらはベストプラクティスではありますが、規制業種の実際のシステムに適用することを考えた場合、多くの実装上の課題に直面することになります。ガバナンスの観点では、法律への適合方法、巨大な組織でもスケールする実装。俊敏性の観点では、アカウント作成とカスタマイズを誰が行うのか、利用者の認証方法、セキュアな基本設定を広く組織全体に展開する方法などです。 これらを実現した事例として、日本のデジタル庁によるガバメントクラウドを紹介します。 デジタル庁ガバメントクラウドの取り組み ここから、デジタル庁 CCO 山本様に、ガバメントクラウドでの取り組みを紹介していただきました。 まずは、こちらのデジタル庁様の紹介動画をご覧ください。 日本のデジタル庁は2021年に発足。コロナ禍の最中でした。コロナ禍ではワクチン接種の記録やワクチンの所在を短期間で確認することは当初困難でした。政府と社会のこういった課題をデジタルの力で解決することを目的としてデジタル庁が設立されました。以後４年間にわたってマイナンバーカードなどの施策を実現しています。ガバメントクラウドはこれらの施策の基盤となるものです。 ガバメントクラウドでは中央省庁だけでなく、地方公共団体や準公共領域の団体のシステムも稼働しており、急速に利用が増えています。2025年9月の時点で6,085アカウントが稼働しており、2025年は1ヶ月平均で370アカウントが増えています。 こういった急速なアカウント増加に対応するため、アカウントの追加や利用者のID追加作業の自動化は必須です。自動化以前では利用者の追加にかかるリードタイムは５営業日でしたが、現在は翌日までの追加が可能になっています。また利用者を１名追加することにかかるデジタル庁管理者の作業は30分から1時間であり、１ヶ月あたり370アカウントの追加であれば259時間を要する計算でした。しかし自動化によってこの作業量は現在ゼロを実現しています。 ガバナンス実現の文脈で、ガバメントクラウドがプラットフォームとして重要視すべき要素は3つあります。一つはもちろんガバナンスですが、日本の地方公共団体における固有の考慮として、地方の独立性（Local autonomy）があります。ガバナンスを実現するためには管理者であるデジタル庁が個々の環境を管理できたほうが効率的ですが、地方の独立性を重視する立場からは、デジタル庁が個々の環境を直接操作することはできません。さらに多数の自治体がガバメントクラウドを利用する場合でも、デジタル庁がそのボトルネックとなることなく俊敏性を提供するためには、スケーラビリティが必要となります。 この「ガバナンス」と「地方の独立性」そして「俊敏性とスケーラビリティ」の3つをバランスすることが、ガバメントクラウドにとって重要となります。 ガバメントクラウドの全体像がこちらです。ガバメントクラウドでは複数のクラウドサービスプロバイダー（CSP）を利用しており、利用者は個々のクラウド環境を直接利用することができます。提供するクラウド環境を払い出す機能や監査ログの記録やダッシュボードといった管理機能はユーザのクラウド環境の外側にあって、クラウド環境利用を阻害しないような構成となっています。これによって利用者はCSPが持つテクノロジをそのまま利用できるようにしています。このアーキテクチャは俊敏性とスケーラビリティを実現することに役立っています。 ガバナンスの実現にあたっては、法制面と技術面の両方から対応しています。法制面では日本法の下での日本政府と CSP との直接契約、データが日本に所在すること、そしてこれが適切に運営されていることを監査と ISMAP 認定で確認しています。技術面では利用者登録時にマイナンバーカードによる認証を行った上で、利用時は MFA で認証します。データは FIPS 140 認定の HSM （ハードウェアセキュリティモジュール）に格納された暗号キーで暗号化することができ、正しく認証したユーザのみが利用可能で、デジタル庁の管理者やCSPも含め外部からアクセスした場合でも読み取ることはできません。このようにして強固なガバナンスを実現していますが、同時に利用者の作成作業などは完全に自動化されており、俊敏性とスケーラビリティの両方を実現しています。 先に示したデータのガバナンスによって地方の環境の独立性も実現されることになります。すなわちデジタル庁の管理者であっても個々の自治体が持つAWSアカウントのデータにアクセスことはできません。さらに個々のアカウントに対してデジタル庁管理者が直接操作を行うことはなく、アカウントの作成や設定は全て自動化されています。またこの操作も毎年の監査を受けています。 アジリティとスケーラビリティ実現はここまでも述べてきましたが、さらに実際の環境における情報をガバメントクラウドとして管理しつつ、全てを自動化するための仕組みを導入しています。これは後ほど技術詳細と共に再度ご説明します。 ガバメントクラウドではマルチクラウド戦略をとっていますが、これは次の３つの戦略に基づいています。（詳細はセッション動画をご覧ください） 1つのシステムは1つの CSP で動作させる（複数のCSPを跨がない） 複数のクラウドを統合的に管理するシステムは使用しない データとプログラムの移行可能性を考慮する（ポータビリティの高いコンテナを採用するなど） 山本さんから最後にガバメントクラウドにおける AI の活用について説明がありました。日本は AI を活用し、ガバメント AI を準備するというポリシーを掲げています。デジタル庁の AI クラウド環境はその基礎となる予定とのことです。 デジタル庁でのベストプラクティス実現方法 最後のパートでは、ガバメントクラウドの実装をサポートした、AWS Japan のソリューションアーキテクト マネージャー 大村から技術的な実装の詳細について解説しました。冒頭 Nivas が提示したベストプラクティスからガバメントクラウド実装のキーとなった４つを取り上げました。 １つ目に取り上げるベストプラクティスは「コントロール（統制）の目的をセキュリティフレームワークに適合させる」です。 デジタル庁ではプリンシプル・ベース・アプローチ（原則主義アプローチ）により、法律から規制、そしてガイドラインへと抽象度の高い要求を徐々に具体化しています。これらのガイドラインをNIST CSFやNIST SP800-53といったフレームワークやコントロールカタログを参照して具体的な管理策にマッピングすることで、実装に落とし込めるようにしています。 さらに、ガバメントクラウドでは、これらのコントロールを実現するにあたり「運用効率を損なうことなく、適切なセキュリティ対策を実現する」という目的を掲げています。そのため、予防的統制は最小限とし、主に発見的統制を使ったガバナンスを実装する方針としています。予防的統制の実装には AWS Organizations の Service Control Policy を使用して特定の操作そのものをできないようにしています。発見的統制の実装には AWS Security Hub CSPM を使用して、操作自体を制限するのではなく、設定内容に統制からの逸脱がある場合、迅速に検出できるようにしています。これは AWS Config が構成情報を記録していることで実現できています。Security Hub CSPM には CIS ベンチマークや、 AWS Foundational Security Best Practice といったスタンダードがすでに用意されており、これらは NIST SP800-53 等のフレームワークとマッピングされています。これによって発見的統制の実装が容易になっています。 ２つ目に取り上げるベストプラクティスは「強力な ID 管理基盤を実装する」です。 ガバメントクラウドでは数千もの利用者やアカウントを管理する必要があり、高いセキュリティを維持しつつスケーラブルに運用するためには、強力な認証基盤とその自動化が重要です。山本さんが紹介されたように、利用者登録の際の認証はマイナンバーカードで自動化しています。これにより当初手動で5日間かかっていたリードタイムを翌日（１日）へと劇的に短縮しました。さらに IAM Identity Center (IIC) では利用するゲストアカウントにアクセスするための権限を Permission Set で設定しますが、個々の利用者、アカウントごとにこれを作成すると設定の管理対象が膨大になり、サービスクォータ（上限）に抵触する可能性もあります。そこで、管理者と非管理者という２つの Permission Set だけを使うシンプルな実装を行っています。管理者権限は IAM ロールの作成が可能で（予防的統制により IAM ユーザの作成は禁止しています）、非管理者権限はロールの切り替えのみが可能である、という仕組みです。これにより利用者が個々のアカウントで必要なロールを作りつつも、IIC の Permission Set 数が爆発的に増えることのない仕組みを実現しています。 ３つ目に取り上げるベストプラクティスは「アカウントの作成とカスタマイズを自動化する」です。 まず初回のみのアカウント設定について説明します。 利用者がAWSアカウントを作成したい場合は GCAS (Government Cloud Assistant Service) というデジタル庁が開発したポータルからリクエストします。アカウント作成自体は AWS Control Tower が行い、アカウントの並列作成をサービス上限以下にコントロールするための Amazon SQS 、そして初期設定手続きを定義する AWS Lambda 関数を、AWS Step Functions ワークフローで繋ぐ形で実現しています。Control Tower には Account Factory Customization という AWS Cloud Formation を使ったアカウント初期設定の仕組みがあります。Cloud Formationのような Infrastructure as Code は「あるべき状態（設定）」を定義するのに適しています。しかしガバメントクラウドで行う初期設定作業には、エンタープライズサポートへの登録などAPIしか利用できない操作も多く、そのような「手続き」を定義するには Lambda 関数の方が適しています。さらに、アカウント作成では自治体名や支払い用メールアドレスといった、AWS の設定とは関係のない実世界の情報も管理する必要があります。これらは GCAS 上のデータベースに登録し、ここでも手動での管理を排除しています。このようにアカウント作成時の初回設定を完全に自動化しています。 利用者のアカウントにはセキュリティの基本設定である「セキュアベースライン」を展開します。これは展開後も継続してメンテナンスする必要があるため「あるべき状態」を定義する Infrastructure as Code が適しています。ガバメントクラウドでは CDK を使用してセキュアベースラインを定義しています。このデプロイは、AWS Service Catalog を使った「Pull（引っ張る）スタイル」でおこないます。これはデプロイ対象であるセキュアベースラインをデジタル庁管理者が Service Catalog の Product として作成し、デプロイは地方公共団体の管理者が自ら（引っ張ってきて）行うやり方です。Pullスタイルの対義語は「Push（押す）スタイル」ですが、これは Cloud Formation StackSet のような、中央の管理者が全ての環境にデプロイするやり方を指します。ガバメントクラウドで Pull スタイルを採用した理由は、一つは管理の独立性の考えに基づき、デジタル庁管理者が地方公共団体などのアカウントにアクセスしないようにする必要があったことです。もうひとつの理由は、Push スタイルの場合、セキュアベースラインをアップデートする際にデジタル庁管理者が地方公共団体管理者と実施タイミングや設定内容を調整する必要があり、デジタル庁管理者の運用がスケールしないためです。Pull スタイルであることで、デジタル庁管理者は Service Catalog の Product を更新するだけでよく、地方公共団体管理者は自らの都合のよいタイミングで、自らの環境の状態を理解した上で、更新を実施することができます。これもまたスケーラブルなセキュアベースライン実現のために必要な仕組みです。 最後に取り上げるベストプラクティスは「コントロールを継続的に監視しテストする」です。 ガバメントクラウドでは、地方公共団体のアカウントで発生したセキュリティイベントは直接地方公共団体の管理者へ通知され、管理者が自ら修正する責務があります。これはセキュアベースラインに設定された Amazon EventBridge と AWS Chatbot によって実現しています。これもデジタル庁管理者を介することなく対応する仕組みによって、管理の独立性とスケーラビリティを実現しています。一方でデジタル庁管理者は多数のアカウント全体の統制について、その統制の状況を把握する必要があります。これは AWS Security Hub CSPM のレポートによって実現しており、少数の、特に注意が必要なセキュリティイベントについては、デジタル庁管理者が定期的にチェックを行い、必要に応じて改善提案を行っています。このようにして、多数のアカウントを対象にしていてもセキュリティイベントが適切に対応される仕組みを実現しています。 まとめ このセッションでは、日本の中央省庁や地方公共団体という現実の世界のシステムを管理する上で、ガバメントクラウドがガバナンスと俊敏性を両立させるためにどのように考え、実装しているのかを紹介しました。また、それがAWSのベストプラクティスにも適合していることをご紹介しました。 会場には日本の方も多くご参加いただき、登壇後に質疑応答もいただきました。ご来場いただきありがとうございました！ 著者：大村幸敬 (AWS Japan, Manager, Solutions Architect)

本記事は 2025 年 12 月 16 日 に公開された「 Unlocking video understanding with TwelveLabs Marengo on Amazon Bedrock 」を翻訳したものです。 メディア・エンターテインメント、広告、教育、企業研修などのコンテンツは、視覚、音声、動きの要素を組み合わせてストーリーを伝え、情報を届けます。個々の単語に明確な意味があるテキストと比べて、はるかに複雑です。このため、動画コンテンツを理解する必要がある AI システムには独自の課題が生じます。動画コンテンツは多次元的であり、視覚要素 (シーン、オブジェクト、アクション)、時間的ダイナミクス (動き、トランジション)、音声コンポーネント (会話、音楽、効果音)、テキストオーバーレイ (字幕、キャプション) を組み合わせています。この複雑さは、組織が動画アーカイブを検索したり、特定のシーンを見つけたり、コンテンツを自動的に分類したり、効果的な意思決定のためにメディア資産からインサイトを抽出したりする際に、大きなビジネス上の課題を生み出します。 このモデルは、異なるコンテンツモダリティに対して個別の埋め込みを作成するマルチベクトルアーキテクチャでこの問題に対処します。すべての情報を 1 つのベクトルに圧縮するのではなく、モデルは特化した表現を生成します。このアプローチにより、動画データの豊かで多面的な性質が保持され、視覚、時間、音声の各次元にわたってより正確な分析が可能になります。 Amazon Bedrock は、同期推論によるリアルタイムのテキストおよび画像処理で TwelveLabs Marengo Embed 3.0 モデルをサポートするように機能を拡張しました。この統合により、企業は自然言語クエリを使用したより高速な動画検索機能を実装できるようになり、高度な画像類似性マッチングによるインタラクティブな製品発見もサポートします。 この記事では、 Amazon Bedrock で利用可能な TwelveLabs Marengo 埋め込みモデルが、マルチモーダル AI を通じて動画理解をどのように強化するかを紹介します。Marengo モデルからの埋め込みと、ベクトルデータベースとしての Amazon OpenSearch Serverless を使用して、動画のセマンティック検索および分析ソリューションを構築します。これにより、単純なメタデータマッチングを超えたセマンティック検索機能でインテリジェントなコンテンツ発見を実現します。 動画埋め込みの理解 埋め込みは、高次元空間でデータの意味的な意味を捉える密なベクトル表現です。これは、機械が理解し比較できる方法でコンテンツの本質をエンコードする数値的な指紋と考えることができます。テキストの場合、埋め込みは「king」と「queen」が関連する概念であること、または「Paris」と「France」に地理的な関係があることを捉えることができます。画像の場合、埋め込みは見た目が異なっていても、 ゴールデンレトリバー と ラブラドール がどちらも犬であることを理解できます。以下のヒートマップは、「two people having a conversation」、「a man and a woman talking」、「cats and dogs are lovely animals」という文章フラグメント間の意味的類似度スコアを示しています。 動画埋め込みの課題 動画は本質的にマルチモーダルであるため、独自の課題があります: 視覚情報 : オブジェクト、シーン、人物、アクション、視覚的な美しさ 音声情報 : 音声、音楽、効果音、環境音 テキスト情報 : キャプション、画面上のテキスト、音声から書き起こされたテキスト 従来の単一ベクトルアプローチでは、この豊富な情報をすべて 1 つの表現に圧縮するため、重要なニュアンスが失われることがよくあります。ここで TwelveLabs Marengo のアプローチがこの課題に効果的に対処する点でユニークです。 Twelvelabs Marengo: マルチモーダル埋め込みモデル Marengo 3.0 モデルは、動画コンテンツのさまざまな側面を捉える複数の特化したベクトルを生成します。典型的な映画やテレビ番組は、視覚要素と聴覚要素を組み合わせて統一されたストーリーテリング体験を作り出します。Marengo のマルチベクトルアーキテクチャは、この複雑な動画コンテンツを理解するために大きな利点を提供します。各ベクトルは特定のモダリティを捉え、多様なデータタイプを単一の表現に圧縮することによる情報損失を回避します。これにより、視覚のみ、音声のみ、または組み合わせたクエリなど、特定のコンテンツの側面をターゲットにした柔軟な検索が可能になります。特化したベクトルは、複雑なマルチモーダルシナリオで優れた精度を提供しながら、大規模なエンタープライズ動画データセットに対する効率的なスケーラビリティを維持します。 ソリューション概要: Marengo モデルの機能 以下のセクションでは、コードサンプルを通じて Marengo の埋め込み技術の威力を実演します。これらの例は、Marengo がさまざまなタイプのコンテンツをどのように処理し、優れた検索精度を提供するかを示しています。完全なコードサンプルは、この GitHub リポジトリ にあります。 前提条件 始める前に、以下を確認してください: 適切な権限を持つ AWS アカウント Amazon Bedrock へのアクセス OpenSearch Serverless コレクションとインデックスを作成するためのアクセス ベクトルデータベースと埋め込みに関する基本的な知識 サンプル動画 Netflix Open Content は、Creative Commons Attribution 4.0 International ライセンスの下で利用可能なオープンソースコンテンツです。Amazon Bedrock 上の TwelveLabs Marengo モデルのデモンストレーションには、 Meridian という動画を使用します。 動画埋め込みの作成 Amazon Bedrock は、Marengo 動画埋め込み生成に非同期 API を使用します。以下は、S3 バケットの場所から動画を取得する API を呼び出す例を示す Python コードスニペットです。サポートされている完全な機能については、 ドキュメント を参照してください。 bedrock_client = boto3.client("bedrock-runtime") model_id = 'us.twelvelabs.marengo-embed-3-0-v1:0' video_s3_uri = "<s3 bucket location for the video>" # Replace by your s3 URI aws_account_id = "<the AWS account owner for the bucket>" # Replace by bucket owner ID s3_bucket_name = "<s3 bucket name>" # Replace by output S3 bucket name s3_output_prefix = "<output prefix>" # Replace by output prefix response = bedrock_client.start_async_invoke( modelId=model_id, modelInput={ "inputType": "video", "video": { "mediaSource": { "s3Location": { "uri": video_s3_uri, "bucketOwner": aws_account_id } } } }, outputDataConfig={ "s3OutputDataConfig": { "s3Uri": f's3://{s3_bucket_name}/{s3_output_prefix}' } } ) 上記の例では、1 つの動画から 280 個の個別の埋め込みが生成されます。各セグメントに 1 つずつ生成され、正確な時間的検索と分析が可能になります。動画からのマルチベクトル出力の埋め込みタイプには、以下が含まれる可能性があります: [ {'embedding': [0.053192138671875,...], 'embeddingOption': "visual", 'embeddingScope' : "clip", "startSec" : 0.0, "endSec" : 4.3 }, {'embedding': [0.053192138645645,...], 'embeddingOption': "transcription", 'embeddingScope' : "clip", "startSec" : 3.9, "endSec" : 6.5 }, {'embedding': [0.3235554er443524,...], 'embeddingOption': "audio", 'embeddingScope' : "clip", "startSec" : 4.9, "endSec" : 7.5 } ] visual – 動画の視覚埋め込み transcription – 文字起こしされたテキストの埋め込み audio – 動画内の音声の埋め込み 音声または動画コンテンツを処理する際、埋め込み作成のために各クリップセグメントの長さを設定できます。デフォルトでは、動画クリップは自然なシーン変化 (ショット境界) で自動的に分割されます。音声クリップは、10 秒にできるだけ近い均等なセグメントに分割されます。例えば、50 秒の音声ファイルは 10 秒ずつの 5 セグメントになり、16 秒のファイルは 8 秒ずつの 2 セグメントになります。デフォルトでは、単一の Marengo 動画埋め込み API は visual-text、visual-image、audio 埋め込みを生成します。デフォルト設定を変更して、特定の埋め込みタイプのみを出力することもできます。Amazon Bedrock API で設定可能なオプションを使用して動画の埋め込みを生成するには、以下のコードスニペットを使用します: response = bedrock_client.start_async_invoke( modelId=model_id, modelInput={ "modelId": model_id, "modelInput": { "inputType": "video", "video": { "mediaSource": { "base64String": "base64-encoded string", // base64String OR s3Location, exactly one "s3Location": { "uri": "s3://amzn-s3-demo-bucket/video/clip.mp4", "bucketOwner": "123456789012" } }, "startSec": 0, "endSec": 6, "segmentation": { "method": "dynamic", // dynamic OR fixed, exactly one "dynamic": { "minDurationSec": 4 } "method": "fixed", "fixed": { "durationSec": 6 } }, "embeddingOption": [ "visual", "audio", "transcription" ], // optional, default=all "embeddingScope": [ "clip", "asset" ] // optional, one or both }, "inferenceId": "some inference id" } } ) ベクトルデータベース: Amazon OpenSearch Serverless この例では、Marengo モデルを介して指定された動画から生成されたテキスト、画像、音声、動画の埋め込みを保存するためのベクトルデータベースとして Amazon OpenSearch Serverless を使用します。ベクトルデータベースとして、OpenSearch Serverless を使用すると、サーバーやインフラストラクチャの管理を心配することなく、セマンティック検索を使用して類似のコンテンツをすばやく見つけることができます。以下のコードスニペットは、Amazon OpenSearch Serverless コレクションを作成する方法を示しています: aoss_client = boto3_session.client('opensearchserverless') try: collection = self.aoss_client.create_collection( name=collection_name, type='VECTORSEARCH' ) collection_id = collection['createCollectionDetail']['id'] collection_arn = collection['createCollectionDetail']['arn'] except self.aoss_client.exceptions.ConflictException: collection = self.aoss_client.batch_get_collection( names=[collection_name] )['collectionDetails'][0] pp.pprint(collection) collection_id = collection['id'] collection_arn = collection['arn'] OpenSearch Serverless コレクションが作成されたら、ベクトルフィールドを含むプロパティを持つインデックスを作成します: index_mapping = { "mappings": { "properties": { "video_id": {"type": "keyword"}, "segment_id": {"type": "integer"}, "start_time": {"type": "float"}, "end_time": {"type": "float"}, "embedding": { "type": "dense_vector", "dims": 1024, "index": True, "similarity": "cosine" }, "metadata": {"type": "object"} } } } credentials = boto3.Session().get_credentials() awsauth = AWSV4SignerAuth(credentials, region_name, 'aoss') oss_client = OpenSearch( hosts=[{'host': host, 'port': 443}], http_auth=self.awsauth, use_ssl=True, verify_certs=True, connection_class=RequestsHttpConnection, timeout=300 ) response = oss_client.indices.create(index=index_name, body=index_mapping) Marengo 埋め込みのインデックス作成 以下のコードスニペットは、Marengo モデルからの埋め込み出力を OpenSearch インデックスに取り込む方法を示しています: documents = [] for i, segment in enumerate(video_embeddings): document = { "embedding": segment["embedding"], "start_time": segment["startSec"], "end_time": segment["endSec"], "video_id": video_id, "segment_id": i, "embedding_option": segment.get("embeddingOption", "visual") } documents.append(document) # Bulk index documents bulk_data = [] for doc in documents: bulk_data.append({"index": {"_index": self.index_name}}) bulk_data.append(doc) # Convert to bulk format bulk_body = "\n".join(json.dumps(item) for item in bulk_data) + "\n" response = oss_client.bulk(body=bulk_body, index=self.index_name) クロスモーダルセマンティック検索 Marengo のマルチベクトル設計により、単一ベクトルモデルでは不可能な異なるモダリティ間での検索が可能になります。視覚、音声、動き、コンテキスト要素に対して個別だが整合性のある埋め込みを作成することで、選択した入力タイプを使用して動画を検索できます。例えば、「jazz music playing」というクエリは、1 つのテキストクエリからミュージシャンの演奏動画クリップ、ジャズの音声トラック、コンサートホールのシーンを返します。 以下の例は、さまざまなモダリティにわたる Marengo の優れた検索機能を示しています: テキスト検索 以下は、テキストを使用したクロスモーダルセマンティック検索機能を示すコードスニペットです: text_query = "a person smoking in a room" modelInput={ "inputType": "text", "text": { "inputText": text_query } } response = self.bedrock_client.invoke_model( modelId="us.twelvelabs.marengo-embed-3-0-v1:0", body=json.dumps(modelInput)) result = json.loads(response["body"].read()) query_embedding = result["data"][0]["embedding"] # Search OpenSearch index search_body = { "query": { "knn": { "embedding": { "vector": query_embedding, "k": top_k } } }, "size": top_k, "_source": ["start_time", "end_time", "video_id", "segment_id"] } response = opensearch_client.search(index=self.index_name, body=search_body) print(f"\n✅ Found {len(response['hits']['hits'])} matching segments:") results = [] for hit in response['hits']['hits']: result = { "score": hit["_score"], "video_id": hit["_source"]["video_id"], "segment_id": hit["_source"]["segment_id"], "start_time": hit["_source"]["start_time"], "end_time": hit["_source"]["end_time"] } results.append(result) テキストクエリ「a person smoking in a room」からの上位検索結果は、以下の動画クリップを返します: 画像検索 以下のコードスニペットは、指定された画像に対するクロスモーダルセマンティック検索機能を示しています: s3_image_uri = f's3://{self.s3_bucket_name}/{self.s3_images_path}/{image_path_basename}' s3_output_prefix = f'{self.s3_embeddings_path}/{self.s3_images_path}/{uuid.uuid4()}' modelInput={ "inputType": "image", "image": { "mediaSource": { "s3Location": { "uri": s3_image_uri, "bucketOwner": self.aws_account_id } } } } response = self.bedrock_client.invoke_model( modelId=self.cris_model_id, body=json.dumps(modelInput), ) result = json.loads(response["body"].read()) ... query_embedding = result["data"][0]["embedding"] # Search OpenSearch index search_body = { "query": { "knn": { "embedding": { "vector": query_embedding, "k": top_k } } }, "size": top_k, "_source": ["start_time", "end_time", "video_id", "segment_id"] } response = opensearch_client.search(index=self.index_name, body=search_body) print(f"\n✅ Found {len(response['hits']['hits'])} matching segments:") results = [] for hit in response['hits']['hits']: result = { "score": hit["_score"], "video_id": hit["_source"]["video_id"], "segment_id": hit["_source"]["segment_id"], "start_time": hit["_source"]["start_time"], "end_time": hit["_source"]["end_time"] } results.append(result) 上記の画像からの上位検索結果は、以下の動画クリップを返します: 動画に対するテキストと画像を使用したセマンティック検索に加えて、Marengo モデルは会話や音声に焦点を当てた音声埋め込みを使用して動画を検索することもできます。音声検索機能により、ユーザーは特定の話者、会話の内容、または話されているトピックに基づいて動画を見つけることができます。これにより、動画理解のためにテキスト、画像、音声を組み合わせた包括的な動画検索体験が実現します。 まとめ TwelveLabs Marengo と Amazon Bedrock の組み合わせは、マルチベクトル、マルチモーダルアプローチを通じて動画理解の新しい可能性を切り開きます。この記事では、時間的精度を持つ画像から動画への検索や、詳細なテキストから動画へのマッチングなどの実践的な例を探りました。たった 1 回の Bedrock API 呼び出しで、1 つの動画ファイルをテキスト、視覚、音声クエリに応答する 336 個の検索可能なセグメントに変換しました。これらの機能は、自然言語によるコンテンツ発見、効率化されたメディア資産管理、および組織が大規模に動画コンテンツをより良く理解し活用するのに役立つその他のアプリケーションの機会を生み出します。 動画がデジタル体験を支配し続ける中、Marengo のようなモデルは、よりインテリジェントな動画分析システムを構築するための堅固な基盤を提供します。 サンプルコード をチェックして、マルチモーダル動画理解がアプリケーションをどのように変革できるかを発見してください。 著者について Wei Teh は、AWS の機械学習ソリューションアーキテクトです。最先端の機械学習ソリューションを使用してお客様のビジネス目標達成を支援することに情熱を注いでいます。仕事以外では、家族とキャンプ、釣り、ハイキングなどのアウトドア活動を楽しんでいます。 Lana Zhang は、AWS の Worldwide Specialist Organization に所属する生成 AI のシニアスペシャリストソリューションアーキテクトです。AI 音声アシスタントやマルチモーダル理解などのユースケースに焦点を当てた AI/ML を専門としています。メディア・エンターテインメント、ゲーム、スポーツ、広告、金融サービス、ヘルスケアなど、さまざまな業界のお客様と緊密に連携し、AI を通じてビジネスソリューションの変革を支援しています。 Yanyan Zhang は、Amazon Web Services のシニア生成 AI データサイエンティストです。生成 AI スペシャリストとして最先端の AI/ML 技術に取り組み、お客様が生成 AI を使用して望む成果を達成できるよう支援しています。テキサス A&M 大学で電気工学の博士号を取得しました。仕事以外では、旅行、ワークアウト、新しいことの探求を楽しんでいます。 この記事は Kiro が翻訳を担当し、Solutions Architect の 榎本 貴之 がレビューしました。

Amazon Simple Storage Service (Amazon S3) は、アプリケーションの需要に応じて自動的にスケールする弾力性のあるサービスで、最新の ML ワークロードに必要な高スループットパフォーマンスを提供します。 Amazon S3 Connector for PyTorch や Mountpoint for Amazon S3 などの高性能クライアントコネクタは、S3 REST API を直接扱うことなく、トレーニングパイプラインにネイティブな S3 統合を提供します。 この記事では、Amazon S3 汎用バケットから直接データを読み取る ML トレーニングワークロードのスループットを最適化するための実用的な技術と推奨事項を紹介します。ここで説明するデータ読み込み最適化技術の多くは、さまざまなストレージ基盤に広く適用できます。 これらの推奨事項を検証するため、代表的なコンピュータビジョン (CV) 学習ワークロード、具体的には数万の小さな JPEG ファイルを使用した画像分類タスクをベンチマークしました。S3 バケットからの複数のデータアクセスパターンを評価し、Amazon S3 Connector for PyTorch や Mountpoint for Amazon S3 を含むさまざまな S3 クライアントのパフォーマンスを比較しました。 調査結果によると、データセットを適切なサイズ (通常 100 MB ~ 1 GB) のデータシャードに統合し、シーケンシャルアクセスパターンと組み合わせることで、大幅に高いスループットが得られます。頻繁にアクセスされる学習データをキャッシュすることで、マルチエポック学習シナリオの効率がさらに向上します。最後に、評価した S3 クライアントの中で、Amazon S3 Connector for PyTorch が一貫して最高のスループットを達成し、S3 のデータアクセスに一般的に使用される他の方法を上回りました。 ML トレーニングパイプラインのパフォーマンスボトルネック GPU は ML 計算の高速化に重要な役割を果たしますが、学習は相互に依存するいくつかの段階を持つ多面的なプロセスであり、そのいずれもがボトルネックになる可能性があります。以下の図は、典型的なエンドツーエンドの学習パイプラインを示し、これらの段階がどこで発生するかを強調しています。学習アルゴリズム、モデルアーキテクチャ、実装の詳細、ハードウェアなどの要素はすべて重要ですが、学習ワークロードを以下の 4 つの繰り返し高レベルステップを持つパイプラインとして考えると便利です。 学習サンプルの読み取り – 永続ストレージからメモリへ 学習サンプルの前処理 – デコード、変換、拡張などのステップをメモリ内で実行 モデルパラメータの更新 – GPU 間で計算および同期された勾配に基づいて実行 学習チェックポイントの保存  – 障害発生時に最新の状態から学習を再開できるようにするため、定期的に実行 ML トレーニングパイプラインの実効スループットは、最も遅いステップによって制約されます。ステップ 3 (モデル更新の実際の計算) が最終的に重要ですが、クラウドベースの ML ワークロードには独自の課題があります。通常、コンピューティングとストレージリソースが設計上分離されているクラウド環境では、データ入力パイプライン (ステップ 1 ~ 2 )が重大なボトルネックとして頻繁に現れます。チェックポイント処理 (ステップ 4) も全体的な学習効率に影響を与える可能性がありますが、この記事では取り上げません。 最新の GPU でも、処理するデータを待ってアイドル状態になっている場合、学習を加速できません。データ待ち時間が発生すると、より強力なコンピューティングハードウェアへ追加投資しても非効率であり、本番環境では高コストになります。最大の GPU 使用率を達成するには、GPU が継続的に学習データを処理できるように、データパイプラインを慎重に最適化する必要があります。 データ読み込みの課題 Amazon S3 からのデータ読み込みパフォーマンスに影響を与える最も重要な要素の 1 つは、学習中にデータがアクセスされるパターンです。特に、データ読み取り方法がシーケンシャルかランダムかによって、全体的なスループットとレイテンシーは大きく影響を受けます。これらのアクセスパターンが Amazon S3 の基礎特性とどのように相互作用するかを理解することが、効率的な入力パイプラインを設計するための鍵となります。 Amazon S3 上の ML ワークロードにおけるシーケンシャル読み取りとランダム読み取り Amazon S3 からのデータ読み取りは、機械式アクチュエータアームを持つ従来のハードディスクドライブ (HDD) の動作に例えることができます。以下の図が示すように、HDD はデータブロックが連続して配置されている場合、アクチュエータアームの移動を最小限に抑えてシーケンシャルにデータを読み取ります。対照的に、ランダム読み取りでは、アクチュエータアームがディスク表面を飛び越えて散在するブロックにアクセスする必要があり、アームの物理的な再配置による遅延が発生します。 Amazon S3 上のデータにアクセスする際、状況は HDD の例にやや似ています。正確には、各 S3 リクエストは実際のデータ転送が始まる前に最初のバイトまでの時間 (TTFB) オーバーヘッドが発生します。このオーバーヘッドは、接続の確立、ネットワークラウンドトリップレイテンシー、S3 の内部操作 (データの場所の特定やディスクへのアクセスなど)、クライアント側のレスポンス処理など、いくつかのコンポーネントで構成されます。データ転送時間自体は取得されるデータのサイズに応じてスケールしますが、S3 GET リクエストの TTFB オーバーヘッドは主に固定されており、データオブジェクトのサイズとは独立しています。これを以下の図が示しています。 ML ワークロードを議論する際の HDD のアナロジーに従えば、例えばデータセットが S3 に保存された多数の小さなファイルで構成され、各ファイルに単一の学習サンプルが含まれている場合、クラウドストレージからのランダム読み取りパターンがあると言えます。あるいは、学習スクリプトが例えばバイト範囲の S3 GET リクエストを使用して、より大きなファイルシャード内のさまざまな部分からサンプルを取得する場合にも、ランダム S3 アクセスが発生します。これは、YouTube ビデオをシーンを前後にスキップしながら視聴するのに似ています。 逆に、データセットが大きなファイルシャードに整理され、各シャードに多くの学習サンプルが含まれ、それらを次々とシーケンシャルに反復できる場合、シーケンシャル読み取りパターンが発生します。この場合、単一の S3 GET リクエストで複数のサンプルを取得でき、ランダム読み取りシナリオよりもはるかに高いデータスループットが可能になります。このアプローチはデータのプリフェッチも効率化します。次のサンプルバッチを予測し、取得してメモリにバッファリングできるため、GPU がすぐに利用できる状態になります。 スループットへの影響の分析：コンピュータビジョンのケーススタディ さまざまなデータアクセスパターンがパフォーマンスにどのように影響するかをよりよく理解するために、データセットが多くの比較的小さな画像ファイル (各約 100 KB) で構成されるコンピュータビジョンタスクの 2 つのシナリオを見てみましょう。最初のシナリオでは、データセットはそのまま Amazon S3 Standard ストレージクラスに保存され、学習スクリプトは各画像をオンデマンドで取得します。これにより、各学習サンプルが独自の S3 GET リクエストを必要とするランダム読み取りアクセスパターンが作成されます。S3 Standard の TTFB レイテンシーは数十ミリ秒のオーダーであり、小さなファイルの実際のダウンロード時間はそれに比べて最小限であるため、データローダーのパフォーマンスはレイテンシーバウンドになります。つまり、クライアントスレッドはデータの到着を待っている間、ほとんどの時間をアイドル状態で過ごします。 2 番目のシナリオでは、データセットは S3 に保存される前に、より大きなファイルシャード(例えば各約 100 MB) に統合されます。これで、データローダーは単一の S3 GET リクエストで複数の学習サンプルをシーケンシャルに読み取ります。これにより、ワークロードは帯域幅バウンドにシフトし、サンプルごとの TTFB 影響が除去され、ダウンロードフェーズ中の連続サンプルの効率的なストリーミングが可能になります。 Amazon S3 からのデータ読み込みの最適化技術 S3 からの ML ワークロード用のランダムおよびシーケンシャルデータアクセスパターンについて説明したので、実際にデータ取り込みパイプラインを最適化する方法を見ていきましょう。 S3 向けに最適化された高性能ファイルクライアントの使用 利用可能なオプションが豊富であることを考えると、パフォーマンスの高い S3 ファイルクライアントを選択することは困難です。これに対処するため、2023 年に AWS は S3 用の 2 つのネイティブオープンソースクライアント、Mountpoint for Amazon S3 と Amazon S3 Connector for PyTorch を導入しました。両方とも AWS Common Runtime (CRT) 上に構築されており、CRT はリクエストの並列化、タイムアウト、リトライ、接続の再利用などのベストプラクティスのパフォーマンス最適化を実装するネイティブ S3 クライアントを含む、高度に最適化された C ベースのプリミティブのコレクションです。これにより、お客様は最小限の労力で最大の S3 スループットを達成できます。 Mountpoint for Amazon S3 は、コンピューティングインスタンスに S3 バケットをマウントし、既存のコードを変更することなくローカルファイルシステムとしてアクセスできるオープンソースのファイルクライアントです。これにより、ML トレーニングを含む幅広いワークロードに適しています。 Kubernetes 環境では、Mountpoint for Amazon S3 Container Storage Interface (CSI) Driver が S3 バケットをストレージボリュームとして提示することでこの機能を拡張し、コンテナが使い慣れたファイルシステムインターフェースを通じて S3 オブジェクトにアクセスできるようにします。最近リリースされた Mountpoint for Amazon S3 CSI v2 では、ドライバーはポッド間の共有キャッシングも導入しており、分散 ML ワークロードがローカルにキャッシュされたデータを再利用できるため、パフォーマンスとリソース効率の両方が向上します。CSI ドライバーは、あらゆる Kubernetes ベースのアプリケーションと互換性があり、Amazon Elastic Kubernetes Service (Amazon EKS) と統合でき、そこでは合理化されたインストールとライフサイクル管理のためのマネージドアドオンとして利用できます。 Amazon S3 Connector for PyTorch は、PyTorchのための、S3 と学習パイプラインを密接に連携できる機能です。この統合により、学習データへの高スループットアクセスと、Amazon S3 への直接的な効率的なチェックポイント処理が可能になります。学習データの読み取りやモデルチェックポイントの書き込み時に、パフォーマンス最適化を自動的に適用します。 コネクタは、ランダムアクセス用のマップスタイルデータセットと、シーケンシャルアクセスをストリーミングするための反復可能スタイルデータセットの両方をサポートしており、さまざまな ML 学習パターンに適しています。また、ローカルストレージに依存せずに S3 からチェックポイントを保存および読み込むことができる組み込みのチェックポイントインターフェースも含まれています。インストールは簡単 (例えば pip を使用) で、コネクタは追加のファイルシステムクライアントや複雑なシステムセットアップを必要とせず、 GitHub で実証されているように、学習コードへの最小限の変更のみが必要です。 データセットのシャード化とシーケンシャル読み取りパターンの使用 S3 からのデータ読み込みを最適化するための効果的な戦略は、データセットを各々に多くの学習サンプルを含む、より少数のより大きなファイルシャードにシリアル化し、データローダーを使用してそれらのサンプルをシーケンシャルに読み取ることです。 S3 micro-benchmark では、100 MB ~ 1 GB のシャードサイズが通常、優れたスループットを提供しました。ただし、理想的なサイズはワークロードによって異なる場合があります。小さなシャードはプリフェッチバッファからの準ランダムサンプリング動作を改善でき、大きなシャードは一般的により良いスループットを提供します。 シャード化の一般的なファイル形式には、 tar ( WebDataset などのライブラリを通じて PyTorch で頻繁に使用されます)と TFRecord (TensorFlow で tf.data と共に使用されます) があります。とはいえ、データのシャード化はシーケンシャル読み取りを保証するものではありません。データローダーがシャード内のサンプルにランダムにアクセスする場合 ( Parquet や HDF5 などの形式で一般的)、シーケンシャルアクセスの利点が失われる可能性があります。パフォーマンス向上を完全に実現するには、各シャード内のサンプルが順番に読み取られるようにデータローダーを設計することをお勧めします。 トレーニングサンプルの並列化、プリフェッチ、キャッシング ML パイプラインのデータ取り込みおよび前処理段階の最適化は、学習スループットの最大化、特にランダムデータアクセスパターンが避けられない場合に重要です。並列化、プリフェッチ、キャッシングなどの技術は、I/O ボトルネックを最小限に抑え、GPU を完全に利用する上で中心的な役割を果たします。 並列化 は、データ読み込みパイプラインのスループットを向上させる最も効果的な方法の 1 つです。特に、データのデコードと前処理は、通信する必要なく同時に実行できる多くの独立したプロセスに分解できる、非常に並列化しやすい処理であることが多いためです。TensorFlow ( tf.data ) や PyTorch (ネイティブな  DataLoader ) などのフレームワークを使用して、ワーカープール (CPU スレッドまたはプロセス) のサイズを調整し、データ取り込みを並列化できます。 シーケンシャルアクセスパターンの場合、経験則としては、ワーカースレッドの数を利用可能な CPU コアの数に合わせることです。ただし、CPU カウントが高いインスタンス (例えば 20 を超える) では、やや小さいプールサイズを使用すると効率が向上します。 対照的に、ランダムアクセスパターン、特に S3 から直接読み取る場合、ベンチマークでは CPU カウントよりも大きなプールサイズが有益であることが証明されました。例えば、8 個の vCPU を持つ EC2 インスタンスでは、PyTorch の  num_workers 設定を 64 以上に増やすと、データスループットが大幅に向上しました。 とはいえ、並列化を増やすことは万能薬ではありません。過度の並列化は CPU とメモリリソースを圧倒し、ボトルネックを I/O から前処理にシフトさせる可能性があります。適切なバランスを見つけるために、特定のワークロードのコンテキスト内でベンチマークを行うことが重要です。 プリフェッチ は、データ読み込みを GPU 計算から分離することで並列化を補完します。プロデューサー-コンシューマーパターンを使用して、プリフェッチはデータを非同期で準備し、メモリにバッファリングすることで、GPU が必要とするときに次のバッチが準備できるようにします。適切なサイズのプリフェッチバッファと適切に調整されたワーカープールサイズは、I/O と前処理のレイテンシーを償却し、全体的な学習スループットを向上させるのに役立ちます。 キャッシング は、同じデータサンプルが複数回読み取られるランダムアクセスパターンを持つマルチエポック学習ワークロードに特に効果的です。Mountpoint for Amazon S3 などのツールは、データセットオブジェクトをインスタンスストレージ (例えば NVMe ディスク)、EBS ボリューム、またはメモリにローカルに保存する組み込みのキャッシングメカニズムを提供します。繰り返される S3 GET リクエストを削除することで、キャッシングは学習速度とコスト効率を向上させます。 学習中は入力データセットが通常静的なままであるため、繰り返される S3 リクエストオーバーヘッドを減らすために、無期限のメタデータ TTL で Mountpoint を構成することをお勧めします ( --metadata-ttl indefinite を設定します、 Mountpoint for S3 ドキュメント を参照ください)。さらに、ベンチマークでは、NVMe へのデータキャッシングも有効にし、Mountpoint がオブジェクトをローカルに保存できるようにしました。キャッシュは、最も最近使用されていないファイルを削除することでスペースを自動的に管理し、デフォルト設定では、ディスク容量の少なくとも 5%を空きスペースとして確保します (設定可能)。キャッシングから完全に恩恵を受けるには、インスタンスに頻繁にアクセスされるデータを保持するのに十分なディスクスペースがあることを確認してください。 パフォーマンスケーススタディ：Amazon S3 Standard からのデータ読み込み 前述のベストプラクティスを検証するため、ランダムおよびシーケンシャルデータアクセスパターンの両方で、現実的なコンピュータビジョン (CV) 学習ワークロードをシミュレートする一連のベンチマークを実施しました。正確な結果は特定のユースケースによって異なる場合がありますが、パフォーマンスの傾向と洞察は、ML トレーニングパイプライン全体に広く適用できます。 ベンチマークセットアップ すべてのベンチマークは、NVIDIA A10G GPU と 32 個の vCPU を搭載した Amazon Elastic Compute Cloud (Amazon EC2) g5.8xlarge インスタンスで実行されました。ベンチマークワークロードは、画像分類タスク用の google/vit-base-patch16-224-in21k バックボーン ViT モデルを使用し、100,000 枚の合成 JPEG 画像 (各約 115 KB) を含む 10 GB のデータセットで学習しました。データセットは、次のいずれかの S3 クライアントを使用して、学習スクリプトによって Amazon S3 Standard からオンデマンドで直接ストリーミングされました。 fsspec ベースのデータローダー – クラウドオブジェクトストア用の人気のあるオープンソースインターフェースである fsspec に基づく TorchData DataPipes の実装。TorchData は v0.10 でDataPipes を廃止しましたが、fsspec は S3 からの ML データアクセスに広く使用されています。 Mountpoint for Amazon S3 (データキャッシングなし) – AWS が開発した高スループットのオープンソースファイルクライアント。この構成では、メタデータキャッシングは有効ですが、学習サンプルはエポック間でローカルにキャッシュされません。 Mountpoint for Amazon S3 (データキャッシング) – 前のクライアントと同じですが、エポック全体で頻繁にアクセスされるサンプルを保存するために、ローカルディスクキャッシングが有効になっています。 S3 Connector for PyTorch – PyTorch のデータセット API と緊密に統合された高性能のオープンソース S3 インターフェースで、AWS がメンテナンスしています。 各ベンチマーク構成は、事前のローカルダウンロードや前処理なしに、学習中にデータセットをオンデマンドでストリーミングしました。 ベンチマークの目標 ベンチマークは以下を探求するために設計されました。 データローダーでの並列化設定の調整の効果 Mountpoint for Amazon S3 を使用したローカルディスクキャッシングのパフォーマンスへの影響 シーケンシャル読み取りパターンの採用によるスループット向上 データセットシャードサイズと持続的なデータ読み込みパフォーマンスの関係 両方のアクセスパターンについて、前処理段階には JPEG デコードと 224×224×3 へのリサイズが含まれ、その後 128 のミニバッチにバッチ化されました。この軽量なセットアップにより、CPU バウンドのオーバーヘッドを最小限に抑えながら、現実的なエンドツーエンドのパイプラインを維持することができました。 再現性とベストプラクティス 独自の環境で同様のベンチマークを再現するために、さまざまな S3 データ読み込み構成をサポートする 専用のベンチマークツール を提供しています。 一貫性のある意味のある結果を得るために： 各 S3 クライアントに対して同一の EC2 インスタンスタイプを使用します。 各テストデータセットを別々の S3 バケットに配置して、トラフィックを分離し、クライアント間の干渉を避けます。 S3 バケットと同じ AWS リージョンで実験を実行して、レイテンシーとネットワークの変動を最小限に抑えます。 これらのベストプラクティスに従うことで、クリーンな測定値を取得し、独自のワークロードでさまざまなデータ読み込み戦略を確実に比較できます。 ランダムアクセスでの単一エポックベンチマーク Amazon S3 から直接データセットをストリーミングする際の並列化の効果を評価するために、潜在的な OS レベルのキャッシングからの干渉を避けるため、1 エポックのベンチマーク (学習データセット全体を 1 回読み込み) を実行しました。 少ないワーカー数では、すべての S3 クライアントがデータ取り込みボトルネックを示し、全体的なスループットを制限します。並列化の度合いが増加すると、スループットが大幅に向上します。特に、S3 Connector for PyTorch は、16 ワーカー以上でほぼ GPU 飽和 (約 138 サンプル/秒) に達します。 ただし、ワーカープールの積極的なスケーリングは、CPU とメモリの負荷を増加させます。これは fsspec ベースのデータローダーで特に顕著で、32 ワーカーで約 100% の CPU 使用率に達し、CPU バウンドのボトルネックを引き起こし、GPU 使用率を低下させ、全体的なサンプルスループットを減少させます。対照的に、S3 Connector for PyTorch は負荷下でより良い効率を維持し、高性能 S3 クライアントを使用することの重要性を強調しています。 データキャッシングありとなしの Mountpoint for Amazon S3 は、この 1 エポックベンチマークでほぼ同じパフォーマンスを提供します。これは予想通りで、各サンプルが一度だけ読み取られ、キャッシングが利点を提供しないためです。次に説明するマルチエポックシナリオでキャッシングの利点を再検討します。 ランダムアクセスでのマルチエポックベンチマーク Mountpoint for Amazon S3 のキャッシング機能は、頻繁にアクセスされる S3 オブジェクトをローカルストレージに保存することで、学習パフォーマンスを大幅に向上させ、エポック間で取得レイテンシーとリクエストコストを削減します。ベンチマークでは、最初のエポック中にアクセスされたデータセットファイルがローカルにキャッシュされます。2 番目のエポック以降、データセット全体がディスクから提供され、データローダーワーカープールが 16 であっても GPU を完全に飽和させ、スループットを最大化します。 次のプロットに示されているように、キャッシングはトレーニングを加速するだけでなく、ネットワークトラフィックと S3 リクエスト量も最小限に抑えます。最初のエポックの終わり (約 2 分マークあたり) までに、Mountpoint は S3 への GET、LIST、HEAD リクエストをさらに削減します。対照的に、キャッシングなしの S3 クライアントは、各エポックで同じデータを継続的に再ダウンロードし、より高いレイテンシーと運用コストを発生させます。 シーケンシャルアクセスでの単一エポックベンチマーク シーケンシャルデータアクセスの利点を検証するために、以前と同じセットアップ (8 データローダーワーカー)を使用してベンチマークを再実行しましたが、シャードサイズが 4 MB ~ 256 MB の tar 形式のシリアル化されたデータセットに切り替えました。 一見すると、このベンチマークの結果は地味に見えるかもしれません。すべての折れ線プロットが平坦です。しかし待ってください、それこそが素晴らしい部分ではないでしょうか？ GPU 負荷は一貫して約 100% の使用率で平坦であり、すべてのファイルシャードサイズにわたって GPU を完全に飽和させていることを意味します。それを一貫して低い CPU 使用率と組み合わせると、非常に注目すべき成果が得られます！ シーケンシャルアクセスでの理論上の最大ベンチマーク 前述のベンチマークの結果は興味深い疑問を提起します。シーケンシャルアクセスで、このセットアップで達成できる理論上の最大スループットはどれぐらいでしょうか？調査のために、方程式から GPU バウンドのモデル学習段階を削除し、CPU 上での読み取りと前処理段階のみを残しました。ワーカープールサイズ 8 の結果を次のプロットに示します。 結果は、fsspec ベースのデータローダーを除くすべてのクライアントで、シャードサイズが大きいほどスループットが向上することを示しています。S3 Connector for PyTorch は最高のパフォーマンスを提供し、テストされた最大のシャードサイズで 8,000 サンプル/秒を超えます。より高い並列化 (32 ~ 64 ワーカー) またはより大きなシャードでは、スループットはさらにスケールし、拡張テストで 12,000 サンプル/秒を超えました。 結論 クラウドでの最新の ML トレーニングパイプラインのパフォーマンスを完全に引き出すには、データ取り込みの最適化が不可欠です。この記事では、ランダムなデータ読み取りや、小さいファイルサイズのデータを使うことがレイテンシーオーバーヘッドを増加させ、スループットを著しく制限する一方で、シーケンシャルアクセスパターンを持つ統合データセットが帯域幅を最大化し、GPU を完全に利用できることを示しました。 Mountpoint for Amazon S3 や S3 Connector for PyTorch などの高性能 Amazon S3 クライアントを使用することが、トレーニングパフォーマンスに大きな違いをもたらすことを探求しました。また、データセットをより大きなファイルにシャード化し、並列化設定を調整し、冗長な S3 リクエストを最小限に抑えるためにキャッシングを適用する利点も示しました。Amazon S3 Standard からのデータアクセスに焦点を当てたベンチマークは、これらのベストプラクティスがアイドル GPU 時間を大幅に削減し、コンピューティングリソースから最大の価値を得るのに役立つことを確認しています。 学習ワークロードが成長するにつれて、データパイプライン設計を見直し続けてください。データ読み込みに関する慎重な決定は、コスト効率と結果までの時間において大きな利益をもたらすことができます。 著者について Dr. Alexander Arzhanov は、ドイツのフランクフルトを拠点とするシニア AI/ML スペシャリストソリューションアーキテクトです。彼は、EMEA 地域全体で AWS の顧客が ML ソリューションを設計および展開するのを支援しています。AWS に入社する前、Alexander は宇宙における重元素の起源を研究しており、大規模な科学計算で ML を使用した後、ML に情熱を持つようになりました。 Ilya Isaev は、英国ケンブリッジを拠点とする Amazon S3 のソフトウェアエンジニアです。彼は、顧客が Amazon S3 で学習データとモデルチェックポイントを効率的に保存および管理できるよう支援し、高性能 GPU インスタンスの大規模クラスター向けのリアルタイムデータアクセスパフォーマンスの改善に焦点を当てています。 Roy Allela は、AWS のシニア AI/ML スペシャリストソリューションアーキテクトです。彼は、小規模なスタートアップから大企業まで、AWS の顧客が AWS 上で基盤モデルを効率的に学習および展開するのを支援しています。彼は計算最適化問題と AI ワークロードのパフォーマンス向上に情熱を持っています。 翻訳はソリューションアーキテクトの 長谷川 大 が担当しました。原文は こちら です。

2025年12月12日にAWS Systems Manager for SAPにおいて、AWSでSAPランドスケープを自動化・管理する方法を変革する3つの機能を発表しました： 構成管理のためのSAPアプリケーションカバレッジの拡張 : AWS Systems Manager for SAP Configuration Managementの自動構成検証が、SAP ABAPアプリケーションをサポートするようになり、S/4HANA、BW/4HANA、ECCなどのABAPベースのSAPアプリケーション全体にわたる包括的なカバレッジを提供します。 Amazon Qによる生成AI搭載のSAPオペレーション : Amazon Qを使用した自然言語でのやり取りを通じて、SAPオペレーションに関する即座のコンテキストに応じた支援を受けられます。 自動タスクスケジューリング : 新しいEventBridge統合により、構成チェックとSAPアプリケーションのアプリケーション認識型起動/停止などのAWS Systems Managerがサポートするオペレーショナルタスクの柔軟なスケジューリングが可能になります。 これらの機能強化により、SAPオペレーションチームに以下の主要なメリットがもたらされます： データベース層とアプリケーション層全体にわたる包括的な構成管理 迅速なオペレーショナルインサイトと運用管理タスクの実行のための対話型インターフェース EventBridgeを使用した定型管理タスクのスケジュール化された自動化 ABAPベースのSAPアプリケーション向けの包括的な構成検証 SAPアプリケーションは、財務からサプライチェーンまで、企業の中核となるビジネスプロセスを支える重要なシステムです。当社の構成チェックは当初SAP HANAデータベースをサポートしていましたが、お客様からSAP ABAPベースのアプリケーションを自動的に検証できる機能のご要望をいただいておりました。今回のリリースにより、自動検証をSAP ABAPベースのアプリケーションにも拡張いたします。この拡張により、データベース層とアプリケーション層の両方をカバーする、SAPシステム全体にわたる一貫したベストプラクティス検証が保証されます。 拡張された設定チェックに含まれる内容: 今回のリリースでは、既存の設定チェックを拡張し、SAP ABAPアプリケーションをサポートします。 HANAデプロイメントで効果が実証されている3つの包括的な設定チェックが、 AWS Well-Architected FrameworkのSAP Lens および AWS for SAP技術ドキュメント に照らしてABAPアプリケーション設定を検証できるようになりました。 EC2インスタンスタイプ選択チェック EC2インスタンスタイプ選択チェック は、ABAPアプリケーションサーバーが適切なハードウェア設定を持つ認定インスタンスタイプで実行されていることを検証します ストレージ構成チェック は、ABAPアプリケーションサーバーのストレージ構成がAWSの推奨事項に従っていることを確認します Pacemakerクラスター構成チェック は、ABAPアプリケーションサーバーの高可用性セットアップを検証します 各チェックは、構成のさまざまな側面を評価する個別のルールを通じて、同じ包括的な評価を提供し、OKAY、ERROR、WARNING、またはINFOのステータスを返します。これらのチェックは、HANAとABAPの両方の要件に合わせて調整されており、期待される値、参照リンク、および関連する技術ドキュメントを示すことで修復ガイダンスを提供します。 SAP ABAPアプリケーション構成の検証 AWS Systems Manager for SAP Configuration Managerを使い始めるには、まず SAP ABAPアプリケーションをSystems Manager for SAPに登録 してください。アプリケーション構成をベストプラクティスと照らし合わせて評価する前に、この登録が必要です。 SAP ABAPアプリケーションをAWS Systems Manager for SAPに登録した後、AWS Management Consoleから、AWS Systems Manager -> Application Managerに移動します。 検索フィールドで、Application sourceとしてSAPを選択すると、登録済みのSAP ABAPシステムを素早く見つけることができます。 評価したいSAP ABAPアプリケーションを選択し、「Actions」ドロップダウンメニューをクリックして「SAP check configuration」を選択します。詳細な手順については ドキュメント を参照してください。 Amazon Q*でSAP運用を強化 *お客様がSAPトランスフォーメーションの一環としてAWS AIサービスを使用する際には、 AWS責任あるAIポリシー を参照することをお勧めします。 AWS上でSAPアプリケーションを運用するには、SAP Basis管理者からインフラストラクチャチームまで、複数の役割にわたる調整が必要です。AWS Systems Manager for SAPは、アプリケーションの登録と検出を通じて多くの管理タスクを統合しますが、包括的な運用のためには、チームは依然として複数のサービスインターフェースを操作する必要があります。 Amazon Qは、AWS Systems Manager for SAPおよび関連するAWSサービスへの統一された会話型インターフェースを提供することで、これらの機能を強化します。自然言語でのやり取りを通じて、チームは次のことができます： SAPアプリケーションの状態と設定の照会 AWSサービスとSAP運用インサイトへのアクセス コンテキストに応じたドキュメントとベストプラクティスの取得 インフラストラクチャの設定とメトリクスの調査 AWS Systems Manager for SAPおよび関連サービスAPIとのインターフェース 注：Amazon Qは運用データと推奨事項への便利なアクセスを提供しますが、本番環境に実装する前に、すべての出力をお客様の組織の要件とベストプラクティスに照らして検証する必要があります。 SAP運用のためにAmazon Qとやり取りする方法の例をいくつか示します： "What instance type is S4HANADev running on" "Compare costs between my current SAP HANA instance for S4HANADev and other certified alternatives" "Show me potential savings if I switch to Reserved Instances for my S4HANADev-HANA application" "I can't connect to S4HANADev-HANA database using HANA Studio, check network configurations" "Review security group configurations for S4HANADev-HANA database access" "Can you summarize the SAP configuration checks that were run previously on my Systems Manager for SAP application S4HANADev ? Use the following guidance - Get the failed subchecks, using list-subcheck-results - For each failed subcheck result ID, use it as an input to call it with list-subcheck-rule-results API, and get additional details on the failures and recommendations - Do the same for each failed subcheck above". Amazon QでSAPアプリケーションを運用する AWSコンソール内のAmazon Qは、AWS上でのSAP運用に対して会話形式のサポートを提供します。以下の手順で開始できます： AWSマネジメントコンソールにサインインします 任意のコンソールページの右上隅にあるAmazon Qアイコンを選択します チャットパネルが開き、SAPの運用に関するお問い合わせをサポートする準備が整います EventBridge統合によるオペレーションのスケジューリング AWS Systems Manager for SAPは、APIとコンソール体験の両方からアクセス可能な、起動/停止機能や設定検証を含むアプリケーション対応のSAPオペレーション機能を提供します。お客様はこれらの機能をオンデマンドのオペレーションに使用してきましたが、週次のコンプライアンスチェックや営業時間外の自動起動/停止などの定期的なアクティビティの自動化に対する需要が高まっています。新しいAmazon EventBridge Scheduler統合は、AWS Systems Manager for SAPオペレーションの自動実行を可能にすることでこのニーズに対応し、お客様がこれらのタスクを効率的にスケジュールおよび自動化できるようにします。 Amazon EventBridge SchedulerによるSAPオペレーションの自動化は簡単です： EventBridge Schedulerへのアクセス AWS Management Consoleにサインインします Amazon EventBridgeに移動します Scheduler を選択し、 Create schedule を選択します スケジュールタイプの選択 1回限り: 移行前のチェックやアップグレード後の検証に使用 レートベース: 定期的な間隔で実行（例：「7日ごと」） Cronベース: 正確なタイミングで実行（例：「毎週月曜日の午前2時」） ターゲットを設定する ターゲットの詳細で： AWS services を選択 「All APIs」から Systems Manager for SAP を選択 アクションとして StartConfigurationChecks を選択 必要なパラメータを指定します： { "ApplicationId": "S4HANADev", } EventBridge Schedulerは実行とログ記録を自動的に処理し、AWSオートメーションワークフローとのシームレスな統合を提供します。 2. アクセス許可 セクションで、SchedulerがStartConfigurationCheck操作を正常に実行するためには、 こちら に記載されている手順を使用してIAMロールを作成する必要があります。 提供状況と料金 AWS Systems Manager for SAPのすべての機能は、Systems Manager for SAPが サポートされている AWSリージョンで利用可能です。Amazon Qの統合とEventBridge Schedulerの自動化は、これらのサービスが利用可能なリージョンでご利用いただけます。サポートされているリージョンの最新リストについては、AWSサービスエンドポイントの ドキュメント をご覧ください。 AWS Systems Manager for SAPは、初期費用や最低料金なしのシンプルな従量課金制の料金モデルに従っています。SAPアプリケーションの登録、アプリケーション対応の起動/停止操作、基本的なモニタリングを含む基本機能は、追加料金なしで利用できます。構成管理については、アプリケーションごとに1回の構成チェック実行につき0.25ドルをお支払いいただき、結果は30日間保持されます。たとえば、2つのSAPアプリケーションに対して週3回チェックを実行する場合、月額6.00ドルとなります。SAP HANAデータベースに対してAWS Backup統合を使用する場合、使用したAWS Backupストレージに対してのみお支払いいただき、バックアップオーケストレーションに対する追加料金はかかりません。EventBridge Schedulerを使用した自動化操作については、スケジュールあたり1日0.00864ドル（日次スケジュールの場合、月額約0.26ドル）という最小限の料金が発生します。 まとめ この発表により、AWS Systems Manager for SAPの機能が拡張され、ABAPアプリケーション全体にわたる包括的な設定検証、コンテキストに応じた洞察とインテリジェントな推奨事項を提供するAmazon Qを通じた生成AI搭載のオペレーション、およびEventBridgeによる自動タスクスケジューリングが可能になりました。これらの機能強化により、お客様はSAPランドスケープ全体で一貫した設定基準を維持し、AI支援によるトラブルシューティングと意思決定を通じてオペレーションを効率化し、日常的なタスクを効率的に自動化できるようになります。AWS Systems Manager for SAPにSAPアプリケーションを登録して、今日から始めましょう。詳細については、 AWS Systems Manager for SAPドキュメント をご覧ください。 本ブログは Amazon Bedrock による機械翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

はじめに こんにちは。AWS Analytics Specialist ソリューションアーキテクトの深見 です。 データベースの変更をリアルタイムに分析基盤へ反映したいというニーズに高まりを感じています。実際に多くのお客様から相談をいただいております。またデータベースの差分をもとに連携することが望まれる場面も多くあります。そういう場合の選択肢の一つが CDC（Change Data Capture）と呼ばれる MySQL の binlogなどの変更履歴をもとにデータを連携する手法になります。しかし、CDC での実装は、データ取得・キャッシュレイヤー・コンシューマーの実装とコンポーネントが多くなる場合も多く技術的なハードルが高く、ソースデータベースのスキーマの変更をターゲットの分析基盤に滞りなく連携する必要があるなど運用負荷も大きいワークロードになります。 CDC のターゲットの選択肢の１つとして、Iceberg を利用することで多様なエンジンから利用することができ、ソーススキーマの変更にも柔軟に対応ができるコスト効率の良い、DB のデータをソースにしたデータレイクハウスを構築することができます。 本記事では、AWS パートナーである primeNumber 社 が提供するデータ統合プラットフォーム「TROCCO」の CDC 機能を使って、MySQL から AWS 上の Apache Iceberg テーブルへのリアルタイムレプリケーションを実現する方法をご紹介します。実際に検証した内容をもとに、セットアップから運用まで詳しく解説していきます。 RDB から Apache Iceberg テーブルへのデータ連携のユースケース RDB をソースに Apache Iceberg へデータを連携したい場面はどのようなケースがあるでしょうか？いくつかの例をみてみましょう。 OLTP と OLAP の分離 RDB にあるデータを分析に使いたい場合でも、様々な理由で直接 RDB に分析クエリを実行することがためらわれる場面はよくあるかと思います。その中でも多く上がる理由としては、ソース DB のトランザクショナルなワークロードのパフォーマンスに影響を与えたくないといった理由です。インタラクティブに分析されるケースでは、そのためだけにリードレプリカなどで分析用のリソースを用意することもコスト増加につながってしまいます。そのため、 OLTP (Online Transaction Processing) と OLAP(Online Analytical Processing) を分離することでリソース管理・効率の向上やコスト最適化を狙った分離を行うことがあります。Apache Iceberg を利用することで高いコスト効率で OLAP 環境を用意することが可能になります。また、Apache Iceberg のオープンなフォーマットである特徴から分析ユーザーの好みのクエリエンジンを利用することが非常に簡単になります。例えば AWS のエンジンであれば Athena や Redshift 、OSS のエンジンであれば Spark や Trino 、 DuckDB や PyIceberg から同じテーブルを参照することができるようになります。これにより、広い活用の幅をもったデータレイクを構築することが可能になります。 タイムトラベル機能を利用した過去断面の参照 データベーステーブルの過去の断面を再現する必要のある場面は度々見受けられます。例えば、テーブルのデータに不整合が発生した際のロールバック、もしくは ML や AI のモデル開発時のモデル変更による影響を過去のテーブルを使って確認するバックテストといったユースケースがあげられます。 これに関連する Iceberg の大きな特徴として、スナップショットを利用した過去のテーブルの断面を指定してクエリを実行する タイムトラベル 機能があります。RDB から Iceberg テーブルにデータを差分で連携することで過去のテーブルの状態を容易に確認することが可能です。従来変更差分をバックアップとして保持しようとすると、定期的にフルスナップショットを取得しそれを保管しておくといったコストのかかる方法が必要でした。しかし、Iceberg では差分データを効率的に保持することが可能なため高いコスト効率でテーブルの断面を保持することが可能です。   他にも様々な場面で RDB から Iceberg テーブルへのデータ連携が有効なソリューションになりえます。これを実装や管理・運用の手間を低く抑えて実現することができる 1 つの手段が TROCCO の CDC 機能になります。 TROCCO とは TROCCO は、データの収集・加工・転送を簡単に実現できるデータ基盤構築・運用の支援 SaaS です。ノーコード/ローコードでデータパイプラインを構築でき、多様なデータソースとデスティネーションに対応しています。 今回ご紹介する TROCCO の CDC 機能 は、ソーステーブルの変更（INSERT/UPDATE/DELETE）やカラムの追加といったスキーマの変更をリアルタイムに検知し、ターゲットシステムへ自動的に反映することをインフラの管理なく実現することができる機能です。ソース DB としては、2025 年 12 月時点で MySQL と PostgreSQL に対応しています。(CDC 機能は Professional プランの契約が前提となります。) 今回はその中の、ソースの MySQL から ターゲットの AWS 上の Glue Data Catalog に登録された Iceberg テーブルにデータ連携する方法をご紹介します。 アーキテクチャ概要 今回構築するシステムのアーキテクチャは以下の通りです： ソース : MySQL データベース(8.x 以降推奨） CDC 処理 : TROCCO CDC 機能 ターゲット : Amazon S3 + AWS Glue Data Catalog（Apache Iceberg 形式） クエリエンジン : Amazon Athena TROCCO が MySQL のバイナリログを監視し、変更を検知すると、その変更を Iceberg 形式で Amazon S3 に書き込みます。 Glue Data Catalog にメタデータが登録されるため、Athena から即座にクエリ可能になります。 セットアップ手順 1. ネットワーク設定 TROCCO から MySQL へ接続するため、セキュリティグループの設定が必要です。TROCCO の固定 IP アドレスからの接続を許可します。 TROCCO の固定 IP アドレスは 公式ドキュメント で確認できます。また、エフェメラルポートとして 1024-65535 を使用するため、セキュリティグループでこの範囲を開放する必要があります。 2. IAM ロールの作成 TROCCO が S3 と Glue Data Catalog にアクセスするため、適切な権限を持つ IAM ロールを作成します。CDC 機能では IAM ロールのみがサポートされています（IAM ユーザーは使用できません）。 TROCCO のドキュメント  にある必要な IAM ポリシーの例はこのようなものになります。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:ListAllMyBuckets" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:ListBucket" ], "Resource": "arn:aws:s3:::<bucket_name>" }, { "Effect": "Allow", "Action": [ "s3:GetObject", "s3:PutObject", "s3:DeleteObject" ], "Resource": "arn:aws:s3:::<bucket_name>/*" }, { "Effect": "Allow", "Action": [ "glue:GetDatabase", "glue:UpdateDatabase", "glue:CreateDatabase" ], "Resource": [ "arn:aws:glue:<aws_region>:<account_id>:catalog", "arn:aws:glue:<aws_region>:<account_id>:database/<database_name>" ] }, { "Effect": "Allow", "Action": [ "glue:GetTable", "glue:UpdateTable", "glue:CreateTable", "glue:DeleteTable" ], "Resource": [ "arn:aws:glue:<aws_region>:<account_id>:catalog", "arn:aws:glue:<aws_region>:<account_id>:database/<database_name>", "arn:aws:glue:<aws_region>:<account_id>:table/<database_name>/*" ] } ] } ターゲットの Iceberg テーブルの Location である S3 と 該当の Glue Data Catalogへのアクセス権限が必要になります。 3. TROCCO 接続情報の設定 TROCCO の管理画面から、以下の接続情報を登録します。 Amazon S3 の接続情報: IAM Role の ARN、S3 バケット名、リージョン MySQL の接続情報: ホスト名、ポート、データベース名、ユーザー名、パスワード まずは Amazon S3 への接続情報を設定する必要があります。 AWS アカウント ID、先ほど 2 番で作成した IAM Role を設定します。                 また、下部に表示される TROCCO の AWS アカウントと外部 ID を先ほど作成した IAM Role に設定します。             IAM Role の 信頼ポリシーは以下のようになります。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::{TROCCO AWS Account ID}:root" }, "Action": "sts:AssumeRole", "Condition": { "StringEquals": { "sts:ExternalId": {External ID}" } } } ] } 次に、MySQL 接続情報を設定します。接続先 DB のホスト、ポート、ユーザー名、パスワードが必要になります。この設定をする前に ソース DB 側で binlogの設定 が必要になることに注意してください。                 4. CDC 転送設定の作成 今作成した接続情報を元に、TROCCO の管理画面から新しい CDC 転送設定を作成します。                 ここで、この CDC データ転送機能の特徴であるテーブルやカラムの自動追従に関する設定が可能です。テーブル・カラムどちらも追従する、カラムのみ追従する、追従しないの  3 パターンが選択できます。                             先ほど設定した MySQL と S3 の接続情報をここで選択します。S3 の設定については Iceberg のプレフィックスやターゲットテーブルの Glue データベースも選択する必要があります。 設定はなんとこれだけで完了です！ 主要な機能 それでは先ほど作成した CDC データ転送設定を実行してみます。                 データ連携 初回実行時にはフルロードが実行され、ソーステーブルの既存データがすべて Iceberg テーブルに転送されます。なお、スキーマ設定より連携するテーブルは選択することができます。 初回のフルロード完了後は、スケジュール設定に従って MySQL のバイナリログを監視して差分更新を継続的に実行します。スケジュールは最短 5 分間隔で設定可能です。 スキーマ変更の自動追従 TROCCO の CDC 機能は、ソースデータベースのスキーマ変更を自動的に検知し、Iceberg テーブルに反映します。 カラム追加の場合、新しいカラムが Iceberg テーブルに自動的に追加されます。既存レコードの新規カラムは NULL になります。バックフィル機能を有効にすると、全レコードを再転送できますが、Iceberg のスナップショット履歴が失われる点に注意が必要です。詳細は こちら をご覧ください。 カラム削除の場合、TROCCO 側では該当カラムのデータ転送が停止されますが、Iceberg テーブルからカラムは削除されません。必要に応じて手動での削除が必要です。 連携するテーブル・カラムの選択                     転送するテーブルやその中のカラムを選択できるため、機密情報を含むカラムを除外したり、不要なカラムを転送しないことでコストを最適化することも簡単にできます。 その他にも、事前に通知先を設定しておくことで、ジョブの実行結果やスキーマ変更の通知を E-mail や Slack に行うことも可能です。また、ジョブの履歴やそれぞれのログについても UI 上で確認が可能になっています。   連携した Iceberg テーブルへのクエリ ジョブの実行後に AWS コンソールからGlue カタログを確認してみると、TROCCO で設定したテーブルが適切に連携されていることがわかります。               連携先の Iceberg テーブルは Athena や Glue、Redshift などさまざまなエンジンからクエリすることが可能です。Iceberg テーブルへのクエリに対応している 3rd party の製品からのクエリももちろん可能です。（ただし、Equality Delete File の読み取りに対応している必要があります。詳細は Apache Iceberg のdocument をご参照下さい。） 今回は、 SageMaker Unified Studio の AI エージェントが組み込まれたノートブック からクエリを行ってみました。下のスクリーンショットのように、連携された Iceberg テーブルを簡単にクエリすることができました。 また、AI エージェントに対して連携した Iceberg テーブルへのクエリを指示することで、クエリ文を作らせて実行することも可能です。今回は、Iceberg の特徴の一つであるスナップショットの履歴を確認したい旨を指示してみました。 `Show me snapshots history of spark_catalog.trocco.movie_table_usecase.` 実際に生成されたクエリが以下の画像です。Iceberg 特有の概念ではありますが、適切なクエリを生成して実行してくれました。結果をみるとこのテーブルには２つのスナップショットがあるようです。この ID を指定することで、過去のテーブル断面をクエリすることができます。このように、Iceberg とくゆうの機能の操作に慣れていない場合でも AI エージェントを使いながら利用することが可能です。 まとめ TROCCO の CDC 機能を使うことで、複雑な CDC パイプラインを構築することなく低い実装コストで RDB と Apache Iceberg のデータ連携を実現することが可能になります。本ブログで説明したように GUI のみで非常に簡単に設定できる上に、ジョブやソーステーブルの監視と通知の機能も UI 上で利用が可能であり、運用する上でもその負荷を下げてくれる機能が揃っています。 これによって、簡単に RDB のデータをソースとした OLAP 基盤を構築したり、タイムトラベルによるバックアップの役割を持つデータレイクへの連携パイプライン構築することが可能になります。 連携した Iceberg テーブルについて、最適なパフォーマンスが出せるようにデータファイルサイズのコンパクションや期限切れスナップショットの処理などテーブルのメンテナンスが重要です。そのため、 Glue Data Catalog の Iceberg テーブルの自動メンテナンス機能 をはじめとして、メンテナンスジョブの実行についてもご検討いただくことをおすすめします。 ぜひ AWS と そのパートナーである primeNumber 社の TROCCO を利用して効果的なデータ基盤を構築していきましょう。 著者について Shuhei Fukami : AWS Japan で Analytics Specialist Solutions Architect としてデータ分析や検索などデータにまつわるワークロードのご支援をしています。趣味でピザ作りにはまっています。

2025 年 12 月 2 日、 AWS サポート がお客様の支援方法を根本から転換し、事後対応型の問題解決から事前対応型の問題予防へと進化することを発表しました。この進化により、AI を活用した機能と Amazon Web Services (AWS) の専門知識を組み合わせた新しいサポートプランが導入されました。新しく強化されたプランは、潜在的な問題が事業運営に影響する前に特定して対処するのに役立ち、クラウドワークロードをより効果的に運用および最適化するのに役立ちます。 ポートフォリオには、さまざまな運用ニーズに合わせて設計された 3 つのプランが含まれています。各プランには異なる機能があり、上位ティアには下位ティアのすべての機能に加えて、追加機能やサービスレベルが強化されています。それぞれを見てみましょう。 新しく強化された AWS サポート有料プラン Business Support+ は、AI を活用したインテリジェントな支援を提供することで、開発者、スタートアップ、中小企業のエクスペリエンスを変革します。AWS の専門家に直接問い合わせるか、必要に応じてシームレスに AWS の専門家に移行する AI を活用した状況に応じた推奨事項から始めるかを選択できます。AWS のエキスパートは、重大なケースについて 30 分以内 (以前の 2 倍の速さ) で対応します。以前の経緯を踏まえているため、同じことを繰り返す必要がなくなります。 このプランは月額料金が安いため、AI を活用したツールと AWS の専門知識を組み合わせて高度な運用機能を利用できます。このプランでは、お客様固有の環境に基づいてワークロードを最適化できるよう、個別の推奨事項を提示します。また、必要に応じて AWS の専門家にシームレスにテクニカルサポートを受けることができます。 エンタープライズサポート は、確立されたサポートモデルに基づいて構築されています。このティアでは、インテリジェントな運用と AI を活用した信頼できるヒューマンガイダンスを通じて、イノベーションとクラウド運用の成功を促進します。担当のテクニカルアカウントマネージャー (TAM) は、AWS に関する深い知識とお客様の環境からのデータに基づくインサイトを組み合わせて、最適化の機会と潜在的なリスクが業務に影響する前に特定できるよう支援します。このプランでは、追加料金なしで AWS Security Incident Response を利用できます。これは、セキュリティイベントの追跡、保管、管理を一元化する包括的なサービスであり、セキュリティ体制を強化するための自動モニタリングおよび調査機能も提供します。 このティアは、AI を活用した支援と AWS 環境の継続的なモニタリングを通じて、運用の規模を新たなレベルに引き上げるのに役立ちます。本番稼働環境での重大な問題への対応時間は最大 15 分で、サポートエンジニアは AI エージェントからパーソナライズされたコンテキストを提供されるため、このティアでは、オペレーショナルエクセレンスを維持しながら、より迅速でパーソナライズされた解決が可能になります。さらに、継続的な技術成長を促進するためのインタラクティブなプログラムや実践的なワークショップにもアクセスできます。 Unified Operations Support は、拡張された AWS 専門家チームを通じて、状況に応じた最高レベルのサポートを提供します。テクニカルアカウントマネージャー、ドメインエンジニア、指定のシニア請求およびアカウントスペシャリストで構成されるコアチームは、移行、インシデント管理、セキュリティに関するオンデマンドの専門家によって補完されます。これらの専任エキスパートは、お客様固有の環境と運用履歴を理解し、アーキテクチャに関する知識と AI を活用したインサイトを組み合わせながら、お好みのコラボレーションチャネルを通じてガイダンスを提供します。 この階層では、24 時間体制の包括的なモニタリングと AI を活用した自動化により、プロアクティブなリスクの特定と状況に応じたガイダンスにより、ミッションクリティカルな業務を強化します。重大なインシデントが発生すると、お客様のワークロードを理解しているサポートエンジニアから技術的な推奨事項が提供され、5 分以内に対応できます。チームは、体系的なアプリケーションレビューを実施し、運用準備が整っていることを確認し、ビジネスに不可欠なイベントをサポートします。これにより、最高レベルの運用能力を維持しながら、イノベーションに集中できます。 クラウド運用の変革 AWS サポートは、クラウドインフラストラクチャをより効果的に構築、運用、最適化できるように進化しています。お客様のアカウントのサポート履歴と過去のケース、構成、以前のケースのコンテキストを維持しているため、AI を活用した機能と AWS の専門家が、お客様固有の環境に合わせた、より適切で効果的なソリューションを提供できます。 サポートプランの機能は継続的に進化し、インフラストラクチャを包括的に可視化できるようになり、パフォーマンス、セキュリティ、コストの側面にわたる実用的なインサイトが得られ、ビジネスへの影響とコスト面でのメリットを明確に評価できるようになります。この AI 搭載ツールと AWS の専門知識の組み合わせは、事後対応型から事前対応型の運用への根本的な転換を意味し、ビジネスに影響が及ぶ前に問題を未然に防ぐのに役立ちます。 AWS デベロッパーサポート、AWS ビジネスサポート (クラシック)、および AWS Enterprise On-Ramp サポートプランのサブスクライバーは、2027 年 1 月 1 日まで現在のレベルのサポートを引き続き受けることができます。それまでは、AWS マネジメントコンソールにアクセスするか、AWS アカウントチームに連絡することで、いつでも新しいプランや拡張プランのいずれかに移行できます。AWS エンタープライズサポートに登録しているお客様は、いつでもこのプランの新機能を使い始めることができます。 知っておくべきこと Business Support+、Enterprise Support、Unified Operations は、すべての商用 AWS リージョンで利用できます。既存のお客様は、現在のプランを継続することも、パフォーマンスと効率を向上させる新しいサービスを検討することもできます。 Business Support+ は月額 29 ドルからで、以前のビジネスサポートの月額最低額から 71％ 節約できます。エンタープライズサポートは月額 5,000 ドルからで、以前のエンタープライズサポートの最低価格より 67% お得です。Unified Operations は、ミッションクリティカルなワークロードを抱える組織向けに設計され、専任の AWS 専門家チームを対象としており、月額 50,000 ドルからご利用いただけます。すべての新しいサポートプランでは、使用量が多いほどサポートの限界価格が下がる価格帯が採用されています。 重大なケースについては、AWS サポートはプランごとに異なる目標応答時間を提供します。Business Support+ は 30 分、Enterprise Support は 15 分以内、Unified Operations Support は 5 分で最速の応答時間を提供します。 AWS サポートのプランと機能の詳細については、 AWS サポートページ にアクセスするか、 AWS マネジメントコンソール にサインインしてください。 AWS サポート機能に関する実践的なガイダンスについては、アカウントチームとの相談をスケジュールしてください。 原文は こちら です。

2025 年 12 月 2 日、AWS DevOps Agent のパブリックプレビューを発表しました。AWS DevOps Agent は、過去のインシデントと運用パターンを体系的に分析することで、インシデントへの対応、根本原因の特定、将来の問題の防止に役立つ フロンティアエージェント です。 フロンティアエージェントは、自律的で非常にスケーラブルで、絶え間ない介入なしに数時間または数日働く、新しいクラスの AI エージェントです。 本番稼働のインシデントが発生した場合、オンコールエンジニアは、利害関係者とのコミュニケーションを管理しながら根本原因を迅速に特定しなければならないという大きなプレッシャーに直面します。複数のモニタリングツールにわたってデータを分析し、最近のデプロイ状況を確認し、対応チームを調整する必要があります。サービスの復旧後、チームはインシデント学習を体系的な改善に変えるだけの余裕がないことがよくあります。 AWS DevOps Agent は、常時稼働している自律的なオンコールエンジニアです。問題が発生すると、メトリクスやログから GitHub や GitLab での最近のコードデプロイまで、運用ツールチェーン全体のデータを自動的に関連付けます。考えられる根本原因を特定し、的を絞った緩和策を推奨することで、解決までの平均時間を短縮できます。エージェントはインシデントの調整も行い、Slack チャンネルを使ってステークホルダーに最新情報を伝えたり、詳細な調査スケジュールを管理したりしています。 開始するには、 AWS マネジメントコンソール を使用して AWS DevOps Agent を既存のツールに接続します。このエージェントは、 Amazon CloudWatch 、 Datadog 、 Dynatrace 、 New Relic 、 Splunk などの一般的なサービスと連携してオブザーバビリティデータを取得し、GitHub Actions や GitLab CI/CD と統合してデプロイとそのクラウドリソースへの影響を追跡します。Bring Your Own (BYO) モデルコンテキストプロトコル (MCP) サーバー機能により、組織のカスタムツール、専用プラットフォーム、 Grafana や Prometheus などのオープンソースのオブザーバビリティソリューションなどの追加ツールを調査に統合することもできます。 エージェントは仮想チームメンバーとして機能し、チケットシステムからのインシデントに自動的に対応するように設定できます。 ServiceNow のサポートが組み込まれており、構成可能な ウェブフック を通じて、 PagerDuty などの他のインシデント管理ツールのイベントに対応できます。調査が進むにつれて、エージェントはチケットと関連する Slack チャンネルに検出結果を更新します。これらはすべて、エージェントが作成するインテリジェントなアプリケーショントポロジに基づいています。つまり、調査中にデプロイに関連する潜在的な原因を特定するのに役立つデプロイ履歴を含む、システムコンポーネントとその相互作用の包括的なマップです。 仕組みを見ていきましょう その仕組みを説明するために、呼び出されたときに意図的にエラーを生成する単純な AWS Lambda 関数をデプロイしました。 AWS CloudFormation スタックにデプロイしました。 ステップ 1: エージェントスペースを作成する エージェントスペースは、AWS DevOps Agent がタスクを実行する際にアクセスできる範囲を定義します。 エージェントスペースは、運用モデルに基づいて整理できます。エージェントスペースを 1 つのアプリケーションに合わせるチームもあれば、オンコールチームごとに 1 つ作成して複数のサービスを管理するチームもあります。また、一元化されたアプローチを使用する組織もあります。このデモンストレーションでは、1 つのアプリケーション用のエージェントスペースを作成する方法を説明します。このセットアップは、特定のアプリケーションの調査とリソースを分離するのに役立ち、そのコンテキスト内でのインシデントの追跡と分析が容易になります。 AWS マネジメントコンソール の AWS DevOps Agent セクションで、 [エージェントスペースの作成] を選択し、このスペースの名前を入力して、自分または他のユーザーの AWS アカウントの AWS リソースのイントロスペクションに使用する AWS Identity and Access Management (IAM) ロールを作成します。 このデモでは、AWS DevOps Agent ウェブアプリを有効にします。これについては後で詳しく説明します。これは後の段階で実行できます。 準備ができたら、 [作成] を選択します。 作成後、 [トポロジ] タブを選択します。 このビューには、AWS DevOps Agent がタスクを効率的に実行する基盤として選択した主要なリソース、エンティティ、および関係が表示されます。これは、AWS DevOps Agent がアクセスまたは表示できるすべての情報を表しているわけではなく、エージェントが現在最も関連性が高いと見なしているものだけを表しています。デフォルトでは、トポロジには自分のアカウントにある AWS リソースが含まれています。エージェントがさらにタスクを完了すると、新しいリソースを見つけてこのリストに追加します。 ステップ 2: オペレーター向けに AWS DevOps ウェブアプリを設定する AWS DevOps Agent ウェブアプリには、オンコールエンジニアが手動で調査を開始したり、関連するトポロジ要素を含む調査の詳細を表示したり、調査を誘導したり、調査に関する質問をしたりするためのウェブインターフェイスが用意されています。 オペレータアクセス リンクを選択すると、AWS コンソールのエージェントスペースからウェブアプリケーションに直接アクセスできます。または、 AWS IAM アイデンティティセンター を使用してチームのユーザーアクセスを設定することもできます。IAM アイデンティティセンターでは、ユーザーやグループを直接管理したり、ID プロバイダー (IdP) に接続したりできるため、AWS DevOps Agent ウェブアプリケーションにアクセスできるユーザーを一元的に制御できます。 この段階では、この特定のアプリケーションの調査とリソースに集中できるようにエージェントスペースがすべてセットアップされ、DevOps チームがウェブアプリを使用して調査を開始できるようになりました。 このアプリケーションの 1 回限りのセットアップが完了したので、障害が発生した Lambda 関数を呼び出します。呼び出しのたびにエラーが生成されます。Lambda エラー数に関連付けられた CloudWatch アラームが ALARM 状態になります。実際には、ServiceNow などの外部サービスからアラートを受け取る場合があります。このようなアラートを受け取ったときに自動的に調査を開始するように AWS DevOps Agent を設定できます。 このデモでは、 [調査を開始] を選択して手動で調査を開始します。 また、事前に設定された複数の開始点から選択して迅速に調査を開始することもできます。たとえば、直近にトリガーされたアラームを調査し、基礎となるメトリクスとログを分析して根本原因を特定するための [最新アラーム]、コンピューティングリソース全体にわたる高い CPU 使用率メトリクスを調査し、どのプロセスまたはサービスが過剰にリソースを消費しているかを特定するための [高 CPU 使用率]、メトリクス、アプリケーションログを分析し、障害の原因を特定してアプリケーションエラー率の最近の増加を調査する [エラーレートスパイク] などです。 [調査の詳細] 、 [調査の開始点] 、 [インシデントの日付と時刻] 、 [インシデントの AWS アカウント ID] などの情報を入力します。 AWS DevOps Agent ウェブアプリケーションでは、調査の展開をリアルタイムで見ることができます。エージェントはアプリケーションスタックを識別します。CloudWatch からのメトリクスを相互に関連付け、CloudWatch Logs や Splunk などの外部ソースからのログを調べ、GitHub からの最近のコード変更を確認し、 AWS X-Ray からのトレースを分析します。 エラーパターンを特定し、詳細な調査概要を提供します。このデモのコンテキストでは、調査の結果、これらは意図的なテスト例外であることが明らかになり、アラームにつながる関数呼び出しのタイムラインが示され、エラー処理に関するモニタリングの改善も提案されています。 エージェントは Slack の専用インシデントチャンネルを使用し、必要に応じてオンコールチームに通知し、ステークホルダーにリアルタイムのステータス更新を提供します。調査チャットインターフェイスを通じて、「どのログを分析しましたか?」などの明確な質問をすることで、エージェントと直接やり取りできます。また、「これらの特定のロググループに焦点を絞って分析を再実行する」など、追加のコンテキストを提供して調査を進めることができます。 専門家による支援が必要な場合は、ワンクリックで AWS サポートケースを作成し、エージェントの検出結果を自動的に入力し、調査チャットウィンドウから AWS サポートの専門家に直接問い合わせることができます。 このデモでは、AWS DevOps Agent が Lambda コンソール内の手動アクティビティを正しく識別して、意図的にエラーをトリガーする関数を呼び出しました 。 インシデント対応以外にも、AWS DevOps Agent は私の最近のインシデントを分析して、将来の問題を防ぐ効果の大きい改善点を特定します。 インシデントが進行中の場合、エージェントはインシデント緩和タブを通じて即時の緩和計画を提示し、サービスの迅速な復旧を支援します。緩和計画は、開発者に詳細な実装ガイダンスを提供する仕様と、 Kiro などのエージェンティックな開発ツールで構成されています。 長期的なレジリエンスについては、オブザーバビリティ、インフラストラクチャ構成、デプロイパイプラインのギャップを調べることで、潜在的な強化点を特定します。しかし、意図的なエラーを引き起こした単純なデモでは、関連する推奨事項を生成するには不十分でした。 たとえば、重要なサービスにマルチ AZ 配置や包括的なモニタリングが欠けていることが検出されるとします。その場合、エージェントは、運用上の影響や実装の複雑さなどの要素を考慮して、実装ガイダンスを含む詳細な推奨事項を作成します。今後のクイックフォローアップリリースでは、エージェントはコードバグやテストカバレッジの改善を含むように分析を拡大する予定です。 可用性 米国東部 (バージニア北部) リージョンで AWS DevOps Agent を今すぐ試すことができます。エージェント自体は米国東部 (バージニア北部) ( us-east-1 ) で実行されますが、複数の AWS アカウントにわたる任意のリージョンにデプロイされたアプリケーションをモニタリングできます。 プレビュー期間中は AWS DevOps Agent を無料で使用できますが、1 か月あたりのエージェントタスク時間数には制限があります。 本番稼働環境の問題のデバッグに数え切れないほどの夜を費やしてきた者として特に興味深く感じるのは、AWS DevOps Agent が運用上の深いインサイトと実用的で実用的な推奨事項をどのように組み合わせているかという点です。このサービスは、チームが事後対応型の消防から積極的なシステム改善に移行するのに役立ちます。 詳細を確認してプレビューにサインアップするには、 AWS DevOps Agent をご覧ください。 AWS DevOps Agent がどのように運用効率の向上に役立つのかを聞くのを楽しみにしています。 — seb 原文は こちら です。

現代のアプリケーションでは、複数段階の支払い処理、AI エージェントのオーケストレーション、または人間の決定を待つ承認プロセスなど、サービス間の複雑で長期にわたる調整がますます必要になっています。従来、これらを構築するには、状態管理を実装し、障害を処理し、複数のインフラストラクチャサービスを統合するために多大な労力が必要でした。 2025 年 12 月 2 日より、 AWS Lambda の耐久性のある関数 を使用して、使い慣れた AWS Lambda エクスペリエンス内で信頼性の高いマルチステップアプリケーションを直接構築できます。耐久性のある関数とは、すでにご存知のものと同じイベントハンドラーと統合を備えた通常の Lambda 関数です。任意のプログラミング言語でシーケンシャルコードを記述すれば、耐久性のある関数が進行状況を追跡し、障害発生時に自動的に再試行し、定義された時点で最大 1 年間実行を一時停止します。待機中のアイドルコンピューティングの費用を支払う必要はありません。 AWS Lambda の高耐久関数は、耐久実行と呼ばれるチェックポイントとリプレイのメカニズムを使用してこれらの機能を提供します。永続実行のための関数を有効にしたら、新しいオープンソースの永続実行 SDK を関数コードに追加します。次に、「steps」などの SDK プリミティブを使用してビジネスロジックに自動チェックポイントとリトライを追加し、「waits」を使用して計算料金なしで実行を効率的に中断します。実行が予期せず終了すると、Lambda は最後のチェックポイントから再開し、完了した操作をスキップしながらイベントハンドラーを最初からリプレイします。 AWS Lambda 高耐久関数の使用開始 耐久性のある関数の使用方法を説明します。 まず、 コンソールで Lambda 関数 を作成し、 [ゼロから作成者] を選択します。 [永続実行] セクションで、 [有効化] を選択します。耐久性のある関数設定は関数の作成時にのみ設定でき、既存の Lambda 関数では現在変更できないことにご注意ください。 Lambda 高耐久関数を作成したら、提供されているコードを使用して作業を開始できます。 Lambda 高耐久関数には、状態管理と回復を処理する 2 つのコアプリミティブが導入されています。 ステップ — context.step() メソッドは、ビジネスロジックに自動再試行とチェックポイントを追加します。ステップが完了すると、リプレイ中はスキップされます。 待機 — context.wait() メソッドは、指定された時間だけ実行を一時停止し、関数を終了し、計算料金なしで実行を一時停止して再開します。 さらに、Lambda の高耐久関数には、より複雑なパターンに対応するオペレーションが他にも用意されています。 create_callback() は API レスポンスや人的承認などの外部イベントの結果を待つために使用できるコールバックを作成し、 wait_for_condition() は特定の条件が満たされる (たとえば REST API をポーリングしてプロセスが完了する) まで一時停止します。また、 parallel() または map() オペレーションは高度な同時実行ユースケースに利用できます。 本番稼働準備が整った注文処理ワークフローの構築 次に、デフォルトの例を拡張して、本番稼働環境ですぐに使える注文処理ワークフローを構築しましょう。これは、外部承認にコールバックを使用し、エラーを適切に処理し、再試行戦略を設定する方法を示しています。これらのコアコンセプトに焦点を当てるために、コードは意図的に簡潔にしています。完全に実装すると、 Amazon Bedrock を使用して検証ステップを強化し、AI を活用した注文分析を追加することができます。 注文処理ワークフローの仕組みは次のとおりです。 最初に validate_order() は注文データをチェックして、すべての必須フィールドが存在することを確認します。 次に、 send_for_approval() は外部からの承認を求める命令を送信し、コールバック応答を待って、コンピューティング料金なしで実行を一時停止します。 その後、 process_order() は注文処理を完了します。 ワークフロー全体を通して、try-catch エラー処理は、実行をすぐに停止するターミナルエラーと、自動再試行をトリガーするステップ内の回復可能なエラーを区別します。 ステップ定義とメインハンドラーを含む完全な注文処理ワークフローは次のとおりです。 import random from aws_durable_execution_sdk_python import ( DurableContext, StepContext, durable_execution, durable_step, ) from aws_durable_execution_sdk_python.config import ( Duration, StepConfig, CallbackConfig, ) from aws_durable_execution_sdk_python.retries import ( RetryStrategyConfig, create_retry_strategy, ) @durable_step def validate_order(step_context: StepContext, order_id: str) -> dict: """Validates order data using AI.""" step_context.logger.info(f"Validating order: {order_id}") # 本番稼働: Amazon Bedrock を呼び出して注文の完全性と正確性を検証 return {"order_id": order_id, "status": "validated"} @durable_step def send_for_approval(step_context: StepContext, callback_id: str, order_id: str) -> dict: """Sends order for approval using the provided callback token.""" step_context.logger.info(f"Sending order {order_id} for approval with callback_id: {callback_id}") # 本番稼働: callback_id を外部承認システムに送信 # 外部システムは Lambda SendDurableExecutionCallbackSuccess を呼び出すか # 承認が完了したらこの callback_id を使って SendDurableExecutionCallbackFailure API を送信 return { "order_id": order_id, "callback_id": callback_id, "status": "sent_for_approval" } @durable_step def process_order(step_context: StepContext, order_id: str) -> dict: """Processes the order with retry logic for transient failures.""" step_context.logger.info(f"Processing order: {order_id}") # 時々失敗する不安定な API をシミュレート if random.random() > 0.4: step_context.logger.info("Processing failed, will retry") raise Exception("Processing failed") return { "order_id": order_id, "status": "processed", "timestamp": "2025-11-27T10:00:00Z", } @durable_execution def lambda_handler(event: dict, context: DurableContext) -> dict: try: order_id = event.get("order_id") # ステップ 1: 注文を検証 validated = context.step(validate_order(order_id)) if validated["status"] != "validated": raise Exception("Validation failed") # ターミナルエラー - 実行を停止 context.logger.info(f"Order validated: {validated}") # ステップ 2: コールバックを作成 callback = context.create_callback( name="awaiting-approval", config=CallbackConfig(timeout=Duration.from_minutes(3)) ) context.logger.info(f"Created callback with id: {callback.callback_id}") # ステップ 3: callback_id を使用して承認リクエストを送信 approval_request = context.step(send_for_approval(callback.callback_id, order_id)) context.logger.info(f"Approval request sent: {approval_request}") # ステップ 4: コールバックの結果を待つ # これは、外部システムが SendDurableExecutionCallbackSuccess または SendDurableExecutionCallbackFailure を呼び出すまでブロックされる approval_result = callback.result() context.logger.info(f"Approval received: {approval_result}") # ステップ 5: カスタム再試行戦略による注文を処理 retry_config = RetryStrategyConfig(max_attempts=3, backoff_rate=2.0) processed = context.step( process_order(order_id), config=StepConfig(retry_strategy=create_retry_strategy(retry_config)), ) if processed["status"] != "processed": raise Exception("Processing failed") # ターミナルエラー context.logger.info(f"Order successfully processed: {processed}") return processed except Exception as error: context.logger.error(f"Error processing order: {error}") raise error # 再発生して実行を失敗させる このコードは、いくつかの重要な概念を示しています。 エラー処理 — try-catch ブロックはターミナルエラーを処理します。未処理の例外がステップの外に投げられた場合 (検証チェックなど)、実行はすぐに終了します。これは、注文データが無効であるなど、再試行しても意味がない場合に役立ちます。 ステップ再試行 — process_order ステップ内では、例外によってデフォルト (ステップ 1) または設定された RetryStrategy (ステップ 5) に基づいて自動再試行がトリガーされます。これにより、一時的な API が使用できなくなるなどの一時的な障害が処理されます。 ログ記録 — メインハンドラーには context.logger を使用し、ステップ内では step_context.logger を使用します。コンテキストロガーは再生中の重複ログを抑制します。 次に、 order_id を使用してテストイベントを作成し、関数を非同期で呼び出して注文ワークフローを開始します。 [テスト] タブに移動し、オプションの 耐久性のある実行名 を入力して、この実行を識別します。なお、耐久性のある関数にはべき等性が組み込まれています。同じ実行名で関数を 2 回呼び出すと、2 回目の呼び出しでは複製を作成せずに既存の実行結果が返されます。 Lambda コンソールの [Durable 実行] タブに移動すると、実行状況をモニタリングできます。 ここでは、各ステップのステータスとタイミングを確認できます。実行すると、 CallbackStarted の後に InvocationCompleted と表示されます。これは、承認コールバックを待っている間にアイドル料金が発生しないように、関数が終了し、実行が一時停止されたことを示します。 これで、コンソールから [送信成功] または [送信失敗] を選択するか、プログラムで Lambda API を使用してコールバックを完了できるようになりました。 [送信成功] を選択します。 コールバックが完了すると、実行が再開され、注文が処理されます。シミュレートされた不安定な API が原因で process_order ステップが失敗すると、設定した戦略に基づいて自動的に再試行されます。すべての再試行が成功すると、実行は正常に完了します。 Amazon EventBridge による実行のモニタリング Amazon EventBridge を使用して永続的な関数の実行をモニタリングすることもできます。Lambda は実行ステータス変更イベントをデフォルトのイベントバスに自動的に送信するため、ダウンストリームのワークフローを構築したり、通知を送信したり、他の AWS サービスと統合したりできます。 これらのイベントを受信するには、デフォルトのイベントバスで次のパターンを使用して EventBridge ルールを作成します。 { "source": ["aws.lambda"], "detail-type": ["Durable Execution Status Change"] } 知っておくべきこと 留意点は以下のとおりです。 可用性 — Lambda 高耐久関数が米国東部 (オハイオ) AWS リージョンで利用できるようになりました。最新のリージョンの可用性については、 AWS Capabilities by Region ページをご覧ください。 プログラミング言語サポート — 起動時、AWS Lambda 高耐久関数は JavaScript/TypeScript (Node.js 22/24) と Python (3.13/3.14) をサポートしています。お好みのパッケージマネージャーを使用して、耐久性のある実行 SDK を関数コードにバンドルすることをお勧めします。SDK は動きが速いため、新機能が利用可能になったときに依存関係を簡単に更新できます。 Lambda バージョンの使用 — 耐久性のある関数を本番稼働環境にデプロイする場合は、Lambda バージョンを使用して、常に同じコードバージョンで再生が行われるようにしてください。実行が中断されている間に関数コードを更新すると、リプレイでは実行を開始したバージョンが使用されるため、長時間実行されるワークフローでのコード変更による不整合を防ぐことができます。 耐久性のある関数のテスト — より複雑な統合テストには、pytest 統合を備えた個別のテスト SDK と AWS サーバーレスアプリケーションモデル (AWS SAM) のコマンドラインインターフェイス (CLI) を使用して、AWS 認証情報なしで耐久性のある関数をローカルでテストできます。 オープンソース SDK —高耐久性 SDK は、 JavaScript/TypeScript および Python 向けのオープンソースです。ソースコードを確認したり、改善に貢献したり、最新の機能について最新情報を入手したりできます。 料金 — AWS Lambda 高耐久関数の料金の詳細については、 AWS Lambda の料金表 ページを参照してください。 AWS Lambda コンソール にアクセスして、AWS Lambda 高耐久関数を使い始めます。詳細については、 AWS Lambda 高耐久関数 のドキュメントページを参照してください。 構築がうまくいきますように! –  Donnie 原文は こちら です。

組織は、生成 AI の使用をビジネスのあらゆる部分で急速に拡大しています。深い専門知識や特定のビジネスコンテキストを必要とするアプリケーションには、独自の知識、ワークフロー、独自の要件を真に理解したモデルが必要です。 プロンプトエンジニアリング や 検索拡張生成 (RAG) などの手法は多くのユースケースでうまく機能しますが、モデルの核となる理解に専門知識を組み込むことに関しては基本的な制限があります。教師ありファインチューニングと強化学習はモデルのカスタマイズに役立ちますが、開発ライフサイクルの後半になってしまい、十分にトレーニングされたモデルの上に修正が重ねられるため、特定の関心領域への誘導が困難になります。 組織が所有データのみを使用して 継続的な事前トレーニング (CPT) を通じてより深いカスタマイズを試みると、モデルが新しいコンテンツを学習する過程で基本的な機能が失われるという、破滅的忘却に陥ることがよくあります。同時に、モデルをゼロからトレーニングするのに必要なデータ、コンピューティング、コストは、ほとんどの組織にとって依然として大きな障壁となっています。 2025 年 12 月 2 日は、Nova を使用して独自のフロンティアモデルを構築するための新しいサービス、 Amazon Nova Forge をご紹介します。Nova Forge のお客様は、初期のモデルチェックポイントから開発を開始し、データセットを Amazon Nova が収集したトレーニングデータとブレンドし、カスタムモデルを AWS で安全にホストできます。Nova Forge は、独自のフロンティアモデルを構築するための最も簡単で費用対効果の高い方法です。 ユースケースとアプリケーション Nova Forge は、独自のデータや業界固有のデータにアクセスでき、自社の領域を真に理解する AI を構築したい組織向けに設計されています。これには以下が含まれます。 製造と自動化 — 特殊なプロセス、機器データ、業界固有のワークフローを理解するモデルの構築 研究開発 — 独自の研究データとドメイン固有の知識に基づいてトレーニングされたモデルの作成 コンテンツとメディア — ブランドボイス、コンテンツ基準、特定のモデレーション要件を理解するモデルの開発 専門業界 — 業界固有の用語、規制、ベストプラクティスに関するトレーニングモデル 特定のユースケースによっては、Nova Forge を使用して差別化された機能の追加、タスク固有の精度の向上、コストの削減、レイテンシの削減を行うことができます。 Nova Forge の仕組み Nova Forge は、トレーニング前、トレーニング中、トレーニング後の各フェーズにわたる初期のチェックポイントからモデル開発を開始できるようにすることで、現在のカスタマイズアプローチの制限に対処します。 Amazon SageMaker AI の完全マネージド型インフラストラクチャで実証済みのレシピを使用してトレーニングを実施することで、すべてのトレーニングフェーズで所有データを Amazon Nova が収集したデータと組み合わせることができます。このデータミキシングアプローチは、生データのみを使ったトレーニングと比較して、破滅的忘却を大幅に減らし、専門知識を取り入れながら、コアインテリジェンス、一般的な指示に従う能力、安全上の利点などの基礎スキルを維持するのに役立ちます。 Nova Forge では、独自の環境で報酬関数を使用して 強化学習 (RL) を行うことができます。これにより、モデルはユースケースを代表する環境で生成されたフィードバックから学習できます。単一ステップの評価だけでなく、独自のオーケストレーターを使用してマルチターンのロールアウトを管理することもできます。これにより、複雑なエージェントワークフローや一連の意思決定タスクのための RL トレーニングが可能になります。化学ツールを使用して分子設計を採点する場合でも、効率的にタスクを完了して衝突を罰するロボットシミュレーションを使用する場合でも、独自の環境を直接接続できます。 また、Nova Forge に組み込まれている責任ある AI ツールキットを活用して、モデルの安全性とコンテンツモデレーションの設定を構成することもできます。安全、セキュリティ、機密コンテンツの処理など、特定のビジネスニーズに合わせて設定を調整できます。 Nova Forge の使用開始 Nova Forge は既存の AWS ワークフローとシームレスに統合されます。Amazon SageMaker AI の使い慣れたツールとインフラストラクチャを使用してトレーニングを実行し、カスタム Nova モデルをプライベートモデルとして Amazon Bedrock にインポートできます。これにより、Amazon Bedrock の他のモデルと同じセキュリティ、一貫性のある API、幅広い AWS 統合が可能になります。 Amazon SageMaker Studio では、Amazon Nova を使用してフロンティアモデルを構築できるようになりました。 モデルの構築を開始するには、使用するチェックポイント (事前トレーニング済み、中間トレーニング済み、トレーニング後チェックポイント) を選択します。ここにデータセットをアップロードするか、既存のデータセットを使用することもできます。 Nova が提供する厳選されたデータセットを組み合わせることで、トレーニングデータをブレンドできます。これらのデータセットはドメイン別に分類されているため、モデルが一般的なパフォーマンスを維持し、オーバーフィットや破滅的忘却を防ぐのに役立ちます。 オプションで、強化ファインチューニング (RFT) を使用して事実の正確性を高め、特定の領域でのハルシネーションを減らすこともできます。 トレーニングが完了したら、モデルを Amazon Bedrock にインポートして、アプリケーションで使用を開始します。 知っておくべきこと Amazon Nova Forge は米国東部 (バージニア北部) AWS リージョン でご利用いただけます。このプログラムには、複数の Nova モデルチェックポイントへのアクセス、所有データと Amazon Nova が収集したトレーニングデータを組み合わせるトレーニングレシピ、実証済みのトレーニングレシピ、Amazon SageMaker AI と Amazon Bedrock との統合が含まれます。 詳細については「 Amazon Nova ユーザーガイド 」をご覧ください。また、 Amazon SageMaker AI コンソール から Nova Forge を試してみてください。 専門家による支援を希望する組織は、 生成 AI イノベーションセンター に連絡し、モデル開発イニシアチブに関する追加サポートを受けることもできます。 – Danilo 原文は こちら です。

2025 年 12 月 2 日、 ストレージのパフォーマンスと使用パターンをより深く理解できる Amazon S3 ストレージレンズ の 3 つの新機能を発表しました。パフォーマンスメトリクスの追加、数十億のプレフィックスの分析のサポート、 Amazon S3 Tables への直接エクスポートにより、アプリケーションパフォーマンスの最適化、コストの削減、Amazon S3 ストレージ戦略に関するデータ主導の意思決定に必要なツールが手に入ります。 新しいパフォーマンスメトリクスカテゴリー S3 ストレージレンズには、組織全体のパフォーマンス制約の特定と解決に役立つ 8 つの新しいパフォーマンスメトリクスカテゴリーが追加されました。これらは組織、アカウント、バケット、プレフィックスレベルで利用できます。たとえば、このサービスは、アプリケーションのパフォーマンスを低下させる可能性のあるバケットまたはプレフィックス内の小さなオブジェクトを識別するのに役立ちます。これは、 Amazon S3 Express One Zone ストレージクラスを使用してスモールオブジェクトワークロードのパフォーマンスを向上させるためにスモールオブジェクトをバッチ処理することで軽減できます。 新しいパフォーマンスメトリクスにアクセスするには、新しいストレージレンズダッシュボードを作成するとき、または既存の設定を編集するときに、S3 ストレージレンズアドバンストティアのパフォーマンスメトリクスを有効にする必要があります。 メトリクスカテゴリー 詳細 ユースケース 緩和策 読み取りリクエストサイズ 読み取りリクエストサイズ (GET) の日別分布 パフォーマンスを低下させる小さな読み取りリクエストパターンを持つデータセットを特定 小規模なリクエスト: 小さなオブジェクトをバッチ処理するか、Amazon S3 Express One Zone を使用して高性能の小さなオブジェクトワークロードにする 書き込みリクエストサイズ 書き込みリクエストのサイズ (PUT、POST、COPY、およびアップロードパート) の日別分布 パフォーマンスを低下させる小さな書き込みリクエストパターンを持つデータセットを特定 大規模なリクエスト: リクエストを並列化、MPU を使用、または AWS CRT を使用 ストレージサイズ オブジェクトタグの分布 パフォーマンスを低下させる小さなオブジェクトを持つデータセットを特定 小さなオブジェクトのサイズ: 小さなオブジェクトをまとめることを検討 同時に発生する PUT 503 エラー 同じオブジェクトに対する同時 PUT 操作による 503 の数 パフォーマンスを低下させる同時 PUT スロットリングのあるプレフィックスを特定 シングルライターの場合は、再試行の動作を変更するか、Amazon S3 Express One Zone を使用します。複数のライターの場合は、コンセンサスメカニズムを使用するか、Amazon S3 Express One Zone を使用 クロスリージョンデータ転送 リージョン内のリージョン間で転送されたバイト数と送信されたリクエスト数 地域間のデータアクセスによる潜在的なパフォーマンスとコストの低下を特定 コンピューティングを同じ AWS リージョンのデータと同じ場所に配置 ユニークオブジェクトへのアクセス 1 日あたりにアクセスされたユニークオブジェクトの数または割合 オブジェクトのごく一部が頻繁にアクセスされるデータセットを特定。これらをよりパフォーマンスの高いストレージティアに移動してパフォーマンスを向上させることができます アクティブなデータを Amazon S3 Express One Zone または他のキャッシュソリューションに移動することを検討 ファーストバイトのレイテンシー (既存の Amazon CloudWatch メトリクス) 1 バイト目のレイテンシーメトリクスの日次平均値 リクエストが完了してからレスポンスが返され始めるまでのリクエストごとの日次平均時間 合計リクエストレイテンシー (既存の Amazon CloudWatch メトリクス) 合計リクエストレイテンシーの日次平均値 最初のバイトが受信されてから最後のバイトが送信されるまでのリクエストごとの日平均経過時間 仕組み Amazon S3 コンソール で [ストレージレンズダッシュボードを作成] を選択して新しいダッシュボードを作成します。既存のダッシュボード設定を編集することもできます。次に、 ダッシュボード名 、 ステータス 、オプションの タグ を指定するなどの一般的な設定を行います。 その後、 [次へ] を選択します。 次に、 [すべてのリージョンを含める] と [すべてのバケットを含める] を選択し、含めるリージョンとバケットを指定して、ダッシュボードの範囲を定義します。 ストレージレンズダッシュボード設定で [アドバンストティア] を選択し、 [パフォーマンスメトリクス] を選択して [次へ] を選択します。 次に、追加のメトリクス集計として [プレフィックス集計] を選択し、残りの情報はデフォルトのままにしてから [次へ] を選択します。 [デフォルトメトリクスレポート] を選択し、次にバケットタイプとして [汎用バケット] を選択し、AWS アカウントの Amazon S3 バケットを [宛先バケット] として選択します。残りの情報はデフォルトのままにして、 [次へ] を選択します。 すべての情報を確認してから、 [送信] を選択してプロセスを終了します。 有効にすると、 ストレージレンズコンソール のダッシュボードに毎日のパフォーマンスメトリクスが直接表示されます。レポートを CSV 形式または Parquet 形式でアカウント内の任意のバケットにエクスポートするか、Amazon CloudWatch に公開するかを選択することもできます。パフォーマンスメトリクスは毎日集計および公開され、組織、アカウント、バケット、プレフィックスといった複数のレベルで利用できます。このドロップダウンメニューで、 [メトリクス] に同時 PUT 503 エラー率 (%)、 [日付範囲] に [過去 30 日間]、 [上位 N バケット] に 10 を選択します。 同時 PUT 503 エラー数メトリクスは、同じオブジェクトに対する同時 PUT 操作によって生成された 503 エラーの数を追跡します。スロットリングエラーはアプリケーションのパフォーマンスを低下させる可能性があります。シングルライターの場合は、再試行の動作を変更するか、Amazon S3 Express One Zone などのよりパフォーマンスの高いストレージティアを使用して、同時発生する PUT 503 エラーを軽減します。複数のライターのシナリオでは、コンセンサスメカニズムを使用して PUT 503 エラーが同時に発生しないようにするか、Amazon S3 Express One Zone などのよりパフォーマンスの高いストレージティアを使用します。 S3 バケット内のすべてのプレフィックスの完全な分析 S3 ストレージレンズは、新しい 拡大プレフィックスメトリクスレポート を通じ、S3 バケット内のすべてのプレフィックスの分析をサポートするようになりました。この機能により、サイズ閾値 1%、最大深度 10 レベルを満たすプレフィックスに分析を制限していた以前の制限がなくなりました。サイズや深さに関係なく、バケットごとに最大数十億のプレフィックスを追跡して、最も詳細なプレフィックスレベルで分析できるようになりました。 拡大プレフィックスメトリクスレポートには、既存の S3 ストレージレンズメトリクスカテゴリー (ストレージ使用量、アクティビティメトリクス (転送されたリクエストとバイト数)、データ保護メトリクス、詳細なステータスコードメトリクスが含まれます。 開始方法 「 仕組み 」セクションで説明されているのと同じ手順に従って、ストレージレンズダッシュボードを作成または更新します。エクスポートオプションを選択するコンソールのステップ 4 では、新しい Expanded prefix メトリクスレポート を選択できます。その後、拡張プレフィックスメトリクスレポートを CSV または Parquet 形式でアカウントの任意の汎用バケットにエクスポートして、ストレージレンズデータを効率的にクエリできます。 知っておくと便利な情報 この機能強化は、組織がプレフィックス構造全体をきめ細かく可視化する必要があるシナリオに対応します。たとえば、マルチパートアップロードが不完全なプレフィックスを特定してコストを削減したり、暗号化とレプリケーションの要件についてプレフィックス構造全体のコンプライアンスを追跡したり、最も詳細なレベルでパフォーマンスの問題を検出したりできます。 S3 ストレージレンズメトリクスを S3 Tables にエクスポート S3 ストレージレンズメトリクスを S3 Tables に自動的にエクスポートできるようになりました。これは、Apache Iceberg サポートが組み込まれた AWS のフルマネージド機能です。この統合により、AWS が管理する S3 Tablesにメトリクスが毎日自動的に配信され、追加の処理インフラストラクチャを必要とせずにすぐにクエリを実行できます。 開始方法 まず、コンソールでステップ 5 で説明したプロセスに従い、エクスポート先を選択します。今回は、 [拡張プレフィックスメトリクスレポート] を選択します。汎用バケットに加えて、 [テーブルバケット] を選択します。 新しいストレージレンズメトリクスは AWS マネージドバケット aws-s3 の新しいテーブルにエクスポートされます。 拡張プレフィックスレポートの API 使用メトリクスを表示するには、 expanded_prefixes_activity_metrics テーブルを選択します。 Amazon S3 コンソールでテーブルをプレビューすることも、 Amazon Athena を使用してテーブルをクエリすることもできます。 知っておくと便利な情報 S3 Tables と S3 ストレージレンズの統合により、データパイプラインを必要とせずに、使い慣れた SQL ツールと Amazon Athena、 Amazon QuickSight 、 Amazon EMR 、 Amazon Redshift などの AWS 分析サービスを使用してメトリクス分析を簡素化できます。メトリクスは自動的に整理されて最適なクエリが実行されるようになり、必要に応じて保存と暗号化のオプションをカスタマイズできます。 この統合により、クロスアカウントおよびクロスリージョンの分析、カスタムダッシュボードの作成、および他の AWS サービスとのデータ相関が可能になります。たとえば、ストレージレンズメトリクスと S3 メタデータを組み合わせて、プレフィックスレベルのアクティビティパターンを分析し、低コストのストレージティアへの移行に適格なコールドデータを含むプレフィックス内のオブジェクトを特定できます。 エージェンティック AI ワークフローでは、自然言語を使用して S3 Tables MCP サーバー で S3 Tablesの S3 ストレージレンズメトリクスをクエリできます。エージェントは、「先月最も増加したバケットはどれか」などの質問をすることができます。または「ストレージクラス別のストレージコストを見せて」と、オブザーバビリティデータから即座にインサイトを得ることができます。 今すぐご利用いただけます 3 つの拡張機能はすべて、S3 ストレージレンズが現在提供されているすべての AWS リージョン (中国リージョンと AWS GovCloud (米国) を除く) で利用できます。 これらの機能は Amazon S3 ストレージレンズアドバンスドティアに含まれており、標準アドバンストティアの価格を超える追加料金はありません。S3 Tables のエクスポートでは、S3 Tables のストレージ、メンテナンス、クエリに対してのみお支払いいただきます。エクスポート機能自体に追加料金はかかりません。 Amazon S3 ストレージレンズのパフォーマンスメトリクス、数十億のプレフィックスのサポート、S3 Tables へのエクスポートの詳細については、「 Amazon S3 ユーザーガイド 」を参照してください。料金の詳細については、 Amazon S3 料金表ページ をご覧ください。 Veliswa Boya 。 原文は こちら です。

2025 年の初めに 、Nova Act のリサーチプレビューをリリースしました。これは、AI エージェントがユーザーインターフェイスと相互作用し、複雑なワークフローを自動化する可能性を実証したものです。開発者は Nova Act を試して、これらの自動化エージェントを本番稼働環境に導入したいと私たちに話しました。 しかし、エージェントを本番稼働環境に持ち込むには、モデルへのアクセスだけでは不十分でした。開発者は、信頼性の高い自動化を実現するために、ワークフローの調整、プロンプトの改良、適切なツールの選択、さまざまなコンポーネントの統合に多大な時間を費やしていました。課題はインテリジェンスだけではなく、信頼性、統合、本番稼働環境までのスピードでした。そこで、本番稼働環境ですぐに使えるブラウザ自動化のための完全に統合されたソリューションを構築しました。 2025 年 12 月 2 日、 Amazon Nova Act が一般公開されたことを発表しました。これは、開発者が本番稼働 UI ワークフローを自動化するための信頼性の高い AI エージェント群を構築、デプロイ、管理するのに役立つ新しい Amazon Web Services (AWS) サービスです。Nova Act は、大規模環境において 90％ 以上の信頼性を提供すると同時に、他の AI フレームワークと比較して、価値創出までの時間が最も短く、実装が容易です。 Nova Act コンソールを簡単に見てみましょう。 Nova Act は、企業規模で信頼性の高いブラウザ自動化を構築するという課題に対処します。カスタム Amazon Nova 2 Lite モデルを搭載した Nova Act は、ブラウザの操作、API 呼び出しのサポート、必要に応じた人へのエスカレーションといった点で優れています。このサービスには、ウェブ品質保証 (QA) テスト、データ入力、データ抽出、チェックアウトフローのコア機能があります。 今日のほとんどのモデルは、タスクを実行するオーケストレーターやアクチュエーターとは別に個別にトレーニングされているため、信頼性が低下します。Nova Act は、エージェントが現実世界の UI をシミュレートするカスタム合成環境 (「ウェブジム」) 内で動作する一方で、強化学習を使用することでこれに対するアプローチが異なります。モデル、オーケストレーター、ツール、SDK をすべて一緒にトレーニングして垂直統合することで、大規模環境でも高い完成率を実現できます。その結果、時折機能するだけでなく、変化に対処するための推論と適応性を備えた、大規模でも信頼できるエージェンティックなシステムが生まれました。 FortiCNP の使用開始 Nova Act は、プロトタイプから本番稼働まで数時間で完了する統合開発エクスペリエンスを提供します。次に、その工程を示します。 プレイグラウンドから始める まず、 nova.amazon.com/act にアクセスして Nova Act Playground にアクセスします。そこでは、Nova Act をすばやく実験し、実際の動作を確認できます。 これらのテストには、Nova Act エージェントのテスト用に設計されたシミュレートされたブラウザ環境である Nova Act Gym を使用します。 架空の旅行予約ウェブサイト を使って、地球型太陽系外惑星に行きます。 ここでは、コードを記述しなくても、自然言語コマンドを使用してワークフローのプロトタイプをすばやく作成できます。自動化する URL を入力し、Nova Act が実行する必要のあるアクションについて説明します。 [アクションを追加] を選択すると、さらにアクションを追加できます。 アクションを定義したら、ライブブラウザセッションで Nova Act エージェントを実行します。これにより、自動化アプローチが期待どおりに機能することを検証できます。 ワークフローを検証したら、それをエクスポートして、 Visual Studio Code (VS Code) 、 Kiro 、 Cursor などの 統合開発環境 (IDE) で開発を続けることができます。 IDE で絞り込む この段階では、サポートされている IDE で自動化を改良する必要があります。Kiro を使用し、 Nova Act 拡張機能プラグインをインストールします。 この拡張モジュールは、各ステップを個別にテストおよびデバッグできるノートブックスタイルのビルダーモードを提供します。ライブブラウザビューにはエージェントが何をしているかが正確に表示され、実行ログにはモデルの理由とアクションが表示されます。これにより、ワークフローの改善とエッジケースの処理が簡単になります。 IDE で Nova Act 拡張機能を使用する方法については、 AWS ニュースブログの「Nova Act IDE 拡張機能で AI エージェント開発を加速」 を参照してください。Nova Act 拡張機能には、一般的なワークフローパターンをすばやく使い始めるのに役立つテンプレートが含まれています。 今回のリリースでは、Nova Act IDE 拡張機能に、認証、ビルダーモード、デプロイ、実行ワークフロー専用のタブが導入され、開発ライフサイクル全体が IDE に取り込まれます。この拡張機能は本番稼働環境への最も簡単な方法ですが、開発者は Nova Act コマンドラインインターフェイス (CLI) または SDK を直接使用して、より高度なデプロイ設定を行うこともできます。 AWS にデプロイ ワークフローの本番稼働環境が整ったら、 [デプロイ] タブに移動して AWS に直接デプロイします。ワークフロー定義名 (スクリプト内の名前と一致する必要があります) を入力し、 AWS リージョン を選択し、オプションで既存の AWS Identity and Access Management (IAM) ロールの Amazon リソースネーム (ARN) を指定します。この拡張機能は、ワークフローを Docker コンテナにパッケージ化し、 Amazon Elastic Container Registry (Amazon ECR) にプッシュし、必要な IAM ロールと Amazon Simple Storage Service (Amazon S3) バケットを作成し、それを Amazon Bedrock AgentCore Runtime にデプロイします。 デプロイ後は、Nova Act コンソールでワークフローの実行をモニタリングできます。 [ワークフロー定義] に移動します。コンソールにはオブザーバビリティダッシュボードがあり、ワークフローに人間の入力が必要な場合、スーパーバイザーが介入するように通知するカスタムダッシュボードを設定します。 次に、ワークフロー定義を選択するには、下にスクロールして、実行されたワークフローを探します。 ここでは、ワークフローの実行に関する詳細情報を確認できます。 ここから、ワークフローの進行状況と実行ログを追跡します。各ステップには、エージェントの理由、アクション、ブラウザのスクリーンショットが表示されます。IDE で開発していたときと同じレベルの可視性で、本番稼働環境の実行を大規模にモニタリングできるようになりました。 実験から本番稼働環境へのこの簡単な移行により、異なるツールやオーケストレーションロジックをつなぎ合わせるのに通常何週間も費やす必要がなくなります。 組み合わせるとより強力: Nova Act と Strands Agents エージェントシステムが成熟するにつれ、専門のエージェントがシームレスに連携する必要性が不可欠になります。Nova Act は Strands Agents フレームワークと自然に統合されるため、カスタム統合作業なしで包括的なマルチエージェントワークフローを構築できます。Strands はドメイン間のエージェントシステムを調整するためのオーケストレーション層を提供し、Nova Act はブラウザ主体の UI 自動化に特化した信頼性を提供します。このようなすぐに使用できる互換性は、現代のエージェントアーキテクチャ、つまり複雑なビジネス上の問題を解決するために統合される専用コンポーネントがどのように機能すべきかを反映しています。 開発者は Strands を使用して複雑なワークフローを調整できます。Nova Act はブラウザ自動化コンポーネントを特殊なツールとして扱い、それらを他のエージェントと組み合わせます。チームはこのアーキテクチャを使用して、Strands によってオーケストレーションされたより広範なエージェントエコシステム内で、Nova Act 専用の UI 自動化機能を活用できます。 知っておくべきこと 留意点は以下のとおりです。 統合 — Strands Agents フレームワークと連携して、ドメイン全体で複雑なマルチエージェントワークフローを構築します。 料金 — 詳細については、 Amazon Nova Act の料金表ページ をご覧ください。 Nova Act と責任ある AI — Nova Actには、 責任ある AI の使用を促進するための安全管理機能とコンテンツモデレーション機能が組み込まれており、推論の進歩、エージェントの安全性、敵対的攻撃に対する堅牢性を組み込んでいます。 可用性 — Amazon Nova Act が米国東部 (バージニア北部) AWS リージョンで利用できるようになりました。最新のリージョンの可用性については、 AWS Capabilities by Region ページをご覧ください。 Nova Act を使い始めるには、 nova.amazon.com/act にアクセスし、API キーを入手してプレイグラウンドを探索します。 ハッピーオートメーション! — Danilo & Donnie 原文は こちら です。

2025 年 12 月 2 日、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンスと Amazon Elastic Container Service (Amazon ECS) タスクの 2 つの攻撃シーケンス検出結果を追加した、 Amazon GuardDuty Extended Threat Detection の新しい拡張機能を発表しました。これらの新しい検出結果は、既存の Extended Threat Detection 機能に基づいており、 AWS Identity and Access Management (IAM) の認証情報の悪用、異常な Amazon Simple Storage Service (Amazon S3) バケットアクティビティ、 Amazon Elastic Kubernetes Service (Amazon EKS) クラスター侵害などのシーケンスをすでに組み合わせています。今回の発表では、EC2 インスタンスグループと ECS クラスターの対象範囲を追加することで、同じアプリケーションをサポートする仮想マシンとコンテナ環境へのシーケンスレベルの可視性が拡大されます。これらの機能を組み合わせることで、さまざまな Amazon Web Services (AWS) ワークロードにわたる多段階のアクティビティをより一貫性のある統一された方法で検出できます。 現代のクラウド環境は動的で分散されており、多くの場合、仮想マシン、コンテナ、サーバーレスワークロードを大規模に実行しています。セキュリティチームは、これらの環境全体の可視性を維持し、複雑で多段階の攻撃シーケンスを示す可能性のある関連アクティビティを結び付けるよう努めています。これらのシーケンスには、初期アクセスと永続性の確立、不足している認証情報の提供、予期しないデータアクセスの実行など、複数のステップが含まれる場合があります。これらのステップは、時間の経過とともに、さまざまなソースにわたって展開されます。GuardDuty Extended Threat Detection は、AWS 規模でトレーニングされた AI と 機械学習 (ML) モデルを使用してこれらのシグナルを自動的にリンクし、アクティビティの全体像を構築し、顧客が対応アクションの優先順位を決めるのに役立つ信頼性の高いインサイトを提示します。この分析では、さまざまな情報源からのエビデンスを組み合わせることにより、個々の事象から推測するのが困難な、忠実度の高い統一された検出結果が得られます。 仕組み Extended Threat Detection は、ランタイムアクティビティ、マルウェア検出、 VPC フローログ 、DNS クエリ、 AWS CloudTrail イベントなど、複数のタイプのセキュリティシグナルを分析して、Amazon EC2 および Amazon ECS ワークロードにわたる多段階攻撃のパターンを特定します。検出は GuardDuty 基本プラン と連携します。EC2 または ECS の ランタイムモニタリング を有効にすると、プロセスやネットワークレベルのテレメトリが深まり、シグナル分析が強化され、各攻撃シーケンスの完全性が向上します。 新しい攻撃シーケンスの検出結果は、ランタイムと環境全体で観察されたその他の動作を 1 つのクリティカルな重大度シーケンスにまとめたものです。各シーケンスには、インシデントの概要、観察されたイベントのタイムライン、マッピングされた MITRE ATT&CK® の戦術とテクニック、およびアクティビティがどのように展開され、どのリソースが影響を受けたかを理解するのに役立つ修復ガイダンスが含まれています。 EC2 インスタンスと ECS タスクは多くの場合、Auto Scaling グループ、共有起動テンプレート、 Amazon マシンイメージ (AMI) 、IAM インスタンスプロファイル、またはクラスターレベルのデプロイによって自動的に作成および置き換えられます。これらのリソースは通常、同じアプリケーションの一部として動作するため、リソース全体で見られるアクティビティは、1 つの根本的なセキュリティ侵害が原因である可能性があります。EC2 と ECS の新しい検出結果は、これらの共有属性を分析し、GuardDuty がグループに影響を及ぼすパターンを検出すると、関連するシグナルを 1 つのシーケンスに統合します。 シーケンスが検出されると、 GuardDuty コンソール は、該当する EC2 インスタンスグループまたは ECS クラスターがすでに特定されている状態で、重大度が高いシーケンスの検出結果を [概要] ページに強調表示します。検出結果を選択すると、リソースがどのように接続されているか、シーケンスに寄与したシグナル、アクティビティの経時的な進行状況を示す統合ビューが開き、仮想マシンとコンテナのワークロード全体にわたる影響範囲をすばやく把握できます。 コンソールでシーケンスを表示できるだけでなく、これらの結果は AWS Security Hub でも確認できます。新しい公開ダッシュボードには、他の GuardDuty 検出結果と一緒に表示されるため、全体的なセキュリティリスクを 1 か所で把握するのに役立ちます。この詳細なビューにより、分析によって関連するシグナルがどのようにしてより広範な攻撃シーケンスにまとめられるかを解釈するためのコンテキストが確立されます。 分析モデルとグルーピングロジックを組み合わせることで、仮想マシンとコンテナのワークロード全体のアクティビティをより明確かつ統合的に把握できるため、多数の検出結果を個別に調査する代わりに、重要なイベントに集中できます。Extended Threat Detection は、関連する行動を 1 つのシーケンスに統合することで、攻撃経路の全容を評価し、最も緊急な修復アクションに優先順位を付けるのに役立ちます。 今すぐご利用いただけます EC2 インスタンスと ECS タスクの対象範囲が拡大された Amazon GuardDuty Extended Threat Detection を、GuardDuty が提供されているすべての AWS リージョン で利用できるようになりました。今すぐこの機能を使用して、ランタイムアクティビティ、マルウェア実行、AWS API アクティビティからのシグナルを組み合わせることで、仮想マシンとコンテナのワークロード全体にわたる協調的な多段階アクティビティを検出できます。 この拡張により、Amazon EKS の既存の Extended Threat Detection 機能が補完され、AWS コンピューティング環境全体で調整された多段階のアクティビティを一元的に可視化できるようになります。詳細については、 Amazon GuardDuty 製品ページ にアクセスしてください。 – Betty 原文は こちら です。

本ブログは 2025 年 11 月 10 日に公開された AWS Public Sector ブログ「 Accelerating CMMC readiness: How AWS and Wiz help public sector organizations 」を翻訳したものです。 米国政府のコントラクターおよびサブコントラクターにとって、 Cybersecurity Maturity Model Certification (CMMC) の取得は片手間にこなせる仕事ではありません。この認証の取得にはリスクが伴い、要件は複雑です。国防総省 (DoD)（別名、戦争省）が新規契約および既存契約に CMMC を段階的に導入するなか、正しく対応しなければならないというプレッシャーは高まり続けています。そのため、チームや予算に過度な負担をかけることなく、CMMC 評価に備えて環境を調査する効率的でスケーラブルな方法がより強く求められています。 Amazon Web Services (AWS) と Wiz は、契約で定義された Controlled Unclassified Information (CUI) の所在を発見し、認証境界を適切なサイズに設定し、自信を持ってコンプライアンスを実証するために必要な証拠を収集することで、コントラクターがより迅速に明確性を得られるよう支援します。AWS と Wiz はこれらのプロセスを自動化することで、組織が管理リソースや組織リソースへの負担を軽減しながら、CMMC 対応準備状況を迅速に評価できるよう支援します。 2024 年 10 月 15 日に公開された CMMC 最終規則 32 CFR Part 170 は、CMMC コンプライアンスを 3 つのレベルに分類しており、レベル 1 と一部のレベル 2 コンプライアンスには自己評価で十分、一部のレベル 2 とすべてのレベル 3 にはCMMC サードパーティ評価機関 (C3PAO) による評価が必要です。Wiz と AWS は、CMMC に必要な技術インフラストラクチャとセキュリティコントロールの多くを提供し、組織が CMMC 評価を開始する前にセキュリティギャップの可能性がある箇所をより迅速に評価できるよう支援します。 次の表は、3 つのレベルのスコープ、要件、評価アプローチの概要を示しています。 図 1: Wiz と AWS は、CMMC レベル 1～3 に必要なさまざまな技術的コントロールのサポートと測定を組織が行えるよう支援します CMMC が大きな負担である理由 国家を後ろ盾とする脅威アクターが防衛産業基盤 (DIB) を標的にし続ける中、CMMC フレームワークは非連邦システムにおける CUI を保護するために不可欠なものとなっています。DoD は現在、防衛関連業務に携わろうとするコントラクターにとって CMMC を必須かつ強制力のあるものと考えています。 しかし、多くの組織はまだ基本的な質問を投げかけています。 どのシステムが CUI を含むまたは処理しているのか？ 認証境界に何が含まれるのか？ コンプライアンスを確保しながら、過剰な監査をどのように避けられるのか？ これらの不明点が共通の課題につながります。 環境の盲点 が評価のスコーピングを複雑にします。 過剰な監査 はコスト増加と無駄な労力を招きます。 チームが適切な成果物を提示できないと 監査の遅延 が発生します。 CUI データフローのマッピング は根拠のない推測作業になります。 従来の技術や手動の方法論に頼ると、CMMC コンプライアンスに必要な裏付け証拠を収集することは非常に困難になる可能性があります。例えば、現役軍人に高度な医療ケアを提供するために CUI 指定の患者データを扱う大規模な医療グループは、CUI がどこに存在し、どのシステムが相互接続されているかを分類するのに 2 年を費やしたと報告しています。この取り組みは、可視性の欠如、 シャドー IT 、クラウド環境におけるワークロードの分散所有権のために困難でした。Wiz は、これらのプロセスの多くを自動化し、手動の労働時間を必要とせずにシャドー IT を発見するのに役立ちます。自動化と可視性により、評価中に必要なデータの手動収集と関連付けを大幅に削減することで、CMMC 認証準備に必要な管理作業を大幅に削減できます。 Wiz と AWS の力 Wiz は、組織に AWS クラウド環境への完全な可視性を提供するクラウドセキュリティプラットフォームです。Wiz を AWS に接続すると、Wiz はパブリックセクターチームがリソース（CUI データが存在する場所を含む）の検出を自動化し、コンテキストに基づいてリスクを評価し、自己評価とサードパーティ監査の負担を軽減するために、防御可能な方法でセキュリティ体制を証明するのに役立ちます。 エージェントなしで数分で AWS 環境に接続することで、Wiz は次のことを特定できます。 どのリソースが CUI を含むまたは CUI に接続しているか どのアイデンティティが何にどこからアクセスできるか どの脆弱性または設定ミスがセキュリティに影響を与えるか AWS 内にデプロイされているリソース、それらのリソースの接続方法、どのアイデンティティがアクセス権を持っているかに関するコンテキストを含む完全な可視性を持つことは、CMMC レベル 2 と 3 の重要な要素であり、Wiz ではすぐに利用できます。AWS GovCloud (US) のセキュリティ機能と組み合わせることで、組織はミッションを遅らせることなく、コンプライアンスのための安全でスケーラブルな基盤を構築できます。 AWS GovCloud (US) は、テクノロジーリーダーが機密データや CUI データをホストするために信頼する革新的なコンプライアント対応クラウドソリューションです。これは、物理的および論理的に分離された 2 つの米国主権 リージョン 、AWS GovCloud (米国東部) と AWS GovCloud (米国西部) で構成されており、米国内で米国市民によって運用されています。政府機関のお客様、テクノロジーパートナー、および高度に規制されたエンタープライズクラウド要件を持つ組織は、 AWS GovCloud (US) のコンプライアンスプログラム と機能を使用して、ワークロードを保護し、運用許可 (ATO) を取得する能力を加速しています。 AWS GovCloud (US) は、連邦、州、地方レベルの米国政府機関、クラウドで機密ワークロードを実行するコントラクター、教育機関、その他の米国のお客様の特定の規制およびコンプライアンス要件に対応するように設計されています。すべての AWS リージョンに適用される保証プログラムに加えて、AWS GovCloud (US) リージョンは、お客様が米国武器国際取引規則 (ITAR)、 Federal Risk and Authorization Management Program (FedRAMP) 、および DoD Cloud Computing Security Requirements Guide (SRG) Impact Levels 2、4、5 に準拠できるように設計されています。AWS GovCloud (US) がサポートする米国のコンプライアンス基準の完全なリストについては、 AWS Compliance をご覧ください。 自信を持って CMMC 評価に臨む AWS と Wiz が組織と緊密に連携して CMMC 監査プロセスを合理化し、本番環境への移行時間を短縮し、イノベーションを促進する方法を以下に示します。 CUI データフローを理解する Wiz は、 Data Security Posture Management (DSPM) 内のカスタムデータ分類ルールを通じて、CUI がどこに存在するかを理解するという一般的な課題にチームが対処できるよう支援します。これらのルールは、防衛契約、作業記述書 (SOW)、業績作業記述書 (Performance Work Statements) 内で定義された CUI を検索するために使用できます。クラウド環境内で CUI が存在する場所を特定することで、組織はこれらのデータに対する適切な保護が実施されていることをより簡単に確認できます。 組織は、防衛契約で定義されているように、CUI が Basic か Specified かを追跡する必要があります。この区別は重要です。なぜなら、CUI Specified には、ITAR によって義務付けられているようなより厳格な法的要件が伴うことが多く、AWS GovCloud (US) や Wiz for Gov などの特殊な環境で見られる強化された保護が必要になるためです。 次のスクリーンショットは、Data Findings ダッシュボードを示しています。 図 2: Wiz は、統合された DSPM 機能を通じてデータ検出を自動化し、データが存在する場所を特定し、検出されたセキュリティリスクの修復に優先順位を付けるのに役立ちます CUI の検出と、どのシステムとリソースが相互接続されているかを自動化することで、組織は CUI Specified データに対する高度なセキュリティ要求とコンプライアンスを満たしているかどうかをより簡単に評価できます。 CMMC のスコープを最適化する AWS クラウド環境全体を認証しようとすることは、単に高額であるだけでなく、多くの場合不要です。適切な可視性があれば、組織は CMMC に必要なものだけを含む明確で防御可能な境界を定義できます。 境界を適切なサイズに設定するには、エンジニアリング、コンプライアンス、法務チーム間のパートナーシップが必要です。これは圧倒的に思えるかもしれませんが、CUI が存在する場所、どのリソースとアイデンティティが接続できるか、これらのシステムが外部にどのように公開されているかの検出を自動化することで、境界を設定できます。 Wiz は、このプロセスを加速するための可視性を提供します。組織の AWS インフラストラクチャ全体にわたるコンテキストに富んだインサイトにより、次のことが可能になります。 CMMC 環境のスコープを適切に定義する どのアイデンティティとリソースが CUI にアクセスできるかを明確に示す 無関係なリソースの監査にかかる時間とコストを回避する このバランス（セキュリティと俊敏性）は、厳しい予算とスケジュールで作業する政府のコントラクターとサブコントラクターにとって不可欠です。次のベン図は、最小限の境界を持つ厳密なスコープと、すべてを囲む境界を持つフルスコープの交差を示しています。厳密なスコープとフルスコープの重なりを示す中央の領域には、CUI と関連システムの周囲に CMMC 評価境界を配置することの利点がいくつか記載されています。 図 3: CMMC 評価のスコープに何を含めるべきかを決定することは、監査のコストと期間、およびスコープとサービスを拡大する柔軟性に影響を与える可能性があります 包括的な監査証拠を収集する 監査人は証拠が示されることを期待します。しかし、脆弱性、設定、アクセスコントロールなどにわたって適切な成果物をまとめることは困難な場合があります。 Wiz は、AWS 環境を継続的に監視し、関連性のある検出結果を表面化させることで、このプロセスを自動化します。Wiz は、 Amazon Bedrock 、 AWS Certificate Manager (ACM) 、 AWS CloudTrail 、 AWS Key Management Service (AWS KMS) 、 AWS Lambda 、 AWS Network Firewall 、 Amazon OpenSearch Service 、 AWS Secrets Manager など、 多数の AWS のサービス を検査します。Wiz は、手動入力を必要とせず、監査要件をサポートするドキュメントを迅速に提供するために、カスタマイズ可能なレポートを生成できます。 次の画像は、検出結果、コンプライアンス、インベントリレポートを示す Wiz Cloud-Native Application Protection Platform (CNAPP) レポートユーザーインターフェイスのスクリーンショットです。各レポートカテゴリの下には、ネットワーク露出、脆弱性、データ検出結果、コンプライアンス評価、コンプライアンスのための脆弱性、データストア、クラウドリソースインベントリなど、レポートサブカテゴリのオプションがあります。 図 4: Wiz は、CMMC 監査をサポートするために必要な情報を迅速にエクスポートするための、カスタマイズ可能なオプションを備えたいくつかのすぐに使えるレポートを提供します 継続的な監視プロセス、脆弱性とリスク指標の迅速な特定、ベストプラクティスと技術的ベンチマークへの準拠、ベースラインからの逸脱が検出されたときのアラートの自動化の組み合わせはすべて、組織が NIST SP 800-171r2 へのコンプライアンスを迅速に示すのに役立ちます。DoD CMMC 最終規則 32 CFR Part 170 は、CUI データが CMMC レベル 2 (Self および C3PAO) 認証のために十分に保護されているかどうかを評価するための技術標準として NIST SP 800-171r2 を指定しています。 例として、Wiz には、多数の技術的ベンチマークに対するすぐに使える自動評価が付属しています。これには、Center for Internet Security (CIS) フレームワークと Defense Information Systems Agency (DISA) Security Technical Implementation Guides (STIGs) が含まれます。これらの自動評価は、サイバーセキュリティの脅威からシステムを保護するための強化要件を満たしているかどうかを特定するように設計されています。これにより、組織は NIST SP 800-171r2 の Configuration Management コントロールファミリー内の多くのコントロールを迅速に満たすことができます。 CMMC クラウドサービスプロバイダー (CSP) 要件を満たし、それを超えるために、AWS と Wiz はどちらも FedRAMP High 認可環境を提供しています。 Wiz for Government と AWS GovCloud (US) は、ITAR、FISMA、HIPAA、FedRAMP を含む多くの規制フレームワークを満たすか、それを超えるように構築されています。これらの FedRAMP High 認可は、これらの環境のセキュリティを証明するための追加ドキュメントを削減または免除することで、CMMC を含む監査を簡素化するのに役立ちます。 Wiz for Government が支援できる CMMC および NIST SP 800-171r2 コントロールの詳細については、Wiz for CMMC Certification データシートを参照してください。 CMMC の達成: 標準をセキュリティに変える CMMC への準備は、DoD と契約またはサブコントラクトを結ぶ多くの組織にとって、もはや任意ではありません。しかし、長く困難なプロセスである必要もありません。 AWS の堅牢な保護と Wiz の CNAPP の可視性を組み合わせることで、パブリックセクターチームはスコーピングを簡素化し、検出を加速し、自信を持って監査準備態勢に移行できます。 組織が AWS GovCloud (US) で構築している場合でも、既存の環境を拡張している場合でも、Wiz は CUI が存在する場所を特定し、セキュリティコントロールを検証し、データでコンプライアンス境界をサポートすることで、手動で生成および保守されるスプレッドシートの必要性を排除することがよくあります。 Wiz の FedRAMP High 認可が AWS のお客様のセキュリティをどのように強化するかについてお読みください 。 CMMC への取り組みを加速する準備はできていますか? 今すぐ AWS Global Security & Compliance Acceleration (GSCA) と Wiz の使用を開始する方法の詳細 をご覧ください。 著者について Varun Jasti Varun Jasti は AWS のソリューションアーキテクトであり、AWS パートナーと協力して、コンプライアンス基準を満たすパブリックセクターのユースケース向けの人工知能ソリューションを設計およびスケールしています。コンピュータサイエンスのバックグラウンドを持つ彼の業務は、主に LLM のトレーニング/推論とコンピュータビジョンに焦点を当てた幅広い ML ユースケースをカバーしています。余暇には、テニスや水泳を楽しんでいます。 Bryan Rosensteel Bryan Rosensteel は Wiz のパブリックセクタープロダクトマーケティング責任者です。彼は 20 年以上のパブリックセクターでの経験を持っています。彼は、ICAM を含む多くのサイバーセキュリティイニシアティブについて米国連邦政府に助言し、NIST 1800 シリーズの特別刊行物につながる複数の NCCoE プロジェクトに取り組み、ATARC などの非営利組織でワーキンググループの形成と運営を支援し、複数の政府 IT モダナイゼーションプロジェクトの設計と実装を支援してきました。 Greg Carpenter Greg Carpenter は AWS Global Security & Compliance Acceleration Partner Team のシニアセキュリティパートナーストラテジストであり、パートナーとお客様がセキュリティと認可のニーズを満たせるよう支援しています。これには、ツールとコントロールのアーキテクト、設定、デプロイ、統合が含まれます。キャリアを通じて、Greg はパートナーおよびお客様とのコミュニケーション、セキュリティとコンプライアンスのサポートで優れた実績を上げてきました。AWS に入社する前、Greg は CIS で 4 年間勤務し、メンバーと非メンバーが独自のサイバーセキュリティ戦略を進める際に、グローバルコミュニティ向けのクラウドサイバーセキュリティ製品と戦略に焦点を当てて支援しました。Greg は、CIS Benchmarks、CIS Controls v8 Cloud Companion Guide、および最新版の CIS Critical Security Controls にも貢献しています。クラウドに頭を悩ませていないときは、家族との時間、ハーレーに乗る時間、アイスホッケー、釣り、マウンテンバイクを楽しんでいます。 Greg Hewitt Greg Hewitt は Wiz のグローバルパブリックセクタービジネスにおける AWS GTM 戦略を主導しており、政府機関や規制産業がクラウド導入を安全に加速できるよう支援することに注力しています。Splunk と Second Front Systems でのリーダーシップの役割を経て、Greg はクラウドセキュリティと防衛モダナイゼーションにおけるイノベーションの推進の中心にいました。彼は AWS と緊密に連携して、FedRAMP、CMMC、ITAR コンプライアンスを可能にする共同ソリューションを提供しており、政府組織にとってクラウドをより安全でアクセスしやすいものにすることで、ミッションレジリエンスを向上させることに情熱を注いでいます。 このブログは WWPS Proposal Writer 中村昌幸が翻訳しました。

本稿は、日本取引所グループの SCRIPTS Asia 社による「生成 AI を活用 した決算説明会等スクリプトの自動翻訳」について、サービス開発をリードされた 松田 敬治 様、雪永 スチュアート 様、アーキテクティングと開発をリードされた 太子 智貴 様に寄稿いただきました。 イントロダクション SCRIPTS Asia は、上場企業の決算説明会や IR イベントの内容をテキスト化し、機関投資家や情報ベンダーに配信しています。従来は、日本語の書き起こしテキストから英語翻訳、成果物の品質確認までをすべて人手で対応していました。しかし、SCRIPTS Asia がカバーする上場企業の全イベントを英訳するには時間及び費用の両面で大きな課題がありました。 今回、AWS の Amazon Bedrock を活用した生成 AI 翻訳を導入し、業務全体の自動化と品質向上を実現しました。 SCRIPTS Asia 社の概要 SCRIPTS Asia は JPX 総研の子会社です。上場企業の決算説明会や IR イベントの音声をテキスト化し、話者情報などのイベント詳細をデータベース化して、機関投資家や金融機関、情報ベンダーに提供しています。併せて、イベントデータの英語翻訳も行っており、グローバル投資家の投資判断や分析に活用されています。このサービスは、単なる技術導入や機械翻訳ではなく、長年の業界知識と翻訳ノウハウを融合した独自の体制によって支えられています。さらに、人力オペレーションによるラストワンマイルの品質保証を組み込むことで、高品質な翻訳やデータ品質の両立を実現しています。 課題 イベントデータの英訳にあたり、SCRIPTS Asia が直面していた主な課題は次のとおりです。 翻訳の作業量は膨大で、コスト負担が大きい 繁忙期には翻訳作業を行う大量の人員が必要（季節要因が激しく、人員確保が困難） 会社固有の専門用語 や業界用語に対応した高い精度での翻訳が求められる ソリューション Amazon Bedrock の導入 Amazon Bedrock を活用し、日本語スクリプトの英語翻訳から成果物出力までを自動化しました。導入にあたっては、BERT や BLEU スコアなどの評価指標を用いて、従来の人手での翻訳結果を用いた精度比較を行い、最適なモデルを選定しました。 ナレッジの融合 過去の翻訳履歴や辞書、証券用語集といった形式知に加え、翻訳作業のレビューアーによるフィードバック資料等からプロダクション担当者が持つ暗黙知についても生成 AI で整理しました 。 この整理した知見をプロンプトや辞書情報等に取り込むことで、従来の SCRIPTS Asia のスタイルを維持しつつ、高品質な翻訳が実現できました。 技術的詳細 AWS サービスの活用 Amazon Bedrock ： Anthropic Claude Sonnet AWS Fargate ： Amazon Bedrock と連携した英訳処理、整形処理 Amazon EventBridge ＋ AWS Lambda ＋ Amazon SQS でクォータを超えないように 制御 Amazon DynamoDB ：過去の翻訳情報 や単語情報の保持 プロンプトエンジニアリングとチャンク分割 長文翻訳では、プロンプトの 指示が反映されにくく、数字表現の精度が低下する傾向がありました。精度向上のため、複数の生成 AI モデルを比較し、文章を細かく 1 行ずつに分割（チャンキング）して英訳することで、プロンプトの意図を正確に理解させるように工夫しました。なお、全体的な文章としての適切性を保持するために、前後の文章についても参考して読み込ませることで文意が保たれるようにしております。 コストと精度のバランス プロンプトの解釈精度向上のためにチャンク分割を実施したことにより、生成 AI への入出力回数が増大し、翻訳辞書等のナレッジを参照した翻訳に係る処理時間と費用面の課題が浮上しました。こちらは単語分割を踏まえつつ辞書情報の組み込み方式を見直すことで、プロンプトのボリュームを圧縮し、処理時間と費用を許容範囲に抑え込みました。 生成 AI を意識した効率的な運用設計 生成AIによる翻訳が難しく、誤訳リスクが高いケース（音声が不明瞭な個所があり、文として成立しない場合など）については、あえて自動翻訳を行わずにエラーとして処理を止め、人手で翻訳するフローに回しています。 こうすることで、「見た目上は訳されているものの、明らかな誤訳」をそのまま出してしまう“クリティカルエラー“を最小化し、英語読者が誤った理解をするリスクを回避しています。 このような翻訳困難ケースは全体の 1 〜 3 ％程度に収まるため、あらかじめ“止めるべき条件“として定義して、それ以外の翻訳は自動処理で回せる設計としており、Human-in-the-loop（人手チェック）を最小限に抑えつつ、必要な部分には確実に人の目を入れることで、効率と品質の両立を実現しています。 効果・成果 翻訳品質の大幅向上 SCRIPTS Asia 社の翻訳有識者による相対的な評価で、各種チューニング後の最終的な品質は 90 点以上を達成し、単純な AI の一括翻訳（ 45 ～ 50 点評価）から大幅に改善しました。この品質は、生成AIの性能だけでなく、専門知識と人力による品質保証の知見の組み合わせによって支えられています。 作業効率の改善とコスト削減 生成 AI を利用した翻訳により、人手での成果物作成と比較して、時間効率は概ね 10 倍以上、費用効率は概算で数十倍となる、プロダクションアウトプットを実現しました。 この成果により、注目度が低いイベントなど従来はコスト面の問題で英文翻訳が実施出来なかったイベントについても英文スクリプトが作成され、日本語と英語に差が無い環境を整えることができました。結果として、SCRIPTS Asia の品質を確保した英文対応のイベント数が大幅に増加することで、グローバルな投資家ニーズに更に応えられるようになりました。 今後の展望 さらなる生成AI活用の拡大 今回の成功経験を活かし、人手で実施している音声の書き起こし業務についても、生成AIの適用を検討していきます。話者情報の識別など現在の高品質と評価いただいている成果物（テキスト及びデータ構造特性）を踏まえた書き起こしという課題はありますが、この取組みにより、これまで人手不足を要因としてリーチできなかったイベントについても対応可能な範囲が増え、データ拡充を通じて世界中の市場関係者に対する新たな価値創出を目指していきます。 執筆者紹介 （松田 敬治（右）、雪永 スチュアート（左）、太子 智貴（中央）） 松田 敬治 (SCRIPTS Asia 株式会社 テクノロジー部長／(株)JPX 総研 IT ビジネス部 パブリッククラウド基盤 統括課長) 東京証券取引所に入所後、市場運営部門を経て、清算機関 (JSCC) 設立時からシステム部門に従事。清算システム構築後、SIer 出向・arrownet 担当を経て、2010 年から株式売買システム arrowhead や CONNEQTOR 等の取引インフラ基盤を開発。2024 年度より SCRIPTS Asia 社システム統括兼 JPX 総研を担当 雪永 スチュアート (株式会社 JPX 総研 フロンティア戦略部 Manager) 金融、外交、映像制作など多様な分野で経験を積む。取引所入所後は広報業務や 清算機関 (JSCC) の OTC デリバティブの海外コンプライアンスを担い、2025 年より SCRIPTS Asia 社の IT サポートおよび JPX 総研のデータサービス営業を担当 太子 智貴 (株式会社 JPX 総研 IT ビジネス部 JPX 生成 AI プロジェクト 統括課長) 取引所入所後、10年以上にわたり上場審査・市場監視などの中核業務を担い、2019 年に IT 部門へ異動。2023 年から JPX グループにおける社内・社外向けの生成 AI プロジェクトをリードし、数十件に及ぶ生成 AI 関連サービスのリリースを主導

みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 今年も熱気に包まれた re:Invent 2025 は  Dr. ワーナーの最後のキーノート と合わせて幕を閉じました。現地に行かれた方も、日本からオンラインで参加された方も、得た学びを整理している状況かなと思います。サービスアップデートの発表だけでなく、会場で行われた多くの講演がすでに 動画としてアップロード されています。ぜひ気になる講演を視聴し、新たなる気づきや技術整理にお役立てください！ それでは、先週の主なアップデートについて振り返っていきましょう。 2025年12月8日週の主要なアップデート 12/8(月) 空間データの洞察を加速させる Spatial Data Management on AWS (SDMA) の発表 AWS が空間データ管理ソリューション Spatial Data Management on AWS (SDMA) を発表しました。SDMA は空間データを大規模に保存、エンリッチ、接続することを可能にするソリューションで、CloudFormation を利用してお客様の AWS アカウントにデプロイして利用します。SDMA により、3D や地理空間データなどのマルチモーダル空間データを一元化されたセキュアなクラウド環境に保存できます。さらに、自社の空間データ、ISV SaaS アプリケーション、AWS サービス間の接続を可能にするコラボレーションハブとしても機能します。また、自動生成されるファイルプレビュー機能により、大容量ファイルをダウンロードせずにデータを表示および検証が可能です。東京リージョンを含む 9 リージョンで利用可能です。詳細は こちらをご参照ください。 Amazon Quick Suite で Quick Research と Quick Flows を統合したレポート生成の自動化 Amazon Quick Suite で Quick Research と Quick Flows が統合され、自動化ワークフローの中でリサーチレポートを生成できるようになりました。これまで手動で行っていたり Quick Research の作業を、スケジュール実行や他システム連携で自動化可能です。例えば営業チームの顧客分析レポートを定期生成し、結果を Salesforce に自動反映するといった活用が実現します。バージニア北部、オレゴン、シドニー、アイルランドリージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 12/9(火) Amazon GameLift Servers が AI を活用したサポートでゲーム開発者向け AWS コンソールを強化 Amazon GameLift Servers に Amazon Q Developer を活用した AI アシスタンス機能が追加されました。ゲーム開発者は AWS コンソール内で、サーバー統合やフリート設定、パフォーマンス最適化に関する AI による専門的なガイダンスを受けられます。従来は複雑な設定やトラブルシューティングに時間がかかっていましたが、この機能によりコスト削減とプレイヤー体験向上を同時に実現できます。詳細は こちらのドキュメントをご参照ください。 Amazon RDS と Aurora が自動バックアップのリソースタグ付けに対応 Amazon RDS と Aurora で、自動バックアップに対するリソースタギング機能が追加されました。これまで自動バックアップ機能を利用する際、親の DB インスタンスやクラスターと同一のタグが、バックアップに自動付与されていましたが、今回から独立してタグを設定できるようになりました。これにより、アプリケーション別やプロジェクト別にバックアップのアクセス制御やコスト追跡が可能となり、より細かなリソース管理が実現できます。 AWS Partner Central に案件規模の算定機能が追加 AWS Partner Central に AI を活用した deal sizing 機能が追加されました。この機能により、AWS パートナーは案件の規模見積もりや AWS サービス推奨を自動化できます。AWS Pricing Calculator の URL をインポートすることで、手動での再入力作業が不要になり、価格戦略の最適化や Migration Acceleration Program (MAP) の適格性分析なども提供されます。案件管理業務を大幅に効率化でき、プログラム申請のプロセスの迅速化にもつながります。詳細は こちらのドキュメントをご参照ください。 12/10(水) AWS Support Center Console でサポートケースのトラブルシューティング用画面共有をサポート AWS Support Center Console にスクリーン共有機能が追加されました。これまでサポートとのやり取りは電話やチャットのみでしたが、今回のアップデートでバーチャルミーティング中にスクリーンを共有できるようになりました。アクティブなチャットや通話中にワンクリックでミーティングに参加でき、画面を見せながら問題を説明できるため、より迅速で効果的なトラブルシューティングが可能になります。詳細は こちらのドキュメントをご参照ください。 Amazon EC2 C8gb インスタンスの一般提供開始 Amazon EC2 C8gb インスタンスの一般提供が開始されました。AWS Graviton4 プロセッサ搭載により、従来の Graviton3 比較で最大 30% のパフォーマンス向上を実現します。最大 150 Gbps の EBS 帯域幅を提供し、高性能ファイルシステムなどの大容量データ処理ワークロードでより高いスループットを実現できます。最大 24xlarge サイズまで対応し、192 GiB メモリと 200 Gbps ネットワーク帯域幅を提供します。現在バージニア北部リージョンとオレゴンリージョンで利用可能です。 Amazon ECS が AWS Fargate でカスタムコンテナ停止シグナルをサポート Amazon ECS が AWS Fargate でカスタムコンテナ停止シグナルに対応しました。従来は強制的に SIGTERM シグナルが送信されていましたが、今回から Docker イメージの STOPSIGNAL 設定を尊重するようになります。これにより SIGQUIT や SIGINT を使うアプリケーションも適切にグレースフルシャットダウンできます。データベース接続の正常切断やファイル保存処理など、終了時の処理が重要なアプリケーションで特に効果的です。全リージョンで利用可能です。詳細は こちらのドキュメントをご参照ください。 12/11(木) Amazon Aurora PostgreSQL が Kiro powers との統合をサポート Amazon Aurora PostgreSQL が Kiro powers との統合を開始しました。この統合により、AI エージェントの支援を受けながら Aurora PostgreSQL を使ったアプリケーション開発が可能になります。Kiro powers は事前にパッケージ化された MCP サーバーを提供し、データベースの作成、スキーマ設計、クエリ最適化などの作業で適切なガイダンスを自動的に提供します。従来は手動で行っていたデータベース操作や設計判断を AI がサポートすることで、開発効率が大幅に向上します。詳細は こちらの Blog 記事をご参照ください。 Amazon Cognito アイデンティティプールが AWS PrivateLink によるプライベート接続をサポート Amazon Cognito identity pools が AWS PrivateLink に対応しました。これまで認証トラフィックはパブリックインターネット経由でしか流せませんでしたが、VPC とのプライベート接続が可能になり、セキュリティが大幅に向上します。企業の機密データを扱うアプリケーションで、認証処理を完全にプライベートネットワーク内で完結できるため、コンプライアンス要件の厳しい業界でも安心して利用できます。詳細は こちらのドキュメントをご参照ください。 Amazon Aurora DSQL が数秒でのクラスター作成可能に Amazon Aurora DSQL でクラスター作成が数秒でできるようになりました。従来は数分かかっていた作業が劇的に高速化され、即座に利用できます。AWS コンソールの統合クエリエディターを使えば、外部クライアントの設定なしですぐに開発を開始でき、AI 支援ツールとの連携も可能です。詳細は こちらのドキュメントをご参照ください。 12/12(金) AWS Shield ネットワークセキュリティディレクターがマルチアカウント分析をサポート AWS Shield のネットワークセキュリティディレクターがマルチアカウント分析に対応しました。従来は単一アカウント内でのセキュリティ設定チェックのみでしたが、今回のアップデートにより複数の AWS アカウントを横断してネットワークセキュリティの状況を一元管理できるようになりました。委任管理者を設定することで組織全体のセキュリティ設定不備を検出し、修正手順も提示されます。大規模な組織でアカウント管理が複雑になりがちな環境で特に有効です。2025年12月時点ではまだ Preview 提供ですが、今回のアップデートと合わせて、追加で５つのリージョンにおいても利用可能となっています。利用詳細は こちらの概要ページをご参照ください。 AWS DataSync がオンプレミスファイル転送のスケーラビリティとパフォーマンスを向上 AWS DataSync Enhanced モードがオンプレミスファイルサーバーと Amazon S3 間のデータ転送に対応しました。従来は S3 間とマルチクラウド転送のみでしたが、今回 NFS や SMB ファイルサーバーからの転送も可能になりました。並列処理により高速転送を実現し、ファイル数制限も撤廃されています。生成 AI の学習データセット移行やデータレイク構築、大規模アーカイブ移行などに活用できます。詳細は こちらのドキュメントをご参照ください。 今年の週刊AWS は次回が最後です！ それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

この記事は Migrating from AWS CodeDeploy to Amazon ECS for blue/green deployments (記事公開日: 2025 年 9 月 16 日) を翻訳したものです。 ブルー/グリーンデプロイは、同一環境で実行している 2 つの異なるバージョンのアプリケーション間でトラフィックを切り替えることで、新しいソフトウェアをリリースできます。これにより、新しいバージョンのアプリケーションの安全なテストを促進し、ほぼゼロダウンタイムでのロールバック機能を提供することで、新しいソフトウェアリリースのデプロイに伴う一般的なリスクを軽減します。 最近まで、 Amazon Elastic Container Service (Amazon ECS) は、ネイティブなデプロイ戦略としてローリングアップデートのみをサポートしていました。ブルー/グリーンデプロイを実装したい場合は AWS CodeDeploy を使用する必要がありましたが、最近リリースされた ECS ブルー/グリーンデプロイ によりサポートされました。 ECS ブルー/グリーンデプロイは CodeDeploy と同様の機能を提供しますが、利用可能な機能とその実装にはいくつかの違いがあります。この記事は、現在 Amazon ECS でのブルー/グリーンデプロイに CodeDeploy を使用しており、新しい Amazon ECS ネイティブなデプロイ戦略への移行を検討しているお客様を対象としています。 (1) 移行を計画する際に考慮すべき要因 (2) CodeDeploy の概念を ECS ブルー/グリーンデプロイの同等機能にマッピングすること (3) 移行戦略についてのガイダンスを提供します。 移行の計画 CodeDeploy から ECS ブルー/グリーンデプロイに移行する際は、計画プロセスの一部として以下の点を考慮する必要があります。 新たな可能性 ： ECS ブルー/グリーンデプロイは、 CodeDeploy ではサポートされていない多数のユースケースを可能にします。これには以下が含まれます。 サービスディスカバリーオプション：CodeDeploy は Elastic Load Balancing (ELB) の背後に配置された ECS サービスのみをサポートしますが、ECS ブルー/グリーンデプロイは ELB と ECS Service Connect の両方をサポートします。 ヘッドレスサービスサポート：ECS ブルー/グリーンデプロイは、キュー処理サービスなど、サービス公開が不要な状況で使用できます。 Amazon EBS サポート：ECS ブルー/グリーンデプロイは、ECS サービスのデプロイ時に Amazon Elastic Block Store (Amazon EBS) ボリュームの設定をサポートします。 複数のターゲットグループ：ECS デプロイコントローラーにより、サービスを複数のターゲットグループに関連付けることができます。これは、複数のロードバランサーを通じて同時にアクセス可能であることを意味します (例：内部および外部サービス公開の分離) 。 柔軟な ALB リスナー設定：CodeDeploy は異なるサービス、本番およびテストエンドポイントに対して別々のリスナーが必要です。ECS ブルー/グリーンはリスナールールレベルで動作するため、ホスト名、HTTP ヘッダー、パス、メソッド、クエリ文字列、またはソース IP に基づく 高度なリクエストルーティング を使用して単一のリスナーを活用できます。例えば、パスベースルーティングを使用して複数のサービスに共通のリスナーポートを使用し、クエリ文字列ベースルーティングを使用して A/B テストをサポートできます。同じリスナーポートでブルー/グリーンの本番およびテストトラフィックもサポートできます。 運用上の改善： ECS ブルー/グリーンデプロイは、 (1) 既存の Amazon ECS 機能 (サーキットブレーカー、デプロイ履歴、ライフサイクルフックなど) との整合性の向上により、異なるAmazon ECS デプロイ戦略間の移行を支援し、 (2) ライフサイクルフックの実行時間の延長 (CodeDeploy のフックは 1 時間に制限) 、 (3) AWS CloudFormation サポートの改善 (サービスリビジョンとライフサイクルフック用の個別の AppSpec ファイルが不要) を提供します。 API/CLI の違い： API (および関連する CLI コマンド) に違いがあります。ある API から別の API へのマッピングは通常簡単ですが、ECS ブルー/グリーンデプロイはデプロイステップを制御するためにライフサイクルフックをより広範囲に使用することに注意してください。例えば、CodeDeploy が新しいデプロイをテストするための待機時間オプション (本番トラフィックを再ルーティングする前) をサポートしているのに対し、ECS ブルー/グリーンデプロイではこれを実現するためにフックを使用する必要があります。 コンソールの違い： 運用の一部として CodeDeploy コンソールを使用している場合、Amazon ECS コンソールがデプロイの進行の手動オーバーライドオプション (例：強制再ルーティングまたはベイク時間の早期終了) を提供していないことに注意してください。代わりに、Amazon ECS ライフサイクルフック (より安全なアプローチと言える) を通じて、より広範な運用プロセスと統合されたカスタム UI を作成できます。 移行パス： CodeDeploy から ECS ブルー/グリーンデプロイにサービスを移行するために利用可能な多数のオプションがあり、環境に最適なものを検討する必要があります。これらのオプションと関連する長所と短所については、この記事の後半でより詳細に説明します。 パイプラインサポート： 既存のパイプラインツールでは、ECS ブルー/グリーンデプロイのサポートが最初は制限される可能性があります。より高度なパイプライン統合では、暫定期間中にカスタムアクションの使用が必要になる場合があります。この記事の執筆時点では、CodePipeline Amazon ECS「標準」アクションを使用して、ECS ブルー/グリーンデプロイを通じてコンテナイメージの変更をデプロイできます (ただし、他のサービス設定変更はできません) 。 CodeDeploy から ECS ブルー/グリーンデプロイへ ECS ブルー/グリーンデプロイへの移行の実装コストを見積もる際は、APIの 違いと、CodeDeploy の機能を ECS ブルー/グリーンデプロイの同等機能にどのようにマッピングできるかを理解する必要があります。CodeDeploy の「一括」設定から開始することを前提として、このセクションでは主要な違いについて説明します。 ロードバランサー設定と ECS サービスの作成 CodeDeploy を使用して Amazon ECS サービスを作成する場合、まず本番リスナーと (オプションで) テストリスナーを持つロードバランサーを作成します。各リスナーは、図 1 (a)に示すように、すべてのトラフィックを単一のターゲットグループ (プライマリターゲットグループ) にルーティングする単一の (デフォルト) ルールで設定されます。次に、リスナーとターゲットグループを使用するように設定された Amazon ECS サービスを作成し、 デプロイコントローラー のタイプを CODE_DEPLOY に設定します。サービスの作成により、指定されたターゲットグループに登録された (ブルー) タスクセットが作成されます。 図 1：ロードバランサーの初期設定 ECS サービスが作成されると、CodeDeploy デプロイグループを (CodeDeploy アプリケーションの一部として) 作成し、ECS クラスター、ECS サービス名、ロードバランサーのリスナー、2 つのターゲットグループ (本番リスナールールで使用されるプライマリターゲットグループと、置換タスクに使用されるセカンダリターゲットグループ) 、 AWS Identity and Access Management (IAM) の CodeDeploy に Amazon ECS および ELB リソースを操作する権限を付与するサービスロール 、およびデプロイ動作を制御する様々なパラメータの詳細を設定します。 ECS ブルー/グリーンデプロイは、Amazon ECS サービス自体にデプロイ設定を指定します。ロードバランサーの本番リスナーは、重み 1 と 0 に設定された 2 つのターゲットグループを含むルールで事前設定されている必要があります。ECS サービス作成の一部として、このリスナールールの Amazon Resource Name (ARN) 、2 つのターゲットグループ、 IAM ロール (Amazon ECS にリスナーとターゲットグループを操作する権限を付与するため) 、 デプロイコントローラー のタイプを ECS に設定、および deploymentConfiguration.strategy を BLUE_GREEN に設定します。これにより、プライマリターゲットグループに登録されたタスクを持つ (ブルー) サービスリビジョン が作成されます。 両方のアプローチともタスクの初期セットの作成という結果になりますが、基盤となる実装は、CodeDeploy が タスクセット を使用するのに対し、Amazon ECS は サービスリビジョン を使用するという点で異なります。後者は Amazon ECS サービスデプロイ API の一部として導入され、デプロイプロセスとサービスデプロイ履歴への可視性を向上させます。 サービスリビジョンのデプロイ 図 2 は、新しいサービスリビジョンがどのようにデプロイされるかを示しています。CodeDeploy は CreateDeployment() を使用してサービスの新しいバージョンをデプロイし、CodeDeploy アプリケーション名、デプロイグループ名、および  AppSpec ファイル内のリビジョン詳細を指定します。これには、新しいリビジョンのタスク定義と、使用するコンテナ名およびポートが含まれている必要があります。ECS ブルー/グリーンデプロイは、 UpdateService() を呼び出して置換タスク定義の詳細を渡すことで、新しいサービスデプロイを作成します。 図 2：サービスリビジョンのデプロイ オプションで、CodeDeploy の AppSpecファイルは、ネットワーク設定やキャパシティプロバイダー戦略などのより多くのサービス設定変更を指定し、ライフサイクルフックを指定するためにも使用できます (次のセクションを参照) 。Amazon ECS を使用する場合は、 UpdateService() を使用してこれらの変更を指定します。 図 3：トラフィックの再ルーティング 図 3 は、トラフィック再ルーティングが実現される方法の違いを示しています。CodeDeploy では、デプロイが置換 (グリーン) タスクセットを作成し、そのタスクをセカンダリターゲットグループに登録します。これが正常になると、テスト (オプション) および本番で利用可能になります。どちらの場合も、再ルーティングは、グリーンタスクセットに関連付けられたセカンダリターゲットグループを指すように各リスナールールを変更することで実現されます。ロールバックは、本番リスナールールをプライマリターゲットグループに戻すことで実現されます。 対照的に、ECS ブルー/グリーンデプロイでは、サービスデプロイが (グリーン) タスクを持つ新しい サービスリビジョン を作成し、それらをセカンダリターゲットグループに登録します。その後、再ルーティングとロールバックは、リスナールールの重みを切り替えることで実現されます。 ライフサイクルフック CodeDeploy と ECS ブルー/グリーンデプロイの両方とも (オプションの) ライフサイクルフックをサポートしており、特定のライフサイクルイベントによって AWS Lambda 関数をトリガーできます。フックは、カスタムロジックでデプロイワークフローを拡張するのに役立ちます。例えば、ライフサイクルフックを使用して、本番ポートにライブトラフィックを再ルーティングする前に、テストポートでのテストを自動化できます。 CodeDeploy と ECS ブルー/グリーンデプロイは大まかに類似したライフサイクルに従いますが、設定オプションとライフサイクルフックの指定方法に違いがあります。 CodeDeploy は、 CreateDeployment() に提供される AppSpec ファイルの一部としてライフサイクルフックを指定します。これは、すべてのデプロイでフックを設定する必要があることを意味します。ECS ブルー/グリーンデプロイは、サービス設定の一部としてフック ( Amazon ECS ブルー/グリーンデプロイの Lambda 関数に必要となるアクセス許可 ) を指定し、変更には UpdateService() 呼び出しが必要になります。 CodeDeploy と Amazon ECS のライフサイクルイベントは同等ですが、以下の表に示すように異なる名前を持ちます。 ライフサイクルイベント CodeDeploy ECS ブルー/グリーン 新しいタスクが作成される前 BeforeInstall PRE_SCALE_UP 新しいタスクが準備完了 AfterInstall POST_SCALE_UP テストポートが有効になる前 同等のものなし TEST_TRAFFIC_SHIFT テストポートがトラフィックを受信する準備完了 AfterAllowTestTraffic POST_TEST_TRAFFIC_SHIFT 本番トラフィックをグリーンに再ルーティングする前 BeforeAllowTraffic PRODUCTION_TRAFFIC_SHIFT 本番トラフィックのグリーンへの再ルーティングが完了 AfterAllowTraffic POST_PRODUCTION_TRAFFIC_SHIFT CodeDeploy と ECS ブルー/グリーンデプロイの両方ともフック実装に Lambda を使用しますが、期待される入力と出力は異なり、特に Lambda 関数がフックステータスのレスポンスを返す方法が異なります。CodeDeploy では、関数は PutLifecycleEventHookExecutionStatus() を呼び出してフック実行ステータスを返す必要があり、これは Succeeded または Failed のいずれかになります。Amazon ECS では、Lambda のレスポンス自体がフック実行ステータスを示すために使用されます。 CodeDeploy は各フックを 1 回限りの呼び出しとして実行し、1 時間以内に最終実行ステータスが返されることを期待します。Amazon ECS フックはより柔軟で、 IN_PROGRESS インジケーターを返すことができ、これは SUCCEEDED または FAILED になるまでフックが繰り返し再実行されるべきであることを示します。フックはデフォルトで 30 秒ごとに実行されますが、レスポンスのパラメータを渡すことで次の実行のタイミングを設定できます。 その他の実装上の考慮事項 CodeDeploy は デプロイグループの詳細オプション の設定を提供しており、これらを Amazon ECS の同等機能にマッピングする必要がある場合があります。これには以下が含まれます。 Amazon Simple Notification Service (Amazon SNS) トリガー：Amazon ECS からの Amazon EventBridge イベントを使用して、状態変更を SNS トピックに発行します。 Amazon CloudWatch アラーム検出と自動ロールバック： Amazon ECS デプロイの失敗検出 機能を使用します。 移行パス CodeDeploy と ECS ブルー/グリーンデプロイ間の実装の違いを考慮した後、適切な移行アプローチを特定する必要があります。いくつかのオプションが利用可能であり、アーキテクチャと要件に最も適合するものを評価する必要があります。関与する要因には以下が含まれます。 ダウンタイム：ダウンタイムは発生するか、発生する場合はどの程度の時間か？ CodeDeploy へのロールバック：ECS ブルー/グリーンデプロイへの切り替えがうまくいかない場合に、移行をロールバックする能力を保持する必要があるか？これは「ブルー/グリーンソリューションのためのブルー/グリーン戦略！」と考えることができます。 サービスディスカバリー：サービスアドレスの変更 (新しい ALB の URI) に対応できるか、それとも同じアドレスを保持する必要があるか？ パフォーマンスおよび/またはデプロイの速度 コスト ロードバランサーの背後に配置された ECS サービスを継続して使用する場合、以下の移行オプションは、Amazon ECS サービス自体とロードバランサーのリソースの両方を考慮して、既存のリソースをどの程度再利用するかについての様々なバリエーションを示しています。すべての場合において、Amazon ECS デプロイコントローラーに渡すための IAM ロール を作成する必要があり、これにより必要なロードバランサーリソースを操作できるようになります。 オプション 1：インプレース更新 このアプローチでは、既存の Amazon ECS サービスを更新して、CodeDeploy デプロイコントローラーではなく、ブルー/グリーンデプロイ戦略を持つ Amazon ECS デプロイコントローラーを使用します。CodeDeploy で使用されているのと同じロードバランサーリスナーとターゲットグループを再利用します。前述のように、CodeDeploy は、サービスに接続されたロードバランサーのリスナーを、すべてのトラフィックを単一のターゲットグループ (プライマリターゲットグループ) にルーティングする単一の (デフォルト) ルールで設定します。ECS ブルー/グリーンデプロイの場合、ロードバランサーリスナーは、重み 1 と 0 に設定された 2 つのターゲットグループを含むルールで事前設定されている必要があります。したがって、以下のステップが必要です。 本番/テストリスナーのデフォルトルールを変更して、代替ターゲットグループを含め、ターゲットグループと代替ターゲットグループの重みをそれぞれ 1 と 0 に設定します。 UpdateService() を呼び出して既存の Amazon ECS サービスを更新し、パラメータ deploymentController を ECS に、パラメータ deploymentStrategy を BLUE_GREEN に設定します。IAM ロール、ターゲットグループ、代替ターゲットグループ、本番リスナールール、およびテストリスナールール (オプション) の ARN を渡します。 Amazon ECS デプロイコントローラーが代替ターゲットグループの下で新しいタスクを持つ新しいサービスリビジョンを作成し、すぐにこのターゲットグループにトラフィックを再ルーティングします。これが完了するまで待機し、その後サービスが期待どおりに動作していることを確認します。 ECS ブルー/グリーンデプロイを使用するようになったら、この Amazon ECS サービス用の CodeDeploy リソースを削除します。 インプレース更新は安全な操作ですが、 (1) 手動エラーの可能性を最小限に抑えるためにプロセスを自動化し (特にリスナー設定を変更する場合) 、 (2) 開発者および/または UAT 環境でこのプロセスを徹底的にテストすることに注意する必要があります。また、Amazon ECS コントローラーがサービスリビジョンの初期作成を完了するとすぐにトラフィックが再ルーティングされることも認識しておく必要があります。さらに、再ルーティング前にこのリビジョンをテストするオプションはありません (ただし、タスクは CodeDeploy で実行されていたタスクセットと同一である必要があります) 。 オプション 2：新しい ECS サービスと既存のロードバランサー このアプローチは移行にブルー/グリーン戦略を使用します (言い換えれば、ブルー/グリーンソリューションのためのブルー/グリーン移行です) 。ECS ブルー/グリーンデプロイを使用して新しい並列ブルー/グリーンセットアップを作成し、それを検証し、CodeDeploy セットアップから新しい ECS ブルー/グリーンデプロイセットアップに切り替え、その後 CodeDeploy リソースを削除します。 必要に応じてこのセットアップにロールバックできるように、CodeDeploy セットアップ用のリスナー、ターゲットグループ、および Amazon ECS サービスをそのまま残しておきます。 既存のロードバランサーの下に新しいターゲットグループと新しいリスナー (元のリスナーとは異なるポート) を作成します。その後、既存の Amazon ECS サービスと一致する新しい Amazon ECS サービスを作成しますが、デプロイコントローラーとして ECS を使用し、デプロイ戦略として BLUE_GREEN を使用し、IAM ロール、新しいターゲットグループ、および新しいリスナールールの ARN を渡します。 新しいセットアップを検証します (新しいリスナーのポートを使用) 。すべてがうまくいけば、元のリスナーのポートを異なるポート番号に変更し (元のポートを解放するため) 、新しいリスナーのポートを元のポートに切り替えて、新しいセットアップにトラフィックをルーティングします。 新しいセットアップを観察し、すべてが期待どおりに動作し続けたら、CodeDeploy セットアップを削除できます。 図 4 はこのアプローチを示しています。 図 4：オプション 2 – 新しいサービスと既存のロードバランサー オプション 3：新しい ECS サービスと新しいロードバランサー 前述のアプローチと同様に、このアプローチは移行にブルー/グリーン戦略を使用します。主な違いは、CodeDeploy セットアップから ECS ブルー/グリーンデプロイセットアップへの切り替えが、ロードバランサーの上の別のルーティング層で行われることです (図 5 に示すとおり) 。この層の実装例には、 Amazon Route 53 、 Amazon API Gateway 、および Amazon CloudFront が含まれます。 このアプローチは、すでにこのルーティング層を持っているユーザーに適しており、Amazon ECS サービスとのすべての通信がその層を通じて行われている場合 (つまり、ロードバランサーレベルでの直接通信がない場合) に適用できます。オプション 2 と比較すると、このオプションはゼロダウンタイムという利点がありますが、少しコストが高くなります。 図 5：オプション 3 – 新しいサービスと新しいロードバランサー アプローチの比較 以下の表は、これら 3 つの移行アプローチを、あなたにとって重要度が異なる可能性のある多数の要因で比較しています。この表を使用して、あなた自身の特定の状況と優先事項に最も適したオプションを評価できます。 オプション 1：インプレース更新 オプション 2：新しい ECS サービスと既存のロードバランサー オプション3：新しい ECS サービスと新しいロードバランサー 移行の複雑さ シンプル 既存の Amazon ECS サービスのデプロイメントコントローラーとデプロイメント戦略を更新 より複雑 新しい Amazon ECS サービス、ターゲットグループ、リスナーを作成し、ポートを交換 より複雑 新しい Amazon ECS サービス、ターゲットグループ、ロードバランサー、リスナーを作成し、ルーティング層の設定を変更 リスク軽減オプション 中程度 テスト用の並列ブルー/グリーンセットアップが利用できません。プロセスの自動化とテストに重点を置く 強力 並列ブルー/グリーンセットアップ、トラフィックを再ルーティングする前に新しいセットアップをテスト 強力 並列ブルー/グリーンセットアップ、トラフィックを再ルーティングする前に新しいセットアップをテスト デプロイメントコントローラーのロールバック シンプル サービスデプロイメントコントローラーを CODE_DEPLOY に戻す シンプル ポート交換を元に戻す シンプル ルーティング層の設定変更をロールバック ダウンタイム ダウンタイムなし ポート交換中の最小限の中断 ダウンタイムなし 適用性 制約なし 制約なし 追加のルーティング層が必要 コスト 追加コストなし 追加コスト 関連するタスクを持つ2つの共存する Amazon ECS サービス 追加コスト 関連するタスクを持つ2つの共存する Amazon ECS サービスと追加のロードバランサー まとめ この記事では、AWS CodeDeploy から Amazon ECS の組み込みブルー/グリーンデプロイへの移行について説明しました。この議論には以下が含まれていました。 移行を決定する前に考慮すべき要因 主要なアーキテクチャの違いと関連する実装上の考慮事項 移行にアプローチする 3 つの異なる方法 現在 CodeDeploy を使用しており、ECS ブルー/グリーンデプロイへの移行を検討している場合は、この記事を実現可能性を評価し、移行を計画するためのガイドとして使用できます。ECS ブルー/グリーンデプロイの詳細については、 Amazon ECS の開発者ガイド をご確認ください。 翻訳はソリューションアーキテクトの加治が担当しました。原文は こちら です。

2025 年 12 月 2 日、 Amazon CloudWatch の機能を拡張して、運用、セキュリティ、コンプライアンスのさまざまなユースケースでログデータを統合して管理し、柔軟で強力な分析を 1 か所で行い、データの重複とコストを削減しました。 今回の機能強化により、CloudWatch は、 Open Cybersecurity Schema Framework (OCSF) および Open Telemetry (OTel) 形式の組み込みサポートにより、ソース間の一貫性が保たれるようにデータを自動的に正規化および処理できるため、分析とインサイトに集中できます。CloudWatch では、 Amazon Simple Storage Service (Amazon S3) Tables を介したデータへのApache Iceberg 互換のアクセスも導入されています。これにより、ローカルだけでなく、 Amazon Athena 、 Amazon SageMaker Unified Studio 、またはその他の Iceberg 互換ツールを使用して分析を実行できます。 また、CloudWatch の運用データを、お好みのツールの他のビジネスデータに関連付けて、他のデータと相関することもできます。この統一されたアプローチにより、管理が合理化され、セキュリティ、運用、ビジネスのユースケースを包括的に関連付けることができます。 詳細な機能強化は次のとおりです。 データインジェストと正規化を効率化 — CloudWatch は、複数アカウントや複数の AWS リージョンにわたって AWS が提供するログを自動的に収集し、 AWS Organizations と連携して、 AWS CloudTrail 、 Amazon Virtual Private Cloud (Amazon VPC) フローログ、 AWS WAF アクセスログ、 Amazon Route 53 Resolver ログなどの AWS サービスに対応します。また、エンドポイント (CrowdStrike、SentinelOne)、アイデンティティ (Okta、Entra ID)、クラウドセキュリティ (Wiz)、ネットワークセキュリティ (Zscaler、Palo Alto Networks)、生産性およびコラボレーション (Microsoft Office 365、Windows Event Logs、GitHub) などのサードパーティソース向けの事前構築済みコネクタに加え、ServiceNow CMDB を備えた IT サービスマネージャーとも連携します。CloudWatch では、取り込まれているデータを正規化して処理するために、さまざまな AWS およびサードパーティのデータソース、およびカスタム解析、フィールドレベルの操作、文字列操作を行うための Grok などの他のプロセッサ向けのマネージド OCSF 変換を提供しています。 コストのかかるログデータ管理を削減 — CloudWatch は、ガバナンス機能が組み込まれた単一のサービスにログ管理を統合します。異なるツールやデータストアに同じデータの複数のコピーを保存して維持する必要はありません。CloudWatch の統合データストアにより、複雑な ETL パイプラインが不要になり、複数の個別のデータストアやツールを維持するために必要な運用コストと管理オーバーヘッドが削減されます。 ログデータからビジネス上のインサイトを得る — CloudWatch では、自然言語クエリと LogSQL、PPL、SQL などの一般的なクエリ言語を使用して 1 つのインターフェイスからクエリを実行したり、Apache Iceberg 互換テーブルから任意の分析ツールを使用してデータをクエリしたりできます。新しいファセットインターフェイスでは、ソース、アプリケーション、アカウント、リージョン、ログタイプで直感的にフィルタリングできます。これを使用して、インテリジェントなパラメータ推論により、複数の AWS アカウントとリージョンのロググループにわたってクエリを実行できます。 次のセクションでは、CloudWatch Logs の新しいログ管理および分析機能について説明します。 1.データソースとタイプによるデータの発見と管理 CloudWatch コンソールの新しいログ管理ビューでは、ログとすべてのデータソースの概要を確認できます。開始するには、 CloudWatch コンソール に移動し、左側のナビゲーションペインの [ログ] メニューで [ログ管理] を選択します。 [概要] タブでは、ログ、データソース、タイプ、取り込み後のロググループの状態に関するインサイト、異常を確認できます。 [データソース] タブを選択すると、データソース、タイプ、およびフィールドごとにログデータを検索して管理できます。CloudWatch は、AWS サービス、サードパーティ、またはアプリケーションログなどのカスタムソースごとにデータソースを取り込み、自動的に分類します。 S3 Tables を統合する データソースアクション を選択して、選択したデータソースの今後のログを作成します。Athena や Amazon Redshift、Spark などの他のクエリエンジンを介し、Iceberg 互換のアクセスパターンを使用してログを柔軟に分析できます。この統合により、CloudWatch からのログは読み取り専用の aws-cloudwatch S3 Tables バケットで利用できるようになります。 CloudTrail データなどの特定のデータソースを選択すると、データ形式、パイプライン、ファセット/フィールドインデックス、S3 Tables の関連付け、そのデータソースとのログ数に関する情報を含むデータソースの詳細を表示できます。このデータソースに含まれるすべてのロググループを確認し、新しいスキーマサポートを使用してソース/タイプフィールドインデックスポリシーを入力および編集できます。 データソースとインデックスポリシーの管理方法の詳細については、「Amazon CloudWatch Logs ユーザーガイド」の「 データソース 」を参照してください。 2.CloudWatch パイプラインを使用したインジェストとトランスフォーメーション パイプラインを作成して、テレメトリデータやセキュリティデータの収集、変換、ルーティングを効率化すると同時に、データ形式を標準化してオブザーバビリティとセキュリティデータ管理を最適化できます。CloudWatch の新しいパイプライン機能は、データソースのカタログからのデータを接続するため、ライブラリからパイプラインプロセッサを追加して設定し、データを解析、強化、標準化できます。 [パイプライン] タブで [パイプラインを追加] を選択します。パイプライン設定ウィザードが表示されます。このウィザードでは、5 つの手順に従ってデータソースとその他のソースの詳細 (ログソースタイプなど) を選択し、保存先を設定し、データに対してアクション (フィルタリング、変換、エンリッチングなど) を実行するプロセッサを最大 19 個まで設定し、最後にパイプラインを確認してデプロイすることができます。 CloudWatch の新しい 取り込み 機能を使用してパイプラインを作成するオプションもあります。パイプラインの設定と管理方法の詳細については、「Amazon CloudWatch Logs ユーザーガイド」の「 パイプライン 」を参照してください。 3.データソースに基づく分析とクエリの強化 ファセットとデータソースに基づくクエリをサポートすることで、分析を強化できます。ファセットを使用すると、ログをインタラクティブに探索したり掘り下げたりできます。ファセットの値は、選択した期間に基づいて自動的に抽出されます。 左側のナビゲーションペインの [ログ] メニューの [Log Insights] で [ファセット] タブを選択します。パネルに表示される使用可能なファセットと値を表示できます。1 つまたは複数のファセットと値を選択して、データをインタラクティブに調べることができます。VPC フローログのグループとアクションに関するファセットを選択し、AI クエリジェネレータを使用して VPC フローログで最も頻繁な 5 つのパターンを一覧表示するようにクエリし、結果のパターンを取得します。 選択したファセットと指定した値を使用してクエリを保存できます。保存したクエリを次回選択すると、クエリ対象のログには事前に指定されたファセットと値が含まれます。ファセット管理の詳細については、「CloudWatch Logs ユーザーガイド」の「 ファセット 」を参照してください。 前に説明したように、データソースを S3 Tablesに統合し、まとめてクエリを実行できます。たとえば Athena のクエリエディタを使えば、特定の IP レンジ ( 174.163.137.* ) からのネットワークトラフィックと AWS API アクティビティを相関分析できます。これは、VPC フローログと CloudTrail ログを、送信元 IP アドレスの一致を基に結合することで実現できます。 このタイプの統合検索は、セキュリティモニタリング、インシデント調査、疑わしい動作の検出に特に役立ちます。ネットワークに接続している IP が、ユーザーの作成、セキュリティグループの変更、データへのアクセスなどの機密な AWS 操作も実行しているかどうかを確認できます。 詳細については、「CloudWatch Logs ユーザーガイド」の「 S3 Tablesと CloudWatch の統合 」を参照してください。 今すぐご利用いただけます Amazon CloudWatch の新しいログ管理機能は現在、AWS GovCloud (米国) リージョンと中国リージョンを除くすべての AWS リージョンでご利用いただけます。リージョンごとの提供状況や今後のロードマップについては、 AWS Capabilities by Region をご覧ください。前払いの義務や最低料金はありません。データインジェスト、ストレージ、クエリに既存の CloudWatch Logs を使用した分だけお支払いいただきます。詳細については、 CloudWatch の料金表ページ をご覧ください。 CloudWatch コンソール で試してください。詳細については、 CloudWatch の製品ページ にアクセスしてください。フィードバックは、 AWS re:Post for CloudWatch Logs 、または通常の AWS サポートの担当者までお寄せください。 – Channy 原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。先週の re:Invent 2025 、みなさまはいかがお過ごしでしたか？　現地に来てくださった方も、オンデマンドで視聴いただいた方も、何か学びになるものを身につけていただけましたなら幸いです。 そして、毎年おなじみ 1 時間で振り返る re:invent 速報を今年も開催いたしました。忙しくてなかなかキャッチアップできなかった方も こちらのページ からキャッチアップをお願いいたします。 先日 2つの新しいプランを追加した「 AWS ジャパン生成 AI 実用化推進プログラム 」も非常に多くの申し込みをいただいています。引き続き募集中ですのでよろしくお願いします。 それでは、12 月 08 日週の生成 AI with AWS界隈のニュースを見ていきましょう。re:Invent 2025 で発表された内容が続々と日本語化されています。ぜひお役立てください。 さまざまなニュース お客様事例 AWS生成AI国内事例ブログ: エスツーアイ株式会社様、Kiro を活用した経費精算システムの迅速な開発 エスツーアイ株式会社様は、愛知県に本社を置く製造業向けシステムインテグレーションサービス企業です。同社では、経営層が AI コーディングの重要性を認識していたものの、現場エンジニアが日々の業務に追われ、新しい技術に取り組む余裕がない状況でした。この課題を解決するため、AI IDE「Kiro」を活用して出張経費精算システムの開発に取り組まれました。ベテランエンジニアが実働約 10 日間（1 日 1〜2 時間の作業）で基本機能を実装し、従来手法と比較して大幅な期間短縮を実現されました。特に Kiro の「Vibe」と「Spec」の使い分けにより、コード生成とドキュメント作成の両方を効率化できたことが成功のポイントでした。 AWS生成AI国内事例ブログ: 明治ホールディングス株式会社様、Amazon Q Developer 導入により 80-90% の生産性向上を実現 明治ホールディングス株式会社様のグループ DX 推進部 AWS 事務局では、300 を超える AWS アカウントを 20 名のメンバーで管理する中で、開発・運用効率化が課題となっていました。Amazon Q Developer を段階的に導入し、ドキュメント・設計資料の自動化、Infrastructure as Code 開発の効率化、運用・トラブルシューティングの高度化、組織全体の管理基盤整備を実現されました。その結果、AWS 事務局全体で 80-90% の生産性向上を達成し、30 名超が継続的に活用されています。特に Model Context Protocol サーバの利用により、素早く正確な情報へのアクセスと調査、ドキュメント生成が可能になりました。 AWS生成AI国内事例ブログ: 地方病院がシステムの内製化に挑戦、IT 知識ゼロから始めた生成 AI による業務効率化への 90 日 兵庫県立リハビリテーション中央病院様と熊本中央病院様が、ANGEL Dojo 2025 プログラムに参加し、IT 知識ゼロの状態から 90 日間で生成 AI を活用したシステム開発に取り組まれました。兵庫県立様は Amazon Bedrock を用いたリハビリスケジュール自動化で 60% の自動化を実現し、月当り約 36 単位（88,200 円）の収益増加を見込んでいます。熊本中央病院様は退院サマリ等の文書作成に生成 AI を活用し、月 800 時間の文書作成時間削減を確認されました。企業とパートナーによる共創型内製化により、医療機関でも AI を活用したシステム開発が現実的になることを実証されています。 技術記事 ブログ記事「 Amazon Nova 2 Sonic の紹介: 会話型 AI 向けの新しい音声変換モデル 」を公開 2025 年 12 月 2 日に発表された Amazon Nova 2 Sonic は、自然でリアルタイムな音声対話をアプリケーションにもたらす音声変換の基盤モデルです。この記事では、業界トップクラスの会話品質と価格設定を実現する Nova 2 Sonic の特徴を詳しく解説しています。多言語サポートの拡張（ポルトガル語とヒンディー語を追加）、ポリグロット音声による言語切り替え機能、自然なターンテイキング、クロスモーダルインタラクション、非同期ツール呼び出しなど、実用的な音声 AI アプリケーション開発に役立つ機能が紹介されています。 ブログ記事「 高速で費用対効果の高い推論モデル、Amazon Nova 2 Lite の紹介 」を公開 Amazon Nova 2 Lite は、日常のワークロードに対応する高速で費用対効果の高い推論モデルとして 12 月 2 日にリリースされました。この記事では、拡張思考（Extended Thinking）機能による段階的な推論、100 万トークンのコンテキストウィンドウ、ウェブグラウンディングとコードインタープリターの組み込みツールなど、Nova 2 Lite の特徴を紹介しています。ビジネスアプリケーション、ソフトウェアエンジニアリング、ビジネスインテリジェンスなど幅広いユースケースでの活用方法も解説されています。 ブログ記事「 新しい AWS Security Agent は、設計からデプロイまでアプリケーションをプロアクティブに保護します（プレビュー） 」を公開 2025 年 12 月 2 日に発表された AWS Security Agent は、開発ライフサイクル全体を通じてアプリケーションを積極的に保護するフロンティアエージェントです。この記事では、設計セキュリティレビュー、コードセキュリティレビュー、オンデマンド侵入テスト機能を提供する AWS Security Agent の詳細を解説しています。AI を活用した自動セキュリティレビューと状況に応じた侵入テストにより、開発の早い段階で脆弱性を防ぐことができ、従来の手動プロセスと比較して大幅な時間短縮を実現します。 ブログ記事「 Amazon Bedrock を活用した太陽光発電データの異常検知・分析システムの構築事例 」を公開 株式会社エナリス様および KDDI アジャイル開発センター株式会社様と共同で執筆した、Amazon Bedrock を活用した太陽光発電データの異常検知・分析システムの構築事例を紹介しています。この記事では、Amazon Bedrock Agents と Amazon Bedrock Knowledge Bases を組み合わせて、太陽光発電設備の運用データから異常を検知し、分析結果を自然言語で提供するシステムの実装方法を解説しています。生成 AI を活用したデータ分析の実践的な事例として参考になります。 ブログ記事「 Amazon Bedrock AgentCore には、信頼できる AI エージェントをデプロイするための品質評価とポリシーコントロールが追加されました 」を公開 2025 年 12 月 2 日に発表された Amazon Bedrock AgentCore の新機能について解説した記事です。AgentCore のポリシー機能により、詳細な権限を持つポリシーを使用してエージェントアクションの明確な境界を定義できます。AgentCore Evaluations では、組み込みエバリュエーターを使用して実際の行動に基づいてエージェントの質をモニタリングします。また、AgentCore Memory のエピソード機能により、エージェントが経験から学び、将来の同様のタスクの一貫性とパフォーマンスを向上させることができます。 ブログ記事「 Amazon Bedrockは、開発者がより賢く、より正確なAIモデルを構築する方法を簡素化する強化学習によるファインチューニングを追加しました 」を公開 Amazon Bedrock に新たに追加された強化学習ファインチューニング機能について詳しく解説した記事です。従来の大規模なラベル付きデータセットを必要とする手法とは異なり、フィードバックから学習してモデルを改善する新しいアプローチを紹介しています。基本モデルと比較して平均 66% の精度向上を実現し、深い機械学習の専門知識なしに高度なモデルカスタマイズが可能になることが説明されています。 ブログ記事「 MCP を用いた Amazon Connect の監視運用準備 」を公開 Model Context Protocol (MCP) と生成 AI を活用して Amazon Connect の監視機能を強化する方法を紹介した記事です。MCP と Amazon Connect の組み合わせにより、フロー効率の分析や監視設定の最適化などが自然言語で直感的に行えるようになり、コンタクトセンターの運用準備体制の向上に役立つことが解説されています。 ブログ記事「 小売業の未来を読み解く：AI ショッピングエージェントの活用 」を公開 AI を活用したショッピングエージェントが小売業界に与える影響と、Model Context Protocol (MCP) を活用した対応策について解説した記事です。AI エージェントが商品発見と購入方法を根本的に変革する中で、小売企業が AWS 上に MCP サーバーを構築することで、AI エージェントとの直接的な関係を築き、競争優位性を確保する方法を紹介しています。 ブログ記事「 AWS Transform discovery tool の紹介 」を公開 VMware インフラストラクチャにデプロイする Open Virtual Appliance（OVA）として提供される AWS Transform discovery tool について解説した記事です。クラウド接続や外部依存関係を必要とせずにオンプレミスでデプロイできる自己完結型アプリケーションとして動作し、ワークロードからパフォーマンスデータとネットワーク接続データを収集します。厳格に規制された業界や、厳格なデータガバナンス要件を持つ組織での移行準備に適しています。 ブログ記事「 Amazon SageMaker AI の新しいサーバーレスカスタマイズにより、モデルのファインチューニングが加速します 」を公開 Amazon Nova、DeepSeek、GPT-OSS、Llama、Qwen などの人気の AI モデル向けの Amazon SageMaker AI の新しいサーバーレスカスタマイズ機能について解説した記事です。強化学習などの最新ファインチューニング手法を簡単に操作できるインターフェイスを提供し、AI モデルのカスタマイズプロセスを数か月から数日に短縮できます。完全にサーバーレスで実行されるため、インフラ管理ではなくモデルのチューニングに専念できます。 ブログ記事「 Amazon SageMaker HyperPod でのチェックポイントなしかつ弾力的なトレーニングの紹介 」を公開 Amazon SageMaker HyperPod における 2 つの新しい AI モデル訓練機能について解説した記事です。チェックポイントレストレーニングは、従来のチェックポイントベースのリカバリーの必要性を軽減し、数時間かかる復旧時間を数分に短縮します。エラスティックトレーニングは、リソースの可用性に基づいて AI ワークロードを自動的にスケールさせることを可能にし、クラスターの利用効率を最大化します。 サービスアップデート Amazon Quick Suite でレポート自動化のための Research と Flow の統合機能を発表 Amazon Quick Suite に、データ分析と研究ワークフローを自動化する新機能が追加されました。この機能により、複雑なデータ分析プロセスを自動化し、レポート生成の効率化が可能になります。生成 AI を活用したインサイト抽出と組み合わせることで、より高度なビジネスインテリジェンス機能を提供します。 Amazon Aurora PostgreSQL で Kiro powers 統合を発表 Amazon Aurora PostgreSQL に、AI 開発プラットフォーム Kiro との統合機能が追加されました。この統合により、データベース操作と AI 開発ワークフローをシームレスに連携させることが可能になり、データドリブンな AI アプリケーションの開発効率が向上します。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近見た映画は「舟を編む」です。

本ブログは 2025 年 12 月 4 日に公開された AWS Blog “ China-nexus cyber threat groups rapidly exploit React2Shell vulnerability (CVE-2025-55182) ” を翻訳したものです。 2025 年 12 月 12 日: ReactJS バージョンの更新が必要となるタイミングを明確にするため、このブログ記事を更新しました。 2025 年 12 月 3 日に CVE-2025-55182 (React2Shell) が公開されてから数時間以内に、Amazon の脅威インテリジェンスチームは、Earth Lamia や Jackpot Panda を含む複数の中国国家支援型脅威グループによる活発な悪用試行を観測しました。React Server Components におけるこの重大な脆弱性は、共通脆弱性評価システム (CVSS) スコアが最大値の 10.0 であり、App Router を使用している React バージョン 19.x および Next.js バージョン 15.x と 16.x に影響します。この脆弱性は AWS サービスには影響しませんが、お客様自身の環境で React または Next.js アプリケーションを実行しているお客様が直ちに対応できるよう、この脅威インテリジェンスを共有します。 中国は引き続き国家支援型サイバー脅威アクティビティの最も活発な発信源であり、脅威アクターは公開エクスプロイトを開示から数時間または数日以内に日常的に実戦投入しています。 AWS MadPot ハニーポットインフラストラクチャでの監視を通じて、Amazon の脅威インテリジェンスチームは、既知のグループとこれまで未特定だった脅威グループの両方が CVE-2025-55182 の悪用を試みていることを特定しました。AWS は、Sonaris アクティブディフェンス、 AWS WAF マネージドルール ( AWSManagedRulesKnownBadInputsRuleSet バージョン 1.24 以降)、および境界セキュリティコントロールを通じて、複数層の自動保護をデプロイしています。ただし、これらの保護はパッチ適用の代替にはなりません。お客様がフルマネージド AWS サービスを使用しているかどうかに関わらず、お客様の環境で影響を受けるバージョンの React または Next.js を実行している場合は、直ちに最新のパッチ適用済みバージョンに更新する必要があります。お客様自身の環境 ( Amazon Elastic Compute Cloud (Amazon EC2) 、コンテナなど) で React または Next.js を実行しているお客様は、脆弱なアプリケーションを直ちに更新する必要があります。 CVE-2025-55182 (React2Shell) の理解 Lachlan Davidson によって発見され、2025 年 11 月 29 日に React チームに開示された CVE-2025-55182 は、React Server Components における安全でないデシリアライゼーション脆弱性です。この脆弱性はセキュリティ研究者によって React2Shell と名付けられました。 主要な事実 CVSS スコア : 10.0 (最大深刻度) 攻撃ベクトル : 認証不要のリモートコード実行 影響を受けるコンポーネント : React 19.x および App Router を使用する Next.js 15.x/16.x の React Server Components 重要な詳細 : React Server Components をサポートしている限り、サーバー関数を明示的に使用していなくてもアプリケーションは脆弱です この脆弱性は Vercel によって Meta および AWS を含む主要なクラウドプロバイダーに責任を持って開示され、脆弱性の公開開示前に協調的なパッチ適用と保護のデプロイが可能になりました。 CVE-2025-55182 を悪用しているのは誰か AWS MadPot ハニーポットインフラストラクチャにおける悪用試行の分析により、既知の中国国家支援型脅威アクターに歴史的に関連する IP アドレスとインフラストラクチャからの悪用アクティビティを特定しました。中国の脅威グループ間で匿名化インフラストラクチャが共有されているため、攻撃主体の明確な特定は困難です。 Earth Lamia に関連するインフラストラクチャ : Earth Lamia は、ラテンアメリカ、中東、東南アジアの組織を標的とするために Web アプリケーションの脆弱性を悪用することで知られる中国関連のサイバー脅威アクターです。このグループは歴史的に、金融サービス、物流、小売、IT 企業、大学、政府組織などのセクターを標的としてきました Jackpot Panda に関連するインフラストラクチャ : Jackpot Panda は、主に東アジアおよび東南アジアのエンティティを標的とする中国関連のサイバー脅威アクターです。このアクティビティは、国内の安全保障と汚職に関する懸念に関連する収集の優先事項と一致している可能性があります 共有匿名化インフラストラクチャ : 大規模な匿名化ネットワークは中国のサイバー作戦の特徴となっており、攻撃元を隠しながら偵察、悪用、コマンド&コントロール (C2) アクティビティを可能にしています。これらのネットワークは複数の脅威グループによって同時に使用されるため、特定のアクティビティを個々のアクターに結びつけることが困難になっています これは、中国関連のサイバー脅威アクティビティと共通性を持つ他の多くの攻撃主体不明の脅威グループに加えてのものです。攻撃主体不明のアクティビティで観測された自律システム番号 (ASN) の大部分は中国のインフラストラクチャに関連しており、ほとんどの悪用アクティビティがその地域から発生していることをさらに確認しています。これらのグループが公開概念実証 (PoC) エクスプロイトを実戦投入した速さは、重大な事実を浮き彫りにしています。すなわち、PoC がインターネットに公開されると、高度な脅威アクターはそれらを迅速に武器化するということです。 悪用ツールと技術 脅威アクターは、自動スキャンツールと個別の PoC エクスプロイトの両方を使用しています。観測された一部の自動ツールには、ユーザーエージェントのランダム化などの検出を阻止する機能があります。これらのグループは、CVE-2025-55182 にアクティビティを限定していません。Amazon の脅威インテリジェンスチームは、CVE-2025-1338 を含む他の最近の N-day 脆弱性を同時に悪用していることを観測しました。これは体系的なアプローチを示しています。脅威アクターは新しい脆弱性の開示を監視し、公開エクスプロイトをスキャンインフラストラクチャに迅速に統合し、複数の CVE にわたって広範なキャンペーンを同時に実施して、脆弱なターゲットを見つける可能性を最大化します。 公開 PoC の現実: 品質より量 調査からの注目すべき観察は、多くの脅威アクターが実際のシナリオでは実際には機能しない公開 PoC を使用しようとしていることです。GitHub セキュリティコミュニティは、脆弱性の仕組みを正しく理解していない複数の PoC を特定しています。 一部の悪用可能なアプリケーションの例では、サーバーマニフェストに危険なモジュール ( fs 、 child_process 、 vm ) を明示的に登録していますが、これは実際のアプリケーションでは決して行うべきではありません いくつかのリポジトリには、安全なバージョンにパッチを適用した後でも脆弱なままになるコードが含まれています 多くの公開 PoC の技術的不備にもかかわらず、脅威アクターは依然としてそれらを使用しようとしています。これはいくつかの重要なパターンを示しています。 正確性より速度 : 脅威アクターは徹底的なテストよりも迅速な実戦投入を優先し、利用可能な任意のツールでターゲットを悪用しようとします ボリュームベースのアプローチ : 複数の PoC (機能しないものでも) で広範にスキャンすることで、アクターは脆弱な設定のわずかな割合を見つけることを期待しています 参入障壁の低さ : 公開エクスプロイトの利用可能性は、欠陥があっても、より洗練されていないアクターが悪用キャンペーンに参加することを可能にします ノイズの生成 : 失敗した悪用試行はログに大量のノイズを生成し、より高度な攻撃を隠す可能性があります 持続的かつ体系的な攻撃パターン MadPot からのデータ分析により、これらの悪用試行の持続的な性質が明らかになりました。注目すべき例として、IP アドレス 183[.]6.80.214 に関連する攻撃主体不明のアクティビティの脅威グループが、約 1 時間 (2025/12/4 02:30:17 〜 03:22:48 UTC) にわたって体系的に悪用試行のトラブルシューティングを行いました。 52 分間で合計 116 件のリクエスト 複数のエクスプロイトペイロードを試行 Linux コマンド ( whoami 、 id ) の実行を試行 /tmp/pwned.txt へのファイル書き込みを試行 /etc/passwd の読み取りを試行 この動作は、脅威アクターが単に自動スキャンを実行しているだけでなく、実際のターゲットに対して悪用技術を積極的にデバッグし、改良していることを示しています。 AWS によるお客様の保護 AWS は、お客様を保護するために複数層の保護をデプロイしました。 Sonaris アクティブディフェンス AWS の Sonaris 脅威インテリジェンスシステムは、この脆弱性を標的とする悪意のあるスキャン試行を自動的に検出し、制限しました。Sonaris は毎分 2,000 億を超えるイベントを分析し、MadPot ハニーポットネットワークからの脅威インテリジェンスを統合して、悪用試行をリアルタイムで特定しブロックします。 AWS WAF マネージドルール AWS WAF AWSManagedRulesKnownBadInputsRuleSet のデフォルトバージョン (1.24 以降) には、CVE-2025-55182 に対応する更新されたルールが含まれており、マネージドルールセットで AWS WAF を使用しているお客様に自動保護を提供します。 MadPot インテリジェンス AWS のグローバルハニーポットシステムは、悪用試行の早期検出を提供し、迅速な対応と脅威分析を可能にしました。 Amazon 脅威インテリジェンス Amazon 脅威インテリジェンスチームは、AWS インフラストラクチャを保護するために CVE-2025-55182 の悪用試行を積極的に調査しています。お客様のインフラストラクチャが侵害された兆候を特定した場合、AWS サポートを通じて通知します。ただし、アプリケーション層の脆弱性は、ネットワークテレメトリだけでは包括的に検出することが困難です。AWS からの通知を待たないでください。 重要 : これらの保護はパッチ適用の代替にはなりません。お客様自身の環境 (Amazon EC2、コンテナなど) で React または Next.js を実行しているお客様は、脆弱なアプリケーションを直ちに更新する必要があります。 直ちに推奨される対応 脆弱な React/Next.js アプリケーションを更新してください。影響を受けるバージョンとパッチ適用済みバージョンについては、AWS セキュリティ速報 ( https://aws.amazon.com/security/security-bulletins/AWS-2025-030/ ) を参照してください 暫定的な保護として、カスタム AWS WAF ルールをデプロイしてください (ルールはセキュリティ速報に記載されています) アプリケーションおよび Web サーバーのログで不審なアクティビティを確認してください next-action または rsc-action-id ヘッダーを含む POST リクエストを探してください アプリケーションサーバーで予期しないプロセス実行やファイル変更を確認してください アプリケーションが侵害された可能性があると思われる場合は、 インシデント対応の支援について直ちに AWS サポートケースを開いてください 。 注: マネージド AWS サービスを使用しているお客様は影響を受けず、対応は不要です。 侵害指標 (IoC) ネットワーク指標 next-action または rsc-action-id ヘッダーを含むアプリケーションエンドポイントへの HTTP POST リクエスト $@ パターンを含むリクエストボディ "status":"resolved_model" パターンを含むリクエストボディ ホストベース指標 偵察コマンド ( whoami 、 id 、 uname ) の予期しない実行 /etc/passwd の読み取り試行 /tmp/ ディレクトリへの不審なファイル書き込み (例: pwned.txt ) Node.js/React アプリケーションプロセスによって生成された新しいプロセス 脅威アクターのインフラストラクチャ IP アドレス, アクティビティ日, 攻撃主体 206[.]237.3.150, 2025-12-04, Earth Lamia 45[.]77.33.136, 2025-12-04, Jackpot Panda 143[.]198.92.82, 2025-12-04, 匿名化ネットワーク 183[.]6.80.214, 2025-12-04, 攻撃主体不明の脅威グループ 追加リソース AWS セキュリティ速報: CVE-2025-55182 https://aws.amazon.com/security/security-bulletins/AWS-2025-030/ AWS WAF ドキュメント: https://docs.aws.amazon.com/waf/ React チームセキュリティアドバイザリ: https://react.dev/blog/2025/12/03/react-server-components-security-advisory ご質問がある場合は、 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 の 中島 章博 が翻訳しました。

こんにちは、プロトタイピングソリューションアーキテクトの 市川です。本日は AWS Summit 2025 や IoT@Loft にもご登壇いただいたブラザー工業株式会社で IoT プラットフォームの開発・運用に携わっていらっしゃるP&S事業 SC開発部の瀧尻 氏と 墨 氏 にお時間をいただき、イベントでは語りきれなかった Deep な話について質問させていただきました。 自己紹介 市川: 本日はよろしくお願いします。イベントの動画やスライドでも紹介されていますが、簡単にお二人の自己紹介をお願いできますでしょうか？ 瀧尻: 新 IoT プラットフォーム開発のプロダクトオーナーを務めました。チームメンバーに恵まれ、とても充実した開発を経験できました。数多くの設計判断をしましたが、”理由さえ残せば、あとでチームとともに修正できる”というスタンスで臨みました。コードよりもドキュメントや ADR・Wiki ページを 10 倍書きました。 墨: 開発・実装担当として、IoT プラットフォームの開発に携わりました。運用フェーズに移行してからは、プロダクトオーナーを継承し、DevOps による改善を続けています。まだまだエンジニア歴は浅いですが、「AWS のサーバーレスサービスを組み合わせれば、本番システムの開発も怖くない」と感じるようになりました。 IaC による属人化排除とリソース管理の工夫 市川: セッションでのお話で特に印象的だったのが、IaC(CDK) によるデプロイに制限することで属人化を排除されている取り組みですが、そのように決めた経緯について教えていただけますか？ 瀧尻: つくった IoT プラットフォームを様々な事業・用途で使ってもらうためには、どのように各事業に提供すればよいか、ということを考えました。手動作業が多いと導入の敷居が高くなる上、導入先ごとの差分や予期しない変更が発生してしまうおそれがあります。なるべくコマンド1つでまったく同じ構成のものを一式デプロイできることが望ましいです。そこで、CDK を利用して IoT プラットフォーム一式を構成し、配布できるようにしました。CDK には TypeScript を採用したので、AWS Lambda 関数の実装言語とも統一できました。 市川: 複数の環境を管理する場合は、IaC 化をすることで、プラットフォームごとに差分が出ずに管理ができますからね。IoT プラットフォームでは、全体のアーキテクチャのような比較的固定的な部分と、Thing や証明書のように随時増えていくリソースがあると思いますが、どの範囲を IaC で管理され、増えていくリソースはどのように管理されているのか、詳しく教えていただけますか？ 瀧尻: 私たちは大きくコントロールプレーンとデータプレーンに分けて考えています。 まずコントロールプレーンについては、3つのレベルで管理を分けています。どのような用途・環境であっても共通 IoT プラットフォームとして構成を強制する部分は CDK で管理、用途ごとに調整可能にするものは CDK + 環境変数で管理、そして事業や用途・デプロイした環境ごとに運用上異なるものは CDK 外での手動設定としています。また AWS Organizations によって AWS アカウントに適用される構成設定もあります。 一方のデータプレーンについては、事業・用途・環境ごとに運用者が管理する形にしています。 具体的には、まず CCoE が管理する AWS Organizations により AWS Security Hub、Amazon GuardDuty 、AWS CloudTrail 、Amazon Inspector などの設定が AWS アカウント単位で適用されます。 IoT プラットフォームとしての IaC 管理には、 AWS IoT Core のルール、Thing に付与するポリシー、Amazon API Gateway、AWS Lambda 、Amazon DynamoDB、Amazon SNS、Amazon S3、AWS Identity and Access Management (IAM)、AWS Config、Amazon CloudWatch などの構成定義を含めています。 IaC 管理しつつ環境変数で調整可能にしているのは、ステージ名や環境識別子プレフィクス、AWS Lambda メモリサイズ、出力ログレベル設定、Amazon DynamoDB や Amazon CloudWatch Logs の TTL・保持期間、そして一部機能のオンオフ（データ基盤連携、ログへの本文ダンプ有無など）です。 IaC 管理外で手動運用としているのは、開発者のロール、Amazon Route53 ドメイン・ACM 証明書、AWS IoT Core に登録する CA 証明書、API Key などの認証情報、異常通知の通知先、外部システムが Amazon SNS トピックをサブスクライブするポリシー設定、Cost Anomaly Detection や AWS Budgets 設定、そして Amazon CloudWatch Dashboards などがあります。 データプレーンについては、運用に伴い増加・変動するものとして、Thing、Thing証明書、Device Shadow の内容、一時クレデンシャルやトークン、IoT Job、Amazon DynamoDB の内容（コマンド履歴、デバイスの通知設定など）、各種ログ、メトリクス値などがあり、これらは IaC 管理外としています。 市川: なるほど、コントロールプレーン、データプレーン で分けるという観点は良いですね。それに加えて組織という単位でも分かれるという考え方は、とても参考になります。 事業部に提供した後の運用はどのように行われているのでしょうか？ 墨: 開発は SC 開発部の IoT プラットフォーム開発チームが専任で行い、定期的に社内にリリースしています。導入先の事業ごとに、リリースバージョンを指定して CDK 一式を取得(git clone) し、それぞれの IoT プラットフォーム用 AWS アカウントへデプロイします。なお、P&S 事業用の IoT プラットフォームの運用は、DevOps として私たち開発チームが担当しています。 事業ごとに開発されるサービスサーバーとの独立性を保つために、1システム – 1アカウントの原則を採用し、事業ごとの IoT プラットフォームはサービスサーバーとは別の AWS アカウントを使用します。各導入先での、IoT プラットフォームそのものの改造・変更は禁止しており、手順に従い CDK 一式をそのままデプロイしてもらっています。AWS Config ルールによりAWS CloudFormation のドリフトを検出する機構も CDK による定義に含めているため、意図せず、手動でリソースの設定などを変更してしまった場合にも気付くことができます。仕様や機能の要望があれば、IoT プラットフォーム開発チームが交流と発展のチャンスとばかりに飛びつき、対応しています。 遠隔からの印刷を実現する仕組み 市川: IoT プラットフォームで提供されている仕組みについてお聞きしたいのですが、実は我が家では御社のプリンターを利用していまして、受験を控えた子どもの問題集の印刷など、さまざまなサイズや用途の印刷に対応していて大変重宝しています。課題とかで写真の印刷も必要な時に、スマートフォンからの印刷をすることも多いのですが、反応が非常に速いのでどのような仕組みなのか気になっていました。このようなリモート印刷は IoT@Loft で紹介いただいた過疎地域の新聞印刷の取り組みでも活用されているとのことですが、他にもこの仕組みは利用されているのでしょうか？ 墨: 外出先からオフィスのプリンターへレポートを送ったり、遠方に住むご家族へ写真を送ることもできます。また、LINE から印刷することもできます。ここではメール添付印刷を例に内側をご紹介します。 まず、E メールで送られたデータをリモート印刷システムが受信し、IoT プラットフォームに対してリモート印刷指示を出します。IoT プラットフォームは、プリンターがサブスクライブしている MQTT トピックへその指示を Publish します。プリンターはそれを即時受信し、印刷データをダウンロードしながら印刷します。つまり、大きな印刷データを全て受信し終える前に動きはじめます。印刷し終えると、プリンターは HTTP API により、IoT プラットフォームへ印刷結果を通知します。 このように、即時性が重要なクラウド側からデバイスへの指示伝達には、MQTT の常時接続を用いています。 市川: AWS IoT Core が対応している MQTT は常時接続のプロトコルですので、あの反応の速さにつながっているんですね。リモート印刷との相性がとても良いように思います。 大規模IoTデバイス管理におけるコスト最適化 市川: IoTのユースケースでは大量のデバイスがつながることが多いと思いますが、コストに関してなにか工夫をされていることはありますか？ 墨: 一度作ったシステムをそのまま維持するのではなく、より最適化できないかという視点を持ち続けるようにしています。その一環として、AWS の SA や TAM から情報をいただいたり、AWS の News Update の RSS を Slack で購読するなどして、関係しそうな新サービス・新機能をチームでウォッチしています。 デバイスの MQTT 接続状態を正確に把握することは意外と難しく、従来はデバイスが Shadow に明示的に状態を記録し、不慮の切断時は LWT により状態を更新する、という仕組みをとっていました。しかし、この仕組みの場合は、接続状態の更新の度に様々な処理が動くため、コストの面でも気になっていました。2024/12に AWS IoT Core の接続ステータスクエリ API が発表され、これは何だろうか？とチームで調査しました。AWS IoT Core がデバイスの正確な MQTT 接続状態を提供してくれる機能であることがわかり、チームを挙げてこれを利用した内部構造への改良を行いました。コストダッシュボードでも、この仕組みを導入したタイミングの前後で、AWS IoT Core 関連コストの減少が観測できました。 市川: 新しい機能を積極的に取り込んでいただくことにより改善が進む良い事例ですね。ちなみに、コストダッシュボードとおっしゃいましたが、どのような監視をされているのでしょうか？ 瀧尻: システム全体の状況は AWS CloudWatch のダッシュボードを使って監視しています。上にビジネスメトリクス的なグラフを、下にいくほどシステムメトリクスや内部状況のグラフを配置して、全体を把握してから詳細を確認できる導線をつくりました。ダッシュボードには「登録デバイス台数」「MQTT 接続台数」「各 API リクエスト数」「レイテンシ」「各 AWS Lambda 呼び出し回数」「AWS Lambda 同時実行数」「エラー・Warn 発生数」、「各ロググループ記録容量」といったメトリクスのグラフを作成し、スクラムの朝会で一通り眺める習慣になっています。複数環境・アカウントありますが、AWS CloudWatch のクロスアカウント機能で1つのアカウントのダッシュボードに集約しました。 コストダッシュボードは、各環境のコスト推移を監視するために作成した AWS CloudWatch のダッシュボードのことです。1日ごとのコストの推移、コスト上位の主要なサービスの内訳推移、デバイス1台あたりの推定年間コストの推移、月次コストの推移をグラフ化しています。こちらは AWS CloudWatch 標準のメトリクスでないため、GitHub Actions を使って各環境の AWS Cost Explorer の情報を取得し、毎晩集約アカウントの AWS CloudWatch メトリクスに登録しグラフ化しています。IoT プラットフォームの設計時に目標とした1台あたりの年間コストがありますが、各環境、稼働開始直後のデバイス数が少ない時期は、メトリクスやアラーム、Amazon GuardDuty などのほぼ固定費な要素により割高になりますが、デバイス数の増加に伴い、目標コストのレンジに収束しています。 AWS Budgets を用いたコストアラートも各環境に設定し、意図しないコスト増があってもすぐに気付けるようにしています。 市川:  コストを下げる取り組みの基点として、AWS CloudWatch のダッシュボードを作って可視化を行っているのはとても良い取り組みですね。これらのダッシュボードを朝会でチェックされているとのことですが、どのような気づきがありましたか？ 墨: チームで定期的に取り組んでいるコスト最適化を、本番環境にデプロイした前後のコスト変化にはいつも着目しており、下がった際には皆で喜びます。また、リージョン障害やその後の段階的な復旧の様子も、ひと目で確認できます。加えて、地域ごとのイベントや長期休暇のシーズンには、接続数やアクセス数に変化がみられます。販売のキャンペーン期間には、新規の登録台数が増加する様子も確認できます。グラフの期間を変えることで、短期と長期の変化や傾向を把握でき、しばしばチームで課題探索や将来予想にも活用しています。 さいごに 本日は貴重なお話をありがとうございました。IaC による運用の標準化から、大規模 IoT デバイスの管理、そしてコストの監視と、非常に参考になるお話をお聞かせいただきました。 特に印象的だったのは、プラットフォームを提供する側として、いかに事業部が使いやすく、かつ管理しやすい仕組みを構築されているかという点です。また、継続的な改善とコスト最適化への取組みも、多くの AWS 利用者にとって参考になる事例だと思います。 今後もブラザー工業様の IoT プラットフォームの進化に注目していきたいと思います。 参考： AWS Summit Tokyo 2025 オフィス機器から産業機器まで多様な製品群に対応する IoT プラットフォームの構築：長期運用を目指し、アジャイルで小さく始める設計 AWSブログ IoT@Loft #27 AI時代にIoTを語れ！【祝】AWS IoT Core 10周年レポート【開催報告＆資料公開】 ブラザー工業様登壇：未来へつなぐ IoT ～IoT でモノはもっと価値をもつ～