第10章 営業活動を自動化する

営業は「入力されない」領域です

第 1 章では、AI とつないで自動化する対象の最初に「営業リスト・CRM」を挙げました。営業は自動化できる余地が大きい領域ですが、多くの現場では営業だけが人の手作業のまま残っています。その理由は道具が無いからではなく、CRM（顧客管理データベース。企業・商談・接点を記録する台帳）に事実が入力されないからです。入力されない項目は、AI から見れば存在しないのと同じです。ここが営業を自動化するときの出発点であり、一番の課題でもあります。

この章では、リスト → 有効リード → 商談 → 契約 → 運用という営業の一連の流れを、姉妹記事と同じく①データモデルと ID、②連携、③自動化の順で組み立てていきます。この順番を飛ばすことはできません。①が無いまま③に進むと、間違ったリストに素早く送る仕組みができあがってしまいます。しかも処理が速いぶん、間違いに気づくのが遅れます。

この章では、CRM の正本を Notion に置く前提で説明します。著者の会社では「基本の情報はすべて Notion に集約する」と決めているためです。スプレッドシートや市販の CRM を使う場合でも設計は変わりません。変わるのは API の呼び方と認可の形だけなので、その部分は章の最後にまとめて説明します。

営業のオントロジー

エンティティと一意キー

まず、姉妹記事で紹介したオントロジーの最小例から、営業に必要な 5 つのエンティティを取り出します。運用アカウントと成果物は第 7 章で扱うので、ここでは省きます。

企業の一意キーを法人名だけにしないのは、表記が揺れるからです。例えば「株式会社」が前に付くか後ろに付くか、全角か半角か、屋号か法人名か、支店か本社か、といった違いがあります。人が見れば同じ会社だと分かりますが、機械には別々の 4 社に見えてしまいます。ドメインを添えることで、初めて同じ会社として扱えるようになります。また、担当者は異動で入れ替わるので、企業とは別のエンティティにして企業に属させます。商談も 1 つの企業に複数できます。失注した半年後に別の商談が始まることも珍しくありません。

表の「誰が起票するか」の列は、この章の設計の中心になる部分です。企業・担当者・接点履歴は自動で入力し、商談と契約のステータスだけを人が更新します。この分担を先に決めておかないと、自動化を足すたびに「この項目は誰が書くのか」が曖昧になり、最終的には二重に書かれるか、誰も書かないかのどちらかになってしまいます。

ステータスは排他・網羅で、遷移条件を書く

商談のステータスは、「どの商談も必ずどれか 1 つのステータスに入り、2 つに同時に入ることはない」形（排他・網羅）にする必要があります。ここでは姉妹記事のステータス表を引き継ぎます。確度は一例なので、自社の実績から決めてください。

ステータスの定義は設定ファイルとして持ちます。画面の選択肢も、フォーキャストの確率も、停滞検知の対象も、すべて同じ 1 箇所の定義から決まるようにするためです。

# 商談ステータスの正本。画面・予測・停滞検知はここだけを読む
statuses:
  - {id: untouched,   label: 未接触,     probability: 0,   open: true}
  - {id: appointment, label: アポ獲得,   probability: 10,  open: true,
     enter_when: 商談の日程が確定した}
  - {id: considering, label: 担当者検討, probability: 25,  open: true,
     enter_when: 提案を提示し先方社内で検討中}
  - {id: champion,    label: 担当者合意, probability: 50,  open: true,
     enter_when: 担当者が導入意思を表明した}
  - {id: decision,    label: 決裁者合意, probability: 90,  open: true,
     enter_when: 決裁ラインが合意した}
  - {id: signed,      label: 締結,       probability: 100, open: false}
  - {id: lost,        label: 保留・失注, probability: 0,   open: false,
     requires: lost_reason}   # 理由が無いと遷移できない

ここで大事なのは確度の数字ではなく、遷移条件が事実として書かれていることです。遷移条件が曖昧だと「担当者合意」の意味が担当者ごとに違ってしまい、フォーキャストは担当者それぞれの主観を足し合わせたものになります。同じ「合意」を「前向きな反応があった」と読む人と「発注の意思を聞いた」と読む人が混ざると、予測は簡単に 2 倍ずれます。確度を 50% にするか 60% にするかを議論する時間があるなら、遷移条件を 1 行書くことに使ったほうが、予測の精度はずっと上がると思います。

遷移条件を事実で書いておくと、機械が判定できる遷移がどれなのかが見えてきます。例えば「日程が確定した」は、カレンダーに予定が入ったという事実で判定できます。ただし、自動で進めてよいのは記録された事実で判定できる遷移だけで、確度の解釈が必要な遷移は人が更新します。また、失注には理由の入力を必須にしてください。理由の無い失注は、後から掘り起こすことができません。

正本は 1 箇所

商談のステータスが CRM とスプレッドシートとチャットの 3 箇所に書かれている現場は珍しくありません。しかし、どれが正しいかが決まっていないと、自動化の仕組みはどれを読めばよいのか判断できません。第 1 章の SSOT の考え方どおり、正本は CRM の 1 箇所と決め、他の場所は同期先かリンクにします（原則 A）。

何がどこに属するかも決めておきます（原則 U）。商談・契約・接点履歴・鍵は企業（案件）に属し、企業はテナント（契約主体）に属します。議事録は別々のページに書き散らさず、CRM 側の議事録データベースにレコードとして保存し、企業へのリレーション（関連付け）を必須にします。命名では略称と「その他」を使わないようにしましょう。略称は人には通じても、機械は同じものだと判断できません。

実装単位で描き直す

姉妹記事の図は、業務の流れを描いたものでした。ここでは同じ流れを、「どの工程をどのスキル・ツールが担い、どこで人が判断するか」という形で描き直します。人が判断するのは送信、CRM の書き込み、提案概要の承認の 3 箇所だけです。送信と CRM の書き込みは、Claude のパーミッション（ツールを確認なしで使わせるか、呼び出すたびに人に確認させるかの設定。第 2 章）で確認の対象にします。エージェントがそのツールを呼ぶと確認画面が表示され、人が内容を見て許可したときだけ実行されます。

先に、次の図の各工程を担う手順書（第 2 章で説明したスキル）を一覧にしておきます。それぞれの骨子は、この章の各節で紹介します。どの手順書も「調べて書くところまで」を担当し、送信と CRM の書き込みは持っていません。いずれも著者の営業チームで使っている手順書から、社名や商材に依存する部分を外して一般化したものです。

図は横にスクロールできます。図を原寸で開く

図の元になった mermaid を見る

mermaid

flowchart LR
  subgraph FIND["見つける（定期実行）"]
    SIG["購買シグナル検知<br>新規オープン / 採用 / 探索投稿"]
    TEN["公募・入札の巡回"]
    LOST["失注・解約の掘り起こし"]
  end
  SIG --> DEDUP["重複排除・除外リスト<br>key: 法人名＋ドメイン"]
  TEN --> DEDUP
  LOST --> DEDUP
  INB["インバウンド<br>検索 / AI 検索 / LP の問い合わせ"] --> DEDUP
  DEDUP --> VAL["アドレスの検証<br>スコアリング"]
  VAL --> LIST[("CRM: 未接触")]
  LIST --> RES["企業調査 + 事例<br>読むだけ"]
  RES --> COPY["文面の一括生成<br>1 行 1 社の CSV"]
  COPY --> G1{"人が確認画面で許可"}
  G1 -->|"送信・投入"| OUT["アウトリーチ<br>フォローアップは反応で分岐・返信で停止"]
  OUT --> REPLY["反応の自動起票<br>返信 / 問い合わせ → 接点履歴"]
  REPLY --> DEAL[("CRM: 商談")]
  DEAL --> PREP["商談前ブリーフ"]
  PREP --> SUM["議事録要約 → 更新案"]
  SUM --> G2{"人が確認画面で許可"}
  G2 -->|"書き込み"| DEAL
  DEAL --> PROP["提案・見積"]
  PROP --> G3{"提案概要の承認"}
  G3 --> DECK["資料はテンプレ複製"]
  DEAL --> WATCH["停滞検知・加重予測<br>決定的（生成 AI 不使用）"]
  WATCH --> PUSH["毎朝の通知"]

FETC の 4 段で読み直す

営業の AI 活用を工程ごとに整理した枠組みに、Clay 社が提唱する FETC があります。Find（見つける）・Enrich（補う）・Transform（整える）・Create（作る）の 4 段です。同社が以前提唱していた FETE では最終段が Export（他システムへの書き出し）でしたが、FETC ではそこが Create に置き換わりました。同社はその理由を、「従来の自動化はデータをシステム間で移すものだったが、AI を使う自動化は新しい成果物を生成するものだから」と説明しています（Clay University）。

上の図をこの 4 段に当てはめると、次のようになります。

この章の構成と FETC が合っているのは、Create が「送る」ではない点です。FETC の最終段は成果物を作るところまでで、送信は含まれていません。本章も同じように、Create の出力（文面・更新案・提案概要）はすべて確認画面の手前に置き、送信と CRM への書き込みは人が確認画面で許可します。一方で、4 段に含まれないものも本章には 2 つあります。送信した後の反応を接点履歴へ自動で起票する工程と、パイプラインを見張る工程です。FETC は見込み客に届くまでを扱う枠組みなので、届いた後の工程は本章の後半で組み立てます。

1 つ注意があります。Clay 社は、この枠組みを使って返信率が従来の 2〜3 倍になった企業があると述べていますが、これは同社のサービスの教材の中の記述で、条件や母数は示されていません。自社の返信率は、自社の実績をもとに設定してください（後の「シーケンスとキャパシティ」）。

リードを見つける

購買シグナルで探す

リードを探すときは、「この業種の会社を全部」ではなく「いま買う理由がある会社」を探します。店舗型ビジネスであれば、新規オープン、リニューアル、採用募集の増加、外国人客の口コミの増加などが代表的なシグナルです。シグナルごとに検索クエリを固定し、定期実行で毎日から週 2 回ほど回します。

BtoB では、求人票と組織の動きがシグナルになります。求人票は職種名だけでなく、本文まで読むようにしましょう。募集している職務の業務内容に、自社が売っているものと同じ仕事（「SNS の運用」「動画の制作」「広告の運用」など）が書かれていれば、その会社はいま、その課題を人を雇って解決しようとしています。「外注でも解決できます」と伝える相手として、これ以上の根拠はありません。部署別の人員の増減も同じように使えます。営業やマーケティングの部署だけが増えている会社は、その領域への投資を始めていると考えられます。公開情報（採用ページの募集数や、SNS で申告されている勤務先など）を定期的に数えて、増えた部署を記録します。このとき見るのは人数そのものではなく、人数の変化です。

競合の顧客も、リードを探す先になります。競合の導入事例ページや「ご利用企業」のロゴから企業名を書き起こし、ドメインと業種を補って（補い方は次の節「相手を調べる」で説明します）、ターゲットの一覧にします。競合を使っている会社には、自社の商材がなぜ必要かを一から説明する必要がありません。さらに、同じ会社が競合への不満を投稿していれば、乗り換えの提案として最初の 1 通を書くことができます。乗り換えを提案する文面では競合を悪く言わず、相手が不満として書いた点に自社がどう応えられるかだけを書くようにしましょう。

こちらから探すリードのほかに、向こうから来るリードもあります。例えば、検索で上位に表示される記事と、それを SNS や LINE で届ける仕組み（第 6 章・第 7 章・第 9 章）、AI 検索の回答で引用されるサイト（第 6 章。自社の商材が ChatGPT などの回答に出てこない場合の原因の調べ方と直し方も第 6 章で説明しています）、広告の遷移先の LP とその改善の A/B テスト（第 4 章・第 3 章）などです。この本の他の章で扱う領域は、営業から見るとすべてリードの入口になります。入ってきたリードは問い合わせフォームの通知から自動で起票し（後の「反応の自動記録」）、こちらから探したリードと同じ一覧・同じ一意キーで管理します。入口が違うからといって別の表で管理すると、同じ会社に両方から連絡してしまうことになります。

SNS で「探している人」を見つける

SNS で何かを探している人は、数日のうちに決めてしまいます。そのため、この仕事では検知の速さがそのまま価値になり、定期実行に載せて初めて意味を持ちます。組み方は次のとおりです。

1. シグナルの定義を先に固定する。「誰の・どんな一文を『探している』とみなすか」を決めてから探します。定義が無いまま探すと毎回違う基準のリストになってしまい、温度を比べることができません。
2. 各行に原文の引用・URL・観測日時・温度（高・中・低）と、理由を 1 行付ける。原文の無い行は載せません。要約だけのリードでは、後から読む人が温度を確かめられないからです。
3. 温度は行動の近さで付ける。例えば「今週末に行く店を探している」は「いつか行きたい」より温度が高くなります。件数を稼ぐために低い温度を高く見せてはいけません。水増ししたリストの分だけ、追客する人の時間が無駄になってしまいます。
4. ゼロ件は正常な結果として扱う。ゼロ件のときは「今回はゼロ件でした」と明記し、定義の広げ方（地域・語彙・見る場所）を提案して終わります。
5. 返信の下書きは作るが、送らない。最初の返信は売り込みではなく、その人の質問に役立つ答えと名乗りにします。一斉送信用の文面は作りません。同じ文面の DM を大量に送るとスパムとみなされ、アカウントが凍結される原因にもなります。また、個人を装った推薦は景品表示法のステルスマーケティング規制（執筆時点で 2023 年 10 月施行。消費者庁）の対象になるので、企業の公式アカウントとして名乗ったうえで書きます。

どの SNS を定期実行に載せるかにも制約があります。Instagram と TikTok は、利用規約で自動化した手段による情報の取得を禁じています（第 3 章。X の利用規約も同様です）。定期実行で自動的に取得してよいのは、公式 API で許可された範囲と、規約で自動収集が禁止されていない情報（ニュースや自治体の公報など。規約はサイトごとに確認してください）だけです。Instagram と TikTok の探索投稿は、人がアプリで検索して記録表に追記し、エージェントは記録表の新着を読んで温度を付け、返信の下書きを作る、という分担にします。

エージェントの作業は、毎回まっさらな状態から始まります（原則 L）。そのため、前回のリストは前回の成果物から取り直し、今回の結果と突き合わせて新着だけを上に出すようにします。初回は「初回なので突き合わせはしていません」と明記します。

「探している」の定義を書き出す

上の手順 1 で固定する定義は、文章にして保存し、毎回同じものを使います。定義に含めるのは、誰の投稿を対象にするか、どんな一文を拾うか、何を除外するか、温度の基準、どこを探すか、の 5 つです。探している人の声のほかに、競合への不満（予約が取れない、対応が悪いといった投稿）や、ライフイベント（引っ越し・記念日・旅行の計画）もシグナルになります。BtoB であれば、担当者の異動や着任、予算期の発言などがこれにあたります。

次は駅前の美容室の例です。

signal_definition:
  対象: 市内と隣接する 2 市に住む個人の公開アカウント
  拾う一文:
    探索: 「〇〇駅 美容室 おすすめ」「縮毛矯正が上手い店を探してる」
    競合への不満: 「予約が 3 週間先まで取れない」「カットが雑だった」
    ライフイベント: 「引っ越してきたばかり」「結婚式の前に髪を整えたい」
  除外:
    - 同業者や事業者のアカウントの投稿
    - 30 日より前の投稿
    - 既存のお客様（顧客名簿と突き合わせる）
  温度:
    高: 日付や期限がある（「今週末」「来月の式までに」）
    中: 探しているが時期が決まっていない
    低: 感想や願望（「いつか行きたい」）
  探す場所: 公開投稿の検索、地域名のハッシュタグ（Instagram・TikTok は人がアプリで検索して記録表に追記する）

定義を変えたときは、変えた日と内容を記録しておきましょう。記録が無いと、先週より件数が増えたときに、見込み客が増えたのか、定義を広げたから増えたのかを区別できなくなります。

ここまでの組み方と定義の決め方を、定期実行にそのまま渡せる手順書（第 2 章で説明したスキル）にすると、次のようになります。description には、この手順書を呼び出す依頼の言い方と、扱わない依頼をどこに回すかを書いています。ここに載せているのは骨子なので、実際に使うときは本文で説明した規則を書き足してください。

---
name: signal-prospecting
description: >-
  公開の投稿や情報から「いま探している・困っている」見込み客の兆しを拾い、
  根拠付きのリード一覧と返信の下書きを作る。
  「見込み客を探して」「リードリストを作って」「競合に不満を持ってる人」で使う。
  定期実行の中身にもなる。
  ※1 社の深掘りは企業調査のスキル。送信はこのスキルでは行わない。
---
# 見込み客の検知

## 先に固定する（定義ファイル）
対象 / 拾う一文 / 除外 / 温度の基準 / 探す場所の 5 つ。
**定義を変えたら、変えた日と内容を記録する**（件数の増減の理由を切り分けるため）。

## 手順
1. 前回のリストを前回の成果物から取り直す。初回は「初回なので突合なし」と明記
2. 規約が自動の取得を禁じている面は、**人が探して記録した表を読む**
3. 各行に原文の引用・URL・観測日時・温度・理由 1 行を付ける。
   **原文の無い行は載せない**
4. 温度は行動の近さで付ける（日付や期限がある = 高）
5. 新着だけを上に出す

## 守ること
- **ゼロ件は正常な結果**。「今回はゼロ」と明言し、定義の広げ方を提案して終わる
- 件数を稼ぐために低い温度を高く見せない
- 返信は下書きまで。一斉送信の文面を作らない。
  企業の公式アカウントとして名乗る（個人を装った推薦は規制の対象）

この手順書の仕事は、見込み客を拾って並べ、返信の下書きを作るところまでで、送信の機能は持たせていません。探している人は数日で決めてしまうので、この手順書は定期実行で毎日回して初めて役に立ちます。毎日自動で回るものに送信まで持たせると、人が確認画面を見ないまま外部に送信される経路ができてしまいます。また、1 社の深掘りは企業調査の手順書に分けています。「見込み客を探して」と「〇〇を調べて」を同じ手順書で受けると、一覧を頼んだ人のところに 1 社の詳しいレポートが届いてしまうからです。地域・語彙・除外といった定義の中身は案件ごとに変わるので定義ファイルに置き、手順書には 5 項目の枠と規則だけを残しています。

手順の最初は、前回の成果物との突き合わせです。エージェントの作業は毎回まっさらな状態から始まり、前回のリストはどこにも残っていないためです（原則 L）。規約で自動の取得が禁止されている SNS については、「人が記録した表を読む」以外の手段を書いていません。Instagram と TikTok の探索投稿を自動で取得する経路は、手順書の側であらかじめ無くしておきます（第 3 章）。原文の無い行を載せないのは、要約だけでは後から読む人が温度を確かめられないからです。温度の基準も「行動の近さ」と決めておきます。基準を決めておかないと、件数を増やす方向に判断がずれていき、低い温度の行に高い温度が付くようになります。水増しした分だけ、追客する人の時間が無駄になってしまいます。

守ることには「ゼロ件は正常な結果」を入れました。ゼロ件を失敗として扱うと、件数を埋める方向に判断が偏るからです。定義を変えた日と内容の記録も欠かせません。件数が増えた週に、見込み客が本当に増えたのか、定義を広げただけなのかは、記録が無ければ見分けられません。また、返信は下書きまでにすること、一斉送信の文面は作らないこと、企業の公式アカウントとして名乗ること、の 3 つにはそれぞれはっきりした理由があります。同じ文面の DM を大量に送るとアカウント凍結の原因になり、個人を装った推薦はステルスマーケティング規制の対象になるからです。

公募・入札を探す

自治体や観光協会は、SNS 運用や動画制作を公募（プロポーザル・入札）で発注することがあります。公募を横断して探すときに一番多い失敗は、集約サイトに書かれた締切をそのまま信じてしまうことです。集約サイトの締切は公式の締切とずれることがあり、著者の環境でも複数の案件でずれを確認しています。締切による足切りは一次情報で確認した締切で行い、確認できないものは「要確認」と書くようにしましょう。参加申込と提案書提出のように締切が 2 段階ある場合は、近いほうを残り日数の基準にして、両方を併記します。

適合度はキーワードが一致するかどうかではなく、「自社のどの資産が、なぜこの案件に合うのか」を理由として 1 行で書きます。「SNS の案件だから」では理由になりません。また、案件を拾うのと同じくらい、捨てることも大切です。除外した案件も理由付きで残しておくと、次回の巡回で同じ案件をもう一度検討せずに済みます。

巡回の検索と記録の決めごと

公募の情報は年度で管理されています。自治体のサイトは和暦、集約サイトは西暦で書かれていることが多いので、検索では両方を使います（令和 8 年度は 2026 年度です）。「公募型プロポーザル」「公告一覧」のように、発注者が必ず使う決まった言葉を検索語に入れると、取りこぼしが減ります。

〇〇市 公募型プロポーザル 令和8年度 SNS
〇〇市 公募型プロポーザル 2026年度 動画制作
〇〇県 観光 プロポーザル 公告一覧
〇〇観光協会 業務委託 企画提案 募集

検索の回数の上限と打ち切りの条件、同じ案件かどうかを判定する目印（発注者＋案件名＋年度）の決め方は、第 3 章の「検索の組み方と打ち切り」で詳しく説明しています。公募の場合は、再公告された案件と、翌年度に同じ名前で出た案件を別の案件として登録します。前年の案件と混ぜてしまうと、締切も予算も前年の値のまま判断することになるからです。

巡回するサイトは一覧にしておきます。3 回続けて新しい案件が 1 件も出なかったサイトは、一覧から外す候補として人に提案します。巡回先が増えるほど 1 回の作業が長くなり、読まれない結果が増えてしまうからです。

巡回からランク付けまでを手順書にすると、次のようになります。

---
name: tender-scouting
description: >-
  自治体・観光協会・公共団体の公募（プロポーザル・入札）を巡回し、
  自社の資産との適合度でランク付けした応募先の一覧を作る。
  「応募先を探して」「今応募できる公募はあるか」「うちに合うプロポーザル」で使う。
  定期実行の中身にもなる。
  ※発注者 1 件の深掘りは企業調査のスキル、提案書づくりは提案ワークフローのスキル。応募は人が行う。
---
# 公募・入札の巡回

## 先に読む（記憶で代用しない）
- 自社の資産と採点基準の一覧（資産ごとに「どんな要件に刺さるか」と、述べてよい実績の範囲）
- 巡回先の一覧（集約サイト・自治体サイト・横断検索の検索語）

## 手順
1. 今日の日付を確認する（残り日数の基準）
2. 巡回先を回り、発注者・案件名・概要・締切・予算・入手先 URL を抜く。
   検索語は和暦と西暦の両方、発注者が使う定型語（公募型プロポーザル / 公告一覧）を含める
3. **締切は一次情報（発注者の公式ページ）で裏取りする**。集約サイトの値で足切りしない。
   裏取りできなければ「要確認」。二段締切は直近を基準にして両方を併記する
4. 同じ案件が複数の出どころに出たら、発注者＋案件名＋年度で 1 件にまとめ、公式を正とする。
   再公告と翌年度の同名案件は別の案件として登録する
5. 適合度を ◎○△✕ で付け、**理由の行に「どの資産がなぜ刺さるか」を書く**。
   「SNS だから」「動画だから」は理由にならない。✕ は除外する
6. 応募すべき順に並べ、本命 1〜2 件を提案ワークフローへ渡す提案で終える

## 出力の型
推奨ショートリスト（適合 / 発注者 / 案件名 / 目的 / 対象媒体 / 締切 / 残り日数 / 刺さる資産と理由 / 入手先）/
締切が近い・判断が要るもの / **除外した案件と理由** / 定点観測している巡回先 / 次の一手

## 守ること
- 実績は資産の一覧に書かれた範囲でしか述べない
- 拾うのと同じくらい捨てる。除外した案件も理由付きで残す（次回の巡回で再検討しないため）
- 3 回続けて新着ゼロの巡回先は、外す候補として人に提案する

この手順書が担当するのは巡回とランク付けまでで、応募は含みません。発注者 1 件の深掘りは企業調査に、提案書づくりは提案ワークフローに分けています。「応募先を探して」と「この案件を調べて」を同じ手順書で受けると、一覧を頼んだ人に 1 件だけの詳しい調査が返ってきてしまうからです。「先に読む」には資産の一覧と巡回先を置き、記憶で代用しないように書きました。記憶で書いた理由は実績を盛りやすく、盛られた 1 行はそのまま提案書まで引き継がれてしまいます。締切の確認を一次情報に限っているのは、集約サイトの締切が公式とずれることがあるからです。ずれた締切で足切りをすると、応募できたはずの案件を自分で外してしまうことになります。除外した案件を理由付きで残す 1 行も、目立ちませんが効果があります。これが無いと、翌週の巡回で同じ案件を同じ理由でもう一度検討することになり、一覧は巡回のたびに同じ長さに戻ってしまいます。

失注と解約を掘り起こす

失注した案件も、時間の経過や状況の変化によって再び商談になることがあります。例えば、担当者が替わった、予算期が来た、競合との契約が切れた、といった場合です。掘り起こしをするためには、失注した時点で理由が選択式で記録されている必要があります。理由が「その他」ばかりの CRM からは、何も掘り起こせません。再アプローチは、相手か自社のどちらかに新しい理由が 1 つあるときだけにしましょう。

解約したお客様の担当者も、掘り起こしの対象になります。特にサービスを使いこなしていた人は、転職先で同じ課題に出会うことが多いです。担当者を企業とは別のエンティティにしているのは、このためでもあります。担当者の行に転職先の企業を新しく紐づければ、転職先を新しい見込み客として一覧に載せることができます。転職の事実は本人の公開プロフィールの更新や転職先の公式サイトの発表で確かめ、確かめられない噂をもとに登録しないようにしてください。文面は、解約したときの理由（選択式で残してあるもの）を踏まえて書きます。例えば理由が価格だった場合は、転職先の規模であれば価格の条件が変わるかどうかを聞く形になります。

重複排除・除外リスト・アドレスの検証

見つけたリードは、登録する時点で CRM の企業と名刺に突き合わせます。キーは法人名＋ドメインです。既存クライアント、アプローチ済みの相手、お断りを受けた相手は除外リストに入れ、リストを作るたびに適用します。また、この処理は冪等（何度実行しても結果が同じになること）にしておく必要があります。定期実行は同じ処理が再実行されることがあり、突き合わせが無いと同じ会社が毎朝増えていってしまいます。登録する行には、必ずステータス「未接触」とチャネルと出典 URL を入れてください。

アドレスの検証も、登録する時点で行います。名刺や公開情報から集めたアドレスには、退職した人のアドレス、使われなくなったドメイン、打ち間違いが混ざっています。検証せずに送ると、リストの 4 割が無効なアドレスだったとしても気づかないまま、届かないメールを大量に送ることになります。しかも、届かないだけでは済みません。無効なアドレスへの送信（バウンス）が続くと送信元のドメインの評判が下がり、有効な相手にもメールが届かなくなります（後の「送信ドメインを分ける」）。

検証は文面を書く前に、費用のかからない順に行います。最初は形式の検査（アドレスの文法が正しいか）です。次にドメインの MX レコード（そのドメインがメールを受け取るサーバーを持っているか）を確認します。これは DNS に 1 回問い合わせるだけで分かり、相手には何も送信されません。MX が無いドメインにはどんな文面を書いても届かないので、その行には調査も文面の生成も行いません。そのうえで、個人向けの無料メール（gmail.com など）と役割アドレス（info@・sales@ など）にラベルを付けます。前者は BtoB では担当者を特定できず、後者は担当者個人ではなく窓口のアドレスだからです。1 件ずつ有効かどうかを確かめる有償の検証サービスもありますが、ここまでの無料の検査で落とせる行を先に落としてから使いましょう。検証の結果（有効・無効・不明・役割アドレス）は担当者の行に日付付きで残し、不明のまま送らないようにします。

優先順位はスコアで付け、ICP は受注から逆算する

リストが増えてくると、営業が上から順に連絡していくための順番が必要になります。順番を人の勘で決めると担当者ごとに変わり、AI に「有望な順に並べて」と頼むと日によって変わってしまいます。そのため、リードスコアリングは後で説明する停滞検知と同じく、決定的な計算（同じ入力からは必ず同じ結果が出る計算）で行います（原則 Q）。材料は 3 種類です。1 つ目は ICP（理想の顧客像。自社が受注しやすく、成果を出しやすい会社の条件）への適合で、業種・規模・地域・使っている予約サイトなど、企業の属性を見ます。2 つ目はシグナルの温度で、前の節で付けた高・中・低と、観測してからの経過日数を見ます。3 つ目はこちらへの反応で、返信・資料の閲覧・フォームの送信を見ます。重みは設定の 1 箇所に置き、点数と一緒に「何点がどこから来たか」の内訳を出すようにします。内訳の無い点数は、営業担当が信用できないからです。

# リードスコアの重み。並び替えも営業への引き渡しも、ここだけを読む
fit:                                  # ICP への適合（企業の属性）
  - {when: 業種が 宿泊・飲食・美容 のいずれか, points: 20}
  - {when: 店舗数が 1〜10, points: 10}
  - {when: 予約サイト経由の比率が 70% 以上, points: 15}
signal:                               # 温度（観測から 30 日で失効）
  - {when: 高, points: 30}
  - {when: 中, points: 15}
  - {when: 低, points: 5}
engagement:                           # こちらへの反応
  - {when: 返信があった, points: 25}
  - {when: 料金ページを見た, points: 10}
handoff_threshold: 60                 # 以上を営業に渡す。未満は育成へ

点数は足し算で出し、掛け算や例外の分岐は入れないようにしましょう。分岐が増えるほど、なぜその順番になったのかを説明できなくなります。閾値を超えた行だけを営業に渡し、超えない行は自動のフォローアップ（後の「シーケンスとキャパシティ」）で育成します。重みを変えたときは、日付と理由を記録してください。シグナルの定義と同じく、順位が動いたときに、相手が変わったのか重みが変わったのかを区別するためです。

重みの根拠は、自社の受注データにあります。ICP の資料は「こういう会社に売りたい」という願望で書かれることが多く、実際に受注した会社の共通点とはずれていることがよくあります。そこで、受注した全アカウントと失注したアカウントを 1 行 1 社の表にし、属性の列を並べて、受注した側に偏っている属性を探します。これは第 2 章で説明した構造化データの扱い方そのものです。AI に「受注の共通点を見つけて」と頼めば仮説は出てきますが、失注した側にも同じ属性があるかどうかを確かめないと、単にその業界に多いだけの属性を「受注の共通点」と読み違えてしまいます。受注と失注の両方の表で差が出た属性だけを採用するようにしましょう。こうして見つかる属性は、業種や規模といった ICP の資料の項目とは別のところに現れることが多いです。例えば「予約の 8 割以上が予約サイト経由」「オーナー自身が SNS を投稿している」「開業から 3 年以内」のような形です（例は架空です）。ICP の資料に無い属性が 3 つ見つかれば、それがそのまま上のスコアの適合の項目になり、企業調査で確かめる観点にもなります。

相手を調べる

ここでは、第 3 章で紹介した企業調査・事例調査の方法を、営業の観点で使います。目的は、「何を伝えれば会ってもらえるか」と「会ったときに何を聞くか」の 2 つを決めることです。

1 社の深掘りは Web だけで成立させ、CRM で強化する

企業調査は、Web 検索だけでも必ず成立する形にしておきます。CRM や議事録に過去の接点があれば精度は上がりますが、それが無いことを理由に調査を止めないようにします。

レポートの構成は固定します。構成を固定するのは、読む側が毎回同じ場所で同じ情報を探せるようにするためで、書く側の都合ではありません。冒頭には「どんな会社か、なぜ自社を必要とする可能性があるか、最適な切り口は何か」を 2〜3 文で置き、忙しい人はそこだけ読めば済むようにします。続いて、企業プロフィール（事業内容・規模・直近 90 日のニュース・採用シグナル）と、キーパーソン（役職・経歴・公開されているインタビューと、話のきっかけ）を書きます。店舗型ビジネスであれば、各 SNS の運用状況と、予約サイト・グルメサイト・美容ポータルへの掲載と口コミ、多言語対応の有無を 1 つの節にまとめます。そのうえで、ポジティブな根拠、懸念、初回の商談で確認する不明点といった評価を、事実とは分けて書きます。最後に推奨アプローチとして、最初に話す相手、最初の話題、聞く質問を 3 つ書いて締めます。評価と事実を同じ段落に混ぜないことがポイントです。混ぜてしまうと、読む人が「これは調べた事実なのか、推測なのか」を 1 行ずつ判断しなければならなくなります。

調査の観点は、「誰が何を売るための調査か」によって変わります。店舗型ビジネスなら SNS と掲載チャネル、BtoB なら顧客セグメントと、採用から読み取れる投資の領域、自治体なら所管の部署と調達の方式、といった具合です。観点が分からないときは推測で決めず、先に確認しましょう。件数の上限も先に決めておきます（目安は 1 社あたり検索 10 クエリまで）。Instagram と TikTok の数字は、エージェントに取りに行かせないでください。規約で自動収集が禁止されているので、人が画面で確かめた数字を渡すか、「未取得」のまま進めます。

依頼の文面にすると、例えば次のようになります。目的・観点・上限・出力の形・やってはいけないことを、すべて 1 通の中に書いています。

来週の火曜に、〇〇温泉の「A 旅館」（https://www.example.com）と初回の商談があります。
商談前の企業調査をしてください。

- 当社について: 宿泊施設・飲食店向けに、SNS 運用と広告運用を代行しています。
- 目的: 初回の商談で「最初に何を話すか」と「何を聞くか」を決めること。
- 見る観点: 各 SNS の運用状況（フォロワー数・直近の投稿頻度・縦型動画の有無）、
  予約サイトと口コミサイトの掲載と評価、多言語対応の有無、直近 90 日のニュース、採用募集。
- 過去の接点: CRM を読める場合は、この旅館の過去の商談と議事録を検索して取り込んでください。
  読めない場合は Web だけで進め、情報源の欄にそう書いてください。
- 上限: Web 検索は 10 クエリまで。Instagram と TikTok の数字は私が画面で確認して下に貼ります。あなたがページを自動で開いて取りに行かないでください（利用規約で禁止されています）。
- 出力: 冒頭に 3 文以内の要約。続けてプロフィール、SNS と掲載の状況（表）、
  評価（良い兆候・懸念・商談で確かめる不明点）、推奨アプローチ（最初に話す相手・最初の話題・質問 3 つ）。
- 禁止: 取れなかった数値を推測で埋めないこと。「未取得」「未確認」と書いてください。
  SNS のアカウントが見つからない場合も「運用していない」とは断定しないこと。
  CRM には書き込まないこと。

同じ相手について、次のように頼むこともできます。

A 旅館について調べておいて。

この依頼でも調査は始まります。しかし、何のための調査なのかが書かれていないので、エージェントは会社概要や沿革を丁寧にまとめて終わることが多くなります。商談で聞く質問も、SNS の実数も出てきません。見つからなかった SNS を「運用していない」と書いてしまうこともあります。先ほどの依頼の最後に禁止事項を並べているのは、このような誤りを先に防ぐためです。

取れなかったものは「未取得」と書きます（原則 C）。SNS の実数が見えなかったときに「運用していない」と断定してしまうと、その 1 行が事実として提案資料まで引き継がれてしまいます。「未確認」と「存在しない」は別の状態として扱う必要があります。

CRM の過去の接点は、読み取り専用のツールで検索して取り込みます。取り込むのは、ステータス・確度・担当者・次アクション・過去の受注と失注の理由・既知の連絡先です。データの構造を推測してクエリを書くのではなく、一覧を取得して実際の中身を確かめてから読むようにしましょう。連携が無い場合は「連携が未設定」として Web だけで進め、レポートの「情報源」の欄にそのことを書きます。

とはいえ、毎回この長さの依頼を書くのは手間がかかります。そこで、繰り返す部分はスキル（第 2 章で説明した手順書）にまとめ、依頼文には相手と目的だけを書けば済むようにします。次は企業調査のスキルの骨子です。調べて書くだけで、CRM には書き込まない形にしています。

---
name: company-brief
description: >-
  商談やアプローチの前に、見込み客の企業・店舗・人物を調べて 1 本のレポートにする。
  「〇〇を調べて」「商談前に〇〇について教えて」「見込み客の下調べをして」で使う。
  Web 検索だけで成立し、CRM を読めれば過去の接点も取り込む。
  ※事例集めは事例調査のスキル、自社の SNS アカウントの採点はアカウント監査のスキル、
  営業文面はアウトリーチのスキル。このスキルは調べて書くだけで、CRM に書き込まない。
---
# 見込み客の企業調査

## 最初に確定すること
- 誰が何を売るための調査か（自社の商材・相手の業種・今回の目的）。
  分からなければユーザーに 1 回だけ確認する。推測で観点を決めない。
- 件数の上限（既定: Web 検索 10 クエリまで）。

## 手順
1. 公式サイトと直近 90 日のニュースを調べる（この手順は必ず成立する）。
2. 業種別の観点を足す（店舗型: SNS・予約サイト・口コミ・多言語対応・採用）。
3. CRM を読み取り専用のツールで検索し、実体を確かめてから本文を読む。
   連携が無い・読めないときは Web だけで続け、「情報源」にその旨を書く。
4. SNS の実数は、利用者が画面で確認した記録か画面写しから読む。Instagram と TikTok を自動で開かない（規約で禁止）。記録が無い項目は「未取得」、アカウントが見つからない場合は
   「未確認」と書く。「運用していない」と断定しない。
5. 事実と評価を分けて統合する。評価の段落に調べた事実を混ぜない。

## 出力の型
要約（3 文以内）/ プロフィール / SNS と掲載の状況（表）/
評価（良い兆候・懸念・不明点）/ 推奨アプローチ（最初に話す相手・最初の話題・質問 3 つ）/ 情報源

## 縮退先
- SNS の記録が無い: 該当欄を「未確認」とし、プロフィール画面の
  スクリーンショットを提供してもらう依頼を 1 回だけ出す。
- 公開情報がほとんど無い: 分かった範囲で出し、商談で聞く質問を多めに書く。

このスキルの範囲は「調べて書くだけ」です。description の末尾で、CRM には書き込まないと宣言しています。調査のついでに CRM を更新させると、確認を通らない書き込みが生まれ、「調べて」と頼んだだけの人の CRM が書き換わってしまうからです。事例集め・自社アカウントの採点・営業文面を別の手順書に分けているのは、「調べて」という言葉がどの依頼にも付くためです。文面まで 1 つの手順書に入れてしまうと、調査を頼んだ人に営業文が返ってきます。反対に、文面を量産するときにエンジンが検索を始めてしまうことも起こります。

手順の最初で「誰が何を売るための調査か」を確定させ、分からなければ 1 回だけ聞くようにしています。先ほどの「A 旅館について調べておいて」の例を思い出してください。目的の無い調査は会社概要と沿革を丁寧にまとめて終わってしまい、商談で聞く質問も SNS の実数も出てきません。また、手順 1 の「必ず成立する」と、手順 3 の「Web だけで続け、情報源にその旨を書く」は、CRM が読めないというだけで調査全体が止まらないようにするための記述です。別の経路を自作して読みに行く分岐は、あえて書いていません。無いものを探しに行く手順は、それらしい数字を作り上げてしまう原因になるからです。

手順 4 では「未取得」と「未確認」を書き分けさせ、「運用していない」と断定しないように明記しました。見えなかった SNS を「存在しない」と書いた 1 行は、事実として提案資料まで引き継がれてしまいます（原則 C）。縮退先の節も省くことはできません。省いてしまうと、SNS を開けない環境ではこの手順書が「確認できませんでした」の一文で止まってしまいます。スクリーンショットの依頼は 1 回だけにし、公開情報が少ないときは商談で聞く質問を多めに書きます。この調査の目的は「会ったときに何を聞くか」を決めることなので、材料が少なくても、質問であれば成果物として残せます。

大型の見込み客は経営計画と財務から読む

上場企業、チェーンの本部、自治体のように規模の大きい相手の場合は、上のレポートの構成に 3 つの観点を足します。個人経営の店舗や中小規模の案件であれば、基本の構成で十分です。すべての観点を毎回調べると、レポートが長くなるだけで読まれなくなってしまいます。

その前に、業種ごとに見る観点を表にしておきます。上で挙げた店舗型ビジネス・BtoB・自治体に、EC（通販）を加えた 4 つです。

1 つ目の観点は、中期経営計画の数値目標と実績の差です。中期経営計画（3〜5 年の経営目標を示した計画）や決算説明資料には、会員数・売上・店舗数などの目標値が載っています。直近の実績を決算短信や有価証券報告書から拾い、達成率と不足分を計算します。差は「目標 30 万人に対して実績 21 万人、9 万人不足」のように数字で書きましょう。そのうえで、差から読み取れる経営課題を 1 行にまとめます。例えば「会員の獲得が伸びていない → 新しい集客経路の開拓が経営課題になっている可能性がある」といった形です。「未達です」と指摘するだけでは提案につながらないので、何があれば差が埋まるのかまで書くようにします。計画の中に名前の付いた重点施策があれば、その進み具合も同じように数字で確かめます。

2 つ目の観点は財務の余力です。自己資本比率・現預金・営業キャッシュフローを、会社の健全性の指標としてだけでなく、マーケティングに投資する余力の目安として読みます。余力が大きい会社は新しい投資を決めやすい、という仮説が立てられます。反対に余力が小さい会社には、初期費用を抑えた試行のプランを先に用意しておきます。ただし、これはあくまで推測です。レポートでは、事実（数値と出典の年度）と、そこから立てた仮説を分けて書いてください。

3 つ目の観点は、相手自身の SNS の状況を媒体ごとに評価することです。媒体ごとにアカウントの有無・フォロワー数・投稿頻度・直近の反応を並べ、◯（運用できていて反応がある）、△（アカウントはあるが更新が止まっている）、✕（アカウントが無い、または実質的に動いていない）を付けます。✕ の媒体や、競合も含めて誰も手を付けていない切り口は、提案の候補として番号付きで並べます。このとき、相手の欠点としてではなく、先に始めれば先行できる領域として書くようにしましょう。第 3 章の競合分析で自社に対して行った評価を、相手の会社に当てはめたものです。

出力の型は次のとおりです。数字はすべて架空です。

■ 中期経営計画の目標と実績（出典: 決算説明資料 2025 年度）
指標          目標（2027 年度）  実績（2025 年度）  達成率  不足分
会員数        30 万人            21 万人            70%     9 万人
EC 売上比率   20%                11%                55%     9 ポイント
→ 会員の獲得が伸びていない。新しい集客経路の開拓が経営課題になっている可能性がある（仮説）

■ 財務の余力（出典: 有価証券報告書 2025 年度）
自己資本比率 58%、現預金 42 億円
→ 新しいマーケティング投資を決める余力はあると推測できる（仮説）

■ SNS の状況（取得日: 2026-09-20）
媒体        アカウント  フォロワー  投稿頻度  直近の反応  評価
Instagram   あり        8,200       月 2 回   低い        △
TikTok      未確認      未取得      未取得    未取得      未確認
YouTube     なし        -           -         -           ✕

■ 誰も手を付けていない領域（提案の候補）
1. 縦型動画での客室紹介（競合 3 社も未着手）
2. 外国人客に向けた英語の投稿

TikTok の行を ✕ にせず「未確認」にしているのは、アカウントを確かめられなかっただけで、アカウントが無いことを確かめたわけではないからです。✕ を付けてよいのは、無いことを確かめたときだけです。

課題に効く事例を集める

提案で納得してもらえる型は、「これをやったことがあります」と「他社でこれが成果を出していて、自社でも再現できます」の 2 つしかありません。事例調査は、この 2 つの材料を 1 回で揃えるための作業です。

自社の実績は社内の正本（案件データベース・議事録・実績レポート）から取り、出典は後から開ける実際の URL で残します。他社の事例は、支援会社が公開している導入事例ページを、一覧から詳細、ページ送りまで最後まで辿ります。検索結果の記事 1 本で満足しないところが、一般的な調査との違いです。とはいえ、すべてを無制限に精読するわけではありません。一覧は全件辿るものの見出しと業界だけを抜き出す浅い確認と、与件に合う本命の事例だけを精読する確認の 2 段階に分け、上限（目安は 5 社×5 件）を先に決めておきます。「もっと見る」を押しても URL が変わらない一覧は最後まで取得できないので、「一覧 N 件中 M 件を確認」と母数を書きましょう。母数を書かずに「主要な事例」とだけ書くと、すべてを網羅したように読めてしまいます。

同じ事例が支援会社と事業会社の両方から出てきた場合は、「事業会社名×施策×時期」をキーにして 1 件にまとめ、事業会社側の発表を正とします。再現できるかどうかは、自社の資産（体制・提携先・実績資料）に照らして高・中・低で付けます。目立たなくても再現できる事例のほうが、華やかでも再現できない事例より、提案の材料としては強くなります。

与件を構造化してから探す

事例調査の精度は、与件（相手が抱えている課題と前提条件）をどれだけ絞り込めるかで決まります。探し始める前に、次の 6 項目を埋めておきましょう。足りない項目は議事録から補うか、依頼した人に確認します。

与件:
  対象: 温泉旅館（客室 30 室・個人経営）
  課題: 平日の稼働率が低い。予約の 8 割が予約サイト経由
  目的の指標: 平日の直接予約数
  施策の種類: [インフルエンサーの起用, アカウント運用]
  ターゲット: 首都圏に住む 30〜40 代の夫婦
  制約: 月の予算は 30 万円まで。撮影は平日のみ

施策の種類が複数ある場合は、種類ごとに分けて調べます。与件は、絞りすぎても広げすぎても役に立ちません。例えば「旅館の SNS 事例」で探すと出てくる事例が浅く、提案に使える数字までたどり着けません。「温泉旅館がインフルエンサーの起用で平日の直接予約を増やした事例」まで絞り込むと、課題と施策と成果が揃った事例が見つかります。

調査先を 4 種類に分ける

調査先は 4 種類あります。1 種類だけを見ていると、集まる事例が偏ってしまいます。

あわせて、調べる時期の範囲も過去に広げます。数年前に成果が出た同じテーマの施策も、いまでも使える材料になります。テレビ番組や海外の配信番組で成功した企画の形式を、SNS の施策に応用できることもあります。

事例は 1 件ずつ同じ形式で記録します。数字の無い事例（「成果が出ました」とだけ書かれたもの）は優先度を下げましょう。提案の場で「どれくらい効果があるのか」と聞かれたときに答えられないからです。次は記録の例です（架空の事例です）。

- タイトル: 温泉旅館 × 旅行系インフルエンサー 3 名の平日宿泊企画
  主体: 事業会社の発表（支援会社の事例ページにも掲載）
  施策の種類: インフルエンサーの起用
  課題: 平日の稼働率
  施策: 平日限定プランを 3 名が宿泊レポートで紹介
  成果: 平日の直接予約が前年同月比 +38%（事業会社の発表）
  出典: https://www.example.com/news/（取得日 2026-09-20）
  与件との近さ: 高
  再現できるか: 中（すぐに依頼できるインフルエンサーは 2 名まで）
  提案での使い方: 「平日限定プラン × 2 名の宿泊レポート」に縮めて提案する

レポートでは、この記録を並べる前に、提案の切り口を結論として先に書きます。「自社でやったことがある」型と「他社で成果が出ていて自社でも再現できる」型の、どちらで提案するかです。最後に調査の記録（どの会社の事例を何件見たか、見ていない範囲、次に調べる価値があるもの）を付けます。見ていない範囲を書かないと、読む人は網羅的な調査だと受け取ってしまいます。

社内の実績の置き場所（案件の台帳・議事録・実績レポート）が分からないときは、1 回だけ聞きます。聞いても分からなければ他社の事例だけで進め、レポートにそのことを書きます。取得できなかった社内の実績を「実績なし」と書いてはいけません。読めなかったことと、実績が無いことは別の事実です。

与件の埋め方から調査の記録までを手順書にしておくと、案件が替わっても同じ順番で事例を集めることができます。

---
name: case-research
description: >-
  与件（相手の課題）を起点に、他社の事例と自社の実績を両方集め、
  再現できるかを付けて提案材料にする。
  「事例を集めて」「好事例を調べて」「類似事例はある？」で使う。
  ※相手企業そのものの調査は企業調査のスキル。
---
# 事例調査

## 先に埋める与件（6 項目）
対象 / 課題 / 目的の指標 / 施策の種類 / ターゲット / 制約。
足りなければ議事録から補うか、依頼した人に 1 回だけ確認する。

## 手順
1. 調査先を 4 種類に分ける（支援会社 / 事業会社 / 業界メディア / 広告のアーカイブ）
2. 2 段階で読む：一覧は見出しと業界だけ、与件に合う本命だけ精読。
   上限は 5 社 × 5 件
3. 同じ事例が複数の出どころから出てきたら、
   「事業会社名 × 施策 × 時期」で 1 件にまとめ、**事業会社側の発表を正とする**
4. 1 件ずつ同じ形式で記録する（主体・課題・施策・成果・出典と取得日・
   与件との近さ・再現できるか・提案での使い方）
5. 数字の無い事例は優先度を下げる

## 守ること
- 一覧が最後まで辿れないときは「一覧 N 件中 M 件を確認」と母数を書く
- 社内の実績が読めなかったときに「実績なし」と書かない
- 見ていない範囲を調査の記録に必ず書く

この手順書が担当するのは、他社の事例と自社の実績を 1 回で揃えるところまでで、相手企業そのものは調べません。提案で納得してもらえる型は「やったことがある」と「他社で成果が出ていて再現できる」の 2 つしかないので、材料を片方しか集めない手順書にすると、提案の型が最初から 1 つに絞られてしまいます。相手企業の調査は企業調査の手順書に分けています。「事例を調べて」と「〇〇を調べて」を同じ手順書で受けると、出力の型が混ざってしまうからです。案件ごとに変わるのは与件の 6 項目だけなので、そこは依頼文か議事録から埋め、調査先・読み方・上限・記録の形式は手順書に置いています。

与件を手順より前に置いているのは、事例調査の精度が与件の絞り込みで決まるからです。「旅館の SNS 事例」で探しても浅い事例しか出てこず、提案に使える数字までたどり着けません。調査先は 4 種類に分けました。1 種類だけを見ていると、集まる事例が偏ってしまうからです。支援会社の事例ページと当事者の数字が食い違うこともあり、その場合は事業会社側の発表を正とします。再現できるかどうかも必ず付けさせます。目立たなくても再現できる事例は、華やかでも再現できない事例より提案の材料として強いからです。数字の無い事例の優先度を下げるのは、提案の場で「どれくらい効果があるのか」と聞かれても答えられないためです。

守ることの 3 行で防ぎたいのは、どれも「網羅したように読めてしまう」失敗です。母数を書かずに「主要な事例」とだけ書くと、最後まで取得できなかった一覧も全件確認したように読めます。見ていない範囲を書かなければ、読む人は網羅的な調査だと受け取ります。社内の実績が読めなかったときも「実績なし」とは書きません。読めなかったことと、実績が無いことは別の事実だからです。

業界の数字は出典付きの正本から引く

業界のペイン、出典付きの数値、経営者の生の声、想定される反論と回答、ヒアリングの設計は、案件ごとに調べ直すものではなく、業界ごとに 1 箇所へ集めておく資産です。Web で調べ直すたびに、出典が変わってしまうからです。

集めるときに守るべきことは 2 つあります。1 つ目は信頼度ラベルです。一次確認済み・二次記事経由・推計値・調査年・サンプル数を、文面やスライドに移すときも一緒に引き継ぎます。推計値を断定の表現に変えてはいけません。2 つ目は「使ってはいけない数値」をはっきりさせておくことです。Web に大量に出回っているのに一次出典が確認できない数字は業界ごとに一覧にしておき、他社の提案資料に使われていても使いません。反対に「出典を確認できなかったので載せていません」と自分から伝えると、残りの数字の信頼度が上がります。また、実名での対応や失注理由のような社内メモは、正本の中に置く場合でも外部に出さない区画に分けておきましょう。

複数の会社をまとめて調べる

アウトリーチの入力 CSV を埋めるときのように、20 社、30 社をまとめて調べる場面もあります。メインの会話で 1 社ずつ調べると、読んだページの本文でコンテキスト（AI が把握する文章量）が埋まってしまい、後半の会社ほど判断が粗くなります。そのため、調査はサブエージェントに分けて行い、メインの会話は結果の確認を担当します。返す項目の決め方、同時に動かす数、ブラウザのように 1 つしかない道具の扱い方は第 2 章の「委譲するときは、返す形を先に決める」で、検索の回数と打ち切りの決め方は第 3 章の「検索の組み方と打ち切り」で詳しく説明しています。営業の調査で付け加えるのは、返す項目をアウトリーチの入力 CSV の列に合わせておくことです。

委任するときの依頼文は、例えば次のように書きます。

次の 5 社について、アウトリーチの下調べをしてください。
1 社ずつ調べ、下の形式だけを返してください。ページの本文や検索結果の一覧は返さないでください。

対象: （会社名とドメインを 1 行ずつ）

返す形式（1 社ごと）:
company_name: 正式名称
domain: 公式ドメイン
recent_fact: 直近 90 日の出来事を 1 つ（無ければ「なし」）
recent_fact_url: その出典の URL と取得日
sns_status: 媒体ごとのアカウントの有無（確かめられなかった媒体は「未確認」）
notes: 取れなかった項目とその理由

ルール:
- 1 社あたり検索は 5 回まで。同じサイトへのアクセスは間隔を空ける。
- 取れなかった項目は推測で埋めず「未取得」と書く。Instagram と TikTok のページは開かない（アカウントの有無は検索結果で確かめる）。

返ってきた recent_fact は、後で書く文面の書き出しの根拠になります（アウトリーチの節で説明する入力 CSV のリサーチメモの列）。出典の URL が無い行は、文面の根拠には使いません。

埋まらない項目は、問い合わせる提供元を順番に変えながら埋めていきます（ウォーターフォール。決めた順番で問い合わせ、埋まった時点で止める方式）。企業の属性（業種・従業員数・所在地・担当者のアドレス）は、1 つの提供元だけでは揃いません。公式サイトで取れるもの、法人番号の公開データで取れるもの、有償のデータベースで取れるもの、というように提供元ごとに得意な項目が違い、同じ項目でも情報が欠けている会社が違うからです。そのため、項目ごとに提供元の順番を決め、先頭から問い合わせて、埋まった時点で止めます。順番は、無料で信頼度の高いもの（公式サイト・公的な公開データ）を先に、有償のものを後に置きます。後ろに置くほど呼び出される回数が減るので、費用を抑えることができます。どの提供元で埋まったかは、項目ごとに出典の列に残しておきます。提供元によって定義が違う項目（従業員数が連結か単体か、グループ全体か、など）は、混ぜると比較できなくなるので、定義ごとに列を分けます。すべての提供元を試しても埋まらなければ、「未取得」のままにしておきます。

商談前のブリーフ

商談の準備は、会社名とミーティングの種別さえあれば作れる形にしておきます。CRM から取るのは、ステータス・次アクション・前回の議事録に残った約束事と未解決の質問・出てきた反論です。Web で足すのは、直近 30 日のニュースと参加者の公開情報です。出力は、アカウントの概要、面談相手ごとの役割と話のきっかけ、これまでの経緯（未完了の約束を含む）、推奨するアジェンダ、ディスカバリーの質問（相手の状況と課題を聞き出す質問）、想定される反論と回答です。

質問は、業種ごとに定番のものを用意しておきます。店舗型ビジネスであれば、集客の現状、客層と外国人客の比率、困っているのが集客なのか採用なのか認知なのか、使っている予約サイト・掲載サイト、誰が意思決定をするか、といった質問です。力を入れる点はミーティングの種別によって変わります。初回は話すより聞くことを優先し、定例では提供した価値と拡大の機会に重点を置きます。

依頼の例です。2 回目の商談で、前回の議事録が CRM にある場合を想定しています。

明日 14 時からの、駅前の美容室「B ヘアサロン」とのオンライン商談の準備をしてください。

- 種別: 2 回目（前回はヒアリング。今回は提案を見せる）。
- 参加者: 先方はオーナーと店長の 2 名、当社は営業 1 名。
- CRM から取るもの: 商談のステータス、次アクション、前回の議事録にある約束事・
  未解決の質問・出た懸念。読めない場合は、私が前回のメモを貼ります。
- Web で足すもの: 直近 30 日のニュースと、店の SNS の最近の投稿。
- 出力（1 画面で読める長さ）: ①前回の約束のうち未完了のもの ②今回のゴール 1 つ
  ③アジェンダ（30 分の時間配分つき） ④確認する質問 5 つ ⑤想定される懸念と答え方
- 前回の懸念は「費用」と「撮影の手間」でした。この 2 つへの答え方は具体的に書いてください。

依頼では、前回の約束のうち未完了のものを先頭に出させています。約束を忘れたまま次の商談に入ると、提案の中身を聞いてもらう前に信頼を失ってしまうからです。懸念への答え方を「具体的に」と指定しているのは、指定しないと「費用対効果をご説明します」のような、中身の無い回答案が返ってくるためです。

依頼のたびにこの長さを書かなくて済むように、ブリーフの型を手順書にしておきます。

---
name: call-prep
description: >-
  商談の前に、CRM の経緯と Web の直近情報から 1 画面のブリーフを作る。
  「〇〇との商談の準備をして」「明日の打ち合わせの準備」「〇〇の商談準備」で使う。
  会社名とミーティングの種別だけで成立し、CRM を読めれば前回の約束と懸念を取り込む。
  ※初回接触前の深掘りは企業調査のスキル、商談の後は議事録要約のスキル。CRM には書き込まない。
---
# 商談前のブリーフ

## 最初に確定すること
会社名 / ミーティングの種別（初回ヒアリング・提案・交渉・定例）/ 参加者 / 背景メモ（あれば）。
種別で力点が変わる: 初回は話すより聞く、定例は提供した価値と拡大の機会。

## 手順
1. CRM を読み取り専用で引く: ステータス・次アクション・担当者・流入元。
   議事録データベースから前回の約束事・未解決の質問・出た反論・競合への言及
2. 資料置き場から過去の提案資料を探す（無ければ「なし」）
3. 業界の正本（ペイン・出典付きの数値・定番のヒアリング項目・想定反論）を Web より先に引く。
   正本に揃っている材料を Web で調べ直さない
4. Web で足す: 直近 30 日のニュース、参加者の公開情報、店の SNS の最近の投稿
5. 足りない情報は推測で埋めず、**商談で確認する質問に変える**

## 出力の型（1 画面）
前回の約束のうち未完了のもの / 今回のゴール 1 つ / アカウント概要（表）/ 面談相手ごとの役割と話のきっかけ /
アジェンダ（時間配分つき）/ 確認する質問 5 つ / 想定される懸念と**具体的な**答え方 / 社内メモ

## 縮退先
- CRM が読めない: 会社・種別・参加者・背景の 4 つを聞き、Web だけで作る。前回のメモは貼ってもらう
- 公開情報が薄い: 質問を多めに出す（ブリーフの目的は「何を聞くか」を決めること）

この手順書は、会社名と種別だけで成立し、CRM が読めれば中身がより充実する形にしています。初回接触前の深掘りは企業調査に、商談の後は議事録要約に分けました。「準備して」の一言で呼び出される手順書に、調査レポートや議事録の形式まで持たせてしまうと、1 画面に収まらなくなるからです。未完了の約束を出力の先頭に固定することと、足りない情報を質問に変えさせることの理由は、上の依頼の例で説明したとおりです。業界の正本を Web より先に引かせているのには、別の理由があります。同じ業界の数字を商談のたびに Web で調べ直すと出典が変わってしまい、先週のブリーフと今週のブリーフで違う数字を話すことになるからです。縮退先の「質問を多めに」は、公開情報が少ない相手ほど、商談で聞くべきことが多くなるためです。材料が少なくても、質問であれば成果物として残せます。

アウトリーチを量産する

アウトリーチ（こちらから連絡する営業）は、文面を書くところまでは自動化できますが、送るところは人が判断する領域です。

1 社を丁寧に書く

まず相手を調べ、それから文面を書きます。汎用の文面を送る工程は作りません。フック（書き出しで相手の関心を引く材料）の優先順位は、相手のトリガーイベント（出店・受賞・採用）、共通のつながり、相手が公開しているコンテンツ、会社の取り組み、役職から推測される課題、の順です。構成は、相手に合わせた書き出し、相手の課題を 1〜2 文、近い業種の実績を 1 件、心理的なハードルの低い依頼（CTA。行動を促す一文）を 1 つ、とします。本文はプレーンテキストにして、太字や見出しの記法は使いません。フォームに貼り付けたときに、記号がそのまま表示されてしまうからです。

やってはいけないことも決めておきます。定型の挨拶で始めること、機能を羅列すること、「貴社にお勤めとのことで」のような見せかけのパーソナライズ、出典の怪しい業界の数字を使うこと、の 4 つです。

相手についての事実を 1 つ根拠にした依頼の例です。

C 旅館（https://www.example.com）の問い合わせフォームに送る、初回の営業文面を書いてください。

- 根拠にする事実（1 つだけ）: 先月、公式サイトで露天風呂付き客室の新設を発表している。
  書き出しはこの事実に触れ、発表ページに書かれていないことは書かないでください。
- 課題の仮説: 新しい客室の認知を、予約サイト以外の経路でも広げたい時期だと考えています。
  断定せず「〜ではないでしょうか」の形で 1〜2 文にしてください。
- 実績: 下の承認済みリストから、宿泊施設の事例を 1 件だけ使ってください。
  リストに無い数字や施設名は使わないこと。
  （承認済みの実績リストを貼る）
- 依頼（CTA）: 15 分のオンライン面談の打診。日程の候補は書かない。
- 形式: プレーンテキストで 400 字以内。件名の案を 3 つ。太字や見出しの記法は使わない。
- 送信はしません。文面と、根拠にした事実の出典 URL だけを返してください。

足りない依頼の例も並べます。

旅館向けの営業メールのテンプレートを作って。うちの実績も入れておいて。

後者の依頼には、宛先についての事実が 1 つもありません。そのため、書き出しは「貴館のますますのご発展を」のような定型の挨拶になり、どの旅館に送っても同じ文面になってしまいます。実績の中身も渡していないので、エージェントがもっともらしい実績の数字を作ってしまうこともあります。前者の依頼で実績を「承認済みリストから 1 件」に限っているのは、このような捏造を防ぐためです。出典 URL を返させておけば、送る前に人が事実を確かめることもできます。

次は、1 社を対話しながら書くための手順書です。次の小節で説明する一括生成とは別のもので、区分ごとの文例の正本はこちらに置きます。

---
name: outreach-draft
description: >-
  1 社を先に調べ、相手の事実 1 つを根拠にした初回の営業文面（フォーム・メール）と
  3 / 7 / 14 日目のフォローを書く。
  「〇〇へのアウトリーチを作って」「〇〇に送るフォーム営業の文面」「〇〇に連絡したい」で使う。
  ※30 社分の量産は一括生成のスキル（文例の正本はこのスキルで、量産側には写さない）。送信は人が行う。
---
# 1 社のアウトリーチ

## 手順
1. 依頼を読む（会社・人物・役職・URL・経路がフォームかメールか）
2. **先に調べる**。公式サイト・直近 90 日のニュース・公開している SNS の投稿から、
   根拠にできる事実を 1 つ見つける。過去の接点があれば CRM を読み取りで引く
3. フックを 1 つ選ぶ。優先順は トリガーイベント（出店・受賞・採用）> 共通のつながり >
   相手の公開コンテンツ > 会社の取り組み > 役職から推測される課題
4. 構成で書く: パーソナルな書き出し（事実 1 つ）→ 課題の仮説 1〜2 文（断定しない）→
   近い業種の実績 1 件（承認済みリストから）→ 心理的ハードルの低い依頼 1 つ
5. 件名 3 案とフォロー 3 通（3 日後: 新しい切り口 / 7 日後: 別の価値 / 14 日後: 最後の 1 通）

## 出力の型
リサーチ要約（相手 / 選んだフック / 根拠の出典 URL）/ 本文（プレーンテキスト）/ 件名 3 案 /
理由（書き出し・フック・実績・依頼をそれぞれなぜ選んだか）/ フォロー 3 通

## 区分ごとの文例（正本はここに 1 つだけ）
コールド / ウォーム（接点あり）/ 再接触（失注・解約の後）/ イベント後（名刺交換）

## 守ること
- 根拠になる事実が見つからない相手には**書かない**（汎用の文面を作る工程は無い）
- 実績は承認済みのリストからだけ。出典の怪しい業界の数字を使わない
- 定型の挨拶・機能の羅列・偽のパーソナライズを使わない。本文に太字や見出しの記法を使わない
- 送信しない。送信の直前に除外リストと「営業目的の投稿お断り」の表示を確認する

この手順書と次の一括生成の手順書は、同じ文面の設計を「対話で 1 社ずつ」と「機械で読める形で 30 社」に分けたものです。区分ごとの文例はこちらに 1 つだけ置き、量産する側には書き写しません。description にそのことを書いておかないと、型を直したときに片方だけが古いまま残ってしまいます。守ることの最初は「根拠になる事実が見つからない相手には書かない」です。「旅館向けのテンプレートを作って」の例がまさにこれで、事実が無いまま書かせると、書き出しは定型の挨拶になり、実績の数字は捏造されてしまいます。フォローの 3 通を最初の 1 通と一緒に書かせているのは、返信の半分以上がフォローアップから来ることも珍しくないからです（後の「シーケンスとキャパシティ」）。3 通をまとめて人が確認して許可すれば、送る時刻が後になるだけで、確認を通っていない文面は 1 通も送られません。

1 行 1 社で一括生成する

量産の設計は 3 段に分けます。上流（調査でリサーチメモを埋める）、エンジン（渡されたデータだけで書く）、下流（フォームへの入力・メールの配信）です。FETC で言えば、上流が Enrich と Transform、エンジンが Create にあたり、下流は FETC の外にあります。エンジンにはリサーチをさせません。1 行ごとに検索をさせると処理が遅く不正確になり、事実の捏造も起きやすくなるからです。パーソナライズの質はリサーチメモの質で決まり、それは上流の責任です。

入力 CSV（1 行 1 社。上流で埋める）
company_name, industry, channel(form|email), segment(cold|warm|event|re-engage),
contact, past_contact, research_notes, urls

出力 CSV（1 行 1 社。そのまま貼れる本文 + 機械可読なメタ）
company_name, channel, subject, subject_alt1, subject_alt2, body,
opening_hook, evidence_case, cta,
personalization_source,   # フックの根拠にした入力列。汎用なら generic
confidence,               # 高 / 中 / 低
needs_review,             # true なら人のレビュー必須
notes                     # 不足データ・要最新確認

メタ列は、品質を検査する項目になります。根拠の列は「本文の具体的な内容がどの入力列に由来するか」を示すもので、捏造していないことの裏付けになります。実績は承認済みのリストからだけ引き、リストに無い数値や固有名が出てきたら差し戻します。リサーチメモが少ない行は、無難な汎用の書き出しにして、要レビューの印を立てます。生成は 1 件ずつ、構造化された形（JSON）で返させ、理由や推論は本文ではなく備考の列に入れさせます。人がレビューするのは要レビューの行だけです。すべての行を読み直す運用にしてしまうと、量産した意味がなくなります。

生成に使ったシステムプロンプトとテンプレートは、成果物と一緒に資産として保存しておきます（原則 P）。次に文面の型を直すとき、前回 AI に何を渡したかを覚えている人はいないからです。

エンジンの部分を手順書にすると、次のようになります。3 段のうち「渡されたデータだけで書く」工程だけを担当し、調査も送信もしない形です。

---
name: outreach-copy
description: >-
  1 行 1 社のデータから、そのまま貼れる営業文面を一括で生成する。
  「営業メールを作って」「フォーム営業の文面を 30 社分」で使う。
  **このスキルは調べない**（渡されたデータだけで書く）。
  ※調査は企業調査のスキル、送信は人が確認画面で許可してから行う。
---
# 営業文面の一括生成

## 入力（1 行 1 社）
会社名 / 業種 / 経路 / 区分 / 宛先 / 過去の接点 / リサーチメモ / 出典 URL

## 出力（1 行 1 社）
件名（主案＋代替 2 案）/ 本文 / 書き出しの根拠 / 使った実績 / CTA /
**根拠にした入力列** / 確信度 / 要レビューの印 / 備考

## 守ること
- 実績は**承認済みのリストからだけ**引く。リストに無い数値や固有名は差し戻す
- リサーチメモが薄い行は、安全な汎用の書き出しに落として**要レビューの印**を立てる
- 本文はプレーンテキスト。太字や見出しの記法を使わない
- 偶然を装ったパーソナライズ（「貴社にお勤めとのことで」）を使わない
- 送信しない。送信の直前に除外リストをもう一度引く

description に「調べない」と太字で書いているのには理由があります。量産のエンジンにリサーチまで持たせると、1 行ごとに検索が走って処理が遅く不正確になり、事実の捏造も起きやすくなるからです。調査を企業調査の手順書に分けているのは、「営業メールを作って」という依頼でこの手順書が呼び出されたときに、検索を始めさせないためです。送信は取り消せない操作なので、人の確認画面に残しました（原則 H）。文例もこの手順書には持たせていません。正本は対話用の手順書に 1 つだけ置いています。量産側に書き写すと、型を直したときに片方だけが古くなってしまうからです。

出力には「根拠にした入力列」を置きました。本文の具体的な内容がどの入力に由来するかを示すこの列が、そのまま捏造していないことの裏付けになります。実績は承認済みのリストからだけ引き、リストに無い数値や固有名は差し戻します。「うちの実績も入れておいて」とだけ頼んだ例のように、エージェントはもっともらしい実績の数字を作ってしまうことがあるからです。リサーチメモが少ない行は汎用の書き出しにして、要レビューの印を立てます。こうしておけば人が読み直すのはその行だけで済みます。すべてを読み直す運用にすると、量産した意味がなくなってしまいます。

「送信しない」には「送信の直前に除外リストをもう一度引く」を添えました。登録してから送信するまでの間に、お断りの連絡が入ることがあるからです。送信を自動化したときに一番起きやすい事故は、送ってはいけない相手に送ってしまうことです。除外リストが古い、お断りが CRM に反映されていない、表記ゆれのせいで同じ企業だと判定されなかった、といった原因は、どれも送信する側が CRM を読まない構成で起きます。相手ごとの事実（リサーチメモ・出典 URL・区分・経路）は入力の 1 行に残し、列の型と禁止事項は手順書に固定しておきます。

シーケンスとキャパシティ

営業のメールは 1 通で終わらせず、シーケンス（複数通の送信計画）にします。例えば、3 日後に新しい切り口、7 日後に別の価値、14 日後に最後の 1 通、という形です。初回の 1 通に返信が無くても、2 通目、3 通目で返信が来ることは多く、返信の半分以上がフォローアップから来ることも珍しくありません。そのため、フォローアップは人が思い出したときに送るものではなく、自動で回る仕組みにしておきましょう。

自動で回す場合、2 通目以降の内容は相手の反応によって変えます（ドリップキャンペーン。決めた間隔で、反応に応じた内容を順に送る仕組み）。分岐の条件は、反応の記録から機械的に決まるものだけにします。例えば、開封も反応も無ければ件名を変えて同じ価値を提案する、リンクを開いていれば開いたページの話題を深めた 1 通を送る、資料を請求していれば営業担当に渡して自動の送信を止める、といった形です。そして、返信があった場合は内容に関係なく、必ずシーケンスを止めます。断りの返信をもらった後に「先日のご提案ですが」というメールが自動で届くと、その会社への営業はそこで終わってしまいます。しかもこれは、仕組みが正しく動いた結果として起きる失敗です。反応の状態は排他・網羅で持ち（未開封 / 開封のみ / リンクを開いた / 返信あり / 停止）、次の 1 通が状態から 1 つに決まるようにします。商談のステータスと同じ作り方です。

分岐ごとの文面は、シーケンスを登録する時点ですべて用意し、まとめて確認して許可します（第 7 章の予約投稿と同じ考え方です。許可したのは文面と宛先で、送る時刻が後になるだけです）。送る直前には、除外リストと「返信があったか」をもう一度確認し、どちらかに当てはまれば送りません。送信の仕組み自体（送信 API の呼び出し、送信の予約、停止の条件、送った事実の接点履歴への起票）は、送信サービスに任せきりにせず、自分で組める規模のものです。自分で組んでおけば、停止の条件と除外の突き合わせを CRM の側に置けます。送信サービスの中だけで停止を判定していると、CRM に入ったお断りを送信側が知らないまま、次の 1 通が送られてしまいます。

文面の質は、件名、冒頭の一文、簡潔さ、CTA の柔らかさと具体性、到達性（スパムとみなされやすい言葉やリンクの多さ）、パーソナライズの信頼性、といった観点から複数の視点で採点します。閾値に届かなければ、弱点を 3 つ直して採点し直します。

送る量は、送れる数から逆算して決めます。担当者数 × 1 人 1 日の送付件数 × 月の営業日数 が月間の送付量で、それに返信率と商談化率を掛けたものが、月に生まれる商談の数です。率は自社の実績から設定し、実績が無ければ最初の月の結果を基準にします。手作業で送る場合は、1 件あたりの調べる時間から現実的な件数を見積もっておくと、計画倒れになりません。

送信のツールは確認の対象にする

送信は取り消すことができません。そのため、送信のツールはパーミッションで確認の対象（Claude Code では ask、claude.ai では「承認が必要」）にし、確認画面で宛先と本文を見てから許可します（原則 H）。確認画面で許可した呼び出しは、表示された内容のまま 1 回だけ実行されます。一括で送る場合は 1 行を 1 回の呼び出しにして、確認画面で各行の宛先と本文を読めるようにします。確認画面に表示されるのはツールの名前と引数だけなので、行の番号だけを引数に渡す作りにはせず、宛先と本文そのものを引数に入れるようにしましょう。また、確認画面での許可は「送ってよい」という判断の根拠であって、除外の確認の代わりにはなりません。送信のツールが CSV だけを読んで CRM の除外リストを見ない構成にはせず、送信の直前にもう一度、送信のツールの側で除外リストを確認します。

法律と規約も設計に組み込みます。執筆時点の理解では、日本の特定電子メール法は広告宣伝メールについてオプトイン（事前の同意）を原則とし、名刺交換や取引関係、公表されているメールアドレスといった例外を設けています。ただし、公表されているアドレスでも「営業目的の送信お断り」と表示されていれば送ることはできません。送信者の名称・住所・受信拒否の連絡先の表示が義務付けられており、拒否を受けた後の送信や送信者情報の偽装は禁止されています。実装する前に、総務省の解説（特定電子メール法）で最新の情報を確認してください。問い合わせフォームは各サイトの利用規約に従い、「営業目的の投稿はお断り」と書かれている相手には送りません。フォームへの入力を自動化する場合も、画像認証などの確認を回避する実装は作らないようにしましょう。

送信ドメインを分ける

営業目的のメールの送信には、会社の本体のドメイン（example.com）を使いません。別に取得したドメイン（example-info.com のような近い名前）か、サブドメインから送ります。理由はドメインの評判です。メールの受信側は、送信元のドメインごとにバウンスの率と迷惑メールの報告を記録していて、評判が悪くなったドメインからのメールを迷惑メールに振り分けます。営業のメールは、どれだけ丁寧に作っても、通常の業務メールより断られる率が高くなります。本体のドメインで送ると、評判の低下が請求書や採用の連絡といった会社のすべてのメールに影響してしまいます。ドメインを分けておけば、影響は営業用のドメインだけで済みます。

分けたドメインには送信元の認証（SPF・DKIM・DMARC。自分のドメインを名乗ってよい送信サーバーを DNS で宣言する仕組み）を設定し、送る量を少しずつ増やしていきます。新しいドメインからいきなり大量に送ると、それだけで迷惑メールと判定されてしまうからです。1 日の送信数の上限を決め、バウンスの率が上がったら送信を止めて原因を調べます。原因の多くは、アドレスの検証をしていないリストです。返信先を本体のドメインの担当者のアドレスにしておくと、返信はいつもの受信箱に届きます。なお、分けたドメインから送る場合も、送信者の名称・住所・受信拒否の連絡先を表示する義務は同じです。ドメインを分けるのは評判を分けるためであって、送信者を隠すためではありません。

商談の後に残すもの

議事録から更新案を作る

商談の後に人が手で書くのは、簡単なメモか、文字起こしの貼り付けまでにします。そこから、社内向けのサマリー（議論点・相手の優先事項・反論と対応・競合への言及・担当者と期日つきのアクション・次のステップ・商談への影響）、顧客向けのフォローアップ（プレーンテキスト）、CRM の更新案（ステータス・次アクション・提案内容と反応）を AI に作らせます。議事録は CRM 側の議事録データベースに、企業へのリレーション付きで保存します。

CRM への反映は案として出し、人が確認画面で許可してから書き込みます。何を何に変えるのかを差分で出し、人がその差分を読んで判断できるようにしましょう。ステータスは事実の解釈を含むので、ここだけは自動で進めないようにします。

議事録を渡すときの依頼は、次のように書きます。3 つの成果物を分けて頼み、CRM には書き込ませません。

以下は、今日の B ヘアサロンとの商談のメモ（文字起こしの抜粋）です。次の 3 つを作ってください。

1. 社内向けサマリー: 決まったこと、相手の優先事項、出た懸念とこちらの回答、
   競合への言及、アクション（担当者と期日つき）。
2. 先方へのお礼とフォローアップのメール文面（プレーンテキスト。送信は私がします）。
3. CRM の更新案: 変える項目だけを「現在の値 → 新しい値 → 根拠（メモの該当箇所）」の形で。
   CRM には書き込まず、案として出すだけにしてください。

メモに無いことは補わないでください。期日が話に出ていないアクションは「期日未定」とします。

（ここにメモを貼る）

返ってくる更新案は、例えば次のような形です。

CRM の更新案（B ヘアサロン / 2 回目の商談）
- ステータス: 担当者検討 → 担当者合意
  根拠: オーナー「来月から始めたいので、見積をください」
- 次アクション: 提案資料の送付 → 見積の送付（期日: 今週金曜）
  根拠: 店長「今週中に見積をいただけますか」
- 獲得目標月: 変更なし

根拠の欄があるので、確認する人はメモを読み返さなくても判断できます。ステータスを進める根拠が発言の解釈に頼っているかどうかも、この欄を見れば分かります。例えば「来月から始めたい」であれば担当者合意の根拠になりますが、「前向きに検討します」だけであれば担当者検討のまま据え置く、という判断を人がここで行います。案のとおりでよければ、「この案のとおりに CRM を更新してください」と続けて依頼します。エージェントが更新のツールを呼ぶと確認画面が表示されるので、表示された差分が案と同じかどうかを見てから許可します。

3 つの成果物の分け方と更新案の形も、手順書にしておきます。

---
name: call-summary
description: >-
  商談のメモや文字起こしから、社内サマリー・顧客向けフォローアップ・CRM の更新案の 3 つを作る。
  メモや文字起こしを貼り付けたとき、「商談のまとめを作って」「議事録にして」「フォローのメールを書いて」で使う。
  ※商談の前は商談前ブリーフのスキル。CRM への書き込みは差分の案までで、反映は人が確認画面で許可する。送信も人が行う。
---
# 商談の後処理

## 入力
ラフなメモ / 文字起こし（貼り付け・アップロード・資料置き場のテキスト）/ 口頭の説明。
通話を自動で記録する経路は持たない。

## 手順
1. メモを構造化する（出席者・種別・所要時間・論点）
2. 決定事項、相手の優先事項、出た反論とこちらの回答、競合への言及を抜く
3. アクションを担当者と期日つきで出す。期日が話に出ていなければ「期日未定」
4. 提案した内容（プラン・金額・期間）と先方の反応を必ず拾う
5. 3 つの成果物を分けて出す。**CRM には書き込まない**

## 出力の型
1. 社内サマリー: 論点 / 相手の優先事項 / 反論と対応 / 競合 / アクション（担当者｜期日）/ 次のステップ / 商談への影響
2. 顧客向けフォローアップ（プレーンテキスト。件名＋本文）
3. CRM の更新案: 変える項目だけを「現在の値 → 新しい値 → 根拠（メモの該当箇所）」で。
   議事録は議事録データベースにレコードとして追加し、企業へのリレーションを必須にする（単独のページを作らない）

## 守ること
- メモに無いことを補わない
- ステータスの遷移は案として出すだけ。「前向きに検討します」で進めない（遷移条件の事実に当たるかを人が判断する）
- 会社名・案件名の略称を使わない（後で機械が同一視できない）
- 顧客向けの文面に社内メモ（確度・懸念・競合の評価）を混ぜない

この手順書は成果物を 3 つに分けて出し、CRM への書き込みは行いません。更新案を「現在の値 → 新しい値 → 根拠」という差分の形にしているのは、確認する人がメモを読み返さなくても判断できるようにするためです。根拠の欄が無い更新案は、「エージェントがそう言っている」以上の意味を持ちません。ステータスの遷移を案にとどめているのは、遷移が事実の解釈を含むからです。「来月から始めたい」と「前向きに検討します」の違いは、遷移条件の表に照らして人が判断します。議事録は単独のページにせず、議事録データベースのレコードにして、企業へのリレーションを必須にしました。企業に紐づいていない議事録は後から誰も辿れず、次の商談前ブリーフで前回の約束を拾えなくなってしまうからです。最後の「顧客向けの文面に社内メモを混ぜない」は、同じ入力から社内向けと顧客向けの文面を同時に作るこの手順書で起きやすい事故を防ぐための規則です。

反応の自動記録

返信、フォームからの問い合わせ、チャットでの反応は、人が転記しなくても接点履歴に自動で起票されるようにします。メールは受信したものを転送するか API で取得し、フォームは送信時の通知（Webhook）で受け取ります。紐づけのキーは、メールアドレス（担当者）とドメイン（企業）です。紐づかないものは推測で紐づけず、「未紐づけ」の列に置いて人が振り分けます。起票は CRM への書き込みですが、外部に反映される操作ではないので確認は必要ありません。確認が必要なのは外部に出ていく操作であって、内部に事実を書き込む操作ではないからです。ただし、「商談のステータスを進める」ことは事実ではなく解釈なので、起票と一緒に自動で進めることはしません。

外部チャットから指示する

営業担当が普段いる場所は、ダッシュボードではなくチャットです。Slack や Chatwork からメンションで指示を出すと、返答が同じスレッドに返ってきて、同じ会話がエージェント側の履歴にも残る形にしておけば、CRM を開かなくても「この会社の商談準備をして」と頼めるようになります。足すのは入口と出口だけで、中の処理はこれまでと同じです。一番大切なのは実行の経路を増やさないことで、そのほかに気をつけることが 4 つあります。

• 外部チャットから頼めるのは、読み取り・調査・下書きまでにする。外部チャットから起動した作業はサーバー側で動き、確認画面に答える人がいないので、確認が必要な書き込み（送信・CRM の更新）は断られます（第 2 章）。断られたことを返信で伝えて止まるようにし、送信や CRM への書き込みは、確認画面を表示できる Claude のアプリ（claude.ai・Claude Code）で行います。
• 自分の投稿には反応しない。反応してしまうと止める方法の無いやり取りが始まり、1 往復ごとに処理が実行されてしまいます。
• 再送で二重に実行しない。チャット側は応答が遅いと同じイベントを再送してくるので、受け付けた ID を記録しておき、2 回目以降は何もせずに成功を返します。
• 宛先を推測しない。1 つのワークスペースを複数の案件で使う場合はチャンネルを案件に割り当てておき、割り当てが無く候補が 2 つ以上あるときは「割り当ててください」と返して終わります。

チャンネルにいる人は誰でも指示を出せるので、運用メンバーだけのチャンネルで使うようにしましょう。受け口には各サービスのイベント通知（Slack の Events API、Chatwork の Webhook）を使い、署名やトークンの検証は省かないでください。返信を投稿するのはサーバー自身だけにして、エージェントにはチャットへ投稿するツールを持たせません。持たせた時点で、確認を通らずに外部へ送信される経路が 1 つ増えてしまいます。

提案と見積

提案は工程の受け渡し

提案資料づくりは 1 つの手順ではなく、複数の工程の受け渡しです。与件の把握（CRM と業界の正本）→ 企業調査 → 事例調査 → アイデアの調査と施策の検討 → 提案ストーリーの構築 → 提案概要の CRM への登録と承認 → 資料作成 → 品質チェックと商談準備、という流れになります。各工程の出力が次の工程の入力になり、ファイルで受け渡します。調査系の工程はサブエージェント（メインとは別に立てる作業用のエージェント）に任せ、メインの会話は全体の指示に専念します。調査ではツールの結果でコンテキストを大量に消費するので、それをメインに戻すと以降の判断の精度が落ちてしまうからです。

工程を図にすると次のとおりです。各工程に書いてあるのは「その工程を担う手順書」で、人が判断するのは提案概要の承認の 1 箇所です。

図は横にスクロールできます。図を原寸で開く

図の元になった mermaid を見る

mermaid

flowchart LR
  P0["0 与件把握<br>CRM の商談・議事録<br>業界の正本"] --> P1["1 企業調査<br>company-brief<br>（相見積りなら競合も並列）"]
  P1 --> P2["2 事例調査<br>case-research"]
  P2 --> P3["3 アイデア調査・施策の熟考<br>企画系の手順書で案を出し<br>採点で絞る"]
  P3 --> P4["4 提案ストーリー構築<br>提案戦略のエージェント<br>骨子は常にフル"]
  P2 -.->|"標準・クイックは 3 を飛ばし<br>事例調査の切り口で代替"| P4
  P4 --> G{"4.5 提案概要の登録と承認<br>議事録 DB に概要ページ<br>企業へのリレーション"}
  G -->|"人が承認"| P5["5 資料作成<br>原本の複製<br>quote・補助アセット"]
  G -.->|"修正指示"| P4
  P5 --> P6["6 品質チェック・商談準備<br>デザイン点検 → call-prep"]
  P6 --> CS["商談後 call-summary<br>→ CRM へ還流（次回の与件）"]

工程には、省略してよいものと、省略してはいけないものがあります。商談の直前や既存クライアントへの追加提案では、アイデア出しの工程を飛ばし、事例調査で見つけた提案の切り口で代わりにすることができます。省略してはいけないのは、企業調査、事例調査、提案概要の承認、テンプレート複製のルールです。リサーチをしないままの提案や、承認を得ないままスライドに着手することは、事故の原因になります。

モードで工程を飛ばす場合でも、「企画の型」は飛ばしません。3 を省くのはアイデア出しの工程を省略するという意味で、施策の型を省略するわけではないからです。与件の施策の種類に対応する手順書の型を参照し、骨子に反映します。起動したときに与件と商談のステージを確認してモードを提案し、各工程の終わりには中間成果物を 1 画面で示して、人が方向を修正できるようにしておきましょう。

提案概要の承認とは、提案の骨子が固まった時点で CRM の議事録データベースに概要ページを作り、企業へのリレーションを付けて、人の明示的な承認を得てから資料の作成に着手する、という手順です。資料が完成したら、同じページに資料と見積の URL を追記してまとめておきます。中間成果物を使い捨てにせず、後から誰でも辿れるようにするためです。

工程の受け渡しそのものを手順書にすると、次のようになります。各工程の中身は担当のスキルに任せ、この手順書は順番と接続と省略の可否だけを持ちます。

---
name: proposal-workflow
description: >-
  提案資料づくりの全工程（与件把握 → 企業調査 → 事例調査 → 施策の熟考 → ストーリー構築 →
  提案概要の登録と承認 → 資料作成 → 品質チェックと商談準備）を、工程ごとのスキルに受け渡して回す。
  「〇〇への提案資料を作って」「提案の準備をして」「提案書の作り方の流れは」で使う。
  ※工程 1 つだけの依頼（企業を調べて / 事例を集めて / 見積を出して）は各スキルを直接使う。
---
# 提案資料の工程

## 工程と担当（出力は次の工程の入力。ファイルで受け渡す）
0 与件把握 …… メインの会話（CRM の商談と議事録、業界の正本を読む）→ 与件サマリー
1 企業調査 …… company-brief（相見積りなら competitor-battlecard を並列）→ 調査レポート
2 事例調査 …… case-research → 提案の切り口と事例集
3 施策の熟考 …… 企画系のスキルで案を出し、採点して絞る → 採点済みの案
4 ストーリー構築 …… 提案戦略のエージェント → 提案の骨子（常にフル）
4.5 提案概要の承認 …… メインの会話。議事録データベースに概要ページを作り、企業へのリレーションを貼る → **人の承認（ゲート）**
5 資料作成 …… 原本（マスター）の複製。補助に quote・HTML アセット → 資料・見積
6 品質チェック・商談準備 …… デザイン点検 → call-prep → 商談後は call-summary → 商談メモ（CRM へ戻す）

## モード
フル（0〜6）/ 標準（3 を省き、事例調査の切り口で代替）/ クイック（0・1・2・4.5・5）。
**省略できない工程: 1・2・4.5・5**。どのモードでも承認のゲートは飛ばさない。

## 委任のきまり
- 調査系の工程（1・2・3）はサブエージェントに切り出す。メインは指揮と品質確認に徹する
- サブエージェントは結果を先にファイルへ保存し、戻り値はパスと要点 5 行以内
- 同時に動かすのは 3〜4 体まで。サブエージェントからの再委任は禁止
- CRM・資料置き場への書き込みと破壊的な操作はメインの会話で行う（サブエージェントに持たせない）

## 守ること
- 原本を直接編集しない。複製してクライアント別のフォルダへ移す
- 原本に無いレイアウトが中核になるなら、着手前に別経路（HTML → PDF / PPTX）を判定して人と合意する
- 既存クライアントへの提案では、原本の匿名の実績カードに相手自身の実績が無いかを複製の前に確認する
- 数値には信頼度ラベルを付ける。業界ごとの「使ってはいけない数値」を使わない
- 骨子はフルで作り、初回提案は引き算版に落とす（柱 1 本・課題 7 割・提案 3 割・最小リスクの試行で締める）。捨てた柱は次回の与件として残す

## 縮退先
- 原本の置き場が使えない: HTML から PDF / PPTX を作る
- CRM が使えない: 概要を Markdown で出して承認を取り、CRM への登録は後追い（ゲート自体は省略しない）

この手順書は工程の受け渡しだけを持ち、各工程の中身は担当のスキルに任せる形です。工程 1 つだけの依頼は、各スキルに直接回すようにしました。「事例を集めて」という依頼でこの手順書が呼び出されると、与件の把握から資料作成までがすべて動き出してしまうからです。省略できない工程は 1・2・4.5・5 に固定し、承認のゲートはどのモードでも飛ばしません。リサーチをしないままの提案や、承認を得ないままのスライド着手は、事故の原因になります。委任のきまりを手順書の側に持たせているのは、調査の工程でツールの結果がコンテキストを大量に消費するためです。それをメインに戻すと以降の判断の精度が落ちるので、戻り値もファイルのパスと 5 行以内の要点に絞ります。書き込みと破壊的な操作はメインの会話に限定しました。サブエージェントには、確認画面に答える人がいないからです。原本の匿名の実績カードを複製の前に確認する 1 行は、次の実例で実際に起きたことを、そのまま手順に書いたものです。

資料はテンプレの複製

正式な提案資料は、原本（マスター）を複製して作ります。原本は直接編集せず、複製したらクライアント別のフォルダへ移します。原本に無いレイアウト（データの表が中心になる提案など）が必要な場合は、複製と差し替えでは作れないので、HTML から PDF や PPTX に書き出す別の方法を使うかどうかを、着手する前に判断します。

初回の提案は、内容を絞った版にします。初回の目的は受注ではなく次のミーティングを獲得することなので、戦略の柱を 1 本に絞り、課題の提起を 7 割、提案を 3 割にします。費用は幅か最小のプランで示し、最後は最もリスクの小さい試行を推奨案として提示します。戦略の骨子自体はすべて作っておき、使わなかった柱は次回の与件として残しておきましょう。

見積書

見積書は、聞くこと、計算、命名、保存先を固定すれば自動化できます。聞くのは、宛先、件名、明細（品目・数量・単位・税抜単価）、有効期限（指定が無ければ発行日から 30 日）、発行日です。番号は日付＋連番で採番します。金額は必ず税抜で受け取り、税込の金額は計算させます。「税込で」と言われた場合は、明細ごとに税込の印を付けて税の加算を飛ばすか、税抜に戻してから入力します。人が暗算した税込の金額を明細に混ぜると、合計が合わなくなってしまうからです。

ファイル名はクライアントに送る用の形（御見積書、件名、宛先の正式名称に御中、日付）に固定し、保存先はクライアント別のフォルダにします。同じ名前のファイルがある場合は、確認せずに上書きすることはせず、古いほうをどうするかを人に確認します。発行元の情報（住所・登録番号・振込先・印影）は設定の 1 箇所に置いておきます。出力は表計算ファイルと PDF の両方で、資料置き場に保存できない環境ではローカルに残して、手動でアップロードする方法を案内します。「できません」で終わらせず、代わりにどうするか（縮退先）を書いておくことが大切です（原則 K）。

手順書にすると次のとおりです。

---
name: quote
description: >-
  見積書を表計算ファイルと PDF の両方で作り、クライアント別のフォルダに保存する。
  「見積書を作って」「見積を出して」「お見積り」で使う。宛先や金額が未定でも見積の文脈があれば起動し、聞くところから始める。
  ※提案資料は提案ワークフローのスキル。送付は人が行う。
---
# 見積書

## 発行元の情報（設定の 1 箇所）
社名・住所・登録番号・振込先・印影・既定の支払条件。未設定の項目は 1 回だけ聞いて設定に書き戻す。

## 聞くこと
宛先（正式名称）/ 件名 / 明細（品目・数量・単位・**税抜**単価）/ 有効期限（未指定なら発行日から 30 日）/ 発行日（未指定なら今日）

## 手順
1. 明細を構造化する（税込で受け取った行には税込の印を立て、加算を飛ばす）
2. 番号を採番する（日付＋連番。同日は連番を進める）
3. 表計算ファイルを生成し、PDF に変換する
4. クライアント別のフォルダを探し、無ければ作って保存する
5. 保存先の URL・番号・合計・有効期限を報告する

## 守ること
- 税の計算は計算機に任せる。人が暗算した税込を明細に混ぜない
- ファイル名は送付用の形に固定する（御見積書_件名_宛先の正式名称 御中_日付）
- 同名のファイルがあっても確認なしに上書きしない。新しく保存し、古いほうの扱いを人に確認する
- 案件が複数でも 1 件ずつ作る

## 縮退先
- 資料置き場に保存できない（未連携・認証切れ）: ローカルに残し、保存先のパスと手動アップロードの手順を案内する
- PDF の変換環境が無い: 表計算ファイルだけを出し、変換手段を案内する

聞くこと・計算・命名・保存先を固定すれば自動化できる、という上の説明を、そのまま手順書にしました。金額は税抜で受け取り、税の計算は計算機に任せます。人が暗算した税込の金額が 1 行混ざるだけで、合計が合わなくなるからです。税込で言われた行に印を付ける手順は、その例外への対処です。同じ名前のファイルを上書きしないのは、上書きが取り消せない操作だからです。前の版を消してよいかどうかは、人にしか判断できません。縮退先の「ローカルに残して手動アップロードを案内する」は、資料置き場の認証が切れた日のための 1 行です。これが無いと「保存できませんでした」で終わってしまい、見積書そのものが出てきません。ファイルさえあれば、見積書は人が送ることができます。

受注後の定例も同じ形で回す

契約した後に始まる定例レポート MTG（多くは月次ですが、隔週や四半期の場合もあります）も、提案と同じく「工程の受け渡し」で組み立てます。与件と前回の宿題の把握 → 実績の調査・集計 → 分析・翌月の企画 → レポート資料の作成 → MTG の準備・実施 → 議事録の CRM への反映、という流れです。実績の数字そのものをどう取得するか（公式 API・画面での確認・CSV の持ち込み）は第 7 章の運用の話なので、ここでは営業側の受け渡しと、人が判断する箇所だけを扱います。

省略してはいけない工程は、実績の調査・集計と、議事録の CRM への反映の 2 つです。数字の無い定例は解約につながりやすく、議事録が残らない定例は翌月の与件を失ってしまいます。反対に、分析・翌月の企画は通常の月であれば軽く済ませ、契約の更新月や解約の兆候がある月だけ深く行います。どのモードでも、客先に出す資料の「翌月の方向性」のページは省きません。省く場合は、実績から読み取れる簡単な所見（続けるべき勝ちパターンと、直すべき点を 1〜2 個）で埋めます。

守るべきことは 4 つあります。①見る指標は運用の種類によって変えます（店舗の集客ならリーチとプロフィールへの遷移、EC ならリンクのクリック、採用なら保存とプロフィールへの遷移）。予約・来店・応募への貢献は SNS の指標だけでは分からないので、クライアントが持っているデータ（予約数・来店時のアンケート・応募の経路）のヒアリングを毎回アジェンダに入れます。②データの取得方法は与件を把握する時点で媒体ごとに決めておき、実績のサマリーに明記します。取れなかった指標を「取得不可」のまま客先に出さず、画面での確認や持ち込みのデータで埋めてから出します。③社内向けの分析と客先向けの資料を混ぜません。独自の品質指標、全投稿の生の表、データ取得の制約の話は社内だけにとどめます。④定例は解約を防ぎ、拡大を提案する一番大事な機会ですが、成果が出ていない月には拡大の提案をしません。まずは改善策を示しましょう。

図は横にスクロールできます。図を原寸で開く

図の元になった mermaid を見る

mermaid

flowchart LR
  R0["0 与件・前回宿題の把握<br>CRM の契約 KPI・前回議事録<br>期間の区切り・取得モードを確定"] --> R1["1 実績調査・集計（省略不可）<br>媒体ごとの実績＋クライアント提供データ<br>前期比・契約 KPI 対比"]
  R1 --> R2["2 分析・翌月企画<br>勝ちパターン → 翌月の企画<br>（外れ値があれば逆解析）"]
  R1 -.->|"クイックは 2 を飛ばし<br>簡易所見で代替"| R3
  R2 --> R3["3 レポート資料作成<br>前月版を複製"]
  R3 --> R4["4 MTG 準備・実施<br>拡大仮説・解約リスク → call-prep"]
  R4 --> R5["5 MTG 後処理（省略不可）<br>call-summary → 議事録 DB<br>企業へのリレーション"]
  R5 -->|"宿題・合意を還流<br>翌月の与件になる"| R0

手順書にすると次のとおりです。

---
name: regular-report-workflow
description: >-
  受注後の定例レポート MTG（月次・隔週・四半期）の全工程（与件・前回宿題の把握 → 実績調査・集計 →
  分析・翌月企画 → レポート資料作成 → MTG 準備・実施 → 議事録・CRM への還流）を、工程ごとのスキルに受け渡して回す。
  「〇〇の月次定例の準備をして」「定例レポートを作って」「定例 MTG の後処理をして」で使う。
  ※拡大提案が合意になったら提案ワークフローのスキルへ。広告パートは広告レポートのスキル。実績の取得そのものは各媒体のスキル。
---
# 定例レポート MTG の工程

## 工程と担当（出力は次の工程の入力。ファイルで受け渡す）
0 与件・前回宿題の把握 …… メインの会話。運用類型・契約 KPI・対象アカウント・前回宿題に加えて、
  **対象期間の区切り**（暦月とは限らない。前回レポートの最終週と接続する）と
  **媒体ごとの取得モード**（公式 API / 画面の実査 / CSV の持ち込み）を人と合意する
1 実績調査・集計 …… 媒体ごとの取得スキル ＋ クライアント提供データ ＋ 納品台帳との突合 → 実績サマリー（前期比・契約 KPI 対比）
2 分析・翌月企画 …… 外れ値の逆解析 → 企画のスキル →（重要な月は採点）→ 所見と翌月企画案
3 レポート資料作成 …… 前月版の複製（メインの会話）。初回は標準の章構成に従う
4 MTG 準備・実施 …… 拡大を担うエージェント → call-prep → 準備メモ
5 MTG 後処理 …… call-summary → 議事録データベースに保存し企業へのリレーション（メインの会話）→ 翌月の与件

## モード
フル（0〜5。逆解析・採点込み）/ 標準（2 は企画のみ）/ クイック（0・1・3。5 はレポート URL の記録のみ）。
**省略できない工程: 1 と、5 の CRM への還流**。どのモードでも客先資料の「翌月の方向性」のページは省かない

## 守ること
- 数字の無い定例を出さない。取れなかった指標を「取得不可」のまま客先に出さず、画面の実査や持ち込みで埋めてから出す
- 見る指標は運用の類型で変える。予約・来店・応募への貢献はクライアント提供データのヒアリングを毎回アジェンダに入れる
- 実績サマリーに媒体ごとの取得モードを明記する。専用の取得手段が無い媒体はギャップとして書く（隠さない）
- 社内分析（独自の品質指標・全投稿の生の表・取得の制約）を客先資料に載せない
- 成果が出ていない月に拡大提案をしない。まず改善策
- 前月版を上書きしない。資料の URL は CRM のレコードに残す。前月比の計算に使う取得データは捨てない
- CRM・資料の原本への書き込みはメインの会話で行う（サブエージェントに持たせない）

## 縮退先
- API が使えない: 画面のインサイトのスクリーンショットか CSV の持ち込みを依頼して集計する
- クライアント提供データが未着: 「取得不可」で埋めず、アジェンダのヒアリング項目に載せる
- 前月版の資料が無い（初回）: 自己流の型を作らず、標準の章構成で組む

この手順書は、提案の手順書と同じ形にしています。受け渡しの単位も、人が判断する箇所も同じだからです。違いは 2 つあります。省略できない工程が「実績の調査・集計」と「CRM への反映」になることと、最後の工程が翌月の最初の工程に戻ることです。データの取得方法は、与件を把握する時点で媒体ごとに合意しておきます。集計の途中で「API では取れない」と分かってから持ち込みを頼んでも、定例の日には間に合わないからです。取れなかった指標を「取得不可」のまま客先に出さない、という規則は、企業調査で「未取得」と書かせる規則と逆のように見えるかもしれません。しかし、実際には同じ考え方です。社内の記録には正直に「取得不可」と残し、客先に出す前に人が画面で確認して埋める、ということです。専用の取得手段が無い媒体を、足りない部分として書かせるのも同じ考え方で、隠してしまうと翌月も同じ部分が抜けたままになります。守ることには、成果が出ていない月に拡大の提案をしない、を入れました。定例が解約を防ぎ拡大を提案する大事な機会であるからこそ、数字の悪い月に拡大を提案すると信頼を失ってしまいます。

パイプラインを見張る

パイプライン（進行中の商談の一覧）は、人が見に行く場所ではなく、異常があったときに知らせが届く仕組みにします。

週次レビュー

週に 1 回、パイプライン全体を 4 つの観点で見直します。ステージの進み具合（同じステータスに 30 日以上とどまっていないか）、活動の新しさ（14 日以上動きが止まっていないか）、期日の正確さ（獲得目標月を過ぎていないか）、連絡先の数（相手側の連絡先が 1 人だけになっていないか）です。優先順位は、成約までの近さ・規模・ステージ・活動・リスクに重みを付けて並べ、重みは指示で変えられるようにしておきます。

60 日以上反応が無い案件や、3 回以上先送りされた案件は、削除の候補として別に出します。停滞している案件はパイプラインを実際より大きく見せ、予測を狂わせてしまうからです。

週次レビューを頼むときの例です。

今週のパイプラインレビューをしてください。対象は開いている商談すべてです（締結・失注は除く）。

- データ: CRM の商談一覧を読み取り専用で取得してください。取れない場合は CSV を渡します。
- フラグは下の閾値で機械的に判定し、閾値を変えないでください。
  停滞 = 最終更新から 14 日以上 / 行き詰まり = 同じステータスに 30 日以上 /
  期日超過 = 獲得目標月が今月より前 / 単線 = 先方の連絡先が 1 人だけ /
  衛生 = 次アクション・期日・金額・担当者のいずれかが空
- 出力: ①今週注力する 5 件（理由を 1 行ずつ） ②フラグ別の一覧（表。案件名・ステータス・
  滞留日数・フラグ・推奨する対処） ③削除候補（60 日以上反応なし、または 3 回以上先送り）
  ④データの欠け（空欄の項目と件数）
- CRM のステータスや期日は変更しないでください。変えたほうがよいものは「更新案」として別に並べます。
- 金額や日付が空の案件を、推測で埋めないでください。

依頼文に閾値を書いているのは、判定を毎週同じにするためです。この章では停滞検知を決定的なコードで行う方針ですが、コードを用意する前であっても、閾値だけは固定して渡すようにしましょう。「停滞している案件を見つけて」とだけ頼むと、エージェントがそのたびに基準を決めてしまいます。そうすると、先週挙がった案件が今週は挙がらなかったときに、それが案件の変化によるものなのか、基準の変化によるものなのかを区別できません。

閾値を手順書の側に固定しておけば、依頼文は「今週のレビューをして」だけで済みます。

---
name: pipeline-review
description: >-
  開いている商談の一覧を 4 つの観点と固定の閾値で見直し、今週注力する案件・リスクの一覧・
  データの欠け・削除候補を出す。「今週のパイプラインレビュー」「停滞している案件は」「商談の棚卸し」で使う。
  ※売上の見込み額は加重予測のスキル、毎朝の 1 通は朝のブリーフィングのスキル。CRM は変更しない。
---
# 週次のパイプラインレビュー

## 入力
CRM の商談一覧を読み取り専用で取得する（締結・失注は除く）。読めなければ CSV か 1 行 1 案件の貼り付け。
読む項目: 案件名 / ステータス / 金額 / 成約予定（獲得目標月）/ 担当者 / 次アクション / 流入元 / 最終更新日 / 相手側の連絡先の数

## 閾値（設定の 1 箇所。依頼で上書きできるが、実行のたびに変えない）
停滞 = 最終更新から 14 日以上 / 行き詰まり = 同じステータスに 30 日以上 /
期日超過 = 成約予定が今月より前 / 単線 = 相手側の連絡先が 1 人 /
衛生 = 次アクション・期日・金額・担当者・流入元のいずれかが空 /
削除候補 = 60 日以上反応なし、または 3 回以上の先送り

## 手順
1. 一覧を取得し、**閾値で機械的にフラグを付ける**（判定に生成 AI を使わない。用意があれば決定的なコードの結果を読む）
2. 優先順位を重み付け（成約の近さ 30 / 規模 25 / ステージ 20 / 活動 15 / リスク 10）で並べる
3. ステージ別・成約月別・規模別の形状を集計する
4. 推奨アクションと更新案を出す

## 出力の型
今週注力する 5 件（理由 1 行ずつ）/ フラグ別の一覧（案件名・ステータス・滞留日数・フラグ・推奨する対処）/
削除候補 / データの欠け（空欄の項目と件数）/ **更新案**（CRM は変更せず、変えたほうがよいものを別に並べる）

## 守ること
- 金額や日付が空の案件を推測で埋めない。埋まらない案件は予測の対象から外す
- 成約予定は「署名を期待する日」であって「願う日」ではない。過ぎた予定は更新か翌期へ繰り越すか失注の 3 択
- 大量に流入した初期段階のリード（展示会後など）は 1 件ずつ扱わず、まとめてフォロー計画を立てる

この手順書で一番大切なのは、閾値を設定の 1 箇所に置き、実行のたびに変えないことです。フラグの判定には生成 AI を使わず、用意があれば決定的なコードの結果を読ませます。同じ入力から同じ結果が出ることに価値がある処理だからです（詳しくは次の節で説明します）。CRM は変更させず、更新案として別に並べさせます。レビューのついでに期日やステータスが書き換わると、翌週のレビューで「先週から状況が動いた」のか「先週書き換えた」のかを区別できなくなるからです。空欄の金額や日付も推測で埋めません。埋めた時点で、加重予測がその推測を事実として足し込んでしまいます。

停滞検知は決定的に

停滞の判定には、生成 AI を使いません（原則 Q）。停滞検知は同じ入力から同じ結果が出ることに価値がある処理なので、昨日と同じデータなのに今日は別の案件が挙がると、利用者は仕組みが壊れたのか、状況が改善したのかを判断できなくなります。判定は閾値を 1 箇所に置いた決定的なコードで行い、AI に任せるのは通知文の下書きだけにします。

# 停滞検知。閾値は設定 1 箇所から読む。結果は理由の配列（空なら健全）
def stall_reasons(deal, today, cfg):
    reasons = []
    if deal.status.open and not deal.next_action:
        reasons.append("次アクション未設定")
    if (today - deal.updated_at).days >= cfg.idle_days:        # 例: 14
        reasons.append(f"{cfg.idle_days} 日更新なし")
    if (today - deal.stage_entered_at).days >= cfg.stuck_days:  # 例: 30
        reasons.append(f"同一ステータス {cfg.stuck_days} 日")
    if deal.target_month and deal.target_month < today.month_start():
        reasons.append("獲得目標月を超過")
    return reasons   # 生成 AI が触るのは、この配列を文面にする工程だけ

加重フォーキャスト

フォーキャスト（売上予測）は、確度 × 単価 × 期間の加重和で出します。確度はステータス表の値をそのまま使い、別に定義し直さないようにします。失注と保留は対象外です。出すのはベスト（全件が成約した場合）、想定（加重和）、ワースト（コミット案件だけが成約した場合）の 3 つのシナリオです。コミット（確実に見込める確度の高い案件）は正直に絞り込み、それ以外はアップサイド（可能性はあるがリスクのある案件）に分けます。目標に対するカバレッジ（開いている案件の合計 ÷ 目標）は 3 倍を目安にし、足りない場合は、加速・再活性化・新規パイプラインの 3 つの選択肢で埋め方を示します。

予測の精度は、過去の予測と実績を比べて初めて分かります。そのため、予測を出すたびに日付付きで保存し、次回に実績と比べるようにしましょう。保存先は、作業の環境の外（データベースやスプレッドシート）にします。

計算方法を固定し、予測の保存を手順に組み込んだ手順書です。

---
name: forecast
description: >-
  開いている商談の確度 × 単価 × 期間の加重和で、ベスト・想定・ワーストの売上予測と
  目標に対するギャップを出す。「今月の見込みは」「四半期のフォーキャスト」「目標に届くか」で使う。
  ※案件ごとの停滞と対処は週次レビューのスキル。確度はステータス表の値を使い、独自に定義しない。
---
# 加重フォーキャスト

## 入力
CRM の商談一覧（読み取り専用。読めなければ CSV か貼り付け）。必須の項目: 案件名 / ステータス / 月額 / 契約期間 / 成約予定。
目標（期間の売上目標）と、期間内にすでに締結した額は依頼した人に聞く。

## 計算（決定的。生成 AI は説明文だけ）
案件価値 = 月額 × 契約期間 / 加重値 = 案件価値 × ステータス表の確度 /
ベスト = 開いている案件の全件 / 想定 = 加重値の合計 / ワースト = コミット案件だけ /
カバレッジ = 開いている案件の合計 ÷ 目標（目安 3 倍。2 倍未満は警告）

## 手順
1. 失注・保留を除き、ステータス表の確度をそのまま使う
2. 3 シナリオを出す
3. コミット（確実に見込める案件だけ）とアップサイド（それ以外）に分ける。コミットは正直に絞る
4. ギャップを、加速・再活性化・新規パイプラインの 3 つの選択肢で埋める案にする
5. **今回の予測を日付付きで保存する**（保存先は実行環境の外）。前回の予測があれば実績と比べて精度を出す

## 出力の型
サマリー（目標 / 締結済み / 開いている案件 / 加重 / ギャップ / カバレッジ）/ 3 シナリオと前提 /
ステージ別（件数・合計・確度・加重）/ コミットの一覧と理由 / アップサイドの一覧とリスク / ギャップの埋め方 / 前回予測との差

## 守ること
- 確度をこの手順書の側で持たない（正本を 2 つにしない）
- 成約予定を過ぎた案件は予測に入れず、更新案として週次レビューへ回す
- 金額や期間が空の案件を推測で埋めない（予測から外し、件数を出力に書く）

確度の表は、この手順書には持たせていません。正本を 2 つにしないためで、詳しくは後の実例で説明します。計算を決定的にして、生成 AI には説明文だけを任せる点は停滞検知と同じです。今回の予測を日付付きで保存する手順も本文に入れました。エージェントの作業は毎回まっさらな状態から始まるので、前回の予測はどこにも残っていないからです。この 1 行が無ければ、予測の精度はいつまでも分からないままになります。成約予定を過ぎた案件は予測から外し、週次レビューに回します。予測の精度を下げるのは、計算ではなく入力です。過ぎた予定を入れたまま「今月は目標に届く」と読んでしまうと、翌月も同じ案件が同じ金額で「今月は届く」に入ってしまいます。

どのチャネルから来た商談かを残す

商談が「どこから来たか」は、後から思い出して書くことができません。そのため、商談の行に流入元（チャネル）を選択式の必須項目として持たせ、最初の接点の時点で自動で埋めるようにします。フォームからの問い合わせであれば、フォームの通知に含まれる URL のパラメータ（広告や記事のリンクに付けた目印）から埋めます。アウトリーチへの返信であれば、送信ログにどのシーケンスの何通目かが残っているので、そこから埋めます。展示会と紹介は、人が起票するときに選びます。ここでも「入力されない項目は存在しないのと同じ」です。自由記述の欄にすると「Web」「HP」「サイト経由」のようにばらばらの値が並び、集計できなくなってしまいます。

流入元が商談の行に入って初めて、コンテンツの成果と実際の商談をつなぐ表が作れるようになります。記事の閲覧数や広告のクリック数は各媒体の管理画面で見られますが、そこから何件の問い合わせが起き、何件が商談になり、いくらの契約になったかは、CRM の側でしか分かりません。つなぐためのキーは、フォームに入力されたメールアドレスとドメイン（担当者と企業の一意キー）です。このキーを使って問い合わせ → 担当者 → 商談 → 契約を辿り、流入元ごとに件数と金額を並べます。このとき並べるのは、流入元ごとの表です。流入元をまたいで数字を足してしまうと、同じ会社を広告でも記事でも数えることになり、しかも媒体ごとに「1 件」の定義も違います（第 11 章）。最初の接点と最後の接点の両方を残しておけば、記事で知って広告から問い合わせた会社を、どちらの成果として扱うかを後から選べます。

毎朝のブリーフィングは push 型で

ダッシュボードは、毎日は見てもらえません。そこで、朝に届く 1 通の通知に変えます（push 型。人が見に行くのではなく、異常だけが人に届く形）。内容は、最優先の 1 件とその理由、今日の数字（開いているパイプライン・今月の成約予定・今日の会議・アクションの数）、今日の会議と会議の前にやること、対応が必要なアラート、止まっているフォロー、おすすめのアクション 3 つです。2 分で読める長さにしましょう。

毎朝決まった時刻に動くものなので、置き場所は定期実行です（原則 M）。また、通知先が設定されていない定期実行は有効にできない形にしておきます（原則 N）。通知の無い自動実行は、何がいつ動いたのかを誰も知らないまま進んでしまうからです。

定期実行の中身になる手順書です。

---
name: daily-briefing
description: >-
  CRM と議事録から、今日の最優先 1 件・数字・会議と会議前の一手・アラート・推奨アクション 3 つを
  2 分で読める 1 通にまとめる。「朝のブリーフィング」「今日の準備」「今日は何を優先するか」で使う。
  定期実行の中身にもなる（通知先が無ければ有効にしない）。
  ※個別の会議の準備は商談前ブリーフのスキル、会議の後は議事録要約のスキル。
---
# 毎朝のブリーフィング

## 入力
CRM の商談一覧（自分の開いている案件・今月成約予定・次アクションが空か期限超過・停滞）と、
議事録データベースの直近の約束事。今日の予定は依頼した人が伝えるか、次アクションと成約予定から拾う。
Web のシグナル（出店・受賞・採用）は任意。

## 最優先 1 件の選び方（この順で最初に当たったもの）
確度 90% 以上の案件の会議がある → 今月成約予定で未締結 → 期限を過ぎた次アクション → 高額の初期案件で 7 日以上動きなし

## 出力の型（2 分で読める長さ）
最優先の 1 件とその理由 / 今日の数字（開いている案件・今月成約予定・今日の会議・アクション数）/
今日の会議と会議前の一手 / 要対応のアラート（表）/ 滞留しているフォロー / 推奨アクション 3 つ

## 守ること
- 最優先の 1 件と推奨アクション 3 つは常に出す。**データの無いセクションは作らない**（数字・アラートは CRM が読めたときだけ）
- 停滞の判定は週次レビューと同じ閾値を読む（この手順書で別の閾値を持たない）
- 読み取りだけ。CRM を更新しない。送信しない

## 縮退先
- CRM が読めない: 今日の予定・注力している案件・緊急事項の 3 つを聞いて組み立てる
- 終業版: 今日完了したこと / ステージが動いた案件 / 明日の予定 / 未完了、の 4 つに切り替える

この手順書は定期実行の中身になる前提なので、持たせたのは読み取りだけです。「データの無いセクションは作らない」を太字にしているのには理由があります。毎朝届く 1 通が空欄を埋める方向に働くと、読めなかった数字がもっともらしい数字に置き換わってしまうからです。最優先の 1 件の選び方も、順番で固定しました。日によって基準が変わると、「今日の最優先」が担当者のその日の気分で決まるものになってしまいます。停滞の閾値を週次レビューと共有させているのも同じ理由です。閾値が 2 箇所にあると、朝の 1 通に挙がった案件が週次レビューには挙がらない、という食い違いが週の途中で起きてしまいます。個別の会議の準備は、商談前ブリーフに分けました。会議ごとの 1 画面分の内容を全部入れると、2 分で読める長さを超えてしまうからです。

PR とイベント

プレスリリースと記者リスト

メディアが取り上げるのは宣伝ではなくニュースです。新規性、時事性、地域性、社会性のどれで取り上げてもらうのかを、タイトルに含めるようにしましょう。どれにも当てはまらない場合は、リリースを出す前に、ニュースになる材料づくり（自社データを調査結果にする・周年・地域との接点を作る）を提案します。構成は、結論を書いたタイトル、5W1H のリード、本文（背景・詳細・今後）、会社概要、問い合わせ先です。リリースに載せる数字にも、検証の状態（自社調べ・サンプル数）を書きます。出典の無い「業界初」「地域最大」は書いてはいけません。メディアの事実確認で落とされるだけでなく、景品表示法の優良誤認にあたるおそれもあります。

記者リストは、公開情報を実際に確認したうえで作ります。各行には、同じ種類の題材を扱った実際の記事の URL と日付を根拠として付け、根拠の無い「大手だから」という理由の行は載せません。連絡先は公開されている窓口だけにし、公開されていない個人の連絡先を推測したり集めたりしないでください。ピッチ（掲載の打診）では、媒体ごとに「なぜこの媒体なのか」を、過去の実際の記事に触れながら 1 行で書き、記者が使える素材（写真・データ・現地取材の可否・コメントの窓口）をはっきり書きます。送信は人が行います。

掲載された後も感想で終わらせず、効果を実際に測ります。指名検索の変化（第 6 章の Search Console の方法で掲載の前後を比較する）、被リンク、言及の広がり（第 8 章のブランドリスニングに掲載日を記録しておく）を見ます。売上や予約への貢献は計測できる範囲だけを書き、計測の仕組みがつながっていなければ「未計測」と書きます。

記者リストの当たり先と、依頼の例

記者リストの当たり先は 3 種類あります。地域メディア（地方紙・地元のテレビ局・タウン誌）は、商圏の地名と「掲載」「特集」で検索し、同じ種類の店を実際に載せた媒体から並べます。業界の専門 Web メディアは、同業他社が掲載された記事から辿ります。一度載せた媒体は、同じ題材をもう一度扱う可能性が高いからです。記者や編集者個人は、署名記事と公開されているプロフィールから探し、その人がそのテーマで書いた実際の記事と一緒に記録します。

依頼の例です。

駅前の和菓子店「D 堂」が、10 月 1 日に地元産の栗を使った新商品を発売します。
プレスリリースの原稿と、掲載を打診するメディアのリストを作ってください。

- 材料: 発売日、価格、地元の農家 2 軒と契約した経緯（下に貼ります）、
  昨年の試験販売で 3 日間に 400 個が売れたこと（自社調べ）。
- リリース: タイトルは結論から書き、30 字前後にしてください。リードは 5W1H を 3〜4 行で。
  切り口は地域性（地元の農家との取り組み）にしてください。
  「地域初」「最大」のような、出典の無い言葉は使わないでください。
- リスト: 市内と県内の媒体を 10 件まで。各行に、同じ種類の題材を扱った
  実際の記事の URL と日付を付けてください。根拠の記事が無い媒体は載せないでください。
- 連絡先: 媒体が公開している窓口（リリースの受付・問い合わせフォーム）だけにしてください。
- 送信と配信はしません。原稿とリストだけを返してください。

足りない例も並べます。

新商品のプレスリリースを書いて、有名なメディアに送っておいて。

後者の依頼では、何がニュースなのかをエージェントが決めることになります。多くの場合、宣伝文に近いリリースになってしまい、どのメディアにも取り上げられにくくなります。また、「有名なメディア」には根拠が無いので、題材と関係の無い全国紙がリストに並びます。「送っておいて」と送信まで頼んでいますが、この章の設計では送信は人が行うので、エージェントは下書きで止まる必要があります。

リストの 1 行は、例えば次のような形です。

媒体: 〇〇タウン情報（月刊のタウン誌。Web 版あり）
根拠: 2026-07-15「夏の新作和菓子 5 選」で市内の和菓子店 3 軒を掲載（記事の URL）
窓口: 公式サイトの情報提供フォーム（公開）
切り口: 地元の農家との取り組み。季節の特集に合わせて 9 月中旬に打診する
未確認: 10 月号の締切（公式サイトに記載なし）

地域によっては、リストに載せられる媒体が少ないこともあります。その場合も、成果物を空にはしません。確認できた媒体だけのリストに、探し方の手順（どの検索語で、どのページを見るか）を添えて渡します。リリースの本文は Web 検索だけでも必ず作れるので、そちらを先に仕上げましょう。

依頼のたびにこれらの条件を書かずに済むように、手順書にしておきます。

---
name: pr-outreach
description: >-
  プレスリリースの原稿と、掲載を打診するメディアのリスト、掲載後の実測までを扱う。
  「プレスリリースを書いて」「メディアに取り上げてほしい」「記者リスト」で使う。
  ※登壇・出展の発掘はイベント発掘のスキル。送信は人が行う。
---
# 広報とメディアリスト

## 手順
1. **何で載るのか**を先に決める（新規性 / 時事性 / 地域性 / 社会性）。
   どれも無ければ、リリースの前に**材料づくりを提案する**
2. 構成：結論のタイトル（約 30 字）→ 5W1H のリード → 本文 → 会社概要 → 連絡先
3. 記者リストは公開情報だけで作る。
   **各行に「同種の題材を扱った実記事の URL と日付」を付ける**。
   根拠の無い媒体は載せない
4. 連絡先は公開されている窓口だけ（非公開の個人連絡先を推測・収集しない）
5. 掲載後は実測する（指名検索の変化・被リンク・言及の波及）。
   売上への寄与は繋がっていなければ「未計測」

## 守ること
- 出典の無い「業界初」「地域最大」を書かない
- 数字には検証の状態（自社調べ・サンプル数）を添える
- リストが薄い地域でも成果物を空にしない（確認できた媒体＋探し方の手順）

この手順書が担当するのは、原稿とリストと掲載後の効果測定までで、送信は含みません。「送っておいて」と頼まれた例でも、エージェントは下書きで止まる必要があるからです。登壇・出展は別の手順書に分けました。「取り上げてほしい」も「登壇したい」も露出を増やしたいという依頼ですが、各行の根拠の種類が違います。メディアの行は同じ種類の題材を扱った実際の記事、登壇などの機会の行は公式サイトの開催実績と締切が根拠になります。1 つの手順書にまとめると、根拠の欄の意味が行ごとに変わってしまいます。

手順の最初は「何で取り上げてもらうのか」です。当てはまるものが無ければ材料づくりを提案する、というところまで書きました。メディアが取り上げるのは宣伝ではなくニュースなので、「新商品のプレスリリースを書いて」とだけ頼むと、何がニュースなのかをエージェントが決めることになります。その結果できあがるのは宣伝文に近いリリースで、どの媒体にも取り上げられません。各行に実際の記事の URL と日付を付け、根拠の無い媒体は載せない、という規則があれば、「有名なメディアに」と頼まれても、題材と関係の無い全国紙がリストに並ぶことはありません。根拠を実際の記事にしたのは、一度載せた媒体は同じ題材をもう一度扱う可能性が高いからです。連絡先は公開されている窓口に限り、公開されていない個人の連絡先を推測したり集めたりする手順は、手順書の側で無くしてあります。

守ることに、出典の無い「業界初」「地域最大」を書かないことを入れたのは、メディアの事実確認で落とされるだけでは済まないからです。景品表示法の優良誤認にあたるおそれもあります。また、リストが少ない地域でも成果物を空にしない、という規則が無ければ、「該当する媒体はありませんでした」の一文で終わってしまいます。確認できた媒体と探し方の手順を渡しておけば、その続きは人が探すことができます。

出展・登壇の発掘

出展・登壇の機会を探すときは、まず目的（リード獲得・認知・採用のどれか）と、話せる材料（話せる実績・データ）を確定させます。そのうえで、展示会・登壇の公募・ポッドキャストのゲスト回・自治体のセミナー講師といった機会を探します。開催実績・締切・費用は公式サイトで確認し、確認できない項目は「未確認」と書きます。締切を推測で書いてしまうと、それを信じて準備した人の作業がすべて無駄になってしまうからです。

適合度はスコアではなく、理由を 1 行で書いて付けます。見るのは、聴衆が一致しているか（規模よりも一致しているかが大切です。200 人の業界特化のイベントのほうが、2 万人の総合展より成果につながることが多いです）、話せる材料と合っているか、時期と工数、の 3 つです。登壇の提案では、演題を聴衆が得られるもので書き（自社の紹介ではなく「月曜から使える 3 ステップ」のように）、聴衆が持ち帰れる 3 点と、話者の根拠を添えます。提案書には、登壇の成果を回収する方法（名刺を交換した人への追客、資料の記事化や投稿化）を必ず入れましょう。合う機会が少ない場合は、自主開催（ウェビナー・共催）の企画と、探し方の指示書を代わりに渡します。

当たり先ごとに見るもの

今期の締切に間に合わない機会は、捨てずに「来期の候補」として別の一覧に分けておきます。展示会や登壇の公募は毎年同じ時期に出るものが多く、翌年の準備に使えるからです。主催者の窓口は、公式の問い合わせフォームや登壇の応募フォームなど、公開されているものだけを記録します。

登壇の提案書は、例えば次のような形です。

演題: 月曜から使える、予約サイトに頼らない集客の 3 ステップ
概要: 客室 30 室の温泉旅館が、Instagram の運用で平日の直接予約を
      増やした手順を、準備・投稿・計測の 3 段階で紹介します。
聴衆が持ち帰るもの:
  1. 投稿の企画を 1 か月分まとめて決めるための表
  2. 直接予約を計測するためのリンクの付け方
  3. 最初の 3 か月で見る数字と、見なくてよい数字
話者の根拠: 宿泊施設の SNS 運用を 5 年担当（実績の数字は検証状態を付けて記載する）
過去の登壇・掲載: （URL）
回収の一手: 名刺を交換した参加者に資料を送り、講演の内容を自社ブログの記事にする

演題は、話者が何を話したいかではなく、聴衆が何を得られるかで書きます。「弊社のご紹介」という演題は、主催者から見ると宣伝の時間にしか見えないからです。

この小節の進め方を手順書にすると、次のようになります。

---
name: event-scouting
description: >-
  出展・登壇・出演の機会を発掘し、登壇提案書まで作る。
  「出られるイベントを探して」「登壇したい」「展示会をリストアップ」で使う。
  ※メディア掲載は広報のスキル、相手企業の調査は企業調査のスキル。応募は人が行う。
---
# 出展・登壇の発掘

## 先に確定する
目的（リード / 認知 / 採用）と持ちネタ（話せる実績・データ）。

## 手順
1. 4 種類を当たる（展示会 / カンファレンスの登壇 / 対談番組 / 自治体・商工会）
2. 開催実績・締切・費用は**公式サイトで確認する**。
   確認できない項目は「未確認」と書く（締切をでっち上げない）
3. 適合度はスコアではなく**理由の行**で付ける
   （聴衆の一致 / 持ちネタとの噛み合い / 時期と工数）
4. 今期の締切に間に合わないものは捨てず、**「来期の候補」**の一覧に分ける
5. 登壇提案は**聴衆の得**で演題を書く（自社紹介にしない）。
   持ち帰る 3 点と、回収の一手を必ず入れる

## 縮退先
- 適合する機会が薄い → 自主開催（ウェビナー・共催）の企画と、探し方の指示書に切り替える

この手順書が担当するのは、機会を探すところから登壇の提案書までで、応募は含みません。メディア掲載は広報の手順書に、相手企業の調査は企業調査の手順書に分けました。「出られるイベントを探して」という依頼への答えに、記者リストや企業のプロフィールが混ざらないようにするためです。目的と話せる材料は案件ごとに変わるので依頼文で受け取り、手順書の最初には「先に確定する」項目として置くだけにしています。

開催実績・締切・費用は公式サイトで確かめさせ、確認できない項目は「未確認」と書かせます。締切を推測で書くと、それを信じて準備した人の作業がすべて無駄になってしまうからです。適合度をスコアにせず理由の行にしたのは、数字にすると規模の大きさが強く効いてしまうためです。200 人の業界特化のイベントのほうが 2 万人の総合展より成果につながることが多く、その違いは「聴衆が一致している」という理由の行でしか読み取れません。今期に間に合わないものを「来期の候補」に分けるのは、展示会や登壇の公募が毎年同じ時期に出るからです。捨ててしまうと、翌年また同じ検索から始めることになります。演題は聴衆が得られるもので書かせ、持ち帰れる 3 点と成果を回収する方法を必須にしました。「弊社のご紹介」という演題は主催者には宣伝の時間にしか見えませんし、目的がリード獲得であれば、成果は登壇そのものではなく、名刺を交換した人への追客から生まれるからです。

縮退先に自主開催の企画と探し方の指示書を置いているのは、合う機会が少ない地域や業種で「見つかりませんでした」で終わらせないためです。探し方の指示書があれば、人が次の巡回を続けることができます。

CRM 連携の作り方

読み取りは絞らず、書き込みは確認の対象にする

エージェントに確認なしで使わせる CRM のツールは、読み取り専用にします。まず、パーミッションの設計上の理由があります。パーミッションはツールの名前で確認の対象を決めるので、読み取りのツールで商談のステータスや接点履歴まで書き込めてしまうと、確認を通らずに「事実」が書き換わる経路ができてしまいます。書き込みは別の名前のツールに分けて、確認の対象にしましょう（第 2 章）。認可の仕組みから考えても、同じ結論になります。資料置き場（Google Drive）には、読み取り専用のスコープだけを要求します。後から書き込みのスコープを追加しても既存のトークンには付かず、すべての案件で同意を取り直す必要があるからです。しかも執筆時点では、Drive の読み取りスコープは Google の分類で制限付き（restricted）にあたり、審査に第三者によるセキュリティ評価が加わります（Google の解説）。読み取りだけで済む設計にしておけば、審査の範囲が広がることはありません。

「鍵がある」と「読める」は違う

Notion の連携には 2 種類あります。内部インテグレーション（クライアントのワークスペース側で作るもの。審査は不要で、接続したページだけを読める）と、パブリックインテグレーション（こちら側で作るもの。審査が必要）です。案件ごとに別のワークスペースを読む構成では、クライアント側に内部インテグレーションを作ってもらうのが、実質的に唯一の選択肢になります。機能は「コンテンツの読み取り」だけで十分です。

ここには注意すべき点があります。Notion はページ単位で接続を許可する仕組みなので、トークンが有効でも、接続していないページは検索にも出てこず、取得もできません。それなのにユーザー情報の API は成功するので、「つながっている」ように見えてしまいます。そのため、疎通確認は検索 API まで実際に呼び出し、件数を確認します（原則 B）。0 件のときに疑うべきなのは、権限ではなく接続の漏れです。親ページに接続すれば、その配下のページにも接続が引き継がれます。

Google Drive は、サービスアカウント（人ではなく機械が使う Google アカウント）の鍵で読みます。ここにも同じような問題があります。Google Cloud の IAM ロールを付けても、Drive の中身を読む権限は付きません。読ませたいフォルダを鍵のメールアドレスに共有して、初めて中身が見えるようになります。共有を忘れると、鍵はあるのに一覧が空で返ってきてしまい、権限が不足しているのと見分けがつきません。クライアントが所有しているドライブの場合は、資料をフォルダ 1 つに集めてもらい、そのフォルダだけを共有してもらうのが現実的です。また、Google 形式のファイルは実体をダウンロードできないので、書き出して取得します。執筆時点の既定では、スプレッドシートを CSV で書き出すと 1 枚目のシートだけが出力されます（書き出し形式）。共有ドライブのファイルは、共有ドライブを含める指定を付けないと一覧に出てきません（files.list）。

API のバージョンは 1 箇所で管理します（原則 G）。Notion の API はバージョンヘッダが必須で、バージョンによってエンドポイントの形が変わります。執筆時点では「データベース」と「データソース」が分かれたバージョンがあり、行の取得はデータソースに対して行います（リファレンス）。バージョンを上げたり下げたりする場合は、呼び出すエンドポイントも一緒に変える必要があります。古いバージョンには、新しいパスは存在しません。

鍵はサーバー側、書き込みは差分と確認

エージェントには、CRM のトークンを渡しません（原則 I）。エージェントが Bash を使える場合、環境変数に入っている鍵はそのまま使えてしまうからです。外部 API は MCP ツールを通して呼び出し、鍵はサーバー側に置いたまま、エージェントには作業ごとの使い捨てのトークンだけを渡すようにします。また、読み取りのツールには書き込みの機能を実装しません。「読み取り専用」はプロンプトでのお願いではなく、ツールに書き込みの機能が無いという仕組みで守ります。

書き込みは差分で出します。「ステータスを担当者検討から担当者合意へ、次アクションを『見積送付』へ」のように、何を何に変えるのかを人が読める形で書き込みのツールの引数に入れ、確認画面で許可されたら実行します。確認画面に表示されるのはツールの名前と引数だけなので、商談の ID だけでは人は判断できません。企業名や現在の値も引数に含め、ツールの側で ID と食い違っていないかを確かめるようにしましょう。取得できなかったときや書き込めなかったときは、ゼロや成功で埋めずに「未取得」と対処法を返します（原則 C・W）。対処法には、内部のファイル名や設定名を書かないでください。画面にそのまま表示されるので、利用者にはそれを開く手段がありません。

図は横にスクロールできます。図を原寸で開く

図の元になった mermaid を見る

mermaid

flowchart LR
  AI["エージェント（実行ごとの使い捨てトークン）"] -->|"読み取り専用ツール"| MCP["MCP サーバー<br>鍵はここに閉じる"]
  MCP -->|"検索・取得"| CRM[("CRM<br>企業 / 商談 / 議事録")]
  MCP -->|"一覧・書き出し"| DRV[("資料置き場<br>提案 / 実績")]
  AI -->|"更新のツール（差分を引数に）"| Q["確認画面<br>パーミッション"]
  Q -->|"人が許可（1 回限り）"| W["書き込み"]
  W --> CRM
  Q -.->|"断る・コメントで直し方を伝える"| AI
  EV["返信 / 問い合わせ / 送信ログ"] -->|"自動起票"| CRM

入力を減らす

「入力されない項目は存在しないのと同じ」という考え方を設計に落とし込むと、やることは 4 つです。1 つ目は、事実を自動で起票すること（反応・議事録の要約・シグナル）。2 つ目は、人が書く項目を選択式にすること（ステータス・失注理由・チャネル）。3 つ目は、識別子を手入力させず一覧から選ばせること（原則 F。ID の打ち間違いは権限不足と同じエラーになり、原因を切り分けられません）。4 つ目は、リレーションを必須にすること（企業に紐づかない議事録や商談を作れないようにする）です。入力の手間が減って初めて、停滞検知とフォーキャストが信用できる数字になります。

他の CRM でも同じ

正本がスプレッドシートでも市販の CRM でも、エンティティ・一意キー・ステータス・読み書きの分離の設計は同じです。変わるのは、API の呼び方と認可の形（OAuth か API キーか、権限の単位がページか組織か）だけです。作る前の判断も姉妹記事と同じ順番で、使っている基盤の公式コネクタ、公式 API や CLI、既存の OSS のラッパーの順に検討し、それでも無ければ自作します。MCP（Model Context Protocol）で公開されているコネクタがある場合は、読み取り専用のツールだけを使える設定にして利用しましょう。

章のまとめ

• 営業のオントロジーは企業（法人名＋ドメイン）・担当者（メールアドレス）・商談・契約・接点履歴の 5 つ。誰が起票するかを先に決める
• ステータスは排他・網羅で、遷移条件を事実で書く。確度の数字より遷移条件。失注には理由を必須にする
• リード発掘はシグナルを定義してから探し、原文と URL と観測日を残し、登録の時点で一意キーで重複排除する。ゼロ件は正常
• Meta（Facebook・Instagram）と TikTok は利用規約で自動収集を禁じている。見込み客の SNS の数字や探索投稿は人が検索して記録し、エージェントはその記録を読む
• 企業調査・事例・ブリーフは Web だけで成立させ、CRM は読み取り専用で強化する。取れないものは「未取得」
• 文面の量産は上流（調査）・エンジン（書くだけ）・下流（送信）に分け、根拠の列と要レビューの印で捏造を防ぐ。送信のツールは確認の対象（ask）
• 議事録要約と反応の自動起票で人の入力を減らし、ステータスの遷移だけ人が押す
• 停滞検知と加重予測は決定的なコードで行い、生成 AI は文面だけ。結果は毎朝の通知として push する
• CRM の書き込みは差分を確認画面で見て許可する。鍵はサーバー側。「鍵がある」と「読める」は疎通確認で分ける
• 大型の見込み客は、中期経営計画の目標と実績の差、財務の余力、媒体ごとの SNS の状況を並べ、事実と仮説を分けて書く
• 事例は与件を 6 項目で構造化してから探し、4 種類の調査先に当たる。数字と出典のある事例を優先し、見ていない範囲は調査の記録に書く
• 複数社の調査はサブエージェントに分け、返す項目をアウトリーチの入力 CSV の列に揃える
• PR と登壇のリストは、各行に根拠の実記事と公開の窓口を付ける。送信と応募は人が行う
• 提案と受注後の定例は工程の受け渡しで組む。提案は与件把握 → 企業調査 → 事例調査 → アイデア調査・施策の熟考 → ストーリー構築 → 提案概要の登録と承認 → 資料作成 → 品質チェック・商談準備。定例は与件・前回宿題の把握 → 実績調査・集計 → 分析・翌月企画 → レポート資料 → MTG 準備・実施 → 議事録の還流。省略できない工程（提案: 調査 2 つ・承認・原本の複製 / 定例: 実績・還流）を先に決め、調査はサブエージェント、書き込みはメインの会話で行う
• こちらから探すリードと向こうから来るリード（検索・AI 検索・LP）は、同じ一覧・同じ一意キーで持つ。BtoB では求人票の本文・部署別の人員の増減・競合の顧客がシグナルになる
• アドレスは文面を書く前に検証する（形式 → MX レコード → ラベル）。優先順位は決定的なスコアで付け、重みは受注と失注の両方の表から逆算する
• フォローアップは反応で分岐し、返信があれば必ず止める。送信は営業用のドメインから行い、本体のドメインの評判を守る
• 商談の行に流入元を選択式で残し、メールアドレスとドメインを鍵にコンテンツの成果と契約をつなぐ。流入元をまたいで足さない

演習

1. 自社の営業の流れを、この章の 1 枚目の図の形で描き直してみましょう。図の各工程に「どのツールが担うか」と「人が判断する箇所」を書き添え、対応するツールが無い工程を 1 つ選んでください。それが最初に作るものです。
2. CRM のステータスを排他・網羅で書き出し、各ステータスに「誰が見ても同じ答えになる遷移条件」を付けてみましょう。遷移条件を付けられないステータスは、定義が曖昧なまま使われています。
3. 停滞検知の疑似コードを自社の CRM の項目名で書き換え、閾値を 1 箇所の設定に置いてみましょう。まずは通知だけを毎朝 1 通流し、1 週間後に閾値を見直します。
4. 見込み客の条件（業種・地域・時期）を 1 つ選び、この章の例にならって「探している」の定義を 5 項目で書き出してみましょう。1 週間分の公開投稿で試し、温度が「高」になった件数と、定義を直したい点を記録します。
5. 過去 1 年に受注した全アカウントと失注したアカウントを 1 行 1 社の表にし、属性の列を 10 個以上並べてみましょう。受注した側にだけ偏っていて、自社の ICP の資料に書かれていない属性を 3 つ探し、リードスコアの適合の項目に追加します。

次の章へ

ここまで、営業・広告・SEO・SNS・LINE と、領域ごとの自動化を見てきました。第 11 章「全体最適を考える」では、これらの領域をまたいで数字を並べる方法（合算しない）、実験の回し方、タスク・定期実行・トリガーの置き場所、人が判断する点と通知の設計、そして外部から操作するための仕組み（外部 MCP・API モード）についてまとめます。