みなさんこんにちは！ どちらかというと猫より犬が好きな Solutions Architect の高野です。一昨年、昨年の AWS Summit Japan でご好評いただいた Chaos Kitty がさらにパワーアップして AWS Summit Japan 2025 に帰ってきました！ 　 この記事では、2025 年の AWS Summit Japan の AWS Builders’ Fair 内の初日に展示される「Chaos Kitty で楽しくインシデント対応の基本を学ぼう！ 」についてご紹介します。本展示は、システムを構築する上でも重要なレジリエンスやセキュリティをゲームを通じて楽しく学ぶことができる体験型コンテンツです。システムのレジリエンスやセキュリティを強化したい全ての方に本記事を読んでいただき、実際に AWS Summit Japan の会場まで足を運んで体験いただけると幸いです。 　 AWS Summit Japan 2025 の開催期間は 2025 年 6 月 25 日 (水) と 26 日 (木) の 2 日間で、会場は幕張メッセになります。 本展示は初日の 6 月 25 日 (水) のみになりますのでご注意ください。 まだ AWS Summit Japan 2025 に登録してない方は こちらのページ からご登録ください。Chaos Kitty は、AWS Expo の AWS Builders’ Fair の中にあります。詳細は こちら 。 Chaos Kitty とは？ 　 Chaos Kitty は、AWS のアーキテクチャを物理的に表現し、インシデント対応の体験学習ができるソリューションです。Web 3 層の Web アプリケーションに異常を注入し、異常を修正するまでのタイムを競うことで、ゲーム感覚でインシデント対応の体験が行うことができます。詳細は 以前のブログ を確認下さい。 1. IoT 電球によるリアルタイムの状態可視化 　 物理的なブロックと電球で表現された Web 3 層アプリケーションのアーキテクチャにおいて、各コンポーネント (Amazon EC2、Amazon RDS、Amazon S3 など) の状態が IoT 電球の色で示されます。電球は、正常な場合には緑、何か異常がある場合には赤で点灯する設定になっており、設定に異常が検出された場合には、電球が緑から赤に変わる仕組みとなっています。これにより AWS 上のアプリケーションの状況をリアルタイムで監視でき、異常をすぐに検知することができます。 2. 障害挿入機能による対応訓練 　 IoT デバイス を操作すると AWS での設定に意図的に設定異常を注入し、IoT 電球の色が赤に変わります。ユーザーは AWS コンソールを使ってこの設定異常を特定・修復し、電球を緑に戻すゲームを行います。修復が完了すれば、修復にかかった時間が表示され、手動での対応の難しさを体感できます。 3. 自動修復機能による対応の効率化 　 注入された設定異常に対して、自動修復するスクリプトを実行する機能が用意されています。マネジメントコンソールを使用した手動修復と比べた自動化の優位性を実感できます。 図 1 : AWS Summit Tokyo 2025 版 Chaos Kitty 外観 図 2 : 障害注入対象の Web 3 層アプリケーション画面 新機能紹介 　 3 回目となる今回は、 できる限り多くの方に簡単にお試しいただけるように 以下パワーアップを行っておりますので、1 つずつご紹介します。 1. IoT 機器なしで設定異常注入・検知ができるように、Web アプリケーション機能追加 2. AWS Cloud Development Kit (AWS CDK) を活用してインフラストラクチャのコード化 (Infrastructure as Code (IaC)) を実装し、デプロイメントプロセスを標準化・自動化 3. 電子工作なしで本ソリューションが利用できるように IoT 関連のアーキテクチャ刷新 4. アプリケーション監視用のモニタリングダッシュボードに Amazon CloudWatch Application Signals を採用 IoT 機器なしで設定異常注入・検知ができるように、Web アプリケーション機能追加 　 今までの Chaos Kitty は IoT 機器での操作を前提としたソリューションとなっており、実際に皆様の環境にデプロイして利用いただくにはハードルが高いところがありました。そこで、今回は、今までのインシデント発生から修正までの時間測定だけ行なっていたWebアプリケーションを改修し、設定異常注入機能と、異常箇所検知・可視化機能を追加しました。これにより、IoT 機器なしで、本ソリューションをデプロイいただくだけで、インシデント対応を学習することができるようにしました。 　 Chaos Kitty はセキュリティ的に問題のある設定を注入する Security シナリオと、アプリケーション自体に障害を注入し利用不可にする Resilienency シナリオがあります。それぞれ 1 つだけ異常を発生させる Easy モードと複数の異常を発生させる Hard モードがあります。図 3 のような画面になっていまして、画面中央のゲームスタートボタンを押下すると、図 4 のように、タイマーがスタートし、Web 3 層アプリケーションの異常発生箇所 (図 4 の例では ALB の Security Group) が点灯し、異常箇所が分かるようになります。参加者の方はこれをヒントに AWS コンソール にログインして異常箇所の修正にチャレンジいただきます。是非タイムアタック No.1 を目指して頑張ってください！ 図 3 : Chaos Kitty Web アプリケーション画面 図 4 : 障害発生時の Chaos Kitty Web アプリケーション画面 AWS CDK を活用したインフラストラクチャのコード化 (IaC) 　 AWS Summit Japan にご来場いただく方に限らず、本ソリューションをご利用いただけるように、アーキテクチャを一部改修し、AWS CDK を活用した IaC 化を行い、AWS Samples として公開する予定です。これにより、利用したい方はコマンド数回で本ソリューションが簡単にデプロイできるようになります。個人での学習や、社内のシステム運用者教育等のイベントにご活用いただけますと幸いです。できる限り、AWS Summit Japan 2025 開催前、遅くとも 7 月中には AWS Samples で公開を予定しておりますので、ご期待下さい！ 図 5 : AWS Summit Japan 2025 版 Chaos Kitty アーキテクチャ概要 電子工作なしで本ソリューションが利用できるように IoT 関連のアーキテクチャ刷新 　 今まで Chaos Kitty を利用するには、Raspberry Pi に様々なソフトウェアをインストールして設定を行う必要がありました。この作業が非常に煩雑で大変なため、多くのお客様に利用いただくのが困難でした。そこで今回、IoT 回りの構成を刷新し、Echo デバイスからボタン一つで IoT 電球の色を変更できるようにアーキテクチャを刷新しました。裏側の仕組みは Alexa Skill と連携することで実現しています。本設定方法の詳細は、別途ブログにて詳しくご紹介する予定ですので、ご期待下さい！ アプリケーション監視用のモニタリングダッシュボードに Amazon CloudWatch Application Signals を採用 　 Chaos Kitty はインシデント対応を学習するためのものであり、ゲームとしてわかりやすくするために、アプリケーションの問題箇所を電球で可視化していますが、実際のシステムではそう簡単にはいきません。実システムでは、ユーザ影響がある障害が発生しているかどうか、すぐに確認・分析できるようにするためのダッシュボードによる可視化が有効です。前回の展示では、Amazon CloudWatch dashboards を使って必要なメトリクスやログ、トレースを表示するようにダッシュボードをカスタマイズして展示していました。今回は、Amazon CloudWatch Application Signals を使った標準的なダッシュボードを使い、サービスとして重要な指標を取得して可視化できるようにしています。監視対象アプリケーションには、 AWS Distro for OpenTelemetry を組み込み CloudWatch Agent と連携することで、必要なデータを取得して、Amazon CloudWatch Application Signals のダッシュボードで表示しております。是非、最新のモニタリング機能をご体感下さい！ 図 6 : CloudWatch Application Signals ダッシュボード画面 　 この他にも当日は、生成 AI を利用した障害分析効率化を図る AIOps を体感いただくために、AWS Japan の Solutions Architect が開発した障害分析ソリューション Failure Analysis Assistant (FA2) との連携デモをお見せします。生成 AI を活用することでどのように日々のシステム運用が効率化できるのかご体感下さい！ さいごに 　 Chaos Kitty は実際のインシデントを模擬する形でサービスの稼働状況を電球やブロックを使ってわかりやすく表現しております。日頃クラウドサービスに慣れ親しむ機会が少ない方でも、運用におけるインシデント対応を気軽に体験いただけます。AWS Summit Japan 2025 で、皆様にお会いできることを楽しみにお待ちしております！ アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 高野 翔史 Choas Kitty は AWS Japan ソリューションアーキテクトの服部 一成、堀 貴裕、佐々 拓也、津郷 光明、河角 修、鈴木 陽三、黒木 琢央、高野 翔史が中心となって開発しております。

みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 いきなりですが、 Amazon Q を使われていますでしょうか？いつも使っているという方も、まだという方にも、「 Amazon Q CLI でゲームを作ろう 」キャンペーンのお知らせです。タイトルにありますように、AIコーディングアシスタントである Amazon Q CLI を使って、ゲームを作ってみようという学習機会のキャンペーンです。6 月 20 日まで実施されており、参加いただいた方はもれなく T シャツを Get できます！参加のための ガイダンスブログ が出ておりますので、ご確認いただき、ぜひこの機会に Amazon Q CLI に触れてみてください！ それでは、先週の主なアップデートについて振り返っていきましょう。 2025年6月2日週の主要なアップデート 6/2(月) Amazon DataZone launches upgrade domain to SageMaker Amazon DataZoneとAmazon SageMaker は、DataZoneドメインを Amazon SageMaker にアップグレードして使用できる新しいユーザーインターフェース(UI) 機能を発表しました。これにより、既存の Amazon DataZone で作成・管理されたアセット、メタデータフォーム、用語集、サブスクリプションなどのすべてのコンテンツは、アップグレードすることで Amazon SageMaker Unified Studio の環境内で新しい SQL 分析、データ処理、AIのユースケースに拡張して利用できるようになります。アップグレードに関する詳細は、 こちらのドキュメント をご確認ください。 Second-generation Amazon FSx for NetApp ONTAP now available in the AWS Mumbai and Tokyo Regions Amazon FSx for NetApp ONTAP の第２世代ファイルシステムが、東京リージョンを含む２リージョンで利用可能となりました。第２世代ではFSx for ONTAP のスケールアウト構成が利用できること、そして最大 12 の高可用性（HA）ペアのファイルサーバーを作成または拡張が可能なため、第1世代と比較してより優れたスケーラビリティと柔軟性を提供します。なお、マルチ AZ 構成は 1 HA ペア のみとなります。 Introducing agentic capabilities for Amazon Q Developer Chat in the AWS Management Console and chat applications AWS Management Console、Microsoft Teams、Slack において Amazon Q Developer は複雑なクエリに対応ができる新しいエージェント機能を提供します。今回のリリースで、Amazon Q Developerは、基本的なAWSに関する質問に答え、専門的なガイダンスを提供するだけでなく、AWSの深い専門知識と新しいマルチステップ推論機能を組み合わせることで、複雑なクエリを解決することが可能です。例えば、「支払い処理のLambda関数から500エラーが発生するのはなぜですか？」と質問すると、自動的に関連するCloudWatchログを収集し、関数の設定と権限を確認し、API Gateway や DynamoDB などの接続されたサービスをチェックし、直近の変更に関する分析して、効率的な解決に導きます。 6/3(火) Amazon Q Developer now helps customers optimize AWS costs Amazon Q Developer が個別のコスト最適化の推奨事項を提供するようになりました。この新機能により、「AWS の請求額を下げるにはどうすればよいですか？」などの質問を Amazon Q Developer にすることで、インスタンスの適切なサイジング、Savings Plans や Reserved Instances の購入、アイドル状態のリソースの終了など、パフォーマンスリスクに基づいて優先順位付けされた推奨事項を受け取ることができます。また、「この推奨事項はどのように計算したのですか？」などの詳細なフォローアップ質問をすることもでき、メトリクス、構成、カスタマイズオプションを含む説明を受け取ることができます。この機能は米国東部（バージニア北部）リージョンで利用可能で、すべての商用 AWS リージョンにわたるコスト最適化の推奨事項を提供します。 Amazon API Gateway introduces routing rules for REST APIs Amazon API Gateway が、カスタムドメイン名を使用した REST API のルーティングルールをサポートするようになりました。この新機能により、HTTP ヘッダーの値、URL ベースパス、またはその両方に基づいて、受信リクエストを動的にルーティングすることが可能になります。API Gateway 内で直接ルーティングロジックを実装することで、プロキシレイヤーや複雑な URL 構造を排除しながら、API トラフィックに対する詳細なルーティング制御を維持できます。この機能はパブリックおよびプライベートの両方の REST API でサポートされており、既存の API マッピングとも互換性があります。 Amazon Athena announces managed query results to streamline analysis workflows Amazon Athena でマネージドクエリ結果という新機能を発表しました。マネージドクエリ結果は、一時的なクエリ結果ストレージを提供することで分析と管理のワークフローを効率化します。例えば、実行する分析のために新しいワークグループを作成する場合、Athenaに結果データを管理させることを選択することで、クエリ結果の S3 の場所を最初に指定することなくクエリを実行でき、結果が暗号化されることを保証し、さらに不要になった後のクエリ結果の保存にかかるコストを回避できます。 6/4(水) Amazon Redshift now supports increased concurrency for vacuum operations Amazon Redshiftは、データウェアハウス内のテーブル間での同時実行性を高めるため、バキューム処理を機能強化しました。バキューム処理は、テーブルデータの並べ替えと、削除された行からのディスク領域の再利用という2つの重要な機能を実行することで、最適なクエリパフォーマンスを維持します。Redshift はすでに、手動メンテナンスの必要性を最小限に抑えるための自動バキューム処理を提供していますが、今回の機能強化により、これらの処理は Redshift によって、より高い同時実行性で実行されるようになりました。さらに、ユーザーは異なるテーブルで複数の手動バキューム処理をセッション間で同時に実行することも可能になりました。 Amazon Lex extends custom vocabulary feature to additional languages Amazon Lexが、中国語、日本語、韓国語、ポルトガル語、カタルーニャ語、フランス語、ドイツ語、スペイン語において、カスタム語彙のサポートを拡張しました。この機能強化により、より広範な言語で、特定分野の専門用語、固有名詞、稀少語の音声認識精度を向上させることが可能となります。例えば、「Cognito」などの技術用語や「支払能力」などの業界固有の語彙が、ボットとのやり取りの中で正確に文字起こしされるようになり、一貫性のある音声認識機能を提供することができます。 Announcing Amazon RDS for PostgreSQL Extended Support versions R2 11.22-rds.20250508 and 12.22-rds.20250508 Amazon RDS for PostgreSQL にて、PostgreSQL データベースの重要なセキュリティアップデートとバグ修正を含む、延長サポートの マイナーバージョン11.22-rds.20250508および12.22-rds.20250508 を提供しました。Amazon RDS 延長サポートは、ビジネス要件を満たすために新しいメジャーバージョンへのアップグレードまでの期間を最大3年間延長することができます。延長サポート期間中、コミュニティがメジャーバージョンのサポートを終了した後も、Amazon RDS は RDS for PostgreSQL データベースに対して重要なセキュリティ修正とバグ修正を提供します。 6/5(木) Amazon OpenSearch Serverless now available in Asia Pacific (Hyderabad) and Asia Pacific (Osaka) regions Amazon OpenSearch Serverless が アジアパシフィック（大阪）リージョンで利用可能になりました。OpenSearch Serverlessは、Amazon OpenSearch Serviceのサーバーレスデプロイメントオプションで、インフラストラクチャ管理の複雑さを伴うことなく、検索および分析ワークロードを実行することができます。 Pricing and usage model updates for Amazon EC2 instances accelerated by NVIDIA GPUs Amazon EC2 P6-B200 インスタンスで Savings Plans が利用可能になりました。また同時に、Amazon EC2 P5 インスタンスで最大 45% 、P5en インスタンスで最大 26% 、P4dとP4deのインスタンスで最大 33% の価格引き下げとなりました。価格引き下げは、2025年6月1日からのオンデマンド価格と2025年6月4日以降の Savings Plan 購入分に適用されます。この新価格は、先進的なGPUコンピューティングをより利用しやすくするとともに、コスト削減分を直接お客様に還元するというAWSのコミットメントを反映しています。更新された価格の詳細については、 EC2 の価格ページ をご確認ください。 Amazon EC2 now enables you to delete underlying EBS snapshots when deregistering AMIs Amazon EC2で、Amazon Machine Images（AMI）の登録解除時に、関連する Amazon EBS スナップショットを自動的に削除できるようになりました。これまでは、AMIの登録を解除する際、関連するEBSスナップショットを別途削除する必要があり、追加の手順が必要でした。今回の機能により、AMIの登録解除時にEBSスナップショットを自動的に削除でき、ストレージコストの管理とAMIクリーンアップワークフローが簡素化されます。 6/6(金) AWS KMS launches on-demand key rotation for imported keys AWS Key Management Service (KMS)は、インポートされたキーマテリアルを持つ 対称暗号化KMSキー のオンデマンドローテーションをサポートしました。この新機能により、Bring Your Own Keys (BYOK)キーのキー識別子（キーARN）を変更することなく、暗号化キーマテリアルをローテーションすることができます。キーのローテーションにより、定期的なキーローテーションを義務付けるコンプライアンス要件とセキュリティのベストプラクティスを満たすことができます。 Amazon EFS and AWS Backup is now available in AWS Asia Pacific (Taipei) Region 台北リージョン(ap-east-2) がオープンとなりました。Amazon Elastic File System (Amazon EFS)、AWS Backup などのサービスも利用可能となっております。台北リージョンのオープンに関する詳細は こちらのブログ を、そして利用可能なサービスは こちら をご確認ください。 今月はいよいよ AWS Summit Japan が開催されます。参加予定の皆様には楽しみにしていただいているとは思いますが、少し先のこともあります。実は、12月1日から5日に ラスベガスで開催される AWS re:Invent 2025 の登録がすでに開始しております！AWS Summit Japan の情熱をそのままに、AWS re:Invent への参加もぜひご計画ください！ それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

現在のデジタル企業環境において、組織はますます資産管理ソリューションに依存して業務を合理化しています。企業は、複数の IT システムや運用技術 (OT) システムで同じ物理資産を管理する必要に直面することがよくあります。IT チームが企業の IT 資産を追跡・管理するのに役立つサービスの 1 つが ServiceNow です。このサービスは、ハードウェアやソフトウェアの在庫管理、サービス要求、ライセンスコンプライアンス、テクノロジーリソースの完全なライフサイクルを一元的に扱います。一方、OT 向けの AWS IoT SiteWise は、企業が産業機器のデータを大規模に収集、体系化、分析できる管理サービスです。このサービスでは、ライブおよび過去の運用データを統合リポジトリにまとめることができるため、組織は生産効率の向上と資産保守の最適化に役立つデータ駆動型の意思決定ができます。 ServiceNow と AWS IoT SiteWise を一緒に使う際に組織が直面する一般的な課題は、システム間で資産情報を一貫して維持することです。ServiceNow で資産階層が更新されると、運用チームは AWS IoT SiteWise でこれらの変更を手動で複製する必要があり、重複した作業や整合性が損なわれる可能性があります。このプロセスは時間がかかり、エラーが発生しやすく、両環境で同じ資産を管理する無駄が生じます。このブログ記事では、ServiceNow と AWS IoT SiteWise 間で資産データを同期する手法を紹介します。この統合パターンを実装することで、手動による更新を排除し、エラーを減らし、IT と OT プラットフォームで資産階層を一貫して維持できます。 ソリューション概要 このソリューションでは、AWS のサービスを使用して、ServiceNow と AWS IoT SiteWise の間の自動統合を実現しています。 ServiceNow の資産管理システムで変更があった場合、自動的に AWS IoT SiteWise に反映されるため、両システムの同期が維持されます。 図 1: アーキテクチャ 図 1 は 2 フェーズのデータフローを示しています。最初のフェーズ (Ingest) では、データが ServiceNow から Amazon AppFlow を経由して Amazon Simple Storage Service (Amazon S3) に移動します。2 番目のフェーズ (Import) では、データは AWS Glue を経由し、AWS IoT SiteWise に到達する前に Amazon S3 に戻ります。 両方のフェーズでは異なる目的がサービスされています。 インジェストフェーズ Amazon AppFlow は、ServiceNow のテーブル (Operations Technology (OT)、OT Entity、OT Entity Type) からアセットデータを取得します。 そのデータは、その後 Amazon S3 に parquet 形式 で格納されます。 インポートフェーズ AWS Glue は、Parquet ファイルを AWS IoT SiteWise がインポートできる JSON 形式 に変換します。 変換された JSON ファイルは、Amazon S3 に保存されます。 AWS IoT SiteWise は、アセット情報をインポートしてアセットモデルと階層を作成または更新します。 実装の概要 この投稿では、この統合を実装するための以下の段階を提示しています: Amazon AppFlow で ServiceNow コネクタを構成し、アセットデータを Amazon S3 に取り込みます。 AWS Glue ジョブを作成し、データを parquet 形式から JSON 形式に変換して、AWS IoT SiteWise インポートの必須フォーマットに一致させます。 Amazon S3 から AWS IoT SiteWise へのアセットインポートを設定します。 前提条件 このソリューションを実装する前に、次のものが必要です。 アセットテーブルへのアクセス権を持つ ServiceNow インスタンス。この例では、次のものを使用します。 Operations Technology (OT) ( cmdb_ci_ot ): ServiceNow からのOTデバイスレコード。これらのレコードには、名前、シリアル番号、モデル番号、メーカー、および場所情報などの基本的な属性が含まれます。 OT Entity ( cmdb_ot_entity ): OT エンティティインスタンスとそれらの関係を定義したレコードが含まれています。また、運用階層でデバイスがどのように接続されているかを表しています。 OT Entity Type ( cmdb_ot_entity_type ): OT エンティティ (Area、Process Cell、Unit、Equipment Module など) のタイプまたはカテゴリを定義したレコードが含まれています。また、運用階層内で許可される親子関係も定義します。 3 つのテーブルがそれぞれの役割を連携して、OT アセットの全体像を提供します。 cmdb_ci_ot は物理デバイス情報 (構成項目) を処理します。 cmdb_ot_entity はこれらのデバイスのインスタンスと関係性を管理します。 cmdb_ot_entity_type は階層構造のルールとカテゴリを定義します。 Amazon AppFlow、Amazon S3、AWS Glue、AWS IoT SiteWise を使用するための権限を持つ AWS アカウント。 アセットテーブルの読み取り権限を持つ system-only user の ServiceNow 認証情報。 実装 ServiceNow コネクタの構成 このセクションでは、Amazon AppFlow を設定して ServiceNow からデータを取り込み、AWS Glue でデータをカタログ化します。 Amazon AppFlow で ServiceNow コネクタを作成する Amazon AppFlow コンソールに移動します。 左側のメニューから、 Connections の下の ServiceNow をコネクタのドロップダウンから選択します。 Create connection を選択します。 Connect to ServiceNow のポップアップで、図 2 を参照し、次の情報を入力します。 必要に応じて Basic Auth または OAuth2 を選択します。 ユーザーガイド に従って必要な情報を入力します。 OAuth2 を選択した場合は、ServiceNow インスタンスの Client ID、Client secret、Instance URL を入力します。 Basic Auth を選択した場合は、ServiceNow インスタンスの Username、Password、Instance URL を入力します。 すべての情報を入力したら、 connect をクリックします。 図 2: ServiceNow に接続する 各テーブルごとにフローを作成します Amazon AppFlow コンソールに移動します。 左側のメニューで、 Flows の下にある Create flow を選択します。 Flow Name (例: cmdb_ci_ot ) を入力し、図 3 を参照の上、 Next を選択します。 図 3: フローを作成する 「ソース詳細」ダイアログボックスで (図 4 参照)、次の内容を入力します: 「ソース名」では、 ServiceNow を選択します。 「前に作成した接続が ServiceNow コネクタ の下で選択されていることを確認してください。参照名は、お使いの ServiceNow インスタンス名になります。この例では “dev287617” を使用しています。 ServiceNow オブジェクト では、 Operational Technology (OT) を選択します。 宛先詳細 ダイアログボックス (図 4 参照) に移動し、次の内容を入力します: 宛先名 では、 Amazon S3 を選択します。 バケット詳細 の下で、宛先のバケットを選択するか、 新しく作成 ( Amazon S3 コンソール から)します。この例ではバケットプレフィックス cmdb_ci_ot を使用しています。 Next を選択します。 図 4: フローのソースと送信先 ソース から 宛先 へのフィールド マッピング ダイアログボックスで (図 5 参照)、以下の作業を行います。 ソース フィールド名 の下で、 すべてのフィールドを直接マップする を選択します。 Next を選択し、続けて Next を選択します。 最後に フローを実行 を選択して完了します。 図 5: 実行フロー すべてのテーブルに対してフローを作成する “Create flows for each table” の手順を繰り返し、他の ServiceNow オブジェクトとの接続を作成してください: フロー名と Amazon S3 プレフィックス:  cmdb_ot_entity 、ServiceNow オブジェクト: OT Asset。 フロー名と Amazon S3 プレフィックス:  cmdb_ot_entity_type 、ServiceNow オブジェクト: OT Asset Type。 AWS Glue Crawler をセットアップし、スキーマを特定するために実行 AWS Glue コンソールに移動します。 左のメニューから Data Catalog の下にある Crawlers を選択します。 Crawlers ダイアログボックス (図 6 参照) で、 Create crawler を選択します。 図 6: AWS Glue Crawlers Crawler 名 には ServiceNow Crawler を使い、 Next  を選択してください。 図 7: Crawler の properties Add an S3 data source を選択します。 Add an S3 data source  ダイアログボックスで (図 8 を参照)、以下の手順に従います。 データソース として S3 を選びます。 S3 path として <your_bucket_name> を入力します。 Add an S3 data source  を選択します。 図 8: Crawler data source Next を選択します。 IAM ロールの項目で、 Create new IAM role を選択してください (図 9 を参照)。 図 9: Crawler IAM Role ロールの名前を決めます。この例では AWSGlueServiceRole-ServiceNowCrawler を使用します。 Next  を選択します。 ターゲットデータベースの下で、AWS Glue データベースを選択します。この例ではデフォルトのデータベースを使用しています。 図 10: AWS Glue データベースの選択 Next  を選択します。 Create を選択します。 クロールを実行します。完了するのに約 2 分かかります。 ServiceNow の Parquet データは、Amazon S3 にインポートされました。 JSON ファイルの変換 このセクションでは、AWS Glue ジョブを設定して parquet ファイルを AWS IoT SiteWise に適した JSON 形式に変換し、データを AWS IoT SiteWise にインポートします AWS Glue ジョブを作成 AWS Glue コンソールに移動します。 左側のメニューから、 ETL Jobs  の下にある  Visual ETL を選択します。 Create Job で、  Visual ETL  を選択します。 図 11: AWS Glue Studio Source ノードを作成します。青い プラス (+) ボタンを選択し (図 12 参照)、 Amazon S3  を選択してください。 図 12: Visual ETL Name  では、図 13 のようにノードの名前を任意につけてください。ここでは cmdb_ot_entity とします。 S3 source type  では、  Data Catalog table  を選択してください。 Database  では、前に AWS Glue Crawler のセットアップ時に選択したターゲットデータベースを選んでください。 Table  では、最初の表 cmbd_ot_entity を選択してください。この手順を cmdb_ci_ot と cmdb_ot_entity_type の各テーブルについて繰り返してください 。  図 13: ソースノードの追加 アセットを AWS IoT SiteWise のインポート形式にマップする 図 12 に示されている青い「+」ボタンを選択して、新しい Source ノードを作成してください。 Transform ノードを追加し、 SQL Query を選択してください。 Name には「 assets」 を使用してください。 Node parents には、ソースノード cmdb_ot_entity と cmdb_ci_ot を選択してください。。 Input sources と SQL Aliases には、図 14 に示すように、それぞれ cmdb_ot_entity と cmdb_ci_ot を選択してください。 図 14: アセットの変換 SQL Query に次のクエリをコピー & ペーストしてください。 SELECT DISTINCT parent.sys_id as assetExternalId, parent.name as assetName, parent.ot_asset_type as assetModelExternalId, COLLECT_LIST( CASE WHEN child.sys_id IS NOT NULL THEN STRUCT( array_join(array(parent.ot_asset_type, child.ot_asset_type), '-') as externalId, child.sys_id as childAssetExternalId ) END ) as assetHierarchies, ( CASE WHEN ot.sys_id IS NOT NULL THEN array( STRUCT('name' as externalId, ot.name as attributeValue), STRUCT('serial_number' as externalId, ot.serial_number as attributeValue), STRUCT('manufacturer' as externalId, ot.manufacturer as attributeValue), STRUCT('model_number' as externalId, ot.model_number as attributeValue), STRUCT('firmware_version' as externalId, ot.firmware_version as attributeValue), STRUCT('hardware_version' as externalId, ot.hardware_version as attributeValue), STRUCT('asset_tag' as externalId, ot.asset_tag as attributeValue), STRUCT('category' as externalId, ot.category as attributeValue), STRUCT('environment' as externalId, ot.environment as attributeValue), STRUCT('short_description' as externalId, ot.short_description as attributeValue) ) ELSE array() END ) as assetProperties FROM cmdb_ot_entity as parent LEFT JOIN cmdb_ci_ot as ot ON parent.ot_asset = ot.sys_id LEFT JOIN cmdb_ot_entity as child ON parent.sys_id = child.parent GROUP BY parent.sys_id, parent.name, parent.ot_asset_type, ot.sys_id, ot.name, ot.serial_number, ot.manufacturer, ot.model_number, ot.firmware_version, ot.hardware_version, ot.asset_tag, ot.category, ot.environment, ot.short_description asset model をマッピングする 図 12 に示されている青い「+」ボタンを選択して、新しい Source ノードを作成します。 新しい Transform ノードを追加し、 SQL Query を選択します。 Name には「 assetModels 」を使用します。 Node Parents では、ソースノード cmdb_ot_entity_type を選択します。 Input sources と SQL Aliases では、図 15 に示されているように、それぞれ cmdb_ot_entity_type を使用します。 図 15: assetModel 変換 SQL Query に次のクエリをコピー & ペーストしてください。 SELECT DISTINCT parent.sys_id as assetModelExternalId, parent.label as assetModelName, ( CASE WHEN parent.ot_table IS NOT NULL THEN from_json( '[{"dataType":"STRING","externalId":"name","name":"Name","type":{"attribute":{"defaultValue":"-"}},"unit":"-"},{"dataType":"STRING","externalId":"serial_number","name":"Serial Number","type":{"attribute":{"defaultValue":"-"}},"unit":"-"},{"dataType":"STRING","externalId":"manufacturer","name":"Manufacturer","type":{"attribute":{"defaultValue":"-"}},"unit":"-"},{"dataType":"STRING","externalId":"model_number","name":"Model Number","type":{"attribute":{"defaultValue":"-"}},"unit":"-"},{"dataType":"STRING","externalId":"firmware_version","name":"Firmware Version","type":{"attribute":{"defaultValue":"-"}},"unit":"-"},{"dataType":"STRING","externalId":"hardware_version","name":"Hardware Version","type":{"attribute":{"defaultValue":"-"}},"unit":"-"},{"dataType":"STRING","externalId":"asset_tag","name":"Asset Tag","type":{"attribute":{"defaultValue":"-"}},"unit":"-"},{"dataType":"STRING","externalId":"category","name":"Category","type":{"attribute":{"defaultValue":"-"}},"unit":"-"},{"dataType":"STRING","externalId":"environment","name":"Environment","type":{"attribute":{"defaultValue":"-"}},"unit":"-"},{"dataType":"STRING","externalId":"short_description","name":"Short Description","type":{"attribute":{"defaultValue":"-"}},"unit":"-"}]', 'array<struct<dataType:string,externalId:string,name:string,type:struct<attribute:struct<defaultValue:string>>,unit:string>>' ) ELSE array() END ) as assetModelProperties, COLLECT_LIST( CASE WHEN child.sys_id IS NOT NULL THEN STRUCT( array_join(array(parent.sys_id, child.sys_id), '-') as externalId, child.name as name, child.sys_id as childAssetModelExternalId ) END ) as assetModelHierarchies FROM cmdb_ot_entity_type as parent LEFT JOIN cmdb_ot_entity_type as child ON parent.sys_id = child.parent_type GROUP BY parent.sys_id, parent.name, parent.label, parent.ot_table assetsと asset model を組み合わせる 図 12 に示されているように、青色の 「+」 ボタンを選択して新しい Source ノードを作成します。 新しい Transform ノードを追加し、 SQL Query を選択します。 Name には 「assetModelHierarchy」  を使用します。 Node parents には、Source ノード assets と assetModels を選択します。 Input sources と SQL aliases には、図 16 のように assets と assetModels を使用します。 図 16: assetModelHierarchy 変換 SQL Query に次のクエリをコピー & ペーストしてください。 SELECT ( SELECT COLLECT_LIST(STRUCT(assetModels.*)) as assetModels FROM assetModels ) as assetModels, ( SELECT COLLECT_LIST(STRUCT(assets.*)) as assets FROM assets ) as assets AWS Glue ジョブ の結果を AWS IoT SiteWise にインポートするために使用するよう、変換のターゲットを追加しましょう。 変換のターゲットを追加する 図 12 に示されている青い 「+」 ボタンを選択して、新しいソースノードを作成します。 新しいノード Transform を追加し、ターゲットから Amazon S3 を選択します。 Name は何でも構いません。この例では Amazon S3 を使用しています。 Node Parents  は、ソースノード assetModelHierarchy を選択します。 Format  は JSON を選択します。 Compression Type は None を選択します。 S3 Target Location  は <your_destination_bucket>  を選択します。 図 17: ターゲットノードの追加 完了すると、図 18 に示すような ETL を確認できるはずです。 Save を選択してください。 それから Run を選択し、完了するまで待ちます。 図 18: アセットの階層 AWS IoT SiteWise への取り込み このセクションでは、Amazon S3 内の JSON ファイルの作成を確認し、AWS IoT SiteWise に ServiceNow のアセットをインポートします。 まず、次の操作を行って JSON ファイルが作成されたことを確認します。  Amazon S3 コンソールを開きます。 <your_destination_bucket> を選択します。 run-<timestamp>-part-r-00000  ファイルを選択後、 アクション をクリック。 オブジェクトの名前変更を選択し、 sitewise-import.json に変更する。AWS IoT SiteWise にインポートするためには、ファイル名に .json の拡張子を付ける必要があります。 AWS IoT SiteWise にインポートするには、AWS IoT SiteWise コンソールを開きます。 ナビゲーションペインで Bulk Operations を選択します。 New Import を選択します。 図 19: AWS IoT SiteWise bulk operations Import metadata からS3 URI に <your_destination_bucket> を選択し sitewise-import.json ファイルを指定します。 図 20: S3 import Import  を選択し、インポートが完了するまで待ちます。 作業の検証 図 21 に示されているように、さまざまなモデルとモデルプロパティを表示できるようになりました。また、図 22、23、24 に示されているように、さまざまなアセットとアセットプロパティも表示できます。あなたの ServiceNow 階層が AWS IoT SiteWise に正常に複製されました。 図 21: AWS IoT SiteWise モデル 図 22: AWS IoT SiteWise のモデルプロパティ 図 23: AWS IoT SiteWise アセット 図 24: AWS IoT SiteWise のアセットプロパティ クリーンアップ このブログで説明した作業をクリーンアップするには、Amazon AppFlow コンソールに移動し、フローと ServiceNow コネクタを削除します。ServiceNow で作成したユーザーとユーザー認証情報を削除します。AWS Glue では、Crawler 、ジョブ、AWS Glue データカタログからテーブルを削除します。AWS IoT SiteWise からアセットとアセットモデルを削除します。最後に、Amazon S3 バケットからParquetと JSON 形式のファイルの両方を削除します。 まとめ このブログでは、ServiceNow のアセットデータと AWS IoT SiteWise を統合するプロセスを紹介しました。 このプラクティスにより、組織は IT と OT のアセット管理ソリューション間で一貫したアセット情報を保持できます。 この統合を完全に自動化するには、Amazon AppFlow のフローに定期的に実行するようにスケジューリングし、AWS Glue ジョブにスケジュールのトリガーを設定します。 AWS Glue ジョブを設定する際、ETL スクリプト経由で出力ファイルに ‘.json’ 拡張子を付与することもできます。 これらの 2 つのソリューションにより、手動でのデータ入力を排除し、IT システムと OT システム間の整合性が保たれます。 AWS IoT SiteWise の詳細を知りたい場合は、 AWS IoT SiteWise Developer Guide  をご覧ください。 この記事は Mariaと Brent によって書かれた  Integrating ServiceNow OT Asset Workspaces with AWS IoT SiteWise Asset Models  の日本語訳です。この記事はソリューションアーキテクトの服部が翻訳しました。 About the authors Maria El Khoury : AWS のソリューションアーキテクト。製造業のデジタルトランスフォーメーションを支援し、IoT やコンピュータビジョンの経験を活かし、産業用 IoT やサプライチェーン分野への AWS 適用に注力。 Brent Van Wynsberge : AWS のソリューションアーキテクト。エンタープライズ顧客のクラウド導入を支援し、 IoT や DevOps 、データ分析、コンテナ技術にも関心を持つ。 Kazunari Hattori 自動車業界担当のソリューションアーキテクト。CCoE 立ち上げや工場 IoT の導入、クラウド活用の推進に注力。AWS の IoT の技術コミュニティに所属。 第二種電気工事士。今春キャンピングカーをレンタルして秩父にキャンプに行きました。

このブログは 2024 年 9 月 11 日 に Roberto Moreno、 Jeremy Schiefer によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 この投稿では、 AWS Private CA Connector for Active Directory が、 Amazon AppStream 2.0 および Amazon WorkSpaces の証明書ベースの認証（CBA）の構成をどのように簡素化し、加速するかについて説明します。このコンテキストにおける AWS Private Certificate Authority と Active Directory Certificate Service の概要を提供します。Active Directory Certificate Service の代替としてAWS Private CA を使用する利点について説明し、構成手順を含めています。 SAML 2.0 アイデンティティプロバイダー (IdP) を AppStream 2.0 または Amazon WorkSpaces で使用している場合、CBA を使用してログインユーザーエクスペリエンスを向上させることができます。CBA は Active Directory ドメインパスワードのユーザープロンプトを排除します。これにより、SAML 2.0 IdP から AppStream 2.0 インスタンスまたは Amazon WorkSpaces へのシングルサインオンが可能になります。CBA の詳細については、「 WorkSpaces 用の CBA の構成方法 」および「 AppStream 2.0 用の CBA の構成方法 」をご覧ください。 概要 AWS Private CA と Active Directory 証明書サービスの役割 AppStream 2.0 および WorkSpaces でのCBAは、ユーザー証明書と仮想スマートカードの組み合わせに依存しています。これにより、Active Directory ドメインのメンバーである Windows マシンへのパスワードレス認証が可能になります。これを実現するために必要な重要なインフラストラクチャコンポーネントは2つあります。 AWS Private CA は、ユーザー証明書の発行と管理に使用されます。AppStream 2.0 と WorkSpaces サービスは、セッション認証プロセス中に AWS Private CA からユーザー証明書を自動的に要求します。その後、証明書がプロビジョニングされた仮想スマートカードを使用して、ユーザーは Active Directory に対して認証されます。AWS Private CA は、必要な CA 階層に応じて、証明書チェーンのルート CA または下位 CA として使用できます。 Active Directory Certificate Service (AD CS) は、Active Directory ドメインで仮想スマートカードログインを可能にするものです。具体的には、Active Directory Certificate Service は公開鍵基盤 (PKI) を提供し、Active Directory integrated Certificate Authority (またはエンタープライズCA) も含まれています。証明機関は、ドメインコントローラー証明書の発行と管理に使用されます。これらの証明書により、Key Distribution Center (KDC) は、CBA や仮想スマートカードログインに必要なドメインの他のメンバーに対して自身の ID を証明することができます。 DC / Kerberos 証明書は、AD CS での証明書自動登録を通じて、すべてのドメインコントローラーに自動的に発行およびインストールされます。 AWS Private CA は、AD CS ルート CA に対する下位 CA として構成されています。AWS Private CA 証明書は、その後手動で AD RootCA および NTAuthCA ストアに公開されます。 CA 証明書チェーンは、AD を介してすべてのドメインマシンに自動的に複製されます。 ユーザーは SAML 2.0 プロバイダーで認証されます。 フェデレーションユーザーは AppStream 2.0 / WorkSpaces リソースへのアクセスが許可されます。 SAML アサーションの属性に基づいて、WorkSpaces / AppStream2.0 には AWS プライベート CA によって署名されたユーザー証明書が発行されます。 AppStream 2.0 / WorkSpaces サービスは、ユーザー証明書を Windows マシンに公開されます。 AppStream 2.0 / WorkSpaces エージェントは、ユーザー証明書を使用して Active Directory にユーザーをシームレスに認証されます。 Active Directory 証明書サービスの代替としての AWS Private CA Connector for AD AD 用コネクタにより、AWS Private CA は Active Directory 統合エンタープライズ CA の役割を担うことができます。これは Active Directory Certificate Services をデプロイして、Active Directory 内のマシンに必要な証明書テンプレートと登録サービスを提供します。このアプローチにより、Active Directory Certificate Services のインフラストラクチャをデプロイする必要がなくなり、実装の労力が大幅に簡素化されます。また、運用オーバーヘッドを削減し、CA の秘密鍵が FIPS 140-2 レベル 3 認定のハードウェアセキュリティモジュール (HSM) に保存されることでセキュリティが向上します。 AWS Private CA を設定、コネクタを介して AD と統合されています。エンタープライズ CA として、その CA 証明書は自動的に AD RootCA および NTAuthCA ストアに公開されます。DC / Kerberos 証明書は、AWS Private CA による証明書自動登録を通じて、ドメインコントローラーに自動的に発行およびインストールされます。 CA 証明書チェーンは、AD を介してすべてのドメインマシンに自動的に複製されます。 ユーザーは SAML プロバイダーで認証されます。 フェデレーションユーザーは AppStream 2.0 / WorkSpaces リソースへのアクセスが許可されます。 SAML アサーションの属性に基づいて、AppStream 2.0 / WorkSpaces には AWS Private CA によって署名されたユーザー証明書が発行されます。 AppStream 2.0 / WorkSpaces サービスは、ユーザー証明書を Windows マシンに公開します。 AppStream 2.0 / WorkSpaces エージェントは、ユーザー証明書を使用して Active Directory にユーザーをシームレスに認証します。 Walkthrough このウォークスルーでは、 AWS Private CA 、 Active Directory 用の AWS Private CA コネクタ、および AppStream 2.0 または WorkSpaces の証明書ベースの認証を設定します。 前提条件 使用する AWS サービスのコマンドを実行するために必要な IAM 権限を持つ AWS コンソール。 SAML 2.0 ID プロバイダーと統合された機能的な AppStream 2.0 または WorkSpaces のデプロイメント SAML アサーションで https://aws.amazon.com/SAML/Attributes/PrincipalTag:UserPrincipalName 属性を設定します。この属性は CBA に必要であり、Active Directory の ユーザープリンシパル名 （UPN）にマッピングする必要があります。詳細については、「 SAML 認証レスポンスのアサーションを作成する 」を参照してください。 SAML 2.0 設定で使用する IAM ロール信頼ポリシーに、まだ存在しない場合は、 sts:TagSession 権限を追加してください。この権限は証明書ベースの認証を使用するために必要です。詳細については、「 SAML 2.0 フェデレーション IAM ロールを作成する 」を参照してください。 セルフマネージド Active Directory AWS Managed Microsoft AD はサポートされていません。 AWS Directory Service AD Connector WorkSpaces ディレクトリで構成された既存のコネクタを使用するか、この目的のために新しいコネクタを作成することができます。 注： Active Directory サービスアカウントには、以下の「ステップ3： AD 用 PCA コネクタの作成」に記載されている 追加の権限 が必要になります。 ニーズに基づいて認証局 (CA) 階層を計画・設計する 注: このブログに含まれる構成手順は、簡略化のために1レベルの CA 階層を想定しています。単一の AWS Private CA インスタンスが 有効期限の短い証明書 でデプロイされ、ルート CA として機能し、証明書を発行します。 本番環境にデプロイする際、個別の管理制御と完全な信頼チェーンが必要な場合は、 AWS Private CA のドキュメント を参照してください。 有効期限の短い証明書 は、特に AppStream 2.0 および WorkSpaces CBA での使用が推奨されています。 設定手順 ステップ1：証明書失効リスト（CRL）をホストするための公開リポジトリを作成する   Amazon Simple Storage Service (Amazon S3) バケットを作成して ACL を無効に設定し、すべてのパブリックアクセスをブロックします。 CloudFront ディストリビューションを作成します： Amazon CloudFront コンソールに移動します。 ディストリビューションを作成します。 オリジンドメインには、最初のステップで指定したオリジンドメインとして作成された S3 バケットを選択してください。 オリジンアクセスには、オリジンアクセスコントロール設定（推奨）を選択してください。 コントロール設定の作成を選択してください。 ディストリビューションを作成します。 S3 バケットポリシーを作成します： Amazon S3 コンソール に移動します。 このステップの最初に作成した S3 バケットを選択してください。 アクセス許可タブを選択します。 バケットポリシーを選択し、編集を選択します。 次のように入力してください。 S3-BUCKET-NAME 、 AWS-ACCOUNT-NUMBER 、および CLOUDFRONT-DISTRIBUTION をあなたの値に置き換えてください。その後、保存を選択します。 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "acm-pca.amazonaws.com" }, "Action": [ "s3:PutObject", "s3:PutObjectAcl", "s3:GetBucketAcl", "s3:GetBucketLocation" ], "Resource": [ "arn:aws:s3:::S3-BUCKET-NAME/*", "arn:aws:s3:::S3-BUCKET-NAME" ], "Condition": { "StringEquals": { "aws:SourceAccount": "AWS-ACCOUNT-NUMBER" } } }, { "Sid": "AllowCloudFrontServicePrincipal", "Effect": "Allow", "Principal": { "Service": "cloudfront.amazonaws.com" }, "Action": "s3:GetObject", "Resource": "arn:aws:s3:::S3-BUCKET-NAME/*", "Condition": { "StringEquals": { "AWS:SourceArn": "arn:aws:cloudfront::AWS-ACCOUNT-NUMBER:distribution/CLOUDFRONT-DISTRIBUTION" } } } ] } ステップ2：AWS Private CA を作成する ca_config.txt ファイルを作成し、以下の情報でフォーマットして、太字の情報をあなたの組織の情報に置き換えてください： { "KeyAlgorithm":"RSA_2048", "SigningAlgorithm":"SHA256WITHRSA", "Subject":{ "Country":"YOUR-COUNTRY", "Organization":"YOUR-ORG", "OrganizationalUnit":"YOUR-OU", "State":"YOUR-STATE", "Locality":"YOUR-LOCALITY", "CommonName":"CA-NAME" } } revoke_config.txt ファイルを作成し、以下の情報でフォーマットしてください。太字のプレースホルダーを置き換えてください 注意： CustomCnameにHTTPS を含めないようにしてください。 { "CrlConfiguration":{ "Enabled":true, "ExpirationInDays":7, "S3BucketName":"YOUR-S3-BUCKET-NAME", "S3ObjectAcl":"BUCKET_OWNER_FULL_CONTROL", "CustomCname":"CLOUDFRONT-DISTRIBUTION-FQDN" } } 短期間のルート AWS プライベート CA を作成するには、次の AWS CLI コマンドを入力してください。ターミナル環境として AWS CloudShell を使用することができます。 注意：これらの値は必須であり、変更してはいけません。コマンドを実行する前に、 ca_config.txt と revoke_config.txt ファイルを AWS CloudShell にアップロードしてください。 aws acm-pca create-certificate-authority \ --certificate-authority-configuration file://ca_config.txt \ --revocation-configuration file://revoke_config.txt \ --certificate-authority-type "ROOT" \ --idempotency-token 01234567 \ --tags Key=euc-private-ca,Value= \ --usage-mode SHORT_LIVED_CERTIFICATE ステップ3：AD の PCA コネクタを作成する AWS マネジメントコンソールを使用してコネクタを作成および設定するには、次の手順に従ってください。 AWS CLI create-connector コマンドまたは CreateConnector API アクションを使用することもできます。 AWS Private CA Connector for Active Directory コンソールに移動します。 初回サービスのランディングページまたは Active Directory 用コネクタのページで、[コネクタの作成]を選択します。 「Select your Active Directory type」の下で、「On-premises Active Directory with AWS AD Connector」を選択します。 「ディレクトリを選択」の下で、リストからあなたのディレクトリを選択してください。 VPC エンドポイントのセキュリティグループを選択で、リストからセキュリティグループを選択するか、新しいセキュリティグループを作成します。 前提条件では、PowerShell スクリプトをダウンロードして実行し、サービスアカウントに権限を委任してください。必要な権限の詳細については、 前提条件 を参照してください。 プライベート認証局セクションで、リストからプライベート CA を選択してください。 必要な情報を提供して選択内容を確認した後、[コネクタの作成] を選択します。これにより、Active Directory 用コネクタの詳細ページが開き、コネクタの作成進行状況を確認できます。 証明書登録ポリシーサーバーのエンドポイント URL を記録してください。これは以下のステップ4で使用します。 ステップ4：Active Directory ポリシーを構成する グループポリシーは、ドメインコントローラーの証明書自動登録設定を構成するために使用され、AWS Private CA Connector エンドポイントに到達するための URL も含まれます。AWS Private CA のドキュメントに記載されている グループポリシーの設定手順 に従ってください。 ステップ5：証明書テンプレートを作成する PCA コネクタには、AD アプリケーションに使用される一般的な証明書テンプレートが含まれています。Kerberos 認証証明書テンプレートは、仮想スマートカードと CBA ログオンを許可するドメインコントローラー向けの最新の証明書テンプレートです。 AWS Private CA Connector for Active Directory コンソールに移動します。 Active Directory のコネクタリストから作成したコネクタを選択し、[詳細を表示] を選択します。 コネクタの詳細ページで、テンプレートセクションを見つけ、「テンプレートの作成」を選択します。 テンプレート作成ページで、テンプレート作成方法セクションにて、定義済みテンプレートから開始（デフォルト）を選択し、リストから Kerberos 認証を選んでください。 テンプレート設定セクションで、以下の情報を提供してください： テンプレート名：Kerberos 認証 テンプレートスキーマバージョン：テンプレートバージョン2 クライアント互換性: Windows 8以降 / Windows Server 2016 以降 証明書設定セクションでは、デフォルト設定を使用します。 注意：AWS Private CA を 有効期間の短い証明書 で使用する場合、有効期間と更新期間を一致させるように設定する必要があります。 有効期間：7日間 更新期間：1日 グループとアクセス許可のセクションで、「新しいグループとアクセス許可を追加」をクリックして、必要なグループと登録設定を必要に応じて構成します。以下の例では、特定のドメイン内のすべてのドメインコントローラーが AWS Private CA から証明書をリクエストすることを許可しています。注：セキュリティ識別子（SID）の値はドメインに固有です。ドメインコントローラーで PowerShell コマンド Get-ADGroup -Identity “Domain Controllers” を実行して SID を取得できます。 表示名: ドメインコントローラー セキュリティ識別子: S-1-5-##-##########-##########-##########-516 登録：許可 自動登録：許可 他のすべてのセクションにはデフォルト設定を使用してください。 テンプレートを作成を選択してください。 ステップ6：AWS Private CA と Active Directory の統合を検証する 新しいコネクタが作成されると、Active Directory に AWS Private CA 用の新しい certificationAuthority オブジェクトが作成されます。 Active Directory サイトとサービスの管理コンソールを開きます。 表示メニューで、サービスノードの表示を選択します。 サービスを展開し、公開鍵サービスを展開してから、証明機関を選択します AWS PCA のオブジェクトが acm-pca-ID として表示されることを確認してください。 PCA ルート証明書はドメインの信頼されたルート証明機関に追加されます。 ドメイン参加済みのマシンで、ローカルコンピュータ用の証明書管理コンソール（certlm.msc）を開きます。 信頼されたルート証明機関を展開して証明書を選択してください 共通名に基づいて AWS PCA 証明書を見つけて開きます。 認証パスタブを選択し、証明書のステータスが「この証明書は問題ありません」であることを確認します。 ドメインコントローラー証明書は自動登録によってインストールされます。 ドメインコントローラーでローカルコンピューターの証明書管理コンソールを開きます。 個人を展開して証明書を選択してください ドメインコントローラーの FQDN に基づいて証明書を特定し、それが AWS PCA によって発行され、Kerberos 認証テンプレートを使用していることを確認します。 証明書を開き、証明書パスタブを選択し、証明書のステータスが「この証明書は正常です」であることを確認します。 注意：証明書の自動登録は、ドメインレプリケーション、グループポリシー、その他のプロセスなどの様々な要因に基づいて時間がかかります。場合によっては、8時間以上かかることがあります。 ステップ7：WorkSpaces または AppStream 2.0 の CBA を有効にする AWS Private CA が Active Directory ドメイン内のエンタープライズ CA になった今、 AppStream 2.0 または WorkSpaces で証明書ベースの認証を有効にするための管理ガイドに従ってください。 AWS CloudTrail は、AppStream 2.0 または WorkSpaces サービスが AWS Private CA からユーザー証明書をリクエストしていることを確認するために使用されます。 CloudTrail のイベント履歴 では、EcmAssumeRoleSession ユーザー名によって行われた acm-pca.amazonaws.com イベントソースからの GetCertificate および IssueCertificate イベント名を確認できます。これらのイベントは、WorkSpaces または AppStream 2.0 の証明書ベースの認証リクエストごとに記録されます。 クリーンアップ このブログに従って作成したリソースが不要になった場合は、以下の手順に従ってください。 AppStream 2.0 または WorkSpaces コンソールで、ディレクトリ設定の証明書ベースの認証を無効にします。 AWS Private CA Connector for Active Directory コンソール で、ステップ3で作成されたコネクタを削除します。 ステップ4で作成された Active Directory の GPO を削除します。 ドメインコントローラーに発行された PCA 上の証明書を取り消し ます。 ドメインコントローラーにインストールされた AWS Private CA によって発行された証明書を削除します。 Active Directory から certificationAuthority オブジェクトを削除 します。 AWS Private CA コンソール で、ステップ2で作成した プライベート認証局を削除 します。 CloudFront コンソール で、ステップ 1 で作成した CloudFront ディストリビューションを削除 します。 S3コンソールで、ステップ1で作成した S3 バケットを削除してください。 まとめ この投稿では、AWS Private CA Connector for Active Directory を使用して、AppStream 2.0 および WorkSpaces での CBA 設定を簡素化する方法について学びました。このユースケースでコネクタを使用する主な利点は、Active Directory 証明書サービスの展開と管理を回避できることです。 ブログで言及されているサービスについて詳しく知るには、 AD 用コネクタ 、 AWS Private CA 、 CA のベストプラクティス 、および AWS Directory Services のドキュメント を参照してください。AWS Management Console を使用して、AWS Private CA で CA の作成を始めることができます。

コンタクトセンター運営における包括的な監査証跡の取得と一元的な可視性の維持は、セキュリティ、コンプライアンス、および運用のベストプラクティスの観点で重要です。以前のブログ記事「 AWS CloudTrail と Amazon Athena による組織内の Amazon Connect API アクティビティの調査 」では、お客様が AWS CloudTrail と Amazon Athena を活用して、Amazon Connect のコンタクトセンター環境の中で行われる様々な API 呼び出しの可視性と監査可能性を実現する方法について説明しました。これは、組織がコンタクトセンター運営の監視および調査をできるようにするための重要な第一歩でした。 Amazon Connect は、さらに一歩進んだ AWS CloudTrail サポートとして、 Amazon Connect コンソールのフロー管理ページのアクティビティに対応 しました。これは、ユーザーがフローを追加、更新、または削除するたびに、そのアクティビティの記録が CloudTrail ログに取得されることを意味します。この新機能により、コンタクトセンターチームはさらなる可視性、レポーティング、およびコンプライアンスの利点を得ることができます。 この続編となるブログ記事では、お客様が AWS 環境全体で Amazon Connect のフロー管理のアクティビティを一元的に分析および監査する方法について、より詳しく説明します。AWS CloudTrail と Amazon Athena の機能を組み合わせることで、組織は以下のような重要な質問に答えることができます： この重要なフローを最後に更新したのは誰ですか？ このフローが最後に保存または削除されたのはいつですか？ 様々な AWS アカウントとリージョンで、どのようなフロー管理のアクティビティが発生していますか？ ソリューションの概要 新しく Amazon Connect のフロー管理が CloudTrail に対応したことにより、組織は複数のアカウントとリージョンを横断し、アクティビティを一元的に監査できます。詳細な記録を取得することで、顧客はフローに対して誰が、いつ、どこから変更を加えたかを追跡できます。CloudTrail ログの有効化は良い第一歩ですが、複数の AWS アカウントとリージョンにわたる環境を管理する場合、記録だけでは不十分です。組織は Amazon Athena を使用して CloudTrail ログをクエリし、 AWS Organization 全体にわたるフローマネジメントのアクティビティを分析できます。 前提条件 Amazon Conenct パブリック API の基本的な理解 AWS CloudTrail で 組織の証跡 を作成できること ユースケース 1. フローのライフサイクル管理の監査 シナリオ: コンタクトセンター運用チームは、時間の経過とともに行われる、フローの作成、変更、削除を追跡したいと考えています。 ソリューション: CloudTrail ログにより、CreateContactFlow や DeleteContactFlow などのフローのライフサイクルイベントを追跡、記録します。 Athena を使用して Amazon S3 に保存された CloudTrail ログを参照することで、フローのライフサイクルイベントの包括的なビューを得ることができます。手順は以下の通りです： Athena コンソールに移動し、クエリエディタを選択します。右側のペインで、クエリエディタを使用してクエリを入力し実行します。 特定の時間以降に作成されたすべてのフローとその作成者を確認するには、クエリエディタで以下のクエリを実行します： (訳注: クエリ最後の ‘2024-06-26 00:00:00’ を監査対象となる期間の開始時間に移動することをお勧めします) SELECT json_extract_scalar(responseelements, '$.ContactFlowId') as ContactFlowId, json_extract_scalar(requestparameters, '$.InstanceId') as InstanceId, userIdentity.arn, eventtime FROM "default"."cloudtrail_logs" WHERE userIdentity.arn IS NOT NULL AND eventName='CreateContactFlow' AND eventTime > '2024-06-26 00:00:00’ クエリ結果には、対応するフローを作成したユーザーの Amazon Resource Names (ARNs) と、その時刻が表示されます。 図 1: フローのライフサイクル管理監査のクエリ結果 結果の ARN フィールドから Amazon Connect の一意のユーザー ID(UUID) を取得できるようになりました。UUID は上の画像のように、ARN の最後のセグメントにあります。これらのユーザー ID を使用して、 DescribeUser API を呼び出すことでユーザーに関する情報を取得できます。 これを行うため、AWS Management Console に移動し、検索ボックスに CloudShell と入力して CloudShell を選択し、 AWS CloudShell を起動します。 図 2: CloudShell サービスへのアクセス CloudShell ターミナル内で DescribeUser API を呼び出すことで、Amazon Connect のユーザー詳細を確認できます。 aws connect describe-user --user-id <ユーザー ID に置き換え> --instance-id <インスタンス ID に置き換え> 図 3: describe-user のクエリ結果 2. 重要なフローへの不正な変更の検出 シナリオ: コンタクトセンターのマネージャーが、特定のフローを更新したユーザーを特定したいと考えています ソリューション: 不正な更新を行ったユーザー、時間、詳細を以下の方法で特定します Athena コンソールに移動し、クエリエディタを選択します。右側のペインで、クエリエディタを使用してクエリを入力し実行します。 特定のフローを更新したユーザーを特定するために、以下のクエリをクエリエディタで実行します。 (訳注: クエリ最後の ‘2024-06-26 00:00:00’ を監査対象となる期間の開始時間に移動することをお勧めします) SELECT json_extract_scalar(requestparameters, '$.InstanceId') as InstanceId, json_extract_scalar(requestparameters, '$.ContactFlowId') as ContactFlowId, userIdentity.arn, eventTimeFROM "default"."cloudtrail_logs" WHERE userIdentity.arn IS NOT NULL AND eventName='UpdateContactFlowContent' AND eventTime > '2024-06-26 00:00:00' クエリ結果には、インスタンス ID とともに、対応するフローを更新したユーザーの Amazon Resource Name (ARN) が表示されます。 図 4: 重要なフローへの不正な変更のクエリ結果 ARN のカラムには、ユーザー ID が長い文字列として表示されます。上記の結果に示されているように、ARN フィールドから Amazon Connect の一意のユーザー ID（UUID）を取得できます。UUID は ARN の最後のセグメントにあります。 これらのユーザー ID を使用して、 DescribeUser API を呼び出すことでユーザーに関する情報を取得できます。 Amazon Connect のユーザー詳細を確認するには、CloudShell ターミナルに移動し、以下のコマンドを実行します。 aws connect describe-user --user-id <ユーザー ID に置き換え> --instance-id <インスタンス ID に置き換え> 図 5: describe-user のクエリ結果 3. フローと電話番号の関連付けの調査 シナリオ: コンタクトセンターのマネージャーは、どの電話番号がどのフローに関連付けられているか、およびこれらの関連付けの変更を追跡したいと考えています ソリューション: CloudTrail ログで AssociatePhoneNumberContactFlow API コールを使用して、これらのフローと電話番号のマッピングを監視および監査します。手順は以下の通りです : Athena コンソールに移動し、クエリエディタを選択します。右側のペインで、クエリエディタを使用してクエリを入力し実行します。 どの電話番号がどのフローに関連付けられているかを確認するには、クエリエディタで以下のクエリを実行します。 (訳注: クエリ最後の ‘2024-06-26 00:00:00’ を監査対象となる期間の開始時間に移動することをお勧めします) SELECT json_extract_scalar(requestparameters, '$.InstanceId') as InstanceId, json_extract_scalar(requestparameters, '$.PhoneNumberId') as PhoneNumberId, userIdentity.arn, eventTimeFROM "default"."cloudtrail_logs" WHERE userIdentity.arn IS NOT NULL AND eventName='AssociatePhoneNumberContactFlow'AND eventTime > '2024-06-26 00:00:00' 上記のクエリの結果は、インスタンス ID 内に関連付けられた電話番号 ID と、フローの変更を行ったユーザーの ARN を提供します。（前のセクションと同様） 図 6：フローと電話番号の関連付けを調査するためのクエリ結果 PhoneNumberId がどの電話番号に対応しているかを確認するには、CloudShell ターミナルに移動し、以下のコマンドを実行します。 aws connect describe-phone-number --phone-number-id <PhoneNumberIdで置き換え> 図 7：describe-phone-number のクエリ結果 まとめ このブログ記事では、新しくサポートされた AWS CloudTrail による Amazon Connect フロー管理ページの証跡が、組織のコンタクトセンター運用の一元的な分析と監査にどのように役立つかを探りました。CloudTrail と Amazon Athena の強力な組み合わせを活用することで、顧客は重要なフローに対する変更を誰が行い、いつ変更が行われ、どの AWS アカウントまたはリージョンから行われたかについて、いままでになかった可視性と監査可能性を得ることができます。 この記事全体を通じて、この一元化された監査ソリューションの価値を示すいくつかの重要なユースケースを取り上げました。 フローのライフサイクル管理の監査: CloudTrail ログを参照することで、組織はフローの作成、変更、削除を含むライフサイクルを完全に追跡できます。これにより、コンタクトセンター運用チームに価値ある洞察を提供します。 重要なフローへの不正な変更の検出: 顧客が CloudTrail と Athena を使用して、機密な顧客データを扱うフローへの不正な更新を誰が行ったかを調査する方法を示し、コンタクトセンターのセキュリティとコンプライアンスの確保を支援します。 フローと電話番号の関連付けの調査: 顧客は CloudTrail で記録された追加の API コールを活用して、フローと電話番号間のマッピングなどの重要な関連付けを監視および監査し、これらの関連付けが適切に管理されていることを確認できます。 AWS 環境全体で Amazon Connect フロー管理のアクティビティを一元的に分析する機能により、組織はコンタクトセンター運用の可視性、セキュリティ、およびコンプライアンスを大幅に改善できます。このブログ記事で説明したガイダンスによって、お客様はこの強力な監査ソリューションを迅速に実装し、より適切な意思決定を行い、顧客により良いサービスを提供するために必要な洞察を得ることができます。 筆者について Guy Bachar Guy Bachar は、ニューヨークを拠点とする AWS のシニアソリューションアーキテクトです。彼はキャピタルマーケットのお客様のクラウドへの移行を支援しています。ID管理、セキュリティ、ユニファイドコミュニケーションに情熱を注いでいます。 Pranjal Gururani Pranjal Gururani は、シアトルを拠点とする AWS のシニアソリューションアーキテクトです。Pranjal はさまざまなお客様とビジネス上の課題に対処するクラウドソリューションを構築しています。ハイキング、カヤック、スカイダイビングを楽しみ、余暇には家族と過ごす時間を楽しんでいます。 Agasthi Kothurkar Agasthi Kothurkar は、ボストンを拠点とする AWS のプリンシパルソリューションアーキテクトです。Agasthi は、クラウドを採用してビジネスを変革する企業のお客様と協力して働いています。彼の専門分野は、クラウドネイティブアプリケーションアーキテクチャ、クラウドマイグレーション、IT 戦略、そして変革です。複雑な実世界のビジネス課題を解決するためにクラウドテクノロジーを適用することに情熱を注いでいます。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。

このブログは、2025 年 3 月 25 日に Marcelo Baptista、Lucia Maria de A. Drummond、Luan Teylo、Alan L. Nunes、Vinod Rebello、Cristina Boeres によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 大手総合エネルギー企業の一つである Petrobras は、複雑な課題に取り組み、新たな機会を切り拓くために、ハイパフォーマンスコンピューティング（HPC）の変革におけるポテンシャルを信じて、長年取り組んできました。同社は、地震データ処理、貯留層シミュレーション、その他の石油・ガス関連ワークロード向けに設計された強力な HPC インフラストラクチャに多額の投資を行ってきました。 これまで、Petrobras は主にオンプレミスソリューションを使用して HPC アプリケーションを実行していました。従来の HPC の制限を克服するため、 フルミネンセ連邦大学 （UFF）の Cloud+HPC ラボと共同で、オンプレミスとクラウドリソースを組み合わせたハイブリッドシステムを開発する研究プロジェクトを立ち上げました。 AWS ParallelCluster と Amazon EC2 スポットインスタンス を活用することで、Petrobras は事実上無制限のコンピューティングパワーを獲得し、複雑なシミュレーションの効率性を向上させ、可用性と最も重要な 生産性 を高めることができました。 本日は、これを可能にするために彼らが作成したフレームワーク Sim@Cloud について説明します。Petrobras はこれを使用して、パフォーマンスを最大限に維持しながら、43 % から 90 % のコスト削減を達成しました。Sim@Cloud は待ち時間を最小限に抑え、適切なインスタンスを選択し、インスタンスの稼働を管理します。 AWS の活用による待ち時間の最小化 需要がピークを迎える時期には、Petrobras はジョブ実行の長い待ち時間に直面していました。これはプロビジョニングにおけるよくあるジレンマですが、簡単にまとめると次の通りです。 オーバープロビジョニング: リソースがピーク需要に合わせてスケーリングされると、需要の低い期間に不必要な費用とエネルギーの無駄が発生します。 アンダープロビジョニング: リソースが十分にプロビジョニングされておらず、ピーク時の需要を満たせない場合、ジョブ実行の遅延が発生し、会社の意思決定に影響を与え、高度な資格を持つ高給の専門家の時間と生産性を妨げ、非効率による潜在的な財務損失をもたらす可能性があります。 このオーバープロビジョニングとアンダープロビジョニングのトレードオフは難しく、どちらの場合もリソースの無駄につながります。図 1 は、Petrobras の実際のデータを使用してこのシナリオを示しています。データは典型的な 1 週間の経過を示しており、オンプレミスのリソースは需要を満たしているものの、アイドル状態のリソースがあることがわかります。特定の日には、使用率が会社の計算能力の 100 % に達します。この時点（緑色の線で表示）で、ジョブがキューに入り、エンジニアのフラストレーションの原因となります（フラストレーションを抱えたエンジニアを見たことがありますか？私はあります）。 したがって、私たちは自問しなければなりません：これを管理する最も効果的な方法は何でしょうか？ 図 1 – Petrobras のオンプレミスインフラにおける 1 週間のジョブ実行状況。100 %（緑色の線）を超える曲線はピーク需要を表し、その結果、ワークロードがクラウドに手動でシフトされます（オレンジ色で表示）。 このような状況において、AWS のネイティブな弾力性が解決策を提供します。日常的なタスクにはオンプレミスリソースを割り当て、ピーク時の要求をクラウドに移行します。これはまさに Petrobras が UFF の Cloud+HPC ラボとのパートナーシップと Sim@Cloud によって実現していることです。 コストの検討 Petrobras のワークロードは通常、完了までに数日から数週間かかり、数百のコンピューティングノードを使用します。クラウドへの移行において彼らの主な懸念はコストでした。これに対処するため、Lúcia Drummond 教授が率いる UFF の Cloud+HPC ラボは、AWS で HPC ワークロードを実行するコストを最適化し削減することに焦点を当てたプロジェクトを立ち上げました。 プロジェクトの最初の 2 年間で、Petrobras はピーク需要期間中に AWS に移行する最初のワークロードとして CMG の貯留層シミュレーションを選択しました。このアプリケーションは、同社のワークロードの大部分を占め、ネイティブで軽量なチェックポイントとリスタート機能を備えていることが特徴です。 チェックポイントとリスタート機能により、エンドユーザーに対する透明性を確保しながら、Amazon EC2 スポットインスタンスを使用してコストを可能な限り低く抑えることができます。ユーザーの視点からは、シミュレーションのバッチを Slurm に送信して結果を待つプロセスは、オンプレミスで実行する場合も AWS Cloud で実行する場合も同じです。 1 人のユーザーのワークロードは、300 を超えるシミュレーションジョブで構成されることがあります。各ジョブは、一度に 100 以上のインスタンスを要求することがあります。適切なインスタンス、適切なタイミング、適切な AWS リージョンを見つけることが、HPC ワークロードを実行し、コストを最適化する鍵となります。 これらの課題を解決するために、プロジェクトは Sim@Cloud を開発しました。これは Slurm や BR-Kalman などの他の Petrobras 内部ツールとネイティブに統合されています。 Sim@Cloud Sim@Cloud は、シミュレーション実行に適したインスタンスと料金モデル（スポットまたはオンデマンド）の選択をサポートすることで課題に対処します。また、スポットインスタンスの中断を管理できるよう実行を監視します。 Sim@Cloud には、 Launcher と Execution Manager という 2 つの主要コンポーネントがあり、それぞれがシミュレーション実行中の特定の管理手順を担当します。フレームワークの動作を説明するために、図 2 はアーキテクチャとステップバイステップの実行例を示しています。 図 2 – Cloud+HPC ラボと Petrobras によって開発された Sim@Cloud フレームワークのアーキテクチャ まず、ユーザーはクラスタージョブスケジューラ（Slurm）にシミュレーションリクエストを送信します。ユーザーは、コア数、実行用のバッチファイル、出力ディレクトリなど、実行のためのパラメータを定義します。 これらのパラメータを使用して、Slurm はヘッドノードで Launcher を起動します。Launcher は、Slurm の機能のみに基づいてシミュレーションの実行時間を推定する機械学習コンポーネントである ML-Predictor を呼び出します。次に、Launcher は Instance-Selector モジュールを呼び出します。推定時間、アプリケーションの特性、チェックポイントのオーバーヘッドなどの環境要因を考慮して、シミュレーションタスクに最適な Amazon EC2 インスタンスタイプ、購入オプション、およびリージョンが決定されます。この決定により、シミュレーションジョブが Slurm に送信され、選択されたインスタンスが割り当てられ、ジョブが開始されます。 Execution Manager モジュールは、 Dynamic-Predictor モジュールを通じてシミュレーションの進行状況を監視します。シミュレータのログに基づいて残りの実行時間を予測します。この情報を使用して、EC2 がスポットインスタンスを中断した場合にシミュレーションを再開するための新しいインスタンスを選択します。 スポットインスタンスで実行する場合、Execution Manager は Checkpoint-Recorder モジュールを使用して定期的にチェックポイントを作成します。必要に応じて、このモジュールは利用可能な最新のチェックポイントからアプリケーションを再起動します。Execution Manager は AWS のインスタンスメタデータからスポットインスタンスの中断通知を受け取ります。中断通知は、スポットインスタンスが中断される 2 分前に送信されます。通知を受け取った後、Checkpoint-Recorder はシミュレーションの現在の進行状況を保存するための最終チェックポイントを開始します。スポットインスタンスが中断された場合、Instance-Selector は Dynamic-Predictor によって予測された残り時間を使用して、シミュレーションを再開するのに最適なインスタンスを決定します。 このプロセスはシミュレーションが完了するまで繰り返されます。Launcher は実行情報を History-Database（実行履歴データベース） に保存し、ユーザーに通知します。データベースには、AWS リージョン、購入オプション、インスタンスタイプ、価格履歴、シミュレーションの実行時間など、シミュレーション実行に関連する情報が保存されます。これにより、実行パフォーマンスとコストのさらなる評価が容易になります。 Sim@Cloud は中断の回数も制限しています。制限に達すると、利用可能なオンデマンドキャパシティを使用してジョブを再開します。 Sim@Cloud は、オンプレミスのクラスターで共有ファイルシステムを使用し、異なる AWS リージョンごとにキャッシュを使用します。Amazon FSx for NetApp ONTAP は、シミュレーションを実行可能な各 AWS リージョンをリンクします。このキャッシュアーキテクチャにより、データは別のリージョンにコピーされ、可用性が向上し、シミュレーションの実行に関連するデータへの迅速なアクセスが可能になります。これは、組織がプライマリデータのホスティング環境としてデータ主権要件を遵守するのにも役立ちます（例えば、ブラジル政府のクラウドサービスのデータ処理とセキュリティに関する規則の遵守など）。 実験結果 スポットインスタンスの中断に対する 2 分前の通知をシミュレートし、Sim@Cloud を使用した場合のコストと総実行時間における効果を調査しました。 AEMM（ AWS EC2 Metadata Mock ）を使用して、スポットインスタンスの中断をシミュレートする別のツールを開発しました。ポアソン分布を使用してインスタンスの中断時間を計算し、インスタンスのメタデータを更新して終了アラートを含め、スポットインスタンスをシャットダウンします。この離散確率分布は、スポットインスタンスの中断タイミングを含む、特定の期間内でのイベント発生を予測するのに適しています。 1 時間あたりの平均中断回数を表すパラメータ λ を使用してポアソン分布からサンプリングし、結果に 3,600 秒を掛けることで終了時間を決定し、τ をインスタンスの利用可能時間として定義します。このツールはインスタンスの稼働時間を追跡し、秒単位で終了アラートを生成します。 評価では、(λ) – 0.1, 0.5, 0.8, 1.0 の 4 つの中断頻度を考慮しました。λ 値が増加するにつれて、スポットインスタンスが早期に終了する確率も高くなり、λ = 1 の場合は最初の 1 時間以内にスポットインスタンスが中断される確率が高いことを示します。 テストでは、 プレソルト（Pre-salt） と呼ばれる 半合成貯留層（semisynthetic reservoir） シミュレーションモデルのワークロードを使用しました。これは、Petrobras によって探査されたブラジル沖合の複雑なプレソルト貯留層の代表的なワークロードです。時間と予算を節約するため、50 年ではなく 20 年のシミュレーションを実行するバージョンを作成しました。この記事の残りの部分では、これらのモデルをそれぞれ Pre-Salt および Short-Pre-Salt と呼びます。これらのモデルは、通常、合成貯留層シミュレータ CMG GEM を使用して本番環境でシミュレートされます。これにより、ブラジルのプレソルトの複雑さに対してより良い結果が得られます。しかし、この調査では、テストの目的に合わせて高速化するため、常に 40 スレッドを使用して CMG IMEX ブラックオイルシミュレータを使用してシミュレーションを実行することを選択しました。 Sim@Cloud は、SA-EAST-1 リージョンのベースラインとなるオンデマンドインスタンスと比較して、様々なシナリオでコストを削減し、実行時間を短縮しました。図 3a、3b、3c は、中断頻度（λ）ごとに 3 回実行した Sim@Cloud のインスタンス選択スキームにおける平均メイクスパン（統合プロセス内でメッセージが処理されるまでの所要時間）とコストを表示しています。これを Short-Pre-Salt および Pre-Salt シミュレーションモデルについて示しています。メイクスパンは、統合プロセス内でメッセージが処理されるまでの時間を計算するパフォーマンス指標です。 図 3a – Short-Pre-Salt モデルの初回の実行時のコストとメイクスパン。破線はベースラインの実行を表します（ホーム AWS リージョン SA-EAST-1 で最も安価なオンデマンドインスタンスを使用）。 図 3b – Short-Pre-Salt モデルの 2 回目の実行のコストとメイクスパン。破線はベースラインの実行を表します（ホーム AWS リージョン SA-EAST-1 で最も安価なオンデマンドインスタンスを使用）。 図 3c – 完全な Pre-Salt モデルの実行におけるコストとメイクスパン。破線はベースラインの実行を表します（ホーム AWS リージョン SA-EAST-1 で最も安価なオンデマンドインスタンスを使用）。 最悪のシナリオ（λ = 1）においても、コスト削減は Short-Pre-Salt モデルの 2 回目の実行（図 3b）で最大 43.87 %、Short-Pre-Salt モデルの初回実行（図 3a）で最大 90.39 % に達しました。前者のケースでは、スポットインスタンスを使用する際にチェックポイントが必要なため、処理時間が 9.28 % 増加する代わりにこれを達成しました。対照的に、Short-Pre-Salt モデルの初回実行では、処理時間が平均 10.42 % 短縮されました。スポットインスタンスの中断から回復するプロセスには、代替インスタンスの選択、初期化、シミュレーションの再開など、回収と再起動のためのオーバーヘッドが含まれます。図 3b が示すように、中断頻度（λ）の上昇に伴い、メイクスパンも増加しました。λ = 0.5 および λ = 0.8 の場合、Short-Pre-Salt モデルの 2 回目の実行におけるコスト削減はそれぞれ 81.78 % と 81.46 % で、メイクスパンはそれぞれ 0.70 % と 2.48 % 増加しました。初回実行におけるコスト削減はさらに良好で、それぞれ 90.13 % と 90.07 % となり、メイクスパンは 13.52 % と 18.35 % 短縮されました。 λ = 0.1 のシナリオでも顕著な改善が見られました。コスト削減は初回実行で最大 91.58 %、2 回目の実行で 85.74 % に達し、メイクスパンはそれぞれ 15.97 % と 3.92 % 短縮されました。このシナリオでは、選択ヒューリスティックにより、ベースラインのインスタンスよりも低価格で性能の良いスポットインスタンスが得られました。Short-Pre-Salt の実行時間が短いため、スポットインスタンスの中断は発生せず、シミュレーションを移行するための追加のオーバーヘッドを回避できました。選択ヒューリスティックは、スポットインスタンスの購入においてコスト効率の良いリソースを検索する方法を示しています。 Pre-Salt モデルについては、図 3c に示す結果は Short-Pre-Salt モデルの結果と類似しています。このシナリオでは、コストとメイクスパンの両方で削減が達成されました。 実行時間は、ジョブ送信時のリージョンにおけるスポットインスタンスの可用性によっても影響されることに注意してください。スポットインスタンスの価格は実行中に変動する可能性がありますが、λ = 1.0 の両方のシナリオでコストが増加した主な原因は、許可されたスポットインスタンスの中断制限を超えた後に、Sim@Cloud がシミュレーションを完了させるためにオンデマンドインスタンスを選択したことでした。 ベネフィット この調査は有益であり、HPC ワークロードの管理方法に新たな可能性をもたらし、Amazon EC2 スポットインスタンスがコスト最適化の鍵となることを示しました。スポットインスタンスを使用することで、オンデマンド料金と比較して EC2 コストを大幅に削減できます。 FlexCache を搭載した Amazon FSx for NetApp ONTAP を使用して効率的なキャッシュを実現したことで、ストレージ費用を削減し、優れたパフォーマンス指標でクラウド内でのデータアクセスを容易にする重要な変化をもたらしました。Sim@Cloud のようなソリューションは、スポットインスタンスの中断という固有の性質があっても、ワークロードの整合性を損なうことなく大幅なコスト削減を実現できることを示しています。 クラウドベースのソリューションは、エンドユーザーに透明性を提供し、技術的な障壁を減らし、ユーザー（科学者やエンジニア）にピーク需要時に必要となる追加のキャパシティを提供することで、HPC アプリケーションのアクセシビリティを向上させます。 結論 このプロジェクトとその良好な成果は、UFF、Petrobras、AWS の三者による緊密な連携とサポートによって実現されました。結果から分かるように、Sim@Cloud はシミュレーションの実行時間に関係なく、全体的なコストの削減に効果的です。中断頻度（λ）が高くても、より長いシミュレーションモデルは低コストで短いメイクスパンを達成できます。 これらの結果は、AWS が HPC ワークロードの処理において成熟していることを示しています。Petrobras のような大企業は、この結果と AWS の規模とキャパシティの恩恵を受けることで、典型的なプロビジョニングの問題だけでなく、特殊なプロビジョニングの問題も解決できます。 AWS は Petrobras と UFF と緊密に連携しました。この緊密な関係は、環境を理解するだけに使われるはずの時間を節約し、研究やソリューションに取り組むことができるため有益でした。これはプロジェクトの成功と Sim@Cloud の開発に不可欠であり、潜在的なバグを回避し、プロジェクトを最良の決断へと導きました。 謝辞 この研究は多くのエンジニアとアナリストによって実施されました。彼らに深く感謝いたします： Alan L. Nunes (UFF), Cristina Boeres (UFF), Daniel B. Sodré (UFF), Felipe A. Portella (Petrobras), José Viterbo (UFF), Luan Teylo (INRIA/Bordeaux), Lúcia M. A. Drummond (UFF), Maicon Dal Moro (Petrobras), Marcelo Baptista (AWS), Paulo F. R. Pereira (Petrobras), Paulo J. B. Estrela (Petrobras), Renzo Q. Malini (Petrobras), Vinod E. F. Rebello (UFF). 出版物 このプロジェクトについて詳しく知りたい場合は、以下の論文リストをご参照ください。 Sim@Cloud – ​Experimental Evaluation MScheduler: Leveraging Spot Instances for High-Performance Reservoir Simulation in the Cloud , IEEE CloudCom 2023: 99-106 Prediction of Reservoir Simulation Jobs Times Using a Real-World Slurm Log , XXIV Simpósio em Sistemas Computacionais de Alto Desempenho 2023: 49-60 A. L. Nunes&nbsp; et al ., “ A Framework for Executing Long Simulation Jobs Cheaply in the Cloud ,”&nbsp; 2024 IEEE International Conference on Cloud Engineering (IC2E) , Paphos, Cyprus, 2024, pp. 233-244, doi: 10.1109/IC2E61754.2024.00033. High Performance Computing in Clouds: Moving HPC Applications to a Scalable and Cost-Effective Environments, Springer, 2023 https://www.amazon.com/High-Performance-Computing-Clouds-Cost-Effective-ebook/dp/B0BYN665C2/ <!-- '"` --> 翻訳はネットアップ合同会社の方様、監修はソリューションアーキテクトの宮城が担当しました。 Marcelo Ferreira Baptista Marcelo Baptista は、30 年以上の IT 経験を持つ AWS のソリューションアーキテクトです。DevOps、コンピューティング、HPCを専門とし、お客様の技術的なチャレンジを支援しています。 Alan L. Nunes Alan L. Nunes は、フルミネンセ連邦大学（UFF、ブラジル）とボルドー大学（UB、フランス）の博士課程の学生です。関心のあるトピックには、ハイパフォーマンスコンピューティング、クラウドコンピューティング、分散システム、フェデレーションラーニング、MapReduce などがあります。 Cristina Boeres Cristina Boeres は、フルミネンセ連邦大学計算科学研究所の准教授であり、エディンバラ大学（イギリス）でコンピューターサイエンスの博士号を取得しました。 Felipe Portella Felipe Portella は、ブラジルのエネルギー会社 Petróleo Brasileiro S.A.（PETROBRAS）の IT コンサルタントで、石油貯留層シミュレーションの HPC を専門としています。ブラジルの PUC-Rio で情報学の学位（2003 年）とコンピューターサイエンスの修士号（2008 年）を取得しました。2024 年には、スペインのバルセロナスーパーコンピューティングセンターと提携して UPC-Barcelona Tech でコンピューターアーキテクチャの博士号を取得しました。 Luan Teylo Luan Teylo は、フランスの INRIA Bordeaux の終身研究員です。2021 年からは TADaaM チームで働き、主に HPC プラットフォームに関連する I/O 問題に焦点を当てています。フルミネンセ連邦大学（UFF）でコンピューターサイエンスの修士号と博士号を取得しました。彼の研究テーマには分散アルゴリズム、クラウドコンピューティング、スケジューリング問題が含まれます。 Lucia Maria de A. Drummond Lucia Maria de A. Drummond は、1994 年にリオデジャネイロ連邦大学でシステム・コンピューター工学の博士号を取得しました。ブラジルで最初の並列コンピューターの開発チームに参加し、論文の主要記事は、ブラジル科学アカデミーによる科学技術省とコンパックコンピュータからの研究奨励賞を獲得しました。現在は、ブラジルのフルミネンセ連邦大学の教授であり、ハイパフォーマンスコンピューティングとクラウドコンピューティングの研究に関心を持っています。 Paulo Estrela Paulo Estrela は、2008 年からブラジルの国営石油会社 Petrobras の HPC システムエンジニアとして、石油貯留層シミュレーション用のスーパーコンピューターの構築と管理を行っています。最近では、クラウドコンピューティングリソースを使用して Petrobras のスーパーコンピューターに弾力性を与え、オンプレミスのキャパシティを補完することに取り組んでいます。これらのスーパーコンピューターの一部は、top500.org 機関によって世界で最も強力な 100 台のコンピューターにリストされています。 Vinod Rebello Vinod Rebello は、1996 年にエディンバラ大学（イギリス）でコンピューターサイエンスの博士号を取得しました。現在は、ブラジルのフルミネンセ連邦大学コンピューターサイエンス学科の准教授です。彼の研究は、自律コンピューティング、科学アプリケーション、リソース管理、スケジューリングとフォールトトレランス、サイバーセキュリティなど、グリッドとクラウドにおける並列および分散コンピューティングのさまざまな側面に焦点を当てています。

AWS Summit のシーズンがやってきました! AWS Summit は世界中の主要都市で開催される無料の対面イベントで、クラウドの専門知識を地域コミュニティに紹介しています。各 AWS Summit では、最新のイノベーションに焦点を当てた基調講演、技術セッション、ライブデモ、 Amazon Web Services (AWS) エキスパートによるインタラクティブなワークショップを実施します。先週は、 AWS Summit Tel Aviv と AWS Summit Singapore が開催されました。 AWS Summit Tel Aviv での満員の基調講演の写真をご紹介します。 お近くの AWS Summit を検索 して、クラウドジャーニーの次の一歩を踏み出している何千もの AWS のお客様やクラウドプロフェッショナルと一緒にご参加ください。 5 月 26 日週、私が最も興味を持ったのは、re:Invent 2024 でプレビュー版が紹介された Amazon Aurora DSQL の一般提供 に関する発表でした。Aurora DSQL は最速のサーバーレス分散 SQL データベースです。事実上無制限のスケーラビリティと最高の可用性を活用して、インフラストラクチャ管理なしで常に利用可能なアプリケーションを構築できます。 Aurora DSQL のアクティブ-アクティブ分散アーキテクチャは、単一リージョン 99.99%、マルチリージョン 99.999% の可用性を実現するように設計されており、単一障害点がなく、障害復旧が自動化されています。つまり、リージョンのクラスターエンドポイントに接続できないというまれな状況でも、アプリケーションは強固な一貫性で読み取りと書き込みを継続することができます。 さらに興味深いのは、Aurora DSQL の構築の舞台裏での過程です。これは、エンジニアリングの効率性を追求するテクノロジーだけにとどまらない物語です。ワーナー ヴォゲルス博士によるブログ記事「 とにかくスケールしよう: Aurora DSQL の物語 」で、全文をお読みいただけます。 5 月 26 日週のリリース 私が注目したその他のリリースをいくつかご紹介します。 AWS サーバーレスとコンテナ向けの新しいモデルコンテキストプロトコル (MCP) サーバーの発表 – MCP サーバーが AWS Lambda、Amazon Elastic Container Service (Amazon ECS)、Amazon Elastic Kubernetes Service (Amazon EKS)、Finch で利用できるようになりました。MCP サーバーでは、お使いの AWS サービスを正しく操作する方法に関する最新のフレームワークに AI アシスタントがアクセスできるようにすることで、アイデアから本番環境までの時間を短縮できます。オープンソース MCP サーバーをダウンロードして試すには、 aws-labs GitHub リポジトリ にアクセスしてください。 Amazon FSx for Lustre Intelligent Tiering の一般提供の発表 – FSx for Lustre Intelligent-Tiering は、アクセスパターンに基づいてコールドデータを適切な低コストストレージ階層に階層化することで、コストを自動的に最適化します。また、低レイテンシーであることが極めて重要なワークロードのパフォーマンスを向上させるオプションの SSD 読み取りキャッシュが含まれています。 Amazon FSx for NetApp ONTAP が ONTAP FlexCache ボリュームのライトバックモードのサポートを開始 – ライトバックモードは、複数の AWS リージョンとオンプレミスのファイルシステムに分散されている、書き込みの多いワークロードのパフォーマンスを向上させるのに役立つ新しい ONTAP 機能です。 AWS Network Firewall が複数の VPC エンドポイントのサポートを追加 – AWS Network Firewall は、1 つのファイアウォールのアベイラビリティーゾーンごとに最大 50 の Amazon Virtual Private Cloud (Amazon VPC) エンドポイントの設定のサポートを開始しました。この新機能により、一元化されたセキュリティポリシーを使用して、Network Firewall のデプロイを複数の VPC にスケールするための選択肢が増えました。 Cost Optimization Hub が Savings Plans と予約設定のサポートを開始 – 請求とコスト管理コンソールの機能である Cost Optimization Hub を使用して、希望の Savings Plans、予約期間、支払いオプションを設定できるようになりました。これにより、結果として得られる推奨事項と、希望のコミットメントに基づく潜在的な節約額を確認できます。 AWS Neuron が NxD Inference GA、新機能、改善されたツールを導入 – Neuron 2.23 のリリースにより、NxD Inference ライブラリ (NxDI) はベータ版から一般提供版に移行し、すべてのマルチチップ推論のユースケースで推奨されるようになりました。Neuron 2.23 では、コンテキスト並列処理や Odds Ratio Preference Optimization (ORPO) などの新しいトレーニング機能も導入され、PyTorch 2.6 と JAX 0.5.3 のサポートも追加されています。 AWS 料金見積りツールが一般提供を開始し、割引や購入コミットメントをサポート – AWS コンソールで AWS 料金見積りツールの一般提供を開始したことが発表されました。ワークロードのコスト見積もりと AWS 請求の全額見積もりという 2 種類のコスト見積もりを提供することで、より正確かつ包括的なコスト見積もりを作成できるようになりました。また、コスト見積もりを作成する際に、過去の使用量をインポートしたり、正味の新規使用量を作成したりすることも可能です。さらに、価格割引と購入コミットメントの両方を含む新しい料金設定により、コストシナリオにおける潜在的な節約額とコスト最適化をより明確に把握できます。 AWS CDK Toolkit Library の一般提供を開始 – AWS CDK Toolkit Library は、スタックの合成、デプロイ、破棄などの AWS CDK のコア機能へのプログラムのアクセスを提供します。このライブラリを使用すると、CDK 操作をアプリケーション、カスタム CLI、自動化ワークフローに直接統合できるため、インフラストラクチャ管理の柔軟性と制御性が向上します。 Red Hat Enterprise Linux for AWS の発表 – RHEL 10 以降の Red Hat Enterprise Linux (RHEL) for AWS の一般提供が開始され、Red Hat のエンタープライズグレードの Linux ソフトウェアとネイティブの AWS 統合が組み合わされました。RHEL for AWS は、AWS 上で実行される RHEL の最適なパフォーマンスを実現するように構築されています。 AWS のお知らせの詳細なリストについては、「 AWS の最新情報 」ページをご覧ください。 その他のアップデート その他の興味深いプロジェクト、ブログ記事、ニュースをいくつかご紹介します。 AI on EKS の紹介: Amazon EKS を使用したスケーラブルな AI ワークロードの強化 – AI on EKS は、Amazon EKS で AI/ML ワークロードをデプロイ、スケール、最適化できるように設計された、AWS の新しいオープンソースイニシアチブです。AI on EKS リポジトリには、分散トレーニング、LLM 推論、生成 AI パイプライン、マルチモデルサービス、エージェント AI、GPU および Neuron 固有のベンチマーク、MLOps ベストプラクティスのデプロイ準備が整ったブループリントが含まれています。 AWS の地理空間基盤モデルによる地球観測の革命 – 地理空間データ用の新しいトランスフォーマーベースのビジョンモデル (地理空間基礎モデル (GeoFM) とも呼ばれる) は、大陸規模で地球の表面をマッピングするための新しい強力なテクノロジーを提供します。この投稿では、Amazon SageMaker で大規模な推論と微調整を行うために、Clay Foundation の Clay Foundation Model をデプロイする方法について説明します。 すぐにデプロイできるコードサンプル を使用して、AWS の独自のアプリケーションに GeoFM をデプロイし、すぐに開始できます。 AI アシスタントの枠を超える: 生成 AI を使用して業界を刷新した Amazon.com の例 – 非会話型アプリケーションには、より高いレイテンシー耐性、バッチ処理、キャッシュなどの独自の利点がありますが、自律型であるため、リアルタイムのユーザーフィードバックと監視の恩恵を受ける会話型アプリケーションと比較した場合、より強力なガードレールと徹底的な品質保証が必要です。この投稿では、非会話型生成 AI アプリケーションの 4 つの多様な Amazon.com の例を紹介します。 近日開催される AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Summit – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。お近くの都市でご登録ください: ストックホルム (6 月 4 日)、 シドニー (6 月 4 日～5 日)、 ハンブルク (6 月 5 日)、 ワシントン (6 月 10～11 日)、 マドリード (6 月 11 日)、 ミラノ (6 月 18 日)、 上海 (6 月 19 日～20 日)、 ムンバイ (6 月 19 日)。 AWS re:Inforce – 6 月 16日～18 日には、ペンシルバニア州フィラデルフィアで AWS re:Inforce が開催されます。AWS re:Inforce は、AWS セキュリティソリューション、クラウドセキュリティ、コンプライアンス、アイデンティティに焦点を当てた学習カンファレンスです。 AWS Community Days – 世界中のエキスパート AWS ユーザーと業界リーダーによるテクニカルディスカッション、ワークショップ、ハンズオンラボが提供される、コミュニティ主導のカンファレンスにご参加ください。開催地は、 米国ミルウォーキー (6 月 5 日)、 メキシコ (6 月 14 日)、 ケニアのナイロビ (6 月 14 日)、 コロンビア (6 月 28 日) です。 6 月 2 日週のニュースは以上です。6 月 9 日週にお届けする次回の Weekly Roundup もお楽しみに! – Prasad 原文は こちら です。

こんにちは！AI/ML スペシャリストソリューションアーキテクトの近藤です。 2025年5月22日に「AI コーディングエージェント with AWS 〜「自律的にコードを書くAI」の AWS での始め方徹底ガイド〜」と題したオンラインセミナーを開催しました。AI によるコーディング技術が急速に発展し、ソフトウェア開発の生産性を劇的に向上させる可能性を秘めたこの革新的技術について、多くの方にご参加いただきました。本ブログでは、そのセッション内容を簡単にご紹介しつつ、発表資料と録画を公開いたします。 セッションの紹介 Keynote : AIエージェント時代のソフトウェア開発 アマゾンウェブサービスジャパン シニアソリューションアーキテクト 高野 賢司 [資料] [動画] 最初のセッションでは、高野より、AIコーディングエージェントの仕組みや背景について解説しました。ソフトウェア開発の歴史を振り返りながら、AIコーディングエージェントがどのように登場し、どのように機能するのかを説明しました。また、AI駆動開発の特徴や、組織への導入方法についても触れ、エンジニアとしてAIと共に開発していくための心構えについても言及しました。 Amazon Q Developer で始めるAIコーディングエージェント アマゾンウェブサービスジャパン ソリューションアーキテクト 国兼 周平 [資料] [動画] 2つ目のセッションでは、国兼より、Amazon Q Developerを使ったAIコーディングエージェントの始め方を解説しました。Amazon Q Developerの概要から、特にCLIでのエージェント型コーディング体験に焦点を当て、実際のデモを交えながら紹介しました。デモでは、カスタマーサーベイアプリケーションの開発を通じて、Amazon Q Developer CLIがどのように自律的にコードを生成し、問題を解決していくかを示しました。また、MCPサーバーを活用したイラスト生成やウェブ検索の機能も紹介され、AIコーディングエージェントの可能性の広さを感じられる内容となりました。 Cline with Amazon Bedrock で始めるAIコーディングエージェント アマゾンウェブサービスジャパン ソリューションアーキテクト 黒澤 蓮 [資料] [動画] 3つ目のセッションでは、黒澤より、Clineと呼ばれるオープンソースのAIコーディングエージェントツールと、Amazon Bedrockを組み合わせた活用方法について解説しました。Clineの特徴として、エージェント主導型の開発が可能であること、既存の統合開発環境に簡単に組み込めること、そして裏側で好きなモデルを利用可能であることなどが挙げられました。デモではVS Code上でClineを使ってテトリスアプリを短時間で作成する様子を紹介し、その効率性を示しました。また、組織でClineを導入する際の課題と対応策についても詳しく解説され、セキュリティとコンプライアンス、トークン消費とAPI制限、コスト管理といった観点からの考慮点が示されました。 お客様事例 LT：合同会社DMM.com「ソフトウェア品質特性、意識してますか？ AIの真の力を引き出す活用事例」 合同会社DMM.com エンジニア ミノ駆動 氏 [資料] [動画] 4つ目のセッションでは、DMM.comのミノ駆動氏より、ソフトウェア品質特性に基づいたAIコーディングエージェントの活用事例が紹介されました。ソフトウェア開発においてAIの力を引き出すには、ソフトウェア品質測定に基づいて指示する必要があるという視点から、変更容易性と機能適合性という2つの品質特性に焦点を当てた活用事例が紹介されました。特に「バグサーチャー」と呼ばれる負債分析用のプロンプトエンジンと、契約による設計を踏まえたテストコード生成の事例が詳細に解説され、AIを活用することで人間の10倍以上の生産性で高品質な分析やテストコードの作成が可能になることが示されました。 お客様事例 LT：株式会社プロトソリューション「Amazon Q Developer 活用事例 in ベトナム」 株式会社プロトソリューション ソリューション開発オフショア 課長 Sankame 氏 [資料] [動画] 5つ目のセッションでは、プロトソリューションのSankame氏より、ベトナムオフショア開発拠点でのAmazon Q Developerの活用事例が紹介されました。従来型のオフショア開発からの脱却を目指し、AIによって少数精鋭の高生産性体制へのシフトを進めている状況が説明されました。Amazon Q Developer IDE版の導入により、炎上気味だったプロジェクトが納期に間に合い、リリース後のバグもほとんど発生しなかった成功事例や、保守プロジェクトでの工数削減効果（約20〜30%）などが紹介されました。また、AIエージェント中心の開発フローの構築や、MCPサーバーを活用したE2Eテストの効率化など、先進的な取り組みについても詳しく解説されました。 AIコーディングエージェントを実際に現場で使うためには？ アマゾンウェブサービスジャパン AI/ML スペシャリストソリューションアーキテクト 近藤 健二郎 [資料] [動画] 最後のセッションでは、近藤より、AIコーディングエージェントを実際に現場で使うための考慮点について解説しました。主に開発チームのプロジェクトマネージャーや意思決定者の視点から、AIコーディングエージェント導入時のリスク管理、コスト管理、ログ管理、権限管理、コード品質管理などの観点について具体的な方法が紹介されました。特に、リスクベースアプローチの考え方に基づき、リスクがあるからといって禁止するのではなく、どう安全に活用していくかという方向性が強調されました。また、組織的な活用に向けた次のステップとして、ツールの選定、用途の明確化、各種管理方法の検討などのポイントが示されました。 まとめ AIコーディングエージェントは、ソフトウェア開発の方法を根本から変える可能性を秘めた技術です。本セミナーを通じて、その仕組みや活用方法、組織への導入方法について多角的に理解を深めていただけたのではないかと思います。 AWSでは、Amazon Q DeveloperやAmazon Bedrockなど、AIコーディングエージェントを安全かつ効率的に活用するためのサービスを提供しています。また、お客様事例からも分かるように、すでに多くの企業がこれらのツールを活用して開発効率の向上を実現しています。今回のセミナーがきっかけとなり、皆様の組織でもAIコーディングエージェントの活用が進むことを願っています。 AWS では、生成AIを活用したビジネス活動創造を支援する 「実用化推進プログラム」 も実施しておりますので、ご興味のある方はぜひご検討ください。 2025年6月25、26日に開催される AWS Summit Japan でもコーディングエージェントに関連したセッションやブースを用意しております。本セミナーのKeynoteで話した高野からは 「AI Agent時代のソフトウェア開発の型 ~ Everything as Code で叡智を伝える ~」 というセッションを予定しております。ぜひご参加ください。 最後に、本セミナーにご参加いただいた皆様に心より感謝申し上げます。今後もAWSは、最新のAI技術を活用したソリューションの提供を通じて、お客様のビジネス成長をサポートしてまいります。 アマゾン ウェブ サービス ジャパン合同会社 AI/ML スペシャリストソリューションアーキテクト 近藤 健二郎

このブログは、 “ Highlights from the 2025 AWS Life Sciences Symposium’s Drug Discovery track ” の翻訳です。 5月6日、ニューヨークで開催された第7回AWS ライフサイエンスシンポジウム には、 400を超える組織から1,000名以上のライフサイエンス業界のリーダー が集いました。「AIがもたらすブレークスルー：製薬バリューチェーンの革新」をメインテーマに掲げ、39名の専門家による26のセッションが開催され、ライフサイエンス分野におけるAI活用の成功事例や課題について、活発な議論が交わされました。シンポジウムを通じて浮かび上がった明確なメッセージ。それは、生成AIがもはや未来の技術ではなく、すでに医薬品の発見から開発、提供方法に至るまで、製薬業界全体を変革する原動力となっているという事実です。特に創薬分野のセッションでは、AIの活用により研究が加速し、科学的精度が向上し、コストが削減され、結果として新しい治療法をより迅速に患者のもとへ届けられるようになっている具体例が次々と紹介されました。 創薬プロセスの抜本的な見直しに向けて 私たちは今、科学、データ、テクノロジーが融合して全く新しい治療法の地平を切り開く、バイオメディカルイノベーションの黄金期にいます。しかし、創薬プロセスは依然として時間がかかり、高コストで、成功の見通しも不確実なままです。医薬品候補の約90%が臨床試験で失敗し、1つの治療薬を市場に送り出すまでに10年以上を要することもあります。巨額の投資が行われているにもかかわらず、多くの疾患に対して効果的な治療法が見つかっていないのが現状です。 この課題の根本にあるのは、生物学そのものが持つ驚くべき複雑さです。私たちの体内には数千種類の細胞、2万を超える遺伝子が存在し、それらの間で起こる分子レベルの相互作用は個人によって千差万別です。研究者たちは、10⁶⁰もの低分子と、20³²にも及ぶ治療用抗体の候補という、ほぼ無限とも言える可能性の中から最適な選択を迫られています。さらに、研究に不可欠なデータは、学術誌やデータベース、各社の独自システムに散在し、体系化されていない状態で存在しています。従来のR&amp;Dツールは確かに優れたものですが、このような規模と複雑さ、そしてスピードへの要求に十分に応えられる設計にはなっていません。 経済面での課題も深刻です。製薬会社は今後数年間で、特許切れ（LOE）により推定2,500億ドルもの収益が失われるリスクに直面しています。イノベーションギャップは広がる一方であり、外部からの資産取得は一時的な解決策にはなりますが、長期的な成功のカギは社内での改革にあります。 このような状況を打開するため、製薬業界にはAIを中心に据えた新しいR&amp;D戦略が必要です。これは単に試行回数を増やすだけでなく、個々の取り組みをより迅速に、より正確に、そしてより成功の可能性が高いものにすることを目指しています。 この変革は、段階的な改善ではなく、パラダイムシフトと呼べるものです。そして、シンポジウムの講演者たちが示したように、この変革はすでに現実のものとなっているのです。 Lab in a Loop：GenentechのAI主導型研究ビジョン Genentech の機械学習による創薬部門バイスプレジデント、 Rich Bonneau 氏が同社がAIを研究の中核に据えて、初期段階の研究プロセスを刷新している取り組みについて紹介しました。 その中心となるのが「 lab in a loop 」という概念です。これは、実験データと臨床データで学習したAIモデルが予測を行い、その結果に基づいて実験室での研究が進められるという、緊密に統合された反復サイクルを指します。新たな実験結果はモデルにフィードバックされ、予測の精度が継続的に向上していきます。このサイクルにより、研究者たちはより正確な予測のもと、広大な化学空間を効率的に探索し、複数の治療特性を同時に最適化することが可能になり、発見のプロセスが劇的に加速されています。 このような革新を支えているのは、Genentechが数十年にわたる研究・臨床活動を通じて構築してきた、質の高い大規模データセットです。これらのデータは、かつては対応が困難と考えられていた課題に取り組むAIモデルの重要な基盤となっています。さらに同社は、生成AIを研究ワークフローに直接組み込む取り組みも進めています。 AWSとの協力により開発された gRED Research Agent は、その代表例です。Amazon Bedrock Agents上で動作するAnthropic社のClaude Sonnet 3.5を搭載したこの知的アシスタントは、科学文献や構造化データベースの調査など、時間のかかる作業を自動化することで、科学者たちがより創造的で影響力の高い研究に注力できる環境を実現しています。 その効果は目覚ましく、これまで数週間を要していたプロセスが数分で完了できるようになりました。例えば、バイオマーカーの検証作業だけでも、43,000時間以上の工数削減が見込まれています。 しかし、これは単なる作業の高速化にとどまりません。科学研究そのものを、かつてない規模で展開できる新たな段階へと押し上げているのです。 セッション録画を視聴する | プレゼンテーションにアクセスする BioFMを活用した分子設計：AbbVieの包括的アプローチ 次に議論は、創薬におけるもう一つの重要課題である 低分子設計 に移りました。 AbbVie のR&amp;Dデータ分析部門バイスプレジデントの Jennifer Van Camp 氏と、グローバルリード兼主任機械学習サイエンティストの Abhishek Pandey 氏が、生物学的基盤モデル（BioFMs）を活用した革新的なアプローチについて発表しました。彼らは生物学を優先した大胆な手法で、イノベーションを推進しています。 AbbVieは画期的な成果として、ヒトゲノム全体の薬剤化可能性スコアの算出に成功しました。これは、どのタンパク質が低分子医薬品の標的として適しているかを予測するものです。この網羅的な評価は、従来のように化合物（リガンド）の特性のみに注目するアプローチからの大きな転換点となりました。AbbVieは、 EvolutionaryScale が開発したESM-2などのbioFMモデルを活用し、タンパク質とリガンドの特性、およびそれらの相互作用パターンを包括的に分析する手法を採用しています。 この生物学的な複雑さを予測可能な形に変換するため、AbbVieはESMの埋め込み技術をリガンドデータと組み合わせ、AffinityNetを開発しました。このシステムは、タンパク質、リガンド、それらの相互作用の特性を階層的に分析するグラフアテンションネットワークを用いた深層学習モデルで、結合親和性を極めて高い精度で予測することができます。これにより、生物学的な知見に基づいた、データ駆動型の低分子探索が可能になりました。 AWSのインフラストラクチャ、拡張性の高い計算能力、そして Amazon Bedrock を通じたBioFMsへのアクセスを活用することで、AbbVieは膨大な生物学的データを、かつてないスピードで実用的な知見へと変換できるようになりました。 セッション録画を視聴する | プレゼンテーションにアクセスする AIエージェント：研究者の役割の新たな形 バイオテックスタートアップのOwkinとBioptimusは、AIを活用した科学研究の新しい協働の形を提示し、生物学の理解をさらに深める取り組みを紹介しました。 Owkin のR&amp;D最高責任者の Jean-Philippe Vert 氏と製品部門VPの Thea Backlar 氏、は、生物学者が生物学者のために開発したAI搭載コパイロット「 K Navigator 」を発表しました。このシステムは高度なエージェントシステムを基盤とし、腫瘍学分野で世界最大の空間オミクスデータセットである MOSAIC Window をはじめとする膨大なデータに接続しています。研究者は自然言語での指示により、多様なデータの探索、分析、視覚化が可能になり、科学的直感を増強し、作業の効率を高め、複雑な問いを実用的な知見へと変換できます。これにより、創薬ターゲットの特定、患者グループの特性評価、既存薬の新たな用途発見などが促進されます。 研究者は現在、3,500万件を超える科学論文へのアクセス、臨床試験の設計、患者データの調査を、単一のインターフェースから行うことができます。しかし、K Navigatorは単なる効率化ツール以上の存在です。これは、人間とAIが協力して新たな知見を生み出し、これまで到達できなかった科学的領域を探索するための新しいパラダイムを示しています。すでにアカデミアで利用可能なこのプラットフォームについて、Owkinは 生物学的人工超知能 （BASI）への足がかりとして位置づけています。これは、AIが人間の発見能力を大規模に拡張する協働システムとなることを目指しています。 一方、フランスのスタートアップ Bioptimus は、生物学特有の多面的な性質に着目したアプローチを展開しています。シンポジウムでは、共同創業者兼主任研究員の Zelda Mariet 氏が、数百万枚の病理画像スライドで学習させた基盤モデル「 H-optimus-1 」について発表しました。このモデルは、がんの種類の分類、腫瘍の段階評価、バイオマーカーの検出、デジタルスライドの品質管理など、主要な診断・研究領域で最高水準の性能を実現しています。生物学における異なるスケール間の関係性を学習することで、より深い洞察を可能にしているのです。 現在、AWS Marketplaceで利用可能 となったこのモデルにより、ヘルスケア・ライフサイエンス分野のお客様は、Bioptimusの最先端病理モデルを自社の安全なクラウド環境に素早く導入し、AWSベースのワークフローにシームレスに統合することができます。これにより、病理学や生物医学研究における知見の獲得が迅速化され、業務効率が大幅に向上します。 しかし、これはほんの始まりに過ぎません。Bioptimusは現在、ゲノミクス、分子データ、イメージング、臨床記録を統合した次世代マルチモーダルモデル「 M-optimus 」の開発を進めています。このモデルは、生命現象のあらゆる複雑さを学習対象とするよう設計されています。彼らの野心的な目標は、生物学における世界初の汎用AIファンデーションモデルの創出です。 セッション録画を視聴する | プレゼンテーションにアクセスする 未来のラボの構築 Deloitte のヘルスケアおよびライフサイエンス部門のマネージングディレクターの Raveen Sharma 氏は、「 未来のラボ 」についての斬新なビジョンを提示しました。それは、計算科学と実験科学が完璧に調和したデジタル統合型のAI駆動エコシステムです。このシステムでは、ドライラボとウェットラボがリアルタイムデータと自動化技術によって緊密に連携し、継続的かつインテリジェントなループを形成することで、科学的発見のプロセスを加速させます。 このモデルにおいて、ドライラボはAIモデルの訓練、調整、改良を担当し、計算機上で実験をシミュレートします。一方、ウェットラボは実際の実験を通じて仮説を検証し、高品質な実験データをシステムにフィードバックします。このデータは FAIR 原則（Findable：見つけやすい、Accessible：アクセスしやすい、Interoperable：相互運用可能、Reusable：再利用可能）に基づいて管理されることで、ループ全体の自己改善が促進され、研究のスピードと科学的厳密性の両立が図られます。 DeloitteとAWSは、このビジョンを実現するため、データの取り込み、統合、ガバナンスを自動化するクラウドネイティブなモジュール型ソリューションを開発しました。これにより、従来は断片化していた研究室のデータを FAIR な資産へと転換することが可能になります。DeloitteのLab of the Futureアクセラレータは、物理的な研究機器とデジタルインフラの間のギャップを埋め、 AWS DataSync 、 AWS IoT Greengrass 、 Amazon S3 、 Amazon DataZone など、実績あるAWSサービスを活用しています。そして、これらすべてを AWS Control Tower で一元管理する仕組みを構築しています。 この新しいアプローチがもたらす影響は大きく、科学者たちはデータ管理に費やす時間を大幅に削減し、本質的な研究活動により多くの時間を充てることができるようになります。結果として、より質の高い治療候補の開発が加速され、革新的な治療法をより迅速に患者のもとへ届けることが可能となるのです。 セッション録画を視聴する | プレゼンテーションにアクセスする データの壁を打ち破る：連合学習による安全な協力体制 科学の進歩は協力があってこそ最も加速します。この原則は、特に創薬の分野で顕著です。 現代の創薬におけるAI活用の最大の課題の一つは、効果的なモデルの学習に不可欠な高品質なタンパク質とリガンド構造データへのアクセスです。確かに公共データベースは存在しますが、困難な創薬ターゲットに対する薬剤設計に必要な、構造的な多様性や分子間相互作用に関する深い知見が不足しています。製薬企業は、これらの相互作用を捉えるための独自のデータセット構築に多額の投資を行ってきましたが、データの機密性が企業間の協力を妨げ、結果として個々の進歩を遅らせる要因となってきました。 連合学習は、こうした壁を打ち破りつつあります。活発な議論が交わされたパネルディスカッションでは、 Johnson &amp; Johnson のIn Silico Discovery部門VP Justin Scheer 氏、AbbVieの計算創薬部門長 John Karanicolas 氏、そして Apheris の共同創業者兼CEO Robin Röhm 氏が、 AI Structural Biology（AISB）コンソーシアム の取り組みを紹介しました。このコンソーシアムは、連合学習を活用することで、各社の機密データを公開することなく、分散したデータセット全体でAIモデルを協調的に学習させることに成功しています。この手法により、知的財産を保護しながら、薬剤の特異性向上や分子間相互作用の最適化、より効果的な治療法の開発加速に向けた知見の共有が可能となっています。 AIモデルの構造予測精度がX線結晶構造解析と同等のレベルに達しつつある今、連合学習は安全で協調的な創薬の新時代を切り開いています。これにより、業界全体の知見を結集し、精密医療における画期的な進展を加速することが可能になってきているのです。 セッション録画を視聴する 発見の新時代 わずか10年前、AIが私たちの移動手段、買い物、音楽鑑賞、ニュース消費の方法を根本から変えることになるとは、ほとんど誰も想像していませんでした。 そして今、同様の変革が創薬の現場で起きています。AIはもはや実証実験の段階を超え、研究開発の全工程において実質的な進歩をもたらしています。科学者たちは、AIの支援を受けながら疾病の生物学的メカニズムを解明し、より効果的な治療法をこれまでにないスピードで設計できるようになっています。これにより、長年にわたって治療法の確立が困難とされてきた疾患に対しても、新たな希望がもたらされています。 2025年のAWSライフサイエンスシンポジウムで明らかになったのは、AIがもはや研究の補助的なツールではないということです。基盤モデル、マルチモーダルデータ、AIエージェント、クラウドネイティブインフラストラクチャーを通じて、研究そのものを根本から変革しているのです。創薬の未来は遠い将来の話ではありません。その変革は、まさに今ここで進行しているのです。 AWSは、お客様がより遠くへ、より速く進むことをサポートできることを誇りに思っています。 世界の大手製薬会社トップ10社のうち9社が、生成AIと機械学習戦略の実現にAWSを選択している という事実は、私たちへの信頼の表れだと考えています。 次のステップを加速するための方法について、詳しくはAWSの担当者までお問い合わせください。 参考資料： 第7回AWS Life Sciences Symposium： 基調講演のハイライト | 基調講演のダイジェスト動画を視聴する ライフサイエンスのイノベーションをAWSのAIエージェントで加速 臨床開発セッションのハイライト – 第7回 AWS ライフサイエンス シンポジウム 製造セッションのハイライト – 第7回 AWS ライフサイエンス シンポジウム コマーシャルセッションのハイライト – 第7回 AWS ライフサイエンス シンポジウム <!-- '"` --> Oiendrilla Das Oiendrilla DasはAWSのライフサイエンスおよびゲノミクスマーケティングのカスタマーアドボカシーリードです。ライフサイエンスマーケティングのバックグラウンドを持ち、ライフサイエンスとクラウドコンピューティングを専門としています。マーケティングのMBA学位を取得しており、MBA取得前にはバイオテクノロジーの工学を修了しています。 このブログは、Senior Solutions Architectの松永が翻訳しました。

このブログは、 “ Highlights from the 2025 AWS Life Sciences Symposium’s Clinical Trials track ” の翻訳です。 5月6日、ニューヨークで第7回AWS ライフサイエンスシンポジウム が開催され、 400を超える組織から1,000名以上の業界リーダー が参加しました。「AIがもたらすブレークスルー：製薬バリューチェーンの革新」をテーマに、39名の専門家による26のセッションが行われ、創薬から医薬品提供までの一連のプロセスにおけるAI活用の実践例が紹介されました。 このシンポジウムで明らかになったのは、生成AIがもはや未来の技術ではなく、すでに製薬業界の現場で活用され、新薬の発見から開発、提供方法まで、さまざまな場面で変革をもたらしているという事実です。特に 臨床開発分野 では、治験実施計画書の作成から実施施設の選定、被験者の登録、規制当局へのデータ提出に至るまで、AIによる効率化の効果が顕著に表れています。 臨床試験の変革期 臨床試験を取り巻く環境は、今まさに大きな転換点を迎えています。新薬開発には平均6～7年、費用にして最大26億ドルもの膨大なリソースが必要とされます。特に深刻な課題が被験者の募集で、全体の時間とコストの3分の1を占めているにもかかわらず、8割の試験で目標被験者数を確保できず、85%で参加者の継続的な確保に苦心しています。さらに、試験の複雑化とグローバル化が進む中、従来の手作業中心のプロセスでは、もはや効率的な運営が困難になっています。 このような課題に対し、AIは画期的な解決策を提供します。組織内のデータとリアルワールドエビデンスを効果的に活用することで、臨床試験のあり方そのものを革新できます。試験デザインの最適化や被験者募集の予測から、最適な被験者とのマッチング、さらには自動データ収集や異常検知によるリアルタイムモニタリングまで、データを基盤とした迅速かつ柔軟な試験運営が可能となります。 今こそ、行動を起こすべき時です。FDAをはじめとする規制当局が、臨床開発におけるAI活用のガイドラインを明確化し始めています。この時期に先駆的な取り組みを行う企業には、業界標準の確立と次世代イノベーションをリードする貴重な機会が開かれています。迅速に行動を起こすことで、開発スピードの向上、コストの効率化、データ品質の改善、より幅広い患者層の包含という面で、大きな優位性を確保することができます。 この期待感と変革への意欲は、臨床開発ブレイクアウトトラックでも強く感じられました。先進的な組織各社が、AIを活用した臨床研究の革新的な取り組みを次々と発表。その主な事例をご紹介します。 アストラゼネカの挑戦：AIによる臨床試験の効率化 アストラゼネカ は、画期的なツール 「Development Assistant」 を発表しました。AWS上で稼働するこの生成AI搭載システムは、臨床データの利用効率を大幅に向上させ、意思決定プロセスを迅速化します。同社の患者安全性担当上級ディレクター、 Vaishali Goyal 氏は、このツールを使用することで、臨床開発チームが自然言語で構造化・非構造化データを自由に検索でき、エビデンスに基づく知見をリアルタイムで得られる仕組みを解説しました。 アストラゼネカは、 Amazon Bedrock を基盤としたプラットフォームを開発し、検索拡張生成（RAG）技術とtext-to-SQL機能を組み込みました。この革新的な組み合わせにより、同社の持つ膨大なデータ資産から、必要な情報を瞬時に抽出することが可能になりました。システムが提供する情報には必ず出典が明記され、追跡可能性が確保されています。これにより、被験者募集や治験実施施設の選定といった業界の重要課題に対して、透明性と信頼性を保ちながら、作業の自動化による効率化を実現しています。 Development Assistantの成功を支えているのは、アストラゼネカが築き上げた堅固なデータ基盤です。同社は、電子研究ノート（ELN）やラボ情報管理システム（LIMS）、臨床システムなど、様々なデータソースを厳選して整備し、FAIR原則（検索可能、アクセス可能、相互運用可能、再利用可能）に準拠したデータプロダクトへと転換しました。これらのデータは、拡張性の高いマルチモーダルAIアプリケーションの重要な資源となっています。 2024年半ばに試験的に導入されたDevelopment Assistantは、わずか6ヶ月で厳格なサイバーセキュリティ基準とAIガバナンス要件をクリアし、実用最小限の製品（MVP）として本番環境での運用を開始しました。複数のAIエージェントを組み合わせた設計により、増加し続けるユーザーのニーズやデータの複雑化にも柔軟に対応できる拡張性を備えています。 アストラゼネカは2025年までに、ユーザー数を1,000人以上に拡大し、より豊富なデータソースとの連携を強化するとともに、部門を越えたシームレスな協働を実現する計画を進めています。Development Assistantは、同社における次世代のAI主導型臨床開発の礎となっています。 セッション録画を視聴する | プレゼンテーションにアクセスする Facultyが提唱するAIエージェント導入の実践的アプローチ アストラゼネカの発表に続いて、 Faculty のチーフテクノロジーオフィサー、 Andy Brookes 氏が登壇し、 組織がAIエージェントを効果的に導入・活用するための実践的なフレームワーク を提示しました。Brookes氏は、AIエージェントの成功を支える3つの重要な要素として、「役割の明確な定義」「ビジネスコンテキストの理解」「パフォーマンス管理」を挙げました。 特に強調されたのが、AIエージェントの役割定義です。同氏は、OUDA（観察・理解・決定・行動）モデルを用いてタスクを決定ループとして構造化することを提案しました。この方法により、AIエージェントは単なる汎用アシスタントではなく、特定のビジネスニーズに応える目的特化型のツールとして機能します。複雑性とリスクを抑えながら、確実な成果を上げることが可能になります。 また、AIエージェントを組織の業務環境に効果的に統合する重要性も指摘されました。Faculty社が「プライベートワールドモデル」と呼ぶこのアプローチは、組織固有の方針やプロセス、制約事項をデジタルシミュレーションとして再現します。これにより、AIエージェントは組織の実態に即した判断が可能になり、本格展開前の安全なテストや、誤作動リスクの低減が実現します。 さらに、パフォーマンス評価においては、処理速度や精度だけでなく、信頼性や判断過程の透明性など、定量・定性両面からの総合的な評価の重要性を説きました。 Brookes氏は、AIエージェントの発展段階を以下の4つのレベルで整理しました： スカウト：情報収集と発見 アナリスト：状況分析と提案 オペレーター：人間の監督下での業務実行 オートパイロット：定められた範囲内での自律的な業務遂行 同氏は、組織がこれらのレベルを段階的に導入することで、即座に価値を生み出しながら、より大規模なシステム変革へと着実に歩を進めることができると提言しました。 セッション録画を視聴する | プレゼンテーションにアクセスする ノバルティス：適応型AI戦略による臨床試験の加速 ノバルティスのデジタルイノベーション、戦略、プログラム＆ポートフォリオオペレーション部門ディレクターであるNoah Hoh氏は、同社が医薬品開発の期間短縮を目指し、R&amp;Dパイプライン全体でAIとデータサイエンスを戦略的に活用している取り組みについて説明しました。 ノバルティスは開発期間を短縮するために3つの重要なイニシアチブを展開しています： Fast-to-IND：治療領域全体で治験薬申請までの期間を12ヶ月短縮 Enhanced Operations：効率性の改善と革新的な試験デザインにより1-2年の時間短縮を実現 AI-Enabled R&amp;D：R&amp;Dライフサイクル全体で予測モデリングとAIシミュレーションを活用し、サイクルタイムを6ヶ月以上短縮 これらのイニシアチブを統合的に推進することで、医薬品開発の総期間を最大19ヶ月短縮することが可能となります。 この変革の中核となっているのは、ノバルティスの適応型AI戦略です。画一的なアプローチを避け、各開発段階に最適な機能を適合させる的確なAI戦略を採用しています。臨床試験における主要な活用領域には、プロトコル設計、実施施設の選定、臨床業務の最適化、文書作成の自動化、意思決定支援システムなどが含まれます。 AWS上に構築されたIntelligent Decision System（IDS）は、このアプローチを具現化したものです。IDSはデジタルツインを活用して臨床試験のワークフローをシミュレートし、実施前に様々な戦略のテストや結果予測を可能にします。これによりリスクを最小限に抑えながら、運用効率を大幅に向上させています。 ノバルティスは段階的な実装アプローチを採用し、R&amp;D全体でのAI統合に向けて着実に歩を進めながら、即座に効果を実感できる施策を展開しています。この実践的で段階的なアプローチにより、現場のスタッフが日々の業務でAIの恩恵を実感しながら、将来的なAI活用の基盤を築いています。その戦略は明確です：即座に測定可能な成果を生み出しながら、長期的な変革に向けた取り組みを着実に進めていくことです。 セッション録画を視聴する | プレゼンテーションにアクセスする メルク：スケーラブルな最新の臨床データプラットフォームの構築 生成AIを活用する競争が加速する中で変わらない真実があります。それは、AIの効果はそれを支えるデータの質に大きく依存するということです。現在の臨床試験は、分断されたシステムとサイロ化されたデータという課題に直面しており、これらが複雑なアーキテクチャを生み出し、イノベーションと規制遵守の障壁となっています。 メルク は、VeevaのDevelopment Data Platformを搭載したAWSベースの最新の臨床データプラットフォームを通じて、この課題に取り組んでいます。メルクのエグゼクティブディレクターである Gopi Gopinath 氏と、Clinical and RWE ITのAVPである Marjorie Waters 氏は、この変革が統一されたメタデータ駆動型アーキテクチャを通じて臨床業務を効率化する方法を共有しました。このプラットフォームは、分断された臨床、運用、規制、安全性データを単一の信頼できるソースに統合し、データの整合性を維持しながらより迅速な試験の実施を可能にします。 このプラットフォームは、内部システムと外部パートナー間のデータを1つの統一されたリポジトリに統合し、Study Data Tabulation Model（SDTM）標準化、自動化された第三者データ取り込み、データマスキングとロールベースのアクセスを含む強化されたセキュリティ機能、中央化されたメタデータ管理、セルフサービス分析ツールといった主要な機能を提供します。統合された分析と可視化ツールにより、このプラットフォームは試験計画、患者登録、サイトパフォーマンス、リスクベースのモニタリングに関する重要な洞察を提供し、運用の負荷を軽減し、予防的な意思決定を可能にします。 新しいアーキテクチャはまた、プロトコルとレポートの作成のための生成AI活用、試験成功のための予測モデリングの実装、プロトコル最適化のためのシミュレーションツールの開発、合成対照群の作成など、高度なAIアプリケーションの基盤を確立します。 クラウドネイティブでプラットフォームベースのアプローチを採用することで、メルクは試験インフラを近代化するだけでなく、臨床開発における生成AIの可能性を完全に実現するために必要なデジタル基盤を構築しています。 セッション録画を視聴する | プレゼンテーションにアクセスする より迅速なデータ駆動型臨床試験の洞察のためのリアルワールドデータとエビデンスの活用 リアルワールドデータ（RWD）は現代のヘルスケアにおける意思決定を推進しています：2019-2021年のFDA承認の85%が実世界エビデンス（RWE）に依存していました。しかし、この貴重なデータは医療提供者、保険会社、医療レジストリ間に散在したままです。研究者たちは分析を開始する前にデータの収集と整理に数ヶ月を費やすことがよくあります。現在のデータサイロ、プライバシー要件、複雑なデータベースクエリは、この貴重な情報源に対するAIツールの潜在的な活用を制限しています。 AWSのWorldWide Real World Dataリードである Praveen Haridas 氏と、 Datavant のプレジデントおよびGMである Arnaub Chatterjee 氏は、この課題に対する解決策を提示しました。 AWS Clean Rooms 上に構築された新しいプラットフォーム、 Datavant Connect は、保護された健康情報（PHI）を公開することなく、研究者がリンクされた患者データを分析することを可能にします。このプラットフォームは、従来4ヶ月かかっていた発見プロセスを2週間に短縮し、同時にデータ所有者のコントロールを維持します。これには医療保険の相互運用性と説明責任に関する法律（HIPAA）準拠とガバナンス機能が組み込まれています。つまり、スピードのためにプライバシーが犠牲にされることはありません。 製薬業界のリーダーたちは、すでにこれらの機能を活用しています。 ベーリンガーインゲルハイム のRWEセンター・オブ・エクセレンスのエグゼクティブディレクター兼グローバルヘッドである Paul Petraro 氏は、ベータブロッカーの有効性評価を例に挙げ、治療効果と経済的アウトカムをより良く理解するために、 組織がこのプラットフォームを使用してRWE戦略をスケールアップする方法 を共有しました。 さらにAWSは、データから得られる知見をより活用しやすくするため、新たなインテリジェントエージェントを導入しました。これにより、研究者はプログラミングの専門知識がなくても、自然な言葉で複雑なデータセットを検索・分析できるようになり、実世界データ（RWD）の利用がより身近なものとなりました。このエージェントは、医学文献、臨床データ、規制文書との連携機能を備えており、ユーザーの役割に応じた適切なアクセス権限の管理や、操作履歴の追跡も可能です。さらに、厳格なコンプライアンスとデータセキュリティも確保されているため、安心して利用することができます。 リリー のRWD担当シニアディレクター、 Greg Cunningham 氏は、AWS上に構築された Real World Data（RWD）Insights Agent を紹介しました。このシステムは、データ分析にかかる時間を劇的に短縮し、従来は日単位で行われていた洞察の抽出を分単位で可能にしています。この「仮想アナリスト」の特筆すべき点は、技術的な専門知識を持たないユーザーでも、SQLのような専門的なクエリ言語を使わずに、自然言語で複雑なデータセットを探索できることです。 Amazon Bedrock を基盤に構築されたこのシステムは、複数のAIエージェントを駆使してメタデータの発見やコホートの定義を管理し、同時に厳格な監査証跡とコンプライアンスの維持を実現しています。さらに、人間の監督を適切に組み込んだ責任あるフレームワークの中で、新たなデータソースの迅速な統合や組織のニーズに応じた柔軟な拡張が可能となっています。 このプレゼンテーションは、AWSが業界のリーダー企業とのコラボレーションを通じて、医療データ分析の変革に真摯に取り組んでいることを如実に示しました。より迅速なエビデンスの生成と、それに基づく患者アウトカムの改善を目指す同社の姿勢が明確に伝わってきました。 参加者たちは、AWSがDatavantのようなパートナー企業と協力し、多様なデータ提供者のネットワークからRWDを容易に発見、評価、購読できるプラットフォームを構築している様子を目の当たりにしました。さらに、購読したRWDから有意義な洞察を導き出すための、ユーザー中心の革新的なツールについても紹介されました。特に注目を集めたのは、技術的な専門知識を持たないユーザーでも、自然言語のクエリを使って複雑な医療データを分析できる、クラウドネイティブなエージェント型AIアプリケーションでした。 セッション録画を視聴する | プレゼンテーションにアクセスする | 詳細を読む 未来を見据えた今日の取り組み 生命科学分野における生成AI投資の約70%が臨床試験に向けられている現在、スピード、精度、拡張性への要求はかつてないほど高まっています。 臨床試験の分野で次々と新たなAI活用事例が登場する中、一つだけ変わらないものがあります。それは、スケーラブルで安全なデータ基盤の必要性です。この基盤があってこそ、組織は将来のどのような技術革新にも柔軟に適応し、進化し、さらなる発展を遂げることができるのです。 私たちは、この革新的な取り組みに参加してくださったすべてのパートナー、顧客、そして参加者の皆様に心からの感謝を申し上げます。これまでの成果を誇りに思うと同時に、さらなる飛躍が期待される未来に大きな期待を寄せています。 AWSの担当者に連絡する か、ライフサイエンス分野におけるイノベーションの新時代を切り開くためにAWSパートナーネットワークをぜひご活用ください。私たちと共に、医療の未来を築いていきましょう。 参考資料： 第7回AWS Life Sciences Symposium： 基調講演のハイライト | 基調講演のダイジェスト動画を視聴する ライフサイエンスのイノベーションをAWSのAIエージェントで加速 創薬研究セッションのハイライト – 第7回 AWS ライフサイエンス シンポジウム 製造セッションのハイライト – 第7回 AWS ライフサイエンス シンポジウム コマーシャルセッションのハイライト – 第7回 AWS ライフサイエンス シンポジウム <!-- '"` --> Oiendrilla Das Oiendrilla DasはAWSのライフサイエンスおよびゲノミクスマーケティングのカスタマーアドボカシーリードです。ライフサイエンスマーケティングのバックグラウンドを持ち、ライフサイエンスとクラウドコンピューティングを専門としています。マーケティングのMBA学位を取得しており、MBA取得前にはバイオテクノロジーの工学を修了しています。 このブログは、Senior Solutions Architectの松永が翻訳しました。

このブログは、 “ Highlights from the 2025 AWS Life Sciences Symposium’s Manufacturing Track ” の翻訳です。 2025年5月6日、ニューヨーク市で開催された第7回 AWS ライフサイエンスシンポジウム には、 400 以上の組織から 1,000 人を超える ライフサイエンス業界のリーダー が参加しました。「ブレークスルーの構築 – 製薬バリューチェーンを変革するAI駆動型イノベーション」という意欲的なテーマのもと、39名の業界のパイオニアによる26のセッションが開催されました。セッションでは、先進的なAIがもたらす革新的な変化により、生命を救う治療法の開発が加速され、コストが削減され、そしてこれらすべてがセキュリティとコンプライアンスを核として実現されていることが紹介されました。 基調講演のハイライト と、 ライフサイエンスのイノベーションをAWSのAIエージェントで加速 に関する主要な発表もぜひご覧ください。 世界では 20億人以上 が慢性疾患を抱え、 3億人以上 が希少疾患の影響を受けています。このような状況下で、バリューチェーン全体における製薬イノベーションの重要性は、かつてないほど高まっています。さらに、 米国インフレ削減法 などの規制圧力の高まりにより、医薬品製造とサプライチェーンの抜本的な変革が求められています。そこで今年の 製造トラック では、世界をリードする製薬企業のリーダーたちに向けて、実践的な革新的取り組みを紹介しました。これらの近代化は、業界の最も差し迫った課題に取り組むため、AWSを活用する先見性のある組織によって実現されています。目標はシンプルでした：リーダーたちが知見を共有し、学び合い、生命を救う治療法をより迅速かつ確実に提供するための具体的な進歩を持ち帰ることができる協働のプラットフォームを作ることです。これらの取り組みは、スケーラビリティの向上、コストの削減、そしてバリューチェーン全体でのレジリエンス強化を同時に実現します。 以下が主要なポイントです。 AIエージェントによる生産とサプライチェーンのブレークスルーの実現 2023年に生成AIが注目を集めて以来、製薬生産ライフサイクルのあらゆる段階—バッチプロセスの最適化、ダウンタイムの削減、SOPの自動化、手動のワークフローを俊敏な自己学習システムへの転換など—における変革への期待が高まっています。しかし、この期待に反して、組織全体での本格的な導入はまだ道半ばです。この課題を克服するには、多くの場合、視点の転換が必要です。それこそが、オープニングセッション「 Amazonから学ぶ 」が提供した価値でした。AI、ロボティクス、デジタルインフラストラクチャを大規模に適用した場合の可能性について、新鮮な視点と強力なインスピレーションを参加者に提供しました。 小売とフルフィルメントにおける数十年の運営実績を活かし、Amazon Retailのセッションでは、リアルタイムの需要予測、在庫の最適化から、ベンダー管理、コンピュータビジョンによる品質管理、ラストマイル配送に至るまで、AmazonがAIをどのように活用しているかの舞台裏を紹介しました。このセッションでは、ライフサイエンス分野のリーダーたちが直面する様々な課題に対して、具体的な解決方法を段階的に示すとともに、実際に成果を上げているテクノロジーを活用した戦略について説明しました。 セッションの後半では、製造現場に焦点が移り、 AIエージェント がすでに生産性の向上、欠陥検出の強化、トレーニング時間の短縮を実現し、保守ワークフローからMES（Manufacturing Execution Systems：製造実行システム）、さらには生産会議そのものまで、中核的な業務を再構築していることが紹介されました。 メッセージは明確でした：適切なツールとマインドセットがあれば、変革は単なる可能性ではなく、手の届くところにあるのです。 最先端のデジタル技術による自律型医薬品製造の再定義 次に、 医薬品製造イノベーションセンター のマネージングディレクターである Dave Tudor 氏が登壇し、AI、最先端のデジタル技術、持続可能な実践、そして深い分野横断的な協力によって実現される医薬品製造の未来への変革的なロードマップを示しました。Tudor氏は、生産の4つの重要な領域を再考することで、業界の最も困難な課題にどのように取り組んでいるかを共有しました： より迅速で省エネルギーな経口固形製剤製造を実現するデジタルツイン化された連続直接圧縮（CDC）プラットフォームの開発 遅延と無駄を排除するジャストインタイム、自動化された治験薬生産の実現 現在治療法のない疾患に対する治療法を可能にする、持続可能でスケーラブルなオリゴヌクレオチド生産方法の開発 医薬品製造4.0を推進する機械学習、AI、ロボティクスの導入加速 このビジョンの核となるのは、AWS上に構築された統合データ基盤を活用した、各工場が独立して運営できる新しい製造モデルです。この基盤では、工場設備、製造拠点、作業者からのデータを一元管理し、それらのデータの整理と統合を効率的に行うシステムを構築しています。さらに、誰でも簡単にデータを活用・再利用できる環境を実現しています。この強固な基盤により、製薬企業は新薬開発のリスクを抑制し、製品の市場投入までの期間を短縮することができます。また、より効率的で正確な製造プロセスが実現可能となり、人手に頼らないスマートな製造の新時代への道を開いています。 プレゼンテーションはこちら AIによる医薬品製造品質管理の革新 すべての医薬品の背後には、その安全性と有効性に依存している人々—親、医療従事者、友人、子供たち—がいます。 Pfizer のAI/ML、データ＆アナリティクスのプラットフォーム＆プロダクト担当バイスプレジデントである Michael Morelli 氏のセッションでは、この責任がPfizerの製造におけるイノベーションの規模拡大をどのように推進しているかが語られました。同氏は、Pfizerの品質管理（QC）ラボにおける品質と安全性を向上させるために設計された生成AI搭載のコンパニオンアプリ「 QC Sidekick 」を紹介しました。 QC Sidekickは、AWSの信頼性の高いデータ基盤上に構築され、 Amazon Bedrock の生成AI技術を活用することで、ラボインシデントレポートの削減と問題の原因究明をサポートしています。さらに、データを見やすく表示し、傾向を分析し、作業手順書や実験方法にすぐにアクセスできる機能により、同じ問題が繰り返し起きることを防いでいます。この取り組みにより、実験ミスの減少、より迅速な判断、そして安全で効率的なラボ運営が実現しています。また、製品の不良や高額な製造ロットの不合格を減らすことで、Pfizerの収益性向上という会社全体の目標達成に貢献しています。QC Sidekickは現在、世界中の英語を使用するPfizerの製造拠点で導入されており、175年近い同社の製造における優れた実績をさらに発展させ、 最新の生成AI技術 によって進化を続けています。 プレゼンテーションはこちら 製造現場から経営層までの可視性の実現 「測定されるものは改善される」。この原則が Merck のセッションで見事に実証されました。Merck製造部門のデジタルサービス組織のAVPである Wincy Fung 氏と、データプラットフォーム＆プロダクトのエグゼクティブディレクターである Ram Silai 氏が主導したセッションでは、MerckのVisual Factory（ビジュアルファクトリー）イニシアチブが紹介されました。同社がPSQDC（People：人材、Safety：安全性、Quality：品質、Delivery：納期、Cost：コスト）フレームワークを通じて、製造業務全体で作業を標準化し、説明責任を推進する方法が示され、製造現場から経営層までのリアルタイムの可視性が実現されています。 Mantis は、120を超えるシステムのデータを一元管理するGMP基準に準拠したデータプラットフォームで、AWS上に構築されています。このプラットフォームでは、ユーザーごとに最適化された分析、ダッシュボード、データに基づく知見を提供しています。製造現場のスタッフは、設備の総合的な稼働効率（OEE）などの重要な指標をリアルタイムで確認できます。また、各拠点の責任者は日々の業務の全体像を把握でき、経営陣は世界中の拠点のサプライチェーンの状況を統一された形式で確認することができます。この取り組みにより、Merckの世界規模の事業運営において、すべての情報が見える化され、より素早い意思決定が可能となり、データを重視する企業文化への大きな変革が実現しています。 今後、Merckはこれらのソリューションを全社的に展開し、すべてのレベルでKPIを完全に標準化し、生成AIを活用して根本原因分析とよりスマートで迅速な意思決定の実現を目指しています。 プレゼンテーションはこちら 対応型から予測型へ：AIによる製品苦情報告の変革 厳格な品質管理とKPIの追跡にもかかわらず、医薬品および医療機器企業は依然として高額な製品苦情と逸脱の課題に直面しています。企業は年間平均1,500万ドルを費やし、苦情の解決には最大20日、根本原因の特定には30日を要し、さらにそれらの原因を正確に特定する際のエラー率は89%にも上ります。この非効率性は、主に手作業で人的リソースを多く必要とするプロセスと、過去のデータの可視性の欠如に起因しています。 この課題に対処するため、 PwC は、Amazon Bedrock上に構築された、苦情と逸脱の検出、分類、解決を自動化するAI駆動型の 品質管理システム（QMS）ツールキット を紹介しました。このツールキットはあらゆる医薬品品質管理システムとシームレスに統合され、説明文からの苦情検出、AIによる調査概要の生成、逸脱報告書の自動評価、そして生成AIチャットボットを活用したグローバルな傾向分析ダッシュボードなどの機能を提供します。 その効果は顕著です：ある大手製薬企業では、このツールキットにより苦情解決時間が20日から1日に短縮され、根本原因の特定が30日から数分に短縮されました。年間100人分以上のフルタイム担当者（FTE）の工数を削減し、大幅なコスト削減と運営効率の向上を実現しています。 プレゼンテーションはこちら ライフサイエンスの新時代の到来 生成AIとAIエージェントが可能性を再形成し続ける中、ライフサイエンスのイノベーションの新時代が確実に到来しています。 組織が実験段階を超えて実世界での本格展開へと移行する中、長期的な成功の鍵は技術だけではありません—それは 人材、プロセス、データの融合 にあります。創薬研究、臨床開発、製造、コマーシャルのいずれの分野でイノベーションを推進する場合でも、AWSは効果的な取り組みの規模拡大を支援し、次のステップに向けて確実に前進できるようサポートします。 AWS担当者に今すぐ連絡 して、 世界のトップ10製薬企業のうち9社が生成AIと機械学習にAWSを選択している 理由をご確認ください。未来は今日から始まっています—共に創造していきましょう。 参考資料 第7回AWS Life Sciences Symposium： 基調講演のハイライト | 基調講演のダイジェスト動画を視聴する ライフサイエンスのイノベーションをAWSのAIエージェントで加速 創薬研究セッションのハイライト – 第7回 AWS ライフサイエンス シンポジウム 臨床開発セッションのハイライト – 第7回 AWS ライフサイエンス シンポジウム コマーシャルセッションのハイライト – 第7回 AWS ライフサイエンス シンポジウム Oiendrilla Das Oiendrilla Dasは、AWSのライフサイエンスおよびゲノミクスマーケティングのカスタマーアドボカシーリードです。ライフサイエンスマーケティングのバックグラウンドを持ち、ライフサイエンスとクラウドコンピューティングを専門としています。マーケティングのMBA学位を取得し、MBA取得前にバイオテクノロジーの工学を修了しています。 このブログは、Senior Solutions Architectの松永が翻訳しました。

このブログは、 “ Highlights from the 2025 AWS Life Sciences Symposium’s Commercialization track ” の翻訳です。 5月6日、 400以上の組織 から 1,000人以上 のライフサイエンスのリーダーたちがニューヨーク市に集まり、第7回 AWS ライフサイエンスシンポジウム が開催されました。「 ブレークスルーの構築 – 製薬バリューチェーンを変革するAI駆動型イノベーション 」をテーマに、生成AIがどのようにしてハイプを超え、製薬業界の実用的な変革の触媒となったかを紹介しました。39名の専門家が登壇した26のセッションを通じて、参加者たちは先進的なAIがイノベーションの加速、コスト削減、そしてコンプライアンスの大規模なサポートにおいて、どのように測定可能なインパクトを生み出しているかを探求しました。（基調講演の 動画 と ハイライト はこちら） コマーシャルトラックでは、業界のリーダーたちが製薬業界の最も緊急かつ複雑な商業的課題に対してAIがどのように適用されているかについて議論し、その実際の影響が明らかになりました。 製薬の営業活動の岐路：新しいプレイブックの必要性 製薬業界の営業活動は現在、大きな転換期を迎えています。各企業は営業・マーケティング活動に多額の投資を行っているものの、複雑化する医療業界において、その投資に見合う成果を上げることに苦戦しています。実際、医師の半数は営業担当者との面会機会がなく、面会できる医師でも、勤務時間内での接点は平均1.4回程度に限られています。さらに、2031年までに830を超える新薬が市場に出てくると予測されており、競争は一層激しさを増しています。このような状況の中、営業部門は他社との差別化と目標達成に向けて大きな課題を抱えています。 これらの課題は、業界を取り巻く環境の大きな変化によってさらに複雑になっています。保険制度の仕組みが変わり、規制が厳しくなり、医療提供体制が分散化し、患者からの要求も高まっています。特に医師からは、より質の高い臨床判断ができるよう、科学的根拠に基づいた、より適切な情報提供が求められています。さらに、営業部門、メディカル部門、マーケティング部門の連携が十分でないため、医師に届く情報に一貫性が欠け、それぞれの部門との関わりが断片的なものになってしまっています。 今日の組織が成功を収めるには、データを最大限に活用した包括的で先進的な事業運営が不可欠です。これは単なる従来型の業務のデジタル化ではなく、AIを駆使した全く新しい運営方式への転換を意味します。この新しい運営方式では、地域ごとの特徴、健康に関わる社会環境、地域特有の市場状況といった多様な要因を分析します。そしてその分析に基づいて、医師や患者一人一人の行動パターンを深く理解し、それぞれに最適な対応を効率的に提供していきます。このような変革を実現するためには、最新のデータ基盤やクラウド技術を導入するだけでなく、営業部門の仕事の進め方そのものを抜本的に改革する必要があります。 コマーシャルトラックでは、すでにこの飛躍を遂げている組織が、実際のユースケース、洞察、推奨事項を共有し、ビジョンを行動に移しました。以下が主要なポイントです。 Gilead：強力なデータ基盤に基づくAI駆動型の営業エクセレンス トラックは Gilead のG&amp;A、コマーシャルアナリティクス、クラウドのグローバルヘッドである Pradeep Yathira 氏と、 ZS のプリンシパルである Faiz Merchant 氏のセッションで幕を開けました。彼らは、接続された、コンプライアンスを遵守した、クラウドファーストのデータ戦略が、AI駆動型コマーシャライゼーションの基盤であることを共有しました。 Gileadは、これまでの分散したクラウド環境から移行を進め、現在では システムの60%をAWSで運用 しています。さらに2025年までには、その割合を90%まで引き上げることを目指しています。この変革の要となっているのが、AWS上に構築されたAIを活用した全社プラットフォームです。このプラットフォームは、データメッシュと呼ばれる設計手法を採用しており、ユーザー自身による分析、データ取り込みの標準的な仕組み、対話型AI、ディープラーニングまで、幅広い機能をサポートしています。この基盤により、データの全社的な活用促進、業務の自動化、柔軟な運営体制の構築、そして適切なデータ管理といった重要な経営課題の解決を進めています。この強固な基盤を整備したことで、Gileadは様々な分野でAI活用を推進しています。例えば、規制関連文書の審査プロセスの効率化、営業活動における最適なアプローチの提案、患者向けの警告システムなど、ビジネスの様々な場面でAIのPoCを行い、効果が確認されたものから本格的な展開を進めています。 特に大きな変革が見られるのは営業担当者の働き方です。これまでの受け身の手作業中心の業務から、AIを活用したスマートで先を見据えた顧客対応へと進化しています。AIアシスタントは、営業担当者に対して有益な情報を提供し、次の行動を提案します。また、規制対応やプロモーション活動における法令順守も、わずか数回のクリックで確認できます。これにより営業担当者は、定められたガイドラインの範囲内で、医師との価値ある関係づくりにより多くの時間を費やすことができるようになっています。企業の販売費および一般管理費（SG&amp;A）の30～50%が営業現場に関連する支出であることを考えると、この業務改善は企業の業績に直接的な好影響をもたらします。 スマートなチャットボットを活用した顧客対応、AIによるコンテンツの自動作成、そして医療・法務審査の効率化まで、AIを活用したこの新しい営業アプローチは、基礎となる仕組みづくりへの強い取り組みを表しています。彼らの経験から得られた最も重要な教訓は、AIの成功には単に新しいツールを導入すればよいのではなく、整理された、つながりのある、適切に管理されたデータを最初から用意することが不可欠だということです。 プレゼンテーションはこちら Johnson &amp; Johnson：静的な計画から動的なパーソナライゼーションへ Johnson &amp; Johnson Innovative Medicine のコマーシャルオペレーション、データ＆アナリティクスのテクノロジー＆プロダクトグループリーダーである Dharmesh Thakkar 氏と、データ＆インサイトのITディレクターである Shyam Mohapatra 氏が主導したセッションでは、 製薬マーケティングにおける大規模なパーソナライゼーション に関する議論を深めました。 Johnson &amp; Johnsonの製品ポートフォリオが今後3年間で進化する中、同社は患者、医療提供者、ステークホルダーの変化するニーズに応えるため、コマーシャル戦略を積極的に再構築しています。同社のアプローチの中核にあるのは、大規模なインサイト生成を可能にするように設計された包括的なデータ戦略です。 その中心となるのは、AWSに構築された セルフサービスデータマーケットプレイス で、ビジネスドメイン全体の高品質で分析準備の整ったデータを統合し、直感的なローコードまたはノーコードインターフェースを通じてユーザーに提供します。このプラットフォームは、ブランドやアカウント全体でアクショナブルなインサイトを提供する単一の情報源として機能します。また、強力なガバナンス、データの系統、コンプライアンスを確保しながら、チーム間でのデータの再利用性を促進します。 結果は印象的です：立ち上げ時間の50%削減、自動化による18-20時間の節約、そして分析効率の2倍向上。この変化は、画一的な戦略から適応的でデータに基づく計画立案への移行を示しており、チームが今日の市場の複雑さに対応し、明日のイノベーションに備えることを可能にしています。 プレゼンテーションはこちら EVERSANA：生成AIによるMLRの加速 基盤となるデータは不可欠ですが、スピードも同様に重要です。特にマーケティングコンテンツの運用において。しかし、新しいコンテンツ生成のための医療、法務、規制（MLR）レビュープロセスは、各アセットに24-45日かかる最も持続的なボトルネックの一つであり続けています。 EVERSANA のチーフイノベーションオフィサーである Faruk Capan 氏と、シニアVPの Abid Rahman 氏は、この課題に正面から取り組み、 MLRワークフローを合理化し加速する ために特別に構築されたAI駆動型ソリューション、 EVERSANA ORCHESTRATE MLR を発表しました。 AWSに構築 され（ Amazon Bedrock 、 Amazon Cognito 、 Amazon Textract などのサービスを使用）、 Veeva と統合されたこのプラットフォームは、生成AIを使用してメッセージの抽出、相互参照、注釈付け、メッセージマッチングを自動化します。人間によるレビューを組み込むことで規制の正確性を確保しながら、レビュー時間を週単位から日単位へと大幅に短縮します。 AWS Marketplaceで提供されているORCHESTRATE MLRは、営業部門が規制に準拠したコンテンツを素早く作成し、マーケティングキャンペーンのスピードを上げながら、コンプライアンス上のリスクを抑えることができるツールです。また、AIを活用した審査プロセスにより、個々の顧客に合わせたコンテンツの作成や、コンテンツの部品化を効率的に行うことができます。これは、AIによる業務の自動化が製薬業界での競争優位性につながる好例であり、めまぐるしく変化する市場において、顧客とのより良いコミュニケーションと迅速な対応を可能にしています。 Lilly：一次データによる患者エンゲージメントの再構築 HCPを超えて、患者もまた、生活の他の分野（小売、銀行、ストリーミングサービスなど）で受けているのと同様の、よりシームレスでパーソナライズされた体験を求めています。これらの期待に応えるには、優れた製品以上のものが必要です。製薬企業が医療の旅全体を通じて患者とどのように関わるかについての完全な再考が必要です。 Lilly は、グローバルVPの Steve Rommeney 氏が発表したように、患者の同意とプライバシーを中心に据えた 一次データエコシステム を構築することで対応しており、肥満治療ポートフォリオなどの対象治療領域で注目すべき実装を行っています。患者から直接データを責任を持って収集し活用することで、Lillyは 患者体験を再形成 し、従来のキャンペーンを超えて、アドヒアランスをサポートし、結果を改善し、信頼を構築する関連性の高い、タイムリーで意味のあるインタラクションを提供しています。 このクラウドベースのデータプラットフォームは、 Red Hat OpenShiftサービス を使用してAWS上に構築され、基盤からガバナンス、プライバシー、権限管理を組み込んでいます。アーキテクチャには、統合された同意機能、クロスドメイントラッキング、広告抑制メカニズム、クロスプラットフォーム認証など、大規模でコンプライアンスを遵守したパーソナライズされた体験を提供するために不可欠な主要な構成要素が組み込まれています。 フロントエンドでは、この統合されたデジタルプラットフォームがLilly.comと LillyDirect 全体で患者向けの体験を提供し、調査やブラウジングから、フルフィルメント、オンボーディング、継続的なサポートまでをカバーしています。バックエンドでは、中央集中型の運営とリアルタイム分析により、Lillyはチャネル全体でのエンゲージメントを合理化し、サービス提供を改善し、関連性とインパクトを継続的に最適化することができます。 Lillyのアプローチは、異なる治療領域には異なるエンゲージメントモデルが必要であることを認識しており、彼らの対象を絞ったイニシアチブは、一次データが適切に実装された場合に患者の旅をどのように変革できるかを示す実証の場として機能しています。これはデジタルアップグレード以上のもの、つまり患者エンゲージメントの戦略的な再構築です。 プレゼンテーションはこちら Salesforce：人間とAIエージェントの能力の組み合わせ コマーシャルトラックの締めくくりとして、AWSパートナーである Salesforce のライフサイエンスクラウド戦略VPの Tara Helm 氏が、 Salesforce Life Sciences Cloud が製薬企業の顧客がバリューチェーン全体にAIを組み込むのをどのように支援しているかを紹介しました。その中核にあるのは、HCPのインタラクション、処方データ、電子カルテ（EHR）などの多様なソースからのデータを統合し、患者サービス、医療業務、営業全体でリアルタイムのエンゲージメントを促進する動的でアクショナブルなプロファイルを作成する強力なデータエンジンです。重要なワークフローにAIを統合することで、このプラットフォームは患者と医療提供者のインタラクションを合理化し、コンプライアンスを簡素化し、運用の俊敏性を向上させるのに役立ちます。 このビジョンの中心にあるのは Agentforce for Life Sciences で、これは AIエージェント と人間の専門知識を組み合わせて管理業務の負担を軽減するシステムです。強力な例：営業担当者の事前コール計画です。Agentforceを使用することで、営業担当者は医療提供者との面談の準備に12-15のツールを使用する必要がなくなりました。代わりに、AIによってキュレーションされたインサイトを受け取り、価値を付加する活動と高いインパクトのあるエンゲージメントに集中できます。 SalesforceとAWSの戦略的パートナーシップは、これらのイノベーションのための強固な技術基盤を作り出しています。これには、企業の情報をAI対応にするデータ変換ソリューションや、エンタープライズグレードのガバナンスで責任あるAI使用を確保しながら、基盤モデルを安全にデプロイするためのAmazon Bedrockとの統合が含まれます。その影響は、製薬企業の顧客は、すべてを一から構築する必要なく、商業的変革のための生成AIソリューションを自信を持って責任を持ってデプロイできます。 プレゼンテーションはこちら コマーシャライゼーションの再構築—生成AI、戦略、スピードを活用して 企業を取り巻く関係者の範囲は現場のチームだけでは対応しきれないほど広がっています。また、科学的な情報が急増し、法令順守の要求も厳しさを増しています。このような状況の中で、一つのことが明確になってきました。それは、個々の相手に合わせた対応を大規模に展開することが、もはや選択肢の一つではなく、ビジネスを進める上で欠かせないものになったということです。さらに、データを活用した他社との差別化された顧客体験の提供は、単なる競争優位性を超えて、ビジネスを継続していく上での必須条件となっています。 ライフサイエンス業界をリードする企業は、営業活動の方法、コミュニケーションの取り方、価値の生み出し方を根本から見直しています。これらの企業は、この見直しを全社的な変革の原動力として捉え、データ基盤、業務運営、顧客とのやり取りの方法を同時に再検討しています。その結果、目に見える成果が表れています。新製品の市場投入が早くなり、コストが削減され、より深い洞察が得られるようになっています。さらに、医療従事者や患者との関係がより強固になるなど、データを活用した新しいアプローチが、ビジネスの様々な面で具体的な改善をもたらしています。 AWSは、お客様のビジネスの発展とスピードアップをサポートしています。AIを活用したコンテンツの自動作成、学会発表や研究論文からの重要な知見の発見、さらには規制対応の業務プロセス改革など、様々な場面でお客様の課題解決を支援します。 そのため、 世界のトップ10製薬企業のうち9社が生成AIと機械学習にAWSを使用しています。 AWS担当者に今すぐ連絡 して、組織の商業的変革を加速する方法をご相談ください。 参考資料 第7回AWS Life Sciences Symposium： 基調講演のハイライト | 基調講演のダイジェスト動画を視聴する ライフサイエンスのイノベーションをAWSのAIエージェントで加速 創薬研究セッションのハイライト – 第7回 AWS ライフサイエンス シンポジウム 臨床開発セッションのハイライト – 第7回 AWS ライフサイエンス シンポジウム 製造セッションのハイライト – 第7回 AWS ライフサイエンス シンポジウム Oiendrilla Das Oiendrilla Dasは、AWSのライフサイエンスおよびゲノミクスマーケティングのカスタマーアドボカシーリードです。ライフサイエンスマーケティングのバックグラウンドを持ち、ライフサイエンスとクラウドコンピューティングを専門としています。マーケティングのMBA学位を取得し、MBA取得前にバイオテクノロジーの工学を修了しています。 このブログは、Senior Solutions Architectの松永が翻訳しました。

本記事は自治体向け標準 20 業務システムを展開する株式会社大崎コンピュータエンヂニアリング（以下 OCE と記載）の第 1 営業統括部 第 2 公共営業部 西口大輔氏、インフラ統括部 データセンター運用部 久保田亨氏から寄稿いただいたものです。 背景 OCE では 2024 年より自治体様のガバメントクラウド導入案件におきまして、ネットワーク構築管理補助環境およびデータ連携基盤環境（以下ネットワークアカウントと記載）の設計・構築を実施しております。令和7年度より本番システムが順次稼働しガバメントクラウド運用管理補助業務が開始しますが、限られた人数で複数自治体様環境の運用管理補助業務を実施するため、業務効率化が必須となっています。そのため、運用管理補助業務の一部を補完する仕組みとして、生成 AI の導入を検討しました。 導入ツール セキュリティについては、問題を未然に防止する「予防的統制」と発生した問題を検出する「発見的統制」といった考え方があります。ガバメントクラウドでは、 AWS Security Hub 、 Amazon GuardDuty 、 AWS Control Tower 、 AWS Config などのサービスを使用し、発見的統制を実現していますが、これらの設定の多くはデジタル庁様から提供される必須適用テンプレートの適用により、実装がされます。これら設定されたセキュリティ関連のアラートや操作ログに関連する運用効率化のため「アラート要約機能」「ログ要約機能」といった生成 AI を活用した2つのツールの開発を行いました。 アラート要約機能 ガバメントクラウド環境において、必須適用テンプレートで設定されるアラートの要約機能を提供します。必須適用テンプレートで設定されるアラートをメールで受信する際、整形処理等が含まれていないため、運用管理補助者が即座に内容を把握することが困難です。アラート要約機能は Amazon Bedrock を使用することによりこれらのアラートを要約、整形、さらに対応手順を追加した上でアラートを送付する機能を提供します。 アラート要約機能導入前は CloudWatch Alarm や Amazon EventBridge から Amazon SNS 経由で各種セキュリティ関連アラートがメール通知されます。（下図点線箇所）。アラート要約機能導入後は AWS Lambda 、 Amazon Bedrock を使用してアラート要約後、 Amazon SNS 経由でメール通知を行う流れとなります。（下図オレンジ線箇所） Amazon Bedrock はガバメントクラウド外の事業者側アカウントに準備を行い、ガバメントクラウド上のアカウントからクロスアカウントアクセスで通信するような構成になります。 ログ要約機能 ガバメントクラウド環境において、必須適用テンプレートで設定されるログの要約機能を提供します。必須適用テンプレートの適用により、AWS アカウント内の操作ログが取得されますが大量のログから特定の操作を抽出することは AWS に精通したエンジニアでなければ困難です。ログ要約機能は Amazon Bedrock を使用することにより該当期間内のログ要約後、確認すべきログを抽出しメール送付を行います。 CloudWatch ダッシュボードに Lambda 関数を CloudWatch ダッシュボードのウィジット として追加することでユーザインタフェースを提供します。ここから対象期間やキーワードを入力することで、CloudWatch Logs 上の AWS CloudTrail ログを取得後、Amazon Bedrock を使用してログを要約して要約結果を出力する仕組みとなります。CloudWatch ダッシュボードのウィジットへの結果出力と同時に、要約結果は Amazon S3 バケットに保存、署名付き URL を発行後、 Amazon SNS を使用して運用管理補助者にメール通知を行います。ログ要約結果とあわせて、実際のログ確認用の CloudWatch Logs Insights のクエリも発行されるため、運用管理補助者は要約結果に加え、実際の AWS CloudTrail のログを確認することが可能です。 ガバメントクラウド外の⽣成 AI を利用する方法 ガバメントクラウド環境から事業者が用意した AWS アカウントの Amazon Bedrock を利用する構成となっています。 自治体様・デジタル庁様・AWS 様と協議を実施し上記の構成としました。 PoC 評価手法 事前に運用に関する評価指標の定義を行い PoC 実施前、実施中の値を比較することにより生成 AI ツール導入による運用管理補助業務の効率化度合いの測定を行いました。 弊社では下記 2 つのグループでガバメントクラウドの運用管理補助業務を行っております。 監視 Gr：インシデント受付、記録、エスカレーションを担当 運用 Gr：インシデント調査・対応を担当 現状、監視 Gr は判断を行わず、全てのインシデントを運用 Gr にエスカレーションするフローとなっていましたが、PoC 実施中は監視 Gr でアラート判断のフローを追加しました。 生成 AI ツール導入による効果測定の指標としては「監視 Gr での一時対応率」「運用 Gr での確認・判断時間の短縮」を定義しました。 PoC実施前、実施時の各評価指標の測定結果は下記になります。 指標 PoC 実施前 PoC 実施中 監視Gr：一時対応率 0 % 84.6 % 運用Gr：判断時間/件 27.5 分 8.3 分 監視 Gr ではアラート要約機能と過去のインシデント履歴の活用により、ほとんどのアラート内容を判断することが可能となりました。監視 Gr での一時対応率は 84.6 % となり生成 AI ツール導入により、監視 Gr の対応可能範囲が拡大しました。 また、運用Grでは１件当たりの判断時間が 8.3 分となり、実施前と比較すると 19 分程度の短縮となりました。認証関連や変更に関するアラートが発生した際は、これまで複数人でログの確認を実施しておりました。アラート活用機能に加えログ要約ツールの活用により、内容把握から他者への情報共有までスムーズに行うことが可能となり、判断時間の短縮に繋がりました。 工夫した点 ログ要約において、 CloudWatchダッシュボードのウィジット を使用してユーザインタフェースを実装した点です。このアーキテクチャは AWS のマネジメントコンソール内のみで完結可能な仕組みとなっております。これにより、ガバメントクラウドのように、運用管理端末からインターネットへの通信にドメインフィルタリングなどの制約がある場合や、運用管理端末にチャットアプリなどのアプリケーションを入れることができない場合でも、ツールを利用することが可能になります。 Why AWS ？ OCEでは既に複数の自治体様のガバメントクラウド環境をAWSで構築中の段階です。 Amazon Bedrock を含む AWS サービスは ISMAP などの政府認証を取得しており (注釈1) 、ガバメントクラウドの AWS 環境からシームレスに利用できるため、自治体様にも安心してサービスを提供することができます。そのため、利用する生成 AI のサービスとしては Amazon Bedrock が最適だと考えました。 今後の展望について 生成 AI ツールの活用により、運用管理補助業務の大きな効率化に繋がりました。本 PoC は一つの自治体様環境で実施しましたが、今後の運用フェーズでは複数自治体様環境の運用管理補助業務を行います。本番運用開始後も生成 AI ツール導入によりさらなる効果が期待出来ると考えております。 注釈1: AWSの「政府情報システムのためのセキュリティ評価制度（ISMAP）」登録が更新されました。(2024年度） | Amazon Web Services ブログ 著者について 写真左: 久保田様　写真右: 西口様 西口 大輔 1999年4月に入社以来、公共部門に在籍し、地方自治体営業を担当。 業務システムからインフラの導入提案まで幅広く経験し、2014年頃からは、インフラ関連を中心に取り組み自治体情報セキュリティ強靭化などの案件を担当。現在は第2公共営業部のリーダーとしてインフラビジネスを推進。 久保田 亨 以前はオンプレミス環境におけるインフラエンジニアとして勤務しておりましたが、現在は主にクラウド関連業務に従事しております。自治体標準化の分野では、ガバメントクラウドにおけるネットワークアカウントや共通基盤の設計・構築を担当しております。

こんにちは。ソリューションアーキテクト（以下 SA）の辻です。 現在注目されているAI Agentの可能性をご認識いただき参加者の皆様で一緒にユースケースのアイディア出しを行うことを目的に、2025年5月29日に「九州ローカルミーティング AI Agent ワークショップ」と題したイベントを開催しました。本 Blog ではイベントの概要の紹介と、イベント内で登壇者が発表に使用した資料を公開いたします。 本イベントは、SA 中島佑樹による座学「AI Agent を始める前のチェックリスト」をご提供した後、お客様5名1チームに分かれていただき「AI Agent ワークショップ」を実施しました。 本イベントには13社25名のお客様にご参加いただきました。2時間半にわたるイベントで、すべてのお客様が自社の課題を解決するための AI Agent を利用したユースケースを発掘し、持ち帰っていただく結果となっています。以下に公開する資料を用いて、ぜひ本Blogをお読みの皆様も AI Agent のユースケースを発掘して下さい！ セッションの紹介 AI Agent を始める前のチェックリスト 資料： https://speakerdeck.com/icoxfog417/how-to-start-ai-agent-project-on-aws AI Agent をこよなく愛する SA 中島佑樹より「AI Agent を始める前のチェックリスト」と題して、AI エージェント登場の背景と昨今の動向や、AWS 上での事例も交えて持続的に AI エージェント活用を進める方法論についてご紹介しました。また当日は Starands Agents を用いて Amazon DynamoDB からデータを取得するための Model Context Protocol (MCP) サーバーと連携して、Streamlit で構成されたアプリケーションからチャットで商品情報を取得するデモも実施しました。こちらのアプリケーションは Bedrock Engineer を用いて実装したとのことで、お客様から非常に良い反応をいただいておりました。 AI Agent ワークショップ 現状の課題を仮設しながら生成 AI と連携するツールやデータを描くことで生成 AI 活用のアイデアをお持ち帰りいただくことを目的に、AI Agent ワークショップを提供しました。 まずは参加者の皆様に、AI エージェントと連携するデータ・ツールを洗い出し、エージェントに期待する動作フローを図に書いていただく練習問題に取り組んでいただきました。 AI エージェントの実装になぜフロー図の記載が必要なのか？と疑問を持たれた方もいらっしゃるかもしれません。しかし、AI エージェントであっても人間が想定できない動作は実現することはできないと考えた方がよいため、期待する動作フローを考えることは AI エージェントを利用して課題を解決させるために非常に重要と言えます。 練習問題の解答例は上記となります。 次に、以下の白紙の記入シートを使って、お客様に個人ワークとしてお客様の課題に合わせ AI エージェントの活用を考えていただきました。 こちらの記入シートは Miro にてテンプレートを提供 しておりますので、ぜひ皆様もご利用ください。 時間は 30 分と短い間でしたが、すべての参加者の方が記入シートにに内容を書き切ることができていました。個人ワークが終了した後は5名1チームとなりそれぞれご自身で考案した AI エージェントのアイデアをチーム内で共有して頂きました。チーム内でのディスカッションも活発に行われ、ユニークで具体的なアイディアが多数発表されていました。 まとめ 本イベントでは、AI Agent にフォーカスし、自社の課題を解決するための AI Agent を利用したユースケースを発掘していただくことを目的にワークショップを提供しました。 AWS では AI Agent を実現するにあたり、今回のような企画段階のご支援を含めさまざまなサービスをご用意しています。以下に筆者がおすすめのリソースリンクを貼り付けておきますので、ぜひご参照いただければと思います。 Amazon Bedrock Agents Amazon Bedrock Agents 自律型 AI の実現に向けて: 検討編 Amazon Bedrock Agents 自律型 AI の実現に向けて: 動作理解編 Amazon Bedrock Agents 自律型 AI の実現に向けて: 開発・運用編 Amazon Q Developer より豊かなコンテキストのための Model Context Protocol (MCP) による Amazon Q Developer CLI の拡張 生成 AI で生成 AI アプリケーションを生成しよう！ Strands Agents Strands Agents – オープンソース AI エージェント SDK の紹介 アマゾン ウェブ サービス ジャパン 合同会社 ソリューションアーキテクト 辻 浩季

この記事は Automating AI-assisted container deployments with the Amazon ECS MCP Server (記事公開日 : 2025 年 5 月 29 日) の翻訳です。 導入 アプリケーションのコンテナ化は、モダンなクラウドデプロイメントの標準として、一貫した環境と効率的な依存関係管理、シームレスなスケーリングを提供します。しかし、コンテナ化とデプロイメントのプロセスは依然として手動で時間がかかります。多くの場合、開発者は Dockerfile の作成やネットワークの設定、コンピューティングリソースの割り当て、デプロイメントパイプラインの管理を行う必要があります。これにより、経験豊富な開発者でさえ、 Amazon Q Developer などの人工知能 (AI) アシスタントを用いて効率化できるはずの繰り返しのタスクに時間を取られています。 この課題を解決するために、AWS は Amazon Elastic Container Service (Amazon ECS) アプリケーション構築のための Model Context Protocol (MCP) サーバーを発表しました。これは AWS MCP Servers の新たな一員として、AI 支援開発と本番環境に対応した Amazon ECS デプロイメントベストプラクティスの間のギャップを解消します。 Amazon ECS MCP Server を使用することで、Amazon Q Developer などの AI アシスタントは AWS Fargate と Application Load Balancer (ALB) を活用しながら、アプリケーションを自動的にコンテナ化して、Amazon ECS へのデプロイメントを管理できるようになります。この記事では Amazon Q Developer に焦点を当てていますが、この MCP サーバーは MCP プロトコルをサポートするあらゆる AI エージェントやクライアントと連携するように設計されています。 これは Amazon ECS MCP Server の最初のバージョンであり、その歩みを始めたばかりです。時間をかけて、より多くのベストプラクティスとより幅広い機能で、その能力を拡張していく予定です。 概要 Amazon ECS MCP Server は、AWS でコンテナアプリケーションを管理するための堅牢なツールキットを提供します。その機能は、開発、デプロイメント、運用、トラブルシューティング、廃止まで、アプリケーションライフサイクル全体をカバーする以下のカテゴリを中心に構築されています。最初のバージョンの Amazon ECS MCP Server では、アプリケーションの分析やコンテナ化、クラウドデプロイメント、モニタリング、メンテナンスを支援するいくつかの ツール (MCP サーバーの構成要素) を提供します。 開発ツール は、アプリケーションコードを分析して言語やフレームワークを検出し、適切なベースイメージと依存関係を持つ最適化された Dockerfile を作成するためのガイダンスを提供します。これには、効率的なコンテナ化のためのマルチステージビルドやレイヤー最適化が含まれます。 デプロイメントツール は、 AWS CloudFormation を使用して Amazon ECS 環境をプロビジョニングします。これらのツールはリソースの依存関係を処理し、最小権限の AWS Identity and Access Management (AWS IAM) ポリシーを設定し、 AWS Software Development Kit (AWS SDK) を用いてポーリングすることでデプロイメントを監視します。 トラブルシューティングツール には、Amazon ECS の各コンポーネント向けの特別なアナライザーが含まれています。これらのツールは、ログパターン認識、イベントストリーム分析、障害パターン検出、およびガイド付き診断のための決定木エンジンといった機能を持ちます。 運用ツール は、クラスター、サービス、タスク、タスク定義などの Amazon ECS リソースを一覧表示および記述するための読み取り専用インターフェースを提供します。これらは自然言語によるフィルタリングオプションをサポートし、Amazon ECS インフラストラクチャに関する詳細な情報を提供します。 廃止ツール は、依存関係を考慮した削除の順序付けと削除前の検証を実施します。これらのツールは、命名パターンに基づいてスタックを識別し、リソースを包括的に追跡し、コンポーネントの削除漏れを防止します。 この MCP サーバーのアーキテクチャは、セキュリティと運用のベストプラクティスを維持しながら、デプロイメントとトラブルシューティングの手間を最小化するように設計されています。AWS SDK を通じて AWS サービスと直接連携し、インフラストラクチャのプロビジョニングに AWS CloudFormation を使用することで、異なる環境間で一貫性のある再現可能なデプロイメントを実現します。 Amazon ECS MCP Server で利用可能なツール Amazon ECS MCP Server には、コンテナアプリケーションの開発と運用をサポートするための以下のツールが含まれます。 ツール名 タイプ 用途 containerize_app 開発 Dockerfile 作成のガイダンスを提供 create_ecs_infrastructure デプロイメント AWS CloudFormation を使用して Amazon ECS インフラストラクチャをプロビジョニング get_deployment_status デプロイメント デプロイメントステータスを監視 ecs_resource_management 運用 リソースインベントリを管理 ecs_troubleshooting_tool トラブルシューティング Amazon ECS サービスおよびタスクに関する問題を診断 delete_ecs_infrastructure 廃止 リソースのクリーンアップを支援 ウォークスルー Amazon Q Developer では、 mcp.json ファイルを使用して MCP サーバーを設定します。このファイルは、グローバルで使用するためにホームディレクトリ ( ~/.aws/amazonq/mcp.json ) に保存するか、チーム全体で共有するためにワークスペースのルート ( .amazonq/mcp.json ) に保存することができます。Amazon Q Developer における MCP サーバーの詳細な設定手順については、 このブログ記事 を参照してください。Amazon ECS MCP Server の設定例は こちら から確認できます。 設定が完了したら、ターミナルで q chat コマンドを実行して Amazon Q Developer CLI の新しいセッションを開始しましょう。以下のように /tools コマンドを実行することで、利用可能なツールの一覧を確認できます。 図 1. Amazon Q Developer CLI で利用可能なツールを表示する例 AI の支援によって、Amazon ECS リソースの管理は自然言語で質問するだけのシンプルなものとなります。“How do I deploy my app to AWS?” (このディレクトリにあるアプリを AWS にデプロイしてください) と尋ねると、Amazon Q Developer はそれをデプロイメントリクエストとして解釈します。Amazon ECS MCP Server の分析機能を呼び出し、一連のツールを実行してアプリケーションをコンテナ化し、Amazon ECS にデプロイします。次のセクションでは、関連するツールと、これらのツールがコンテナワークロードのライフサイクル全体をどのように効率化するかを確認します。 (訳註: 実際にAWS 上にリソースを作成したい場合は、MCP サーバーの環境変数 ALLOW_WRITE を true に設定する必要があります。また、Amazon Q Developer から情報を求められた場合は、対話形式で追加の指示を入力することができます。) 開発およびデプロイメントツール containerize_app ツールは、アプリケーションのソースコードをスキャンしながら、“Analyzing application structure…” (アプリケーションの構造を分析中…) や “Creating Docker file…” (Dockerfile を作成中…) といったメッセージで進捗状況を通知します。また、ローカルでアプリケーションを開発およびデバッグするのに役立つ Docker Compose ファイル も作成します。“What runtime version was detected?” (検出されたランタイムバージョンは何ですか？) や “Show me the planned container configuration” (計画しているコンテナの設定を表示して) といったフォローアップの質問を投げかけることもできます。 図 2. Amazon Q Developer がツールを使用してアプリケーションをコンテナ化する様子 その後、Amazon Q Developer は create_ecs_infrastructure ツールを呼び出し、コンテナ化されたアプリケーションを Amazon ECS に自動的にデプロイします。このツールは、 Amazon Virtual Private Cloud (Amazon VPC)、サブネット、セキュリティグループ、IAM ロールおよびポリシーなどの必要な AWS インフラストラクチャをプロビジョニングします。さらに、ECS クラスターやタスク定義、サービス、ALB をセットアップし、外部からのトラフィックを受信できるようにします。すべてのリソースは CloudFormation テンプレートを使用して作成されます。また、Amazon Q Developer に対するプロンプトでパラメータを指定することで、デプロイメントをカスタマイズできます。例えば、VPC とサブネットの設定、CPU とメモリの割り当て、タスク数、オートスケーリングオプション、コンテナポート、環境変数、ヘルスチェックパスなどを指定することができます。 図 3. Amazon Q Developer がツールを使用して Amazon ECS インフラストラクチャを作成・デプロイする様子 また、“How’s my deployment going?” (デプロイメントの進行状況を教えて) のようなプロンプトを入力することで、デプロイメントの進行状況を追跡できます。裏側では、Amazon Q Developer が get_deployment_status ツールを呼び出して、Amazon ECS におけるデプロイメントをリアルタイムで監視します。デプロイメントが完了すると、Amazon Q Developer は基本的なヘルスメトリクスとともにアプリケーション URL を表示します。アップデートの際は、“Update my React app” (React アプリケーションをアップデートして) などの指示や “How is my application performing?” (アプリケーションの動作状況はどうですか？) などの質問を使用できます。Amazon Q Developer の自然言語インターフェースと Amazon ECS MCP Server を用いた自動化によって、Amazon ECS におけるデプロイメントの管理は、専門の DevOps エンジニアとチャットするのと同じくらい直感的になります。 以下のシーケンス図は、これらのコンポーネントがどのように相互作用するかを示しています。 図 4. Amazon ECS インフラストラクチャのコンテナ化、デプロイメント、クリーンアップの流れ トラブルシューティングツール Amazon ECS 環境での問題の調査と解決を支援するために、Amazon ECS MCP Server には統合的な診断ツール ecs_troubleshooting_tool が含まれています。このツールは、インフラストラクチャのプロビジョニングからアプリケーションの動作まで、Amazon ECS インフラストラクチャの様々なレイヤーに可視性をもたらすいくつかのアクションを提供します。このツールでできることは以下の通りです。 トラブルシューティングのためのガイダンスの取得 : まずは大まかなレベルの評価から始めます。このアクションは Amazon ECS 環境を評価し、デプロイメントの状態に基づいてトラブルシューティングのためのガイド付きの計画を提案します。 CloudFormation スタックの分析 : CloudFormation スタックの失敗したリソースやエラーメッセージを確認し、インフラストラクチャレベルの問題を詳しく調査します。 サービスイベントの調査 : Amazon ECS サービスイベントを確認して、アプリケーションに影響を与えるサービスレベルの設定ミスや障害を特定します。 タスクの失敗の診断 : リソースの制約やアプリケーションエラーなど、失敗したタスクのパターンを特定し、信頼性とパフォーマンスを向上させます。 運用ツール Amazon ECS 環境の調査と理解を支援するため、Amazon ECS MCP Server には読み取り専用ツール ecs_resource_management が含まれています。このツールは Amazon ECS インフラストラクチャの一元的なビューを提供し、カスタムスクリプトを作成したり AWS マネジメントコンソール にログインしたりすることなく、自然言語クエリを使用してリソースの構成を探索できるよう支援します。このツールでは、以下のことを実現できます。 Amazon ECS リソースの一覧表示 : ECS クラスター、サービス、タスク、タスク定義、コンテナインスタンス、キャパシティプロバイダーに関する情報を素早く取得します。 設定の詳細表示 : 起動タイプや希望するタスク数、サービスディスカバリーの設定、タスク定義など、Amazon ECS リソースの詳細なメタデータを取得します。 自然言語フィルターの使用 : “What services are running in cluster X?” (クラスター X で実行中のサービスは何ですか？) や “Show me tasks using container image Y” (コンテナイメージ Y を使用しているタスクを表示して) などの質問をすると、ツールがその内容を解釈して関連する結果を返します。 運用の可視性向上 : Amazon ECS リソース間の依存関係を理解し、インフラストラクチャが期待される構成になっていることを確認できます。 廃止ツール 環境をクリーンアップする準備ができたら、“Tear down my ECS stack.” (ECS スタックを削除して) と尋ねることができます。Amazon Q Developer は delete_ecs_infrastructure ツールを呼び出し、MCP を用いたワークフローを通じてプロビジョニングされたすべてのリソースを安全に削除します。依存関係が正しく処理され、コンポーネントの削除忘れがないようにすることで、廃止作業をクリーンで予測可能、かつリスクの低いものにします。 以上です！これで Amazon ECS アプリケーションの開発と運用のためのエンドツーエンドのサポートが整いました。これらのツールは、Amazon Q Developer および MCP プロトコルをサポートするすべての AI アシスタントと互換性があります。アプリケーションのコンテナ化やデプロイメントから、モニタリングとトラブルシューティングに至るまで、コンテナワークロードのライフサイクル全体をサポートします。 次のステップ AI アシスタントと Amazon ECS MCP Server を組み合わせて使用することによって、Amazon ECS におけるビルド、コンテナ化、デプロイメントに大きな変化がもたらされます。テンプレートのような設定を使用するのではなく、自然言語を使用して、コードの分析からインフラストラクチャのプロビジョニングまで、ワークフロー全体を効率化することができます。 私たちは今後も継続して機能を拡張し、既存のツールを改良していきます。機能の追加リクエストがある場合には、 AWS Containers Roadmap リポジトリ や AWS MCP Servers リポジトリ に Issue をお寄せください。 また、私たちはコンテナ管理におけるユーザーの多様なニーズをサポートするために、 Finch MCP Server を開発しました。 Finch は、コンテナをローカルでビルド、実行、管理するために設計されたオープンソースのクライアントサイドコンテナ開発ツールです。Finch MCP Server は、コンテナ操作に安全で一貫したインターフェースをもたらし、幅広いユーザー要件を満たす柔軟でエンタープライズ対応のソリューションに対する私たちのコミットメントを反映しています。 ここで紹介したツールは、ユーザーが開発に集中できるように設計されています。新しいプロジェクトを立ち上げる場合でも、既存のアプリケーションをコンテナに移行する場合でも、お使いの AI コーディングアシスタントと共に、そのプロセスをより速く、より楽なものにしてくれるでしょう。 まずは、ぜひ試してみてください！ 新しい Amazon Q Developer セッションを開始し、プロジェクトに接続して、“deploy my-app to Amazon ECS” (このアプリを Amazon ECS にデプロイしてください) といった指示を投げかけてみましょう。数分で、本番環境に対応したコンテナをデプロイできることを体験してみてください。 より詳しく学びたい場合は、 Amazon Q Developer ドキュメント を参照し、 Amazon ECS 開発者ガイド をご覧ください。

本ブログは 2025 年 6 月 2 日に公開された Blog “ A deep dive into data protection sessions at AWS re:Inforce 2025 ” を翻訳したものです。 カンファレンスパス全体の料金は $1,099 です。 今すぐ登録 して、コード flashsale150 を使用すると、数量限定で $150 の割引を受けられます。 訳注) 日本からご参加いただくお客様が利用できるカンファレンスパスのディスカウントコードをご用意しました。 コード JAPbHNlXWaI2 を利用することで 500 USD の割引 を受けることができます。数に限りがございますので、お早めにご登録ください！ Amazon Web Services (AWS) では、セキュリティが最優先事項です。AWS は、6 月 16 日から 18 日に開催される AWS re:Inforce 2025 での データ保護トラック をここで紹介できることをうれしく思います。このトラックでは、お客様が量子コンピューティング、AI、デジタル主権の時代にデータを保護しながら、AWS を活用して革新的な取り組みを生み出していく方法を探ります。今年のセッションでは、次世代の暗号技術、信頼できる AI、プライバシー強化技術、およびデータライフサイクル全体にわたる情報保護のための新たなベストプラクティスに関する革新的なアプローチに焦点を当てます。 データ保護トラックでは、AWS を初めて使用する方でも経験豊富なセキュリティプロフェッショナルでも、あらゆる規模の組織に対する洞察と実践的なガイダンスを提供します。規制コンプライアンス、国境を越えたデータ転送、マルチクラウド環境でのデータ保護など、今日の最も差し迫った課題に対応するセッションを慎重に選定しました。大規模な暗号化とデータ分類の実装に関するハンズオンワークショップから、最新の AWS データ保護サービスに関する詳細な技術セッションまで、堅牢なデータ保護戦略の構築と維持に役立つコンテンツをご用意しています。 このブログでは、実際のお客様のユースケースを含む講義形式のプレゼンテーションと、AWS の専門家が現場で直面する具体的な課題とその解決策をガイドするインタラクティブな少人数グループセッションを紹介します。今年のカンファレンスで期待できることを見ていきましょう。 データアクセスと管理 DAP471 | ワークショップ | Defend against ransomware with data defense, recovery, and response (データ防御、リカバリ、対応によるランサムウェア対策) ランサムウェアやマルウェアはビジネスアプリケーションを混乱させる可能性があります。このエキスパートレベルのワークショップでは、 AWS Backup のロックメカニズム、論理エアギャップボールト、復元テストを適用して、サイバーリカバリ体制を強化する方法を学びます。エアギャップ化された不変のボールトと自動化された復旧ポイントテストを実際に構成して、企業の目標を達成する経験を積みます。これらの機能を組み合わせて、進化するサイバー脅威に耐えうる包括的なリカバリ重視のデータ保護戦略を構築する方法を探ります。参加するにはラップトップを持参する必要があります。 暗号とポスト量子 DAP472 | ワークショップ | Examining hybrid post-quantum TLS key exchanges (ハイブリッドポスト量子 TLS 鍵交換の検証) このワークショップでは、ポスト量子暗号の実践的な探求を提供し、従来のアルゴリズムとのパフォーマンス比較と AWS サービスを使用した実世界での実装を示します。 AWS Key Management Service (AWS KMS) と AWS SDK for Java v2 を使用して量子安全なトンネルを確立し、安全なデータ転送のためのハイブリッドポスト量子 TLS を実装する方法を学びます。このセッションでは、ポスト量子鍵交換アルゴリズムの CPU およびバンド幅のパフォーマンスメトリクス、TLS ハンドシェイクプロトコルの変更、 AWS Transfer Family との統合など、重要な側面をカバーします。ハンズオンデモンストレーションでは、ハイブリッド古典/量子耐性アプローチを通じて、現在および将来の量子コンピューティングの脅威から機密通信を保護する方法を説明します。参加するにはラップトップを持参する必要があります。 DAP452 | ビルダーズセッション | Cryptographic controls with AWS CloudHSM (AWS CloudHSM による暗号制御) AWS CloudHSM を使用した強力な暗号制御の実装を実践的に体験します。Nginx での TLS オフロード、Windows コード署名の統合、カスタムキーストアの作成方法を学びます。FIPS 140-3 レベル 3 ハードウェアセキュリティモジュール (HSM) 内での暗号鍵の使用状況のモニタリングを、最新の高性能 hsm2m.medium HSM タイプを使用して探索します。このセッションでは、これらの進歩がセキュリティポスチャの強化、厳格なコンプライアンス要件の達成、運用管理の簡素化、アプリケーションが要求するパフォーマンスを維持しながら、成長するワークロードをサポートするための暗号操作のスケーリングにどのように役立つかを示します。参加するにはラップトップを持参する必要があります。 データ移行とモダナイゼーション DAP302 | ブレイクアウトセッション | Fannie Mae’s practical path to modern PKI and certificate management (Fannie Mae の実践的な最新 PKI と証明書管理への道のり) Fannie Mae のパブリックキーインフラストラクチャ (PKI) をレガシーシステムから AWS 上のクラウドネイティブソリューションへの変革を探ります。このセッションでは、分散型トラストストアの更新やアプリケーションチームからの賛同の確保などの課題に対処するフェーズド移行戦略について詳しく説明します。Fannie Mae がレガシー依存関係やコンプライアンス要件などの移行の障害をどのように克服し、セキュリティを維持しながら証明書関連のオーバーヘッドを削減して 100% の採用を達成したかを学びます。クラウドでのエンタープライズ規模の証明書管理のためのコスト最適化、リスク軽減、アーキテクチャのベストプラクティスについての洞察を得ましょう。このプレゼンテーションでは、同様の PKI モダナイゼーションの取り組みを行う組織のための実行可能な戦略を提供します。最後に、クラウドでのエンタープライズ規模の証明書管理における最新情報を共有します。 DAP322 | ライトニングトーク | How Monzo Bank protects critical workloads using AWS Nitro Enclaves (Monzo Bank が AWS Nitro Enclaves を使用して重要なワークロードを保護する方法) Monzo Bank は、コードの整合性、システム強化、限定されたアタックサーフェスに関して高レベルの保証を必要とするセキュリティ重要なアプリケーションをデプロイしています。彼らは、再現可能なビルドと AWS Nitro Enclaves が提供する暗号化アテステーションと分離されたコンピューティング環境を使用してこれを達成しました。このトークでは、このアプローチを使用した本番ワークロードの構築とデプロイで彼らが克服した課題と、その過程で学んだことを説明します。 AI のためのデータ保護 DAP201 | ブレイクアウトセッション | Veradigm’s security-first approach to amplifying potential with GenAI (Veradigm のセキュリティ重視アプローチによる生成 AI の可能性の拡大) 組織はどのようにして厳格なデータセキュリティ基準を責任を持って維持しながら、チームに生成 AI 機能を提供できるでしょうか？ Veradigm は当初、データプライバシー、セキュリティ、規制コンプライアンスの懸念から生成 AI の採用をためらっていました。Veradigm の社内 AI ソリューション主任開発者と共に、 Amazon Bedrock を使用してコンプライアンスに準拠した生成 AI アシスタントを構築・展開するための実用的なセキュリティ対策をどのように実装し、チームの能力を強化しながらセキュリティポスチャを強化したかを発見してください。厳しく規制された環境で働く従業員向けに AI を成功裏に実装するための重要なセキュリティコントロール、アーキテクチャの決定、貴重な教訓について学びましょう。 DAP332 | チョークトーク | Executive perspective: Risk management for generative AI workloads (エグゼクティブの視点：生成 AI ワークロードのリスク管理) 責任ある AI の認識された複雑さに惑わされず、AWS で生成 AI アプリケーションをデプロイしましょう。このチョークトークでは、AI の安全性とセキュリティリスクを分解するためのフレームワークを紹介し、ゼロトラスト原則を使用して生成 AI アプリケーションで企業データを安全に保つための AWS のベストプラクティスを紹介し、 Amazon Bedrock Guardrails などのテクノロジーを使用して安全性リスクを軽減します。他のセキュリティリーダーと共に、ワークロードに関連する安全性とセキュリティリスクを特定し、適切な緩和戦略を実装し、時間の経過とともに効果を測定する方法を発見しましょう。 DAP371 | ワークショップ | Defend your AI: Mitigate prompt injection with Amazon Bedrock (AI を守る：Amazon Bedrock でプロンプトインジェクションを緩和する) このハンズオンワークショップを通じて、生成 AI システムにおけるプロンプトインジェクションの脆弱性を特定し緩和する技術を習得しましょう。Amazon Bedrock を使用して、本番環境における大規模言語モデルのセキュリティへの影響を理解するために、攻撃的および防御的なプロンプトエンジニアリング技術の両方を探ります。このセッションでは、プロンプトインジェクション攻撃の仕組みを学び、シミュレートされた AI 環境を悪用しようとする対話型の キャプチャ・ザ・フラッグ スタイルのチャレンジを完了し、Amazon Bedrock Guardrails を使用して防御コントロールを実装する方法を学びます。参加するにはラップトップを持参する必要があります。 スケールでのデータ保護とコンプライアンス DAP331-R | チョークトーク | Architecting a secrets management strategy that scales (スケールするシークレット管理戦略の設計) クラウドネイティブ環境におけるエンタープライズシークレット管理のアーキテクチャパターンを深く掘り下げます。このセッションでは、集中型と分散型のシークレット管理の実装の複雑さを分析し、これらのパターン間のトレードオフについて議論します。これには開発者の速度、セキュリティ、運用オーバーヘッドへの影響が含まれます。AWS サービスを使用して、開発者とセキュリティチームのニーズのバランスを取る柔軟なシークレット管理戦略を実装し、シークレットのライフサイクルを管理する方法を学びます。また、選択したアーキテクチャに関係なく、集中型のコンプライアンスと監査のためのベストプラクティスもカバーします。 DAP202 | ブレイクアウトセッション | Navigating sovereignty requirements: Architectures and solutions on AWS (主権要件のナビゲーション：AWS 上のアーキテクチャとソリューション) 進化するデータ保護規制とデジタル主権要件により、組織はクラウド機能を使用する際にますます複雑なコンプライアンス要件に直面しています。このブレイクアウトセッションでは、ヨーロッパおよびグローバルな規制フレームワークに焦点を当てて、AWS で主権要件を満たすための実用的なアーキテクチャアプローチを探ります。データレジデンシー制御、運用の透明性、ソブリンワークロードの分離を可能にする主要なアーキテクチャパターンを検討します。このセッションでは、ソブリン設計のベストプラクティスを含む AWS Sovereignty Pledge と、今後の AWS European Sovereign Cloud についても取り上げます。 まとめ セキュリティ対策をモダナイズしようとするセキュリティアーキテクトであれ、より速いビジネス成長を促進するために組織のセキュリティポスチャを向上させることを目指すセキュリティエグゼクティブであれ、re:Inforce はお客様にとって有意義なカンファレンスになるでしょう。厳選され認定された AWS スピーカーにより、価値ある洞察と現実的な戦略が提供されます。デジタル時代にチームを強化し、資産を保護し、ビジネスを前進させるために、re:Inforce にぜひご参加ください。 この記事に関する質問がある場合は、 AWS サポート にお問い合わせください。 Rahul Sahni Rahul は AWS Security のシニアプロダクトマーケティングマネージャーです。熱心な Amazonian として、Rahul は仕事と私生活の両方で会社の原則である「学び、好奇心を持つ」を体現しています。継続的な学習への情熱を持ち、新しい経験と冒険を楽しんでいます。仕事以外では、世界中の新しい料理を試すことを楽しんでいます。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 5 月 28 日に公開された Blog “ Application security at re:Inforce 2025 ” を翻訳したものです。 カンファレンスパスの料金は 1,099 ドルです。 今すぐ登録 して、コード flashsale150 を使用すると、数量限定で 150 ドルの割引が受けられます。 訳注) 日本からご参加いただくお客様が利用できるカンファレンスパスのディスカウントコードをご用意しました。 コード JAPbHNlXWaI2 を利用することで 500 USD の割引 を受けることができます。数に限りがございますので、お早めにご登録ください！ 2025 年 6 月 16 日～18 日、フィラデルフィアで開催される AWS re:Inforce にぜひご参加ください。クラウドセキュリティ、コンプライアンス、ID、プライバシーに関するスキルと自信を高めることができます。参加者は、数百の技術的・非技術的セッション、 Amazon Web Services (AWS) の専門家と AWS セキュリティコンピテンシーパートナー が出展する展示会、業界リーダーによる基調講演にアクセスできます。AWS re:Inforce では、アプリケーションセキュリティ (AppSec) を含む主要なセキュリティ分野に包括的に焦点を当てています。 2025 年の AppSec の主要テーマ AppSec トラックでは、開発ライフサイクル全体を通じてアプリケーションを保護するためのベストプラクティスを理解し実装するのに役立ちます。2025 年は、いくつかの重要なテーマに焦点を当てています： 迅速かつセキュアにリリースするための組織戦略 セキュリティのオーナーシップ、DevSecOps などのパートナーシップ、包括的なアプリケーションセキュリティプログラム、アプリケーションセキュリティの専門知識を開発チームへの展開する方法について学びましょう。これらのセッションでは、スピードを犠牲にすることなく、組織がセキュリティを開発プロセスに組み込む方法を探り、セキュリティ責任を効果的に委譲させる実践的なアプローチに焦点を当てています。 設計段階からのセキュリティ ソフトウェアアーキテクチャと設計の初期段階にセキュリティ原則を組み込むことで、脆弱性を早期に軽減し、リスクを最小限に抑え、セキュリティをコアビジネス要件として認識します。先進的な組織がセキュリティをアドオンではなく基盤要素として実装する方法を学びましょう。 パイプラインのセキュリティ パイプラインのセキュリティには、Supply chain Levels for Software Artifacts (SLSA)、Supply Chain Integrity, Transparency, and Trust (SCITT)、コード署名を含むパイプラインを保護するためのツール、リファレンスアーキテクチャ、ベストプラクティスが含まれます。アプリケーションを構築・デプロイするシステムとプロセスを保護する方法を発見しましょう。 パイプライン内のセキュリティ パイプライン内のセキュリティは、静的解析、動的解析、責任ある AI テスト、ソフトウェアコンポジション分析、形式手法 (自動推論)、依存関係追跡などのテスト手法によって部分的に実現されます。これらのセッションでは、開発ライフサイクル全体に包括的なセキュリティテストを統合する方法を紹介します。 以下のセクションでは、今年の AppSec トラックで行われる最も興味深いセッションの一部をご紹介します。完全なリストは、 re:Inforce 2025 カタログ をご覧ください。 ブレイクアウトセッション、チョークトーク、ライトニングトーク、コードトーク APS204 | ブレイクアウトセッション | Scaling security with Sportsbet’s Security Guardians program (Sportsbet のセキュリティガーディアンプログラムによるセキュリティのスケーリング) セキュリティガーディアンプログラムは、セキュリティ専門知識を構築し埋め込むことで、アプリケーションチーム全体でセキュリティをスケールするのに役立ちます。Sportsbet のプログラムを詳しく掘り下げ、始め方、考慮すべき主要フェーズ、新しいガーディアンの最初の学習ステップについて学びます。得られた教訓、一般的な課題、長期的な成功のためにプログラムを改良する方法を発見しましょう。アプリケーションチームに早期にセキュリティを統合することで、Sportsbet は共有責任の文化を育み、開発速度を落とすことなくセキュリティポスチャを向上させています。セキュリティガーディアンプログラムを立ち上げ、発展させて組織全体に実際の影響を与えるための実践的な洞察を提供します。 APS301 | ブレイクアウトセッション | Improve code quality with Amazon Q Developer (Amazon Q Developer によるコード品質の向上) Amazon Q Developer は、コード作成だけでなく、ドキュメントの改善、ユニットテストの生成、コードレビューの自動化も可能な生成 AI アシスタントです。このセッションでは、ソフトウェアコンポジション分析 (SCA)、静的アプリケーションセキュリティテスト (SAST) などを使用してセキュリティ問題を検出するために、Amazon Q Developer をソフトウェア開発ライフサイクルに統合する方法を発見します。統合開発環境 (IDE) と DevSecOps ツール内で Amazon Q Developer の機能を使用してコードベースの品質を向上させる方法を学びましょう。 APS401 | ブレイクアウトセッション | Build verifiable apps using automated reasoning and generative AI (自動推論と生成 AI を使用した検証可能なアプリの構築) 大規模言語モデル (LLM) は創造的なソリューションの生成に優れており、自動推論ツールは厳密な検証を可能にします。このセッションでは、より信頼性の高い AI システムを作成するために、これらの相補的な強みを組み合わせる方法論を探ります。このセッションでは、自動推論を紹介し、形式手法が生成 AI をどのようにガイドし制約できるかを実演します。確率的アプローチと記号的アプローチを組み合わせることで、創造的能力を維持しながら検証可能な出力を確保するハイブリッドシステムの構築方法を示します。Amazon Q Developer と Amazon Bedrock ガードレール が自動推論を使用して、ハルシネーションのない安全で論理的に正しい出力を生成する方法をデモンストレーションします。 APS431 | チョークトーク | DevSecOps in action with Visual Studio Code &amp; AWS IAM Access Analyzer (Visual Studio Code と AWS IAM Access Analyzer による DevSecOps の実践) 組織は AWS Identity and Access Management (IAM) ポリシーを管理する際、開発者の生産性とセキュリティコンプライアンスのバランスという重要な課題に直面しています。このセッションでは、 AWS IAM Access Analyzer を Visual Studio Code と統合することで、開発者が開発中に安全な IAM ポリシーを作成できるようにする方法を発見します。過度に許容的な権限を早期に検出し、組織の標準に対して検証し、リアルタイムのフィードバックを提供する自動ポリシーチェックの実装方法を学びましょう。このプロアクティブなアプローチは、セキュリティチームが制御を維持しながら開発者に必要な自律性を与え、最終的にデプロイリスクを軽減し、貴重な開発時間を節約するのに役立ちます。 APS341 | コードトーク | Move fast and stay secure: Lessons learned from the AWS prototyping team (迅速に進みながらセキュリティを確保する: AWS プロトタイピングチームから学ぶ教訓) 生成 AI やサーバーレスなどのテクノロジーを使用してプロトタイプやアプリケーションを構築する際、迅速かつ安全に進めることが重要です。このコードトークでは、AWS プロトタイピングチームがこれらの目標をどのようにバランスよく達成しているかを学びます。ユーザーの需要に応えるため、AWS は短期間でプロトタイプを構築しながら、高いセキュリティ基準を満たしています。脅威モデリングから AWS Cloud Development Kit (AWS CDK) の機能、カスタムコンストラクト、ブループリントの活用まで、インフラストラクチャのセキュリティを強化し生産性を向上させるためのポイント、ヒント、テクニックを学びましょう。 APS441 | コードトーク | Supercharge IaC security with AI: From commit to auto-remediation (AI で IaC セキュリティを強化: コミットから自動修復まで) Git コミット署名、静的解析、生成 AI を組み合わせた自動セキュリティフィードバックループの構築について詳しく学びます。このセッションでは、ライブコーディングを通じて、Amazon Q Developer と Amazon Bedrock を使用して Infrastructure as Code (IaC) テンプレートを分析し、問題を自動的に検出・解決し、状況に応じた修正推奨事項を生成する方法を紹介します。セキュリティ検出結果のコミットベースの追跡方法、問題の自動作成方法、CI/CD パイプラインとの統合方法を学びましょう。脆弱性の検出から修復までの時間を数日から数分に短縮する完全なシステムの構築をご覧ください。 APS442 | コードトーク | Create memory safe applications using open source verification tools (オープンソース検証ツールを使用したメモリ安全なアプリケーションの作成) メモリ安全性のエラーは、さまざまな攻撃ベクトルを可能にする重大なセキュリティリスクをもたらします。AWS では、顧客データやプロセスを扱う非管理コードのメモリ安全性を優先しています。このトークでは、Rust と C コードのメモリ安全性エラーを削減するための 2 つの取り組みを紹介します。どちらの取り組みも、Rust と C コードのメモリ安全性を大規模に検証するための検証ツールの開発を含み、皆さんが利用できるものです。最初の取り組みでは、何百万人もの開発者が使用する中核的なソフトウェアリソースである Rust 標準ライブラリを検証します。2 つ目の取り組みでは、C モデルチェッカーを使用して C コードの安全性と正確性を検証します。 APS221 | ライトニングトーク | Building secure development into Amazon stores (Amazon ストアにセキュアな開発を組み込む) Amazon.com は長い間、顧客データを保護するための堅牢なセキュリティ対策への投資の最前線にいました。デジタル環境が進化するにつれて、私たちの戦略も進化しています。このセッションでは、AWS サービスを使用してソフトウェア開発ライフサイクル全体にセキュリティを統合することに焦点を当て、セキュリティプラクティスの継続的な改善の旅を探ります。Amazon.com が開発の各段階にセキュリティを組み込むために使用している最先端の方法を共有し、成功事例と学びについて議論します。開発者と顧客のニーズの変化に対応するために戦術をどのように適応させてきたか、そして顧客データ保護への取り組みをこれまで以上に強化する方法を発見するためにご参加ください。 APS222 | ライトニングトーク | Transform threat modeling using generative AI (生成 AI を活用した脅威モデリングの変革) インドの最大級のフィンテック企業の一つである CRED が、生成 AI を活用してアプリケーション全体の脅威モデリングを自動化した方法をご紹介します。CRED がセキュリティ分析をスケールし、リスク識別を改善し、意思決定を強化するために活用したアーキテクチャパターンを学びましょう。Amazon Bedrock を使用してセキュリティモデリングワークフローに AI を統合する実践的な例をご覧ください。 SEC221 | ライトニングトーク | Raising the tide: How AWS is shaping the future of secure AI for all (潮位を上げる: AWS が全ての人のためのセキュアな AI の未来を形作る方法) AI セキュリティは AWS の最優先事項です。設計段階からセキュアな AI ソリューションを構築することで、AWS は新たな脅威を軽減しながら、自信を持って迅速にイノベーションを実現できるよう支援します。しかし、AI のセキュリティ確保は個々の組織を超えた、業界全体の標準とベストプラクティスを必要とします。AWS は、AI 技術の安全性、回復力、信頼性を確保するために、Secure AI Coalition (CoSAI) などの業界標準団体への参加を含め、グローバルな AI セキュリティの取り組みに積極的に貢献しています。このセッションでは、AWS が AI セキュリティのイノベーションをリードし、顧客を保護し、業界全体の AI セキュリティの未来を形作るために協力している方法を探ります。 ワークショップとビルダーセッション APS351 | Securing generative AI agents using AWS Well-Architected Framework (AWS Well-Architected フレームワークを使用した生成 AI エージェントのセキュリティ確保) AWS Well-Architected フレームワーク生成 AI レンズ のセキュリティベストプラクティスに従って、セキュアな生成 AI エージェントソリューションを構築する方法を実践的に学びます。エンドポイントセキュリティ、プロンプトエンジニアリングガードレール、監視システム、過剰なエージェンシーからの保護の実践的な実装を通じて、本番環境に対応した生成 AI エージェントを構築します。ハンズオン演習を通じて、Amazon Bedrock、 Amazon CloudWatch 、IAM などを使用して、これらのコントロールを組み込んだセキュアな生成 AI エージェントソリューションを AWS 上に構築します。参加にはノートパソコンをご持参ください。 APS353 | Red-teaming your LLM security at scale (LLM セキュリティのスケールに応じたレッドチーム演習) GenAI レッドチームチャレンジで AI を活用したレッドチーム攻撃者の立場を体験してください。この集中ワークショップでは、AI セキュリティエージェントを展開して、プロンプトインジェクションから境界テストまで、生成 AI アプリケーションに対する高度な攻撃チェーンを体系的に発見・悪用しながら、自動化されたセキュリティテストワークフローをマスターします。さらに、プロンプトテンプレートからガードレールまでの対策の適用方法を学びます。このハンズオン形式のゲーム化された体験は、脅威アクターのように考える助けとなり、LLM ベースのアプリケーションに対する MITRE や OWASP の一般的な脆弱性に対する自動化された脆弱性テストとリスク軽減の実践的なスキルを身につけることができます。参加にはノートパソコンをご持参ください。 APS354 | Secure your application using AWS services and open source tooling (AWS サービスとオープンソースツールを使用してアプリケーションを保護する) AWS、オープンソース、およびパートナーツールが連携して、ソフトウェア開発ライフサイクルを加速します。オープンソースのアプリケーションセキュリティツールである Automated Security Helper (ASH) を使用して、さまざまなセキュリティテストツールをソフトウェアのビルドおよびデプロイフローに迅速に統合する方法を学びましょう。AWS のエキスパートが、ローカルマシンでのセキュリティテストと、サンプルの生成 AI アプリケーションを使用したシミュレーションパイプライン内でのテストプロセスをガイドします。静的解析、ソフトウェアコンポジション分析、およびインフラストラクチャ・アズ・コードテストを通じてアプリケーションの潜在的なセキュリティ問題を特定し、Amazon Q Developer を使用して結果を確認し、修復策を生成する方法を発見しましょう。参加するにはラップトップを持参する必要があります。 APS271 | Threat modeling for builders (ビルダーのための脅威モデリング) このワークショップでは、脅威モデリングの中核概念と、一連のグループ演習を通じてそれらを適用する方法を学びます。主要なトピックには、脅威モデリングのペルソナ、主要フェーズ、データフロー図、 STRIDE (なりすまし、改ざん、否認、情報漏洩、サービス拒否、および権限昇格)、およびリスク対応戦略が含まれます。 脅威文法ルール と関連ツールを紹介します。演習では、脅威モデリングのペルソナそれぞれの視点から脅威と緩和策を特定します。グループに分かれて導入事例を検討します。AWS の脅威モデリングの専門家がガイドとフィードバックを提供します。参加するにはラップトップを持参する必要があります。 APS371 | Securing your generative AI applications on AWS (AWS での生成 AI アプリケーションのセキュリティ確保) このワークショップでは、AWS サービスと機能を使用して生成 AI アプリケーションを保護する方法を発見します。脆弱性のあるサンプルの生成 AI アプリケーションをデプロイし、セキュリティコントロールを層状に適用してセキュリティ問題から保護、検出、対応する方法を探ります。組織内の生成 AI アプリケーションに同様のコントロールを適用する方法を学びましょう。参加するにはラップトップを持参する必要があります。 APS471 | Boost developer productivity with Amazon Q Developer and Amazon Bedrock (Amazon Q Developer と Amazon Bedrock で開発者の生産性を向上させる) Amazon Q Developer と Amazon Bedrock で開発を加速しイノベーションを推進しましょう。AI を活用した自動化とインテリジェントなコード支援が、摩擦を減らし、開発サイクルを短縮し、コード品質を向上させる方法を発見します。AI 駆動のコードレビュー、自動テスト、スマートなドキュメント生成などの実際のユースケースを探ります。これらのツールをワークフローにシームレスに統合して効率性を高め、コラボレーションを強化し、セキュリティとコンプライアンスを確保しながら開発者エクスペリエンスを向上させる方法を学びましょう。既存のプロセスを最適化する場合でも、初めて AI を採用する場合でも、このセッションは開発チームを強化するための実用的な洞察を提供します。参加するにはラップトップを持参する必要があります。 まとめ この投稿では、今後開催される AWS re:Inforce 2025 カンファレンスで利用可能な AppSec セッションの一部をご紹介しました。これらのトピックに興味がある方は、 AWS re:Inforce 2025 に登録 して、これらのセッションや他のセキュリティドメイントラックの多くのセッションに参加することをお勧めします。すべてのセキュリティトラックにわたるセッションの全範囲を確認するには、 AWS re:Inforce カタログ をご覧ください。 この記事に関する質問がある場合は、 AWS サポート にお問い合わせください。 Daniel Begimher Daniel はクラウドセキュリティとインシデント対応ソリューションを専門とするシニアセキュリティエンジニアです。AWS セキュリティおよびコンプライアンス技術フィールドコミュニティ内のアプリケーションセキュリティ分野を共同リードし、すべての AWS 認定資格を保有しており、オープンソースのコードスキャンツールである Automated Security Helper (ASH) の作者です。プライベートでは、ガジェット、ビデオゲーム、旅行を楽しんでいます。 Danny Cortegaca Danny はセキュリティスペシャリストソリューションアーキテクトであり、AWS セキュリティおよびコンプライアンス技術フィールドコミュニティ内のアプリケーションセキュリティ分野を共同リードしています。2021 年に AWS に入社し、世界最大の組織と提携して複雑なセキュリティおよび規制環境をナビゲートするのを支援しています。顧客とアプリケーションセキュリティについて話し合うことを楽しみ、多くの組織が脅威モデリングを実践に取り入れるのを支援してきました。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 5 月 27 日に公開された Blog “ Navigating the threat detection and incident response track at re:Inforce 2025 ” を翻訳したものです。 カンファレンスパスの料金は 1,099 ドルです。 今すぐ登録 して、コード flashsale150 を使用すると、数量限定で 150 ドルの割引が受けられます。 訳注) 日本からご参加いただくお客様が利用できるカンファレンスパスのディスカウントコードをご用意しました。 コード JAPbHNlXWaI2 を利用することで 500 USD の割引 を受けることができます。数に限りがございますので、お早めにご登録ください！ 年次クラウドセキュリティイベント AWS re:Inforce の開催が近づいてきました！AWS はセキュリティ専門家やビルダーのみなさまを 2025 年 6 月 16 日～ 18 日にペンシルベニア州フィラデルフィアにお招きし、クラウドセキュリティについて学ぶ 3 日間の体験型プログラムにご参加いただけることをうれしく思います。AWS re:Inforce では、 Amazon Web Services (AWS) セキュリティの全体像を確認し、セキュリティサービスの運用方法を学び、クラウドセキュリティのスキルと自信を高めて組織のセキュリティポスチャを改善する機会が得られます。参加者は、データ保護、ID とアクセス管理、脅威検出とインシデント対応、ネットワークとインフラストラクチャセキュリティ、生成 AI、ガバナンス、リスク、コンプライアンス、アプリケーションセキュリティなど、複数のトピックトラックにわたる 250 以上のセッションにアクセスできます。さらに、AWS でセキュアにイノベーションを実現した経験を共有するお客様スピーカーの講演にもご期待ください。 このブログでは、お客様の実際のユースケースを紹介する講義形式のプレゼンテーションや、AWS の専門家が実践的な問題と解決策を案内する少人数グループのインタラクティブセッションなど、主要なセッションの概要を紹介します。 脅威検出とインシデント対応トラックは、ワークロードを大規模に保護するためのセキュリティリスクの検出と対応方法を実証するように設計されています。AWS の専門家とお客様は、統合クラウドセキュリティ、脅威検出、脆弱性管理、クラウドセキュリティポスチャマネジメント (CSPM)、検出から対応までの統合、脅威インテリジェンス、AWS セキュリティサービスの運用化、コンテナセキュリティ、効果的なセキュリティ調査、セキュリティ分析、インシデント対応のベストプラクティスなどの主要トピックを発表します。また、生成 AI の活用によるセキュリティ強化と生成 AI ワークロードの保護の両方についても探求します。 ブレイクアウトセッション、チョークトーク、ライトニングトーク TDR301 | ブレイクアウトセッション | Innovations in AWS detection and response for integrated security outcomes (統合セキュリティ成果のための AWS 検出と対応のイノベーション) AWS の最新の検出および対応機能がクラウド環境をより効果的に保護する方法を発見してください。強化された脅威検出、自動化された脆弱性管理、合理化された対応を通じて、すべて大規模に統合されたセキュリティ成果を達成するための実践的な方法を学びます。AWS セキュリティサービスを使用してワークロードとデータを保護し、セキュリティ監視を一元化し、セキュリティ体制を継続的に管理し、セキュリティデータを統合する方法を紹介します。また、セキュリティ運用のための生成 AI の活用方法も説明します。AWS 検出および対応サービスを統合して AWS 全体のセキュリティを強化し簡素化するための実用的な洞察を得ることができます。 TDR302 | ブレイクアウトセッション | Multi-stage threat detection using GuardDuty and MITRE (GuardDuty と MITRE を使用した多段階脅威検出) Amazon GuardDuty 拡張脅威検出と MITRE フレームワークを活用して、脅威検出機能を強化します。このセッションでは、 MITRE Corp の Shane Steiger Esq. が、AWS 環境での多段階セキュリティイベントを効果的に特定し対応する方法を実演します。検出コントロールの実装、対応手順の開発、レジリエントなクラウドアーキテクチャの構築のための実践的な戦略を学びましょう。 GuardDuty と MITRE フレームワークを統合することで、イベント検出と対応戦略を強化する方法を発見してください。 TDR303 | ブレイクアウトセッション | Building secure generative AI security tools, featuring Trellix (Trellix が紹介するセキュアな生成 AI セキュリティツールの構築) セキュリティデータを統合し、自然言語による調査を可能にする企業レベルの生成 AI セキュリティツールの構築方法を学びます。このセッションでは、データプライバシーとコンプライアンスコントロールの実装パターンを含む、セキュアな生成 AI ソリューションを開発するための実践的なアプローチを紹介します。AWS ファンデーションモデルとセキュリティオーケストレーションを組み合わせた実際のアーキテクチャを探索します。 Trellix が Amazon Bedrock モデルを使用して 95% の精度を維持しながら 23 倍のコスト削減を達成した方法をご紹介します。セキュリティチームをサポートする安全な AI アシスタントを構築するための戦略を持ち帰りましょう。 TDR304 | ブレイクアウトセッション | Scaling AWS threat intelligence to protect customers (お客様を保護するための AWS 脅威インテリジェンスのスケーリング) AWS が何百万ものお客様を保護するために前例のない規模で脅威インテリジェンスを構築・運用する方法を発見してください。このセッションでは、高度な脅威を追跡して防御する Amazon 脅威インテリジェンスと、毎秒 40 億以上のレコードを分析するセキュリティデータ処理アーキテクチャである Active Defense という 2 つの重要なセキュリティ機能について詳しく掘り下げます。これらの機能が連携して AWS セキュリティサービスを強化し、アプリケーションに自動保護を提供する方法を学びます。AWS がこのインテリジェンスを活用して、ワークロードの安全を確保するセキュリティサービスを継続的に強化する方法をご覧ください。 TDR305 | ブレイクアウトセッション | Scale Vulnerability Management Using Amazon Inspector (Amazon Inspector を使用した大規模な脆弱性管理) Lambda セキュリティを強化し、脆弱性管理を合理化したいですか？ Amazon Inspector が生成 AI を使用してコンテキスト内のコードパッチを提供し、SBOM 管理を自動化する方法を学びます。CI/CD 統合、クロスアカウントスキャン、自動修復ワークフローのための実践的なテクニックを発見してください。AWS 環境全体でセキュリティ運用を強化するための Security Hub および EventBridge との組み込み統合を探索します。 TDR306 | ブレイクアウトセッション | Enterprise Security at Scale: SAP’s AWS Blueprint (エンタープライズセキュリティのスケーリング: SAP の AWS ブループリント) SAP はどのように数千の AWS アカウントを保護しているのでしょうか？高度な脅威パターンを特定するために、 Amazon GuardDuty 保護プランと拡張脅威検出を実装するためのブループリントを学びます。 AWS Security Hub コントロールと自動修復ワークフローを大規模に標準化するためのフレームワークを発見してください。AWS Organizations 全体でエンタープライズセキュリティ運用を強化するための実践的な戦略を持ち帰りましょう。 TDR331 | チョークトーク | Ask AWS: Your ransomware questions answered (AWS に質問: ランサムウェアに関する質問に回答) このインタラクティブな Q&amp;A セッションで、ランサムウェアに関する最も重要な質問への回答を得ましょう。AWS のセキュリティ機能とベストプラクティスが、ランサムウェアの脅威の検出、対応、復旧にどのように役立つかを学びます。専門家が、早期警告サインの特定、効果的なインシデント対応の実施、ランサムウェアに対する全体的なレジリエンスの強化について実践的なガイダンスを共有します。新たなランサムウェア戦術やクラウド保護戦略に関する難しい質問をお持ちください。AWS セキュリティ機能を使用してデータと運用を保護するための実用的な洞察を得ることができます。 TDR332 | チョークトーク | Decoding AWS CIRT tactics &amp; techniques for proactive defense (AWS CIRT の戦術とテクニックを解読して積極的な防御を実現) お客様の重要なセキュリティイベントへの対応を支援する AWS Customer Incident Response Team (CIRT) の専門家から直接学びましょう。AWS 環境全体で観察された新たな脅威の戦術と手法に関する実世界の洞察を発見します。 共有責任モデル に沿った実践的な検出と緩和戦略を共有し、セキュリティ体制の強化を支援します。進化する脅威から防御する CIRT の最前線での経験から得られる実用的なベストプラクティスを持ち帰り、これらの洞察を AWS ワークロードの保護に適用する方法を学びましょう。 TDR333 | チョークトーク | Strategy for prioritization and response (優先順位付けと対応の戦略) このセッションに参加して、複数のアカウント、リージョン、リソースにわたるセキュリティ体制とリスクの管理について議論しましょう。 AWS セキュリティサービス を使用してセキュリティアラートとリスクの優先順位をつける方法に関する意思決定プロセスを探ります。優先順位付けの後、セキュリティ検出結果への対応と修復のためのフレームワークについて議論します。検出結果への対応に関する意思決定プロセス、自動修復の考慮事項、最も重要なセキュリティ検出結果への迅速かつ徹底的な対応を促進する方法について説明します。 TDR334 | チョークトーク | Strengthen Security: Making GuardDuty Protection Plans Work for You (セキュリティ強化: GuardDuty 保護プランを活用する) 環境に適した Amazon GuardDuty 保護プランを選択することで、脅威検出機能を最大化する方法を発見してください。AWS ワークロードに最も重要な保護機能を評価し、各プランがセキュリティ戦略にもたらす価値を理解する方法を学びます。実践的なシナリオを通じて、AWS アカウント全体でコスト効率の良い実装戦略を探索します。AWS ワークロードとデータの保護を強化するために Amazon GuardDuty のデプロイを最適化するための実用的な洞察を持ち帰りましょう。 TDR431 | チョークトーク | Best practices for containing AWS resources during incident response (インシデント対応中の AWS リソース隔離のベストプラクティス) セキュリティイベント発生時の AWS リソースとアカウントの隔離コントロールを実装するためのベストプラクティスを学びます。実践的なシナリオを通じて、 Amazon EC2 インスタンス、 AWS Lambda 関数、 Amazon ECS コンテナを隔離するための効果的なアプローチを発見します。ID、リソース、ネットワークコントロールを含むアカウントレベルの隔離のための包括的な戦略を探ります。このセッションでは、対応手順の一部として隔離コントロールを実装し、安全に削除するためのガイダンスを提供します。AWS インシデント対応機能を強化するための実用的なパターンを持ち帰りましょう。ビジネスの迅速化とセキュリティ成果の提供を支援するために、最新のセキュリティチームはワークフローを自動化し簡素化する機会を特定する必要があります。その方法の一つが生成 AI です。このチョークトークに参加して、Amazon GuardDuty、Amazon Inspector、AWS Security Hub からの検出結果の調査、優先順位付け、修復に生成 AI がどのように役立つかのユースケースを特定する方法を学びましょう。次に、これらのユースケースからアーキテクチャを開発し、実装し、その有効性を評価する方法を発見します。このトークでは、認知負荷を軽減し、新規で価値の高い機会への集中を高めるために、生成 AI を安全に使用するのに役立つ生成 AI とセキュリティの原則を提供します。 TDR336 | チョークトーク | Secure generative AI models and agents on AWS (AWS での生成 AI モデルとエージェントの保護) AWS 環境での生成 AI モデルと Amazon Bedrock エージェントのセキュリティコントロールを強化する方法を学びます。このセッションでは、API エンドポイントの保護とエージェントの対話の保護のための実装パターンを探ります。AI/ML ワークロードの保護コントロールの実装とデータセキュリティの維持のための実践的なアプローチを発見します。AWS サービスを使用してセキュアな生成 AI 実装を構築するための実用的な戦略を持ち帰りましょう。 TDR337 | チョークトーク | Implementing AWS security best practices: Insights &amp; strategies (AWS セキュリティのベストプラクティスの実装: 洞察と戦略) Amazon GuardDuty 、 AWS Security Hub 、 AWS WAF を含む AWS セキュリティサービスの実装を最適化する方法を学びます。AWS セキュリティの専門家が、数千のお客様のデプロイから得られた実践的な洞察と実証済みのパターンを共有します。このセッションでは、環境内でセキュリティサービスを効果的に運用するための実用的な戦略を提供します。AWS セキュリティサービスの価値を最大化するための実装のベストプラクティスとアーキテクチャアプローチを発見してください。 TDR338 | チョークトーク | Building cloud-native forensic investigation architectures on AWS (AWS でのクラウドネイティブフォレンジック調査アーキテクチャの構築) このチョークトークに参加して、AWS でのクラウドネイティブデジタルフォレンジックとインシデント対応の利点を探りましょう。安全なフォレンジック調査環境を確立するためのベストプラクティスに関するインタラクティブな議論に参加してください。フォレンジックアーティファクトを安全に収集・保存するためのアーキテクチャパターン、セキュリティを強化するためのエフェメラルリソースの活用、効果的なネットワーク、アカウント、組織設計の実装について探ります。質問やシナリオをお持ちください。 AWS サービス を使用してスケーラブルで標準化された調査プロセスを構築する方法を共同で検討します。クラウドでのフォレンジックとインシデント対応機能を強化するための実践的な戦略を持ち帰りましょう。 TDR231 | チョークトーク | Resilient security teams: Reduce burnout and boost performance (レジリエントなセキュリティチーム: バーンアウトを減らしパフォーマンスを向上させる) 高いパフォーマンスを維持しながらウェルビーイングを優先するレジリエントなセキュリティおよびインシデント対応チームを構築するための戦略を学びます。このセッションでは、定期的なチームチェックイン、データに基づいたウェルビーイングイニシアチブ、サポート的なチーム文化を実装するためのアプローチを探ります。オープンなコミュニケーションを促進し、チームのエンゲージメントを維持し、チームの貢献を認識するための実践的な方法を発見します。実際の例を通じて、チームのレジリエンスを高め、定着率を向上させ、セキュリティの卓越性を維持するための実用的な計画を立てます。高パフォーマンスのセキュリティチームを構築・維持するための戦略を持ち帰りましょう。 TDR321 | ライトニングトーク | From Incidents to Insights: Creating a Security Learning Organization (インシデントから洞察へ: セキュリティ学習組織の構築) セキュリティイベントを組織の改善に変える方法を学びます。このセッションでは、効果的なフィードバックループの構築、組織知識の保存、セキュリティ運用の持続可能な強化を実装するための実践的なアプローチを紹介します。改善の影響を測定し、継続的な学習の文化を育む AWS の戦略を発見してください。体系的な学習と適応を通じてセキュリティプログラムを強化するための実用的なフレームワークを持ち帰りましょう。 TDR322 | ライトニングトーク | How AWS uses generative AI to advance native security services (AWS がネイティブセキュリティサービスを進化させるために生成 AI を活用する方法) AWS がネイティブセキュリティサービスを強化するために生成 AI をどのように活用しているかを発見してください。このセッションでは、AWS がセキュリティポートフォリオ全体に AI 機能を実装して、脅威検出、調査、対応を改善する方法を紹介します。自動分析と自然言語セキュリティクエリを可能にする Amazon GuardDuty と Amazon Inspector での実践的な実装を探索します。AWS が生成 AI を通じてセキュリティをよりインテリジェントで効率的にする方法についての洞察を持ち帰りましょう。 TDR323 | ライトニングトーク | How Autodesk scales threat detection with Amazon GuardDuty (Autodesk が Amazon GuardDuty で脅威検出をスケールする方法) Autodesk が Amazon GuardDuty を使用して脅威検出戦略を向上させた方法を学びます。このライトニングトークでは、マルウェア保護を含む GuardDuty の高度な検出機能を活用するための実装アプローチ、運用上の洞察、ベストプラクティスを探ります。成長するクラウドフットプリントを効率的に管理しながら、堅牢なセキュリティを維持する方法を発見してください。 TDR421 | ライトニングトーク | Accelerating Incident Response with AWS Security Incident Response (AWS Security Incident Response によるインシデント対応の加速) AWS Security Incident Response がセキュリティチームの調査と対応手順を合理化する方法を学びます。このセッションでは、一元化されたインシデント管理を提供するための Amazon GuardDuty 、 AWS CloudTrail 、 AWS Security Hub とのサービス統合機能を紹介します。お客様の事例と実装パターンを通じて、自動化された対応戦略を構築するための実践的なアプローチを発見してください。AWS サービスを使用してセキュリティ運用を強化するための実用的な洞察を持ち帰りましょう。 インタラクティブセッション (ビルダーズセッション、コードトーク、ワークショップ) TDR251 | ビルダーズセッション | Build your first AI security assistant with Amazon Q (Amazon Q で最初の AI セキュリティアシスタントを構築する) Amazon Q Business を使用して最初の AI 搭載セキュリティアシスタントを構築する方法を発見しましょう—AI の専門知識は必要ありません。このハンズオンセッションでは、3 つの実践的なセキュリティワークフローを作成します: セキュリティ検出結果にコンテキストを提供する自動化された Amazon GuardDuty インシデント調査ツール、ポリシー評価を合理化する AWS Security Hub コンプライアンスレポート生成ツール、修復を加速する Amazon Inspector ベースの脆弱性管理ヘルパーです。生成 AI で AWS セキュリティ運用を強化しながら、実践的なアプリケーションを通じて AWS の主要なセキュリティサービスをマスターしたいセキュリティ実務者に最適です。 TDR252 | ビルダーズセッション | Detect ransomware events in Amazon S3 using Amazon GuardDuty (Amazon GuardDuty を使用して Amazon S3 でのランサムウェアイベントを検出する) このビルダーズセッションでは、 AWS Customer Incident Response Team (CIRT) と共に Amazon GuardDuty を使用して Amazon S3 ランサムウェア検出を実装します。ハンズオンシナリオを通じて、不正な暗号化操作を特定し、効果的な対応手順を実装する方法を学びます。 AWS CloudTrail 、 Amazon Athena 、 Amazon GuardDuty 、 Amazon CloudWatch を使用して検出パターンを構築します。イベントの調査と AWS セキュリティの最新ガイダンスに沿った Amazon S3 オブジェクト保護のための予防措置の実装を練習します。参加するにはラップトップを持参する必要があります。 TDR351 | ビルダーズセッション | Build an OCSF security log pipeline with AWS (AWS で OCSF セキュリティログパイプラインを構築する) このハンズオンセッションで、 Open Cybersecurity Schema Framework (OCSF) を活用した完全なセキュリティログパイプラインを構築します。AWS の専門家と一緒に、セキュリティデータの取り込み、変換、強化を行います。独自のスキーマを使用する場合でも、提供されたサンプルを使用する場合でも、セキュリティログを標準化するための実践的なテクニックを学びます。正規化されたセキュリティデータフローを通じて脅威検出機能を強化するための実装可能なソリューションを持ち帰りましょう。ラップトップとオプションのカスタムログサンプルを持参して、ユースケースに合わせたソリューションを作成してください。 TDR451 | ビルダーズセッション | Automate incident response for Amazon EC2 and Amazon EKS (Amazon EC2 と Amazon EKS のインシデント対応を自動化する) Amazon Elastic Compute Cloud ( Amazon EC2 ) と Amazon Elastic Kubernetes Service ( Amazon EKS ) 用の自動フォレンジックオーケストレーターソリューションを使用してインシデント対応を合理化する方法を学びます。このセッションでは、 AWS Security Hub の検出結果によってトリガーされる自動化されたワークフローを実装する方法を紹介します。実装の前提条件、カスタマイズオプション、自動フォレンジック機能によるセキュリティ運用の強化のためのベストプラクティスを探ります。 Amazon EC2 および Amazon EKS 環境全体で対応手順を標準化する方法を発見してください。 TDR452 | ビルダーズセッション | Build generative AI security runbooks with Amazon Bedrock (Amazon Bedrock で生成 AI セキュリティランブックを構築する) このビルダーズセッションでは、 Amazon Bedrock と Bedrock Agents を使用した生成 AI 搭載ランブックでセキュリティ運用を強化する方法を学びます。 AWS Security Hub の検出結果を分析し、コンテキストに応じた修復ガイダンスを提供するインテリジェントなワークフローを作成します。ハンズオン演習を通じて、AWS ドキュメントを活用し、セキュリティ調査のための自然言語インターフェースを実装する Bedrock Agents を構築します。組織固有のコンテンツでナレッジベースを構成し、適切なガードレールを実装する方法を学びます。生成 AI を使用してセキュリティ運用を合理化するための実践的なソリューションを持ち帰りましょう。参加するにはラップトップを持参する必要があります。 TDR341 | コードトーク | Build AI security agents with Amazon Bedrock and Security Lake (Amazon Bedrock と Security Lake で AI セキュリティエージェントを構築する) このコードトークでは、 Amazon Bedrock と Amazon Security Lake を使用して AI エージェントを作成し、セキュリティ運用を強化する方法を探ります。ライブコーディングデモを通じて、セキュリティ分析と対応のために生成 AI と自律的な意思決定機能を組み合わせた自動化されたワークフローを構築する方法を学びます。ログを分析し、コンテキストに応じた洞察を提供し、対応手順を実行するエージェントを実装する方法をご覧ください。セキュリティワークフローにカスタムツールと大規模言語モデルを統合するための実践的なアプローチを発見します。 TDR342 | コードトーク | Operationalizing Amazon Security Lake with analytics and generative AI (分析と生成 AI による Amazon Security Lake の運用化) このハンズオンコーディングセッションでは、 Amazon Security Lake 上に最新のセキュリティ分析ツールを構築します。インタラクティブなデモを通じて、 Amazon OpenSearch Service 、 Amazon QuickSight 、 Amazon Athena 、 Amazon Bedrock などの AWS サービスを使用してセキュリティデータを運用化するためのクエリと可視化を作成します。セキュリティデータを分析するための実践的なコードサンプルとアーキテクチャを持ち帰りましょう。脅威検出とインシデント対応スタックを変革するためのアイデアを得てください。 TDR343 | コードトーク | From detection to code: GuardDuty attack sequences with Amazon Q (検出からコードへ: Amazon Q による GuardDuty 攻撃シーケンス) このコードトークでは、 Amazon GuardDuty の攻撃シーケンス検出機能が Amazon Q と連携してセキュリティ運用を強化する方法を探ります。ライブコーディングデモを通じて、 GuardDuty の機械学習モデルが接続されたセキュリティイベントを特定し、包括的なイベントシーケンスを作成する方法を学びます。Amazon Q の AI 支援開発機能を使用して自動化された対応手順を構築する方法をご覧ください。コンテキストを認識したセキュリティ自動化を実装するための実践的なアプローチを発見します。生成 AI ツールを使用してセキュリティ運用を強化するための実装パターンを持ち帰りましょう。 TDR371 | ワークショップ | Hands-on Threat Detection &amp; Response using AWS Security (AWS セキュリティを使用したハンズオン脅威検出と対応) このインタラクティブなワークショップで AWS セキュリティサービスを実際に体験してください。 Amazon GuardDuty 、 Amazon Inspector 、 AWS Security Hub 、 Amazon Detective を使用してシミュレートされた脅威を検出し対応する方法を学びます。さまざまなリソースタイプにわたるセキュリティイベントを調査しながら、 AWS Lambda を使用した手動および自動化された対応テクニックを練習します。AWS 環境で脅威検出と対応を運用化するための実践的なスキルを持ち帰りましょう。このハンズオンワークショップに参加するにはラップトップを持参してください。 TDR372 | ワークショップ | Secure container workloads with AWS security services (AWS セキュリティサービスによるコンテナワークロードの保護) このワークショップでは、コードから運用までコンテナワークロードを包括的に保護するために AWS セキュリティサービスを実装する方法を学びます。静的コード分析、検出コントロール、脅威検出、脆弱性管理、Amazon Elastic Kubernetes Service ( Amazon EKS ) および Amazon Elastic Container Service ( Amazon ECS ) のインシデント対応について実践的な経験を積みます。ガイド付きシナリオを通じて、AWS セキュリティサービスを使用してコンテナのセキュリティ体制を強化する方法を発見します。コンテナ環境にセキュリティコントロールを実装するための実践的な戦略を持ち帰りましょう。参加するにはラップトップを持参する必要があります。 TDR471 | ワークショップ | AWS Security Incident Response Challenge: Defense in action (AWS セキュリティインシデント対応チャレンジ: 実践的な防御) このインタラクティブなセッションで AWS セキュリティインシデント対応スキルをテストしましょう。時間的制約のあるシナリオに対応する AWS セキュリティエンジニアの役割を担います。提供されたインテリジェンスを使用して、AWS 環境にセキュリティコントロールを実装するための限られた時間があります。現実的な条件下で効果的にアクションの優先順位を付け、AWS セキュリティサービスを活用する方法を学びます。このハンズオン演習は、AWS 環境での迅速な意思決定とセキュリティ実装を練習するのに役立ちます。インシデント対応戦略の実践的な経験を持ち帰りましょう。参加するにはラップトップを持参する必要があります。 TDR472 | ワークショップ | Active defense strategies using AWS AI/ML services (AWS AI/ML サービスを使用したアクティブディフェンス戦略) このワークショップでは、 Amazon Bedrock と Amazon SageMaker を使用して、欺瞞などのアクティブディフェンス戦略を開発・デプロイする方法を学びます。セキュリティ運用のための AI 駆動型レスポンスの開発に関する実践的な経験を積みます。攻撃者が使用しようとしている可能性のあるものを模倣する適応型レスポンスの開発方法を学びます。プロンプトエンジニアリング、デプロイ戦略、監視方法論の実装パターンを学びます。参加するにはラップトップを持参する必要があります。 他のトラックのセッション、ゲーム型学習、イノベーションセッション、パートナーセッション、ラボについて詳しく知るには、 re:Inforce カタログ 全体をご覧ください。 参加者ガイド で re:Inforce の旅を最適化する方法を発見してください—完璧な学習セッションを選択し、体験から最大の価値を得るための必須リソースです。 包括的なトラックコンテンツは、AWS でワークロードとアプリケーションを安全に管理するために必要な知識とスキルを提供するように設計されています。脅威検出とインシデント対応における最新のベストプラクティスを学ぶ機会をお見逃しなく。 今すぐ登録 して、フィラデルフィアでの re:Inforce 2025 にご参加ください。みなさまのご参加を心よりお待ちしております！ この記事に関する質問がある場合は、 AWS サポート にお問い合わせください。 Nisha Amthul Nisha は AWS Security のシニアプロダクトマーケティングマネージャーで、検出と対応ソリューションを専門としています。情報セキュリティとデータ保護の分野におけるプロダクトマネジメントとプロダクトマーケティングの強固な基盤を持っています。仕事以外では、ケーキデコレーション、筋力トレーニング、そして 2 人の元気な子供たちの世話に忙しくしています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2025 年 5 月 27 日に公開された Blog “ Elevate your AI security: Must-see re:Inforce 2025 sessions ” を翻訳したものです。 カンファレンスパスの料金は 1,099 ドルです。 今すぐ登録 して、コード flashsale150 を使用すると、数量限定で 150 ドルの割引が受けられます。 訳注) 日本からご参加いただくお客様が利用できるカンファレンスパスのディスカウントコードをご用意しました。 コード JAPbHNlXWaI2 を利用することで 500 USD の割引 を受けることができます。数に限りがございますので、お早めにご登録ください！ 概念実証 (PoC) から本番環境での大規模な利用まで、生成 AI の急速な進歩により、イノベーションを実現する絶好の機会が生まれています。同時に組織が対処しなければならない新たなセキュリティ課題 (そしてチャンス) も生まれています。モデルの効果を維持しながら、検索拡張生成 (RAG) やトレーニングデータをどのように保護すればよいでしょうか？大規模言語モデル (LLM) との対話にはどのような制御が必要でしょうか？リスクを最小限に抑えながら、AI エージェントや Model Context Protocol (MCP) をどのように最大限に活用できるでしょうか？AWS re:Inforce 2025 では、セキュリティの専門家や、実務者、業界のリーダーが集まり、実世界の実践的なガイダンスなどを学習できるため、これらの疑問を解決することができるでしょう。 今年の生成 AI セキュリティセッションは、大規模でセキュアな本番 AI システムの構築と維持を支援するために、特別に厳選したコンテンツをご用意しています。AI セキュリティの検討を開始したばかりの方も、成熟した企業全体の AI イニシアチブをリードしている方も、組織のセキュリティポスチャを向上させるための実践的なガイダンス、ハンズオン体験、戦略的な洞察を見つけることができます。 基本的な概念から高度な防御技術まで、これらのセッションはデータ保護、モデルセキュリティ、ID 管理、AI エージェントのレジリエンスなどの重要な領域を網羅しています。AWS セキュリティの専門家や、安全な AI システムを成功裏に実装したお客様、AI の安全性とセキュリティで新しい基準を設定している業界をリードするパートナーから直接学ぶことができます。 このブログでは、AI をセキュアにする方法だけでなく、セキュリティ実務者が重要なセキュリティミッションを支援するために AI をどのように活用できるかについても紹介する「必見」のセッションをいくつか紹介します！ぜひ re:Inforce 2025 に登録 して、ご参加ください！ イノベーショントーク イノベーショントーク シリーズで AWS のトップリーダーから最前線のクラウドテクノロジーについてのセッションを通じて、貴重な洞察を得ることができます。生成 AI の最新の進歩を確認し、堅牢なクラウドセキュリティ戦略を発見し、アプリケーション開発に革命をもたらし AWS クラウドの可能性を拡大している先駆的なアーキテクチャ概念を明らかにします。 SEC301 | イノベーショントーク | From possibility to production: A strong, flexible foundation for AI security (可能性から本番へ: AI セキュリティのための強力で柔軟な基盤) スピーカー: Hart Rossman (AWS) &amp; Becky Weiss (AWS) AWS が AI セキュリティの負担をどのように軽減し、開発から本番環境への移行を加速できるかを発見してください。このセッションでは、実証済みの AWS セキュリティ基盤と、柔軟な制御および自動推論を組み合わせることで、組織が AI イノベーションを自信を持ってデプロイできるようにする方法を明らかにします。実例を通じて、セキュリティを潜在的な障害からイノベーションの原動力に変える方法を学びます。今日の AI ワークロードを保護するための実践的なガイダンスと、データセキュリティやエージェント型 AI を含む新たなセキュリティ課題に対処するための戦略的な洞察を得ることができます。AWS の AI セキュリティへのアプローチが、強力なセキュリティ制御を維持しながら、どのように先行して始めるのに役立つかを学びます。 ブレイクアウトセッション、チョークトーク、ライトニングトーク ブレイクアウトセッション は、AWS の専門家、お客様、パートナーによって提供される講義形式の 1 時間のセッションで、重要なトピックに関する知識を深め、実用的な洞察を得て、業界のリーダーとつながるのに最適です。 チョークトーク は、少人数の聴衆と行う 1 時間の高度にインタラクティブなセッションです。このフォーマットは、特定のトピックを深く掘り下げ、AWS の専門家と直接対話し、リアルタイムで質問に答えてもらうのに理想的です。 ライトニングトーク は、特定のユーザー事例、サービスデモ、または AWS パートナーの提供物に特化した短い (20 分間) シアタープレゼンテーションです。 SEC303 | ブレイクアウトセッション | Behind the shields: AWS and Anthropic’s approach to secure AI (シールドの裏側: AWS と Anthropic の安全な AI へのアプローチ) スピーカー: Matt Saner (AWS) &amp; Shahzeb Jiwani (Anthropic) エンタープライズ AI の採用には堅牢なセキュリティが必要です。このセッションでは、Anthropic のリスクガバナンス責任者と AWS のセキュリティリーダーが、AWS と Anthropic が LLM とそれが可能にする生成 AI ワークロードのためのエンタープライズグレードのセキュリティを提供するためにどのように協力しているかを明らかにします。インフラストラクチャ、データ、モデルにまたがる多層的なセキュリティアプローチについて学びます。実際のセキュリティアーキテクチャ、ガバナンスフレームワーク、リスク軽減戦略を探ります。厳格なセキュリティとコンプライアンス要件を維持しながら、組織の AI イニシアチブを加速するために AWS と Anthropic のセキュリティ機能を活用する方法についての理解を深めることができます。 SEC304 | ブレイクアウトセッション | Amazon.com testing frameworks and tools for GenAI security and privacy (Amazon.com の生成 AI セキュリティとプライバシーのためのテストフレームワークとツール) スピーカー: Alex Torres (AWS), Josh Haycraft (Amazon), &amp; Jess Clark (Amazon) 生成 AI ソリューションは、ユニークで急速に変化するセキュリティ環境で立ち上げられています: 顧客データでトレーニングされる可能性があり、内部サービスやデータストアと統合される可能性があり、生成されたコンテンツを顧客や他のシステムに提供します。 Amazon.com が大規模言語モデルと生成 AI を活用して顧客とのやり取りを豊かにし、俊敏性とイノベーションを促進するためのツールキット、システム、フレームワークをどのように作成しているかを学びます。 TDR301 | ブレイクアウトセッション | Innovations in AWS detection and response for integrated security outcomes (統合されたセキュリティ成果のための AWS 検出と対応の革新) スピーカー: Himanshu Verma (AWS) &amp; Ryan Holland (AWS) 最新の AWS 検出および対応機能がクラウド環境をより効果的に保護する方法を発見してください。強化された脅威検出、自動化された脆弱性管理、合理化された対応を通じて、すべてスケールで統合されたセキュリティ成果を達成するための実践的な方法を学びます。AWS セキュリティサービスを使用してワークロードとデータを保護し、セキュリティ監視を一元化し、セキュリティポスチャを継続的に管理し、セキュリティ運用のために生成 AI を活用しながら、セキュリティデータを統合する方法をお見せします。AWS 検出および対応サービスを統合して AWS 全体でセキュリティを強化し簡素化するための実用的な洞察を得ることができます。 SEC431 | チョークトーク | Dive deep into data protection architectures for Amazon Bedrock Agents (Amazon Bedrock エージェントのデータ保護アーキテクチャを深く掘り下げる) スピーカー: Andrew Kane (AWS) &amp; Gabrielle Dompreh (AWS) このチョークトークに参加して、 Amazon Bedrock がエージェントおよびナレッジベースやガードレールなどの関連機能全体でデータをどのように保護するかを理解してください。クロスリージョンデプロイ、マルチエージェントコラボレーション、プロンプトキャッシュのセキュリティ考慮事項について学びます。データ保護を維持する安全な生成 AI ソリューションのアーキテクティングに関する深い洞察を得て、アプリケーションを安全かつセキュアに保つアーキテクチャパターンを発見してください。 APS231 | チョークトーク | Using AWS services to mitigate the OWASP Top 10 for LLM threats (AWS サービスを使用して LLM の OWASP トップ 10 の脅威を軽減する) スピーカー: Mark Keating (AWS) &amp; Cameron Smith (AWS) 生成 AI のユースケースを特定し、テストして、セキュアなアプリケーションアーキテクチャ設計を作成しています。生成 AI 特有の脅威から保護するために、どのような脅威に対して保護すべきか、また利用可能なツールやサービスは何かをどのように知ることができるでしょうか？LLM アプリケーションの OWASP トップ 10 について聞いたことがあるかもしれませんが、どこから、またはどのように始めればよいでしょうか？OWASP トップ 10 の脅威、バージョン間の違い、そして AWS がこれらの脅威を軽減するためにどのように役立つかについて議論します。 DAP332 | チョークトーク | Executive perspective: Risk management for generative AI workloads (エグゼクティブの視点: 生成 AI ワークロードのリスク管理) スピーカー: Jason Garman (AWS) &amp; Mark Ryland (AWS) 責任ある AI の認識された複雑さが、AWS での生成 AI アプリケーションのデプロイを妨げないようにしましょう。このチョークトークでは、AI の安全性とセキュリティリスクを分解するためのフレームワークを提示し、ゼロトラスト原則を使用して生成 AI アプリケーションでエンタープライズデータを安全に保つための AWS のベストプラクティスを紹介し、Bedrock ガードレールなどのテクノロジーを使用して安全性リスクを軽減します。セキュリティリーダーの仲間とともにグループとして、ワークロードに関連する安全性とセキュリティリスクを特定し、適切な軽減戦略を実装し、時間の経過とともに効果を測定する方法を発見してください。 GRC337 | チョークトーク | Build compliant AI: Implementing controls for emerging regulations (コンプライアントな AI の構築: 新たな規制のための制御の実装) スピーカー: Samuel Waymouth (AWS) &amp; Mark Keating (AWS) AI の採用が加速するにつれて、組織はますます規制の監視とコンプライアンス要件に直面しています。このセッションでは、AI、データプライバシー、データ主権に関する進化するグローバルな規制環境について学び、規制要件とセキュリティ制御を AWS サービスと機能にマッピングする方法を見ていきます。生成 AI が評価、リスク分類、コンプライアンスガイダンスの生成のためのツールとしてどのように機能するかを実演します。また、AWS が開発した最新の脅威モデリングリソースの使用方法も紹介します。セキュリティの専門家と AI の実務者は、イノベーションの速度を維持しながら、コンプライアンス基準に沿った AI システムを構築するための実用的な戦略を学ぶことができます。 SEC221 | ライトニングトーク | Raising the tide: How AWS is shaping the future of secure AI (新時代を創る: AWS が安全な AI の未来をどのように形作っているか) スピーカー: Matt Saner (AWS) AI セキュリティは AWS の最優先事項です。設計上安全な AI ソリューションを構築することで、AWS はお客様が新たな脅威を軽減しながら自信を持って迅速にイノベーションを行うのを支援します。しかし、AI の保護は個々の組織を超えて、業界全体の標準とベストプラクティスを必要とします。AWS は、CoSAI (安全な AI のための連合) などの業界標準団体への参加を含め、AI 技術が安全で、回復力があり、信頼できるものであることを確認するために、グローバルな AI セキュリティの取り組みに積極的に貢献しています。このセッションでは、AWS が AI セキュリティイノベーションをリードし、お客様を保護し、業界全体の AI セキュリティの未来を形作るために協力している方法を探ります。 SEC322 | ライトニングトーク | Managing digital identity in the age of generative AI (生成 AI 時代のデジタル ID の管理) スピーカー: Arthur Mnev (AWS) &amp; Lily Ashidam (AWS) このセッションでは、生成 AI ワークロードでの ID 管理の課題と解決策を探ります。このセッションでは、LLM の API アクセスの保護、AI サービスの適切な認証の実装、データリネージュの維持について取り上げます。コンプライアンスとガバナンス要件を維持しながら、生成 AI アプリケーションを保護するための実践的なアプローチを学びます。 SEC323 | ライトニングトーク | A practical guide to generative AI agent resilience (生成 AI エージェントのレジリエンスに関する実践的ガイド) スピーカー: Yiwen Zhang (AWS) &amp; Jennifer Moran (AWS) 生成 AI エージェントが見出しや技術的な議論を支配する中、エンタープライズでの採用はまだ初期段階にあります。生成 AI エージェントのレジリエンスは、成功した実装とユーザーの信頼構築における重要な要素です。データベースの可用性、ワークロードの容量、オブザーバビリティ、ディザスタリカバリなどの従来のワークロードレジリエンスの実践は引き続き関連していますが、生成 AI エージェントは独自の課題をもたらします。このセッションでは、LLM モデルの適応性、レイテンシー管理、ツールの可用性、オブザーバビリティ、財務的持続可能性など、生成 AI エージェントのレジリエンスの重要な側面を掘り下げます。エンタープライズが信頼し維持できる堅牢で信頼性の高い生成 AI エージェントを構築するための実践的な戦略を共有します。 SEC326 | ライトニングトーク | Secure remote MCP server deployment for Gen AI on AWS (AWS での生成 AI 向けの安全なリモート MCP サーバーデプロイ) スピーカー: Aaron Brown (AWS) &amp; James Ferguson (AWS) プロトコルのセキュリティと信頼の原則を実装する AWS 上の Model Context Protocol (MCP) サーバーを安全に構築およびデプロイする方法を発見してください。このセッションでは、ユーザーの同意、データプライバシー、ツールの安全性要件を強制する OAuth 2.1 認証パターンを実演します。 Amazon Cognito 、 API Gateway 、 Lambda を使用してプロトコル準拠を維持しながら堅牢なセキュリティ制御を実装する方法を学びます。MCP 仕様に沿った認証フロー、アクセス制御、セキュリティ監視の実践的な例を探ります。 TDR322 | ライトニングトーク | How AWS uses generative AI to advance native security services (AWS がネイティブセキュリティサービスを進化させるために生成 AI をどのように使用しているか) スピーカー: Marshall Jones (AWS) &amp; Himanshu Verma (AWS) AWS がネイティブセキュリティサービスを強化するために生成 AI をどのように活用しているかを発見してください。このセッションでは、AWS が脅威検出、調査、対応を改善するためにセキュリティポートフォリオ全体で AI 機能をどのように実装しているかを実演します。 Amazon GuardDuty と Amazon Inspector での自動分析と自然言語セキュリティクエリを可能にする実践的な実装を探ります。AWS が生成 AI を通じてセキュリティをよりインテリジェントで効率的にする方法についての洞察を得ることができます。 インタラクティブセッション (ビルダーズセッション、コードトーク、ワークショップ) AWS の専門家が主導する小グループと対話して、AWS での構築方法について対話型学習を行います。各 ビルダーズセッション は、参加者が構築するものについての短い説明またはデモから始まり、その後は構築する番です！専門家がこのハンズオン体験を最初から最後までガイドします。または、 コードトーク に参加してください。これは AWS の専門家がライブコーディングやコードサンプルを特集し、AWS ソリューションの「なぜ」を説明するコード重視のインタラクティブセッションです。参加者は質問をしたり、一緒に進めることが奨励されています。 ワークショップ は、チームで協力するか個別に作業して AWS サービスを使用して実世界の課題を解決する 2 時間のインタラクティブセッションで、ハンズオン学習に最適です。各ワークショップは短い講義から始まり、その後、問題に取り組むための専用の時間が設けられています。 注意: AWS の専門家と一緒に構築するためにラップトップを持参することを忘れないでください。 SEC351 | ビルダーズセッション | Accelerating incident response, compliance &amp; auditing using generative AI (生成 AI を使用したインシデント対応、コンプライアンス、監査の加速) スピーカー: Snehal Nahar (AWS), Ravindra Kori (AWS), Rayette Toles-Abdullah (AWS), &amp; Abhijit Barde (AWS) このセッションでは、Slack などのエンタープライズコミュニケーションツールを使用して、インシデント後の回復時間を短縮するために AWS ネイティブの生成 AI 機能を使用する方法を学びます。また、インシデントにつながる可能性のあるイベントを特定するための検出制御と、インシデントが発生するリスクを軽減するための予防制御の使用方法も学びます。 Amazon Q Developer 、 AWS Config 、 AWS CloudTrail Lake 、 Amazon CloudWatch などのサービスやその他のオブザーバビリティ機能を使用します。 SEC352 | ビルダーズセッション | Agentic AI for security: Building intelligent egress traffic controls (セキュリティのためのエージェント型 AI: インテリジェントな出力トラフィック制御の構築) スピーカー: Ranjith Rayaprolu (AWS), Anil Nadiminti (AWS), Michael Leighty (AWS), &amp; Dwaragha Sivalingam (AWS) クラウドインフラストラクチャを保護する AI 駆動のセキュリティエージェントの構築方法を学びます。このハンズオンセッションでは、Amazon Bedrock と Bedrock エージェントを使用して、ネットワークを監視するインテリジェントシステムを作成する方法を示します。出力トラフィックを監視し、潜在的な脅威を特定し、悪意のあるトラフィックをブロックするためにネットワークファイアウォールを自動的に更新する生成 AI エージェントを構築します。クラウドインフラストラクチャを保護するために推論、決定、行動できる AI 駆動のセキュリティエージェントを実装するスキルを身につけて帰りましょう。 SEC353 | ビルダーズセッション | Threat modeling for generative AI applications (生成 AI アプリケーションの脅威モデリング) スピーカー: Laura Verghote (AWS), Isabelle Mos (AWS), Samuel Waymouth (AWS), &amp; Omar Zoma (AWS) このビルダーズセッションでは、生成 AI アプリケーション特有のセキュリティ脅威を体系的に特定および分析する方法を学びます。組織が大規模言語モデルやその他の生成 AI 機能を急速に採用するにつれて、プロンプトインジェクションからデータ汚染まで、独自のセキュリティ課題を理解することが重要になります。Amazon Bedrock などの AWS サービスを使用して構築されたアプリケーションに特に焦点を当てて、一般的な生成 AI アーキテクチャの脅威モデルを作成するプロセスをガイドします。 SEC451 | ビルダーズセッション | From logs to defense: Generative AI for security automation (ログから防御へ: セキュリティ自動化のための生成 AI) スピーカー: Ravindra Kori (AWS), Siavash Iran (AWS), Lily Ashidam (AWS), &amp; Yiwen Zhang (AWS) この技術セッションでは、AWS ネイティブサービスと生成 AI を使用して、従来のオペレーティングシステムログ分析をインテリジェントな自動防御システムに変換する方法を実演します。Windows および Linux システムからセキュリティ関連のログをキャプチャする包括的なソリューションの構築方法を探ります。 APS351 | ビルダーズセッション | Securing generative AI agents using AWS Well-Architected Framework (AWS Well-Architected フレームワークを使用した生成 AI エージェントの保護) スピーカー: Krupanidhi Jay (AWS), Ryan Dsouza (AWS), Birender Pal (AWS), &amp; Omkar Mukadam (AWS) AWS Well-Architected フレームワークの生成 AI レンズセキュリティベストプラクティスに従って、安全な生成 AI エージェントソリューションを構築する方法をハンズオンで学びます。エンドポイントセキュリティ、プロンプトエンジニアリングガードレール、監視システム、過剰なエージェンシーからの保護の実践的な実装を通じて、本番環境対応の生成 AI エージェントを構築します。ハンズオン演習を通じて、Amazon Bedrock、Amazon CloudWatch、 AWS Identity and Access Management (IAM) などを含むこれらの制御を組み込んだ安全な生成 AI エージェントソリューションを AWS 上に構築します。参加するにはラップトップを持参する必要があります。 APS353 | ビルダーズセッション | Red teaming your LLM security at scale (スケールでの LLM セキュリティのレッドチーミング) スピーカー: Otto Kruse (AWS), Owen Hawkins (AWS), Aaron Brown (AWS), &amp; Jeff Lombardo (AWS) 生成 AI レッドチームチャレンジで AI 駆動のレッドチーム攻撃者の立場に立ちます。この集中ワークショップでは、AI セキュリティエージェントをデプロイして、プロンプトインジェクションから境界テストまで、生成 AI アプリケーションに対する洗練された脅威チェーンを調整し、脆弱性を体系的に発見して悪用しながら、自動化されたセキュリティテストワークフローをマスターします。さらに、プロンプトテンプレートからガードレールまでの対策を適用する方法を学びます。このハンズオン、ゲーム化された体験は、脅威アクターのように考えるのに役立ち、LLM ベースのアプリケーションの一般的な MITRE および OWASP の脆弱性に対する自動化された脆弱性テストとリスク軽減の実践的なスキルを身につけることができます。参加するにはラップトップを持参する必要があります。 GRC354 | ビルダーズセッション | Best practices for using generative AI to manage cloud compliance (クラウドコンプライアンス管理に生成 AI を使用するためのベストプラクティス) スピーカー: Adnan Bilwani (AWS), Ali Maaz (AWS), Artur Rodrigues (AWS), &amp; Peter Pereira (AWS) Amazon Q Developer を活用して AWS Config を使用したクラウドコンプライアンス管理を合理化する方法を学びます。このハンズオンビルダーズセッションでは、生成 AI 機能を使用してインテリジェントなコンプライアンスチェックを作成し、修復ワークフローを自動化し、詳細なコンプライアンスレポートを生成する方法を実演します。実践的な演習を通じて、生成 AI の力と AWS Config の堅牢なコンプライアンスフレームワークを組み合わせた自動化されたコンプライアンス監視を実装する方法を学びます。参加するにはラップトップを持参する必要があります。 IAM451 | ビルダーズセッション | Securing GenAI apps: Fine-grained access control for Bedrock Agents (生成 AI アプリの保護: Bedrock エージェントのきめ細かなアクセス制御) スピーカー: Edward Sun (AWS), Pravin Nair (AWS), Dustin Ellis (AWS), &amp; Kevin Hakanson (AWS) 組織のデータにアクセスする生成 AI アプリケーションを保護したいですか？Amazon Bedrock を活用したアプリケーションが組織のデータにアクセスするためのインテリジェントなアクセス制御を実装する方法を学びます。このビルダーズセッションでは、Amazon Cognito を使用した認証と Amazon Verified Permissions を使用したきめ細かな認可を組み合わせた多層防御アプローチを構築して、Bedrock AI エージェントのアクセスを保護します。生成 AI 機能を制限することなく機密データを保護する階層化されたアクセス許可を実装します。参加するにはラップトップを持参する必要があります。 TDR251 | ビルダーズセッション | Build your first AI security assistant with Amazon Q (Amazon Q で最初の AI セキュリティアシスタントを構築する) スピーカー: Scott Taggart (AWS), Joe Wagner (AWS), Laura Verghote (AWS), &amp; Riggs Goodman III (AWS) Amazon Q Business を使用して最初の AI 駆動のセキュリティアシスタントを構築する方法を発見してください – AI の専門知識は必要ありません。このハンズオンセッションでは、セキュリティの検出結果をコンテキスト化する自動化された Amazon GuardDuty インシデント調査員、ポリシー評価を合理化する AWS Security Hub コンプライアンスレポートジェネレーター、修復を加速する Amazon Inspector ベースの脆弱性管理ヘルパーという 3 つの実用的なセキュリティワークフローを作成します。生成 AI で AWS セキュリティ運用を強化したいセキュリティ実務者に最適で、実践的なアプリケーションを通じて AWS の主要なセキュリティサービスをマスターできます。参加するにはラップトップを持参する必要があります。 IAM441 | コードトーク | The right way to secure AI agents with code examples (コード例で見る AI エージェントを保護する正しい方法) スピーカー: Jeff Lombardo (AWS) &amp; Fei Yuan (AWS) 生成 AI エージェントは人間のユーザーに代わってタスクを実行し、オンプレミス環境や異なるクラウドプロバイダー間で相互に対話することがよくあります。これにより、エージェント型 AI ソリューション全体で ID 認証、伝播、委任、リソース認可に新たな課題がもたらされます。Amazon Cognito の OAuth2 ベースの ID 管理、マシン間認証と、Amazon Verified Permissions のきめ細かな認可を組み合わせることで、人間の ID と同意、エージェントのマシン ID、およびエージェントチェーン全体の他のリクエストコンテキストを保持しながら、AI エージェントの安全な委任パターンを有効にする方法を学びます。Amazon Bedrock または他のフレームワークで構築されたエージェントを使用した実世界の例を紹介します。 TDR341 | コードトーク | Build AI security agents with Amazon Bedrock and Amazon Security Lake (Amazon Bedrock と Amazon Security Lake を使用した AI セキュリティエージェントの構築) スピーカー: Chris Lamont-Smith (AWS) &amp; Pratima Singh (AWS) このコードトークでは、Amazon Bedrock と Amazon Security Lake を使用して AI エージェントを作成することでセキュリティ運用を強化する方法を探ります。ライブコーディングデモを通じて、セキュリティ分析と対応のために自律的な意思決定機能と生成 AI を組み合わせた自動化されたワークフローを構築する方法を学びます。ログを分析し、コンテキストに応じた洞察を提供し、対応手順を実行するエージェントを実装する方法を見てください。セキュリティワークフローにカスタムツールを統合し、大規模言語モデルを活用するための実践的なアプローチを発見してください。 SEC371 | ワークショップ | Red Team approaches to practical generative AI defenses (実践的な生成 AI 防御へのレッドチームアプローチ) スピーカー: Mac Stevens (AWS) &amp; Cameron Smith (AWS) このワークショップでは、Amazon Bedrock、 Amazon SageMaker 、および関連サービスに焦点を当てた生成 AI セキュリティへのハンズオンアプローチを取ります。まず、推論中のデータ保護や、エージェント、ガードレール、ナレッジベースなどの機能におけるデータ保護など、Bedrock の中核的なセキュリティ原則を検討します。参加者は、コンテキストウィンドウ、システムプロンプト、エージェントオーケストレーションなどの内部アーキテクチャとセキュリティへの影響について洞察を得ることができます。その後、セッションは SageMaker を使用したハンズオンのレッドチーミング演習に移行します。その後、これらの脅威ベクトルに対する防御戦略を探り、これらの実践を開発ワークフローに統合する方法について議論します。参加者は、個々のモデル保護から複雑なマルチコンポーネントシステムの保護まで、生成 AI セキュリティの全体的な理解を身につけて帰ることができます。 APS371 | ワークショップ | Securing your generative AI applications on AWS (AWS での生成 AI アプリケーションの保護) スピーカー: Mark Keating (AWS) &amp; Maitreya Ranganath (AWS) このワークショップでは、AWS サービスと機能を使用して生成 AI アプリケーションを保護する方法を発見してください。脆弱なサンプル生成 AI アプリケーションをデプロイし、セキュリティ問題から保護、検出、対応するためのセキュリティ制御を層状に適用する方法を探ります。組織の生成 AI アプリケーションに同様の制御を適用する方法を学びます。参加するにはラップトップを持参する必要があります。 DAP371 | ワークショップ | Defend your AI: Mitigate prompt injection with Amazon Bedrock (AI を守る: Amazon Bedrock でプロンプトインジェクションを軽減する) スピーカー: Anthony Harvey (AWS) &amp; Jeremy Schiefer (AWS) このハンズオンワークショップを通じて、生成 AI システムのプロンプトインジェクション脆弱性を特定および軽減する技術をマスターしてください。Amazon Bedrock を使用して、参加者は本番環境での大規模言語モデルのセキュリティへの影響を理解するために、攻撃的および防御的なプロンプトエンジニアリング技術の両方を探ります。このセッションでは、プロンプトインジェクション攻撃の仕組みを理解し、シミュレートされた AI 環境を悪用しようとする対話型の「キャプチャ・ザ・フラッグ」スタイルのチャレンジを完了し、Amazon Bedrock ガードレールを使用して防御制御を実装する方法を学びます。参加するにはラップトップを持参する必要があります。 今すぐ登録を！ AI 実装のセキュリティについて業界の専門家や AWS のリーダーから学ぶこの機会をお見逃しなく。今すぐ AWS re:Inforce 2025 に登録して、これらのセッションに参加しましょう。他のトラックのセッション、パートナーセッション、コードトークについて詳しく知るには、 re:Inforce カタログ 全体をご覧ください。 この記事に関する質問がある場合は、 AWS サポート にお問い合わせください。 Margaret Jonson Margaret は AWS 生成 AI セキュリティのシニアプロダクトマーケティングマネージャーで、AI/ML チームと協力して、Amazon Bedrock、Amazon SageMaker、Amazon Q、その他の AI/ML ソリューション全体で安全でガバナンスされた AI ソリューションを実装するお客様を支援しています。 Matt Saner AWS のシニアマネージャーとして、Matt は世界で最も複雑な組織が重要なセキュリティ課題に取り組むのを支援するセキュリティスペシャリストのチームをリードしています。Matt とそのチームは、セキュリティ組織を戦略的なビジネスイネーブラーに変革するために取り組んでいます。AWS に入社する前、Matt は金融サービス業界で 20 年近くを過ごしました。仕事以外では、Matt は一般航空機を飛ばすことに喜びを見出すパイロットです。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

地震波イメージングは、地球の内部構造の詳細な画像を作成するために使用される地球物理学的手法です。この手法は、地中に放射すると、さまざまな岩石層や構造に反射して地表に戻る地震波を生成することで機能します。戻った地震波は、ジオフォンやハイドロフォンと呼ばれる精密機器によって検出されます。収集された膨大なデータの量は 1 回の調査でペタバイトに達することが多く、保存、処理、管理に関する重大な課題を研究者やエネルギー企業にもたらします。 このような地震波イメージングのワークロードや、気象予報、先進運転支援システム (ADAS) トレーニング、ゲノム解析といった ハイパフォーマンスコンピューティング (HPC) ワークロードを実行するお客様は、既にオンプレミスのハードディスクドライブ (HDD) ベースのファイルストレージ、または HDD とソリッドステートドライブ (SSD) を組み合わせたファイルストレージに大量のデータを保存しています。しかし、これらのオンプレミスのデータセットとワークロードが拡大する中、ワークロードのパフォーマンスニーズに対応し、ストレージの容量不足を回避するには先行投資を行う必要があるため、お客様はこの手法がますます困難で高額になっているのを実感しています。 5 月 29 日、AWS は Amazon FSx for Lustre Intelligent-Tiering の一般提供を発表しました。この新しいストレージクラスは、実質上無制限のスケーラビリティを提供し、唯一完全な伸縮性を備えた Lustre ファイルストレージで、クラウド内で最もコストが低い Lustre ファイルストレージでもあります。開始価格が GB-月あたり 0.005 USD 未満の FSx for Lustre Intelligent-Tiering は、クラウド内で最も低コストの高性能ファイルストレージを提供し、アクセス頻度の低いデータのストレージコストが他のマネージド Lustre オプションより最大 96% 低くなります。その伸縮性により、データの追加や削除に合わせてファイルシステムも拡大縮小するため、ストレージ容量を事前にプロビジョニングする必要がなくなります。また、支払いも保存するデータの量に対する料金のみです。 FSx for Lustre Intelligent-Tiering は、アクセスパターンに基づいてコールドデータを適切な低コストストレージ階層に階層化することでコストを自動的に最適化し、低レイテンシーが極めて重要なワークロードのパフォーマンスを向上させるオプションの SSD 読み取りキャッシュが含まれています。ギガバイト規模の実験データで使用を開始するか、最も要求の厳しい 人工知能/機械学習 (AI/ML) ワークロードや HPC ワークロードのためのペタバイト規模の大規模データセットを処理するかにかかかわらず、Intelligent-Tiering は優れたパフォーマンスを提供します。ストレージとは無関係にファイルシステムのパフォーマンスを調整する柔軟性を備えた Intelligent-Tiering は、オンプレミスの HDD ファイルシステムよりも最大 34% 優れた価格パフォーマンスを実現します。Intelligent-Tiering ストレージクラスは、ホットデータとコールドデータの組み合わせを使用する、HDD ベースまたは HDD/SSD 混在のワークロード向けに最適化されています。FSx for Lustre Intelligent-Tiering には、アプリケーションの変更なしでこのようなワークロードを移行して実行できるので、ストレージ容量の計画と管理が不要になり、支払いは使用したリソースに対する料金のみになります。 このリリース以前、お客様は FSx for Lustre SSD ストレージクラスを使用して、オール SSD ストレージのパフォーマンスと全データに対する一貫的な低レイテンシーアクセスを必要とする ML ワークロードと HPC ワークロードを高速化していました。しかし、多くのワークロードにはホットデータとコールドデータが混在しており、コールド寄りのデータにオール SSD ストレージは必要ありません。FSx for Lustre は、グラフィックスプロセッシングユニット (GPU) 利用率を向上させるために AI/ML ワークロードで使用されることがますます増えています。このようなワークロードのオプションの 1 つとなるべく、FSx for Lustre のコストがさらに最適化されました。 FSx for Lustre Intelligent-Tiering データは、ユーザー操作なしで 3 つのストレージ階層 (高頻繁アクセス、低頻度アクセス、アーカイブ) 間を移動するため、初期費用や事前のコミットメントなしで自動的にコストを削減できます。階層化は次のような仕組みになっています。 高頻度アクセス – この階層には過去 30 日以内にアクセスされたデータが保存されます。 低頻度アクセス – この階層には 30～90 日間アクセスされなかったデータが保存され、高頻度アクセスよりもコストが 44% 低くなります。 アーカイブ – この階層には 90 日以上アクセスされなかったデータが保存され、低頻度アクセスよりもコストが 65% 低くなります。 単一の物理的ロケーション内に限定されることが一般的な通常のオンプレミス実装とは異なり、ユーザーのデータは、そのストレージ階層にかかわらず、冗長性と可用性のために複数の AWSアベイラビリティーゾーン に保存されます。さらに、データはミリ秒単位で瞬時に取得できます。 ファイルシステムの作成 ファイルシステムは、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、API、または AWS CloudFormation を使用して作成できます。コンソールで [ファイルシステムを作成] を選択して作成を開始します。 [Amazon FSx for Lustre] を選択してから [次へ] を選択します。 ここで、ファイルシステムを作成するための残りの情報を入力します。ファイルシステムの名前 ( veliswa_fsxINT_1 ) を入力し、[デプロイとストレージクラス] には [永続的な インテリジェント階層化] を選択します。希望する [スループットキャパシティ] と [メタデータ IOPS] を選択します。 [SSD 読み取りキャッシュ] は、指定したスループットキャパシティに基づいて FSx for Lustre が自動的に設定します。残りはデフォルトのままにしておいて [次へ] を選択し、選択内容を確認してからファイルシステムを作成します。 Amazon FSx for Lustre Intelligent-Tiering を使用することで、基盤となるストレージ容量を事前にプロビジョニングしなくても、ワークロードに必要なパフォーマンスをプロビジョニングする柔軟性が得られます。 作成後にどの値を編集できるか知りたかったので、ファイルシステムの作成を完了する前に設定をしっかり確認しておいたところ、スループットキャパシティ、メタデータ IOPS、セキュリティグループ、SSD 読み取りキャッシュ、およびその他いくつかの設定を後で編集できることがわかりました。ML ジョブの実行を開始した後で、処理するデータ量に応じてスループットキャパシティを増やす必要が生じることもあるため、この情報は私にとって重要です。 これで、ファイルシステムが利用可能になりました。今後 HPC ワークロードを実行することを考えると、これから大量のデータを処理することが見込まれるため、スループットキャパシティを 24 Gb/秒 に増やします。増やしたとしても、支払うのは使用したリソースの料金のみです。 SSD 読み取りキャッシュは、パフォーマンスニーズの増加に応じて自動的にスケールします。キャッシュサイズは、ユーザープロビジョニングモードでいつでも個別に調整できます。低レイテンシーアクセスが必要ない場合は読み取りキャッシュを無効化することもできます。 知っておくと便利な情報 FSx for Lustre Intelligent-Tiering は、1 秒あたり最大で数テラバイトの総スループットを実現するように設計されています。 Elastic Fabric Adapter (EFA) /GPU Direct Storage (GDS) をサポートする FSx for Lustre は、クライアントあたりのスループットが以前の FSx for Lustre システムよりも最大 12 倍 (最大 1200 Gbps) 高くなっています。 書き込みとキャッシュ読み取りでは、最大で数千万 IOPS を実現できます。SSD 読み取りキャッシュ内のデータの TTFB (Time to First Byte) レイテンシーはミリ秒未満で、その他すべてのデータの TTFB レイテンシーも数十ミリ秒の範囲です。 今すぐご利用いただけます この新機能には、いくつかの留意点があります。 FSx Intelligent-Tiering ストレージクラスは、米国東部 (バージニア北部、オハイオ)、米国西部 (北カリフォルニア、オレゴン)、カナダ (中部)、欧州 (フランクフルト、アイルランド、ロンドン、ストックホルム)、アジアパシフィック (香港、ムンバイ、ソウル、シンガポール、シドニー、東京) の各 AWS リージョン にある新しい FSx for Lustre ファイルシステムで利用できます。 料金については、ファイルシステムに保存するデータとメタデータに対する料金 (GB/月)、データを書き込むとき、または SSD 読み取りキャッシュ内にないデータを読み取るときの操作ごとの料金、およびファイルシステムにプロビジョニングする合計スループットキャパシティ (MBps/月)、メタデータ IOPS (IOPS/月)、データとメタデータ用の SSD 読み取りキャッシュのサイズ (GB/月) に対する料金を支払います。詳細については、「 Amazon FSx for Lustre の料金 」ページをご覧ください。この機能を含めた Amazon FSx for Lustre の詳細については、「 Amazon FSx for Lustre 」ページをご覧ください。 Amazon FSx コンソールで Amazon FSx for Lustre Intelligent-Tiering を今すぐお試しください。 Amazon FSx for Lustre の AWS re:Post や通常の AWS サポート連絡先経由でのフィードバックもお待ちしています。 – Veliswa 原文は こちら です。 ニュースブログはいかがでしたか? こちらの 1 分間のアンケートにぜひご協力ください ! (この アンケート は外部企業に委託して行われます。AWS は、 AWS プライバシー通知 に記載された内容に従って、お客様の情報を取り扱います。AWS は、このアンケートを通じて収集したデータを所有し、収集した情報をアンケートの回答者と共有することはありません)