【レポート】Amazon QuickSight Roadshow 東京

こんにちは、岩城です。

8月4日に開催されたAmazon QuickSight Roadshowのレポートです。

諸事情で時間を取れずブログにできていなかったのですが、折角メモっていたのでレポートブログに昇華させました。

セッションレポートは鮮度が命なのは重々承知しています。許してください。

イベント概要

• タイトル
  • Amazon QuickSight Roadshow | 東京
• 開催日時
  • 2023年8月4日 10:00-17:00
• アジェンダ
  • オープニング・ Amazon QuickSight の最新アップデートを総まとめ！
  • NTTドコモのネットワーク事業における社内QuickSightコミュニティの取り組み事例
  • 〜スタートアップ事例から学ぶ〜 ビジネスをのばす QuickSight の賢い使い方
  • QuickSight のコスト、管理していますか？新機能を用いたコスト管理のコツ
  • QuickSight のユーザーコミュニティ活動のご紹介
  • Dive Deep パート1：QuickSight におけるアセット管理
  • Dive Deep パート2：フォルダと API を活用したシングルアカウントでの複数環境運用
  • Dive Deep パート3：データセットパラメータでクエリーを最適化し、CloudWatch で測定
  • Amazon QuickSightを活用した大学IRダッシュボードサービス「IRQuA」サービス立ち上げ事例
  • SaaS で QuickSight を活用するためのポイント 〜設計から運用まで〜
  • 生命保険会社の営業部門における予測分析のビジネス活用と得られた学び
  • QuickSight のポテンシャルを引き上げる SageMaker Canvas 連携で実現するノーコード予測分析
  • キーノート：BI における生成 AI
  • キーノート：今後の QuickSight の拡張予定（英語セッション）

レポート

オープニング・ Amazon QuickSight の最新アップデートを総まとめ！

• BIと生成系AIは相性が良く、ますます面白くなってくるはず
• 本日の流れ
  • 社内ユースケース、社外ユースケース、AIMLのビジネス活用ユースケース、QuiskSight+生成系AIの発展計画
• データ活用は難しい
  • Excelから脱却できない
  • 分析が断片的で活用できない
  • 全社的な動きにならない
  • データ活用は成果が見えづらく経営層にアピールしづらい
  • 世界規模で多くの企業で課題と考えている
• なぜデータ分析をするのか
  • 日々データに基づいて成果の高いビジネス意思決定する
• ビッグデータの活用には創意工夫が必要
  • これからのデータはテーブルで表現すると、特定の指標に対してピンポイントにみていってもよくわからない
  • まずは全体感を捉えたうえで詳細を深ぼることが絶対にひつよう
• なぜ可視化するのか
  • 事業部ごとのインサイトが一瞬でわかり、それぞれに適したアクションにつながる
• データ分析に求められる3つの要素
  • ビッグデータを
  • 高速に
  • 全社員で
• QuickSightの特徴
  • サーバーレスのBIツール
  • 直感的でインタラクティブな分析サービス
  • いつでも、どこでも、閲覧できる
    • PC、モバイル、Emailレポート
  • AI/MLを使って、より効率的に素早くビジネスインサイトを得る
    • QuickSight Q
      • 今も猛スピードで機能開発中
  • 組み込みアナリティクス
    • 社内サイトに共有
    • 自社Webサイトに公開
    • SaaSアプリの一環でマネタイズ
  • 定型レポートの作成と配信もサーバーレスで提供
    • PDF出力可
  • 多様なデータソースに接続
    • オンプレミス
    • AWSクラウド
    • SaaS
  • インメモリSPICEへのキャッシュでサクサク操作
  • 企業での運用に適したユーザー・データの権限管理
    • ユーザごと、行/列レベルセキュリティで必要なデータだけ参照可能
  • 大規模利用に適した料金体系、ユーザ課金
    • Author:分析ユーザー
    • Reader:参照
      • 従量課金で安い
      • データ活用はまず環境があってとりあえず使って欲しい、そうしたケースに適した料金
      • 利用ユーザーでコミットメントする必要がない
  • 2年で150以上の機能追加がされた
    • 去年に関しては100以上の機能追加
    • 今のデータ活用にマッチした機能アップデートを考えるAWSエンジニアが開発している
• 可視化のアップデート
  • Small Multiple
    • ディメンションごとの複製が簡単になった
  • フリーフォーム
    • チャートにテキストを被せて配置することができる
    • 表示の切り替えもできる
  • テキストボックス
    • ビジュアライズにカウントされない
    • 沢山テキスト配置したい場合に使う
  • 散布図の改善
    • まとまってたところを色だけ変えてわかりやすくする
  • 表およびピボットテーブルの表現力
    • ヘッダーの色
    • 画像表示
    • 非表示列を見せない
  • フィールドの配色を統一
    • 売上は常に赤、などどんなアクションをしようが変わらない
• データ準備のアップデート
  • データセットでのパラメータ利用
    • カスタムSQL
      • ダッシュボード側でフィルターで変えて、カスタムSQLに渡してクエリできる
  • SPICE
    • 増分更新
      • 最短15分頻度
  • データセットのバージョニング
    • 地味に知られていないらしい
    • 前のバージョンに戻せる
  • 新しいファイルをアップしてデータセットを更新
    • これも地味に知られていないらしい
      • 同じデータセットにファイルアップロードして更新できる
      • データセットを作り直す必要がない
  • QuickSight Q
    • 英語しかサポートしていない
    • Forecastに対応
    • Whyを入力すると、要因分析に関するインサイトを得られる
  • SageMaker Canvasとの連携
    • ノーコードでMLのモデリングできる
    • パワフルな組み合わせ
    • PythonやJupyter使わずともポチポチできる
• 組み込みのアップデート
  • JavaScript SDK2.0
  • ビジュアル単位の組み込み
    • より外部向けの画面を整えるときに使える
  • ノーコードな1クリック組み込み
    • Wikiに組み込むためのHTMLコード生成
  • 匿名アクセス組み込みでの行レベルセキュリティ
    • タグベースで制御
• 運用管理系のアップデート
  • APIでビジュアル定義
  • APIでアセットのインポート・エクスポート
    • アカウント移行時に使える
  • 管理者向けアセットコンソール
    • ユーザー、グループ単位で誰が何を所有しているかわかる
  • CloudWatchでの監視
    • ダッシュボード、ビジュルアルの描画速度
  • コスト管理
    • 細かい粒度でのコスト管理

NTTドコモのネットワーク事業における社内QuickSightコミュニティの取り組み事例

導入の背景・現在の状況

• ネットワーク事業とは
  • ネットワークの安定運用や通信品質の向上がミッション
  • 全国のネットワークデータ分析・可視化
  • 日々分析で扱うデータは数PB
• ネットワーク事業のデータ分析
  • 基地局で様座なデータを収集→分析に利用
  • 分析者ごとに分析単位や規模は様々
    • 基地局、エリア、都道府県
    • 月単位で前年同月比、分単位で設定変更前後
• QuickSightの導入目的
  • データ分析におけるDX化の促進
    • これまではExcelを使っていた
  • ダッシュボード機能における事例・ノウハウ共有
  • 気軽に複雑な分析を行える環境の提供
• QuickSight導入の決めて
  • 他社のBIツールと比較して安価かつ月額
    • ユーザーに気軽に分析を行って欲しいという要望とあっていた
    • 分析を作成するAuthorユーザーを増やしたかった
  • フルマネージドサービスのためメンテナンスが楽
    • AWSによる手厚いサポート
    • 中々ないらしい
  • 他システムでもAWSを利用しているため連携が用意
    • データソースとなるDBとの連携が簡単だった
      • DBは既にAWS上に構築済みだった
• 利用イメージ
  • 分析したい人がデータ分析できる環境
    • 特定の担当者が分析して、他ユーザが閲覧のみするのではだめ、みんなで分析する
• 利用イメージの背景
  • 定型化できる分析は一括して作成
  • 定型化できない分析も多い
    • データの種類・分析単位が多岐
    • 都度データの用途が変わることも
  • 新しい分析手法の発見に期待
    • データ自体の意味を理解したものが分析した方が意味がある
• 現在の利用状況
  • ユーザー数・閲覧数ともに増加傾向
    • 2022/4から使い始めた
    • Authorユーザー：300超え
    • セッション数：3500
  • ユーザーの属性も増加
  • ダッシュボードの増加に伴って閲覧数増加
  • これまでは所属部署しか使っていなかったが、少しずつ他部署も使うようになってきている

コミュニティ活動

• 立ち上げの経緯
  • Quicksightの利活用を促進したい・社内認知を広めていきたい
  • ユーザー同士で事例を共有しあえる・なんでも相談し会える環境つくりたい
    • 運用に問い合わせるのではなく、同じユーザー同士で質問を解決してくれることを期待
• コミュニティの規模
  • 全国各地のネットワーク系の分析業務でQuickSightを利用しているもの
  • 最近ではエリア品質以外のメンバも増加
• 目指すコミュニティの姿
  • ユーザー対ユーザーの会話が増えて、レベル問わず気軽に誰でも質問でき、誰かが回答してくれる
  • 自ら勉強会開催、コミュニティの自走を期待している
• 主な取り組み
  • Slackでの専用チャンネル
    • QuickSight導入当初から立ち上げた
      • 運用チームにDMや電話が来ていたが、Slackで質問するように促し続けた
      • 徐々に質問・相談をチャンネルで行ってくれるように
        • 履歴から
        • 今では運用チームではなく、誰かが回答してくれるように
        • 1~1.5年位かかった
  • 勉強会・事例共有会
    • 月1回開催
      • レベル別のハンズオンやTIPS開設を実施
    • ユーザーからの事例共有会も定期的に開催
      • 分析事例や新しい使い方の共有
    • QuickSight関連外の会議でもQuickSightを使った分析事例共有をユーザー自ら実施
      • 徐々にユーザー主体での発信も増えてきた
    • 事例
      • ある支店で分析手法を全国向けに会議で共有
        • 他支店からも分析を行いたいとリクエストがあった
      • QuickSightなら分析の共有や複製からすぐに再現可能
      • 全国展開・ノウハウ共有に便利
  • ダッシュボード作成イベント
    • 運用チームの手厚いサポートを受けながらダッシュボードを作成するイベント
    • 完全に初心者でも業務に使えるダッシュボードの作成ができ好評
    • 使うきっかけを作ってあげることが重要
• コミュニティの取り組みの学び
  • Slackのようなコミュニケーションの場を作る
  • 良いものができればユーザー自身から発信したくなる
  • ユーザーの第一歩を踏み出すきっかけを与えることが重要

〜スタートアップ事例から学ぶ〜 ビジネスをのばす QuickSight の賢い使い方

スタートアップにおけるQuickSightの必要性

• Seed
  • MVPを作るフェーズ
    • 最小限のプロダクトでアイデアと実現方法を素早く評価、検証するトライ&エラーの連続
• Early
  • PMFを目指す
    • 素早くデータドリブンなフィードバックサイクルを構築し、ユーザーが自動的に増え続ける状態を目指す
• 初期のプロダクト開発における課題
  • お金もなく、人手も足りない
  • 最低限のコストで手軽にKPIを評価する基盤が求められる
• 中期のプロダクト開発における課題
  • ユーザーをファンにする施策とフィードバックをより効率よく回していかなければならない
• フィードバックサイクルを高速に回すことが大切
  • プロダクトを市場に提供
  • ユーザーからフィードバックを得る
  • 機能を見直す
  • これにQuickSightがハマる
• Quicksightであれば各フェーズに柔軟に対応できる
  • 初期
    • 様々なリソースに手軽に接続可能
    • サーバーレスなので構築にかかる運用工数が削減
  • 中期
    • 新たに構築したDWH基盤にも手軽に接続
    • 他AWSサービスを利用することで他SaaSからデータも組み合わせて分析
  • 後期
    • 行レベル/列レベルセキュリティや、SSOの機能を利用した柔軟なアクセス制御

初期の事例

• 分析基盤がない状態から気軽にBIツールを導入
• プロダクトデータを特定KPIに沿って評価し、その状況を会社全体で確認できようにしたい
• 社内メンバー全員がプロダクトのビジネス推移を確認できるようになった
• ユーザーの利用状況(Aurora)→SPICE QuickSight→S3(画像データをホスティング)
  • SPICEを利用して高速なデータクエリと、既存DBへの影響を抑える
  • カスタムビジュアルコンテンツで画像データを参照

中期の事例

• Salseforceから営業データを取り入れ、より横断的なプロダクト分析をしたい
• 専任データ分析者を採用したので、データ分析基盤も作りたい
• 規模が大きくなるとBIツールの費用が高い
• 既存BIツールと分析基盤の連携がしづらい
• 67%のコスト削減、他事業部に共有するレポートが150%に増加
• サブスクリプションではなくユーザー単位の従量課金で手軽に始められる

後期の事例

• 規模の大きい顧客のため、大規模にも耐えうる認証基盤との連携や、データの細かいアクセス制御が求められる一方でセキュリティまわりの実装工数が割けない
• 他会社と比較して80%コスト削減
• 安全なアクセス制御は行レベルセキュリティを利用してQuickSightに任せる
• シングルサインオンを用いてユーザーの認証基盤とQuickSight上のユーザーを簡単に連携
  • Auth0がキーワードにでてきてた

本日のまとめ

• スタートアップではビジネスを伸ばすために、データドリブンでのプロダクト分析が最重要である
• QuickSightはシンプルな厚生から要件の複雑化にともなうデータ分析版の導入まであらゆるフェーズに対応する
• サーバーレスで従量課金でスモールに素早く使い始められる

QuickSight のコスト、管理していますか？新機能を用いたコスト管理のコツ

これまでのコスト管理と課題

• Cost Explorer
• AWS使用状況レポート
• CUR
  • ここがポイント
• CURでできなかったこと
  • ユーザー、グループ、タグベースのコスト情報
  • 作成者、管理者のコスト
  • 閲覧者コスト
  • 匿名セッションコスト
  • ダッシュボード単位のアラートやレポートコスト把握

新機能の紹介

• できるようになったこと
  • グループ、タグベース以外はできるようになった
• 6/8に発表があったアップデート

ユースケース

• ユーザーレベルのコスト情報の取得
  • 利用の妥当性評価
    • 全員分析を掲げた時、実際に全員が分析しているか
  • 行動分析
    • ユーザー毎の利用状況の差異から新たなインサイトを得る
  • コスト予測
    • 一定のグルーピングにより、グループとしての月間費用予測する
      • 現在、グループ単位とするには別のデータと組み合わせが必要
• 作成者と管理者に掛かる管理コストの把握
  • コスト効率
    • 作成者が高コストの場合、生成したレポートやダッシュボードの価値は
      • コスト比率だけが基準では無い点は注意
  • 予算配分
    • 作成と閲覧が別の予算部門で管理される場合に有効
• 閲覧者コストのユーザー/セッション別の把握
  • セッション別のコスト
    • セッション単位の課金利用頻度を把握
      • ユーザー単位の課金からセッション単位の課金に切り替えるときに利用
    • コスト効率の最適化と効率的な使用の推進
  • 比較からの情報
    • 最適な課金モデルの特定
    • ユーザー行動の変化から得られるインサイト
• 匿名セッションのコストの把握
  • 匿名ユーザーの活動量、割合の分析
  • 埋め込みダッシュボードの効率分析
• ダッシュボード単位のアラートやレポート出力コスト把握
  • ダッシュボードとレポートの利用状況
  • 価値の分析
    • 意思決定に利用されるレポートのコストはどれくらいか
  • ダッシュボード改善
    • 利用状況をインプットにして、ダッシュボードを整理
  • 予算設定
    • ダッシュボードやレポートの利用者に紐づく予算を設定

QuickSightに取り込む

• CURをQuickSightに取り込んで視覚化する
  • 手順がre:Postに書いてある
    • リソースIDを含めるオプションを利用する

Key takeaways

• コストと使用状況レポートでこれまでより細かい粒度で確認可能
  • ユーザー単位
  • 作成者/管理者の別
  • 閲覧者のユーザー/セッション単位
  • 匿名セッション
  • アラートやページネイテッドレポートコストのダッシュボード単位

QuickSight のユーザーコミュニティ活動のご紹介

• JAWS Big-data QuickSight分科会の紹介
  • https://jawsug-bigdata.connpass.com/event/284869/

Dive Deep パート1：QuickSight におけるアセット管理

• 主にAPIの紹介

今までの課題

• ビジュルアルや設定を変更してダッシュボードや分析再利用
• ダッシュボードや分析のバージョン管理やバックアップおよびリストア
• 別アカウントからのダッシュボードや分析のインポート
• 別アカウントへのダッシュボードや分析のエクスポート
• 開発効率が悪く管理コスト高になっていた
• 昨年Assets as Codeにより、JSON/YAMLでエクスポートできるように

Template

• できること
  • 分析とダッシュボードのレイアウトのスナップショットを作成
  • QuickSightアカウント内でのバージョン管理
• できないこと
  • Quicksightの外部に定義エクスポート
  • アセットを移行する前にレイアウトを修正
  • BCPまたはDRの定義
  • プログラムによるダッシュボード/分析の作成
  • QuickSight GUI上でテンプレートそのものを確認すること
• 異なるアカウント間で共有する場合
  • Templateに特定アカウントIDからのアクセスを許可する
    

Assets as Code

• できること
  • QuickSightの外部に定義をエクスポートできる
  • BCPまたはDRの定義
  • プログラムによるダッシュボード/分析の作成
  • 他のツールからの移行するための自動化
• AaCワークフロー

Assets as Bundle

• AaCの拡張版
• 移行をよりシームレスに行うためにフォーカスされたもの
• 分析やダッシュボードだけでなく、使用しているデータセットやデータソースも合わせて定義ファイルをZip化してエクスポートし、そのZipを使用してまとめてインポートできる
• AaBワークフロー
  • デフォルトでは分析はimportもExportもされない、必要に応じてちゃんと指定する

それぞれの比較と用途

まとめ

• 用途や要件に応じてTemplate、AaC、AcBの中から最適なものを選択する
• AaCやAaBを使ってアセット管理する際は、外部リポジトリにおけるバージョン仮のルールを徹底する
• AaCやAaBのハンズオンが用意されている

Dive Deep パート2：フォルダと API を活用したシングルアカウントでの複数環境運用

アセット管理の課題

• ダッシュボード開発における環境分離ニーズ
  • 開発者と利用者が別れており、開発環境で開発、検証ユーザーがテスト後にビジネスユーザーに展開する
  • 複数部門で利用していて環境を混ぜたくない
  • 環境は分離したいけどAWSアカウントを複数持ちたくない

環境分離の選択肢

• アカウント分離
  • 複数のQuickSightアカウントで運用
  • 各アカウントを各環境に見立てる
• 名前空間分離
  • 一つのQuickSightアカウントで運用
  • 名前空間機能を使用し環境分割
• フォルダ分離
  • 一つのQuickSightアカウントで運用
  • フォルダ機能を使用して環境分割

フォルダ分離で使用する権限管理機能

• QuickSightにおける権限管理の要素
• グループ
  • 昔はAPIからしか作成できなかったが今はGUIから作成できる
  • QuickSightのユーザーをグループに所属させる
  • 認証の仕組みとは別
• 共有フォルダ
  • フォルダ単位でアセットの共有/権限管理できる
  • 親フォルダの権限は子フォルダに引き継がれる
  • フォルダ作成や名前変更権限はカスタムパーミッションで制御可能
• リソースパーミッション
  • データソース、データセット、分析、ダッシュボード、テンプレートに対するアクセス制御
• API/CLIによる操作

共有フォルダによる環境管理

• 実践パターン
• リソース共有パターン(GUI)
  • ダッシュボードのURLが変わってしまうので、ブックマークしているユーザーに影響あり
• リソース共有パターン(API)
  • ダッシュボードのURLを維持できる
    • URLを変えたくないならTemplateを挟む
• リソース分離パターン(GUI)
  • URLが変わる
• リソース分離パターン(API)

まとめ

• 環境分離には複数ある
• シングルアカウントで手軽に環境分離する場合はフォルダ分離
• データを共有して良いかを考慮してパターン検討
• CLI/APIを利用することで運用の自動化・効率化が可能

Dive Deepパート3：データセットパラメータでクエリーを最適化し、CloudWatch で測定

パラメータとは

• アクションまたはオブジェクトにより使用される値を転送できる名前付きの変数
• インタラクティブなダッシュボードの作成には必須
• コントロール、フィルタ、アクション、計算フィールドで使える
• ダッシュボード間の連携にも利用可能
• 分析の中で使うもの

データセットパラメータ機能

• ダイレクトクエリーでTB級のデータを扱う場合、動的にスライスされたデータのみを取得しクエリーを作りたい、データソース側のスキャン量制御
• 特に多くのテーブルをJOINしたクエリーにおいて、クエリーを最適化でき、フィルター制御のパフォーマンス向上が期待できる
• データセットの所有者がデータセット内にパラメータを作成、それを分析のフィルターコントロールに利用できる
• カスタムSQLの中でパラメータを利用する
• ユーザ選択によるベーシックフィルター
  • リージョンでフィルターする
  • このレベルのフィルターであれば、カスタムSQL+パラメータは利用しない方が良い
    • テーブル指定のデータセットを作成し、分析上でリージョンフィルターした方が良い
• case when または ifelseで使用
• Selectで新しい列を作成

ユースケース

• ダイレクトクエリーのカスタムクエリーを最適化
• 分析でりようするデータセットを汎用化
• パラメータの繰り返し利用によるデータセットのメンテナンスの簡素化

デモ

• 同じでデモの内容がワークショップで公開されているので試せる
  • https://aws.amazon.com/jp/blogs/news/amazon-quicksight-handson-202006/

制限事項

• SPICEデータセットでは利用できない
• 動的デフォルト値設定は、分析のパラメータでのみ利用可能
• データセットパラメータをマッピングした分析のパラメータで複数値選択のコントロールを使用可能だが、「すべて選択」オプションは利用できない
• データセットパラメータを使用したかスケーティングコントロールはサポート外
• データセットパラメータは分析フィルターでは使用できず、データセット上のフィルターで使用可能（ダイレクトリクエリーのみ）
• Eメールでの定期配信をスケジュールするとき、コントロールの選択値がデータセットパラメータの値（フィルター値）としてレポートには反映されない。パラメータのデフォルト値がレポートでは使用される

Amazon QuickSightを活用した大学IRダッシュボードサービス「IRQuA」サービス立ち上げ事例

• 大学IRとは
  • Institutional Researchの訳後
  • 大学の定員割れが起きて、大学が潰れる危機が迫っている
  • 大学の経営に役立てるための分析活動を指す
• 大学IRで求められるデータ基盤の特徴
  • ビッグデータ規模のデータではない
  • 制度対応などによりデータレイアウトが変更されやすい
  • データ前処理の業務負荷が高い
    • 導入済みのパッケージ製品が後で
  • 大学本部側にノウハウがない
  • ワンオフ型のデータ基盤構築対応だと価格が高騰しやすい構造に
• IRQuAの開発コンセプト
  • 大学IR開始までに必要となるあらゆるコストを下げること
• ビジネス価値
  • 前提知識がなくても大学教職員であれば難なく使いこなせる
  • 大学IRデータ基盤が安価に構築・運用できる
  • ここを抑えておけば大学IRのベースはできていることをお客様が理解する
• QuickSightの選定理由
  • シンプルな捜査官でダッシュボードを作成しやすい
  • UIがモダンで操作感が良い
  • サンキーダイアグラムを簡単に実装できる
    • 大学から高評価
    • 競争力がある機能
  • 柔軟かつ低廉なライセンス体型
  • AWSの他サービスとの親和性の高さ
• IRQuAの全体アーキテクチャ
  • 1.5ヶ月で構築完了
• QuickSight設計における留意点
  • ダッシュボード担当が管理しやすいようにリリース単位ごとにテンプレートを管理
  • 各大学のユーザーがアップロードしたデータとIRQuA上のグラフとの対応関係をわかりやすくするため、QuickSight上での複雑な計算は極力行わない
  • ユーザーのITリテラシーが多様なため、Quicksight上で実装する機能はフィルターとドリルダウン程度に留める
  • ユーザーによってわかりやすいデータレイアウト設計を心がける
• 構築時に直面した課題
  • AWSの他のサービスと比較して全体的にAWS以外の各社エンジニアが公開している情報ソースが少ない
    • SaaSへの組み込みを行う際のQuickSightの構築事例、設計ナレッジなど
    • 権限周りの実装に関しては特に手探りだった
  • 計算フィールドのエラー発生時、原因特定をしにくい
• 今後のビジョン
  • ユーザーからの要望の集約と持続的な追加開発による機能拡張
  • ユーザーコミュニティの充実化
  • IRQuAをベースにした大学間コンソーシアムの設立
  • ML、AIを活用した機能の導入（SageMaker、Bedrock）

SaaS で QuickSight を活用するためのポイント 〜設計から運用まで〜

SaaS x QuickSight

• SaaSでは顧客の満足度を高めることが大切
  • 実験→傾聴→アイデア→実験
• BIツールの組み込みはSaaSの価値を高める方法の１つ
  • ユーザーがデータを活用できる
    • ユーザーの定着につながる

ユースケース別アクセス管理方法

• 前提:SaaSにおけるテナント分離
  • SaaSにおいてテナント間のアクセス制御は不可欠
  • ユーザーごとに適切なデータのみアクセス/可視化が行える必要がある
• ユースケース別の２つのアクセス管理方法
  • 準備したダッシュボードを閲覧オンリーの状態で配布したい
    • 方法：閲覧者ごとの権限制御
  • データ準備と分析機能を提供することでサービス価値を高めたい
    • 方法：ネームスペースによる環境分離
• 閲覧者ごとに権限制御する２つの方法
  • Quicksight上でReaderユーザーを作成してアクセス制御
  • 匿名アクセス x 行レベルセキュリティによるアクセス制御
• 匿名アクセス x 行レベルセキュリティによるアクセス制御
  • QuickSight上でのユーザー管理不要、簡単に始められる
    • 各テナント特有のタグを使用してパーソナライズされたデータにアクセス
  • 行レベルセキュリティとは
    • データセットにルールを設定し行レベルのアクセス制御を行う機能
      • ユーザーベース or タグベースのルールを設定可能
  • アクセス制御の仕組み
  • 埋め込みURLを取得するためにCLIを実行する
    • SessionTagを付与したJSONを与える
  • 埋め込み時のフロー
  • 料金形態
    • ユーザー単位の課金ではなく、まとまったセッション数単位での課金
• ネームスペースによる環境分離
  • SaaS事業者のアカウントの中で環境分離することで、Author権限を渡すことができる
    • よりセキュアに管理できる
  • 必要に応じてAuthorが利用可能な機能を制限できる
    • 例：データセットの利用はできるが、作成はできない
  • 埋め込み時のフロー
  • 参考
    • Embeded Analytics Developer Portal
      • 埋め込みの機能性や実装方法を学べる

AaCを活用した運用

• 分析、テンプレート、ダッシュボードをJSON/YAMLによって定義、出力し作成できる
• メリット
  • 外部リポジトリを使用したQuickSightのアセット管理
    • バルク生成
    • バージョン管理
    • コードレビュー
    • バックアップ、デプロイ、ロールバック
• 活用例
  • 開発環境で作成したダッシュボードをgitで管理、本番環境に自動で反映する
    • CodeCommit→Codebuild→QuickSight

まとめ

• BIツールの組み込みはSaaSの価値を高める方法の１つ
• SaaSでQuickSightを活用するユースケース別方法
  • 閲覧のみ→匿名アクセス x 行レベルセキュリティ
  • データの準備と編集→ネームスペースによる環境分離
• AaCを活用した運用
  • gitを利用したバージョン管理、DevOpsが可能に

生命保険会社の営業部門における予測分析のビジネス活用と得られた学び

• アクサのデータ利活用状況
  • 全社でデータ活用の環境が整いつつ有り、QuickSightの活用も活発
    • 2023年: アクティブユーザー数3833
• パフォーマンスレポーティンググループでの取り組み
  • 全社でデータドリブン文化の構築と定着化のため、BIツールなどを活用した様々なレポートの開発配信を行っている
  • ネクストステップとして、予測分析を始めた
• 課題
  • Simulation Forecastの作成
    • 業績の予測
    • Excelで手作業で作成しており、時間と工数が発生している
    • 経験と実績に基づいた判断を取り入れての作成（属人的）
    • 月末最終予測値のみしか確認出来ない
  • レポート利用者数の拡大
    • ログイン方法がやや面倒
    • レポートがたくさんあり、見たいものが探しにくい
    • レポートへのリンクが複数箇所ある
• 具体的な解決策
  • MLを使った、新しいSimulation Forecastの作成
    • MLを使い予測値を作成する→結果を効率的に出力する仕組みを作る→QuickSightでダッシュボード化する
  • QuickSightでもつ予測分析機能を使わず、Amazon Forecastを使った
    • より柔軟な表現ができる
    • 欲しい予測値に対して、どのようなデータを投入すればよいか分からなかった
• 諦めずに頑張った
  • 投入する過去データの選択
  • 予測値出力の自動効率化
  • 全社員使用ツールへレポート埋め込み
• うまく言ったこと
  • 高精度な予測値の出力
  • 新しいSimulation Forecast新しい自動日次更新
  • ストレスフリーなアクセスと閲覧
• 高精度な予測値の出力
  • 隔月で初旬、中旬、下旬にポイントを置いた
• 新しいSimulation Forecast新しい自動日次更新
  • 手作業零で日々の値更新が可能となった
    • Predictor再学習の必要なく、先の予測値更新
      • Amazon Forecastのrolling forecastの機能を利用した
• ストレスフリーなアクセスと閲覧
  • 全社員のイントラへフレームインし、ユーザーによってレポートへのストレスフリーなアクセスと閲覧を実現
    • Teamsへフレームイン
• Sales Dashboard Simulation by AI
  • 月次、日次のデータを可視化でき、タイムリーに予測値を確認できるようになった
• 効果
  • 担当者作業工数
    • 17-18h/月 → 0h
  • 予測値
    • 精度&客観性UP
  • アクティブユーザー数
    • 約2500 → 3800(社員に二人に一人）
• 今後の展望
  • より高精度なSimulation Forecast
  • 新コンテンツの企画・開発
• より高精度なSimulation Forecast
  • 予測値に影響を与える他要素の検討
  • 長期予測モデルの作成
    • 現在は月単位、今後は四半期や年単位で表示したい
  • より複雑かつ新たな予測モデルの作成
    • SageMaker Canvasを使って日々トライしている
• 新コンテンツの企画・開発
  • ダッシュボードを埋め込んだページに利用者アンケート貼り付け
  • ユーザーアクセス数管理シート作成
• まとめ
  • 欲しい物を欲しい人がすぐに作れる
  • 適切なデータ選択やアウトプットのイメージしやすさ
  • 活発なアジャイル開発
  • コスト削減（費用・時間）
  • ビジネス部門で思考してみる良さが沢山ある
    • ITエンジニアではなく、データサイエンティストでもないものが試せる

QuickSight のポテンシャルを引き上げる SageMaker Canvas 連携で実現するノーコード予測分析

ノーコード予測がもたらす価値

• データの収集、学習、予測、これらを機械学習が半自動化することで顧客体験の改善を提供する
• 予測がビジネス競争力をもたらす多様なユースケース
  • 予知保全
  • 需要予測
  • 不正検知
  • 信用リスク判断
  • テキスト抽出、テキスト分析
  • コンピュータビジョン
  • 自動運転
  • パーソナライズレコメンド
  • 離反予測
• データサイエンスのリソースは限られている
  • ボトルネック
    • より優れたMLアプリケーションの構築がボトルネック
    • データサイエンス人材は規模拡大にコストがかかる
• このボトルネックを解決するためSageMaker Canvasが登場した
  • AI/MLの知識が不足していも精度の高い機械学習可能
• 予測から分析まで一気通貫する力をビジネスアナリストに
  • SageMaker Canvas→QuickSightへ予測レポートをパブリッシュ

デモ1

デモ2

• すでにデータセットをQuickSight上に用意されている、そのような場合SageMaker Canvasにデータセットをまた用意するのは辛い。SageMaker CanvasのモデルをQuickSightに送って予測する（先週あったアップデート）

まとめ

• ビジネスで予測することの価値を説明
  • 未来を予測することでビジネス価値が創出される
• ノーコード予測分析ソリューションとしてSageMaker Canvasを説明
  • 予測分析のブロッカーとなる人為的リソースからの解放

キーノート：BI における生成 AI

• 生成系AIで変わったこと、変わっていないこと
  • 変わっていないことが重要だったりする
  • 誰が作ったモデルを作成するのではなく、自分でも作成していく。だからデータを集めていくのがまだまだ重要

生成系AIとは

• 一般に基盤モデルと呼ばれる
  • 膨大なデータに基づいて事前にトレーニングされた大規模モデルを利用
• 生成系AIを支える基盤モデル
  • より固有のタスクや会社特有の情報について知識を持たせたい場合、ファインチューニングしていく
    • データサイエンティストの活躍の場
• Why AWS?
  • AWSのスタンス、あくまでも企業向けに色々なモデルを色々なユースケースで選択できるようにし、安く提供したい
  • OSSが勢力を伸ばしていて、選べるものが世の中に沢山あり、最終的にモデルが良いと評価されるかはユースケース次第
    • クラウド上でGPU/CPU/コストの組み合わせで色々なモデルを選択し、様々なユースケースで試して欲しい
• Bedrock出始める最先端の基盤モデル
  • お試しをやりやすくする、お客様の環境内にモデルがある、モデルを外から使うのではなくお客様の環境にある状態で試して欲しい
• Amazon Titan
  • Amazon.comで使っている検索エンジンで使っているモデル
• ユースケース
• SageMaker JumpStartで始める基盤モデル
  • Market Praceでサブスクライブできる
  • 利用するだけでなくファインチューニングも可能
• Bedrock
  • お客様の業務課題を解決する基盤モデルによる生成系AIアプリをサーバレスで素早く開発可能に
    • セキュリティ
      • お客様環境にだけ存在すること
  • ファインチューニング
    • 安全なカスタマイズで差別化を加速
    • 業務目的：特定タスク向けに回答精度を最大化
    • 必要なデータ：少数ラベル付けされたサンプル例
• CodeWhisperer
  • コードを自動生成

さいごに

本エントリがどなかたのお役にたてれば幸いです。