# Failure Patterns & Counter-Cases：Tiger AI 方法論を適用すべきでない / 失敗する時

> 🌐 言語：[繁體中文](FAILURE_PATTERNS.md) ｜ [English](FAILURE_PATTERNS_EN.md) ｜ [Deutsch](FAILURE_PATTERNS_DE.md) ｜ [Français](FAILURE_PATTERNS_FR.md) ｜ [Español](FAILURE_PATTERNS_ES.md) ｜ 日本語 ｜ [한국어](FAILURE_PATTERNS_KR.md)
>
> Apache License 2.0 · 著者：Morris Lu · Tiger AI

最終更新：2026-05-16

---

> **目的**：成功のみを議論する方法論はセールス資料。学術 / 規制 / 真剣な顧客は問う：「**いつ失敗するか？いつ適用すべきでないか？レベルをスキップすると何が間違うか？**」 本ドキュメントは既知の failure patterns と counter-cases を、方法論の批判可能性と改善可能性のハードエビデンスとして公開記録する。

---

## 1. なぜ方法論は Failure Modes を公開しなければならないか

| オーディエンス | なぜ失敗を見る必要があるか |
| --- | --- |
| **学術レビュアー** | 成功のみのケース = selection bias → 出版不可 |
| **規制当局** | リスク評価は failure modes + early-warning 条件を含まねばならない |
| **真剣な顧客** | 「**いつ失敗するか教えてくれ**」は真の信頼質問 |
| **コンサルタント** | Failure modes = 組織記憶 = 繰り返し回避 |

> **成功のみを議論する**方法論は、**失敗を認める**方法論より信頼性が低い。

---

## 2. レベルスキップの失敗

### 2.1 L1 スキップ → L4 Agent へジャンプ

**症状**：全社的 L1 採用なし。ボスが Agent デモを見て、カスタマーサービス Agent を欲しがる。3 エンジニアが 3 ヶ月で Agent を構築。ライブ後：CS スタッフが使うのを恐れる、QC が承認しない、IT がオーディットログのつなぎ方を知らない、Compliance が「誰がリスクを負うのか」と問う。

**根本原因**：スタッフは L1 を通じた **個人的信頼**を構築していない；L2 Skill Library なし → Agent には「会社が書いた判断ロジック」がない；L3 Workflow なし → Agent はシステムに作用する合法的パイプを持たない；L1-L3 ガバナンス基盤なし → Agent はコンプライアンスブラックボックスとしてライブする。

**典型的結末**：Agent は 6 ヶ月で廃止；IT 部長が責められる；AI 予算カット。

### 2.2 L2 スキップ → L3 Workflow を直接構築

**症状**：IT が n8n チュートリアルを見る → Gmail → CRM → Slack チェーンを構築。月 1：動く。スタッフが「出力がオフトーン / 我々の SOP を引用していない」と苦情。エンジニアがプロンプトをチューニングするが、**各 Workflow に 10 プロンプトが n8n ノードに散在 — オーナーなし、バージョンなし、ドキュメントなし**。

**根本原因**：「会社が書いたプロンプト + 判断 + データ」としての L2 Skill Library がない → L3 が「IT エンジニアの個人プロンプトプレイグラウンド」になる。

**典型的結末**：Workflow 品質が時間とともにドリフト；3 ヶ月後ビジネスユニットが revert を要求；IT は信頼を失う。

### 2.3 HITL なしで L3 / L4 へ

**症状**：Workflow が自動的に顧客メールを送信、自動的に請求書を作成、自動的にオーダーを配置。月 1：70% 効率向上。月 2：LLM ハルシネーション → tier-A 顧客への誤価格見積り → NT$ 300 万契約損失。

**根本原因**：全ての AI に ~0.5-3% ハルシネーション率。**HITL なし = 遅かれ早かれ zero-tolerance シナリオに当たる**。

**典型的結末**：C-suite が AI 禁止；AI Champion が罰せられる；方法論が「unreliable」とラベル付けされる。

### 2.4 L4 安定化前に L5 ClawTeam を急ぐ

**症状**：ボスがマルチエージェントデモを見て、Sales + CS + QC 部門横断 Agent Team を欲しがる。一つの Agent も Stage Gate 4A-4E を通っていないのに、3 Agent がチェーン化される。Evidence trail が Agent 間で壊れる → 誰も決定をトレースできない。

**根本原因**：単一 Agent がガバナンスされていない → multi-Agent は制御を失わざるを得ない（どの Agent がどの問題を引き起こしたか誰も特定できない）。

**典型的結末**：プロジェクトは 6 ヶ月で解散；単一 Agent に戻る；半年無駄に。

---

## 3. Organizational Misfit 失敗

### 3.1 AI Champion なし（エグゼクティブドライバー）

**前提条件**：各 Phase は少なくとも 1 人の Champion が必要、「部門横断調整、決定、Sponsor へ報告」可能な人。

**失敗**：CEO が Phase A に署名するが Champion を指名しない → インタビュー中に部門長が責任を押し付け合う → As-Is 不完全 → Phase A 品質低い → 顧客は Phase B に署名しない。

**Tiger AI 拒否**：Phase B 前に Champion が定位置にない場合、**コンサルタントは署名を拒否すべき**、または Champion 指名を先に要求。

### 3.2 L3+ に IT キャパシティ不足

**前提条件**：L3 Workflow + L4 Agent は継続的メンテナンスに 0.5-2 IT FTE が必要。

**失敗**：会社に IT が 1 人、すでに ERP / ネットワーク / Helpdesk で maxed。5 Workflow がライブ → 誰もメンテナンスしない → 6 ヶ月で 50% 失敗 → スタッフは手動に戻る。

**Tiger AI 拒否**：Tool 6.3 Organizational Absorption「IT FTE」< Phase 2 最小（0.5 専任 FTE）の場合、**顧客に強く IT 追加を先にするよう助言**。

### 3.3 Compliance/規制不足（センシティブ業界）

**前提条件**：Financial / Healthcare / Government / Legal は強いコンプライアンス要件を持つ。

**失敗**：病院が HIPAA / PIPA / 患者権利レビューなしに CS AI をデプロイ → 3 ヶ月後に厚生省により監査 → AI 引き上げ、罰金、ニュースに → AI プランが失敗するだけでなく IT ガバナンス全体が疑問視。

**Tiger AI 拒否**：センシティブ業界で専任 Compliance Officer / 弁護士レビューなし → **Phase A 終了レポートは「コンプライアンス未検証 → Phase B 中断」をマークしなければならない**。

### 3.4 エグゼクティブターンオーバーが 24 ヶ月ロードマップを壊す

**前提条件**：Phase C 24 ヶ月は安定した Sponsor サポートが必要。

**失敗**：Phase A は CEO 署名；CEO が Phase C 月 9 に離任 → 新 CEO が反対 → Phase C 凍結 → NT$ 980 万投資、部分出力（L1-L3）保持されるが L4-L5 放棄。

**Tiger AI 緩和**：Phase C 四半期 Gate C exit メカニズム = Sponsor が変わっても、各四半期は独立して再評価可能、sunk-cost-all-lost ではない。

---

## 4. 既知の方法論限界

### 4.1 スコアリングモデルに心理測定検証なし

**ステータス**：6 構成概念 × 0-4 スケールと L1-L5 境界は**専門家コンセンサス**、Cronbach's α / EFA / CFA / 評価者間信頼性で**まだ検証されていない**。

**潜在的問題**：

- 2 人のコンサルタントが同じ会社をスコアして L2 vs L3 を yield する可能性
- 「50-60 = L2 境界 vs 41-60 = L2」に実証的基盤なし
- 構成概念にコリニアリティの可能性；実際の因子数が異なる可能性

**Tiger AI 対応**：レポートは「専門家コンセンサス版、心理測定検証保留」を明示マーク；`PILOT_STUDY_PROTOCOL.md` が実証研究を計画；学術提出は claim strength を「a proposed framework」に下げるべき。

### 4.2 ケースライブラリ Evidence Level

**ステータス**：7 ケースは Evidence Level 2 の**匿名化合成**（Tool 8.9 ごと）。

**潜在的問題**：顧客が「これらの数字は本物か捏造か」と問う可能性。ROI ~358%、不良率 3.2 → 2.0% は**いかなる単一顧客の契約コミットメントとしても使用できない**。

**Tiger AI 対応**：各ケースヘッダーは Evidence Level と Composite 性質をマーク；SOW は顧客自身のベースラインを使用、ケース数字ではない；実 L3-L5 縦断ケースで段階的に置換。

### 4.3 Tiger AI L1-L5 認知度はまだ新しい

**ステータス**：Tool 2.5 self-qualification 9/10；Condition 6（広い業界認識）は △ 部分。

**潜在的問題**：初期接触者が「APQC、SCOR は国際的に認知されている — Tiger AI L1-L5 はどの権威か？」と問う。学術引用はクリティカルマスに達していない。

**Tiger AI 対応**：オープンソース（Apache 2.0 + GitHub）；ISO/IEC ワーキンググループ / IEEE AI Maturity 標準議論と積極的にエンゲージ；学術パートナー機関との共同研究構築（具体的パートナーは MOU 締結後に開示）。

---

## 5. コンサルタントレベル Anti-Patterns（内部失敗）

### 5.1 Phase A スキップ → Phase B-C 直接署名

**症状**：セールスプレッシャー → Phase A スキップ → 6 ヶ月エンゲージメント直接署名。
**結果**：顧客署名済み As-Is / RM / Ideal なし → Stage 4+ で顧客が「これは我々が望んだものではない」と否定可能 → コンサルタントは守勢。
**規律**：**Phase A は絶対にスキップしない**。それは後続全てのアンカー。

### 5.2 顧客の Ideal Practice を顧客のために起草

**症状**：時間節約のため、コンサルタントが Ideal Practice を顧客が署名するために起草。
**結果**：顧客はオーナーシップを感じない → 後で各項目に挑戦 → 推論チェーン崩壊。
**規律**：**Tool 3.6 Co-Creation Workshop 6 ステップを実行しなければならない**。独立投票、集合的コンセンサス、reality check、definition table、3 者署名 — どのステップもスキップできない。

### 5.3 L1 Self-Report のみに基づくレポート

**症状**：書きを急ぐ → 全結論が顧客自己アンケートから。
**結果**：顧客内部監査 / 親会社により監査 → 「insufficient evidence」 → プロジェクト全体差し戻し。
**規律**：Tool 8.9 Evidence Hierarchy 通り、**いかなる主要結論も L3+（system log）サポートが必要**。各段落が `[E:L#]` をマーク。

### 5.4 Risk を Gap Analysis に混ぜる

**症状**：Stage 4 章が「このリスクは高い、推奨しない」主観的判断を混ぜる。
**結果**：Stage 4 が主観的になる → 顧客が「なぜリスクと思うのか」と挑戦 → 章再書き。
**規律**：**Stage 4 = 客観的ギャップインベントリ、リスク評価ではない**。リスクは Stage 8 Risk Register に属する。

### 5.5 Gate C で四半期 Stage 2 レーダー再訪をスキップ

**症状**：実装中、PoC にフォーカス、各四半期は進捗のみ報告、レーダー再訪なし。
**結果**：PoC は完了するが構造的完全性は変化なし → 24 ヶ月後「実際に改善したか？」答えられない。
**規律**：**四半期 Gate C はレーダーを再訪しなければならない**。しないこと = コンサルタント過失。

---

## 6. Hard Refusal Conditions

Tiger AI は以下の条件下で Phase C 署名を**拒否すべき**（顧客が望んでも）：

- [ ] **Phase A + B 未完了** → 署名済み Ideal Practice なし → Phase C 拒否
- [ ] **AI Champion 定位置確認なし** → Phase C 拒否
- [ ] **ターゲット Phase に IT FTE 不足** → 遅延 + IT 先追加を強く推奨
- [ ] **センシティブ業界で Compliance Officer / 弁護士レビューなし** → Phase C 拒否
- [ ] **Sponsor 定位置なし（明確な CEO サポートなし）** → Phase C 拒否
- [ ] **顧客がレベルスキップを望む（例：L1-L3 → L4-L5 スキップ）** → 拒否、Phase 1 基盤要求
- [ ] **現フェーズに予算不足** → 拒否、スコープ縮小助言

---

## 7. Customer Exit Protocol

Phase A / B / C いずれかが失敗した場合、Tiger AI はコミット：

1. **Phase A 失敗**：顧客は mid-engagement レポート + インタビューサマリー + レーダーを保持 → **自己実行または次のコンサルタント雇用可能**
2. **Phase B 失敗**：完全レポート + 署名済み Ideal Practice テーブル保存 → **他コンサルタントへ移管可能**
3. **Phase C 途中失敗（四半期 Gate C 停止決定）**：完了 Phase 保存 + ガバナンスドキュメント保存 + コード / Skills / Workflow 完全に顧客へ移管（コンサルタントは**顧客資産を保持しない**）
4. **顧客資産の人質取りなし**：[`../06_Delivery/ENGAGEMENT_LIFECYCLE_EN.md`](../06_Delivery/ENGAGEMENT_LIFECYCLE_EN.md) 7 Pillars #1「Client Hosts」 ごと

---

## 8. 本ドキュメントの使い方

| 役割 | 使用 |
| --- | --- |
| **コンサルタント内部トレーニング** | 必須オンボーディング読み物；四半期チームレビュー「先四半期どの failure pattern にヒットしたか」 |
| **顧客との署名前** | コンサルタントが本 doc を積極的に共有 → 顧客は「このコンサルタントは成功のみを売らない、失敗を正直に議論する」と信頼 |
| **学術提出** | 方法論クリティカリティ / 反証可能性のエビデンスとして引用 |
| **規制 / ビッドドキュメント** | リスク評価 + 緩和エビデンスとして添付 |

> **正直に失敗を議論 = セールススキルの最高形**。顧客は「保証された成功」ではなく「失敗時に何をすべきか我々は知っている」を買う。

---

ライセンス & 引用

本ドキュメントは Apache License 2.0；[`../NOTICE`](../NOTICE) 帰属が保持されることを条件に、使用、修正、商業化可能。
