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

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

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

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

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

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

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

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

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

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

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

皆さん、信じられますか? 早いもので、今年も年末がすぐそこまでやって来ています。AWS re:Invent が開催日を迎えるのもあっという間です! 米国ラスベガスで毎年行われる AWS 最大のイベントは 12 月 1 日から 12 月 5 日の日程で開催され、私たちが取り組んできた数多くの事柄が発表およびリリースされます。チケットをまだ購入していない場合は AWS re:Invent 2025 のチケットを購入 して、このイベントを実際に体験しましょう。ラスベガスに行けなくても心配ありません。数々の発表を情報が入り次第お伝えする AWS ニュースブログをチェックしてください。 これから re:Invent までの間にもエキサイティングな新しいリリースがまだまだたくさん行われるので、いつものように9 月 22 日週のハイライトを簡単に振り返って最新のリリースを見ていきましょう。まずは、最も人気のあるサービスの 1 つである Amazon S3 です。 S3 の更新 S3 チームは、S3 の使用をさらに向上させるために懸命に取り組んできました。今月だけでも、 S3 バッチオペレーションのターゲット一括選択 、 S3 汎用バケットでの条件付き削除のサポート 、 マルウェア防止のためのファイルサイズとアーカイブスキャンの制限拡張 などがリリースされました。 9 月 22 日週は、 AWS コンソールでの Amazon S3 Tables プレビュー機能の追加 により、新たな S3 マイルストーンが達成されました。今後は、コンソールから直接 S3 テーブルを確認することで、SQL を記述しなくてもテーブルのデータ構造と内容を簡単に理解できるようになります。簡単に表示できるこの特徴量は、S3 Tables がサポートされているすべてのリージョンで今すぐ利用でき、発生するコストはテーブルプレビューを表示するために必要な S3 リクエストの料金のみです。 その他のリリース 9 月 29 日週はすばらしい機能をリリースしたその他サービスのハイライトをいくつかご紹介します。 Amazon Bedrock AgentCore が エンタープライズ統合オプションと自動化オプションを拡大 – Bedrock AgentCore サービスは、新たに Amazon VPC 接続、 AWS PrivateLink 、 AWS CloudFormation 、リソースタグをサポートすることで エンタープライズ対応性をレベルアップ し、開発者がセキュリティやインフラストラクチャの自動化よりよく制御できるようにしました。スケーラブルなエージェントデプロイ用の AgentCore Runtime、ウェブインタラクション用の AgentCore Browser、セキュアなコード実行用の AgentCore Code Interpreter のどれを使用しているかにかかわらず、これらの機能強化によって、プライベートリソースへのアクセス、インフラストラクチャのデプロイ自動化、系統立ったリソース管理の維持をセキュアに実行できる AI エージェントのデプロイが可能になります。 AWS X-Ray が より優れたエラー検出のためのスマートサンプリングを導入 – AWS X-Ray が、 定義した制限内でトレースキャプチャ率を自動的に調整する適応型サンプリング の提供を開始しました。この機能は、DevOps チームや SRE が通常の操作時にオーバーサンプリングを行うことなく重要な問題を検出できるようにします。新機能には、異常発生時にサンプリングを増加させる Sampling Boost や、ターゲットを絞りこんだエラートレースを行う Anomaly Span Capture などがあり、チームはコストを抑えながら必要なときに高度なオブザーバビリティを実現できます。 AWS Clean Rooms が段階的な ID マッピングでリアルタイムコラボレーションを強化 – AWS Clean Rooms では、 AWS Entity Resolution を使用した新規、変更済み、削除済みのレコードのみでの ID マッピングテーブルの更新が可能になり、コラボレーター間でのデータ同期化をより効率的かつタイムリーに行えるようになりました。この改善は、広告効果測定プロバイダーがプライバシーコントロールを維持しながら広告主やパブリッシャーとの最新データセットを維持するために役立ち、データセット全体を再処理しなくても常時オンのキャンペーン効果測定が可能になります。 要点だけを簡潔に チームやワークロードに大いに役立つと思われる更新をいくつか簡単に紹介します。 EC2 インスタンスタイプはどんどん更新されるので、最新タイプを完全に把握しておくのも大変です。 AWS Compute Optimizer では、最新の C8、M8、R8、I8 ファミリーを含めた 99 のインスタンスを追加でサポートするようになりました。 e スポーツでは、1 ミリ秒たりとも無駄にできません! Amazon GameLift が米国ダラスに新しい Local Zone を立ち上げ、テキサス州のプレイヤーはより近い場所に設置された超低レイテンシーゲームサーバーを利用できるようになりました。 大規模な Amazon EC2 デプロイを管理するときは、コントロールがすべてです! Amazon EC2 の 許可された AMI 設定がマーケットプレイスコード、廃止時、作成日、命名パターンでのフィルタリングのサポートを開始 しました。これは、非準拠イメージの使用防止に役立ちます。さらに、 EC2 Auto Scaling ではインスタンスの更新を即座に強制キャンセル できるようになり、重要なデプロイ中の制御をより迅速に行えるようになりました。 よりインテリジェントでセキュアなカスタマーサービスをさまざまな言語で実現しましょう! Amazon Connect が、より優れたカスタマージャーニーインサイトを得るために フローデザイナーの分析を強化 し、 正確なインタラクション追跡のためのカスタム属性 を追加するとともに、 Contact Lens の機密データ秘匿化機能を拡張 してさらに 7 つの欧米言語をサポートするようになりました。 9 月 29 日週のニュースは以上です! 世界中で開催される 今後の AWS イベントのすべて を忘れずにチェックしましょう。テクノロジー業界の気の合う仲間たちとすばらしい 1 日を過ごしながら、たくさんの人々と出会い、たくさんの事柄を学べる無料のイベントに参加するエキサイティングな機会が盛りだくさんです。 賞金を掛けて勝負したいと考えているなら、特別なイベントへの参加期間が終了間近です! 10 月 20 日まで続く AWS AI Agent Global Hackathon は、AWS の包括的な生成 AI スタックを使用して革新的な AI エージェントを構築するというまたとない機会を開発者に提供します。45,000 USD を超える賞金と独占的な市場参入機会を獲得できるグローバルなコンペであなたの創造性と技術力を披露するチャンスをお見逃しなく。 9 月 22 日週のリリースから、役に立つ機能やエキサイティングな機能を見つけていただけたでしょうか。AWS では、毎週月曜日にウィークリーレビューを公開して AWS の最新情報を皆さんにお届けしています。このページをブックマークして、10 月 6 日週もまたお会いしましょう! Matheus Guimaraes | @codingmatheus 原文は こちら です。

本ブログは、2025 年 9 月 23 日に Adam Balest によって執筆された「 Showcase your AWS achievements with the new Skills Profile 」を翻訳したものです。 AWS Training and Certification では、AWS のスキルと成果を共有したい学習者のために、AWS Skill Builder の新機能「スキルプロファイル」の提供を開始しました。これは、AWS 認定、学習成果、デジタルバッジを 1 つの共有可能なプロファイルで紹介する強力な新しい方法です。スキルプロファイルにはカスタマイズ可能な共有オプションがあり、可視性と信頼性を高めながら、学習者それぞれのクラウドスキルを伝えるために使用できます。 スキルプロファイルは Skill Builder にサインインしている学習者が利用でき、AWS の学習成果を公開できる中心的な場所となります。あなたが意欲的なクラウドプラクティショナーであろうとベテランエキスパートであろうと、あなたのスキルプロファイルはあなたの AWS スキルのショーケースとなり、LinkedIn などのプラットフォームや求人応募で、同僚や採用マネージャーにすぐに共有可能です。 「スキルプロファイルでは、AWS の学習過程と、私が身に付けたスキルを簡単に紹介できます。認定資格や学習のマイルストーンをわかりやすい形式で共有できます。スクリーンショットや色々な場所に散らばったリンクは必要ありません。」— AWS Skill Builderの学習者 学習から専門的な評価へ 専門的なプラットフォームでのソーシャルラーニングの広がりにより、学習者が信頼性の高い一貫した方法で専門知識を示すことが不可欠になっています。スキルプロファイルは、プライベートな学習記録と、公開される専門的な評価の間のギャップを埋めるものです。 Skill Builder 内の学習者ダッシュボードはプライベートである一方、スキルプロファイルは公開共有を目的に設計されています。AWS の認定資格、Skill Builder での学習成果、Cloud Quest のバッジ、その他の達成項目などを紹介できます。表示内容を完全にコントロールできるため、自分がプロファイルで共有したい内容を伝えることができます。 スキル共有を通じたつながりの構築 スキルプロファイルは、クラウドの専門知識を可視化し、共有可能にすることで、学習者と組織の双方に新たな価値をもたらします。認証された AWS での実績を共有することで、新たな職業的なつながり、コラボレーション、キャリアの機会への扉が開かれます。 学習者にとっては、熱心に培ってきたスキルを示す手段となり、組織や採用担当者にとっては、クラウド人材を発見し検証するための信頼できる情報源となります。これらの共有プロファイルにより、スキルを持つ専門家と、現在および将来の機会との間により強固なつながりが生まれます。 今後、スキルプロファイルは、特定のスキルや AWS クラウドでの成果に基づいて組織や採用担当者が人材を発見するのを助ける機能に加えて、さらに多くの共有可能な実績を含むように拡張される予定です。 スキルプロファイルの始め方 スキルプロファイルを使い始めるには、AWS Skill Builder にサインインし、画面右上の「アカウント」より「プロフィール」に移動し、スキルプロファイルを作成・カスタマイズします。そこから、表示する実績を選択し、ヘッドライン (オプション) を挿入して、プロファイルのリンクをネットワークと共有できます。 次の役職に就くことを目指している場合でも、最近の認定資格を紹介したい場合でも、AWS で学んだことを誇りを持って共有したい場合でも、スキルプロファイルを使用して自分のクラウド専門知識を世界に共有できます。 あなたの AWS ストーリーを共有する準備はできましたか ? 今すぐ AWS Skill Builder にサインインして、スキルプロファイルを作成しましょう ! 翻訳は Technical Instructor の 室橋 弘和 が担当しました。

みなさん、こんにちは。AWS ソリューションアーキテクトの森です。 2025 年も多くのお客様に生成 AI の活用にチャレンジいただいております。特に注目すべきは、生成 AI をコアビジネスの価値向上や成長加速に繋げる事例が増えてきていることです。今回ご紹介するのは、医療従事者向けの情報サービスを提供する株式会社ケアネット様が、AWS の生成 AI サービスである Amazon Bedrock を活用して、医師向け情報サービスの価値を大幅に向上させた事例です。 ケアネット様の状況と課題 株式会社ケアネット様は、医療従事者向けプラットフォームを基盤に、医療の人材・教育・経営関連の事業から新薬の開発・治験普及を支援する事業まで、医療・医薬分野の専門サービスを幅広く展開しています。 その中でも、日常臨床に役立つ医療・医学情報を提供する医師向けの会員制サイト「CareNet.com」は、ケアネット様の主力サービスとなっており、日本全国の医師数の約70%に相当する24万人が登録しています。CareNet.comでは、臨床医による連載やガイドライン解説などの臨床で役立つコンテンツや、医学誌に掲載された論文を厳選し日本語で要約したニュース記事を配信したりしています。しかし、忙しい医師にとっては次のような点が課題となっていました： 膨大な医学情報の処理：年間 150 万件以上の医学文献が発表される中、臨床医が最新情報を継続的に取得することが困難 情報提供の限界：従来の人力によるニュース作成では 1 日約 10 件程度しか提供できず、医師の情報ニーズを十分に満たせていなかった これらの課題を解決するため、ケアネット様は生成 AI を活用した新サービス「CareNet Academia（ケアネットアカデミア）」の開発に着手しました。ケアネットアカデミアは、「限られた時間で専門分野の知識を効率よくアップデートしたい」といった臨床現場のニーズに応えるスマホ対応ブラウザアプリケーションです。膨大な医学文献（米国国立医学図書館（NLM）が提供する医学文献データベース PubMed）のアブストラクト情報を読み込み、各医師ごとの関心に合わせて生成 AI が自動でニュース記事を選定・作成し、その内容がメールで配信されます。関心のあるトピックス（診療科や疾患）については利用開始時に選択可能となっており、配信されたニュース記事を評価することでより有益な情報を配信できるようになります。 ソリューション ケアネットアカデミアで配信する記事を作成するために、Amazon Bedrock を活用した大規模 AI ライティングシステムを構築しました。具体的には、Anthropic 社が開発した LLM である Claude を使ってニュース記事を自動生成し、独自開発のレコメンデーションAIと組み合わせることで、個々の医師に最適化された情報配信を実現しています。 本記事では、特に Amazon Bedrock を活用した AI ライティングシステムについて詳細に解説します。 主な機能 AI ライティングシステム（Amazon Bedrock を活用した機能） Claude を活用して医学文献から記事を自動生成 Claude を使って医学文献を整理・要約 解説記事の自動生成 Amazon Bedrock 選定理由 ケアネット様が Amazon Bedrock を選定した主な理由は以下の通りです： セキュリティとデータ保護 データが AWS 内に閉じるため、会員情報、医療情報のセキュリティを確保 転送中・保管時のデータ暗号化により、機密性の高い会員情報、医療情報を安全に処理 信頼性と品質 Amazon Bedrock の SLA が定義されており、安定したサービス品質を確保 スケーラビリティ クロスリージョン推論機能を活用し、大量のリクエストを並列処理 短時間で多数の記事を生成・処理することが可能 導入効果 Amazon Bedrock を活用した新機能の導入により以下の効果が得られました： 情報提供量の飛躍的増加 1日あたりの記事生成数が最大5,000件に拡大（従来比約500倍） 医師が必要とする幅広い医学情報をカバー 医師の情報収集効率化 膨大な医学文献から必要な情報だけを抽出・要約して提供 医師の情報収集時間の短縮と、より効率的な臨床判断をサポート また、CareNet Academiaをお使いいただいているユーザーの継続率は60%を超えていることからも、医師からの高い満足度が伺えます。さらに、ユーザーからの追加機能の要望（関心のある疾患カテゴリの追加）に迅速に対応したことで、「非常に有用で助かっている」という声も届いています。ケアネット様の CTO である榊原海様からは「Amazon Bedrock の活用で、AWS の統合されたセキュアなインフラ内でAI処理の大規模並列実行を実現できました。」とコメントを頂戴しています。 まとめ 本事例は、医療情報という専門性の高い分野において、生成 AI を活用してビジネスの価値向上に繋げた優れた事例です。Amazon Bedrock のセキュリティ、信頼性、スケーラビリティを活かし、医師向け情報サービスの質と量を大幅に向上させることに成功しました。 特に注目すべきは、単に業務効率化だけでなく、医師の情報収集をサポートし、最終的には医療の質向上に貢献するという社会的意義の高いユースケースである点です。AWS は今後も、このような社会的価値の創出に貢献できるよう、安全で信頼性の高い生成 AI サービスの提供を続けてまいります。 生成 AI を活用したビジネス価値の向上や、AWS が提供する様々なサービスの選択肢にご興味をお持ちの方は、お気軽にお問い合わせください。 ソリューションアーキテクト 森 瞭輔

はじめに 近年、IT の急速な進歩と共に EC 市場は急速に拡大し、様々な顧客ニーズに応えるため EC サイトや決済手段も多様化する中、「電話」という従来からのチャネルの重要性は今なお低下することはありません。シニア層や IT に不慣れな方への対応や緊急時の問い合わせなど、電話での対応が必要とされるシーンは決して少なくなく、むしろ事業者様とお客様をつなぐ接点として大きな価値をもたらす役割を担っています。 その一方で、コンタクトセンターにおける人手不足やコストの課題は、業界共通の大きな悩みであることも事実です。オペレータの負荷軽減や業務効率化、運用コストの削減を目指す中で注目される技術として IVR (Interactive Voice Response) があります。IVR は電話による顧客対応を自動化する技術として活用されており、音声ガイダンスに従ってキーパッドから番号を入力する、あるいはユーザーが発話することで、その内容に応じて様々なサービスを利用できるシステムです。この技術により、ヒューマンオペレーターの対応を減らし必要な場面にだけオペレーターが介在できるため、人手不足の課題解決につながり、見方を変えると、オペレータ対応を真に必要とするお客様に絞った対応ができるため、問い合わせ窓口としての満足度向上にも貢献できます。 ここで注目したいのが、AWS が提供するクラウドベースのコンタクトセンターサービス Amazon Connect と AI による柔軟な対話を実現する Amazon Lex です。従来の定型フレーズによる音声ガイダンスでは無機質な印象もあった IVR ですが、AI や 音声合成マークアップ言語 (SSML) など、多様な機能を活用することで、より自然で温かみのあるインタラクションを AWS で実現することができます。そもそも、従来のオンプレミスのコンタクトセンター基盤の IVR にこうした最新のテクノロジーを組み込もうとした場合、時間やコストが制約になることもあります。これに対し、Amazon Connect と Amazon Lex はわずか数クリックでデプロイすることができ、料金についても初期費用不要の従量課金モデルでサービスを利用することが可能です。そのため、スモールスタートで素早く取り組みを開始し、事業成長とともに規模をスケールすることができます。 また、 Amazon Pay は Amazon が提供する ID 決済サービスで、Amazon アカウントを持っていればどなたでも利用できる簡単・便利な決済サービスです。 amazon.co.jp を普段からご利用いただいているお客様はすでに Amazon アカウントをお持ちですので、Amazon Pay をすぐに利用できます。 Amazon Pay が導入されている EC サイト では、Amazon アカウントに登録されたお支払い方法・お届け先住所を利用できるため、最短 3 ステップでお買い物が完了します。Amazon Pay を IVR による電話注文と統合することで、電話口でのやり取りから Web 決済までスムーズかつセキュアに完結し、これまで抱えていた「電話口でのクレジットカード番号の伝達」や「注文導線における入力操作の手間」というお客様の不安・不満、さらには事業者様が懸念する「購入からの途中離脱」の解消につながります。 本記事では、Amazon Connect および Amazon Lex を活用した IVR による電話注文から Amazon Pay での Web 決済につなげる新しい購入体験のシナリオや構成例についてご紹介します。お客様の利用シーンや属性に合わせて選択可能な最適なチャネルを提供し、コンタクトセンタービジネスをさらに拡張するアプローチのきっかけとなれば幸いです。 電話注文時のユーザー体験 本記事では電話注文のシーンに焦点を置き、電話注文の開始から決済完了までの一連の流れを想定します。 お客様がカタログやテレビショッピングで見た電話番号を入り口とし、どういった体験ができるかのアイデアをご紹介します。 一例ではありますが、以下のようなフローをユーザー体験として想定できます。 電話をかけて、商品名・購入数 を電話口で伝える。 注文を電話口で確認したら、電話をかけた端末に SMS メッセージを受信する。 SMS のリンクから Web に遷移し、Amazon Pay で決済を行う。 手順 1, 2 のフローは電話口でのインタラクションとなり、手順 3 は、Web での決済操作となるイメージです。 電話口でのインタラクションは IVR によって実現が可能です。つまりオペレータの介在なしに電話でのフローは完結できます。 例えば、以下のような対話イメージを IVR によって実現できます。 IVR による電話注文を実現する AWS のサービス 電話口での IVR は Amazon Connect と Amazon Lex で構築が可能です。 Amazon Connect は AWS が提供するクラウドベースのコンタクトセンターサービスで、Web コンソールの UI 上でブロックをつなげることで、コンタクトフローを簡単に構築することができます。そのブロックの中の一つに、Amazon Lex を呼び出すブロックがあります。Amazon Lex は 会話型インターフェースを構築する、いわゆるチャットボットのサービスです。Amazon Lex を Amazon Connect と統合することで、電話口での対話を実現することができます。Amazon Lex では注文を処理するためのインテントを構築し、Amazon Connect のフローの中で呼び出すように構築が可能です。「買い物したい」という発話によって、構築した注文処理のインテントが発動し、最後の注文確認までの会話フローを構築することができます。 また、Amazon Lex から AWS Lambda を呼び出すことも可能なため、Amazon Lex のインテントの中で注文確認ができれば AWS Lambda を呼び出し、注文情報をデータベースなどに保管するような構築イメージになります。 なお、SMS メッセージの送信についても AWS で実現することができ、例えば、Amazon SNS のサービスに SMS メッセージを送信する機能があります。Amazon Connect では発信者の電話番号を取得することができ、さらにコンタクトフローの中で AWS Lambda に電話番号情報を渡して実行することも可能です。そのため、Lambda 関数にて Amazon SNS から SMS 送信を行うよう実装することで、Amazon Connect から連携された電話番号をもとに発信者であるお客様に SMS メッセージを送信することを実現できます。 上記のように、多様な機能を提供する AWS のサービスを組み合わせることで、IVR による電話注文から SMS の送信まで、すべてを AWS でシンプルに実現できると考えています。電話注文でのインタラクションから SMS 送信までのアーキテクチャ例を以下に掲載いたしますので、ご参考にいただけますと幸いです。 本記事冒頭でも言及した通り AWS は従量課金モデルであるため、スモールスタートで「まず試してみる」といったことが可能です。新しい機能の導入・拡張に AWS は非常に親和性が高いです。 Amazon Pay による Web 決済 続いて、Web での決済操作の導線イメージをご紹介します。 ここでまずは簡単に Amazon Pay の紹介をいたします。 Amazon Pay とは Amazon Pay は Amazon のお客様向けに提供されている ID 決済サービスで、 Amazon Pay を導入されている事業者様 の EC サイトにてご利用いただけます。 Amazon Pay のご利用に新たな専用アカウント・アプリの登録は必要ありません。 Amazon アカウントをお持ちのお客様、つまり amazon.co.jp を普段からご利用いただいているお客様であれば、その Amazon アカウントに登録されているお支払い方法・お届け先住所を利用することができるため、購入したい EC サイトにて新たにクレジットカードや住所情報登録の手間が軽減され、スピーディーかつ安心してお買い物を楽しむことができます。また、Amazon Pay ではクレジットカードだけでなく、Amazon ギフトカードやあと払い（ペイディ）、メルペイ、パートナーポイントによるお支払いも可能です。 Amazon Pay に関する詳しい情報、および導入を検討される事業者様は、 Amazon Pay の公式ページ 、または こちらのページ から無料でダウンロードできる資料にてご説明しておりますので、ご参照ください。 Amazon Pay での決済イメージ Amazon Pay の概要を掴めたところで、決済操作の導線イメージをご紹介します。「電話注文時のユーザー体験」の章にて記載した手順 3 に相当する箇所のご紹介となります。 簡易な例ではございますが、以下に購入フローのイメージを掲載します。上部の水色のエリアが事業者様の EC サイト、下部のオレンジのエリアが Amazon 側のページ (Amazon Hosted Page) を表しています。 Amazon Pay ではこのように、EC サイトと Amazon Hosted Page を行き来することで決済を進めることが基本となります。 流れとしては、ユーザーに SMS が到達し、そこに記載された URL をクリックすることで、電話口での注文情報が反映されたカートページに遷移します。今回 SMS での送信としているのは、Amazon Connect で発信者の電話番号が取得できるためであり、他の手段で URL を送付する方法も考えられます。URL をクリックし Web ページに表示された Amazon Pay ボタンをクリックすることで、Amazon Hosted Page に遷移します。ユーザーはお持ちの Amazon アカウントでログインし、そのアカウントに登録されているお支払方法およびお届け先住所を選択、あとは EC サイト側で注文確定ボタンを押すことで Amazon Pay の決済を完了することができます。 このように、Amazon アカウントを持ったユーザーであれば、電話注文から購入完了までの一連の流れを、途中での入力の手間などなくスムーズに完結できるよう実装することが可能です。 Amazon Pay を事業者様サイトに組み込む方法については、 Amazon Pay インテグレーションガイド にて記載がございますので、適宜ご参照ください。 （EC サイトへの Amazon Pay 導入には お申し込み が必要です。） IVR × Amazon Pay 導入のメリット IVR による電話注文から、Amazon Pay での Web 決済に引き込むことで以下の観点でメリットがあると考えています。 待ち時間の軽減 IVR での自動応答がない場合、電話注文が殺到すると、オペレータに接続されるのを待つ時間が長くなってしまい、お客様の体験は低下します。 IVR による自動応答で一部の通話に対応することができれば、待ち呼数が減ることになり、有人対応を必要とするお客様もオペレータに繋がりやすくなります。 購入離脱の削減と在庫確保の安心感 オペレータと繋がらないことで今まで購入から離脱していたお客様を救うことができます。また、IVR によって商品の在庫状況をすぐに確認できるようになるため、例えば、期間限定商品の注文に対して、電話注文でまずは在庫を確保することでお客様の安心感や満足度を向上させることもできると考えられます。 有人対応が必要なお客様への手厚いサポート IVR による電話注文の導入により、その利用者だけでなく、一方でそれを利用しないお客様に対してもメリットがあると考えられます。例えば、高齢者やまだ Web 操作に不安がある方からの問い合わせや、注文トラブルなどの緊急の問い合わせに対して、オペレータをさらに動員させることできます。つまり、オペレータの対応が真に必要なお客様に対するサポートにより時間を充てられることにつながるため、コールセンターとしての質やお客様満足度の向上につながると考えられます。 電話口でのクレジットカード番号情報の伝達が不要、後払いによる支払い不安からの解消 Amazon Pay による Web での決済導線に誘導することで、電話口でクレジットカード番号を伝える必要がなくなります。加えて、商品と併せて配送する請求書でお客様からの入金を待つという決済モデルから解放され、支払い不安が解消されます。お客様および EC サイトを持つ事業者様双方においてメリットが出てくるポイントです。 利用シーン 利用シーンとしては、以下の場面が例として考えられます。 テレビ/ラジオ ショッピング カタログ通販 チケット予約 ホテル予約 飲食店予約時の事前決済 上記のユースケースや本記事にて紹介したフローはあくまで例ではございますので、他にも適用できる場面や取り入れられるフローなどがあるかと思います。イメージを膨らましていただくための一助となれば幸いです。 Outbound Call による Amazon Pay 決済 本記事でご紹介した構想は、テレビやカタログで見た電話番号に対してお客様から電話をかけるといったシーンを想定しておりました。一方、Amazon Connect では Outbound Call の機能があり、Amazon Connect からお客様に対して電話を発信することができます。 また、Amazon Pay では Payment Method On File (PMOF) という機能があります。 PMOF という機能は、購入者が商品を初回購入するタイミング、あるいはマイページなどから事前に支払い方法を登録することで、以降の購入時は事業者の任意のタイミングでその購入者が登録した支払い方法に対して課金することができる機能です。 支払い方法の事前設定を必要とする事業者や、購入者の操作なしに取引を処理する必要がある事業者に有用な機能です。 IVR を使った Amazon Connect からの Outbound Call と Amazon Pay の PMOF の機能を統合することで、お客様の再購入をサポートする体験を実現することも可能です。 （現時点におきまして、PMOF は Amazon Pay の担当者より個別でご案内をした事業者様のみご利用いただける限定機能となっております。導入のご検討・PMOF の技術資料をお求めの場合は Amazon Pay への お申し込み 後、担当者へご相談ください。） 流れとしては、初回の購入時あるいは事前に PMOF によって支払い方法を登録します。 初回の購入時から例えば 2 週間経過したタイミングで、その購入者に対して Amazon Connect から Outbound Call をかけます。 Outbound Call の中でお客様が購入の意思を示すことで、事前に PMOF にて登録した決済方法に対して請求をかけることができます。 これにより、再購入の際に Web 決済導線を再度操作することなく完結することができ、簡単でスムーズな購入体験を実現できます。 PMOF による支払い方法の登録を行った以降における Outbound Call での IVR 対話イメージ例を参考までに掲載いたします。 上記のイメージ例では、お客様は最短 1 クリックのキーパッド操作で購入まで完了できるため、非常に手軽でスムーズな購入体験になります。 認証コードによる本人確認や、注文から 60 分間は注文を取り消せるようにするといったオペレーションを組み込むことで、さらなる安心感を付加することもアイデアとしてあるかと思います。 なお、関連する記事といたしまして、取引内容の確認・承認を Amazon Connect の Outbound Call で自動化する技術ブログ Automate transaction confirmation using outbound calls with Amazon Connect もございますので、よろしければ参考にしてみてください。 最後に、Outbound Call に関して Amazon Connect Outbound Campaign という機能もございます。この機能はアウトリーチすべきお客様のセグメントを作成し、適切なタイミング、適切なチャネル（音声通話、SMS、Email等）でプロアクティブなアプローチを実現することができます。ここに IVR を活用することもでき、オペレータが不要な大規模なアウトリーチも可能です。ぜひご検討材料の一つとしていただけますと幸いです。 まとめ 本記事では、AWS で実現する IVR と Amazon Pay を統合することによって、電話注文から決済までを実現する構想についてご紹介しました。IVR を構成する AWS のサービスについても触れ、AWS を活用することでシンプルかつスモールスタートで始められる点、加えて柔軟に機能拡張していくことができる点も AWS 活用の大きな強みです。すでにコンタクトセンターを導入されている事業者様におきましても、IVR による電話注文のチャネルだけを切り出す形で AWS にて実現することも考えられます。また、Amazon Connect で実現するコンタクトセンターの柔軟性は Amazon Bedrock や Amazon Q in Connect と組み合わせることで、生成 AI の技術要素を盛り込みさらに広げていくこともできると考えています。 本記事でご紹介した対話フローや AWS 構成図は一例ではございますので、事業者様の取り扱う商材や社内要件、ターゲットとするお客様、必要となる機能によっても変わってくる部分があるかと思いますが、電話注文のチャネルを拡張するためのアイデアの一助となりましたら幸いでございます。 著者 庭屋 郁基 アマゾンジャパン合同会社 Amazon Payments Japan 事業部 Solutions Architect

はじめに 本稿は、日本航空株式会社デジタルEX企画部 空港オペレーショングループの橋本様よりご寄稿いただいた、成田空港でのドーリー運用効率化を目的とした動態管理システム導入プロジェクトの取り組みをご紹介します。 開発の経緯 空港内では、航空機に搭載する貨物や手荷物の入ったコンテナを運ぶために、『ドーリー』と呼ばれる台車を利用しています。 ドーリーは動力を持っておらず、牽引車で複数台連結して使用されます。航空機からコンテナを降ろすときも、航空機にコンテナを搭載するときも、必ずコンテナと同じ台数のドーリーが必要となります。 航空機からコンテナを降ろし、ドーリーに載せ替える 使用中のドーリー（コンテナあり） コンテナ搭載前のドーリー ドーリーに設置されたIoT機器 しかし、成田空港では以下のような課題に直面していました。 ドーリーの利用は、複数のグループ会社にまたがるため、各社で連絡を取り合いながら、利用するドーリーをそれぞれ確保している。 未使用のドーリーが空港内のどこに何台あるのか把握する手段が無く、利用の度に各社の現場作業者が捜索をしている。 ドーリーの稼働状況が分からず適正数が配備されているか不明。 成田空港内には多くのドーリー置き場や貨物上屋が点在しており、場合によっては移動に30分以上を要することもあります。そのため、ドーリーを見つけるだけでも多大な時間と労力がかかり、業務の効率性を損なう原因となっていました。 これらの課題を解決すべく、IoTデバイスとクラウド技術を活用した「DOLYSプロジェクト」を立ち上げました。 DOLYS導入の目指すもの 本プロジェクトの核となるのは、成田空港内の約3,040台のドーリーに装着したIoTデバイスを活用することで位置情報をリアルタイムに管理し、これを可視化するシステムです。このシステムにより以下の具体的な改善目標を掲げました。 1.ドーリー捜索時間の削減 IoTデバイスでリアルタイムに位置を管理することで、ドーリーを探す時間を削減し、業務効率を向上。 2.ドーリー稼働率の向上による台数削減 効率的な運用管理により、必要な台数を最適化し、ドーリーおよびカートの台数の削減。 プロジェクト体制とアプローチ 本プロジェクトでは、成田空港におけるドーリーの運用を効率化するシステムを低コスト・短期間で構築することを目指し、アジャイル開発を採用しました。この手法により、現場の課題や要望を迅速にシステムに反映しながら、稼働までのリードタイムを最小化しました。 特徴的なポイントとして、本プロジェクトでは、JALのグループ企業である JALグランドサービス 、 JALカーゴサービス 、 JALスカイ といった複数のグループ会社の現場からの意見を広く取り入れ、現場と開発チームとの連携を密接に構築。現場スタッフを主要ステークホルダーに位置付け、ユーザー目線のシステムを実現しました。 また、プロジェクトは「必要機能のみに絞る」という方針を掲げ、シンプルかつ実用性重視のシステム設計を行ったことが特徴です。 システムのアーキテクチャ AWSを基盤にしたサーバーレスアーキテクチャを採用しています。 システムの規模やデータ量に応じたリソースの自動スケールが可能となり、運用コストを最小化しました。また、サーバーレスの特性を活かし、迅速な開発と変更対応も可能になっています。 また、本システムはJALグループの統合クラウドプラットフォームである CIEL/S 上に構築することで、AWSの柔軟性を活用しつつ、同グループに求められるITガバナンス要件と高いセキュリティ基準を満たしました。 IoT技術とAWSのクラウドサービスを組み合わせることで、IoTデバイスからのリアルタイム位置情報を効率的に収集し、ドーリーの位置情報可視化および運用の最適化を実現しました。 ※DOLYS画面（成田空港の概略図にリアルタイムでドーリー台数を表示） また、現場作業者はiPadなどのタブレット端末を活用し、直感的にドーリーの場所を検索・確認できます。ダッシュボードでは「エリア・スポットごとのドーリー配置台数」や「各会社の必要数」をリアルタイム表示し、機材の種類やコンテナ搭載の有無など細かい条件による検索機能も備えているため、現場の即時対応力と業務効率を大幅に向上させています。 ※アーキテクチャ概略図 想定効果と今後の展望 本システムの導入により、以下の効果が見込まれます。 1.稼働率の向上に伴い、新規購入台数および点検費用の削減が可能となります。具体的には、年間で56台（約7％減）の更新台数削減により、約7,170万円のコスト削減が期待されます。 2.所在の見える化により、捜索時間と燃料消費の削減が実現します。年間で約14,157時間の捜索時間が削減され、燃料も約66,361リットル（約760万円相当）が節約されます。 加えてCO2排出量は年間約171トン削減され、環境負荷の軽減にも寄与します。 ※CO2算出方法：66,361[ℓ]×0.00258[t-CO2/ℓ]=171[t] 現在は成田空港で運用が進んでいますが、同様の仕組みを羽田空港にも展開する計画が進行中です。これにより、複数の主要空港でのドーリー運用効率が向上し、さらに標準化された管理体制が構築される見込みです。 現行のDOLYSは主に「ドーリーの現在位置」と「利用可否ステータス（積載検知）」を確認する機能で活用されていますが、将来的には以下のようなデータ分析機能の追加が構想されています。 稼働率の分析：ドーリーの使用頻度や運用状況を可視化。過剰な配備や不足を是正。 リソースマネジメント：人だけでなく、設備などのリソースを最適化し、全体の運用効率を最大化。 これらのデータ分析機能により、コスト削減と業務改善をさらに推進します。 まとめ 本稿でご紹介した「DOLYSプロジェクト」は、成田空港におけるドーリー管理の課題を起点に、IoTとクラウド技術を融合させた革新的なソリューションを実現しました。AWSを活用したサーバーレスアーキテクチャにより、低コストかつ迅速なシステム構築を可能とし、現場のニーズに対応したシンプルで使いやすい管理環境を提供しています。 導入効果として、稼働率向上による更新台数の削減や捜索時間・燃料消費の大幅な削減が想定されており、コストメリットだけでなく環境負荷の低減にも寄与しています。今後は、羽田空港への展開をはじめ、データ分析機能の充実によるさらなるリソース最適化を目指し、運用効率化に貢献してまいります。 本プロジェクトは、現場を中心に据えたアジャイル開発の好例であり、デジタル化推進における成功モデルとして、今後のさらなる業務改革の礎となることを期待しています。 日本航空株式会社 デジタルEX企画部空港オペレーショングループ 橋本 隆彦 2008年、日本航空のグランドハンドリング業務を担う株式会社JALグランドサービスに入社。 現場業務を経験後、2018年より社内システム開発に関する業務などを担当。 2024年より現職に従事。DOLYSや空港オペレーション系システムを担当。 日本航空株式会社 グランドハンドリング企画部BPR推進グループ 村上 忠 1993年、日本航空のグランドハンドリング業務を担う株式会社JALグランドサービスに入社。 現場業務・間接業務（安全品質・生産計画担当）を経験後、2022年より現職に従事。 DOLYSを含む空港ハンドリングの生産性向上施策を担当。 JALデジタル株式会社 デジタル開発部第1グループ 篠原 奈都未 2018年、日本航空のITを担う株式会社JALインフォテック（現：JALデジタル株式会社）に入社。 業務システムの基盤維持管理を担当。 2021年より現職に従事。 クラウドネイティブ技術を活用したアプリ開発やアジャイル開発推進を担当。

本記事は、2025 年 8 月 6 日に公開された Amazon QuickSight BIOps – Part 3: Assets deployment using APIs を翻訳したものです。翻訳は Solutions Architect の守田 凜々佳が担当しました。 ビジネスインテリジェンス (BI) エコシステムがチーム、アカウント、環境全体に拡大するにつれて、一貫性、信頼性、ガバナンスの維持が大きな課題となります。特にマルチアカウント環境では、ダッシュボードとデータセットを手動でデプロイすることで、バージョンの不一致、依存関係の破綻、運用リスクの増大につながることがあります。 このシリーズの投稿では、 Amazon QuickSight におけるビジネスインテリジェンス運用 (BIOps) に焦点を当てています。 パート 1 では、バージョン管理とコラボレーションのノーコードガイドを提供しました。 パート 2 では、QuickSight API を使用した自動バージョン管理とロールバック、そして BI アセットの継続的インテグレーション/継続的デリバリー (CI/CD) パイプラインについて説明しました。本記事では、QuickSight における API を活用した BIOps 戦略に焦点を当て、特に以下のトピックについて説明します： API を使用したクロスアカウントおよび複数環境へのアセットの展開 データセットのバージョン更新時における競合の検出と解決 開発、QA、本番環境間での権限と設定の管理 Assets-as-Bundle API、 Describe-Definition API、自動化スクリプトなどのツールを使用して、手作業を最小限に抑え、下流での障害を防ぎながら、アセットをプログラムによって自動的にデプロイする方法を説明します。 ソリューションの概要 このシリーズの パート 2 では、QuickSight API を使用したバージョン管理、ロールバック、CI/CD ワークフローについて説明しました。本記事では、その内容を踏まえて、デプロイメントをスケールし、異なる環境間での一貫性を確保するための実践的なテクニックを紹介します。 以下のセクションでは、QuickSight における API ベースの BIOps ソリューションの概要を説明し、チームがプログラムコードを用いて BI アセットのデプロイメントとガバナンスを自動化する方法を紹介します。 QuickSight において複数の AWS アカウント・リージョン間での BI アセットのデプロイ方法について解説し、API を使用してダッシュボード、データセット、および依存関係を一貫性をもって、安全でスケーラブルな形で展開する方法を説明します。 前提条件 このチュートリアルを実施するには、以下の前提条件が必要です。 AWS アカウント 以下の AWS サービスへのアクセス: AWS CloudFormation Amazon QuickSight Amazon Simple Storage Service (Amazon S3) AWS Identity and Access Management (IAM)、QuickSight の Template 、 Assets-as-Bundle 、 Create 、 Update 、 Delete 、 Describe API にアクセスする権限を持っていること Python の基本的な知識 (Python 3.9 以降を使用) SQL の基本的な知識 最新バージョンの AWS Command Line Interface (AWS CLI) がインストールされている Boto3 がインストールされている また、続きを読む前に、このシリーズの パート 1 と パート 2 を確認することをお勧めします。 アセットデプロイメントのためのテンプレート API 「 BIOps: Amazon QuickSight object migration and version control 」では、テンプレートベースのアプローチを使用して QuickSight アセットをデプロイする方法について説明しています。執筆時点ではテンプレートは環境間でダッシュボードを移行およびバックアップするための主な手段でした。 開発環境と本番環境の 2 つの QuickSight アカウントがあるとします。両方のアカウントは、有効なデータソースに接続するように設定されています。 以下の図は、このアーキテクチャを示しています。 実装の詳細に興味がある場合は、 元の記事 を参照してください。ただし、現在ではアセットのデプロイメントにテンプレート方式を使用することはおすすめしていません。 Assets-as-Bundle や Describe-Definition などの新しい API が導入されたことで、BI チームは QuickSight アセットの管理において、より柔軟で透明性が高く、バージョン管理に適したオプションを利用できるようになりました。 アセットの一括デプロイのための Assets-as-Bundle API Automate and accelerate your Amazon QuickSight asset deployments using the new APIs では、 Assets-as-Bundle API を使用して、AWS アカウントやリージョン間で QuickSight アセットをデプロイする方法について説明しています。これらの API は、ダッシュボード、分析、データセットなど、依存関係のあるアセットのデプロイのために設計されています。 次の図は、このアプローチに基づくサンプルワークフローを示しています。 ExportAssetsBundle API は、QuickSight JSON または CloudFormation テンプレートの 2 つのエクスポート形式オプションを提供します。 QuickSight JSON オプションを使用すると、アセットは各アセットタイプ（分析、ダッシュボード、データセット、データソースなど）に対応した JSON ファイルを含む ZIP ファイルとしてエクスポートされます。 この ZIP パッケージはアセット間の関係を保持し、個々の JSON ファイルの確認や修正がしやすいため、デプロイメントの自動化に適していますが、きめ細かなバージョン管理には適していません。 コンテンツは、次のスクリーンショットに示すような階層構造で整理されています。 この サンプル Jupyter ノートブック では、QuickSight JSON 形式で、ソースアカウントからターゲットアカウントに QuickSight アセットをデプロイするための ExportAssetsBundle および ImportAssetsBundle API の使用方法を示すワークフローを提供しています。このサンプルは基本的なユースケースとなり、ソース管理の統合、バージョンタグ付け、環境固有の設定などの自動化ステップを組み込んだ包括的なデプロイメントパイプラインに拡張することができます。 アセットデプロイメントにおけるアクセス許可の管理 デフォルトでは、エクスポートされた QuickSight アセットは、エクスポート操作時に include-permissions オプションが明示的に有効化されていない限り、ユーザーレベルまたはグループレベルの権限は保持されません。 権限が含まれている場合でも、ソース環境とターゲット環境の両方でユーザー名またはグループ名が一致していない限り、アカウント間で正しくマッピングされない可能性があります。 適切なアクセス制御のために、インポートジョブの完了後に適切な UpdatePermissions API を使用して、アセットのアクセス権限を手動で更新することがベストプラクティスです。 これにより、ターゲット環境の正しいユーザーまたはグループが、インポートされたダッシュボード、分析、データセット、その他のアセットにアクセスできるようになります。 もう 1 つの選択肢は、 StartAssetBundleImportJob API の OverridePermissions パラメータを使用して、インポート時にアクセス許可を割り当てることです。インポートされたアセットへのアクセス権を付与する必要があるターゲットアカウントのユーザーまたはグループを指定できます。 ただし、このオプションは慎重に使用する必要があります。インポートジョブが完了すると、指定されたユーザーまたはグループは直ちにアセットにアクセスできるようになります。意図しないユーザーに機密性の高いダッシュボードやデータセットが公開されることを防ぐため、アクセス許可が正しく設定されていることを確認することが重要です。 環境固有の設定を使用したアセットデプロイメントの管理 StartAssetBundleImportJob API には OverrideParameters というパラメータも用意されており、BI チームはこれを使用してインポート時に環境固有の設定を上書きできます。 これには、Virtual Private Cloud (VPC) 接続、データソースの資格情報、その他のデプロイメント固有の属性などが含まれます。 OverrideParameters を使用することで、エクスポートされたバンドルファイルを直接変更することなく、新しいアカウントや環境にインポートされたアセットが正しいインフラストラクチャリソースに確実に接続できるようにします。 これは特に、ネットワークや認証設定が異なる環境間 (例えば、開発環境から本番環境) でアセットを昇格させる際に便利です。 環境やアカウント間でのアセットのデプロイデプロイメントに関するより包括的なアーキテクチャについては、 Guidance for Multi-Account Environments on Amazon QuickSight を参照してください。 このガイダンスでは、開発、検証、本番アカウントの体系的な管理、QuickSight の名前空間とアクセス許可の管理、自動化されたアセットデプロイパイプラインの実装について、企業のシステムに求められるガバナンスおよびスケーラビリティの要件を考慮したベストプラクティスを説明しています。 次の図は、このオプションのソリューションアーキテクチャを示しています。 Assets-as-Bundle API の CloudFormation テンプレートオプションは、機能的には QuickSight JSON オプションと似ています。 このオプションを選択すると、エクスポート出力は、ダッシュボードまたは分析と、データセット、データソース、テーマ、フォルダなどの依存関係をカプセル化した CloudFormation テンプレートになります。このオプションは、既に AWS CloudFormation をインフラストラクチャの自動化に使用しているチームにとって特に有用です。なぜなら、一貫したツールとデプロイメントパイプラインを使用して、他の AWS リソースと共に QuickSight アセットをデプロイおよび管理できるためです。 実践的な例として、 Assets-as-Bundle API の CloudFormation テンプレートオプションを使用した一連のワークフローを示す サンプル Jupyter ノートブック をご参照ください。 このノートブックでは、CloudFormation テンプレートを使用して、構造化された再現可能な形でアセット昇格を実現するために QuickSight のアセットをアカウント間でエクスポートおよびデプロイする方法を示しています。 以下の表は、CloudFormation テンプレートを用いる方法と QuickSight JSON ( Assets-as-Bundle API) を用いる方法を比較したものです。 項目 CloudFormation テンプレート QuickSight JSON エクスポート形式 YAML/JSON 形式の CloudFormation テンプレート ZIP アーカイブ内の構造化された JSON ファイル 目的 AWS CloudFormation ベースの Infrastructure as Code (IaC) ワークフローとの統合 QuickSight ネイティブ形式でのアセットの移植性と検査の簡素化 対象範囲 ダッシュボード、分析、および依存関係を含む ダッシュボード、分析、および依存関係を含む 変更可能性 AWS CloudFormation の構文知識が必要；より厳格 読み書きが容易；JSON は QuickSight の内部構造に従う デプロイメント方法 CloudFormation スタックを使用してデプロイ ImportAssetsBundle API を使用してインポート 開発ツールの互換性 AWS CloudFormation ベースの環境に最適 JSON ベースのワークフローまたはカスタムデプロイメントスクリプトに最適 可読性 BI ユーザーにとって直感的ではない；インフラ指向 BI チームにとってより直感的； Describe API と密接に連携 ユースケースの適合性 BI アセットのデプロイメントを広範な IaC テンプレートに統合するチーム向け QuickSight アセットの移行やコードベースのワークフローに焦点を当てたチーム向け Assets-as-Bundle API で利用可能な QuickSight JSON と CloudFormation テンプレートのオプションについて詳しく比較するには、 Choosing between the two export options of the Amazon QuickSight asset deployment APIs をご参照ください。 この記事では、それぞれのオプションの長所と短所について詳しく説明し、実際の例を示しながら、BI チームがデプロイメントワークフローと自動化のニーズに最適なフォーマットを選択できるようにサポートします。 Automate your Amazon QuickSight assets deployment using the new Amazon EventBridge integration では、 Assets-as-Bundle API を Amazon EventBridge と連携してデプロイメントワークフローを自動化する方法を説明しています。 QuickSight アセットの作成、更新、削除などのイベントに応答する EventBridge ルールを設定することで、チームは環境間でアセットのエクスポート、バージョン管理、昇格を行うワークフローを自動的にトリガーできます。この連携は、QuickSight の BI アセットに対してイベントドリブンの CI/CD パイプラインを実現する上で特に有用です。 アセットの段階的なデプロイのための Describe-Definition API このシリーズの パート 2 では、 Describe-Definition API を使用して、単一の QuickSight アカウント内でバージョン管理を行う方法について説明しました。 同じ原則をマルチアカウント構成に拡張することで、環境全体で BI アセットの体系的かつ選択的なデプロイが可能になります。 個々のアセットのデプロイに Describe API を使用することは、多くのシナリオでベストプラクティスとされています。例えば、関連するダッシュボードを更新せずに本番アカウントのデータセットの問題を修正するための緊急デプロイを実行する場合や、依存アセットに影響を与えずにダッシュボード内のフィルター定義を更新する場合などです。このきめ細かな制御により、デプロイのリスクを軽減し、不要な上書きを回避し、大規模な BI 環境における段階的な開発ワークフローとの整合性を保つことができます。 サンプルコードについては、QuickSight アセットのデプロイに関する 2 つの一連の自動化オプションを説明している BIOps: Amazon QuickSight object migration and version control を参照してください。 この記事は元々テンプレートベースのアプローチに基づいていましたが、基本的な概念は今でも有用です。 関連する GitHub リポジトリ で提供されているコードを再利用および応用することができます。 従来のテンプレート関連の API 呼び出しを、新しい DescribeDashboardDefinition やその他の Describe-Definition API に更新することで、バージョン管理されたリソースのデプロイに関する現在のベストプラクティスに沿って、同じ自動化ワークフローを拡張できます。 API メソッドの比較 以下の表は、 Assets-as-Bundle API と Describe-Definition API の使用を比較したものです。 比較項目 Assets-as-Bundle API Describe-Definition/Describe API 主なユースケース 環境、アカウント、リージョン間での関連アセットのデプロイ バージョン管理、モジュール開発、CI/CD 統合 粒度 依存関係 (データセット、ソース、テーマ、フォルダ) を含むダッシュボードと分析を完全にバンドル 個別のアセット定義に焦点を当てる 可視性 ZIP ファイルに埋め込まれた JSON または CloudFormation テンプレート；追加作業を要して内容確認が可能 API を通じて直接アクセス可能な、完全に可視化された行単位の JSON 定義 バージョン管理との適合性 理想的ではない；差分の確認、モジュール化、レビューが困難 優れている；Git ベースのワークフロー、レビュー、ロールバックに適している コンポーネントの再利用性 限定的；バンドルは自己完結型で、複数バンドルのシナリオではデータセットが重複する可能性がある 高い；適切に設計されたソリューションでは、コンポーネント (計算フィールド、フィルター) をアセット間で再利用およびモジュール化できる 開発ワークフロー QuickSight の既存のダッシュボードまたは分析からバンドルを作成 JSON をプログラムで作成または変更し、 Update API を使用して適用 デプロイメントワークフロー ExportAssetsBundle を使用してエクスポートし、 ImportAssetsBundle を使用してインポート Create または Update API を使用して変更をプッシュ 最適な用途 環境間でのダッシュボードとその依存関係をパッケージとして移行する場合 反復的な開発、CI/CD、コードベースの作業を行う BI チーム向け 制約 バンドルが大きく、冗長なアセットが含まれる可能性がある；個別のコンポーネントの分離や編集が困難 依存アセット (データセット、ソース、テーマ) は含まれず、別途処理が必要 バックアップ、リストア、ディザスタリカバリ このセクションでは、QuickSight API を使用して BI アセットのバックアップ、リストア、リカバリを行い、信頼性の高いディザスタリカバリを実現し、環境全体でのデータ損失を最小限に抑える方法について説明します。 QuickSight アセットのバックアップ、リストア、ディザスタリカバリには、 Assets-as-Bundle API と Describe-Definition API の両方を使用できます。 アセットを定期的にバンドル (ZIP ファイルまたは CloudFormation テンプレート) または個別の JSON 定義としてエクスポートすることで、BI チームは Amazon S3、Git、その他のリポジトリに保存されるバージョン管理されたバックアップを作成できます。 Assets-as-Bundle API を使用すると、チームはダッシュボードごとにバックアップを整理し、各ダッシュボードをその依存関係 (データセット、データソース、テーマなど) と共にエクスポートできます。このアプローチは便利で、ダッシュボード単位でのリカバリに適しています。 一方、 Describe-Definition API はより柔軟性が高いものの、より多くの労力を必要とします。 BI チームは、すべてのアセットを個別にリストアップし、タイプ別 (データソース、データセット、分析) に保存し、モジュール式のバックアップ構造を維持できます。確実な復元のためには、データソースから始まり、データセット、テーマ、最後にダッシュボードと分析という依存関係を意識した適切な順序でアセットを再デプロイする必要があります。 前述のとおり、記事 BIOps: Amazon QuickSight object migration and version control では、テンプレートベースのアプローチを使用して QuickSight アカウントのアセットをバックアップおよび復元するためのサンプル実装を提供しています。関連する Jupyter ノートブック では、アカウント全体でのアセットの一括エクスポートとインポートを自動化する方法を説明しています。 もともとはテンプレートを中心に構築されていましたが、関連する API 呼び出しを Describe-Definition API に置き換えることで、現在のベストプラクティスに沿った、スケーラブルで保守可能なバックアップおよび復元ワークフローを作成できます。 さらに、チームは QuickSight フォルダを使用してバックアップを整理し、関連するアセットを構造化された復旧戦略の一部としてグループ化することで、より直感的に復元の操作を管理できます。フォルダベースのバックアップと復元のアプローチについては、こちらの サンプル Jupyter ノートブック を参照してください。このノートブックでは、フォルダで整理された QuickSight アセットのエクスポートと再インポートの方法を示しており、BI チームが関連するアセット (ダッシュボード、分析、データセット) をグループ化して一括管理できるようになっています。 データセットとダッシュボード間のマージコンフリクトの解決方法 このセクションでは、QuickSight でデータセットとダッシュボード間のマージのコンフリクトを検出し解決する方法について説明し、スキーマの変更が依存する可視化やフィルターを壊さないようにする方法を解説します。 次の図は、データセットのバージョン管理とコンフリクト解決のワークフローを示しています。 このプロセスは初期データセット (v1) から始まり、フィールドの名前変更やデータ型の変更などの更新が発生したかどうかを評価します。更新が検出されると、データセットはバージョン 2 (v2) に進み、潜在的なマージのコンフリクトをチェックします。コンフリクトが見つかった場合、フィールドマッピング（例えば、名前が変更されたフィールドを再マッピングしてビジュアルを復元する）によって解決できるかどうかを判断します。コンフリクトが解決可能な場合、影響を受けたアセットを復旧するためにマッピングが適用されます。解決できない場合（例えば、データ型の変更による場合）、サンプルコードを使用して変更されたフィールドを自動的に検出し、未解決の変更によって破損したフィルターやビジュアルをクリーンアップできます。 データセットのマージのコンフリクトを検出して処理するためのサンプルコードは、以下の Jupyter ノートブック で入手できます。このノートブックでは、変更されたフィールドを自動的に特定し、フィールドのデータ型の変更などの単純なマッピングの問題を解決し、互換性のない変更によって破損したフィルターをクリーンアップする方法を示しています。 さらに、QuickSight データセットの更新時にマージのコンフリクトの検出を自動化するためのサンプルコードと GitHub Actions ワークフローを提供しました。Python スクリプト compare_quicksight_datasets.py は、データセットのバージョンを比較して、データ型の変更、フィールド名の変更、フィールドの追加、フィールドの削除を特定します。 GitHub Actions ワークフロー compare-quicksight.yml は、比較を実行するために自動的にトリガーされます。 比較結果はリポジトリの新しいアーティファクトとして保存され、BI チームが変更内容を確認し、データセットのバージョン昇格時にコンフリクトを自動的に解決するか、手動での対応を行うかの判断を下すことができます。 ワークフローを設定して実行するには、以下のステップを完了してください： YAML ファイルが正しい GitHub ディレクトリに保存されていることを確認してください。 .github/workflows/compare-quicksight.yml リポジトリは以下のような構造になっているはずです。 your-repo/ ├── .github/ │ └── workflows/ │ └── compare-quicksight.yml ├── compare_quicksight_datasets.py ├── ... 以下の例のように compare-quicksight.yml に有効なトリガーが含まれていることを確認してください。 name: Compare QuickSight Datasets on: workflow_dispatch: # 手動トリガーを許可 この方法により、 Actions タブからワークフローを手動で実行できます。 ワークフローファイルをリポジトリにコミットしてプッシュします： git add .github/workflows/compare-quicksight.yml git commit -m "Add QuickSight dataset comparison workflow" git push origin main GitHub リポジトリのシークレットを追加します： GitHub リポジトリに移動し、 Settings, Secrets and variables, Actions を選択します。 New repository secret を選択します。 以下のようなシークレットを追加します： AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_REGION QUICKSIGHT_ACCOUNT_ID NEW_DATASET_ID ワークフローを実行します： GitHub リポジトリに移動します。 Actions タブで、 Compare QuickSight Datasets を選択します。 Run workflow を選択し、必要な入力情報を提供します。 このユーティリティは、バージョン管理やデプロイメントパイプラインの一部として使用できます。また、BI チームは分析やダッシュボードで影響を受けるビジュアルやフィルターを直接確認して更新することで、手動でコンフリクトを解決できます。 リソースの削除 今後の料金発生を防ぐため、テスト中に作成した S3 バケット、QuickSight データセット、分析、ダッシュボード、サンプルスクリプトで使用したその他のリソースなどを削除してください。 まとめ QuickSight API の機能により、大規模な BI アセットを管理するための強力な自動化、ガバナンス、柔軟性が実現可能になります。本記事では、クロスアカウントおよび複数環境のデプロイメント、コンフリクトの検出とガバナンスに API を使用する方法について説明しました。本記事のガイダンスを使用して、QuickSight の信頼性が高くコンフリクトを考慮したデプロイメント手法を確立できます。 著者について Ying Wang は、AWS の Generative AI 組織の Senior Specialist Solutions Architect で、Amazon QuickSight と Amazon Q を専門とし、大規模エンタープライズおよび ISV のお客様をサポートしています。データアーキテクトおよびソフトウェア開発エンジニアリングマネージャーとしての強固な経験を持つとともに、データ分析とデータサイエンスの分野で 16 年の経験を有しています。データアーキテクトとして、お客様のクラウドにおけるエンタープライズデータアーキテクチャソリューションの設計とスケーリングを支援してきました。エンジニアリングマネージャーとしては、エンジニアリングとプロダクトの双方の観点から新機能の提供と製品革新を推進し、QuickSight を通じてお客様のデータの力を引き出すことを可能にしました。

本記事は、2025年8月6日に公開された Amazon QuickSight BIOps – Part 2: Version control using APIs を翻訳したものです。翻訳は ProServe Data Analytics Consultant の西澤 祐介が担当しました。 この記事では、API駆動のビジネスインテリジェンスオペレーションズ（BIOps）フレームワークの概要を説明します。このフレームワークは、手作業による負荷を軽減し、Amazon QuickSightにおけるライフサイクル管理を改善することを目的としています。 ビジネスインテリジェンス (BI) 環境が複雑化する中で、ダッシュボード、データセット、デプロイといった作業を手動で管理していると、結果の不整合、バージョンのずれ、コラボレーションの効率低下といった課題につながりがちです。データから得られるインサイトの提供をスケールさせ、ガバナンスを強化し、そして開発、QA（品質保証）、本番といった各環境の信頼性を高める上で、自動化は極めて重要になります。 DevOps は、ソフトウェア開発と IT 運用を統合することで、デリバリーを加速し、信頼性を向上させるための考え方です。ソフトウェアのワークフローを合理化し、スケールさせるために、DevOps では以下のプラクティスが重視されます。 継続的インテグレーションと継続的デリバリー（CI/CD） Infrastructure as Code (IaC) と Assets as Code (AaC) 自動化 モニタリング コラボレーションツール（Git、Jira、Slackなど） BIOps は、これらの原則を BI のワークフローに応用したものです。アセットのバックアップ、バージョン管理、デプロイを自動化することで、BI チームはダッシュボード、データセット、分析を、一貫性を高め、トレーサビリティを向上させ、より効率的に管理できるようになります。 このブログシリーズでは、皆様が QuickSight で BIOps のプラクティスを実装し、よりスケーラブルで信頼性の高い BIOps を実現するための方法について解説します。 パート1 では、ノーコードでのバージョン管理とコラボレーションに関するガイドを提供しました。この記事では、QuickSight API を使用してバージョン管理とロールバックを自動化し、BI アセットのための CI/CD パイプラインを構築する方法について解説します。そして パート3 では、クロスアカウントおよびマルチ環境でのデプロイ、競合の検出とガバナンスについて取り上げます。 ソリューションの概要 この記事では、QuickSight における API ベースの BIOps ソリューションの概要を解説し、チームがプログラムによって制御する手法で BI アセットのバージョン管理、デプロイ、ガバナンスを自動化する方法を紹介します。BI エンジニア、DevOps リード、そしてプラットフォーム管理者の方々は、この記事で紹介するコードベースのプラクティスを実践することで、BI ワークフローをスケールさせることができます。 前提条件 このチュートリアルを進めるにあたり、以下の前提条件が必要です。 AWS アカウント &nbsp;以下の AWS サービスへのアクセス権: AWS CloudFormation Amazon QuickSight Amazon Simple Storage Service (Amazon S3) AWS Identity and Access Management (IAM)：QuickSight の Template , Assets-as-Bundle , Create , Update , Delete , Describe API を利用できる権限が必要です。 Python の基本的な知識（Python 3.9 以降を推奨） SQL の基本的な知識 最新バージョンの AWS Command Line Interface (AWS CLI) が インストール 済みであること Boto3 がインストール済みであること また、このチュートリアルを始める前に、シリーズの パート1 を確認しておくことをお勧めします。 QuickSight アセット API の概要 QuickSight は、BI アーティファクトを管理するための API ベースのアプローチを複数提供しています。バージョン管理、デプロイの自動化、バックアップといった目的に応じて、それぞれ強みの異なる API を使い分けることができます。 主なアプローチは以下の3つです。 Template API (旧来の方法) Assets-as-Bundle API (新しい方法) Describe-Definition API これら3つのアプローチは、いずれもダッシュボード、分析、データセットなどをプログラムで扱うことを可能にしますが、可視性、制御性、そして最新の CI/CD ワークフローとの親和性において大きく異なります。 Template API 「テンプレート」ベースのアプローチは、 CreateTemplate や CreateDashboard といった API を利用し、AWS アカウントや AWS リージョンをまたいで QuickSight のアセットを移行するための従来からの手法でした。従来、「テンプレート」はダッシュボードのバックアップや、他の環境へのアセットのデプロイに使用されてきました。初期の実装では、「テンプレート」の中身は不透明で、BIチームにとっては完全なブラックボックスでした。しかし、 DescribeTemplateDefinition API の登場により、チームは「テンプレート」のJSON 定義を抽出して、内容の確認やバックアップを行えるようになりました。とは言え、「テンプレート」は新しい他の方法に比べて柔軟性に欠け、反復的な開発、フィールドレベルでの編集、あるいはバージョン管理といったワークフローには最適化されていません。 それでも、Git リポジトリや S3 バケットといった外部のバージョン管理システムやストレージをセットアップせずに、QuickSight 環境内にバックアップを保存したいと考える BI チームにとっては、「テンプレート」は依然として有用です。このため、製品内でのアセット管理を中心に行いたいチームにとって、「テンプレート」は手軽な選択肢となります。 QuickSight アセットに関する Template API の全リストは以下の通りです。 CreateTemplate DeleteTemplate DescribeTemplate DescribeTemplateDefinition UpdateTemplate UpdateTemplatePermissions Assets-as-Bundle API CI/CDパイプラインを導入したり、IaC を実践したりしているチームにとって、モダンな Assets-as-Bundle API と Describe-Definition API は、より高い透明性、柔軟性、そして制御性をもたらします。そのため、今日の多くのエンタープライズ向けのユースケースにおいて推奨されるアプローチとなっています。 Assets-as-Bundle API は、よりモジュール化され、ポータビリティの高いデプロイの選択肢を提供します。この API は、QuickSight のダッシュボードや分析、そしてそれらに関連するアセット（データセット、データソース、テーマ、フォルダ）を、ZIP アーカイブ、または AWS CloudFormation テンプレートとしてエクスポートします。エクスポートされたアーカイブを展開すれば、アセットのメタデータを JSON ファイルとして確認することは可能ですが、それには手間がかかり、きめ細かいバージョン管理には理想的ではありません。さらに、複数のダッシュボードをエクスポートする際には、複数のバンドル間でデータセットが重複し、冗長な形で含まれてしまう可能性があります。QuickSight のインポート処理はこれらの重複を適切に処理し、意図しない上書きを防いでくれますが、やはりこの手法は、詳細なバージョン管理というよりは、関連アセットをまとめてデプロイする用途に適しています。 ソースアカウントからバンドルファイルをエクスポートするジョブの開始、追跡、詳細確認には、以下の API を使用します。バンドルファイルとは、呼び出し元が指定したアセットと、オプションでそのアセットが依存するすべてのリソースを含む ZIP ファイル（拡張子は .qs ）のことです。 StartAssetBundleExportJob – アセットバンドルファイルをエクスポートするための非同期 APIです。 DescribeAssetBundleExportJob – エクスポートジョブのステータスを取得するための同期 APIです。成功した場合、レスポンスにはバンドルを取得するための署名付き URL が含まれます。 ListAssetBundleExportJobs – 過去のエクスポートジョブを一覧表示するための同期 API です。リストには、過去15日間の完了したジョブと実行中のジョブが両方含まれます。 以下の API は、バンドルファイルを入力として受け取り、ターゲットのアカウントでアセットを新規作成または更新するインポートジョブの開始、追跡、詳細確認を行います。 StartAssetBundleImportJob – アセットバンドルファイルのインポートを開始するための非同期 API です。 DescribeAssetBundleImportJob – インポートジョブのステータスを取得するための同期 API です。 ListAssetBundleImportJobs – 過去のインポートジョブを一覧表示するための同期 API です。リストには、過去15日間の完了したジョブと実行中のジョブが両方含まれます。 Describe-Definition API `Describe-Definition API` は、各アーティファクトの内部的な JSON 構造を、透過的かつフィールドレベルのフォーマットで公開します。この定義ファイルは Git で追跡したり、プルリクエストを通じてレビューしたり、対応する Update API で更新したりすることが可能です。そのため、CI/CD パイプラインや IaC プラクティスとの統合に最適な手法と言えます。主なトレードオフは、データセットやデータソースといった依存関係を個別に扱う必要がある点です。これらはダッシュボードや分析の定義には自動でバンドルされないためです。 Describe-Definition API には以下が含まれます。 DescribeDataSource DescribeDataSet DescribeAnalysisDefinition DescribeDashboardDefinition 実際の現場では、多くの BI チームは両方のアプローチを併用しています。アセットをまとめてデプロイする際には Assets-as-Bundle を、そして、きめ細かいバージョン管理や反復開発には Describe-Definition を利用する、といった使い分けです。それぞれの API をいつ使うべきか理解することで、ガバナンスの強化、監査性の向上、そして環境間でのスムーズなアセットの移行が可能になります。 各手法の比較 以下の表は、これら3つの API 手法の主なユースケースとデータの保管場所をまとめたものです。 手法 主なユースケース 用途 保管場所 Template API 製品内でのバックアップ、レガシーなデプロイ UI 中心のチーム、シンプルなバックアップ QuickSight 内 Describe-Definition API きめ細かいバージョン管理と自動化 CI/CD、Git との連携 Git, Amazon S3, コードリポジトリ Assets-as-Bundle API 依存関係を含めた環境単位のデプロイ 開発環境から本番環境への展開、一括移行 Amazon S3, ローカルのZIPアーカイブ QuickSight APIに関するより詳細な情報については、 QuickSight API リファレンス や Boto3 QuickSight ドキュメント をご参照ください。 BI アーティファクトのバージョン管理におけるベストプラクティス これ以降のセクションでは、単一アカウント内でのダッシュボードのバージョン管理に関するベストプラクティスを解説します。 QuickSight において、「ダッシュボード」は他の人が見れるように設定された、「分析」のスナップショットです。一方、「分析」は、BI チームが開発や改善を繰り返すための作業用アセットです。QuickSight の UI 上では、バージョン管理機能は「ダッシュボード」に対してのみ提供されています。これは、「分析」がエンドユーザーに公開されることはなく、常に開発中のものと見なされているためです。 しかし、 Describe-Definition API のようなプログラム的な手法を用いると、分析の各要素（フィルター、計算フィールド、ビジュアル、パラメーターなど）を、モジュール化されたコードブロックとして扱うことができます。これにより、チームは構造化されたコード駆動の方法で「分析」を管理し、バージョンを記録していくことが可能になります。結果として、複数の作成者が並行して共同作業を進められるようになります。そのため、 Describe-Definition API を利用する際には、「分析」自体のバージョン管理も重要なプラクティスであると我々は考えています。 Template API を利用したバージョン管理 以前のブログ記事「 BIOps: Amazon QuickSight object migration and version control 」では、テンプレートベースのアプローチを用いて QuickSight のダッシュボードのバージョン管理を実装する方法を解説しました。その記事の執筆時点では、「テンプレート」が、「ダッシュボード」のバージョン管理を行うための唯一利用可能なメカニズムでした。 次の図は、そのソリューションで用いたアーキテクチャを示したものです。 このワークフローは以下のステップで構成されます。 まず、BI 開発者が「分析」を作成し、それに基づいて「テンプレート」を保存します。これらがバージョン1のアセットとなります。 この「分析」は「ダッシュボード」として公開され、QA チームがこのバージョン1の「ダッシュボード」に対してテストを実施します。 QA テストの後、BI 開発者は「分析」の改修を続け、バージョン2を構築します。 更新された「分析」は、バージョン2の「ダッシュボード」として公開されます。 QA チームはバージョン2の「ダッシュボード」をテストし、結果に応じて以下のアクションのいずれかを実行します。 テストに合格した場合： BI 管理者は「テンプレート」を更新し、バージョン2の内容を反映させます。 問題が発見された場合： BI 開発者は分析上で修正を試みます。 問題が修正可能な場合、バージョン2の開発が継続されます。 問題が修正不可能な場合、BI 管理者はバックアップ用の「テンプレート」を使ってバージョン1にロールバックできます。 QuickSight には、作成者がセッション中に以前のバージョンに戻せる Undo 機能があります。もし Undo の履歴がリセットされた場合（例えばデータセットの置換など）、あるいは以前に安定版として確認済みの状態へのロールバックが必要になった場合は、BI 管理者はバージョン1の「テンプレート」と UpdateAnalysis API を使って分析を復元できます。 BI 開発者は、この復元されたバージョン1の「分析」をベースに作業を再開し、次の安定バージョンを目指して開発サイクルを繰り返します。 Describe-Definition API を利用したバージョン管理 次の図は、 Describe-Definition API と Create または Update API を利用して、QuickSight アセットのバージョン管理を実装するためのアーキテクチャを示したものです。 ワークフローは以下のステップで構成されます。 アセットの作成と保存 BI チームは、 Describe-Definition API のレスポンス構文を参考に、プログラムで QuickSight アセットの構築を開始できます。ダッシュボードや分析は、シート、計算フィールド、ビジュアル、フィルター、パラメーターといった JSON ベースの構成要素を使って構築可能です。同様に、データセットも物理テーブルと論理テーブルのマッピングを定義する JSON 構造を用いて作成できます。QuickSight のアセットは構造化された JSON 形式に従っているため、コード駆動の開発に適しています。 学習のハードルを下げるために、まず QuickSight コンソールを使ってアセットを作成し、その設定が要件を満たしていることを確認した上で、 Describe-Definition API でアセットの定義を抽出する方法もあります。抽出した JSON 定義は、Git、Amazon S3、あるいは社内のコードリポジトリといったバージョン管理が可能な場所に保存できます。これは、UI ベースの開発からコード駆動の開発へスムーズに移行するのに役立ちます。 チームが既に本番環境にアセットをデプロイ済みで、そこからプログラムによるワークフローに移行したい場合は、本番アカウントから直接 Describe-Definition API で定義を抽出できます。その定義を開発環境のソースリポジトリ（Git や Amazon S3 など）に保存し、今後の開発やデプロイの起点として利用することが可能です。 JSON 定義のデプロイと可視化 BI チームが JSON 定義の開発を完了したら、 Create または Update API （ CreateDashboard , UpdateAnalysis , UpdateDataSet など）を使ってアセットをデプロイし、QuickSight コンソール上で直接内容を可視化します。これにより、コードからビジュアルへのシームレスな移行が実現し、バージョン管理されている定義が UI に一貫して反映されるようになります。 テストと本番環境へのデプロイ 開発環境や QA 環境にアセットをデプロイした後、BI チームはテストを実施し、アセットが機能面・ビジュアル面で要件を満たしているか検証します。検証後、テスト済みの定義を同じ Create または Update API を使って本番アカウントへデプロイすることで、統制の取れた一貫性のあるリリースプロセスを実現できます。更新された分析を QA という名前のフォルダにデプロイする サンプルコード 、QA アカウントへデプロイする サンプルコード を用意してますのでご確認下さい。 以下の サンプルコード は、「分析」の定義を取得し、dev という名前のフォルダにコピーします。これにより、BI チームはアセットをプログラムで開発・管理できるようになります。 def describe_analysis_definition(session, id): qs = session.client('quicksight') sts_client = session.client("sts") account_id = sts_client.get_caller_identity()["Account"] try: response = qs.describe_analysis_definition( AwsAccountId=account_id, AnalysisId=id) except Exception as e: return ('Faild to describe analysis: ' + str(e)) else: return response try: sample_analysis = func.describe_analysis_definition(qs_session, analysisid) print('Successfully get sample analysis contents.') except Exception as e: faillist.append({ "Action": "scenario_1_dev: get sample analysis contents", "Error Type": "describe_analysis_contents Error", "AnalysisID": analysisid, "Name": 'template_1', "Error": str(e) }) new_id = 'copy_t_1_' + str(int(time.time())) new_name = 'copy_t_1' try: res = func.copy_analysis(qs_session, sample_analysis, new_id, new_name, 'owner', dev_config["assets_owner"]) except Exception as e: faillist.append({ "Action": "scenario_1_dev: copy analysis", "Error Type": "copy_analysis Error", "AnalysisID": analysisid, "Name": 'template_1', "Error": str(e) }) time.sleep(20) status = func.check_object_status('analysis', new_id, qs_session) print('Copy status of analysis ' + new_id + ' is ' + status) if status == 'CREATION_SUCCESSFUL': res = func.locate_folder_of_asset(qs_session, new_id, dev_config["dev_folder"], 'ANALYSIS') print('Successfully copied analysis ' + new_id + ' in dev account/folder.') 以下の サンプルコード は、「分析」を定義し、計算フィールド、パラメーター、フィルターをプログラムで追加するものです。これらの二次的なアセット（計算フィールド、フィルター、パラメーター）は、再利用可能なコードブロックとして共有ライブラリに保存されます。 { "most_recent": { "DataSetIdentifier": "ds_assets_as_code", "Name": "most_recent", "Expression": "max({date_time})" } , "Calculated TimeFrame": { "DataSetIdentifier": "ds_assets_as_code", "Name": "Calculated TimeFrame", "Expression": "datediff(${StartDate},${Enddate},'DD')" } } """ Now, please add CalculatedFields """ f = open('Assets_as_Code/library/2nd_class_assets/analysis_cf_library.json') l_cf = json.load(f) cf_name = 'most_recent' try: res = func.update_analysis(qs_session,new_id, new_name, new_analysis, 'CalculatedFields', l_cf[cf_name]) except Exception as e: faillist.append({ "Action": "scenario_2_dev: add CalculatedFields", "Error Type": "update_analysis Error", "AnalysisID": new_id, "Name": new_name, "Error": str(e) }) print(cf_name + " is successfully added into analysis " + new_name) """ Now, please add parameters (keyword: ParameterDeclarations) """ new_analysis = func.describe_analysis_definition(qs_session, new_id) f = open('Assets_as_Code/library/2nd_class_assets/parameter_library.json') l_p = json.load(f) p_name = "StartDate" try: res = func.update_analysis(qs_session,new_id, new_name, new_analysis, 'ParameterDeclarations', l_p[p_name]) except Exception as e: faillist.append({ "Action": "scenario_2_dev: add ParameterDeclarations", "Error Type": "update_analysis Error", "AnalysisID": new_id, "Name": new_name, "Error": str(e) }) print(p_name + " is successfully added into analysis " + new_name) ビルド済みの関数群は GitHub で公開されています。 ライブラリ 、 ユーティリティ 、 設定サンプル 、 ロギングヘルパー といったその他の補助コードは、以下の ディレクトリ に格納されています。 次のスクリーンショットは、AaC（Assets as Code）アプローチにおけるサンプルコードのディレクトリ構造を示したものです。パッケージ全体をダウンロードし、独自のAaCソリューションを構築するためのベストプラクティスとしてご活用ください。 このアーキテクチャでは、バージョン管理は Git リポジトリや Amazon S3 のバージョニング機能といった外部の仕組みで扱われます。このアプローチにより、BI チームはアセットを並行開発したり、計算フィールド、フィルター、ビジュアルといった二次的なアセットを再利用したりすることが可能になります。例えば、チームは計算フィールドの定義を、標準化された名前を持つ独立した JSON オブジェクトとして保存できます。これにより、複数の分析やダッシュボードをまたいで再利用できるようになります。この手法のさらなるメリットとしては、プルリクエストによる行単位のコードレビュー、以前のバージョンへの簡単なロールバック、そして CI/CD ワークフローとのシームレスな統合などが挙げられます。 まとめると、このパターンは QuickSight を完全にコード駆動のプラットフォームへと変革し、インフラと BI アセットをコードとして扱うことを可能にします。 QuickSight UI と API を併用したハイブリッドワークフローによるバージョン管理 BI チームは、このアーキテクチャを拡張してハイブリッドモデルを構築することもできます。つまり、開発は QuickSight UI で行い、バージョン管理を API 経由で行うというモデルです。このアプローチでは、チームは QuickSight コンソール上で対話的にアセットの構築や更新を続けます。開発が完了し、アセットがテストに合格したら、チームは Describe-Definition API を使って更新された JSON 定義を抽出し、Git や Amazon S3 といったバージョン管理リポジトリに保存します。 このモデルは、UI ベース開発の容易さと柔軟性を、コードベースのバージョン管理が持つ構造性やトレーサビリティと組み合わせるものです。プログラムによるワークフローへ移行しようとしているBI チームにとっては、まさに両者の良いとこ取りと言えるでしょう。 次の図は、UI ベースの開発とコードベースのバージョン管理が持つ構造性やトレーサビリティを組み合わせたアーキテクチャを示しています。 ワークフローは以下のステップで構成されます。 BI の作成者は、ダッシュボード、分析、データセット、データソース、テーマを QuickSight コンソール上で直接開発します。 開発が完了し、アセットが機能面・ビジュアル面のテストに合格したら、チームは Describe-Definition API を使ってアセットの定義をエクスポートし、Git やAmazon S3 に保存します。 検証済みのアセットは、 Create または Update API を使って本番環境にデプロイされます。 作成者は、次のバージョンに向けてUI 上で同じアセットの開発を再開します。 作成したバージョンはテストされます。 テストに合格した場合：リポジトリにあるバージョン管理された JSON 定義を更新し、ステップ6に進みます。 テストに失敗した場合：Git や Amazon S3 に保存しておいた以前の定義を使い、 Update API を介して QuickSight UI 上のアセットをロールバックします。 更新された、あるいはロールバックされた定義を本番アカウントにデプロイすることで、安定したバージョン管理下でのリリースを実現します。 Amazon EventBridge を利用した QuickSight のバージョン管理自動化 Amazon EventBridge を利用すると、個々の QuickSight アセット（分析、ダッシュボード、VPC 接続など）やフォルダ構造への変更を、アセットレベルのイベントとしてほぼリアルタイムに捉え、監視することができます。ここで言うイベントには、アセットの作成、更新、削除、フォルダ構成の変更などが含まれます。詳細については、「 Automate your Amazon QuickSight assets deployment using the new Amazon EventBridge integration 」をご参照ください。 QuickSight と EventBridge を連携させることで、BI チームは特定のアセットやフォルダが変更された際に、後続のワークフロー（例えば AWS Lambda や AWS Step Functions ）を自動的にトリガーするルールを定義できます。これにより、アセット定義のエクスポート、Git や Amazon S3 へのスナップショット保存、監査やロールバックのためのタグ付けといったバージョン管理プロセスがシームレスになります。結果として、チームは手動での介入なしにガバナンスを自動化し、環境間の一貫性を維持できるようになります。 Assets-as-Bundle APIを利用したバージョン管理 Assets-as-Bundle API をバージョン管理に利用することは推奨しません。この API の主なユースケースは、ダッシュボードとその依存関係にあるアセットを環境間で移行（例えば、開発環境から QA、本番環境へ）することです。バンドルファイルは技術的には保存して再利用できますが、きめ細かい追跡、比較、モジュール開発にはあまり適していません。適切なバージョン管理のためには、 Describe-Definition API を Git や Amazon S3 ベースのストレージと組み合わせて利用してください。 クリーンアップ 将来的な課金を防ぐため、テスト中に作成した S3 バケット、QuickSight のデータセット、分析、ダッシュボード、その他サンプルスクリプトで利用したアセットなどのリソースは削除してください。 まとめ この記事で解説した QuickSight API の機能は、BI アセットを大規模に管理するための強力な自動化、ガバナンス、そして柔軟性をもたらします。これらの API により、アセットのライフサイクルを完全にコントロールし、CI/CD パイプラインや Git ベースのワークフロー、カスタムツールとシームレスに連携させることが可能になります。ダッシュボードのバージョン管理、環境をまたいだデプロイ、スキーマ競合の解決などを簡単に行うことができます。 きめ細かい制御、監査性、アカウントやリージョンをまたいだ再現可能なデプロイが必要な場合は、API を利用してください。スピード、使いやすさ、あるいは手軽なイテレーションを優先する場合は、QuickSight コンソールを利用しましょう。多くのチームにとっては、QuickSight コンソールで開発し、変更のキャプチャを API で行うというハイブリッドなアプローチが、両方の長所を活かす最良の方法となるでしょう。 BIOps プラクティスを導入することで、BI チームはデリバリーをスケールさせ、リスクを低減し、一回限りの開発から、信頼性が高く統制の取れたインサイトの創出へと移行することができます。 パート3 では、クロスアカウントおよびマルチ環境でのデプロイ、そして競合の検出とガバナンスについて解説します。

本記事は、2025年8⽉6⽇に公開された Amazon QuickSight BIOps – Part 1: A no-code guide to version control and collaboration を翻訳したもの です。翻訳は Public Sector PSA の西川継延が担当しました。 ビジネスインテリジェンス（BI）チームが成長するにつれて、ダッシュボード、データセット、分析の管理はますます複雑になります。明確なバージョン管理なしでのコラボレーションは、作業の上書き、レポートの不整合、本番環境でのエラーにつながる可能性があります。ビジネスのステイクホルダーは迅速なインサイトを要求しますが、BI 作成者は変更を間違いなく繰り返し、自信を持ってデプロイするためのツールを欠いていることがよくあります。 DevOps の原則に着想を得たビジネスインテリジェンスオペレーション（BIOps）は、BI プロセスにバージョン管理と共同開発を導入します。この記事では、 Amazon QuickSight のノーコードのコンソール機能を使用して BIOps を実装する方法を説明します。ダッシュボードのバージョン管理、ビジュアルの再利用、並行でのコラボレーション、そして更新の安全なデプロイを、すべて QuickSight UI を通じて行う方法を紹介します。私たちのフレームワークは、QuickSight に組み込まれたバージョン管理ツールを使用して、チームが管理を合理化し、手作業を削減するのに役立ちます。このコード不要のアプローチは、BI アナリストとダッシュボード作成者の両方がこれらのプラクティスをすぐに採用するのに役立ちます。 QuickSight の基本 このセクションでは、Amazon QuickSight におけるビジネスインテリジェンスオペレーション（BIOps）の基本を紹介します。QuickSight のアセットがどのように分類されるか、基礎となる権限モデル、そして私たちのオペレーションを導く不可欠な BIOps の原則という3つの主要な領域を検証します。 アセットの分類 QuickSight はアセットを4つのカテゴリに整理し、それぞれが BI ワークフローで特定の目的を果たします。 メインアセット – これらは中核となる構成要素であり、QuickSight コンソール上でスタンドアロンのオブジェクトとして表示されます。これらのアセットは相互に依存しています。例えば、分析はデータセットに依存し、データセットはデータソースに依存します。 データソースは、 Amazon Redshift 、 Amazon Athena 、 Amazon Simple Storage Service (Amazon S3) などのシステムに接続します。 データセットはデータソースから構築され、結合、カスタム SQL、計算フィールドを含むことができます。 分析は、ビジュアルを構築するためのインタラクティブな環境です。 ダッシュボードは、分析が公開されたもので、読み取り専用のバージョンです。 Amazon Q のトピックは、自然言語クエリのためのセマンティックレイヤーを定義します。 補助アセット -これらはユーザーエクスペリエンスを向上させますが、QuickSight UI では主要なオブジェクトではありません。例えば、テーマはダッシュボードや分析のスタイルを定義しますが、QuickSight コンソール上ではスタンドアロンのアセットとしてリストされません。しかし、テーマは API を介してプログラム的にスタンドアロンのオブジェクトとして管理でき、 list 、 describe 、 update 、 delete などの操作をサポートします。 セカンドクラスアセット – これらはメインアセット内の内部コンポーネントであり、カスタム SQL、テーブル、フィルター、計算フィールド、パラメータなどが含まれます。これらの要素は QuickSight コンソール UI 上ではスタンドアロンのオブジェクトではなく、直接的なリスト ( list ) や詳細表示 ( describe ) の API コールを通じてもアクセスできません。代わりに、データセット、分析、またはダッシュボードの定義内で定義されます。これらは QuickSight コンテンツのロジック、構造、およびインタラクティビティを定義する上で重要な役割を果たします。 フォルダ – これらはメインアセットを階層構造に整理するために使用される管理アセットです。個人用または共有フォルダを作成してアセットを分類できます。フォルダはアクセス権限をサポートし、1つのアセットは複数のフォルダに存在できます。 権限モデル QuickSight のメインアセット、補助アセット、および管理アセットは、安全なコラボレーションのためにユーザーおよびグループレベルの権限をサポートしています。 BIOps の基本ワークフロー BIOps には３つのコア機能が含まれます。 アセットのバックアップと復元 – これは通常、AWS アカウントごと、または AWS リージョンごとにスコープが設定されます。このプロセスにより、誤った削除、サービスの中断、またはデータの破損が発生した場合に QuickSight アセットを復元できることが保証されます。 バージョン管理 – これは同じ AWS アカウント内で適用でき、BI チームはアセット定義（例えば、データセットやダッシュボード）への変更を追跡したり、以前のバージョンにロールバックしたり、時間の経過とともに異なる開発ブランチを維持したりできます。 デプロイメント – これは環境間（例えば、開発アカウントからテスト、QA、本番アカウントへ）およびリージョン間（例えば、 us-east-1 から us-west-2 へアセットをデプロイ）でのアセットの昇格をサポートします。 BIOps ワークフローを使用すると、チームはアセットレベルとフォルダレベルの両方でデプロイとバックアップを管理できます。ダッシュボードをデプロイする際、チームは機能をサポートするために依存アセット（データセット、データソース、テーマ）を含めることができます。フォルダレベルの操作により、関連するアセットを単一のパッケージとして昇格させることが可能になります。AWS アカウント間でのデプロイには、慎重な権限管理が必要です。アセットタイプにはユーザーまたはグループの権限があり、セキュリティを維持し、依存関係の破損を防ぐために、ターゲット環境で適切に再作成する必要があります。 次の図は、BIOps ワークフローの概要を説明したものです。バージョン管理は、QuickSight コンソール UI を通じても実現できます。 QuickSight ダッシュボードの構築と公開 次のグラフに示すように、QuickSight のダッシュボード開発プロセスは、BI 作成者から始まります。BI 作成者は、アクセス管理を簡素化するためにグループにまとめることができます。 作成者はまず、QuickSight を Amazon Redshift などのストレージシステムに接続してデータソースを作成します。次に、変換、結合、カスタムフィールドを追加してデータセットを構築します。データセットの鮮度は、手動またはスケジュールされた更新によって維持され、モニタリング機能も備わっています。 これらのデータセットを使用して、作成者はビジュアルとインタラクティブなコンポーネントを備えた分析を作成します。一貫した組織のブランディングのためにテーマを適用することができます。最終ステップは、分析をダッシュボードとして公開し、特定のユーザーやグループと共有することです。このプロセスにより、ガバナンスを維持しながら、スケーラブルなセルフサービス BI が可能になります。 ソリューションの概要 この記事では、３つの主要な QuickSight 機能について説明します。 コンソール UI を通じた ダッシュボードのバージョン管理 異なる分析からダッシュボードを公開することによる並行でのチームコラボレーション 他の分析やダッシュボードから ビジュアルをインポート することによるコンテンツの再利用 QuickSight コンソールのこれらの新機能により、ノーコードのインターフェースを通じて効率的な BI コラボレーションとダッシュボードのライフサイクル管理が可能になります。作成者は以下のことができます。 ダッシュボードとデータセットのバージョン履歴を追跡する ダッシュボードを以前のバージョンにロールバックする アセットを手動で複製する 分析とダッシュボード間でビジュアルをインポートおよびエクスポートする アセットの説明を通じて変更を文書化する ブックマークを使用してパーソナライズされたビューを作成する 元に戻す（undo）とやり直し（redo）機能で分析の編集を管理する これらの機能は、コーディングの経験を必要とせずに、合理化されたガバナンスとチームコラボレーションをサポートします。 この記事では、ノーコードでUIベースのワークフローに焦点を当てます。このシリーズの パート 2 と パート 3 では、QuickSight API とプログラム可能なアプローチを使用した自動化されたガバナンスとデプロイについて説明します。 UI ベースのデータセットとダッシュボードのバージョン管理 QuickSight は 2021 年後半にネイティブな データセットのバージョン管理 を導入しました。ユーザーは、QuickSight コンソール UI 内で直接、最大 1,000 の公開済みバージョンを追跡および管理できます。データセットの所有者は、過去の状態をプレビューしたり、以前のバージョンに戻したり、安全に編集したりできます。これには、互換性のない変更（削除されたソースや無効な計算など）に対する保護機能が含まれています。 2025 年 4 月、QuickSight は&nbsp; ダッシュボードのバージョン管理 を導入し、バージョン管理機能をデータセットから完全なダッシュボードへと拡張しました。ダッシュボードの所有者は、UI を通じてバージョンの管理、変更の追跡、以前の状態への復元を、コードを書くことなく行えるようになりました。技術チームは引き続き API ベースの自動化を選択するかもしれませんが、アナリストやビジネスユーザーはこれらの機能を利用して、エンドツーエンドのダッシュボードライフサイクル管理を容易に行うことができます。 次の図は、QuickSight のダッシュボード開発における、バージョン管理された継続的インテグレーションと継続的デリバリー（CI/CD）のワークフローを示しています。 ワークフローは、分析の作成と編集（バージョン 1）から始まり、次にそれをダッシュボードバージョン 1 として公開します。QA テストの後、ダッシュボードが合格すれば、分析はバージョン 2 に更新され、再公開されます。QA テストがどの時点でも失敗した場合、チームは現在のバージョンの編集を続けるか、以前のバージョンにロールバックすることができます。このサイクルは、公開、テスト、更新という反復的な開発を続け、変更が本番環境に到達する前に検証されることを保証します。「元に戻す」「やり直し」アクションは分析内の変更をサポートし、バージョンのロールバックは BI チームの安全性と俊敏性を高めます。 分析における軽微な編集のための「元に戻す」「やり直し」 QuickSight で分析を編集する際、作成者は 「元に戻す」および「やり直し」 オプションを使用して、変更が永続的になることを心配せずに実験できます。分析内で最大 200 のアクションを元に戻したり、やり直したりすることができ、ツールバーのアイコン（次のスクリーンショットを参照）を使用してアクセスできます。 ダッシュボードの公開とバージョン履歴 分析がダッシュボードとして公開されると、QuickSight は自動的に新しいバージョンを作成します。ダッシュボードの所有者は、 バージョン履歴 を表示することでこれらのバージョンを管理できます。そのためには、ダッシュボードを開き、上部ツールバーのバージョン履歴アイコンを選択します（次のスクリーンショットを参照）。 これにより、現在公開されているバージョンと、タイムスタンプや各バージョンを公開したユーザーを含むすべての以前のバージョンのリストが表示されるペインが開きます。そこから、必要に応じて以前に公開されたバージョンを確認、比較、復元できます。この機能は、ダッシュボードの変更履歴を明確に追跡でき、所有者はコンテンツがどのように変化してきたかを把握することができます。 間違いが発見されたり、以前のバージョンが好まれたりした場合、所有者はワンクリックでダッシュボードを以前のバージョンにロールバックできます。 このバージョン管理機能は、公開された各ダッシュボードの完全なスナップショットを保持することで、手動での再作業を削減します。他のバージョンへのアクセスを失うことなく以前のバージョンを復元でき、安定性を維持しながら迅速なイテレーション（反復）を可能にします。 UI ベースの並行作成とコラボレーション 次の図は、単一の QuickSight 開発アカウント内で複数の作成者が並行してコラボレーションする方法を示しています。共有フォルダ「QA Assets」は、再利用可能なコンテンツを一元管理する場所として機能し、作成者はダッシュボードを拡張したり、ビジュアルを再利用したり、バージョンを独立して管理したりできます。 この例では、３人の作成者が共有の開発ワークフローに貢献しています。 Ying は分析 1 を作成し、それをダッシュボード 1 として公開し、チームのための再利用可能なアセットを確立します。 Julia は分析 2 を作成し、ダッシュボード 1 から選択したビジュアルをインポートします。これにより、既存の作業を基に構築しながら、独自のバージョンを維持できます。その後、ダッシュボード 2 を公開します。 Rushabh はダッシュボード 2 の「 名前を付けて保存 」オプションを使用して分析 3 を作成し、さらにカスタマイズしてダッシュボード 3 を公開します。Rushabh は、分析 3 を公開してダッシュボード 1 を置き換えることで、ダッシュボード 1 を更新することもできます。 このアプローチは 2 つの主要な利点をサポートします。 並行開発 – 各作成者は、共有アセットを参照しながら独立して作業します。これにより、上書きや競合の変更のリスクなしに、複数のダッシュボードや機能を同時に開発できます。 副次的な変更を伴わない安全な修正 – 本番のダッシュボードに迅速な修正が必要な場合、作成者は公開されたバージョンから開始し、ターゲットを絞った編集を行い、再公開することができます。これにより、開発中の元の分析にある未完成のビジュアルや実験的な変更を導入することがありません。 これらの機能を組み合わせることで、バージョンの追跡可能性が促進され、リスクが最小化され、大規模なコラボレーションが合理化されます。共有フォルダとモジュール式のワークフローにより、QuickSight はエンタープライズ BI チームにとって強力なプラットフォームとなります。 ダッシュボードを分析として保存 公開後、ダッシュボードはさらなる変更のために分析として 保存 できます。作成者は、次のスクリーンショットに示すように、「 名前を付けて保存 」オプション（フロッピーディスクアイコン）を使用して、利用中のダッシュボードから新しい分析を作成できます。 新しい分析は個人のリストに表示され、自由に編集できます。元のダッシュボードに影響を与えることなく、ビューをカスタマイズしたり、ビジュアルを試したりできます。 他の分析やダッシュボードからビジュアルをインポート QuickSight の ビジュアルのインポート機能 を使用すると、分析間でダッシュボードコンポーネントを効率的に再利用し、標準化できます。分析ツールバーから「ビジュアルのインポート」を選択し、共有または個人のアセットを参照して 1 つ以上のビジュアルをインポートします。クエリ、フォーマット、インタラクションを含むインポートされたビジュアルは、現在の分析にコピーされ、元のソースに影響を与えることなく独立してカスタマイズできます。この機能により、ダッシュボードの開発が合理化され、ビジュアルの一貫性が促進され、チーム間の重複が削減されます。 分析からダッシュボ​​ードを公開 QuickSight で 既存のダッシュボードを置き換える には、公開時に「既存のダッシュボードを置き換える」を選択します。これにより、セキュリティ設定や E メールレポートの設定に影響を与えることなく、ダッシュボードが新しい変更で更新されます。 ダッシュボードを分析として保存する、任意の分析からダッシュボードを公開する、他の分析やダッシュボードからビジュアルをインポートするなどの機能を組み合わせることで、BI チームは開発ワークフローにおいて強力な柔軟性を得ることができます。チームはダッシュボードを並行して開発でき、複数の作成者が異なる機能やビジュアルに独立して取り組むことができます。また、元の分析にある進行中または実験的なビジュアルを誤って本番バージョンに導入することなく、本番ダッシュボードの問題を安全に修正することもできます。このモジュール式で管理されたアプローチは、本番環境での安定性を維持しながら、アジャイルなイテレーション（反復）をサポートします。 ダッシュボードを壊さずにデータセットを置き換える QuickSight のフィールドタイプは、ビジュアル、フィルター、計算がどのように機能するかを決定します。データセットのスキーマ変更が分析の要件と競合すると、ダッシュボードの障害が発生する可能性があります。次のスクリーンショットは、フィルターとビジュアライゼーションのキーフィールドとして SaleDate を使用して構築された、映画チケット販売ダッシュボードの例です。 データセットが更新されました。この更新中に、 SaleDate は Date（日付）フィールドから Integer（整数）に変更されました。 再公開後、ダッシュボードは SaleDate に関連付けられたビジュアルを読み込むことに失敗しました。影響を受けた各ビジュアルには、「データセットが変更されすぎたため、QuickSight が分析を自動的に更新できませんでした」というメッセージが表示されました。 円グラフのレンダリングが停止し、時間比較のビジュアルが失敗し、 SalesDate のフィルターコントロールが機能しなくなりました。 すでにダッシュボードを動かしているデータセットのスキーマを更新する際、データ型の不一致（フィールドを Date から Integer や String に変更するなど）は、ビジュアルが破損する一般的な原因です。 スキーマの変更が意図的な場合は、次のことを行う必要があります。 影響を受けるフィルターを再作成する 新しいデータ型を認識するようにビジュアルを更新する スキーマの変更が意図的でない場合は、次のことができます。 不要な変更が含まれていない以前のデータセットバージョンに戻す QuickSight でデータセットを置き換える際、フィールドマッピングの不一致によるビジュアルの破損も一般的なリスクです。これを軽減するために、QuickSight は現在、次のアクションを実行します。 不一致が検出された場合にフィールドマッピングを更新するようユーザーに自動的に促す スキーマの類似性に基づいてフィールドを自動的にマッピングしようと試みる スキーマが完全に一致しない場合にレビューのための不一致ダイアログを表示する 一致しない、または不整合なフィールドは手動で調整する必要があります。QuickSight は検出された不一致に対してマッピングを強制しますが、ユーザーが提供したマッピングの正確性を検証しません。スキップされたり不適切なマッピングは、依然としてビジュアルの破損を引き起こします。正しいフィールドマッピングにより、ビジュアルが新しいデータセットで期待通りにレンダリングされることが保証されます。 まとめ 新しい QuickSight コンソール機能により、ダッシュボードとデータセットのライフサイクルをコードフリーで管理できます。チームは、バージョン管理、ロールバック機能、並行開発、ビジュアルの再利用を活用して、より安全で効率的なワークフローを作成できます。 自動化、CI/CD 統合、またはプログラムによるガバナンスを必要とするチームのために、このシリーズの パート 2 と パート 3 では、API ベースの BIOps ワークフローについて説明します。 著者について Ying Wang は、AWS のジェネレーティブ AI 組織に所属するシニアスペシャリストソリューションアーキテクトで、Amazon QuickSight と Amazon Q を専門とし、大企業や ISV のお客様をサポートしています。彼女はデータアナリティクスとデータサイエンスで 16 年の経験を持ち、データアーキテクトおよびソフトウェア開発エンジニアリングマネージャーとしての強力なバックグラウンドを持っています。データアーキテクトとして、Ying は顧客がクラウドでエンタープライズデータアーキテクチャソリューションを設計し、スケールするのを支援しました。エンジニアリングマネージャーとしての役割では、新機能を提供し、エンジニアリングと製品の両方の観点から製品イノベーションを推進することで、顧客が QuickSight を通じてデータの力を解き放つことを可能にしました。 Julia Flash は、AWS のジェネレーティブ AI 組織に所属するシニアビジネスディベロップメントスペシャリストで、北米のエンタープライズセグメント向けのQuickSightエンゲージメントをリードしています。AI、コーディング、製品戦略で 12 年の経験を持ち、エンジニア、テクニカルプロダクトマネージャー、特許を持つイノベーターとしての深いバックグラウンドを持っています。Julia は AI ソリューションの設計と開発、オープンソースのデータサイエンスへの貢献、そして影響力の大きい顧客対応のエンゲージメントを提供してきました。今日、彼女は引き続き顧客と協力し、QuickSight の大規模な採用を推進しています。

本ブログは 2025 年 4 月 24 日に公開された AWS Public Sector ブログ「 How AWS Wickr can enable secure communications for the Australian Government and its allies 」を翻訳したものです。 メッセージングアプリケーションは、オーストラリア人のコミュニケーション方法においてますます中核的な存在となっています。 オーストラリア通信メディア庁 (ACMA) の調査によると、オーストラリア人の約 5 人中 4 人が個人的な目的でメッセージングアプリケーションを使用していることが分かりました。これらのアプリは特に若いオーストラリア人の間で普及しており、18～24 歳の 92%、25～34 歳の 89% がつながりや交流のためにこれらのアプリを使用していると報告されています。 また、 Australian Public Service (APS) Workforce Strategy 2025 (オーストラリア公共サービス人材戦略 2025) では、2025 年までに APS の労働力の半分がデジタルネイティブである Y 世代と Z 世代で構成されるようになることが認識されています。このように変わりゆく労働力構成を考慮すると、友人や家族とのチャットに使用するアプリと同じようなツールが職場でのコミュニケーションにおいても求められるようになることは自然な流れのように考えられます。 しかし、一般消費者向けのメッセージングアプリケーションの使用は、オーストラリア政府機関にとって重大なセキュリティと主権のリスクをもたらし、政府の情報管理義務を満たすことを困難にしています。 Official guidance from the National Archives of Australia (NAA: オーストラリア国立公文書館) の公式ガイダンスでは、「オーストラリア政府業務の一環として作成または受信されたインスタントメッセージの投稿は連邦記録である」と明確に述べられています。 Australian National Audit Office (ANAO: オーストラリア会計検査院) は、 国防省 のハンター級フリゲート艦プロジェクトの管理に関する業績監査報告書において、プロジェクトの記録管理の弱点を指摘し、特に国防省職員によるコンシューマーメッセージングアプリケーションの使用について「Signal、Zoom、WhatsApp などのアプリケーションは、公式情報の送信や保存に使用することはできない」と 具体的に言及 しています。 セキュアでコンプライアントなメッセージング Amazon Web Services (AWS) Wickr は、エンドツーエンド暗号化メッセージングおよびコラボレーションサービスであり、政府機関が機密情報を保護し、 Australia’s Archives Act 1983 (オーストラリアの公文書館法) などの法的要件を満たすために必要な高度なセキュリティ、管理制御、およびデータ保持機能を提供します。 Wickr は、1 対 1 およびグループメッセージング、音声・ビデオ通話、ファイル共有、画面共有、位置情報共有を 256 ビット暗号化で保護します。データは、あるエンドポイントから別のエンドポイントへ移動する際に、不正アクセス、傍受、改ざんから保護されます。コンテンツの復号化に必要なキーにアクセスできるのは、意図された受信者のみであり、AWS でさえアクセスできません。Wickr は 2023 年 10 月に AWS シドニーリージョン で開始されました。 きめ細かい管理制御により、ユーザーをセキュリティグループに編成し、そのレベルでの機能やコンテンツへのアクセスを制限できます。Wickr ネットワーク管理者は、望ましい結果を達成するためにカスタマイズされたポリシーを各グループに適用できます。パスワードのリセットやプロファイルのリモート削除が可能で、紛失または盗難されたデバイスに起因するデータ漏洩のリスクを軽減できます。 Wickr ネットワーク管理者は、Wickr ネットワーク内の内部および外部コミュニケーションにデータ保持を設定および適用できます。これには、ゲストユーザー、外部チーム、その他のパートナーネットワークとの会話が含まれるため、組織との間で送受信されるメッセージやファイルを、完全にお客様の管理下にあるプライベートデータストアに保持でき、オーストラリア政府の記録管理義務への準拠をサポートします。 Wickr は、 Information Security Registered Assessors Program (IRAP: 情報セキュリティ登録評価者プログラム) プロセスに基づき、 独立した評価者による監査を受け 、 Information Security Manual PROTECTED (ISM: 情報セキュリティマニュアル準拠) レベルの要件を満たしていることを認定されました。この認定により、各省庁は、Wickr の使用に関して、情報管理および記録保持の要件に加えて、PROTECTED セキュリティ分類までの情報の取り扱いに関する要件を満たすことができます。 Wickr は、ユーザーやチームが他の組織の Wickr ネットワーク内のユーザーとセキュアに通信できるよう、ネットワークフェデレーションを提供します。ユーザーグループを特定のフェデレーションルールに割り当て、選択した機関やパートナーへのアクセスを制限し、個々のセキュリティグループに対してゲストユーザーアクセス機能を許可または無効にできます。 Wickr は現在、アジアパシフィック (シンガポール、シドニー、東京)、カナダ (中部)、ヨーロッパ (フランクフルト、ロンドン)、および米国の米国東部 (バージニア北部) リージョンの AWS リージョンで利用可能であり、2024 年には追加のリージョンが開始される予定です。これにより、確立された同盟国・同志国、新興パートナーとのセキュアなコラボレーションを迅速かつ簡単に設定できます。例えば、次の図に示すように、オーストラリア政府機関は、英国、米国、日本政府の対応機関と Wickr ネットワークフェデレーションを設定できます。 図 1. AWS シドニー、ロンドン、東京、バージニア北部リージョン間の Wickr フェデレーション コミュニケーションを保護する 従業員は今後も、友人や家族とのチャットや職場での生産性向上のためにメッセージングアプリを使い続けるでしょう。これらのアプリの多くは政府機関にリスクをもたらしますが、Wickr はエンドツーエンド暗号化と管理制御、データ保持、データレジデンシー制御を組み合わせることで、お客様の目標達成と、内部およびオーストラリアの主要セキュリティパートナーとの安全なコミュニケーションを支援します。 詳細については、 AWS Wickr のウェブページ をご覧になるか、 メール にてお問い合わせください。 著者について Andrew McBride Andrew は オーストラリアのキャンベラを拠点に、国家安全保障・防衛 (NSD) セクターのお客様を担当する AWS のシニアソリューションアーキテクトです。Andrew は 20 年以上の経験を持ち、実践的なアナリストやソフトウェア開発者から戦略的計画まで幅広く携わってきました。オーストラリア国立大学の National Security College にて国家安全保障政策の修士号を取得しています。 このブログは WWPS Proposal Writer 中村昌幸が翻訳しました。