Claude CodeにSkillとサブエージェントで営業を回してもらう

最近SNSでサブエージェントやSkillの活用事例をよく見かけます（まあ、驚き屋さんの記事も多いですが）。
そのせいもあるのか、「うちの会社でもああいうのやりたいんだけど」と聞かれることが増えました。聞いてくるのはたいてい非エンジニアの方や、町工場の社長さんです。やはり自動化で現状の課題を解決したいという思いがあるのでしょう。

そこで、実際に受けた案件を最初から最後まで動かしてサンプルを作ってみることにしました。

以前「Claude Codeを開発チームとして運用する」という記事を書きました。今回は同じ考え方を営業部門に適用してみました。

見積もり作成、提案書レビュー、新規問い合わせへの一次回答。この3つの定型業務をSkillとサブエージェントに切り出し、実際にfreeeへの見積書発行まで動く環境を作った過程をまとめます。使っているCLAUDE.md・SKILL.md・エージェント定義は実物ベース（数値は一般化）のものをサンプルとして掲載しました。

コードは数十行のMarkdownファイル4つと、見積もりExcelを作るPythonスクリプト1本（本論ではないので省いています）です。難しかったのはコードではなく、「AIエージェントに何を判断させ、何を人間に戻すか」の設計でした。

全体構成

ディレクトリはこうなっています。

.
├── CLAUDE.md
├── leads/
│   └── <案件名>/
│       ├── form_customer.txt          # 問い合わせ原文
│       ├── quote.json                 # 見積もり生成用の構造化データ
│       ├── 見積書_YYYYMMDD.xlsx        # 自己検証済みの見積書Excel
│       ├── 別紙_作業内容明細.md          # 見積書に対応する詳細説明
│       └── 一次回答案.md               # lead-triageの出力
└── .claude/
    ├── agents/
    │   ├── lead-triage.md             # 新規問い合わせへの一次回答担当
    │   └── proposal-reviewer.md       # 提出前の提案書チェック担当
    ├── commands/
    │   └── lead-sweep.md              # leads/巡回コマンド（/loopで定期実行する）
    ├── sales-knowledge/
    │   ├── faq.md                     # よくある質問
    │   └── products.md                # 商品・サービス資料
    ├── competitor-notes/
    │   └── <競合名>.md                 # 競合の価格・提案内容メモ
    └── skills/
        └── quote-organizer/
            ├── SKILL.md
            ├── generate_quote.py
            └── templates/quote.sample.json

構成物は4つです。

構成物	種類	役割
quote-organizer	Skill	見積書の作成〜freee発行〜別紙作成の一連フロー
lead-triage	サブエージェント	新規問い合わせへの一次回答案作成
proposal-reviewer	サブエージェント	提出前の提案書レビュー
lead-sweep	Slash Command	leads/配下の定期巡回（/loopと組み合わせて使う）

設計方針は2つだけです。

1. 判断の根拠（ナレッジ）と実行担当（エージェント）を分離する。ナレッジは sales-knowledge/ competitor-notes/ にMarkdownで置き、エージェントはそこに書かれていることだけを根拠に動く。
2. 1案件＝1フォルダで完結させる。問い合わせ原文から見積書、別紙まで、案件に関するファイルはすべて leads/<案件名>/ に集約する。

CLAUDE.md — プロジェクト全体のルール

リポジトリ直下のCLAUDE.mdには、ディレクトリ構成の意味と、ファイルを置く場所のルールだけを書いています。

# 営業・見積対応プロジェクト

営業・見積対応まわりの管理リポジトリ。

## ディレクトリ構造

### `leads/<案件名>/`

問い合わせ案件ごとに案件名でディレクトリを作り、以下のファイルを格納する。

- `form_customer.txt` — 顧客からの問い合わせ原文
- `一次回答案.md` — 社内確認結果・顧客への返信案・送信前の確認事項・確信度をまとめたファイル
- `quote.json` — 見積り生成用の構造化データ（`quote-organizer` skillの入力）
- `見積書_YYYYMMDD.xlsx` — `quote-organizer` skillで発行した正式見積書
- `別紙_作業内容明細.md` — 見積書に対応する作業内容の詳細説明（顧客提示用）

一次回答案は、ヒアリング前後で内容が変わる。ヒアリング未了時点では金額・検証範囲を
「現物確認後に確定」とし、ヒアリング済み・金額確定後は見積書・別紙の内容と整合させる
（現物確認前の文言を残したまま見積書だけ発行すると、案内内容が矛盾するので注意）。

### `.claude/agents/`

- `lead-triage.md` — 新規リードへの一次回答案を作る担当。ナレッジベースだけを根拠に回答し、確信度を自己申告する
- `proposal-reviewer.md` — 提出前の提案書（一次回答案・別紙・見積書）をチェックする担当。競合比較の抜け漏れと数値整合性を作成者とは別視点で確認する

### `.claude/commands/`

- `lead-sweep.md` — `leads/`配下を定期巡回し、送信待ち・確信度が低い案件を検知して`lead-triage`に再評価させるコマンド。`/loop`と組み合わせて使う

### `.claude/competitor-notes/`

競合他社の価格・提案内容のメモ。分野ごとに揃っているとは限らないので、
該当分野のノートが無い場合はその旨を明記する。

### `.claude/sales-knowledge/`

`lead-triage`が一次回答を作る際に参照するFAQ・商品情報。

### `.claude/skills/quote-organizer/`

見積書発行フロー一式（Excel自己検証 → freee発行 → 別紙作成）。詳細は同ディレクトリの`SKILL.md`参照。

開発チームのCLAUDE.mdと違い、コーディング規約やアーキテクチャの説明は一切ありません。「どこに何を置くか」と「誰が何を担当するか」の索引だけです。営業ドメインではコードではなくファイルの置き場所こそが規約になります。

ナレッジ層: sales-knowledge と competitor-notes

エージェント定義に入る前に、その判断根拠になっているナレッジ層を見ておきます。lead-triageとproposal-reviewerは、この2つのディレクトリに書かれていること以外を根拠にしないという制約で動いています。

sales-knowledge/faq.mdは、よくある質問への回答をQ&A形式で並べたものです。

# よくある質問（一次回答の根拠ナレッジ）

## 料金について

**Q. 見積りは無料ですか？**
A. はい、初回のお見積りは無料です。ヒアリング後、3営業日以内にお見積書をお送りします。

**Q. 支払条件は？**
A. 標準は月末締め翌月末払いです。案件規模により分割払いのご相談も可能です。

## サービスについて

**Q. 納品後の修正は対応してもらえますか？**
A. 納品後2週間は無償修正に対応しています。それ以降は別途お見積りとなります。

---
最終更新日: 2026-07-01
このファイルにない内容は、一次回答案で「要確認」として扱ってください（推測で回答しない）。

sales-knowledge/products.mdは、商品・サービスごとの内容と価格帯を並べたものです。価格が確定していない領域は、価格を書かずに「個別見積り」と明記し、lead-triageがどこまで自分で答えてよいかの境界線を引いています。

# 商品・サービス資料（一次回答の根拠ナレッジ）

## Webサイトリニューアル一式

- 内容：要件整理・デザイン・実装・公開
- 目安価格：〇〇万円〜（規模により変動）
- 標準納期：6週間

## 保守契約プラン

| プラン | 月額 | 内容 |
|---|---|---|
| ライト | 〇万円 | 軽微な修正・監視 |
| スタンダード | 〇万円 | 軽微な修正・監視・月次レポート |

## 基幹システム関連

現時点で標準商品化されたパッケージはなし。個別見積り対応のため、
問い合わせがあった場合は一次回答で確定金額を提示せず「要確認」として担当者への
エスカレーションを案内すること。

---
最終更新日: 2026-07-12

competitor-notes/は競合ごとにファイルを分け、価格帯・強み・弱み・自社の比較優位点をメモしたものです。proposal-reviewerが「提案書の競合比較に裏付けがあるか」を確認する際の唯一の根拠になります。

# 競合A社（比較用ノート）

## 価格帯

- Webサイトリニューアル一式：〇〇万円〜（当社の相場より安価）
- 保守契約：月額〇万円〜（当社の相場より高め）

## 強み

- 制作スピードが速い（納期は当社より1〜2週間短い傾向）

## 弱み

- 納品後の追加修正は別途見積り（当社は納品後2週間は無償修正）

## 当社の比較優位として提案書に書くべき点

- 納品後2週間の無償修正保証
- 保守契約の月額単価の安さ

最終更新日: 2026-06-01

CLAUDE.mdにも書いた通り、競合ノートは分野ごとに揃っているとは限りません。ノートがない分野の競合主張は、proposal-reviewerが「裏付けを確認できない」と指摘するだけで、正しい・誤りの判定はしない設計にしています（後述）。ナレッジが薄い領域で無理に判定させると、そこで推測が混ざり込みます。

サブエージェント1: lead-triage — 新規問い合わせへの一次回答

新規の問い合わせに対して、ナレッジベースだけを根拠に一次回答案を作る担当です。toolsを Read, Grep, Glob に絞り、ファイルの参照以外は何もできないようにしています。

---
name: lead-triage
description: 新規リード（問い合わせ）への一次回答案を作る担当。ナレッジベースだけを根拠に回答し、確信度を自己申告する。
tools: Read, Grep, Glob
---

あなたは新規リード対応の一次回答担当です。渡された問い合わせ内容を読み、`.claude/sales-knowledge/` 配下のFAQ・商品資料だけを根拠に一次回答案を作成してください。

## 手順

1. `.claude/sales-knowledge/` 配下のファイルを読み、問い合わせ内容に関連する情報を探す。
2. 一次回答案を作成する。
3. 回答の確信度を「高／中／低」で自己申告する。
4. 確信度が低い場合は「人間の確認が必要」と明記する。
5. 出力をファイルに保存する場合は `leads/<顧客名>/一次回答案.md` に保存する（フォルダがなければ作成する）。プロジェクトルート直下に直接保存しない。

## 重要な制約

- ナレッジにない内容は絶対に推測で回答しないこと。価格・納期など数値を含む項目は特に厳禁。
- ナレッジに情報がない質問は、確信度を「低」とし、担当者へのエスカレーションを案内する回答にする。

## 出力形式

\```
## 案件
（問い合わせの要約）

## 一次回答案
（顧客にそのまま送れる文面）

## 確信度: 高 / 中 / 低
（低い場合は理由と、確認が必要な点を明記）
\```

このキモは「重要な制約」の1文だけです。ナレッジにない内容は推測で埋めない。これがないと、LLMは学習知識から「たぶんこうだろう」という価格・納期を平気で回答します。営業の一次回答で一番怖いのがこれです。エージェントを調子のいい営業マンにしないための戒めのようなものです。

サブエージェント2: proposal-reviewer — 提案書レビュー

提案書を出す前に、作成者（メインの会話）とは別視点でチェックする担当です。競合ノートと照らして裏付けのない主張がないか、金額の整合性が取れているかを確認します。

---
name: proposal-reviewer
description: 提案書を提出する前に、競合比較の抜け漏れと数値の整合性を確認する担当。作成者本人とは別視点でチェックする。
tools: Read, Grep, Glob
---

あなたは提案書レビュー担当です。作成者（メインの会話）とは別の視点で、提案書をチェックしてください。提案書本文は書き直さないこと。

## 確認する観点

1. **競合比較の裏付け**：提案書内の競合比較・優位性の主張が、`.claude/competitor-notes/` 配下のノートで裏付けられているか。裏付けのない主張（推測や誇張）がないか確認する。
2. **金額の整合性**：品目ごとの金額と合計金額が一致しているか。
3. **抜け漏れ**：競合ノートに記載されている当社の比較優位ポイントのうち、提案書に書かれていないものがないか。

## 重要な制約

- `.claude/competitor-notes/` にない内容は、絶対に推測で補完しないこと。ノートに情報がない主張は「競合ノートで裏付けを確認できない」と指摘するだけにとどめ、正しい・誤りの判定はしない。
- 提案書の文章を書き換えない。指摘のみを返す。

## 出力形式

以下の形式で、指摘だけを箇条書きで返す。

\```
## 指摘事項
- [重大度: 高/中/低] 指摘内容

## 金額チェック
- 一致 / 不一致（不一致の場合は差分を明記）

## 確信度: 高 / 中 / 低
（低い場合は理由と、人間が確認すべき点を明記）
\```

確信度が低い場合は「人間の確認が必要」と明記すること。競合ノートに載っていない業界・競合の主張が含まれる提案書では、確信度を高にしないこと。

lead-triageと同じ構造ですが、狙いは少し違います。lead-triageは「知らないことを答えない」ためのガード、proposal-reviewerは「作成者が見落とした裏付け不足を、別視点から拾う」ためのガードです。同じ会話の中で提案書を書いた本人にレビューさせても、自分の書いた誇張には気づきにくい。サブエージェントとして別セッションで走らせることで、コンテキストを引き継がない第三者視点を作っています。

Skill: quote-organizer — 見積書作成〜freee発行〜別紙作成

3つの構成物のうち、唯一コードを伴うのがこれです。見積もりは「①ローカルExcelで自己検証 → ②freeeで正式発行 → ③別紙作成」の3段階固定で、段階を飛ばして直接freeeに発行することを禁止しています。

---
name: quote-organizer
description: 見積書を作るとき使う。顧客名・件名・品目（品名／単価／数量）・支払条件・見積有効期限を受け取り、①ローカルExcelで金額の自己検証をした上で、②freeeに正式な見積書を発行し、③受注内容の別紙（Markdown）を作成する、一連の標準フローを実行する。
---

見積書は次の3段階で作成する。①ローカル確認 → ②freee発行 → ③別紙作成。段階を飛ばして直接freeeに発行しないこと（金額の自己検証を経ないまま正式書類を作ることになる）。

## 入力

以下をユーザーから受け取る（不足があれば質問して補う）。

- 顧客名（正式社名）
- 件名
- 品目のリスト（品名・単価・数量）
- 支払条件
- 見積有効期限（日数、または明示された期限日）
- 発行日（省略時は本日の日付）
- 受注内容の詳細（別紙用。作業観点・納品物・進め方など。1行見積で済む単純な案件なら省略可）

## 出力先｜案件フォルダに集約する

案件関連ファイル（問い合わせ原文・一次回答案・quote.json・見積書Excel・別紙）は、プロジェクトルート直下に散らかさず `leads/<顧客名>/` にまとめる。フォルダがなければ作成する。

## 段階①｜ローカルExcelで金額を自己検証

1. 受け取った内容から `leads/<顧客名>/quote.json` を作成する（このSkillのディレクトリ内 `templates/quote.sample.json` を雛形として使う）。
2. `.venv` の Python でスクリプトを実行し、Excelを生成する。
3. スクリプトが出力する小計・消費税・合計金額と、自己検証結果（`自己検証: OK`）を確認する。
4. 自己検証でエラーが出た場合（`金額の自己検証に失敗しました`）は、入力データを見直してから再実行する。エラーを無視して次段階に進まない。

この段階で確定した金額（税抜・税込）を、段階②のfreee発行に使う。金額はここで一度も自己検証を通さずにfreeeへ送らないこと。

## 段階②｜freeeで正式な見積書を発行

freee会計・freee請求書は別サービスで、見積書のAPIも別物である点に注意する。

- `service: "accounting"` の `/api/1/quotations` は **GET専用**（一覧・参照のみ）。ここにPOSTしても見積書は作れない。
- 見積書の新規作成は `service: "invoice"` の `/quotations` で行う（POST）。
- 取引先（partner）は `service: "accounting"` の `/api/1/partners` で作成・検索する。ここで作った `partner_id` を `invoice` サービスの `/quotations` にそのまま渡せる（取引先マスタは会計・請求書で共有されている）。

### 発行済み見積書を編集する前の安全確認（重要）

既存の見積書に手を加える前は、**必ず直前にGETし直して現在の状態を確認する**。特に以下のいずれかが自分の直近の記憶と異なっていたら、上書きせずユーザーに確認すること。

- `sending_status` が `"sent"`（送信済み）になっている
- 取引先名・住所・担当者名など、自分が最後に確認した時点から変わっている

これらは、自分の与り知らないところで先方への送付や他者による編集が行われた可能性を示す。気づかず上書きすると、送付済みの内容と食い違う書類を作ることになる。

## 段階③｜受注内容の別紙（Markdown）を作成

見積書本体は品目をシンプルに保ち、受注内容の詳細説明は別紙として分ける。見積書に埋め込まない理由は、金額訂正のたびに詳細説明ごと再発行する事態を避けるため。

## 完了とみなす条件（自己検証の基準）

- 段階①：Excelファイルが実際に生成され、`自己検証: OK` が出ている
- 段階②：freee見積書が発行され、金額が段階①のExcelと一致している。発行済み見積書を編集した場合は、編集前に安全確認（上記）を行っている
- 段階③：別紙の金額表記が見積書本体と一致している（別紙内で独自に金額を計算し直していない）
- 金額は税抜・税込を必ず併記する
- 顧客名は正式社名（略称不可）で統一する

SKILL.mdのうち手順詳細（freee APIのリクエストボディ例など）は本記事では割愛していますが、実物にはリクエストの具体的なJSON例まで書いてあります。ポイントは「エラーを無視して次段階に進まない」「発行済み見積書を編集する前に必ずGETし直す」という2つの安全弁です。どちらも、実際に運用して初めて必要性が分かったルールでした（後述）。図にすると次のようになります。

金額の自己検証は、openpyxlでExcelを組み立てる十数行のPythonスクリプトで行っています。quote.jsonのフォーマットはこうです。

{
    "customer": "株式会社サンプル商事",
    "subject": "Webサイトリニューアル一式",
    "items": [
        {"name": "ディレクション費", "unit_price": 300000, "quantity": 1},
        {"name": "デザイン費", "unit_price": 200000, "quantity": 1}
    ],
    "payment_terms": "月末締め翌月末払い",
    "valid_days": 30,
    "issue_date": "2026-07-12",
    "tax_rate": 0.10
}

品目・単価・数量から小計・消費税・合計を計算し、Excelに出力すると同時に「入力データに不足がないか」「品目が1件もないケース」などをバリデーションします。この結果が「自己検証: OK」にならない限り、Skillの手順上、次のfreee発行段階に進めません。

freee API連携で踏んだ落とし穴

実際にfreee APIをつないで見積書発行まで動かす過程で、2つ踏み抜きました。

落とし穴1: freee会計とfreee請求書は別サービス

見積書を作ろうとして最初にハマったのがこれです。freee会計の /api/1/quotations にPOSTしても見積書は作れませんでした。このエンドポイントは自分が確認した時点では一覧・参照用の挙動しかせず、新規作成は service: "invoice" の /quotations を使う必要があります。freeeはエンドポイントの仕様が変わることがあるので、実装前に最新のAPIドキュメントで挙動を確認してから叩くのが安全です。

取引先（partner）は逆に、invoiceではなくaccountingサービス側で作成・検索します。ただし作ったpartner_idはinvoice側にそのまま渡せるので、取引先マスタ自体は会計・請求書の間で共有されています。この「エンドポイントはサービスごとに分かれているが、IDは共有」という構造は、SKILL.mdに明記しておかないと毎回同じ場所で迷います。

落とし穴2: 見えないところで状態が変わる

見積書を発行した後、確認のために再度GETしたところ、sending_statusが「送信済み」に変わっており、取引先情報も自分が最後に見た内容から書き換わっていました。原因は特定できていません（freee画面から誰かが操作した、あるいは別の連携が動いた可能性があります）。

これに気づかず上書き編集していたら、送信済みの書類と食い違う内容で再発行してしまうところでした。この経験から、「発行済み見積書を編集する前は必ず直前にGETし直し、記憶と違っていたら止まる」というルールをSKILL.mdに明文化しました。今回の1件だけでの判断ですが、エージェントが担当する作業が増えるほど、この手の「見えない状態変化」に対する自衛策は必要になっていくはずです。

確信度が低いことを判断できるのは重要な機能

3つの構成物を実際の問い合わせ対応で使ってみて、一番効いたのはlead-triageの「確信度」の仕組みでした。

ある問い合わせで、ナレッジ（sales-knowledge/）にWebサイト制作の情報しかない状態で「システムのセキュリティレビュー」を依頼されたケースがありました。lead-triageは確信度「低」を返し、「ナレッジに該当情報がないため要確認（前例のない案件）」と明記して止まりました。

ここで担当者が内容を確認し、対応方針（機能・アーキテクチャ・運用可用性の3観点でのレビュー、改善提案までを含む対応）を決定。この内容をproducts.mdに新しい項目として追記しました。

## システムレビュー・セキュリティ検証（対応可能）

既存プログラムの検証・改善を希望する問い合わせに対応可能。

- 内容：上級プログラマによるレビュー。①機能の過不足、②システムとしてのアーキテクチャ、
  ③運用の可用性、の3観点を中心に検証する
- 付加サービス：レビューで見つかった改善点について、依頼者が自身で
  改造・修正する際にそのまま使えるプロンプトの作成まで対応する
- 価格：個別見積り（プログラム現物を確認してから確定）。一次回答では金額を提示せず、
  ソースコード一式の共有を依頼し、確認後に見積りを案内する

同じ問い合わせ内容でlead-triageを再実行すると、確信度は「高」に変わりました。少なくともこのパターンの問い合わせについては、担当者確認なしで一次回答案を出せる状態になっています。

ここから得た運用パターンは3つです。

1. 確信度が低いのはバグではなく機能。ナレッジにない情報を推測で埋められるより、「分からないので確認してください」と正直に止まってくれる方が営業上安全です。
2. 1回の確認は、必ずナレッジに書き戻す。担当者確認をその場限りで終わらせずproducts.mdに反映すれば、次の類似案件から効果が波及します。書き戻さなければ、同じ確認を毎回繰り返すことになります。
3. 見えない状態変化には即座に対応する。freeeのsending_statusのように、エージェントの外側で状態が変わるケースは、エージェントの作業範囲が広がるほど増えます。気づいた時点でルール化して踏み抜きを防ぐしかありません。

/loopと/goalで巡回を仕組み化する

ここまでの3つの構成物は、すべて「メインの会話で呼び出す」前提でした。しかし実際に運用してみると、leads/配下の案件は増えていくのに、「送信前の確認事項が残っていないか」「一次回答案の文面がヒアリング後の内容と食い違っていないか」を毎回手動でチェックするのは抜け漏れが起きやすいと分かりました。ここで使えるのがClaude Codeの/loopと/goalです。

/loop — 定期巡回のコマンドを作る

まず、巡回手順を.claude/commands/lead-sweep.mdとして切り出しました。

---
description: leads/配下を巡回し、送信待ち・確信度が低い案件を検知して一次回答案を更新する
---

`leads/` 配下の全案件フォルダを走査し、以下を確認する。

## 手順

1. `leads/<顧客名>/一次回答案.md` を持つ案件を列挙する。
2. 各案件について次を確認する。
   - 確信度が「中」または「低」のままか
   - 「送信前の確認事項」にチェック未了の項目が残っているか
   - `quote.json` や見積書が案件フォルダに存在するのに、一次回答案の文面が「現物確認後に確定」など未確定トーンのまま残っていないか（矛盾チェック）
3. 該当する案件があれば、`lead-triage` サブエージェントを使って一次回答案を再評価・更新する。ナレッジ（`.claude/sales-knowledge/`）に新しい情報が追加されていれば、それを反映する。
4. 更新した案件・現状維持した案件を一覧にして報告する。

## 重要な制約

- 見積書の発行・顧客への送信はここでは行わない。あくまで一次回答案の内容確認と更新にとどめる。
- 確信度が「低」のまま解決できない場合（ナレッジ不足）は、その旨を報告に明記し、担当者に判断を仰ぐ。
- `sales-knowledge/` への書き戻しは提案のみ行い、ファイルの編集は担当者の承認を得てから行う。

## 出力形式

```
## 巡回結果（<日時>）

### 更新した案件
- <顧客名>：<変更内容>

### 現状維持（確信度: 高、対応完了）
- <顧客名>

### 要確認（人間の判断待ち）
- <顧客名>：<理由>
```

これを/loop 5m /lead-sweepのように実行すると、5分おきに巡回が走る定期ジョブが立ちます。ただし実際に検証してみると、ここには3つの注意点がありました。

1. セッション限定・7日で自動失効する。/loopが作る定期ジョブはそのセッションが生きている間だけ動き、しかも7日を超えると自動的に消えます。「エージェントに営業を任せっぱなしにする」という期待とは裏腹に、実体は「今開いているセッションの間だけ効く時限式のリマインダー」です。無人・恒久的に回し続けたいなら、クラウド常駐の/scheduleを検討する必要があります。
2. 本番データに対して無人で発火する。leads/の実データ、この案件では実際にfreeeで見積書まで発行済みの案件に対して、定期ジョブが人手を介さず発火します。今回は記事化のための実演として一度だけ手動発火させ、設定内容と出力を確認したのち、定期ジョブ自体は削除しました。本番運用するなら、発火のたびにleads/とsales-knowledge/の実データを触ることになる自覚が要ります。
3. 新しく置いたコマンドが、その場ではまだ拾われないことがあった。.claude/commands/lead-sweep.mdを作成した直後にこのコマンドを呼び出したところ、その時点では「未登録」として弾かれました。少し操作を挟んでから呼び直すと登録されていました。1回の観測なので原因（内部的な一覧更新のタイミングなど）は特定できていませんが、追加したコマンドがすぐに使えないときは、こうした反映待ちの可能性も疑うとよさそうです。

実際にヒアリング済み・見積書発行済みだが確信度「中」のまま残っていた案件に対して巡回を走らせたところ、次のような趣旨の評価が返ってきました（実際の出力を要約・匿名化しています）。

products.mdには「価格：個別見積り（プログラム現物を確認してから確定）」と明記されている。しかし本件は、ソースコードがまだ共有されていない段階にもかかわらず、ヒアリングのみで金額が確定し見積書まで発行済みという、ナレッジが想定する順序（現物確認→確定）と異なる進み方をしている。一次回答案の「確信度：中」の理由欄はNDAのみを挙げており、この価格確定プロセスの逸脱には触れていない。これは社内の人間判断による正当な確定経路であり確信度を下げるべき事案ではないが、確信度の理由欄に明記した方が、後から見直す人にとって経緯が分かりやすい。

これは想定していなかった収穫でした。この案件は担当者がヒアリングだけで価格を確定させた、ナレッジの標準プロセス（現物確認後に確定）とは違う進み方をした案件でした。人間の判断としては正当な近道でも、確信度ラベルの理由欄にその近道を通ったことが書かれていなければ、後から案件を見返す人（あるいは次に巡回するエージェント自身）には「なぜ現物未確認なのに金額が確定しているのか」が分かりません。定期的に機械的な目でチェックさせて初めて、この記録の抜けに気づきました。

なお、同じ案件・同じファイルに対して巡回を複数回試したところ、毎回まったく同じ指摘が返るわけではありませんでした（ある回は「確信度ラベルの理由欄の書き方」を、別の回は「確信度と個別の保留事由の混同」を指摘するなど、着眼点が変わることがあります）。LLMベースのレビューは決定的な静的解析ではなく、実行のたびに切り口が変わり得るものとして扱う必要があります。1回の巡回結果を鵜呑みにせず、指摘を積み重ねて記録に残していく運用が前提になります。

/goal — 「どこまでやったら終わりか」を縛る

/loopが「いつ・何度回すか」を決める一方、/goalは「1回の実行の中で、どこまで終えたら完了としてよいか」を縛るコマンドです。Claude Codeのコマンド一覧には「Set a goal Claude checks before stopping（Claudeが停止する前にチェックするゴールを設定する）」と説明されています。

※ここは断っておきますが、筆者はまだ/goalを実際に実行して挙動を確認できていません。以下は説明文とコマンド体系から読み取れる役割分担についての、筆者の推測です。

想定している使い分けは次の通りです。

• /loop：/lead-sweepを「いつ・何度」実行するかを管理する（時間・間隔の制御）
• /goal：1回の/lead-sweep実行の中で、「更新した案件・要確認案件をすべて報告し終えるまで完了と言わない」といった達成条件をチェックさせる（完了判定の制御）

例えば/lead-sweep実行時に「巡回結果の出力形式にある3つの区分（更新した案件／現状維持／要確認）すべてに触れるまで完了としない」というゴールを設定すれば、報告の書き漏らしをClaude自身に自己チェックさせられます。lead-triageの「確信度が低ければ止まる」がエージェント単体の安全弁だとすれば、/goalはコマンド実行1回分の完了判定に対する安全弁、という位置づけになりそうです。

まとめ

営業部門の3つの定型業務を、CLAUDE.md 1本・サブエージェント定義2本・Skill 1本・Slash Command 1本（+Pythonスクリプト1本）で実現しました。コード量としては小さく、大半はMarkdownです。

設計で意識したのは次の2点だけです。

• ナレッジ（何を知っているか）と実行担当（誰が何をするか）を分離する
• 「分からない」を機能として扱い、確信度が低い場合は必ず人間に戻す

見積書・提案書・一次回答案、いずれも最終的な送信・発行判断は人間が行う設計にしています。AIエージェントが作るのはあくまで下書きと自己検証済みの数値まで。営業はミスがそのまま顧客に届く業務なので、この線引きだけは崩さないようにしています。逆に言えば、線引きさえ守れば定型部分は思っていたより安全に任せられる、というのが今回の実感です。

/loop・/goalで巡回を仕組み化する場合も、この線引きは変わりません。ループが自動化するのは「検知して下書きを更新するところまで」であり、freeeへの見積書発行や顧客への送信は今回もあえて自動化の対象から外しました。仕組み化するほど、どこまでを機械に任せてどこからを人間の承認に戻すかの境界線を明文化しておく必要性は増します。

各定義を見てもらうとわかると思いますが、その内容は整理されているとは言え、普通に営業マンに作業指示・営業の考え方を行うことしか書かれていません。つまり、このレベルで書けばスキル・エージェントとして機能させることができるということです。
とにかく、テスト環境下で色々と試してみることです。