
Amazon Quickと壁打ちして進めるデータ活用を始めるための最初の一歩
こんにちは、こーへいです。
いきなりですがデータ活用とは、「データを使ってビジネスを前に進める意思決定をすること」です。
売上や稼働率、顧客の反応など、手元にある数字をただ眺めるのではなく、その数字をもとに「次に何をするか」を決めることが大切です。

「社内データをAIと対話して動かす Amazon Quickで始めるデータ活用・業務自動化入門」というタイトルで登壇しました | DevelopersIO
とはいえ、「実際に手持ちのデータをどう活用すればいいのか分からない」という声はよく聞きます。
組織全体でBIツールを導入し、ダッシュボードを整備し、みんなが数字を見て動く……という状態を最終ゴールとしたとき、そこに至る道のりは決して短くありません。
そこで今回は組織展開の前段階、つまり「個人としてまず何ができるか」という一歩目を「Amazon Quick」を使って踏み出す方法を紹介します。
身近な例えで全体像をつかむ
データ活用の話をまずは身近な例えで紹介します。データ活用には大きく2つのパターンがあります。
①モニタリング: 体重計

毎朝体重計に乗ると、数値がぱっと見でわかります。数値の推移をグラフにしていれば「先週から少し増えたな」といった変化にも気づけますし、それを受けて「今日は少し食事を控えよう」というアクションにつながります。
ビジネスの世界では、これがダッシュボードでのKPI定点観測にあたります。売上・稼働率・エラー率といった重要な数値を毎日・毎週決まった形で見えるようにしておくことで、変化にいち早く気づけるようになります。
②課題分析: 健康診断

体重の増加に気づいたとき、「なぜ増えたのか」を知りたければ健康診断を受けて多角的に検査します。血液検査、生活習慣の振り返り……いろいろな角度からデータを見ることで、初めて原因が特定できます。
ビジネスでは、これが原因分析にあたります。「なぜ稼働率が下がったのか」「なぜ解約が増えたのか」といった問いに対して、データを様々な切り口で分解し、原因の仮説を立てて検証していくプロセスです。
この「①ぱっと見でわかる定点観測」と「②異変に気づいたら深掘りする原因分析」の2つが、データ活用の基本的な型になります。
個人でデータ活用を始めるための準備6ステップ
ここからは実際に個人としてデータ活用を始めるための準備を6つのステップに分けて紹介します。先ほどの体重計・健康診断の例えを引き続き使いながら説明します。
ステップ1: 組織のミッションと追うべき数値を整理する
まず最初にやるべきは、自分の組織(チーム・部署・ライン)が果たすべきミッションと、それを測るための数値を言語化することです。
ダイエットで言えば「なぜ痩せたいのか」にあたります。健康診断で再検査になったからなのか、単純に見た目を変えたいからなのか。ここが曖昧なまま体重計に乗り続けても、数字の変化に一喜一憂するだけで終わってしまいます。
ビジネスでも同じで、ここを飛ばしていきなり「データがあるから分析してみよう」と手を動かすと、データ活用は簡単に迷走します。ミッションに紐づかない「あればいいな分析」は、結局誰も見なくなります。
ステップ2: あるべき状態を定義する
次に、追うべき数値について「どうなっていれば成功と言えるか」というあるべき状態を定義します。ステップ1と重なる部分もありますが、目指す状態が具体的な数値やラインとして定まって初めて、データ活用に「意味」が生まれます。
「痩せたい」だけでは何も決められませんが、「3か月で体重を3kg減らし、65kgで維持する」まで決めれば、初めて体重計の数字に意味が生まれます。
ビジネスでも同様に、「稼働率を見ている」だけでは何も決められません。「稼働率98%以上を安定的に維持している状態」まで定義して、初めて現状との比較ができるようになります。
ステップ3: 現状の状態を整理する
あるべき状態が決まったら、今持っているデータを使って現状を整理します。必要であればグラフや表にして可視化します。
ダイエットなら、まず直近の体重の推移を記録・グラフ化してみるステップです。これをやって初めて、ステップ2で定義した「あるべき状態」とのギャップ、つまり「あと何kg減らす必要があるのか」が目に見える形になります。逆に言えば、現状整理をサボると「太った気がする」「痩せた気がする」という感覚論のままで話が進んでしまい、対策の優先順位もつけられません。
ステップ4: 定点観測する情報と都度分析する情報を切り分ける
ステップ2とステップ3のギャップを埋めるために、どの情報をどのくらいの頻度で見るべきかを整理します。毎週・毎月チェックしたい「定点観測」の情報と、四半期に一度など必要なタイミングだけ見ればよい「都度分析」の情報に切り分けます。
体重計は毎日乗って定点観測する一方、血液検査を伴う健康診断まで毎日受ける人はいません。年に1〜2回、必要なタイミングで受ければ十分な「都度分析」です。
ビジネスでもここをやらずに何でもかんでもダッシュボードに載せてしまうと、「一度作ったきり誰も見ない指標」がどんどん積み重なり、ダッシュボード全体が汚れていきます。定点観測すべきものを絞り込むことは、個人的に非常に重要な作業です。
ステップ5: 足りないデータを整理する
ここまで進めると、「このデータさえあれば、もっと踏み込んだ分析ができるのに」という不足が見えてきます。
体重は減っているのに、それが筋肉なのか脂肪なのかは体重計の数字だけではわかりません。体組成計や血液検査のデータがあって初めて、もう一歩踏み込んだ判断ができます。
不足しているデータの中には、業務フローの変更が必要など、すぐには揃わないものも多くあります。ただ、それでも「今は足りない」という事実を記録に残しておくことが大切です。そうすることで、将来「そのデータを取得することで得られるメリット」と「取得にかかる工数」を天秤にかけて、導入の判断ができるようになります。
ステップ6: 一枚の資料にまとめる
最後に、ステップ1〜5で整理してきた内容を一枚の資料にまとめます。これは自分の理解を整理する意味でも、他人に展開する意味でも役立ちます。
ダイエットで言えば、「目標」「現在地」「今後の測定計画」「足りないデータ」を1枚のメモにまとめておくようなものです。
ここで大事なのは、机上で考えるだけで終わらせないことです。実際に手を動かしてAIで出力したグラフを見て考え、その過程で得た気づきも含めて、最終的に一枚の資料に考えをダンプする。
この「作りながら考える」プロセスこそが、手持ちのデータ活用の解像度を一気に上げてくれます。
具体例: Amazon Quickで6ステップを回してみる
ここからは、SaaSプロダクトを提供する企業のカスタマーサクセス担当者を例に、契約継続に関するデータ(ログイン頻度、問い合わせ件数、月次解約率)を持っているという想定で、6ステップをどう回すかを見ていきます。
ステップ1・2: ミッションとあるべき状態
まず整理したのは以下の内容です。
| 項目 | 内容 |
|---|---|
| ミッション | 解約を減らし、既存顧客の契約継続率を安定させる |
| あるべき状態 | 月次解約率2%以下を維持し、解約の予兆が出た顧客には契約更新前にフォローできている状態 |
ステップ3: 現状整理
手元にあった過去6か月分(2025年1月〜6月)の月次解約率を整理すると、以下のようになっていました。
| 月 | 月次解約率 |
|---|---|
| 2025年1月 | 1.6% |
| 2025年2月 | 1.5% |
| 2025年3月 | 1.8% |
| 2025年4月 | 2.9% |
| 2025年5月 | 3.4% |
| 2025年6月 | 4.1% |
このデータをAmazon Quickに読み込ませて折れ線グラフにしてもらうと、3月まではあるべき状態(2%以下)を概ね満たせていたのに対し、4月以降右肩上がりで悪化が進んでいることがひと目でわかります。数字を表で眺めているだけでは気づきにくい傾向も、グラフにするだけでこれだけはっきり見えてきます。
ステップ4: 定点観測と都度分析の切り分け
続いて、どの指標を定点観測にして、どの指標を都度分析にするかをQuickと壁打ちしました。プロンプトのイメージは以下の通りです。
月次解約率(日次)、アクティブユーザーのログイン頻度(日次)、
四半期ごとの解約理由の傾向(四半期に一度)
という3つの指標がある。
このうち毎日見るべきダッシュボードにすべき指標と、
四半期など都度分析でよい指標に整理して。
これに対してQuickからは、「月次解約率」と「アクティブユーザーのログイン頻度」は解約の予兆を早期に捉えるために毎日見るべき定点観測指標、「四半期ごとの解約理由の傾向」は解約要因の変化を把握するための都度分析指標として整理するとよい、という回答が返ってきました。整理した結果は以下の通りです。
| 指標 | 分類 | 理由 |
|---|---|---|
| 月次解約率(日次更新) | 定点観測 | 悪化の兆候をいち早く捉えるため |
| ログイン頻度(日次) | 定点観測 | 利用離れの予兆を解約前に検知するため |
| 解約理由の傾向(四半期に一度) | 都度分析 | 解約要因の変化を把握できれば十分なため |
ステップ5: 不足データの洗い出し
解約率の悪化とログイン頻度の低下を突き合わせると、両者にある程度の相関が見えてきました。しかし、解約前にどんな問い合わせをしていたかというサポート対応履歴が手元になかったため、「機能への不満なのか、価格への不満なのか」という根本原因までは断定できませんでした。
このことをQuickとの壁打ちの中で言語化したところ、「サポート対応履歴があれば、解約理由との相関をより正確に検証できる」という気づきが得られました。これは、すぐには揃わないデータではあるものの、今後サポート部門と連携してデータを残していく運用に変えるかどうかを検討する材料になります。
ステップ6: 一枚の資料にまとめる
ここまでの内容をQuickとの対話の中で整理し、最終的に一枚の資料としてまとめたイメージが以下の表です。
| 項目 | 内容 |
|---|---|
| 現状(解約率推移) | 2025年1月〜3月は2%未満で推移していたが、4月以降右肩上がりで6月には4.1%まで悪化 |
| あるべき姿とのギャップ | ミッションで掲げる解約率2%以下に対し、直近3か月は未達が継続 |
| 原因仮説 | ログイン頻度の低下との相関が見られるが、機能面か価格面かは未特定 |
| 定点観測する指標 | 月次解約率、ログイン頻度(いずれも日次) |
| 不足データと今後の対応 | 解約前のサポート対応履歴がなく原因を断定できないため、記録運用の導入を検討 |
このように、Amazon Quickとの壁打ちを重ねながらグラフを作り、整理し、また問い直すというサイクルを繰り返すことで、一人でも短時間で「現状把握」から「不足データの洗い出し」まで一気に進めることができます。

手持ちのデータの量にもよりますが、この流れさえ抑えておけば資料作成までに1時間かかりません。AI時代には本当に感謝です。
まとめ
今回紹介した内容は、あくまで組織展開前の「個人としての最初の一歩」です。
ですがここで作った一枚の資料が、次に「組織全体でどう展開するか」を議論するための土台になると思うので、まずは小さく始めてみましょう。







