本記事は、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年に現部署に異動し、プラットフォームチームの運用高度化を推進。

はじめに データドリブンエンタープライズの環境では、組織は 2 つの重要な要件を満たすデータベースソリューションを必要としています。1 つは、トランザクション処理と分析処理の両方のワークロードを扱える高性能性、もう 1 つはセキュリティとコンプライアンス要件への適合です。AWS 上で運用される SAP HANA Cloud は、 SAP Business Technology Platform（ SAP BTP ） のサービスの一つであり、フルマネージド型のクラウドネイティブな Database-as-a-Service として、これらの要件に応えます。 SAP HANA Cloud は主に 2 つの用途で活用されています。1つは、ERP、CRM、HR、ロジシティックスなどの基幹システムを単一の高速プラットフォームで支えること。もう 1 つは、高度な分析とデータアプリケーションを通じて、実践的なビジネスイノベーションを推進・支援することです。また、SAP HANA Cloud は、SAP Analytics Cloud、SAP Datasphere、SAP Cloud Application Programming Model（CAP）で開発されたアプリケーションなどの、様々な SAP BTP サービスの基盤でもあります。 このブログでは、AWS PrivateLink を通じて SAP HANA Cloud のセキュリティと接続性を強化することにフォーカスし、高性能と信頼性を維持しながらプライベートで安全なデータベースアクセスを必要とする組織の重要なニーズに対応します。 AWS が SAP HANA Cloud の稼働基盤として選ばれた理由 SAP HANA Cloud は&nbsp; AWS Graviton プロセッサーによって対応しており、分析ワークロードで計算性能が最大 30% 向上しを提供し、計算コストを 15% 削減し、同等の EC2 インスタンスと比較して最大 60% 消費エネルギーを抑えることができます 。AWS Graviton ベースのインスタンスに移行することで、SAP は SAP HANA Cloud ワークロードの計算カーボンフットプリントを約 45% 削減できると見込んでおり、炭素排出量削減を支援する Amazon の The Climate Pledge の署名企業としての取り組みを支持します。SAP は将来的に AWS Graviton の使用を拡大し、これらの性能向上、コスト削減、エネルギー効率を継続的に活用する計画です。したがって、AWS 上の SAP HANA Cloud を使用するお客様は、性能向上のメリットを享受しながら、カーボンフットプリントを削減も実現できます。 AWS 上の SAP HANA Cloud への接続 SAP HANA Cloud に接続する際、オンプレミスまたは他のクラウド環境にあるクライアントアプリケーションやユーザーは、インターネットアクセス可能なエンドポイントを通じてパブリック API を使用してデータベースにセキュアにアクセスできます。 図1：デフォルトのパブリックエンドポイント経由でのSAP HANA Cloudへの接続 金融サービス、ヘルスケア、政府機関などの規制産業のお客様で、HIPAA、EU/US Privacy Shield、PCI DSS などの規制により、パブリックエンドポイントの使用が制限される場合があります。この場合、SAP HANA Cloud と AWS PrivateLink を組み合わせることをお勧めします。これにより、AWS の安全なネットワークインフラストラクチャを活用しながら、データベースとアプリケーション間の安全かつプライベートな通信を実現できます。また、プライベートIPアドレス範囲（RFC 1918）を使用することで、サービスへの攻撃リスクが低減できます。 このブログでは、AWS PrivateLink を使用したプライベート接続オプションを活用して、SAP HANA Cloud のデータ転送時のセキュリティを強化する方法について解説します。PrivateLink は、AWS 環境と SAP HANA Cloud 間の安全でプライベートなネットワーク接続を確立でき、パブリックインターネットへの通信を回避し、不正アクセスのリスクを抑制することができます。 AWS PrivateLink とは AWS PrivateLink を使うことにで、AWSサービス（ネットワーク、コンピューティング、サーバーレスアプリケーション、AI など）と SAP BTP サービス間の通信をインターネット経由せず、プライベート接続を実現できます。また、AWS PrivateLink を使用して、Direct Connect または VPN 経由で Amazon Virtual Private Cloud（VPC）に接続されたオンプレミスネットワーク間の安全でプライベートな接続を提供することもでき、パブリックネットワークやIPアドレスを完全に回避できます。 AWS PrivateLink により、異なるアカウントやVPC間でのサービス接続が簡単になり、ネットワークアーキテクチャを大幅に簡素化します。VPC 内のプライベート IP アドレスを持つ Elastic Network Interface であるインターフェースエンドポイント経由で、AWS サービス、他の AWS アカウントで稼働しているサービス（エンドポイントサービス）、AWS Marketplace パートナーサービスに接続できます。 インターフェースエンドポイントは、VPC のサブネット内の Elastic Network Interface と IP アドレスを使用して、VPC 内に直接作成されます。プロバイダーとコンシューマーは、IPアドレスの重複を避けるためにネットワークセグメントや CIDR ブロックを調整する必要がありません。VPC ピアリングや AWS Transit Gateway 経由の接続は通信に必要ありません。セキュリティグループを関連付け、AWS サービスのインターフェースエンドポイントにエンドポイントポリシーを設定することで、指定されたサービスへのアクセスを制御できます。AWS PrivateLink を使用すると、 AWS サービス や他の VPC が提供する他のサービスに、AWS ネットワーク内のプライベート接続を通じて安全にアクセスできます。すべてのネットワークトラフィックはグローバル AWS バックボーン上に留まり、パブリックインターネットを経由することはありません。 図2：AWS PrivateLink 経由での SAP HANA Cloud への接続 SAP HANA Cloudと AWS PrivateLink との接続するメリットをより理解するために、実際のシナリオでそのメリットを示すいくつかの実用的なユースケースを探ってみましょう。 SAP HANA Cloud と AWS PrivateLink を使うユースケース データセキュリティが重要なビジネス環境において、AWS PrivateLink の実装は、データ転送中の機密情報を保護するために不可欠です。AWS のインフラストラクチャが提供するプライベート IP エンドポイントサービスは、重要なセキュリティレイヤーとして機能し、ビジネスへ重大な影響をもたらす可能性のあるセキュリティ侵害を防ぐのに役立ちます。この統合は、現代のクラウドアーキテクチャの複雑な要件に対応するエンタープライズクラスのセキュリティソリューションを提供することに対する AWS のコミットメントを示しています。 ユースケース 1 – SAP HANA Cloud 管理アクセスセキュリティ SAP HANA Cloud PrivateLink を実装する重要なユースケースの 1 つは、安全なデータベースアクセスへの対応です。企業の環境では、オフィスで働くデータベース管理者と開発者は、テーブル管理、メンテナンス、開発タスクなどの重要タスクを実行するために SAP HANA Cloud への定期的なアクセスが必要です。これらの技術者は、一般ユーザーとは異なり、タスクに必要な広範なデータベース権限を付与されているため、接続セキュリティが特に重要になります。 図3に示すように、 AWS PrivateLinkを使用した SAP HANA Cloud は、組織が機密データの転送をプライベートネットワークでのみに制限できるようにする完璧なソリューションを提供します。データベース操作へのプライベートアクセスは、運用効率を維持しながらパブリック IP を使わず、厳格なアクセス制御を通じて組織のセキュリティを強化します。 図3：SAP HANA Cloud 管理アクセスセキュリティ ユースケース 2 – セキュアなデータプラットフォーム統合：SAP HANA Cloud と AWS サービス SAP HANA Cloud と AWS PrivateLink の重要なユースケースは、AWS 上でデータプラットフォームを構築し、SAP HANA Cloud データを分析エコシステムに統合するケースです。AWS データプラットフォーム内で SAP HANA Cloud データにアクセスするには、主に2つの方法があります。AWS Glue ETL ジョブを使用してデータを抽出しAmazon S3 にロードする方法、またはフェデレーションクエリに Amazon Athena SAP HANA コネクタを使用する方法です。両方のアプローチには、AWS サービスと SAP HANA Cloud 間の安全で信頼性の高い接続が必要です。 これらのデータ統合パターンを実装する際、機密ビジネスデータがシステム間で転送されるため、セキュリティが重要になります。図4は、AWS PrivateLinkが必要なセキュアな接続レイヤーを提供することを示しています。AWS サービス（AWS Glue や Amazon Athena など）と SAP HANA Cloud 間のすべてのデータ転送とクエリがプライベートネットワークチャネルを介して行われ、パブリックインターネットへの通信を介さず、エンタープライズデータ統合シナリオの厳格なセキュリティ要件を満たします。 図4：セキュアなデータプラットフォーム統合：SAP HANA Cloud と AWS サービス AWS PrivateLink を使用した SAP HANA Cloud の設定方法 ユースケース 1 のエンタープライズグレードの SAP HANA Cloud アクセスの設定手順を説明します。このブログでは、設定について SAP HANA Cloud 管理ガイド を参照しました。この設定は SAP BTP 有料ティアアカウントで利用可能です。このブログ執筆時点では、データレイクインスタンス用の SAP HANA Cloud PrivateLink はAWS でのみ利用可能であり、 SAP HANA Cloud PrivateLink ドキュメント に記載されているように、リージョン内の接続のみをサポートしています。以下は設定手順の概要です。 SAP HANA Cloud で AWS PrivateLink Endpoint ID を有効化 AWS VPC で VPC エンドポイントを設定 AWS VPC エンドポイントを HANA Cloud インスタンスの許可リストに追加 Amazon Route53 でプライベートホストゾーンを設定 VPC 内から HANA Cloud へのプライベートルーティングをテスト インバウンド DNS クエリ転送用のリゾルバーを設定（RISE またはオンプレミスネットワークでの使用例1でのみ必要） 各ステップの詳細は以下の通りです。さらなるステップバイステップガイダンスについては、 このワークショップ のラボを参照してください。 1. SAP HANA Cloud で AWS PrivateLink Endpoint ID を有効化 SAP HANA Cloud の管理画面で、設定したい HANA Cloud インスタンスを選択し、 View Configuration をクリックします。 図5：SAP HANA Cloud – 設定を表示 接続タブで、AWS PrivateLink Endpoint ID を有効にするボタンをオンにします。これにより、AWS VPC への接続を設定するための PrivateLink Endpoint ID を取得できます。 許可する接続 で、「この BTP リージョンの Cloud Foundry からの IP アドレスのみを許可」または「特定の IP アドレスと IP 範囲を許可（BTP の Cloud Foundry に加えて）」を選択して、すべてのトラフィックがプライベート接続を通過するように制御します。 図6：SAP HANA Cloud – 接続 2. AWS VPC で VPCエンドポイントを設定 このステップでは、AWS VPC で VPC エンドポイントとセキュリティグループを設定して、Amazon VPC からこのエンドポイント経由で HANA Cloud へのアクセスを許可します。ご自身のAWS アカウントに VPC が設定されていない場合は、 Amazon VPC ドキュメント を参照して VPC を作成してください。SAP HANA Cloud インスタンスの設定タブで AWS PrivateLink Endpoint Service ID をコピーします。 図7: SAP HANA Cloud – PrivateLink Endpoint Service IDs AWS コンソールで、Amazon VPC サービスにアクセスし、 パートナーサービス用の VPC インターフェースエンドポイント を作成します。エンドポイント作成画面で、エンドポイントの名前を入力し、タイプに「PrivateLink Ready partner services」を選択します。サービス設定で、HANA Cloud インスタンスの AWS PrivateLink Endpoint Service ID をサービス名ボックスに入力します。次に、サービス確認ボタンをクリックします。 図 8: Amazon VPC – VPC エンドポイント作成 (1) 「サービス名が確認されました」という成功メッセージが表示されたら、ネットワーク設定を選択できるようになります。ネットワーク設定で、エンドポイントを作成したい VPC とアベイラビリティーゾーン、サブネットを選択します。SAP HANA Cloud インスタンスが複数の AZ で利用可能な場合、VPC で複数の AZ とサブネットを選択できます。 図 9: Amazon VPC – VPC エンドポイント作成 (2) このエンドポイントに、 https トラフィックを許可するセキュリティグループを割り当ててください。このブログでは、同 VPC 内のIP アドレス CIDR からの https トラフィックを許可するインバウンドルールを持つ https-from-sap-vpc という名前のセキュリティグループを作成しました。 図 10: Amazon VPC – VPC エンドポイント作成 (3) VPCエンドポイントが作成され、ステータスが「使用可能」になったら、エンドポイントの詳細ページからエンドポイント ID をコピーしてください。この ID は、次のステップで HANA Cloud の設定に使用します。DNS ネームをコピーして、後で Route 53 での DNS 設定時に使用します。プライベート IPv4 アドレスをメモしておいてください。これは、プライベートルーティングをテストする最後のステップで確認することができます。 図 11: Amazon VPC – VPC エンドポイントの確認 3. Amazon VPC エンドポイントを HANA Cloud インスタンスの許可リストに追加 HANA Cloud 管理画面に戻り、HANA Cloud インスタンスの設定を開きます。接続設定画面で、作成した VPC エンドポイント ID を許可リストに追加します。これにより、先ほどの VPC から作成された VPC エンドポイントで HANA Cloud PrivateLink エンドポイントサービスに接続できるようになります。 Figure 12: SAP HANA Cloud – VPC エンドポイント ID 許可 4. Amazon Route53 でプライベートホストゾーンを設定 このステップでは、VPC 用の Amazon Route 53 のプライベートホストゾーンを設定し、HANA Cloud インスタンスへのトラフィックを VPC エンドポイントに向ける DNS レコードを作成します。SAP HANA Cloud 接続の詳細から、SQL エンドポイントアドレスとランドスケープアドレスを確認します。Route 53 DNS 設定と接続テストで使用するため、これらのアドレスをメモしてください。 図 13: SAP HANA Cloud – 接続情報確認 Amazon Route 53 ホストゾーン設定で、以下のように値を設定します。 – ドメイン名として HANA Cloud ランドスケープ名を入力 – タイプとしてプライベートホストゾーンを選択 – ホストゾーンを VPC に関連付けるために VPC ID を選択 次に、ホストゾーンの作成ボタンをクリックします。 図 14: Amazon Route 53 – ホストゾーン作成 作成されたホストゾーン画面で、すべての HANA Cloud へのトラフィックを VPC エンドポイントにルーティングする新しい DNS レコードを作成します。 図 15: Amazon Route 53 – DNS レコード作成 5. VPC 内から HANA Cloud へのプライベートルーティングをテスト 設定完了後、VPC 内の EC2 インスタンスから dig または nslookup コマンドを実行して、HANA Cloud インスタンスへのトラフィックが VPC エンドポイントのプライベート IP アドレスに向かっていることを確認します。HANA Cloud エンドポイント URL でこれらのコマンドを実行すると、VPC エンドポイントのプライベート IP アドレスが応答されます。 図 16: コマンドでプライベートルーティングを確認 hdbsql コマンドで HANA Cloud エンドポイントへのデータベース接続を確認します。 図 17: hdbsql コマンドでデータベース接続を確認 6. インバウンド DNS クエリ転送用のリゾルバーを設定（RISE またはオンプレミスネットワークでのユースケース 1 でのみ必要） Route 53 プライベートホストゾーンは AWS アカウントの VPC 内に設定されているため、この VPC からのトラフィックにのみ影響します。ユースケース 1 で、RISE またはオンプレミスネットワークから HANA Cloud へのトラフィックも VPC エンドポイントを通過させたい場合は、 Route 53 インバウンドリゾルバー を使用し、ネットワークからこのリゾルバーに DNS を転送する必要があります。 詳細な手順は Route 53 ドキュメント を参照してください。下記の画面は、VPC 内に作成されたインバウンドエンドポイントのサンプルで、2 つのサブネットに 2 つのプライベートIPアドレスが割り当てられています。これらの IP アドレスは、RISE やオンプレミスネットワークでの DNS 設定に使用することができます。 図 18: Amazon Route 53 – インバウンドリゾルバー 高可用性 AWS PrivateLink の高可用性アーキテクチャは、複数のアベイラビリティーゾーン（ AZ ）を通じて堅牢で回復力のある接続を提供し、重要なビジネス運用のための継続的なサービス可用性を確保します。図 19 は、複数の AZ にまたがるエンドポイントネットワークインターフェースで AWS PrivateLink を実装することで、自動フェイルオーバー機能を実現し、ネットワークアーキテクチャにおける単一障害点を排除できることを示しています。この分散設計により、ある AZ が使用不可能になった場合でも、トラフィックは自動的に正常なエンドポイントにルーティングされ、アプリケーションやサービスへのシームレスな接続が維持されます。 これにより、アプリケーションの信頼性が向上し、ダウンタイムのリスクが軽減され、パフォーマンスが安定するとともに、プライベート接続のセキュリティ上の利点も得られます。さらに、AWS PrivateLink と Amazon Route 53 DNS サービスとの統合により、インテリジェントなルーティングとヘルスチェックが可能となり、ソリューション全体の可用性と耐障害性が向上します。この包括的な高可用性の実装により、セキュアでプライベートなネットワーク通信を維持しながら、厳格なビジネス継続性要件を満たすことができます。 以下のアーキテクチャは、Network Load Balancer を通じて 2 つの AZ に跨って HA がどのように機能するかを説明しています。 図19：高可用性を備えた AWS PrivateLink 価格例 このブログの公開時点では、SAP HANA Cloud で AWS PrivateLink を有効にする際、SAP BTP で追加料金は発生しません。SAP が Network Load Balancer の実装と有効化を実施します。ご自身の AWS アカウントで作成されたリソースに対してのみ課金されます。 例えば、高可用性ありとなしでのお客様の AWS アカウントでの AWS PrivateLink のコストを比較してみましょう。両方のオプションは、この AWS 料金計算ツールリンク にあります。 図20: 料金の例 次のステップ AWS PrivateLink の詳細については、AWS ドキュメント 「AWS PrivateLink とは？」 、 「AWS PrivateLink を使用して VPC をサービスに接続する」 、およびAWSホワイトペーパー 「AWS PrivateLink」 を参照してください。 同様に、詳細については SAP HANA Cloud オンラインドキュメント と&nbsp; SAP HANA Cloud データベース管理ガイド を参照してください。 AWS アカウントチームと AWS サポートチャネルに加えて、AWS コミュニティ向けの Q&amp;A 体験である re:Post を開始しました。AWS for SAP ソリューションアーキテクチャチームは、お客様とパートナーを支援するために回答できる議論と質問について、AWS for SAP トピックを定期的に監視しています。質問がサポート関連でない場合は、re:Post での議論に参加し、コミュニティの知識ベースに貢献することを検討してください。 クレジット このブログへの貢献に対して、Derek Ewell、Ferry Mulyadi、Diego Lombardini、Eneko Bilbaoに感謝いたします。 翻訳は Specialist SA トゥアンが担当しました。原文は こちら です。

9 月 29 日週、SWE-Bench によって世界最高のコーディングモデルと評価されている Anthropic の Claude Sonnet 4.5 が、 Amazon Q コマンドラインインターフェイス (CLI) と Kiro でご利用いただけるようになりました。このことに高揚感を覚えている理由は 2 つあります: まず、私は数週間前に世界中のお客様と 4 日間にわたって集中的に AI 支援開発ワークショップを開催し、 Amazon Q CLI がデベロッパーの生産性をいかに向上させるかを実際に体験しました。ワークショップ中、お客様は Amazon Q CLI を使用して 1 日でアプリケーションに新しい特徴量を追加することができました。これは従来であれば少なくとも 2 週間はかかっていた作業です。Amazon Q CLI で Anthropic の Claude Sonnet 4.5 が使用できるようになることで、デベロッパーの生産性がさらに向上すると確信しています。 2 つ目として、私は AWS re:Invent 2025 でのコードトークの準備を始めました。このコードトークでは、私と共同講演者が Kiro を使用してレガシーコードベースをモダナイズするライブコーディングを行います。Kiro で Anthropic の Claude Sonnet 4.5 を使用してライブデモを作成するのが待ちきれません。このデモや、クラウドと AI に関する 1,000 を超える他のセッションをご覧になりたい方は、12 月 1 日から 5 日までラスベガスで開催される AWS re:Invent 2025 にぜひご参加ください。 9 月 29 日週のリリース 私が注目したリリースをいくつかご紹介します。 Amazon Bedrock で Claude Sonnet 4.5 が使用可能に – コーディングと複雑なエージェントに最適な、Anthropic の最もインテリジェントなモデルが、Amazon Bedrock でご利用いただけるようになりました。Amazon Bedrock で Claude Sonnet 4.5 を利用することで、デベロッパーは、基盤モデル (FM) 用の統合 API を提供するだけでなく、セキュリティと最適化を実現するためのエンタープライズグレードのツールによってデータを完全に制御できるようにする、フルマネージドサービスにアクセスできます。 AWS Outposts が Dell および HPE とのサードパーティーストレージ統合をサポート – AWS Outposts のサードパーティーストレージ統合に、 Dell PowerStore および HPE Alletra Storage MP B10000 システムが含まれるようになりました。これらは、 NetApp オンプレミスエンタープライズストレージアレイ および Pure Storage FlashArray との既存の統合リストに加わりました。この統合には、主に 3 つの目的があります。1 つ目は、お客様が既存のストレージインフラストラクチャを維持しながら VMware ワークロードを AWS に移行するのをサポートすることです。2 つ目は、お客様が AWS サービスを利用しながらデータをオンプレミスに保持することで、厳格なデータレジデンシー要件を満たすのをサポートすることです。3 つ目として、この統合により、お客様は、AWS ツールを通じてサードパーティーストレージアレイとともに AWS Outposts を利用できます。 Amazon ECS マネージドインスタンスが利用可能に – コンテナ化されたアプリケーション向けの Amazon ECS マネージドインスタンスは、Amazon ECS 向けの新しいフルマネージドコンピューティングオプションであり、インフラストラクチャ管理のオーバーヘッドを排除しながら、Amazon EC2 の全機能を使用できるように設計されています。ECS マネージドインスタンスは、ワークロードを迅速に起動およびスケールするとともに、パフォーマンスを改善し、総保有コストを削減するのに役立ちます。 Amazon CloudWatch でアプリケーションマップの一般提供を開始 – Amazon CloudWatch は、設定とその関係に基づいてサービスを自動的に検出し、グループに整理することで、大規模な分散アプリケーションをモニタリングするのをサポートします。この新しいアプリケーションパフォーマンスモニタリング (APM) 機能を使用すると、分散アプリケーションのトラブルシューティング時に、どのアプリケーションと依存関係に重点を置くべきかを迅速に視覚化できます。 Amazon Bedrock AgentCore モデルコンテキストプロトコル (MCP) サーバーが使用可能に – ランタイム、ゲートウェイ統合、ID 管理、エージェントメモリのサポートが組み込まれた AgentCore MCP サーバーは、Bedrock AgentCore と互換性のあるコンポーネントの作成を高速化するために特別に構築されています。AgentCore MCP サーバーは、ラピッドプロトタイピング、本番 AI ソリューション、またはエージェントインフラストラクチャのスケールに使用できます。 その他のアップデート 以下では、私が興味深いと思った他のニュースやブログ記事をいくつかご紹介します: AWS ビルダー ID が「Google でログイン」をサポート –「Google でログイン」を使用して AWS ビルダー ID を作成できるようになりました。AWS ビルダー ID は、Kiro、AWS Builder Center、AWS トレーニングと認定、AWS re:Post、AWS スタートアップなどの AWS アプリケーションへのアクセスを提供する個人プロファイルです。 AWS API MCP サーバー v1.0.0 リリース – AWS API MCP サーバーは、AI アシスタントと AWS サービスの間のブリッジとして機能し、構文的に正しい CLI コマンドを作成して実行することで、基盤モデルが自然言語を通じてあらゆる AWS API とインタラクションできるようにします。AWS API MCP サーバーはオープンソースであり、 AWS ラボ GitHub リポジトリ で現在入手可能です。 AWS Knowledge MCP サーバーの一般提供を開始 – AWS Knowledge サーバーは、AI エージェントと MCP クライアントに、ドキュメント、ブログ記事、新機能のお知らせ、Well-Architected ベストプラクティスなどの信頼できる情報を LLM 互換形式で提供します。このリリースでは、AWS API と CloudFormation のリソースが利用できるリージョンに関する情報もサーバーに含まれます。 AWS Transform で VMware ネットワークオートメーションのために Terraform が使用可能に – AWS Transform は、VMware 環境からネットワークインフラストラクチャコードを自動的に生成するための追加オプションとして Terraform を提供するようになりました。このサービスは、ソースネットワーク定義を再使用可能な Terraform モジュールに変換し、現在の AWS CloudFormation と AWS Cloud Development Kit (CDK) のサポートを補完します。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS AI Agent Global Hackathon – AWS の強力な生成 AI スタックを掘り下げて、目を見張るようなすばらしいソリューションを創り出すチャンスです。9 月 8 日から 10 月 20 日までの期間、AWS の AI サービススイートを使用して AI エージェントを作成し、45,000 USD を超える賞金と独占的な市場参入の機会の獲得に向けて競い合いましょう。 AWS Gen AI Loft – 特別セッションで AWS の AI 製品とサービスについて学び、業界をリードするエキスパートと交流して、投資家や同業者との有益なネットワーキングの機会を得ることができます。最寄りの都市でご登録ください: パリ (10 月 7 日～21 日)、 ロンドン (10 月 13 日～21 日)、 テルアビブ (11 月 11 日～19 日)。 AWS Community Days – 世界中の AWS ユーザーや業界リーダーによる技術的なディスカッション、ワークショップ、ハンズオンラボを特徴とする、コミュニティ主導のカンファレンスにぜひご参加ください: ミュンヘン (10 月 7 日)、 ブダペスト (10 月 16 日)。 今後開催されるすべての AWS イベント と AWS スタートアップイベント をご覧いただけます。 10 月 6 日週のニュースは以上です。10 月 13 日週にお届けする次回の Weekly Roundup もお楽しみに! – Prasad 原文は こちら です。

9 月 30 日、Amazon ECS マネージドインスタンスを発表しました。これは Amazon Elastic Container Service (Amazon ECS) の新しいコンピューティングオプションです。開発者はインフラストラクチャ管理の責任を Amazon Web Services (AWS) にオフロードしながら、 Amazon Elastic Compute Cloud (Amazon EC2) の全機能を使用できるようになります。この新しいサービスは、インフラストラクチャのオフロードによる運用のシンプルさと Amazon EC2 の柔軟性および制御を組み合わせたものです。つまり、お客様は総保有コスト (TCO) を削減し、AWS のベストプラクティスを維持しながら、イノベーションを推進するアプリケーションの構築に集中することができます。 弊社では、コンテナ化されたワークロードを実行しているお客様から、サーバーレスのシンプルさとセルフマネージド EC2 インスタンスの柔軟性を組み合わせたいというご要望をいただいていました。サーバーレスオプションは優れた汎用ソリューションを提供しますが、アプリケーションによっては GPU アクセラレーション、特定の CPU アーキテクチャ、またはネットワークパフォーマンスの強化など、特定のコンピューティング機能が必要となります。さらに、EC2 料金オプションを通じて既に Amazon EC2 キャパシティに投資してくださったお客様は、これらのコミットメントをサーバーレスサービスで十分に活用することができませんでした。 Amazon ECS マネージドインスタンスは、さまざまな EC2 インスタンスタイプと AWS サービスとの密な統合をサポートする、フルマネージドのコンテナコンピューティング環境を提供します。デフォルトでは、ワークロードに最適なコストの EC2 インスタンスが自動的に選択されますが、必要に応じて特定のインスタンス属性またはタイプを指定できます。AWS がプロビジョニング、スケーリング、セキュリティパッチ処理、コスト最適化など、インフラストラクチャ管理のすべての側面を処理するため、お客様はアプリケーションの構築と実行に集中することが可能です。 試してみましょう 新しい Amazon ECS クラスターを作成する AWS マネジメントコンソール のエクスペリエンスを見てみると、ECS マネージドインスタンスを使用するための新しいオプションだということがわかります。それでは、すべての新しいオプションについて簡単に見ていきましょう。 [Fargate とマネージドインスタンス] を選択すると、2 つのオプションが表示されます。 [ECS デフォルトを使用] を選択すると、Amazon ECS は保留中のタスクをグループ化して汎用インスタンスタイプを選択し、コストと耐障害性のメトリクスに基づいて最適なインスタンスタイプを選択します。これが最もわかりやすい、お勧めの開始方法です。 [カスタムを使用 – 詳細] を選択すると、Amazon ECS が使用するインスタンスの属性をファインチューニングできる追加の設定パラメータが開きます。 デフォルトでは、 CPU と メモリ は属性として表示されますが、さらに 20 個の属性から選択し、Amazon ECS がアクセスできる使用可能なインスタンスタイプのリストを引き続きフィルタリングすることができます。 属性を選択すると、選択に一致するすべてのインスタンスタイプのリストが表示されます。 ここから、通常どおり ECS クラスターを作成できます。Amazon ECS は、前のステップで定義した属性と基準に基づき、私に代わってインスタンスをプロビジョニングします。 Amazon ECS マネージドインスタンスの主な特徴量 Amazon ECS マネージドインスタンスでは、AWS がインフラストラクチャ管理の全責任を負い、インスタンスのプロビジョニング、スケーリング、メンテナンスのすべての側面を処理します。これには、14 日ごとに開始される定期的なセキュリティパッチの実装 (インスタンスの Connection Draining により、インスタンスの実際の存続期間が長くなる場合があります) や、アプリケーションの中断を最小限に抑えるために Amazon EC2 イベントウィンドウを使用してメンテナンスウィンドウをスケジュールする機能が含まれます。 このサービスでは、インスタンスタイプを非常に柔軟に選択できます。デフォルトではコスト最適化されたインスタンスタイプが自動的に選択されますが、ワークロードにおいて特定の機能が必要な場合、必要なインスタンス属性を指定することができます。これには GPU アクセラレーション、CPU アーキテクチャ、ネットワークパフォーマンス要件のオプションが含まれており、コンピューティング環境を正確に制御できます。 Amazon ECS マネージドインスタンスはコストを最適化するために、必要に応じて複数のタスクをより大きなインスタンスに自動的に割り当てることにより、リソースの使用率をインテリジェントに管理します。このサービスはタスク配置を継続的に監視および最適化し、ワークロードを少数のインスタンスに統合してアイドル (空の) 状態のインスタンスを枯渇させ、利用および終了することで、コンテナ化されたアプリケーションの可用性とコスト効率の両方を高めます。 既存の AWS サービス、特に EC2 料金オプションなどの Amazon EC2 特徴量との統合はシームレスです。この密な統合により、フルマネージドサービスの運用のシンプルさを維持しながら、既存のキャパシティ投資を最大限に活用することができます。 Amazon ECS マネージドインスタンスでは、引き続きセキュリティが最優先事項です。このサービスは、専用のコンテナオペレーティングシステムである Bottlerocket 上で動作し、自動化されたセキュリティパッチとアップデートを通じてお客様のセキュリティ体制を維持します。Bottlerocket OS イメージに適用されたすべてのアップデートとパッチは、 Bottlerocket のウェブサイト で確認できます。この包括的なセキュリティへのアプローチにより、コンテナ化されたアプリケーションを安全かつ管理された環境で引き続き実行することができます。 今すぐご利用いただけます Amazon ECS マネージドインスタンスは現在、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (ダブリン)、アフリカ (ケープタウン)、アジアパシフィック (シンガポール)、アジアパシフィック (東京) の AWS リージョンでご利用いただけます。マネージドインスタンスは、AWS マネジメントコンソール、AWS コマンドラインインターフェイス (AWS CLI)、または AWS Cloud Development Kit (AWS CDK) や AWS CloudFormation などの Infrastructure as Code (IaC) ツールから使用を開始できます。使用する EC2 インスタンスの料金と、サービスの管理料金が請求されます。 Amazon ECS マネージドインスタンスの詳細については、 ドキュメント をご覧ください。コンテナインフラストラクチャの簡素化を今すぐ始めましょう。 原文は こちら です。

はじめに みなさんこんにちは、ソリューションアーキテクトの眞壽田（ますた）です。2025年9月18日に開催された「Vector SDV Symposium Japan 2025」にて、AWSのソリューションアーキテクトとして「SDV時代の車載ソフトウエア開発を支えるAWSソリューション」というテーマでセッションを担当させていただきました。Software-Defined Vehicle（SDV）の波が自動車産業を大きく変革している今、クラウドテクノロジーがどのように車載ソフトウェア開発の課題を解決し、イノベーションを加速させるのか。本セッションでは、仮想開発環境や仮想ECU技術を使ったテストの効率化まで、AWSが提供するソリューションについて紹介しました。 この記事では、セッションの内容を詳しく解説するとともに、SDV時代におけるクラウドの可能性について掘り下げていきたいと思います。 これまでのSDV事例のおさらい SDV時代を見据え、AWSを活用して車載ソフトウエア開発の効率化を目指した自動車メーカー様の事例は次の通りです。詳細はリンクやブログを参照頂ければと思います。 1. ステランティス　Virtual Engineering Workbench（VEW）2022年 youtube blog 2. BMW Operating System 9 2023年 link 3. 本田技研工業株式会社　Digital Proving Ground 2023年 youtube これらの事例に共通するAWSのソリューションを、次の章でじっくり紹介していきたいと思います。 SDV開発を支援するAWSのソリューション 自動車産業がソフトウェア定義車両（SDV）へと急速に進化する中、AWSは自動車メーカーが直面する複雑な課題に対して、包括的な支援フレームワークを提供しています。この図が示すように、AWSの支援は三つの主要な柱を中心に構成されています。 これらの柱に加え、AWSはデジタル人材の育成支援やパートナーとの連携を通じて、自動車メーカーのSDV開発を包括的にサポートしています。この統合的なアプローチにより、お客様は従来の開発モデルからソフトウェア中心の開発へとスムーズに移行し、次世代モビリティの創造に専念することができます。 自動車業界におけるオンプレミスの開発環境に対する課題 以下の例は、AWSがお客様からよく聞く課題をAWSの生成AIのサービス（ Amazon Bedrock ）でストーリー調に仕立てたものです。 ある自動車メーカーの制御ECU開発部門では100名以上のエンジニアがモデルベース開発（MBD）環境を使って制御ソフトウェアの開発に取り組んでいます。「開発環境の構築と維持が私たちの最大の頭痛の種なんです」とAさんは語ります。 「昨年、新たなプロジェクトが始まった時、各エンジニアの開発PC調達だけで数ヶ月を要しました。そして機材が到着した後も、必要なツールのインストールに数週間を費やしました。開発に必要なツール群は多岐にわたり、互換性の問題も頻発します。詳細なインストールマニュアルを整備する専任スタッフまで配置したのですが、それでも約2割のエンジニアが環境構築に失敗し、Q&amp;A対応に追われました」とAさんは振り返ります。 「さらに、一度環境を構築できても問題は続きます。シミュレーションやテスト実行中はPCリソースが占有されるため、他の作業が事実上不可能になります。また社外エンジニアとの協業においては、セキュリティ上の制約から開発PC利用に制限がかかることも少なくありません。また、すべての開発PCに対するセキュリティパッチの適用にも膨大な時間を要します。静的解析やテスト、シミュレーションの実行にも長時間を要し、開発サイクル全体が遅延する要因となっていました」とAさんは説明します。 このような開発環境では、ソフトウエアの開発量が増大するSDV時代に対応することは難しくなります。そこでAWSは、従来のオンプレミスでの開発環境の課題解決のために、主に次の２つのソリューションを提供しています。 開発環境課題を解決するためのAWSソリューション ２選 1. Research and Engineering Studio on AWS (RES) RESに関する情報　 GitHub 　 AWS Document 　 AWS Blog 　 YouTube RESの特徴的な機能として、 専用ウェブポータルからデスクトップ環境を簡単に作成 できることが挙げられます。 各プロジェクトでデスクトップイメージを保存 し、チームメンバーがそれを必要に応じてデプロイできる柔軟性も備えています。さらに、共有データストアを活用した共同作業環境の構築や、既存のID管理インフラ（AWS Managed Microsoft AD）との統合も実現しています。 先ほどの車載ソフトウエア開発の例では、RESを導入することで彼らの課題を以下のように解決できます： 迅速な環境構築 : 専用ウェブポータルからデスクトップ環境を短時間で作成でき、数ヶ月かかっていたPC調達・環境構築のプロセスを大幅に短縮 環境の標準化と再利用 : プロジェクト毎にデスクトップイメージを保存し、チームメンバーが即座にデプロイできるため、環境構築の失敗によるQ&amp;A対応の負担が限りなく軽減される 共同作業の効率化 : 共有データストアを活用した共同作業が可能となり、OEM、サプライヤーが所属するチームのコラボレーションが促進される セキュリティの強化と簡素化 : 既存のID管理インフラ（AWSマネージドAD）との統合により、社外エンジニアとの協業におけるセキュリティ課題が解決され、一元的なセキュリティ管理が可能 メンテナンス作業の軽減: セキュリティパッチを当てた開発環境をイメージとして保存することで、開発者は最新の環境をデプロイすることが可能 2. Virtual Engineering Workbench (VEW) ステランティスの事例で紹介したVirtual Engineering Workbenchは、AWSのソリューションとしても展開しています。 このソリューションは、前述のRESで提供する開発環境やシミュレーション環境だけではなく、特定の仮想ECUのイメージも管理することで、今まで評価ボードを調達しなければECUのテストができなかった機能テストや結合テストが、仮想環境で実現することを可能とします。ステランティスの事例では、Github actionsやArtifactoryを用いたDevOpS環境の構築と、そのWorkflowで作成したアーティファクトの仮想ECUのバイナリファイルを、専用線で接続したオンプレミスのHILS環境へ連携するユースケースも実現しています。ご興味のある方は、こちらの ブログ もご覧ください。 Shift Leftを実現する仮想ECU技術 車載ソフトウエア開発のV字モデルの開発プロセスでは、ECU間の結合テストがV字の右側（後半）で実施されることがありました。右側の段階で不具合が発見されると、開発の手戻りが大きくなり、コストや時間の増大につながっており、多くのお客様が仮想ECUに興味を持っていただいています。 1. AWS Graviton と ARM on ARM技術 AWSはARMアーキテクチャを採用したデータセンター向けLSIであるGravitonを自ら設計し、2015年にLSI設計会社のAnnapuruna Labsを完全子会社化することでその技術基盤を強化しました。特に自動車開発において重要な点として、 AWS Graviton は、ARMとの協力により、実際のECUで使用されるARMのCortex-A、Cortex-M、Cortex-Rシリーズの命令コードをAWS Graviton上でそのまま実行できる「ARM on ARM技術」を搭載しています。これにより、仮想ECUの環境を正確かつ効率的に構築することが可能となっています。 このARM on ARMの技術を活用したソリューションがAWS Marketplaceで公開されました。Corellium社が提供する Atlas Private Cloud です。 詳細は、 Marketplaceのページ をご覧頂ければと思いますが、このAtlas Private Cloudは、 AWS Graviton 4 c8g.metal24xl EC2インスタンス上で、32ビットと64ビットのArm Cortex A、R、MコアをベースにしたARM Virtual Hardware（AVH）を実行することができます。2025年10月現在、AWS Graviton 4 c8g.metal24xl １つのEC2インスタンス上で動作可能なAVHは、トータル80 core分で、１つのEC2インスタンス上で複数の仮想ECUを起動することが可能です。今まで、制御系ECUを仮想化する場合、x86上のEC2インスタンスでエミュレーターを動かしいるのが通常でしたが、GravitonとARM on ARM技術を利用したソリューションで解決できるようになるケースが期待できます。 例えば、2025年のAWS Summit JapanのAutomotiveデモブースでは、下記の構成でコックピットとパワートレインのECUを仮想化し、Autosar APのSOME/IPで接続するデモンストレーションを紹介しました（下の図）。③の仮想ECUのスタックでは、AWS Graviton EC2 + Corellium上で、Cortex-R82AEのVirtual Hardwareを動作させ、パワートレインのアプリケーションを動作させています。 2. QNX Hypervisor on AWS Blackberry社のQNXが、 QNX Hypervisor 2.2 をAWS Marketplaceから提供しています。2025年10月現在、AWS上でQNX Hypervisor 2.2を利用するには、Blackberry社と別途ライセンス契約が必要になります。ご興味がある方は、Blackberry社にお問い合わせ頂ければと思います。 QNX Hypervisor on AWS QNX Hypervisor 2.2 on AWSは、AWS Graviton EC2インスタンスである、c6g.metal, r6g.metal, m6g.metalインスタンスで稼働します。アプリケーションから周辺デバイスへのアクセスは、Hardware Abstraction Layer（HAL層）のVirtIO経由で行います。仮に、従来のアプリケーションを、QNX Hypervisor 2.2上で仮想化するには、そのアプリケーション内で、ハードウエアに依存した処理をVirtIOで分離させる必要があります。どのハードウエアへのアクセスを抽象化するかという点において、サポートするVirtIOのバージョンやQNXとのライセンス契約にも依存しますので、Blackberry社にお問い合わせ頂ければと思います。 QNX Hypervisor on AWSに関する情報は以下のブログでもまとめられています。 Elevating cluster software development with QNX Hypervisor on AWS おわりに このブログでは、SDV時代を支えるAWSソリューションとして、開発環境と検証環境の２点に絞って紹介しました。特に、開発環境の課題については多くのお客様が解決したい課題ではないかと思います。量産開始後も継続してソフトウエアのアップデートが本格化する将来、開発環境を必要に応じて伸縮自在に調整することが望まれ、クラウドベースのエコシステムを構築していくことは多くのお客様において急務となっています。このブログを読んでAWSの人と少しお話してみたいなと思われる読者様がいらっしゃいましたら、お近くのAWSのアカウントチームや AWS for Automotive （チャット）までご連絡下さいませ。 著者 眞壽田 英輝 (Masuta, Hideki) アマゾン ウェブ サービス ジャパン 合同会社 自動車製造領域のお客様を支援するシニアソリューションアーキテクト。長年乗っていた車を最近買い替えたところ、車載ソフトウェアの目覚ましい進化に驚かされる日々を過ごしています。今後さらに高度な運転支援システムが普及することで、交通死亡事故ゼロの社会へと一歩ずつ近づいていくでしょう。そのような未来の実現に貢献すべく、自動車産業のお客様のイノベーションを技術面からバックアップしています。

イベント概要 AWS は Amazon の流通小売事業における知見と経験をもとにソリューションを提供しており、流通小売・消費財業界におけるイノベーションのカギとして、「カスタマーエンゲージメント」「デジタル コマース」「インテリジェント・サプライチェーン」「マーチャンダイジング &amp; プランニング」「スマートストア」の 5 つのテーマを重視しています。 本イベントでは、この 5 つのテーマから、特に「カスタマーエンゲージメント」「デジタル コマース」 「スマートストア」の 3 つのテーマにフォーカスをして、AWS のテクノロジー、専門知識を活用して提供しているソリューションプロバイダーから業界に固有の課題と機会に応えるサービスやベストプラクティスをご紹介します。 「イノベーションを加速させたいが、スピードや人材が課題」といった状況でもすぐに活用できるソリューションを学び、展示ブースで製品デモをご覧いただけるほか、ソリューションプロバイダー各社と個別にご相談できる機会も提供いたします。 日時：2025 年 11 月 25 日（火）16:00–19:00（15:30 受付開始） 場所：AWS 目黒オフィス 目黒セントラルスクエア 21 階（東京都品川区上大崎 3-1-1） 主催：アマゾン ウェブ サービス ジャパン合同会社 参加費：無料（要事前申込） 参加申込：こちらの お申込みフォーム からお申込みください。 展示テーマと出展企業 「カスタマーエンゲージメント」 カスタマー 360° によって顧客セグメントの関係性や特徴、顧客生涯価値を理解し、CRM、顧客データプラットフォーム、コンタクトセンター DX など、データ主導のインサイトによるカスタマーエンゲージメントの促進に役立つソリューションをご紹介します。 ＜出展企業（アルファベット順）＞ Amplitude Analytics 合同会社 Braze 株式会社 株式会社電通デジタル 株式会社サーバーワークス トレジャーデータ株式会社 「デジタルコマース」 生成 AI を利用した魅力的なサイトや、俊敏なコマース基盤など、デジタルコマースソリューションへの投資は不可欠です。デジタルコマースのイノベーションを加速し、あらゆるチャネルでカスタマーエクスペリエンスを高めるためのソリューションをご紹介します。 ＜出展企業（アルファベット順）＞ アジアクエスト株式会社 Contentsquare Japan 合同会社 「スマート ストア」 小売業に新たな収益の柱をもたらすことが期待される店舗内の先進ソリューションや、顧客接点の可能性を広げる POS データ活用、店舗省人化に応える最新のテクノロジーなどをご紹介します。 ＜出展企業（アルファベット順）＞ フォージビジョン株式会社 富士ソフト株式会社 株式会社インテック ソニー株式会社 株式会社ティールテクノロジーズ 株式会社 USEN Camera Solutions 来場者特典 事前お申込みのうえ当日ご来場いただきましたお客様へ 先着 150 名限定 で、イベント特製のステンレスマグカップ（AWS ロゴ入り）をプレゼントいたします！ ※ 画像はイメージです。実物と異なる場合がございます。 当日はパートナー各社のブースにて、展示ブースで製品デモをご覧いただけるほか、ソリューションプロバイダー各社と個別にご相談できる機会も提供いたします この特別な機会をお見逃しなく。お申し込みは こちら から。 皆様のご参加を楽しみにお待ちしております！