Phase2展開に向けて、追加媒体（キミスカ／レバテックダイレクト）へのRPA適用可否を実機検証し、 併せて実行基盤の選定（Robocorp継続 vs n8n＋Playwright移行）を技術的に評価しました。
本調査の結論を冒頭に提示します。
① 媒体適用：キミスカ・レバテックダイレクトともに、ログイン／レジュメ取得／メッセージ送信の3工程すべてで
実機検証に成功しました。両媒体とも実用可能です（CAPTCHA・特殊認証なし）。
② 技術選定：n8n＋Playwright(Cloud Run)構成への移行は、技術可否9項目すべてで実現可能と判定。
毎回手動起動が不要になり、Robocorp費用も削減される一方、本番移行は段階的に進めることを推奨します。
「ログイン」「レジュメ取得」「メッセージ送信」の3工程で実機検証した結果。
| 媒体 | ①ログイン | ②レジュメ取得 | ③メッセージ送信 | 総合判定 |
|---|---|---|---|---|
| OfferBox（Phase1 稼働中） | ✓ | ✓ | ✓ | 実用中 |
| レバテックダイレクト | ✓ | ✓ 候補者番号 20件抽出 |
✓ 送信フォーム完全マッピング |
実用可能 |
| キミスカ | ✓ 同時ログイン制限を自動突破 |
✓ 学生ID 25件抽出 |
✓ 「クイック送信」ボタン有効化確認 |
条件付き可 |
| Green | ✓ | ✓ 後描画・名札ランダムで少し手間 |
✓ | 実用可能 |
| ambi | △ reCAPTCHA「私はロボットではありません」あり |
検証中 | 検証中 | 条件付き可（想定） |
※ OfferBox／レバテック／キミスカ／GreenはCAPTCHA・特殊認証なしを確認済み。
/cr/signinでメール＋PWのフォーム認証/cr/candidate/list/<listId>非エンジニアでも媒体の RPA 可否を判断・報告できるよう、3つの関門で整理。
ID＋パスワードのフォーム入力なら基本的に自動化可。
CAPTCHA／2段階認証／SSO／生体認証は要工夫または不可。
CAPTCHA・速度制限・IP制限・アカウント保護で止まらないか。
操作間隔・実行頻度・IP戦略で対応の引き出しを持つ。
自動アクセス・スクレイピング禁止条項の有無を確認。
技術可否と別に「やってよいか」を必ず判定する。
| 認証方式 | 自動化 | 説明・確認ポイント |
|---|---|---|
| ID＋パスワードのフォーム入力 | 可能 | 最も自動化しやすい。例：Green、OfferBox、レバテック、キミスカ |
| 「ログイン状態を保持」Cookie方式 | 可能 | 一度ログインすれば一定期間有効 |
| 画像認証（CAPTCHA / reCAPTCHA v2） | 要工夫 | 原則自動突破は不可。人が一度だけ通す等の工夫が必要 |
| reCAPTCHA v3 / Botスコアリング | 要工夫 | 不可視で人間らしさを採点。検知されやすい |
| 2段階認証（SMS/認証アプリ/メール） | 要工夫 | コード受け取りの自動化が必要。難易度高 |
| マジックリンク（メール認証） | 要工夫 | メール側の自動化が必要 |
| SSO（Google/Microsoft等） | 場合による | 連携先のログイン＋同意画面。2FAが絡むと難化 |
| ICカード／生体認証／専用アプリ承認 | ほぼ不可 | 物理デバイス必須。RPAの範囲外 |
| # | 確認項目 | 判定 | 備考 |
|---|---|---|---|
| 1 | ログインはID＋パスワードだけで入れるか | ○ / △ / × | ×なら2FA/SSO等を確認 |
| 2 | ログイン時にCAPTCHA・画像認証が出ないか | ○ / △ / × | 出るなら要工夫 |
| 3 | 操作中にアクセス制限・警告が出ないか | ○ / △ / × | 出るなら頻度・IP対策 |
| 4 | 利用規約で自動操作が禁止されていないか | ○ / △ / × | ×なら技術可否に関わらずNG |
| 5 | 取得したい情報が画面で人にも見えるか | ○ / △ / × | 見えれば原則取得可 |
| 6 | 送信操作が画面のボタンで完結するか | ○ / △ / × | できれば送信自動化も可 |
判定の目安：1〜4がすべて○ → 実用可能（GO）／ 1〜3に△あり → 条件付き可（工夫・追加コスト見積） ／ 4が× → 不可（規約NG）
Phase2で媒体数・クライアント数が増えることを見据えた、実行基盤の再評価。
Robocorp（起点）→ n8n（AI生成）→ Robocorp（スカウト送信）
| # | コンポーネント | 可否 | 根拠 |
|---|---|---|---|
| 1 | n8n cloud の Schedule Trigger で定期実行 | ✓ | 標準機能。cron式で指定可 |
| 2 | n8n cloud の Manual Trigger（Run UI） | ✓ | 標準機能。クライアントもアクセス可 |
| 3 | n8n cloud 内でPlaywrightを直接実行 | ✗ | クラウド版はサンドボックス制限・コミュニティノード不可 |
| 4 | n8n cloud から外部HTTPサービス呼び出し | ✓ | HTTP Requestノード標準装備 |
| 5 | Cloud Run で Playwright＋Chromium 実行 | ✓ | 公式Dockerイメージあり、実績多数 |
| 6 | Cloud Run から OfferBox.jp の操作 | ✓ | 既存Robocorp版と等価以上。Green検証でも同型SPAで実証済 |
| 7 | n8n cloud → Cloud Run の認証 | ✓ | Cloud Run IAM（推奨）／APIキー |
| 8 | OfferBox認証情報の安全な管理 | ✓ | GCP Secret Manager → 環境変数 |
| 9 | 100件規模を1リクエスト内で完了 | ✓ | Cloud Runタイムアウト60分以内（処理見込み20-25分） |
総合判定：✅ 技術的に実現可能（n8n内Playwright直接実行は不可だが、外部HTTPサービス分離で解決）
| 選択肢 | 月コスト | メリット | デメリット |
|---|---|---|---|
| Cloud Run (GCP) 推奨 |
$1〜5 | 使った分課金、Google連携統一、60分タイムアウト、デプロイ簡単 | コールドスタート5-15秒（定期実行では影響軽微） |
| Render.com | $7常駐 | git pushでデプロイ、Dockerfile不要 | 常駐課金、IPは可変 |
| VPS 固定IP（Lightsail等） | $5〜10 | 固定IPでBAN対策に有効 | サーバ保守必要（OS更新等） |
| Browser-as-a-Service（Browserless等） | $200〜 | Playwrightエンジン外部委託 | 高コスト、複雑フロー記述が不便 |
| リスク | 影響 | 対策 |
|---|---|---|
| OfferBox側のBan／レート制限 | 送信不可・アカウント停止 | 現状と同等リスク。問題化したらVPS固定IPへ切替 |
| Cloud Run コールドスタート（5-15秒） | 初回応答が遅い | Schedule実行では問題なし。Min instances=1で回避可 |
| 毎リクエストでログイン必要 | オーバーヘッド | PoCではそのまま。セッショントークン方式で後日最適化可 |
| n8n cloud のワークフロー実行時間制限 | 長時間ジョブが切れる | バッチ分割／Cloud Run側でループ実行 |
| OfferBox DOM変更 | セレクタが壊れる | 現Robocorp版と同リスク。テスト・モニタリングで対応 |
| 利用規約上の自動化可否 | 規約違反リスク | 現状と同じ。法務確認は別途必須 |
Phase2に向けて n8n＋Playwright 構成を取り入れた場合に見込める効果。
Schedule Triggerで定期実行が自動化され、毎日の手動起動・属人化が解消される。
Control Roomとn8nの二重管理が解消され、クライアントの操作箇所がn8nに集約される。
Robocorp費用を廃止し、使った分だけ課金されるCloud Run（$1〜5/月）へ置き換え可能。
| 工程 | 工数 |
|---|---|
| Cloud Run用Playwrightサービス実装（FastAPI＋Playwright、既存ロボットから移植） | 2-3日 |
| n8nワークフロー再構成(Schedule＋HTTP連携) | 1日 |
| Cloud Run／Secret Managerデプロイ・認証設定 | 0.5-1日 |
| 動作検証（ドライラン＋限定実送信） | 1日 |
| ドキュメント整備・引き継ぎ | 0.5日 |
| 合計 | 約1週間 |