ビジネスアナリストのワークフローにおけるAI: 活きる場面と壊れる場面

月曜日の9時14分。VP がSlackのスクリーンショットを転送してきます。CSMツールの新しいAIアシスタントによると、アクティブな顧客が前四半期に38%増加したとのことです。その数字をランチまでにボードデッキに入れたいと言っています。

データウェアハウスを開くと、実際の数字は12%に近いことがわかります。チャットボットはcustomersテーブルの全行をstatusに関係なくカウントし、データエンジニアが2月に追加したis_testフラグを無視し、月次でリセットされる指標を累計値であるかのように合計していたのです。今から40分で、自分がAIに取って代わられることを恐れているように聞こえない説明をしなければなりません。

これが今のBAの現実です。あらゆるBIツールに「平易な英語で質問する」機能が搭載されています。あらゆるIDEにJOINを書いてくれるオートコンプリートがあります。その出力のほとんどは「自信満々に間違ったSQL」です。クエリは実行され、数字を返し、ガードレールを引っかからない方法で間違った計算をします。最後の防衛線となる人間が必要です。それはまだあなたです。そしてツールは仕事を楽にしたというよりも、難しい部分の所在を変えただけです。

これは、実際のダッシュボードをリリースし、実際に失敗した経験を持つ人のために書いた、現役BAの視点です。

AIがBAに本当に役立つ場面

ここには本物の活用価値があります。原則として拒否するのは、2014年にIDEは「ジュニア向け」だからと言って、すべてのJOINを手書きにこだわったアナリストと同じ発想です。仕事は変わりました。AIが真に価値を発揮する5つの場面を挙げます。

リファクタリングのためのSQLドラフト。 スケルトンのJOIN、ウィンドウ関数の構文、誰もドキュメント化しなかったあのログフィールドのための正規表現。列名と欲しい結果の一行説明をClaudeに渡すと、70%正確で、空白ファイルから始めるより100%マシなクエリが返ってきます。その後リファクタリングします。モデルはあなたの指より速い。そもそも指がボトルネックだったことはありません。

ダッシュボードのスキーマドキュメント化。 fact_ordersに43列あり、そのうち3列はflag_2やlegacy_amt_v3のような名前です。スキーマと最近のコミット履歴をモデルに貼り付けて、列の説明文を下書きするよう依頼します。半分は修正することになりますが、以前は存在しなかったドキュメントが完成します。永遠に書かれない版よりずっとましです。

要件インタビューの準備。 ステークホルダーのキックオフの前に、モデルに「解約とはここでは何を意味するのか、カレンダー月か30日間のローリング期間か？」や「同じ期間にダウングレードしてからアップグレードしたアカウントをどう扱うか？」といった、忘れがちな厄介な質問を生成させます。モデルはあなたのビジネスを知りません。しかし、あなたが必ず聞かなければならない質問のカテゴリーを思い出させてくれます。

既知データセットの異常検知。 モデルに時系列データを見せて「注意深い人が最初に調べる箇所は？」と尋ねます。モデルは適切な箇所を指摘します。突然のnullサージ、ポイントインタイムのスパイク、行数が丸い数字に落ちる日（部分的なロードを示唆）などです。調査はまだあなたが行います。モデルはスキャンを圧縮するだけです。

データディクショナリのメンテナンス。 Jiraチケットを用語集エントリに変換するのは手間のかかる作業です。クローズされたチケットをモデルに入力して、1段落の定義を依頼するのは、AIが十分にこなせる機械的な文章作業であり、そうしなければ永遠に後回しにされる作業です。

パターンに気づくでしょうか。AIが有用なのは、入力が限定されており、あなたが編集者であり続ける場合です。モデルが最終的な作成者になった瞬間、物事が崩れ始めます。

AIが静かに壊れる場面

これが重要なセクションです。失敗は声高に起きません。クエリは実行されます。グラフが描画されます。数字が間違っていますが、それを証明するには30分のウェアハウス考古学が必要な方法で。

データのセマンティクス。 ordersテーブルにstatus列があり、値はpending、processing、shipped、delivered、returned、void、chargeback、legacy_v2などです。そのうちどれが「実際の売上」を意味するのか？財務チームには意見があります。オペレーションチームには別の意見があります。モデルはどちらも知らず、最もそれらしい選択肢、たいていはdeliveredを選びます。返品が別のバッチで処理されるため、これは約8%の確率で間違っています。

NULL処理。 モデルはデフォルトでWHERE column IS NULLチェックを使います。あなたのウェアハウスは空文字列、1900-01-01のようなセンティネル日付、リテラル文字列"NULL"、そして欠損値が-999としてエンコードされている列を使っています。これらを教えない限り、モデルは何も検知できません。ほとんどのBAは教えるのを忘れます。それらの癖を内面化して、もはや目に入らなくなっているからです。

ビジネスロジック。 「アクティブな顧客」とは、2年以上経過したウェアハウスでは少なくとも6つの定義があります。今月ログインした。有料サブスクリプションを持っている。有料サブスクリプションを持ち、支払い延滞中でない。有料サブスクリプションを持ち、支払い延滞中でなく、テストアカウントでない。過去14日間にプロダクトを使用した。月末の財務スナップショット時点でアクティブだった。モデルはそのうちの1つを選びます。そして選んだことを教えてくれません。CROはその結果をボードミーティングで引用します。

ガバナンス。 顧客の行をチャットウィンドウに貼り付けることは、データ漏洩インシデントです。スキーマの貼り付けはグレーゾーンです。実際のPIIを含むクエリプランの貼り付けは実際のインシデントです。ほとんどのBAは「Claudeに聞く」をデータ移動とは考えません。しかし法務部はそう考えますし、次の監査担当者もそう考えます。

この12ヶ月で、これらの失敗が実際の分析を壊す場面をそれぞれ目撃しました。どれも前触れなく起きます。クエリは実行されます。それが肝心なのです。

SQLのためのCursor + Claudeのループ

私と私が信頼するBAたちが実際に行っている方法です。

ステップ1: コードの前に前提を強制する。 最初のプロンプトは決して「クエリを書いて」ではありません。「SQLを書く前に、このスキーマに対してこの質問に答えるために立てなければならない前提をすべて列挙して」です。関連するテーブル定義を貼り付けます。モデルはリストを返します。編集します。前提の約3分の1は間違っており、完成したクエリと議論するよりリストと議論する方がずっと良いです。

実際の例を挙げます。質問:「Q1のプランティア別の月間アクティブアカウント数」。モデルの前提（軽く編集済み）:

1. 「アクティブ」とはカレンダー月内にlast_activity_atがあることを意味する。
2. プランティアはaccounts.plan_idをplans.tier_nameに結合したものである。
3. テストアカウント（is_test = true）は除外する。
4. 無料トライアルアカウントはアクティブとしてカウントする。
5. 1ヶ月に複数のプラン変更があるアカウントは、月末のプランに帰属させる。
6. タイムゾーンはUTCとする。

4番と5番は、私たちのレポート基準では間違っています。無料トライアルアカウントはカウントされず、財務部がそうしているため月初のプランで帰属させます。ここで発見することで、正しい形状でありながら間違った数字を報告するクエリを防げます。

ステップ2: Cursorでドラフトを作成する。 前提を修正した状態で、クエリを要求します。Cursorのエディターではサイドバーでスキーマを確認できるため、モデルが列名を幻覚する可能性が低くなります。それでも1、2個は幻覚を起こします。だから読むのです。

ステップ3: dbtのPRのようにリファクタリングする。 AIが生成したクエリをジュニアのPRと同じように扱います。目的、前提、「AIアシストによるドラフト、[あなた]がリファクタリング」を記したヘッダーコメント。非自明なJOINへのインラインメモ。結果を誰かに送る前に、末尾でテスト集計（SELECT COUNT(*) FROM finalを既知の参照値と照合）を実行します。

ステップ4: ウェアハウスに対して2回実行する。 1回目は小さい日付範囲で形状をサニティチェック。2回目は実際の範囲で答えを得ます。両方の数字がありえないと感じたら、実際にありえません。モデルはもっともらしさについて何の意見も持っていません。あなたは持っています。

このループは、ほとんどの非自明なクエリにおいて、SQLをゼロから書くよりも遅くはありません。実質的に速く、かつ最初のドラフトをそのまま受け入れる版よりも実質的に安全です。

「AIがこのクエリを生成した」という罠

新たな言い訳が広まっています。誰かが間違った数字をリリースします。ポストモーテムが行われます。その言葉が登場します:「AIがこのクエリを生成した」。

この言葉は2つの役割を担っています。正直な方:「ツールを使っていた、ツールが間違えた、気づかなかった」。これは良い、記録して、前に進む。不正直な方:「この数字の責任はモデルにあり、私にはない」。これは2009年に誰かのジョーク編集だったと判明した引用でWikipediaを裁判所の申請で引用して肩をすくめるのと現代的に同等です。

あなたが数字を送ったなら、あなたがその数字に責任を持ちます。あなたがクエリを実行したなら、あなたがそのクエリに責任を持ちます。モデルは文章作成ツールです。あなたがアナリストです。ステークホルダーはチケットに書かれたあなたの名前の先の責任の連鎖には関心がなく、関心を持つべきでもありません。

このルールの実践的な形:モデルの出力をウェアハウスで実行してから初めてステークホルダーのチケットに貼り付けます。「見る」ではありません。実行します。行数を確認して。実際のスキーマ、実際のフィルター、実際の日付範囲で。締め切りが迫っているからそのステップをスキップしようとしている自分に気づいたら、締め切りはいつだって迫っていたのであり、スキップこそが間違った数字がボードデッキで引用されることになる経緯です。

ガバナンスとバージョン管理

AIアシストによる分析は他のコードと同じように扱います。実際にコードだからです。作業チェックリスト:

• PRレビュー。 ダッシュボードや定期レポートに入るAIアシストのクエリはすべて、手書きと同じレビューを経ます。「単なる簡単な数字だから」という例外はありません。
• アシストを記録するコメント。 ヘッダー行:「-- AIアシストによるドラフト（Claude、2026-04-28）、[あなたの名前]がリファクタリングおよび検証済み。」これは次のアナリストのためであり、モデルのためではありません。
• プロンプトにPIIを含めない。 スキーマは問題ありません。テストデータなら最初の3行も通常は問題ありません。実際の顧客の行、メールアドレス、支払い詳細、従業員記録:絶対に禁止です。合成サンプルまたは列の説明のみを使用してください。
• 監査用のプロンプトログ。 CursorとClaudeはどちらも履歴を持っています。削除しないでください。6ヶ月後に何かが壊れたとき、元のプロンプトを探したくなります。
• データセットのキルスイッチリスト。 一部のテーブルはサードパーティAPIに送信されることはありません。人事記録、顧客財務情報、地域のデータレジデンシールールの対象となるものすべて。リストを書き留めます。BAのSlackチャンネルにピン留めします。新入社員はウェアハウスアクセスを与えられる前に読みます。

ガバナンスの作業は地味です。しかしそれは、AIが生産性乗数となることと、AIが来年のデータインシデントレポートに記名された原因となることの違いです。

オプション: ACEフレームワークにおける位置づけ

ビジネス全体でAI能力をマッピングするためにACEフレームワークを使用しているチームにとって、AIアシストによるBAの作業は分析（Analyze）のケイパビリティレベル（5段階中レベル2）に位置します。AIを使用して既存データを解釈し意思決定を生成しており、新しいソースの取り込み（Ingest）、予測（Predict）、文書の下書き（Generate）、ダウンストリームアクション（Execute）ではありません。

有用なフレームワークです。BAにとってAIが行っていないことを明示しているからです。データパイプラインを構築せず、将来データに対してモデルを実行せず、ステークホルダーに自動メールを送信しません。それらは他のACEの行に属し、それぞれ独自の失敗モードを持っています。レーンを明確に保つことで、会話を明確に保てます。

30日間のプラン

ここまで読んで、ワークフロー全体を書き直すことなく始める方法を求めているなら、これです。定期的なSQLタスクを1つ選んで実験を行います。

30日間の目標は「AIを導入する」ことではありません。あなたの特定のウェアハウスで、モデルがどこで嘘をつくかを学ぶことです。ウェアハウスはそれぞれ異なる方法で嘘をつきます。一般的なAIアドバイスはこれを無視します。だからほとんどが役に立たないのです。

30日後、その活用価値について正確な感覚を持てるようになります。どのタスクがAIで3倍速くなり、どのタスクが検証で節約分が消えてしまうかがわかります。チームが頭の中に持ち歩いていたことを書き留めることになり、それは将来の自分への別の贈り物です。

まとめ

BAのワークフローにおけるAIは、初日から即戦力の若手のようなものです。役立ち、熱意があり、自信満々に間違えます。活用価値は本物であり、失敗モードも本物です。仕事の本質は変わっていません。質問を理解し、ウェアハウスを理解し、正しい数字をリリースする。ツールが、難しい部分の所在を変えただけです。

モデルがどこで嘘をつくかを知っているBAは、より価値が高くなります。決して低くなりません。モデルを最終的な作成者として扱うBAは、来年のインシデントレポートで「AIがこのクエリを生成した」の隣に名前が載る人です。

最初の選択肢を選びましょう。

関連記事

• ビジネスアナリスト職務記述書テンプレート
• 信頼を生むSQLとダッシュボードデザイン
• 形骸化しない要件収集
• BAによくある落とし穴