CLAUDE.mdで営業チームの暗黙知をコード化する -- Claude Code Agent Teamによるセールスエンジニアリング

CLAUDE.mdの設計思想をGTMに転用する

前回の記事で、Claude APIを使った営業パイプラインの自動化を実装した。リードスコアリング、企業リサーチ、メッセージ生成の3つのユースケースをTypeScriptで書き、HubSpotに接続するところまでを見せた。

あの実装は「Claude APIに毎回プロンプトでICP定義やスコアリング基準を渡す」方式だった。動くし、十分に実用的だ。しかし、営業組織のスケールに合わせてこのアプローチを拡張していくと、ある問題にぶつかる。

営業チームが持っている暗黙知は、コードやプロンプトの中に散在する。

ICP定義はscoringモジュールのハードコードに、反論対応パターンは営業マネージャーの頭の中に、業種別メッセージテンプレートはGoogleスプレッドシートに。情報が分散し、誰がいつ何を変えたか追えない。

この問題を解決するのが、Claude CodeのCLAUDE.mdというファイルフォーマットの設計思想を営業オペレーションに転用するアプローチだ。

CLAUDE.mdとは何か

Claude Codeを使ったことがあるエンジニアには馴染みのあるファイルだ。知らない方のために簡潔に説明する。

CLAUDE.mdは、Claude Code（AnthropicのCLIツール）がプロジェクトのコンテキストを理解するための設定ファイル。プロジェクトルートに配置すると、Claude Codeはこのファイルを最初に読み込み、プロジェクトの前提知識として利用する。

通常は以下のような内容を書く:

• プロジェクトのアーキテクチャ概要
• コーディング規約（TypeScriptのstrictモード、ESLint設定等）
• ディレクトリ構成と各モジュールの責務
• テスト方針（カバレッジ目標、テストフレームワーク）
• デプロイ手順

要するに、新しくプロジェクトに参加したエンジニアが最初に読むべき情報を構造化したドキュメントだ。Claude Codeというエージェントにプロジェクトの文脈を与え、一貫した判断と行動をさせるための仕組み。

そしてCLAUDE.mdはGitリポジトリの中に置かれるから、変更履歴が全て残る。誰がいつ何を変えたかがcommit logで追跡できる。

この設計思想をそのまま営業オペレーションに持ち込む。

営業チームの暗黙知をCLAUDE.mdに書く

営業組織が機能するために必要な知識を列挙すると、驚くほど多い。そしてその大半は、特定の個人の頭の中か、散在するドキュメントに閉じ込められている。

以下に、GTMエンジニアリング用のCLAUDE.mdに記述すべき内容を具体的なマークダウンで示す。

ICP（理想的顧客プロファイル）の定義

markdown
## ICP定義

### ティア1（最優先ターゲット）
- 従業員数: 100-500名
- 業種: SaaS, FinTech, ヘルスケアIT
- 技術スタック: AWS or GCP利用中、React/Next.js採用
- シグナル: 直近12ヶ月以内にシリーズB以上の資金調達
- 年間IT予算: 1億円以上（推定）
- 営業チーム規模: 10名以上

### ティア2（標準ターゲット）
- 従業員数: 50-100名
- 業種: EC/小売（D2C）、製造業（DX推進中）、メディア/広告
- 技術スタック: クラウド利用中（種類不問）
- シグナル: DX推進の発表、基幹システム刷新の報道
- 営業チーム規模: 5名以上

### 除外条件
- 従業員10名未満のスタートアップ（予算不足の可能性が高い）
- 公共機関・行政（調達プロセスが12ヶ月以上かかる）
- 競合プロダクトの開発企業
- 過去にトライアル後に解約した企業（解約理由が機能不足の場合を除く）

リードスコアリング基準

markdown
## リードスコアリング基準（100点満点）

### 企業属性スコア（40点満点）
| 要素 | 配点 | 基準 |
|------|------|------|
| 業種適合 | 15点 | ティア1: 15点、ティア2: 10点、その他: 3点 |
| 従業員規模 | 10点 | 100-500名: 10点、50-100名: 7点、500-2000名: 5点 |
| 技術スタック | 10点 | AWS+React: 10点、GCP: 8点、Azure: 5点、不明: 2点 |
| 資金調達 | 5点 | シリーズB以上: 5点、シリーズA: 3点、不明: 1点 |

### 行動シグナルスコア（35点満点）
| 要素 | 配点 | 基準 |
|------|------|------|
| ウェブサイト訪問 | 10点 | 料金ページ訪問: 10点、機能ページ: 5点、ブログのみ: 2点 |
| コンテンツDL | 10点 | ホワイトペーパーDL: 10点、事例集DL: 8点、ウェビナー参加: 5点 |
| 問い合わせ | 15点 | デモリクエスト: 15点、資料請求: 10点、一般問い合わせ: 5点 |

### 担当者スコア（25点満点）
| 要素 | 配点 | 基準 |
|------|------|------|
| 役職レベル | 15点 | CxO/VP: 15点、部長: 12点、マネージャー: 8点、担当者: 4点 |
| 部門 | 10点 | 営業/CS: 10点、マーケ: 8点、経営企画: 7点、情シス: 5点 |

### スコア別アクション
- 80-100点: immediate_outreach（24時間以内にAEがコンタクト）
- 60-79点: fast_track（3営業日以内にSDRがメール+電話）
- 40-59点: nurture_sequence（メールシーケンスで温める）
- 0-39点: low_priority（月次レビューで再評価）

商談ステージごとの判断基準

markdown
## 商談ステージ定義と判断基準

### Stage 1: 初回接触（Discovery）
- 目的: ニーズの有無を確認する
- 判断基準:
  - BANT確認: Budget（予算の存在）、Authority（決裁権）、Need（課題の具体性）、Timeline（導入時期）
  - 次のステージへ進む条件: BANTの3項目以上が確認できた
  - 失注判定: 「課題はあるが今期は予算がない」→ 6ヶ月後にリナーチャリング

### Stage 2: 課題深掘り（Qualification）
- 目的: 顧客の課題を具体化し、自社プロダクトとのフィットを確認する
- 判断基準:
  - 顧客が「現状の問題を具体的な数字で語れる」状態になっているか
  - 例: 「営業のリサーチに1日3時間かかっている」「リードの30%しかフォローできていない」
  - 次のステージへ進む条件: 課題が定量化され、自社プロダクトで解決可能と判断
  - Pivot判定: 課題が自社プロダクトの対応範囲外 → パートナー企業に紹介

### Stage 3: デモ/PoC（Evaluation）
- 目的: 自社プロダクトが課題を解決できることを実証する
- 判断基準:
  - デモ後のフィードバックが具体的か（「良さそうですね」は危険。「この機能でXXが解決できそう」は好材料）
  - PoC期間中の利用頻度（週3回以上のログインが目安）
  - 技術的なブロッカーがないか

### Stage 4: 提案/稟議（Proposal）
- 目的: 稟議を通すための支援
- 判断基準:
  - 稟議書のドラフトを営業側で用意できているか
  - 決裁者との直接対話が実現しているか
  - 競合との比較検討で自社が優位か

### Stage 5: 交渉/契約（Negotiation）
- 目的: 契約条件の合意
- 判断基準:
  - 値引き要請への対応基準（上限15%。それ以上はVP承認必須）
  - 契約期間: 年間契約推奨。月額の場合は月額料金を10%上乗せ

業種別・役職別メッセージテンプレート

markdown
## メッセージテンプレート

### 業種別アングル

#### SaaS企業向け
- 主要ペイン: 営業の属人化、パイプライン可視化の不足
- 刺さるキーワード: 「営業効率」「パイプライン速度」「ARR成長」
- 導入事例言及: A社（SaaS、従業員200名）の事例

#### FinTech企業向け
- 主要ペイン: コンプライアンス対応で営業リソースが圧迫される
- 刺さるキーワード: 「コンプライアンス」「セキュリティ」「規制対応の効率化」
- 導入事例言及: B社（FinTech、従業員150名）の事例

#### 製造業（DX推進中）向け
- 主要ペイン: レガシーシステムとの連携、現場の抵抗
- 刺さるキーワード: 「DX」「基幹システム連携」「現場定着」
- 導入事例言及: C社（製造業、従業員800名）の事例

### 役職別トーン

#### CxO/VP向け
- トーン: consultative（コンサルティング型）
- 構成: 業界トレンド → 経営インパクト → 15分の意見交換提案
- NG: 機能の羅列、価格の言及

#### 部長/マネージャー向け
- トーン: practical（実務型）
- 構成: 現場の課題共感 → 具体的な解決方法 → デモ提案
- NG: 抽象的な表現、「DX」の多用

#### 担当者向け
- トーン: casual（カジュアル型）
- 構成: 業務効率化の具体例 → 無料トライアル案内
- NG: 上から目線、稟議・予算の話

競合比較と反論対応

markdown
## 競合比較

### vs CompetitorA
- 強み: UI/UXの洗練度、モバイル対応
- 弱み: 日本語対応が不十分、kintone連携なし、サポートが英語のみ
- 価格: $49/user/月（当社比 約1.5倍）
- 勝ちパターン: 「日本企業の商習慣への対応」「kintone/freee等の国産ツール連携」で差別化

### vs CompetitorB
- 強み: 大企業への導入実績、Salesforce連携の深さ
- 弱み: 導入に3-6ヶ月かかる、カスタマイズ費用が高額
- 価格: 個別見積（年間500万円〜）
- 勝ちパターン: 「2週間で立ち上がる」「月額課金でリスクなく始められる」

## 反論対応（Objection Handling）

### 「今のツールで間に合っている」
→ 質問で返す: 「営業チームのリサーチ時間は月に何時間ぐらいですか?」
→ 回答が2時間以上/日なら: 「その時間を商談に充てられたら、月にあと何件の商談ができそうですか?」

### 「予算が確保できていない」
→ 「来期の予算策定はいつですか? その前にPoCで効果を実証できれば、予算申請の材料になります」
→ ROI試算ツールの案内

### 「セキュリティが心配」
→ SOC2 Type II取得済み、データは国内リージョン保存
→ 情シス向けのセキュリティホワイトペーパーを送付

### 「他社も検討中」
→ 「どの点を比較されていますか?」で具体的な評価軸を聞き出す
→ 比較表（自社有利に作成済み）を提供
→ 相手が言及した競合に応じて、上記の競合比較セクションの勝ちパターンを適用

ここまでが、営業チームの暗黙知をCLAUDE.mdのフォーマットで構造化した例だ。全体で1つのマークダウンファイルになる。

重要な点は、これがただのドキュメントではないということ。Claude Code Agent Teamがこのファイルを読み込み、スコアリングやメッセージ生成の判断基準として自律的に参照する。ドキュメントが実行可能なルールになる。

Agent Teamによる営業オペレーション自動化

CLAUDE.mdに営業知識を記述しただけでは、前回の記事でプロンプトにICP定義をハードコードしたのと変わらない。ここからが本題だ。Claude Code Agent Teamを使って、CLAUDE.mdの知識を読み込んだ複数のエージェントが協調動作する仕組みを構築する。

Agent Teamの基本概念

Claude Code Agent Teamは、複数のサブエージェントをチームとして編成し、タスクを分担・並列実行する仕組みだ。各エージェントは独立したコンテキストを持ち、ファイルシステム経由でデータを受け渡す。

営業パイプラインの日次処理をAgent Teamで設計すると、以下の構成になる。

team_name: "sales-pipeline-daily"
members:
  - lead-scorer (haiku): 新規リードのスコアリング
  - researcher (sonnet): 高スコアリードの企業リサーチ
  - message-writer (haiku): パーソナライズドメッセージ生成
  - crm-updater (haiku): CRMデータ更新とSlack通知

各エージェントの役割を説明する。

lead-scorer: CLAUDE.mdのICP定義とスコアリング基準を参照し、新規リードに0-100のスコアを付ける。Haikuモデルを使う。スコアリングは判断基準が明確に定義されているため、高速・低コストなモデルで十分な精度が出る。

researcher: スコア60点以上のリードに対して、企業のWebサイト、IR資料、プレスリリース、採用ページを調査する。Sonnetモデルを使う。長文の分析と課題仮説の生成には推論能力の高いモデルが必要。

message-writer: CLAUDE.mdの業種別・役職別テンプレートと、researcherの出力を組み合わせて、パーソナライズドメッセージを生成する。反論対応パターンも参照し、想定される反論への準備情報もメッセージに添える。

crm-updater: スコアリング結果、リサーチレポート、メッセージ下書きをCRM（HubSpot）に書き込む。完了後、Slackの営業チャンネルに通知を送る。

CLAUDE.mdからICP定義をスコアリングに反映する仕組み

CLAUDE.mdの内容は、Agent Team起動時に各エージェントのコンテキストとして自動的に読み込まれる。これがCLAUDE.mdの設計思想の核心だ。

開発プロジェクトでは、CLAUDE.mdにコーディング規約を書けば、Claude Codeはその規約に従ったコードを生成する。同じ仕組みで、CLAUDE.mdにICP定義を書けば、lead-scorerエージェントはその基準に従ったスコアリングを実行する。

プロンプトに毎回ICP定義を埋め込む必要がない。CLAUDE.mdに一度書けば、チーム内の全エージェントがその知識を共有する。

Agent間のファイルベースデータ受け渡し

Agent Teamの各エージェントは独立したコンテキストで動作する。エージェント間のデータ受け渡しはファイルシステム経由で行う。

.claude-work/sales-pipeline-daily/
├── step-1-scoring/
│   ├── lead-001.json      # スコアリング結果
│   ├── lead-002.json
│   └── summary.json        # 高スコアリードの一覧
├── step-2-research/
│   ├── company-a.json      # 企業リサーチ結果
│   └── company-b.json
├── step-3-messages/
│   ├── lead-001-messages.json   # メッセージバリエーション
│   └── lead-002-messages.json
└── step-4-crm-update/
    └── update-log.json      # CRM更新ログ

この構造には2つの利点がある。

第一に、各ステップの成果物が明示的に残る。lead-scorerが出力したスコアリング結果のJSONを、researcherが読み込んで調査対象を決定する。中間データがファイルとして可視化されるから、パイプラインのどこで問題が起きたか特定しやすい。

第二に、リトライが容易になる。researcherがAPI制限で失敗しても、step-1-scoringの結果はそのまま残っている。失敗したステップだけ再実行すればいい。

Skillsとの組み合わせ

Claude Codeには、CLAUDE.mdとは別にSkillsという仕組みがある。CLAUDE.mdとSkillsの役割分離を理解することが、営業オペレーション自動化の設計で重要になる。

CLAUDE.md vs Skills の役割分離

CLAUDE.mdに手順を書かない。Skillsに前提知識を書かない。この分離を守ることで、知識の更新と手順の改善を独立して行える。

営業オペレーション向けSkills

以下のSkillsを定義する。

/lead-score: リードスコアリング実行

markdown
# lead-score Skill

## 手順
1. `.claude-work/inbox/` から未処理のリードデータ（JSON）を取得
2. CLAUDE.mdの「ICP定義」と「リードスコアリング基準」を参照
3. 各リードに対して:
   a. 企業属性スコア（40点満点）を算出
   b. 行動シグナルスコア（35点満点）を算出
   c. 担当者スコア（25点満点）を算出
   d. 合計スコアと推奨アクションを決定
4. 結果を `.claude-work/sales-pipeline-daily/step-1-scoring/` に出力
5. スコア60点以上のリードを `summary.json` にまとめる

/research-company {company}: 企業リサーチ

markdown
# research-company Skill

## 手順
1. 対象企業のドメインからWebページを収集:
   - コーポレートサイト（/about, /company）
   - IR/投資家向けページ（/ir, /investor）
   - 採用ページ（/careers, /recruit）
   - ニュース/プレスリリース（/news, /press）
2. 各ページの内容をClaude APIで構造化:
   - 企業概要（3文以内）
   - 直近の経営戦略
   - 財務ハイライト
3. CLAUDE.mdの「競合比較」を参照し、ターゲット企業が競合プロダクトを使用している兆候を検出
4. 課題仮説を3つ生成（evidence + confidence付き）
5. 結果を `.claude-work/sales-pipeline-daily/step-2-research/` に出力

/generate-outreach {lead}: アウトリーチメッセージ生成

markdown
# generate-outreach Skill

## 手順
1. step-1-scoringのスコアリング結果を読み込む
2. step-2-researchのリサーチ結果を読み込む
3. CLAUDE.mdの「メッセージテンプレート」から:
   a. 対象企業の業種に合ったアングルを選択
   b. 担当者の役職に合ったトーンを選択
4. 3つのバリエーションを生成:
   - バリエーションA: 課題仮説1にフォーカス
   - バリエーションB: 課題仮説2にフォーカス
   - バリエーションC: 導入事例にフォーカス
5. CLAUDE.mdの「反論対応」から、想定される反論と対応策を添付
6. 結果を `.claude-work/sales-pipeline-daily/step-3-messages/` に出力

/pipeline-report: パイプラインレポート

markdown
# pipeline-report Skill

## 手順
1. CRM（HubSpot API）から現在のパイプラインデータを取得
2. CLAUDE.mdの「商談ステージ定義と判断基準」を参照
3. 各ステージの:
   a. 商談数と金額
   b. 平均滞留日数
   c. ステージ判断基準に照らした警告（滞留が長い商談、BANTが不足している商談）
4. Slack通知:
   - #sales チャンネルにサマリーを投稿
   - 個別のAEにDMで担当商談の警告を送信

暗黙知のバージョン管理

ここまでの設計で、営業チームの暗黙知がCLAUDE.mdという1つのファイルに集約された。このファイルはGitリポジトリに置かれる。

Gitで管理されるということは、以下が自動的に実現する。

変更履歴の完全な記録

commit a1b2c3d
Author: sales-manager
Date: 2026-04-15

refactor: ICPのティア1に「ヘルスケアIT」を追加

直近3ヶ月の受注データを分析した結果、ヘルスケアIT業界の
受注率が他業種の1.8倍であることが判明。ティア1に昇格。

commit d4e5f6g
Author: ae-tanaka
Date: 2026-04-10

fix: CompetitorA比較の弱みに「API連携の制限」を追記

先週のC社商談で、CompetitorAからの乗り換え検討中と判明。
CompetitorAのAPI連携が10エンドポイントまでの制限があり、
C社の要件（30エンドポイント以上）を満たせないことが決め手に。
この情報を競合比較セクションに追加。

従来の営業ツール（SFA）では、こうした知識の変更理由は残らない。設定画面でパラメータを変えるだけだから、「なぜ変えたか」の文脈が消える。CLAUDE.mdをGit管理することで、営業知識の進化がcommit messageとして蓄積される。

PRレビューによる知識の品質管理

営業マネージャーがICP定義やスコアリング基準を変更する際、Pull Requestを出してレビューを受けるワークフローが成立する。

PR #42: ICPスコアリング基準の調整 -- 行動シグナルの重み付け変更

## 変更内容
- ウェブサイト訪問のスコアを10点→15点に引き上げ
- コンテンツDLのスコアを10点→8点に引き下げ
- 企業属性スコアの配点を40点→37点に調整

## 変更理由
直近30件の受注分析で、ウェブサイト訪問（特に料金ページ）が
受注との相関が最も高いことが判明（r=0.72）。
一方、コンテンツDLだけで商談化につながるケースは減少傾向。

## 影響範囲
- lead-scorerエージェントのスコアリング結果に影響
- 既存リードの再スコアリングが必要（/lead-score --rerun で実行可能）

エンジニアがコードレビューをするように、営業チームが営業知識のレビューをする。「なぜこの基準を変えるのか」「エビデンスはあるか」「既存パイプラインへの影響は」を議論した上でマージする。

これは「営業の知見を個人の経験から組織の資産にする」プロセスそのものだ。

実装例: 日次営業パイプラインの自動処理

ここまでの概念を、実際に動く実装として組み立てる。

ステップ1: CLAUDE.md定義

上で示したICP定義、スコアリング基準、メッセージテンプレート、競合比較、反論対応パターンを1つのCLAUDE.mdにまとめる。ファイルの冒頭に以下を追加する。

markdown
# GTM Engineering CLAUDE.md

## 概要
このファイルは営業オペレーション自動化のための知識ベースです。
Agent Teamの各エージェントはこのファイルを前提知識として参照します。

## 更新ルール
- ICP定義の変更: 営業マネージャーのPR承認が必須
- スコアリング基準の変更: 直近30件以上の受注/失注データによるエビデンスが必要
- 競合情報の更新: ソース（商談議事録、顧客フィードバック）を明記すること
- メッセージテンプレートの変更: A/Bテスト結果に基づくこと

ステップ2: Agent Teamの構成

typescript
// sales-pipeline.ts
// Agent Team構成の概念コード

interface AgentTeamConfig {
  teamName: string
  members: AgentConfig[]
  claudeMdPath: string
}

interface AgentConfig {
  name: string
  model: 'haiku' | 'sonnet' | 'opus'
  skill: string
  dependsOn: string[]
}

const salesPipelineTeam: AgentTeamConfig = {
  teamName: 'sales-pipeline-daily',
  claudeMdPath: './CLAUDE.md',
  members: [
    {
      name: 'lead-scorer',
      model: 'haiku',
      skill: '/lead-score',
      dependsOn: [],
    },
    {
      name: 'researcher',
      model: 'sonnet',
      skill: '/research-company',
      dependsOn: ['lead-scorer'],
    },
    {
      name: 'message-writer',
      model: 'haiku',
      skill: '/generate-outreach',
      dependsOn: ['researcher'],
    },
    {
      name: 'crm-updater',
      model: 'haiku',
      skill: '/pipeline-update',
      dependsOn: ['message-writer'],
    },
  ],
}

ステップ3: 各エージェントの処理フロー

[Daily 08:00 JST - Trigger]
  │
  ├── [lead-scorer (Haiku)] ← CLAUDE.md: ICP定義、スコアリング基準
  │     入力: CRM Webhookで受信した新規リード (JSON)
  │     処理: ICP照合 → 企業属性40点 + 行動シグナル35点 + 担当者25点
  │     出力: .claude-work/sales-pipeline-daily/step-1-scoring/
  │
  ├── [researcher (Sonnet)] ← CLAUDE.md: 競合情報、業種知識
  │     入力: step-1-scoring/summary.json (スコア60+のリード)
  │     処理: Webスクレイピング → Claude APIで構造化 → 課題仮説生成
  │     出力: .claude-work/sales-pipeline-daily/step-2-research/
  │
  ├── [message-writer (Haiku)] ← CLAUDE.md: テンプレート、反論対応
  │     入力: step-2-research/*.json
  │     処理: 業種×役職でテンプレート選択 → 3バリエーション生成
  │     出力: .claude-work/sales-pipeline-daily/step-3-messages/
  │
  └── [crm-updater (Haiku)]
        入力: step-1〜3の全出力
        処理: HubSpot APIでコンタクト/Deal更新 → Slack通知
        出力: .claude-work/sales-pipeline-daily/step-4-crm-update/

ステップ4: 成果物

日次パイプライン処理の完了後、以下の成果物が生成される。

1. スコアリング結果: 全新規リードのスコア一覧。CRMのカスタムフィールドに書き込み済み
2. 企業リサーチレポート: 高スコアリードの企業分析。課題仮説3つ付き。CRMのノートに登録
3. メッセージ下書き: 3バリエーション。AEがSlackで確認し、微調整して送信
4. Slack通知: #sales-pipeline チャンネルに日次サマリー

[sales-pipeline-daily] 日次処理完了

処理リード数: 47件
  - 80点以上 (immediate_outreach): 3件
  - 60-79点 (fast_track): 8件
  - 40-59点 (nurture): 22件
  - 39点以下 (low_priority): 14件

企業リサーチ完了: 11件（60点以上）
メッセージ生成完了: 11件（3バリエーション × 11 = 33通）
CRM更新完了: 47件

[immediate_outreach リード]
1. 株式会社X (SaaS, 350名) - スコア: 92点
   担当: 田中太郎（CTO）
   課題仮説: 営業チーム拡大に伴うパイプライン管理の複雑化
   → メッセージ下書き確認: /review-message lead-001

2. 株式会社Y (FinTech, 180名) - スコア: 85点
   ...

ステップ5: CRM更新とSlack通知のコード

typescript
// src/pipeline/crm-updater.ts
import type { ScoringResult } from '../scoring/lead-scorer'
import type { ResearchResult } from '../research/types'
import type { MessageSet } from '../messaging/types'

interface PipelineOutput {
  leadId: string
  scoring: ScoringResult
  research: ResearchResult | null
  messages: MessageSet | null
}

async function updateCRM(outputs: PipelineOutput[]): Promise<void> {
  const hubspotConfig = {
    apiKey: process.env.HUBSPOT_API_KEY ?? '',
    baseUrl: 'https://api.hubapi.com',
  }

  for (const output of outputs) {
    // コンタクトのカスタムフィールドを更新
    await updateContactProperties(hubspotConfig, output.leadId, {
      ai_lead_score: String(output.scoring.score),
      ai_suggested_action: output.scoring.suggestedAction,
      ai_scoring_reasoning: output.scoring.reasoning,
      ai_score_breakdown: JSON.stringify(output.scoring.breakdown),
      ai_last_scored_at: new Date().toISOString(),
    })

    // リサーチ結果があればノートとして追加
    if (output.research) {
      await createNote(hubspotConfig, output.leadId, {
        title: `AI企業リサーチ: ${output.research.company}`,
        body: formatResearchAsNote(output.research),
      })
    }

    // メッセージがあればタスクとして登録
    if (output.messages) {
      await createTask(hubspotConfig, output.leadId, {
        title: `アウトリーチ送信: ${output.messages.companyName}`,
        body: formatMessagesAsTask(output.messages),
        dueDate: calculateDueDate(output.scoring.suggestedAction),
      })
    }
  }
}

function formatResearchAsNote(research: ResearchResult): string {
  const hypotheses = research.painHypotheses
    .map((h) => `- [${h.confidence}] ${h.hypothesis}\n  根拠: ${h.evidence}`)
    .join('\n')

  return `## 概要\n${research.summary.overview}\n\n` +
    `## 経営戦略\n${research.summary.recentStrategy}\n\n` +
    `## 課題仮説\n${hypotheses}\n\n` +
    `## 商談トーキングポイント\n${research.talkingPoints.map((t) => `- ${t}`).join('\n')}\n\n` +
    `## リスク\n${research.risks.map((r) => `- ${r}`).join('\n')}`
}

function formatMessagesAsTask(messages: MessageSet): string {
  return messages.variants
    .map((v) => `### バリエーション ${v.variantId} (${v.tone})\n` +
      `件名: ${v.subject}\n\n${v.body}\n\nCTA: ${v.cta}\n` +
      `アングル: ${v.focusAngle}`)
    .join('\n\n---\n\n')
}

function calculateDueDate(action: string): string {
  const now = new Date()
  const daysToAdd = action === 'immediate_outreach' ? 1 : 3
  now.setDate(now.getDate() + daysToAdd)
  return now.toISOString().split('T')[0]
}

従来の営業ツールとの比較

ここまで読んで「それ、SFAツールでできるのでは」と思ったかもしれない。比較する。

もちろんトレードオフはある。CLAUDE.md + Agent Teamの運用には、GTMエンジニアがいなければ成り立たない。SFAツールは営業チームだけで運用できるが、こちらにはエンジニアリングリソースが必要だ。

ただし、前回の記事で試算した通り、月$18程度で1,000リードの自動処理が回る。SFAツールで営業10人分のライセンスを払うのと、GTMエンジニア1人（兼務可能）+ API費用を比較すると、後者のほうがコスト効率が高い場面は確実にある。

もう1つ重要な違いは知識の移植性だ。SFAツールに蓄積した設定やワークフローは、ツールを乗り換えるとゼロからやり直しになる。CLAUDE.mdに書いた営業知識は、マークダウンファイルとしてどこにでも持っていける。ツールロックインがない。

CLAUDE.mdのメンテナンスサイクル

営業知識は静的ではない。ICP定義は四半期ごとに見直した方がいいし、競合情報は毎月更新が必要だ。CLAUDE.mdを生きたドキュメントにするためのメンテナンスサイクルを定義する。

週次: 反論対応パターンの追加

毎週の営業ミーティングで出てきた新しい反論を、CLAUDE.mdに追記する。AEが「こう聞かれて困った」という事例を、対応パターンとしてコード化する。

commit weekly-objection-update
Author: ae-suzuki

feat: 「データ移行コストが心配」の反論対応パターンを追加

今週のD社商談で「既存システムからのデータ移行にいくらかかるのか」
という反論が出た。移行ツール無料提供 + CSチームの伴走支援で対応。
同様の反論が3件/月のペースで増えているため定型パターン化。

月次: 競合情報の更新

競合プロダクトのリリースノート、プレスリリース、顧客の声を収集し、競合比較セクションを更新する。

四半期: ICP・スコアリング基準の見直し

過去四半期の受注/失注データを分析し、ICP定義とスコアリング基準を調整する。「この業種のリードが増えているが受注率が低い → ICPから除外」「この行動シグナルが受注と強く相関する → スコアの重みを上げる」といった判断をデータに基づいて行い、PRとしてレビューに出す。

Agent Teamフィードバックループ

Agent Teamの出力品質も継続的に改善する。

[月次レビュー]
  ├── メッセージ生成: 開封率・返信率のA/Bテスト結果を分析
  │     → 高パフォーマンスバリエーションの特徴をテンプレートに反映
  ├── スコアリング: スコアと実際の商談化率の相関を検証
  │     → スコアリング基準の重み付けを調整
  └── リサーチ: AEフィードバック「このリサーチは役立った/外れていた」
        → リサーチプロンプトの精度改善

このフィードバックループ全体がGitのcommit historyとして記録される。営業組織の学習プロセスがバージョン管理される。これは従来の営業ツールでは実現できなかった。

この手法が効く組織の条件

CLAUDE.md + Agent Teamによる営業自動化は万能ではない。効果を発揮する組織の条件を明示しておく。

効く条件:

• 営業チーム5-30名規模。属人的な営業から組織的な営業への転換期
• GTMエンジニア（またはエンジニアリング意欲のある営業）が最低1名いる
• CRMを導入済み（HubSpot無料プランでも可）
• 月間リード数が100件以上（自動化の投資対効果が出るボリューム）

効かない条件:

• 営業チーム3名以下（暗黙知のコード化コストが手動運用を上回る）
• 完全紹介ベースの営業モデル（リードスコアリングの対象がない）
• エンジニアリングリソースがゼロ（CLAUDE.mdの保守ができない）

---

CLAUDE.mdというファイルは、もともと開発プロジェクト向けの設計だ。ただ、「エージェントに与えるコンテキストを明示的に管理する仕組み」という考え方は、営業の暗黙知管理にもそのまま使える。カスタマーサクセスのプレイブック管理にも使えると思う。

自分でこれを実際に回してみた印象では、一番効いたのはGitのcommit historyに「なぜ変えたか」が残るようになったことだった。ICPの変更理由が検索できるというのは、SFAツールにはない体験だ。

次回はGTMエンジニアが商談同席から得るインサイトとして、Agent Teamが処理した商談データを人間の営業がどう活用するか、AIと人間の協調モデルの実践を解説する。

---

参考資料

• Claude Code Documentation - CLAUDE.md
• The 2026 State of GTM Engineering
• Anthropic Claude API Documentation
• HubSpot CRM API Reference
• Vercel AI Sales Agent - Tomasz Tunguz
• Git Workflows for Non-Engineering Teams