目次
結論
編集部(ALLFORCES)は、補助金(IT導入補助金・ものづくり補助金・事業再構築補助金)を受給した企業のうち登録企業プロファイル2万社超を対象に、各社のWebサイトを解析してカスタマイズした営業提案を自動生成し、問い合わせフォーム経由で送信するAI営業パイプラインを自社開発・運用した。5段階のステージ構成で、Web調査完了2,900社、カスタム提案生成2,400件、営業メール生成2,300件、フォーム送信完了2,700件超という規模で稼働した実績がある(いずれも各段階の累積実行回数であり、単純な歩留まりの系列ではない)。本稿は営業成果を語るものではなく、このパイプラインの設計・運用を通じて得た工学的な知見、とりわけ「AIに検索や調査を指示しても、ツールが実際に実行された保証がなければ、その出力を”検証済み”として扱ってはならない」という失敗から学んだ設計原則を記録するものである。相手企業への言及、成果の誇張は行わない。（出典: 自社パイプライン実行ログの内部集計、2026年8月時点）
パイプラインの前提と安全設計
補助金を受給した企業は、AI/DXへの投資意欲と予算があるという仮説のもとに対象を選定した。テンプレート営業ではなく、企業ごとの事業内容・採用状況から課題を推理し、具体的な解決策まで踏み込んだ提案を生成する設計を目指した。
安全設計は以下の通りである。
- 人間の承認必須: メール生成後、送信前に人間がレビューしない限り送信されない。
- 日次送信上限: メール送信(Stage 4)は10件/日(設定変更可能)。後述のフォーム送信(Stage 5、Playwright MCP経由)にはこの上限の実装がなく、運用初期には日次上限のない一括送信を行った期間がある(詳細は次節)。
- クールダウン: 同一企業へは90日間再送信しない。
- オプトアウト: 配信停止リストを管理し、特定電子メール法の要件に沿う。
- フォーム送信: 最終送信ボタンは必ず人間がクリックする設計とし、全自動送信にはしていない。
出典: 自社パイプライン設計仕様の内部記録による
アーキテクチャと処理規模
パイプラインは以下の5段階(および補助ステージ)で構成した。
1
2
3
4
5
6
7
Stage 1: リード抽出(補助金採択リストから対象企業を抽出)
-> Stage 2: Web調査(Playwright + Claude、企業サイトから事業内容・課題を分析)
-> Stage 2.5: 深掘り調査(求人・ニュース・業界動向)
-> precheck: フォーム到達可否チェック(HTTP並列30、CAPTCHA・営業お断りを事前判定)
-> Stage 3: 提案生成(Claude Sonnet × 並列8、企業固有の課題推理から解決策提案)
-> Stage 4: メール生成(Claude Sonnet × 並列8、提案を営業メールに変換)
-> Stage 5: フォーム送信(Playwright MCP、問い合わせフォームへの自動入力・送信)
各ステージの累積処理数は次の通りである。
| 指標 | 数値 |
|---|---|
| 企業プロファイル | 20,000社超 |
| Web調査完了 | 2,900社 |
| カスタム提案生成 | 2,400件 |
| 営業メール生成 | 2,300件 |
| フォーム送信完了 | 2,700件超 |
出典: 自社パイプライン実行ログの内部集計、2026年8月時点
フォーム送信完了件数がメール生成件数を上回っているのは、複数回の実行にまたがる累積カウントであり、1回のパイプライン実行内での歩留まりを示す数値ではない。また、前節の「日次送信上限10件」はメール送信(Stage 4/outbound_sender)に対する設定であり、フォーム送信(Stage 5)のコードにはこの上限のチェックが実装されていない。実際、送信ログでは2026年3月26日に759件を一括送信し、2026年4月には日次300件超の日が複数回発生している(送信ログ上の最大は同月24日の462件)。フォーム送信完了2,700件超という規模は、この上限なしの一括送信期を含めた累積である。開発・運用は2026年3月から継続しており、同年7月には無人運用向けの堅牢化(冪等リトライ・安全停止機構)を追加している。（出典: 同上、自社送信ログ）
失敗から学んだ設計原則
パイプラインの「Stage 2.5: 深掘り調査」は、企業ニュース・求人情報・業界課題をWeb検索で調べ、その結果をもとに「根拠付き課題(verified_pain_points)」というフィールドに格納する設計だった。この段階の実装は、Claude CLIをclaude -p --model sonnetという形でサブプロセス呼び出しし、プロンプト内で「Web検索を使って調べてください」「推測は書かないでください」と指示する方式を採っていた。
ここに設計上の欠陥があった。このサブプロセス呼び出しには、非対話環境でツール利用を許可する--permission-modeや--allowedToolsの指定を入れていなかった。対話端末(TTY)がないバッチ処理の中でツール利用の承認が得られなければ、Web検索が実際には実行されないまま、モデルがプロンプトの指示に応じてもっともらしい体裁の出力(ニュース・求人情報の箇条書き)を返す可能性がある。プロンプトの中でどれだけ「推測は書かないでください」と指示しても、呼び出し側がツールの実行結果そのものを検証していなければ、その出力が実在の一次情報に基づくことは保証できない。にもかかわらず、統合処理ではその出力の一部をverified_pain_pointsという、検証済みであることを示唆するフィールド名でJSONに格納していた。推測を検証済みとラベル付けすること自体が、パイプライン設計として危険だった。
この経験を踏まえ、編集部では以降のプロジェクトで「生成・判定を担うパイプラインの内部でCLIをサブプロセス呼び出しする設計は避け、ツール実行の可否・結果を呼び出し元のコード側で明示的に検証できる構成にする」という方針に転換した。CLIの対話的な権限モデルは、無人実行前提のバッチ処理とは相性が悪く、ツールが使えているように見えて実は使えていない状態を静かに生む。誠実な設計とは、指示文でモデルに「正直に書いて」と頼むことではなく、ツールが実際に動いた証拠をコード側で確認できる形にすることだと考えている。
開示していないこと
本稿は工学的な設計・処理規模の記録に徹し、以下は開示していない。相手企業の名称・業種・個別のやり取りへの言及は行わない。返信率・商談化率・受注率等の営業成果は、社内で体系的に検証したデータを持たないため、本稿では述べない。API利用コストについても、具体的な金額を検証済みの数値として持っていないため記載しない。「フォーム送信2,700件超」等、社内の実行ログから直接集計できる自社計測値のみを記載している。（出典: 同上、自社実行ログ）
まとめ
補助金採択企業2万社超を対象としたこのパイプラインは、Web調査からカスタム提案生成、フォーム送信までを自動化する構成として実運用に至った。得られた最大の教訓は、AIパイプラインの信頼性は「もっともらしい出力を生成できるか」ではなく、「ツールが実際に実行されたことを検証できる設計になっているか」に依存するという点である。同様のAIエージェント・パイプラインの設計を検討している方の参考になれば幸いである。（出典: 同上、自社パイプライン実行ログの内部集計）