homula × T3 ｜ 採用オファー自動化
アーキテクチャ変更のご説明
費用のお話の前に、今回の構成変更を整理します。結論は「Playwrightで速くなる改善はそのまま、土台（バックエンド）は実績あるRobocorpを継続」です。
今回の変更を一言で
自動化は「RPA（画面操作の方法）」×「バックエンド（動かす・定期実行する土台）」の組み合わせで作ります。
今回変えるのは左のRPAだけ（Robocorp → Playwright）。右の土台はRobocorpを続けます。
RPA（画面操作の方法）
バックエンド（動かす土台・定期実行）
処理に時間がかかる
変えるのは左だけ：Playwright化で時短50〜67%・コスト減
ここが誤解されやすいポイント：「Robocorpを使う＝後退・高コスト」ではありません。改善の主役はPlaywright化（高速化）で、前回ご議論いただいたメリットはそのまま得られます。Robocorpは“動かす土台”として続けるだけで、追加で重くなる・高くなるものではありません。
ここがポイント（3つ）
- Playwright化のメリットは変わりません。前回の議論どおり、Playwrightで処理時間が短縮（時短50〜67%）され、ランニングコストも下がります。
- 変えるのはRPA（左）だけ。土台（右）はRobocorpを継続するので、構成はシンプルで、すでに動いている部分をそのまま活かせます。
- 「Robocorpをバックエンドに」は“土台”の話。費用が二重にかかる、という意味ではありません（費用の詳細は別資料でお示しします）。
なぜ、土台（バックエンド）はRobocorpなのか
Robocorpは「ログイン付きのブラウザ自動化を安定して回す」ことに最適化された専用基盤です。Playwrightの高速化を、いちばん安定した形で活かせる土台だから採用します。
- ブラウザ自動化に最適化された専用基盤。ログインや画面操作の多い処理を安定して実行でき、Playwright化の“速さ”を“安定して”引き出せます。
- すでに本番品質で安定稼働。実際の媒体（AMBI・Green）で数百件規模の取得〜送信をエラーなく完走済み。リリース初日から安定が見込めます。
- 運用・監視が標準で揃っている。実行ログ・Artifacts・自動リトライが最初から備わり、状況の可視化や障害対応が容易。別途の作り込みが要りません。
今後の進め方
・7/1リリースは「Playwright × Robocorp」で確実に。まずは品質と安定性を最優先します。
・具体的なコスト（初回＋再オファー・構成別）は別資料でお示しします。
homula ｜ 採用オファー自動化 アーキテクチャ変更のご説明