仕事探しに毎日何時間も費やしていました。ほとんどは同じ情報を少し異なるフォームにコピペする作業です。そこで、以下のことを行うエージェントを作りました：
求人ボード全体で空いているポジションを見つける
各仕事に合わせて履歴書を書き直し、新しいPDFを生成する
実際の応募フォーム（Ashby、Greenhouse — ドロップダウン、コンボボックス、「なぜここで働きたいのか」の記入欄）を埋める
提出前に止めて、私が各応募を確認できるようにする — これはアシスタントであり、スパム送信機ではありません
Python + Playwright + フォームフィールドマッピングを行うLLMで構築しました。最も難しかったのは、ATSごとにフォームの表示が大きく異なることへの対応でした。
構築について何でも聞いてください — 皆さんがこれを自律的に提出することを信頼するかどうか興味があります（私はまだ信頼していません）。
ATSフォームの処理は本当に最も難しい部分であり、これを構築するほとんどの人はそれがどれほど厄介になるかを過小評価しています。Greenhouseだけでも、会社の設定方法に応じて4つの異なるフォームレンダリングパターンがあります。あなたはそれを苦労して学んだようです。
送信前に人間が確認するのは、倫理的にも実用的にも正しい判断です。自動送信された応募は読み方が異なり、トーンがずれており、「なぜここで働きたいのか」という回答が常にきれいすぎます。採用担当者はそれに気づき始めています。
ただし、一つ指摘したいのは、求人ごとの履歴書の調整は良いアイデアですが、出力が実際に送信される前に確認していますか？LLMは、技術的には正確だがあなたの経験について微妙に間違っている箇条書きを自信を持って書き換えます。フォーム入力を承認しても、毎回履歴書を再読していないなら、そこがギャップです。
次に考えるべきは、企業が知名度の低いATSやカスタム構築のポータルを使用する場合です。業界によっては、これはおそらく求人の30％を占め、エージェントは静かに失敗するかスキップします。このカバレッジのギャップは、このシステムをより多くの求人に拡大するにつれて、時間とともにより重要になります。
PDF生成の側面をどのように処理しているのか興味があります。多くの履歴書からPDFへのパイプラインは、採用担当者が特定のバージョンのAcrobatで開いてフォーマットが崩れるまでは問題なく見えます。
基本的に、私はChromiumを使用して、入力されたHTMLに基づいてオーダーメイドの履歴書を生成しています。
提出前の停止部分が重要な設計上の選択です。求人応募はまさに、エージェントが時間を節約できるが、最終的な人間によるレビューがスパムや誤った表現を防ぐワークフローです。
私も自律的に提出させることはしないでしょう。少なくとも、システムが副作用に対して退屈なガードレールを持つまでは。
有用な境界は次のとおりです。エージェントは応募パッケージを準備できますが、提出は別の特権アクションです。
より多くのボリュームを任せる前に追加したいことがいくつかあります。
応募ごとに領収書を保持する：ジョブURL、会社、役割ID、生成された履歴書のハッシュ、使用された回答、タイムスタンプ、および提出されたかどうか
生成された履歴書/回答をベースプロファイルと比較して、奇妙な幻覚の経験がレビュー前に見えるようにする
可能な限りすべての外部書き込みを冪等にする：明示的に許可されない限り、同じジョブ/会社のペアを再提出しない
決して発明されるべきでないフィールドをハードブロックする：市民権、就労許可、給与、障害/退役軍人ステータス、場所、可用性
提出前の最終レビューページのスクリーンショットまたはDOMスナップショットを保存する。ATSフォームは乱雑で、必須フィールドや状態を隠すことがあるため
積極的にスロットルと重複排除を行い、偶発的なスパムにならないようにする
最も疑わしい部分はテキストボックスへの入力ではありません。フィールドの解釈です：「就労許可」、「スポンサーシップが必要」、「転居を希望する」などのドロップダウンや、間違ったマッピングが実際の結果をもたらすノックアウト質問です。
したがって、あなたの「提出前に停止する」という選択は正しい製品形状だと思います。興味深い次のステップは、おそらくすべての入力フィールドの出所を示すレビューUIです：プロフィールからのソース、履歴書から推測、求人投稿から生成、または人間の入力が必要。