営業部門にAIエージェントチームを1つ作ってみた話
- ⏱ 約6分で読めます - 👁 … viewsSNSでは最近、エージェントを使った自律動作の話題をよく見かけます。「会社組織をエージェント化して、一人で50人分の会社を作った」といった類の投稿です。この流れもあってか、「サブエージェントとかSkillって、結局どう使えばいいの？」と聞かれることが増えました。ドキュメントを読めば機能の説明は書いてあります。でも「実際に1つの案件でどう動くか」までは、自分で手を動かさないと分かりません。
その回答のつもりで、営業部門の3つの定型業務（見積書作成・提案書レビュー・新規リード対応）をClaude CodeのSkill・サブエージェントとして構築し、実際に来た1件の問い合わせで最初から最後まで動かしてみました。今回はその記録です。
作ったもの
構築したのは3つです。
顧客名・件名・品目を渡すと金額の自己検証つきで見積書を作るquote-organizer（Skill）。提案書を、作成者本人とは別の視点でレビューするproposal-reviewer（サブエージェント）。そして新規の問い合わせに、ナレッジベースだけを根拠に一次回答案を作るlead-triage（サブエージェント）。
どれも数十行のMarkdownファイル（SKILL.mdやagents/*.md）を書くだけで作れます。難しいプログラミングは要りません。
管理構造
ファイルはプロジェクトルート直下に散らかさず、役割ごとに分けています。
.claude/
agents/
lead-triage.md # 一次回答案を作るサブエージェント
proposal-reviewer.md # 提案書レビューのサブエージェント
skills/
quote-organizer/ # 見積書作成Skill（SKILL.md + 生成スクリプト）
sales-knowledge/
faq.md # よくある質問
products.md # 商品・サービス資料（確信度を上げるフィードバック先）
competitor-notes/ # 競合情報のメモ
leads/
<顧客名>/ # 案件ごとにフォルダを分ける
form_customer.txt # 問い合わせ原文
一次回答案.md # lead-triageの出力
quote.json # 見積書生成の入力
見積書_<YYYYMMDD>.xlsx # 金額の自己検証用（送付用ではない）
別紙_作業内容明細.md # 受注内容の詳細（見積書本体とは別に作成）
ポイントは2つです。1つは、判断の根拠（sales-knowledge/）と実行担当（agents/・skills/）を分けていること。確信度が低かった案件で得た知見はproducts.mdに書き戻す先が決まっているので、都度どこに追記すべきか迷いません。もう1つは、案件ファイルをleads/<顧客名>/に集約していること。1案件分がひとつのフォルダで完結します。
実際に1案件を流してみた
ある日、問い合わせフォームにこんな内容が届きました（実際の案件を元にしていますが、企業名は仮名にしています）。
「自社で作った注文管理システムの検証をお願いしたい。プログラミングの知識はなく、プログラムはChatGPTで作成した」
lead-triageサブエージェントに一次回答案を作らせてみたところ、返ってきたのは**確信度「低」**の回答でした。理由は明快で、当時のナレッジ（FAQ・商品資料）にはWebサイト制作と保守契約の情報しかなく、「セキュリティ・コードレビュー」というサービスの記載がなかったからです。ナレッジにない内容は絶対に推測で回答しないという制約を、そのまま守った結果です。
ここで担当者（今回は社長。まあ自分です）が内容を確認し、対応方針を確定しました。「機能の過不足」「システムとしてのアーキテクチャ」「運用の可用性」の3観点でレビューし、改善に必要なChatGPT向けプロンプトの構築まで行う、という内容です。
正式な返信案を作った後、このサービス内容をproducts.md（ナレッジファイル）に追記しました。そして同じ問い合わせでlead-triageを再実行すると、今度は**確信度「高」**に変わりました。同じ問い合わせパターンなら、次回は担当者確認を挟まず一発で使える回答案が出てきます。
freeeで見積書を発行してみて分かったこと
見積り内容が固まったところで、quote-organizer Skillでローカルの見積書Excelを作り、金額の自己検証を通してから、freee APIで正式な見積書を発行しました。
ここでいくつか、事前には分からなかった落とし穴がありました。
freee会計とfreee請求書は別サービスで、見積書のAPIも別物です。freee会計側の/api/1/quotationsはGET専用（一覧参照だけ）で、実は見積書の新規作成には使えません。実際に発行できるのはfreee請求書側の/quotationsエンドポイントでした。ドキュメントを読んだだけでは気づきにくく、実際にPOSTしてエラーを見て初めて分かった構造です。
もう1つ、これは肝を冷やした話です。見積書を発行した後、少し間を置いて内容を確認しようとGETし直したところ、sending_statusが「送信済み」に変わっており、取引先の住所や担当者名まで、自分が最後に見た状態から書き換わっていました。誰かが既に先方に送ったのか、それとも別の経路で編集が入ったのか、その場では分かりません。ここで本文を上書き編集していたら、送付済みの内容と食い違う書類を作ることになっていたはずです。
結局、状態が変わっていることに気づいた時点で作業を止め、確認を取りました。状態が変わった経緯そのものは最後まで分からずじまいでしたが、先方への発行自体は済んでいたようで、本体には触れず、受注内容の詳細を書いた別紙（Markdown）だけを別途作成する方向に切り替えました。
この経験から、quote-organizerのSkill定義には「発行済みの見積書を編集する前は、必ず直前に状態を再確認する」というルールを明文化しました。次に似た場面が来ても、同じ見落としをしないための備忘です。
見えてきたパターン
lead-triageが最初に返した確信度の低さは、直すべきバグじゃありません。ナレッジにない話を自信満々に答えられる方がむしろ怖い。低いまま担当者に投げてくれるから、確認するタイミングが生まれます。
確認した後の情報を、その場限りで捨てないこと。今回は1回の担当者確認をproducts.mdに書き戻しただけで、次からは同じ手間が要らなくなりました。1回の確認が、以降の類似案件すべてに効いてきます。
そして一番効いたのは、状態が自分の知らないところで変わっていたら、まず疑って手を止めること。これは実際に肝を冷やしたから身についた癖です。エージェントに任せる作業が増えるほど、「今見ている状態は自分が最後に見た状態と同じか」を確認する必要が出てきます。
最後に
「営業部門にAIエージェントを導入する」と聞くと大掛かりに聞こえますが、実態は数十行のMarkdownファイルを3つ書いただけです。難しいのはコードではなく、確信度が低かったときに何を確認し、何をナレッジに戻すか、その運用の型を決めることでした。
同じような定型業務を抱えている部門があるなら、一番よく繰り返している業務を1つ選んで、都度チャットで頼んでいる内容をSkillかサブエージェントに書き起こしてみてください。うまくいくかは、正直やってみないと分かりません。