TECH PLAY

AWS

AWS の技術ブログ

3122

生成AIの向かう先 2025年10月時点での生成AI活用はまず生産性の向上、つまり人間が行う業務の代わりをさらに効率化していくことに主眼が置かれています。しかしながら生成AIの価値はそれだけにとどまらず、今後は人間の置き換え以上のビジネス効果をもたらすことが期待されます。一般業務の改善の次に来るのは特定の業務や業界に特化したソリューションであると言われています。実際Gartner*は、2027年までに生成AI モデルの半数以上がドメイン固有(特定の産業または業務機能に特化)となると予測しています。これは2024年時点でのドメイン固有の割合1%と比べると飛躍的な伸び率と言えるでしょう。 参考: “2027年までに企業が利用する生成AI モデルの半数以上がドメイン固有(特定の産業または業務機能に特化)となり、 2024年の1%から大幅に増加する” *Gartner, Generative AI Models, Worldwide, 2023-2029, Q2’25 それぞれの業界課題と生成AIを使った解決例 それでは業界に特化した課題とどのように生成AIがそれらを解決できるのか、いくつかのユースケースを使って解説しましょう。 「金融業界向けAIソリューション」 金融業界では新たなビジネスモデルを模索する一方、厳格なコンプライアンス対応、レギュレーションの遵守が求められています。例えばコールセンターでの音声データのチェックは、経験のある専門家が音声を聞いてチェックしているケースが多くあります。もちろんすべての音声記録をチェックできればよいのですが現実的には困難でしょう。また大量の作業を行えば、チェックの品質の低下も懸念されます。このような作業に生成AIを活用することで、膨大な音声記録を一定の品質でチェックすることが可能になります。クレジットカードのレギュレーションチェックもとても手間がかかる一方、属人化している業務です。大手クレジットカード会社ですと年に2回の大きなレギュレーションの変更があり、そのドキュメントのページ数は1000ページになることもあります。また変更の内容によっては複数部署での対応が必要となり、その影響範囲と内容の注意点を説明する資料を作ることも大きな負担となっています。こういった課題を解決するために、生成AIを利用して大量の文書を分析し、変更内容や影響範囲をチャットでわかりやすく教えてくれる仕組みが考えられます。 「製造業界向けAIソリューション」 製造業では生産の自動化が進む一方、人材不足、技術継承が大きな課題となっています。例えば設備管理においては、人がそれぞれ設備を目視でチェック、紙の報告書に記載してあとからパソコンに入力するといったことが行われているケースはまだまだ多いでしょう。加えて何らかの異常を検知した際に正しい判断を、短い時間で行うことは経験者が持つ暗黙知のなせる技とも言えます。こういった属人化を解消するために、例えばアナログメータをAIカメラが読み取り定期的に記録、異常があれば通知する仕組みが考えられます。 また過去の記録から最適な対応策をAIがアドバイスする仕組み、手袋をしていてパソコン入力ができない作業者を補助する音声によるデータの記録、マニュアルの必要な部分を読み出して解説する機能などで、生産性の飛躍的な向上を目指します。 「エンターテイメント、レジャー業界向けAIソリューション」 エンターテイメント、レジャー業界で新たな収益の柱をもたらすことが期待されるのはパーソナライゼーションです。エンターテイメントの世界ではSNSを通じた顧客接点の拡大が重要になってきています。デバイスとしては多くの場合にスマートフォンになるわけですが、通常は横型で作成されている映像コンテンツを縦型にに編集するのは、実は容易ではありません。単純に映像を中央で切り取るとストーリー上重要な部分をカットしてしまうこともあり得るからです。このような作業はとても手間がかかりかつセンスが求められます。AIによるプロフェッショナルなテクニックを用いた編集で短時間に大量のコンテンツ変換ができれば、SNSへの情報発信もタイムリーにできるようになります。レジャー・トラベル業界でもパーソナライゼーションの導入が加速しています。多種多様なサービスを提供するトラベル体験のパーソナライゼーションは、それぞれのサービスごとのAIエージェントとスーパーバイサーエージェントが情報をやり取りすることで実現できます。 業界固有の知見を持つパートナーの価値 上記のような業界固有のソリューションの開発には、AI技術や実装方法の知識や経験だけではなく、それぞれの業界に高い知見をもつパートナーの存在が欠かせません。AWSには各業界に精通した様々なパートナーが多数存在し、専門知識とソリューションの活用、セキュリティとコンプライアンス、コスト最適化やイノベーションの加速をAWSと一緒にご支援させていただいています。 AWS パートナーは業界の規制や組織構造、プロセスを熟知しており、AI の活用の仕方やビジネス効果を出すためのプロセス等の適切なアドバイスをすることが可能です。実際に上述した業界特有の課題に対して様々な AWS パートナーが AI ソリューションを開発しています。「 AI の導入を考えているけどどこから手を付けてよいかわからない」、「ビジネスとして効果が出せるのか悩んでいる」、「AI 技術の進歩が早く、最適な AI 技術の選択に不安を感じている」といったような課題をお持ちの方にはぜひとも以下に紹介するイベントにご参加いただきたいと思います。 AWS Industry GenAI Innovation Dayイベント概要 生成AI(Generative AI)の実用フェーズが加速する中、先進企業はすでに具体的な成果を生み出しています。製造現場のスマート化、金融サービスの革新、レジャーやエンターテインメントの進化など、各業界で実践的なソリューションが次々と実現されています。 本イベントでは、業界をリードするAWS認定パートナーが、製造、金融など分野における活用事例と導入のポイントをご紹介します。 各パートナーによる最新ソリューションのプレゼンテーションに加え、特別企画として、AWSガイド付きのブースツアーを予定しております。少人数グループで効率的にすべてのソリューションをご体験いただけます。各ブースでは実機デモを交えながら、貴社特有の課題に対する解決策を専門家と直接ご相談いただける機会がございます。 また、ブース訪問された方には、AWSオリジナルグッズをご用意しております。 ビジネス革新に向けた確かな一歩を踏み出すための、実践的な機会です。 皆様のご参加を心よりお待ちしております。 ※より充実したディスカッションの場とするため、定員を120名とさせていただいております。 定員に達し次第、申し込みを締め切らせていただきます。 日時:2025 年 11 月 4 日(火)14:00–17:30(13:30 受付開始) 場所:AWS 目黒オフィス 目黒セントラルスクエア 21 階(東京都品川区上大崎 3-1-1) 主催:アマゾン ウェブ サービス ジャパン合同会社 参加費:無料(要事前申込) 参加申込: こちらのお申込みフォーム からお申込みください。 展示テーマ 「金融業界向けAIソリューション」 金融業界では新たなビジネスモデルを模索する一方、厳格なコンプライアンス対応、レギュレーションの遵守が求められています。本イベントではコールセンター等の音声データ分析による金融規制対応の自動化、決済カードレギュレーションチェックプロセス業務効率化、脱属人化を実現するAIソリューションを紹介します。 「製造業界向けAIソリューション」 製造業では生産の自動化が進む一方、人材不足、技術継承が大きな課題となっています。より少ない人数で質の高い設備管理が行えるような、AIカメラソリューション、設備管理の自動化、作業実績の自動記録からマニュアルの音声での呼び出しまで、製造・プラントの現場で役に立つソリューションをご紹介します。 「エンターテイメント、レジャー業界向けAIソリューション」 エンターテイメント、レジャー業界で新たな収益の柱としてより適切なパーソナライゼーションが期待されています。顧客接点の可能性を広げるSNS向け動画自動編集、個人に最適化された旅行体験を提供する最新のAIサービスをご紹介します。 来場者特典 事前お申込みのうえ当日ブースツアーで5箇所以上にご参加いただきましたお客様へ 先着 100 名限定 で、イベント特製の持ち運び可能コンパクトPCスタンドをプレゼントいたします! ※ 画像はイメージです。実物と異なる場合がございます。 当日はソリューションプロバイダー各社の展示ブースで製品デモをご覧いただけるほか、各社と個別にご相談できる機会も提供いたします。 こちらのお申込みフォーム からお申込みください。 皆様のご参加を楽しみにお待ちしております!
Amazon Redshift は、標準 SQL と既存のビジネスインテリジェンス(BI)ツールを使用してデータを簡単かつ費用対効果高く分析できる、高速でペタバイト規模のクラウドデータウェアハウスです。何万もの顧客が Amazon Redshift を利用してエクサバイト規模のデータを分析し、複雑な分析クエリを実行して、最高のコストパフォーマンスを実現しています。 完全マネージド型の AI 駆動による Massively Parallel Processing(MPP)アーキテクチャを備えた Amazon Redshift は、迅速かつコスト効率的にビジネス意思決定を推進します。以前、Amazon Redshift はコンピュート集約型ワークロードに最適化された DC2(Dense Compute)ノードタイプを提供していました。しかし、これらはコンピュートとストレージを独立してスケーリングする柔軟性に欠け、現在利用可能な多くの最新機能をサポートしていませんでした。分析需要の増大に伴い、多くのお客様が DC2 から RA3 または Amazon Redshift Serverless へアップグレードしています。これらは独立したコンピュートとストレージのスケーリングを提供し、 データ共有 、 ゼロ ETL 統合 、 Amazon Redshift ML による組み込みの人工知能および機械学習(AI/ML)サポートなどの高度な機能を備えています。 この記事では、ターゲットアーキテクチャと移行戦略を計画するための実践的なガイドを提供し、アップグレードオプション、主要な考慮事項、および成功したシームレスな移行を促進するためのベストプラクティスをカバーしています。 DC2 ノードから RA3 および Redshift Serverless へのアップグレードプロセス アップグレードへの第一歩は、新しいアーキテクチャをどのようにサイジングすべきかを理解することです。このために、AWS はプロビジョニングされたクラスター用の 推奨表 を提供しています。Redshift Serverless エンドポイントの構成を決定する際は、RPU とメモリの関係を調べることで、コンピューティング容量の詳細を評価できます。各 RPU は 16 GiB の RAM を割り当てます。ベース RPU 要件を見積もるには、DC2 ノードクラスターの合計 RAM を 16 で割ります。これらの推奨事項は、初期ターゲットアーキテクチャのサイジングに関するガイダンスを提供しますが、ワークロードのコンピューティング要件に依存します。要件をより適切に見積もるには、 Redshift Test Drive を使用して潜在的な構成を実行する概念実証の実施を検討してください。詳細については、「 Redshift Test Drive を使用してワークロードに最適な Amazon Redshift 構成を見つける 」および「 Amazon Redshift で概念実証を実施する 」を参照してください。ターゲット構成とアーキテクチャを決定した後、アップグレード戦略を構築できます。 アーキテクチャパターン 最初のステップは、ソリューションのターゲットアーキテクチャを定義することです。「 Amazon Redshift のパフォーマンスを大規模に最適化するためのアーキテクチャパターン 」で提示されているオプションから、ユースケースに最も適合するメインのアーキテクチャパターンを選択できます。次の図に示すように、主に2つのシナリオがあります。 執筆時点では、Redshift Serverless には手動のワークロード管理機能がなく、すべてが自動ワークロード管理で実行されます。独立したスケーリングとより良いパフォーマンスを実現するために、ユースケースに基づいてワークロードを複数のエンドポイントへ分離することを検討してください。詳細については、「Amazon Redshiftのパフォーマンスを大規模に最適化するためのアーキテクチャパターン」を参照してください。 アップグレード戦略 DC2 ノードから RA3 ノードまたは Redshift Serverless へのアップグレード時には、2つのアップグレードオプションから選択できます: リアーキテクチャ : 最初のステップでは、ワークロードを評価してモダンなデータアーキテクチャの導入効果があるかを判断します。次に、DC2 ノードからのアップグレードと同時に、既存プラットフォームのリアーキテクチャを実施します。 段階的アプローチ : これは2段階の戦略です。第1段階では、ターゲットの RA3 または Serverless 構成への単純な移行を行います。第2段階では、最先端の Redshift 機能を活用してターゲットアーキテクチャをモダナイズできます。 通常、段階的なアプローチを推奨しています。これにより、将来の最適化を可能にしながら、よりスムーズな移行が実現できます。段階的アプローチの第1段階は、以下のステップで構成されています: 既存の DC2 クラスターに相当する RA3 ノードまたは Redshift Serverless の構成を評価します。プロビジョニングされたクラスターの サイジングガイドライン またはサーバーレスエンドポイントの コンピューティング容量オプション を使用します。 Redshift Test Drive を使用して、非本番環境で選択したターゲット構成を検証します。この自動化ツールにより、本番ワークロードのシミュレーションプロセスが簡素化されます。さまざまな潜在的なターゲット構成で包括的な what-if 分析を実行できます。 特定のターゲット構成の価格対性能比に満足できたら、次のセクションで詳述する方法のいずれかを使用してアップグレードプロセスに進みます。 Redshift RA3 インスタンスと Redshift Serverless は、ゼロ ETL、 Amazon Redshift Streaming Ingestion 、 データ共有を使用したマルチウェアハウス書き込み 、独立したコンピュートとストレージのスケーリングなど、強力な新機能へのアクセスを提供します。これらのメリットを最大限に活用するために、現在のアーキテクチャの包括的なレビュー(段階的アプローチの第2段階)を実施し、Amazon Redshiftの最新機能を使用したモダナイゼーションの機会を特定することをお勧めします。例えば: データ共有を使用したマルチウェアハウスアーキテクチャ を実装し、ワークロードを分離してパフォーマンスを向上させる 現在、トランザクショナルソースから Amazon Redshift へのデータ転送に AWS Database Migration Service (AWS DMS)を使用している場合は、ゼロ ETLを実装して運用を効率化し、メンテナンスのオーバーヘッドを削減する アップグレードオプション DC2 から RA3 または Redshift Serverless へのクラスターのリサイズまたはアップグレードには、 スナップショットの復元 、 Classic resize 、 Elastic resize の3つの方法から選択できます。 スナップショットの復元 スナップショット復元方式は、既存の(ソース)クラスターのスナップショットを取得することから始まる順次的なプロセスに従います。このスナップショットは、希望する性能で新しいターゲットクラスターを作成するために使用されます。作成後、データがターゲットクラスターに正しく転送されたことを確認して、データの整合性を検証することが不可欠です。重要な考慮事項として、最初のスナップショット後にソースクラスターに書き込まれたデータは、同期を維持するために手動で転送する必要があります。 この方式には以下の利点があります: 既存の DC2 クラスターに影響を与えることなく、新しい RA3 または Serverless セットアップの検証が可能 異なる AWS リージョンまたはアベイラビリティーゾーンへの復元の柔軟性を提供 移行中の書き込み操作に対するクラスターのダウンタイムを最小限に抑える ただし、以下の考慮事項に留意してください: セットアップとデータの復元は、Elastic resize よりも時間がかかる場合があります。 スナップショット作成後にソースクラスターに書き込まれた新しいデータは、ターゲットへの手動コピーが必要になるため、データ同期の課題に直面する可能性があります。このプロセスは完全な同期を達成するために複数回の反復が必要になる場合があり、カットオフ前にダウンタイムが必要になることがあります。 新しい Redshift エンドポイントが生成されるため、接続の更新が必要になります。元のエンドポイントを維持するため、 両方のクラスターの名前変更 を検討してください(新しいターゲットクラスターが元のソースクラスターの名前を採用するようにしてください)。 Classic resize Amazon Redshift はターゲットクラスターを作成し、バックアップおよび復元を使用してソースクラスターからデータとメタデータを移行します。データベーススキーマやユーザー設定を含むすべてのデータは、新しいクラスターに正確に転送されます。ソースクラスターは最初に再起動し、数分間使用できなくなるため、ダウンタイムは最小限に抑えることができます。すぐに再開され、バックグラウンドでリサイズが継続される間、読み取りと書き込みの両方の操作が可能になります。 Classic resize は2段階のプロセスです: ステージ1(クリティカルパス): このステージでは、ソースとターゲットの構成間でメタデータの移行が行われ、ソースクラスターが一時的に読み取り専用モードになります。この初期フェーズは通常、短時間で完了します。このフェーズが完了すると、クラスターは読み取りおよび書き込みクエリで使用可能になります。KEY 分散スタイルで最初に構成されたテーブルは一時的に EVEN 分散を使用して保存されますが、プロセスのステージ2でオリジナルの KEY 分散に再分散されます。 ステージ2(バックグラウンド操作):このステージは、データを元の分散パターンに復元することに焦点を当てています。この操作は、主要な移行プロセスに影響を与えることなく、低優先度でバックグラウンドで実行されます。このステージの期間は、再分散されるデータ量、進行中のクラスターワークロード、使用されているターゲット構成など、複数の要因によって異なります。 全体的なリサイズ期間は、主に処理されるデータ量によって決まります。Amazon Redshift コンソールで進行状況を監視するか、変換中のテーブルの完了率を表示する SYS_RESTORE_STATE システムビューを使用して監視できます(このビューへのアクセスにはスーパーユーザー権限が必要です)。 Classic resize アプローチには、以下の利点があります: すべての可能なターゲットノード構成がサポートされています ソースクラスターの包括的な再構成により、データスライスがノードごとのデフォルトに再バランスされ、ノード間でデータが均等に分散されます ただし、以下の点に留意してください: ステージ2 では、最適なパフォーマンスのためにデータを再分散します。しかし、ステージ2 は低い優先度で実行され、ビジーなクラスターでは完了までに長時間かかることがあります。プロセスを高速化するには、KEY DISTSTYLE を持つテーブルに対して ALTER TABLE DISTSTYLE コマンドを手動で実行できます。このコマンドを実行することで、データの再配布を優先的に実行でき、進行中のステージ2 プロセスによる潜在的なパフォーマンス低下を軽減できます。 ステージ2 のバックグラウンド再分散プロセスのため、 リサイズ操作 中はクエリの完了に時間がかかることがあります。軽減策として同時実行スケーリングの有効化を検討してください。 データ分散を高速化するため、リサイズを開始する前に不要で使用されていないテーブルを削除してください。 リサイズ操作に使用されるスナップショットは、この操作専用になります。そのため、テーブルの復元やその他の目的には使用できません。 クラスターは仮想プライベートクラウド(VPC)内で動作する必要があります。 このアプローチでは、Classic resize を開始する前に取得した新しいまたは最近の手動スナップショットが必要です。 ビジネスへの影響を最小限に抑えるため、オフピーク時間またはメンテナンスウィンドウ中に操作をスケジュールすることをお勧めします。 Elastic resize Elastic resize を使用してノードタイプを変更する場合、Amazon Redshift は順次プロセスに従います。まず既存のクラスターのスナップショットを作成し、そのスナップショットの最新データを使用して新しいターゲットクラスターをプロビジョニングします。バックグラウンドでデータが新しいクラスターに転送される間、システムは読み取り専用モードのままです。リサイズ操作が完了に近づくと、Amazon Redshift は自動的にエンドポイントを新しいクラスターにリダイレクトし、元のクラスターへのすべての接続を停止します。このプロセス中に問題が発生した場合、システムは通常、手動介入を必要とせずに自動ロールバックを実行しますが、そのような障害は稀です。 Elastic resize にはいくつかの利点があります: 平均 10 ~ 15 分で完了する迅速なプロセスです ユーザーはプロセス中もデータへの読み取りアクセスを維持でき、中断は最小限に抑えられます クラスターエンドポイントは操作中および操作後も変更されません このアプローチを検討する際は、以下の点に留意してください: Elastic resize 操作は、 EC2-VPC プラットフォーム を使用するクラスターでのみ実行できます。そのため、Redshift Serverless では利用できません。 ターゲットノード構成は、既存のデータに対して十分なストレージ容量を提供する必要があります。 すべてのターゲットクラスター構成が Elastic resize をサポートしているわけではありません。そのような場合は、Classic resize またはスナップショット復元を検討してください。 プロセスが開始された後、Elastic resize を停止することはできません。 データスライスは変更されません。これにより、データまたは CPU の偏りが発生する可能性があります。 アップグレード推奨事項 次のフローチャートは、適切な Amazon Redshift アップグレード方法を選択するための意思決定プロセスを視覚的にガイドします。 Amazon Redshift をアップグレードする際、その方法はターゲット構成と運用上の制約によって異なります。Redshift Serverless の場合は、常にスナップショット復元方式を使用します。RA3 プロビジョニングクラスターにアップグレードする場合は、2つのオプションから選択できます。ダウンタイムを伴う完全なメンテナンスウィンドウが許容できる場合はスナップショット復元を使用し、ダウンタイムを最小限に抑えたい場合は Classic resize を選択します。Classic resize は、データスライスをノードごとのデフォルトにリバランスし、ノード間でデータを均等に分散させるためです。特定の範囲内での特定のノードタイプの変更(例:DC2 から RA3)には Elastic resize を使用できますが、Elastic resize はスライス数を変更しないため、データや CPU の偏りが生じる可能性があり、後で Redshift クラスターのパフォーマンスに影響を与える可能性があるため、推奨されません。ただし、既存のクラスターでノードを追加または削減する必要がある場合は、Elastic resize が引き続き主要な推奨事項となります。 移行のベストプラクティス 移行を計画する際は、以下のベストプラクティスを検討してください: Amazon Redshift Advisor または Amazon CloudWatch を使用して、移行前の評価を実施する。 ユースケースとワークロードに基づいて、適切なターゲットアーキテクチャを選択する。Redshift Test Drive を使用して、適切なターゲットアーキテクチャを決定する。 手動スナップショットを使用してバックアップを作成し、自動ロールバックを有効にする。 ステークホルダーにタイムライン、ダウンタイム、変更内容を伝える。 新しいアーキテクチャの詳細とエンドポイントでランブックを更新する。 ベンチマークとデータチェックサムを使用してワークロードを検証する。 最終同期と切り替えにはメンテナンスウィンドウを使用する。 これらのプラクティスに従うことで、パフォーマンス、コスト、運用の継続性のバランスを取りながら、低リスクな移行を実現できます。 結論 Redshift DC2 ノードから RA3 ノードまたは Redshift Serverless への移行には、パフォーマンス、コスト効率、および最小限の中断をサポートするための構造化されたアプローチが必要です。ワークロードに適したアーキテクチャを選択し、移行後のデータとワークロードを検証することで、組織はデータプラットフォームをシームレスに最新化できます。このアップグレードにより長期的な成功が促進され、チームは RA3 のスケーラブルストレージまたは Redshift Serverless の自動スケーリング機能を最大限に活用しながら、コストとパフォーマンスを最適化できるようになります。 著者について Ziad Wali は、AWS のアナリティクススペシャリストソリューションアーキテクトです。データベースとデータウェアハウジングにおいて10年以上の経験を持ち、信頼性が高く、スケーラブルで効率的なソリューションの構築を得意としています。仕事以外では、スポーツや自然の中で過ごすことを楽しんでいます。 Omama Khurshid は、Amazon Web Services のアナリティクスソリューションアーキテクトです。彼女は、さまざまな業界のお客様が信頼性、拡張性、効率性に優れたソリューションを構築できるよう支援することに注力しています。仕事以外では、家族との時間を過ごしたり、映画鑑賞、音楽鑑賞、新しい技術の学習を楽しんでいます。 Srikant Das は、Amazon Web Services のアナリティクス スペシャリスト ソリューションアーキテクトとして、アナリティクスと AI においてスケーラブルで堅牢なクラウドソリューションを設計しています。技術的な専門知識に加えて、魅力的なブログを通じて旅行の冒険やデータインサイトを共有し、ソーシャルメディア上で分析的な厳密さとストーリーテリングを融合させています。 翻訳は、ソリューションアーキテクトの駒野が担当しました。原文は こちら です。
本ブログは 株式会社クリエイティブ・ウェブ様 と アマゾン ウェブ サービス ジャパン合同会社 が共同で執筆いたしました。 みなさん、こんにちは。AWS ソリューションアーキテクトの齋藤です。 最近、多くのお客様から「コールセンター業務の効率化」や「問い合わせ対応の品質向上」についてのご相談をいただく機会が増えています。特に、生成 AI を活用した業務改善への関心が高まっており、実際の導入事例を求める声を多く耳にします。 その一方で、「生成 AI をコールセンター業務にどう活用すればいいのかわからない」「過去のナレッジをうまく活用できていない」といった課題をお持ちの方も多いのではないでしょうか? 今回ご紹介する事例は、株式会社クリエイティブ・ウェブ様が Amazon Bedrock をはじめとしたマネージドサービスを活用して開発された、コールセンターお問い合わせ管理システムです。RAG (Retrieval-Augmented Generation) 技術を用いることで、過去の対応履歴を活用した対応サジェスト機能を実現し、問い合わせ対応の効率化と品質向上を同時に達成された事例となります。 お客様の状況と課題 株式会社クリエイティブ・ウェブ様は、システム・PC サポート・Web サイト・EC 関連の問い合わせ対応サービスを提供しており、日々多様な問い合わせに対応されています。 従来のコールセンター業務では、以下のような課題を抱えていらっしゃいました: 業務効率面での課題 手作業による情報管理: 問い合わせ内容や対応方法の記録・管理が属人的で、情報の一元化ができていない 対応品質のばらつき: 担当者によって対応方法が異なり、サービス品質に差が生じている ナレッジ活用の困難: 過去の対応事例が蓄積されているものの、類似ケースを検索・参照するのに時間がかかる 業務管理面での課題 進捗状況の把握困難: 受電から完了までのステータス管理が不十分で、対応漏れや遅延が発生するリスク 引き継ぎ作業の非効率: 担当者が変わる際の情報共有に時間がかかる 対応データの活用不足: 蓄積された対応履歴を分析して改善に活かせていない ソリューション・構成内容 これらの課題を解決するため、株式会社クリエイティブ・ウェブ様は AWS の生成 AI サービスを活用して「コールトラック」システムを開発されました。 システムアーキテクチャ システムは AWS のマネージドサービスを中心としたサーバーレス構成で設計されています: Amazon Bedrock: RAG 機能による過去対応履歴の検索 Amazon OpenSearch Service: 過去の対応履歴データの検索・インデックス化 AWS Lambda: 各種処理の実行基盤 Amazon Relational Database Service (Amazon RDS): 問い合わせ情報と対応履歴の管理 Amazon Simple Storage Service (Amazon S3): 対応関連ドキュメントの保存 Amazon API Gateway: フロントエンドとバックエンドの連携 主要機能 1. 問い合わせ情報管理機能 受電、保留、対応中、完了といったステータス管理 担当者、顧客情報、問い合わせ内容、対応方法の詳細記録 リアルタイムでの進捗状況可視化 2. RAG による過去対応履歴の検索 Amazon Bedrock の基盤モデルを活用し、過去の対応事例から最適な対応方法をサジェスト Amazon OpenSearch Service による高速な類似事例検索 文脈を理解した自然な日本語での回答生成 3. 自動要約機能 問い合わせ内容を箇条書きで入力すると、AI が自動的に要約 対応記録の標準化と効率化を実現 4. ナレッジの自動蓄積・学習機能 全ての対応履歴を自動でデータ化 定期的な RAG への取り込みによる継続的な学習 蓄積されたナレッジの品質向上 実際の画面 オペレーターが受電・架電時に使用するメイン画面です。対応者の状況 (対応可能・対応中・離席中) が一目でわかり、ワンクリックでステータスを変更できるため、スムーズな電話対応業務をサポートします。 「言った言わない」の確認や、対応内容の振り返りが簡単に行えます。通話音声の再生に加え、文字起こしデータと AI の要約が確認できます。さらに、電話対応を自動評価するため、教育にも利用可能です。 質の高い対応履歴は、AI の精度向上に不可欠です。この機能は、履歴の内容を AI が評価し、「より良いナレッジ」となるように文章を自動で校正。手間をかけずにナレッジの品質を維持できます。 対応履歴の作成時間を大幅に短縮します。箇条書きで入力したキーワードやメモを元に、AI が状況説明から対応内容までを瞬時に文章化。対応者は、文章作成の負担から解放されます。 日々の頑張りが「見える化」され、モチベーションアップに繋がります。受電数や対応件数などの成果がポイントとして貯まり、そのポイントでバーチャルペットを育てて楽しむことができます。 全体の業務状況をダッシュボードで可視化します。月・日・時間別の対応件数、カテゴリ別の割合など多角的に分析し、データに基づいた最適な人員配置や育成計画を支援します。 導入効果 お問い合わせ管理システムの導入により、以下の大きな効果を実現されました: 1. 対応効率の大幅向上 初回解決率の向上: RAG による過去対応履歴の検索により、一回目の対応で解決するケースが約 30% 増加 対応時間の短縮: 平均対応時間を従来比で約 40% 削減 情報検索時間の短縮: 過去事例の検索時間を従来の 5 分から 1 分以下に短縮 2. サービス品質の標準化 対応品質の均質化: 全担当者が同等レベルの対応サジェストにアクセスできるため、サービス品質が標準化 新人教育期間の短縮: 蓄積されたナレッジを活用することで、新人でも早期に高品質な対応が可能 3. データ活用による継続改善 対応パフォーマンスの可視化: 対応件数、時間、解決率などの KPI を自動集計・分析 改善点の特定: データ分析により、頻出する問い合わせパターンや対応改善点を特定 ナレッジの品質向上: 継続的な学習により、サジェストの精度が徐々に向上 4. コスト削減効果 人件費の最適化: 対応効率向上により、同じ人員でより多くの問い合わせに対応可能 教育コストの削減: 標準化されたナレッジにより、新人教育にかかる時間とコストを削減 技術的なポイント RAG の実装における工夫 株式会社クリエイティブ・ウェブ様では、RAG システムの精度向上のために以下の工夫を実装されました: 多層的な検索戦略: キーワード検索とセマンティック検索を組み合わせた高精度な類似事例抽出 文脈理解の強化: 問い合わせの背景情報も含めて分析し、より適切なサジェストを生成 フィードバックループ: 実際の対応結果をフィードバックとして活用し、継続的にモデルの精度を向上 コスト最適化の取り組み 適切なモデル選択: 問い合わせの複雑さに応じて、Amazon Nova、Claude 3 Sonnet と Haiku などを使い分け サーバーレス構成: 必要な時だけリソースを使用するため、運用コストを最小化 段階的なスケーリング: 問い合わせ量に応じた自動スケーリングにより、効率的なリソース利用を実現 今後の展望 株式会社クリエイティブ・ウェブ様では、お問い合わせ管理システムのさらなる発展を計画されています: 短期的な改善計画 音声認識機能の追加: 電話内容の自動文字起こしによる記録作業の完全自動化 多言語対応: グローバル展開を見据えた多言語サポート機能 リアルタイム分析: 対応中のリアルタイムサジェストとエスカレーション判定 長期的なビジョン 予測分析機能: 問い合わせ内容から将来のトラブルを予測し、事前対応を可能にする機能 顧客感情分析: 音声や文章から顧客の感情を分析し、適切な対応トーンを提案 業界特化型展開: 特定業界のナレッジベースを構築し、より専門的な対応を支援 お客様の声(株式会社クリエイティブ・ウェブ様) Amazon Bedrock を活用した RAG システムの導入により、これまで活用しきれていなかった過去の対応履歴が貴重な資産として生まれ変わりました。新人スタッフでもベテランと同等の対応品質を提供できるようになり、お客様満足度の向上と業務効率化を同時に実現できています。 AWS のマネージドサービスを活用することで、インフラ運用の負担を最小限に抑えながら、高度な AI 機能を短期間で実装することができました。特に Amazon Bedrock の多様なモデル選択肢により、コストと性能のバランスを最適化できた点が大きなメリットでした。 今後は、このシステムをベースにさらなる機能拡張を計画しており、コールセンター業務の完全自動化に向けて取り組んでいきます。 まとめ 今回は、Amazon Bedrock を活用した RAG システムにより、コールセンター業務の効率化と品質向上を同時に実現された株式会社クリエイティブ・ウェブ様の事例をご紹介しました。 特に注目すべきは、単なる AI ツールの導入ではなく、業務プロセス全体を見直し、データ駆動型の改善サイクルを構築された点です。これにより、継続的にサービス品質が向上する仕組みを実現されています。 同様の課題をお持ちのお客様、特に「コールセンター業務の効率化を図りたい」「過去のナレッジを有効活用したい」「問い合わせ対応の品質を標準化したい」といったニーズをお持ちの方には、非常に参考になる事例だと思います。 また、AWS では、生成 AI を活用したソリューション開発を支援するさまざまなイベントやプログラムを定期的に開催しております。技術セッションやハンズオンを通じて実際に技術に触れることができますので、ぜひご参加ください。 https://aws.amazon.com/jp/events/ ご関心のあるお客様は、ぜひ AWS までお問い合わせください。 株式会社クリエイティブ・ウェブ : 片桐 翼様 (左)、大皿 綾馬様 (中央)、藤井 龍生様 (右) 著者について 齋藤 拓巳 ソリューションアーキテクトとして幅広いお客様の AWS 導入支援を担当しています。AWS Lambda や Amaozn API Gateway などのサーバレスのサービスが好きです。
本稿は、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 情報システム様、キヤノンITソリューションズ様、ソニーグループ様、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 原文は こちら です。