【非エンジニアのためのClaude/ClaudeCodeシリーズ】ClaudeのSkillを作成し、案件分析させてみた

---
name: lost-deal-analysis
description: |
  失注分析レポートを自動生成するスキル。CRMから失注案件の情報を収集し、事実としての失注要因の整理・推論による仮説出し・次回アプローチ提案をWord文書（.docx）として出力する。
  以下のようなユーザー発言で必ずこのスキルを使うこと：
  - 「失注分析」と入力された場合（会社名・案件名が未指定でも必ず起動する）
  - 「失注分析して」「失注案件を分析」「負け分析」「クローズドロスト」「失注した案件をまとめて」「lost dealを分析」
  - 特定の会社名や案件名と「失注」「負け」「closed lost」を組み合わせた発言
  - 「なぜ負けたか」「なぜ失注したか」「競合に負けた原因」を分析したい発言
  - 営業担当者からの「次のアプローチを考えたい」「再提案のタイミングを知りたい」という文脈
  - 「受注確度」「提案中案件のリスク分析」「商談確度を確認したい」という文脈
---

# 失注・受注確度分析スキル

このスキルはCRMの案件データを収集・分析し、営業担当者・マネージャー向けの構造化された分析レポート（Word形式）を生成する。

**対応する分析タイプ**：
- **失注分析**：失注した案件の要因分析と次回アプローチ提案
- **受注確度分析**：提案中案件のリスク分析とS/A/B/C確度評価・アクションプラン

## ステップ1：対象案件の特定

まず `[CRM連携ツール]__get_user_details` を呼んでユーザー情報を取得する（CRM検索で使用）。

次に、**ユーザーがすでに会社名・案件名・ステージを指定しているかどうかに関わらず**、必ず `AskUserQuestion` ツールで以下の3点を確認する。これはフォームとして機能させるため、省略しない。

質問1（header: "会社名"）：
「分析したい会社名を入力してください」
選択肢：
  - （会社名をOtherに入力）  ← 必ずOtherで自由入力させる
  - 不明（案件名で検索する）

質問2（header: "案件名"）：
「案件名を入力してください（分からない場合はキーワードでも可）」
選択肢：
  - （案件名・キーワードをOtherに入力）  ← 必ずOtherで自由入力させる
  - 不明（会社名だけで検索する）

質問3（header: "案件ステージ"）：
「この案件は現在どのステージですか？」
選択肢：
  - 失注（Closed Lost）
  - 提案中（進行中の商談）

入力された情報をもとに `DEAL_STAGE` を確定する。

- 質問3で「失注」→ `DEAL_STAGE = "closed_lost"` → **失注フロー**で進める
- 質問3で「提案中」→ `DEAL_STAGE = "active"` → **提案中フロー**で進める

## ステップ2：CRMからデータ収集

以下の順で情報を収集する。**各ステップは並列で実行できるものはまとめて呼ぶ。**

### 2-1. 案件の検索

`search_crm_objects` で deals を検索。

**失注フローの場合**（`DEAL_STAGE = "closed_lost"`）：

objectType: "deals"
filterGroups: [
  { filters: [
      { propertyName: "deal_stage", operator: "EQ", value: "closed_lost" },
      { propertyName: "deal_name", operator: "CONTAINS_TOKEN", value: "<ユーザー入力>" }
  ]}
]
properties: ["deal_name","amount","deal_stage","close_date","closed_won_date","deal_stage_probability",
             "pipeline","owner_id","last_modified_date","description",
             "lost_reason","analytics_source","associated_contacts_count"]

**提案中フローの場合**（`DEAL_STAGE = "active"`）：

objectType: "deals"
filterGroups: [
  { filters: [
      { propertyName: "deal_name", operator: "CONTAINS_TOKEN", value: "<ユーザー入力>" }
  ]}
]
properties: ["deal_name","amount","deal_stage","close_date","deal_stage_probability",
             "pipeline","owner_id","last_modified_date","description",
             "analytics_source","associated_contacts_count"]

`closed_lost` で見つからない場合は `deal_stage` フィルターを外し、案件名・会社名だけで検索してステージを確認する。

### 2-2. 関連情報の並列収集

案件IDが分かったら、まず**連絡先・会社**を取得してオーナーIDを確定してから、アクティビティを絞り込む（2段階）。

#### ステップA：連絡先・会社を取得（並列）

**連絡先（contacts）**：

objectType: "contacts"
associatedWith: [{ objectType: "deals", operator: "EQUAL", objectIdValues: [<deal_id>] }]
properties: ["firstname","lastname","email","jobtitle","phone","email_last_open_date"]

**会社（companies）**：

objectType: "companies"
associatedWith: [{ objectType: "deals", operator: "EQUAL", objectIdValues: [<deal_id>] }]
properties: ["name","industry","annualrevenue","numberofemployees","city","country","description","owner_id"]

#### ステップB：オーナーIDの確定

以下2つを収集し、重複を除いて `OWNER_IDS`（文字列配列）として保持する：

- **取引担当者ID**：2-1で取得した案件の `owner_id`
- **会社担当者ID**：会社の `owner_id`

例：`OWNER_IDS = ["44124561", "526758200"]`（同一の場合は1件のみ）

> ※ どちらかが取得できない場合は、取得できたIDのみで進める。

#### ステップC：アクティビティをオーナーで絞り込んで取得（並列）

notes / calls / meetings / tasks / emails はすべて、案件への紐付け（associatedWith）に加えて **`owner_id IN OWNER_IDS` フィルターを必ず追加**する。これにより、取引担当者・会社担当者によるアクティビティのみに絞り込み、無関係な担当者のアクティビティを除外する。

**ノート（notes）**：

objectType: "notes"
filterGroups: [
  {
    filters: [{ propertyName: "owner_id", operator: "IN", values: OWNER_IDS }],
    associatedWith: [{ objectType: "deals", operator: "EQUAL", objectIdValues: [<deal_id>] }]
  }
]
properties: ["note_body","timestamp","owner_id","attachment_ids"]
sorts: [{ propertyName: "timestamp", direction: "DESCENDING" }]
limit: 50

**コール（calls）**：

objectType: "calls"
filterGroups: [
  {
    filters: [{ propertyName: "owner_id", operator: "IN", values: OWNER_IDS }],
    associatedWith: [{ objectType: "deals", operator: "EQUAL", objectIdValues: [<deal_id>] }]
  }
]
properties: ["call_body","call_title","call_duration","call_status","call_direction","timestamp","owner_id"]
sorts: [{ propertyName: "timestamp", direction: "DESCENDING" }]
limit: 30

**ミーティング（meetings）**：

objectType: "meetings"
filterGroups: [
  {
    filters: [{ propertyName: "owner_id", operator: "IN", values: OWNER_IDS }],
    associatedWith: [{ objectType: "deals", operator: "EQUAL", objectIdValues: [<deal_id>] }]
  }
]
properties: ["meeting_title","meeting_body","meeting_outcome","timestamp","owner_id","internal_meeting_notes"]
sorts: [{ propertyName: "timestamp", direction: "DESCENDING" }]
limit: 20

**タスク（tasks）**：

objectType: "tasks"
filterGroups: [
  {
    filters: [{ propertyName: "owner_id", operator: "IN", values: OWNER_IDS }],
    associatedWith: [{ objectType: "deals", operator: "EQUAL", objectIdValues: [<deal_id>] }]
  }
]
properties: ["task_subject","task_body","task_status","timestamp","owner_id"]
sorts: [{ propertyName: "timestamp", direction: "DESCENDING" }]
limit: 20

**メール（emails）**：

objectType: "emails"
filterGroups: [
  {
    filters: [{ propertyName: "owner_id", operator: "IN", values: OWNER_IDS }],
    associatedWith: [{ objectType: "deals", operator: "EQUAL", objectIdValues: [<deal_id>] }]
  }
]
properties: ["email_subject","email_body","email_direction","timestamp","owner_id","email_status"]
sorts: [{ propertyName: "timestamp", direction: "DESCENDING" }]
limit: 30

### 2-3. 外部メールツールによる補完（任意）

外部メールツールとの連携が利用可能な場合、連絡先のメールアドレスを使って追加のメールスレッドを検索する。
CRMのメールデータが乏しい場合に特に有効。

[メール連携ツール]__search_messages: "from:<contact_email> OR to:<contact_email>"

## ステップ2.5：営業担当者からの補足情報収集（必須）

CRMのデータ収集が完了したら、分析を始める**前に**必ず以下の補足情報を収集する。`DEAL_STAGE` によって質問内容を切り替える。

### 【失注フロー】収集する質問

`AskUserQuestion` ツールで以下の質問を行う（2回に分けて収集）。

**1回目の質問（案件の核心部分）**：

質問1（header: "失注の核心"）：
「ご自身の感触として、最も大きな失注要因は何だったと思いますか？」
選択肢：
  - 価格・予算の問題
  - 競合他社に負けた
  - 顧客の社内事情（優先度低下・予算凍結など）
  - 製品・サービスのフィット感が弱かった
  - タイミングが合わなかった
  ※ Other（自由記述）

質問2（header: "競合状況"）：
「競合他社の状況を教えてください」
選択肢：
  - 具体的な競合名が分かった（→ Otherで入力）
  - 競合はいたが詳細不明
  - 現状維持・内製が選ばれた
  - 競合は特にいなかった（予算・優先度の問題）
  ※ Other（競合名・状況を自由記述）

**2回目の質問（関係性と今後の見通し）**：

質問3（header: "顧客の温度感"）：
「失注時点での顧客との関係性・温度感はどうでしたか？」
選択肢：
  - 良好。今後も関係継続できると思う
  - 普通。距離を置かれた感じ
  - 冷え込んだ。しばらく接触しにくい
  - キーパーソンが変わった・去った

質問4（header: "担当者コメント"）：
「その他、CRMに記録しきれなかった背景・状況・感じたことがあれば教えてください。
▶ コメントがある場合は「Other（その他）」を選択して入力欄に記入してください。」
選択肢：
  - 特になし（追加コメントなし）
  - 競合・価格についての補足がある → Otherに入力
※ コメントがある場合は必ず「Other」を選んでテキストを入力してから送信してもらう

### 【提案中フロー】収集する質問

`AskUserQuestion` ツールで以下の質問を行う（2回に分けて収集）。

**1回目の質問（現状のリスク・課題）**：

質問1（header: "現状の懸念点"）：
「現在、この案件で最も気になっている課題・リスクは何ですか？」
選択肢：
  - 意思決定者へのアクセスができていない
  - 予算・価格面での不安がある
  - 競合の存在が気になる
  - 顧客の優先度が下がっている気がする
  - 提案内容のフィット感が弱い
  ※ Other（自由記述）

質問2（header: "競合状況"）：
「競合他社の状況を教えてください」
選択肢：
  - 具体的な競合名が分かった（→ Otherで入力）
  - 競合はいるが詳細不明
  - 現状維持・内製の選択肢が有力
  - 競合は特にいない
  ※ Other（競合名・状況を自由記述）

**2回目の質問（温度感と見通し）**：

質問3（header: "顧客の温度感"）：
「現在の顧客との関係性・温度感はどうですか？」
選択肢：
  - 非常に前向き。受注の可能性が高い
  - まずまず。次のステップに進めそう
  - やや停滞。顧客側で迷いがある感じ
  - 厳しい。担当者・優先度の変化がある

質問4（header: "担当者コメント"）：
「その他、CRMに記録しきれなかった商談の状況・感触があれば教えてください。
▶ コメントがある場合は「Other（その他）」を選択して入力欄に記入してください。」
選択肢：
  - 特になし（追加コメントなし）
  - 商談の状況・見通しについての補足がある → Otherに入力

### 補足情報の扱い方

- 選択肢の回答・自由記述の内容を `SALES_INPUT` として保持する
- **「事実（CRM記録）」と「担当者の主観（補足）」は明確に区別して**レポートに反映する
- 担当者コメントは分析の「文脈補完」として使い、仮説の根拠に引用可能
- 担当者が「特になし」と答えた項目は無理に引用しない

## ステップ3：分析・レポート構成

`DEAL_STAGE` によって分析フレームを切り替える。

### 3-0. 情報ソースの区分（共通）

| ソース | 信頼性 | レポート内の表記 |
|--------|--------|----------------|
| CRMの記録データ | 客観・事実 | `[CRM記録]` |
| 外部メールツールなど外部ツールのデータ | 客観・事実 | `[メール記録]` |
| 営業担当者の補足コメント | 主観・現場感 | `[担当者コメント]` |

---

### 【失注フロー】分析

#### 3-1. 事実の整理（ファクト）

CRMに記録されている客観的情報をそのまま整理する：

- **失注理由（公式）**: `lost_reason` の値
- **タイムライン**: 最初のコンタクトから失注までの期間・フェーズ推移
- **接触頻度**: コール回数・ミーティング回数・メール往復数
- **キーパーソン**: 誰と何回接触したか（役職・関与度）
- **金額・規模**: 案件金額・会社規模
- **競合**: ノートやメールで言及されている競合他社
- **明示的な懸念事項**: 顧客が直接伝えた懸念・要望

#### 3-2. 失注要因の仮説（推論）

事実に基づいて論理的に推論する：

**価値・ニーズの観点**
- ソリューションが顧客課題にフィットしていたか
- 顧客の優先課題とアプローチの順序は合っていたか

**タイミング・プロセスの観点**
- 接触頻度・間隔に問題はあったか
- 意思決定者へのアプローチができていたか

**競合・代替案の観点**
- 競合が有利だった点は何か（価格・機能・実績・リレーション）
- 「現状維持」「内製」という選択肢が取られた可能性はあるか

**コミュニケーションの観点**
- 提案内容や訴求ポイントは適切だったか
- 顧客の懸念に十分応えられていたか

> **注意**：仮説はあくまで「推論」であることを明記し、断定しない。

#### 3-3. 次回アプローチ提案

失注要因の仮説と顧客状況に基づき、以下を具体的に提案する：

**アプローチ時期**
- 顧客の予算サイクル・契約更新時期・プロジェクト開始時期を考慮
- 競合の初期契約期間（一般的に1〜2年）を踏まえた再提案タイミング

**アプローチ内容**
- 次回の接点づくりに使えるネタ（新機能・事例・業界動向）
- 前回の課題・懸念を解消できる新しい角度での提案内容

**アプローチ先の優先順位**
- 最も効果的な連絡先（キーパーソン）の特定

---

### 【提案中フロー】分析

#### 3-1P. 事実の整理（ファクト）

現在進行中の商談に関するCRMデータを整理する：

- **現在のステージ**: CRMのステージ値と推移
- **タイムライン**: 商談開始から現在までの期間・主要アクティビティ
- **接触状況**: コール・ミーティング・メールの頻度と最終接触日
- **キーパーソン**: 接触している役職・関与度・意思決定への近さ
- **金額・クローズ予定日**: 案件金額・close_date
- **競合・懸念事項**: ノートで言及されている競合・顧客の懸念

#### 3-2P. リスク分析

以下の観点からリスクを評価する：

**意思決定リスク**
- 最終意思決定者にアプローチできているか
- 複数のステークホルダーのコンセンサスが取れているか

**競合リスク**
- 競合が有利な点・差別化できていない領域はあるか
- 「現状維持」「内製」が選ばれるリスクはあるか

**タイムラインリスク**
- close_date が現実的か
- 顧客の内部プロセス（稟議・予算）に間に合うか

**エンゲージメントリスク**
- 接触頻度が落ちていないか
- 顧客の温度感が低下している兆候はあるか

#### 3-3P. 受注確度の評価

以下の基準でS/A/B/Cのランクを付与する：

| ランク | 受注確度 | 主な基準 |
|--------|---------|---------|
| **S** | 90%以上 | 意思決定者のコミット済み、競合排除、クロージング段階 |
| **A** | 70〜89% | 提案評価中、前向きなシグナルあり、競合に優位 |
| **B** | 40〜69% | 検討中だが不確実要素あり、競合が拮抗、決裁者への接触不十分 |
| **C** | 40%未満 | 停滞気味、競合に劣勢、顧客の優先度低下、温度感が弱い |

**評価根拠**：CRMデータ・担当者コメントからの具体的な根拠を3〜5点挙げる。

#### 3-4P. アクションプラン

ランクと課題に応じた具体的なアクションを提案する：

**直近1〜2週間のアクション**（優先度高）
- 最も重要な1〜2つのアクション

**1ヶ月以内のアクション**
- フォローアップ・資料提供・関係者へのアプローチなど

**リスク対策**
- 各リスクに対応する具体的な手段

---

## ステップ4：Word文書の生成

`docx` スキルの SKILL.md の指示に従い、Word文書（.docx）を生成する。
SKILL.md のパス：`/sessions/relaxed-epic-hawking/mnt/.claude/skills/docx/SKILL.md`

`DEAL_STAGE` によってテンプレートを使い分ける。

### 【失注フロー】レポートテンプレート

# 失注分析レポート：[案件名 / 会社名]

作成日：[YYYY年MM月DD日]　担当：[オーナー名]

---

## 1. 案件概要

| 項目 | 内容 |
|------|------|
| 案件名 | ... |
| 会社名 | ... |
| 業種 | ... |
| 案件金額 | ¥X,XXX,XXX |
| 担当者 | ... |
| 失注日 | YYYY年MM月DD日 |
| 商談期間 | X ヶ月（初回コンタクト：YYYY/MM/DD） |
| CRM記録の失注理由 | ... |
| 担当者が感じた主要因 | [SALES_INPUT より] |
| 競合状況 | [SALES_INPUT より] |
| 失注時の顧客温度感 | [SALES_INPUT より] |

---

## 2. 営業担当者コメント（補足情報）

> ※ この情報は営業担当者へのヒアリングをもとにしており、主観的な見立てを含みます。

### 担当者の見立て（失注要因）
[SALES_INPUT の回答をそのまま記載]

### 競合状況
[SALES_INPUT の回答をそのまま記載]

### 顧客との関係性・温度感
[SALES_INPUT の回答をそのまま記載]

### その他コメント
[SALES_INPUT の自由記述をそのまま記載。「特になし」の場合は省略]

---

## 3. 商談経緯タイムライン

[時系列で主要アクティビティを箇条書き。情報ソースを [CRM記録] / [メール記録] / [担当者コメント] で明示]

---

## 4. キーパーソン・接触サマリー

| 氏名 | 役職 | 接触回数 | 主な懸念・発言 | 情報ソース |
|------|------|----------|--------------|----------|

---

## 5. 事実としての失注要因

### 5-1. 明示された理由 [CRM記録]
### 5-2. 活動データから読み取れる事実 [CRM記録 / メール記録]

---

## 6. 失注要因の仮説

### 仮説1：[タイトル]
**根拠**：... **推論**：...

### 仮説2：[タイトル]

---

## 7. 次回アプローチ提案

### 推奨アプローチ時期
### アプローチ内容
### 優先コンタクト先
### 関係維持のための施策

---

## 8. What-If Analysis

---

## 9. 補足・参考情報

**ファイル名**：`失注分析_[会社名]_[YYYYMMDD].docx`

---

### 【提案中フロー】レポートテンプレート

# 受注確度レポート：[案件名 / 会社名]

作成日：[YYYY年MM月DD日]　担当：[オーナー名]

---

## 1. 案件概要

| 項目 | 内容 |
|------|------|
| 案件名 | ... |
| 現在のステージ | ... |
| クローズ予定日 | ... |
| 担当者が感じる主な懸念 | [SALES_INPUT より] |

---

## 2. 受注確度評価

### 確度ランク：[S / A / B / C]（受注確度 XX%）
### 評価根拠（3〜5点）

---

## 3. 商談経緯タイムライン

---

## 4. キーパーソン・接触サマリー

| 氏名 | 役職 | 接触回数 | 最終接触日 | 意思決定への関与 |

---

## 5. リスク分析

### 5-1. 意思決定リスク
### 5-2. 競合リスク
### 5-3. タイムラインリスク
### 5-4. エンゲージメントリスク

---

## 6. 担当者コメント（補足情報）

---

## 7. アクションプラン

### 直近1〜2週間（最優先）
### 1ヶ月以内
### リスク対策

---

## 8. 補足・参考情報

**ファイル名**：`受注確度レポート_[会社名]_[YYYYMMDD].docx`

---

### docxファイル生成時の共通注意事項

- 保存先：`/sessions/relaxed-epic-hawking/mnt/outputs/`
- ページサイズ：A4（11906 x 16838 DXA）
- フォント：Meiryo または游ゴシック（なければArial）
- テーブルは `WidthType.DXA` で幅固定
- 完成後に `python scripts/office/validate.py` でバリデーション

## ステップ5：レポート完成後の案内

レポートを出力したら、ユーザーに以下を伝える：

1. ファイルへのリンク（`computer://` 形式）
2. 分析のポイント3点（要約）
3. 最も優先すべき次回アクション1つ

---

## データ不足時の対応

CRMに十分なデータがない場合は、レポートの該当箇所に「データなし（CRMへの記録なし）」と明記し、推論には使用しない。データが乏しい場合ほど「データ不足自体がリスク要因の一つである可能性」を仮説・リスクとして提示する。

---

## 参考：CRMのアクティビティオブジェクト一覧

| object type | 内容 |
|-------------|------|
| `notes` | ノート |
| `calls` | 電話記録 |
| `meetings` | ミーティング記録 |
| `emails` | メール記録（CRM経由） |
| `tasks` | タスク |