本ブログは、2025 年 10 月 14 日に Tim Trsar によって執筆された「 Big news: AWS expands AI certification portfolio and updates security certification 」を翻訳したものです。 本日、AWS は認定ポートフォリオの重要な更新を発表し、人工知能とセキュリティの分野における専門知識を検証するための取り組みを強化しました。 近日公開：AWS Certified Generative AI Developer – Professional 新しい認定「 AWS Certified Generative AI Developer – Professional 」の発表をお知らせします。この認定は、開発者が基盤モデルをアプリケーションやビジネスワークフローに効果的に統合する能力を検証します。ソフトウェア開発者や AI エンジニアは、基盤モデル、RAG アーキテクチャ、ベクトルデータベースを使用した本番環境対応の AI ソリューション構築における専門知識をアピールできます。 ベータ試験の登録は 2025 年 11 月 18 日に開始 され、合格したベータ参加者には特別な「Early Adopter バッジ」が授与されます。ベータ試験は 204 分間、 85 問の問題で構成されています。休憩を含むこの試験に関する情報については、 試験当日のポリシーページ をご覧ください。 ※ 訳者追記 : 本ベータ試験は日本語での受験が可能です。 「Exam Prep Plan: AWS Certified Generative AI Developer – Professional」は 2025 年 11 月 18 日に AWS Skill Builder で利用可能になります。この準備プランには、試験形式の問題による練習評価、AWS SimuLearn による実践練習、各試験ドメインとタスクステートメントを確認するレッスンが含まれます。この準備プランでは、 AWS の知識とスキルを更新するためのロールベーストレーニングも紹介します。 ※ 訳者追記 : 2025 年 11 月 18 日時点では「Exam Prep Plan: AWS Certified Generative AI Developer – Professional」は英語版にて提供予定です。 「AWS Certified Machine Learning – Specialty」の廃止 AI/ML 認定ポートフォリオの進化の一環として、「 AWS Certified Machine Learning – Specialty 」認定の廃止をお知らせします。 この試験の最終受験日は 2026 年 3 月 31 日です。すでに Machine Learning – Specialty を取得している方の認定は、元の有効期限まで有効です。 現在の認定保持者は、「AWS Certified AI Practitioner」、「AWS Certified Machine Learning Engineer – Associate」、「AWS Certified Data Engineer – Associate」、そして新しい「AWS Certified Generative AI Developer – Professional」認定を通じて、AI/ML 学習の旅を継続できます。 「AWS Certified Security – Specialty」の更新 「 AWS Certified Security – Specialty 」試験は、進化するセキュリティ環境に対応するために更新されます。新バージョン（SCS-C03）では、生成 AI と機械学習セキュリティに重点を置いて、新しいテクノロジーの適用範囲を拡大しています。セキュリティ専門家により良いサービスを提供するため、試験ドメインを再構成し、検出とインシデント対応機能のための明確なセクションを作成しました。 更新された試験（SCS-C03）の登録は 2025 年 11 月 18 日に開始されます。現行バージョン（SCS-C02）に関心のある方は、2025 年 12 月 1 日までに認定を完了する必要があります。 新試験の準備をする学習者をサポートするため、2025 年 11 月 18 日に AWS Skill Builder を通じて SCS-C03 向けの更新された試験準備プランを導入します。また、学習者は「 AWS Security Engineer Advanced Learning Plan 」に登録することで、AWS の知識とスキルを更新できます。このプランでは、AWS クラウドを使用したセキュリティエンジニアの役割を遂行するために必要なクラウドセキュリティの重要な側面をカバーしています。トレーニングは、事前計画、積極的なモニタリング、対応アクションという 3 つの主要機能に焦点を当てています。 これらの更新は、安全でスケーラブルな AI ソリューションを実装するために必要な専門知識を持つチームの構築を組織が行えるよう支援するという AWS のコミットメントを反映しています。これらの更新について詳しく知り、認定の旅を始めるには、 AWS Training and Certification Blog をご覧ください。 AI/ML AWS 認定について詳しく知るには、 Amazon blog をご確認ください。 翻訳は Technical Instructor の 室橋 弘和 が担当しました。

このブログ記事は、ネットアップ合同会社 ソリューションアーキテクト 井谷寛と AWS シニアソリューションアーキテクト 長田義広が共同で執筆し、株式会社東陽テクニカ テクニカルサポート 村吉翔大とネットアップ合同会社 シニアクラウドソリューションアーキテクト 藤原善基が監修しています。 はじめに ソフトウェア開発で利用される VCS ( Version Control System ) には、Git / Git LFS や Subversion、そしてUnity Version Control ( 旧名 Plastic SCM ) などがあります。しかしゲーム開発や映像制作で広く利用されるゲームエンジンである Unreal Engine と連携してよく使われるのが Perforce P4 ( 旧名 Helix Core、以降 Perforce と表記 ) です。 本記事では AWS 上で Perforce と NetApp ONTAP を組み合わせるメリットとして、大規模なソフトウェア開発に使えるストレージの効率化とコスト削減を実現する手法について説明します。 ※ Perforce に関する解説は こちら の AWS ブログにも記載があります Perforce と NetApp ONTAP を組み合わせるメリット 1. データ量の削減とストレージコストの削減 Perforce で管理するデジタルアセット ( 3DCG コンテンツや映像コンテンツ、ソースコードなど ) はプロジェクト間で流用や共有されることが多く、プロジェクト終了時にシステム管理者が削除を要請してもすぐに削除が可能になる訳ではありません。ソースコードであればデータ量は極端に大きくなることはありませんが、映像コンテンツはファイルサイズが大きい為サーバやストレージを圧迫します。どのデータを残してどれを削除するのかを選別するのは時間のかかる作業であり、また「あの時のあのバージョンが欲しい」という状況が将来発生することを考えると、プロジェクト終了時に過去のバージョンは全て捨てて最新バージョンだけ残すと割り切れないケースもあります。 このように多くのデータを保持する為に、重複排除機能を持ったストレージを活用してデータの保持コストを削減するアプローチがあります。バージョン管理システムには差分の少ない異なるデータが複数世代格納されることが多い為、一般的に重複排除が効きやすいです。NetApp ONTAP には重複排除機能があり、このボリュームを Perforce のリポジトリとして設定するだけでストレージコストを削減できます。 AWS 上で Perforce を利用する場合は Amazon FSx for NetApp ONTAP ( FSx for ONTAP ) を活用できます。マネジメントコンソールや AWS CLI を用いてユーザの VPC に NFS / CIFS / iSCSI プロトコルで接続可能なストレージを提供できます。 Amazon Elastic Compute Cloud ( Amazon EC2 ) インスタンスにインストールした Perforce サーバが FSx for ONTAP を NFS プロトコルなどでマウントし、そのパスを Perforce サーバ上でリポジトリとして定義すれば設定は完了です。 重複排除に加えて、FSx for ONTAP の階層化設定を追加するとアクセス頻度の低いデータは SSD 層から GB 単価の安いキャパシティ層にデータを透過的に移動するようになります。これにより同容量の Amazon Elastic Block Store (Amazon EBS) を Perforce サーバに割り当てるのに比べ半分以下のコストで運用できるようになります。 ※ FSx for ONTAP のコストは AWS Pricing Calculator から算出できます 図 1: EBS と FSx for ONTAP のコスト比較 ( 2025 年 7 月時点 ) これら FSx for ONTAP の機能を活用することでデータの管理コストを下げることが可能です。AWS の ガイダンス では 16TB 未満は EBS の GP3 ボリュームタイプの利用を推奨していますが、Perforce で扱うデータ量がそれ以下であっても、16TB 以上に容量が増えていく想定であれば FSx for ONTAP の利用を検討できます。 図 2: Guidance for Building Perforce Helix Core on AWS 2. Perforce サーバの負荷軽減 ( ストレージオフロード ) 開発規模の大きいプロジェクトであったり、複数拠点で大容量のデータ連携をする必要がある場合、そのデータ転送処理にPerforce サーバのリソースがとられることがあります。他の VCS と異なり Perforce では Perforce プロキシサーバや転送レプリカ、エッジサーバなどを立てて分散処理することが可能です。それでもパッチ適用やエラーログ調査などの運用コストが増えることを鑑みるとサーバ台数は最小限にすべきです。 以下の処理を NetApp ONTAP に任せることで、Perforce サーバの負荷を下げることができます。 A. ファイルの圧縮・解凍処理 B. ファイルのサーバ間ネットワーク転送 A. ファイルの圧縮・解凍処理 通常ファイルを受け取った Perforce サーバは、そのデータを圧縮した上でディポ ( リポジトリ ) に格納します。しかし大量のファイルを同時に処理するとこの圧縮処理でサーバの CPU 負荷が 100% になることがあります。また CPU コアが多い環境では、仮に空いているコアがあったとしても、圧縮のオーバーヘッドによりネットワーク帯域に余裕があるにもかかわらず転送レートが低い状態になることがあります。読み出し時にも解凍に CPU を使うため、大量のデータをダウンロードする際同様に Perforce サーバがボトルネックになることがあります。これらはプロキシサーバやエッジサーバで負荷分散していても、特定のサーバで発生し得ます。 ※圧縮のオーバーヘッド : Perforce サーバがクライアントから受信したデータは Perforce サーバの CPU を使って圧縮します。もし圧縮が無効であれば Perforce サーバは受信したデータをそのままディポに格納するため、サーバプロセスが圧縮することによる処理遅延 ( = データ転送を低下させる要素 ) が削減されます。 ※近年では VCS にデータを格納する前に圧縮をしてしまうアプリケーションも増えています。Unity などのゲームエンジンでは圧縮した状態で VCS にデータを渡すこともあり、VCS 側の圧縮設定をどうするかは注意すべき設計要素になりつつあります このような時は Perforce によるデータ圧縮を無効にして圧縮処理は外部のストレージに委ねます。NetApp ONTAP ストレージにはハードウェア圧縮・解凍するためのアクセラレータが搭載されています。ネットアップ合同会社のテスト環境では、圧縮済みのデータをサブミットする際に Perforce の gz 圧縮を無効化することで、ネットワーク転送スピードが 3 ～ 8 倍程度高速化することを確認しています。 Perforce で圧縮を無効にする方法は lbr.autocompress と p4 typemap の 2 種類があります。すべてのファイルタイプを非圧縮にするには後者の設定が有効です。 設定 (1) lbr.autocompress 1. 既存の設定を確認 ( p4 configure show ) Linux# p4 -u PERFORCE_SUPERUSER_NAME -p PERFORCE_SERVER_IP:PORT configure show allservers 以下のような行があれば、次の手順に進みます。 any: lbr.autocompress = 1 edge: lbr.autocompress = 1 master: lbr.autocompress = 1 2. 圧縮設定の解除 ( p4 configure unset ) Linux# p4 -u PERFORCE_SUPERUSER_NAME -p PERFORCE_SERVER_IP:PORT configure unset any#lbr.autocompress Linux# p4 -u PERFORCE_SUPERUSER_NAME -p PERFORCE_SERVER_IP:PORT configure unset edge#lbr.autocompress Linux# p4 -u PERFORCE_SUPERUSER_NAME -p PERFORCE_SERVER_IP:PORT configure unset master#lbr.autocompress 3. 明示的な非圧縮の設定 ( p4 configure set ) Linux# p4 -u PERFORCE_SUPERUSER_NAME -p PERFORCE_SERVER_IP:PORT configure set any#lbr.autocompress=0 edge や commit ではなく any を指定することで、Perforce 全体に設定が反映されます。 設定 (2) p4 typemap 1. p4 typemap ですべてのディポのすべてのファイルを非圧縮に指定 Linux# p4 -u PERFORCE_SUPERUSER_NAME -p PERFORCE_SERVER_IP:PORT typemap エディタが起動するので、すべてのディポ ( //... ) のすべてのファイル ( * ) を非圧縮 ( binary+F ) として扱うように設定します。 TypeMap: binary+F //...* エディタを保存して終了すれば、設定完了です。 ※ Perforce のバージョン2022.1 以降、 lbr.autocompress は “1” がデフォルト値になっています。古いバージョンを使用しているユーザは、現在の設定値を事前にご確認ください ※ Perforce に設定可能なパラメータの一覧は 公式サイト に記載があります 図 3: lbr.autocompress の設定 B. バージョン化ファイルの Perforce サーバ間ネットワーク転送 このオフロードは Perforce を分散サーバ構成にしたときに有効です。Perforce の分散アーキテクチャ ( 7 種類 ) はこちらの ドキュメント に記載があります。 ※ Perforce の中心となるサーバにはセントラルサーバやマスタサーバ、コミットサーバなどいくつかの呼び方がありますが、本ブログでは「コミットサーバ」と表記を統一します プロキシサーバやエッジサーバがコミットサーバから離れている場所に存在する場合、通常 Perforce クライアントがプロキシサーバなどにデータをリクエストするとプロキシサーバはコミットサーバにファイルを要求し、そのデータをプロキシサーバのキャッシュ領域に保存しつつ Perforce クライアントにデータを渡します。 図 4: 通常の Perforce サーバ間データ同期 これに対して、NetApp ONTAP の機能と連携してデータを同期する場合は以下の様になります。 図 5: NetApp ONTAP の機能を使った Perforce サーバ間データ同期 サーバ間のファイル転送は NetApp ONTAP の FlexCache という機能を使い、Perforce の機能とは別でデータを転送します。。FlexCache が設定された NetApp ONTAP ストレージをプロキシサーバやエッジサーバがマウントすると、キャッシュストレージにはオリジンストレージのファイルシステムのメタデータのみを転送・保存するため、実体データがキャッシュに存在しなくてもコミットサーバ上のすべてのディポのデータにプロキシサーバが直接アクセスできる状態になり、Perforce サーバ間のバージョン化ファイルの転送が不要になります。 ※実データの転送は Perforce 間で行われませんが、Perforce 内部でメタデータを管理するデータベースへのアクセスは引き続き Perforce 間で行われます FSx for ONTAP でもこの FlexCache を使えるため、AWS に立てた Perforce サーバもこの機能の恩恵を受けることができます。 ※データを二重持ちするわけではなく、NetApp ONTAP のキャッシュ機能を活用するため、キャッシュ側のストレージコストは最小限となります ※キャッシュストレージの容量が溢れそうになると、ストレージが自動的にアクセス頻度の低いデータをキャッシュから削除して空きスペースを確保します 3. リモート拠点やクラウドとのデータ連携作業の簡易化 Perforce は分散アーキテクチャを採用しているため、2.B. で説明したサーバ間転送を用いなくても利用することは可能です。しかし特に距離の離れた拠点との通信ではネットワークの遅延が大きいことによる性能低下が発生するため、Perforce サーバのチューニングだけでなくその下で動く Linux OS のチューニングも必要になることがあります。 自社の環境にあわせてこれらを適切に設定するには幅広い知識とスキル・経験が必要になりますが、NetApp ONTAP のストレージキャッシュ技術を組み合わせることでそのハードルを下げることができます。リモート拠点のプロキシサーバやエッジサーバはその拠点に設置されたキャッシュ用の NetApp ONTAP、AWS 上では FSx for ONTAP をマウントするだけで、高速なデータ連携が可能になります。 図 6: エッジサーバと組み合わせた場合の構成例 まとめ ネットアップ合同会社には日本のお客様向けに Perforce と AWS を連携させて検証できる環境があります。また海外リージョンの FSx for ONTAP と接続して性能検証を行う設備もそろっています。バージョン管理システムの運用管理にお困りの方はご相談ください。 AWS では多くのゲーム会社様が AWS のクラウドサービスを使ってゲームを開発・運用するための技術支援をしています。またこのブログの様に AWS パートナー企業と共同でゲーム会社様に役立つ情報をご紹介したり、CEDEC や GDC などのゲーム業界イベントや AWS 主催のイベントでも情報を発信しています。私たちの活動がゲーム業界の発展に貢献できる様、今後も技術とビジネスの両面から全力でお客様をサポートしていく所存です。 著者 ( 敬称略 ) 井谷 寛 ネットアップ合同会社 ソリューションアーキテクト部 ソリューションアーキテクト ハイブリッド・マルチクラウドの提案を得意とするエンジニア。様々な技術を組み合わせて検証し、ソリューション化して、販売から事例化までトータルでお客様をサポートしている。お客様やパートナー様と一緒に手を動かして現実的な提案をするのが得意。 村吉 翔大 株式会社東陽テクニカ ソフトウェア・ソリューション テクニカルサポート 藤原 善基 ネットアップ合同会社 AWS SE Support シニアクラウドソリューションアーキテクト Amazon FSx for NetApp ONTAPの技術支援を担当するエンジニア。NetAppが持つONTAPのナレッジと、AWSとFSx for ONTAPの共同開発・共同営業を通して積み上げた実績と経験に基づくTIPSを資料として公開・トレーニングや案件支援などを行なっている。新卒で国際物流業の物理コンテナを扱う営業になった後、現職まで複数の業種・職種を経験。 長田 義広 アマゾンウェブサービスジャパン合同会社 ゲームスペシャリスト シニアソリューションアーキテクト ゲーム会社でインフラエンジニア、ゲームプログラマなどを務めた後 AWS Japan に入社。ゲーム業界のお客様だけでなくゲームエンジンを使ったストリーミング配信やメタバースなどノンゲーム分野も支援している。社内ではゲーム・ストレージ・メディアの3つの技術コミュニティで活動中。

世界中の組織が、お客様体験の向上、業務の効率化、イノベーションの推進を目的として、生成 AI の機能をアプリケーションに統合しています。生成 AI ワークロードの規模と重要性が増すにつれ、AI を活用したアプリケーションの一貫したパフォーマンス、信頼性、可用性を維持することが新たな課題となっています。同時に、多くの日本企業では、データレジデンシー要件やコンプライアンス規制により、データ処理を国内に限定する必要があります。 このニーズに応えるため、 Amazon Bedrock では Anthropic の最新モデル Claude Sonnet 4.5 / Claude Haiku 4.5 と共に、 日本国内クロスリージョン推論 (Japan Cross Region Inference) を導入しました。このマネージドな機能により、推論リクエストを日本国内のリージョンに限定自動的にルーティングし、開発者が需要の変動を予測したり、複雑な負荷分散メカニズムを実装したりすることなく、トラフィックバーストをシームレスに処理できるようになります。 本記事では、日本国内クロスリージョン推論の仕組み、そして Claude 4.5 シリーズと組み合わせることで、コンプライアンス要件を満たしながら生成 AI アプリケーションのパフォーマンスと信頼性を向上させる方法について解説します。 日本国内クロスリージョン推論のコア機能 日本国内クロスリージョン推論は、データを日本国内に留めながら、東京リージョンと大阪リージョンの計算リソースを活用することで、予期しないトラフィックバーストに対応します。このセクションでは、この機能の動作原理と、その基盤となる技術メカニズムについて説明します。 推論プロファイルの理解 Amazon Bedrock における 推論プロファイル は、基盤モデルと、モデル呼び出しリクエストをルーティング可能なひとつ以上のリージョンのセットを定義します。Claude 4.5 の日本国内クロスリージョン推論プロファイルは、この概念を地理的境界内で適用し、リクエストを日本国内のリージョン (東京リージョンもしくは大阪リージョン) のいずれかにルーティングすることで、データレジデンシー要件を満たしながら、予期しないトラフィックバーストに備えて複数リージョンにトラフィックを分散できます。 推論プロファイルについて理解するために重要な概念として以下のふたつがあります。 ソースリージョン – API リクエストが発行されるリージョン デスティネーションリージョン – Amazon Bedrock が推論のためにリクエストをルーティングできるリージョン 日本国内クロスリージョン推論では、デスティネーションリージョンは以下の日本国内のリージョンに限定されます。 ap-northeast-1 (東京リージョン) ap-northeast-3 (大阪リージョン) これにより、すべての推論処理が日本国内で完結し、データが国外に出ることはありません。 かつ、クロスリージョン推論では、モデルの可用性、キャパシティ、レイテンシーなど複数の要素を考慮して、最適なリージョンにリクエストをルーティングします。リクエストの割り振りには手動設定を必要とせず、自動的に最適な利用可能リージョンを選択します。 モニタリングとロギング クロスリージョン推論を使用する場合、 Amazon CloudWatch と AWS CloudTrail は、リクエストが発生したソースリージョンにのみログを記録します。これにより、推論リクエストが最終的にどこで処理されるかに関係なく、すべてのレコードを単一のリージョンに維持することで、モニタリングとロギングが簡素化されます。 どのリージョンがリクエストを処理したかを追跡するためには CloudTrail の記録を参照できます。CloudTrail イベントには、デスティネーションリージョンを指定する inferenceRegion キーを持つ additionalEventData フィールドが含まれています。これにより、日本国内の AWS インフラストラクチャー全体での推論リクエストの分散を監視および分析できます。 データセキュリティとコンプライアンス Amazon Bedrock の通常のオンデマンド推論と同様に、クロスリージョン推論においても、データセキュリティの高い基準を維持します。クロスリージョン推論中に送信されるデータは、 暗号化され、安全な AWS ネットワーク内に留まります 。機密情報は、どのリージョンがリクエストを処理するかに関係なく、推論プロセス全体を通じて保護されます。 セキュリティとコンプライアンスは AWS とお客様の間における共同責任 であるため、異なる地理的場所での推論リクエスト処理に伴う法的またはコンプライアンス要件も考慮する必要があります。日本国内クロスリージョン推論では、リクエストは日本国内のリージョンのみにルーティングされるため、データレジデンシー要件を満たしながら、高可用性とスループットのメリットを享受できます。 日本国内クロスリージョン推論の実装 Claude 4.5 で日本国内クロスリージョン推論は以下のステップで使用できます。 日本国内クロスリージョン推論プロファイル ID を使用 – Amazon Bedrock への API 呼び出しを行う際、リージョン固有のモデル ID の代わりに、日本国内クロスリージョン推論プロファイル ID (Claude Sonnet 4.5 の場合は jp.anthropic.claude-sonnet-4-5-20250929-v1:0 、Claude Haiku 4.5 の場合は jp.anthropic.claude-haiku-4-5-20251001-v1:0 ) を指定する。これは InvokeModel API と Converse API の両方で機能する。 IAM 権限の設定 – 推論プロファイルと、デスティネーションリージョンの基盤モデルにアクセスするための適切な AWS Identity and Access Management (IAM) 権限を付与する。 適切な IAM 権限の詳細な設定方法と前提条件については、以下の公式ドキュメントをご参照ください。 推論プロファイルの前提条件 推論プロファイルをモデル呼び出しで使用する サービスクォータの管理 日本国内クロスリージョン推論のサービスクォータ増加を申請する場合、それぞれのソースリージョン (日本の場合は東京もしくは大阪) の AWS Service Quotas コンソール を使用します。例えば Claude Sonnet 4.5 モデルのクォータ増加をリクエストする際には、以下の画像のように関連する特定のクォータを検索し、特定のリージョンでのワークロード要件に基づいて増加申請を提出できます。詳しくは Amazon Bedrock のクォータ管理ドキュメント をご参照ください。 日本国内クロスリージョン推論の料金 グローバル全体分散のクロスリージョン推論に比べて、日本国内クロスリージョン推論では 10% 上乗せの料金設定になっています。以下は Claude Sonnet 4.5 および Claude Haiku 4.5 の料金表です。その他のモデルも含めた詳しい料金は Amazon Bedrock 料金ページ をご参照ください。 モデル ゾーン 入力 (100万トークン当たり) 出力 (100万トークン当たり) プロンプトキャッシュ書き込み (100万トークン当たり) プロンプトキャッシュ読み込み (100万トークン当たり) Claude Sonnet 4.5 グローバル $3 $15 $3.75 $0.3 Claude Sonnet 4.5 日本 (US/EU/オーストラリアも同様) $3.3 $16.5 $4.125 $0.33 Claude Haiku 4.5 グローバル $1 $5 $1.25 $0.1 Claude Haiku 4.5 日本 (US/EU/オーストラリアも同様) $1.1 $5.5 $1.375 $0.11 日本国内とグローバルのクロスリージョン推論の選択 現在 Amazon Bedrock で Anthropic の従来モデルを使用している場合、Claude Sonnet/Haiku 4.5へアップグレードすることで生成 AI アプリケーションの性能を強化することができるでしょう。従来の Claude 3/3.5/3.7/4 といったシリーズのモデルから切り替えるべき主な理由としては、 Sonnet 4.5 / Haiku 4.5 のさまざまなドメインにおける優れたパフォーマンスが挙げられます。エージェント型ツール利用、コンピュータ利用といったエージェント構築における汎用な能力の向上だけでなく、特にコーディングや金融分析といった領域においても最先端のパフォーマンスを持つことが示されています。Claude Haiku 4.5 に関しては Sonnet シリーズの 1/3 のコストで利用でき、かつコード生成能力としても従来の Sonnet 4 よりも高いベンチマークスコアを達成するなど、コストパフォーマンスに優れたモデルであることも注目に値します。 また、 発表から時間が経過した旧来のモデル は、最新のモデルよりも信頼性が低い可能性があることにご注意ください。最高レベルのサポートと信頼性を維持するために、ワークロードを最新なモデルに移行することを強くお勧めします。 グローバル分散のクロスリージョン推論を選択すべきケース データレジデンシー要件がない、または柔軟に対応できる 世界中の Amazon Bedrock 対応リージョンのリソースプールを活用して、最大限のスループットを確保したい グローバルに展開するアプリケーションで、世界中どこからでも同等のパフォーマンスを提供したい 日本国内クロスリージョン推論を選択すべきケース データレジデンシー要件があり、データを日本国内に留める必要がある 金融、医療、政府などの規制業界で、国内完結のデータ処理が求められる コンプライアンス規制により、データの国外転送が制限されている ビジネス要件として、データ処理場所を明確に特定・管理する必要がある 10%上乗せのプレミアム料金を許容できる これまでデータレジデンシー要件により、東京リージョンで利用可能な Claude 3.5 Sonnet 等のモデルを利用されていたお客様も、ぜひ日本国内に閉じて推論処理を実行できる Claude Haiku 4.5 もしくは Claude Sonnet 4.5 の利用をご検討ください。 まとめ Amazon Bedrock で新しく利用できるようになった Claude Sonnet/Haiku 4.5 では、日本国内クロスリージョン推論の機能により、日本に閉じたデータ処理が可能です。簡単な実装と、CloudTrail および CloudWatch による包括的なモニタリングにより、コンプライアンス要件を満たしながら、最先端の生成 AI モデルを活用できます。 Claude Sonnet/Haiku 4.5 の日本国内クロスリージョン推論をお試しいただく際には、Amazon Bedrock のマネジメントコンソールの「チャット/テキストのプレイグラウンド」において、そのメリットを直接体験することをお勧めします。また、皆様のアプリケーションにおいても、日本国内クロスリージョン推論プロファイル ID (Claude Sonnet 4.5 の場合は jp.anthropic.claude-sonnet-4-5-20250929-v1:0 、Claude Haiku 4.5 の場合は jp.anthropic.claude-haiku-4-5-20251001-v1:0 ) を使用するようにコードを更新し、適切な IAM 権限を設定し、アプリケーションが日本国内の AWS インフラストラクチャーを活用して推論を実行する様子を監視してください。 Amazon Bedrock の日本国内クロスリージョン推論の詳細については、 クロスリージョン推論によるスループットの向上 、 推論プロファイルのサポートされるリージョンとモデル 、 モデル呼び出しでの推論プロファイルの使用 を参照してください。 著者について 本橋 和貴 (Motohashi, Kazuki) は、AWS Japan の機械学習ソリューションアーキテクトです。AI/ML 領域には8年ほど携わっており、AWS の生成 AI/ML サービスを利用する日本のお客様や AWS パートナー企業をサポートしています。最近購入したファイナルファンタジータクティクスを子育ての傍らプレイする時間を探していますが、まだ起動すらできていません。博士 (理学)。 菊地 貴彰 （Kikuchi, Takaaki）は、AWS Japan で通信業界のお客様を担当するソリューションアーキテクトです。最近は学生時代の専攻である機械学習の知見を活かし、ビジネスにおける AI/ML の活用に関するご支援を多く行っています。趣味は音楽鑑賞であり、ライブ参加後は首が筋肉痛になります。 片山 洋平 (Katayama, Yohei) は AWS Japan のパブリックセクターのソリューションアーキテクトです。主に医療機関をはじめとしたヘルスケア業界のお客様のソリューション構築の支援を行なっています。週末は登山を嗜んでいます。

本ブログは 株式会社 マキタ様 と Amazon Web Services Japan 合同会社  が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの森です。 最近、製造業のお客様における生成 AI を活用した業務効率化の取り組みが加速しています。特に内製開発による AI 活用は、企業独自の課題に対応した柔軟なソリューションを低コストで実現できる点で注目されています。今回は、船舶用ディーゼルエンジンの製造・販売・アフターサービスを手がける株式会社マキタ様が AWS を用いて経営ダッシュボードと労働災害報告書作成支援 AI を「短期間」かつ「システム開発経験の少ないエンジニア主導の開発体制」で内製した事例をご紹介します。 なお、本取り組みは、AWS ジャパンが 2025年7月15日に開催いたしました中堅・中小企業向け事業戦略説明会にて、株式会社マキタ 執行役員 情報企画部 部長 高山 百合子様よりご紹介いただきました。 なお、中堅・中小企業のお客様のビジネス成長や新たな価値創出に向けた、2025年度の新たな AWS の取り組み、生成 AI の事例の詳細については こちら  をご参照ください。 株式会社マキタ様の状況と検証に至る経緯 株式会社マキタ様は、船舶用ディーゼルエンジンを製造する企業として、各種業務システムを AWS で運用しておりましたが、以下のような課題を抱えておりました。 経営判断に必要なデータが社内の様々な部門に分散しており、迅速な意思決定を行う上でボトルネックとなることがあった。 労働災害報告書の作成に多くの時間を要し、提出者ごとに記載および検討レベルにばらつきがある。また過去の類似事例や法令確認についても経験と知識が必要なため属人化しており、多面的な対策検討が不足しがちだった。 そこで Amazon QuickSight (* 現 Amazon Quick Suite) や Amazon Bedrock をはじめとしたマネージドサービスを活用して、これらの課題を解決するソリューションの検証をすることになりました。 生成 AI を活用して、以下2つのソリューションを情報システム部門にて内製開発しました。 (*) Amazon QuickSight は先日リリースされた Amazon Quick Suite の一部に統合されました。詳細は こちら をご覧ください。 ソリューションと構成 1. 経営ダッシュボード 本ソリューションは、クラウドストレージに取り込んだ情報ソース（就労、人材管理、会計データ）を基に、Amazon QuickSight を活用して可視化しています。 AWS Lambda を活用した各種 SaaS やオンプレ環境からのデータを効率よく収集・整形 AWS Glue DataBrew を活用した ETL 処理でデータを効率的に変換して Amazon S3 にて一元管理 Amazon QuickSight を活用してデータを取り込み経営ダッシュボードとして可視化 2.労働災害報告書作成支援 AI 本ソリューションでは、Amazon Bedrock を活用して労働災害報告書の作成・分析プロセスを効率化しました。 AWS で構築していた既存の AI チャット基盤（Dify）のアーキテクチャを踏襲し、労働災害報告書作成支援 AI を Amazon Bedrockと Python で構築 製造業で一般的なリスクアセスメント手法に沿った網羅的な AI 提案により、原因分析と対策立案時に関係者の議論を支援 マルチエージェントコラボレーション機能により、使用目的に応じた柔軟に思考する AI を実現 RAG ( Retrieval Augmented Generation ) とデータベース（MCP : Model Context Protocol 経由での呼び出し）を使い分け、過去の災害情報や法令情報を効率的に検索・参照できる仕組みを実装 AWS のセキュアなネットワーク内で、機密性の高い労働災害情報や社内データを外部に漏らすリスクを排除しながら、AI を活用した業務効率化を実現しました。 導入効果 上記のソリューションをリリースした結果、以下のような効果が得られました。 1. 経営ダッシュボード 統一された情報の見える化により各部門の自走的なデータ活用が促進 7 つのダッシュボードで 231 の指標を可視化することに成功。更新頻度の上昇や視認性の向上、ドリルダウン機能の実装により、判断・意思決定スピードが向上 ダッシュボード構築によりデータの共有や運用が標準化され、集計や分析の属人化リスクを軽減 2. 労働災害報告書作成支援 AI 過去事例を踏まえた多角的な分析により人間では見落としがちな災害要因を発見し、再発防止策の質が向上 AIによる網羅的な原因分析やリスクアセスメント提案による検討漏れ防止 過去 15 年分の自社災害 DB を AI が検索分析し、従来活用が難しかった過去データの有効活用を実現 お客様の声（株式会社マキタ様） AWS はスモールスタートが容易で仕組みの再利用ができるため、内製のハードルが下がり、短期間での実装実現につながりました。安定した AWS 基盤上で完結する、多機能な AI 開発環境を使えることが、AWS 上で AI を使うメリットです。AWS の豊富なサービスを活用することによって、システム開発経験者の少ない状況でも、7カ月で経営ダッシュボードを、1.5 カ月で報告書作成支援 AI を内製開発できました。これは、潤沢にエンジニアを抱えることができない中堅・中小企業にとって、非常に魅力的な要素だと感じています。 ダッシュボードも AI も、「蓄積されたデータを使い、人が判断したり、効率を上げたり、楽をしたりするためのツール」という意味でよく似ています。今後、より多くの社員が同時に利用したり、複雑な業務にも利用したいという要望が増えると考えています。実際、既に 200 近い AI とダッシュボード関連の活用案が、社内の全部門から寄せられています。それらの声に応えられるよう、私たちの部門で最新技術情報をキャッチしながら、更なるデータ活用と AI の高度利用を推進していきます。 まとめ 本事例は、製造業の企業が AWS の生成 AI サービスを活用することで、セキュリティを確保しつつ、業務効率化と安全対策の高度化を実現した好例です。株式会社マキタ様の内製化への積極的な姿勢と、AWS が提供する運用負荷の少ないマネージドサービス群が、経営ダッシュボードと労働災害報告書作成支援 AI の内製開発により、データ活用と業務プロセスの効率化を同時に達成しています。 製造業における生成 AI の活用は、業務効率化だけでなく、生産性の向上や労働環境の安全性向上など様々な面で効果を発揮します。本事例が、様々な業種のお客様の AI 活用の参考になれば幸いです。AWS での生成 AI 活用や内製開発の推進にご興味をお持ちの方は、お気軽にご相談ください。 株式会社マキタ (右から) 執行役員 情報企画部 部長 高山 百合子 様 情報企画部 宮﨑 凌大 様 情報企画部 佐藤 功併 様 情報企画部 岡 育美 様 経営企画部 谷 かすみ 様 株式会社マキタ : 執行役員 情報企画部 部長 高山 百合子様（中央） Amazon Web Services Japan : アカウントマネージャー 植木 輝（左）、ソリューションアーキテクト 森 瞭輔（右） ソリューションアーキテクト 森

本稿は、2025 年 3 月 11 日に公開された “ Efficiently manage Amazon EC2 On-Demand Capacity Reservations (ODCRs) with split, move, and modify ” を翻訳したものです。 はじめに 今日のクラウドファーストの世界では、アプリケーションの可用性を確保しながらコンピューティング能力を効率的に管理することがビジネスにとって非常に重要です。 Amazon EC2 オンデマンドキャパシティ予約（ODCR） は、予約を管理したいが、複数のチームやアカウントにまたがる予約を管理するのは難しいと考える組織にとって有用なツールです。2024 年 8 月に、キャパシティ予約の管理に新しい機能（分割、移動、変更）が導入されました。このブログでは、これらの機能がどのように業務を変えることができるかご紹介します。 ODCR に関するよくある課題 ODCR を活用する際、キャパシティ予約の管理についていくつか課題に直面することがあります。これらの課題には以下が含まれますが、これらがすべてではありません。 一部のアカウントで予約したキャパシティが十分に活用されていない 余剰キャパシティを効率的に再配分できていない 複数の AWS アカウントにわたる既存キャパシティの管理が難しい キャパシティ予約後の変更が難しい 複数の開発チームと様々なプロジェクトが同時に進行している場合、効率的なキャパシティ割り当てに苦労するかもしれません。また、あるチームではキャパシティが余っている一方で、別のチームではキャパシティが切実に必要になっているという状況に直面することもありえます。 ユースケース 1: チーム間でのキャパシティの再配分 未使用キャパシティのジレンマ 機械学習（ML）チームが c5.2xlarge インスタンス 10 個分の ODCR を所有しているものの、実際に使用しているのは 5 個のみというシナリオを考えてみます。一方、分析チームは新しいプロジェクトのために、同じタイプの Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを 3 個を必要としています。これまでであれば、分析チームは新しいキャパシティ予約を作成する必要があり、独自のキャパシティ予約を管理するという不要な作業が発生していました。一方、ML チームが所有する ODCR の未使用のキャパシティ 5 個分は、不要なコストを発生させています。 キャパシティの分割 キャパシティ予約の 分割機能 を使用すると、EC2 インスタンス 10 個分の ODCR （図 1 の ODCR-1）を分割し、未使用キャパシティ 3 個分を使用して新しい ODCR を作成できるようになります。 図 1: キャパシティ分割前の ODCR-1 のキャパシティ この機能により、2 つの ODCR が作成されます。 元の ODCR（ODCR-1）: ML チーム向けのインスタンス 7 個分のキャパシティ 新しい ODCR（ODCR-2）: 分析チーム向けのインスタンス 3 個分のキャパシティ 分割されると次の図のようになります。 図 2: キャパシティ分割により更新された ODCR-1 と新しく作成された ODCR-2 アカウント間の共有 キャパシティ予約の分割機能により、同じ AWS アカウント内に新しい ODCR が作成できます。チームが同じ AWS アカウントで作業している場合は、分割は直接実行され、追加の作業は必要ありません。ただし、チームが異なる AWS アカウントを使用している場合は、分割後に新しく作成された ODCR を 共有 するために、 AWS Resource Access Manager (AWS RAM) を使用する必要があります。これにより、アカウント間で共有されたキャパシティ予約も一元管理できます。 キャパシティを分割する場合の前提条件と考慮事項の詳細については、 AWS ドキュメント を参照してください。 また、パラメーターや例外、制限などの詳細については、 API および CLI のドキュメントを参照してください。 ユースケース 2: ODCR 間のキャパシティの移動 成長に合わせたスケーリング 数日後、分析チームではプロジェクト拡大のためにさらにインスタンス 1 個分のキャパシティが必要になり、ODCR-2 にキャパシティをさらに追加する必要が出てきました。 キャパシティの移動 この目的のために新しい ODCR を作成するのではなく、未使用キャパシティの 1 つを ODCR-1 から ODCR-2 に 移動 することができます。この柔軟性により、新しくキャパシティ予約を作成する手間が省かれ、既存のワークロードの実行も中断されず、ODCR の管理をシンプルにできます。キャパシティの移動により、追加の調達を行うことなく、最適なリソース使用率を確保できます。 図 3: キャパシティ移動前の ODCR-1 と ODCR-2 図 4: キャパシティ移動によりキャパシティを減らした ODCR-1 とキャパシティが追加された ODCR-2 キャパシティを移動する場合の前提条件と考慮事項の詳細については、 AWS ドキュメント を参照してください。 また、パラメーターや例外、制限などの詳細については、 API および CLI のドキュメントを参照してください。 ユースケース 3: 変化するワークロードのパターンに合わせたキャパシティ予約属性の調整 動的なワークロード要件 データ処理のワークロードパターンが大きく変化する場合は、それに適応する必要があります。最初は、ODCR を特定のインスタンスに限定する基準で作成し、予測可能なワークロードを対象としていました。ですが、より動的で即興的な分析プロジェクトを導入するにつれて、予約に対してインスタンスを起動する方法をより柔軟にする必要が出てきました。 キャパシティ予約の変更 キャパシティ予約の 変更 により、新しい予約を作成したり、実行中のワークロードを中断したりすることなく、予約の属性を変更できるようになりました。ODCR は以下の変更が可能です。 インスタンス数の変更 インスタンスの適格性の変更（ターゲットからオープンへ） プロジェクトのタイムラインに合わせたキャパシティ予約の終了日の変更 キャパシティ予約の変更により、以下のことができるようになります。 厳密なインスタンスの適格性がなくても、新しいインスタンスをより柔軟に起動可能 さまざまなプロジェクトにおけるキャパシティ予約の使用率向上 変化するビジネスニーズに適応しながら、コストの最適化 この機能は、既存のワークロードが中断されることなく継続的に実行されることを保証しながら、柔軟性を確保できるため、動的なワークロードにとって非常に貴重なツールとなります。ODCR-2 のキャパシティを 4 から 6 に変更する例については、次の図をご覧ください。 図 5: キャパシティ予約変更前の ODCR-2（全体キャパシティは 4 でインスタンスの適格性はターゲット） 図 6: キャパシティ予約変更後の ODCR-2（全体キャパシティは 6 でインスタンスの適格性はオープン） ODCR の規模を拡大したり、新規に作成したりするには、Amazon EC2 オンデマンドインスタンスのキャパシティに空きがあることが条件となります。したがって、既存の ODCR に未使用のキャパシティがある場合は、ODCR を変更するよりも、その ODCR を移動または分割する方が適切な選択肢となる場合があります。 キャパシティ予約を変更する場合の前提条件と考慮事項の詳細については、 AWS ドキュメント を参照してください。 また、パラメーターや例外、制限などの詳細については、 API および CLI のドキュメントを参照してください。 キャパシティ分割に関する特別な考慮事項 前のセクションでは、キャパシティ分割機能を使用して未使用の余剰キャパシティを切り離し、別のチームの ODCR を作成する方法について説明しました。また、この機能を使用して、使用済みキャパシティを分割して新しい ODCR を作成することもできます。この機能は、部分的に使用されている ODCR を分割して新しい ODCR を作成し、追跡と管理を容易にしたい場合に特に役立ちます。未使用や余剰キャパシティの分割に関する 考慮事項 に加えて、使用済みキャパシティの分割には以下の考慮事項があります。 使用済みキャパシティは、どのアカウントとも共有されておらず、インスタンスの適格性がオープンである ODCR に対してのみ分割できる キャパシティ予約内で実行されているインスタンスの適格性はオープンである 使用済みキャパシティを分割すると、適格性のあるインスタンスがランダムに選択される。分割対象のインスタンスを指定することはできず、数量を満たすのに十分な数の適格性のあるインスタンスが見つからない場合、キャパシティ分割は失敗する。分割するインスタンス数を指定すると、デフォルトでは未使用のキャパシティが最初に移動され、次に適格性のある実行中のインスタンス（予約内の使用済みキャパシティ）が移動される 次のセクションでは、キャパシティ分割を使用できるシナリオと使用できないシナリオについて説明します。 シナリオ 1: 社内における ODCR の管理（他の AWS アカウントと共有されないキャパシティ予約） 社内プロジェクトで利用する ODCR が、他の AWS アカウントを持つ外部パートナーと共有せず、インスタンスの適格性がオープンであるシナリオとして、以下の条件を満たす ODCR-1 を考えてみます。 全体キャパシティが 10 個の c5.2xlarge インスタンス（インスタンスの適格性はすべてオープン） 現在 ML チームが使用しているインスタンスは 8 個 未使用のインスタンスは 2 個 図 7: キャパシティ分割前の ODCR-1（全体キャパシティは 10 で未使用キャパシティは 2） この ODCR は他の AWS アカウントと共有されないため、キャパシティ予約を分割する際の柔軟性を最大限に高めることができます。現在使用中のインスタンス数に関わらず、最大 9 個のインスタンスを新しいキャパシティ予約（全体キャパシティから 1 を引いた数）として分割できます。このシナリオでは、使用済みキャパシティと未使用キャパシティの両方を共有できます。これにより、社内チームのキャパシティ割り当てを柔軟に再編成できます。 図 8: キャパシティ分割により更新された ODCR-1 と新しく作成された ODCR-2 シナリオ 2: 外部パートナーと共有する ODCR の管理（他の AWS アカウントと共有されるキャパシティ予約） ODCR を外部パートナーの AWS アカウントと共有する必要があるシナリオとして、以下の条件を満たす ODCR-1 を考えてみます。 全体キャパシティが 10 個の c5.2xlarge インスタンス 現在チームとパートナーが使用しているインスタンスは 8 個 未使用のインスタンスは 2 個 図 9: 他の AWS アカウントと共有するキャパシティ分割前の ODCR-1 この場合、選択肢は限定されます。ODCR-1 はパートナーの AWS アカウントと共有されるため、未使用のキャパシティ（最大 2 つのインスタンス）のみを分割できます。キャパシティ分割後、新しく作成された ODCR-2 は社内の AWS アカウントに残り、他の AWS アカウントと共有されることはありません。これにより、パートナーが実行中のワークロードへの中断を防ぎながら、キャパシティ管理の柔軟性を確保できます。 図 10: キャパシティ分割により他の AWS アカウントと共有される ODCR-1 と共有されない ODCR-2 これらのシナリオは、社内環境および外部パートナーとの共有環境の両方におけるキャパシティ管理に関して重要なものです。キャパシティの分割や変更を計画する前に、ODCR の共有状況を慎重に検討し、社内チームと外部パートナーの両方にとって円滑な運用を確保する必要があります。 キャパシティ移動に関する特別な考慮事項 キャパシティ移動を行うと、利用可能な（または余剰の）キャパシティを ODCR 間で再配分できます。ただし、場合によっては、この機能を使用して使用済みインスタンスを ODCR 間で移動することもできます。この機能は、部分的に使用されている ODCR を 1 つに統合して追跡と管理を容易にしたい場合に特に役立ちます。 未使用キャパシティの移動に関する考慮事項 に加えて、使用済みキャパシティの移動には以下の考慮事項があります。 移動元の ODCR と移動先の ODCR はどちらもインスタンスの適格性をオープンとして利用可能でアクティブ状態である キャパシティ予約内で実行されているインスタンスはインスタンスの適格性をオープンとして利用可能である 移動元の ODCR と移動先の ODCR はどちらも同じ AWS アカウントが所有する 移動元の ODCR と移動先の ODCR は共有可能だが、使用済みインスタンスを移動する際に同じアカウントリストを使用する必要がある。また、同じアカウントへ共有するための条件は、ODCR の未使用部分には適用されない 移動するインスタンス数を指定すると、デフォルトでは未使用キャパシティが最初に移動され、次に対象となる実行中のインスタンス（予約で使用されているキャパシティ）が移動されます。 次のセクションでは、この機能が使用できる場面と使用できない場面を説明します。 シナリオ 1: 移動元と移動先の ODCR を他のアカウントと共有していない（チーム内でのキャパシティ移動） 同じ AWS アカウント（アカウント A）を使用して社内チーム間でキャパシティを管理する場合、プロセスは明確です。例えば、ML チームのリソースを統合するシナリオとして、以下の条件を満たす ODCR-1 と ODCR-2 を考えてみます。 ODCR-1（ML チーム A）：合計キャパシティ 10 個のうち、8 個は使用中で 2 個は未使用（インスタンスの適格性はすべてオープン） ODCR-2（ML チーム B）：合計キャパシティ 5 個のすべてが使用中（インスタンスの適格性はすべてオープン） 図 11: キャパシティ移動前の ODCR-1 と ODCR-2（どちらも同じ AWS アカウントで共有なし） 両方の ODCR は同じアカウントに属しており、外部と共有されておらず、インスタンスの適格性はオープンです。そのため、ODCR-1 から ODCR-2 にすべてのキャパシティを自由に移動でき、統合 DevOps チーム向けに 15 個のインスタンスからなる統合プールを作成できます。 図 12: ODCR-1 からキャパシティが移動され、合計キャパシティが 15 になった ODCR-2（2 個は未使用） シナリオ 2: 移動元と移動先の ODCR が同じアカウントで共有される（外部パートナーとのコラボレーション） ML チーム（ODCR-1）が外部の AI 研究パートナー（アカウント B）と連携するシナリオとして、以下の条件を満たす ODCR-1 と ODCR-2 を考えてみます。 ODCR-1: 合計キャパシティ 10 個（8 個が使用済み、2 個が未使用）のインスタンスの適格性はすべてオープンであり、AWS RAM を通じて研究パートナーと共有 ODCR-2: 社内分析チーム用の合計キャパシティ 5 個（すべて使用済み）のインスタンスの適格性はすべてオープン 図 13: キャパシティ移動前の ODCR-1 と ODCR-2（ODCR-1 は他の AWS アカウントと共有） 分析チームにさらに多くのキャパシティが必要になった場合、他の 8 個は外部パートナーとのコラボレーションで使用されているため、未使用のインスタンス 2 個だけを ODCR-1 から ODCR-2 に移動できます。 図 14: ODCR-1 の未使用キャパシティのみが移動されて拡張された ODCR-2 シナリオ 3: 異なるアカウントで共有される移動元 ODCR と移動先 ODCR（複数の外部パートナーが参加するプロジェクト） さまざまなパートナー契約にわたるキャパシティの管理を伴うこのシナリオでは、次のようになります。 ODCR-1: データベースパートナー（アカウント B）と共有される全体キャパシティ 10 個のインスタンス（使用済み 8 個、未使用 2 個） ODCR-2: セキュリティパートナー（アカウント C）と共有される全体キャパシティ 5 個のインスタンス（すべて使用済み） 図 15: 異なる AWS アカウントで共有される ODCR-1 と ODCR-2 パートナー契約が異なる、つまり ODCR が他のアカウントと共有されているため、未使用の 2 つのキャパシティを ODCR-1 から ODCR-2 にのみ移動できます。これにより、データベースパートナーのワークロードに影響が出ることはありません。 図 16: 共有されたキャパシティ予約により、ODCR-1 の未使用キャパシティが移動された ODCR-2 これらのシナリオから、マルチアカウント環境におけるキャパシティ管理に関する貴重な教訓を得ることができます。柔軟性とパートナーのコミットメントのバランスを取った包括的な共有戦略を策定することで、強固なパートナー関係を維持しながらリソース使用率を最適化できます。 まとめ AWS の新しい ODCR 機能（分割、移動、変更）は、クラウドキャパシティ管理において大きな進歩となりました。これらの機能は、組織におけるコンピューティングリソースの運用方法を変革し、より効率的な運用とコスト管理を実現します。キャパシティ予約を動的に調整・共有できる機能により、重要なワークロードに必要な安定性を維持しながら、必要な柔軟性が得られます。 クラウドインフラストラクチャが進化を続ける中、これらの機能により、複雑なクラウド環境の管理で直面する現実的な課題へ対応できるようになりました。AWS インフラストラクチャの最適化に向けて、新しい ODCR 機能はキャパシティ管理とリソース利用を向上させる強力なツールとなります。 これらの機能への理解を深めていただくために、実装用の API を含む GitHub リポジトリを作成しました。詳細については、キャパシティ予約の ドキュメント をご覧ください。ご質問やご意見がございましたら、コメント欄にご記入いただくか、AWS サポートまでお気軽にお問い合わせください。 翻訳はソリューションアーキテクトの 阿部 純一郎 が担当しました。

本記事は、2025 年 7 月 17 日に公開された Automate installing AWS Systems Manager agent on unmanaged Amazon EC2 nodes を翻訳したものです。 大規模な AWS リソースのフリート（訳者注: EC2 インスタンス群）管理は困難な課題です。組織は、タスクの自動化、インベントリの収集、インスタンスのパッチ適用、セキュリティコンプライアンスの維持のために、複数のソリューションに依存しています。インバウンドポートを開いたり SSH キーを管理したりせずにインスタンスにアクセスしたいと思うこともあるでしょう。 AWS Systems Manager (SSM) は、これらすべてのニーズを大規模にサポートする一元管理ソリューションとして機能することで、この複雑さを簡素化します。 Systems Manager の機能を使用するには、次の 3 要件を満たす必要があります: インスタンスに Systems Manager エージェント ( SSM エージェント ) がインストールされている Systems Manager に必要な インスタンスのアクセス許可が設定されている AWS Systems Manager エンドポイント へのネットワーク接続がある Systems Manager の統合コンソール を使用すると、組織内のすべてのノードに対してインスタンスのアクセス許可を設定および付与できます。 診断と修復 機能は、管理されていない AWS ノードを特定し、ネットワーク関連の問題を解決するのに役立ちます。これらの問題には、セキュリティグループの設定ミスや、 Amazon Virtual Private Cloud (Amazon VPC) DNS（訳者注: DNS ホスト名と DNS 解決のこと）の無効化が含まれます。 AWS が提供する多くの Amazon Machine Image (AMI) には Systems Manager エージェントがプリインストールされています が、カスタム AMI または古い AMI はエージェントのインストールが必要になる場合があります。大規模なフリートを管理する組織では、複数のサーバーとアカウントにわたって SSM エージェントを手動でインストールすると、運用上の負担が生じます。 このブログでは、既存の Amazon EC2 インスタンスに SSM エージェントをインストールする自動化ソリューションを紹介します。このソリューションは、複数のアカウントやリージョンに分散したノードのフリートに対して、SSM エージェントのインストールを効率化するように設計されています。これにより、AWS Organization 全体で Systems Manager の管理機能を素早く導入できます。 前提条件 ノードは以下の前提条件を満たす必要があります。: サポートされているオペレーティングシステム : Windows Server 2016-2025 Amazon Linux 2/2023 RHEL/CentOS 7.x-10.x Ubuntu 18.04-24.04 SUSE Linux Enterprise 15.x Windows ノード用の EC2Launch v2 エージェント Linux ノード用の Cloud-init SSM エージェントのインストールファイルのダウンロードおよびインストール後の実行ログのアップロードには、 Amazon S3 (s3.amazonaws.com) へのネットワーク接続が必要です。 インターネットゲートウェイ 、 NAT ゲートウェイ 、プライベートサブネットの場合は、 S3 ゲートウェイエンドポイント を使用して接続できます。 Linux ベースのノードでは、SSM エージェントソフトウェアをダウンロードし、ログをアップロードするために、unzip、curl、awscli パッケージが必要です。これらのパッケージがない場合、自動的にシステムのパッケージリポジトリからインストールを試みます。その際、インストール中にインターネットアクセスが必要です。 統合コンソールをセットアップ済みの場合は、セットアップ時に登録した Systems Manager の委任管理者 アカウントを使用してください。 統合コンソールをセットアップしていない場合は、組織の管理アカウントまたは CloudFormation StackSets の委任管理者 アカウントを使用してください。 重要な注意事項 このソリューションは、ユーザーデータを使用して SSM エージェントをインストールし、プロセス中にノードの停止と起動を要求します。これにより、 一時ストレージ がクリアされ、 非 Elastic IP アドレス が変更されることに注意が必要です。 これらのノード上で実行中のアプリケーションはすべて中断されます。予期しない中断を避けるため、この作業は予定されたメンテナンス期間中に実行することをお勧めします。 実行中、このソリューションはインスタンスから S3 へのログアップロードを可能にするために、一時的にインスタンスプロファイルをアタッチします。完了すると、この一時的なプロファイルは削除され、インスタンスは元の状態に戻ります。 ソリューションの概要 このソリューションでは、 AWS CloudFormation を使用した自動デプロイにより、必要なすべてのリソースをプロビジョニングします。これらのリソースには、S3 バケット、Systems Manager Automation ランブック、 IAM ロール 、 アクセス許可ポリシー 、 インスタンスプロファイル が含まれます。デプロイ後、 Systems Manager Automation ランブックをオンデマンドで実行して、SSM エージェントをインストールできます。インストールは、EC2 フリート全体またはタグを使用して特定のノードを対象にすることができます。 図 1 – SSM エージェントインストールのデプロイメントワークフローのアーキテクチャ図 デプロイメントワークフローは、連携して動作する 3 つの相互接続された Systems Manager Automation ランブックで構成されています。プロセスは、中心的な調整役として機能する SSMAgentInstall-Orchestrator ランブックを実行することから始まります。この Orchestrator ランブックは最初にすべての入力パラメーターを検証し、次に指定されたターゲットアカウントごとに SSMAgentInstall-Primary ランブックを呼び出します。 Primary ランブックは、ターゲットリージョンでの入力で指定されたノード (タグを使用するか、診断と修復の出力を使用するかのいずれか) に対して実行されます。各ターゲットノードに対して、SSMAgentInstall-Secondary ランブックを呼び出し、まずそのノードが既に SSM で管理されているかどうかを確認します。 ノードが管理されていない場合、Secondary ランブックは、順序付けられた手順で慎重にインストールプロセスを進めます。ノードの適格性 (Auto Scaling グループのメンバーシップ、ルートボリュームのタイプ、ノードの状態) 検証した後、停止と開始のサイクルを実行します。このサイクルでは、ユーザーデータを介して SSM エージェントのインストールスクリプトを注入し、必要な IAM アクセス許可を一時的にアタッチし、エージェントが正常にインストールされたことを確認します。 このプロセス全体を通して、実行ログが収集され、Central Account の S3 バケットに格納されます。最終的に、Orchestrator ランブックがすべての結果を集約して包括的な CSV レポートを作成し、組織全体の各インストール試行の成否を可視化します。 IAM アクセス許可について: インストール後、SSM エージェントがノードを AWS Systems Manager に登録します。そのため、ノードが Systems Manager エンドポイントに接続でき、必要な IAM アクセス許可 を持っていることを確認してください。 注意 : 統合コンソールを使用している場合、必要な IAM アクセス許可は自動的に設定されます。 ウォークスルー このソリューションをデプロイするには、 CloudFormation StackSets の委任管理者 アカウントを使用してください。 Step1: CloudFormation テンプレートを使用したリソースのデプロイ  CloudFormation テンプレート をダウンロードします。 適切な AWS アカウントにログインします。有効になっている場合は、統合コンソールのホームリージョンに切り替えます。 AWS CloudFormation のコンソールに移動し、ナビゲーションペインのスタックをクリックした後スタックページで、右上の スタックの作成 を選択し、 新しいリソースを使用 (標準) を選択します。 前提条件 – テンプレートの準備 で、 既存のテンプレートを選択 を選択します。 テンプレートソース で、 テンプレートファイルのアップロード を選択し、 ファイルの選択 を選択して、ステップ 1 でダウンロードしたテンプレートを選択します。 次へ を選択します。 スタック名を入力します (例: SSMAgentMultiAccountInstallation)。 パラメータセクションで、パラメータの値を指定します: DeploymentTargetsOUs では、ターゲットインスタンスが存在する組織単位 (OU) の ID を指定します。CloudFormation は、Stacksets を使用してこれらのアカウントとリージョンにリソースを作成しようとします。 OrganizationId では、 Organizations の組織 ID を入力します。 TargetRegions では、組織内のターゲットインスタンスが存在するリージョンを入力します。 スタックオプションの設定 ページで、必要に応じてタグを適用します。 機能セクションで、 AWS CloudFormation によって IAM リソースがカスタム名で作成される場合があることを承認します。 を選択し、 次へ を選択します。 確認して作成ページ で 送信 を選択します。 図 2 – AWS CloudFormation コンソール – スタックページ Step2: Automation ランブックの実行 CloudFormation テンプレートのデプロイが完了したら、同じリージョンで Systems Manager コンソールを開きます。 ナビゲーションペインで 変更管理ツールカテゴリの自動化 を選択し、 Execute runbook を選択します。 Owned by me タブで、 SSMAgentInstall-Orchestrator を選択し、 Next を選択します。 Input parameters セクションで、必要な入力を指定します: AutomationAssumeRole に、SSMAgentInstall-MAMR-AutomationAdministrationRole を選択します UploadLogsToS3Bucket に、ログ用 S3 バケット ssm-agent-install-automation-logs-<アカウント ID> を選択します タグを使ってインスタンスをターゲットにする場合は、以下を指定します : TargetAccounts – アンマネージドインスタンスが実行されているアカウント ID または OU を入力します。 TargetRegions – アンマネージドインスタンスを含むリージョンを入力します。 TargetTagKey – ターゲットのタグキーを tag: として入力します (すべてのインスタンスをターゲットにする場合は InstanceIds を使用)。 TargetTagValue – ターゲットのタグ値を入力します (すべてのインスタンスをターゲットにする場合は、InstanceIds と共に * を使用)。 あるいは、以前に Systems Manager 統合コンソールで診断を実行した場合は、 診断と修復 の出力を使用してCSV からアンマネージドインスタンスを取得できます: ナビゲーションペインで 診断および是正 を選択します。 View executions を選択します。 実行を選択し、 Output セクションを展開します。 AggregateOutput.ExportObjectUri から S3 パスをコピーします。 Execute を選択します。 完了すると、 S3 バケットに集約レポートの CSV ファイルが作成され、出力サマリーにファイルパスを表示します。 図 3 – AWS Systems Manager – オートメーション Output レポート CSV ファイルには、インスタンスごとの詳細と実行ログが含まれています: 図 4 – インスタンスの詳細 CSV レポート このソリューションは、CloudFormation StackSets を使用して必要なリソースを複数の AWS アカウントにデプロイし、その後 Systems Manager Automation ランブックを実行して SSM エージェントをインストールします。完了すると、S3 にインスタンスレベルの詳細と実行ログを含む包括的な CSV レポートを生成し、組織全体のデプロイ状況を可視化します。上記 Automation ランブックを使用した後に SSM エージェントがインストールされていない場合は、 ベストプラクティスとして紹介されている方法 のいずれかを使用するか、 手動インストール に切り替えることができます。 クリーンアップ ソリューションが不要になった場合は、プロビジョニングした AWS リソースを削除することを忘れないでください。これにより、継続的なコストを回避できます。クリーンアップするには:  AWS CloudFormation コンソールに移動します。 このソリューションで作成したスタックを選択します。 削除 を選択し、確認画面が表示されたら削除をクリックします。 削除プロセスでは、CloudFormation テンプレートと Automation ランブックの両方で作成されたすべてのリソース (S3 バケット、ログファイル、関連する IAM ロールとポリシー、その他の依存リソースなど) を削除します。 まとめ このAWS Systems Manager のエージェントインストールの自動化ソリューションは、複雑な手動プロセスを効率的な運用に変革することを目的としています。手動でのエージェントインストールの手間を軽減することで、組織が Systems Manager のポテンシャルを最大限に活用できるよう設計されています。組織は AWS 基盤の運用の効率化、セキュリティコンプライアンスの確保、自動化された管理を実現できます。 EC2インスタンスに SSM エージェントがインストールされたら、AWS Systems Manager の機能を深く活用してください。Patch Manager、Session Manager、Parameter Store、Automation などの機能を活用すると、AWS 運用をさらに強化できます。 自動パッチ適用を実装する : Patch Manager を使用して、EC2 インスタンスに定期的な自動パッチ適用スケジュールを設定し、システムを常に最新で安全な状態に維持します。 Session Manager で セキュリティを強化する : SSH アクセスを Session Manager に置き換え、インバウンドポートを開く必要なく、安全で監査可能なインスタンスアクセスを実現します。 Parameter Store による設定の効率化 : 構成データ、シークレット、その他の運用パラメータを Parameter Store に安全に保存します。 ここで立ち止まらず、 AWS Systems Managerのさまざまな機能 を活用しましょう。 自動パッチ管理からセキュアなリモートアクセス、パラメータストアからメンテナンスウィンドウまで、Systems Manager には多くの機能があります。これらを活用することで、AWS 基盤の管理を効率化し、運用の効率性を高めることができます。 Ali Alzand Ali は、Amazon Web Services のMicrosoft Specialist Solutions Architectです。Ali は、グローバルな顧客が Microsoft のワークロードをクラウドに移行、モダナイズ、最適化することを支援しています。Aliは、Systems Manager、Amazon EC2 Windows、EC2 Image Builder などの AWS サービスを活用したクラウド運用に特化しています。仕事以外では、アウトドアを探索したり、週末にグリルで友人とバーベキューを楽しんだり、さまざまな料理を味わうことを楽しんでいます。 Justin Thomas Justin Thomas は、AWS Premium Support のシニアクラウドサポートエンジニアです。Justin は、AWS Systems Manager、Linux、シェルスクリプティングに特に長けており、顧客のクラウドインフラストラクチャの移行、最適化、ナビゲーションに関する技術的なガイダンスを提供することに強い関心を持っています。仕事以外では、友人や家族と過ごす時間を大切にし、新しい料理を試したり映画を観たりするのが好きです。 翻訳は Partner Sales Solutions Architect 福井 敦が担当しました。

本記事は 2025 年 10 月 9 日に公開された Keerthi Sreenivas による “ How I stopped worrying about ReadMe files ” を翻訳したものです。 多くの開発者と同じように、私もこんな経験があります。：深夜 2 時に素晴らしい新機能をプッシュし、ビルドが通ってデプロイが成功したときの達成感。ところが 3 週間後に、新しいチームメンバーが私の古い README を見ながらオンボーディングしようとすると、そこに書かれているのはバージョン2.1の手順。一方で、実際に動いているのはバージョン3.2。セットアップコマンドは通らず、APIエンドポイントも変わっている。かつて頼りになっていたドキュメントが、今や足かせになっていたのです。 開発チームにとって、ドキュメントを常に最新に保つのは大きな課題です。変化の早い開発環境において、コードの変更のたびに README を手動で更新するのは現実的ではありません。その結果、ドキュメントはすぐに古くなり、信頼できない情報源となってしまいます。これが新しいメンバーのオンボーディングを遅らせ、開発者同士が質問のために作業を中断しなければならない事態を引き起こします。こうした絶え間ない中断はシニアエンジニアの負担を増やし、燃え尽き症候群や離職を加速させます。そして彼らがチームを離れると、重要な組織の知識も一緒に失われてしまうのです。 ドキュメントが自動的に「魔法のように」更新されるとしたら？ Kiro のエージェントフック がこの問題を解決します。エージェントフックとは、IDE 上で特定のイベントが発生したときに、あらかじめ定義されたエージェントのアクションを自動で実行するトリガーのことです。ドキュメントを手動で更新する代わりに、ファイルを保存した際に README を自動更新したり、エンドポイントの変更時に API ドキュメントを更新したり、コードの進化に応じて使用例を自動生成するようなフックを設定できます。 仕組み 1. エージェントフックを定義する： ユーザーは、ドキュメント要件をエージェントフックとして自然言語で定義できます。 プロンプトの例：「このリポジトリ内のすべての Python ファイル（.py）において、新しく追加された API や削除された古い API を検出し、OpenAPI の YAML を更新してください。存在しなくなった API は削除してください。また、.py ファイルの更新内容に基づいて ReadMe ファイルも更新してください。」 図 1 は、ユーザーがエージェントフックを作成している様子を示しています。 2. Kiro がエージェントフック設定を作成する： Kiro は、エージェントフック要件をタイトル、説明、イベント、監視するファイルパス、およびイベント発生時に Kiro に送信される指示を含んだ構成を自動作成します。詳細については、 フック定義のベストプラクティス をご参照ください。 この場合では、ステップ 1 のプロンプト例に基づいて、以下の構成（図 2）が作成されました。Kiro はタイトルを「API Documentation Sync」として構成を生成し、イベントを「File Saved」（他の フックタイプ も利用可能）として設定し、監視するパスをリポジトリ内のすべての .py ファイルに設定しました。エージェントフックの指示も、エージェントフック作成時にユーザーが提供した初期プロンプトに基づいて生成されます。 エージェントフック作成 エージェントフックの作成（ステップ 1 と 2 を表示） エージェントフックが作成されると、json 設定が .kiro/hooks フォルダに .hook ファイルとして保存されることがわかります。私の場合、図 3 の以下の設定が保存されます。エージェントフックの設定は、UI または生成された .hook ファイルのいずれかの方法で変更できます。 エージェントフック作成後に .kiro/hook/api-documentation-sync.kiro.hook に保存される設定： { "enabled": true, "name": "API Documentation Sync", "description": "Watches for changes in Python files to detect new or removed API's, the nupdates OpenAPI YAML documentation and README files accordingly", "version": "1", "when": { "type": "fileEdited", "patterns": [ "**/*.py" ] }, "then": { "type": "askAgent", "prompt": "Analyze the changed Python files to identify any new API endpoints, modified endpoints, or removed endpoints. Then: 1. Scan all Python files in the repository to build a complete inventory of current API endpoints 2. Compare with existing OpenAPI YAML documentation to identify: - New APIs that need to be added - Removed APIs that need to be deleted - Modified APIs that need updates 3. Update the OpenAPI YAML file with the detected changes 4. Update README.md and any other relevant documentation files to reflect the API changes 5. Provide a summary of what APIs were added, modified, or removed Focus on Flask routes, FastAPI endpoints, Django views, or any other Python web framework endpoints you find." } } 3. イベント発生時にフックがトリガーされる： ファイルの保存や作成などのイベントが発生すると、エージェントフックがトリガーされ、Kiro 内で新しいセッションがバックグラウンドで実行されます。開発者は、エージェントフックセッションを通じて提案された変更を受け入れたり修正したりできます。 フックをテストしてみましょう。 たとえば Kiro に「レコードを CSV として抽出する新しい API を追加するのを手伝って」と依頼したとします。Kiro は関連する .py ファイルに新しい API エンドポイントを追加します。バックグラウンドでは、「Execute hook: API Documentation Sync」という名前の別のセッションが作成され、Kiro が OpenAPI.yaml ファイルと README ファイルを更新します。Kiro は導入された変更を追跡するために CHANGELOG.md も生成します。 以下のビデオは、新しい API が「app.py」ファイルに追加されたときに API Documentation Sync フックがトリガーされる様子を示しています。 エージェントフックがトリガーされる エージェントフックで他に何ができるか？ README の自動化は強力ですが、それは始まりに過ぎません。エージェントフックは、コードが変更されたときに必要となるあらゆる日常的なタスクを自動化できます： コード最適化： 可読性、保守性、パフォーマンス最適化のためのコード最適化 言語ローカライゼーション ： ユーザー向けテキストコンテンツの自動翻訳生成 セキュリティドキュメント： 認証コードを変更したときのセキュリティ考慮事項の更新 アーキテクチャ図： サービス統合を変更したときのシステム図の更新 デプロイメントガイド： Docker 設定を変更したときのデプロイメント手順の更新 トラブルシューティングガイド： 例外処理コードに基づく一般的なエラーシナリオの生成 Figma デザインの検証 ： Figma MCP を使用して HTML/CSS ファイルが Figma デザインに従っているかを検証 その他にもたくさんあります。詳細なエージェントフック設定を含む 例のリスト をご覧ください。 最終的に重要なのは何か ドキュメントが自動で常に最新の状態に保たれるようになると、まるで魔法のような変化が起こります。：開発者は再びドキュメントを信頼するようになります。チームメンバー同士で作業を中断し合うことも減ります。開発者は集中状態を保ったままより多くの時間を過ごし、コード品質が向上し、機能のリリースも加速します。しかし、得られる恩恵は生産性指標にとどまりません。 新しい開発者のオンボーディングが速くなり、正確なドキュメントが組織にとっての「知の蓄積」なります。経験豊富な開発者がチームから去るとき、知識も一緒にドアから出て行くのではなく、彼らの在職中にエージェントフックによって常に最新の状態に保ってきたガイドの中に生き続けます。ドキュメントは 3 か月前の古いスナップショットではなく、コードベースの現在の状態をリアルタイムで反映した「生きた記録」であるべきです。Kiro のエージェントフックを活用すれば、ドキュメントがコードと並行して自動的に進化する間、あなたは優れたソフトウェアの構築に集中できます。 まとめ みなさんが Kiro でエージェントフックを設定し、ご自身のプロジェクトで実際に動作する様子を見るのをとても楽しみにしています。ぜひ Discord サーバー にて、ご意見やご感想をお聞かせください。このブログで話したドキュメントのユースケースから始めて、他のユースケースにもぜひチャレンジしてみてください。具体例は こちらのドキュメント でも紹介されています。 エージェントフック使用時の注意点 正規表現を利用するイベントトリガー（たとえば、 **/*.py ）でエージェントフックを実装する場合、パターンの適用範囲を慎重に検討することが重要です。あまりに広範囲なスコープになると、フックが実行されたときに過度の変更をもたらし、大規模プロジェクトにて意図しないドキュメント更新につながる可能性があります。効率性とドキュメントの明確性を維持するために、より具体的で対象を絞ったパターンマッチングを実装することをお勧めします。 エージェントフックのトラブルシューティング を参照してください。 翻訳はApp Dev Consultantの宇賀神が担当しました。

本稿は、2025 年 7 月 8 日に AWS Architecture Blog で公開された Migrate and modernize VMware workloads with AWS Transform for VMware を翻訳したものです。 2025年5月15日、AWS は画期的なソリューションである AWS Transform for VMware を発表しました。この革新的なサービスは、クラウド移行における長年の課題に正面から取り組み、AWS クラウドへの簡素化され効率的な移行の新たな時代を切り開きます。手作業を大幅に削減し、重要な VMware ワークロードの移行を加速することで、AWS Transform for VMware は、組織がクラウドへのアプローチを革新することを目指しています。 一般提供開始の発表 以来、AWS Transform for VMware は業界全体で注目を集めており、組織はその機能を活用して VMware のワークロードの移行とモダナイゼーションの取り組みを加速したいと考えています。この革新的な技術の詳細を掘り下げていく中で、 AWS Transform for VMware が移行を簡素化するだけでなく、クラウド導入とデジタルトランスフォーメーションの実態を再形成していることを明らかにします。 VMware 移行の課題 企業のワークロードをクラウドに移行することは、単なる技術的な課題ではありません。それは、ビジネス変革、精度、スピード、そして最小限の中断です。長年にわたる確立された運用プロセスは、文書化が不十分な構成、一貫性に欠けるセキュリティプラクティス、そして暗黙知への強い依存を伴う複雑な環境を作り出すことが多くあります。技術チームは、これらの変革プロジェクトを実行しながら、複雑なアプリケーションの依存関係を把握し、複数のステークホルダー間で調整を行い、ビジネスの継続性を維持しなければなりません。包括的な文書化の欠如と、システム間の依存関係に対する明確な理解の不足は、頻繁な移行期間の延長やプロジェクトリスクの増加につながります。さらに、進行中の運用と移行活動のバランスを取る必要性も課題です。適切な知識の移転を実現することは、これらの重要な取り組みにさらに複雑さを加えます。 ソリューションの概要 AWS Transform for VMware が、アプリケーションのディスカバリーを簡素化し、ネットワーク変換を自動化し、包括的なアーキテクチャを通じて複雑な移行をオーケストレーションする方法について、以下の図で見ていきましょう。 これらの機能がどのように連携するかを理解するために、アーキテクチャの各構成要素を調べてみましょう。 効率化されたディスカバリーとアセスメント この旅は、VMware 環境の徹底的なディスカバリーとアセスメントから始まります (1)。 AWS Transform for VMware (4) は複数のディスカバリー方法をサポートしています。1つの選択肢は、VMware インベントリ収集用の RVTools です。VMware NSX を実行しているお客様向けには、オプションで import/export 機能があります。さらに、 AWS Application Discovery Service は、移行のためのデータと依存関係を収集する、エージェントベースおよびエージェントレスの両方のディスカバリーオプション (2) を提供しています。 インベントリ検出 (5) は、ソース環境から重要なデータを収集し、AWS Migration Discovery アカウント (7) 内にある Amazon Simple Storage Service (Amazon S3) バケット (12) に安全に保存します。このデータは、十分な情報に基づいた移行計画の基礎となり、AWS Application Discovery Service (15) によって、AWS Migration Planning アカウントでさらに処理されます。AWS Transform は、これらのサービスと連携し、移行の進捗状況を追跡し、サーバーのインベントリと依存関係データを収集するための単一の場所を提供します。これは、アプリケーションの適切なグループ化とウェーブプランニングの成功に不可欠です。 インテリジェントなネットワーク変換とウェーブプランニング 環境を包括的に理解することで、AWS Transform for VMware は、次の重要なフェーズへ移行します。ネットワーク変換機能 (19) は、ターゲットネットワークインフラストラクチャを設定するために、 AWS CloudFormation テンプレート (13、26) の作成を自動化します。これらのテンプレートにより、クラウド環境がソース設定を密接に反映することを確実にし、移行のセットアップを簡素化します。 一方、ウェーブプランニング機能 (6) は、高度な グラフニューラルネットワーク を使用してアプリケーションの依存関係を分析し、最適な移行ウェーブを計画します。これにより、複雑なポートフォリオおよびアプリケーションの依存関係分析が最小限に抑えられ、移行準備の整ったウェーブプランが提供され、スムーズな移行を実現します。 強化されたセキュリティとコンプライアンス セキュリティは移行プロセス全体を通じて最優先事項です。 AWS Key Management Service (AWS KMS) (8、16、26) は、保存されたデータ、会話履歴、および成果物に対して堅牢な暗号化を提供します。デフォルトでは、AWS マネージドキーが使用され、追加の制御のために カスタマーマネージドキー を使用するオプションがあります。 AWS Organizations (9) は、複数の AWS アカウントにわたる一元管理を可能にし、 AWS CloudTrail (14、26) は、完全な監査証跡のために API アクティビティの取得と記録をします。アクセス制御は、 AWS Identity and Access Management (IAM) (26) を通じて管理され、AWS アカウント全体で一元化されたアクセス管理を提供します。 Amazon CloudWatch (10、26) は、管理アカウント内の AWS Transform サービスのアクティビティ、リソース利用状況、および運用メトリクスを継続的に監視し、移行プロセス全体を通じて完全な可視性と制御を提供します。 AWS Identity Center (11) は、移行に関与するすべての AWS アカウントに一元的なアクセス管理を提供することで、セキュリティをさらに強化します。 組織的な移行実行 移行を実行する時が来たら、AWS Transform はさまざまな AWS ツールとサービス (20) と連携し、エンドツーエンドの移行をオーケストレーションします。 AWS Application Migration Service (25) は、綿密に計画されたウェーブとグループ化に基づいて、ソース環境から AWS Migration Target Account (18) の Amazon Elastic Compute Cloud (Amazon EC2) インスタンス (21) にサーバーを複製します。 AWS レプリケーションエージェント (2) は、AWS Application Migration Service と連携し、効率的で信頼性の高いデータ転送を実現します。 Amazon Elastic Block Store (Amazon EBS) (21) は、移行された仮想マシンに必要なストレージを提供し、最適なパフォーマンスとスケーラビリティを実現します。 柔軟なネットワーク構成 AWS Transform for VMware は、異なる要件に対応する2つのネットワークモデルを提供します： ハブアンドスポークモデル – AWS Transit Gateway (23) は、Amazon Virtual Private Clouds (Amazon VPC) に共有 NAT ゲートウェイ を持つ中央ハブ VPC を介して接続します。このモデルは、一元管理および共有サービスに最適です。 分離モデル – 各 VPC は接続性が確立されていない状態で独立して動作します。このアプローチは、既存の AWS ネットワークインフラストラクチャを持つお客様向けに設計されており、新しい VPC を既存のネットワークトポロジーに手動で接続することを可能にします。 AWS Transform によって作成された VPC (22) は、オンプレミスのネットワークセグメントと一致し、シームレスな移行を提供します。NAT ゲートウェイ (24) は、プライベートサブネットにアウトバウンドインターネットアクセスを提供し、セキュリティを維持しながら必要な接続性を可能にします。ハブアンドスポークアーキテクチャでは、ハブ VPC の一元化 NAT ゲートウェイを複数のスポーク VPC に提供でき、コストの最適化と管理の簡素化を実現できます。分離された VPC 展開の場合、インターネットアクセスを必要とする各 VPC 内で専用の NAT ゲートウェイをプロビジョニングする必要があります。すべての場合において、NAT ゲートウェイを通る Egress トラフィックの流入を可能にするために、ルートテーブルを設定する必要があります 完全なセットアップ手順と要件については、 AWS Transform ユーザーガイド を参照してください。 追加の考慮事項 AWS Transform for VMware のディスカバリーワークスペースは、世界中でご利用いただけます (3)。サポートされているリージョンに関する最新の情報については、 AWS Services by Region (17) を参照してください。 移行プロセス全体を通じて、AWS Migration Discovery アカウントと AWS Migration Target アカウントの両方の主要な移行成果物は Amazon S3 バケット (12、26) に格納されます。これらには、インベントリデータ、依存関係マッピング、ウェーブプラン、アプリケーショングループ化、同様に Infrastructure as Code templates (AWS CloudFormation および AWS Cloud Development Kit)、およびウェーブごとの移行計画が含まれます。 お客様のメリット AWS Transform for VMware は、重要な利点を提供します： 手作業の手間を削減 – 自動化により人的ミスを最小限に抑え、貴重な IT リソースを解放します 精度の向上 – AI 主導の依存関係マッピングとウェーブプランを活用でき、最適な移行戦略を立てられます コラボレーションの強化 ― 一元管理とトラッキングにより、チーム間の連携が向上します コスト最適化 – インスタンスの適切なサイズと AWS の柔軟な価格設定モデルを活用して、即時かつ長期的なコスト削減を実現します 将来性 – AWS クラウドサービス上で、継続的なモダナイゼーションとイノベーションの機会を開きます 移行ソリューションを実装する際には、常に組織のセキュリティ要件、コンプライアンス義務、および AWS セキュリティベストプラクティクス を確認し、遵守してください。詳細なセキュリティガイダンスについては、 AWS セキュリティドキュメント と組織のセキュリティチームに相談してください。 料金 AWS Transform は、エージェント AI 機能により、VMware ワークロード向けの移行およびモダナイゼーションプロジェクトを加速します。現在、アセスメントと変換を含む主要機能を無料* で AWS のお客様へ提供しています。これにより、前払い費用なしで、移行とモダナイゼーションの道のりを迅速化できます。 *無料とは、AWS Transform サービス自体を指します。移行時に使用する AWS サービスおよびリソースには標準料金が適用されます。 まとめと次のステップ AWS Transform for VMware は、組織に VMware の移行とモダナイゼーションの複雑さを克服する力を与えます。包括的で自動化されたアプローチを提供することで、AWS クラウドへのより高速で信頼性の高い移行を可能にします。この新しいサービスは、変化する VMware の環境を自信を持って進むために必要なツールと機能を提供します。 探究したアーキテクチャは、AWS Transform for VMware が主要な課題にどのように取り組むか示しています： ディスカバリーおよびアセスメントプロセスを効率化 ネットワーク変換とインテリジェントウェーブプランニングの自動化 最小限の混乱で移行実行をオーケストレート 移行全体を通じたセキュリティとコンプライアンスの向上 一元管理と監視の提供 多様な要件に対応できる柔軟なネットワークオプションの提供 VMware 移行の旅を加速する準備はできましたか？ AWS Transform for VMware 製品ページにアクセスして、詳細をご確認いただき、今日から始めましょう。AWS Transform for VMware の インタラクティブデモ をご確認ください。VMware NSX 環境からネットワーク構成をエクスポートする場合は、 Import/Export for NSX によるネットワーク構成データのエクスポート も参照してください。私たち専門家チームが、お客様の移行およびモダナイゼーションの取り組みをガイドし、AWS クラウドの可能性を最大限に引き出すお手伝いをいたします。 著者について <!-- '"` --> Kiran Reid Kiran Reidは、AWS の Senior Generative AI および Machine Learning Specialist です。人工知能 (AI) 技術に関する専門知識を持つ Kiran は、AWS のパートナーやお客様と密接に連携し、AI を活用したワークロードの移行とモダナイゼーションを支援しています。 Ramu Akula Ramu Akula は、AWS の Principal Portfolio Manager および Telco Network Transformation specialist です。24 年以上にわたる IT 分野での経験を活かし、お客様の AWS へのワークロード移行およびモダナイジングを支援しています Patrick Kremer Patrick Kremer は、インフラの移行と現代化に特化した Senior Specialist Solutions Architect です。Patrick は 2022 年に AWS に入社し、20 年にわたる VMware の経験を活かし、お客様が AWS ソリューションに移行するのを支援してきました。彼は教育とブログ活動に情熱を持つ、認定 AWS Solutions Architect Professional です。 Mark Jaggers Mark Jaggers は、AWS の Outbound Product Management であり、クラウド移行およびディザスタリカバリーソリューションの市場開拓戦略を統括しています。Mark は、AWS Elastic Disaster Recovery と AWS Application Migration Service の両方のサービスチーム内で働き、お客様の大規模な IT インフラストラクチャのモダナイズを支援しています。 この投稿の翻訳は Solutions Architect の田澤が担当させていただきました。原文記事は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの杉山です。今週も 週刊AWS をお届けします。 2025 年 11 月 21 日に、株式会社LangGenius、株式会社リコー、アマゾンウェブサービスジャパン合同会社が登壇する「 企業の生成 AI 活用を加速する Dify Enterprise on AWS 〜セキュアなデータの活用とパートナー導入事例〜 」のイベントが開催されます。Dify Enterprise の新機能紹介、機密性の高いデータを保有する企業システムと Dify の安全な連携手法、Dify 導入パートナーによる事例紹介を通じて、エンタープライズでの安全かつ効果的な生成 AI 活用の知見を提供します。物理開催のため、事前にお申し込みの上、ご参加ください。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年10月6日週の主要なアップデート 10/6(月) 新しいコンピュート最適化 Amazon EC2 C8i および C8i-flex インスタンス AWS が新しいコンピュート最適化インスタンス C8i と C8i-flex の一般提供を開始しました。カスタム Intel Xeon 6 プロセッサを搭載し、従来の Intel ベースインスタンスと比較して最大 15% のコスト削減と 2.5 倍のメモリ帯域幅を実現します。Web アプリケーションでは最大 60%、AI 推論では最大 40% の性能向上を達成します。C8i-flex は Web サーバーやデータベース向けで、料金が少し安価で採用しやすいタイプです。C8i は、CPU 負荷の高いシステム向けのインスタンスタイプです。バージニア北部、オハイオ、オレゴン、スペインリージョンで利用可能です。詳細は こちらの Blog 記事をご参照ください。 Amazon EKS と Amazon EKS Distro が Kubernetes バージョン 1.34 をサポート開始 Amazon EKS と Amazon EKS Distro で Kubernetes version 1.34 のサポートが開始されました。Kubernetes 1.34 のアップデートの内容を一部取り上げると、コンテナイメージを取得する時のセキュリティが強化され、従来よりも安全にイメージの認証を行えるようになりました。また Pod 内の複数コンテナのリソース管理が簡素化され、より効率的なリソース配分が可能になります。既存クラスターは EKS コンソールや eksctl を使って簡単にアップグレード可能で、全ての AWS リージョンで利用できます。詳細は こちらのドキュメントをご参照ください。 10/7(火) AWS Service Quotas の自動 Quota 管理が一般提供開始 AWS Service Quotas で自動クォータ管理機能が一般提供開始となりました。AWS Service Quotas は各サービスの利用上限 (Quota) を一元管理するサービスです。新しいアップデートで、Quota 使用量を監視し、上限に近づくと事前に自動通知を受け取れるようになります。これまでは Quota 超過でサービスが停止するリスクがありましたが、事前通知により計画的な対応が可能です。通知は email や SMS、Slack などで受け取れます。 AWS Marketplace が Channel Partner Private Offers の日本消費税サポートを拡張 AWS Marketplace で日本の消費税サポートが拡張され、Channel Partner Private Offers (CPPO) にも対応しました。これまで、日本に住所を持つ ISV 会社 (SaaS 系) や Channel Partner が、日本のお客様に販売する場合、AWS Japan が 10% の消費税を徴収して、日本の税務当局に送金をしています。今回のアップデートで、Channel Partner Private Offers (CPPO) の取引においても、日本の消費税のサポートが拡大されました。CPPO とは、AWS パートナーが、AWS Marketplace に出品されている ISV製品・SaaS製品を、各ベンダーに代わって販売することができるプログラムです。詳細は こちらの FAQ をご参照ください。 AWS Marketplace が使用量ベースのプライベートオファーで新しい通貨をサポート AWS Marketplace で Usage ベース (従量課金制) のプライベートオファーが EUR、GBP、AUD、JPY の 4 つの新通貨に対応しました。これまで、通貨が USD のみ利用可能でしたが、利用しやすい通貨で取引できるようになりました。外国為替リスクを回避でき、売り手は現地通貨での受取が可能となり、利用者は調達プロセスが簡素化されます。詳細は こちらのドキュメントをご参照ください。 Amazon DocumentDB (MongoDB 互換) が、アジア太平洋地域とメキシコの 4 つの新しいリージョンで利用可能になりました Amazon DocumentDB (MongoDB 互換) が大阪リージョン、タイリージョン、マレーシアリージョン、メキシコ中央リージョンで新たに利用可能になりました。Amazon DocumentDB は、MongoDB 互換のフルマネージドデータベースとなり、今回のアップデートでリージョンが拡張し、システムを構成しやすくなりました。 10/8(水) Amazon Q Developer がサービス料金の理解とワークロードコストの見積もりを支援 Amazon Q Developer に新しく「価格・コスト見積もり」を行うための機能が追加されました。自然言語で AWS サービスの料金情報を取得できるため、人間が複数の価格ページを確認する手間を削減しやすくなりました。「RDS 拡張サポートの料金は?」「SNS で月 100 万通知の見積もりは?」といった質問を投げかけられます。AWS Management Console のチャットパネルから利用可能です。詳細は こちらのドキュメントをご参照ください。 新しい汎用 Amazon EC2 M8a インスタンス AWS で新しい汎用 EC2 インスタンス M8a の提供が開始されました。5世代目 AMD EPYC プロセッサを搭載し、従来の M7a インスタンスと比較して最大 30% の性能向上と 19% のコストパフォーマンス改善を実現しています。メモリ帯域幅も 45% 向上し、レイテンシに敏感なワークロードにも対応できるようになりました。金融アプリケーション、ゲーム、レンダリング、アプリケーションサーバーなどの高性能が求められる用途に最適で、オハイオ、オレゴン、スペインリージョンで利用可能です。詳細は こちらの Blog 記事をご参照ください。 10/9(木) Amazon DynamoDB が Internet Protocol version 6 (IPv6) をサポート開始 Amazon DynamoDB に VPC からアクセスする際に IPv6 がサポートしました。AWS PrivateLink Gateway および Interface エンドポイントを利用して VPC 内からアクセスする際に、IPv6 を利用した接続が可能となります。現在は米国リージョンで利用可能で、他のリージョンにも順次展開予定です。詳細は こちらのドキュメントをご参照ください。 Amazon Quick Suite の提供開始 従来あった Amazon QuickSight が Amazon Quick Suite に名前がリブランドされました。組織内の全従業員がデータに触れながら新しいインサイトを得やすくする方向性へのリブランドとなります。AI を活用した新機能を 3 つピックアップすると、Quick Research : インターネット上の情報と社内のデータをかけ合わせて質の高いレポートを作成、Quick Automate : 複雑な多段階のビジネスプロセスを自然処理で定義しながら自動的に処理、Quick Index : 組織内のデータを MCP、S3、Gmail、Sharepoint などと連携してナレッジべースとして提供、といった機能が含まれています。社内データと AI を連携する仕組みを、より統合された形で提供することで、社内でのインサイト発見に活用しやすくなります。最大 25 ユーザーまで 30 日間の無料トライアルが利用でき、バージニア北部、オレゴン、シドニー、アイルランドリージョンで提供中です。東京リージョンについては、Qucik Suite の UI に変更されていますが、新たな機能は現時点では利用できません。詳細は こちらの Blog 記事をご参照ください。 10/10(金) AWS Client VPN が macOS Tahoe をサポート開始 AWS Client VPN が MacOS Tahoe (バージョン 26.0) に対応しました。これまでも Mac 用の Client を提供していましたが、より最新の MacOS のバージョンに対応した形です。Client VPN ソフトウェアのバージョン 5.3.1 以降でサポートをしています。Client VPN は、リモートワークで自宅から会社のネットワークや AWS 環境に安全に接続したい場合に利用いただけるネットワーク系のサービスです。詳細は こちらのドキュメントをご参照ください。 それでは、また来週お会いしましょう！ 著者について 杉山 卓(Suguru Sugiyama) / @sugimount AWS Japan のソリューションアーキテクトとして、幅広い業種のお客様を担当しています。最近は生成 AI をお客様のビジネスに活かすためにアイデア出しやデモンストレーションなどを多く行っています。好きなサービスは仮想サーバーを意識しないもの全般です。趣味はゲームや楽器演奏です

2025 年 9 月に公開された AWS Black Belt オンラインセミナーの資料及び動画についてご案内させて頂きます。 動画はオンデマンドでご視聴いただけます。 また、過去の AWS Black Belt オンラインセミナーの資料及び動画は「 AWS Black Belt Online Seminar 一覧 」に一覧がございます。 YouTube の再生リストは「 AWS Black Belt Online Seminar の Playlist 」をご覧ください。 Reserved Instances Reserved Instances は、1 年または 3 年の期間で特定の使用量を契約するかわりに、オンデマンド料金と比較して低料金を実現する柔軟な料金モデルです。本セッションでは、Reserved Instances の概要、購入方法および購入計画などについて説明します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Reserved Instances の概要や購入方法を知りたい方 Reserved Instances の購入計画を立てたい方 データベースなどのワークロードのコスト最適化を促進したい方 本 BlackBelt で学習できること Reserved Instances の概要・購入方法について学んでいただけます 購入計画や購入後のモニタリングについても紹介します スピーカー 加須屋 悠己 テクニカルアカウントマネージャー Amazon Managed Grafana Amazon Managed Grafana は 拡張性、安全性、⾼可⽤性を備えたフルマネージドな Grafana 環境を提供する AWS サービスです。本セッションでは、Amazon Managed Grafana についてご紹介しております。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS 上でオープンソースを利⽤したオブザーバビリティに関⼼のある⽅ Grafana の運⽤に課題を持っている⽅ Amazon Managed Grafana に興味のある⽅ 本 BlackBelt で学習できること Amazon Managed Grafana の特徴や機能 Amazon Managed Grafana のユースケース スピーカー 辻林侑 ソリューションアーキテクト Amazon Cognito Amazon Cognito は、ウェブアプリケーションやモバイルアプリケーションにユーザー認証、認可、ユーザー管理機能を簡単に追加できる認証サービスです。複雑な認証システムの構築や運用が不要になることから、多くのお客様のアプリケーション開発で採用頂いています。本セッションでは、Amazon Cognito を使用するユースケースや機能についてご紹介します。 資料（ PDF ）&nbsp; 対象者 アイデンティティ管理に AWS の利⽤を検討している⽅ Amazon Cognito でできることを理解されたい⽅ Cognito ユーザープールと ID プールの違いや使い⽅を理解されたい⽅ 本 BlackBelt で学習できること アイデンティティ管理における Amazon Cognito の使い方を学習いただけます Amazon Cognito ユーザープールと ID プールの違いについて理解を深めていただけます Amazon Cognito の機能や認証フローを習得いただけます スピーカー 鈴⽊ 理希也／海江⽥ 祥汰／吉⽥ 健⼈ クラウドサポートエンジニア Amazon GuardDuty Runtime Monitoring 編 Amazon GuardDuty の保護プランである Runtime Monitoring は EC2、ECS、EKS のワークロード内部の異常な動作をモニタリングし、セキュリティ脅威を検知できます。本セミナーでは Amazon GuardDuty Runtime Monitoring の概要と開始方法および検知例について解説します。 資料（ PDF ） | 動画（ YouTube ） 対象者 AWS ワークロード上のセキュリティ強化をご検討中の方 Amazon GuardDuty Runtime Monitoring の機能について知りたい方 Amazon GuardDuty Runtime Monitoring の開始方法や検出例について知りたい方 本 BlackBelt で学習できること ランタイムモニタリングをおすすめする理由 Amazon GuardDuty Runtime Monitoring の概要 Amazon GuardDuty Runtime Monitoring の開始方法 Amazon GuardDuty Runtime Monitoring による脅威検出の例 スピーカー 坂下 拓弥 クラウドサポートエンジニア Amazon Connect Global Resiliency Amazon Connect は東京リージョンで複数の要素により信頼性を高めていますが、地域的な災害や障害が発生した場合など、より高い要件に対応することが必要なお客様のために大阪リージョンを利用した Amazon Connect Global Resiliency によって事業継続計画にも対応できるようになりました。本セッションは Amazon Connect が備える信頼性を改めて解説し、Amazon Connect Global Resiliency で実現可能になることや注意事項について紹介致します。 資料（ PDF ） | 動画（ YouTube ） 対象者 Amazon Connect が備えている信頼性を理解したい方 Amazon Connect における BCP の設計に関心のある方 Amazon Connect Global Resiliency の具体的な機能が知りたい方 本 BlackBelt で学習できること Amazon Connect が備える信頼性について Amazon Connect Global Resiliency の機能、動作、および運用上の注意事項 Amazon Connect Global Resiliency の具体的な切替方法 スピーカー 清水 幸典 Amazon Connect スペシャリスト ソリューションアーキテクト

本記事は米国時間 10 月 13 日に公開された AWS エージェンティック AI 担当バイスプレジデント　スワミ・シバスブラマニアン（Swami Sivasubramanian）の署名ブログ「 Make agents a reality with Amazon Bedrock AgentCore: Now generally available 」の日本語抄訳版です。 AIエージェントをプロトタイプから、セキュリティ、スケーラビリティ、信頼性を備えた本番環境へ 2006年に AWS を立ち上げた時、私たちはクラウドコンピューティングが組織のテクノロジーを構築し、スケールさせる方法を変革すると信じていました。現在、AI エージェントについても同様の転換点に立っています。私たちは、数十億もの AI エージェントが協働し、日常業務から複雑なビジネスプロセスまであらゆるものを変革する世界を思い描いています。しかし、これを現実のものとするには、フレームワークやローコードの開発者向けツール以上のものが必要です。企業がビジネスの基盤として信頼できるAIエージェントには、エンタープライズグレードの運用基盤が必要です。その基盤は、セキュアで信頼性が高く、スケーラブルで、AI エージェントの非決定的な性質を考慮して構築されている必要があります。AWS はミッションクリティカルなシステム構築支援の経験を活かし、多様な組織が自信を持ってエージェンティックシステムを本番環境へ移行できる包括的な基盤を Amazon Bedrock AgentCore を通じて提供します。 AgentCore: AIエージェントを迅速に本番環境へ AgentCore の一般提供開始により、すべての開発者がAIエージェントをパイロット環境からフルスケールの本番環境へ迅速に移行することが可能になります。AgentCore は AI エージェントの構築、デプロイ、運用に必要な基盤を提供します。エージェントに複雑なワークフローを処理するためのツール、メモリ、データを簡単に取り入れることが可能です。数行のコードを書くだけで、現在利用可能な最も安全でスケーラブルなランタイム環境の一つの選択肢にAIエージェントをデプロイすることが可能です。また、エンタープライズグレードでの展開に必要なコントロールとアクセス管理を備えてこれらのエージェントを運用できます。これらすべてをインフラ管理なしで実行でき、任意のモデルやエージェントフレームワークを使って簡単に開始できます。 AgentCore SDK は、多様な業界のあらゆる規模のお客様に既に100万回以上ダウンロードされています。初期のお客様には、Clearwater Analytics (CWAN)、Cox Automotive、Druva、Ericsson、Experian、Heroku、National Australia Bank、ソニーグループ、Thomson Reutersなど、その他多くのお客様が含まれます。AgentCore はまた、Accenture、Cisco、Deloitte、SalesforceなどのAWSパートナーによってサポートされ、すでに変革を実現する結果をもたらし始めています。 AgentCore: 包括的なAIエージェント基盤 AI エージェントの構築は簡単ではありません。例えば、ID プロバイダーとの統合方法、メモリと可観測性（オブザーバビリティ）の実現方法、ツールとの統合方法などを理解する必要があります。私たちのAIエージェント基盤は、構築からデプロイ、運用までのAI エージェント開発ライフサイクル全体にわたるフルマネージドサービスを提供します。任意のモデルやフレームワークを組み合わせることができ、エンタープライズグレードのインフラストラクチャとツールにアクセスしながら最大限の柔軟性を提供します。その主要な機能を見てみましょう。 自由自在にAIエージェント構築： AI エージェント分野は急速に進化しており、新しいフレームワーク、モデル、プロトコルがほぼ毎週のように登場しています。AgentCore のサービス群はモジュールとして提供されているため、必要に応じて組み合わて利用することも、単独で利用することも可能であり、開発者はAIエージェントを望む方法で構築できます。組織としては、チームが必要とするAgentCore のサービスを選択しながら、好みのフレームワーク（CrewAI、Google ADK、LangGraph、LlamaIndex、OpenAI Agents SDK、Strands Agentsを含む）とモデル（Amazon Bedrockで利用可能なモデルや、OpenAIやGeminiなどBedrock以外で利用可能なモデルを含む）を使用できるため、望む方法で自由に構築できます。 価値を生み出すAIエージェントのための基盤： AI エージェントは具体的なアクションの実行で価値を生み出します。例えば、コードの記述と実行、企業システムへの接続、ウェブサイトのナビゲーションなどです。AgentCoreはこれらに不可欠なサービスを提供します。AgentCore Code Interpreter により、AIエージェントは分離された環境でコードを安全に生成・実行でき、AgentCore Browserにより、AIエージェントはウェブアプリケーションを大規模に操作することができるようになります。また、AgentCore Gateway は既存の API や AWS Lambda 関数をエージェント互換のツールに変換し、既存の MCP サーバーに接続し、必要不可欠なサードパーティのビジネスツールやサービス（JiraやAsana、Zendeskなど）とのシームレスな統合を提供します。この統一されたアクセスポイントにより、企業システム全体にわたる安全な統合が可能になります。AgentCore Identity を使用すると、エージェントはOAuth 標準を使用した適切な認証と認可によって、これらのツール全体に安全にアクセスし、操作できます。 インテリジェントなメモリを備えたコンテキスト対応AIエージェント： AIエージェントが真に効果的であるためには、時間の経過とともに対話からコンテキストを維持し、学習する必要があります。例えば、企業向けソフトウェアを検討するお客様を支援する営業サポートAIエージェントの例を考えてみましょう。複数回にわたるお客様との会話から、お客様の業界、予算上の制約、技術要件を記憶し、同じ質問を繰り返すことを避けながら、お客様にパーソナライズされた提案を行う必要があります。同様に、複雑な技術的トラブルシューティングを支援する例では、AI エージェントは以前のデバッグ試行の結果を思い出し、より的を絞ったソリューションを提供しなければなりません。AgentCore Memory は、開発者が複雑なメモリインフラストラクチャを管理することなく、このような高度なコンテキスト対応エクスペリエンスの構築を支援し、AI エージェントがユーザーの好み、過去のやり取り、そして会話を豊かにする関連コンテキストの詳細な理解を構築・維持するのを支援します。 信頼できるエージェントのための包括的な可観測性： AI エージェントはリアルタイムで推論し、非決定的にアクションを実行します。そのため、開発者にはAIエージェントの推論とアクションに対して完全な可視性が必要です。AgentCore Observability は、リアルタイムダッシュボードと詳細な監査証跡を通じて包括的なモニタリングを提供します。組織はAIエージェントのすべてのアクションを追跡し、問題を迅速にデバッグし、パフォーマンスを継続的に最適化できます。AgentCore Observability は、メトリクス、ログ、トレースなどのテレメトリデータを収集してルーティングするための標準化されたプロトコルとツールを提供するオープンソースのオブザーバビリティフレームワークであるOpenTelemetry（OTEL）との互換性を提供しています。これにより、Dynatrace、Datadog、Arize Phoenix、LangSmith、Langfuseなどの既存のモニタリングツールと統合が可能です。 業界をリードする信頼性であらゆる規模に対応： 従来のアプリケーションとは異なり、AI エージェントのワークロード持続時間は本質的に予測不可能です。AgentCore Runtime はこうした変動性に対応するように設計されており、必要に応じてゼロから数千のセッションへと自動的にスケーリングし、長時間実行タスク向けに業界をリードする8時間のランタイムを提供します。 エンタープライズグレードのAIエージェントセキュリティ： AIエージェントはユーザーに代わって行動しながら、複数のシステムに安全にアクセスし、機密データを処理する必要があるため、堅牢なセキュリティと規制コンプライアンスの実現においては一切の妥協が許されません。AgentCore はAI エージェントが安全に運用できるよう、すべてのサービスにセキュリティを組み込んでいます。バーチャルプライベートクラウド（VPC）環境と AWS PrivateLink をサポートし、ネットワークトラフィックをプライベートで安全に保ちます。最も重要なことに、AgentCore Runtime は microVM 技術を通じて業界をリードするセキュリティを提供し、各AIエージェントのセッションに独自の分離されたコンピューティング環境を与え、データ漏洩を防止し、すべての相互作用の完全性を維持します。 AgentCoreでスピード、スケール、セキュリティを両立： AgentCore は、 Kiro や Cursor AI などの統合開発環境（IDE）で動作する MCP サーバーを通じて、本番環境対応の AI エージェントを簡単に構築できます。開始にはわずか数分しかかかりません。そして、これらは簡略化されたツールではありません。堅牢なセキュリティを維持しながら、ゼロから数千のセッションへと即座にスケールできる、フル機能の本番環境対応ソリューションです。つまり、お客様のチームは AI エージェントが実証済みの基盤上に構築されていることを理解した上で、アイデアからデプロイメントまで自信を持って迅速に進めることができます。 AIエージェントの価値を実現するお客様事例 Cohere Health の規制された医療環境から、Ericsson の複雑でテクニカルなシステム、そしてソニーグループのグローバル規模での変革まで、先進的な組織がAgentCoreを活用して業界を超えた次世代のAIイノベーションを推進しています。AI 時代に成功する組織は、未来を完璧に予測する組織ではなく、進化する柔軟性を維持しながら実証された基盤の上に構築する組織でしょう。AgentCore を基盤とすることで、AI エージェントの展開と運用のための専用サービスにアクセスできるだけでなく、グローバル規模でセキュリティを確保しながら、企業の変革を支援してきた約20年の経験を持つパートナーも得ることになるでしょう。 世界最大の広告会社 Publicis Groupe に所属するEpsilon が、AgentCore を使用して大手ブランドのキャンペーンをパーソナライズし、革新する様子を以下のビデオでご覧ください。同社の Intelligent Campaign Automation ソリューションは、複数のチャネルにわたるキャンペーン設計、オーディエンスターゲティング、リアルタイム最適化を自動化し、実行時間の短縮と顧客ターゲティング精度の向上を大規模に実現しています。 インテリジェントなワークフロー自動化による製造業の変革： Amazon Devices Operations &amp; Supply Chain チームは、AI エージェントを活用した製造アプローチの開発にAgentCoreを使用しています。この新しいアプローチの一環として、AIエージェントは製品仕様を使って協働し、手動プロセスを自動化します。あるAIエージェントは製品要件を読み取り、品質管理のための詳細なテスト手順を作成し、別のエージェントは製造ライン上のロボットが必要とするビジョンシステムをトレーニングします。その結果、従来はエンジニアリング時間に数日を要していたオブジェクト検出モデルの微調整が、高い精度で1時間以内に完了できるようになりました。この実証実験は、AI エージェントが初期製品要件から最終生産までの過程を効率化するスマートな製造へのビジョンの始まりに過ぎません。 AIエージェントによる医療判断の迅速化： 医療現場では、1分1秒が重要です。Cohere Health® は臨床インテリジェンス企業で、保険者（Payer）、医療機関（Provider）の連携を強化し、ケア前後の臨床的意思決定のスピードと正確性を向上させることに焦点を当てています。同社の臨床トレーニングを受けたAIは、患者ケアへのアクセスを加速し、患者のアウトカムを改善し、医療機関の管理負担を軽減し、ケア継続全体にわたって医療サービス提供におけるエコノミクスを改善します。 例えば、Cohere HealthはAgentCoreを利用して、医療保険における医療の必要性審査の精度と効率を最適化するAI搭載コパイロットであるCohere Review Resolve を構築しました。Cohere Review Resolve は、臨床記録、患者メモ、FAX などの構造化データと非構造化データの両方を分析し、要求された治療の医学的必要性を検証するための証拠を迅速に特定して表示します。このコパイロットは、医療保険の審査担当者に事前承認リクエストの審査に向けて必要な臨床コンテキストを提供し、審査担当者の質問にもインテリジェントに対応します。 Cohere Health は、高度に規制された医療業界においてエージェンティックAIを初めて本番環境でデプロイするためのエンタープライズグレードのインフラを求め、AgentCore を選択しました。AgentCore で利用可能な包括的な監査証跡、拡張セッションサポート、複数時間にわたる複雑なワークフローを通じて履歴を維持する機能は、Cohere Health のユースケースに不可欠となっています。 Cohere Health は、Review Resolve が今後レビュー時間を30～40％短縮し、重要な義務付けられた処理時間を満たすのに貢献するだろうと予想しています。より迅速な意思決定は、患者にとりケアへのアクセスを早め、治療への順守を増やし、結果を改善し、コストを削減します。Review Resolve はまた、医療保険が臨床的決定の正確性を約30％向上し、それによって医療費の削減と患者のアウトカム改善に貢献する見込みです。 通 信業界におけるAIエージェント — 複雑なシステムの簡素化： 通信技術における世界的リーダーであるEricssonは、AIエージェントのデプロイにおける課題に取り組むためにAgentCore を使用しています。Ericsson で、ビジネスエリアネットワークにおけるAIと先進テクノロジーを担当する責任者であるDag Lindbo 氏は次のように述べています。「Ericsson において、私たちの3G/4G/5G/6Gシステムは数百万行ものコードで構成され、数千の相互接続されたサブシステムに及んでいます。これは、国レベルの重要インフラストラクチャにおける数十年にわたるエンジニアリングイノベーションを示しています。AgentCore は、データと情報の重要な融合を実現し、実世界のR&amp;Dにおいて前例のない能力を持つAIエージェントを提供し、数万人規模の社員全体で二桁の価値創出につながるでしょう。また、AgentCore は任意のエージェントフレームワークを使用できるため、多くのチームとユースケースにわたって拡張する上で不可欠です」 エンターテインメント業界におけるエージェント活用： セキュリティ、オブザーバビリティとスケーラビリティを両立：世界有数のテクノロジー・エンターテインメント企業であるソニーグループでも、AgentCoreがインパクトを生み出しています。「Agentic AI は、これまでにないレベルでの業務の高度化と効率化を実現するために不可欠な技術です」とソニーグループ株式会社 D&amp;Tプラットフォーム AI Acceleration 部門 部門長の大場 正博氏は述べています。「一方で、エージェンティックAI の活用には、多くの技術的課題があることも事実です。Amazon Bedrock AgentCore を活用することで、グループ全体のAgentic AI Platform を構築し、エンタープライズレベルのセキュリティ、オブザーバビリティそしてスケーラビリティを実現し、さらにクロスプラットフォームでのシームレスな AI リソースへの接続を実現しました。Amazon Bedrock AgentCore を 私たちの AI エコシステムの中核に置くことで、膨大なAIを管理・共有する能力を獲得し、確信と安全性を持ってAIトランスフォーメーションを加速することができます」 AgentCore は現在、アジアパシフィック（ムンバイ）、アジアパシフィック（シンガポール）、アジアパシフィック（シドニー）、アジアパシフィック（東京）、ヨーロッパ（ダブリン）、ヨーロッパ（フランクフルト）、米国東部（バージニア北部）、米国東部（オハイオ）、米国西部（オレゴン）の9つの AWS リージョンで一般提供され、お客様の世界規模での展開をサポートしています。AgentCore上で動作するように予め設計・構築されたAIエージェントとツールを提供する AWS Marketplace を活用することで価値実現までの時間を加速することも可能です。 Amazon Bedrock AgentCoreをご利用の日本のお客様からのコメント （日本語抄訳版における追加記載、五十音順） 株式会社ウェザーニューズ　執行役員 テクノロジー・プロダクト責任者 出羽 秀章氏 ウェザーニューズでは、BtoC 向けの「お天気エージェント」やBtoB 向け SaaS サービスにおいて、AIエージェントの β 版をリリースし、天気に関連するデータやソリューションの提供を開始しています。正式リリース後により多くのユーザーに安心してご利用いただくためには、性能・セキュリティ・ガバナンス・スケーラビリティといった観点が不可欠です。今回、Amazon Bedrock AgentCore のマネージドサービスを活用することで、これらの課題解決に向けて大きく前進できると考えています。新たに提供されるフルマネージドなサービス群と共に、お客様へこれまで以上に大きなビジネス価値をお届けできることを楽しみにしています。 TIS株式会社 IT 基盤技術事業本部 IT基盤ビジネス事業部長　黒田 訓功氏 当社のお客様には、安全性とガバナンスを重視するエンタープライズ企業に加え、AI活用による成長を目指す中堅・中小企業まで、幅広い層が含まれます。Amazon Bedrock AgentCore によるアイデンティティ管理、セッション隔離、運用の透明性の確保は、そうしたお客様にとって“安心して業務を任せられる AI エージェント”の基盤となります。応答の質、対話の一貫性、サービスの稼働安定性が整うと、利用者にとって使いやすく、心地よい体験となります。そのような体験が信頼を育み、選ばれ続けるサービスにつながると考えています。Amazon Bedrock AgentCore があるからこそ、TIS はお客様から信頼される AI エージェントソリューションの提供者として、これからも期待に応え続けられると確信しています。 株式会社ディー・エヌ・エー ML Ops Engineer　外山 寛氏 弊社ディー・エヌ・エーでは AI オールインを掲げ全社で AI 活用を推進していきます。その際に大規模言語モデル（LLM）を業務で安全に活用するためにデータセキュリティに配慮したシステム設計が重要になってきます。 Amazon Bedrock AgentCore ではそのようなシステム設計を支援するための機能が提供されていると感じます。 今後のさらなるきめ細やかなデータセキュリティ機能の発展に期待しています。 株式会社野村総合研究所　AI 担当 経営役　生産革新センター　センター長　稲葉 貴彦氏 Amazon Bedrock AgentCore は、企業のデジタル変革を根本的に変える可能性を秘めています。多様なオープンソースフレームワークとの柔軟な連携や、独自の機能を提供する 7 つのサービスの選択肢、完全なセッション分離機能と最大 8 時間の長時間ワークロード対応により、より高度な業務での安定運用が期待できます。プレビュー版からの検証を経て、現在、社内外の複数プロジェクトで利活用を進めており、今後も検証を重ねながら、当社のお客様の競争優位性確保に貢献してまいります。 今すぐAgentCoreを始めましょう – aws.amazon.com/bedrock/agentcore/にアクセスして、エージェントの未来を構築し始めましょう！

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 来る 10/24 に AWS Japan AI Agent Day 2025 が開催されます。本日ご紹介するAmazon Quick Suite をはじめとして、 AWS でAgentを活用するための知見を学ぶことができます。ぜひ、 こちらの申し込みページ からご登録をお願いいたします。 先日 2つの新しいプランを追加した「 AWS ジャパン生成 AI 実用化推進プログラム 」も非常に多くの申し込みをいただいています。引き続き募集中ですのでよろしくお願いします。 それでは、10 月 6 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS生成AI国内事例ブログ: 株式会社情報戦略テクノロジー様、AIエージェント秘書「パイオにゃん」で情報探索業務を83%改善 株式会社情報戦略テクノロジー様は、IT コンサルティングやシステム開発を行う企業です。社員の情報探索業務の効率化とスキルアップという課題に対して、Amazon Bedrock を活用したAIエージェント秘書「パイオにゃん」を開発しました。その結果、情報探索業務を83%改善し、社員一人ひとりに寄り添いともに成長する仕組みを実現しています。さらに社員の成長の可視化にも成功し、組織全体の生産性向上に貢献しています。 AWS生成AI国内事例ブログ: 第一三共株式会社様、AIエージェント統合型創薬基盤の構築を開始 第一三共株式会社様は、製薬企業として次世代の創薬研究プロセスの実現に取り組んでいます。AWS と連携し、AIエージェントシステムを統合した創薬研究基盤の構築を開始しました。AI・クラウド・実験自動化技術を融合させることで、創薬研究プロセスの革新を目指しています。この取り組みにより、創薬の効率化と新薬開発の加速が期待されています。 ブログ記事「 ビジネスインテリジェンスの再解釈: Amazon QuickSight から Amazon Quick Suite への進化 」を公開 Amazon QuickSight が Amazon Quick Suite へと進化しました。この記事では、エージェンティックAIを搭載した新しいワークスペース機能について詳しく解説しています。ビジネスインテリジェンスの概念を再定義し、データ分析の新しい形を体験できる内容となっています。 ブログ記事「 Amazon Bedrockを活用したAWS サポート問い合わせ内容の自動集約ソリューションの実装 」を公開 AWS Support と Amazon Bedrock を組み合わせた、サポート問い合わせ内容の自動集約ソリューションの実装方法を紹介しています。生成AIを活用することで、サポート対応の効率を向上させる実践的な事例です。 ブログ記事「 Amazon Q Business ブラウザ拡張機能による組織の生産性向上 」を公開 Amazon Q Business のブラウザ拡張機能について詳しく解説しています。ブラウザから直接企業ナレッジにアクセスし、生成AIの支援を受けられる機能により、組織全体の生産性向上が期待できます。実際の使用方法と活用シーンを紹介しています。 ブログ記事「 AWS WAF で AI ボットを管理し、セキュリティを強化する方法 」を公開 生成AIボットの普及に伴い、ウェブサイトへのボットアクセス管理が重要になっています。この記事では、AWS WAF を使用して AI ボットを適切に管理し、セキュリティを強化する方法を解説しています。正規のAIボットと悪意のあるボットを区別する実践的な手法を紹介しています。 ブログ記事「 AWS re:Invent 2025 におけるクラウドガバナンスの必須ガイド 」を公開 AWS re:Invent 2025 で注目すべきクラウドガバナンス関連のセッションとトピックを紹介しています。生成AI時代におけるガバナンスのベストプラクティスについても触れられています。 ブログ記事「 [AWS Summit Japan 2025] 生成 AI を用いた自治体向けソリューションデモのご紹介 」を公開 AWS Summit Japan 2025 で展示された、生成AIを用いた自治体向けソリューションデモを紹介しています。公共セクターにおける生成AI活用の具体例を学べる貴重な機会です。 ブログ記事「 日本のヘルスケア・ライフサイエンス業界における戦略的ビジョン「Journey for 2030 データがつながる、価値を生む」を発表 」を公開 日本のヘルスケア・ライフサイエンス業界における AWS の戦略的ビジョン「Journey for 2030」を発表しました。データ連携による価値創出を目指す、業界の未来像を描いています。 ブログ記事「 ヘルスケア・ライフサイエンスの意思決定と業務の高度化を実現する HealthData x Agent を発表 」を公開 ヘルスケアとライフサイエンス分野向けの新しいソリューション「HealthData x Agent」を発表しました。AIエージェントを活用して医療データの分析と意思決定を支援し、業界の変革を加速させるソリューションです。この記事では、HealthData x Agent の機能と活用方法を詳しく解説しています。 ブログ記事「 生成AIで起こるSAP技術文書変革：Amazon BedrockでSAP Notesのナレッジ生成を加速 」を公開 SAP システムの技術ドキュメント作成に生成AIを活用する方法を紹介しています。Amazon Bedrock を使用して SAP Notes のナレッジ生成を自動化・高速化することで、ドキュメント作成の効率を大幅に向上させる事例を解説しています。 ブログ記事「 Amazon Bedrock での Claude Sonnet 4.5 のご紹介: Anthropic の最もインテリジェントなモデルで、コーディングや複雑なエージェントに最適 」を公開 Anthropic の最新モデル Claude Sonnet 4.5 が Amazon Bedrock で利用可能になりました。特にコーディングタスクと複雑なエージェント構築において優れた性能を発揮します。この記事では、Claude Sonnet 4.5 の特徴と活用方法、実際のユースケースを詳しく紹介しています。 サービスアップデート Amazon Q Developer がサービス価格の理解とワークロードコスト見積もりに対応 Amazon Q Developer に新機能が追加され、AWS サービスの価格を理解し、ワークロードのコスト見積もりを支援できるようになりました。開発者は自然言語で質問するだけで、使用予定のサービスのコスト情報を取得し、アーキテクチャ設計時のコスト最適化が容易になります。コスト意識の高い開発を支援する重要なアップデートです。 Amazon Quick Suite: エージェンティックAI搭載ワークスペースを発表 Amazon QuickSight が Amazon Quick Suite へと進化し、エージェンティックAIを搭載したワークスペース機能が追加されました。AIエージェントがデータ分析を支援し、ビジネスインサイトの発見を加速します。自然言語でのデータ探索、自動的なインサイト生成、インタラクティブなダッシュボード作成など、データ分析の新しい体験を提供します。 AWS Service Quotas で自動クォータ管理機能が一般提供開始 AWS Service Quotas に自動クォータ管理機能が一般提供開始されました。この機能により、サービスの使用状況を監視し、クォータ上限に近づいた際に自動的に引き上げリクエストを送信できるようになります。生成AIワークロードなど、急速にスケールするアプリケーションの運用において、クォータ制限によるサービス中断を防ぐことができます。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航&nbsp; (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近感動したものは帯広の豚丼です。

シニア GTM アナリティクススペシャリストソリューションアーキテクトの大薗です。 2025 年 7 月 15 日に「 Amazon SageMaker Roadshow –Japan 」を開催しました。本イベントでは、 Amazon SageMaker 開発チームが来日し、次世代の Amazon SageMaker を開発した理由やその機能紹介を行い、AWS Japan チームからデモやプレゼンテーションを通じて Amazon SageMaker の世界観を深堀りしました。さらに NX 情報システム株式会社様、キヤノンＩＴソリューションズ株式会社様、ソニーグループ株式会社様、株式会社 NTT データ様より SageMaker を含めたデータと AI の具体的な活用事例についてお話がありました。本ブログでは当日の各発表内容について紹介します。 次世代の Amazon SageMaker とは？ 次世代の Amazon SageMaker は、2024 年末に開催された re:Invent 2024 で発表された、すべてのデータに対する統合アクセスとともに、分析と AI のための統合エクスペリエンスを提供するサービスです。モデル開発、生成 AI、データ処理、SQL 分析のために使い慣れた AWS ツールを使用して、統合スタジオ環境からの迅速なコラボレーションと構築を実現します。 アジェンダ Welcome and Keynote Navigating Modern Data Landscapes with Amazon SageMaker Amazon SageMaker エンドツーエンドデモ Amazon SageMaker によるデータ &amp; AI ガバナンスの民主化 NX Data Station ～ Nippon Express ｘ キヤノン MJ グループによるデータ分析基盤構築（NX 情報システム株式会社様、キヤノンＩＴソリューションズ株式会社様） Amazon SageMaker による生成 AI アプリケーション開発 ソニーグループにおける生成 AI の社内活用と今後の展望（ソニーグループ株式会社様） データから AI をつなぐオールインワンプラットフォーム「データレイクハウス」と Amazon SageMaker（株式会社 NTT データ様） 1. Welcome and Keynote イベントキーノートとして、Amazon SageMaker のプロダクトマネジメントの Director である William が登壇しました。William はまず、データ、AI、アナリティクスの融合が進む現代において、AWS のデータ基盤がどのように進化してきたかを語りました。 マネージドデータベースの導入から始まり、サーバーレス化、マルチリージョン展開、そして Amazon Aurora による高速トランザクション処理の実現まで、データベース技術の革新的な進化を時系列で解説しました。さらに、Amazon 社内での大規模 AI モデル開発経験が、現在の Amazon SageMaker AI という形で結実し、一般提供されているという歴史的な流れも紹介しました。そして生成 AI のテクノロジーとして Amazon Bedrock や Amazon Nova シリーズ、また、 Amazon Q Developer や Amazon Q Business 、 Amazon QuickSight など、開発者やビジネスアナリストが AI を活用するための具体的なサービスも紹介されました。 かつては個別に発展していたビッグデータ、SQL アナリティクス、機械学習、生成 AI の領域が、Amazon SageMaker という単一のプラットフォームで統合されつつある未来像を示し、次のスピーカーである Stephanie による Amazon SageMaker の詳細説明への期待を高めて締めくくられました。 2. Navigating Modern Data Landscapes with Amazon SageMaker 次のセッションでは、AWS のアナリティクス関連の Go-to-Market チームリーダーを務める Stephanie が登壇し、次世代 Amazon SageMaker の全容を紹介しました。 冒頭、Stephanie は現在の企業が直面している課題について触れました。第三社機関の調査を引用しながら、多くの企業が生成 AI の実験に取り組んでいるものの、その 70% が本番環境への展開に至っていないという現状を指摘。その根本的な原因の一つともなる、強固なデータ基盤の重要性を力強く訴えかけました。そして、これらの課題を解決するために開発された次世代 Amazon SageMaker の紹介へと話を展開。その中でも「 Amazon SageMaker Unified Studio 」という新しい統合環境の紹介に時間を割き、データエンジニア、ビジネスアナリスト、データサイエンティストが一つのプラットフォーム上で協働できる環境の中で、従来別々に存在していたツールやワークフローをシームレスに統合できることのメリットを説明しました。 データガバナンスの面では、 Amazon SageMaker Catalog という新機能を紹介。生成 AI を活用してメタデータを自動生成する機能や、データの品質管理、データリネージ管理の機能が組み込まれており、全社規模でのデータ活用を加速できる点を強調しました。さらに、 Amazon SageMaker のレイクハウスアーキテクチャ についても詳しく解説。オープンな設計思想に基づき、様々なデータソースを統合できる柔軟性と、 ゼロ ETL による効率的なデータ処理の実現について解説しました。 最後に、 Amazon SageMaker の料金 の考え方について、紹介した様々な機能が従量課金制で提供される点を解説しました。これによりコスト面での懸念を払拭しながら、企業のデータ活用と AI 導入への取り組みを進めやすいモデルとなっていることを強調しました。 まとめとして、次世代 Amazon SageMaker が企業のデータ活用と AI 導入を本質的に変革するプラットフォームとして位置づけられていることを強調してセッションを締めくくりました。 3. Amazon SageMaker エンドツーエンドデモ 続くセッションでは、AWS Japan BigData Architect 関山より、次世代の Amazon SageMaker のユーザー体験をエンドツーエンドで知っていただくために、架空の企業エニーカンパニービバレッジにおけるデータと ML/AI の課題解決のストーリーを Amazon SageMaker Unified Studio 上でデモしました。 Amazon SageMaker Unified Studio の各機能はネイティブで Amazon Q と統合されており、データディスカバリー、ETL ヴィジュアルパイプラインの自動作成、SQL の自動生成などが可能になっています。下のスクリーンショットは、画面右側の Amazon Q チャットウィンドウで自動生成したクエリをクエリブックから実行するデモです。 Amazon SageMaker Unified Studio におけるデータガバナンスの中核をなすのが Amazon SageMaker Catalog です。SageMaker Catalog を使用することで、データを簡単に発見・共有する仕組みを導入できます。また、生成 AI を活用することで新しく作ったテーブルにビジネスメタデータを自動生成することもできます。 SageMaker Catalog で共有されたデータを機械学習チームが利用して、今後の製品の売り上げを予測しグラフにプロットしています。このデモでは機械学習に加えて、生成 AI を活用したマーケティングコンテンツ (テキスト・画像) の自動生成も紹介しました。 このように、複数人で協働する具体的なユースケースを想定したデモを通じて、Amazon SageMaker Unified Studio を活用したデータと AI に関する一連の作業のイメージを披露しました。データと AI の活用に課題をお持ちの方には、ぜひ、次世代の Amazon SageMaker ならびに Amazon SageMaker Unified Studio をお試しいただき、データとAIをビジネス推進のために活用いただけましたら幸いです。 4. Amazon SageMaker によるデータ &amp; AI ガバナンスの民主化 デモセッションに続いて、AWS Japan アナリティクススペシャリストソリューションアーキテクトの大薗よりデータ &amp; AI ガバナンスの民主化をテーマにセッションを行いました。 セッションでは、まず AI 時代におけるテクノロジーの変化について説明し、生成 AI の進化について触れました。単純なチャットボットから、複雑なタスクを自動化する生成エージェント、さらには完全自立型のエージェンティックAIへと発展していく流れを解説し、今後ますます質が高く統制されたデータを最大限活用いる環境準備が不可欠である時代がきていることを提起しました。 データガバナンスに対する新しい考え方として、従来の「統制重視」から「データ活用促進のためのガードレール」という位置づけへの転換について説明し、企業全体でのデータガバナンスの民主化の必要性を述べました。組織面での取り組みでは、「データスチュワードシップ」の概念を中心に、クロスファンクショナルなチーム編成の必要性や、データドメイン駆動のガバナンスについて説明。これらを実現するための具体的な組織構造についても例を交えて解説しました。 技術面では、SageMaker Catalog の機能の詳解を行いました。このツールが「発見」「ガバナンス」「コラボレーション」という 3 つの主要機能を持つことを説明し、特に「発見」の機能については、メタデータの自動生成やデータ品質の可視化などの特徴と仕組みを紹介しました。最後に、プロジェクトベースの権限管理モデルや、様々なツールとの統合について説明を行い、データガバナンスのプラットフォームとしての SageMaker Catalog の位置づけを示してセッションを終えました。 5. NX Data Station ～ Nippon Express ｘ キヤノンMJグループによるデータ分析基盤構築（NX情報システム株式会社様、キヤノンＩＴソリューションズ株式会社様） 本セッションでは日本通運株式会社 (NX) が AWS 上で利用しているデータ分析基盤である「NX Data Station」について、NX 情報システム株式会社 (NIS) からそのビジネスの狙いを、そして技術観点で伴走支援を提供しているキヤノンＩＴソリューションズ株式会社からは、どのような構成でどう進化させているかの説明がありました。 最初に登壇した NIS 第 5 アプリケーションマネジメント部 次長 髙 為彦氏からは、日本通運が置かれているビジネス的な課題とNX Data Station を活用することでどのように課題解決に取り組んでいるかについて説明がありました。 最初に、NX Data Station のアーティテクチャーの概要が説明されました。NX グループでは 2013 年からオンプレミスやプライベートクラウドから AWS へ移行を開始しており、それらとの親和性を鑑み、 Amazon Redshift や Amazon QuickSight などのサービスを利用し、データレイク、データウェアハウスを構築されてきました。 髙氏は、AWS は機械学習や AI などのサービス基盤がアドオンで追加可能で、基本的に従量課金であり、スモールスタートが可能であること、コストパフォーマンスの良さ、およびデータ利活用文化を醸成する上で必要となる PoC やトライ&amp; エラーに適しているという運用面から、AWS を選定したと説明されました。 課題の例として、物流業界における労働力不足という社会課題について、日本通運がどう対応し、NX Data Station をどう活用しているかの説明がありました。自動倉庫といった機械による効率化もあるものの、まだ人手に頼ることも多くあり、24 時間稼働の大型倉庫などでは、一日の労働者数が延べ数百人規模になることもある業務です。髙氏は、労働力不足への対応で重要なのは適切な人員配置であると説明したうえで、繁忙期、閑散期、キャンペーンなどに適切な配置を実施するため、NX Data Station のデータレイクに蓄積したデータを BI の分析や機械学習により予測し、最適な配置を計算していると説明しました。商品カテゴリー、作業スペース必要の有無などを考慮したメッシュの細かい予測をし、その予測に対してフォークリフトに乗れる、特殊梱包ができる、など従業員の属性などを掛け合わせ、最適な人員配置を計算します。また、求人情報をダッシュボード化して分析し、それらの人員確保の戦略を練ることも合わせて行っています。 続いて、キヤノンＩＴソリューションズ株式会社 渡邊 哲也 氏より、NX Data Station のアーキテクチャについて、技術的な説明があった後に、それをどのように継続して改善しているかについて説明がありました。構成として、ETL は AWS Glue 、補足手法として Amazon AppFlow と AWS Database Migration Service (DMS)、データレイクとしての Amazon S3 、DWH として Amazon Redshift を活用する構成です。 また、 渡邊氏は、NX Data Station が活用され続けている理由として、キヤノンＩＴソリューションズが 1/サービスを常にアップデートすること、2/データ登録の障壁をなくすこと、そして 3/前向きなユーザーを待たせないこと、といった工夫を続けていることを説明されました。 これにより、SIer がなんでもやるのではなく、ユーザーによるデータ活用の 「自走」 が行われる環境を実現しているとし、最後に、利用している AWS サービスが含まれる、Amazon SageMaker への移行・活用を検討している事を説明されました。 6. Amazon SageMaker による生成 AI アプリケーション開発 AWS Japan の AI/ML スペシャリストソリューションアーキテクトである武田からは、Amazon SageMaker の AI 機能に深く踏み込んだ内容に関するセッションをお届けしました。 セッションは、現代の AI 活用の課題提起から始まりました。生成 AI の急速な発展により、顧客体験の改革や従業員の生産性向上など、様々な可能性が広がっている一方で、企業が直面している現実的な課題について説明。特に、単に基盤モデルの API を利用するだけでは、企業の複雑な課題解決や競合との差別化は難しいという点を強調しました。 さらに、現在の生成 AI の技術的背景について、歴史的な流れを交えながら説明が続きました。ニューラルネットワークから始まり、ディープラーニング、そして現在のトランスフォーマーモデルに至るまでの技術の変遷について説明を行ったうえで、なぜ Amazon SageMaker が必要になるのかといった点について解説しました。 セッションの後半では、実際のデモを用いて SageMaker Unified Studio における AI/ML 関連の機能を深堀りして紹介しました。チャットボット開発の手順からファインチューニングの方法まで、具体的な操作フローを示し、システムプロンプトの設定、ナレッジベースの統合、ガードレールの設定など、実務で必要となる機能が単一の画面で操作できる点、さらに、プロジェクトの共有機能など、チーム開発を意識した機能についても触れ、従来別々に管理されていた機能が一つの環境で扱えるようになった点について説明しました。 セッションを通じて、生成 AI の活用には技術的な理解と実務的なノウハウの両方が必要であり、Amazon SageMaker がそれらを統合的にサポートするプラットフォームとして機能していることを伝えました。 7. ソニーグループにおける生成AIの社内活用と今後の展望（ソニーグループ株式会社様） 本セッションでは、ソニーグループ株式会社からソニーグループにおける生成 AI の活用を推進するための取り組みの概要と、技術的な観点から RAG (Retrieval-Augmented Generation) の精度向上のための施策や Amazon SageMaker の活用についてご紹介いただきました。 ソニーグループでは、様々な事業領域にわたる AI の民主化を積極的に推進しています。ソニーグループの全社員が AI とデータの良き使い手となり、AI のビジネスへの適用を加速させることで、クリエイティビティと生産性向上の両立を狙っています。 AI の民主化を実現するため、ソニーグループでは主に Enterprise LLM と Playground という 2 つのソリューションを提供しています。Enterprise LLM はビジネスにおける安全な生成 AI 活用を可能にするプラットフォームであり、Playground はより実践的なビジネス適用を支援する環境です。これらのソリューションを通じて、ソニーグループは従業員が生成 AI を日常的なビジネス活動に取り入れやすい環境を整備しています。 Enterprise LLM のアーキテクチャは 130 以上のモデルへのアクセス、ローコード・ノーコードでエージェントを作成可能なワークスペース、カスタムデータパイプライン、外部検索 API などから成り、ソニーグループでの AI 活用を支えています。ソニーグループでの AI 活用において、ソニーグループ内の専門用語の理解は重要です。RAG の検索精度向上のために埋め込みモデルの Fine-tuning を検証しており、 Amazon SageMaker notebook instance を活用することでマネージドな Fine-tuning ジョブの実行が可能で、検証プロセス全体が数時間程度で完了できことが紹介されました。また、推論エンドポイントには Amazon SageMaker Serverless Inference を採用し、プロビジョニングされた同時実行を活用することでコールドスタートを最小限に抑えながらコストも削減することに成功しています。 また、Amazon SageMaker により、幅広いユースケースに対応可能な多様なモデルの提供や、Amazon SageMaker Unified Studio によるローコード・ノーコードでの生成 AI アプリケーション構築が可能です。将来的には SLM (Small Language Model) の進化により生成 AI のエッジ展開が予想されますが、その際にも Amazon SageMaker でのカスタムモデル構築が重要な役割を果たすことが期待されています。 8. データからAIをつなぐオールインワンプラットフォーム「データレイクハウス」とAmazon SageMaker（株式会社 NTTデータ様） 最後のセッションとして、株式会社 NTT データより、”データからAIをつなぐオールインワンプラットフォーム「データレイクハウス」と Amazon SageMaker” と題した発表がありました。 まずはじめに、オールインワンプラットフォームが必要とされるようになった背景について説明がありました。従来型のビルディングブロックによるデータ分析基盤では、利用するサービスの数が増え複雑化し、学習コストや運用負荷、データの分散管理といった課題が顕在化しています。そのため、あらゆるデータを一か所で管理できるデータレイクハウスアーキテクチャを持ち、複数のユースケースに対応した機能がオールインワンで提供されるデータプラットフォームが必要になってきています。これが次世代の Amazon SageMaker です。これまで各サービス個別で提供していた UI や資材管理を一元化する Unified Studio、複数サービス横断でデータの探索をしたり、一元的なガバナンス・セキュリティを提供する Catalog、データを Open Table Format で一元管理するレイクハウスアーキテクチャで構成されています。 上記を踏まえる形で、次世代の Amazon SageMaker について NTT データからの視点で解説がありました。次世代の Amazon SageMaker は多様なユースケースに対応するデータ・アナリティクス・AI サービスを統合し、オールインワンプラットフォーム化することで、よりデータ・AI を管理・活用しやすくする仕組みです。本プラットフォームは、データレイクハウスアーキテクチャを採用し、Amazon S3 上のデータを管理するだけでなく、Amazon Redshift のマネージドストレージを Apache Iceberg 互換の API で統合することができます。また、 Amazon DataZone を内包する Amazon SageMaker Catalog にて横断的なデータだけではなく AI モデルを管理し、ガバナンス・セキュリティをかけることができます。そして、最後に、AWS が持つアナリティクス・機械学習・生成 AI の多様なサービスを、Amazon SageMaker Unified Studio という、一元的なエントリーポイントで生産性高くデータと AI、アプリの開発を行うことができます。 最後に生成 AI 時代のデータ活用組織のあり方について説明されました。AI エージェントシステムの開発には、データ・AI・生成AI・アプリの要素が必要であり、これまで説明してきたオールインワンプラットフォームはすべての要素が含まれており、最適です。ただ、ツールがオールインワンプラットフォームである以上、組織側もオールインワンになる必要があります。すなわち、データエンジニア・データサイエンティスト・生成 AI エンジニア、アプリエンジニアがいかにサイロ化を防ぎ協力し合えるかが重要です。NTT データも例外ではなく、組織の壁を超える取り組みを行っているものの、その難しさに直面しています。そのためには、より広い視点から AI システムを俯瞰するアーキテクトのような職種も必要になってくるのではないでしょうか。NTT データでは、オールインワンプラットフォームの考え方や AI システムの全体像を理解している、このスーパーマンを育成し、お客様をご支援できるように尽力していると述べ、発表を締めくくりました。 まとめ 「Amazon SageMaker Roadshow –Japan」と題した本セミナーでは、近年注目されているデータと AI の統合というテーマに関連する、多様な観点を含むセッションが盛り沢山となりました。本セミナーにて紹介された AWS サービスにご興味ある場合は無料で個別相談会を開催しております。皆様からのお申込みをお待ちしております。 お申込みリンク 本ブログは、ソリューションアーキテクトの大薗が作成しました。

ゲーム業界は今、かつてない変革期を迎えています。モバイルゲームの普及、クロスプラットフォーム化、そしてメタバースの概念拡大など、従来のゲーム開発に求められる技術スタックでは対応しきれない課題や知識需要が次々と生まれています。特に、大規模なマルチプレイヤーオンラインゲームの開発においては、スケーラブルなサーバーサイド技術への需要が急速に高まっています。 しかし、こうした技術需要に対して、ゲーム開発に特化したサーバーサイド技術を持つプログラマーの育成には課題が山積しているのが現状です。多くのゲームプログラマーはクライアントサイドの開発に特化しており、サーバーサイド技術への理解が十分とは言えません。従来の Web アプリケーション開発とは異なる、リアルタイム性やスケーラビリティ、グローバル展開といったゲーム特有の要件、さらには可用性・レジリエンシーを確保した堅牢なシステム設計に対応できるプログラマーの育成が、業界の課題となっています。 ゲーム開発におけるクライアントサイド技術に加えて、サーバーサイド技術も身につけることで、ゲームプログラマーとしてのキャリアの可能性は大きく広がります。オンラインゲームの企画段階からアーキテクチャ設計に関わることができ、技術的制約を考慮した企画提案や、運用を見据えた実装が可能になります。 このような背景から、 株式会社コーエーテクモゲームス (以下、コーエーテクモゲームス) と、Amazon Web Services Japan は共同で、2025 年度新卒ゲームプログラマー向けに、次世代のゲームプログラマーを育成する「ゲームサーバー開発研修プログラム」を実施しました。その取り組みをご紹介します。 ゲームサーバー開発研修プログラムの設計 オンラインゲーム開発・運営では、ゲーム開発スキルに加えて、以下のネットワーク関連スキルの習得が不可欠です： サーバーサイド基盤技術：Linux、TCP/IP、HTTP/HTTPS プロトコル データベース設計：RDB、NoSQL、分散データベース リアルタイム通信：UDP、TCP ソケットを活用したゲーム通信プロトコル 分散システム設計：負荷分散、可用性・レジリエンシー対応 クラウドアーキテクチャ：AWS サービス群の適切な活用と組み合わせ 新卒ゲームプログラマーがこれらのスキルを効率よく身につけられるよう、コーエーテクモゲームスと協力して、ゲームサーバー開発の研修プログラムを作り上げました。 また、この研修では、 「オンラインゲームがどのような仕組みで動いているのかを理解し、それを他の人とわかりやすく話し合えるようになること」 を目標に掲げています。プログラミングスキルやネットワーク関連スキルを習得することはもちろん大切ですが、それだけではありません。習得した知識を使って、オンラインゲームの仕組み全体を理解し、チームメンバーや企画部門、運営チームなど、さまざまな立場のスタッフと技術的な意見交換ができるようになることに期待しています。その結果、企画段階から「この機能のトレードオフは性能面でどうか」といった技術的な観点での提案ができたり、「将来の運用負荷を考慮したシステム設計」ができる。そんな幅広い視点を持つゲームプログラマーを育成することでオンラインゲーム開発力を高めたいと考えています。 この目標を達成するための、新卒ゲームプログラマー向けの研修は以下の方針で行いました。 1. 段階的スキル構築 ：基礎から応用まで無理のない学習曲線を設定 2. ゲーム開発に即した学習 ：汎用的なWebアプリではなく、ゲーム開発の文脈で技術を習得 3. 実践重視 ：座学・ハンズオン・グループワーク・確認テストを効果的に組み合わせ 4. チーム開発体験 ：個人学習に加え、グループ内のディスカッションや他グループのプレゼンテーションを通じた学びを得る ゲームサーバー開発研修プログラムの実装 研修プログラムは5日間の集中プログラムとして行われ、具体的には以下の技術要素を実践的に学習しました。本研修ではオンラインゲームの主要機能 (ギルド作成・ギルド参加・ギルド内でのプレイヤー間メッセージ送信)を題材に、データベース設計から Linux サーバーの操作、 Web API とリアルタイムサーバーのソフトウェアを一通り開発することができ、オンラインゲームにおけるサーバーサイド開発を体験することができるカリキュラムとして実装しています。 1日目: データベース リレーショナルデータベースを活用したゲームデータ設計の基本概念 ゲームデータに対する SQL 操作 テーブル設計グループワーク 2日目: Linuxサーバー・TCP/IP Amazon EC2 インスタンスでの Linux OS 基本操作 パフォーマンス監視、プロセス管理、ログ分析 TCP/IP プロトコルスタック、パケット解析 3日目: ネットワークプログラミング① HTTP プロトコルの理解 PHP を用いた Web API の実装 Web API の設計グループワーク 4日目: ネットワークプログラミング② ゲーム開発におけるネットワーク通信手段の理解 Node.js を用いたリアルタイムサーバーの実装 リアルタイムサーバーにおけるスケーラビリティの考慮 5日目: クラウドとアーキテクチャ設計 クラウドコンピューティングの基礎 要件定義からアーキテクチャ設計に至るプロセス ゲームサーバーのアーキテクチャ設計グループワーク データベース研修の様子 グループワークの実施 研修の一部では、3〜4名のチームに分かれて、オンラインゲームを題材に以下の3つの設計課題に取り組みました： データベース設計：プレイヤーデータ、ギルド、メッセージ情報の設計 Web API 設計：ゲームクライアント・サーバー間通信、ギルド参加、メッセージ送受信の実装 クラウドアーキテクチャ設計：AWS サービスを活用したシステム設計 グループワークで作成した API 設計の一例 グループワークの成果物のプレゼンテーションが行われている様子 グループワークの実施により、個人学習では得られない以下の効果が確認されました： 技術的議論を通じた理解の深化 ：チームメンバー間での技術的議論により、個人学習では気づかない設計上の考慮点や最適化手法を発見する場面が見られました。特に、データベース設計においては「なぜこの設計にするのか」という根拠を説明し合い、他チームからのフィードバックを得ることで、理解が大幅に深まりました。 多角的な視点の獲得 ： 同一の技術課題に対して複数のアプローチを検討する機会が生まれました。これにより、単一の解決策に固執せず、トレードオフを考慮した柔軟な思考力が身につきました。 研修の成果と評価 参加者フィードバック 研修終了後のアンケートでは、「オンラインゲームのアーキテクチャを大まかに理解できたこと」「サーバーサイド技術への苦手意識の改善」など参加者から多くの前向きな評価をいただきました。実施後の参加者向けのアンケートでも想像以上の高い満足度が確認できており、新卒ゲームプログラマーの成長に合わせた学習カリキュラムの提供を今後もコーエーテクモゲームスと共同で計画しています。 以下に、フリーコメントの一部を抜粋して紹介します： サーバーサイドの分野について漠然としていた理解が、より具体的でクリアなものになりました。特にデータベース設計やアーキテクチャ設計については、パズルのような面白さがあり、アイデアや深い思考が求められる点に強く関心を持つことができました。 以前はプログラミングでネットワーク関連に触れる機会がなく、今回の研修でサーバーの構築や運用の概要を知ることができ、大変勉強になりました。「ネットワークが難しそう」という印象から、「ネットワークをもっと知りたい」という意欲的な姿勢に変化することができました。 オンラインゲームに必要な技術や考え方、さらにインターネットを介することで重要性が増すセキュリティについて、実感を伴う形で理解を深めることができました。 技術理解度の測定 技術理解度の測定には、 AWS Skill Builder Trivia を活用し、ゲーム感覚で学習効果を測定できる仕組みを導入しました。AWS Skill Builder Triviaは、リアルタイムでマルチプレイヤー競争が可能なクイズプラットフォームです。本研修では、5日間の学習内容の復習を目的として、研修で扱った技術要素に関するカスタムクイズを作成し活用しました。 特に効果的だった点： 即座のフィードバック：クイズ結果により、理解不足の領域を即座に特定できる 競争要素：リアルタイムリーダーボードによる学習意欲の向上 インタラクティブな体験：QRコードでの簡単参加により、全員がスマートフォンから気軽に参加できる AWS Skill Builder Triviaを活用した復習セッションの様子 今後の展望 今後の展望について、執行役員 エンタテインメント事業部 シブサワ・コウブランド長 澤田 圭輔 氏と、エンタテインメント事業部シブサワ・コウブランド シニアリーダー 冨士田 智仁 氏に、今後の展望について話を伺いました。 「5 日間の集中研修で基礎技術を習得した後、チームでミニゲームを作成し、ネットワーク機能を実装することにしました。クライアント・サーバー間の連携や、実際のコーディング経験の重要性を、実践的なゲーム開発を通じて体験してもらうことで、より実用的なスキルが身につくと考えています。新卒社員にとって、サーバーサイド技術との連携を実感できる貴重な機会になると期待しています。そして、今回の研修で得た技術・経験を活かして開発現場で活躍いただけることに期待しています！」 澤田 圭輔 氏 「研修の成功を受け、より高度な技術領域への展開を計画しています。 AWS のクラスルームトレーニング を活用し、専門コースの受講を検討中です。また、研修参加者のスキルの可視化と継続的な学習モチベーションの維持のため、 AWS 認定資格 の取得を推奨しています。既に一部の社員が積極的に資格取得に取り組んでおり、社内の AWS 技術レベルの向上に大きく貢献しています。」 冨士田 智仁 氏 初級クラウド人材育成おすすめラーニングパス おわりに コーエーテクモゲームスと Amazon Web Services Japan の共同研修である「ゲームサーバー開発研修プログラム」は、ゲーム業界特有の技術要件に対応できる人材育成において、貴重な一歩を踏み出すことができました。 リアルタイム性、スケーラビリティ、グローバル対応、継続的サービス運用といったゲーム特有の要件を満たすために、クラウドの理解と実践的活用スキルを磨き続けることがゲーム開発者のキャリアの幅を大きく広げると期待しています。 また、今回の取り組みが、ゲーム業界全体での技術人材育成のモデルケースとなり、より多くの企業で同様のプログラムが展開されることを期待しています。AWS は今後も、ゲーム業界のイノベーションを支える人材育成に積極的に貢献していきます。 この記事は、アマゾン ウェブ サービス ジャパン合同会社 シニアソリューションアーキテクト 大西 啓太郎が執筆しました。

この記事は&nbsp;Camilla Panni, Greg Breen によって書かれた AWS IoT Greengrass nucleus lite – Revolutionizing edge computing on resource-constrained devices の日本語訳です。この記事は ソリューションアーキテクトの川崎が翻訳しました。 AWS IoT Greengrass は、オープンソースのエッジランタイムです。このクラウドサービスは、マルチプロセスアプリケーションを大規模に構築 / デプロイ / 管理することができ、IoT フリート全体の運用を支援します。 AWS IoT Greengrass は2020 年 12 月に V2 をリリースし、 nucleus として知られる Java エッジランタイムを導入しました。 2024 年 12 月の release 2.14.0 &nbsp;では、 C 言語で書かれた追加のエッジランタイムオプションである nucleus lite を追加しました。 AWS IoT Greengrass nucleus lite は、リソース制約のあるデバイスを対象とした軽量な オープンソース のエッジランタイムです。スマートホームハブ、スマートエネルギーメーター、スマートビークル、エッジ AI、ロボティクスなどの大量生産アプリケーション向けに、低コストのシングルボードコンピュータで AWS IoT Greengrass の機能を拡張できます。このブログでは、2つのエッジランタイムオプションの利点を説明し、ユースケースに最適なオプションを選択するための指針を提供します。 nucleus と nucleus lite の主な違い AWS IoT Greengrass nucleus lite は、AWS IoT Greengrass の V2 クラウドサービス API と&nbsp; プロセス間通信 (IPC) &nbsp;インターフェースと完全に互換性があります。これは、1 つまたは両方の実行時を対象としたコンポーネントを構築してデプロイできること、また、クラウドサービスを使用してデバイスフリートを管理し続けることができることを意味します。ただし、nucleus lite には、いくつかの重要な違いがあり、特定のユースケースに適しています。 メモリ使用量 AWS IoT Greengrass nucleus は、 ディスク スペース 256 MB 以上、RAM 96 MB 以上 が必要です。 ただし、オペレーティング システムやJava 仮想マシン (JVM)、アプリケーションが動作するため、 RAM は最低 512 MB を推奨しています。昨今では、1GB以上のRAMを搭載したデバイスは一般的になってきています。しかし、限られたリソースで動作を求められるデバイスも数多く存在しています。物理的リソース条件が厳しいデバイスでも利用できるよう nucleus lite が誕生しました。 nucleus lite は非常に小さなフットプリントで動作します。 RAM 5MB 、ストレージ (ディスク/フラッシュ)&nbsp; 5MB のみ必要です。また、JVM を必要とせず、C 標準ライブラリのみで動作可能です。 図 1: nucleus と nucleus lite のメモリフットプリントの比較 リソース制約のあるデバイス上でも AWS IoT Greengrass を利用する新しい選択肢が生ました。 静的メモリ割り当て AWS IoT Greengrass nucleus lite&nbsp; ランタイムのメモリフットプリントは、初期設定とビルドプロセス中に決定されます。ランタイムが開始すると、 nucleus lite は一定量のメモリを割り当て、その後はその量が一定のままです。 つまり、 nucleus lite はリソース要件が予測可能で再現性があり、メモリリークのリスクが最小限に抑えられ、ガベージコレクションを行う言語に関連する非決定論的な待ち時間がなくなります。 メモリ使用量が変動するのは、デプロイした AWS IoT Greengrass コンポーネントや AWS IoT Greengrass 外で実行するプログラムによる動的メモリ割り当てのみです。 ディレクトリ構造 Nucleus lite は、Nucleus lite ランタイム、Greengrass コンポーネント、設定、ログをディスク上の異なる領域に分離します。組み込み Linux システムでは、これらの異なる要素は通常、異なるパーティションまたは異なるボリュームに保存できます。 例えば: nucleus lite ランタイムは、OS イメージの更新を可能にするため、A/B パーティション分割の一部として、読み取り専用パーティションに格納される可能性があります。 AWS IoT Greengrass のコンポーネントと設定は、アプリケーションが AWS IoT Greengrass のデプロイメントによって管理できるように、読み書き可能なパーティションまたはオーバーレイに格納される可能性があります。 ログファイルは、ルートボリュームの限られたフラッシュメモリの書き込みサイクルを消費しないように、一時パーティションまたは別の物理ボリュームに格納される可能性があります。 この分離により、スケールでデバイス製造のための golden イメージを構築するのに役立ちます。詳細については、 Manufacturing devices at scale with AWS IoT Greengrass golden images をご覧ください。 systemd との統合 systemd &nbsp;は Linux システムで一般的に利用可能なシステムとサービス管理フレームワークで、AWS IoT Greengrass nucleus lite には必須です。 nucles lite をデバイスにインストールすると、 systemd サービスまたはデーモンの集合体 &nbsp;としてインストールされます。nucles lite は、デバイスに展開する AWS IoT Greengrass コンポーネントごとに個別の systemd サービスとしてインストールします。nucles lite は、デバイスの多数のフリートにまたがってスケールするクラウド管理の systemd として考えることができます。 nucleus lite とコンポーネントを systemd サービスとしてインストールしているため、systemd がシステムログを処理し、集中管理します。つまり、一般的な Linux システムツールを使用して、デバイスソフトウェアを監視、保守、デバッグできます。 nucleus と nucleus lite の選択 nucleus ランタイムと nucleus lite ランタイムの選択は、使用ケース、デバイスの制約、必要な機能、および OS によって異なります。次の表は、選択の目安を要約したものです。 nucleus 利用ケース nucleus lite 利用ケース オペレーティングシステムに Windows を使用したい、または systemd が含まれていない Linux ディストリビューションを使用したい場合 アプリケーションコンポーネントが Docker コンテナである場合 アプリケーションコンポーネントが Lambda 関数である場合 スクリプト言語または解釈型プログラミング言語を使ってアプリケーションコンポーネントを開発する場合 nucleus lite でまだサポートされていない機能 を使用したい場合 AWS IoT SiteWise ゲートウェイ を作成する場合 デバイスのメモリが制約されており、RAM が 512 MB 以下の場合 デバイスの CPU のクロック周波数が 1 GHz 未満の場合 組み込み Linux ディストリビューションを作成し、OS イメージの更新や A/B パーティションなどの機能をサポートするため、パーティションスキームを正確に制御する必要がある場合 マシン語にコンパイルされるプログラミング言語を使ってアプリケーションコンポーネントを開発する場合 ava が適さないコンプライアンス要件がある場合 静的メモリ割り当てを好む場合 表 1: nucleus と nucleus lite を選択する際の指針 表 1 の指示は規範ではなく、一般的なガイダンスです。たとえば、ユースケースのニーズに基づいて、ギガバイトの RAM を搭載したデバイスで nucleus lite を使用することができます。また、デバイスのリソースが十分にある場合は、スクリプト言語やインタプリタ型言語で書かれたコンポーネントを nucleus lite にデプロイすることもできます。 シナリオとユースケース ユースケース メモリとプロセシング能力が制限された低コストデバイス、そして慎重に選別された組み込み Linux ディストリビューションに適しているのが、リソース要件のハードルが低い nucleus lite です。こうしたデバイスには、スマートホーム、産業、自動車、スマートメーターなど、さまざまな分野があります。 組込みシステム nucleus lite は、ローンチ時から meta-aws project によって提供される組み込み Linux のサポートを含むことで、組み込みシステム開発者にとって大きな前進を示しています。このプロジェクトには、 サンプルレシピ が含まれており、AWS IoT Greengrass を OpenEmbedded または Yocto プロジェクトにビルドインすることができます。このプロジェクトの姉妹プロジェクト meta-aws-demos には、 RAUC を使った A/B アップデートのデモ など、AWS IoT Greengrass の数多くのデモが含まれています。 コンテナ化された軽量&nbsp;AWS IoT Greengrass nucleus lite&nbsp;によるマルチテナンシーのサポート nucleus lite はフットプリントが小さいため、マルチテナント IoT デプロイに対して効果的なコンテナ化を実現できます。独自の AWS IoT Greengrass ランタイムと一体化した複数の分離アプリケーションを実行できます。 図 2: マルチテナントのコンテナ化 アーキテクチャの利点は次のとおりです: セキュリティを考慮した分離 : それぞれのコンテナ化されたインスタンスは、アプリケーション間の厳格な境界を維持します。 リソース最適化 : 軽量なフットプリントにより、制約された環境でも複数のコンテナをサポートできます。 独立した運用 : アプリケーションを個別に管理、デバッグ、更新できます。 柔軟なデプロイ : デバイスの機能に基づいて、さまざまなコンテナ化の戦略をサポートします。 実装のベストプラクティス nucleus lite を使用するには、コンポーネントを書き直す必要はありません。ただし、メモリ効率を最大化したい場合は、コンポーネントを最適化または書き換えることを選択できます。 nucleus lite を使用するにあたり、以下の重要な考慮事項を確認ください。 プラグインの互換性 プラグインコンポーネント は、Java 版 の nucleus ランタイムと密接に統合された特殊な Java コンポーネントです。これらのプラグインは nucleus lite ランタイムでは使用できません。 コンポーネント言語の考慮事項 カスタムコンポーネント用のプログラミング言語を選択する際は、各言語のインタープリターまたはランタイム環境が全体のメモリフットプリントに影響することを考慮する必要があります。Python のような言語を選択すると、nucleus lite のメモリ節約効果がある程度相殺されます。Java を選択する場合は、システムに JVM を導入する必要があります。 異なるシナリオ向けの推奨事項 nucleus から nucleus lite に移行する際、既存のコンポーネントはそのまま動作します。そのため、nucleus lite への移行が簡単になり、最適化の計画を立てている間も機能が維持されます。 新規に作成する場合: 最大の効率を得るために、重要なコンポーネントを書き換えることを検討してください。 C、C ++、Rust などのランタイムオーバーヘッドが最小限の言語を選んでください。 開発の労力とメモリ最適化のニーズのバランスをとってください。 メモリ容量の計画を立てる場合: メモリ計算では、すべてのランタイム依存関係を考慮してください。 nucleus lite のサイズだけでなく、システム全体のフットプリントを評価してください。 適切な場合はコンポーネントの統合を検討してください。 将来の展望と結論 今後、AWS IoT Greengrass nucleus lite を活用することで、エッジコンピューティングの実装を再構築できます。 リソース要件を大幅に削減することで、次のようなことが可能になります。 リソースの制限のあるデバイスに IoT 機能をデプロイ より広範なハードウェアでのエッジコンピューティングソリューションの実装 機能を維持しながら運用オーバーヘッドの削減 リソース要件に制限されていた新しい使用例の実現 開発者にとって、nucleus lite はエッジで革新的なことを行う新たな機会を提供します。リソース制約のあるデバイスでエッジコンピューティングが可能かどうかを気にする代わりに、ビジネス価値を生み出すソリューションの実装に集中できます。 この AWS IoT ポートフォリオの強化により、より幅広いデバイスやユースケースに対応する効率的かつスケーラブルな IoT ソリューションを構築するというコミットメントが示されました。 AWS IoT Greengrass nucleus lite を使用して IoT ソリューションの開発に向けて以下を検討ください。 詳細を理解する : AWS IoT Greengrass のドキュメント を参照してください。 nucleus lite を試す : インストールガイド または Getting Started チュートリアル に従って実験と開発を始めましょう。 専門家に質問 : 質問やガイダンスが必要な場合は、AWS IoT の専門家に相談してください。 コミュニティに参加 : AWS IoT コミュニティフォーラムで体験を共有したり、他のユーザーから学びましょう。 コントリビュート : オープンソースリポジトリ にコードを投稿してください。 _________________________________________________________________________________ 著者について Camilla Panni は、 Amazon Web Services のソリューションアーキテクトです。彼女は、イタリア全土の公共部門の顧客がクラウド導入の取り組みを加速するのを支援しています。自動化とIoTにおける彼女の技術的背景が、顧客が新興技術でイノベーションを起こすのを支援することへの情熱を後押ししています。 &nbsp; Greg Breen は、Amazon Web Services のシニア IoT スペシャリスト ソリューションアーキテクトです。オーストラリアを拠点とし、アジア太平洋地域全体の顧客がIoTソリューションを構築するのを支援しています。組み込みシステムにおける豊富な経験を持つ彼は、製品開発チームがデバイスを市場に投入するのを支援することに特に関心を持っています。

本記事は、2025 年 10 月 9 日に公開された Reimagine business intelligence: Amazon QuickSight evolves to Amazon Quick Suite を翻訳したものです。翻訳は Solutions Architect の守田凜々佳が担当しました。 ビジネスインテリジェンス (BI) の領域は、変革期を迎えています。データ活用が進み、AI が日常生活におけるデータとの関わり方を大きく変えている今、顧客は重要な岐路に立っています。つまり、ビジネスを加速させるために AI の可能性を受け入れる必要がありますが、それを慎重かつ安全に行わなければなりません。多くの顧客が、いかに実質的な価値を生み出す形で AI を業務に統合するか、という課題に直面しています。構造化データの可視化とレポート作成を主な目的とした従来の BI ソリューションは、もはやこの新時代には十分ではありません。 顧客は 3 つの課題に直面しています。データの発見、分析、アクションの間で広がりつつあるギャップを埋めることができるソリューション、具体的なビジネス成果をもたらす形での AI 活用、さらにエンタープライズレベルのセキュリティとガバナンスを維持しながら組織全体のユーザーがアクセスできるソリューション、が必要です。多くの組織は、強力な AI 機能と、既存のデータやプロセスに適合する実用的で安全な実装との間で、適切なバランスを見つけることに苦闘しています。 本日、Amazon QuickSight が Amazon Quick Suite へと進化することを発表できることを嬉しく思います。これは、組織内の全メンバーが包括的なビジネスインサイトを容易に利用できるようにする大きな前進です。この進化は、BI の可能性を広げ、AI エージェントがユーザーと協働しながら複雑な質問への回答、詳細な調査、定型業務の自動化を行う統合された体験を実現します。またその際に企業が期待するセキュリティ、信頼性、ガバナンスを維持します。Quick Suite は、AI 時代における BI の再解釈を行う私たちのビジョンを表しており、組織がより良い意思決定をより迅速に行い、それに基づいて行動できるように支援します。 従来の BI 機能 (現在は Quick Sight と呼ばれています) に加えて、Quick Suite は複数の AI を活用した機能を導入しています： Quick Research – 企業内外のデータソースから、引用付きの包括的なインサイトを提供します Quick Flows – 自然言語でワークフローオートメーションを作成および共有します Quick Automate – 複雑な多段階のビジネスプロセスを処理します Quick Index – 企業のすべてのドキュメントとデータを共有ナレッジベースとして提供します これらの機能は、自然言語インターフェースの Quick chat を通じてアクセスでき、Quick spaces を通じて各チーム向けにカスタマイズすることができます。この統合環境では、ユーザーはデータ分析、詳細な調査、プロセスの自動化まで、全ての作業を同一アプリケーション内でシームレスに実行することができ、さらにエンタープライズレベルののセキュリティとガバナンスを維持できます。 なぜこの進化が重要なのか 冒頭で述べた企業が直面する 3 つの重要な課題 (データとアクションのギャップの解消、AI の実用的な活用、セキュリティの維持) に対して、Quick Suite は、企業がデータと AI を活用する方法を変革する包括的なソリューションを提供します。 あらゆるデータを統合するインテリジェンス – 従来の BI ソリューションは、指標と数値の活用に限定されており、ドキュメント、メール、エンタープライズアプリケーションに含まれる価値あるインサイトが活用できていませんでした。これにより、データの発見と有意義なインサイトの間に大きなギャップが生じていました。Quick Suite は、エンタープライズシステム、データベース、データレイク、チームの知見、リアルタイムのウェブインサイトなど、意思決定に必要なすべてのソースからのデータアクセスを統合することで、このギャップを解消します。経営者は、財務データベース、カスタマーフィードバックのメール、サポートチケット、市場調査文書にまたがる質問を行い、数秒で完全な回答を得ることができます。データの専門家は、利用可能なソースからコンテキストを取り込んだ高度な可視化と分析を作成し、より豊かで実用的なインサイトをステークホルダーに提供できます。 実用的な AI イノベーション – 企業が必要としているのは、単なる技術的な目新しさではなく、具体的なビジネス成果をもたらす AI です。Quick Suite は、強力な調査、分析、自動化エージェントを通じてこれを実現します。Quick Research は、社内データ、公開情報、専門データセットから情報を統合し、これまで数週間かかっていた包括的で引用付きのインサイト提供を数時間で実現します。Quick Flows を活用すると、議事録からアクション可能なタスクを作成する、最新のインサイトを含む週次レポートを自動で生成する、カスタマーサポートプロセスを効率化するなど、自然言語を使用して AI を活用したワークフローを作成できます。これらのワークフローを素早く共有することで、組織全体の生産性向上を実現できます。 セキュアでアクセスしやすい自然言語での体験 – Quick Suite は、エンタープライズレベルのセキュリティとガバナンスを維持しながら、AI へのアクセスを民主化します。強力なチャットインターフェースにより、自然言語での会話を通じて各機能にアクセスできます。組織は、技術的な質問に対応するトラブルシューティングアシスタントや、従業員に社内手続きをナビゲートするためのポリシーガイドなど、特定のニーズに合わせたカスタム AI エージェントを作成できます。これらのエージェントは、ドメインの専門知識と関連データソースを組み合わせ、必要とするすべての人が専門知識にアクセスできるようにします。各エージェントは、特定のペルソナ、データアクセス権、行動ガイドラインでカスタマイズでき、組織全体で一貫性のある、コンプライアンスに準拠した対話を実現します。 変更されない点 Quick Suite は強力な新機能を導入しますが、既存の BI 機能は変更なく維持されます。この進化は、現在の運用を妨げることなく、お客様が信頼する基盤の上に構築されています。 従来の QuickSight 環境は、ダッシュボード、データセット、分析を含めて、すべてがそのまま維持されます。データ接続、セキュリティ管理、ユーザー権限もすべて変更なく継続されます。既存の API 連携も以前と同様に機能し、データの移行も必要ありません。重要な点として、SOC、HIPAA、ISO 27001、ISO 27019、ISO 27018、ISO 9001、GDPR、FedRAMP を含む既存のコンプライアンス認証と認定が、引き続き有効です。Quick Suite は QuickSight の既存のコンプライアンス体制を継承します。また、データのプライバシーとセキュリティに対する AWS のコミットメントを強調したいと思います。私たちは、お客様のコンテンツをモデルのトレーニングに使用することはなく、新しいモデルプロバイダーも導入していません。お客様のデータは、信頼できるエンタープライズグレードのセキュリティとガバナンス管理により、お客様のものとして維持されます。このシームレスな移行により、ビジネスの継続性を維持しながら、お客様のペースで新機能を採用することができます。 リージョンの提供状況 Quick Suite は、すべてのお客様にスムーズな移行を提供するよう、段階的なアプローチで展開します。2025 年 10 月 9 日より、世界中の QuickSight のお客様は、新しい Quick Suite UI とブランディングが表示されます。新機能は、US East (N. Virginia)、US West (Oregon)、Europe (Dublin)、Asia Pacific (Sydney) でご利用いただけます。その他の AWS リージョンのお客様は、新しい Quick Suite インターフェイスが表示されますが、既存の BI 機能のみにアクセス可能な状態が維持されます。 新しいエクスペリエンスの操作方法 Quick Suite のインターフェースは、使い慣れた操作性を維持しながら強力な新機能を導入できるよう、慎重に再設計されました。このセクションでは、Pro ユーザー (Admin Pro、Author Pro、Reader Pro) と Author (Admin 含む) 向けの主要な変更点について説明します。 Quick chat が Quick Suite のホームページに目立つように配置され、Quick Suite の機能にすぐにアクセスできるようになっています。また、ダッシュボードから主要なビジュアルをホームページにピン留めできる新機能が追加され、パーソナライズされたレコメンデーションや最近アクセスしたアイテムにも引き続き簡単にアクセスできます。基本的な Reader ($3) の体験は変更されていませんが、重要なメトリクスをホームページにピン留めできる機能が追加され、最も重要な情報を追跡しやすくなりました。 従来の BI 機能は、ナビゲーションペインの Quick Sight の下に整理されています。コンテンツへの整理されたアクセスのための マイフォルダ と 共有フォルダ 、 ダッシュボード 、 ストーリー (旧 データストーリー )、 分析 、 データセット などです。 お気に入り は、素早くアクセスできるようにトップレベルに残され、グローバル検索は左上に配置されました。また、 Quick Research 、 Quick Flows 、 Quick Automate 、 Connections は、ナビゲーションペインの専用セクションからアクセスできます。 以下のスクリーンショットは、以前の QuickSight ナビゲーションペインと強化された Quick Suite ナビゲーションペインを比較したものです。 価値の向上 既存のお客様にとってのシンプルさを維持しながら、より多くの価値を提供するため、料金体系が変更されます。 お客様は、価格の引き下げと機能アクセスの拡充のメリットを得ることができます: Author Pro の料金が月額 50 ドルから 40 ドルに値下げされ、Author Pro ユーザーは Quick Suite の Enterprise ユーザーの機能 にアクセスできるようになりました Reader Pro (月額 20 ドル) ユーザーは Quick Suite の Professional ユーザーの機能 にアクセスできるようになりました 現在の Author および Admin ユーザーは、2026 年 4 月 30 日までプロモーションとして Quick Suite の Enterprise ユーザーの機能にアクセスできます Reader (3 ドル) および Author (24 ドル) の料金は変更ありません 専用インフラストラクチャ料金: 既存の月額 250 ドルのインフラストラクチャ料金は、引き続き以下のアカウントにのみ適用されます： Pro ユーザー (20 ドル/40 ドルプラン) が 1 つ以上存在 Topics または Dashboard Q&amp;A がアクティブ 2025 年 10 月 9 日以降の新規 Pro ユーザーまたは Q&amp;A 有効化を行ったアカウントについては、2025 年 12 月 31 日までプロモーションとして本料金が免除されます 機能導入の完全なコントロール 組織が AI 機能の採用を正確にコントロールする必要があることを理解しています。管理者は、カスタムアクセス許可を使用してアカウント、ロール、ユーザーレベルで機能の有効化や無効化を行い、新機能を導入しながら既存のセキュリティポリシーを維持し、API を通じて複数のアカウントに一貫したコントロールを適用できます。 Quick Suite は、お客様のペースで導入を管理できる柔軟性を提供します。すべての機能を直ちに有効化することも、異なるユーザーグループに段階的に導入するかを選択ことも可能です。 埋め込み分析 BI の埋め込み機能をご利用の場合、主要な機能は変更されません。埋め込み機能、API、および統合機能は、これまでと同様に動作し、既存の実装に変更を加える必要はありません。ただし Quick Suite に合わせて、フッターが「Powered by Amazon Quick Suite」に更新、カラースキームが青色から紫色に変更、標準的な配置に Quick Suite ロゴが表示されるというビジュアルの更新が行われます。 ブランドカスタマイズ機能をご利用の場合、カスタムスタイルは引き続き製品のデフォルトの外観を上書きします。QuickSight アプリケーション要素について現在の青色のカラースキームを維持したい場合は、アカウントレベルで設定されたブランドカスタマイズ、公開時のテーマカスタマイズの適用、SDK を使用した埋め込み呼び出しでの動的な適用、のいずれかの方法で実現できます。これにより、埋め込み分析においてエンドユーザーに一貫した体験を継続して提供できます。 リソースとサポート お客様がスムーズに移行できるよう、私たちは全力でサポートいたします。以下のリソースをご利用いただけます： Amazon Quick Suite User Guide における詳細なドキュメント AWS Support を通じたテクニカルサポート AWS アカウントチームによるコンサルテーション 今後の展望 Quick Suite への進化は、意思決定とビジネス成果を導くために必要なコンテキストを提供する、新しい働き方を実現します。AI が組織でのインサイト発見と戦略的な意思決定の方法を変革し続ける中、Quick Suite は安全で実用的な前進の道筋を提供します。私たちは、お客様とこの旅を共にし、これらの機能を活用して組織全体の価値を引き出していく様子を見ることを楽しみにしています。 BI の未来を体験する準備はできましたか？ Quick Suite の 30 日間無料トライアルを利用して、最大 25 ユーザーまでその機能を試すことができます。機能や料金について詳しく知るには Amazon Quick Suite をご覧いただくか、Quick Suite がお客様の組織のデータドリブンな意思決定をどのように変革できるかについて、AWS アカウントチームにお問い合わせください。 著者について Sindhu Chandra は、AWS の Amazon Quick Suite のシニアプロダクトマーケティングマネージャーで、マーケティングとテクノロジーの分野で 10 年以上の経験を持っています。現職に就く前は、Amazon、Uber、Google などのテクノロジー企業でマーケティングの職務を歴任し、クロスチャネルマーケティング戦略を主導してきました。B2B マーケティングをより親しみやすくし、インクルーシブなマーケティング施策を推進することに情熱を注いでいます。仕事以外では、愛犬と遊んだり、さまざまな産地のコーヒーを淹れたりすることを楽しんでいます。

10 月 8 日は、汎用 M インスタンスファミリーに最近追加された Amazon Elastic Compute Cloud (Amazon EC2) M8a インスタンスの提供開始についてお知らせしたいと思います。これらのインスタンスは、 第 5 世代 AMD EPYC (コードネーム「Turin」) プロセッサ を搭載しており、最大周波数は 4.5 GHz です。お客様は、M7a インスタンスよりも最大 30% 高いパフォーマンスと最大 19% 優れたコストパフォーマンスを期待できます。これらのインスタンスは、より広いメモリ帯域幅、改善されたネットワークスループットとストレージスループット、幅広い汎用ワークロードに対応する柔軟な設定オプションも提供します。 M8a の改善点 M8a インスタンスは、vCPU あたりのパフォーマンスが M7a インスタンスよりも最大 30% 優れているため、金融アプリケーション、ゲーム、レンダリング、アプリケーションサーバー、シミュレーションモデリング、中規模のデータストア、アプリケーション開発環境、キャッシュフリートなど、高パフォーマンスと高スループットのメリットを活用する必要がある用途に最適です。 M7a インスタンスよりも 45% 広いメモリ帯域幅を提供し、インメモリデータベース、分散キャッシュ、リアルタイム分析を高速化します。 I/O 要件の高いワークロードには、M8a インスタンスが最大 75 Gbps のネットワーク帯域幅と 60 Gbps の Amazon Elastic Block Store (Amazon EBS) 帯域幅を提供します。これは、前世代から 50% の向上です。これらの機能強化は、迅速なデータ転送と低レイテンシーのネットワーク通信が不可欠な最新のアプリケーションをサポートします。 M8a インスタンスの各 vCPU は物理的な CPU コアに対応するものです。つまり、同時マルチスレッディング (SMT) は行われません。アプリケーションベンチマークでは、M7a インスタンスと比較した M8a インスタンスのパフォーマンスが、 GroovyJVM の場合に最大 60%、 Cassandra の場合に最大 39% 高速になっています。 M8a インスタンスは、ネットワーク帯域幅と EBS 帯域幅間でリソースを割り当てる柔軟性を提供する インスタンス帯域幅設定 (IBC) をサポートしています。IBC は、ネットワーク帯域幅または EBS 帯域幅を最大 25% スケールし、データベースパフォーマンス、クエリ処理、ロギングの速度を向上させる柔軟性をお客様に提供します。 M8a は、10 個の仮想化サイズと 2 つのベアメタルオプション ( metal-24xl と metal-48xl ) で利用でき、小規模なアプリケーションから大規模なエンタープライズワークロードにスケールするデプロイ選択肢を提供します。これらすべての改善は、すべてのインスタンスサイズ全体で低い仮想化オーバーヘッド、一貫的なパフォーマンス、高度なセキュリティを実現する AWS Nitro System を基盤としています。&nbsp;これらのインスタンスは、機能の I/O をオフロードして加速する最新の第 6 世代 AWS Nitro Card を使用して構築されており、全体的なシステムパフォーマンスを向上させます。 M8a インスタンスには複数のサイズがあり、最大で 192 個の vCPU と 768 GiB の RAM を備えています。詳しい仕様は次のとおりです。 M8a vCPU メモリ (GiB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) medium 1 4 最大 12.5 最大 10 large 2 8 最大 12.5 最大 10 xlarge 4 16 最大 12.5 最大 10 2xlarge 8 32 最大 15 最大 10 4xlarge 16 64 最大 15 最大 10 8xlarge 32 128 15 10 12xlarge 48 192 22.5 15 16xlarge 64 256 30 20 24xlarge 96 384 40 30 48xlarge 192 768 75 60 metal-24xl 96 384 40 30 metal-48xl 192 768 75 60 インスタンスのサイズと仕様の完全なリストについては、 Amazon EC2 M8a インスタンスページ を参照してください。 M8a インスタンスを使用する状況 M8a は、コンピューティング、メモリ、ネットワークのバランスを取る必要がある汎用アプリケーションに最適です。M8a インスタンスは、予測可能なパフォーマンスと効率的なスケーリングが重要となる、ウェブやアプリケーションのホスティング、マイクロサービスアーキテクチャ、データベースに理想的なインスタンスです。 これらのインスタンスは SAP 認定を受けており、金融アプリケーションやエンタープライズリソースプランニング (ERP) システムなどのエンタープライズワークロードにも最適です。コスト効率性と柔軟性が求められる開発環境やテスト環境に加えて、インメモリキャッシュや顧客関係管理 (CRM) でも同様の効果を発揮します。こうした汎用性を備えた M8a は、お客様がコストパフォーマンスを向上できるように支援しながら、幅広いワークロードをサポートします。 今すぐご利用いただけます Amazon EC2 M8a インスタンスは、米国東部 (オハイオ)、米国西部 (オレゴン)、欧州 (スペイン) の各 AWS リージョン で 10 月 8 日からご利用いただけます。 M8a インスタンスは、 オンデマンド 、 Savings Plans 、 スポットインスタンス としての購入が可能です。M8a インスタンスは 専有ホスト でも利用できます。詳細については、 Amazon EC2 の料金ページ をご覧ください。 詳細については、 Amazon EC2 M8i インスタンスページ をご覧ください。フィードバックは、 AWS re:Post for EC2 に送信するか、通常の AWS サポート連絡先経由でお寄せください。 – Betty 原文は こちら です。

Amazon Elastic Compute Cloud (Amazon EC2) メモリ最適化 R8i および R8i-flex インスタンス 、ならびに汎用 M8i および M8i-flex インスタンス のリリースに続き、カスタムインテル Xeon 6 プロセッサを搭載し、持続的なオールコア 3.9 GHz ターボ周波数と 2:1 のメモリ対 vCPU 比を備えた、AWS でのみ利用可能なコンピューティング最適化 C8i および C8i-flex インスタンス の一般提供の開始をお知らせします。これらのインスタンスは、クラウドにおける同等の Intel プロセッサの中でも最高のパフォーマンスと最速のメモリ帯域幅を提供します。 C8i および C8i-flex インスタンスは、 C7i および C7i-flex インスタンス と比較して、最大 15% 優れた料金パフォーマンスと 2.5 倍のメモリ帯域幅を提供します。C8i および C8i-flex インスタンスは、C7i および C7i-flex インスタンスと比較して、NGINX ウェブアプリケーションで最大 60%、AI 深層学習レコメンデーションモデルで最大 40%、Memcached ストアで 35% 高速です。 C8i および C8i-flex インスタンスは、ウェブサーバー、キャッシュ、Apache.Kafka、ElasticSearch、バッチ処理、分散分析、ハイパフォーマンスコンピューティング (HPC)、広告配信、高度にスケーラブルなマルチプレイヤーゲーム、動画エンコーディングなど、コンピューティングを多用するワークロードの実行に最適です。 他の第 8 世代インスタンスと同様、これらのインスタンスは新しい第 6 世代 AWS Nitro Card を使用しており、前世代のインスタンスと比較してネットワークと Amazon Elastic Block Storage (Amazon EBS) の帯域幅が最大 2 倍増加しています。また、ネットワークと Amazon EBS 帯域幅の間で 25% の割り当て調整を行う帯域幅設定にも対応しており、データベースのパフォーマンス、クエリ処理、ログ記録速度が向上します。 C8i インスタンス C8i インスタンスは、基盤となる物理ハードウェアへの専用アクセスを提供するベアメタルインスタンスを含め、最大 384 個の vCPU と 768 TB のメモリを提供します。これらのインスタンスは、CPU ベースの推論や、継続的に最大インスタンスサイズまたは高い CPU を必要とする動画ストリーミングなど、コンピューティングを多用するワークロードの実行に役立ちます。 C8i インスタンスの仕様は次のとおりです。 インスタンスサイズ vCPU メモリ (GiB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) c8i.large 2 4 最大 12.5 最大 10 c8i.xlarge 4 8 最大 12.5 最大 10 c8i.2xlarge 8 16 最大 15 最大 10 c8i.4xlarge 16 32 最大 15 最大 10 c8i.8xlarge 32 64 15 10 c8i.12xlarge 48 96 22.5 15 c8i.16xlarge 64 128 30 20 c8i.24xlarge 96 192 40 30 c8i.32xlarge 128 256 50 40 c8i.48xlarge 192 384 75 60 c8i.96xlarge 384 768 100 80 c8i.metal-48xl 192 384 75 60 c8i.metal-96xl 384 768 100 80 C8i-flex インスタンス C8i-flex インスタンスは、C8i インスタンスの低コスト版であり、5% 低い料金で 5% 優れた料金パフォーマンスを実現しています。これらのインスタンスは、最新世代のパフォーマンスから恩恵を享受できるにかかわらず、すべてのコンピューティングリソースを完全に活用していないワークロード向けに設計されています。これらのインスタンスは、95% の確率で最大 CPU パフォーマンスを発揮できます。 C8i-flex インスタンスの仕様は次のとおりです。 インスタンスサイズ vCPU メモリ (GiB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) c8i-flex.large 2 4 最大 12.5 最大 10 c8i-flex.xlarge 4 8 最大 12.5 最大 10 c8i-flex.2xlarge 8 16 最大 15 最大 10 c8i-flex.4xlarge 16 32 最大 15 最大 10 c8i-flex.8xlarge 32 64 最大 15 最大 10 c8i-flex.12xlarge 48 96 最大 22.5 最大 15 c8i-flex.16xlarge 64 128 最大 30 最大 20 現在、旧世代のコンピューティング最適化インスタンスを使用している場合は、アプリケーションやワークロードに変更を加えることなく、C8i-flex インスタンスを採用できます。 今すぐご利用いただけます Amazon EC2 C8i および C8i-flex インスタンスは、現在、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、欧州 (スペイン) の AWS リージョン でご利用いただけます。C8i および C8i-flex インスタンスは、 オンデマンド 、 Savings Plan 、 スポットインスタンス として購入できます。C8i インスタンスは、 ハードウェア専有インスタンス および 専有ホスト での利用も可能です。詳細については、 Amazon EC2 の料金ページ をご覧ください。 Amazon EC2 コンソール で C8i および C8i-flex インスタンスをお試しください。詳細については、 Amazon EC2 C8i インスタンスのページ をご覧ください。また、 AWS re:Post for EC2 に、または通常の AWS サポートの連絡先を通じて、ぜひフィードバックをお寄せください。 – Channy 原文は こちら です。

10 月 6 日より、独自の AWS Key Management Service (AWS KMS) キーを使用して、 AWS IAM アイデンティティセンター の組織インスタンスに保存されているユーザー属性やグループ属性などの ID データを暗号化できるようになりました。 規制の厳しい業界で事業を展開している多くの組織は、暗号化キー管理を完全に制御する必要があります。アイデンティティセンターでは既に AWS 所有キーを使用して保管中のデータを暗号化していますが、監査やコンプライアンスのために独自の暗号化キーを管理する必要があるお客様もいます。 このリリースにより、 カスタマーマネージド KMS キー (CMK) を使用して、アイデンティティセンターの保管中の ID データを暗号化できるようになりました。CMK を使用すると、作成、ローテーション、削除など、キーのライフサイクルを完全に制御できます。 AWS Key Management Service (AWS KMS) キーポリシーと IAM ポリシーを使用して、キーへのきめ細かなアクセスコントロールを設定できるため、認可されたプリンシパルのみが暗号化されたデータにアクセスできるようにするのに役立ちます。起動時には、CMK は IAM アイデンティティセンターインスタンスと同じ AWS アカウントおよびリージョンに存在する必要があります。アイデンティティセンターと KMS の統合により、キーの使用状況を監査するための詳細な AWS CloudTrail ログが提供され、規制コンプライアンス要件を遵守するのに役立ちます。 アイデンティティセンターは、デプロイのニーズに合わせて、単一リージョンキーとマルチリージョンキーの両方をサポートしています。アイデンティティセンターインスタンスは現在単一のリージョンにのみデプロイできますが、会社のポリシーで単一リージョンキーに制限されていない限り、マルチリージョン AWS KMS キーを使用することをお勧めします。マルチリージョンキーは、各リージョンで独立したキーインフラストラクチャを維持しながら、リージョン間で一貫したキーマテリアルを提供します。これにより、暗号化戦略の柔軟性が高まり、デプロイが将来の変化にも対応できるようにするのに役立ちます。 始めましょう CMK を使用してアイデンティティセンターの組織インスタンスの ID データを暗号化するとします。私の組織では、アイデンティティセンターを使用して、 AWS マネージドアプリケーション ( Amazon Q Business や Amazon Athena など) へのアクセスを従業員に付与しています。 現時点では、一部の AWS マネージドアプリケーションは、カスタマーマネージド KMS キーで設定されたアイデンティティセンターでは使用できません。互換性のあるアプリケーションのリストは常に更新されるため、「 AWS managed applications that you can use with Identity Center 」で最新情報をご覧ください。 大まかなプロセスでは、まず AWS KMS で対称カスタマーマネージドキー (CMK) を作成する必要があります。このキーは、暗号化および復号オペレーション用に設定する必要があります。次に、アイデンティティセンター、AWS マネージドアプリケーション、管理者、およびアイデンティティセンターと IAM アイデンティティセンターサービス API にアクセスする必要がある他のプリンシパルにアクセスを付与するキーポリシーを設定します。キーにはポリシーを、IAM プリンシパルには IAM ポリシーを、それぞれアイデンティティセンターの使用方法に応じて定義する必要があります。 サービスドキュメントには、極めて一般的なユースケースをカバーするのに役立つ詳細が記載されています 。 このデモは 3 つのパートに分かれています。まず、AWS KMS でカスタマーマネージドキーを作成し、アイデンティティセンターと AWS マネージドアプリケーションがそのキーを使用することを認可する許可を設定します。次に、AWS アプリケーション管理者など、別の AWS アカウントのキーを使用するプリンシパルの IAM ポリシーを更新します。最後に、アイデンティティセンターがそのキーを使用するように設定します。 パート 1: キーを作成して、許可を定義する まず、AWS KMS で新しい CMK を作成しましょう。 キーは、アイデンティティセンターインスタンスと同じ AWS リージョンおよび AWS アカウントに存在する必要があります。AWS Organizations 内の組織の管理アカウントに、アイデンティティセンターインスタンスとキーを作成する必要があります。 アイデンティティセンターインスタンスと同じリージョンで AWS Key Management Service (AWS KMS) コンソールに移動し、 [キーを作成] を選択します。これでキー作成ウィザードが起動します。 [ステップ 1 – キーを設定する] で、キータイプとして、[対称] (暗号化と復号の両方に使用される単一のキー) または [非対称] (暗号化/復号と署名/検証用のパブリックキーとプライベートキーのペア) を選択します。アイデンティティセンターでは、保管中の暗号化に対称キーが必要です。私は [対称] を選択します。 キーの使用方法については、 [暗号化および復号] を選択します。これにより、キーはデータの暗号化と復号にのみ使用されます。 [高度なオプション] の [キーマテリアルのオリジン] で [KMS – 推奨] を選択し、AWS KMS がキーマテリアルを作成および管理するようにします。 [リージョン] で、[シングルリージョンキー] または [マルチリージョンキー] を選択します。 [マルチリージョンキー] を選択すると、キー管理者は、キーを他のリージョンにレプリケートできます。既に説明したように、アイデンティティセンターでは現時点ではこれは必要ありませんが、設定が将来の変化に対応できるようにするのに役立ちます。なお、シングルリージョンキーを作成した後で、マルチリージョンキーに変換することはできません (ただし、アイデンティティセンターによって使用されるキーを変更することは可能です)。 その後、 [次へ] を選択して、ラベルの追加、管理許可の定義、使用許可の設定、キー作成前の最終設定の確認などの追加の設定ステップに進みます。 [ステップ 2 – ラベルを追加する] で、キーの [エイリアス] 名を入力し、 [次へ] を選択します。 このデモでは、 ドキュメント で提供されているテンプレートを使用してポリシーステートメントを追加することで、キーポリシーを編集します。&nbsp;ステップ 3 とステップ 4 はスキップし、 [ステップ 5 – キーポリシーを編集する] に進みます。 アイデンティティセンターでは、少なくともアイデンティティセンターとその管理者がキーを使用できるようにする許可が必要です。そのため、3 つのポリシーステートメントを追加します。1 つ目と 2 つ目はサービスの管理者を認可し、3 つ目はアイデンティティセンターサービス自体を認可します。 { "Version": "2012-10-17", "Id": "key-consolepolicy-3", "Statement": [ { "Sid": "Allow_IAMIdentityCenter_Admin_to_use_the_KMS_key_via_IdentityCenter_and_IdentityStore", "Effect": "Allow", "Principal": { "AWS": "ARN_OF_YOUR_IDENTITY_CENTER_ADMIN_IAM_ROLE" }, "Action": [ "kms:Decrypt", "kms:Encrypt", "kms:GenerateDataKeyWithoutPlaintext" ], "Resource": "*", "Condition": { "StringLike": { "kms:ViaService": [ "sso.*.amazonaws.com", "identitystore.*.amazonaws.com" ] } } }, { "Sid": "Allow_IdentityCenter_admin_to_describe_the_KMS_key", "Effect": "Allow", "Principal": { "AWS": "ARN_OF_YOUR_IDENTITY_CENTER_ADMIN_IAM_ROLE" }, "Action": "kms:DescribeKey", "Resource": "*" }, { "Sid": "Allow_IdentityCenter_and_IdentityStore_to_use_the_KMS_key", "Effect": "Allow", "Principal": { "Service": [ "sso.amazonaws.com", "identitystore.amazonaws.com" ] }, "Action": [ "kms:Decrypt", "kms:ReEncryptTo", "kms:ReEncryptFrom", "kms:GenerateDataKeyWithoutPlaintext" ], "Resource": "*", "Condition": { "StringEquals": { "aws:SourceAccount": "&lt;Identity Center Account ID&gt;" } } }, { "Sid": "Allow_IdentityCenter_and_IdentityStore_to_describe_the_KMS_key", "Effect": "Allow", "Principal": { "Service": [ "sso.amazonaws.com", "identitystore.amazonaws.com" ] }, "Action": [ "kms:DescribeKey" ], "Resource": "*" } ] } また、AWS マネージドアプリケーションの使用という私のユースケースを許可するために、ポリシーステートメントをさらに追加する必要があります。これらの 2 つのポリシーステートメントを追加して、AWS マネージドアプリケーションとその管理者が KMS キーを使用することを認可します。 このドキュメントには、追加のユースケースとそれぞれのポリシーがリストされています 。 { "Sid": "Allow_AWS_app_admins_in_the_same_AWS_organization_to_use_the_KMS_key", "Effect": "Allow", "Principal": "*", "Action": [ "kms:Decrypt" ], "Resource": "*", "Condition": { "StringEquals" : { "aws:PrincipalOrgID": "MY_ORG_ID (format: o-xxxxxxxx)" }, "StringLike": { "kms:ViaService": [ "sso.*.amazonaws.com", "identitystore.*.amazonaws.com" ] } } }, { "Sid": "Allow_managed_apps_to_use_the_KMS_Key", "Effect": "Allow", "Principal": "*", "Action": [ "kms:Decrypt" ], "Resource": "*", "Condition": { "Bool": { "aws:PrincipalIsAWSService": "true" }, "StringLike": { "kms:ViaService": [ "sso.*.amazonaws.com", "identitystore.*.amazonaws.com" ] }, "StringEquals": { "aws:SourceOrgID": "MY_ORG_ID (format: o-xxxxxxxx)" } } } キーの使用を特定のアイデンティティセンターインスタンス、特定のアプリケーションインスタンス、または特定のアプリケーション管理者にさらに制限することもできます。 このドキュメントには、お客様のユースケース向けの高度なキーポリシーの例が記載されています 。 許可セットの再作成時に IAM ロール名が変更されないようにするには、「 Custom trust policy example 」で説明されている方法を使用します。 パート 2: IAM ポリシーを更新して、別の AWS アカウントからの KMS キーの使用を許可する アイデンティティセンターの委任された管理者や AWS アプリケーション管理者など、別の AWS アカウントからアイデンティティセンターサービス API を使用するすべての IAM プリンシパルには、これらの API 経由での KMS キーの使用を許可する IAM ポリシーステートメントが必要です。 新しいポリシーを作成し、ユースケースに関連する IAM ロールにそのポリシーをアタッチすることで、キーにアクセスするための許可を付与します。これらのステートメントを IAM ロールの既存の ID ベースのポリシーに追加することもできます。 これを行うには、キーを作成した後、その ARN を見つけて、以下のテンプレートの key_ARN を置き換えます。その後、そのポリシーをマネージドアプリケーション管理者の IAM プリンシパルにアタッチします。このドキュメントでは、 キーにアクセスするための許可をアイデンティティセンターの委任された管理者に付与する IAM ポリシー についても説明しています。 マネージドアプリケーション管理者向けの例を次に示します: { "Sid": "Allow_app_admins_to_use_the_KMS_key_via_IdentityCenter_and_IdentityStore", "Effect": "Allow", "Action": "kms:Decrypt", "Resource": "&lt;key_ARN&gt;", "Condition": { "StringLike": { "kms:ViaService": [ "sso.*.amazonaws.com", "identitystore.*.amazonaws.com" ] } } } ドキュメントでは、最も一般的なユースケース向けの IAM ポリシーテンプレートを共有しています 。 パート 3: キーを使用するように IAM アイデンティティセンターを設定する CMK は、アイデンティティセンターの組織インスタンスを有効にする際に、または既存のインスタンスで設定できます。また、CMK を切り替えたり、AWS 所有キーに戻したりすることで、いつでも暗号化設定を変更できます。 KMS キーの許可を正しく設定しないと、アイデンティティセンターの運用が中断され、アイデンティティセンターを通じた AWS マネージドアプリケーションおよびアカウントへのアクセスが中断される可能性があることにご留意ください。この最後のステップに慎重に進み、ドキュメントをよく読み、理解するようにしてください。 CMK を作成して設定したら、アイデンティティセンターを有効にする際に [高度な設定] でその CMK を選択できます。 AWS マネジメントコンソールを使用して既存のアイデンティティセンターインスタンスで CMK を設定するには、まず AWS マネジメントコンソール のアイデンティティセンターのセクションに移動します。そこで、ナビゲーションペインから [設定] を選択し、 [管理] タブを選択して、 [IAM アイデンティティセンターの保管中のデータの暗号化用のキー] セクションで [暗号化を管理] を選択します。 いつでも、同じ AWS アカウントから別の CMK を選択したり、AWS マネージドキーに切り替えて戻したりできます。 [保存] を選択すると、キーの変更プロセスが完了するまで数秒かかります。移行中もすべてのサービス機能は中断なく使用できます。何らかの理由でアイデンティティセンターが新しいキーにアクセスできない場合は、エラーメッセージが返され、アイデンティティセンターは引き続き現在のキーを使用し、既に暗号化で使用されている暗号化メカニズムで ID データを暗号化し続けます。 留意事項 作成した暗号化キーは、アイデンティティセンターの重要なコンポーネントとなります。保管中の ID 属性を暗号化するために独自のマネージドキーを使用することを選択する場合は、次の点を確認する必要があります。 KMS キーを使用するために 必要な許可 を設定しましたか? 適切な許可がない場合、CMK を有効にすると失敗したり、IAM アイデンティティセンターの管理や AWS マネージドアプリケーションが中断したりする可能性があります。 AWS マネージドアプリケーションが CMK キーと互換性があることを確認しましたか? 互換性のあるアプリケーションの一覧については、「 AWS managed applications that you can use with IAM Identity Center 」をご覧ください。 CMK と互換性のない AWS マネージドアプリケーションによって使用されるアイデンティティセンターのために CMK を有効にすると、それらのアプリケーションの運用が中断されます。互換性のないアプリケーションがある場合は、続行しないでください。 組織は、アイデンティティセンターおよび Identity Store API を利用するために追加の IAM ロール設定を必要とする AWS マネージドアプリケーションを使用していますか? 既にデプロイされているこのような各 AWS マネージドアプリケーションについて、マネージドアプリケーションのユーザーガイドを読み、IAM アイデンティティセンターの使用のための、更新された KMS キーの許可を確認し、指示に従ってそれらの許可を更新して、アプリケーションが中断しないようにしてください。 簡潔にするために、この記事の KMS キーポリシーステートメントでは、 暗号化コンテキスト を省略しています。暗号化コンテキストを使用すると、 特定のインスタンスを含むアイデンティティセンターへの KMS キーの使用を制限 できます。本番のシナリオでは、アイデンティティセンターに次のような条件を追加できます: "Condition": { "StringLike": { "kms:EncryptionContext:aws:sso:instance-arn": "${identity_center_arn}", "kms:ViaService": "sso.*.amazonaws.com" } } あるいは、Identity Store に次のような条件を追加できます: "Condition": { "StringLike": { "kms:EncryptionContext:aws:identitystore:identitystore-arn": "${identity_store_arn}", "kms:ViaService": "identitystore.*.amazonaws.com" } } 料金と利用可能なリージョン キーストレージと API の使用には、AWS KMS の標準料金が適用されます。アイデンティティセンターは引き続き追加料金なしでご利用いただけます。 この機能は、すべての AWS 商用リージョン、AWS GovCloud (米国)、および AWS 中国リージョンでご利用いただけます。詳細については、「 IAM アイデンティティセンターユーザーガイド 」にアクセスしてください。 セキュリティとコンプライアンスの要件を満たすために、この新しい機能をどのように使用するのかについて、ぜひお聞かせください。 – seb 原文は こちら です。

本稿は、JALデジタル株式会社システムマネジメント本部ハイブリッドクラウド基盤部クラウド基盤運営グループの梅本様、北様からご寄稿いただきました。 はじめに JALデジタル株式会社のプラットフォームチームでは、JALグループのITシステムとして必要な設計・運用を満たすためのAWSアカウントを「 CIEL/S 」(※1)として提供しています。 今回私たちのチームでは、複数のAWSアカウントにおける AWS サポートとのやり取りを組織全体で効率的に活用するため、Amazon Bedrock を活用したナレッジ集約のソリューションを開発しました。 本記事では、AWS サポート問い合わせ内容の自動収集、AI要約、ServiceNow（※2）への連携を実現したアーキテクチャについて解説します。 ※1：リンク先の資料内におけるJALインフォテックは2025年4月、JALデジタルに社名変更しています。 ※2：JALグループではITSMツールとしてServiceNowを利用しています。 導入背景 現在JALグループで利用しているAWSアカウント数は数百アカウントあり、エンタープライズサポートを活用して24時間365日の運用を実現しています。しかし、利用していく中でいくつかの課題が発生しました。 アカウントの制約 各アカウントから行った問い合わせ内容は、そのアカウントでしか閲覧もできません。そのため、複数のAWSアカウントでのサポート問い合わせ内容が分散することになり、組織全体での知見共有が困難となっていました。また、私たちのチームに「○○という内容で過去に問い合わせしているアカウントはいないか」と質問があっても、一元管理できていないため探すのが困難でした。 ナレッジ共有の壁 問い合わせした内容をドキュメント化して共有する場合、CIEL/SのAWSアカウント全体で平均60件/月の問い合わせが発生しており、それらを手動でナレッジとして作成することはコストがかかりすぎてしまいます。また問い合わせ履歴が多くなってしまったサポートケースをそのまま転記するだけでは、読み手の負担も大きいためある程度要約をする必要がありますが、要約作成もナレッジ化のハードルとなっていました。 AWS サポートケース保管期限の制約 解決から２年経過した問い合わせはAWSコンソール上から削除されるため、それ以上過去に遡って探すことができませんでした。 ソリューション概要 上記課題を解決するために、自動的にAWS サポートケース の集約と Amazon Bedrock を活用した問い合わせ内容の要約作成を行うソリューションの開発を行いました。開発したソリューションは、2種類のAWSアカウントと、3つの主要なコンポーネントで構成されています。 AWSアカウントの種類 集約実行アカウント 問い合わせ内容を集約し、ServiceNowに連携するAWSアカウント 集約対象アカウント 問い合わせを集約させたいAWSアカウント コンポーネント 既存の AWS サポートケース の集約（集約実行アカウント） 本ソリューション導入前に解決済みとなっている AWS サポートケース を集約させるための処理 Amazon Bedrockを利用して問い合わせ内容の要約を作成 新規の AWS サポートケース の集約（集約実行アカウント） 本ソリューション導入後に解決済みとなった AWS サポートケース を自動で集約させるための処理 Amazon Bedrockを利用して問い合わせ内容の要約を作成 集約した問い合わせをServiceNowに連携する処理 AWS サポートケース の ResolveCase を検知（集約対象アカウント） 集約対象AWSアカウントで解決済みとなった AWS サポートケース を集約実行アカウントに連携する処理 AWS Cloudformation StackSets を利用して複数AWSアカウントに Amazon EventBridge Rule を展開 AWS サポートケースの検索と表示（ServiceNow） 集約実行アカウントから連携された問い合わせの表示 AWSサポートケースの内容検索 アーキテクチャ詳細 既存の AWS サポートケース の集約の処理については、一度のみの処理となるため、メインとなる新規の AWS サポートケース の集約について詳細を解説します。 Step 1: サポートケースが解決したイベント検知（集約対象AWSアカウント） 集約実行アカウントの Event Bus をターゲットとした Amazon EventBrige Rule を作成します AWS サポートの解決処理をトリガーとして、Amazon EventBridge Ruleのイベントパターンに定義します { "detail-type": ["Support Case Update"], "source": ["aws.support"], "detail": { "communication-id": [""], "event-name": ["ResolveCase"] } } Step 2: Step 1 の検知を元にLambdaを実行（集約実行AWSアカウント） 集約対象AWSアカウントに対して、AWS Support API ( DescribeCases 、 DescribeSeverityLevels 、 DescribeServices 、 DescribeCommunications )を実行してサポートケース情報を取得 Amazon Bedrock API ( Converse ) を実行し サポートケース会話情報を要約 Amazon DynamoDB に登録 Step 3: ServiceNow連携（集約実行AWSアカウント） DynamoDB Stream から AWS Lambda 関数を実行 ServiceNow への認証処理 ServiceNow への記事の登録処理の実行 ①AWS サポートケースとServiceNow上のナレッジとのマッピング ②ServiceNow上でナレッジ検索する際イメージ 実装ポイント Amazon EventBridgeのリージョン制約対応 AWS サポートは us-east-1 リージョンのグローバルリソースであるため、EventBridge Rule の配置および Lambda 関数のデプロイも us-east-1 にまとめることが推奨されます。 セキュリティ権限の最小化 各AWSアカウントに必要な IAMロール・ポリシーは最小権限の原則に従い、AWS サポートケースの読み取り権限や EventBridge Rule の作成権限だけに限定することで安全性を確保してください。 システムプロンプトの設計 読み手が短時間で問題の本質と解決策を把握できるよう、要約生成のためのプロンプトは、以下のポイントを押さえて設計しています。 ユーザーが直面した問題、サポートの具体的な解決策、成功のための考慮事項を明確に区別して要約させる 日本語で簡潔に300文字以内に収める文字数制限を設定し、不要な情報を排除 「問い合わせ内容」「解決策」「考慮事項」という出力フォーマットを厳格に指定し、一貫性のある要約を実現 ナレッジ格納先にServiceNowを選定 本ソリューション実装前から、プラットフォームに関するナレッジを ServiceNow 上に乗せていた 標準となるナレッジの型があり、UI を一から作成する必要が無い 検索機能も ServiceNow 標準のものを利用できる(AIを用いた検索等は今後実装予定) ※AWS Support APIの利用条件 AWS Support APIの利用にはビジネスサポート以上のサポートプラン（ビジネス、エンタープライズ On-Ramp、エンタープライズ）が必要です。JALグループではエンタープライズサポートを利用しているため、本ソリューションで必要となるAWS Support APIの全機能を活用することができます。 導入効果 本ソリューションの導入により、以下の効果を実現しました。 ナレッジ共有の効率化 複数アカウントの問い合わせ内容を一元管理することで、組織全体の知見を活用できるようになりました。またAI要約を入れることで、すべてのやり取りを読む前に自分たちが探している情報かどうか判断することができるようになりました。 運用工数の削減 手動でのドキュメントや要約作成が不要になることで、ナレッジ作成に伴う運用コストを大幅に削減させることができました。また ServiceNow への自動連携により転記作業を削減した上で、解決済みになった問い合わせをリアルタイムでナレッジ化することが可能になりました。 問題解決の迅速化 一元管理により、各アカウントの担当者が組織全体の知見を活用して、調べたい情報や類似事例を直接検索-閲覧できるようになりました。これにより、プラットフォームチームやAWSサポートに問い合わせて回答を待つ時間を省略し、素早い問題解決が可能になりました。 まとめ AWS Support APIを利用した問い合わせ内容の取得と、Amazon Bedrock を活用した問い合わせ内容の要約作成を組み合わせることで、組織全体のナレッジマネジメントを大幅に改善することができました。AWS Lambda、 Amazon EventBridge、Amazon DynamoDB などAWSのマネージドサービスを最大限に活用、AWS利用料を最小限に抑えるアーキテクチャを実現しました。 今後は、要約精度の向上や、より高度な分析機能の追加を検討しており、継続的な改善を進めていく予定です。 著者略歴 JALデジタル株式会社 システムマネジメント本部ハイブリッドクラウド基盤部クラウド基盤運営グループ 梅本征宏 2019年入社　旅客系システムの開発・維持管理業務を担当。 2022年に現部署に異動して以降、Platform Engineeringを推進。 JALデジタル株式会社 システムマネジメント本部ハイブリッドクラウド基盤部クラウド基盤運営グループ 北修哉 顧客系システムの開発を担当。 2024年に現部署に異動し、プラットフォームチームの運用高度化を推進。