本ブログは アサイクル株式会社様 と Amazon Web Services Japan 合同会社 が共同で執筆いたしました。 みなさん、こんにちは。ソリューションアーキテクトの森です。 展示会やオンラインイベントなどの営業活動においては、顧客との重要な会話を正確に記録し、後続のフォローアップに活かすことが重要です。しかし、従来の手動による記録作業は営業担当者にとって大きな負担となっており、本来の営業活動に集中できないという課題がありました。今回は薬局 DX をリードする企業として「 ASKAN 」「 PICKING GO 」「 ZERO STOCK 」といったソリューションを提供されているアサイクル株式会社様が、音声会話要約ソリューションを短期間で開発した事例を紹介します。 お客様の状況と検証に至る経緯 アサイクル株式会社様は、薬局 DX を推進するシステムを提供する企業として、展示会やオンラインデモでの営業活動を積極的に展開しておりましたが、以下のような課題を抱えておりました。 会話内容を CRM にテキストで手入力する作業は時間を要し、担当者によって情報の質や量にばらつきが発生していた。 貴重な商談時間がメモ取りで中断してしまい、顧客との対話に集中できない状況があった。 既存の文字起こしサービスでは、調剤薬局を取り巻く業界特有の専門用語の認識精度が低く、商談後の情報整理に支障をきたしていた。（例：「アスカン」→「明日感」、「ピッキングゴー」→「ピッキング語」） そこで AWS のマネージドサービスを活用し、業界特化型の音声文字起こしシステムを構築することで、これらの課題を解決するソリューションの検証をすることになりました。 ソリューションと構成 本ソリューションは、展示会やオンラインデモで録音した音声ファイルを基に、Amazon Bedrock を活用した高精度な構造化テキスト出力を実現しています。 Amazon Bedrock を活用した構造化テキスト出力: LLM のプロンプト制御により専門用語を補正し、会話内容の要約・重要キーワード抽出・次のアクション提案などを CRM に最適な形式で自動生成 Amazon ECS (AWS Fargate) を活用したコンテナベースの音声処理: サーバーレスコンテナ環境で高度な音声処理機能を実装 AWS ネットワークを活用したセキュアな環境での構築: 機密性の高い顧客との会話内容を外部に漏らすリスクを排除したセキュアな処理環境を提供 このソリューションにより、音声ファイルをアップロードするだけで、営業活動の効率化と品質向上を同時に実現できる仕組みを構築しました。   AI コーディングエージェントを活用した短期間開発 アサイクル株式会社様は AWS 主催のハッカソンイベント「DEVCRAFT」で本プロジェクトに取り組まれました。本プロジェクトの特筆すべき点は、AI コーディングエージェントを活用した AI 駆動開発により、従来であれば数週間から数ヶ月を要するようなシステム開発を、ハッカソンイベントの約２週間という短期間で実用レベルまで構築された点にあります。 要件定義から実装まで一貫した開発：ビジネス要件を技術仕様に落とし込み、生成 AI の支援により実装まで効率的に実施 AWS サービスとの統合コードの自動生成：各 AWS サービスとの連携に必要となるコードの自動生成 コンテナ化された処理基盤の構築：音声処理機能をコンテナ環境で効率的に実装 定型的なコード記述や API 連携部分を生成 AI に任せることで、エンジニアはより創造的で付加価値の高い、業界特化の音声認識ロジックやプロンプト設計といった本質的な価値創出に集中することができました。この結果、ハッカソンイベント期間中に実用的な機能を持つシステムを完成させ、従来の開発手法では実現困難な短納期開発を成功させることができました。 お客様の声（アサイクル株式会社様） DEVCRAFT では、AI コーディングエージェントを活用することで、短期間でのプロトタイプ開発が実現できました。イベント期間中に要件定義から実装まで一貫して取り組み、実用的な機能を持つシステムを完成させることができました。この成功は、AWS のマネージドサービスの使いやすさと、AI コーディングエージェントによる開発効率化の相乗効果によるものです。インフラ構築の負担を軽減してビジネスロジックの開発に集中できたことが、短期間での成果創出につながりました。 まとめ 本事例は、営業活動における音声データ活用の好例です。今回作成した音声会話要約ソリューションにより、展示会やオンラインデモでの記録作業を自動化し、営業担当者が顧客との対話に集中できる環境を構築されました。特に注目すべきは、AI コーディングエージェントを活用することで、短期間のハッカソンイベントにおいて実用的なソリューションを構築できた点です。本事例が、営業活動の効率化や音声データ活用をご検討中のお客様の参考になれば幸いです。AWS による音声データ活用、生成 AI 活用、AI コーディングエージェントを用いた高速開発にご興味をお持ちの方は、お気軽にご相談ください。 アサイクル株式会社（左から）： 打越 隆志 様、代表取締役社長 浅井 亨介 様、谷川 祐一 様、銭谷 武 様、佐竹 智樹 様 Amazon Web Services Japan : アカウントマネージャー 植木 輝（左端） ソリューションアーキテクト 森 瞭輔（右端） ソリューションアーキテクト 森

データベース監視は、堅牢で信頼性の高いアプリケーションを維持するための重要な側面です。 Amazon RDS for SQL Server インスタンスの効果的な監視により、チームは最適なデータベースパフォーマンスを維持し、シームレスな運用を確保できます。モダンな監視ソリューションは、データベース管理者、開発者、運用チームがデータベース環境を管理する方法を革新し、プロアクティブな問題検出と迅速な対応機能を可能にしています。これらの進歩は、システムの信頼性向上、メンテナンスワークフローの合理化、複数のデータベースインスタンス全体でのリソース使用率の最適化という魅力的な機会を提供します。これまでチームは手動でのログチェックや断片化された監視ツールという課題に直面してきましたが、今日の自動化されたリアルタイム通知システムは、応答時間を大幅に短縮し、システムダウンタイムを最小限に抑える革新的なデータベース管理アプローチを提供します。 この投稿では、AWS ネイティブサービスと Slack 統合を使用して、Amazon RDS for SQL Server の効率的なサーバーレス監視システムを構築する方法を示します。 ソリューション概要 このソリューションは、Amazon RDS for SQL Server、 Amazon CloudWatch 、 AWS Lambda 、および Slack サービスを統合することで、データベース監視に対する効率的でサーバーレスなアプローチを提示します。これらの AWS サービスと Slack のコミュニケーションプラットフォームを使用することで、データベースの問題についてチームに自動的にアラートを送信する合理化された通知システムを構築します。このアーキテクチャは手動監視の必要性を排除し、データベースの健全性に対するリアルタイムの可視性を提供します。 処理するには、エラーが検出されたときに自動的にトリガーされる Lambda 関数を実装します。Lambda 関数は、ログデータをデコードして読みやすいメッセージにフォーマットするために必要な権限と依存関係で構成されています。これらのメッセージは最初に Amazon DynamoDB テーブルに保存され、その後セキュアな Webhook 統合を通じて指定された Slack チャンネルに配信され、データベース管理者とサポートチームへの即座の通知を可能にします。 このサーバーレスアーキテクチャは、潜在的な問題の迅速な通知をしながら、最小限のメンテナンスでリアルタイムデータベース監視を行うコスト効率に優れたスケーラブルなソリューションを提供します。エラーの発生から Slack 通知までの全プロセスは通常数秒以内に完了し、データベース問題への迅速な対応とシステム信頼性の向上を可能にします。 以下の図は、ソリューションのアーキテクチャを示しています。 DynamoDB のアイテムは 48 時間後 (設定可能) に自動的に削除されます。これにより、ストレージ料金を削減してコストを最適化し、テーブルを軽量に保つことでクエリパフォーマンスを向上させ、古いデータの自動クリーンアップによってより良いデータ管理を提供します。また、同じエラーメッセージが 15 分間 (設定可能) のウィンドウ内で複数回発生した場合、最初のインスタンスのみが Slack に送信されます。これにより通知スパムを防ぎ、運用の明確性を維持するのに役立ちます。 通知プロセスは、Amazon RDS for SQL Server がエラーログを生成し、 CloudWatch ロググループ に公開した時点で開始されます。新しいログが到着すると、 CloudWatch サブスクリプションフィルター がこれらのエントリを継続的に監視し、事前定義されたエラーパターンと照合します。一致するエラーパターンが検出されると、フィルターは自動的に Lambda 関数をトリガーします。Lambda 関数は、まず CloudWatch からデータをデコードして解凍しログエントリを処理します。タイムスタンプ、ロググループの詳細、実際のエラーメッセージなどの重要な情報を抽出し、DynamoDB に保存します。処理後、Lambda 関数はこの情報を読みやすいメッセージにフォーマットし、安全な Webhook URL を通じて指定された Slack チャンネルに送信します。チームメンバーは、RDS インスタンスで元のエラーが発生してから数秒以内にこれらの通知を受け取ります。この合理化されたアプローチにより、データベース管理者とサポートチームが潜在的な問題を迅速に特定して対応できるようになり、最適なデータベースのパフォーマンスと信頼性を維持できます。 このソリューションを実装する主要なステップは以下のように要約できます： RDS for SQL Server のエラーログを CloudWatch ログループに公開する CloudWatch ログを処理する Lambda 関数を作成・設定する エラーを監視するための Lambda サブスクリプションフィルターを設定する Slack チャンネルを作成し、受信 Webhook を設定する Slack 通知用の Webhook URL で Lambda 環境を設定する 前提条件 このソリューションを実装するには、RDS for SQL Server インスタンスが既に設定され稼働しているアクティブな AWS アカウントが必要です。CloudWatch、Lambda、 AWS Identity and Access Management (IAM) を含む AWS サービスにアクセスして設定できる十分な権限を持っている必要があります。これには、Lambda 関数の作成と変更、CloudWatch ログループの管理、IAM ロールとポリシーの作成、RDS インスタンス設定の変更を行う機能が含まれます。 Slack 統合では、チャンネルを作成し Webhook 統合を設定できる Slack ワークスペースへの管理者アクセスが必要です。これらの権限は、受信 Webhook の設定とチーム向けの通知チャンネルの設定を行うために不可欠です。 RDS デプロイメントタイプ (シングル AZ またはマルチ AZ) の選択は、このソリューションにおける最大のコスト要因となる可能性があるので注意が必要です。続行する前に、 Amazon RDS 、 CloudWatch 、および AWS Lambda の料金ページを確認し、このソリューションを実装することのコストへの影響を理解することをお勧めします。 RDS ログの CloudWatch へのエクスポートを設定 最初に、エラーログを CloudWatch にエクスポートするために RDS for SQL Server インスタンスを設定する必要があります。この設定により、一元的なログ保存が可能になり、通知システムの基盤が構築されます。RDS for SQL Server のエラーログを CloudWatch に公開するには、DB インスタンスを変更する必要があります。以下の手順を完了してください： Amazon RDS コンソールのナビゲーションペインで、「データベース」を選択します 変更したい DB インスタンスを選択します 「変更」を選択します 「ログのエクスポート」セクションで、CloudWatch への公開を開始したいログを選択します。この投稿では、「エラーログ」を選択し、「続行」をクリックします 確認ページで変更内容を確認し、変更を即座に適用するには「すぐに適用」を選択します。変更を保存するには「DB インスタンスを変更」を選択します。または、変更を修正するには「戻る」を選択し、変更をキャンセルするには「キャンセル」を選択します これで、リアルタイム Slack 通知を使用した CloudWatch ログ処理フローをセットアップする準備が整いました。 Slack チャンネルの受信 Webhook を作成 通知システムの次のステップでは、アラートの送信先を設定します。Lambda 関数がフォーマットされたメッセージを送信できる安全な URL エンドポイントを提供する Slack webhook を作成します。これにより、指定された Slack チャンネルにエラー通知を自動投稿でき、チームメンバーが問題を監視し対応できるようになります。以下の手順を完了してください : Slack ワークスペースを開きます ワークスペース設定に移動します アプリと連携を選択します Incoming Webhooks を検索します Slack に追加を選択します 通知用のチャンネルを選択します Webhook URL をコピーします – 次のステップで必要になります Lambda 関数を作成し、関連リソースを設定 このステップでは、CloudWatch ログを処理するコアとなるサーバーレス Lambda 関数を作成します。Lambda 関数は Python で記述され、CloudWatch ログデータをデコードし、関連するエラー情報を抽出し、Slack 通知用にフォーマットするロジックが含まれています。この関数は、監視ソリューションの中央処理装置として機能します。Lambda 関数を作成するために、以下の手順を完了してください : GitHub からプロジェクトリポジトリ をクローンまたはダウンロードしてローカルマシンに保存します ターミナルでプロジェクトのルートディレクトリに移動します 前提条件が満たされていることを確認します AWS CLI がインストールされ、適切な権限が設定されていること Python 3.12 がローカルにインストールされていること (デプロイメントスクリプトが独立した仮想環境を作成します)。システムに Python 3.12 をインストールする方法については、README.md を参照してください。 zip ユーティリティが利用可能であること IAM、Lambda、DynamoDB に対する適切な AWS 権限 (README.md ファイルの前提条件セクションを参照) 自動デプロイメントスクリプトを実行します : ./scripts/deploy.sh プロンプトが表示されたら、前のステップで作成した Slack Webhook URL を入力してください スクリプトは自動的に以下を実行します : システムに Python 3.12 がインストールされていることを確認する 分離された Python 3.12 仮想環境を作成する 依存関係の分離のために仮想環境をアクティベートする 分離された環境に urllib3 をインストールする DynamoDB アクセス許可を持つ IAM ポリシー (SlackNotifierLambdaPolicy) を作成する 適切な信頼関係を持つ IAM ロール (SlackNotifierLambdaRole) を作成する Python 3.12 を使用して urllib3 Lambda レイヤーをビルドして公開する Lambda 関数 (SlackNotifier) をパッケージ化してデプロイする Slack Webhook URL を含む環境変数を設定する urllib3 レイヤーを関数にアタッチする 一時ファイルをクリーンアップする 仮想環境を非アクティブ化する 免責事項 : このプロセスの一部として作成された IAM ポリシー (SlackNotifierLambdaPolicy) は、一般的なガイドラインとしてのみ機能します。お客様の特定の要件とコンプライアンス基準に従って、すべてのセキュリティ対策を確認、カスタマイズ、および検証する必要があります。AWS のベストプラクティスでは、ユーザーがタスクを実行するために必要な最小限の権限のみを付与する最小権限の原則の実装を強く推奨しています。 AWS IAM ドキュメント で詳述されているこのコアセキュリティ概念は、潜在的なセキュリティリスクを最小限に抑えるのに役立ちます。 CloudWatch ログループの Lambda サブスクリプションフィルターの作成 サブスクリプションフィルターはトリガーメカニズムとして機能し、どのログエントリを Lambda 関数に送信すべきかを定義します。CloudWatch ロググループ内の特定のエラーパターンを監視するように設定し、関連するログのみが処理され、不要な関数呼び出しが回避されるようにします。先ほど作成した Lambda 関数を使用して Lambda サブスクリプションフィルターを作成するには、以下の手順を完了してください： CloudWatch コンソールで、ナビゲーションペインの「ロググループ」を選択します SQL Server ロググループを選択します 「アクション」メニューで「サブスクリプションフィルター」を選択し、「Lambda サブスクリプションフィルターの作成」を選択します Choose destination セクションのドロップダウンから Lambda 関数 (SlackNotifier) を選択してください Configure log format and filters の下で、以下の Subscription filter pattern を入力してください : ?ERROR ?EXCEPTION ?FAILURE ?CRITICAL? FATAL ?error ?exception ?fail ?severity ?deadlock ?timeout ?terminated ?violation ?denied ?insufficient ?overflow ?syntax ?invalid ?unable ?cannot ?failed ?corrupt ?inconsistent "Error: 18456" "Error: 17806" "Error: 233" "Error: 1205" "Error: 3041" "Error: 8152" ?error ?Error ?Failed ?failed ?Severity ?severity Code サブスクリプションフィルターに名前を付けてください。この投稿では、Error Subscription Filter を使用します (オプション) テストパターンセクションでこの設定をテストできます。「テストするログデータを選択」ドロップダウンからデータベースを選択し、「パターンをテスト」をクリックしてください。結果セクションでフィルターパターンに一致するログが表示されるはずです 「ストリーミングを開始」をクリックしてください これで、すべてのデータベースエラーログが処理され、CloudWatch ログストリームを通じてアクセス可能になります この最終ステップにより、Amazon RDS for SQL Server の自動監視ソリューションの実装が完了しました。これで、システムはSQL Server エラーをキャプチャし、Slack チャンネルに通知を送信する準備が整いました。Lambda 関数は Webhook URL を使用して Slack と安全に通信し、データベースエラーが発生した際、チームに即座に通知を送信します。これらの通知には、エラーメッセージ、タイムスタンプ、コンテキストの詳細などの重要な情報が含まれており、チームが潜在的な問題を迅速に評価し対応できるようになります。システムはバックグラウンドで継続的に動作し、データベースログの監視に手動での介入は必要ありません。 ソリューションの検証 実装が意図したとおりに動作していることを確認するために、簡単な検証テストを実行できます： SQL Server Management Studio (SSMS) を使用して RDS for SQL Server インスタンスに接続します。次のスクリーンショットに示すように、データベース SlackNotifications を使用します。 デモンストレーション目的で RAISERROR WITH LOG オプションを使用してエラーメッセージを作成します << RAISERROR('This error has been raised using RAISERROR', 16, 1) WITH LOG; >> Code 先ほど言及されたエラーについて、SQL Server エラーログを確認してください << EXEC rdsadmin.dbo.rds_read_error_log @index = 0, @type = 1, @search_str1= 'This error has been'; >> Code RDS for SQL Server のエラーログを CloudWatch に公開したので、次のステップはエラーが CloudWatch にエクスポートされているかどうかを確認することです。 CloudWatchコンソールで、ナビゲーションペインの「ログ」の下にある「ロググループ」を選択します DB インスタンスの RDS for SQL Server エラーログを選択します (この投稿では、 /aws/rds/instance/<<your db instance>>/error ) 「ログストリーム」タブで、データベースが実行されているアクティブノードを選択します (これは特定の環境によって異なる場合があります) タイムスタンプとともにエラーメッセージを確認できます。 数秒以内に、設定された Slack チャンネルにこのテストエラーが通知として表示されるはずです。以下のような感じです： CloudWatch Logs を確認して RDS ログが正常にエクスポートされ、Lambda 関数がこれらのログを正しく処理していることを確認することで、システムの動作を検証することもできます。 考慮事項 このソリューションを実装する際は、最適なパフォーマンスとコスト効率を実現するために、いくつかの重要な点に注意することが大切です： RDS for SQL Server エラーログを CloudWatch に公開する前に、機密情報を保護するためのカスタムマスキングロジックを実装してください。これらのログには機密データが含まれている可能性があるため、特定のビジネス要件に基づいてこのアプローチを評価してください。 デフォルトの「期限切れなし」設定はストレージコストを増加させる可能性があるため、要件に基づいて CloudWatch Logs の保持期間を設定してください。 セキュリティのため、Lambda 実行ロールが最小権限の原則に従っていることを確認し、Slack の Webhook URL などの機密情報を Lambda 環境変数で表示したくない場合は、AWS Systems Manager Parameter Store または Secrets Manager に保存してください。 CloudWatch メトリクスを通じて Lambda 関数のパフォーマンスとエラーを定期的に監視 してください。 これはサンプル実装ですが、本番環境での信頼性を確保するために、Lambda 関数に適切なエラーハンドリングを追加することを確認してください。 この実装は、最小権限を持つ IAM ロール、機密情報のための環境変数、依存関係管理のための Lambda レイヤーを使用して、セキュリティとスケーラビリティのための AWS ベストプラクティスに従っています。このアプローチは、信頼性の高い監視を提供するだけでなく、ニーズに応じて自動的にスケールするサーバーレスコンポーネントを使用することでコスト効率性も維持します。このソリューションは、複数のデータベースインスタンスを監視するように適応したり、追加のエラーパターンや通知形式を含むように変更したりできます。 クリーンアップ 不要な料金の発生を避け、AWS の環境をクリーンに保つために、以下の手順に従ってこのソリューションで作成されたリソースを削除します : DB インスタンスの削除 Lambda リソースを削除する : 自動化されたアンデプロイスクリプトを実行する : ./scripts/undeploy.sh CloudWatch リソースを削除する : CloudWatch ロググループからサブスクリプションフィルターを削除する 不要になった場合は、CloudWatch への RDS エラーログエクスポートを無効にする CloudWatch ロググループに保存されているログが不要になった場合は、削除を検討する Slack のクリーンアップ : Slack チャンネルから Incoming Webhook インテグレーションを削除する この目的のために専用に作成された通知チャンネルがある場合は、アーカイブまたは削除する 結論 この投稿では、AWS ネイティブサービスと Slack 統合を使用して、Amazon RDS for SQL Server 向けの効率的でサーバーレスなリアルタイム監視システムを構築する方法を紹介しました。エラー通知プロセスを自動化することで、チームはデータベースの問題への対応時間を大幅に短縮し、アプリケーションへの潜在的な影響を最小限に抑えることができます。最も重要なことは、この自動通知システムが従来のデータベース監視アプローチをリアクティブなものからプロアクティブなものに変革することです。チームはもはやログを手動でチェックしたり、重要なデータベースエラーを見逃すことを心配したりする必要がありません。リアルタイム Slack 通知により、チームは問題の検出ではなく解決に集中でき、最終的にデータベースの信頼性向上と運用オーバーヘッドの削減につながります。 翻訳はソリューションアーキテクトの Yoshinori Sawada が担当しました。原文は こちら です。 著者について Sandip Samanta Sandip は AWS インドのテクニカルアカウントマネージャーで、エンタープライズのお客様の AWS クラウドジャーニーの加速を支援しています。クラウドアーキテクチャとソリューション設計における豊富な経験を持ち、技術的ガイダンスとアーキテクチャのベストプラクティスを通じてお客様が AWS への投資を最大化できるよう支援することに注力しています。 Kanchan Bhattacharyya Kanchan は、AWS のシニアテクニカルアカウントマネージャーです。彼は企業のデータベース運用の最適化を専門としています。SQL Server、PostgreSQL、MySQL、Amazon Aurora を含む Amazon RDS プラットフォーム全体にわたる深い専門知識を活用し、組織がクラウド投資を最大化できるよう戦略的ガイダンスを提供しています。

こんにちは、Amazon Connect ソリューションアーキテクトの梅田です。 2025 年 9 月のアップデートまとめ はお読みいただけましたでしょうか。今月も 以下の内容でアップデート 情報をお届けします。皆さんのお役に立つ内容があれば幸いです！ 注目のアップデートについて 2025 年 10月のアップデート一覧 AWS Contact Center Blog のご紹介 AWS Black Belt オンラインセミナー (Amazon Connect 関連) 1.注目のアップデートについて Amazon Connect で生成 AI を活用したメールの会話の概要と推奨応答を提供 Amazon Connect で、生成 AI を活用したメール会話の概要、推奨アクション、メール会話への応答(下書き)がエージェントに提供されるようになりました。これにより、エージェントはメールをより効率的に処理できるようになり、顧客はより迅速で一貫したサポートを受けることができます。例えば、顧客から返金リクエストのメールを受信すると、Amazon Connectは購入履歴から重要情報を提供し、返金処理の手順をガイドしながら、適切な返信メールを自動生成することで、問い合わせを迅速に解決します。 この機能を有効にするには、メールによる問い合わせをエージェントに割り当てる前に、 Amazon Q in Connect ブロック をフローに追加します。 ナレッジベース を追加して プロンプトを定義 することで、メールの生成 AI を活用したアシスタントの出力をカスタマイズできます。これにより、一貫したカスタマーサービスを提供するために、会社の言語、口調、ポリシーに合った応答を AI エージェントに生成させることができます。 Amazon Q in Connect はユースケースに応じた AI エージェントと AI プロンプトを提供します。今回、E メール 用に新たに3つの AI エージェントと4つの AI プロンプトが追加されました。これらを使用して、Amazon Q in Connect はお客様から受信した問い合わせ E メールに対して、「メール会話の概要」「関連するナレッジベースと推奨アクション」「メール会話への応答(下書き)」を提供します。 本機能の利用を開始するには、上述した AI プロンプトと それらを使用した AI エージェントを設定してください。日本語に対応した AI エージェントを設定する際は、AI エージェントの設定画面のロケールで「Japanese」を指定します。 設定の詳細については以下の Amazon Connect 管理者ガイドをご参照ください E メールの概要と推奨されるレスポンスを使用する AI プロンプトを作成する AI エージェントを作成する 2. 2025年10月のアップデート一覧 Amazon Connect が会話の録音とトランスクリプトに対する詳細なアクセス許可の提供を開始 – 2025/10/24 Amazon Connect で、会話の録音データと文字起こしデータへのアクセス権限を、UI を通じてより詳細に設定できるようになりました。この新機能により、管理者はより柔軟でセキュアなアクセス制御を実現できます。コンタクトセンターの管理者は、録音データと文字起こしデータへのアクセス権限を個別に設定できるようになりました。例えば、ユーザーが通話を聞くことはできても、文字起こしデータの不正なコピーを防止するといった制御が可能です。システムは、ダウンロード制御の柔軟性も向上しています。編集済み（機密情報などがマスキング処理された）録音データのダウンロールは許可しつつ、未編集版のダウンロードは制限するといった設定が可能です。さらに、管理者は機密性の高い会話については編集済みの録音データへのアクセスのみを許可し、その他の一般的な会話については未編集の録音データへのアクセスを許可するなど、より高度な権限設定のシナリオを作成することができます。このアップデートにより、セキュリティとコンプライアンスの要件に応じた、より緻密なアクセス制御が可能になり、コンタクトセンターの運用における安全性と効率性が大幅に向上します。  関連リンク 管理者ガイド Amazon Connectのアウトバウンドキャンペーンがプレビューダイヤリングに対応し、エージェントの制御性を向上 – 2025/10/24 Amazon Connect のアウトバウンドキャンペーン機能に、通話開始前に顧客情報を確認できるプレビューダイヤルモードが追加されました。この機能により、エージェントは発信前に顧客の名前、アカウント残高、過去のやり取りなどの重要な情報を確認し、最適なタイミングで発信することができるようになりました。また、キャンペーンマネージャーはプレビュー設定をカスタマイズし、エージェントの行動、キャンペーン結果、顧客エンゲージメントの傾向を新しいダッシュボードで監視できるようになっています。この機能が重要である背景として、適切な情報がないまま電話をすることにより、エージェントは顧客に応じた対応に苦労し、結果として顧客の信頼や満足度の低下に繋がります。さらに、米国電話消費者保護法(TCPA)や英国通信庁(OFCOM)の規制により、顧客とエージェントの接続の遅延に対して厳しい罰則が科される可能性があることも考慮されています。新しいプレビューダイヤリング機能では、マネージャーは確認時間の制限を設定し、必要に応じてキャンペーンからのコンタクトの削除を有効にできます。エージェントは顧客データとともにカウントダウンタイマーを確認でき、任意のタイミングで発信が可能です。また、平均プレビュー時間や破棄数などの分析データにより、戦略の最適化とチームの効果的な指導を行うことができます。発信前にエージェントを確保することで、規制遵守をサポートしながら、アウトバウンドコールの精度を向上させることができます。これにより、顧客との接続性と運用管理の両方が改善され、より効果的なアウトバウンドキャンペーンの実施が可能になります。  関連リンク 管理者ガイド Amazon Connect がスレッド表示に対応し、エージェントの返信に会話履歴が含まれるように   – 2025/10/23 Amazon Connect の E メール に、会話の文脈を理解しやすくする新機能が追加されました。エージェントの返信に過去のやり取りの履歴が自動的に含まれるようになり、さらにメールのやり取りをスレッド形式で表示できるようになりました。この機能強化により、エージェントと顧客の双方が過去のコミュニケーション内容を簡単に確認できるようになり、会話の流れや文脈を把握しやすくなりました。これは一般的なメールクライアントでよく見られる機能を取り入れたもので、エージェントと顧客の両者にとって、より自然で使い慣れた形でのメールコミュニケーションが可能になります。このアップデートは、顧客とエージェント間のコミュニケーションをよりスムーズにし、サービス品質の向上に貢献することが期待されます。 関連リンク 管理者ガイド Amazon Connect が初期評価結果に基づく自動フォローアップ評価のサポートを開始 – 2025/10/21 Amazon Connect に、新しい自動フォローアップ評価機能が追加されました。この機能により、初回の評価結果に基づいて、特定の状況を分析するためのフォローアップ評価を自動的に開始することが可能になります。例えば、顧客サービスの初回評価において顧客が商品に対して興味を示していることが検出された場合、システムは自動的にエージェントの営業パフォーマンスに焦点を当てたフォローアップ評価を開始することができます。これにより、マネージャーはエージェントグループ間で一貫した評価基準を維持しながら、時間の経過に関係なく評価の質を保つことができます。さらに、営業機会やエスカレーション、その他の重要なやり取りなど、特定のシナリオについてより深いインサイトを得ることが可能になりました。このような自動化された評価プロセスにより、品質管理の効率化とサービス品質の向上が実現できます。 関連リンク 管理者ガイド Amazon Connect がスケジュール遵守に関する設定可能なしきい値を提供開始 -2025/10/14 Amazon Connect で、スケジュール遵守に関する設定可能なしきい値の提供が開始され、エージェントのパフォーマンスをより柔軟に追跡できるようになりました。エージェントのシフト開始または終了の繰り上げと繰り下げや、個々のアクティビティのしきい値を定義できます。例えば、エージェントがシフト開始を 5 分繰り上げ、終了を 10 分繰り下げ、休憩の終了を 3 分繰り下げても、遵守スコアに悪影響が及ばないようにできます。これらのしきい値は、個々のチームに合わせてさらにカスタマイズできます。例えば、対応に長い時間を要する問い合わせを処理するチームは休憩の開始時間をより柔軟に設定できます。今回のリリースにより、マネージャーは本当の遵守違反に目を向け、軽微なスケジュール逸脱がエージェントのパフォーマンスに及ぼす影響を除外できるようになり、マネージャーの生産性とエージェントの満足度が向上します。  関連リンク 管理者ガイド Amazon Connect がエージェントスケジュール準拠の通知をサポート -2025/10/11 Amazon Connect では、エージェントのスケジュール準拠通知がサポートされるようになりました。これにより、エージェントがスケジュールされたアクティビティを順守していないことを積極的に特定することが簡単になります。エージェントが準拠基準値を超えたときに、EventBridge 経由でメールまたはテキスト通知をスーパーバイザーに自動的に送信するルールを定義できます。たとえば、エージェントの準拠率が直近の 15 分間で 85％ を下回った場合、スーパーバイザーはメールでアラートを受信できます。これらの自動通知により、ダッシュボードを継続的にモニタリングする必要がなくなり、サービスレベルが低下する前に積極的な介入が可能になり、スーパーバイザーの生産性と顧客満足度の両方が向上します。 関連リンク 管理者ガイド Amazon Connect でエージェントのスケジュール設定のコピーと一括編集をサポート -2025/10/10 Amazon Connect では、エージェントのスケジュール設定のコピーと一括編集がサポートされるようになり、設定と管理が容易になりました。既存のスケジュール設定をコピーして新しいスケジュール設定を作成できます。たとえば、平日のシフトプロファイルをコピーして週末のバリエーションを作成したり、既存のエージェントのスケジュール設定 (タイムゾーン、週ごとの勤務時間、休日など) を既存のエージェントから複数の新入社員にコピーしたりできます。一括編集では、週ごとの勤務時間を変更せずに、新入社員のタイムゾーンや開始日を更新するなど、特定の項目を選択して更新できます。このような更新により、管理者が構成管理に費やす時間が短縮され、生産性と運用効率が向上します。 関連リンク 管理者ガイド Amazon Connect で、関連ケースをリンクし、カスタム関連項目を追加し、それらを検索するための新しいケース API をリリース -2025/10/07 Amazon Connect では、関連するケースをリンクしたり、カスタム関連項目を添付したり、それらを検索したりして、ケースデータをプログラムで拡充できるようになりました。これにより、エージェントは問題をより迅速に解決するために必要なすべてのコンテキストを把握できます。例えば、航空会社は 1 件のフライトキャンセルに関連するすべての顧客ケースをリンクして再予約を調整し、事前に最新情報を送信できます。また、小売業者は注文と配送の詳細を返金リクエストに添付して、より迅速な解決を実現し、顧客に常に情報を提供できます。 関連リンク API リファレンス Amazon Connect でサービスレベルの計算がカスタマイズ可能に -2025/10/06 Amazon Connect では、特定のニーズに合わせてサービスレベルの計算をカスタマイズできるようになりました。スーパーバイザーとマネージャーは、問い合わせがサービスレベル基準を満たしていると見なされる時間しきい値を定義し、どの問い合わせの結果を計算に含めるかを選択できます。例えばマネージャーは、設定可能な時間しきい値を使用して、コールバック問い合わせの数を数えたり、キューで待機している間に転送された問い合わせを除外したり、短期間の離脱を除外したりすることができます。サービスレベルの計算のカスタマイズは、分析ダッシュボードのメトリクス設定セクションから実行できます。この機能により、スーパーバイザーとマネージャーは、事業運営により合致したサービスレベルメトリクスの計算を作成できるようになりました。サービスレベルのパフォーマンスをカスタマイズして表示することで、運用マネージャーはサービス基準をどの程度効果的に満たしているかを評価できます。 関連リンク 管理者ガイド Amazon Connect で生成 AI を活用したメールの会話の概要と推奨応答を提供 -2025/10/03 注目アップデート をご覧ください！ Amazon Connect で ChromeOS でのエージェント画面録画のサポートを開始 -2025/10/03 Amazon Connect では、ChromeOS デバイスを使用するエージェントに対して画面録画機能が提供されるようになり、エージェントのパフォーマンスを簡単に向上させることができるようになりました。画面録画を使用すると、顧客との通話を聞いたり、チャットの文字起こしを確認したりするだけでなく、問い合わせを処理する際のエージェントのアクション (音声通話、チャット、タスクなど) を監視することで、エージェントにコーチングが必要な領域 (例: 対応の処理時間が長い、ビジネスプロセスの違反など) を特定できます。 関連リンク 管理者ガイド Amazon Connect 料金 Amazon Connect が分析データレイクでエージェントの休暇残数データを提供 -2025/10/03 Amazon Connect が分析データレイク* でエージェントの休暇残数データを提供するようになり、このデータからレポートやインサイトを簡単に生成できるようになりました。このリリースにより、分析データレイクのさまざまな休暇カテゴリ (有給休暇、病気休暇、休業など) にわたる最新および過去のエージェントの休暇残数にアクセスできるようになりました。残数に加えて、残数に影響を与えたすべてのトランザクションの時系列リストを表示することもできます。例えば、エージェントが 1 月 1 日に 80 時間の有給休暇を付与されて勤務を開始し、1 月 3 日に 20 時間の休暇をリクエストを送信したが、その後そのリクエストをキャンセルした場合、各トランザクションによる最終的な 80 時間の残数に対する影響を確認できます。このリリースにより、マネージャーが手動で残数と休暇トランザクションを調整する必要がなくなり、休暇管理が容易になります。これにより、マネージャーの生産性が向上し、エージェントからの問い合わせへの対応が容易になります。 * Amazon Connect 分析データレイク Amazon Connect 分析データレイク は、コンタクトセンターのデータ分析を効率化し、より深いインサイトを得るための機能です。最大の特徴は、複雑なデータパイプラインを構築することなく、Amazon Connect の運用データに直接アクセスできる点にあります。データレイクに蓄積されるデータは、通話記録やチャットトランスクリプト、エージェントのパフォーマンス指標、キューの状態、顧客とのインタラクション履歴など、コンタクトセンター運営に関わる包括的な情報が含まれています。これらのデータはすべて構造化された形式で保存され、Amazon Athena を使用して標準的な SQL クエリで簡単に分析することができます。さらに、BI ツールと統合し、カスタムレポートやダッシュボードの作成も容易です。これにより、データアナリストやビジネスユーザーは、必要な情報にすぐにアクセスし、データドリブンな意思決定を行うことができます。また、AWS の分析サービスと組み合わせることで、より高度な分析も可能となります。 関連リンク 管理者ガイド Amazon Connect で発信通話における顧客入力を簡単に取得   -2025/10/02 AWS のクラウドベースのコンタクトセンターサービスである Amazon Connect で、発信音声ウィスパーフロー用に [顧客の入力を取得する] および [顧客の入力を保存する] フローブロックがサポートされるようになりました。[顧客の入力を取得する] フローブロックを使用すると、顧客が発信通話に応答した後、エージェントに接続される前に、発信通話で顧客にプロンプトを再生できます。また、顧客の応答は DTMF 入力または Amazon Lex Bot を介して収集できます。 この機能により、エージェントへの接続前に、発信通話でインタラクティブかつ動的な顧客入力をキャプチャできます。例えば、[顧客の入力を取得する] フローブロックを使用して、エージェントによる発信通話の一部としての通話録音について顧客の同意を得て、それを使用して Amazon Connect Contact Lens の録音と分析をトリガーできます。 関連リンク 管理者ガイド( 顧客の入力を取得する / 顧客の入力を保存する ) 3. AWS Contact Center Blog のご紹介 AWS re:Invent 2025: Reimagining customer experience with Amazon Connect (英語記事) AWS re:Invent 2025が12月1日から5日にかけてラスベガスで開催されることが発表されました。今年のAmazon Connect セッションでは、AI が大きな変革を遂げた一年を経て、インテリジェントな顧客体験の未来について深く探求します。基調講演やブレイクアウトセッション、実践的な学習を通じて、企業がエージェンティックAIを活用して卓越した顧客体験を実現しながら、運用効率を向上させている事例を紹介します。特に注目のセッションとして、Amazon Connect 部門の VP である Pasquale DeMaio による「BIZ221：Amazon Connect による顧客体験におけるエージェンティック AI の進歩」が予定されており、AI を活用したカスタマーサービスの革新的な取り組みについて解説されます。また、12月2日には Cromwell の Giada にて顧客体験レセプションが開催され、AWS エキスパートや CX（カスタマーエクスペリエンス）リーダーとの交流の機会も提供されます。 4. AWS Black Belt オンラインセミナー (Amazon Connect 関連) Amazon Connect Global Resiliency 詳説 Amazon Connect Global Resiliency は Amazon Connect に地理的な冗長性を提供します。予期しない地域的な災害や障害が発生した場合にも、お問い合わせとエージェント接続を別のリージョンにあるインスタンスに分散する柔軟なソリューションを提供します。Amazon Connect が備えている信頼性を理解したい方、コンタクトセンターにおける BCP の設計に関心のある方、Amazon Connect Global Resiliency の具体的な機能が知りたい方は、ぜひご視聴ください。 資料（ PDF ） | 動画（ YouTube ） 今月のお知らせは以上です。皆さまのコンタクトセンター改革のヒントになりそうな内容はありましたでしょうか？ぜひ、実際にお試しいただき、フィードバックをお聞かせいただけますと幸いです。 シニア Amazon Connect ソリューションアーキテクト 梅田 裕義

本記事は、2025 年 10 月 23 日に公開された How D2L transformed educational analytics using visual data preparation in Amazon Quick Sight を翻訳したものです。翻訳は Public Sector PSA の西川継延が担当しました。 この投稿は、D2L の Surekha Rao と Andrew Wooster が共同で執筆しました。 D2L では、世界の学習方法を変革することをミッションとしています。グローバルな学習イノベーションのリーダーとして、世界中の教育機関と緊密に連携し、学習をより刺激的で、魅力的で、人間的なものにしています。当社の主力学習管理システム（LMS）である D2L Brightspace は、数え切れないほどの教育体験の基盤として機能し、教育と学習成果の有意義な改善を推進できる貴重なデータを生成しています。 当社の Performance+ analytics suite は、教育者や管理者がエンゲージメントを監視し、リスクのある学習者を特定し、アセスメントやコース設計の有効性を評価できるように設計されています。直感的なダッシュボードと予測分析により、学習者へのタイムリーな介入とパーソナライズされたサポートを可能にします。しかし、学習エコシステムが拡大するにつれて、学習者のエンゲージメント指標、コースのパフォーマンス、機関の KPI など、管理する必要のあるデータの量と複雑さも増大しました。 この投稿では、D2L が Amazon Quick Sight の新しいデータ準備機能を使用して、Performance +パッケージの Brightspace Analytics 製品を強化した方法を紹介します。この進歩により、教育機関全体でデータインサイトが民主化されます。教育者や管理者は、技術的な専門知識を必要とせず、シンプルなクリック操作で生データを実用的なインサイトに変換できるようになります。 課題: ユーザビリティを維持しながら分析をスケールする ユーザーベースが拡大するにつれて、パフォーマンスや使いやすさを損なうことなく、分析機能をスケールさせるプレッシャーが高まりました。教育機関は厳しい予算制約の下で運営されることが多く、専任のデータサイエンスチームを持たない機関も少なくありません。私たちは、コスト効率が高く予測可能でありながら、さまざまなスキルレベルでデータインサイトを民主化できるソリューションが必要でした。Quick Sight を採用する前は、分析を効果的にスケールさせる能力を制限するいくつかの技術的課題に直面していました。 手頃な価格とコストの予測可能性 – 以前使用していたツールの多くは、ユーザー数やコンピューティング使用量に紐づく複雑な価格モデルを採用していました。これにより、コストの予測が困難になり、持続可能な方法で顧客に分析機能を提供することが難しくなっていました。リソースが限られている教育機関にとって、この予測不可能性は導入の大きな障壁となっていました。 リージョンの可用性とデータレジデンシー – 世界中の教育機関にサービスを提供しているため、マルチリージョンデプロイメントをサポートし、進化するデータレジデンシー要件に対応できるソリューションが必要でした。以前のツールには、データ主権の懸念に対処するために必要な柔軟性がなく、地理的に分散したリージョンのユーザーにサービスを提供する際にレイテンシーの問題が発生していました。 インサイトへの技術的障壁 – おそらく最も重要なことは、従来のデータ準備ツールでは SQL やプログラミングの専門スキルが必要とされることが多かったことです。これにより、教育者や管理者がインサイトにアクセスする前に、技術チームがデータを準備および変更する必要があったため、分析プロセスにボトルネックが生じていました。 ソリューション概要 新しい Quick Sight のデータ準備体験は、教育分析へのアプローチに⾰命をもたらしました。データ変換に GUI ベースのローコードなインターフェースを提供することで、技術的な障壁が取り除かれ、あらゆるスキルレベルのユーザーがデータを直接扱えるようになりました。 強化されたデータ準備機能により、Aggregate、Filter、Pivot、Unpivot、Append の各変換がサポートされるようになりました (更新されたナビゲーションペインのスクリーンショットに示されています)。これらはすべて、GUI ベースのローコードインターフェースを通じて利用できます。これらの機能がデータ準備プロセスを大幅に効率化しました。 教育機関では、教育者や管理者が以下のことを行えるようになりました。 データへのアクセスと変換を独立して実行 – 教職員は、SQL やプログラミングの知識を必要とせずに、データのクリーニング、変更、結合を行うことができます。これにより、技術チームへの依存が減り、より多くの人がデータを直接扱えるようになり、より迅速なインサイトの獲得とより機敏な意思決定につながります。 実用的なインサイトを迅速に生成 – ポイントアンドクリックのインターフェースとビジュアルワークフローにより、ユーザーはワークフローとダッシュボードを迅速に構築できます。これは、タイムリーな介入が学生の成功に大きな影響を与える可能性がある、ペースの速い教育環境に最適です。 部門全体で分析をスケール – 直感的なツールにより、教育機関は複雑なコーディングや Extract、Transform、Load (ETL) ツールについて全員をトレーニングする必要なく、部門全体で分析をスケールできます。このデータアクセスの民主化により、組織全体でよりデータに基づいた文化を創出できます。 リソース配分の最適化 – 専門的なデータエンジニアリングリソースの必要性を減らすことで、Quick Sight は限られた予算の教育機関にとって、分析をより手頃で予測可能なものにします。 次のワークフローは、Brightspace の生データセットが視覚的に変換され、統合された洞察に富んだデータセットになる様子を示しています。この変換により、学習者の登録情報とユーザーの人口統計情報をより深く分析できるようになり、カリキュラム計画とサポート戦略全体でデータドリブンな意思決定が可能になります。 データソースと統合 Quick Sight 実装の主な強みの 1 つは、複数のソースからデータを取得できることです。Quick Sight は、 Brightspace Learning Management System (LMS) と Data Hub の Brightspace Data Sets (BDS) と統合され、学習者のエンゲージメント、コースのパフォーマンス、インストラクターのアクティビティに関する豊富なデータを取得します。また、以下を含むさまざまな Quick Sight データソースを通じて、お客様が追加データを取り込むことをサポートしています。 1 回限りの (アドホック) 分析のためのファイルアップロード データベース接続 (MySQL、PostgreSQL、Oracle、SQL Server、 Amazon Aurora 、MariaDB) データプラットフォーム (Databricks、Spark、Teradata) クエリエンジン (Presto、Starburst、Trino) この柔軟性により、教育機関は運用の包括的なビューを作成し、学習データを他のシステムからの情報と組み合わせて、運用全体の改善を推進できます。 実世界への影響: 教育における意思決定の変革 Brightspace と統合することで、Quick Sight は教育における データに基づいた意思決定の推進力として機能します。学習分析を日常のワークフローに組み込むことで、教育者や管理者がより賢明でリアルタイムな意思決定を行い、学習成果にポジティブな影響を与えることを支援します。 たとえば、教員は学生のエンゲージメントデータのパターンを迅速に特定し、問題になる前に潜在的な課題を発見できるようになりました。教授は、学生が特定のモジュールに他のモジュールと比較して著しく少ない時間しか費やしていないことに気づけ、そのコンテンツの改訂や追加のサポートリソースが必要である可能性を示唆できます。 同様に、管理者は部門全体の組織的な KPI を追跡し、優れた領域と改善の機会を特定できます。技術チームがデータを準備するのを待つことなく、コース修了率、アセスメント結果、プラットフォーム採用トレンドを分析できます。 その影響は、運用効率以外の領域にも及びます。Quick Sight はデータインサイトへのアクセスを民主化することで、教育機関全体でエビデンスに基づく意思決定の文化を育むのに役立ちます。教員は自分でデータを探索できるようになることで、データへの関心が高まり、教育と学習に対するより革新的なアプローチにつながります。 教育エコシステム全体にわたる分析のスケーリング 現在、D2L の顧客の大部分が当社の分析ソリューションにアクセスしており、教育におけるデータの価値に対する認識が高まっていることを示しています。Performance +アドオンパッケージをご利用のお客様は、機関のニーズに応じてスケールする組み込み分析機能にアクセスできます。 このアプローチにより、予測可能なコスト構造を維持しながら、さまざまな規模の機関全体で分析をスケールすることが可能になります。リソースが限られている教育機関にとって、この予測可能性は長期的な計画と持続可能性にとって極めて重要です。 Quick Sight のローコードなデータ準備機能は、このスケーリングの取り組みにおいて特に価値がありました。技術的な障壁を取り除くことで、さまざまなスキルレベルのユーザーがインサイトにアクセスしやすくなり、教育者、管理者、ビジネスチームが日常業務でデータを活用できるようになりました。 教育分析の未来 今後を見据えて、私たちは学習成果と業務生産性能向上のため、導入の加速と分析の日常業務への組み込みに注力しています。 教育ワークフローとのより深い統合 – 分析機能を教育体験にさらに組み込むことで、データに基づいた意思決定を別の活動としてではなく、教育業務の自然な一部にすることを目指しています。 予測機能の強化 – Quick Sight の機械学習 (ML) 機能を基盤として、リスクのある学生をより高い精度で特定し、的を絞った介入を提案できる、より高度な早期警告システムの提供に取り組んでいます。 機関間ベンチマーク – プライバシーとデータガバナンスの要件を尊重しながら、機関がより広い文脈で自らのパフォーマンスを理解できるよう、匿名化されたベンチマークを提供する機会があると考えています。 セルフサービス分析の拡張 – Quick Sight のローコードアプローチを基盤として、技術者以外のユーザーが特定のニーズに合わせた独自のレポートやダッシュボードを作成できるよう、さらに支援する予定です。 まとめ D2L では、スケールし、コンプライアンスをサポートし、データへのアクセスを民主化するツールを教育機関に提供することに取り組んでいます。Brightspace と統合された Quick Sight は、その約束を実現する上で重要な役割を果たしています。 この新しいデータ準備エクスペリエンスは、教育エコシステムのすべての人々が分析にアクセスできるようにするための大きな前進を表しています。技術的な障壁を取り除き、データ変換のための直感的なツールを提供することで、Quick Sight はさまざまな規模の教育機関が、教育と学習における有意義な改善のためにデータを活用できるよう支援します。 教育機関が影響力を示し、成果を向上させるプレッシャーが高まる時代において、アクセスしやすいアナリティクスは不可欠です。Quick Sight を使用することで、技術的な専門知識や予算の制約に関係なく、さまざまなお客様に強力なデータインサイトを提供できるソリューションを提供できることを誇りに思います。 この取り組みを続ける中で、私たちは核となるミッションに集中し続けています。それは、イノベーション、エンゲージメント、データに基づいた意思決定を通じて、世界の学習方法を変革することです。AWS のようなパートナーや Quick Sight のようなサービスとともに、私たちは教育機関がこれまで想像もしなかったような成果を達成できるよう支援する能力に自信を持っています。Quick Sight が教育分析をどのように変革できるかについて詳しく知るには、以下のリソースをご覧ください。 Amazon Quick Sight の機能をさらに深く理解する 無料トライアル を始める Quick Suite Community に参加する 著者について Surekha Rao は、D2L のプロダクトマネジメントディレクターであり、過去 14 年間にわたって教育テクノロジーのイノベーションを推進してきました。プロダクトリーダーシップにおいて 4 年以上の経験を持ち、生成 AI、アナリティクス、アセスメント、エンゲージメントツールにわたる変革的なソリューションの戦略と立ち上げを主導してきました。これらの取り組みは、教育機関が学習成果を向上させ、教育者の効率を強化し、よりつながりのある学習体験を創出することに貢献しています。現在は、データとアナリティクスに注力し、教育者や管理者に実用的なインサイトを提供し、大規模なエビデンスに基づく意思決定を可能にする取り組みを推進しています。 Andrew Wooster は、D2L のシニアディレクター オブ エンジニアリングです。Andrew は、データ、分析、AI 製品および機能の全体的な技術戦略と提供に責任を持ち、チームが品質、パフォーマンス、スケーラビリティの高い方法で顧客価値を最前線にもたらすことができるよう取り組んでいます。 Barret Newman は、カナダ アルバータ州カルガリーにある Amazon Web Services (AWS) のプリンシパルソリューションアーキテクトです。15 年以上の IT 経験を持つ Barret は、EdTech のお客様が AWS 上で移行、モダナイゼーション、イノベーションを実現できるよう支援することに注力する技術的なソートリーダーです。仕事をしていないときは、パートナーと 2 匹の猫と過ごしたり、家中のあらゆるデバイスを自動化して統合したり、たくさんのコーヒーを飲んだりすることを楽しんでいます。 Vignessh Baskaran は、Amazon Quick Suite の機能である Amazon Quick Sight において、データ接続とデータ準備ドメインを担当するシニアテクニカルプロダクトマネージャーです。ビジネスインテリジェンスとデータウェアハウジングのバックグラウンドを活かし、Quick Sight の新しいデータ準備エクスペリエンスの製品戦略と開発を主導し、複雑なデータ変換をすべてのユーザーがアクセスできるようにすることに注力しています。仕事以外では、クリケット観戦、ラケットボール、シアトルでのさまざまな料理の探索を楽しんでいます。

本記事は、2025 年 10 月 23 日に公開された Transform and visualize your data preparation flow in Amazon Quick Sight without SQL を翻訳したものです。翻訳は Public Sector PSA の西川継延が担当しました。 Amazon Quick Sight は、 Amazon Quick Suite の機能の 1 つで、AI を活用したビジネスインテリジェンス (BI) 機能を提供し、散在するデータを戦略的なインサイトに変換して、より迅速な意思決定とより良いビジネス成果の達成を支援します。 データ準備は、特にビジネスユーザーが SQL の専門知識を持っていない場合、分析において最も時間のかかる部分であることが多いです。アナリストは通常、インサイトを生成するよりもデータ準備に多くの時間を費やしています。この課題は、データが複数のシステムや期間にわたってサイロ化されていることが多い小売組織において、特に重要です。 この投稿では、中規模の小売企業である AnyCompany (この投稿のための架空の企業) が、新しい Quick Sight データ準備エクスペリエンスを使用して、ビジネスアナリストが SQL を一行も書かずに複雑なデータを変換する方法を探ります。アナリストが、Append、Join、Unpivot、Aggregate などの機能を使用して、シンプルなポイントアンドクリックインターフェイスを通じて複雑なデータの課題を解決する方法、およびデータセットをさらなる変換のソースとして再利用できるようにすることで、チーム間のコラボレーションを可能にする方法を見ていきます。 データ準備における課題 AnyCompany は、USB ハブ、壁掛け時計、収納ボックス、その他の家庭用品やオフィス用品など、さまざまな消費者向け製品を販売しています。同社のアナリティクスチームは、過去の販売データと予測を組み合わせて、地域全体でマーケティング費用を最適化する必要があります。 この企業はいくつかのデータに関する課題に直面しています: 売上データは年度 (2023、2024、2025) ごとに複数のテーブルに分割されています 製品情報と地域情報は別々のディメンションテーブルに存在します データソース間でデータ形式の不整合が存在します (例: 郵便番号の形式) 予測データは列指向構造の Excel ファイルに保存されています 以前は、これらの課題には SQL の専門知識が必要であったり、技術チームからの支援を待つ必要がありました。新しい Quick Sight データ準備エクスペリエンスにより、AnyCompany のビジネスアナリストはこれらの問題を独立して解決できるようになりました。 ソリューション概要 AnyCompany は、Quick Sight を使用して共同データ準備ワークフローを実装しました。 グローバルアナリストが、売上、製品、地域データを組み合わせた基盤データセットを作成します。 地域アナリストが、その基盤に地域固有の分析と予測を追加します。 GUI ベースのビジュアルデータ編集準備機能により、アナリストは複雑な SQL クエリを記述することなく、高度なデータ変換を実行できます。 SPICE (Super-fast, Parallel, In-memory Calculation Engine) が、最適なパフォーマンスを実現するインメモリ計算エンジンを提供します。 グローバルアナリストのジャーニー AnyCompany のグローバルアナリストは、複数年のデータと製品および地域情報を組み合わせた包括的な売上データセットを作成する必要があります。SQL の知識が限られているにもかかわらず、アナリストは新しい Quick Sight データ準備エクスペリエンスを使用してこの基盤を構築することができます。 複数年にわたる売上基盤の構築 グローバルアナリストは、まず 2023 年の売上データを調査します。このデータには、 product_id 、 customer_id 、 order_date 、 ship_date 、 sales 、 quantity 、 discount などの注文詳細が含まれています。次のスクリーンショットは、これらのカラムの一部の例を示しています。 Quick Sight の Append 機能を使用することで、アナリストはわずか数クリックで 2024 年と 2025 年の売上データを結合できます。各ステップ後の Preview タブにより、アナリストはデータが正しく結合されていることをすぐに確認でき、変換プロセスに対する信頼性を高めることができます。 ディメンションデータによるエンリッチメント 統合された売上データが準備できたら、アナリストはそれを製品ディメンションテーブルと結合します。Quick Sight での結合操作は簡単です。アナリストは結合するテーブルと共通キー ( product_id ) を選択するだけで、プレビューには製品情報と売上データが並んだ拡張されたデータセットがすぐに表示されます。 しかし、地域ディメンションテーブルとの結合を試みると、アナリストはデータ品質の課題に直面します。 Preview タブを見ると、売上データと地域テーブルの郵便番号が一致していないことがわかります。売上データの一部の郵便番号は 5 桁以上あり、地域テーブルでは郵便番号が文字列ではなく整数として保存されています。 データ型の不整合の解決 Quick Sight は、これらの不整合を解決するための変換機能を提供しています。1 つの計算列ステップで、アナリストは left({postal_code}, 5) という数式を使用して Clean Zip 列を作成し、郵便番号の長さを標準化します。 Configure タブには、この計算のプレビューがリアルタイムで表示されます。 別の変換では、アナリストは単純なデータ型の変更を使用して、整数の郵便番号を文字列に変換します。複雑な SQL の CAST 関数や文字列操作が必要だったものが、ビジュアルインターフェースでの数回のクリックで実現できます。 郵便番号が両方のテーブルで一貫性を持つようになったため、アナリストは地域ディメンションテーブルとの結合に成功し、次に customer_id をキーとして顧客ディメンションテーブルとの結合を進めます。 データセットの最終化 データセットをより使いやすくするために、アナリストは Rename columns ステップを使用して、列により説明的な名前を付けます。Quick Sight では、1 つのステップで複数の列の名前を変更できるため、プロセスが効率化されます。Select columns ステップは、列の追加、除外、並べ替えを行うための直感的なインターフェイスを提供します。アナリストは列をドラッグして並べ替えたり、ワンクリックで除外したりできます。 変換を完成させた後、アナリストは 2023 & 2024 Union、Product Join、Calc – Clean Zip、Customer Join のようなユーザーフレンドリーなステップ名を作成し、データ準備プロセスを透明で理解しやすいものにします。その後、アナリストはデータセットを Sales Revenue Dataset として保存して公開し、他のアナリストが活用できるようにします。 次のスクリーンショットは、グローバルアナリストの最終的なワークフローを示しています。 地域アナリストのジャーニー AnyCompany の米国中部地域のアナリストは、自分の担当地域の前年比売上予測を作成する必要があります。グローバルアナリストがすでに行ったデータ準備作業を再現する代わりに、Sales Revenue Dataset を基盤として使用できます。 作成済データセットに基づく作業 地域アナリストは、新しいデータセットを作成し、Sales Revenue Dataset をソースとして選択することから始めます。このアプローチには大きな利点があります。地域アナリストは、グローバルアナリストが管理する Sales Revenue Dataset の構築に使用されたロジックを理解したり、再作成したりする必要がありません。ソースデータセットへの更新は、地域アナリストの作業に自動的に反映されます。 地域アナリストは、まず Change data type ステップを使用して適切な日付フォーマットを適用し、分析全体で一貫した日付処理を可能にします。 地域データにフォーカス 次に、アナリストは Filter ステップを使用して US-Central リージョンのみに焦点を当て、担当領域のデータセットを素早く絞り込みます。アナリストはまた、2025 年 9 月の最初の数日間の売上データに推定売上 (実際の売上ではない) が含まれていることに気づき、適切なフィルターを適用します。 Configure タブは、アナリストが複数のフィルターの条件をプレビューするのに役立ちます。 異なる粒度レベルの処理 アナリストは、フィルタリングされた Sales Revenue Dataset と予測データを結合する必要がありますが、粒度が一致していません。Sales Revenue Dataset には顧客情報が含まれていますが、予測データは製品カテゴリと月のレベルになっています。 Aggregate ステップを使用して、アナリストは Product 、 Zip 、 Region 、 Category などのカラムでデータをグループ化し、 Sales の合計を計算します。この変換により、複雑な SQL の GROUP BY ステートメントを必要とせずに、予測データに合わせて粒度を調整できます。 列指向の予測データの変換 地域アナリストは別の課題に直面しています。2025 年 9 月から 12 月までの予測データは、月が行ではなく列として格納された Excel ファイルに保存されています。従来の SQL では、これには複雑な UNPIVOT 操作が必要になります。 Quick Sight の Unpivot 変換を使用すると、アナリストは月の列 (2025 年 9 月、10 月、11 月、12 月) を選択し、出力列名を order_date と sales として指定するだけで、集計された Sales Revenue Dataset の列名と一致させることができます。この変換により、列指向のデータが即座に行指向の形式に変換され、履歴データと組み合わせることができます。 追加する前に、アナリストは Change data type ステップを使用して、 order_date 列を文字列型から日付型に変換し、Sales Revenue Dataset の日付形式との一貫性を保ちます。 履歴データと予測データの結合 両方のデータセットが互換性のある形式になったので、地域アナリストは Append ステップを使用して、2025 年 8 月までの履歴データと 2025 年 9 月から 12 月までの予測データを結合します。 Product や Category などのカラムの順序は 2 つのテーブル間で完全に異なり、カラム数も異なります。Quick Sight は、位置ではなく名前でカラムを自動的に整列させる重い処理を自動的に処理し、 Configure タブに適切な出力メッセージを提供します。これにより、カラムの整列と潜在的な不一致を明示的に処理する必要がある複雑な SQL を記述する場合と比較して、アナリストの時間を大幅に節約できます。 その結果、過去の月 (2025 年 8 月以前) の実績値と将来の月 (2025 年 9 月以降) の予測値を含む、年間全体にわたる完全なデータセットが得られます。 次のスクリーンショットは、地域アナリストの最終的なワークフローを示しています。 前年比分析の作成 データの準備が完了したので、地域アナリストは実績データと予測データの両方を含む前年比較を作成できます。Quick Sight の分析機能を使用して、前年と比較した売上のトレンドを示すビジュアライゼーションを作成し、年末までの予測を含めます。これにより、地域チームは SQL の専門知識を必要とせずに、計画とリソース配分のための貴重なインサイトを得ることができます。 メリットと結果 Quick Sight の新しいデータ準備機能により、AnyCompany は大幅な改善を実現しました。 時間の節約 – 以前は数日かかっていたデータ準備タスクが、1 時間未満で完了できるようになりました 技術的な依存関係の削減 – ビジネスアナリストは SQL の専門知識を必要とせずにセルフサービスで作業できます コラボレーションの向上 – グローバルおよび地域のアナリストが互いの作業を基に構築できます インサイト獲得までの時間短縮 – ビジュアルインターフェースにより、アナリストはデータ品質の問題を迅速に特定して解決できます ステップバイステップのビジュアルインターフェースは、AnyCompany がデータを扱う方法を変革します。以前は複雑な SQL クエリが必要だった作業が、今ではシンプルなクリックで実行できるようになりました。 まとめ 新しい Quick Sight データ準備エクスペリエンスは、データ変換を民主化し、技術的な専門知識がなくても高度な操作を実行できるようにします。AnyCompany の事例が示すように、Append、Join、Unpivot、Aggregate などの機能と、複合データセットを構築する機能を組み合わせることで、アナリストは直感的なビジュアルインターフェースを通じて実際のデータ課題を解決できます。 既存のデータセットを新しい変換のソースとして使用できる機能により、チーム間のコラボレーションが促進され、組織全体での一貫性が容易になります。アナリストのデータ準備の複雑さを排除することで、組織はインサイトを得るまでの時間を短縮できます。 Quick Sight の新しいデータ準備エクスペリエンスを開始するには、 Quick Suite アカウント にサインアップしてください。その後、新しいデータセットを作成し、ステップバイステップの変換機能を探索できます。 著者について Ramon Lopez は、Amazon Quick Sight のプリンシパルソリューションアーキテクトです。BI ソリューションの構築における長年の経験と会計のバックグラウンドを持ち、お客様との協働、ソリューションの創出、世界クラスのサービスの提供に情熱を注いでいます。仕事以外の時間は、海や山でアウトドアを楽しむことを好んでいます。 Vignessh Baskaran は、Amazon Quick Suite の機能である Amazon Quick Sight において、データ接続とデータ準備ドメインを担当するシニアテクニカルプロダクトマネージャーです。ビジネスインテリジェンスとデータウェアハウジングのバックグラウンドを活かし、Quick Sight の新しいデータ準備エクスペリエンスの製品戦略と開発を主導し、複雑なデータ変換をすべてのユーザーがアクセスできるようにすることに注力しています。仕事以外では、クリケット観戦、ラケットボール、シアトルでのさまざまな料理の探索を楽しんでいます。

本記事は 2025 年 10 月 22 日に Migration & Modernization Blog で公開された “ AWS for VMware: Your complete re:Invent 2025 guide ” を翻訳したものです。 AWS の最新の AI を搭載した移行ツールとモダナイゼーションソリューションを使って、VMware 環境を革新する方法を紹介します。今年の re:Invent では AWS Transform や Amazon Elastic VMware Service (Amazon EVS) などの画期的な新機能、業界リーダーによる実践的な変革戦略、そしてデジタルトランスフォーメーションを開始するためのガイダンスが紹介されています。 私たちは、クラウドジャーニーにとって最も重要な VMware に焦点を当てた注目のセッションを厳選しました。各セッションでは、技術的な詳細解説からハンズオン移行ワークショップまで、お客様の成功事例や実証済みのモダナイゼーションフレームワークを取り上げ、最も重要な移行課題の解決に役立つ実用的な洞察を提供します。 基礎的な移行計画から高度なアーキテクチャの詳細解説まで、あなたのデジタルトランスフォーメーションの段階に応じた専用セッションが用意されています。専門家によるワークショップ、インタラクティブなラボ、戦略ディスカッションに参加して、シームレスなクラウド導入のための最新の AWS ツールとベストプラクティスを習得しましょう。 移行とモダナイゼーション戦略 世界中の IT チームが、ROI と事業継続性を確保しながら、レガシーシステムを変革し、アプリケーションにとって最適な道筋を決定しようとしています。これらのセッションでは、実体験、お客様の成功事例、そして VMware ワークロードをクラウドに自信を持って移行するのに役立つ、さまざまな移行パスの概要をまとめています。 AWS for VMware Migrations: Successes, roadmaps, & strategies | MAM203 | Level: 200 Type: Breakout session – Customer Panel Date & Location: Monday, Dec 1 2:30 PM – 3:30 PM PST | Wynn VMware 環境の AWS への移行に成功した IT リーダーたちが、彼らのクラウドジャーニーの経験を共有するセッションにご参加ください。移行計画と実行において実証済みのツール、戦略、そして学んだ教訓から学びましょう。これらのグローバル組織は、モダナイゼーションロードマップとイノベーション戦略に関する洞察を共有し、クラウドトランスフォーメーションを始めたばかりの方も、課題に直面している方も、あなた自身のクラウド変革に向けた貴重なガイダンスを提供します。 Map your VMware workloads migration and modernization journey to AWS | MAM323 | Level: 300 Type: Chalk talk Date & Location: Tuesday, Dec 2 1:00 PM – 2:00 PM PST | Wynn このインタラクティブセッションでは、多様な VMware ワークロードに対する、固有の要件、依存関係、ビジネス目標を考慮したカスタマイズされた移行とモダナイゼーション戦略を探求します。リフト & シフトから完全なクラウドネイティブなトランスフォーメーションまで、生成 AI などのイノベーションを活用して移行を加速し、リスクを軽減するアプローチの選択方法を学びます。投資を最適化し、情報に基づいた意思決定を導くためのベストプラクティス、ライセンスに関する考慮事項、戦略的フレームワークを取り上げ、ビジネス目標と技術的制約に合致した、回復力があり拡張可能なクラウドアーキテクチャの構築をお手伝いします。 Pioneering Agentic AI Transformation: CSL VMware & SAP modernization | MAM346 | Level: 300 Type: Breakout session Date & Location: Wednesday, Dec 3 11:30 AM – 12:30 PM PST | Wynn CSL Behring 社が AWS Transform の Agentic AI を使用して 4000 台以上の VMware サーバーを移行し、SAP システムを統合することで、どのようにインフラストラクチャを変革したかを紹介します。彼らの戦略は、技術的負債とライセンスコストを削減しながら、発見と計画のプロセスを 10 倍高速化することを実現しました。 RISE with SAP on AWS を通じて ERP ランドスケープを統合し、企業全体のデータ標準を確立した方法を学びましょう。このケーススタディでは、あなたの組織のトランスフォーメーションジャーニーに適用できる技術的ガイダンスと実用的な洞察を提供します。 VMware to AWS Readiness: Foundational decisions before your migration | MAM357 | Level: 300 Type: Chalk talk Date & Location: Monday, Dec 1 3:00 PM – 4:00 PM PST | MGM VMware から AWS への移行を成功に導く重要な意思決定を探求するためにご参加ください。ライセンス、運用モデル、技術アーキテクチャ、組織の準備状況における選択が、移行結果にどのような影響を与えるかを検証します。VMware 環境の依存関係とビジネス制約を包括的に評価し、ステークホルダーの合意形成と将来を見据えた計画のための実用的なフレームワークを使用する方法を学びましょう。このセッションでは、一般的な移行の落とし穴を回避し、長期的な成功を確実にするための重要な戦略的ガイダンスを提供します。 製品の詳細解説とハンズオンワークショップ: AWS Transform VMware から AWS への移行ジャーニーを加速するために設計された没入型セッションを通じて AWS Transform を探求しましょう。ワークロードを Amazon EC2 にモダナイズし、VMware ライセンスコストを削減し、Agentic AI を活用してアプリケーション発見、依存関係マッピング、ネットワーク変換、ウェーブ計画、最適化された EC2 インスタンス選択を自動化します。ブレークアウトセッションを通じた戦略的洞察を求めている場合でも、ワークショップを通じたハンズオン体験を求めている場合でも、クラウド移行の複雑さを軽減する方法を発見し、開始方法を学ぶことができます。 Agentic AI for VMware migrations with AWS Transform for VMware | MAM202 | Level: 200 Type: Breakout session Date & Location: Wednesday, Dec 3 10:00 AM – 11:00 AM PST | Wynn Amazon EC2 への大規模な VMware 移行を実現する初の Agentic AI サービスである AWS Transform を紹介します。アプリケーション発見、依存関係マッピング、ネットワーク変換、ウェーブ計画、そして最適化された EC2 インスタンス選択によるサーバー移行を自動化する方法のライブデモをご覧ください。VMware インフラストラクチャをクラウドネイティブアーキテクチャにモダナイズしながら、ライセンスの課題とベンダーロックインを克服し、より迅速で確実な移行を可能にする方法を学びましょう。 Accelerating Cloud Migration with Agentic AI: Hands-on AWS Transform [REPEAT] | PEX307-R | Level: 300 Type: Builders’ session Date & Location: Wednesday, Dec 3 3:00 PM – 4:00 PM PST | Caesars Forum AWS パートナーが AI を搭載した AWS Transform を活用して、クライアントのクラウド移行ジャーニーを最適化する方法を紹介するセッションにご参加ください。このハンズオンセッションでは、高度な AI エージェントを活用して移行アセスメント、計画、そして AWS へのワークロード移動を加速する方法を学びます。パートナーの皆様は、プロンプトエンジニアリング戦略に関する貴重な洞察を得て、実用的なユースケースを探求し、1 時間以内での完全自動移行を目撃することができます。 AWS Transform for VMware と AWS Transform Assessments が、制御と可視性を維持しながら、合理化された移行サービスの提供にどのように役立つかを理解しましょう。AI を活用した移行プラクティスの最大化に関するインタラクティブなディスカッションのために、ご質問をお持ちください。 VMware to AWS modernization blueprint: Migrate, containerize, scale | MAM338 | Level: 300 Type: Workshop Date & Location: Wednesday, Dec 3 1:00 PM – 3:00 PM PST | Wynn このハンズオンワークショップでは、VMware から AWS への移行とワークロードのモダナイゼーションのための技術的なブループリントを提供します。VMware から Amazon EC2 、そしてコンテナへのジャーニーに沿って、より高速でスケーラブルな移行のために Agentic AI を備えた AWS Transform の使用する方法を学びます。ワークショップでは、 Amazon Elastic Kubernetes Service (Amazon EKS) を使用したコンテナ化、マイクロサービスの実装、そしてクラウドネイティブソリューションの開発を実演します。実証済みのVMware 移行経験を持つ AWS エキスパートが、アプリケーションアーキテクチャの再構築、インフラストラクチャの最適化、そしてイノベーションの加速についててガイドします。 Fast-Track your VMware to AWS Migration with AWS Transform | MAM316 | Level: 300 Type: Workshop Date & Location: Tuesday, Dec 2 12:30 PM – 2:30 PM PST | MGM このハンズオンワークショップでは、VMware ワークロードをクラウドネイティブソリューションに変換するための AI を搭載した AWS Transform の機能について学びます。自動化された発見、依存関係マッピング、インフラストラクチャ変換のための Agentic AI の実践的な経験を積み、効率的な移行計画のための AWS モダナイゼーション手法の使用方法を学びます。このセッションでは、レガシー VMware 環境を最適化されたクラウドネイティブアーキテクチャに変革することに焦点を当て、複雑さ、コスト、移行リスクを削減しながら AWS への投資を最大化するお手伝いをします。 Scale VMware migrations with Cloud Migration Factory & AWS Transform | MAM335 | Level: 300 Type: Workshop Date & Location: Thursday, Dec 4 3:30 PM – 5:30 PM PST | MGM このハンズオンワークショップでは、 AWS Transform と Cloud Migration Factory を使用した大規模な VMware 移行の自動化について学びます。発見、テスト、カットオーバープロセスにおいて手動作業を 90% 削減できる実証済みの自動化パターンの実践的な経験を積むことができます。簡素化された変更管理により、コンプライアンスに準拠した大規模移行を可能にする実践的なフレームワークを探求します。ご参加の際はノートパソコンを持参ください。 Accelerate migration of VMware workloads using Agentic AI | MAM408 | Level: 400 Type: Workshop Date & Location: Thursday, Dec 4 12:30 PM – 2:30 PM PST | MGM この技術的な詳細解説では、 AWS Transform を使用してサーバー移行ライフサイクルを最適化する方法を紹介します。AI を搭載したエージェントが、オンプレミス環境のインテリジェントな発見から AI 生成によるウェーブ計画とネットワークアーキテクチャまで、移行ジャーニーをどのように自動化し最適化するかを探求します。ハンズオン演習を通して、生成 AI 機能を活用し、Infrastructure as Code の自動作成とネットワーク変換を行う方法を学びます。実際のサーバー移行を体験し、AWS ジャーニー中のビジネス中断を最小限に抑える、最新の AI を活用した移行技術の実用的な知識を身につけて帰りましょう。 製品の詳細解説: Amazon Elastic VMware Service (Amazon EVS) Amazon Elastic VMware Service (Amazon EVS) セッションに参加して、アプリケーションのリプラットフォームやリファクタリングを行うことなく、 AWS 上で VMware ワークロード を実行する方法を学びましょう。これらのセッションでは、クラウドで VMware 環境を正常にデプロイし、スケールするために必要なすべてをカバーします。 A complete guide to Amazon EVS: Unlock AWS scale for VMware workloads | MAM201 | Level: 200 Type: Breakout session Date & Location: Tuesday, Dec 2 1:30 PM – 2:30 PM PST | MGM Amazon EVS は、リプラットフォームやリファクタリングの手間をかけることなく、VMware ワークロードを AWS にシームレスに移行する方法を提供します。このサービスにより、既存の VMware への投資と専門知識を保護しながら、AWS の堅牢なインフラストラクチャを活用できます。セルフマネージドを選択するか AWS パートナーと協力するかに関わらず、Amazon EVS は統合されたストレージ、バックアップ、災害復旧機能を備えた仮想環境をカスタマイズするための柔軟なオプションを提供します。プラットフォームの直感的なデプロイメントプロセスと継続的なイノベーションにより、クラウドジャーニーを最適化するために必要なツールと柔軟性を確実に得ることができます。 Amazon EVS Deep Dive: Advanced Networking and Storage Architecture | MAM401 | Level: 400 Type: Chalk talk Date & Location: Thursday, Dec 4 12:30 PM – 1:30 PM PST | MGM Amazon EVS は、クラウド仮想化スタックの構築において柔軟性を提供します。この詳細解説セッションでは、Amazon EVS 環境の高度なパターンに焦点を当て、ネットワークアーキテクチャ、VPC 間通信、そして高度なネットワーキング戦略をカバーします。また、環境をスケールする際のパフォーマンスとコストの最適化に役立つ高度なストレージアーキテクチャパターンについても探求します。 Amazon EVS Deep Dive: Strategic migration planning | MAM305 | Level: 300 Type: Chalk talk Date & Location: Wednesday, Dec 3 1:00 PM – 2:00 PM PST | MGM AWS の VMware ワークロードを Amazon EVS で実行するインタラクティブな技術セッションにご参加ください。最適な移行成功に向けた Amazon EVS 環境の設計と計画方法の紹介、技術的な前提条件、キャパシティ計画、ホスト配置オプションもカバーします。Amazon EVS とストレージ、バックアップ、災害復旧ソリューションを統合するためのベストプラクティスを学び、さらに他の AWS サービスとの接続によってクラウドデプロイメントを最大化する方法を紹介します。 Optimizing Storage costs for Amazon EVS with FSx for ONTAP (sponsored by NetApp) | MAM101 | Level: 100 Type: Breakout session Date & Location: Wednesday, Dec 3 1:00 PM – 2:00 PM PST | MGM Amazon EVS は、リプラットフォームを行うことなく VMware ワークロードを AWS にシームレスに移行することを可能にします。 Amazon FSx for NetApp ONTAP と組み合わせることで、高い TCO や複雑なデータ操作といった一般的な移行課題に対処します。この統合により、シームレスなデータ移行、自律型ランサムウェア保護、そしてオンプレミスソリューションで一般的に見られるエンタープライズ機能を備えた最適化されたストレージ利用を含む、エンタープライズグレードのデータ管理機能を提供します。AWS パートナーである NetApp 社による発表です。 Migrate from VMware to AWS: Cloud Operations Best Practices | COP325 | Level: 300 Type: Chalk talk Date & Location: Tuesday, Dec 2 4:30 PM – 5:30 PM PST | Mandalay Bay Amazon EVS を AWS のクラウド運用サービスを通じて最適化することに焦点を当てたインタラクティブセッションにご参加ください。 AWS Organizations 、 AWS CloudTrail 、 AWS Config 、 Amazon CloudWatch 、そして AWS Systems Manager がどのようにタスクを自動化し、可視性を向上させ、ガバナンスを強化し、移行を加速するかを探求します。移行プロセスを強化し、AWS でワークロードをより効率的かつ安全に実行するための実用的な戦略を習得できます。このセッションは、新しい移行と既存の Amazon EVS デプロイメントの最適化の両方にとって価値があります。 AWS re:Invent 2025 に向けた準備を始めましょう AWS re:Invent 2025 がもうすぐ開催されます。VMware ワークロードの AWS へのモダナイズと移行に成功した AWS エキスパートとお客様からの貴重な洞察が満載です。準備のためのチェックリストはこちら： AWS re:Invent 2025 に登録 re:Invent Portal でこれらのセッションを予約 #reInvent を使ってソーシャルメディアで会話に参加 AWS Events mobile app をダウンロード してスケジュールを作成 より深く学ぶ: AWS for VMware リソース 先取りするために、これらのリソースを探求しましょう： AWS for VMware AWS Transform for VMware Amazon Elastic VMware Service (Amazon EVS) AWS for VMware Partners 最新情報を入手 見逃さないでください！ @AWSreInvent をフォローし、お気に入りのソーシャルプラットフォームで #reInvent ハッシュタグをチェックしましょう。他の参加者とつながり、イベント前の興奮を味わうのに最適な方法です。 プロのヒント: セッションスケジュールは変更される場合があります。最新情報については、常に公式の AWS re:Invent Session Catalog を参照してください。 翻訳はソリューションアーキテクトの増田雄紀が担当しました。原文は こちら です。 Suhail Fouzan Suhail Fouzan は Amazon Web Services (AWS) のスペシャリストソリューションアーキテクトで、IT 業界で 15 年以上の経験を持っています。Microsoft ワークロード、移行サービス、そして AWS Systems Manager による運用管理を専門とし、お客様のインフラストラクチャの AWS への移行を成功へ導くサポートをしています。仕事以外では、Suhail はクリケットをプレイしたり、家族と時間を過ごしたりすることを楽しんでいます。 Bianca Velasco Bianca Velasco は AWS のプロダクトマーケティングマネージャーで、VMware ベースのワークロードの AWS への移行と変革に重点を置いています。マーケティングとテクノロジーの分野で 7 年以上の経験を持ち、複雑なテクノロジーをわかりやすく、そして共感しやすいものにするためのストーリー作りに情熱を注いでいます。AWS 以外では、Bianca はボランティア活動、ダンス、ボルダリングを楽しんでいます。 Yogi Barot Yogi Barot は AWS の ワールドワイドな Microsoft Tech リーダーで、AWS における Microsoft 技術フィールドコミュニティを率いています。彼女の役割の一部として、技術的な支援のためのコミュニティを主導し、お客様の Microsoft ワークロードの AWS への移行とモダナイゼーションをサポートしています。Yogi は 26 年にわたり、様々な Microsoft テクノロジーに携わってきた経験を持ち、特に SQL Server と様々なデータベーステクノロジーを専門としています。Yogi は AWS に関する深い知識と、AWS 上で Microsoft ワークロードを実行する専門知識を有しています。

みなさん、こんにちは。ソリューションアーキテクトの水野です。AWS ではサービスのアップデートだけでなく製造業の方に向けたイベントの開催や事例の発表などを頻繁に行っています。それらの情報を効率良くインプットしていただく為に、今月から日本の製造業のお客様に向けた情報発信を行っていきます。 このブログでは開催予定のイベントや直近1カ月に発表された製造関連のブログ・サービスのアップデート・事例などをお届けしています。国内だけでなく海外の情報も含めていますので、リンク先には英語の記事・動画も含まれていますが、解説を加えていますのでご興味あればぜひご覧ください。 ピックアップトピック AWS re:Invent 2025 が 12 月 1 日から 5 日までラスベガスで開催されます。毎年恒例の AWS re:Invent 速報も会期中の 2025 年 12 月 5 日 (金)に開催が決定しています。ご登録は こちら 。新しいサービスの発表も楽しみなのですが、沢山のセッションも行われます。そんな中、日本のメンバーも現地で Chalk Talk 「 Accelerating Smart Products SDLC with Amazon Q Developer (IND303) 」 に登壇します。Amazon Q Developer によるスマートプロダクト開発ライフサイクルの革新をテーマに、ハードウェア・組込みソフトウェア・アプリケーションを AI 支援のチケット駆動型ワークフローで統合する方法をご紹介します。ただ残念ながらオンライン配信もなく、現地も既にキャンセル待ちとなっています。ご興味あるお客様には個別にご紹介いたしますので担当営業までお声がけください。 直近で開催予定のイベント 11/19 – 21 EdgeTech+ 2025 一般社団法人 組込みシステム技術協会の主催でパシフィコ横浜で行われる EdgeTech+ 2025 に AWS も登壇します。基調講演では「 SDV Acceleratorが導く、車載ソフト開発の新たなステージ 」(19日)、 「 エッジとクラウドが織りなす製造業の未来 – AI エージェントがもたらすデジタル変革 」(21日)の２つで登壇します。テーマ別セミナーでは、「 コード生成を超えた AI エージェント活用で組み込み開発プロセスを効率化する実践手法 」(19日)、「 プロダクトの進化を導くためのエッジ AI の技術動向と AI 開発運用ソリューション 」(20日)の２つで登壇します。 IIFES 2025 製造業と社会インフラを支える制御・駆動・計測を軸に、デジタル化技術の展示会である IIFES が、東京ビッグサイトで行われます。AWS は三菱電機様のブースでパートナーとしてデモ展示を行います。ブース内でのセッションにも登壇予定です。ぜひ三菱電機様のブースへお立ち寄りください。 12/1 – 5 AWS re:Invent 2025 ピックアップトピックでも記載しましたが、今年もこの季節がやってきました！AWS における世界最大のイベントが AWS re:Invent です。毎年多くのサービス発表や機能拡張が発表されますが、私たちはこの期間は毎年寝不足になりながら、リアルタイムで視聴をするのが恒例行事となっています。製造業に関わるサービスやセッションについては、今後こちらのブログで発信しますのでご期待下さい。 製造関連ブログのご紹介 10/1 Hexagon Automates Manufacturing Standard Operating Procedures with AWS Generative AI このブログでは、Hexagon 社が AWS の生成 AI サービスを活用して、製造業・エネルギー業界の標準作業手順書（SOP）のデジタル化を自動化した事例を紹介しています。Amazon Bedrock を中心に、複数のAWSサービスを組み合わせたサーバーレスワークフローにより、従来の手作業プロセスを 90% 以上の精度で自動化。ドキュメント処理の時間を数日から数分に短縮し、コスト削減と業務効率化を実現した革新的なソリューションの構築方法が詳しく解説されています。 10/9 【自動車業界】SDV時代の車載ソフトウエア開発を支えるAWSソリューション（Vector SDV Symposium Japan 2025で発表） 2025 年 9 月 18 日に開催された「Vector SDV Symposium Japan 2025」にて、「SDV 時代の車載ソフトウエア開発を支える AWS ソリューション」というテーマで登壇した内容をより掘り下げてご紹介しています。このブログでは、 仮想開発環境や仮想 ECU 技術を使ったテストの効率化まで、AWS が提供するソリューションについて紹介しています。 10/10 Transform Supply Chain Logistics with Agentic AI このブログでは、AWS のプロフェッショナルサービスチームがシンガポールの A*STAR と協力して開発したロジスティクスエージェントを紹介しています。Amazon Bedrock を活用した AI エージェントは、ERP、TMS、WMS など複数のシステムからリアルタイムデータを集約し、自然言語での問い合わせに即座に対応。手作業による情報検索を最大 50 %削減し、配送コスト 3～5 %削減、顧客満足度向上を実現します。サプライチェーン全体での Agentic AI の活用可能性を示す実践的な事例を紹介しています。 10/14 AWS IoT Greengrass nucleus lite 窶・リソース制約のあるデバイスでエッジコンピューティングに革命を起こす AWS IoT Greengrass nucleus lite は、リソース制約のあるデバイスを対象とした軽量な オープンソース のエッジランタイムです。スマートホームハブ、スマートエネルギーメーター、スマートビークル、エッジ AI、ロボティクスなどの大量生産アプリケーション向けに、低コストのシングルボードコンピュータで AWS IoT Greengrass の機能を拡張できます。このブログでは、2つのエッジランタイムオプションの利点を説明し、ユースケースに最適なオプションを選択するための指針を提供しています。 10/16 株式会社マキタ様の AWS 生成 AI 事例「AWS 上の閉鎖型 AI 環境で労働災害報告書作成支援と経営ダッシュボードを内製開発。システム開発経験の少ないエンジニアが短期間でリリースを実現」のご紹介 このブログでは、 船舶用ディーゼルエンジンの製造・販売・アフターサービスを手がける株式会社マキタ様が AWS を用いて経営ダッシュボードと労働災害報告書作成支援 AI を「短期間」かつ「システム開発経験の少ないエンジニア主導の開発体制」で内製した事例についてご紹介しています。 10/24 Secure, remote monitoring and control of a PLC from AWS このブログでは、Inductive Automation の Ignition を使用して、遠隔地の PLC（プログラマブルロジックコントローラ）を AWS クラウドから安全に監視・制御するシステムの構築方法を詳細に解説しています。Teltonika RUT956 ルーターと AWS Site-to-Site VPN を活用した暗号化通信、AWS Private CA による証明書管理、BGP による自動フェイルオーバーなど、エンタープライズグレードの信頼性を備えた実装手順が段階的に説明されており、再生可能エネルギーやマイニング、石油ガス産業などの大規模産業ユーザーに適した設計について紹介しています。 10/29 How Sibros, Panasonic Automotive, and AWS Collaborate to Reduce Connected Services Integration Challenges During Vehicle Development このブログでは、Sibros、Panasonic Automotive、AWS が協力して、自動車の接続サービス統合の課題を解決する方法を紹介しています。仮想開発環境 vSkipGen ｢と Sibros の Deep Connected Platform を活用することで、自動車メーカーは物理ハードウェアを待たずに早期から統合テストを実施でき、開発期間の短縮とソフトウェア品質の向上を実現できます。OTA 更新やデータ収集などの機能も含まれており、グローバルな分散チームでの開発を加速させる方法について紹介しています。 イベント動画のご紹介 10/23 AWS at IAA MOBILITY 2025 – Highlights この動画は、2025 年 9 月 8 日から 12 日にかけてミュンヘンで開催された IAA MOBILITY 2025 における AWS の参加ハイライトを紹介しています。自動車産業における AWS の革新的なAIソリューションが展示され、特にエージェント型 AI アシスタントや自動車設計における AI 活用など、自動車業界の未来を形作る技術が紹介されました。 10/30 AWS Summit Paris 2025 – Comment accelerer sa transformation numerique industrielle このセッションは、AWS Summit Paris 2025 での「産業デジタルトランスフォーメーションの加速方法」に関する講演です。ゲストスピーカーとして Aremmon 社の Industry 4.0 責任者である Ali Ponlou 氏が、製造業におけるデジタルトランスフォーメーションの実践方法と事例について解説しています。特に POC 段階を超えて本格的な展開を計画している企業にとって、Aremmon 社の実例や段階的アプローチの解説は実践的な指針となります。また、産業データプラットフォームの構築方法や生成 AI の活用事例は、製造業の IT 部門と OT 部門の橋渡しを担当する技術者にとって参考になる具体的な実装方法を提供しています。 製造関連の主要なアップデート 10/14 AWS IoT SiteWise Edge データ処理パックと AWS IoT SiteWise Monitor がメンテナンスモードに 2025 年 11 月 7 日以降、新規のお客様は AWS IoT SiteWise Edge データ処理パックと AWS IoT SiteWise Monitor がご利用頂けなくなります。既存のお客様については、代替ソリューションを検討頂きながら、引き続きこれらのサービスや機能をご利用頂けます。また、Amazon Lookout for Equipment と AWS IoT Greengrass v1 については、サービスの運用とサポートを終了する日程が発表されています。これらのサービスをご利用中のお客様は、ドキュメントで推奨されている代替手段への移行を計画してください。 10/23 AWSのカスタマーカーボンフットプリントツール (CCFT) が、SCOPE 3 に対応 カスタマーカーボンフットプリントツール (CCFT)は、AWS が提供するツールで顧客が AWS の利用による炭素排出量を可視化・追跡できます。 今回 CCFT が更新され、SCOPE 3 排出量データに対応しました。これにより、サーバー製造、施設電力、機器輸送など、クラウド利用の全ライフサイクルにおける炭素影響を可視化できます。2022 年 1 月からの履歴データも利用可能で、組織のサステナビリティ目標達成に向けた戦略的な意思決定が容易になります。 10/31 AWS IoT Greengrass 開発者向け MCP サーバ AWS IoT Greengrass 向けの新しい MCP サーバが発表されました。このオープンソースツールは GitHub で公開されており、開発者が Amazon Q Developer などの AI コーディングエージェントを活用して、エッジデバイスアプリケーション開発を加速できます。テンプレートと例が含まれており、開発時間を短縮しながら、フリート全体への展開管理も簡素化できるのが大きなメリットです。9 月には AWS IoT SiteWise の MCP サーバも 発表 されています。 最後まで読んでいただきありがとうございました。いかがだったでしょうか？このような形式で毎月最新の情報を製造業の皆様にお届けして参ります。月刊 AWS 製造ブログを今後ともよろしくお願いします。それでは、また来月お会いしましょう！ 著者について 水野 貴博 水野貴博は、製造業のお客様をご支援しているソリューションアーキテクトです。サプライチェーン領域を得意としており、好きな AWS サービスは AWS Supply Chain です。趣味は、ドラマや映画のエキストラに参加することです。 <!-- '"` -->

データ分析者やエンジニアは、データベーススキーマを探索したり、テーブル構造を理解したり、さまざまな Amazon Redshift データウェアハウス間でクエリを実行するために、複数のツールを行き来することがよくあります。メタデータやデータを自然言語で探索できれば、このプロセスが簡素化されますが、AI エージェントは、最適な実行パスを探索して構築するために、Redshift クラスターの構成とスキーマの追加コンテキストを必要とすることがよくあります。 ここで Model Context Protocol (MCP) が AI エージェントと Redshift クラスターの橋渡しをし、データへの自然言語インターフェースをより適切にサポートするために必要な情報を提供できます。MCP は、AI アプリケーションが外部のデータソースやツールに安全に接続し、ユーザーの特定の環境に関する豊富なリアルタイムのコンテキストを提供できるようにする、オープンな標準規格です。静的なツールとは異なり、MCP を使えば AI エージェントが動的にデータベース構造を探索し、テーブル関係を理解し、Amazon Redshift 設定を完全に認識したうえでクエリを実行できます。 これらの課題に対処し、会話型データ分析の可能性を最大限に引き出すために、 Amazon Web Services (AWS) は、Amazon Redshift データウェアハウスとのインタラクションの仕方を革新するオープンソースソリューションの Amazon Redshift MCP サーバー をリリースしました。Amazon Redshift MCP サーバーは、 Amazon Q Developer コマンドラインインターフェース (CLI)、 Claude Desktop 、 Kiro 、およびその他の MCP 互換ツールとシームレスに統合されています。これにより、データベース環境を本当に理解する AI アシスタントとの自然言語会話を通じて、Amazon Redshift のメタデータとデータを発見、探索、分析できるようになります。 この記事では、Amazon Redshift MCP サーバーのセットアップ方法を説明し、データ分析者が自然言語クエリを使用して Redshift データ ウェアハウスを効率的に探索し、データ分析を行う方法を示します。 Amazon Redshift MCP サーバーとは Amazon Redshift MCP サーバーは、AI エージェントに Amazon Redshift リソースへの安全で構造化されたアクセスを提供する MCP 実装です。以下の機能を実現します: クラスター検出 – プロビジョニングされた Redshift クラスターとサーバーレスワークグループの両方を自動的に検出します メタデータ探索 – 自然言語でデータベース、スキーマ、テーブル、カラムを参照できます 安全なクエリ実行 – 組み込みの安全保護機能を備えた READ ONLY モードで SQL クエリを実行できます マルチクラスターサポート – データ照合タスクのために、複数のクラスターとワークグループを同時に操作できます MCP サーバーは、Amazon Q CLI とあなたの Amazon Redshift インフラストラクチャの間の橋渡しの役割を果たし、自然言語のリクエストを適切な API 呼び出しと SQL クエリに変換します。次の図は、高レベルのアーキテクチャを示しています。 前提条件 始める前に、次のものがあることを確認してください。 システム要件 Python 3.10 以降のバージョン uv パッケージマネージャ ( インストールガイド ) Amazon Q CLI または Claude Desktop のような MCP サポートクライアントツールがインストールされ、設定済みであること AWS の要件 AWS Command Line Interface (AWS CLI)、環境変数、または AWS Identity and Access Management (IAM) ロールを使用して設定された AWS 認証情報 Amazon Redshift へのアクセスに適切な IAM 権限 少なくとも 1 つの Redshift クラスターまたはサーバーレスワークグループ 必要な IAM 権限 ユーザー ID には、アクセスポリシーで以下の IAM 権限が必要です。 { &nbsp;&nbsp;"Version": "2012-10-17", &nbsp;&nbsp;"Statement": [ &nbsp;&nbsp; &nbsp;{ &nbsp;&nbsp; &nbsp; &nbsp;"Effect": "Allow", &nbsp;&nbsp; &nbsp; &nbsp;"Action": [ &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;"redshift:DescribeClusters", &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;"redshift-serverless:ListWorkgroups", &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;"redshift-serverless:GetWorkgroup", &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;"redshift-data:ExecuteStatement", &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;"redshift-data:BatchExecuteStatement", &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;"redshift-data:DescribeStatement", &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;"redshift-data:GetStatementResult" &nbsp;&nbsp; &nbsp; &nbsp; ], &nbsp;&nbsp; &nbsp; &nbsp;"Resource": "*" &nbsp;&nbsp; &nbsp;} &nbsp;&nbsp; ] } インストールと設定 次のセクションでは、Amazon Redshift MCP サーバーをインストールして設定するための手順について説明します。 必要な依存関係のインストール 次の手順に従って、必要な依存関係をインストールしてください: uv パッケージマネージャーをまだインストールしていない場合はインストールしてください: # macOS/Linux curl -LsSf https://astral.sh/uv/install.sh | sh # Windows powershell -c "irm https://astral.sh/uv/install.ps1 | iex" Python 3.10 以降をインストールしてください: uv python install 3.10 MCP サーバーの設定 MCP サーバーは、いくつかの MCP サポートクライアントを使用して設定できます。この記事では、Amazon Q Developer CLI と Claude Desktop を使用する手順について説明します。ホストマシンで Amazon Q Developer CLI を設定し、Amazon Redshift MCP サーバーにアクセスするには、以下の手順を実行してください。 Amazon Q Developer CLI をインストールしてください。 Amazon Q CLI 設定で Amazon Redshift MCP サーバーを設定します。 ~/.aws/amazonq/mcp.json にある MCP 設定ファイルを編集してください。 { &nbsp;&nbsp;"mcpServers": { &nbsp;&nbsp; &nbsp;"awslabs.redshift-mcp-server": { &nbsp;&nbsp; &nbsp; &nbsp;"command": "uvx", &nbsp;&nbsp; &nbsp; &nbsp;"args": ["awslabs.redshift-mcp-server@latest"], &nbsp;&nbsp; &nbsp; &nbsp;"env": { &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;"AWS_PROFILE": "default", &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;"AWS_REGION": "us-east-1", &nbsp;&nbsp; &nbsp; &nbsp; &nbsp;"FASTMCP_LOG_LEVEL": "INFO" &nbsp;&nbsp; &nbsp; &nbsp;}, &nbsp;&nbsp; &nbsp; &nbsp;"disabled": false, &nbsp;&nbsp; &nbsp; &nbsp;"autoApprove": [] &nbsp;&nbsp; &nbsp;} &nbsp;&nbsp;} } インストールの詳細については、Amazon Redshift MCP サーバーの README.md の インストールセクション を参照してください。 Amazon Q CLI を起動して、MCP サーバーが適切に設定されていることを確認します: q chat /tools Amazon Redshift MCP サーバーが正常に初期化されたことを、起動ログで確認してください。ホストマシン上で Amazon Q Developer CLI をセットアップし、Claude Desktop から Amazon Redshift MCP サーバーにアクセスするには、以下の手順を実行してください。 オペレーティングシステム用の Claude Desktop をダウンロードしてインストールします Claude Desktop を開き、左下のギアアイコンを選択して 設定 に移動します Developer タブを選択し、Amazon Q CLI 設定の手順 2 と同じ設定を追加して MCP サーバーを設定します MCP サーバー接続を有効にするために Claude Desktop を再起動します 新しい会話を開始し、 Show me all available Redshift clusters (利用可能な Redshift クラスターをすべて表示してください) と尋ねて統合をテストします (訳註: Amazon Q Developer CLI では日本語を使用して指示や質問を行うことも可能です。) 顧客購買分析のユースケース データアナリストが複数の Redshift クラスターにまたがる顧客の購買データを探索する必要がある実用的なシナリオを想像してみましょう。以下のウォークスルーでは、MCP サーバーがこのワークフローを簡素化する方法を示します。e コマース企業のデータアナリストとして、次の作業が必要です。 利用可能な Redshift クラスターを検出する データベース構造を調べて、顧客データと売上データを見つける 顧客の購買パターンを分析する ビジネスチームに向けて分析結果を生成する これらのタスクを実行するには、次の手順に従います。 Amazon Q に、利用可能な Amazon Redshift リソースを表示するよう依頼します: Show me all available Redshift clusters (利用可能な Redshift クラスターをすべて表示してください) Amazon Q は MCP サーバーを使用してクラスターを検出し、クラスター識別子やタイプ (プロビジョニングされたものかサーバーレスか)、現在のステータスと可用性、接続エンドポイントと設定、ノードタイプとキャパシティ情報などの詳細を提供します。 データの構造を探索して、データの構成を把握します: What databases and tables are available in the analytics-cluster? (どのデータベースとテーブルが analytics-cluster で利用可能ですか?) Amazon Q は、MCP サーバーを使用してクラスター内のオブジェクトを体系的に探索します: データを分析する前に、テーブルスキーマを把握します: Show me the structure of the customers and orders tables in analytics-cluster (analytics-cluster にある customers テーブルと orders テーブルの構造を表示してください) Amazon Q は MCP サーバーを使用して、テーブルの列を検査し、詳細なスキーマ情報を提供します。 自然言語クエリを使用して顧客の購買パターンを分析します: Analyze customer purchase pattern from analytics cluster. Show me the top 10 customers by total purchase amount and their buying frequency (analytics-cluster から顧客の購買パターンを分析してください。購入総額が最も多い上位10人の顧客と、その購買頻度を表示してください) Amazon Q は MCP サーバーを使用して適切な SQL クエリを実行し、インサイトを提供します。 MCP サーバーは、複数のクラスターにまたがってデータを分析できます: Compare customer acquisition costs between the analytics-cluster and marketing-cluster data. (analytics-cluster と marketing-cluster のデータ間で、顧客獲得コストを比較してください。) Amazon Q は MCP サーバーを使用して、適切な SQL クエリを実行し、analytics-cluster と marketing-cluster 間でデータを比較します。 ベストプラクティス MCP サーバーには、データとシステムパフォーマンスを保護するための重要な安全対策がいくつか備わっています。READ ONLY モードは、意図しないデータ変更を防ぐための重要な保護機能であり、ユースケースに応じてこの機能を有効にすることをお勧めします。さらにセキュリティを高めるため、サーバーには潜在的に有害な影響を与える操作を検証するクエリ検証メカニズムが実装されており、最適な安全性を確保するために user-in-loop 検証が推奨されています。リソース管理については、サーバーはパフォーマンスに影響を与える無制限のクエリを防ぐためにリソース制限を適用しており、ここでもユーザーインザループ検証を行うことで最良の結果が得られます。アクセシビリティの観点では、MCP 機能は Amazon Redshift Data API がサポートされているすべての AWS リージョンで幅広く利用可能であり、Amazon Redshift Data API サービスの既存のスロットリング制限に合わせてスロットリング制限が設定されているため、一貫したパフォーマンスと信頼性が確保されています。最良の結果を得るには、以下の推奨事項に従ってください。 ディスカバリから始める – クラスターやデータベースの構造、テーブルを探索することから始めます 自然言語を使う – 直接 SQL を書くのではなく、分析したいことを説明します 徐々に反復する – 複雑な分析を一歩ずつ構築します 結果を検証する – 重要な発見はビジネス担当者と相互確認します インサイトを文書化する – 重要なクエリと結果を将来の参照用に保存します 結論 Amazon Redshift MCP サーバーは、Kiro や Amazon Q CLI のようなエージェントツールを通じて自然言語によるデータ探索と分析を可能にすることで、データ分析者が Redshift クラスターとやり取りする方法を変革します。SQL クエリを手動で記述したり、複雑なデータベース構造を把握する必要がなくなるため、分析者はシンタックスやスキーマの探索に悩まされることなく、インサイトの生成に集中できます。一時的な分析を行うか、定期的なレポートを生成するか、新しいデータセットを探索するかにかかわらず、Amazon Redshift MCP サーバーは、データ分析ワークフローに強力で直感的なインターフェースを提供します。準備はできましたか? 以下の手順を行っていきましょう。 この投稿の設定手順に従って MCP サーバーをインストールしてください 自然言語クエリを使用して Amazon Redshift 環境を探索してください シンプルな分析から始め、徐々に複雑さを高めてください 自然言語の要約を使ってチームとインサイトを共有してください フィードバックを提供して、MCP サーバーの機能改善に役立ててください 各ユースケースで自然言語を使用するためのナビゲーションをするブログ記事をご覧ください: Implementing conversational AI for S3 Tables using Model Context Protocol (MCP) Accelerating development with the AWS Data Processing MCP Server and Agent Introducing MCP Server for Apache Spark History Server for AI-powered debugging and optimization AWS Announces Billing and Cost Management MCP Server Introducing enhanced AI assistance in Amazon SageMaker Unified Studio: Agentic chat, Amazon Q Developer CLI, and MCP integration 著者について Ramkumar Nottath Ramkumar は AWS のプリンシパルソリューションアーキテクトとして、データおよび AI サービスに重点を置いて活動しています。様々な顧客と協力して、スケーラブルで信頼性の高いビッグデータおよび分析ソリューションの構築を支援することを楽しみにしています。分析、機械学習、生成 AI 、データウェアハウス、ストリーミング、データガバナンスなどの様々な技術に関心を持っています。家族や友人と時間を過ごすことを大切にしています。 Rohit Vashishtha Rohit はテキサス州ダラスを拠点とする AWS のシニアアナリティクススペシャリストソリューションアーキテクトです。ビッグデータプラットフォームの設計、構築、リード、保守において20年の経験を持っています。AWS の幅広いサービスを活用して顧客の分析ワークロードを最新化し、最高のセキュリティとデータガバナンスを備えた最適なコストパフォーマンスを顧客が得られるよう支援しています。 翻訳はソリューションアーキテクトの小役丸が担当しました。原文は こちら です。

AWS では、 Amazon Relational Database Service (Amazon RDS) のデータベースパフォーマンスメトリクスを収集・分析するためのいくつかのサービスを提供しています。これには Amazon CloudWatch と CloudWatch Database Insights が含まれます。さらに、さまざまなツールを使用して Amazon RDS for PostgreSQL と Amazon Aurora PostgreSQL-Compatible Edition を監視するためのカスタムダッシュボードを作成できます (詳細については、 Create an Amazon CloudWatch dashboard to monitor Amazon RDS for PostgreSQL and Amazon Aurora PostgreSQL と Monitor Amazon RDS for PostgreSQL and Amazon Aurora PostgreSQL performance using PGSnapper をご覧ください)。 人工知能と機械学習 (AI/ML) の進歩により、データベース監視領域で ML 機能を使用する無数のソリューションが利用可能になっています。これらのツールは、パフォーマンスの監視のボトルネックから運用上の問題まで、幅広い機能を提供します。また、問題をプロアクティブかつリアクティブに解決するための規範的な推奨事項も提供します。 このブログでは、セルフマネージドの Amazon RDS for PostgreSQL や Amazon Aurora PostgreSQL などのマネージドデータベースサービスを使用して、PostgreSQL 向けの人工知能と機械学習 (AI/ML) を活用したデータベース監視ツールについて探求します。 監視に関する考慮事項 このセクションでは、すべてのデータベースにとって重要なメトリクスについて説明します。これらのメトリクスは、ワークロード、データベースパラメータ、およびパフォーマンスに影響するその他の要因の変化を比較およびベンチマークするための履歴情報を保持するために、定期的に監視する必要があります。次の表は、AWS マネージドデータベースで監視することを推奨するメトリクスを示しています。 監視のソース パラメータ/メトリクス Amazon CloudWatch Database Connections CPU Utilization Freeable Memory FreeStorageSpace ReadLatency, WriteLatency DiskQueueDepth ReadIOPS, WriteIOPS WriteThroughput, ReadThroughput ReplicaLag OldestReplicationSlotLag ReplicationSlotDiskUsage MaximumUsedTransactionIDs Amazon CloudWatch Database Insights DatabaseLoad IO Latency EBS IO LongestIdleInTransaction CPU Utilization (%) Sessions Tuples Transactions, Transaction in progress IO cache vs Disk read Deadlocks OS Processes pg_stat_progress_vacuum Vacuum progress pg_stat_activity state of the query/idle_in_transaction 完全なリストについては、 拡張モニタリングの OS メトリクス 、 RDS PostgreSQL の SQL 統計 、 Amazon RDS for PostgreSQL の CloudWatch Database Insights カウンター 、 Vacuum Progress Reporting 、 pg_stat_activity を参照してください。 ここでは、AI/ML ベースのデータベース監視およびトラブルシューティングツールである PI Reporter について、その機能とユースケースを含めて説明します。 PI Reporter は、AWS ソリューションアーキテクトが開発したオープンソースツールで、パフォーマンスメトリクスとワークロードスナップショットを取得し、 Amazon Aurora PostgreSQL-Compatible Edition の詳細な比較レポートを生成し、 Amazon Bedrock の支援によるオプションのレポート分析を提供します。 PI Reporter PI Reporter は Amazon Bedrock と統合し、 Anthropic の Claude や Amazon Nova モデルなどの大規模言語モデル (LLM) の機能を活用して、個別のスナップショットと比較データを分析します。必要なモデルにアクセスできることを確認してください。この分析により、スナップショットウィンドウで発見されたデータベースパフォーマンスの問題に対する包括的な要約、根本原因分析、実行可能な推奨事項が生成されます。 PI Reporter では、以下のことが実行可能です : インスタンス関連情報の包括的な HTML レポートを数分で取得 定期的なレポートを比較して、パフォーマンス、ワークロード、または設定の変更を検出 インスタンスがワークロードを処理できるかを評価し、適切なサイジングのニーズを特定 システムセキュリティを損なうことなく、サードパーティとインスタンス統計を共有 根本原因の特定と推奨事項を含む LLM 分析を受信 このツールは、さまざまなシナリオで活用できます。一般的な例をいくつか紹介します。データベースのパフォーマンスが突然低下した場合、PI Reporter は影響を受けた期間と、通常のデータベースアクティビティを示す比較可能な期間の両方のスナップショットを取得できます。HTML 比較レポートは、何が変わったのか、そして考えられる根本原因を即座に表示します。 もう 1 つの有用なユースケースは、計画通りにデータベースを変更した後のワークロードの変化を評価することです。これには、新しい主要なアプリケーションをリリースする場合、データベースのメジャーバージョンにアップグレードする場合、ブルーグリーンデプロイメントを使用して新しいクラスターに移行する場合、またはその他の重要な変更を行う場合などの状況が含まれます。これらのシナリオでは、変更前後にスナップショットを取得して比較レポートを生成できます。 Amazon Aurora PostgreSQL Serverless インスタンスの監視において、PI Reporter は、予想される ACU 使用パターンと予想外の ACU 使用パターンの期間を比較することで、予想外の高い Aurora Capacity Units (ACU) 使用量の原因を特定するのに役立ちます。 これらの例は、このツールを活用できる方法のほんの一部を示しています。パフォーマンスの比較と分析が必要なあらゆるシナリオに可能性が広がります。 このツールは軽量で使いやすいように設計されています。 Amazon Elastic Compute Cloud (Amazon EC2) またはオンプレミスで Node.js スクリプトとしてデプロイできます。Linux x86 システム用にコンパイルされたポータブル版のスクリプトも含まれています。PI Reporter のセットアップの詳細については、 GitHub リポジトリ を参照してください。 ソリューション概要 次の図は、AWS サービスを使用した PI Reporter アーキテクチャを示しています。 このソリューションの動作方法を説明します。4 つのレイヤーで構成されています : データ収集レイヤー: Amazon CloudWatch Database Insights は、インスタンスレベルのカウンターパフォーマンスメトリクスと SQL レベルのメトリクスを提供します Amazon CloudWatch は、インフラストラクチャとリソースのメトリクスを提供します Amazon RDS は、メタデータとデータベースログファイル情報を提供します 処理レイヤー: PI Reporter ツールは、すべてのデータソースからデータを集約します 適切な権限を持つインスタンスロールが必要で、pireporterPolicy.json IAM ポリシーを通じて設定されます このツールは収集されたデータを処理し、統合されたメトリクスを含む JSON スナップショットファイルを生成します 分析レイヤー: 高度な分析のために、このソリューションは Amazon Bedrock と統合されます システムは、パフォーマンスメトリクス、リソース使用率データ、ワークロード情報 (SQL 統計を含む) を関連する知識と組み合わせて Amazon Bedrock に送信します Amazon Bedrock の LLM 機能は以下を提供します: 包括的な要約 詳細な分析 実行可能な推奨事項 出力: 最終的な出力は、生のメトリクスと LLM による洞察の両方を含む HTML レポートとして生成されます このアーキテクチャは、適切な IAM ロールと権限を通じてセキュリティを維持しながら、包括的なパフォーマンス監視と分析を確保します 前提条件 PI Reporter は Amazon CloudWatch Database Insights からの情報を使用するため、まず Amazon CloudWatch Database Insights を有効にする必要があります。 以下は、チューニングとトラブルシューティングツールに共通する PostgreSQL 固有の要件です : pg_stat_statements 拡張機能を有効にして、クエリごとの統計情報を収集します。この拡張機能は、Aurora PostgreSQL ではデフォルトで有効になっています デフォルトでは、PostgreSQL データベースは 1,024 バイトを超えるクエリを切り捨てます。ログに記録されるクエリサイズを増やすには、DB インスタンスに関連付けられた DB パラメータグループの track_activity_query_size パラメータを変更します。このパラメータを変更する場合、データベースの再起動が必要です 詳細については、 GitHub リポジトリ を参照してください。 PI Reporter のインストールと実行 PI Reporter は使いやすいように設計されています。Linux OS を搭載した Amazon EC2 上、または Aurora PostgreSQL クラスターが実行されている AWS リージョンにアクセス可能なオンプレミスの Linux ホスト上で、 GitHub リポジトリ からダウンロードできます。 PI Reporter をインストールするには、以下の手順を実行します : リポジトリをローカルファイルシステムにクローンします : git clone https://github.com/awslabs/pireporter.git リポジトリをクローンした後、 pireporter ディレクトリ内に pireporterPolicy.json AWS Identity and Access Management (IAM) ポリシーファイルがあります。このポリシーには、PI Reporter を実行するために必要な権限が含まれています。これらの権限は読み取り専用で、必須のもののみが含まれています。このポリシーにより、 pireporter:allow タグが付いたインスタンスとクラスターのみにアクセスできます。制限条件を緩和したい場合は、提供されたポリシーファイルを変更できます。 pireporterPolicy を、ツールを実行する予定の EC2 インスタンスのインスタンスロールにアタッチします。オンプレミスの Linux ホストでツールを実行する場合は、共有認証情報ファイル ~/.aws/credentials でアクセスキーとシークレットキーを使用します。EC2 インスタンスに最新バージョンの AWS CLI をインストールして、プログラムで RDS インスタンスに接続します。PI Reporter で使用される AWS SDK は、ロード時にポリシーファイルを自動的に読み取ります。この場合、ポリシーはアクセスキーが適用される IAM エンティティにアタッチされている必要があります。AWS リージョンは、インスタンスメタデータに基づいて、ホスティング EC2 インスタンスのリージョンに自動的に設定されます。特にオンプレミスでツールを実行する場合は、AWS_REGION 環境変数を希望の値に設定することで、これをオーバーライドできます ツールを実行するには 2 つのオプションがあります : Node.js を使用して pireporter ツールを実行するには、レポートを生成したいホストに Node.js がインストールされている必要があります : cd pireporter npm install node pireporter.js --help ポータブル版を使用する場合（ホストに Node.js をインストールしたくない場合）は、次のコマンドを使用します : cd pireporter/portable ./pireporter --help 特定の期間のスナップショットを生成するには、次のコマンドを使用します : ./pireporter --create-snapshot --rds-instance myinstance --start-time 2025-01-20T10:00 --end-time 2025-01-20T10:15 --comment "Unusually slow inserts" 上記の例では、 create-snapshot コマンドが疑わしいアクティビティや異常な動作を観察した 15 分間の時間間隔のデータをキャプチャします。そうでない場合は、終了して次のメッセージを出力します : No performance data available from Performance Insights for the selected time frame. Please choose a time frame with application load or user activity. これは、指定した時間枠によって数秒から 1 分程度かかる場合があります。メトリクスの平均値の希釈を減らすために、スナップショットの境界を関心のある期間に制限してください。このコマンドは、snapshots サブフォルダに JSON スナップショットファイルを生成します。 --comment 引数を使用すると、生成されたスナップショットにコメントを関連付けることができます。このコメントは LLM に渡され、その推論動作に影響を与える可能性があります。 キャプチャしたスナップショットに対して生成 AI 分析と推奨事項を含む HTML レポートを生成するには、次のコマンドを使用します : ./pireporter --create-report --snapshot snapshot_myinstance_202501201000_202501201015.json --ai-analyzes --ai-analyzes 引数は、Amazon Bedrock によって提供される LLM の分析を HTML レポートに含めます。レポートは reports サブフォルダに保存されます。 ツールで使用される LLM (リージョンとモデル ID) は、 conf.json ファイルで確認できます。Converse API をサポートする Amazon Bedrock の LLM を使用できます。 考慮事項と推奨事項 PI Reporter はインスタンスの動作の変化を特定して問題検出フェーズを最小化するために作成されたため、2 つのスナップショットを生成することを推奨します : インスタンスが異常な動作をしている問題のある期間 インスタンスが正常に動作していた類似の期間 次に --create-compare-report を使用して比較 HTML レポートを生成します。これにより、大幅に変更されたメトリクスと SQL を確認できます。 比較期間レポートの生成 AI 分析は、両方の期間のデータがあることで、より洞察に富んだものになります。両方の期間は以下の要件を満たす必要があります : 両方の期間は同じ長さである必要があります 問題のあるスナップショットは、問題が開始した時点から開始する必要があります 問題のあるスナップショットは、問題が終了した時点で終了するか、問題がまだ存在する場合は開始時刻から 60 分など合理的な時間後に終了する必要があります また、スナップショットに意味のあるコメントを提供することも検討してください。LLM に対して、特定の領域に注意を向けるよう指示したり、ユーザーとしての観察結果を伝えるなどのヒントを提供できます。 生成 AI は幻覚を起こしたり、間違った仮定を提供したりする可能性があります。私たちは、有用なデータベースエンジン固有の知識を含む追加のコンテキストを LLM に提供することで、これを最小限に抑えるよう努めました。生成 AI 分析は、それらを評価できるデータベース専門家と組み合わせて使用することをお勧めします。 レポートの解釈 LLM が生成するレポートの部分は、HTML レポートの上部にある薄い青色のボックスに表示されます。生成 AI セクションは一般的な要約から始まり、主な発見事項と問題の根本原因 (ある場合) が含まれます。 一般的なレポートサマリーの後に、レポートの各セクションのサマリーが表示されます。これには、一般的なインスタンス設定、非デフォルトパラメータ、待機イベント、OS メトリクス、DB メトリクス、および DB インスタンスの全体的なネットワークスループットなどの追加メトリクスが含まれます。これらは他の統計情報と SQL セクションから計算されます。スナップショット作成時に --include-logfiles 引数が指定されていた場合、レポートにはスナップショット期間のデータベースログファイルの分析も含まれます。 次のスクリーンショットは、ユースケース用に生成されたレポートからの生成 AI 分析のサマリーセクションを示しています。サマリーには、CPU、メモリ、ネットワークスループットなどの非常に高いリソース使用率に関するいくつかの観察結果が含まれています。また、高負荷の原因となっているワークロードタイプ（ insert ステートメントやその他の書き込みアクティビティ）に関する情報も取得できます。さらに、 public.employee テーブルでの insert と autovacuum アクティビティという 2 つの SQL ステートメントが表示されます。SQL 参照 ID を選択すると、完全な SQL テキストを表示できます。レポートでは、パフォーマンス問題の根本原因も提供されます。 一般的な要約の次のセクションは、推奨事項セクションです。このセクションには、問題の根本原因を修正するために LLM が生成したステップが含まれています。この特定のケースでは、LLM は観測されたワークロードを処理できる推奨インスタンスタイプの 1 つにインスタンスをスケールアップすることを推奨しています。また、ワークロードを確認し、システムへの影響を減らすために特定の autovacuum パラメータを調整することも推奨しています。 リアクティブユースケース: バルクデータインサート このセクションでは、データベースでバルクデータロードを実行し、CPU、ディスク、IOPS、ネットワークなどの異なるリソースの使用率を観察するユースケースについて説明します。リソースの使用率が高くなると、アクティブまたはパッシブアラートがトリガーされる可能性があるため、リソースが過度に使用されており、アップグレードが必要であることを理解できます。 バルクデータインサートの前提条件 このユースケースを検証するには、データを一括挿入するテーブルが必要です。例えば、以下のコードを参照してください。 BEGIN ; CREATE TABLE employee( emp_id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY, name TEXT NOT NULL ); COMMIT ; バルクデータインサートのユースケース 以下のコードを使用してバルクインサートを実行します : BEGIN ; INSERT INTO employee (name) SELECT substr(md5(random()::text), 1, 12) FROM generate_series(1, 100000000) AS _g ; ANALYZE ; COMMIT ; このテストケースでは、 employee テーブルに大量のデータを挿入するために、前述の INSERT 文を 100000000 の件数で実行しました。これにより 500 MB のデータが作成され、テーブルに挿入されました。 次に、PI Reporter を使用して AI/ML ベースのレポートを作成するには、以下のコマンドを実行します : ./pireporter --create-snapshot --rds-instance myinstance --start-time 2024-10-15T09:00 --end-time 2024-10-16T08:00 --comment "Bulk inserts" ./pireporter --create-report --snapshot snapshot_myinstance_202410150900_202410160800.json --ai-analyzes ここで、 --start-time と --end-time パラメータは、insert 文の実行前のタイムスタンプと insert 文の完了後のタイムスタンプに対応する必要があります。レポートが生成されたら、HTML レポートファイルを開いてレポートを読むことができます。次の推奨事項が表示されます : レポートの最初の部分では、レポートの開始時刻と終了時刻、およびレポートが生成された総期間の詳細が表示されます。次に、インスタンスの高レベルな詳細と、一括実行した insert 文などのリソース使用率上昇の責任または主要な原因が示されます。パフォーマンスに影響を与えるクエリと、定期的な vacuum および checkpoint チューニングの必要性が強調されています。 同じ情報が上記の推奨事項セクションに記載されていますが、ポイントごとの詳細が含まれています。 推奨事項の最初の部分は、インスタンスの一般情報に関するもので、従っている高可用性プラクティス、設定されているバックアップと監視オプションが含まれます。次のセクションには、レポート期間のメモリと CPU 使用率に関する静的メトリクスが含まれます。最後のセクションは、存在する場合のデフォルト以外のパラメータに関するものです。 AI によって生成されたレポートの分析では、リソース使用率と IO イベントに関する洞察が提供されます。また、インスタンスの現在のサイズ、使用率、推奨される適切なインスタンスタイプについても説明されています。さらに、CPU 使用率、ディスク IO、メモリ、ネットワーク、スワップ使用量などの重要な OS メトリクスも提供されます。この場合、リソースが十分に活用されていなかったため、コスト最適化のために適切なインスタンスタイプを選択することが推奨されました。これらの推奨事項を生成する際は、レポートを生成する期間を十分に長く設定することを確認してください。実装前に、データベースの専門家と推奨事項を検証してください。 上記の画像のデータベースメトリクスに関する推奨事項は価値があります。バルクインサートトランザクションアクティビティ、チェックポイントチューニング、定期的なバキュームに関する提案が含まれているためです。 最終的な GenAI 分析では、インスタンスを十分に活用できていないことに関するインサイトが提供されますが、ダウンサイジングを実行する前に、インスタンスのパフォーマンスを総合的に確認することを強く推奨します。CPU、ネットワーク帯域幅、効率的なキャッシュ、ディスク IO、チェックポイント、autovacuum などの要素を考慮してください。これらの洞察はすべて、データベースパフォーマンスの最適化において価値があります。統合された推奨事項では、クエリ最適化、インスタンスアップグレード、削除保護、バックアップ保持、高可用性のためのリーダーインスタンスの追加がカバーされています。 アイドルトランザクションのユースケース PI Reporter ツールは、スナップショットを使用して収集されたデータで動作します。アイドル状態のトランザクションセッションがあるスナップショットで収集された統計は、最終レポートで報告されます。アイドル状態のトランザクションを自動的に終了し、リソースの保持を防ぐために、 idle_in_transaction_session_timeout パラメータを 300 秒 (5 分) の値で実装することを推奨します。 上記の画像では、PI Reporter がトランザクション内でアイドル状態のセッションを明確に特定し、関連するパラメータに適切な値を設定することを推奨しています。また、コミットやロールバックのないトランザクションブロックを見つけるために、アプリケーションコードを確認することも提案しています。5 分以上アイドル状態のトランザクションに対する監視アラートを設定することを推奨しており、これにより、そのようなトランザクションを終了したり、データベースリソースの大部分を消費し始める前に問題を修正したりできます。Amazon CloudWatch Database Insights は、Database Telemetry -&gt; Metrics オプションの下で、最大アイドルトランザクションメトリクスを提供します。 データベースメトリクスセクションでは、セッションがトランザクション内でアイドル状態になっている概算時間を確認できます。最後の Analysis セクションでは、パフォーマンスの向上とコスト最適化のためのインスタンス全体の推奨事項をまとめています。 クリーンアップ Amazon Bedrock によって作成された AWS リソースは、使用している限りコストが発生します。生成 AI 分析を含むレポートを生成するたびに、PI Reporter は特定の呼び出しで使用された入力トークンと出力トークンの数を出力します。リソースが不要になったら、関連するサービスとスクリプトを削除してクリーンアップしてください。この投稿に従ってテスト環境を作成した場合は、使用が完了したらリソースをクリーンアップしてください。 機能の概要 次の表は、PI Reporter ツールの機能の概要を示しています。 パラメータ/機能 PI Reporter クラウドに依存しない No オンプレミスデータベース No 設定の推奨事項 Yes データベースの健全性 Yes インデックスの推奨事項 Yes 非効率な SQL Yes Autovacuum Yes パフォーマンスチャート No エージェントタイプ No 本番環境対応 Yes コスト Apache-2.0 ライセンス インフラストラクチャと Amazon Bedrock に関連するコスト *デプロイメントオプション、データベースフリートのサイズ、複数年契約などの要因が最終的なコストに大きく影響します。 まとめ この投稿では、PI Reporter ツールの監視機能と可能なユースケースについて説明しました。PI Reporter は数秒で有用な情報を収集し、JSON スナップショットに保存できます。これらは HTML レポートの生成や将来の調査のための保存に使用できます。これは、トラブルシューティングや DB インスタンスの健全性を理解するのに役立つツールです。Amazon Bedrock でホストされている LLM と組み合わせて使用することで、利用可能なメトリクスと SQL を分析し、生成 AI に調査結果の要約、問題の根本原因の検出、推奨事項の提供を行わせることができます。 この記事で説明した PI Reporter ツールには独自の機能があり、お客様のワークロードに適合する場合もあれば適合しない場合もあるため、慎重にテストと評価を行う必要があります。本番環境で実行する前に、非本番環境でこれらのツールをテストすることを強く推奨します。 皆様のフィードバックをお待ちしています。ご質問やご提案がございましたら、コメント欄でお聞かせください。 著者について Sachin Kotwal Sachin はAWSにおいてマイグレーションとモダナイゼーションを専門とするデリバリーコンサルタントです。お客様と連携し、様々なデータベースおよびマイグレーション・モダナイゼーションプロジェクトに関するガイダンスと技術支援を提供しています。これまでに数多くの同種データベース移行やパフォーマンス最適化プロジェクトに携わってきました。 Aychin Gasimov Aychin はAWSにおいてデータとAIを専門とするシニア・パートナー・ソリューション・アーキテクトです。彼は顧客やパートナーと連携し、様々なデータベース、アナリティクス、AIプロジェクトに関するガイダンスと技術支援を提供しています。 HariKrishna Boorgadda HariKrishna はAmazon Web Servicesのプロフェッショナルサービスチームに所属するシニアデリバリーコンサルタントです。AWSへのデータベース移行を専門とし、顧客と連携してAmazon RDSおよびAmazon Auroraのアーキテクチャ設計と実装を担当しています。 Sachin Khanna Sachin はAWSプロフェッショナルサービスチームにおいて人工知能および機械学習（AI/ML）を専門とするリードコンサルタントです。データ管理、生成AI、大規模言語モデル、機械学習における豊富な経験を持ち、データ、データベース、AI駆動型ソリューションに関わるプロジェクトに幅広い専門知識を提供します。クラウド移行とコスト最適化における熟練したスキルにより、顧客のクラウド導入プロセスを成功へと導き、カスタマイズされたソリューションと戦略的洞察を提供しています。 翻訳は、ソリューションアーキテクトの鈴木が担当しました。 原文 はこちらです。

本記事は 2025 年 10 月 27 日に AWS Public Sector Blog で公開された Building large language models for the public sector on AWS を翻訳したものです。翻訳はソリューションアーキテクトの川戸渉が担当しました。 大規模言語モデル (Large Language Model, LLM) は、公共機関によるサービス提供、市民とのエンゲージメント、データに基づく意思決定の方法を根本から変えています。高度な多言語対応と複雑なタスクの自動化により、LLM は応答時間を短縮し、ドメイン固有の情報を大規模に処理することが可能になります。 既製のモデルは確かに強力ですが、公共機関特有の規制要件、文化的背景、業務上の条件を十分に満たすことができないケースが少なくありません。多くの商用 LLM は、インターネット全体から収集された幅広いデータセットで学習しているため、特定の国や分野における言葉のニュアンス、文化的文脈、法規制の枠組みを適切に反映していないことがあります。また、これらのモデルは学習データに含まれるバイアスを引き継いだり、専門用語の知識が不足していたり、データ主権やプライバシー保護の要件を満たせない環境で動作したりする課題があります。正確さ、コンプライアンス、信頼性が極めて重要な公共機関にとって、これらの制約は市販モデルをミッションクリティカルな用途で使用する上での限界となっています。カスタム LLM 開発はこれらの課題に対処します。ゼロからのモデル学習、既存モデルの継続事前学習、事前学習済みモデルのファインチューニングによって、言語やドメイン固有の知識を取り込み、地域の法規制に準拠し、文脈に応じた微妙なニュアンスにも対応できるようになります。 公共部門のミッションに特に関連する 2 種類のカスタム LLM があります : ナショナル LLM は、特定の国や地域の言葉の使い方、文化的背景、法規制の枠組みを反映するように構築されたモデルです。地域言語の保全、文化に適した回答の生成、国のデータ主権要件への準拠を可能にします。顕著な例として、 ギリシャの取り組み があります。これは商用モデルにおけるギリシャ語の過小表現に対処し、現代および古典ギリシャ語の言語遺産を保全するオープンウェイト LLM (モデルの重みパラメータが公開された LLM) の開発を進めている事例です。 ドメイン特化型 LLM は、医療、教育、金融、法務などの高度に専門化された分野向けに最適化されたモデルです。専門性の高い業務においてより高い精度と、分野固有の専門用語もしっかりと理解できます。これらのモデルは、品質と適切性を保ちながら、ドメインに特化することで専門的なコア業務をどれだけ向上させられるかを示しています。 このブログ記事では、公共部門での活用を想定したカスタム LLM の開発について、科学的アプローチと定量的な成果評価を軸に、そのライフサイクル全体を解説します。開発プロセスは 6 つの重要なステージで構成されています。各ステージは、セキュリティ、コンプライアンス、パフォーマンスの厳格な基準を満たしながら、モデルが本来の目的を確実に果たせるように設計されています。 コスト分析フレームワーク カスタム LLM 開発に着手する前に、2 つのレベルでコストを評価する必要があります。マネージド API のトークン単価と、セルフホスティングの総保有コスト (Total Cost of Ownership, TCO) です。 マネージド API は迅速な導入に適していますが、トークン課金とデータ転送コストにより、規模が大きくなると高額になる可能性があります。一方、セルフホスティングでは、初期投資（GPU 調達や予約容量、エンジニアリングリソース）に費用がかかりますが、時間の経過とともにトークンあたりの運用コストは下がります。 モデルサイズはコストに大きく影響します。一般的に、パラメータ数が多いほど、一定レベルまで品質が向上しますが、応答時間、メモリ使用量、学習・推論コストも増加します。継続事前学習や目的特化型のファインチューニングによってモデルサイズを調整することで、コストを抑えながら同じレベルの性能を実現できます。 適切なデプロイ方法を決定するには、まず 1 日あたりのトラフィック (トークン / 日)、季節変動、目標応答速度、システムの可用性要件を把握する必要があります。その上で、API 利用料の累計がセルフホスティングの TCO (機器の減価償却費、電気代、運用費を含む) を超えるポイントを計算することで、データに基づいた選択ができるようになります。多くの公共機関では、自組織のクラウド環境で運用する中規模の調整済みオープンソースモデルが最も適した選択肢となります。これにより、データレジデンシー (データが保存される地理的な場所) 要件を満たしながら、より少ない GPU で目標の応答速度を実現し、初期投資の後は長期的な運用コストを抑えることができます。 カスタム LLM 開発のプロセス カスタム LLM の開発ステージは以下の通りです： ユースケースと要件の定義 評価フレームワークの確立 モデル選択と学習アプローチ データ収集と準備 インフラストラクチャ構築と学習アプローチ 本番環境へのデプロイと性能テスト 各ステージは、公共部門が求めるセキュリティ、コンプライアンス、性能基準を満たしながら、モデルが意図された目的を効果的に果たすための基盤となります。 ステージ 1: ユースケースと要件の定義 カスタム LLM 開発は、厳密な要件定義から始まります。これは、組織のハイレベルな目標を具体的で測定可能な仕様に落とし込む作業です。このステージでは、カスタムアプローチが必要なのか、それともプロンプトエンジニアリングのみで目標を達成できるのかを決定します。 カスタムアプローチは通常、プロンプトエンジニアリングを複数回試行しても一貫して許容できる結果が得られない場合、既存のモデルでは特定の言語要件を満たせない場合、または標準的なプロンプト技術では確実に活用できない深い専門知識を必要なユースケースがある場合に必要となります。 要件定義プロセスは、カスタム LLM が明確な価値を提供する具体的なユースケースを特定することから始まります。政府機関では実用的な活用方法を検討する必要があります。例えば、市民参加型プラットフォーム、政策分析システム、専門的な研究ツール、行政業務の自動化などです。最近の事例からも、このステージの重要性がよくわかります。ギリシャのナショナル LLM プロジェクトでは、現代ギリシャ語と古代ギリシャ語の両方を処理しながら、英語でも高い性能を維持するという明確な要件を定義し、公共部門のさまざまな分野での活用を可能にしました。 組織は、明確な成功指標を設定する必要があります。具体的には、サービス提供時間の定量的な改善、専門タスクの精度、市民満足度スコアなどが挙げられます。技術要件については、目標応答時間、想定されるクエリ量、既存の行政システムとの統合ニーズに対応する必要があります。 また、包括的なデータ処理プロトコル、アクセス制御、監査要件の定義も不可欠です。ナショナル LLM の場合、データ主権に関する要件やローカルホスティングの要件が含まれることが一般的です。ドメイン特化型モデルでは、医療、金融、その他の機密性の高い分野における専門的な規制への準拠が求められる場合があります。 これらの要件を文書化することで、ステークホルダーに対してビジネス価値を効果的に伝えられるだけでなく、技術チームには明確な開発ガイドラインを提供できます。この文書化は、複数の政府部門や機関間での調整を行う際に特に重要であり、技術的能力と組織ニーズの整合性を確保する上で欠かせません。 ステージ 2: 評価フレームワークの確立 モデル選択前にしっかりとした評価フレームワークを確立することで、開発プロセス全体を通して科学的な厳密さと測定可能な成果を確保できます。このフレームワークは、その後のすべての意識決定の基盤となり、主観的な選択によってプロジェクトが失敗するリスクを防ぎます。 ベースライン性能と適応率の指標 モデル選定と学習の決定を左右する 2 つの重要な指標があります : ベースライン性能 (b) : 候補モデルをカスタマイズする前の、タスクおよびドメイン固有の評価スコアです。固定プロンプトと別途用意した開発 / テスト用データセットを使用します。これにより、異なるベースモデルを客観的に比較する基準が得られます。 適応率 (ra) : カスタマイズ中にモデルが評価指標をどれだけ速く効率的に改善できるかを示す指標で、学習の進捗 (ステップ数、トークン数、時間、コスト) で正規化されます。この指標により、限られた予算内で継続学習に最も適したモデルを予測できます。 評価ツールと実装 Language Model Evaluation Harness (LM Harness) は、LLM 評価の業界標準ツールです。60 以上の学術的ベンチマークと数百のサブタスクおよびバリアントでモデルをテストできる統一フレームワークを提供してます。LM Harness は、Hugging Face transformers、高速推論用の vLLM 、商用 API など、さまざまなモデル環境に対応しており、異なる実装でも同じ条件で比較できます。 AWS を中心としたワークフローでは、LM Harness を AWS が提供する評価ツールで補完しながら、業界標準との互換性も保てます。LM Harness を基盤とする Hugging Face Open LLM Leaderboard では、さまざまなタスクと言語での標準化された性能比較が提供されており、ナショナル LLM 評価の優れた参考資料として活用できます。 Q&amp;A データセット生成と検証プロセス 高品質な評価データセットを作るには、自動生成と人間による検証を組み合わせた体系的なアプローチが必要です : スコープとコーパスの定義 : 優先度の高いユースケース、ドメイン、言語をリストアップします。文書、政策、FAQ、ナレッジベースから代表的で高品質なコーパスを収集し、適切なクリーニング、重複除去、個人識別情報 (personally identifiable information, PII) の除去を確実に行います。 ベースライン生成器の確立 : 候補モデル間で簡単な評価を実行し、対象言語とドメインに最適な生成器を選択し、自己評価バイアスを回避します。 プロンプトテンプレートの作成 : スタイル、難易度、回答形式、根拠要件を決めます。事実に基づく Q&amp;A、多段階推論、政策準拠、多言語シナリオのバリエーションを作成します。 パイロット生成 (100-300 項目) : ベースラインモデルを使用してコーパスから Q&amp;A ペアを生成し、すべてのドメイン、難易度、言語を比例的にカバーします。各項目に来歴メタデータをタグ付けします。 人間による検証ループ : 正確性、根拠、明確性、安全性について項目をサンプリングしてラベル付けします。問題を修正し、エラーパターンを文書化します。受入基準を計算します (目標は 90% 以上の正確性、根拠) 。 品質と安全フィルター : NVIDIA NeMo Curator などのツールを使用して、重複排除、定型文の削除、パープレキシティフィルタリング、PII チェックの自動パスを適用します。 生成のスケール化 : 固定されたテンプレートとモデルで完全な Q&amp;A データセットを生成し、学習 / 開発 / テストの分割全体で厳密なメタデータとバージョン管理を維持します。 検証の強化 : 層別サンプルに対する人間による監査を実施し、敵対的ケースと安全性シナリオを追加します。 性能測定フレームワーク 評価は複数の側面から検証する必要があります： 言語習熟度と文化的正確性 政府のユースケースにおけるタスク固有の性能 規制および倫理ガイドラインへの準拠 応答の適切性と安全性 計算効率とリソース使用率 モデルが性能目標を満たし、コンプライアンス要件を満足するまで、最適化フェーズに結果をフィードバックする反復的な評価プロセスを実装する必要があります。 ステージ 3: モデル選択と学習アプローチ 評価フレームワークを確立した後、モデルアーキテクチャと学習戦略について重要な決定を行う必要があります。これらの決定は、問題のスコープ、現在のモデル性能、セキュリティ要件、必要なカスタマイズレベルによって左右されます。 学習アプローチの決定基準 主に3つの選択肢があり、それぞれ異なるメリットとリソース要件があります。 ファインチューニング は最もリソース効率の良いアプローチで、事前学習済みモデルをドメイン固有のデータで追加学習させます。この手法は、対象ドメインが事前学習データと類似している場合や、リソースが限られている場合に適しています。ファインチューニングでは、特定の指示に対してモデルがどう応答すべきかの例を使うインストラクションファインチューニングや、人間のフィードバックを活用した強化学習 (Reinforcement Learning from Human Feedback, RLHF) などの技術により、モデルを人間の好みにより合わせることができます。 継続事前学習 (Continued pretraining, CPT) は、一般的な能力を保ちながら、既存のベースモデルを追加データで学習させる方法です。このアプローチは、基本的な理解力と推論能力を維持しながら、モデルを新しい言語やドメインに効果的に適応させます。ゼロから学習するよりも少ないデータで済みますが、ファインチューニングよりは多くのデータが必要で、高品質なデータによる 2 段階の学習により、未知の質問に対してもより良い対応力を提供します。具体的には、CPT はまずベース知識を保ちながらモデルを新しいドメインや言語に適応させ、次に特定能力の向上に集中することで、より安定して汎用性の高い性能を実現します。 ゼロからの学習 は、モデルアーキテクチャと機能を完全にコントロールできますが、既存のベースモデルをカスタマイズするよりもはるかに多くの計算リソースと高品質データが必要です。このアプローチは、既存モデルが対象言語を適切に扱えない場合や、特定のコンプライアンス要件を満たせない場合に必要となります。 予想されるアクセス量、応答速度の要件、ハードウェアコストを考慮して、API 利用料がセルフホスティングの TCO を上回るポイントを計算する必要があります。TCO 分析では、初期費用と運用費の両方を慎重に評価する必要があります。運用費は主にモデルのホスティング要件によって決まり、パラメータ数が多く GPU 計算需要の大きなモデルは、一定のユーザーアクセスと帯域幅を前提として、時間の経過とともに比例的に高い運用コストにつながります。意思決定では、サービス提供の制約内で主要性能指標を達成する最小のモデルを優先すべきです。これは、初期学習でのコスト削減とホスティング費用およびリソース要件の削減により、長期的な運用持続可能性に直接影響するためです。 ベースモデルがプロンプトにより目標性能の約 80 %を達成し、ラベル付きタスクデータが利用可能な場合はファインチューニングを選択してください。ドメインや言語のカバー範囲が不十分だが、大規模なラベルなしドメイン内コーパス (10-1000B トークン) が存在する場合は継続事前学習 (CPT) を選択してください。適切なベースモデルが存在せず、組織が兆単位のトークン学習インフラをサポートできる場合のみ、ゼロからの学習を検討してください。 主要な要因には、コストと時間の制約 (API 対 GPU 時間) 、サービング要件 (応答速度 / メモリ) 、データレジデンシーの要件、リスク許容度 (破滅的忘却 : 新しい学習によって以前の学習内容が上書きされてしまう現象) が含まれます。CPT またはファインチューニング後に主要性能指標を満たす最小のベースモデルを選ぶべきで、その決定はベースライン性能 (b) と適応率 (ra) 曲線によりを検証する必要があります。 モデルアーキテクチャの検討事項 ファインチューニングや CPT を検討している組織には、出発点として使えるオープンソースモデルがいくつかあります。モデルの選択は、希望するモデルサイズと必要な計算能力、対応したい言語、モデルの初期性能などの技術的な要素によって決まります。 さらに、モデルのアーキテクチャ (例 : Transformer ベースの設計や Expert Parallelism)、対応する情報の種類 (テキストのみか、マルチモーダルか)、パラメータ数、そしてこれらの選択が学習に必要なリソースと本番環境での推論性能にどう影響するかを考慮する必要があります。 ステージ 4: データ収集と準備 データ収集と準備は、カスタム LLM 開発において最も重要なステージです。特に、データの品質、関連性、セキュリティが重要な公共部門での利用では、なおさら重要になります。このアプローチは、選択したモデルアーキテクチャと学習戦略によって大きく変わります。 NeMo Curator による包括的データパイプライン NVIDIA NeMo Curator は、大規模な事前学習とファインチューニング用コーパス向けに設計された、データ整理の統合ツールキットです。このモジュール式パイプラインシステムは、Spark、Ray、Dask を使った分散処理に対応し、データのダウンロードから抽出、クリーニング、フィルタリング、重複除去、分類まですべてを処理します。 NeMo Curatorの主要機能は以下の通りです : データ取り込み : Web クローリング、Common Crawl 処理、データレイク連携、文書解析 (レイアウトヒューリスティクスを使用した PDF からテキストへの変換) データ正規化 : Unicode / NFKC 処理、空白と句読点の標準化、定型文とテンプレートの削除 安全性と PII 処理 : 設定可能な編集 / 削除ポリシーと国 / 分野別のコンプライアンス設定を持つ正規表現と機械学習ベースの検出器 高度な重複除去 : 文書・段落レベルでの完全一致ハッシュマッチング (MinHash/SimHash) とファジー近似重複検出 (LSH) 品質フィルタリング : 言語識別、長さ / パープレキシティ境界値、n-gram / ストップワード比率、有害性 / 安全性スコアリング 分類とタグ付け : ドメイン / トピックのラベル付け、文書構造分析、管轄 / 言語タグ付け 重要なデータ処理要素 重複除去 は複数のレベルで動作します。正規化されたテキストでの完全一致ハッシュ (SHA256) により同一文書とセグメントを削除し、近似重複検出では文書・段落レベルで LSH クラスタリングを使った MinHash/SimHash を使用します。このプロセスは、正規のコピーを保持し、保持根拠とともにハッシュクラスターを記録することで来歴を維持します。 PII 除去 は複数の検出方法を使います。メール、電話番号、ID の正規表現パターン、名前と場所の辞書、人物 / 組織 / 場所エンティティの機械学習による認識、支払いと健康情報に対する特殊なパターンです。データの種類と管轄区域ごとにコンテンツを編集または削除のポリシーを設定でき、コンプライアンス検証のための包括的な監査ログを取得できます。 合成データ生成 は、データが少ないドメインに対して体系的なプロセスで対処します。シード選択、スタイルと根拠制約を持つ LLM プロンプト、出力スキーマの強制 (JSON)、正規表現 / スキーマ / 有害性 / 根拠チェックによる検証、人間によるレビューサンプリング、適切な制御 (temperature / top-p 制限、長さの制限、ソース引用を含む) によるスケーリングを行います。 品質フィルタリングとパープレキシティスコアリング は複数の指標を組み合わせます。言語識別、長さ制御、ヒューリスティック測定 (ストップワード比率、記号 / 絵文字の割合)、有害性 / 安全性スコア、ドメイン適合性分類、参照言語モデルを使ったパープレキシティスコアリングにより、希少だが有効なコンテンツにバイアスをかけることなく、情報量の少ない、または劣化したテキストを特定します。 データ処理を以下の順序で実行する必要があります : データ正規化 PII 除去 重複除去 品質フィルター パープレキシティによるトリミング 保持率などのメトリクスを追跡しながらの分類 / 分割 重複率 PII ヒット率 パープレキシティの分布 言語 / ドメインごとのカバレッジ データセット構成戦略 ナショナル LLM の場合 、対象言語の素材、関連する言語や方言、一般知識を混合した多様なコンテンツを含める必要があります。対象言語と共に英語データを含めることには、2 つの目的があります。 一般的な能力の破滅的忘却を防ぐことと、実用的なバイリンガル機能を維持することです。並列データ (両言語でのペアテキスト) は、スムーズな言語切り替えのために言語間の関係を理解するのに役立ちます。重要なのはバランスの取れた構成です。英語のデータが多すぎると対象言語の能力が低下する可能性があり、英語のコンテンツが不足すると一般知識と推論能力が損なわれる可能性があります。特定の用途に必要な場合、コードや数学テキストなどの専門コンテンツを含めることもできます。 ドメイン特化型モデルの場合 、ドメイン固有のコンテンツと一般知識のバランスを保つことが重要です。ドメインデータに重点を置きすぎると、モデルが幅広い推論と言語スキルを失う可能性があり、一般データが多すぎると専門知識が希薄化してしまいます。並列データセットは、同一言語内で技術的テキストとわかりやすいテキストをペアリングすることで解決策を提供します。例えば、医療ガイドラインと患者向けの分かりやすい説明をマッチングさせて、専門用語と理解しやすい説明を結び付けることができます。 技術実装の考慮事項 トークン化手法の選択は、特に異なる文字体系やアルファベットを使用する言語において、モデル性能に重要な影響を与えます。ラテン文字の言語向けに開発された標準トークン化手法は、単語の区切りがない言語や基本トークナイザーの語彙に含まれていない文字を含む言語には効果的でない可能性があります。多言語モデルの場合、複数の言語を適切に表現する共有語彙を作成することは特に困難で、非効率なテキスト表現と性能低下を招く可能性があります。 ステージ 5: インフラストラクチャ構築と学習アプローチ インフラストラクチャの選択は、学習効率、コスト、運用の複雑さに大きく影響します。AWS では、組織の要件と技術レベルに合わせて、さまざまな選択肢を用意しています。 コンピューティング環境の選択肢 機械学習用のキャパシティブロック を備えた Amazon Elastic Compute Cloud (Amazon EC2) は、柔軟性が高く、細かい制御ができます。これは、特定のカスタマイズが必要な組織に向いていますが、コンピューティング環境の管理における深い専門知識が必要です。Amazon EC2 は、強力な GPU を搭載したさまざまな機械学習向けのインスタンスタイプが用意されており、特定のプロジェクト要件に合わせたコスト効率のよいリソースを選べます。 トレーニングプラン を備えた Amazon SageMaker HyperPod は、大規模深層学習ワークロード向けに最適化されたマネージドサービスです。自動ヘルスモニタリングやインスタンス交換などの機能により、分散学習インフラストラクチャの構築と管理を簡単にします。SageMaker HyperPod のクラスターエージェントは、障害が発生したノードを自動検出して、そのノードを交換し、ユーザーの介入なしに最後の正常なチェックポイントから学習を再開します。これは、信頼性が極めて重要な長時間実行 LLM 学習ジョブにとって特に有効です。 ネットワークとストレージの最適化 Elastic Fabric Adapter (EFA) は、マルチノード GPU 学習に最適な、低遅延、高速通信により、分散 LLM 学習の効率を大幅に向上させる高性能コンピューティングネットワークです。EFA は、カスタムビルドされたオペレーティングシステムをバイパスするハードウェアインターフェースをより、ノード間で頻繁に通信するアプリケーションを AWS 上でスケーラブルに実行できます。これにより、アプリケーションはオペレーティングシステムカーネルを経由せずネットワークハードウェアと直接通信できるため、遅延と CPU 負荷を大幅に削減します。このハードウェアへの直接アクセスは、勾配同期時の頻繁なノード間通信がボトルネックとなりがちな分散機械学習ワークロードにとって特に効果を発揮します。 データストレージとアクセス方法も、学習効率に大きく影響します。大規模学習では、AWS は長期保存用の Amazon Simple Storage Service (Amazon S3) と高性能ファイルシステムの Amazon FSx for Lustre を組み合わせるのが最適です。学習ノード間での効率的なデータアクセスを可能にします。Amazon FSx for Lustre は 分散ファイルストレージ (ストライピング) を使い、ファイルメタデータと実データを物理的に分離することで高速な読み書きを実現します。Amazon S3 と Amazon FSx for Lustre 間の接続は、 データリポジトリの関連付け で管理できます。 オーケストレーションとジョブ管理 選択したインフラストラクチャとチームの技術力に応じて、さまざまなオーケストレーションツールから最適なものを選べます。 SLURM 統合 は、オンプレミスからの移行とクラウドネイティブなデプロイの両方に対応しています。 AWS Parallel Computing Service (AWS PCS) は、SLURM をデフォルトのジョブスケジューラーとして使用し、HPC チームに馴染みのあるワークフロー管理を提供します。SLURM 設定には、GPU リソース管理 (gres.conf)、NCCL/IB 最適化、異なるタイプのジョブのサポート、共有ファイルシステムへのチェックポイントが必要です。 Amazon EKS 統合 は、Kubernetes の専門知識を持つ組織に柔軟性を提供します。 Amazon Elastic Kubernetes Service (EKS) のセットアップには、GPU 対応ノードグループ (p4d/p5、L4/L40S)、NVIDIA GPU Operator のインストール、ノードセレクターとテイントによる適切なスケジューリング、スケールアウト用の Karpenter、学習・推論ワークロード用のポッド優先度 / プリエンプションが必要です。 移行に関する考慮事項 として、SLURM と EKS の間で移行する際は、ネットワーク性能の検証 (同等のインターコネクト性能の実現) 、スケジューラー設定の適切な対応付け (Slurm パーティション / QoS と K8s 名前空間 / ResourceQuotas のマッピング) 、チェックポイントの互換性検証、セキュリティ制御のマッピング (サービスアカウント用の IAM ロール) 、コストモデリングと段階的なロールアウト計画の策定が必要です。 学習プロセスの実装 学習プロセスは通常、PyTorch や TensorFlow などのフレームワークを使用し、複数の GPU またはノード間で分散処理を行います。このプロセスは、データの分散、結果の収集、学習結果に基づく反復サイクルのパターンに従います。 学習は、モデルが定義された性能目標を満たすまで、学習、テスト、改良を繰り返すプロセスです。これには、学習率、バッチサイズ、モデルアーキテクチャなどのパラメータを最適な性能のために調整するハイパーパラメータチューニングなどの手法が含まれます。 学習ジョブの規模、組織内の技術力、特定の性能要件、運用の複雑さと柔軟性のバランスを考慮してインフラストラクチャを選ぶ必要があります。 ステージ 6: 本番環境へのデプロイと性能テスト LLM が性能とコンプライアンスの基準を満たしたら、本番環境への包括的なデプロイに向けて、体系的な性能テスト、インフラストラクチャの最適化、監視を行います。 本番環境の性能テストフレームワーク さまざまな条件下でモデルの性能を検証するために、体系的な性能テストを実施する必要があります。これには、 GenAI-Perf や vLLM などの業界標準ツールを使用したベンチマークフレームワークが含まれ、異なる構成間で一貫した性能測定と比較が可能になります。テストでは、再現性を確保するためにカナリアデータセットを使用し、ステップロードテストやスパイクテストを通じて定常状態とバースト時の両方の動作を把握する必要があります。k6、Locust、またはカスタム Python ハーネスなどのツールを使ってテストを自動化できます。GPU サービスの場合、複数のレプリカを実行することで、オートスケーリングのしきい値を効果的にテストできます。検証では、同時実行レベルごとに 10 〜 30 分間の安定性を確認し、本番環境への準備のために 1 〜 2 時間の耐久テストまで拡張する必要があります。 モデルのデプロイオプションとデータ主権 ナショナル LLM のモデルホスティングを選択する際、3 つの主要なデプロイ方法を区別する必要があります。それぞれのアプローチはデータ主権に対して異なる意味を持ちます : サードパーティクラウド上のクローズドソースモデル : データフローとログは、自組織のアカウント外で管理されるため、厳格なデータレジデンシー要件がある管轄区域ではコンプライアンス上の課題が生じる可能性があります。 マネージドサービス ( Amazon Bedrock など) 経由のオープンソースモデル : マネージドサービス環境で動作しながら、アクセスとガバナンスを簡素化し、制御のしやすさと運用の手軽さのバランスを実現します。 自組織の AWS アカウント内で完全にホストするオープンソースモデル : データの流れ、テレメトリ、監査証跡を最も強力に管理でき、厳格な主権要件を満たすために必要となることが多い方法です。 GDPR 準拠や国内処理義務などのデータレジデンシー要件と主権要件が、この選択を左右します。一部の管轄区域では、学習と推論の両方を国内で行うことを義務付けており、国境を越えたエンドポイントは使用できません。保存場所だけでなく、プロンプト、出力、モデルログの処理される場所もコンプライアンスの対象となります。一時的な推論トラフィックであっても、必要な境界を越えると規制違反になる可能性があります。 多くの公共部門では、自組織のアカウント内でオープンソースモデルをセルフホストすることが、データレジデンシー、プライバシー、監査義務を満たす最も確実な方法です。一方、機密性の低いワークロードや初期評価段階では、マネージド API も有効な選択肢となります。 Amazon SageMaker AI は、モデルデプロイのためのマネージド環境を提供し、基盤となるインフラストラクチャの複雑さの多くを処理しながら、スケーラブルな推論と他の AWS サービスとのシームレスな連携を実現します。より詳細な制御や特定の構成が必要な場合には、Amazon EC2 で完全なカスタマイズ可能な直接デプロイが可能です。Kubernetes の専門知識がある組織なら、Amazon EKS を選んでコンテナ化されたデプロイを行うことで、環境間の柔軟性と移植性が得られます。 デプロイを成功させるには、コスト管理、性能監視、セキュリティコンプライアンスへの細心の注意が必要です。モデルが既存システムとシームレスに連携し、公共部門のセキュリティとコンプライアンス要件を満たすよう、適切な最適化戦略を実装する必要があります。 セキュリティとコンプライアンスのフレームワーク 公共部門の LLM デプロイには、データ主権、プライバシー、監査要件に対応する包括的なセキュリティとコンプライアンス対策が必要です。 承認されたリージョンと VPC (Virtual Private Cloud) に学習と推論を限定し、カスタマーマネージドキー、プライベートサブネット、VPC エンドポイントを使用してデータレジデンシーを確保します。PII 検出と除去は、監査された拒否バケットと不変の変換ログを備えたキュレーションパイプラインに実装する必要があります。 ドキュメントには、一時的なログも含め、プロンプト、出力、テレメトリがどこで処理されるかを明記します。モデルホスティングについては、主権義務がデータの流れとログの制御を求める場合、アカウント内のエンドポイント (Amazon EC2 / Amazon EKS / Amazon SageMaker) を優先すべきです。その際、アクセス制御 (IAM / IRSA) 、転送中と保管時の暗号化、監査証跡 (CloudTrail) 、定期的なコンプライアンスレビューを維持する必要があります。 まとめ 公共部門向けのカスタム LLM の開発とデプロイには、イノベーションとセキュリティ、コンプライアンス、信頼性の要件のバランスを取る体系的なアプローチが必要です。測定可能な成果と再現可能なプロセスを重視する科学的手法により、複雑な課題を乗り越えながらミッションクリティカルな目標を達成できます。 AWS の包括的なサービス群は、初期評価フレームワークから本番環境へのデプロイと監視まで、各開発ステージに必要なツールとインフラストラクチャを提供します。ナショナル LLM を通じて文化遺産を保護する場合でも、ドメイン特化型 LLM で公共サービスを強化する場合でも、カスタム LLM は政府や公共機関がコミュニティにサービスを提供する方法を大きく改善する可能性を秘めています。 成功には、初期デプロイ後も継続的な取り組みが必要です。進化する運用環境において LLM の有効性を維持するため、継続的な監視、改良、適応を行います。 カスタム LLM 開発を開始する準備ができている場合、以下を実施する必要があります : 評価フレームワークの確立 : LM HarnessとAWSネイティブツールを使用 コスト分析の実施 : 予測されるワークロードに対する API 利用とセルフホスティングの TCO を比較 AWS インフラストラクチャオプションの検討 : SageMaker HyperPod、AWS PCS、Amazon EC2 Capacity Blocksを検討 データキュレーションパイプラインの実装 : Nemo Curatorなどのツールで大規模処理に対応 セキュリティとコンプライアンスフレームワークの設計 : 特定の管轄要件を満たす設計 詳細な技術ガイダンスについては、包括的なリソースライブラリをご覧ください : An introduction to preparing your own dataset for LLM training AWS Machine Learning Documentation Amazon SageMaker AI Documentation GENIAC プログラムから学んだ基盤モデル構築支援の教訓 組織のナショナル LLM 取り組みに対する具体的な要件やカスタマイズされた実装ロードマップの作成については、AWS アカウントチームにお問い合わせください。 TAGS: Artificial Intelligence , AWS Public Sector , technical how-to Laura Verghote Lauraは AWS の欧州 PSI における生成 AI リードとして、公共部門への生成 AI 導入を推進しています。欧州全域のお客様と協力し、技術的専門知識と戦略的計画を通じて生成 AI イニシアチブを加速させ、複雑な要件と革新的な AI ソリューションを橋渡ししています。 Anton Alexander Antonは AWS の生成 AI シニアスペシャリストとして、SageMaker HyperPod を使用した大規模な学習および推論ワークロードのスケーリングに注力しています。ベテランの CUDA プログラマーであり Kubernetes エキスパートとして、分散学習のための NVIDIA 技術の統合を支援し、EKS と Slurm 実装を専門としています。MENA 地域および政府部門のお客様と密に連携し、生成 AI ソリューションの最適化に取り組んでいます。機械学習エッジコンピューティングシステムに関する特許を申請中です。仕事以外では、ブラジリアン柔術と大学ボクシングのチャンピオンであり、飛行機の操縦を楽しんでいます。 Eliuth Triana Isaza Eliuth は NVIDIA のデベロッパーリレーションズマネージャーとして、Amazon の AI MLOps、DevOps、サイエンティスト、AWS テクニカルエキスパートを支援しています。 NVIDIA コンピューティングスタックを活用して、データキュレーション、GPU 学習、モデル推論、AWS GPU インスタンスでの本番デプロイにまで、生成 AI 基盤モデルの高速化と最適化をサポートしています。プライベートでは、マウンテンバイク、スキー、テニス、ポーカーを楽しんでいます。 Niki Sotiria Kokkalas Niki Sotiria は EMEA 地域の公共部門組織向けの生成 AI とデータ分析ワークロードを専門とする AWS のインダストリーソリューションアーキテクトです。主に教育に焦点を当てた機関や組織と協力し、イノベーションとインパクトを推進する効果的なデータと AI 戦略の設計と実装を支援しています。 Wenhan Tan Wenhan は NVIDIA のソリューションアーキテクトとして、お客様が大規模に NVIDIA AI ソリューションを導入できるよう支援しています。彼の業務は、深層学習アプリケーションの高速化と推論および学習の課題への対処に焦点を当てています。

このブログ記事は、株式会社タイミー様が執筆し、Amazon Web Services Japan が監修しています。 はじめに 株式会社タイミーは、「働きたい時間」と「働いてほしい時間」をマッチングするスキマバイトサービスを提供しています。 私たちは、 Amazon EKS Auto Mode (EKS Auto Mode) × Actions Runner Controller (ARC) を活用し、コスト・パフォーマンス・運用性のバランスを兼ね備えた Self-hosted Runner 基盤を構築しました。 本記事では、その背景と設計方針、導入時に直面した課題と解決への取り組み、導入によって得られた効果、そして今後の展望について紹介します。 背景と課題 スキマバイトサービス『タイミー』を中心にプロダクト開発が拡大する中で、CI/CD 基盤の改善には継続的に取り組んできました。 2024年10月に公開した「 CI 基盤を GitHub Actions へ移行した記事 」で紹介したとおり、 CircleCI から GitHub Actions への移行によって、開発体験やパイプライン速度は大きく改善しました。 しかし、開発者数やテストケースの増加、そして AI エージェントの活用拡大により、時間の経過とともに新たな課題が見えてきました。 コスト面での課題 CI 実行回数の急増 開発者や AI エージェント (例 : Devin) の利用が増えるにつれ、CI の実行回数も増加しました。 2025年初頭には、ピーク時で 1 時間あたり 60 件を超えるワークフローを処理する必要があり、コストとパフォーマンスの両立が新たな課題となりました。 GitHub-hosted Runner のコスト最適化限界 GitHub-hosted Runner は安定性に優れる一方で、割引オプションが少なく、コストコントロールの柔軟性に欠けます。実行頻度が高いワークロードに対しては、効率的なコスト最適化が難しい状況でした。 柔軟な最適化が可能な基盤の必要性 一方で、AWS では Savings Plans や Spot インスタンスを活用することで、柔軟な最適化が可能です。利用量が増え続けるタイミーのユースケースにおいては、こうした 柔軟に最適化できる基盤 が求められるようになりました。 技術面での課題 高並列・高頻度な実行負荷 CI ワークフローでは最大 35 並列でジョブを実行しており、ピーク時には 1 時間あたり約 60 回のワークフローが走ることもありました。CI ワークフローだけでも、1 時間に最大で 2,000 件以上の Runner が起動する規模 となり、開発速度を維持しながら、この高い実行頻度に耐えられる仕組みが求められていました。 環境構築コストによる実行時間の肥大化 GitHub-hosted Runner ではジョブごとに環境を都度構築するため、 apt install などのセットアップ処理によって実行時間が長くなり、まれに依存パッケージの取得に失敗してジョブが落ちるケースも発生していました。 テストケースの増加による実行時間の延伸 テスト数の増加に伴い、CI 全体の実行時間が徐々に長くなる傾向がありました。 その結果、「Self-hosted Runner (テスト実行用のコンテナ環境) にテスト実行に必要なライブラリをあらかじめインストールしておけば、テストのたびに毎回ライブラリをインストールする必要がなくなり、より高速化できるのでは？」という意見が開発者から上がるようになりました。 セキュリティと運用負荷のトレードオフ Terraform の適用など、強い IAM 権限を必要とするワークフローも存在しており、 セキュリティを強化しつつ、Self-hosted Runner 基盤に過剰な運用コストをかけないバランスが課題となっていました。 これらの課題を踏まえ、私たちは「コスト」「パフォーマンス」「セキュリティ」「運用性」のバランスを両立できる Self-hosted Runner 基盤を設計することにしました。そのために、複数のアプローチを比較検討しながら、最適なアーキテクチャを模索していきました。 プロジェクト概要 検討のプロセス 最初に検討したのは、 Amazon ECS (ECS) + AWS Lambda (Lambda) + Amazon API Gateway を組み合わせて Self-hosted Runner を構築する方法でした。 スケーラブルでサーバーレスに見える魅力的な構成でしたが、実際に検証してみるといくつかの課題が見えてきました。 GitHub API のレートリミット対応が難しい 1回の CI 実行で最大 35 並列の Runner を起動し、ピーク時には 1 時間に 60 回以上実行されるケースもあります。 これを Lambda 側で制御するのはかなり複雑で、実装コストが高くなってしまう懸念がありました。 起動の速さに限界がある Runnerは「30秒以内に起動してほしい」という要件がありますが、Lambda 経由で ECS タスクを起動する構成ではコールドスタートが発生し、安定 して要件を満たすのが難しい状態でした。 メンテナンスコストが高い Lambda 側のコードを継続的に更新・管理する必要があり、長期運用を考えると負担が大きいと判断しました。 そこで次の候補として、Kubernetes クラスタ上で ARC を運用する方法を検討しました。 ただし Kubernetes は強力である一方、クラスタバージョンアップやノード管理といった運用コストの高さが懸念でした。 こうした背景から、最終的に採用したのが EKS Auto Mode × ARC の組み合わせです。 EKS Auto Mode : クラスタ管理・ノード管理の運用負荷を大幅削減 ARC : GitHub API と連携し、Runner Pod を動的にスケーリング 「Kubernetes の柔軟性を活かしながら、運用負荷を抑えて安定した Self-hosted Runner 基盤を実現できる」 そう判断し、この構成を選びました。 プロジェクト体制と期間 本プロジェクトは、プラットフォームエンジニア 1 名と壁打ち役 1 名という少人数体制で進行しました。 EKS Auto Mode では、クラスターを立ち上げるだけで主要な Add-on が自動的にセットアップされるため、そこに ARC（Actions Runner Controller）を Helm でデプロイするだけで、基本的な骨組みをすぐに構築できます。 これにより、検証と調整を素早く繰り返せる環境を整え、効率的に構築を進めることができました。 さらに、EKS Auto Mode ではノードや主要な Add-on の更新・管理を AWS 側が自動で行ってくれるため、運用設計にかける手間を大幅に減らすことができました。 その結果、短いサイクルで構築から本番導入までスムーズに完了し、検証開始から約 2 か月で安定稼働に至りました。 システムアーキテクチャー ARC : GitHub API と連携し、必要に応じて Runner Pod を自動で起動・削除 EKS Auto Mode : Karpenter による高速スケーリングを実現 EKS Auto Mode のおかげでノード管理の負担を大幅に軽減し、「Kubernetes を使いたいが運用コストは最小限にしたい」という要件を満たすことができました。 導入時に直面した課題と解決策 ① Spot インスタンスの安定性問題 当初はコスト削減を狙って、停止率の低いインスタンスタイプの Spot インスタンス を採用していました。しかし、弊社のCIは 35 並列で高頻度に実行 されるため、必要なインスタンス数が多くなり、停止確率が低いタイプでも 1 日あたり 5〜10 回ほどノードが落ちる ことがありました。その結果、CIが途中で失敗するケースが頻発し、 開発者体験を大きく損ねる要因 となってしまいました。 対策 そこで思い切って オンデマンドインスタンスに切り替え 、必要に応じて Savings Plans を適用する方針にしました。 オンデマンドにしたことで、Runnerが突然落ちるリスクがなくなり、安定して CI を回せるようになった 安定性が向上したことで、CIだけでなく デプロイなど他のワークフローも Self-hosted Runner に寄せる ことが可能に これにより EC2 のアイドル時間を減らし、稼働率を高めることでコスト効率も改善できました ② スケールインで Runner Pod が強制終了する問題 次に直面したのは「EC2 のスケールインによって、Runner Pod が CI 実行中に突然落ちる」という問題です。 原因は、Karpenter の設定でした。 デフォルトでは disruption.consolidationPolicy が WhenEmptyOrUnderutilized になっており、リソース使用率が低いと、 Pod が稼働中でも容赦なくノードを落としてしまう のです。 (参考: https://karpenter.sh/docs/concepts/disruption/ ) 対策 consolidationPolicy を WhenEmpty に変更 Podがないノードのみスケールイン対象とするよう設定 spec: disruption: consolidationPolicy: WhenEmpty これで Runner Pod が実行中に消える問題は解消しました。 ③ ノードが全然スケールインしない問題 しかし、ここで新たな課題が発生します。 それは「一度スケールアウトすると、ノードがほとんどスケールインしなくなる」という現象です。 原因は、Kubernetes のスケジューリングの仕組みにありました。Kubernetes は、Pod をできるだけ均等にノードへ分散配置しようとする特性があります。そのため、ノード上の Pod 数がバラけやすく、どのノードも完全に空になることがほとんどありません。 結果として、スケールインのトリガー条件 (＝Pod が存在しないノード) がなかなか満たされず、 ノードが減らない状態が続いてしまいました。 対策 Pod Affinity を利用し、Runner Pod はなるべく同じノードに詰めるよう設定 Pod 配置の断片化を防ぎ、スケールインしやすくしました affinity: podAffinity: preferredDuringSchedulingIgnoredDuringExecution: - weight: 100 podAffinityTerm: labelSelector: matchLabels: actions.github.com/scale-set-namespace: arc-runners topologyKey: kubernetes.io/hostname これによりリソース効率が大きく改善されました。 ④ 夜間にリソースを最適化する作戦 リソース効率をさらに高めるため、 日中は安定性を優先し、夜間だけ段階的にノードを整理する仕組み を導入しました。 具体的には、disruption.consolidationPolicy を WhenEmptyOrUnderutilized に設定したうえで、夜間に 一定間隔で 15 分だけ pod が存在するノードのスケールインを許可 → その後は再び禁止 というサイクルを繰り返します。 これにより、ノード上にPodが残っていても一気に消されることはなく、 「急に Pod が落ちて CI が止まる」といったリスクを避けながら、少しずつリソースを最適化 できるようになります。 spec: disruption: consolidationPolicy: WhenEmptyOrUnderutilized consolidateAfter: 5m budgets: - nodes: "0" reasons: - Underutilized schedule: "0 0 * * *" duration: "11h45m" - nodes: "0" reasons: - Underutilized schedule: "0 12 * * *" duration: "3h15m" - nodes: "0" reasons: - Underutilized schedule: "30 15 * * *" duration: "1h45m" - nodes: "0" reasons: - Underutilized schedule: "30 17 * * *" duration: "2h45m" - nodes: "0" reasons: - Underutilized schedule: "30 20 * * *" duration: "3h30m" この仕組みによって、 日中は安定して CI を回しつつ、夜間は少しずつノードを整理してリソースを効率的に活用 できるようになりました。 導入の効果 コスト面 現時点では、GitHub-hosted Runner を利用していた頃とコストはほぼ同水準です。 しかし今後、Savings Plans の適用やリソースチューニングを進めることで、段階的なコスト削減を見込んでいます。 GitHub-hosted Runner は、 利用時間に応じて課金される従量課金モデル であり、Private リポジトリ向けは 2core 固定 の課金体系になっています。 一方、Self-hosted Runner は EC2 の実行時間に基づく課金 となるため、ジョブの内容に応じて柔軟にリソースを割り当てることが可能になりました。 CPU バウンドなジョブでは多コアを割り当てて高速化 I/O 中心や軽量なジョブでは 1core またはそれ以下に制限 このようにリソースを使い分けることで、EC2 の起動台数を最適化し、コストを柔軟にコントロールできるようになりました。 さらに、Self-hosted Runner の課金体系は基本的に EC2 の稼働時間に依存するため、開発者数が増えても、GitHub-hosted Runner のように Runner 利用料金が比例して膨らむことがない点も大きな利点です。 パフォーマンス面 Runner イメージに事前に必要な apt パッケージなどをインストールしておくチューニングにより、CI 実行時間を 平均で約 3 分短縮 しました。 運用コスト面 EKS を利用する上で手間のかかるポイントのひとつが、ノードや Add-on のバージョン管理です。しかし、EKS Auto Mode を採用したことで、 ノードと主要な Add-on のアップデートは AWS 側で自動的に管理 されるようになりました。 そのため、利用者がノードの入れ替えや Add-on の更新を手動で行う必要がなく、運用負荷を大幅に削減できました。 一方で、クラスタ本体 (control plane) のバージョンアップは引き続き手動で行う必要があります。 ただし、ARC Runner (Helm) で使用している Kubernetes 関連の依存関係については、 Renovate や Dependabot により継続的に最新化しています。その結果、 常に最新の API 群を利用できており、非推奨 API に依存するリスクが低減 されています。これにより、クラスタ本体のバージョンアップ時にも大きな修正を伴うことが少なく、 安全かつスムーズにアップグレードを進められる運用体制 を実現できました。最終的には、定期的にクラスタのバージョンを上げるだけで安定稼働を維持できるようになり、 ほぼ手放しで安定稼働できる運用体制を実現しており、日常的なメンテナンス工数は従来に比べて大幅に軽減されています。 今後の取り組み Runner イメージのチューニングによって、実行時間の短縮には一定の成果を得られました。 今後は、 セキュリティ強化 を目的として、Self-hosted Runner のさらなる活用を検討しています。 たとえば、Terraform を用いて AWS 構成管理を行う GitHub Actions のワークフローでは、 その性質上、比較的強い IAM Role の権限を付与する必要があります。 ワークフロー内では IAM ユーザーを直接使用していないものの、一時的に発行される STS トークン（セッションクレデンシャル）によって、一定期間 AWS リソースにアクセスできる状態になります。 このような仕組みの中で、仮に悪意のあるアクションや依存ライブラリによって環境変数からクレデンシャル情報が抜き取られた場合、そのトークンを悪用して AWS リソースを破壊・改ざんされるリスクがあります。 これは、GitHub-hosted Runner 利用時における 攻撃対象領域 の一つとなり得ます。 Self-hosted Runner を活用することで、こうしたリスクに対してより強固なセキュリティ対策が可能です。 たとえば、Runner の送信元 IP は NAT 経由で固定されているため、Terraform 実行時に利用する IAM Role に IP 制限を付与することで、不正アクセスを防止できます。 さらに、 DNS Firewall や Network Firewall を組み合わせることで、ワークフロー内から外部への不正な通信（例：環境変数を外部サーバーに送信するなど）を遮断できます。これらの対策により、ワークフロー内で利用される一時的なクレデンシャル情報の漏えいを防ぎ、よりセキュアで信頼性の高い環境を実現できると考えています。 まとめ EKS Auto Mode × Actions Runner Controller (ARC) の導入により、タイミーでは運用負荷を抑えながら、スケーラブルで安定した Self-hosted Runner 基盤を実現しました。 EKS Auto Mode によるノード管理の自動化と、ARC・Karpenter による柔軟なスケーリングによって、高速な CI 実行と高い安定性を両立し、開発者体験も大きく向上しました。 今後は、コスト最適化やセキュリティ強化を継続的に進めるとともに、EKS Auto Mode の運用ナレッジが社内に蓄積されていけば、必要に応じてサービス基盤への適用も検討していきたいと考えています。 著者について 徳富 博 (Tokudomi Hiroshi) 株式会社タイミー プラットフォーム エンジニアリング1G 2024年5月にタイミーへ入社。オブザーバビリティ、開発者体験やセキュリティの向上、インフラ整備、パフォーマンスチューニングなどに取り組んでいます。

本記事は米国時間 2025 年 10 月 31 日に公開された「 This is Kiroween 」を翻訳したものです。 ついに来ました！このハロウィン、私たちは初回となる Kiroween ハッカソン を開始します。これは年に一度のコンテストで、従来のツールでは実現が困難な、ワイルドで創造的なアイデアを刺激するために設計されています。私たちは 12 の異なる賞と 66 人の受賞者に総額 10 万ドルを授与し、1 位の賞金は 3 万ドルです。スペック、エージェントフック、ステアリング、MCP などの Kiro のエージェント機能が可能性をどのように押し広げるかを体験してください。あなたが熟練した開発者、スタートアップ創設者、デザイナー、または技術愛好家であっても、Kiro があなたをどのように後押しするかを見るのが待ちきれません。 Devpost で登録 注意：提出期間中、参加者には Kiro Pro + プラン相当のクジレットを提供いたします。Kiroween に登録すると、特典を受ける方法の詳細な手順が記載された確認メールが届きます。私たちの優先事項は、あなたが Kiro で意味のある構築と実験を行うためのリソースを確実にご提供することです。 ダークモードでコーディングする勇気を チャレンジは、ハロウィンの精神に浸れるような不気味なカテゴリーセットに着想を得て、Kiro を使用して動作するアプリを構築することです。これらを自由にしたのは、あなたが最もワクワクするものを構築でき、本当にクールでユニークなアプリのアイデアを引き出すのに十分なインスピレーションを与えるためです。 復活 ：お気に入りの廃れた技術を蘇らせましょう。廃れた技術を今日のイノベーションで再構想するか、明日の問題を解決してください。 フランケンシュタイン ：思いもよらない強力なものを一つのアプリにしてつなぎ合わせましょう。一見互換性のない要素を結び合わせて、予想外に強力なものを構築してください。 スケルトンクルー ：骨組みとなるコードテンプレートを構築してください。簡潔で明確でありながら、様々なユースケースに対応できる柔軟性を備えたものにしましょう。基盤となる 2 つの異なるアプリケーションを通じて、その汎用性を示してください。 コスチュームコンテスト ：どんなアプリでも構築してください。ただし、洗練されて忘れられない不気味なユーザーインターフェースを見せてください。アプリの機能を向上させる不気味なデザイン要素を取り入れてください。 さらに、スタートアップらしい味付けも Kiroween に新たな賞カテゴリ「ベストスタートアッププロジェクト」を追加しました。このカテゴリでは、最優秀作品に 1万ドル を授与します。（提出詳細については ルール を参照してください）。スタートアップ創設者に、通常であれば大幅により多くのリソースが必要なコンセプトを迅速にプロトタイプし開発する機会を提供したいと考えています。Kiro の開発サイクル加速能力により、より野心的なアイデアをテストし、より速い反復で、魅力的な製品を生み出すことができます。これらをすべてハッカソンの期間内に実現します。 詳細 重要な日程： 開始：2025 年 11 月 1 日土曜日、日本時間 午前 1 時 提出締切：2025 年 12 月 6 日金曜日、日本時間 午前 7 時 賞金プール ：カテゴリー受賞者、総合受賞者、創造性、ソーシャルエンゲージメントなどの特別ボーナス賞を含む、総額 10 万ドルの賞金が待っています。 審査基準 ：あなたの提出物は、 Ania Kubow 、 Santiago Valdarrama 、 Rachel Stephens などを含む専門業界審査員のパネルによって評価されます。各アプリは以下に基づいて評価されます： 潜在的価値 ：あなたのソリューションはどれほど有用で、アクセスしやすく、インパクトがありますか？ 実装 ：Kiro の機能をどれほど効果的に活用しましたか？ 品質とデザイン ：あなたのプロジェクトはどれほど創造的で、独創的で、洗練されていますか？ 提出要件 ： .kiro ディレクトリ（スペック、フック、ステアリングの使用方法を示す）を含むパブリックコードリポジトリ、機能するアプリケーション URL、3 分間のデモンストレーション動画、および以下のような機能の次世代レベルの理解を示す開発プロセス全体での Kiro 活用に関するドキュメントを提供する必要があります。 バイブコーディング ：プロジェクトを構築するために Kiro との会話をどのように構造化しましたか？Kiro が手助けした最も印象的なコード生成は何でしたか？ エージェントフック ：Kiro フックでどのような特定のワークフローを自動化しましたか？これらのフックは開発プロセスをどのように改善しましたか？ 仕様駆動開発 ：Kiro が実装するためのスペックをどのように構造化しましたか？仕様駆動アプローチは開発プロセスをどのように改善しましたか？これはバイブコーディングと比較してどうでしたか？ ステアリングドキュメント ：Kiro の応答を改善するためにステアリングをどのように活用しましたか？最も大きな違いを生んだ特定の戦略はありましたか？ MCP ：Kiro の機能拡張はプロジェクト構築にどのように役立ちましたか？MCP が可能にした機能やワークフロー改善のうち、そうでなければ困難または不可能だったものは何ですか？ Devpost で登録 Discord が居場所です Kiro Discord では専用の #kiroween-hackathon チャンネルが待っています。そこで仲間の参加者とつながり、チームを結成し、アイデアを共有し、他の開発者や Kiro チームメンバーからサポートを得ることができます。私たちのコミュニティは、課題をナビゲートし、フィードバックを提供し、途中での進歩を祝うお手伝いをする準備ができています。また、製品専門家にリアルタイムで質問できる隔週のオフィスアワーもあります。ハッカソンを超えて、プロジェクトスポットライト、製品発表、イベント更新、その他のニュースやリソースが定期的に共有されています。そこでお会いしましょう。 暗闇に git commit する準備はできましたか？ Kiroween は Kiro 開発者のために、Kiro で実験し、それが提供する機能と能力の全範囲を活用する楽しい機会として設計されました。今こそ、忘れられない何かを生み出すチャンスです。Kiroween の特別な不気味さからインスピレーションを得て、アイデアを召喚し、暗闇に git commit してください。 Devpost で登録 X 、 LinkedIn 、 Instagram で @kirodotdev を、 BlueSky で@kiro.devをタグ付けし、ハッシュタグ #codewithkiro を使用して進捗の更新を共有してください。

複雑なデータ取得システムを開発する手間をかけることなく、正確かつ最新の情報を提供する AI アプリケーションを構築することを想像してみてください。10 月 28 日は、 Amazon Bedrock の Nova モデル向けの新しい組み込みツールである Web Grounding の一般提供が開始されたことを皆さんにお知らせします。 Web Grounding は、ターンキー 検索拡張生成 (RAG) オプションを開発者に提供します。このオプションは、Amazon Nova 基盤モデル がプロンプトの内容に基づいて関連する最新情報をいつ取得して組み込むのかをインテリジェントに判断できるようにします。これは、ハルシネーションの削減と精度の向上を目的とするもので、引用されたパブリックソースをコンテキストとして組み込むことでモデル出力をグラウンディングするために役立ちます。 開発者が Web Grounding を使うべき状況 開発者は、最新の事実情報にアクセスする必要があるアプリケーションや、十分な引用が行われた応答を提供する必要があるアプリケーションを構築するときに Web Grounding の使用を検討すべきです。この機能は特に、製品やサービスに関する最新情報を提供する知識ベースのチャットアシスタントや、事実確認やソース検証が必要になるコンテンツ生成ツールといったさまざまなアプリケーションで真価を発揮します。また、複数の最新ソースからの情報を合成する必要があるリサーチアシスタントや、精度と検証可能性が極めて重要なカスタマーサポートアプリケーションにも最適です。 Web Grounding は、AI アプリケーションのハルシネーションを低減する必要があるときや、ユースケースで透明性のあるソース属性が必要になるときに特に便利です。Web Grounding は情報の取得と統合を自動的に処理するため、複雑な RAG 実装の管理ではなく、アプリケーションの構築に集中したい開発者のための効率的なソリューションです。 使用の開始 Web Grounding は、推論時における情報の取得と処理を実行するために、サポートされている Amazon Nova モデルとシームレスに統合します。これは、複雑な RAG パイプラインを構築して維持する必要をなくすとともに、情報の取得元を実証するソース属性も提供します。 Web Grounding を有効にした状態で、Python を使用して Amazon Bedrock Converse API を呼び出す Nova Premier に質問する例を見てみましょう。 まず、通常の方法で AWS SDK for Python (Boto3) を使用して Amazon Bedrock クライアントを作成しました。これには、グッドプラクティスとしてセッションを使用しています。セッションは、設定をグループ化して再利用可能にするために役立ちます。次に、BedrockRuntimeClient を作成します。 try: session = boto3.Session(region_name='us-east-1') client = session.client( 'bedrock-runtime') それから、Amazon Bedrock Converse API ペイロードを準備します。ここでは、「role」パラメータが「user」(AI 生成応答の場合は「assistant」になります) に設定されており、メッセージがアプリケーションのユーザーからのものであることを示しています。 このデモでは、「現在の AWS リージョンとそれらの場所を教えてください」という質問を選びました。 この質問は、応答に最新の情報が必要になることから意図的に選択しました。これは、Amazon Nova が最新の知識が必要であると判断したときにどのように Web Grounding を使用して検索を自動的に呼び出すのかを実証するために役立ちます。 # Prepare the conversation in the format expected by Bedrock question = "What are the current AWS regions and their locations?" conversation = [ { "role": "user", # Indicates this message is from the user "content": [{"text": question}], # The actual question text } ] まず、Web Grounding を使用しなかった場合の出力を見てみましょう。Amazon Bedrock Converse API を呼び出します。 # Make the API call to Bedrock model_id = "us.amazon.nova-premier-v1:0" response = client.converse( modelId=model_id, # Which AI model to use messages=conversation, # The conversation history (just our question in this case) ) print(response['output']['message']['content'][0]['text']) 現在のすべての AWS リージョン とそれらの場所のリストが返されます。 今度は、Web Grounding を使ってみましょう。Amazon Bedrock Converse API に同じような呼び出しを行いますが、今回はモデルが利用できるツールの 1 つとして nova_grounding を宣言しています。 model_id = "us.amazon.nova-premier-v1:0" response = client.converse( modelId=model_id, messages=conversation, toolConfig= { "tools":[ { "systemTool": { "name": "nova_grounding" # Enables the model to search real-time information } } ] } ) 応答の処理後、モデルが Web Grounding を使用して最新情報にアクセスしたことを確認できます。出力には、思考過程を辿り、外部ソースを自動的にクエリした箇所を確認するために使用できる推論トレースが含まれています。これらの外部コールからの応答の内容は [HIDDEN] として表示されています。これは、AI システムにおける標準的な慣行で、機密情報を保護するとともに、出力サイズの管理にも役立ちます。 さらに、出力には Web Grounding がクエリしたソースに関する情報が含まれた CitationsContent オブジェクトもあります。 最後に AWS リージョンのリストを確認でき、「これらは世界中の最新かつアクティブな AWS リージョンです」というメッセージで終わっています。 Web Grounding は、最小限の労力で AI アプリケーションの信頼性と最新性を向上させることにおける大きな進歩です。正確かつ最新の情報を提供する必要があるカスタマーサービスチャットアシスタントを構築している、複数ソースからの情報を分析して合成するリサーチアプリケーションを開発している、または目的地や宿泊施設に関する最新の詳細情報を提供する旅行アプリケーションを作成しているかに関わらず、Web Grounding は、簡単に設定して使用できる便利なターンキーソリューションで、より正確で関連性の高い応答をユーザーに提供できるようにしてくれます。 知っておくべきこと Amazon Nova Web Grounding は、10 月 28 日から米国東部 (バージニア北部) でご利用いただけます。Web Grounding は、米国東部 (オハイオ) と米国西部 (オレゴン) でも近日リリース予定です。 Web Grounding には追加料金が発生します。詳細については、 Amazon Bedrock の料金ページ をご覧ください。 現在、Web Grounding を使用できるのは Nova Premier のみですが、他の Nova モデルのサポートも近々追加される予定です。 Amazon Nova を使用したことがない場合や、さらに深く掘り下げたいとお考えの場合は、自分のペースで進めることができるこちらのオンライン ワークショップ をお試しください。このワークショップでは、テキスト、画像、動画の処理のために Amazon Nova 基盤モデルと関連特徴量を効率的に使用する方法を実践的な演習を通じて学ぶことができます。 Matheus Guimaraes | @codingmatheus 原文は こちら です。

10 月 27 日週、私は AWS Shenzhen Community Day で Jeff Barr に会いました。Jeff は、世界中のビルダーが生成 AI でどのように実験しているかについて語り、これからもアイデアを実際のプロトタイプに落とし込んでいくように現地の開発者を励ましました。セッション終了後も多くの参加者がその場に残り、モデルのグラウンディングと評価、生成 AI を実際のアプリケーションに組み込む方法について話し合いました。 コミュニティビルダーたちは、Kiro をテーマにしたクリエイティブなデモ、AI 駆動の IoT プロジェクト、学生主導の実験を紹介しました。生成 AI イノベーションに対する共通の好奇心と意気込みを通じてつながる新しい開発者、学生、そして年来の Amazon Web Services (AWS) コミュニティリーダーを見ることができ、とても良い刺激になりました。 世界で最も強力なオペレーショナル AI スーパーコンピュータの 1 つである Project Rainier がオンラインになりました。Anthropic との密接なコラボレーションを通じて AWS が構築した Project Rainier は、高帯域幅、低レイテンシーのモデルトレーニングを極めて大規模に実現するために設計された新しい Amazon Elastic Compute (Amazon EC2) UltraServer と EC2 UltraCluster のアーキテクチャを使用して、 AWS がカスタム設計した Trainium2 チップ 約 50 万個をサービスに導入します。 Anthropic は Project Rainier で Claude のトレーニングと推論を既に行っており、2025 年末までに直接使用と Amazon Bedrock の全体で 100 万個を超える Trainium2 チップにスケールする予定です。アーキテクチャの詳細、デプロイに関するインサイト、UltraServer オンライン化の舞台裏動画については、「 AWS activates Project Rainier 」で発表の全文をお読みください。 11 月 3 日週のリリース 私が 10 月 27 日週注目したリリースをご紹介します。 Amazon Nova – 引用ベースのウェブ検索をリアルタイムで行うための新しい組み込みツールとして Web Grounding が追加されました。また、統合されたクロスモーダルベクトルを生成することで 検索拡張生成 (RAG) とセマンティック検索の精度を向上させる最新鋭のモデル、 Multimodal Embeddings も導入されました。どちらの機能も Amazon Bedrock でご利用いただけます。 Amazon Bedrock – TwelveLabs の Marengo Embed 3.0 が、動画、画像、音声、テキストの全体でロングフォームの動画ネイティブなマルチモーダル埋め込みに利用できるようになり、ドメイン精度も向上しました。 Stabability AI Image Services に、高解像度アップスケーリング、アウトペインティング、制御されたバリエーションのための Outpaint、Fast Upscale、Conservative Upscale、Creative Upscale の 4 つの新しいツールが追加されました。 Model Context Protocol (MCP) Proxy for AWS – SigV4 認証を使用して MCP クライアントを AWS がホストするリモート MCP サーバーに接続するクライアント側プロキシとしての一般提供が開始されました。Amazon Q Developer CLI、Kiro、Cursor、Strands Agents といったツールと連動し、読み取り専用モード、再試行ロジック、ロギングなどの安全制御を提供します。MCP Proxy for AWS はオープンソースです。 AWS GitHub リポジトリ にアクセスしてインストールや設定のオプションを確認し、リモート AWS MCP サーバーへの接続を開始できます。 Amazon Elastic Container Service (Amazon ECS) – 組み込みのリニアデプロイ戦略とカナリアデプロイ戦略 のサポートが開始されました。これらは、段階的なトラフィックシフト、小規模な本番環境スライスを使用したカナリアテスト、安全なロールバックのためのデプロイベイク時間、Amazon CloudWatch アラームベースの自動ロールバックといった機能を提供します。 Amazon DocumentDB – Amazon DocumentDB 5.0 に 新たなクエリプランナー が追加されました。このプランナーは、より的確なインデックスプランと、 $neq 、 $nin 、ネストされた $elementMatch のサポートによってクエリパフォーマンスを最大 10 倍高速化し、クラスターパラメータグループ経由でダウンタイムなしで有効化できます。 Amazon Elastic Block Store (Amazon EBS) – CloudWatch の新しいボリューム別メトリクス である VolumeAvgiOps と VolumeAvgThroughput を使用して、AWS Nitro ベースのインスタンスにアタッチされた EBS ボリュームの平均 IOPS とスループットを分単位で把握できるようになりました。これらのメトリクスは、パフォーマンス傾向を監視し、ボトルネックをトラブルシューティングして、プロビジョニングされたキャパシティを最適化するために役立ちます。 Amazon Kinesis Data Streams – 最大 10 MiB の個別レコード を送信できるようになりました。これは以前の上限の 10 倍で、より大規模な IoT、変更データキャプチャ、AI 生成のペイロードのサポートに役立ちます。 Amazon SageMaker – Unified Studio の検索結果が 追加の検索コンテキスト を提供するようになりました。このコンテキストは、一致するメタデータフィールドやランク付けの理論的根拠を提供して、データ検出における透明性と関連性を向上させます。 その他のアップデート その他の興味深いプロジェクト、ブログ記事、ニュースをいくつかご紹介します。 AWS VAMS と 4D Pipeline を用いた本番環境対応の 3D パイプラインの構築 – AWS Visual Asset Management System (VAMS) と 4D Pipeline を使用してスケーラブルなクラウドベースの 3D アセットパイプラインを作成するためのリファレンスアーキテクチャで、インジェスト、検証、共同レビュー、ゲーム全体での配信、視覚効果 (VFX)、デジタルツインをサポートします。 Amazon Location Service が新しい API キー制限を導入 – バンドル ID を使用するきめ細かなセキュリティポリシーを作成して、特定のモバイルアプリケーションへの API アクセスを制限できるようになりました。これは、ロケーションベースのワークロード全体でアクセスコントロールを向上させ、アプリケーションレベルのセキュリティを強化します。 AWS Clean Rooms が高度な SQL 設定をリリース – Spark プロパティとコンピューティングサイズのランタイムカスタム化に加えて、大規模な分析クエリのより迅速でコスト効率性に優れた処理のためのテーブルキャッシュをサポートする、Spark SQL ワークロードのためのパフォーマンス強化です。 AWS Serverless MCP Server がイベントソースマッピング (ESM) ツールを追加 – AWS Lambda イベントソースマッピングの設定、パフォーマンス調整、トラブルシューティングをサポートするイベント駆動のサーバーレスアプリケーション向けの機能で、AWS サーバーレスアプリケーションモデル (AWS SAM) テンプレートの生成と診断インサイトが含まれます。 AWS IoT Greengrass が AI エージェントコンテキストパックをリリース – クラウドに接続されたエッジアプリケーションのための開発アクセラレーターです。すぐさま使用できる指示、例、テンプレートを提供することで、チームがより迅速なソフトウェアの作成、テスト、フリート全体でのデプロイのために Amazon Q などの生成 AI ツールを統合できるようにします。エージェントコンテキストパックは、 GitHub リポジトリ でオープンソースとして利用できます。 AWS Step Functions が新しいメトリクスダッシュボードを導入 – 単一のコンソール内で、標準ワークフローと express ワークフローの使用状況、請求、パフォーマンスのメトリクスをステートマシンレベルで確認できるようになりました。これは、分散型アプリケーションの可視性を向上させ、トラブルシューティングを容易にします。 今後の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS Builder Loft – エキスパートセッションから学び、ハンズオンワークショップに参加して、AI や新興テクノロジーを検証するとともに、他のビルダーとのコラボレーションを通じてアイデアを加速させることができる、米国サンフランシスコのコミュニティテクノロジースペースです。 開催予定のセッション を閲覧して、関心のあるイベントにぜひご参加ください。 AWS Community Day – 世界中のエキスパート AWS ユーザーと業界リーダーがリードするテクニカルディスカッション、ワークショップ、ハンズオンラボが盛り込まれたコミュニティ主導のカンファレンスに参加しましょう。日程は、 香港 (11 月 2 日)、 アブジャ (11 月 8 日)、 カメルーン (11 月 8 日)、 スペイン (11 月 15 日) です。 AWS Skills Center Seattle 4 周年記念イベント – 11 月 20 日に開催される、基調講演、専門家パネル、採用担当者によるインサイト、抽選会、仮想参加オプションなどが盛りだくさんの無料公開イベントです。 AWS Builder Center に参加して、AWS コミュニティのビルダーを学び、構築し、交流しましょう。こちらで 近日開催予定の対面イベント 、 開発者に焦点を当てたイベント 、 スタートアップ向けのイベント をご覧ください。 11 月 3 日週のニュースは以上です。11 月 10 日週にお届けする次回の Weekly Roundup もお楽しみに! – Betty 原文は こちら です。

10 月 28 日、エージェンティック 検索拡張生成 (RAG) およびセマンティック検索アプリケーション向けの最先端のマルチモーダル埋め込みモデルである Amazon Nova Multimodal Embeddings をご紹介します。このモデルは Amazon Bedrock でご利用いただけます。これは、テキスト、ドキュメント、画像、動画、音声を単一のモデルを通じてサポートし、極めて高い精度のクロスモーダル検索を可能にする初の統合埋め込みモデルです。 埋め込みモデルは、テキスト、画像、音声の入力を、 埋め込み と呼ばれる数値表現に変換します。これらの埋め込みは、AI システムが比較、検索、分析できるように入力の意味を捉え、セマンティック検索や RAG などのユースケースを強化します。 組織は、テキスト、画像、ドキュメント、動画、音声コンテンツに分散している、増大し続ける非構造化データからインサイトを引き出すソリューションをますます求めています。例えば、組織には、製品の画像、インフォグラフィックとテキストを含むパンフレット、ユーザーがアップロードした動画クリップなどが存在する場合があります。埋め込みモデルは非構造化データから価値を引き出すことができますが、従来のモデルは通常、1 つのコンテンツタイプを処理するように特化しています。この制限により、お客様は、複雑なクロスモーダル埋め込みソリューションを構築するか、または単一のコンテンツタイプに特化したユースケースに制限せざるを得なくなります。また、この問題は、テキストと画像がインターリーブされたドキュメントや、ビジュアル、音声、テキスト要素を含む動画など、混合モーダルのコンテンツタイプにも当てはまります。これらのコンテンツタイプでは、既存のモデルでは、クロスモーダル関係を効果的に捉えることが困難です。 Nova Multimodal Embeddings は、混合モーダルコンテンツ間のクロスモーダル検索、参照画像を使った検索、ビジュアルドキュメントの取得などのユースケースにおいて、テキスト、ドキュメント、画像、動画、音声のための統合セマンティック空間をサポートします。 Amazon Nova Multimodal Embeddings のパフォーマンスの評価 幅広いベンチマークでモデルを評価した結果、次の表に示すとおり、すぐに活用できる極めて優れた精度を実現しました。 Nova Multimodal Embeddings は、最大 8K トークンのコンテキスト長、最大 200 言語のテキストをサポートし、同期および非同期 API を介して入力を受け付けます。さらに、セグメンテーション (「チャンキング」とも呼ばれます) をサポートし、長文のテキスト、動画、音声コンテンツを扱いやすいセグメントにパーティショニングし、各部分の埋め込みを生成します。最後に、このモデルは 4 つの出力埋め込みディメンションを提供します。これらの埋め込みディメンションは、 Matryoshka Representation Learning (MRL) を使用してトレーニングされており、精度の変動を最小限に抑えながら、低レイテンシーのエンドツーエンド検索を可能にします。 実際に新しいモデルをどのように使用できるのかを見てみましょう。 Amazon Nova Multimodal Embeddings の使用 Nova Multimodal Embeddings の開始方法は、 Amazon Bedrock の他のモデル と同じパターンに従います。このモデルは、テキスト、ドキュメント、画像、動画、または音声を入力として受け入れ、セマンティック検索、類似度比較、または RAG に使用できる数値埋め込みを返します。 ここでは、 AWS SDK for Python (Boto3) を使用して、さまざまなコンテンツタイプから埋め込みを作成し、後で取得できるように保存する方法を示す実用的な例を示します。簡潔にするために、埋め込みの保存と検索には、あらゆる規模のベクトルの保存とクエリをネイティブにサポートするコスト最適化ストレージである Amazon S3 Vectors を使用します。 まずは基本、すなわち、テキストを埋め込みに変換することから始めましょう。この例では、シンプルなテキスト記述を、その意味論的意味を捉えた数値表現に変換する方法を示します。これらの埋め込みは、後でドキュメント、画像、動画、音声からの埋め込みと比較することで、関連コンテンツを見つけることができます。 コードを理解しやすくするために、一度に示すのはスクリプトの一部にとどめます。完全なスクリプトはこのウォークスルーの最後に含まれています。 import json import base64 import time import boto3 MODEL_ID = "amazon.nova-2-multimodal-embeddings-v1:0" EMBEDDING_DIMENSION = 3072 # Amazon Bedrock ランタイムクライアントを初期化します bedrock_runtime = boto3.client("bedrock-runtime", region_name="us-east-1") print(f"Generating text embedding with {MODEL_ID} ...") # 埋め込むテキスト text = "Amazon Nova is a multimodal foundation model" # 埋め込みを作成します request_body = { "taskType": "SINGLE_EMBEDDING", "singleEmbeddingParams": { "embeddingPurpose": "GENERIC_INDEX", "embeddingDimension": EMBEDDING_DIMENSION, "text": {"truncationMode": "END", "value": text}, }, } response = bedrock_runtime.invoke_model( body=json.dumps(request_body), modelId=MODEL_ID, contentType="application/json", ) # 埋め込みを抽出します response_body = json.loads(response["body"].read()) embedding = response_body["embeddings"][0]["embedding"] print(f"Generated embedding with {len(embedding)} dimensions") 次に、スクリプトと同じフォルダにある photo.jpg ファイルを使用して、同じ埋め込み空間でビジュアルコンテンツを処理します。これは、マルチモーダリティの力を示しています。Nova Multimodal Embeddings は、テキストとビジュアルの両方のコンテキストを単一の埋め込みに取り込むことができ、ドキュメントをより深く理解できるようにします。 Nova Multimodal Embeddings は、使用方法に合わせて最適化された埋め込みを生成できます。検索または取得のユースケースのためにインデックスを作成する場合、 embeddingPurpose を GENERIC_INDEX に設定できます。クエリステップでは、取得する項目のタイプに応じて embeddingPurpose を設定できます。例えば、ドキュメントを取得する場合、 embeddingPurpose を DOCUMENT_RETRIEVAL に設定できます。 # 画像を読み取ってエンコードします print(f"Generating image embedding with {MODEL_ID} ...") with open("photo.jpg", "rb") as f: image_bytes = base64.b64encode(f.read()).decode("utf-8") # 埋め込みを作成します request_body = { "taskType": "SINGLE_EMBEDDING", "singleEmbeddingParams": { "embeddingPurpose": "GENERIC_INDEX", "embeddingDimension": EMBEDDING_DIMENSION, "image": { "format": "jpeg", "source": {"bytes": image_bytes} }, }, } response = bedrock_runtime.invoke_model( body=json.dumps(request_body), modelId=MODEL_ID, contentType="application/json", ) # 埋め込みを抽出します response_body = json.loads(response["body"].read()) embedding = response_body["embeddings"][0]["embedding"] print(f"Generated embedding with {len(embedding)} dimensions") 動画コンテンツの処理には、非同期 API を使用します。これは、 Base64 としてエンコードされたときに 25 MB を超える動画の要件です。まず、同じ AWS リージョン 内の S3 バケットにローカル動画をアップロードします。 aws s3 cp presentation.mp4 s3://my-video-bucket/videos/ この例では、動画ファイルのビジュアルと音声の両方のコンポーネントから埋め込み情報を抽出する方法を示します。セグメンテーション特徴量により、長い動画が扱いやすいチャンクに分割されるため、何時間にも及ぶコンテンツを効率的に検索できます。 # Amazon S3 クライアントを初期化します s3 = boto3.client("s3", region_name="us-east-1") print(f"Generating video embedding with {MODEL_ID} ...") # Amazon S3 URI S3_VIDEO_URI = "s3://my-video-bucket/videos/presentation.mp4" S3_EMBEDDING_DESTINATION_URI = "s3://my-embedding-destination-bucket/embeddings-output/" # 音声付き動画の非同期埋め込みジョブを作成します model_input = { "taskType": "SEGMENTED_EMBEDDING", "segmentedEmbeddingParams": { "embeddingPurpose": "GENERIC_INDEX", "embeddingDimension": EMBEDDING_DIMENSION, "video": { "format": "mp4", "embeddingMode": "AUDIO_VIDEO_COMBINED", "source": { "s3Location": {"uri": S3_VIDEO_URI} }, "segmentationConfig": { "durationSeconds": 15 # 15 秒単位のチャンクにセグメント化します }, }, }, } response = bedrock_runtime.start_async_invoke( modelId=MODEL_ID, modelInput=model_input, outputDataConfig={ "s3OutputDataConfig": { "s3Uri": S3_EMBEDDING_DESTINATION_URI } }, ) invocation_arn = response["invocationArn"] print(f"Async job started: {invocation_arn}") # ジョブが完了するまでポーリングします print("\nPolling for job completion...") while True: job = bedrock_runtime.get_async_invoke(invocationArn=invocation_arn) status = job["status"] print(f"Status: {status}") if status != "InProgress": break time.sleep(15) # ジョブが正常に完了したかどうかをチェックします if status == "Completed": output_s3_uri = job["outputDataConfig"]["s3OutputDataConfig"]["s3Uri"] print(f"\nSuccess! Embeddings at: {output_s3_uri}") # S3 URI を解析してバケットとプレフィックスを取得します s3_uri_parts = output_s3_uri[5:].split("/", 1) # プレフィックス「s3://」を削除します bucket = s3_uri_parts[0] prefix = s3_uri_parts[1] if len(s3_uri_parts) &gt; 1 else "" # AUDIO_VIDEO_COMBINED モードは、embedding-audio-video.jsonl に出力します # output_s3_uri には既にジョブ ID が含まれているため、ファイル名を付加するだけです embeddings_key = f"{prefix}/embedding-audio-video.jsonl".lstrip("/") print(f"Reading embeddings from: s3://{bucket}/{embeddings_key}") # JSONL ファイルを読み取って解析します response = s3.get_object(Bucket=bucket, Key=embeddings_key) content = response['Body'].read().decode('utf-8') embeddings = [] for line in content.strip().split('\n'): if line: embeddings.append(json.loads(line)) print(f"\nFound {len(embeddings)} video segments:") for i, segment in enumerate(embeddings): print(f" Segment {i}: {segment.get('startTime', 0):.1f}s - {segment.get('endTime', 0):.1f}s") print(f" Embedding dimension: {len(segment.get('embedding', []))}") else: print(f"\nJob failed: {job.get('failureMessage', 'Unknown error')}") 埋め込みを生成したら、それらを効率的に保存および検索するための場所が必要です。この例では、大規模な類似性検索に必要となるインフラストラクチャを提供する Amazon S3 Vectors を使用してベクトルストアをセットアップする方法を示します。これは、意味論的に類似したコンテンツが自然にクラスター化される、検索可能なインデックスを作成するものと考えてください。インデックスに埋め込みを追加する際、メタデータを使用して元の形式とインデックスの作成対象のコンテンツを指定します。 # Amazon S3 Vectors クライアントを初期化します s3vectors = boto3.client("s3vectors", region_name="us-east-1") # 設定 VECTOR_BUCKET = "my-vector-store" INDEX_NAME = "embeddings" # ベクトルバケットとインデックスを作成します (存在していない場合) try: s3vectors.get_vector_bucket(vectorBucketName=VECTOR_BUCKET) print(f"Vector bucket {VECTOR_BUCKET} already exists") except s3vectors.exceptions.NotFoundException: s3vectors.create_vector_bucket(vectorBucketName=VECTOR_BUCKET) print(f"Created vector bucket: {VECTOR_BUCKET}") try: s3vectors.get_index(vectorBucketName=VECTOR_BUCKET, indexName=INDEX_NAME) print(f"Vector index {INDEX_NAME} already exists") except s3vectors.exceptions.NotFoundException: s3vectors.create_index( vectorBucketName=VECTOR_BUCKET, indexName=INDEX_NAME, dimension=EMBEDDING_DIMENSION, dataType="float32", distanceMetric="cosine" ) print(f"Created index: {INDEX_NAME}") texts = [ "Machine learning on AWS", "Amazon Bedrock provides foundation models", "S3 Vectors enables semantic search" ] print(f"\nGenerating embeddings for {len(texts)} texts...") # Amazon Nova を使用して各テキストの埋め込みを生成します vectors = [] for text in texts: response = bedrock_runtime.invoke_model( body=json.dumps({ "taskType": "SINGLE_EMBEDDING", "singleEmbeddingParams": { "embeddingDimension": EMBEDDING_DIMENSION, "text": {"truncationMode": "END", "value": text} } }), modelId=MODEL_ID, accept="application/json", contentType="application/json" ) response_body = json.loads(response["body"].read()) embedding = response_body["embeddings"][0]["embedding"] vectors.append({ "key": f"text:{text[:50]}", # 一意の識別子 "data": {"float32": embedding}, "metadata": {"type": "text", "content": text} }) print(f" ✓ Generated embedding for: {text}") # 1 回の呼び出しで、保存するすべてのベクトルを追加します s3vectors.put_vectors( vectorBucketName=VECTOR_BUCKET, indexName=INDEX_NAME, vectors=vectors ) print(f"\nSuccessfully added {len(vectors)} vectors to the store in one put_vectors call!") この最後の例では、単一のクエリでさまざまなコンテンツタイプを検索し、テキスト、画像、動画、音声のいずれから生成されたかにかかわらず、最も類似したコンテンツを見つける機能を示します。距離スコアは、結果が元のクエリとどの程度関連しているのかを理解するのに役立ちます。 # クエリするテキスト query_text = "foundation models" print(f"\nGenerating embeddings for query '{query_text}' ...") # 埋め込みを生成します response = bedrock_runtime.invoke_model( body=json.dumps({ "taskType": "SINGLE_EMBEDDING", "singleEmbeddingParams": { "embeddingPurpose": "GENERIC_RETRIEVAL", "embeddingDimension": EMBEDDING_DIMENSION, "text": {"truncationMode": "END", "value": query_text} } }), modelId=MODEL_ID, accept="application/json", contentType="application/json" ) response_body = json.loads(response["body"].read()) query_embedding = response_body["embeddings"][0]["embedding"] print(f"Searching for similar embeddings...\n") # 最も類似した上位 5 つのベクトルを検索します response = s3vectors.query_vectors( vectorBucketName=VECTOR_BUCKET, indexName=INDEX_NAME, queryVector={"float32": query_embedding}, topK=5, returnDistance=True, returnMetadata=True ) # 結果を表示します print(f"Found {len(response['vectors'])} results:\n") for i, result in enumerate(response["vectors"], 1): print(f"{i}. {result['key']}") print(f" Distance: {result['distance']:.4f}") if result.get("metadata"): print(f" Metadata: {result['metadata']}") print() クロスモーダル検索は、マルチモーダル埋め込みの重要な利点の 1 つです。クロスモーダル検索を使用すると、テキストでクエリして、関連する画像を見つけることができます。また、テキストの説明を使用して動画を検索したり、特定のトピックに一致する音声クリップを見つけたり、ビジュアルとテキストのコンテンツに基づいてドキュメントを検出したりすることもできます。ご参考までに、これまでの例をすべてまとめた完全なスクリプトをこちらに示します: import json import base64 import time import boto3 MODEL_ID = "amazon.nova-2-multimodal-embeddings-v1:0" EMBEDDING_DIMENSION = 3072 # Amazon Bedrock ランタイムクライアントを初期化します bedrock_runtime = boto3.client("bedrock-runtime", region_name="us-east-1") print(f"Generating text embedding with {MODEL_ID} ...") # 埋め込むテキスト text = "Amazon Nova is a multimodal foundation model" # 埋め込みを作成します request_body = { "taskType": "SINGLE_EMBEDDING", "singleEmbeddingParams": { "embeddingPurpose": "GENERIC_INDEX", "embeddingDimension": EMBEDDING_DIMENSION, "text": {"truncationMode": "END", "value": text}, }, } response = bedrock_runtime.invoke_model( body=json.dumps(request_body), modelId=MODEL_ID, contentType="application/json", ) # 埋め込みを抽出します response_body = json.loads(response["body"].read()) embedding = response_body["embeddings"][0]["embedding"] print(f"Generated embedding with {len(embedding)} dimensions") # 画像を読み取ってエンコードします print(f"Generating image embedding with {MODEL_ID} ...") with open("photo.jpg", "rb") as f: image_bytes = base64.b64encode(f.read()).decode("utf-8") # 埋め込みを作成します request_body = { "taskType": "SINGLE_EMBEDDING", "singleEmbeddingParams": { "embeddingPurpose": "GENERIC_INDEX", "embeddingDimension": EMBEDDING_DIMENSION, "image": { "format": "jpeg", "source": {"bytes": image_bytes} }, }, } response = bedrock_runtime.invoke_model( body=json.dumps(request_body), modelId=MODEL_ID, contentType="application/json", ) # 埋め込みを抽出します response_body = json.loads(response["body"].read()) embedding = response_body["embeddings"][0]["embedding"] print(f"Generated embedding with {len(embedding)} dimensions") # Amazon S3 クライアントを初期化します s3 = boto3.client("s3", region_name="us-east-1") print(f"Generating video embedding with {MODEL_ID} ...") # Amazon S3 URI S3_VIDEO_URI = "s3://my-video-bucket/videos/presentation.mp4" # Amazon S3 出力バケットと場所 S3_EMBEDDING_DESTINATION_URI = "s3://my-video-bucket/embeddings-output/" # 音声付き動画の非同期埋め込みジョブを作成します model_input = { "taskType": "SEGMENTED_EMBEDDING", "segmentedEmbeddingParams": { "embeddingPurpose": "GENERIC_INDEX", "embeddingDimension": EMBEDDING_DIMENSION, "video": { "format": "mp4", "embeddingMode": "AUDIO_VIDEO_COMBINED", "source": { "s3Location": {"uri": S3_VIDEO_URI} }, "segmentationConfig": { "durationSeconds": 15 # 15 秒単位のチャンクにセグメント化します }, }, }, } response = bedrock_runtime.start_async_invoke( modelId=MODEL_ID, modelInput=model_input, outputDataConfig={ "s3OutputDataConfig": { "s3Uri": S3_EMBEDDING_DESTINATION_URI } }, ) invocation_arn = response["invocationArn"] print(f"Async job started: {invocation_arn}") # ジョブが完了するまでポーリングします print("\nPolling for job completion...") while True: job = bedrock_runtime.get_async_invoke(invocationArn=invocation_arn) status = job["status"] print(f"Status: {status}") if status != "InProgress": break time.sleep(15) # ジョブが正常に完了したかどうかをチェックします if status == "Completed": output_s3_uri = job["outputDataConfig"]["s3OutputDataConfig"]["s3Uri"] print(f"\nSuccess! Embeddings at: {output_s3_uri}") # S3 URI を解析してバケットとプレフィックスを取得します s3_uri_parts = output_s3_uri[5:].split("/", 1) # プレフィックス「s3://」を削除します bucket = s3_uri_parts[0] prefix = s3_uri_parts[1] if len(s3_uri_parts) &gt; 1 else "" # AUDIO_VIDEO_COMBINED モードは、embedding-audio-video.jsonl に出力します # output_s3_uri には既にジョブ ID が含まれているため、ファイル名を付加するだけです embeddings_key = f"{prefix}/embedding-audio-video.jsonl".lstrip("/") print(f"Reading embeddings from: s3://{bucket}/{embeddings_key}") # JSONL ファイルを読み取って解析します response = s3.get_object(Bucket=bucket, Key=embeddings_key) content = response['Body'].read().decode('utf-8') embeddings = [] for line in content.strip().split('\n'): if line: embeddings.append(json.loads(line)) print(f"\nFound {len(embeddings)} video segments:") for i, segment in enumerate(embeddings): print(f" Segment {i}: {segment.get('startTime', 0):.1f}s - {segment.get('endTime', 0):.1f}s") print(f" Embedding dimension: {len(segment.get('embedding', []))}") else: print(f"\nJob failed: {job.get('failureMessage', 'Unknown error')}") # Amazon S3 Vectors クライアントを初期化します s3vectors = boto3.client("s3vectors", region_name="us-east-1") # 設定 VECTOR_BUCKET = "my-vector-store" INDEX_NAME = "embeddings" # ベクトルバケットとインデックスを作成します (存在していない場合) try: s3vectors.get_vector_bucket(vectorBucketName=VECTOR_BUCKET) print(f"Vector bucket {VECTOR_BUCKET} already exists") except s3vectors.exceptions.NotFoundException: s3vectors.create_vector_bucket(vectorBucketName=VECTOR_BUCKET) print(f"Created vector bucket: {VECTOR_BUCKET}") try: s3vectors.get_index(vectorBucketName=VECTOR_BUCKET, indexName=INDEX_NAME) print(f"Vector index {INDEX_NAME} already exists") except s3vectors.exceptions.NotFoundException: s3vectors.create_index( vectorBucketName=VECTOR_BUCKET, indexName=INDEX_NAME, dimension=EMBEDDING_DIMENSION, dataType="float32", distanceMetric="cosine" ) print(f"Created index: {INDEX_NAME}") texts = [ "Machine learning on AWS", "Amazon Bedrock provides foundation models", "S3 Vectors enables semantic search" ] print(f"\nGenerating embeddings for {len(texts)} texts...") # Amazon Nova を使用して各テキストの埋め込みを生成します vectors = [] for text in texts: response = bedrock_runtime.invoke_model( body=json.dumps({ "taskType": "SINGLE_EMBEDDING", "singleEmbeddingParams": { "embeddingPurpose": "GENERIC_INDEX", "embeddingDimension": EMBEDDING_DIMENSION, "text": {"truncationMode": "END", "value": text} } }), modelId=MODEL_ID, accept="application/json", contentType="application/json" ) response_body = json.loads(response["body"].read()) embedding = response_body["embeddings"][0]["embedding"] vectors.append({ "key": f"text:{text[:50]}", # 一意の識別子 "data": {"float32": embedding}, "metadata": {"type": "text", "content": text} }) print(f" ✓ Generated embedding for: {text}") # 1 回の呼び出しで、保存するすべてのベクトルを追加します s3vectors.put_vectors( vectorBucketName=VECTOR_BUCKET, indexName=INDEX_NAME, vectors=vectors ) print(f"\nSuccessfully added {len(vectors)} vectors to the store in one put_vectors call!") # クエリするテキスト query_text = "foundation models" print(f"\nGenerating embeddings for query '{query_text}' ...") # 埋め込みを生成します response = bedrock_runtime.invoke_model( body=json.dumps({ "taskType": "SINGLE_EMBEDDING", "singleEmbeddingParams": { "embeddingPurpose": "GENERIC_RETRIEVAL", "embeddingDimension": EMBEDDING_DIMENSION, "text": {"truncationMode": "END", "value": query_text} } }), modelId=MODEL_ID, accept="application/json", contentType="application/json" ) response_body = json.loads(response["body"].read()) query_embedding = response_body["embeddings"][0]["embedding"] print(f"Searching for similar embeddings...\n") # 最も類似した上位 5 つのベクトルを検索します response = s3vectors.query_vectors( vectorBucketName=VECTOR_BUCKET, indexName=INDEX_NAME, queryVector={"float32": query_embedding}, topK=5, returnDistance=True, returnMetadata=True ) # 結果を表示します print(f"Found {len(response['vectors'])} results:\n") for i, result in enumerate(response["vectors"], 1): print(f"{i}. {result['key']}") print(f" Distance: {result['distance']:.4f}") if result.get("metadata"): print(f" Metadata: {result['metadata']}") print() 本番アプリケーションでは、埋め込みは任意のベクトルデータベースに保存できます。 Amazon OpenSearch Service は、リリース時に Nova Multimodal Embeddings とのネイティブ統合を提供しているため、スケーラブルな検索アプリケーションを簡単に構築できます。前の例で示したように、 Amazon S3 Vectors を使用すると、アプリケーションデータを使用して埋め込みを簡単に保存およびクエリできます。 知っておくべきこと Nova Multimodal Embeddings は、3,072、1,024、384、256 の 4 つの出力ディメンションオプションを提供します。ディメンションが大きいほど詳細な表現が得られますが、より多くのストレージと計算が必要になります。ディメンションが小さいほど、検索パフォーマンスとリソース効率の実用的なバランスを実現できます。この柔軟性は、特定のアプリケーションとコスト要件に合わせて最適化するのに役立ちます。 このモデルは、かなり長いコンテキストを処理できます。テキスト入力では、一度に最大 8,192 トークンを処理できます。動画と音声の入力は最大 30 秒のセグメントをサポートし、モデルはより長いファイルをセグメント化できます。このセグメンテーション機能は、特に大容量のメディアファイルを扱う際に役立ちます。モデルはファイルを扱いやすいサイズに分割し、各セグメントの埋め込みを作成します。 このモデルには、Amazon Bedrock に組み込まれた責任ある AI の機能が含まれています。埋め込み用に送信されたコンテンツは、Amazon Bedrock のコンテンツセーフティフィルターを通過します。また、モデルには、バイアスを低減するための公平性対策が含まれています。 コード例で説明されているように、このモデルは同期 API と非同期 API の両方を通じて呼び出すことができます。同期 API は、検索インターフェイスでのユーザークエリの処理など、即時の応答が必要なリアルタイムアプリケーションに適しています。非同期 API は、レイテンシーの影響が小さいワークロードをより効率的に処理するため、動画などの大容量コンテンツの処理に適しています。 利用可能なリージョンと料金 Amazon Nova Multimodal Embeddings は、米国東部 (バージニア北部) の AWS リージョン の Amazon Bedrock で本日よりご利用いただけます。料金の詳細については、 Amazon Bedrock の料金ページ にアクセスしてください。 詳しくは、包括的なドキュメントについては「 Amazon Nova ユーザーガイド 」、実用的なコード例については GitHub の Amazon Nova モデルクックブック をご覧ください。 Amazon Q Developer や Kiro などの AI を利用したアシスタントをソフトウェア開発に使用している場合は、AI アシスタントが AWS のサービスやリソースとインタラクションするのに役立つように AWS API MCP サーバー をセットアップしたり、最新のドキュメント、コードサンプル、AWS API と CloudFormation リソースのリージョンレベルの可用性に関するナレッジを提供するために AWS Knowledge MCP サーバー をセットアップしたりできます。 今すぐ Nova Multimodal Embeddings を使用してマルチモーダル AI を利用したアプリケーションの構築を開始し、 AWS re:Post for Amazon Bedrock または通常の AWS サポートの連絡先を通じてフィードバックをぜひお寄せください。 – Danilo 原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの西村です。 今週も 週刊AWS をお届けします。 いきなりですが、「お祭り」のご案内です！11月5日(水)にコスト最適化の最新アップデートや生成AIを活用したメソッドを学ぶ「 AWS 秋のCost Optimization祭り 2025 」が、そして 11月6日(木) は生成 AI を使ったAWS オブザーバビリティの最新動向を学ぶ「 AWS 秋のオブザーバビリティ祭り 2025 」が開催されます。両日とも AWS Startup Loft Tokyo で 19:00 から開始予定です。 だんだん寒くなってきましたが、秋夜にアツい２日間を過ごしてみるのはいかがでしょうか？ AWS のコスト最適化や可観測性に課題をお持ちの方も、ただただ興味があるという方も、ぜひ参加してみてください！ それでは、先週の主なアップデートについて振り返っていきましょう。 2025年10月27日週の主要なアップデート 10/27(月) Amazon SageMaker が検索結果に追加の検索コンテキストを追加 Amazon SageMaker Unified Studio の検索機能が大幅に改善されました。これまで検索結果がなぜ表示されるのか分からず、関連性を判断するのに時間がかかっていましたが、今回のアップデートでメタデータのどの部分がクエリにマッチしたかが視覚的に分かるようになりました。名前、説明、用語集、スキーマなどの各フィールドでマッチした箇所がハイライト表示され、説明パネルで詳細も確認できます。これにより、データ発見の効率が向上し、不要なアセットを開かずに関連性を素早く判断できるようになります。詳細は こちらのドキュメントをご参照ください。 Amazon Redshift Serverless が AWS アジアパシフィック (大阪) およびアジアパシフィック (マレーシア) リージョンで利用可能になりました Amazon Redshift Serverless が大阪リージョンとマレーシアリージョンで利用可能になりました。データウェアハウスクラスターの管理が不要で、データ分析を数秒で開始できます。従来は事前にノードタイプやクラスター設定を決める必要がありましたが、今回のサービスでは自動的にキャパシティを調整し、使った分だけの従量課金となります。Query Editor V2 ですぐにクエリを実行でき、データアナリストや開発者が手軽に分析環境を構築できるようになりました。詳細は こちらの機能ページをご参照ください。 Amazon ECS マネージドインスタンス が全ての商用 AWS リージョンで利用可能になりました Amazon ECS マネージドインスタンスが全商用リージョンで利用可能になりました。このサービスは ECS において EC2 を利用時に、EC2 のインフラストラクチャ管理を AWS に任せつつ、全機能へのアクセスを提供するよう設計された、新しいフルマネージドのオプションです。これまで東京リージョンを含む６つのリージョンで利用可能でしたが、今回のアップデートで大阪リージョンを含むすべての商用リージョンで利用することできるようになりました。Amazon ECS マネージドインスタンスの詳細は こちらの Blog 記事をご参照ください。 10/28(火) AWS Resource Explorer が 47 の追加リソースタイプをサポート AWS Resource Explorer が 47 の新しいリソースタイプに対応し、Amazon Bedrock や AWS Shield、AWS Glue などのリソースも検索できるようになりました。これまで個別のサービスコンソールでしか確認できなかったリソースを、Resource Explorer で一括検索できるため、複数のサービスを利用している環境でのリソース管理が大幅に効率化されます。詳細は こちらのドキュメントをご参照ください。 Amazon Nova マルチモーダル埋め込みの発表 Amazon Nova Multimodal Embeddings が一般提供開始されました。これまではテキスト、画像、動画、音声それぞれに専用のモデルが必要でしたが、今回の新モデルでは単一モデルですべてのコンテンツタイプを処理できます。動画アーカイブから複雑な検索クエリでコンテンツを探したり、顧客の質問に基づいて関連商品画像を見つけるなど、クロスモーダルな検索が可能になります。バージニア北部リージョンの Amazon Bedrock で利用できます。詳細は こちらの Blog 記事をご参照ください。 Amazon Kinesis Data Streams が 10 倍大きなレコードサイズをサポート Amazon Kinesis Data Streams のレコードサイズ上限が従来の 1 MiB から 10 MiB に 10 倍拡大されました。これまで大きなデータを扱う際は別の処理パイプラインが必要でしたが、今回のアップデートにより IoT データ分析や AI ワークロードなどで間欠的に発生する大容量データも単一のストリームで処理できるようになり、運用負荷が大幅に軽減されます。詳細は こちらのドキュメントをご参照ください。 10/29(水) Web Grounding: Amazon Nova モデルで正確な AI アプリケーションを構築 Amazon Nova モデルの新機能 Web Grounding が一般提供開始されました。この機能により、Amazon Nova モデルが Web 上の最新情報を自動で取得し、その情報を引用付きで回答に活用するAIアプリケーションの構築が可能となります。従来の AI モデルでは古い学習データに基づく回答や不正確な内容 (ハルシネーション) が課題でしたが、Web Grounding を使うことでリアルタイムの正確な情報に基づいた回答が可能になります。現在 Nova Premier で利用でき、バージニア北部、オハイオ、オレゴンリージョンで提供中です。詳細は こちらの Blog 記事をご参照ください。 Amazon S3 がコピー操作に条件付き書き込み機能を追加 Amazon S3 のコピー操作で条件付き書き込み機能が利用できるようになりました。複数のユーザーが同じオブジェクトに同時アクセスする際、意図しない上書きを防げます。if-match や if-none-match ヘッダーを使用することで、コピー先にオブジェクトが存在するかや内容が変更されているかを事前チェック可能です。全リージョンで追加料金なしで利用でき、従来必要だったクライアント側の調整処理が不要になります。詳細は こちらのドキュメントをご参照ください。 Amazon EBS が EBS ボリュームの追加パフォーマンス監視メトリクスを導入 Amazon EBS で新しい CloudWatch メトリクス VolumeAvgIOPS と VolumeAvgThroughput が追加されました。これにより EBS ボリュームの平均 IOPS と平均スループットを 1 分間隔で監視できるようになり、パフォーマンスのトレンド分析やボトルネックの特定が簡単になります。従来は詳細なパフォーマンス監視が困難でしたが、これらのメトリクスを使ってダッシュボード作成やアラーム設定も可能です。EC2 Nitro インスタンスに接続された全ての EBS ボリュームで無料利用できます。詳細は こちらのドキュメントをご参照ください。 10/30(木) Amazon Managed Service for Prometheus が異常検知機能を追加 Amazon Managed Service for Prometheus にアノマリー検知機能が追加されました。機械学習により時系列データの異常を自動検知し、従来は手動で監視していた異常値を自動で発見できるようになります。システムの性能低下やエラー急増などを早期発見でき、運用負荷を大幅に軽減します。検知結果は Grafana で可視化でき、アラート設定も可能です。詳細は こちらのドキュメントをご参照ください。 Amazon Bedrock AgentCore Browser が Web Bot Auth (プレビュー) で CAPTCHA を削減 Amazon Bedrock AgentCore Browser で Web Bot Auth (プレビュー) が利用可能になりました。この機能により、AI エージェントがウェブサイトを自動操作する際の CAPTCHA による中断を大幅に減らせます。従来は AI エージェントが人間による手動介入を必要とする場面が多くありましたが、Web Bot Auth により AI エージェントが信頼できる存在として認識され、スムーズな自動化ワークフローを実現できます。詳細は こちらの Blog 記事をご参照ください。 AWS Backup が AWS リージョンとアカウント間でのデータベーススナップショットの単一アクションコピー機能を追加 AWS Backup で、データベースのスナップショットを異なるリージョンやアカウントに 1 回の操作でコピーできるようになりました。従来は 2 段階の手順が必要でしたが、この機能により RDS、Aurora、Neptune、DocumentDB のスナップショットを直接コピー可能です。ランサムウェア攻撃やリージョン障害から保護でき、中間コピーのコストも削減されます。詳細は こちらのドキュメントをご参照ください。 Amazon ECS で Linear デプロイメントとCanary デプロイメントの組み込みサポートを開始 Amazon ECS で Linear(線形)と Canary デプロイメント戦略が利用できるようになりました。従来の Blue/Green デプロイメントに加えて、より柔軟なデプロイメント方法が選択可能です。Linear(線形) デプロイメントでは段階的にトラフィックをシフト (例: 10% ずつ) し、各段階で動作確認できます。Canary デプロイメントでは少量のトラフィックを新バージョンに向けて検証後、残りのトラフィックを移行します。CloudWatch アラームと連携した自動ロールバック機能により、問題発生時の迅速な対応が可能です。詳細は こちらのドキュメントをご参照ください。 10/31(金) Amazon VPC IPAM がプレフィックスリストの更新を自動化 Amazon VPC IPAM で、プレフィックスリストの更新を自動化する prefix list resolver (PLR) 機能が追加されました。これまで VPC や サブネット の IP アドレス範囲が変更されるたびに、手動でプレフィックスリストを更新する必要がありましたが、PLR により自動同期が可能になります。ルートテーブルやセキュリティグループで参照するプレフィックスリストが、ビジネスルールに基づいて自動更新されるため、運用負荷が大幅に軽減されます。全リージョンで利用可能です。 詳細はこちらのドキュメントをご参照ください。 AWS 向け Model Context Protocol (MCP) Proxy が一般提供開始 AWS が Model Context Protocol (MCP) Proxy for AWS の一般提供を開始しました。これにより、AI 開発ツール (Amazon Q Developer CLI や Cursor など) から AWS SigV4 認証を使って AWS のリソースに安全にアクセスできるようになります。例えば S3 バケットや RDS テーブルなどの AWS サービスを AI エージェントから直接操作可能です。読み取り専用モードやリトライ機能などの安全機能も搭載しており、開発者は安心して AI ワークフローに AWS サービスを組み込めます。詳細は こちらの GitHub リポジトリをご参照ください。 AWS PrivateLink が AWS サービスのクロスリージョン接続をサポート AWS PrivateLink がクロスリージョン接続に対応しました。これまで Interface VPC エンドポイントは同一リージョン内の AWS サービスにしか接続できませんでしたが、今回のアップデートにより他リージョンの Amazon S3 や Route 53、ECR などに VPC ピアリングやパブリックインターネットを経由せずプライベート接続が可能になります。データレジデンシー要件を満たしつつ、グローバルなプライベートネットワーク構築に活用できます。詳細は こちらのドキュメントをご参照ください。 今年の AWS re:Invent まであと約１ヶ月と迫ってきました。おそらく開催前の 11 月も多くのサービスアップデートが発表されると思いますので、情報の準備体操をお願いします！ それでは、また来週！ 著者について 西村 忠己(Tadami Nishimura) / @tdmnishi AWS Japan のソリューションアーキテクトとして、小売・消費財業種のお客様を担当しています。データガバナンスの観点から、お客様がデータ活用を効果的に行えるようなデモンストレーションなども多く行っています。好きなサービスは Amazon Aurora と Amazon DataZone です。趣味は筋トレで、自宅に徒歩０分のトレーニングルームを構築して、日々励んでいます。

みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。11月が始まり、心の中ではre:invent へのカウントダウンを始めました。今年は何が発表されるのでしょうか。。。！？ そして毎年おなじみAWS Japanから提供する re:invent 速報を今年も開催いたします。ぜひ こちらのページ より事前登録をお願いいたします。 先日 2つの新しいプランを追加した「 AWS ジャパン生成 AI 実用化推進プログラム 」も非常に多くの申し込みをいただいています。引き続き募集中ですのでよろしくお願いします。 それでは、10 月 6 日週の生成 AI with AWS界隈のニュースを見ていきましょう。先週はBedrock上で利用することができる新モデルやモデル向けツールの発表が多数ありました。 さまざまなニュース AWS 生成 AI 国内事例ブログ: 仰星監査法人様の AWS 生成 AI 活用事例 ：株式会社 Sapeet 様支援のもと、Dify を用いて生成 AI アプリを構築し、機微な情報を扱えるセキュアな環境でクライアント情報の収集・環境分析調査時間の 87% 削減を実現 仰星監査法人様は、株式上場 (IPO) 支援業務やファイナンシャルアドバイザリーサービスなどの各種サービスを提供する法人です。監査業務では、クライアント情報の収集や環境分析に多くの時間を要し、業務効率化が課題となっていました。この課題を解決するため、株式会社Sapeet様の支援のもと、Amazon Bedrock や Difyを採用し、生成AIアプリケーションを構築しました。機微な情報を扱えるセキュアな環境を実現しながら、クライアント情報の収集・環境分析調査時間の87%削減という大きな成果を上げています。 AWS 生成 AI 国内事例ブログ: ロジカル・アーツ株式会社様の AWS 生成 AI 事例「コールセンター業務の効率化と品質向上を実現する生成 AI コンタクトセンター」 従来のコールセンター業務では、オペレーターの対応品質のばらつきや、問い合わせ対応の効率化が課題となっていました。これらの課題を解決するため、ロジカル・アーツ株式会社様は Amazon Bedrockを活用した生成AIコンタクトセンターソリューションを構築しました。生成AIにより、リアルタイムでのオペレーター支援、自動応答の生成、通話内容の要約などが可能になり、顧客対応の効率化と品質の均一化を実現しています。特に、生成 AI による会話リアルタイム文字起こしと会話議事録生成機能により、エージェントのアフターコールワーク（ACW）時間が 75% 削減され、従来 20 分かかっていた作業が 5 分で完了できるようになりました。この時間短縮により、電話対応件数が 100% 増加し、従来 20 人で対応していた業務量を 10 人で処理できるようになったことで、人的リソースの最適化を実現しました。今後は、さらなる機能拡張を通じて、コールセンター業務の更なる高度化を目指しています。 ブログ記事「 AWS 金融リファレンスアーキテクチャ日本版 2025 (v1.6) アップデート 」を公開 AWS 金融リファレンスアーキテクチャ日本版がバージョン1.6にアップデートされました。この記事では、金融機関がAWS上でセキュアかつスケーラブルなシステムを構築するためのベストプラクティスとアーキテクチャパターンを紹介しています。今回のアップデートでは、生成AIを活用した金融サービスの実装パターンや、最新のセキュリティ要件への対応方法が追加されています。金融業界特有の規制要件に対応しながら、生成AIを活用する際の参考アーキテクチャとして活用いただけます。 ブログ記事「 エージェントステアリングと MCP を使って Kiro に新しいスキルを教える方法 」を公開 この記事では、Kiro における2つの重要な新機能を紹介しています。1つ目は「エージェントステアリング」で、エージェントの動作をより細かく制御し、特定のタスクに最適化できるようになりました。2つ目は「Model Context Protocol (MCP)」のサポートで、外部ツールやデータソースとの統合が容易になります。記事では、これらの機能を使ってKiroに独自ライブラリを理解させ、連携する例を通じて、エージェント開発の新しいアプローチを解説しています。開発者がAIエージェントをより効果的に活用するための参考になる内容です。 サービスアップデート AWS Marketplace、AIエージェントとツールの価格モデルの柔軟性を提供 AWS Marketplaceは、AIエージェントとツールに対して柔軟な価格モデル、簡素化された認証、効率化されたデプロイメントを提供開始しました。Amazon Bedrock AgentCore Runtimeコンテナに対する契約ベースおよび使用量ベースの価格設定が可能になり、顧客は自社のビジネスモデルに最適な価格体系を選択できます。また、認証プロセスが簡素化され、デプロイメントの複雑さが軽減されることで、AIエージェントソリューションの導入がより容易になります。これにより、ISVはAIエージェントソリューションをより柔軟に提供でき、顧客は自社のニーズに合わせた選択が可能になります。 Amazon Bedrock AgentCore Browser、Web Bot Authで CHAPCHA を削減（プレビュー） Amazon Bedrock AgentCore BrowserがWeb Bot Authをサポートし、AIエージェントが大規模にウェブサイトと対話する際の CHAPCHA による中断を削減できるようになりました（プレビュー）。従来、AIエージェントがウェブサイトにアクセスする際、ボット検出システムによってCHAPCHA認証を求められることが多く、自動化の妨げとなっていました。Akamai Technologies、Cloudflare、HUMAN Securityなどの主要なセキュリティプロバイダーとの連携により、正当なAIエージェントのアクセスを効率的に検証し、CHAPCHAの表示を削減します。これにより、AIエージェントによるウェブ自動化がよりスムーズに実行できるようになります。 TwelveLabs Pegasus 1.2モデルが3つの追加AWSリージョンで利用可能に TwelveLabsの動画理解モデルPegasus 1.2が、米国東部（バージニア北部）、米国西部（オレゴン）、欧州（フランクフルト）の3つの追加AWSリージョンで利用可能になりました。Pegasus 1.2は、動画コンテンツの分析、検索、要約などを高精度で実行できる動画理解AIモデルです。これにより、より多くのリージョンで動画分析ソリューションを構築できるようになり、レイテンシーの削減やデータレジデンシー要件への対応が容易になります。 TwelveLabs Marengo Embed 3.0、Amazon Bedrockで高度な動画理解を実現 TwelveLabsのMarengo Embed 3.0がAmazon Bedrockで利用可能になりました。このモデルは、動画、画像、音声、テキストを単一の表現空間に統合する動画ネイティブマルチモーダル埋め込み機能を提供します。最大4時間の動画と音声コンテンツを処理でき、スポーツ分析の改善や36言語へのグローバル多言語サポートが含まれています。 Amazon Nova Multimodal Embeddingsを発表 Amazon Nova Multimodal Embeddingsの一般提供が開始されました。テキスト、ドキュメント、画像、動画、音声を単一のモデルでサポートする統合埋め込みモデルで、クロスモーダル検索を実現します。最大8Kトークンの入力と最大30秒の動画/音声セグメントをサポートしています。 Stability AI Image Services、Amazon Bedrockで4つの新しい画像編集ツールを追加 Amazon Bedrock で利用することができる Stability AI Image Services に4つの新しい画像編集ツール（Outpaint、Fast Upscale、Conservative Upscale、Creative Upscale）を追加しました。これらのツールにより、クリエイターはワークフローをより細かく制御でき、コンセプトを完成品に効率的に変換できます。 &nbsp;Amazon NovaモデルでWeb Grounding機能が一般提供開始 Amazon Novaモデル向けの新しい組み込みツール「Web Grounding」の一般提供が開始されました。Web Groundingは、公開されている情報を引用付きで取得し、応答のコンテキストとして組み込むことができるツールです。開発者は、現在のリアルタイム情報を使用したRAGソリューションを実装でき、ハルシネーションを削減できます。 Model Context Protocol (MCP) Proxy for AWSが一般提供開始 Model Context Protocol (MCP) Proxy for AWSの一般提供が開始されました。MCPは、AIアプリケーションがコンテキスト情報を標準化された方法で共有するためのオープンプロトコルです。このプロキシにより、MCPクライアントがAWS SigV4認証を使用してリモートのAWSホスト型MCPサーバーに安全に接続できるようになります。Amazon Q Developer CLI、Kiro、Cursorなどの人気のエージェント型AI開発ツールをサポートしており、読み取り専用モードなどの安全制御機能を備えています。これにより、開発者はAIエージェントと外部システムの統合をより安全かつ容易に実現できます。 AWS IoT Greengrass開発者向けAIエージェントコンテキストパックを発表 AWS IoT Greengrass開発者向けのAIエージェントコンテキストパックが発表されました。このコンテキストパックは、AIエージェントがIoT Greengrassの開発タスクを支援するために必要な情報を提供します。開発者は、AIエージェントを活用してIoTアプリケーションの開発、デバッグ、最適化をより効率的に行うことができます。 AWS Serverless MCP Server、AWS Lambda Event Source Mapping (ESM) ツールをサポート AWS Serverless Model Context Protocol (MCP) Serverが、AWS Lambda Event Source Mapping (ESM) 用の専用ツールをサポートするようになりました。これらのツールは、開発者がイベント駆動型サーバーレスアプリケーションのセットアップ、最適化、トラブルシューティングを効率化します。 AI/ML/HPCインスタンスタイプ向け Capacity Reservation Topology API を発表 Capacity Reservation Topology APIが、AI/ML/HPCワークロード向けのインスタンスタイプをサポートしました。このAPIにより、大規模な生成AIモデルのトレーニングや推論に必要な計算リソースを、最適なネットワークトポロジーで予約できます。特に、複数のGPUインスタンス間の高速通信が必要な分散学習において、パフォーマンスの向上が期待できます。 Amazon SageMaker、検索コンテキスト機能を追加 Amazon SageMakerに検索コンテキスト機能が追加されました。この機能により、機械学習モデルの開発過程で、関連する実験、モデル、データセットを効率的に検索し、コンテキストを把握できるようになります。大規模なML開発プロジェクトにおいて、過去の実験結果や関連リソースを素早く見つけることができ、開発効率が向上します。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航&nbsp; (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近見たアニメは「光が死んだ夏」です。

2025年10月7日、大規模分散アプリケーションの監視を簡素化する Amazon CloudWatch Application Signals の強化機能を新たに発表できることを嬉しく思います。CloudWatch Application Signals の アプリケーションマップ の改善により、サービスの検出、及びグループ化をサービスの関係性を元に自動的に行える様になりました。また、ビジネスの観点に合わせたカスタムグループもサポートします。最新のサービスデプロイ時間を確認し、 サービスレベル指標 （SLI）違反等の問題に関する自動監査結果を評価できるようになりました。 主な機能と特徴 CloudWatch Application Signals のアプリケーションマップは、サービスレベル目標（SLO）や健全性指標などの運用シグナルを表示します。コンテキストに応じたトラブルシューティングドロワーにより、標準メトリクス、最新のデプロイステータス、実用的なインサイトに即座にアクセスできます。より詳細な分析のために、包括的なトラブルシューティング用にカスタマイズされたアプリケーション固有のダッシュボードにシームレスに移行できます。この統合された体験により、チームは根本原因をより迅速に特定し、平均解決時間を短縮できます。 即座に利用可能 AWSアカウント で Application Signals がすでに有効になっている場合、これらの新機能を使い始めるために追加の設定は必要ありません。Application Signals を有効にするには、 アカウントで Application Signals を有効にする を参照して、Application Signals がサービスを検出するために必要な権限を付与する必要があります。ご自身のアプリケーションに実装する前にサンプルアプリで CloudWatch Application Signals を試す際には、この AWS ドキュメント の手順に従ってください。 根本原因分析 DevOps エンジニアは、アプリケーションマップを使用してインシデント発生時に根本原因を迅速に特定できます。サービスが高いエラー率を示している場合、影響を受けたノードをクリックすると、トラブルシューティングドロワーにメトリクス、最近のデプロイ、依存関係の健全性が表示されます。エンジニアは、メトリクス、最新のデプロイ、SLI違反などの問題に関する監査結果を確認できます。 図1. サービス このトラブルシューティングプロセスをさらに効率化するために、生成AI搭載アシスタントである CloudWatch Investigations がシステムのテレメトリをスキャンし、問題に関連する関連データと提案を即座に表示します。Application Signals は CloudWatch Investigations と統合されており、サービスダッシュボードから 調査 を開始できます。 図2. 調査 CloudWatch Application Signals のアプリケーションマップは、標準グループ化を通じてサービスの探索とトラブルシューティングを簡素化します。デフォルトでは、サービスはダウンストリームの依存関係に基づいて自動的にグループ化されます。 グループの管理 を使用して、ビジネス要件と運用上の優先順位に基づいてサービスを整理するための独自のカスタムグループを定義できます。フィルターは、デプロイの変更、SLI違反、または Amazon Elastic Kubernetes Service（Amazon EKS）、Amazon Elastic Container Service（Amazon ECS）、AWS Lambda などのコンピューティングプラットフォームに焦点を当てるのに役立ちます。「View insights」機能は、サービスの健全性、変更履歴、メトリクスを表示します。ダッシュボードには、リソース分析と属性フィルタリングのビューが含まれており、根本原因分析を複数の観点から開始することができます。 図3. アプリケーションマップ まとめ このリリースにより、AWS上の大規模分散アプリケーションを監視およびトラブルシューティングできるようになります。サービスとアプリケーションの依存関係を自動的にグループ化し、コンテキストに応じた運用インサイトを提供することで、カスタムダッシュボードの維持負担を排除し、運用メンテナンス時間を削減します。アプリケーションの複雑さが増し続ける中、AWSのアプリケーション中心のオブザーバビリティアプローチは、チームが大規模で信頼性が高くパフォーマンスの高いサービスを維持するために必要な可視性とツールを提供します。 それでは、探索を始めましょう。 バーチャルツアー ：Application Signals がアプリケーションをどのように可視化し、トラブルシューティングを改善し、監視を変革するかを直接体験したいですか？ 独自の環境をセットアップすることなく、この インタラクティブ なバーチャルツアーをご利用ください。 デモのスケジュール ：AWSアカウントチームに連絡して、アプリケーション監視体験をどのように変革できるかをご確認ください。 AWSオブザーバビリティを始める ：包括的な監視を実装してオブザーバビリティの基盤を強化し、効果的な分析に必要なデータを確実にキャプチャできるようにします。 オブザーバビリティワークショップ ：AWSがアプリケーションのオブザーバビリティを実現するために提供する幅広いツールセットのハンズオン体験を探索してください。 TAGS: Amazon CloudWatch , Application Performance Monitoring , observability Arun Chandapillai Arun Chandapillaiは、ダイバーシティ＆インクルージョンのチャンピオンであるシニアクラウドアーキテクトです。彼は、ビジネスファーストのクラウド導入戦略を通じてお客様のIT近代化を加速し、クラウドでアプリケーションとインフラストラクチャを成功裏に構築、デプロイ、管理することを支援することに情熱を注いでいます。Arunは自動車愛好家であり、熱心なスピーカーであり、「与えたものが（返って）得られる」と信じる慈善家です。 Siva Guruvareddiar Siva Guruvareddiarは、AWSのシニアソリューションアーキテクトであり、お客様が高可用性システムを設計することを支援することに情熱を注いでいます。彼は、マイクロサービス、コンテナ化、可観測性、サービスメッシュ領域、およびクラウド移行を使用してプラットフォームインフラストラクチャと内部アーキテクチャをモダナイズすることにより、クラウドネイティブ導入の取り組みを加速することを支援しています。LinkedIn： linkedin.com/in/sguruvar Mitun Lahiri CloudWatch Application Signals のソフトウェア開発マネージャー 本記事は、 Amazon CloudWatch Application Signals new enhancements for application monitoring を翻訳したものです。翻訳は Technical Account Manager の 日平 が担当しました。

AWS X-Ray 用の SDK と Daemon は2026年2月25日にメンテナンスモードに入り、2027年2月25日にサポート終了となります。OpenTelemetry ベースの計装ソリューションへ移行することで、AWS 内でアプリケーションのトレースを継続して生成できます。 AWS X-Ray 用の X-Ray SDK と Daemon を使用している既存のアプリケーションは、意図された通りに機能し続けます。ただし、2026年2月25日から2027年2月25日の間、X-Ray SDK とDaemon は重要なバグ修正とセキュリティアップデートのみ対応され、新機能をサポートするための更新は行われません。例えば、SDK は追加のライブラリ計装や既存のライブラリ計装の機能強化は対応されません。 以下の表は、X-Ray SDK と Daemon のライフサイクルの各フェーズにおけるサポートレベルの概要を示しています。 SDK ライフサイクルフェーズ 開始日 終了日 サポートレベル 一般提供 N/A 2026年2月25日 この段階では、SDK と Daemon は完全にサポートされます。AWSは、バグ修正とセキュリティ修正を含む定期的な SDK / Daemon リリースを提供します。 メンテナンスモード 2026年2月25日 2027年2月25日 AWS は、重要なバグ修正とセキュリティ問題への対応を目的とした SDK と Daemon のリリースのみを行います。SDK / Daemon は新機能の拡張を受け取ることはありません。 サポート終了 2027年2月25日 N/A SDK と Daemon は、今後アップデートやリリースを受け取ることはありません。以前に公開されたリリースは、パブリックパッケージマネージャーを通じて引き続き利用可能であり、コードは GitHub 上に残ります。 AWS X-Ray は、アプリケーショントレースとオブザーバビリティの主要な計装標準として OpenTelemetry に移行しています。アプリケーションからトレースを生成して AWS X-Ray に送信するために、OpenTelemetry ベースの計装ソリューションへの移行をお勧めします。コンソールでの体験は従来と同じままです。 OpenTelemetry は、トレーシング計装とオブザーバビリティのための業界全体のオープンソース標準であり、IT チームにテレメトリデータの収集とルーティングのための標準化されたプロトコルとツールを提供します。メトリクス、ログ、トレースなどのアプリケーションテレメトリデータを計装、生成、収集し、分析と洞察のためにモニタリングプラットフォームにエクスポートするための統一されたフォーマットを提供します。これにより、より迅速な機能開発と、業界全体で一貫したより広範なツールと統合のセットが実現されます。OpenTelemetry 計装ソリューションは、フレームワークとライブラリの計装、より多くの言語サポート、およびゼロコード計装機能に対してより幅広いサポートを提供します。 移行を支援するために、AWS X-Ray ドキュメントで移行ガイダンスと例を見つけることができます。 https://docs.aws.amazon.com/ja_jp/xray/latest/devguide/xray-sdk-migration.html Amazon CloudWatch において、AWS Distro for OpenTelemetry (ADOT) やネイティブな OpenTelemetry に移行すると、アプリケーションヘルスモニタリングの強化のための CloudWatch Application Signals や、アプリケーションのトランザクションスパンへの完全な可視性を提供する Transaction Search などの強力なツールにアクセスできるようになります。 OpenTelemetryについてさらに学び、OpenTelemetry を活用する AWS CloudWatch のより多くのソフトウェアソリューションを活用するには、以下のリソースを参照してください。 Amazon CloudWatch with OpenTelemetry では、OpenTelemetry を使用してアプリケーションで CloudWatch を使用する方法を説明し、 Application Signals や Transaction Search などの強力なツールを有効にする方法を説明しています。 X-Ray 計測から OpenTelemetry 計測への移行 では、 AWS Distro for OpenTelemetry (ADOT) または OpenTelemetry SDK の使用に切り替える方法の例を説明しています。 OpenTelemetry の公式ドキュメントでは、OpenTelemetry の使用に関するすべてのノウハウを説明しています。 フィードバック サポートが必要な場合やフィードバックがある場合は、AWS サポートまでお問い合わせください。 https://aws.amazon.com/jp/contact-us/ また、GitHub ( Java , Python , JavaScript , .NET , Go , Ruby ) でディスカッションやissueを開くこともできます。AWS X-Ray SDKs と Daemon for AWS X-Ray をご利用いただき、ありがとうございました。 Jonathan Lee Jonathan Leeは、AWS の AWS Application Observability のソフトウェア開発エンジニアです。彼は、アップストリームと AWS Distro of OpenTelemetry の両方でオープンソースに貢献しています。 Naina Thangaraj Naina Thangaraj は AWS Batch のシニアプロダクトマネージャーであり、AWS の Advanced Computing and Simulation 組織で働いています。彼女のバックグラウンドはバイオインフォマティクスで、AWS に入社する前は、ヘルスケアとライフサイエンス業界で働いていました。 本記事は、 Announcing AWS X-Ray SDKs/Daemon End-of-Support and OpenTelemetry Migration を翻訳したものです。翻訳は Technical Account Manager の 日平 が担当しました。

※&nbsp;この投稿はお客様に寄稿いただいた記事です。 本稿では株式会社 NTTドコモ（以下、ドコモ）の主要な Web サービス提供基盤である『 POPLAR 』において、 Amazon Q Developer 活用により開発効率向上を実現した取り組みについて、全 2 回に分けてご紹介します。 第1回：NTT ドコモの Web サービス基盤『 POPLAR 』開発における Amazon Q Developer 活用 (本記事) 第2回： Amazon Q Developer 活用をプロジェクト全体へ拡げた取り組み 1.はじめに 『 POPLAR 』は、ドコモの主要Webサービスを提供する基盤であり、現在、30以上の Web サービスを提供しています。 AWS を利用することで、各種 Web サービスをユーザトラヒック変動に柔軟に対応可能なアーキテクチャとして構築しました。さらに、新規 Web サービス提供時の開発期間短縮を実現しています。 また、アプリケーションのアーキテクチャを AWS Lambda や AWS Fargate といったマネージドサービスを活用したアーキテクチャへ進化させることで、開発・運用の最適化を進めています。 さらに、複数の Web サービスを同時並行で短期間に開発・改善するため、マネージドサービスの活用に加え、アーキテクチャモデルの標準化にも取り組んでいます。アーキテクチャモデルの標準化には AWS CDK を活用し、類似機能ごとにアーキテクチャをモデル化しています。複数の開発案件でアーキテクチャモデルを共用することで、開発効率の大幅な向上を実現してきました。 また、我々は AWS が提供するソフトウェア開発生成 AI アシスタントである Amazon Q Developer に注目し、プロジェクト全体で Amazon Q Developer を開発者の教師役として有効活用するべく日々取り組んでいます。 図1. POPLAR アーキテクチャ標準化の取り組み 2.開発における課題 移り変わりの激しい市場動向に対応するために、ドコモが提供する各種 Web サービスにおいても、”速さ”と”品質”を維持したサービス改善が要求されます。POPLAR では、標準化したアーキテクチャモデルを用いて、複数の Web サービスに対して短期間且つ同時並行で機能開発を進めています。 一方で、サービス改善に関する開発を進める過程において、以下の様な課題を抱えています。 課題①　開発の大部分を占める既存機能の改修案件において、既存機能の知見やノウハウの有無が開発生産性に与える影響が大きく、既存機能の知見及びノウハウの習得は開発遂行の上で必要条件となります。一方で、5 年以上の基盤運用実績から提供機能数も多くなり、既存機能の知見及びノウハウ継承には、大きな労力が掛かります。 課題②　開発要員のローテーションの際には、交代要員の立ち上がり期間を十分に確保しつつ、既存開発者からの様々な支援を必要とします。一例をあげると、交代要員が本プロジェクトの開発に必要な技術的スキル、既存機能の知見及びノウハウを習得して貰うために、一定期間、既存開発要員が教育へ大きな労力とを掛ける必要があります。 課題③　障害時にサービス影響のある機能も担っており、開発において相応の品質を求められます。開発者にはアプリケーションからインフラまで幅広い技術的知識が必要となりますが、その技術的要件を全て満たした開発者は市場でも数少なく、大半の開発者は開発遂行にあたって技術的知識の不足部分に対するプロジェクトからの技術的支援を必要とします。 これらの課題を解決し、各種サービスからの改善要求を満たした開発を安定的に実施するためには、以下の仕組みが必要となります。 既存機能およびノウハウについて、労力(時間)をかけずに効率的に継承できる仕組み 不足する技術スキルを短期間で習得できるよう支援・補完する仕組み これらの課題を解決するために、我々は、AWS が提供するソフトウェア開発生成 AI アシスタントである Amazon Q Developer を開発者の教師役としてプロジェクト全体で活用しています。 3. Amazon Q Developerを活用した開発の取り組み POPLAR の開発プロジェクトにおいては、全体で 50 名以上の開発者が携わっています。これらの開発者は Amazon Q Developer Pro サブスクリプションを日常的に利用しています。さらに、プロジェクトに携わる開発者が Amazon Q Developer を有効活用するために、環境準備を支援する設定ガイド、開発時の Amazon Q Developer を活用する方法をまとめたガイドラインを整備する等、POPLAR の開発プロジェクト全体で利用促進を図りました。 また、 Amazon Q Developer から有益な支援を得るために、以下のようなコンテクストを Amazon Q Developer に与える工夫も実施しています。 今までの開発で積み上げてきた既存ソースコード &nbsp;標準化したアーキテクチャモデル &nbsp;開発ルールをまとめた設定ファイル AWS が提供する MCP サーバ これらの営みにより、標準化したアーキテクチャモデル等、POPLAR の既存の仕組みや AWSド キュメントに記載された仕様を踏まえた Amazon Q Developer からの支援を実現しています。 図2. Amazon Q Developer の利用条件・環境について 4. Amazon Q Developer による開発効率向上への寄与 Amazon Q Developer の活用は、学習用途で開発者がノウハウや技術的知識を吸収するだけに留まりません。 開発者の教師役として、 Amazon Q Developer に開発ドキュメントを読み込んで貰い仕様調査に協力して貰う、 Amazon Q Developer を壁打ち役として仕様検討を手伝って貰う、または、 Amazon Q Developer に改修コードを提案して貰う等、各開発工程においても幅広く支援を受けることが可能です。 既存機能の改修を前提とした開発において Amazon Q Developer を最大限活用することで、影響調査、設計及び設計とコーディング（自動コーディング）といった開発工程において生産性の向上が見込めることも確認しました。 特に、既存機能の改修においては、既存ソースコードを Amazon Q Developer に対するインプット情報として活用することにより、 Amazon Q Developer との最小限のやり取りで高い精度のアウトプットが得ることができ、 Amazon Q Developer を活用しない従来の開発手法と比べて各開発工程において開発品質向上及び開発期間の短縮を確認できています。 また、開発プロジェクトへの所属期間が短く、既存機能への知見も多くない開発要員が Amazon Q Developer を活用することで、習熟期間の短縮、開発期間の短縮及び開発品質の向上等の高い支援効果が得られることも確認しました。 5.まとめ 第一回の事例では、ドコモの主要な Web サービス提供基盤である『 POPLAR 』における Amazon Q Developer の活用方法及び開発者の教師役として Amazon Q Developer を活用することの有用性についてご紹介しました。 開発ノウハウの継承や開発生産性向上に取り組む皆様の参考にしていただければ幸いです。 次回は以下をご紹介します。 Amazon Q Developer 活用をプロジェクト全体へ拡げた取り組み 著者について 株式会社 NTTドコモ 情報システム部 デジタルデザイン担当 担当部長 深谷 治男 ( Haruo Fukaya ) 担当課長 小柴 辰久 ( Tatsuhisa Koshiba ) 主査 川口 晃平 ( Kouhei Kawaguchi ) &nbsp;