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

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

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

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

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

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

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

Workable Connectorは、職種別の候補者一覧と個々のプロフィールを取得するツールを持ちます。募集要件を満たしているかの一次確認は、この一覧取得とプロフィール取得を組み合わせて行います。

例です。

Account Executiveの職種の候補者を全員表示して、Edna Rennerの全プロフィールを見せて、コミュニケーション能力が高いというコメントを追加して

この指示は3段階に分かれます。パイプラインの一覧取得、個別プロフィールの取得、コメントの追加です。前半2つは読み取りで、最後の1つが書き込みです。募集要件(経験年数や資格、稼働可能日など)との照合は、取得したプロフィールを人が読んで判断するか、要件を指示文に明示してClaudeに照合させるかのどちらかになります。後者を選ぶ場合、募集要件はWorkable側の求人情報ではなく、プロンプトの中で具体的に書く方法を本記事では採ります。求人フィールドに登録された要件をツール側がどこまで自動で拾って照合に使えるかは公式のツール一覧からは確認できないため、確実な運用としてはプロンプトへの明記を基本にしておきます。

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

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

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

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

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

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

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

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

例です。

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

この一連の操作も、要件照合や評価記録と同じく、一覧取得・詳細取得・承認実行の3段階です。承認は書き込み操作で、実行すると採用予算やヘッドカウントの確定に直結します。指示だけで承認まで一気に進めると、内容の確認なしにリクイジションが確定してしまう可能性があります。中身の妥当性はプロンプトの中でClaudeに要約させ、実際の承認は人が最終確認したうえで実行するのが安全な運用です。

保留中のリクイジションが複数ある場合、一括承認の指示は避けたほうが安全です。1件ずつ詳細を出させて内容を確認し、個別に承認する順序にすると、Claudeが返す要約と実際のリクイジション内容の食い違いにも途中で気づけます。1件ごとの確認は手間が増えますが、承認という取り消しにくい操作である以上、確認の粒度を粗くする理由にはなりません。

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

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

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

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

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

つまずきやすい点

募集要件をWorkableの求人票の自由記述欄にだけ書いて、Claudeが自動で読み取ってくれることを前提にしないほうが安全です。求人情報を取得するツールが自由記述の条件をどこまで構造的に扱うかは公式のツール一覧からは確認できないため、要件は毎回プロンプトで書き直す運用を基本にしておきます。

Claudeが実行できる操作は、一般的なコネクタの仕組み上、接続時に使ったWorkableアカウントの権限の範囲内に収まると考えておくのが安全です。採用担当者本人のロールでリクイジション承認権限が無ければ、Claude経由でも承認は実行できないはずです。権限を持つ別のアカウントで接続し直す運用は、代理承認であって権限の拡張ではない点に注意します。

同じ候補者に同じ指示を繰り返すと、コメントが重複して残る可能性があります。追記か上書きかを指示文で明示しておくと、こうした重複を避けやすくなります。

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

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

ここまでの3操作(要件照合・評価記録・リクイジション承認)は、いずれも人が下した判断をWorkableに反映する作業です。「この候補者を採用すべきか」という評価そのものをClaudeに委ねる操作ではありません。この線引きは、Cowork人事の実務が採用フロー全体で示す「評価・合否は渡さない」という方針と一致します。

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

まとめ

Workable Connectorの一次スクリーニングは、候補者プロフィールの取得と募集要件の照合、評価コメントの構造化記録、リクイジション承認の3つに集約されます。いずれもClaudeが候補者を独自に評価する機能ではなく、人が決めた内容をWorkableへ正確に反映する機能です。書き込みを伴う操作は、実行前に内容を確認してから進めます。指示の粒度を分けておくほど、あとから何が起きたかを追いやすくなります。