このブログは 2023 年 11 月 27 日に James Bornholt、Abhinav Goyal、Jonathan Henson、Andrew Kutsy によって執筆された内容を日本語化したものです。原文は こちら を参照してください。 データはあらゆる機械学習パイプラインの中心にあります。基盤モデル (FM) の事前トレーニング、ビジネス固有のデータによる FM のファインチューニング、推論クエリの実行など、機械学習ライフサイクルのあらゆる段階においてコンピューティングリソースを常時稼働させて有用な作業を実行できるようにするには、低コストで高性能なデータストレージが必要です。お客様はトレーニングデータやモデルチェックポイントの保存に Amazon Simple Storage Service (Amazon S3) を使用することが推奨されています。理由として弾力性、複数のテラビット/秒にスケールする性能、そして S3 Intelligent-Tiering のようなストレージクラスによってアクセスパターンが変化した際に自動的にストレージコストを節約できるからです。 Amazon S3 との間のデータ転送を自動的に高速化し、機械学習パイプラインの基盤をさらに強化する AWS Command Line Interface (AWS CLI) と AWS SDK for Python (Boto3) の新しいアップデートを発表しました。AWS CLI と Boto3 は、Amazon S3 との間の高スループットデータ転送を提供するために特別に設計・構築された AWS Common Runtime (CRT) S3 クライアントと統合されました。この統合は現在、Amazon EC2 Trn1 、 P4d 、 P5 インスタンスタイプではデフォルトで有効化されており、他のインスタンスタイプではオプトインとして有効化することができます。 AWS Common Runtime とは何か Amazon S3 は、どの HTTP クライアントからもアクセスできるシンプルな REST API で、お客様から好評をいただいています。ただし、大量のデータを扱うアプリケーションで最高のパフォーマンスを得るには、リクエストの並列化、タイムアウト、再試行、バックオフなどの パフォーマンスのベストプラクティス を実装する必要があります。数年前、私たちはこれらのパターンを各 AWS SDK で再実装していて、お客様も独自のアプリケーションにこれらのパターンを実装しなければならないことに気付きました。私たちは、こうした一般的な設計パターンを再実装することなく、どのアプリケーションからでも簡単に S3 の伸縮自在なパフォーマンスにアクセスできるようにしたいと考えていました。 このポータブルなパフォーマンスを実現するために、 AWS Common Runtime (CRT) を構築しました。CRT は C で書かれたオープンソースライブラリの集合体で、高性能 HTTP クライアントや暗号化ライブラリなど、AWS サービスとやり取りするための共通機能を実装しています。CRT ライブラリは連携して AWS サービスに高速で信頼性の高いクライアントエクスペリエンスを提供します。Amazon S3 の場合、CRT にはネイティブ S3 クライアントが含まれており、自動リクエストの並列化、リクエストのタイムアウトと再試行、接続の再利用と管理を実装して、ネットワークインターフェイスの過負荷を回避します。たとえば、S3 から 1 つの巨大なオブジェクトをダウンロードする場合、CRT クライアントは複数のバイト範囲を自動的に並行してダウンロードするため、スループットが向上し、ネットワークインターフェースを上手に活用します。 CRT は Java や C++ を含む複数の AWS SDK で既に本番環境で利用可能であり、以前は AWS CLI の実験的なオプションとして提供されていました。また、オープンソースファイルクライアントである Mountpoint for Amazon S3 の基盤でもあります。 私たちはCRTをTrn1、P4d、P5 EC2 インスタンスタイプの AWS CLI と Boto3 で提供を開始しました。これらのインスタンスタイプは大きな CPU とネットワークインターフェースを持ち、これらのパフォーマンス設計パターンから最も恩恵を受けることができます。 他のインスタンスタイプについては、AWS CLI または Boto3 アプリケーションで CRT を使用するように選択すると、多くの場合、自動的にパフォーマンス向上が得られます。 ML パイプラインのパフォーマンス向上 AWS Common Runtime で実現できる可能性のあるパフォーマンス向上を実証するために、ML ライフサイクルの各ステップを表す 4 つのベンチマークデータセットを収集しました： Caltech-256： 画像データセット で、平均 40 kB サイズの 30,607 の小さな画像ファイルを含み、総データセットサイズは 1.1 GB です。 Caltech-256-WebDataset：同じ Caltech 256 の画像データセットですが、WebDataset 形式を使用して保存されており、複数の画像を 100 MB のシャードオブジェクトにまとめています。シャード化されたデータセットは、ML トレーニングで Amazon S3 を使用する際に、より高いパフォーマンスを達成できることがよくあります。 C4-en： Common Crawl corpus に基づく C4 データセットの英語サブセットで、320 MB の 1,024 ファイルを含みます。 Checkpoint：単一の 7.6 GB PyTorch チェックポイントファイルで、大規模 ML モデルのシャード化されたチェックポイントを代表しています。 AWS CLIを使用して、これらの各データセットを trn1n.32xlarge EC2 インスタンスからアップロードおよびダウンロードしました。AWS CRTが有効になっていない場合と有効になっている場合の両方です。結果は次のとおりです： CRT は、AWS CLI の最新リリースへの更新以外の追加作業なしで、これらのベンチマーク全体で 2 ～ 6 倍のパフォーマンス向上を実現します。CRT を有効にして Boto3 を使用する Python アプリケーションでも、同様のパフォーマンス向上が見られました。 アプリケーションで CRT を使い始める AWS CLI で CRT を使用するには、まず AWS CLI の最新バージョンをインストールしてください。 まだ AWS CLI のバージョン 2 にアップデート していない場合は絶好の機会です。CRT との統合はバージョン 2 でのみ利用可能です。Trn1、P4d、または P5 EC2 インスタンスで実行している場合はこれだけで準備完了です — aws s3 sync のような CLI コマンドを使用する際に、CRT はデフォルトで有効になります。その他のインスタンスタイプでは、次のコマンドを実行して CRT を有効にすることができます： aws configure set s3.preferred_transfer_client crt Boto3 で CRT を使用するには、まず追加の crt 機能を含む Boto3 をインストールしていることを確認してください。たとえば、pip を使用してインストールする場合は、以下を実行します： pip install boto3[crt] Trn1、P4d、および P5 インスタンスでは、Boto3 が crt 機能付きでインストールされると、upload_file と download_file の呼び出しに自動的に CRT が使用されます。たとえば、CRT を使用してファイルを S3 にアップロードするには、以下を実行します： import boto3 s3 = boto3.client('s3') s3.upload_file('/tmp/hello.txt', 'doc-example-bucket', 'hello.txt') また、s3transfer パッケージを使用して Boto3 で CRT にアクセスできますが、このパッケージはまだ一般提供を開始されておらず、将来変更される可能性があります。 パフォーマンスチューニング CRT は S3 を使用するアプリケーションのパフォーマンスを自動的に最適化します。デフォルト設定では多くの状況で速度が向上します。これらのデフォルトでは、CPU トポロジー、メモリ量、 Elastic Network Adapter (ENA) インターフェイスの数とレイアウトなど、実行中のインスタンスタイプの仕様に基づいて CRT が自動的に設定されます。これらの詳細に基づいて、 CRTはS3リクエストの並列化戦略（並列接続の数、各リクエストのサイズ、S3 IPアドレスごとのリクエスト数など）を選択します。 CRT 転送で使用されるネットワーク帯域幅の量を制限する場合など、状況によってはこれらのデフォルトをオーバーライドしたい場合があります。AWS CLI で CRT を使用する場合は、target_bandwidth パラメーターを設定することでデフォルトをオーバーライドできます。たとえば、転送を 5 ギガビット/秒に制限するには、以下を実行します： aws configure set s3.target_bandwidth 5Gb/s 注意事項とオプトアウト CLI と Boto3 用の CRT の今回のリリースでは、多くの ML アプリケーションのパフォーマンスが向上しますが、注意すべき点が 3 つあります。 マルチプロセス実行 CRT は、S3 リクエストを複数のスレッドで並行して行うことで、高スループットのデータ転送を実現します。これは、一度に 1 つの S3 クライアントしか使用しないアプリケーションに最適です。これらのスレッドはインスタンスの vCPU に分散する可能性があるためです。ただし、それぞれが独自の S3 クライアントを作成する複数のプロセスを使用する場合、これらのスレッドは互いに競合して S3 のパフォーマンスを低下させる可能性があります。また、これらの複数のクライアントがネットワーク帯域幅をめぐって競合し、輻輳が発生してパフォーマンスが低下する場合もあります。 AWS CLI と Boto3 の CRT 統合では、複数のプロセスが CRT ベースの S3 クライアントを作成していることを自動的に検出し、このような場合は非 CRT ベースの S3 クライアントにフォールバックします。このフォールバックにより、CRT クライアントが 1 つだけ存在するようになるため、システム上で競合が発生するリスクが軽減されますが、その結果、他のクライアントのパフォーマンスが低下する可能性があります。この制限は複数の S3 クライアントにのみ影響します。1 つの S3 クライアントを同じプロセス内の複数のスレッドで共有することも、同じ AWS CLI 呼び出し内の多数の S3 転送で共有することもできます。 アプリケーションが複数のプロセスで独自の S3 クライアントを作成してしまうパターンは主に 2 つあります。1 つ目は、AWS CLI の呼び出しを複数同時に実行すると、各 CLI プロセスに独自の S3 クライアントが存在することになります。たとえば、以前に AWS CLI を parallel や xargs -P ユーティリティを実行してパフォーマンスを向上させたことがある場合は、複数の AWS CLI プロセスを使用し、それぞれに独自の S3 クライアントを用意することになります。新しい CRT 統合では、CLI プロセスを 1 つだけ使用し、CLI に転送の並列処理を任せることをお勧めします。2 つ目に、 PyTorch のような ML フレームワークで Boto3 を使用する場合、データをロードするために複数のワーカープロセス （たとえば、PyTorch の DataLoader の num_workers 引数） を使用することになります。 マルチリージョンおよびクロスリージョンアクセス AWS CLI と Boto3 の CRT 統合は、現在 S3 バケットの自動リージョン検出をサポートしていません。つまり、アプリケーションがインスタンスが実行されているリージョンとは異なるリージョンの S3 バケットにアクセスする場合、ターゲットリージョンを手動で指定する必要があります。これを行うには、AWS CLI の –region argument を使用するか、AWS CLI と Boto3 の両方に AWS_REGION 環境変数を設定します。Boto3 の場合、リージョンはクライアントの作成時に設定されるため、この制限により、1 つの S3 クライアントは 1 つのリージョンのバケットにしかアクセスできないことにもなります。複数のリージョンのバケットにアクセスする必要がある場合は、複数のクライアントを作成する必要があります。 Transfer コンフィグレーション Boto3 の CRT 統合は、クライアントを転送ごとに設定するための TransferConfig API をサポートしていません。代わりに、CRT はネットワーク帯域幅を最大化するようにクライアントを自動的に設定し、同じプロセスで同時に実行される S3 リクエストすべてでその帯域幅を共有します。 CRT からのオプトアウト これらの制限のいずれかを回避する必要がある場合は、CRT をオプトアウトできます。AWS CLI の CRT 統合を無効にするには、以下を実行します： aws configure set s3.preferred_transfer_client classic 同様に、Boto3 の CRT S3 統合を無効にするには、boto3 転送コールで使用するときに TransferConfig の preferred_transfer_client を classic に設定してください。 from boto3.s3.transfer import TransferConfig config = TransferConfig(preferred_transfer_client='classic') client = boto3.client('s3', region_name='us-west-2') client.upload_file('/tmp/file', Bucket='doc-example-bucket', Key='test_file', Config=config) まとめと今後の改善点 Amazon S3 は伸縮自在でパフォーマンスが高いため、ML トレーニングデータやモデルチェックポイントを保存するのに最適です。AWS CLI と Boto3 の改善により、ML パイプラインで S3 にアクセスする際のパフォーマンスをさらに簡単に最適化できるようになり、ジョブをより早く完了し、コストを削減できるようになりました。将来的には、AWS Common Runtime をデフォルトでより多くのインスタンスタイプで有効にし、よりきめ細かな調整機能を公開して、ワークロードのパフォーマンスをさらに最適化できるようにする予定です。 AWS CLI 、 Boto3 、 AWS Common Runtime はすべてオープンソースプロジェクトであり、それぞれの GitHub リポジトリに関するフィードバックをお待ちしています。 TAGS: Amazon Simple Storage Service (Amazon S3) , AWS Cloud Storage , AWS Open Source , AWS re:Invent , machine learning James Bornholt James Bornholt は、Amazon S3 の自動推論に取り組んでいます。 Abhinav Goyal Abhinav Goyal は、AWS の SDK およびツールチームのエンジニアリングマネージャーで、Common Runtime Tools、AWS Rust SDK、AWS C++ SDK を担当しています。AWS に入社する前は、さまざまな銀行アプリケーション向けの大規模分散システムを構築した 20 年以上の技術リーダーシップの経験があります。余暇には、Abhinav は読書をしたり、卓球をしたり、長い散歩をしたりするのが好きです。彼はデリーのインド工科大学（インド）で学士号を取得しています。 Jonathan Henson Jonathan Henson は AWS の主任ソフトウェアエンジニアで、AWS SDK のランタイムとアーキテクチャを専門としています。 Andrew Kutsy Andrew は Amazon S3 のプロダクトマネージャーです。彼は 2016 年に Amazon に入社し、ユーザーがAWS を使用する革新的な方法について学ぶためにユーザーと話すのが大好きです。彼はコーヒーに夢中で、旅行が好きで、現在、世界で最高のクロワッサンを探しています。

本稿は、2025 年 8 月 1 日に公開された “ How to manage AI Bots with AWS WAF and enhance security ” を翻訳したものです。 最初の Web クローラーは 1993 年に Web のサイズを測定する目的で作成されましたが、現在ではエージェント型 AI を搭載した最新のボットへと進化しています。今日のインターネットは、AI 関連タスクをサポートするためにアプリケーションと対話する自動化された AI ボットによって、ますます占有され支配されるようになっています。 私たちは AI ボットを 3 つのタイプに分類しました： AI スクレイパー : AI モデルをトレーニングするために、アプリケーションから体系的にデータを収集します。 AI ツール : 関数呼び出しを使用して、AI アプリケーション内でアプリケーションのデータを表示します。 AI エージェント : 複雑なタスクを実行するために、アプリケーションを自律的にナビゲートし、動的に対話できます。 AI ボットの中には、面倒なタスクを自動化するといった価値あるサービスを提供するものもありますが、悪意のあるボットは Web アプリケーションの所有者や運用者にとって深刻な問題となる可能性があります。悪意のあるボットは過剰なトラフィックでサーバーを圧倒し、パフォーマンスの低下やシステム停止を引き起こします。こうしたボットを野放しにすると、セキュリティが侵害されるだけでなく、ユーザーからの信頼を失い、ブランドイメージを損なうことにもつながります。 この記事では、AI ボットが引き起こすさまざまな問題について考察し、 Amazon Web Services (AWS) WAF を使用して AI ボットを検出・管理するさまざまな手法について学びます。 前提条件 本記事では、アプリケーションへの AI ボットのアクティビティを監視・管理する最前線の防御として、AWS WAF に焦点を当てています。AWS WAF による保護をまだ有効化していない場合は、まず AWS Shield network security director を使って脅威の全体像を可視化することから始めましょう。これにより、AWS WAF で保護されていないリソースを特定できます。 その後、ワンクリックセキュリティ統合機能を使用して、初期セキュリティ体制を構築できます。この機能は、最も一般的な脅威からアプリケーションを保護するルールを含む 保護パックまたは Web ACL を自動的に作成します。詳細については、以下のリファレンスを参照してください： Amazon CloudFront を使用してアプリケーションをホストしている場合は、 CloudFront ワンクリック AWS WAF 統合 を使用して保護を有効にします。 Application Load Balancer (ALB) を使用してアプリケーションをホストしている場合は、 ALB ワンクリック AWS WAF 統合 を使用して保護を有効にします。 AI ボットによって引き起こされる問題 ボットは Web 上の新しい脅威ではありません。ただし、大規模言語モデル (LLM) が必要とする大量のデータや、AI エージェントが可能にした新たな対話パターンにより、多くのアプリケーションでボットの挙動がより問題視されるようになりました。Web アプリケーションは、AI ボットにより次のような問題に直面する可能性があります： 独自データをモデルのトレーニングに使用される : 組織のデータが無許可で AI モデルのトレーニングに使用されると、知的財産に関する懸念が生じます。たとえば、あなたのコンテンツが対価なしに競合サービスの作成に利用され、コンテンツの独自の市場価値が低下する可能性があります。 パフォーマンスの低下とコストの増加 : アプリケーションのコンテンツを積極的に収集する AI ボットは、膨大なトラフィックを発生させ、正規ユーザーのパフォーマンスを低下させる可能性があります。これにより、データ転送送信 (DTO) 料金が発生し、コンピューティングリソースが浪費されるほか、スクレイピングのピーク時にはサービス停止が発生する可能性もあります。 望ましくない自動/エージェント動作 : AI ボットは、人間が介在することなくアプリケーションと自動的に対話できます。AI が結果を要約できるため、アプリケーションへの貴重な人間のトラフィックを奪う可能性があります。また、AI ボットは、限定在庫の購入など、高価値で時間的制約のあるワークフローを完了するために、正規の人間のトラフィックと競合する可能性もあります。これらのボットは通常、以下の手法を使ってアプリケーションと対話します： 関数呼び出しと AI 検索 : AI アプリケーションはツールを使って、アプリケーションから直接データを検索し、単発のリクエストを実行します。 ブラウザ自動化フレームワークによる対話 : Amazon Nova Act などの AI エージェントは Playwright を使用して実際のブラウザを制御します。複数ステップのタスクを完了し、人間のような方法でアプリケーションと対話できます。これらのエージェントは JavaScript を実行し、複雑な UI 要素を効果的に処理することが可能です。 VM ベースの対話 : Anthropic の Computer Use のようなシステムは、仮想マシン (VM) 環境内で動作します。より人間に近い方法でアプリケーションと対話し、Playwright の自動化ブラウザとは異なり、標準にインストールされたブラウザを使用します。そのため、その動作は実際の人間ユーザーとほぼ区別できません。 AI ボットアクティビティの規模を把握する まず、AI ボットがどのようにアプリケーションに影響を与えているか、またその規模を理解する必要があります。最初のステップとして、検査レベル Commonで AWS WAF Bot Control ルールグループをリソース保護パックに追加しましょう。初期段階では Count モードを使ってトラフィックパターンを監視します。このアプローチにより、本番環境のトラフィックに影響を与える可能性のある変更を行う前に、ボットアクティビティを分析できます。 Bot Control の Common ルールグループは、署名検証によって自己申告ボットを検証します。このルールグループには、検証済み AI ボットを検出する CategoryAI ルールが含まれています。図 1 に示すように、必ず最新バージョンでルールグループを設定してください。 図 1: 検査レベル Common およびバージョン 3.2 の AWS WAF Bot Control ルールグループ マネージドルールグループを数日間実行した後、収集したデータを分析できます。インサイトを表示するには、AWS WAF および AWS Shield コンソールを開き、 AWS リージョン を選択します。保護パックを選択して ダッシュボードを表示 を選択します。 概要 セクションに移動し、 ボット オプションを選択すると、ボットアクティビティ、検出、カテゴリ、シグナルを確認できます。このダッシュボードでは、アプリケーション上のボットアクティビティに関するインサイトが得られます。 図 2 は、Bot categories セクションの例を示しています。 ai - AllowedRequests としてマークされた大量のリクエストが表示されています。これらは CategoryAI ルールによって検出されたものの、ブロックはされていない AI ボットです。また、他のボットも大量のリクエストを送信している様子が確認できる場合があります。 図 2: AWS WAF が検出した CategoryAI ルールのトラフィック概要 AI ボットによって引き起こされる問題の管理 以下のセクションでは、AI ボットによって引き起こされる問題を管理するためのさまざまな方法について説明します。 robots.txt で AI ボットを早期に停止する シナリオ 1 : ルール準拠AIボットの早期遮断 robots.txt ファイルを使用すると、アプリケーションに対するボットのアクセスを制御できます。このシンプルなテキストファイルをアプリケーションのルートディレクトリ（/robots.txt）に配置し、標準形式でルール準拠ボットに対してアクセス可能範囲を指示します。すべてのボットがこれらのルールに従うわけではありませんが、信頼できるボット事業者は適切に構成された robots.txt ファイルを尊重します。 ai.robots.txt などのオープンソースプロジェクトでは、最新のAI関連クローラーを含む robots.txt が提供されており、アプリケーションのクロール開始前にこれらのボットを停止できます。 AWS WAF で特定のボットからの大量リクエストが検出された場合、 robots.txt を使用して、過剰ながらもルールに従うスクレイピングボットを停止できます。これにより、DTO およびアプリケーションパフォーマンスへの影響を防止できます。 次の例は、Amazon Amazonbot に /public URL のクロールを許可し、 /private URL のクロールを禁止する設定です。 User-agent: Amazonbot Disallow: /private/ Allow: /public/ シナリオ2:AIボットのデータ使用方法を管理 主要なテクノロジー企業のボットは二重の目的で動作します。アプリケーションを一度スクレイピングし、取得したデータを検索インデックス化とAIモデルのトレーニングに利用します。これらのボットに対して、検索インデックス作成を目的としたアプリケーションのクロールは許可しつつ、LLMトレーニングへのデータ使用は拒否するよう指定できます。次に示すのは、主要なボット運用事業者がLLMのトレーニングにデータを使用することを防止する3つの例です。 Amazonbot : HTTP レスポンスヘッダー X-Robots-Tag: noarchive を使って、このレスポンスを LLM の学習に使用しないよう指示します。CloudFront の レスポンスヘッダーポリシー を利用することで、アプリケーションから返されるすべてのレスポンスにこのヘッダーを付与できます。 HTTP/1.1 200 OK Date: Tue, 15 Oct 2024 08:09:00 GMT X-Robots-Tag: noarchive Applebot : robots.txt に User-agent Applebot-Extended という項目を追加することで、Apple の機械学習（ML）モデルの学習にアプリケーションのデータを使わせないよう要請できます。この設定でも、検索用のコンテンツインデックス作成は引き続き Apple に許可されます。以下は、アプリケーション全体で Applebot-Extended のアクセスを拒否する記述例です。 User-agent: Applebot-Extended Disallow: / robots.txt における User-agent ディレクティブは、特定の目的を持ちます。このディレクティブは、ボットが宣言するアイデンティティに対してパターンマッチングを実行しますが、これは HTTP User-Agent ヘッダーとは異なるものです。 Googlebot : 同じように、Google も robots.txt に User-agent Google-Extended を追加することで、Google の ML モデル学習へのデータ使用を拒否 できます。 User-agent: Google-Extended Disallow: / robots.txt ファイルを尊重しないボット運用者も存在するため、そうしたボットは AWS WAF で管理する必要があります。 AWS WAF を使用した対策 シナリオ 3 :パフォーマンス低下と高コストの原因となる AI ボットの管理 過度にデータをスクレイピングする AI ボットは、アプリケーションの性能を悪化させ、DTO やコンピューティングの費用を大幅に増加させる恐れがあります。以下に紹介する AWS WAF を使った手法で、 robots.txt のルールを守らないボットからアプリケーションを守ることができます。 1 . AWS WAF Bot Control ルールグループ(検査レベル Common)を使った自己識別 AI ボットの管理 検査レベル Common の AWS WAF Bot Control ルールグループにおいて、以前「Count」としていた すべてのルールアクションをオーバーライド を解除することで、AI ボットからの大量アクセスを防ぐことが可能です。 CategoryAI ルールにより、これらの AI ボットリクエストは標準でブロックされるようになっています。 CategoryAI ルール配下の AI ボットを除き、AWS WAF は一般的かつ検証可能なボットをブロックしません。大量のトラフィックを生成している検証済みボットやボットカテゴリを特定した場合は、図 3 に示すように、AWS WAF Bot Control ルールグループの後方に、特定のボット（または ラベル名前空間 で表現されるボットクラス）をブロックするルールを明示的に追加する必要があります。 図 3：ラベルを活用し yandexbot をブロックするための AWS WAF のカスタムルール設定 2. 検知回避を試みるスクレイパーの速度抑制 ボットは、有名なボットや正当なユーザークライアントになりすますため、HTTP ユーザーエージェントヘッダーを偽造します。 AWS WAF の拡張されたアプリケーション層（L7）DDoS 保護 と AWS WAF レートベースルール を利用することで、これらのボットによるアプリケーションへの過剰な負荷を防ぐことができます。DDoS ルールとレート制限ルールにより、ボットを含む大量リクエストを行うすべてのソースからアプリケーションを守ることができます。レートベースルールのしきい値の設定方法や最適な作成方法については、 AWS WAF の主要な 3 つのレートベースルール に関する記事をご覧ください。 3. 検知回避を試みるスクレイパーに負荷をかける AWS WAF の Challenge アクション は、ユーザーの介入なしでクライアント環境においてサイレントチャレンジを実行します。これはユーザー体験に認識可能な影響を与えないよう設計されています。このチャレンジでは、クライアントに計算コストの高い作業（プルーフオブワーク）の実行を要求します。この方式により、正当なユーザーに対しては環境検証のためのシームレスな仕組みを提供する一方で、アプリケーションにアクセスを試みるボット運用者のコストを上昇させることを意図しています。 図 4 では、AWS WAF Bot Control ルールグループの後方にカスタムルールを追加する方法を示しています。このルールでは、許可済み/検証済みボットを除き、ユーザーが処理を継続する前にチャレンジの完了を必要とします。検証済みボットは、 awswaf:managed:aws:bot-control:bot という名前空間内のラベルにより識別されます。 図 4：未検証のボットトラフィックに対してチャレンジを強制する AWS WAF ルール 4 . 巧妙なボットの捕捉にハニーポットを活用 Security Automations for AWS WAF には、 ハニーポットエンドポイント が組み込まれています。このエンドポイントは、正当なユーザーや適切な振る舞いをするボットがアクセスしないように設計されており、アプリケーションをクロールするボットを誘い込む仕組みとなっています。アプリケーションへのスクレイピングの影響を抑制するため、検知した IP アドレスをブロックします。 シナリオ 4：不要な自律型/エージェント型 AI ボットへの対処 自律型 AI ボットへの対処には、次の技術を活用できます： 1 . AWS WAF Bot Control ルールグループ（検査レベル Common） ： CategoryAI ルールには、Amazon Nova Act などの広く認識された AI エージェントへの対応ルールが含まれています。また、 SignalNonBrowserUserAgent と SignalAutomatedBrowser の各ルールにより、Playwright タイプのブラウザ自動化エージェントをブロックすることができます。 2 . AWS WAF Bot Control ルールグループ（検査レベル Target） ：このレベルの検査では、トラフィックパターンの知的ベースラインを構築します。人間をシミュレートするエージェント型ボットからアプリケーションを守るため、フィンガープリンティング手法を活用します。設定手順の詳細については、 高度なボットトラフィックの検知・ブロック に関する投稿をご確認ください。 3 . AWS WAF CAPTCHA アクション ：主要プロバイダーが提供する LLM は、CAPTCHA を解決しないよう学習されています。これにより、多くのエージェントによる要求された操作の完了を防ぐことができます。前述の チャレンジ 技術と同様に、特定のリクエストに対して CAPTCHA の完了を要求するルールを設定できます。設定手順の詳細については、「 Use AWS WAF CAPTCHA to protect your application against common bot traffic 」の投稿をご確認ください。 4 . 認証（生体認証を含む） ：ボットは継続的に進化し、対策を回避するようになっていきます。人間による操作を厳密に要求する場合は、やり取りを継続する前に、生体認証を含む認証の使用を検討してください。ボットトラフィックの可能性を示す動作が確認された際の適応的なユーザー認証の実装方法については、「 How to use AWS WAF Bot Control for targeted bots signals and mitigate evasive bots with adaptive user experience 」の記事を参照してください。 まとめ AI ボットは、パフォーマンスを低下させコストを増加させる過剰なスクレイピング、AI トレーニングのための不正なコンテンツ使用、迷惑なものから悪意のあるものまで様々な自動化された操作を通じて、重大な課題を引き起こします。本記事で説明した基本的な robots.txt の設定から、高度な AWS WAF Bot Control ルール、レート制限、CAPTCHA チャレンジまでの戦略を実装することで、不正なデータスクレイピングから保護し、パフォーマンスの低下を防ぎ、AI ボットによるコンテンツの使用方法を制御することができます。 さらに、AWS WAF の最新情報については、 AWS WAF Security Blog および AWS Security, Identity, and Compliance の新着情報をご参照ください。 本記事をお読みいただき、ありがとうございます。本記事に関するご質問がある場合は、 AWS WAF re:Post で新しいスレッドを開始するか、 AWS サポート までお問い合わせください。 著者 David MacDonald David は、ニュージーランドのスタートアップ企業が安全でスケーラブルなソリューションを構築できるよう支援することに注力しているシニアソリューションアーキテクトです。彼はキャリアの大半を、さまざまな業界にサービスを提供するSaaS 製品の構築と運用に費やしてきました。仕事以外では、David はアマチュア農家として、少数のアルパカとヤギの群れの世話をしています。 Kartik Bheemisetty Kartik Bheemisetty は、米国 ISV 顧客向けのシニアテクニカルアカウントマネージャーであり、お客様が AWS クラウドサービスを活用してビジネス目標を達成できるよう支援しています。彼は AWS のネットワークおよびコンテンツ配信サービスに関する専門知識を有しています。ベストプラクティスに関する専門的なガイダンスを提供し、各分野の専門家へのアクセスを促進し、AWS の支出、ワークロード、イベントの最適化に関する実用的な洞察を提供しています。 LinkedIn で彼とつながることができます。 翻訳は Solutions Architect の長谷川 純也が担当しました。

組織がガバナンスをコンプライアンスの負荷としてではなく戦略的な実現手段 (enabler) として認識するようになってきている中、今年の AWS Cloud Ops トラックにおけるクラウドガバナンスでは、運用の卓越性 (operational excellence) とビジネスイノベーションの間のギャップを埋める最先端のセッションを提供します。 ガバナンスの環境は急速に進化しており、今年のセッションは、今日のクラウドガバナンス専門家が直面している最も差し迫った課題と機会を反映した 4 つの重要なテーマを中心に構成されています。 クラウドガバナンストラックの参加を計画しよう 今年、AWS Cloud Ops トラック下のクラウドガバナンスには 4 つの主要テーマがあります。ハンズオンワークショップから専門家レベルのディスカッションまで、あらゆる方にあらゆるコンテンツを提供します。re:Invent での体験を最高のものにするために、以下をおすすめします: 優先事項に焦点を当てる: 組織の直近の運用課題に合致するセッションを選択する 形式を組み合わせる: 講義形式のセッションとインタラクティブなワークショップやビルダーズセッションを組み合わせる スキルを伸ばすために計画する: 現在のスキルレベルに合ったセッションと、能力を伸ばすセッションを選択する 早めに予約する: 人気のセッションはすぐに満席になるため、登録開始と同時に予約する クラウドガバナンスの re:Invent における主要テーマ re:Invent 2025 の AWS Cloud Ops トラック下のクラウドガバナンスは、今日の最も喫緊の運用課題に対処する 4 つの主要テーマを中心に構成されています: 1. 生成 AI とインテリジェントガバナンス ガバナンスワークフローへの生成 AI の統合は、組織がコンプライアンス、コントロール、運用監視を管理する方法に革命をもたらしています。Amazon Q による CloudTrail ログの分析から、自動化されたコントロール検証のための AI 活用まで、これらのテクノロジーは、リアクティブなガバナンスを、プロアクティブでインテリジェントなシステムに変革します。問題を予測し、応答を自動化し、大規模にコンテキスト認識型のインサイトを提供できるようにします。 2. 運用効率とコスト最適化 効果的なガバナンスとは、セキュリティとコンプライアンスだけではありません。リソースを最適化しながらビジネスの俊敏性を実現することです。最新のガバナンスフレームワークは、堅牢な統制と業務効率のバランスを図り、費用対効果の高い監視戦略を実施し、アカウント管理を合理化し、日常業務を自動化することで、チームが戦略的取り組みに注力できる環境を整えなければなりません。 3. セキュアな運用と自動化 セキュリティガバナンスは、チェックボックス式のコンプライアンスから、ビジネス運用を制約するのではなく推進するような自動的・継続的な保護へと進化しています。Policy-as-code、自動化されたコンプライアンス検証、プロアクティブなセキュリティコントロールを用いることで、組織は強力なセキュリティ態勢を維持しながら成長に合わせて拡張できるガバナンスフレームワークを構築できます。 4. マルチクラウドとソブリンクラウド要件 組織がグローバルに、そして複数のクラウド環境にわたって拡大するにつれて、ガバナンスは、データ主権や地域コンプライアンス、国境を越えた運用に関する複雑な要件に対処する必要が出てきます。本テーマのセッションでは、国固有の規制を満たし、運用の柔軟性を維持しながら、多様な環境全体で一貫したガバナンスを維持する方法を探ります。 学習パスを選択する 必見のクラウドガバナンスセッションをテーマ別に整理してご紹介します。ご自身にパーソナライズされたアジェンダの作成にお役立てください: 生成AIとインテリジェントガバナンス コンプライアンスを強化しつつ手作業を削減する AI 駆動の自動化とインテリジェントなインサイトによって、ガバナンスアプローチを変革します。 COP350 | Building and validating cloud controls with generative AI | Breakout session 場所: 12月3日(水) | 午後4:00 – 5:00 PST | Caesars Forum このテクニカルセッションでは、生成 AI を活用してコンプライアンスモニタリングと検証プロセスを自動化および強化する方法を実演します。生成 AI が AWS Control Tower を通じて AWS アカウントのカスタマイズを加速し、AWS Config ルールを作成し、AWS CloudTrail ログを分析する方法を学びます。 COP411 | Intelligent automation for managing cloud governance and compliance | Builders session 場所: 12月4日(木) | 午前11:30 – 午後12:30 PST | Mandalay Bay AWS Config、AWS Security Hub、AWS Audit Manager を含む AWS コンプライアンスツールからのデータを分析し、効率的なポリシー実施とリスク管理のためのコンテキスト認識型インサイトを提供するスマートワークフローの作成方法を学びます。ハンズオン演習を通じて、コンプライアンスクエリを処理し、複雑なガバナンス調査のためのインターフェースを実装する自動化ソリューションを構築します。 運用効率とコスト最適化 運用コストとリソース利用を最適化しながら、ビジネスの俊敏性を実現するガバナンスフレームワークを構築するための戦略をマスターします。 COP355 | A practical guide to implement cost-effective governance controls | Chalk talk 場所: 12月1日(月) | 午後3:00 – 4:00 PST | Mandalay Bay この chalk talk では、堅牢なセキュリティとコンプライアンスモニタリングを維持しながら運用コストを削減する方法を示します。ガバナンスを損なうことなく実装を最適化するための実証済みの戦略を学びます。実際のシナリオを通じて、AWS Config や AWS CloudTrail などのサービスを用い、コンプライアンス要件を満たしながらモニタリングコストを削減することに成功した組織の事例を見ていきます。 COP351 | Innovation Sandbox on AWS: Automating Temporary Cloud Environments| Lightning Talk 場所: 12月1日(月) | 午後4:30 – 4:50 PST | Venetian クラウド管理者は、セキュリティとコスト管理を徹底しつつ一時的なサンドボックス環境を効率的に管理するためにはどうしたらよいかという課題に直面しています。AWS 上のイノベーションサンドボックスは、短期間の環境のデプロイと管理を自動化し、サービスコントロールポリシー、支出管理、アカウントリサイクルメカニズムを実装して、数週間分の管理時間を節約します。 COP324 | Moving AWS Accounts seamlessly at scale | Chalk talk 場所: 12月1日(月) | 正午12:00 – 午後1:00 PST | MGM 合併・買収、事業売却、その他のビジネス移行に際しては、運用の中断を防ぎ、セキュリティギャップに対処するために、AWS アカウントを安全かつ正確に移行する必要がよく生じます。マルチアカウントのベストプラクティスは、ビジネスの変化や移行時にマエストロ (指揮者) のように AWS アカウントを移行するのに役立ちます。ワークロードのスケーリングを簡素化し、時間を節約しリスクを軽減しながら俊敏性を促進できます。依存関係を評価し、追加のチェックを実行して、迅速で安全かつ効率的な移行を実行する方法を学びます。 セキュアな運用と自動化 自動化、policy-as-code、継続的なコンプライアンス検証を通じて、プロアクティブなセキュリティガバナンスを構築します。 COP347 | Actionable controls for improving governance and compliance | Breakout session 場所: 12月1日(月) | 午前8:30 – 9:30 PST | Wynn 効果的なギャップ分析とコントロールマッピングを通じて、コンプライアンスフレームワークを実行可能な AWS コントロールに変換する方法を学びます。このセッションでは、AWS Control Tower、AWS Security Hub、AWS Config、AWS Audit Manager を活用してスケーラブルなガバナンス戦略を構築および維持する方法を示します。複数のフレームワークにわたる共通コントロールのマッピング、自動化されたコンプライアンスチェックの実装、カスタムコントロールデプロイメントの作成の実例を探ります。 COP352 | From Reactive to Proactive: Infrastructure governance by design | Code talk 場所: 12月4日(木) | 午後3:30 – 4:30 PST | MGM この code talk では、AWS CloudFormation Hooks と AWS CloudFormation Guard を使用したセキュリティのベストプラクティスについて説明し、非準拠のインフラストラクチャデプロイメントが発生する前に防止する方法を実演します。静的テンプレート検証のための CloudFormation Guard ドメイン固有言語 (DSL) ルールの記述方法と、マネージドフックを含む CloudFormation Hooks との統合方法を学び、組織全体でセキュリティ標準をプロアクティブに実施します。 COP406 | Build and automate policy as code | Builders session 場所: 12月3日(水) | 午前10:00 – 11:00 PST | MGM このハンズオンセッションでは、完全な policy-as-code パイプラインを構築し、セキュリティチェック、Pre-commit hooks、早期に問題をキャッチするカスタム組織ルールの実装方法を学びます。ガイド付き演習を通じて、シフトレフトセキュリティプラクティスを理解し、インフラストラクチャガバナンスを強化する自動化されたフィードバックループを作成します。 COP353 | Building your data protection strategy with governance controls | Chalk talk 場所: 12月4日(木) | 午後2:30 – 3:30 PST | Mandalay Bay このインタラクティブセッションでは、ガバナンスポリシーとコントロールを使用した効果的なデータ保護戦略を探ります。不正アクセスの防止、セキュリティポリシーの実施、大規模な一貫したリソース構成の維持方法を実演する実際のシナリオに取り組みます。認可と管理ポリシーがどのように連携して組織のデータの自動化されたコントロールを作成するかを見ていきます。 COP348 | Scaling Compliance Controls and Risk Assessment | Chalk talk 場所: 12月4日(木) | 午後4:00 – 5:00 PST | Wynn リスクを評価し、証拠収集のために AWS Audit Manager と統合する AWS ポリシーを有効にする方法を学びます。このセッションは、リスクオーナーと技術チームに、プライバシー管理、コンプライアンス自動化、監査文書化のための実用的なツールを提供し、機密データ環境の保護に対して即座に価値をもたらします。 マルチクラウドとソブリンクラウド要件 複雑な主権要件に対応し、多様なクラウド環境全体で機能するガバナンスフレームワークを構築します。 COP409 | Building Sovereign Cloud Environments | Code talk 場所: 12月3日(水) | 午前10:30 – 11:30 PST | Mandalay Bay このセッションでは、AWS Control Tower と Landing Zone Accelerator on AWS が、国固有のコンプライアンスフレームワーク、リージョナルサービスの選択、データ移動のための自動化されたコントロール、国境を越えた転送を含む主要な主権要件をどのようにサポートするかを探ります。 COP349 | Balancing agility and compliance feat. the Digital Agency of Japan | Breakout session 場所: 12月3日(水) | 午前9:00 – 10:00 PST | Mandalay Bay このセッションでは、日本政府が 30 の省庁と 1,700 の地方自治体にわたるクラウド採用のための集中ガバナンスモデルをどのように成功裏に実装し、5,000 以上のアカウントをシームレスに管理できるようにしたのかを学びます。AWS Control Tower、AWS Config、AWS Security Hub などの AWS クラウドガバナンスサービスにより、規制業種および公共サービス業は、運用を合理化し、ガバナンスを強化し、進化するコンプライアンス要件を満たして、中央集権管理と地方自治のバランスを実現します。 COP346 | Governance that Enables Innovation at Scale feat. Eli Lilly | Breakout session 場所: 12月4日(木) | 午後1:00 – 2:00 PST | Caesars Forum AWS Control Tower を用いてクラウドガバナンスをモダナイズすることで、顧客は安全で回復力のある方法でより迅速に実験、イノベーション、スケールすることができます。アメリカの製薬会社である Eli Lilly が、重要なワークロードをダウンタイムゼロで AWS Control Tower に移行することによってガバナンス構造をどのように成功裏にモダナイズしたかを学びます。コンプライアンス要件を満たすためのコントロールの実装方法と、Account Factory for Terraform を統合してプロビジョニングを自動化し、俊敏性を高め、セキュリティ態勢を改善し、より迅速にイノベーションを行い、生活とコミュニティの改善に集中できるようにした方法を学びます。 クラウドガバナンスの展望 これらのセッションは、単なる技術トレーニングを超え、コンプライアンス上の必要性から戦略的ビジネス推進要因 (enabler) へと進化するクラウドガバナンスの実践例を示しています。AI 駆動型のガバナンスと統制を導入し、セキュリティ運用を自動化する組織は、スピード、セキュリティ、運用効率の面で大きな競争優位性を獲得します。 生成 AI をガバナンスワークフローに統合し、policy-as-code の自動化を重視し、事後対応型ではなく事前対応型の統制に焦点を当てることは、クラウド運用へのアプローチにおける根本的な転換を示しています。 re:Invent 2025 では、組織でこの変革をリードするための知識と実践的なスキルを獲得できます。 まだ参加できます！ re:Invent ポータルから登録してください 。 David Sokolik 10 年以上の IT およびクラウド経験を持つ David は、スケーラブルで耐障害性が高く、コスト効率に優れたソリューション構築において、顧客のための献身的なチームメンバーであり、支援者です。David は家族や友人と世界中を旅し、現地の料理を探求する時間を大切にしています。 翻訳はソリューションアーキテクトの山田が担当しました。原文は こちら です。

自治体においては、労働人口減少に伴い職員数の確保が難しくなっていることや住民へのインターネットの普及率の向上から、職員の業務効率化や業務のデジタルトランスフォーメーションが重要な課題となっています。近年の生成AIの登場は、これらの課題に対する有効なソリューションとして期待されています。生成AIを取り巻く技術は目覚ましい発展を遂げており、自治体での活用可能性もますます拡大しています。 こうした状況を踏まえ、2025 年 6 月 25 日・26 日に開催された AWS Summit Japan 2025 において、生成 AI 技術を活用した自治体向けのソリューションのデモ展示をいたしました。親しみやすいアバターを通して避難者情報を収集しカードの発行までを行う「避難所窓口対応ソリューション」と、電話上で自然な日本語を使って情報の検索や予約などが行える「 Amazon Connect x 生成AI」、さらに書類不備の早期発見を助ける「AirDoc」の 3 つのデモを通じて、現在の生成 AI 技術が自治体でどのような可能性を秘めているかをご紹介しました。 本ブログでは、Summit 会場にてご紹介したデモの詳細を解説し、現在の生成 AI 技術が自治体の業務改善にどのように貢献できるかを、より多くの皆様にお伝えしたいと思います。動画で実際に動く様子も見ることができますので、ぜひご覧ください。 目次 避難所窓口対応ソリューション Amazon Connect x 生成AIエージェント Airdoc – PDF書類のAI OCR・JSONデータ抽出ツール まとめ 避難所窓口対応ソリューション 生成AIエージェントを用いた窓口アバターです。 解決したい課題 避難所での、被災者情報を取得し各種申請を行なったり、罹災したことを証明する避難者カードを発行するという業務 高齢者や子供など、すべての人がタブレットなどの端末から自分で情報を入力できるわけではないため、完全セルフサービスにしてしまうのも問題がある 生成AIを利用したソリューションアプローチ 上記課題を踏まえて、今回のデモでは生成AIを用いて避難者情報の対話型収集を行い、JSON形式で情報を記録するとともに、そのデータを加工してHTMLベースの人間が閲覧しやすく印刷もできる避難者カードを発行する、というソリューションを開発しました。 生成AIの自然な日本語によるヒアリングで、プライバシー設定や怪我の有無などを聞き出し、避難者カードに必要な情報を収集します。その後、生成AIが収集した情報を使ってJSONデータを作成し、さらにコードを実行してそのデータを決まった形のHTMLカードに整形します。 生成AIが対応するため、動画にある通り、「私は無事ですが、花子は怪我をしています」などの曖昧な指示をしても、「私」が誰であるかや「怪我」とは被害のことであることを認識し、出来上がったカードでは正しい名前とともに 無事です/被害があります/不明です のいずれかにチェックがされています。 技術的なポイント ローカルのアプリケーションから、基盤モデルは Amazon Bedrock を、音声読み上げは Amazon Polly を、音声認識は Amazon Transcribe を活用しています。 AI エージェントを用いることによって、ローカルでコードを実行してJSONデータを加工し、生成AIの挙動に左右されることなくいつも同じ形式のHTMLカードを作成することができます。 AWSがサンプルとして提供するオープンソースソフトウェアである Bedrock Engineer をベースとして、 Generative AI Avatar Chat を組み合わせる形で作成しました。 期待できる効果 電子機器に不慣れな市民についても、人間を介することなく対応できる 職員数を確保することが難しい災害時において、申請・発行業務に割く人員を削減できる より必要な支援を住民に届けることができる 実際に稼働させる場合に考慮すべきこと/コスト ローカルでアプリケーションを動かしていることから、AWS上で発生するコストは基盤モデル、音声読み上げ、音声認識のAPI使用料のみです。詳しくは Amazon Bedrock の料金ページ 、 Amazon Polly の料金ページ 、 Amazon Transcribe の料金ページ をご覧ください。 ローカルでアプリケーションを動かしデータもローカルに保存するため、端末の取り扱いや端末のネットワーク接続に気をつける必要があります。 Amazon Connect x 生成AI RAG（情報検索）、生成AIエージェント、人間へのエスカレーションといった機能を持つコールセンター自動応答ソリューションです。 解決したい課題 電話対応 マニュアルから引用して答えれば事足りるもの・予約などの事務手続き・複雑で専門性が求められる問い合わせなどが混在 一部は自動化きるが一部は人間の対応が必要 生成AIを利用したソリューションアプローチ 上記課題を踏まえて、今回のデモではお問い合わせをしてきた住民の要望を判別し、情報検索を行って回答したり、データベースアクセスできる予約エージェントに繋いだり、人間にエスカレーションしたりすることができるコールセンターAIを実装しました。 下の音声では、 情報検索を行って回答するケースとして、子ども医療費助成制度の案内を行なう 予約エージェントに繋いで、場所や希望日時などを収集し、予約情報をデータベースに保存する 複雑な相談や苦情対応では、人間のオペレータへ適切に引き継ぐ といった動作が確認できます。 また、 Amazon Connect は音声通話にもチャットにも対応しているため、一度設定を行えば両方で対応することが可能です。 技術的なポイント 音声通話またはチャットが開始されると、まず Amazon Q in Connect (Amazon Connect と統合された Amazon Q) が対応します。このエージェントは情報検索（RAG）による回答や予約エージェントへの切り替え、人間へのエスカレーションを担っています。 予約エージェントは、 AWS Lambda で動作しており、Amazon DynamoDB にある空き時間テーブルを見て住民に都合のいい時間帯を確認し、予約内容について了承が取れたら予約テーブルに新しい予約情報を挿入します。 期待できる効果 自動化できる部分を自動化し、人間への適切なエスカレーションを行う 職員の業務を効率化 住民の待ち時間を減らす 実際に稼働させる場合に考慮すべきこと/コスト 2025年8月現在、 通話のユースケースでは以下の料金がかかります Amazon Q in Connect の使用料 0.008 USD/分 Amazon Connect のサービス利用料金 0.018 USD/分 ウェブ通話の音声使用料金 0.01 USD/分 チャットのユースケースでは以下の料金がかかります Amazon Q in Connect の使用料 0.0015 USD/メッセージ チャット料金 0.004 USD/メッセージ 2025年8月現在、既存の電話番号を移行することは基本的にできないため、既存の電話番号を利用する際は別途転送などの料金を考慮することが必要です。 電話番号を取得しなくても、Web上に埋め込んだソフトフォンからチャット・音声通話を受けることができます。 最新の詳しい情報は、Amazon Connect の 料金ページ をご覧ください。 Airdoc 申請書類などのファイルデータ (PDFや画像) を⽣成 AI を⽤いて OCR (文字認識) し、JSON 形式のデータとして抽出するソリューションです。 解決したい課題 日々多数提出される住民からの就労証明書や各種申請書類などのPDF書類 記入内容の確認・不備のチェック・データ入力作業などを、手作業で行っていて処理に時間を要している 生成AIを利用したソリューションアプローチ 上記課題を踏まえて、申請書類のファイルに記入された内容をシステムが扱いやすいJSON形式のデータとして抽出する生成 AI ソリューションを開発しました。 具体的には、以下の 2 ステップで内容を抽出しています。 サンプルファイル（就労証明書の記入例の PDF ファイルなど）からその書類の内容に合った JSON スキーマを生成 AI で自動生成。（JSON スキーマは必要に応じてユーザーが編集可能） ステップ 1 で作成した JSON スキーマに従って、実際に申請された書類の内容を、JSON 形式のデータとして生成 AI で抽出。 自治体のシステムに本ソリューションを組み込めば、（書類の内容が JSON データとして抽出されシステムで処理することが可能になるので）今まで職員が手作業で行っていたデータ入力作業や書類の内容を精査する作業を自動化出来るようになります。 技術的なポイント バックエンドには AWS Lambda、Amazon Bedrock、Amazon DynamoDB、Amazon S3 を組み合わせたサーバーレス構成を採用しています。 JSON スキーマの抽出、JSON スキーマの生成を担う部分には Amazon Bedrock で利用可能な Claude モデルを利用し、Few-shot プロンプトを追加することで精度を高めています。 フロントエンドには Vue.js を利用して、Amazon CloudFront と Amazon S3 でホストしています。 セキュリティの観点では、AWS WAF で IP アドレス制限をかけたり、Amazon Cognitoで認証認可を行っています。また、フロントエンドのアプリケーションから AWS Lambda の Function URL に API リクエストを送る部分では、SigV4 署名で IAM の認証情報を追加しています。 期待できる効果 職員の業務負担軽減 住民サービス向上 実際に稼働させる場合に考慮すべきこと/コスト 月間の処理件数や書類内容のデータ量によって、Amazon Bedrock の利用料金（処理トークン数に応じた従量課金）が変動するため、事前の処理量見積もりが必要になります。詳しくは Amazon Bedrock の料金ページ をご覧ください。 プロンプトのチューニングやモデルの変更、書類の形式変更などによって、データ抽出の精度向上を検証する必要があります。 生成AIの特性上 100% の精度は保証できないため、自動化された業務の最後に職員による最終確認フローを残す必要があります。 まとめ 本ブログでは AWS Summit Japan 2025 にて自治体向けブースで展示をした 3 種類のデモについてご紹介しました。 今回ご紹介したデモが、自治体の課題解決に役立てられれば幸いです。 最後に、本ブログでご紹介したデモに関して、ご興味・ご質問をお持ちのお客様は お問い合わせフォーム もしくは担当営業までご連絡ください。また会場で投影した資料を こちら からダウンロードできます。 本ブログは、 アマゾン ウェブ サービス ジャパン合同会社 パブリックセクター のソリューションアーキテクト、押川令、岸本尚大が執筆しました。

本ブログは株式会社情報戦略テクノロジー様とAmazon Web Services Japan 合同会社が共同で執筆いたしました。 みなさん、こんにちは。AWS アカウントマネージャーの中道です。 社内の重要な情報が複数のツールに分散し、必要な情報を見つけ出すのに思わぬ時間を費やしていませんか？また、組織の成長に伴い、社員一人ひとりの成長やスキルアップを適切に把握・支援することが難しいと感じることは、多くのお客様の共通課題だと感じています。 伴走型戦略DXファームの 株式会社情報戦略テクノロジー様 は、 社員一人ひとりに寄り添い、共に成長することをコンセプトとしたパーソナルAIエージェント秘書サービス「パイオにゃん」 を開発されました。本記事では、AI Agent を活用した、情報探索の効率化や社員の成長の可視化に向けた取り組みについてご紹介します。   お客様の状況と経緯 株式会社情報戦略テクノロジー様は、事業拡大に伴い以下の課題に直面されていました。 ・情報探索の非効率性 ：社内の情報が複数のツールに分散し、必要な情報の検索に多大な時間を要している。 ・社員数増加と個別対応の限界 ：コミュニケーションが希薄化し、一人ひとりの状況や課題の把握が難しい。 ・成長の可視化 ：個人のスキルや経験の成長を客観的に評価することが難しく、効果的な育成計画の立案が難しい。 これらの課題に対して、AI Agent を活用し効率的な情報探索、社員一人ひとりへのきめ細やかな支援、個人の成長の可視化を目指しました。   ソリューション / 構成内容 「パイオにゃん」は、Slack、Googleドライブ、GitHubといった社内の多様な情報源と連携し、過去のやり取りや文脈を深く理解することで、各個人に最適化されたアドバイスや情報を提供します。利用者のスキル向上と連動してAI自身もレベルアップし、アバターが視覚的に成長していく「AI成長システム」です。これにより、社員はゲーム感覚で自身の成長を実感でき、学習意欲の向上を促します。 「パイオにゃん」の成長度合いや、社員のAIリテラシーレベルが一目でわかる専用のダッシュボードを提供します。猫のアバターが子猫から成猫へと成長していく様子を視覚的に確認でき、AIリテラシーレベルに応じた機能のアンロックや高度なアドバイスが提供されゲーム感覚でAI活用を促進し利用者のモチベーションを維持しながら、継続的なスキルアップを促します。画面は全てレスポンシブデザインで、PC・タブレット・スマートフォンなどデバイスを選ばず操作可能としました。 情報の探索部分は Amazon Bedrock のKnowledge Bases 機能を採用し、RAG (Retrieval Augmented Generation) によって膨大な情報をあいまい検索できる機能を実現しています。さらにKnowledge Bases のメタデータフィルタリングの機能により、ユーザーごとの権限によって検索対象となる情報を制限する機能を構築しました。 パーソナルアドバイスについては、業務内容、行動パターン、参照履歴などのユーザーひとりひとりの固有情報を用いて、検索処理や応答を最適化することで、個人個人へと最適化したRAG へ進化する仕組みを導入しています。 また、成長システムについては、Strands Agents SDK を利用して構築した AI エージェントが「組織独自のコンピテンシー定義」「ユーザーごとの会話履歴などの短期記憶、長期記憶」といったデータを元に、ユーザーの成長レーダーチャートを生成します。   導入効果 「パイオにゃん」の導入により、 年間24,000 時間かかっていた情報探索の時間を 4,000時間まで 約83%削減 できることが期待されており、社員は本来集中すべき業務に時間を費やすことができるようになります。※ また、社員一人ひとりの業務状況や課題、学習進捗を理解し、個別最適化されたサポートを提供することで社員のエンゲージメントが向上し、自身のスキルや経験の成長が客観的な指標やアバターの進化として可視化されることで、組織全体の生産性を最大化、継続的なモチベーション維持と自立的な学習を促進します。 (※フェルミ推定条件 : 対象人数400人、年間稼働日数240日、情報探索の頻度を1日5回とした場合。導入前の情報探索時間3分/回、導入後の情報探索時間30秒/回にて試算。)   今後の展望 株式会社情報戦略テクノロジー様は、2025年のパイオにゃんβ版リリースを皮切りに、段階的な機能拡張を計画されています。社内のフィードバックを元に機能改善を行い、各ツールの連携を拡大していく予定です。中長期的には、音声入力や出力機能、API 公開による外部サービス連携を視野にいれており、社員間のAI エージェントの貸し借りを可能にすることで、異なる思考や情報収集を疑似体験できる新たな価値提供を実現することを目指されています。 「『パイオにゃん』開発の核は、いかにして『一人ひとりに寄り添うAI』を実現するかでした。Amazon Bedrock の Knowledge Bases は、RAGによる高精度な検索とメタデータフィルタリングによる厳密な権限管理を驚くほど迅速に実現してくれました。技術的な挑戦であったアバターの成長システムも、今では社員のモチベーションを支える重要な要素です。アイデアを迅速に形にできたのは、AWSの豊富なサービス群と手厚いサポートがあったからこそ。生成AIの可能性を最大限引き出せるプラットフォームとして、Amazon Bedrock は最高の選択でした。」 株式会社情報戦略テクノロジー AI Officer　藤本 雅俊 氏 本取り組みは、アマゾンウェブサービスジャパン合同会社 広域事業統括本部主催の生成AI コンテストにてアイデアの革新性、ビジネスへの貢献度が高く評価され、23社の取り組みの中で「Scalable Innovation Award」を獲得されました。 Amazon Web Services Japan アカウントマネージャー 中道 野々香 ソリューションアーキテクト 小林 大樹

第一三共株式会社（以下、第一三共）はAWSとの連携を強化し、AIエージェントシステムを統合した創薬研究基盤の構築を開始しました。第一三共は現在、AI・クラウド技術を実験自動化技術と融合した次世代の創薬研究プロセスを段階的に構築しており、2026年の運用開始を目指しています。 近年、AIと高品質なデータの融合が、創薬研究に変革をもたらしています。なかでも、注目されているのが、創薬研究プロセス全体をAIエージェントシステムで統合し、研究者の知的活動をサポートする創薬AIプラットフォームです。（※1）英ウェルカムトラストとボストンコンサルティンググループ（BCG）の調査レポート（※2）によると、従来の低分子創薬の領域では探索研究から前臨床試験に至る創薬プロセスでのAI活用により、創薬研究に必要な時間とコストを少なくとも25-50%削減できる可能性が示されています。さらに第一三共が近年強化しているバイオロジクス創薬（※3）の領域においても、大規模言語モデルを活用した創薬の効率化に期待が高まるなど、AI活用が製薬業界における次世代イノベーションの鍵として世界的に注目を集めています。 独自の研究データとAIを融合した次世代創薬プロセスを実現 第一三共では、創薬研究プロセス全体の変革に向けて、研究者が従来、手作業で実施していた医薬品候補物質に関する実験の自動化を進めています。研究機器をAWSクラウド上で統合し、実験プロセスをプログラムコード化することで、実験から生まれたデータとその詳細情報（メタデータ）を自動的に捉え、AWS上の研究データ基盤に保存します。これにより、高品質な研究データを大規模に創出することが可能となります。さらに、この独自の研究データとAIを効果的に活用することで、創薬プロセスにおける医薬品候補物質の設計・合成・評価・分析（Design-Make-Test-Analyze、DMTA）サイクルの大幅な加速を目指しています。 例えば、研究者が医薬品候補物質について実験の指示を出すと、AIエージェントが自律的に過去の研究データを参照して最適な実験を計画し、24時間365日、複数の自動化された研究機器を連携させながら実験を進め、データを保存します。この研究データを国際的に認められるFAIR原則（※4）に基づいて管理することで、研究者だけでなくAIエージェントも自律的にデータを活用できるようになります。 第一三共では2023年に、組織横断でクラウド活用を推進するため、研究部門とIT部門が協働してCloud Center of Excellence（CCoE）を立ち上げ、翌2024年には研究者自身がセルフサービス方式でAWS上のクラウド基盤を創薬研究に利用できる環境を整備しました。今回の取り組みでは、研究機器をAWSクラウド上で統合し、 Amazon SageMaker Unified Studio を活用して、データメッシュアーキテクチャを採用した研究データ基盤を構築中です。データガバナンスポリシーに従い適切に管理・統制された環境において、AIエージェントを介したデータアクセスと活用を実現します。AIエージェントの開発には、生成AIアプリケーション構築のための Amazon Bedrock を採用し、将来的な導入に向けて Amazon Bedrock AgentCore の検証も進めています。このように、AWSの多様なマネージドサービスを活用することで、創薬研究基盤におけるアジリティとスケーラビリティを高め、研究者がイノベーティブな活動に集中できる環境を実現します。 人材育成と組織変革で実現する持続的イノベーション AWSは第一三共の持続的な創薬プロセス変革に向けた、人材育成とアジャイルな組織文化の醸成も支援しています。第一三共はAWS Professional Servicesの助言のもと、研究者自身がクラウドサービスやAI技術を学習しながら、創薬研究のデジタル変革を主導する体制を構築しています。さらに、クラウド・AIを活用した複数のアジャイル研究チームが共通のビジョンと価値創出に向けて連携しやすいよう、プロダクトマネジメントオフィス（PdMO）を設置するなど、組織面における変革にもチャレンジしています。今後も第一三共はAWSとの連携を深化させ、技術面と組織文化の両面から変革加速を支援することで、「革新的医薬品を継続的に創出し、多様な医療ニーズに応える医薬品を提供する」という同社ミッションの実現に向けて取り組みを加速します。 ※1 日本政府 新しい資本主義のグランドデザイン及び実行計画2025年改訂版 https://www.cas.go.jp/jp/seisaku/atarashii_sihonsyugi/pdf/ap2025.pdf ※2 ウェルカムトラスト・ボストンコンサルティンググループ（BCG）署 「Unlocking the potential of AI in Drug Discovery」2023年、6ページ https://web-assets.bcg.com/86/e5/19d29e2246c7935e179db8257dd5/unlocking-the-potential-of-ai-in-drug-discovery-vf.pdf ※3バイオロジクス創薬：遺伝子、タンパク質、細胞といった生体由来の物質や生物の機能を利用し、医薬品を開発する創薬研究プロセス。従来の化学合成された小さな分子を用いて病気の原因となるタンパク質などの標的に作用する低分子医薬品では対応が難しかった複雑な疾患メカニズムに対応でき、特異性が高く副作用の少ない治療法を実現できる可能性があると期待されている ※4 FAIR原則：研究データを「Findable（見つけられる）」「Accessible（アクセスできる）」「Interoperable（相互運用できる）」「Reusable（再利用できる）」にするための国際的な指針

データの分断を超えて、革新的な患者体験へ ヘルスケア・ライフサイエンス業界はセキュリティが極めて重要な業界であるため、厳格な規制が設けられており、それらの規制へのコンプライアンス対応が欠かせません。一方で、世界経済フォーラムによると医療機関で生み出されるデータの97％は十分に活用されていないという現状があります。電子カルテや医用画像、検査結果などのデータが個々のシステムや組織に点在し、標準化も進んでいないため、患者理解に不可欠な情報が断片化され、最適な医療提供の障壁となっています。 このたび AWS ジャパンは、日本のヘルスケア・ライフサイエンス業界に向けた戦略的ビジョン「 Journey for 2030 データがつながる、価値を生む 」を発表しました。このビジョンは、医療機関や製薬企業など患者を取り巻く多様なステークホルダーが、組織の壁を越えてデータを連携させ、革新的な患者体験を実現するうえでの AWS の貢献を示すものです。 「縦」と「横」のつながりで新たな価値を創出 このビジョンの核心は、データを「つなぎ」、そこから「新しい価値を生み出す」という考え方です。 「縦のつながり」とは、ゲノムや分子レベルのミクロデータから、診療記録や行動データといったマクロデータまでを統合することです。例えば、ゲノム解析と生活習慣データを結びつけることで、疾患リスクの早期予測や個別化医療が可能になります。 「横のつながり」とは、医療機関・製薬企業・研究機関・行政など組織間の壁を越えたデータ共有です。現在バラバラに存在する患者データを横断的に結びつければ、疾患の進行や治療効果を長期的に追跡し、最適な医療介入が実現します。 AWS ジャパンは、生成 AI とクラウドテクノロジーを活用してこの両方向のつながりを推進し、断片化されたデータから革新的な患者体験を創出します。 AWSが提供する4つの価値 1. つないで広げる：組織を超えたデータ連携の実現 医療・製薬データは極めて多様で、それぞれの組織内に閉じている限り、真の価値創出は困難です。 AWS Clean Rooms は、原データを共有せずに安全にデータを統合・分析できる環境を提供します。 米国では Datavant 社がこのサービスを活用し、7万以上の医療機関と350以上のデータプロバイダーをつなぎ、数カ月の探索作業を数日に短縮しました。日本でも、リアルワールドデータを用いた治験補完や市販後調査の効率化など、医療費抑制と患者アウトカム改善に直結するユースケースが拡大しています。 2. かしこく支える：生成 AIによる意思決定と業務の高度化 整備されたデータ基盤があってこそ、生成AIやエージェントは真価を発揮します。 Amazon Bedrock は複数の基盤モデルを統合的に利用でき、ユースケースごとに最適なモデルを選択できる環境を提供します。 スイスの製薬大手ロシュグループの Genentech 社では、創薬研究に AI エージェントを導入し、過去の特許・論文・ゲノムデータの統合探索を数日から10分に短縮。研究者は本質的な仮説構築や化合物設計に集中できるようになりました。 3. 安全にまもる：セキュアで信頼性の高いデータ活用基盤 AWS は世界最高水準のセキュリティを提供するとともに、日本国内の 3省2ガイドラインに準拠した利用リファレンス をパートナーと共に公開しています。 ライフサイエンス領域では、GLP、GCP、GMP など（総称して GxP ）のコンプライアンス対応のための ホワイトペーパー や パートナー提供のリファレンス を通じ、治験データ保管や製造工程記録管理など厳格な要件が求められるユースケースでもお客様を支援します。 4. ともに進める：現場と育てるデジタル人材育成 持続的なデータ活用には人材育成が不可欠です。AWS はインプット（知識習得）、アウトプット（スキル獲得）、実践（内製化支援）の3段階で体系的な支援を提供します。 第一三共株式会社ではこの枠組みを活用し、創薬研究基盤の内製化を実現。外部依存を減らし、自社内で継続的にイノベーションを生み出せる組織文化を醸成しています。 新たな取り組み：HealthData x Agent [ ウェブサイト ][ ブログ ] AWSは医療・製薬業界向けに「HealthData x Agent（ヘルスデータエージェント）」を新たに発表します。これは50個のユースケースに対応したデモ動画とツール群を無料で提供し、生成AIの具体的活用シナリオを示すものです。 医療機関向けには、診療記録から退院サマリーを自動生成するツールで医師や看護師の事務負担を軽減し、患者との時間を確保。製薬企業向けには、AI エージェントが化合物情報や試験データを統合解析し、創薬サイクルを大幅に短縮するツールを提供します。 各ツールは現場の課題に直結するシナリオとともに提供され、AWS クラウドサービスを活用した実装サンプルとして、すぐに概念実証や本番検証を開始できます。詳細はこちらのブログをご参照ください。 お客様事例：データから価値を創出する先進的取り組み 第一三共株式会社： AWS 基盤による Discovery Research DX の加速　[ ご登壇スライド ] [ ブログ ] 第一三共は、AWS と連携してAI エージェント統合型創薬基盤の構築を開始したことを発表しました。AI エージェントシステムと実験自動化技術を統合することで、創薬研究に必要な時間とコストを大幅に削減し、研究効率の向上を図ります。また、研究者自身がクラウドサービスや AI 技術を主体的に活用できる環境を整備し、人材育成とアジャイルな組織文化の醸成を通じて持続的なイノベーションを推進しています。これらの取り組みにより、革新的な医薬品をより迅速に患者さんに届ける創薬研究プロセスの実現に貢献していきます。 国立大学法人 浜松医科大学： GenU を用いた医療情報利活用　[ ご登壇スライド ] [ ブログ ] 浜松医科大学は、静岡県全体の医療空洞化という社会課題の解決に向け、デジタルトランスフォーメーション（DX）による医療の高度化等を確立するため、クラウドを活用したデータプラットフォーム構築に取り組んでいます。このプラットフォームを活用し、国が進める「医療 DX令和ビジョン2030」の柱の一つである「電子カルテ情報共有サービス」のモデル事業の来年度本番運用開始を予定しています。また、AWS とはスマートヘルスケア実現に向けた包括連携協定を締結しており、生成 AI アプリ実装ソリューションである GenU (Generative AI Use Cases JP)を活用し、医療従事者の働き方改革の実現を目指しています。 日本の医療・製薬の未来に向けて AWS は、行政、アカデミア、医療機関、製薬企業、ヘルステック企業など多様なステークホルダーの戦略的パートナーとして、日本独自の課題解決に貢献することを強くコミットしています。グローバルの知見を活かしながらも日本市場のニーズに即した支援を提供し、2030年に向けて質の高い個別化医療の実現に貢献します。データがつながり、新たな価値が生まれるとき、日本のヘルスケア・ライフサイエンスは大きく進化します。その未来を、AWS はお客様とともに切り拓いてまいります。   アマゾン ウェブ サービス ジャパン合同会社 常務執行役員 エンタープライズ事業統括本部長 堤 浩幸 常務執行役員 パブリックセクター統括本部長 宇佐見 潮

「先生、この薬は本当に使えないのですか？」 40代の母親がそう尋ねたとき、主治医は言葉を失いました。 効果があると知っているのに—「日本ではまだ承認されていません」。 生きられたかもしれない命が、静かにこぼれ落ちていく。そんな現実が、この国の医療で起きています。 数字が物語る、日本の医療の危機 2024年、国立大学病院長会議の発表によれば、全国42の国立大学病院のうち32病院が赤字見込み 1） 。医療機関の倒産は事業者（施設運用主体者）数ベースで64件、休廃業・解散は722件。過去最多を更新しました。 2) これは単なる経営の問題ではなく、医療の質や安全性に直結します。 医療DXの遅れが、新薬開発の足かせに 電子カルテの普及率は、医療施設種別で差があり、一般病院では約65.6%・診療所では約55%（2023年医療施設調査）と報告されています。400床以上の病院では、90%が導入済みとされていますが、世界的には、医療機関が日々生成するデータのうち約97%が活用されていないとの指摘があり 4) 日本も例外ではありません。医師の働き方はすでに逼迫しており、業務効率の観点でも問題ですが、加えて、臨床試験の効率低下、研究時間の不足、リアルワールドデータ（RWD）の質と量の不足といった深刻な問題を引き起こしています。 特に、新薬開発に欠かせない臨床試験において、複雑化する適格基準に対応するためには、単なるデジタル化や従来型の検索では限界があり、医師が夜遅くまでカルテや検査データを照らし合わせても、見落としや誤選定のリスクが付きまといます。結果として、試験の達成率は下がり、エントリー期間は延び、治験開始後においても、労働集約的で高コストな環境に、製薬企業は日本での開発投資を躊躇う。日本の患者は「治せるはずの未来」から遠ざかってしまうのです。 ドラッグ・ラグとドラッグ・ロス——命の選択肢が奪われる現実 厚生労働省の調査によれば、欧米では承認されているが日本で未承認の医薬品は143品目で、そのうち86品目が国内で開発未着手、57品目が開発中（＝承認が遅延している）とされています（2023年時点の集計）。希少疾患やがんの患者にとって、これは「生きられたかもしれない命」が失われる現実です。 保険が使えず、1カ月数百万円の治療費。副作用の強い旧来治療しか選べない。承認を待つ間に病状が進行する——。技術の遅れが、命の選択肢を奪っています。 現場発の挑戦——DXで”治せる未来”を取り戻す こうした厳しい現実を前に、医療現場からはテクノロジーを駆使した挑戦が始まっています。2025年7月に実施された 第29回日本医療情報学会春季学術大会 では、藤井進先生（東北大学災害科学国際研究所/東北大学病院　メディカルITセンター・医療データ利活用センター）を座長に迎え、2つの希望ある事例が発表されました。 東北大学病院：危機を超えて未来へ 中村直毅先生（東北大学病院メディカルITセンター）は、コロナ禍におけるDX推進を振り返りながら、こう語ります。 「医療従事者と医療技術者が協力して、宿泊施設が第二の病院として機能するように、情報連携の仕組みを整備しました。結果、宮城県の感染者数・死亡者数を全国でも最小に食い止め、DX大賞の受賞に繋がりました 6） が、すべてお手製で、非常事態の中で限界を超えた挑戦でした。」 コロナ禍を乗り越えた2025年、同院が取り組むのは臨床試験業務のAI活用による効率化です。 「AIエージェントが、複雑な条件の下でも自律的に患者をスクリーニングし、エラー修正も含めてリスト作成まで完結してくれました。今回の実証で、AIエージェントが、ドラッグ・ラグやドラッグ・ロスの原因の1つである被検者検索に係る課題解決に貢献しうるという手応えを得ました。今後も、技術を活用して、現場に山積する課題を解決し、治療が届く未来を実現したいと思います。」 浜松医科大学：看護変革の最前線 寺阪比呂子先生（浜松医科大学医学部附属病院）は、看護業務におけるAI活用の可能性を示しました。 「褥瘡マット選定という、患者の状態・在庫状況・使用実績など複雑な判断を要する業務でも、AIエージェントが的確に支援してくれました。看護師は日々膨大な記録業務に追われているので、記録システムの再構築を行い、対患者ケアの時間を増やしたいと考えています。」 一方で、市販のAIツールは現場の多様なニーズに必ずしも合致しておらず、職種・業務ごとに別のツールを導入するのはコスト面での最適化が困難であることを指摘しました。職種・診療科に応じて現場の意見を基にコントロールできる柔軟なAIシステムの必要性を課題提起されました。 座長の東北大学藤井先生は、本セッションが、医療情報を作る側（東北大学病院）と使う側（浜松医科大学）からの発表だったことに触れ、医療現場に定着する仕組みを作るには、多職種・多様な観点からの実証が重要であることを示唆されました。ご興味を持たれた方は、ぜひ浜松医科大や東北大学病院に視察に来てくださいと、同じビジョンや課題意識を持つ聴講者の皆さんとの意見交換と連携を呼びかけ、セッションを締めくくられました。 地域医療における課題解決を生成AIで加速 浜松医科大学の生成AI活用プロジェクトは、取組は、AWSの包括連携協定締結（2024年11月） ７） をうけて本格始動したもので、人口減少や少子高齢化に直面する県内の医療課題解決を目指し、医療従事者の働き方改革にも対応する取り組みが進められています。 こうした取り組みは、日本全体が直面する課題とも繋がっています。 病院から地域全体へ-社会インフラとして医療供給体制の変革を支えるクラウド- 人口1,000人当たり2.4人という少ない医師数で、世界最高水準の病床数13.0床 8) を支えてきた日本の医療体制。2025年以降、団塊世代の後期高齢者入りにより医療需要はピークを迎える一方で、生産年齢人口の急激な減少により医療従事者不足は深刻化します 9) 。こうした未来に備えるには、医療供給体制の抜本的な再構築が避けられません。今後10年間で予想されるのは、病床の統廃合、病院の機能分化と統合、そして地域医療ネットワークの重要性の飛躍的な高まりです。 急性期は高度医療に特化し、回復期・慢性期は地域に分散。診療所・薬局・介護施設・在宅医療がひとつのネットワークとして連携する。こうした再編を、セキュリティを担保しながら推進する、その要となるのが、クラウド基盤です。 クラウドで推進する医療Dx 6月13日のAWS Healthcare Webinar 10） で、東京慈恵医科大学の高尾洋之先生は強調しました。 「医療DX推進にはデータのデジタル化とAI活用が不可欠であり、その基盤としてクラウドは欠かせません。」 クラウドは、医療データの柔軟な拡張、災害時の安全なバックアップ、遠隔診療でのリアルタイム共有、多職種連携、AI利用促進、セキュリティ対応、コスト効率化、最新環境維持など多くの利点を持ちます。政府の医療DX方針や実装手順も整備され、クラウドは医療の安全性と効率化を支える基盤として位置付けられています。 世界初・日本初ブロックチェーンでドラッグ・ラグ、ドラッグ・ロスに挑むBuilderの取り組み 医療情報学会に先立って開催されたAWS Summit Tokyo 2025では、持続可能な医療の実現に向けて世界初・日本初の取り組みを推進するBuilderの事例として、SUSMED（サスメド）社の取り組みが紹介されました。（動画は こちら から）ブロックチェーン技術を世界で初めて治験に導入した同社は、東京科学大学との実証でモニタリング業務の効率を3割改善し、さらに、サンドボックス制度を活用して医薬品承認申請への応用も実証しています。 11) データの信頼性を担保しながら、治験を推進できるため、ドラッグ・ラグやドラッグ・ロスの解決に寄与することが期待されます。また、同社が24年に東北大学と発表したブロックチェーンを活用した静脈の疾患レジストリ 12） は、日本初の取組で、製造販売後データベース調査のデータの信頼性を担保し、そのまま条件再評価や適用拡大に使えるため、現場の負担を軽減しながら、最新の治療方法を患者さんに届けることに貢献します。 代表取締役　医師の上野太郎氏は次のように語っています： 「医療の現場で、デジタル技術が貢献できる場面は急速に増えています。命と向き合う現場に技術者の貢献が不可欠なものとなっています」 医療現場の危機は、新型コロナが過ぎても終わったわけではありません。むしろ、人口減少と超高齢社会の到来、医師不足の加速により、課題はより複雑さを増しています。ドラッグ・ラグやドラッグ・ロスの解消、医療供給体制の再編、個別化医療の推進等一つ一つの課題が複雑で多層的であり、単一の技術やノウハウ、1医療機関、1企業だけの尽力では解決できません。だからこそ、私たちAWSは医療・ヘルスケア業界の皆様に、協業の加速を呼びかけます。AWSのクラウド技術、AI・機械学習、セキュリティ、そしてグローバルな知見と、パートナー企業の知見、医療従事者が持つ専門知識、現場での実践経験、病気と闘う患者さんや見守る家族への深い理解—これらを組み合わせることで、今まで解決できなかった課題に新たなアプローチを見出すことができるはずです。 医療界の「アポロ計画」-協業で切り拓く医療の未来 1961年、ケネディ大統領は「この10年で人類を月に送る」と宣言しました。当時、多くの専門家が「不可能」と断じたこの目標に対し、NASA、民間航空宇宙企業、大学の研究者、材料科学者、コンピュータ技術者等40万人もの異なる専門分野の人々が集結、1969年7月20日、人類は月面に第一歩を記しました。「不可能を可能にする協業の力」を証明した瞬間です。 あなたの技術が未来を変える 協業の力が歴史を変えたように、未来の医療もまた、多くの人の力で変えられます。 その中で、あなたの技術や洞察が果たす役割は決して小さくありません。 患者と家族が嘆きます。「日本では、病気が治せない」 治験担当医師がカルテの前で頭を抱えます。「ここにいるはずの患者さんを、探し出せない」 夜勤明けの看護師はつぶやきます。「患者さんともっと話したい」 —この声に応えるのは、あなたかもしれません。 あなたの技術や洞察が、誰かの命を救う未来を切り拓く。 AWSはその挑戦を、全力で支援します。 出展 1) 国立大学病院の赤字（32病院） — m3報道（国立大学病院長会議の記者会見報道）。 m3.com 2) 医療機関の倒産／休廃業件数（倒産64件・休廃業722件） — 帝国データバンクの調査レポート（2024年）。 TDB 3) 電子カルテ導入率（病院65.6%、診療所55%：2023年医療施設調査） — 厚生労働省の医療施設調査／関連報道（JAHIS等まとめ）。 nkgr.co.jp 4) 「医療データの97%が未活用」 — World Economic Forum（記事）。※グローバル数値。 World Economic Forum 5) ドラッグラグ／ドラッグロスの現状（143品目・86未着手・57開発中） — 厚生労働省「ドラッグ・ロスの実態」調査（令和6年度科研事業資料）。 厚生労働省 6) 東北大学のDX取り組みと受賞（TOHOKU DX大賞ほか） — 東北大学公式リリース／学会資料。 tohoku.ac.jp 7) 浜松医科大学・アマゾンウェブサービスジャパン合同会社「包括連携協定の締結について」（2024年11月19日） https://www.hama-med.ac.jp/topics/20241119.html 8) OECD Health Statistics 2023「Physicians (per 1,000 population)」 OECD Health Statistics 2023「Hospital beds (per 1,000 population)」 https://stats.oecd.org/Index.aspx?DataSetCode=HEALTH_REAC 9) 国立社会保障・人口問題研究所「日本の将来推計人口（令和5年推計）」（2023年推計） https://www.ipss.go.jp/pp-zenkoku/j/zenkoku2023/pp2023_gaiyou.pdf 10) AWS Healthcare Webinar「生成AIと医療の未来」（登壇：高尾洋之氏, 2025年6月13日） https://aws.amazon.com/jp/events/healthcare-webinar-2025/ 11) フォームの始まりフォームの終わりSUSMEDの実証・効率化データ— SUSMED / AWS 発表資料（SUSMED SourceDataSync のスライド／PDF） https://pages.awscloud.com/rs/112-TZM-766/images/20241121-HCLS-2_Susmed.pdf 12) 医療機器の使用成績調査の利活用を促進する 統合型静脈疾患レジストリシステムを構築 ～医療現場の省力化・効率化と情報の信頼性を確保～ https://www.tohoku.ac.jp/japanese/2024/12/press20241211-05-system.html 問い合わせ窓口： aws-healthcare-ps@amazon.com 著者について 鈴田 尚子 (Naoko Suzuta) ヘルスケア事業本部　アカウントエグゼクティブ 医療機関の働き方改革をはじめとした課題解決や、医療・看護・介護に関わるHealthTech企業のサービス開発等を、クラウドサービスで実現する支援をしています。製薬や医療機器メーカーでの勤務経験もあり、現場で患者さんと向き合う医療従事者の方々の努力に深い敬意を抱いています。クラウドが少しでもその支えになれるよう、今後も真摯に取り組んでまいります。

ヘルスケア・ライフサイエンス業界では、患者ケアの質の向上とイノベーションの加速が強く求められています。一方で、現場では様々な課題に直面しています。ヘルスケアの現場では、診療記録の作成や情報検索に多くの時間が費やされ、患者と向き合う時間の確保が課題となっています。また、診療データの標準化や部門間での情報共有も容易ではありません。電子カルテやPHR（個人健康記録）、検査データなど、様々な形式のデータを統合的に活用することは、依然として大きな課題です。ライフサイエンス業界においても、研究開発の過程で生み出される膨大なデータの処理や、過去の知見の効率的な活用が重要な課題です。臨床開発では、試験計画の立案から実施、解析まで、データに基づく迅速な意思決定が求められています。さらに、リアルワールドデータの活用や、早期の安全性シグナルの検出など、より高度なデータ活用のニーズも高まっています。このような状況の中、生成AIへの期待が高まっています。自然言語での対話的なデータ活用や、複雑な分析タスクの自動化により、業務効率の大幅な改善が期待できます。特に、生成AIを活用したエージェントは、ユーザーの意図を理解し、必要な情報やアクションを適切に提供することで、業務プロセスを大きく改善する可能性を秘めています。 世界、そして日本のお客様からのこうした声を踏まえ、本日AWSは、ヘルスケア・ライフサイエンス業界に特化した生成AIソリューション「HealthData x Agent」（ヘルスデータエージェント）を発表しました。これは、実際の業務シーンですぐに活用できる生成AIデモとツール群です。HealthData x Agentは、診療現場での記録作成の効率化から、創薬研究におけるデータ分析の高度化まで、数十のユースケースに対応します。業務フローに自然に組み込める形で、生成AIの活用を支援します。また、医療情報の取り扱いに求められる高度なセキュリティ要件や、各種規制へのコンプライアンスにも十分な配慮がなされています。本ブログでは、HealthData x Agentが提供するソリューションのうちお客様のご要望の多かったものと、その活用シーンについてご紹介します。ヘルスケア・ライフサイエンス業界の業務担当者の皆様に、生成AI活用の具体的なイメージを持っていただければ幸いです。 ヘルスケア業界のソリューション 医療現場での業務効率化と質の向上を支援するため、HealthData x Agentは以下の3つの領域でソリューションを提供します。医療従事者の方々が、より多くの時間を患者のケアに充てられるよう、AIエージェントが様々な業務をサポートします。 診療記録作成の効率化 医師や医療スタッフの記録業務の負担を軽減するため、複数の文書作成支援ソリューションを提供しています。これらのソリューションは、日々の診療業務の中で自然に活用できるよう設計されています。 退院サマリーの自動作成 入院診療の要点を簡潔にまとめた退院サマリーの作成を支援します。診療記録から重要な情報を抽出し、構造化された形式で文書を自動生成。医師は生成された内容を確認・編集するだけで、質の高い退院サマリーを作成できます。入院期間中の主要な検査結果や治療内容、経過なども自動的に要約され、転院先や診療所との円滑な情報共有を実現します。 放射線読影レポートの患者サマリ生成 放射線科医の読影レポートから、患者や他科の医師向けに分かりやすい要約を自動生成します。専門用語を平易な表現に置き換えながら、重要な所見や結論を簡潔にまとめることができます。画像所見の経時的な変化や、臨床的に重要な変化も分かりやすく提示することで、患者への説明や他科との連携がスムーズになります。 音声入力によるSOAP文章生成 診察室での会話をリアルタイムに文字起こしし、SOAP形式（主観的情報、客観的情報、評価、計画）の診療記録として自動で構造化します。自然な診療の流れを妨げることなく、正確な記録を作成できます。2チャンネルの音声入力に対応し、医師と患者の会話を適切に区別して記録。さらに、関連する病名や国際疾病分類 第10版に対応したICD-10コードの候補も自動で提案します。 臨床意思決定支援 AIエージェントによる褥瘡予防マットレス選定 患者の状態や褥瘡リスクに応じて、最適な褥瘡予防マットレスを選定するAIエージェントです。日本褥瘡学会の褥瘡予防・管理ガイドラインの知識ベースと、院内で利用可能なマットレスの在庫情報を組み合わせ、エビデンスに基づいた選定を支援します。看護師は対話形式で患者の状態を入力するだけで、適切なマットレスの提案を受けることができます。また、選定理由も明確に示されるため、チーム内での情報共有や教育にも活用できます。 医療データ分析アシスタント HL7 FHIR形式で標準化された医療データに対して、自然言語で質問し回答を得ることができます。患者の検査結果や治療経過など、必要な情報に素早くアクセスし、より良い医療判断をサポートします。複雑なデータ検索や分析も、会話形式で簡単に実行できるため、日常の診療業務の中で効率的に情報活用が可能です。 データ活用 生成AIによるFHIRマッピング 様々な形式の医療データをFHIR形式に標準化する作業を支援します。生成AIの活用により、データ項目の対応付けやマッピングルールの作成を効率化し、異なるシステム間でのデータ連携を促進します。これにより、組織を超えた医療情報の共有や二次利用が容易になり、より質の高い医療サービスの提供が可能になります。 健診データの分析と可視化 健診センターの実績データを分析し、経営判断や健康増進施策の立案に活用できるインサイトを提供します。自然言語でのデータ分析が可能で、専門的な知識がなくても必要な情報を得ることができます。また、経年変化の分析や人口統計学的な傾向の把握も容易で、予防医療の推進や健診サービスの改善に役立てることができます。 ライフサイエンス業界のソリューション ライフサイエンス業界では、研究開発の加速化からコマーシャル活動の効率化まで、データドリブンな意思決定を支援する多様なソリューションを提供します。 研究開発支援 マルチモーダルデータ解析によるバイオマーカー探索 臨床データ、オミクスデータ、画像データなど、多様なモダリティのデータを統合的に分析し、新たなバイオマーカーの発見を支援します。AIエージェントが研究者との対話を通じて、複雑なデータ解析のワークフローを自動で構築。データの前処理から統計解析、可視化まで、一貫した分析環境を提供します。 さらに、公開文献やリアルワールドデータとの統合分析により、バイオマーカーの臨床的意義や有用性の評価も効率的に実施できます。研究者は、専門的なプログラミング知識がなくても、高度なデータ分析を実行することが可能です。 AIエージェントを活用したラボオートメーション 創薬研究におけるDMTA（Design-Make-Test-Analyze）サイクルを効率化するAIエージェントです。研究者との対話的なやり取りを通じて、実験計画の立案から結果の解析まで、一連のプロセスを支援します。 例えば、抗体医薬品の開発では、抗体配列の設計から特性予測、実験結果の評価まで、AIエージェントが自律的にプロセスを実行。機械学習モデルを活用した予測と実験結果のフィードバックにより、効率的な最適化サイクルを実現します。 HealthOmicsを活用したタンパク質デザイン AWS HealthOmicsと連携し、タンパク質の構造予測や特性最適化を支援します。事前学習済みの言語モデルやプロパティ予測モデルを活用することで、目的に応じた新規タンパク質配列の設計が可能です。バイオテクノロジーや創薬研究において、より効率的な分子設計を実現します。 臨床開発・製造 臨床試験プロトコルの自動生成支援 過去の臨床試験データや公開文献の知見を活用し、効率的なプロトコール作成を支援します。ClinicalTrials.govやPubMedのデータを自動で解析し、類似の試験デザインや重要な考慮点を抽出。さらに、社内の過去の試験情報も参照し、より質の高いプロトコール案を生成します。 人間による判断を補完する形で、エビデンスに基づいた試験デザインの検討が可能です。また、生成されたプロトコールは規制要件との整合性も確認されます。 製造プロトコール文書のコンプライアンス確認 生成AIを活用して、製造プロトコール文書（MPD）と標準作業手順書（SOP）との整合性を自動的に検証します。不整合や漏れ、不正確な記述を特定し、コンプライアンス違反のリスクを低減します。 文書間の相違点を詳細に分析し、修正が必要な箇所を明確に示すことで、品質管理担当者の作業効率を大幅に向上させます。また、規制要件の変更にも迅速に対応し、常に最新の基準との整合性を確保できます。 コマーシャル・メディカル 医薬品情報提供資料の生成・レビュー 添付文書や論文から、医師や患者向けの情報提供資料を効率的に作成できます。生成AIを活用して、対象に応じた適切な表現での説明文を自動生成。さらに、コンプライアンス要件に基づく自動チェック機能により、規制遵守も確実に行えます。 有害事象シグナル分析 FDAの有害事象報告データベース（FAERS）やPubMedの文献情報、製品ラベル情報などを統合的に分析し、安全性シグナルの早期検出を支援します。AIエージェントが自動的にデータを収集・分析し、潜在的な安全性の課題を特定。統計的なシグナル検出に加え、文献による裏付けも自動で検索します。 医療専門家は、対話形式でデータを探索し、特定の有害事象や製品に関する詳細な分析を実行できます。また、検出されたシグナルの重要度評価や、安全対策の立案までを一貫してサポートします。 セールスコンシェルジュ 生成AIを活用して、MRの営業活動を効率化・高度化するソリューションです。医師とのエンゲージメント履歴、製品情報、最新の医学文献などのデータを統合的に活用し、パーソナライズされた提案内容の作成を支援します。また、リアルタイムでの情報アクセスにより、医師からの専門的な質問にも適切に対応できます。 さいごに HealthData x Agentは、ヘルスケア・ライフサイエンス業界におけるデジタルトランスフォーメーションを加速する新たなソリューションです。生成AIの力を活用し、より良い医療の提供と革新的な創薬の実現をサポートします。 導入・活用のための支援体制 お客様のニーズに応じて、以下の2つの方法で導入いただけます： オープンソースによる提供 GitHub上で公開されているサンプルコードやデモの活用 自社環境に合わせたカスタマイズが可能 コミュニティによる継続的な改善と機能拡張 AWS Professional Services による導入支援 要件定義から実装まで、専門家による包括的なサポート 既存システムとの統合設計 セキュリティとコンプライアンスへの対応支援 運用体制の確立とナレッジ移管 継続的な進化への取り組み お客様とともに歩みながら、HealthData x Agentを継続的に発展させていきます： 新たなユースケースへの対応 既存機能の改善と高度化 お客様からのフィードバックの反映 業界標準や規制の変化への迅速な対応 詳細については、以下のリソースをご参照ください： HealthData x Agent ポータル: https://aws.amazon.com/jp/local/health/healthdata-x-agent/ ヘルスケア・ライフサイエンス業界向けポータル: https://aws.amazon.com/jp/local/health/ Agent Toolkit: https://github.com/aws-samples/amazon-bedrock-agents-healthcare-lifesciences 著者について 松永 徹人 (Tetsuto Matsunaga) ヘルスケア・ライフサイエンス ビジネスユニット シニアソリューションアーキテクト 国内外のヘルスケア・ライフサイエンスのお客様のクラウド利用を支援しています。SIerやコンサルティングファーム、製薬企業にてライフサイエンス業界へのITサービス提供の豊富な経験があります。

こんにちは、Amazon Connect ソリューションアーキテクトの坂田です。ようやく過ごしやすい季節になってきましたね！秋の味覚もいろいろですが、皆さんは何がお好きですか？わたしはなんでも好きなので、食べ過ぎ注意です。。 さて、 2025年8月のアップデートまとめ はご覧いただけましたか？前回はなんといっても、 Amazon Connect に組み込まれたAI 機能のバッジプログラム に注目でした。今回ももちろん、AI 関連のアップデートがありましたよ。それでは9月のアップデートを確認していきましょう！ 1. 注目のアップデートについて Amazon Lex が新たに 8 つの言語で生成 AI ベースの強化された自然言語理解を提供 Amazon Lex が日本語でも、大規模言語モデル（LLM）を利用したアシストつきNLU（Assisted NLU）をサポートするようになりました。Assisted NLU を使うと、顧客が例えば「えーっと、明日が結婚記念日でして、私と妻と子供で食事をしたいんですが予約をお願いできますか？」と言うと、Bot は 予約の日付は 2025−10-06 で、人数は 3名 だと解決することができるようになります。Assisted NLU を有効にすることで、Bot は冗長で複雑な発話から必要な情報を抽出することができます。 日本語のインテントで Assisted NLU を有効にするには、対象のボットで Japanese(JP) ロケールを選択し、Assisted NLU の設定を有効にします。有効にした後は Bot をビルド (構築) します。 Assisted NLU を有効にする場合、インテント名やスロット名はその目的やアクションを端的に示す名前をつけてください (例: BookTable)。また、インテント名とスロット名にプレフィックス、サフィックス、または不要な単語を追加しないでください。「Dev」や「Test」などの追加の要素は LLM を混乱させ、目的をより不明確にする可能性があります。さらに、インテントとスロットごとに、簡潔で有益な説明を含めます。これにより、特定の用途とコンテキストを説明し、人間と LLM の両方がその目的を理解しやすくなります。 詳細については、 Amazon Lex のドキュメント をご覧ください。 2. 2025年9月のアップデート&リリース一覧 Amazon Connect ダッシュボードが任意の時間範囲でのメトリクスのフィルタリングと比較をサポート – 2025/09/29 Amazon Connect ダッシュボードで、任意の時間範囲を指定してメトリクスを比較できるようになりました。最大で過去3ヶ月、35日分の範囲を指定することができます。 管理者ガイド Amazon Connect でコンタクトの特定のセグメントに属性を保存できるようになった – 2025/09/23 Amazon Connect でコンタクトを転送したりすると、転送後のコンタクトには新たなコンタクトIDが付与されます。この時、このコンタクトは転送前後の二つのコンタクトセグメントで構成されています。今回のアップデートにより、特定のコンタクトセグメントだけに属性（問い合わせセグメント属性）を記録することができるようになりました。 例えば、サポート部門で受電したコンタクトをセールス部門に転送したとき、転送前のコンタクトセグメントだけに”Support”というセグメント属性を記録し、転送後のコンタクトセグメントにだけ”Sales”というコンタクトセグメント属性を記録することができます。これにより、コンタクトセンターの管理者はより効率的に特定のコンタクトセグメントを検索することができるようになります。 コンタクトセグメント属性を利用するには、まず Amazon Connect で 事前定義されたコンタクト属性 を作成する必要があります。事前定義されたコンタクト属性はコンタクトフローの「コンタクト属性の設定」ブロックもしくは UpdateContact API を使って対象のコンタクトセグメントにアタッチすることができます。 記録されたコンタクトセグメント属性は例えば コンタクトの検索 で利用することができます。 管理者ガイド – 問い合わせセグメント属性を使用する Amazon Connect Contact Lens が新たに7つの言語で機密データの秘匿化に対応 – 2025/09/23 フランス語 (フランス、カナダ）、ポルトガル語 (ポルトガル、ブラジル）、イタリア語、ドイツ語、スペイン語 (スペイン）をサポートするようになりました。 管理者ガイド – 機密データの秘匿化を有効にする サポートする言語の詳細は こちら をご確認ください。 Amazon Connect のフローデザイナーで分析モードをサポート – 2025/09/23 Amazon Connect フローデザイナー上で、各ブランチを通ったコンタクトの割合や数を分析できるようになりました。これにより、顧客の行動パターンを特定したりエラーが発生している場所を特定したりすることができ、データ駆動型のフローの最適化が可能になります。 この分析モードを利用するには、対象のインスタンスで 次世代 Amazon Connect を有効にする必要があります。 詳細については、 管理者ガイド – フローデザイナー分析モードでメトリクスを使用してフローパフォーマンスをモニタリングする を参照してください。 サービスレベルの計算式のカスタマイズが可能に – 2025/09/22 Amazon Connect ダッシュボードにおいてサービスレベル（X秒以内に何%のコンタクトに応答できたか）を計算する際に、コールバック、放棄、または転送されたコンタクトを含めるかどうかを選択できるようになりました。これにより、それぞれのコンタクトセンターの要求に合わせてサービスレベルの計算をカスタマイズできます。 Amazon Lex の組み込みの Confirmation スロットと Currency スロットのサポートを新たに 10 言語に拡大 – 2025/09/18 Amazon Lex の組み込みスロットタイプの Confirmation スロットタイプと Currency スロットタイプが新たにポルトガル語、カタルーニャ語、フランス語、イタリア語、ドイツ語、スペイン語、標準中国語、広東語、日本語、韓国語の 10 言語でサポートされるようになりました。 Confirmation スロットタイプはユーザによる”確認”のさまざまな表現を取得するために使用し、ユーザーの発言をYes/No/Maybe/Don’t know のいずれかの値に解決します。 Currency スロットタイプは通貨を認識するために役に立ちます。例えば顧客が「100円」と発話した場合は ”JPY 100.00” と解決され、「100ドル」と発話した場合は “USD 100.00” と解決されます。 Amazon Lex の組み込みスロットタイプ Amazon Connect にエージェント階層フィルターを使用したコンタクト検索機能を導入 – 2025/09/18 コンタクトの検索でエージェント階層フィルターを使えるようになりました。 管理者ガイド Amazon Lex が新たに 8 つの言語で生成 AI ベースの強化された自然言語理解を提供 – 2025/09/17 詳しくは 注目のアップデート をご覧ください。 Amazon Connect Cases がケースリストビューで日付範囲フィルターのサポートを開始 – 2025/09/16 Amazon Connect Cases のケースリストビューで日付範囲によるフィルタリングがサポートされるようになりました。 例えば、ユーザーは、過去 30 日間に作成されたケースをフィルタリングして月次レポートを作成したり、過去 24 時間に変更されたケースを表示して直近のアクティビティをモニタリングしたり、今後 2 日以内に SLA 違反の可能性があるケースを表示して違反を防止したりできます。 管理者ガイド Amazon Q in Connect の Connect ウェブ UI で直接 LLM を選択可能に – 2025/09/09 エージェントアシストと顧客向けセルフサービスの両方で使える、生成 AI 搭載アシスタントである Amazon Q in Connect では、コンタクトセンターの管理者が Amazon Connect ウェブ UI からさまざまな大規模言語モデル (LLM) を直接選択できるようになりました（従来は API や CLI から行う必要がありました）。このノーコードアプローチにより、管理者は AI プロンプトの設定でさまざまなビジネス要件に適した、異なる LLM モデルファミリーを簡単に選択できます。例えば、応答時間を短縮するには Amazon Nova Lite を、複雑な推論タスクには Anthropic Claude Sonnet を選択したりできます。 AI プロンプトの種類ごとに利用可能なモデルの一覧は「 システム/カスタムプロンプトでサポートされているモデル 」をご確認ください。 Amazon Connect が、通話のトラブルシューティングを改善するための詳細な切断理由の項目を追加 – 2025/09/04 アウトバウンドコールが顧客に接続できなかった理由をよりよく理解できるように、切断理由の項目を拡充しました。拡張版の切断理由は、標準的な通信エラーコードに基づいており、より詳細な通話分析情報を提供し、迅速なトラブルシューティングを可能にします。 追加された接続失敗の理由(DisconnectReason)は TELECOM_BUSY、TELECOM_UNANSWERED、TELECOM_PROBLEM などです。各通話における DisconnectReason は ContactTraceRecord – ContactDetails 内に記録されます。 Amazon Connect でエージェントが、タスク、E メール、チャットを自分に手動で割 り当て可能に – 2025/09/03 エージェントは、キュー内の次の重要なタスク、電子メール、またはチャットを手動で優先順位付けできるようになりました。例えば、顧客が以前に提出した返金リクエストについて問い合わせの電話をかけてきた場合、エージェントはそのケースに関連する保留中のチケットを検索し、自分自身に割り当て、すぐに解決することができます。エージェントは Amazon Connect Agent Workspace の Worklist アプリ を使ってキュー内の特定のコンタクト（チャット、Email、タスク）に手動で優先順位をつけてピックアップすることができます。 AssociateContactWithUser と ListRoutingProfileManualAssignmentQueues の 2つの API を使うことで、これと同等の機能を実現することができます。 3. AWS Contact Center Blog のご紹介 IVR による電話注文から Amazon Pay 決済へ – Amazon Connect で実現する新しい注文導線の構築アイデア (日本語記事) AWS の Amazon Connect と Amazon Lex は、AI と音声技術を活用し、従来の無機質な IVR を自然で温かみのあるインタラクションに変革します。さらに、Amazon Pay と統合することで、電話注文から Web 決済までのシームレスな顧客体験を提供することが可能になります。この記事では、これらのサービスを活用して電話注文においてクレジットカード番号の伝達や複雑な入力プロセスを排除し、購入の途中離脱を防ぐ革新的なアプローチを実現する方法を示します。 コンタクトセンター運用を最適化する Amazon Connect の予測、キャパシティプランニング、スケジューリング機能 (日本語翻訳) コンタクトセンターの成功には効果的なワークフォースマネジメントが不可欠です。この記事では、Amazon Connect の予測、キャパシティプランニング、スケジューリング機能について紹介します。AI を活用したこの機能により、問い合わせ量の正確な予測、最適な人員配置、エージェントスケジュールの最適化が可能になります。この機能はクリック一つで有効化でき、内部運用の効率化、サービス目標の達成、エージェントと顧客満足度の向上に貢献します。 Amazon Connect の予測、キャパシティプランニング、スケジューリング機能 (2025 年第 2 四半期) (日本語翻訳) この記事では、Amazon Connect の予測、キャパシティプランニング、スケジューリング機能について、特に 2025 年第 2 四半期に発表された、スケジュールの管理に役立つ、予測の編集やアクティビティの管理機能について説明します。 Automate agent onboarding with Amazon Connect using PingOne : Amazon Connect と PingOne を使用したエージェントのオンボーディングの自動化 (英語記事) 労働力の変動が頻繁な現代のコンタクトセンター環境では、効率的なオンボーディングプロセスが不可欠です。この記事では PingOne イベントフックと Amazon Connect の統合により、エージェントのプロビジョニングを自動化し、運用エラーの削減、データセキュリティの強化、展開時間の短縮を実現する方法について説明しています。また、このシステムは一貫したロールベースのアクセス制御を提供し、退職者の認証情報の即時削除や、統合された監査証跡とリアルタイムのアクセス監視による規制遵守の確保を可能にします。これにより、コンタクトセンターの運用効率が大幅に向上し、セキュリティリスクも軽減されます。 Streamline employee support with Amazon Connect and Microsoft Teams integration : Amazon Connect とMicrosoft Teams の統合による従業員サポートの効率化 (英語記事) この記事では、大規模な国際金融サービス組織における IT サポート改革の事例を説明しています。この組織は、運用資産 1.46兆ドル、従業員数2万人以上を抱え、従来の IT サービスデスクは基本的な問い合わせで圧迫され、効率的なサポート提供に苦心していました。この問題を解決するため、組織は Amazon Connect を活用した AI 搭載チャットボットを導入し、Microsoft Teams との統合を図りました。この新システムは、一般的な IT 問い合わせの自動応答、ナレッジベースへの直接アクセス、必要に応じた人間のエージェントへのエスカレーション機能を提供しています。特に注目すべき点は、従業員が Teams 環境を離れることなくサポートを受けられる統合されたユーザー体験の実現です。このソリューションにより、従業員のセルフサービスアクセスが改善され、より効率的な IT サポート体制が確立されました。 Visualize and optimize your Amazon Connect costs with the Cost Insight Dashboard : コストインサイトダッシュボードによる Amazon Connect のコストの可視化と最適化 (英語記事) 本記事で紹介する Amazon Connect 用のコストインサイトダッシュボードは、コンタクトセンターのリーダーが求めていた詳細なコスト分析機能を提供し、生の請求データを実用的な洞察へと変換します。具体的には、月次支出傾向の追跡、サービスコンポーネント別のコスト分析、国や通話方向による通信費用の分析、チャネルコストの比較、地域別支出の分析、そしてコンタクトあたりのコストなどの重要な効率性指標を提供します。この包括的な分析ツールにより、マネージャーはサービス品質を維持しながら効率化の機会を特定し、より適切な運用上の意思決定を行うことが可能になります。 Unified customer story: Unlock a single source of truth for customer issues with Amazon Connect Cases and Tasks : 統合された顧客ストーリー：Amazon Connectのケースとタスクによる顧客課題の単一の情報源の実現(英語記事) この記事では、Amazon Connect のケースとタスク の導入・活用について具体的なお客様 (Arbonne社やOrbit Irrigation社)の事例を紹介していきます。 AWS recognized as a Leader in the 2025 Gartner Magic Quadrant for Contact Center as a Service (CCaaS) with Amazon Connect : AWS が Amazon Connect で、 Gartner 社 の Magic Quadrant 2025年版 Contact Center as a Service (CCaaS) 部門でリーダーとして認定 AWS は AI 駆動型のクラウドネイティブな顧客体験ソリューションである Amazon Connect によって 3 年連続で Gartner 社の Magic Quadrant Contact Center as a Service 部門のリーダーに選出されました。 Amazon Connect は、Amazon.com 自身のカスタマーサービス運営で使用されているテクノロジーを基盤とし、クラウドファーストで AI ネイティブな設計を特徴としています。このソリューションは、AI を顧客体験全体に組み込み、柔軟な従量課金モデルを通じて企業の運用コスト最適化とサービス品質向上を支援しています。このリーダー認定は、Amazon Connect が効率的でパーソナライズされた顧客サービスの新基準を確立し、企業の顧客エンゲージメントを革新していることを示しています。 4. AWS Black Belt オンラインセミナー (Amazon Connect 関連) Amazon Connect アウトバウンドキャンペーン詳説 Amazon Connect のアウトバウンドキャンペーン機能は、コンタクトセンターから顧客への能動的なアプローチを効率的に実施するためのソリューションです。ダイヤラー機能を活用した自動発信や、事前設定したキャンペーンに基づく発信スケジューリング、キャンペーン進捗の詳細な分析など、アウトバウンド業務に必要な機能を包括的に提供します。コンタクトセンターのアウトバウンド業務の生産性向上とコスト効率化をお考えの方は、ぜひご視聴ください。 資料（ PDF ） | 動画（ YouTube ） 今月のお知らせは以上です。皆さんのコンタクトセンター改革のヒントになりそうな内容はありましたでしょうか？ぜひ、実際にお試しいただき、フィードバックをお聞かせ頂けますと幸いです。 シニア Amazon Connect ソリューションアーキテクト 坂田 陽一郎

この投稿は AWS と SAP が共同で執筆しました。成功したパートナーシップとこのブログ投稿への貢献に対して、SAP for MeチームのForrest ZhangとLawrence Biに感謝いたします。 SAP Notesとは？ SAP NotesとKnowledge Base Articles（KBA）は、SAPのサポートエコシステムの基本的なコンポーネントです。これらの文書は、SAP ソフトウェア製品内の既知の問題に対する詳細な手順とソリューションを提供します。SAP Notesは主にコーディング修正と技術的ソリューションに焦点を当てていますが、KBAはビジネス言語で問題を説明し、しばしばスクリーンショットや視覚的な補助を含むことで、これらを補完します。これらは一緒になって、ユーザーとコンサルタントがSAP関連の課題を効果的にトラブルシューティングし、解決するのに役立つ包括的な知識ベースを形成します。 複雑なSAPシステムと文書のナビゲーションにおいてお客様が直面する課題 SAPプロフェッショナルが外出先でのトラブルシューティングのためにモバイルファーストのワークフローをますます採用する中、SAP Notesなどの重要な文書へのアクセスは増大する課題となっています。ユーザーはスマートフォンやタブレット経由でSAP Notesを即座に検索・取得することを期待していますが、コンテンツはデスクトップブラウザ向けに最適化されたままであり、モバイル閲覧者は過度なズーム、スクロール、テキスト重視のナビゲーションに耐えることを強いられています。重要な実装手順や緊急の設定修正は、コンパクトなスクリーンに適さない密集した技術的専門用語と複数ページのレイアウトに埋もれています。これらの手間が一刻を争う問題解決を遅らせ、サポートチームがモバイルデバイス上でデスクトップ形式のコンテンツを解読するのに時間を浪費し、重要なタスク中の見落としと認知疲労のリスクを増加させます。 SAP for Meチームが導入した要約機能とは？ これらの課題に対処するため、SAP for MeチームはAWSとパートナーシップを組みました。Amazon Bedrockを使用して、SAP NotesとKBAのAI生成要約を特徴とするモバイルアプリの新バージョンを開発しました。この革新により、ユーザーは簡潔で自動生成された要約を通じて技術文書を迅速にナビゲートし、理解できるようになります。 この要約機能がSAP for Meモバイルアプリのユーザーにとって有用な理由 要約機能により、ユーザーは特定のビジネスシナリオに対するノートの関連性を迅速に評価し、前提条件と実装要件に即座にアクセスできます。この機能は、長大な技術文書をモバイルフレンドリーなコンテンツに変換し、広範囲なスクロールなしに重要な実装手順を強調表示することで、緊急のトラブルシューティングシナリオ中に費やす時間を大幅に削減します。例えば、Basisや機能サポートチーム、コンサルタントなどのエンドユーザーは、外出先での効率向上の恩恵を受け、専門知識がモバイルファーストのコンテキストでよりアクセスしやすくなり、より迅速な意思決定を可能にし、調査のためのノートの関連性を迅速に判断する能力を提供します。 基盤の構築：ビジョンから最初のデプロイメントまで Think big と Start small 2024年のSAP SapphireでClaude 3.5 SonnetとAmazon Titanを特徴とするAmazon BedrockのSAP Generative AI Hubへの統合が発表された後、AWSはSAP China Labsと生成AIワークショップを開始しました。AWSとSAP China Labsは定期的なワークショップを通じて協力的な環境を育成し、数百万の技術文書からなるSAP NotesとKBAを生成AI強化の主要候補として特定しました。チームは、SAP Generative AI HubからAmazon Bedrock API経由でのClaudeモデルの呼び出しを実装するため、週次ミーティングとオンデマンドサポートを確立しました。初期の技術的課題にもかかわらず、AWSの技術支援により、SAPは2024年クリスマス前のデプロイメント期限を達成する事ができました。 チームが直面した初期の障害は何でしたか？ チームは、厳しい時間枠内で600万のSAP Notesを要約しようとする際に時間的プレッシャーに直面しました。AI生成要約の技術的精度を確保することが重要であることが判明し、新規および既存のノートの両方に対する要約更新を管理するための効率的なシステムの開発も必要でした。 アーキテクチャ詳細：バックボーンとしてのナレッジベース このプロジェクトは、Retrieval-Augmented Generation（RAG）を使用して、SAP NotesとKBAから直接お客様のクエリに対して正確な回答を提供し、複数の文書を手動で検索する必要がなくなります。お客様は正確で関連性の高い情報への即座のアクセスから恩恵を受け、問題解決を大幅に加速します。 RAGシステムは、SAP NotesとKBAに特化したデータ取り込みと処理パイプラインから始まります。この段階では、HTML形式のSAP Notesなどの非構造化および半構造化文書が体系的に収集、クレンジング、検索可能な形式に変換されます。主要なステップには、テキスト、メタデータ（ノート番号、適用性、リリースバージョンなど）の抽出、および文書間の相互参照の解決が含まれます。セマンティックチャンキングやエンティティ認識などの前処理技術が適用され、技術的なニュアンスを保持しながらコンテンツを文脈的に意味のある単位にセグメント化します。これらのチャンクは、Amazon Titan Embeddingモデルを使用して高次元ベクトル埋め込みにエンコードされます。処理されたデータは、高速類似性検索に最適化されたHANAベクトルデータベースにインデックス化され、検索中にユーザークエリを最も関連性の高いSAPコンテンツに効率的にマッピングできるようにシステムが確保されます。 クエリ段階では、RAGサービスは検索と生成を組み合わせて正確な回答を提供します。ユーザーがクエリを送信すると、システムはまずHANAベクトルデータベースを活用して、クエリの意図と意味的に整合したトップkのSAP NotesまたはKBAスニペットを検索します。再ランキングステップでは、関連性スコア、公開日、または適用性基準に基づいて結果を優先順位付けし、最新で実行可能な洞察を確保します。検索されたコンテキストは、SAP Generative AI Hub経由でAmazon BedrockのBedrock Claude 3.5 Sonnetモデルに送られ、簡潔で自然言語の応答を合成します。重要なことは、回答が検索されたソースに厳密に基づいており、透明性のために元のNotes/KBAへの引用が組み込まれている点です。このハイブリッドアプローチは速度と精度のバランスを取り、お客様がリアルタイムで問題を解決できるようにしながらハルシネーションを最小限に抑え、従来のサポートチャネルへの依存を減らします。 高レベルアーキテクチャ： 顧客価値とメリット 「SAP Notes/KBAの要約」と「SAP Notes/KBAのRAG」プロジェクトを通じて顧客体験を向上させるSAPの取り組みは、重要なビジネス価値を提供します。この2つのプロジェクトは重要な情報へのアクセスを合理化し、お客様が効率的に問題を解決し、SAPソフトウェア製品の使用を最大化できるようにします。明確性とアクセシビリティを向上させることで、お客様は関連するソリューションを迅速に特定でき、ダウンタイムを削減し、生産性を最適化できます。この正確な情報への強化されたアクセスは、運用効率を向上させるだけでなく、全体的な顧客サポート体験も強化します。 次のステップ：コンテキストを持つオンライン推奨 SAP for Meチームは、基本的な要約からエージェンティックRAGと知識グラフの使用に移行しています。これにより、よりスマートでコンテキスト対応の技術ガイダンスを提供し、システム依存関係と知識マップの可視化を容易にします。チームはまた、ユーザーエクスペリエンスをさらに向上させるために、予測サポートとパーソナライズされた推奨の追加にも取り組んでいます。これらのステップにより、SAPユーザーにとってより強力で直感的なサポートシステムが構築されます。 まとめ SAP for Meの生成AIジャーニーは、企業ソフトウェアの課題にAIを思慮深く適用することの変革的な影響を実証しています。Amazon BedrockのClaude 3.5 SonnetとSAPのGenerative AI Hubの統合を活用して、チームはSAPの膨大な技術ノートリポジトリに対する要約機能を実装することで、知識アクセシビリティの根本的な問題に取り組みました。この初期機能は、複雑な文書の効率的なモバイル消費という重要なニーズに対処しました。 生成AIのスキルアップや技術的精度の確保を含む初期の実装課題にもかかわらず、SAPとAWSチーム間の協力的な努力により、目標とした2024年年末ホリデー期限前に要約機能を成功裏に提供しました。この成果は単なる技術的マイルストーン以上のものを表しています。これは、SAPのお客様がモバイルデバイス上で重要な技術知識にアクセスし、活用する方法の根本的な変化を示しています。 エージェンティックRAG、知識グラフ、プロアクティブな推奨を通じて進歩する今後のロードマップは、静的な文書から動的で相互接続された予測的な知識システムへの進化に向けた戦略的ビジョンを示しています。この進化は、SAPの顧客サポートモデルを反応的な問題解決から、各お客様の独自の環境に合わせたプロアクティブなガイダンスに変革することを約束します。 SAP for Meモバイルアプリケーションのこれらの新機能を探求し、生成AIが技術サポートと知識管理をどのように変革できるかを直接体験することをお勧めします。Amazon Bedrockを活用し、組織のより大きな効率と洞察を解き放つ方法を学ぶために、私たちにお声がけください。 <!-- '"` --> 本ブログの翻訳はパートナー SA 松本が担当しました。原文は こちら です。

はじめに SAP HANAデータベースは、AWS上で継続的な運用を維持するために、高可用性（HA）構成でデプロイされることが多くあります。SAP HANAデータベースには、データを保護し、完全なシステム復旧をサポートするために、HA構成と包括的なバックアップ戦略の両方が必要です。SAP HAデプロイの利点にもかかわらず、SAP HANAデータベースは、クラスター全体の障害、論理エラー、データ破損、ランサムウェア攻撃、コンプライアンス問題など、さまざまなリスクに対して脆弱性を持っています。HAだけでは、ポイントインタイム復旧のニーズ、テスト/開発環境のシステム更新、長期データ保持要件などのシナリオに対処することはできません。組織には、完全なデータ保護、規制遵守、運用レジリエンスのための包括的な戦略が必要です。 RISE with SAP on AWSデプロイでは、データベースバックアップはAWS Backint Agent for SAP HANAを通じて管理されます。これは、SAP HANAデータベースと統合する標準的なバックアップソリューションです。バックアッププロセスは、RISEオファリングの一部としてSAPによって完全に管理されますが、お客様はSAPが提供するツールとAWS Backupコンソールを通じてバックアップステータスを監視できます。SAP ERPやS/4HANAなどのSAPをAWS上でネイティブに実行しているお客様には、AWS Backup for SAP HANAが優れた選択肢です。 このブログでは、組織がHAデプロイでAWS BackupによるSAP HANAデータベースの堅牢なバックアップ戦略をどのように実装しているかについて学習します。このブログでは、データ保護とWell-Architected Framework SAP Lensの信頼性の柱と運用のベストプラクティスについても説明します。 データ保護とSAP向けWell-Architected Framework Well-Architected Framework SAP Lens は、主に信頼性の柱内でデータベースバックアップを重視しています。この柱は、障害や中断に直面しても、SAPワークロードが意図された機能を一貫して正しく実行するための専門的なガイダンスを提供します。 信頼性の柱内では、データベースバックアップは、いくつかの重要な領域の主要コンポーネントとして強調されています： データ保護 ：フレームワークは、SAPデータベースやその他の重要なデータに対する堅牢なバックアップと復旧戦略を実装するためのベストプラクティスを提供します。これにより、組織はシステム障害、データ破損、その他の予期しない事象に備えてデータ復旧の準備を行うためのガイダンスを得られます。 災害復旧 ：バックアップは災害復旧計画において重要な役割を果たします。SAP Lensは、大規模なインシデントが発生した場合にバックアップを活用して運用を復旧する災害復旧メカニズムの設定に関するガイダンスを提供します。 高可用性 ：バックアップに直接関連するものではありませんが、高可用性戦略は、システムの稼働時間を確保し、バックアップからの復旧の必要性を最小限に抑えることで、バックアップ手順を補完します。 データ保持 ：フレームワークは、規制要件やビジネスニーズを満たすためのバックアップ戦略を含む、長期データストレージとアーカイブに関する推奨事項を提供します。 信頼性の柱は、データベースバックアップ戦略のいくつかの重要な側面を強調しています： 定期的で一貫したバックアップスケジュールの実装 効果的な復旧手順の徹底的なテスト 人的エラーを削減し一貫性を維持するためのバックアップソリューションの自動化 バックアップと復旧プロセス全体を通じたデータ整合性とセキュリティの維持 組織の復旧時間目標（RTO）と復旧ポイント目標（RPO）とのバックアップ戦略の整合 これらの領域に焦点を当てることで、 Well-Architected FrameworkのSAP Lens は、AWS上のSAPワークロードが回復力があり復旧可能であることを確保するための包括的なガイダンスを提供します。これにより、組織はビジネス継続性をサポートし、データ損失リスクを最小限に抑える効果的なバックアップ戦略を実装できます。このアプローチにより、障害時の重要なSAPシステムの迅速な復旧が実現され、ビジネスの中核業務に不可欠な信頼性と可用性が保持されます。 AWS Backint Agent for SAP HANAの概要 AWS Backint for SAP HANA は、SAP HANAのバックアップ機能とのネイティブ統合を提供し、アプリケーション整合性のあるバックアップを確保します。このソリューションは、ストレージにAmazon Simple Storage Service（S3）を利用し、耐久性、スケーラビリティ、コスト効率性を提供します。Backintエージェントは増分バックアップをサポートし、ストレージコストとバックアップウィンドウを削減します。また、転送中と保存時の両方でバックアップの暗号化を提供し、セキュリティを強化します。このソリューションはスクリプト化可能で、既存のバックアップワークフローとの自動化と統合を可能にします。データ破損や人的エラーに対処するために重要なポイントインタイム復旧（PITR）をサポートします。Backintは大規模なSAP HANAデータベースに対応し、バックアップ操作中のパフォーマンスへの影響を最小限に抑えます。コスト効率性は主要な機能であり、S3ストレージクラスとライフサイクルポリシーを活用して、長期保持のためにより安価なストレージクラスに移行します。このソリューションは、バックアップストレージのためのAmazon S3の高い耐久性と可用性の恩恵を受けます。 これらの機能により、AWS Backint Agentは、AWSストレージ機能を活用する信頼性の高いSAPネイティブバックアップソリューションを求めるお客様、特にSAPツールとの直接統合を好み、よりシンプルなバックアップ要件を持つお客様にとって優れた選択肢となります。AWS Backintエージェントを使用してSAPをAmazon S3で構成する方法の詳細については、 SAP HANAワークロードのAmazon S3へのバックアップと復元 をご覧ください。 Amazon Elastic Cloud Compute（EC2）上のAWS Backup for SAP HANA Amazon EC2上のAWS Backup for SAP HANA は、SAP HANAデータベースのバックアップと復元操作のための管理された合理化されたエクスペリエンスを提供します。直感的なAWS Backupコンソールを通じてカスタマーエクスペリエンスを向上させ、Amazon EC2、Amazon Elastic Block Store（EBS）、Amazon Elastic File System（EFS）を含む複数のAWSサービス全体でデータ保護を拡張し、管理を簡素化します。継続的バックアップ機能は、特にAWS Backint Agentでフルバックアップに制限されていたユーザーにとって、大幅なコスト削減を提供します。AWS Backupは、Backup Vault LockとLegal Holdsを使用したバックアップの包括的な監査とコンプライアンス機能をサポートします。自動化されたクロスリージョン・クロスアカウントバックアップコピーをサポートし、災害復旧とデータ冗長性を強化します。この完全管理サービスは、SAP HANAデータ管理を最適化し、AWSエコシステム内での信頼性と運用効率を向上させます。 AWS BackupでSAP HANAバックアップを自動化し簡素化する方法の詳細については、ブログ AWS BackupでSAP HANAバックアップを自動化し簡素化する をお読みください。SAP HANA用AWS Backupの構成方法に関するドキュメントについては、 ドキュメント をお読みください。 SAP HAデプロイの推奨事項 AWS Backup for SAP HANAは、シングルノードとHAデプロイの両方をサポートします。HAデプロイでは、以下の図-1に示すように、バックアップを実行するためのアクティブノードを自動的に識別します。お客様は、SAP HANA HAデプロイを管理するためにPacemakerクラスターソフトウェアを使用します。 図-1：AWS Backup for SAP HANA HAデプロイ Amazon EC2上でAWS Backup for SAP HANAを構成する手順は以下の通りです： Secrets ManagerにHANA認証情報を保存 EC2インスタンスとSecretsキーのIAM権限とタグを確認 HAデプロイのHANAインスタンスの1つをSSM for SAP（ssm-sap）に登録 SSMドキュメント（AWSSAP-InstallBackintForAWSBackup）を使用してAWS Backup用Backintをインストール AWS BackupコンソールでAmazon EC2上のSAP HANAをオプトイン バックアッププランを作成 AWS BackupコンソールからHAデプロイでSAP HANAデータベースのオンデマンドバックアップを開始するには、スケジュールされたバックアップはバックアップポリシーを定義することでバックアッププランで構成されます。以下は高レベルのアクティビティリストです： AWS BackupがSSM for SAPバックアップAPIを呼び出してバックアップを開始 AWS SSM for SAPがSSM実行コマンドを介してBackintを呼び出し バックアップがAWS Vaultに保存され、バックアップステータスが記録される Pacemakerクラスターマネージャーによって管理されるSAP HAデプロイでのデータベース復元の前後に必要な手順は以下の通りです。SAP HANAのHAシステムを復元する際に含める追加手順の詳細については、ドキュメント SAP HANA HA復元 をお読みください。さらに、Pacemakerクラスターの設定に関する詳細なガイダンスは、 SAP HANA on AWS：SLESとRHEL向け高可用性構成ガイド で確認できます。 復元前： SAPデータベースクラスターとノード（プライマリデータベースノードとスタンバイデータベースノード）をメンテナンスモードに配置し、両方のノードでSAP HANAを停止する必要があります。システムデータベースを復元した後、テナントデータベースの復元に進む前に、プライマリデータベースでSAP HANAを開始します。データベース復元操作中、SAPデータベースクラスターとクラスターノードはメンテナンスモードのままです。 SAP HANAデータベースの復元を開始するには、AWS Backupコンソールにログインし、フルバックアップまたは継続的バックアップ復旧ポイントIDを使用して復元を開始します。以下は高レベルのアクティビティリストです： AWS BackupがSSM for SAPバックアップAPIを呼び出して復元を開始 AWS SSM for SAPがSSM実行コマンドを介してBackintを呼び出し データベースがAWS Vaultからプライマリデータベースノードに復元される 復元後： システムとテナントデータベースの復元が成功した後、セカンダリデータベースノードでSAP HANAを停止します。プライマリデータベースノードでSAP HANAシステムレプリケーション（HSR）を登録し、続いてセカンダリデータベースノードで登録します。セカンダリデータベースノードでSAP HANAを開始し、SAPデータベースクラスターノードとグローバルクラスターをメンテナンスモードから解除します。 データ保護管理と運用の簡素化 AWS Backup for SAP HANAは、SAP HANAシングルノードとHAデプロイのバックアッププロセスを合理化し、復旧を強化し、災害復旧機能を向上させる堅牢な機能セットを提供する完全管理AWSサービスです。 機能 メリット 一元管理 複数のSAPインスタンス全体でバックアップと復元を管理する単一のダッシュボードにより、分散アーキテクチャでの復旧操作が簡素化されます。 コスト最適化ストレージ ライフサイクルポリシー管理機能により、復旧機能を損なうことなく、バックアップの費用対効果の高い長期保持が可能になります。 クロスリージョンとクロスアカウントコピー SAP HANAとのネイティブ統合により、複雑なSAP環境でのデータ整合性の維持に重要なアプリケーションの整合性のあるバックアップが作成されます。クロスリージョンとクロスアカウントバックアップ機能により、地理的に分散した復旧オプションが可能になり、災害復旧戦略とランサムウェア保護が強化されます。 コンプライアンスと監査 多くのSAPデプロイにとって重要な監査ログと保持ポリシーにより、規制要件を満たすのに役立ちます。Vault Lockは、AWS Backup vaultに保存されたバックアップの削除や変更を防ぎ、保持ポリシーを強制するメカニズムです。保持設定に関係なくバックアップの削除を防ぐためのリーガルホールドをサポートします。 監視とアラート デフォルトの→AWS Backup コンソールジョブダッシュボードでバックアップと復元のジョブステータス、および復旧ポイントID ステータスを監視。CloudWatch メトリクスとアラームで失敗したバックアップ、復元、復旧ポイントのステータスを監視します。 ポイントインタイム復旧（PITR） 復旧ポイントIDを維持するための自動化およびスケジュールされたPITR継続的バックアップ。PITRにより、1秒の粒度内で特定のタイムスタンプへのSAP HANAデータベースの迅速な復元が可能になり、ダウンタイムを最小限に抑えます。 ポリシーベースの自動化 自動化と事前定義されたポリシーにより、バックアップと復旧プロセスでの人的エラーを削減します。 リソースタグ付け SAP HANAバックアップ、およびAmazon EC2 Amazon Machine Image（AMI）バックアップ、Amazon EBSボリュームスナップショット、Amazon EFSファイルシステムスナップショットなどのAWSサービスに対して最大50のタグをサポートします。 簡素化された復旧管理 目標復旧時間（RTO）：継続的バックアップ（フルおよび増分）とデータベースログの組み合わせと自動化されたプロセスにより、SAPシステムの復旧時間が大幅に短縮されます。 目標復旧時点（RPO）：自動化されたスケジュール継続的バックアップにより、より最近の復旧ポイントとログが可能になり、最大1秒の粒度でデータ損失の可能性を最小限に抑えます。 スケーラビリティ 復旧速度や信頼性を損なうことなく、大規模なSAP HANAデータベースを処理するために簡単にスケールします。 スケジューリング 時間単位、日単位、週単位、およびカスタムcron式でAWS Backupコンソールからスケジュール。 セキュリティ KMSとIAM統合による組み込み暗号化により、データ整合性とアクセス制御を維持しながら、安全なストレージと復旧プロセスを提供します。 追加のSAPコンポーネントのサポート 他のAWSサービスとのシームレスな統合により、Amazon EC2、Amazon EBS、Amazon EFSなどの高度な復旧シナリオと自動化が可能になります。 AWS Backup for SAP HANAとAWS Backint Agentは、SAP HANAデータベースのバックアップに対して異なるアプローチを提供します。BackintはSAP HANA固有で、SAPエコシステムとシームレスに統合し、管理と復旧にSAPツールを使用します。対照的に、AWS Backup for SAP HANAはより汎用性の高いサービスで、ネイティブSAP HANAを含む複数のAWSサービス全体でバックアップ機能を提供します。AWSコンソールを通じて管理される、ストレージとライフサイクルオプションでより大きな柔軟性を提供します。 以下は、AWS Backint AgentとAWS Backup for SAP HANAの並列比較です： 機能 AWS Backint Agent for SAP HANA AWS Backup for SAP HANA 自動化 SAP HANAのスケジューリングメカニズム バックアップルールで構成されたバックアッププラン バックアップタイプ フル、増分、差分、ログ フル、増分、ログ カタログ管理 SAP HANAバックアップカタログに保存 AWS Backupカタログに保存 コンプライアンス 両方ともリーガルホールドなどの監査ログと保持ポリシーをサポート 災害復旧 Amazon S3クロスリージョンレプリケーション（CRR） 同じまたは異なるKMS キーを使用して、同じまたは異なるAWS Vault にリージョンとアカウントを跨いでバックアップをコピー エンドユーザーツール SAP HANA StudioからのSAP HANAデータベースのバックアップと復旧管理 AWS Backup コンソールからSAP HANA およびAmazon EC2、EBS、EFS などの追加のSAP コンポーネントのバックアップと復旧管理 暗号化 Amazon S3バケットサーバーサイド暗号化 SAP HANAデータベースバックアップは常に暗号化されます。AWS Key Management Service（KMS）暗号化はAWS Backup Vaultで構成 粒度 ファイルレベルとデータベースレベルのバックアップ データベースレベルのバックアップ、およびAmazon EC2、Amazon EBS、Amazon EFSなどのSAPコンポーネントのバックアップ ライフサイクル管理 Amazon S3ライフサイクルポリシー AWS Backup Vaultライフサイクルポリシー パフォーマンス SAP HANA固有のバックアップ操作に最適化 SAP HANAバックアップ操作、およびAWSサービス（Amazon EC2、Amazon EBS、Amazon EFS）に最適化 復旧 SAP HANA StudioからのフルデータベースとPITR復旧 AWS BackupコンソールからのフルデータベースとPITR復旧 スケーラビリティ SAP HANAデータベース専用に設計 SAP HANAデータベースおよびAmazon EC2、Amazon EBS、Amazon EFSなどのAWSサービス用に設計 ストレージ お客様が管理するAmazon S3バケットに直接保存されるバックアップ サービスが管理するAWS Backup Vaultに直接保存されるバックアップ セキュリティ Write-Once-Read-Many（WORM）モデルを使用するAmazon S3 Object Lock。IAMファイル粒度アクセス制御をサポート バックアップイメージの追加セキュリティと制御のためのAWS Backup Vault Lock。IAM ファイル単位のアクセス制御をサポート 運用のベストプラクティス AWS Backint AgentはSAPと深く統合されている一方で、AWS Backupはこの機能を拡張し、AWSサービスとより広く統合します。AWS Backupがより広いクロスサービス機能を提供し、BackintがSAP中心の専門機能を提供することで、SAP HANAバックアップ戦略に適した選択肢となります。以下は、Amazon EC2上のAWS Backup for SAP HANAの運用ベストプラクティスです。 発見と登録： AWS Backup for SAP HANAは、SSM for SAP（SSM4SAP）、Systems Manager（SSM）、Secrets Manager、AWS Backupを含むいくつかのAWSサービスへのパブリックエンドポイントアクセスを必要とします。スムーズな運用を可能にするために、両方のSAP HANAノードがサービスとストレージエンドポイントアクセスを許可するようにファイアウォールを構成します。AWS SSMエージェントは、SAP HANAデータベースをホストするEC2インスタンスにインストールされ、実行されている必要があり、正しいIAMロールが添付されている必要があります。すべてのHANAノードでこれらの前提条件を満たすことが、 AWS SSM4SAPでのSAP HANAデータベースの登録 を促進し、AWS Backupを通じて成功したバックアップと復元操作を実行するために必要です。 コスト最適化ストレージ： SAP HANA環境でAWS Backup Vaultの ライフサイクルとストレージ階層 を使用してコストを最適化し、管理を合理化します。組織の保持ポリシーに合わせて、フルデータベースバックアップとPITRバックアップの両方を組み込んだ包括的な階層化バックアッププランを実装します。この戦略により、費用を効果的に管理しながら堅牢なデータ保護が可能になります。フルバックアップについては、バックアップライフサイクルポリシーを活用して、古いバックアップをAmazon S3 Glacierなどのコスト効率の良いコールドストレージソリューションに自動的に移行します。このアプローチにより、データアクセシビリティを損なうことなく、長期ストレージコストが大幅に削減されます。PITR（継続的バックアップ）ではストレージ階層化はサポートされていませんが、PITRはデータベースに書き込まれた変更量に基づいてデータベースバックアップのタイプ（フルまたは増分）をインテリジェントに決定し、ライフサイクルポリシーと組み合わせてストレージコストを最適化します。 セキュリティ、ガバナンス、コンプライアンス： AWS Backup Vault Lock は、厳格なコンプライアンス要件とデータ保護を整合させる強力なガバナンスフレームワークを確立します。Vault Lockのコンプライアンスとガバナンスモードにより、組織は業界固有の規制を効果的に満たすことができます。リーガルホールド機能は、レビュー中のバックアップの削除を防ぎ、監査や法的手続き中のデータ整合性を確保します。AWS Backup Vaultの安全な 暗号化されたボルト と不変バックアップを実装します。この多層アプローチにより、SAPデータを不正アクセス、ランサムウェア攻撃、内部および外部の脅威から保護します。デフォルトでは、SAP HANAバックアップは暗号化され、AWS Backup Vaultはバックアップストレージの暗号化にAWS Key Management Service（KMS）の使用を義務付け、保存時のデータ機密性を確保します。 クロスアカウントとクロスリージョンコピーによる災害復旧（DR）： このマルチリージョンバックアップ戦略により、ビジネス継続性とリージョン停止に対する回復力が大幅に向上します。 クロスリージョン・クロスアカウント 機能により、バックアップを異なるAWSリージョンとアカウントに自動的にコピーでき、リージョン全体が利用できなくなった場合でもデータの可用性を確保します。クロスアカウントコピーは、バックアップを別のAWSアカウントに保存することで別の保護層を追加し、プライマリアカウントでの潜在的なセキュリティ侵害から隔離します。クロスリージョンとクロスアカウントコピーの設定方法については、この ブログ を参照してください。 パフォーマンスチューニング： 日常業務とバックアップの最適なパフォーマンスを実現するために、HANAデータベースEC2インスタンスとEBSボリュームを適切にサイズ設定することをお勧めします。SAP認定メモリ最適化EC2インスタンスについては、インスタンスタイプの最大帯域幅、最大スループット、最大IOPSの EBS仕様 を考慮してください。これは、SAP HANAデータとログの個別EBSボリュームをチューニングする際のEC2インスタンスの制限を理解するのに役立ちます。これは、バックアップを含むあらゆるワークロードのパフォーマンスに直接影響します。個別ボリュームとインスタンスレベルでの集約メトリクスのEBSメトリクスを測定するには、Amazon Elastic Block Store（Amazon EBS）のパフォーマンス問題を診断し、パフォーマンスメトリクスを計算してAmazon CloudWatchダッシュボードに公開する AWSSupport-CalculateEBSPerformanceMetrics ランブックを参照してください。 図-2：AWSSupport-CalculateEBSPerformanceMetricsランブック Amazon CloudWatchダッシュボード パフォーマンスと復旧時間目標を満たすように、SAP HANAとAWS Backint Agentに関連するこれらのパラメータを慎重に確認し調整してください。SAP HANAを微調整する構成パラメータは/hana/shared/$SID/global/hdb/custom/config/global.iniに、AWS Backint Agentについては/hana/shared/aws-backint-agent/aws-backint-agent-config.yamlに保存されています。これらのパラメータは、システムリソース（CPU、メモリ、ネットワーク容量）、データベースサイズとワークロード特性、バックアップウィンドウ要件、利用可能なネットワーク帯域幅に基づいて調整する必要があります。SAP HANAバックアップと復元のパフォーマンスチューニングの詳細については、 AWS Backint Agent for SAP HANAのインストールと構成 – パフォーマンスチューニング と AWS Backint Agent for SAP HANAのインストールと構成 – Backint関連SAP HANAパラメータ を参照してください。 SAP HANAバックアップと復元最適化のパラメータ構成 構成ファイル パラメータ 目的 設定 global.ini parallel_data_backup_backint_channels 並列バックアップチャネル数を制御 8（システムリソースに基づいて調整） global.ini data_backup_buffer_size バックアップ操作のバッファサイズを設定 1024（利用可能メモリに基づいて調整） aws-backint-agent-config.yaml UploadChannelSize アップロードチャンクのサイズを制御 256MB（必要に応じて調整） aws-backint-agent-config.yaml UploadConcurrency 同時アップロードストリーム数 8（必要に応じて調整） aws-backint-agent-config.yaml MaximumConcurrentFilesForRestore 並列復元操作を制御 5（システムリソースに基づいて調整） aws-backint-agent-config.yaml DownloadConcurrency 同時ダウンロードストリーム数 10（システムリソースに基づいて調整） 監視： AWS Backupダッシュボードは、AWSサービス全体のバックアップアクティビティを一元化します。ジョブステータスを追跡し、コンプライアンスを監視し、保護されたリソースを表示します。ダッシュボードは問題を特定し、ポリシー遵守を監視し、運用を管理します。AWS BackupはAmazon CloudWatchとメトリクスとイベントで統合し、バックアップと復元ジョブのステータスを追跡し、障害に対するアラームを設定できます。 図-3：AWS Backup for SAP HANAバックアップ、復元、コピージョブを監視するAmazon CloudWatchダッシュボード エラーのトラブルシューティング： Amazon EC2上でAWS Backup for SAP HANAを構成する際は、以下のログファイルとこれらのファイルの目的に注意してください。 アクティビティ 関連ログ 発見と登録 /usr/bin/ssm-sap/logs/discovery.log AWS Backint Agent for SAP HANAのインストール /var/lib/amazon/ssm/packages/AWSSAP-Backint/*/aws-backint-agent-install-*.log AWS Backint Agentのバックアップと復元ログ /hana/shared/aws-backint-agent/aws-backint-agent.log システムとテナントデータベースのSAP HANAログ システムDBバックアップと復旧ログ： /usr/sap/&lt;SID&gt;/&lt;SID&gt;&lt;instance&gt;/&lt;hostname&gt;/trace/backup.log /usr/sap/&lt;SID&gt;/&lt;SID&gt;&lt;instance&gt;/&lt;hostname&gt;/trace/backint.log テナントDBバックアップと復旧ログ： /usr/sap/&lt;SID&gt;/&lt;SID&gt;&lt;instance&gt;/&lt;hostname&gt;/trace/DB_&lt;SID&gt;/backup.log /usr/sap/&lt;SID&gt;/&lt;SID&gt;&lt;instance&gt;/&lt;hostname&gt;/trace/DB_&lt;SID&gt;/backint.log SAP HANAバックアップのハウスキーピング活動： SAPノートは、バックアップカタログのハウスキーピング活動を維持し、SAP HANA Out Of Memory（OOM）エラーを回避するための大きなバックアップカタログサイズの解決手順をまとめています。SAP HANAバックアップのSAP BASISハウスキーピング活動の詳細については、SAPノート： 3411878 をお読みください。 AWS Backint Agentバージョンの最新情報： Amazon Simple Notification Service（Amazon SNS）は、AWS BackintエージェントまたはAWS Backintインストーラーの新しいバージョンがリリースされたときに通知できます。詳細については、 AWS Backint Agent for SAP HANAのインストールと構成 – 最新バージョンへの更新または以前のバージョンのAWS Backintエージェントのインストール をご覧ください。 SAP HANAデータベースとオペレーティングシステムバージョンの最新情報： SAPノートは、SAP HANAデータベースバージョンとサポートされているオペレーティングシステムのリストをまとめています。詳細については、SAPノート： 2235581 をお読みください。 まとめ このブログでは、SAP HANA HAデプロイでAWS Backupを実装するための戦略とベストプラクティスについて概説しました。スケジュールされたバックアップ、→HA 展開の簡素化された復旧、DR とランサムウェア保護のためのクロスリージョン・クロスアカウントコピー、Audit Manager によるコンプライアンス遵守、ジョブと復旧ポイントを監視するCloudWatch メトリクスなどのフルマネージド機能について説明しました。ライフサイクルポリシーと保持期間の見直しによるコスト最適化についても取り上げました。進化するビジネスニーズに基づく定期的な戦略見直し、監査、改良の重要性が強調されました。これらのプラクティスにより、SAP HANA HAデプロイのための堅牢で効率的かつコンプライアントなAWS Backup戦略が確立され、データ保護と運用レジリエンスが強化されます。 AWS Backupサービスを開始するために、以下のドキュメント、ブログ、ワークショップを確認することをお勧めします。 Amazon EC2インスタンス上のSAP HANAデータベースバックアップ AWS BackupでSAP HANAバックアップを自動化し簡素化する AWSサービスでSAPバックアップを簡素化する AWS Backup for SAPを使用したSAP HANAデータベースのクロスリージョン・クロスアカウントバックアップと復元の実行 AWS Backup for SAP HANA高可用性 何千ものお客様がSAPワークロードの移行、モダナイゼーション、イノベーションでAWSを信頼する理由については、 SAP on AWS ページをご覧ください。 謝辞 以下のチームメンバーの貢献に感謝いたします：Nerys Olver、Dhrumin Shah、Adam Hill、Spencer Martenson、David Rocha、Adam Kaminski、Balaji Krishna。 本ブログはパートナー SA 松本が翻訳しました。原文は こちら です。 <!-- '"` -->

画期的なパフォーマンスとスケーラビリティを備えた 第 2 世代 AWS Outposts ラック を 4 月に発表してからも、AWS はクラウドのエッジでお客様のために革新し続けてきました。9 月 30 日、 AWS Outposts サードパーティー統合プログラムが拡大され、既存の NetApp オンプレミスエンタープライズストレージアレイ や Pure Storage FlashArray との統合リストに、 Dell PowerStore システムと HPE Alletra Storage MP B10000 &nbsp;システムが仲間入りしました。このプログラムは、お客様が AWS ネイティブツールを使用して、AWS Outposts をサードパーティーストレージアレイで簡単に使用できるようにします。ソリューションの統合は、VMware ワークロードを AWS に移行しており、移行中に既存のストレージインフラストラクチャを維持する必要がある組織や、AWS サービスの使用中もデータをオンプレミスに維持することで、厳しいデータレジデンシー要件を満たす必要がある組織にとって特に重要です。 この発表は、AWS が過去 1 年の間に達成した 2 つの重要なストレージ統合マイルストーンを基盤とするものです。2024 年 12 月、AWS マネジメントコンソール経由で Outposts 上の Amazon EC2 インスタンスに サードパーティーストレージアレイからのブロックデータボリュームを直接アタッチする機能 を導入しました。2025 年 7 月には、これらの外部ストレージアレイから直接 Amazon EC2 インスタンスを起動 できるようにしました。今回 Dell と HPE が追加されたことにより、オンプレミスストレージ投資の AWS Outposts との統合方法におけるお客様の選択肢がますます広がりました。 強化されたストレージ統合機能 AWS のサードパーティーストレージ統合は、データボリュームとブートボリュームの両方をサポートし、iSCSI SanBoot と Localboot の 2 つの起動方法を提供します。iSCSI SANBoot オプションは読み取り専用ブートボリュームと読み取り/書き込みブートボリュームの両方を有効にし、Localboot オプションは iSCSI プロトコルか NVMe-over-TCP プロトコルのいずれかを使用する読み取り専用ブートボリュームをサポートします。この包括的なアプローチにより、お客様は、Outposts が提供する一貫的なハイブリッドエクスペリエンスを維持しながら、ストレージリソースを一元的に管理できます。 お客様は、AWS マネジメントコンソールにある Amazon EC2 インスタンス起動ウィザードを使用して、任意のサポート対象パートナーが提供する外部ストレージを使用するようにインスタンスを設定できます。ブートボリュームについては、 Windows Server 2022 と Red Hat Enterprise Linux 9 向けの AWS 検証済み AMI が提供されており、 AWS Samples からセットアッププロセスを簡素化するための自動化スクリプトを入手できます。 さまざまな Outposts 構成のサポート Outposts 2U サーバーと両世代の Outposts ラックでは、サードパーティーストレージ統合特徴量のすべてがサポートされています。第 2 世代 Outposts ラックのサポートは、お客様が Outposts 上の最新 EC2 インスタンスの強化されたパフォーマンス (2 倍の vCPU、メモリ、ネットワーク帯域幅など) を、希望するストレージソリューションと組み合わせて活用できることを意味します。統合は、簡素化された新しいネットワークスケーリング機能と、超低レイテンシーで高スループットのワークロード向けに設計された専用の Amazon EC2 インスタンスの両方とシームレスに連動します。 知っておくべきこと お客様は、既存の Outposts デプロイで、または AWS マネジメントコンソール から新しい Outposts を注文することで、これらの機能の使用を今すぐ開始できます。Outposts サーバーとのサードパーティーストレージ統合を使用している場合は、オンサイト担当者またはサードパーティー IT プロバイダーにサーバーの取り付けを依頼できます。Outposts サーバーがネットワークに接続されたら、AWS がコンピューティングリソースとストレージリソースをリモートでプロビジョニングして、アプリケーションの起動を開始できるようにします。Outposts ラックのデプロイプロセスには、ラックを取り付けてアクティブ化する前に AWS 技術者がサイトの状態とネットワーク接続を確認するセットアップ作業が含まれます。サードパーティーストレージコンポーネントの実装は、ストレージパートナーが援助します。 互換性のあるすべてのストレージベンダーとの Outposts サードパーティーストレージ統合は、Outposts がサポートされているすべての AWS リージョンで利用でき、追加の料金はかかりません。サポートされているリージョンの最新リストについては、 Outposts サーバー と Outposts ラック のよくある質問を参照してください。 Outposts サードパーティーストレージ統合プログラムの今回の拡大は、エンタープライズグレードの柔軟なハイブリッドクラウドソリューションを提供し、クラウド移行ジャーニーの進捗状況に合わせてお客様に対応するという AWS の継続的な取り組みを実証するものです。この機能とサポートされるストレージベンダーの詳細については、 AWS Outposts のパートナーページ と、 Outposts サーバー 、 第 2 世代 Outposts ラック 、 第 1 世代 Outposts ラック のテクニカルドキュメントをご覧ください。 パートナーソリューションの詳細については、 Dell PowerStore の AWS Outposts との統合 と、 HPE Alletra Storage MP B10000 の AWS Outposts との統合 をお読みください。 原文は こちら です。

みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。最近すっかり涼しくなり、私の周りには体調を崩される方が多くなってきました。みなさま働きすぎと体調管理にお気を付けください。ちなみに私はいつも元気です。 さて、月替わりしまして10月の builders.flash から生成AI関連の記事が出ていますのでピックアップしてみました。週刊生成AIの情報と併せて是非ご参照くださいませ。 Amazon Bedrock ガードレールでゲーム内のキャラクターを彩ろう！ 「それ、AI にやらせてみよう」Claude Code Action 活用テクニック with Amazon Bedrock AWS Transform for mainframe と GenU で COBOL プログラム説明書を作ってみよう Amazon Novaを使った特許分析システムの処理コスト最適化 ~ パテント・リザルトの生成 AI 実装解説 生成 AI x RAG x サーバーレスで実現！ AWS AppSync Events と Amazon Bedrock Knowledge Bases で作るライブチャットモデレーション Cline with Amazon Bedrock で始める Vibe Coding ~ テックアカデミーにおける活用事例 AI エージェントで開発効率を加速しよう！Bedrock Engineer を触って学ぶ AI エージェント活用術 利用率 100% 達成 ! Amazon Bedrock を活用した生成 AI の開発組織への導入 そして毎回お知らせしておりますが「 AWS ジャパン生成 AI 実用化推進プログラム 」も非常に引き続き募集中ですのでよろしくお願いします。 では今週も生成 AI with AWS界隈のニュースを見ていきましょう！ さまざまなニュース AWS生成AI国内事例ブログ「株式会社ケアネット様の AWS 生成 AI 事例「医師向け情報サービスにおける大規模 AI ライティングシステムの実装」のご紹介」 このブログでは医師向け情報サービスを提供する株式会社ケアネット様が、Amazon Bedrock を活用して医学文献から記事を自動生成する大規模AIライティングシステムを構築した事例を紹介しています。年間150万件以上発表される医学文献の中から、従来は人力で1日約10件しか提供できなかった記事を、生成AIを活用することで最大5,000件まで飛躍的に増加させ、24万人の医師会員に個別最適化された情報配信を実現しました。Amazon Bedrockのクロスリージョン推論機能により大量のリクエストを並列処理し、セキュアなインフラ内で医療情報という機密性の高いデータを安全に扱いながら、高い継続率60%超という成果を達成しています。Amazon Bedrockを活用する際のアーキテクチャ設計、スケーラビリティの確保、セキュリティ対策の参考になる内容となっています。 AWS生成AI国内事例ブログ「AWS Summit Japan 2025 AI健康アプリ「HugWay」を支えるAWSアーキテクチャ：テオリア・テクノロジーズの認知症プラットフォーム戦略」 AWS Summit Japan 2025で展示されたテオリア・テクノロジーズのAI健康アプリ「HugWay」は、認知症予防をサポートする新しい健康管理アプリケーションです。このブログでは、AIパートナー「ハグまる」がユーザーに寄り添った会話を実現する仕組みや、会話履歴を分析・要約して長期的なパーソナライゼーションを提供する技術が紹介されています。マイクロサービス設計により機能拡張がしやすく、トラフィックの変動にも柔軟に対応できる実践的なアーキテクチャは、生成AIアプリケーションを開発する方にとって参考になると思います。また、OpenTelemetryを採用したオブザーバビリティ基盤の構築手法も解説されており、生成AIの安全性検証や品質管理のアプローチについてヒントを得ることができます。 サービスアップデート Anthropic Claude Sonnet 4.5 が Amazon Bedrock で提供開始 Amazon Bedrock でAnthropicの最も高性能なモデルであるClaude Sonnet 4.5が利用可能になりました。このモデルは、SWE-bench Verifiedベンチマークで高い性能を誇り、複雑なエージェント処理、コーディング、長期にわたるタスクに優れた能力を発揮しながら、大量利用時のスピードとコスト効率も最適化されています。マルチチャネルマーケティングキャンペーンの自律的な管理、クロスファンクショナルなエンタープライズワークフローの調整、サイバーセキュリティにおける脆弱性の自動パッチ適用、金融サービスでの高度な予測モデリングなど、複雑なマルチステップタスクを高精度で処理できます。Amazon Bedrock API 経由で、過去のツール呼び出しからの古い情報を自動的にクリアするコンテキスト編集機能と、コンテキストウィンドウ外に情報を保存・参照できる新しいメモリツールが利用可能となり、生成AIエージェントの精度とパフォーマンスが向上します。クロスリージョン推論により複数のロケーションで利用できます。またCross-Region Inference Profile に日本が追加され、日本国内（ap-northeast-1 と ap-northeast-3）でのクロスリージョン推論が可能となりました。 AWS API MCP Server v1.0.0 がリリース AWS API Model Context Protocol（MCP）Server のv1.0.0がリリースされました。このサーバーは、自然言語でAWS APIと対話し、文法的に正しいCLIコマンドを生成・実行できる機能を提供します。今回のリリースでは、起動時間の短縮、セキュリティ強化、CloudWatchエージェントによるログ収集対応、HTTP transportのサポート追加などの機能強化が実装されました。オープンソースとして GitHub で公開され、 Amazon ECR Public Gallery からコンテナイメージとしても利用可能です。 AWS Knowledge MCPサーバーが一般提供開始 AWS Knowledge Model Context Protocol（MCP）Server の一般提供が開始されました。このサーバーは、AWSのドキュメント、ブログ投稿、What’s New、ベストプラクティスなどの情報を、LLM互換フォーマットでAIエージェントやMCPクライアントに提供します。今回のリリースでは、AWS API のリージョンごとの可用性や CloudFormation リソースの情報も含まれており、より実用的な情報のアクセスが可能になりました。AWSアカウント不要で無料利用でき、グローバルに提供されています。 Open Source Model Context Protocol (MCP) Server now available for Amazon Bedrock AgentCore Amazon Bedrock AgentCore 向けに、オープンソースのModel Context Protocol（MCP）サーバーが提供開始され、開発者が好みの開発環境で本格的なAIエージェントを分析・変換・デプロイできる標準化されたインターフェースが利用可能になりました。Kiro、Claude Code、Cursor、Amazon Q Developer CLI などの統合IDEやAIコーディングアシスタントとワンクリックインストールで統合でき、自然言語を使ってエージェントロジックを反復開発し、AgentCore SDKに変換して開発アカウントにデプロイすることが可能です。AgentCore MCP Serverについてのドキュメントやインストール方法は、 GitHubリポジトリ をご覧ください。また、詳しい情報はこちらの ブログ にも掲載しています。 Amazon Bedrock Data Automationが文字起こし機能を強化 Amazon Bedrock Data Automation で、音声ファイルの文字起こし出力が強化され、スピーカーダイアライゼーション（話者識別）とチャネル識別がサポートされるようになりました。スピーカーダイアライゼーションは複数人が参加する会議や通話で各話者を自動的に検出・追跡し、チャネル識別では顧客と営業担当者など、各チャネルの音声を個別に処理できます。米国西部（オレゴン）、米国東部（バージニア北部）、GovCloud（米国西部）、欧州（フランクフルト）、欧州（ロンドン）、欧州（アイルランド）、アジアパシフィック（ムンバイ）、アジアパシフィック（シドニー）で利用可能です。 Cohere Embed v4 マルチモーダル埋め込みモデルが Amazon Bedrock で提供開始 Amazon Bedrock でCohereの最新マルチモーダル埋め込みモデルEmbed v4が利用可能になりました。このモデルは、テキストだけでなく、表やグラフ、図、コードスニペット、手書きメモを含む複雑なビジネスドキュメントをネイティブに処理できる点が大きな特徴です。従来のモデルでは必要だった大規模なデータ前処理パイプラインが不要となり、スペルミスやフォーマットの問題も自動的に処理するため、時間のかかるデータクリーンアップ作業から解放されます。100以上の言語をサポートし、金融、医療、製造などの業界特有の文書に対してもファインチューニングされているため、グローバルな企業が専門的なドキュメントから洞察を引き出す際に優れた性能を発揮します。生成AIアプリケーションにおいては、複雑なビジネス資料を含むRAGシステムの構築や、多言語対応の高度な検索・情報取得機能の実装が、これまで以上に容易かつ高精度に実現できます。米国東部（バージニア北部）、欧州（アイルランド）、アジアパシフィック（東京）で利用可能です。また、特定のAWSリージョンからクロスリージョン推論を通じてアクセスすることができます。詳細は こちらのドキュメント をご参照ください。 Amazon Neptune DatabaseがGraphStormと統合し、スケーラブルなグラフ機械学習を実現 Amazon Neptune Database が、エンタープライズ向けのオープンソースグラフ機械学習ライブラリであるGraphStormと統合されました。この統合により、GraphStormでグラフニューラルネットワーク（GNN）モデルをトレーニングし、Neptune上のグラフデータに対してリアルタイムで推論を実行できるようになります。ノード分類やリンク予測などの予測結果を1秒未満で取得できるため、アカウント、デバイス、トランザクション間の複雑な関係性をリアルタイムに分析する不正検知や、ユーザー行動に即座に適応する動的レコメンデーション、継続的に更新されるリスクスコアリングなどのユースケースが実現可能です。Amazon Neptune Database が利用可能な全リージョンで提供されています。 Amazon OpenSearch Ingestion がバッチAI推論をサポート開始 Amazon OpenSearch Ingestion パイプラインで、バッチAI推論機能が利用できるようになりました。これまで Amazon Bedrock やAmazon SageMaker などとのコネクターを使ったリアルタイム推論は可能でしたが、今回のアップデートにより、大規模データセットをオフラインで効率的に処理できる非同期バッチ推論が追加されました。この機能により、ベクトル埋め込みの生成や取り込みといった大量データの処理が、より高いパフォーマンスとコスト効率で実現できます。Amazon OpenSearch Ingestion 対応の全リージョンおよびバージョン2.17以降のドメインで利用可能です。詳細は こちらのドキュメント をご参照ください。 Amazon SageMaker managed MLflow が AWS GovCloud（米国）リージョンでの提供を開始 Amazon SageMaker managed MLflow が AWS GovCloud（米国西部）および AWS GovCloud（米国東部）の両リージョンで利用可能になりました。政府機関や厳格なセキュリティ要件を持つ組織にとって、GovCloudでの提供により高いセキュリティ基準を満たしながら生成AI開発を推進できる重要な選択肢となります。 Amazon Bedrock がアジアパシフィック（タイ、マレーシア、台北）リージョンでの提供を開始 Amazon Bedrock が新たにアジアパシフィック（タイ、マレーシア、台北）リージョンで利用可能になりました。これにより、タイ、マレーシア、台北それぞれの現地でデータを保持しながら、多様な基盤モデルと包括的なツール群を活用した生成AIアプリケーションの開発・運用が実現できます。詳細は こちらのドキュメント をご参照ください。 Amazon Bedrock が中東（UAE）リージョンでの提供を開始 Amazon Bedrock が新たに中東（UAE）リージョンで利用可能になりました。これにより、UAE現地でデータを保持しながら、多様な基盤モデルと包括的なツール群を活用した生成AIアプリケーションの開発・運用が実現できます。詳細は こちらのドキュメント をご参照ください。 Amazon Bedrock がイスラエル（テルアビブ）リージョンでの提供を開始 Amazon Bedrock が新たにイスラエル（テルアビブ）リージョンで利用可能になりました。これにより、イスラエル現地でデータを保持しながら、多様な基盤モデルと包括的なツール群を活用した生成AIアプリケーションの開発・運用が実現できます。詳細は こちらのドキュメント をご参照ください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近、ハーブを育てるのにハマっています。

9 月 29 日、Anthropic を搭載した Claude Sonnet 4.5 が Amazon Bedrock で利用可能になったことを発表できることを嬉しく思います。Amazon Bedrock は、主要な AI 企業が提供する高性能な基盤モデルの選択を提供するフルマネージドサービスです。この新しいモデルは、Claude 4 の基盤に基づいて構築されており、コーディングや複雑なエージェントアプリケーションにおいて最先端のパフォーマンスを実現しています。 Claude Sonnet 4.5 は、ツール処理、メモリ管理、およびコンテキスト処理でのパフォーマンスが強化されたことで、エージェント機能が向上したことを示しています。このモデルでは、最適な改善点の特定から、リファクタリングの決定におけるより強力な判断の実施まで、コード生成と解析において著しい改善が見られます。特に、開発サイクル全体を通じて一貫したパフォーマンスと信頼性を維持しながら、複雑なソフトウェアプロジェクトを数時間または数日にわたって効果的に計画および実行できる、自律的で長期的なコーディングタスクに優れています。 ソース: https://www.anthropic.com/news/claude-sonnet-4-5 Amazon Bedrock で Claude Sonnet 4.5 を使用することで、デベロッパーはフルマネージドサービスにアクセスできるようになります。このサービスでは、基盤モデル用の統合 API を提供するだけでなく、セキュリティと最適化のためのエンタープライズグレードのツールでデータを完全に制御できます。 また、Claude Sonnet 4.5 は Amazon Bedrock AgentCore とシームレスに統合されているため、デベロッパーは複雑なエージェントを構築する際にモデルの機能を最大限に活用できます。AgentCore の専用インフラストラクチャは、ツール処理、メモリ管理、およびコンテキスト理解におけるモデルの強化された機能を補完します。デベロッパーは、完全なセッション分離、8 時間の長期サポート、および包括的なオブザーバビリティ特徴量を活用して、自律的なセキュリティ運用から複雑なエンタープライズワークフローまで、本番環境に対応したエージェントをデプロイおよび監視できます。 ビジネスアプリケーションとユースケース Sonnet 4.5 は、その技術的機能だけでなく、一貫したパフォーマンスと高度な問題解決能力を通じて、実用的なビジネス価値をもたらします。このモデルは、複雑なワークフロー全体で信頼性の高いパフォーマンスを維持しながら、ビジネス文書の作成と編集に優れています。 このモデルは、いくつかの主要産業における強みを示しています: サイバーセキュリティ – Claude Sonnet 4.5 を使用すると、脆弱性が悪用される前に自律的にパッチを適用するエージェントをデプロイし、事後対応型の検出から事前対応型の防御へと移行できます。 財務 – Sonnet 4.5 は、エントリーレベルの財務分析から高度な予測分析まですべてを処理し、手作業による監査準備をインテリジェントなリスク管理に変換するのに役立ちます。 リサーチ – Sonnet 4.5 は、ツールやコンテキストをより適切に処理し、すぐに使えるオフィスファイルを提供できるため、専門家が分析して最終的な成果物や実用的な洞察を得ることができます。 Amazon Bedrock API の Sonnet 4.5 機能 Amazon Bedrock API での Sonnet 4.5 のハイライトは次のとおりです: スマートコンテキストウィンドウ管理 – 新しい API は、AI モデルが最大容量に達したときにインテリジェントな処理を導入します。Claude Sonnet 4.5 では、会話が長すぎたときにエラーを返す代わりに、利用可能な上限までの応答を生成し、停止した理由を明確に示すようになりました。これにより、イライラするような中断がなくなり、ユーザーは利用可能なコンテキストウィンドウを最大限に活用できます。 効率化のためのツール使用量のクリア – Claude Sonnet 4.5 では、長時間の会話中でもツールのインタラクション履歴を自動的にクリーンアップできます。会話に複数のツールコールが含まれる場合、システムは最新のツール結果を保存しながら、古いツール結果を自動的に削除できます。これにより、会話を効率的に保ち、不要なトークンの消費を防ぎ、会話の質を維持しながらコストを削減できます。 クロスカンバセーションメモリ – 新しいメモリ機能により、Sonnet 4.5 はローカルメモリファイルを使用してさまざまな会話の情報を記憶できます。ユーザーは、好み、コンテキスト、または 1 回のチャットセッションを超えて残る重要な情報をモデルに明示的に記憶するように依頼できます。これにより、ローカルファイル内の情報を安全に保ちながら、よりパーソナライズされたコンテキスト認識型のインタラクションが可能になります。 コンテキストを管理するためのこれらの新機能により、デベロッパーは、コンテキストの制限に達したり、重要な情報を頻繁に失ったりすることなく、長時間実行されるタスクをより高いインテリジェンスで処理できる AI エージェントを構築できます。 開始方法 Claude Sonnet 4.5 の使用を開始するには、正しいモデル ID を使用して Amazon Bedrock からアクセスできます。 Amazon Bedrock Converse API を使用してコードを一度記述し、さまざまなモデルをシームレスに切り替えることが優れたプラクティスです。これにより、Sonnet 4.5 や Amazon Bedrock で利用できる他のモデルを簡単に試すことができます。 これを簡単な例で実際に見てみましょう。Amazon Bedrock Converse API を使用して、Sonnet 4.5 にプロンプトを送信します。まず、これから使用するモジュールをインポートします。この短い例では、BedrockRuntimeClient を作成できるように、 AWS SDK for Python (Boto3) のみが必要です。後で出力をうまくフォーマットできるように、リッチパッケージもインポートしています。 ベストプラクティスに従って、boto3 セッションを作成し、Amazon Bedrock クライアントを、直接作成するのではなく、そこから作成します。これにより、構成を明示的に制御でき、スレッドの安全性が向上し、デフォルトのセッションに依存する場合に比べてコードの予測とテストが容易になります。 Sonnet 4.5 のパワーを実証するために単純な質問をするのではなく、少し複雑なものをモデルに与えたいと思います。そこで、単一のデータベースを使用して Java で記述された架空のレガシーモノリシックアプリケーションの現在の状態をこのモデルに与えて、移行戦略、リスク評価、推定タイムライン、主要なマイルストーン、および具体的な AWS サービスの推奨事項を含むデジタルトランスフォーメーション計画を求めます。 プロンプトがかなり長いので、ローカルのテキストファイルに入れて、コードでロードするだけです。次に、ロールを「user」に設定して Amazon Bedrock コンバースペイロードをセットアップし、これがアプリケーションのユーザーによるメッセージであることを示し、コンテンツにプロンプトを追加します。 ここで魔法が起こります! すべてをまとめて、モデル ID を使用して Claude Sonnet 4.5 を呼び出します。こんな感じですね。Sonnet 4.5 には、推論プロファイルからのみアクセスできます。これにより、モデルリクエストを処理する AWS リージョンが定義され、スループットとパフォーマンスの管理に役立ちます。 このデモでは、Amazon Bedrock のシステム定義のクロスリージョン推論プロファイルの 1 つを使用しています。これにより、リクエストが自動的に複数のリージョンにルーティングされ、最適なパフォーマンスが得られます。 あとは、画面にプリントして結果を確認するだけです。ここでは、先ほどインポートした豊富なパッケージを使用するので、これに対して長い応答が予想されるため、適切な形式の出力が得られる可能性があります。また、出力をファイルに保存して、チームと簡単に共有できるようにしています。 オーケー、結果を確認しましょう! 予想通り、Sonnet 4.5 は私の要求を満たし、私が実行に移せるデジタルトランスフォーメーション計画のための広範囲かつ詳細なガイダンスを提供してくれました。その内容には、エグゼクティブサマリー、時間の見積もりがある段階的な移行戦略のほか、開発プロセスを開始してマイクロサービスに分解し始めるためのコードサンプルも含まれていました。また、テクノロジーを導入するためのビジネスケースを示し、各シナリオに適した AWS サービスを推奨しました。レポートのハイライトをいくつかご紹介します。 Claude Sonnet 4.5 は、一貫性を保ちながら創造的なソリューションを提供できるため、複雑な問題解決や開発タスクに AI を使用したい企業にとって理想的な選択肢です。指示に従い、ツールを使用するという強化された機能が、さまざまなビジネス環境においてより信頼性が高く革新的なソリューションに効果的に反映されます。 知っておくべきこと Claude Sonnet 4.5 は、エージェント機能において大きな進歩を遂げており、一貫したパフォーマンスと創造的な問題解決が不可欠な分野では特に優れています。ツール処理、メモリ管理、およびコンテキスト処理における強化された機能により、金融、研究、サイバーセキュリティなどの主要業界で特に価値があります。Claude Sonnet 4.5 は、複雑な開発ライフサイクルの処理、長期にわたるタスクの実行、ビジネスクリティカルなワークフローへの取り組みのいずれにおいても、卓越した技術と実践的なビジネス価値を兼ね備えています。 Claude Sonnet 4.5 が本日発売されました。 提供状況の詳細 については、ドキュメントをご覧ください。 Amazon Bedrock の詳細については、自分のペースで進められる Amazon Bedrock Workshop をご覧ください。また、利用可能なモデルとその機能をアプリケーションで使用する方法をご覧ください。 原文は こちら です。

みなさん、こんにちは。ソリューションアーキテクトの根本です。 今週も 週刊AWS をお届けします。 今週で4月期初の企業は上期が終わり、内定式や異動など多い季節でしょうか。 まだ暑い日も多く寒暖差激しいので、みなさん体調お気をつけください。 AWSが直接開催するイベントではないですが、今週末の10/11(土)はいよいよJAWS FESTA 2025 in 金沢ですね。 キャンセル待ち等もあるようですが、興味ある方はぜひ確認してみてください！ – JAWS FESTA 2025 in 金沢 https://jawsfesta2025.jaws-ug.jp/ それでは、先週の主なアップデートについて振り返っていきましょう。 2025年9月29日週の主要なアップデート 9/29(月) Anthropic’s Claude Sonnet 4.5 is now in Amazon Bedrock Amazon Bedrock で Anthropic の最新モデル Claude Sonnet 4.5 が利用可能になりました。このモデルは現在 SWE-bench Verified ベンチマークでトップの成績を収めており、コーディングや複雑なエージェント処理に優れ、マルチチャネルマーケティングキャンペーンの自動管理やサイバーセキュリティの脆弱性パッチ適用など、多段階タスクを高精度で実行できます。新たにメモリツール機能も追加され、コンテキストウィンドウ外の情報を保存・参照して、精度とパフォーマンスを向上させることも可能になっています。利用可能なリージョンに関しては ドキュメント 、詳細は Blog もご確認ください。 Amazon ECS announces IPv6-only support Amazon ECS で IPv6-only サブネットでのタスク実行がサポートされました。従来は IPv4 アドレスが必須だったため、大規模にコンテナを展開するアプリケーション環境では IPv4 アドレス不足がボトルネックになることがありました。今回のアップデートによりIPv4を必要とせず、IPv6 のみでの運用が可能になりスケーラビリティの制約が解消されます。詳細についてはこちらの Blog をご確認ください。 9/30(火) Announcing Amazon ECS Managed Instances Amazon ECS Managed Instances が発表されました。このサービスはECSにおいて EC2を利用時に、EC2のインフラストラクチャ管理をAWSに任せつつ、全機能へのアクセスを提供するよう設計された、新しいフルマネージドのオプションです。従来からECSではデータプレーンとしてFargateも選択可能ですが一定の環境制約が存在します。一方、EC2を利用時はスケーリングを含むEC2の管理を自分でする必要がありました。今回の機能により vCPU 数やメモリサイズを指定するだけで最適なEC2インスタンスが自動でプロビジョニングされ、動的スケーリングや、14 日ごとのセキュリティパッチも AWS に任せることが可能になります。この機能は東京リージョンを含む 6 つのリージョンで利用可能です。詳細は ドキュメント や Blog をご確認ください。 AWS Transfer Family now supports VPC endpoint policies and FIPS VPC endpoints AWS Transfer Family で VPC エンドポイントポリシーと FIPS 対応 VPC エンドポイントがサポートされました。これまで、VPC エンドポイント経由で Transfer Family API にアクセスする際はAPIの細かい制御ができませんでしたが、今回のVPCエンドポイントポリシーサポートにより CreateServer や DeleteServer など、 詳細なAPI 操作制御ができるようになりました。これにより企業のセキュリティポリシーに応じてアクセス権限を適切に管理でき、データ保護とセキュリティ体制が大幅に向上します。この機能はAWS Transfer Familyの各サービスが利用可能なすべてのAWS リージョンで利用可能です。詳細は ドキュメント をご確認ください。 AWS Transform now enables Terraform for VMware network automation AWS Transform for VMware が VMware 環境からネットワーク構成のIaCを自動生成する選択肢として、これまでのCloudFormation と CDKに加えてTerraform サポートしました。VMware 環境からクラウドへの移行時、既存の Terraform ベースのデプロイメントパイプラインをそのまま活用できるため、移行作業の効率が大幅に向上します。この機能はAWS Transformが提供されるすべてのAWS リージョンで利用可能です。詳細は ドキュメント をご確認ください。 Amazon CloudWatch and OpenSearch Service expand region support for integrated analytics experience Amazon CloudWatch と Amazon OpenSearch Service が統合分析エクスペリエンスが、大阪を含む5つのリージョンで新たに利用可能になりました。このアップデートは従来、OpenSearch Service でのCloudWatchのログ分析にはストレージへのコピーや ETL パイプラインが必要だったのを不要にする他、CloudWatch Logs のログ分析にCloudWatch Logs Insights QLだけではなく SQL や OpenSearch PPL が使えるようにするものです。これらにより作業効率が大幅に向上します。詳細については ドキュメント をご確認ください。 10/1(水) AWS API MCP Server v1.0.0 release AWS API MCP Server v1.0.0 がリリースされました。このサーバーを使うことで、FMモデルを活用し自然言語で AWS API を操作できるようになります。v1.0.0 リリースにあたっては起動時間を短縮、セキュリティの強化、既存の stdio に加えてストリーミング可能な HTTP トランスポートのサポートなどの機能追加がされています。また、一般的な AWS タスクの規範的なワークフローを提供する get_execution_plan という新しいツールも追加されています。利用開始方法と機能の詳細については GitHub リポジトリ &nbsp;をご確認ください。 Application map is now generally available for Amazon CloudWatch Amazon CloudWatch でApplication mapがGAしました。Application mapはアプリケーションパフォーマンス監視 (APM) 機能で、設定や関係性に基づいて関連サービスを自動的に検出しグループに整理するものです。これにより大規模な分散アプリケーションの監視で問題となる、サービス間の依存関係を把握を容易にしてくれます。関係性の可視化が容易になることで、障害時の影響範囲を素早く特定でき、平均復旧時間 (MTTR) の短縮が期待できます。この機能は全ての商用リージョン利用可能です。詳細は ドキュメント をご確認ください。 AWS Knowledge MCP Server now generally available AWS Knowledge MCP Server がGAしました。これは AI エージェントや MCP クライアントが AWS の公式ドキュメント、ブログ記事、Well-Architected のベストプラクティスなどの情報に LLM 互換フォーマットでアクセスできるサービスです。従来は手動で AWS の情報を収集・管理する必要がありましたが、このサーバーにより AI が、信頼できる AWS 情報を基にした正確で一貫性のある回答を提供できるようになります。この機能はAWS アカウント不要で無料で利用可能です。利用に当たっては 利用ガイド をご確認ください。 Announcing Apache Airflow 3.0 support in Amazon Managed Workflows for Apache Airflow Amazon MWAA で Apache Airflow 3.0 がサポートされました。Apache Airflow 3.0&nbsp;では新しい UI でワークフロー管理がより直感的になり、外部イベントに基づく自動実行機能により従来の定期実行だけでなくリアルタイムなデータ処理が可能になります。また、Task SDK の導入でコード記述が簡単になり、Python 3.12 対応やセキュリティ強化も実現されています。Apache Airflow 3.0の詳細は 変更ログ を、Amazon MWAAについては ドキュメント をそれぞれご確認ください。 10/2(木) Amazon ECS now supports one-click event capture and event history querying in the AWS Management Console Amazon ECS がAWS Management Console で直接イベント取得とイベント履歴クエリを利用可能になりました。従来はタスクの停止理由やサービスのイベント履歴を確認するのにCloudWatch Logsなど複数のサービスのコンソールを行き来する必要がありました。今回のアップデートによりこれが不要になり、ECS コンソール内で完結したトラブルシューティングが可能になります。この機能はすべてのリージョンで利用可能です。詳細は ドキュメント をご確認ください。 Amazon Neptune Database now integrates with GraphStorm for scalable graph machine learning Amazon Neptune Database が GraphStorm と統合されました。Neptune はグラフデータベースで、GraphStorm は、エンタープライズ規模のアプリケーション向けに構築された、スケーラブルなオープンソースのグラフ機械学習 (ML) ライブラリです。この統合により、詐欺検出や動的レコメンド、リスクスコアリングなどレイテンシに敏感なトランザクション環境でグラフMLの推論が可能になりました。この機能は、Amazon Neptune Database が利用可能なすべてのリージョンで利用可能です。詳細はこちらの Blog をご確認ください。 Amazon Bedrock AgentCore 向けオープンソース Model Context Protocol (MCP) サーバーが利用可能に Amazon Bedrock AgentCore のためのオープンソースModel Context Protocol (MCP) Serverが利用可能になりました。このインターフェースにより、好みの開発環境で直接AIエージェントの分析、変換、デプロイが可能になります。KiroやClaude Code、Cursor、Amazon Q Developer CLIなどのAgentic IDEとワンクリックインストールにより統合できるので、自然言語を使用したエージェント開発やデプロイの指示などが可能です。このMCPサーバについては GitHub リポジトリ や Blog をご確認ください。 AWS Builder ID now supports Sign in with Google AWS Builder ID の作成時に Google アカウントを使ったサインインが可能になりました。AWS Builder ID は Kiro、 AWS Training や re:Post などを含む AWS アプリケーションにアクセスするための、AWSアカウントの認証とは独立した個人プロファイルです。今回のサポートにより、Google アカウントでワンクリックサインインできるようになり、パスワード管理の手間を省けます。AWS Builder IDと、利用するアプリケーションについては ドキュメント をご確認ください。 10/3(金) AWS Introduces self-service invoice correction feature 請求書の修正をセルフサービスで行える機能がGAしました。これまで請求書の住所変更等はサポートに依頼して、作業の待ち時間が発生していました。今回の機能によりAWS Billing and Cost Management のコンソールから、購入注文番号や会社名、住所などの請求書情報を直接編集可能によります。これにより自社の経理処理、請求書管理を迅速に行うことが可能になります。この機能はGovCloud (US) リージョンおよび中国 (北京) と中国 (寧夏) リージョンを除く、他のすべてのリージョンで利用可能です。詳細は 製品詳細ページ をご確認ください。 EC2 Image Builder now provides enhanced capabilities for managing image pipelines EC2 Image Builder に連続失敗後に自動でパイプラインを無効化する機能とカスタムロググループ設定の2つの管理機能が追加されました。これにより柔軟な運用が可能になり、また失敗時に無効化できることで繰り返し失敗するビルドによるコストを削減できます。この機能は全ての商用リージョンで利用可能です。詳細は ドキュメント をご確認ください。 Amazon OpenSearch Ingestion now supports batch AI inference Amazon OpenSearch Ingestion パイプライン内でバッチ AI 推論がサポートされました。従来サポートしていたリアルタイム推論は、ストリーミングエンリッチメントなどの低レイテンシ要件に向いたものです。今回のバッチ推論サポートにより、大規模データセットを効率的にオフライン処理できるようになりました。この機能はAmazon OpenSearch Ingestionと2.17以降のバージョンのドメインをサポートする全てのリージョンで利用可能です。詳細については ドキュメント をご覧ください。 実は、私（根本）が週刊AWSを執筆するのは今回を最後にします。2023年の7月に小林、下佐粉から引き継いで以降２年強書いてきましたが、「週刊AWS読んでます！」「写真見たことあります。」とお声がけいただく機会が多く、読んでくださっている方の多さに感謝すると共に、励みになりました。これまでありがとうございました！ 週刊AWSは他のメンバー達で今後も更新されますので、引き続きよろしくお願いします。 ソリューションアーキテクト 根本 裕規 著者について 根本 裕規(Yuki Nemoto) AWS Japan のソリューションアーキテクトとして、金融機関のお客様の AWS 活用や個別案件の技術支援を担当しています。過去には公共部門やモダナイゼーションのスペシャリストもしていました。好きなサービスは AWS CodeBuild です。週末はオフロードバイクのレースをしています！

本投稿は、 Suchindranath Hegde と Mahesh Kansara と Sridhar Ramasubramanian による記事 「 Data consistency with AWS DMS data resync 」を翻訳したものです。 この投稿では、 AWS Database Migration Service の データの再同期機能について詳しく説明します。これは DMS バージョン 3.6.1 で導入された機能で、データベース移行中のデータの不整合を検出して解決するので、手動による修正が必要ありません。 データの再同期 を使用することで、ソースとターゲットデータベース間のデータ検証によって特定されたデータの不整合が識別され、対処されます。ここでは、データの再同期機能を有効にする手順と、例を通じてデータの不整合を特定する方法について説明します。 データの再同期が利用可能になる前は、データの不整合に対してユーザーの介入が必要でした。例えば、フルロードと変更データキャプチャ (CDC) のタスクでテーブルの再ロードを実行したり、ターゲットのレコードを手動で更新したりする必要がありました。データの再同期は、AWS DMS が Oracle か SQL Server から PostgreSQL か Amazon Aurora PostgreSQL への移行をサポートしているすべての リージョン で利用可能です。 AWS DMS データの再同期の設定 データの再同期は、DMS データ検証で特定された不一致を読み取り、ソースから現在の値を取得し、それをターゲットに適用してターゲット上のレコードを同期することによって実行されます。フルロードのみのタスクの場合、再同期が有効になっていると、すべてのテーブルが検証された直後に実行されます。CDC タスクの場合、再同期はタスク設定を通じてスケジュールする必要があり、その時点で、タスクは CDC とデータ検証を一時停止することで書き込みの競合を最小限に抑えます。 ベストプラクティス で推奨されているように、ソースデータベースのアクティビティが少ないタイミングに、再同期ウィンドウを短時間でスケジュールすることをお勧めします。これにより、CDC が一時停止することによるレイテンシーのスパイクを最小限に抑えることができます。 データの再同期を設定するには、タスクの 作成 または 変更 時に有効にする必要があります。AWS DMS コンソールで、 データの再同期 の下にある 再同期のスケジュール を選択します。以下のスクリーンショットに示すとおりです。 再同期スケジュールは、Cron 式を使用してデータ再同期の実行をスケジュールします。 * * * * * | | | | | | | | | | | | | | +---- Day of Week (0-6) | | | +------ Month (1-12) | | +-------- Day of Month (1-31) | +---------- Hour (0-23) +------------ Minute (0-59) 例えば、以下の設定では、データの再同期を土曜日の深夜に実行するようにスケジュールしています： "ResyncSettings": { "EnableResync": true, "ResyncSchedule": "0 0 * * 6", // Run Saturday at midnight "MaxResyncTime": 360, // Run for maximum of 360 minutes, or 6 hours "ValidationTaskId": "" //Optional, used only if validation is performed as a separate Validation only task } その他の例については、 データ再同期の設定と例 を参照してください。 AWS DMS はデータ再同期で PostgreSQL ターゲットエンドポイントに awsdms_validation_failures_v2 テーブルを作成します。このテーブルの構造は、以下のスクリーンショットに示されています。 このテーブルは、検証プロセス中にプライマリキーを使用してソースのデータを参照することで、ターゲットテーブルの不一致を追跡し対処するために参照されます。AWS DMS バージョン 3.6.1 以上にタスクをアップグレードまたは移行する際、アップグレード前に発生した検証の失敗は自動的に再同期されません。アップグレードによる検証の失敗に対処するには、テーブルの再ロードまたは再検証を開始する必要があります。アップグレード後に発生する新しい検証の失敗は、 awsdms_validation_failures_v2 テーブルを通じて追跡され、再同期されます。 再同期実行中に、AWS DMS はタスクタイプに応じて以下の一連のステップを実行します。各ステップについて、タスクタイプに応じて以下のメッセージが CloudWatch ログに記録されます： フルロード と CDC タスク、または CDC タスクの場合： 再同期実行のトリガー： [DATA_RESYNC ]I: Data Resync Manager schedule window time matched to start resync 検証の一時停止： [DATA_RESYNC ]I: Trying to STOP validation before resync process. (resync_manager.c:331) CDC の一時停止： [DATA_RESYNC ]I: Data Resync Manager sending command to sorter to PAUSE applying changes to target. テーブルの再同期： [RESYNC_UNLOAD ]I: Sent ctrl command for Resync Unload of table with id: 1 CDC の再開： [DATA_RESYNC ]I: Data Resync Manager sending command to sorter to RESUME applying changes to target 検証の再開： [DATA_RESYNC ]I: Trying to RESUME validation after resync process フルロードのみのタスクの場合、検証プロセスが完了した後に再同期マネージャーがトリガーされるため、スケジュールを指定する必要はありません。 再同期実行のトリガー： [DATA_RESYNC ]I: Data Resync Manager sending command to start up resync subtasks テーブルの再同期： [TASK_MANAGER ]I: All tables are loaded. Validation is finished. Waiting for resync to finish... (replicationtask.c:4953) [DATA_RESYNC ]I: Stopped Data Resync Manager, exiting thread AWS DMS データの再同期のユースケース AWS DMS のデータの再同期が有効なユースケースはいくつかあります。このセクションでは、2 つの例を見ていきます。 ターゲットでレコードの誤削除 最初に検討するユースケースは、ターゲット上のレコードが誤って削除された場合です。このユースケースを説明するために、REVIEWS という名前のテーブルを Oracle から PostgreSQL に移行します。フルロードが完了した後、ターゲット上の数レコードを誤って削除します。以下の例では、ターゲット上の特定のレコードを削除するために、ターゲットに対して Data Manipulation Language (DML) ステートメントを実行します： dmsdb=&gt; delete from dms_test.reviews where review_id=8193 ; DELETE 1 このシナリオでは、テーブルの再検証を試みるとデータ不整合が発生します。これは、以下のコマンドを入力するか、AWS コンソールで確認することができます： aws dms describe-table-statistics --replication-task-arn arn:aws:dms:us-east-1:xxxxxxxxxxxx:task:xxxxxxxxxxxx --filters Name=table-name,Values="REVIEWS" { "TableStatistics": [ { "SchemaName": "DMS_TEST", "TableName": "REVIEWS", "Inserts": 0, "Deletes": 0, "Updates": 0, "Ddls": 0, "AppliedInserts": 0, "AppliedDeletes": 0, "AppliedUpdates": 0, "AppliedDdls": 0, "FullLoadRows": 3500, "FullLoadCondtnlChkFailedRows": 0, "FullLoadErrorRows": 0, "FullLoadStartTime": "2025-06-03T14:24:23.062000-05:00", "FullLoadEndTime": "2025-06-03T14:24:25.408000-05:00", "FullLoadReloaded": false, "LastUpdateTime": "2025-06-03T14:35:12.009000-05:00", "TableState": "Table completed", "ValidationPendingRecords": 0, "ValidationFailedRecords": 1, "ValidationSuspendedRecords": 0, "ValidationState": "Mismatched records" } ] } データの再同期が有効になっている場合、ソースをチェックし、ターゲットに再適用することでこれらの不整合が処理されます。次の例では、 public.awsdms_validation_failures_v2 テーブルに反映されたレコードを確認できます。ここでは、 RESYNC_ACTION が UPSERT であることから、ターゲットに再適用されたことがわかります。 RESYNC_TIME は、アクションが実行されたタイムスタンプを示しています。 dmsdb=&gt; select * from public.awsdms_validation_failures_v2 ; -[ RECORD 1 ]-+--------------------------- RESYNC_ID | 1029 TASK_NAME | BESR3KWW2FCLLH4AJBFSEYSNW4 TABLE_OWNER | dms_test TABLE_NAME | reviews FAILURE_TIME | 2025-06-03 19:33:26.410998 KEY_TYPE | Row KEY | { + | "key": ["8193"] + | } FAILURE_TYPE | MISSING_TARGET DETAILS | RESYNC_RESULT | SUCCESS RESYNC_TIME | 2025-06-03 19:35:06.322 RESYNC_ACTION | UPSERT CDC 中にターゲットで誤って数件のレコードを削除してしまうシナリオを想像してみてください。例えば、以下の SQL コマンドでは、ターゲット上の 20 件のレコードをランダムに削除します： dmsdb=&gt; delete from dms_test.reviews where ctid in (select ctid from dms_test.reviews order by RANDOM() LIMIT 20); DELETE 20 データの再同期がこれらのレコードを処理し、ターゲットに正常に適用されたことを確認できます。 dmsdb=&gt; select "TABLE_OWNER", "TABLE_NAME","RESYNC_ACTION", "FAILURE_TYPE", "RESYNC_RESULT",count(*) from public.awsdms_validation_failures_v2 group by "TABLE_OWNER", "TABLE_NAME","RESYNC_ACTION", "FAILURE_TYPE", "RESYNC_RESULT"; -[ RECORD 1 ]-+--------------- TABLE_OWNER | dms_test TABLE_NAME | reviews RESYNC_ACTION | UPSERT FAILURE_TYPE | MISSING_TARGET RESYNC_RESULT | SUCCESS count | 21 これまで説明したフルロードと CDC の両方のシナリオでは、データの再同期にテーブルの再検証が必要です。これにより、すべてのデータの不整合が適切に特定され、修正されます。この再検証が必要なのは、ターゲットの変更が AWS DMS によって行われたものではないためです。 テーブルエラー後の CDC タスクの再開 別のユースケースとして、移行中にテーブルがエラー状態になり、そのテーブルの変更がターゲットにレプリケートされない場合があります。この場合、タスクの実行中にテーブルを 再ロード することができます。ただし、CDC のみのタスクの場合、テーブルが失敗した時の LSN からタスクを再開する必要があります。AWS DMS タスク中に複数のテーブルがある場合、特定の時間枠から DMS タスクを開始すると、変更がターゲットに再度適用される場合があります。 Oracle から PostgreSQL に ADMIN スキーマの 5 つのテーブルを移行するシナリオを考えてみましょう。次のスクリーンショットでは、5 つのテーブルのうち 3 つがエラーで終了しています。 CloudWatch ログから、これらのテーブルが異なるタイムスタンプでエラーになったことがわかります。テーブルが異なるタイムスタンプで失敗したため、テーブルがエラーになった最も早いタイムスタンプを CDC 開始時間として使用し、これら 3 つのテーブルで CDC のみのタスクを作成する必要があります。この場合、最も早いタイムスタンプは 2025-06-05T03:40:13 です。 2025-06-05T03:40:13 [TASK_MANAGER ]W: Table 'ADMIN'.'DMST1' was errored/suspended (subtask 0 thread 1). 2025-06-05T03:47:53 [TASK_MANAGER ]W: Table 'ADMIN'.'DMST2' was errored/suspended (subtask 0 thread 1). 2025-06-05T03:52:32 [TASK_MANAGER ]W: Table 'ADMIN'.'DMST5' was errored/suspended (subtask 0 thread 1). データの再同期中に、検出された競合が解消されたことを確認できます。以下のスクリーンショットに示されています。 dmsdb=&gt; select * from public.awsdms_validation_failures_v2 ; -[ RECORD 1 ]-+--------------------------- RESYNC_ID | 9949 TASK_NAME | 6LOQBMAKQFDELB5WQB5BPG5Q74 TABLE_OWNER | admin TABLE_NAME | dmst1 FAILURE_TIME | 2025-06-05 05:26:58.027987 KEY_TYPE | Row KEY | { + | "key": ["101"] + | } FAILURE_TYPE | MISSING_TARGET DETAILS | RESYNC_RESULT | SUCCESS RESYNC_TIME | 2025-06-05 05:30:06.423 RESYNC_ACTION | UPSERT Conclusion この投稿では、データの再同期について紹介し、その設定方法と、検証中にデータ再同期を使用して不整合を確認および修正できる 2 つのユースケースについて説明しました。詳細については、 AWS DMS データの再同期 を参照してください。 著者について Suchindranath Hegde Suchindranath は Amazon Web Services のシニアデータ移行スペシャリストソリューションアーキテクトです。彼はお客様と協力して、AWS DMS を使用した AWS へのデータ移行に関するガイダンスと技術支援を提供しています。 Mahesh Kansara Mahesh は Amazon Web Services のデータベースエンジニアリングマネージャーです。彼は開発チームやエンジニアリングチームと緊密に連携して、移行およびレプリケーションサービスを改善しています。また、お客様と協力して、データベースや分析のさまざまなプロジェクトに関するガイダンスや技術支援を行い、AWS を使用する際のソリューションの価値向上を支援しています。 Sridhar Ramasubramanian Sridhar はAWS Database Migration Service チームのデータベースエンジニアです。彼はAWSのお客様のニーズにより合うように、DMS サービスの改善に取り組んでいます。

このブログは、テオリア・テクノロジーズ株式会社と、アマゾン ウェブ サービス ジャパン合同会社 ソリューション アーキテクト 椎名優司による共著です。 2025 年 6 月 25 日、26 日に幕張メッセで開催された AWS Summit Japan 2025 では、EXPO として AWS Village と呼ばれる展示エリアが用意され、90 を超える AWS 最新テクノロジー展示、先進企業 50 社による AWS 活用事例、パートナーによる 130 以上のソリューション展示など、270 を超える展示を行いました。その中に展開された Industries Pavilion では、各業界向けの最新の AWS ソリューションの展示や、実際に AWS を活用している企業のブースも併設されました。 テオリア・テクノロジーズ株式会社は Industries Pavilion のヘルスケア・ライフサイエンス業界向けブースに出展されました。 今回のブログでは、Industries Pavilion のテオリア・テクノロジーズ株式会社ブースで展示されたAI健康アプリ「 HugWay(はぐうぇい) 」について、プラットフォーム概要やAWS アーキテクチャをご紹介します。 テオリア・テクノロジーズの認知症プラットフォーム事業とAI健康アプリ「HugWay」 テオリア・テクノロジーズは「認知症との向き合い方を、テクノロジーで変えていく。」をミッションに掲げ、エーザイグループの一員として認知症という社会課題の解決を目指しています。 エーザイが創薬で貢献する一方、テオリアはデータサイエンス技術を中心に、「認知症にかかわる全ての人が自分らしくいるための『羅針盤』となる」世界を目指します。その核となるのが、認知症に関する様々なソリューションや人々をつなぐ「認知症プラットフォーム」の構築です。 運動プログラムや食事指導、治療薬やデジタルを活用したものなど多岐にわたるソリューションを線で繋げ、一人ひとりへの「体験の最適化」を目指します。具体的には、健常・未病の方向けに認知機能の低下のリスクに「そなえる」、認知機能の低下が顕著になった方向けに医療機関受診・診断・治療への橋渡しを行う「つながる」、認知症やMCI（軽度認知障害）の診断後の治療・介護を「ささえる」の3つの領域でサービス開発を進め、ポータルサイト「 テヲトル 」がこれらを横断します。 「そなえる」領域のサービスである脳に良い生活習慣をサポートするアプリ「 HugWay（はぐうぇい） 」は、2025年6月16日にリリースしたAIを搭載した健康管理アプリケーションです。「HugWay」は、ユーザーに寄り添うAIパートナーとの対話を中心に、歩数管理、睡眠管理、活動記録、脳に良い生活習慣コンテンツ、そして楽しく続けられる脳トレゲーム（ブレインワークアウト）を提供し、多くの人が抱える「漠然とした認知症への不安」や「義務感があって健康活動が続けられない」「老後の健康不安」といった悩みを解決します。 脳に良い生活習慣をサポートするアプリ「HugWay（はぐうぇい）」の特徴 AIパートナーとの会話と記録 AIパートナー「ハグまる」と日常の出来事や感じたことなど好きなテーマで話す事ができます。AIパートナーがユーザー自身の事や話した内容の一部を覚えて、寄り添った会話が特徴です。話せば話すほどにAIパートナーの「ハグまる」がユーザーの事を理解してくれて、共感し、時には健康に関するヒントや新しい活動を提案します。過去の会話内容も踏まえてパーソナライズされたコミュニケーションを提供し、孤独感の解消やモチベーション維持に繋げます。また、会話の記録はアプリで確認してふりかえる事ができます。 歩数や睡眠などの活動管理 日々の歩数や活動量、睡眠データ、毎日の会話を自動で記録し、ダッシュボードで分かりやすく可視化します。歩数の目標設定機能もあり、AIパートナーとの会話の中で褒められたりと楽しみながら健康習慣の定着をサポートします。 脳活コンテンツ 脳トレゲームとしてブレインワークアウトを搭載。計算問題や記憶ゲームなど、スキマ時間に手軽に楽しく取り組める全10種類のゲームです。脳の活性化を促し、認知機能の維持をサポートします。その他にも脳の健康情報サイトである「 脳ラボ 」と連携し、脳の健康を意識した食事や睡眠、運動などのコンテンツを提供します。 こんな方におすすめ 脳の健康が気になる方 「何となく認知症は不安」、「とりあえず脳トレはやってるけど、認知症のそなえはよくわからない」といった方へ脳に良い生活習慣のサポートを「HugWay」が行います。 健康改善が必要な方 健康診断の結果や体調の変化を機に、生活習慣を見直したいと考えている方に、「HugWay」が寄り添います。 アクティブなシニア層 趣味や社会との繋がりを大切にし、これからも活動的な生活を送りたい方を「HugWay」が応援します。 「HugWay」のシステム設計と運用基盤 「HugWay」 では、生成 AI によるユーザーの会話体験を中核に据え、継続利用を促す話題創出に向けた機能拡張性を担保しました。さらに、スケールと安全性を高めるために当社独自の ID 基盤を活用し、API ゲートウェイを開発して、モバイルからバックエンド、データ基盤までを疎結合のマイクロサービス群として設計しています。これにより、新しい会話体験や外部データ連携を小さく素早く追加可能にしました。また、トラフィックのスパイク時にも安定したレスポンスを維持し、ゼロトラスト前提の認証・認可でユーザーデータを保護します。さらに、DevOps 体制のもとで CI/CD とオブザーバビリティ基盤を活用し、継続的なフィードバックを取り込むことで、機能改善の速度とサービスの信頼性を同時に高めています。 「HugWay」のAWSアーキテクチャのご紹介 サービスとしてAPI機能を提供するバックエンド環境と、生成AIのオブザーバビリティ環境について紹介します。 API を提供するバックエンドは AWS App Runner を中核に据え、オートスケーリングと負荷分散を適切に設計しています。構成は、当社 ID 基盤と連携する認証サーバー、生成 AI と連携するチャットサーバー、その他のアプリ機能を担うメインサーバーの3サーバー構成です。 AWS App Runner はウェブアプリケーションを自動的に構築するサービスであり、トラフィックに合わせてスケールし、Amazon Bedrockを含むほかAWSサービスとシームレスに連携させることができます。AWS App Runnerはフルマネージドサービスであり、インフラの構築や運用は不要です。開発者はコンテナレジストリに保存されているコンテナイメージ、もしくはレポジトリでホストされているコードをソースとして使用することでサービス(上記構成では各機能をもつサーバー)をデプロイできます。 Amazon Bedrock は生成AIアプリケーションやエージェントを構築するためのサービスであり、「HugWay」ではユーザーとAIパートナーの間でパーソナライズされたコミュニケーションを実現するために利用しています。ユーザーとの会話を実現するためにAIチャットサーバーが Converse API を用いてAmazon Bedrockを利用しているほかに、会話内容からユーザーの特徴や傾向を分析したり、シームレスな会話体験を提供するため会話内容を要約して Amazon Aurora に保存し適宜参照し会話に活かすことで、ユーザーに寄り添った会話を実現しています。 生成 AI のテレメトリーは過渡期にあり選定が難しかったため、「HugWay 」では OpenTelemetry を採用しその時最適なソリューションを選択する方法を採用しました。ベンダーに依存しない形でアプリケーションの観測性を高め、生成テキストの安全性検証や表現ルールの策定に活用しています。 おわりに 本ブログでご紹介したテオリア・テクノロジーズ株式会社の展示や関連する AWS サービスに関して、ご興味・ご質問をお持ちのお客様は お問い合わせフォーム もしくは担当営業までご連絡ください。 著者について テオリア・テクノロジーズ株式会社 太田 忠 (Tadashi Ota) プロダクトマネージャー 予防、ヘルスケア領域を担当しており、認知症のそなえを推進しています。プロダクトマネジメントの他に事業戦略や組織、採用など幅広く活動しています。 安藤 圭吾 (Keigo Ando) プロダクト開発部シニアソフトウェアエンジニア バックエンド・インフラを中心に、何でもやる縁の下の力持ちを目指しています。 アマゾン ウェブ サービス ジャパン合同会社 椎名 優司 (Yuji Shiina) ソリューションアーキテクト ヘルスケア・ライフサイエンス領域のお客様を中心に、クラウド利用の技術支援を通じてお客様のご要望を具現化するための活動をしています。

クライオ電子顕微鏡（Cryo-EM）は、創薬研究者が創薬に不可欠な生体分子の三次元構造を決定することを可能にします。Cryo-EMの導入が進むにつれ、科学者やITシステム管理者は、これらの顕微鏡によって毎日生成される数テラバイトのデータを効率的に処理する方法を模索してきました。これらの処理パイプラインには、スケーラブルで多様なワークロードに対応できるコンピューティング環境と、高速かつコスト効率に優れたストレージが必要です。 AWS Parallel Computing Service (PCS)は、クラウドでハイパフォーマンスコンピューティング(HPC)クラスタを展開・管理するためのマネージドサービスです。Cryo-EMにPCSを使用することで、構造生物学者にとって一貫したユーザー体験を維持しながら、HPCインフラの構築と管理に伴う差別化につながらない重労働を軽減し、研究に迅速に取り掛かることができます。 この投稿では、PCS上でCryo-EMに使用できる推奨リファレンスアーキテクチャを紹介し、一般的なアプリケーションである CryoSPARC を使用した具体例を示します。また、可視化ツールとして ChimeraX について紹介し、一般的にクラウドでCryo-EMを実行するためのベストプラクティスについても解説します。 アーキテクチャの概要 図1 – AWS上のCryoSPARCのアーキテクチャ概要。SlurmコントローラはAWSサービスアカウントに配置され、コンピュートとストレージリソースはユーザーAWSアカウントに配置されます。クラスタにはFSx for LustreとAmazon Elastic File Store (EFS)がマウントされています。 セットアップと前提条件 PCSドキュメントに記載されている 前提条件 に加え、CryoSPARCのライセンスが必要です。ライセンスなしでこのガイドに従ってPCSクラスタを作成することは可能ですが、最終的にはソフトウェアをインストールしてテストジョブを実行するためにライセンスが必要になります。ライセンスを取得するには、 Structura Biotechnology にお問い合わせください。 共有ストレージを使用したクラスタの作成 HPC Recipes Library は AWS のエンジニアリングチームとアーキテクチャチームが作成したテンプレートを共有するGitHubの公開リポジトリです。これにより、面倒な構築手順なしにHPCインフラをクラウド上に展開できます。この例に適した共有ストレージを備えたPCSクラスタを作成するには、AWS CloudFormationを使用してクラスタ全体を迅速に起動する PCS guidance for a one-click deployment &nbsp;を利用できます。 CloudFormationが起動するとパラメータ指定の画面が表示されます。ここにクラスターのログインノードにアクセスするためのSSHキーをプルダウンで指定するオプションが表示されます。その他のフィールドはすべてそのままにしておき、 Create を選択してください。これにより、必要なネットワークの前提条件、ログインノードグループを含むクラスター、単一のデモ用コンピューティングノードグループ、/home用のEFSファイルシステム、および/shared用のLustreファイルシステムが作成されます。。 準備が整うと CloudFormation console &nbsp;に以下のスタックが表示されるはずです。図2はCloudFormationのスクリーンショットで、各スタックにデプロイされた内容の簡単な説明が含まれています。 図2: hpcレシピテンプレートによって作成されたCloudFormationスタック また、PCSクラスタを手動で作成する場合や、アカウント内の既存のリソースを使用する場合は PCS User Guide の手順に従ってこれらのリソースを設定するだけです。 LustreファイルシステムのスループットのためのFSxの調整 CloudFormation console で View Nested のラジオスライダーをクリックして、デプロイしたテンプレートから作成されたさまざまなスタックを確認します。 get-started-cfn-FSxLStorage で始まるスタックを見つけてクリックします。コンソールの右側にスタック情報が表示されたら、 Outputs タブをクリックし、後ほど使用する FSxLustreFilesystemId &nbsp;の値をメモします。 図 3: hpc レシピテンプレートによって作成された FSx for Lustre CloudFormation スタック CryoSPARC のインストールを成功させるには、FSx for Lustre システムのストレージ単位あたりのスループットを 250 MB/s/TiB に更新する必要があります。この処理には最大 20 分かかる場合がありますので、残りのクラスター設定を進める間、ファイルシステムの更新がバックグラウンドで完了する時間を確保するため、今すぐコマンドを実行しましょう。 aws fsx update-file-system \ --file-system-id $FSX-LUSTRE-ID \ --lustre-configuration PerUnitStorageThroughput=250 追加のノードグループとキューの作成 最初のクラスタ作成が完了したら、いくつかのコンピュートノードグループとキューを作成します。AWS PCSのコンピュートノードグループは、Amazon Elastic Compute Cloud (Amazon EC2)のノード(インスタンスと呼称されます)の論理的な集合体です。これらは、あなたがジョブを実行する一時的なマシンとなります。AWS PCSキューは、スケジューラのネイティブ実装であるワークキューを軽量に抽象化したものです。ジョブはキューに投入され、キューは1つ以上のコンピュートノードグループにマッピングされます。CryoSPARCでは、レーンはPCSキューに相当します。 compute-cpu （c5a.8xlargeインスタンス）、 compute-single-gpu （g6.4xlarge）、 compute-multi-gpu （g6.48xlarge）の3つの新しい計算ノードグループを作成し、これらの計算ノードグループをそれぞれのキューにマッピングします。これらのインスタンスタイプは、私たちの内部テストに基づいて選定されました。処理パイプライン内の個々のタスクのスケーラビリティに関する詳細な説明は CryoSPARC performance benchmarks にて選定理由が説明されています。 これらのノードグループはPCSコンソールから作成できますが、ここではAWS CLIで作成する方法を紹介します。このコマンドを実行して、 compute-1 の PCS Compute Node GroupのAMI ID、Instance Profile、Launch Template IDを取得し、出力を保存します。次の一連のコマンドでこれを使用して、追加のコンピュートノードグループを作成します: aws pcs get-compute-node-group \ --cluster-identifier $PCS_CLUSTER_NAME \ --compute-node-group-identifier compute-1 以下のコマンドを実行し、各コマンドの出力から計算ノードグループ名とIDを保存します。これを使用して、これらのノードグループをキューにマッピングします： aws pcs create-compute-node-group \ --compute-node-group-name compute-cpu \ --cluster-identifier $PCS_CLUSTER_NAME \ --region $REGION \ --subnet-ids $PRIVATE_SUBNET_ID \ --custom-launch-template id=$COMPUTE_LT_ID,version='1' \ --ami-id $AMI_ID \ --iam-instance-profile $INSTANCE_PROFILE_ARN \ --scaling-config minInstanceCount=0,maxInstanceCount=2 \ --instance-configs instanceType=c5a.8xlarge aws pcs create-compute-node-group \ --compute-node-group-name compute-single-gpu \ --cluster-identifier $PCS_CLUSTER_NAME \ --region $REGION \ --subnet-ids $PRIVATE_SUBNET_ID \ --custom-launch-template id=$COMPUTE_LT_ID,version='1' \ --ami-id $AMI_ID \ --iam-instance-profile $INSTANCE_PROFILE_ARN \ --scaling-config minInstanceCount=0,maxInstanceCount=2 \ --instance-configs instanceType=g6.4xlarge aws pcs create-compute-node-group \ --compute-node-group-name compute-multi-gpu \ --cluster-identifier $PCS_CLUSTER_NAME \ --region $REGION \ --subnet-ids $PRIVATE_SUBNET_ID \ --custom-launch-template id=$COMPUTE_LT_ID,version='1' \ --ami-id $AMI_ID \ --iam-instance-profile $INSTANCE_PROFILE_ARN \ --scaling-config minInstanceCount=0,maxInstanceCount=2 \ --instance-configs instanceType=g6.48xlarge 以下のコマンドを実行して、ノードグループの作成状況を確認します： aws pcs get-compute-node-group --region $region \ --cluster-identifier $cluster-name \ --compute-node-group-identifier $node-group-name 3つのノードグループそれぞれのステータスが ACTIVE になったら、キューの作成に進むことができます。各キューは1つ以上のノードグループにマッピングされ、これらのノードグループはキューに到着したジョブを処理するための一時的なインスタンスを供給する役割を担います。このクラスタでは、各キューを単一のノードグループにマッピングします。 $NODE_GROUP_ID はノードグループ名と同じではないことに注意してください。 aws pcs create-queue \ --queue-name cpu-queue \ --cluster-identifier $PCS_CLUSTER_NAME \ --compute-node-group-configurations computeNodeGroupId=$COMPUTE_CPU_NODE_GROUP_ID aws pcs create-queue \ --queue-name single-gpu-queue \ --cluster-identifier $PCS_CLUSTER_NAME \ --compute-node-group-configurations computeNodeGroupId=$COMPUTE_SINGLE_GPU_NODE_GROUP_ID aws pcs create-queue \ --queue-name multi-gpu-queue \ --cluster-identifier $PCS_CLUSTER_NAME \ --compute-node-group-configurations computeNodeGroupId=$COMPUTE_MULTI_GPU_NODE_GROUP_ID 次に、キューが正常に作成されたことを確認します： aws pcs get-queue --region $REGION \ --cluster-identifier $PCS_CLUSTER_NAME \ --queue-identifier $PCS_QUEUE_NAME ステータスが ACTIVE &nbsp;を返したら、キューの作成は完了です。クラスタログインノードにログインして、CryoSPARCをインストールします。 Amazon EC2のコンソールを開き Instances に移動します。 検索バー で aws:pcs:compute-node-group-id = &lt;LOGIN_COMPUTE_NODE_GROUP_ID &gt; を検索し、 &lt;LOGIN_COMPUTE_NODE_GROUP_ID&gt; をログインノードグループのIDに置き換えてエンターキーを押します。このインスタンスを選択し、 Connect を選択します。次のページで、 Session Manager を選択し、 Connect を選択します。ブラウザのタブでターミナルセッションが開きます（これはSession Managerの優れた機能です）。ターミナルで、ユーザを ec2-user に変更します。ec2-userは、ジョブの投入と管理を行うSlurmの権限を持つクラスタ内のユーザです。 sudo su - ec2-user クラスタのログインノードに接続したら、次のコマンドを実行して追加のSlurmパーティションを確認します： sinfo 以下のように表示されます： PARTITION AVAIL TIMELIMIT NODES STATE NODELIST demo up infinite 4 idle~ compute-1-[1-4] single-GPU up infinite 4 idle~ single-GPU-[1-4] CPU up infinite 4 idle~ CPU-[1-4] multi-GPU up infinite 4 idle~ multi-GPU-[1-4] クラスタにログインできたので、CryoSPARCをインストールしてテストデータセットをダウンロードします。 CryoSPARCのインストールとテストデータセットのダウンロード CryoSPARCのインストールとセットアップを簡単にするために、共有ファイルシステムにアプリケーションをインストールし、クラスタのキュー名に基づいてレーンを登録するシェルスクリプトを用意しました。これにアクセスするには、 キーペアを生成して ログインノードにSSH接続します。ログインノードに接続したら、スクリプトをダウンロードして実行可能ファイルにしてください： wget https://raw.githubusercontent.com/aws-samples/cryoem-on-aws-parallel-cluster/refs/heads/main/parallel-computing-service/pcs-cryosparc-post-install.sh スクリプトを実行し、インストール用の共有ファイルシステムを指定します。 $LICENSE_ID をCryoSPARCのライセンスに置き換えてください。最大1時間かかります。 chmod +x pcs-cryosparc-post-install.sh sudo ./pcs-cryosparc-post-install.sh $LICENSE_ID /shared/cryosparc /shared/cuda 11.8.0 11.8.0_520.61.05 /shared インストールが完了したら、CryoSPARCサーバーを起動します： /shared/cryosparc/cryosparc_master/bin/cryosparcm start ログインノードを再起動した場合、CryoSPARCサーバーのstartコマンドを再度実行する必要があります。このコマンドを起動テンプレートのEC2ユーザーデータセクションに追加することで、このプロセスを自動化できます。Amazon EC2ユーザーデータの操作については PCS User Guide を参照してください。 サーバーが正常に起動し、 CryoSPARC master started という確認メッセージが表示されたら、新しいユーザーを作成します： cryosparcm createuser \ --email "&lt;youremail@email.com&gt;" \ --password "&lt;yourpassword&gt;" \ --username "&lt;yourusername&gt;" \ --firstname "yourname&gt;" \ --lastname "&lt;yourlastname&gt;" 完了したら、ログインノードからログアウトしてください。 CryoSparc UIへのアクセス 次に、先に生成したEC2キーペアを使用してSSHトンネルをCryoSPARCのログインノードに設定します： ssh -i /path/to/key/key-name -N -f -L \ localhost:45000:localhost:45000 ec2-user@publicIPofyourinstance これを実行した後、ウェブブラウザで http://localhost:45000 &nbsp;にアクセスすると、CryoSPARC のログイン画面が表示されます。 図4: ウェブブラウザのログイン画面から、新しく作成したユーザー認証情報を使ってCryoSPARCにアクセスします。 テストジョブの実行 sharedディレクトリにテストデータ用のデータフォルダを作成し、以下のコマンドでテストデータセットをダウンロードします： mkdir /shared/data cd /shared/data /shared/cryosparc/cryosparc_master/bin/cryosparcm downloadtest tar -xf empiar_10025_subset.tar このステップの完了には数分かかります。 このテストでは、データセットをLustreファイルシステムに直接ダウンロードしています。本番環境では、Amazon Simple Storage Service (Amazon S3)にデータセットを保存し、Amazon S3とAmazon Fsx for Lustreファイルシステム間で Data Repository Association (DRA) を使用することをお勧めします。1つのCryo-EMサンプルのサイズは数十テラバイトになることがあり、組織は定期的にペタバイトの顕微鏡データを保存しているため、このようにAmazon S3とFSx for Lustreを使用すると、コストを大幅に削減できます。DRA をセットアップするには FSx for Lustre documentation を参照してください。 テストデータセットのダウンロードが完了したら Get Started with CryoSPARC Tutorial &nbsp;の手順に従って、Import Movies ジョブを実行します。ジョブのキューを選択すると、Slurmクラスタのキューが表示されます。Import Moviesジョブの compute-cpu レーンを選択します： 図5：CryoSPARCは、PCSキューと同じ名前でレーンを構成しています。ムービーのインポートジョブにcompute-cpuを選択します ジョブを実行します。CryoSPARC UIのEvent Logの下に、このようなSlurmサブミッションが表示されるはずです： 図6: 成功したCryoSPARCジョブ投入 ターミナルに戻ってログインノードから squeue コマンドを実行すると、クラスタ上で実行されているジョブを確認できます： JOBID PARTITION NAME USER ST TIME NODES NODELIST(REASON) 1 compute-c cryospar ec2-user CF 1:02 1 compute-cpu-1 sinfo を実行して、ジョブ用に割り当てられているノードを確認します： PARTITION AVAIL TIMELIMIT NODES STATE NODELIST demo up infinite 4 idle~ compute-1-[1-4] compute-cpu up infinite 1 mix# compute-cpu-1 compute-cpu up infinite 3 idle~ compute-cpu-[2-4] compute-single-GPU up infinite 4 idle~ compute-single-gpu-[1-4] compute-multi-GPU up infinite 4 idle~ compute-multi-gpu-[1-4] このノードは、EC2によってAWSアカウントにプロビジョニングされたシングルインスタンスです。EC2コンソールで確認できます。ジョブは数分で正常に完了するはずです。これ以上ジョブをキューに投入しなければ、最後のジョブが完了した数分後にそのインスタンスが動的に終了するのがわかります。 可視化と次のステップ 可視化パッケージのような追加アプリケーションをクラスタ共有ストレージにインストールすることができます。 ChimeraXは構造生物学者によく使われている可視化アプリケーションです。この記事では取り上げませんが、ログインノードにAmazon DCVを設定することで、クラスタ上でこれを実行することができます。DCVは、デスクトップとクラウド間で低レイテンシー、高解像度のリモート可視化を提供し、手元の環境とクラウド間の時間とコストのかかるデータ移動を不要にします。 図7: CryoSPARCで実行し、ChimeraXで可視化したEMPIAR 10288サンプルの結果のスクリーンショット。 環境の削除 AWS CLIを使用して、まず以下のコマンドを使用して cpu-queue 、 single-gpu-queue 、 multi-gpu-queue を削除することで、この投稿で構築した環境を削除できます： aws pcs delete-queue --cluster-identifier &lt;pcs_cluster_name&gt; --queue-identifier &lt;pcs_queue_name&gt; 次に、以下のコマンドで compute-cpu , compute-single-gpu と compute-multi-gpu &nbsp;の各コンピュートノードグループを削除します： aws pcs delete-queue --cluster-identifier &lt;pcs_cluster_name&gt; --compute-node-group-identifier &lt;pcs_compute_node_group_name&gt; 最後に、次のコマンドを使用してCloudFormationテンプレートを削除することで、PCSクラスタとそれで作成されたすべてのリソースを削除します： aws cloudformation delete-stack --stack-name &lt;pcs_cloudformation_stack name&gt; 結論 AWS Parallel Computing Service は、 Cryo EM をクラウドで実行するためのパワフルでスケーラブルなソリューションを提供し、研究者が新しい科学的発見を解き放つことを可能にします。 AWS上のスケーラブルでオンデマンドなコンピューティングにより、科学者のアイデアや意欲の成長に合わせて要求に応えることができます。多様なワークロードに対応できるコンピューティングでAWS PCSを構成し、利用可能になった最新のインスタンスタイプで状態を保つことができます。Amazon DCVを使用してPCSに統合された高解像度、低レイテンシーの可視化により、科学者はデスクトップから直接、完全なCryo-EMワークフローを実行できます。 お客様がクライオ電子顕微鏡（Cryo-EM）のデータ解析環境にAWSを選択するメリットは、研究者にとってスケーラビリティ、柔軟性、最終的な効率性をもたらすことができることです。 本ガイドでは、PCS上でCryo-EMジョブを実行する方法の一例を紹介します。構造生物学者は、1つのサンプルを処理する際に複数のアプリケーションを使用し、組織内の研究グループ間でデータセットを共有することがよくあります。AWS Professional ServicesとClovertexのようなAmazon Partner Network (APN)のメンバーは、組織のニーズに合わせてこの初期システムのスケールアウトを支援することができます。詳細については、AWSアカウントチームにお問い合わせいただくか ask-hpc@amazon.com までご連絡ください。 <!-- '"` --> 本ブログ記事は、プロフェッショナルサービスの山下が翻訳しました。原文は こちら です。 &nbsp; 著者について Marissa Powers Marissa Powers は、ハイパフォーマンスコンピューティング(HPC)とライフサイエンスに特化したAWSのスペシャリストソリューションアーキテクトです。彼女は計算神経科学の博士号を持っており、創薬ワークロードを加速するために研究者や科学者と働くことを楽しんでいます。ボストンに家族と住んでおり、ウィンタースポーツとアウトドアの大ファンです。 Juan Perin Juan Perin は、HPCとストレージを専門とするヘルスケアとライフサイエンスのスペシャリストです。ライフサイエンス分野の研究開発で深い経験を持ち、テクノロジーとサイエンスの応用のギャップを埋めることに喜びを感じています。ニューヨーク近郊に住み、3人の男の子の父親として多忙な日々を送っています。 Rye Robinson Rye Robinson は、AWSのHPCを専門とするライフサイエンス・ソリューション・アーキテクトです。お客様が新技術や最先端技術を活用し、多様な複雑な課題を解決するお手伝いをすることが喜びです。仕事以外では、完璧なエスプレッソを淹れるための探求を続けています。 翻訳者について Tomoya Yamashita 山下 智也(Tomoya Yamashita)は Professional Services のコンサルタントです。大規模なマイグレーションやDBマイグレーションチームに所属しています。HPC、ライフサイエンスをはじめエッジの効いたマイグレーションを推進することを楽しんでいます。最近は一緒に年を取ってきた老犬のお世話を日課にしています。 <!-- '"` --> TAGS: Cryo-EM , Elastic Fabric Adapter , Research Computing , Storage , visualization

コンタクトセンターのリーダーは、情報に基づいた適切な運用上の意思決定を行うために、 Amazon Connect のコストの可視性の向上を常に求めています。この記事では、生の請求データを実用的なインサイトに変換する強力なソリューションである Amazon Connect Cost Insight Dashboard をご紹介します。このツールは、コンタクトセンターの最適化に特化して設計された包括的なコスト分析機能を提供し、サービスの品質・優秀性を維持しながら効率化の機会を特定することを可能にします。 Amazon Connect Cost Insight Dashboard は、コンタクトセンターの財務的なパフォーマンスについて、包括的に可視化します。月次のコストトレンドを追跡し、サービスコンポーネント別にコストを分解し、通話国や通話の方向に関わらずテレフォニー費用を分析します。このダッシュボードは、チャネル別のコスト比較、地域別のコスト分析を可能にし、コンタクトあたりのコストなどの主要な効率性に関わるメトリクスを提供します。この強力なツールは、コンタクトセンターマネージャーが情報に基づいた意思決定を行い、運用を最適化するために、必要なデータを提供します。 仕組み このソリューションは、以下のように AWS サービスを利用し、請求データをアクセスしやすいインサイトに加工します。 図 1: Cloud Intelligence Dashboards Framework のアーキテクチャ概要 AWS コストと使用状況レポート (AWS CUR) が詳細なコストデータを S3 バケットに配信 AWS Glue crawler がコスト情報のデータカタログを作成・更新 Amazon Athena が情報をクエリし、関連する Amazon Connect のデータを処理 Amazon QuickSight がこれらのデータからインタラクティブな可視化を提供 Amazon Connect のコスト分析に役立つ 6 つのビュー Overview (概要): Amazon Connect の使用状況とコストに対する概要レベルの可視化を提供します。Amazon Connect のサービスと通話料を分割して表示できす。また月次のトレンドや当月のメトリクスを表示できます。インバウンドおよびアウトバウンド通話の上位国を特定できます。アカウント、リージョン、サービス別にコストを分類できます。 Contact Center: Amazon Connect が有効化されたアカウント内での AWS サービス全体のコストを追跡します。より明確に可視化するため Amazon Connect のコストを除外したサービスのトレンドを表示します。Amazon Lex、Amazon DynamoDB、Amazon S3 などのコンタクトセンターソリューションに統合されるサービスの利用増加のパターンを明らかにできます。また、それらの月次分析が可能です。このビューでは、コンタクトセンターソリューション全体の完全なコストをマッピングできます。例えば、棒グラフでは（Amazon Connect のコストを除いた）サービスタイプ別のコンタクトセンターでの使用状況を表示でき、Amazon Connect と併用されている追加サービスのコストが確認できます。これにより、顧客は Amazon Connect サービスを超えた全体の技術的な支出を理解できます。 Amazon Connect: Amazon Connect サービスコストを通話料と切り離して確認できます。複数のリージョンとアカウント間での使用パターンをマッピングでき、サービスコンポーネントの詳細な内訳（エンドカスタマーの通話分数、チャットインタラクション、タスク、エージェント評価）を表示できます。各サービスコンポーネントの単位あたりコストを計算できます。 Telecom: コンタクトセンターの通話料の分析のためのビューです。インバウンド/アウトバウンドの時間(分)と通話料のタイプを分類できます。国別にテレコムの使用状況とコストをマッピングでき、世界地図上でグローバルな通話料の状況を可視化できます。コスト影響の多い上位の要素と高額な通話先を特定できます。 Daily usage (日次使用状況): 過去 30 日間の詳細な使用状況ビューを提供します。データをインバウンド、アウトバウンド、電話番号のコストに分類できます。特定の日、国、通話へのドリルダウンが可能です。バブルチャートを使用してコストと利用量、価格の関係を可視化できます。個別の通話コストの調査に役立つビューです。 Call Details (通話詳細): コンタクト ID ごとの使用タイプを集約できます。通話コストと通話時間の分布を可視化します。最も高額で最も長時間の通話にフラグを立てたり、国別の通話時間パターンを表示することができます。特定の通話詳細と使用タイプの詳細な分析に役立ちます。 Contact Search (問い合わせ検索): 特定の問い合わせに対する高度なフィルタリングを提供します。価格、通話時間、国による検索が可能です。コンタクトセンター使用状況を地理的ビューで確認できます。個別の問い合わせコストと特性の詳細分析が可能です。 Amazon Connect Cost Insight Dashboard のデモ 実際にデプロイする前にダッシュボードの機能を体験したい場合、 インタラクティブなデモをご覧ください 。このデモではサンプルデータを使用して、ダッシュボードの直感的なインターフェースと強力な可視化機能を紹介しています。 図 2: Amazon Connect Cost Insight Dashboard のデモ このデモでは、サービスコンポーネント別のコスト内訳、地域別支出比較、チャネルコスト分析などの主要機能に触れることができます。FinOps チーム、コンタクトセンターマネージャー、DevOps エンジニア、ビジネスリーダーは、これらのインサイトが各役割と責任にどのように活用、適用できるかすぐに確認できます。 コンタクトセンターのコスト最適化の例 高額な通話の調査によるコスト分析 Call Details ビューにアクセスすることで、最もコストの高い上位 50 件の通話を特定し分析することができます。例えば $0.62 の通話を例にします。この特定のデータポイントを選択すると、ビューが即座にフィルタリングされ、その完全な内訳が表示されます。ダッシュボードでは、エンドカスタマーとフリーダイヤルの分単位のコストの両方が表示され、$0.62 に積み上がるコストの単価・要素が表示されます。高額な通話に対して、この詳細な可視化を行うことで、高コストなやり取りのパターンを特定し、的を絞ったコスト最適化戦略とより効率的なリソース配分を可能にします。 国別の通話時間ベースのコスト分析 国別の通話時間分布により、10 秒の短い通話から 20 分の長時間の通話まで、異なる時間別のセグメントにわたるコストパターンが明らかになります。例えば、ベルギーの通話パターンを調べるために、その時間のセグメントを選択すると、関連するすべてのコンタクト ID がインタラクティブにバブルとして表示され、それぞれに関連するコストが表示されます。特定の問い合わせをクリックすると、エンドカスタマーとフリーダイヤル分数の詳細なコスト内訳が表示されます。この詳細なビューを Contact Lens の分析と組み合わせることで、どの通話時間と国がより高いコストを発生させるかを特定し、国際通話ルーティングの最適化、人員配置の調整、運用費用削減のためのプロセス改善について、データに基づいた意思決定を可能にします。 アクションを起こしましょう Amazon Connect のコストを完全に可視化しましょう。このダッシュボードは、すべてのチャネルにわたる使用パターンとコストを明らかにし、最適化の機会のすばやい特定に役立ちます。 このソリューションを実装し、コンタクトセンターのコストを最適化するために、 ワークショップガイドにアクセス してください。 筆者紹介 Paras Babbar は AWS の Enterprise Support Lead および Connect スペシャリストで、顧客が堅牢で効率的なクラウドソリューションを構築するためのガイダンスの提供に長けています。彼はコンタクトセンターの革新と複雑なビジネス課題への取り組みを専門とし、顧客の成功を推進する革新的な戦略を一貫して提供しています。 Alex Yankovskyy は AWS Telecom のソリューションアーキテクトで、コンタクトセンターおよびカスタマーエクスペリエンスのソリューションにおいて 15 年の経験を持っています。彼は様々な業界の企業が Amazon Connect を使用してコンタクトセンターを変革することを支援し、AI 統合と運用効率に焦点を当てています。Alex は 12 の AWS 認定資格を保有しています。 Baraa Elkosh は AWS Telecom のソリューションアーキテクトで、コンタクトセンターおよびカスタマーエクスペリエンスのソリューションにおいて 15 年の経験を持っています。彼は様々な業界の企業が Amazon Connect を使用してコンタクトセンターを変革することを支援し、AI 統合と運用効率に焦点を当てています。Alex は 12 の AWS 認定資格を保有しています。 Mariia Poliak は AWS のクラウドオペレーションアーキテクト（COA）で、クラウドコスト最適化に情熱を持っています。Enterprise Support 組織内で働く彼女は、顧客が AWS サービスから最大の価値を得ながら、最適なクラウド利用のプラクティスを実現できるよう支援しています。 翻訳はテクニカルアカウントマネージャー高橋が担当しました。原文は こちら です。