通信業界のネットワーク運用ではより安定した通信ネットワークを提供するために、障害の検知、要因特定、復旧を早期に対応する必要があります。一方で、近年拡張し複雑化し続けるネットワークに追従することは従来のオペレーションでは難しく、自動化、高度化、自律化が求められています。その実現手段の1つとして、AI エージェントとデータ活用が注目されており、導入への期待が高まる一方で、AI を適用する運用ユースケースの策定、より簡単な AI エージェントの実装方法、商用運用への本格導入、といった課題があります。そこで、本ワークショップでは、通信ネットワークの運用に携わる方向けに、 AI エージェントの仕組みを学び、参考アーキテクチャや事例から最新動向を知り、ハンズオンでより具体的な実装方法を学び、ネットワーク運用 AI エージェントを触って体感していただく場を提供しました。事例紹介の 1 つとして、株式会社 NTTドコモにご登壇いただきました。また、複数社による同じネットワーク運用に携わる者同士の意見交換や AI エージェント活用のためのユースケース議論を行っていただくことで、他社動向や自社の課題を浮き彫りにし、今後のアクションの参考にしていただく場も提供しました。通信ネットワーク運用に特化した業界横断イベントは、今回初めてであり今後も定期的に開催していきたいと思います。 早朝から 96 名/ 14 社のお客様に目黒オフィスまで足を運んでいただき、懇親会まで含めて大盛況なイベントとなりました。ご参加いただきました皆様、本当にありがとうございました！！ アジェンダ タイトル スピーカー 資料 AI エージェント とは – Autonomous Network の実現のために 宮崎 友貴*1 ダウンロード Strands Agents ハンズオン – AI エージェント開発を簡素化しよう 神谷 拳四郎*1 ダウンロード ランチタイム ユースケース議論 宮崎 友貴 通信ネットワーク運用 AI エージェント実践編 – 実際に作って、動かして、触ってみよう 堀場 勝広*2 ダウンロード Amazon Bedrock AgentCore 概要 – AI Agent を本番環境にデプロイおよび運用する方法を学ぼう 川岸 基成*1 ダウンロード クロージング 宮崎 友貴 ダウンロード 懇親会 – – ※1. Solutions Architect, ※2. Principal Solutions Architect AI エージェント とは – Autonomous Network 実現のために 通信業界のオペレーション標準化団体である TM Forum では、 Autonomous Network (自律ネットワーク）の自律レベルを定義しており、 近年、多くの通信事業者が L4 (高度自律ネットワーク) / L5 (完全自律ネットワーク) を目指す動きが出てきています。それを実現するためのコンポーネントの例と AWS で実現する参考アーキテクチャをご紹介しました。このアーキテクチャのキーは、AI エージェント × データであり、Autonomous Network の実現には必須要素であることをお伝えしました。そして、AI エージェントが自律的な行動を行うことができるようになった基礎技術や変遷と共に、オペレーション業務に携わるオペレータと近い動きができることを説明しました。最後に、AI エージェントの活用事例とネットワーク運用における AI エージェントの 参考ユースケース をご紹介することで、最新の業界動向と AI エージェントによる自律運用が実現可能な世界であることをインフルエンスさせていただきました。 宮崎 友貴 Solutions Architect NTTドコモ 「さらば、単純作業！AWSで実現する、”人間が人間らしく働く”ためのネットワーク運用自動化」の事例紹介 AI エージェントを使ったネットワーク運用自動化の事例として、NTTドコモ の舟山空良氏と福嶋章悟氏にご登壇いただきました。両氏は、モバイル端末と MEC 基盤を直結して通信経路を最適化することで、低遅延・高セキュリティ通信を実現するサービス docomo MEC® のオプションであるサービス「MECダイレクト®」 の開発・構築・運用を担当しており、定義済みのフローによる運用の自動化がある程度完了したことで、さなる自動化を目指し、AI の活用に挑戦しました。 株式会社 NTTドコモ 舟山 空良氏（写真左） 福嶋 章悟氏（写真右） 登壇時点では、AI エージェントによる監視措置業務の自律的な実行を実現し、アラート受信、分析、措置手順の提案までの自動化を達成され、そのソリューションとして Amazon Bedrock エージェント を使用していることをご説明いただきました (以下、システム構成図)。Bedrock エージェントの選定の理由としては、マネージドかつサーバーレスなためインフラの構築に時間をかけず迅速な開発を行うことができた点や、社内のセキュリティ承認を得るためのデータプライバシーの観点で Bedrock ではデータをモデルの学習にはしない点が評価されました。 実際の AI エージェントの開発では、参照するデータを泥臭く時間をかけて整備し、プロンプトを工夫することが精度向上には必要であることや、AI に完璧さを求めないこと、がリアルな実装のポイントとして挙げられました。将来的には、LLM 適用による維持管理業務への AI エージェントの適用を行い、AI エージェントの適用領域のさらなる拡張を進め、自律レベルの向上を目指しています。 Strands Agents ハンズオン – AI エージェント開発を簡素化しよう Autonomous Network 実現の核となる AI エージェント、それをわずか数行のコードで構築可能なオープンソース SDK である Strands Agents をご紹介しました。Strands Agents はシンプルな実装だけでなく、本番稼働に対応するためのオブザーバビリティ、モデルプロバイダーやデプロイ環境に依存しない設計思想、データを保護しながら責任を持ってエージェントを実行することを最優先とするなどの特徴があります。本パートでは実際に SDK を使って AI エージェントを構築し、Strands Agents における主要な概念と機能を探索するハンズオンを行いました。 神谷 拳四郎 Solutions Architect Autonomous Network の自律レベル向上を目指していくにあたっては、単一の AI エージェントによるタスク処理だけではなく、マルチエージェントによる協調の必要性が高まってくるでしょう。異なるスキルやモダリティをもつ、複数の専門化された AI エージェントを効果的に組み合わせるデザインパターンとして Agents as Tools、Swarm、Graph、Workflow の4つをご紹介しました。 運用業務における AI エージェントのユースケース議論 本イベントは、複数社の運用担当者にご参加いただいたので、各社混合のグループディスカッションを AWS 社員も交えて実施いただきました。議論テーマは、以下です。各社、自担当の業務をご紹介いただき、どのような業務を AI エージェントに任せられるのか、を議論いただきました。AI エージェントに任せられる業務としては、調査、分析、切り分け、オペレータの支援、ドキュメント作成、オペレーションの記録、ネットワークのエッジ側での操作、などが挙げられ、任せられない業務としては、サービス影響の出る可能性のあるオペレーションの実行、顧客対応や社内調整など対人コミュニケーション関連の業務が挙げられました。各社の AI 活用状況や運用の現場における課題の共有、活発な意見交換が行われました。 通信ネットワーク運用 AI エージェント実践編 – 実際に作って、動かして、触ってみよう 本セッションでは、「実際に触って、動かして、理解して、そして、考えてみよう」というコンセプトに、通信ネットワーク運用における AI エージェント活用の実践的なハンズオンを実施しました。参加者の皆様には、通信ネットワークの保守運用者の立場で、数千台以上の装置で構成されるトランスポート～基地局 NW 網を管理し、毎日数万件以上のアラームが発生する環境で AI エージェントを活用したネットワーク運用を体験いただきました。 堀場 勝広 Solutions Architect ハンズオンの技術アーキテクチャ 本ハンズオンでは、AWS の複数のサービスを統合した実践的な環境を構築しました。データストア層として、 Amazon Neptune をグラフ DB とベクトル DB の両方で活用し、ネットワークトポロジデータとエージェント用の知識ベースを格納しました。また、 Amazon Aurora (RDB) にはネットワークトポロジとアラーム情報を、 Amazon S3 ストレージには保守運用マニュアルや対応手順書を格納しました。 AI処理層では、Amazon Bedrock が提供する大規模言語モデル（LLM）を基盤として、複数の専用 AI エージェントを配置しました。Orchestration エージェント（全体調整）、Observability （分析）エージェント、ナレッジエージェント、チケット管理エージェント、そしてRCA （根本原因分析）エージェントが連携し、包括的なネットワーク運用支援を実現しています。さらに、外部システムとして ServiceNow ITSM と連携し、インシデントチケットの管理も可能にしました。 実践的な対話シナリオ 参加者の皆様には、AI エージェントとの対話を通じて、以下のような実践的なシナリオを体験いただきました。 ナレッジベースへのアクセス：「網内の装置にて IF 品質異常発⽣(流⼊ error )が発⽣した場合どう対処すべきか？」といった質問を通じて、保守運用マニュアルから必要な情報を即座に取得する体験をしていただきました。 アラームの分析：「 2024-0713-0900 前後 30 分間に埼玉エリアで発生したアラームから、発生していたネットワーク障害の内容をまとめて下さい」といった時系列での障害分析や、計画作業との関係性分析を実施しました。 トポロジの分析：アラーム情報とネットワークトポロジ情報を組み合わせることで、障害の根本的な原因を特定する高度な分析を体験いただきました。さらに、マニュアルに沿った対応として、「根本的な原因を解決するために必要な処理は何ですか？保守運用マニュアルに従って回答して下さい」という質問を通じて、AI エージェントが適切な対応手順を提示する様子を確認しました。 最後にチケットの起票：「障害の概要、根本原因の分析結果、対応手順を取りまとめて ServiceNow にチケット起票」と言う依頼を通じて、AI エージェントが一連の対応を外部システム( ServiceNow )に書き込み可能なことをご確認いただきました。 システムの内部構造を探る – 応用編 ハンズオンの後半では、Jupyter Notebook を使用して AI エージェントの動作をカスタマイズし、パラメータ調整による応答内容の最適化を体験いただきました。例えば、マルチエージェント構成のオーケストレーターエージェントのシステムプロンプトを変更することにより、他のエージェントの呼び出し方の変化を体験いただきました。これにより、AI エージェントが単なるブラックボックスではなく、調整可能なシステムであることを実感していただけたと考えています。 ハンズオンを経験した上でのユースケース議論 ワークショップの後半 60 分間では、グループに分かれて AI エージェントの活用方法を議論しました。参加者の皆様には、以下の5つの質問を軸に、自担当でのオペレーション業務の洗い出しから、AI エージェントに任せられる業務と任せられない業務の仕分け、その判断基準の検討、必要なデータと指示（プロンプト）の検討、そして実際の AI エージェントアーキテクチャの設計まで、包括的なディスカッションを行っていただきました。このグループワークを通じて、AI が単なるツールではなく、ネットワーク運用を変革する可能性を持つことを体感いただけたと考えています。特に、どの業務を AI に委譲できるか、どこで人間の判断が必要かという議論は、実際の業務への適用を考える上で非常に重要な示唆を与えるものとなりました。 Amazon Bedrock AgentCore 概要 – AI Agent を本番環境にデプロイおよび運用する方法を学ぼう 続いては、AI エージェントを大規模かつ安全に構築、デプロイ、運用するためのビルディングブロック Amazon Bedrock AgentCore についてのセッションです。これまでのセッションで Strands Agents を利用したエージェントを作りました。このエージェントを本番環境で運用するには、リクエスト増減に合わせてさばけるスケーラブルなコンピューティング環境、認証認可の仕組み、会話履歴などを管理する記憶領域、ツールへの接続と管理、などを考慮する必要があります。これらの課題解決に役立つのが Amazon Bedrock AgentCore であることをお伝えしました。 川岸 基成 Solutions Architect 通信ネットワーク運用というワークロードに当てはめた際の使い方や価値についてもお伝えしました。例えば、機密性の高いNW運用ワークロードでは、Runtime のセッション分離のセキュアな環境が役立つでしょう。AI Agent とのやり取りの中で発見されたインシデントパターン、解決戦略などのナレッジを Memory に蓄積・活用していくことで、より精度を高められる可能性があります。 クロージング 最後に、ワークショップ全体の振り返りながら、AI エージェントを導入するには、AI エージェントに加えてユースケースに応じたオペレーションデータを活用することが必須であることを改めて伝えさせていただきました。また、その実現に向けて AWS がどのように貢献をすることができるか、について、サービスとしてのメリットだけではなく、豊富な事例やネットワーク運用を理解した支援が可能である点をお伝えしました。本ワークショップはその支援の一つであり、ネットワーク運用に携わる方にとってより実用的な内容だったかと思います。 おわりに 本記事では、「通信ネットワーク運用向け AI エージェントワークショップ」についてレポートしました。参加頂いたお客様からは「AI エージェントの現場への導入へのイメージの確度が高めることができた」「やれる気がしてきた」「他社他部署の運用保守に携わる方と交流できた貴重な時間」「Amazon Bedrock AgentCore がサーバレスなので運用がとても楽になる」などのご評価を頂きました。ご参加頂いた皆様、本当にありがとうございました。頂いたフィードバックをもとに改善を重ねて参ります。また、ネットワークの運用 AI エージェントの導入に向けて、本内容が少しでも皆様の業務のお役に立てば幸いです。 著者 宮崎 友貴 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部 通信グループ ソリューションアーキテクト 神谷 拳四郎 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部 通信グループ ソリューションアーキテクト 川岸 基成 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 ストラテジックインダストリー技術本部 通信グループ ソリューションアーキテクト 堀場 勝広 アマゾン ウェブ サービス ジャパン合同会社 Telecom Industry Business Unit プリンシパルソリューションアーキテクト

クエリ最適化、使いこなせてますか？ データ分析業務でSnowflake Notebooksを使っている私が、良さを最大に引き出すテクニックをご紹介します。大容量データを爆速で集計して、コーナーで差をつけましょう！ はじめに NTTデータの齊藤青葉です。クラウドDWHであるSnowflakeのデータを使って分析する毎日を過ごしています。 　もともと、Jupyter Notebookで集計分析を行っていましたが、Snowflake Notebooksを使ってみたところ集計スピードが上がり、クラウドBIツールとの相性も良いこと、自動化もできることから良さに気づき、乗り換えて使っています。

本記事は、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 を通じてお客様のデータの力を引き出すことを可能にしました。