ワークフロー

ワークフロー詳解

Sales Claw が企業ごとに実行する 2 フェーズの処理フロー全体を解説します。

絶対ルール: フォームへの実入力とスクリーンショット撮影が完了するまで、awaiting_approval ステータスにしてはいけません。 スクリーンショットなしでは承認判断ができません。

2 フェーズ処理の概要

Sales Claw は複数社を処理する際、フェーズ A(並列)フェーズ B(順次) の 2 段階で処理します。

Phase A

企業分析・メッセージ生成

  • MCP Playwright 不使用
  • haiku サブエージェントで並列実行
  • 企業サイト HTTP フェッチ
  • 事業ドメイン・ギャップ分析
  • CLI 用メッセージプロンプト生成
Phase B

フォーム入力・スクショ

  • MCP Playwright 使用
  • 1 社ずつ順次処理
  • フォーム構造解析
  • 全フィールド実入力
  • スクリーンショット必須撮影

Phase A: 企業分析(並列処理)

複数社の処理では、まず全社の「企業分析+メッセージプロンプト構築」を並列で実行します。 この処理は MCP Playwright を使わず、直接 HTTP フェッチで企業サイトを解析します。

各社に対して以下を実行します:

  1. 企業の公式サイトを HTTP フェッチ(parallel-analysis.cjs
  2. 事業内容・注力分野・サイト構造を抽出
  3. 自社強みとのギャップ分析
  4. CLI 用プロンプト(messagePrompt)を生成
  5. フォールバック用テンプレート文面(templateDraft)を生成
  6. POST /api/log-actionsite_analysis を記録
Phase A は haiku モデルのサブエージェントで並列実行するため、コストと時間を大幅に削減できます。 3 社同時処理でも、Opus での逐次処理と比べて 70〜80% のコスト削減効果があります。

Phase A.5: CLI メッセージ生成

Phase A の分析結果と messagePrompt を受け取り、CLI(Claude/Codex/Gemini)が各社向けの最終文面を生成します。templateDraft は CLI 生成に失敗した場合のフォールバックとして使用します。

良いメッセージの条件

  • 相手の事業や取り組みへの言及から始まる
  • テンプレート感がなく「この会社だけに書いた」文面
  • 強みを全部詰め込まず、1〜2 点に絞る
  • 課題を決めつけず、提案として提示する
  • 読了時間 1〜2 分以内(400〜600 文字が目安)

Phase B: フォーム入力(順次処理)

1 社ずつ、MCP Playwright を使ってフォーム入力を実行します。

Step 1: フォーム URL の探索

既知の formUrl がある場合はそこに遷移します。 ない場合は、企業サイトの「お問い合わせ」「Contact」「資料請求」「パートナー」リンクを Playwright で辿ります。 公式 URL がない場合は WebSearch で「会社名 + 公式」を検索して特定します。

Step 2: フォーム構造解析と NG 判定

browser_snapshot でフォーム構造を解析し、以下に該当する場合は スキップ します:

  • 「営業目的のお問い合わせはご遠慮ください」
  • 「既存顧客専用」「採用専用」「IR 専用」「報道専用」
  • フォーム自体が表示されない / Cloudflare ページゲートで本体到達不可
CAPTCHA が検出された場合は、フォーム入力(Step 3)まで進め、awaiting_approval(人間が CAPTCHA を解いて送信)にします。 フォーム入力をせずにスキップするのは誤りです。

Step 3: フォームへの実入力(絶対省略不可)

browser_fill_form / browser_type / browser_select_option を使い、 全フィールドに実際に入力します。

最低限の入力項目:

  • 会社名(companyProfile.companyName
  • 担当者名(companyProfile.contactName
  • メールアドレス(companyProfile.email
  • 電話番号(companyProfile.phone
  • 問い合わせ本文(Phase A.5 で生成した文面)
問い合わせ本文は 連絡先のダンプ(TEL/MAIL だけ)を絶対に入力しない こと。sentMessage が 30 文字未満だと API ガードで 422 エラーになり、ログに記録されません。

Step 4: スクリーンショット撮影(絶対省略不可)

browser_take_screenshotscreenshots/ss-{No}-input.png を保存します。 確認画面がある場合は ss-{No}-confirm.png も撮影します。

Step 5: 確認待ちに登録

Step 3・4 が完了していることを確認してから、awaiting_approval を記録します:

curl -X POST http://127.0.0.1:3765/api/log-action \
  -H "Content-Type: application/json" \
  -H "x-sales-claw-session: $SALES_CLAW_SESSION" \
  -d '{
    "no": 1,
    "name": "株式会社テクノロジー",
    "action": "awaiting_approval",
    "details": {
      "sentMessage": "お世話になります。株式会社サンプルの山田です...",
      "screenshot": "ss-1-input.png",
      "finalFormTab": "https://example.co.jp/contact",
      "tabKept": true
    }
  }'

承認フロー

ダッシュボードの「確認待ち」タブに各社のスクリーンショットと生成メッセージが表示されます。 内容を確認して「送信」または「却下」を選択します。

送信

ブラウザのタブに残っているフォームから手動で送信ボタンをクリック → submitted に更新

却下

メッセージや企業が不適切と判断した場合。rejected に更新

編集して再生成

文面を修正して再生成。Phase A.5 からやり直し