この記事は 2025 年 2 月 13 日に公開された Using Open Job Description to Customize Submitter Workflows  を翻訳したものです。 レンダーファームへのジョブの定義と送信プロセスを効率化したいアーティストやテクニカルディレクター (TD) の方はいらっしゃいますか？このブログでは、Open Job Description (OpenJD) を使用して AWS Deadline Cloud の統合サブミッターをカスタマイズする方法について説明し、最後にゼロから作成したカスタムサブミッターのコードサンプルを紹介します。 OpenJD は、ユーザーがレンダーファームに送信するジョブを定義できるオープンな仕様です。ジョブの送信はコンテンツ作成ワークフローの終盤で行われ、OpenJD は TD やテクニカルアーティストがワークフローの中断を最小限に抑えるために、サブミッターワークフローをカスタマイズする機会を提供します。サブミッターのカスタマイズにより、 AWS Deadline Cloud にジョブを送信するユーザーの時間と労力を節約できます。 図 A は、Deadline Cloud に統合された Maya 2024 サブミッターを示しています。これは Maya ジョブを送信するための基本的な機能ユーザーに提供します。 図 A: Maya 2024 サブミッターに統合された Deadline Cloud カスタマイズのユースケース FuzzyPixel のカスタム Maya サブミッターは、FuzzyPixel チームによって開発されました。私たちは、AWS の機能がリリースされる前に、設計、プロトタイプ作成、テストを行うために、実際のプロダクションに取り組んでいる AWS チームです。このブログでは、最新のプロダクションで開発したカスタマイズについて説明します。 ユースケースは以下の通りです: プロジェクトパスと出力パスの更新 ：プロジェクトパスと出力パスが開いているシーンに基づいて自動的に設定されることで、ユーザーの時間を節約し、認知的負荷を軽減します。 画像解像度 ：ジョブの最終レンダリング解像度が 8K の場合があります。テストレンダリング用に解像度を下げることができれば、時間を節約しレンダリングコストを削減できます。 GUI の再構成 ：統合されたサブミッターは、4 つの異なるタブを使用して GUI コントロールを整理します。頻繁に使用するコントロールを RenderSettings タブの下に配置することで、ジョブ送信ワークフローを効率化できます。 フリートのカスタム属性 ：ユーザーがジョブをスポットインスタンスとオンデマンドインスタンスのどちらで実行するかを選択できるようになると、長時間のレンダリングでもジョブの中断を回避できます。 レンダーレイヤーコントロール ：サブミッターでレンダーレイヤーを明示的に制御できるようにすることで、レンダーレイヤーの可視性とフレーム範囲をより詳細に制御できます。 これら全てのユースケース要件を、OpenJD、AWS Deadline Cloud API、Maya API、PySide2、Python スクリプトを使用して実現しました。最初のユースケースを見ていく前に、OpenJD について詳しく見ていきましょう。 前提条件 続行する前に、以下の前提条件をすべて満たす必要があります。 Windows ワークステーション Maya 2024 と AWS Deadline Cloud Submitter のインストール Maya 2024 には独自の料金体系があり、これはAWS とは関連していないことに注意してください。 ファーム、フリート、キュー、および Deadline Cloud Monitor 、そしてファーム用に作成されたプロファイル Python-3.10.8 のインストール (Maya 2024 の Python バージョンと一致させるため、このバージョンの使用を推奨します) https://www.python.org/downloads/ このバージョンの Python に deadline と GUI の依存関係を pip でインストール 例：”C:\Program Files\Python-3.10.8\PCBuild\amd64\python.exe”  -m pip install deadline[gui] FuzzyPixel カスタム Maya サブミッター のダウンロード 注意: このブログで提供されているすべての例は、Windows ワークステーションでのみ実行できます。 ジョブバンドルで OpenJD を見る Deadline Cloud 統合サブミッターの画像 (図 A) では、右下に Export bundle ボタンがあります。ジョブバンドルとは、Deadline Cloud レンダーファームで実行されるジョブの完全な説明です。このセクションでは、前述のユースケースがどのように実現されたかを理解するための第一歩として、Maya シーンからエクスポートされたジョブバンドルを見ていきます。 ジョブバンドルのエクスポート Maya を開き、レンダーファームに送信するシーンを読み込みます。 シーンの読み込み後、サブミッターを起動します。サブミッターが正しくインストールされている場合、図 B に示すように AWS Deadline タブ (画面の右端) が表示されます。サブミッターが表示されない場合は、 Windows 、 Settings/Preferences 、そして Plug-in Manager の順に選択してください。表示されるポップアップウィンドウで Deadline と入力し、 Loaded と Auto load を選択してからウィンドウを閉じます。 図 B: Maya 2024 の AWS Deadline Cloud ツールシェルフ AWS Deadline シェルフに Deadline Cloud アイコンが表示されたら、それをクリックすると Maya 統合 サブミッターが起動します。 こちらの手順 に従ってファームにログインしてください。 図 C: Maya 2024 統合サブミッターの初期起動 サブミッターを起動したら、 Export bundle ボタンをクリックします。エクスポート後、ファイルブラウザと確認モーダルがポップアップ表示されます。ファイルブラウザには、ジョブバンドルを含む 3 つのファイルが格納されたフォルダが表示されます。 図 D: Export bundle をクリックした後の Maya 2024 統合サブミッター ジョブバンドルの説明 Maya からエクスポートされた各ジョブバンドルフォルダには、アセット参照用、パラメータ値用、エクスポートされたジョブを記述するテンプレートの 3 つのファイルが含まれています。 asset_references.yaml ファイルには、アセットパス、出力フォルダ、ジョブの参照パスが含まれています。 Service-Managed Fleet (SMF) を使用している場合、これはアセットをレンダーファームにアップロードするための手段となります。 Customer-Managed Fleet (CMF) を ストレージプロファイル と共に使用している場合、asset_references.yaml で指定されるリストは空でも構いません。 parameter_values.yaml ファイルには、ジョブテンプレートで参照する予定の値が全て含まれているので便利です。画像解像度のユースケースでは、パラメータ値の例として ImageWidth と ImageHeight があります。 template.yaml ファイルには、ジョブの説明が含まれています。asset_references.yaml と parameter_values.yaml ファイルを参照して、ジョブを完全に表現することができます。3 つのファイルすべてを使用すると便利ですが、template.yaml ファイルだけでジョブを完全に記述することも可能です。 最初のユースケースである、プロジェクトパスと出力パスの更新を実現するために、ジョブバンドルを使用して構築していきます。 ユースケース #1 – プロジェクトパスと出力パスの更新 FuzzyPixel チームは、現在開いている Maya シーンから導出した Python コードを使用して、プロジェクトパスと出力パスを設定したいと考えていました。 以下のようなアプローチを取りました： Maya クエリの実行 Maya ファイルの現在のパスを取得する方法は複数ありますが、ここでは次のように実行しました: project_path = cmds.workspace(q=True, active=True) 出力パスについては、図 G に示すように、プロジェクトパスとフォルダを連結しました: output_path = f'{project_path}/images' 次に、クエリの結果を使用して、サブミッターのプロジェクトフィールドと出力フィールドに値を設定します。 プロジェクトパスと出力パスの値が得られたら、前のセクションで説明した parameter_values.yaml ファイルにデータを挿入できます。 先ほどエクスポートした parameter_values.yaml ファイルを開き、プロジェクトパスと出力パスを参照している行を見つけます。これらの行がハイライトされたエクスポートされたバンドルは図 E で確認できます。エクスポートしたバンドルの .yaml ファイルの該当する行は次のとおりです: - name: ProjectPath value: W:/Prod2/prod/sequences/sq0300/sh0050/light - name: OutputFilePath value: W:/Prod2/prod/sequences/sq0300/sh0050/light/maya/images 図 E: エクスポートされた parameter_values.yaml ファイル Python の pyyaml パッケージを使用して、parameter_values.yaml ファイルをプログラムで更新できます。今回は手動でファイルを変更します。例えば、13 行目の project_path と、15 行目の output_path に変更します (図 E を参照)。 変更されたバンドルからジョブを送信  このセクションでは、エクスポートしたジョブバンドルに加えた変更を表示する GUI を起動します。 1. 上記の前提条件を満たしたワークステーションのコマンドシェルから、次のコマンドを入力します: deadline bundle gui-submit C:\path_to_your_exported_and_modified_bundle サブミッターの起動: 図 F: deadline バンドル gui-submit の画面 Job-specific settings タブをクリックして、変更したプロジェクトパスと出力パスを確認します。 図 G: Deadline バンドル gui-submit の Job-specific settings ユースケース #2 – 画像解像度 バンドルデータを変更して画像解像度のユースケースを実現するパターンに従うことで、時間を節約し、レンダリングコストを削減できます。すべての GUI control の Description が利用可能です。 ユースケース #3、#4、#5 – カスタムサブミッターのスクラッチ開発 タブの再編成、フリートのカスタム属性、レンダーレイヤーの制御のユースケースは、前のセクションのカスタマイズパターンから、以下の 4 つの領域で外れていました。 タブの再編成 : Deadline Cloud Maya 統合サブミッターでは、.yaml の編集によるタブの追加や削除はできません。 QTree Widget : レンダーレイヤーの表示に QTree Widget コントロールを使用したいと考えましたが、このコントロールはジョブテンプレート UI コントロールとして利用できません。 カスタムハンドラー : 統合サブミッターは、 Submit ボタンをクリックした後の template.yaml の更新をまだサポートしていません。Maya のクエリ、またはカスタムサブミッター GUI の変更、そしてユーザーが Submit ボタンをクリックした 後に  template.yaml を更新するには、カスタムハンドラーが必要です。 フリート属性の表示 : ユーザーがジョブを実行するインスタンスタイプを制御できるようにするため、ファームで ‘スポット’ と ‘オンデマンド’ のフリート属性を定義し、これらの属性をサブミッターで表示しました。 タブの再編成、QTree Widget の実装、カスタムハンドラーについては、公開されている QT のコントロールとドキュメント を活用しました。フリートの属性を表示するために AWS Deadline Cloud API を使用しました。 FuzzyPixel Maya カスタムサブミッターは、図 H に示すように、Render Settings タブの下によく使用される機能を統合することで、ユーザーのワークフローを効率化します。図 I に示すように、Render Layers タブはサブミッター内でレンダーレイヤーの可視性とフレーム範囲を直接制御できるようにすることで、サブミッターの機能を拡張します。これまでのすべてのユースケースは、スクラッチ開発された Python コードを通じて実装されており、 OpenJD スキーマ全体 を探索するための実践的な経験とコンテキストを提供します。 図 H: FuzzyPixel Maya サブミッターの Render Settings タブ 図 I: FuzzyPixel Maya サブミッターの Render Layers タブ まとめ このブログでは、Maya サブミッターのワークフローをカスタマイズするために、Python コードを手動で編集し、ジョブバンドルを変更しました。これらのカスタマイズにより、クリエイティブワークフローの中断を最小限に抑え、時間を節約し、最終的にコストを削減するというるユースケースを実現するのに役立ちました。 AWS がどのようにお客様のビジネスを加速させることができるのか、  AWS の担当者 にお問い合わせください。 参考資料 Open Job Description ドキュメント ジョブの構築方法 ジョブの実行方法 サンプル Gregory Dismond Gregory Dismond は、AWS のクリエイティブツール部門でデザインテクノロジストを務めており、35 年以上にわたる経験を持っています。その経験には、DreamWorks や EA でのパイプライン開発、telltale games でのナラティブ R&D、Wavefront Technologies でのプロダクト開発、NSF ERC での計算幾何学が含まれます。 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチームの問い合わせ先: awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 本記事は、 Using Open Job Description to Customize Submitter Workflows を翻訳したものです。翻訳は Solutions Architect の濵野が担当しました。

はじめに こんにちは！ソリューションアーキテクトの西亀真之です。今回は、 AWS Summit Japan 2025 の1日目 (2025年6月25日) に展示予定の「生成 AI でロボットが人間の指示を理解！」というデモについて、その魅力と背景にある技術をご紹介します。このデモでは、Amazon Bedrock の生成 AI 技術を活用して、Mini Pupper という小型四足歩行ロボットを自然言語で直感的に操作する体験ができます。 図1: デモで利用する小型四足歩行ロボットのMini Pupper 「ダンスして」「前に歩いて、その後に右に曲がって」といった日常的な言葉で指示するだけで、ロボットが理解して動く様子は、まるで未来から来たかのような体験です。しかも、事前にプログラムしていない指示でも、生成 AI がうまく解釈してロボットの動きに変換してくれる柔軟性も魅力の一つです。どのような指示でも何かしようと頑張る姿は、思わず愛着が湧いてくるほど可愛らしいものです。 デモで体験できること このデモでは、以下のような体験ができます： 自然言語でのロボット操作 : 専門的な知識がなくても、日常会話のような言葉でロボットを操作できます 生成 AI による指示の解釈 : 曖昧な指示や複雑な指示も、生成AIが適切に解釈してロボットの動きに変換します 例えば、「嬉しそうに踊って」と指示すると、Mini Pupper は頭を上下に振りながら前後に動いたり、「悲しそうに歩いて」と言えば、頭を下げながらゆっくりと歩いたりします。事前にプログラムされていない行動でも、生成 AI が「嬉しい」「悲しい」といった感情表現を解釈し、適切なロボットの動きに変換してくれるのです。 背景にある技術 図2: デモのアーキテクチャ概要 このデモの裏側では、以下の AWS サービスと技術が連携して動作しています： 1.  Amazon Bedrock による自然言語処理 デモの中核となるのは、 Amazon Bedrock の大規模言語モデル（LLM）です。今回のデモでは、軽量なモデルである Claude 3.5 Haiku を利用しています。ユーザーからの自然言語の指示を受け取り、ロボットが理解できるコマンドの組み合わせに変換します。例えば「前に歩いて、その後に右に曲がって」という指示は、以下のようなコマンドに変換されます： ['move_forward:0.5:2.0', 'stop:0:0.5', 'turn_right:-1.0:1.0', 'stop:0:0.5'] 2.  Amazon Bedrock Agents によるアクション実行 Amazon Bedrock Agents は、生成 AI が作成したコマンドを受け取り、 AWS Lambda を通じて AWS IoT Core 経由でロボットにコマンドを送信します。 3.  AWS IoT Core による安全な通信 AWS IoT Core は、クラウドとロボット間の安全で信頼性の高い通信を実現します。MQTT プロトコルを使用することで、低レイテンシーでリアルタイムな制御が可能になっています。ロボットがコマンドを受信すると、そのコマンドに基づいて対応するアクションを実行します。ロボットの制御では ROS2 というロボット開発で広く使われるソフトウェアを利用しています。 図3: ユーザーの指示からロボットの制御までの流れ デモの見どころ このデモの見どころはユーザからの指示を事前に細かく設定せずとも、生成 AI が柔軟に指示を解釈し、動作を生成してくれるところになります。あらかじめ定義された基本的な動作（前進、後退、回転など）を組み合わせることで、事前に明示的にプログラムしていない複雑な行動も実現できます。生成 AI が人間の意図を理解し、適切な動作の組み合わせを考え出すことで、ロボットの可能性が大きく広がります。 例えば、「犬のように振る舞って」という指示に対して、生成 AI は「吠える」「尻尾を振る（体を揺らす）」「四つん這いで歩く」といった基本動作を組み合わせて、犬らしい振る舞いを作り出します。ブースにお越しいただいた際にはロボットに対して無茶振りをしてみてください。 AWS Summit Japan 2025 でぜひ体験を！ このデモは、 AWS Summit Japan 2025 の1日目の6月25日に ブース B-131-A  で体験いただけます。実際に自分の言葉で Mini Pupper を操作する体験は、文章や画像だけでは伝わらない感動があります。 ぜひ会場にお越しいただき、生成 AI とロボティクスの融合がもたらす新しい可能性を体感してください。皆さまのご来場をお待ちしております。 まとめ：生成 AI とロボティクスの未来 Amazon Bedrock のような生成 AI 技術とロボティクスの融合は、まだ始まったばかりです。今回のデモで示したような自然言語インターフェースは、ロボットとのコミュニケーション方法を変える可能性を秘めています。将来的には、家庭用ロボット、産業用ロボット、介護ロボットなど、様々な分野で自然言語による直感的な操作が当たり前になるかもしれません。 AWS Summit Japan 2025 のデモブースで、その未来の一端を体験してみませんか？皆さまのご来場を心よりお待ちしております。 イベント情報 イベント名 : AWS Summit Japan 2025 日程 : 2025年6月25日 (Day 1) 場所 : AWS Expo の AWS Builders’ Fair の中にあります。詳細は こちら 。 デモブース名 : 生成 AI でロボットが人間の指示を理解！ ブース番号 : B-131-A このブログ記事が、AWS Summit Japan 2025 のロボティクスデモに興味を持っていただくきっかけになれば嬉しいです。 著者紹介 西亀 真之 (Saneyuki Nishigame) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト AWS Japan のソリューションアーキテクトとして製造業のお客様をご支援しています。好きな領域は IoT とロボットです。趣味はボルダリングでオフィスにあるボルダリングウォールにトライしています。 Muhammad Fikko Fadjrimiratno（ふぃっこ） アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト 不動産・建設業界のお客様を中心に、AWS 利用をご支援しているソリューションアーキテクトです。好きな領域はロボットとIoTと機械学習であり、最近はロボット分野での生成AIの活用にチャレンジしています。趣味はフライトシミュレーター、冬はスノーボードです。

AWS re:Inforce 2025 (6 月 16 日～18 日、フィラデルフィア) において、AWS の Vice President 兼 Chief Information Security Officer である Amy Herzog が基調講演を行い、新たなセキュリティイノベーションについて発表しました。イベント全体を通して、AWS は、セキュリティの大規模な簡素化と、組織がクラウドでより回復力の高いアプリケーションを構築できるようにすることに重点を置いた追加のセキュリティ機能を発表しました。今年のカンファレンスで発表された主要なセキュリティ機能のリリースとアップデートの包括的な概要を以下に示します。 新しい IAM Access Analyzer 機能を使用して、重要な AWS リソースへの内部アクセスを検証 AWS Identity and Access Management Access Analyzer の新機能は、セキュリティチームが、自動推論を使用して複数のポリシーを評価し、統合ダッシュボードを通じて検出結果を表示することで、AWS 組織内のどのプリンシパルが、S3 バケット、DynamoDB テーブル、RDS スナップショットなどの重要なリソースにアクセスできるのかを検証するのに役立ちます。 AWS IAM がすべてのアカウントタイプでルートユーザーに MFA を強制するようになりました 新しい多要素認証の強制により、パスワード関連の攻撃の 99% 超を防ぐことができます。FIDO 認定セキュリティキーなど、サポートされているさまざまな IAM MFA の方法を用いて、AWS アカウントに対するアクセスを強化できます。AWS はユーザーフレンドリーな MFA 実装のために FIDO2 パスキーをサポートしているため、ユーザーはルートユーザーと IAM ユーザーごとに最大 8 台の MFA デバイスを登録できます。 AWS Network Firewall で Amazon 脅威インテリジェンスを使用してセキュリティ体制を強化 この新しい Network Firewall マネージドルールグループは、AWS におけるワークロードに関連するアクティブな脅威に対する保護を提供します。この機能は、Amazon 脅威インテリジェンスシステムである MadPot を利用して、マルウェアホスティング URL、ボットネットのコマンド & コントロールサーバー、暗号通貨マイニングプールなどの攻撃インフラストラクチャを継続的に追跡し、アクティブな脅威についての侵害指標 (IOC) を特定します。 AWS Certificate Manager がどこでも使用できるエクスポート可能なパブリック SSL/TLS 証明書を導入 AWS Certificate Manager を利用して、安全な TLS トラフィック終端処理を必要とする AWS、ハイブリッド、またはマルチクラウドワークロードのために、エクスポート可能なパブリック証明書を発行できるようになりました。 AWS WAF の簡素化されたコンソールエクスペリエンス 新しい AWS WAF コンソールエクスペリエンスでは、事前設定済みの保護パックを通じて、セキュリティ設定のステップが最大 80% 少なくなります。セキュリティチームは、統合セキュリティメトリクスと、直感的なインターフェイスを通じたカスタマイズ可能なコントロールにより、特定のアプリケーションタイプのための包括的な保護を迅速に実装できます。 Amazon CloudFront が新しいユーザーフレンドリーなインターフェイスでウェブアプリケーションの配信とセキュリティを簡素化 Amazon CloudFront の簡素化されたコンソールエクスペリエンスをぜひお試しください。AWS WAF の強化されたルールパックと統合インターフェイスを通じて、TLS 証明書のプロビジョニング、DNS 設定、セキュリティ設定を自動化することで、わずか数クリックでウェブアプリケーションの高速化とセキュリティ保護を実現できます。 新しい AWS Shield 機能が、ネットワークセキュリティの問題が悪用される前に検出 (プレビュー) Shield のネットワークセキュリティ体制管理は、AWS アカウント全体でネットワークリソースを自動的に検出および分析し、AWS のベストプラクティスに基づいてセキュリティリスクの優先順位付けを行い、SQL インジェクションや DDoS 攻撃などの脅威からアプリケーションを保護するための是正に関する実用的なレコメンデーションを提供します。 新しい AWS Security Hub を利用してセキュリティを統合し、リスクの優先順位付けと対応を大規模に実現 (プレビュー) AWS Security Hub は、セキュリティシグナルを実用的なインサイトに変換できるように強化されています。これは、セキュリティチームが重要度の高い問題を大規模に優先順位付けして対応するのに役立ちます。この統合ソリューションは、クラウド環境全体の包括的な可視性を提供するとともに、複数のセキュリティツールの管理に伴う複雑さを軽減します。 Amazon GuardDuty が Extended Threat Detection の対象範囲を Amazon EKS クラスターに拡張 Amazon GuardDuty Extended Threat Detection が Amazon EKS クラスターをサポートするようになりました。これは、Kubernetes 監査ログ、実行時の動作、AWS API アクティビティにおけるセキュリティシグナルを相関させることで、高度な多段階攻撃を検出するのに役立ちます。この機能強化により、この機能がなければ見逃される可能性のある重大度の高い攻撃シーケンスが自動的に特定され、脅威への迅速な対応が可能になります。 AWS MSSP コンピテンシーの新しいカテゴリ AWS MSSP コンピテンシー (旧称: AWS レベル 1 MSSP コンピテンシー) に、インフラストラクチャセキュリティ、ワークロードセキュリティ、アプリケーションセキュリティ、データ保護、ID およびアクセス管理、インシデント対応、サイバーリカバリをカバーする新しいカテゴリが追加されました。パートナーは、専用のセキュリティオペレーションセンターを通じて 24 時間年中無休のモニタリングとインシデント対応を提供します。 Amazon Verified Permissions を利用して Express アプリケーション API を数分で保護 Amazon Verified Permissions は、デベロッパーが Amazon Verified Permissions を利用して Express ウェブアプリケーション API の認可を数分で実装できるようにするオープンソースパッケージである verified-permissions-express-toolkit のリリースを発表しました。 コンピューティングを超えて: Amazon Inspector のコードセキュリティで脆弱性検出をシフトレフト Amazon Inspector のコードセキュリティ機能の一般提供が開始されました。これは、アプリケーションのソースコード、依存関係、Infrastructure as Code (IaC) 全体でセキュリティ上の脆弱性と設定ミスを迅速に特定し、優先順位を付けることで、本番導入前にアプリケーションのセキュリティを実現するのに役立ちます。 AWS Backup が論理エアギャップボールトのためにマルチパーティー承認機能を追加 AWS Backup の論理エアギャップボールトのためのマルチパーティー承認機能により、AWS アカウントが侵害された場合でも、リカバリアカウントとのボールト共有を有効にできる、信頼された個人で構成される指定承認チームからの認可を活用することで、バックアップデータをリカバリできます。 原文は こちら です。

6 月 17 日、AWS re:Invent 2024 での発表「 Amazon GuardDuty Extended Threat Detection: クラウドセキュリティの強化のための AI/ML 攻撃シーケンスの特定 」でご紹介した機能を基に、対象範囲を Amazon Elastic Kubernetes Service (Amazon EKS) に拡張した Amazon GuardDuty Extended Threat Detection を発表しました。 Kubernetes ワークロードを管理するセキュリティチームは、コンテナ化されたアプリケーションを標的とする高度な多段階攻撃の検出に苦労することがよくあります。これらの攻撃には、コンテナの悪用、権限昇格、Amazon EKS クラスター内での不正な移動が含まれる場合があります。従来のモニタリングアプローチでは、個々の疑わしいイベントは検出できたとしても、さまざまなデータソースや期間にまたがる、より広範な攻撃パターンを見逃してしまうことがよくあります。 GuardDuty Extended Threat Detection では、Amazon EKS 監査ログ、EKS クラスターに関連付けられたプロセスの実行時の動作、EKS クラスターでのマルウェア実行、AWS API アクティビティにおけるセキュリティシグナルを自動的に相関させ、この機能を使用しなければ見過ごされる可能性のある高度な攻撃パターンを特定する、重大度の高い検出結果タイプが新たに導入されています。例えば、GuardDuty は、脅威アクターがコンテナアプリケーションを悪用し、特権サービスアカウントトークンを取得して、これらの昇格された権限を使用して機密性の高い Kubernetes シークレットまたは AWS リソースにアクセスする攻撃シーケンスを検出できるようになりました。 この新しい機能は、GuardDuty 相関アルゴリズムを使用して、潜在的な侵害を示唆するアクションシーケンスを監視および特定します。 保護プラン や他のシグナルソース全体で検出結果を評価して、一般的な攻撃パターンや新たな攻撃パターンを特定します。検出された攻撃シーケンスごとに、GuardDuty は、影響を受ける可能性のあるリソース、イベントのタイムライン、関与するアクター、シーケンスの検出に使用されたインジケーターなど、包括的な詳細を提供します。また、検出結果は、検知されたアクティビティを、MITRE ATT&CK® の戦術と手法、および AWS ベストプラクティスに基づく是正に関するレコメンデーションにマッピングします。これは、セキュリティチームが脅威の性質を理解するのに役立ちます。 EKS のために Extended Threat Detection を有効にするには、 EKS Protection または Runtime Monitoring のうち、少なくとも 1 つの機能を有効にする必要があります。検出カバレッジを最大化するために、両方を有効にして検出機能を強化することをお勧めします。EKS Protection は監査ログを通じてコントロールプレーンのアクティビティをモニタリングし、Runtime Monitoring はコンテナ内の動作を監視します。これらを組み合わせることで、EKS クラスターの完全なビューが作成され、GuardDuty は複雑な攻撃パターンを検出できるようになります。 仕組み EKS クラスターのために新しい Amazon GuardDuty Extended Threat Detection を利用するには、 GuardDuty コンソール に移動して、アカウントで EKS Protection を有効にします。右上のリージョンセレクターから、EKS Protection を有効にするリージョンを選択します。ナビゲーションペインで、 [EKS Protection] を選択します。 [EKS Protection] ページで、現在のステータスを確認し、 [有効にする] を選択します。 [確認] を選択して選択内容を保存します。 有効になると、GuardDuty は追加の設定を必要とせずに、EKS クラスターからの EKS 監査ログのモニタリングを直ちに開始します。GuardDuty は、独立したストリームを通じて、EKS コントロールプレーンから直接、これらの監査ログを使用します。これは、既存のログ記録設定には影響しません。 マルチアカウント環境の場合 、委任された GuardDuty 管理者アカウントのみが、メンバーアカウントのために EKS Protection を有効または無効にしたり、組織に参加する新しいアカウントのために自動有効化設定を構成したりできます。 Runtime Monitoring を有効にするには、ナビゲーションペインで [Runtime Monitoring] を選択します。 [設定] タブで [有効にする] を選択して、アカウントのために Runtime Monitoring を有効にします。 これで、 [概要] ダッシュボードから、Kubernetes クラスターの侵害に特に関連する攻撃シーケンスと重要度の高い検出結果を表示できます。GuardDuty が、認証情報の侵害イベントや EKS クラスター内の疑わしいアクティビティなど、Kubernetes 環境における複雑な攻撃パターンを特定していることを確認できます。重大度、リソースへの影響、攻撃タイプ別に検出結果が視覚的に表されるため、Amazon EKS のセキュリティ体制を全体的に把握できます。これにより、コンテナ化されたワークロードに対する極めて重要な脅威を優先できます。 [検出結果の 詳細] ページでは、EKS クラスターを標的とする複雑な攻撃シーケンスが可視化されるため、潜在的な侵害の全容を把握するのに役立ちます。GuardDuty は、シグナルをタイムラインに相関させ、検知された動作を、MITRE ATT&CK® の戦術や手法 (アカウント操作、リソースハイジャック、権限昇格など) にマッピングします。このきめ細かなインサイトにより、攻撃者が Amazon EKS 環境をどのように侵害しているのかが正確に明らかになります。EKS ワークロードやサービスアカウントなどの影響を受けるリソースを特定します。インジケーター、アクター、エンドポイントの詳細な内訳により、攻撃パターンを理解し、影響を判断して、是正作業の優先順位を決定するための実用的なコンテキストが提供されます。これらのセキュリティインサイトを統合ビューにまとめることで、Amazon EKS セキュリティインシデントの重大度を迅速に評価し、調査時間を短縮して、コンテナ化されたアプリケーションを保護するための的を絞った対策を実施できます。 [検出結果の詳細] ページの [リソース] セクションには、攻撃シーケンス中に影響を受けた特定のアセットに関するコンテキストが表示されます。この統合リソースリストにより、最初のアクセスから標的の Kubernetes コンポーネントに至るまで、侵害の正確な範囲を可視化できます。GuardDuty には、リソースタイプ、識別子、作成日、名前空間の情報などの詳細な属性が含まれているため、コンテナ化されたインフラストラクチャのどのコンポーネントで即時の対応が必要かを迅速に評価できます。この集中的なアプローチにより、インシデント対応中の推測作業が排除されるため、影響を受ける極めて重要なリソースの是正作業を優先し、Amazon EKS を標的とした攻撃の潜在的な影響範囲を最小限に抑えることができます。 今すぐご利用いただけます 対象範囲を Amazon EKS クラスターに拡大した Amazon GuardDuty Extended Threat Detection は、Kubernetes 環境全体にわたる包括的なセキュリティモニタリングを提供します。この機能を使用すると、さまざまなデータソース間でイベントを相関させ、従来のモニタリングでは見逃される可能性のある攻撃シーケンスを特定することで、高度な多段階攻撃を検出できます。 この拡張カバレッジの使用を開始するには、GuardDuty の設定で EKS Protection を有効にし、検出機能を強化するために Runtime Monitoring を追加することを検討してください。 この新機能の詳細については、 Amazon GuardDuty のドキュメントをご覧ください。 – Esra 原文は こちら です。

本稿は、2025 年 6 月 17 日に AWS Storage Blog で公開された “ Protect on-premises VMware infrastructure with NetApp BlueXP Disaster Recovery, Amazon Elastic VMware Service, and Amazon FSx for NetApp ONTAP ” を翻訳したものです。 VMware ワークロードには、ビジネス上の意思決定や運用の原動力となる重要なデータが含まれています。ランサムウェアの脅威、壊滅的なハードウェア障害、自然災害などの潜在的な災害が、多大なコストを伴うダウンタイムやデータ損失につながる可能性があるため、データの可用性と耐障害性の維持は最優先事項です。こうした課題に対処するには、あらゆる企業にとって効果的なディザスタリカバリ (DR) 戦略を策定するための戦略的計画と信頼できるソリューションが必要不可欠です。 NetApp BlueXP Disaster Recovery は、Amazon Elastic VMware Service ( Amazon EVS ) と Amazon FSx for NetApp ONTAP ( FSx for ONTAP ) を使用してクラウドと統合することで、オンプレミスの VMware ワークロードをシームレスに保護する方法を提供します。 この統合ソリューションにより、組織には次のようなメリットがあります。 短縮された目標復旧時間 (RTO) と目標復旧時点 (RPO) の達成 Amazon Web Services (AWS) の従量課金制モデルを活用した費用対効果の高い DR ソリューション 既存の VMware ツールやプロセスとのシームレスな統合 本番環境の VM の中断を伴わないフェイルオーバーのテスト 本稿では、これらのテクノロジーがどのように連携して、事業継続性の重要なニーズに対応する包括的な DR ソリューションを提供するのかを探ります。 1. Amazon EVS をフェイルオーバーサイトとして設定する方法、2. Amazon EVS の vCenter を新しいサイトに追加する方法、3. レプリケーションプランの作成、4. テストフェイルオーバーの実行の 4 つのステップで構成と実装について説明します。 ソリューション概要 NetApp BlueXP Disaster Recovery NetApp BlueXP Disaster Recovery は、VMware 環境に堅牢なデータ保護とリカバリを提供するように設計された DRaaS (Disaster Recovery as a Service) ソリューションです。 BlueXP クラウドベースの管理フレームワークの不可欠な部分として、このサービスは既存の BlueXP マネージド NetApp ONTAP ストレージインフラストラクチャと自動的に統合されます。Amazon EVS と FSx for ONTAP を活用することで、企業は重要な仮想マシン (VM) をデータ損失から保護し、ダウンタイム時に迅速に復旧できます。ソリューションアーキテクチャを 図 1 に示します。 図 1: BlueXP Disaster Recovery の概要 BlueXP Disaster Recovery の主な価値は次のとおりです。 シームレスな統合 : オンプレミスの VMware 環境と AWS のサービスを簡単に統合できます。 VM の自動フェイルオーバー : 最小限のダウンタイムで AWS のワークロードを迅速に復旧できます。 管理の簡素化 : オンプレミス環境と Amazon EVS 環境の両方を単一のインターフェイスから管理できます。 コスト最適化 : 使用した AWS リソースに対してのみお支払いいただきます。 スケーラビリティ : 変化するビジネスニーズに合わせて DR 環境を迅速に拡張できます。 Amazon Elastic VMware Service (Amazon EVS) Amazon EVS は、プラットフォームの変更や再構築を必要とせずに、使い慣れた VMware Cloud Foundation (VCF) ソフトウェアとツールに AWS のスケール、回復力、パフォーマンスを連携させることができます。 Amazon EVS の主な価値は次のとおりです。 スピードとシンプルさ : 移行の煩わしさを解消し、運用の一貫性を維持します。 IP アドレスの変更、スタッフの再トレーニング、運用手順書の書き換えをすることなく、オンプレミスネットワークを拡張し、ワークロードを移行できます。 制御とカスタマイズ : クラウド内の VMware アーキテクチャを完全に制御して、アドオンやサードパーティソリューションなど、アプリケーション固有の要求を満たす仮想化スタックを設計および最適化できます。ワークロードだけでなく、仮想化環境もリフト＆シフトできます。 使い慣れたツールを活用して、ストレージ、バックアップ、ディザスタリカバリのニーズに対応できます。 管理方法の選択 : セルフマネージドで運用するか、AWS パートナーの専門知識を活用して AWS 上の VCF 環境を構築、管理、運用し、人材、時間、コストにわたるビジネス目標を達成することを選択できます。 AWS サービスへのアクセス : ワークロードをクラウドに確実に移行し、信頼性、耐障害性、セキュリティ、スケーラビリティの向上によるメリットを享受できます。Amazon EVS は、200 を超えるサービスを通じて VMware 環境の拡張と拡大を簡素化します。 FSx for ONTAP によるサポート : 外部データストアと VM 接続ストレージの両方で、FSx for ONTAP は柔軟性を高め、コストを削減し、データ保護、高可用性を実現するコンピューティングから切り離された伸縮自在なストレージなど、さまざまなエンタープライズグレードのメリットをもたらします。 Amazon FSx for NetApp ONTAP Amazon FSx for ONTAP は、NetApp の ONTAP ストレージソフトウェアの機能をネイティブサービスとして AWS にもたらすフルマネージドストレージサービスです。 Amazon EVS での使用が検証されており、高度なデータ管理機能を備えた VMware 環境のストレージ基盤を提供します。これには ONTAP API、スナップショットベースのデータ保護、SnapMirror レプリケーションが含まれます。 FSx for ONTAP の主な価値は次のとおりです。 ハイパフォーマンス : 低レイテンシで高いパフォーマンスを実現し、要求の厳しいアプリケーションやワークロードに適しています。 コスト最適化 : 重複排除や圧縮などのストレージ効率化機能を提供して、ストレージコストを削減します。 データ保護 : ONTAP スナップショットと SnapMirror レプリケーションをサポートします。 スケーラビリティ : パフォーマンスを犠牲にすることなく、増大するデータニーズに合わせて迅速に拡張できます。 使い慣れた ONTAP エクスペリエンス : オンプレミスの NetApp ONTAP と同等のユーザーエクスペリエンスを提供します。 構成と実装 Amazon EVS と FSx for ONTAP を使用した BlueXP Disaster Recovery のセットアップは簡単です。以下に 4 つの概要を示します。 ステップ 1: Amazon EVS をフェイルオーバーサイトとして設定する BlueXP Disaster Recovery を使用して Amazon EVS の vCenter でサイトをセットアップする場合は、 Location ドロップダウンメニューから AWS-EVS を選択します。 (図 2) 図 2: BlueXP Disaster Recovery での Amazon EVS サイトの作成 ステップ 2: Amazon EVS の vCenter を新しいサイトに追加する サイトが作成されたら、既存の FSx for ONTAP ベースの Amazon EVS の vCenter を追加できます。vCenter の管理 IP アドレスまたは完全修飾ドメイン名 (FQDN)、正しい TCP ポート、および DRaaS で vCenter を管理するために必要な権限を含むログイン認証情報を入力します (図 3) 。 この情報は、不正アクセスを防ぐために、お客様の Amazon Virtual Private Cloud ( Amazon VPC ) 内の BlueXP コネクタに保存されます。 図 3: Amazon EVS の vCenter クラスターをサイトに追加する ステップ 3: レプリケーションプランを作成する BlueXP Disaster Recovery コンソールの Replication plans セクションに移動し、 レプリケーションプラン を追加します。新しく作成したサイトを “Failover site” として使用します。 (図 4) 図 4: Amazon EVS を Failover site として使用するレプリケーションプラン ステップ 4: テストフェイルオーバーを実行する データレプリケーションが完了したら、VMware DR プランを簡単に有効化できます。 レプリケーションプラン を選択し、 ドロップダウンメニュー から Failover をクリックします。 確認ポップアップに Failover と入力し、 Failover ボタン をクリックして確定します。 (図 5) 図 5: Amazon EVS と FSx for ONTAP を使用したフェイルオーバーの実行 フェイルオーバープロセスが期待通りに動作することを確認するために、定期的にテストを行うことが重要です。BlueXP Disaster Recovery のユニークな機能の 1 つは、稼働中の本番 VM とその保護を中断することなく、テストフェイルオーバーを実行できることです。 テストフェイルオーバーを実行するには、 ドロップダウンメニュー から “Fail over” の代わりに Test failover メニューオプションを選択します。 このプロセスは、実際のフェイルオーバーとは 3 つの点で異なります。 オンプレミスで実行されている本番環境の VM は停止しません。 レプリケーションプランで保護されているデータストアのレプリケーションは停止されません。 FSx for ONTAP クラスタで保護されている各データストアのクローンを作成し、その情報を使用して Amazon EVS の vCenter に VM を登録して起動します。 利用を開始する NetApp の既存のお客様は、追加費用なしで Lab On Demand にアクセスできるため、既存のインフラストラクチャにサービスをインストールすることなく、BlueXP Disaster Recovery の機能を試すことができます。FSx for ONTAP を初めて使用する場合は、 AWS Marketplace で NetApp BlueXP のリストにアクセスしてサブスクライブしてください。いくつかの手順を実行して導入すると、BlueXP コンソールから BlueXP Disaster Recovery の 30 日間の容量無制限トライアルにアクセスできるようになります。追加コストは発生しません。トライアルが終了したら、レプリケーションプランとサイトを削除するだけで、すべての変更を元に戻すことができます。 結論 データの可用性が収益に直接影響する今日のビジネス環境において、堅牢なディザスタリカバリソリューションを持つことは単なる IT イニシアチブではなく、ビジネス要件です。 BlueXP Disaster Recovery を Amazon EVS および Amazon FSx for NetApp ONTAP と組み合わせると、オンプレミスの VMware ワークロード向けの強力で柔軟なデータ保護およびディザスタリカバリソリューションが実現します。この統合ソリューションでは、シームレスな AWS 統合、スケーラブルなディザスタリカバリ、AWS での従量課金制モデルによるコスト効率の向上、使い慣れた VMware ツールとインターフェイスによる管理の効率化が実現します。このソリューションを導入することで、企業は不測の災害に直面しても、重要なアプリケーションが引き続き利用可能で保護されていることを確認できます。 このブログでは、これらのテクノロジーがどのように連携して、事業継続性の重要なニーズに対応する包括的な DR ソリューションを実現するかを説明しました。1. Amazon EVS をフェイルオーバーサイトとして設定する方法、2. Amazon EVS の vCenter を新しいサイトに追加する方法、3. レプリケーションプランの作成、4. テストフェイルオーバーの実行の 4 つのステップで構成と実装について説明しました。 より多くの AWS パートナー ソリューションについて調べるか、 AWS の担当者 にお問い合わせいただき、お客様のビジネスの加速をどのように支援できるかをご相談ください。 さらに詳しく Amazon Elastic VMware Service (Amazon EVS) のパブリックプレビュー開始のお知らせ Amazon Elastic VMware Service が Amazon FSx for NetApp ONTAP と統合 Amazon FSx for NetApp ONTAP の開始方法 AWS における VMware ワークロードの次なる展開は？ BlueXP Disaster Recovery と Amazon EVS — ビデオ NetApp BlueXP Disaster Recovery の概要 NetApp BlueXP Disaster Recovery 導入ガイド   Eric Yuen Eric Yuen は AWS のシニアパートナーソリューションアーキテクトです。 ソリューションを構築する AWS ストレージパートナーと緊密に連携し、お客様が AWS でストレージ環境を設計できるよう支援しています。 Eric は、さまざまなストレージおよびデータ保護テクノロジーに関わってきた 20 年の業界経験があります。 Tony Ansley Tony Ansley は NetApp のシニアテクニカルマーケティングエンジニアで、NetApp ONTAP ストレージソリューションのデータ保護機能とサービスを担当しています。 Tony は、エンタープライズクライアントとデータセンターのテクノロジーに関する 35 年以上の経験があります。 翻訳はパートナーソリューションアーキテクト 豊田が担当し、監修はネットアップ合同会社の藤原様に協力頂きました。原文は こちら です。

AWS Security Hub は、Amazon Web Services (AWS) アカウント全体のセキュリティアラートとコンプライアンスステータスを表示し、集計するための中心的な場所となっています。6 月 17 日、相関関係、コンテキスト化、可視化機能が追加された新しい AWS Security Hub のプレビューリリースを発表します。これにより、重大なセキュリティ問題の優先順位付け、大規模な対応によるリスクの軽減、チームの生産性の向上、クラウド環境の保護強化ができるようになります。 新しい AWS Security Hub を簡単に紹介します。 この新しい機能強化により、AWS Security Hub は Amazon GuardDuty 、 Amazon Inspector 、 AWS Security Hub クラウドセキュリティ体制管理 (CSPM) 、 Amazon Macie 、その他の AWS セキュリティ機能を統合し、統合クラウドセキュリティソリューションでの一元管理を通じてクラウド環境全体を可視化できるようにします。 新しい AWS Security Hub の使用を開始する AWS Security Hub の使用を開始する方法を順を追って説明します。 AWS Security Hub を初めてご利用になる場合は、AWS Security Hub コンソールに移動して AWS のセキュリティ機能と諸機能を有効にし、組織全体のリスク評価を開始する必要があります。 ドキュメントのページ をご覧ください。 AWS Security Hub を有効にすると、Amazon GuardDuty、Amazon Inspector、Amazon Macie、AWS Security Hub CSPM など、有効にしたサポートセキュリティ機能のデータが自動的に使用されます。AWS Security Hub コンソールに移動してこれらの検出結果を確認し、これらの機能にわたる検出結果の相関関係から得られるインサイトを活用できます。 セキュリティリスクが発見されると、再設計された Security Hub 概要ダッシュボードに表示されます。新しい Security Hub 概要ダッシュボードでは、AWS のセキュリティ体制を包括的かつ統一的に把握できます。ダッシュボードでは、セキュリティの検出結果が明確なカテゴリに整理されるため、リスクの特定と優先順位付けが容易になります。 新しい エクスポージャーサマリー ウィジェットは、Amazon Inspector、AWS Security Hub CSPM、Amazon Macie からのリソース関係とシグナルを分析することで、エクスポージャー (セキュリティの脆弱性) を特定して優先順位を付けるのに役立ちます。これらのリスク検出結果は自動的に生成され、新しいソリューションの重要な部分となり、重要なエクスポージャーがどこにあるかが明らかになります。エクスポージャーについての詳細は、 ドキュメントのページをご覧ください 。 AWS Security Hub には、潜在的なカバレッジギャップを特定するのに役立つ セキュリティカバレッジ ウィジェットが提供されるようになりました。このウィジェットを使用すると、Security Hub のセキュリティ機能でカバーされていない箇所を特定できます。この可視性により、セキュリティカバレッジを向上させるために必要な機能、アカウント、機能を特定できます。 ナビゲーションメニューでわかるように、AWS Security Hub はセキュリティ管理を効率化するために 5 つの主要領域に分かれています。 エクスポージャー : Security Hub によって発生した、AWS リソースやシステムを不正アクセスや侵害にさらす可能性のある、セキュリティ上の脆弱性や設定ミスなど、すべてのエクスポージャー検出結果が可視化され、環境外からアクセスできる可能性のあるリソースを特定しやすくなります 脅威 : Amazon GuardDuty によって生成されたすべての脅威検出結果を統合し、潜在的な悪質なアクティビティや侵入の試みを表示します 脆弱性 : Amazon Inspector によって検出されたすべての脆弱性が表示され、ソフトウェアの欠陥と設定の問題が強調表示されます 体制管理 : AWS Security Hub クラウドセキュリティ体制管理 (CSPM) から得られたすべての体制管理検出結果を表示し、セキュリティのベストプラクティスに準拠できるようにします 機密データ : Amazon Macie が特定したすべての機密データ検出結果を表示し、機密情報の追跡と保護に役立ちます エクスポージャー ページに移動すると、タイトル別にグループ化された検出結果が表示され、重大度レベルが明確に示されるため、最初に重大な問題に集中できます。 特定のエクスポージャーを調べるには、任意の検出結果を選択すると、影響を受けたリソースが確認できます。パネルには、関係するリソース、アカウント、リージョン、および問題が検出された日時に関する重要な情報が表示されます。 このパネルには、複雑なセキュリティ関係を理解するのに特に役立つ攻撃パスも可視化されて表示されます。ネットワークエクスポージャーパスについては、仮想プライベートクラウド (VPC)、サブネット、セキュリティグループ、ネットワークアクセスコントロールリスト (ACL)、ロードバランサーなど、パスに含まれるすべてのコンポーネントを確認できるため、セキュリティコントロールを実装する場所を正確に特定するのに役立ちます。また、この可視化では Identity and Access Management (IAM) の関係も強調表示され、アクセス許可の設定によって権限昇格やデータアクセスがどのように可能になるかがわかります。複数の特性を持つリソースには明確なマークが付けられているため、どのコンポーネントが最もリスクが高いかをすばやく特定できます。 脅威ダッシュボード には、Amazon GuardDuty によって検出された潜在的な悪意のあるアクティビティに関する実用的なインサイトが表示され、検出結果が重大度別に整理されるため、異常な API コール、疑わしいネットワークトラフィック、潜在的な認証情報の侵害などの重大な問題をすばやく特定できます。ダッシュボードには、 GuardDuty 拡張脅威検出 の検出結果が表示され、すべての「重大」な重大度の脅威は、早急な対応を必要とするこれらの拡張脅威検出を表します。 同様に、Amazon Inspector の 脆弱性ダッシュボード では、ソフトウェアの脆弱性とネットワーク露出リスクを包括的に把握できます。ダッシュボードには、悪用が判明している脆弱性、緊急の更新が必要なパッケージ、脆弱性の数が最も多いリソースが表示されます。 もう 1 つの貴重な新機能は、AWS Security Hub の対象となる組織内にデプロイされたすべてのリソースのインベントリを提供する リソースビュー です。このビューを使用すると、どのリソースに不利な検出結果があるかをすばやく特定し、リソースタイプまたは検出結果の重大度でフィルタリングできます。任意のリソースを選択すると、他のコンソールに切り替えなくても詳細な設定情報が得られるため、調査ワークフローが効率化されます。 新しいセキュリティハブには、クラウド環境を包括的に監視し、サードパーティのセキュリティソリューションに接続するのに役立つ統合機能も用意されています。これにより、組織固有のニーズに合わせた統合セキュリティソリューションを柔軟に作成できます。 例えば、統合機能を使用すると、セキュリティ検出結果を表示するときに、「 チケットの作成 」オプションを選択して、希望するチケット統合を選択できます。 その他の情報 いくつかの留意点を次に示します: 利用可能なリージョン – このプレビュー期間中、新しい AWS Security Hub は、次の AWS リージョンでご利用いただけます。米国東部 (バージニア北部、オハイオ)、米国西部 (北カリフォルニア、オレゴン)、アフリカ (ケープタウン)、アジアパシフィック (香港、ジャカルタ、ムンバイ、大阪、ソウル、シンガポール、シドニー、東京)、カナダ (中部)、欧州 (フランクフルト、アイルランド、ロンドン、ミラノ、パリ、ストックホルム)、中東 (バーレーン)、南米 (サンパウロ) 。 価格 — 新しい AWS Security Hub は、プレビュー期間中は追加料金なしでご利用いただけます。ただし、Amazon GuardDuty、Amazon Inspector、Amazon Macie、AWS Security Hub CSPM などの統合機能のコストは引き続き発生します。 既存の AWS セキュリティ機能との統合 — Security Hub は Amazon GuardDuty、Amazon Inspector、AWS Security Hub CSPM、および Amazon Macie と統合されているため、運用上のオーバーヘッドを増やすことなく包括的なセキュリティ体制を実現できます。 データ相互運用性の強化 — 新しい Security Hub は オープンサイバーセキュリティスキーマフレームワーク (OCSF) を使用しており、標準化されたデータ形式でセキュリティ機能全体でシームレスなデータ交換を可能にします。 強化された AWS Security Hub の詳細とプレビューへの参加については、 AWS Security Hub 製品ページをご覧ください。 構築がうまくいきますように。 –  Donnie 原文は こちら です。

マルチチャネル文字起こしストリーミングは、 Amazon Transcribe の機能の一つで、多くの場合ウェブブラウザで利用できます。このストリームソースの作成にはいくつかの制約がありますが、 JavaScript Web Audio API を使用すると、動画、音声ファイル、マイクなどのハードウェアなど、さまざまなオーディオソースを接続して組み合わせ、文字起こしを作成できます。 この記事では、2 つのマイクをオーディオソースとして使用し、それらを 1 つのデュアルチャネルオーディオに結合し、必要なエンコードを実行して Amazon Transcribe にストリーミングする方法を説明します。ブラウザに 2 つのマイクを接続する際に必要とする Vue.js アプリケーションのソースコードも提供されています。ただし、このアプローチの汎用性はこのユースケースにとどまらず、さまざまなデバイスやオーディオソースに対応するように調整できます。 このアプローチでは、1 回の Amazon Transcribe セッションで 2 つのソースの文字起こしを取得できるため、ソースごとに個別のセッションを使用する場合と比較して、コスト削減などのメリットが得られます。 2つのマイクを使用する際の課題 今回のユースケースでは、2 つのマイクでシングルチャネルのストリームを使用し、 Amazon Transcribe のスピーカーラベル識別機能 を有効にしてスピーカーを識別すれば十分かもしれませんが、いくつか考慮すべき点があります。 スピーカーラベルはセッション開始時にランダムに割り当てられるため、ストリーム開始後にアプリケーションで結果をマッピングする必要があります。 似たような声色を持つスピーカーが誤ってラベル付けされる可能性があり、人間でさえ区別が困難です。 2 人のスピーカーが 1 つのオーディオソースで同時に話すと、音声が重なり合う可能性があります。 マイクで 2 つのオーディオソースを使用し、各トランスクリプトが固定の入力ソースから取得することで、これらの懸念に対処できます。スピーカーにデバイスを割り当てることで、アプリケーションはどのトランスクリプトを使用するかを事前に認識できます。ただし、近くにある 2 つのマイクが複数の音声を拾っている場合、音声が重なり合う可能性があります。これは、指向性マイク、音量管理、Amazon Transcribe の単語レベルの 信頼度スコア を使用することで軽減できます。 ソリューションの概要 次の図はソリューションのワークフローを示しています。 2つのマイクのアプリケーション図 Web Audio API では、2つのオーディオ入力を使用します。この API を使うと、マイク A とマイク B の2つの入力を1つのオーディオデータソースに統合できます。左チャンネルがマイク A、右チャンネルがマイク B を表します。 次に、このオーディオソースを PCM (パルス符号変調) オーディオに変換します。PCM はオーディオ処理で一般的なフォーマットであり、Amazon Transcribe がオーディオ入力に必要とするフォーマットの1つです。最後に、PCM オーディオを Amazon Transcribe にストリーミングして文字起こしを行います。 前提条件 以下の環境を事前に用意することが必要です。 GitHub リポジトリ からのソースコード。 Bun または  Node.js が JavaScript ランタイムとしてインストールされていること。 Web Audio API と互換性のあるウェブブラウザ。このソリューションは、Google Chrome バージョン 135.0.7049.85 で動作することがテストされています。 2 つのマイクがコンピュータに接続され、ブラウザからこれらのマイクに アクセスできること 。 Amazon Transcribe の権限を持つ AWS アカウント。例として、Amazon Transcribe には次の AWS Identity and Access Management ポリシーを使用できます。 { "Version": "2012-10-17", "Statement": [ { "Sid": "DemoWebAudioAmazonTranscribe", "Effect": "Allow", "Action": "transcribe:StartStreamTranscriptionWebSocket", "Resource": "*" } ] } アプリケーションを起動する アプリケーションを起動するには、以下の手順を実行してください。 コードをダウンロードしたルートディレクトリに移動します。 env.sample ファイルから AWS アクセスキーを設定するための .env ファイルを作成します。 パッケージをインストールし、 bun install を実行します（Node.js を使用している場合は node install を実行します）。 Web サーバーを起動し、 bun dev を実行します（Node.js を使用している場合は node dev を実行します）。 ブラウザで http://localhost:5173/ を開きます。. 2つのマイクを接続して http://localhost:5173 で実行されているアプリケーション コードの説明 このセクションでは、実装のための重要なコード部分を解説します。 最初のステップは、ブラウザ API navigator.mediaDevices.enumerateDevices() を使用して、接続されているマイクの一覧を取得することです。 const devices = await navigator.mediaDevices.enumerateDevices(); return devices.filter((d) => d.kind === 'audioinput'); 次に、接続されているマイクごとにMediaStreamオブジェクトを取得する必要があります。これは、ユーザーのメディアデバイス（カメラやマイクなど）へのアクセスを可能にする navigator.mediaDevices.getUserMedia() APIを使用して実行できます。その後、これらのデバイスからの音声または動画データを表すMediaStreamオブジェクトを取得できます。 const streams = [] const stream = await navigator.mediaDevices.getUserMedia({ audio: { deviceId: device.deviceId, echoCancellation: true, noiseSuppression: true, autoGainControl: true, }, }) if (stream) streams.push(stream) 複数のマイクからの音声を結合するには、音声処理用の AudioContextインターフェース を作成する必要があります。この AudioContext 内で、 ChannelMergerNode を使用して、異なるマイクからの音声ストリームを結合できます。 connect(destination, src_idx, ch_idx) メソッドの引数は次のとおりです。 destination – 出力先。この例では mergerNode です。 src_idx – ソースチャンネルのインデックス。この例では両方とも0です（各マイクがシングルチャンネルの音声ストリームであるため）。 ch_idx – 出力先のチャンネルインデックス。この例ではそれぞれ0と1で、ステレオ出力を作成します。 // audioContextのインスタンス const audioContext = new AudioContext({ sampleRate: SAMPLE_RATE, }) // マイクのストリームデータを処理するために使用 const audioWorkletNode = new AudioWorkletNode(audioContext, 'recording-processor', {...}) // microphone A const audioSourceA = audioContext.createMediaStreamSource(mediaStreams[0]); // microphone B const audioSourceB = audioContext.createMediaStreamSource(mediaStreams[1]); // 2つの入力用のオーディオノード const mergerNode = audioContext.createChannelMerger(2); // オーディオ ソースを mergerNode の宛先に接続。 audioSourceA.connect(mergerNode, 0, 0); audioSourceB.connect(mergerNode, 0, 1); // mergerNodeをAudioWorkletNodeに接続 merger.connect(audioWorkletNode); そのマイクデータは AudioWorklet tで処理され、指定された録音フレーム数ごとにデータメッセージが送信されます。これらのメッセージには、Amazon Transcribeに送信するPCM形式でエンコードされた音声データが含まれます。 p-event ライブラリを使用すると、Workletからのイベントを非同期的に反復処理できます。このWorkletの詳細については、この記事の次のセクションで説明します。 import { pEventIterator } from 'p-event' ... // ワークレットを登録する try { await audioContext.audioWorklet.addModule('./worklets/recording-processor.js') } catch (e) { console.error('Failed to load audio worklet') } // 非同期イテレータ const audioDataIterator = pEventIterator<'message', MessageEvent<AudioWorkletMessageDataType>>( audioWorkletNode.port, 'message', ) ... // AsyncIterableIterator: ワークレットが `SHARE_RECORDING_BUFFER` メッセージを含むイベントを発行するたびに、このイテレータは必要な AudioEvent オブジェクトを返す。 const getAudioStream = async function* ( audioDataIterator: AsyncIterableIterator<MessageEvent<AudioWorkletMessageDataType>>, ) { for await (const chunk of audioDataIterator) { if (chunk.data.message === 'SHARE_RECORDING_BUFFER') { const { audioData } = chunk.data yield { AudioEvent: { AudioChunk: audioData, }, } } } } Amazon Transcribeへのデータのストリーミングを開始するには、作成したイテレータを使用し、 NumberOfChannels: 2 と EnableChannelIdentification: true を有効にしてデュアルチャネルの文字起こしを有効にします。詳細については、 AWS SDK StartStreamTranscriptionCommand のドキュメントをご覧ください。 import { LanguageCode, MediaEncoding, StartStreamTranscriptionCommand, } from '@aws-sdk/client-transcribe-streaming' const command = new StartStreamTranscriptionCommand({ LanguageCode: LanguageCode.EN_US, MediaEncoding: MediaEncoding.PCM, MediaSampleRateHertz: SAMPLE_RATE, NumberOfChannels: 2, EnableChannelIdentification: true, ShowSpeakerLabel: true, AudioStream: getAudioStream(audioIterator), }) リクエストを送信すると、オーディオストリームデータと Amazon Transcribe の結果を交換するための WebSocket 接続が作成されます。 const data = await client.send(command) for await (const event of data.TranscriptResultStream) { for (const result of event.TranscriptEvent.Transcript.Results || []) { callback({ ...result }) } } result オブジェクトには、 ch_0 や ch_1 など、マイクのソースを識別するために使用できる ChannelId プロパティが含まれます。 詳細: オーディオワークレット オーディオワークレットは別スレッドで実行することで、非常に低レイテンシなオーディオ処理を実現します。実装とデモのソースコードは、 public/worklets/recording-processor.js ファイルにあります。 今回のケースでは、このワークレットを使用して主に2つのタスクを実行します。 mergerNode のオーディオを反復処理します。このノードは両方のオーディオチャンネルを含み、ワークレットへの入力となります。 mergerNode ノードのデータバイトを PCM 符号付き 16 ビット リトルエンディアン オーディオ形式にエンコードします。この処理は、反復処理ごとに、またはアプリケーションにメッセージペイロードを送信する必要があるときに行います。 これを実装するための一般的なコード構造は次のとおりです。 class RecordingProcessor extends AudioWorkletProcessor { constructor(options) { super() } process(inputs, outputs) {...} } registerProcessor('recording-processor', RecordingProcessor) このWorkletインスタンスには、 processorOptions 属性を使用してカスタムオプションを渡すことができます。デモでは、新しいメッセージペイロードを送信するタイミングを決定するためのビットレートガイドとして、 maxFrameCount: (SAMPLE_RATE * 4) / 10 を設定しています。メッセージの例は以下のとおりです。 this.port.postMessage({ message: 'SHARE_RECORDING_BUFFER', buffer: this._recordingBuffer, recordingLength: this.recordedFrames, audioData: new Uint8Array(pcmEncodeArray(this._recordingBuffer)), // PCM encoded audio format }) 2チャンネルのPCMエンコード 最も重要なセクションの一つは、2チャンネルのPCMエンコード方法です。 Amazon Transcribe APIリファレンス のAWSドキュメントによると、AudioChunkは Duration (s) * Sample Rate (Hz) * Number of Channels * 2 で定義されます。2チャンネルの場合、16000Hzで1秒は、1 * 16000 * 2 * 2 = 64000 bytesです。エンコード関数は以下のようになります。 // 入力は配列であり、各要素は AudioWorkletProcessor からの -1.0 ～ 1.0 の Float32 値を持つチャネルであることに注意してください。 const pcmEncodeArray = (input: Float32Array[]) => { const numChannels = input.length const numSamples = input[0].length const bufferLength = numChannels * numSamples * 2 // 2 bytes per sample per channel const buffer = new ArrayBuffer(bufferLength) const view = new DataView(buffer) let index = 0 for (let i = 0; i < numSamples; i++) { // 各チャンネルごとにエンコード for (let channel = 0; channel < numChannels; channel++) { const s = Math.max(-1, Math.min(1, input[channel][i])) // 32 ビット浮動小数点数を 16bit PCM オーディオ波形サンプルに変換します。 // 最大値: 32767 (0x7FFF)、最小値: -32768 (-0x8000) view.setInt16(index, s < 0 ? s * 0x8000 : s * 0x7fff, true) index += 2 } } return buffer } オーディオデータブロックの処理方法の詳細については、 AudioWorkletProcessor: process() ソッドを参照してください。PCM形式のエンコードの詳細については、 Multimedia Programming Interface and Data Specifications 1.0 を参照してください。 結論 この記事では、ブラウザの Web Audio API と Amazon Transcribe ストリーミングを使用して、リアルタイムのデュアルチャネル文字起こしを実現するウェブアプリケーションの実装の詳細について説明しました。 AudioContext 、 ChannelMergerNode 、 AudioWorklet を組み合わせることで、2 つのマイクからの音声データをシームレスに処理およびエンコードし、Amazon Transcribe に送信して文字起こしを行うことができました。特に AudioWorklet を使用することで、低レイテンシーの音声処理を実現し、スムーズで応答性の高いユーザーエクスペリエンスを提供できました。 このデモを基に、会議の録音から音声制御インターフェースまで、幅広いユースケースに対応する、より高度なリアルタイム文字起こしアプリケーションを作成できます。 ぜひこのソリューションをお試しいただき、コメント欄にフィードバックをお寄せください。 原文は こちら です。 About the Author Jorge Lanzarotti  is a Sr. Prototyping SA at Amazon Web Services (AWS) based on Tokyo, Japan. He helps customers in the public sector by creating innovative solutions to challenging problems.

6 月 17 日、 AWS Backup 論理エアギャップボールト と マルチパーティ承認 を統合する新機能の一般提供についてお知らせします。これにより、不注意または悪意のあるイベントにより AWS アカウントにアクセスできなくなった場合でもバックアップにアクセスできるようになります。AWS Backup は、AWS のサービスとハイブリッドワークロードのデータ保護を一元化および自動化するフルマネージドサービスです。中核となるデータ保護機能、ランサムウェア復旧機能、データ保護ポリシーと運用に関するコンプライアンス情報と分析を提供します。 バックアップ管理者は、AWS Backup 論理エアギャップボールトを使用して、アカウントや組織間でバックアップを安全に共有し、バックアップストレージを論理的に分離し、ダイレクトリストアをサポートして、不注意または悪意のあるイベントが発生した場合の復旧時間を短縮できます。ただし、悪意のある攻撃者や意図しない攻撃者がバックアップアカウントまたは組織の管理アカウントへのルートアクセスを取得した場合、論理エアギャップボールトに安全に保存されているにもかかわらず、バックアップには突然アクセスできなくなります。従来のアカウント復旧はサポートチャネルを通じて行う必要がありましたが、マルチパーティ承認を受けた AWS Backup では復旧ツールにすぐにアクセスできるため、解決までの時間を短縮し、復旧スケジュールをより細かく管理できます。 AWS Backup の論理エアギャップボールトに対するマルチパーティ承認により、AWS アカウントに完全にアクセスできなくなった場合でもアプリケーションデータを復旧するための保護レイヤーが強化されます。マルチパーティ承認を使用すると、組織内の信頼できる個人で構成される承認チームを作成し、論理エアギャップボールトに関連付けることができます。不注意または悪意のある行為によって AWS アカウントからロックアウトされた場合は、 AWS Organizations アカウント外のアカウントも含め、どのアカウントからでもボールトの共有を許可するよう承認チームにリクエストできます。承認されると、バックアップへのアクセスが許可され、復旧プロセスを開始できます。 仕組み AWS Backup の論理エアギャップボールトのマルチパーティ承認は、論理エアギャップボールトのセキュリティとマルチパーティ承認のガバナンスを組み合わせることで、AWS アカウントが侵害された場合でも機能する復旧メカニズムを構築します。その仕組みは次のとおりです。 1.承認チームの作成 まず、AWS Organizations 管理アカウントで承認チームを作成します。管理アカウントが新しい場合は、承認チームを作成する前に、まず AWS Identity and Access Management (IAM) Identity Center インスタンスを作成します。承認チームは、ボールト共有リクエストを承認する権限を持つ信頼できる個人 (IAM Identity Center ユーザー) で構成されます。各承認者は、新しい承認ポータルを通じて承認チームに参加するための招待状を受け取ります。 2.ボールトアソシエーション 承認チームがアクティブになったら、 AWS Resource Access Manager (AWS RAM) を使用して論理エアギャップボールトを所有するアカウントと承認チームを共有し、任意のアカウントからの承認リクエストから保護します。その後、バックアップ管理者は、この承認チームを新規または既存の論理エアギャップボールトに関連付けることができます。 3.侵害からの保護 AWS アカウントが乗っ取られたり、アクセスできなくなったりした場合は、別のアカウント (クリーンリカバリアカウント) からバックアップへのアクセスをリクエストできます。このリクエストには、 論理エアギャップボールトの Amazon リソースネーム (ARN) が arn:aws:backup:<region>:<account>:backup-vault:<name> の形式で含まれ、オプションのボールト名とコメントも含まれています。 4.マルチパーティ承認 リクエストは承認チームに送信され、承認チームは承認ポータルでリクエストをレビューします。必要最小限数の承認者がリクエストを承認すると、ボールトはリクエスト元のアカウントと自動的に共有されます。すべてのリクエストと承認は AWS CloudTrail に包括的に記録されます。 5.復旧プロセス アクセスが許可されると、侵害されたアカウントが修復されるのを待たずに、新しいリカバリアカウントのデータの復元またはコピーをすぐに開始できます。 この方法では、AWS アカウントの認証情報とは完全に独立した、バックアップにアクセスして復元するための完全に別の認証パスが提供されます。攻撃者がお客様のアカウントへのルートアクセス権を持っていたとしても、承認チームによる復旧プロセスを防ぐことはできません。 1.論理エアギャップボールトの新規作成 新しい論理エアギャップボールトを作成するには、 名前 、 タグ (オプション)、 ボールトロックプロパティ を指定します。 2.承認チームの割り当て ボールトが作成されたら、[ 承認チームの割り当て ] を選択して既存の承認チームに割り当てます。 ドロップダウンメニューから既存の承認チームを選択し、[ 送信 ] を選択して割り当てを確定します。 これで、承認チームが論理エアギャップボールトに割り当てられるようになりました。 便利なヒント 実際に緊急事態が発生する前に、復旧プロセスをテストすることが不可欠です。 別の AWS アカウントから、AWS Backup コンソールまたは API を使用して、ボールト ID と ARN を指定して、論理エアギャップボールトの共有をリクエストします。 承認チームにリクエストの承認を要請します。 承認されたら、テストアカウントのボールトからバックアップにアクセスして復元できることを確認します。 ベストプラクティスとして 、 AWS Backup Audit Manager を使用して承認チームの状態を定期的に監視し、承認基準を満たす十分な数のアクティブな参加者がいることを確認します。 クラウドガバナンスを強化するためのマルチパーティ承認 6 月 17 日、AWS アカウント管理者が製品にマルチパーティ承認を追加するために使用できる新機能の一般提供についても発表します。この投稿で強調しているように、AWS Backup はこの機能を統合した最初のサービスです。マルチパーティ承認により、管理者は分散型のレビュープロセスを使って、アプリケーション所有者が機密性の高いサービス業務を保護できるようすることができます。 便利なヒント マルチパーティ承認には、いくつかの重要なセキュリティ上の利点があります。 分散型の意志決定により、単一障害点を排除 AWS CloudTrail 統合による完全な監査可能性 認証情報の漏洩に対する保護 コンプライアンス重視の業務のための正式なガバナンス 統合サービス全体で一貫した承認エクスペリエンス 今すぐご利用いただけます マルチパーティ承認は、現在 AWS Organizations が利用可能なすべての AWS リージョン でご利用いただけます。AWS Backup の論理エアギャップボールトのマルチパーティ承認は、 AWS Backup が利用可能なすべての AWS リージョンで利用できます。 – Veliswa 原文は こちら です。

AWS Amplify Hosting では、決められたインスタンスを使用してウェブアプリケーションを構築してきました。アプリケーションが複雑化し、依存関係管理、アセット最適化、包括的なテストに集中的なビルドプロセスが必要とされるようになると、開発者は生産性とデプロイ速度を維持するために、より強力なビルド環境を必要とするようになります。 Amplify Hosting のビルド環境用のインスタンスをカスタマイズできるようになったことを喜んでお知らせします。この更新により、2 つの新しいインスタンスサイズ (Large, XLarge) が追加され、メモリと CPU リソースが増強されました。開発チームは、これで特定のニーズに合わせて構築リソースをスケーリングできるようになりました。これは特に、大規模な依存関係ツリーの処理、多数の静的アセットの処理、TypeScript コンパイルやパラレルなテストフレームワークのような、メモリ集約的な操作の実行時に有用です。 今までのビルド環境用のインスタンスの課題 大規模なアプリケーションを構築し、重たいワークロードを実行しているお客様は、 ビルド時間が長くなり、メモリエラーのため CI/CD が遅くなりビルド失敗が発生する ことがあります。開発チームが Amplify Hosting を導入する際、さまざまなワークロードに対応できるスケーラブルなビルド環境を求めています。ビルド時間の最適化は存在しますが、8GiB メモリと 4 vCPU のインスタンスサイズのコンテナ構成では、アプリケーションの拡大に限界があります。物理メモリに比べ、仮想メモリ (スワップスペース) の性能ペナルティは非常に大きく、固定環境内でコンピューティング容量やストレージを拡張する効果的な手段はありません。これらのハードウェア上の制約により、ソフトウェアの最適化だけでは根本的な障壁を乗り越えることはできません。 カスタマイズ可能なビルドインスタンスの紹介 Amplify Hosting の新しいカスタマイズ可能なビルドインスタンスにより、開発者はアプリケーションのニーズに最適なコンピューティングリソースを選択できるようになりました。これにより、リソースの制約を排除して、予測可能なビルドパフォーマンスを実現できます。Standard ビルドインスタンスに加えて、Large と XLarge のインスタンスを導入しました。次の表は、Amplify Hosting のすべてのビルドインスタンスオファリングの仕様をまとめたものです。 ビルドインスタンスの仕様 ビルド インスタンス vCPU 数 メモリ ディスク領域 Standard 4 8 GiB 128 GB Large 8 16 GiB 128 GB XLarge 36 72 GiB 256 GB アプリ作成時または既存のアプリを後から更新する際に、アプリケーションレベルでビルドインスタンスを構成できます。更新された構成は、アプリのすべてのブランチに適用され、ビルド間でアプリのビルドインスタンスサイズを変更します。ビルドをトリガーしたとき、ブランチに関係なく、アプリのビルドでは、アプリレベルで構成したビルドインスタンスサイズが使用されます。新しいアプリを作成したり、既存のアプリを更新したりするときに、ビルドインスタンスサイズを構成できます。 Amplifyコンソールを通じて新しいアプリのビルドインスタンスサイズをカスタマイズするには ：アプリ設定ステップの間に、下にスクロールして「 詳細設定 」をクリックします。ドロップダウンリストから、アプリに設定したいビルドイメージを選択します。 図1 – 新しいアプリのビルドインスタンスサイズの設定 既存のアプリのビルドインスタンスサイズを Amplify コンソールから変更するには : アプリに移動し、 ホスティングタブ を開いてから、 ビルドの設定 を選択します。 詳細設定 までスクロールダウンし、 編集 をクリックします。ドロップダウンから、アプリをアップデートしたい ビルドイメージ を選択してください。 図2 – 既存アプリのビルドインスタンスの変更 注 : ビルドインスタンスの割り当て処理には、ビルドが開始される前に追加のプロビジョニング時間が必要になる場合があります。大規模なインスタンス、特に XLarge の場合、このオーバーヘッドの時間によりビルド開始前に遅延が発生することがあります。ただし、課金されるのはビルド時間のみで、オーバーヘッド時間は課金されません。 パフォーマンステストの説明 次に、100 を超える静的ページを生成する Next.js アプリケーションを使用して、より強力なインスタンスの価値を実証します。このアプリを Amplify Hosting にデプロイする手順をガイドし、メモリ関連のビルド失敗をデバッグする方法を説明し、アプリケーションのメモリ要件を満たすためにビルドインスタンスをアップグレードする方法をご紹介します。 まず、デフォルト設定を使用して静的アプリを Amplify Hosting にデプロイします。 図3 – アプリページを確認して作成する デプロイが始まると、Amplify Hosting がリソースをプロビジョニングし、デプロイを進めます。 図4 – デプロイ中 大容量メモリの使用のためのアプリケーションの構成 デプロイが開始されると、最初のビルドで JavaScript のヒープメモリ不足のエラーが発生します。ランタイム環境がヒープメモリを要求すると、ホストの OS がメモリを割り当てます。JavaScript の Node.js V8 ランタイム環境には、ホストのメモリサイズなどの複数の条件によりデフォルトのヒープサイズ制限が適用されています。そのため、Standard と Large インスタンスではデフォルトの Node.js ヒープサイズが 2096MB ですが、XLarge インスタンスでは 4144 MB になっています。 図5 – ヒープサイズのメモリ制限により Deployment 1 が失敗しました Node.js のデフォルト ヒープメモリ制限の問題を解決するには、ヒープサイズを増やす必要があります。アプリは 8 GiB のメモリを持つ Standard ビルドインスタンスを使用しているため、ヒープサイズを 7000 MB (約 7 GB) に増やす必要があります。これにより、他のプロセスで使用するために、オペレーティングシステム用に約 1 GB のメモリが残ります。そうすれば、意図しない動作を回避できます。 次に、以下のコマンドでビルド仕様を変更し、Node.js のヒープメモリ制限を増やします。 export NODE_OPTIONS ='--max-old-space-size = 7000' 代わりに、 NODE_OPTIONS はアプリ内の環境変数として設定することもできます。詳細については、ドキュメントを参照してください。 これらの変更に対応するように、ビルド仕様ファイルも次のように更新します: version: 1 frontend: phases: preBuild: commands: # Set the heap size to 7000 MB - export NODE_OPTIONS ='--max-old-space-size = 7000' # To check the heap size memory limit in MB - node -e "console.log('Total available heap size (MB):', v8.getHeapStatistics().heap_size_limit / 1024 / 1024)" - npm ci --cache .npm --prefer-offline build: commands: - npm run build artifacts: baseDirectory: .next files: - '**/*' cache: paths: - .next/cache/**/* - .npm/**/* 変更したヒープサイズで新しいデプロイをトリガするには、Deployment ページに移動し、Redeploy this version ボタンをクリックします。 しかし、アプリのビルドはまだ失敗します。今度は「Total available heap size (MB): 7048」というログが表示され、ヒープサイズが増えたことを確認できます。興味深いことに、SIGKILL ディレクティブも表示され、オペレーティングシステムがビルドプロセスを強制終了したことがわかります。これは別のメモリ不足エラーを示しています。 図6 – メモリ不足のためデプロイ2が失敗しました ビルドインスタンスのアップグレード 標準インスタンスのメモリ制限は 8 GiBであり、ヒープサイズをこの制限に近づけて増やしたにもかかわらず、依然としてメモリ不足になっています。この問題を解決するために、ビルドインスタンスを Large にアップグレードします。これにより、ビルドプロセスにより多くのメモリを割り当てることができます。 以下のようにビルド仕様ファイルを更新して、Large インスタンスにデプロイします： version: 1 frontend: phases: preBuild: commands: # Set the heap size to 14000 MB - export NODE_OPTIONS ='--max-old-space-size = 14000' # To check the heap size memory limit in MB - node -e "console.log('Total available heap size (MB):', v8.getHeapStatistics().heap_size_limit / 1024 / 1024)" - npm ci --cache .npm --prefer-offline build: commands: - npm run build artifacts: baseDirectory: .next files: - '**/*' cache: paths: - .next/cache/**/* - .npm/**/* ホスティングタブ を開き、 ビルド設定 を選択して、ビルドインスタンスを更新します。その後、 詳細設定 までスクロールダウンして編集をクリックします。ドロップダウンから、 ビルドイメージ を「Large」に選択します。 図7 – ビルドインスタンスのサイズを「Large」に更新 次に、Deployment トページで「 このバージョンを再デプロイ 」をクリックして、Large インスタンスで新しい Deployment を作成します。また、ビルドログの最初の行にビルドインスタンスの仕様が表示されていることに気付きます。 図8 – Large ビルドインスタンスで進行中のデプロイ3 アプリが正常にデプロイされたことが確認できます。 図9 – アプリのデプロイ完了 まとめ このブログでは、ビルドインスタンスサイズを設定するためのアプリワークフローの作成と更新方法、および Amplify Hosting でホストされているプロジェクトのメモリ問題を解決する方法について探ってきました。ビルドインスタンスサイズについてさらに詳しく知り、この機能についてもっと学ぶには、Amplify Hosting のドキュメントをご覧ください。ビルドインスタンスの料金に関する情報は、料金ページでご確認いただけます。 著者について Sohaib Uddin Syed, Software Engineer, Amplify Hosting Sohaib Uddin Syed はAWS Amplify Hostingでソフトウェア開発エンジニアとして働いています。Sohaib は AWS のスケーラビリティを活用してフロントエンドのウェブアプリケーションを構築できるようにするソフトウェアを開発しています。空き時間には、サッカー観戦や料理、家族や友人との時間を楽しんでいます。 Angela Zheng, Software Engineer, Amplify Hosting Angela Zheng は、AWS Amplify Hosting のソフトウェア開発エンジニアです。彼女は、あらゆる規模の開発者がフロントエンド Web アプリケーションのホスティングを簡単かつ分かりやすく行えるような機能の開発に取り組んでいます。彼女の自由時間には、ダンスやバレーボールを楽しんだり、キッチンでレシピを試したり、旅行したりしています。 Matt Auerbach Matt Auerbach はニューヨーク市を拠点とする AWS Amplify チームのプロダクトマネージャーです。彼は開発者に製品やサービスについて教育し、サポートやフィードバックの主要な窓口として活動しています。マットは穏やかな性格のプログラマーで、テクノロジーを使って問題を解決し、人々の生活をより便利にすることを楽しんでいます。夜になっても…まあ、ほぼ同じことをしています。マットは X で @mauerbacとして見つけることができます。彼は以前、Twitch、Optimizely、Twilioで働いていました。 翻訳者について 稲田大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。普段は製造業のお客様を支援しています。年明け 4 kg 太ったので、ダイエットに励んでいます。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログなどを執筆しています。

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。いよいよ今週 AWS Summit Japan が幕張メッセで開催されます。参加が初めての方、こちらに 初めてでも楽しめるAWS Summit Japan ガイド が公開されていますので是非チェックしてみてください。Summit では生成AI関連では AIエージェント をテーマとしたハッカソンが企画されています。多数の応募チームの中から選出された14組がAIエージェントを使ったハッカソンで競い合います。審査員として QuizKncok 伊沢拓司氏、鶴崎修功氏も登場しますので楽しみです。ちなみに私もExpoエリアのブースに立っておりますので見つけた方は声かけてください。 では今週も生成 AI with AWS界隈のニュースを見ていきましょう！ さまざまなニュース AWS生成AI国内事例ブログ「株式会社フレイ・スリー様の AWS 生成 AI 活用事例：Amazon Bedrockを活用し、企業の動画活用における課題特定と解決策提示の自動化機能を構築。サポート部門の業務効率化を実現。」 株式会社フレイ・スリー様は、AI動画生成配信プラットフォーム「1ROLL」を提供する企業として、Amazon Bedrock を活用した新しい機能開発に取り組みました。動画マーケティングにおいて、制作後の運用面での課題に着目し、Amazon Bedrock Claude3.5 Sonnet v2 と Knowledge Bases を組み合わせたソリューションを構築。これにより、動画の視聴データを自動で分析し、わずか15秒で課題の特定から解決策の提示までを完了できるようになりました。この取り組みにより、サポート部門の業務効率が大幅に改善され、顧客は自身で動画活用の改善サイクルを回すことが可能になりました。 ブログ記事「Amazon Q Developer の IDE で Model Context Protocol を使用し、コンテキストに応じた開発プロセスを実現する」 Amazon Q Developer に新たに追加されたModel Context Protocol (MCP) のサポートにより、開発者の作業効率が大幅に向上します。MCP を通じて Jira や Figma などの外部ツールと直接連携することで、開発者は IDE からプロジェクト管理やデザインツールの情報にシームレスにアクセスできるようになります。例えば、Jira のタスクから Figma のデザイン仕様まで、必要な情報を自動的に取得し、コンテキストを維持したままコーディング作業を進めることができます。これにより、ツール間の行き来や情報のコピー&ペーストといった手作業が不要になり、開発プロセス全体が効率化されます。さらに、タスクの進捗更新やコメント追加などもIDE内から直接実行できるため、開発者は本来の作業に集中できる環境が整います。スクリーンショット付きで分かりやすくまとめているので是非チェックしてみてください。 ブログ記事「GENIAC プログラムから学んだ基盤モデル構築支援の教訓」 AWSはGENIAC第2期において、12の事業者に対して大規模な計算リソースと技術支援を提供しました。具体的には、127台のAmazon EC2 P5インスタンスと24台のTrn1インスタンスをデプロイし、6ヶ月にわたる基盤モデル開発を支援しました。支援の要となったのは、クロスファンクショナルなチーム体制、効果的なコミュニケーション戦略、そして事前検証済みのリファレンスアーキテクチャの提供です。さらに、詳細なデプロイメントガイドとワークショップを通じて知識共有を行い、参加企業が効率的に基盤モデル開発に取り組める環境を整備しました。この取り組みから、基盤モデル開発は単なるハードウェアの問題ではなく、組織的な課題であることが明らかになりました。また、適切なサポート体制と再現可能なテンプレート、チーム間の効果的な連携があれば、小規模なチームでも大規模な基盤モデル開発が実現可能であることも実証されました。 ブログ記事「AWS 環境の可視化を加速する Diagram-as-code とAmazon Bedrockの活用」 AWS のインフラ構成を可視化する際、多くの組織では構成図の作成・更新に多大な労力がかかっているのが現状です。本記事では、Amazon Bedrock と Diagram-as-code を組み合わせることで、この課題を解決する新しいアプローチを紹介しています。Diagram-as-code は、CloudFormation テンプレートなどの構造化されたテキストからアーキテクチャ図を自動生成できるツールです。これに Amazon Bedrock を組み合わせることで、ユーザーの自然言語での要件を理解し、データフローやセキュリティ境界といった CloudFormation テンプレートには含まれていない要素も含めたアーキテクチャ図を効率的に生成できます。 この手法は、中間ファイルを生成してから図を作成するアプローチを採用しており、生成された図の修正が容易で、かつ中間ファイルの検証が可能という利点があります。また、CIパイプラインへの組み込みも容易で、システムの変更に応じて自動的に最新の構成図を維持することができます。 ブログ記事「Amazon Novaを使用した会議の要約とアクションアイテムの抽出」 このブログ記事では、Amazon Novaファミリーの各理解モデルを使用して、会議の要約とアクションアイテムを自動的に抽出する方法について解説しています。Amazon Novaモデルは、Nova Micro(テキストのみ)、Nova Lite(マルチモーダル)、Nova Pro(速度と知能のバランス)、Nova Premier(最高性能)の4つのレベルで構成されており、Amazon Bedrockを通じて利用可能です。評価実験では、QMSumデータセットを使用して各モデルのパフォーマンスを検証し、Nova Premierが最も高い忠実度スコアを達成しましたが、より小規模なモデルでも十分な性能と高速な処理時間を実現できることが示されました。このソリューションにより、企業は会議の内容を効率的に構造化された形式で記録・活用でき、特にプロジェクト管理、カスタマーサポート、法務やコンプライアンスなどの分野で大きな価値を提供します。各モデルのスコアと処理速度の比較がされており、モデル選択の参考になると思います。 サービスアップデート 欧州（ロンドン）リージョンのAmazon Bedrock で Anthropic Claude 3.7 Sonnet が利用可能に 欧州（ロンドン）リージョンで Claude 3.7 Sonnet が利用可能になりました。このモデルの特徴は、迅速な応答と詳細な思考プロセスの両方を提供できる点です。標準モードと拡張思考モードを備え、ユーザーは用途に応じて処理時間と回答の質のバランスを調整できます。コーディングや数学、物理学など幅広いタスクで高いパフォーマンスを発揮し、トークン制限によるコスト管理も可能です。 P5 および P5en インスタンス向けの1年間の EC2 Instance Savings Plan が利用可能に EC2 の GPU 搭載インスタンスである P5 および P5en インスタンスに対して、1年間の EC2 Instance Savings Plan の提供が開始されました。このプランを利用することで、オンデマンド料金と比較して最大40%のコスト削減が可能となります。従来は3年間の契約のみでしたが、より柔軟な1年間の選択肢が追加されたことで、ビジネスニーズに合わせて最適な期間を選択できるようになりました。特に生成AIやディープラーニングの開発・運用を行うユーザーにとって、NVIDIA H100 Tensor Core を搭載した P5 インスタンスの Savings Plan は大規模なAIモデルのトレーニングや推論処理をより費用対効果の高い方法で実行することが可能になり、AI開発プロジェクトの期間が1年程度の場合でも、コスト最適化の恩恵を受けることができるようになります。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎(Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近、麻辣醤にハマっています。

6 月 17 日、 AWS Shield ネットワークセキュリティディレクター (プレビュー) を発表できることを嬉しく思います。これは、SQL インジェクションや分散型サービス拒否 (DDoS) イベントなどの脅威に関連する設定上の問題の特定を簡素化し、修正を提案する機能です。この機能は、ネットワークリソース、接続、設定を識別して分析します。これらを AWS のベストプラクティスと比較して、保護が必要なリソースを浮き彫りにしたネットワークトポロジを作成します。 今日の組織は、強固なネットワークセキュリティ体制を維持する上で重大な課題に直面しています。セキュリティチームは、環境内のすべてのリソースを効率的に検出し、これらのリソースがどのように相互接続されているかを把握し、どのセキュリティサービスが現在設定されているかを特定するのに苦労することがよくあります。さらに、リソースが AWS のベストプラクティスに照らしてどの程度適切に設定されているかを判断するには、かなりの専門知識と努力が必要であることがわかっています。多くのチームが、自社のアプリケーションを一般的な脅威や新たな脅威から保護するのに最適なネットワークセキュリティサービスとルールセットを特定するのが難しいと感じています。 AWS Shield ネットワークセキュリティディレクターは、3 つの主要機能を通じてこれらの課題に対処します。まず、包括的な分析を実行して、AWS アカウント全体のリソースを検出し、リソース間の接続を識別し、現在どのネットワークセキュリティサービスと設定が実施されているかを判断します。次に、AWS ネットワークセキュリティのベストプラクティスと脅威インテリジェンスに基づいて、重大度レベル別にリソースに優先順位を付けます。最後に、リソースを保護するための AWS WAF 、 Amazon Virtual Private Cloud (Amazon VPC) セキュリティグループ 、Amazon VPC ネットワークアクセスコントロールリスト (ACL) など、適切な AWS セキュリティサービスを実装するためのステップバイステップの手順など、具体的な修復に関する推奨事項を提供します。 このサービスは、インターネットからの脅威からアプリケーションを保護したり、ポート、プロトコル、またはIP アドレス範囲に基づいてリソースへの人間のアクセスを制御したりするなど、重要なネットワークセキュリティユースケースをサポートします。ネットワーク分析を行って資産を発見し、保護が必要なリソースを特定するための時間のかかる手動プロセスを排除する分析を行います。このサービスでは、ネットワークコンテキストと AWS ベストプラクティスの遵守に基づいてセキュリティ検出結果に重大度を割り当てることにより、リソースの優先順位付けを行い、最も重要なことに集中できるようにします。さらに、どのサービスと設定がそれぞれのセキュリティギャップに対処するかについての具体的なガイダンスとともに、実行可能な推奨事項も提供します。また、 AWS マネジメントコンソール やチャットアプリケーションの Amazon Q Developer 内の AWS Shield ネットワークセキュリティディレクターから、自然言語で回答を得ることもできます。 AWS Shield ネットワークセキュリティディレクターの使用を開始する AWS Shield ネットワークセキュリティディレクターを使用するには、AWS リソースのネットワーク分析を開始する必要があります。 AWS WAF & Shield コンソール に移動し、ナビゲーションペインの [ AWS Shield ネットワークセキュリティディレクター ] で [ 使用を開始 ] を選択します。[ 使用を開始 ] を選択すると、設定ページが表示されます。このページでは、最初のネットワーク分析の実行方法を選択できます。つまり、すべてのサポート対象リージョンの検出結果を評価することも、現在のリージョンのみを評価することもできます。[ ネットワーク解析を開始 ] を選択します。 分析が完了すると、ダッシュボードページには、重大度レベル別のリソースタイプの内訳と、そのリソースに関連するネットワークセキュリティ検出結果の最も一般的なカテゴリが表示されます。リソースはタイプと重大度レベル (重要、高、中、低、参考) ごとに分類されているため、早急な対応が必要な領域を簡単に特定できます。 次に、「 リソース 」セクションを調べて、アセットの分布を把握し、環境内の重大度レベルでフィルタリングします。[ リソース概要 ] を使用して特定の重大度レベルを確認できます。これにより、関連する重大度レベルのフィルターを含む [ ネットワークセキュリティディレクター ] の下の [ リソース ] にリダイレクトされます。重大度が「 中 」のリソースを選択します。 特定のリソースを選択すると、そのリソースが他のリソースや関連する検出結果とどのように接続されているかを示すネットワークトポロジマップが表示されます。この可視化は、セキュリティ設定の潜在的な影響を理解し、露出されたパスを特定するのに役立ちます。「すべてのポートで無制限のインバウンドアクセス（0.0.0.0/0）を許可する」などの詳細な検出結果を重大度評価とともに確認します。 次に、[ ネットワークセキュリティディレクター ] の [ 検出結果 ] に移動すると、一般的な設定の問題が表示されます。検出結果ごとに、詳細な情報と推奨される修復手順を受け取ります。このサービスでは、検出結果の重大度（高、中、低）を評価して、対応の優先順位付けに役立てています。「CloudFront オリジンは CloudFront 保護なしでもインターネットにアクセスできる」といった重大度が重要な検出結果や、「すべてのポートで無制限のインバウンドアクセス (0.0.0.0/0) を許可する」といった重大度の高い検出結果が最初に表示され、次に重大度が中および低の問題が続きます。 AWS マネジメントコンソールとチャットアプリケーションの Amazon Q Developer 内の AWS Shield ネットワークセキュリティディレクターを使用して、ネットワークセキュリティ設定を自然言語で分析できます。例えば、「CloudFront ディストリビューションにネットワークセキュリティの問題はありますか?」や「ボットやスクレイパーに対して脆弱なリソースはありますか?」と尋ねることができます。 この統合により、セキュリティチームは広範なドキュメントを参照しなくても、セキュリティ体制を迅速に把握し、ベストプラクティスの実装に関するガイダンスを得ることができます。 この機能を調べるために、「私が抱えている最も重要なネットワークセキュリティの問題は何か」と尋ねます。「 Amazon Q で探索 」セクションにあります。Amazon Q はネットワークセキュリティ設定を分析し、AWS 環境のセキュリティ評価に基づいて応答を生成します。 このようにネットワークセキュリティを包括的に把握することで、新たな脅威に対する防御を強化するためのデータ主導型の意志決定が可能になります。 プレビューをお試しください AWS Shield ネットワークセキュリティディレクターは、米国東部 (バージニア北部) および欧州 (ストックホルム) リージョンでご利用いただけます。Amazon Q Developer によるネットワークセキュリティ設定の分析機能は、米国東部 (バージニア北部) でプレビュー段階にあります。ネットワークセキュリティの強化を開始するには、 AWS Shield ネットワークセキュリティディレクターコンソール にアクセスして、最初のネットワークセキュリティ分析を開始してください。 詳細については、 AWS Shield 製品 ページをご覧ください。 – Esra 原文は こちら です。

6 月 17 日、 Amazon CloudFront 向けの簡素化された新しいオンボーディングエクスペリエンスを発表しました。デベロッパーはこれを利用して、ウェブアプリケーションを数秒で高速化し、セキュリティを実現できます。この新しいエクスペリエンスと、 AWS WAF コンソールエクスペリエンスの改善により、デベロッパーは、高度な技術的専門知識なしで、コンテンツ配信およびセキュリティサービスをこれまで以上に簡単に設定できるようになります。 従来、ウェブアプリケーションのためにコンテンツ配信とセキュリティを設定するには、複数の Amazon Web Services (AWS) サービスを適切に利用して、設定に関して数多くの意思決定を行う必要がありました。この新しい CloudFront オンボーディングエクスペリエンスにより、デベロッパーは、わずか数クリックで、DNS と TLS 証明書を備えた、完全に設定されたディストリビューションを作成できるようになりました。 Amazon CloudFront は、コンテンツとアプリケーションをグローバルに配信したいと考えているあらゆる規模の組織に魅力的なメリットを提供します。コンテンツ配信ネットワーク (CDN) である CloudFront は、ユーザーに最も近いエッジロケーションからコンテンツを配信することでアプリケーションのパフォーマンスを大幅に改善して、レイテンシーを低減し、ユーザーエクスペリエンスを改善します。パフォーマンスに加えて、CloudFront は、エッジにおける分散型サービス拒否 (DDoS) 攻撃や他の脅威からアプリケーションを保護する組み込みのセキュリティ機能を提供し、悪意のあるトラフィックがオリジンインフラストラクチャに到達するのを防ぎます。このサービスは、手動による介入を必要とせずにトラフィック需要に合わせて自動的にスケールし、計画されたトラフィックの急増と予期しないトラフィックの急増の両方に容易に対応します。実行しているのが、小規模なウェブサイトと大規模なアプリケーションのいずれであるかにかかわらず、他の AWS サービスとの CloudFront の統合と、簡素化された新しいコンソールエクスペリエンスにより、ウェブアプリケーションに不可欠なこれらの機能をこれまで以上に簡単に実装できます。 合理化された CloudFront 設定 新しい CloudFront コンソールエクスペリエンスは、簡素化されたワークフローを通じてデベロッパーをガイドします。このワークフローは、ディストリビューションに使用するドメイン名の入力から始まります。 Amazon Route 53 を利用する場合、このエクスペリエンスは TLS 証明書のプロビジョニングと DNS レコード設定を自動的に処理し、セキュリティのベストプラクティスをデフォルトで組み込みます。この統合アプローチにより、 AWS Certificate Manager 、Route 53、AWS WAF などの複数のサービスを切り替える必要がなくなり、デベロッパーは、各サービスの詳細な設定オプションを深く理解することなく、より迅速に本番に移行できます。 例えば、デベロッパーは、ドメイン名を入力し、ロードバランサーをオリジンとして選択することで、ロードバランサーを経由するアプリケーションのために安全な CloudFront ディストリビューションを作成できるようになりました。コンソールは、アプリケーションのタイプと要件に基づいて最適な CDN とセキュリティ設定を自動的に推奨するため、デベロッパーは AWS のベストプラクティスに従っていると確信しながらデプロイできます。 Amazon Simple Storage Service (Amazon S3) で静的ウェブサイトをホストしたいと考えているデベロッパーのために、CloudFront はいくつかの重要なメリットを提供します。まず、ユーザーにより近いエッジロケーションにコンテンツをキャッシュすることでウェブサイトのパフォーマンスが改善され、レイテンシーが低減し、ページのロード時間が短縮されます。次に、セキュリティレイヤーとして機能することで S3 バケットを保護するのに役立ちます。CloudFront をコンテンツへの唯一のアクセス方法として設定することで、S3 バケットへの直接アクセスを防ぐことができます。新しいエクスペリエンスは、これらのセキュリティのベストプラクティスを自動的に設定します。 AWS WAF を利用したセキュリティ統合の強化 新しい CloudFront エクスペリエンスを補完するものとして、アプリケーションのタイプとセキュリティ要件に基づいて厳選された一連のセキュリティルールであるインテリジェントなルールパックを備えている、改善された AWS WAF コンソールも導入します。これらのルールパックにより、デベロッパーは包括的なセキュリティコントロールを実装できます。セキュリティのエキスパートである必要はありません。 デベロッパーは、CloudFront ディストリビューションを作成する際に、これらの新しいルールパックを使用した統合エクスペリエンスを通じて AWS WAF 保護を有効にできるようになりました。コンソールは、デベロッパーがデプロイ前に設定をプレビューおよび検証するために使用できるセキュリティ設定に関する明確なレコメンデーションを提供します。 6 月 17 日、ウェブアプリケーションは、SQL インジェクション攻撃、クロスサイトスクリプティング (XSS)、および他の OWASP Top 10 の脆弱性など、数多くのセキュリティの脅威に直面しています。新しい AWS WAF 統合により、これらの一般的な攻撃ベクトルに対する保護が自動的に提供されます。推奨されるルールパックは、悪意のあるボットトラフィック、一般的なウェブエクスプロイト、既知の不正行為者に対する即時の保護を提供し、インフラストラクチャに過負荷をかける可能性のある direct-to-origin 攻撃を防止します。 詳しく見てみましょう Amazon CloudFront ディストリビューションを作成したことがあるお客様は、すぐに変更点に気付くでしょう。新しいエクスペリエンスは、利用しやすく、容易に理解できます。私の例では、Amazon S3 をオリジンとして使用して、静的ウェブサイトのディストリビューションを作成することにしました。 [ステップ 1] では、ディストリビューションに名前を付けて、 [単一のウェブサイトまたはアプリケーション] または新しい [マルチテナントアーキテクチャ] オプションを選択します。このオプションを使用すると、複数のドメインを使用しながらも共通の設定を共有するディストリビューションを設定できます。 [単一のウェブサイトまたはアプリケーション] を選択し、オプションのドメイン名を入力します。新しいエクスペリエンスでは、 [ドメインを確認] ボタンを使用して、ドメインが Route 53 ゾーンファイルとして設定されていることを確認できます。 次に、ディストリビューションのオリジンを選択します。これは、CloudFront がコンテンツを取得して配信およびキャッシュする場所です。 [オリジンタイプ] で、Amazon S3 を選択します。前掲のスクリーンショットに示すように、選択できる追加オプションがいくつかあります。各オプションは、極めて一般的なユースケースで、可能な限り簡単に設定できるように設計されています。次に、バケット名を入力するか、または [S3 を参照] ボタンを使用して、S3 バケットを選択します。 次に、オリジンとしての Amazon S3 の使用に関連するいくつかの設定があります。 [CloudFront にオリジンへのアクセスを付与] オプションは重要です。このオプション (デフォルトで選択されています) により、S3 バケットポリシーが更新され、CloudFront がバケットにアクセスできるようになります。また、バケットが オリジンアクセスコントロール 用に設定されます。これにより、完全にプライベートなバケットを使用でき、バケット内のアセットには CloudFront を通じてのみアクセスできることを確信できます。これは、バケットとアセットを安全に保つための重要なステップです。 次のステップでは、AWS WAF を設定するオプションが表示されます。AWS WAF を有効にすると、着信リクエストがウェブサーバーに送信される前に、それらの各リクエストに潜在的な脅威が含まれていないかが検査されるため、ウェブサーバーはより良く保護されます。AWS WAF を有効にするにはコストがかかります。次のスクリーンショットに示すように、追加料金の見積りに役立つ料金見積りツールを使用できます。 今すぐご利用いただけます 新しい CloudFront オンボーディングエクスペリエンスと、強化された AWS WAF コンソールは、これらのサービスが提供されているすべての AWS リージョン で本日よりご利用いただけます。これらの新機能は、 AWS マネジメントコンソール を通じて利用を開始できます。これらの新しいエクスペリエンスの利用に追加料金はかかりません。お支払いいただくのは、それぞれの料金モデルに基づいて、使用した CloudFront および AWS WAF リソースについての料金のみです。 新しい CloudFront オンボーディングエクスペリエンスと、AWS WAF の改善点の詳細については、 Amazon CloudFront ドキュメント および AWS WAF ドキュメント にアクセスしてください。これらの簡素化されたエクスペリエンスを活用して、より高速かつ安全なウェブアプリケーションの構築を今すぐ始めましょう。 原文は こちら です。

6 月 17 日、 AWS Certificate Manager (ACM) からエクスポート可能なパブリック SSL/TLS 証明書についてお知らせします。このリリースに先立ち、お客様は追加コストなしで、 パブリック証明書を発行 したり、サードパーティーの認証期間 (CA) が発行した 証明書をインポート したりできるとともに、これらの証明書を AWS の統合サービス ( Elastic Load Balancing (ELB) 、 Amazon CloudFront ディストリビューション、 Amazon API Gateway など) にデプロイできます。 ACM からパブリック証明書をエクスポートし、プライベートキーに対するアクセスを取得して、 Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、コンテナ、またはオンプレミスホストで実行されているあらゆるワークロードで使用できるようになりました。エクスポート可能なパブリック証明書の有効期間は 395 日間です。発行時と更新時に料金が発生します。 ACM からエクスポートされたパブリック証明書は Amazon Trust Services によって発行され、Apple や Microsoft などの一般的に使用されているプラットフォーム、および Google Chrome や Mozilla Firefox などの人気のウェブブラウザによって広く信頼されています。 ACM のエクスポート可能なパブリック証明書の実際の動作 パブリック証明書をエクスポートするには、まず新しいエクスポート可能なパブリック証明書をリクエストします。以前に作成したパブリック証明書をエクスポートすることはできません。 開始するには、 ACM コンソール で [証明書をリクエスト] を選択し、 [エクスポートを許可] セクションで [エクスポートを有効にする] を選択します。 [エクスポートを無効にする] を選択すると、この証明書のプライベートキーは ACM からエクスポートできなくなります。また、この設定は証明書の発行後に変更できません。 AWS コマンドラインインターフェイス (AWS CLI) で request-certificate コマンドを使用して、 Export=ENABLED オプションを指定してエクスポート可能なパブリック証明書をリクエストすることもできます。 aws acm request-certificate \ --domain-name mydomain.com \ --key-algorithm EC_Prime256v1 \ --validation-method DNS \ --idempotency-token <token> \ --options \ CertificateTransparencyLoggingPreference=DISABLED \ Export=ENABLED パブリック証明書をリクエストしたら、証明書をリクエストしているドメインを所有または管理していることを証明するために、ドメイン名を検証する必要があります。ドメイン検証が成功すると、通常は数秒以内に証明書が発行されます。 証明書のステータスが [発行済み] になったら、 [エクスポート] を選択して発行済みのパブリック証明書をエクスポートできます。 プライベートキーを暗号化するためのパスフレーズを入力します。このパスフレーズは、後でプライベートキーを復号するために必要になります。パブリックキーを取得するには、 [PEM エンコーディングを生成] を選択します。 PEM エンコーディングされた証明書、証明書チェーン、プライベートキーをコピーしたり、それぞれを個別のファイルにダウンロードしたりできます。 export-certificate コマンドを使用して、パブリック証明書とプライベートキーをエクスポートできます。セキュリティを強化するには、ファイルエディタを使用してパスフレーズと出力キーをファイルに保存し、コマンド履歴に保存されないようにします。 aws acm export-certificate \ --certificate-arn arn:aws:acm:us-east-1:<accountID>:certificate/<certificateID> \ --passphrase fileb://path-to-passphrase-file \ | jq -r '"\(.Certificate)\(.CertificateChain)\(.PrivateKey)"' \ > /tmp/export.txt これで、Amazon EC2 インスタンスなど、SSL/TLS 通信を必要とするワークロードで、エクスポートしたパブリック証明書を使用できるようになりました。詳細については、EC2 インスタンスでの「 Configure SSL/TLS on Amazon Linux 」にアクセスしてください。 知っておくべきこと エクスポート可能なパブリック証明書について知っておくべきことがいくつかあります: キーのセキュリティ – 組織の管理者は、AWS IAM ポリシーを設定して、エクスポート可能なパブリック証明書をリクエストできるロールとユーザーを認可できます。現在証明書を発行する権限を持つ ACM ユーザーに、エクスポート可能な証明書を発行する権限が自動的に付与されます。また、ACM 管理者は証明書を管理し、証明書の取り消しや削除などのアクションを実行することもできます。エクスポートされたプライベートキーは、安全なストレージとアクセスコントロールを使用して保護する必要があります。 取り消し – 組織のポリシーを遵守するため、またはキーの漏えいによる影響を軽減するために、エクスポート可能なパブリック証明書を取り消す必要がある場合があります。取り消すことができるのは、以前にエクスポートされた証明書のみです。証明書の取り消しプロセスはグローバルかつ永続的です。取り消されると、取り消された証明書を取得して再利用することはできません。詳細については、AWS ドキュメントの「 Revoke a public certificate 」にアクセスしてください。 更新 – Amazon EventBridge を利用してエクスポート可能なパブリック証明書の自動更新イベントを設定することで、証明書の更新をモニタリングし、更新が発生したときに証明書のデプロイを処理するためのオートメーションを作成できます。詳細については、AWS ドキュメントの「 Using Amazon EventBridge 」にアクセスしてください。これらの証明書はオンデマンドで更新することもできます。証明書を更新すると、新しい証明書の発行にについて課金されます。詳細については、AWS ドキュメントの「 Force certificate renewal 」にアクセスしてください。 今すぐご利用いただけます 他のコンピューティングワークロードや、ELB、Amazon CloudFront、Amazon API Gateway を使用するために、ACM からエクスポート可能なパブリック証明書を発行して、証明書をプライベートキーとともにエクスポートできるようになりました。 ACM を利用してエクスポート可能なパブリック証明書を作成すると、追加料金がかかります。完全修飾ドメイン名ごとに 15 USD、ワイルドカードドメイン名ごとに 149 USD かかります。証明書の有効期間中に一度だけお支払いいただき、証明書の更新時にのみ再度課金されます。詳細については、「 AWS Certificate Manager サービスの料金 」ページにアクセスしてください。 ACM のエクスポート可能なパブリック証明書は、 ACM コンソール でお試しいただけます。詳細については、 ACM ドキュメントページ にアクセスしてください。また、 AWS re:Post for ACM または通常の AWS サポート担当者を通じてフィードバックをぜひお寄せください。 – Channy 原文は こちら です。

リアルタイム機能は、ユーザーがすぐに更新されたり双方向の体験を求める現代のアプリケーションにおいて不可欠となっています。チャットアプリ、ライブダッシュボード、ゲームのリーダーボード、IoT システムなどを構築する場合、 AWS AppSync Events は WebSocket API を通じてこれらのリアルタイム機能を実現し、スケーリングや接続管理を気にかけることなく、スケーラブルで高性能なリアルタイムアプリケーションを構築できるようにしています。 AWS Lambda 用の Powertools は、監視、バッチ処理、 AWS Systems Manager Parameter Store 統合、冪等性、フィーチャーフラグ、 Amazon CloudWatch メトリクス、構造化ログなどを含む開発者向けツールキットです。Powertools for AWS は、Python、TypeScript、.NET で提供される新しい AppSyncEventsResolver を通じて、AppSync Events をサポートするようになりました。この新機能により、ビジネスロジックに集中できるように設計された機能が強化され、開発体験が向上します。 AppSyncEventsResolver は、イベントの処理のためのシンプルで一貫したインターフェイスを提供し、イベントのフィルタリング、変換、ルーティングなどの一般的なパターンに対する組み込みサポートも提供されます。 この記事では、 TypeScript の例を見ますが、 Powertools for AWS (Python) と Powertools for AWS (.NET) を使えば、Python と .NET 関数でも同じ機能を利用できます。 図 1 – AWS AppSync、Lambda、および Powertools を使用したリアルタイムイベントハンドリングアーキテクチャー 本ブログでは、以下の点を学びます。 AppSyncEventsResolver を使用してイベントハンドラを設定する 最適なパフォーマンスのために、さまざまなイベント処理パターンを実装する パターンベースのルーティングを使用して、イベントハンドラを整理する 一般的な使用パターンに対して、組み込み機能を活用する 始め方 AppSyncEventsResolver は、 AWS Lambda 関数内での AppSync Events を処理する簡単で宣言的な方法です。このイベントリゾルバーによって、 PUBLISH イベントと SUBSCRIBE イベントをリッスンできます。 PUBLISH イベントは、クライアントがチャネルにメッセージを送信するときに発生します。一方、 SUBSCRIBE イベントは、クライアントがチャネルをサブスクリプションしようとしたときに発生します。異なる名前空間やチャネルのハンドラを登録することで、イベント駆動型の通信を管理できます。 次に、作業を開始してさまざまな開発体験を向上させるための主要機能について見ていきましょう。 AppSyncEventsResolver を設定する基本的な例は次のとおりです。 import { AppSyncEventsResolver, UnauthorizedException, } from '@aws-lambda-powertools/event-handler/appsync-events'; // Types for our message handling type ChatMessage = { userId: string ; content: string ; } // Simple authorization check const isAuthorized = (path: string, userId ?: string): boolean => { // check against your authorization system if (path.startsWith('/chat/private') && ! userId) { return false ; } return true ; }; // Message processing logic const processMessage = async (payload: ChatMessage) => { // - Validate message content // - Store in database // - Enrich with additional data return { ...payload, timestamp: new Date().toISOString() }; }; const app = new AppSyncEventsResolver(); // Handle publish events for a specific channel app.onPublish('/chat/general', async (payload: ChatMessage) => { // Process and return the message return processMessage(payload); }); // Handle subscription events for all channels app.onSubscribe('/*', async (info) => { const { channel: { path }, request, } = info ; // Perform access control checks if (! isAuthorized(path, userId)) { throw new UnauthorizedException(`not allowed to subscribe to ${ path } `); } return true ; }); export const handler = async (event, context) => app.resolve(event, context); AppSyncEventsResolver クラスは、受信したイベントデータを解析し、イベントの種類に応じて適切なハンドラメソッドを呼び出します。ここで何が起こっているのかを解説しましょう。 パターンベースのルーティング AppSyncEventsResolver は、チャネルパスに基づいてイベントハンドラを整理できる直感的なパターンベースのルーティングシステムを使用しています。以下のことが可能です： 特定のチャネルを処理する（/chat/general） 名前空間にワイルドカードを使用する（/chat/*） グローバルなキャッチオールハンドラを作成する（/*） import { AppSyncEventsResolver } from '@aws-lambda-powertools/event-handler/appsync-events'; const app = new AppSyncEventsResolver(); // Specific channel handler app.onPublish('/notifications/alerts', async (payload) => { // your logic here }); // Handle all channels in the notifications namespace app.onPublish('/notifications/*', async (payload) => { // your logic here }); // Global catch-all for unhandled channels app.onPublish('/*', async (payload) => { // your logic here }); export const handler = async (event, context) => app.resolve(event, context); 最も一般的なキャッチオールハンドラは /* で、これはどの名前空間やチャネルにもマッチします。一方、 /default/* は、 default 名前空間のあらゆるチャネルにマッチします。複数のハンドラが同じイベントにマッチする場合は、ライブラリは最も具体的なハンドラを呼び出し、より一般的なハンドラは無視されます。たとえば、 /default/channel1 に対してハンドラが登録されており、さらに /default/* にもハンドラが登録されている場合、Powertools は /default/channel1 にマッチするイベントでは最初のハンドラを呼び出し、2 番目のハンドラは無視されます。このアプローチにより、イベントがどのように処理されるかを制御し、不要な処理を回避できます。デフォルトでは、Powertools はどのハンドラとも合致しないイベントについては、そのままイベントを返し、警告をログに記録します。つまり、そういったイベントは変更されずにそのまま渡されます。このアプローチは、特定のイベントに対してはカスタムロジックを適用しつつ、他のイベントはデフォルトの挙動で処理できるため、徐々にライブラリを適用していくのに役立ちます。 Subscription ハンドリング Powertools はサブスクリプションイベントを処理する簡単な方法も提供します。受信したイベントを自動的に解析し、イベントタイプに基づいて適切なハンドラを呼び出します。デフォルトでは、Lambda ハンドラがエラーをスローしたり要求を明示的に拒否しない限り、AppSync はサブスクリプションを許可します。サブスクリプションが拒否されると、AppSync はクライアントに 4xx レスポンスを返し、サブスクリプションが確立されるのを防ぎます。 import { AppSyncEventsResolver } from '@aws-lambda-powertools/event-handler/appsync-events'; import { Metrics, MetricUnit } from '@aws-lambda-powertools/metrics'; import type { Context } from 'aws-lambda'; const metrics = new Metrics({ namespace: 'serverlessAirline', serviceName: 'chat', singleMetric: true, }); const app = new AppSyncEventsResolver(); app.onSubscribe('/default/foo', (event) => { metrics.addDimension('channel', event.info.channel.path); metrics.addMetric('connections', MetricUnit.Count, 1); }); export const handler = async (event: unknown, context: Context) => app.resolve(event, context); サブスクリプションイベントが到着すると、このライブラリはイベントオブジェクトを第 1 引数としてハンドラを呼び出します。アクセス制御チェックの実行など、サブスクリプションイベントに基づいて必要な処理を行えます。 app.onSubscribe('/private/*', async (info) => { const userGroups = info.identity?.groups && Array.isArray(info.identity?.groups) ?info.identity ?.groups : [] ; const channelGroup = 'premium-users'; if (!userGroups.includes(channelGroup)) { throw new UnauthorizedException( `Subscription requires ${ channelGroup } group membership` ); } }) サブスクリプションイベントは同じマッチングルールに従い、イベントとコンテキストへの完全なアクセスを提供します。ワイルドカード * 文字を使用して任意の名前空間やチャンネルに対するキャッチオールハンドラを登録でき、ハンドラ内でイベントとコンテキストオブジェクトに完全にアクセスすることもできます。 イベントとコンテキストの完全なアクセス リゾルバーがイベントハンドリングを簡素化しますが、必要に応じてイベントとコンテキストオブジェクトに完全にアクセスできます。これは、リクエストヘッダーや Lambda コンテキストの残り実行時間など、カスタムロジックを実装するために追加情報が必要な場合に役立ちます。 リゾルバーは、全てのイベントとコンテキストを第 2 引数と第 3 引数として各ハンドラに渡します。これにより、既存のコードを変更することなく、関連する全ての情報にアクセスできます。 import { AppSyncEventsResolver } from '@aws-lambda-powertools/event-handler/appsync-events'; import { Logger } from '@aws-lambda-powertools/logger'; const logger = new Logger({ logLeveL: 'INFO', serviceName: 'serverlessAirline' }); const app = new AppSyncEventsResolver({ logger }); app.onPublish('/orders/process', async (payload, event, context) => { // Access request headers const { headers } = event.request ; // Access Lambda context const { getRemainingTimeInMillis } = context ; logger.info('Processing event details', { headers, remainingTime: getRemainingTimeInMillis() }); return payload ; }); export const handler = async (event, context) => app.resolve(event, context); エラーハンドリング AppSyncEventsResolver には、Lambda 関数の障害を防ぎながら、エラーが適切に AppSync に通知されるよう組み込みのエラー処理機能があります。AppSync はそれらのエラーをクライアントに伝播させます。ハンドラでエラーが発生した場合、リゾルバ は Lambda の呼び出し全体を失敗させるのではなく、そのエラーをイベントごとのレスポンスペイロードに含めます。 このアプローチにより、Lambda 関数は実行を継続しながら、AppSync に適切にフォーマットされたエラーメッセージを提供します。複数のイベントを処理する場合、1つのイベントが失敗しても、他のイベントは正常に処理を続けます。これは、あるイベントのエラーが他のイベントの処理に影響を与えないようにしたい並列処理シナリオで特に役立ちます。 import { AppSyncEventsResolver } from '@aws-lambda-powertools/event-handler/appsync-events'; const app = new AppSyncEventsResolver(); app.onPublish('/messages', async (payload) => { // If message contains "error", throw an exception if (payload.message === "error") { throw new Error("Invalid message"); } return payload ; }); export const handler = async (event, context) => app.resolve(event, context); // When processing this event: // { // "id": "123", // "payload": { // "message": "error" // } // } // The resolver will return: // { // "id": "123", // "error": "Error - Invalid message" // } 高度なパターンとベストプラクティス AppSyncEventsResolver には、堅牢でメンテナンス性の高いリアルタイムアプリケーションを構築するのに役立つ、高度な機能が追加されています。これらの機能とその効果的な利用方法を見ていきましょう。 パブリッシュ処理について デフォルトでは、メッセージごとにルートハンドラを 1 回呼び出します。Powertools がメッセージの反復処理やイベントレスポンス形式の変換を行うため、ビジネスロジックに集中し、定型コードを書く必要がありません。あとはペイロードとして使いたい値を返すか、そのメッセージでエラーをスローするだけです。ライブラリがペイロードを正しいイベント ID と関連付けます。 import { AppSyncEventsResolver } from '@aws-lambda-powertools/event-handler/appsync-events'; import { Metrics, MetricUnit } from '@aws-lambda-powertools/metrics'; type SensorReading = { deviceId: string ; temperature: number ; humidity: number ; timestamp: string ; } const app = new AppSyncEventsResolver(); const metrics = new Metrics({ namespace: 'SensorReadings' }); app.onPublish('/sensors/readings', async (payload: SensorReading) => { // Process each sensor reading independently if (payload.temperature > 100) { metrics.addDimension('alertType', 'highTemperature'); metrics.addMetric('HighTemperature', MetricUnit.Count, 1); throw new Error('Temperature reading too high'); } // Enrich the payload with processing timestamp return { ...payload, processed: true, processedAt: new Date().toISOString() }; }); export const handler = async (event, context) => app.resolve(event, context); このパターンは、単一のイベントに対するロジックのみを記述すればよいため、開発を簡素化します。Powertools が残りを自動的に処理します。 集約処理 集約モードでは、イベントを個別に処理するのではなく、複数のイベントを単一のバッチとして処理することができます。これは、データベースへの複数のクエリを1回の操作で送信するなど、リソース使用を最適化したい場合や、処理前に複数のイベントをまとめて分析したい場合に特に役立ちます。どちらのモードでもイベント処理を完全に制御できますが、集約モードでは一度にイベントのリスト全体にアクセスできます。 これを実現するには、 aggregate オプションを true に設定します。このモードを使用すると、リゾルバーはイベントのリスト全体を1回の呼び出しでハンドラに送信し、バッチとして処理することができます。 import { AppSyncEventsResolver } from '@aws-lambda-powertools/event-handler/appsync-events'; const app = new AppSyncEventsResolver(); app.onPublish('/default/*', async (events) => { const results = [] ; for (const event of events) { try { results.push(await handleDefaultNamespaceCatchAll(event)); } catch (error) { results.push({ error: { errorType: 'Error', message: error.message, }, id: event.id, }); } } return results ; }, { aggregate: true, }); export const handler = async (event, context) => app.resolve(event, context); 集約オプションはパブリッシュイベントにのみ使用可能であり、このオプションを使用する場合は、イベントの処理と適切なレスポンスの返却に責任を持つ必要があることに注意してください。Powertools は引き続きイベントを正しいハンドラにルーティングしますが、イベントの処理方法は完全にあなたの制御下にあります。 イベントフィルタリング イベントをフィルタリングするには、チャネルハンドラでエラーをスローします。ハンドラが特定のイベントに対してエラーをスローすると、ライブラリはそれをキャッチし、同じインデックスのレスポンスリストにエラーオブジェクトを追加します。これは、対応するメッセージを破棄すべきであることを示します。これにより、イベントを静かにフィルタリングするか、サブスクライバーに意味のあるエラーフィードバックを提供するかを選択できます。 import { AppSyncEventsResolver } from '@aws-lambda-powertools/event-handler/appsync-events'; app.onPublish('/moderation/*', async (payload) => { // Filter out inappropriate content if (await containsInappropriateContent(payload)) { throw new CustomError('Content violates guidelines'); } // Process valid content return await processContent(payload); }); export const handler = async (event, context) => app.resolve(event, context); まとめ Powertools for AWS の AppSyncEventsResolver は、シンプルで一貫したインターフェースを提供することで、AppSync Events を処理する開発体験を向上させます。定型コードを削減し、一般的なパターンに対する組み込みサポートを提供することで、インフラコードではなくビジネスロジックに集中できます。 詳細については： Powertools for AWS のドキュメント で詳細情報を探索する サービスについてもっと学ぶために AppSync Event のドキュメント をチェックする 貢献や問題を報告するために私たちの GitHub リポジトリ を訪問する これらの新機能で何を構築するのか楽しみにしています。フィードバックを共有し、アプリケーションで AppSyncEventsResolver をどのように使用しているかお知らせください！ 本ブログは「 Simplify AWS AppSync Events integration with Powertools for AWS Lambda 」 を翻訳したものです。 翻訳者について 稲田 大陸 AWS Japan で働く筋トレが趣味のソリューションアーキテクト。好きな AWS サービスは Amazon Location Service と AWS Amplify で、日本のお客様向けに Amazon Location Service の解説ブログ などを執筆しています。

企業の環境では、カスタムアプリケーションが業務の改善、生産性の向上、組織内の知識の集中化において重要な役割を果たします。しかし、これらのツールは多くの場合、関連する情報にユーザーが素早く直感的にアクセスできるような賢い会話型インターフェイスが備わっていません。膨大な組織データから文脈に応じた洞察を把握したり、複雑なクエリを解釈したりするには、従来のダッシュボードや検索バーでは限界があります。 生成 AI は、この課題に対する強力なソリューションを提供します。開発者が制御できるアプリケーションに会話型エクスペリエンスを直接埋め込むことで、組織は、ユーザーが自然言語で質問をし、正確で行動可能な回答を受け取れるようにできます。 Amazon Q Business は、大規模な言語モデルのインフラストラクチャを管理する負担なしに、この機能をセキュアな 埋め込み可能な HTML インラインフレーム (iframe) 経由で提供します。 このブログは、ナレッジポータル、サポートダッシュボード、社内向け Web ツールなどのカスタムアプリケーションやエンタープライズ向けアプリケーションを構築する開発者を対象としています。Amazon Q Business、 AWS Amplify Gen 2 、および AWS Cloud Development Kit (CDK) を使用して、生成 AI 搭載の会話型エクスペリエンスをアプリケーションに埋め込む方法を示します。Amazon Q Business をアプリケーションに埋め込むには、アプリケーションのソースコードへのアクセスが必要となり、カスタムコードの埋め込みが不可能なサードパーティ SaaS プラットフォームでは利用できません。 このブログでは以下について紹介します。 社内文書やナレッジベースへの会話形式によるアクセス 企業の ID 管理システムとの安全な統合 複雑なバックエンド実装なしで、スケーラブルな AI 駆動型検索の実現 AWS Amplify のフロントエンドおよびバックエンド開発機能を使用したスピーディーなデプロイ Amazon Q Business と AWS Amplify を使えば、アプリに生成 AI を素早く追加でき、生産性を向上、手作業を削減、意思決定を加速できます。 Figure 1 Submitting a prompt to Amazon Q Business iframe. 内部アプリケーションに生成 AI アシスタントを組み込むには、以下の AWS サービスを活用します。 AWS Amplify : セキュアなフルスタックアプリケーションを構築、デプロイ、管理するための包括的なツールとサービスのセットです。認証には Amazon Cognito、ストレージには Amazon S3、その他の AWS インフラストラクチャ構築には CDK とタイトに統合されていることで、フロントエンドとバックエンドの開発を簡素化します。 Amazon Cognito : アプリケーションに認証と承認機能を追加するためのマネージドサービスです。Cognito は、ユーザー登録、サインイン、アクセス制御をサポートし、エンタープライズアクセス管理のために外部のアイデンティティプロバイダー (IdP) と連携することができます。 AWS IAM Identity Center : IAM Identity Center は、内部ユーザーに対してセキュアで集中管理されたアクセス管理を可能にします。Okta、Microsoft Entra ID、Ping Identity などのエンタープライズプロバイダーとのアイデンティティ連携をサポートしており、組織が統一された認証ポリシーを適用し、埋め込み型 AI アシスタントへのアクセスを許可されたユーザーのみに制限することができます。 Amazon Q Business : 内部アプリケーションに iframe 経由で埋め込むことができるマネージド型の生成 AI サービスです。Amazon Q Business は Amazon S3 などのエンタープライズデータソースに接続し、インテリジェントなアシスタントインターフェースを通じて自然言語のクエリを可能にします。セキュアなアクセスをサポートしており、IAM Identity Center と統合することでエンタープライズでの連携利用が可能です。 Amazon Simple Storage Service (S3) : 内部文書、PDF、マニュアル、その他の非構造化コンテンツを保存するための、耐久性とスケーラビリティに優れたオブジェクトストレージサービスです。これらのファイルが Amazon Q Business アシスタントのナレッジベースとなり、従業員からの問い合わせに対してコンテキストを含む応答を可能にします。 Figure 2 From Build to Embed Architecture Diagram 前提条件 AWS アカウント : AWS Amplify は AWS フリーティア の一部であることに注意してください。 インストール: npm (v9 以降)、 git (v2.14.1 以降)。 テキストエディタ: このガイドでは VSCode を使用しますが、お好みの IDE を使用できます。 サンプルデータセット: PDF をアップロードするか、 Kaggle で利用可能なサンプルデータセットを確認してください。 IAM Identity Center : IAM ID センターインスタンスを有効化 し、 ID センターディレクトリにユーザーを追加 する必要があります。 リポジトリのクローン ステップ 1: AWS サンプルの リポジトリ に移動し、自分の GitHub リポジトリにフォークしてください。 ステップ 2: ターミナルで以下のコマンドを実行して、アプリをクローンしてください。 git clone https://github.com//sample-build-and-embed-genai-apps.git ステップ3 ：以下のコマンドをターミナルで実行して、新しくクローンしたリポジトリをVSCodeでアクセスします。 cd sample-build-and-embed-genai-apps code . -r VSCode は、リポジトリフォルダを開き、次のセクションで確認するアプリのコードを含む Amplify フォルダが表示されます。 Figure 3 Opening code in VSCode. ステップ4： 以下のコマンドを実行して、Amplify Gen 2 パッケージを含む必要なパッケージをインストールします。 npm install Amplify のバックエンド 最終的なアプリ (投稿の冒頭の GIF 動画で確認できます) では、ユーザーはアプリケーションにログインし、チャットボットアイコンをクリックして、連携アクセス認証を行います (これは iframe を通して Amazon Q Business の Web エクスペリエンスにアクセス するためです)。その後、Amazon Q Business に質問を開始できるようになります。このコードは、クローンしたリポジトリにあります。ここでは、Amplify で開発およびホストされた検索エンジンアプリを作成する主要なステップを説明します。 Figure 4 Amplify Gen 2 Project Folder Structure. amplify/auth/resource.ts ファイル (図 5) では、アプリケーションにアクセスしファイルをアップロードするために、ユーザーがメールアドレスでログインする必要がある認証が設定されています。メール認証によってログインを有効にすることで、機密データと機能にアクセスできるのが認証されたユーザーのみという制限を設けています。 import { defineAuth } from '@ aws-amplify/backend'; export const auth = defineAuth({ loginWith: { email: true, }, }); Figure 5 defineAuth in amplify/auth/resource.ts amplify/storage/resource.ts ファイル (図 6) では、 Amplify ストレージ を構成して、セキュアでユーザー固有のファイル管理を有効にしています。 defineStorage 関数は、ストレージリソースを分かりやすい名前 q-datasource-bucket でインスタンス化し、 protected/{entity_id}/* パスにアクセス制御を適用します。 この構成により、認証済みのユーザーは自身のスコープ付きディレクトリ内のファイルを読み取ることができ、ファイル所有者には読み取り、書き込み、削除のアクセス権限が付与されます。 import { defineStorage } from "@ aws-amplify/backend"; export const storage = defineStorage({ name: "q-datasource-bucket", access: (allow) => ({ 'protected/{entity_id}/*': [ allow.authenticated.to(['read']), allow.entity('identity').to(['read', 'write', 'delete']) ] }) }); Figure 6 defineStorage in amplify/storage/resource.ts amplify/backend.ts （図7）ファイルでは、アプリケーションの重要な側面を設定するために CDK ライブラリをインポートします。 aws-iam モジュールは権限管理に使用され、 aws-kms は暗号化とキー管理を処理し、 aws-qbusiness は Amazon Q Business をスタックにインテグレーションします。各ライブラリは、アプリケーションが安全であり、AWSサービスと適切に統合されるよう、特定の役割を果たしています。 import * as iam from 'aws-cdk-lib/aws-iam'; import * as kms from 'aws-cdk-lib/aws-kms'; import * as q from 'aws-cdk-lib/aws-qbusiness'; Figure 7 import CDK libraries in amplify/backend.ts 次に、 backend.createStack() (図 8) メソッドを使用して、カスタムリソースを格納するための新しい CloudFormation スタックの生成をバックエンドに指示します。AWS Amplify Gen 2 では、CDK を使用してカスタムリソースを作成できるため、Amplify ライブラリ以外のサービスを利用でき、スケーラビリティを備えた CloudFormation テンプレートでスタックをバックアップできます。たとえば、Generative AI スタックを作成し、カスタム AWS リソースを追加する前に AI 関連サービスの論理的な構成をすることができます。これでカスタム AWS リソースの定義を開始できます! export const customResource = backend.createStack("CustomResourceStack"); Figure 8 define backend stack for custom resources in amplify/backend.ts CustomResourceStack のデプロイ中に、複数のIAMロール、信頼ポリシー、インラインアクセスポリシーが作成されるのが確認できます。これらはすべて、Amazon Q Businessが安全に機能し、他のAWSサービスと連携するために不可欠なものです。これらには以下が含まれます。 サービスアクセスロール (QApplicationServiceAccessRole) は、Amazon Q Business が CloudWatch を経由してログとメトリクスを出力できるようにするためのロールです。 Web エクスペリエンスロール (QWebExperienceRole と QWebExperienceRole) は、埋め込みアシスタントがフルアプリケーションコンテキストとユーザーインタラクションで動作できるようにするためのロールです。 データソースロール (QBusinessS3Role) は、Amazon Q Business が Amplify ストレージによってプロビジョニングされた S3 バケットからドキュメントを読み取ることを許可するための専用のロールです。 各ロールには、 誰がそのロールを引き受けられるか を定義するトラストポリシーと、特定のアクションとリソースへのアクセス権を付与する詳細なアクセス許可が含まれています。Amazon Q Business データソース向けの必要なポリシー構造の詳細は、 Amazon Q Business コネクタの IAM ロールドキュメント で確認できます。 Amazon Q Business のセットアップ すべての基盤となる IAM ロールとポリシーが整ったところで、埋め込み型生成 AI アシスタントを動かす中核コンポーネントである Amazon Q Business アプリケーションを定義する準備が整いました。 amplify/backend.ts ファイル（図9）で、CDK を使用して、必要な設定、サブスクリプションプラン、IAM 統合を宣言的にインスタンス化できます。 export const qapp = new q.CfnApplication(customResource, "Qapp", { displayName: "Qapp", description: "CDK instantiated Amazon Q Business App", autoSubscriptionConfiguration: { autoSubscribe: "ENABLED", defaultSubscriptionType: "Q_LITE" }, identityType: "AWS_IAM_IDC", roleArn: `arn:aws:iam::${ customResource.account }:role/aws-service-role/qbusiness.amazonaws.com/AWSServiceRoleForQBusiness`, /* REPLACE WITH YOUR IAM IDENTITY CENTER ARN */ // identityCenterInstanceArn: "arn:aws:sso:::instance/", }); Figure 9 defining Q Business Application in amplify/backend.ts このステップでは正式に Amazon Q Business アプリケーションを作成し、サービスリンクロール ( AWSServiceRoleForQBusiness ) と関連付けます。デプロイ前に必ず IAM Identity Center ARN を置き換えて、ユーザーのフェデレーションアクセスを有効にしてください。 インデックスの作成 Amazon Q Business のインデックスは、企業データを効率的に保存、整理、取得するために使用されます。保存されたドキュメントの構造化されたクエリを可能にするためにインデックスが必要であり、これによりチャットボットはユーザークエリに基づいて関連する回答を取得できます。 amplify/backend.ts （図10）の以下の CDK コードは、Amazon Q Business アプリケーション内にインデックスを設定します。 export const qIndex = new q.CfnIndex(customResource, "QIndex", { displayName: "QIndex", description: "CDK instantiated Amazon Q Business App index", applicationId: qapp.attrApplicationId, capacityConfiguration: { units: 1, }, type: "STARTER", }); Figure 10 defining Q Business Index in amplify/backend.ts ここでは、STARTER インデックスタイプが選択されています。これはテストや小規模なデプロイメントに適した基本的な構成です。本番環境での使用には、スケーラビリティ、可用性、高度な機能のサポートを確保するために、 ENTERPRISE などの上位ティアが必要です。詳細は Amazon Q Business の料金とティア のガイダンスを参照してください。 Retriever の作成 Retriever はインデックスから関連ドキュメントを取得することで検索機能を強化します。Amazon Q Business では、Retriever はインデックスに接続し、クエリが意味のある応答を返すことを保証します。 amplify/backend.ts （図11）の次の CDK コードは、Amazon Q Business アプリケーション内に Retriever を設定します： export const qRetriever = new q.CfnRetriever(customResource, "QRetriever", { displayName: "QRetriever", applicationId: qapp.attrApplicationId, type: "NATIVE_INDEX", configuration: { nativeIndexConfiguration: { indexId: qIndex.attrIndexId, }, } }); Figure 11 defining Q Business Retriever in amplify/backend.ts この Retriever は、以前に作成された qIndex と連携するように構成されており、Amazon Q Business のインデックス付きコンテンツを効率的に取得することを保証します。 データソースの定義 データソースは、Amazon Q Business アプリケーションがその知識ベースのためにデータを取得する場所です。この場合、データソースは、以前に Amplify Storage の設定 amplify/storage/resource.ts で定義され、 amplify/backend.ts （図12）ファイルで参照されているAmazon S3バケットです。このバケットには、Amazon Q Businessがインデックスを作成して分析するドキュメントが保存されています。 export const qDataSource = new q.CfnDataSource(customResource, "QDataSource", { displayName: ` ${ backend.storage.resources.bucket.bucketName } `, applicationId: qapp.attrApplicationId, indexId: qIndex.attrIndexId, configuration: { type: "S3", syncMode: "FULL_CRAWL", connectionConfiguration: { repositoryEndpointMetadata: { BucketName: backend.storage.resources.bucket.bucketName } }, repositoryConfigurations: { document: { fieldMappings: [ { indexFieldName: "s3_document_id", indexFieldType: "STRING", dataSourceFieldName: "s3_document_id" } ] } }, }, roleArn: qBusinessS3Role.roleArn }); Figure 12 defining Q Business Data Source in amplify/backend.ts このセットアップの主要要素 syncMode : “FULL_CRAWL” は、S3バケット内のすべてのドキュメントがインデックス化されることを保証します。 フィールドマッピングは、インデックス作成のためのドキュメントメタデータの構造を定義します。 Amazon Q Business Web エクスペリエンスの作成 Amazon Q Businessの Web エクスペリエンスは、ユーザーがカスタマイズされたチャットボットに組み込まれた Amazon Q Business とやり取りできるようにするフロントエンドです。このコンポーネントは amplify/backend.ts （図13）ファイルで定義されており、許可された Web サイトのオリジン、ブランディング、認証を含め、チャットボットインターフェースがどのように表示され機能するかを定義します。 export const qWebExperience = new q.CfnWebExperience(customResource, "QWebExperience", { applicationId: qapp.attrApplicationId, origins: [ /* REPLACE WITH YOUR AMPLIFY DOMAIN URL */ "https://main..amplifyapp.com", ], samplePromptsControlMode: "ENABLED", subtitle: "AnyCompany Generative AI Assistant", title: "AnyCompany Q App", welcomeMessage: "Welcome to your Amazon Q Business Application !", roleArn: qWebExperienceRole.roleArn }); Figure 13 defining Q Business Web Experience in amplify/backend.ts Web エクスペリエンス設定 origins ：チャットボットを<iframe>経由で埋め込むことを許可する Web サイトドメインを指定します。Amplify アプリのデプロイされた URL がここに正しく記載されていることを確認してください。 samplePromptsControlMode ：チャットボット UI 内に事前定義されたサンプルプロンプトを保存できるようにします。 title & subtitle ：チャットボットの表示名と追加の説明を設定します。 welcomeMessage ：ユーザーがチャットウィンドウを開いたときに最初に表示されるメッセージです。 Amazon Q Business とフロントエンドの統合 Web エクスペリエンスを設定した後、iframe を使用して Amazon Q Business Web エクスペリエンスを埋め込む ことができます。 src/components/qframe.tsx （図14）では、src は amplify_outputs.json ファイルから動的に取得されます。このファイルにはバックエンドによってエクスポートされた Q Web エクスペリエンスのデプロイされた URL が含まれています。ユーザーは新しいブラウザタブで認証を求められ、その後チャットセッションは埋め込まれた iframe 内で続行されます。 import React from 'react'; import rawOutputs from '../../amplify_outputs.json'; const outputs = rawOutputs as unknown as { custom: { q_business_url: string ; }; }; const QFrame: React.FC = () => { const qBusinessDeployedURL = outputs.custom.q_business_url ; return ( ); }; export default QFrame ; Figure 14 Embeds Amazon Q Business via iframe using config URL. アプリの実行 ステップ1：Amplifyは各開発者に個人用の クラウドサンドボックス環境 を提供し、迅速な構築、テスト、反復のための隔離された開発スペースを提供します。クラウドサンドボックス環境を開始するには、新しいターミナルウィンドウを開き、次のコマンドを実行します。 npx ampx sandbox ステップ2：以下のコマンドを実行して、localhost の開発サーバーを起動します。 npm run dev 前述のコマンドを実行してアプリケーションを起動した後、 Amplify Authenticator コンポーネント の「Create Account」機能を使用し、メールアドレスとパスワードを入力します。確認メールを通じてユーザー設定を完了した後、ログインしてアプリケーションにアクセスします。（図15） Figure 15 Logging in using the Amplify Authenticator component during local development testing. 開発サーバーでアプリを操作した後、ターミナルで Ctrl + C を押してサンドボックス環境を停止します。その後、「 npx ampx sandbox delete 」と入力し、サンドボックス環境のリソースを削除するよう求められたら「 Y 」と入力して確認します。（図16） Figure 16 Deleting all resources in the Amplify sandbox environment バックエンドリソースのデプロイ アプリが期待通りに機能することを確認したら、「 Amplify Hosting へのアプリのデプロイを開始する 」の手順に従ってバックエンドリソースをデプロイします。デプロイのリポジトリとして GitHub が選択されていることを確認してください。 Amplify ドメインエンドポイントの更新 バックエンド CDK コードで、 amplify/backend.ts に移動し、origins フィールドのプレースホルダーを実際の Amplify ドメインに置き換えます。このドメインは、前のセクションで作成したアプリ名の Amplify コンソールで確認できます。（図17） origins: [ "https://main..amplifyapp.com", ], Figure 17 Updating the origins field in the CDK backend code with your Amplify app ’ s deployed domain. サンプルデータのアップロード デプロイしてアプリケーションにサインインした後、Amplify によって生成されたアプリのドメイン URL にアクセスしてサンプルデータをアップロードします。ファイルをアップロードした後、AWS Amplify コンソールのストレージセクション内の public/フォルダを確認してアップロードを確認します。（図18） Figure 18 Uploading sample data in deployed app. Amazon Q Business Web エクスペリエンスへのユーザーアクセスの設定 次に、Qapp では、埋め込まれた Web エクスペリエンスにログインできるユーザーを割り当てる必要があります。このユーザーは、前提条件の間に IAM Identity Center を使用して作成されているはずです。新規または既存のユーザーを追加するには、 Amazon Q Business コンソールで、Qapp を選択し、「User access」セクションに移動して「Manage user access」をクリックし、続いて「Add groups and users」をクリックします。（図19） Figure 19 Assigning user access via IAM Identity Center. ユーザーがすでに存在する場合は、「Assign existing users and groups」を選択し、割り当てたいユーザーを検索します。追加したら、選択を確認して Amazon Q Business Web エクスペリエンスへのアクセスを許可します。（図20） Figure 20 Granting access to existing IAM Identity Center users. S3データをQ Businessインデックスに同期する サンプルドキュメントをアップロードした後、Amazon S3 バケットを Amazon Q Business インデックスと同期して、データを保存および取得します。 Amazon Q Business コンソールから、「Data Sources」に移動し、「amplify-your-unique-bucket-name」を選択します。次に、「Sync now」を選択します（図21）。 Figure 21 Syncing uploaded S3 data to Q Business index. データソースの同期が完了し、最後の同期ステータスが「Completed」と表示されたら、Amazon Q Business Web エクスペリエンスの使用を開始する準備がほぼ整いました。続行する前に、サインインしていることを確認してください。サインインが成功すると、「サインイン完了」というメッセージが表示されます。その時点でアプリケーションに戻ることができます—認証が完了しました。（図22） Figure 22 Confirming sign-in completion for authentication. サインインしたので、アプリケーションを通じて Amazon Q Business Web エクスペリエンスに直接クエリを開始できます！（図23） Figure 23 Querying Amazon Q Business in your application. クリーンアップ AWS Identity Center コンソール インスタンスを削除するには、「Settings」に移動し、「Management」タブを開きます。「Delete IAM Identity Center Instance」セクションで、「Delete」を選択してインスタンスを削除します。 最後に、 AWS Amplify コンソール 内で、このブログに従って作成したアプリケーションの「View App」を選択します。次に、「App Settings」を選択し、「General Settings」を選択します。最後に、「Delete App」を選択して、アプリケーションと関連するバックエンドリソースを削除します。なお、Amplify はプロジェクトの一部として作成されたすべてのバックエンドリソースを削除します。 まとめ このブログでは、Amazon Q Business をカスタムアプリケーションに統合するための主要なステップについて説明しました。AWS Amplify を使用したフロントエンドのセットアップ、CDK を使用したQ Business アプリケーションの構成、iframe を介したチャットボットの埋め込みです。これらの AWS サービスとツールを活用することで、ユーザーの対話と知識へのアクセシビリティを向上させるAI駆動の検索体験を作成できます。 さあ、あなたの番です！会話型 AI をアプリケーションに埋め込み、Amazon Q Business で新しいレベルの生産性と意思決定を解き放ちましょう。そして、 Amazon Q Developer で開発ワークフローを強化しましょう。生成 AI とクラウドコンピューティングのパワーを活用して、開発を加速し、イノベーションを推進するモダンなアプリケーションを迅速に構築しましょう。 本記事は「 From Build to Embed: Creating and Embedding GenAI Apps with AWS Amplify, CDK, and Amazon Q Business 」翻訳したものです。 Ben-Amin York Jr. Ben-Amin は、フロントエンド Web およびモバイル技術を専門とする AWS ソリューションアーキテクトで、自動車および製造業企業のデジタルトランスフォーメーションを支援しています。 Dianne Eldridge Dianne Eldridge は、AWS で産業用 AI のグローバルビジネス開発をリードし、2021 年以降の戦略と成長を推進しています。それ以前は、エマーソンで 20 年間、米国、中国、イタリアにわたるグローバル製造ポートフォリオを監督していました。 Vaidehi Patel Vaidehi Patel は、AWS のソリューションアーキテクトで、自動車および製造業企業をサポートしています。彼女はサーバーレスと Amazon Connect を専門とし、顧客がイノベーションとデジタルトランスフォーメーションを推進するための AI/ML および生成 AI ワークロードの設計とスケーリングを支援しています。 Dexter Pham Dexter Pham は、AWS のソリューションアーキテクトで、自動車および製造業セクターの企業顧客がビジネスおよび技術目標を実現するのをサポートしています。彼はインフラストラクチャ、データ、AI/ML をカバーするクラウドジャーニーで顧客をサポートし、VMware および SAP ワークロードを専門としています

Part 1 では、生成 AI がスマート製品にもたらす価値と、顧客体験を向上する事例について、 AWS Summit Japan 2025 で展示する e-Bike デモのユースケースを元にご紹介しました。このブログ Part 2 ではソフトウェア開発ライフサイクル (SDLC) の複数フェーズに生成 AI を活用し得た洞察をお伝えします。 Part 1 で紹介したデモの開発に当たり、私たちは調査・設計・開発等に生成 AI をフル活用し、 Amazon Q Developer や Amazon Bedrock に 99% 以上のコードを生成させました。 スマート製品の開発における課題 スマート製品とサービスの開発においては、製品開発サイクルの短縮、顧客ニーズへの迅速な対応、そして継続的な製品改善が求められ、開発者やプロダクトマネージャーは多くの課題に直面しています。特に、ハードウェアとソフトウェアの融合によるスマート製品の開発では、複雑な技術統合と顧客体験の最適化が求められます。 スマート製品開発における SDLC 特有の課題 スマート製品の提供企業はソフトウェアの割合を増やし、その開発スピードや生産性を高めることが必要ですが、このためには、製品開発ライフサイクル全体を強化し、組織のアジリティを向上させる必要があります。スマート製品ではハードウェア製品とサービスを同時に取り扱うため開発プロセスが異なる両者を融合しながらアジリティを高めるのはより困難な課題です。 これらの課題に対応するためには、ハードウェアや属人性の高い開発プロセスから脱却し、開発者の生産性を最大化するソリューションが必要です。これまで、私たちは活用した組み込みソフトウェア開発の課題をクラウドで解決する方法について提案してきました（ https://aws.amazon.com/jp/blogs/news/embedded-software-on-aws/ ）。 生成 AI の出現は、さらにソフトウェア開発に共通の開発タスクや、組み込み固有のコーディングスタイルの準拠といった要件にも対応し、スマート製品開発の課題をさらに広く解決することができます。 製品開発ライフサイクルにおける生成AI活用の新しいパラダイム 一般的に、ソフトウェア開発のライフサイクル (SDLC) は、以下のようなフローで行われます。 図: ソフトウェア開発ライフサイクルの例 Research（調査）: ビジネス価値調査、UI(User Interface) Mock 作成、機能要件調査 Plan（計画）: 要件定義、仕様書作成、手順書作成、サブタスク分解、設計図作成 Development（開発）: コーディング、テスト、修正、リファクタリング Release（リリース）: デプロイ計画、IaC(Infrastructure as Code) 、継続的デプロイメント、マルチ環境対応 Operation（運用）: 監視、調査・分析、復旧対応、可観測性 ソフトウェア開発ライフサイクルを加速するための２つのポイント：タスクの効率化と、協調開発プロセス SDLC に生成 AIを導入し開発プロセスを加速するためには、1) 個々のタスクの効率化と自動化 2) 計画的・段階的に開発を進めるための AI と協調した開発手法 の２つの側面から考える必要があります。 製品開発におけるタスクの効率化と自動化 SDLC 内のタスクには様々なものがあり、上流においては企画のための調査やプロトタイピング、アーキテクチャの検討や設計や文書化、コーディングやテストなど多岐にわたります。今回、生成 AI を効率化に活用した様々なタスクを、SDLC 各フェーズでの実践的活用事例セクションに記載しました。 生成 AI を活用した人間と AI の協調モデル 生成 AI を使った開発でも、事前に作成した完璧な仕様書から一気にコードが出力される、といったものではありません。 実際の開発では、仕様は徐々に固まり、作業は段階的に行われていきます。また、生成 AI の特徴として、大規模なプロジェクトでは、生成 AI が一度に読み込める情報（トークン）量の限界があります。現在人と AI エージェントが対話している内容は記憶されていますが、エージェントを再起動したり、複数のエージェントを活用する場合には履歴に頼ることはできません。 したがって、人間同士の開発と同じように、たとえば要件を基に設計方針、設計、仕様といった形にフェーズに合わせた粒度の文書を作成し、検討結果を記録し固定化します。その過程で、たとえば、変動してはならない API 層の定義や、データフォーマット等の仕様なども追加されていきます。こうした文書の内容を生成 AI に提案させ、それを人間がレビューや修正を行ってプロジェクトの成果物として保存していきます。 時間軸においても、すべての開発を一気に行うのではなく、全体をいくつかのマイルストーンに分けてそれぞれの目標を設定し、段階的に作業を進めることで、スケジュールや要件を守り、時には前の状態にプロジェクトを戻しながら開発していくことができます。生成 AI の能力はここでも発揮され、マイルストーンに向けたタスクの細分化や順序を提案してくれます。タスクレベルに分割された作業は、チケット管理システムと連携することによって、生成 AI 自身がその進捗を逐次報告することができます。 上記はいずれも人間同士の開発でも行われている方法であり、生成 AI でも同じような方法の実践により分担・分割して開発を進めることが必要になります。 人間と生成 AI による協調開発の実践：1. 生成 AI からの提案と、ドキュメントに基づく同意 デモアプリケーションの仕様策定では、Amazon Q Developer の支援を受けて 要件設計書・機能設計書の作成を効率化しました。特筆すべきは、曖昧な指示に対してもコンテキストを適切に理解し、e-Bike に特化した詳細な仕様を提案できる点です。 開発者は提案内容を確認しながら、 不明点について深掘りした質問を行う 不要な仕様の削除を依頼する 新しいアイデアについてブレインストーミングを行う といった対話的なプロセスを通じて、仕様を確実に固めていくことができました。 人間と生成AIによる協調開発の実践：2. チケットベース開発への移行 デモ開発においては、開発規模の拡大に応じてチケット管理システム (Issue Tracking System) を導入し、生成 AI への指示と生成 AI からの報告をチケットで管理しました。これは現在の AI コーディングエージェントの課題に対する一つのソリューションです。 近年 AI コーディングエージェントは自然言語による対話によって高度なアプリケーション開発を実現しますが、規模が大きくなるにつれ、対応が困難になっていきます。これはあたかも優秀な一人の開発者がチームによる大規模開発で必ずしも成果を発揮できないことに似ています。タスクを分割してチケットによりアサインすることで、複数エージェントを混乱なく活用し更に生産性を上げることも可能になりました。 図: チケット管理システムを介した新しいワークフロー 人間と生成AIの役割 人間と生成 AI による協調開発を進めると、人間と生成 AI の適切な役割分担のモデルが生まれます。私達の経験から、この概念は複数の人間による開発の場合と大きな違いはないと考えられます。生成 AI が開発のタスクを担うことで、これまで開発者だった人間がリーダーとしてチーム開発を行う姿に移行していくと考えられます。 人間の役割 ： 創造的な目標設定とビジネス判断 優先度決定と戦略的方向性の管理 成果物の品質確認と最終承認 Amazon Q Developerの役割 ： 反復的なコーディングとテスト実行 ドキュメント作成と分析作業 技術的な実装と問題解決 図: 人間と AI による協調開発の流れ SDLC 各フェーズでの実践的活用事例 また、SDLC の各フェーズにおいて、下記のような様々なタスクを生成 AI によって効率化しました。 リサーチフェーズでの活用: 市場調査 ： 製品企画段階では、市場動向、競合分析、顧客ニーズの把握が不可欠ですが、従来は多くの時間とリソースを要するタスクです。今回、「 Bedrock Tool-use Reporter 」を活用し Web の情報収集から、「市場規模、成長予測、競合状況、調査」を行うことで、AI 分析機能が提案するビジネス改善内容が説得力をもてるようになりました。 図: デモにおける Bedrock T00l-use Report を用いた市場調査報告の活用 組み込みアプリケーションのプロトタイピング ： HMI の GUI デザインにおいて、Amazon Q Developer を活用して HTML ベースでイメージを生成し、デモの具体的なビジョンを構築しました。詳細な指示によるイメージの微調整が可能で、最終的には組み込み機器上で動作する Qt (クロスプラットフォームのアプリケーション開発フレームワーク) ベースの実装へと変換することができました。 組み込みアプリケーションの仮想化アーキテクチャ検討 ：開発効率化のために、組み込みアプリケーションを実機と仮想環境の両方で動かすことが必要です。私たちはこれを実現するアーキテクチャを Amazon Q Developer に提案させました。 図: Amazon Q Developer が提案した組込ハードウェアとAWSの間で可搬性のあるアーキテクチャ Web アプリケーションプロトタイピング ：サービスダッシュボードアプリの企画・プロトタイピングにおいても、Amazon Q Developer は、自然言語での要求を理解し、曖昧な要求から、UI が実際に動くダッシュボードを迅速に生成し、早期にイメージを共有して進めることができました。 計画フェーズでの活用: 仕様策定 : モックやユーザーストーリーなどの断片的な情報をもとに、ソフトウェアとして必要な仕様を Amazon Q Developer はベストプラクティスをもとに策定しました。我々はそれをレビューし、さらなる追加要件を加えたり、設計の改善を指示することで仕様を確定していきました。 この過程においては前述のチケット管理システムによる協調作業が大きく役立ちました。 開発・リリースフェーズでの活用: テストコードの生成と不具合調査 : Amazon Q Developer はテストコードを生成したりコードレビューを行う機能を持ちます。さらに画像を認識する機能をもつため、フロントエンドアプリケーションの不具合を画像のキャプチャから理解し原因を調査することができ、不具合の改修に役立ちました。 デバッガーの使用: 組み込みアプリケーションの不具合解決にはデバッガの利用が不可欠ですが、GDB や LLDB といったデバッガへのインターフェイスを Amazon Q Developer CLI で実現できたことにより、従来、開発者が手動でコマンドを入力しながら進めていたデバッグ作業が大きく効率化され、専門的なスキルが不足している開発者でも、効率的なデバッグ作業を行えるようになりました。 Webアプリケーション多言語対応: グローバル展開を見据えた多言語対応において、Amazon Q Developerの威力を実感し、メッセージやデータベースの使い分けなどの7ヶ国語対応をわずか2日で実装完了しました。 運用フェーズでの活用: AI 分析機能評価用データ生成の効率化 : 開発したデモはサービス運用そのものの AI 活用可能性を示しています。AI を活用することで、多数の要因から改善策を立案する仕組みは ブログ Part 1 をご覧ください。 クラウド連携するデバイスのトラブルシューティング : スマートプロダクト開発では、デバイスと AWS クラウドの連携時の問題解決が課題でした。 Amazon CloudWatch は強力な監視ツールですが、複雑な操作が必要でした。これに対し Amazon Q Developer は自然言語での指示を解釈し、適切な CloudWatch クエリを自動生成を行います。デバイス開発者でも容易にクラウド側の問題分析が可能となり、トラブルシューティングの効率化と運用コストの削減を実現しました。 プロジェクトの成果 こうして開発したプロジェクトで、私たちは以下の成果を得ました。 デモシステムのアーキテクチャ（クラウド部分 ＆デバイス）を設計 図: Amazon Q Developer の提案により開発したシステムのアーキテクチャ (上: e-Bike サービスダッシュボード、下: e-Bike プロダクトデモ ) デバイスソフトウェアを含むアプリケーションの企画開発の効率化 調査やプロトタイピングによる企画段階の加速 クロスプラットフォーム対応の HMI アプリケーションを開発 AI 分析機能を搭載したフリート管理の Web アプリケーションを開発 ローカル PC 開発からリファクタリングを重ねながら段階的に AWS 上へデプロイ デバッグやトラブルシュートといった専門知識を要する業務を自然言語の指示により簡略化 Amazon Q Developer で行った定量的な開発効果 50K Line 以上の Web アプリケーション(フリート管理アプリ)を ２ 名で開発 チケット管理システムで、400 件以上の Issue を Amazon Qとの協調作業で完了 1 週間ごとの開発リリースサイクルを実現 ダッシュボードの多言語対応（７カ国語）を２日で実装 まとめ このように、私たちは SDLC 全フェーズにおいて生成 AI を活用し、各タスクを効率化するとともに、生成 AI を活用した協調開発における知見を得ることができました。 体験機会のご案内 スマート製品の開発に興味をお持ちの方は、 AWS Summit Japan 2025（6月 25-26 日、幕張メッセ） の 製造ブース にて、実際の e-Bike デモをご覧いただけます。 今後も、生成 AI を活用したスマート製品開発の可能性を探求し、製造業のデジタル変革を支援してまいります。AWS のサービスを活用したスマート製品ソリューションにご興味のある方は、ぜひ お問い合わせ ください。 このブログは AWS Japan のソリューションアーキテクト 吉川 晃平、村松 謙、山本 直志が共同で執筆しました。ソリューションデモは執筆者たちと西田 光彦、中西 貴大が開発しました。

こんにちは！ソリューションアーキテクトの中西です。 AWS Summit Japan 2025 で展示予定の「IoT ミニ四駆よ！ シリコンバレーの風を切れ」は、懐かしのミニ四駆に IoT 技術と AI を組み合わせ、製造業への転用可能性も秘めたデモとなっています。 図1: IoT ミニ四駆がサーキットを走行し、リアルタイムでテレメトリデータが可視化される様子 このデモでは、リアルタイムデータ収集、AI による自律制御、予知保全といった技術要素を、誰もが親しみやすいミニ四駆で体験いただけます。楽しさの中に本格的な産業技術の可能性を発見していただける内容となっています。 デモで体験できること このデモでは、製造業の DX を支える 3 つの技術を体験いただけます。 図2: IoT ミニ四駆デモの AWS アーキテクチャ構成 1. リアルタイム可視化 ミニ四駆に搭載されたセンサーから、バッテリー電圧、モーター温度、速度、加速度などのテレメトリデータを AWS IoT Core 経由でリアルタイム収集し、 Amazon Timestream に蓄積します。収集されたデータは Web ダッシュボードで可視化され、まるで F1 マシンのように走行中のミニ四駆の状態が一目で把握できます。 2. AI エージェントによる分析・実況 Amazon Bedrock を活用した AI エージェントが、Amazon Timestream に蓄積されたデータを AWS Lambda 経由で分析し、レースの実況解説を行います。「モーター温度上昇中！限界走行だ！」といった熱い実況から、「バッテリー残量から判断して省エネモードに切り替えます」といった冷静な分析まで、AI が多角的にレース状況を解説します。 3. AI による自律制御 最も注目すべきは、クラウド上の AI エージェントによる自律制御機能です。ミニ四駆自体は判断を行わず、センサーデータを AWS IoT Core に送信し、クラウドからのスロットル制御指令を受け取るだけのシンプルな構成です。一方、クラウド側では Amazon Bedrock の AI エージェントが AWS Lambda 上で動作し、収集されたテレメトリデータを総合的に分析して状況を自律的に判断、最適な制御指令を AWS IoT Core 経由でミニ四駆に送信します。 図3: 本展示のために製作された IoT ミニ四駆 AI エージェントの個性豊かな制御 このデモの特徴的な点は、それぞれのミニ四駆を制御する AI エージェントが異なる「個性」を持っていることです。陽気なギャル系、熱血漢、上品なお嬢様、忠実な執事といった多様なキャラクターの AI エージェントが登場します。 図4: テレメトリのリアルタイム可視化ダッシュボードと AI によるインサイトが流れるチャット画面 これらの AI エージェントは、ミニ四駆から送信される同じテレメトリデータを受け取っても、それぞれの「性格」に応じて異なる判断を下し、個別の制御指令をミニ四駆に送信します。ミニ四駆は単純にその指令に従うだけですが、観客の皆様は AI の多様性と意思決定プロセスを楽しみながら体験できます。 製造業への応用可能性 予知保全 「温度限界チャレンジ」では、意図的にモーター温度を上昇させ、危険レベルに達した瞬間に AI が自動停止を実行します。これは製造現場での設備保護と予知保全の実際の動作を、目で見て体験できる貴重な機会です。 故障診断の自動化 「AI トラブル診断」では、意図的に異常状態を作り出し、AI がテレメトリデータから異常を特定・診断します。横転、スタック、追突など様々なトラブルを AI が瞬時に判断し、適切な対処法を提示します。 データドリブンな自律制御 AI エージェントは 1 分毎にミニ四駆から送信されるテレメトリデータを分析し、比較的曖昧なプロンプトからでも状況を理解して、「全力アタックモード」「省エネモード」「安定走行モード」など、AI が最適と思う制御指令を自律的に生成・送信します。 このデモでは、AWS IoT Core、Amazon Bedrock、AWS Lambda、Amazon Timestream、 Amazon API Gateway といった AWS サービスが連携して動作しており、ミニ四駆という親しみやすい素材を通じて、複雑な産業技術を直感的に理解できるよう設計されています。 AWS Summit Japan 2025 でぜひ体験を！ このデモの真の価値は、「楽しさ」を入り口として、本格的な産業技術を体験できることにあります。ミニ四駆という親しみやすい素材を通じて、IoT、AI、リアルタイムデータ処理といった最新技術の可能性を実感していただけます。 AWS Summit Japan 2025 （6 月 26 日）の AWS Builders’ Fair で、実際にリアルタイムでデータが可視化される様子、そして AI が自律的に判断を下してミニ四駆を制御する瞬間を、ぜひその目でご確認ください。製造業の DX、IoT の活用、AI による自律制御に興味をお持ちの方はもちろん、単純にミニ四駆が好きな方も楽しめる内容となっています。 イベント後には、より詳細な技術解説ブログも予定しており、実装の詳細や応用事例についてもご紹介する予定です。会場でお待ちしております！ なお本展示の他にも 製造業のお客様向け展示 がございます。関連ブログをいくつかご案内します。 AWS Summit Japan 2025 製造業ハイライト展示の見どころ紹介！ | Amazon Web Services ブログ AWS Summit Japan 2025 ブース紹介 スマート工場で実現するオペレーションの最適化 | Amazon Web Services ブログ AWS Summit Japan 2025 ~ 生成 AI とグラフデータを活用した 業務横断データ活用（Digital Thread）の展示のご紹介 | Amazon Web Services ブログ イベント情報 イベント名 : AWS Summit Japan 2025 日程 : 2025 年 6 月 26 日（Day 2） 場所 : AWS Expo の AWS Builders’ Fair 内。詳細は こちら 。 デモ名 : IoT ミニ四駆よ！ シリコンバレーの風を切れ ブースID : B-082A 皆さまのご来場を心よりお待ちしております。 著者紹介 中西 貴大 (Takahiro Nakanishi) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト AWS Japan のソリューションアーキテクトとして製造業のお客様をご支援しています。好きな AWS サービスは AWS IoT Core です。機械も含めてものづくり全般が好きで、自分と同い年の愛車を整備したり、 製造業の設計開発領域での AI 活用 – 「身体性」の原理から考える というブログを書いていたりします。 松本 修一 (Shuichi Matsumoto) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト アマゾンウェブサービスジャパン合同会社のソリューションアーキテクトです。普段は製造業のお客様のご支援を中心に活動しています。趣味はオンラインゲームで、日々インターネットの向こうにいる仲間たちと冒険に出かけています。 西亀 真之 (Saneyuki Nishigame) アマゾン ウェブ サービス ジャパン合同会社 ソリューションアーキテクト AWS Japan のソリューションアーキテクトとして製造業のお客様をご支援しています。好きな領域は IoT とロボットです。趣味はボルダリングでオフィスにあるボルダリングウォールにトライしています。

こんにちは。ソリューションアーキテクトの松本侑也です。普段はパブリックセクター技術統括本部で自治体のお客様の技術支援を担当しています。 2025 年 6 月 17 日に「自治体事業者向け AWS ガバメントクラウドワークショップ 2025 in 東京」を開催しました。このイベントは、ガバメントクラウドへの標準化対象業務システムの移行を進める上で必要となる技術について深く学び (Dive Deep)、実践的なワークショップを通じて技術スキルを高め、さらに参加者同士の交流 (Have Fun) を目的として開催されました。本ブログでは、イベント内容を簡単にご紹介しつつ、当日のセッションやワークショップの様子を共有いたします。 また、同日に中央省庁向けガバメントクラウドワークショップ、夜には Gov-JAWS 第2回 も開催され、約 140 人が参加する大規模なイベントになりました。 イベント概要 「AWS ガバメントクラウドワークショップ 2025」を以下のような形で実施しました。 日時 : 2025 年 6 月 17 日 (火) 13:00-18:30 (懇親会 + Gov JAWS: 18:30-21:00) 場所 : アマゾン ウェブ サービス ジャパン合同会社 目黒オフィス 参加対象 : 運用管理補助者、ASP、自治体向けパッケージ開発者の方々、自治体 前半：事例セッション まず前半では、実際の導入事例に基づいた2つのセッションを実施しました。 生成 AI によるガバメントクラウド運用管理補助業務の効率化 – ネットワーク運用管理補助における生成 AI の具体的な活用例 標準準拠システムのモダナイズとコスト最適化 – 健康管理システムのクラウド移行とアーキテクチャ刷新の実例 後半：テーマ別ワークショップ 後半は、参加者が以下の4つのワークショップから自身の関心や課題に合わせて選択できる形式を採用しました。 ワークショップ名 主な内容 耐障害性・可用性設計ワークショップ 障害耐性評価と復旧プロセスの体験 ガバメントクラウド IaC、CI/CD ワークショップ マルチアカウント環境での CDK デプロイ自動化 ⽣成 AI による開発・運用効率化ワークショップ 生成 AI による業務効率化と開発支援の実践 セキュリティインシデント疑似体験 GameDay セキュリティインシデント対応と調査手法 事例セッションで得た知識をどう実践するのか、具体的に学ぶことができる構成となっていました。 事例セッション – ハイライト 生成 AI によるガバメントクラウド運用管理補助業務の効率化 株式会社大崎コンピュータエンヂニアリング 久保田 亨 氏より、自治体向け標準 20 業務システムを展開する中での生成 AI 活用事例をご紹介いただきました。ガバメントクラウドにおけるネットワーク運用管理補助業務を、生成 AI でどのように効率化したかについて、具体的な実装事例をお話しいただきました。 特に印象的だったのは、セキュリティアラート分析の自動化や複雑なログ解析を生成 AI により効率化した事例です。また、生成 AI を導入する際の地方自治体との調整内容など、実務的な知見も共有いただきました。参加者からは「具体的な適用シナリオがイメージしやすくなった」という声が聞かれました。 詳細については、以下のブログ記事もご参照ください。 【寄稿】生成 AI 活用によるガバメントクラウド環境運用管理補助業務の効率化 | Amazon Web Services ブログ 標準準拠システムのモダナイズとコスト最適化 日本コンピューター株式会社 嶋田 忠相 氏より、標準化業務である健康管理システム「WEL-MOTHER」のモダナイゼーション事例についてご講演いただきました。クラウド移行による具体的なメリットとして、コスト改善や AWS CDK を用いたインフラ構築作業の効率化について詳しくご説明いただきました。 実際のアーキテクチャ図を用いた説明は、参加者にとって非常に参考になったようです。特に、従来のオンプレミスシステムからクラウドへの移行における考慮点や、ガバメントクラウドならではの要件対応について、具体的な手法が示されました。 テーマ別ワークショップ 耐障害性・可用性設計ワークショップ このワークショップでは、AWS における障害への備え方やサービス継続性の考え方を学びました。座学では「レジリエンス (障害への耐性) 」の基本的な考え方や、コストとのバランス、障害時に備えた設計パターン (バックアップ・ウォームスタンバイ・マルチサイト構成など) を体系的に整理しました。 また、演習パートでは 各自に割り当てられた AWS アカウントの中で AWS Fault Injection Service を使用してアプリケーションに対して疑似的な障害を発生させ、リアルタイムで対応するという緊張感のあるシナリオを体験しました。復旧手順や設定の確認を通して、「設計段階からどう備えておくべきか」を身をもって体感できる内容でした。 ガバメントクラウド IaC、CI/CD ワークショップ 本ワークショップでは、Infrastructure as Code (IaC)や CI/CD を活用した、AWS のガバメントクラウド環境における開発・運用の効率化について学びました。ハンズオンでは、 AWS Code サービス群 や AWS CDK を用いた実践的な環境構築をするハンズオンを行いました。 特に、ガバメントクラウドなどで採用が進む構成を題材に、インフラとアプリケーションの責務分離、設定の一元管理の重要性、さらには Amazon RDS のようなリソースにおけるライフサイクル管理のベストプラクティスなど、実運用を見据えた設計上の注意点についても講義形式で解説しました。 参加者の多くが AWS Code サービス群 や AWS CDK の基本的な概念をすでに理解されていたため、講義ではそうした概要説明は最小限にとどめ、より実践的な構成管理の課題や改善に焦点を当てました。 信頼性が求められる自治体システムを例に、IaC による環境の一貫性確保や、セキュリティ・運用性の両立を意識した設計思想について、具体的な事例を通じて理解を深めることができました。 ⽣成 AI による開発・運用効率化ワークショップ 生成 AI の活用に関するワークショップでは、 Amazon Bedrock や Amazon Q Developer を使った実践的なセッションが行われました。生成 AI の概要解説から始まり、開発や運用業務での活用方法まで幅広くカバーしました。 参加者は Amazon Bedrock を使って、セキュリティアラート分析の自動化やドキュメント生成などの実用的なユースケースを体験するハンズオンを実施しました。特にガバメントクラウド特有の考慮点 (セキュリティやプライバシーへの配慮など) についても解説があり、安全に生成 AI を活用する方法への理解を深めました。 セキュリティインシデント疑似体験 GameDay このワークショップでは、AWS 上の典型的なセキュリティインシデントを想定し、ログ分析による調査手法について学びました。セキュリティイベントを検出してから、ログ調査で原因特定を行う一連の流れを体験しました。 参加者は各チームに分かれ、提供されたログデータから不審なアクティビティを特定し、インシデント対応策を検討するという実践的な演習に取り組みました。この演習は、ログ調査をすることで答えが分かるクイズで得点を競い合い、上位 3 チームに景品を授与するゲーム形式で進めました。 ゲーム形式の演習を通して AWS 環境の典型的なセキュリティインシデントと対策について理解を深めることができる内容となっていました。 Gov-JAWS コミュニティの活動紹介 ワークショップと併せて、 Gov-JAWS の活動も行われました。 Gov-JAWS は、AWS のユーザーコミュニティ「 JAWS-UG 」の支部として、公共分野における AWS 利用に焦点を当てた新しいコミュニティです。政府や自治体が進める公共分野のクラウド利用に関連する知識やノウハウを共有するための場として設立されました。 イベント当日は夜の部として Gov-JAWS 第 2 回 Meet Up が開催され、懇親会と併せて多くの参加者が交流を深めました。参加者からは「多くのベンダーの方々と情報交換ができ、普段なかなか話す機会のない方とも直接意見を交わすことができました。こうした場で顔を合わせることで、関係性がぐっと良くなると感じました。」という声が上がりました。このコミュニティを通じて、今後も公共分野でのクラウド活用に関する情報共有と横のつながりの拡大が期待されています。 まとめ 今回のワークショップでは、ガバメントクラウドにおける技術的な課題解決に焦点を当て、実践的な知識とスキルの習得を目指しました。「セキュリティ」「レジリエンス」「モダナイズ (IaC・CI/CD)」「生成 AI」といった様々な観点から、自治体基幹システムのガバメントクラウドへの移行を進める上で重要なテーマを深掘りすることができました。 参加者からは「実際の業務に活かせる具体的な内容だった」「他の事業者の取り組みを知ることができて参考になった」といった声が多く聞かれ、大変好評でした。 今後も、AWS ではガバメントクラウドの活用を支援するためのイベントや情報提供を継続して実施してまいります。 ガバメントクラウドに関するお問い合わせ AWS の公共チームではガバメントクラウドクラウド相談窓口を設けております。 ガバメントクラウド利用全般に関するお問い合わせについて、担当の営業およびソリューションアーキテクトがご回答いたします。ぜひご活用ください。 https://aws.amazon.com/jp/government-education/worldwide/japan/gov-cloud-advisory-site/ 著者について 松本 侑也 アマゾン ウェブ サービス ジャパン合同会社のソリューションアーキテクト。パブリックセクター技術統括本部に所属し、自治体のお客様の技術支援を担当。ガバメントクラウドにおける標準化対象業務システムの移行支援や生成 AI の活用支援に取り組んでいる。

「このシステム、全体像を見せてもらえますか？」この質問に即座に対応できる組織はどれくらいあるでしょうか。 多くの AWS ユーザーが直面している課題の一つが、インフラストラクチャの可視化です。AWS リソースの構築は Infrastructure as Code (IaC) を実現する AWS CloudFormation や AWS CDK などの発展により自動化が進んだ一方で、それらの構成図を作成する工程は依然として人の手に委ねられていることが多いのが現状です。 以下のような課題を抱えているチームは少なくないでしょう： AWS CloudFormation で管理している本番環境の構成図が古いままで、実態と合っていない 開発環境、ステージング環境、本番環境など、複数の環境の構成図を最新に保つのが困難 システム変更の際、アーキテクチャ図の更新まで手が回らない チーム内でアーキテクチャ図の描き方にばらつきがあり、レビューに時間がかかる このような状況は、以下のような問題につながる可能性があります： チーム間のコミュニケーションロスによる開発の遅延 システム変更時の影響範囲の見落とし 新メンバーのオンボーディングの長期化 セキュリティレビューやコンプライアンス監査への対応の複雑化 本記事では、これらの課題に対する新しいアプローチとして、定義されたドキュメントからアーキテクチャ図を生成するツールである Diagram-as-code と AWS が提供する生成 AI サービスである Amazon Bedrock を組み合わせることで、事前定義されたインフラ構成情報から自動的にアーキテクチャ図を生成し、効率的に管理する手法について実践的な例を交えて解説します。 前提：本記事は大規模言語モデル (LLM) の可能性を提示したもので、構成の規模・複雑度が大きい場合は、精度を高める工夫が追加で必要になります。また、 Diagram as code は、一般的にアーキテクチャ図をコードや定義ベースで管理する概念を指す用語としても使われています。しかし本記事では、特に言及がない限り、同概念を実現するYAML形式の定義ファイルからアーキテクチャ図を自動生成できるCLIツールを指す用語として使用します。 アーキテクチャ図生成の自動化 システム開発・運用においてアーキテクチャ図は不可欠です。アーキテクチャ図はシステムの全体像や各コンポーネント間の関係を視覚的に表現し、ステークホルダーのシステム理解を深め、コミュニケーションを円滑化します。しかしながら、アーキテクチャ図の作成と管理には相当な労力がかかり、アーキテクチャ図が存在しないまま進行しているプロジェクトや、更新が滞っており実態と異なるアーキテクチャ図しか存在しないといった状況はよくみられる課題です。 この問題に対し、アーキテクチャ図の自動生成を目指す取り組みは既に存在します。とはいえ、プロジェクトやシステムによって必要な表現や粒度が千差万別であるため、高度で繊細な作業が求められ、「やはり人の手で作成する方が正確で早い」という状況が続いているのが実情です。この現状に共感される方も多いのではないでしょうか。 近年、生成 AI の登場によって、この状況が変わろうとしています。生成 AI の曖昧な要件に対するタスク実行能力や、以前よりも拡大したコンテキストウィンドウを活用することで、構造化されていない文章からの情報抽出や構造化されたテキストへの変換が容易に可能となりました。これにより、アーキテクチャ図作成の自動化における大きな課題だった多様な要件の図への反映作業が簡略化できるようになります。 Diagram-as-code とは 本記事で紹介する Diagram-as-code は、事前に準備された構造化されたテキストベースから自動でアーキテクチャ図を生成するツールです。図の生成にあたって画像編集ソフトウェアや手作業での配置を必要としないため、効率的にアーキテクチャ図を作成・管理することができます。 本ツールの主な特長とユースケースは以下のとおりです： AWS アーキテクチャガイドラインに準拠した、一貫性のある図を簡潔に生成できます ヘッドレスブラウザや GUI に依存せず軽量で、コンテナですぐに始めることができます。これにより CI/CD での活用に親和性があります CloudFormation テンプレートからツールで使用する定義ファイル (Dac ファイル) への変換機能が存在するため、IaC を実現している環境でより一貫した図を生成できます CLI ツールとしての提供の他、Golang のライブラリとしても提供されており、例えば import して他の IaC ツール、AI システム、または描画 GUI ツールとの統合が可能です 拡張可能な定義ファイル形式により、AWS サービスに限らず、様々なクラウドプロバイダーやオンプレミスコンポーネントを含むダイアグラムの作成が可能です Diagram-as-code は CloudFormation テンプレートに類似したYAML形式のファイルを入力として、アーキテクチャ図を生成します。以下の図は活用中の CloudFormation テンプレートが存在する場合における Diagram-as-code の利用フローを示しています。 Diagram-as-code を活用すれば、既存の CloudFormation テンプレートからアーキテクチャ図を効率的に生成できます。しかし実際のプロジェクトで活用する段階においては、データフローやセキュリティ境界といった CloudFormation テンプレートに明示されていない要素をアーキテクチャ図に追加する必要が不可欠であり、この部分は依然として手作業による対応が求められます。さらに、目的に応じて表現の粒度や内容を変えたい場合、生成したい図ごとに手動での作業が発生します。そのため、用途の多様化やステークホルダーの増加、図に含まれるシステムの複雑さやリソース数に比例して、下図のように手作業の工数が増大していきます。 このように、IaC からのアーキテクチャ図の生成は、IaC に含まれない要件を反映する作業について効率化の余地が残されていました。 生成 AI によるアーキテクチャ図作成の自動化 Amazon Bedrock を活用した自動化のソリューション設計 この課題に対し、Amazon Bedrock と Diagram-as-code を組み合わせることで、より効率的かつ柔軟なアーキテクチャ図の生成が可能となります。 Amazon Bedrock は、フルマネージド型のサービスで、Anthropic、Cohere、Meta、Mistral AI、Amazon などの最先端の AI 企業が提供する高性能な基盤モデル (Foundation Model) を単一の API で利用できるほか、セキュリティ、プライバシー、責任ある AI に配慮した生成 AI アプリケーションを構築するための幅広い機能を提供します。 Amazon Bedrock を活用することで、本課題に対して以下の機能を実装できます： 要件解釈機能 : ユーザーが自然言語で入力した要件を理解する 構造化出力機能 : 理解した要件を含む構造化されたテキストを生成する 対話的最適化機能 : 生成結果に対するフィードバックを通じて出力したテキストの調整と改善を行う 前項で示した課題に対して Amazon Bedrock を取り入れた活用のフローは以下の通りです。ユーザーの自然言語での入力と CloudFormation テンプレートの情報から Dac ファイルの生成を行う手続きを Amazon Bedrock に任せることで、要件ごとに形式化された情報を手動で追加する作業を大幅に効率化できます。 中間定義ファイルの生成と直接描画手法の比較と考察 近年、マルチモーダル機能を持つモデルの発展により、モデルに対して入力から直接イメージを生成するよう指示する方法も可能になってきています。 入力から直接イメージを生成する方法と、一度中間ファイルを生成した後 Diagram-as-code のようなツールが描画を行う方法を比較した場合、後者には現時点で以下の特徴があります： 正確性と一貫性 定義されたフォーマットに従った出力を描画ツールが保証 コンポーネント間の関係性をドキュメントベースで明確に表現 修正の容易さと柔軟性 コードベースでの差分管理が可能 修正時にコードベースでの厳密な指示をすることも可能 検証とガバナンス イメージを生成する前に、生成された中間ファイルに対する検証が可能 上記特徴は、ツールが引き受ける責任範囲とモデルが引き受ける責任範囲の差分によって生じます。したがって、将来は利用シーンごとに AI エージェントなどがモデルと使用するツールの適切な組み合わせを選ぶ形になると予想されます。例えば開発の初期段階では入力からアーキテクチャ図生成までを全てモデルに指示する方が開発速度向上の観点から好まれるかもしれません。一方、運用のフェーズでは正確性を重視し、中間ファイルから生成する方法が選択されることが多いと予想されます。 なお、AWS Blog 「 Architecture to AWS CloudFormation code using Anthropic’s Claude 3 on Amazon Bedrock 」では、本記事と逆の変換プロセス、つまりアーキテクチャ図から CloudFormation コードを生成する手法を紹介しています。この手法と本記事のアプローチを組み合わせることで、初期段階のラフスケッチから IaC とアーキテクチャ図の双方を効率的に生成し、本番環境への移行をスムーズに実現できます。 具体的な活用例の紹介 本記事後半では、前半で説明したアーキテクチャ図を生成する方法の具体例を示します。このアプローチにより、AWS環境の可視化を自動化し、作業時間を大幅に削減できます。 Step0 前提条件 まずは前提となる活用シチュエーションの設定と解説を行います。 今回対象とするシステムは、以下で掲載されているAWS ソリューションの CloudFormation テンプレート（空白を除き約 2.6 万文字、リソース数 23 個) とします。 Cognito User Profiles Export リファレンスアーキテクチャ Step1 Diagram-as-code のセットアップ はじめに Diagram-as-code  を使用するための準備を行います。以下に示す通り、数ステップを完了することでツールの動作を確認することができます。 まず、以下いずれかの方法で awsdac をインストールします。 # Goを使用してインストール go install github.com/awslabs/diagram-as-code/cmd/awsdac@latest # macOS の場合 brew install awsdac 次に リファレンスアーキテクのチャページ から CloudFormation テンプレートファイルをダウンロードします。ダウンロードしたファイルをターゲットとした以下コマンドを実行すると、中間ファイルと描画結果である png ファイルの両方を作成できます。 awsdac cognito-user-profiles-export-reference-architecture.template --cfn-template --dac-file デフォルトでは一部の親子関係が明確なリソースを除いてアイコン間の関係情報が存在しないため、以下のように多数のリソースが横並びになった結果が表示されます。 中間生成ファイルを修正し、関係情報や位置情報を追加することで、元となる CloudFormation テンプレートでは表現できないリソース間の関係性やグループを表現することは可能です。しかし前述したように、リソースの数や要件の数に比例して作業時間が増大します。 Step2 Amazon Bedrock で利用するプロンプトの準備 効率よくリソース間の関係や要件を補完するため、Amazon Bedrock を活用することを考えます。まずは、モデルに入力するためのプロンプトを作成します。今回は、ユーザーの口語的な表現を Diagram-as-code のフォーマット に従った表現に変換するプロンプトを作成しました。 以下にプロンプトのサンプルを示します。 User: CloudFormation テンプレートとユーザー要件という2つの入力ソースに基づいて、Diagram-as-code の YAML ファイルを生成します。 CloudFormation テンプレートは<cloudformation-template></cloudformation-template>セクションに、ユーザー要件は<user-requirements></user-requirements>セクションに記載されています。 Diagram-as-codeファイル形式はYAML構文を使用し、3つの主要セクションで構成されています。また、<custom-rules></custom-rules>にカスタムルールセクションがあります。 <diagram-as-code-format> {DAC_FORMAT_INTRODUCTION} </diagram-as-code-format> <custom-rules> {CUSTOM_RULES} </custom-rules> <cloudformation-template> {INPUT_CLOUDFORMATION_TEMPLATE} </cloudformation-template> <user-requirements> {INPUT_USER_REQUIREMENTS} </user-requirements> 最終的なYAML出力を生成するには、以下の手順に従ってください: 1. CloudFormationテンプレートを確認し、図に表示する必要のあるAWSリソースの定義を抽出します。 2. ユーザー要件とカスタムルールを確認し、CloudFormationテンプレートに含まれていないシステムアーキテクチャに関する追加のコンテキストや詳細を収集します。 3. 以下の方法でDiagram-as-code YAMLファイルを構築します: - DefinitionFilesセクションでリソース定義ファイルの場所を指定する。 - Diagram-as-code形式に従って、Resourcesセクションでリソースとその関係を定義する。 - Diagram-as-code形式とカスタムルールに従って、Linksセクションでリソース間のリンクを定義する。 4. 最終的なYAML出力が入力ソースに基づいてシステムアーキテクチャを正確に表現していることを確認します。 <example> {INPUT_EXAMPLE} </example> 実際にプロンプトテンプレートを利用する場合、可変値となる部分は変数として定義しています。上記テンプレートに埋め込まれた5つの変数の用途は以下のとおりです。接頭辞として INPUT がついている変数は特に入力毎に変化する値として想定しています。 DAC_FORMAT_INTRODUCTION : ツールのバージョンアップとともに更新されるDiagram-as-code の仕様 CUSTOM_RULES : 美しい図を生成するためのヒント INPUT_CLOUDFORMATION_TEMPLATE : ユーザー入力となる、生成元の CloudFormation テンプレート INPUT_USER_REQUIREMENTS : ユーザーが生成する図の方向性を指示するための要件 INPUT_EXAMPLE : 生成の精度を向上させるためのサンプル。一度生成した図を編集したい場合も活用する Step3 プロンプトを使用したプログラムからの中間ファイルの生成と図の生成 Amazon Bedrock 上の Claude を利用し、文書化された要件から Diagram-as-code で利用可能なフォーマットを生成します。以下は一連の流れを実行するサンプルスクリプトです。 import boto3 import os import subprocess # プロンプトテンプレート prompt_template = """ <Step3 で記述しているため省略> """ # prompt_variables フォルダから入力用の変数を読み込む variables = {} for filename in os.listdir('prompt_variables'): if filename.endswith('.txt'): with open(os.path.join('prompt_variables', filename), 'r') as f: variable_name = os.path.splitext(filename)[0] variables[variable_name] = f.read().strip() # プロンプトテンプレートに変数を挿入 prompt = prompt_template.format( **variables ) # Amazon Bedrock Runtime client を作成 client = boto3.client("bedrock-runtime", region_name="us-east-1") model_id = "us.anthropic.claude-3-7-sonnet-20250219-v1:0" conversation = [ { "role": "user", "content": [{"text": prompt}], } ] # Amazon Bedrock へメッセージを送信 response = client.converse( modelId = model_id, messages = conversation, inferenceConfig={"maxTokens": 8192, "temperature": 0.2, "topP": 0.9}, ) response_text = response["output"]["message"]["content"][0]["text"] # 中間 Dac ファイル保存 yaml_filename = f"output.yaml" with open(yaml_filename, 'w') as f: f.write(response_text) # PNG ファイル生成 png_filename = f"output.png" try: subprocess.run(["awsdac", yaml_filename, "-o", png_filename], check=True) print(f"PNG ファイル生成完了: {png_filename}") except subprocess.CalledProcessError as e: print(f"PNG ファイル生成中にエラーが発生しました: {e}") except FileNotFoundError: print("Error: awsdac コマンドが見つかりません。") python ファイルを配置した場所に prompt_variables フォルダを作成し、以下の各テキストファイルを作成します。今回実行にあたって指定した内容を以下に示します。 DAC_FORMAT_INTRODUCTION.txt Diagram-as-code の Introduction guide に掲載された内容を記述しています。 CUSTOM_RULES.txt 整った画像を表示するためのヒントを記述します。今回記述した指示は以下の通りとなります。 全体に関する指示 - YAML構文に従い、回答に不要な説明や説明文を含めないでください。 - 回答の最初と最後にトリプルバッククォートのYAMLマーカーを含めないでください。 Links に関する指示 - 特に指示がない場合、CloudFormation template に含まれる Resource は全て表示してください。 - Resources の後に Links を出力してください - Links セクションでは、SourcePosition が S の場合、TargetPosition は N が望ましく、その逆も同様です。また、SourcePosition が E の場合、TargetPosition は W が望ましく、その逆も同様です。 - Links セクションの要素は、Resource セクションに存在する Resource 間でのみ接続する必要があり、存在しない Resource を Source もしくは Target に指定することはできません。 - Links セクションの要素には必ず orthogonal プロパティを追加し、Source から Target への方向を明示してください。 - AWS::Diagram::VerticalStackとAWS::Diagram::HorizontalStack はグループ化に使用し描画しないソースであるため、Link の Source と Target に指定しないでください。 - 同じ SourcePosition や TargetPosition を指定する Link が 3 つ以上存在する場合、2文字目に同じ方角を重ねた後、3文字目に違う方角を追加し Link が重なることを避けてください（例: 同じ Resource の同じ Position である N を指定する複数の Link が存在する場合、Position の値を NNE, NNW とすることで描画時の Link の重なりを避けることができます) Resource に関する指示 - 同じ Resource を 複数の Resource の Children プロパティに指定できません。子の親は必ず 1 つです。 - Resource が所属するグループを明示的に指定する場合は、AWS::Diagram::Resource を使用し、その Children プロパティにグループに所属させたい Resource を指定してください。 - 指示がありUserアイコンを表示した方が良い場合には、以下の表記を使用できます： ``` User: Type: AWS::Diagram::Resource Preset: "User" ``` Label に関する指示 - 同じ Resource を Target もしくは Source として指定する複数の Link があり、それぞれに Label がある場合、Label の重なりを防ぐため Label のプロパティに TargetLeftまたはTargetRight を使用してください。 - Resource アイコンの下には Label が付与されるため、SourcePositionがSのLink の Label は TargetLeft か TargetRight のプロパティ使用して配置してください 配置に関する指示 - VerticalStack の Children は西(W)から東(E)に描画されます。HorizontalStack の Children は北(N)から南(S)に描画されます。 - Userからの距離が2より大きい Resource については、HorizontalStackまたはVerticalStackをネストして使用することを積極的に検討してください。これにより Links で Resource を接続した時に、 Links がアイコンと重なる可能性が下がります - Vertical と Horizontal を交互に使ってリソースを配置することで図全体が一方向に長くならないようにしてください。 - 以下の優先度のルールに従って配置してください。優先度は値が小さいものが優先されます。 1. Link は SourcePosition: S と TargetPosition: N で固定してください。ただし、深い階層から浅い階層へフィードバックする Link のみ SourcePosition, TargetPosition に E もしくは W が許可されます。 2. AWSCloud (AWS::Diagram::Cloud) の中で AWS::Diagram::HorizontalStack で hierarchy を作成してください。hierarchy は User から辿れる Link 数です。hierarchy は何個作成しても構いません。 3. Link が交差しないように Children の順序を入れ替えてください。Link(A->D), Link(B->C) ならば VerticalStack(HorizontalStack(A, B), HorizontalStack(D, C)) が Link が交差しない HorizontalStack 内の Children の順序です。前の hierarchy の並び順から Link されている Resource の順序を決定してください。 INPUT_CLOUDFORMATION_TEMPLATE Step 0 で提示した CloudFormation テンプレート を使用します。 INPUT_USER_REQUIREMENTS 以下に示す、ユーザーや状況によって異なる要件を記述します。今回はソリューションのページは閲覧しているが、実際にデプロイされるリソースについては把握していないという状況を想定して記述しました。 - これは ユーザーが認証に使う Amazon Cognito User Pools のユーザー情報をエクスポートして、別のリージョンにバックアップするソリューションです。 - Cognito のユーザー情報がバックアップされまでの道筋を明確にしてほしいです - 各リージョンにどの AWS リソースが所属しているかを明確に示してください - 可能な範囲で役割ごとに関連する AWS リソース群をグループ化してその役割を明示して欲しいですが、AWS リソースの省略はしないでください - IAM と KMS に関する AWS リソース以外は全ての AWS リソースを必ず表示してください INPUT_EXAMPLE.txt 今回の実行時は空白の状態にしています。一度生成したファイルを修正したい時はこちらに記載します。 Step4 実行結果の確認と修正 上記手順を実行した際に生成したアーキテクチャ図の例を複数以下に記載します。 デフォルトで生成された図 はアイコンが横並びでしたが、以下より、配置がグループ化されリソース間の関係が確認できます。指示の通りリージョンの要素が表示され、IAM や KMS の情報は逆に含まれないことなどが確認できることから、ユーザー要件がモデルによって解釈され適切な中間ファイルがモデルによって生成されていることが確認できます。 この後は、生成された中間ファイルを入力とし、追加の要件や修正の指示を与えることで、よりきめ細やかな表現の調整が可能です。 また、より正確性を求める場合、生成された中間ファイルと入力として使用した CloudFormation テンプレートのそれぞれに含まれるリソース情報の差分を YAML 形式で解析して抽出し、図の生成に使用されているリソースと入力に含まれているリソースが一致しているか、意図した通りのリソースの省略が行われているかの確認をスクリプトベースで実現することも可能です。 サマリー 本記事ではアーキテクチャ図の生成管理に関する既存の課題について説明し、生成 AI を活用することで課題を解決し、容易に環境を視覚化する新しいインフラストラクチャ管理の方式を紹介しました。さらに、Diagram-as-code と Amazon Bedrock を組み合わせ、中間ファイルを生成した後にアーキテクチャ図を生成する手順を示しました。 紹介した方法は、直接アーキテクチャ図を生成する代わりに、描画するための情報を含んだ中間ファイルを生成します。これは生成 AI でプロンプトから直接図を生成する方法と比較すると 1 ステップ手間が増える一方、生成した図の微修正の容易さや中間ファイルに対する検証が可能であるというメリットもあります。本記事では Diagram-as-code というツールにて実例を示しましたが、利用シーンごとに別のツールを利用する場合でも同様の構成が実現できます。 本記事を参考に、中間生成したファイルに対する検証チェックの実装や、CI/CD パイプラインへの組み込みなど、要件に応じた応用と発展の例が今後多数出てくることを期待しています。 著者 秋山 周平（ゲームソリューションアーキテクト） 北村 裕汰（クラウドサポートエンジニア）

6 月 17 日、重要な AWS リソースにどの AWS Identity and Access Management (AWS IAM) ロールとユーザーがアクセスしているかをセキュリティチームが検証するために役立つ、 AWS IAM Access Analyzer の新しい機能が発表されました。この新機能は、 Amazon Web Services (AWS) 組織内から付与されたアクセス権を包括的に可視化することで、既存の外部アクセス分析を補完します。 金融サービスやヘルスケアなどの規制対象業界内のセキュリティチームは、クレジットカード情報や医療記録が含まれる Amazon Simple Storage Service (Amazon S3) バケットといった機密データストアへのアクセスを検証する必要があります。これまで、チームは AWS Identity and Access Management (IAM) ポリシーの手動でのレビューに膨大な時間とリソースを費やしたり、内部アクセスパターンを理解するためにパターンマッチングツールを利用したりする必要がありました。 IAM Access Analyzer の新しい内部アクセス検出結果により、AWS 組織内の誰が重要な AWS リソースにアクセスできるのかを特定することができます。この機能は、自動推論を使用してサービスコントロールポリシー (SCP)、リソースコントロールポリシー (RCP)、アイデンティティベースのポリシーを含めた複数のポリシーをまとめて評価し、ユーザーまたはロールが S3 バケット、 Amazon DynamoDB テーブル、または Amazon Relational Database Service (Amazon RDS) スナップショットへのアクセス権を持つときに検出結果を生成します。検出結果は統合ダッシュボードに集約されるので、アクセス権の確認と管理がシンプルになります。 Amazon EventBridge を使用することで、新しい検出結果を開発チームに自動的に通知し、意図しないアクセス権を排除できます。内部アクセスの検出結果は、重要なリソースに対するアクセスコントロールを強化するための可視性をセキュリティチームに提供し、コンプライアンスチームがアクセスコントロール監査要件を実証するために役立ちます。 試してみましょう この新機能の使用を開始するには、 AWS マネジメントコンソール を使用して IAM Access Analyzer が特定のリソースを監視できるようにします。IAM に移動し、左側のナビゲーションメニューにある [アクセスレポート] セクションで [アナライザーの設定] を選択します。ここで、 [アナライザーを作成] を選択します。 [アナライザーを作成] ページで [リソース分析 – 内部アクセス] オプションを選択します。 [アナライザーの詳細] では、アナライザーの名前を好きなようにカスタマイズすることも、自動的に生成された名前を使用することもできます。次に、 [信頼ゾーン] を選択する必要があります。アカウントが AWS 組織の管理アカウントである場合は、組織内のすべてのアカウント全体のリソースを監視するか、現在ログインしているアカウントのリソースを監視するかを選択できます。アカウントが AWS 組織のメンバーアカウント、またはスタンドアロンアカウントの場合は、アカウント内のリソースを監視できます。 信頼ゾーンの選択に応じて、どの IAM ロールとユーザーが分析の対象と見なされるかも決定します。組織を信頼ゾーンとするアナライザーがリソースに対して行われる可能性のあるアクセスについて組織内のすべての IAM ロールとユーザーを評価するのに対し、アカウントを信頼ゾーンとするアナライザーは、そのアカウントの IAM ロールとユーザーのみを評価します。 この最初の例では、アカウントが管理アカウントであると仮定し、組織を信頼ゾーンとするアナライザーを作成します。 次に、分析するリソースを選択する必要があります。 [リソースを追加する] を選択すると、3 つのオプションが表示されます。まず、分析するアカウントとリソースタイプを特定することによってリソースを選択する方法を見てみましょう。 新しいインターフェイスでは、 [アカウントでリソースを追加] ダイアログを使用してリソースタイプを選択できます。ここでは、 [サポートされているすべてのリソースタイプ] を選択して、監視するアカウントを選択します。そうすることで、サポートされているすべてのリソースタイプを監視するアナライザーが作成されます。組織構造からアカウントを選択するか (以下のスクリーンショットを参照)、 [AWS アカウント ID を入力] オプションを使用してアカウント ID を貼り付けることができます。 [特定のリソースタイプを定義] ダイアログを選択することも可能です。これは、サポートされているリソースタイプのリストから選択するために使用できます (以下のスクリーンショットを参照)。この構成でアナライザーを作成すると、IAM Access Analyzer がアカウント内で選択したタイプの既存リソースと新規リソースの両方を継続的に監視し、内部アクセスをチェックします。 選択し終えたら、 [リソースを追加] を選択します。 また、 [リソース ARN でリソースを追加] オプションを使用することもできます。 あるいは、 [CSV ファイルをアップロードしてリソースを追加] オプションを使用して、特定のリソースのリストを大規模に監視するように設定することも可能です。 アナライザーの作成が完了すると、IAM Access Analyzer がポリシーを毎日分析し、組織内の IAM ロールとユーザーに付与されたアクセス権を表示する検出結果を生成します。新しくなった IAM Access Analyzer ダッシュボードでは、リソース中心のビューが提供されるようになりました。 [アクティブな検出結果] セクションでは、アクセスがパブリックアクセス、組織外からの外部アクセス (別の外部アクセスアナライザーを作成する必要があります)、組織内アクセスの 3 つの個別のカテゴリーに要約されています。 [キーリソース] セクションには、3 つのカテゴリー全体の上位リソースがアクティブな検出結果と共に表示されます。左側のナビゲーションメニューで [すべてのアクティブな検出結果を表示] または [リソース分析] を選択すると、分析されたすべてのリソースのリストを確認できます。 [リソース分析] ページでは、分析されたすべてのリソースのリストをフィルタリングして、さらに分析することができます。 特定のリソースを選択すると、利用可能な外部アクセスと内部アクセスの検出結果が [リソースの詳細] ページに一覧表示されます。この機能を使用して、選択したリソースに対して行われる可能性のあるすべてのアクセスを評価します。IAM Access Analyzer は、検出結果ごとに許可された IAM アクションや条件に関する詳しい情報を提供します。これには、該当する SCP と RCP の影響が含まれます。つまり、アクセスが適切に制限されており、最小特権要件を満たしていることをユーザーが検証できるということです。 料金と利用可能なリージョン この新しい IAM Access Analyzer 機能は、今日からすべての商用リージョンでご利用いただけます。 料金 は、監視される重要な AWS リソースの 1 か月あたりの数に基づいています。外部アクセス分析は、今後も追加料金なしで利用可能です。EventBridge については、料金が別途適用されます。 IAM Access Analyzer の詳細を確認し、重要なリソースに対する内部アクセスの分析を開始するには、 IAM Access Analyzer ドキュメント をご覧ください。 原文は こちら です。