副業案件の募集が1日50件流れるクラウドで、条件に合う案件を抽出し、応募文を生成し、送信前まで自動化した。2週間で5件の商談、1社と契約。ただし最終送信は手動で残した。その判断基準と、自動化する工程としない工程の境界をどう引いたかの記録。
副業マッチング自動化を始めた背景
「また締め切られている」。副業募集サイトで気になる案件を開くと、公開から3時間で応募が締め切られていました。
営業代行の案件を探していた時期、1日に50件ほど新着が流れてくるクラウドサービスを巡回していた。ただ、条件に合うものは5件程度。それを手作業で探し、応募文を書き、送信する。ここに1日2時間かかっていました。
問題は、時間ではなくタイミングです。夜に巡回していると、昼に公開された良案件はすでに埋まっている。通知を受け取っても、そのたびに作業を中断して応募するわけにはいかない。商談に集中したいのに、案件探しに時間を取られている状態でした。
方針を決めた。条件マッチング、応募文生成、送信準備までを自動化し、最後の送信だけ人が確認する。ここまでを2週間で組みました。
条件抽出と応募文生成の設計
最初に決めたのは、どこまでをルールベースで処理し、どこから LLM に渡すかの境界です。
クラウドサービスの API から案件リストを取得し、条件に合うものだけをフィルタリングする部分は、Python のスクリプトで組んだ。報酬額、稼働時間、リモート可否、募集終了日。これらは構造化されているため、正規表現と辞書マッチで処理できる。
次に、抽出した案件の募集文から「求められているスキル」と「納品物のイメージ」を読み取り、それに対応する応募文を生成する。ここは Claude API に渡した。プロンプトには、自分の経歴と過去に評価された提案文のテンプレートを含めた。案件ごとに文章を生成させ、Notion のデータベースに保存する。
生成された応募文は、件名・本文・添付資料の3要素に分解して格納した。送信時に人が見直す前提のため、どこを修正すべきか一目でわかる構造にする必要があった。応募自動化の仕組み自体は動いても、生成された文章の質が低ければ商談には繋がらない。
実装には Cursor と Claude Code を併用した。API 接続部分は Cursor で補完を効かせながら書き、プロンプト設計と出力の調整は Claude Code で対話しながら詰めた。コードは GitHub に push し、Render で自動デプロイ。1日3回、定時実行される cron job として動かしています。
最終送信を手動で残した理由
自動化の範囲を決める際、最後まで迷ったのが送信ボタンを押す工程でした。
技術的には、API 経由で応募を完了させることも可能です。ただ、そこまで自動化すると「誰が応募したのか分からない」状態が生まれる。クライアント側から見れば、テンプレート感のある提案が機械的に送られてくる印象になる。
私たちが自動化したかったのは「条件に合う案件を見つける作業」と「応募文の初稿を作る作業」であって、「提案する判断」ではなかった。最終的に送信するかどうかは、案件の背景や募集文の行間を読んで決めたい。そのため、Notion に生成された応募文が溜まった時点で通知を Slack に飛ばし、そこから人が目を通して送信する設計にしました。
結果として、2週間で12件の応募文が生成され、そのうち8件を送信。5件が商談に進み、1社と契約しました。自動化しなかった場合と比べて、応募数は3倍、商談率は変わらず。ただ、案件探しにかけていた時間がほぼゼロになり、その分を商談準備に充てられるようになった。
副業マッチング自動化で見えた境界
自動化する工程としない工程の境界は、「判断が必要か」ではなく「判断の結果に責任を持つか」で引くべきだと考えています。
条件抽出は判断ではなく選別。応募文生成は判断ではなく下書き。送信は、相手の時間をもらう行為であり、そこには責任が伴う。だから人が出る。
この構造は、他の営業自動化にも適用できると考えています。リード抽出、初回メール生成、送信判断。工程を分け、それぞれに適切なツールと人の関わり方を設計する。完全自動化ではなく、人が集中すべき工程に時間を寄せる設計です。
いま、同じ仕組みを別のクラウドサービスにも展開しています。API 仕様が異なるため、パーサー部分を書き直す必要がある。ただ、プロンプト設計と Notion への格納ロジックは使い回せる。この「部分的に再利用できる自動化」が、少人数で複数の営業チャネルを回す鍵になると感じています。