ZFS が発明された Sun Microsystems で勤務していた私は、開発やテストのニーズに合わせてインスタントボリュームコピーを提供するストレージシステムを使用するのが好きでした。 10 月 14 日、AWS が Amazon EBS ボリュームクローンのリリースによって同様の機能を Amazon Elastic Block Store (Amazon EBS) に搭載したとお伝えできることを嬉しく思います。これは、同一アベイラビリティーゾーン内で EBS ボリュームのポイントインタイムコピーを瞬時に作成できる新機能です。 多くのお客様は、個別の非本番環境での開発およびテスト作業をサポートするために、本番データのコピーを作成する必要があります。これまで、このプロセスでは ( Amazon Simple Storage Service (Amazon S3) に保存されている) EBS スナップショットを取得し、そのスナップショットから新しいボリュームを作成する必要がありました。このアプローチは有効ですが、このプロセスでは複数のステップが原因で運用上のオーバーヘッドが発生します。 Amazon EBS ボリュームクローンを使用すると、1 回の API コールまたはコンソールクリックで EBS ボリュームのコピーを作成できるようになりました。コピーされたボリュームは数秒で使用可能になり、1 桁ミリ秒のレイテンシーでデータにすぐアクセスできます。そのため、ボリュームクローンは、本番データを使用したテスト環境を迅速にセットアップしたり、開発目的でデータベースの一時的なコピーを作成したりする場合に特に役立ちます。 ボリュームクローンの仕組みのご紹介 この記事では、ボリュームがアタッチされた小規模な Amazon Elastic Compute Cloud (Amazon EC2) インスタンスを作成しました。 echo "Hello CopyVolumes" > hello.txt コマンドを使用して、ルートファイルシステムにファイルを作成しました。 コピーを開始するには、 AWS マネジメントコンソール でブラウザを開き、 [EC2] 、 [Elastic Block Store] 、 [ボリューム] に移動します。コピーするボリュームを選択します。 この記事の公開時点では、暗号化されたボリュームしかコピーできないことに注意してください。 [アクション] メニューで、 [ボリュームをコピー] オプションを選択します。 次に、ターゲットボリュームの詳細を選択します。 [ボリュームタイプ] を変更し、 [サイズ] 、 [IOPS] 、 [スループット] パラメータを調整できます。 [ボリュームをコピー] を選択して、ボリュームクローンの操作を開始します。 コピーされたボリュームは [作成中] 状態になり、数秒以内に使用可能になります。それを EC2 インスタンスにアタッチして、すぐに使用を開始できます。 データブロックはソースボリュームからコピーされ、バックグラウンドでボリュームコピーに書き込まれます。処理が完了するまで、ボリュームは [初期化] 状態のままです。 describe-volume-status API を使用して、進行状況を監視できます。初期化操作はソースボリュームのパフォーマンスに影響しません。コピー処理中も通常どおり使用できます。 私は、コピーしたボリュームをすぐに使用できることが気に入っています。初期化が完了するのを待つ必要はありません。初期化フェーズでは、コピーしたボリュームのパフォーマンスは、3,000 IOPS と 125 MiB/s のベースライン、ソースボリュームのプロビジョニングされたパフォーマンス、またはコピーされたボリュームのプロビジョニングされたパフォーマンスのうち、最も低い値に基づいて提供されます。 初期化が完了すると、コピーされたボリュームはソースボリュームから完全に独立し、フルプロビジョニングされたパフォーマンスを発揮します。 または、 AWS コマンドラインインターフェイス (AWS CLI) を使用してコピーを開始することもできます。 aws ec2 copy-volumes \ --source-volume-id vol-1234567890abcdef0 \ --size 500 \ --volume-type gp3 ボリュームコピーを作成したら、それを EC2 インスタンスにアタッチしてマウントします。起動時に作成したファイルが存在することを確認できます。 まず、 attach-volume コマンドを使用して、ノートパソコンからボリュームをアタッチします。 aws ec2 attach-volume \ --volume-id 'vol-09b700e3a23a9b4ad' \ --instance-id 'i-079e6504ad25b029e' \ --device '/dev/sdb' 次に、インスタンスに接続し、以下のコマンドを入力します。 $ sudo lsblk -f NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS nvme0n1 ├─nvme0n1p1 xfs / 49e26d9d-0a9d-4667-b93e-a23d1de8eacd 6.2G 22% / └─nvme0n1p128 vfat FAT16 3105-2F44 8.6M 14% /boot/efi nvme1n1 ├─nvme1n1p1 xfs / 49e26d9d-0a9d-4667-b93e-a23d1de8eacd └─nvme1n1p128 vfat FAT16 3105-2F44 $ sudo mount -t xfs /dev/nvme1n1p1 /data $ df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 4.0M 0 4.0M 0% /dev tmpfs 924M 0 924M 0% /dev/shm tmpfs 370M 476K 369M 1% /run /dev/nvme0n1p1 8.0G 1.8G 6.2G 22% / tmpfs 924M 0 924M 0% /tmp /dev/nvme0n1p128 10M 1.4M 8.7M 14% /boot/efi tmpfs 185M 0 185M 0% /run/user/1000 /dev/nvme1n1p1 8.0G 1.8G 6.2G 22% /data $ cat /data/home/ec2-user/hello.txt Hello CopyVolumes 知っておくべきこと ボリュームクローンは、ソースボリュームと同じアベイラビリティーゾーン内にコピーを作成します。コピーは暗号化されたボリュームからのみ作成することができ、コピーのサイズはソースボリュームと同じかそれより大きい必要があります。 ボリュームクローンは、スナップショットとまったく同じように、ボリュームの Crash-consistent コピーを作成します。アプリケーションの整合性を保つには、コピーを作成する前にアプリケーションの I/O 操作を一時停止する必要があります。例えば、PostgreSQL データベースでは、 pg_start_backup () 関数と pg_stop_backup () 関数を使用して書き込みを一時停止し、一貫性のあるコピーを作成できます。XFS 搭載の Linux のオペレーティングシステムレベルでは、 xfs_freeze コマンドを使用してファイルシステムへのアクセスを一時的に中断および再開し、キャッシュされたすべての更新がディスクに書き込まれるようにすることができます。 ボリュームクローンはポイントインタイムコピーを作成しますが、バックアップ目的で EBS スナップショットを置き換えるのではなく、補完するものです。データバックアップと AZ レベルおよびボリューム障害からの保護としては、引き続き EBS スナップショットが推奨のソリューションです。EBS ボリュームの耐久性 (io2 では 99.999%、その他のボリュームタイプでは 99.9%) を維持するボリュームクローンと比較して、スナップショットは Amazon S3 への増分バックアップを 99.999999999% の耐久性で提供します。特に、ボリュームコピーへの即時アクセスが必要なテスト環境と開発環境のシナリオでは、ボリュームクローンの使用をご検討ください。 コピーされたボリュームはソースボリュームから独立して存在し、削除するまで標準の EBS ボリューム料金が引き続き発生します。コストを効果的に管理するには、ガバナンスルールを導入し、開発またはテストアクティビティで不要になったコピーされたボリュームを特定して削除してください。 料金と利用可能なリージョン ボリュームクローンはすべての EBS ボリュームタイプをサポートし、同一の AWS アカウントおよびアベイラビリティーゾーンのボリュームで動作します。この新機能は、すべての AWS 商用 リージョン 、一部の ローカルゾーン 、 AWS GovCloud (米国) でご利用いただけます。 料金については、開始時にソースボリュームのデータの GiB あたり 1 回限りの料金が請求され、新しいボリュームには標準 EBS 料金が請求されます。 ボリュームクローンは、データベースワークロードや継続的インテグレーション (CI) シナリオで特に役立つと思います。例えば、本番環境に影響を与えたり、Amazon S3 からデータがハイドレートされるのを待ったりすることなく、新しい特徴量のテストや問題のトラブルシューティングを行うために、本番環境のデータベースのコピーをすばやく作成できます。 Amazon EBS ボリュームクローンの使用を開始するには、 コンソールの Amazon EBS セクション にアクセスするか、 EBS ドキュメント をご覧ください。この機能を使用して開発ワークフローを改善した方法についてお伺いすることを楽しみにしています。 – seb 原文は こちら です。

重要なビジネスデータを交換するための業界標準として、多数の組織が Secure File Transfer Protocol (SFTP) に頼っています。従来、プライベート SFTP サーバーへのセキュアな接続には、カスタムインフラストラクチャ、手作業によるスクリプト作成、パブリックインターネットへのエンドポイントの公開が欠かせませんでした。 10 月 14 日から、 AWS Transfer Family SFTP コネクタ が Amazon Virtual Private Cloud (Amazon VPC) 環境経由でのリモート SFTP サーバーへの接続をサポートするようになりました。 Amazon Simple Storage Service (Amazon S3) とプライベートまたはパブリック SFTP サーバー間でのファイル転送を、お使いの VPC で既に定義されているセキュリティコントロールとネットワーク設定を適用しながら実行できます。この機能は、オンプレミス環境、パートナーホスト型プライベートサーバー、またはインターネットに接続するエンドポイントの全体でデータソースを統合するために役立ち、フルマネージド型の Amazon Web Services (AWS) サービスのシンプルな運用性を備えています。 SFTP コネクタによる新機能 以下が主な機能強化になります。 プライベート SFTP サーバーへの接続 – SFTP コネクタは、AWS VPC 接続内でしかアクセスできないエンドポイントに到達できるようになりました。これらのエンドポイントには、VPC または共有 VPC でホストされるサーバー、 AWS Direct Connect 経由で接続されるオンプレミスシステム、VPN トンネル経由で接続されるパートナーホスト型サーバーなどがあります。 セキュリティとコンプライアンス – すべてのファイル転送は、VPC で既に適用されているセキュリティコントロール ( AWS Network Firewall や、一元化されたイングレスおよびエグレスインスペクションなど) を経由してルーティングされます。プライベート SFTP サーバーはプライベートのまま維持されるため、インターネットに公開する必要はありません。パートナーの許可リスト要件を満たすために、静的 Elastic IP や Bring-Your-Own-IP (BYOIP) のアドレスを提示することも可能です。 パフォーマンスとシンプルさ – NAT ゲートウェイ、AWS Direct Connect、VPN 接続などの独自のネットワークリソースを使用することで、コネクタは大規模な転送のためにより多くの帯域幅容量を利用できるようになります。コネクタの設定は、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS SDK を使用して数分で完了でき、カスタムスクリプトを作成したりサードパーティツールを構築したりする必要はありません。 VPC ベースの SFTP 接続の仕組み SFTP コネクタは、VPC 経由でセキュアな接続を確立するために Amazon VPC Lattice リソースを使用します。 主なコンストラクトには、 リソース設定 と リソースゲートウェイ が含まれます。リソース設定はターゲット SFTP サーバーを表すもので、プライベート IP アドレスやパブリック DNS 名を使用して指定します。リソースゲートウェイは SFTP コネクタがこれらの設定にアクセスできるようにして、ファイル転送が VPC とそのセキュリティコントロールを経由して行われるようにします。 以下は、Amazon S3 とリモート SFTP サーバー間のトラフィックフローを説明するアーキテクチャ図です。 アーキテクチャ図にあるように、Amazon S3 からのトラフィックは SFTP コネクタを経由して VPC に送られます。リソースゲートウェイは、コネクタから VPC リソースへのインバウンド接続を処理するエントリポイントです。アウトバウンドトラフィックは、設定されたエグレスパスを通じてルーティングされます。この場合、パブリックサーバーには Elastic IP がアタッチされた Amazon VPC NAT ゲートウェイが使用され、プライベートサーバーには AWS Direct Connect と VPN 接続が使用されます。VPC CIDR 範囲からの既存の IP アドレスを使用できるため、パートナーサーバーの許可リストが簡略化されます。VPC 内の一元化されたファイアウォールがセキュリティポリシーを適用し、お客様所有の NAT ゲートウェイが大規模な転送のための高帯域幅を提供します。 この特徴量を使用するシナリオ この機能を使用することで、開発者と IT 管理者はさまざまなシナリオのセキュリティ要件とコンプライアンス要件を満たしながらワークフローを簡素化できます。 ハイブリッド環境 – エンドポイントをインターネットに公開することなく、AWS Direct Connect または AWS Site-to-Site VPN を使用して、Amazon S3 とオンプレミス SFTP サーバー間でのファイル転送を行います。 パートナー統合 – プライベート VPN トンネルまたは共有 VPC 経由でしかアクセスできないビジネスパートナーの SFTP サーバーに接続します。そうすることで、カスタムスクリプトの作成やサードパーティツールの管理が不要になり、運用に伴う複雑性が軽減されます。 規制対象業界 – 金融サービス、政府、またはヘルスケアにおけるセキュリティ要件を順守するために、VPC 内の一元化されたファイアウォールとインスペクションポイント経由でファイル転送のルーティングを行います。 高スループット転送 – Elastic IP や BYOIP を用いた NAT ゲートウェイ、AWS Direct Connect、VPN 接続などの独自のネットワーク設定を使用して、パートナーの許可リストに既に存在する IP アドレスを保持しながら、大規模な高帯域幅転送を処理します。 統合ファイル転送ソリューション – Transfer Family で内部と外部両方の SFTP 接続を標準化し、ファイル転送ツール全体での断片化を低減します。 SFTP コネクタを使用した構築の開始 SFTP コネクタを使用した VPC 環境経由のファイル転送を開始するには、以下の手順を実行します。 まず、VPC Lattice リソースを設定します。 Amazon VPC コンソール のナビゲーションペインにある [ PrivateLink と Lattice ] で [ リソースゲートウェイ ] を選択してから [ リソースゲートウェイを作成 ] を選択して、VPC へのイングレスポイントとして機能するリソースゲートウェイを作成します。 次に、ナビゲーションペインの [ PrivateLink と Lattice ] で [ リソース設定 ] を選択してから [ リソース設定を作成 ] を選択して、ターゲット SFTP サーバー用のリソース設定を作成します。プライベート IP アドレスまたはパブリック DNS 名、およびポート (通常は 22) を指定します。 指定したら、 AWS Identity and Access Management (IAM) 許可を設定します。コネクタの作成に使用した IAM ロールに transfer:* 許可と VPC Lattice 許可 ( vpc-lattice:CreateServiceNetworkResourceAssociation 、 vpc-lattice:GetResourceConfiguration, vpc-lattice:AssociateViaAWSService ) があることを確認します。IAM ロールの信頼ポリシーを更新して、 transfer.amazonaws.com を信頼できるプリンシパルとして指定します。そうすることで、SFTP コネクタを作成したり管理したりするときのロールを AWS Transfer Family が引き継げるようになります。 ロールが引き継がれたら、 AWS Transfer Family コンソール を使用して SFTP コネクタを作成します。[ SFTP コネクタ ] を選択してから、[ SFTP コネクタを作成する ] を選択します。 [ コネクタの設定 ] セクションで [ VPC Lattice ] を出力タイプとして選択してから、[ リソース設定 ] の Amazon リソースネーム (ARN)、[ アクセスロール ]、[ コネクタの認証情報 ] を指定します。オプションで、セキュリティを強化するための信頼できるホストキーを含めます。または、SFTP サーバーが非標準のポートを使用する場合はデフォルトポートを上書きします。 次に、接続をテストします。[ アクション ] メニューで [ テスト接続 ] を選択して、コネクタがターゲット SFTP サーバーに到達できることを確認します。 最後に、コネクタのステータスが [ アクティブ ] になったら、 StartDirectoryListing 、 StartFileTransfer 、 StartRemoteDelete 、または StartRemoteMove などの Transfer Family API を呼び出すことで、リモート SFTP サーバーとのプログラム的なファイル操作を開始できます。すべてのトラフィックは、IP アドレスやセキュリティコントロールとともに NAT ゲートウェイ、AWS Direct Connect、VPN 接続などの設定済みリソースを使用して、VPC 経由でルーティングされます。 すべてのオプションと高度なワークフローについては、 AWS Transfer Family ドキュメント を参照してください。 今すぐご利用いただけます VPC ベースの接続性を備えた SFTP コネクタは、現在 21 の AWS リージョン でご利用いただけます。サポートされている AWS リージョンの最新リストについては、 AWS Services by Region を確認してください。これからは、NAT ゲートウェイ、Elastic IP、ネットワークファイアウォールなどの独自の VPC リソースを使用して、プライベート、オンプレミス、またはインターネットに接続されたサーバーに AWS Transfer Family の SFTP コネクタをセキュアに接続できるようになります。 – Betty 原文は こちら です。

本記事は、2025 年 10 月 9 日に公開された Development phase steps for successful launches on Amazon GameLift Servers を日本語に翻訳したものです。翻訳はソリューションアーキテクトの安藤怜央が担当しました。 マルチプレイヤーゲームの開発において、ゲームサーバーのグローバルなホスティング、スケーリング、監視の効率的な方法について検討されているのではないでしょうか。また、世界中のプレイヤーに最高のゲーム体験を提供するため、セッション配置の最適化についてもお悩みかもしれません。これらすべてを一から構築するのは、かなりの労力を必要とする作業です。 私たちはグローバルなゲームサーバーホスティングのためのフルマネージド型サービスである Amazon GameLift Servers をお勧めしています。このサービスは、オーケストレーション、グローバルなセッション配置、ゲームセッションライフサイクル管理を担うため、マルチプレイヤーゲームのローンチにおける運用作業とストレスを軽減するのに役立ちます。 このブログシリーズでは、ゲームローンチを成功させるための準備の重要な考慮事項について説明します。この最初のブログはプリプロダクションで実行すべきアクションに焦点を当て、第 2 部はプリローンチ準備 ( ローンチの 2〜3 ヶ月前 ) に焦点を当てます。これらの推奨事項は、開発初期のインテグレーションからゲームローンチまで数百のゲームスタジオをサポートした経験に基づいています。 このブログの内容の理解を進めるために、以下の知識があることを想定しています： Amazon GameLift Servers の基本 に精通していること ゲームエンジンとゲーム開発の知識 マルチプレイヤーネットワーキング概念の理解 ゲームローンチの初期計画における 4 つの重要な領域について説明します： ゲームサーバーのテストとインスタンスタイプの選択 ゲームセッションライフサイクル管理の設定 セッション配置のためのキューとキューイベントの活用 モニタリング、ログ記録、アラームの設定 ゲームサーバーのテストとインスタンスタイプの選択 ゲームサーバーのテストは通常、ローカル上でゲームサーバーをテストするところから始まります。ローカルサーバーの動作が確認できたら、次のステップは Amazon GameLift Servers フリート にデプロイし、サービス上でパフォーマンスをテストすることです。 正しいインスタンスタイプとサイズを特定するのに役立つ重要な測定メトリクスは以下の通りです： リソース消費量 ( CPU 集約型と比較したメモリ集約型 ) 各インスタンスで実行できるゲームサーバーコンテナまたはプロセスの数 最大プレイヤー負荷でのインスタンス上のゲームサーバーのパフォーマンス このフェーズは小さなフリート、単一リージョンの 1 つのインスタンスでも実行できます。この時点で、リソース分離のために別の開発用 Amazon Web Services ( AWS ) アカウントを作成することをお勧めします。後でテストや本番などの他の環境を追加できます。フリートは非常に線形にスケールアウトするため、実際のテスターやボットクライアントで単一インスタンスを最大プレイヤー負荷にかけることで、ゲームサーバーのパフォーマンスについて良い指標を得ることができます。 推奨されるフリートタイプは コンテナフリート です。コンテナフリートでは、各ゲームサーバーの vCPU とメモリ要件を定義できます。Amazon GameLift Servers は、選択されたインスタンスタイプに可能な限り多くのセッションを自動的に配置します。 組み込みの Amazon CloudWatch メトリクス は、ゲームサーバーのメモリと CPU 制約を特定するのに役立ちます。このテスト使用データに基づいて調整し、C インスタンスファミリー ( より多くの CPU が必要な場合 ) 、M インスタンスファミリー( メモリと CPU のバランス )、R インスタンスファミリー ( より多くのメモリが必要な場合 ) の中から選択できます。物理シミュレーションは多くの CPU リソースを消費するため、ほとんどのゲームは C インスタンスファミリーまたは M インスタンスファミリーを使用します。 Amazon GameLift Servers でサポートされている最新世代のインスタンスは、最高の価格パフォーマンスを提供します。ARM ベースの AWS Graviton インスタンス を活用することで、パフォーマンスをさらに向上させることができます。 選択したインスタンスタイプに何個のコンテナ ( コンテナフリートの場合 ) またはゲームサーバープロセス ( Amazon EC2 フリートの場合 ) を配置できるかを決定するには、実際の負荷でテストし、パフォーマンスを監視する必要があります。これは、ゲームをプレイするテストグループ、またはサーバーに接続して事前定義されたスクリプトでゲームを自動的にプレイするヘッドレスボットクライアントのいずれかで実行できます。 このテストは、クライアントとサーバー間で実際のデータトラフィックが流れる状態で実行する必要があります。サーバー上のローカルボットでシミュレーションをテストするだけでは、パフォーマンスの包括的な全体像を得られないためです。複数のリージョンにボットクライアントや実際のテスターを配置することも、地理的なネットワークトラフィックレイテンシーがパフォーマンスにどのように影響するかをより現実的に理解するのに役立ちます。 図 1 は、 Amazon CloudWatch メトリクスとログを通じてパフォーマンスを監視しながら、ゲームセッションにトラフィックを生成するボットクライアントを示しています。コンテナフリートは自動的にゲームサーバーログを Amazon CloudWatch にプッシュし、Amazon EC2 フリートでは CloudWatch Agent を使用 してログを CloudWatch にプッシュできます。 図 1：ゲームサーバーのパフォーマンステスト ゲームセッションライフサイクル管理の設定 ゲームサーバープロセスのライフサイクルにはいくつかの重要な要素があり、すべてを考慮することがフリートの健全性を保つために不可欠です。それでは、ゲームサーバーフリートでのセッション管理のシーケンスを詳しく見てみましょう。 起動時、ゲームサーバープロセスは Amazon GameLift Servers との通信を確立し、ゲームセッションをホストする準備ができていることを報告します。 ゲームサーバープロセスは以下のサーバー SDK 操作を順番に呼び出します： ゲームサーバーの初期化 サーバー準備完了の通知 ゲームサーバーヘルスの評価 ゲームセッションイベントの処理 ゲームセッションの終了 1. ゲームサーバーの初期化 サーバーは InitSDK 呼び出しメソッドで開始します。この関数は、サーバープロセスを認証し、Amazon GameLift Servers のオーケストレーションの準備を行います。 考慮事項： Amazon GameLift Servers との通信を速やかに確立するため、サーバープロセスの起動時に最初の呼び出しとして InitSDK を実行してください。 フリートの監視をサポートし、サイレントな障害を防ぐため、SDK 初期化エラーのログ取得とハンドリングを行ってください。 2. サーバー準備完了の通知 リソースとゲームロジックがロードされたら、 ProcessReady を呼び出して Amazon GameLift Servers にプロセスがゲームセッションをホストする準備ができていることを通知します。この呼び出しでは、ゲームクライアントがゲームセッションに接続するために使用するプロセスの接続情報も報告されます。Amazon GameLift Servers はゲームサーバープロセスのステータスを ACTIVE に更新し、新しいゲームセッションをホストできる状態になります。 考慮事項： すべての初期化が完了した後にのみ ProcessReady を呼び出し、重複した呼び出しを避けてください。 OnStartGameSession や OnHealthCheck などの必要なコールバックをすべて提供し、適切なエラーハンドリングと再試行を実装してください。 Amazon GameLift Servers コンソールまたは API からセッションログにアクセスできることを確認するため、EC2 フリートで正確なログパスを提供してください。 3. ゲームサーバーヘルスの評価 サーバープロセスが ACTIVE に設定されると、Amazon GameLift Servers はゲームサーバープロセスからヘルスステータスを要求するため、定期的に OnHealthCheck コールバックを呼び出し始めます。プロセスが unhealthy と報告するか、ヘルスチェックに応答しない場合、サービスはプロセスのアクティブステータスを変更し、新しいプロセスに置き換えます。 考慮事項： サーバー SDK で堅牢な OnHealthCheck コールバックを実装し、true で応答する前にサーバーが健全であることを適切に検証してください。 4. ゲームセッションイベントの処理 プレイヤーがゲームへの参加を要求すると、ゲームクライアントはバックエンドサービスにリクエストを送信し、新しいセッションを開始するために StartGameSessionPlacement または CreateGameSession を呼び出す場合があります。サービスは利用可能なサーバープロセスをフリートで検索します。見つかると、ゲームセッションを作成し、 OnStartGameSession コールバックを呼び出します。サーバーは自身の準備ができたら ActivateGameSession を呼び出し、Amazon GameLift Servers はセッションを PENDING から ACTIVE に更新し、配置を完了します。 考慮事項： OnStartGameSession を受信した後にのみプレイヤーが接続するようにしてください。Amazon GameLift Servers は、サーバープロセスが新しいゲームセッションのホストを開始することを望む場合にこのコールバックを呼び出します。これにより、実際にゲームがロードされる前にサーバーへの接続を試みることによって発生する問題を減らすことができます。 ゲームマップやその他の設定を適切にセットアップし、セッションをホストする完全な準備ができてから、 OnStartGameSession コールバック内で ActivateGameSession を呼び出してください。 ActivateGameSession を呼び出すことで、サーバーが新しいゲームセッションをホストするための初期化を完了し、プレイヤー接続を確立するための着信トラフィックを受信する準備ができたことを Amazon GameLift サービスに通知します。 プロセスがセッション配置を数日間待機している場合、ヘルスチェックですべてのシステムが正しく動作していることを確認してください。これは、フリートを事前にセットアップしたものの、実際の本番トラフィックを後から受信する場合や、時間帯によってプレイヤートラフィックが変化する場合に当てはまります。一部のロケーションでは、セッション配置を受信しない時間帯が存在する可能性があります。 5. ゲームセッションの終了 ゲームセッションの終了時に、サーバープロセスは Amazon GameLift Servers にゲームセッションステータスを通知します。ゲームサーバープロセスは、サーバー SDK 操作 ProcessEnding を呼び出してシャットダウンを開始します。ゲームセッション終了の一環として、Amazon GameLift Servers はゲームセッションとサーバープロセスのステータスを TERMINATED に変更します。 考慮事項： ゲームセッションがサーバーに配置され ( OnStartGameSession が呼び出され ) たものの、プレイヤーが接続しない、または切断された場合のバックアッププロセス終了メカニズムを実装してください。これらの状況で確実にプロセスを正しく終了させ、新しいゲームサーバーに置き換えられるようにする必要があります。 複数のセッションでサーバープロセスを再利用しないでください。セッション終了後、 ProcessEnding を呼び出して終了してください。これにより、新しいプロセスの作成と登録が即座にトリガーされます。 サーバーが終了する可能性のあるすべてのパスで Amazon GameLift Servers SDK の ProcessEnding を呼び出してください。これにより、適切にクリーンアップされ、直ちに新しいセッションに置き換えられることが保証されます。 図 2 は、ゲームサーバープロセスのライフサイクルと、すべてのゲームサーバーの実装において考慮すべき重要なステップを示しています。 図 2：ゲームサーバーライフサイクル セッション配置のためのキューとキューイベントの活用 Amazon GameLift Servers キュー は、フリートで直接セッションを作成するよりもいくつかの利点を提供します。 キューの利点として以下があります： 最初のオプションが利用できない場合、セカンダリのフリートロケーションにフェイルオーバーできます 複数のフリートに跨ってセッションを配置できます バックエンドが処理できるセッション配置イベントを提供します レイテンシーとコストに基づいて送信先 ( destination ) を優先順位付けします キューを使用する場合、 StartGameSessionPlacement 呼び出しが使用する必要がある唯一の API です。残りはキューイベントを通じて管理されます。 キューを使用する際のベストプラクティスは以下です： 適切なキャパシティが見つからない場合に配置が失敗と見なすまでの時間を定義するため、キューのタイムアウトを設定してください 。 キューにプレイヤーのレイテンシーを提供する場合は、プレイヤーレイテンシーポリシーを設定してください。ここで設定する制限は現実的なものにしてください。多くのマッチで一部のプレイヤーが到達できないレイテンシー値を待つために長時間待機することは避けるべきです。プレイヤーレイテンシーポリシーがない場合でも、キューにレイテンシーデータを提供すると、このデータに基づいてセッションが配置されます。デフォルトの動作は平均値に基づいて機能しますが、プレイヤーレイテンシーポリシーは最大レイテンシー制限を超えるプレイヤーがいないことを保証します。 ゲームセッション配置の優先順位を定義してください。ほとんどの場合、登録されたすべてのフリートでレイテンシーを優先し、次にコストを考慮するというデフォルトの動作を推奨します。ただし、レイテンシーの品質に関係なく Amazon GameLift Servers Anywhere フリート リソースを最初に使用したい場合は、その送信先を最優先に設定してください。 キューイベントを使用する際のベストプラクティスは以下です： ゲームセッション配置イベントの通知 を受信するために、Amazon Simple Notification Service ( Amazon SNS ) トピックを登録するか、 Amazon EventBridge を使用してください。 AWS Lambda 関数をイベントに登録し、 Amazon DynamoDB などのデータベースにイベントデータを保存したり、WebSocket を介してプレイヤーに直接更新を送信したりできます。Describe API の使用と比較して、イベントの使用は非常にスケーラブルです。 図 3 は、Amazon GameLift Servers キューを活用したゲームセッションの配置と Amazon SNS トピックへのサブスクライブを通じたイベント処理に関する基本的なアーキテクチャ概要を示しています。 図 3：Amazon GameLift Servers キューを活用するための基本的なアーキテクチャ レイテンシポリシーを使用せず、特定のロケーションを優先して正確にセッションを配置する必要がある場合は、 StartGameSessionPlacement リクエストで Priority Configuration Override を定義できます。これは、ゲームデザイン上、プレイヤーが特定のロケーションまたは優先ロケーションのリストから選択できる機能を提供する場合に役立ちます。また、マッチメーカーが各ロケーションのレイテンシーを個別に提供する代わりに、優先順位リストを提供する場合にも役立ちます。 マッチメーカーとして Amazon GameLift Servers FlexMatch を使用している場合、定義したキューとネイティブに統合されます。その後、セッション配置プロセスを追跡するために、キューイベントの代わりに FlexMatch イベントを使用できます。 メトリクス、ログ記録、アラームの設定 環境で何が起きているかを理解する上で、オブザーバビリティは重要です。Amazon GameLift Servers には、これをサポートするいくつかのネイティブ機能があります。ログ、モニタリング、アラームという 3 つの重要な側面について説明します。 ログ コンテナフリートでは、追加のツールやサービスを使用せずに、ゲームサーバーの出力を Amazon CloudWatch または Amazon Simple Storage Service ( Amazon S3 ) に送信するように設定できます。デバッグ時に適切ログファイルを検索できるよう、ゲームサーバーの出力にゲームセッション ID を書き込むようにしてください。EC2 フリートでは、ゲームセッション終了後 14 日以内にログファイルをダウンロードできます。EC2 フリートでも Amazon CloudWatch にログをプッシュしたい場合は、 AWS Game Backend Framework ガイダンスの Amazon GameLift Servers integration が Amazon CloudWatch Agent の設定に役立ちます。 ゲームサーバープロセスからログ出力を生成する際は、ロギングシステムでログの詳細度を定義できるようにすることをお勧めします。開発時にはより詳細なロギングを使用し、本番環境では収集するデータ量を減らすことができます。JSON 形式などの構造化されたログ出力を使用することで、CloudWatch のクエリ機能を活用しやすくなります。 さらに、サイドカーコンテナを実行するか、EC2 フリートの場合はインスタンス上でバックグラウンドエージェントを実行することで、任意のサードパーティログ管理ツールにログ出力を送信できます。 メトリクス Amazon GameLift Servers は広範囲な CloudWatch メトリクス を提供します。これには、フリート内のインスタンスとゲームセッションの情報、キューによる配置時間、リソース使用率メトリクス、その他多くが含まれます。これらのメトリクスは、Amazon GameLift Servers コンソールと CloudWatch で直接利用できます。 監視すべき主要なメトリクスは以下です： リソース使用率： CPUutilization 、 MemoryUtilization （コンテナフリート用）、 NetworkIn/NetworkOut 。これらのメトリクスは、ゲームサーバープロセスのパフォーマンスと使用しているリソース量の概要を提供します。 セッション可用性： PercentAvailableGameSessions 、 AvailableGameSessions 。これらのメトリクスは、フリートの健全性と新しいセッションを配置する能力を示します。 潜在的な問題： UnhealthyInstancesReplaced 、 ServerProcessAbnormalTerminations 。これらのメトリクスは、動作を継続するためのリソースが不足しているインスタンスと、プロセスが正しく終了していない問題を示します。 キューメトリクス： AverageWaitTime 、 PlacementsFailed 、 PlacementsTimedOut 。これらのメトリクスは、プレイヤーがマッチに配置されるまでの速さや、配置の失敗頻度など、キューの健全性の指標を提供します。 ログと同様に、サイドカーコンテナまたは EC2 フリートのエージェントを使用して、他のシステムに関するカスタマーメトリクスを収集できます。これには、Grafana で視覚化できる Prometheus インスタンスでメトリクスを収集する OpenTelemetry エージェントなどのツールやサービスが含まれます。 アラーム アラームは、ゲームバックエンドに問題があることを運用チームに通知するメカニズムです。問題の可能性を示すメトリクスに対して 適切なアラームを作成 する必要があります。これには、 PercentAvailableGameSessions ( 低いまたはゼロ ) 、 ServerProcessAbnormalTerminations 、 UnhealthyInstancesReplaced 、 PlacementsFailed などのメトリクスや、ニーズに関連するその他のメトリクスが含まれます。さらに、 CloudWatch Logs からメトリクスを抽出 し、抽出されたメトリクスに基づいてアラームを作成できます。ログからのメトリクスの迅速な抽出には JSON 形式が推奨されます。 図 4 は、CloudWatch のメトリクスとログを活用して、問題が発生した際にアラームを生成し、オンコールチームに通知する方法の例を示しています。同様のアプローチは、Prometheus でメトリクスを収集し、Grafana で可視化する場合にも適用できます。 図 4：ログとメトリクスに基づくオンコールチームへのアラーム 結論 Amazon GameLift Servers をゲームサーバーホスティングに使用することで、ゲームローンチの成功に向けた運用面で準備を整えるためのベースラインについて説明しました。正しいインスタンスタイプとサーバープロセス、またはコンテナパッキングを選択することで、高性能でコスト最適化された構成を確保する方法について議論しました。また、すべてのアーキテクチャが適切に制御されたイベントベースのセッション配置のためにキューを活用すべき方法についても考察しました。最後に、ログ、モニタリング、アラームの設定が問題の特定とゲームサーバーのパフォーマンスに関する情報収集にどのように役立つかについて議論しました。 シリーズの第 2 回ブログ「Amazon GameLift Servers でローンチを成功させるためのステップ：ローンチフェーズ」では、ゲームローンチの準備についてより深く掘り下げます。 マルチプレイヤーゲームサーバーホスティングのために Amazon GameLift Servers を今すぐ始めましょう。ビジネスの加速にどのように役立つかを学ぶために、 AWS 担当者 にお問い合わせください。 参考資料 Preparing your game for launch Amazon GameLift achieves 100 million concurrently connected users per game Compiling Unreal Engine 5 Dedicated Servers for AWS Graviton EC2 Instances Juho Jantunen Juho Jantunen は、AWS for Games チームのワールドワイドプリンシパルソリューションアーキテクトとして、ゲームバックエンドとゲームサーバーホスティングソリューションに注力しています。ゲーム業界とクラウドテクノロジーのバックグラウンドを持ち、数百万人のプレイヤーを抱える複数のタイトルにおいて、AWS 上でゲームバックエンドの構築と運用を行ってきました。 Sushil Ranganathan Sushil Ranganathan は、Amazon Web Services のシニアテクニカルアカウントマネージャーです。12 年以上の業界経験を持ち、戦略的産業のお客様が AWS クラウド上でエンタープライズ規模のソリューションを構築・運用できるよう支援することに情熱を注いでいます。

はじめに 小売業界では、顧客の購買行動が多様化し、実店舗にもオンラインのようなパーソナライズ体験が求められるようになっています。顧客は自分に最適な提案を受け、迷うことなくスムーズに買い物できる体験を期待するようになりました。こうした背景のもと、AWS は Amazon Bedrock AgentCore を活用し、 PROTO 社のサイネージデバイスと連携したマルチ AI エージェントによる新しい販売支援アプローチを提案しています。本記事では、その全体構成と技術の仕組み、そして店頭に導入された際の顧客側・店舗側それぞれの活用方法について紹介します。 図1. マルチ AI エージェントによる店舗での販売支援ソリューション概要 全体構成 このソリューションの特徴は、複数の AI エージェントがそれぞれの役割を担い、連携して一貫した顧客体験を実現する点にあります。顧客とのコミュニケーションを担う「アバターエージェント」、商品情報を扱う「商品情報エージェント」、店舗運営を支援する「店舗支援エージェント」、そして全体を統制する「オーケストレーターエージェント」が協調して動作します。 これらのエージェントは、Amazon Bedrock AgentCore を中核としたアーキテクチャ上に構築されています。実行基盤には Amazon ECS 、連携制御には AgentCore Gateway 、ステート管理には AgentCore Memory を利用しています。さらに、商品情報は Amazon S3 Vector にベクトルデータとして格納され、顧客との会話データは Amazon DynamoDB に保存されます。 AWS Lambda を用いて外部 API 連携や処理フローを柔軟に実装することで、企業ごとの業務要件に合わせた高度な拡張性を実現しています。 図2. ソリューションデモアーキテクチャ 共有スペース/来店前 アバター店員側の仕組み アバターエージェントは、来店前後を通じて顧客の購買体験を支える重要な存在です。来店前には、Web やスマートフォン経由で顧客の希望カテゴリや用途を音声やチャットでヒアリングし、その情報を店舗と共有します。これにより、顧客が入店した瞬間から、AI が最適な売場や商品を案内できる状態が整います。 店頭では、アバターが自然な対話を通じて商品やフロアを案内します。案内には、 Amazon Transcribe を活用して多言語対応にしています。また、必要に応じて商品比較のポイントやおすすめの組み合わせを Amazon Personalize を用いて提示します。例えば「シンプルなデザインの長袖と華やかなデザインのものを比べて試してみてください」といった会話が自動生成され、顧客の好みに合わせて提案されます。また、多言語理解と音声出力を組み合わせることで、海外からの来店者にも対応可能です。これらの対話内容は AgentCore Memory に蓄積され、顧客体験の改善に役立てられます。 最後に QR コードが払い出され、ユーザーはスマートファンなどで QR コードをかざすと、商品の情報や店舗までの地図が表示されます。さらにその QR コードは店舗側のスタッフに掲示するような流れを作っています。 画像1. PROTO デバイス Type M 動画1. エージェントログによる振る舞いの参考可視化とPROTO デバイスでの表示内容 動画2. モバイル側のデモ 店舗側の仕組み 店舗スタッフにとっても AI エージェントは強力なサポートツールです。AI が事前に顧客の来店目的や希望商品を整理して共有するため、スタッフは来店時点で顧客に最適な提案をスムーズに行えます。店舗スタッフは、事前にユーザーがアバター店員側で取得した QR コードを店員にタブレット端末でスキャンをしてもらいます。タブレット端末には、エージェントAI が事前に生成したセールストークや説明文が提示され、それを基に均質かつ効果的な接客が実現されます。 さらに、顧客がどの商品に興味を示したか、どのような会話がされたかといった情報が掲示され、購買心理に基づく販売支援が可能になります。店舗は AI を通じて常にナレッジを蓄積し、接客の品質を可視化・標準化することができます。AI による支援で人員不足の課題も解消され、スタッフはより創造的な顧客サービスに注力できるようになります。 画像2. AI エージェントが出力した店員が使うタブレットの表示内容 技術アーキテクチャ Amazon Bedrock AgentCore は、AI エージェントを本番運用レベルで安全かつ拡張性高く稼働させるための統合プラットフォームです。その特徴は、AI エージェントの「思考（推論）」「記憶（メモリ）」「行動（ツール実行）」を分離して最適化する設計思想にあります。この仕組みにより、企業は複雑な統合作業を行うことなく、柔軟にエージェント群を構築・拡張できます。 図３．Bedrock Agent Core の機能群 AgentCore Runtime による安全な AI エージェント運用 AgentCore Runtime は、AWSのサーバーレス基盤上で動作するエージェント専用の実行環境です。任意の AI フレームワークで構築したエージェントを「Bedrock AgentCore App」としてコンテナ化し、Amazon ECS または Lambda 経由でスケーラブルに稼働させます。長時間のタスク（最大8時間）や非同期実行をネイティブにサポートしており、たとえば店舗内のアバター案内のような持続的インタラクションにも適しています。また、Runtime はマルチエージェント間の通信チャネルを MCP（Model Communication Protocol）で統一しているため、異なる言語モデルやバックエンドでも相互協調が可能です。 AgentCore Gateway による多様な外部サービス連携 AgentCore Gatewayは、外部のAPI・Lambda 関数・社内システムをエージェント互換ツールとして自動登録・接続する中枢です。開発者は既存の API 仕様（ OpenAPI や Smithy など）をそのまま用いて、MCP 互換ツールとして登録できます。これにより、POS システムや在庫 DB などを AI エージェントがアクセスできるようになります。さらに、Gateway にはツール検索用のセマンティックディスカバリー機構が組み込まれており、複数エージェント間で動的に最適なツールを呼び出せます。店舗支援エージェントが在庫を確認し、アバターエージェントに結果を返すような非同期連携を実現する中核がこの Gateway です。 AgentCore Memory による顧客体験の蓄積と進化 AgentCore Memory は、エージェントが顧客との過去の対話を知識として再利用するための永続記憶レイヤーです。短期記憶は直前の会話コンテキストを保持し、長期記憶は複数セッションにまたがる行動履歴や嗜好情報を蓄積します。単なるテキスト保存ではなく、発話内容の意味抽出・統合・重複排除を行うAI 駆動の「知識整理プロセス」が特徴的です。たとえば、顧客が「昨年は青いシャツが好み」と発言した情報を参照し、翌年の来店時に「今年は同系色の新作をおすすめします」と提案するような連続的な体験を提供できます。この構造により、AI エージェントは「覚えている」だけでなく、「理解して進化する」存在へと近づいています。 AgentCore IdentityとObservability による運用セキュリティと可視化 企業利用を前提とした統合認証基盤も、AgentCore の大きな強みです。 AgentCore Identity は、IAM および Cognito を活用してマルチサービス間の権限とユーザー認証を統一管理します。これにより、どのエージェントがどのツールにアクセスできるかを厳密に制御できます。 Observability コンポーネントでは、CloudWatch・OpenTelemetry 連携を通してエージェントの挙動や消費コスト、エラー発生率を可視化し、運用チームがプロアクティブに調整可能です。特に、企業規模でマルチ AI エージェントを運用する際のトレーサビリティと説明責任を確保するうえで、この仕組みは欠かせません。 AgentCore Browser による Web 連携自動化 AgentCore Browser は、AI エージェントにヘッドレス環境でウェブページの自動操作能力を提供します。画面を表示せず、裏側で Web サイトの閲覧や情報抽出、フォーム入力などを安全かつサンドボックス内で行えるため、店舗スタッフが価格調査や在庫確認を依頼するだけで、AI が Web 上の必要な業務を迅速に自動化します。現場の効率化と幅広い外部情報連携が可能となり、店舗 DX の中核技術として注目されています。 AgentCore Code Interpreter による店舗業務の自動化と高度分析 AgentCore Code Interpreter はエージェントによるコード実行・データ分析・レポート生成を可能にしたサンドボックス型のマネージド実行環境です。会話から生まれた業務要望があった際、エージェントはブラウザ操作や外部データ取得に加え、リアルタイムの集計・グラフ化・予測解析まで一貫して自律的に実施できます。たとえば「店舗ごとの売上データを集計し、週ごとの増減をグラフ化して、Excel 形式で提出」「最新の販売結果から、次回発注数量を Python で計算」など、これまで人手と複雑なシステム連携が必要だった分析業務が、自然言語指示のみで完結します。大容量データ処理や複雑な条件分岐も、Code Interpreter のセキュアサンドボックス内で実行され、API 連携や IAM 統合によって権限管理も万全です。店頭とクラウドが一体化した展開により、業務フローの高度化と省力化を両立できる土台となります。 エージェント連携設計の核心 こうした構成の中で、重要なのは「各エージェントが独立しながらも共有知を持つ」という設計です。販売支援の現場では、アバター、商品推薦、店舗オペレーションという異なる領域のAIが、共通メモリを介してスムーズに協調します。AgentCore はこの協調制御（Orchestration）をネイティブサポートし、オーケストレーターエージェントが会話ログ・ツール呼び出し・状態管理を一元的に制御します。この仕組みによって、個々の応答だけでなく「一貫した店舗全体体験」をAIが提供できます。 今後の展望 今後は、顧客行動ログと売上データを統合し、AI が販売戦略を自律的に最適化するフェーズへと発展していくことが期待されます。また、Amazon Bedrock の進化に伴い、エージェント間の協調精度や自然対話能力が高まることで、より人間らしい接客体験の実現が可能になるでしょう。AWS は、こうした次世代店舗モデルの実現に向けて、企業と共にリアルな価値創造を支援し続けます。 おわりに AI が店舗運営を支える時代は、すでに目の前にあります。マルチ AI エージェントによる販売支援は、単なる自動化ではなく、「顧客と人のあいだにある理想的な接客体験」を形にするものです。Amazon Bedrock AgentCore を活用することで、企業は短期間で柔軟な AI 接客システムを立ち上げ、顧客満足と業務効率を両立させることができます。これからも AWS は、小売業をはじめとする多様な業種において、AI が創り出す新たなビジネス体験をともに実現していきます。 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲食やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについて顧客に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。 川路 義隆（Yoshitaka Kawaji）/ @kawaji_scratch 担当業界は小売業、技術面ではServerless・AI-DLC・アジャイル開発などの領域で業界を問わずお客様をご支援しています。 趣味はJAWS-UGコミュニティの運営支援で、全国各地のイベントに参加しています。 飯野 善行（Yoshiyuki Iino） 主に小売業界のお客様を支援するソリューションアーキテクトです。生成 AI エージェントやベクトルデータベースの技術を使った提案機会が増えてきたことを嬉しく思っています。休日はカメラと重量級のレンズを持ってロードバイクで出かけます。

10 月 13 日週は、 英国 AWS ユーザーグループの第 1 回 AWS AI in Practice ミートアップ に出席しました。この夜のフォーカスは、AI 支援ソフトウェア開発とエージェントでした! 10 月 20 日週はイタリアで Codemotion (ミラノ) と AWS ユーザーグループのミートアップ (ローマ) に参加します。また、AI を活用した研究、ビジネスインテリジェンス、自動化機能を単一のワークスペースにまとめた 新しい Amazon Quick Suite を試してみる のも楽しみです。 10 月 6 日週のリリース 私が 10 月 13 日週に注目したリリースをご紹介します。 Amazon Quick Suite – 職場での質問にすばやく回答し、インサイトをアクションに変換する新しいエージェンティックチームメイトです。 詳細については、Esra によるリリース記事をご覧ください 。 Amazon EC2 – 第 5 世代 AMD EPYC (コードネーム Turin) プロセッサを搭載した汎用 M8a インスタンス と、カスタム Intel Xeon 6 プロセッサを搭載しコンピューティング最適化された C8i および C8i-Flex インスタンス が利用可能になりました。 Amazon EKS – EKS と EKS Distro でいくつかの改善が実施され、 Kubernetes バージョン 1.34 のサポートが開始 されました。 AWS IAM アイデンティティセンター – AWS Key Management Service キーを使用して、 IAM アイデンティティセンター組織インスタンスに保存されている ID データを暗号化 できるようになりました。 Amazon VPC Lattice – リソースゲートウェイの Elastic Network Interface (ENI) に割り当てられる IPv4 アドレスの数を設定 できるようになりました。IPv4 アドレスはネットワークアドレス変換に使用され、リソースへの同時 IPv4 接続の最大数を決定します。 Amazon Q Developer – Amazon Q Developer は、 AWS の製品とサービスの価格、可用性、属性に関する情報の入手 をお手伝いします。これにより、自然言語を使用して適切なリソースを選択し、ワークロードコストを見積もることが容易になります。 このブログ記事で詳細をご覧ください 。 Amazon RDS for Db2 – データベースレベルのネイティブバックアップを実行 できるようになり、データベースの管理と移行の柔軟性が向上しました。 AWS Service Quotas – 自動クォータ管理 でクォータ使用量の通知を受け取ることができます。E メール、SMS、Slack など、お好みの通知チャネルを設定できます。通知は AWS Health でも利用可能で、自動化ワークフロー向けの関連する AWS Cloudtrail イベントをサブスクライブできます。 Amazon Connect – 新しいケース API を使用してケースデータをプログラムで強化 し、関連するケースのリンク、カスタム関連項目の追加、複数のケースの検索を実行できるようになりました。また、特定のニーズに合わせて サービスレベル計算をカスタマイズ できるようになりました。導入されたばかりの新機能には、 エージェントのスケジュール設定のコピーと一括編集 と エージェントスケジュール遵守通知 が含まれます。 AWS Client VPN – MacOS Tahoe のサポートを開始しました 。 その他のアップデート その他の興味深いプロジェクト、ブログ記事、ニュースをいくつかご紹介します。 サーバーレス ICYMI Q3 2025 – 見逃した方のために、サーバーレスニュースを四半期ごとにまとめています。 Amazon MWAA で Apache Airflow 2.x から Apache Airflow 3.x に移行するためのベストプラクティス – 新しいリリースの利点を活用するのに役立つガイドです。 Amazon EKS と Amazon S3 Vectors を使用したセルフマネージド RAG アプリケーションの構築 – Ray 、 Hugging Face 、 LangChain などのオープンソースツールを使用してセルフマネージド RAG アプリケーションを構築およびデプロイするためのリファレンスアーキテクチャです。 BBVA: 複数リージョンや複数国でのグローバルデータおよび ML プラットフォームの大規模な構築 – 銀行セクターにおける最大かつ最も複雑なクラウド移行の 1 つによって、 BBVA のデータ分析インフラストラクチャ全体を変革するまでのジャーニーを、6 部構成の連載でご紹介します。 Amazon Nova を使用したテキストコンテンツモデレーションのカスタマイズ – ドメイン固有のトレーニングデータと組織固有のモデレーションガイドラインを使用して、お客様の要件に合わせたコンテンツモデレーションタスクを実現するためファインチューニングされています。 近日開催予定の 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 月 16 日)。 AWS Builder Center に参加して、AWS コミュニティのビルダーを学び、構築し、交流しましょう。 近日開催予定の対面イベント 、 開発者に焦点を当てたイベント 、 スタートアップ向けのイベント はこちらからご覧ください。 10 月 13 日週のニュースは以上です。10 月 20 日週にお届けする次回の Weekly Roundup もお楽しみに! – Danilo 原文は こちら です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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