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

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

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

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 原文は こちら です。