「優秀なBAはどんなドメインでも働ける」— これは半分だけ正しいです。BAの基礎はトランスファラブルですが、ドメイン知識が各業界でのBAのスピードと深さを決定します。そしてAI時代には、ドメイン知識はさらに重要になります。
1. Fintech：規制された環境におけるAI
1.1 FintechにおけるAIの一般的なユースケース
| ユースケース | AIの役割 | BAキースキル |
|---|---|---|
| 不正検出 | リアルタイム取引スコアリング | 偽陽性/偽陰性のトレードオフ、異議申し立てプロセスの設計 |
| 信用スコアリング | 代替データ評価 | 説明可能性（ECOA）、バイアス監査 |
| AML/KYC | 文書確認、リスクスコアリング | 規制への理解、監査証跡 |
| バンキングチャットボット | 顧客サービス、製品推薦 | コンプライアンス言語、人間へのエスカレーション |
| アルゴ取引 | 市場予測（ニッチ） | ほとんどのBAの範囲外 |
1.2 Fintech BAが知っておくべき規制
| 規制 | AIへの影響 | BAがすべきこと |
|---|---|---|
| GDPR / PDPA | 同意なしにAIがPIIを使用できない | 要件にプライバシー・バイ・デザインを組み込む |
| ECOA（米国） | 信用決定AIは説明可能でなければならない | ACにXAI（説明可能なAI）を要求する |
| AMLディレクティブ | AIリスク決定の監査証跡が必要 | タイムスタンプ付きですべてのAIスコアリングイベントをログに記録 |
| PCI DSS | 支払いデータをLLMに公開できない | APIコール前にデータをマスキング |
| MAS TRM（シンガポール） | 金融機関のAIモデルガバナンス | モデルライフサイクルのRACI |
1.3 Fintech固有のBAスキル
- 調整思考： すべての金額が一致する必要がある — AIはお金を作ったり失ったりできない
- 四つ目の原則： 高額取引には二重承認が必要（AI＋人間）
- 監査証跡へのこだわり： すべてのAI決定が追跡可能でエクスポート可能でなければならない
- 説明可能性の要件： 「なぜAIはこのローン申請を拒否したのか？」— 答えられる必要がある
2. Healthcare：臨床環境におけるAI
2.1 HealthcareにおけるAIユースケース
| ユースケース | リスクレベル | 規制 |
|---|---|---|
| 臨床意思決定支援 | 非常に高い | FDA 510(k)、CEマーク |
| 医療画像AI | 非常に高い | FDA、IEC 62304 |
| 管理自動化 | 中 | HIPAA |
| 患者チャットボット（トリアージ） | 高い | 州の医療委員会規則 |
| 収益サイクル自動化 | 低〜中 | CMS、支払者要件 |
2.2 BAのためのHIPAA基礎
PHI（保護医療情報）= 患者を特定できるあらゆるデータ：
- 氏名、住所、生年月日、SSN、電話番号
- 医療記録番号、健康保険番号
- 生体識別子、写真
- IPアドレス（場合によっては）、地理的データ
PHIを使用するAIのBA要件：
1. 最小限必要の原則 — AIは実際に必要なデータフィールドのみ使用
2. 外部LLMに送信する前に非識別化
3. AIベンダーとのBusiness Associate Agreement（BAA）
4. PHIへのすべてのアクセスの監査ログ
2.3 臨床ワークフローへの理解
Healthcare BAが理解すべきこと：
- ケア設定： ICU vs 救急 vs 外来 — AI決定の時間許容度が異なる
- 臨床役割： 医師 vs 看護師 vs 管理スタッフのワークフロー — UIと権限が異なる
- アラート疲労： AIアラートが多すぎる → 臨床医がすべてを無視する → 危険
- 責任： 臨床コンテキストでAIが間違えた場合、誰が責任を負うか？（法的レビューが必要）
3. eCommerce：ハイベロシティ環境におけるAI
3.1 eCommerceにおけるAIユースケース
| ユースケース | インパクト | 主要指標 |
|---|---|---|
| 製品レコメンデーション | +15〜30%のバスケットサイズ | クリックスルー率、コンバージョン |
| 検索関連性 | ゼロ結果率の削減 | 検索 → 購入率 |
| 不正検出 | チャージバックの削減 | 偽陽性率（正当な注文のブロック） |
| 価格最適化 | 動的価格設定 | セッションあたりの収益 |
| レビューモデレーション | ブランド保護 | 偽陽性（正当なレビューの削除） |
| カスタマーサービスチャットボット | コスト削減 | FCR、CSATスコア |
3.2 eCommerce固有の考慮事項
パーソナライゼーション倫理：
- 価格差別（同じ製品、セグメントによって異なる価格）— 一部の管轄区域では法的リスク
- フィルターバブル：AIはユーザーが既に好むものだけを表示する → 発見性の低下
- BAはダイバーシティ/セレンディピティインジェクションを仕様化する必要がある：「推薦の10%はフィルターバブルの外のものでなければならない」
A/Bテスト文化：
- eCommerceは意見ではなくデータで決断する
- BAが理解すべき：統計的有意性、最小検出効果、ホールドアウトグループ
- すべてのAIフィーチャーはリリース前にA/Bテスト仕様が必要
フラッシュセール/イベント処理：
- 通常トラフィックでトレーニングされたAIモデルはフラッシュセール中に失敗する
- BAは仕様化する必要がある：「イベントモード中（手動トリガー）、AIレコメンデーションは無効化し、編集リストにフォールバック」
4. スキル比較：最も異なること
| スキル | Fintech BA | Healthcare BA | eCommerce BA |
|---|---|---|---|
| 規制知識 | AML/KYC/PCI | HIPAA/GDPR/FDA | GDPR＋プラットフォームルール |
| リスク許容度 | 非常に低い | 極めて低い | 中程度 |
| ユーザーリサーチ | UX＋コンプライアンスレビュー | 臨床医のシャドーイング | 定量的UX |
| データリテラシー | 取引データ、コホート分析 | EHR、HL7/FHIR | クリックストリーム、ファネル |
| AI説明可能性 | 必須（信用） | 必須（臨床） | あると良い |
| 反復速度 | 遅い（コンプライアンスサイクル） | 非常に遅い（CE/FDA） | 速い（週次デプロイ） |
5. 自分に合ったドメイントラックを選ぶ
決定するための質問：
1. あなたのリスク許容度は高いですか、低いですか？
→ 低い（慎重、プロセス指向）= Fintech/Healthcare
→ 高い（実験が好き）= eCommerce/コンシューマーテック
2. 規制/コンプライアンスを学ぶのが好きですか、市場ダイナミクスが好きですか？
→ 規制 = Fintech/Healthcare
→ 市場 = eCommerce
3. あなたのバックグラウンドは何ですか？
→ 金融/会計 → Fintech
→ 理系/看護 → Healthcare
→ 小売/マーケティング → eCommerce
まとめ
ドメイン専門知識はBAスキルを増幅させます。3年の経験を持つFintech AI BAは、3年の経験を持つeCommerce AI BAとは全く異なる価値を持っています — どちらが「優れている」わけではありませんが、1〜2週間で互換性はありません。
1つのドメインフォーカスを選び、その規制とユースケースを深く掘り下げ、「なぜビジネスにこれが必要なのか」を理解してほしいときに技術チームが信頼する人物になってください。