6 月 16 日より、 AWS re:Inforce 2025 が開幕します。このイベントでは、セキュリティのプロフェッショナルが一堂に会し、3 日間にわたる技術学習セッション、ワークショップ、デモンストレーションに参加します。セキュリティに特化したこのカンファレンスには、組織がクラウドセキュリティのニーズを満たすために利用するサービスを構築および保守する AWS セキュリティスペシャリストが集まります。 AWS の Chief Information Security Officer (CISO) である Amy Herzog がカンファレンスの 基調講演 を行い、ゲストスピーカーは新しいセキュリティ機能と実装に関するインサイトを共有します。このイベントは、さまざまな技術的役割や専門知識レベルに合わせて設計されたセッションを含む複数の学習パスを提供します。AWS の多くの同僚が、ハンズオンワークショップを主導して、新しいセキュリティ機能のデモンストレーションを行うとともに、コミュニティの議論を促進します。 フィラデルフィアでご参加いただけない方のために、基調講演とイノベーショントークは、 イベントの開催中にライブストリーム で視聴でき、イベント終了後はオンデマンドで視聴できます。カンファレンスでの重要な発表や技術的なインサイトについては、今後の記事でお知らせしますので、どうぞご期待ください! 6 月 9 日週のリリース 私が注目したリリースをご紹介します。 MCP ツールで Amazon Q Developer IDE プラグインを拡張 – Amazon Q Developer は、統合開発環境 (IDE) プラグインで Model Context Protocol (MCP) をサポートするようになりました。これは、デベロッパーがコンテキストを踏まえた開発ワークフローを強化するために、外部ツールを統合するのに役立ちます。stdio トランスポート層をサポートする任意の MCP サーバーを使用して、組み込みツールを拡張できるようになりました。これらのサーバーは、Amazon Q Developer ユーザーインターフェイス内で管理できます。これにより、ツールの許可の追加、削除、変更が容易になります。この統合により、ネイティブツールと MCP サーバーベースのツールの両方でタスクをオーケストレートすることで、よりカスタマイズされた応答が可能になります。MCP サポートは、Visual Studio Code および JetBrains IDE プラグイン、ならびに Amazon Q Developer コマンドラインインターフェイス (CLI) でご利用いただけます。詳細なドキュメントと実装ガイドは、 Amazon Q Developer ドキュメント で入手できます。 AWS WAF が自動アプリケーション層 DDoS 保護のサポートを開始 – AWS は、アプリケーション層 (L7) の分散型サービス拒否 (DDoS) 保護機能を強化し、イベントに数秒以内に応答する高速な自動検出と緩和機能を追加しました。この AWS マネージドルールグループは、あらゆる期間の DDoS 攻撃を自動的に検出して緩和し、Amazon CloudFront、Application Load Balancer、および他の AWS WAF がサポートするサービスで実行されているアプリケーションがユーザーにとって使用可能であり続けるよう維持します。システムは、機械学習 (ML) モデルを使用してアクティベーションから数分以内にベースラインを確立し、トラフィックの異常を検出します。その後、疑わしいリクエストに対処するためのルールを自動的に適用します。設定オプションは、チャレンジの提示やリクエストのブロックなどの応答をカスタマイズするのに役立ちます。この機能は、アジアパシフィック (タイ)、メキシコ (中部)、中国 (北京および寧夏) を除く、サポートされているすべての AWS リージョンにおいて、すべての AWS WAF および AWS Shield Advanced サブスクライバーで使用できます。AWS WAF アプリケーション層 (L7) DDoS 保護の詳細については、 AWS WAF ドキュメント または AWS WAF コンソール にアクセスしてください。 AWS Control Tower がサービスにリンクされた AWS Config マネージド AWS Config ルールのサポートを開始 – AWS Control Tower は、以前の CloudFormation StackSets のデプロイ方法に代えて、サービスにリンクされた AWS Config ルールをマネージドアカウントで直接デプロイするようになりました。この変更により、複数の AWS Control Tower マネージドアカウントとリージョンにわたってサービスにリンクされた AWS Config ルールを有効にする場合のデプロイ速度が向上します。これらのサービスにリンクされたルールは AWS サービスによって完全に管理され、ユーザーが編集または削除することはできません。これは、一貫性を維持し、設定のドリフトを防ぐのに役立ちます。AWS Control Tower Config ルールは、アカウント内のリソースの非準拠を検出し、ダッシュボードを通じてアラートを提供します。これらのコントロールは、 AWS Control Tower コンソール または AWS Control Tower コントロール API を使用してデプロイできます。 Powertools for AWS Lambda に Bedrock Agents Function ユーティリティが導入されました – Powertools for AWS Lambda の新しい Amazon Bedrock Agents Function ユーティリティは、Amazon Bedrock エージェントと統合されたサーバーレスアプリケーションの構築を簡素化します。このユーティリティは、デベロッパーが組み込みのパラメータ挿入と応答フォーマットを使用して Amazon Bedrock エージェントのアクションリクエストに応答する AWS Lambda 関数を作成するのに役立ち、ボイラープレートコードが不要になります。このユーティリティは Logger や Metrics などの他の Powertools 機能とシームレスに統合するため、本番対応の AI アプリケーションをより容易に構築できます。この統合により、AWS Lambda 関数を使用して Amazon Bedrock エージェントによってリクエストされたアクションを処理するエージェントベースのソリューションを構築する際のデベロッパーエクスペリエンスが改善されます。このユーティリティは、Powertools の Python、TypeScript、.NET バージョンで使用できます。 pgactive のオープンソース化を発表: PostgreSQL のアクティブ/アクティブレプリケーション拡張機能 – pgactive は、データベースインスタンス間でデータをストリーミングするための非同期アクティブ/アクティブレプリケーションを可能にする PostgreSQL 拡張機能であり、AWS がオープンソース化しました。この拡張機能は、異なるリージョンにあるライターを含むインスタンス間のデータ移動において、回復力と柔軟性を高めます。これは、書き込みトラフィックの切り替えなどのオペレーション中の可用性の維持に役立ちます。PostgreSQL の論理レプリケーション機能を基盤とする pgactive は、アクティブ/アクティブレプリケーションのシナリオの管理を簡素化する機能を追加します。このオープンソースアプローチは、PostgreSQL のアクティブ/アクティブ機能の開発におけるコラボレーションを促進するとともに、マルチアクティブインスタンス環境での PostgreSQL の使用を効率化する機能を提供します。詳細と実装ガイダンスについては、 GitHub リポジトリ にアクセスしてください。 AWS からのお知らせの詳細なリストについては、「AWS の最新情報」ページを随時ご確認ください。 追加のリージョンで既存のサービスとインスタンスタイプの提供を開始しました: AWS Glue がアジアパシフィック (台北) リージョンで利用可能に – AWS Glue は、分析、ML、アプリケーション開発のためのデータの検出、準備、結合を簡素化するサーバーレスデータ統合サービスです。 欧州 (アイルランド) で Amazon EC2 I8g インスタンスの提供を開始 – Amazon EC2 I8g インスタンスは、ストレージを多用するワークロードのために、Amazon EC2 で最も優れたパフォーマンスを提供します。 Amazon VPC IP Address Manager がアジアパシフィック (台北) リージョンで利用可能に – Amazon VPC IPAM を利用すると、AWS ワークロードの IP アドレスの計画、追跡、モニタリングがより容易になります。 その他の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 コラボレーションスペースであり、没入型エクスペリエンスでもある AWS GenAI Lofts  は、クラウドコンピューティングと AI に関する AWS の専門知識を紹介し、AI 製品やサービスを実際に使用する機会、業界リーダーとの独占セッション、投資家や同業他社との貴重なネットワーキングする機会をスタートアップや開発者に提供します。  お近くの GenAI Loft 開催地を見つけて 、忘れずに登録しましょう。 AWS Summit は、クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントです。お近くの都市でご登録ください: ミラノ (6 月 18 日)、 上海 (6 月 19 日～20 日)、 ムンバイ (6 月 19 日)、 日本 (6 月 25 日～26 日)。 近日開催予定のすべての AWS 主導の対面およびバーチャルイベントは、こちら でご覧ください。 6 月 16 日週のニュースは以上です。6 月 23 日週の Weekly Roundup もお楽しみに! — Esra この記事は、 Weekly Roundup  シリーズの一部です。毎週、AWS からの興味深いニュースや発表を簡単にまとめてお知らせします! 原文は こちら です。

このブログ記事では、コードの保守性を評価するための基準を概説し、 AWS Blu Age がメインフレームアプリケーションを保守可能なオブジェクト指向の Java にどのように変換するか説明します。 AWS Blu Age を利用すると、お客様はメインフレームアプリケーションを Java Spring アプリケーションに変換できます。このトランスフォーメーションは、技術的な問題を解決するだけでなく、ビジネスのトランスフォーメーションも可能にします。新しく着任した開発者が、担当する Java アプリケーションに取り組むことができる状態になっていないと、モダナイゼーションの取り組みは行き詰まり、モダナイゼーション後の作業の大半がメンテナンスに集中したままになります。 COBOL から Java へのプログラム変換や同様のリファクタリングサービスを調査検討すると、JaBOL のような用語がよく出てきます。JaBOL という用語は COBOL の構造を模倣した Java コードを指し、多くの場合、移行元のコードのロジックが理解されないままの状態であることの表れです。AWS Blu Age は、モデルからモデルへの変換、再利用可能なクラス、非手続き型パターンによって JaBOL を回避するコードを生成し、よりクリーンでモダンで保守しやすい実装を実現しています。 可読性 コードは、明確な命名規則に従って、コードの目的やロジックの説明に関して意味のあるコメントを備えた、読みやすく理解しやすいものでなければなりません。プロジェクト全体で一貫したコーディングスタイルがあれば、開発者の認知負荷が軽減され、コードベースの操作が容易になります。 AWS Blu Age の Transformation Engine は、プロジェクト全体を通して一貫したコーディングスタイルに従い、読みやすくわかりやすいコードを生成します。 AWS Blu Age がモダナイズしたアプリケーションは Java Web アプリケーション (WAR) としてパッケージ化されており、どの Java EE サーバーにもデプロイできます。通常、サーバーは Spring Boot と Angular フレームワーク上に構築された AWS Blu Age ランタイムを組み込んだ Tomcat インスタンスです。 基本的な Java プロジェクトは、以下のように構成されます。 Entities プロジェクト — ビジネスモデルとコンテキスト要素が含まれています。プロジェクト名は通常「-entities」で終わります。これはレガシー COBOL プログラムの INPUT-OUTPUT SECTION (データセット) と DATA DIVISION のモダナイゼーションに相当します。一つのアプリケーションに複数の Entities プロジェクトを含むことができます。 Service プロジェクト — 従来のビジネスロジックのモダナイゼーション要素が含まれています。これは COBOL プログラムの PROCEDURE DIVISION に相当します。一つのアプリケーションに複数の Service プロジェクトを含むことができます。 Utility プロジェクト — 他のプロジェクトで使用される共通のツールやユーティリティが含まれています。 Web プロジェクト — UI があるアプリケーションの場合は、モダナイズされた UI 関連の要素が含まれます。これらの UI 要素は、CICS BMS マップ、IMS MFS コンポーネント、およびその他のメインフレーム UI ソースから取得されます。一つのアプリケーションに複数の Web プロジェクトを作成できます。 各構成要素のトランスフォーメーション前後の対応関係を捉えやすくするために、各 Java クラスは、対応する COBOL プログラムの名前を踏襲しています。リファクタリング中、AWS Blu Age の Transformation Engine は変数と関数にお客様固有の命名規則を適用します。各プロジェクトは Apache Maven をビルドの自動化とプロジェクト管理に活用し、一貫した構造と一元的な依存関係管理を実現しています。 モジュール性 個々のモジュール、クラス、および関数は、それぞれシステムの特定の側面を処理するよう、コードを構成する必要があります。このモジュール型のアプローチにより、システム全体に影響を与えずに個々のコンポーネントを更新でき、コンポーネントの再利用が可能になり、重複が減り、保守性が向上します。 AWS Blu Age は、COBOL のモノリシックな構造とは異なり、オブジェクト指向設計のベストプラクティスに従い、複数のレイヤーに編成されたコードを生成します。その構造は以下のようになります。 COBOL の DATA DIVISION は、複数のエンティティに変換されます (01/77 レベルの COBOL データ構造ごとに 1 つ)。コンテキストクラスが生成され、すべてのエンティティが COBOL の実行ユニットコンテキストの概念を再現する 1 つの Java オブジェクトにグループ化されます。プログラムの呼び出し時にコンテキストを復元する必要が生じた場合は、シリアライズ/逆シリアライズできます。 各プログラムには固有の Configuration クラスがあり、プログラムごとに動作をカスタマイズできます。たとえば、アプリケーション内で、あるプログラムは ASCII データを処理するよう設定し、別のプログラムは EBCDIC データを処理するよう設定することができます。 COBOL の PROCEDURE DIVISION は、Spring 等のモダンなアプリケーションで使用されている DI (Dependency Injection) フレームワークに則り、interface を実装する Service クラスに変換されます。COBOL のパラグラフは、標準的な Java のメソッドになります。 最後に、プログラムの名前を持つクラスが、上述の独立した各クラス間を繋ぎます。このクラスは run メソッドを公開しており、呼び出されると最新バージョンのプログラムが実行されます。 このアーキテクチャでは、同一のデータ構造が 1 つのクラスに統合されるので、コードの重複が減り、メンテナンスが容易になります。 複雑さ コードの複雑さは、主に循環的複雑度とコードの重複によって測定されます。 循環的複雑度 — コード内の独立したパスの数を測定します。一般に、複雑度が低いということは、コードの理解、テスト、および保守に必要な労力が最小限であることを示します。複雑度が高いと、コードにバグが発生しやすくなり、変更が難しくなります。 コードの重複 — 繰り返されるコードは最小限に抑える必要があります。重複していると、変更を複数の場所に反映する必要があるため、メンテナンスの負担が増えます。重複したコードを関数やクラスにリファクタリングすると、保守性が向上します。 モダナイズされたコードは、レガシーシステムの複雑さをいくらか受け継いでいます。とはいえ、モダナイズされたコードの方が COBOL よりも読みやすく、クラスやオブジェクトおよびメソッド等の定義や参照先を辿り易くなっています。これは、メソッドのナビゲーション、インデント、構文がより明解になったことによるものです。たとえば、COBOL の END-IF やドットメカニズム (文の終端にピリオド「.」を書くこと) と比べると、if / else ステートメントには中括弧 { … } が使われます。 AWS Blu Age でリファクタリングしたコードは Java Spring の標準的なコーディングルールすべてに準拠しているため、どんな Java 開発者でもすぐにコードの中身に入って行き、詳しく調べることができます。 複数のレイヤーがあり、それぞれが特定のアーキテクチャレイヤーに焦点を当てている 標準の getter / setter を持つオブジェクト interface と実装を分離する Spring のデザインパターン Fluent API に支えられたフレームワーク 設定情報をプログラムから分離して設定ファイルに外出しすることで、必要なときに設定情報に素早くアクセスして変更することができる。たとえば、設定ファイルに外出しした SQL クエリや、YAML での設定など。 トランスフォーメーション中に、複雑な制御フローアルゴリズムを使用して、各プログラムの動作を把握します。AWS Blu Age ツールチェーンは、コード実行シミュレーションを使用して実行可能なパスを見つけ、モダンなコードで必要になるものだけを処理するようにしています。このプロセスのおかげで、COBOL の「GO TO」構文の動作を維持しつつ、COBOL パラグラフを Java メソッドに変換することで、移行元のプログラム構造を残しています。 進化可能性 コードは、最小限の労力で変更に対応できるように設計する必要があります。コンポーネント間は疎結合にする必要があります。つまり、システムのある部分の変更が他の部分に与える影響を最小限に抑える必要があります。 モダナイゼーション後に改修を実施することで、モダンな言語のすべての機能が利用できるようになり、モダンなアプリケーションですぐに有効化できるようになります。 使用されているエンティティ (COBOL データ構造に由来する) は JSON 互換であるため、Spring の機能とアノテーションを活用して、わずか数分で JSON ペイロードをもつモダンな HTTP エンドポイントとしてプログラムを公開できます。結果として、アプリケーションのソースコードを API ベースのソリューション、メッセージングシステム、その他の最新テクノロジーとシームレスに統合できます。 生成されるコードは一定の Java イディオムで構成され、どのコードも同じコーディングパターンに従います。以下は、簡単に実装できる一般的な変更の例です。 新しい特定の動作をアプリケーション全体に一律実装する必要がある場合 : Spring が AspectJ で提供する アスペクト指向プログラミング (AOP) を使用して、アプリケーション全体に実装します。 データアクセスルーチンが、本番 (実データ) とテスト (スタブデータ) では異なる動作をする必要がある場合 : 生成されたコードが Java の interface を使うので、テスト用の実装を作成し、プロファイル (本番/テスト) に基づいて異なる Bean を使うよう Spring を構成します。 無限ループプログラムを使って IBM MQ メッセージの取得と応答を行っている場合 : メッセージ処理に Spring Integration を使用するようにコードをリファクタリングします。これによって、従来の順次処理に代わって、トラフィックに基づいてメッセージを並行して処理するスケーラブルなリスナーを実現します。 既存のバッチの実行時間を改善する必要がある場合 : 既存のコードを Java Runnable に直接ラップし、Spring の TaskExecutor の概念と Java Future オブジェクトを使用した並列化を追加します。 AWS Blu Age で作成された Java コードは、モダンなコーディングのベストプラクティスに従った、標準的な Java コードです。これにより、他の標準的な Java プロジェクトと同様に、移行後のコードをさらに進化させて複雑さを軽減し、保守性を向上させることができます。 コードレビューと品質保証 SonarQube のような静的解析ツールは、エラー、セキュリティの脆弱性、コーディング標準からの逸脱を検出することにより、コードの品質と保守性を保証します。 AWS Blu Age は、コード品質を判定するための主な指標として、静的コード解析ツールである SonarQube を使用します。SonarQube はコードベースを実行せずにスキャンし、開発プロセスの早い段階でバグ、セキュリティの脆弱性、潜在的なパフォーマンス上の問題を特定します。バグ、テストカバレッジ、コードの複雑さなどの重要な指標にしきい値を設定することで、「品質ゲート」を通じて標準を適用します。 AWS Blu Age における SonarQube の主な機能: コードの重複と保守性の問題に関する洞察を提供します OWASP Top 10 などの標準を使用してセキュリティの脆弱性を検出します 不適切なプラクティスや設計を示す兆候となるようなコードを特定します 特定のプロジェクト要件に合わせてルールとしきい値をカスタマイズできます AWS Blu Age でモダナイズされたコードは、お客様の SonarQube プロファイルを使用して解析しても確実に AAAA 評価を得られるようにし、業界標準を満たす高品質で保守しやすいコードになることを保証します。 ドキュメント化 保守に必要なドキュメントとして、次の 2 種類のものが考えられます。 インラインコメント — 複雑なロジック、アルゴリズム、または自明ではない決定を説明するコメントがコード内に必要不可欠です。コメントは、冗長だったり、自明なコードを説明したりするべきではありません。 外部ドキュメント — API リファレンス、アーキテクチャ図、使用ガイドなどの包括的なドキュメントは、新規開発者がシステムを理解し、効果的に貢献するのに役立ちます。 AWS Blu Age のトランスフォーメーションプロセスでは、元のプログラム内でロジックの説明に記述されているコメントをそのまま引き継ぎ、インラインコメントとしてコード内に残します。 JDK に含まれている Javadoc を使うと、他の開発者が追跡し理解できるような一貫したスタイルのドキュメントを作成できます。Web ベースの HTML ドキュメントを生成することで、開発者はコードベースのドキュメントを簡単に参照および検索できます。AWS Blu Age は、各機能を適切に文書化し、将来の開発やデバッグ作業で理解しやすくするため、コードの保守に役立ちます。 テスト容易性 単体テストで個々のコンポーネントを簡単にテストできるよう、コードを記述する必要があります。そのためには、多くの場合、疎結合で、明確なインターフェースを備えたコードを設計する必要があります。単体テスト、統合テスト、回帰テストを含む包括的なテスト自動化により、コードの変更によってバグが発生しないことが確認できると、メンテナンスが容易になります。 リファクタリングされたコードには、明確なインターフェースがあり、疎結合であるため、単体テストコードの生成が容易になります。JUnit、EvoSuite、JUnit-QuickCheck などのツールは、コードに基づいて単体テストケースを自動的に生成できます。また、JaCoCo などのツールを使用すると、テストの都度コードカバレッジを分析したり、追加のテストケースが必要な領域を特定したりできます。 AWS は、アプリケーションテストを大規模に記録、再生、比較するためのサービスである AWS Mainframe Modernization Application Testing を提供しています。これにより、アプリケーション機能のテスト再生、比較、検証のためのテストワークフローを高度に自動化して作成できます。 まとめ AWS Blu Age はメインフレームアプリケーションの俊敏性を高め、メインフレームのモノリスからアジャイルな マクロサービス へ進化させることができます。すると、お客様はモダンな開発環境を採用できるようになり、生産性が向上し、ブロッカーを排除できます。開発とテストは、機能ごとに独立して柔軟に行えるようになります。その結果、市場投入までの時間が短縮され、変更にかかるコストが削減されます。レガシーテクノロジーに熟練した人材の退職に伴うリスクも軽減されます。AWS Blu Age によって移行したアプリケーションは、マイクロサービスの導入によってモダナイゼーションの次の段階に進むことができ、メインフレームアプリケーションに AI を活用し、AWS クラウドサービスと統合することができるようになります。 AWS Blu Age に関するその他の参考情報: AWS Blu Age 認定: https://bluinsights.aws/certification/ ドキュメンテーション: https://bluinsights.aws/docs/transformation-center-create-a-project/ メインフレーム・モダナイゼーションの お客様事例とその他のソリューション Yann Kindelberger Yann Kindelberger は、アマゾンウェブサービスの Principal Solution Architect です。Yann は 23 年以上メインフレームに携わり、IBM で 20 年以上メインフレームアーキテクトとして勤務しました。彼はメインフレームの AWS クラウドへの移行とモダナイゼーションに取り組んでいるワールドワイドなチームの一員です。彼は 2021 年に AWS に入社し、ソリューションアーキテクトとして、お客様のメインフレームの移行とモダナイゼーションを支援し、助言し、サポートしています。 Arnaud Perrier Arnaud はアマゾンウェブサービスの Senior Software Development Engineer です。Arnaud は、主に AWS Blu Age ツールセットを使用したリファクタリングパターンに関するメインフレーム/ミッドレンジのモダナイゼーション活動 (プリセールス、採用、認定、専門知識) に 15 年以上携わってきました。彼の役割は、お客様のモダナイゼーションジャーニーを支援し、パートナーと広範に連携し、サービスチームやデリバリーチームが高度な技術的課題を解決できるようサポートすることです。 Chiranjeev Mukherjee Chiranjeev は AWS のメインフレームモダナイゼーション担当 Sr. Specialist Solution Architect です。Chiranjeev は、メインフレームで約 20 年間働いており、主に世界中のお客様を対象としたメインフレームのモダナイゼーションイニシアチブにフォーカスしてきました。現在の役職では、メインフレームとレガシーシステムに AWS の価値提案を最大限に活用する方法について、お客様やパートナーに助言しています。 Sylvain Eveillard Sylvain はメインフレームモダナイゼーションにおいて 15 年以上の経験があります。彼はユニークな言語/プラットフォーム（Open VMS / GS21 / Natural-Adabas / 階層型データベースまたはネットワークデータベース）でのプロジェクトや製品設計に関する専門知識を持っています。 Tim Gray Tim は AWS の Worldwide Go-to-market Specialist で、メインフレームとレガシーのモダナイゼーションを専門としています。Tim は世界中のお客様やパートナーと協力して、メインフレームアプリケーションをトランスフォーメーションするための革新的な戦略を開発しています。Tim はメインフレームモダナイゼーション業界に 7 年以上携わり、Astadia（Amdocs により買収）と IBM に勤務してきました。AWS では、お客様やパートナーがより早く結果を出せるよう支援する、拡張性の高いモダナイゼーション戦略の構築に注力しています。 この投稿の翻訳は Mainframe Modernization Specialist Solutions Architect の皆川が担当致しました。原文記事は こちら です。

はじめに 2024年、経済産業省は  GENIAC（Generative AI Accelerator Challenge）  を立ち上げました。これは、企業に資金、メンタリング、そして基盤モデル開発のための 大規模なコンピューティングリソース を提供することで生成AIを推進する国家プログラムです。AWSはGENIACの第二期において、一括調達方式のクラウドプロバイダーとして選定されるとともに、個別調達方式でGENIACに参加する事業者からの計算リソース需要にも対応しました。結果として、12の事業者に向けて基盤モデル開発のための計算リソースと、AIアクセラレータークラスタ構築・運用支援を主とする技術支援を提供させていただきました。技術支援という観点では表面的には、各チームに数百のGPU/Trainiumを提供するというシンプルな課題のように見えましたが、実際には 基盤モデル（FM）のトレーニングには、単なるハードウェア以上の要素が必要 でした。 AWSは、 1000以上のアクセラレーターの割り当ては始まりに過ぎない ことを早期から認識していました。真の課題は、信頼性の高いインフラストラクチャ・ソフトウェアスタックの構築、ユーザーへの知識共有、分散トレーニングの障害克服にありました。GENIAC第2サイクルでは、12の顧客が1日で 127台の Amazon EC2 P5インスタンス （NVIDIA H100 TensorCore GPUサーバー）と24台の Amazon EC2 Trn1インスタンス （AWS Trainiumサーバー） をデプロイし、その後の6ヶ月間で、各社複数の大規模モデルがトレーニングされました。 この記事では、その取り組みから得られた重要な教訓を共有します。これらは、大規模な基盤モデルを構築しようとする企業や他の国家イニシアチブに適用できる貴重な知見です。 Cross Functional なエンゲージメントチーム GENIACの取り組みに対してAWSがどういった支援を提供できるかを検討する中で得られた重要な初期の教訓は、複数組織による国家規模のMLイニシアチブを実行するには、AWS内部の多数のチームが協業して支援を提供する必要があるということでした。このため AWSは、アカウントチーム、Specialist SA/BD、サポート担当者、サービスチームを統合した Virtual Team（“v-team”） を設立しました。GENIACに向けたエンゲージメントモデルは、顧客と多層的なAWSチーム構造との緊密なコラボレーションを基盤としています。 顧客（Cx） は通常、ビジネスリード、テクニカルリード、MLまたはプラットフォームエンジニアで構成され、トレーニングワークロードの実行を担当します。 AWS Account Team（ソリューションアーキテクトとアカウントマネージャー） は関係性の管理、ドキュメントの維持、顧客と内部スペシャリストとのコミュニケーションフローを確保します。 World Wide Specialist Organization（WWSO）Frameworksチーム は、このエンゲージメント構造の確立と、プログラム内の技術的エンゲージメントの監督を担当します。彼らは他のステークホルダーとパートナーシップを組み、エンゲージメントをリードし、他のステークホルダーのためのエスカレーションポイントとして機能します。彼らは サービスチーム（Amazon EC2、Amazon S3やAmazon FSx for LustreなどのStorageサービス、Amazon SageMaker HyperPod） と直接連携し、エンゲージメント、エスカレーション（ビジネスおよび技術的）、エンゲージメントフレームワークの正常な動作を確保します。彼らは顧客にトレーニングと推論に関するガイダンスを提供し、他のチームに技術を教育します。WWSO Frameworksチームは GENIACに向けた支援体制で特に設定した役割であるリードソリューションアーキテクト（Lead SA） と密接に連携しました。これらのリードSAは、このエンゲージメントの基盤となる存在です。彼らはFrameworksスペシャリストチームと協力しながら、顧客とアカウントチームと直接連携します。彼らは顧客と直接対話しながら、詳細な技術的議論やトラブルシューティングの際には Frameworks チームの対応者と連携します。この階層構造により、AWSは複雑な基盤モデルトレーニングワークロードにわたって技術的ガイダンスを効果的にスケールさせることができます。 GENIACのもう一つの重要な成功要因は、顧客とAWSメンバー間の堅牢なコミュニケーションチャネルの確立でした。私たちのコミュニケーション戦略の基盤は、GENIAC支援のための専用の 内部Slackチャネル で、AWSアカウントチームとLead SA、Frameworks team が連携します。このチャネルは、リアルタイムのトラブルシューティング、ナレッジ共有、事業者の問題を適切な技術スペシャリストやサービスチームメンバーへの迅速なエスカレーションを可能にしました。これを補完するのが、AWSチームと事業者を橋渡しする 外部Slackチャネル で、参加者が質問をし、洞察を共有し、即時の技術支援を受けられる協力的な環境を作り出しました。この直接的なコミュニケーションラインは、解決時間を大幅に短縮し、参加者間の実践コミュニティを育みました。 私たちは、各顧客のトレーニング実装の詳細（モデルアーキテクチャ、分散トレーニングフレームワーク、関連するソフトウェアコンポーネント）とインフラストラクチャの仕様（インスタンスタイプと数量、ParallelClusterまたはHyperPodデプロイメントのクラスター設定、FSx for LustreやS3などのストレージソリューション）を Tracking Document として文書化しました。こうした文書を用いることで、各事業者のプロジェクトの詳細や、過去のやり取りと、サポートケースの状況等を透過的に把握できました。 この構造化されたコミュニケーションとドキュメントのアプローチにより、私たちは共通の課題を特定し、チーム間でソリューションを共有し、サポートモデルを継続的に改善することができました。詳細な追跡システムは、将来のGENIACサイクルのための貴重な洞察を提供し、顧客のニーズを予測し、基盤モデル開発プロセスにおける潜在的なボトルネックを先行的に対処するのに役立ちました。 リファレンスアーキテクチャ もう一つの重要な洞察は、 基盤モデル開発に特化したリファレンスアーキテクチャの重要性 でした。各事業者が独自のクラスターを一から立ち上げる必要がないよう、AWSは2つの主要なアプローチ AWS ParallelCluster （Self-managed の HPC クラスタ管理ツール）と Amazon SageMaker HyperPod （Managed の回復力のあるクラスターサービス用）のための 事前検証済みリファレンスアーキテクチャ を開発しました。これらのリファレンスアーキテクチャは、ネットワークとストレージからコンテナ実行環境とモニタリングなど、分散学習実行に必要な機能をカバーしています。 これらのリファレンスアーキテクチャは  GitHub レポジトリ（ awsome-distributed-training ） 上で提供され、チームが最小限の工数でデプロイできるようになっています。 このリファレンスアーキテクチャは、Computing、Networking、Storage、Monitoring を、大規模な基盤モデルトレーニングに特化して設計された統合システムにシームレスに組み合わせています。 このレファレンスアーキテクチャはベースインフラストラクチャスタックと、クラスタ本体から構成されます。 ベースインフラストラクチャスタックは CloudFormationテンプレート として利用可能で、最小限の労力デプロイ可能です。このテンプレートは、最適化されたネットワーク設定を持つ専用VPCを自動的に設定し、トレーニングデータ用の高性能なAmazon FSx for Lustre Filesystemを実装します（オプショナルで共有ホームディレクトリ用に FSx for OpenZFS Filesystem を Deploy することも可能です）。また、このインフラストラクチャスタックではパフォーマンスとコスト効率のバランスを取る階層型ストレージアプローチを採用しています。基盤となるのは、トレーニングデータとチェックポイントの長期ストレージを提供するAmazon S3です。トレーニング中のストレージボトルネックを防ぐため、S3バケットは データリポジトリアソシエーション（DRA） を通じてLustreファイルシステムとリンクされています。DRAは、Amazon S3とFSx for Lustre間の自動的で透過的なデータ転送を可能にし、手動コピーなしでS3データへの高性能アクセスを実現します。 オプションのモニタリングインフラストラクチャは、 Amazon Managed Service for PrometheusとAmazon Managed Grafana （または EC2上で実行されるセルフマネージドGrafanaサービス ）を組み合わせて、包括的な可観測性を提供します。GPUメトリクスのDCGM ExporterとネットワークメトリクスのEFA Exporterを統合し、システムの健全性とパフォーマンスのリアルタイムモニタリングを可能にしました。このセットアップにより、GPUの健全性、ネットワークパフォーマンス、トレーニングの進捗を継続的に追跡し、Grafanaダッシュボードを通じて異常の自動アラートを実現します。例えば、 GPU Health Dashboard は、Uncorrectable Remapped Rows、Correctable Remapped Rows、XID Error Codes、Row Remap Failure、Thermal violations、Missing GPUs（Nvidia-SMIから）などの一般的なGPUエラーのメトリクスを提供し、ユーザーがハードウェア障害を可能な限り迅速に特定できるようにします。 詳細なDeployment Guide とワークショップ リファレンスアーキテクチャも、チームが使用方法を知らなければ役に立ちません。GENIACの成功の重要な要素は、 再現可能なデプロイメントガイドとワークショップを通じた知識の共有 でした。 2024年10月3日、AWS JapanとWWSO Frameworksチームは、GENIAC第2サイクル参加者向けの大規模なワークショップを開催し、米国からのFrameworksチームメンバーを招いて、AWSでの基盤モデルトレーニングのベストプラクティスを共有しました。 このイベントには80名以上の参加者を迎え、講義、ハンズオンラボ、グループディスカッションを組み合わせた包括的なプログラムを提供し、CSAT 4.75 という高い評価をいただきました。講義セッションでは、インフラストラクチャの基礎、AWS ParallelCluster、Amazon EKS、Amazon SageMaker HyperPodなどのオーケストレーションオプション、AWSを使用した大規模基盤モデル（FM）の構築とトレーニングに必要なソフトウェアコンポーネントについて説明しました。セッションでは、FM開発における実践的な課題—大規模なコンピューティング要件、スケーラブルなネットワーキング、高スループットストレージを取り上げ、それらを適切なAWSサービスとベストプラクティスにマッピングしました（ 講義セッションのスライドデッキ ）。別のセッションではベストプラクティスに焦点を当て、参加者はPrometheusとGrafanaを使用したパフォーマンスダッシュボードの設定、EFA Trafficのモニタリング、NVIDIAのDCGMツールキットとFrameworksチームの2000台のP5インスタンスを持つクラスター管理経験に基づくカスタムGrafanaダッシュボードを使用したGPU障害のトラブルシューティングを学びました。 さらに、WWSOチームはParallelCluster（ Machine Learning on AWS ParallelCluster ）とHyperPod（ Amazon SageMaker HyperPod Workshop ）の双方に対応したワークショップを準備しました。これらの資料を使用して、参加者はSlurmを使用したトレーニングクラスターのデプロイ、FSx for LustreとFSx for OpenZFSを含むファイルシステム、マルチノードPyTorch分散トレーニングの実行を実践しました。ワークショップの別のセグメントでは可観測性とパフォーマンスチューニングに焦点を当て、参加者はリソース使用率、ネットワークスループット（EFAトラフィック）、システムの健全性のモニタリング方法を学びました。これらのセッションを通して、顧客とサポートするAWSエンジニアの両方が、共有の知識基盤とベストプラクティスのツールキットを確立しました。学んだすべての資産と知識を使用して、顧客はリードSAと共に、特定のユースケースに合わせたクラスターを同時にデプロイしました。このステップはオンボーディングセッションと呼ばれます。これらのセッション中、各リードSAは顧客がクラスターをデプロイし、NCCLテストを使用してクラスターの機能をテストし、通話中に発生した技術的な質問に対処できることを確認しました。 顧客のフィードバック データ入力の課題を根本的に解決するため、通常項目にはSLMとLLMを使用した2段階推論と自律学習、詳細項目には10万件の合成データサンプルを使用したVLMによる視覚学習を適用し、処理精度とコスト効率を大幅に改善しました。また、Amazon EC2 P5インスタンスを活用して研究開発効率を向上させました。これらの野心的な取り組みは、AWSを含む多くの方々のサポートによって可能になりました。広範なサポートに深く感謝いたします。 井上 拓真 – 執行役員CTO, AI Inside フューチャーはGENIACでの日本語とソフトウェア開発に特化した大規模言語モデルの開発においてAWSを選択しました。複数ノードを用いた大規模なモデル学習ではノード間通信等の環境設定に関する不安がありましたが、AWSではParallelCulsterをはじめとして周辺ツールが充実していたことに加え、AWSのソリューションアーキテクトの方々からも強力なサポートを頂き、迅速に大規模な学習を開始することができました。 森下 睦 – Chief Research Engineer, Future Corporation 結果と今後の展望 このブログで述べたような包括的な支援体制ににより、AWSは 12の顧客が1日で127台以上のP5インスタンスと24台のTrn1 を立ち上げる支援を提供できました。クラスタ上での6ヶ月の学習を通して、各事業者は基盤モデルの開発を行いました。 GENIACは、大規模な基盤モデルのトレーニングが本質的に組織的な課題であり、単なるハードウェアの問題ではないことを実証しました。構造化されたサポート、再現可能なテンプレート、クロスファンクショナルなコラボレーションを通じて、小さなチームでもクラウドで大規模なワークロードを成功裏に実行することができます。 AWSはすでにGENIACの次のサイクルの準備を開始しています。その一環として、AWSは4月3日に東京で基盤モデルビルダーにハンズオン体験とアーキテクチャガイダンスを提供するための技術イベントを開催しました。50名以上の参加者を集めたこのイベントは、スケーラブルで回復力のある生成AIインフラストラクチャをサポートするAWSの取り組みを示しました。 このイベントでは、GENIACのためのAWSの技術的エンゲージメントモデルと、 LLM Development Support Program や Generative AI Accelerator などの他のサポートメカニズムが紹介されました。イベント午前中には SageMaker HyperPod に関するワークショップが行われ、参加者はマルチノードGPUクラスターの立ち上げ、分散PyTorchトレーニング、オブザーバビリティを手を動かしながら学びました。午後に行われたセッションは、コンテナ化されたML、分散トレーニング戦略、AWSのカスタムシリコンソリューションなどの重要なトピックをカバーしました。またClassmethod Inc. からも実践的なHyperPodの洞察を共有するセッションがありました。このイベントは、インフラストラクチャからデプロイメントツールまで、AWSのエンドツーエンドのGenAIサポートエコシステムを紹介し、GENIAC第3サイクルの基盤を築きました。AWSが基盤モデル開発のサポートを拡大し続ける中、GENIACの成功は、組織が基盤モデル開発を効果的に構築しスケールするための青写真として機能します。 この記事は、AWS GENIAC Cycle2のコアテックメンバーである 小林正人 、 一柳健太 、 白澤聡 、Accelerated Computing Specialist  木内 舞 、ならびにリードソリューションアーキテクトの 宮本大輔 、 針原佳貴 、 佐々木啓 、 常世大史 によって寄稿されました。エグゼクティブスポンサーシップとして 安田俊彦 が支援を提供しました。また、AWS在籍時にコアメンバーおよびリードソリューションアーキテクトとして 畑浩史 氏 、 尾原颯 氏 、 卜部達也  氏も支援を提供しました。WWSO Frameworks チームのメンバーである Maxime Hugues 、 Matthew Nightingale 、 Aman Shanbhag 、 Alex Iankoulski 、 Anoop Saha 、 Yashesh Shroff 、 Shubha Kumbadakone  も広範な技術支援を提供しました。 Pierre-Yves Aquilanti 氏  もAWS 在職中に技術支援を提供しました。 著者について 渡辺啓太 は、AWS WWSO FrameworksチームのSenior Specialist Solutions Architectで、基盤モデルの学習と推論を専門としています。AWS 入社前は、E コマース業界で Machine Learning Researcherとして商品検索向けの画像検索システムの開発に従事していました。GENIAC における技術面のリードを担当しています。 井坂大 は、AWS WWSO Frameworksチームの Principal Business Development で、機械学習と人工知能ソリューションを専門としています。GENIAC の立ち上げ当初から関与しており、AWS の生成系 AI 製品の市場戦略をリードしています。 小林正人 は、2013年からAWS Japanのソリューションアーキテクト(SA)として、お客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援してきました。2024年からは特定のお客様を担当するチームを離れ、技術領域やサービスを担当するスペシャリストSAチームをリードする役割に変わりました。好きな温泉の泉質は、酸性-カルシウム-硫酸塩泉です。

この記事は 2025 年 5 月 20 日に公開された Securing your origin for Media and Entertainment workflows を翻訳したものです。 メディアストリーミングアプリケーションでは、コンテンツへの権限のないアクセスや再配布などの、増加しているセキュリティ上の課題に直面しています。ストリーミングワークフローに対する一般的なセキュリティ脅威を精査し、Amazon Web Services ( AWS ) を使用してコンテンツを保護するための実用的なソリューションを提供します。 メディアストリーミングにおけるセキュリティ上の課題 ストリーミングアプリケーションに適切なセキュリティ対策が講じられていない場合、権限のないユーザーは以下のことが可能となります： 許可なくコンテンツにアクセスして再配布する 許可されていない Web サイトにストリームを埋め込む 自動プログラムを使用してコンテンツをスクレイピングする これらのセキュリティ侵害は以下を引き起こす可能性があります： 顧客の離反 インフラストラクチャコストの増加 アプリケーションパフォーマンスの低下 このブログはメディア & エンターテインメントのワークフローに適したオリジンについてのシリーズの第 2 回目です。前回は ワークフローに適したオリジンを選択する方法について説明 しました。 今回はオリジンとコンテンツの保護に焦点を当てます。 望ましくないアクセスからの保護方法 不正アクセスの 3 つの主要なポイントとそれに対応するソリューションについて精査します。 クロスオリジンリソースシェアリング ( CORS ) とオリジンへの直接アクセス iFrame 埋め込み ユニフォーム・リソース・ロケーター (URL) シェアリング 1. CORS とオリジンへの直接アクセス オリジンが直接アクセスされないようにするにはクライアントアプリケーションまたはウェブサイトがコンテンツ配信ネットワーク (CDN) 経由でのみビデオストリームをリクエストするようにしてください。 AWS の CDN サービスは Amazon CloudFront ( CloudFront ) です。 Amazon Simple Storage Service ( Amazon S3 )、AWS Elemental MediaPackage ( MediaPackage )、またはカスタムオリジンのいずれを使用する場合でも、オリジンを CloudFront に追加できます。詳細な手順については コンテンツへのセキュアなアクセスの設定とアクセスの制限 を参照してください。ドキュメントの手順に沿って実行することでリクエストはオリジンではなく CloudFront によってのみ処理されるようになります。 選択したオリジンの CORS ルールがアクセスを許可するドメイン名のみを許可するよう設定されていることを確認しましょう。 以下の図は正しい CORS ルールによってビデオストリームがどのように保護されるかを示しています。 図 1 : ビデオストリームへのアクセスを保護する CORS ルールを示す図 以下はドメイン “my-site.com” に対して GET メソッドを許可する Amazon S3 CORS ポリシーの例です。 <?xml version="1.0" encoding="UTF-8"?> <CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/"> <CORSRule> <AllowedOrigin>https://www.my-site.com</AllowedOrigin> <AllowedMethod>GET</AllowedMethod> <MaxAgeSeconds>3000</MaxAgeSeconds> <AllowedHeader>Authorization</AllowedHeader> </CORSRule> </CORSConfiguration> CORS ルールとポリシーの設定方法の詳細については Amazon S3 CORS と MediaPackage CORS を参照してください。 2. iFrame の埋め込み ウェブページでは、特に動画の再生にネストフレーム (iframe) を使用するのが一般的です。これは、ウェブページの読み込み時間が短縮され、デプロイが容易になるためです。 このようなアプローチでは、開発者はプレーヤーフレームを埋め込んで目的の動画に指定するだけです。 iframe は HTML タグ <iframe> で 、HTML ページ（具体的には、「あるウェブサイト」）をあなたの HTML ページ（つまり、「あなたのウェブサイト」）に埋め込むことができるタグです。Web を使用していると気付かないうちに iframe を目にしています。 例えば、ニュースウェブサイトに埋め込まれている YouTube 動画がその一例です。ブログに埋め込まれている Facebook や Twitter の投稿も iframe の場合があります。これらはすべて別の HTML ページに埋め込まれた HTML ページです。 次の例では、左上の最初のウェブページに挿入された 4 つのビデオすべてが iframe タグを使用して挿入されます。ユーザーが動画の 1 つをクリックすると、ウェブサイトに動画を埋め込んだ iframe タグで定義されている動画（右側の 2 番目の画像）が開きます。この動画が実際にホストされている “実際の” ページは YouTube（中央下の画像）にあります。右上の画像に表示されている埋め込みページとは異なることがわかります。 図 2 : Web サイトに埋め込まれた iframe の使用 iframe の不正な埋め込みを防ぐには : セキュリティヘッダーに X-Frame-Options を実装します。 詳細については Mozilla 開発者ネットワークのドキュメント を参照してください。 CloudFront のセキュリティヘッダーレスポンスを使用してください。 詳細な説明については CloudFront レスポンスへの HTTP セキュリティヘッダーの追加 を参照してください。 適切な X-Frame-Options 値を設定します。 iframe のドメインが親フレームと同じ場合は SAMEORIGIN を使用してください。 DENY を使用すると、誰にも埋め込まれないようにできます。 誰かがあなたの iframe 埋め込みを悪用しようとした場合に、あなたのページに戻るようにする JavaScript ベースの埋め込み防止コードを追加することを検討してください。 3. URL シェアリング URL シェアリングに対処するには、いくつかの方法があります。 a. トークン化された URL トークン化された URL を使用すると、指定されたトークンが提供された場合にのみリクエストが処理されます。 通常、トークンは特定の情報をカプセル化したハッシュで、長期間使用されないように有効期限を短くするのが一般的です。 一般的な実装の例は以下のとおりです。 https://example.com/hls/playlist.m3u8?token=4180da90a6973bc8bd801bfe49f04a&expiry=1526231040535 や https://example.com/hls/segment001.ts?token=4180da90a6973bc8bd801bfe49f04a&expiry=1526231040535 のようになります。URL を取得しようとするリクエスト (この例では https://example.com/hls/segment001.ts ) を実行すると、403 HTTP エラーコードが返されます。 トークン化された URL を使用する利点 : 期間限定にできる 静的なホットリンクを防ぐことができる トークン化された URL を使用する場合の欠点 : 共有できてしまう スクレイピングできてしまう b. セッションベースのトークン URL トークンを強化するために、特定のユーザーと緊密に結びついたセッションベースのトークンを作成することができます。 汎用トークンはリソースへの直接アクセスを防ぐことができますが、セッショントークンはサイトやアプリケーションのコンテキスト外にあるリソースへのアクセスを防ぎます。 このトークンは、コンテンツをリクエストするユーザーが同じ IP アドレス、ユーザーエージェント、JS で生成されたハッシュ、その他のユーザー固有の情報を持っていることなどを検証します。 セッションベースのトークンを使用する利点 : セキュリティレイヤーの追加 特定のユーザーに紐付けられたアクセス制御 追跡と分析が可能 有効期限と取り消しが可能 セッションベースのトークンを使用する場合の欠点 : 複雑さの増大 アプリケーションのパフォーマンスに影響する可能性 サードパーティのプレーヤーや CDN ではサポートされていない可能性 強固な実装を行うには、 AWS でのエッジにおける安全なメディア配信 を使用することを検討してください。 c. ログインまたはペイウォールの追加 ユーザーログインやペイウォールの背後にあるストリームは、切り抜きされたり、外部で再生されたりする可能性がはるかに低くなります。 これをユーザー固有のトークンと組み合わせると、合理的で十分なレベルの保護が可能になります。 ログインやペイウォールを追加する利点 : 望ましくない一般からのトラフィックを削減させる ストリーミング認証を実際のユーザーセッションに紐付けられる ログインやペイウォールを追加することの欠点 : より複雑になってしまう エンゲージメントへの障壁が増加 アプリケーション認証ワークフローを改善するには、 新しい Amazon Cognito の機能でアプリケーションの認証ワークフローに磨きをかけよう を参照してください。 ペイウォールをエッジに移行するソリューションについては、 Guidance for Moving Your Paywall to the Edge on AWS をご参照してください。 d. 安全なハイパーテキスト転送プロトコル接続を使用 常にセキュアハイパーテキスト転送プロトコル (HTTP) 接続、別名 HTTPS を使用してください。これは HTTP のセキュアバージョンで、ユーザーとウェブサイト間の通信を暗号化します。HTTPS は、ユーザーとウェブサイト間で送信される情報を暗号化するために、トランスポート層セキュリティ ( TLS )、または以前はセキュア・ソケット・レイヤー ( SSL ) を使用します。 HTTPS 接続は、ユーザーが本物のウェブサイトと通信していることを保証するため、ウェブサイトの身元を検証します。次の確認により検証および保証します: 盗聴や身元情報の盗難から保護 ウェブサイトの身元を検証 データの整合性を保証 図 3 : SSL/TLS 通信ハンドシェイク図 HTTPS 接続を使用する利点 : HTTPS はエンドツーエンドの暗号化を提供 信頼と確実性を確立 コンプライアンスと規制 (PCI DSS、HIPAA、GDPR、NIST、ISO 27001) を保証 検索エンジン最適化 (SEO) の向上 HTTPS 接続を使用する場合の欠点 : レイテンシーにおけるパフォーマンスへの影響 SSL/TLS 証明書の管理における構成の複雑さ レガシー互換性 サーバー負荷の増加 特に機密情報やトランザクションを処理するアプリケーションでは、通常、HTTPS 接続の利点が欠点を上回ることに注意することが重要です。 HTTPS によってもたらされるセキュリティと信頼性の向上は現代のウェブアプリケーションにとって不可欠になっています。 CloudFront で HTTPS を設定する方法については、 CloudFront で HTTPS を使用する を参照してください。 e. デジタル著作権管理 ユーザーとウェブサイト間が HTTPS 接続されているだけでは、ユーザーが動画コンテンツをダウンロードし、コピーしたり、再配信したりすることを防ぐことはできません。要件とビジネスケースでユーザーによるコンテンツのダウンロードと再配信を阻止する必要がある場合は、ビデオストリームにデジタル著作権管理 (DRM) の適用を検討する必要があります。 DRM を適用できる AWS メディアサービスは、MediaPackage と AWS Elemental MediaConvert ( MediaConvert ) です。 これらのサービスは、Secure Packager and Encoder Key Exchange ( SPEKE ) を利用します。 SPEKE API の導入と統合はお客様の責任となります。 ビデオストリームに DRM を適用するには、 Content encryption and DRM in AWS Elemental MediaPackage と Protecting your media assets with encryption and DRM using AWS Elemental MediaConvert を参照してください。 次の (図 4) は DRM ワークフローの例です。 図 4 : SPEKE で DRM を使用するビデオワークフロー DRM を使用する利点: 不正なコンテンツダウンロードを防止 コンテンツライセンスルールを強制 さまざまな再生プラットフォームをサポート 安全なオフライン再生が可能 (設定されている場合) 詳細なコンテンツ使用状況の分析 DRM を使用する場合の欠点: プライバシーに関する懸念 技術的複雑さ 追加コスト 結論 メディアストリーミング配信元を保護することは、コンテンツを保護し、顧客の信頼を維持するために不可欠です。 ここで説明した方法を組み合わせて実装することで、アプリケーションのセキュリティ体制を大幅に強化できます。 まず Amazon CloudFront を設定し、HTTPS を有効にしてコンテンツを配信することをおすすめします。 適切な CORS ルールを実装し、セッションベースのトークン化された URL を使用してください。 iframe 保護の設定も検討してください。 ベストプラクティスとして、複数のセキュリティ方法を階層化して包括的な保護を行うことを提案しました。 セキュリティ要件とユーザーエクスペリエンスのバランスを取りながら、セキュリティ対策を定期的に監視および監査する必要があります。 次のステップでは、現在のセキュリティ体制を評価し、コンテンツ保護戦略のギャップを特定し、このブログで説明されているセキュリティ対策を実施することをお勧めします。 また、最適なユーザーエクスペリエンスを実現するために、必要に応じてセキュリティ構成を監視および調整する必要があります。 AWS メディアソリューションの詳細については、 AWS Media & Entertainment ページをご覧になるか、 AWS の担当者にお問い合わせいただき 、当社がお客様のビジネスの加速をどのように支援できるかをご確認ください。 追加情報 Cost-effective ways for securing your web applications using AWS WAF Geo-blocking with Amazon CloudFront Using CloudFront origin shield to protect your origin in a multi-CDN deployment Getting started with workflow monitor for AWS Media Services 参考リンク AWS Media Services AWS Media & Entertainment Blog (日本語) AWS Media & Entertainment Blog (英語) AWS のメディアチームの問い合わせ先 : awsmedia@amazon.co.jp ※ 毎月のメルマガをはじめました。最新のニュースやイベント情報を発信していきます。購読希望は上記宛先にご連絡ください。 翻訳は SA 加藤、長澤、石井が担当しました。原文は こちら をご覧ください。

本ブログは株式会社フレイ・スリー様と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWS アカウントマネージャーの藤川です 。 昨今、多くのお客様から生成 AI の活用についてご相談いただくようになりました。ISV(独立系ソフトウェアベンダー)/SaaS業界のお客様においても、生成 AI を活用した新しい製品・サービス開発の取り組みが増えてきています。 AI動画生成配信プラットフォーム「 1ROLL 」を提供する株式会社フレイ・スリー様は、 実際のビジネス課題を解決する機能をAWS上で開発するハッカソンイベント AWS DEVCRAFT に参加。「 Amazon Bedrock Claude3.5 Sonnet v2 / Amazon Bedrock Knowledge Bases 」を活用し、視聴データの評価、及び課題に応じた解決策を提案する機能を開発されました。 本記事では、生成AIを活用した動画マーケティング領域における効率化の取り組みについてご紹介します。 お客様の状況と検証に至る経緯 近年、動画コンテンツの需要が高まる中、動画制作は効率化が進んできました。しかしながら、制作後の運用面では以下の課題が残っていました。 どんな動画を作れば効果的か分からない 配信したけど視聴データの指標の見方が分からない 何を改善したらよいか分からない これらの課題についてサポートチームが個別に対応する必要があり、業務の負担が増大していました。また、視聴データの評価ポイントや改善策の内容は目的毎に共通していることが多く、生成 AI を活用してサポート業務を効率化できないかと考えました。 ソリューション/構成 動画の視聴データを「Amazon Bedrock Claude3.5 Sonnet v2」が分析及び課題を特定し、Amazon Bedrock Knowledge Baseから最適な解決策を提示する仕組みを AWS Step Functions でスピーディーに実装されました。 まずRDSに入っている動画構成データ、動画視聴データを取得します 次に動画視聴データをAmazon Bedrock Claude3.5 Sonnet v2に評価させます 視聴データの評価内容を解決ナレッジを保管してあるAmazon Bedrock Knowledge Basesから検索し提示します 導入効果 フレイ・スリー様の「動画アナリティクスAI Agent機能」により、以下の効果が期待されています。 動画活用の課題特定と解決策提示の自動化（動画評価及び解決策提示までわずか15秒で完了） サポート部門の作業負荷軽減に成功。 動画活用の継続的な改善サイクルの構築 今後の展望 今後の展開について、フレイ・スリー様は次のように意欲を示しています。 「今回の機能で動画活用の継続的な改善サイクルを構築し、より良い動画活用を自動で提案しながら、顧客自身で解決できるようなシステムの構築を目指します。」 AWS DEVCRAFTでの取り組み内容発表時の様子 株式会社フレイ・スリー 開発部 リードエンジニアの青木 諭氏 AWS DEVCRAFTでの要件定義ディスカッション中の様子 フレイ・スリー様ビジネスサイド（代表取締役 CEO 石田氏）、開発サイド（テックリード 青木氏、三好氏）、AWSアカウントチーム（ソリューションアーキテクト呉、アカウントマネージャー藤川）が１つの会場に集まりディスカッションする事で、ビジネス課題解決に向け実現したいイメージを短期間で形にすることが出来ました。

本記事は 2025 年 6 月 12 日に公開された “ Use Model Context Protocol with Amazon Q Developer for context-aware IDE workflows ” を翻訳したものです。 本日、 Amazon Q Developer が Visual Studio Code と JetBrains の統合開発環境（IDE）プラグインで Model Context Protocol（MCP）サポートを発表しました。これにより、開発者は外部ツールや MCP サーバーを Q Developer に接続でき、よりコンテキストを理解した応答と複雑な開発プロセスの支援が可能となります。MCP サポートは、2025 年 4 月 29 日から Amazon Q Developer for Command Line ですでに利用可能でした。 はじめに Q Developer は、 エージェント型コーディング 機能の追加により、IDE 内でのツールの利用（シェルコマンドの実行、ローカルファイルの読み取り、コード生成など）が可能でした。今回、開発者は MCP をサポートする追加のツールをツールキットに組み込めるようになりました。MCP は、大規模言語モデル（LLM）がアプリケーションと統合する方法を標準化するオープンプロトコルです。コンテキストの共有、データソースへのアクセス、API とのやり取りの方法を提供します。MCP の詳細については、この 紹介記事 をご覧ください。 追加のコンテキストとツールを利用できることで、Q Developer はより正確なコードを書き、計画ツールと統合し、デザインから UI コンポーネントを作成し、実際のスキーマを調べてデータベースドキュメントを生成し、複雑なマルチツールタスクを実行できます。これらはすべてカスタム統合コードなしで実現できます。この機能が Q Developer IDE プラグインに追加され、開発者がもっとも多くの時間を過ごす場所で開発プロセスがさらに向上することを嬉しく思います。 この記事では、開発者として Jira などのプロジェクト管理ツールで定義された課題に取り組むという一般的なシナリオを紹介します。この課題には、ユーザーストーリー、受け入れ基準、ユーザーインターフェイスの Figma デザインへのリンク、追加の技術実装メモが含まれています。Q Developer が 2 つの別々の MCP サーバーを使用して Jira と Figma と独立してやり取りすることで、プロセス全体を効率化する方法をデモします。ブラウザタブを手動で切り替えたり、情報をコピーしたり、複数のツール間で要件を追跡しようとする代わりに、Q Developer が MCP を使用して詳細な情報を自動的に取得し、両方のプラットフォームでコンテキストを維持しながら機能を実装する方法を紹介します。 図 1: MCP サーバーを使用して外部ツールとやり取りする Visual Studio Code の Q Developer 拡張機能 MCP サーバーの設定 設定を開始するには、以下の画像に示すように、Chatタブバーの上部にある Configure MCP servers の設定 ボタンをクリックします。これにより、現在設定されている MCP サーバーのリストが表示されます。+（Add new MCP）ボタンをクリックして、新しいサーバーを追加します。 図 2: Visual Studio Code の Q Developer 拡張機能での MCP サーバー設定の追加 設定時に MCP サーバーのスコープを設定します。グローバルスコープでは、すべてのプロジェクトで MCP サーバーを使用でき、ワークスペーススコープでは現在の IDE ワークスペースのみで設定されます。以下は、使用する Atlassian と Figma の MCP の設定例です。 Atlassian Scope:  This workspace Name:  Atlassian Transport:  stdio Command:  npx Arguments: -y mcp-remote https://mcp.atlassian.com/v1/sse Figma Scope:  This workspace Name:  Figma Transport:  stdio Command:  npx Arguments: -y mcp-remote http://127.0.0.1:3845/sse 注意: Atlassian MCP サーバーを初めて設定する際は、ブラウザで OAuth 認証フローを完了し、Jira プロジェクトへのアクセス許可を提供するよう求められます。同様に、Figma Dev Mode MCP サーバーに接続するには、Figma デスクトップアプリ経由で 有効にする 必要があります。 図 3: 設定された Figma と Atlassian MCP サーバーを表示する Q Developer の MCP 管理ウィンドウ MCP サーバーの個別ツールを理解するには、以下の画像に示すように、その名前の横にある展開アイコンをクリックします。ツールとは MCP サーバーによって公開される実行可能な機能のことです。これらにより、Q Developer のエージェント型チャットがアクションを実行し、ユーザーに代わって外部システムとやり取りできます。個別ツールの権限も設定できます。各ツールには、Ask、Always allow、または Deny のオプションがあり、Q Developer がそのツールを実行できるかどうかを設定できます。私の例では、データを読み取るだけのツールはすべて Always allow に設定し、残りのツールを Ask に設定します。 図 4: Ask、Always allow、または Deny のオプションを持つ MCP ツールの説明と設定ドロップダウン MCP サーバーが設定されたので、これらを開発プロセスに統合する方法を見てみましょう。 ウォークスルー Q Developer は、設定された MCP サーバーを通じて利用できる追加情報とツールで強化されました。これが開発者の生産性をどのように向上させるかをデモするために、 Q Words ゲーム を使って作業します。 シナリオ Q-Words は、Q Developer の機能をデモするために顧客のワークショップで使用されるインタラクティブな単語推測ゲームです。プロダクトマネージャーから、ゲームにダークモードを追加するタスクを与えられました。ユーザーストーリーは Jira に記録され、デザイナーが準備した Figma デザインにリンクしています。 図 5: Q-Words ゲームアプリケーションにダークモードを追加するためのユーザーストーリーと受け入れ基準を示す Jira チケット 図 6: QWords ゲームアプリケーションのダークモードとライトモードのインターフェイスを示す Figma デザイン MCP を開発プロセスに統合する エージェント型チャットで以下のプロンプトを入力して、Jira で自分に割り当てられたタスクを確認するよう Q Developer に依頼することから始めましょう。 作業が必要なタスクをリストアップして Q Developer はあなたの意図を理解し、Atlassian MCP サーバーとやり取りして、あなたに割り当てられ、To Do 状態にある Jira タスクをフィルタリングして表示します。オプションで、Q Developer に特定の MCP サーバーを使用するよう指示できます。他のプロンプトと同様に、明確な指示を提供することでより良い結果が得られます。以下の画像では、Q Developer が私に割り当てられたタスクの詳細を取得しています。 図 7: Atlassian MCP サーバーを使用して Jira で私に割り当てられた課題を取得し説明する Q Developer 以下のプロンプトでタスクの作業を開始しましょう。 タスク CRM-9 を In Progress に移動し、タスク ID にちなんだ名前の新しい git ブランチをチェックアウトして作業を開始して 図 8: 割り当てられた課題の作業を開始するよう Q Developer にプロンプトする 次に、デザイン変更が現在のアプリケーションに与える影響を理解したいと思います。これを実現するために以下のプロンプトを使用します。 Jira ユーザーストーリーとリンクされた Figma デザインを分析して。既存のコードで変更が必要な UI コンポーネントについて、技術的な実装計画を説明して。 図 9: 新しい UI を実装するために既存のコードの変更を分析するよう Q Developer にプロンプトする Q Developer は Jira からタスクの詳細を自動的に取得し、Figma から色などのデザイン仕様も取得します。MCP 以前は、これらの詳細をプロンプトに直接追加するか、ローカルファイルからコンテキストとして提供する必要がありました。今では、プロンプトにはタスクの説明のみが含まれ、コンテキストは MCP サーバーから取得した詳細情報で強化されます。提案された計画を確認し、必要に応じて修正案を出してください。満足したら、Q Developer に変更の作業を開始するよう指示します。 計画を実装して 図 10: HTML と CSS でダークモード機能を実装するための Q Developer による変更の差分表示 Q Developer によって変更されたファイルの差分を確認できたら、新しいダークモード機能が希望通りに実装されていることを確認します。変更をテストし、すべての受け入れ基準が満たされていることを確認しましょう。アプリケーションを実行するために、以下のプロンプトを使用します。 アプリケーションをローカルで実行して Q Developer は許可を求め、ローカル Web サーバーを起動するコマンドを実行します。その後、ブラウザで変更をテストできます。 図 11: MCP を使用して Q Developer によって実装されたダークモード切り替えボタンを持つ更新されたアプリケーション 少しテストを行った後、ストーリーのすべての受け入れ基準を満たしたことを確認できました。次に、以下のプロンプトで、達成したことをチームのメンバーに共有しましょう。 Jira タスクのステータスを Done に更新し、行った変更を要約したコメントを追加して Q Developer と Jira 間のこの便利な MCP 経由の統合により、達成した作業を文書化するために、ツール間を行き来する手間が省けます。 図 12: テーマ切り替え、CSS 変数、UI コンポーネントを含むダークモード機能の完了した実装を詳述する Jira チケットコメント まとめ Amazon Q Developer の IDE 用 MCP サポートの追加により、コンテキストを共有し、追加のツールと連携するための標準化された方法が提供されました。この記事では、IDE で Q Developer を使用し、タスク管理のための Atlassian Jira と UI 更新のための Figma とやり取りする方法をデモしました。プロンプトにユーザーストーリーの詳細情報を明示的に含めることなく、また UI モックアップからデザインアセットを別途ダウンロードしたりすることなく、これを実現できました。代わりに、Q Developer は MCP サーバーによって公開されたツールを使用して、ユーザーストーリーのコンテキストに自動的にアクセスし、デザインアセットを簡単に統合できました。新しい MCP 機能を探索し、GitHub の AWS MCP Servers リポジトリもチェックすることをオススメします。詳細については、 IDE での Q Developer の MCP 設定 を参照してください。 Amazon Q Developer の機能と価格の詳細については、 Amazon Q Developer 製品ページ をご覧ください。 著者について Ritik Khatwani Ritik は、ニューヨーク市を拠点とする AWS の生成 AI スペシャリストソリューションアーキテクトです。エンジニア、アーキテクト、創設者として製品構築に深い専門知識を持っています。AWS では、以前はスタートアップがクラウドで構築し成長する方法についてアドバイスし、現在は開発者が Amazon Q Developer を使用してソフトウェア開発ライフサイクルを再構想することに取り組んでいます。

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 6 月 25 日 (水)、26 日 (木) に開催される AWS Summit Japan 2025 まであと少しですね。 本ブログ内でもいくつか展示についてのブログをピックアップしておりますので、ご興味のある皆様はぜひ ↑ のリンクよりご登録をお願いいたします。そのほかにも新しいお客様の活用事例や GPU インスタンスの値下げ、用途特化のエージェントに関する情報などが今週も盛りだくさんです。 それでは、6月9日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「AWS 生成 AI 事例 : 株式会社 Nint 様の EC モールデータ分析サービスにおける AI 分析機能の開発」を公開 株式会社 Nint 様は「データで世界を自由にする」というミッションのもと、日本、中国、および東南アジアにおいて大手ECモールのデータ分析サービス「Nint ECommerce」を提供している企業です。従来、データ分析には高度な知識や経験が必要で、未経験者には敷居が高く、スキル獲得に1-2ヶ月を要するなどの課題がありました。これを解決するために、Amazon Bedrock エージェントを活用した対話形式のデータ分析 AI 機能「Nint AI」を開発しました。その結果、ユーザーは自然言語で分析作業をリクエストするだけで、AIエージェントが自律的に必要な作業を行い、分析結果やインサイトを提示し、視覚的に説明するためのグラフや図表を描画できるようになりました。今後、さらなる機能拡張を検討されています。 ブログ記事「AI チャットボットを超えて：Amazon.comの生成AIでビジネスを再発明した事例」を公開 この記事では、Amazon.comが生成AIをどのように活用して様々な業界に変革をもたらしているかについて解説しています。単なるAIアシスタント以上の活用事例として、製品開発、カスタマーサービス、マーケティング、Amazon Pharmacy など多岐にわたる領域での実践例を紹介しています。Amazon.comの経験から得られた教訓や、他の企業が生成AIを戦略的に活用するためのヒントも提供されており、ビジネス変革を目指す組織にとって有益な活用事例となっています。 ブログ記事「Amazon の生成 AI 搭載ショッピングアシスタント Rufus を、80,000 以上の AWS AI チップを活用して Prime Day 向けにスケーリング」を公開 Amazon Rufusは生成AIを活用したショッピングアシスタントで、Amazon の商品情報やウェブ上の様々な情報を活用してお客様のよりスマートなお買い物をサポートします。この記事では、RufusがNeuron SDKやInferentia2、Trainiumチップ、そしてAWSの各種サービスを活用して、数十億のパラメータを持つLLMを安定的にデプロイし、運用する方法を紹介しています。80,000以上のAWS InferentiaとTrainiumチップを活用することで、他のソリューションと比べてコストを約4.5分の1に削減し、P99レイテンシーを1秒未満に保ちながら1分間に平均300万トークンを処理することを実現しています。 ブログ記事「AWS Summit 2025 Japan 小売・CPGブースとセッションのご案内」を公開 この記事では、AWS Summit Japan 2025における小売・CPG（消費財）業界向けのブースとセッションについて紹介しています。生成AIを活用した顧客体験の向上、サプライチェーン最適化、データ分析などのテーマに関するセッションやデモが予定されており、小売・CPG業界の企業がAWSの最新技術をどのように活用できるかを学ぶ機会となっています。業界特有の課題解決に焦点を当てた内容となっており、関連業界の方々に特に参考になる情報が提供されています。 ブログ記事「AWS Summit Japan 2025 ~ 生成 AI とグラフデータを活用した 業務横断データ活用（Digital Thread）の展示のご紹介」を公開 この記事では、AWS Summit Japan 2025で紹介される「Digital Thread」の概念と、それがどのように製造業のデジタルトランスフォーメーションを加速するかについて解説しています。Digital Threadは製品のライフサイクル全体にわたるデータの流れを一元管理するアプローチで、生成AIを活用することでさらに強化されます。記事では、Summit会場でのデモ展示内容や関連セッションの紹介も行っており、製造業に関わる方々にとって有益な情報が満載です。 ブログ記事「生成 AI (Amazon Bedrock と Amazon Q Developer) を活用した製造業スマート製品開発の新しいかたち-Part1 顧客体験とサービス運営力の向上」を公開 この記事では、製造業におけるスマート製品開発に生成AIがどのように変革をもたらすかについて解説しています。Amazon BedrockとAmazon Q Developerを活用することで、顧客体験とサービス運用を向上させる方法に焦点を当てています。具体的には、製品設計プロセスの効率化、顧客フィードバックの分析、サービスマニュアルの自動生成などのユースケースを紹介し、製造業における生成AIの実践的な活用方法を示しています。 ブログ記事「Amazon Bedrock を使用したWell-Architected な生成 AI ソリューションによる運用効率の向上」を公開 この記事では、AWS Well-Architected Frameworkの原則に基づいた生成AIソリューションの構築方法について解説しています。特に運用効率の向上に焦点を当て、Amazon Bedrockを活用した生成 AI アプリケーションの設計、デプロイ、運用のベストプラクティスを紹介しています。セキュリティ、信頼性、パフォーマンス効率、コスト最適化などの観点から、生成 AI ソリューションを構築する際の重要なポイントを詳細に説明しています。 ブログ記事「AWS Transform の AI エージェントを使って メインフレームモダナイゼーションジャーニーを加速する」を公開 この記事では、AWS Transformを使用したメインフレームモダナイゼーションプロセスにAIエージェントを活用する方法について解説しています。AIエージェントがレガシーコードの分析、現代的なアーキテクチャへの変換、テスト自動化などをサポートすることで、従来は複雑で時間のかかるメインフレームモダナイゼーションプロジェクトを大幅に効率化できることを示しています。具体的なユースケースや実装例も紹介されており、メインフレームモダナイゼーションに取り組む組織にとって参考になる内容です。 ブログ記事「Amazon Nova Canvas を使ったテキストから画像生成の基礎」を公開 Amazon Nova Canvasは、テキストプロンプトから高品質な画像を生成するAIモデルです。この記事では、Nova Canvasの基本的な使い方から、効果的なプロンプトの書き方、様々な画像スタイルの生成方法まで、実践的な内容を紹介しています。画像生成AIを初めて使う方にも分かりやすい内容となっており、クリエイティブな作業の効率化に役立つ情報が満載です。具体的なプロンプト例と生成結果の比較も掲載されており、すぐに実践できる知識を得ることができます。 ブログ記事「インテリアデザインと商品写真における Amazon Nova Canvas の実用例」を公開 この記事では、Amazon Nova Canvasを使ったインテリアデザインと製品写真撮影の実用的な活用例を紹介しています。Nova Canvasを使用することで、実際の写真撮影を行わずに様々な環境での製品イメージを生成したり、インテリアデザインのコンセプト作成を効率化できることを解説しています。具体的なプロンプト例や生成された画像サンプルも豊富に掲載されており、クリエイティブ業界での実践的な活用方法を学ぶことができます。 ブログ記事「Amazon EKS MCP Server によるアプリケーション開発の促進」を公開 この記事では、Amazon EKSで実行されるModel Context Protocol（MCP）サーバーを使用して、アプリケーション開発を加速する方法を紹介しています。MCPは、AIモデルが外部ツールやデータソースにアクセスするためのオープンプロトコルで、Amazon Q Developer CLIなどのAIアシスタントと連携することで、開発者はKubernetesリソースの作成や管理を自然言語で行うことができるようになります。記事では、MCPサーバーのセットアップから実際の使用例まで、詳細なステップバイステップガイドを提供しています。AWS の公開しているMCPサーバーは こちら のGitHubレポジトリにまとまっておりますので、ぜひご一読ください。 ブログ記事「Amazon EC2 NVIDIA GPU 高速インスタンスの最大45%価格削減を発表」を公開 Amazon EC2のNVIDIA GPU高速インスタンスの価格を最大45%削減することが発表されました。この記事では、P4、P5インスタンスファミリーの価格削減について詳しく説明しています。これらの料金更新は、コスト削減分を直接お客様に還元しながら高度な GPU コンピューティングをより利用しやすいものにする AWS の取り組みを反映しており、お客様は生成AIモデルの開発・推論をより高いコスト効率で取り組むことができるようになります。価格削減は、オンデマンドインスタンス、Savings Plans、リザーブドインスタンスなどの購入オプションに適用されます。詳細は Amazon EC2 料金ページ をご参照ください。 サービスアップデート Amazon Q Developer IDE プラグインでMCPツールをサポート開始 Amazon Q DeveloperがIDE プラグインでModel Context Protocol (MCP)をサポート開始しました。MCPは、AIモデルが安全で構造化された方法で外部ツール、データソース、APIにアクセスするためのオープンプロトコルです。開発者は外部ツールを利用してより豊富なコンテキストでの開発ワークフローを実現できるようになります。Visual Studio Code、JetBrains IDE plugins、Amazon Q Developer CLIで利用可能で、より カスタマイズされた応答を提供し、ネイティブツールとMCPサーバーベースのツール間でタスクを調整できます。 Amazon Q Developer で CLI における Java の選択的変換（プレビュー）を発表 Amazon Q DeveloperにてJavaコードの選択的変換を行うCLI機能がプレビューで発表されました。レガシーJavaコードのモダナイゼーションや、特定の部分のみを対象とした変換作業を効率的に行うことができます。大規模なJavaアプリケーションの段階的な移行に特に有用な機能です。この機能を使用することで、Java 8からJava 21への移行、JUnitのバージョンアップグレード、Log4jからLogbackへの移行など、特定のコード変換タスクを選択的に実行できます。変換プロセスは高度にカスタマイズ可能で、特定のファイルやディレクトリを対象にすることも可能です。現在、米国東部（バージニア北部）リージョンでプレビュー提供されています。 Amazon Q Developer Pro tier でBuilder IDのアップグレードが可能に Amazon Q Developer Pro tierにて、Builder IDのアップグレード機能が追加されました。これにより、個人のBuilder IDからチーム向けのPro tierへのスムーズな移行が可能になり、より高度な機能やサポートを利用できるようになります。開発チームの生産性向上に貢献する機能です。アップグレードプロセスは簡素化され、既存のBuilder IDを維持したまま、Pro tierの高度なコード生成、コードトランスフォーメーション、セキュリティスキャンなどの機能を利用できるようになります。この機能は、Amazon Q Developerが利用可能なすべてのリージョンで提供されています。 Amazon Lex で LLM-Assisted NLUによって会話精度が向上 Amazon Lexにて、大規模言語モデル（LLM）を活用した自然言語理解（NLU）機能により、会話の精度が大幅に向上しました。従来のルールベースのアプローチと比較して、より自然で柔軟な対話が可能になり、ユーザーの意図をより正確に理解できるようになりました。この機能強化により、複雑な表現や文脈依存の質問にも適切に対応できるようになり、チャットボットやボイスアシスタントの品質向上に大きく貢献します。現在、米国東部（バージニア北部）、米国西部（オレゴン）、欧州（アイルランド）リージョンで利用可能です。 Amazon Nova Sonic でスペイン語サポートを開始 Amazon Nova Sonicにてスペイン語のサポートが開始されました。これにより、スペイン語圏のユーザーもNova Sonicの高品質な音声生成機能を活用できるようになります。多言語対応の拡充により、グローバルなアプリケーション開発がより容易になりました。Nova Sonicは自然で表現力豊かな音声を生成するAIモデルで、ポッドキャスト、オーディオブック、教育コンテンツなど様々な用途に活用できます。スペイン語サポートは、米国東部（バージニア北部）、米国西部（オレゴン）リージョンで利用可能です。 Amazon Bedrock Custom Model Import で Qwen モデルをサポート Amazon Bedrock Custom Model ImportにてQwenモデルのサポートが開始されました。Qwenは高性能な多言語対応の大規模言語モデルで、特に中国語や日本語などのアジア言語に強みを持っています。お客様は独自のQwenモデルをBedrockに持ち込んで利用できるようになり、より多様なユースケースに対応可能になりました。サポートされるモデルには、Qwen1.5-0.5B、Qwen1.5-1.8B、Qwen1.5-4B、Qwen1.5-7B、Qwen1.5-14B、Qwen1.5-32B、Qwen1.5-72B、Qwen1.5-110Bが含まれます。現在、米国東部（バージニア北部）、米国西部（オレゴン）、アジアパシフィック（東京）を含む複数のリージョンで利用可能です。 PowerTools for Lambda に Bedrock Agents 機能ユーティリティを追加 AWS Lambda PowerToolsにて、Amazon Bedrock Agents向けの機能ユーティリティが追加されました。これにより、Lambda関数内でBedrock Agentsをより簡単に活用できるようになり、サーバーレスアーキテクチャでのAIエージェント開発が効率化されます。新しいユーティリティは、Bedrock Agentsのアクション実行に必要なボイラープレートコードを削減し、エラー処理、入力検証、レスポンス形式の標準化などを自動化します。Python、TypeScript、Java言語でサポートされており、開発者はより本質的なビジネスロジックの実装に集中できるようになります。 Amazon SageMaker AI GPU高速インスタンスの価格を最大45%削減 Amazon SageMaker AI GPU高速インスタンスの価格を最大45%削減することが発表されました。対象はP4 (P4d, P4de)、P5 (P5, P5e, P5en)インスタンスタイプで、オンデマンドおよびSavings Plan価格、利用可能な全リージョンに適用されます。オンデマンド購入は6月9日から、Savings Plan購入は6月16日以降に適用されます。また、SageMaker HyperPodのフレキシブルトレーニングプランの価格も削減され、より費用対効果が高い生成AIモデル開発を実現できます。 今週は以上でした。それでは、また来週お会いしましょう！ 著者について 三厨 航(Wataru Mikuriya) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近見たドラマは「ブラッシュアップライフ」です。

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 全国各地、梅雨入りし始めているようですが、雨というより急に暑さが厳しくなりましたね・・・ さて、来週は AWS Summit Japan が開催されます。 私は AWS ExpoのAWS Village にある金融サービスのブースにいる時間が長いです。よかったら覗いてみてください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年6月9日週の主要なアップデート 6/9(月) AWS launches public preview of Amazon Elastic VMware Service (Amazon EVS) Amazon Elastic VMware Service（Amazon EVS）のパブリックプレビューが開始され、VPC内でVMware Cloud Foundationベースのワークロードを実行できるようになりました。パブリックプレビューの期間中は、VCFライセンスのポータビリティを利用し、非本番環境のワークロード移行が可能で、ガイド付きワークフローを通じて環境のプロビジョニングおよび設定を行います。Amazon EVSでは同時に発表された Amazon FSx for NetApp ONTAPのEVS対応 など、使い慣れたVCFツールや外部ストレージソリューションの統合をサポートします。現時点では、VCFバージョン5.2.1とi4i.metalインスタンスをサポートしています。Amazon EVSのパブリックプレビューは現在、米国東部（バージニア北部）、米国東部（オハイオ）、米国西部（オレゴン）、アジアパシフィック（東京）、ヨーロッパ（フランクフルト）の5つのリージョンで利用可能です。詳細については ドキュメント をご確認ください。 Announcing open sourcing pgactive: active-active replication extension for PostgreSQL アクティブ-アクティブレプリケーション用のPostgreSQLエクステンションであるpgactiveがオープンソース化されました。pgactiveは非同期のアクティブ-アクティブレプリケーションを使用してデータベースインスタンス間でデータをストリーミングでき、異なるリージョンに配置されたライターを含むデータベースインスタンス間のデータ移動において、追加の回復力と柔軟性を提供するものです。PostgreSQL 16から導入された論理レプリケーション機能をベースとし、レプリケーションの管理を簡素化する機能を提供しています。詳細については GitHubリポジトリ をご確認ください。 Amazon CloudWatch agent adds support for EBS detailed performance statistics Amazon CloudWatchエージェントで、EC2インスタンスとEKSノードに接続されたEBSボリュームの詳細なパフォーマンス統計の収集が可能になりました。NVMeベースのメトリクス（キューの深さ、操作数、データ転送量、I/O操作時間など）を収集し、カスタムメトリクスとして利用可能です。この機能により、ストレージパフォーマンスの詳細な分析、監視、アラート設定が可能となり、アプリケーションのパフォーマンスのボトルネック特定と迅速な対処が可能になります。この機能は、すべてのAWS商用リージョンとGovCloudリージョンのNitroベースEC2インスタンスで利用可能です。詳細については ドキュメント をご確認ください。 6/10(火) Amazon Q Developer launches Java upgrade selective transformation in CLI (Preview) Amazon Q DeveloperのJava upgrade transformation CLIに選択的変換機能がプレビューとして追加されました。この機能は自然言語チャットやインプットファイルを使用した変換計画のカスタマイズを可能にするもので、変換ステップの選択や依存関係のアップグレード管理がより細かく制御できるようになります。LinuxとMacOSのコマンドラインで利用可能です。詳細は ドキュメント をご確認ください。 Powertools for AWS Lambda introduces Bedrock Agents Function utility Powertools for AWS Lambdaに、Amazon Bedrock Agentsとの統合を簡素化する新しいFunction ユーティリティが追加されました。この機能により、開発者はパラメータ注入や応答フォーマットなどの定型コードを排除し、AWS LambdaとBedrock Agents間の複雑な統合をユーティリティに任せることができます。また、Logger、Metricsなどの既存のPowertools機能とシームレスに統合され、AIアプリケーションの開発効率が大幅に向上します。詳細については各言語毎のドキュメント ( Python , TypeScript , .NET ),、もしくは GitHubリポジトリ のコード例をご確認ください。 AWS AppSync Enhances Security with Default Encryption for GraphQL API Caching AWS AppSyncで新規APIキャッシュ構成に対して保管時および転送時の暗号化が自動的に有効化されるようになりました。この機能は新規作成されるキャッシュにのみ適用され、既存のキャッシュ設定には影響しません。また、同時にAWS AppSync SDKsも更新され、新規キャッシュに対する暗号化が強制適用されるようになっています。この変更により、追加設定なしでセキュリティが強化され、AWSのベストプラクティスに準拠したより安全なキャッシング実装が可能になります。この機能は、AWS AppSyncが提供されているすべてのリージョンで利用可能です。詳細は ドキュメント をご確認ください。 6/11(水) Amazon RDS for DB2 now supports cross region standby replicas Amazon RDS for DB2でクロスリージョンスタンバイレプリカがサポートされ、災害復旧(DR)時のデータベースダウンタイムを大幅に削減できるようになりました。この機能により、別のAWSリージョンに最大3つのスタンバイレプリカを作成可能で、プライマリデータベースが利用できなくなった際に即座にレプリカを昇格させて運用を再開できます。スタンバイレプリカは昇格するまで操作できないですが、レプリカごとに2vCPU分のライセンスしか使わないため、コストを抑えてDRを実現できます。BYOLまたはMarketplaceライセンシングモデルで利用可能です。詳細は ドキュメント をご確認ください。 Amazon Q Developer introduces Pro Tier upgrades for Builder IDs Amazon Q Developerが、AWS Builder IDユーザーでもPro Tierへのアップグレードできるようになりました。従来はPro Tierの利用にはIAM Identity Center を使って管理者が設定する必要がありました。今回のアップデート後は、Amazon Q DeveloperのFree Tier制限に達すると、AWSアカウントを接続してPro Tierへの登録を促されます。その後コンソールで自身のBuilder IDを接続し、Pro Tierサブスクリプションに登録することが可能です。この機能は、Amazon Q Developerがサポートされているすべてのリージョンで利用可能です。詳細は ドキュメント をご確認ください。 AWS CloudTrail enhances logging for Amazon S3 DeleteObjects API Amazon S3 DeleteObjects APIのCloudTrailログ機能が強化され、バルク削除操作の詳細な可視性が向上しました。これまでは削除操作が単一のイベントとしてのみ記録されていましたが、新機能により個々のオブジェクトの削除イベントも記録されるようになります。この機能強化により、S3バケットのセキュリティ管理とコンプライアンス対応が向上し、高度なイベントセレクターを使用して必要なデータイベントのみを選択的に記録することも可能になりました。詳細は ドキュメント をご確認ください。 AWS Cloud WAN simplifies network operations with Security Group Referencing and enhanced DNS support Cloud WANで接続されたVPC間でのセキュリティグループ参照機能とDNSサポート強化が一般提供されました。これまではCloud WANを介して接続されたVPC間のトラフィックを制御するためにSG参照を使用することができませんでしたが、参照できることによりトラフィックの許可が用意になります。また、強化されたDNSサポートにより、Cloud WANに接続されたVPCからのDNSクエリに対して、パブリックDNSホスト名をプライベートIPアドレスに解決できるようになります。この機能はCloud WANが利用可能なすべてのAWSリージョンで追加料金なしで利用できます。詳細については ドキュメント をご確認ください。 6/12(木) AWS WAF now supports automatic application layer distributed denial of service (DDoS) protection AWS WAFに数秒以内の応答が可能な高速な自動検知と緩和機能を備えたアプリケーション層（L7）DDoS保護機能の強化が追加されました。この機能は、機械学習モデルを活用してトラフィックの異常を検出し、自動的に保護ルールを適用します。AWS WAFおよびAWS Shield Advancedサブスクライバーが利用可能で、Amazon CloudFront、ALB、をはじめとするWAFでサポートされるAWSリソースに適用可能です。この強化により、手動での設定・管理負荷を軽減しながら、効果的なDDoS保護を実現できます。この機能は、アジアパシフィック（タイ）、メキシコ（中央）、中国（北京および寧夏）を除くすべてのサポート対象AWSリージョンで利用可能です。詳細は ドキュメント をご確認ください。 Amazon Lex improves conversational accuracy with LLM-Assisted NLU Amazon Lexで、英語とスペイン語向けに大規模言語モデル（LLMs）支援の自然言語理解（NLU）機能が導入されました。この機能により、複雑な発話の解釈やスペルミスへの対応、最小限のトレーニングデータでの精度向上など、標準NLUで直面する課題に対してLLMsを活用し精度向上が見込まれます。これにより、より自然な会話体験を提供することが可能になります。この機能の利用に際して権限や設定の変更は不要です。カナダ（中央）とヨーロッパ（ロンドン）を除く、Amazon Lexが運用されているすべての商用AWSリージョンで利用可能です。詳細は ドキュメント をご確認ください。 Announcing price reductions for Amazon SageMaker AI GPU-accelerated instances 先日のAmazon EC2 NVIDIA GPU搭載インスタンスの価格削減の発表に続き、生成AIモデル開発の費用対効果を高めるため、Amazon SageMaker AIインスタンスの価格も最大45%の値下げが発表されました。この価格削減は、P4（P4dとP4de）およびP5（P5、P5e、P5en）のインスタンスタイプが対象で、オンデマンドとSavings Plan価格の両方に適用されます。加えて、SageMaker HyperPod上のフレキシブルトレーニングプランの価格についても、米国以外のすべてのリージョンにおいて、P5、P5e、P5en、およびtrn1インスタンスタイプの値下げが発表されています。これらの価格アップデートは、コスト削減を直接お客様に還元しながら、GPUコンピューティングをより利用しやすくするというAWSのコミットメントを反映したものです。 Amazon Verified Permissions reduces authorization request price by up to 97% Amazon Verified Permissionsの、単一の認可リクエストの価格が最大97%削減し、100万APIリクエストあたり5ドルになりました。この価格削減により、ユーザーアクションに対する認可チェックをする際のコスト効率が大幅に向上します。Amazon Verified Permissionsはスケーラブルでフルマネージド型の認可サービスとして、Cedarを使用したアクセス制御を提供し、アプリケーションのセキュリティと開発効率を向上させるサービスです。この価格削減は2025年6月12日から全リージョンで適用され、追加のアクションなしで適用されます。 6/13(金) AWS announces open-source AWS API Models すべてのAWSサービスのAPI定義ファイルとサービスモデルパッケージの公式ソースが提供されるようになりました。これらのモデルは日次でGitHubリポジトリとMaven Centralに公開されます。開発者は実際のAWSサービスと同じモデル定義を活用できるようになることで、モックテストやMCPサーバーのニーズの進化といった開発ツールのユースケースに使用できます。詳細についてはこちらの ブログ をご確認ください。 AWS KMS adds support for post-quantum ML-DSA digital signatures AWS KMSが、量子コンピューティングの脅威に対応するために設計された量子耐性デジタル署名アルゴリズムであるFIPS 203 Module-Lattice Digital Signature Standard（MLDSA）のサポートを開始しました。このNIST標準の耐量子署名アルゴリズムは、特にファームウェアやアプリケーションコード署名の保護が必要な場合や、長期的な署名の有効性が求められる場合に有用です。既存のKMS APIとの統合を維持しながら、3つの新しいキー仕様（ML_DSA_44、ML_DSA_65、ML_DSA_87）が導入され、生の署名と事前ハッシュ化された変種（External Mu）の両方をサポートします。現時点では米国西部（北カリフォルニア）およびヨーロッパ（ミラノ）で利用可能です。残りの商用AWSリージョンは今後数日中に対応予定です。詳細については ブログ や、 ドキュメント をご確認ください。 Extend Amazon Q Developer IDE plugins with MCP tools Amazon Q Developerが、IDEプラグインでModel Context Protocol（MCP）のサポートしました。これにより開発者は外部ツールを活用してより豊富なコンテキストを持つ開発ワークフローを実現できるようになります。MCPサーバーはQ Developerのユーザーインターフェースで簡単に管理でき、ネイティブツールとMCPサーバーベースのツールをまたがるタスクによる柔軟な開発環境を構築できます。この機能は、Visual Studio Code、JetBrains IDE、Amazon Q Developer CLIで利用可能です。詳細については ドキュメント と ブログ をご確認できます。 それでは、また来週！ ソリューションアーキテクト 根本 裕規 著者について 根本 裕規(Yuki Nemoto) AWS Japan のソリューションアーキテクトとして、金融機関のお客様の AWS 活用や個別案件の技術支援を担当しています。過去には公共部門やモダナイゼーションのスペシャリストもしていました。好きなサービスは AWS CodeBuild です。週末はオフロードバイクのレースをしています！

本記事は 2025 年 6 月 5 日に公開された “ Introducing an agentic coding experience in Visual Studio and JetBrains IDEs ” を翻訳したものです。 開発者は、コードのデバッグ、単体テストの作成、ビルドプロセスの検証といった繰り返し行う作業に膨大な時間を費やしています。そして、そうした時間はイノベーションや問題解決にもっと活用すべきです。このような課題を解決するため、Amazon Q Developer はインテリジェントなコーディングアシスタント機能を Visual Studio と JetBrains 統合開発環境（IDE）に拡張しました。この新しいエージェント体験は、あなたの代わりに積極的に動作し、ワークスペースを自動的に分析してコードを修正し、コマンドを実行して開発プロセスを効率化します。 このブログ記事では、Amazon Q Developer がコード変更を検証するために、単体テストの作成と実行を自動化し、一般的な問題を特定して解決することでビルドプロセスを効率化する方法について説明します。 2025 年 5 月、同僚の Brian Beach が Amazon Q Developer for VS Code における新しいエージェント型コーディング体験 について書きました。エージェント体験を Visual Studio と JetBrains IDE に拡張することで、Amazon Q Developer はさらに多くの開発者にインテリジェントな自動化をもたらします。 開発者にとってのメリット Amazon Q Developer は、開発者の働き方を変革します。AI アシスタンスを日常の作業の流れにシームレスに統合することで、コンテキストを切り替えたり、好みの開発環境を離れたりすることなく、作業が進められます。 @workspace や @files などの機能を使うことで、IDE 内で非常に関連性の高い推奨事項を得られます。Q Developer の機能を活用すれば、コード差分の生成やコマンドの実行など、さまざまなアクションを自動化し、繰り返し行われるコーディングタスクを効率化したり、複雑な機能をより迅速に実装したり、フローを中断することなく問題をトラブルシューティングしたりできます。 英語、中国語、日本語、スペイン語などの複数言語に対応 しており、Amazon Q Developer は世界中の開発チームに高度な AI アシスタンスを提供し、グローバルな組織全体でのインクルーシブなコラボレーションを促進します。 Amazon Q Developer による開発効率の最大化 Amazon Q Developer は、IDE 内で包括的な機能セットを提供することで、開発プロセスを革新します。この強力なツールが、どのようにコードベースの背景情報を活用し、コンテキスト機能、コードベースのフォルダ、ルールを使用してコーディング体験を向上させるのかを見ていきましょう。 Q Developer はプロンプトコンテキストで特定のファイルやフォルダを定義することで、明示的にガイドできます。特定の情報がどこにあるのかわからなくても問題ありません！Q Developer は @workspaces を使用してコードベースを効率的にナビゲートし、複数のファイルから関連するコードスニペットを収集できます。これは、複数のファイルにまたがるドキュメントを作成したい場合や、バグを修正する必要があるがどこから始めればよいかわからない場合にとくに重要です。 エージェント型チャット機能は、コードベースのフォルダからコンテキストを自動的に導出し、あなたに代わってコマンドを実行します。これは、すでに多くの開発者の心を掴んでいる Q Developer CLI で使用されているのと同じインテリジェントな推論機能を備えています。 コンテキスト管理は、.amazonq/rules/ ディレクトリを通じて設定にも拡張されます。このディレクトリ内で、コーディング標準、テスト要件、セキュリティプロトコル、ドキュメント慣行の ルール を定義できます。一部の顧客は、Q Developer が変更をコミットする方法を定義するルールをすでに作成しています。このルールは、メッセージの詳細とファイルを変更するエージェント型アクションのための Git コミットのテンプレートを提供します。これにより、Q Developer のコードベースへの貢献を特定し、レビューすることが容易になります。 エージェント体験のクイックツアー 2 つのユースケースを順を追って説明します。この例では、Visual Studio IDE を使用します。同様のエージェント型機能は JetBrains IDE でもサポートされています。 Bob’s Used Books のサンプルリポジトリ をクローンして Visual Studio 2022 で開いて、一緒に作業を進めてみましょう。 Amazon Q Developer 拡張機能 を追加または更新することを忘れないでください。 単体テストの作成 Bookstore.Domain プロジェクトには、 Book や ShoppingCart などのドメインオブジェクトが含まれています。 図 1: Bookstore.Domain のドメインオブジェクト Book クラスのテストを含む Bookstore.Domain.Tests という別のプロジェクトがあります。 図 2: Book クラスのテスト ShoppingCart クラスの単体テストを追加したいと思います。Amazon Q Developer に ShoppingCart の単体テストを作成するよう依頼しましょう。また、Amazon Q Developer には、既存のパターンに従って、別のテストプロジェクトにテストクラスを作成してもらいたいと思います。 デフォルトでは、エージェント機能がオンになっています。ソフトウェア開発ライフサイクル（SDLC）の計画・設計の段階にいて、従来の双方向チャットを使用する場合は、エージェント機能をオフにできます。エージェント機能のオン/オフを切り替えるには、Q Developer チャットウィンドウの左下隅にある </> のマークを選択します。 次に、Q Developer に 「@ShoppingCart.cs のテストを作成できますか？既存のテストを見て、同じライブラリを使用してください」 と尋ねます。（訳者注：画像は英語ですが、日本語でのやり取りにも対応しています。）まず、単に質問するのではなく、コマンドを与えていることに注意してください。次に、Q Developer に適切なコンテキストを提供するために、ファイル ShoppingCart.cs を明示的に指定しています。次の画像では、Q Developer が私たちの代わりに行動していることがわかります。エージェント型コーディングモードでは、Q Developer はアクションを実行してコマンドを実行できます。この例では、ファイルの読み取り、ファイルへの書き込み、そしてあなたの許可を得てからコマンドを実行しています。 図 3: 新しいテストを作成するためのプロンプト コマンドを使用して、Q Developer はソリューション構造を分析し、 Bookstore.Domain.Tests というプロジェクトがあることを理解し、 ShoppingCart の単体テストを含む新しいファイルを作成しました。 図 4: テストケースの概要 Bookstore.Domain.Tests プロジェクトに ShoppingCartTests という新しいファイルがあることを確認できます。これは既存のテスト作成戦略と一致しています。 図 5: 生成されたテストケースを含む新しいファイル Visual Studio で、単体テストを実行して合格することを確認できます。 図 6: 新しいテストの成功したテスト実行 ビルドエラーの解決 次の例では、Q Developer を使用してアプリケーションをビルドし、ビルドエラーを解決することで、エージェント型コーディング体験の力を実証します。 この例では、 IShoppingCartRepository インターフェイスのメソッドの 1 つを意図的にスペルミスしています。 AddAsync メソッドが AddAsyn と間違って書かれています。 図 7: メソッド名のスペルミス Bookstore.Domain プロジェクトをビルドしようとすると、予想通りビルドエラーが発生します。Q Developer にエラーを修正するよう依頼しましょう。エージェント型コーディング機能がなければ、ビルドエラーのテキストをチャットウィンドウにコピーして、Q Developer に推奨事項を提供するよう依頼する必要があります。その後、手動で変更を加えてビルドを試すことで、その推奨事項に基づいて行動する必要があります。これは、コマンドを実行し、コマンドの出力を使用してプロンプトのコンテキストを豊かにし、アクションを実行するエージェント型チャットの力を示す一例です。 エージェント型コーディング機能では、Q Developer に 「ソリューションをビルドする際に発生しているエラーを修正できますか？ビルドして確認してください」 と尋ねるだけです。次の画像では、Q Developer が .NET ビルドコマンドを実行してビルドエラーを取得し、関連ファイルを読み取っていることがわかります。 図 8: ソリューションのビルド ファイルを読み取った後、スペルミスを見つけて自動的に修正します。次の画像に示すように、修正が機能したことを確認するためにプロジェクトをビルドします。 図 9: スペルミスの修正   次の画像では、実行結果のサマリとして Amazon Q Developer がエラーの概要、ビルドのために実行したアクション、ビルド実行時に発生した警告を修正するための推奨事項まで提供しています。 図 10: 変更の概要と提案 まとめ Microsoft Visual Studio と JetBrains IDE における Amazon Q Developer のエージェント機能の追加により、Amazon Q Developer は従来のチャットベースの相互作用を超えて、インテリジェントでアクション指向の支援を提供します。ファイルの自動読み取り、コード差分の生成、シェルコマンドの実行、変更の検証を行う能力は、コード品質を維持しながら開発タスクを大幅に加速できる自律性の高さを示しています。私たちが取り上げた例では、テスト作成の自動化からビルドエラーの解決まで、エージェント機能が従来複数の手動ステップを必要としていた一般的な開発タスクを効率化できることを示しています。この新しい機能は、多言語サポートとカスタマイズ可能な開発標準と組み合わせることで、Amazon Q Developer を現代のソフトウェア開発プロセスにおける強力な味方にします。開発チームがコード品質を損なうことなく生産性を向上させる方法を模索し続ける中、Amazon Q Developer のエージェント機能は、IDE 統合 AI アシスタンスにおける重要な進歩を意味します。テスト作成、バグ修正、コード最適化をする際、解決策を提案するだけではなく、コンテキスト認識を維持しながらそれらを実装できる AI アシスタントを持つ能力は、開発者のツールキットにとって革新的な追加となります。 翻訳はApp Dev Consultantの宇賀神が担当しました。 著者について Artur Rodrigues Artur Rodrigues is a Artur Rodrigues は、Amazon Web Services（AWS）の Generative AI 担当プリンシパルソリューションアーキテクトで、次世代開発者体験に焦点を当て、Generative AI を作業の流れに統合することで開発者がより効率的かつ創造的に働けるようにしています。Artur はサイクリングとカナダの美しいブリティッシュコロンビア州の大自然の探索を楽しんでいます。また、ジェラートの愛好家でもあり、サッカーと柔術のファンでもあります。 Neeraj Handa Neeraj Handa は Amazon Web Services のスペシャリストソリューションアーキテクトで、Amazon Q Developer を使用してアプリケーション開発と近代化を加速するために企業顧客とパートナーシップを組んでいます。彼は、AI テクノロジーの使用を通じてより高い生産性とソフトウェア品質を達成するために、組織がソフトウェア開発ライフサイクルを変革することを支援することに情熱を注いでいます。

急速に変化し競争が激化する製造業界において、組織は製品開発プロセスを加速および最適化するために、エンジニアリングシミュレーションなどの仮想エンジニアリングワークフローの採用を増やし続けています。性能、コスト、信頼性、製造性、組立性などの主要な性能指標を評価するための複雑な設計研究への需要が高まる中、シミュレーションプロセス・データ管理（SPDM）は、組織がシミュレーションデータを製品ライフサイクル管理（PLM）システムに管理および統合できるようにすると同時に、製品設計者、シミュレーションアナリスト、製造エンジニアを含む機能横断的なチーム間の相互作用とコラボレーションを促進する重要な記録システムになりつつあります。ただし、世界中に分散しているエンジニアリングチームの性質に対処し、インフラストラクチャコストを管理し、柔軟なデータ移動を実現するには、SPDM 導入の近代化が不可欠です。このブログでは、お客様の製品エンジニアリング変革をサポートするために、Amazon Web Services（AWS）クラウドインフラストラクチャを活用して、費用対効果が高く、安全でスケーラブルな SPDMを構築する方法について説明します。 シミュレーションデータ管理とインフラストラクチャ制約の課題 さまざまな市場への対応が求められることによって、あらゆる業界が製品の複雑化に直面しており、その結果、製品のバリエーションや構成が多様化しています。計算流体力学（CFD）や有限要素解析（FEA）などのデジタルエンジニアリングシミュレーションは、製品の複雑性を管理し、効率的な製品開発を実現するために不可欠であると広く認識されていますが、シミュレーションプロセス自体が大きなボトルネックになることがよくあります。分析チームは、バージョン管理が適切でない古いデータや、結果の提供が遅すぎて設計の方向性に影響を与えられないようなデータを扱うことがよくあります。分野の専門家は、相関作業を行う際に、物理テストとシミュレーションのデータセットを一致させるのに苦労することがよくあります。コンピュータ支援エンジニアリング（CAE）の結果はアナリストの支援がないと閲覧できないため、プログラムマネージャーは多くの場合、可視性に乏しく、洞察を得ることができません。重要なのは、設計者やアナリストが不在の場合、適切なデータに適切なタイミングでアクセスして、情報に基づいたビジネス上の意思決定を行うことが制限要因になるということです。さらに、設計バリエーションの数と実行される関連シミュレーションの数が指数関数的に増加するにつれて、チームが生成する膨大な量のデータで行き詰まる危険性があります。 従来のオンプレミス環境では、最新のセキュリティ標準への対応が困難で、スケーラビリティが限られ、インフラストラクチャコストが高額になるため、これらの問題がさらに悪化します。このような(オンプレミス)環境では容量が固定されており、多くの場合、シミュレーションのニーズに応じてコンピューティングリソースを迅速に拡張できないため、プロジェクトが遅れる可能性があります。さらに、多くの場合、堅牢なディザスタリカバリおよびバックアップ機能が不足しており、システム障害が発生した場合にデータや運用を迅速に復元することが困難です。 Teamcenter Simulation Teamcenter Simulation は、エンジニアリングワークフローに携わるエンジニアやアナリスト向けに設計されたシミュレーションプロセス・データ管理（SPDM）ソリューションです。 Siemens Xcelerator ビジネスソフトウェアプラットフォーム内の製品ライフサイクル管理（PLM）ソリューションであるTeamcenterを基盤とするこのツールは、シミュレーションと物理試験のプロセス、データ、ツール、ワークフローを包括的に管理できます。既存の製品データとシームレスに統合し、すべての関係者に完全なトレーサビリティと可視性を提供します。Teamcenter Simulationを利用することで、エンジニアリングチームはデジタルスレッド全体で効果的に共同作業を行うことができ、一貫性のある効率的な製品開発プロセスを実現できます。 シミュレーションと製品データの連携 シミュレーションデータ管理の課題に対処するには、製造会社はシミュレーション業務をPLM戦略全体の重要な要素として管理する必要があります。Teamcenter Simulationを使用すると、組織はエンジニアリングシミュレーションのデータとプロセスをより適切に管理、理解、再利用できるようになり、製品開発ライフサイクル全体にわたる制御と効率性が向上します。Teamcenter SimulationはTeamcenterプラットフォームに不可欠なモジュールであるため、コンピューター支援設計（CAD）、材料データ、製品パラメーター、製品要件など、シミュレーションに関連するすべてのデータを製品データと関連付けて管理できます。AWS上のTeamcenterを使用することで、組織全体の信頼できる唯一の情報源を確保し、シミュレーションアクティビティを組織のデジタルスレッドに接続できます。この接続は、モデルベースシステムエンジニアリング (MBSE) やモデルベーステスト (MBT) の導入など、企業レベルのデジタルスレッド構想を実現するために不可欠です。デジタルスレッドにより、シミュレーションチームは最新の製品データをシミュレーションの入力として使用し、すべての意思決定者と利害関係者が主要なシミュレーション結果に簡単にアクセスできるようにすることで、製品ライフサイクルを完全にサポートできます。 AWS 上の Teamcenter Simulation による組織的メリット AWS上のTeamcenter Simulationは、お客様のSPDMプロセスとインフラストラクチャのニーズに合わせてカスタマイズできます。AWS のサービスは、スケーラブルなインフラストラクチャとストリーミングサービス、運用コストの削減、従来のオンプレミス環境を上回る堅牢なセキュリティと信頼性により、Teamcenter Simulation インフラストラクチャの課題を克服するのに役立ちます。次のセクションでは、  Well-Architected Framework の原則に基づいて、AWS上にTeamcenterを展開するメリットについて詳しく説明します。 セキュリティの向上 : オンプレミスのTeamcenter実装を管理している組織は、多額のコストと従業員のスキルセットギャップにより、現在のセキュリティプロトコルと暗号化標準を維持する上で課題に直面することがよくあります。さらに、これらの組織は進化する基準へのコンプライアンスを保証する責任を負っており、これはAWS の継続的に更新されるインフラストラクチャが本質的に提供する堅牢なセキュリティおよびコンプライアンス認証と比較すると困難です。また、要件、部品表（BOM）、CADファイル、シミュレーション結果など、Teamcenterで管理される機密性の高い製品情報は、AWSサービスを使用して保存時と転送中の両方で暗号化できます。これにより、重要な製品データの機密性、一貫性、整合性が保証されます。 信頼性の向上 :  AWSリージョン内の複数の アベイラビリティーゾーン により、高可用性とデータレプリケーションが確保されます。Teamcenter Simulationを高可用性アーキテクチャで導入することで、企業は個別のハードウェア障害とデータセンター停止の両方から保護され、重要なPLMデータとプロセスへの継続的なアクセスを確保できます。さらに、AWS のグローバルなリージョンネットワークにより、組織はクロスリージョンレプリケーションによる災害復旧戦略を実装でき、事業継続性をさらに強化し、企業の厳しい稼働時間要件を満たすことができます。対照的に、オンプレミス環境では、ハードウェア障害、停電、拡張性の制限といった脆弱性により、このレベルの信頼性に欠けることが多く、深刻なダウンタイムやデータ損失につながる可能性があります。 コスト最適化 : TeamcenterをAWS上に展開することで、お客様はオンプレミスインフラストラクチャに関連する初期投資を回避できます。その代わり、コンピューティング、ストレージ、ストリーミング、データ処理 (ML と Analytics)、およびその他の使用したリソースに対してのみ料金を支払います。この従量課金モデルは、特にワークロードが変動する組織では、必要に応じてリソースをスケールアップまたはスケールダウンできるため、大幅なコスト削減につながります。企業は AppStream 2.0 サービスを活用して、シミュレーションソフトウェアと統合されたTeamcenter Simulationクライアントをストリーミングできます。このアプローチにより、エンジニアが高価なローカルワークステーションを所有する必要がなくなり、エンドユーザーのITハードウェアとソフトウェアの管理が簡素化されます。 パフォーマンス効率 : お客様は、TeamcenterとCAEアプリケーションの両方に対してカスタマイズされたコンピューティング構成とGPU設定を通じて性能を最適化することができます。CAEシミュレーションでは、効率的な実行と結果取得時間の短縮のために多大な計算能力が必要となるため、オーバープロビジョニングすることなく、必要に応じてコンピューティングリソースをスケールアップまたはスケールダウンし、最適なパフォーマンスを確保することが重要です。 運用効率 : AppStream 2.0では、TeamcenterおよびSimulationアプリケーションを事前構成したカスタムイメージを作成できるため、IT組織はエンドユーザー環境を効率的に管理できます。さらに、 Amazon Relational Database Service for Oracle や FSx for NetApp ONTAP などのマネージドサービスは、データベースとファイルシステムの管理をオフロードします。これにより、組織はITインフラストラクチャとプロセスが合理化され、Teamcenterの管理者はコアアプリケーション管理に集中できるようになります。 AWS 上の Teamcenter Simulation アーキテクチャ AWS では、ウェブサーバー、エンタープライズサーバー、FMS サーバー、ビジュアライゼーション、および Solr サーバーを、異なるアベイラビリティーゾーンの複数の Amazon EC2 インスタンスに分散させることで、Teamcenter を高可用性アーキテクチャで実装できます。このセットアップでは、Amazon RDS for Oracleをフルマネージド型の商用データベースとして使用し、Teamcenter ボリュームストレージは FSx for NetApp ONTAP または Amazon EFS を使用してプロビジョニングされます。このアーキテクチャの中心的な要素は、マネージドストリーミングサービスであるAmazon AppStream 2.0の統合です。これにより、Teamcenter Simulationクライアントをシミュレーションソフトウェアに統合して配信できます。AppStream 2.0 は、高性能な NVIDIA GPU 搭載インスタンス (グラフィックス G4dn、G5、Graphics Pro ファミリーなど) を活用して、シミュレーションワークロードに必要な高度な可視化ニーズをサポートします。 図1 : Siemens Teamcenter Simulation アーキテクチャ AWS Marketplace Siemens Xceleratorのソフトウェアとソリューションのポートフォリオへのシームレスなアクセスは、日々のシミュレーションワークフローにシミュレーションプロセスとデータ管理をうまく実装するために不可欠です。AWS Marketplace では、Siemens Xcelerator 製品の購入を含め、お客様が AWS 上で動作するソフトウェアの発見、導入、管理をより簡単に行うことができます。AWS Marketplace が提供する柔軟な価格体系と透明性の高い請求システムにより、IT 管理者はソフトウェアの消費を効率的に監視し、コスト管理を維持できます。AWS Marketplace でSiemensのソフトウェアを購入するメリットをより包括的に理解するには、Siemensのブログ「 AWS Marketplace がクラウドでの購入体験をどのように変えるか 」を参照してください。 まとめ Teamcenter Simulation はお客様のAWS環境にデプロイすることも、AWS上のTeamcenter Xを介してSaaSソリューションとして導入することもできます。Teamcenter Simulation ソフトウェアをAWSに展開することで、インフラストラクチャコストの削減、コラボレーションの強化、データトレーサビリティ、データ整合性の向上、SPDM実装の最新化など、様々なメリットがあります。AWS のクラウドネイティブサービスを利用することで、組織は Well-Architected SPDM ソリューションを構築し、製品ライフサイクルを管理するための安全でスケーラブルで高性能な基盤を提供できます。 AWS Marketplace   は、Siemens Digital Industries Softwareのソリューションを幅広く提供しています。AWS Marketplace で入手可能なSiemens製品の全リストをご覧ください。また、AWS とシーメンスのコラボレーションの詳細については、公式 パートナーシップウェブサイト をご覧ください。 このブログにご協力いただいた以下の方々にも心より感謝申し上げます。 ·       Noah Jackson (AWS グローバル EUC ソリューションアーキテクト) ·       Indrakanti Chakravarthy（Siemens 戦略プログラムマーケティングディレクター） Chandan Murthy Chandan Murthy は AWS でシニアパートナーソリューションアーキテクトを務め、AWS の戦略的パートナーが AWS プラットフォーム上で非常に効率的でスケーラブルなソリューションを設計および構築できるよう支援することに専念しています。20 年の経験を持つ Chandan は、Teamcenter や Mendix などのプラットフォームでの技術ソリューション設計の確固たる基盤を持っています。この専門知識と AWS での職務により、AWS のお客様が PLM やローコード産業用ソリューションを AWS に実装できるよう支援しています。 Vedanth Srinivasan Vedanth Srinivasan は、アマゾンウェブサービスのエンジニアリング&デザインおよび市場開拓 (GTM) 向けソリューションの責任者です。業界横断型ソリューションに重点を置いているのは、ハイパフォーマンスコンピューティング (HPC) や製品ライフサイクル管理 (PLM) などのコンピュータ支援エンジニアリング (CAE)、製品ライフサイクル管理 (PLM) のほか、モデルベースシステムエンジニアリング (MBSE)、デジタルスレッド、デジタルツインソリューションなどの高次ワークロードです。自動車、航空宇宙、防衛、石油・ガス、ヘルスケア業界にわたる高度なエンジニアリング・ワークフローの開発と展開において 20 年以上の経験があります。 Wouter Dehandschutter, PhD Wouter は、シーメンス・インダストリー・ソフトウェアのテクニカル・プロダクト・マネジメント・ディレクターであり、シーメンスのシミュレーション・プロセスおよびデータ管理（SPDM）の戦略とロードマップを担当しています。ベルギーのルーベン大学でメカトロニクス・エンジニアとして卒業し、ルーベン大学で博士号を取得しました。Lernout & Hauspie や、後にシーメンス・インダストリー・ソフトウェアに買収された LMS International で職務を歴任しました。シーメンスでは、耐久性試験と解析、試験データ管理、メカトロニクス・システム・シミュレーションとシミュレーション・モデル管理のためのCAEアプリケーションの製品開発と製品管理で複数の役職を歴任してきました。現在、Wouter は Teamcenter Simulation の製品ロードマップを管理し、製品ライフサイクルと密接に関連するシミュレーションプロセスとデータのマルチドメイン管理を行っています。 翻訳はソリューションアーキテクトの 山田航司 が担当しました。原文は こちら です。

本記事は 2025年5月12日に公開された “ Performance and metrics enhancements for AWS Transit Gateway and AWS Cloud WAN ” を翻訳したものです。 AWS は 2024年後半に AWS Transit Gateway と AWS Cloud WAN において、以下のいくつかの機能強化を行いました。 Transit Gateway および AWS Cloud WAN における Path MTU Discovery (PMTUD) のサポート アベイラビリティゾーン（AZ） の認識を改善するためのアプライアンスモードでのルーティング機能の強化 AZ ごとの CloudWatch メトリクスへの対応 AWS Cloud WAN におけるサービスの挿入操作に関する機能の強化 この記事では、これら4つの機能強化がどのように動作するのか、AWS ネットワークインフラストラクチャ全体に対してどのような価値を提供するのか、そしてこれらの機能を利用する上での重要な考慮事項について解説します。 1. Transit Gateway および AWS Cloud WAN における Path MTU Discovery (PMTUD) のサポート 2024年11月、AWS は Transit Gateway と AWS Cloud WAN の両方において PMTUD をサポート したことを発表しました。この機能強化により、Transit Gateway と AWS Cloud WAN は現在 IPv4 と IPv6 の両方において PMTUD をサポートしています。 Transit Gateway と AWS Cloud WAN コアネットワークエッジ (CNE) における PMTUD の動作 PMTUD は、2つのホスト間におけるパス MTU を決定するために用いられます。パス MTU とは、送信側ホストと受信側ホストとの通信においてサポートされる最大パケットサイズです。2 つのホスト間のネットワークにおいてサポートされる MTU サイズが異なっている場合、PMTUD がサポートされているとパス上のネットワークデバイス（ここでは Transit Gateway や AWS Cloud WAN CNE）が送信側ホストに対して Internet Control Message Protocol (ICMP) メッセージで応答し、ネットワークパスでサポートされている最小の MTU サイズを通知することで、通知された MTU サイズ以下での再送を要求します。もしこの仕組みがなかった場合には、以下の図で示すように、送信されたパケットのサイズが受信側ホストで対応可能なサイズよりも大きかった場合にパケットドロップが発生する可能性があります。 図 1: PMTUD パケットフロー PMTUD がサポートされる以前では、Transit Gateway や AWS Cloud WAN CNE がサポートする最大 MTU サイズ（8500 bytes）を超えるジャンボフレームパケットを受信した場合には、VPC アタッチメントにおいて通知されることなく破棄されていました。PMTUD のサポートによって、このようなパケットが確認された場合には送信側ホストに対して IPv4 の場合は ICMP Fragmentation Needed メッセージ（Type 3、Code 4）が、IPv6 の場合は Packet Too Big (PTB) メッセージが ICMPv6 (Type 2) で通知されるようになります。これにより、送信元ホストは適切なパケットサイズへ調整した上で再送を行うことが可能となり、それ以降のネットワーク間でのサポートされるパケットサイズの不一致に伴うパケットドロップの発生を抑制することができます。 ユースケース Amazon Linux の Amazon Machine Image (AMI) では既定の最大 MTU サイズは 9001 byte（ジャンボフレーム）となっています。Transit Gateway および AWS Cloud WAN における PMTUD のサポートによって、ユーザーは Amazon Elastic Compute Cloud (Amazon EC2) において引き続き 9001 byte のジャンボフレームを使用しつつ、最大 MTU サイズとして 8500 byte までのサポートとなるこれらのサービスを経由した通信を使用する場合においても、このジャンボフレームの既定値を変更する必要性はありません。 同一 AWS リージョン内での VPC Peering においては最大 9001 byte のジャンボフレームがサポートされています。 一方で、Transit Gateway や AWS Cloud WAN の最大 MTU サイズは 8500 byte であるため、従来は VPC Peering からこれらのサービスを利用する構成へ移行する際には VPC 内の全ての EC2 インスタンスにおいて MTU サイズを 8500 byte 以下に変更する必要がありました。Transit Gateway および AWS Cloud WAN における PMTUD のサポートによって、そのような対応は不要となり、移行に際しての工数が大幅に削減されます。 考慮事項 Transit Gateway および AWS Cloud WAN における PMTUD 機能は既定で有効となっているため、ユーザーは設定変更を行う必要性はありません。 セキュリティグループとネットワークアクセスコントロールリスト（NACL）において、 必要な ICMP ルール を許可する必要があります。 執筆時点においては、Transit Gateway および AWS Cloud WAN において AWS Site−to−Site VPN や AWS Direct Connect を利用する場合や、ピアリングを構成する場合における PMTUD はサポートしていません。 Transit Gateway でインスペクション VPC を用いてサードパーティの仮想アプライアンスを通信が通過する必要がある場合には、それらのネットワーク仮想アプライアンスにおいてジャンボフレームが有効となっていることを確認する必要があります。 詳細については、 Transit Gateway における MTU の考慮事項 および EC2 インスタンスにおける MTU の設定について のユーザーガイドを参照してください。 2. Transit Gateway と AWS Cloud WAN におけるアプライアンスモードでのルーティング機能強化による AZ 認識の強化 2つ目の機能強化として、Transit Gateway および AWS Cloud WAN CNE におけるパケットルーティングが改善されました。このルーティングプロセスにおける AZ 認識に関する機能強化は 2024 年 11 月 30 日に、Transit Gateway および AWS Cloud WAN が使用可能な全ての AWS リージョンに展開されました。 アプライアンスモードは、ファイアウォールやインライン分析、その他の通信経路に挿入して使用される仮想アプライアンスなどをサポートするための インスペクション VPC アーキテクチャ を実現するために実装されました。これらのセキュリティアプライアンスは、ネットワーク接続情報を維持しつつ 適切にトラフィックフローの検査および制御 を行います。たとえば、ファイアウォールは外部への送信トラフィックの開始を検出すると、その返信トラフィックを適切に評価するために必要となる接続状態についての情報を作成します。しかし返信トラフィックが別の AZ に配置されているファイアウォールに転送されてしまった場合、そのファイアウォールは接続状態についての情報を保持していないため返信トラフィックをブロックしてしまうことになります。アプライアンスモードは、このような問題の発生を防止するために、送受信トラフィックが同じ AZ の同じセキュリティアプライアンスを通過するように対称ルーティングと呼ばれる制御を行います。 これまでは、VPC アタッチメントにおいて アプライアンスモード が有効になっている場合、Transit Gateway および AWS Cloud WAN CNE における対称ルーティングではフローハッシュアルゴリズムに基づいてトラフィックの AZ を判断していました。このアルゴリズムは IP パケットにおける 4 タプル に基づいており、トラフィックフローの送信元および宛先の AZ については考慮されていなかったため、トラフィックが異なる AZ を経由する遠回りな経路となってしまう場合がありました。 この問題に対して、今回の AZ 認識の強化により、Transit Gateway と AWS Cloud WAN CNE はトラフィックパスの選択において、トラフィクフローの送信元と宛先の両方の AZ を考慮するようになり、フローの送信元と宛先が同じ AZ にある場合には、トラフィックはインスペクション VPC を経由する場合であっても同じ AZ 内に留まるようになりました。これにより、より効率的なルーティングとなり、レイテンシーを低減できる可能性があります。 この機能強化によるトラフィック最適化シナリオ 次の図で示すように、同じ AZ（use1-az1）に配置されているリソース間での Transit Gateway によってインスペクション VPC を経由させるトラフィックフローを考えてみましょう。このフローでは、use1-az1 と use1-az2 の2つの AZ にアタッチメント接続を構成したインスペクション VPC を経由します。今回の機能強化以前では、送信元と宛先の両方のリソースが use1-az1 にあったとしても、トラフィクが use1-az2 にあるインスペクションアプライアンス経由となる可能性がありました。今回の機能強化によって、Transit Gateway は送信元と宛先のリソースが use1-az1 にある場合には use1-az1 側のインスペクションアプライアンスを経由させるようになるため、AZ アフィニティが維持され、レイテンシーの低減とより予測可能なネットワークパフォーマンスが実現されます。 図 2: アプライアンスモードにおける AZ アフィニティ このアプライアンスモードの機能強化は、Transit Gateway と AWS Cloud WAN CNE を通過する既存のフローには影響を与えません。新しいフローのみがこの新しい動作仕様に基づいてルーティングされるため、既存ワークロードのスムーズな移行が可能です。AZ アフィニティは自動的に適用されるため、特に有効化の必要はありません。また、この機能強化の利用において追加のコストはありません。この機能強化によって、Transit Gateway と AWS Cloud WAN を利用する構成における AZ 間ネットワークトラフィックの管理がより改善されることとなります。 3. Transit Gateway と AWS Cloud WAN における AZ ごとの CloudWatch メトリクスの可視性強化 Transit Gateway と AWS Cloud WAN において、CloudWatch での AZごとのメトリクスに対応する重要な機能強化がリリースされました。この新機能により、AZごとでのトラフィック状況やパフォーマンスについてより詳細に可視化できます。この新機能によって、入出力バイト数や、入出力パケット数、ドロップパケット数などのパフォーマンスとトラフィックに関するメトリクスを用いてグローバルなネットワークのモニタリングが可能です。これらのメトリクスは 2024 年 11月 11 日に提供が開始され、Transit Gateway と AWS Cloud WAN を利用可能な全ての AWS リージョンでご利用頂けます。なお、これらのメトリクスは従来はアタッチメントのレベルのみで提供されていました。 AZごとのメトリクスに対応したことによって、トラフィックが AZ 間でどのように分散されているかについて、運用上の分析が可能となります。たとえば、Transit Gateway と AWS Cloud WAN のクォータは AZ ごとに設定されるため、この機能強化によって AZ ごとのトラフィックフローに対するクォータの影響をより詳細に把握することができます。AZ ごとのメトリクスは、リソース所有者のアカウントと、アタッチメント所有者のアカウント（クロスアカウントシナリオの場合）の両方に対して公開されます。 Transit Gateway における CloudWatch での AZごとのメトリクス CloudWatch コンソールで [メトリクス] > [すべてのメトリクス] を選択します。 メトリクスとして [TransitGateway] > [Per-TransitGatewayAttachment AvailabilityZone Metrics] を選択します。 グラフに含めたいメトリクスを選択します（チェックボックスにチェックを入れます）。各メトリクスの AZ 列もしくは詳細において、対象の AZ （use1-az1 や use-az2 など）を確認できます。 図 3 は、Transit Gateway の AZ ごとのメトリクスと集約されたメトリクスをグラフ化した表示例です。 図 3: Transit Gateway について CloudWatch における AZ ごとおよび集約されたメトリクスの表示例 これらの新しいメトリクスを使用するには、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイスCLI 、もしくは AWS SDK を使用して CloudWatch にアクセスし、AZ 単位のデータに基づくカスタムダッシュボードやアラームを作成できます。これらのメトリクスを有効化するために必要な追加の操作はありません。サポートされているアタッチメントタイプに対して自動的に利用可能となります。 AZ ごとのメトリクスの使用に対して追加のコストはありません。ただし、 AWS 無料利用枠 を超える API 操作に対しては 標準の CloudWatch 料金 が適用されます。詳細については、 Transit Gateway の CloudWatch メトリクス や AWS Cloud WAN の CloudWatch メトリクス のガイドを参照してください。 4. AWS Cloud WAN におけるサービス挿入に関する運用機能の強化 このセクションは、 AWS Cloud WAN における以下のコンポーネント についての理解を前提としています：グローバルネットワーク、コアネットワーク、ネットワークポリシー、アタッチメント、コアネットワークエッジ（CNE）、ネットワークセグメント、そしてネットワーク機能グループ（NFG）と呼ばれる AWS Cloud WAN におけるサービス挿入 機能。 ネットワーク機能グループ（NFG） NFG（図4）は、内部的には、特別なネットワークやセキュリティ機能をホストするVPCに対するネットワークアタッチメントの集合で構成されている単一のセグメントです。これらの機能としては、次世代ファイアウォール（NGFW）や侵入検知システム（IDS）、侵入防止システム（IPS）、 AWS Network Firewall 、 Gateway Load Balancer などが含まれ、グローバルな AWS Cloud WAN ネットワークの一部としてデプロイされます。 NFG を使用すると、AWS Cloud WAN に接続された同一セグメントもしくはクロスセグメント間での通信を自動的に Cloud WAN に接続されたVPC に展開されているネットワーク機能を経由させることができます。その際には、適用させたいネットワーク機能が存在するコアネットワークアタッチメント（VPC、Site-to-Site VPN、Direct Connect、Transit Gateway ルートテーブル等）と、トラフィックを指定したネットワーク機能にリダイレクトさせる必要のあるセグメント（1つもしくは複数）をそれぞれ指定することができます。AWS Cloud WAN は NFG によって指定したセグメント間のネットワークトラフィックをコアネットワークアタッチメントを経由するように制御します。この NFG によるトラフィックの制御は、コアネットワークにおける同一リージョン内（イントラリージョン）トラフィックと、リージョン間（インターリージョン）トラフィックの両方に対して適用できます。 この機能強化が提供される前は、NFG においてサービス挿入を構成するためには、[セグメントアクション] の [サービス挿入] > [アクション] において [以下経由で送信]（send-via）もしくは [以下に送信]（send-to）を構成する前に、NFG を事前にコアネットワークアタッチメントに関連付ける必要があったため、新しいリージョンに Cloud WAN を拡張をする際の手順を複雑化させる要因となっていました。 今回のこのサービス挿入に関する運用機能の強化によって、AWS Cloud WAN のポリシーの適用を成功させる前提として、NFG をアタッチメントに関連付けることは必要ではなくなりました。アタッチメントが関連付けられていない NFG に対してセグメントアクションで [以下経由で送信]（send-via）もしくは [以下に送信]（send-to）を設定していていても、AWS Cloud WAN におけるポリシーの適用は成功します。ただし、関連付けが構成されるまで NFG に対するサービス挿入トラフィックは以下の図で示すようにブラックホールとして扱われます。 図 4: AWS Cloud WAN NFG この機能強化によって、AWS Cloud WAN を新しい AWS リージョンに展開することが容易となり、ポリシー管理の複雑さが削減されることで、サービス挿入の構成が管理しやすくなります。 AWS Cloud WAN の標準料金 以外に、サービス挿入を利用するために必要となる追加の料金はありません。 まとめ 今回ご紹介した Transit Gateway および AWS Cloud WAN におけるこれらの機能強化は、ネットワークのパフォーマンスや可視性、運用効率などを改善するものです。これらの機能強化は、AWS がネットワークの管理機能を改善するとともに運用の負荷を削減することに対する継続的なコミットメントを示しています。複雑なマルチ AZ アーキテクチャの管理や、セキュリティ統制の実装、ネットワークパフォーマンスの最適化などにおいて、今回ご紹介した機能を活用頂くことで、より信頼性が高く効率性の高いクラウドネットワークを構築頂けます。 より詳細なガイダンスやベストプラクティスについては、 Transit Gateway および AWS Cloud WAN の各ガイドをご参照いただくか、AWS のアカウントチームもしくは AWS サポートにお問い合わせください。 著者について Tushar Jagdale Tushar は AWS においてネットワークを専門とするソリューションアーキテクトであり、AWS においてスケーラブルで高い可用性とセキュリティを確保した、耐障害性とコスト効率を兼ね備えたネットワークの設計・構築するお客様を支援しています。データセンターのセキュリティおよびクラウドネットワークの構築に関して 15 年を超える経験があります。 Andrew Troup Andrew は AWS におけるエンタープライズテクノロジストで、20 年以上にわたり米国連邦政府の顧客における複雑な技術的変革を支援してきた経験があります。ネットワーク、コンピュート、レジリエンス、オブザーバビリティの専門家として、AWS のお客様に対して実践的な経験に基づくガイダンスの提供に情熱を注いでいます。 翻訳は Technical Account Manager の畝高 孝雄が担当しました。原文は こちら です。

本記事は 2025 年 5 月 29 日に AWS Machine Learning Blog で公開された Real-world applications of Amazon Nova Canvas for interior design and product photography を翻訳したものです。翻訳はソリューションアーキテクトの川戸渉が担当しました。 ブログ翻訳時点（2025 年 6 月）では、Amazon Nova Canvas は英語のみをサポートしており、プロンプトは英語で記載する必要があります。本記事では理解の助けになるよう、英文プロンプトに和訳を併記しています。 AI 画像生成技術が今日のビジネスの現場で重要性を増す中、多くの企業や組織は、業界特有の課題を解決するためにこの技術をどう活用すべきか模索しています。AI 画像生成には計り知れない可能性があるものの、自社の独自のニーズに合わせて効果的に活用できている企業はまだ少ないのが実情です。 この記事では、 Amazon Nova Canvas が高度な画像生成技術を通じて実際のビジネス課題をどのように解決できるかを探ります。特に、この技術の強力さと柔軟性を示す 2 つの具体的なユースケースに焦点を当てています： インテリアデザイン – セグメンテーションを活用した画像調整技術により、インテリアデザイナーはデザイン案を素早く何パターンも試せるようになり、クライアントへのプレゼンテーション資料を作成する時間とコストを大幅に削減できます 商品写真 – アウトペインティング機能を使えば、商品の撮影担当者は大がかりな撮影をしなくても、商品をさまざまな環境の中で魅力的に見せる画像を作成できます インテリアデザイン会社でデザイン案の作成プロセスを効率化したい方も、小売業で商品写真の撮影コストを削減したい方も、この記事が役に立ちます。Amazon Nova Canvas の先進機能を活用して、ビジネス目標を達成する方法を紹介します。それでは、これらのパワフルなツールがどのように画像制作の流れを一新するのか、具体的に見ていきましょう。 前提条件 本ソリューションを試すには、以下の前提条件が必要です： AWS アカウント ( このソリューションに必要な AWS リソースを管理するため ) AWS リージョン us-east-1 における Amazon Bedrock 上の Amazon Nova Canvas モデルへの アクセス権 Amazon Bedrock コンソールでソリューションをテストする場合は、Amazon Bedrock プレイグラウンドの使用経験が必要です。詳細については、 Generate responses in the console using playgrounds を参照してください。 Amazon SageMaker AI ノートブックでコーディングする場合は、Python プログラミング言語 (v3.12) の知識が必要です。詳細については、 Run example Amazon Bedrock API requests using an Amazon SageMaker AI notebook を参照してください。SageMaker ノートブックインスタンスのセットアップ手順については、 Create an Amazon SageMaker notebook instance を参照してください。 インテリアデザイン あるインテリアデザイン会社は次のような問題を抱えていました：デザイナーたちがクライアントへのプレゼンテーション用に写実的なデザインを作成するのに何時間もかけており、同じ部屋に対して異なるテーマや装飾要素を用いた複数のバリエーションが必要でした。従来の 3D レンダリングは時間がかかり、コストも高くなります。この問題を解決するために、Amazon Nova Canvas の画像調整機能 ( セグメンテーション ) を使用することで、既存の部屋の写真を素早く様々なバージョンに変換できます。元となる画像を分析して主要な形や構造を識別し、これをもとにセグメンテーションマスクが作成されます。このマスクが画像生成をガイドする役割を果たします。生成された新しい画像は元の画像のレイアウトを忠実に踏襲しながらも、各領域の境界内で AI モデルが創造的なアレンジを加えることができます。 以下の画像は、元の入力画像、入力に基づいたセグメンテーションマスク、そして 2 つの異なるプロンプトに基づく出力例を示しています。 リビングルームの入力画像 リビングルームのセグメンテーションマスク プロンプト : A minimalistic living room ( ミニマリスティックなリビングルーム ) プロンプト : A coastal beach themed living room ( 海辺をテーマにしたリビングルーム ) この記事では、リビングルームの基本的な構造はそのままに、インテリアのデザイン要素だけを変更する方法をご紹介します。この手法を使えば、簡単なプロンプトと元の写真だけで、わずか数分のうちに様々なデザインバリエーションを作成できます。下記のコードは、セグメンテーション機能を使った画像加工に必要な API リクエストの構造を示しています。変換に必要な各種設定は API リクエストを通してモデルに送信されます。なお、画像が不自然に歪まないよう、出力画像のサイズは入力画像と同じにすることをお勧めします。 { "taskType": "TEXT_IMAGE", "textToImageParams": { "conditionImage": string (Base64 encoded image), #Original living room "controlMode": "SEGMENTATION", "controlStrength": float, #Specify how closely to follow the condition #image (0.0-1.0; Default: 0.7). "text": string, #A minimalistic living room ( ミニマリスティックなリビングルーム ) "negativeText": string }, "imageGenerationConfig": { "width": int, "height": int, "quality": "standard" | "premium", "cfgScale": float, "seed": int, "numberOfImages": int } } taskType オブジェクトは実行する処理タイプを指定するもので、それぞれの処理タイプに応じたパラメータがあります。これに対して、 imageGenerationConfig オブジェクトには、背景削除を除くすべての処理タイプに共通する基本パラメータが含まれています。各種生成タイプに関するリクエスト / レスポンス構造の詳細については、 Request and response structure for image generation を参照してください。 以下の Python コードは、Amazon Bedrock 上の Amazon Nova Canvas v1.0 モデルを呼び出して画像加工を行う方法を示しています： import base64 #For encoding/decoding base64 data import io #For handling byte streams import json #For JSON operations import boto3 #AWS SDK for Python from PIL import Image #Python Imaging Library for image processing from botocore.config import Config #For AWS client configuration #Create a variable to fix the region to where Nova Canvas is enabled region = "us-east-1" #Create Bedrock client with 300 second timeout bedrock = boto3.client(service_name='bedrock-runtime', region_name=region, config=Config(read_timeout=300)) #Original living room image in current working directory input_image_path = "Original Living Room.jpg" #Read and encode the image def prepare_image(image_path): with open(image_path, 'rb') as image_file: image_data = image_file.read() base64_encoded = base64.b64encode(image_data).decode('utf-8') return base64_encoded #Get the base64 encoded image input_image = prepare_image(input_image_path) #Set the content type and accept headers for the API call accept = "application/json" content_type = "application/json" #Prepare the request body api_request = json.dumps({ "taskType": "TEXT_IMAGE", #Type of generation task "textToImageParams": { "text": "A minimalistic living room", #Prompt ( ミニマリスティックなリビングルーム ) "negativeText": "bad quality, low res", #What to avoid "conditionImage": input_image, #Base64 encoded original living room "controlMode": "SEGMENTATION" #Segmentation mode }, "imageGenerationConfig": { "numberOfImages": 1, #Generate one image "height": 1024, #Image height, same as the input image "width": 1024, #Image width, same as the input image "seed": 0, #Modify seed value to get variations on the same prompt "cfgScale": 7.0 #Classifier Free Guidance scale } }) #Call the model to generate image response = bedrock.invoke_model(body=api_request, modelId='amazon.nova-canvas-v1:0', accept=accept, contentType=content_type) #Parse the response body response_json = json.loads(response.get("body").read()) #Extract and decode the base64 image base64_image = response_json.get("images")[0] #Get first image base64_bytes = base64_image.encode('ascii') #Convert to ASCII image_data = base64.b64decode(base64_bytes) #Decode base64 to bytes #Display the generated image output_image = Image.open(io.BytesIO(image_data)) output_image.show() #Save the image to current working directory output_image.save('output_image.png') 商品写真 あるスポーツシューズ企業は次のような課題を抱えていました：新しく作ったランニングシューズが様々な場所 ( 陸上トラック、自然の中など ) で使えることをアピールしたいのですが、それぞれの環境で実際に撮影すると、場所代や撮影費用がかさんでしまいます。さらに、シューズの色違いやデザインの違いなど、すべてのバリエーションで撮影するとなると、さらに多くの時間と費用がかかってしまいます。こうした問題の解決策として、Amazon Nova Canvas を使用して 1 枚の商品写真から多様なショットを生成することができます。アウトペインティング機能を使えば、画像の背景を置き換えることが可能です。モデルに対して “Shoes ( 靴 )” といったマスクプロンプトを含めることで、画像の特定部分を保存するよう指示できます。マスクプロンプトとは、アウトペインティングの処理中に変更せずにそのままにしたい画像内のオブジェクトを自然言語で説明したものです。その後、新しいプロンプトを使って、さまざまな異なる背景の靴の画像を生成できます。 以下の画像は、最初の入力画像、“Shoes ( 靴 )” 用に作成されたマスク、そして2つの異なるプロンプトに基づく出力例を示しています。 ランニングシューズのスタジオ写真 “Shoes ( 靴 )” 用に作成されたマスク プロンプト : Product photoshoot of sports shoes placed on a running track outdoor ( 屋外の陸上トラックに置かれたスポーツシューズの商品撮影 ) プロンプト : Product photoshoot of sports shoes on rocky terrain, forest background ( 岩の多い地形、森の背景でのスポーツシューズの商品撮影 ) マスクプロンプトの代わりに、保存したい画像の領域を定義するマスク画像を入力することもできます。マスク画像は入力画像と同じサイズでなければなりません。編集する領域は完全な白で、保存する領域は完全な黒で表示します。アウトペインティングのモードは、画像の保持部分と変更部分をどのように処理するかを決めるパラメータです。 DEFAULT モードを選ぶと、保持したい部分と変更する部分の境目が自然につながるようになります。これは、元の背景と似た雰囲気の新しい背景を作りたい場合に適しています。ただし、元の背景と全く異なる背景に変更しようとすると、ハロー効果が現れることがあります。一方、 PRECISE モードでは、保持部分と変更部分の境界をはっきりと区切ります。これは背景を大きく変更する場合に適しており、よりクリアな境界線が得られます。 この記事では、商品の正確さを維持しながらアウトペインティングを使用し、1 枚のスタジオ写真を異なる環境にシームレスに変換する方法を紹介します。以下のコードは、アウトペインティングのための API リクエスト構造を示しています： { "taskType": "OUTPAINTING", "outPaintingParams": { "image": string (Base64 encoded image), "maskPrompt": string, #Shoes "maskImage": string, #Base64 encoded image "outPaintingMode": "DEFAULT" | "PRECISE", "text": string, #Product photoshoot of sports shoes on rocky terrain ( 岩の多い地形でのスポーツシューズの商品撮影 ) "negativeText": string }, "imageGenerationConfig": { "numberOfImages": int, "quality": "standard" | "premium", "cfgScale": float, "seed": int } } 以下の Python コードは、Amazon Bedrock 上の Amazon Nova Canvas v1.0 モデルを呼び出してアウトペインティングによる背景置換を実行する方法を示しています。より多くのコード例については、 Code examples を参照してください。 import base64 #For encoding/decoding base64 data import io #For handling byte streams import json #For JSON operations import boto3 #AWS SDK for Python from PIL import Image #Python Imaging Library for image processing from botocore.config import Config #For AWS client configuration #Create a variable to fix the region to where Nova Canvas is enabled region = "us-east-1" #Create Bedrock client with 300 second timeout bedrock = boto3.client(service_name='bedrock-runtime', region_name=region, config=Config(read_timeout=300)) #Original studio image of shoes in current working directory input_image_path = "Shoes.png" #Read and encode the image def prepare_image(image_path): with open(image_path, 'rb') as image_file: image_data = image_file.read() base64_encoded = base64.b64encode(image_data).decode('utf-8') return base64_encoded #Get the base64 encoded image input_image = prepare_image(input_image_path) #Set the content type and accept headers for the API call accept = "application/json" content_type = "application/json" #Prepare the request body api_request = json.dumps({ "taskType": "OUTPAINTING", "outPaintingParams": { "image": input_image, "maskPrompt": "Shoes", "outPaintingMode": "DEFAULT", "text": "Product photoshoot of sports shoes placed on a running track outdoor", # 屋外の陸上トラックに置かれたスポーツシューズの商品撮影 "negativeText": "bad quality, low res" }, "imageGenerationConfig": { "numberOfImages": 1, "seed": 0, #Modify seed value to get variations on the same prompt "cfgScale": 7.0 } }) #Call the model to generate image response = bedrock.invoke_model(body=api_request, modelId='amazon.nova-canvas-v1:0', accept=accept, contentType=content_type) #Parse the response body response_json = json.loads(response.get("body").read()) #Extract and decode the base64 image base64_image = response_json.get("images")[0] #Get first image base64_bytes = base64_image.encode('ascii') #Convert to ASCII image_data = base64.b64decode(base64_bytes) #Decode base64 to bytes #Display the generated image output_image = Image.open(io.BytesIO(image_data)) output_image.show() #Save the image to current working directory output_image.save('output_image.png') クリーンアップ ソリューションのテストが完了したら、使用していないリソースによる課金を防ぐため、以下のリソースをクリーンアップしてください： SageMaker ノートブックインスタンス内の Jupyter ノートブックをバックアップしましょう SageMaker ノートブックインスタンスをシャットダウンし、削除してください コストに関する考慮事項 AWS にデプロイしたソリューションでは、以下の費用が発生します： Amazon Bedrock での生成 AI 推論に対する料金が発生します。詳細は Amazon Bedrock の料金 を参照してください。 SageMaker ノートブックインスタンスの使用料が発生します。詳細は Amazon SageMaker AI の料金 を参照してください。 まとめ この記事では、ビジネスに大きな価値をもたらす 2 つのシナリオを通じて、Amazon Nova Canvas の実践的な活用法を紹介しました。従来は何時間もかかっていた複数のデザインバリエーションや多様な環境の制作が、わずか数分で可能になります。Amazon Nova Canvas を導入することで、従来の視覚コンテンツ制作にかかるコストを大幅に削減できるでしょう。Amazon Nova Canvas が提供するその他の機能については、 Generating images with Amazon Nova のドキュメントをご覧ください。 次のステップとして、まずは自社のビジネスニーズに最も合致する一つのユースケースから始めることをお勧めします。この記事で紹介したコード例をベースとして、お客様固有の要件に合わせてカスタマイズしてください。基本的な実装に慣れたら、複数の技術を組み合わせながら段階的に規模を拡大していきましょう。また、時間の短縮やコスト削減の実績を記録し、投資対効果を測定することもお忘れなく。企業規模での導入についてさらに詳しいガイダンスが必要な場合は、担当の AWS アカウントチームにご相談ください。 著者について Arjun Singh は、Amazon のシニアデータサイエンティストとして活躍中で、人工知能、機械学習、ビジネスインテリジェンスの分野に精通しています。ビジュアル志向の人物であり、コンテンツ作成における生成 AI 技術に強い関心を持っています。顧客と協力して、顧客の目標達成に向けた機械学習および AI ソリューションの構築に取り組んでいます。シンシナティ大学にて情報システムの修士課程を修了。仕事以外では、テニスや筋トレ、新しいスキルの習得を趣味としています。

本記事は、2024 年 10 月 2 日に AWS Machine Learning Blog で公開された Achieve operational excellence with well-architected generative AI solutions using Amazon Bedrock を翻訳したものです。 大規模な企業は、組織全体で 生成 AI の力を活用するための戦略を策定しています。しかし、生成 AI の規模を拡大し、異なる事業部門 (LOB) での導入を容易にするには、データのプライバシーとセキュリティ、法的要件、コンプライアンス、運用上の課題を組織レベルで管理するという課題があります。 AWS Well-Architected Framework は、数千件のお客様との関わりから得られた AWS のベストプラクティスとガイドを活用し、大規模組織でクラウドを使用する際の課題に対応できるように開発されました。AI には、バイアスの管理、知的財産、プロンプトの安全性、データの整合性など、生成 AI ソリューションを大規模に展開する際に重要な考慮事項となる特有の課題もあります。これは新興分野であるため、ベストプラクティス、実用的なガイダンス、設計パターンを簡単に利用できる形で見つけることは困難です。本稿では、 AWS Well-Architected Framework の運用上の優秀性 (operational excellence) の柱をベースラインとして、AI を安全に大規模利用するために実際のプロジェクトで開発したベストプラクティスとガイドラインを共有します。 Amazon Bedrock は、この取り組みにおいて重要な役割を果たします。これはフルマネージド型のサービスで、Anthropic、Cohere、Meta、Mistral AI、Amazon などの最先端の AI 企業が提供する高性能な基盤モデル (Foundation Model) を単一の API で利用できるほか、セキュリティ、プライバシー、責任ある AI に配慮した生成 AI アプリケーションを構築するための幅広い機能を提供します。 AWS Lambda などのサービスを使用して、生成 AI 機能をアプリケーションに安全に統合およびデプロイでき、シームレスなデータ管理、モニタリング、コンプライアンスを実現できます (詳細については、 モニタリングとオブザーバビリティ をご参照ください)。Amazon Bedrock を使用することで、企業は以下を実現できます： 拡張性 – 事業部門横断で生成 AI アプリケーションをデプロイ セキュリティとコンプライアンス – 業界標準と規制に準拠したデータプライバシー、セキュリティ、コンプライアンスを実施 運用効率 – AWS Well-Architected Framework に沿った監視、ログ記録、自動化のための組み込みツールで運用を効率化 イノベーション – 最先端の AI モデルにアクセスし、リアルタイムデータとフィードバックで継続的に改善 このアプローチにより、企業は運用上の優秀性を維持しながら、大規模に生成 AI を導入することができ、最終的に組織全体でイノベーションと効率性を推進することができます。 生成 AI ワークロードとソリューションの運用における違いは何か Well-Architected Framework の運用上の優秀性の柱は、チームがより多くの時間を顧客に利益をもたらす新機能の構築に費やすことを支援します。この場合、安全でスケーラブルな方法での生成 AI ソリューションの開発に時間を費やすことができます。しかし、生成 AI の観点を適用する場合、その革新的な特性から生じる様々な課題と可能性に対応する必要があります。例えば、以下の側面が含まれます： 大規模言語モデル (LLM) が新しいコンテンツを生成する能力により、複雑性が予測できなくなる可能性がある モデルの学習データの透明性が欠如しているため、知的財産権の侵害が懸念される 生成 AI の精度が低いと、不正確または論争を招くコンテンツが作成される可能性がある リソースの利用には、学習やプロンプト、トークンサイズに応じて必要な大規模な計算リソースを満たすための特定の運用モデルが必要 継続的な学習には、追加のデータアノテーションとキュレーション戦略が必要 コンプライアンスも急速に進化している分野であり、データガバナンスがより繊細かつ複雑になり、課題が生じる レガシーシステムとの統合には、互換性、システム間のデータフロー、パフォーマンスへの潜在的な影響を慎重に考慮する必要がある そのため、生成 AI に対する観点は、これらの課題に対処し、責任ある AI 利用の基盤を提供するために、以下の要素を様々なレベルの規定と強制力を組み合わせる必要があります： ポリシー – 意思決定を導くための原則の体系 ガードレール (安全境界)  – ポリシーの範囲内に留めるための境界を作るルール メカニズム – プロセスとツール AWS は、LLM からの有害な出力を防ぐための手段として Amazon Bedrock Guardrails を導入し、裏側の基盤モデルに関係なく、責任ある AI の出発点として追加の保護層を提供しています。しかし、生成 AI の実践者、データサイエンティスト、開発者が、確立された制御を回避するために幅広いテクノロジー、モデル、データセットを使用する可能性があるため、より包括的な組織的アプローチが重要です。 従来の IT ワークロードとアプリケーションのクラウド導入が成熟するにつれ、企業におけるクラウド利用のリスクを最小限に抑え、開発者体験を簡素化する適切なクラウドソリューションを開発者が選択できるよう支援する必要性が生まれてきました。これは一般的に プラットフォームエンジニアリング と呼ばれ、「あなた (開発者) は構築とテストを行い、プラットフォームエンジニアリングチームがそれ以外のすべてを担当します！」という考え方に要約できます。 成熟したクラウド運用モデルには、通常、クラウドの需要を生み出すことができるビジネスオフィスと、その需要をサポートするセキュリティや DevOps (CI/CD、オブザーバビリティなど) などの支援サービスを提供するプラットフォームエンジニアリングチームが含まれます。これは次の図に示されています。 生成 AI ソリューションにおいては、MLOps やプロンプトの安全性機能など、特定の AI や機械学習 (ML) プラットフォームの構成をサポートするようにサービスが拡張されます。 どこから始めるか 本稿では、運用上の優秀性の指針で定義されている基本的な運用要素について説明することから始めます。 ビジネス成果を中心にチームを組織化： チームがビジネス成果を達成する能力は、リーダーシップのビジョン、効果的な運用、そしてビジネスに沿った運用モデルから生まれます。リーダーシップは、チームが最も効率的な方法で運用し、ビジネス成果を達成できるような適切なクラウド運用モデルを備えた CloudOps 変革に全面的に投資し、コミットする必要があります。適切な運用モデルは、人材、プロセス、テクノロジーの能力を活用して、スケールを実現し、生産性を最適化し、俊敏性 (agility)、即応性 (responsiveness)、適応性 (adaptation) を通じて差別化を図ります。組織の長期的なビジョンは、ステークホルダーやクラウドサービスの利用者に向けて企業全体に伝達される目標に変換されます。目標と運用 KPI はすべてのレベルで整合性が取れているべきです。この実践により、以下の設計原則の実装から得られる長期的な価値が維持されます。 実践的な知見を得るためのオブザーバビリティの実装： ワークロードの動作、パフォーマンス、信頼性、コスト、健全性を包括的に理解する必要があります。重要業績評価指標 (KPI) を確立し、オブザーバビリティのテレメトリーを活用して、十分な情報に基づいた意思決定を行い、ビジネス成果が危険にさらされた場合に迅速に行動を起こしましょう。実用的なオブザーバビリティデータに基づいて、パフォーマンス、信頼性、コストを積極的に改善しましょう。 可能な限り安全に自動化： クラウドでは、アプリケーションコードに使用するのと同じエンジニアリング規律を環境全体に適用できます。ワークロード全体とその運用 (アプリケーション、インフラストラクチャー、構成、手順) をコードとして定義し、更新することができます。その後、イベントに応じてワークロードの運用を開始することで自動化できます。クラウドでは、レート制御、エラー閾値、承認などのガードレールを構成することで、自動化の安全性を確保できます。効果的な自動化により、イベントへの一貫した対応、人的エラーの制限、オペレーターの負担軽減を実現できます。 頻繁で小規模な、元に戻せる変更を行う： コンポーネントを定期的に更新できるよう、スケーラブルで疎結合なワークロードを設計すべきです。自動化されたデプロイ技術と小規模な段階的な変更により、障害が発生した場合の影響範囲が制限され、より迅速な復旧が可能になります。これにより、品質を維持しながらワークロードに有益な変更を加え、市場状況の変化に素早く適応する自信が高まるでしょう。 運用手順を頻繁に改善： ワークロードの進化に合わせて、運用も適切に進化させるべきです。運用手順を使用する中で、改善の機会を探しましょう。定期的なレビューを実施し、すべての手順が効果的であり、チームがそれらに精通していることを確認しましょう。ギャップが特定された場合は、それに応じて手順を更新しましょう。手順の更新をすべてのステークホルダーとチームに伝達しましょう。運用を楽しく学べる形にしてベストプラクティスを共有し、チームを教育しましょう。 障害を予測： ワークロードのリスク特性とビジネス成果への影響を理解するために、障害シナリオを検証することで運用の成功を最大化しましょう。これらのシミュレートされた障害に対する手順の有効性とチームの対応をテストしましょう。テストによって特定された未解決のリスクを管理するために、十分な情報に基づいた意思決定を行いましょう。 すべての運用イベントとメトリクスから学ぶ： すべての運用イベントと障害から得られた教訓を通じて改善を推進しましょう。得られた知見をチーム間および組織全体で共有しましょう。共有する内容には、運用がビジネス成果にどのように貢献するかについてのデータと事例を含める必要があります。 マネージドサービスを使用： 可能な限り AWS マネージドサービスを使用して運用の負担を軽減しましょう。これらのサービスとの相互作用を中心に運用手順を構築しましょう。 生成 AI プラットフォームチームは、概念実証やプロトタイプフェーズから本番環境対応のソリューションへと移行する際の重要な点に注力する必要があります。具体的には、モデルの安全な開発、デプロイ、監視の方法について説明し、運用上およびコンプライアンス上のリスクを軽減することで、AI を大規模に本番環境で採用する際の障壁を低減する方法を説明します。 まず、以下の設計原則に焦点を当てます。 実行可能な知見を得るためのオブザーバビリティの実装 (Implement observability for actionable insights) 可能な限り安全に自動化 (Safely automate where possible) 頻繁で小規模な、元に戻せる変更を行う (Make frequent, small, reversible changes) 運用手順を頻繁に改善 (Refine operations procedures frequently) すべての運用イベントとメトリクスから学ぶ (Learn from all operational events and metrics) マネージドサービスを使用 (Use managed services) 以下のセクションでは、アーキテクチャー図を使用しながら、統制の柱のベストプラクティスについて詳しく説明します。 メトリクス、ログ、トレースを活用してモデル、ガードレール、コストを透明化し制御する 生成 AI フレームワークの統制の柱は、可視性、コスト管理、ガバナンスに焦点を当て、企業が生成 AI ソリューションを安全かつ効率的にデプロイ・運用できるようにします。次の図は、この柱の主要な構成要素を示しています。 オブザーバビリティ 監視体制の構築は、FinOps とガバナンスという他の 2 つのコンポーネントの基盤を築きます。オブザーバビリティは、生成 AI ソリューションのパフォーマンス、信頼性、コスト効率を監視する上で重要です。 Amazon CloudWatch 、 AWS CloudTrail 、 Amazon OpenSearch Service などの AWS サービスを使用することで、企業はモデルのメトリクス、使用パターン、潜在的な問題について可視性を確保でき、予防的な管理と最適化が可能になります。 Amazon Bedrock は、ML モデルとアプリケーションを監視・管理するための堅牢なオブザーバビリティ機能と互換性があります。CloudWatch で収集される主要なメトリクスには、呼び出し回数、レイテンシー、クライアントおよびサーバーエラー、スロットル、入出力トークン数などが含まれます (詳細については、 Monitoring the performance of Amazon Bedrock をご覧ください)。また、 Amazon EventBridge を使用して Amazon Bedrock に関連するイベントを監視することもできます。これにより、特定のイベントが発生した際に特定のアクションを実行するルールを作成でき、監視構成の自動化と応答性を向上させることができます。CloudTrail は、AWS 環境内のユーザー、ロール、または AWS サービスによって Amazon Bedrock に対して行われたすべての API 呼び出しをログに記録できます。これは、個人を特定できる情報 (PII)、モデルの更新、その他の重要なアクティビティなどの機密リソースへのアクセスを追跡するのに特に有用で、企業は堅牢な監査証跡 (Audit Trail) とコンプライアンスを維持できます。詳細については、 Log Amazon Bedrock API calls using AWS CloudTrail をご覧ください。 Amazon Bedrock は、LLM のオブザーバビリティ成熟度モデルを実装するために必要なメトリクスとテレメトリーをサポートしており、以下が含まれます： CloudWatch を通じて、モデルのパフォーマンス、プロンプトの属性情報、コストに関する指標などの LLM 固有のメトリクスを取得し分析 LLM 関連の問題に特化したアラートとインシデント管理の実装 Amazon Bedrock は一般的なコンプライアンス基準の対象範囲であり、自動化された不正利用検出メカニズムを提供するため、セキュリティコンプライアンスと堅牢な監視メカニズムを提供 CloudWatch と CloudTrail を使用した異常検出、使用量とコストの予測、パフォーマンスの最適化、リソース使用率の監視 より良いリソース計画とコスト管理のための AWS 予測サービスの使用 CloudWatch は、AWS サービスやオンプレミスのソースからログ、メトリクス、イベントを収集する、統合された監視とオブザーバビリティのサービスを提供します。これにより、企業は I/O ボリューム、レイテンシー、エラー率など、生成 AI モデルの主要性能指標 (KPI) を追跡できます。CloudWatch ダッシュボードを使用してカスタムの可視化とアラートを作成でき、チームは異常やパフォーマンスの低下を迅速に検知できます。 より高度なオブザーバビリティ要件に対しては、企業は OpenSearch と Kibana のデプロイ、運用、スケーリングを行うフルマネージドサービスである Amazon OpenSearch Service を利用できます。 Opensearch Dashboards は強力な検索と分析機能を提供し、チームは生成 AI モデルの動作、ユーザーとの対話、システム全体のメトリクスをより深く掘り下げることができます。 さらに、 モデル呼び出しのログ記録 を有効にすることで、AWS アカウントにおけるすべての Amazon Bedrock モデル API 呼び出しの呼び出しログ、完全なリクエストレスポンスデータ、およびメタデータを収集できます。呼び出しログを有効にする前に、 Amazon Simple Storage Service (Amazon S3) または CloudWatch Logs の出力先を設定する必要があります。呼び出しログは、 AWS Management Console または API を通じて有効にできます。デフォルトでは、ログ記録は無効になっています。 コスト管理と最適化 (FinOps) 生成 AI ソリューションは急速にスケールし、大量のクラウドリソースを消費する可能性があるため、効果的なコスト管理の実践が不可欠です。 AWS Cost Explorer や AWS Budgets などのサービスを使用することで、企業は使用状況を追跡し、生成 AI の支出を最適化して、コスト効率の良いデプロイと規模拡大を実現できます。 Cost Explorer は詳細なコスト分析と予測機能を提供し、テナントに関連する支出を理解し、コストの発生源を特定し、将来の成長を計画することができます。チームはカスタムのコスト配分レポートを作成し、AWS Budgets とアラートを使用してカスタムの予算を設定し、時間の経過に伴うコストの傾向を分析できます。 生成 AI モデルのコストとパフォーマンスの分析は、モデルのデプロイと最適化に関する適切な意思決定を行う上で重要です。 EventBridge、CloudTrail、CloudWatch は、これらのメトリクスを追跡・分析するために必要なツールを提供し、企業がデータに基づく意思決定を行うことを支援します。この情報を活用することで、十分に活用されていないリソースのスケールダウンなど、最適化の機会を特定できます。 EventBridge を使用すると、Amazon Bedrock のステータス変更イベントに自動的に応答するように Amazon Bedrock を設定できます。これにより、API レート制限の問題、API の更新、追加のコンピューティングリソースの削減に対応できます。詳細については、 Amazon EventBridge での Amazon Bedrock イベントのモニタリング を参照してください。 前のセクションで説明したように、CloudWatch は Amazon Bedrock を監視して生データを収集し、読みやすいリアルタイムに近いコスト指標に処理することができます。CloudWatch コンソールを使用してメトリクスをグラフ化できます。また、特定のしきい値を監視するアラームを設定し、値がそのしきい値を超えた場合に通知を送信したり、アクションを実行したりすることもできます。 ガバナンス エンタープライズ環境における生成 AI ソリューションの責任ある効果的な導入には、継続的な評価や複数層のガードレールなど、堅牢なガバナンス対策の実装が不可欠です。それぞれについて見ていきましょう。 パフォーマンスのモニタリングと評価 – 生成 AI モデルのパフォーマンス、安全性、コンプライアンスを継続的に評価することは重要です。これは以下のような方法で実現できます： 企業は Amazon SageMaker Model Monitor や Amazon Bedrock のガードレール、 Amazon Comprehend などの AWS サービスを使用して、モデルの動作をモニタリングし、ドリフトの検知を行い、生成 AI ソリューションが期待通り (またはそれ以上) に機能し、組織のポリシーを遵守していることを確認できます。 RAGAS などのオープンソースの評価指標をカスタムメトリクスとしてデプロイし、LLM のレスポンスが適切な根拠に基づいているか、バイアスを軽減し、ハルシネーション (幻覚) を防止できているかを確認できます。 モデル評価ジョブ を使用すると、モデルの出力を比較し、ユースケースに最適なモデルを選択できます。このジョブは、正解データに基づいて自動化することも、専門知識を持つ人間が評価することもできる。また、Amazon Bedrock の基盤モデル を使用してアプリケーションを評価することもできます。このアプローチについて詳しくは、 Amazon Bedrock を使用した検索拡張生成アプリケーションの信頼性評価 を参照してください。 ガードレール – 生成 AI ソリューションには、責任ある AI と監視を実施するための堅牢な多層的ガードレールを含める必要があります： まず、バイアスのリスクを軽減し、責任ある AI ポリシーでアプリケーションを保護するために、LLM モデルの周りにガードレールが必要です。これは、Amazon Bedrock のガードレールを使用して、モデル (基盤モデルまたは微調整済み) の周りにカスタムガードレールを設定し、禁止トピック、コンテンツフィルター、ブロックされたメッセージを構成することで実現できます。 第二のレベルは、各ユースケースのフレームワークの周りにガードレールを設定することです。これには、アクセス制御、データガバナンスポリシー、予防的なモニタリングとアラートの実装が含まれ、機密情報が適切に保護され監視されることを確実にします。例えば、データウェアハウジングには Amazon Redshift 、データ統合には AWS Glue 、ビジネスインテリジェンス (BI) には Amazon QuickSight などの AWS データ分析サービスを使用できます。 コンプライアンス対策 – 企業は、GDPR、CCPA、または業界固有の基準などの規制要件や業界標準を満たすための堅牢なコンプライアンスフレームワークを設定する必要があります。これにより、生成 AI ソリューションが様々なユースケースで機密情報を安全かつ効率的に処理し、コンプライアンスを維持できます。このアプローチにより、データ漏洩や不正アクセスのリスクを最小限に抑え、重要なデータ資産の整合性と機密性を保護します。企業は、包括的なガバナンス構造を作成するために、以下の組織レベルのアクションを取ることができます： コンプライアンス違反や AI システムの誤動作に対応するための明確なインシデント対応計画を確立します。 定期的なコンプライアンス評価とサードパーティ監査を実施し、潜在的なリスクや違反を特定して対処します。 従業員に対して、コンプライアンス要件と AI ガバナンスのベストプラクティスに関する継続的なトレーニングを提供します。 モデルの透明性 – 生成 AI モデルの完全な透明性の実現は依然として課題ですが、組織はモデルの透明性と説明可能性を高めるために以下のようなステップを取ることができます： モデルの使用目的、パフォーマンス、機能、潜在的なバイアスについてのモデルカードを提供します。 モデルに自己説明を求める、つまり自身の判断に対する説明を提供させます。これは複雑なシステムでも設定できます。例えば、エージェントが複数ステップの計画を実行し、自己説明を通じて改善することができます。 LLMOps または FMOps によるモデルライフサイクル管理の自動化 LLMOps の実装は、生成 AI モデルのライフサイクルを大規模に効率的に管理するために重要です。FMOps のサブセットである LLMOps の概念と、MLOps との主な違いについては、 FMOps/LLMOps: 生成 AI の実運用と MLOps との違い をご覧ください。このブログ記事では、生成 AI アプリケーションの開発ライフサイクルと、生成 AI アプリケーションを実運用するために必要な追加のスキル、プロセス、技術について詳しく説明しています。 データ取り込みと利用における標準的な管理手法 LLM に新しいデータを追加して強化することは、大規模な微調整や企業独自の LLM を構築する負担なしに、より文脈に沿った回答を提供するために不可欠です。データの取り込み、抽出、変換、カタログ化、ガバナンスの管理は、企業のデータポリシーとガバナンスフレームワークに準拠する必要がある複雑で時間のかかるプロセスです。 AWS はこれらをサポートするいくつかのサービスを提供しています。以下の図は、これらの概要を示しています。 詳細については、 Scaling AI and Machine Learning Workloads with Ray on AWS および Build a RAG data ingestion pipeline for large scale ML workloads をご参照ください。 このワークフローには、以下の手順が含まれます。 データは、カスタムツールや既存のツール、または AWS Transfer を使用して AWS に安全に転送できます。 AWS Identity and Access Management (IAM) と AWS PrivateLink を使用してデータと生成 AI リソースへのアクセスを制御・保護し、データが組織の境界内に留まり、関連規制に準拠することを確実にできます。 データが Amazon S3 に格納されたら、AWS Glue を使用してデータの抽出と変換 (例えば Parquet 形式への変換) を行い、取り込んだデータに関するメタデータを保存してデータガバナンスとカタログ化を容易にできます。 3 つ目のコンポーネントは GPU クラスターで、これは Ray クラスターを利用できます。 AWS Step Functions 、 Amazon SageMaker Pipelines 、または AWS Batch などの様々なオーケストレーションエンジンを使用して、埋め込みを作成し、データをデータストアやベクトルストアに取り込むためのジョブ (またはパイプライン) を実行できます。 埋め込みは OpenSearch などのベクトルストアに保存でき、効率的な検索とクエリが可能になります。あるいは、 Amazon Bedrock Knowledge Bases のようなソリューションを使用して Amazon S3 やその他のデータソースからデータを取り込み、生成 AI ソリューションとシームレスに統合することができます。 Amazon DataZone を使用して、Amazon S3 とベクトルストアに保存された生データへのアクセス制御を管理し、データガバナンスのためのロールベースまたは細粒度のアクセス制御を実施できます。 データの意味的な理解が必要な場合は、 Amazon Kendra を使用してインテリジェントな企業検索を実現できます。Amazon Kendra には ML 機能が組み込まれており、S3 などの様々なデータソースと簡単に統合でき、組織のニーズに応じて適応可能です。 使用するコンポーネントの選択は、ソリューションの具体的な要件によって異なりますが、すべてのデータ管理をブループリントにコード化できるよう (次のセクションで説明)、一貫したソリューションが存在する必要があります。 モデル、プロンプトカタログ、API、アクセス制御ガイドラインのための管理型インフラストラクチャーパターンとブループリントの提供 生成 AI ソリューションを構築・デプロイする方法は数多くあります。AWS は Amazon Bedrock、Amazon Kendra、OpenSearch Service などの主要サービスを提供しており、これらはテキスト要約や検索拡張生成 (RAG) などの複数の生成 AI のユースケースをサポートするように構成できます。 最も簡単な方法は、生成 AI を必要とする各チームが AWS 上で独自のカスタムソリューションを構築できるようにすることですが、これは必然的にコストを増加させ、組織全体で不整合を引き起こすことになります。より拡張性の高いオプションは、統括チームがブループリントやコンストラクトにコード化された標準的な生成 AI ソリューションを構築し、各チームがそれらをデプロイして使用できるようにすることです。このチームは、使いやすく統合された API でこれらのコンストラクトを抽象化するプラットフォームを提供し、LLMOps、データ管理、FinOps などの追加サービスを提供することができます。次の図は、これらのオプションを示しています。 LangChain や LiteLLM などの生成 AI のランタイム、API、プロンプト、オーケストレーションのためのブループリントとコンストラクトを確立することで、生成 AI の導入が簡素化され、全体的な安全な利用が促進されます。アクセス制御、一貫性のある AI、データとコストの管理を備えた標準 API を提供することで、利用が簡単で、コスト効率が良く、セキュアな利用が可能になります。 AWS 上でソリューションを構築する際のマルチテナントアーキテクチャにおけるリソースの分離の強制方法や、分離戦略における重要なパターンについての詳細は、ホワイトペーパー SaaS Tenant Isolation Strategies を参照してください。 まとめ Well-Architected Framework の運用上の優秀性の柱を生成 AI の観点から重視することで、企業は安全で費用対効果が高くコンプライアンスに準拠したソリューションを構築し、生成 AI の取り組みを自信を持ってスケールできます。生成 AI のランタイム、プロンプト、オーケストレーションに標準化された基本フレームワークを導入することで、組織は既存のワークフローに生成 AI の機能をシームレスに統合できるようになります。 次のステップとして、予防的なモニタリングとアラートを設定することで、バイアスのある出力や有害な出力の生成など、潜在的な問題を迅速に検出して軽減できるようになります。 受け身で待つ必要はありません。ベストプラクティスを採用するために、積極的な姿勢で取り組みましょう。倫理的な AI の実践を維持するため、生成 AI システムの定期的な監査を実施してください。生成 AI の運用における優れた実践に関する技術について、チームのトレーニングに投資してください。これらのアクションを今すぐ実行することで、この技術の複雑さに賢明に対処しながら、生成 AI の変革的な可能性を活用する準備が整います。 著者について Akarsha Sehwag は、AWS プロフェッショナルサービスのデータサイエンティストおよび ML エンジニアで、ML ベースのサービスと製品の構築に 5 年以上の経験を持っています。コンピュータビジョンとディープラーニングの専門知識を活かし、お客様が AWS クラウドで ML の能力を効率的に活用できるよう支援しています。生成 AI の登場により、多くのお客様と協力して適切なユースケースを特定し、本番環境で利用可能なソリューションを構築してきました。開発、起業家精神、研究など、幅広い分野に関心を持っています。 Malcolm Orr は AWS のプリンシパルエンジニアで、AWS サービスを使用したプラットフォームと分散システムの構築に長年の経験を持っています。構造化されたシステム的な視点で生成 AI に取り組み、組織全体で安全、セキュア、かつコスト効率的に生成 AI を導入する方法の定義を支援しています。 Tanvi Singhal は AWS プロフェッショナルサービスのデータサイエンティストです。データサイエンス、機械学習、ビッグデータが専門分野です。クラウド環境での機械学習モデルと MLOps ソリューションの開発においてお客様をサポートしています。AWS 入社前は、配車サービス、小売、金融サービスなど、さまざまな業界でコンサルタントを務めていました。お客様のクラウドにおけるデータ/AI の取り組みを支援することに情熱を注いでいます。 Zorina Alliata は主席 AI 戦略担当として、人工知能と機械学習を活用して業務を迅速化しプロセスを強化するソリューションをグローバルなお客様と共に見出し、さまざまな業界の企業における AI ユースケース、プラットフォーム、AI の大規模実装に向けた戦略と実行計画の策定を支援しています。 翻訳は機械学習ソリューションアーキテクトの本橋が担当しました。

みなさんこんにちは。AWS ソリューションアーキテクトの伊藤ジャッジ向子です。本記事では AWS Summit Japan 2025 における Digital Thread の展示についてご紹介します。 展示概要 製造業におけるデータの活用はビジネスの成功に不可欠な要素となっていますが、一方で多くの企業は、業務をまたいだデータを包括的に活用することは難しいと感じています。実際、ものづくり白書 2025 でも、DX の具体的成果が半分以下しか出ていない、と報告されています。この理由の一つとしては、部門や関連会社ごと、さらに部門内のシステムも CRM、PLM、ERP、MES/MOM などに散らばってデータが保存されているからです。この展示では、データ活用のハードルを下げる提案の一つとして、e-Bike の仮想的なビジネスのデータを集約し、グラフデータと生成 AI を組み合わせ、業務横断のデータ (Digital Thread) の活用を実現するアプリケーションを展示しています。 よくある課題 多くの製造業は下記のような問題に直面しています： 製品ライフサイクルの各段階のデータが、分断された企業システムで管理され、ビジネス意思決定者が洞察を得るためのデータ活用ができていない 部署や拠点を単位としたシステムがサイロ化しており、業務プロセスにおける問題が顕在化しにくい 業務プロセスにおける問題がたとえ顕在化したとしても、問題の特定に至るまでには、属人的、もしくは高度な技術を必要とする膨大なコストが嵩む調査が必要になる この展示の注目ポイント この展示では、e-Bike の業務プロセスを例に取り、様々なデータソースからの接続されたデータの繋がりにより問題の解決やトレース、またはビジネス決定のための洞察を与える、データ活用例を体現したアプリケーションを展示しています。 例えば、e-Bike 製品の品質管理における課題として、塗装に関するクレームが発生した場合を想定してみましょう。従来であれば多数の部署に問合せ、多数のシステムを確認せざるをえなかった複雑な問題でも、業務横断のデータ活用ができれば、クレームに添付された製造番号から、製造ラインの特定、使用している部品、影響を受けるユーザーの範囲まで、一つの検索で瞬時に把握することが可能になります。また、お客様からのフィードバックを製品改善に活かす際も、サプライチェーン・エンジニアリングチェーン全体を通じた影響分析が可能となります。 さて、ここまで読んでくださった方の中には、Digital Thread やグラフデータといった言葉には、馴染みのない方もいらっしゃるかもしれません。以下にこの展示のキーワードとなる概念と技術について解説します。 Digital Thread とは Digital Thread は、製品のライフサイクル全体にわたるデータの流れを一貫して管理する概念で、仕入れ、設計から製造、運用、保守、市場調査に至るまでの全てのプロセスで記録されたデータを、糸 (Thread) で紡ぐように連携させることで、製品に関する包括的な情報の把握を可能にするという考え方です。Digital Thread は、米国で 2010 年代にデータドリブンの一つの概念として広まりました。ここで以前から存在していたグラフデータと併用することにより、Digital Thread の実現が可能になりました。 グラフデータベースとは グラフデータベース とは、データをノードとエッジで表現するデータ構造を持つデータベースです。リレーショナルデータベースと異なり、データ間の関係性を直接的に表現できるため、複雑な関連性を持つデータの処理に優れています。例えば、下記の図はソーシャルネットワークで広く使われているグラフデータです。 上記の図はソーシャルネットワークの例ですが、製造業では製品を構成する各部品や、製造工程における製造ラインの組み合わせなど、データ間の繋がりが重要な役割を果たしています。このような複雑な依存関係を検索する際も、グラフデータベースではテーブルの結合操作が不要なため、シンプルな検索が可能です。またグラフデータベースはスキーマの柔軟性が高く、新しい種類のノードや関係性を容易に追加することが可能なため、ビジネス要件や企業の部門の統合などの変化に迅速に対応することが可能です。 さらに、製品に関連する様々なデータ間の複雑な関係性を表現できるグラフデータベースの特性は、Digital Thread が目指す統合的なデータ管理に適しています。例えば、製品の設計変更の影響の分析が必要な際に、既存の業務プロセスや保守計画に影響を与えるかどうかを、データ間の関連性を通じて容易に追跡することができます。 展示するアプリケーションでは、AWS のグラフデータベースを提供するサービスである、 Amazon Neptune を利用しています。 しかし、グラフデータベースのもう一つの特徴として、専門知識が必要であるという点があります。グラフデータは関係性が明確なデータを表現できる良さがある一方で、独自のクエリ言語による問い合わせが必要となります。 Digital Thread における生成 AI の活用 近年多くの企業に注目されている生成 AI は、膨大な量のデータを効率的に処理し、そこから意味のあるパターンを見出すことが可能です。特に製造業における生成 AI とグラフデータの活用については、こちらの ブログ もご参照ください。 今回の展示アプリケーションにおいて注目すべき点は、生成 AI の活用により、独自のクエリ言語を使用したグラフデータベースへのクエリを自然言語で行える点です。このアプリケーションでは、クエリテンプレートを使用して、自然言語のクエリをグラフデータへのクエリに変換するので、専門知識がなくても必要なデータの抽出や解析が可能になり、さらにその結果も分かりやすい自然言語で得られます。これにより、データ活用をさまざまなタイプの従業員の方々に体験していただき、製品プロセスの改善活動を広く展開することが可能になります。 例えば、下記の画像は展示アプリケーションの画面ですが、不具合が報告された部品のシリアル番号を元に、類似の問い合わせの存在について質問をしている画面です。従来の検索方法では、条件付けや検索範囲の指定が必要でしたが、そういった検索技術は必要ありません。また、「これはよくあることですか」という自然な問いかけから、製品に関連する様々なデータを、関連性を元に検索し、さらに検索結果に対する洞察を、誰にでも分かりやすい自然言語で返答しています。 この展示では AWS のフルマネージドの生成 AI サービス、 Amazon Bedrock を使用しています。 製造業の Digital Thread によるグラフデータ活用 グラフデータの特徴として、データ間の関連性を視覚的に表現することが可能という点があります。この特性から、生成AI で返答された回答が、下記の図のように、どのような情報の繋がりを根拠として生成されたかを、データレベルで直感的に理解することができます。 このデモでご覧いただける Digital Thread は、IT やデータの専門家のみならず、システムエンジニアリング、設計エンジニアリング、製造エンジニアリング、サプライチェーン、運用、品質管理など、様々な部門のプロフェッショナルの業務効率を劇的に向上させる可能性があり、またビジネス決定に必要な洞察をすばやく提供することが可能となります。 製造業のデジタルトランスフォーメーションに関心をお持ちの方、企業におけるデータ活用の新しい可能性を探っている方は、ぜひ私たちの展示にお立ち寄りください。デモを通じて、最新のデータ活用の姿をご覧いただけます。 利用しているAWSサービス Amazon CloudFront Amazon Bedrock Amazon Neptune Amazon Cognito Amazon S3 AWS Fargate その他、ご要件により各データストアへの連携サービスと、組み合わせてご利用いただけます それでは、AWS Summit Japan 2025 で 業務横断データ活用 (Digital Thread) の展示でお会いできることを楽しみにしています！ 著者 : 伊藤 ジャッジ向子 (Ito, Judge Sakiko) アマゾン ウェブ サービス ジャパン合同会社 アソシエイトソリューションアーキテクト 米国で化学と医療の製造業双方で、.Netアプリケーションの開発を経験し、帰国後 AWS Japan のサポート部に入社。その後異動し、エンタープライズ事業本部でソリューションアーキテクトとして製造業のお客様をご支援しています。 趣味は山登りとキャンプの他、クラッシックバレエ、紀州犬と甲斐犬含む家族のお世話です。

AWS ヒーロープログラム は、知識を共有したいという熱意によってコミュニティ内に真の影響をもたらしている、活気に満ちた世界中の AWS エキスパートグループを表彰するプログラムです。ヒーローたちは、デベロッパーコミュニティにおいて、さまざまな方法で知識を共有するために尽力しています。2025 年第 2 四半期における 最新の AWS ヒーロー をご紹介します。 お近くの他の AWS ヒーローを見つけてつながるには、それぞれの専門カテゴリにアクセスしてください コミュニティヒーロー 、 コンテナヒーロー、 データヒーロー、 DevTools ヒーロー、 機械学習ヒーロー、 セキュリティヒーロー、 サーバーレスヒーロー 。 6 月 2 日週のリリース ご紹介で盛り上がったところで、私の目をひいた AWS のリリースをいくつかご紹介します。 AWS マネジメントコンソールおよびチャットアプリケーションにおける Amazon Q Developer Chat のエージェント機能 – AWS マネジメントコンソール、Microsoft Teams、Slack において、Amazon Q Developer は、200 を超える AWS サービスから適切なツールを自動的に特定し、クエリを実行可能なステップに分割して、機能する際にその推論プロセスを表示して、より複雑なクエリに回答できるようになりました。 Amazon Q Developer CLI における Claude Sonnet 4 モデル – Amazon Q Developer CLI は、Anthropic の Claude Sonnet 4 をサポートするようになりました。これにより、デベロッパーは、 /model や q chat --model などのシンプルなコマンドを使用して、プレミアムモデル (Sonnet 4、3.7、3.5) を切り替えることができます。 Amazon API Gateway が REST API の動的リクエストルーティングのサポートを開始 – Amazon API Gateway は、カスタムドメイン名を使用した REST API のルーティングルールをサポートするようになりました。これにより、HTTP ヘッダー、URL ベースパス、またはその両方に基づいたトラフィック分散が可能になります。 Amazon Athena が分析ワークフローを効率化するマネージドクエリ結果を発表 – マネージドクエリ結果は、お客様のために、クエリ結果のライフサイクルを追加コストなしで自動的に保存、暗号化、管理する新機能です。 AWS Network Firewall コンソールの新しいモニタリングダッシュボード – 新しいダッシュボードは、上位のフロー、TLS Server Name Indication (SNI)、HTTP ホストヘッダー、長時間存続する TCP 接続、失敗した TCP ハンドシェイクなど、ネットワークトラフィックパターンについての強化された可視性を提供します。 AWS のお知らせの詳細なリストについては、「 AWS の最新情報 」をご覧ください。 AWS のその他のニュース その他のいくつかのプロジェクトと、興味深いブログ記事をいくつかご紹介します: Amazon EC2 NVIDIA GPU アクセラレーテッドインスタンスを最大 45% 値下げ – AWS は、オンデマンドおよび Savings Plan でご利用の場合、NVIDIA GPU アクセラレーテッド Amazon EC2 インスタンス (P4d、P4de、P5、P5en) を最大 45% 値下げします。また、大規模なデプロイをサポートするために、最新の P6-B200 インスタンスを Savings Plans を通じて提供しています。 パブリック AWS API モデルのご紹介 – AWS は、GitHub で Smithy API モデルの日々の更新を提供するようになりました。これにより、デベロッパーは、カスタム SDK クライアントを構築し、AWS API の動作を理解して、より良い AWS サービスとの統合を実現するための開発ツールを作成できます。 AWS アジアパシフィック (台北) リージョンが開設されました – この新しいリージョンは、台湾でデータを安全に保存するためにデータレジデンシー要件を満たせるようにしながら、さらに低いレイテンシーを提供しています。さまざまな業界のお客様が、安全かつスケーラブルで信頼性の高いクラウドインフラストラクチャの恩恵を享受し、デジタルトランスフォーメーションとイノベーションを推進できます。 Amazon EC2 で AMI クリーンアップワークフローが簡素化 – Amazon EC2 は、Amazon マシンイメージ (AMI) の登録を解除する際に、基盤となる Amazon Elastic Block Store (Amazon EBS) スナップショットの自動削除をサポートするようになりました。 AWS がカスタムチップを設計するラボ – テキサス州オースティンにある Annapurna Labs にぜひお越しください。オフィス、ワークショップ、さらにはミニデータセンターが併設されたこのラボでは、Amazon Web Services (AWS) のエンジニアたちがコンピューティングの未来を設計しています。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 どこからでも re:Inforce にご参加いただけます – フィラデルフィア (6 月 16 日～18 日) にお越しいただけないお客様にも、リモートでご視聴いただけます。re:Inforce の基調講演とイノベーショントークのライブに無料でアクセスできます。 AWS Summit – クラウドコンピューティングコミュニティがつながり、コラボレートし、AWS について学ぶために一堂に会する無料のオンラインおよび対面イベントに参加しましょう。お近くの都市でご登録ください: 上海 (6 月 19 日～20 日)、 ミラノ (6 月 18 日)、 ムンバイ (6 月 19 日)、 日本 (6 月 25 日～26 日)。 AWS re:Invent – ラスベガスで開催される AWS re:Invent (12 月 1 日～5 日) にぜひご参加ください。登録受付開始 AWS Community Days – 世界中のエキスパート AWS ユーザーと業界リーダーによるテクニカルディスカッション、ワークショップ、ハンズオンラボが提供される、コミュニティ主導のカンファレンスにご参加ください。開催地は、 メキシコ (6 月 14 日)、 ナイロビ (ケニア) (6 月 14 日)、 コロンビア (6 月 28 日) です 6 月 9 日週のニュースは以上です。6 月 16 日週に再びアクセスして、新たな Weekly Roundup をぜひお読みください! – Betty 原文は こちら です。

6 月 5 日、 Amazon Web Services (AWS) は、AWS アジアパシフィック (台北) リージョンの一般提供が 3 つの アベイラビリティゾーン とリージョンコード ap-east-2 で開始されたことを発表しました。この新しいリージョンにより、台湾のお客様には、より近くで AWS インフラストラクチャ とサービスをご利用いただけるようになります。 台北 101 を含む台北のスカイライン 台北初のインフラストラクチャリージョンとして、また、アジアパシフィックにおける 15 番目のリージョンとして、この新しいリージョンは、AWS のグローバルフットプリントを、世界中の 37 の地理的リージョンにわたる 117 のアベイラビリティゾーンに拡大します。新しい AWS リージョン は、デベロッパー、スタートアップ、エンタープライズ、ならびに教育、エンターテインメント、金融サービス、ヘルスケア、製造業、非営利団体が、台湾でデータレジデンシーを維持しながら、アプリケーションを実行し、エンドユーザーにサービスを提供するのに役立ちます。 台湾の AWS AWS は、2014 年の AWS 台北オフィスの開設以来、10 年を超える期間にわたって台湾で事業を展開しています。それ以来、AWS は、台湾において、次を含む多くのインフラストラクチャオファリングを導入してきました。 2014 年には、AWS は初の Amazon CloudFront エッジロケーションを立ち上げ、2018 年にはさらにもう 1 つ立ち上げました。これにより、世界中のデータ、動画、アプリケーション、API 配信を高速化できるよう、安全で効率的なコンテンツ配信ネットワークをお客様に提供しています。 2018 年には、接続オプションを強化するため、AWS は 2 つの AWS Direct Connect ロケーションを台湾に設けました。AWS アジアパシフィック (台北) リージョンの立ち上げに伴い、台湾で新しい Direct Connect ロケーション を追加し、より高速かつ高帯域幅のサービスをお客様に提供します。 2020 年には、AWS は台湾で AWS Outposts をリリースしました。これは、お客様が AWS インフラストラクチャとサービスをオンプレミスまたはエッジロケーションにシームレスに拡張し、一貫したハイブリッドエクスペリエンスを実現するのに役立ちます。 2022 年、1 桁ミリ秒の応答性を必要とする低レイテンシーアプリケーションをサポートするために、AWS は 台北の AWS Local Zone を立ち上げました。 6 月 5 日、AWS アジアパシフィック (台北) リージョンの立ち上げにより、台湾におけるイノベーションをサポートするというコミットメントをさらに強化します。規制が厳しい産業の組織は、データの場所と移動に対する完全なコントロールを維持しながら、データをローカルに保存できるようになります。ハイテク製造業から、半導体企業や中堅・中小企業 (SME) まで、企業は、成長とイノベーションに必要なスケーラブルなインフラストラクチャを利用できるようになります。 台湾の AWS のお客様 台湾中の組織は、既に AWS を利用してイノベーションを起こし、差別化されたエクスペリエンスを顧客に提供しています。以下に例を挙げます: Cathay Financial Holdings (CFH) は、台湾の金融テクノロジー分野のリーダー的存在です。同社は最新のテクノロジーを継続的に導入し、フルシナリオの金融サービスエコシステムを構築しています。CFH は 2021 年以来、AWS 上でクラウド環境を構築しています。これにより、セキュリティコントロールを強化し、コンプライアンス要件を満たしています。 「Cathay Financial Holdings は、業界におけるデジタルトランスフォーメーションを加速させるとともに、当社の金融サービスの安定性、セキュリティ、適時性、スケーラビリティを改善し続けます」と CFH の Senior Executive Vice President である Marcus Yao 氏は述べています。「台湾における新たな AWS リージョンを利用することで、CFH は、より多様で便利な金融サービスをお客様に提供できると期待しています」。 Gamania Group は、同社の革新的な Vyin AI プラットフォーム を通じて AI と著名人の IP を統合することで、エンターテインメント分野に革命をもたらしています。Gamania は、AWS の堅牢かつスケーラブルなインフラストラクチャを活用して、安全で応答性の高い AI インタラクションを開発しました。 Chief Strategy Officer 兼 Head of Innovation Lab である Benjamin Chen 氏は次のように述べています。「Vyin AI の核となる目標は、完全にインタラクティブかつリアルで安全に使用できるデジタル ID を生み出すことです。これを実現するには、安定しており、応答性が高く、安全なテクノロジーが必要です。そのために、当社は AWS の堅牢で回復力に優れたクラウドインフラストラクチャを活用し、台湾における AWS リージョンが提供する低レイテンシーの利点に期待しています。AWS は、Vyin AI が AI のハルシネーションのない安全なインタラクションをユーザーに提供できるよう、非常に安定した安全な環境を提供してくれます。AWS クラウドサービスにより、当社は、中核的な AI テクノロジーのイノベーションと『ハイパーパーソナライズされたインタラクティブな』ユーザーエクスペリエンスの強化にさらに注力することができ、製品のイテレーションと最適化を加速できます」。 中華電信 は、極めて広範なメインストリームの 5G 帯域幅、卓越したネットワーク速度、世界的に評価の高いモバイルインターネット機能を提供する、台湾のクラウドネットワークサービス分野のリーダー的存在です。中華電信は、 Amazon Bedrock などの生成 AI プラットフォームを活用して、革新的なサービスを構築し、さまざまな業界向けにインテリジェントなアプリケーションを生み出しています。 CHT の President である Rong-Shy Lin 博士は次のように述べています:「台湾における AWS リージョンの立ち上げにより、CHT と AWS のパートナーシップは新たな段階に入りました。低レイテンシーやローカルデータストレージなどの AWS リージョンの主な利点を、CHT の広範なバックボーンネットワーク、豊富なクラウド経験、複数の AWS コンピテンシー認定を取得した専門チームと組み合わせて、その統合をより一層強化していきます。これにより、CHT は、政府、金融、重要なインフラストラクチャ、規制の厳しい業界における、セキュリティとコンプライアンスの厳格な要件を満たすソリューションを提供できるようになります。同時に、当社は、革新的なアプリケーションを開発したり、デジタルトランスフォーメーションや AI の導入を加速したりするために、Amazon Bedrock などの AWS テクノロジーを活用しています。今後も台湾において、お客様のグローバル展開をサポートしながら、最適化されたクラウドおよびネットワークサービスを提供し続けていきます」。 台湾の AWS パートナー 台湾の AWS パートナーネットワーク は、お客様がクラウドテクノロジーを導入し、新しい AWS アジアパシフィック (台北) リージョンから最大限の価値を引き出すのをサポートする上で重要な役割を果たします。これらの専門パートナーは、深い技術的専門知識と、現地の市場に関する知識を組み合わせることで、業界全体にわたるデジタルトランスフォーメーションを加速させます。 eCloudvalley Digital Technology Group は、AWS プレミアティアサービスパートナーであり、600 超の認定を持つクラウドエキスパートのチームを擁しています。 「eCloudvalley Group は、クラウドの伝道者になるというミッションを常に掲げ、台湾の業界全体におけるクラウドテクノロジーの導入を推進してきました」と eCloudvalley Group の Chairman である MP Tsai 氏は述べています。「AWS との 10 年超にわたる緊密な協力関係において、AWS でのお客様のデジタルトランスフォーメーションジャーニーに参加しながら、より多くのお客様と業界がクラウドに移行するのをサポートできることを光栄に思います。AWS アジアパシフィック (台北) リージョンの立ち上げにより、世界をリードするクラウドテクノロジーを利用することで、台湾において、台湾企業のデジタルトランスフォーメーションとイノベーションがさらにサポートされるとともに、金融やヘルスケアなど、厳しいローカルデータレジデンシー要件を満たす必要がある業界がクラウドトランスフォーメーションジャーニーをさらに推進できるようになるでしょう」。 Nextlink Technology Inc. は、AWS プレミアコンサルティングパートナーであり、 マネージドサービスプロバイダー (MSP) の認定を受けています。また、AWS Level 1 Managed Security Service Provider (MSSP) と Government Consulting Competency を保有しています。 「AWS によるローカルインフラストラクチャへの投資は、台湾企業がデジタルトランスフォーメーションを推進するのを支え、伝統的な産業から新興のデジタルセクターに至るまで、さまざまな産業の発展を促進するでしょう」と Nextlink Technology Inc. の CEO である Shasta Ho 氏は述べています。「当社は AWS と引き続き連携し、さまざまな業界の企業が新しい AWS アジアパシフィック (台北) リージョンを深く活用できるようサポートすることを楽しみにしています。このローカルな利点は、データローカライゼーション、低レイテンシー、コンプライアンス、高性能コンピューティングワークロードにおけるお客様のニーズに対応します。また、世界をリードする AWS のクラウドテクノロジーを利用して、お客様のデジタルトランスフォーメーションジャーニーを推進するとともに、台湾経済の多様化にも貢献していきたいと考えています」。 SAP は 10 年超にわたり AWS の戦略的パートナーであり、世界中の数千のエンタープライズ顧客が AWS 上で SAP ワークロードを実行しています。 「SAP は、AWS が台湾に新しいデータセンターを設立することに高揚感を覚えています」と SAP Global Vice President and Managing Director for Taiwan, Hong Kong, and Macau である George Chen 氏は述べています。「この投資により、台湾企業は、より幅広い選択肢、より低いサービスレイテンシー、強化された運用上の柔軟性を活用できます。SAP は長期的な戦略パートナーとして、これらの企業のクラウドトランスフォーメーションを加速させることに尽力しています。 RISE with SAP を通じて、当社は、お客様がクラウドにシームレスに移行し、より高い柔軟性やスケーラビリティ、および運用コストの削減を実現するのをサポートします。SAP のエンタープライズソリューションと、AWS の堅牢なクラウドプラットフォームを組み合わせることで、台湾の企業が革新的な AI アプリケーションを実現し、コアビジネスを安全、確実、ローカルに運用できるようサポートして、台湾のエンタープライズクラウドトランスフォーメーションをともに推進していきます」。 台湾における持続可能なイノベーションのサポート 2050 年までに排出量ネットゼロを実現するという目標に向けて台湾が前進する中、AWS クラウドソリューションは、組織が環境への影響を軽減しながら、運用効率を高めるのをサポートしています。新しい AWS アジアパシフィック (台北) リージョンは、持続可能性に対する AWS のコミットメントを組み込み、組織が技術目標と環境目標の両方を達成するのをサポートします。 Ace Energy は、台湾のエネルギー管理分野のパイオニア的存在です。Ace Energy は 2013 年以来、 Amazon Simple Storage Service (Amazon S3) 、 Amazon Elastic Compute Cloud (Amazon EC2) 、 AWS IoT Core などの AWS サービスを利用し、同社の Energy Saving Performance Contract モデルを通じて革新的なエネルギーソリューションを提供しています。Ace Energy は、1,000 拠点にエネルギー管理ソリューションをデプロイして、半導体メーカーが蒸気消費量を 65% 削減するのをサポートし、年間 2,200 万 TWD 相当のエネルギー節約を実現するとともに、同社の廃熱回収テクノロジーを通じて二酸化炭素排出量を 8,000 トン削減しました。 Taiwan Power Company (Taipower) は、台湾の国営電力会社であり、2018 年から AWS を通じて業務改革を進めています。ドローン、ロボット工学、仮想現実を活用したスマートグリッドテクノロジーをスマートパトロールに実装することで、「Taiwan Power」アプリケーションを通じてカスタマーエクスペリエンスを強化しました。同社はデータ駆動型の意思決定を通じて業務効率を高め、Taiwan Corporate Sustainability Awards の Corporate Sustainability カテゴリにおいて、6 回連続で Platinum Awards を受賞しました。 クラウドスキルをともに構築 AWS は 2014 年以来、台湾におけるクラウド教育とスキル開発のための包括的なプログラムを構築してきました。例えば、 AWS Academy 、 AWS Educate 、 AWS Skill Builder などの教育プログラムは、クラウドスキルについて台湾の 200,000 人超をトレーニングするのに役立っています。これらのプログラムは、台湾のデジタルの未来の基盤を築くために、インフラストラクチャへの投資と並行して拡大していく予定です。 台湾には、皆様のご参加いただける、活気のある AWS コミュニティがあります。台北のローカル AWS ユーザーグループ で知識共有やネットワーキングに参加したり、台湾で有名な 4 人の AWS ヒーロー と交流したりしましょう。また、既に台湾のクラウドエコシステムに貢献している 17 人の AWS コミュニティビルダー に加わり、AWS に熱意を注ぐ人々の、拡大し続けるコミュニティの一員になることをご検討ください。これらのコミュニティとのつながりはすべて、地域の専門知識と共同学習を通じてお客様のクラウドジャーニーを加速させる貴重な機会を提供します。 ご期待ください AWS アジアパシフィック (台北) リージョンは、お客様のビジネスをサポートする準備ができています。このリージョンで利用可能なサービスの詳細なリストは、 AWS サービス (リージョン別) ページでご覧いただけます。AWS リージョンの開設に関するニュースについては、AWS ニュースブログの リージョンに関するニュース をご覧ください。 今すぐアジアパシフィック (台北) リージョンで構築を開始しましょう。 – Betty 原文は こちら です。

6 月 5 日、 Amazon Web Services (AWS) のための API モデルの新しい一般公開ソースについてお知らせします。現在、AWS では AWS API モデルを毎日 Maven Central で公開しており、 GitHub にある新しいリポジトリへのオープンソースアクセスを提供しています。このリポジトリには、AWS パブリックインターフェイスの定義と動作を規定する、 Smithy API モデル の最終的な最新ソースが含まれています。 これらの Smithy モデルは、AWS サービスに対する理解を深めることに加えて、AWS に接続するためのカスタム Software Development Kit (SDK) やコマンドラインインターフェイス (CLI) といった開発者ツールを構築したり、AWS でのアプリケーション統合を検証するためのテストツールを構築したりするために使用できます。 2018 年以来、AWS では Smithy モデル を使用して SDK クライアントと CLI ツールを生成してきました。すべての AWS サービスは、プロトコル、認証、リクエストとレスポンスタイプ、エラーといった操作や動作を含めた API コントラクトを完全に文書化するために、Smithy でモデル化されています。 このパブリックリソースを使用することで、自信を持って AWS サービスと直接統合できる独自のアプリケーションを構築してテストできます。これには以下が含まれます。 SDK クライアントの生成 – Smithy ツールチェーンを使用して クライアント SDK ライブラリ を生成することで、 公式の AWS SDK サポート やコードジェネレーターを必要とすることなく、言語コミュニティのために独自の専用 SDK を構築できます。 API 実装の生成 – 言語固有のフレームワーク用のサーバースタブを生成できます。AI エージェント用の Model Context Protocol (MCP) サーバー構成を生成することも可能です。独自の API 標準に準拠していることを確認するための組み込み検証機能を利用できます。 独自の開発者ツールの構築 – モックテストツール、IAM ポリシージェネレーター、または AWS に接続するためのより高次の抽象化など、AWS 上に独自のツールを構築できます。 AWS API 動作の理解 – アーティファクトを簡潔かつ簡単に調査して、SDK が API コールを解釈する方法と、それらのコールで期待される動作をすばやく確認し、理解できます。 AWS API モデルについて学ぶ AWS サービスモデルは、 api-models-aws リポジトリにアクセスすることで、GitHub で直接閲覧できます。このリポジトリには、すべてのパブリック AWS API サービスのための、 JSON AST 形式の Smithy モデルが含まれています。すべての Smithy モデルは、シェイプとトレイトで構成されています。 シェイプ は types のインスタンスです。 トレイト は、クライアント、サーバー、文書化に有用であると思われる情報をシェイプに追加するために使用されます。 AWS モデルリポジトリには以下が含まれています。 トップレベルのサービスディレクトリは、サービスの <sdk-id> ( <sdk-id> はモデルの sdkId の値) を使用して命名されます。名前は小文字で、スペースはハイフンに変換されます。 各サービスディレクトリには、サービスの <version> ごとに 1 つのディレクトリが含まれています。 <version> は、サービスシェイプの バージョンプロパティ の値です。 service-version ディレクトリ内には、< sdk-id>-<version>.json という名前のモデルファイルが含まれています。 例えば、 Amazon EC2 サービスで RunInstances API を定義したい場合、モデルは service タイプを使用します。これは、リソースとオペレーションを集約する API のエントリポイントです。メンバーが参照するシェイプは target と呼ばれます。 com.amazonaws.ec2#AmazonEC2": { "type": "service", "version": "2016-11-15", "operations": [ .... { "target": "com.amazonaws.ec2#RunInstances" }, .... ] operation タイプは、API オペレーションの入力、出力、トレイト、発生する可能性のあるエラーを表します。オペレーションシェイプは、 リソース シェイプと サービス シェイプにバインドされます。オペレーションは、 operation_statement を使用して IDL で定義されます。トレイトでは、ドキュメントや例などの詳しい API 情報を見つけることができます。 "com.amazonaws.ec2#RunInstances": { "type": "operation", "input": { "target": "com.amazonaws.ec2#RunInstancesRequest" }, "output": { "target": "com.amazonaws.ec2#Reservation" }, "traits": { "smithy.api#documentation": "<p>Launches the specified number of instances using an AMI for which you have....", smithy.api#examples": [ { "title": "To launch an instance", "documentation": "This example launches an instance using the specified AMI, instance type, security group, subnet, block device mapping, and tags.", "input": { "BlockDeviceMappings": [ { "DeviceName": "/dev/sdh", "Ebs": { "VolumeSize": 100 } } ], "ImageId": "ami-abc12345", "InstanceType": "t2.micro", "KeyName": "my-key-pair", "MaxCount": 1, "MinCount": 1, "SecurityGroupIds": [ "sg-1a2b3c4d" ], "SubnetId": "subnet-6e7f829e", "TagSpecifications": [ { "ResourceType": "instance", "Tags": [ { "Key": "Purpose", "Value": "test" } ] } ] }, "output": {} } ] } }, AWS は、サービス API をモデル化し、 AWS SDK と AWS CLI を毎日リリースするために Smithy を幅広く使用しています。AWS API モデルは、AWS サービスとやり取りするためのサーバースタブの実装に役立ちます。 AWS API モデルを使用して構築する方法 Smithy API モデルは、構築ツール、クライアントまたはサーバーコードジェネレーター、IDE サポート、実装などの 構築リソース を提供します。例えば、 Smithy CLI では、モデルの構築、アドホック検証の実行、モデル間の相違点の比較、モデルのクエリなどを簡単に行うことができます。Smithy CLI を使用することで、Java をセットアップしたり、 Smithy Gradle Plugins を使用したりすることなく、Smithy での作業を簡単に開始できます。 AWS API モデルと Smithy 構築ツールを使用して独自のアプリケーションを構築する方法の例を 2 つご紹介します。 最小限の SDK クライアントを構築する – このサンプルプロジェクトは、 Smithy TypeScript を使用して Amazon DynamoDB 用の最小限の AWS SDK クライアントの作成を開始するためのテンプレートを提供します。Smithy モデルから最小限の SDK を構築し、その後でサンプルコードを実行できます。詳細については、こちらの サンプルプロジェクト をご覧ください。 MCP サーバーを構築する – このサンプルプロジェクトは、Smithy CLI を使用して MCP StdIO サーバーを実行するために必要なすべての依存関係が含まれる fat jar を生成するためのテンプレートを提供します。ツールを Smithy API としてモデル化することで MCP サーバーを構築するための MCPServerExample や、任意の Smithy サービス用のプロキシ MCP サーバーを作成するための ProxyMCPExample を見つけることができます。 詳細については、 GitHub リポジトリ をご覧ください。 今すぐご利用いただけます AWS API モデルリポジトリ と、 Maven Central で利用できるサービスモデルパッケージへのオープンソースアクセスを提供することで、AWS API モデルに毎日アクセスできるようになりました。選択した Maven パッケージを使用してモデルをインポートし、依存関係を追加することができます。 AWS が優先する API モデリング言語の詳細については、 Smithy.io と「 Code Generation 」ガイドをご覧ください。各 AWS SDK の詳細については、「 AWS での構築ツール 」と、 それぞれのリポジトリ にアクセスして SDK 固有のサポートを受けるか、通常の AWS サポート担当者にお問い合わせください。 – Channy 原文は こちら です。

さまざまな業界のお客様が AWS の生成 AI の力を活用して、従業員の生産性を高め、優れたカスタマーエクスペリエンスを提供し、ビジネスプロセスを合理化しています。しかし、GPU 容量に対する需要の拡大は業界全体の供給を上回っているため、GPU は希少なリソースとなり、その確保コストも増加しています。 Amazon Web Services (AWS) は成長するにつれ、コスト削減に努め、その節約分をお客様に還元できるようにしています。定期的な AWS サービスの料金引き下げ は、AWS がスケールから得た経済効率をお客様に還元するための標準的な方法となっています。 6 月 5 日、弊社は Amazon Elastic Compute Cloud (Amazon EC2) NVIDIA GPU 高速インスタンスの P4 (P4d と P4de) および P5 (P5 and P5en) インスタンスタイプについて、最大 45% の料金引き下げを発表しました。 オンデマンド および Savings Plans のこの料金引き下げは、これらのインスタンスが利用可能なすべてのリージョンに適用されます。料金引き下げは、6 月 1 日以降のオンデマンド購入と、6 月 4 日以降に有効となる Savings Plans の購入に適用されます。 以下は、2025 年 5 月 31 日からのインスタンスタイプと料金プラン別の基本料金の引き下げ率 (%) の表です。 インスタンスタイプ NVIDIA GPU オンデマンド EC2 Instance Savings Plans Compute Savings Plans 1 年 3 年 1 年 3 年 P4d A100 33% 31% 25% 31% – P4de A100 33% 31% 25% 31% – P5 H100 44% – 45% 44% 25% P5en H200 25% – 26% 25% – Savings Plans は、1 年または 3 年間にわたって一貫した使用量 (USD/時間で測定) をコミットすることと引き換えに、コンピューティング使用量を低価格で提供する、柔軟な料金モデルです。当社では 2 種類の Savings Plans をご用意しています。 EC2 Instance Savings Plans は最低料金で、あるリージョンの個々のインスタンスファミリーの使用量に対するコミットメント (米国 (バージニア北部) リージョンでの P5 の使用量など) と引き換えに割引を提供します。 Compute Savings Plans は最も柔軟性が高く、インスタンスファミリー、サイズ、アベイラビリティーゾーン、リージョンを問わないコスト削減に役立ちます (P4d から P5en インスタンスへ、米国のリージョン間でワークロードを移行する場合など)。 お客様が引き下げ料金を利用しやすくするために、当社では次に対する大規模なオンデマンドキャパシティを提供しています。 アジアパシフィック (ソウル)、アジアパシフィック (シドニー)、カナダ (中部)、欧州 (ロンドン) リージョンの P4d インスタンス 米国東部 (バージニア北部) リージョンの P4de インスタンス アジアパシフィック (ムンバイ)、アジアパシフィック (東京)、アジアパシフィック (ジャカルタ)、南米 (サンパウロ) リージョンの P5 インスタンス アジアパシフィック (ムンバイ)、アジアパシフィック (東京)、アジアパシフィック (ジャカルタ) リージョンの P5en インスタンス また、大規模なデプロイをサポートするために、Savings Plans を通じた Amazon EC2 P6-B200 インスタンス の提供を開始しました。これは、2025 年 5 月 15 日のリリース時に EC2 Capacity Blocks for ML を通じてのみ 利用可能 になりました。NVIDIA Blackwell GPU を搭載した EC2 P6-B200 インスタンスは、GPU 対応の幅広いワークロードを高速化しますが、特に大規模な分散 AI トレーニングや推論に適しています。 これらの料金更新は、コスト削減分を直接お客様に還元しながら、高度な GPU コンピューティングをより利用しやすいものにする AWS の取り組みを反映しています。 Amazon EC2 コンソール で Amazon EC2 NVIDIA GPU 高速インスタンスをお試しください。これらの料金更新の詳細については、 Amazon EC2 料金 ページにアクセスし、 AWS re:Post for EC2 に、または通常の AWS サポートの連絡先を通じて、フィードバックを送信してください。 – Channy 原文は こちら です。

本ブログは 2025 年 2 月 7 日に公開された Blog “ Allies can share data and technologies and remain compliant with international regulations using AWS ” を翻訳したものです。 国家安全保障と防衛は、国際的な同盟国間の緊密な協力に支えられています。これらの同盟国は、データや技術を含む互いの能力を活用したいと考えています。機密データを保護し、堅牢なサイバーセキュリティフレームワークを促進するために、組織は互いのコンプライアンス要件を考慮する必要があります。そのような要件の一つが、米国の 国際武器取引規制 (ITAR) です。これは米国の国家安全保障を守るために、防衛および軍事関連技術の輸出を制限・管理するものです。ここでは、 Amazon Web Services (AWS) 上の Trusted Secure Enclaves (TSE) が、クラウドを使用して最新かつ革新的な技術で防衛・安全保障任務を提供したい米国外の国家組織に対して、どのようにコンプライアンスを維持しながらこれを実現できるかを説明します。 ITAR はクラウド技術の真価や可能性が十分に理解される前の時代に、従来型のオンプレミス IT システムを前提として策定されました。しかし、Trusted Secure Enclaves の登場により、各国の政府機関や防衛関連組織は、ITAR 規制対象データを容易にクラウドサービスでも安全に扱えるようになりました。 2020 年 3 月、ITAR の改正により、以下のパラメータを持つ技術データを米国外に送信、持ち出し、または保存することは、輸出、再輸出、再移転、または一時的な輸入 (またはその他の管理対象イベント) に該当しないことが明確になりました。 機密指定されていないこと FIPS 140-2 準拠のアルゴリズムを使用したエンドツーエンドの暗号化で保護され、最低でも AES 128 ビットのセキュリティ強度と NIST 800-57 part 1 rev 4 の暗号化と同等の強度を持つこと クラウドサービスプロバイダーや第三者が復号用の暗号キーにアクセスできないこと データが意図的に §126.1 で規定された国 の人物に送信されたり、そこに保存されたりしないこと データが §126.1 で規定された国 から送信されないこと これらの保護措置は、AWS の 責任共有モデル の下でお客様と協力して容易に満たすことができます。責任共有モデルでは、AWS は仮想化レイヤーからサービスが運用される施設の物理的セキュリティまでのコンポーネントを管理・統制し、AWS のお客様は安全なアプリケーションの構築に責任を持ちます。AWS は、お客様がアプリケーションおよびアーキテクチャレベルのセキュリティ対策を提供する際に使用できる、幅広いベストプラクティス文書、暗号化ツール、およびその他のガイダンスを提供しています。さらに、AWS パートナーは、ネットワークセキュリティ、構成管理、アクセス制御、データ暗号化など、お客様がセキュリティ目標を達成するのに役立つ何百ものツールと機能を提供しています。 Trusted Secure Enclaves は、AWS が提供するガイダンスの一例です。TSE は、米国外でホストされる環境を含め、クラウド環境を必要とするユースケースでコンプライアンスとセキュリティ要件を満たすのを支援するために設計された、AWS が管理するオープンソースソリューションです。AWS は、グローバルな国家安全保障、防衛、法執行機関、および政府のお客様と共に TSE リファレンスアーキテクチャを設計し、クラウドのすべての利点にアクセスする際の厳格なセキュリティとコンプライアンス要件を満たすようにしました。米国国務省 (DoS) による輸出の定義の現代化と、ITAR コンプライアンスを管理するメカニズムとしての暗号化の使用に関する立場により、Trusted Secure Enclaves Sensitive Edition (TSE-SE) はこのユースケースを可能にする基礎的な構成要素となります。 AWS セキュリティリファレンスアーキテクチャ に基づき、TSE は AWS 上に事前設定されたセキュリティコントロールを備えたマルチアカウント環境をデプロイします。これらは、米国国務省の ITAR データ保護ガイダンスに沿った、一元化されたアイデンティティとアクセス管理、ガバナンス、データセキュリティ、包括的なログ管理、およびネットワーク分離に対応できます。TSE は迅速なセットアップを可能にし、セキュリティ要件を満たしながらクラウドでのイノベーションをサポートします。 防衛関連企業、軍事技術提供企業、航空宇宙メーカー、および政府関連の研究機関が ITAR コンプライアンス要件を確実に満たすために、TSE 環境で技術的コントロールを実装することができます。これらには以下が含まれます。 暗号化 – ITAR 管理データを保護するために、 AWS Key Management Service (AWS KMS) や AWS CloudHSM などのサービスを使用して、お客様が暗号化キーを制御する形で保存時に暗号化する必要があります。最新の AWS Nitro System ベースのインスタンスを使用します。これは Nitro インスタンス間のデータが AWS によって転送中に暗号化 されるためです。 AWS Certificate Manager (ACM) は、インターネット接続を保護する トランスポートレイヤー証明書 を自動的に更新およびローテーションできます。 データの場所 – AWS では、政府機関は選択した AWS リージョン (AWS がデータセンターをクラスター化する物理的な場所) およびアベイラビリティーゾーン (AWS リージョン内の 1 つ以上の個別のデータセンター) 内で機密ワークロードを実行し、データを保存できます。このようにして、データがどこに保存され処理されるかについて可視性を持ち、統制することができます。 アクセスコントロール – 組織はユーザーが認証するための外部 ID プロバイダーを選択します。TSE-SE 構成にはユーザー認証サービスである AWS IAM Identity Center が統合されており、ユーザーがサービスにシームレスにアクセスできるようになります。組織はユーザー管理と認証を一元化し、シングルサインオン機能のセキュリティと利便性の恩恵を受けることができます。 データ境界 – 強力なデータ境界の確立はコンプライアンスを達成するために不可欠です。データ境界は、信頼できる ID のみが予期されたネットワークから信頼できるリソースにアクセスすることを確実にするための予防的なガードレールのセットを作成するときに確立されます。AWS ホワイトペーパー Building a Data Perimeter on AWS はこのトピックを詳細に探求しており、TSE の既存のパターンに拡張されます。 ログ記録とモニタリング – TSE アーキテクチャでは、ユーザーアクティビティ、ネットワークトラフィック、セキュリティイベントなどのすべてのログが、専用のログアーカイブアカウントに一元化されることが要求されます。これにより、ログが安全に保存され、改ざんされないようにし、必要に応じて徹底的な監査と調査が可能になります。 さまざまな Amazon サービス (例えば、 Amazon GuardDuty 、 AWS Security Hub 、 AWS Config ) を通じて、不審なアクティビティやセキュリティ問題の継続的な監視が実現されています。これらのサービスはデータソースとログを分析し、セキュリティポスチャの包括的な視点を提供します。 そのため、組織は AWS 環境全体にわたるすべてのアクティビティを完全に可視化できます。これにより、あらゆるセキュリティインシデントを迅速に検出し対応することが可能になります。 政府機関が国家安全保障や防衛任務をサポートするために AWS の最新かつ革新的な技術を利用しながら ITAR コンプライアンスを満たす必要がある場合、TSE ベースの AWS Well-Architected フレームワーク によってその目標を達成できます。 関連情報 国家安全保障および防衛任務が AWS 上の Trusted Secure Enclaves でデータを保護する方法 John Nicely John は Amazon Web Services (AWS) のグローバル国家安全保障・防衛 (GNSD) チームのテクニカルビジネスデベロッパーで、セキュリティアーキテクチャとコンプライアンスに焦点を当てています。John はクラウドセキュリティ、認可プロセス、リスク管理の専門家です。John は米国連邦政府でキャリアをスタートし、国家安全保障および防衛コミュニティで 25 年以上の経験を持っています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。

本ブログは 2024 年 11 月 21 日に公開された Blog “ How national security and defence missions protect data with Trusted Secure Enclaves on AWS ” を翻訳したものです。 国家安全保障、防衛、法執行機関は、進化する市民への脅威に対抗するために、同盟国とほぼリアルタイムでデータを共有しコミュニケーションをするためにクラウドの利用を望んでいます。 例えば、英国の Cloud Strategic Roadmap for Defence (防衛のためのクラウド戦略ロードマップ) では次のように述べています。「デジタルバックボーンの重要な構成要素は、すべての機密レベルにわたるハイパースケールクラウド機能です。私たちの未来は、データを戦略的資産として活用し、敵よりも迅速に行動できるようにするものです。防衛は、これまでにない規模でデータを取り込み、集約、分析、活用する比類のない能力を持つことになります。」 別の例では、2030年までに NATO のデジタルトランスフォーメーションは、相互運用性、状況認識の向上、データ駆動型の意思決定により、マルチドメイン作戦 (MDO) を促進します。NATO 同盟国間の協力は最も重要であり、デジタルシステムとそれらに関するすべての標準とポリシーは、常にあらゆる環境、あらゆる機密レベルで相互運用可能かつ安全でなければなりません。また、任務のスピードに即時対応できる必要があります。主要な防衛技術イベントである NATO Edge 24 のテーマは「つなげる、革新する、高める」です。これは、同盟の防衛能力を強化する上で堅固なパートナーシップの重要性を強調しています。スピーカーの一人として、私はクラウド導入について議論します。 任務重視のソリューション 訓練から前線支援まで、Amazon Web Services (AWS) は各種部隊、軍事組織、同盟国が直面する課題を解決するためのソリューションを提供できます。クラウドでのコンピューティングとストレージ機能を提供するだけでなく、AWS は情報、計画、運用チームが、より新しくコスト効率の高い人工知能 (AI) や機械学習、分析、シミュレーション、その他のテクノロジーを活用するのを支援できます。 AWS はグローバルインフラストラクチャと安全でスケーラブルな任務重視のソリューションを提供します。国家安全保障、防衛、法執行機関、政府の厳格なセキュリティとコンプライアンス要件を満たすために、AWS はお客様と共に Trusted Secure Enclaves on AWS (TSE) を設計しました。これは、スピード、スケーラビリティ、セキュリティなど AWS クラウドがもたらすすべての利点を可能にするため、お客様の任務上の要件をサポートし、厳格なセキュリティ基準に準拠し、隔離環境を提供するリファレンスアーキテクチャです。 TSE の仕組み TSE アーキテクチャにより、組織はゼロから始める場合よりも迅速にクラウド内に安全な環境を構築・維持できます。これにより、ワークロード用の堅牢で準拠したスケーラブルな運用環境を確立するのに必要な時間を、数ヶ月から数時間に短縮できます。こちらの TSE の紹介動画 もご覧ください。 TSE は標準化、テンプレート化、自動化された安全な基盤を提供します。これにより、組織はクラウド内で独自の運用セキュリティポスチャを確立できます。TSE は、米国国防総省 (DoD) インパクトレベル 4 ( DOD IL4 ) や FedRAMP Moderate 、 NIST 800-53 Medium 、 ITSG-33 、カナダの CCCS-Medium 、オーストラリアの IRAP など、世界で最も厳格なセキュリティ基準を満たすための基盤を組織に提供します。 TSE 環境は、以下を含むセキュリティサービスの自動デプロイを通じて、コンプライアンス違反とセキュリティ脅威を可視化します。 Amazon Security Hub – クラウドセキュリティポスチャ管理 (CSPM) サービスで、セキュリティのベストプラクティスチェックを実行し、アラートを集約し、検出された問題に対する自動修復を可能にします Amazon GuardDuty – AWS アカウントと Amazon Simple Storage Service (Amazon S3) に保存されたデータを保護するために、悪意のあるアクティビティや不正な動作を継続的に監視するマネージド脅威検出サービス AWS Key Management Service (AWS KMS) – アプリケーションと AWS サービス全体で暗号化キーを作成、管理、制御できるサービス 世界中のセキュリティ重視のお客様は AWS を信頼しています。AWS は 143 以上のセキュリティ 認証と証明 、 法律と規制 、 プライバシー基準 、および 業界フレームワークへ準拠 しています。お客様が TSE を使用する場合、 AWS の責任共有モデル の下で機密および保護レベルのデータセキュリティ要件と義務を満たすことができます。この責任共有モデルにより、お客様は統制を保持し、選択したサービスをデプロイするために必要な柔軟性を持ちます。 関連情報 すでに Landing Zone Accelerator on AWS を使用している場合は、 Guidance for Trusted Secure Enclaves on AWS をご確認ください。AWS が初めての方は、 公共部門における AWS をご覧ください。 Chris Bailey Chris は Amazon Web Services (AWS) のワールドワイドパブリックセクターにおけるグローバル国家安全保障・防衛チームのゼネラルマネージャーです。国家安全保障および防衛クラウド導入プログラムの提供に関する専門家です。Chris は国家安全保障分野の開発者としてキャリアをスタートし、防衛産業基盤 (DIB) での 30 年以上の経験を持っています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。