Workableの一次スクリーニングをClaudeで承認フロー付きに回す

Workableの一次スクリーニングで任せられること

Workable Connectorをつなぐと、候補者プロフィールを募集要件と照合し、評価コメントを記録し、リクイジション(採用申請)を承認する一連の作業を、Claudeとの会話だけで進められます。求人票づくりから入社手続きまでの工程全体はCowork人事の実務が扱っていますが、本記事はそのうちWorkable固有の3つの操作、要件照合・評価記録・リクイジション承認に絞ります。

接続そのものの手順はClaudeとWorkableを連携する方法にまとめています。ここでは接続済みの状態から先の使い方を扱います。

「一次スクリーニング」という言葉は、応募が集まったあとに面接へ進める候補者を絞り込む最初の工程を指します。書類上の要件を満たすかどうかの確認と、満たす候補者への一次評価の記録が中心で、面接の日程調整やオファーの提示は含みません。Workable Connectorがこの工程で担うのは、候補者データの取得と、人が下した判断の書き込みです。

この書き込みはWorkableという採用管理システムそのものへ直接反映されます。下書きをファイルに残して人が転記するのではなく、コメントやステージ、承認ステータスがその場でWorkableの記録として確定する点が、一般的な文書作成の支援とは性質が異なります。指示に書いた文言がそのままコメントとして残ります。

候補者プロフィールを募集要件と照合する

Workable Connectorには、求人ごとの候補者一覧を返す get_candidates と、個々のプロフィールを返す get_candidate があります。get_candidates が受け付ける絞り込み条件は、ステージ・メールアドレス・日付です。経験年数や資格のような要件で絞る機能ではないので、要件の照合は取得したプロフィールをもとに行います。

例です。

Account Executiveの職種の候補者を全員表示して、候補者Aさんの全プロフィールを見せて、コメントを追加して

氏名は架空の例で、実際には候補者の名前をそのまま書きます。この指示は3段階に分かれます。パイプラインの一覧取得、個別プロフィールの取得、コメントの追加です。前半2つは読み取りで、最後の1つが書き込みです。照合の基準は、求人票の記述に任せず指示文の中に具体的に書きます。「3年以上のSaaS営業経験」「英語ビジネスレベル」のように数値や水準まで入れておくと、Claudeが読み取った結果と突き合わせやすくなります。

候補者が多い求人では、1人ずつ読ませる前に絞り込みます。Workable側のドキュメントには、標準項目・カスタム項目のどちらでも条件にできる検索ツールが載っています。使い方は次の3段階で、Claudeに頼むときも同じ順序をたどります。

注意したいのは、コネクタ側の一覧との食い違いです。claude.comのWorkableコネクタのページには45のツールが載りますが、search_candidates_detailed も、求人名から求人コードを引く search_jobs も、アカウント一覧を返す get_accounts もありません。Workable側のドキュメントにはこれらが載っており、get_accounts を最初に呼ぶ決まりになっています。

同じ一覧には、評価を更新する upsert_candidate_rating、見送りを取り消す revert_disqualification、リクイジションを更新する update_requisition もありません。候補者を移す relocate_candidate、複製する copy_candidate、タグを置き換える update_candidate_tags も同様です。項目の一覧と選択肢を返す get_candidate_detailed_fields と get_candidate_detailed_filter_options も載っていません。どのツールが実際に使えるかは接続したコネクタの表示に従うので、絞り込みが効かないときは get_candidates での取得に切り替えます。

Workableのアカウントを複数持つ場合、ツールはアカウントのサブドメインを引数に取ります。取り違えを避けるには、指示文に会社名やサブドメインを入れておきます。

照合の頼み方には性質の違う2種類があります。「3年以上のSaaS営業経験がある候補者だけ抜き出して」のように、履歴書の記述と数値・年数を突き合わせる指示は抽出に近く、結果の再現性も高くなります。一方で「この候補者はカルチャーにフィットしそうか」のように評価が伴う指示は、実質的に選考の一部です。条件と結果が一意に決まる作業と、人の判断が入る作業を分けて頼むと、あとで結果を検証しやすくなります。

評価コメントとスコアリングの記録

候補者への評価を構造化して記録する例です。

候補者Bさんにポジティブな評価をつけて、コメントに「営業経験が豊富で、カルチャーフィットも良い」と入れて、次のステージに進めて

この指示でClaudeが行うのは、評価内容(ポジティブ、コメント文)と次アクション(ステージ移動)を、そのままWorkableへ書き込むことです。評価の中身を決めるのは指示を出した人で、Claudeが候補者を独自に採点しているわけではありません。「スコアリング」という言葉が指しているのは、この構造化された記録作業そのものです。

評価の入れ方には2つのツールがあります。add_review は評価を新しく足すツールで、claude.comの一覧に載っています。upsert_candidate_rating は同じメンバーが同じステージにつけた評価があれば更新し、なければ作ります。

後者は一覧になく、Workable側の表ではエージェントから使うならこちらを勧めています。接続したコネクタに upsert_candidate_rating があればそれを使い、一覧にあるものだけなら add_review で足します。評価の尺度は親指(0〜2)・星(0〜4)・数値(0〜9)の3種類です。後者はステージを省くと候補者の現在のステージに付き、評価は認証したメンバーの名義で残ります。つまりWorkableの画面では、Claudeを接続した採用担当者本人が評価したように見えます。

コメントを残す add_comment は、公開範囲を指定できます。評価と違って更新ではなく追記なので、同じ候補者に同じ指示を繰り返すとコメントが重複して残ります。再実行するときは、追記か上書きかを指示文に書いておきます。

同じステージ移動の指示でも、評価コメントを付けずに移動だけを頼むこともできます。ただし移動の理由が記録に残らないと、あとで見返す採用担当者やWorkableの他ユーザーが判断の根拠を追えなくなります。コメントを添える運用を既定にしておくと、記録としての追跡性が保てます。

指示の書き方によって、Claudeの役割は変わります。「候補者Bさんを評価して、良ければ次のステージに進めて」のように評価の中身を委ねる指示だと、良し悪しの基準をClaudeが自分で決めることになります。「ポジティブな評価をつけて、コメントは『営業経験が豊富で、カルチャーフィットも良い』」と中身まで指定すれば、Claudeが行うのは指定どおりの記録だけです。この区別を保つと、誰が何を判断したかがコメントの文面からも追えます。

見送りと承認はどこまで戻せるか

書き込みツールは、取り消しの効き方がそれぞれ違います。Workable側の表では、次のようになります。戻す側のツールの多くはclaude.comの一覧になく、接続したコネクタにあるときだけ使えます。

一次スクリーニングの最後に出る「見送り」は、disqualify_candidate で記録します。見送りの根拠は、評価コメントと同じく指示文に書いて残します。

接続したコネクタに revert_disqualification が無いなら、見送りは戻せない操作として扱います。実行前に、対象の候補者と選んだ理由を読み上げさせます。

リクイジション承認のワークフロー

例です。

保留中のリクイジションを全部見せて、REQ1の詳細を出して、承認して

REQ1はコードの仮の例で、実際にはWorkable上のリクイジションのコードを書きます。

承認の前後は、次の流れに分けておくと、確認が抜けません。

指示だけで3つ目まで一気に進めると、内容を読まないまま承認が確定します。複数件あるときも、一括承認は避けて1件ずつ個別に進めます。Claudeが返す要約と実際の内容の食い違いに、途中で気づけるからです。承認は取り消しにくい操作なので、確認の粒度を粗くする理由はありません。

Claude Codeで定型チェックを回す

同じ要件照合を、Claude Codeのセッションから定型的に呼び出すこともできます。

Workableで「Account Executive」の求人を探して、その候補者を一覧にして、募集要件(3年以上のSaaS営業経験、英語ビジネスレベル)と照合し、満たない項目がある候補者だけを理由付きで挙げて

求人は名前で指定します。get_candidates が受け取るのは求人のコードで、リクイジションのコード(REQ1など)とは別物だからです。名前から求人コードを引く search_jobs が使えない接続でも、get_jobs で一覧を出してから選ぶ流れで足ります。

この形式にしておくと、募集要件を指示文の中で毎回明示できます。Workable側の求人情報が未整備でも照合の基準がぶれません。結果をコメントとして書き込むかどうかは別の指示に分けておくと、読み取りと書き込みの操作が混ざらずに済みます。

応募が継続的に集まる求人では、同じプロンプトを日次や週次で回すと、新着候補者だけを都度洗い出せます。絞り込んだ結果をステージ移動やコメントとして書き込むかどうかは、人が判断してから別に指示します。定型チェックの自動化が進むほど、書き込みの承認だけは人の手元に残す線引きが重要になります。

つまずきやすい点

募集要件を求人票の自由記述欄にだけ書いて、Claudeが自動で読み取ってくれることを前提にしないほうが安全です。要件は毎回プロンプトで書き直す運用を基本にします。

Claudeが実行できる操作は、接続時にサインインしたWorkableアカウントの権限の範囲に収まると考えておくのが安全です。採用担当者本人のロールでリクイジション承認権限が無ければ、Claude経由でも承認は実行できないはずです。権限を持つ別のアカウントで接続し直すのは代理承認であって、権限の拡張ではありません。

プロフィールの記入が薄い候補者では、募集要件との照合結果が「不明」になる項目が出ます。この場合は、空欄を推測で埋めず「不明」のまま返すよう指示に明記します。不明な項目がある候補者は、確認要の別枠に分けておくと見返しやすくなります。

合否判断をどこで線引きするか

この線引きは、Cowork人事の実務が採用フロー全体で示す「評価・合否は渡さない」という方針と一致します。

Claude経由でWorkableに書き込んだ操作が、誰の権限でいつ実行されたかを追う方法はClaudeコネクタの権限設定は監査ログでどこまで追えるかにまとめています。承認や評価コメントの記録が増えるほど、この追跡可能性が運用の安全網になります。

まとめ

書き込みを頼む前に、接続したコネクタのツール一覧で、戻すツールがあるかを確かめます。見送りや承認のように戻すツールが無い操作は、内容を読み上げさせてから実行します。