みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 AWS Bedrock AgentCore の一般提供開始を受け、私たちリテールチームは、店舗への導入ですぐに価値を発揮できるソリューションとして、マルチ AI エージェントによる販売支援を提案しています。実際に実機のデジタルサイネージを用いたデモをイベントなどで展示し、その内容をブログにまとめました。ぜひこちらもご覧ください。 マルチ AI エージェントが創る新しい店舗体験 〜Amazon Bedrock AgentCoreによる販売支援〜 こちらのデモは、10/28(火)-30(木)で開催される Gartner IT Symposium での展示予定となっております。 それでは、先週の主なアップデートについて振り返っていきましょう。 2025年10月13日週の主要なアップデート 10/13(月) Amazon CloudWatch で生成 AI オブザーバビリティが一般提供開始 Amazon CloudWatch で生成 AI オブザーバビリティ機能が一般提供開始となりました。AI アプリケーション全体の監視が可能になり、レイテンシーやトークン使用量、エラーをリアルタイムで把握できます。LangChain や LangGraph などのフレームワークにも対応し、問題の迅速な特定が可能です。追加料金なしで利用できます。詳細は こちらのドキュメントをご参照ください。 Amazon Bedrock AgentCore が一般提供開始 Amazon Bedrock AgentCore が一般提供開始されました。このサービスは AI エージェントを簡単に構築・運用できるプラットフォームです。従来は複雑だったエージェント開発が、インフラ管理不要で実現できるようになりました。最大 8 時間の長時間実行や VPC サポートによる安全なプライベート環境での運用が可能です。CrewAI や LangGraph などの人気フレームワークに対応し、CloudWatch で運用状況を監視できます。東京リージョンを含む 9 リージョンで利用でき、従量課金制で初期費用は不要です。詳細は こちらの Blog 記事をご参照ください。 Amazon SageMaker AI Projects がカスタムテンプレートの S3 プロビジョニングをサポート Amazon SageMaker AI Projects で、Amazon S3 からカスタム ML プロジェクトテンプレートをプロビジョニングできるようになりました。これまで管理者は標準的な ML プロジェクトテンプレートの管理が困難でしたが、今回のアップデートにより S3 上でテンプレートを管理し、データサイエンティストが SageMaker AI Studio から直接アクセスできます。組織の要件に合った標準化された ML 開発ワークフローを簡単に構築でき、全社的な ML プロジェクトの品質向上とガバナンス強化が実現します。詳細は こちらのドキュメントをご参照ください。 10/14(火) Amazon MSK Connect が 10 の追加 AWS リージョンで利用可能に Amazon MSK Connect が 10 の新しいリージョン (ジャカルタ、香港、大阪、メルボルンなど) で利用可能になりました。MSK Connect は Apache Kafka のデータ連携を完全マネージドで実現するサービスです。データベースやファイルシステムなどの外部システムと Kafka 間でデータを移動するコネクターを、インフラ管理不要で簡単にデプロイできます。従来は自分でサーバーを管理する必要がありましたが、これで使った分だけの課金で自動スケールが可能になります。詳細は こちらのドキュメントをご参照ください。 Amazon Route 53 Profiles が AWS PrivateLink をサポート開始 Amazon Route 53 Profiles が AWS PrivateLink をサポート開始しました。従来はパブリックインターネット経由でのアクセスが必要でしたが、今回のアップデートでプライベートネットワーク経由での安全なアクセスが可能になりました。Route 53 Profiles は複数の VPC に統一された DNS 設定を適用できるサービスで、今回セキュリティが大幅に向上しました。詳細は こちらのドキュメントをご参照ください。 Amazon AppStream 2.0 がライセンス込み Microsoft アプリケーションの提供を発表 Amazon AppStream 2.0 で Microsoft Office や Visio、Project 2021/2024 がライセンス込みで利用できるようになりました。これまでは別途ライセンスの準備が必要でしたが、今回のアップデートにより AWS が提供するライセンス込みバージョンを直接利用可能です。リモートワークや在宅勤務で Microsoft アプリケーションを安全にクラウド経由で提供したい企業にとって、ライセンス管理の手間が大幅に削減されます。詳細は こちらのドキュメントをご参照ください。 10/15(水) Amazon Aurora PostgreSQL と Amazon SageMaker のゼロ ETL 統合が利用可能に Amazon Aurora PostgreSQL が SageMaker Lakehouseとの zero-ETL 統合をサポート開始しました。これまで複雑な ETL プロセスが必要だったデータ分析が、リアルタイムに近い形で可能になります。PostgreSQL のデータを自動的にデータレイクハウスに同期し、Apache Iceberg 互換形式で SQL や Spark、機械学習ツールから直接利用できます。ノーコードで設定でき、本番環境への影響もありません。詳細は こちらのドキュメントをご参照ください。 Amazon Bedrock がサーバーレス基盤モデルの自動有効化によりアクセスを簡素化 Amazon Bedrock で、サーバーレス基盤モデルへのアクセスが自動で有効化されるようになりました。従来は手動でモデルアクセスを有効化する必要がありましたが、今回のアップデートで全商用リージョンにおいて即座に AI モデルを利用開始できます。Amazon Bedrock コンソールや AWS SDK から直ちにアクセス可能で、開発効率が大幅に向上します。ただし Anthropic モデルのみ初回利用時に一度だけ使用フォームの提出が必要です。詳細は こちらの Blog 記事をご参照ください。 Anthropic の Claude 4.5 Haiku が Amazon Bedrock で利用可能に Amazon Bedrock で Claude Haiku 4.5 が利用可能になりました。Claude Sonnet 4 並みの高性能でありながら、大幅にコストを抑えて高速処理を実現しています。リアルタイムのカスタマーサポートやチャットボットなど、レスポンス速度が重要なアプリケーションに最適です。従来は性能とコストのどちらかを諦める必要がありましたが、両方を兼ね備えた AI モデルが使えるようになりました。 10/16(木) AWS Security Hub CSPM が CIS AWS Foundations Benchmark v5.0 をサポート開始 AWS Security Hub CSPM で CIS AWS Foundations Benchmark v5.0 がサポート開始されました。この業界標準のベンチマークには 40 のコントロールが含まれ、AWS リソースのセキュリティ設定を自動チェックできます。従来版から最新のセキュリティ要件に対応し、組織全体のアカウントで一括有効化も可能です。セキュリティ設定の見落としを防ぎ、コンプライアンス対応が効率化されます。詳細は こちらのドキュメントをご参照ください。 Amazon EC2 がライセンス込みインスタンスの CPU オプション最適化をサポート Amazon EC2 でライセンス込み Windows インスタンスの CPU オプション最適化が可能になりました。これまで固定だった vCPU 数やハイパースレッディングを調整できるようになり、Microsoft SQL Server などの vCPU ベースライセンス費用を大幅削減できます。例えば r7i.8xlarge インスタンスでハイパースレッディングを無効にすることで、32 vCPU を 16 vCPU に削減し、ライセンス費用を 50% 節約しながら、メモリ 256 GiB と IOPS 40,000 の性能は維持可能です。詳細は こちらの Blog 記事をご参照ください。 Amazon Location Service が強化されたカスタマイゼーションのための新しいマップスタイリング機能を導入 Amazon Location Service で新しい地図スタイリング機能が利用可能になりました。地形の可視化、等高線表示、リアルタイム交通情報、交通手段別ルーティングなどが追加され、用途に応じたカスタマイズが可能です。物流アプリではトラック専用ルートの制限情報を表示したり、アウトドアアプリでは標高や地形の詳細を可視化できます。従来の基本的な地図表示から、より実用的で詳細な地図アプリケーションの開発が実現できるようになりました。詳細は こちらの Developer Guide をご参照ください。 10/17(金) AWS Systems Manager Patch Manager が Windows 向けセキュリティ更新通知を開始 AWS Systems Manager Patch Manager で Windows 向けセキュリティ更新通知機能がリリースされました。この機能により、パッチベースラインで承認されていないセキュリティ更新を AvailableSecurityUpdate 状態として識別できます。これまで ApprovalDelay などを使用する際に、意図せずインスタンスがパッチ未適用のままになるリスクがありましたが、デフォルトで Non-Compliant として明確に表示されるため、セキュリティパッチの見落としを防げます。詳細は こちらのドキュメントをご参照ください。 Amazon EC2 Capacity Manager の発表 Amazon EC2 Capacity Manager が一般提供開始されました。これまで複数のアカウントやリージョンにまたがる EC2 容量の管理は煩雑でしたが、単一のインターフェースで一元管理できるようになりました。On-Demand、Spot、Capacity Reservation の使用状況をダッシュボードで可視化し、履歴トレンドや最適化の機会も確認できます。全商用リージョンで追加コストなしで利用可能です。詳細は こちらの Blog 記事をご参照ください。 CloudWatch Database Insights でタグベースアクセス制御をサポート開始 Amazon CloudWatch Database Insights で、タグベースアクセス制御がサポート開始されました。これまで RDS や Aurora インスタンスに設定したタグが Performance Insights のメトリクスに適用されず、データベースリソースごとに個別で権限設定する必要がありましたが、今回のアップデートでインスタンスのタグが自動評価されるようになりました。IAM ポリシーでタグベースアクセス条件を定義でき、複数のデータベースを論理的にグループ化した権限管理が可能です。詳細は こちらのドキュメントをご参照ください。 もうすぐ 今年もラスベガスにて、 AWS re:Invent が開催されます。私は、BuildersFair のコーナーにて、LLM を活用したロボットのデモ展示対応をしております。ぜひ遊びにきてください。 それでは、また来週お会いしましょう！ 著者について 戸塚 智哉(Tomoya Tozuka) / @tottu22 飲料やフィットネス、ホテル業界全般のお客様をご支援しているソリューション アーキテクトで、AI/ML、IoT を得意としています。最近では AWS を活用したサステナビリティについてお客様に訴求することが多いです。 趣味は、パデルというスペイン発祥のスポーツで、休日は仲間とよく大会に出ています。

本記事は、2025 年 10 月 7 日に公開された Best practices for migrating from Apache Airflow 2.x to Apache Airflow 3.x on Amazon MWAA を翻訳したものです。翻訳はクラウドサポートエンジニアの山本が担当しました。 Amazon MWAA の Apache Airflow 3.x では、セキュリティと分離性を強化する API ベースのタスク実行など、アーキテクチャの改善が導入されています。その他の主要なアップデートには、ユーザーエクスペリエンスを向上させた UI の再設計、パフォーマンスを改善したスケジューラーベースのバックフィル、 Python 3.12 のサポートが含まれています。Amazon MWAA における Airflow のマイナーバージョンのインプレースアップグレードとは異なり、Airflow 2 から Airflow 3 へのアップグレードには根本的な破壊的変更があるため、慎重な計画と移行アプローチによる実行が必要です。 この移行は、ビジネス継続性を確保しながら、次世代のワークフローオーケストレーション機能を導入する機会となります。しかし、これは単なるアップグレードではありません。Amazon MWAA で Airflow 3.x に移行する組織は、ワーカーからのメタデータデータベースへの直接アクセスの削除、SubDAG の廃止、デフォルトのスケジューリング動作の変更、ライブラリ依存関係の更新など、破壊的変更を理解する必要があります。この記事では、ミッションクリティカルなデータパイプラインへの影響を最小限に抑えながら、Airflow 3 の強化された機能を最大限に活用するための、ベストプラクティスとして合理的なアプローチを提供します。 移行プロセスの理解 Amazon MWAA における Airflow 2.x から 3.x への移行には、組織が移行を開始する前に理解しておくべき、いくつかの基本的な変更が含まれています。これらの変更は主要なワークフローの操作に影響を与えるため、スムーズな移行を実現するには慎重な計画が必要です。 以下の破壊的な変更に注意してください： 直接的なデータベースアクセスの削除 – Airflow 3 における破壊的変更は、ワーカーノードからのメタデータデータベースへの直接アクセスができなくなったことです。タスクとカスタムオペレーターは、直接的なデータベースアクセスではなく REST API を介して通信する必要があります。この設計変更は、以前 SQLAlchemy 接続を通じてメタデータデータベースに直接アクセスしていたコードに影響を与え、既存の DAG とカスタムオペレーターのリファクタリングが必要になります。 SubDAG の廃止 – Airflow 3 では、TaskGroups、Assets、Data Aware Scheduling を優先し、SubDAG 構造を削除します。組織は既存の SubDAG を前述のいずれかの構造にリファクタリングする必要があります。 スケジューリング動作の変更 – デフォルトのスケジューリングオプションに関する 2 つの注目すべき変更により、影響分析が必要です： catchup_by_default と create_cron_data_intervals のデフォルト値が False に変更されました。この変更は、これらのオプションを明示的に設定していない DAG に影響を与えます。 Airflow 3 では、execution_date、tomorrow_ds、yesterday_ds、prev_ds、next_ds などのいくつかのコンテキスト変数が削除されます。これらの変数を、現在サポートされているコンテキスト変数に置き換える必要があります。 ライブラリと依存関係の変更 – Airflow 3.x では多数のライブラリが変更され、DAG コードのリファクタリングが必要になります。以前に含まれていた多くのプロバイダーパッケージは、 requirements.txt ファイルに明示的に追加する必要が場合があります。 REST API の変更 – REST API のパスが /api/v1 から /api/v2 に変更され、外部統合に影響を与えます。Airflow REST API の使用に関する詳細については、 ウェブサーバーセッショントークンを作成し、Apache Airflow REST API を呼び出す をご参照ください。 認証システム – Airflow 3.0.1 以降のバージョンでは Flask-AppBuilder の代わりに SimpleAuthManager がデフォルトになりますが、Amazon MWAA は Airflow 3.x でも引き続き Flask-AppBuilder を使用します。これは、Amazon MWAA のお客様には認証の変更が発生しないことを意味します。 この移行では、インプレースアップグレードではなく、新しい環境を作成する必要があります。このアプローチはより多くの計画とリソースを必要としますが、移行プロセス中にフォールバックオプションとして既存の環境を維持できるという利点があり、ビジネスの継続性を確保できます。 移行前の計画と評価 移行を成功させるには、現在の環境を徹底的に計画し評価することが重要です。この段階では、依存関係、構成、潜在的な互換性の問題を特定することで、スムーズな移行の基盤を確立します。前述の互換性に影響する変更点に照らして環境とコードを評価し、移行を成功に導きましょう。 環境評価 まず、現在の Amazon MWAA 環境の完全なインベントリを作成します。すべての DAG、カスタムオペレーター、プラグイン、依存関係について、それぞれの特定のバージョンと構成を含め文書化します。Airflow 3.x を搭載した Amazon MWAA へのアップグレードに最適な互換性パスを提供するため、現在の環境がバージョン 2.10.x であることを確認してください。 DAG コード、requirements ファイル、起動スクリプト、プラグインが含まれている Amazon Simple Storage Service (Amazon S3) バケットの構造を確認します。この構造を新しい環境用の新しいバケットに複製します。環境ごとに個別のバケットを作成することで、競合を回避し、現在のパイプラインに影響を与えることなく開発を継続できます。 設定ドキュメント すべてのカスタム Amazon MWAA 環境変数、Airflow 接続、環境設定を文書化してください。新しい環境の実行ロールには同一のポリシーが必要となるため、 AWS Identity and Access Management (IAM) の リソース を確認してください。Airflow UI にアクセスする IAM ユーザーまたはロールには、新しい環境に対する CreateWebLoginToken 権限が必要です。 パイプラインの依存関係 パイプラインの依存関係を理解することは、段階的な移行を成功させるために重要です。Datasets (現在は Assets )、SubDAG、TriggerDagRun オペレーター、または外部 API との連携を通じて相互依存関係を特定してください。これらの依存関係に基づいて移行計画を立て、関連する DAG を同時に移行できるようにします。 移行ウェーブを計画する際は、DAG のスケジューリング頻度を考慮してください。実行間隔が長い DAG は、頻繁に実行される DAG と比較して、より長い移行期間を確保でき、重複実行のリスクも低くなります。 テスト戦略 互換性の問題を特定するための体系的なアプローチを定義して、テスト戦略を作成します。 ruff linter を AIR30 ルールセットと共に使用して、更新が必要なコードを自動的に特定します。 ruff check --preview --select AIR30 <path_to_your_dag_code> 次に、環境の requirements.txt ファイルを確認し、パッケージのバージョンが更新された制約ファイルに準拠するように更新してください。また、以前は airflow-core パッケージに含まれていた一般的に使用されるオペレーターは、現在は別のパッケージに移動されているため、requirements ファイルに追加する必要があります。 Airflow 3.x 用の Amazon MWAA Docker イメージ を使用して DAG をテストします。これらのイメージを使用することで、requirements ファイルの作成とテスト、そしてスケジューラーが DAG を正常にパースすることを確認できます。 移行戦略とベストプラクティス 体系的な移行アプローチにより、明確な検証チェックポイントを提供しながら、リスクを最小限に抑えることができます。推奨される戦略は、信頼性の高い移行と即時のロールバック機能を提供する段階的ブルー/グリーンデプロイメントモデルを採用しています。 段階的な移行のアプローチ 以下の移行フェーズは、移行計画の定義に役立ちます。 フェーズ 1: 発見、評価、計画 – このフェーズでは、環境のインベントリ、依存関係のマッピング、変更による影響の分析を完了します。収集した情報を基に、詳細な移行計画を策定します。この計画には、コードの更新、requirements ファイルの更新、テスト環境の作成、テスト、ブルー/グリーン環境の作成 (この記事の後半で説明)、および移行手順が含まれます。また、計画には、トレーニング、モニタリング戦略、ロールバック条件、ロールバック計画も含める必要があります。 フェーズ 2: パイロット移行 – パイロット移行フェーズでは、影響範囲が限定された管理環境で詳細な移行計画の検証を行います。異なるスケジュールや依存関係など、多様な特性を持つ 2 ～ 3 個の重要度の低い DAG にフォーカスします。前のフェーズで定義した移行計画を使用して、選択した DAG を移行します。このフェーズを活用して計画とモニタリングツールを検証し、実際の結果に基づいて両者を調整します。パイロット中に、完全な移行のパフォーマンスを予測するのに役立つ基準となる移行メトリクスを確立します。 フェーズ 3: 段階的な本番移行 – パイロットが成功したら、残りの DAG の段階的な完全移行を開始する準備が整います。残りの DAG を、ビジネスの重要度 (重要度の低いものから開始)、技術的な複雑さ、相互依存関係 (依存関係のある DAG をまとめて移行)、スケジュールの頻度 (実行頻度の低い DAG は移行に時間を確保できる) に基づいて論理的なウェーブにグループ化します。ウェーブを定義したら、ステークホルダーと協力してウェーブスケジュールを作成します。次のウェーブを開始する前に、ウェーブが成功したことを確認するための十分な検証期間を設けます。この時間は、移行の問題が発生した場合の影響範囲を抑え、ロールバックを実行するための十分な時間も確保します。 フェーズ 4: 移行後のレビューと廃止 – すべてのウェーブが完了したら、得られた知見、最適化の機会、その他の未解決の項目を特定するために移行後のレビューを実施します。これはシステムの安定性を承認するのにも適した時期です。最後のステップは、元の Airflow 2.x 環境の廃止です。ビジネス要件と意見に基づいて安定性が確認されたら、元の (ブルー) 環境を廃止します。 ブルー/グリーンデプロイメント戦略 安全で元に戻せる移行のために、ブルー/グリーンデプロイメント戦略を実装します。この戦略では、移行中に 2 つの Amazon MWAA 環境が稼働し、どの DAG をどの環境で実行するかを管理します。 ブルー環境 (現行の Airflow 2.x) は、移行中に本番ワークロードを維持します。移行前に DAG の変更に対する停止期間を設定することで、直前のコードの競合を回避できます。この環境は、新しい (グリーン) 環境で問題が特定された場合の即時ロールバック環境として機能します。 グリーン環境 (新しい Airflow 3.x) は、制御された段階で移行された DAG を受け取ります。ブルー環境からネットワーク、IAM ロール、セキュリティ設定をミラーリングします。この環境はブルー環境と同じオプションで構成し、同一の監視メカニズムを作成して、両環境を同時に監視できるようにします。DAG の重複実行を避けるため、DAG が単一の環境でのみ実行されるようにしてください。これには、グリーン環境で DAG をアクティブ化する前に、ブルー環境で DAG を一時停止することが含まれます。移行全体を通じて、ブルー環境をウォームスタンバイモードで維持します。各移行段階での具体的なロールバック手順を文書化し、少なくとも 1 つの重要度の低い DAG でロールバック手順をテストしてください。さらに、ロールバックのトリガー基準（特定の失敗率や SLA 違反など）を明確に定義してください。 段階的な移行プロセス このセクションでは、移行を実施するための詳細な手順を説明します。 移行前の評価と準備 移行プロセスを開始する前に、現在の環境を徹底的に評価し、移行計画を策定してください。 現在の Amazon MWAA 環境がバージョン 2.10.x であることを確認してください DAG、カスタムオペレーター、プラグインについて、それらの依存関係とバージョンを含む詳細なインベントリを作成してください 現在の requirements.txt ファイルを確認し、パッケージの要件を理解してください すべての環境変数、接続、設定を文書化してください Apache Airflow 3.x リリース ノートを確認し、破壊的変更を理解してください 移行の成功基準、ロールバック条件、ロールバック計画を決定してください パイロット移行に適した少数の DAG を特定してください Amazon MWAA ユーザーに対する Airflow 3 のトレーニングまたは習熟計画を策定してください 互換性のチェック 互換性の問題を特定することは、移行を成功させる上で重要です。このステップにより、開発者は Airflow 3 と互換性のない特定のコードに焦点を当てることができます。 ruff linter を AIR30 ルールセットと共に使用して、更新が必要なコードを自動的に特定します。 ruff check --preview --select AIR30 <path_to_your_dag_code> さらに、 メタデータベースへの直接アクセス がコードに含まれていないか確認してください。 DAG コードの更新 互換性テストの結果に基づいて、Airflow 3.x に影響を受ける DAG コードを更新してください。ruff DAG チェックユーティリティを使用すると、一般的な変更を自動的に修正できます。以下のコマンドを使用して、更新モードでユーティリティを実行してください： ruff check dag/ --select AIR301 --fix ––preview 一般的な変更点は以下の通りです: メタデータベースへの直接アクセスを API 呼び出しに置き換える： # Before (Airflow 2.x) - Direct DB access from airflow.settings import Session from airflow.models.taskInstance import TaskInstance session=Session() result=session.query(TaskInstance) For Apache Airflow v3.x, utilize in the Amazon MWAA SDK. Update core construct imports with the new Airflow SDK namespace: # Before (Airflow 2.x) from airflow.decorators import dag, task # After (Airflow 3.x) from airflow.sdk import dag, task 非推奨のコンテキスト変数を最新の同等のものに置き換える： # Before (Airflow 2.x) def my_task(execution_date, **context): # Using execution_date # After (Airflow 3.x) def my_task(logical_date, **context): # Using logical_date 次に、2 つのスケジューリング関連のデフォルト変更の使用状況を評価します。 catchup_by_default が False になったため、欠落した DAG の実行は自動的にバックフィルされなくなりました。バックフィルが必要な場合は、DAG の定義を catchup=True に更新してください。DAG にバックフィルが必要な場合は、この移行とバックフィルの影響を考慮する必要があります。履歴のないクリーンな環境に DAG を移行するため、バックフィルを有効にすると、指定された start_date から始まるすべての実行に対して DAG 実行が作成されます。不要な実行を避けるため、start_date の更新を検討してください。 create_cron_data_intervals も False になりました。この変更により、cron 式は CronTriggerTimetable コンストラクトとして評価されます。 最後に、手動および Asset トリガーの DAG に対する 非推奨のコンテキスト変数 の使用状況を評価し、適切な代替コードに更新してください。 requirements の更新とテスト パッケージバージョンの変更に加えて、airflow-core パッケージに含まれていた複数の Airflow コアオペレーターが apache-airflow-providers-standard パッケージに移行されました。これらの変更は、 requirements.txt ファイルに反映する必要があります。requirements ファイルでパッケージバージョンを指定 (固定) することはベストプラクティスであり、この移行でも推奨されています。requirements ファイルを更新するには、以下の手順を実行します： Amazon MWAA Docker イメージをダウンロードして設定します。詳細については、 GitHub リポジトリ を参照してください。 現在の環境の requirements.txt ファイルを新しいファイルにコピーします。 必要に応じて、新しい requirements ファイルに apache-airflow-providers-standard パッケージを追加します。 対象の Airflow バージョンに適した Airflow constraints ファイルを作業ディレクトリにダウンロードします。constraints ファイルは、Airflow バージョンと Python バージョンの組み合わせごとに用意されています。URL は以下の形式になります： https://raw.githubusercontent.com/apache/airflow/constraints-${AIRFLOW_VERSION}/constraints-${PYTHON_VERSION}.txt バージョン指定のない requirements ファイルと constraints ファイルを使用して、バージョン指定された requirements ファイルを作成します。requirements ファイルの作成ガイダンスについては、 requirements.txt ファイルの作成 を参照してください。次のステップに進む前に、依存関係の競合がないことを確認してください。 Docker イメージを使用して requirements ファイルを検証します。実行中のコンテナ内で以下のコマンドを実行します： ./run.sh test-requirements インストールエラーが発生した場合は、パッケージのバージョンを更新して対処します。 ベストプラクティスとして、Amazon MWAA へのデプロイ用にパッケージを ZIP ファイルにパッケージ化することをお勧めします。これにより、すべての Airflow ノードに同じパッケージが確実にインストールされます。依存関係のパッケージ化に関する詳細については、 PyPI.org 要件ファイルフォーマットを使用した Python 依存関係のインストール を参照してください。 新しい Amazon MWAA 3.x 環境の作成 Amazon MWAA はメジャーバージョンアップグレードに移行アプローチを必要とするため、ブルー/グリーンデプロイメント用に新しい環境を作成する必要があります。この記事では例として AWS Command Line Interface (AWS CLI) を使用しますが、Infrastructure as Code (IaC) を使用することもできます。 現在の S3 バケットと同じ構造で新しい S3 バケットを作成します。 更新された requirements ファイルとプラグインパッケージを新しい S3 バケットにアップロードします。 新しい環境設定のテンプレートを生成します： aws mwaa create-environment --generate-cli-skeleton > new-mwaa3-env.json 生成された JSON ファイルを変更します： 既存の環境から設定をコピーします。 環境名を更新します。 AirflowVersion パラメータをターゲットの 3.x バージョンに設定します。 S3 バケットのプロパティを新しい S3 バケット名で更新します。 必要に応じて他の設定パラメータを確認し更新します。 既存の環境と同じネットワーク設定、セキュリティグループ、IAM ロールで新しい環境を設定します。これらの設定については、 Amazon MWAA ユーザーガイド を参照してください。 新しい環境を作成します： aws mwaa create-environment --cli-input-json file://new-mwaa3-env.json メタデータの移行 新しい環境には、同じ変数、接続、ロール、プールの設定が必要です。このセクションを、これらの情報の移行ガイドとして使用してください。 AWS Secrets Manager をシークレットのバックエンドとして使用している場合は、接続を移行する必要はありません。環境サイズに応じて、Airflow UI または Apache Airflow REST API を使用してこのメタデータを移行できます。 Airflow UI を使用して、新しい環境でカスタムプールの情報を更新します。 メタデータベースをシークレットバックエンドとして使用する環境の場合、すべての接続を新しい環境に移行します。 すべての変数を新しい環境に移行します。 カスタム Airflow ロールを新しい環境に移行します。 移行の実行と検証 古い環境から新しい環境への移行を計画し、実行します。 ワークフローの影響を最小限に抑えるため、アクティビティの少ない期間に移行をスケジュールしてください。 移行前および移行中で DAG の変更の停止期間を設定してください。 移行を以下のフェーズで実行してください： 古い環境で DAG を一時停止します。少数の DAG の場合は Airflow UI を使用できます。大規模なグループの場合は、REST API の使用を検討してください。 Airflow UI で実行中のすべてのタスクが完了したことを確認します。 DAG トリガーと外部統合を新しい環境にリダイレクトします。 更新された DAG を新しい環境の S3 バケットにコピーします。 新しい環境で DAG を有効化します。少数の DAG の場合は Airflow UI を使用できます。大規模なグループの場合は、REST API の使用を検討してください。 初期運用期間中は新しい環境を注意深く監視してください： 失敗したタスクやスケジューリングの問題がないか監視します。 変数や接続の欠落がないか確認します。 外部システムとの統合が正しく機能しているか確認します。 Amazon CloudWatch メトリクスをモニタリングして、環境が期待通りに動作していることを確認します。 移行後の検証 移行後、新しい環境を徹底的に検証します: すべての DAG が定義されたスケジュールに従って正しくスケジュールされていることを確認します。 タスク履歴とログにアクセス可能で完全であることを確認します。 重要なワークフローのエンドツーエンドテストを実施し、正常に実行されることを確認します。 外部システムへの接続が適切に機能していることを検証します。 パフォーマンスの検証のために CloudWatch メトリクスを監視します。 クリーンアップと文書化 移行が完了し、新しい環境が安定したら、以下の手順を実行してください。 移行プロセス中に行った変更を文書化します。 新しい環境を反映するように、運用手順書とオペレーション手順を更新します。 ステークホルダーが定めた十分な安定期間の後、古い環境を廃止します： aws mwaa delete-environment --name old-mwaa2-env 組織のデータ保持ポリシーに従ってバックアップデータをアーカイブします。 まとめ Amazon MWAA における Airflow 2.x から 3.x への移行は、ワークフロー運用の信頼性を維持しながら、次世代のワークフロー オーケストレーション機能を活用する機会となります。これらのベストプラクティスに従い、体系的なアプローチを維持することで、ビジネス運用へのリスクと混乱を最小限に抑えながら、この移行を成功させることができます。 移行を成功させるには、入念な準備、体系的なテスト、そしてプロセス全体を通じた明確なドキュメントの維持が必要です。この移行アプローチは初期の労力は大きくなりますが、このような重要なアップグレードに必要な安全性と制御を提供します。 著者について Anurag Srivastava は、AWS のシニアテクニカルアカウントマネージャーとして、Amazon MWAA を専門に担当しています。お客様のスケーラブルなデータパイプラインとワークフロー自動化ソリューションの構築支援に情熱を注いでいます。 Kamen Sharlandjiev は、ビッグデータおよび ETL ソリューションアーキテクトのシニアで、Amazon MWAA と AWS Glue ETL のエキスパートです。複雑なデータ統合とオーケストレーションの課題に直面するお客様の負担を軽減することをミッションとしています。最小限の労力で成果を出せるフルマネージド型 AWS サービスが彼の秘密兵器です。Amazon MWAA と AWS Glue の最新機能やニュースについては、LinkedIn で Kamen をフォローしてください！ Ankit Sahu は、革新的なデジタル製品やサービスの構築において 18 年以上の実績があります。製品戦略、市場投入の実行、デジタルトランスフォーメーションイニシアチブにわたる幅広い経験を持ちます。現在は Amazon Web Services (AWS)のシニアプロダクトマネージャーとして、Amazon MWAA サービスを主導しています。 Jeetendra Vaidya は、AWS のシニアソリューションアーキテクトとして、AI/ML、サーバーレス、データ分析の分野で専門性を発揮しています。お客様の安全で、スケーラブルで、信頼性が高く、コスト効率の良いソリューションの設計を支援することに情熱を注いでいます。 Mike Ellis は、AWS のシニアテクニカルアカウントマネージャーで、Amazon MWAA のスペシャリストです。お客様の Amazon MWAA 支援に加えて、Airflow オープンソースプロジェクトにも貢献しています。 Venu Thangalapally は、シカゴを拠点とする AWS のシニアソリューションアーキテクトで、クラウドアーキテクチャ、データ分析、コンテナ、アプリケーションモダナイゼーションに関する深い専門知識を持っています。金融サービス業界のお客様と協力して、ビジネス目標を安全で、スケーラブルで、コンプライアンスに準拠したクラウドソリューションに転換し、測定可能な価値を提供しています。技術を活用してイノベーションと業務効率の向上を推進することに情熱を注いでいます。仕事以外では、家族との時間を大切にし、読書や散歩を楽しんでいます。

本記事は、2025/10/1 に公開された Introducing Apache Airflow 3 on Amazon MWAA: New features and capabilities を翻訳したものです。翻訳はプロフェッショナルサービスの佐藤が担当しました。 本日、Amazon Web Services (AWS) は、 Amazon Managed Workflows for Apache Airflow (Amazon MWAA) における Apache Airflow 3 の一般提供開始を発表しました。このリリースにより、組織がクラウド上でデータパイプラインやビジネスプロセスをオーケストレーションするために Apache Airflow を使用する方法が変革され、強化されたセキュリティ、改善されたパフォーマンス、そして最新のワークフローオーケストレーション機能がもたらされます。 Amazon MWAA は、AWS のお客様向けにワークフロー管理を最新化する Airflow 3 の機能を導入します。Apache コミュニティによる 2025 年 4 月の Airflow 3 リリースに続き、AWS はこれらの機能を Amazon MWAA に組み込みました。Airflow は現在、再設計された直感的な UI を備えており、あらゆるレベルのユーザーにとってワークフローオーケストレーションを簡素化します。Task Execution Interface (Task API) により、タスクは Airflow 内とスタンドアロンの Python スクリプトの両方として実行でき、コードの移植性とテストが向上します。スケジューラー管理のバックフィルは、操作を CLI からスケジューラーに移行し、Airflow UI を通じて一元的な制御と可視性を提供します。CLI のセキュリティ改善により、データベースへの直接アクセスが API 呼び出しに置き換えられ、インターフェース全体で一貫したセキュリティが維持されます。Airflow は現在、event-driven ワークフローをサポートしており、AWS サービスや外部ソースからのトリガーが可能になります。Amazon MWAA は Python 3.12 のサポートも追加し、ワークフロー開発に最新の言語機能をもたらします。 この記事では、Amazon MWAA における Airflow 3 の機能を探求し、ワークフローオーケストレーション機能を向上させる拡張機能の概要を説明します。このサービスは、前払いのコミットメントなしで Amazon MWAA の従量課金制の料金モデルを維持します。 Amazon MWAA コンソール にアクセスし、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI)、 AWS CloudFormation 、または AWS SDK を通じて Apache Airflow 環境を起動することで、数分以内に開始できます。 Amazon MWAA における Airflow 3 のアーキテクチャの進歩 Amazon MWAA における Airflow 3 は、セキュリティ、パフォーマンス、柔軟性を向上させる重要なアーキテクチャの改善を導入します。これらの進歩により、既存のワークフローとの下位互換性を維持しながら、ワークフローオーケストレーションのためのより堅牢な基盤が構築されます。 セキュリティの強化 Airflow 3 を搭載した Amazon MWAA は、コンポーネントの分離をオプションではなく標準とすることで、セキュリティモデルを変更します。Airflow 2 では、DAG プロセッサー (DAG ファイルを解析および処理するコンポーネント) はデフォルトでスケジューラープロセス内で実行されますが、スケーラビリティとセキュリティの分離を向上させるために、オプションで独自のプロセスに分離できました。Airflow 3 では、この分離を標準とし、デプロイメント全体で一貫したセキュリティプラクティスを維持します。 API サーバーと Task API このセキュリティモデルの上に、Airflow 3 を搭載した Amazon MWAA では新しい API サーバーコンポーネントが導入され、タスクインスタンスと Airflow メタデータデータベース間の仲介役として機能します。この変更により、タスクから Airflow メタデータデータベースへの直接アクセスを最小限に抑えることができ、ワークフローのセキュリティ態勢が向上します。タスクは現在、最小権限のデータベースアクセスで動作し、あるタスクが他のタスクに影響を与えるリスクを軽減し、データベースへの直接アクセスを減らすことで全体的なシステムの安定性を向上させます。 明確に定義された API エンドポイントを通じた標準化された通信により、より安全で、スケーラブル、柔軟なワークフローオーケストレーションの基盤が構築されます。Task API により、タスクは Airflow 内とスタンドアロンの Python スクリプトの両方として実行でき、コードの移植性とテスト機能が向上します。 data-aware スケジューリングから event-driven スケジューリングへ Airflow の event-driven スケジューリングへの進化は、Airflow 2.4 での data-aware スケジューリングの導入から始まり、時刻だけでなくデータの変更や更新を検知して DAG をトリガーできるようになりました。Airflow 3 を搭載した Amazon MWAA は、Dataset から Asset への名称変更を含む移行を通じてこの基盤の上に構築され、Asset パーティション、外部イベント統合、Asset 中心のワークフロー設計などの高度な機能を導入します。 Dataset から Asset への移行は、単純な名称変更以上のものを表しています。 Asset は、データベーステーブル、永続化された ML モデル、埋め込みダッシュボード、ファイルを含むディレクトリなど、多様なデータ製品を表すことができる、論理的に関連するデータのコレクションです。 Airflow 3 を搭載した Amazon MWAA は、ワークフローの設計方法における重要な変化を表す新しい Asset 中心の構文を導入します。@asset デコレーターにより、開発者は Asset をワークフロー設計の中心に置くことができ、より直感的な asset-driven パイプラインを作成できます。 以下は、asset-aware DAG スケジューリングの例です: from airflow.sdk import DAG, Asset from airflow.providers.standard.operators.python import PythonOperator # Define the asset customer_data_asset = Asset(name="customer_data", uri="s3://my-bucket/customer-data.csv") def process_customer_data(): """Process customer data...""" # Implementation here # Create the DAG and task with DAG(dag_id="process_customer_data", schedule="@daily"): PythonOperator( task_id="process_data", outlets=[customer_data_asset], python_callable=process_customer_data ) 以下は、@asset デコレーターを使用した Asset 中心のアプローチを示しています: from airflow.sdk import asset @asset(uri="s3://my-bucket/customer-data.csv", schedule="@daily") def customer_data(): """Process customer data...""" # Implementation here @asset デコレーターは、関数名を持つ Asset、同じ識別子を持つ DAG、および Asset を生成するタスクを自動的に作成します。これにより、コードの複雑さが軽減され、各 Asset が自己完結型のワークフローユニットになる自動 DAG 作成が容易になります。 Asset Watchers による external event-driven スケジューリング Airflow 3 を搭載した Amazon MWAA における重要な進歩は、Asset Watchers の導入です。これにより、Airflow は Airflow システム自体の外部で発生するイベントに反応できるようになります。以前のバージョンでは内部のクロス DAG 依存関係をサポートしていましたが、Asset Watchers は AssetWatcher クラスを通じて、この機能を外部データシステムやメッセージキューに拡張します。 Airflow 3 を搭載した Amazon MWAA には、Asset Watchers を通じた Amazon Simple Queue Service (Amazon SQS) のサポートが含まれています。これにより、ワークフローを外部メッセージによってトリガーでき、より event-driven なスケジューリングが促進されます。Airflow は現在、event-driven ワークフローをサポートしており、AWS サービスや外部ソースからのトリガーが可能になります。Asset Watchers は外部システムを非同期的に監視し、特定のイベントが発生したときにワークフローの実行をトリガーします。これにより、従来のセンサーベースのポーリングメカニズムのオーバーヘッドなしに、ビジネスイベント、データ更新、またはシステム通知に応答できるようになります。 最新の React ベース UI Airflow 3 を搭載した Amazon MWAA は、React と FastAPI で構築された完全に再設計された直感的な UI を備えており、あらゆるレベルのユーザーにとってワークフローオーケストレーションを簡素化します。新しいインターフェースは、より直感的なナビゲーションとワークフローの可視化を提供し、タスクのステータスと履歴をより良く可視化する強化されたグリッドビューを備えています。ユーザーは、長時間の使用中の疲労を軽減するダークモードのサポートの追加と、特に大規模な DAG を扱う際に顕著な全体的に高速なパフォーマンスを高く評価するでしょう。 新しい UI は、DAG 管理と監視のためのより最新で効率的なエクスペリエンスを提供しながら、使い慣れたワークフローを維持し、開発者と運用者の両方にとって日常業務をより生産的にします。レガシー UI は完全に削除され、システム全体でよりクリーンで一貫したエクスペリエンスを提供します。新しい UI の基盤は、REST API と UI 操作用の内部 API のセットに基づいて構築されており、両方とも FastAPI に基づいているため、プログラムアクセスと UI 操作の両方に対して、より統合的で安全なアーキテクチャが構築されます。 スケジューラーの最適化 Airflow 3 を搭載した Amazon MWAA の強化されたスケジューラーは、タスク実行とワークフロー管理のパフォーマンス向上を実現します。再設計されたスケジューリングエンジンは、タスクをより効率的に処理し、タスクの送信と実行の間の時間を短縮します。この最適化は、迅速なタスク処理とタイムリーなワークフロー完了を必要とするデータパイプライン操作に利益をもたらします。 スケジューラーは現在、コンピューティングリソースをより効果的に管理し、ワークロードがスケールしても安定したパフォーマンスを実現します。複数の DAG を同時に実行する場合、改善されたリソース割り当てシステムは、ボトルネックを防ぎ、一貫した実行速度を維持するのに役立ちます。この進歩は、さまざまなリソース要件を持つ複雑なワークフローを実行する組織にとって特に有用です。新しいスケジューラーは、同時操作をより高い精度で処理するため、チームはシステムの安定性と予測可能なパフォーマンスを維持しながら、複数の DAG インスタンスを同時に実行できます。 強化されたスケジューラーバックフィル操作 スケジューラー管理のバックフィル (過去の日付に対して DAG を実行するプロセス) は、操作を CLI からスケジューラーに移行し、Airflow UI を通じて一元的な制御と可視性を提供します。Airflow 3 を搭載した Amazon MWAA は、スケジューラーのバックフィル機能に重要なアップグレードを提供し、データチームが過去のデータをより効率的に処理できるようにします。バックフィルプロセスは、パフォーマンスの向上のために最適化されており、これらの操作中のデータベース負荷を軽減し、バックフィルをより迅速に完了できるようにし、ニアリアルタイムのワークフロー実行への影響を最小限に抑えます。 Airflow 3 を搭載した Amazon MWAA は、バックフィル操作の管理も改善し、スケジューラーはバックフィルジョブ間のより良い分離を提供し、過去の Dataset より効率的な処理をサポートします。運用者は現在、バックフィルジョブの進行状況とステータスを追跡するためのより良い監視ツールを持っており、これらの重要なデータ処理タスクのより効果的な管理が可能になります。 開発者向けの改善 Amazon MWAA における Airflow 3 は、簡素化されたタスク定義からより良いワークフロー管理機能まで、開発者エクスペリエンスを向上させるために設計されたいくつかの拡張機能を提供します。 Task SDK Task SDK は、タスクと DAG を定義するためのより直感的な方法を提供します: # Example using the Task SDK from airflow.sdk import dag, task from datetime import datetime @dag( start_date=datetime(2023, 1, 1), schedule="@daily", catchup=False ) def modern_etl_workflow(): @task def extract(): # Extract data from source return {"data": [1, 2, 3, 4, 5]} @task def transform(input_data): # Transform the data return [x * 10 for x in input_data] @task def load(transformed_data): # Load data to destination print(f"Loading data: {transformed_data}") # Define the workflow extracted_data = extract() transformed_data = transform(extracted_data["data"]) load(transformed_data) # Instantiate the DAG etl_dag = modern_etl_workflow() このアプローチは、タスク間のより直感的なデータフロー、改善された型ヒントによるより良い統合開発環境 (IDE) サポート、およびタスクロジックのより簡単な単体テストを提供します。その結果、パイプラインの実際のデータフローをより良く表現する、よりクリーンで保守しやすいコードが得られます。このパターンを採用するチームは、特にワークフローが複雑さを増すにつれて、DAG がより読みやすく、保守が簡単になることがよくあります。 DAG バージョニング Airflow 3 を搭載した Amazon MWAA には、Airflow 3 にデフォルトで付属する基本的な DAG バージョニング機能が含まれています。DAG が変更されてデプロイされるたびに、Airflow は DAG 定義をシリアル化して保存し、履歴を保持します。この自動バージョン追跡により、手動での記録管理の必要性が最小限に抑えられ、すべての変更が記録されます。 Airflow UI を通じて、チームは DAG の履歴にアクセスして確認できます。この視覚的表現は、バージョン番号 (v1、v2、v3 など) を示し、チームがワークフローが時間とともにどのように進化したかを理解するのに役立ちます。 Amazon MWAA でサポートされている DAG バージョニングは、Airflow UI で実行されたさまざまな DAG バージョンを確認する機能を提供し、複雑で進化するデータパイプラインを管理するデータエンジニアリングチームに、改善されたワークフローの可視性と強化されたコラボレーションを提供します。 Python 3.12 サポート Amazon MWAA は Python 3.12 のサポートを追加し、ワークフロー開発に最新の言語機能をもたらします。このアップグレードにより、最新の Python 言語の改善、パフォーマンスの強化、ライブラリの更新にアクセスでき、データパイプラインを最新かつ効率的に保ちます。 Amazon MWAA で現在サポートされていない機能 このリリースで Amazon MWAA に Airflow 3 の機能のほとんどを導入していますが、現時点ではサポートされていない機能がいくつかあります: Flask AppBuilder の置き換え ( AIP-79 ) – 完全な置き換え機能 Edge Executor とタスクの分離 ( AIP-69 ) – リモート実行機能 多言語サポート ( AIP-72 ) – Python 以外の言語のサポート これらの機能は、Amazon MWAA における Airflow の今後のバージョンでサポートする予定です。 まとめ Amazon MWAA における Airflow 3 は、強化されたワークフロー自動化機能を提供します。アーキテクチャの改善、強化されたセキュリティモデル、開発者フレンドリーな機能により、より信頼性が高く保守しやすいデータパイプラインを構築するための堅固な基盤が提供されます。Asset Watchers の導入により、ワークフローが外部イベントに応答する方法が変わり、真のevent-driven スケジューリングが可能になります。この機能は、新しい Asset 中心のワークフロー設計と組み合わせることで、Airflow 3 をより強力で柔軟なオーケストレーションサービスにします。 スケジューラーの最適化により、タスク実行とワークフロー管理のパフォーマンスが向上し、強化されたバックフィル機能により、過去のデータ処理がより効率的になります。DAG バージョニングシステムは、ワークフローの安定性とコラボレーションを向上させ、Python 3.12 サポートにより、データパイプラインを最新かつ効率的に保ちます。 組織は現在、Amazon MWAA における Airflow 3 のこれらの新機能と改善を活用して、ワークフローオーケストレーション機能を強化できます。開始するには、 Amazon MWAA 製品ページ をご覧ください。 著者について Anurag Srivastava は、Amazon Web Services (AWS) のシニアビッグデータクラウドエンジニアとして、Amazon MWAA を専門としています。彼は、お客様が AWS 上でスケーラブルなデータパイプラインとワークフロー自動化ソリューションを構築するのを支援することに情熱を注いでいます。 Kamen Sharlandjiev は、シニアビッグデータおよび ETL ソリューションアーキテクトであり、Amazon MWAA と AWS Glue ETL のエキスパートです。彼は、複雑なデータ統合とオーケストレーションの課題に直面しているお客様の生活を楽にすることを使命としています。彼の秘密兵器?は、最小限の労力で仕事を完了できる完全マネージド型 AWS サービスです。最新の Amazon MWAA と AWS Glue の機能とニュースを最新の状態に保つために、LinkedIn で Kamen をフォローしてください! Ankit Sahu は、革新的なデジタル製品とサービスの構築において 18 年以上の専門知識を持っています。彼の多様な経験は、製品戦略、市場投入の実行、デジタルトランスフォーメーションイニシアチブにまたがっています。現在、Ankit は Amazon Web Services (AWS) のシニアプロダクトマネージャーとして、Amazon MWAA サービスをリードしています。 Mohammad Sabeel は、Amazon Web Services (AWS) のシニアクラウドサポートエンジニアとして、AWS Glue、Amazon MWAA、Amazon Athena を含む AWS Analytics サービスを専門としています。14 年以上の IT 経験を持つ彼は、お客様がスケーラブルなデータ処理パイプラインを構築し、AWS 上の分析ソリューションを最適化するのを支援することに情熱を注いでいます。 Satya Chikkala は、Amazon Web Services のソリューションアーキテクトです。オーストラリアのメルボルンを拠点とし、エンタープライズのお客様と緊密に協力してクラウドジャーニーを加速しています。仕事以外では、自然と写真撮影に非常に情熱を注いでいます。 Sriharsh Adari は、Amazon Web Services (AWS) のシニアソリューションアーキテクトであり、お客様がビジネス成果から逆算して AWS 上で革新的なソリューションを開発するのを支援しています。長年にわたり、彼は業界の垂直市場全体でデータシステムの変革において複数のお客様を支援してきました。彼の中核的な専門分野には、テクノロジー戦略、データ分析、データサイエンスが含まれます。余暇には、スポーツをしたり、テレビ番組を一気見したり、タブラを演奏したりすることを楽しんでいます。

この記事は Accelerate Marketing campaign planning by 3x with Treasure Data AI Agents powered by Amazon Bedrock の翻訳記事です。 マルチチャネル・キャンペーンの企画・実行において、マーケティングチームは大きな課題に直面しています。従来のキャンペーン企画​では、仮説設定、オーディエンス分析、ジャーニーマッピング、コンテンツ開発、アクティベーション、そして効果測定など、システムとチーム間の調整だけで数ヶ月を必要とします。この長いプロセスの間に、顧客がエンゲージメントを必要とする重要な瞬間を逃してしまうことがあるのです。 Treasure Dataの 顧客データプラットフォーム（CDP） は、世界中の大手ブランドにサービスを提供しており、インターネット接続人口の大部分の顧客プロファイルを管理しています。Amazon Web Services（AWS）と連携し、Amazon Bedrock を利用したマーケティングチーム向けの AI 活用ソリューションを開発しました。 Amazon Bedrock は、生成 AI アプリケーションを構築するための高性能な 基盤モデル へのフルマネージドアクセスを提供し、自然言語の指示を理解し、様々なシステムと自律的に対話する AI エージェントの導入を可能にするサービスです。 このブログでは、Amazon Bedrock を使って構築された Treasure Data の AI を活用したサービスによって、どのようにしてキャンペーン作成を数か月かかるプロセスから数時間または、数日へと変革することができるのか解説します。これらのソリューションにより、マーケティングチームと CX チームは、エンタープライズ企業が求めるセキュリティとガバナンスの基準を有しつつ、市場機会に迅速に対応し、パーソナライズされた体験を大規模に提供できるようになります。 信頼できるデータを基にした AI エージェント構築 AI の真の力は、高度な基盤モデルと高品質な顧客データを組み合わせることにこそあります。Treasure Data のプラットフォームと Amazon Bedrock の統合により、マーケティング担当者が顧客データを迅速に分析し、ターゲットオーディエンスセグメントを生成し、詳細なペルソナを定義し、技術的な専門知識がなくてもデータに基づく意思決定を行うことができるようになります。この組み合わせにより、キャンペーン作成時間が大幅に短縮され、ターゲティングの精度とキャンペーンのパフォーマンスが向上します。 AWS との共同開発 Treasure Data は AWS と緊密に連携し、従来のキャンペーン計画・実行プロセスにおける主要なボトルネックを特定しました。既存のツールにチャットインターフェースを単に追加するのではなく、AI の効果を最大限に高めるための基本的なワークフローを再設計することに重点を置きました。 このパートナーシップでは、人間の持つ専門知識と AI の能力の適切なバランスを見つけることを重視しました。マーケティング担当者は戦略的な全体監督としての役割を維持し、AI エージェントが時間のかかる分析タスクを処理します。このアプローチでは、複雑なデータの相関性を処理し、実際の顧客の行動に基づいた実用的なインサイトを提供できるエージェントを構築する必要がありました。 このコラボレーションにより、Amazon Bedrock 上に構築されたマルチエージェント・フレームワークが実現し、エンタープライズ企業が求めるセキュリティとコンプライアンスの標準を維持しながら、特定のマーケティング課題に対処できるようになりました。 Amazon Bedrock の価値 Treasure Data が AI エージェント基盤として Amazon Bedrock を選択したのは、制御性やセキュリティを犠牲にすることなく迅速な導入を可能にするためです。Amazon Bedrock はモデル選択を簡素化し、チームにデータサイエンスの専門知識がなくても高度な基盤モデルにアクセスできるようになります。 このフルマネージドプラットフォームにより、カスタムインフラストラクチャをゼロから構築することなく、本番環境への迅速な導入が可能になります。顧客データは AWS とお客様による責任共有モデルの範囲内でプライバシーとセキュリティが確保されます。AWS が基盤となるインフラストラクチャを保護し、お客様はコンテンツとアクセス権限を管理できます。 Treasure Data の顧客データに関する専門知識と Amazon Bedrock が提供する AI 基盤モデルを組み合わせることにより、組織がセキュリティとガバナンスの標準を維持しつつ AI イニシアチブを拡張することができます。 Treasure Data の目的別 AI エージェント Treasure Data は、Amazon Bedrock を基盤として、特定のマーケティング課題に対応するための目的別 AI エージェントをいくつか開発しました。各エージェントは、キャンペーンの計画・実行プロセスにおける重要な課題を専門に扱います。 Audience Agent を利用すれば、マーケティング担当者が SQL や高度なデータ操作スキルを持たなくても、行動シグナルから高価値のオーディエンスセグメントを素早く発見・作成できます。エージェントが顧客行動のパターンを自動的に識別してくれるため、データ分析とオーディエンスセグメンテーションの速度と精度が向上します。図 1 はクエリに基づいて顧客データを取得する Audience Agent の例です。例えば「最もロイヤルティの高い顧客について知りたい」という要求に対して、Audience Agent が関連する属性を識別し、結果を提示しています。 図 1: Audience Agent コンソール Deep Research & Analysis Agent は、仮説構築プロセスを数ヶ月から 1 週間未満にまで短縮します。手作業による分析やマーケティングに膨大な時間を費やす代わりに、顧客チームは行動シグナルに基づいた高品質な仮説を構築し、戦略、テスト、実行の意思決定に役立てることができます。Treasure Data の Deep Insight Platform は「質問管理」機能を提供しており、ユーザーは図 2 に示すように、解約率の傾向やメールのパフォーマンス分析など、いろいろな分析のための質問を作成できます。 図 2: Treasure Data Deep Insight Platform Treasure Data の CDP トレードアッププログラム の一部として提供される Migration Agent は、既存の顧客データプラットフォームからの移行を最大 60% 加速します。現在のシステムからクエリ、セグメント、変換ロジックを抽出し、SQL、パイプライン、オーケストレーション・ワークフローを自動生成します。このエージェントにより、既存のセグメント、ワークフロー、ビジネスロジックを維持したままデータを移行できるため、ゼロから構築する必要がなくなります。 これらのエージェントは、データ処理機能と Amazon Bedrock の推論機能を組み合わせた Retrieval Augumented Generation (RAG) を利用しており、正確でデータに基づいた応答を提供します。これにより、AI による提案が一般的な推奨事項ではなく、実際の顧客行動を反映したものになります。 Treasure Data AI Agent Foundryのご紹介 予め提供されるエージェントは一般的なマーケティング課題に対応していますが、Treasure Data のお客様からは、独自のビジネス要件や業界固有のユースケースに合わせてカスタマイズされたエージェントを作成する必要性も指摘されていました。 AI Agent Foundry はこのニーズに応えるソリューションとして登場しました。 AI Agent Foundry は、特定のビジネスニーズに合わせてカスタマイズされた AI エージェントを構築するための基盤です。マーケティングチーム、カスタマーエクスペリエンスチーム、データチームは、深い専門知識を持たなくても、エージェントを作成、改良、導入することができます。効果の高いユースケースとしては、ジャーニーオーケストレーション、データヘルスモニタリング、組織固有のキャンペーン最適化などが挙げられます。 AI Agent Foundry には、エンタープライズガバナンス要件を満たすセキュリティ機能、権限管理、監査機能、アクセス管理が組み込まれています。チームは、データセキュリティ、プライバシー、規制コンプライアンスを維持しつつ、AI 機能を試し、エージェントを導入できます。このアプローチにより、お客様は特定の市場動向やビジネスプロセスに対応するエージェントを構築できます。 成果に直結する実用的なアプリケーション これら専用エージェントは、Amazon Bedrock との統合で、複数の重要なマーケティングユースケースにも対応します。意思決定支援機能は、マーケティング担当者がキャンペーンのターゲティング、メッセージング、チャネル選択を決定する際に、複数の要素を同時に評価するのに役立ちます。AI が、単なる直感ではなく、包括的なデータ分析に基づいた推奨事項を提供してくれます。 複数のチームメンバーが AI エージェントと同時に協働できるため、マーケティング組織全体で顧客インサイトへのアクセスが民主化されます。この機能により、マーケティングチームの技術的専門知識の不足によって生じるボトルネックが解消されます。 エージェントは顧客とのやり取りやキャンペーンのパフォーマンスから継続的に学習するため、チームは素早い反復と最適化を通じてアプローチを改善し、よりよい成果を上げることができます。 事例：nobitel 株式会社 ヘルス＆スポーツサービスのリーディングカンパニーである nobitel 株式会社は、日本全国でストレッチ専門チェーン「Dr.Stretch」240 店舗以上を展開しています。同社はマーケティング業務において、手作業によるキャンペーン計画とデータのサイロ化により、技術チーム以外のチームが、顧客インサイトにアクセスしてタイムリーなパーソナライズされた推奨事項を提供することができないという課題を持っていました。 この課題に対処するため、nobitel 社は Amazon Bedrock を含む AWS AI/ML サービスを利用して構築された Treasure Data AI Agent Foundry を導入しました。これにより、同社のマーケティング業務は変革され、技術チーム以外の、高度なデータスキルを持っていないマーケターでも、パーソナライズされたキャンペーンを実行できるようになりました。その結果、キャンペーン計画のスピードは 3 倍、店舗効率は 20% 向上しました。nobitel 社の変革の詳細については ケーススタディ をご覧ください。（訳注：日本語補足資料として こちら もご覧ください） AI を活用したマーケティングの未来 AI エージェントは、マーケティングとカスタマーエクスペリエンスのオペレーションを再構築する変革の始まりを象徴しています。将来的には、エージェントがメッセージのバリエーションをテストし、クリエイティブなコンテンツを生成し、マルチチャネルキャンペーンをオーケストレーションし、デバイスや地域を問わずリアルタイムで支出を最適化するようになるでしょう。 マーケティングと CX の専門家は、キャンペーンを実行する役割から戦略的なオーケストレーターへと進化します。大事なことは、データインフラストラクチャが多数の自律型キャンペーンを正確かつ制御された状態で同時に実行できるかどうかです。 こうした未来では、堅牢なデータ基盤、高度な AI 機能、そして大規模な信頼とコンプライアンスを確保するガバナンスフレームワークが必要とされます。すでにこのような基盤を構築している組織であれば、自律型マーケティングと CX オペレーションを活用できる態勢を整えていると言えるでしょう。 AI とデータによるマーケティングの変革 Amazon Bedrock を基盤とする Treasure Data の専用 AI エージェントと AI Agent Foundry は、マーケティング、CX、データの各チームが顧客データから価値を引き出す方法を根本的に変革します。信頼できるデータと高度な基盤モデルを組み合わせることで、チームはデータ分析、セグメント作成、ペルソナ生成、そして戦略的な意思決定を、数ヶ月ではなく数時間で実行できるようになります。 この変革により、顧客インサイトへのアクセスが民主化され、複雑な分析タスクが自動化されます。マーケティングチームは市場機会への素早い対応と、迅速な反復処理によるよりよい成果の達成が可能になります。このソリューションは、効果的なマーケティングには、インテリジェントエージェントと、それらを真に強力にする堅牢なデータ基盤の両方が必要であることを示しています。 セキュリティとコンプライアンスは、AWS とお客様の共有責任モデルの上にあります。AWS は Amazon Bedrock を通じて安全でコンプライアンスに準拠した基盤を提供し、お客様はデータとアクセスポリシーを管理できます。このアプローチにより、企業のガバナンス要件を満たしつつ AI を活用したイノベーションを実現できます。 まとめ Amazon Bedrock を基盤とする Treasure Data AI Agent Foundry とプリビルドの AI エージェントが、マーケティングキャンペーンの作成プロセスを数か月から数時間、あるいは数日へと変革します。これらの AI ソリューションにより、マーケティング担当者に深い専門知識がなくても、データの迅速な分析、セグメントの作成、ペルソナの生成、そしてデータに基づく意思決定が可能になります。Amazon Bedrock の基盤モデルを活用した顧客インサイトへのアクセスの民主化と、複雑な分析タスクの自動化により、マーケティングチームは市場機会への素早い対応と迅速な反復処理を通じてよりよい成果を達成できるようになります。 Treasure Data – AWS パートナースポットライト AWS パートナーである Treasure Data は、エンタープライズ規模に特化したインテリジェントなカスタマーデータプラットフォームです。Yum! Brands、Stellantis、AXA を始めとする 80 社を超える Global 2000 企業から信頼を得ている Treasure Data は、信頼性、パフォーマンス、そして AI ファーストのアーキテクチャを融合し、高度にパーソナライズされた顧客体験による収益向上、マーケティングコストの削減、そしてリスク軽減を実現します。Treasure Data は、すぐにご利用いただけるエージェントと AI Agent Foundry の両方を提供しています。データドリブンなチームやパートナーは、Treasure Data プラットフォーム上およびワークフロー全体で AI エージェントを活用、作成、展開し、信頼できる Treasure Data 環境内でデータを活用することができます。 関連情報 Treasure Data on AWS Marketplace Treasure Data Partner Profile 著者について Ronak Shah Ronak Shah は、ニューヨークを拠点とする AWS インダストリーバーティカルチームのプリンシパルパートナーソリューションアーキテクトです。小売消費財業界の AWS パートナーと協力し、AWS 上でのイノベーション共創を推進しています。小売業界の新たなトレンドの発見と、デジタルコマース、サプライチェーン、顧客体験、マーケティングテクノロジーの分野における革新的なソリューションの開発に関心を持っています。プライベートでは、ボーイスカウトや地元のディベート大会でボランティア活動を行っています。 Hiroshi Nakamura Hiroshi Nakamura は、ソフトウェアエンジニアリングとシステムアーキテクチャの分野で豊富な経験を持つテクノロジーリーダーです。2014 年 10 月より Treasure Data の CTO 兼エンジニアリング担当 VP を務めており、膨大なデータに対応可能なクラウドベースのデータ管理プラットフォームの設計・開発に尽力してきました。1999 年 4 月からオープンソース開発者としても積極的に活動しており、Ruby と JRuby の大幅な機能強化に貢献しています。早稲田大学理工学修士号を取得しています。 Pranjal Gururani Pranjal Gururani は、シアトルを拠点とする AWS のソリューションアーキテクトです。様々な顧客とともにビジネス課題を解決するクラウドソリューションの構築に取り組んでいます。趣味はハイキング、カヤック、スカイダイビング、​​そして家族との時間です。 翻訳は Solutions Architect 杉中が担当しました。原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 今週 10月24日 (金) に「AWS Japan AI Agent Day 2025」が開催されます。一般提供開始された Amazon Bedrock AgentCore・Amazon Quick Suite など、AWS で AI Agent を活用するための知見を学ぶことができます。ぜひ、 こちらの申し込みページ からご登録をお願いいたします。 また「AWS 生成 AI 活用ワークショップ～ Amazon Q Developer で生成 AI の一歩先へ！ ～」という Amazon Q Developer のワークショップイベントを 10月29日(水) に開催予定です。こちらも 申し込みページ から登録いただけます。 「 AWS ジャパン生成 AI 実用化推進プログラム 」も非常に多くの申し込みをいただいています。引き続き募集中ですのでよろしくお願いします。 それでは、10 月 13 日週の生成 AI with AWS 界隈のニュースを見ていきましょう。 先週は、Amazon Bedrock AgentCore の一般提供開始や Claude Haiku 4.5 のサポート開始など注目度が高いアップデートが多くありました。 さまざまなニュース AWS生成AI国内事例ブログ「株式会社マキタ様の AWS 生成 AI 事例「AWS 上の閉鎖型 AI 環境で労働災害報告書作成支援と経営ダッシュボードを内製開発。システム開発経験の少ないエンジニアが短期間でリリースを実現」のご紹介」を公開 株式会社マキタ様が、経営ダッシュボードと労働災害報告書作成支援 AI を AWS 上で内製開発した事例を紹介しています。データのサイロ化や業務属人化の課題に対し、Amazon QuickSight や Amazon Bedrock などのマネージドサービスを活用し、経営ダッシュボードを7カ月、報告書作成支援 AI を1.5カ月という短期間でリリースしました。潤沢にエンジニアがいない環境においても内製化が可能になるAWSの容易さやサービスの豊富さを評価いただいています。 ブログ記事「Amazon Bedrock AgentCore、東京を含むAWSリージョンで一般提供開始：AIエージェントを現実の世界へ」を公開 Amazon Bedrock AgentCore が、東京を含む9つの AWS リージョンで一般提供開始されました。本ブログでは、AI エージェントを本番環境で安全かつスケーラブルに運用するための統合プラットフォームである AgentCore の主要機能を紹介しています。またAmazon Bedrock AgentCoreをご利用の日本のお客様からのコメントも複数紹介しています。 ブログ記事「Amazon Bedrock で日本国内に閉じた Anthropic Claude 4.5 の推論が可能に！日本国内クロスリージョン推論のご紹介」を公開 Amazon Bedrock で Claude Sonnet 4.5 / Claude Haiku 4.5 と共に日本国内クロスリージョン推論が導入されました。本ブログでは、データを日本国内に留めながら東京リージョンと大阪リージョンの計算リソースを活用し、予期しないトラフィックバーストに対応する仕組みや、推論プロファイルの概念、モニタリング方法、セキュリティ、料金体系などを解説しています。 ブログ記事「【開催報告】Amazon SageMaker Roadshow -Japan」を公開 本ブログは、2025年7月15日に開催された「Amazon SageMaker Roadshow -Japan」の開催報告です。Amazon SageMaker 開発チームによる次世代 Amazon SageMaker の紹介、Amazon SageMaker Unified Studio を活用したエンドツーエンドデモ、NX 情報システム様、キヤノンＩＴソリューションズ様、ソニーグループ様、NTT データ様による具体的な活用事例が紹介されています。 ブログ記事「AWS Transform for VMware を使用して VMware ワークロードを移行およびモダナイズする」を公開 本ブログでは、AWS Transform for VMware を使用した VMware ワークロードの移行とモダナイゼーションについて解説しています。ディスカバリーとアセスメント（仮想マシンの発見と移行評価）の効率化、ネットワーク変換の自動化、AI 主導のウェーブプランニング（段階的な移行計画）、セキュアな移行実行など、AWS Transform for VMware のアーキテクチャと主要機能を詳しく紹介しています。 ブログ記事「README ファイルの心配をやめた方法」を公開 Kiro のエージェントフック機能を活用して、README ファイルや API ドキュメントを自動更新する方法を紹介しています。エージェントフック機能とは、IDE 上で特定のイベントが発生したときに、あらかじめ定義されたエージェントのアクションを自動で実行するトリガー機能を指します。エージェントフックの設定方法や実際の動作例、さらにコード最適化や言語ローカライゼーションなどの他のユースケースも紹介しています。 ブログ記事「マルチAIエージェントが創る新しい店舗体験 〜Amazon Bedrock AgentCoreによる販売支援〜」を公開 Amazon Bedrock AgentCore と PROTO 社のサイネージデバイスを連携させた、マルチ AI エージェントによる店舗販売支援ソリューションを紹介しています。アバターエージェント、商品情報エージェント、店舗支援エージェント、オーケストレーターエージェントが協調して動作し、来店前から店頭接客までシームレスな顧客体験を提供します。本ブログでは、AgentCore の各機能(Runtime、Gateway、Memory など)を活用したアーキテクチャと、顧客側・店舗側それぞれの活用方法を詳しく解説しています。 サービスアップデート Amazon Bedrock AgentCore が一般提供開始 Amazon Bedrock AgentCore が一般提供開始されました。このサービスは AI エージェントアプリケーションを安全かつスケーラブルに運用できるプラットフォームです。最大 8 時間の長時間実行や VPC サポートによる安全なプライベート環境での運用が可能です。CrewAI や LangGraph などの人気フレームワークに対応し、CloudWatch で運用状況を監視できます。東京リージョンを含む 9 リージョンで利用でき、従量課金制で初期費用は不要です。詳細は 上記のブログ をご参照ください。 Amazon CloudWatch で生成 AI オブザーバビリティが一般提供開始 Amazon CloudWatch で生成 AI オブザーバビリティ機能が一般提供開始となりました。Amazon Bedrock AgentCore でデプロイされるエージェントを含む AI アプリケーションの監視が可能になり、レイテンシーやトークン使用量、エラーをリアルタイムで把握できます。LangChain や LangGraph などのフレームワークにも対応し、問題の迅速な特定が可能です。追加料金なしで利用できます。詳細は こちらのドキュメント をご参照ください。 Anthropic の Claude 4.5 haiku が Amazon Bedrock で利用可能に Amazon Bedrock で Claude Haiku 4.5 が利用可能になりました。Claude Sonnet 4 並みの高性能でありながら、大幅にコストを抑えて高速処理を実現しています。リアルタイムのカスタマーサポートやチャットボットなど、レスポンス速度が重要なアプリケーションに最適です。性能とコストの両方を兼ね備えた AI モデルが使えるようになりました。詳細は こちらのコンソール をご参照ください。 Amazon Bedrock がサーバーレス基盤モデルの自動有効化によりアクセスを簡素化 Amazon Bedrock で、サーバーレス基盤モデルへのアクセスが自動で有効化されるようになりました。従来は手動でモデルアクセスを有効化する必要がありましたが、今回のアップデートで全商用リージョンにおいて即座に AI モデルを利用開始できます。Amazon Bedrock コンソールや AWS SDK から直ちにアクセス可能です。ただし Anthropic モデルのみ初回利用時に一度だけ使用フォームの提出が必要です。詳細は こちらのブログ記事 をご参照ください。 DeepSeek、OpenAI、Qwen モデルが Amazon Bedrock の追加リージョンで利用可能に Amazon Bedrock で DeepSeek-V3.1、OpenAI オープンウェイトモデル、Qwen3 モデルが新たに複数リージョンで利用開始できるようになりました。オハイオ、フランクフルト、ジャカルタリージョンで利用でき、データ保管要件対応や遅延削減が可能になります。詳細は こちらのドキュメント をご参照ください。 Amazon SageMaker AI Projects がカスタムテンプレートの S3 プロビジョニングをサポート Amazon SageMaker AI Projects で、Amazon S3 からカスタム ML プロジェクトテンプレートをプロビジョニングできるようになりました。これまで管理者は標準的な ML プロジェクトテンプレートの管理が困難でしたが、今回のアップデートにより S3 上でテンプレートを管理し、データサイエンティストが SageMaker AI Studio から直接アクセスできます。詳細は こちらのドキュメント をご参照ください。 Amazon ElastiCache のベクトル検索機能の発表 Amazon ElastiCache でベクトル検索機能が一般提供開始しました。この機能により、AI アプリケーションで重要なベクトルデータをマイクロ秒レベルの超低遅延で検索できます。特に LLM のセマンティックキャッシングや RAG で威力を発揮し、応答速度向上とコスト削減を実現します。Valkey 8.2 で追加コストなしで利用でき、既存クラスターもダウンタイムなしでアップグレード可能です。詳細は こちらのブログ記事 をご参照ください。 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI Agent と毎日戯れており、AI Agent 無しでは生きていけなくなっています。好きなうどんは’かけ’です。

10 月 16 日、Amazon EC2 Capacity Manager を発表いたしました。Amazon EC2 Capacity Manager は、すべてのアカウントと AWS リージョンのキャパシティ使用状況を単一のインターフェイスから監視、分析、管理できる一元化ソリューションです。このサービスは、キャパシティ情報を時間単位の更新レートで集約し、優先順位付けされた最適化の機会を提供します。これにより、以前はカスタムオートメーションや複数の AWS サービスからの手動のデータ収集が必要だったキャパシティ管理ワークフローが合理化されます。 Amazon Elastic Compute Cloud (Amazon EC2) を大規模に使用している組織は、オンデマンドインスタンス、スポットインスタンス、キャパシティ予約を使用して、複数のアベイラビリティーゾーンとアカウントで、何百ものインスタンスタイプを運用しています。この複雑さゆえに、お客様は現在、 AWS マネジメントコンソール 、 コストと使用状況レポート 、 Amazon CloudWatch 、EC2 describe API などのさまざまな AWS サービスを介してキャパシティデータにアクセスしています。このような分散型の方法では、手動のデータ収集、ツール間のコンテキスト切り替え、キャパシティ最適化分析を実現するための情報集約用カスタムオートメーションが必要性となるため、運用上のオーバーヘッドが生じる可能性があります。 EC2 Capacity Manager は、すべてのキャパシティデータを統一型のダッシュボードに統合することで、このような運用の複雑さを解消します。すべての商用 AWS リージョンのオンデマンドインスタンス、スポットインスタンス、キャパシティ予約のクロスアカウントおよびクロスリージョンのキャパシティメトリクスを 1 か所で確認できるようになりました。これにより、カスタムデータ収集ツールを構築したり、複数の AWS サービス間を移動したりする必要がなくなりました。 この統合された可視性により、十分に活用されていないキャパシティ予約を強調し、インスタンスタイプ間の使用パターンを分析し、スポットインスタンスの中断パターンに関するインサイトを入手できるため、コスト削減の発見に役立ちます。包括的なキャパシティデータに 1 か所からアクセスできるようになると、インフラストラクチャの適切なサイジングと EC2 支出の最適化について、より多くの情報に基づく意思決定を行うことができます。 EC2 Capacity Manager の機能について詳しくご紹介します。 EC2 Capacity Manager の開始方法 AWS マネジメントコンソールで Amazon EC2 に移動し、ナビゲーションペインで [Capacity Manager] を選択します。サービス設定を通じて EC2 Capacity Manager を有効にします。このサービスは、初期設定時に過去 14 日間の履歴データを集計します。 メインの [ダッシュボード] では、主要なメトリクスを一目で把握できる包括的な概要セクションを通じて、すべてのインスタンスタイプのキャパシティ使用率が表示されます。 [予約] 、 [使用状況] 、 [スポット] のキャパシティ概要カードには、傾向の指標と変化率が表示されるため、キャパシティパターンをすばやく特定できます。日付範囲の選択、タイムゾーンの設定、間隔の設定を含む日付フィルターコントロールを使用して、フィルタリングを適用できます。 さまざまな単位を選択して、vCPU、インスタンス数、または推定コストごとにデータを分析し、リソース消費パターンを把握できます。推定コストは公開済みのオンデマンド料金に基づいており、Savings Plans やその他の割引は含まれていません。この料金リファレンスは、さまざまなインスタンスタイプで十分に活用されていないキャパシティの相対的な影響を比較するのに役立ちます。例えば、100 vCPU 時間の未使用の p5 予約は、100 vCPU 時間の未使用の t3 予約よりもコストに大きな影響を与えます。 ダッシュボードには、合計使用量の視覚化グラフと使用状況の推移グラフの両方を含む詳細な [使用状況メトリクス] が含まれています。合計使用量セクションには、リザーブド使用量、非リザーブド使用量、スポット使用量の内訳が表示されます。使用量の推移グラフでは、時間の経過に伴うキャパシティの傾向を視覚化できるため、使用パターンとピーク需要期間の特定に役立ちます。 [予約メトリクス] の [リザーブドキャパシティの傾向] では、選択した期間の使用済みリザーブドキャパシティと未使用リザーブドキャパシティを視覚化し、アクティブに消費された時間に対する未使用のまま残っているリザーブド vCPU 時間の割合を示します。これにより、予約効率パターンを追跡し、一貫して使用率が低い期間を特定できます。この可視化により、使用率の低い予約を特定し、キャパシティの調整について情報に基づく意思決定を行えるようになるため、コスト削減に役立ちます。 [未使用キャパシティ] セクションには、インスタンスタイプとアベイラビリティーゾーンの組み合わせごとに十分に活用されていないキャパシティ予約が一覧表示され、さまざまなアベイラビリティーゾーンの特定の使用率とインスタンスタイプを確認できます。この優先順位付けされたリストでは、未使用のキャパシティコストを直接把握できるため、節約の可能性を特定するのに役立ちます。 [使用状況] タブには、スポットインスタンス、オンデマンドインスタンス、キャパシティ予約、リザーブドインスタンス、Savings Plans のすべての AWS リージョンにわたる詳細な傾向履歴と使用統計が表示されます。専有ホストの使用状況は含まれていません。 [ディメンションフィルター] を使用すると、アカウント ID、リージョン、インスタンスファミリー、アベイラビリティーゾーン、インスタンスタイプ別にキャパシティデータをグループ化およびフィルタリングして、アカウントと AWS Organizations 全体の使用パターンを明らかにするカスタムビューを作成できます。これにより、特定の設定を分析し、アカウントやリージョンのパフォーマンスを比較できます。 [集計] セクションには、EC2 インスタンスとスポットインスタンスの包括的な使用状況の表が表示されます。さまざまな単位を選択して、vCPU、インスタンス数、または推定コストごとにデータを分析し、リソース消費パターンを把握できます。この表には、合計使用量の統計、リザーブド使用量、未リザーブド使用時間、スポット使用量データを含むインスタンスファミリーの内訳が表示されます。各行には、詳細な分析を行うための [内訳を表示] アクションが含まれています。 [キャパシティ使用状況または推定コストの傾向] セクションは、使用状況の傾向、リザーブド使用量、未リザーブド使用量、スポット使用量を視覚化します。表示されたデータをフィルタリングし、測定単位を調整して履歴パターンを表示できます。これらのフィルタリングおよび分析ツールは、使用状況の傾向の特定、さまざまな側面でのコストの比較、キャパシティプランニングと最適化に関する情報に基づく意思決定に役立ちます。 [集計] 表から [内訳を表示] を選択すると、選択したディメンションフィルターに基づいて詳細な [使用状況の内訳] が表示されます。この内訳ビューには、選択したファミリーとアベイラビリティーゾーンの組み合わせに含まれる個々のインスタンスタイプの使用パターンが表示され、特定の最適化の機会を特定するのに役立ちます。 [予約] タブには、キャパシティ予約の使用率が表示されます。自動分析機能により、最適化の機会の優先順位リストが生成されます。 [使用状況] タブと同様に、予約の詳細に関連する追加オプションとともに、アカウント ID、リージョン、インスタンスファミリー、アベイラビリティーゾーン、インスタンスタイプ別のディメンションフィルターを適用できます。各タブでは、ドリルダウンして各行の項目のデータを表示できます。特に予約については、特定の予約を表示したり、利用履歴、構成パラメータ、現在のステータスなど、オンデマンドキャパシティ予約 (ODCR) に関する詳細情報にアクセスしたりできます。ODCR が Capacity Manager と同じアカウントにある場合は、このインターフェイスから予約パラメータを直接変更できるため、予約管理を行うために別の EC2 コンソールセクションに移動する必要がなくなります。 [統計] セクションには、合計予約数、全体的な使用率、リザーブドキャパシティの合計、使用済みキャパシティと未使用キャパシティのボリューム、平均スケジュール済み予約数、アカウント、インスタンスファミリー、予約のあるリージョンの数などの概要メトリクスが表示されます。 この統合ビューは、インフラストラクチャ全体の予約分布と利用パターンを理解するのに役立ちます。例えば、開発アカウントでは常に 30% の予約使用率を示しているのに対し、本番アカウントでは 95% を超える予約使用率が表示される場合があります。これは、予約を再配分または変更する機会があることを示しています。同様に、特定のリージョンの特定のインスタンスファミリーで使用率が低いことがわかれば、予約調整やワークロード最適化について検討できます。これらのインサイトは、予約の購入、変更、キャンセルについてデータに基づく決定を下すのに役立ち、リザーブドキャパシティを実際の使用パターンに合わせてより適切に調整できるようになります。 [スポット] タブはスポットインスタンスの使用状況に焦点を当て、スポットインスタンスが中断されるまでの実行時間を表示します。このスポットインスタンスの使用パターンの分析は、スポットインスタンスワークロードの最適化の機会を特定するのに役立ちます。スポットプレースメントスコアの推奨を使用すると、ワークロードの柔軟性を高めることができます。 データエクスポート機能を必要とする組織向けに、Capacity Manager にはキャパシティ分析のための Amazon Simple Storage Service (Amazon S3) バケットへのデータエクスポートが含まれています。 [データエクスポート] タブで、データエクスポートを表示および管理できます。これにより、新しいエクスポートの作成、配信ステータスの監視、AWS マネジメントコンソール外でキャパシティデータを分析するためのエクスポートスケジュールの設定を行うことができます。 データをエクスポートすると、コンソールと API で利用可能な 90 日間の保持期間を超えてキャパシティデータを保存できるため、分析機能が拡張されます。この長期保存により、長期的な傾向分析と過去のキャパシティプランニングが可能になります。また、エクスポートしたデータを既存の分析ワークフロー、ビジネスインテリジェンスツール、またはカスタムレポート作成システムと統合して、EC2 キャパシティメトリクスをより広範なインフラストラクチャ分析および意思決定プロセスに組み込むこともできます。 [設定] セクションには、AWS Organizations 統合の設定オプションがあり、複数のアカウントでの一元的なキャパシティ管理を実現できます。組織管理者は、適切な許可とアクセス制御を維持しながら、企業全体のキャパシティの可視化を有効にしたり、特定のアカウントへのアクセスを委任したりできます。 今すぐご利用いただけます EC2 Capacity Manager は、複数のソースからキャパシティデータを収集して分析することによる運用上のオーバーヘッドを排除します。このサービスでは、自動化された最適化の機会、マルチアカウントの一元的な可視化、キャパシティ管理ツールへの直接アクセスが可能になります。EC2 インフラストラクチャ全体のキャパシティ利用率を向上し、コストを最適化しながら、手動の分析時間を削減できます。 Amazon EC2 Capacity Manager は追加コストなしでご利用いただけます。Amazon EC2 Capacity Manager の使用を開始するには、 Amazon EC2 コンソール にアクセスするか、サービス API を通じてアクセスしてください。本サービスは、すべての商用 AWS リージョンでご利用いただけます。 詳細については、 EC2 Capacity Manager のドキュメント をご覧ください。 – Esra 原文は こちら です。

本記事は米国時間 2025 年 10 月 16 日に公開された「 The wait(list) is over, get started with Kiro today 」を翻訳したものです。 90 日前のローンチ以来、数十万人の開発者が Kiro を試すためにウェイトリストに参加してくれました。 本日（2025 年 10 月 16 日）をもって、ウェイトリストは廃止されます。 AI を使った仕様駆動型コーディングアプローチを試したい方は、このブログの残りを飛ばして今すぐ サインアップ してください。 期間限定で、新規ユーザーとしてサインアップすると、30 日以内に使用できる無料の 500 ボーナスクレジットを獲得できます。参考までに、 これは Kiro Pro プランの 50 ％に相当します 。初めての方のために、 Kiro の価格設定の仕組みについてより詳細なガイド をご用意していますが、要約すると以下になります。 バイブ駆動型と仕様駆動型の両方のコーディングに使用できる単一のクレジットプール。タスクは複雑さに基づいて異なる率でクレジットを消費します。 クレジットは 0.01 単位で計測されるため、クレジットの使用量を最大化できます。 異なるモデルは異なる率でクレジットを消費し、我々のエージェントである Auto は 1 倍、Claude Sonnet クラスのモデルは同じプロンプトに対して 1.3 倍のクレジットを消費します。 Kiro はまだ AWS IAM Identity Center を介したログインをサポートしていないため、それがお好みの場合は、アクセス方法について AWS アカウントマネージャーにお問い合わせください。 あなたのような 10 万人以上の開発者が、ローンチ後最初の 5 日間で Kiro の使用を開始したので、あなたも良い仲間に加わることになります。彼らの体験は以下のようなものでした。 スタートアップの共同創設者兼 CTO として、時間は最も重要なリソースです。Kiroは、ビジネスクリティカルな資産を社内で開発するための時間の使用を正当化してくれます。 Rolf Koski – CTO 兼共同創設者 Terraform と Python で AWS Cloud と AI ソリューションを設計する私の役割において、Kiro での仕様駆動型開発は、コードの関連性と品質を全く新しいレベルに押し上げました。機能開発を劇的に加速し、顧客価値までの時間を数週間から数日に短縮しました。Kiro を我々の最新チームメンバーとして迎えることを楽しみにしています。 Håkon Eriksen Drange – プリンシパルクラウドアーキテクト Kiro の自律エージェントはゲームチェンジャーでした。ファイルを保存するたびに、エージェントが自動的にユニットテストを生成し、パフォーマンスを最適化し、ドキュメントを更新してくれました。以前は何時間もかかっていた手作業が、バックグラウンドで瞬時に実行されるようになりました。 Kiran Ravichandran – リードエンジニア Kiro はスタートアップにとって強力な味方です。見落とされがちなドキュメントや仕様を自然に堅牢な資産に変換し、成長をよりスムーズにし、将来のスケーリングをより効果的にしてくれます。 Kento Ikeda – 創設者兼エンジニア 私は Kiro をあらゆることに使用しています – 新しい Terraform モジュールの下書き、コンテナ設定の調整、さらには午前2時にランダムな AI アイデアを書き留めることまで。しかし何よりも、それは私の学習をサポートしてくれます。私は無限に好奇心旺盛で、Kiro は私がその学習ループに留まることを助けてくれます。試行錯誤し、修正し、そして学んだことをコミュニティと共有することを可能にしてくれます。 Adit Modi – ソリューションアーキテクト Kiro の能力には圧倒されています。エージェント体験は本当に変革的です。コンテキストを理解するマルチモーダル入力から、IDE 内での完全なライフサイクル制御まで、シニア開発者と一緒に作業しているような感覚です。 Vivek Velso – クラウドエンジニアリングリード ほとんどのツールはコードの生成に優れていますが、Kiro はコードを書く前の混沌に秩序をもたらします。 Farah Abdirahman – クラウド＆AIエンジニア 約 2 日で、セキュアなファイル共有アプリケーションをゼロから構築しました。単純に Kiro に要件を共有するだけで、暗号化やさまざまなセキュリティコーディング実践を組み込んだ完全にセキュアなアプリケーションを作成することができました—追加のプロンプトは不要でした。 Ihor Sasovets – リードセキュリティエンジニア 変更をプッシュする際にユニットテストを追加したり、ドキュメントを更新したりすることをよく忘れますが、Kiro ではフックを作成でき、それらのタスクをバックグラウンドで自動実行してくれるので、二度と考える必要がありません。 Darya Petrashka – シニアデータサイエンティスト 0.4.0 の機能、改善、修正 過去 90 日間、私たちは価格モデルの刷新、新しい仕様とエージェント機能の構築、Claude Sonnet 4.5 サポートの追加、新しいエージェント Auto の発表、そして多くの UX 品質向上の改善に懸命に取り組んできました。 本日（2025 年 10 月 16 日）、IDE のバージョン 0.4.0 もリリースしており、仕様、クレジット消費の可視性、開発サーバーと信頼できるコマンドのより良いサポートに有用な改善が含まれています。 仕様 MVP タスク ：仕様作成時に、包括的なタスクリストを手元に置きながらコア機能を優先するために、タスク（ユニットテストを含む）をオプションとしてマークできるようになりました。 プロンプトごとのクレジット消費インサイト ：各プロンプトが消費したクレジット数を、チャットパネルで直接確認できるようになりました。 開発サーバー統合 ：Kiro は開発サーバーの出力をインテリジェントに読み取り、より多くのコンパイルエラーとランタイムエラーをキャッチできるようになりました。 仕様をコンテキストとして参照 ：既存の仕様をプロンプトへの追加コンテキストとして使用できるようになりました。 信頼できるコマンドの追加改善、バグ修正など ver 0.4.0 で提供される全ての機能の完全なリストについては、変更ログをご覧ください。 いつものように、 Discord でのフィードバック をお待ちしています。AI でソフトウェア構築を再構想するこの旅路で私たちをサポートしてくださり、ありがとうございます。あなたが何を構築するか楽しみにしています。 今すぐ Kiro をダウンロード して始めましょう！

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 の田澤が担当させていただきました。原文記事は こちら です。