本稿は、2025 年 10 月 17 日に公開された “ Charting the life of an Amazon CloudFront request ” を翻訳したものです。 Amazon CloudFront は、AWS ネイティブの Content Delivery Network (CDN) サービスです。CDN は、エンドユーザーにより近い世界中のエッジロケーションのネットワークを使用し、エッジでコンテンツをキャッシュすることで、Web アクセラレーションを提供します。しかし、CloudFront はそれ以上のことができます。エッジでの機能として、地理的フィルタリング、関数の実行、 AWS Web Application Firewall (WAF) フィルタリングの実行など、さまざまな機能を備えています。この投稿では、CloudFront ディストリビューションへのクライアントリクエストのライフサイクルを探求し、特にこれらの機能の実行順序に注目します。この理解は、Web アプリケーションの配信最適化、Web アプリケーションのセキュリティ保護、および CDN 設定のトラブルシューティングにおいて不可欠です。 リクエストのライフサイクルを見ていく前に、CloudFront クライアントリクエストに関わるインフラストラクチャの構成要素を探ってみましょう。 図 1: CloudFront エッジロケーションと リージョン別エッジキャッシュ エッジキャッシングの概要 CloudFront の Point of Presence (POP)、別名エッジロケーションは、リクエストが最初に到達するサーバーグループです。エッジロケーションは、リクエストに対して応答する(コンテンツがキャッシュされている場合)か、次のレイヤーに転送するかを判断します。エッジロケーションは世界中に分散配置されており、通常の AWS リージョン よりも小規模です。説明を分かりやすくするため、POP を 1 つの単位として考えることができます。図 1(公式 CloudFront ドキュメントより引用)は、この構成を示しています。 この概要説明で十分なケースもありますが、実際には CDN 設定のトラブルシューティング、キャッシング最適化、動的コンテンツ配信のパフォーマンス改善などのために、リクエスト-レスポンスの流れをより詳細に理解する必要があります。注目すべき点は、ビューワーからのリクエストとレスポンスが CloudFront ネットワーク内の複数のレイヤーを通過することです。POP では初期接続処理、負荷分散、キャッシング、 CloudFront Functions の実行が行われ、リージョン別エッジキャッシュ (REC) では高度なキャッシュ最適化、 Lambda@Edge の実行、オリジンサーバーへの接続、リクエストの折りたたみ、オリジンタイムアウト設定などが処理されます。また、キャッシュ効率をさらに向上させるオプション機能として Origin Shield を有効化できます。 HTTP(s) プロトコルに加えて、CloudFront はプロトコルの拡張機能もサポートしています。例えば、HTTP/2 上に構築されたオープンソースの Remote Procedure Call (RPC) フレームワークである gRPC や、TCP ベースのプロトコルである WebSocket があります。WebSocket は、リアルタイムアプリケーションで永続的な接続が必要な場合に、クライアントとサーバー間で長時間持続する双方向通信を実現するのに適しています。 本記事では HTTP(s) のリクエストとレスポンス処理に絞って解説し、gRPC と WebSocket 接続については別の記事で詳しく説明する予定です。 DNS 名前解決と POP ユーザーが CloudFront 経由で Web サイトにアクセスするところから始まります(次の図を参照)。通常、Web サイトは カスタムドメイン名 を CloudFront のドメイン名に紐付けて設定されています。CloudFront は DNS リクエストからユーザーの位置情報を判断し、そのリクエストを処理するのに最適なエッジロケーションの情報を DNS レスポンスとして返します。この際、CloudFront はインターネットネットワークの健全性、ネットワーク負荷など複数の要素を考慮して、ビューワーに最適な POP の IP アドレス(複数)を提供します。エンドユーザーの所在地に応じて、リクエストに応答するインフラを制限することで、コスト削減と異なる価格クラスの活用が可能です。CloudFront ディストリビューションで選択した価格クラスによって、ユーザーが利用できる POP が限定されます。また、 CloudWatch Network Monitor と CloudWatch Internet Monitor を利用することで、AWS 上でホストされているアプリケーションのネットワークおよびインターネットのパフォーマンスと可用性について、運用上の可視性を得ることができます。 CloudFront で エニーキャスト 静的 IP を使用している場合、DNS 解決によって最適な CloudFront POP を決定するプロセスは異なります。本記事では エニーキャスト IP を使用しないケースを想定しています。 図 2: CloudFront リクエストの経路 接続確立と TLS ネゴシエーション DNS 名前解決が完了すると、クライアントアプリケーション(Web ブラウザやモバイルアプリなど、ビューワーと呼ばれます)は、最適な POP の IP アドレスリストを受け取ります。クライアントアプリケーションは、これらの IP のいずれかを使用して POP への接続を確立し、必要に応じて別の IP を使ってフェイルオーバーすることができます。CloudFront は IETF 標準に準拠し、ポート 80/443 で HTTP、HTTPS、WebSocket を 受け付けます 。すべての POP は AWS Shield Standard によって保護されており、UDP フラッドや SYN フラッドなどの一般的な DDoS ボリューメトリック攻撃から守られています。次のレイヤーでは、Secure Sockets Layer (SSL)/Transport Layer Security (TLS) 接続が正しく確立されているかを確認します。CloudFront ディストリビューションに設定された セキュリティポリシー によって、使用可能なプロトコルと暗号スイートが定義されます。 リクエストルーティングと検証 リクエストはリクエストルーターに引き渡されます。POP のリクエストルーターは、クライアント接続を複数のキャッシュサーバーに負荷分散します。ここには重要なセキュリティレイヤーも存在し、クライアントからのリクエストが Request for Comments (RFC) に準拠しているか、不正または曖昧な構文による脅威が含まれていないかを確認することで、キャッシュサーバーを監視・保護しています。このレイヤーによって、キャッシュレイヤーに転送されるリクエストが適切なフォーマットで HTTP 仕様に準拠していることが保証されます。この段階で、CloudFront ディストリビューションの設定に基づき、許可されるプロトコル、HTTP メソッド、地理的制限が評価されます。 AWS WAF リクエストの負荷分散とアクセス前のセキュリティチェックの後、CloudFront ディストリビューションで AWS WAF が有効化されている場合は、リクエストは AWS WAF のウェブアクセスコントロールリスト (ウェブ ACL) に設定されたルールによって処理されます。AWS WAF は Web アプリケーションファイアウォールであり、SQL インジェクション、クロスサイトスクリプティング、ボット攻撃、DDoS 攻撃などのアプリケーションレイヤーの攻撃からアプリケーションを守るために、リクエストを監視します。AWS WAF は、キャッシュビヘイビア、リクエスト/レスポンスヘッダーポリシー、CloudFront Functions や Lambda@Edge といったエッジコンピューティング関数などのコンテンツ処理ルールよりも必ず先に実行されます。 ビヘイビア この段階で、ユーザーはビヘイビアセクションにて、CloudFront がリクエストをどのように処理するかを定義できます。ビヘイビアは URL のパスパターンごとに異なる設定を持つことができます。ビヘイビア設定では、使用するオリジン、許可する HTTP メソッド、キャッシュポリシー、関数の紐付け、そしてオリジンリクエストポリシーを指定します。オリジンリクエストポリシーでは、どのパラメータ(ヘッダー、クエリ文字列、Cookie)をオリジンに転送するかを定義します。また、機密情報を保護するためのフィールドレベル暗号化も設定可能です。 CloudFront キャッシング CloudFront は、CloudFront Functions の Viewer Request 関数(設定されている場合)の実行後、POP のキャッシュに問い合わせを行います。POP 内には、キャッシュヒット率を最大化するための複数レイヤーのキャッシュが存在します。最初のレイヤーにオブジェクトがキャッシュされていない場合、リクエストは次のレイヤーへ、さらに次へと順次転送されていきます。ただし、無限にレイヤーを増やすことはできないため、各キャッシュスタック内のキャッシュサーバー数や、最初のレイヤーが参照できるピアの数には上限があります。POP 内のすべてのキャッシュレイヤーでオブジェクトが見つからない場合、リクエストは REC に転送されます。 REC REC には POP と同様のキャッシュレイヤーがあり、キャッシュ容量の拡大と Lambda@Edge 関数の実行に必要なコンピューティングインフラを提供しています。REC は POP とオリジンサーバーの間に位置する大容量のキャッシュレイヤーとして機能し、キャッシュヒット率のさらなる向上、オリジンへのリクエスト削減、そして Lambda@Edge の実行基盤としての役割を果たします。 Lambda@Edge の ビューワーリクエスト関数を定義している場合、CloudFront が REC のキャッシュを確認する前に、この段階で実行されます。その後、REC のキャッシュにオブジェクトが存在しない場合、Lambda@Edge のオリジンリクエスト関数が実行されます。 CloudFront ディストリビューションで Origin Shield を有効化している場合、すべての REC はオリジンサーバーへリクエストを送る前に Origin Shield を経由するため、オリジンサーバーへの負荷を削減できます。Origin Shield はユーザーのオリジンサーバーに近い場所に配置され、オリジンへのトラフィック帯域幅とリクエスト数を減らすことで、キャッシング効率を高めます。 オリジン接続側の最終レイヤー (REC または Origin Shield) は、コンテンツオリジンとの間で永続的な接続を維持し、効率的なデータ転送を実現します。 オリジンタイムアウト設定 (カスタムオリジンの場合) では、ユーザーは以下の値を調整することができます: 接続試行回数: CloudFront がオリジンサーバーへの接続を試みる回数を設定します。 接続タイムアウト: CloudFront がオリジンサーバーへの接続確立を試みる際の待機時間(秒)を指定します。 レスポンスタイムアウト: CloudFront がオリジンにリクエストを転送してからレスポンスを待つ時間、およびオリジンからレスポンスパケットを受信した後、次のパケットを受信するまでの待機時間を設定します。 オリジンリクエストポリシー では、エッジからオリジンサーバーへ接続する際に使用する最小 SSL バージョンも定義されます。 オリジンからのレスポンス リクエストがすべてのキャッシュレイヤー、REC、Origin Shield のいずれにも存在しない場合、オリジンサーバーから取得されます。オリジンはパブリック IP でアクセス可能なリソースですが、 VPC オリジン と組み合わせることでプライベートリソースにすることも可能です。オリジンが URL で指定されている場合、この段階で DNS 名前解決が実行されます。これにより、 Amazon Route 53 のレイテンシーベースルーティングや地理的位置情報ルーティングといったルーティングポリシーを活用して、最適なオリジンの場所を決定できます。 レスポンスは、リクエストとは逆の経路をたどって戻ります。オリジンサーバーからのレスポンスは REC に返されます。リクエストがキャッシュ可能で圧縮が有効な場合、レスポンスは圧縮されます。キャッシュの保持期間は CloudFront ビヘイビアのキャッシュポリシーで管理されます。Lambda@Edge のオリジンレスポンス関数が定義されている場合は、この段階で実行され、その結果が REC にキャッシュされます。Lambda@Edge のビューワーレスポンス関数が定義されている場合も実行されます。セキュリティ上の理由から、レスポンスに対して実行される関数はレスポンスボディの読み取りはできませんが、置き換えることは可能です。処理は POP へと続きます。CloudFront Functions の ビューワーレスポンス関数が定義されている場合は POP で実行され、最終的なコンテンツがクライアントに配信されます。図 2 は、このリクエスト/レスポンスの流れにおける主要なステップをまとめたものです。 まとめ 本記事では、ビューワーから Amazon CloudFront を経由してオリジンサーバーへと至る単一のリクエスト、そしてオリジンサーバーからビューワーへ戻るレスポンスの流れを追いながら、CloudFront が提供する様々なレイヤーと機能について解説しました。 各機能の実行順序と、それぞれがどのレイヤーで動作するかについて理解が深まったことと思います。ぜひこの知識を活かして、お使いの CloudFront 設定(キャッシュ設定、エッジ関数、AWS WAF、AWS Shield など)を見直し、CloudFront CDN の持つすべての力を最大限に活用してください。 著者について Sanchith Kandaka Sanchith は、コンテンツデリバリとアプリケーションセキュリティの分野で 15 年以上の経験を持ち、エッジ関連のあらゆる技術に情熱を注いでいます。ソリューションアーキテクトおよびソリューションエンジニアを経て、現在は AWS のスペシャリストソリューションアーキテクトとして、Amazon CloudFront、AWS WAF、AWS Shield などの AWS Edge Services および境界保護サービスを専門としています。 Jorge Prado Jorge は、ノースカロライナの AWS でシニアテクニカルアカウントマネージャーを務めています。エンタープライズサポートのお客様が最適なソリューションを見つけ、運用面での優れた成果を達成できるよう支援することに情熱を持っています。専門分野はネットワーキング技術です。プライベートでは、読書や映画鑑賞、お子さんとのゲームを楽しんでいます。 翻訳は Solutions Architect の長谷川 純也が担当しました。

本ブログは株式会社ファイン様と Amazon Web Services Japan 合同会社が共同で執筆いたしました。 皆様こんにちは。AWSジャパン アカウントマネージャーの松家です。 近年、多くのお客様が生成AIの検証段階から本番環境への適用に移行されています。また、開発現場にも生成AIが活用される時代になり、アイデアから実装に至るまでのスピードも劇的に早くなっていることを実感しています。 「建築CGのデジタル素材」という市場において高品質なデジタル商品、サービスを提供されている 株式会社ファイン様 は実際のビジネス課題を解決する機能をAWS上で開発するハッカソンイベント AWS DEVCRAFTに参加。Amazon SageMakerやAmazon Bedrockを通じてAmazon Titan Multimodal Embeddings を活用し、設計からわずか1か月半で生成された建築AIパースのイメージに近い商品をレコメンドする機能を開発されました。 本記事では生成AIを活用した業務効率化、および顧客満足度向上の取り組みについてご紹介いたします。 お客様の状況と検証に至る経緯 株式会社ファイン様は施主の要望と設計者の見識から建築パース画像を生成するサービス「AI PERS（AIパース）」を提供されています。このサービスはお客様に大変好評だったものの、いくつか運用面で課題が残っていました。 • 施主のイメージは具体化出来るが、実際の商品とのマッチングや検索に時間がかかってしまう。 • 営業や設計の商談に差が出てしまい、お客様の検討の温度感が高い間に提案が出来ずに至ってしまう。 そこで、生成AIを活用してこれらの課題を解決できないかと考えました。 ソリューション / 構成 施主が選択したプランから、理想のお部屋イメージを入力すると入力内容に基づき建築AIパースが生成されます。その生成されたAIパースのイメージと、実際に販売している商品とをベクトル検索を通じておすすめ度の1-5位を表示します。 機能全体のフロー • 生成された画像の中から検索をかけたい部位を検出します。今回は床を想定しています。 • その床部分だけをAWS Lambdaを用いて切り抜きます。 • 切り抜かれた画像をAmazon Bedrock に渡し、ベクトル化モデルのAmazon Titan Multimodal Embeddings を活用し、ベクトル化を実施します。 • Amazon RDS PostgreSQLでベクトル検索を行い、類似品を検索します。 導入効果 ファイン様の「レコメンド AI」により、以下の効果が期待されています。 • 出力されたAIパースのイメージに近い商品を探す時間を75% 削減し、担当者の工数削減に寄与する。 • ベクトル検索を通じて、おすすめ度合いに応じて1-5位まで瞬時に表示できるため、顧客体験の標準化や向上を図る。 今後の展望 今後の展開について、ファイン様は次のように意欲を示しています。 • AIパースサービスからの連携だけでなくSNSなどの写真画像を入力としての機能拡張 • 自社のパース制作アプリケーションの自動仕様設定機能として組み込み • 自社のコンテンツ配信サービス（データステーション）の検索機能としての組み込み AWS DEVCRAFTでの取り組み内容発表時の様子 株式会社ファイン 開発部 ゼネラルマネージャー 雑賀 崇 氏

このブログ記事は、株式会社ギフティ様が執筆し、Amazon Web Services Japan が監修しています。 はじめに 株式会社ギフティ (以下、ギフティ) は「eギフトを軸として、人、企業、街の間に、さまざまな縁を育むサービスを提供する」をビジョンに掲げ、カジュアルギフトサービス「giftee」や、法人・自治体向けにeギフトを活用したソリューションを提供する「giftee for Business」などを展開しています。 本稿では、弊社の「giftee for Business」のソリューションのうちの一つであり、2025年4月1日より提供を開始したキャンペーン基盤「giftee Reward Suite」のインフラ構築事例を紹介いたします。 giftee Reward Suite は、企業の会員サービスと連携し、既存会員向けの効果的なキャンペーン施策やリワードプログラムの実装を継続して実現するための SaaS です。ユーザー認証から条件判定、抽選、ギフト配布までを一括で提供することで、企業が手軽にキャンペーンを実施できます。 giftee Reward Suite では、主に Amazon Elastic Kubernetes Service (以下、EKS) クラスタの運用管理がよりシンプルになる点に魅力を感じて、 Amazon EKS Auto Mode (以下、EKS Auto Mode) を採用しています。EKS Auto Mode は2024年12月の AWS re:Invent において一般提供が開始されました。これは、Kubernetes クラスタのコンピューティング、ストレージ、およびネットワーキングの管理を自動化する新機能です。この機能により、クラスターを迅速に構築し、パフォーマンスを向上させ、Kubernetes の実行や管理を簡素化することができます。クラスタ管理を AWS に任せることで、アプリケーションの構築に集中してイノベーションの推進により注力することが可能です。本稿では、「giftee for Business」における EKS Auto Mode の導入に至った経緯、採用したアーキテクチャ、導入効果、そして今後の展望についてご説明します。 プロジェクトの概要 本プロジェクトの開発は2024年1月頃にスタートし、2025年4月1日に 日本生命保険相互会社をクライアントとしてサービスインを迎えること が決定していました。開発体制としては、フロントエンド主担当1名、バックエンド主担当2名、そしてインフラ担当1名（筆者）の計4名で開発を進めました。 プロジェクト期間は長く見えるかもしれませんが、法人向け SaaS システムとしての要件定義や設計をゼロベースで検討する必要があるため、インフラ構築にかけられる実質的な期間は限られていました。このため、短期間での効率的な構築が求められる状況でした。 EKS Auto Mode を採用した経緯 アーキテクチャとしては、マイクロサービス的な構想があることや、インフラ側でも複雑な要件が発生する可能性が高い状況であったので Kubernetes の採用も積極的に視野に入れて検討していました。開発当初は EKS on EC2 のマネージドノードで構築を進めていましたが、プロジェクト体制や兼務の問題があり、その運用負荷の高さが大きな課題でした。 そうした最中、2024年12月に EKS Auto Mode が発表され、アドオン等の AWS マネージドな領域が大きく広がり、EKS クラスタの運用管理がよりシンプルになる点に魅力を感じ、すぐに検証を開始しました。その後、採用を決定し2025年4月より本番環境でサービス稼働しています。 採用する上で大変だった点については後述しますが、今回の対象のワークロードは一般的な Web サーバー等のステートレスの構成が多く、EKS Auto Mode や Karpenter などの採用の際に注意が必要な長時間実行されるバッチ処理やステートフルなリソースも少ない構成でした。これが短期間での検証から採用に踏み切れた決め手のうちの一つと考えています。 なお、補足しておくと、EKS Auto Mode は長期実行のワークロードでも利用可能です。その場合の注意点や設定については、AWS ブログ「 Amazon EKS Auto Mode のノード自動更新を Deep Dive する ~ 長期実行ワークロードを正しく取り扱う 」が大変参考になります。 アーキテクチャ概要 特徴として、EKS Auto Mode のデータプレーン側の EC2 ノードは、高可用性のため 3AZ に冗長化されています。また本記事に直接関連しない箇所については、一部表記を省略しております。 図 1 giftee Reward Suite アーキテクチャ概略図 導入の効果 EKS Auto Mode の導入により、運用負荷が大幅に軽減されたのが最大のメリットであると感じています。具体的な効果は以下の3点です。 クラスタ管理の簡素化：従来、EKS クラスタでは、AWS Load Balancer Controller や Kube proxy などの各種アドオンを自分たちで管理する必要がありました。EKS Auto Mode はこれらを AWS の責任範囲で自動的に管理してくれるため、バージョンアップといった運用タスクの負荷が軽減されました。 ノード管理の効率化：開発当初は、EKS Managed ノードで Auto Scaling Group を利用して EC2 インスタンスのノードを管理していました。EKS Auto Mode では Karpenter をベースとしたクラスターオートスケーラーを含めて AWS の責任で管理されるため、自身で管理する必要がない点もメリットだと感じています。 セキュリティ：EKS Auto Mode のノードでは、Bottlerocket と呼ばれるコンテナの実行に最適化された OS が利用され、セキュリティアップデートやパッチなどが AWS の責任で自動的に適用されることにより、セキュリティの安全性が確保されています。また、ノードの最大存続期間が21日に設定されており、自動的に新しいノードに置き換えられるため、セキュリティのベストプラクティスである定期的なノードの定期的な入れ替えが運用負荷なしに実現できています。 導入時の検討と課題 EKS Auto Mode は、従来の EKS に比べて AWS マネージドな領域が広がり、ユーザの運用がシンプルになる一方で、ユーザー側で設定できる範囲は狭まるというトレードオフがあると言えます。このため、導入にあたっては下記の事項について検討しましたが、今回のワークロード特性上、結果的に大きな制約とはなりませんでした。 ノードの自動更新：EKS Auto Mode では、セキュリティの観点から最大21日ごとにノードが自動的に置き換えられます。これは、ホストサーバーにデータを保存するようなステートフルなワークロードや、長時間実行されるバッチ処理などがある場合は検討すべきポイントになります。ただ今回のワークロードは、データベースとして RDS や Valkey などのサービスを活用し、アプリケーション自体はステートレスな設計にしていました。また、バッチ処理もいくつか存在するものの、短時間で処理が終了するものであり、かつ冪等性も考慮していたため、制約にはなりませんでした。 カスタム AMI の利用制限：EKS Auto Mode ではカスタム AMI を持ち込むことができません。これも、特定のソフトウェアをホストサーバーに事前にインストールしておく必要があるようなケースでは課題となり得ますが、今回のアプリケーションはホストサーバーに依存しない設計になっていたため、この点も制約とはなりませんでした。 Security Group per Pod (SGPP) の非サポート：EKS Auto Mode では、Pod 単位でセキュリティグループを付与する Security Group per Pod (SGPP) が現時点ではサポートされていません。しかし、今回のアプリケーションで、Pod 単位でセキュリティ分離を行うモチベーションは強くありませんでした。また、将来的に特定のアプリケーションからのみ、ある AWS サービスへのアクセスを許可する要件が発生しても、NodeClass を利用して NodePool ごとに異なる Security Group を適用することで、一定のセキュリティ分離は達成できると見込んでいたため、大きな制約とは判断しませんでした。とはいえ、他アプリケーションでも EKS Auto Mode を利用することを想定すれば、pod レベルで Security Group が付与できる方がより良いと考えているため、今後 SGPP 相当の機能がリリースされることを期待しています。 一方で、Karpenter や EC2 ノードの管理等、AWS がマネージドで提供する機能の挙動を理解する必要があるという点は大変だったかもしれません。上記で述べた通り、EKS Auto Mode では今までユーザーが担う必要があった部分も AWS の責務範囲になっていますが、これらの機能が AWS マネージドになったからといって、もちろんその挙動を理解しなくても良いわけではなく、同様に理解する必要があります。 今回、キャッチアップに苦労した部分もありましたが、 EKS Auto Mode のワークショップ やコミュニティ勉強会の中で、AWS のプロフェッショナルの方々や、EKS を運用している事業会社のコミュニティメンバーとのディスカッションを通じて、理解を深めることができたと感じています。 今後の展望 「giftee Reward Suite 」を、今後より多くのお客様にご利用いただくための機能開発と、サービスの安定運用に引き続き注力していきます。 特にインフラ面では Karpenter の設定最適化を進めることでインフラコストの効率化をはかりたいと考えています。具体的には、スポットインスタンスの活用等を行う予定です。 まとめ 本稿では、「giftee Reward Suite」 における Amazon EKS Auto Mode の導入事例をご紹介いたしました。 EKS Auto Mode を採用することで、Kubernetes の優れたアーキテクチャを活用しつつ、クラスターの運用管理をシンプルにすることができました。Kubernetes の採用をご検討されており、運用負荷に懸念をお持ちの方々にとって、本事例が参考になれば幸いです。 著者について 牧 純平 SIer でのキャリアを経て、2022年に株式会社ギフティへ入社。 法人向けギフトキャンペーンサービスの開発に従事し、現在はプラットフォームエンジニアリング組織の立ち上げを推進。 Rui Lee (リー) AWS Japan のソリューションアーキテクトとして、Web 業界のお客様を中心にアーキテクチャの設計・構築を支援しています。

本投稿は、Suchindranath Hegde と Mahesh Kansaraと Leonid Slepukhinと Sridhar Ramasubramanian による記事 「 Data masking and performance improvements in AWS DMS 3.5.4 」を翻訳したものです。 AWS Database Migration Service (AWS DMS) のレプリケーションエンジンバージョン 3.5.4 で新機能が利用可能になったことをお知らせできることを嬉しく思います。 このリリースには、セキュリティ強化のためのデータマスキングと、データ検証時のパフォーマンス向上という 2 つの主要な機能強化が含まれています。 この投稿では、これら 2 つの機能について詳しく説明します。この新バージョンで利用可能なすべての新機能のリストは、 リリースノート を参照してください。 セキュリティ強化のためのデータマスキング データ保護を強化するため、お客様からデータマスキング機能のリクエストがありました。これにより、移行中にカラムレベルで機密データを変換し、GDPR などのデータ保護規制への準拠を支援します。AWS DMS を使用することで、カラムレベルで保護が必要な情報を編集したデータのコピーを作成できるようになりました。 データベース移行中のお客様にとって最大の懸念事項の 1 つは、口座番号、電話番号、メールアドレスなどの機密情報の安全な取り扱いです。AWS DMS 3.5.4 では、3 つの柔軟な データ変換ルール を実装しました： 数字マスク 数字のランダム化 ハッシュマスク これらの変換ルールを説明するために、「EMPLOYEES」というテーブルを Amazon RDS for Oracle インスタンス から Amazon RDS for PostgreSQL インスタンスに移行します。 以下の手順を完了してください： ソース (Oracle) インスタンスで以下のテーブル DDL を使用して EMPLOYEES テーブルを作成します： CREATE TABLE EMPLOYEES ( EMPLOYEE_ID NUMBER(6) PRIMARY KEY, FIRST_NAME VARCHAR2(50) NOT NULL, LAST_NAME VARCHAR2(50) NOT NULL, EMAIL VARCHAR2(100) UNIQUE, PHONE_NUMBER VARCHAR2(20), HIRE_DATE DATE NOT NULL, JOB_TITLE VARCHAR2(50), SALARY NUMBER(10,2), DEPARTMENT_ID NUMBER(4), MANAGER_ID NUMBER(6), ACCOUNT_NUMBER VARCHAR2(20), CREATED_DATE DATE DEFAULT SYSDATE ); CREATE SEQUENCE emp_seq START WITH 1 INCREMENT BY 1 NOCACHE NOCYCLE ; EMPLOYEES テーブルにいくつかのレコードを挿入します。 INSERT INTO EMPLOYEES (EMPLOYEE_ID, FIRST_NAME, LAST_NAME, EMAIL, PHONE_NUMBER, HIRE_DATE, JOB_TITLE, SALARY, DEPARTMENT_ID, MANAGER_ID,ACCOUNT_NUMBER) VALUES (emp_seq.NEXTVAL, 'John', 'Smith', 'john.smith@company.com', '555-0101', DATE '2020-01-15', 'CEO', 150000, 10, NULL,'456-123-456-789'); INSERT INTO EMPLOYEES (EMPLOYEE_ID, FIRST_NAME, LAST_NAME, EMAIL, PHONE_NUMBER, HIRE_DATE, JOB_TITLE, SALARY, DEPARTMENT_ID, MANAGER_ID,ACCOUNT_NUMBER) VALUES (emp_seq.NEXTVAL, 'Sarah', 'Johnson', 'sarah.johnson@company.com', '555-0102', DATE '2020-03-20', 'IT Director', 120000, 20, 1,'666-000-111-222'); INSERT INTO EMPLOYEES (EMPLOYEE_ID, FIRST_NAME, LAST_NAME, EMAIL, PHONE_NUMBER, HIRE_DATE, JOB_TITLE, SALARY, DEPARTMENT_ID, MANAGER_ID,ACCOUNT_NUMBER) VALUES (emp_seq.NEXTVAL, 'Michael', 'Brown', 'michael.brown@company.com', '555-0103', DATE '2021-02-10', 'Software Engineer', 85000, 20, 2,'777-333-444-555'); INSERT INTO EMPLOYEES (EMPLOYEE_ID, FIRST_NAME, LAST_NAME, EMAIL, PHONE_NUMBER, HIRE_DATE, JOB_TITLE, SALARY, DEPARTMENT_ID, MANAGER_ID,ACCOUNT_NUMBER) VALUES (emp_seq.NEXTVAL, 'Emily', 'Davis', 'emily.davis@company.com', '555-0104', DATE '2021-06-15', 'HR Manager', 75000, 30, 1,'899-987-654-321'); INSERT INTO EMPLOYEES (EMPLOYEE_ID, FIRST_NAME, LAST_NAME, EMAIL, PHONE_NUMBER, HIRE_DATE, JOB_TITLE, SALARY, DEPARTMENT_ID, MANAGER_ID,ACCOUNT_NUMBER) VALUES (emp_seq.NEXTVAL, 'David', 'Wilson', 'david.wilson@company.com', '555-0105', DATE '2022-01-20', 'Software Engineer', 80000, 20, 2,'567-111-222-333'); 「移行のみ」または「移行および複製」オプションを使用して AWS DMS タスクを作成 します。 次のテーブルマッピングルール JSON を使用して AWS DMS タスクを設定します。 ACCOUNT_NUMBER 列には文字 # で、 PHONE_NUMBER 列には乱数で、 EMAIL 列にはハッシュでマスキングします。また、変換ルールを使用してすべての文字を小文字に変換するなど一部の文字を変換していますが、これはオプションです。 {     "rules": [         {             "rule-type": "transformation",             "rule-id": "171087779",             "rule-name": "171087779",             "rule-target": "column",             "object-locator": {                 "schema-name": "ADMIN",                 "table-name": "EMPLOYEES",                 "column-name": "ACCOUNT_NUMBER"             },             "rule-action": "data-masking-digits-mask",             "value": "*",             "old-value": null         },         {             "rule-type": "transformation",             "rule-id": "171057753",             "rule-name": "171057753",             "rule-target": "column",             "object-locator": {                 "schema-name": "ADMIN",                 "table-name": "EMPLOYEES",                 "column-name": "PHONE_NUMBER"             },             "rule-action": "data-masking-digits-randomize",             "value": null,             "old-value": null         },         {             "rule-type": "transformation",             "rule-id": "169940283",             "rule-name": "169940283",             "rule-target": "column",             "object-locator": {                 "schema-name": "ADMIN",                 "table-name": "EMPLOYEES",                 "column-name": "EMAIL"             },             "rule-action": "data-masking-hash-mask",             "value": null,             "old-value": null         },         {             "rule-type": "transformation",             "rule-id": "169926638",             "rule-name": "169926638",             "rule-target": "column",             "object-locator": {                 "schema-name": "%",                 "table-name": "%",                 "column-name": "%"             },             "rule-action": "convert-lowercase",             "value": null,             "old-value": null         },         {             "rule-type": "transformation",             "rule-id": "169918368",             "rule-name": "169918368",             "rule-target": "table",             "object-locator": {                 "schema-name": "%",                 "table-name": "%"             },             "rule-action": "convert-lowercase",             "value": null,             "old-value": null         },         {             "rule-type": "transformation",             "rule-id": "169908300",             "rule-name": "169908300",             "rule-target": "schema",             "object-locator": {                 "schema-name": "%"             },             "rule-action": "convert-lowercase",             "value": null,             "old-value": null         },         {             "rule-type": "selection",             "rule-id": "169895493",             "rule-name": "169895493",             "object-locator": {                 "schema-name": "ADMIN",                 "table-name": "EMPLOYEES"             },             "rule-action": "include",             "filters": []         }      ] } 次の出力例では、データマスキングを適用した PostgreSQL インスタンスの出力を確認することができます: dmsdb=> select employee_id,phone_number,email,account_number from admin.employees ;   employee_id | phone_number |                               email                               | account_number -------------+--------------+------------------------------------------------------------------+-----------------            20 | 685-9897     | FDC2A4ABC53872D0F934B5614DDC312DAA165895065BB00A5986849AADE8C322 | ***-***-***-***            21 | 579-3441     | 3A4FA9FE0AA0A2B468EDF13A29A75C4E3A20650243143D834D7898D40AA0FA2F | ***-***-***-***            22 | 156-9277     | 0985B1D142A4067E397DF5AB56B03E3BF4857FB1F229CB39B49CE06E46B7AA98 | ***-***-***-***            23 | 238-5321     | D07EAB207F4F1366C1E35B35E33F7842FF3EEB2C80E47FDAEB0900B49EE77697 | ***-***-***-***            24 | 536-1233     | 3D438AF13A839ACDC24FD0CE8EB8C8C45083B90A31DF3583A88131614086C3B9 | ***-***-***-*** (5 rows) 以下の画像は、比較のために Oracle での出力例を示しています。 前述の例では、データマスキング機能を使用して機密情報をマスキングする方法を示しました。詳細については、 データマスキングを使用して機密情報を隠す を参照してください。 データ検証パフォーマンスの強化 データの整合性を維持することは、どのデータベース移行においても重要ですが、多くの場合、時間とリソースを大量に消費するプロセスです。AWS DMS 3.5.4では、高速パーティション検証などの革新的な手法を使用して検証プロセスを合理化する 拡張データ検証機能 によってこの課題に対処しています。 強化されたデータ検証の主な利点には、以下のようなものがあります： レプリケーションインスタンスから AWS DMS のソースおよびターゲットエンドポイントへのリソース使用量の再分配 潜在的なネットワーク使用量の減少 LOB データ型を含まない幅広いテーブルに効率的 拡張データ検証機能は、Oracle から PostgreSQL、SQL Server から PostgreSQL、Oracle から Oracle、SQL Server から SQL Server など、特定の AWS DMS による移行パスで利用できるようになりました。この機能を使用するには、環境が 前提条件 を満たしていることを確認してください。 AWS DMS が拡張データ検証を使用しているかどうかは、 Amazon CloudWatch ログを見れば確認できます。次のようなメッセージが表示されます: 2025-02-12T21:23:26 [VALIDATOR ]I: Fast validation of table 'dbo'.'customer' : partition : 178 (partition_validator.c:1001) パフォーマンスの向上を定量化するために、以下のスクリーンショットに示す設定で HammerDB を使用してベンチマークを実施しました。 ベースラインとして、検証を無効にしたフルロードと変更データキャプチャ (CDC) タスクを作成し、約 9,300 万レコード (サイズ 15 GB) を Amazon RDS for SQL Server から Amazon Aurora PostgreSQL 互換エディション へ、合計 9 つのテーブルにわたって移行しました。 次に、2 つの 検証のみ タスクを実行しました。1 つは AWS DMS 3.5.3 で、もう 1 つは AWS DMS 3.5.4 で、どちらも r6i.xlarge インスタンスを使用しました。 検証を高速化するために、 PartitionSize を 100,000 に、 ThreadCount を 15 に増やしました： "ValidationSettings": { "PartitionSize": 100000, "ThreadCount": 15, "ValidationOnly": true } 次のスクリーンショットは、エンジンバージョン 3.5.4 で実行されている AWS DMS レプリケーションインスタンスのリソース消費量を示しています。 次のスクリーンショットは、エンジンバージョン 3.5.3 で実行されている AWS DMS レプリケーションインスタンスのリソース消費量を示しています。 AWS DMS 3.5.3 と比較して、AWS DMS 3.5.4 で実行した場合、検証のみのタスクの TaskMemoryUsage が 91% 減少し、基盤となるAWS DMS レプリケーションインスタンスの CPU 使用率が 95% 削減されることがわかります。検証のみのタスクを別に実行したいお客様は、この機能を使用して、AWS DMS レプリケーションインスタンスのコンピューティングとメモリをより有効に活用できます。 まとめ この投稿では、AWS DMS 3.5.4 におけるデータマスキングと強化されたデータ検証の変換ルールについて説明しました。 データマスキング機能を実装することで、データベース移行プロセス全体を通じて機密情報を確実に保護できます。 拡張データ検証機能により、DMS レプリケーションインスタンスのリソース消費を抑えながら、検証を実行するすべての利点を得ることができます。 これらの機能を試してみて、あなたのユースケースにどのように役立ったかをコメント欄でお聞かせください。 著者について Suchindranath Hegde は Amazon Web Services のシニアデータ移行スペシャリストソリューションアーキテクトです。彼はお客様と協力して、AWS DMS を使用した AWS へのデータ移行に関するガイダンスと技術支援を提供しています。 Mahesh Kansara は、Amazon Web Services のデータベースエンジニアリングマネージャーです。 彼は開発およびエンジニアリングチームと密接に協力して、移行およびレプリケーションサービスの改善に取り組んでいます。 また、お客様と協力して、さまざまなデータベースおよび分析プロジェクトに関するガイダンスと技術支援を提供し、AWS を使用する際のソリューションの価値向上を支援しています。 Leonid Slepukhin は、Amazon Web Services の Database Migration Service (DMS) チームのシニアデータベースエンジニアです。 AWS DMS のコア機能の開発に取り組み、社内外の顧客が複雑なデータベース移行とレプリケーションの課題を解決するのを支援することを専門としています。 DMS の機能強化と、AWS クラウドへのデータベース移行を成功させるための技術的専門知識の提供に重点を置いています。 Sridhar Ramasubramanian は、AWS Database Migration Service チームのデータベースエンジニアです。 AWS のお客様のニーズにより適合するよう、DMS サービスの改善に取り組んでいます。

本投稿は、Veeramani A と Manoj Ponnurangam による記事 「 Best practices to handle AWS DMS tasks during PostgreSQL upgrades 」を翻訳したものです。 AWS Database Migration Service は、データのセキュリティとデータの整合性を提供しながら、データベースを Amazon Web Services (AWS) に移行およびレプリケーションするためのマネージドソリューションを提供します。AWS DMS は、ソースとターゲットのデータベースが同じエンジンを使用する 同種の移行 と、異なるデータベース環境間の 異種の移行 の両方に対応しています。 AWS DMS は、PostgreSQL データベースから サポートされているターゲット へのデータ移行を容易にし、また サポートされているソース から PostgreSQL データベースへの移行も可能にします。これにより、企業がデータインフラストラクチャをクラウドに移行するための堅牢な経路を提供します。 ソリューションの概要 オープンソースの PostgreSQL は、頻繁に発生するバグ、セキュリティ問題、データ破損の問題の修正を含む 新しいマイナーバージョンとメジャーバージョンをリリース することがあります。一般的に、Amazon RDS は、 新しいエンジンバージョンが利用可能になってから 5 か月以内にサポート することを目指しています。特定のバージョンがサポートされなくなった場合には PostgreSQL インスタンスをアップグレードする必要があります。問題の解決や新しい改善の導入、あるいはコンプライアンスの遵守やデータ保護のためにも PostgreSQL インスタンスをアップグレードする必要があります。 進行中の AWS DMS タスクのソースまたはターゲットとして設定されている PostgreSQL データベースをアップグレードする場合は、これをアップグレード計画に組み込むことが重要です。 この記事では、PostgreSQL のマイナーバージョンまたはメジャーバージョンへのアップグレード中に AWS DMS タスクを処理するためのベストプラクティスについて説明します。 前提条件 この記事のソリューションをテストするには、以下のリソースが必要です： AWS DMS レプリケーションインスタンス RDS for PostgreSQL または Amazon Elastic Compute Cloud（Amazon EC2）かオンプレミスで実行されている PostgreSQL ソースとターゲットのエンドポイント ソースまたはターゲットでPostgreSQLを指定する AWS DMS タスク PostgreSQL のバージョンアップグレードの理解 PostgreSQL のアップグレードが AWS DMS タスクにどのように影響するかを詳しく見る前に、PostgreSQL におけるメジャーバージョンとマイナーバージョンのアップグレードについて明確に理解しておきましょう。 マイナーバージョンは、セキュリティの脆弱性を修正し、バグを修正し、一般的に新機能を追加しません。 マイナーリリースは内部ストレージ形式を変更せず、常に同じメジャーバージョン番号の前後のマイナーリリースと互換性があります。 例えば、バージョン 14.10 は、バージョン 14.9 およびバージョン 14.16 と互換性があります。 PostgreSQL のメジャーリリースでは、システムテーブル、データファイル、内部データストレージ形式も変更される可能性があります。RDS for PostgreSQL は、ネイティブの pg_upgrade ユーティリティを使用して、インスタンスを新しいメジャーバージョンにアップグレードします。アップグレードの詳細については、 Amazon RDS の PostgreSQL DB エンジンのアップグレード をご参照ください。 マイナーリリースとメジャーリリース、またはバージョンアップグレードのいずれもダウンタイムが発生するため、適切なメンテナンスウィンドウ内で実施する必要があります。できればデータベースへのクエリが最も少ない時間帯にスケジュールされたメンテナンスウィンドウをこのアップグレード作業のために計画することをお勧めします。 AWS DMS と PostgreSQL の連携 AWS DMS を使用して PostgreSQL ソースから PostgreSQL ターゲットにデータを移行する場合を想定しましょう。 フルロード中、AWS DMS はソースの PostgreSQL データベースに接続し、テーブルマッピングで定義されたテーブルで select * を実行してデータをアンロードします。ソースから取得したデータは、PostgreSQL ターゲットに向けてレプリケーションインスタンスの CSV ファイルに書き込まれます。PostgreSQL ターゲットの場合、AWS DMS は COPY コマンドを使用して、CSV ファイルのデータをターゲットの PostgreSQL テーブルにロードします。 移行中の継続的な変更を取り込むために、AWS DMS はソースの PostgreSQL データベースに論理レプリケーションスロットを作成します。スロットは、変更のストリームを表し、ソースの PostgreSQL データベースで実行された順序でクライアントに再生することができます。DMS は、レプリケーションスロットからの変更のロジカルデコーディングに test_decoding または pglogical プラグイン のいずれかを使用します。ソースの PostgreSQL データベースで pglogical プラグインが利用可能な場合、DMS は pglogical を使用してレプリケーションスロットを作成します。そうでない場合は、 test_decoding プラグインが使用されます。ソースから読み取られた変更は、レプリケーションインスタンス上のソーターコンポーネントに渡されます。ソーターコンポーネントはトランザクションをコミット順にソートし、その後、DMS タスクの設定に基づいて、順次またはバッチモードでこれらの変更をターゲットデータベースに適用します。 レプリケーションスロットは、フルロード + CDC および CDC のみのタスクにおいて重要な役割を果たします。 これは、ソースの PostgreSQL データベース上で必要なログ先行書き込み (WAL) ファイルを保持する役割を担っています。 ソースデータベース上でレプリケーションスロットが削除されると、DMS はソースデータベースからの継続的な変更を処理できなくなります。 PostgreSQL のアップグレードが AWS DMS タスクに与える影響 以下のセクションでは、ソースまたはターゲットの PostgreSQL データベースのマイナーバージョンまたはメジャーバージョンのアップグレード中に、DMS タスクをどのように扱うかについて説明します。 ソース PostgreSQL データベースのアップグレード時 フルロードのみの DMS タスクは、1 回限りのデータ移行用に設計されています。 これらのタスクは、ソースの PostgreSQL データベースのマイナーバージョンまたはメジャーバージョンのアップグレード後に安全に再開できます。 フルロード + CDC および CDC のみの DMS タスクは、進行中の変更をターゲットデータベースに継続的に複製します。PostgreSQL のアップグレード中に、フルロード + CDC および CDC のみの DMS タスクを処理する場合、次のセクションのベストプラクティスに従ってください。 マイナーリリースまたはバージョンアップグレード マイナーバージョンのアップグレードを行う前に、実行中の AWS DMS レプリケーションタスクを停止してください。マイナーバージョンのアップグレードが完了したら、DMS タスクを再開できます。 メジャーバージョンアップグレード 執筆時点で、DMS は PostgreSQL バージョン 9.4 以降 (9.x バージョン)、10.x、11.x、12.x、13.x、14.x、15.x、および 16.x をサポートしています。 メジャーバージョンアップグレードを実行する際は、レプリケーションインスタンスが新しい PostgreSQL バージョンをサポートしていることを確認してください。 pg_upgrade を使用してメジャーバージョンアップグレードを進めるには、ソースの PostgreSQL データベース上のレプリケーションスロットを削除する必要があります。これらのスロットを削除しないと、アップグレードプロセスに影響を与える可能性があります。レプリケーションスロットを削除せずにアップグレードを試みると、 pg_upgrade_precheck.log に 1 つ以上の論理レプリケーションスロットによってブロックされたためインスタンスをアップグレードできなかったというメッセージが表示され、アップグレードは失敗します。ただし、レプリケーションスロットを削除すると AWS DMS タスクが無効になり、進行中のレプリケーションタスクを再開できなくなります。 この問題に対処し、メジャーバージョンアップグレード中に進行中のレプリケーションタスクを管理するには、以下の手順を使用します： PostgreSQL データベースへのすべてのアプリケーション接続を停止します。以下を使用してアクティブな接続を監視します： select * from pg_stat_activity where datname = 'database_name'; 必要に応じて、残りの接続を以下のコマンドで終了します： select pg_terminate_backend(pid) from pg_stat_activity where datname = 'database_name'and pid <> pg_backend_pid(); AWS DMS タスクのメトリクスを監視して、 CDCLatencySource と CDCLatencyTarget の両方がゼロに近いことを確認します。これにより、DMS タスクが変更を遅延なく複製していることを確認できます。ターゲットで awsdms_txn_state を使用してタスクステータスを取得することもできます（タスク設定「 TaskRecoveryTableEnabled = True 」で有効にできます）。次の画像は、 CDCLatencySource と CDCLatencyTarget の Cloudwatch メトリクスを示しています。 レイテンシーがゼロに近づいたら、実行中のアクティブなレプリケーション DMS タスクをすべて停止してください。 ソースの PostgreSQL データベースから既存のレプリケーションスロットを削除します。 postgres=> select * from pg_replication_slots ; slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size -----------------+-------------+-----------+--------+----------+-----------+--------+------------+------+-------------+-------------+-------------------+------------+--------------- bb6jw1f3enambi4z_00014405_e3972613_00e2_4960_ae4c_fe267b1cfcde | test_decoding | logical | 14405 | postgres | f | f | | | 898 | 0/5936F798 | 0/5F1A3440 | reserved | (1 row) postgres=> SELECT pg_drop_replication_slot('bb6jw1f3enambi4z_00014405_e3972613_00e2_4960_ae4c_fe267b1cfcde'); pg_drop_replication_slot -------------------------- (1 row) レプリケーションスロットがないことを確認してください。 postgres=> select * from pg_replication_slots ; slot_name | plugin | slot_type | datoid | database | temporary | active | active_pid | xmin | catalog_xmin | restart_lsn | confirmed_flush_lsn | wal_status | safe_wal_size -----------+--------+-----------+--------+----------+-----------+--------+------------+------+-------------+-------------+-------------------+------------+--------------- (0 rows) PostgreSQLデータベースのインプレイスアップグレードを完了してください。 アップグレードプロセスが正常に完了したことを確認します。データベースレベルの検証チェックを実行して、アップグレード後にデータベースが期待通りに動作していることを確認します。アプリケーションを開始する前に、DMS タスクを処理するために step 8 または step 9 のいずれかに従ってください。 CDC のみのタスクを新しく作成してください。タスク設定で、 ソーストランザクションの CDC 開始モード の カスタム CDC 開始モードを無効にする を選択します。古いタスクと同様に、他のタスク設定とテーブルマッピングを定義します。 タスクが作成されたら、CDC のみのタスクを開始します。これにより、ソースの PostgreSQL データベースに新しいレプリケーションスロットが作成され、レプリケーションスロットが作成された時点からの変更の移行が開始されます。 または、指定されたログシーケンス番号 (LSN) から開始する DMS CDC のみのタスクを使用して、ソース PostgreSQL データベースにレプリケーションスロットを手動で作成することもできます。ソースにレプリケーションスロットを作成し、 confirmed_flush_lsn を記録してください。 confirmed_flush_lsn は、論理スロットのコンシューマーが PostgreSQL エンジンにデータを受信したことを確認した最後の LSN を表します。 この LSN より前にコミットされたトランザクションに対応するデータは、もはや利用できません。 a. ソースエンドポイントの設定を変更し、ソース PostgreSQL データベースで作成した目的のスロットを SlotName として追加します。 b. タスク設定を変更してください。 カスタム CDC 開始モードを有効にする を選択し、 ログシーケンス番号を指定する (訳者注 : DMS マネジメントコンソールの新しいナビゲーションの場合 「ネイティブな CDC 開始点」) を選択して、 confirmed_flush_lsn から LSN を入力します。 DMS タスクを開始し、変更が問題なくターゲットデータベースに移行されていることを確認します。 アプリケーションを起動し、DMS CDC レプリケーションを監視します。 ターゲットの PostgreSQL データベースをアップグレードする時 AWS DMS CDC は、ターゲットの PostgreSQL データベースのマイナーバージョンアップグレードの影響を受けません。 DMS のターゲットとして設定された PostgreSQL データベースをアップグレードする前に、DMS タスクを停止し、マイナーバージョンアップグレードが成功した後に再開してください。 DMS のターゲットとして設定された PostgreSQL データベースでメジャーバージョンアップグレードを実行する場合： 現在のレプリケーションインスタンスエンジンのバージョンが新しい PostgreSQL バージョンをサポートしていることを確認してください。 新しいエンジンバージョンが現在のレプリケーションインスタンスバージョンでサポートされている場合は、AWS DMS タスクを停止し、メジャーバージョンのアップグレードを完了してから DMS タスクを再開できます。 新しいエンジンバージョンが現在のレプリケーションインスタンスバージョンでサポートされていない場合は、DMS タスクを停止して、ターゲットの PostgreSQL データベースでメジャーバージョンのアップグレードを完了する必要があります。また、レプリケーションインスタンスを、ターゲットの PostgreSQL データベースの現在のバージョンをサポートするバージョンにアップグレードする必要があります。ターゲットデータベースとソースデータベースの両方が互換性のあるメジャーバージョンに更新されたら、DMSタスクを再開できます。 クリーンアップ この投稿で作成したリソースを削除することで、変更を元に戻し、継続的な料金の発生を避けることができます： このソリューションのテストのために作成され、不要となった RDS for PostgreSQL インスタンス と EC2 インスタンス を削除します。 このソリューションのテストのために作成された AWS DMS タスクを削除します 。 AWS DMS のソースエンドポイントとターゲットエンドポイントを削除します 。 AWS DMS レプリケーションインスタンスを削除します 。 まとめ この投稿では、PostgreSQL データベースを AWS DMS のソースまたはターゲットとして構成している場合に、アップグレード時に DMS タスクをどのように扱うかについて説明しました。 このソリューションを試してみて、フィードバックや質問をコメントで共有してください。 About the Authors Veeramani A は Amazon Web Services のクラウドデータベースエンジニアで、AWS Database Migration Service とAmazon RDS for PostgreSQL で SME(Subject Matter Expert)を務めています。15 年以上にわたる多様なデータベーステクノロジーの経験を持つ彼は、AWS へのデータベース移行を進めるお客様に戦略的ガイダンスと技術的専門知識を提供しています。 Manoj Ponnurangam は、Amazon Web Services のクラウドデータベースエンジニアとして働いています。彼はAmazon RDS for Oracle、Amazon RDS for PostgreSQL、AWS DMS の SME(Subject Matter Expert) です。Manoj はリレーショナルデータベースを15 年扱ってきた経験があります。彼はお客様と協力して、さまざまなデータベースや移行プロジェクトに関する指導や技術支援を提供しています。

こんにちは！ アマゾン ウェブ サービス ジャパンのソリューションアーキテクト馬渕です。 2025 年 11 月 21 日 (金) 15:30-17:00 、AWS Japan の目黒オフィスにて、Dify と AWS に関するイベント「 企業の生成 AI 活用を加速する Dify Enterprise on AWS 〜セキュアなデータの活用とパートナー導入事例〜 」の開催が決定しました。社内の生成 AI 活用を加速するために Dify を利用したいお客様、すでに Dify を利用していてさらにセキュアなデータも扱いたいお客様、Dify Enterprise を利用したいものの導入・運用に不安をお持ちのお客様に、今後のさらなる活用のためのヒントをご提供します。 Dify のご紹介と、 AWS とのシナジーのご紹介 Dify は、生成 AI アプリをノーコードで開発できるプラットフォームです。技術者以外でも AI アプリが作れる使いやすさから多くのお客様の注目を集めており、社内の生成 AI 基盤として PoC ・本番導入しているお客様が増えてきています。Dify には SaaS 利用するか自社の環境にセルフホストするかの 2 つの利用方法があり、後者のセルフホスト方式では多くのお客様が AWS 上で Dify をデプロイし、セキュアに社内の生成 AI 推進を実現しています。なお、前者の Dify Cloud も AWS 上で稼働しており 、AWS 上での Dify の稼働実績を十分に裏付けるものになっています。 また、AWS では、AWS 上に Dify をスケーラブルかつマネージドな環境でセルフホストするための AWS CDK サンプル や、それをワンクリックでデプロイするための AWS Generative AI Solution Box を公開しています。また、 AWS 上に簡易な構成で Dify 環境を構築し、その上で AI アプリケーションを構築する方法を学ぶワークショップ も公開しており、Dify を通じたお客様の生成 AI 活用をご支援しています。 GitHub 上で公開している Dify on AWS with CDK サンプルのアーキテクチャ Dify Enterprise のメリットとユースケース そして、 Dify をエンタープライズ規模でセキュアに社内利用するのに役立つのが Dify Enterprise です。OSS 版 Dify の機能に加えて、自社 IdP とのシングルサインイン機能や、マルチワークスペースによるアプリケーション利用の細かい権限管理など、社内利用に役立つガバナンス向上のための機能を備えています。 Dify Enterprise のライセンスは AWS Marketplace 上でも購入可能 になっており、これを用いて AWS 上にデプロイすればセルフホスト時の基盤の費用とライセンス費用を効率的に管理することが可能です。 Dify Enterprise を利用することで特にメリットのあるユースケースの 1 つが、セキュアなデータソースとの連携です。Dify には様々な SaaS やアプリケーションと連携できるプラグインのエコシステムがあり、例えば企業のデータウェアハウスと連携して社内データを活用した生成 AI アプリケーションを構築できます。Dify Enterprise の権限管理機能では、アプリケーションやプラグインへの細やかなアクセス可否を制御できるため、公開範囲が厳密なデータソースを連携するアプリケーションであっても安心して組み込むことが可能になります。 11/21(金) のイベントの詳細 今回のイベントでは、企業で社内の生成 AI 活用を推進する方を対象に、Dify Enterprise をご活用いただくための情報をご提供いたします。Dify の最新情報アップデートや、 Dify Enterprise ならではのセキュアなデータを扱うユースケースのご紹介に加えて、Dify の Eliter Partner でもあり AWS パートナーでもある株式会社リコー様にもご登壇いただき、Dify Enterprise の構築・運用のナレッジについてご共有いただきます。 開催概要 タイトル : 企業の生成 AI 活用を加速する Dify Enterprise on AWS 〜セキュアなデータの活用とパートナー導入事例〜 日時 : 2025年11月21日（金）15:30-17:00 (15:00 開場) 終了後、懇親会あり 参加費 : 無料 お申し込み方法 : イベントの ランディングページ よりフォームにアクセスしてお申し込みください 開催場所 : 〒153-0064 東京都目黒区下目黒1-8-1 ARCO TOWER 19 F JR線・東急目黒線・東京メトロ南北線・都営地下鉄三田線 目黒駅より徒歩約5分 [ google map ] [ ARCO TOWERへのアクセス方法 ] アジェンダ 開始 終了 コンテンツ プレゼンター 15:30 15:35 オープニング アマゾン ウェブ サービス ジャパン 合同会社 15:35 15:55 Dify Updates : RAG 2.0, MCP 株式会社 LangGenius 15:55 16:15 Dify Enterprise でセキュアなデータを扱おう 〜Snowflake と連携してインサイトを生む〜 株式会社 LangGenius アマゾン ウェブ サービス ジャパン 合同会社 16:15 16:30 Dify on AWS の選択肢と、AWS で Dify を使う理由 アマゾン ウェブ サービス ジャパン 合同会社 16:30 16:50 パートナーと進める Dify 活用 株式会社リコー 16:50 17:00 Q&A / クロージング アマゾン ウェブ サービス ジャパン 合同会社 17:00 18:00 懇親会 – ※ アジェンダやスピーカーは変更となる可能性がございます。 こんな課題をお持ちのお客様に 機密性の高いシステムと生成 AI の安全な連携方法を模索している 部門やプロジェクトごとに異なるセキュリティレベルでの AI 活用を検討している コンプライアンスを確保しながら生成 AI の全社展開を進めたい Dify を活用したいが、その導入・運用のナレッジやリソースに不安がある お申し込み方法 イベントの ランディングページ よりフォームにアクセスしてお申し込みください。会場の定員の都合上、抽選とさせていただく場合がございますのでご了承ください。ご不安・ご不明点がある場合は、 AWS の担当営業にお声がけください。

本記事は 2025 年 10 月 10 日に公開された “ Boosting Unit Test Automation at Audible with Amazon Q Developer ” を翻訳したものです。 Amazon の子会社である Audible は、オーディオストーリーテリングの大手プロデューサーかつプロバイダーです。オーディオブック、ポッドキャスト、特別にキュレーションされた Audible Originals を含む 100 万タイトル以上の膨大なライブラリを持っています。Audible は没入感のあるオーディオ体験で、日常を学習や想像力、エンターテイメントの機会に変えています。数百万のエンドユーザーがデバイス間でシームレスな体験を楽しめるよう、堅牢なテストが重要です。 テストカバレッジが不十分なコードベースを引き継いだ経験はありませんか？あるいは、締切に間に合わせるために急いでコードを書き、「後で」テストを追加すると約束したことは？私たちは皆そのような経験があります。テストは重要ですが、締切が迫ると優先度が下がりがちです。そこで Amazon Q Developer のエージェント機能が登場し、開発者のテスト生成アプローチを変革しています。このブログでは、Audible が Amazon Q Developer を活用してユニットテストカバレッジを向上させた方法を紹介します。 ソフトウェアテストのビジネスユースケース ベロシティの高い開発環境では、厳しい締切の下でテストサイクルが圧縮されることが多く、品質に問題が生じやすくなります。Amazon Q Developer は包括的な基準を維持しながらテストを加速し、この状況を変えます。自動テスト生成、エッジケースの特定、修正提案により、チームは短い時間で徹底的なテストを実行できます。これにより迅速なリリース、QA リソースの最適化、本番環境への準備強化を実現します。 適切なテストが実装されていない各関数は、作り直し、バグ、メンテナンスの課題につながる可能性があります。さらに、引き継いだコードベースは特別な課題を提示します。開発者は既存機能のテストを書くのに数週間を費やすか、テストなしでの開発を続けるかという難しい選択を迫られます。 Amazon Q Developer は適切なテストカバレッジに必要な時間と労力を削減し、これらの課題に対処します。テストを面倒な作業から効率的なプロセスに変え、チームがコード品質を確保しながら新機能の提供に集中できるようにします。 Amazon Q Developer：コードベースのテストカバレッジ拡張 Amazon Q Developer のエージェント機能は、ソフトウェアテスト生成に高度なアプローチを提供します。汎用的なテストを生成する従来ツールとは異なり、Amazon Q Developer はコードの意図、ビジネスロジック、エッジケースを分析します。単にテストを生成するだけでなく、コードの動作を包括的に検証する意味のあるテストスイートを作成します。 今回紹介する専用のテスト生成機能以外にも、Amazon Q Developer はテストを支援するさまざまな方法を提供します。テスト計画生成のための会話型プロンプトの使用、既存コードのテスト改善要求、テスト作成時の Amazon Q Developer とのペアプログラミングなどが可能です。テスト開発プロセス全体に AI アシスタンスを統合する柔軟性により、Amazon Q Developer は開発者にとって多用途なパートナーとなります。 Amazon Q Developer のワークフローアーキテクチャ 以下のアーキテクチャ図は、Audible がテスト生成とコード変換の両方で Amazon Q Developer を活用した方法を示しています。 Amazon Q Developer の開発プロセスは、2つの主要な機能を実証します。 テスト生成： Amazon Q Developer は Java クラスを分析し、ユニットテスト、エッジケーステスト、例外処理テストを含む包括的なテストスイートを作成します。 コード変換： Amazon Q Developer は自動移行タスクを実行します。これには JDK 8 から JDK 17/21 へのアップグレード、言語バージョン互換性の処理、 JUnit 4 から JUnit 5 への変換、テストフレームワークの構文とアノテーションのモダナイゼーション、非推奨 API とコードパターンの更新が含まれます。 この開発プロセスがとくに強力なのは、AI 機能と人間の専門知識を組み合わせる点です。エキスパート開発者が日常の開発プロセスで AI を活用できるようにします。Amazon Q Developer はコードベースを分析してコンテキストとして使用し、エッジケースを特定し、自動変換を実行します。一方で開発者はドメイン知識を適用し、出力がビジネス要件と期待される動作に合致することを確保します。 Amazon Q Developer の可能性を活用する Audible のアプローチ Audible チームは、Amazon Q Developer を活用してテストカバレッジを向上させるために以下のステップに従いました。 コード生成： Audible チームは Amazon Q Developer を活用し、Java クラスの追加ユニットテストを生成してテストカバレッジを強化しました。対象には静的メソッドや既存のテストケースを持つメソッドも含まれます。このアプローチは彼らの堅牢なテスト戦略を補完しました。Amazon Q Developer はクラス、メソッド、パラメータ、戻り値の型、例外を調べる能力を持っています。null 入力チェックや空文字列チェックなど、見落としやすいエッジケースをカバーするユニットテストを自動的に特定します。 対象を絞った要求： Audible チームは Amazon Q Developer に以下を提供するよう具体的に依頼しました。 Java クラス内の指定されたメソッドをカバーするユニットテストの提案 テストされていないエッジケースを対象とするユニットテストの推奨事項 エラー処理と例外シナリオに対処するテストケースの推奨事項 Audible チームはテスト生成とコード変換の両方で Amazon Q Developer を使用し、大幅な改善を達成しました。成功の鍵は体系的な開発プロセスで、対象を絞ったプロンプトとともに豊富なコンテキストを提供することでした。 開発者の作業の流れ Audible は自動化ツールからの出力をレビューするため、人間参加型のアプローチを採用しています。上記の開発プロセスは完全なプロセスを示しています。：（1）IDE でクラスファイルを開く、（2）特定のメソッドを選択してプロンプトを追加する、（3）この組み合わされたコンテキストを Amazon Q Developer に送信する、（4）生成されたテストを受け取る、（5）テストをレビューしてコードベースに統合する。 効果的なプロンプトとアプローチ Audible チームは Amazon Q Developer が対応できる対象を絞った要求を使用し、構造化されたアプローチに従いました。 コード生成： チームは Java クラスを Amazon Q Developer に提供し、個々のメソッドのテストを生成しました。対象には静的メソッドや、既にいくつかのテストがあるが完全なカバレッジが不足しているメソッドも含まれます。Amazon Q Developer はクラス、メソッド、パラメータ、戻り値の型、例外を調べ、null 入力チェックや空文字列チェックなどのエッジケースをカバーするユニットテストを自動的に特定しました。 特定のリクエストのための汎用サンプルプロンプト 基本的なテスト生成： 以下の Java メソッドのユニットテストを生成してください。すべての可能な入力シナリオとエッジケースをカバーすることに焦点を当ててください： [メソッドコードをここに] 以下のテストを含めてください： - 有効な入力シナリオ - Null 入力チェック - 空文字列検証 - 例外処理 エッジケースフォーカス： ユーザー入力を処理するこのメソッドがあります。見落としている可能性のあるエッジケースをカバーするユニットテストを提案してもらえますか？境界条件とエラーシナリオにとくに注意してください： [メソッドコードをここに] 手動フレームワーク移行（Q Developer Chat 経由）： この JUnit 4 テストを JUnit 5 形式に変換してください。アノテーションを更新し、適切な場合は最新の JUnit 5 機能を使用するようにしてください： [JUnit 4 テストコードをここに] 注意：Amazon Q Developer のコード変換機能は、コードベース全体で JUnit4 から JUnit5 への移行を自動的に処理できますが、Audible は上記のように手動でターゲット化された変換のために会話型インターフェイスも使用しました。両方のアプローチが利用可能です。自動変換の詳細については ドキュメント を参照してください。 テスト生成： チームのリクエストに基づいて、Amazon Q Developer は適切なアサーションとテストメソッドでこれらの領域に対処する特定のテスト提案を生成しました。 実装： 開発チームは、レビュー後に提案されたテストを実装しました。 ドキュメント： Amazon Q Developer は、テストの目的、テストがカバーしている機能の領域を説明するコメントを追加する能力を持っています。さらに、Amazon Q Developer は、readme ファイルやプロジェクトドキュメントなど、他の側面に関連するドキュメントを生成する能力も持っています。 定量化可能な結果 Amazon Q Developer を活用することで、Audible チームは以下を達成しました。 10 以上の主要パッケージ が包括的なユニットテストカバレッジを受けました テストクラスあたり約 1 時間 の節約（通常 8-10 の個別テストを含む） 5,000 以上のテストケース が Amazon Q Developer のコード変換と手動での会話支援の両方を使用して JUnit4 から JUnit5 に正常に移行されました Amazon Q Developer のコード変換を使用し、 JDK8 から JDK17 への移行にて  50 時間以上の手作業を節約 AI 支援変換による人的エラーの削減 主要機能の実証結果 Amazon Q Developer は、手動テストで見落とされがちないくつかの領域で優れていました。 包括的な例外テスト： 標準的な null 入力チェックと空文字列検証を超えて、 IllegalArgumentException 、 NullPointerException 、カスタムビジネス例外のテストを自動的に提案しました。例外の投げ方と特定のエラーメッセージの両方の検証を含みます。この体系的なアプローチによりテストカバレッジがより完全になり、エラー処理がより堅牢になりました。 自動エッジケース検出： Amazon Q Developer はプロンプトなしで null ポインタ例外処理のインライン提案を行い、プロセスをよりスムーズで高速にしました。 AI 支援による手動フレームワーク移行： Amazon Q Developer のパターン認識は会話支援を通じて移行プロセスを加速しました。チームはチャットを通じて Amazon Q Developer に JUnit4 から JUnit5 へのテスト構文を手動で変換するよう依頼できました。たとえば、以前のセットアップには @UseDataProvider と @DataProvider アノテーションを持つ JUnit4 構文がありました。必要な作業はコードブロックをハイライトし、Send to Prompt して、Amazon Q Developer にテストを JUnit5 互換にするよう依頼することだけでした。数秒以内に ParameterizedTest アノテーションと Stream of Arguments を持つ信頼性の高い JUnit5 テストを生成し、手動で実装できました。 コンテキスト分析： Amazon Q Developer は既存のコードベースを分析してパターンを認識し、チームのコーディングスタイルとテスト規約に一致するテストを生成しました。 まとめ Amazon Q Developer はテスト生成プロセスを時間のかかる作業から効率的な開発プロセスに変換し、チームが最小限の労力で包括的なテストカバレッジを達成できるようにします。これにより開発者はコード品質と信頼性を向上させながら、より価値の高い活動に集中できます。 ビジネスへの影響は大きく、テストが負担でなくなるとチームは自然により良いテスト手法を採用します。全体的なコード品質が向上し、より高速な開発サイクルとメンテナンス時間の削減という好循環を作り出します。 Amazon Q Developer の機能と価格の詳細については、 Amazon Q Developer 製品ページ をご覧ください。 翻訳はApp Dev Consultantの宇賀神が担当しました。 著者について Kirankumar Chandrashekar は AWS の Generative AI Specialist Solutions Architect で、Q Developer、Kiro、AI を使用した Developer Productivity などの次世代開発者体験ツールに焦点を当てています。AWS クラウドサービス、DevOps、モダナイゼーション、Infrastructure as Code の深い専門知識を持ち、革新的な AI 駆動ソリューションを通じて顧客の開発サイクルを加速し、開発者の生産性を向上させることを支援しています。Amazon Q Developer を活用することで、チームがアプリケーションをより高速に構築し、日常的なタスクを自動化し、開発作業の流れを合理化できるようにしています。Kirankumar は、複雑な顧客の課題を解決しながら開発者の効率を向上させることに専念しており、音楽、料理、旅行を楽しんでいます。   Alex Torres は AWS の Senior Solutions Architect で、AWS 上でのアプリケーションのアーキテクチャ設計、設計、構築において Amazon.com をサポートしています。セキュリティ、ガバナンス、開発者向けエージェント AI の深い専門知識を持ち、顧客が最先端のクラウド技術を活用して人々の生活を形作る製品を作成することを支援しています。革新的な AWS ソリューションを通じて複雑な課題を解決するチームの支援に情熱を注ぎ、Alex は最高水準のセキュリティとガバナンスを維持しながら顧客の成功を推進することに専念しています。仕事以外では、料理とハイキングを楽しんでいます。   GK は Senior Customer Solutions Manager で、AWS の顧客としての Amazon をサポートする戦略的顧客アドバイザーです。AWS での 4 年間で、開発者の生産性向上と AWS サービス全体での Amazon のニーズの擁護に焦点を当て、ユーザー体験を向上させ、2つの組織間のより深い連携を推進してきました。高度な Amazon チームとの彼女の仕事は、最終的に内部と外部の両方の AWS 顧客に利益をもたらすソリューションの提供を支援しています。GK は、GenAI が開発者と非開発者の間のギャップをどのように埋めているかにとくに関心があり、GenAI とセキュリティの課題解決に多くの時間を費やしています。彼女はサンフランシスコベイエリアを拠点とし、ハイキングとキャンプを楽しんでいます。   Aditi Joshi は Audible のソフトウェアエンジニアで、Amazon プラットフォーム全体での Audible の存在拡大に取り組んでいます。フルスタック開発者として、主に Web 技術、クラウドサービス、JavaScript と Java などのプログラミング言語を使用して、Amazon iOS アプリでの Audible 購入機能の導入などの最近のプロジェクトを含む、クロスプラットフォーム統合機能を構築・強化しています。ユーザーインターフェイス開発、レスポンシブデザイン、Web 技術の専門知識を持ち、Audible オファーの紹介と Amazon エコシステム全体での Audible の可視性向上に焦点を当てています。Aditi は、クリーンで効率的なコードでスケーラブルなシステムを構築することに焦点を当てたソフトウェアアーキテクチャとユーザー体験に情熱を注いでいます。コーディング以外では、旅行、ヨガ、音楽鑑賞を楽しんでいます。   Sam Park は Audible のソフトウェア開発エンジニアで、Amazon プラットフォーム全体での Audible 機能の構築に焦点を当てています。Amazon Cart を通じた Audible 購入の有効化、および Amazon iOS と Android アプリ内での Audible の可視性拡大において重要な役割を果たしてきました。彼の仕事は、検索、商品ページ、チェックアウト、カート体験を含む Amazon エコシステム内の複数のタッチポイントにわたっています。Sam は、直感的な顧客体験を創出するソリューションの開発と、開発効率と生産性を向上させるための GenAI の活用に情熱を注いでいます。仕事以外では、旅行、バスケットボール、クリーブランド・キャバリアーズの応援を楽しんでいます。

2025 年 9 月 30 日に AWS Startup Loft Tokyo (目黒) で開催された「 Amazon Q Developer Meetup #3 生成AIの利用を中心としたソフトウェア開発の新しいアプローチであるAI-DLCおよびその活用実績のご紹介 」のイベントの様子をレポートします。 このイベントは、生成 AI を中心としたソフトウェア開発に対する新たなアプローチである、 AI 駆動開発ライフサイクル (AI-DLC) をテーマに実施しました。まず Developer Specialist SA の金森から AI-DLC が必要とされる背景と、AI-DLC の概要、進め方をご紹介しました。続いて、すでに AI-DLC を体験していただいた LINE ヤフー株式会社様、株式会社サイバーエージェント様、東京海上日動システムズ株式会社様に、実際の進め方や学び、今後の展望などについて発表していただきました。 現地参加・オンライン参加合わせて 200 名以上の方にご登録いただきました。参加者の方からは「実際に AI-DLC を実施した結果としての良い点、課題点が聞けたことが良かったです。」とのご感想をいただきました。AI-DLC を始めて知った方、これから AI-DLC の実施を検討されている方、すでに AI-DLC を体験されて改善に取り組まれている方、それぞれの皆様にご参考いただける情報をお届けしました。 現地参加の方のみ、ケータリングをご用意し、ネットワーキングのための懇親会を実施しました。 登壇者の方への質問や、参加者同士の意見交換、AWS メンバーへの相談が活発におこなわれていました。 イベント概要 開催日時: 2025年9月30日 会場: AWS Startup Loft Tokyo (目黒)、オンライン配信 スピーカー LINE ヤフー株式会社様「AI-DLC を活用した、 負荷試験環境の構築」 株式会社サイバーエージェント様「CA 流、現場と伴走する AI 駆動開発 (AI-DLC)」 東京海上日動システムズ株式会社様「AI-DLC 体験記」 Developer Specialist SA 金森政雄, Amazon Web Services Japan G.K. 「AI 駆動開発ライフサイクル (AI-DLC) ソフトウェアエンジニアリングの再構築」 登壇資料: こちらからダウンロード (zip) AI 駆動開発ライフサイクル(AI-DLC)ソフトウェアエンジニアリングの再構築 スピーカー: Developer Specialist SA 金森政雄, Amazon Web Services Japan G.K. はじめに、Developer スペシャリストソリューションアーキテクトの金森より、AI-DLC をご紹介しました。 まず、ソフトウェア開発における生成 AI 利用に対する既存のアプローチの課題を挙げ、AI-DLC が必要とされる背景について述べました。続いて、開発プロセスを生成 AI が制御し、開発者が最終的な責任を保持するという AI-DLC のコンセプトを示し、AI-DLC を構成する各ステップの詳細についてご説明しました。そして AI-DLC を実践するためのアプローチであり、ご登壇いただいた各社様にご体験いただいた、AI-DLC Unicorn Gym についてケーススタディに基づいて仕組みや期待される成果についてご説明しました。 AI-DLC についてさらに詳しく知りたい方は、添付資料と併せてブログ「 AI 駆動開発ライフサイクル:ソフトウェアエンジニアリングの再構築 」をご覧ください。 LINEヤフー株式会社 様「AI-DLC を活用した、 負荷試験環境の構築」 LINE ヤフー株式会社様からは「AI-DLC を活用した、 負荷試験環境の構築」と題して、負荷試験環境の構築に AI-DLC を実践した事例についてご紹介いただきました。負荷試験ツールである Locust の設定や API、DB 初期化スクリプト等を AI-DLC を応用して作成した際の留意事項や実際の手順、工夫や今後の展望についてご説明いただきました。 一次情報は社員が普段から利用しているツールから MCP Server 経由で取得していることや、AI-DLC のアウトプットを新規担当者のキャッチアップ資料などに活用していること、AI-DLC を軽量にカスタマイズして取り入れていることをご紹介いただきました。AI エージェントとの対話内容の例や実際のアウトプットについてもご共有いただきました。これからの展望として、アウトプットであるドキュメントの更新・メンテナンスの仕組みについても検討されていることをご紹介いただきました。 株式会社サイバーエージェント様 「CA 流、現場と伴走する AI 駆動開発 (AI-DLC)」 株式会社サイバーエージェント様からは「CA 流、現場と伴走する AI 駆動開発」と題して、AI 駆動開発の全社展開を目指す背景とその実践についてお話しいただきました。AI 駆動開発の浸透・普及により AI 活用を強化し、競争力のあるプロダクトを作ることの重要性や、AI を前提とした開発文化の定着には全社への浸透、行動様式や意思決定プロセスの変革も必要である、と言う方針についてご紹介いただきました。既存プロジェクトへの AI-DLC の適用においてはドメイン知識に関するコンテキストの不足や、伝達の難しさについてお話しいただいたのち、Code を Single source of truth とすることや、ドメインごとに独立したコンテキストを与えるという AI へのドメイン知識の伝達方法をご説明いただきました。最後に、AI 活用の普及には継続的に開発チームとコミュニケーションし、二人三脚で進めていくことが重要であるとも述べていただきました。 AI-DLC Unicorn Gym 実施内容の詳細はブログ「 既存開発フローに AI-DLCを適用する 」と「 AWS 発「AI-DLC」ワークショップレポート！現場に適用するには？ 」も併せてご覧ください。 東京海上日動システムズ株式会社様 「AI-DLC 体験記」 東京海上日動システムズ株式会社様からは「AI-DLC 体験記」というタイトルで、AI-DLC ワークショップにご参加いただいた背景や準備、当日の様子や今後の展望についてご紹介いただきました。要件定義から実装フェーズの効率化の検証のため、既存システム改修と新規システム構築を対象とし、さまざまな部門・役割のメンバーが参加されたという背景をお話しいただきました。ワークショップ当日の成果物の例や完成したアプリケーションもご紹介いただきました。最後に各参加者からのフィードバックや、今後の AI-DLC を広く導入するための取り組みについてご説明いただきました。 AI-DLC Unicorn Gym 実施内容の詳細はブログ「 東京海上日動システムズ株式会社様の AWS 生成 AI 事例：金融業界初 AI-DLC Unicorn Gym による開発変革への挑戦 」も併せてご覧ください。 おわりに 今回の Amazon Q Developer Meetup #3 では、AI 駆動開発ライフサイクル (AI-DLC) をテーマとしてその概要と実際に体験されたお客様からの事例をご紹介いただきました。LINE ヤフー株式会社様、株式会社サイバーエージェント様、東京海上日動システムズ株式会社様にご登壇いただき、実施の背景や体験していただいた内容、学びや今後の展望についてお話しいただきました。今後も、開発者の皆様が生成 AI をより有効に活用していただくための AI-DLC をはじめとしたプラクティスや Amazon Q Developer や Kiro といったツールについて発信・アップデートをお届けします。 次回予告: Amazon Q Developer & Kiro Meetup #4 AWS サポートが語るよくある問い合わせ紹介とKiroのユースケース紹介 次回から Amazon Q Developer & Kiro Meetup にシリーズ名をアップデートします！ Amazon Q Developer & Kiro Meetup #4 では AWS サポートエンジニアから Amazon Q Developer に関するよくあるお問い合わせとその回答を、株式会社アド・ダイセン様から Kiro のユースケースをご紹介いただきます。皆様のご登録をお待ちしています。 参加登録: Amazon Q Developer Meetup & Kiro #4 AWS サポートが語るよくある問い合わせ紹介とKiroのユースケース紹介 開催日時: 2025年10月31日 (金) 19:00-21:00 会場: AWS Startup Loft Tokyo (目黒)、オンライン配信 お客様登壇 株式会社アド・ダイセン ソリューション部 部長 吉田 和弘 様「非エンジニアが生成AIでチームのイノベーション文化を創った実践事例」 yamazaki hiroki profile-20250806 山崎 宏紀 (Hiroki Yamazaki) 山崎宏紀 は Amazon Web Services Japan G.K. のソリューションアーキテクトとして、ISV/SaaS 業界のお客様を中心にアーキテクチャ設計や構築、生成 AI の活用をご支援しています。Amazon Q Developer や AWS CDK を好みます。(より良いご支援のために) AI エージェントに代わりに働いてもらおうと画策しています。

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊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 原文は こちら です。