本ブログは、NTT西日本グループ 吉田 健哉氏、同 中井 智絵氏、アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 川岸 が共同で執筆しました。 はじめに NTT西日本株式会社 （以下、NTT西日本）では、 ビジネスチャット『elgana』（エルガナ） をサービス提供しています。 2022 年 7 月にアマゾン ウェブ サービス (AWS) へプラットフォーム を移行し、生成 AI による新機能開発も加速しています。 elgana Project 「AI Lab.チーム」では、生成 AI を実際の業務にどう活かせるかをテーマにトライアル開発を進めています。本記事では、営業担当者支援を目的として Amazon Bedrock Knowledge Bases を活用した RAG を構築し、そのトライアルを実施した取り組みについて紹介します。 取り組み背景 elgana は一般の企業様を中心にご利用いただいているサービスですが、生成 AI による新機能開発は社内向けに検証を開始しました。NTT西日本グループにおいて営業担当者は日々多様な商材を扱い、膨大なマニュアルや資料を参照しています。しかし実際には、情報が複数のシステムに散在しており、必要な情報を探し出すのに時間がかかる・属人化してしまうといった課題がありました。加えて、商材の問い合わせ窓口である社内ヘルプデスクは限られた対応時間の中で運用されており、すべての問い合わせに即時対応することは難しい状況でした。そこで、生成 AI に社内ナレッジを組み合わせる RAG を活用し、効率的に「聞ける・探せる・使える」仕組みを提供できないか検証することにしました。AWS サービスとの親和性、日本語対応、セキュリティ設計の容易さから、Amazon Bedrock Knowledge Bases を採用しました。 営業支援 AI ボット 営業支援 AI ボットは elgana 上に構築しました。トークルーム上で営業支援 AI ボットに対して商材に関する質問を入力すると、AI ボットが即時に回答を提示する仕組みです。また、AI ボットからの回答には、補足情報として関連するマニュアルページへのリンクを設けることで、裏付けとなる情報を容易に確認できる設計としました。 さらに、回答後には「解決した／解決していない」の簡易アンケートを設け、解決率を収集するとともに、未解決のユーザーをヘルプデスクに誘導する流れを設けています。これにより、AI の強みと有人対応を組み合わせた実用的なサポート体験を実現しています。 アーキテクチャ 本システムでは、AWS のマネージドサービスをフル活用して構成し、最新技術の活用、インフラ運用の負担軽減とアプリレイヤの改善への集中を実現しています。elgana 上で営業支援 AI ボットに質問すると、Amazon API Gateway と AWS Lambda で実装したアプリケーションがメッセージを受信し、Amazon Bedrock Knowledge Bases を呼び出して質問に回答します。ナレッジのドキュメントの保存先のベクトルストアとして Amazon OpenSearch Serverless を利用しています。 営業支援 AI ボットでは、利用者体験を向上させるため、回答生成に利用したマニュアルのページ番号まで案内すること、関連するサービスマニュアルのナレッジだけを参照するよう メタデータフィルタリング を活用して検索対象を絞り込むことで回答精度を向上させる工夫をしています。 具体的な処理内容としては、運用者が Amazon S3 にアップロードしたマニュアルの pdf ファイルは AWS Lambda (pre-processing) を通じて、(A) ページ分割した上で、Markdown 形式に変換、(B) マニュアルに付与するメタデータを作成、の 2 つの処理が行われた後、Amazon S3 に格納されます。(A) の処理では、ページ分割することで RAG 回答で参照したマニュアルのページ番号をファイル名から特定できるようにしています。また、マニュアルに含まれる表データの抽出精度向上のため、pdf 文書をテキスト化するための python ライブラリである pdfminer を用いて HTML 化し、その後 Claude 3.5 Sonnet で Markdown 形式に変換しています。なお、Claude 3.5 Sonnet はマルチモーダル対応 LLM であるため、画像認識による情報抽出も可能ですが、検証時点では pdfminer を介す方法の方が優れていると判断しました。(B) の処理では、S3 のオブジェクトキー情報からカテゴリ情報等を抽出して、 .metadata.json メタデータファイルを作成しています。 以下はメタデータファイルの中身の例です。 { "metadataAttributes": { "original-s3-key": "docs/商材A/pdf/manualA.pdf", "file-type": "pdf", "category": "商材A" } } このメタデータは、ベクトルストアからドキュメント検索する際に、メタデータに基づき事前にフィルタリングした上で、関連するドキュメントを検索できます。上記の例では、単一の Knowledge Base に複数の商材のマニュアルを格納していた場合にも、 category = 商材A でフィルタリングすることで関連する情報を取得できるため、検索精度向上に寄与します。 トライアル結果 今回の取り組みでは、実際の営業担当者に数週間トライアル利用していただき、その後、ユーザーアンケートを実施し様々な評価を得ました。利用者からは「知りたい情報に素早くアクセスできる」「マニュアルを探す時間が減った」といった声が多く寄せられ、業務効率化につながる手応えを実感していただいており、現場での実用性を確認する結果となりました。一方で、「回答速度を上げてほしい」や「回答の幅（サービスの種類）を広げてほしい」などの改善意見もポイントも挙げられました。こうした声を踏まえ、今後も更なる機能改善を繰り返し利用者がさらに安心して業務に取り入れられるよう、進化させていく予定です。 今後の展望 今回のトライアルで得られた成果をもとに機能改善を重ねて実運用を目指していく予定です。 また、開発した RAG 基盤は Amazon S3 にナレッジドキュメントを格納するだけで対象商材に特化した検索基盤を自動的に構築できる仕組みであり、幅広い業務で活用できる柔軟な基盤へ発展させることも視野に入れています。将来的には Amazon Bedrock AgentCore 等を活用することで、単なる検索や回答にとどまらずタスク実行まで支援できる「Agentic RAG」へ時代に即した価値創出を目指します。 まとめ 本ブログでは、NTT西日本グループによる、 Amazon Bedrock Knowledge Bases を活用した営業支援 AI ボットによる情報検索効率化の取り組み事例をご紹介しました。生成 AI の業務利用にあたっては、ハルシネーションのような不確実性を課題視されるお客様もいらっしゃると思います。本事例では、関連マニュアルのページ番号まで明示することで情報の正確性を迅速に確認できる仕組みを構築するとともに未解決の場合にはヘルプデスクに誘導する仕組みを設け、AI の強みと有人対応を組み合わせた実用的なサポート体験を実現しています。皆様の生成 AI 活用の参考になれば幸いです。 著者 吉田 健哉 NTTビジネスソリューションズ株式会社 バリューデザイン部 システム開発部門 中井 智絵 NTT西日本株式会社 ビジネス営業本部 バリューデザイン部 DXプラットフォーム部門 川岸 基成 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部 通信グループ ソリューションアーキテクト

本ブログは 2025 年 1 月 9 日に公開された AWS Blog “ Securing a city-sized event: How Amazon integrates physical and logical security at re:Invent ” を翻訳したものです。 Amazon Web Services の年次カンファレンスである AWS re:Invent のような大規模イベントのセキュリティ確保は、決して簡単なことではありません。2024 年 12 月に開催された AWS re:Invent 2024 は、ラスベガス・ストリップ (ラスベガス中心部の大通り) にわたって 12 マイル (約 19 km)、約 700 万平方フィート (約 65 万平方メートル、東京ドームのグラウンド約 50 個分) に及び、7 つの会場で展開され、小さな都市に匹敵する規模で運営されました。 6 万人の現地参加者、40 万人のオンライン参加者、そしてそのデータすべてを安全に保つには、物理セキュリティと論理セキュリティの高度な組み合わせが必要です。Amazon は、両者を統合したセキュリティ戦略により、この課題に対処してきました。ドローン、K9 ユニット (警備犬)、ネットワークセキュリティチームなど、あらゆるリソースを活用して、イベントに参加するすべての人々とそのデータを保護しています。 図 1: re:Invent のコマンドポスト (統制本部) セキュリティはチームスポーツ Amazon では、物理セキュリティチームと情報セキュリティ (論理セキュリティ) チームが協力して、多様なビジネス全体で、お客様、従業員、インフラストラクチャを幅広い脅威から大規模に保護しています。re:Invent のような大規模イベントでは、この統合アプローチにより、参加者から現地のコンピュータやサーバー、Wi-Fi ネットワークとそのユーザーまで、イベントの多くの側面を可能な限り包括的に保護できます。 Amazon は単独で活動しているわけではありません。イベントセキュリティチームは、Las Vegas Metropolitan Police や、テロ対策、爆発物処理班、救急隊員を含む 40 以上の異なる機関と連携しています。 図 2: K9 ユニット – 現地セキュリティチームの重要なメンバー これらのチームは、セキュリティオペレーションの中枢であるコマンドポスト (統制本部) に配置されています。ここでは、物理セキュリティと論理セキュリティが融合し、セキュリティ体制のほぼすべての要素が集まり、リアルタイムでイベントの脅威を監視しています。これには、イベントセキュリティ管理チーム、インテリジェンスチーム、監視カメラオペレーターが含まれ、地元の警察や緊急対応機関と連携しています。さらなる保護層として、メインのコマンドポストと緊密に連携して、ワイヤレスセキュリティオペレーションセンター (WiSOC) も運営しており、これはワイヤレスおよびサイバーセキュリティチームの主要なハブとして機能しています。 re:Invent を効果的に保護するためには、オープンな対話と情報共有を促進することが重要です。脅威の状況が進化し続ける中、組織は物理セキュリティと論理セキュリティの間のギャップを埋めることを優先する必要があります。この統合アプローチは、re:Invent のような都市規模のイベントを効果的に保護する鍵であるだけでなく、毎日お客様、従業員、会社を保護するのにも役立っています。 都市規模のセキュリティ Amazon は re:Invent で、物理的資産とデジタル資産を保護するために、多数の統合セキュリティ対策を展開しています。物理セキュリティに関しての最優先事項はもちろん人命です。re:Invent では、警備員、K9 ユニット、救急隊員を含む数千人のセキュリティ要員を配置し、急病やけが、火災、盗難、混雑などの問題に対応し、支援しています。混雑エリアに監視カメラを設置し、入口でのゲート型金属探知機や堅牢な認証システムを含む厳格な入場管理を実施して、参加者にとって安全で安心な環境を作り出しています。 ドローンの支援もあります。自動化された高高度飛行体は、Las Vegas Festival Grounds で開催される最終コンサート re:Play で鳥瞰図を提供し、問題への対応を調整するのに役立ちます。AWS クラウドソリューションを使用して、ライブ映像が現地のセキュリティチームに直接ストリーミングされ、人の流れを監視しています。 図 3: re:Play の保護に使用されるドローンを紹介するセキュリティチームメンバー Amazon はネットワークのセキュリティにも注力しており、それによってユーザー、つまり参加者を保護しています。ワイヤレスおよびサイバーセキュリティチームは、ネットワーク全体で異常なアクティビティを特定するために活動しています。これには、 スプーフィング (なりすまし) の兆候も含まれます。スプーフィングとは、攻撃者が似たような Wi-Fi ネットワークを設定し、参加者を自分たちのネットワークに接続させようとする手法です。 Amazon は、 re:Invent のクラウドコンピューティングと AI の専門家、エグゼクティブ、エンジニア によるプレゼンテーションのセキュリティも確保しています。講演者が自信を持って知見を共有するには、世界中の数十万人の視聴者に安全で中断のないチャネルでストリーミングされることを知る必要があります。re:Invent モバイルアプリもセキュリティを念頭に置いて構築されているため、参加者はイベントやカンファレンス内のニーズを安全に管理できます。 統合されたセキュリティアプローチは、AWS クラウドによって実現されています。AWS クラウドは、セキュリティオペレーションのさまざまなコンポーネントをサポートし、重要な情報を迅速に共有するのに役立ちます。論理セキュリティの脅威、物理セキュリティの懸念、医療的な緊急事態のいずれに直面している場合でも、成功の鍵は対応時間にあります。AWS クラウドでオペレーションを実行することで、迅速に行動できます。 Amazon は、脅威の種類に関係なく、チームが一貫した統一された対応を取れるように、統合アプローチへの投資と強化を続けていきます。Amazon はこの分野のリーダーであることを誇りに思っており、私たちの知見が、大規模イベントの運営時においても日常業務においても、他の企業や組織のセキュリティレジリエンス強化に役立つことを願っています。 Steve Schmidt Steve は Amazon の最高セキュリティ責任者であり、2008 年 2 月から同社に在籍しています。情報セキュリティ、物理セキュリティ、セキュリティエンジニアリング、規制プログラムチームを統括しています。2010 年から 2022 年まで、Steve は AWS の最高情報セキュリティ責任者を務めました。Amazon に入社する前は、FBI で長いキャリアを積み、上級幹部として勤務していました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 11 月 14 日に公開された AWS Blog “ AWS re:Invent 2025: Your guide to security sessions across four transformative themes ” を翻訳したものです。 AWS re:Invent 2025 は、 Amazon Web Services (AWS) が主催する最高峰のクラウドコンピューティングカンファレンスで、2025 年 12 月 1 日から 5 日にかけて、ネバダ州ラスベガスで開催されます。AWS では、セキュリティを最優先事項としており、re:Invent 2025 はこのコミットメントを反映した、これまでで最も包括的なセキュリティトラックを提供します。ブレイクアウト、ワークショップ、チョークトーク、ハンズオンのビルダーズセッションなど、80 以上のセキュリティ関連セッションを通じて、優秀な人材が集まり、インサイト、ベストプラクティス、革新的なソリューションを共有します。セキュリティのプロフェッショナル、開発者、クラウドアーキテクトにとって、このイベントは AWS の最新セキュリティイノベーション、高度な脅威保護機能、スケールする防御戦略に関する貴重なインサイトを提供します。re:Invent では、展示ホールのセキュリティキオスクと AI セキュリティキオスクを訪れて、AWS セキュリティエキスパートと直接、お客様固有のニーズについて相談することができます。 セキュリティトラックのセッション選定プロセスは、お客様のニーズと実際の実装課題に関する広範な分析に基づいて行われました。特に、お客様が最も多くのガイダンスを求めているセキュリティ分野に焦点を当て、4 つの主要テーマを中心にセッションをまとめました。 AI のセキュリティ確保と活用 、 大規模なセキュリティとアイデンティティのアーキテクチャ設計 、 セキュリティ文化の構築とスケーリング 、 AWS セキュリティのイノベーション です。これらのセッションの目標は、目前のセキュリティ課題に対処し、より広範なビジネス成果の達成を支援することです。以下のセクションでは、4 つのテーマそれぞれの主要なセッションをいくつか紹介します。すべてのセッションについては、 re:Invent カタログ をご覧ください。 AI のセキュリティ確保と活用 AI のセキュリティ確保と活用は、セキュリティとアイデンティティトラックの主要テーマとして浮上しており、AI がもたらす機会と課題の両方を反映しています。AI ワークロードの保護から、セキュリティオペレーションの強化のための AI 活用まで、セッションは複数の AI トピックにわたり、組織がこの変革的なテクノロジーを安全かつ効果的に活用できるよう支援します。以下は、各 AI トピックに関する主要なセッションです。 AI ワークロードのセキュリティ確保 ブレイクアウト SEC410 – Advanced AI Security: Architecting Defense-in-Depth for AI Workloads (高度な AI セキュリティ: AI ワークロードのための多層防御アーキテクチャ設計) : AI ワークロードのための高度なセキュリティアーキテクチャを深く掘り下げ、高度な攻撃ベクトルからワークロードを保護する方法を探ります。技術的な例を通じて、アイデンティティ、きめ細かいアクセスポリシー、安全な基盤モデルのデプロイパターンをカバーしながら、AI ワークロードのための安全なアーキテクチャを実装します。AWS のセキュリティ機能を使用して生成 AI とエージェンティック AI アプリケーションを強化し、最小権限コントロールを実装し、大規模な安全なアーキテクチャを構築する方法を学びます ワークショップ SEC406 – Red teaming your generative AI and MCP applications at scale (生成 AI と MCP アプリケーションの大規模なレッドチーム演習) : GenAI Red Team Challenge で、AI を活用したレッドチーム攻撃者の立場に立ってみましょう。この集中的なワークショップでは、AI セキュリティエージェントをデプロイして、Model Context Protocol (MCP) アプリケーションに対する高度な脅威チェーンを組織的に実行し、脆弱性を体系的に発見します。プロンプトテンプレートとガードレールから、不正アクセスを防ぐ OAuth 強化 MCP セキュリティ設定まで、対策をマスターします。このハンズオンのゲーム化された体験は、脅威アクターのように考えることを支援し、LLM ベースのアプリケーションに対する一般的な MITRE と OWASP の脆弱性に対する自動化された脆弱性テストとリスク軽減の実践的なスキルを身につけます。参加にはノートパソコンが必要です エージェンティック AI のセキュリティ チョークトーク SEC408 – Securing Agentic AI: OWASP, MAESTRO, and Real-World Defense Strategies (エージェンティック AI のセキュリティ確保: OWASP、MAESTRO、実世界の防御戦略) : OWASP の更新された脅威と軽減ガイドおよびエージェンティックセキュリティイニシアチブを使用して、エージェンティック AI セキュリティの最新情報を探ります。また、AI システムに特化した脅威モデリングアプローチである MAESTRO についても探求します。これは、AI ライフサイクル全体にわたってリスクを特定し軽減するための階層化された方法論を提供します。実世界のケーススタディを通じて、堅牢なガバナンス、継続的なモニタリング、最小権限アクセスを含む、エージェンティック AI のセキュリティベストプラクティスを実証します。リスクを最小限に抑えながら、自律的な AI エージェントを自信を持ってデプロイする方法を学びます。産業を安全に変革できる、安全で信頼性が高く、レジリエントなエージェンティック AI アプリケーションを構築するための実践的なインサイトを得られます ワークショップ SEC307 – Design authentication, authorization, and logging logic in Agentic AI apps (エージェンティック AI アプリにおける認証、認可、ログ記録ロジックの設計) : このハンズオンワークショップでは、生成 AI エージェントのアイデンティティと権限を管理するという重要な課題に取り組みます。AI エージェント、ツール、LLM に合わせた、ユーザーとマシンの認証、およびきめ細かい認可メカニズムを実装する方法を学びます。AI コンテキストにおける同意管理と権限委譲を探ります。参加者は、Strands SDK、Amazon Bedrock AgentCore Identity、アイデンティティ管理のための Amazon Cognito、認可決定のための Amazon Verified Permissions など、AWS の最新サービスを使用した実践的な経験を得られます。最後には、AWS の最先端のアイデンティティおよびアクセス管理ソリューションを使用して、AI オペレーションのセキュリティとコンプライアンスを強化するスキルを習得できます セキュリティのための AI 活用 ビルダーズ SEC318 – Strengthen your network security with generative AI (生成 AI でネットワークセキュリティを強化する) : 生成 AI の力を使用して、ネットワークセキュリティの管理方法を変革します。Amazon Q Developer が自然言語での会話を通じて AWS Shield Network Security Director の検出結果を探索する方法をご覧ください。設定ミスのあるリソースを迅速に特定し、セキュリティ問題を理解し、AWS 環境全体でガイド付きの修正を実装する方法を学びます チョークトーク SEC304 – Building an AI-Powered security guardian for your Cognito applications (Cognito アプリケーションのための AI を活用したセキュリティガーディアンの構築) : Amazon Cognito で認証されたアプリケーションを保護するインテリジェントな AI を活用したセキュリティガーディアンで、アプリケーションセキュリティを向上させます。このインタラクティブなセッションでは、アイデンティティのベストプラクティスと、Amazon Bedrock AgentCore を使用した AI エージェントの構築について探ります。このエージェントは、ベストプラクティスの検証、検出分析の実行、リスクを軽減するための自動化された予防措置を支援します。AI エージェントが動的な WAF ルール調整、認証フローの変更、セキュリティオペレーションセンター (SOC) アクションをどのように実行できるかについて説明します。Cognito で保護されたアプリケーションに AI 駆動のセキュリティコントロールを実装する方法を深く掘り下げる際に、質問やシナリオをお持ちください セキュリティ文化の構築とスケーリング このテーマは re:Invent 2025 のセキュリティトラック全体に織り込まれており、テクノロジーソリューションだけでは堅牢なセキュリティ成果を確保できないという信念を反映しています。 セキュリティ文化 を持つ企業は、セキュリティファーストの組織となり、その後、安全なデジタルトランスフォーメーションを加速できます。このテーマを示すセッションには、以下のようなものがあります。 ブレイクアウト SEC319 – Climbing the AI Mountain With Your Security Team (セキュリティチームと共に AI の山を登る) : この実践的なセッションでは、AI とセキュリティ文化の交差点をナビゲートします。セキュリティチームが段階的なステップと検証技術を通じて、AI イノベーションを効果的に受け入れる方法を学びます。実世界の例を使用して、セキュリティ実務者が専門知識のレベルに関係なく、AI の課題にスキルを適応させる方法を実証し、セキュリティを意識した AI プラクティスを構築するための戦略を共有します。生成 AI とエージェンティック AI 特有のセキュリティリスクの理解から、魅力的なチーム演習の作成まで、セキュリティを潜在的なボトルネックから責任ある AI イノベーションの実現者に変革する方法を発見します。参加者は、AI 導入に対するセキュリティファーストのアプローチを構築するための実践的なインサイトを得られます チョークトーク SEC343 – Fostering a Resilient Incident Response Culture (レジリエントなインシデント対応文化の醸成) : セキュリティインシデント対応において、人間の専門知識とインテリジェントオートメーションを組み合わせる方法を発見します。AWS Security Incident Response、自動トリアージ機能、生成 AI がどのように連携して、チームの意思決定を置き換えるのではなく強化するかを学びます。AWS Security Incident Response と生成 AI をワークフローに統合することで、アラート疲労を軽減し、正確なインシデント分類を加速し、対応者が重要な分析に集中できるようにする方法を探ります。主要な組織が自動化と人間の監視をどのようにバランスさせ、人間の判断と組織的知識の重要な要素を維持しながら、より効率的でレジリエントなインシデント対応プロセスを作成しているかをご覧ください。インシデント対応文化において、AI 駆動のインサイトと人間の専門知識を統合するための実践的な戦略を明らかにします チョークトーク SEC227 – Translating Security Metrics into Business Outcomes (セキュリティメトリクスをビジネス成果に変換する) : 今日、CISO は複雑なセキュリティデータをビジネス価値に変換するという課題に直面しています。このセッションでは、セキュリティメトリクスを、取締役会の意思決定を推進する戦略的インサイトに変換するための実証済みのフレームワークを明らかにします。主要な組織が AWS Security Hub、OpenSearch、Security Analytics、自動化をどのように活用して、セキュリティのビジネスへの影響を示すリアルタイムのリスクダッシュボードを構築しているかを学びます。セキュリティプログラムを運用メトリクスからビジネス成果へと進化させ、データ駆動型の投資決定と、経営幹部に響く測定可能なリスク削減を可能にする実践的な戦略を持ち帰ります 大規模なセキュリティとアイデンティティのアーキテクチャ設計 このテーマでは、AWS が提供する包括的なツールセットと実証済みのパターンを使用して、個々のワークロードからグローバル組織まで拡張できるエンタープライズグレードのセキュリティコントロールを実装する方法を探ります。このテーマに関する主要なセッションには、以下のようなものがあります。 チョークトーク SEC333 – From Static to Dynamic: Modernizing AWS Access Management (静的から動的へ: AWS アクセス管理のモダナイゼーション) : 堅牢な AWS アイデンティティ基盤の構築には、静的な認証情報を超えた取り組みが必要です。このセッションでは、AWS 組織全体で動的で一時的なアクセスを実装するための実証済みのパターンを深く掘り下げます。アクセスキーの依存関係に関する実世界の課題を探り、IAM ロールと SAML フェデレーションを使用して一時的な認証情報への移行を行うための実践的なアプローチを共有します。実践的な例と学んだ教訓を通じて、運用オーバーヘッドを削減しながら拡張できる安全な認証パターンを実装する方法を発見します。アイデンティティ境界を強化し、アクセス管理アプローチをモダナイズするための実践的な戦略を持ち帰ります ワークショップ SEC401 – Active defense strategies using AWS Al/ML services (AWS AI/ML サービスを使用したアクティブディフェンス戦略) : このワークショップでは、Amazon Bedrock と Amazon SageMaker を使用して、デセプション (欺瞞技術) などのアクティブディフェンス戦略を開発およびデプロイする方法を学びます。セキュリティオペレーションのための AI 駆動の対応を開発する実践的な経験を得られます。攻撃者があなたに対して使用しようとする可能性のあるものを模倣する適応的な対応を開発する方法を学びます。プロンプトエンジニアリング、デプロイ戦略、モニタリング手法の実装パターンを発見します。参加にはノートパソコンが必要です ワークショップ SEC303 – Advanced AWS Network Security: Building Scalable Production Defenses (高度な AWS ネットワークセキュリティ: スケーラブルな本番環境の防御構築) : このハンズオンワークショップでは、今日の最も重要な脅威から防御するための AWS ネットワークセキュリティ技術をマスターします。AWS Network Firewall と Route 53 Resolver DNS Firewall を使用して、レイヤー 7 機能とディープパケットインスペクションを実装し、インターネット向けトラフィックと内部トラフィックフローの両方を保護する方法を学びます。ゼロデイ攻撃とランサムウェアに対抗するためのスケーラブルで信頼性の高いフィルタリングの設定、および洗練された東西トラフィックコントロールを実装してラテラルムーブメント (横展開) を防ぐ実践的な経験を得られます。実世界のシナリオを通じて、フルマネージド AWS サービスを使用して、IDS/IPS フィルタリング、ドメインベースのコントロール、最小権限の原則を活用する方法を学びます。現代のサイバー脅威に対するレジリエントなネットワーク防御を構築するための準備を整えて帰ります AWS セキュリティのイノベーション AWS のセキュリティ機能におけるイノベーションは、組織が進化する脅威に先んじることを支援するように設計されています。機械学習を活用した高度な脅威検出から革新的なデータ保護メカニズムまで、これらのイノベーションは、進化する環境においてお客様を安全に保つという AWS のコミットメントを示しています。イノベーションに焦点を当てたセッションには、以下のようなものがあります。 ブレイクアウト SEC203 – State of the Art: AWS data protection in 2025 (ft. Vanguard) (最先端技術: 2025 年の AWS データ保護 (Vanguard 社の事例)): AWS Cryptography のリーダーと共に、2025 年の画期的なセキュリティイノベーションの包括的なツアーに参加しましょう。CloudFront、KMS、Private CA、Secrets Manager における最新のリリースを発見し、NIST 標準化されたポスト量子暗号の AWS 実装をご覧ください。量子耐性アルゴリズム、高度な証明書管理、自動化されたシークレット処理を通じて、クラウドセキュリティをどのように革新しているかを学びます。Vanguard 社のエンタープライズ全体にわたる PQC 移行と、それを戦略的なビジネス優先事項にした方法について、内部の視点を得られます。最も機密性の高いワークロードに対するデータ保護の基準を、AWS がどのように引き上げ続けているかを直接ご覧ください ブレイクアウト SEC323 – AWS detection and response innovations that drive security outcomes (セキュリティ成果を推進する AWS の検出と対応のイノベーション): 最新の AWS 検出および対応機能が、クラウド環境をより効果的に保護する方法を発見します。強化された脅威検出、自動化された脆弱性管理、合理化された対応を通じて、統合されたセキュリティ成果を大規模に達成する実践的な方法を学びます。AWS セキュリティサービスを使用して、ワークロードとデータを保護し、セキュリティモニタリングを一元化し、セキュリティポスチャを継続的に管理し、セキュリティデータを統合しながら、セキュリティオペレーションのために生成 AI を活用する方法をお見せします。AWS 環境全体でセキュリティを強化し簡素化するために、AWS 検出および対応サービスを統合するための実践的なインサイトを持ち帰ります ブレイクアウト SEC310 – Innovations in Infrastructure Protection to strengthen your network (ネットワークを強化するインフラストラクチャ保護のイノベーション): このセッションでは、AWS Network Firewall、Amazon Route 53 DNS Firewall、AWS WAF、AWS Shield などのインフラストラクチャ保護サービスの新機能について学び、アプリケーション保護を簡素化し、堅牢なエグレス保護を合理化し、ネットワークへのインサイトを得る方法を探ります。新しい可視性への投資が、設定ミス、潜在的な脅威、ネットワーク設定問題の事前特定についてのインサイトをどのように提供できるかを深く掘り下げます まとめ クラウドセキュリティの知識を向上させ、AWS セキュリティエキスパートや業界の仲間とつながるこの機会をお見逃しなく。セキュリティとアイデンティティのセッションの全体像については、 AWS re:Invent カタログ をご覧ください。トピック、関心分野、役割などでセッションをフィルタリングできます。 セッション予約システムにアクセスして登録すると、セッションへの参加予約ができます。特にハンズオンセッションなど、人気のあるセキュリティセッションは、定員が限られているため早く埋まりますので、スケジュールが公開されたらすぐに希望のセッションを予約することをお勧めします。re:Invent でお会いしましょう! Rahul Sahni Rahul は AWS Security のシニアプロダクトマーケティングマネージャーです。熱心な Amazonian として、Rahul は仕事でもプライベートでも、会社の「Learn and Be Curious (学び、好奇心を持つ)」という原則を体現しています。継続的な学習への情熱を持ち、新しい経験と冒険を楽しんでいます。仕事以外では、世界中の新しい料理を試すことを楽しんでいます。 Justin Criswell Justin は AWS のセキュリティソリューションアーキテクチャのシニアマネージャーです。21 年間のテクノロジー専門知識を持ち、そのうち 13 年間はクラウドセキュリティとカスタマーサクセスを専門としています。スペシャリストのチームと AWS セキュリティフィールドコミュニティを率いて、お客様がセキュリティサービスを採用し運用し、可視性を高め、リスクを軽減し、AWS クラウドでのセキュリティポスチャを強化することを支援しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

皆さんこんにちは、ソリューションアーキテクトの金杉と石見です。 AWS では、生成 AI を活用したお客様のビジネス変革を支援するため、多くのAWSパートナーとの連携を行っています。先日 2025 年 10 月 29 日には、AWS ソフトウェアパスのパートナーであるAnthropic が Tokyo Office を開設され、日本のお客様をより密に支援する体制が強化されました。今後日本国内でも AWS で利用できる Anthropic ソリューションのニーズが増すことが予想されるため、この記事では AWS で利用できる Anthropic ソリューションについてご紹介します。 AWS が提供する Anthropic のソリューション AWS で利用できる Anthropic のソリューションとして、 Amazon Bedrock 経由での Claude モデルの提供と Claude for Enterprise の AWS Marketplace 上での販売についてご紹介します。 Amazon Bedrock 経由での Claude モデルの提供 Amazon Bedrock は、生成 AI アプリケーションやエージェントの構築に適した包括的でセキュアかつ柔軟なプラットフォームです。Amazon Bedrock の一機能として、Anthropic の Claude を含む基盤モデルをセキュアで簡単に利用できる API を提供しており、 国内でも多数の本番利用における公開事例 があります。 Anthropic 社の Claude API で利用する際と同じ料金で提供しており（2025年11月19日時点）、お客様の要件に応じてAmazon BedrockでもClaude モデルをご利用いただけます。Amazon Bedrock 経由で Claude モデルを利用するメリットとしては主に以下のようなお声をいただいています。 データコントロールの観点で、全てのデータが AWS に留まる上、必要に応じて日本国内や閉域に閉じた利用が可能 利用や支払いを AWS の他サービスとまとめられるため、モデルプロバイダーと追加の契約手続きや、それに付随するセキュリティ申請、予算獲得等の社内プロセスが省略できる AWS の包括契約のコミットメントに合算できる AWS のエンタープライズグレードの可用性と SLA (Service Level Agreement) が適用される AWS サポート、ML スペシャリスト、生成 AI イノベーションセンターなど様々なメンバーからの密なサポートを受けられる 特に、最新モデル Claude Sonnet 4.5 / Claude Haiku 4.5 は 日本国内クロスリージョン推論 (Japan Cross Region Inference) に対応しました。このマネージドな機能により、多くのお客様のデータレジデンシー要件を満たしながら、推論リクエストを日本国内の 2 リージョンに自動的にルーティングできるようになり、トラフィックバーストをシームレスに処理できるようになります。 詳しくは、AWS ブログ「 Amazon Bedrock で日本国内に閉じた Anthropic Claude 4.5 の推論が可能に！日本国内クロスリージョン推論のご紹介 」も参照してください。 AWS Marketplace 上での Claude for Enterprise の提供  AWS Marketplace は、サードパーティのソフトウェア、データ、サービスを売り買いできる厳選されたデジタルカタログであり、購入者としてはソフトウェア調達やライセンス管理を簡素化することができます。例えば、サードパーティが提供する SaaS を AWS Marketplace からサブスクライブし、AWS インフラの支払いと SaaS 製品の支払いを集約できる機能も提供しています。現在では、Anthropic の Enterprise プランである “Claude for Enterprise“ を AWS Marketplace 上で購入する ことができるようになっており、Claude のウェブやデスクトップ版が利用できる Standard seat だけでなく、Claude Code を合わせて利用できる Premium seat も取り扱っています。 Anthropic がネイティブに提供する Enterprise プランとは一部機能差異はありますが、AWS Marketplace 経由で Claude for Enterprise を契約する際のメリットとして、主に以下のような声をいただいています。 購入プロセスや支払いを AWS にまとめることができる AWS の包括契約のコミットメントに合算できる 特に Anthropic が提供するエージェンティックコーディングツールである Claude Code の社内展開を目的とした Claude for Enterprise への注目は日本でも大きく、 Team プラン 以上で提供されているチーム管理機能、一元請求管理や SSO (Single Sign On)/JITP に加え、監査ログ、ロールベースの権限管理などのエンタープライズグレードなセキュリティ機能や業務に十分なクオータなどを理由に導入が進んでいます。     AWS と組み合わせて Claude Code を利用する場合について 昨今は、特に Claude Code に関するお問い合わせが増えているため、Claude Code に絞って AWS と組み合わせて利用できる方法を整理すると、上記で説明した Amazon Bedrock と Claude for Enterprise に対応する形で二種類の方法があります。一つ目は Claude Code と Amazon Bedrock API 経由の Claude モデルを組み合わせる方法であり、従量課金でデータをAWSに留めて利用できる方法になります。もう一方は AWS Marketplace 上で Claude for Enterprise の Premium seat を購入する方法であり、これは予測可能な予算管理が好ましい場合や、ウェブ・デスクトップ版の Claude も合わせて活用したい場合、必要な機能をビルトインですぐ使い始めたい場合に適しています。 Claude Code を AWS 上で利用する方法に関してより詳しく知りたい方は、ブログ「 Claude Code on AWS パターン解説 – Amazon Bedrock / AWS Marketplace 」を参照してください。   AWS と Anthropic で生成 AI による変革をサポート ここまで、Amazon Bedrock 経由での Claude モデルの提供や、Claude for Enterprise の AWS Marketplace 上での販売といった具体的なソリューションについてご説明してきました。AWS からの支援体制については、ソリューションの提供を超えて、コスト面では各種クレジットプログラム、技術支援リソースの面では生成 AI イノベーションセンターや プロトタイピングチーム、そして定期的な生成 AI 関連イベントを介した知見共有に至るまで、幅広い観点でのご支援を続けています。また、Anthropic ソリューションについてのスペシャリスト組織も社内で拡大しているため、AWS からも深く Anthropic ソリューションについての技術支援ができる体制が強化されてきています。 今後も AWS は生成 AI テクノロジーを活用してビジネスの変革を進めるお客様を包括的に支援してまいりますので、ぜひお気軽にご相談ください。   Anthropic Tokyo Office Launch Event なお、10 月 29 日に開催されたAnthropic Tokyo Office Launch Eventでは、Anthropic Japan 代表執行役社長 東條英俊氏によるオープニング、共同創業者 ベン・マン氏 による最新情報の発表、CEO ダリオ・アモデイ氏のインタビューに加えて、アマゾン ウェブ サービス ジャパン 代表執行役員社長 白幡も登壇しました。白幡のスピーチでは、お客様に代わってイノベーションを継続するAWSのマインドセットと、Anthropic が信条とする AI Safety へのコミットメントの親和性について紹介しました。Anthropic の持つモデルやソリューションを、AWS の安全でスケールするインフラストラクチャが支えることで、スタートアップからエンタープライズ企業までが安心してご利用いただけるようなサービスをお届けしています。  

本記事は 2025 年 11 月 17 日に公開された Aaron Eline（Researcher） による “ Does your code match your spec? ” を翻訳したものです。 仕様の重要性 Kiro は 7 月にローンチした際に仕様駆動開発（Spec Driven Development、以下、SDD）を導入したエージェント型 IDE です。SDD では、Kiro のエージェントがコードを書く前にソフトウェアの完全な仕様を作成します。これにより、開発前にエージェントと繰り返しやり取りしながら、アプリケーションの要件を完全に捉えられているか確認できます。Kiro はその要件ドキュメントを実行して Spec （仕様）に変換し、生成されたコードが仕様に準拠しているかをチェックします。Kiro はこの実行可能な仕様を使ってプログラムをテストしますが、その際にプロパティベーステストと呼ばれる手法を使用します。私たちはこの手法は、バグ発見により効果的であると考えています。 要件からプロパティへ Kiro を使うと、仕様からコードが生成されます。しかし、そのコードが本当に仕様通りに動作するかをどうやって確認すればよいのでしょうか？Kiro や他の生成 AI コード生成ツールは、この問いに答えるために自動生成されたユニットテストを使ってきました。Kiro はコードと一緒にユニットテストを生成し、コードがそれらをパスすることを確認します。しかし、ここには鶏と卵の問題があります。ユニットテストが仕様で示された動作を捉えているかをどうやって確認するのでしょうか？各テストを見て、1/ そのテストがどの仕様要件に適用されるのか、2/ テストで規定された動作が仕様と一致しているかを判断する必要があります。どちらのステップも面倒でエラーが起きやすい作業です。 実際のところ、ユニットテストの代わりにプロパティベーステストを使用することで、より優れた結果を得られる場合があります。ユニットテストは本質的に「例ベース」のテストで、単一の入力と出力のペアで構成されています。各テストは特定の例において、システムが特定の方法で動作することを主張します。対照的に、プロパティベーステスト（または単にプロパティテスト）は、システムの動作についてプロパティが真であることをテストします。つまり、広範囲の（場合によっては無限の）入力に対してそれが成り立つことを確認します。この普遍性こそが、プロパティテストに力を与えるものです。プロパティテストでは、多くの入力をランダムに生成してテストします。プロパティテストが false を返した場合、そのプロパティを破る反例を見つけたことになります。これはテスト対象のプログラムのバグを表している可能性が高いです（ただし、プロパティ定義のバグや元の仕様のバグである可能性もあり、それを見つけることも有用です）。Kiro はこの例を使って、正しくなるまでコードを修正できます。 プロパティベーステストは 20 年以上前に Haskell プログラミング言語向けに QuickCheck というフレームワークで発明されました。それ以来、成長し成熟してきました。プロパティテストは、Kiro が行うような仕様駆動開発と非常に相性が良いです。なぜなら、仕様要件は多くの場合、直接的にプロパティを表現しており、これらのプロパティはプロパティベーステストを使ってテストできるからです。ある意味で、プロパティは仕様の（一部の）別の表現です。プロパティベーステストを使えば、動かして確認できる仕様表現が手に入ります。プロパティベーステストで構成される実行可能な仕様は、テキストの要件と簡単に結びつけられるため、プロパティテストがパスする限り、コードが要件通りに動作しているという確信が得られます。 例 例として、Python で小さな信号機シミュレーターを書いているとしましょう。Kiro は受け入れ基準で構成される要件ドキュメントを含む仕様を作成します。受け入れ基準の 1 つは次のようになるかもしれません。 要件 2.3: 安全性の不変条件 システムは、矛盾する交通の流れを防ぐために、任意の時点で最大 1 つの方向のみが緑信号を持つことを保証しなければならない。 この基準は、信号機の重要な条件を表現しています。2 つの方向が同時に緑になることは決してないということです。この受け入れ基準をテキストのプロパティに変換すると次のようになります。 プロパティ: 安全性の不変条件 - 最大1つの緑信号 *任意の*操作シーケンス（状態遷移、緊急モードの有効化、タイミング更新）に対して、 任意の時点で、最大1つの方向のみが緑信号を持つべきである **検証対象: 要件 2.3** このプロパティが「任意の」という言葉で始まっていることに注目してください。これがプロパティである理由は、単一の例の入力がどう処理されるべきかの説明ではなく、入力と動作の範囲について語っているからです。Kiro はこのプロパティテキストをもとに、実行可能なテストコードへ変換します。Kiro は、テキストの仕様からこのプロパティをチェックするテストへ直接ナビゲートできるようにすることで、両者を結びつけます。 Kiro はテキストのプロパティを、 Hypothesis というフレームワークを使って書かれたプロパティベーステストに変換します。これについては後ほど詳しく見ていきます。信号機のプロパティのコードは以下の通りです。このコードを読めば、実際に私たちが気にしているプロパティをチェックしていることがわかります。まず、正常な状態から始まっていることを確認します。次に、操作スケジュールの各操作を反復処理し、それらを適用して、常に 1 つの緑信号しか見られないことを確認します。 def test_safety_invariant_at_most_one_green( timing_config: TimingConfig, operations: list ): """機能: 信号制御システム、プロパティ 2: 安全性の不変条件 - 最大1つの緑信号 検証対象: 要件 2.3 """ # 状態マネージャーと制御モジュールを作成 state_manager = SignalStateManager(timing_config) control_module = ControlModule(state_manager) # 初期状態（すべて赤）が安全性を満たすことを確認 assert control_module.validate_safety(), "初期状態は安全であるべき" # 各操作を実行し、操作後に毎回安全性を確認 for operation in operations: op_type = operation[0] if op_type == 'transition': _, direction, state = operation control_module.request_transition(direction, state) elif op_type == 'emergency_activate': _, direction = operation control_module.activate_emergency_mode(direction) elif op_type == 'emergency_deactivate': control_module.deactivate_emergency_mode() # すべての操作後に安全性の不変条件を確認 all_states = state_manager.get_all_states() green_count = sum(1 for state in all_states.values() if state == SignalState.GREEN) assert green_count <= 1, ( f"安全性違反: 操作 {operation} の後に {green_count} 個の緑信号。" f"状態: {all_states}" ) このプロパティテストの素晴らしい点は、最初に定義した要件を直接テストしていることです。つまり、多くの入力でテストすれば、その要件を満たしていることに高い確信が持てます。さらに重要なのは、その逆も成り立つことです。この関数を失敗させる入力が存在する場合、プログラムは正しくないのです。Kiro はこの特性を積極的に利用します。 プロパティテストの重要な部分は、プロパティテストを実行するための多様な入力をランダムに生成することです。この例では、重要な入力は test_safety_invariant_at_most_one_green に渡される操作の list です。次のセクションでは、この例の文脈で入力生成について説明します。自動入力生成は、ユニットテストに対する重要な利点を提供します。誰かがユニットテストを書くとき（モデルであれ人間であれ）、エッジケースを考慮しようとしますが、 自分自身の内部バイアスによって制限されます。 ランダム生成を利用することで、見落とされがちなエッジケースやコンポーネント間の相互作用を発見できることがよくあります。Kiro はこの事実を最大限に活用します。 プロパティの典型パターン プログラムの正しさに関する文献では、よく現れるプロパティの典型的なパターンがあることがわかっています。Kiro はこれらのパターンを認識しており、プロパティを生成する際にそれらを探します。たとえば、二分探索木のようなデータ構造の一般的なプロパティは、実行時の不変条件を維持することです。個々の操作が不変条件を維持することを検証するプロパティを書けます。 # 挿入操作は二分探索木の性質を維持すべき def bst_insert(tree, input): if is_bst(tree): tree.insert(input) assert is_bst(tree), "木は依然として二分探索木であるべき" assert tree.contains(input), "木は入力値を含むべき" 別の一般的なプロパティのパターンは「ラウンドトリップ」で、一連の操作によって開始時の値に戻るというものです。このプロパティは特にパーサーやシリアライザーに有用です。 # パーサーでほぼ常に成り立つべきプロパティ # 整形してから再度パースすると、同じ式が得られるべき def parser_correctness(expression): assert parse(pretty_print(expression)) == expression Web API では、削除操作が「冪等」であることを望むことがよくあります。つまり、アクションを 2 回繰り返しても 1 回実行したのと同じ効果になるということです。 def delete_idempotence(orders_list, order_id): if order_id in orders_list: assert orders_list.delete(order_id) == orders_list.delete(order_id).delete(order_id) プロパティの設計についてさらに詳しく知りたい場合は、次のブログ記事をお勧めします。 Choosing Properties for Property-Based Testing 、および How To Specify it [PDF] の論文です。 入力ジェネレーターを使ったプロパティのテスト プロパティをテストするには、具体的な入力値が必要です。多数の（数百の）多様な値を取得し、バイアスの影響を減らすために、PBT フレームワークは「ジェネレーター」を使用します。これは何らかのランダム性を受け取り、特定の型の入力値を生成する関数です。プロパティベーステストフレームワークのユーザーは、特定のプロパティテストを実行する際にどの入力ジェネレーターを使用するかを指定します。Kiro は生成するプロパティテストに対してこれを自動的に行います。 Hypothesis などの PBT フレームワークには、一般的な型用のジェネレーターが多数付属しており、これらを構成要素として使ってより複雑なジェネレーターを作成できます。Hypothesis フレームワークはジェネレーターをストラテジーと呼び、多くの場合、ストラテジーを変数 st に格納します。整数を生成するストラテジーの例をいくつか示します。 >>> from hypothesis import strategies as st >>> st.integers().example() -43489276822011488813107857396380363774 >>> st.integers().example() 1944533851 >>> st.integers().example() 3 >>> st.integers().example() -6029 >>> st.integers().example() -3157022535735084108 >>> st.integers(1,500).example() 271 >>> st.integers(1,500).example() 18 >>> st.integers(1,500).example() 20 >>> st.integers(1,500).example() 350 >>> st.integers(1,500).example() 89 Hypothesis には、カスタムデータ型用のより複雑なストラテジーも付属しています。 >>> st.emails().example() '^3l@s.K.sM' >>> st.emails().example() '~g0}XGSf|m$6wOgvEI`e~8h@Z.roDeO' >>> st.uuids().example() UUID('ff1fe0e9-c9a7-324d-f04d-c6f7c3fa4059') >>> st.uuids().example() UUID('156c8e91-0ad7-24b0-6e59-0e6b6a114e74') >>> st.complex_numbers() complex_numbers() >>> st.complex_numbers().example() (-inf-infj) >>> st.complex_numbers().example() (nan+352724254975j) >>> st.complex_numbers().example() 0j 小さなストラテジーから複雑なストラテジーを構築することもできます。たとえば、 lists ストラテジーは別のストラテジーを引数として受け取り、その引数によって生成されたもののリストを構築します。 >>> st.lists(st.integers()).example() [297324786, 38] >>> st.lists(st.integers()).example() [13158, 3] >>> st.lists(st.integers()).example() [17, 27825, -25292, 30419, -8472, -30306, 6151414495842486117, 1264487630263387308, -10877, 1076876455, -10851] >>> st.lists(st.booleans()).example() [False, False, False, False, True, False, False, False, True, False] >>> st.lists(st.booleans()).example() [False, False, True, True] >>> st.lists(st.booleans()).example() Kiro でのプロパティベーステスト 現在、Kiro は要件をテストするために、プロパティチェックコードとジェネレーターの両方を含むプロパティベーステストを自動的に作成します。先ほどの信号機の例に戻ると、Kiro は先ほど見たプロパティチェックコードを生成するだけでなく、メソッドの上に @given アノテーションを追加し、使用したい 2 つの Hypothesis ストラテジーをリストします。 @given( timing_config=timing_config_strategy(), operations=operation_sequence_strategy() ) def test_safety_invariant_at_most_one_green( timing_config: TimingConfig, operations: list ): 以下は、Kiro がこのプロパティのために書いたストラテジーです。このコードは Hypothesis ストラテジーフレームワークを使用して、信号機の遷移シーケンスに対するストラテジーを構築します。このストラテジーが、Kiro が書いた signal_state_strategy などの他のストラテジーを参照していることがわかります。これにより、複数のプロパティテスト間でコードを共有できます。 # 操作シーケンスを生成するストラテジー @st.composite def operation_sequence_strategy(draw): """制御モジュールに対して実行する操作シーケンスを生成する""" operations = [] num_operations = draw(st.integers(min_value=1, max_value=20)) for _ in range(num_operations): op_type = draw(st.sampled_from(['transition', 'emergency_activate', 'emergency_deactivate'])) if op_type == 'transition': direction = draw(direction_strategy) state = draw(signal_state_strategy) operations.append(('transition', direction, state)) elif op_type == 'emergency_activate': direction = draw(direction_strategy) operations.append(('emergency_activate', direction)) else: # emergency_deactivate operations.append(('emergency_deactivate',)) return operations このテストは、標準的な Python テストフレームワークである pytest とすぐに統合できます。 pytest が実行されると、Hypothesis は 100 個のテストケースを生成し、それらすべてがプロパティをパスすることを確認します。 テストの品質にとって、入力生成ストラテジーが実際に多様な入力を生成することが重要です。 Tyche というツールを使って、それらの入力と実行時にカバーされるコードを調べることで、どれだけうまくいっているかを評価できます。以下は、ジェネレーターが生成した入力のサンプルで、Tyche が表示してくれるものです。 以下は、プロパティベーステストによって実行されるコードを示す Tyche が生成した視覚化です。50 回の試行後でも、まだ新しいコードパスを探索していることがわかります。 コードカバレッジについて注意点があります。テストスイートの効果を測定する非常に一般的な指標ですが、テスト品質の最終的な判断基準ではありません。コードの行をカバーする（つまり実行する）ことは、その行のすべての動作を網羅したことを意味しません。プロパティテストは網羅的な手法ではないため、プログラムにバグがないことを保証できません。プロパティベーステストが見つけられない反例が常に存在する可能性があります。しかし、私たちは、プロパティベーステストが従来の例ベーステストよりもバグの発見において効果的なツールであり、仕様とテストをより良く結びつけ、プログラムの正しさの問題を具体的で実行可能な仕様の観点から表現するという重要なステップを踏んでいると考えています。 反例と縮小 この記事を終える前に、プロパティベーステストの本当に役立つ最後の機能について話したいと思います。それは縮小です。プロパティテストが失敗すると、プロパティを失敗させる入力、つまり反例が得られます。理想的には、最小限の入力、つまりテストを失敗させた問題の核心を示す小さな例が欲しいところです。巨大な反例には問題とは関係のない余分なデータが含まれている可能性が高いのに対し、最小限の例は、あなた（そしておそらく Kiro エージェント）がプログラムの実際の欠陥を特定し、修復するのに役立ちます。ほとんどのプロパティベーステストフレームワークは、「縮小」と呼ばれるプロセスを通じて最小限の例を提供しようとします。これがどのように機能するか見てみましょう。 探索木に基づく集合を実装しているとしましょう。おそらく次のようなプロパティがあるでしょう。 # プロパティ: 任意の2つの二分探索木を結合すると、 # 適切な二分探索木になるべき @given(left = trees(), right = trees()) def test_union_maintains_invariant(left, right): assert left.union(right).is_bst() このテストを実行すると、次のような出力が得られるかもしれません。 Falsifying example: left = Node(lhs=Empty(), rhs=Empty(), value=0) right = Node(lhs=Empty(), rhs=Empty(), value=0) しかし、これは実際には Hypothesis が見つけた最初の反証例ではありませんでした。Hypothesis のログを見ると、最初に失敗した反例は実際には次のようなものでした。 Trying example: test_union( lhs=Node(lhs=Empty(), rhs=Node(lhs=Empty(), rhs=Node(lhs=Empty(), rhs=Empty(), value=30), value=-111), value=-25482), rhs=Node(lhs=Node(lhs=Empty(), rhs=Empty(), value=-26344), rhs=Node(lhs=Empty(), rhs=Node(lhs=Node(lhs=Empty(), rhs=Empty(), value=42), rhs=Node(lhs=Node(lhs=Node(lhs=Empty(), rhs=Empty(), value=6076), rhs=Empty(), value=10768), rhs=Empty(), value=27223), value=121), value=-89), value=-20602), ) これはデバッグがより困難なケースです。 縮小は、失敗を引き起こし続けることを確認しながら、失敗した入力を体系的に単純化します。 この例では、Hypothesis は不要なノードを削除し、整数値を減らし、木構造を単純化して、最小限のケースを見つけました。それは、両方とも値 0 を含む 2 つの単一ノード木です。これにより、複雑な木構造のノイズなしに、核心となる問題、つまり union 操作が重複値を適切に処理していないことが明らかになります。 Kiro がプロパティテストを生成する際、基盤となる PBT フレームワークの縮小機能を活用します。つまり、開発中にプロパティテストが失敗すると、デバッグを大幅に容易にする実用的で最小限の反例が得られます。エージェントはこの最小限の例を使って根本原因をより簡単に理解し、修正を提案でき、仕様、テスト、実装の間に緊密なフィードバックループを作り出します。Kiro が実装は正しいかもしれないが仕様と一致しないことを発見した場合、または AI が生成したコードが自明でない方法で根本的に間違っているように見える場合、Kiro はこれを開発者に提示して選択を求めます。コードを修正するか、仕様を修正するか、PBT を修正するかです。そうすることで、人間の判断と AI および PBT を組み合わせて、実装を開発者の意図により明確に合わせます。 まとめ Kiro がプロパティベーステストを採用したことで、AI コーディングタスクにおける正しさの考え方が大きく変わります。個々の例をチェックすることから、入力空間全体にわたる普遍的なプロパティを検証することへと移行しています。自然言語の仕様を実行可能なプロパティに自動的に変換し、包括的なテストケースを生成することで、Kiro は AI エージェントと人間の開発者の両方がより信頼性の高いソフトウェアを構築するのに役立つ強力なフィードバックループを作り出します。このアプローチは、従来のテストが見逃すバグを見つけるだけでなく、要件とそれらを検証するテストの間に明確で追跡可能なリンクを維持します。PBT はすべてのバグの不在を保証できませんが、例ベーステストだけよりも大幅に強力な正しさの証拠を提供し、仕様駆動開発にとって不可欠なツールとなっています。 LLM とプロパティベーステストに関する詳細については、以下の研究論文を参照してください。 QuickCheck Can LLMs write good PBTs Agentic PBT Use Property-Based Testing to Bridge LLM Code Generation and Validation Tyche Kiro をダウンロード して、 仕様 で プロパティベーステスト を試してみてください。 翻訳は AppDev Consultant の宇賀神が担当しました。

AI 駆動開発ツールの導入を検討している方、または現在 Claude Code を利用しているがガバナンスやコスト管理に課題を感じている方に向けて、AWS 上で Claude Code を活用する 2 つの主要なパターンについて解説します。 本記事は、AI 駆動開発ツールを組織内に導入したい管理者や意思決定者、Claude Code Max プランを利用中でガバナンス面に課題を感じている方、AWS の支払いとソフトウェアライセンスの支払いを一元化したい方を対象としています。Claude Code 自体の使い方や Tips ではなく、エンタープライズ環境での導入パターンと選定基準に焦点を当てて解説していきます。 AWS と Anthropic の戦略的協業 AWS と Anthropic は 深い戦略的協業 を結んでいます。2024 年 11 月時点で、Amazon は Anthropic に総額 80 億ドル、日本円にして 1 兆円以上という大規模な投資を実施しています。ただ単に投資するだけでなく、実際の製品・サービスレベルでの統合も着実に進んでいます。 AWS の生成 AI サービスである Amazon Bedrock では、Anthropic の Claude モデルを提供しており、ファインチューニング、ナレッジベース、エージェント、ガードレールといった Amazon Bedrock の各機能との統合されています。Claude は 3rd party モデルでありながら、セキュアに利用できる仕組みが整っています。お客様の推論データや学習データは、明示的に設定しない限り AWS に保管されませんし、Claude モデルは AWS にホストされているため、Anthropic 側から顧客データを閲覧することはできません。通信は AWS バックボーンを経由し、セキュアな環境で処理されます。 さらに、AWS のグローバルインフラに Claude モデルがデプロイされており、東京・大阪リージョンを含む世界中のリージョンで利用可能です。リアルタイム推論だけでなくバッチ推論にも対応しており、前払い制でスループットを予約することも可能です。Claude 自体は AWS 謹製のアクセラレータである AWS Trainium に最適化されており、高いキャパシティと低いレイテンシーで利用できます。 Anthropic のモデルを AWS 上で利用する際の参考となるコードサンプルやノートブックを集めた  anthropic-on-aws  というリポジトリも公開されています。例えば、「 Claude Code on Amazon Bedrock AgentCore 」というサンプルというサンプルが含まれています。 これは、Claude Code を Amazon Bedrock AgentCore Runtime にデプロイし、ヘッドレスモードで動作させる仕組みです。リクエストを投げると裏側で Amazon Bedrock の Claude モデルが呼び出され、作業結果を Amazon Simple Storage Service (Amazon S3) に保存するという、サーバーレス Claude Code のような構成を実現できます。 他にも、「 Claude Code Advanced Patterns – Complete Implementation Package 」では、Claude Code で利用できるサブエージェントや、スラッシュコマンドのサンプルなどが含まれていたり、「 Claude Sonnet 4.5 Memory Features Demo 」には Claude 4.5 のメモリ機能と AgentCore Memory と連携する方法などが紹介されています。このように、Anthropic Claude を AWS 上で効果的に連携するための方法についても積極的に発信しています。 Claude Code とは さて、本題である Claude Code は、Anthropic が開発している Agentic coding のコマンドラインツールです。最近では VS Code 拡張機能として UI も提供 していたり、 Claude Code on the web というウェブブラウザ上で動作するバージョンもリリースされています。 Claude Code は処理過程で何が行われているかという透明性があり、どのようなアクションを許可するか細かく制御できるという特徴を持っています。また、Anthropic が開発しているだけあって、Claude モデルの能力を最大限に引き出せるように最適化されているのが最大の強みです。 Claude Code は、Anthropic が提唱する MCP (Model Context Protocol) や エージェントスキル といった仕組みを活用できます。MCP は外部データソースやツールとの連携を標準化するプロトコルで、スキルは特定のタスク、例えばドキュメント操作やデータ処理などに特化した機能拡張を提供します。これらを組み合わせることで、幅広いコーディングタスクを処理し、開発タスクを大幅に加速できます。 Claude Code on AWS パターン 1: Amazon Bedrock との連携 基本的な連携方法 Claude Code は、裏側で呼び出す Claude モデルのプロバイダーを切り替えられる柔軟な設計になっています。AWS のクレデンシャルと Amazon Bedrock のモデルアクセス権限を持った状態で、環境変数を指定すると Claude Code が Amazon Bedrock のモデルを利用するように設定できます。 環境変数による設定 # Amazon Bedrock を有効化 export CLAUDE_CODE_USE_BEDROCK=1 # AWS リージョンを指定 export AWS_REGION=ap-northeast-1 # 使用するモデル ID を指定 export ANTHROPIC_MODEL=global.anthropic.claude-sonnet-4-5-20250929-v1:0 チーム全体での設定共有 （.claude/settings.json） チームで同じ設定を使いたい場合は、 .claude  ディレクトリ配下の  settings.json  に記述することで、チーム全体で設定を共有できます。 { "env": { "CLAUDE_CODE_USE_BEDROCK": "1", "AWS_REGION": "ap-northeast-1", "ANTHROPIC_MODEL": "global.anthropic.claude-sonnet-4-5-20250929-v1:0" } } この設定により、Claude Code 起動時に API provider の部分が自動的に AWS Bedrock に切り替わります。 利用可能なモデル Amazon Bedrock 上では、最新の Claude モデルが利用可能になっています。それぞれ特性が異なるため、ユースケースに応じた使い分けが重要です。 画像出典: Introducing Claude Haiku 4.5 Claude Sonnet 4.5 （複雑なエージェントとコーディングに最適） 複雑な推論、高度なコーディングタスク、エージェント型アプリケーションに最適 200K トークンのコンテキストウィンドウ (100 万トークンのベータ版も利用可能) 料金: $3/M Tokens (入力)、$15/M Tokens (出力) ソフトウェア開発ベンチマークの SWE-bench Verified で最高精度を達成 Claude Haiku 4.5 （ほぼ最先端の知能を備えた高速モデル） 前世代の Sonnet 4 より高性能でありながら、2 倍以上の速度で実行可能 200K トークンのコンテキストウィンドウ 料金: $1/M Tokens (入力)、$5/M Tokens (出力) コスト効率を重視しつつ高品質な出力が必要なケースに適している いずれのモデルも、テキストと画像入力、ビジョン機能、多言語対応、Extended thinking 機能をサポートしています。 日本国内クロスリージョン推論 Claude Sonnet/Haiku 4.5 は、日本国内に閉じた東京・大阪リージョン間のクロスリージョン推論にも対応しています。グローバル分散推論オプションに比べて 10% のプレミアム料金が乗るのですが、特に規制産業においては非常に求められていた機能です。 動作イメージとしては、例えば東京リージョンに対して Claude Sonnet 4.5 モデルを呼び出すと、基本は東京リージョンで処理されます。もしリージョンが混んでいた場合は自動的に大阪リージョンにルーティングしてくれます。この時通信は常に AWS バックボーンを経由し、セキュアかつ日本国外に出ないので安心です。この機能を用いて Claude Code 自体も日本国内に閉じた形で利用いただくことができます。 組織導入のための参照アーキテクチャー Claude Code を Amazon Bedrock と連携して利用いただく形式を組織で導入しやすいようにするための参照アーキテクチャーも提供されています。具体的には、社内の Okta、Microsoft Entra ID (旧 Azure AD)、Auth0 といった OIDC プロバイダーと連携して、社内のシングルサインオンの仕組みと統合された形で一時的な認証情報を払い出すためのソリューションとなっています。 ユーザーが Claude Code を使おうとなった時に、まず Entra ID 等の OIDC provider で認証し、ID トークンを Amazon Cognito に渡します。Cognito から一時的な AWS クレデンシャルをもらって、それで Amazon Bedrock の Claude モデルを呼び出すという仕組みです。 Guidance for Claude Code with Amazon Bedrock というページから詳細を確認でき、CloudFormation テンプレートを使ってすぐにデプロイ可能です。 IT 管理者側では、AWS アカウントチームと連携してチームサイズに基づいた必要なクォータ (TPM/RPM) を確保し、ドキュメント化されたガイダンスに従って既存のエンタープライズ ID プロバイダーを使用した安全で一元化されたアクセスを提供します。エンドユーザー向けインストールパッケージを検証・テストして配布するという流れです。 開発者側としては、配布されたパッケージをローカルマシンに展開するだけで利用可能です。macOS、Linux、Windows に対応しており、AWS アカウントへのアクセスは不要です。組織の ID プロバイダーで認証し、一時的なクレデンシャルを受け取って Claude Code にアクセスします。 利用状況監視ダッシュボード シングルサインオンの仕組みだけでなく、利用状況を監視するためのダッシュボードも用意することができます。ここで Claude Code on AWS の導入効果やクォータ管理に関するインサイトを一覧で確認できます。 ダッシュボードでは、トークン利用量やアクティブユーザー数、API コール数、キャッシュ効率といったメトリクスが見れます。時系列データとしてアクティブユーザー数の推移、編集行数の推移、トークン利用量のトータルやモデルごとの値を見て、いつ何がどれくらい使われているかを確認できます。 また、誰がヘビーユーザーで、どのモデルが使われていて、どんなコードが生成されているかを見る項目もあります。開発生産性向上の度合いを測るための指標として、生成行数やコミット数、アクセプト数 (Claude Code の提案を受け入れた回数)、利用時間を確認できます。さらに、API エラーやスロットリング発生回数も見て、そろそろ Amazon Bedrock のクォータの上限緩和をしないといけないな、といった判断材料に使っていただけます。 Claude Code with Amazon Bedrock パターンのメリット Claude Code と Amazon Bedrock を組み合わせるメリットは多岐にわたります。 コスト面 トークン使用量に基づいた従量課金で、スモールスタートが可能 利用状況に応じて段階的にクォータ上限を緩和してスケール可能 使った分だけの支払いで、利用頻度にばらつきがあるチームに最適 セキュリティ・コンプライアンス面 通信が AWS 内に閉じており、データが外部に出ない 日本国内クロスリージョン推論により、データレジデンシー要件を満たせる 高いキャパシティと低レイテンシーを実現 ガバナンス・管理面 社内 SSO との統合ソリューションが提供されている 利用状況の監視ダッシュボードを簡単に構築可能 IAM や VPC など既存の AWS セキュリティ機能を活用できる AWS のサービスレベルのもとで利用可能 導入・運用面 既に Amazon Bedrock を利用している場合、追加設定のみで導入可能 Anthropic との新規契約が不要で、既存の AWS 契約の範囲内で利用可能 CloudFormation テンプレートによる迅速なデプロイが可能 パターン2: AWS Marketplace での購入 Claude for Enterprise プラン Anthropic の SaaS としての Claude を利用するとき、個人プランとして Free、Pro、Max というプランがあり、チームや企業向けのプランとして Team プランと Enterprise プランがあります。この Enterprise プランで各ユーザーにプレミアムシートを購入いただけると Claude Code も利用可能になります。Claude for Enterprise は AWS Marketplace というソフトウェアの売り買いを行えるプラットフォーム上でサブスクライブすることもできるようになっています。 Enterprise プランでは、個人向けプランで使える機能にプラスして、ユーザーの集中管理や請求の一元化といったチーム向けの機能が提供されます。さらに、会社のシングルサインオンとの統合、SCIM (System for Cross-domain Identity Management) を使ったアカウント管理の簡素化、権限管理、監査ログ機能なども利用できます。 Enterprise プラン内では、各ユーザーにスタンダードシートとプレミアムシートを割り当てられます。プレミアムシートのユーザーは Claude Code を定額で利用することが可能です。この Enterprise プランを AWS Marketplace 経由でサブスクライブできるというわけです。 GUI アプリケーションとしての Claude Claude の SaaS 版やデスクトップ版 (claude.ai) ではリッチなチャット UI を提供しています。Claude Code でコード開発やテスト周辺を効率化するだけでなく、GUIアプリケーションを利用してソフトウェア開発ライフサイクル全体を効率化することができます。 例えば、ライブラリやフレームワークについて調査したり、インタラクティブな相談相手として機能してくれます。技術的な質問に即座に答えてもらえるのは、日々の開発で大きな助けになります。上図右側の Artifact という機能を利用すると、データの可視化や UI のモック作成なども行えます。リアルタイムでプレビューを見ながらインタラクティブなプロトタイプを生成できるのは非常に便利です。また、Notion や Google Docs といったナレッジソースと繋いでプロジェクト状況を読み込んだり、Asana にタスクとして登録してカンバンボードで進捗管理するといったこともできます。 開発ライフサイクル全体を見ると、要件定義では外部ドキュメントを参照しながら要件を整理し、設計では Artifact で設計図やモックを作成し、実装では Claude Code でコーディングし、レビューではチャット UI で実装の妥当性を相談し、テストではテストコードの生成と実行を行い、ドキュメントでは技術ドキュメントの作成支援を受け、デプロイではデプロイスクリプトの生成と実行を行うという一連の流れを効率化できます。 Claude Code via AWS Marketplace パターンのメリット AWS Marketplace で Claude for Enterprise を購入するメリットは多数あります。 コスト・予算管理面 ユーザー数課金で予算管理がしやすい定額制 各ユーザーの支払いを一本化できる AWSインフラコストと支払いを一元化可能 機能・利便性面 GUI アプリケーションとしての Claude も利用可能 (チャット UI、Artifact 機能など) SSO、SCIM、監査ログ、ロールベースアクセスがビルトイン Notion や Google Docs などの外部ツール連携 拡張コンテキストウィンドウ 調達・管理面 AWS Marketplace 上で購入プロセスやライセンス管理が完結 ソフトウェア調達プロセスが簡素化される 追加の統合作業が最小限で済む 大規模利用時はプライベートオファーで個別相談可能 注意点 一部直販との細かい機能差がある場合があります シート数の最小数や年間契約のみといった制限があります 詳細な契約内容については AWS / Anthropic の営業にご相談ください 選定基準 Claude Code を AWS 上で利用するには大きく分けて二つのパターンがあるというお話をしてきました。それぞれどのようなケースに適しているのか整理していきます。 Amazon Bedrock パターンが適しているケース Amazon Bedrock と連携するパターンは、従量課金なのでスモールスタートできます。初期投資を抑えて小規模から始めたい場合や、まずは試験的に導入して利用状況を見ながら拡大したい場合に最適です。チーム内での Claude Code 利用頻度にばらつきがあり、ヘビーユーザーばかりではないケースでも、使った分だけ支払うという形式は合理的です。全社展開を見越すなど、ユーザー数が多くなる場合はトークン数ベースで従量課金となるこちらのパターンが適しているでしょう。 セキュリティやデータコントロールの制限がある場合でも、AWS にデータを留めることができます。特にデータを日本国内に留める必要がある規制産業などでは、日本国内クロスリージョン推論が大きな価値を持ちます。VPC や IAM など既存の AWS セキュリティ機能を活用したい場合にも向いています。 また、すでにお使いの Amazon Bedrock 環境を活用したい場合や、Anthropic との新規契約の手続きにハードルがあるケースでは、Amazon Bedrock の連携を検討いただければと思います。既存の AWS 契約の範囲内で利用できるというのは、調達プロセスの簡素化という点で大きなメリットです。 AWS Marketplace パターンが適しているケース 一方、エンタープライズ版を AWS Marketplace でサブスクライブすると、GUI アプリケーションとしての Claude がついてきます。コーディングだけでなく、設計、レビュー、ドキュメント作成なども効率化したい場合、このパターンが適しています。チャット UI、Artifact、外部ツール連携なども活用できるため、開発ライフサイクル全体をカバーできます。 また、定額プランとなるので、一定人数の利用が見込まれていて予算管理を楽にしたい場合はこちらを選んでいただければと思います。チーム全体で頻繁に利用する見込みがあり、ヘビーユーザーが多い場合は、従量課金による変動を避けられる定額制の方が予算計画を立てやすくなります。 必要な機能がビルトインで用意されているのでセットアップの手間を減らすことができます。複雑な統合作業なしに、すぐに使い始めたい場合や、運用負荷を軽減したい場合に向いています。また、AWS インフラコストと同じ請求書で管理したい場合や、社内の調達プロセスが AWS Marketplace 経由を推奨している場合にも最適です。 コスト試算例 実際の導入を検討する際、コストの見積もりは重要な判断材料となります。ここでは典型的なユースケースでの試算例をご紹介します。 Amazon Bedrockパターンでの試算 （10 名チームの月間利用） 前提条件: チームメンバー 10 名 1 人あたり月間平均利用: 20 日、1 日あたり 4 時間 1 日あたりセッション数: 8 セッション (30 分に 1 回程度のやり取り) 平均セッションあたりトークン消費: 入力: 500K トークン (プロジェクトコンテキスト + 会話履歴) 出力: 100K トークン プロンプトキャッシュヒット率: 70% 使用モデル: Claude Sonnet 4.5 月間総トークン数: - 総セッション数: 10 名 × 20 日 × 8 セッション = 1,600 セッション - 入力トークン総量: 1,600 × 500K = 800M トークン - 出力トークン総量: 1,600 × 100K = 160M トークン 入力トークンの内訳（キャッシュ考慮）: - Cache write (30%): 800M × 30% = 240M トークン コスト: 240M × $3.75/MTok = $900 - Cache read (70%): 800M × 70% = 560M トークン コスト: 560M × $0.3/MTok = $168 出力トークンのコスト: - コスト: 160M × $15/MTok = $2,400 合計コスト: - 入力: $900 + $168 = $1,068 - 出力: $2,400 - 合計: $3,468/月（約 520,200 円/月、1 ドル = 150 円換算） Claude Haiku 4.5 を使用する場合は約 1/3 のコスト (約 173,000 円/月) となります。利用頻度にばらつきがある場合、使わない月は安くなる点にも考慮が必要です。 AWS Marketplace パターンでの試算 (10 名チーム) 前提条件: チームメンバー 10 名 全員にプレミアムシート (Claude Code利用可能) を割り当て プレミアムシート単価: $200/月/ユーザー 月間コスト: - 10 名分: $200 × 10 名 = $2,000/月 (約 300,000 円/月、1 ドル = 150 円換算) 定額制のため、使用量にかかわらず予算が確定します。GUI アプリケーションも含めたフル活用が前提であれば、この価格設定が妥当なコストとなります。 参考リソース Claude Code on AWS の導入を検討される際に役立つリソースをご紹介します。 まずは Claude Code の 公式ドキュメント に Getting Started の記事があるので、そこから始めるのが良いかと思います。AWS が用意しているコードサンプルとして  aws-samples/anthropic-on-aws  があり、Anthropic のモデルを AWS 上で利用するための各種サンプルコードが公開されています。 ハンズオンワークショップもそれぞれ利用者向けと管理者向けのものがあります。利用者向けには Claude Code in Action on AWS があり、Claude Code の基本的な使い方を学べる実践ワークショップとなっています。管理者向けには Supercharge your development with Claude Code on Amazon Bedrock があり、OpenTelemetry の設定や管理ダッシュボードの作成、ガバナンス設定、クォータ管理などを取り扱っています。 参照アーキテクチャーと CloudFormation テンプレートは  Guidance for Claude Code with Amazon Bedrock  から入手できます。具体的な導入計画や見積もりについては、AWS の営業担当にご相談ください。 おわりに 本記事では、Claude Code on AWS の 2 つの主要な利用パターンについて解説しました。 Amazon Bedrock との連携パターンは、従量課金によるスモールスタートや、厳格なセキュリティ・データレジデンシー要件がある場合に適しています。既存の AWS 環境との統合が容易で、詳細な利用状況の監視も可能です。 AWS Marketplace での購入パターンは、GUI アプリケーションを含めた総合的な活用や、定額制による予算管理の簡素化を求める場合に適しています。エンタープライズ向け機能がビルトインで提供されるため、セットアップの手間を大幅に削減できます。 どちらのパターンも、AWS と Anthropic の戦略的協業により、セキュアで高品質な AI 駆動開発環境を実現できます。AWS 側も Claude のサポートに力を入れており、豊富なドキュメントやワークショップが用意されています。Claude Code 導入を検討される際は、ぜひ AWS の営業担当にご相談ください。両パターンのメリット・デメリットを踏まえて、皆様のニーズに最適な選択をすることが、AI 駆動開発の成功への第一歩となります。

金融機関では近年、デジタル化の進展に伴いリスク環境が急速に変化しています。障害への未然防止策に重点を置いた従来的なリスク管理や事業継続計画（BCP）だけでは、重要な業務を提供し続けられない可能性が出てきており、障害の早期復旧や影響範囲の軽減確保を重視する、オペレーショナル・レジリエンスという考え方が近年注目されています。 AWS では、オペレーショナル・レジリエンスに関心の高いお客様向けに、AWS の取り組みを紹介するオペレーショナル・レジリエンス ワークショップを提供しております。この度、アフラック生命保険株式会社様（以下、アフラック様）と共に、本ワークショップを2025年9月中に2回開催しました。本稿ではこちらのワークショップの開催報告をお届けします。 オペレーショナル・レジリエンスとは オペレーショナル・レジリエンスという考え方は、金融機関を取り巻くリスク環境の複雑化を背景に国際的に注目されるようになりました。ITシステムへの依存の高まり、大規模システム障害の発生、サイバーセキュリティ上の脅威の増大、クラウドサービスの利用拡大など、従来のリスク管理やBCPだけでは対応しきれない新たな課題が顕在化したためと言われています。 既存のリスク管理では障害への未然防止策に重点が置かれ、想定外の事象が発生した際に金融システムにとって重要な業務を継続できない可能性があり、利用者目線での早期復旧という視点も十分ではありませんでした。 金融庁のホワイトペーパー では、オペレーショナル・レジリエンスについて「未然防止策を尽くしてもなお、業務中断は必ず起こることを前提に、利用者目線に立ち、代替手段等を通じた早期復旧や影響範囲の軽減を担保する枠組みを確保すること」と記載しています。さらには、ゼロリスク志向からリスク管理文化を醸成することや、経営陣のコミットメントが必要であるとも記載しています。 AWS は以前からオペレーショナル・レジリエンスの実現に積極的に取り組んでいます。過去にも AWS のレジリエンシーを全体的に解説したセミナーを開催しておりますので、こちらも併せてご参照ください。 参考資料：金融インダストリー向け クラウドを活用したレジリエンシーの最新動向 https://aws.amazon.com/jp/blogs/news/20230615-fin-resilience-webiner-post/ ワークショップの内容 今回のワークショップにご協力いただいたアフラック様は、以前 AWS Summit Japan 2024 にもご登壇いただきました。その際に、「2027年までにクラウド化による効果が大きい全システムの移行を目標とし、全社を挙げて推進中」であるとご説明いただきました。クラウドを積極的にご利用されているアフラック様においても、オペレーショナル・レジリエンスへの関心が高く、今回のワークショップ開催につながりました。ここからは、アフラック様と2回開催したワークショップの内容についてご説明します。 1回目（9月26日）は東京のアマゾン ウェブ サービス ジャパン合同会社 本社で開催し、アフラック様の ITインフライノベーション部から 7 名の皆様にご参加いただきました。同部門は AWS 環境を含めた IT インフラの企画・運用という重要な役割を担っています。 2回目（9月30日）はアフラック様の BCP 拠点である札幌システム開発オフィスで開催し、ITインフライノベーション部、ITインフラ運用管理部、営業システム開発部、顧客・代理店システム開発部、勘定系システム開発部、契約管理システム開発部、その他セキュリティ部門の方々から 18 名の皆様にご参加いただきました。同オフィスは、首都圏での災害リスクに備えた戦略的拠点として、東京拠点と同水準の環境を整備されています。 ワークショップは以下の 2 パートに分かれています。 前半パートでは、AWS 側が国内外の金融機関のお客様や規制当局との会話で培った知識として、オペレーショナル・レジリエンスに関する規制動向と、各金融機関の対応状況、これまでのリスク管理や BCP との違いについて、プリンシパルコンプライアンススペシャリストの高野からご説明しました。また、オペレーショナル・レジリエンスのメンタルモデルや、オンプレミスとクラウドにおける障害対応の違いについても紹介し、AWS のレジリエンスが規制当局からも評価されていることを紹介しました。 後半パートでは、AWS のサービス、インフラストラクチャ、運用体制について、ソリューションアーキテクトの松本から、ホワイトボーディングによるレクチャーとディスカッションを実施しました。具体的には、リージョン・アベイラビリティーゾーン内の各構成要素が全て冗長化されていることや、AWSの各サービスにおけるレジリエンシー強化のためにセルベースアーキテクチャを採用していること、AmazonのTwo-pizza teamという考え方を中心にしたAWSサービスの開発と運用モデルといった観点をご紹介しました。さらに、アフラック様から AWS のレジリエンスに対する疑問や懸念を挙げていただき、最新の AWS の取り組みを踏まえてご回答しました。 ワークショップのフィードバック 第1回のフィードバック 参加されたITインフライノベーション部の皆様からは、経営層をはじめとする方々からの懸念として、「クラウドが長時間止まるリスク」「東京リージョンから大阪リージョンへの切り替え後のレイテンシへの影響」「クラウドのサービスアップデートに追従できないリスク」といった課題をご共有いただきました。これらの課題に対し、AWSの取り組みや考え方もお伝えしながら、建設的な議論が展開されました。 ITインフライノベーション部部長の藤田昌孝様からは、以下のようなコメントをいただきました。 今回のワークショップを通じて、AWSのオペレーショナル・レジリエンスに対する考え方や、実際のインフラストラクチャ、運用体制について、非常に具体的かつ分かりやすいご説明をいただきました。特に、単なる技術的な側面だけでなく、経営戦略や顧客価値向上の観点からもレジリエンスを捉える重要性を再認識することができました。 また、クラウドサービスの可用性や障害対応、リージョン切り替え時の課題など、我々が日頃抱えている懸念点についても率直に議論できたことは大きな収穫でした。AWSの内部でどのような工夫や仕組みがあるのか、普段はなかなか知ることのできない情報にも触れることができ、透明性が高まったと感じています。 AWSとのディスカッションによって、世界の金融機関のAWS利用状況や利用方法、金融庁をはじめとした官公庁の関心事など、多様な視点を学ぶことができました。今後は、今回得られた知見を社内に展開し、上位層や若手社員にも積極的に参加を促していきたいと考えています。 アフラックとしても、AWSとの連携をさらに深めることで、単なるコスト削減にとどまらず、ビジネス拡大やイノベーション創出、そして事業継続性の強化につなげていきたいと思います。今後も継続的な改善活動や新たな技術へのチャレンジを通じて、お客様本位のシステム提供を目指してまいります。 第2回のフィードバック 札幌での開催では、AWSの運用体制や障害対応方法、セキュリティ、地政学的リスクなどについて、実際の運用現場での課題解決に向けた具体的な知見と事例等の相談をいただき、これらの課題に対し議論を展開、参加者の皆様から以下のような高い評価をいただきました。 「普段は社内に閉じた議論になりがちなところ、世界的な潮流や、官公庁のスタンスなど、幅広い考え方を聞けて大変参考になりました」 「基礎の部分からわかりやすく、多方面の視点にて説明いただき、理解がとても進みました。上位層や若手にも参加を促したい内容でした」 「具体的なAWSのサービス紹介ではなく、思想や大まかな仕組み、AWS内部の工夫や進め方について解説いただき、公開されてはいると思いますが、調べても簡単には辿り着けない話が聞けて、透明度があがりました」 「非常にわかりやすいご説明で、AWSの可用性がなぜここまで高いのかをよく理解できました。会社としてもこのようなメンタルモデルを採用できると、よりお客様本位のシステムを提供できると感じました」 スピーカーからのコメント 今回のワークショップのスピーカーを務めたプリンシパルコンプライアンススペシャリストの高野 敦史は、アフラック様の取り組みについて次のように述べています。 「アフラック様のように 、AWS をご活用いただくことで、単なるランニングコストの削減にとどまらず、ビジネス拡大やイノベーションの創出、オペレーショナル・レジリエンスの強化による事業継続性の向上にも寄与します。今後も AWS としてもアフラック様のレジリエンシー強化をご支援し、アフラック様のデジタル変革戦略の成功に貢献してまいります。」 今後のアクションプラン 今回のワークショップの成果を踏まえ、両社で今後のアクションプランを整理しました。 AWS Countdown Premium や AWS Incident Detection and Response といったAWSの支援プログラムを検討いただくとともに、クラウド障害対応訓練の実施といった継続的な改善活動を行う予定です。また、ワークショップ中に話題になった PQC（耐量子計算機暗号）の対応推進も予定しています。 まとめ アフラック様との今回のワークショップは、金融機関におけるオペレーショナル・レジリエンス強化の重要性と、AWS の活用がオペレーショナル・レジリエンスにも貢献することを示す貴重な機会となりました。東京・札幌両会場での参加者の皆様には積極的に議論いただくことができ、アフラック様におけるレジリエンスへの熱量を感じることができました。札幌会場では「会社としてもこのようなメンタルモデルを採用できると、よりお客様本位のシステムを提供できると感じました」というコメントもいただき、オペレーショナル・レジリエンスが単なる技術課題ではなく、顧客価値向上のための経営戦略の一部であることを理解いただくことができました。 2027年までにクラウド化による効果が大きい全システムの移行という野心的な目標を掲げるアフラック様の戦略的取り組みが、金融業界全体のデジタル変革をリードし、お客様により安心・安全な金融サービスを提供する礎となることを確信しております。 運営チーム / ブログ著者 スピーカー： 高野 敦史 (Atsushi Takano) アマゾン ウェブ サービス ジャパン合同会社 プリンシパルコンプライアンススペシャリスト メガバンク、米系監査法人およびコンサルティングファームにおいて、長年にわたり一貫して金融分野のIT、リスク、セキュリティ領域に従事。現在はAWSにて、お客様のクラウドコンプライアンスを支援しています。 松本 耕一朗 (Koichiro Matsumoto) アマゾン ウェブ サービス ジャパン合同会社 ファイナンシャルサービスインダストリー技術本部 ソリューションアーキテクト AWSを活用することでお客様がご自身のレジリエンスを向上させていくための支援を行っています。普段は銀行業界のお客様を担当しています。 著者 ： 広恵 幸輝 (Kohki Hiroe) アマゾン ウェブ サービス ジャパン合同会社 金融事業統括本部 保険営業本部 アカウントエグゼクティブ 金融機関・保険グループを担当するアカウントエグゼクティブとして、クラウドを通じたビジネス革新から、Amazon.comとの戦略的協業まで、お客様のデジタルジャーニーを包括的に支援しています。 遠藤 亘 (Wataru Endo) アマゾン ウェブ サービス ジャパン合同会社 ファイナンシャルサービスインダストリー技術本部 ソリューションアーキテクト 保険業界のお客様を担当しているソリューションアーキテクトです。AWS全般を活用いただく際の技術的な課題解決に加えて、コンタクトセンターソリューションである Amazon Connect の利用も支援しています。 今井 勇太 (Yuta Imai) アマゾン ウェブ サービス ジャパン合同会社 シニアカスタマーソリューションマネージャー システム開発やコンサルティングに従事した経験に基づき、金融業界のお客様のクラウド活用の企画からプロジェクトの立ち上げ・推進まで、幅広いフェーズで様々な課題の解決をご支援しています。

はじめに AWS 上の SAP 運用を最適化するには、効率的な監視、トラブルシューティング、およびメンテナンス機能が必要です。 part 1 での Amazon CloudWatch Application Insight に関する以前の議論、 part 2 での CloudWatch Application Insight を使用して SAP 高可用性を監視する方法、および part 3 での Amazon CloudWatch Model Context Protocol (MCP) Server と Amazon Q for command line (Q CLI) に基づき、この第4回では、これらのツールの高度な実世界のアプリケーションを実演します。実用的なユースケースを通じて、この統合が SAP メンテナンス計画をどのように効率化し、根本原因分析を加速するかを探ります。 詳細な例を通じて、CloudWatch MCP Server と Q CLI がどのように連携して以下を実現するかを示します： 最小限の中断で計画的なメンテナンスイベントを調整 インテリジェントなログ分析を通じて問題診断を高速化 SAP 運用のためのコンテキストに応じた推奨事項を提供 SAP インシデントの平均解決時間を短縮 ユースケース 3: SAP の計画的メンテナンスイベント このユースケースでは、SAP アプリケーションクラスターで計画的メンテナンスイベントを実行します。ワークフロー統合により、チームは IDE で CloudWatch メトリクスを直接表示しながら、Q CLI を使用して正確な修復コマンドを生成することで、破壊的なコンテキスト切り替えなしに問題を診断できます。このシナリオでは、Q CLI は次のようにタスクリストを作成しました： App Server のステータスを確認するプロンプト aws ec2 describe-instances を実行して SAP クラスターステータスを確認 ssm コマンド crm_mon を実行して ASCS と ERS クラスターを確認 ssm コマンド ps を実行して ASCS と ERS プロセスステータスを取得 ssm コマンド sapcontrol を実行してプロセスリストを取得 ssm コマンドを実行して pacemaker.log を確認 ssm コマンド crm を実行してクラスターリソースステータス、制約、構成を確認 誤ったクラスター構成のため ERS が無効になっていることを要約 CloudWatch ログを確認するプロンプトの後 describe_log_groups を実行 analyze_log_groups を実行 ASCS と ERS に関連する execute_log_insights_query を検索実行 手元の ERS 問題に関連する execute_log_insights_query を検索実行 ERS 問題に関連するすべてのログエントリを要約 SAP ERS サービスを起動するプロンプトの後 ssm コマンド crm を実行してクラスターリソースステータスを確認 ssm コマンド crm を実行して ERS リソースを有効化（予想通り失敗） ssm コマンドを実行してリソース構成を更新 ssm コマンド crm を実行して ERS リソースを有効化（構成修正後） ssm コマンド sapcontrol を実行して ASCS と ERS のプロセスリストを取得 ERS サービスが正常に起動したことを要約 重要な注意事項： 以下のプロンプトと応答は短縮されています。完全なプロンプトと Q CLI からの応答を確認するには、この ユースケース 3 – SAP の計画的メンテナンスイベント をダウンロードしてください。 プロンプト: サービスを再起動せずに、SAPDemo SAP アプリケーションの SAP ASCS/ERS クラスターのステータスを確認します。 > I'll check the status of the SAP ASCS/ERS cluster for the SAPDemo SAP application without restarting any services. 🛠 Using tool: execute_bash (trusted) ⋮ ● I will run the following shell command: aws ec2 describe-instances --filters "Name=tag:Name,Values=*SAP-FIS-CS*" --query "Reservations[*].Instances[*].[InstanceId,Tags[?Key=='Name'].Value|[0],State.Name,InstanceType,PrivateIpAddress]" --output table ⋮ ↳ Purpose: Checking EC2 instances that are part of the SAP cluster ------------------------------------------------------------------------------------------- | DescribeInstances | +----------------------+-------------------------+----------+-------------+---------------+ | i-064751ba1b4c8340f | SAP-FIS-CS-sapclnode2 | running | c5a.xlarge | 10.0.155.180 | | i-0e08f883d5c3b3747 | SAP-FIS-CS-sapclnode1 | running | c5a.xlarge | 10.0.134.80 | +----------------------+-------------------------+----------+-------------+---------------+ ⋮ ● Completed in 1.666s …… ## Conclusion The SAP ASCS/ERS cluster for the SAPDemo application is partially operational: • The ASCS instance is running correctly on sapclnode2 • The ERS instance is intentionally disabled (target-role=Stopped in the configuration) • The virtual IP for ERS is still active on sapclnode1 • Both cluster nodes are online and the cluster has quorum This configuration appears to be intentional based on the cluster configuration, but it means that enqueue replication is not currently active. In a normal high-availability setup, both ASCS and ERS would be running to ensure enqueue table replication in case of a failover. 次のシナリオでは、CloudWatch MCP Server を使用して pacemaker クラスターログを調査し、SAP ASCS のステータスを判断します。CloudWatch MCP サーバーは、describe_log_groups、analyze_log_groups、execute_log_insights_query などのツールを呼び出して分析を行います。 プロンプト: SAPDemo アプリケーションの SAP ASCS ERS Pacemaker クラスターイベント、アラーム、問題に関連する CloudWatch ログを確認します。 > Check CloudWatch logs related to SAPDemo application for SAP ASCS ERS Pacemaker cluster events, alarms and issues. only use cloudwatch mcp server for this analysis. > I'll analyze the CloudWatch logs related to the SAPDemo application for SAP ASCS ERS Pacemaker cluster events, alarms, and issues using only the CloudWatch MCP server. Let's start by identifying the relevant log groups for the SAPDemo application: 🛠 Using tool: describe_log_groups (trusted) from mcp server awslabscloudwatch_mcp_server ⋮ ● Running describe_log_groups with the param: ⋮ { ⋮ "arguments": { ⋮ "log_group_name_prefix": "PACEMAKER", ⋮ "region": "us-east-1" ⋮ }, ⋮ "name": "describe_log_groups" ⋮ } ⋮ ● Completed in 0.760s …… ### Analysis: This log data shows that the ERS component (rsc_sap_ECD_ERS11) has been successfully started on sapclnode1. The cluster first cleared previous failure records, then migrated the IP resource (rsc_ip_ECD_ERS11) from node 2 to node 1, and finally started the ERS service on node 1. The successful start is confirmed by the @rc-code=0 in the logs, indicating no errors. The monitoring operation is also successful, showing that the service is running properly. This aligns with our previous findings where we had identified issues with the ERS component and cleared CloudWatch alarms for it. The logs now confirm that the ERS service has been successfully started and is being monitored by the cluster, which explains why the service is now running despite previous alarms. Would you like me to analyze any specific aspect of these logs in more detail or provide recommendations for ongoing monitoring of the ERS component? プロンプト: ノード sapclnode1 で SAP ERS サービスを起動します。 > start SAP ERS services on node sapclnode1 > I'll start the SAP ERS services on node sapclnode1. 🛠 Using tool: execute_bash (trusted) ⋮ ● I will run the following shell command: aws ssm send-command --instance-ids i-0e08f883d5c3b3747 --document-name "AWS-RunShellScript" --parameters 'commands=["sudo crm resource status rsc_sap_ECD_ERS11"]' --output json ⋮ ↳ Purpose: Checking the current status of the ERS resource .. …… ## Conclusion The SAP ERS services have been successfully started on node sapclnode1. The enqueue replication is now active and functioning correctly, providing high availability for the SAP enqueue service. The cluster is now in a fully operational state with all resources running as expected. ユースケース 4: SAP の根本原因分析を加速 このシナリオでは、構成エラーにより ERS が障害に遭遇した SAP アプリケーションクラスターがあります。Q CLI と CloudWatch MCP Server の統合により、複雑な SAP ランドスケープにおける従来の診断上の課題が解消されます。問題は多くの場合、複数のシステムレイヤーにわたってカスケードします。Q CLI は次のようにタスクリストを作成しました： App Server のステータスを確認するプロンプト aws ec2 describe-instances を実行して SAP クラスターステータスを確認 ssm コマンド crm_mon を実行して ASCS と ERS クラスターを確認 ssm コマンド sapcontrol を実行してノード 1 と 2 のプロセスリストを取得 ssm コマンド crm を実行してクラスターリソースステータスとログを確認 ssm コマンドを実行して pacemaker.log を確認 ssm コマンド crm を実行してリソースをクリーンアップ ssm コマンド crm_mon を実行してクラスターステータスを確認 ssm コマンド sapcontrol を実行してノード 2 のプロセスリストを取得 構成問題による分析結果を要約 この問題をトラブルシューティングするプロンプトの後 ssm コマンドを実行してノード 2 の ASCS と ERS の SAP システムログを確認 ssm コマンドを実行して ASCS と ERS の SAP プロファイルを確認 ssm コマンドを実行してノード 2 の hosts ファイルのホスト名構成を確認 ssm コマンドを実行してノード 1 と 2 の IP アドレスを確認 ssm コマンドを実行してノード 1 と 2 の hosts ファイルを更新 ssm コマンド crm_mon を実行してリソースをクリーンアップ ssm コマンド sapcontrol を実行してノード 2 のプロセスリストを取得 ssm コマンド sapcontrol を実行して ERS サービスを起動し、ログを確認 ssm コマンド sapcontrol を実行して ASCS を起動し、ログを確認 ssm コマンド crm_mon を実行してクラスターを停止し、ステータスを確認 ssm コマンド crm_mon を実行してクラスターリソースをクリーンアップ ssm コマンド crm_mon を実行してクラスターを起動し、待機して確認 ssm コマンド sapcontrol を実行してノード 1 の ASCS プロセスリストを取得 ssm コマンド sapcontrol を実行して ASCS サービスを起動し、確認 問題を修復するための推奨事項を要約 SAP ERS サービスを起動するプロンプトの後 ssm コマンド crm を実行して ASCS と ERS クラスターリソースを停止 ssm コマンドを実行してノード 1 と 2 の hosts ファイルを検証および更新 ssm コマンドを実行してノード 1 と 2 のホスト名解決をテスト（最初は更新に失敗したが、別のアプローチで再試行） ssm コマンドを実行して ASCS と ERS の SAP プロファイルを確認 ssm コマンド crm_mon を実行してクラスターリソースをクリーンアップ ssm コマンド sapcontrol を実行して SAP ASCS と ERS リソースを起動し、検証 ASCS と ERS サービスが正常に起動したことを要約 重要な注意事項： 以下のプロンプトと応答は短縮されています。完全なプロンプトと Q CLI からの応答を確認するには、この ユースケース 4 – SAP のRoor Cause Analytics を加速 をダウンロードしてください。 図5. SAP Central Services (ASCS/ERS) エラーステータス プロンプト: SAP アプリケーション SAPDemo の SAP ASCS ERS クラスターノードの現在のステータスは何ですか。 > what is the current status of SAP ASCS ERS cluster nodes for sap application SAPDemo. > I'll check the current status of the SAP ASCS/ERS cluster nodes for the SAPDemo SAP application. 🛠 Using tool: execute_bash (trusted) ⋮ ● I will run the following shell command: aws ec2 describe-instances --filters "Name=tag:Name,Values=*SAP-FIS-CS*" --query "Reservations[*].Instances[*].[InstanceId,Tags[?Key=='Name'].Value|[0],State.Name,InstanceType,PrivateIpAddress]" --output table ⋮ ↳ Purpose: Checking EC2 instances that are part of the SAP cluster ------------------------------------------------------------------------------------------- | DescribeInstances | +----------------------+-------------------------+----------+-------------+---------------+ | i-064751ba1b4c8340f | SAP-FIS-CS-sapclnode2 | running | c5a.xlarge | 10.0.155.180 | | i-0e08f883d5c3b3747 | SAP-FIS-CS-sapclnode1 | running | c5a.xlarge | 10.0.134.80 | +----------------------+-------------------------+----------+-------------+---------------+ ⋮ ● Completed in 1.815s …….. ## Current State Summary The SAP ASCS/ERS cluster for SAPDemo is currently in a degraded state: • The cluster infrastructure (corosync/pacemaker) is functioning correctly with quorum • Both nodes are online and communicating • The virtual IP addresses for both ASCS and ERS are properly assigned • However, the actual SAP services (ASCS and ERS) are failing to start • The application servers are showing YELLOW status, likely due to their dependency on the central services This indicates a problem with the SAP services themselves rather than with the cluster infrastructure. The services may be failing to start due to configuration issues, file system problems, or other SAP-specific issues that need to be investigated further. プロンプト: この問題のトラブルシューティングを手伝ってください。 > help me troubleshoot this problem > I'll help you troubleshoot the issues with the SAP ASCS/ERS cluster for the SAPDemo application. Based on the current state, both the ASCS and ERS services are failing to start properly, even though the cluster infrastructure itself is functioning correctly. Let's take a systematic approach to troubleshooting: ## Step 1: Check SAP-specific error logs First, let's check the SAP system logs to understand why the services are failing to start: 🛠 Using tool: execute_bash (trusted) ⋮ ● I will run the following shell command: aws ssm send-command --instance-ids i-064751ba1b4c8340f --document-name "AWS-RunShellScript" --parameters 'commands=["sudo su - ecdadm -c \"tail -50 /usr/sap/ECD/ASCS10/work/dev_ms\""]' --output json ⋮ ↳ Purpose: Checking SAP system logs for ASCS on node 2 .. > Now let's check the ERS logs: …….. > Based on my troubleshooting, I've identified the root cause of the issues with your SAP ASCS/ERS cluster and can provide you with a comprehensive solution: # SAP ASCS/ERS Cluster Troubleshooting Report ## Root Cause Analysis After thorough investigation, I've identified that the primary issue is related to hostname resolution. The error message MsSInit: NihostToAddr rc=(NIEHOST_UNKNOWN) in the ASCS logs clearly indicates that the Message Server cannot resolve its hostname. ### Specific Issues Identified: 1. Hostname Resolution Problems: • The SAP profiles are configured to use the hostnames ecdascsnode and ecdersnode, but these hostnames were not properly defined in the /etc/hosts files on both nodes. • We've updated the hosts files, but the SAP services are still failing to start properly. 2. IP Address Configuration: • The virtual IPs (192.168.48.201 for ASCS and 192.168.48.202 for ERS) are not being properly managed by the cluster. • Both virtual IPs are currently assigned to node 1 (sapclnode1), which is causing conflicts. 3. SAP Profile Configuration: • The SAP profiles are using hostnames that don't match the actual hostnames of the cluster nodes. • The ERS service is trying to connect to the ASCS service but failing with "Connection refused" errors. プロンプト: 上記のソリューションを適用して問題を修正します。 > apply the above solution to fix the problem > I'll apply the solution to fix the SAP ASCS/ERS cluster issues. Let's follow the step-by-step plan: ## Step 1: Stop the cluster resources > I need to use SSM to execute these commands on the cluster nodes: 🛠 Using tool: execute_bash (trusted) ⋮ ● I will run the following shell command: aws ssm send-command --instance-ids i-0e08f883d5c3b3747 --document-name "AWS-RunShellScript" --parameters 'commands=["sudo crm resource stop rsc_sap_ECD_ASCS10 && sudo crm resource stop rsc_sap_ECD_ERS11"]' --output json ⋮ ↳ Purpose: Stopping the cluster resources using SSM .. > ## Step 2: Verify the hosts file configuration on both nodes …… > Great! The solution has been successfully applied and the SAP ASCS/ERS cluster is now working correctly. Here's a summary of what we did: ## Summary of the Fix 1. Fixed Hostname Resolution: • Updated the /etc/hosts files on both nodes with the correct mappings for all hostnames. • Verified that hostname resolution was working correctly by pinging the virtual hostnames. 2. Cleaned Up and Restarted Cluster Resources: • Stopped the cluster resources to ensure a clean state. • Cleaned up any failed resource actions. • Started the resources in the correct order: ASCS first, then ERS. 3. Verified the Services: • Confirmed that both the ASCS and ERS services are now running correctly. • The system instance list shows all components are GREEN (running). ## Current Status • **Cluster Status**: All resources are running correctly. • **ASCS Status**: The Message Server and Enqueue Server are both running on node 2 (sapclnode2). • **ERS Status**: The Enqueue Replication Server is running on node 1 (sapclnode1). • **Virtual IPs**: The virtual IPs are correctly assigned to the appropriate nodes. ## Recommendations for Long-term Stability 1. Regular Monitoring: Set up monitoring for the cluster to detect any issues early. 2. Failover Testing: Regularly test failover scenarios to ensure the cluster works correctly. 3. Documentation: Document the cluster configuration and troubleshooting steps for future reference. 4. DNS Resolution: Consider implementing proper DNS resolution instead of relying on /etc/hosts files. The SAP ASCS/ERS cluster for the SAPDemo application is now functioning correctly. The issue was primarily related to hostname resolution, which we've fixed by properly configuring the hosts files on both nodes. 図6. 正常な状態の SAP Central Services (ASCS/ERS) クラスターの最終ステータス コスト考慮事項 このソリューションを実装するには、以下を考慮する必要があります： Amazon Q CLI の価格は このリンク に反映されています。月あたり 1,000 のエージェントリクエストを含む Pro バージョン（ユーザーあたり月額 $19）を少なくとも推奨します。 Amazon CloudWatch の価格は このリンク に反映されています。このテストでは、無料利用枠で十分であると想定しています。 AWS Systems Manager の価格は このリンク に反映されています。HA テストでは、最低 6 ノードを管理すると想定でき、$0.01137 * 6 * 8 時間 = $3.27456 となります。 Amazon CloudWatch MCP Server の使用に追加コストはありません。 us-east-1 で SAP Netweaver の HA をセットアップするコストは以下のように見積もられます： 2 x m5.large = $148.16（ASCS と ERS） 2 x m5.xlarge = $280.32（2 つのアプリケーションサーバー） 2 x r5.2xlarge = $756.32（SAP HANA プライマリとセカンダリ） 推定総コスト = $19 + $3.27456 + $39.4933 = $61.76786（1 日のテスト） まとめ CloudWatch MCP Server は、クライアント環境で SAP ランドスケープ全体にわたる統一された可視性を提供します。SAP アプリケーションログ、SAP HANA メトリクス、AWS EC2 パフォーマンスデータを統合します。システムは SAP コンポーネント全体でメトリクスを自動的に相関させます。Q CLI は、この豊富なデータセットとの自然言語インタラクションを可能にすることでこれを補完し、チームがダイアログ応答時間を簡単に調査したり、HANA メモリ消費パターンを比較したり、パフォーマンス問題中に待機状態の SAP ワークプロセスを特定したりできるようにします。 CloudWatch MCP Server は、システムログとトランザクション障害のパターンを分析して異常を特定することで、複雑な SAP インシデントのトラブルシューティングに役立ちます。インフラストラクチャアラートとアプリケーション動作を相関させます。さらに、過去の類似インシデントからの履歴コンテキストを提供します。Q CLI は、SAP エラーコードを解釈し、観察されたパターンに基づいて診断コマンドを生成し、根本原因を提案し、より深い調査のための関連する SAP トランザクションコードを推奨することで、この機能を強化します。 この統合は、SAP システムの共有運用ビューを作成し、SAP 用語と AWS 概念の間を翻訳することで、SAP BASIS 管理者と AWS インフラストラクチャチーム間の知識ギャップを埋めます。この組み合わせにより、コンテキストの切り替えを排除し、SAP 固有のパターンのインテリジェントな分析を提供し、監視データとの自然言語インタラクションを可能にすることで、平均解決時間が短縮され、インシデント解決の高速化、信頼性の向上、AWS 上のミッションクリティカルな SAP ワークロードのより効率的な運用が実現されます。 次のステップとして、このソリューションを試してみてください。このソリューションにより、少なくとも 6 倍の生産性を達成できます。 Amazon CloudWatch 、 AWS Model Context Protocol Servers 、 Amazon Q for command line に関する今後のイノベーションにご期待ください。 SAP on AWS ディスカッションに参加 お客様のアカウントチームと AWS サポートチャネルに加えて、最近 re:Post – AWS コミュニティのための再構想された Q&A エクスペリエンスを開始しました。AWS for SAP ソリューションアーキテクチャチームは、お客様とパートナーを支援するために回答できるディスカッションや質問について、AWS for SAP トピックを定期的に監視しています。サポート関連でない質問がある場合は、re:Post でのディスカッションに参加し、コミュニティナレッジベースに追加することを検討してください。 謝辞 次のチームメンバーの貢献に感謝します：Sreenath Middhi、および Adam Hill。 タグ #SAP Netweaver , AWS Systems Manager , CloudWatch , SAP , SAP High Availability 本ブログは Amazon Q Developer CLI による機械翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

はじめに 今日の複雑な SAP 環境において、効率的な運用と迅速なトラブルシューティングは、ビジネス継続性にとって極めて重要です。SAP オブザーバビリティ（ part-1 英語 ）と Amazon CloudWatch Application Insights の機能（ part-2 英語 ）に関する以前の議論に基づき、この第3回では、チームが SAP ランドスケープを管理する方法を革新する強力なツールの組み合わせを紹介します：Amazon CloudWatch Model Context Protocol (MCP) Server と Amazon Q for command line (Q CLI) です。 この革新的なソリューションは、SAP 運用における3つの主要な課題に対処します： 運用タスクを遅らせる複雑なコマンド構文 複数のツールとコンテキストを必要とする時間のかかる根本原因分析 効率化されたヘルスモニタリングとレポーティングの必要性 このブログでは、以下について説明します： CloudWatch MCP Server と Q CLI がどのように連携して SAP 運用を簡素化するか 自動化されたヘルスレポート作成の実用的なユースケースを実演 自然言語コマンドが日常的なメンテナンスタスクをどのように効率化できるか このソリューションが SAP 向けにAWS Well-Architected Framework とどのように整合しているか シリーズの 第4回 では、メンテナンス計画、高度な根本原因分析、およびこのソリューションを実装するための詳細なコスト考慮事項に焦点を当てます。 図1. Amazon CloudWatch MCP Server と Amazon Q for CLI のアーキテクチャ図 Amazon Q for CLI (Q CLI) とは？ Amazon Q CLI は、AI アシスタンスをコマンドラインワークフローに直接統合することで、AWS のお客様に変革的な価値を提供します。ユーザーは自然言語でコマンドを表現でき、Q がそれを適切な CLI 構文に変換するため、学習曲線が短縮されます。このツールは、ユーザーの意図に基づいてコンテキストに応じたコマンド提案を提供し、時間のかかるドキュメント検索を不要にします。エラーが発生した場合、Q は明確な説明と修復手順を提供し、トラブルシューティングを加速します。 コマンドを理解しやすいコンポーネントに分解し、理解とスキル開発を強化します。ユーザーをターミナル環境内に留めることで、Q は外部リソースへの破壊的なコンテキスト切り替えを排除し、ワークフローを最適化します。 この生産性の向上により、構文例の検索やトラブルシューティングの問題に費やす時間が削減され、開発者はコマンド構造に時間を費やすのではなく、構築に集中できます。Q のインタラクティブな性質により、学習プロセスが加速され、ユーザーは AWS CLI により迅速に習熟できます。最終的に、Amazon Q CLI は、コマンドライン体験を潜在的な障壁から直感的なインターフェースに変換し、あらゆる専門知識レベルのお客様にとって AWS サービスをより利用しやすく効率的にします。 図2. Amazon Q CLI プロンプト Amazon CloudWatch Model Context Protocol (MCP) Server とは？ Model Context Protocol (MCP) は、開発者ツールが AI モデルとどのように通信するかを革新するオープンソース標準です。コード、ファイル、プロジェクトに関する構造化されたコンテキストを提供することで、MCP は AI アシスタントが正確に調整された提案を提供できるようにします。このプロトコルには、CloudWatch MCP サーバーのような実用的な実装が含まれており、CloudWatch メトリクスとログを開発環境に直接統合します。この統合により、開発者は統合開発環境 (IDE) を離れることなくアプリケーションのトラブルシューティングと監視を行うことができ、運用ワークフローが効率化されます。 AWS Labs CloudWatch MCP Server は、AI トラブルシューティングエージェントと運用データの間のギャップを埋めます。この統合により、AI を活用した根本原因分析と推奨事項が可能になります。カスタム API 統合を必要とせずに CloudWatch テレメトリを使用します。 このサーバーは、運用ニーズに対応する4つの専門ツールを備えています： アラームベースのトラブルシューティング ：アクティブなアラームを特定し、履歴パターンを分析して、コンテキストに応じた修復推奨事項とともに根本原因を判断 ログアナライザー ：指定された時間枠内で CloudWatch ログ グループの異常とエラーパターンを調査 メトリクス定義アナライザー ：計算方法や推奨される統計を含むメトリクスの説明を提供 アラーム推奨事項 ：適切なしきい値と評価期間を持つ最適なアラーム構成を提案 CloudWatch MCP Server のツールとは？ ユーザーが Q CLI で自然言語を使用してプロンプトを入力すると、CloudWatch MCP サーバーツールが呼び出され、AWS サービスと対話して作業を実行します。このブログでは、SAP ユースケースで呼び出されるこれらのツールと AWS サービスを強調します。クライアントから ‘q’ と入力して Q を起動し、 /tools と /mcp を使用して、環境で利用可能なツールのリストと読み込まれた MCP サーバーを表示できます。 図3. クライアントセッションに読み込まれた CLI サーバーツール 図4. クライアントセッションに読み込まれた CloudWatch MCP サーバー このソリューションは Well-Architected Framework for SAP Lensとどのように整合していますか？ 効率化された SAP 運用： Q CLI は、SAP ワークロードをサポートする AWS 運用にエンジニアが自然言語を使用できるようにすることで、SAP 運用手順を変革します。これは、 SAP Lens が強調する、ミッションクリティカルなビジネスシステムの管理における自動化と手動作業の削減と整合しています。SAP インフラストラクチャの CLI コマンドは、シンプルな会話リクエストを通じて生成できます。 加速された SAP トラブルシューティング： この組み合わせにより、SAP コンポーネントのコンテキストに応じた監視データと AI 支援分析を提供することで、SAP インシデントの平均解決時間が短縮され、運用に影響を与えるビジネスクリティカルな障害からの迅速な復旧をサポートします。 統合された SAP オブザーバビリティ： SAP 固有のメトリクス、ログ、アラームをクライアント環境に直接統合することで、コンテキストの切り替えを排除し、複雑な SAP ランドスケープ全体でのエンドツーエンドの監視をサポートします。この統合により、チームはワークフローの中断なしに SAP システムの動作を観察できます。 SAP 変更影響分析： SAP テクノロジースタック全体の運用メトリクスに関する即座のフィードバックを提供することで、チームが変更が SAP システムの安定性にどのように影響するかを理解するのに役立ちます。 SAP レジリエンス検証： このツールは、分散 SAP ランドスケープ全体での SAP 回復メカニズムと障害分離境界の監視、およびビジネスクリティカルなプロセスとトランザクションの信頼性のテストを簡素化します。 SAP アーキテクチャインサイト： Q CLI は、CloudWatch データに基づいて AWS サービスと SAP アプリケーション間の関係を説明でき、チームが SAP アーキテクチャの信頼性に関する洞察を得るのに役立ちます。 SAP ナレッジの民主化： 組織が「コードを使用して SAP を運用する」のに役立ちます。Q CLI のコマンドラインを説明する能力により、チームは適切な情報を持って SAP ランドスケープを効果的に運用し、データ駆動型の意思決定を行うことができます。 前提条件 AWS Launch Wizard for SAP を使用して HA を備えた SAP S/4 HANA システムをデプロイ Amazon CloudWatch Application Insights for SAP に従って SAP フルスタックオブザーバビリティを有効化 Installing Amazon Q for command line の手順に従って Amazon Q CLI をインストール AWS Labs CloudWatch MCP repository の手順に従って PC に CloudWatch MCP Server を構成 configuration settings for the AWS CLI の手順に従って PC に AWS CLI を構成 このソリューションへのアクセスは AWS Identity and Access Management (IAM) で保護されています。また、 Q CLI のセキュリティに関する考慮事項とベストプラクティス 、および Systems Manager のセキュリティベストプラクティス も考慮してください。SAP Basis および AWS インフラストラクチャエンジニアには、最小権限アクセスモデルに従ってください。 ユースケース 1: SAP のヘルスレポートを作成 このユースケースでは、SAP HANA データベースと ABAP SAP Central Services (SAP ASCS) クラスターのヘルスレポートを生成します。Q CLI は、Amazon EC2 インスタンスを検出してヘルスレポートを作成するためのコンテキストに応じたコマンドラインを作成します。このシナリオでは、Q CLI は SAP Central Services のステータスをチェックし、完全なヘルスレポートを作成するために複数のコマンドを実行します： SAP クラスターのヘルスステータスを生成するプロンプト クラスターの一部である aws ec2 describe-instances を実行 ssm コマンド crm_mon を実行してクラスターノードのステータスを確認 ssm コマンドを実行して pacemaker.log を確認 ssm コマンドを実行して corosync.log を確認 ssm コマンドを実行して corosync.log を確認 重要な注意事項： 以下のプロンプトと応答は短縮されています。完全なプロンプトと Q CLI からの応答を確認するには、この ユースケース 1 – SAP のヘルスレポートを作成 をダウンロードしてください。 プロンプト: SAP HANA データベース、データベースクラスタ、および HSR のヘルスレポートを生成します。 > generate a health report for SAP Hana database, database cluster and HSR > # SAP HANA Health Report ## Executive Summary Based on the analysis of CloudWatch logs for the SAP HANA system in the SAPDemo environment, the overall health status is GOOD. The SAP HANA database, cluster infrastructure, and HANA System Replication (HSR) are all functioning properly after recovering from replication issues that occurred on July 11-12, 2025. …… ## Conclusion The SAP HANA database, cluster infrastructure, and HSR are currently healthy and functioning as expected. The system has demonstrated resilience by recovering from previous replication issues. Regular monitoring and proactive maintenance are recommended to maintain system stability and performance. プロンプト: SAP アプリケーション SAPDemo の SAP ASCS ERS クラスタノードの現在のステータスは何ですか。 > what is the current status of SAP ASCS ERS cluster nodes for sap application SAPDemo. > I'll check the current status of the SAP ASCS and ERS cluster nodes for the SAPDemo SAP application. 🛠 Using tool: execute_bash (trusted) ⋮ ● I will run the following shell command: aws ec2 describe-instances --filters "Name=tag:Name,Values=*SAP-FIS-CS*" --query "Reservations[*].Instances[*].[InstanceId,Tags[?Key=='Name'].Value|[0],State.Name,InstanceType,PrivateIpAddress]" --output table ⋮ ↳ Purpose: Checking EC2 instances that are part of the SAP *SAPDemocluster ------------------------------------------------------------------------------------------- | DescribeInstances | +----------------------+-------------------------+----------+-------------+---------------+ | i-064751ba1b4c8340f | SAP-FIS-CS-sapclnode2 | running | c5a.xlarge | 10.0.155.180 | | i-0e08f883d5c3b3747 | SAP-FIS-CS-sapclnode1 | running | c5a.xlarge | 10.0.134.80 | +----------------------+-------------------------+----------+-------------+---------------+ ⋮ ● Completed in 1.737s …… ## Conclusion The SAP ASCS/ERS cluster for the *SAPDemo application is functioning properly with the expected resource distribution: • ASCS (Central Services) is active on sapclnode2 • ERS (Enqueue Replication Server) is active on sapclnode1 • Both nodes are online and healthy • The cluster has quorum and is properly configured for high availability This is the expected configuration for an SAP high-availability setup, where ASCS and ERS run on separate nodes to ensure enqueue replication functionality in case of a node failure. The cluster is operating normally and no immediate action is required. 複雑な運用の場合、Q CLI は複数ステップの手順をガイドし、MCP はシステム状態に関するリアルタイムのフィードバックを提供します。 ユースケース 2: SAP 運用を簡素化 次のユースケースは、SAP アプリケーションサーバーのメンテナンスです。Q CLI は、日常的なメンテナンスタスクのランブックを生成することで、日々の SAP 管理を効率化します。SAP BASIS 管理者は、Q CLI を使用して管理タスクを管理しながら、メンテナンスウィンドウ中に CloudWatch MCP サーバーを通じてシステムステータスをリアルタイムで監視できます。このシナリオでは、Q CLI は次のようにタスクリストを作成しました： App Server のステータスを確認するプロンプト aws ec2 describe-instances を実行して SAP アプリケーションサーバーを確認 ssm コマンド ps を実行して SAP ディスパッチャーとダイアログプロセスを確認 ssm コマンド sapcontrol を実行してシステムステータスを取得 SAP アプリケーションサーバーが停止していることを要約 SAP アプリケーションサーバーを起動するプロンプトの後 ssm コマンド sapcontrol を実行して SAP アプリケーションサーバーを起動 ssm コマンド sapcontrol を実行してプロセスのステータスを確認 ssm コマンド ps を実行して SAP ダイアログプロセスを確認 ssm コマンド sapcontrol を実行してシステムステータスを取得 SAP アプリケーションサーバーが起動したことを要約 重要な注意事項： 以下のプロンプトと応答は短縮されています。完全なプロンプトと Q CLI からの応答を確認するには、この ユースケース 2 – SAP 運用を簡素化 をダウンロードしてください。 プロンプト: アプリケーションサーバー sapbaseaas1 の SAP のステータスを取得します。サーバーを起動せず、SAP プロセスの現在のステータスのみを報告してください。 > get status of sap in application server sapbaseaas1. Do not start the server, Only report on current status of SAP process. > I'll check the current status of SAP processes on the application server sapbaseaas1 without starting the server. 🛠 Using tool: execute_bash (trusted) ⋮ ● I will run the following shell command: aws ec2 describe-instances --filters "Name=tag:Name,Values=*sapbaseaas1*" --query "Reservations[*].Instances[*].[InstanceId,Tags[?Key=='Name'].Value|[0],State.Name,PrivateIpAddress]" --output table ⋮ ↳ Purpose: Finding the instance ID for sapbaseaas1 .. > Now I'll check the current status of the SAP processes on the running sapbaseaas1 server: …….. ## Conclusion The SAP application server sapbaseaas1 is currently stopped. While the EC2 instance itself is running and the SAP support processes are active, the actual SAP application instance (dialog instance) is not running. No work processes are active, and the instance is showing as GRAY in the system status. The instance would need to be started to become operational and process SAP transactions. 次のシナリオでは、SAP BASIS 管理者は CLI から Amazon Q に SAP アプリケーションサーバー、関連する SAP サービスを起動し、SAP アプリケーションのステータスを報告するよう依頼します。Q CLI の execute_bash ツールは、リクエストを満たすために 8 つの SSM コマンドを実行します。 プロンプト: SAP アプリケーションサーバー sapbaseaas1 で SAP を起動します。 > start SAP on the SAP application server sapbaseaas1 > I'll start the SAP application on the sapbaseaas1 server. 🛠 Using tool: execute_bash (trusted) ⋮ ● I will run the following shell command: aws ssm send-command --instance-ids i-0539ecbaf407c4886 --document-name "AWS-RunShellScript" --parameters 'commands=["sudo su - ecdadm -c \"sapcontrol -nr 00 -function Start\""]' --output json ⋮ ↳ Purpose: Starting SAP instance on sapbaseaas1 .. > Now let's check if the SAP instance has started successfully: …….. ## Conclusion The SAP application server sapbaseaas1 is now fully operational. All required processes are running, and the instance is properly integrated with the SAP system. The instance is ready to handle user workloads and process SAP transactions. まとめ CloudWatch MCP Server は、クライアント環境で SAP ランドスケープ全体にわたる統一された可視性を提供します。SAP アプリケーションログ、SAP HANA メトリクス、AWS EC2 パフォーマンスデータを統合します。システムは SAP コンポーネント全体でメトリクスを自動的に相関させます。Q CLI は、この豊富なデータセットとの自然言語インタラクションを可能にすることでこれを補完し、チームがシステムログを簡単に生成し、SAP システム運用を簡素化できるようにします。これは、SAP システムランドスケープの実行と保守の生産性を向上させるために、AWS Well-Architected Framework とよく整合しています。 次のブログ では、CloudWatch MCP Server と Q CLI を活用してメンテナンスイベントを計画し、SAP の根本原因分析を加速する方法、およびソリューションのコスト考慮事項について詳しく説明します。 次のステップとして、このソリューションを試してみてください。このソリューションにより、少なくとも 6 倍の生産性を達成できます。 Amazon CloudWatch 、 AWS Model Context Protocol Servers 、 Amazon Q for command line に関する今後のイノベーションにご期待ください。 SAP on AWS ディスカッションに参加 お客様のアカウントチームと AWS サポートチャネルに加えて、最近 re:Post – AWS コミュニティのための再構想された Q&A エクスペリエンスを開始しました。AWS for SAP ソリューションアーキテクチャチームは、お客様とパートナーを支援するために回答できるディスカッションや質問について、AWS for SAP トピックを定期的に監視しています。サポート関連でない質問がある場合は、re:Post でのディスカッションに参加し、コミュニティナレッジベースに追加することを検討してください。 謝辞 次のチームメンバーの貢献に感謝します：Sreenath Middhi、および Adam Hill。 タグ #saponaws , AWS Systems Manager , CloudWatch , SAP 本ブログは Amazon Q Developer CLI による機械翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

はじめに SAPシステムの適切な負荷テストを実施することは、ピーク使用時にシステムがビジネスのパフォーマンスと信頼性の期待に応えられることを保証する主要な要因です。負荷テストが必要となる典型的なシナリオには、新しい会社/国の展開、ECCからS/4HANAへのソフトウェアリリースアップグレード、アプリケーションパッチ（例：サポートパッケージ）、S/4HANA変革プロジェクト、またはSAP RISEへの移行があります。このような大規模な変更後の安定した運用を確保するため、潜在的なパフォーマンス関連の問題を回避するために、本番カットオーバー前に負荷テストを実行することが推奨されます。このブログでは、オンプレミスまたはRISEにデプロイされたSAP ERPシステムに異なるタイプの負荷を注入するために、AWS上で負荷テストプラットフォームを実装し使用する方法を学びます。 SAP負荷テストとは？ SAPにおける負荷テストは、重負荷条件下でのシステムの動作を測定するために、システムに様々なタイプの負荷を体系的に注入することです。このプロセスは、複数の同時ユーザーがシステムに同時にアクセスし、様々なSAPトランザクションを実行し、大量のデータを処理し、ビジネスクリティカルなプロセスをテストしながら、適切なパフォーマンス評価のためにレスポンス時間とリソース使用率を測定することをシミュレートします。 負荷テストの重要性 SAP負荷テストの重要性は、いくつかの重要な理由から過小評価することはできません。ビジネス継続性の観点から、ピークビジネス時間中のシステムクラッシュを防ぎ、月末締めプロセスなどの重要なビジネスがスムーズに実行されることを保証し、ユーザーの生産性と満足度を維持します。 リスク軽減の観点では、負荷テストは運用に影響を与える前にパフォーマンスのボトルネックを特定し、コストのかかるシステムダウンタイムを防ぎ、データ処理エラーのリスクを軽減します。リソース最適化については、最適なハードウェア要件を決定し、容量計画を支援し、パフォーマンスチューニングの領域を特定します。コスト削減に関しては、適切な負荷テストはリソースのオーバープロビジョニングを防ぎ、予期しないメンテナンスコストを削減し、ビジネスの中断を最小限に抑えます。適切な負荷テストなしでは、組織は重要なビジネス期間中のシステム障害、システムダウンタイムによる収益損失、ユーザー生産性の低下、ビジネス評判の損傷、メンテナンスコストの増加のリスクを負います。 従来の負荷テストの課題 負荷テストの状況は近年大きな変革を遂げています。確立されたツール（例：Tricentisが提供するLoadRunnerを含むテスト自動化スイート）は長い間SAPエコシステムの定番ソリューションでしたが、その従来のアプローチには、多くの組織が正当化することがますます困難になっている相当な要因が伴います。従来の負荷テストツールは、ライセンス、インフラストラクチャ、専門スキルの観点から調達と運用が高価であることが多いです。 AWSによるサーバーレス負荷テスト 現代の負荷テストアプローチは、特にAWSネイティブサービスを使用して、サーバーレスアーキテクチャを採用するように進化しています。 AWS Lambda 、 Amazon EventBridge 、 AWS Batch 、 AWS Fargate 、 AWS Step Functions 、 AWS Systems Manager 、 Amazon CloudWatch などのサービスを活用することで、組織はSAPシステム向けのスケーラブルでコスト効率的な負荷テストソリューションを作成できます。このサーバーレスアプローチにより、専用のテストインフラストラクチャを維持する必要がなくなり、オンデマンドでのテスト実行が可能になります。AWS Step Functionsによるテストシナリオのオーケストレーションと、テスト結果を保存する Amazon S3 または Amazon DynamoDB の組み合わせにより、詳細なパフォーマンスメトリクスと洞察を提供しながら数千の同時ユーザーをシミュレートできる堅牢で自動化されたテストフレームワークが作成されます。 サーバーレス負荷テストの利点は大きく、従量課金制の価格モデル（以下で詳述するように、多くのサービスがAWS無料利用枠に含まれます）、インフラストラクチャメンテナンスゼロ、 自動スケーリング機能 、テストのセットアップと実行の複雑さの大幅な軽減があります。 負荷テストを実行するタイミング SAP負荷テストは、SAPのお客様が考慮すべき全体的な非機能テストの重要な部分です。負荷テストは、新しいSAP実装の本稼働前、主要なシステムアップグレードやパッチ適用後、新しいビジネスプロセスの追加時、年末締めなどのピークビジネス期間前、ビジネス成長の計画時に実行すべきです。 月末や年末の財務締めなど、例外的なシステム負荷を生成する計画されたビジネスイベントは、スムーズな運用を確保するために事前のパフォーマンス評価が必要です。さらに、組織が新しいビジネスエンティティを統合したり、新しい複雑なプロセスを実装したりする計画がある場合、負荷テストは増加した複雑さと量を処理するシステムの能力を検証するために不可欠になります。 一貫したシステムパフォーマンスを維持するために、組織は変更管理戦略内に負荷テストを組み込むべきです。この体系的なアプローチは、アプリケーションの変更が本番環境に影響を与える前に、潜在的なパフォーマンスへの影響を特定するのに役立ちます。自動化されたテスト機能を統合することで、組織は将来のアップグレードと統合を通じて品質を維持するための基盤を確立しながら、システムパフォーマンスをより効率的に検証できます。パフォーマンステストに対するこの積極的な姿勢は、最終的にシステムの信頼性とSAPランドスケープ全体での最適なユーザーエクスペリエンスを確保するのに役立ちます。 ソリューションアーキテクチャ SAP on AWS Native 図1：SAP on AWS Nativeアーキテクチャ RISE with SAP 図2：RISEアーキテクチャ 注：RISE内で実行されているSAPシステムからOSメトリクスを抽出するために、いくつかのコード調整が必要な場合があります テストシナリオ RISE環境 アプリケーションテスト 図3：RISE負荷テストタイプ HANAデータベース負荷テスト この オープンソースソリューション は、SAP HANAシステム向けの現実的なデータベースワークロードを生成し、k6-sqlモジュールとk6スクリプト機能を使用して大規模なデータベース挿入/更新/削除SQL操作を注入します。以下は例です： import sql from "k6/x/sql"; import driver from "k6/x/sql/driver/hdb"; import secrets from 'k6/secrets'; const db = sql.open(driver, `hdb://${username}:${password}@${hanaHost}:${hanaPort}`); export function setup() { db.exec(` CREATE COLUMN TABLE test_table ( A INT GENERATED BY DEFAULT AS IDENTITY, B TEXT, C TEXT, D TEXT ); `); } export default function () { // first insert let insert_result = db.exec(` INSERT INTO test_table (B, C, D) VALUES ('test', 'test', 'test'); `); console.log("Row inserted"); // then select let selectResult = db.query(` SELECT * FROM test_table LIMIT 10; `); console.log(`Read ${selectResult.length} rows`); } export function teardown() { db.exec(`DROP TABLE test_table;`); db.close(); } HANAネイティブとAmazon CloudWatchに基づく監視コンポーネントは、トランザクションスループットとレスポンス時間に焦点を当て、システム全体の詳細なリソース使用パターンを取得します。エラー率とパフォーマンスボトルネックを分析しながら、メモリとCPUへの影響に関する洞察を提供します。 SAP FioriとIDoc負荷テスト 高ボリュームのIDoc処理をテストするために設計された k6ベース のフレームワークで、堅牢なビジネス文書交換機能を確保します。システムは、販売注文などの様々な文書タイプ（idocの例については コードリポジトリ を参照）の動的IDocペイロード生成をサポートし、ランプアップ、持続、ピークテストフェーズを含む設定可能な負荷パターンを提供します。AWS CloudWatchとの深い統合により、メトリクス収集と閾値ベースのパフォーマンス検証が可能になります。 同様に、SAP Fioriフロントエンド経由の複数の並列エンドユーザーインタラクションを同じアプローチを使用してシミュレートし、システムが重負荷状態に入ったときのエンドユーザーエクスペリエンスをテストできます。 パフォーマンス監視は2つの主要な領域に焦点を当てています。第一に、FioriアクセスまたはIDoc処理パフォーマンスは、スループット率、処理時間、負荷下でのキューの動作、エラーパターンを追跡しながら、エンドツーエンドの処理を検証します。第二に、システム影響分析は、SAPレスポンス時間、データベースパフォーマンス、ネットワーク使用率、全体的なリソース消費パターンを調査します。k6データベースシナリオと同様に、JavaScriptスクリプトを使用してSAPシステムに販売注文idocを注入したり、SAP Fioriユーザーインタラクションをシミュレートしたりできます： import http from 'k6/http'; import { check, sleep } from 'k6'; import { Rate } from 'k6/metrics'; import encoding from 'k6/encoding'; import secrets from 'k6/secrets'; //get information from secret const username = await secrets.get('username'); const password = await secrets.get('password'); const sapClient = await secrets.get('sapClient'); //get baseUrl from environment variable const sapBaseUrl = __ENV.SAP_BASE_URL //set the sap client in url parameter let sapClientStringParameter="" if (sapClient.match(/^[0-9]{3}$/)) { sapClientStringParameter=`?sap-client=${sapClient}` } // define your url path const urlPath="/sap/bc/idoc_xml" //build the final url const url = `${sapBaseUrl}${urlPath}${sapClientStringParameter}`; //start your load test logic const xmlfile = open('./sample_idoc_ID1.xml'); const todayDate = new Date().toISOString().slice(0, 10); const newDate = todayDate.replace("-","") export const successRate = new Rate('success'); export const options = { vus: 5, duration: '60s', insecureSkipTLSVerify: true, }; export default function () { const data = getAndConvertIdocXml(); const credentials = `${username}:${password}`; const encodedCredentials = encoding.b64encode(credentials); const httpOptions = { headers: { Authorization: `Basic ${encodedCredentials}`, "Content-Type": 'text/xml' }, }; check(http.post(url, data, httpOptions), { 'status is 200': (r) => r.status == 200, }) || successRate.add(1); sleep(5); } function getAndConvertIdocXml() { let result = xmlfile.replace("{{GENERATED_IDOC_NUMBER}}", Math.floor(Math.random() * 100000000000000)) result = result.replace("{{GENERATED_MESSAGE_ID}}", Math.floor(Math.random() * 100000000000000)) return result } サンプルxml idoc構造は、トランザクションWE19（idocテストツール）を介して生成できます。idocが生成されたら、xmlは負荷テストスクリプトの実行時にランタイムで埋められる文字列プレースホルダーGENERATED_IDOC_NUMBER、GENERATED_MESSAGE_IDを持つテンプレートに変換する必要があります。 注： ステータス53 （アプリケーション文書が投稿済み）でのインバウンドIDoc処理を成功させるために、SAPシステムに応じて送信者/受信者とパートナー番号/ポートが正しい値で設定されるなど、適切な ALE設定 を実行することを確認してください。 両方のテストアプローチは、現実的なビジネスプロセスシミュレーションとスケーラブルなテストシナリオを通じて大きな利点を提供します。包括的な監視フレームワークは、コスト効率的なオープンソースツールと組み合わされ、可視性と制御の向上のためのAWSサービスとの深い統合を提供します。 SAP on AWS Native環境 RISE環境オプションに加えて、SAPをAWS上でネイティブに実行する場合、以下のテストを実行できます。 インフラストラクチャテスト 図4：インフラストラクチャ負荷テストタイプ この図は、異なるインフラストラクチャ側面に焦点を当てた、AWS上のSAPシステムの3つの主要なテストシナリオを示しています： コンピュートテストシナリオ： このシナリオは、オペレーティングシステムツールを使用した体系的なストレステストを通じて、SAPシステムのコンピューティング能力を評価します。CPU負荷シミュレーションでは、 AWS Fault Injection Simulator （FIS）と同様に、’ stress-ng ‘などのツールを使用して正確なCPU使用率パターンを生成します。例えば、stress-ngを使用してすべてのコアで75%のCPU負荷を維持したり、利用可能なRAMの80%を消費するメモリストレステストを行います。チュートリアルは こちら で見つけることができます。これらのツールは、SAP固有のパフォーマンスメトリクス（例：sapsocol / Workload Monitorによって収集される）と組み合わされ、IntelとAMDプロセッサ間のインスタンスタイプ比較に関する包括的な洞察を提供し、特定のSAPワークロードに最適なコンピュート設定の決定を支援します。テスト方法論には、段階的な負荷増加、持続的な高使用率期間、様々な計算ストレス条件下でのシステム動作の監視が含まれます。 ストレージテストシナリオ： このシナリオは、 Flexible I/O （FIO）テスターを使用した包括的なテストを通じて、ストレージパフォーマンスの最適化に焦点を当てています。FIOは、ランダム読み取り/書き込みテスト、シーケンシャル読み取りパフォーマンス、EBSボリュームのIOPSテストなど、様々なテストパターンを通じてストレージパフォーマンス特性の正確な測定を可能にします。AWS上でのFIOベンチマークの詳細については、この リンク を参照してください。FIOテストは、異なるEBSボリュームタイプ（例：gp3 vs io2）で実行され、以下を分析します： 最大スループット能力 様々なワークロード下でのIOPSパフォーマンス 異なるキュー深度でのレイテンシパターン 持続的負荷下でのストレージシステムの動作 ネットワークテストシナリオ： このシナリオは、SAPシステムのパフォーマンスに影響を与える重要なネットワークパラメータを測定することで、ネットワークパフォーマンスと接続性を調査します。主要な機能は、Linuxの’ tc ‘（トラフィック制御）などのオペレーティングシステムコマンドを使用したネットワーク遅延シミュレーションです。これにより、人工的なレイテンシ、パケット損失、帯域幅制限を導入することで、ネットワーク条件を正確に制御できます。例えば、’tc qdisc’などのコマンドを使用することで、以下を含む実世界のネットワーク条件のシミュレーションが可能になります： 特定のレイテンシ値の導入（例：300ms遅延） パケット損失シナリオのシミュレーション（例：5%パケット損失） 帯域幅スロットリング条件の作成 ネットワーク通信でのジッターの実装 これらのネットワーク障害シミュレーションは、様々なネットワーク条件下でのSAPシステムの動作に関する貴重な洞察を提供します。このアプローチは、組織がSAPシステムのネットワーク問題に対する回復力を理解し、それに応じてネットワーク設定を最適化するのに役立ちます。このシナリオは、SAP相互接続システム（例：ERP BW）間で追加のレイテンシを導入し、ERPがオンプレミスで実行され、BWがAWSに移行される移行プロジェクトをシミュレートすることで、データ抽出プロセスを測定するために使用できます。 負荷テスト監視 リアルタイム監視オプション CloudWatchダッシュボード カスタムAmazon CloudWatchダッシュボードは、インフラストラクチャメトリクス、アプリケーションパフォーマンスデータ、カスタムテストメトリクスを包括的な視覚化に組み合わせて、統一されたビューで重要なパフォーマンスメトリクスを表示します。主要パフォーマンス指標は論理グループに整理されています：SAP運用チーム向けのダイアログとデータベースレスポンス時間、システムダンプ数、アクティブユーザーなどのSAP技術メトリクス、およびインフラストラクチャ運用チーム向けのCPU、メモリ使用率、ストレージIOPSとスループットなどのOSメトリクス。ダッシュボードは、事前定義された閾値に基づく自動アラート機能を備えており、テスト実行中のパフォーマンス問題に対する積極的な対応を可能にします。履歴データ保持により、トレンド分析と異なるテスト実行間のパフォーマンス比較が可能になり、容量計画とシステム最適化のための貴重な洞察を提供します。 図5：負荷テスト中のCloudwatchダッシュボードメトリクス Amazon Managed Grafana（オプション） CloudWatchダッシュボードの代替または補完として、Amazon Managed Grafanaは強化された視覚化機能とより深い分析機能を提供します。このサービスは、高度なデータ相関とカスタムメトリクスを通じて監視エクスペリエンスを向上させ、事前構築されたパネルとカスタムパネルの両方で豊富な視覚化オプションを提供します。クロスアカウントとクロスリージョンのメトリクス集約をサポートし、複雑なSAPランドスケープの包括的な監視を可能にします。チームベースのアクセス制御とダッシュボード共有により、異なるステークホルダーグループ間でのコラボレーションが促進され、AWSサービス（このシナリオではAmazon CloudWatch）と外部データソースとのネイティブ統合により監視機能が拡張されます。リアルタイムメトリクス探索とアドホック分析機能は、パフォーマンス問題の即座の調査をサポートし、Infrastructure as Codeによる自動化されたダッシュボードプロビジョニングによって補完されます。組み込みのアラートと通知チャネルにより、パフォーマンス異常への適時な対応が保証されます。CloudWatchメトリクスとGrafana視覚化の組み合わせにより、リアルタイム運用監視と長期パフォーマンス分析の両方をサポートする強力な監視エコシステムが作成され、SAPシステム最適化のためのデータ駆動型意思決定が可能になります。 図6：負荷テスト中のGrafanaダッシュボードメトリクス どちらの場合も、SAP Netweaver固有のメトリクスは、このオープンソースソリューションを使用してCloudwatchで収集できます。 負荷テストワークフロー オーケストレーションと実行フロー ワークフローは、SAPシステム負荷テストを実行し監視するために、AWSサービス全体で構造化されたイベントシーケンスに従います： テスト開始： Step Functionが専用のWebアプリケーションUIでのエンドユーザー入力に基づいてテストワークフローを開始し、テスト実行と監視を制御するステートマシンを通じて全体のプロセスをオーケストレートします。入力ペイロードは、どのシナリオが実行されるか（SAP、HANA、またはインフラストラクチャ）を決定します。 テスト実行： AWS Secrets Managerを介して認証する特定のLambda関数が負荷テストシナリオを実行します。関数には特定のテストシナリオのロジックとパラメータが含まれています。 システムアクセス： AWS Systems ManagerとFargateがVPC内のSAPランドスケープへの安全なアクセスを提供し、以下でのテスト実行を可能にします： アプリケーションレベルテスト用のSAPアプリケーションサーバー データベースレベルテスト用のSAP HANAデータベース CPU、メモリ、ストレージ、ネットワークテスト用のオペレーティングシステムレベル 監視とデータ収集： Amazon CloudWatchがテスト実行からパフォーマンスメトリクスを収集・処理し、すべてのSAPコンポーネントとインフラストラクチャ要素からデータを収集します。 リアルタイム視覚化オプション： リアルタイム監視用の直接CloudWatchダッシュボード 高度な視覚化と分析用のAmazon Managed Grafana（オプション）、認証用のAWS IAM Identity Center（AWS Single Sign-Onの後継）とのオプション統合 長期データ処理と分析： パフォーマンスメトリクスはAmazon S3に保存されます AWS Glueがデータを処理・変換します Amazon AthenaがSQLベースの結果分析を可能にします Amazon QuickSight（オプション）がパフォーマンス洞察と視覚化を生成します エンドユーザーエクスペリエンスをさらに改善し合理化するために、 Amazon Cognito を介して安全に認証されたユーザーが負荷テストを直接開始し、ステータスを監視できるReactアプリケーションが開発されました。これは Amazon CloudFront でホストされ、 Amazon API Gateway を通じてStep Functionワークフローと相互作用します。 このワークフローは、VPC分離と適切なアクセス制御を通じてセキュリティを維持しながら、包括的なテスト実行、監視、分析を保証します。 実装 今日から始めましょう： GitHub リポジトリ をクローンする ステップバイステップのデプロイメントガイドに従う SAPシステムで最初の負荷テストを実行する – セットアップから結果まで – 60分以内に！ コスト サービス コスト 説明 Step Functions 無料利用枠 月間4,000回の無料ステート遷移を含む Lambda 無料利用枠 月間100万回の無料リクエストと400,000 GB秒のコンピュート時間 Secrets Manager 月額$0.40 ユーザー認証情報とその他のパラメータを保存するために1つのシークレットが必要 Systems Manager 無料 実行コマンドに追加料金なし CloudWatch $3.00 基本監視メトリクス + 10カスタムメトリクス CloudFront 月額$0.12 Cognito 月額$6.22 5ユーザー、月間100トークンリクエスト、1アプリクライアント ECR 月額$0.07 2イメージ、月間合計750 MB Fargate 月額$6.32 16 vCPU 16 GBメモリ、月間ポッドあたり10タスク、60分間の実行時間 API Gateway 月額$0.35 月間10,000 REST APIリクエスト S3 無料利用枠 S3 Standardで5GBストレージ、20,000 GETリクエスト、2,000 PUT/COPY/POST/LISTリクエスト、月間100 GBデータ転送アウト Glue 無料利用枠 保存される最初の100万オブジェクトは無料 Athena 月額$0.29 1日20クエリ、クエリあたり100 MBスキャンデータ Managed Grafana 月額$9.00（オプション） 1エディター、5ユーザー QuickSight 月額$33（オプション） 5ユーザー 合計 Grafana / QuickSightなしで月額$16.77 QuickSightありで月額$25.77 GrafanaとQuickSightありで月額$58.77 レポートのみが必要な場合は、QuickSightを使用できます。Grafanaの代替として、CloudWatchダッシュボードも使用できます（いくつかの制限があります） コストの詳細については、 このリンク でご確認ください。 結論 この包括的なブログ投稿では、AWSサーバーレスサービスを活用してSAP負荷およびパフォーマンステストを実行する方法を探求しました。クラウドネイティブサービスを採用することで、深い実用的なメトリクスを収集しながらSAP環境の広範囲な負荷テストを実施する効率的でコスト効率的なアプローチを実証しました。私たちのアプローチは、現代のクラウド機能が従来のパフォーマンステストを、SAPデプロイメントのためのよりスケーラブルで、コスト効率的で、データ駆動型のプロセスに変革する方法を示しています。 AWS for SAPブログ を読んで、SAP投資からより多くを得る方法についてのインスピレーションを得てください。今日からAWS上でSAPを始めて、SAPランドスケープで負荷テスト戦略を開始しましょう！ SAP on AWSディスカッションに参加 お客様のアカウントチームとAWSサポートチャネルに加えて、AWSは re:Postサイト で公開の質問回答フォーラムを提供しています。私たちの AWS for SAP ソリューションアーキテクチャチームは、お客様とパートナーを支援するために回答できるディスカッションと質問について、AWS for SAPトピックを定期的に監視しています。質問がサポート関連でない場合は、re:Postでのディスカッションに参加し、コミュニティナレッジベースに貢献することを検討してください。 本ブログはAmazon Q Developer CLIによる機械翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

フィールドサービス業務のデジタル変革により、資産の生成が指数関数的に増加し、それに伴いストレージ要件も増大しています。 SAP Field Service Management （SAP FSM）を使用する組織は、フィールドサービス技術者が取得するデジタル資産の管理において、ますます大きな課題に直面しています。これらの資産には、機器の写真、フォーム、顧客の署名、その他現場で管理される重要な資産が含まれます。この投稿では、 Amazon Web Services （AWS）を活用して、 SAP Clean Core Extensibility の原則に従いながら、SAP FSM向けのスケーラブルでコスト効率的な添付ファイルストレージソリューションを作成する方法を実証します。 概要 フィールドサービス業務では、日常的な活動を通じて大量の添付ファイルが生成されます。SAP FSMは ネイティブストレージ機能を提供 していますが、組織はしばしばより多くのストレージ容量と、コンプライアンス上の理由でデータ所有権を維持しながら他のビジネスプロセスとの統合を可能にする、より柔軟でコスト効率的なソリューションを必要とします。SAP FSMを組織のAWSインフラストラクチャと統合することで、このソリューションは企業がデータの制御を維持しながら、現場で作成された資産から最大の価値を抽出するための高度な処理と分析を可能にします。 このブログで提案する統合により、組織はSAP FSMで生成された添付ファイルを自社のAWSアカウント内の Amazon Simple Storage Service （S3）バケットに保存し、データ所有権を強化し、SAP FSMでのデータフットプリントを削減できます。さらに、組織は Amazon Textract によるテキスト抽出、 Amazon Rekognition による画像分析、 Amazon Comprehend による自然言語処理などのAWSサービスを活用して、保存された添付ファイルに対する追加のデータ処理と分析を実装できます。これらの資産を完全に制御することは、 Large Language Models （LLM）と Knowledge Base 統合を活用して、他のサービスやフィールドプロセスで価値のある文脈化された洞察を得るための、より複雑なソリューションを強化する出発点でもあります。 仕組み プロセスは現場から始まります。サービス技術者が顧客サイトでの作業を完了します。SAP FSMアプリケーションを搭載したモバイルデバイスを使用して、重要な文書を取得します。修理された機器の写真、顧客フォーム、または詳細なサービスレポートなどです。FSMアプリケーションで「アップロード」をタップすると、文書が組織内で安全にアクセス可能に保存されるよう設計された一連のイベントが開始されます。 （図1：仕組み） 添付ファイルがSAP FSMに到着すると、システムのビジネスルールエンジンが即座にこの新しいコンテンツを検出します。添付ファイル処理用の特定のルールで構成されたエンジンが動作を開始します。 ビジネスルールは添付ファイルに関する重要な情報を抽出します。 これには、一意の識別子、ファイル名、説明、タイムスタンプ、およびサービスコールとの関係が含まれます。その後、ビジネスルールは添付ファイルのメタデータを含むHTTPS要求を、顧客のAWS環境内の専用APIエンドポイントに送信します。このAPIは Amazon API Gateway 上に構築され、SAP FSMテナント用の一意のAPIキーで保護され、SAP FSM環境へのIP許可リストが設定されています。 メタデータを受信すると、APIはそれを Amazon EventBridge （EventBridge）に公開します。このイベントの処理は、 AWS Lambda （Lambda）関数である添付ファイルプロセッサによって非同期的に行われます。この関数は、いくつかの重要なタスクを順次実行します。まず、 AWS Secrets Manager に保存された OAuth2 認証情報を使用してSAP FSMで認証を行います。認証が完了すると、SAP FSMの添付ファイルAPIを使用して実際の添付ファイルコンテンツを取得します。その後、関数はこのコンテンツを処理し、元のメタデータで強化し、すべてを指定されたS3バケットに保存します。適切な暗号化とアクセス制御で構成されたS3バケットは、添付ファイルの安全で長期的な保存場所として機能します。 詳細なアーキテクチャ図は以下の通りです： （図2：リファレンスアーキテクチャ） このソリューションにより、FSMの顧客は添付ファイルのAmazon S3バックアップに関する運用メトリクスを表示でき、 SAP FSM拡張機能 としてインストールできます。 この拡張機能は、Reactで構築されたWebページで、Amazon CloudFrontとAmazon S3でホストされています。SAP FSM管理者は、CloudFrontディストリビューションのURL（各SAP FSMテナントには独自のものがあります）を使用して、SAP FSM拡張機能カタログから直接この拡張機能を簡単にインストールできます。この拡張機能は、S3ストレージメトリクスへのリアルタイムの可視性を提供します。この組み込みの Amazon CloudWatch ダッシュボードにより、管理者はS3バケット内の総オブジェクト数、現在のストレージ使用率、エラー率と失敗した操作、バックアップ完了ステータス、データ転送メトリクスなどの重要なメトリクスを監視できます。 拡張機能はユーザーのブラウザ内で実行されるため、対応するAPIメソッドはAPIキー認証やIP許可リストを使用できません。代わりに、拡張機能はSAP FSMとAWSを統合するために開発した新しい認証パターンを使用します。拡張機能は（すべてのSAP FSM拡張機能と同様に）SAP FSM内で HTML iframe として実行され、 SAP FSM SDK を使用して、拡張機能はユーザー用の 短期間トークン（JWT） を取得できます。このトークンには、ユーザーとテナントコンテキストに関する詳細が含まれ、SAP FSMによって暗号学的に署名されています。その後、トークンは拡張機能からAWS API Gatewayへの要求を承認するために使用されます。この目的のために、ソリューションには別のLambda関数であるカスタム認証機能が含まれています。このLambda関数は、 aws-jwt-verify ライブラリを使用してトークンを検証し、テナントの詳細（アカウントIDと会社ID）と暗号学的署名をチェックします。サンプル実装はすべての有効なトークンを受け入れ、例えばSAP FSMがトークンに設定する`permission_group_id`クレームに基づいて、きめ細かい認証を追加するように簡単に拡張できます。 はじめに このソリューションを開始するには、この GitHubリポジトリ で利用可能な手順を参照してください。実装の高レベルステップには以下が含まれます： 前提条件を確認し、必要なAWSとSAP FSMアクセスがあることを確認する お客様のリージョンで提供されたCloudFormationテンプレートを使用してソリューションをデプロイする SAP FSMでOAuth2認証情報を設定する SAP FSM拡張機能マーケットプレイスで拡張機能をインストールおよび設定する 提供されたCloudWatchダッシュボードを通じて実装を監視する コスト概要 ソリューションのデプロイと使用に関連するコストは、主にFSMで作成される添付ファイルの量に関連しています。テスト目的では、コストは最小限で、月額1ドル未満です。 実際の本番シナリオでは、以下の前提に基づく簡単な計算を示します： 前提 値 詳細 SAP FSMで作成される添付ファイル数（FSMエージェント） 100,000 月あたり 添付ファイルの容量（GB） 100 月あたり 拡張機能UIのHTTPリクエスト数（FSM管理者ユーザー） 10,000 月あたり AWSリージョン eu-central-1 （フランクフルト） 通貨 USD 米ドル （表1：コスト計算の前提） これにより以下の結果となります： 月額総コスト：6.81 USD 年額総コスト：81.72 USD コストの内訳は以下の通りです（完全な計算は こちら ）： 説明 AWSサービス 月額（USD） 年額（USD） ディストリビューション Amazon CloudFront 0.23 2.76 S3バケット（Webアプリ） S3 Standard 0.07 0.84 S3バケット（Webアプリ） データ転送 0 0.00 S3バケット（添付ファイル） S3 Standard 3.04 36.48 S3バケット（添付ファイル） データ転送 0 0.00 JWT認証機能 AWS Lambda 0 0.00 JWT認証機能 AWS Lambda 0 0.00 FSM BR作成機能 AWS Lambda 0 0.00 イベントバス Amazon EventBridge 0.1 1.20 REST API Gateway Amazon API Gateway 0.37 4.44 添付ファイル保存機能 AWS Lambda 0 0.00 メトリクス Amazon CloudWatch 3.0103 36.12 （表2：コスト詳細） 結論 SAP Field Service ManagementとAWSの統合は、組織がクリーンコアアプローチを維持しながら、スケーラブルで安全、かつコスト効率的なソリューションを構築するためにクラウドネイティブサービスを活用する方法を実証しています。このソリューションは、即座のストレージ課題に対処するだけでなく、AWSサービスを通じた高度なデータ処理と分析機能の機会も創出します。 この統合の主な利点には以下が含まれます： SAP FSMでのデータフットプリントの削減 データ主権と制御の強化 S3によるコスト効率的でスケーラブルなストレージ 組み込みの監視と可観測性 高度な分析とAI/ML統合の可能性 フィールド技術者にとってのシームレスなユーザーエクスペリエンス フィールドサービス業務の最適化を目指す組織にとって、この統合はシステムの整合性とスケーラビリティを維持しながら、デジタル変革への戦略的なステップを表しています。ソリューションのサーバーレスアーキテクチャは、将来の機能強化に最大限の柔軟性を提供しながら、運用オーバーヘッドを最小限に抑えることを保証します。 SAP on AWSディスカッションに参加 お客様のアカウントチームとAWSサポートチャネルに加えて、AWSは re:Postサイト で公開の質問回答フォーラムを提供しています。私たちの AWS for SAP ソリューションアーキテクチャチームは、お客様とパートナーを支援するために回答できるディスカッションと質問について、AWS for SAPトピックを定期的に監視しています。質問がサポート関連でない場合は、re:Postでのディスカッションに参加し、コミュニティナレッジベースに貢献することを検討してください。さらに、サーバーレスとイベント駆動アーキテクチャパターンについて詳しく学ぶには、 AWSサーバーレスブログセクション を参照してください。 本ブログはAmazon Q Developer CLIによる機械翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

この記事は Deep Dive: Amazon ECS Managed Instances provisioning and optimization (記事公開日: 2025 年 11 月 4 日) を翻訳したものです。 Amazon Elastic Container Service (Amazon ECS) マネージドインスタンス は、完全マネージドのコンピューティングオプションで、インフラストラクチャ管理のオーバーヘッドを排除しながら、 Amazon Elastic Compute Cloud (Amazon EC2) の幅広い機能にアクセスできます。これには、インスタンスタイプの選択、リザーブドキャパシティへのアクセス、高度なセキュリティと監視設定の活用などの柔軟性が含まれます。ECS マネージドインスタンスは Amazon Web Service (AWS) にオペレーションを委託することでお客様の迅速な開始を支援します。総所有コストを削減し、チームがイノベーションをもたらすアプリケーションの構築に専念できるようします。 この記事では、ECS マネージドインスタンスが EC2 インスタンスを自動的にプロビジョニングして最適化し、ワークロードの高可用性とコスト効率のバランスを取る方法について詳しく説明します。 Amazon ECS マネージドインスタンスキャパシティープロバイダー Amazon ECS の「キャパシティープロバイダー」はワークロードのコンピューティング能力を定義するインターフェースです。ECS クラスターには、サーバーレスコンピューティングでワークロードを起動するための AWS マネージドの FARGATE と FARGATE_SPOT キャパシティプロバイダーが自動的に含まれています。また EC2 インスタンス上でワークロードを実行するための独自の EC2 Auto Scaling グループ (ASG) キャパシティプロバイダーも作成できます。Amazon ECS マネージドインスタンス は、AWS Fargate のフルマネージドの体験と Amazon EC2 の柔軟性を組み合わせた新しいキャパシティプロバイダーで、両者の長所を兼ね備えています。ECS は、ワークロードの要件に応じて、AWS アカウント内でフルマネージドの EC2 インスタンスを迅速にプロビジョニングおよびスケーリングします。ECS マネージドインスタンスキャパシティプロバイダーは、コスト最適化された汎用インスタンスを自動的に選択します。vCPU とメモリの最小/最大、希望のインスタンスタイプ、CPU メーカー、アクセラレータタイプ、その他のインスタンスの仕様を指定することで、インスタンスの要件をカスタマイズできます。インスタンスの選択の詳細については、 ドキュメント を参照してください。 プロビジョニングワークフロー ECS マネージドインスタンスは、ワークロードを継続的に監視し、ワークロードの要件に基づいてタイムリーに新しい EC2 インスタンスを起動します。構成済みのサブネット内の Availability Zone (AZ) 間でタスクを自動的に分散することで、アプリケーションの可用性を高めます。新しいインスタンスを起動する際、ECS は最初に適切な AZ 分散を確保してから、各インスタンス内でタスクをビンパッキングし、コストを最適化します。これにより、高可用性とコスト効率のバランスが実現されます。さらに、複数のタスクを同じインスタンス上に配置することで、ECS マネージドインスタンスはインフラストラクチャコストを最適化するだけでなく、後続のタスクがインスタンスプロビジョニングの待ち時間を回避し、インスタンス上のコンテナイメージキャッシュの恩恵を受けるため、タスクの起動が高速化されます。ここでは、まず、インスタンスプロビジョニングのワークフローを説明し、その後、可用性とインフラストラクチャの最適化の側面について詳しく説明します。 次の図は、インスタンスのプロビジョニングワークフローを示しています。マネージドインスタンスキャパシティプロバイダーを通して 4 つの新しいタスクが起動されると、ECS は既存の管理対象インスタンスを評価して、利用可能な容量を判断します。ECS はタスクサイズと利用可能なインスタンスリソースに基づいて、できるだけ多くのタスクを現在実行中のインスタンスに配置します。この場合、2 つのタスクが他のタスクをホストしている既存の EC2 インスタンスに正常に配置されています。既存のインスタンスで収容できない残り 2 つのタスクについては、ECS が自動的に新しい EC2 インスタンスを起動します。この新しいインスタンスは、残りのタスクに十分な CPU とメモリを確保するためにタスクのリソース要件に基づいてプロビジョニングされ、タスクを AZ 間で均等に配置します。このビンパッキングアプローチは、タスクを効率的に共存させながら可用性を高めるために複数の AZ に分散させることで、リソースの利用を最大化し、インフラストラクチャコストを最小限に抑えます。 図 1: ECS マネージドインスタンスキャパシティプロバイダーにおける新規 ECS タスクの Run Task フロー 既存インスタンスの選択 ECS はインスタンスごとに正確なリソース管理を行い、CPU、メモリ、その他のリソースをリアルタイムに追跡します。インスタンスが ECS に登録されると、利用可能な容量は EC2 インスタンスのリソース合計から ECS エージェントに予約されたメモリを差し引いた値になります。ECS はインスタンスの登録時に、インスタンスタイプごとの実績データに基づいてエージェントが消費するリソース量を推定し、複数の並行タスクに十分なリソースを確保します。タスクの起動と終了に伴い、ECS はインスタンスの利用可能なリソース容量を動的に更新します。新しいタスクの配置では、ECS は既存のインスタンスにリソースが十分にあるかどうかを最初にチェックします。複数の適切なインスタンスが存在する場合、ECS はマネージドインスタンスキャパシティプロバイダーで構成されたサブネットによって AZ 分散を制御しながら、最大の回復力を得るために AZ 間でタスクを分散させることを優先します。既存のインスタンスでは最適な AZ 分散ができなくても、現在の AZ に容量がある場合、ECS は新しいインスタンスをプロビジョニングするのではなく、サービスの目標タスク数に早く到達するために既存の容量を使用することを優先し、可用性を高めます。その後、ECS は継続的な AZ 間での ECS サービスの調整 によってワークロードを調整し、可用性をさらに高めるための最適な AZ 分散を実現します。 新規インスタンスの登録 ECS マネージドインスタンスが新しいタスクを既存のインスタンスに配置できない場合、そのタスクは新しいキャパシティを待つ間 PROVISIONING 状態になります。ECS は個々のインスタンスをプロビジョニングするのではなく、複数のアプリケーションから起動要求されたタスクをインテリジェントにバッチ処理します。これにより、レスポンス性と最適化の機会のバランスを取ることができます。ECS はリソース要件を全体的に分析し、最適なインスタンスタイプを選択しながら、タスクを AZ 間に分散させます。CPU、メモリ、ストレージの要件が異なるタスクを数百種類の利用可能なインスタンスタイプに配置することは、NP 完全な多次元ビンパッキング問題となります。ECS は First Fit Decreasing（FFD）アルゴリズムを採用しており、効率的なリソース使用率を維持しながら、数学的な完全性よりもシステムの応答性を優先し、多項式時間で最適に近い結果を提供ます。 インフラストラクチャの最適化 ECS マネージドインスタンスは、キャパシティプロバイダーの構成とワークロード要件に基づいて適切なサイズの EC2 インスタンスを起動します。時間の経過とともに、トラフィックパターンの変化や動的スケーリングにより、EC2 インスタンスがワークロード要件から外れる可能性があります。ECS マネージドインスタンスは、インフラストラクチャを継続的に最適化し、利用率の低いインスタンスをドレインし、タスクを既存の利用可能なリソースを持つインスタンスか、新たに適切なサイズでプロビジョニングされたインスタンスに再配置します。次の図は、利用率の低いインスタンスの最適化の動作を示しています。2 つのタスクが停止すると、ECS はリソースの非効率性を認識し、利用率の低いインスタンスを DRAINING としてマークします。これにより、インフラストラクチャが 3 つのインスタンスから 2 つに減り、サービスの可用性を維持しながら、不要なコンピュートコストを排除します。 図 2: ECS マネージドインスタンスキャパシティプロバイダーが、リソース活用率を向上させるために、利用率の低いインスタンスをドレインする ECS マネージドインスタンスは、実行中のタスクがないアイドル状態のインスタンスを自動的に削除するため、アクティブなリソースのみの支払いで済みます。次の図は、2 つのタスクがインスタンス上で停止した際の動作を示しています。ECS はアイドル状態のインスタンスを特定し、登録を解除します。これによりインスタンスの終了が開始され、2 つのインスタンスから 1 つのインスタンスにスケールダウンされます。同じメカニズムにより、以前ドレイン (タスクの移行) されたインスタンスも、空になった時点で自動的に登録解除と終了が行われます。 図 3: ECS マネージドインスタンスキャパシティプロバイダーが、リソース活用率を向上させるためにアイドル状態のインスタンスをドレインする 可用性 ECS マネージドインスタンスは、事前に設定されたサブネットに対して ECS サービスのタスクを AZ 間で自動的に分散させることで、アプリケーションの可用性を向上させます。ECS は新しいインスタンスを起動する際、まずインスタンスを事前に設定された全ての AZ に分散させ、その後それらのインスタンス上にタスクを配置して可用性を最大化します。複数のスケーリング操作を経て、ECS サービスがタスクが完全に AZ 間でバランスされていない状態に達した場合、 AZ 間での ECS サービスの調整 機能がインスタンス間でタスクを再分散するのに役立ちます。これには、インスタンスのスケールイン・アウトが必要になる場合があります。最終的な利点は、ECS がサービスタスクを主に AZ 間でバランスされた状態に保ち、次にインスタンス上で効率的にビンパッキングを行うことで、可用性とコスト最適化のバランスを最適化することです。 デモのウォークスルー このウォークスルーでは、マネージドインスタンスキャパシティプロバイダーで構成された Amazon ECS クラスターをデプロイすることで、ECS マネージドインスタンスの実践的なデモを作成します。このセットアップには、CPU とメモリの要件が異なる 2 つの個別の ECS サービスが含まれています。ECS リソースをプロビジョニングするために、 Amazon Virtual Private Cloud (Amazon VPC) 、IAM、EC2 リソースもプロビジョニングします。AWS CLI を使用し、AWS CloudFormation 経由で初期リソースセットをプロビジョニングします。次に、ECS API に対する AWS CLI コマンドを使用してサービス内の ECS タスクの数を更新し、ECS が内部で EC2 インスタンスを管理する様子を観察します。このデモ全体を完了するのに約 40 分かかります。 前提条件 CloudFormation、ECS、EC2 の操作権限を持つユーザー AWS CLI 手順 この GitHub リポジトリから CloudFormation テンプレートをダウンロードします。  - vpc-stack.json、ecs-stack.json、nested-stack-coordinator.json git clone https://github.com/aws-samples/sample-amazon-ecs-managed-instances cd sample-amazon-ecs-managed-instances/cfn-templates CloudFormation テンプレートを配置する S3 バケットを作成し、テンプレートを S3 バケットに配置します。 export AWS_REGION=us-west-2 export BUCKET_NAME=ecs-managed-instances-templates-$(date +%s%N | sha256sum | head -c 6) aws s3 mb s3://$BUCKET_NAME --region $AWS_REGION CloudFormation テンプレートを上記の S3 バケットに配置します。 aws s3 cp vpc-stack.json s3://$BUCKET_NAME aws s3 cp ecs-stack.json s3://$BUCKET_NAME aws s3 cp nested-stack-coordinator.json s3://$BUCKET_NAME nested-stack-coordinator.json テンプレートで CloudFormation スタックを作成します。これにより、アカウントに 3 つの CloudFormation スタック (Coodinator Stack, VPC Stack and ECS stack) が作成されます。Coodinator Stack が VPC Stack と ECS stack を作成します。VPC Stack には VPC リソースが含まれ、ECS stack には ECS リソースが含まれます。 aws cloudformation create-stack --stack-name managed-instances-coordinator --template-body file://nested-stack-coordinator.json --parameters ParameterKey=VpcStackTemplateUrl,ParameterValue=https://$BUCKET_NAME.s3.amazonaws.com/vpc-stack.json ParameterKey=EcsStackTemplateUrl,ParameterValue=https://$BUCKET_NAME.s3.amazonaws.com/ecs-stack.json --capabilities CAPABILITY_NAMED_IAM --region $AWS_REGION CloudFormation によって作成されるリソースは以下の通りです。 マネージドインスタンスキャパシティプロバイダーを持つ 1 つの ECS クラスター 2 つの ECS サービス: ManagedInstancesService1 : タスクあたり 1 vCPU、5.5GB メモリ ManagedInstancesService2 : タスクあたり 1 vCPU、9.5GB メモリ AZ 間で分散された合計 4 つのタスク (サービスごとに 2 つ) マネージドインスタンスキャパシティプロバイダー内の 2 つの マネージドインスタンス ECS クラスターと ECS サービス 図 4: 1 つのクラスターで、サービスごとに 2 つのタスクが実行されている 2 つの ECS サービス ECS タスク アプリケーションは、高可用性を実現するために 2 つの AZ (us-west-2a と us-west-2b) に分散して 4 つの ECS タスクを実行しています。1 つの AZ で問題が発生した場合でも、アプリケーションは他の AZ から実行を継続するため、単一障害点がなくなり、サービスの可用性が一貫して確保されます。 図 5: サービスごとにタスクのリソース設定が異なる 2 つの ECS サービスに対する 4 つの ECS タスク Amazon ECS マネージドインスタンス キャパシティプロバイダー 図 6: 2 つの AZ にまたがる 2 つのインスタンスで実行されているマネージドインスタンスキャパシティプロバイダー。リソースの利用が最適化される マネージドインスタンスキャパシティプロバイダーは、正確なリソース要件を分析しました。インスタンスごとに合計 15GB のメモリ (9.5GB + 5.5GB) と 2 つの vCPU が必要でした。ECS は、2 つの AZ で最適な r5a.large インスタンス (2 vCPU、16GB メモリ) をプロビジョニングし、高可用性を確保しつつリソース効率を最大化しました。各インスタンスでは、両方のサービスタスクが効率的に実行されています。16GB のメモリのうち 15GB が使用され、両方の vCPU も積極的に使用されています。この結果、手動による推測作業を排除し、効率的なリソース割り当てによってコストを削減しながら、アプリケーションに必要なパフォーマンスを維持する、インテリジェントな容量管理が実現されました。 次に、ManagedInstancesService1 の希望タスク数を 0 に設定して、ECS マネージドインスタンスのインテリジェントなリソース管理を実演します。この操作により、現在 2 つの r5a.large インスタンス上で実行中の 2 つのタスク (それぞれ 9.5GB のメモリ、1 vCPU) が停止します。ManagedInstancesService1 のタスクが削除されると、各インスタンスでは残りの ManagedInstancesService2 のタスク (それぞれ 5.5GB のメモリ、1 vCPU) のみが実行されます。これにより、r5a.large インスタンス (16GB、2 vCPU) で単一の 5.5GB タスクが実行され、未使用の容量が生じるリソース利用状況が作られます。 aws ecs update-service --cluster $(aws cloudformation describe-stacks --stack-name managed-instances-coordinator --query 'Stacks[0].Outputs[?OutputKey==`EcsClusterId`].OutputValue' --output text) --service ManagedInstancesService1 --desired-count 0 --region $AWS_REGION 図 7: ECS タスクを停止すると、マネージドインスタンスキャパシティプロバイダーのインスタンスが過小利用になる ECS マネージドインスタンスキャパシティプロバイダー は、このようなリソースの非効率を素早く検出し、利用率の低いインスタンスの 1 つをドレインすることで対処します。現在のワークロードに対して両方のインスタンスが最適ではなくなりますが、システムはサービスの可用性を損なうリスクがあるため、同時にドレインすることはありません。代わりに、ECS は可用性を最優先するアプローチを取り、インスタンスを段階的にドレインします。最適化プロセス中に十分なアクティブ容量を維持することで、新しいタスクの配置や予期しないスケーリングイベントに対して常に容量を確保できます。 図 8: マネージドインスタンスキャパシティプロバイダーが利用率の低いインスタンスをドレインする ドレイン処理が完了すると、排除されたタスクは残りの us-west-2a のインスタンスに移動します。このインスタンスには十分なリソースが残っています。ECSマネージドインスタンスは、サービスの安定化を早めるため、新規プロビジョニングよりも既存の容量を優先します。両方の ManagedInstancesService2 タスクは、リソース活用を最大化するため、単一のインスタンス上で実行されます。一方で、ドレインされたインスタンスは空になります。ECS は自動的にこの空のインスタンスを登録解除し、終了させます。これにより、インフラストラクチャは 2 つのインスタンスから 1 つに縮小されます。これは、実際の需要に基づく継続的な適正化を示しています。ECS は、後の最適化ステップで AZ の分散を処理し、効率性と高可用性のバランスを取ります。 図 9: マネージドインスタンスキャパシティプロバイダーが、タスクのないアイドル状態のインスタンスを登録解除する ECS クラスターが安定した後、ECS は新しい AZ でタスクの置換を開始しながら、既存のタスクを停止することで、AZ 間でワークロードを自動的に再分散します。これにより、5.5GB のタスクに対して、2 番目の AZ に適切なサイズの r7a.medium インスタンス (1 vCPU、8GB) がプロビジョニングされ、一方で元の r5a.large インスタンスは 1 つのタスクを実行するには過剰なリソースとなります。ECS マネージドインスタンスキャパシティプロバイダーはこの非効率性を検出し、過小利用のインスタンスをドレインすることで、AZ 間の高可用性と費用対効果のバランスを取った継続的な最適化を実現します。 図 10: マネージドインスタンスキャパシティープロバイダーの AZ 再分散と継続的な最適化 最終的に、マネージドインスタンスキャパシティプロバイダーは、2 つの AZ にまたがって、それぞれ 1 つのタスク (1 vCPU、5.5 GB) を実行する 2 つの r7a.medium インスタンス (1 vCPU、8 GB) を実行する最適な状態になります。 図 11: インフラストラクチャの最適化後、最適な容量で実行されているマネージドインスタンスキャパシティプロバイダー 長時間実行のワークロード 図 12: ECS タスクの予測可能なスケーリングを伴う長時間実行テスト 図 13: 周期的なスケーリングパターンのキャパシティプロバイダーメトリクス ECS マネージドインスタンスキャパシティプロバイダーは、リソースを実際の需要に合わせてマッチングします。別のテストシナリオ (図 12) では、2 つの ECS サービスがワークロードの変更を 30 分ごとに繰り返し、合計 100 タスクから 70 タスクに、さらに 2 タスクにスケーリングしています。これは 2 時間にわたって行われ、1 分間隔でデータを取得することで、キャパシティプロバイダーがこれらのワークロード変更にどのように対応しているかを詳細に確認できます。 ここでの重要なインサイトは、ECS マネージドインスタンス が、リソース割り当てと実際の需要の間の強力な整合性を維持し、vCPU とメモリ使用率のメトリクスが正確に ECS タスクのサイクルパターンを反映していることです。 DrainingContainerInstances メトリクスは、バックグラウンドで継続的に最適化が行われていることを示しています。手動による介入を待つのではなく、ECS マネージドインスタンスはクラスター全体のリソース効率を継続的に監視し、タスクがスケールダウンすると、すぐに未活用のインスタンスをドレインし、残りのワークロードを適切に移動させて ECS クラスターの密度を最適化します。この自動化されたプロセスにより、リソースが必要以上に長くアイドル状態になることはありません。 クリーンアップ このウォークスルーを完了した後は、継続的な課金を防ぎ、きれいな AWS 環境を維持するために、デプロイしたすべてのリソースをクリーンアップする必要があります。このステップにより、予期しない課金を防ぎ、使用されていないリソースを削除することで AWS 環境を整頓できます。 CloudFormation スタックを削除します aws cloudformation delete-stack --stack-name managed-instances-coordinator --region $AWS_REGION CloudFormation テンプレートと S3 バケットを削除します aws s3 rb s3://$BUCKET_NAME --region $AWS_REGION --force まとめ この記事では、Amazon ECS マネージドインスタンスのインフラストラクチャプロビジョニングとワークフローの最適化について説明しました。初期リリースでは、可用性とコスト効率のバランスを取るために AWS の運用ベストプラクティスが実装されていますが、さまざまなワークロードではコスト、パフォーマンス、可用性の側面でそれぞれ異なるトレードオフが必要になることを理解しています。今後は、プロビジョニングと最適化ワークフローを強化し、最適化ワークフローの設定可能な期間、 capacity headroom やターゲット利用率レベル、カスタム配置戦略、Disruption Budgets など、お客様のコントロールを導入する予定です。 今後のアップデートについては、 GitHub の ECS ロードマップ を参照してください。Amazon ECS の未来を形作るのに役立つフィードバックをお待ちしています。はじめに、 ドキュメント を参照してください。 翻訳はソリューションアーキテクトの加治が担当しました。 原文 はこちらです。

本投稿は、Anil Malakar と Mahesh Kansara と Prabodh Pawar による記事 「 AWS DMS validation: A custom serverless architecture 」を翻訳したものです。 AWS Database Migration Service (AWS DMS) は、ダウンタイムを最小限に抑えて AWS へのデータベース移行をサポートするマネージドサービスです。移行プロセス中にソースデータベースを完全に稼働したまま、同種の移行 (Oracle から Oracle など) と異種の移行 (Oracle から PostgreSQL など) の両方をサポートしています。この投稿では、 AWS サーバーレス サービスを使用して AWS DMS データ検証ソリューションをカスタムに構築する方法を説明します。 データ検証の課題 AWS DMS のお客様は、AWS DMS サービスが提供する データ検証機能 の使用を選択しないかもしれません。ビジネスの要件としてターゲット環境でデータを迅速に利用できるようにする必要がある場合、ロード、大規模なデータセットの転送、またはデータのリロード後、検証が完了するまでに時間がかかってしまうためです。その結果、手動で検証を実行するか、1 回限りのフルロードのみの検証を使用することを選択する可能性がありますが、これには追加の労力と時間が必要になります。 この問題は、ある企業のお客様が毎月手動で検証を行っていることが原因で判明しました。顧客がデータの不一致を発見して報告した時点で、関連する DMS ログはすでに期限切れになっていました。これにより、2つの問題が発生しました。１つは、お客様のビジネスに影響を与える可能性がある正確なデータ検証の機会を逃したこと、もう一つは、根本原因のトラブルシューティングにおいて重大な課題に直面したことです。 この課題に対処するため、カスタマイズされたソリューションアーキテクチャを構築しました。このアーキテクチャは、AWS DMS タスクの完了かエラーが発生したとき (フルロード移行の場合)、あるいは変更データキャプチャ (CDC) 中のソースにアクティブな書き込み/変更がないときに、データ検証プロセスを自動的に実行することを目的としています。 この投稿では、AWS DMS にイベント駆動型データ検証を実装する方法を紹介します。この投稿はアーキテクチャのガイダンスのみです。いくつかのコードスニペットが含まれていますが、それらは参照用であり、特定の実装ニーズに合わせて調整する必要がある場合があります。 当社のカスタムアーキテクチャアプローチでは、移行パフォーマンスを損なうことなく、自動データ検証の恩恵を受けることができます。ソースデータベースとターゲットデータベース間の単純なレコード数の比較から、ビジネス固有のデータポイントを対象とした複雑なマルチテーブルクエリまで、データ検証に柔軟性があります。このアーキテクチャは、検証結果をメールなどの選択した通信チャネルを通じて自動的に配信するので、AWS DMS コンソールにログインする必要がなくなります。これは、通知を通じてデータ品質を監視するのに役立ちます。 このカスタム検証アプローチは、DMS のネイティブな検証機能の代替手段ではなく並行して機能します。特定のデータ品質要件に基づいて検証チェックを自動化する柔軟性があります。 ソリューションの概要 このアーキテクチャは、 AWS サーバーレスコンピューティング とイベント駆動型のメカニズムを使用して、2 つの方法でデータを検証します： AWS DMS タスクのステータスが変更されたときに自動的に (例えば、 REPLICATION_TASK_STOPPED がトリガーされたとき) Amazon EventBridge で定義されたスケジュールに基づいて どちらの場合も、 AWS Lambda 関数がデータ検証を実行し、結果は Amazon Simple Notification Service (Amazon SNS) のメール通知を使用して自動的に送信されます。 次の図は、ソリューションアーキテクチャを示しています。 前提条件 始める前に、次の前提条件を満たす必要があります: AWS DMS レプリケーションインスタンスを作成します。 AWS DMS のソースエンドポイントとターゲットエンドポイントを作成し、それぞれソースデータベースとターゲットデータベースに接続します。 AWS DMS タスクを作成し、タスクにエンドポイントを関連付け、 Amazon CloudWatch ログを有効にします。 AWS Identity and Access Management （ IAM ）ロールを使用して、必要な AWS サービスにアクセスするための適切な権限があることを確認します。 このソリューションを実装するには、 AWS Lambda 関数を記述およびカスタマイズするための Python プログラミング言語 の知識が必要です。 Lambda 関数の作成 カスタムデータ検証を実装するには、まず Lambda 関数を作成し、特定のジョブを実行するためのファイルを追加します。これは、ソリューションをモジュール化し続けるためです。次のスクリーンショットは、さまざまなカスタムモジュールを示しています。 アーキテクチャは、以下のような構造であるべきです。これは必要に応じて拡張できます： dms_task_details – AWS DMS タスク情報を管理し、AWS DMS タスクのソースとターゲットエンドポイントを取得します。 dms_task_event – AWS DMS フルロードタスクから発生したイベントから AWS DMS タスクの詳細を取得します。 dms_task_latency – AWS DMS タスクのレイテンシーメトリクスを処理します: Amazon CloudWatch から AWS DMS レイテンシーメトリクスを取得します。 CDC のソースレイテンシーとターゲットレイテンシーの両方を監視します。 lambda_function – AWS DMS レプリケーションタスクの自動検証システムとして機能します。次の機能を実行します: AWS DMS イベントのモニタリング: AWS DMS タスクイベントをキャプチャして処理します。特に REPLICATION_TASK_STOPPED イベントを監視します タスクが停止すると、dms_task_event_details モジュールの dms_task_event_details メソッドを介して詳細なイベント処理がトリガーされます。 レプリケーションデータの検証: ソースとターゲットの両方の AWS DMS レプリケーションレイテンシーメトリックスを監視します。 並列処理を実装して、ソースとターゲットのデータ数を効率的に比較します。 検証を行う前のレイテンシー閾値チェック （5 秒未満） を含みます。 パラレルデータ検証: 並行実行には ThreadPoolExecutor を使用します。これは、ソースデータベースとターゲットデータベースで同時にクエリを実行するのに役立ちます。 ソースクエリとターゲットクエリを並行して実行することでパフォーマンスを最適化します。 notification – Amazon SNS を使用してアラート通知を実行します: 検証結果の自動通知を実装しています。 ソースとターゲットのデータ数の不一致を報告します。 トラブルシューティングに役立つ詳細なエラーメッセージを提供します。 requirements.txt – アプリケーションに必要なすべての依存関係を一覧表示します。この場合、Lambda 関数が MySQL データベースと通信できるようにするライブラリである PyMySQL バージョン 1.0.2 を指定しています。Lambda 関数を MySQL に接続するには、関数に PyMySQL パッケージを含む レイヤーを追加 する必要があります。 source_db – ソースデータベースの操作を管理します。AWS Secrets Manager に保存されている認証情報を使用して AWS DMS ソースデータベースに接続し、source.sql で定義されたクエリを実行するコードを実装します。 source.sql – ソースデータベースからデータを取得し、レプリケーションが成功したことを確認するためにターゲットデータベースと比較する SQL クエリが含まれています。 target_details – ターゲットデータベースの操作を処理します。AWS Secrets Manager に保存されている認証情報を使用して AWS DMS ターゲットデータベースに接続し、 target.sql ファイルに定義されているクエリを実行するコードを実装します。 target.sql – レプリケーションが成功したことを確認するために、ソースデータベースに対応するターゲットデータベースからデータを取得する SQL クエリが含まれています。 フルロードの場合 AWS DMS のステータス変更イベント REPLICATION_TASK_STOPPED が、Lambda 検証関数の lambda_handler 関数イベントパラメータで受信されます。 REPLICATION_TASK_STOPPEDイベントのイベントパラメータからイベントタイプを取得して、イベントリソースからタスクを取得します。次のコードを参照してください: event_type = event['detail']['eventType']    if(event_type == 'REPLICATION_TASK_STOPPED'): dms_event.dms_task_event_details(event) task_arn = event['resources'][0] Boto3 ライブラリを使用して AWS DMS クライアントを作成し、 describe_replication_tasks メソッドのレスポンスからソースとターゲットの詳細を取得します: dms_client = boto3.client('dms',region_name=os.environ.get('AWS_REGION', 'us-east-1')) response = dms_client.describe_replication_tasks(              Filters=[                 {                     'Name': 'replication-task-arn',                     'Values': [task_arn]                 }              ]         ) task = response['ReplicationTasks'][0]   # Get the source and target endpoint ARNs          source_endpoint_arn = task['SourceEndpointArn']          target_endpoint_arn = task['TargetEndpointArn'] クエリの実行と結果送信の自動化 次のステップは、Lambda 検証関数が各データベースで実行して結果を比較するためのソースおよびターゲット固有のクエリを作成することです。Amazon SNS を使用して、結果をユーザーにメールで送信できます。 以下のコードスニペットを参照して、ソースとターゲットからデータを取得し、結果を比較することができます。以下のコードでは、source.sql と target.sql で単純な count クエリを使用してソースとターゲットのデータを比較していますが、クエリを複数のテーブルに拡張したり、成功または失敗を定義するロジックをカスタマイズしたりすることができます。 # get_source_data_details method retrieves DMS task source data by connecting to the source # MySql database, reading the source.sql file, and executing its defined query source_data = sourcedb.get_source_data_details(task_details['Source']) # get_redshift_table_details method retrieves DMS task target data by connecting to the target # Redshift database, reading the target.sql file, and executing its defined query target_data = dmstarget.get_redshift_table_details(task_details['Target']) if source_data==target_data: notify.send_notification('DMS custom data validation succeeded') CDCの場合 Lambda 検証関数は、EventBridge で定義されたスケジュールに従ってトリガーされます。AWS DMS タスクのレイテンシーメトリクスである CDCLatencySource と CDCLatencyTarget を取得する必要があります。 Boto3 を使用して CloudWatch クライアントを作成します： cloudwatch = boto3.client('cloudwatch', region_name=region_name) 以下のコードを使用して CloudWatch からメトリクスを取得します： metrics = ['CDCLatencySource', 'CDCLatencyTarget'] ソースとターゲットのレイテンシーメトリクスを取得するには、CloudWatch クライアントを使用して以下のコードを参照してください： response = cloudwatch.get_metric_statistics( Namespace='AWS/DMS', MetricName=metric, Dimensions=[ {'Name': 'ReplicationTaskIdentifier', 'Value': taskIdentifier}, {'Name': 'ReplicationInstanceIdentifier', 'Value': instance_id} ], StartTime=start_time, EndTime=end_time, Period=6000, # 5-minute intervals Statistics=['Average'] ) source_latency_value = metric['metric'][0]['Average'] target_latency_value = metric['metric'][0]['Average'] レイテンシーが 5 秒未満として指定して下さい（要件に応じて変更可能）。Lambda 検証関数はソースとターゲットの両方のデータベースで並列クエリを実行します。以下のコードでは、source.sql と target.sql で単純な count クエリを使用してソースとターゲットのデータを比較していますが、複数のテーブルにクエリを拡張したり、成功または失敗を定義するロジックをカスタマイズしたりすることができます。 # get_data_parallel メソッドは 2 つのタスクを同時に実行します： # 1. DMS タスクのソースデータを取得：# ソースの MySQL データベースに接続し、source.sql のクエリを読み取って実行 # 2. DMS タスクのターゲットデータを取得：# ターゲットの Redshift データベースに接続し、target.sql のクエリを読み取って実行 if source_latency_value < 5 and target_latency_value < 5: # Lambda ハンドラーでの使用 source_data, target_data = get_data_parallel(sourcedb, dmstarget) Lambda 検証関数は両方のクエリ結果を受け取ると、それらを比較し、Amazon SNSを使用して通知を送信します。以下は、メールで受信した通知の例です: This is a notification from DMS Lambda validation for replication task dms-cdc-task and relication Instance dms-validation-demo-ri has source_data count – 1000000 and target_data count - 1000000! EventBridge のルールを作成してください また、AWS DMS イベントをキャプチャするように EventBridge ルールを設定し、スケジューラーを実行して Lambda 検証機能を呼び出す必要があります。 EventBridge コンソールで、次の JSON に示されている構成を使用してルールを作成します。このルールはフルロードのシナリオで使用されます。 { "source": ["aws.dms"], "detail-type": ["DMS Replication Task State Change"], "detail": { "eventType": ["REPLICATION_TASK_STOPPED"], "type": ["REPLICATION_TASK"], "category": ["StateChange"] } } 次のスクリーンショットに示すように、Lambda 関数にルールのターゲットを設定します。 CDC の場合は、特定のスケジュールで実行するスケジューラーを作成し、ターゲットに Lambda 検証機能を設定します。 技術的範囲と制限事項 このソリューションを実装する前に、その技術的な境界と制約を理解することが重要です。 このセクションでは、このアーキテクチャが達成できることとその制限について概説し、特定のユースケースの要件を満たすかどうかを判断するのに役立ちます。 データベースサポート : 本ソリューションでは MySQL から Redshift への移行シナリオを示していますが、他のデータベースにも対応できるように拡張できます。ただし、照合順序の違いを検証し、文字セットの互換性を確認し、お客様の環境で十分にテストすることを忘れないでください。 LOB の取り扱い : このソリューションは Large Object (LOB) の検証をサポートしていません。これらのカラムを検証の対象から除外することを検討してください。 クエリ : クエリの実行に 15 分以上かかる場合は、Lambda の代わりに Amazon Elastic Container Service (Amazon ECS) または AWS Fargate を使用してください。 コストに関する考慮事項 このソリューションは自動化された検証機能を提供しますが、検証チェックの頻度を調整し、CloudWatch で適切なログ保持期間を設定し、Lambda 関数の実行時間を最適化することで、コストを効果的に管理できます。 不要なコストの発生を防ぐため、このアーキテクチャの実装後はすべてのリソースを削除することを忘れないでください。 まとめ この投稿では、AWS DMS のデータ検証プロセスを自動化し、手動の作業を削減するアーキテクチャをご紹介しました。 このアーキテクチャは、サーバーレスコンピューティングとイベント駆動型アーキテクチャを使用して、データ検証ルーチンを動的にトリガーし、レイテンシーに関する懸念に対処し、データ移行のパフォーマンスへの影響を最小限に抑えます。 ご自身のユースケースでこのアプローチを試してみてください。 著者について Anil Malakar Anil はアマゾンウェブサービスのシニア・テクニカル・アカウント・マネージャーで、アプリケーションのモダナイゼーションやアーキテクチャ、ソリューション設計を専門としています。 Mahesh Kansara Mahesh は Amazon Web Services のデータベースエンジニアリングマネージャーです。彼は開発チームやエンジニアリングチームと緊密に連携して、移行およびレプリケーションサービスを改善しています。また、お客様と協力して、データベースや分析のさまざまなプロジェクトに関するガイダンスや技術支援を行い、AWSを使用する際のソリューションの価値向上を支援しています。 Prabodh Pawar Prabodh は、Amazon Web Services のDatabase Migration Service チームのシニアデータベースエンジニアです。彼はデータベース移行の自動化に役立つサービスとツールを開発しています。Prabodh は、お客様と一緒に、お客様のマイグレーションジャーニーを効率化することに情熱を注いでいます。

本投稿は、 Nelly Susanto による記事 「 Assess and migrate your database using AWS DMS Schema Conversion CLI 」を翻訳したものです。 DMS Schema Conversion は、 AWS Database Migration Service (AWS DMS) の機能で、AWS DMS コンソールと AWS Command Line Interface (AWS CLI) からアクセスできます。これは AWS DMS のフルマネージドな機能で、データベースの評価と変換が可能です。このマルチパートシリーズの 2 回目の投稿では、DMS Schema Conversion コンポーネントの作成と、評価や変換などの移行アクティビティの実行を自動化する方法を紹介します。このシリーズの 最初の投稿 では、DMS Schema Conversion の設定における前提条件の準備、DMS Schema Conversion の設定、AWS DMS コンソールを通じた移行アクティビティの実行についてのガイダンスを提供しています。 AWS CLI を使用する主な利点の 1 つは、特に大規模なデータベース移行において移行プロセスを自動化および合理化できることです。 この投稿では、DMS Schema Conversion を使用して Amazon Relational Database Service (Amazon RDS) for SQL Server データベースを評価し、 Amazon Aurora PostgreSQL-Compatible Edition に変換する方法を記載します。DMS Schema Conversion コンポーネントのセットアップと構成の自動化、評価レポートの生成、データベースストレージとコードオブジェクトの変換、変換されたコードの Amazon Simple Storage Service (Amazon S3) へのエクスポート、そして変換されたコードをターゲットデータベースに適用する方法について、順を追って説明します。 ソリューションの概要 DMS Schema Conversion CLI は AWS CLI Version 2 で利用可能です。現在インストールされているバージョンを確認するには、コマンドプロンプトで次のコマンドを使用してください： aws --version aws-cli/2.17.38 Python/3.11.9 Darwin/24.3.0 exe/x86_64 AWS CLI Version 2 のインストール方法については、 AWS CLI の使用開始 をご覧ください。 DMS Schema Conversionの主要コンポーネントは以下の通りです： インスタンスプロファイル – インスタンスプロファイルは、DMS Schema Conversion が使用するネットワークとセキュリティを定義します。また、内部の DMS Schema Conversion リソースが起動される場所も決定します。 データプロバイダー – データプロバイダーは、DMS Schema Conversion が接続するためのデータベースタイプ、ソースおよびターゲットの接続詳細に関する情報を保存します。 移行プロジェクト – 移行プロジェクトは、すべての DMS Schema Conversion 移行アクティビティの基盤です。ここでは、インスタンスプロファイル、ソースおよびターゲットのデータプロバイダー、移行ルールなどの移行エンティティを定義します。 まず、AWS CLI を使用して主要な DMS Schema Conversion コンポーネントを作成する方法を説明します。 次に、データベースオブジェクトの評価や変換など、移行作業を実行するためのコマンドについて説明します。 このポストでは、AWS リージョンとして us-east-1 を使用し、デフォルトの AWS プロファイルを使用します。 export AWS_DEFAULT_REGION='us-east-1' export AWS_PROFILE=default AWS CLI の環境変数の設定方法については、 AWS CLI の環境変数の設定 をご覧ください。 インスタンスプロファイルの作成 インスタンスプロファイル は、DMS Schema Conversion が使用するネットワークとセキュリティの設定を指定し、内部の DMS Schema Conversion リソースがどこにデプロイされるかを決定します。インスタンスプロファイルの作成プロセスの一部として、DMS Schema Conversion が使用すべきインスタンスプロファイル名、ネットワークタイプ、サブネットグループ、セキュリティグループを指定します。 aws dms create-instance-profile \ --publicly-accessible \ --network-type IPV4 \ --instance-profile-name "ip-demo" \ --description "Instance profile sql to Aurora PG" \ --subnet-group-identifier "sc2" \ --vpc-security-groups sg-052b3xxx \ --query 'InstanceProfile.InstanceProfileArn' \ --output text #Output return Instance Profile arn arn:aws:dms:us-east-1:123456789012:instance-profile:JX6FWLF6T5E4JJXXD5YCDOCABI データプロバイダーの作成 データプロバイダー は、DMS Schema Conversion で使用されるデータベースの種類と、ソースデータベースとターゲットデータベースに関する接続情報に関するメタデータを定義します。このステップでは、データプロバイダーの名前、データベースエンジンの種類、データベースサーバー名、ポート、データベースに接続するための DMS Schema Conversion の SSL モードなどのデータベース設定を指定して、データプロバイダーを作成します。 #Create Source (SQL Server) Data Provider aws dms create-data-provider \ --data-provider-name "demo-sql" \ --description "sql server" \ --engine sqlserver \ --settings "{\"MicrosoftSqlServerSettings\": {\"ServerName\": \"tsw.c3wkj7xxxx.us-east-1.rds.amazonaws.com\", \"Port\": 1433, \"DatabaseName\": \"tsw\"}}" \ --query 'DataProvider.DataProviderArn' \ --output text #Return of source data provide arn arn:aws:dms:us-east-1:123456789012:data-provider:MVPJGML3DJBEJJMYVBZSGRYSMA #Create Target (Aurora PostgreSQL) Data Provider aws dms create-data-provider \ --data-provider-name "demo-pg" \ --description "Aurora PostgreSQL" \ --engine "aurora-postgresql" \ --settings "{\"PostgreSqlSettings\": {\"ServerName\": \"apg1-instance-1.c3wkj7xxxx.us-east-1.rds.amazonaws.com\", \"Port\": 1234, \"DatabaseName\": \"postgres\", \"SslMode\": \"none\"}}" \ --query 'DataProvider.DataProviderArn' \ --output text #Output return of target data provider arn arn:aws:dms:us-east-1:123456789012:data-provider:L72LHMJATZB2TJZIQXMVM5ORM4 移行プロジェクトの作成 DMS Schema Conversion の 移行プロジェクト は、インスタンスプロファイル、ソースとターゲットのデータプロバイダー、移行ルールなどの主要コンポーネントの統合を調整します。AWS CLI コマンドを使用して移行プロジェクトを作成するには、まずプロジェクト名を指定します。次に、プロジェクトが使用するインスタンスプロファイルを関連付けます。次に、ソースとターゲットのデータプロバイダーとそのシークレット、および AWS Secrets Manager の AWS ID および AWS Identity and Access Management （IAM）の役割を指定します。最後に、評価レポートとエクスポートされた変換コードの Amazon S3 パスを設定し、Amazon S3 バケットの IAM ロールを指定します。 aws dms create-migration-project \ --migration-project-name "demo-sql-apg" \ --instance-profile-identifier "arn:aws:dms:us-east-1:123456789012:instance-profile:JX6FWLF6T5E4JJXXD5YCDOCABI" \ --source-data-provider-descriptors "{\"DataProviderIdentifier\": \"arn:aws:dms:us-east-1:123456789012:data-provider:MVPJGML3DJBEJJMYVBZSGRYSMA\", \"SecretsManagerSecretId\": \"arn:aws:secretsmanager:us-east-1:123456789012:secret:sql-aiml-9Wmj68\", \"SecretsManagerAccessRoleArn\": \"arn:aws:iam::123456789012:role/aws-dms-sc-oltp\"}" \ --target-data-provider-descriptors "{\"DataProviderIdentifier\": \"arn:aws:dms:us-east-1:123456789012:data-provider:L72LHMJATZB2TJZIQXMVM5ORM4\", \"SecretsManagerSecretId\": \"arn:aws:secretsmanager:us-east-1:123456789012:secret:apg1-Lzc3TT\", \"SecretsManagerAccessRoleArn\": \"arn:aws:iam::123456789012:role/aws-dms-sc-oltp\"}" \ --description description \ --schema-conversion-application-attributes "{\"S3BucketPath\": \"s3://amzn-s3-demo-bucket\", \"S3BucketRoleArn\": \"arn:aws:iam::123456789012:role/aws-dms-sc-oltp\"}" \ --query 'MigrationProject.MigrationProjectArn' \ --output text #Output project arn arn:aws:dms:us-east-1:123456789012:migration-project:HYY6WUCDVRG43NTF2JK5URI6II ソース選択ルールの作成 DMS Schema Conversion のコンポーネントを作成する AWS CLI コマンドについて説明してきました。それでは、移行アクティビティを実行するコマンドを見てみましょう。最初のステップは、DMS Schema Conversion で移行プロセスに含めたいデータベースオブジェクトを定義するソースの選択ルールを作成することです。以下は、ユースケースに合わせて必要に応じて変更できる選択ルールの例です。 cat > source_rules.json << EOF { "rules": [ { "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "server-name": "tsw.c3wkj7xxxx.us-east-1.rds.amazonaws.com", "database-name": 'tsw', "schema-name": 'dbo' }, "rule-action": "explicit" ]} EOF このルールを設定したら、次のステップであるデータベースオブジェクトの評価と変換に進むことができます。 アセスメントレポートの作成 アセスメントを開始するには、start-metadata-model-assessment コマンドを使用します。移行プロジェクトの Amazon Resouce Name (ARN) と、前のセクションで作成したソースの選択ルールを指定してください。 aws dms start-metadata-model-assessment \ --migration-project-identifier arn:aws:dms:us-east-1:123456789012:migration-project:35TRQ7CYINHXXK7HQYMD2BUS64 \ --selection-rules file://source_rules.json #Response { "RequestIdentifier": "44fc9838-146f-41d8-b13c-923b3cc704c2" } 評価の進捗状況を確認するには、describe-metadata-model-assessments コマンドを使用してください。 aws dms describe-metadata-model-assessments \ --migration-project-identifier arn:aws:dms:us-east-1:123456789012:migration-project:35TRQ7CYINHXXK7HQYMD2BUS64\ --query 'Requests[0].Status' --output text #Response IN_PROGRESS SUCCESS This is the full list of operation statuses: IN_PROGRESS, SUCCESS, FAILED, DUPLICATE, RETRY, CANCELING, CANCELLED. 評価レポートのエクスポート 評価レポートを作成したら、export-metadata-model-assessment コマンドを使用してレポートを Amazon S3 にエクスポートします。PDF 形式のサマリレポートには、移行の複雑さの推定値が記載されています。DMS Schema Conversion には、手動でのアクションが必要なオブジェクトや推奨事項を含む詳細なレポートを CSV 形式で生成するオプションもあります。 以下のコードは、サマリレポートを PDF 形式でエクスポートする方法を示しています。サマリではなく詳細なレポートが必要な場合は、assessment-report-type を csv に設定してください。 aws dms export-metadata-model-assessment \ --migration-project-identifier arn:aws:dms:us-east-1:123456789012:migration-project:35TRQ7CYINHXXK7HQYMD2BUS64\ --selection-rules file://source_rules.json\ --file-name "assessment report" \ --assessment-report-types "pdf" #Assessment reports are available in S3 Exporting metadata model assessment... { "PdfReport": { "S3ObjectKey": "demo-sql-apg/report.pdf", "ObjectURL": "https://sc-123456789.s3.amazonaws.com/demo-sql-apg/report.pdf" } } { "CsvReport": { "S3ObjectKey": "demo-sql-apg/report.zip", "ObjectURL": "https://sc-123456789.s3.amazonaws.com/demo-sql-apg/report.zip" } } 変換を実行 変換を実行する準備ができたら、 start-metadata-model-conversion を使用します。以前に作成したマイグレーションプロジェクトの ARN とソースの選択ルールを指定してください： aws dms start-metadata-model-conversion \ --migration-project-identifier arn:aws:dms:us-east-1:123456789012:migration-project:35TRQ7CYINHXXK7HQYMD2BUS64 \ --selection-rules file://source_rules.json describe-metadata-model-conversions コマンドを使用して、変換の進捗状況を確認できます： aws dms describe-metadata-model-conversions \ --migration-project-identifier arn:aws:dms:us-east-1:123456789012:migration-project:35TRQ7CYINHXXK7HQYMD2BUS64\ --query 'Requests[0].Status' --output text #Response IN_PROGRESS SUCCESS 変換したコードをSQLとしてエクスポート 変換が完了すると、変換されたコードは移行プロジェクト内で利用可能になります。SQL としてエクスポートするか、ターゲットデータベースに直接適用することができます（適用方法については次のセクションを参照してください）。エクスポートまたは適用する前に、まずターゲットの選択ルールでデータベースオブジェクトを定義する必要があります。以下のコードは、ターゲット選択ルールの例です。必要に応じて、ユースケースに合わせて修正することができます。 cat > target_rules.json << EOF { "rules": [ { "rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": { "server-name": " apg1-instance-1.c3wkj7xxxx.us-east-1.rds.amazonaws.com", "schema-name": 'tsw_dbo' }, "rule-action": "explicit" } ] } EOF これで、 start-metadata-model-export-as-script コマンドを使用して、変換されたコードを SQL としてエクスポートできます。移行プロジェクト、ターゲット選択ルール、Origin には対象として Target を指定、ファイル名を記載してください： aws dms start-metadata-model-export-as-script \ --migration-project-identifier arn:aws:dms:us-east-1:123456789012:migration-project:35TRQ7CYINHXXK7HQYMD2BUS64 \ --selection-rules file://target_rules.json \ --origin TARGET \ --file-name "SaveAsSQL" エクスポートの進行状況を確認するには、describe-metadata-model-export-as-script コマンドを使用してください: aws dms describe-metadata-model-exports-as-script \ --migration-project-identifier arn:aws:dms:us-east-1:123456789012:migration-project:35TRQ7CYINHXXK7HQYMD2BUS64 \ --query 'Requests[0].Status' --output text #Response IN_PROGRESS SUCCESS 変換されたコードのターゲットデータベースへの適用 変換されたコードをターゲットデータベースに適用するには、start-metadata-model-export-to-target コマンドを使用します。以前に作成した移行プロジェクトの ARN とターゲットの選択ルールを指定してください： aws dms start-metadata-model-export-to-target \ --migration-project-identifier arn:aws:dms:us-east-1:123456789012:migration-project:35TRQ7CYINHXXK7HQYMD2BUS64 \ --selection-rules file://target_rules.json \ --overwrite-extension-pack 適用の進行状況を確認するには、describe-metadata-model-exports-to-target を使用します： aws dms describe-metadata-model-exports-to-target \ --migration-project-identifier arn:aws:dms:us-east-1:123456789012:migration-project:35TRQ7CYINHXXK7HQYMD2BUS64\ --query 'Requests[0].Status' --output text #Response IN_PROGRESS SUCCESS 移行後のクリーンアップ 移行が完了したら、DMS Schema Conversion リソースをクリーンアップできます。 #Cleanup # Delete migration project aws dms delete-migration-project \ > --migration-project-identifier arn:aws:dms:us-east-1:123456789012:migration-project:HYY6WUCDVRG43NTF2JK5URI6II #Response { "MigrationProject": { "MigrationProjectName": "demo-sql-apg", "MigrationProjectArn": "arn:aws:dms:us-east-1:123456789012:migration-project:HYY6WUCDVRG43NTF2JK5URI6II", "MigrationProjectCreationTime": "2024-08-01T17:29:05.681257 + 00:00", "SourceDataProviderDescriptors": [ { "SecretsManagerSecretId": "arn:aws:secretsmanager:us-east-1:123456789012:secret:sql-aiml-9Wmj68", "SecretsManagerAccessRoleArn": "arn:aws:iam::123456789012:role/aws-dms-sc-oltp", "DataProviderName": "demo-sql", "DataProviderArn": "arn:aws:dms:us-east-1:123456789012:data-provider:MVPJGML3DJBEJJMYVBZSGRYSMA" } ], "TargetDataProviderDescriptors": [ { "SecretsManagerSecretId": "arn:aws:secretsmanager:us-east-1:123456789012:secret:apg1-Lzc3TT", "SecretsManagerAccessRoleArn": "arn:aws:iam::123456789012:role/aws-dms-sc-oltp", "DataProviderName": "demo-pg", "DataProviderArn": "arn:aws:dms:us-east-1:123456789012:data-provider:L72LHMJATZB2TJZIQXMVM5ORM4" } ], "InstanceProfileArn": "arn:aws:dms:us-east-1:123456789012:instance-profile:JX6FWLF6T5E4JJXXD5YCDOCABI", "InstanceProfileName": "ip-demo", "TransformationRules": "{\"rules\":[]}", "SchemaConversionApplicationAttributes": { "S3BucketPath": "s3://amzn-s3-demo-bucket", "S3BucketRoleArn": "arn:aws:iam::123456789012:role/aws-dms-sc-oltp" } } } #Delete source data provider aws dms delete-data-provider --data-provider-identifier arn:aws:dms:us-east-1:123456789012:data-provider:MVPJGML3DJBEJJMYVBZSGRYSMA #Response { "DataProvider": { "DataProviderName": "demo-sql", "DataProviderArn": "arn:aws:dms:us-east-1:123456789012:data-provider:MVPJGML3DJBEJJMYVBZSGRYSMA", "DataProviderCreationTime": "2024-08-01T17:27:12.902435 + 00:00", "Engine": "sqlserver", "Settings": { "MicrosoftSqlServerSettings": { "ServerName": "tsw.c3wkj7xxxx.us-east-1.rds.amazonaws.com", "Port": 1433, "DatabaseName": "tsw", "SslMode": "none" } } } } #Delete Target data provider aws dms delete-data-provider --data-provider-identifier arn:aws:dms:us-east-1:123456789012:data-provider:L72LHMJATZB2TJZIQXMVM5ORM4 #Response { "DataProvider": { "DataProviderName": "demo-pg", "DataProviderArn": "arn:aws:dms:us-east-1:123456789012:data-provider:L72LHMJATZB2TJZIQXMVM5ORM4", "DataProviderCreationTime": "2024-08-01T17:27:12.902435 + 00:00", "Engine": "aurora-postgresql", "Settings": { "MicrosoftSqlServerSettings": { "ServerName": "apg1-instance-1.c3wkj7xxxx.us-east-1.rds.amazonaws.com", "Port": 1234, "DatabaseName": "postgres", "SslMode": "none" } } } } #Delete Instance Profile aws dms delete-instance-profile --instance-profile-identifier arn:aws:dms:us-east-1:123456789012:instance-profile:JX6FWLF6T5E4JJXXD5YCDOCABI #Response { "InstanceProfile": { "InstanceProfileArn": "arn:aws:dms:us-east-1:123456789012:instance-profile:JX6FWLF6T5E4JJXXD5YCDOCABI", "KmsKeyArn": "arn:aws:kms:us-east-1:123456789012:key/e26404b5-853a-4a33-95b9-99ef043cd207", "PubliclyAccessible": true, "NetworkType": "IPV4", "InstanceProfileName": "ip-demo", "InstanceProfileCreationTime": "2024-08-01T17:25:33.128750 + 00:00", "SubnetGroupIdentifier": "sc2", "VpcSecurityGroups": [ "sg-052b3xxx" ] } } まとめ 特に大規模なデータベース移行の場合で、AWS CLI による DMS Schema Conversion を使用する主な利点は、移行プロセスを自動化および合理化できることです。この投稿では、AWS CLI を使用して、インスタンスプロファイル、データプロバイダー、移行プロジェクトなど、主要な DMS Schema Conversion のコンポーネントを設定する方法を示しました。選択ルールの作成、評価レポートの生成、変換の実行、変換されたコードのエクスポート、変換されたコードのターゲットデータベースへの適用という移行ワークフローを順を追って説明しました。このソリューションは、移行プロセスの自動化と標準化に役立ち、手作業を減らし、リスクを最小限に抑えます。チームが複数のワークロードを同時に移行する必要がある場合に最適です。大規模な移行を計画している場合は、このソリューションを活用して作業を合理化し、移行を加速することをお勧めします。 DMS SC CLI を使用してデータベースオブジェクトを評価および変換する方法の詳細については、 AWS DMS CLI リファレンスガイド をご覧ください。 著者について Nelly Susanto Nelly は、AWS Database Migration Accelerator の主任データベース移行スペシャリストです。彼女はデータベースとデータウェアハウスのワークロードの移行と複製に焦点を当てた技術経験が 10 年以上あります。彼女はお客様のクラウドジャーニーを支援することに情熱を注いでいます。

本投稿は、 Caius Brindescu と Mahesh Kansara による記事 「 Real-time Iceberg ingestion with AWS DMS 」を翻訳したものです。 これは、AWS とのパートナーシップに基づいた、Etleap の主任エンジニアである Caius Brindescu によるゲスト投稿です。 タイムリーな意思決定には、低レイテンシーで最新のデータにアクセスすることが不可欠です。しかし、多くのチームにとって、データレイクへのレイテンシーを削減することは、更新の処理、パイプラインの複雑さ、ウェアハウスとの統合と格闘することを意味します。 Apache Iceberg は、リアルタイムの取り込みとマルチエンジンアクセスを実用的かつ効率的にすることで、この方程式を変えます。 Etleap は、AWS データ＆アナリティクスコンピテンシーと Amazon Redshift サービスレディの認定を受けた AWS アドバンストテクノロジーパートナー です。この投稿では、Etleap が、 AWS Database Migration Service（AWS DMS） を使用して、オペレーション中の SQL データベースからIceberg テーブルにデータをストリーミングする、スケーラブルでほぼリアルタイムのパイプラインの構築にどのように役立つかを示します。AWS DMS は、 すべての主要なデータベース から AWS への変更データキャプチャ（CDC）のための堅牢で構成可能なソリューションとして使用できます。 実際のユースケースを参考に、一貫性、耐障害性、クラウドデータウェアハウスとの統合をどのように提供しているかをご紹介します。これにより、最も重要な時にデータがアクションを促す原動力となります。 AWS DMS の概要 AWS DMS は、リレーショナルデータベース、データウェアハウス、NoSQL データベース、その他のタイプのデータストアの移行を簡単に実現するクラウドサービスです。 AWS DMS を使用して、データを AWS クラウドに移行したり、クラウドとオンプレミス環境の組み合わせ間で移行したりすることができます。 AWS DMS を使用すると、1 回限りの移行を実行できるほか、継続的な変更を複製して、ソースとターゲットを様々な要件に応じてほぼリアルタイムで同期させることができます。ソースで変更が行われてからターゲットに複製されるまでに、わずかな遅延が生じる可能性があります。この遅延、つまり レイテンシー は、AWS DMS の設定、ネットワーク帯域幅、ソースおよびターゲットデータベースの負荷など、さまざまな要因の影響を受ける可能性があります。 次の図は、AWS DMS のレプリケーションプロセスを示しています。 Iceberg の概要 Iceberg は、データレイク上の大規模分析用に設計されたオープンテーブルフォーマットです。 コストの高いテーブルの書き換えやダウンタイムを必要とせずに、ACID トランザクションの完全サポート、隠しパーティショニング、スキーマ進化、タイムトラベルを提供します。 Iceberg は、Hive のような古い形式とは異なり、メタデータとデータファイルを別々に追跡し、スナップショットの高速読み取りと効率的なファイルレベルの更新を可能にします。データファイルはイミュータブルで、新しいスナップショットを作成することで変更が適用されるため、upserts や delete などの操作が安全で効率的になります。次の図は、Iceberg テーブルのファイルレイアウトを示しています。 Iceberg は、エンジンに依存しないデータストレージフォーマットであり、Spark、Apache Flink、Trino （ Amazon Athena などのサービスを含む）、および Hive と統合されています。 これは、複数のダウンストリームシステムに確実にサービスを提供できる、本番環境グレードの低レイテンシーデータレイクアーキテクチャを構築するための強固な基盤となります。 カタログをクエリすることで、各エンジンは格納されているデータの一貫したビューを持つことができます。 Etleap の顧客が Iceberg を必要とする理由 Etleap のお客様にとって、低レイテンシーは最優先事項です。 ここでいうレイテンシーとは、ソースデータとターゲットデータの間の時間差として定義しています。 例えば、ターゲットがソースより 5 分遅れている場合、レイテンシーは 5 分となります。 従来のデータウェアハウスやデータレイクでは、レイテンシーをどこまで低く抑えられるかに制限があります。 ウェアハウスでは、新しいデータがステージング領域にロードされ、その後、ターゲットテーブルの大部分をスキャンしてから書き換えるようなマージが実行されます。 データに 2 回アクセスする (1 回は読み取り、1 回は書き換え) ことが、遅延の大部分を引き起こしています。 一方、データレイクは通常追加専用で、更新を効率的に処理しません。すべての行バージョンを保存してクエリ時に最新のバージョンを解決する（クエリのパフォーマンスを犠牲にする）か、ロード時に最新の状態を事前に計算することができます。ロード時にコストの高いテーブルの書き換えが必要になり、待ち時間が長くなります。 Iceberg は、Etleap ユーザーにとってこれらの両方の課題を解決します。ある事例では、ヨーロッパの自転車シェアリング企業が、自転車ラックの空き状況を監視し、ラックが空の状態で放置される時間を制限する規制を遵守するために運用ダッシュボードを使用しています。Iceberg は、パイプラインのレイテンシーを 5 ～ 10 分から数秒に短縮することで、より リアルタイムなデータを可能にし、オペレーターがラックのバランスを取り直し、ペナルティを回避するための重要な追加時間を提供します。 別のケースでは、チームは 1 つのデータセットを複数のデータウェアハウスで利用できるようにする必要がありました。以前は、移行先ごとに別々のパイプラインを構築して維持する必要がありました。Icebergを使用すると、データを一度ロードして複数のエンジンからのクエリがサポートされるため、複雑さが軽減され、ツール間の一貫性が保たれます。 ソリューションの概要 最初のステップは、ソースデータベースからできるだけ迅速に更新を抽出することです。このために、高スループットのデータキャプチャ (CDC) に確実にスケールする AWS DMS を使用します。AWS DMS は変更を Amazon Kinesis Data Streams に書き込みます。Etleap はこのデータストリームを読み取り、 Amazon EMR 上の Flink を使用して変更を処理します。 そこから、データは Amazon S3 に保存された Iceberg テーブルに書き込まれ、 AWS Glue がデータカタログとして使用されます。これにより、複数のクエリエンジンからデータをクエリできるようになります。 以下の図は、パイプラインのアーキテクチャを示しています。 完全に一度だけの処理 低遅延のパイプラインでデータの整合性を維持するには、データを迅速に移動するだけでは不十分です。また、データを一度だけ処理する必要もあります。レコードが重複または欠落していると、特に更新が多いワークロードでは、誤った結果になる可能性があります。変更が AWS DMS によってキャプチャされ、Kinesis Data Streams にストリーミングされた後、Etleap は Flink の2フェーズコミットプロトコルを使用して1回だけ処理します。 フェーズ 1 では、Flink が各並列データストリームにチェックポイントバリアを挿入します（次の図を参照）。 バリアがパイプラインを流れる際、各オペレーターは一時停止し、同期的に状態を保存してから、バリアをダウンストリームに転送します。その後、状態のスナップショットを耐久性のあるストレージ（この場合は Amazon S3 ）に非同期で永続化します。 この分離により、I/O 待ちの間も重要な処理がブロックされないことが保証されます。オペレーターが状態の保存に成功すると、チェックポイントが完了したことを Flink Job Manager に通知します。 フェーズ 2 では、パイプラインのすべての部分でチェックポイントを完了したことをジョブマネージャーが確認し、その後グローバルなコミット信号をブロードキャストします (次の図を参照)。 この時点で、オペレーターは外部システムへのデータ書き込みなどの副作用を安全に実行できます。 Etleap の場合、これには Iceberg テーブルへの新しいスナップショットのコミットや、モニタリング用のメトリクスの記録が含まれます。 耐障害性をサポートするため、コミット操作は冪等性を備えるように実装されています。これは、Iceberg テーブルに新しいスナップショットを書き込む場合と、パイプラインのメトリクスとログを記録する場合の両方に適用されます。 この段階でパイプラインが失敗し、再起動が必要になった場合、Flink は安全にコミットを再試行します。 各操作は、重複や不整合を生じることなく複数回実行できるため、障害が発生した場合でもデータの正確性を維持できます。 パズルの最後のピースは、チェックポイントの頻度、つまりパイプラインがどのくらいの頻度でデータを Iceberg にコミットするかです。 この設定は、パイプライン全体のレイテンシーを決定する上で重要な役割を果たします。 ユースケースを評価した結果、3 秒のチェックポイント間隔を選択しました。 これは効果的なバランスを取っています。エンドツーエンドのレイテンシーを 5 秒未満に抑えつつ、頻繁なコミットによるパフォーマンスのオーバーヘッドを最小限に抑えています。 この間隔は、次のセクションで説明するように、ウェアハウスのメタデータ更新サイクルともうまく一致しています。 テーブルのメンテナンスとデータウェアハウスの統合 Iceberg テーブルは時間の経過とともに、メタデータ、スナップショット、最適でないファイルレイアウトを蓄積し、パフォーマンスが低下する可能性があります。 クエリのパフォーマンスを高く保ち、ストレージを効率的に使用するためには、定期的なメンテナンスが不可欠です。 これには、データファイルの圧縮、スナップショットの有効期限切れ、メタデータのクリーンアップなどのタスクが含まれます。 Etleap は、取り込みを中断することなく、これらのメンテナンスタスクを自動的に処理します。 メンテナンスジョブはデータパイプラインと並行して実行され、ファイルサイズの分布やスナップショット数などの発見的手法に基づいてトリガーされます。 次のスクリーンショットは、データフローを中断することなく、並行してメンテナンス作業を実行している Etleap パイプラインの例を示しています。 最後の要素はウェアハウスの統合です。Iceberg の主な利点の1つは相互運用性です。Athena、 Amazon Redshift 、Snowflake、Databricks などのエンジンから同じテーブルをクエリできます。 手動でのセットアップも可能ですが、Etleap はパイプラインの作成時にこれらの統合を自動的に設定できます。 例えば、Iceberg テーブルを Snowflake でクエリ可能にするために、AWS Glue とのカタログ統合を作成し、テーブルの Amazon S3 ロケーションを指す外部ボリュームを定義します： CREATE CATALOG INTEGRATION ETLEAP_ICEBERG_CATALOG CATALOG_SOURCE = GLUE GLUE_AWS_ROLE_ARN = 'arn:aws:iam::123456789012:role/etleap-streaming-ingestion-snowflake' GLUE_CATALOG_ID = '123456789012' CATALOG_NAMESPACE = 'iceberg_lake' GLUE_REGION = 'us-east-1' TABLE_FORMAT = ICEBERG ENABLED = TRUE ; CREATE EXTERNAL VOLUME ETLEAP_ICEBERG_EXTERNAL_VOLUME STORAGE_LOCATIONS = (( NAME = 'etleap_iceberg_bucket' STORAGE_PROVIDER = 'S3' STORAGE_AWS_ROLE_ARN = 'arn:aws:iam::123456789012:role/etleap-streaming-ingestion-snowflake' STORAGE_BASE_URL = 's3://<bucket\_name>/iceberg' )) ALLOW_WRITES = FALSE ; その後、Snowflake で Iceberg テーブルを指す新しいテーブルを作成できます： CREATE OR REPLACE ICEBERG TABLE "product_order" EXTERNAL_VOLUME = ETLEAP_ICEBERG_EXTERNAL_VOLUME CATALOG = ETLEAP_ICEBERG_CATALOG CATALOG_NAMESPACE = 'iceberg_lake' CATALOG_TABLE_NAME = 'product_order'; Snowflake を最新の Iceberg スナップショットと同期させるために、Etleap は各コミット後に REFRESH 操作をトリガーします。 これにより、ユーザーは最新のデータを確認でき、Snowflake のビューが大きく遅れることを防ぎます。 リフレッシュの同期的な性質は、自然なレート制限メカニズムも提供し、スナップショットの可視性をウェアハウスのクエリパフォーマンスと整合させます。 まとめ AWS DMS、Kinesis Data Streams、Amazon EMR などの AWS ツールと、Iceberg の更新、スキーマ進化、マルチエンジンアクセスのサポートを組み合わせることで、低レイテンシーで信頼性の高いデータパイプラインを Iceberg に構築することが可能です。 このポストでは、運用データベースからの変更を Iceberg にストリーミングし、エンドツーエンドのレイテンシーを 5 秒未満に抑えながら、データの整合性を維持し、Snowflake のようなツールでのダウンストリーム分析をサポートする方法を紹介しました。 このアーキテクチャは、データレイクの最新化、エンジン間のアクセス統合、リアルタイムの運用要件の達成を目指すチームにとって、強力な基盤となります。 Etleap がどのようにして自動パイプライン作成、耐障害性がある処理、Iceberg のメンテナンスを含め、これらをすぐに実現可能にするかを確認するには、 サインアップ して、パーソナライズされたデモをご覧ください。 著者について Caius Brindescu Caius は Etleap のプリンシパルエンジニアで、ソフトウェア開発で 20 年以上の経験があります。彼は、Hadoop、Spark、Flink などのシステムでの作業を含む、Java バックエンド開発とビッグデータテクノロジーを専門としています。彼はオレゴン州立大学で博士号と AWS certification Big Data – Specialty certification を取得しています。 Mahesh Kansara Mahesh は Amazon Web Services のデータベースエンジニアリングマネージャーです。彼は開発チームやエンジニアリングチームと緊密に連携して、移行およびレプリケーションサービスを改善しています。また、お客様と協力して、データベースや分析のさまざまなプロジェクトに関するガイダンスや技術支援を行い、AWSを使用する際のソリューションの価値向上を支援しています。

本ブログは、東京大学松尾・岩澤研究室が主催する AI エンジニアリング実践講座において、AWS を活用した講座の取り組みをご紹介する、AWS との共同寄稿です。 はじめに 本ブログシリーズでは、2025 年 4 月から 7 月にかけて実施した東京大学 松尾・岩澤研究室の AI エンジニアリング実践講座において、 AWS クラウドを活用した実践的な学習環境を用意し、1400 名を超える受講申し込み者に対して、個別のAWSアカウントを提供する大規模なオンライン講義を開講した取り組みを全 3 回に分けてまとめたものです。 [準備、構築編] 講義に参加する受講生に AWS アカウントを準備し、受講者情報と紐づける [演習、運用編] それぞれの AWS アカウントに適切な権限を配布し、提供期間中管理/運用する [後片づけ編] 講義終了後に、適切にアカウントをクリーンアップする（本ブログ） 最初の [準備、構築編] では、講義で利用する AWS アカウントを作成し、申し込みがあった受講者のメールアドレスと紐づけるところを解説しました。 前回の [演習、運用編] では、受講生の使う AWS アカウントに対して権限の適用と管理方法について説明しました。今回は、環境の後片付けの実施方法とそこで得た知見について共有します。 環境の後片付け 講義終了後、環境の後片付けを実施しました。 まずは受講者の権限を外すために、IAM Identity Center にて、ユーザーの削除を aws identitystore delete-user コマンドにて行いました。これにより受講者は環境へのログインができなくなりました。 次に、演習用アカウントの後片付けを行います。後片付けとしては、提供したAWSアカウントを閉鎖するのがもっとも確実な方法ですが、AWS Organizations の制限として、「 30 日以内に閉鎖できるアカウントの数」が「組織内のメンバーアカウントの 10% 」となっており、すべてのアカウントを閉鎖するには何ヶ月もの時間が必要で現実的ではありません。加えて、今回の講座は今後も実施する予定があるため、再利用のためにアカウントは残しつつ、費用がかからないようにアカウント内の全てのリソースを削除する方式をとりました。リソースの全削除にはソリューションアーキテクトにご紹介頂いた aws-nuke という OSS を利用しました。aws-nuke はコマンド一つで対象のAWSアカウントに存在するリソースを全て削除することができる非常に強力なツールです。今回はこちらを利用して演習で利用したすべての子アカウントのリソースを全て削除し、次回以降も再利用可能な状態で保持しています。 aws-nuke実行の具体的手順 以降は aws-nuke を利用するために具体的に実施した手順となります。 作業ユーザーに各アカウントの Administrator 権限を付与する 全アカウントにアクセスするための .aws/config を作成する すべての削除対象のアカウントにアカウントエイリアスを設定する aws-nuke で使用する nuke-config.yaml を作成する SCP を修正し ec2:DescribeRegions を実行できるようにする aws-nuke を実行し、全ての演習アカウントの全てのリソースを削除する それぞれの手順についてより詳細に説明していきます。 1. 作業ユーザーに各アカウントの Administrator 権限を付与する 各アカウントで削除を行える権限として Administrator 権限を付与しました。IAM Identity Center のユーザーに対して、Administrator 権限を設定した許可セットを作成し、 aws sso-admin create-account-assignment コマンドにてすべての演習アカウントへの権限付与を実施しました。このとき、セッション時間も 12 時間などに長めに設定しておくと aws-nuke 実行時にセッションが切れず安心なので設定しておきましょう。 2. 全アカウントにアクセスするための .aws/config を作成する aws-nuke を利用するためには AWS Profile の指定が必要です。各アカウントの Profile をそれぞれ下記のように作成し、aws sso login を実施するのみで全アカウントにアクセスできるように設定しました。 [profile lecture-practical-ai-engineering-weblab-XXXX-admin] sso_session = lecture-ai-engineering-weblab sso_account_id = xxxxxxxxxxxx sso_role_name = AdministratorAccess region = us-east-1 output = json 3. すべての削除対象のアカウントにアカウントエイリアスを設定する aws-nuke を利用するためには対象のアカウントにアカウントエイリアスが設定されていることが必須要件となっていました。そこで、先ほど作成した Profileと aws iam create-account-alias コマンドを利用して、すべてのアカウントにエイリアスを設定しました。 4. aws-nuke で使用する nuke-config.yaml を作成する aws-nuke は実行時に config ファイルを必ず指定し、対象のアカウントが削除許可のものかどうか、削除対象のリソースは何かなどを確認した上で実行する仕組みになっています。今回は下記のように config を作成しています。 regions: - all blocklist: - "XXXXXXXXXXXX" # lecture-practical-ai-engineering-weblab presets: common: filters: IAMRole: - "OrganizationAccountAccessRole" IAMRolePolicyAttachment: - "OrganizationAccountAccessRole → AdministratorAccess" resource-types: includes: - APIGatewayAPIKeyLister - APIGatewayAPIKey ... accounts: XXXXXXXXXXXX: # 0000 presets: - common XXXXXXXXXXXX: # 0001 presets: - common ... bypass-alias-check-accounts: - XXXXXXXXXXX - XXXXXXXXXXX ... それぞれについてポイントを説明すると、 regions については今回 SCP 側で特に制限を設定しなかったので all を指定しています。削除の作業時間を考えると、次回以降は SCP にて region を制限し、対象を限定する形に改善を検討しています。 presets として、IAM Identity Center で作成される OrganizationAccountAccessRole と OrganizationAccountAccessRole → AdministratorAccess の PolicyAttachment を除外する設定を作成しています。これを除外しないと、IAM Identity Center 経由でのログイン等ができなくなってしまうので必ず filters で除外するようにしましょう。各アカウントの filters の設定を適用するために presets として定義し、各アカウント全てに反映されるように accounts の指定で presets: [common] を設定しています。 resource-types については数が多いので省略しますが、今回 SCP で除外したサービス以外の全てを含むように記載しました。 bypass-alias-check-accounts に全ての対象のアカウントを記載しています。これは aws-nuke の実行時に確認プロンプトを skip するための設定で、今回はスクリプトにて大量のアカウントに対する自動実行を行うために設定をしています。 5. SCP を修正し ec2:DescribeRegions を実行できるようにする aws-nuke 実行時に、 ec2:DescribeRegions の権限が必要なため ec2:* を全て拒否していた SCP を修正する必要がありました。 6. aws-nuke を実行し、全ての演習アカウントの全てのリソースを削除する いよいよ削除の実行ですが、単体のアカウントに対して実行する場合は下記のようになります。 $ ./aws-nuke nuke -c config/nuke-config.yaml --profile lecture-practical-ai-engineering-weblab-XXXX-admin --no-alias-check --no-prompt --no-dry-run ここで --no-alias-check --no-prompt --no-dry-run は確認なしで削除を実行するオプションとなるため、利用の際には十分に注意して実行する必要があります。aws-nuke には事故を起こさないためのいくつもの機能が備わっていますが、さらなる安全のため実行時の端末側の aws config は削除対象のアカウントのみしか設定されていない状態にして作業を実施しました。 実行時間ですが、削除リソースがない場合は大体 1 ~ 2 分、削除リソースがある場合は 5 ~ 7 分程度の時間が実績としてかかりました。 大規模並列実行 今回は大量のアカウントに対して aws-nuke を実行する必要があるため、ローカル環境内で並列実行することにしました。aws-nuke 自体は大きくリソースを使用するものではないので、筆者の MacBook Pro では 12 並列にしても大きな問題なく実行できました。もし大量に実施する際はご参考いただければと思います。 実際に使用したスクリプトはこちらになります。 #!/bin/bash START=0 END=1424 N_PARALLEL=12 # 並列数をここで指定 TOTAL=$((END - START + 1)) CHUNK_SIZE=$((TOTAL / N_PARALLEL)) for i in $(seq 0 $((N_PARALLEL - 1))); do RANGE_START=$((START + i * CHUNK_SIZE)) if [ "$i" -eq $((N_PARALLEL - 1)) ]; then RANGE_END=$END else RANGE_END=$((RANGE_START + CHUNK_SIZE - 1)) fi echo "並列処理 $((i+1)): ${RANGE_START} ~ ${RANGE_END}" ( for ACCOUNT_NO in $(seq $RANGE_START $RANGE_END); do ACCOUNT_NAME=$(printf "%04d\n" ${ACCOUNT_NO}) echo ./aws-nuke nuke -c config/nuke-config.yaml --profile lecture-practical-ai-engineering-weblab-${ACCOUNT_NAME}-admin --no-alias-check --no-prompt --no-dry-run # ▼処理を実行し、失敗したらログに記録 if ! time ./aws-nuke nuke -c config/nuke-config.yaml --profile lecture-practical-ai-engineering-weblab-${ACCOUNT_NAME}-admin --no-alias-check --no-prompt --no-dry-run; then echo "FAILED: ${ACCOUNT_NO}" >> "error_${i}.log" fi done ) > "output_${i}.log" 2>&1 & done wait echo "全ての並列処理が終了しました" 失敗パターンと対処法 上記実行後、2 つのパターンで削除が失敗したものがあるため、その対処についても記載しておきます。 AWS CloudFormation (Cfn) 実行用 Role が先に削除されてしまって Stack が削除できなくなりエラーとなる (ValidationError: Role arn:aws:iam::xxxxx:role/cdk-xxxxxxxxx-cfn-exec-role-xxxxxxxxxx-us-east-1 is invalid or cannot be assumed) → 手動で Role 作成して Stack を削除する必要がある 削除保護が有効なリソースがありエラーとなる (deletion protection is activated) → ユーザーが最終課題で作成したリソースに Amazon Cognito が設定されており、手動で解除する必要があった 以上の手順を踏むことで、全ての演習用アカウントから全てのリソースを削除することができました。削除後はコストエクスプローラにて、対象のアカウントで費用が発生していないことを持って最終確認としました。 次回以降の実施に向けて 今回は初回かつ短期間での準備であったため、コストやセキュリティ、構築時のリスクを低減できるようにシンプルかつ不確実性の低い構成を選択しました。結果として大きな問題なく短期間かつ低コストで環境を提供することができましたが、利用できるサービスを一部制限するなどの安全に倒した形での運用となりました。次回以降では、管理側の仕組み(コストアラート/自動停止等のガードレールの構築など)をより充実させることでサービス制限の緩和などに取り組みたいと考えています。 なお、本対応を実施後に AWS から Innovation Sandbox on AWS という一時的に利用するAWSアカウントを発行する仕組みのテンプレートが AWS solutions で公開されました。用意されたテンプレートを展開することで、AWSのサービスを組み合わせたソリューションを展開して特定の機能が利用ができる仕組みです。 Innovation Sandbox on AWS では、AWS アカウント管理者が一時利用 AWS アカウントの利用期間や金額条件等を設定し、利用者が申請して設定された条件の範囲ならばセルフサービスで AWS アカウントを一時利用できる仕組みを簡単に提供できるとのことです。このソリューションが我々の要件にマッチするかはまだ確認できていませんが、アカウントごとのコスト制限を設けられる点がとても魅力的なので、次回の実施の際はぜひ追加で検証してみたいと考えています。 まとめ 今回の東京大学松尾研究室でのデータサイエンス講座における AWS 環境を活用した大規模演習は、以下の点で大きな成果を上げました。 大規模クラウド環境の教育活用 1400 名もの参加者に対し、個別の AWS アカウントを提供することで、実践的なクラウド環境での学習機会を創出しました。従来の小規模・単発の講義とは異なり、多数の受講者が同時にクラウドリソースにアクセスできる環境を構築したことは、教育におけるクラウド活用の新たなモデルケースとなりました。 最新技術の実践的学習 サーバレスアーキテクチャを中心とした最新のクラウド技術と生成AIの組み合わせにより、次世代のアプリケーション開発手法を体験的に学習する機会を提供しました。特に、Amazon Bedrock を活用したチャットボット開発は、AI とクラウドの融合を実践的に理解する貴重な経験となりました。 大規模ユーザー管理の実践 IAM Identity Center と AWS Organizations を活用した大規模ユーザー管理の実践例を確立しました。この知見は、今後の同様の教育プログラムや大規模クラウド環境の管理に応用可能です。 セキュリティとコスト管理の両立 適切な権限設定とサーバレスアーキテクチャの採用により、セキュリティリスクとコスト管理を両立させることができました。特に、不要なサービスへのアクセス制限などの工夫は、教育環境におけるクラウド利用の重要なノウハウとなりました。 理論と実践の融合 講義と演習を組み合わせることで、クラウドとAIの理論的理解と実践的スキルの両方を習得できる学習体験を提供しました。リアルタイムとオンデマンドの両方の受講形態を用意したことで、多様な学習スタイルに対応できました。 今回の取り組みでは、従来の教室内での限定的な演習環境から脱却し、実際のクラウド環境で最新技術に触れる機会を提供することができました。このような理論と実践を融合させた学習体験が、受講者のスキル習得に大きく貢献し、将来の IT 人材育成に向けた重要なステップとなることを期待します。 今後の課題は、さらに多様なクラウドサービスを取り入れたカリキュラムの開発や、より効率的な環境構築・管理手法の確立が挙げられます。このような大規模クラウド環境を活用した教育プログラムは、次世代のAIエンジニア育成において重要な役割を果たせると考えられます。 松尾・岩澤研究室では、今回ご紹介したAIエンジニアリング実践講座だけでなく、様々な先進的な講座を開講しています。年間を通じて受講生を募集しており、2014 年から提供するAI講座の累計受講者数が 75,000 人を突破しました（2025年6月時点）。各講座はオンライン講義が中心なので、全国どこからでも参加可能です。大学生・大学院生だけでなく、中学生・高校生・高専生・専門学校生・短大生でも無料で参加できます。また、社会人の方が募集できる講座も用意しております。現在募集中の講座一覧は こちら となりますので、ぜひご確認ください。 執筆者 Hideaki Masuda 増田 英晃 東京大学大学院 工学系研究科 松尾・岩澤研究室 Saori Yagyu 柳生 さおり アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター教育事業本部 アカウントエグゼクティブ Naoya Funazashi 篙 直矢 アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター技術統括本部 ソリューションアーキテクト Kei Sasaki 佐々木 啓 アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター技術統括本部 シニアソリューションアーキテクト

2025 年 5 月 23 日に開催された「第20回情報危機管理コンテスト」決勝戦にて AWS 賞を受賞したチーム C01UMBA（コルンバ）の皆様にインタビューを行いました。 今回の情報危機管理コンテストでは、AWS 上に構築されたシステムを舞台として実践的なセキュリティインシデント対応が行われました。C01UMBA は名古屋工業大学の学生 4 名で構成された新人中心のチームでありながら、Amazon S3 や Amazon Athena を駆使し、優れたチームワークと的確な対応で AWS 賞を受賞しました。 C01UMBA の皆様から情報危機管理コンテストへの参加の経緯、研究室を選択したきっかけやコンテストへの準備など、これまでの活動についてお聞きすることができました。インタビュー記事を通してコンテストで得た学び、これからのクラウドやご自身のキャリアイメージなどをお伝え出来ればと思います。 (写真左から) C01UMBA 名古屋工業大学 情報工学科 齋藤・掛井研究室 情報工学科 学部 4 年 滝本 那奈 氏 情報工学科 学部 4 年 平山 洪 氏 情報工学科 学部 4 年 奥井 真二郎 氏 情報工学科 修士 1 年 東 政澄 氏（リーダー） コンテストに参加したきっかけ AWS : 今回の危機管理コンテストに参加するきっかけをお聞かせいただけますか。 滝本 : 研究室で代々参加しているコンテストだったので、その流れでというのと、自分自身もネットワークの知識が弱かったりしたので、勉強したいなという意識があったので参加しました。 平山 : 私も同じく、勉強の糧にしたかったというのと、実務経験もほとんどない状態でしたので、監視とか、ログの異常とか、どうやって見分けられるようになりたいかということも考えつつ参加しました。 奥井 : 研究室で出るっていうのもあって、それがきっかけではあるんですけど、学部 3 年の時に少しだけ就職活動したのですが「挑戦したこと」を聞かれた際、自分にはそのような経験が少ないことに気づきました。この気づきをきっかけに、技術的なことも含めていろいろ挑戦したいと考え、コンテストに参加しました。 東 : 昨年参加し、このコンテストから得られる学びとして大きいものがいろいろありました。もう一度参加する機会があったので、それなら最後に参加して、知識を深めたいなと思い参加しました。 研究室選びのきっかけ AWS : 所属している研究室がコンテスト参加の一つのきっかけとのことですが。研究室をどのように選んだかお聞きできますでしょうか。 滝本 : 研究室配属の時期が 10 月で、色んな研究室に行ったり悩んでたんですけど、ちょうどその時期に選んだ研究室の教授がやっているセキュリティ系の授業があって、それが面白かったので、ここにしようと思いました。 平山 : 研究室としてセキュリティをメインにやっているところっていうのがここの研究室しかなくて、講義で学ぶ上でいろいろなことを実務的にやれると感じたのと、侵入検知や、ブロックチェーンを含めた様々なセキュリティのことを経験することが他の研究室にはない特徴だったので、この研究室に入ろうとしました。 奥井 : 名古屋工業大学のセキュリティやってる研究室がここしかなくて、学部時代に応用情報とか資格試験に力を入れていて、応用情報は問題が選択出来るのですが、セキュリティだけは必須だったことから、セキュリティは重要だと思う様になり、それから興味を持ちました。 東 : 中学高校とセキュリティに興味があり、大学の学部を選んだ理由も、情報工学に行けばセキュリティを学べるからでした。ずっとセキュリティがやりたくて、ここに来たという感じです。セキュリティをやっていったら、社会に携われる、貢献できると思って選びました。 コンテストへの取り組み AWS : 研究室でのコンテストに対する取り組みを教えていただけますでしょうか。 東 : チーム編成の話からすると、去年私は同学年の他のメンバーと参加して、今回は後輩 3 人と参加という形です。このチームは、新人がどれだけの高みを目指せるかという、挑戦のチームという感じです。 平山 : もともと 4 人の学部 4 年生の人がいて、それを 2 人ずつで分けるか、それとも 3 と 1 で分けるかで考えていて。優勝を狙う為に、3 と 1 に分けて、上手いこと育成も含めて兼ねて、次に入った 学部 4 年生の育成がやりやすくなると考えて、結果的に今のチームの編成になりました。 AWS : コンテストでは「電話対応」というリーダーシップと技術的な判断をマルチタスクに求められる役割があると伺っています。今回、電話対応は東さんが担当されていましたが、役割分担は他のメンバーから見てどうでしたか。 平山 : 結構適切だったと思います。というのも二次予選で私が電話対応をしていましたが、結構パンクしてしまったので、それよりも規模が大きい決勝の状況になると、テンパっちゃって、何もできなくなってしまう可能性が高かったので、やはり、任せて正解だったと思います。 滝本 : 予選や二次予選の段階でもコマンドラインを覚えても使いきれない状況で、悩むことが多くあった。東さんに適切にポジション振り分けてもらい感謝しています。 東 : 今回のメンバーは文書作成、技術担当でそれぞれ強みがあることが分かったため、シングルタスクに持ち込めばいけると判断したため、決勝戦では僕が司令塔という立ち回りで進めました。 技術的な準備 AWS : 研究室のコンテストに対する取り組み、テクニカルな部分での対策したというエピソードはありますでしょうか。 滝本 : 研究室に代々受け継がれてるコマンドライン操作やコマンドをまとめたシートがあったり、あとは実際に攻撃して、それに対応するっていう環境が整えられてたりしていました。先輩方もその環境を使って、学部 4 年生の練習するのに結構な時間付き合ってくださっていました。 東 : 1 週間に 2 回やれればいいかもぐらいですね。合計で 4 回程度練習して本番に挑みました。 奥井 : 個人的に練習した後に課題と思ったのが、原因の特定です。絶対的な証拠を見つけることさえできれば、後は調べたりなんなりできる。チートシートに書いてあるコマンドの意味を理解することや、複数あるオプションの意味を調べたり、状況によってどんなコマンドを使うのかを調べて、勉強していました。 クラウドへの所感 AWS : 今回初参加の方は、初めてクラウドに触られたということでしたが。クラウドに感じる可能性があれば教えていただけないでしょうか。 平山 : S3 が今回題材に出されたというのもありますが、クラウドには様々なログが集積されて、データも大量に保存されているところが沢山あり、可能性という意味では、そういったログを全て確認できれば、インシデントが起きた時には楽になるとは感じました。 東 : 僕の中で S3 は倉庫のイメージがあって。S3 がログのストレージとして使われていますが、ログの中身を可視化して欲しい際に、他の AWS のサービスを利用することを考えて、これは良いと思い採用を検討したのが、Athena でした。 例えば、S3 が何でも出来るというのは良くないと思っていて。可視化をしようとした時に S3 を使った範囲内でちゃんと使いやすくしてる工夫が個人的には印象に残っていました。 奥井 : コンテストでは、(課題解決をする為に)その何かの機能を追加してくださいという問題だったんで、普通にオンプレミスでやってたら、簡単に機能を追加することは難しいのですが、クラウドでは気軽に機能を追加出来る。これはすごいと思っていました。ただ種類が多すぎて、時間内で自分たちだけで調べてというのには時間が掛かりました。 将来のキャリアイメージ AWS : 将来のキャリアイメージとして、将来やりたいことについて、お話をお聞きしたいと思います。 滝本 : 学部 3 年生の時に、学部で卒業しようと思っていました。本格的に就活をやってきたつもりだったんですけど、いろいろな企業を見ても、自分が何をやりたいか一番大事なところが全然見えてこなかった。そのような経験から大学院に進んで、もっといろいろなことを学んだり、今回のコンテストや大会に積極的に出て、視野を広げたい。専門性を磨きたいです。 平山 : 今はキャリアイメージは明確にないが、現在の研究室に配属になり、いろんなことをやりながら、まだ自分には経験というものが足りないという風に感じた。大学院に進んで、その後も資格を受けながら、色んな経験をこなしていくことによって、キャリアプランを探しています。 奥井 : 明確な目標としては、プロフェッショナルというか一つのことに誰にも負けない、自信を持って、自分にしか出来ないことを出来る人になりたいというのが、目標ではあります。 東 : いろいろな経験の中で二つ決まっていて、一つがセキュリティに関する仕事に携われること、もう一つが、人に携われること。今回の教える立場に立った中で、楽しいと思えたのが一つ、セキュリティに携わることも面白い。近い業種でいうと CSIRT かもしれない、顧客対応ができるキャリアを歩んでいけたら良いと思っている。技術的なところは大学の研究を通して学んでいければと考えている。人に携わるところはコミュニケーションを通じて伸ばしていければと考えています。 おわりに チーム C01UMBA の皆様、お忙しい中インタビューに快く対応いただきありがとうございました。 このブログは、2025 年 11 月時点の情報に基づいて ソリューションアーキテクト 深井 宣之 が執筆しました。

第 29 回サイバー犯罪に関する白浜シンポジウムにて開催された第 20 回情報危機管理コンテストに技術協賛として参加しました。   情報危機管理コンテストとは 情報危機管理コンテストは、2005 年から継続開催され、2025 年で 20 回を迎える歴史あるセキュリティコンテストです。 このコンテストでは、単なる技術力だけでなく、電話や電子メールによるリアルタイムな顧客対応の適切さが求められます。詳細な記載は省きますが、サーバへの外部侵入を含む多様な内容が含まれます。競技終了時に複数のトラブルへの対応状況を総合的に判断する仕組みとなっており、実際の対応を想定したシナリオが用意されています。限られた時間内での迅速かつ適切な判断力が要求され、個人の技術力だけでなく、チーム全体での連携と役割分担が重要な要素となっています。 参加チームが情報システム担当として、次々と発生するトラブル（システム障害や顧客・外部からの苦情など）に対して適切な対処を行い、問題解決能力を競うコンテストです。主に大学生・大学院生のチームが参加し、実践的なサイバーセキュリティ人材育成の場として業界から高く評価されています。 技術協賛 この度、AWS は技術協賛として参加し、シナリオ作成協力や参加者へのハンズオンの提供を行いました。また、決勝戦当日は AWS の問い合わせ窓口役として、現役のソリューションアーキテクト 2 名が現地で対応を行いました。   決勝戦 1 次・2 次予選を勝ち抜いた 8 チームが白浜シンポジウムの会場で決勝戦を行いました。 決勝戦の結果は公式サイトの 決勝戦について を参照ください。   AWS賞の授与 特に印象的なチームに対し AWS から AWS 賞を授与しています。本コンテストでは 名古屋工業大学 C01UMBA に授与しました。同チームは優れた技術力とチームワークを発揮し、決勝戦参加チームの中でも、特に実際の運用に近い発想を持っていました。   さいごに 第 20 回情報危機管理コンテストへの技術協賛参加を通じて、次世代のサイバーセキュリティ人材の成長を間近で見ることができました。参加チームの皆さんの真剣な取り組みと成長ぶりは非常に印象的で、日本の情報セキュリティ分野の未来に大きな希望を感じました。 このブログは、アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター ソリューションアーキテクト 深井宣之 が執筆しました。

※ この投稿はお客様に寄稿いただいた記事です。 ANA システムズ 株式会社について ANA システムズ 株式会社は、エアライン分野に精通した「IT のスペシャリスト集団」として、エアラインビジネスを中心としたシステム企画・開発、空港施設・インフラ展開から稼働後のシステム運用、ANA グループ各社の DX 推進支援、地域創生への取り組みなど、幅広く品質の高いトータルサービスを提供しています。 1. はじめに プロジェクトチームには、様々な経験や背景を持つメンバーが集まります。当然、個々人のスキルセットは様々です。一方で、入社時の研修で学ぶ内容が、現場で求められる技術のすべてをカバーしているわけではありません。配属されて初めて触れるプログラミング言語やフレームワークに直面することも多いでしょう。加えて、プロジェクトには必ず「納期」が存在し、事前に十分な準備を行うための時間を確保することは難しいです。 本ブログでは、プログラミング経験の浅い担当者がある開発プロジェクトを「どのようにして短期間でやり遂げたのか」に焦点を当ててご紹介します。 2. 機能実装における課題 本システムのアーキテクチャは以下の通りとなっています。 図 1：アプリケーションのアーキテクチャ 機能実装にあたり、AWS Lambda における利用率が高く、各種ライブラリを扱うことから、開発言語として Python を選択しました。しかし、この選択には以下の 2 つの課題がありました。 担当者のスキルセット 実装の担当者は Python での開発経験がなく、コーディング経験自体も新人研修で Java に触れたのみという状況でした。そのため、扱う技術に対するスキルセットとの間に大きなギャップがありました。 素早い本番稼働が求めらている プロジェクトは、1 スプリントを 1 週間とするアジャイル形式で進められました。ユーザーから早期導入の大きな期待もあり、開発初期のわずかな遅れが、全体のスケジュール遅延やスコープ変更に影響する状況であったため、Python 未経験の担当者にとっては、期待に応えるために大きなプレッシャーもありました。 限られた開発期間の中で、スキルセットのギャップを埋める時間を確保するのは困難です。この状況を打開するため、不足する知識と技術を補う手段として、生成 AI をコーディングに活用することにしました。 3. 生成 AI を活用したコーディング手法 本開発におけるコーディングには、基盤モデルとして Anthropic の「Claude3 Haiku」を採用しました。実際に活用した内容を 2 つご紹介します。 対話形式のコーディング まず開発の起点となるコードの土台を得るために、システムのアーキテクチャと実現したい機能要件をプロンプトとして AI に入力しました。 図 2 : 生成 AI へのインプット 図 3 : 生成 AI からのアウトプット (抜粋) そして生成されたコードを基に、細部の実装を進めました。具体的には、「このコードをもっとシンプルに記述できますか？」といった改善点を AI に質問し、得られた回答を元に修正を重ねるという対話形式で、コード全体の完成度を高めていきました。 エラー内容の解析 エラー発生時の原因特定も、生成AIを活用して大幅に効率化しました。対象コードとエラーメッセージをAIに入力するだけで、問題の根本原因を特定することができました。実際に「AWS IAMの権限不足」のエラーが発生した際も、どこのどのような処理でエラーとなっているのかを解説してくれるため、必要な権限と設定箇所を早急に特定でき、迅速な問題解決につながりました。 4. 効果・利点 実際に生成 AI と共にコーディングを行う中で得られた、効果と利点をお伝えします。 未経験者の開発を強力にサポート まず最大の利点は、プログラミング経験の浅い担当者でも、短期間で実装を完遂できたことです。通常、未経験者が新しい言語で開発する際は「何から手をつければよいか」という最初のステップでつまずきがちです。しかし、生成 AI が開発の土台となるコードの雛形を提示してくれるため、この初動のハードルを大きく下げることができました。 また、従来はエラー内容の分析と調査に多くの時間が掛かっていました。このプロセスを AI に任せることで、問題解決の効率を大幅に向上させることができました。 それにより、未経験者でも 1 週間のスプリントでコーディングを行うことができました。 仕様変更やアーキテクチャ変更への柔軟な対応力 開発途中で発生した、アーキテクチャの変更を伴う緊急の改修作業においても、生成 AI の能力を感じられました。新しいアーキテクチャの構想を伝えるだけで、AI が変更に沿ったロジックを即座に提案してくれるため、急な仕様変更にも迅速かつ柔軟に対応することができました。 5. AI とのコーディングを通した自己成長 開発が始まったばかりの頃は、Python に関する知識や経験が全くなかったため、コーディングからデバッグに至るまで、開発プロセスのほぼすべてを AI に頼ってしまっていました。AI にコードの生成を依頼し、エラー発生時にはその解決策を AI に求めるという方法でしか開発を進めることができなかったのです。 しかし開発を進めていく中で、AI に何度も繰り返しコードレビューを依頼し、問題箇所の特定を繰り返すうちに、Python コードを読み解く能力が徐々に身につきました。徐々に AI との関わり方に変化が生じてきたのです。AI に全てを任せるのではなく、自身で問題の原因を検討したり、細かな修正を施したりするなど、プログラミングスキルを向上させることができました。それと同時に AI にはより具体的で詳細な指示ができるようになったことで、協働して解決策を見つけ出せるようになりました。AI がプログラミングの先生からパートナーへと変化したのです。 AI との連携はさらに効率的になり、コーディング速度だけでなく、エラー解決の効率も向上させることができました。結果として、緊急の改修作業が必要となった際にも、わずか 2 日半で Lambda コードのコーディングとテストを含めたシステムの改修を完了することができ、プロジェクトスケジュールへの影響を最小限に抑えられました。AI との関わり方、プログラミングスキル向上という2つの側面から自身の成長へとつなげることができました。 6. 成功のポイントと教訓 今回の開発を通じて、生成 AI を活用する上での重要なポイントと、今後の課題となる教訓が見えてきました。 やってみて分かった AI の能力を最大限に引き出す「対話力」の重要性 生成 AI は優れたコードを生成するものの、その回答を鵜呑みにするだけでは問題解決に至らない場面がありました。例えば、AI の回答から原因を絞り込めず、同じエラーについて何度も質問を繰り返すことがありました。また 1 機能としてコード自体は正しくても、他の機能と連携するための設定など、コード以外に起因する問題には気づくことができません。 この経験から、以下の2つの能力が重要だと分かりました。 読解・分析能力： AI の回答を元に、根本原因を自ら推測し、検証する力。 背景説明能力： 開発の背景やシステム構成、制約条件といった「コンテキスト」を正確に AI へ伝え、問題解決の精度を高める力。 改めて実感した AI 開発における「プロンプト設計」の重要性 本番リリース後、想定していたパフォーマンスが出ず、緊急の改修作業が発生するという事態がありました。原因は、開発環境と本番環境におけるデータ量の差異を考慮した設計・コーディングができていなかったことです。 このことから、AI はあくまで指示された範囲内で最適なコードを生成するものであり、実データ量のような非機能要件や環境特有の事情までは考慮できないという限界を学びました。 逆説的に言えば、もしプロンプトの段階で「本番環境では毎分〇〇件のデータが流れる」といった具体的な条件を細かく指定していれば、AI はより堅牢な設計を提案してくれたかもしれません。AI に「何を」「どこまで」考慮させるか、といった設計も開発者の重要なスキルであることが分かりました。 7. 結論 今回、私たちは「Python 未経験」「限られた開発期間」という状況の中で、生成 AI を活用することで、無事にスプリント内に機能をリリースすることができました。スキルや時間がない状況でも、新しい技術を駆使して「動くもの」を創り上げられたことは、大きな自信と学びにつながりました。 振り返ると、仕様書などのドキュメント作成や単体テストコードの自動生成など、AI を活用できそうな領域はコーディング以外にもあります。そういった作業は AI に任せ、エンジニアは顧客との要件調整といった創造性が必要な業務に注力することで、開発プロセスのさらなる効率化が図れるはずです。 また今回はプロジェクトの時期の都合上、Amazon Q Developer の利用が出来ませんでした。今年から日本語にも対応し始めたので、導入のハードルも大きく下がりました。今後のプロジェクトでは、より開発ライフサイクルに統合された AI アシスタントとして、その能力を検証していきたいと考えています。 執筆者 ANA システムズ株式会社 CXマネジメント部 カスタマーコミュニケーションチーム 中山 紗椰果 アジャイル開発エンジニア ANA システムズ株式会社 CXマネジメント部 カスタマーコミュニケーションチーム 都留 昌彦 アジャイル開発エンジニア、PMI PMP(R) 会社情報 会社名 : ANA システムズ 株式会社 URL : https://www.anasystems.co.jp/

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 ついに 12 月 1 日から 5 日で re:Invent 2025 が開催されます。私もデモ展示員として、現地ラスベガスに行く予定なので、ぜひ現地に行かれる方は Builders Fair で展示している私のブースにお越しください。そのブースでは、生成 AI を活用したロボットの自動走行デモを今絶賛開発中で、間に合わせるために必死に頑張っています。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年11月10日週の主要なアップデート 11/10(月) Amazon SageMaker Unified Studio がカタログ通知のサポートを追加 Amazon SageMaker Unified Studio でデータカタログの通知機能が利用できるようになりました。データセットの公開や更新、アクセス承認などの重要な変更をリアルタイムで受け取れます。プロジェクトホームページの「ベル」アイコンから通知を確認でき、通知センターでは全ての通知を一覧表示して必要に応じてフィルタリングも可能です。データチーム間のコラボレーションがスムーズになり、重要な更新を見逃すリスクが大幅に減ります。詳細は こちらのドキュメントをご参照ください。 AWS Control Tower がアカウントの自動登録をサポート AWS Control Tower で、アカウントを組織単位 (OU) に移動するだけで自動的にガバナンス管理下に登録できる機能が追加されました。従来は手動でのアカウント更新や OU の再登録が必要でしたが、この機能により大幅に簡素化されます。アカウント作成後に適切な OU に移動するだけで、ベストプラクティス設定やコントロールが自動適用されるため、管理者の運用負荷が軽減されます。 MSK Express ブローカーが追加コストなしでインテリジェントリバランシングをサポート、アクション不要 Amazon MSK の Express brokers で インテリジェントリバランシング が無料提供開始しました。Kafka クラスターのスケーリング時に自動でパーティションバランシングを実行し、Standard brokers と比較して最大 180 倍高速に処理できます。これまで手動や外部ツールで管理していたパーティション操作が不要になり、クラスター性能を最大化できます。新規 MSK Provisioned clusters では追加設定なしで利用可能です。詳細は こちらのドキュメントをご参照ください。 11/11(火) Amazon EC2 M8a インスタンスが追加リージョンで利用可能に Amazon EC2 M8a インスタンスがバージニア北部と東京リージョンで利用開始されました。AMD の第 5 世代 EPYC プロセッサを搭載し、従来の M7a と比較して最大 30 % のパフォーマンス向上と 19 % の価格性能比改善を実現しています。メモリ帯域幅も 45 % 向上したため、レイテンシが重要なアプリケーションでも快適に動作します。金融アプリケーション、ゲーム、レンダリング、アプリケーションサーバーなどの高性能を必要とするワークロードに最適で、12 種類のサイズから選択可能です。 Mountpoint for Amazon S3 が Amazon Linux 2023 に含まれるようになりました Amazon Linux 2023 で Mountpoint for Amazon S3 が標準提供開始されました。これまで GitHub からパッケージをダウンロードして手動インストールする必要がありましたが、今後は1つのコマンドで簡単にインストール・アップデートが可能です。S3 バケットをローカルファイルシステムのようにマウントできるため、既存のアプリケーションを変更せずに S3 のデータにアクセスできます。サーバー上でのデータ処理やバックアップ作業が大幅に効率化されるでしょう。 Amazon CloudWatch Composite Alarms にしきい値ベースのアラート機能を追加 Amazon CloudWatch Composite Alarms で、しきい値ベースのアラート機能が追加されました。従来は個々のアラームごとに通知を受け取っていましたが、今回のアップデートで複数のリソースのうち一定数に問題が発生した場合にのみ通知を受け取れるようになりました。例えば 4 つのストレージボリュームのうち最低 2 つで容量不足が発生した場合や、クラスター内の 50 % のホストで CPU 使用率が高くなった場合に通知するといった柔軟な設定が可能です。これにより軽微な問題による不要なアラートを削減し、本当に重要な問題に集中できます。詳細は こちらのドキュメントをご参照ください。 11/12(水) Amazon EC2 F2 インスタンスが 4 つの追加 AWS リージョンで一般提供開始 Amazon EC2 F2 インスタンスが新たにフランクフルト、東京、ソウル、カナダ中部の 4 リージョンで利用開始となりました。F2 インスタンスは FPGA 搭載の第二世代で、従来の F1 インスタンスと比較して 3 倍の vCPU、2 倍のメモリを提供します。遺伝学研究やマルチメディア処理、ビッグデータ解析などの高速計算処理が必要な用途で威力を発揮します。これにより計 8 リージョンでの利用が可能となり、より多くの地域で FPGA の高性能を活用できるようになりました。 AWS Builder Center で Spaces が利用可能になりました AWS Builder Center に Spaces という新しいコミュニティ機能が登場しました。AWS に関する特定のトピックやユースケースについて、他のエンジニアとグループを作成して情報交換できるツールです。Public、Private、招待制の 3 つのスペースタイプから選択でき、投稿やコメント、検索機能を通じて知識共有や課題解決の議論が可能になります。AWS の学習で困った時に仲間を見つけたり、ベストプラクティスを共有したりする場として活用できそうです。 セキュリティインシデント対応のコミュニケーション設定の発表 AWS Security Incident Response で通知設定のカスタマイズ機能が追加されました。これまでは全メンバーが全ての通知を受信していましたが、今回のアップデートで役割に応じて必要な通知のみを選択できるようになりました。例えば管理者はケース変更通知を、一般メンバーは組織のお知らせのみを受け取るといった設定が可能です。不要な通知が減ることで重要な情報に集中でき、作業効率が向上します。追加費用なしで Security Incident Response コンソールから簡単に設定できます。 11/13(木) Amazon Kinesis Video Streams WebRTC マルチビューワー が一般提供開始 Amazon Kinesis Video Streams で WebRTC Multi-Viewer 機能が提供開始されました。これまで 1 対 1 だったリアルタイム動画配信が、最大 3 人の同時視聴者に対応しました。デバイスの負荷を増やすことなく、セキュリティカメラや IoT デバイスからの映像を複数人で共有でき、音声会話も可能です。家庭のセキュリティシステムでの家族間共有や、リモート監視システムでの複数オペレーター対応など、幅広い用途で活用できます。詳細は こちらのガイドをご参照ください。 Amazon Connect がマネージャーによるエージェントパフォーマンス評価の完了に関するメトリクスを提供開始 Amazon Connect でエージェントのパフォーマンス評価完了状況を測定するメトリクスが新たに提供開始されました。マネージャーは「月 5 回の評価」などの社内ポリシーや規制要件への準拠状況をリアルタイムで監視できるようになります。さらに、異なるマネージャー間の評価スコアパターンを分析することで、評価の一貫性と精度の向上も図れます。詳細は こちらのドキュメントをご参照ください。 AWS IoT Core が Amazon Sidewalk 対応デバイス向けの位置解決機能を追加 AWS IoT Core Device Location が Amazon Sidewalk デバイスの位置解決機能を追加しました。従来は GPS ハードウェアが必要でしたが、WiFi アクセスポイントや Bluetooth Low Energy データを活用して低電力デバイスの位置を特定できるようになります。これによりアセット追跡やジオフェンシングアプリケーションをより効率的に構築可能です。Amazon Sidewalk は Echo や Ring デバイスを通じた安全なコミュニティネットワークで、IoT デバイスにクラウド接続を提供します。バージニア北部リージョンで利用開始され、米国内でのみ Amazon Sidewalk ネットワークが使用できます。詳細は こちらのドキュメントをご参照ください。 11/14(金) AWS Lambda が Rust のサポートを追加 AWS Lambda で Rust が正式サポートされました。これまで実験的な扱いだった Rust が、本格的な本番環境での利用が可能になります。Rust は高性能でメモリ効率が良く、コンパイル時の安全性チェックが特徴的な言語です。パフォーマンスを重視するサーバーレスアプリケーションの開発に最適で、従来の言語では難しかった高速処理が求められるワークロードでも安心して利用できます。詳細は こちらの Blog 記事をご参照ください。 Amazon SageMaker Catalog が Amazon S3 への読み取りおよび書き込みアクセスをサポート Amazon SageMaker Catalog が Amazon S3 への読み書きアクセスに対応しました。これまでデータの検索や共有に制限がありましたが、今回のアップデートでデータサイエンティストが非構造化データを簡単に検索し、構造化データと組み合わせて処理できるようになりました。処理結果を S3 に保存して他チームと自動共有することも可能です。データ提供者は読み取り専用または読み書き両方のアクセス権限を選択でき、セキュリティを保ちながら効率的なデータ分析が実現できます。詳細は こちらのドキュメントをご参照ください。 AWS IoT サービスが VPC エンドポイントと IPv6 接続のサポートを拡張 AWS IoT Core、AWS IoT Device Management、AWS IoT Device Defender で VPC エンドポイントと IPv6 サポートが拡張されました。AWS PrivateLink を使って VPC エンドポイントを設定することで、IoT デバイスからの通信がパブリックインターネットを経由せずプライベートネットワーク内で完結できるようになり、セキュリティが大幅に向上します。また IPv6 サポートにより既存の IPv4 環境と併用しながら最新のネットワーク要件にも対応可能です。詳細は こちらのドキュメントをご参照ください。 実は今週末、趣味でやっているパデルのシニア日本代表を決める試合があり、出場予定です。reInvent の準備も忙しいのですが、体づくりもしっかりして万全の状態で今月乗り切りたいです。よい結果になることを期待してください。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲料業界やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。