AI Readyなデータ分析フローの構築

はじめに

こんにちは、ビジネス・アナリティクス部マーケティング・サイエンスブロックの茅原です。普段はマーケティング施策の効果検証を担当しています。マーケティング・サイエンスブロックではAI協働型分析フロー構築の取り組みをしています。本記事では本取り組みの詳細や、この中で得られた知見をご紹介します。

背景・課題

近年、生成AIの発達が目覚ましく、開発をはじめとするエンジニアリング組織ではその活用事例が多く見られるようになってきました。一方でデータ分析組織においては、エンジニアリング組織ほど生成AIとの協業事例が見られないという所感があります。これは分析組織にとって、生成AIの持つ不確実性の高さが致命的であるため、と考えています。例えば、生成AIは「ただ数値を転記する」といった簡単なタスクにおいてもハルシネーションを起こし、誤ったアウトプットを生成してしまうことがあります。データ分析においては、アウトプットの正確性が非常に重要であるため、こうした不確実性の高さは大きな障壁となっています。

本記事ではその不確実性を低減したAI協働型分析フロー構築の取り組みについてご紹介します。またこうした取り組みは、生成AIに限定せず、人間も含めた組織全体のアウトプット品質向上にも寄与するものと考えています。以下は現在検証中の内容ですが、同様の課題を抱える方の参考になれば幸いです。

取り組みの紹介

分析環境の標準化

まず前準備として、分析環境の標準化を行いました。前提として、弊チームでは環境としてはローカル/クラウド、IDEとしてはVS Code/JupyterLabなど、メンバーによって作業環境が統一されていない状態でした。こういった多様な環境によって各環境に合わせた設定が必要となり、AI活用ナレッジの転用が難しくなってしまう、という状況となっていました。そのため、Google CloudのCompute Engine (GCE)インスタンスへVS CodeからリモートSSH接続する形式に統一しました。これによりAI活用ナレッジの横展開が可能になりました。

AI活用フロー検証のためのGitHubリポジトリ構築

こちらも前準備として分析環境の標準化に加え、AI活用フロー検証のためのGitHubリポジトリ構築も行いました。具体的には、20人規模のチームで使用していたGitHubリポジトリを、4〜5人規模のチーム単位に分割しました。

旧来のリポジトリでは、リポジトリ全体へ影響を及ぼす設定変更に他チームとの合意が必要であり、検証/改善をスムーズに進められない状況になってしまっていました。チーム単位で分割することで、各チームは独自に設定を変更できるようになりAI活用ナレッジの試行錯誤がしやすくなりました。AI協働型分析フローを検証する段階においては、GitHubリポジトリの共有範囲は「ルールやフローを共有する範囲」で区切ることが検証スピードの観点から望ましいと考えています。

以下は実際のリポジトリのディレクトリ構成例です。

aia-ms/
├── projects/           # 依頼部門ごとに案件を管理するディレクトリ
│   ├── marketing_div/  # マーケティング部依頼案件ディレクトリ
│   │   └── project_001/      # 案件ディレクトリ
│   │       ├── overview.md   # 分析設計書ファイル
│   │       ├── data/         # CSV等のデータファイルディレクトリ
│   │       ├── sql/          # SQLファイルディレクトリ
│   │       ├── scripts/      # Python, Rの分析コードファイルディレクトリ
│   │       ├── notebooks/    # Jupyter Notebookのノートブックファイルディレクトリ
│   │       ├── reports/      # Markdown等のレポート関連ファイルディレクトリ
│   │       └── etc
│   └── etc
├── labs/               # メンバーごとに自由に使用するディレクトリ
│   ├── kayahara/   
│   └── etc
├── scripts/            # 再利用可能なスクリプトを管理するディレクトリ
│   ├── bq_utils/       # BigQueryを操作するスクリプトをまとめたディレクトリ
│   └── etc
└── .github/            # GitHub関連設定ディレクトリ
│   ├── workflows/      # GitHub Actionsワークフローを管理するディレクトリ
│   ├── prompts/        # GitHub Copilot Chat用プロンプトファイルを管理するディレクトリ
│   ├── agents/         # GitHub Copilot Custom Agents設定ファイルを管理するディレクトリ
│   └── copilot-instructions.md  # GitHub Copilot Chat設定ファイル

分析設計書の活用

以前から部内で使用していた分析設計書について、AI協働のためさらに活用するようになりました。前提として、弊チームでは「良い分析のためには、良い分析設計書が不可欠である」と考え、AI協働以前の2020年ごろから分析設計書を重んじるフローを構築していました。これはデータ分析が「1つの問題に対してアプローチが無数にある」タスクであり、「何を解くか」「なぜ解くか」「どう解くか」を関係者全員で合意形成しておくことが重要、という思想からです。AIとの協働においては、疑似的に「関係者」の一員としてAIが加わるため、AIに対しても「なぜこの分析をするのか」「何をもって成功とするのか」を明確に伝える必要があります。

分析設計書を活用することで、AIに対してもこれらの情報を正確に伝えることができ、アウトプットの不確実性を低減できました。具体的には、設計書の観点の見直し・充実化を行い、全案件で設計書を作成・レビューするような運用ルールを設定しました。

設計書には、主に以下の項目を記載しています。

依頼の概要
- 分析対象に関する基礎情報や依頼内容
依頼部門の理想/課題
- 依頼の背景として依頼部門が抱える理想や課題
分析対象の理想/課題
- 依頼部門が抱える理想や課題を踏まえた、分析対象に関する理想や課題
本案件で取り組む課題とゴール
- 分析対象の理想や課題に対して、本案件で取り組む具体的な課題と分析におけるゴール
アウトプット予定項目
- ゴールを達成するために必要なアウトプット項目

また、以前はGoogle Sheetsで管理していた分析設計書を、GitHubでMarkdown形式として管理する方式に変更しました。これにより、作業時にはAIへ設計書の内容を容易に参照させることができる上、設計書のレビュー時にもプルリクエスト上でGitHub Copilot Reviewを活用できるようになりました。結果として、設計書の品質向上にも寄与しました。

分析作業フローの定型化

AIのアウトプットの不確実性を下げるために、分析作業フローの定型化も行いました。AI協働型分析の良くない典型例として、「課題感を共有してAIに自由に分析させた結果、意図しないフローで進められ、期待したアウトプットが得られない」というものがあります。

具体的には、「Pythonファイルの中に長大なSQLを書いてしまう」「本来Pythonですべきような複雑な集計処理をSQLで行ってしまう」といったケースです。これを防ぐために、AI協働型分析での分析作業フローを下記のように定型化し、フローと各ステップでのアンチパターンをプロンプト内で明示的に伝えるようにしました。

社内Wikiから資料をMarkdown形式でダウンロードする
資料を基にBigQueryからSQLでデータを抽出する
抽出したデータをPythonで加工・モデル適用し、分析結果を得る
分析結果をMarkdown形式のレポートにまとめる

各ステップで再利用可能なPythonスクリプトを開発し、安定して各ステップの作業ができるようにしました。具体例としては、ステップ4では「CSVを自動でMarkdown形式の表に変換する」スクリプトを作成しました。非常にシンプルなタスクであり、AIにも可能そうに見えますが、実際にこのようなタスクを任せた際にハルシネーションが発生し「元のCSVと全く違った数値がレポートに転記される」といった事象が発生しました。そのため、このようにフローを定型化し、各ステップで再利用可能な仕組みを構築することで、AIのアウトプットの不確実性を低減しました。

再利用性を高める工夫

AI協働型分析の大きな強みの1つは、「再利用性の高さ」です。例えば、同じような分析タスクが発生した場合、過去の分析コードやプロンプトを再利用し、効率的に分析を進めることができます。これを最大限活用するため、LLMツールの機能を積極的に活用する方針を採りました。

具体的には、GitHub Copilotの以下の機能を活用しています。これらの設定ファイルはいずれもMarkdown形式で保存されています。リポジトリ内で共有可能なため、チーム内での横展開が容易です。

Prompt Files: あらかじめ定義したプロンプトをファイルとして保存し、再利用可能にする機能。これにより、分析フローの各ステップで使用するプロンプトを標準化し、チーム内で共有できるようになった。
Custom Agents: 複数のプロンプトやツールを組み合わせて、特定のタスクに特化したエージェントを作成できる機能。これにより、フローにおける各ステップを自動化するエージェントを構築し、効率的に分析を進められるようになった。

以下は分析設計書をレビューするプロンプトファイルの例です。以下のようなファイルを作成し所定のフォルダに保存することで、GitHub Copilot Chatからスラッシュコマンド形式ですぐ呼び出すことが可能となります。

---
agent: 'edit'
description: 'Review the analysis design document for clarity, consistency, and completeness, then propose specific revisions and improvements to its structure, logic, and wording.'
---
- 回答は **必ず** 日本語で記載してください
- 添付された文章を以下の観点でレビューし、修正を提案してください

# 全体
- 論理の流れがマクロからミクロへ分断なく接続できているか
- 解釈が揺れる表現、不明確な表現を使用していないか
## 1. 施策/依頼の概要
- 分析対象について、十分な情報があるか
    - 例: 施策意図、対象者、訴求方法、施策内容、検証設計(RCT有無)
## 2. 事業部の理想/課題
- 事業部の長期的な理想/課題が理解できる記述か / 短期的であったりタスクベースであったりしないか
## 3. 施策の理想/課題
- 本施策が何を目指しているか、KPIベースで記載できているか
## 4. 本案件で取り組む課題とゴール
### 課題  
- タスクリスト等ではなく課題の形式（～できていない 等）で記載できているか
### ゴール
- タスクリスト等ではなくゴールの形式（～によって○○を××する 等）で記載できているか
- 課題に紐づいたゴールとなっているか
- どのようなビジネスアクション or 貢献に繋げたいか記載できているか
### 問
- タスクリスト等ではなく問の形式（～か？）で記載できているか
- ゴールに紐づいた問となっているか
### 判断指標/基準
- 判断指標とその定量基準を記載できているか(暫定でも可)
- 判断指標/基準がない場合、代替となるもの(目標ライン等)を記載できているか
## 5. アウトプット予定項目
- アウトプット項目形式として、名詞の箇条書きにできているか
- 具体的に算出する指標を記載できているか (主要なもののみでOK)

これらの作業単位で組み上げたプロンプト&エージェントと、各案件の分析設計書を組み合わせることで、効率的かつ安定的にAI協働型分析を進められる仕組みの構築を試みています。

文化の醸成

上記のような仕組みの整備に加え、文化の醸成にも取り組みました。日夜進歩するAIへの理解度やLLMツールの活用状況は、どうしても各メンバーの興味や意欲に依存してしまう部分があり、差が付きやすいという課題があるかと思います。この差を放置すると、AIに明るくないメンバーにとっては「気が付いたら複雑なフローを組まれていて着いていけない」といった状況になり、悪循環に陥りかねません。そこで、下記の2施策を実施しました。

1点目は事例共有会の開催です。実際の案件でのAI活用事例を共有し、「どんな良さがあったか」「うまくいかないときにどうすればいいか」といったポイントをセットで共有しました。これにより、各メンバーにまず「やってみたい」と思ってもらう、使ってみて躓いたときに「もう一度試してみよう」と思ってもらうことをターゲットとしました。

2点目は初心者向けレクチャの開催です。「そもそもどんなツールがあるのか」「各ツールでどんな操作をすれば何ができるのか」という基礎的な内容を、弊チームの業務フローに合わせた形でレクチャしました。これにより、各メンバーが「やってみたい」と思ったときにすぐに試せるような土台を作りました。

上記の主要施策の他にも、Slackのtimesチャンネルやチームの朝会での情報共有など、継続的に文化醸成を図る取り組みを行っています。