はじめに データドリブンエンタープライズの環境では、組織は 2 つの重要な要件を満たすデータベースソリューションを必要としています。1 つは、トランザクション処理と分析処理の両方のワークロードを扱える高性能性、もう 1 つはセキュリティとコンプライアンス要件への適合です。AWS 上で運用される SAP HANA Cloud は、 SAP Business Technology Platform（ SAP BTP ） のサービスの一つであり、フルマネージド型のクラウドネイティブな Database-as-a-Service として、これらの要件に応えます。 SAP HANA Cloud は主に 2 つの用途で活用されています。1つは、ERP、CRM、HR、ロジシティックスなどの基幹システムを単一の高速プラットフォームで支えること。もう 1 つは、高度な分析とデータアプリケーションを通じて、実践的なビジネスイノベーションを推進・支援することです。また、SAP HANA Cloud は、SAP Analytics Cloud、SAP Datasphere、SAP Cloud Application Programming Model（CAP）で開発されたアプリケーションなどの、様々な SAP BTP サービスの基盤でもあります。 このブログでは、AWS PrivateLink を通じて SAP HANA Cloud のセキュリティと接続性を強化することにフォーカスし、高性能と信頼性を維持しながらプライベートで安全なデータベースアクセスを必要とする組織の重要なニーズに対応します。 AWS が SAP HANA Cloud の稼働基盤として選ばれた理由 SAP HANA Cloud は  AWS Graviton プロセッサーによって対応しており、分析ワークロードで計算性能が最大 30% 向上しを提供し、計算コストを 15% 削減し、同等の EC2 インスタンスと比較して最大 60% 消費エネルギーを抑えることができます 。AWS Graviton ベースのインスタンスに移行することで、SAP は SAP HANA Cloud ワークロードの計算カーボンフットプリントを約 45% 削減できると見込んでおり、炭素排出量削減を支援する Amazon の The Climate Pledge の署名企業としての取り組みを支持します。SAP は将来的に AWS Graviton の使用を拡大し、これらの性能向上、コスト削減、エネルギー効率を継続的に活用する計画です。したがって、AWS 上の SAP HANA Cloud を使用するお客様は、性能向上のメリットを享受しながら、カーボンフットプリントを削減も実現できます。 AWS 上の SAP HANA Cloud への接続 SAP HANA Cloud に接続する際、オンプレミスまたは他のクラウド環境にあるクライアントアプリケーションやユーザーは、インターネットアクセス可能なエンドポイントを通じてパブリック API を使用してデータベースにセキュアにアクセスできます。 図1：デフォルトのパブリックエンドポイント経由でのSAP HANA Cloudへの接続 金融サービス、ヘルスケア、政府機関などの規制産業のお客様で、HIPAA、EU/US Privacy Shield、PCI DSS などの規制により、パブリックエンドポイントの使用が制限される場合があります。この場合、SAP HANA Cloud と AWS PrivateLink を組み合わせることをお勧めします。これにより、AWS の安全なネットワークインフラストラクチャを活用しながら、データベースとアプリケーション間の安全かつプライベートな通信を実現できます。また、プライベートIPアドレス範囲（RFC 1918）を使用することで、サービスへの攻撃リスクが低減できます。 このブログでは、AWS PrivateLink を使用したプライベート接続オプションを活用して、SAP HANA Cloud のデータ転送時のセキュリティを強化する方法について解説します。PrivateLink は、AWS 環境と SAP HANA Cloud 間の安全でプライベートなネットワーク接続を確立でき、パブリックインターネットへの通信を回避し、不正アクセスのリスクを抑制することができます。 AWS PrivateLink とは AWS PrivateLink を使うことにで、AWSサービス（ネットワーク、コンピューティング、サーバーレスアプリケーション、AI など）と SAP BTP サービス間の通信をインターネット経由せず、プライベート接続を実現できます。また、AWS PrivateLink を使用して、Direct Connect または VPN 経由で Amazon Virtual Private Cloud（VPC）に接続されたオンプレミスネットワーク間の安全でプライベートな接続を提供することもでき、パブリックネットワークやIPアドレスを完全に回避できます。 AWS PrivateLink により、異なるアカウントやVPC間でのサービス接続が簡単になり、ネットワークアーキテクチャを大幅に簡素化します。VPC 内のプライベート IP アドレスを持つ Elastic Network Interface であるインターフェースエンドポイント経由で、AWS サービス、他の AWS アカウントで稼働しているサービス（エンドポイントサービス）、AWS Marketplace パートナーサービスに接続できます。 インターフェースエンドポイントは、VPC のサブネット内の Elastic Network Interface と IP アドレスを使用して、VPC 内に直接作成されます。プロバイダーとコンシューマーは、IPアドレスの重複を避けるためにネットワークセグメントや CIDR ブロックを調整する必要がありません。VPC ピアリングや AWS Transit Gateway 経由の接続は通信に必要ありません。セキュリティグループを関連付け、AWS サービスのインターフェースエンドポイントにエンドポイントポリシーを設定することで、指定されたサービスへのアクセスを制御できます。AWS PrivateLink を使用すると、 AWS サービス や他の VPC が提供する他のサービスに、AWS ネットワーク内のプライベート接続を通じて安全にアクセスできます。すべてのネットワークトラフィックはグローバル AWS バックボーン上に留まり、パブリックインターネットを経由することはありません。 図2：AWS PrivateLink 経由での SAP HANA Cloud への接続 SAP HANA Cloudと AWS PrivateLink との接続するメリットをより理解するために、実際のシナリオでそのメリットを示すいくつかの実用的なユースケースを探ってみましょう。 SAP HANA Cloud と AWS PrivateLink を使うユースケース データセキュリティが重要なビジネス環境において、AWS PrivateLink の実装は、データ転送中の機密情報を保護するために不可欠です。AWS のインフラストラクチャが提供するプライベート IP エンドポイントサービスは、重要なセキュリティレイヤーとして機能し、ビジネスへ重大な影響をもたらす可能性のあるセキュリティ侵害を防ぐのに役立ちます。この統合は、現代のクラウドアーキテクチャの複雑な要件に対応するエンタープライズクラスのセキュリティソリューションを提供することに対する AWS のコミットメントを示しています。 ユースケース 1 – SAP HANA Cloud 管理アクセスセキュリティ SAP HANA Cloud PrivateLink を実装する重要なユースケースの 1 つは、安全なデータベースアクセスへの対応です。企業の環境では、オフィスで働くデータベース管理者と開発者は、テーブル管理、メンテナンス、開発タスクなどの重要タスクを実行するために SAP HANA Cloud への定期的なアクセスが必要です。これらの技術者は、一般ユーザーとは異なり、タスクに必要な広範なデータベース権限を付与されているため、接続セキュリティが特に重要になります。 図3に示すように、 AWS PrivateLinkを使用した SAP HANA Cloud は、組織が機密データの転送をプライベートネットワークでのみに制限できるようにする完璧なソリューションを提供します。データベース操作へのプライベートアクセスは、運用効率を維持しながらパブリック IP を使わず、厳格なアクセス制御を通じて組織のセキュリティを強化します。 図3：SAP HANA Cloud 管理アクセスセキュリティ ユースケース 2 – セキュアなデータプラットフォーム統合：SAP HANA Cloud と AWS サービス SAP HANA Cloud と AWS PrivateLink の重要なユースケースは、AWS 上でデータプラットフォームを構築し、SAP HANA Cloud データを分析エコシステムに統合するケースです。AWS データプラットフォーム内で SAP HANA Cloud データにアクセスするには、主に2つの方法があります。AWS Glue ETL ジョブを使用してデータを抽出しAmazon S3 にロードする方法、またはフェデレーションクエリに Amazon Athena SAP HANA コネクタを使用する方法です。両方のアプローチには、AWS サービスと SAP HANA Cloud 間の安全で信頼性の高い接続が必要です。 これらのデータ統合パターンを実装する際、機密ビジネスデータがシステム間で転送されるため、セキュリティが重要になります。図4は、AWS PrivateLinkが必要なセキュアな接続レイヤーを提供することを示しています。AWS サービス（AWS Glue や Amazon Athena など）と SAP HANA Cloud 間のすべてのデータ転送とクエリがプライベートネットワークチャネルを介して行われ、パブリックインターネットへの通信を介さず、エンタープライズデータ統合シナリオの厳格なセキュリティ要件を満たします。 図4：セキュアなデータプラットフォーム統合：SAP HANA Cloud と AWS サービス AWS PrivateLink を使用した SAP HANA Cloud の設定方法 ユースケース 1 のエンタープライズグレードの SAP HANA Cloud アクセスの設定手順を説明します。このブログでは、設定について SAP HANA Cloud 管理ガイド を参照しました。この設定は SAP BTP 有料ティアアカウントで利用可能です。このブログ執筆時点では、データレイクインスタンス用の SAP HANA Cloud PrivateLink はAWS でのみ利用可能であり、 SAP HANA Cloud PrivateLink ドキュメント に記載されているように、リージョン内の接続のみをサポートしています。以下は設定手順の概要です。 SAP HANA Cloud で AWS PrivateLink Endpoint ID を有効化 AWS VPC で VPC エンドポイントを設定 AWS VPC エンドポイントを HANA Cloud インスタンスの許可リストに追加 Amazon Route53 でプライベートホストゾーンを設定 VPC 内から HANA Cloud へのプライベートルーティングをテスト インバウンド DNS クエリ転送用のリゾルバーを設定（RISE またはオンプレミスネットワークでの使用例1でのみ必要） 各ステップの詳細は以下の通りです。さらなるステップバイステップガイダンスについては、 このワークショップ のラボを参照してください。 1. SAP HANA Cloud で AWS PrivateLink Endpoint ID を有効化 SAP HANA Cloud の管理画面で、設定したい HANA Cloud インスタンスを選択し、 View Configuration をクリックします。 図5：SAP HANA Cloud – 設定を表示 接続タブで、AWS PrivateLink Endpoint ID を有効にするボタンをオンにします。これにより、AWS VPC への接続を設定するための PrivateLink Endpoint ID を取得できます。 許可する接続 で、「この BTP リージョンの Cloud Foundry からの IP アドレスのみを許可」または「特定の IP アドレスと IP 範囲を許可（BTP の Cloud Foundry に加えて）」を選択して、すべてのトラフィックがプライベート接続を通過するように制御します。 図6：SAP HANA Cloud – 接続 2. AWS VPC で VPCエンドポイントを設定 このステップでは、AWS VPC で VPC エンドポイントとセキュリティグループを設定して、Amazon VPC からこのエンドポイント経由で HANA Cloud へのアクセスを許可します。ご自身のAWS アカウントに VPC が設定されていない場合は、 Amazon VPC ドキュメント を参照して VPC を作成してください。SAP HANA Cloud インスタンスの設定タブで AWS PrivateLink Endpoint Service ID をコピーします。 図7: SAP HANA Cloud – PrivateLink Endpoint Service IDs AWS コンソールで、Amazon VPC サービスにアクセスし、 パートナーサービス用の VPC インターフェースエンドポイント を作成します。エンドポイント作成画面で、エンドポイントの名前を入力し、タイプに「PrivateLink Ready partner services」を選択します。サービス設定で、HANA Cloud インスタンスの AWS PrivateLink Endpoint Service ID をサービス名ボックスに入力します。次に、サービス確認ボタンをクリックします。 図 8: Amazon VPC – VPC エンドポイント作成 (1) 「サービス名が確認されました」という成功メッセージが表示されたら、ネットワーク設定を選択できるようになります。ネットワーク設定で、エンドポイントを作成したい VPC とアベイラビリティーゾーン、サブネットを選択します。SAP HANA Cloud インスタンスが複数の AZ で利用可能な場合、VPC で複数の AZ とサブネットを選択できます。 図 9: Amazon VPC – VPC エンドポイント作成 (2) このエンドポイントに、 https トラフィックを許可するセキュリティグループを割り当ててください。このブログでは、同 VPC 内のIP アドレス CIDR からの https トラフィックを許可するインバウンドルールを持つ https-from-sap-vpc という名前のセキュリティグループを作成しました。 図 10: Amazon VPC – VPC エンドポイント作成 (3) VPCエンドポイントが作成され、ステータスが「使用可能」になったら、エンドポイントの詳細ページからエンドポイント ID をコピーしてください。この ID は、次のステップで HANA Cloud の設定に使用します。DNS ネームをコピーして、後で Route 53 での DNS 設定時に使用します。プライベート IPv4 アドレスをメモしておいてください。これは、プライベートルーティングをテストする最後のステップで確認することができます。 図 11: Amazon VPC – VPC エンドポイントの確認 3. Amazon VPC エンドポイントを HANA Cloud インスタンスの許可リストに追加 HANA Cloud 管理画面に戻り、HANA Cloud インスタンスの設定を開きます。接続設定画面で、作成した VPC エンドポイント ID を許可リストに追加します。これにより、先ほどの VPC から作成された VPC エンドポイントで HANA Cloud PrivateLink エンドポイントサービスに接続できるようになります。 Figure 12: SAP HANA Cloud – VPC エンドポイント ID 許可 4. Amazon Route53 でプライベートホストゾーンを設定 このステップでは、VPC 用の Amazon Route 53 のプライベートホストゾーンを設定し、HANA Cloud インスタンスへのトラフィックを VPC エンドポイントに向ける DNS レコードを作成します。SAP HANA Cloud 接続の詳細から、SQL エンドポイントアドレスとランドスケープアドレスを確認します。Route 53 DNS 設定と接続テストで使用するため、これらのアドレスをメモしてください。 図 13: SAP HANA Cloud – 接続情報確認 Amazon Route 53 ホストゾーン設定で、以下のように値を設定します。 – ドメイン名として HANA Cloud ランドスケープ名を入力 – タイプとしてプライベートホストゾーンを選択 – ホストゾーンを VPC に関連付けるために VPC ID を選択 次に、ホストゾーンの作成ボタンをクリックします。 図 14: Amazon Route 53 – ホストゾーン作成 作成されたホストゾーン画面で、すべての HANA Cloud へのトラフィックを VPC エンドポイントにルーティングする新しい DNS レコードを作成します。 図 15: Amazon Route 53 – DNS レコード作成 5. VPC 内から HANA Cloud へのプライベートルーティングをテスト 設定完了後、VPC 内の EC2 インスタンスから dig または nslookup コマンドを実行して、HANA Cloud インスタンスへのトラフィックが VPC エンドポイントのプライベート IP アドレスに向かっていることを確認します。HANA Cloud エンドポイント URL でこれらのコマンドを実行すると、VPC エンドポイントのプライベート IP アドレスが応答されます。 図 16: コマンドでプライベートルーティングを確認 hdbsql コマンドで HANA Cloud エンドポイントへのデータベース接続を確認します。 図 17: hdbsql コマンドでデータベース接続を確認 6. インバウンド DNS クエリ転送用のリゾルバーを設定（RISE またはオンプレミスネットワークでのユースケース 1 でのみ必要） Route 53 プライベートホストゾーンは AWS アカウントの VPC 内に設定されているため、この VPC からのトラフィックにのみ影響します。ユースケース 1 で、RISE またはオンプレミスネットワークから HANA Cloud へのトラフィックも VPC エンドポイントを通過させたい場合は、 Route 53 インバウンドリゾルバー を使用し、ネットワークからこのリゾルバーに DNS を転送する必要があります。 詳細な手順は Route 53 ドキュメント を参照してください。下記の画面は、VPC 内に作成されたインバウンドエンドポイントのサンプルで、2 つのサブネットに 2 つのプライベートIPアドレスが割り当てられています。これらの IP アドレスは、RISE やオンプレミスネットワークでの DNS 設定に使用することができます。 図 18: Amazon Route 53 – インバウンドリゾルバー 高可用性 AWS PrivateLink の高可用性アーキテクチャは、複数のアベイラビリティーゾーン（ AZ ）を通じて堅牢で回復力のある接続を提供し、重要なビジネス運用のための継続的なサービス可用性を確保します。図 19 は、複数の AZ にまたがるエンドポイントネットワークインターフェースで AWS PrivateLink を実装することで、自動フェイルオーバー機能を実現し、ネットワークアーキテクチャにおける単一障害点を排除できることを示しています。この分散設計により、ある AZ が使用不可能になった場合でも、トラフィックは自動的に正常なエンドポイントにルーティングされ、アプリケーションやサービスへのシームレスな接続が維持されます。 これにより、アプリケーションの信頼性が向上し、ダウンタイムのリスクが軽減され、パフォーマンスが安定するとともに、プライベート接続のセキュリティ上の利点も得られます。さらに、AWS PrivateLink と Amazon Route 53 DNS サービスとの統合により、インテリジェントなルーティングとヘルスチェックが可能となり、ソリューション全体の可用性と耐障害性が向上します。この包括的な高可用性の実装により、セキュアでプライベートなネットワーク通信を維持しながら、厳格なビジネス継続性要件を満たすことができます。 以下のアーキテクチャは、Network Load Balancer を通じて 2 つの AZ に跨って HA がどのように機能するかを説明しています。 図19：高可用性を備えた AWS PrivateLink 価格例 このブログの公開時点では、SAP HANA Cloud で AWS PrivateLink を有効にする際、SAP BTP で追加料金は発生しません。SAP が Network Load Balancer の実装と有効化を実施します。ご自身の AWS アカウントで作成されたリソースに対してのみ課金されます。 例えば、高可用性ありとなしでのお客様の AWS アカウントでの AWS PrivateLink のコストを比較してみましょう。両方のオプションは、この AWS 料金計算ツールリンク にあります。 図20: 料金の例 次のステップ AWS PrivateLink の詳細については、AWS ドキュメント 「AWS PrivateLink とは？」 、 「AWS PrivateLink を使用して VPC をサービスに接続する」 、およびAWSホワイトペーパー 「AWS PrivateLink」 を参照してください。 同様に、詳細については SAP HANA Cloud オンラインドキュメント と  SAP HANA Cloud データベース管理ガイド を参照してください。 AWS アカウントチームと AWS サポートチャネルに加えて、AWS コミュニティ向けの Q&A 体験である re:Post を開始しました。AWS for SAP ソリューションアーキテクチャチームは、お客様とパートナーを支援するために回答できる議論と質問について、AWS for SAP トピックを定期的に監視しています。質問がサポート関連でない場合は、re:Post での議論に参加し、コミュニティの知識ベースに貢献することを検討してください。 クレジット このブログへの貢献に対して、Derek Ewell、Ferry Mulyadi、Diego Lombardini、Eneko Bilbaoに感謝いたします。 翻訳は Specialist SA トゥアンが担当しました。原文は こちら です。

9 月 29 日週、SWE-Bench によって世界最高のコーディングモデルと評価されている Anthropic の Claude Sonnet 4.5 が、 Amazon Q コマンドラインインターフェイス (CLI) と Kiro でご利用いただけるようになりました。このことに高揚感を覚えている理由は 2 つあります: まず、私は数週間前に世界中のお客様と 4 日間にわたって集中的に AI 支援開発ワークショップを開催し、 Amazon Q CLI がデベロッパーの生産性をいかに向上させるかを実際に体験しました。ワークショップ中、お客様は Amazon Q CLI を使用して 1 日でアプリケーションに新しい特徴量を追加することができました。これは従来であれば少なくとも 2 週間はかかっていた作業です。Amazon Q CLI で Anthropic の Claude Sonnet 4.5 が使用できるようになることで、デベロッパーの生産性がさらに向上すると確信しています。 2 つ目として、私は AWS re:Invent 2025 でのコードトークの準備を始めました。このコードトークでは、私と共同講演者が Kiro を使用してレガシーコードベースをモダナイズするライブコーディングを行います。Kiro で Anthropic の Claude Sonnet 4.5 を使用してライブデモを作成するのが待ちきれません。このデモや、クラウドと AI に関する 1,000 を超える他のセッションをご覧になりたい方は、12 月 1 日から 5 日までラスベガスで開催される AWS re:Invent 2025 にぜひご参加ください。 9 月 29 日週のリリース 私が注目したリリースをいくつかご紹介します。 Amazon Bedrock で Claude Sonnet 4.5 が使用可能に – コーディングと複雑なエージェントに最適な、Anthropic の最もインテリジェントなモデルが、Amazon Bedrock でご利用いただけるようになりました。Amazon Bedrock で Claude Sonnet 4.5 を利用することで、デベロッパーは、基盤モデル (FM) 用の統合 API を提供するだけでなく、セキュリティと最適化を実現するためのエンタープライズグレードのツールによってデータを完全に制御できるようにする、フルマネージドサービスにアクセスできます。 AWS Outposts が Dell および HPE とのサードパーティーストレージ統合をサポート – AWS Outposts のサードパーティーストレージ統合に、 Dell PowerStore および HPE Alletra Storage MP B10000 システムが含まれるようになりました。これらは、 NetApp オンプレミスエンタープライズストレージアレイ および Pure Storage FlashArray との既存の統合リストに加わりました。この統合には、主に 3 つの目的があります。1 つ目は、お客様が既存のストレージインフラストラクチャを維持しながら VMware ワークロードを AWS に移行するのをサポートすることです。2 つ目は、お客様が AWS サービスを利用しながらデータをオンプレミスに保持することで、厳格なデータレジデンシー要件を満たすのをサポートすることです。3 つ目として、この統合により、お客様は、AWS ツールを通じてサードパーティーストレージアレイとともに AWS Outposts を利用できます。 Amazon ECS マネージドインスタンスが利用可能に – コンテナ化されたアプリケーション向けの Amazon ECS マネージドインスタンスは、Amazon ECS 向けの新しいフルマネージドコンピューティングオプションであり、インフラストラクチャ管理のオーバーヘッドを排除しながら、Amazon EC2 の全機能を使用できるように設計されています。ECS マネージドインスタンスは、ワークロードを迅速に起動およびスケールするとともに、パフォーマンスを改善し、総保有コストを削減するのに役立ちます。 Amazon CloudWatch でアプリケーションマップの一般提供を開始 – Amazon CloudWatch は、設定とその関係に基づいてサービスを自動的に検出し、グループに整理することで、大規模な分散アプリケーションをモニタリングするのをサポートします。この新しいアプリケーションパフォーマンスモニタリング (APM) 機能を使用すると、分散アプリケーションのトラブルシューティング時に、どのアプリケーションと依存関係に重点を置くべきかを迅速に視覚化できます。 Amazon Bedrock AgentCore モデルコンテキストプロトコル (MCP) サーバーが使用可能に – ランタイム、ゲートウェイ統合、ID 管理、エージェントメモリのサポートが組み込まれた AgentCore MCP サーバーは、Bedrock AgentCore と互換性のあるコンポーネントの作成を高速化するために特別に構築されています。AgentCore MCP サーバーは、ラピッドプロトタイピング、本番 AI ソリューション、またはエージェントインフラストラクチャのスケールに使用できます。 その他のアップデート 以下では、私が興味深いと思った他のニュースやブログ記事をいくつかご紹介します: AWS ビルダー ID が「Google でログイン」をサポート –「Google でログイン」を使用して AWS ビルダー ID を作成できるようになりました。AWS ビルダー ID は、Kiro、AWS Builder Center、AWS トレーニングと認定、AWS re:Post、AWS スタートアップなどの AWS アプリケーションへのアクセスを提供する個人プロファイルです。 AWS API MCP サーバー v1.0.0 リリース – AWS API MCP サーバーは、AI アシスタントと AWS サービスの間のブリッジとして機能し、構文的に正しい CLI コマンドを作成して実行することで、基盤モデルが自然言語を通じてあらゆる AWS API とインタラクションできるようにします。AWS API MCP サーバーはオープンソースであり、 AWS ラボ GitHub リポジトリ で現在入手可能です。 AWS Knowledge MCP サーバーの一般提供を開始 – AWS Knowledge サーバーは、AI エージェントと MCP クライアントに、ドキュメント、ブログ記事、新機能のお知らせ、Well-Architected ベストプラクティスなどの信頼できる情報を LLM 互換形式で提供します。このリリースでは、AWS API と CloudFormation のリソースが利用できるリージョンに関する情報もサーバーに含まれます。 AWS Transform で VMware ネットワークオートメーションのために Terraform が使用可能に – AWS Transform は、VMware 環境からネットワークインフラストラクチャコードを自動的に生成するための追加オプションとして Terraform を提供するようになりました。このサービスは、ソースネットワーク定義を再使用可能な Terraform モジュールに変換し、現在の AWS CloudFormation と AWS Cloud Development Kit (CDK) のサポートを補完します。 近日開催予定の AWS イベント カレンダーを確認して、近日開催予定の AWS イベントにサインアップしましょう。 AWS AI Agent Global Hackathon – AWS の強力な生成 AI スタックを掘り下げて、目を見張るようなすばらしいソリューションを創り出すチャンスです。9 月 8 日から 10 月 20 日までの期間、AWS の AI サービススイートを使用して AI エージェントを作成し、45,000 USD を超える賞金と独占的な市場参入の機会の獲得に向けて競い合いましょう。 AWS Gen AI Loft – 特別セッションで AWS の AI 製品とサービスについて学び、業界をリードするエキスパートと交流して、投資家や同業者との有益なネットワーキングの機会を得ることができます。最寄りの都市でご登録ください: パリ (10 月 7 日～21 日)、 ロンドン (10 月 13 日～21 日)、 テルアビブ (11 月 11 日～19 日)。 AWS Community Days – 世界中の AWS ユーザーや業界リーダーによる技術的なディスカッション、ワークショップ、ハンズオンラボを特徴とする、コミュニティ主導のカンファレンスにぜひご参加ください: ミュンヘン (10 月 7 日)、 ブダペスト (10 月 16 日)。 今後開催されるすべての AWS イベント と AWS スタートアップイベント をご覧いただけます。 10 月 6 日週のニュースは以上です。10 月 13 日週にお届けする次回の Weekly Roundup もお楽しみに! – Prasad 原文は こちら です。

9 月 30 日、Amazon ECS マネージドインスタンスを発表しました。これは Amazon Elastic Container Service (Amazon ECS) の新しいコンピューティングオプションです。開発者はインフラストラクチャ管理の責任を Amazon Web Services (AWS) にオフロードしながら、 Amazon Elastic Compute Cloud (Amazon EC2) の全機能を使用できるようになります。この新しいサービスは、インフラストラクチャのオフロードによる運用のシンプルさと Amazon EC2 の柔軟性および制御を組み合わせたものです。つまり、お客様は総保有コスト (TCO) を削減し、AWS のベストプラクティスを維持しながら、イノベーションを推進するアプリケーションの構築に集中することができます。 弊社では、コンテナ化されたワークロードを実行しているお客様から、サーバーレスのシンプルさとセルフマネージド EC2 インスタンスの柔軟性を組み合わせたいというご要望をいただいていました。サーバーレスオプションは優れた汎用ソリューションを提供しますが、アプリケーションによっては GPU アクセラレーション、特定の CPU アーキテクチャ、またはネットワークパフォーマンスの強化など、特定のコンピューティング機能が必要となります。さらに、EC2 料金オプションを通じて既に Amazon EC2 キャパシティに投資してくださったお客様は、これらのコミットメントをサーバーレスサービスで十分に活用することができませんでした。 Amazon ECS マネージドインスタンスは、さまざまな EC2 インスタンスタイプと AWS サービスとの密な統合をサポートする、フルマネージドのコンテナコンピューティング環境を提供します。デフォルトでは、ワークロードに最適なコストの EC2 インスタンスが自動的に選択されますが、必要に応じて特定のインスタンス属性またはタイプを指定できます。AWS がプロビジョニング、スケーリング、セキュリティパッチ処理、コスト最適化など、インフラストラクチャ管理のすべての側面を処理するため、お客様はアプリケーションの構築と実行に集中することが可能です。 試してみましょう 新しい Amazon ECS クラスターを作成する AWS マネジメントコンソール のエクスペリエンスを見てみると、ECS マネージドインスタンスを使用するための新しいオプションだということがわかります。それでは、すべての新しいオプションについて簡単に見ていきましょう。 [Fargate とマネージドインスタンス] を選択すると、2 つのオプションが表示されます。 [ECS デフォルトを使用] を選択すると、Amazon ECS は保留中のタスクをグループ化して汎用インスタンスタイプを選択し、コストと耐障害性のメトリクスに基づいて最適なインスタンスタイプを選択します。これが最もわかりやすい、お勧めの開始方法です。 [カスタムを使用 – 詳細] を選択すると、Amazon ECS が使用するインスタンスの属性をファインチューニングできる追加の設定パラメータが開きます。 デフォルトでは、 CPU と メモリ は属性として表示されますが、さらに 20 個の属性から選択し、Amazon ECS がアクセスできる使用可能なインスタンスタイプのリストを引き続きフィルタリングすることができます。 属性を選択すると、選択に一致するすべてのインスタンスタイプのリストが表示されます。 ここから、通常どおり ECS クラスターを作成できます。Amazon ECS は、前のステップで定義した属性と基準に基づき、私に代わってインスタンスをプロビジョニングします。 Amazon ECS マネージドインスタンスの主な特徴量 Amazon ECS マネージドインスタンスでは、AWS がインフラストラクチャ管理の全責任を負い、インスタンスのプロビジョニング、スケーリング、メンテナンスのすべての側面を処理します。これには、14 日ごとに開始される定期的なセキュリティパッチの実装 (インスタンスの Connection Draining により、インスタンスの実際の存続期間が長くなる場合があります) や、アプリケーションの中断を最小限に抑えるために Amazon EC2 イベントウィンドウを使用してメンテナンスウィンドウをスケジュールする機能が含まれます。 このサービスでは、インスタンスタイプを非常に柔軟に選択できます。デフォルトではコスト最適化されたインスタンスタイプが自動的に選択されますが、ワークロードにおいて特定の機能が必要な場合、必要なインスタンス属性を指定することができます。これには GPU アクセラレーション、CPU アーキテクチャ、ネットワークパフォーマンス要件のオプションが含まれており、コンピューティング環境を正確に制御できます。 Amazon ECS マネージドインスタンスはコストを最適化するために、必要に応じて複数のタスクをより大きなインスタンスに自動的に割り当てることにより、リソースの使用率をインテリジェントに管理します。このサービスはタスク配置を継続的に監視および最適化し、ワークロードを少数のインスタンスに統合してアイドル (空の) 状態のインスタンスを枯渇させ、利用および終了することで、コンテナ化されたアプリケーションの可用性とコスト効率の両方を高めます。 既存の AWS サービス、特に EC2 料金オプションなどの Amazon EC2 特徴量との統合はシームレスです。この密な統合により、フルマネージドサービスの運用のシンプルさを維持しながら、既存のキャパシティ投資を最大限に活用することができます。 Amazon ECS マネージドインスタンスでは、引き続きセキュリティが最優先事項です。このサービスは、専用のコンテナオペレーティングシステムである Bottlerocket 上で動作し、自動化されたセキュリティパッチとアップデートを通じてお客様のセキュリティ体制を維持します。Bottlerocket OS イメージに適用されたすべてのアップデートとパッチは、 Bottlerocket のウェブサイト で確認できます。この包括的なセキュリティへのアプローチにより、コンテナ化されたアプリケーションを安全かつ管理された環境で引き続き実行することができます。 今すぐご利用いただけます Amazon ECS マネージドインスタンスは現在、米国東部 (バージニア北部)、米国西部 (オレゴン)、欧州 (ダブリン)、アフリカ (ケープタウン)、アジアパシフィック (シンガポール)、アジアパシフィック (東京) の AWS リージョンでご利用いただけます。マネージドインスタンスは、AWS マネジメントコンソール、AWS コマンドラインインターフェイス (AWS CLI)、または AWS Cloud Development Kit (AWS CDK) や AWS CloudFormation などの Infrastructure as Code (IaC) ツールから使用を開始できます。使用する EC2 インスタンスの料金と、サービスの管理料金が請求されます。 Amazon ECS マネージドインスタンスの詳細については、 ドキュメント をご覧ください。コンテナインフラストラクチャの簡素化を今すぐ始めましょう。 原文は こちら です。

はじめに みなさんこんにちは、ソリューションアーキテクトの眞壽田（ますた）です。2025年9月18日に開催された「Vector SDV Symposium Japan 2025」にて、AWSのソリューションアーキテクトとして「SDV時代の車載ソフトウエア開発を支えるAWSソリューション」というテーマでセッションを担当させていただきました。Software-Defined Vehicle（SDV）の波が自動車産業を大きく変革している今、クラウドテクノロジーがどのように車載ソフトウェア開発の課題を解決し、イノベーションを加速させるのか。本セッションでは、仮想開発環境や仮想ECU技術を使ったテストの効率化まで、AWSが提供するソリューションについて紹介しました。 この記事では、セッションの内容を詳しく解説するとともに、SDV時代におけるクラウドの可能性について掘り下げていきたいと思います。 これまでのSDV事例のおさらい SDV時代を見据え、AWSを活用して車載ソフトウエア開発の効率化を目指した自動車メーカー様の事例は次の通りです。詳細はリンクやブログを参照頂ければと思います。 1. ステランティス　Virtual Engineering Workbench（VEW）2022年 youtube blog 2. BMW Operating System 9 2023年 link 3. 本田技研工業株式会社　Digital Proving Ground 2023年 youtube これらの事例に共通するAWSのソリューションを、次の章でじっくり紹介していきたいと思います。 SDV開発を支援するAWSのソリューション 自動車産業がソフトウェア定義車両（SDV）へと急速に進化する中、AWSは自動車メーカーが直面する複雑な課題に対して、包括的な支援フレームワークを提供しています。この図が示すように、AWSの支援は三つの主要な柱を中心に構成されています。 これらの柱に加え、AWSはデジタル人材の育成支援やパートナーとの連携を通じて、自動車メーカーのSDV開発を包括的にサポートしています。この統合的なアプローチにより、お客様は従来の開発モデルからソフトウェア中心の開発へとスムーズに移行し、次世代モビリティの創造に専念することができます。 自動車業界におけるオンプレミスの開発環境に対する課題 以下の例は、AWSがお客様からよく聞く課題をAWSの生成AIのサービス（ Amazon Bedrock ）でストーリー調に仕立てたものです。 ある自動車メーカーの制御ECU開発部門では100名以上のエンジニアがモデルベース開発（MBD）環境を使って制御ソフトウェアの開発に取り組んでいます。「開発環境の構築と維持が私たちの最大の頭痛の種なんです」とAさんは語ります。 「昨年、新たなプロジェクトが始まった時、各エンジニアの開発PC調達だけで数ヶ月を要しました。そして機材が到着した後も、必要なツールのインストールに数週間を費やしました。開発に必要なツール群は多岐にわたり、互換性の問題も頻発します。詳細なインストールマニュアルを整備する専任スタッフまで配置したのですが、それでも約2割のエンジニアが環境構築に失敗し、Q&A対応に追われました」とAさんは振り返ります。 「さらに、一度環境を構築できても問題は続きます。シミュレーションやテスト実行中はPCリソースが占有されるため、他の作業が事実上不可能になります。また社外エンジニアとの協業においては、セキュリティ上の制約から開発PC利用に制限がかかることも少なくありません。また、すべての開発PCに対するセキュリティパッチの適用にも膨大な時間を要します。静的解析やテスト、シミュレーションの実行にも長時間を要し、開発サイクル全体が遅延する要因となっていました」とAさんは説明します。 このような開発環境では、ソフトウエアの開発量が増大するSDV時代に対応することは難しくなります。そこでAWSは、従来のオンプレミスでの開発環境の課題解決のために、主に次の２つのソリューションを提供しています。 開発環境課題を解決するためのAWSソリューション ２選 1. Research and Engineering Studio on AWS (RES) RESに関する情報　 GitHub 　 AWS Document 　 AWS Blog 　 YouTube RESの特徴的な機能として、 専用ウェブポータルからデスクトップ環境を簡単に作成 できることが挙げられます。 各プロジェクトでデスクトップイメージを保存 し、チームメンバーがそれを必要に応じてデプロイできる柔軟性も備えています。さらに、共有データストアを活用した共同作業環境の構築や、既存のID管理インフラ（AWS Managed Microsoft AD）との統合も実現しています。 先ほどの車載ソフトウエア開発の例では、RESを導入することで彼らの課題を以下のように解決できます： 迅速な環境構築 : 専用ウェブポータルからデスクトップ環境を短時間で作成でき、数ヶ月かかっていたPC調達・環境構築のプロセスを大幅に短縮 環境の標準化と再利用 : プロジェクト毎にデスクトップイメージを保存し、チームメンバーが即座にデプロイできるため、環境構築の失敗によるQ&A対応の負担が限りなく軽減される 共同作業の効率化 : 共有データストアを活用した共同作業が可能となり、OEM、サプライヤーが所属するチームのコラボレーションが促進される セキュリティの強化と簡素化 : 既存のID管理インフラ（AWSマネージドAD）との統合により、社外エンジニアとの協業におけるセキュリティ課題が解決され、一元的なセキュリティ管理が可能 メンテナンス作業の軽減: セキュリティパッチを当てた開発環境をイメージとして保存することで、開発者は最新の環境をデプロイすることが可能 2. Virtual Engineering Workbench (VEW) ステランティスの事例で紹介したVirtual Engineering Workbenchは、AWSのソリューションとしても展開しています。 このソリューションは、前述のRESで提供する開発環境やシミュレーション環境だけではなく、特定の仮想ECUのイメージも管理することで、今まで評価ボードを調達しなければECUのテストができなかった機能テストや結合テストが、仮想環境で実現することを可能とします。ステランティスの事例では、Github actionsやArtifactoryを用いたDevOpS環境の構築と、そのWorkflowで作成したアーティファクトの仮想ECUのバイナリファイルを、専用線で接続したオンプレミスのHILS環境へ連携するユースケースも実現しています。ご興味のある方は、こちらの ブログ もご覧ください。 Shift Leftを実現する仮想ECU技術 車載ソフトウエア開発のV字モデルの開発プロセスでは、ECU間の結合テストがV字の右側（後半）で実施されることがありました。右側の段階で不具合が発見されると、開発の手戻りが大きくなり、コストや時間の増大につながっており、多くのお客様が仮想ECUに興味を持っていただいています。 1. AWS Graviton と ARM on ARM技術 AWSはARMアーキテクチャを採用したデータセンター向けLSIであるGravitonを自ら設計し、2015年にLSI設計会社のAnnapuruna Labsを完全子会社化することでその技術基盤を強化しました。特に自動車開発において重要な点として、 AWS Graviton は、ARMとの協力により、実際のECUで使用されるARMのCortex-A、Cortex-M、Cortex-Rシリーズの命令コードをAWS Graviton上でそのまま実行できる「ARM on ARM技術」を搭載しています。これにより、仮想ECUの環境を正確かつ効率的に構築することが可能となっています。 このARM on ARMの技術を活用したソリューションがAWS Marketplaceで公開されました。Corellium社が提供する Atlas Private Cloud です。 詳細は、 Marketplaceのページ をご覧頂ければと思いますが、このAtlas Private Cloudは、 AWS Graviton 4 c8g.metal24xl EC2インスタンス上で、32ビットと64ビットのArm Cortex A、R、MコアをベースにしたARM Virtual Hardware（AVH）を実行することができます。2025年10月現在、AWS Graviton 4 c8g.metal24xl １つのEC2インスタンス上で動作可能なAVHは、トータル80 core分で、１つのEC2インスタンス上で複数の仮想ECUを起動することが可能です。今まで、制御系ECUを仮想化する場合、x86上のEC2インスタンスでエミュレーターを動かしいるのが通常でしたが、GravitonとARM on ARM技術を利用したソリューションで解決できるようになるケースが期待できます。 例えば、2025年のAWS Summit JapanのAutomotiveデモブースでは、下記の構成でコックピットとパワートレインのECUを仮想化し、Autosar APのSOME/IPで接続するデモンストレーションを紹介しました（下の図）。③の仮想ECUのスタックでは、AWS Graviton EC2 + Corellium上で、Cortex-R82AEのVirtual Hardwareを動作させ、パワートレインのアプリケーションを動作させています。 2. QNX Hypervisor on AWS Blackberry社のQNXが、 QNX Hypervisor 2.2 をAWS Marketplaceから提供しています。2025年10月現在、AWS上でQNX Hypervisor 2.2を利用するには、Blackberry社と別途ライセンス契約が必要になります。ご興味がある方は、Blackberry社にお問い合わせ頂ければと思います。 QNX Hypervisor on AWS QNX Hypervisor 2.2 on AWSは、AWS Graviton EC2インスタンスである、c6g.metal, r6g.metal, m6g.metalインスタンスで稼働します。アプリケーションから周辺デバイスへのアクセスは、Hardware Abstraction Layer（HAL層）のVirtIO経由で行います。仮に、従来のアプリケーションを、QNX Hypervisor 2.2上で仮想化するには、そのアプリケーション内で、ハードウエアに依存した処理をVirtIOで分離させる必要があります。どのハードウエアへのアクセスを抽象化するかという点において、サポートするVirtIOのバージョンやQNXとのライセンス契約にも依存しますので、Blackberry社にお問い合わせ頂ければと思います。 QNX Hypervisor on AWSに関する情報は以下のブログでもまとめられています。 Elevating cluster software development with QNX Hypervisor on AWS おわりに このブログでは、SDV時代を支えるAWSソリューションとして、開発環境と検証環境の２点に絞って紹介しました。特に、開発環境の課題については多くのお客様が解決したい課題ではないかと思います。量産開始後も継続してソフトウエアのアップデートが本格化する将来、開発環境を必要に応じて伸縮自在に調整することが望まれ、クラウドベースのエコシステムを構築していくことは多くのお客様において急務となっています。このブログを読んでAWSの人と少しお話してみたいなと思われる読者様がいらっしゃいましたら、お近くのAWSのアカウントチームや AWS for Automotive （チャット）までご連絡下さいませ。 著者 眞壽田 英輝 (Masuta, Hideki) アマゾン ウェブ サービス ジャパン 合同会社 自動車製造領域のお客様を支援するシニアソリューションアーキテクト。長年乗っていた車を最近買い替えたところ、車載ソフトウェアの目覚ましい進化に驚かされる日々を過ごしています。今後さらに高度な運転支援システムが普及することで、交通死亡事故ゼロの社会へと一歩ずつ近づいていくでしょう。そのような未来の実現に貢献すべく、自動車産業のお客様のイノベーションを技術面からバックアップしています。

イベント概要 AWS は Amazon の流通小売事業における知見と経験をもとにソリューションを提供しており、流通小売・消費財業界におけるイノベーションのカギとして、「カスタマーエンゲージメント」「デジタル コマース」「インテリジェント・サプライチェーン」「マーチャンダイジング & プランニング」「スマートストア」の 5 つのテーマを重視しています。 本イベントでは、この 5 つのテーマから、特に「カスタマーエンゲージメント」「デジタル コマース」 「スマートストア」の 3 つのテーマにフォーカスをして、AWS のテクノロジー、専門知識を活用して提供しているソリューションプロバイダーから業界に固有の課題と機会に応えるサービスやベストプラクティスをご紹介します。 「イノベーションを加速させたいが、スピードや人材が課題」といった状況でもすぐに活用できるソリューションを学び、展示ブースで製品デモをご覧いただけるほか、ソリューションプロバイダー各社と個別にご相談できる機会も提供いたします。 日時：2025 年 11 月 25 日（火）16:00–19:00（15:30 受付開始） 場所：AWS 目黒オフィス 目黒セントラルスクエア 21 階（東京都品川区上大崎 3-1-1） 主催：アマゾン ウェブ サービス ジャパン合同会社 参加費：無料（要事前申込） 参加申込：こちらの お申込みフォーム からお申込みください。 展示テーマと出展企業 「カスタマーエンゲージメント」 カスタマー 360° によって顧客セグメントの関係性や特徴、顧客生涯価値を理解し、CRM、顧客データプラットフォーム、コンタクトセンター DX など、データ主導のインサイトによるカスタマーエンゲージメントの促進に役立つソリューションをご紹介します。 ＜出展企業（アルファベット順）＞ Amplitude Analytics 合同会社 Braze 株式会社 株式会社電通デジタル 株式会社サーバーワークス トレジャーデータ株式会社 「デジタルコマース」 生成 AI を利用した魅力的なサイトや、俊敏なコマース基盤など、デジタルコマースソリューションへの投資は不可欠です。デジタルコマースのイノベーションを加速し、あらゆるチャネルでカスタマーエクスペリエンスを高めるためのソリューションをご紹介します。 ＜出展企業（アルファベット順）＞ アジアクエスト株式会社 Contentsquare Japan 合同会社 「スマート ストア」 小売業に新たな収益の柱をもたらすことが期待される店舗内の先進ソリューションや、顧客接点の可能性を広げる POS データ活用、店舗省人化に応える最新のテクノロジーなどをご紹介します。 ＜出展企業（アルファベット順）＞ フォージビジョン株式会社 富士ソフト株式会社 株式会社インテック ソニー株式会社 株式会社ティールテクノロジーズ 株式会社 USEN Camera Solutions 来場者特典 事前お申込みのうえ当日ご来場いただきましたお客様へ 先着 150 名限定 で、イベント特製のステンレスマグカップ（AWS ロゴ入り）をプレゼントいたします！ ※ 画像はイメージです。実物と異なる場合がございます。 当日はパートナー各社のブースにて、展示ブースで製品デモをご覧いただけるほか、ソリューションプロバイダー各社と個別にご相談できる機会も提供いたします この特別な機会をお見逃しなく。お申し込みは こちら から。 皆様のご参加を楽しみにお待ちしております！

本記事は、2025 年 9 月 17 日に公開された Supercharge your organization’s productivity with the Amazon Q Business browser extension を翻訳したものです。翻訳はテクニカルアカウントマネージャーの竹林聡が担当しました。 Amazon Q Business のような生成 AI ソリューションは、従業員の働き方を変革しています。あらゆる業界の組織が、意思決定プロセスを加速するために、ますます散在するデータから価値のある洞察を引き出すことができるこれらのツールを採用しています。しかし、生成 AI ツールの導入には課題もあります。 生成 AI ソリューションの実装において、2 つの障壁が浮上しています。1 つ目は、ユーザーが慣れ親しんだワークフローを放棄し、データを手動で AI アシスタントに転送して分析する必要に迫られることです。これにより、不要な手間が生じ、効果が得られるまでの時間が長くなってしまいます。2 つ目は、一般的に使用されているソフトウェアに生成 AI ツールが組み込まれていないため、従業員が AI で生産性を大幅に向上できる機会を見出すことが難しいという点です。 職場向けに特化した生成 AI アシスタントの Amazon Q Business が登場し、企業データやエンタープライズシステムにシームレスに接続することで、会話を行い、複雑な問題を解決し、アクションを実行できるようになりました。Amazon Q Business は、従業員に関連情報とアドバイスへの即時アクセスを提供し、タスクを効率化し、意思決定を加速し、職場での創造性とイノベーションを促進します。最近、Amazon Q Business でブラウザ拡張機能をリリースし、現在 Amazon Q Business の購読者 (Lite および Pro) が利用できるようになりました。Amazon Q Business ブラウザ拡張機能により、Amazon Q Business の機能を直接ブラウザで利用できるようになり、コンテキストを認識した生成 AI サポートを受け、日常のタスクに対する即時のサポートを得ることができます。 本ブログでは、チームが AI を活用したインサイトとサポートにスムーズにアクセスできるように、この解決策を企業に実装する方法をご紹介します。 Amazon Q Business ブラウザ拡張機能のユースケース Amazon Q Business ブラウザ拡張機能は、すべての Amazon 社員に展開されており、毎日数万人のユーザーの生産性を向上させています。このセクションでは、Amazon 社員が生産性を向上させるために Amazon Q Business ブラウザ拡張機能を使用している、最も効果的なユースケースをいくつかご紹介します。 Web コンテンツの分析 ビジネスチームと技術チームは、企業データ外にある各種レポート、競合分析、業界文書の情報を分析・統合して、インサイトと戦略を構築する必要があります。戦略に関する提言は、検証済みのデータソースと信頼できる業界情報に基づいていることを確認しなければなりません。さらに、複数のソースにまたがるパターンの特定は、時間がかかり複雑な作業です。Amazon Q Business ブラウザ拡張機能を使用することで、戦略担当者は人間の判断を活かしながら、信頼できる社内外のデータソースから数秒で業界のインサイトを生成し、トレンドを特定することができます。 以下のデモビデオをご覧ください: コンテンツ品質の向上 Amazon Q Business ブラウザ拡張機能は、生成AI アシスタントでは容易に利用できない背景情報を組み込むことができる独自の機能を提供します。Amazon Q Business ブラウザ拡張機能を使用すると、通常の生成AI アシスタントでは利用できない複数の異なるソースを問い合わせに含めることで、コンテンツの作成と品質向上が可能になります。さまざまなソースからのコンテンツをリアルタイムで確認し、Web ベースのスタイルガイドやベストプラクティスを組み込んでコンテンツ作成を加速することができます。 以下のデモビデオをご覧ください: ソリューションの概要 以下のセクションでは、組織で Amazon Q Business をすでに有効化している場合の Amazon Q Business ブラウザ拡張機能の使用開始方法について説明します。詳細については、 Amazon Q Business ブラウザ拡張機能の使用設定 をご覧ください。 前提条件 ブラウザ拡張機能をデプロイする前に、このセクションの前提条件の手順を完了してください。 Amazon Q Business アプリケーションの作成とユーザーのサブスクリプション設定 Amazon Q Business ブラウザ拡張機能は Amazon Q Business の機能であり、ブラウザ拡張機能を有効にする前に、お客様は Amazon Q Business アプリケーションを作成し、ユーザーのサブスクリプション登録を行う必要があります。Amazon Q Business の使用開始方法の詳細については、 Amazon Q Business の使用を開始する をご覧ください。 Amazon Q Business のWeb機能のセットアップ ブラウザ拡張機能は、Amazon Q Business の Web インターフェースクライアントを使用して、ユーザーの認証と Amazon Q Business の機能提供を行います。ブラウザ拡張機能を有効にする最初のステップは、Amazon Q Business の Web インターフェースを作成することです。すでにユーザー向けの Web インターフェースを作成している場合は、このステップをスキップできます。ただし、Amazon Q Business API を使用してカスタム Web インターフェースを開発している場合は、以下の手順に従って Amazon Q Business の Web インターフェースを作成してください： Amazon Q Business コンソールで、Amazon Q Business アプリケーションに移動します。 Web experience settings セクションには、Web エクスペリエンスがすでにデプロイされているかどうかが表示されます。Web エクスペリエンスがデプロイされていない場合、このセクションは空白で、「A web experience needs to be created before deploying.」というメッセージが表示されます。 アプリケーションの詳細ページの上部で、 Edit を選択します。 Outcome で、 Web experience を選択します。 Update を選択します。 この手順が完了するまでに数分かかる場合があります。 Web エクスペリエンスをデプロイすると、Amazon Q Business アプリケーションの詳細ページに、Web エクスペリエンスがホストされている URL が表示されます。この URL は後で使用するため保存しておいてください。 大規模言語モデルへのクエリ送信権限の付与 Amazon Q Business ブラウザ拡張機能は、ユーザーのプロンプトと共にWebページのコンテンツをファイル添付として渡すことで、ユーザーのWebページのコンテキストをクエリに含めることができます。ファイル添付機能は一般知識モードでのみ利用可能であるため、ブラウザ拡張機能の全機能を活用するには、Amazon Q Business の管理者がユーザーに対して大規模言語モデル (LLM) に直接クエリを送信する権限を付与する必要があります。この前提条件がない場合、ユーザーはブラウザ拡張機能を通じて自社の知識にのみアクセスでき、Webページのコンテンツについて Amazon Q Business に質問することはできません。 Amazon Q Business はユーザーの会話データを保存せず、クエリや会話を LLM のトレーニングに使用することはありません。会話はアプリケーション内に 30 日間のみ保存されます。以下のスクリーンショットに示すように、Amazon Q Business の Web インターフェースにアクセスし、ナビゲーションペインで Chat を選択することで、これらの会話を削除できます。 ユーザーが Amazon Q LLM に直接クエリを送信できるようにするには、以下の手順を実行します： Amazon Q Business コンソールで、アプリケーションに移動します。 ナビゲーションペインで Admin controls and guardrails を選択します。 Global controls セクションで、 Edit を選択します。  Allow end users to send queries directly to the LLM を選択します。   Save を選択します。 これでユーザー向けにブラウザ拡張機能を有効化する準備が整いました。 Amazon Q Business ブラウザ拡張機能の設定 ブラウザ拡張機能の前提条件を完了したので、以下の手順に従ってユーザー向けにブラウザ拡張機能を有効化してください： Amazon Q Business コンソールで、アプリケーションに移動します。 ナビゲーションペインの Enhancements から Integrations を選択します。 Browser extensions セクションで、 Edit を選択します。 有効にしたいブラウザ拡張機能のチェックボックスを選択します: Chromium チェックボックスは、Google Chrome と Microsoft Edge ブラウザをサポートする Chrome ストア拡張機能を有効にします。 Firefox チェックボックスは、Firefox 向けアドオンを有効にします。 それぞれの Learn more セクションにあるリンクを使用して、拡張機能の Chrome または Firefox ストアページを表示することもできます。 Save を選択します。 ユーザーは次回 Amazon Q Business の Web インターフェースにログインする際に、Amazon Q Business ブラウザ拡張機能のインストール手順が表示されます。まだの場合は、前のステップで取得した Web サービスの URL をユーザーと共有して、ブラウザ拡張機能をインストールするための手順に従えるようにしてください。 IAM フェデレーション認証を使用する場合の Amazon Q Business ブラウザ拡張機能の有効化 Amazon Q Business アプリケーションで外部のアイデンティティプロバイダー (IdP) を使用している場合、ユーザーがブラウザ拡張機能を使用できるようにするには、外部プロバイダーでブラウザ拡張機能を許可リストに追加する必要があります。ブラウザ拡張機能を有効にするには、IdP で以下の URL を許可リストに追加してください。 Chromium ブラウザ拡張機能 (Google Chrome と Microsoft Edge に対応) の場合は、 https://feihpdljijcgnokhfoibicengfiellbp.chromiumapp.org/ を使用します Mozilla Firefox ブラウザ拡張機能の場合は、 https://ba6e8e6e4fa44c1057cf5f26fba9b2e788dfc34f.extensions.allizom.org/ を使用します Amazon Q Business アプリケーションの認証ソリューションとして AWS IAM Identity Center を使用している場合は、前述の手順を実行する必要はありません。 ブラウザ拡張機能の使用開始 Web エクスペリエンス URL をユーザーと共有すると、ユーザーはそれを使用してブラウザ拡張機能のストアページを見つけ、ブラウザ拡張機能をインストールできます。ユーザーは以下の手順に従うことができます。 管理者から提供された Amazon Q Business の Web インターフェースにログインします。 管理者があなたのためにブラウザ拡張機能を有効にしたことを知らせるバナーが表示されます。 Install extension を選択します。 使用しているブラウザに応じて、リンクをクリックすると適切な Amazon Q Business ブラウザ拡張機能のストアページに移動します。 Add to Chrome を選択するか、お使いのブラウザに応じたインストールオプションを選択します。 拡張機能をインストールすると、ブラウザのツールバーの Extensions の下に表示されます。ピンアイコンを選択して、ブラウザ拡張機能をピン留めすることができます。 ブラウザ拡張機能を開くと、次のスクリーンショットのようなサイドペインが表示されます。開いているタブから正しい Web エクスペリエンス URL を自動的に検出し、サインインをサポートします。検出されない場合は、管理者から提供された Web エクスペリエンス URL を Amazon Q URL セクションに入力し、 Sign In  を選択してください。 サインインすれば、すぐに使用できます！生産性を向上させるためにこの拡張機能をどのように活用できるか、先ほどの Amazon のユースケースに関するセクションを参考にしてください。 ユーザーに代わって Amazon Q Business ブラウザ拡張機能をデプロイ 一部の管理者は、導入を効率化し加速させるために、ユーザーのブラウザに Amazon Q Business ブラウザ拡張機能を直接インストールすることを選択する場合があります。 企業は、さまざまなモバイルデバイス管理ソフトウェアを使用し、ブラウザポリシーに関する要件も異なります。 Amazon Q Business ブラウザ拡張機能を導入するには、以下のリソースを参照してください： Mozilla Firefox ポリシー設定 Google Chrome ポリシー設定 Microsoft Edge: ポリシー設定 リファレンスガイド エンタープライズ向け Amazon Q Business ブラウザ拡張機能のカスタマイズ 一部の管理者は、企業のニーズに合わせて Amazon Q Business ブラウザ拡張機能の外観と操作感をカスタマイズすることがあります。このセクションでは、拡張機能でサポートされているカスタマイズ機能と、ユーザーのブラウザで設定する対応するブラウザ拡張機能ポリシー値について説明します。 ブラウザ拡張機能のログインページにおける Amazon Q Business URL 入力の削除 ユーザーのサインイン時に Amazon Q Business Web エクスペリエンス URL の入力を求めたくない場合は、 Q_BIZ_BROWSER_EXTENSION_URL ポリシーにユーザー向けの適切な Amazon Q Business Web エクスペリエンス URL を設定することで、ユーザーに代わってデフォルト URL を設定できます。 ブラウザ拡張機能のツールバーアイコンの置き換え ブラウザー拡張機能のツールバーアイコンを変更するには、ユーザーに対して以下のブラウザーポリシーキーのいずれかまたは複数の値を、PNG や SVG 画像の URL、または有効な datauri に設定します。 Q_BIZ_BROWSER_EXTENSION_ICON_128 (必須) Q_BIZ_BROWSER_EXTENSION_ICON_16 (オプション) Q_BIZ_BROWSER_EXTENSION_ICON_32 (オプション) Q_BIZ_BROWSER_EXTENSION_ICON_48 (オプション) ブラウザ拡張機能ウィンドウのロゴまたはアイコンの置き換え ブラウザ拡張機能のウィンドウでロゴやアイコンを変更するには、 Q_BIZ_BROWSER_EXTENSION_LOGO ポリシーキーの値に、PNG または SVG 画像の URL、もしくはユーザー向けの有効な datauri を設定してください。 拡張機能のウィンドウに表示される名前の変更 ブラウザ拡張機能のウィンドウ内で「Amazon Q」、「Amazon Q Business」、「AWS」、「Amazon Web Services」への参照を任意の名前に置き換えるには、 Q_BIZ_BROWSER_EXTENSION_ENTERPRISE_NAME ポリシーキーの値にユーザー向けの新しい名前を設定します。 ブラウザ拡張機能のマウスオーバー時のテキストのタイトル変更 ブラウザ拡張機能にマウスオーバー時に表示されるテキストのタイトル (前のスクリーンショットで示した「Amazon Q Business has access to this site」) を変更するには、 Q_BIZ_BROWSER_EXTENSION_TITLE_NAME ポリシーをユーザーに適切な文字列に設定してください。 ブラウザ拡張機能のフッターにある AI ポリシーリンクの置き換え ブラウザ拡張機能のフッターにあるリンクテキストを置き換えるには、 Q_BIZ_BROWSER_EXTENSION_FOOTER_POLICY_NAME をユーザーに適した文字列に設定してください。 ブラウザ拡張機能のフッターにある URL を置き換えるには、 Q_BIZ_BROWSER_EXTENSION_FOOTER_POLICY_URL をユーザーにとって適切な URL に設定してください。 おめでとうございます！あなたとあなたの組織は、ブラウザ上の作業に対する 生成AI による支援を受ける準備が整いました。 リソースの削除 このセクションでは、ブラウザ拡張機能を無効化または削除する手順、およびユーザーのデプロイメントとカスタマイズを元に戻す手順について説明します。 Amazon Q Business コンソールを使用した Amazon Q Business ブラウザ拡張機能の無効化 Amazon Q Business ブラウザ拡張機能は、ユーザーがブラウザから拡張機能を削除する前でも、Amazon Q Business コンソールからいつでも無効化できます。手順は以下の通りです： Amazon Q Business コンソールで、 Applications に移動します。 ナビゲーションペインの Enhancements から Integrations を選択します。 Browser Extensions  セクションで、 Edit を選択します。 無効にしたいブラウザ拡張機能のチェックボックスを外します: Chromium チェックボックスを外すと、Google Chrome と Microsoft Edge ブラウザをサポートする Chrome ストア拡張機能が無効になります。 Firefox チェックボックスを外すと、Firefox ブラウザ用のアドオンが無効になります。 Save を選択します。 ユーザーに代わって Amazon Q Business ブラウザ拡張機能のデプロイを元に戻す 企業は、さまざまなモバイルデバイス管理ソフトウェアを使用し、ブラウザポリシーに関する要件も異なります。 ブラウザポリシー設定を更新してブラウザ拡張機能をデプロイした場合は、各ブラウザのポリシー設定に関するドキュメントに従って、これらのポリシーを削除する必要があります。 Mozilla Firefox ポリシー設定 Google Chrome ポリシー設定 Microsoft Edge: ポリシー設定 リファレンスガイド このブログで先述したように、ブラウザポリシーを変更して Amazon Q Business ブラウザ拡張機能をカスタマイズした場合、ブラウザポリシー設定から対応するポリシーエントリを削除するだけで、これらのカスタマイズを元に戻すことができます。 まとめ このブログでは、Amazon Q Business ブラウザ拡張機能を使用して、チームに AI を活用したインサイトとサポートをスムーズに提供する方法を紹介しました。このブラウザ拡張機能は、Lite サブスクリプションの一部として、US East (N. Virginia) および US West (Oregon) の AWS リージョンで Mozilla、Google Chrome、Microsoft Edge に対応しています。ブラウザ拡張機能の使用に追加コストはかかりません。 まず、Amazon Q Business コンソールにログインし、Amazon Q Business アプリケーション用のブラウザ拡張機能をセットアップします。詳細については、 Amazon Q Business ブラウザ拡張機能の使用設定 をご覧ください。 著者について Firaz Akmal は Amazon Q Business のシニアプロダクトマネージャーで、AWS に 8 年以上在籍しています。顧客の声を代弁し、AWS での検索や生成 AI のユースケースの変革を支援しています。仕事以外では、太平洋岸北西部の山々で過ごしたり、娘の視点を通して世界を体験することを楽しんでいます。 Abhinand Sukumar は、AWS の Amazon Q Business のシニアプロダクトマネージャーとして、革新的な生成 AI ソリューションのプロダクトビジョンとロードマップを推進しています。Abhinand は、ブラウザ拡張機能を含む統合を成功させるため、お客様とエンジニアリングチームと緊密に協力しています。教育、人工知能、デザイン思考に深い情熱を持ち、生成 AI エクスペリエンスと AI/ML 教育デバイスに関する専門知識を有しています。AWS に入社する前は、ネットワーク業界でエンベデッドソフトウェアエンジニアとして勤務し、テクノロジー分野で5-6年の経験があります。

本稿は、沖縄県の小売企業である株式会社サンエー（以降、サンエー）様の内製によるモダナイゼーションのお取り組みをご紹介する AWS との共同寄稿です（サンエー: 丸山氏、高原氏、宮良氏、AWS: 中島）。 はじめに サンエーは、1950 年創業、1970 年設立の沖縄県を拠点とする総合小売企業です。食料品、衣料品、家電、日用雑貨等の住居関連用品の小売業を主力事業とし、沖縄県内で78店舗（2025 年 10 月現在）の小売店舗および外食レストラン等のフランチャイズを展開しています。2025 年 6 月にはサンエー石垣シティをリニューアルオープンするなど、ビジネス拡大を進めています。また、2024 年度は過去最高益となる売上高 2,275 億円を達成しました。ビジネスが成長する中でシステムのモダナイゼーションへの機運も高まり、基幹システムのモダナイズを始められたサンエー様のこれまでの活動と AWS の支援を紹介します。 モダナイゼーションのきっかけ AWS 中島: モダナイゼーションの取り組みのきっかけを教えてください。 サンエー丸山氏: そうですね、きっかけをお伝えする前に、まずは弊社の内製化の歴史を少しご紹介させてください。もともとサンエーでは IBM AS/400 というメインフレームで社内システムを内製にて構築していました。それを約 10 年ほど前から、アプリケーションをスクラッチでつくり直しながら内製で AWS に移行し続けています。利用しているプログラミング言語がシェルスクリプト形式ということもあり、移行先のアーキテクチャは EC2 と EFS をメインで利用しています。DBを使わずにファイルを量産するプログラミング言語なので、どうしてもEFSの利用料が常に膨らんでいきます。モダナイゼーションの初期の検討では RDBMS を用いた IaaS での 3 層 Web を一度経由する案もありましたが、その構成の知見が社内に多いわけでもありませんでした。そのような背景もあり、今後、内製でスクラッチ開発するシステムでは、サーバレスを採用したいと考えていました。 AWS 中島: 2021 年に参加された ( ANGEL Dojo ) も同じような思いがあられたからでしょうか？ サンエー丸山氏: そうですね。サーバレスを知識としては知っていたものの、実際に作ってみたことがほとんどなくて。このイベントに参加して手触り感が欲しかったというのもあります。ただ、当時は今回のテーマのモダナイゼーションに本腰を入れていたというよりは、サーバレスという便利なものがある、AWSは EC2 と EFS だけじゃない、というのをチームメンバーや会社に知って欲しかったという意図の方が大きかったです。 AWS 中島: なるほど、ありがとうございます。では、モダナイゼーションに本腰を入れて活動を開始されたのはいつ頃からでしょうか？ サンエー丸山氏: 以前より検討はしていたのですが、2023年にパートナーの支援を受けながらポイントシステムをサーバレスで内製構築した経験がきっかけとなり、徐々に本格化し始めました。実際に組織体制を変更して、目にみえるかたちで活動し始めたのは 2024 年からだと思います。前述のコストの話だけではなく、これまでの技術スタックでは、社内からの開発要望に機能的に答えられないものが出てきたり、開発体験やシステム運用の課題に気づいたり、と、そういうものが積み重なってモダナイゼーションを本気で実行しないと先がないのではないかと思うようになりました。そういう意味ではトップダウンで発令されたとか、大きな事故があったとか、そういう大きなきっかけではないんです。でも、ビジネスをさらに成長させるためには必要だと感じていました。 モダナイゼーションへの一歩目を踏み出す AWS 中島: では、2024 年からの活動について教えてください。 サンエー丸山氏: サンエーのシステムのあり方は、今まで、世の中のベストプラクティスに則ったかたちがあまり取れていませんでした。ですので、自分たちのやり方で進める前にきちんと学んでみようと思ったんです。そこで出会ったのがストリームアラインドチームという考え方でした。マイクロサービスを技術として取り入れるだけでは成功せず、組織も変える必要があることを知ったんです。AWS との打ち合わせの中でも、そういうお話をしてくださいましたよね。 AWS 中島: はい、コンウェイの法則(※)などを含めてお話しさせていただきました。チームトポロジーの本を握りしめて会話したことを覚えています。その後、本当に組織を変えられたと聞いた時は正直驚きました。 ※ システム（広義に定義）を設計するあらゆる組織は、組織のコミュニケーション構造をコピーした構造を持つ設計を生み出す。 サンエー丸山氏: モダナイゼーションに必要なことはやろうと決めていましたので、上司に掛け合ってチームを再編しました。組織を変える目処がついた後に困ったのが EC2 + EFS からどういう形に変えていこうかということでした。サーバレスがいいなとは思っていたのですが、具体的にどういうかたちが良いのかについては不透明でした。社内エンジニアのスキルセットはバニラ (素の) html, js と sh をラップした有償製品のコマンドに偏っており、いわゆる Web アプリケーションフレームワークや汎用プログラミング言語に明るい人間もいない。そんな時、AWSからご提案をいただいたんです。 AWS 中島: 貴社を日々ご支援する中で、課題は広く難易度は高いが、それらが点になっており、うまく整理がついてないように感じました。そこで、1/デベロッパートランスフォーメーション (以降 DevTx) チームから Discovery ワークをご提供することによって課題の整理と短距離の目標を定義すること。2/内製メンバーで作れるようになるきっかけ作りのためにプロトタイピング (以降 Proto) チームと協業で開発してみること。3/協業の期間は短くそれだけで作れるようになるわけではないため、プロトタイピング後、実際の開発において伴走しながらスキルアップを支援してくれる AWS パートナーのご紹介。ここまでを 1 セットでご提案しました。 サンエー丸山氏: どこまでやれるのか不安もありましたが AWSの提案に乗ってみようと思いました。2024 年11月のキックオフ後、Discovery ワークを進める中で、コスト以外にも、開発テスト、運用、認証、UI など幅広い課題を整理することができました。また Proto の方をテックリードとして一緒に開発してみることで、サーバレス, REST, SPA + API, フロントエンド Framework, OSS の活用などの開発方法を実際に作りながら学ぶことができました。言語を全て TypeScript で統一したのもプロトタイピングの進め方として良かったと思います。様々な体験が得られましたが、ワークショップ後にモダナイゼーションへの投資を役員と合意することができたことはとても大きな成果でした。先述のとおり、モダナイゼーションはトップダウンで降りてきたものではないため、モダナイゼーションを進めるためには役員との合意が必須だったんです。役員合意が取れたのは 2025年3月のことでした。 図は プロトタイピングの成果物に対して DevTx チームと実施したリスクストーミングの一コマ AWS 中島: ここで、Discovery ワークとプロトタイピングにご参加いただいたメンバーの高原様と宮良様にご感想を聞いてみたいと思います。高原様いかがでしたか？ サンエー高原氏: 協業で開発したのは 2 週間という短期間でしたが、モダンな開発手法やツールに触れることができて非常に勉強になりました。Git の使い方や サーバレスに関する AWS のサービスについて実際に手を動かしながら学べたのは大きな収穫でした。TypeScript は フロントエンドでもバックエンドでも CDK でも使えることを体感したため、今後もしっかりと学習していく必要があると感じています。エラーメッセージを読む習慣やドキュメントを参照する姿勢は身についたので、これを継続していきたいと思います。チーム開発の楽しさも実感できました。モブプログラミングで他の人の考え方を知ることができたり、困った時にすぐに相談できる環境があったのは心強かったです。中島さんがライブラリの調査やドキュメント読みを実際にやってみせてくださったのが非常に参考になりました。本番開発に向けて、基礎的な部分をしっかりと固めて、チームにより貢献できるよう頑張りたいと思います。 AWS 中島: ありがとうございます。高原様はメンバーの中で IT 経験が一番少ない中でご参加くださいました。では、続いて宮良様、いかがでしょうか？ サンエー宮良氏: 2週間をとおして、一番の大きな変化は「調べる文化」が身についたことだと思います。既存の開発言語では調べても情報が少なく、誰かに聞くか、とりあえず書いてみるという文化でしたが、モダンな開発では豊富なドキュメントやコミュニティの情報があることを実感できました。技術的には、React の概念や TypeScript の型システムなど、既存の開発言語とはまったく異なる概念に苦戦し、従来の開発経験とのギャップが大きく、理解に時間がかかりました。ただ、何かを作る楽しさを久しぶりに感じることができたのは大きな収穫でした。コードの品質についても多くの気づきがありました。Proto 担当の和田さんからのレビューコメントで、命名規則や処理の順番、可読性の重要性を学びました。「動けばいい」から「他の人が読みやすいコード」を意識する必要があると強く感じました。本番開発に向けては、基礎的な概念の理解を深めることと、自分の理解を言語化する練習が必要だと思います。生成 AI に自分の理解が合っているか質問しながら学習を進めていきたいと思います。 AWS 中島: 宮良様ありがとうございます。宮良様は貴社独自の生成 AI プロンプト作成アプリの開発もしていただいているので、ぜひ基幹システムのモダナイゼーションでもご活躍いただきたいです。 基幹システム開発に向けて AWS 中島: それでは、Discovery ワーク・プロトタイピング後の活動について教えてください。 サンエー丸山氏: 現在、システムのモダナイゼーションに向けて社内の認証認可基盤を作り直しています。これは Discovery ワークで明らかになった認証認可の課題を解決してから、アプリケーション側をモダナイズするという方針にしたためです。認証認可基盤は AWS のパートナーに伴走いただきながら進めています。 AWS 中島: 今の活動において Discovery ワークやプロトタイピングの効果を感じていただけているでしょうか？ サンエー丸山氏: こちらを見てみてください。これは高原さんと宮良さんが パートナー企業と議論して書いたホワイトボードです。Discovery ワークやプロトタイピング後に 2 人が追加で学んだ部分もありますが、それでも EC2 と EFS の現行のアーキテクチャの説明もおぼつかなかった 2 人が、このようにホワイトボードにアーキテクチャを描き、パートナー企業と議論する姿を見ると、ご提案いただいた活動の効果を感じています。現在開発中の認証認可基盤が完成した後、アプリケーション側のモダナイズを実施する予定です。高原さんと宮良さんにはぜひこのプロジェクトを引っ張っていってもらいたいです。 最後に AWS 中島: 丸山様、高原様、宮良様、本日はありがとうございました。これからも是非 AWS と一緒にモダナイゼーションジャーニーを歩ませていただければと思っております。最後に我々アカウントチームへ今後期待することをお聞かせいただけないでしょうか？ サンエー丸山氏: AWSとの協業は、単なる技術導入に留まらず、私たちの開発文化そのものを変える大きなきっかけとなりました。深く感謝しています。 現在進めている基幹のモダナイゼーションは、その先に見据える AI 活用によるビジネス革新のための重要な布石です。この未踏の領域への挑戦においても、AWS には戦略的パートナーとして、最先端の知見と専門的な支援で私たちの成長を力強くリードしていただけることを期待しています。 AWS 中島: ありがとうございます。ちなみに今回、”序章” ということですが、次回があると思ってよろしいでしょうか？ サンエー丸山氏: そうですね。次回はモダナイズしたプロダクション環境がリリースされた後にまた寄稿させていただければと思います。 サンエー様 著者 丸山 海理 氏 高原 元来 氏 宮良 一輝 氏

デジタル資産決済により、迅速かつ低コストのピアツーピア取引が可能になります。 ブロックチェーンベースの決済システムは、従来の決済方法で企業が直面する主要な課題に対処します。 これには、高い処理手数料、キャッシュフローに影響を与える決済遅延、業務に影響を及ぼす複雑な国際取引などが含まれます。 この投稿では、ブロックチェーンベースのデジタル資産決済システムがどのようにコストと遅延を削減できるかを説明します。 USDC 、 PYUSD 、 USDG などのステーブルコインを例として、AWS 上でサーバーレス決済システムを構築する方法を紹介します。 このソリューションは、従来の決済方法に代わる低コストでスケーラブル、かつ分散型の選択肢を提供します。 実装は GitHub リポジトリ で公開されています。 この投稿は、デジタル資産決済ソリューションの技術的な概要を示すものであり、法的助言や規制上のガイダンスを意図したものではありません。 法的コンプライアンス、検証、確認の要件は管轄区域によって異なる場合があり、読者ご自身の責任です。 この投稿で説明されている決済ソリューションを実装または使用する前に、ご自身でデューデリジェンスを実施してください。 ブロックチェーンベースの決済のメリット デジタル資産決済を導入する企業には、魅力的なメリットがあります。 コスト管理 決済処理のオーバーヘッドの削減 決済効率 ブロックチェーンの確認後に資金にアクセスできます。正確なタイミングはネットワークによって異なります (数秒から数分) グローバル展開 複数の仲介業者を介さずに国境を越えた取引を実行し、為替手数料を排除します トランザクションの可視性 オンチェーン検証による完全なトランザクションの透明性により、監査の効率化 デジタル資産決済は、さまざまなステークホルダーにメリットをもたらします。 加盟店 – 高速で低手数料の決済により、EC （イーコマース）を効率化します。 金融機関 – 決済時間を短縮し、国際送金や資金管理を促進します。 共通のメリット – 通貨交換と決済処理の手数料を最小化します。 最終的に、デジタル資産決済は、マーチャントや金融機関が技術革新を進め、コストを最小化し、新たな機会を引き出すのに役立ちます。 ソリューション概要 このソリューションにより、企業は Ethereum を含む Ethereum Virtual Machine (EVM) 互換ネットワーク全体で、デジタル資産による消費者からの支払いを、完全な自動化と安全な資金処理で受け入れることができます。 テストネットとメインネット環境の両方に対応しています。 リポジトリ では、デジタル資産支払いソリューションをデプロイして使用する手順を順を追って説明しています。 このソリューションの主な機能は以下の通りです。 デジタル資産決済ソリューションの 3 つのコアコンポーネントについて、さらに詳しく見ていきましょう。 請求書ジェネレーター このコンポーネントを使用すると、請求書を生成し、顧客から直接支払いを受け付けることができます。 請求書ジェネレーターは以下の機能を提供します: 確定的な請求書生成 – 請求書ジェネレーターは、請求書とブロックチェーンアドレスの 1 対 1 のマッピングを容易にします。これにより、各支払いが対応する請求書に正しく紐付けられることが保証されます。このシステムは、 アトミックカウンター を Amazon DynamoDB に保存してウォレットインデックスを維持し、高い同時実行シナリオでもスレッドセーフなアドレス生成を維持します。 効率的な鍵管理 – BIP32 / BIP44 は、階層的決定性鍵導出関数を使用して、 AWS Secrets Manager に保存された単一のプライマリシードから多数の鍵パスを生成し、複数のアカウントとアドレスの構造化された管理を可能にします。 UI ですぐに使える出力 – 請求書ジェネレーターは、請求書の入金アドレスと Data URL 形式の Base64 エンコードされた QR コードの両方を返します。これは HTML の タグに直接埋め込むことができます。 セキュリティとプライバシーの強化 – 各顧客は一意の 1 回限りの支払いアドレスを受け取ります。これにより、アドレスの再利用を防ぎ、パブリックブロックチェーン上でユーザーのプライバシーを保護することができます。 簡素化された会計処理 – 合理化された追跡により、会計と監査が容易になります。 定期支払いのシナリオでは、安定した顧客識別子から支払いアドレスを導出するようにソリューションを拡張できます。 これにより、各顧客に対して一貫したウォレットアドレスが作成され、定期支払いが合理化され、顧客の許可リスト登録プロセスが簡素化されます。 支払いの自動検出 「The Watcher」は、自動的な更新情報とイベント駆動型通知による支払い状況の監視を可能にします。 自動支払い検出コンポーネントは、以下の機能を提供します。 最適化されたデータベースクエリ – DynamoDB グローバルセカンダリインデックス ( status-index ) を使用して、 pending 状態の請求書のみをクエリします。これにより、請求書の総量が増加してもクエリのパフォーマンスが維持され、DynamoDB の読み取り消費量が大幅に削減されます。 リアルタイム残高検証 – ETH および ERC-20 トークンの残高を請求書の金額と照合して検証します。 自動ステータス更新 – 十分な支払いが検出されると、請求書を自動的に paid としてマークします。(デフォルトでは、このソリューションはファイナリティやリオーグを考慮しません。より強力な保証が必要な場合は、Watcher の eth_getBalance に finalized ブロックタグを渡すことができます。) 即時通知 – 支払い確認時に Amazon SNS を通じて加盟店への通知をトリガーします。 資金照合 請求書の支払いを受け取った後、資金は安全な管理のために指定された財務ウォレット (できれば高度にセキュアなコールドウォレット) に自動的に移動されます。 これにより、数分以内にオフラインで支払いが安全に処理され、加盟店が選択したウォレットへの資金集約のための監査可能なメカニズムがサポートされます。 ファンド照合プロセスは、以下の機能を提供します。 DynamoDB Streams によるトリガー – フィルタリングされたストリームトリガーを通じて確認済みの支払いを検出します (ステータスが paid )。ネットワークの混雑や一時的なブロックチェーンの問題に対処するための組み込みメカニズムを備えています。 ガスの最適化 – コスト効率の高いトランザクションのために、ネットワークのガス価格を動的に計算します。 ガス補充メカニズム – 専用のホットウォレット「ガスタンク」が、ネットワークのネイティブトークン (例: ETH) の準備金を保持します。これは、ERC-20 インボイスを補充するためだけに使用され、最小限のガス料金で コールドストレージの金庫に集約できるようにします。 安全な転送 – 秘密鍵はメモリ内で決定論的に導出され、保存されません。これらは個々のインボイスからの転送を実行するために使用されます。これは Lambda 内で行われ、AWS は オペレーターによるアクセスはありません 。 ステータスの更新 – 正常に完了すると、インボイスのステータスを swept に更新します。 次の図は、ソリューションのアーキテクチャを示しています。 このアーキテクチャは、サーバーレスなデジタル資産決済処理の PoC （ Proof of Concept ）を目的としており、本番環境で使用できる状態ではありません。 セキュリティ、信頼性、コンプライアンス、監査可能性に関する本番環境の基準を満たすには、追加の機能強化が必要です。 以下のフローの各ステップの番号は、Ethereum ネットワーク上でのステーブルコイン決済を示しており、上記のアーキテクチャ図の番号に対応しています。 加盟店は、 Amazon API Gateway が提供する /create-invoice REST API へのリクエストを通じて、ステーブルコインのインボイスを作成します。これは API キーを使用して保護されています。 AWS Lambda 関数である Invoice Generator がトリガーされ、 AWS Secrets Manager からニーモニック シードフレーズ を取得します。シードフレーズは、インボイスに対応するキーペアを作成 (および復元) するために必要です。 Invoice Generator は Amazon DynamoDB のアトミックカウンターをインクリメントします。アトミックカウンターの値はインデックスを表します。これはシードフレーズと共に使用され、特定の支払いに対する 階層的決定性 (HD) ウォレットアドレスを決定論的に導出します。 Invoice Generator Lambda 関数は新しいインボイスを作成し、 status: pending として DynamoDB に保存します。データは AWS Key Management Service (AWS KMS) を使用して保管時に自動的に暗号化されます。 前のステップで生成された QR コードには、送金先アドレス、通貨、金額がエンコードされており、加盟店に返されます。加盟店は QR コードを顧客と共有します。顧客は、入金アドレスに適切な金額の資金を送信することで、ステーブルコインの支払いを行います。 Amazon EventBridge スケジュールを通じて、Watcher という Lambda 関数が毎分トリガーされます。Watcher は DynamoDB から保留中のインボイスを取得し、提供された RPC エンドポイントを通じて行われた支払いを確認します。支払いが到着した場合、インボイスを paid に更新します。 Watcher Lambda 関数は、 Amazon Simple Notification Service (Amazon SNS) を使用して、加盟店に支払い確認を送信します。 CryptoInvoices データベースで支払いが検出されると (ステータスが paid に遷移すると)、 Amazon DynamoDB Streams を使用してイベントが発行されます。これにより Lambda Sweeper 関数がトリガーされます。 Sweeper 関数は資金の集約トランザクションに必要なガスを計算し、これが ERC20 インボイスであるため Eth をリクエストします。 十分な Eth が利用可能になると、Sweeper 関数はインボイスに関連付けられたトークンをオフラインの保管用ウォレットに送信します。Sweeper 関数は、HD ウォレットのシードフレーズをリクエストし、トランザクションに署名するための秘密鍵を導出することでこれを行います。その後、インボイスは CryptoInvoices データベースで swept としてマークされます。資金の集約プロセス中にエラーが発生した場合、失敗がログに記録され、最大 3 回の再試行が行われます。 加盟店は、API Gateway を使用して公開された REST エンドポイントを通じてインボイスを管理できます (インボイスの現在のステータスを表示したり、保留中のインボイスをキャンセルしたりできます)。 支払い、支払い監視、資金の回収フローの詳細な図解については、 GitHub リポジトリ を参照してください。 まとめ このサーバーレスソリューションは、AWS 上でデジタル資産決済を処理するための安全で効率的、かつコスト効率の高いシステムを提供します。 AWS のサービスとブロックチェーン技術を活用することで、組織は決済処理コストを削減し、資金へのより迅速なアクセスを実現し、キャッシュフローを向上させ、グローバルに事業を展開できます。 本記事は、2025 年 10 月 2 日に公開された Processing digital asset payments on AWS を翻訳したものです。翻訳は Blockchain Prototyping Engineer の 深津颯騎 が担当しました。 GitHub で完全なコードを確認し、AWS 上で安全なサーバーレスデジタル資産決済ソリューションの構築を始めましょう。 著者について Simon Goldberg Simon は、AWS のブロックチェーン/Web3 スペシャリストソリューションアーキテクトです。仕事以外では、音楽制作、読書、クライミング、テニス、ハイキング、コンサート鑑賞、Web3 テクノロジーの研究を楽しんでいます。 David Dornseifer David は、AWS のブロックチェーンおよびコンフィデンシャルコンピュートアーキテクトです。彼は、お客様がエンドツーエンドのブロックチェーンおよびコンフィデンシャルコンピュートソリューションの設計、開発、スケーリングを支援することに注力しています。主な専門分野は、デジタル資産の保管と鍵管理ソリューションです。

このブログは 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 松本が翻訳しました。原文は こちら です。 <!-- '"` -->