■ 1. SDAを検討した背景
- 生成AIによる分析の限界:
- SQLやPythonコード、グラフのたたき台は短時間で作れる
- 分析目的、指標、対象データの前提が曖昧なままでは、正しく見える結果でも意思決定に使えるとは限らない
- 前提と判断の経緯を残す重要性:
- 生成AIで分析を試す中で、コード作成だけでなく分析の前提や判断の経緯を残すことが重要だと考えるようになった
- 会話だけで分析を進める問題:
- 分析目的や条件が会話履歴に埋もれる
- どの判断が確認済みなのか分からなくなる
- 同じ条件で分析を再現しにくくなる
- 途中で条件を変えた場合に、見直すべき成果物が分かりにくくなる
- 仕様駆動開発の応用:
- 実装前に目的や条件を仕様として整理するソフトウェア開発の考え方を、データ分析へ応用した
- 仕様として残すことで、目的や条件を共通の入力として扱い、各段階の確認内容を追跡しやすくする
- SDAの位置づけ:
- 生成AIを使ったデータ分析で試行している進め方を整理したもの
- 新しい標準手法の提唱ではなく、検討内容と得た知見の紹介
■ 2. 仕様駆動データ分析（SDA）の考え方
- SDAの定義:
- 分析目的、データ要件、指標定義、分析方法、検証条件を仕様として明示する
- その仕様を基準に、人間とAIが段階的に分析を進めるアプローチ
- SDAの特徴:
- 各フェーズの成果物を次のフェーズへ引き継ぐ
- 人間の確認を経ながら仕様と成果物を更新する
- 分析を複数のフェーズに分割:
- 課題理解、データ確認、分析設計、実装、検証、レポート作成などに分ける
- その時点でAIが行う作業と、人間が確認する内容を絞れる
- 前工程の成果物を次工程の入力に:
- 各フェーズの内容をMarkdownなどのファイルとして保存する
- 仕様を分析設計の入力とし、分析設計の成果物をコード生成の入力とする
- 分析の前提が会話履歴だけに依存することを避けられる
- 方針変更時も、変更した仕様と影響を受ける成果物を確認しやすい
- 重要な時点での人間による確認:
- SDAはAIだけで分析を完結させることを目的としない
- 分析目的が業務上の課題と合っているかを確認する
- 利用するデータや分析方法が目的に合っているかを確認する
- 指標の定義や結果の解釈が適切かを確認する
- 分析結果から提案するアクションが妥当かを確認する
- AIが仕様やコードのたたき台を作り、人間が重要な判断に集中できる状態を目指す
- SDAの全体フロー:
- 分析依頼から始め、ビジネス課題、データ条件、分析方針を順に整理する
- 仕様に基づいて分析し、結果を検証してレポートにまとめる
- 各フェーズを人間が確認し、必要に応じて前のフェーズへ戻って改善する
- 重要なのは一方向の自動化ではなく、判断の経緯を仕様として残しながら反復できること
■ 3. 架空のB2B営業データでの実践
- 最初の依頼:
- 法人顧客の営業データを分析し、既存顧客へのクロスセル施策につながる分析案を提示するという一文のみ
- 具体的な分析方法や評価指標は指定しない
- SDAではすぐに分析せず、まず依頼の目的や前提を整理する
- 曖昧な依頼の仕様化:
- AIとの対話を通じて分析の目的と条件を整理した
- 目的を、受注実績のある法人顧客について未保有の商品カテゴリから次に確認すべき候補を見つけることとした
- 営業担当者が確認するための候補一覧として整理した
- 過去に提案しなかった商品や失注した商品はデータから分からないため、自動的な商品提案とはしない
- 整理した内容は問題仕様として保存し、後続の分析を確認する基準とした
- 誰が結果を使うか、何を候補として示すか、結果をどこまで利用するかが明確になった
- 利用データ:
- 顧客、商談、商品、商談商品明細、営業活動を含む架空データ
- 顧客には複数の商談があり、各商談の商品明細は商品および商品カテゴリと結び付く
- 受注済みの商談商品明細から、顧客ごとの保有商品カテゴリを整理した
- 分析計画の作成:
- 分析対象、商品カテゴリの単位、結果の扱い方をもとに、処理と可視化の内容を分析計画として整理した
- 計画を基準にすることで、途中で条件が変わることや当初の目的と異なる分析へ進むことを防ぐ
- 実行した主な処理:
- 受注実績のある商談と顧客を抽出する
- 商品を商品カテゴリ単位にまとめる
- 一緒に受注・保有されている組み合わせを集計する
- 顧客ごとに保有済みと未保有の商品カテゴリを整理する
- 未保有の商品カテゴリに、候補とした根拠を付ける
- 実行時の確認:
- AIが作成したコードは、分析計画どおりの処理かを人間が確認してから実行する
- 実行後も対象件数や集計値を確認する
- 仕様との不一致があれば、コードだけでなく仕様や分析計画まで戻って見直す
- AIが任意の条件で処理を作るのではなく、前工程の仕様を参照して分析することが重要
■ 4. 分析結果と解釈
- 候補一覧の生成:
- 受注実績を持つ30社について、未保有の商品カテゴリの候補一覧を生成した
- 現在も有効な顧客を対象に、商品カテゴリ別の未保有顧客数を集計した
- この件数は商品の優劣ではなく、まだ保有していない商品カテゴリを数えた結果
- 共保有:
- 同じ顧客が2つの商品カテゴリをどちらも保有している状態
- セキュリティを保有する13社のうち11社がネットワークも保有していた
- Lift（リフト値）:
- 2つの商品カテゴリの保有が独立している場合を1とする指標
- セキュリティとネットワークのLiftは1.34で、セキュリティ保有顧客ではネットワークが共保有されやすい
- 候補の優先付け:
- コラボレーションとデータ分析のLiftは1.43で最も高いが、共保有は2社にとどまる
- Liftだけで判断せず、共保有件数が3社以上かつLiftが1以上の組み合わせを優先した
- 共保有件数が11社と最も多いセキュリティとネットワークを、最初に確認する候補とした
- ヒートマップの読み方:
- 組み合わせによって値に差があり、一緒に保有されやすい組み合わせとそうでない組み合わせがある
- 結果の限界:
- セキュリティ保有顧客へネットワークを提案すれば受注するとは言えない
- 確認したのは受注済み顧客の過去の保有傾向にすぎない
- 営業担当者は顧客のニーズ、契約状況、提案のタイミングを別途確認する必要がある
■ 5. 人間によるレビュー
- レビューの観点:
- 分析対象が目的に合っているか
- 少ない事例だけを根拠にしていないか
- 商品の組み合わせを因果関係として説明していないか
- 分析結果をそのまま営業対象として扱っていないか
- 営業担当者が顧客の状況を確認してから利用できるか
- 仮説としての扱い:
- 両カテゴリを保有する顧客は11社にとどまり、提案の有無、失注理由、顧客のニーズは分からない
- Liftの値だけでは受注可能性や提案効果を判断できない
- セキュリティからネットワークへの組み合わせは、自動的な提案ルールではなく少数顧客から確認を始める仮説とした
- 施策化に必要な検証:
- 候補を提示した日、提案した商品カテゴリ、提案結果、失注理由などを記録する
- 記録をもとに結果をあらためて検証する
- 利用範囲の明確化:
- AIが仕様や分析のたたき台を作り、人間が重要な判断を確認することで、分析結果をどこまで利用できるかが明確になる
■ 6. 実践して分かったこと
- 判断の経緯の確認:
- 最終的な数値だけでなく、なぜその条件で分析したのかという経緯を確認しやすくなった
- 依頼の具体化:
- 仕様の整理を通じて、結果の利用者を営業担当者とした
- 出力を自動的な提案ではなく、未保有の商品カテゴリを確認するための候補一覧とした
- 前提の追跡性:
- 分析対象、商品カテゴリの単位、結果を解釈できる範囲を仕様として残した
- 最終結果がどの前提から作られたのかを確認できた
- 問題が見つかった場合も、修正すべきフェーズを判断しやすい
- 完全自動化ではない:
- 仕様の妥当性や結果の解釈には、引き続き人間による確認が必要
- 主な成果:
- コード生成の速さだけでなく、人間が前提と判断を確認できる一連の成果物を作成できたこと
■ 7. 現時点の課題
- 仕様の妥当性確認:
- AIが作成した仕様のたたき台を、人間が業務目的や条件と照らして確認する必要がある
- ドメイン知識の整理:
- 業務用語、指標の定義、データの意味を各フェーズで参照できる形にする必要がある
- 業務固有の知識を与えていないAIに目的とデータだけを渡しても、業務上の前提を含む仕様は自動的に作れない
- AIへドメイン知識を適切に与える方法も含め、整理方法を検討中
- 結果解釈での人間の判断:
- 相関を因果関係として扱わない
- 業務知識や現場の状況を踏まえて利用方法を判断する
- 利用環境の安全性:
- 実際の業務データでは、入力データの意図しない学習利用や情報漏えいを防ぐ必要がある
- 利用するAIサービスや実行環境のルールを確認し、定められたガバナンスに従う
■ 8. まとめ
- SDAの要点:
- 分析目的、データ要件、指標定義、分析方法、検証条件を仕様として残す
- 各フェーズの成果物を次へ引き継ぎ、人間が確認しながら分析を進める
- 実践例の成果:
- 曖昧な依頼を仕様へ変換し、結果を営業担当者が確認するための候補一覧として整理した
- 結果に至った前提と判断を確認しやすくなった
- SDAが目指すもの:
- 分析をAIへ丸投げすることではない
- AIが仕様やコードのたたき台を作り、人間が目的、定義、解釈、意思決定に集中できる進め方を作ること
- 今後の展望:
- 実際の分析テーマへの適用を通じて、仕様の作り方やレビュー方法を改善していく