新卒のみだったスカウト対象を中途採用候補者にも拡張。ジョブホッパー検出・中途専用プロンプトを新設する。
NEW
中途採用媒体への自動スカウト送信を新規実装。対象媒体は Green・ビズリーチ・ambi に確定（キミスカを4媒体目として追加）。Green
を先行して着手する。セグメントはビズリーチ＝全方位、ambi＝若手層、Green＝専門職・エンジニアで使い分ける。
NEW
homula 外販展開に向け、クライアント × 媒体 単位で独立管理できるワークフロー複製方式を確立する。
NEW
Google スプレッドシートのログ限界を将来的に解消するため、PostgreSQL 等の本格DBへの移行を検討。Phase 2 では導入せず、スプレッドシート運用を継続する。
NEW
2
Phase 1 → Phase 2 変更サマリー
データストレージ
Google スプレッドシートのみ
→
対象媒体
Green・ビズリーチ・ambi に確定（＋キミスカを追加）。Green を先行着手
データストレージ
Google スプレッドシート継続（DB移行は将来構想）
候補者分類
Type-A〜E 継承 + ジョブホッパー検出追加
プロンプト管理
時期別（新卒）+ タイプ別（中途）計7種
Phase 2
で新設する中途採用候補者向けの処理フロー。ジョブホッパー検出・中途向けメッセージ生成を新たに組み込む。RPA層では全ページ取得（ページネーション）と、n8n連携前の送信可否「事前判定」を行う（詳細は巻末「改修備考」を参照）。
ブックマーク
（人間）
→
RPA起動
対象媒体
→
レジュメ取得
全ページ
→
事前判定
送信可否
→
区分判定
（中途）
→
ジョブホッパー
判定
→
→
Type分類
A〜E
→
中途向け
メッセージ生成
→
品質ゲート
HG + AI
→
送信
対象媒体
→
ログ
スプレッドシート
職歴・転職回数・在籍期間からLLMで分類。Type-A〜Eは新卒と共通化しつつ中途固有の観点を追加。
NEW
LLMがプロフィール全体を評価しType-D判定。キーワード辞書を使わず誤検出を最小化。理由を type_d_reason に記録。
NEW
実績・スキルをフックとする中途専用プロンプト。「活躍イメージ」と「即戦力への期待」を軸に構成。
NEW
中途は就活シーズンが存在しないため時期判定を行わない。候補者タイプのみでプロンプトを選択する。
CHANGE
対象媒体のブックマーク／関心リストに登録された候補者のレジュメを自動スクレイピング。ページネーション必須（2ページ目以降も全件取得）。媒体ごとに必要な認証突破ロジックを実装する。
NEW
n8nにデータを送る前段で「実際に送信可能か」を媒体UI上で判定し、送信不可な候補者を除外。送信枠不足・送信ボタン非活性・媒体側ブロック等を実送信と同じフローで確認する。スプレッドシートログとUI上の送信数の乖離を防ぐ。
NEW
承認済みメッセージを各媒体に自動送信。IPローテーション・送信時間ゆらぎによるBAN対策を媒体ごとに適用。
NEW
GCP Secret Manager でクライアント・媒体ごとに認証情報を完全分離。Cloud Run のサービス間で環境変数として注入。
INHERIT
プロンプト管理・スプレッドシート・修正依頼フローをクライアント単位で独立管理。外販対応の基盤を整備。
NEW
Auto送信ルートでもタイムスタンプを記録。再送信時の履歴重複を防ぐため、ログ書き込み前に candidate_id
／送信対象キーで既存ログを照合する。現状ログは UTC（JST化はコード対応が必要）。
NEW
スプレッドシートのログ限界を将来的に解消するため、本格DB（PostgreSQL 等）への移行を検討。Phase 2 では導入せず、スプレッドシート運用を継続する。
FUTURE
各媒体での RPA 適用可否を実機検証し、あわせて Phase 2 で使う実行基盤を再評価しました。対象媒体は Green・ビズリーチ・ambi
に確定（キミスカを4媒体目として追加）。Green を先行して着手します。ビズリーチはアカウント発行・検証から、ambi はログアウト検知の検証から進めます。実行基盤はPhase 2 では n8n＋Playwright (Cloud Run) 構成を前提として実装し、Phase 1 を含めた Robocorp
からの移行可否もあわせて検討します。
5-1. 媒体別 RPA 適用可否（実機検証済み）
媒体
① ログイン
② レジュメ取得
③ メッセージ送信
総合判定
OfferBox
Phase 1 稼働中
✓
✓
✓
実用中
ビズリーチ
未契約・未検証
未検証
未検証
未検証
契約後に検証
運用上の留意点：
-
ambi：ログイン時に「私はロボットではありません」認証（reCAPTCHA）あり。一度ログインすれば数日間セッションが維持される想定のため、人が適宜ログインを通す運用で対応可能。ログアウト検知と復帰フローは検証中
-
キミスカ：管理者ユーザの同時ログイン制限があり、人間の利用と取り合いになる。RPA専用アカウントを別途発行する運用設計を推奨。また媒体側に自動送信・AI文書生成機能が標準装備され、曜日・送信数の指定も可能なため、T3の機能と重複する。運用範囲の切り分けを要確認
- レバテックダイレクト：媒体側に「気になる自動送信」「AIで自動生成（β版）」機能が標準装備されているため、T3の機能と重複する可能性あり。運用範囲の切り分けを要確認
5-2. 新規媒体追加時の評価フレーム
非エンジニアでも媒体の RPA 可否を判断できるよう、3つの関門で整理。
01 — TECH
ログイン認証方式
ID＋パスワードのフォーム入力なら基本的に自動化可。CAPTCHA／2段階認証／SSO／生体認証は要工夫または不可。
02 — OPS
Bot対策・アクセス制限
CAPTCHA・速度制限・IP制限・アカウント保護で止まらないか。操作間隔・実行頻度・IP戦略で対応する。
03 — LEGAL
利用規約・契約
自動アクセス・スクレイピング禁止条項の有無を確認。技術可否と別に「やってよいか」を必ず判定する。
判定の目安：TECH・OPS・LEGAL がすべて○ → 実用可能 ／ TECH/OPS に△あり →
条件付き可（工夫・追加コスト） ／ LEGAL が× → 不可（規約NG）
5-3. 実行基盤の移行検討（n8n＋Playwright on
Cloud Run）
Phase 1 の Robocorp
中心構成には、定期実行が手動・UI二重管理・運用コストといった課題があるため、別構成への移行を検討中。移行可否は今後の評価次第。
現状
Robocorp → n8n → Robocorp
- 毎回手動でRobocorpを起動
- Control Roomとn8nのUI二重管理
- Robocorp Control Room費用が発生
→
移行候補(検討中)
n8n Schedule → Cloud Run (Playwright)
- n8n Schedule Trigger で定期実行を自動化
- UIが n8n に一本化
- Cloud Run 月$1〜5 で運用コスト削減
移行候補のアーキテクチャ(採用は未確定)
n8n Cloud（オーケストレーション） 既存活用
Schedule Trigger 定期実行 ／ Manual Trigger Run UI ／ AI生成・スコアリング・スプレッドシート連携を担当
↓ HTTPS（IAM／APIキー）
Cloud Run（Playwright サービス） 移行時に新規構築
FastAPI + Playwright (Chromium headless)
POST /candidates 検索条件→候補者リスト＋レジュメ ／ POST /scout スカウト送信（DRY_RUN対応） ／
GET /healthz ヘルスチェック
↓ 認証情報注入
GCP Secret Manager 移行時に新規構築
各媒体・各クライアントの認証情報を暗号化保管 ／ Cloud Run 起動時に環境変数として注入
5-4. ホスティング選定
Cloud Run（GCP）推奨
$1〜5
使った分課金 ／ Google連携 ／ 60分タイムアウト ／ デプロイ簡単
コールドスタート5-15秒（定期実行では影響軽微）
Render.com
$7常駐
git push でデプロイ ／ Dockerfile 不要
常駐課金 ／ IP は可変
VPS 固定IP（Lightsail等）
$5〜10
固定IP で BAN 対策に有効
サーバ保守必要（OS 更新等）
5-5. 移行した場合に期待される効果と工数（移行可否は未確定）
EFFECT 01
運用負荷の低減
移行した場合、Schedule Trigger で定期実行が自動化され、毎日の手動起動・属人化が解消される。
EFFECT 02
UIの一本化
移行した場合、Control Room と n8n の二重管理が解消され、クライアントの操作箇所が n8n に集約される。
EFFECT 03
コスト削減
移行した場合、Robocorp 費用を廃止し、使った分だけ課金される Cloud Run（$1〜5/月）へ置き換え可能。
移行開発工数：合計 約1週間
Cloud Run用Playwrightサービス実装（2-3日）／ n8nワークフロー再構成（1日）／ Cloud Run・Secret Managerデプロイ（0.5-1日）／ 動作検証（1日）／
ドキュメント整備（0.5日）
移行前にクリアしたい項目：各媒体の利用規約上の自動アクセス可否（法務確認）／
既存n8nワークフローのコピー方針 ／ テスト送信用候補者IDの指定 ／ GCPプロジェクトの準備 ／ キミスカ向けRPA専用アカウント発行 ／ ambiのログアウト検知・復帰フロー検証完了
多層防御パイプライン
①
RPA 抽出チェック
レジュメ取得の成否を厳格に判定。失敗時は EXTRACT_FAIL としてスキップし次へ進む。
EXTRACT_FAIL
②
ジョブホッパー判定（中途のみ）
LLM がプロフィール全体を評価。Type-D 判定された候補者は以降の処理へ進まない。
Skipped_TypeDtype_d_reason
③
ハードルール検証（HG-01〜06）
変数残留・禁止語・文字数逸脱・形式不備を正規表現・単純ロジックで即時判定。
HG-01 変数残留
HG-02 禁止語
HG-03 文字数
HG-04 形式
④
AIスコアリング（Gemini Flash）
幻覚・トーン・断定表現を0〜100点で評価。スコアに応じて3段階に振り分ける。
80〜100点 Auto送信
50〜79点 承認待ち
〜49点 送信禁止
⑤
重複チェック（送信ログ照合）
send_dedup_key の UNIQUE 制約をDBレベルで保証。媒体・クライアントをキーに含め二重送信を防止。
{candidate_id}_{client_id}_{platform}_{ver}_{date}
AIスコアリング閾値
品質スコア帯と処理アクション
0〜49点
送信禁止
50〜79点
承認待ち
80〜100点
Auto送信
承認フロー（Human-in-the-loop）
75〜79点
最初3件のみ目視 → 問題なければ残り一括承認（目安2分）
60〜74点
1件5秒ルールで目視。迷ったらNG（目安5分）
50〜59点
一括NG（目安30秒）
「完全自動化はできるのか？」への回答。送信まで多くの工程を自動化するが、グレーゾーン（AIスコアが中間帯）のメッセージは必ず人の目視判断を経由する設計。誤送信リスクを構造的にゼロにするため、意図的に人のレビューを残している。
① 候補者の選定・ブックマーク
手動
エンドクライアント 各媒体上で候補者を選びブックマーク／関心リスト登録。ここは採用要件の解釈が必要なため自動化しない
② レジュメ取得
自動
n8n の Schedule Trigger により、Cloud Run 上の Playwright サービスが定期実行で各媒体をスクレイピング
③ ジョブホッパー判定
自動
Claude Sonnet がプロフィール全体を評価。Type-D は自動除外（送信禁止）
④ 候補者分類・メッセージ生成
自動
Type-A〜E 分類 + 中途向けプロンプトで Claude Sonnet がメッセージを生成
⑤ ハードルール検証
自動
変数残留・禁止語・文字数逸脱をプログラムで即時判定。NG なら送信禁止
⑥ AIスコアリング
自動
Gemini Flash が 0〜100 点で評価
⑦ 承認判断
ハイブリッド
80点以上は自動承認 ／ 50〜79点はエンドクライアントが Google スプレッドシート上で目視判断 ／ 50点未満は自動拒否
⑧ 各媒体への送信
自動
Cloud Run 上の Playwright が承認済みメッセージを自動送信（IPローテーション・送信時間ゆらぎ適用）
⑨ 候補者からの返信対応
手動
エンドクライアント 面談調整・質問回答は人が対応。自動返信はしない（ブランディング重視）
⑩ 送信エラー監視・定例レポート
ハイブリッド
T3 エラー発生時のみ対応。レポート出力は自動化、分析と改善提案は人
なぜ完全自動化しないのか 誤送信は企業ブランドに致命的なダメージを与える。Gemini の誤判定や
Claude
の幻覚による不適切なメッセージを完全にゼロにすることはAIの性質上不可能なため、スコア50〜79点の「グレーゾーン」は人のレビューを必ず経由させる設計とする。将来AIの精度が向上すれば閾値を引き上げて自動化率を高めることは可能（例：80→70点に引き下げ）。
基本方針：「クライアント × 媒体 × 候補者区分」単位でワークフローを複製・独立管理する
単一ワークフローに client_id
を渡して管理するのではなく、ワークフロー自体を分離することで障害の影響範囲を局限化し、クライアントごとの設定変更を安全に行える。
クライアントA
ClientA_中途_媒体A
検討中
＋ 追加時
n8n Workflow を複製
Robocorp Process を追加（移行検討中）
新規クライアントを追加するときの作業手順
クライアントA を新規追加する場合を想定。初回のみ発生する作業と、所要時間の目安を示す。実装は homula、運用設定は T3、情報提供はエンドクライアントが担当。
1
対象媒体アカウント・名義情報の受領
ID / PW・2要素認証解除・送信者署名・自社紹介文・NGワードなど（使用する媒体分まとめて）
クライアント
〜1週間
2
RPA基盤に認証情報を登録
クライアント × 媒体ごとに認証情報を登録（現行：Robocorp Process-level 環境変数／移行後想定：GCP Secret Manager）
homula
15分
3
n8n ワークフローを複製
クライアント別ワークフローを Duplicate → RPA基盤への認証設定を反映
homula
15分
4
Google スプレッドシートを複製
Approval_Queue / Send_History / Forbidden_Words の3シート構成をクライアント別に新規作成 → 共有権限付与
homula
10分
5
プロンプト・自社紹介文をカスタマイズ
受領した情報をクライアント別プロンプトに反映。固定テンプレートの <カスタム文章>
部分を差し替え
T3
1〜2時間
6
テスト送信・動作確認
少数のテスト候補者でエンドツーエンド動作を確認（送信はDryRunモード）
homula
1時間
7
クライアント向けオンボーディング
スプレッドシートの使い方・ブックマーク命名規則の説明ミーティング
T3
1時間
マルチクライアント運用時の「状態」 n8n ワークフロー・RPA基盤の認証情報・Google
スプレッドシートはクライアント別に完全に独立。クライアントAの障害がクライアントB・Cに波及しないため、運用中のクライアントを止めずに新規クライアントの追加・停止・設定変更が可能。共通の集計DBは Phase 2
では設けず、必要な集計はクライアント別スプレッドシートから個別に行う。
Phase 2 では Google スプレッドシートの運用を継続します。PostgreSQL
等の本格DB導入は将来構想として扱い、本フェーズでは設計・実装の対象外とします。
Phase 2 のデータ保管：Google スプレッドシートのみ
Phase 1 から継続して Google スプレッドシートを使用します。承認待ちキュー・送信履歴・禁止ワード辞書をクライアント別シートで管理し、重複送信防止は send_dedup_key
をスプレッドシート上で照合する方式を継続します。集計・レポート抽出はスプレッドシートの関数および手動エクスポートで対応します。
スプレッドシートで管理する主なシート
- Approval_Queue 承認待ち（スコア50〜79点）のメッセージ一覧。OK/NG を入力する作業シート
- Send_History 送信履歴。直近30〜90日分を保持し、古いものはアーカイブシートへ退避
- Forbidden_Words 禁止ワード辞書。ハードルール検証で参照する
- Send_Dedup_Key 重複送信防止のキー一覧（候補者ID × クライアント × 媒体 × テンプレートver × 日付）
将来構想：本格DBへの移行（Phase 2
では実施しない）
クライアント数・送信件数が増えるとスプレッドシートでは集計性能・行数制限・重複チェックの厳密性に限界が出てきます。将来的には PostgreSQL（Supabase / AWS RDS
等）への移行を検討します。本フェーズでは導入せず、スプレッドシートのまま運用しつつ蓄積データを資産化していきます。
移行を判断する目安：クライアント数が一定規模を超えた／スプレッドシートのパフォーマンス劣化が顕在化した／クライアント横断の分析・レポートが定常業務になった、等。
10
エンドクライアント ユーザーフロー（画面ベース）
エンドクライアント（企業側の人事担当者）が日常的に操作する画面は 各媒体の管理画面 と Google スプレッドシート の2つのみ。集計・レポートは T3 側でスプレッドシートから抽出し、必要に応じて共有する。
Phase 2 では専用の管理画面UIは構築しない（それは竹プラン以降）。
画面：対象媒体の候補者検索画面（Green／ビズリーチ／ambi／キミスカ）
STEP 1. スカウト対象を媒体上で登録
各媒体に自社アカウントでログイン → 候補者検索 → 要件に合う候補者を見つけたら、媒体の「お気に入り」「関心リスト」「ブックマーク」等の機能で登録。
- 命名規則に従って登録（例：
【SEND】エンジニア_東京_即戦力）
- 【SEND】で始まる名前で登録した候補者だけがシステムの対象となる
- 媒体ごとの登録手順は各媒体のマニュアルで案内する
- 作業頻度：随時（週に数時間〜）
裏側：n8n + RPA + Google スプレッドシート
STEP 2. システムが自動実行（人は待つだけ）
登録されたブックマークを対象に、以下を人の介在なしに全自動で実施。
- レジュメ取得（スクレイピング）
- ジョブホッパー判定・Type分類・メッセージ生成
- ハードルール検証・Geminiスコアリング
- スコア80点以上は即日 各媒体に自動送信
- スコア50〜79点は承認待ちキューに振り分け
- スコア50点未満は送信禁止
候補者A
78
✓ OK
候補者B
62
✓ OK
候補者C
55
× NG
画面：Google スプレッドシート（承認待ちビュー）
STEP 3. 承認待ちキューをレビュー（50〜79点のみ）
T3 から共有された Google スプレッドシートを開く → Approval_Queue シートで一覧を確認 → 承認列に「OK / NG」を入力。
- スコア75〜79点：最初の3件だけ目視し、問題なければ残りは一括「OK」（2分）
- スコア60〜74点：1件5秒ルールで個別判断。迷ったらNG（5分）
- スコア50〜59点：原則一括「NG」（30秒）
- 1日の所要時間目安：10分以内
- 承認済みレコードは翌バッチで送信される
画面：各媒体のメッセージ受信箱
STEP 4. 候補者からの返信を確認・対応
各媒体のメッセージ画面で返信を確認 → 面談調整・ご返信は人事担当者自身が実施。
- この部分は本システムの対象外（自動返信はしない）
- 候補者との対話品質は企業のブランディングに直結するため、人が担当
- 作業頻度：毎日（メール・Slack 感覚でチェック）
homula の構築したシステムを T3 が代行運用する際の日次・週次ルーチン。品質ゲートでスクリーニングされた結果のみを T3 が最終確認し、人件費を最小化しつつ事故ゼロを担保する。
1
日次（朝 10:00 目安）
前日の送信結果・エラーを確認
送信ログ（スプレッドシート）で send_status = Failed のレコードを確認。連続3件失敗があれば即時停止→開発チームへ連絡。Slack
のエラー通知も併せてチェック。
2
日次（随時）
エンドクライアントからの依頼対応
プロンプト修正・ブックマーク条件変更の依頼が来たら、依頼受付フォーム経由で受理。T3 側で内容確認のうえ反映（直接編集は不可）。反映後はクライアントに完了通知。
3
週次（金曜 30分）
NG分析と文面微修正
先週の NG 理由 Top3 を抽出し、該当箇所のみ修正。template_ver
を更新（例：v1.2.5→v1.2.6）。修正は週1回の固定枠のみ実施し、日常的な変更は避ける。
4
月次
クライアント定例レポート作成・共有
クライアント別スプレッドシートから集計（送信数・返信率・スコア分布・エラー内訳）。集計結果をレポートシートに整形し、定例ミーティングで改善提案と併せて共有。
システム構築・運用開始にあたり、T3 から提供・対応いただく必要がある事項（エンドクライアントからの情報集約を含む）。赤枠＝必須（未対応だと稼働不可）、黄枠＝重要（品質に直結）、青枠＝推奨。
必須
各媒体アカウントの共有
RPA がログイン操作を行うために必要。使用する媒体ごとに以下を共有。
- ログイン ID（メールアドレス）
- パスワード
- 2要素認証の解除、または認証アプリの共有方法協議
- 代行送信を許容するプラン契約状況
- キミスカは RPA 専用アカウントを別途発行（同時ログイン枠分離のため）
-
ビズリーチは自社採用として最安プランで新規契約・アカウント発行（代理店契約は当面困難なため）。検証は閲覧・文章生成まで（送信は数件のテストに留め、原則は送信直前で停止）。見積もり取得・契約手配を依頼
※ GCP Secret Manager に暗号化して保管。ログには出力しない。
必須
送信者名義・署名の決定
各媒体上でのスカウト送信者は誰の名義か。
- 送信者名（例：代表 ○○ / 人事部長 ○○）
- 署名（所属・肩書・連絡先）
- 名義が複数ある場合の使い分け基準
重要
自社紹介・ポジション情報の提供
メッセージの固定部分（STEP 3）に使う情報。
- 会社概要・事業内容・ビジョン
- 募集ポジションの業務内容・魅力・条件
- 解決してほしい課題・任せたい役割
- カジュアル面談のご案内（所要時間・形式・選考免除の有無）
重要
ターゲット候補者像の明確化
ブックマーク条件の設計に必要。
- 必須スキル・経験年数・職種
- 歓迎スキル・マッチ度の重み付け
- 除外条件（現職業界・居住地・年齢層など）
- 想定ペルソナ（既存社員の事例があればベター）
重要
禁止ワード・NG表現の共有
品質ゲートのハードルールに組み込む。
- 競合他社名
- 使用を避けたい表現・誤解を招く用語
- 自社のトーン＆マナー基準（もしあれば）
推奨
運用担当者・連絡窓口の指定
依頼・報告の一元化のため以下を明確化。
- 主担当（定例MTG出席者）
- 副担当（緊急連絡先）
- Slack または定期メールの連絡経路
- 承認フローに関与する場合はその旨明記
推奨
過去の成功文面・返信例の提供
AIプロンプトチューニングの学習データとして活用。
- 過去に返信率が高かったスカウト文面
- 逆に全く返信のなかった文面（失敗パターン）
- 面談まで進んだ候補者のプロフィール傾向
推奨
レポート受領方法の決定
定例レポートの配信形式を選択。
- スプレッドシート共有（自動更新）
- 月次メール配信（PDF添付）
- 定例MTGでの対面報告
HIGH
各媒体の利用規約上の自動アクセス可否（法務確認）
技術検証は完了したキミスカ・レバテックダイレクト・Green・ambi、および契約後検証予定のビズリーチについて、各媒体の利用規約上、自動操作・スクレイピングが許容されているかを法務観点で確認する必要がある。
澤・青野さん
HIGH
実行基盤の移行可否の検討
既存 Robocorp 構成から n8n＋Playwright（Cloud Run）構成への移行可否を検討中。コスト・運用負荷の削減効果と移行リスクを比較し、Phase
2 内で移行するか別フェーズに送るかを判断する。
田中さん
HIGH
ambi のログアウト検知・復帰フロー検証
ambi は reCAPTCHA があり、一度ログインすれば数日セッション維持される想定。ログアウト発生時の検知と人手介入による復帰フローを設計・検証する必要がある。
田中さん
HIGH
中途向け Type 分類の設計決定
新卒のType-A〜Eをそのまま流用するか、中途専用の分類軸を作るか。プロンプト設計に直結するため早期に方針決定が必要。
澤・田中さん
MID
ジョブホッパー判定閾値の設定
「平均在籍期間1年未満かつ転職回数3回以上」をLLMプロンプトでどう定義するか。テスト後に微調整を想定。
澤
MID
送信ログDB化のタイミング判断（将来）
Phase 2 ではスプレッドシート運用を継続するが、クライアント数・送信件数の増加に応じて本格DBへの移行を検討する必要がある。移行判断の基準と時期を別途整理。
田中さん
LOW
LinkedIn・ニュースオプションの要件詳細化
Bright Data Dataset 利用方式・LinkedIn DM フロー・ニュースソース選定。Phase 2.5 以降で別途要件整理を行う。
澤
LOW
クライアント向けレポート形式の確定
スプレッドシート自動出力 vs 定期メール送付 vs ダッシュボード（竹プラン）。粒度（日次/週次/月次）も含めて検討。
澤・青野さん
14
改修備考（Phase 1 検証で判明した改修）
Phase 1（OfferBox）のテスト工程で判明し、対応した RPA
層の改修メモ。本節は実装上の補足であり、Phase 2 でも全媒体の RPA に共通して継承する。
① ページネーション対応 — 候補者リストの全ページ取得
改修前
ページング処理が未実装で、検索結果の 1ページ目の候補者しか取得できていなかった。2ページ目以降は処理対象から漏れていた。
改修後
ページング処理を追加し、2ページ目以降の候補者も取得。対象ブックマーク内の全候補者を処理する。
確認結果：本改修により、RPA から n8n へ
100件分のデータ送信ができることを実機で確認済み。検索結果が複数ページにまたがる場合でも全件が処理対象となる。
② n8n送信前の事前判定フィルター — 「送信できる候補者だけ送る」
改修前
送信枠不足・送信不可の候補者も 一度すべて n8n へ連携。n8n でスコア判定・ログ書き込みを行った後に RPA
側で送信可否を判定していたため、スプレッドシートの送信履歴数と実際の送信人数に差分が発生していた。
改修後
n8n へ送る前に、実送信と同じ基準で「送信可能か」を判定。確定送信の直前まで到達できる候補者のみ n8n
へ連携する（事前判定時に確定送信は行わない）。
事前判定で確認する項目（実送信と同じフロー）
送信ボタン押下可否
Offer送信ボタンが押下できる状態か。
メッセージ入力欄
メッセージ入力欄が表示されるか。
送信枠／不可文言
送信人数枠の有無・送信不可文言の有無。
確認へ進む
「送信内容の確認へ進む」が押下できるか。
確定送信ボタン
「確定送信」ボタンが表示されるか。
判定NG時
処理を止めず次の候補者へスキップ（非破壊的処理）。
確認結果：50件を対象にテストし、n8n 側受信は 41件。送信不可と判定された候補者が RPA
側でスキップされること、判定 NG 時も処理が止まらず次へ進むことを確認済み。送信不可候補者を n8n 送信前に除外でき、LLM 呼び出し・ログ書き込みの無駄を削減する。
事前判定の分岐イメージ
候補者
リスト取得
→
レジュメ
取得
→
事前判定
送信可否
→
→
n8n へ連携
送信可のみ
→
スコア判定
／生成
→
確定送信
→
送信ログ
記録
③ 送信ログの記載 — タイムスタンプ記録と再送信時の重複防止
改修前
送信履歴ログの タイムスタンプが Auto送信ルート側で生成されていなかった（承認待ちルートでは生成済み）。また、承認待ちで
approval に変更すると再送信が走るため（30分ポーリング）、再送信のたびにログが追加され 同一候補者の履歴が重複するおそれがあった。
改修後
承認待ちルートの実装を参考に、二重送信チェックノードへ タイムスタンプ生成を追加（タイムスタンプ含めて append
を確認済み）。あわせて、ログ書き込み前に candidate_id ／送信対象キーで既存ログを照合し、同一データがあれば追記しない重複チェックを追加する。
留意点（タイムゾーン）：送信ログは現状 UTC
で記録される。日本時間（JST）で保持する場合はコード側での追加対応が必要（n8n ワークスペースの基本設定変更のみでは反映されない見込み）。
残課題（送信禁止リスト）：送信禁止者の分岐自体は正常動作を確認済み。ただし
送信禁止リストへの書き込み処理は未実装（専用シートも未作成）。書き込みの要否を確定する。
④ 大量送信時の課題 — 100件単位の上限と「オファー受信枠」の圧迫
事象
ブックマークを
300件規模に増やしたところ、100件単位でしか送信できない挙動を確認。さらにその100件の中にオファー受信が 15/15
で埋まっている候補者が混在すると、その候補者には送れず枠を圧迫し、結果として実送信が 100件中 数件（例：7件）に留まる事象が発生した。
対応方針
① 保存した検索条件でオファー受信数を 1〜14 に絞り込み、送信可能な母数を増やす（受信数の上限は各社で調整可）。②
100件上限は撤廃を試み、撤廃できない場合はページを取得し直して続きから再実行するサイクルで全件を処理する。
補足：受信数を 14 で絞り込んでも、検索時点で 15枠フルの候補者が
8〜9割を占めるケースがあり、なおネックになりうる。リアルタイムに枠が埋まっていくため、絞り込みはあくまで検索時点の状態である点に留意する。①の絞り込みは ① ページネーション（全ページ取得）と組み合わせて運用する。
残課題：「100件」が媒体側の上限なのか実装上の制約なのか切り分けが必要。あわせて、実際に何件送信できたかが UI
上で即座に把握しづらいため、各タイミング（RPA取得・n8n受信・実送信）の件数突合をモニタリングに組み込む。なお本課題への対応のため、リリースは当初の6月1日から1週間程度、要件定義書のフィックスは5月末から6月10日頃へ後ろ倒しとなった。