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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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