AI がプロダクトに組み込まれるようになると、経験豊富な BA でさえ迷い始めます：このチームで自分は何をするのか？ AIエンジニアがプロンプトを書き、データサイエンティストがモデルを構築し、PO がバックログを優先し、PM がロードマップを管理する…では BA はどこにいるのか？
この記事はまっすぐに要点に切り込みます。
1. AI プロダクトチームの役割マップ
まず、AI 機能を開発するチームの全体像を見てみましょう：
| 役割 | 主な責任 | 意思決定の対象 |
|---|---|---|
| BA（ビジネスアナリスト） | 問題の発見、要件収集、受け入れ基準の作成、ソリューションの評価 | ビジネス要件は正しいか？ |
| PO（プロダクトオーナー） | バックログの管理、ストーリーの優先付け、Agile チームにおけるビジネスの代表 | どのストーリーを先に実装するか？ |
| PM（プロダクトマネージャー） | プロダクト戦略、GTM、価格設定、採用 | 何を、誰のために、なぜ作るか？ |
| AIエンジニア | AI パイプラインの設計、システムプロンプトの作成、モデルの統合 | どの AI 技術ソリューションが実現可能か？ |
| ML エンジニア / データサイエンティスト | モデルの学習、ファインチューニング、技術的メトリクスの評価 | どのモデルがより優れているか？ |
2. AI 機能における BA の具体的な仕事
構築前（ディスカバリー）
- ステークホルダーにインタビューして真の問題を理解する — 機能要求を聞くだけでなく
- データに裏打ちされた問題ステートメントを書く（「チャットボットが必要」ではなく「初回解決率が45%しかなく、目標より25%低い」）
- 問いかける：ここで AI は本当に必要なのか、それともシンプルなルールベースで十分ではないか？
構築中（要件定義）
- AI 機能のユーザーストーリーと受け入れ基準を作成する — エッジケースとフェイルモードを含む
- ガードレールを定義する：AI がいつ回答できるか、いつ人間にエスカレーションすべきか
- AI エンジニアと協力してモデルの制約を理解し、現実的な要件を書く
ゴーライブ後（評価）
- 当初のビジネス仮説と照らし合わせて AI 機能を評価する
- ユーザーフィードバックを収集し、改善バックログにまとめる
3. 最も混同されやすい点：BA vs PO
多くの会社で BA と PO が混用されています。しかし本質的には：
BA = 問題と要件を深掘りする人 — アウトプットは分析ドキュメント、詳細なユーザーストーリー、受け入れ基準、データマッピング、プロセスフロー。
PO = バックログと優先付けを管理する人 — アウトプットは優先付けされたプロダクトバックログ、スプリントゴール、スコープに関する意思決定。
小規模チームでは一人が両方を担うことも多いです。大規模なチームでは、BA がディープ分析を行い、PO がデリバリーの優先付けを行います。
4. BA は AI についてどれくらい知る必要があるか？
モデルを学習させる必要はありません。勾配降下法を理解する必要もありません。しかし知っておかなければならないこと：
- ハルシネーションとは何か、なぜ受け入れ基準にとって重要なのか
- RAG vs ファインチューニング：いつどちらを使うか、適切な種類の要件を書くために
- レイテンシとコスト：AI は無料ではない — トークンごとにコストがかかり、フロー設計に影響する
- 信頼度しきい値：AI が「不確か」になるのはどのレベルからか、その時人間のレビューが必要か
- データプライバシー：ユーザーの入力はトレーニングに使用されるか？
BA はこれらの質問に答える必要はありませんが、技術チームに対してこれらの質問を投げかけることを知っていなければなりません。
5. まとめ：AI 時代に BA はどのようにポジショニングすべきか
AI 時代の BA は古くからのコアを保持します — チーム内の誰よりもビジネス問題を深く理解すること — そしてそれに加えて：
- AI の能力と制約について正しい質問をすること
- AI 機能の受け入れ基準を作成すること（標準的な CRUD 機能だけでなく）
- ビジネスの観点から AI 出力品質の評価に参加すること
- AI が誤りを犯したり害を与えたりする際にユーザーを守る人であること
役割がなくなることはありません — それはレベルアップしています。