Amazon Elastic Compute Cloud (Amazon EC2) メモリ最適化 R8i および R8i-flex インスタンス 、ならびに汎用 M8i および M8i-flex インスタンス のリリースに続き、カスタムインテル Xeon 6 プロセッサを搭載し、持続的なオールコア 3.9 GHz ターボ周波数と 2:1 のメモリ対 vCPU 比を備えた、AWS でのみ利用可能なコンピューティング最適化 C8i および C8i-flex インスタンス の一般提供の開始をお知らせします。これらのインスタンスは、クラウドにおける同等の Intel プロセッサの中でも最高のパフォーマンスと最速のメモリ帯域幅を提供します。 C8i および C8i-flex インスタンスは、 C7i および C7i-flex インスタンス と比較して、最大 15% 優れた料金パフォーマンスと 2.5 倍のメモリ帯域幅を提供します。C8i および C8i-flex インスタンスは、C7i および C7i-flex インスタンスと比較して、NGINX ウェブアプリケーションで最大 60%、AI 深層学習レコメンデーションモデルで最大 40%、Memcached ストアで 35% 高速です。 C8i および C8i-flex インスタンスは、ウェブサーバー、キャッシュ、Apache.Kafka、ElasticSearch、バッチ処理、分散分析、ハイパフォーマンスコンピューティング (HPC)、広告配信、高度にスケーラブルなマルチプレイヤーゲーム、動画エンコーディングなど、コンピューティングを多用するワークロードの実行に最適です。 他の第 8 世代インスタンスと同様、これらのインスタンスは新しい第 6 世代 AWS Nitro Card を使用しており、前世代のインスタンスと比較してネットワークと Amazon Elastic Block Storage (Amazon EBS) の帯域幅が最大 2 倍増加しています。また、ネットワークと Amazon EBS 帯域幅の間で 25% の割り当て調整を行う帯域幅設定にも対応しており、データベースのパフォーマンス、クエリ処理、ログ記録速度が向上します。 C8i インスタンス C8i インスタンスは、基盤となる物理ハードウェアへの専用アクセスを提供するベアメタルインスタンスを含め、最大 384 個の vCPU と 768 TB のメモリを提供します。これらのインスタンスは、CPU ベースの推論や、継続的に最大インスタンスサイズまたは高い CPU を必要とする動画ストリーミングなど、コンピューティングを多用するワークロードの実行に役立ちます。 C8i インスタンスの仕様は次のとおりです。 インスタンスサイズ vCPU メモリ (GiB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) c8i.large 2 4 最大 12.5 最大 10 c8i.xlarge 4 8 最大 12.5 最大 10 c8i.2xlarge 8 16 最大 15 最大 10 c8i.4xlarge 16 32 最大 15 最大 10 c8i.8xlarge 32 64 15 10 c8i.12xlarge 48 96 22.5 15 c8i.16xlarge 64 128 30 20 c8i.24xlarge 96 192 40 30 c8i.32xlarge 128 256 50 40 c8i.48xlarge 192 384 75 60 c8i.96xlarge 384 768 100 80 c8i.metal-48xl 192 384 75 60 c8i.metal-96xl 384 768 100 80 C8i-flex インスタンス C8i-flex インスタンスは、C8i インスタンスの低コスト版であり、5% 低い料金で 5% 優れた料金パフォーマンスを実現しています。これらのインスタンスは、最新世代のパフォーマンスから恩恵を享受できるにかかわらず、すべてのコンピューティングリソースを完全に活用していないワークロード向けに設計されています。これらのインスタンスは、95% の確率で最大 CPU パフォーマンスを発揮できます。 C8i-flex インスタンスの仕様は次のとおりです。 インスタンスサイズ vCPU メモリ (GiB) ネットワーク帯域幅 (Gbps) EBS 帯域幅 (Gbps) c8i-flex.large 2 4 最大 12.5 最大 10 c8i-flex.xlarge 4 8 最大 12.5 最大 10 c8i-flex.2xlarge 8 16 最大 15 最大 10 c8i-flex.4xlarge 16 32 最大 15 最大 10 c8i-flex.8xlarge 32 64 最大 15 最大 10 c8i-flex.12xlarge 48 96 最大 22.5 最大 15 c8i-flex.16xlarge 64 128 最大 30 最大 20 現在、旧世代のコンピューティング最適化インスタンスを使用している場合は、アプリケーションやワークロードに変更を加えることなく、C8i-flex インスタンスを採用できます。 今すぐご利用いただけます Amazon EC2 C8i および C8i-flex インスタンスは、現在、米国東部 (バージニア北部)、米国東部 (オハイオ)、米国西部 (オレゴン)、欧州 (スペイン) の AWS リージョン でご利用いただけます。C8i および C8i-flex インスタンスは、 オンデマンド 、 Savings Plan 、 スポットインスタンス として購入できます。C8i インスタンスは、 ハードウェア専有インスタンス および 専有ホスト での利用も可能です。詳細については、 Amazon EC2 の料金ページ をご覧ください。 Amazon EC2 コンソール で C8i および C8i-flex インスタンスをお試しください。詳細については、 Amazon EC2 C8i インスタンスのページ をご覧ください。また、 AWS re:Post for EC2 に、または通常の AWS サポートの連絡先を通じて、ぜひフィードバックをお寄せください。 – Channy 原文は こちら です。

10 月 6 日より、独自の AWS Key Management Service (AWS KMS) キーを使用して、 AWS IAM アイデンティティセンター の組織インスタンスに保存されているユーザー属性やグループ属性などの ID データを暗号化できるようになりました。 規制の厳しい業界で事業を展開している多くの組織は、暗号化キー管理を完全に制御する必要があります。アイデンティティセンターでは既に AWS 所有キーを使用して保管中のデータを暗号化していますが、監査やコンプライアンスのために独自の暗号化キーを管理する必要があるお客様もいます。 このリリースにより、 カスタマーマネージド KMS キー (CMK) を使用して、アイデンティティセンターの保管中の ID データを暗号化できるようになりました。CMK を使用すると、作成、ローテーション、削除など、キーのライフサイクルを完全に制御できます。 AWS Key Management Service (AWS KMS) キーポリシーと IAM ポリシーを使用して、キーへのきめ細かなアクセスコントロールを設定できるため、認可されたプリンシパルのみが暗号化されたデータにアクセスできるようにするのに役立ちます。起動時には、CMK は IAM アイデンティティセンターインスタンスと同じ AWS アカウントおよびリージョンに存在する必要があります。アイデンティティセンターと KMS の統合により、キーの使用状況を監査するための詳細な AWS CloudTrail ログが提供され、規制コンプライアンス要件を遵守するのに役立ちます。 アイデンティティセンターは、デプロイのニーズに合わせて、単一リージョンキーとマルチリージョンキーの両方をサポートしています。アイデンティティセンターインスタンスは現在単一のリージョンにのみデプロイできますが、会社のポリシーで単一リージョンキーに制限されていない限り、マルチリージョン AWS KMS キーを使用することをお勧めします。マルチリージョンキーは、各リージョンで独立したキーインフラストラクチャを維持しながら、リージョン間で一貫したキーマテリアルを提供します。これにより、暗号化戦略の柔軟性が高まり、デプロイが将来の変化にも対応できるようにするのに役立ちます。 始めましょう CMK を使用してアイデンティティセンターの組織インスタンスの ID データを暗号化するとします。私の組織では、アイデンティティセンターを使用して、 AWS マネージドアプリケーション ( Amazon Q Business や Amazon Athena など) へのアクセスを従業員に付与しています。 現時点では、一部の AWS マネージドアプリケーションは、カスタマーマネージド KMS キーで設定されたアイデンティティセンターでは使用できません。互換性のあるアプリケーションのリストは常に更新されるため、「 AWS managed applications that you can use with Identity Center 」で最新情報をご覧ください。 大まかなプロセスでは、まず AWS KMS で対称カスタマーマネージドキー (CMK) を作成する必要があります。このキーは、暗号化および復号オペレーション用に設定する必要があります。次に、アイデンティティセンター、AWS マネージドアプリケーション、管理者、およびアイデンティティセンターと IAM アイデンティティセンターサービス API にアクセスする必要がある他のプリンシパルにアクセスを付与するキーポリシーを設定します。キーにはポリシーを、IAM プリンシパルには IAM ポリシーを、それぞれアイデンティティセンターの使用方法に応じて定義する必要があります。 サービスドキュメントには、極めて一般的なユースケースをカバーするのに役立つ詳細が記載されています 。 このデモは 3 つのパートに分かれています。まず、AWS KMS でカスタマーマネージドキーを作成し、アイデンティティセンターと AWS マネージドアプリケーションがそのキーを使用することを認可する許可を設定します。次に、AWS アプリケーション管理者など、別の AWS アカウントのキーを使用するプリンシパルの IAM ポリシーを更新します。最後に、アイデンティティセンターがそのキーを使用するように設定します。 パート 1: キーを作成して、許可を定義する まず、AWS KMS で新しい CMK を作成しましょう。 キーは、アイデンティティセンターインスタンスと同じ AWS リージョンおよび AWS アカウントに存在する必要があります。AWS Organizations 内の組織の管理アカウントに、アイデンティティセンターインスタンスとキーを作成する必要があります。 アイデンティティセンターインスタンスと同じリージョンで AWS Key Management Service (AWS KMS) コンソールに移動し、 [キーを作成] を選択します。これでキー作成ウィザードが起動します。 [ステップ 1 – キーを設定する] で、キータイプとして、[対称] (暗号化と復号の両方に使用される単一のキー) または [非対称] (暗号化/復号と署名/検証用のパブリックキーとプライベートキーのペア) を選択します。アイデンティティセンターでは、保管中の暗号化に対称キーが必要です。私は [対称] を選択します。 キーの使用方法については、 [暗号化および復号] を選択します。これにより、キーはデータの暗号化と復号にのみ使用されます。 [高度なオプション] の [キーマテリアルのオリジン] で [KMS – 推奨] を選択し、AWS KMS がキーマテリアルを作成および管理するようにします。 [リージョン] で、[シングルリージョンキー] または [マルチリージョンキー] を選択します。 [マルチリージョンキー] を選択すると、キー管理者は、キーを他のリージョンにレプリケートできます。既に説明したように、アイデンティティセンターでは現時点ではこれは必要ありませんが、設定が将来の変化に対応できるようにするのに役立ちます。なお、シングルリージョンキーを作成した後で、マルチリージョンキーに変換することはできません (ただし、アイデンティティセンターによって使用されるキーを変更することは可能です)。 その後、 [次へ] を選択して、ラベルの追加、管理許可の定義、使用許可の設定、キー作成前の最終設定の確認などの追加の設定ステップに進みます。 [ステップ 2 – ラベルを追加する] で、キーの [エイリアス] 名を入力し、 [次へ] を選択します。 このデモでは、 ドキュメント で提供されているテンプレートを使用してポリシーステートメントを追加することで、キーポリシーを編集します。 ステップ 3 とステップ 4 はスキップし、 [ステップ 5 – キーポリシーを編集する] に進みます。 アイデンティティセンターでは、少なくともアイデンティティセンターとその管理者がキーを使用できるようにする許可が必要です。そのため、3 つのポリシーステートメントを追加します。1 つ目と 2 つ目はサービスの管理者を認可し、3 つ目はアイデンティティセンターサービス自体を認可します。 { "Version": "2012-10-17", "Id": "key-consolepolicy-3", "Statement": [ { "Sid": "Allow_IAMIdentityCenter_Admin_to_use_the_KMS_key_via_IdentityCenter_and_IdentityStore", "Effect": "Allow", "Principal": { "AWS": "ARN_OF_YOUR_IDENTITY_CENTER_ADMIN_IAM_ROLE" }, "Action": [ "kms:Decrypt", "kms:Encrypt", "kms:GenerateDataKeyWithoutPlaintext" ], "Resource": "*", "Condition": { "StringLike": { "kms:ViaService": [ "sso.*.amazonaws.com", "identitystore.*.amazonaws.com" ] } } }, { "Sid": "Allow_IdentityCenter_admin_to_describe_the_KMS_key", "Effect": "Allow", "Principal": { "AWS": "ARN_OF_YOUR_IDENTITY_CENTER_ADMIN_IAM_ROLE" }, "Action": "kms:DescribeKey", "Resource": "*" }, { "Sid": "Allow_IdentityCenter_and_IdentityStore_to_use_the_KMS_key", "Effect": "Allow", "Principal": { "Service": [ "sso.amazonaws.com", "identitystore.amazonaws.com" ] }, "Action": [ "kms:Decrypt", "kms:ReEncryptTo", "kms:ReEncryptFrom", "kms:GenerateDataKeyWithoutPlaintext" ], "Resource": "*", "Condition": { "StringEquals": { "aws:SourceAccount": "<Identity Center Account ID>" } } }, { "Sid": "Allow_IdentityCenter_and_IdentityStore_to_describe_the_KMS_key", "Effect": "Allow", "Principal": { "Service": [ "sso.amazonaws.com", "identitystore.amazonaws.com" ] }, "Action": [ "kms:DescribeKey" ], "Resource": "*" } ] } また、AWS マネージドアプリケーションの使用という私のユースケースを許可するために、ポリシーステートメントをさらに追加する必要があります。これらの 2 つのポリシーステートメントを追加して、AWS マネージドアプリケーションとその管理者が KMS キーを使用することを認可します。 このドキュメントには、追加のユースケースとそれぞれのポリシーがリストされています 。 { "Sid": "Allow_AWS_app_admins_in_the_same_AWS_organization_to_use_the_KMS_key", "Effect": "Allow", "Principal": "*", "Action": [ "kms:Decrypt" ], "Resource": "*", "Condition": { "StringEquals" : { "aws:PrincipalOrgID": "MY_ORG_ID (format: o-xxxxxxxx)" }, "StringLike": { "kms:ViaService": [ "sso.*.amazonaws.com", "identitystore.*.amazonaws.com" ] } } }, { "Sid": "Allow_managed_apps_to_use_the_KMS_Key", "Effect": "Allow", "Principal": "*", "Action": [ "kms:Decrypt" ], "Resource": "*", "Condition": { "Bool": { "aws:PrincipalIsAWSService": "true" }, "StringLike": { "kms:ViaService": [ "sso.*.amazonaws.com", "identitystore.*.amazonaws.com" ] }, "StringEquals": { "aws:SourceOrgID": "MY_ORG_ID (format: o-xxxxxxxx)" } } } キーの使用を特定のアイデンティティセンターインスタンス、特定のアプリケーションインスタンス、または特定のアプリケーション管理者にさらに制限することもできます。 このドキュメントには、お客様のユースケース向けの高度なキーポリシーの例が記載されています 。 許可セットの再作成時に IAM ロール名が変更されないようにするには、「 Custom trust policy example 」で説明されている方法を使用します。 パート 2: IAM ポリシーを更新して、別の AWS アカウントからの KMS キーの使用を許可する アイデンティティセンターの委任された管理者や AWS アプリケーション管理者など、別の AWS アカウントからアイデンティティセンターサービス API を使用するすべての IAM プリンシパルには、これらの API 経由での KMS キーの使用を許可する IAM ポリシーステートメントが必要です。 新しいポリシーを作成し、ユースケースに関連する IAM ロールにそのポリシーをアタッチすることで、キーにアクセスするための許可を付与します。これらのステートメントを IAM ロールの既存の ID ベースのポリシーに追加することもできます。 これを行うには、キーを作成した後、その ARN を見つけて、以下のテンプレートの key_ARN を置き換えます。その後、そのポリシーをマネージドアプリケーション管理者の IAM プリンシパルにアタッチします。このドキュメントでは、 キーにアクセスするための許可をアイデンティティセンターの委任された管理者に付与する IAM ポリシー についても説明しています。 マネージドアプリケーション管理者向けの例を次に示します: { "Sid": "Allow_app_admins_to_use_the_KMS_key_via_IdentityCenter_and_IdentityStore", "Effect": "Allow", "Action": "kms:Decrypt", "Resource": "<key_ARN>", "Condition": { "StringLike": { "kms:ViaService": [ "sso.*.amazonaws.com", "identitystore.*.amazonaws.com" ] } } } ドキュメントでは、最も一般的なユースケース向けの IAM ポリシーテンプレートを共有しています 。 パート 3: キーを使用するように IAM アイデンティティセンターを設定する CMK は、アイデンティティセンターの組織インスタンスを有効にする際に、または既存のインスタンスで設定できます。また、CMK を切り替えたり、AWS 所有キーに戻したりすることで、いつでも暗号化設定を変更できます。 KMS キーの許可を正しく設定しないと、アイデンティティセンターの運用が中断され、アイデンティティセンターを通じた AWS マネージドアプリケーションおよびアカウントへのアクセスが中断される可能性があることにご留意ください。この最後のステップに慎重に進み、ドキュメントをよく読み、理解するようにしてください。 CMK を作成して設定したら、アイデンティティセンターを有効にする際に [高度な設定] でその CMK を選択できます。 AWS マネジメントコンソールを使用して既存のアイデンティティセンターインスタンスで CMK を設定するには、まず AWS マネジメントコンソール のアイデンティティセンターのセクションに移動します。そこで、ナビゲーションペインから [設定] を選択し、 [管理] タブを選択して、 [IAM アイデンティティセンターの保管中のデータの暗号化用のキー] セクションで [暗号化を管理] を選択します。 いつでも、同じ AWS アカウントから別の CMK を選択したり、AWS マネージドキーに切り替えて戻したりできます。 [保存] を選択すると、キーの変更プロセスが完了するまで数秒かかります。移行中もすべてのサービス機能は中断なく使用できます。何らかの理由でアイデンティティセンターが新しいキーにアクセスできない場合は、エラーメッセージが返され、アイデンティティセンターは引き続き現在のキーを使用し、既に暗号化で使用されている暗号化メカニズムで ID データを暗号化し続けます。 留意事項 作成した暗号化キーは、アイデンティティセンターの重要なコンポーネントとなります。保管中の ID 属性を暗号化するために独自のマネージドキーを使用することを選択する場合は、次の点を確認する必要があります。 KMS キーを使用するために 必要な許可 を設定しましたか? 適切な許可がない場合、CMK を有効にすると失敗したり、IAM アイデンティティセンターの管理や AWS マネージドアプリケーションが中断したりする可能性があります。 AWS マネージドアプリケーションが CMK キーと互換性があることを確認しましたか? 互換性のあるアプリケーションの一覧については、「 AWS managed applications that you can use with IAM Identity Center 」をご覧ください。 CMK と互換性のない AWS マネージドアプリケーションによって使用されるアイデンティティセンターのために CMK を有効にすると、それらのアプリケーションの運用が中断されます。互換性のないアプリケーションがある場合は、続行しないでください。 組織は、アイデンティティセンターおよび Identity Store API を利用するために追加の IAM ロール設定を必要とする AWS マネージドアプリケーションを使用していますか? 既にデプロイされているこのような各 AWS マネージドアプリケーションについて、マネージドアプリケーションのユーザーガイドを読み、IAM アイデンティティセンターの使用のための、更新された KMS キーの許可を確認し、指示に従ってそれらの許可を更新して、アプリケーションが中断しないようにしてください。 簡潔にするために、この記事の KMS キーポリシーステートメントでは、 暗号化コンテキスト を省略しています。暗号化コンテキストを使用すると、 特定のインスタンスを含むアイデンティティセンターへの KMS キーの使用を制限 できます。本番のシナリオでは、アイデンティティセンターに次のような条件を追加できます: "Condition": { "StringLike": { "kms:EncryptionContext:aws:sso:instance-arn": "${identity_center_arn}", "kms:ViaService": "sso.*.amazonaws.com" } } あるいは、Identity Store に次のような条件を追加できます: "Condition": { "StringLike": { "kms:EncryptionContext:aws:identitystore:identitystore-arn": "${identity_store_arn}", "kms:ViaService": "identitystore.*.amazonaws.com" } } 料金と利用可能なリージョン キーストレージと API の使用には、AWS KMS の標準料金が適用されます。アイデンティティセンターは引き続き追加料金なしでご利用いただけます。 この機能は、すべての AWS 商用リージョン、AWS GovCloud (米国)、および AWS 中国リージョンでご利用いただけます。詳細については、「 IAM アイデンティティセンターユーザーガイド 」にアクセスしてください。 セキュリティとコンプライアンスの要件を満たすために、この新しい機能をどのように使用するのかについて、ぜひお聞かせください。 – seb 原文は こちら です。

本稿は、JALデジタル株式会社システムマネジメント本部ハイブリッドクラウド基盤部クラウド基盤運営グループの梅本様、北様からご寄稿いただきました。 はじめに JALデジタル株式会社のプラットフォームチームでは、JALグループのITシステムとして必要な設計・運用を満たすためのAWSアカウントを「 CIEL/S 」(※1)として提供しています。 今回私たちのチームでは、複数のAWSアカウントにおける AWS サポートとのやり取りを組織全体で効率的に活用するため、Amazon Bedrock を活用したナレッジ集約のソリューションを開発しました。 本記事では、AWS サポート問い合わせ内容の自動収集、AI要約、ServiceNow（※2）への連携を実現したアーキテクチャについて解説します。 ※1：リンク先の資料内におけるJALインフォテックは2025年4月、JALデジタルに社名変更しています。 ※2：JALグループではITSMツールとしてServiceNowを利用しています。 導入背景 現在JALグループで利用しているAWSアカウント数は数百アカウントあり、エンタープライズサポートを活用して24時間365日の運用を実現しています。しかし、利用していく中でいくつかの課題が発生しました。 アカウントの制約 各アカウントから行った問い合わせ内容は、そのアカウントでしか閲覧もできません。そのため、複数のAWSアカウントでのサポート問い合わせ内容が分散することになり、組織全体での知見共有が困難となっていました。また、私たちのチームに「○○という内容で過去に問い合わせしているアカウントはいないか」と質問があっても、一元管理できていないため探すのが困難でした。 ナレッジ共有の壁 問い合わせした内容をドキュメント化して共有する場合、CIEL/SのAWSアカウント全体で平均60件/月の問い合わせが発生しており、それらを手動でナレッジとして作成することはコストがかかりすぎてしまいます。また問い合わせ履歴が多くなってしまったサポートケースをそのまま転記するだけでは、読み手の負担も大きいためある程度要約をする必要がありますが、要約作成もナレッジ化のハードルとなっていました。 AWS サポートケース保管期限の制約 解決から２年経過した問い合わせはAWSコンソール上から削除されるため、それ以上過去に遡って探すことができませんでした。 ソリューション概要 上記課題を解決するために、自動的にAWS サポートケース の集約と Amazon Bedrock を活用した問い合わせ内容の要約作成を行うソリューションの開発を行いました。開発したソリューションは、2種類のAWSアカウントと、3つの主要なコンポーネントで構成されています。 AWSアカウントの種類 集約実行アカウント 問い合わせ内容を集約し、ServiceNowに連携するAWSアカウント 集約対象アカウント 問い合わせを集約させたいAWSアカウント コンポーネント 既存の AWS サポートケース の集約（集約実行アカウント） 本ソリューション導入前に解決済みとなっている AWS サポートケース を集約させるための処理 Amazon Bedrockを利用して問い合わせ内容の要約を作成 新規の AWS サポートケース の集約（集約実行アカウント） 本ソリューション導入後に解決済みとなった AWS サポートケース を自動で集約させるための処理 Amazon Bedrockを利用して問い合わせ内容の要約を作成 集約した問い合わせをServiceNowに連携する処理 AWS サポートケース の ResolveCase を検知（集約対象アカウント） 集約対象AWSアカウントで解決済みとなった AWS サポートケース を集約実行アカウントに連携する処理 AWS Cloudformation StackSets を利用して複数AWSアカウントに Amazon EventBridge Rule を展開 AWS サポートケースの検索と表示（ServiceNow） 集約実行アカウントから連携された問い合わせの表示 AWSサポートケースの内容検索 アーキテクチャ詳細 既存の AWS サポートケース の集約の処理については、一度のみの処理となるため、メインとなる新規の AWS サポートケース の集約について詳細を解説します。 Step 1: サポートケースが解決したイベント検知（集約対象AWSアカウント） 集約実行アカウントの Event Bus をターゲットとした Amazon EventBrige Rule を作成します AWS サポートの解決処理をトリガーとして、Amazon EventBridge Ruleのイベントパターンに定義します { "detail-type": ["Support Case Update"], "source": ["aws.support"], "detail": { "communication-id": [""], "event-name": ["ResolveCase"] } } Step 2: Step 1 の検知を元にLambdaを実行（集約実行AWSアカウント） 集約対象AWSアカウントに対して、AWS Support API ( DescribeCases 、 DescribeSeverityLevels 、 DescribeServices 、 DescribeCommunications )を実行してサポートケース情報を取得 Amazon Bedrock API ( Converse ) を実行し サポートケース会話情報を要約 Amazon DynamoDB に登録 Step 3: ServiceNow連携（集約実行AWSアカウント） DynamoDB Stream から AWS Lambda 関数を実行 ServiceNow への認証処理 ServiceNow への記事の登録処理の実行 ①AWS サポートケースとServiceNow上のナレッジとのマッピング ②ServiceNow上でナレッジ検索する際イメージ 実装ポイント Amazon EventBridgeのリージョン制約対応 AWS サポートは us-east-1 リージョンのグローバルリソースであるため、EventBridge Rule の配置および Lambda 関数のデプロイも us-east-1 にまとめることが推奨されます。 セキュリティ権限の最小化 各AWSアカウントに必要な IAMロール・ポリシーは最小権限の原則に従い、AWS サポートケースの読み取り権限や EventBridge Rule の作成権限だけに限定することで安全性を確保してください。 システムプロンプトの設計 読み手が短時間で問題の本質と解決策を把握できるよう、要約生成のためのプロンプトは、以下のポイントを押さえて設計しています。 ユーザーが直面した問題、サポートの具体的な解決策、成功のための考慮事項を明確に区別して要約させる 日本語で簡潔に300文字以内に収める文字数制限を設定し、不要な情報を排除 「問い合わせ内容」「解決策」「考慮事項」という出力フォーマットを厳格に指定し、一貫性のある要約を実現 ナレッジ格納先にServiceNowを選定 本ソリューション実装前から、プラットフォームに関するナレッジを ServiceNow 上に乗せていた 標準となるナレッジの型があり、UI を一から作成する必要が無い 検索機能も ServiceNow 標準のものを利用できる(AIを用いた検索等は今後実装予定) ※AWS Support APIの利用条件 AWS Support APIの利用にはビジネスサポート以上のサポートプラン（ビジネス、エンタープライズ On-Ramp、エンタープライズ）が必要です。JALグループではエンタープライズサポートを利用しているため、本ソリューションで必要となるAWS Support APIの全機能を活用することができます。 導入効果 本ソリューションの導入により、以下の効果を実現しました。 ナレッジ共有の効率化 複数アカウントの問い合わせ内容を一元管理することで、組織全体の知見を活用できるようになりました。またAI要約を入れることで、すべてのやり取りを読む前に自分たちが探している情報かどうか判断することができるようになりました。 運用工数の削減 手動でのドキュメントや要約作成が不要になることで、ナレッジ作成に伴う運用コストを大幅に削減させることができました。また ServiceNow への自動連携により転記作業を削減した上で、解決済みになった問い合わせをリアルタイムでナレッジ化することが可能になりました。 問題解決の迅速化 一元管理により、各アカウントの担当者が組織全体の知見を活用して、調べたい情報や類似事例を直接検索-閲覧できるようになりました。これにより、プラットフォームチームやAWSサポートに問い合わせて回答を待つ時間を省略し、素早い問題解決が可能になりました。 まとめ AWS Support APIを利用した問い合わせ内容の取得と、Amazon Bedrock を活用した問い合わせ内容の要約作成を組み合わせることで、組織全体のナレッジマネジメントを大幅に改善することができました。AWS Lambda、 Amazon EventBridge、Amazon DynamoDB などAWSのマネージドサービスを最大限に活用、AWS利用料を最小限に抑えるアーキテクチャを実現しました。 今後は、要約精度の向上や、より高度な分析機能の追加を検討しており、継続的な改善を進めていく予定です。 著者略歴 JALデジタル株式会社 システムマネジメント本部ハイブリッドクラウド基盤部クラウド基盤運営グループ 梅本征宏 2019年入社　旅客系システムの開発・維持管理業務を担当。 2022年に現部署に異動して以降、Platform Engineeringを推進。 JALデジタル株式会社 システムマネジメント本部ハイブリッドクラウド基盤部クラウド基盤運営グループ 北修哉 顧客系システムの開発を担当。 2024年に現部署に異動し、プラットフォームチームの運用高度化を推進。

はじめに データドリブンエンタープライズの環境では、組織は 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サービス提供の豊富な経験があります。