2024 年 6 月に MLflow を搭載した Amazon SageMaker AI を発表 して以来、弊社のお客様は MLflow トラッキングサーバーを使用して 機械学習 (ML) と AI 実験のワークフローを管理してきました。この基盤を基に、MLflow のエクスペリエンスを進化させて、実験をさらに利用しやすくしています。 2025 年 12 月 2 日、 MLflow を搭載した Amazon SageMaker AI に、インフラストラクチャ管理が不要なサーバーレス機能が含まれるようになったことを発表できたことを嬉しく思います。この新しい MLflow 機能により、キャパシティプランニングが不要になる自動スケーリングにより、実験の追跡を即時のオンデマンドエクスペリエンスに変換できます。 ゼロインフラストラクチャ管理への移行は、チームの AI 実験へのアプローチ方法を根本的に変えます。インフラストラクチャを計画しなくてもアイデアをすぐにテストできるため、より反復的で探索的な開発ワークフローが可能になります。 Amazon SageMaker AI および MLflow の開始方法 最初のサーバーレス MLflow インスタンスを作成する手順を説明します。 Amazon SageMaker AI Studio コンソール に移動して MLFlow アプリケーションを選択します。 MLflow アプリ という用語は、以前の MLflow 追跡サーバー の用語に代わるもので、単純化されたアプリケーション重視のアプローチを反映しています。 ここで、デフォルトの MLflow アプリケーションがすでに作成されていることがわかります。このように単純化された MLflow エクスペリエンスにより、実験を始めるのがより簡単になりました。 [MLflow アプリを作成] を選択し、名前を入力します。ここでは、 AWS Identity and Access Management (IAM) ロール と Amazon Simple Storage Service (Amazon S3) バケットの両方がすでに設定されています。必要な場合にのみ、 詳細設定 で変更する必要があります。 ここで、最初の大きな改善点が明らかになります。作成プロセスは約 2 分で完了します。この即時可用性により、インフラストラクチャ計画の遅延なしに迅速な実験が可能になり、以前は実験ワークフローを中断していた待ち時間がなくなります。 作成後、ノートブックから接続するための MLflow Amazon リソースネーム (ARN) が届きます。管理がシンプルなため、サーバのサイジングの決定やキャパシティプランニングが不要になります。異なる構成を選択したり、インフラストラクチャの容量を管理したりする必要がなくなったため、実験に完全に集中できます。MLFlow SDK の使用方法については、 「Amazon SageMaker デベロッパーガイド」の「MLFlow をお客様の環境と統合する」 を参照してください。 MLflow 3.4 のサポートにより、 生成 AI 開発の新しい機能にアクセスできるようになりました。MLflow Tracing は、開発ライフサイクル全体にわたって詳細な実行パス、入力、出力、メタデータをキャプチャし、分散型 AI システム全体で効率的なデバッグを可能にします。 この新機能では、 AWS Resource Access Manager (AWS RAM) 共有によるクロスドメインアクセスとクロスアカウントアクセスも導入されています。このコラボレーションの強化により、異なる AWS ドメインやアカウントのチームが MLflow インスタンスを安全に共有できるようになり、組織のサイロ化が解消されます。 連携のメリット: パイプライン統合 Amazon SageMaker Pipelines は MLFlow と統合されています。SageMaker Pipelines は、 機械学習オペレーション (MLOps) と大規模言語モデルオペレーション (LLMOP) の自動化を目的として構築されたサーバーレスワークフローオーケストレーションサービスです。これは、本番稼働環境での ML および LLM モデルの展開、モニタリング、管理の実践です。直感的なドラッグアンドドロップ UI または Python SDK を使用して、反復可能なエンドツーエンドの AI ワークフローを簡単に構築、実行、モニタリングできます。 パイプラインから、デフォルトの MLflow アプリがまだ存在しない場合は作成されます。テスト名を定義すると、コードの定義に従ってメトリクス、パラメーター、アーティファクトが MLflow アプリに記録されます。MLflow を搭載した SageMaker AI は、 SageMaker AI JumpStart や Model Registry などの使い慣れた SageMaker AI モデル開発機能とも統合されているため、データ準備からモデルのファインチューニングまで、エンドツーエンドのワークフロー自動化が可能になります。 知っておくべきこと 留意点は以下のとおりです。 価格 — 新しいサーバーレス MLflow 機能は追加費用なしで提供されます。サービス制限が適用されることに注意してください。 可用性 – この機能は現在、米国東部 (バージニア北部、オハイオ)、米国西部 (カリフォルニア北部、オレゴン)、アジアパシフィック(ムンバイ、ソウル、シンガポール、シドニー、東京)、カナダ (中部)、欧州 (フランクフルト、アイルランド、ロンドン、パリ、ストックホルム)、南米 (サンパウロ) の AWS リージョンでご利用いただけます。 自動アップグレード: MLflow インプレースバージョンアップグレードは自動的に行われるため、手動での移行作業や互換性の懸念なしに最新の機能にアクセスできます。このサービスは現在 MLflow 3.4 をサポートしており、強化されたトレース機能を含む最新機能にアクセスできます。 移行サポート — mlflow-export-import で利用できるオープンソースの MLflow エクスポート/インポートツールを使用すると、既存のトラッキングサーバーから SageMaker AI、セルフホスト、その他の方法でサーバーレス MLflow (MLflow アプリ) に移行できます。 Amazon SageMaker AI Studio にアクセスして初めての MLflow アプリケーションを作成し、サーバーレス MLFlow を使い始めまることができます。SageMaker Unified Studio ではサーバーレス MLflow もサポートされているため、ワークフローの柔軟性が高まります。 よい実験を! – Donnie 原文は こちら です。

2025 年 12 月 2 日、 Amazon Simple Storage Service (Amazon S3) を使用して、 Amazon FSx for NetApp ONTAP 内のデータにアクセスできるようになったことを発表しました。この機能により、企業内のファイルデータを活用して、 検索拡張生成 (RAG) 用 Amazon Bedrock のナレッジベース による生成 AI アプリケーションの拡張、 Amazon SageMaker を用いた 機械学習 (ML) モデルのトレーニング、Amazon S3 と統合されたサードパーティサービスによるインサイト生成、 Amazon Quick Suite などの AI 搭載ビジネスインテリジェンス (BI) ツールでの包括的なリサーチ、さらに Amazon S3 を基盤としたクラウドネイティブアプリケーションによる分析を実行できます。これらすべてを、ファイルデータを FSx for NetApp ONTAP ファイルシステム内に保持したまま行うことが可能です。 Amazon FSx for NetApp ONTAP は、データの管理方法を変更することなく、NetApp ONTAP やその他の ネットワークアタッチドストレージ (NAS) アプライアンスに依存するオンプレミスアプリケーションを AWS に移行できる、クラウド初の完全 AWS マネージド型 NetApp ONTAP ファイルシステムです。FSx for NetApp ONTAP は、ONTAP ファイルシステムの一般的な機能、高パフォーマンス、データ管理 API に加えて、管理の簡素化、オンデマンドのスケーリング、他の AWS サービスとのシームレスな統合など、AWS クラウドの利点も提供します。 長年にわたり、AWS は Amazon S3 のデータを扱う業界をリードする AI、ML、分析サービスとアプリケーションを幅広く開発してきました。これらのサービスやアプリケーションを使用することで、組織はより迅速にイノベーションを起こし、新しいインサイトを発見し、より優れたデータ主導型の意思決定を行うことができます。ただし、NetApp ONTAP やその他の NAS アプライアンスに保存されているエンタープライズファイルデータでこれらのサービスを利用したいと考える組織もあります。 開始方法 S3 Access Point は、 Amazon FSx コンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS SDK を使用して作成し、FSx for ONTAP ファイルシステムにアタッチできます。 ONTAP ファイルシステムの demo-create-s3access 用既存の FSx があります。これは FSx for ONTAP ドキュメントの「ファイルシステムの作成」 の手順に従って作成しました。Amazon FSx コンソールを使用して、ファイルシステム ID fs-0c45b011a7f071d70 を選択して、ファイルシステムのすべての詳細にアクセスできるようになりました。 アクセスポイントをファイルシステムのボリュームに接続します。ボリューム vol1 を選択し、 [アクション] ドロップダウンメニューから [S3 Access Point を作成] を選択します。 アクセスポイント名 、 ファイルシステムユーザ ID のタイプ 、 ネットワーク設定 などの詳細を入力し、 [s3 Access Point を作成] を選択してプロセスを終了します。 作成が完了すると、アクセスポイント my-s3-accesspoint を使用して、Amazon S3 から自分のファイルシステム demo-create-s3access に保存されているファイルデータにアクセスできるようになります。 Amazon アクセスポイント は、Amazon FSx ボリュームにアタッチして Amazon S3 オブジェクトオペレーションを実行するために使用できる S3 エンドポイントです。 これで、ファイルシステム demo-create-s3access に保存されている所有データを Amazon S3 に持ち込んで、Amazon S3 と連携するアプリケーションで使用できるようになりました。ただし、ファイルデータはアクセスポイント my-s3-accessspoint を使用して FSx for NetApp ONTAP ファイルシステムに引き続き格納されます (このデータにはファイルプロトコルを通じて引き続きアクセスできます)。 この記事のウォークスルーでは Quick Suite と統合します。 何十年にもわたるエンタープライズファイルデータを、AWS 上の AI を活用した最新の BI ツールと統合 Quick Suite Console の左側のナビゲーションペインで [接続] を選択し、 [統合] を選択します。開始する前に、Amazon S3 AWS リソースに対する正しいアクセス権限があることを確認します。Quick Suiteが アクセスできる AWS リソースは、「 Amazon Quick Suite ユーザーガイド 」に従って管理できます。 Amazon S3 統合 を選択したら、 S3 バケット URL として Amazon S3 Access Point のエイリアスを入力し、残りの情報はデフォルトのままにして、 [作成して続行] を選択します。 ナレッジベースの 名前 と 説明 を入力してプロセスを終了し、 [作成] を選択します。 ナレッジベースが作成されると、自動的に同期され、インタラクションが可能になります。 AWS European Sovereign Cloud について詳しく知りたいので、このトピックに関する AWS ホワイトペーパーでファイルシステム (S3 Access Point my-s3-accesspoin-iyytkgz83djdjj7abn3u711supfgkuse1b-ext-s3alias ) を更新しました。Amazon Quick Suite のチャットで、最初の質問「 欧州のソブリンクラウドに関する文書はありますか? 」を始めます。私の質問に答えるために、 チャットエージェントは、私が使用権限を持っているさまざまなタイプのデータソースにアクセスして分析します 。その中には、現在の会話でアップロードされたファイル、アクセスできるスペース、統合のナレッジベースがあります。 ソースを確認すると、ファイルシステムにアップロードしたドキュメントがソースの 1 つとしてリストされていることがわかります。 Amazon FSx for NetApp ONTAP 用 Amazon S3 Access Points のその他のユースケース 先ほど、組織独自のファイルデータを Amazon Quick Suite に接続して高度なビジネスインテリジェンスを実現するなどのユースケースについて説明しました。さらに、Amazon FSx for NetApp ONTAP の Amazon S3 Access Points を使用すると、エンタープライズファイルデータを、 サーバーレス SQL クエリ用の Amazon Athena や ETL 処理用の AWS Glue などの包括的な分析サービスとシームレスに統合できます。 Amazon FSx for NetApp ONTAP の Amazon S3 Access Points は、設定ファイル、参照データ、コンテンツライブラリ、モデルアーティファクト、アプリケーション資産などの共有エンタープライズデータセットへの柔軟なアクセスを必要とする、コンテナ化されたマイクロサービスを備えたクラウドネイティブな サーバレス コンピューティングワークロードからのデータアクセスにも適しています。 今すぐご利用いただけます Amazon FSx for NetApp ONTAP ファイルシステムへの Amazon S3 Access Points のアタッチは、Amazon FSx コンソール、AWS CLI、または AWS SDK を使用して今すぐ開始できます。この機能が利用できる AWS リージョン は、アフリカ (ケープタウン)、アジアパシフィック (香港、ハイデラバード、ジャカルタ、メルボルン、ムンバイ、大阪、ソウル、シンガポール、シドニー、東京)、カナダ (セントラル、カルガリー)、欧州 (フランクフルト、アイルランド、ロンドン、ミラノ、パリ、スペイン、ストックホルム、チューリッヒ)、イスラエル (テルアビブ)、中東 (バーレーン、UAE)、南米 (サンパウロ) 、米国東部 (バージニア北部、オハイオ) 、および米国西部 (カリフォルニア北部、オレゴン) です。Amazon FSx の標準料金に加えて、S3 Access Points 経由のリクエストとデータ転送に対する Amazon S3 料金が請求されます。詳細については、 Amazon FSx for NetApp ONTAP の料金ページ をご覧ください。 追記: AWS でのブログ記事の執筆は、常にチームとしての取り組みです。これは、記事のタイトルの下に 1 人の名前しか表示されない場合でも同様です。今回は、テクニカルガイダンスでの専門知識と惜しみない援助を提供してくれた Luke Miller に感謝の意を述べたいと思います。この包括的な概要をまとめることができたのは同氏のおかげです。 – Veliswa Boya 。 原文は こちら です。

アマゾン ウェブ サービス ジャパン（以下、AWS）は 2025 年 11 月 11 日に、「【EdTech Meetup】 AI 時代の EdTech ～プロダクト・開発・運用の変革と EdTech の未来～」を AWS Startup Loft Tokyo にて開催しました。 AI 技術の急速な発展により大きな変革期を迎えている教育テクノロジー（EdTech）分野について、ユニファ株式会社、スタディポケット株式会社、ビズメイツ株式会社からのライトニングトークとパネルディスカッションを通じて議論を深めました。 EdTech スタートアップ、教育関係者、テクノロジー企業など、多様な参加者が70名以上集まり、知見の共有と交流を深める場となりました。本ブログではそのレポートをお届けします。 オープニング AWS パブリックセクター 教育・研究事業本部 事業本部長 白石 智良 「一年前の EdTech Meetup では『生成 AI という言葉が当たり前になってきました』と言っていましたが、もうそれから一年経ち、完全に日常に生成 AI が入っています。教育業界における生成 AI と人間の関係性、学習の個別最適化、導入時の障壁や運用コストの最適化など、重要なテーマについて、進的に取り組んでいる企業の CxO から様々な事例や取り組みをご紹介いただき、懇親会で皆様と意見交換できればと思います。」と挨拶しました。 ライトニングトーク① : ユニファ株式会社 ユニファ株式会社 執行役員 CPO プロダクトデベロップメント本部 本部長 兼 AI 開発推進部 部長 山口 隆広 氏 ユニファ株式会社は、ICT・IoTを活用した業務負荷削減と、ドキュメンテーションによる振り返り支援の観点から、こどもともっと向き合う豊かな環境を整える保育施設向け総合 ICT サービス「ルクミー」を展開しています。 「保育 AI」の取り組みでは、「保育士さんの業務負担の軽減だけが問題ではなく、こどもの安全や成長のサポートも重要」と強調。具体的な AI 活用事例として以下を挙げました： 若手保育士の育成支援: 連絡帳の誤字脱字チェックに AI を活用することで、本質的な保育の指導に時間を使えるようになった。 写真管理の効率化: 保育園の多くは一回のイベントで約1000〜2000枚の写真を撮影するが、AI を使ってこどもの顔認識や不適切な写真のフィルタリング、こどもごとの枚数のバランス調整などを効率化できるようになりつつある。 記録の活用: 従来は紙のファイルに保存されていた保育記録をデータ化し、AI 経由で他の先生が参照できるようにすることで、引き継ぎなどに役立てられるようになった。 山口氏は、AI の導入には当初反発もあったことを振り返り、「保育士の先生だからできる大事なところはたくさんあります。ただ、誤字脱字や文章の修正など、先生が頑張るべきことではない部分は AI に任せましょう。」という考え方で理解を得てきたと説明しました。また、国や自治体が AI の活用を推進する姿勢を示すことが、現場での導入を促進する上で重要だと指摘しました。 ライトニングトーク② : スタディポケット株式会社 スタディポケット株式会社 代表取締役 CPO 鶴田 浩之 氏 スタディポケット株式会社は、学校・教育機関向けに、セキュアな環境で簡単に導入できる生成 AI サービスを提供しています。 鶴田氏は、「答えを教えない AI 」というコンセプトでハッカソンに参加したところ、学校現場からの反響を受けて、スタディポケットが誕生したという経緯を紹介しました。 「スタディポケットが提供するソリューションの特徴は、教員向けのソリューションとこどもたちの学習をサポートするソリューションの二つが表裏一体になっていることです。生成 AI としては、Amazon Bedrock で Anthropic の Claude モデルなどを利用しています。それにより、先生たちはセキュアな環境で、こどもたちは安心安全に使えるガードレールを整備した環境で生成 AI を利用できています。」 「教員向けソリューションで特に反響が大きかったのは、学校の先生特有のプロンプトのテンプレートを40～50種類用意し、プロンプトエンジニアリングの知識がなくても直感的に AI を使えるようにしたこと。また13歳未満の利用についてのルールを早期に定めました。」 「答えを直接教えないという、考えに伴走していくというコンセプト」を初期から打ち出していたことが、AI を用いたサービスが受け入れられた要因だと分析しています。学校の伴奏支援も必要で、「ただ導入しただけだと全然使わない」という課題に対しては、ワーキンググループを作るなど、きめ細やかなサポートの重要性を強調しました。 ライトニングトーク③ : ビズメイツ株式会社 ビズメイツ株式会社 IT本部 本部長 兼 CTO 林 哲也 氏 ビズメイツ株式会社は、「もっと多くのビジネスパーソンが世界で活躍するために」というミッションのもと、ビジネス特化型オンライン英会話サービス「Bizmates」を主力として、ビジネス日本語教育やグローバル人材マッチングなど複数のサービスを提供しています。 ビズメイツは、「日常会話を幅広く学ぶより、使用シーンが限られるビジネス英語に特化することは学習の近道になる」という考えのもと、創業以来ビジネスに特化した英語教育を提供しています。現在では、AI によって「受講生の業種、職種、状況に特化した最適な英語教材を生成」「受講生のオンライン英会話レッスン音声の AI データ解析を基にした英語学習コーチングを提供」と更に学習体験のパーソナライズ化が進んでいます。 ハイブリッド型英語学習の特長として、アプリでの自習（インプット）、人間のコーチによる伴走・動機づけ、対人のオンライン英会話でのアウトプット、AI と人それぞれの強みを組み合わせていることを挙げ、この中での AI 活用例として業種・職種・シーン別に学習者ごとに最適化したロールプレイの生成、発音評価、レッスン音声の分析などを紹介しました。 開発面では、要件定義から実装、テストまでの開発ライフサイクル全体で AI を活用し始めていると説明しました。FuelPHP から Laravel への移行や Vue.js のバージョンアップなどの領域で、生成 AI を搭載した会話型アシスタント Amazon Q Developer などを活用しており、サービス提供と開発の両面で AI が活用できることを強調しました。 「AI によって個別最適な学習体験を提供する一方で、自走支援には人間による動機づけやコーチングも重要」とし、開発においても「AI は標準的な開発の生産性を上げ、人間は変革をする企画やレビューを行う。人間が AI と一緒になりながら、より良いサービスを開発していきたい」と今後の展望を示しました。 ライトニングトーク④ : AWS AWS パブリックセクター 技術統括本部 教育・研究技術本部 本部長 松井 佑馬 「AWS の AI ポートフォリオは、インフラ層（GPU等）、基盤モデル層（Amazon Bedrock等）、アプリケーション層の3つのレイヤーに分かれています。今日は、アプリケーション層の新しいサービスである『Amazon QuickSuite』について詳しく説明します。Amazon QuickSuite は、AI エージェントと一緒に働くことが普通になる中で、業務データを把握し素早く答えを出し、アクションにつなげられる AI エージェントを提供するサービスです。2025年10月に一般提供が開始されたばかりで、ダッシュボード作成サービスである Amazon QuickSite に AI 機能を追加した発展版です。」 デモにて、チャットによるデータ探索、ドメインやチームごとの権限管理、タスクの自動化ワークフロー、複数データソースを参照したリサーチ機能をお見せしました。ユースケースの例として、営業担当者が商談の議事録から日報を作成し、Slack に投稿するという一連の流れを AI に自動化させる例を紹介。このサービスはデベロッパー向けではなく、ビジネスユーザーが自然言語で定義できることが特徴だと強調しました。 パネルディスカッション ＜モデレーター＞ AWS パブリックセクター 教育・研究事業本部 アカウントマネージャー 尾島 菜穂 ＜パネリスト＞ スタディポケット株式会社 代表取締役 CPO 鶴田 浩之 氏 ビズメイツ株式会社 IT本部 本部長 兼 CTO 林 哲也 氏 ユニファ株式会社 執行役員CPO プロダクトデベロップメント本部 本部長 兼 AI開発推進部 部長 山口 隆広 氏 AWS パブリックセクター 技術統括本部 教育・研究技術本部 本部長 松井 佑馬 AI と人間の最適な役割分担 山口氏（ユニファ）：「保育の専門性は AI に持たせない」という方針。こどもの表情一つをとっても、笑顔の裏に嫌なことがあって笑う癖がある子もいるなど、AI では判断できない専門性が存在するからです。そのため、AI の役割は「先生が活かせるデータを簡単に集めること」に限定。若手保育士の育成においても、AI が生成した情報を「正解だと思い込んでしまう」リスクを避けるため、あえて使わない判断をしています。 鶴田氏（スタディポケット）：教員へのアプローチとして「働き方改革」よりも「授業の質が高められる」という点を強調すると興味を持ってもらえます。教師の役割は変わっても無くならず、教室の「コミュニティマネージャー」のような存在になっていくと予測しています。また、こどもたちが AI を使うことで、自分で応用問題に挑戦したり、苦手な単元をキャッチアップできるようになり、結果的に「こどもたちが使った方が先生の働き方改革になる」という効果も生まれています。 林氏（ビズメイツ）：AI によって「何を覚えるべきか」が変わってきています。翻訳ツールにより「英語を覚えなくても会議ができる」時代になりつつあるが、最終的には「人間として人間に伝える」ことが重要であり、「英語を教えるのではなく、グローバルで活躍できるビジネスのやり方を教える」という人間の役割を重視しています。 AI のコスト課題と工夫 鶴田氏（スタディポケット）：一般企業に比べて、教育業界の予算が少ないことに驚きました。公立学校向けには、月額ではなく年間2,000〜3,000円を切る価格設定が必要です。高性能なモデルを初期に提供し、モデルの価格が下がるのを見越した戦略を取り、必要に応じてモデルを切り替えたり、キャッシュ技術を活用するなどのコスト最適化の工夫をしています。 林氏（ビズメイツ）：AI を使って顧客の利便性を高め、「その利便性に見合う付加価値」としてオプション価格をいただく形でコストを回収しています。コーチングサービスやモバイルアプリなど、新たな付加価値の中に AI のコストを含める形を取っています。 山口氏（ユニファ）：保育領域は予算が限られているところも多いので、テキスト処理などは無料で提供し、画像処理など負荷の重い処理は課金する形を取っています。写真販売などのビジネスモデルでマージンが増えるような AI 機能は無料で提供するなど、「間接的にいただく」工夫もしています。さらに、期待値をコントロールすることで価格を抑えたモデルでも満足してもらえるようにしていています。 松井（AWS）からは、技術的観点から、最適なモデルの使い分けやトークン節約のためのキャッシュ活用、コンテキスト圧縮などの工夫を紹介しました。 開発・運用での AI 活用 林氏（ビズメイツ）：フィリピンの子会社でも AI を導入しており、フィリピンのメンバーも「AI に発注して、作らせて、納品されたものをチェックする」という役割に変わりつつあります。そのためコードを書くエンジニアから要件定義や QA を担当する役割へのシフトが起きています。また、グローバルでは英語の情報が豊富なため、日本よりも AI 活用が進んでいる面もあります。 山口氏（ユニファ）：インフラ面では Amazon Q を活用している一方、アプリケーション開発ではエンジニアによって AI 活用度に大きな差があります。特に非エンジニア職種（QA エンジニアやデザイナー）の方がむしろ AI を積極的に活用し、「エンジニアに聞きづらかったことを AI に聞く」ことで成果を出している傾向があります。 鶴田氏（スタディポケット）：コードの8割が AI コーディングベースになっています。プルリクエストのコードレビューには複数の LLM を同時に走らせ、様々な観点からレビュー。また、私自身も AI と共にプロトタイピングを行うことで「2日で新機能を見せる」といった高速開発が可能になっています。 教育現場での導入障壁と克服策 鶴田氏（スタディポケット）：「活用する人としない人の差」が生まれることが課題。特に契約する主体（教育委員会など）と実際に使う主体（先生やこどもたち）が異なる中で、いかに満遍なく使ってもらうかが重要です。 山口氏（ユニファ）：保護者からの視線が障壁になることがあります。「保育士がスマホで連絡帳をチェックしていると、遊んでいると思われる」といった誤解が生まれうるため、「こどもの育ちをより分析し、保護者に伝えるために AI を使っている」というストーリー作りが重要です。 会場からの質問 質問「AI がジュニアエンジニアを代替しているという傾向は実感するか」 山口氏（ユニファ）：AI 活用に対してネガティブな人はエンジニア採用において「減点」になりつつあります。一方で「自分の方が優秀だから使わない」という人もいるが、それは現時点での能力なので、「インターネットと同様に使ってほしい」と考えています。 鶴田氏（スタディポケット）：むしろジュニアの方が AI を活用・吸収していて、「シニアでアンラーニングできない方がリスク」。20代前半の若手が AI で自己拡張している姿に「危機感を感じる」。 林氏（ビズメイツ）：AI が生成したものをレビューできるスキルが重要になるが、それができるシニアエンジニアの採用は簡単ではないため、「ジュニアエンジニアを採用して育てていく」ことが会社の使命だと思います。 質問「高校向けサービスで様々なアプリに AI が組み込まれ、ユーザーが混乱するのではないか」 鶴田氏（スタディポケット）：「AI は様々なものに大前提で入ってくる」、「インターネットのように空気のような存在になっていく」と予測しており、時間とともに情報リテラシーが育ち、成熟していくと思います。 質問「英語学習の AI 活用がコモディティ化している中での差別化」 林氏（ビズメイツ）：ビズメイツは「ハイブリッド学習」として、アプリでのインプット、人間のコーチによる伴走と動機づけ、オンライン英会話でのアウトプットを組み合わせることで、単なる AI 英会話ツールとは異なる価値を提供しています。 3年後のビジョン 山口氏（ユニファ）：「保育園・幼稚園などのデータを小学校に、小学校のデータを中学校に持っていけるようになれば、こどもの人生をもっと良くできる」ので、AI に合った法律整備に期待しています。 鶴田氏（スタディポケット）：スタディポケットは、ドラえもんのように、のび太に寄り添い、時に怒り、時に優しいサービスを目指しています。不登校だった生徒がスタディポケットを使って自分で勉強し、志望校に合格しています。多様な社会の中で、AI が幅広く機会を作り、黒子としてサポートできる存在になりたいです。 林氏（ビズメイツ）：3年後、今は人間がやらなければいけないと思われていることが AI でできるようになります。スピードがもっと上がることで、何を覚えるべきか、何を AI に任せるかの境目が変わると予想しています。 松井（AWS）：個人的見解だが、AI による社会変化は避けられないので、「AI に使われる人ではなく、AI を使いこなす人を育てる」という教育の役割が、ますます重要になると思います。 クロージング 最後は会場で懇親会が行われ、参加者同士の交流や登壇者との質疑応答など、活発な意見交換が行われ、AI 時代の教育について議論を深める貴重な機会となりました。 過去の EdTech Meetup に関しては、以下のブログをご参照ください： 【Edtech Meetup】教育×AI ～生成系 AI によって教育はどう変わるのか～【開催報告】 【Edtech Meetup】Edtech スタートアップがグローバルに活躍するには？【開催報告】 【Edtech Meetup】急成長サービスの秘訣と実践戦略【開催報告】 AWS パブリックセクターは今後も、EdTech がイノベーションを加速させるための、さまざまなテクニカル・ビジネスセッションやコミュニティ活動を実施予定です。ご関心をお持ちの方は、お気軽に お問い合わせ ください。教育のイノベーションに取り組まれる皆様のご参加をお待ちしております。 このブログは、 アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター ソリューションアーキテクト 伊達幸希が執筆しました。

本ブログは、NetApp Japan が主催する Amazon FSx for NetApp ONTAP Advent Calendar 2025 の 19 日目の記事です。 皆様は Amazon FSx シリーズと聞くと、ファイルストレージサービスを想起するのではないでしょうか？私もそんな一人です。しかし、FSx シリーズの 1 つである Amazon FSx for NetApp ONTAP (FSx for ONTAP) はブロックストレージとしても利用できます。 FSx for ONTAP は高性能なブロックストレージであるとともに、マルチ AZ やマルチリージョンの構成を容易に実現できます。本ブログでは FSx for ONTAP について振り返りながら、FSx for ONTAP のブロックストレージとしての特徴を確かめてみたいと思います。 FSx for ONTAP の特徴 利用できるプロトコル FSx for ONTAP では、第 1 世代のファイルシステムと第 2 世代のファイルシステムがあります。後者については、 こちら のブログを参照してください。 図 1: 利用できるプロトコル そのほか、Amazon S3 Access Point を利用した、HTTPS アクセスも東京と大阪リージョンの FSx for ONTAP でご利用いただけます。NetApp Japan の小寺さんが作成した本アドベントカレンダーの ブログ もご参照ください。 マルチ AZ とマルチリージョン FSx for ONTAP は、シングル AZ 構成でもマルチ AZ 構成でも同様に 2 台のファイルシステムから成る冗長構成を採用しています。また、どちらの構成においても NFS や SMB で指定する接続先の IP アドレスは、フェイルオーバーの前後で変わりません。一方で、iSCSI や NVMe-over-TCP アクセス先の IP アドレスは ENI ごとに存在します。そのため、FSx for ONTAP でフェイルオーバーが発生した場合には、クライアント側で接続先のパスを切り替える必要があります。 なお、ENI が存在する VPC 外部からマルチ AZ 構成の FSx for ONTAP へと NFS や SMB でアクセスする場合、AWS Transit Gateway が必要となります。詳しくは こちら のリンクをご参照ください。 図 2 FSx for ONTAP の構成。上がシングル AZ、下がマルチ AZ。 マルチリージョン構成を採用する場合、 SnapMirror を活用できます。SnapMirror を用いると、プライマリリージョンにある FSx for ONTAP のストレージボリュームからセカンダリリージョンのストレージボリュームへと、スナップショット単位でデータをレプリケーションすることができます。災害復旧やバックアップ、データ保護の目的で広く活用されており、ビジネス継続性の確保に重要な役割を果たします。初回は全データをコピーし、その後は差分のみを転送することで、ネットワーク帯域の効率的な利用を実現しています。 ストレージ容量の効率化 FSx for ONTAP は、次の 3 つの方法で、データ容量を効率化します。マネジメントコンソールでボリュームを作成する際に、一括で設定することができます。 重複排除 圧縮 コンパクション 図 3 マネジメントコンソール上でのストレージ容量の効率化設定 ストレージの階層化 FSx for ONTAP ではアクセス頻度に応じて、ブロック単位でパフォーマンス重視の SSD ストレージ階層から低コストのキャパシティプール層へとデータを移動します。 FSx for ONTAP でブロックストレージを構成 今回は東京リージョンにシングル AZ の FSx for ONTAP を構築し、同じ VPC 内の Amazon EC2 から NVMe-over-TCP でアクセスします。NVMe-over-TCP は第 2 世代のファイルシステムのみ利用可能ですので、マネジメントコンソールでは「シングル AZ 2」を選択します。 図 4 マネジメントコンソール上での設定 ファイルシステムが作成されたら、FSx for ONTAP のファイルシステムへと接続し、NVMe-over-TCP プロトコルを用いて、Amazon EC2 からマウントします。詳細な手順は こちら のドキュメントに従います。なお、FSx for ONTAP 側での準備が完了すると、次の図のように NVMe-over-TCP に対応したネットワークインタフェースが 2 つ表示されます。これらの IP アドレスは、 ストレージ仮想マシン （SVM）の iSCSI IP アドレスに対応しています。 図 5 FSx for ONTAP において、NVMe-over-TCP プロトコルを使用するネットワークインターフェース 第 2 世代のFSx for ONTAP では、スループットと IOPS はそれぞれ 6 GBps と 200,000 IOPS まで設定することができ、高いパフォーマンスが必要なワークロードにも利用できます。スループットと IOPS 以外にも、細かいファイル操作が必要なワークロードではレイテンシが重要となるケースがあります。そこで、本ブログではレイテンシを fio というツールを用いて検証してみました。 今回は単純なコマンドのみ実行します。書き込みブロックサイズは 4 KB または 16 KB とします。1 GB のファイルを、ランダムリードとランダムライトで処理を行った時のレイテンシを測定します。なお、今回はレイテンシの測定が目的なため、ジョブの並列度は 1 としました。4 KB のブロックサイズで 1 GB のファイルをランダムリードしたときのサンプルコマンドを記載します。 fio --name=test --ioengine=libaio --rw=randread --bs=4k --direct=1 --size=1G --numjobs=1 --runtime=60 --group_reporting --filename=/fsx/ontap/example1.dat また、本ブログでは性能の検証が目的ではないので厳密な議論は行いませんが、レイテンシが低いことが分かります。 図 6 レイテンシの測定結果。RR、RW はそれぞれランダムリード、ランダムライトの略。clat_p50/clat_p95/clat_p99 はそれぞれ、Completion Latency における 50/95/99 パーセンタイル。 マルチリージョン構成 東京リージョンと大阪リージョンでシステム構成を統一する場合には、iSCSI を用いたブロックアクセスも有効です。iSCSI の設定方法は こちら をご覧ください。 まずは東京リージョンで作成したボリュームに対して、iSCSI でクライアントからアクセスします。そして、iSCSI でブロックアクセスしたボリューム上に、「Hello world!」と記載した hello.txt を作成します。このファイルは後ほど大阪リージョンのボリュームへと転送し、大阪リージョンのクライアントからアクセスできることを確認します。 次に、東京リージョンの FSx for ONTAP のボリュームから、大阪リージョンの FSx for ONTAP のボリュームへと SnapMirror でデータをレプリケーションします。 図 7 マルチリージョン構成 SnapMirror を転送する流れは、次の通りです。詳細は こちら のドキュメントを参照してください。 送信元と送信先の FSx for ONTAP のファイルシステム間でピアリング関係を構築 送信元と送信先の SVM 間でピアリング関係を構築 SnapMirror 関係を構築 SnapMirror でデータをレプリケーション SnapMirror で全てのデータの転送が完了した後、snapshot show コマンドを実行すると、大阪リージョンのファイルシステムに「snapmirror」というスナップショットが転送されていることが分かります。これは東京リージョンのファイルシステムから転送されたスナップショットで、上記の「hello.txt」を含んでいるはずです。 図 8 スナップショットの確認 この後、SnapMirror 関係を停止します。そして、大阪リージョンの FSx for ONTAP のボリュームに対して、iSCSI でクライアントからマウントすることで、ボリューム中のファイルへとアクセスすることができます。例えば、東京リージョンの FSx for ONTAP のボリュームに作成した hello.txt ファイルは大阪リージョンのボリュームへも転送され、下図のようにアクセスすることができます。 図 9 大阪リージョンのボリューム中のファイルへとアクセス FSx for ONTAP は、SnapMirror によってネイティブにマルチリージョンレプリケーションを実現できます。これにより、通常の AWS ブロックストレージで必要な AWS Elastic Disaster Recovery やアプリケーション層での実装が不要となり、シンプルな構成でリージョン間レプリケーションが可能です。 まとめ FSx for ONTAP はファイルストレージだけでなく、ブロックストレージとしても活用することができます。NVMe-over-TCP を利用することで、低レイテンシかつ高い可用性が要求されるシステムにも対応することができます。また、東京リージョンと大阪リージョンで同様の構成を採用したい場合には、iSCSI をプロトコルに採用した上で、SnapMirror によるレプリケーションで実現できます。 本ブログが皆様のお役に立てれば幸いです。 佐藤真也 アマゾンウェブサービスジャパン合同会社 フィナンシャルサービス技術本部 ソリューションアーキテクト AWS のストレージサービス全般が好きで、AWS Black Belt オンラインセミナーなどのイベントへの登壇にも力を入れています。

本ブログは 株式会社 Nint 様 と Amazon Web Services Japan 合同会社 が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの森です。 デジタル市場の急速な変化に伴い、多くの企業が新しいプラットフォームやサービスへの対応を迫られています。特に SaaS 事業者にとって、市場の変化に迅速に対応しながら、既存システムの運用負荷を抑制することは重要な経営課題となっています。 従来の仮想マシンベースのインフラでは、サーバー管理やスケーリング対応に多くの工数を要し、開発チームが本来注力すべきビジネスロジックの実装に集中することが困難となります。また、新しいサービスの立ち上げの度に、インフラ構築から始める必要があり、市場投入までの時間が長期化してしまうという問題もあります。さらに、既存システムの技術的負債が蓄積し、属人化が進むことで、将来的な拡張性や保守性に不安を抱える企業も少なくありません。 今回ご紹介するのは、EC データ分析サービスを提供する株式会社 Nint 様が、AWS のマネージドサービスを活用したモダンなアーキテクチャを採用し、新しい EC プラットフォーム対応 SaaS を わずか 2 か月で開発、さらに運用工数を 70% 削減した事例です。 Nint 様の状況と課題 株式会社 Nint 様 は、データ分析サービスを提供している企業です。10 年以上前から AWS を活用してサービスを展開してきましたが、当時は現在ほど多様なマネージドサービスは提供されておらず、Amazon EC2 を中心としたインフラ構成で運用していました。そのような中で、近年急成長した EC プラットフォームである TikTok Shop への対応が急務となり、以下のような課題に直面していました： 既存環境の運用負荷 Amazon EC2 で構築された既存環境は、追加開発や日々のメンテナンスにおける負荷が高く属人化していた サーバー管理、スケーリング、リソース最適化などの運用作業に多くの工数を要していた 将来性への懸念 将来的に既存環境を刷新する計画もあり、保守性の高いアーキテクチャを採用した新環境での開発を検討していた グローバル展開を見据え、各国への展開が容易なアーキテクチャが求められていた スケーラビリティと保守性を両立できるアーキテクチャが求められていた これらの課題を解決するため、Nint 様は AWS のマネージドサービスを活用した新しいアーキテクチャでの開発に着手しました。 ※ 画面は実際のお客様データではなく、デモ用のサンプルデータを使用しております。 ソリューション Nint 様は、AWSのマネージドサービスを最大限活用し、以下のようなモダンなアーキテクチャを採用しました： 独立したネットワーク環境の構築 既存環境とは異なる Amazon VPC 上で新サービスを開発 既存環境とは VPC Peering で接続し、連携が可能なアーキテクチャを採用 コンテナ化とマネージドサービスの活用 フロントエンドおよびバックエンドの両方を AWS Fargate 上でコンテナ化し運用 Infrastructure as Code（IaC）の実装 AWS Cloud Development Kit (CDK)により、インフラのコード化（Infrastructure as Code : IaC）を実現 GitHub Actions を活用した CI/CD パイプラインにより、デプロイメントプロセスを自動化 10 通り以上のアーキテクチャパターンを比較検討し、最終的に拡張性と運用効率を両立できる最適な構成を選定しました。また、AWS CDK を活用した IaC 化により開発効率を向上させ、環境の再現性を容易にしました。さらに IDE の支援機能やバージョン管理システムとの連携により、複数の開発者が安心してインフラの変更を行える体制を構築しています。 導入効果 AWSのマネージドサービスを活用した新アーキテクチャの導入により、以下の効果が得られました： AWS のマネージドサービスを活用することで、わずか 2 か月という短期間で新サービスをリリースし、開発チームがインフラ構築ではなくビジネスロジックの実装に集中できる環境を実現 サーバー管理やスケーリング、リソース最適化といったメンテナンス作業が不要となり、AWS Fargate の自動スケーリング機能によるトラフィック変動への自動対応により、従来比で運用負荷を70%軽減 AWS CDK による IaC 化と GitHub Actions への移行により、環境構築・更新にかかる時間を最大 90%削減し、手離れの良い運用と新機能開発のスピードアップを達成 モダンなアーキテクチャの採用と属人化の解消により、将来の機能拡張や他のプラットフォーム対応への基盤を構築し、Amazon Bedrock を活用した生成 AI 機能によりデータ分析サービスに新たな価値を提供 お客様の声 AWS Fargate と AWS CDK の組み合わせにより、従来の EC2 ベースの環境では考えられなかった開発・運用の効率化を実現できました。特に、サーバー管理から解放されたことで、開発チームがプロダクトの価値向上に集中できるようになったことが最大の成果です。また、AWS CDK による IaC 化により、環境の再現性が格段に向上し、複数の開発者が安心してインフラの変更を行えるようになりました。TikTok Shop という新しい市場への迅速な対応が求められる中で、AWS のマネージドサービスの力を借りて短期間でのサービス立ち上げを実現できたことは、ビジネスの競争力向上に大きく貢献しています。 まとめ 本事例は、従来の EC2 ベースの環境から AWS のマネージドサービスを活用したモダンなアーキテクチャへの移行により、開発速度と運用効率を大幅に向上させた優れた事例です。AWS Fargate、AWS CDK などのサービスを組み合わせることで、短期間でのサービス開発と大幅な運用工数削減を同時に実現しました。特に注目すべきは、単なる技術的な改善だけでなく、急速に変化する市場への迅速な対応を可能にし、ビジネスの競争力向上に直接貢献している点です。また、将来的な環境刷新への布石としても機能しており、持続可能な成長基盤の構築に成功しています。コンテナ化や IaC を活用したモダンなアーキテクチャの導入、AWS が提供する様々なマネージドサービスの活用にご興味をお持ちの方は、お気軽にお問い合わせください。 株式会社 Nint（左から）： 姚 舒威様 河野 康裕様 真鍋 颯一朗様 矢後 志明様 横沢 裕大様   Amazon Web Services Japan : アカウントマネージャー 新井 豪（左端） ソリューションアーキテクト 森 瞭輔（右端） ソリューションアーキテクト 森

2025 年 11 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS サービス別資料集 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 Amazon Elastic VMware Service の概要 Amazon EVS は、オンプレミスの VMware ワークロードを AWS へ移行、モダナイゼーションする選択肢の1つで、リロケートに位置づけられているサービスです。本セミナーでは、Amazon EVS の特徴、技術的な概要についてご説明します。 資料（ PDF ） | 動画（ YouTube ） 対象者 オンプレミスの VMware 環境から AWS へ移行を検討している方 ダウンタイム最小化や IP アドレス維持など、移行における課題を抱えている方 既存の VMware スキルやノウハウを活用しつつクラウドのメリットを得たい方 本 BlackBelt で学習できること Amazon EVS の概要 Amazon EVS のビルディングブロック Amazon EVS の展開前の準備 Amazon EVS の料金 スピーカー 増田　雄紀 ソリューションアーキテクト 今更聞けない Amazon EC2 インスタンスの選択肢 Amazon EC2 インスタンスの新しい EC2 インスタンスの情報や、CPU、GPU の選択肢についてと、インスタンス選択で大切なことをお話しします。(2025 年 11 月時点の内容です) 資料（ PDF ） | 動画（ YouTube ） 対象者 EC2 インスタンスを選ぶとき、いつも同じインスタンスタイプを選んでいる方 オンプレミスからの移行でサイジングに悩んでいる方 最近の新しいインスタンスの特性をキャッチアップしたい方 本 BlackBelt で学習できること Flex、Fractional GPU インスタンスを含めた Amazon EC2 インスタンス選択の最新情報や、パフォーマンス分析やキャパシティ戦略など EC2 インスタンス選択で大切なことを学習できます。 スピーカー 寺部 祐菜 ソリューションアーキテクト AWS Security Hub CSPM AWS Security Hub CSPM AWS が提供する CSPM サービスである AWS Security Hub CSPM の概要と機能、活用法についてご紹介しています 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS Security Hub CSPM の利用を考えている方 AWS Security Hub CSPM がどのようなサービスか知りたい方 AWS Security Hub CSPM の各機能や運用方法について知りたい方 本 BlackBelt で学習できること AWS Security Hub CSPM の概要と各種機能について理解する AWS Security Hub CSPM の一般的な運用のプラクティスについて知る スピーカー 喜多 望 ソリューションアーキテクト Amazon Connect Salesforce 連携 (CTI Adapter で実現する CRM 連携のご紹介 ) Amazon Connect と Salesforce の連携を実現する Amazon Connect Salesforce CTI Adapter について、機能と活用方法をご紹介します。本コンテンツでは、CTI Adapter の基本機能から具体的なユースケース、さらには Lambda Package を活用した機能拡張まで、導入ポイントを解説します。 資料（ PDF ） 対象者 Amazon Connect ご利用中のエンドユーザー/パートナーの方 これから Amazon Connect のご利用を検討されている方 コンタクトセンターにおける CTI 連携にご関心をお持ちの方 Amazon Connect と Salesforce の CTI 連携を実現しようとされている方 本 BlackBelt で学習できること Amazon Connect Salesforce CTI Adapter と Lambda Package の実践的な活用方法を学んでいただけます。CTI 連携による顧客情報の一元管理、効率的なコールハンドリングの実現方法など、実務に直結する知識を習得できます。また、実装時の設定のポイントもご紹介します。 スピーカー 梅田 裕義 シニア Connect スペシャリストソリューションアーキテクト  

本記事は自治体向けシステムを展開する株式会社アイネスの運用本部管理部 田中翔氏、根岸亮太氏から寄稿いただいたものです。 背景 株式会社アイネスでは、自治体様の多岐にわたる業務を網羅する、豊富なラインナップを揃えた基幹業務パッケージシステム「WebRings」を全国の自治体様に提供しています。 自治体システムのガバメントクラウド移行を進める中で、私たちクラウド保守グループは 100 を超える膨大な数のアカウントを管理する必要性に迫られました。 しかし、アラームを人手で確認・調査する従来の仕組みでは、1 件あたりの対応に時間を要し、かつ経験者でないと調査が難しいため、これほど多くのアカウントを運用していくための人的リソースが非常に不足していました。 さらに、これらのシステムは同一のパッケージ及び、クラウド構成となっており、 アプリケーションの潜在的なバグやインフラ設定の不備により、複数の環境で同時に問題が起こる可能性が高いというリスクを抱えていました。 そのため、障害発生時に必要となる対応要員数が膨大になることが予測され、安定的な運用を維持することが困難でした。 これらの課題を根本的に解消し、限られたリソースで高品質な運用を維持するためには、運用の効率化が不可欠であり、生成 AI の活用を検討することとしました。 構築：Amazon Bedrock Agents を活用した AI エージェントの実装による障害分析 課題解決のため、私たちは AWS が公開していた「 FA2（Failure Analysis Assistant） 」を参考に、独自の障害原因自動分析機能「FA3（Failure Analysis Assistant Agent）」を実装しました。これは、エージェント版 FA2 を意味する社内での呼称です。 私たちは以前からガバメントクラウド上の環境を集約して管理する「共通運用アカウント」を構築・運用していました。FA3 は、この共通運用アカウントに集約されるデータを活用することで、効率的に障害分析を行える仕組みとしています。 FA3 の実装には Amazon Bedrock Agents を採用しました。これにより、複雑な実装は不要となり、プロンプトの調整などによるメンテナンスの容易さを確保しました。 さらに、マルチエージェント機能を利用することで、分析精度の向上、コスト削減、そして将来的な機能拡張性を実現しました。 エージェント構成 FA3 は、分析全体を統括する「分析エージェント」と、特定の情報収集を担当する複数の「収集エージェント」で構成されています。 分析エージェントは、障害の状況に応じて必要な調査タスクを自律的に計画し、配下の収集エージェント（Configuration, Log, Metrics）へ指示を行います。その後、各エージェントから返却された情報を分析し、障害の根本原因を特定します。 収集エージェントは、以下のとおり役割ごとに Action を定義し、 AWS Lambda と連携させています。 ConfigurationAgent（サービスの詳細情報収集） /describe_service 指定された AWS リソース（ Amazon Elastic Compute Cloud（Amazon EC2） 、 Amazon Relational Database Service（Amazon RDS） 等）の詳細情報を収集します。 LogAgent（ログ情報収集） /describe_service 指定された AWS リソース（ロググループ）の詳細情報を収集します。 /get_logsqueryresult CloudWatch Logs Insights クエリを実行し、そのクエリ結果を収集します。 /get_athenaqueryresult Amazon Athena でクエリを実行し、そのクエリ結果を収集します。 MetricsAgent（メトリクス情報収集） /list_metrics 指定された名前空間やメトリクス名から取得可能な Amazon CloudWatch メトリクスの一覧を特定します。 /get_metric_data 開始・終了時間やクエリを指定し、実際のメトリクスデータを収集します。 また、あらかじめ環境構成やログの格納方法といったアカウント毎の情報を Amazon DynamoDB に登録しておくことで、運用担当者の操作を不要としました。CloudWatch アラームから送られてくる JSON 形式のアラームデータのみをインプットとして、FA3 が自動で障害分析を実行します。分析が完了すると、その結果はメールで関係者に通知されます。 これにより、運用担当者はアラーム発生と同時にそのアラームに対する分析結果を受け取れるようになりました。 ガバメントクラウド外の生成 AI を利用する仕組み 本ソリューションは、ガバメントクラウド環境から事業者側で用意した AWS アカウントの Amazon Bedrock を利用する構成となっています。 ガバメントクラウド環境では国内に通信が完結する LLM の利用が認められています。同様のセキュリティ水準を遵守することを前提に、事業者側で用意したガバメントクラウド外の AWS アカウントで生成 AI サービスを利用することとし、以下のようなアーキテクチャを採用しました。 セキュリティ設定 生成 AI（FA3）専用のアカウント（FA3 アカウント）には、デジタル庁から提供される必須適用テンプレートをコピーし、ガバメントクラウド環境と同等のセキュリティレベルを確保しました。 データ分離 FA3 アカウントには、実際に通知されたアラームのデータのみを配置する構成とし、リソースを参照するための Role や Lambda はすべてガバメントクラウド環境の「共通運用アカウント」に設定することで、明確にデータと権限を分離しました。 本ソリューションによる障害分析の流れ FA3 によるアラーム発生から分析結果通知までの障害分析の処理の流れは以下の通りです。 アラーム発生 自治体アカウントで発生した障害を検知し、CloudWatch アラームを発報します。 FA3 へアラームを連携 共通運用アカウントにてアラームを処理し、FA3 アカウントの Amazon Simple Queue Service（Amazon SQS） へ通知を行います。Amazon SQS は Amazon Bedrock Agents 呼び出し用の Lambda をトリガーします。 プロンプト生成 呼び出された Lambda が、DynamoDB から該当アカウントの情報を取得し、受け取ったアラーム情報と組み合わせて、Amazon Bedrock Agents へのプロンプトを生成します。 障害調査 プロンプトを受け取った分析エージェントが、障害内容に合わせて必要な情報の取得を収集エージェント群に指示します。 各収集エージェントがそれぞれの担当領域（メトリクス、ログ、サービス情報など）の調査・情報収集を行います。分析エージェントは、収集エージェントから集約したデータを基に、障害の根本原因を分析します。 情報収集は以下のアーキテクチャにて実装しています。 収集エージェントは、アクションとして定義された Lambda を実行します。 実行された Lambda は、共通運用アカウントに保管されているデータが必要な場合、共通運用アカウントへ AssumeRole を行い情報を収集します。 自治体アカウント内の情報（サービスの状態など）が必要な場合は、共通運用アカウントの Lambda を同期的に呼び出し、その Lambda が自治体アカウントへ AssumeRole を行い情報を収集します。 ※処理の長時間化や複雑化が発生した場合には、リトライ処理や分岐などの管理を容易にするため AWS Step Functions を検討 結果通知 分析した結果をメールにて運用担当者へ通知します。 AIの思考過程の記録 分析時に AI がどのような思考で調査を行ったのか、そのプロセスを DynamoDB に記録します。これにより、分析内容の妥当性を確認することが可能です。 検証結果 エージェント（FA3）の導入効果を検証するため、エンジニアによる調査結果と FA3 が報告した障害原因を照合し、その的中率を測定しました。 検証の結果、以下の通り全体で約9割、特にクラウド設定に関しては 100 %という高い信頼性が確認されました。 被疑箇所 アラームサンプル数 的中数 的中率 クラウド設定 27 27 100% OS内 56 47 83.90% 全体 83 74 89.20% 実現効果 アラーム確認のオペレーションを「FA3 の報告を確認し、その妥当性を判断する」というフローへ変更した結果、多数のアラーム調査が 10 分未満で完了するようになっています。 従来、事象推定からデータ確認までの初動調査には 1～2 時間を要していたため、調査時間は約 10 分の 1 にまで短縮されました。 事象の特定が困難である OS 内が起因のアラームであっても、被疑箇所の絞り込みを FA3 が行ってくれるため、初動調査に要する時間は短縮されました。 対応フロー 平均初動調査時間 従来 105分 FA3活用（クラウド設定起因） 7.5分 FA3活用（OS内起因） 15分 また、障害調査には AWS や業務システムに関する知見と経験を要するため、対応できるエンジニアが限られてしまうという課題がありましたが、FA3 が調査の大部分をサポートしてくれることで、経験の浅いエンジニアでも迅速かつ的確な対応が可能となりました。これにより、当初の課題であった人的リソースの不足が解消し、安定的な運用を維持することができるようになりました。 Why AWS？ 私たちクラウド保守グループは、AWS のシステム運用を強みとしており、今回のガバメントクラウド移行 におけるシステム構築でも AWS を利用してきました。そのため、AWS の生成 AI サービスである Amazon Bedrock を利用することは、既存環境との親和性、シームレスな連携、そして私たちが持つノウハウを最大限に活かす上で、最適な選択でした。 また、今回参考にした「FA2」が AWS 環境での実行を前提としていたことも、Amazon Bedrock を採用する後押しとなりました。 コスト 生成 AI へのリクエスト費用は、1回あたり 75 円程度です。 マルチエージェントではエージェント毎にモデルを設定できますので、例えば、高度な分析を行う「分析エージェント」には高性能なモデルを使用し、比較的単純な情報収集を行う「収集エージェント」には低コストなモデルを使用する、といった柔軟な選択肢も可能です。 以下の対策を組み合わせることで、コストの最適化も可能です。 分析対象の絞り込み： ディスク使用率低下など、AI 分析の効果が薄いアラームを除外する。 入力トークンの最適化： 調査対象とするメトリクスを厳選することや、取得データを加工してから AI に渡すことで、AI への入力データ量を抑制する。 今後の構想 FA3 のさらなる進化に向けて、以下の構想を描いています。 分析精度の向上 AWS X-Ray の情報や、AWS の障害情報といった、より多様な情報ソースを収集・分析対象に加えることで、原因分析の精度をさらに高めていきます。 対話型インターフェースの実装 現在は分析結果を一方的にメールで通知する形式ですが、受けた通知を元に AI と対話しながら現在のシステムの状態をより深く探れるような機能を、 Kiro や Amazon Q Developer といったサービスも活用しながら実装することを目指します。 複数アカウントにまたがる分析 同一パッケージシステムを利用している環境では、あるアカウントで発生した障害が他アカウントでも発生するリスクが高いです。そのため、単一アカウントの分析にとどまらず、特定した障害原因が他アカウントにも潜在していないかを横断的に分析できる機能を実装し、障害の未然防止につなげます。 著者について 田中 翔（たなか かける） データセンターのオンプレミス・プライベートクラウドからパブリッククラウドにフィールドを移しながらインフラ構築と運用監視をメイン領域として担当。最近ではパブリッククラウド向け MSP ビジネスの推進やガバメントクラウド保守チームのマネジメントを行っています。（写真右） 根岸 亮太（ねぎし りょうた） 以前はシステムの運用作業を主に担当しておりましたが、オンプレミスから AWS への移行プロジェクトを機に、現在は AWS を中心としたインフラエンジニアとして活動しております。最近ではガバメントクラウド環境の構築・管理、および AI 活用の推進に携わっております。（写真左）

米国ラスベガスで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 中村昌幸が翻訳しました。