Cowork人事の実務 — 求人票づくりから入社手続きの下ごしらえまで

採用で最初に決めるのは、渡さない工程のほう

人事の仕事でCoworkを使うとき、決め方の順序が他の部門と違います。何を任せるかより先に、何を絶対に渡さないかを決めます。合否の判定と人物の評価がそれにあたり、ここを曖昧にしたまま便利さから入ると、あとで戻せない領域まで作業が広がります。

渡さない工程を先に外すと、残りは輪郭がはっきりします。Coworkは、Claudeが資料を読み、ブラウザーを動かし、ファイルを作るところまでを引き受ける製品です。採用フローに当てはめれば、文章の下書き、情報の整形、抜けの点検が中心になります。

「書類の確認」を条件次第としているのは、扱いの幅が広いためです。応募書類から資格の有無や経験年数を拾って一覧にする作業は、抽出として成立します。一方で「この応募者は要件を満たすか」を判定させると、そこから先は選考になります。同じファイルを渡していても、頼み方で性質が変わる工程です。

Coworkの機能と料金の全体像はClaude Coworkとは — 全機能・料金・始め方にまとめています。

求人票のドラフトは、要件を分解してから頼む

求人票を「魅力的に書いて」と頼むと、どの会社でも通る文章が返ってきます。原因は、渡している材料が少ないことにあります。魅力は書き方ではなく、実際の職務と条件の中にあるためです。

先に分解しておくと、ドラフトの質が変わります。分解の単位は4つで足ります。担当する業務、必須の要件、歓迎する要件、そして条件面です。このうち必須と歓迎の線引きは人が決めます。ここを機械に決めさせると、応募母集団の広さが意図せず変わります。

以下の材料から求人票のドラフトを作ってください。
 
【材料】
- 職種: 社内システムの運用担当
- 担当業務(実際の割合): 問い合わせ対応50% / 設定変更30% /
  手順書の整備20%
- 必須要件: 業務システムの運用経験2年以上、社内向けの説明経験
- 歓迎要件: 情報システム部門での就業経験、ヘルプデスクの構築経験
- 条件: 勤務地・雇用形態・就業時間・想定年収レンジは別紙のとおり
 
【書き方】
- 業務内容は割合の大きい順に、実際の作業が想像できる粒度で書く
- 必須と歓迎を混ぜない。見出しを分ける
- 年齢・性別・国籍・家族構成を示唆する表現は使わない
- 「若手が活躍」「未経験歓迎」のような幅の広い決まり文句を使わない
- 材料にない情報を補わない。足りない箇所は「要確認」と書く
 
【出力】
- 求人票の本文(Markdown)
- 材料が足りず書けなかった項目の一覧

「材料にない情報を補わない」の指定が要です。求人票の下書きは補完が効きやすく、社風や成長機会の記述が自然に足されます。読み物としては通っていても、社内で確認できない内容が混ざると、応募者との認識の食い違いにつながります。

年齢や性別を示唆する表現を避ける指定も、毎回書くより設定側に置いたほうが確実です。募集に関する表記の決まりは会社ごとに整理されているはずなので、その内容をGlobal Instructionsに寄せておくと、日々の依頼は職種ごとの材料だけで済みます。設定の階層ごとの使い分けはClaude Coworkカスタマイズにまとめています。

応募者データは、渡す前に列を落とす

応募書類には、氏名、住所、生年月日、連絡先、経歴が並びます。作業に必要のない項目まで渡す理由はありません。一覧の整形を頼むだけなら、氏名を応募番号に置き換え、住所や生年月日の列を落としてから渡す形が取れます。

列を落とす作業自体は手間ですが、一度手順を決めれば繰り返せます。書類選考の一覧を作るなら、必要なのは応募番号、応募職種、経験年数、保有資格、応募日あたりです。氏名と連絡先は、選考が進んだ段階で人が別途扱えば足ります。

添付の {applicants_202607.csv} を整形してください。
 
- 元データの列: 応募番号, 応募職種, 経験年数, 保有資格, 応募日
- 出力: 応募職種ごとに、経験年数の分布と保有資格の件数を集計した表
- 個々の応募者について、要件を満たすかどうかの判定は書かない
- 集計に使えなかった行(空欄・表記ゆれ)は、行番号と理由を別表に出す
- 元ファイルの行数と、集計後の合計行数が一致するかを最後に報告する

判定を書かせない指定を毎回入れておくと、成果物の性格が固定されます。頼み方によっては、集計の結果に「この職種は要件を満たす応募者が少ない」といった所見が付いてきます。読み物としては親切ですが、選考に近い記述が資料の中に残るのは扱いにくくなります。機微なデータを含むファイルの渡し方はCowork経理の実践でも同じ考え方で扱っています。

Connectorsで採用管理ツールやメールにつなぐときも、接続はOAuthの委任権限で動きます。つないだ本人が閲覧できない応募者は、Coworkの視界にも入りません。裏を返せば、全応募者を見られる管理者の権限で接続した場合、その全部が作業範囲になります。誰のアカウントでつなぐかは、接続を作る時点で決まる設計です。権限まわりの組み方はClaude CoworkのRBAC運用にまとめています。

候補者への連絡は下書きまでで止める

日程調整や案内の連絡文は、下書きの形で受け取るのが扱いやすい範囲です。送信そのものを任せるかどうかは、別に決める話になります。

対外的な操作については、Approval Gatesで実行前に承認を挟む形にできます。候補者へのメール送信はここに含めておくと、内容を読まずに出てしまう事態を避けられます。承認はモバイルからも返せるため、外出中に手続きが止まったままになりにくい仕組みです。

連絡文で効くのは、文面の型を先に固定することです。日程の候補、所要時間、面接の形式、持ち物、当日の連絡先。この5つが入っているかを毎回確認できる形にしておけば、個別の書き分けは冒頭の1文だけで足ります。

面接日程の案内メールの下書きを作ってください。
 
- 宛先の呼称: 応募者様(氏名は差し込み欄 {{name}} のままにする)
- 必ず含める: 日程候補3つ / 所要時間 / 実施形式 / 持ち物 / 当日の連絡先
- 日程候補は添付の {slots.csv} の空き枠から、営業日のみを選ぶ
- 送信はしない。下書きのテキストとして出力する
- 選考の進み具合や評価に触れる文言は入れない

氏名を差し込み欄のまま残しているのは、下書きの段階で個人を特定できる情報を持ち込まないためです。差し込みは送信前に人の手で行えば足ります。ブラウザーの操作や手元のファイルへのアクセスは、ユーザーの端末で動くClaudeデスクトップアプリを経由する構成のため、採用管理ツールの画面を直接触らせる場合はログインや二要素認証の扱いが接続の構成に左右されます。まず1件だけ試して、どこまで到達できるかを確かめてから広げる進め方が安全です。

合否と評価を人が持つ理由

評価と合否の判定を渡さない理由は、単に精度の問題ではありません。採用の判断は、結果として応募者の職業選択に影響し、会社は説明を求められる立場に立ちます。判断の根拠を人が持っていない状態は、その説明が成り立たない状態です。

面接の記録についても、線の引き方があります。話した内容を項目ごとに整理する作業は、聞き手が書いたメモの整形として成立します。一方で、その記録から評点を付けさせたり、複数の候補者を並べて順位を出させたりすると、判断そのものを渡したことになります。

• 評点を付けさせない: 記録の整理と評価は別の作業として分ける
• 候補者を横並びで比較させない: 順位付けは選考の結論に直結します
• 応募書類から属性を推測させない: 経歴から年齢や家庭状況を割り出す形の依頼はしない
• 過去の採用実績を学習材料として渡さない: 過去の偏りをそのまま引き継ぐ結果になります

4つ目は見落とされやすいところです。「これまで活躍している人の傾向から、書類の評価基準を作って」という依頼は自然に見えますが、過去の採用に偏りがあれば、その偏りを言語化して固定する作業になります。基準づくりは人の議論の中で行い、Coworkには決まった基準に沿った整形だけを渡す形が扱いやすくなります。

入社手続きの下ごしらえ

入社の手続きは、判断がほとんど要らないぶん、Coworkとの相性が良い領域です。ここで効くのは書類の作成そのものより、抜けの点検です。

必要な書類、提出先、期限の3つを表にしておき、入社日から逆算した確認リストを作らせる形が扱いやすくなります。入社者ごとに雇用形態や勤務地が違えば、必要な手続きも変わります。条件の組み合わせから該当する項目だけを抜き出す作業は、繰り返しに強い部類です。

{onboarding_master.csv}(手続きの一覧: 手続き名, 対象条件,
提出先, 期限の目安)から、入社者ごとの確認リストを作ってください。
 
- 入社者の条件: 雇用形態 / 勤務地 / 入社日(別表 {joiners.csv})
- 出力: 入社者1人につき、該当する手続きを期限の早い順に並べた表
- 期限は入社日からの相対日数を、実際の日付に換算して書く
- 対象条件が判定できない行は「要確認」に入れ、勝手に含めない
- 個人の氏名は使わず、社員番号の列だけを使う

このリストは、人が確認するための下地です。制度に関わる手続きは会社の状況や制度の改定で変わるため、一覧の側を最新に保つ作業は人が担います。一覧が古ければ、返ってくるリストも古いままです。

入社初日に渡す資料の整形も同じ範囲に入ります。既存の説明資料から、その入社者に関係する部分だけを抜き出してまとめる作業は下書きとして受け取れます。制度の説明が正確かどうかは、人事の担当者が読んで確かめる工程が要ります。運用ルールの組み立て方はClaude Cowork運用ベストプラクティスで扱っています。

定期実行に載せる作業、載せない作業

Scheduled Tasksでは「毎週月曜9時に」のような指定を自然言語で書けます。人事の業務でいえば、期限が近い手続きの洗い出しや、応募状況の集計が候補になります。

ただし実行時刻に厳密な保証はなく、長時間かかる処理は途中で止まることがあります。締め切り当日に1本で走らせる設計は、外れたときの影響が大きくなります。

対外的な影響が出る操作は、Approval Gatesで実行前の承認を挟む形にできます。候補者へのメール送信や、外部の求人媒体への掲載更新がこれにあたります。承認の対象を広めに取っておくと、定期実行に載せた後も内容を見る機会が残ります。

よくある質問

応募書類のPDFをそのまま読み込ませても問題ありませんか

技術的には読み取れますが、書類には氏名・住所・生年月日が揃って含まれます。一覧の整形が目的なら、必要な項目だけを抜いた表を先に作り、それを渡す形にすると扱う範囲が小さくなります。原本を渡す必要がある場合は、プランごとのデータの扱いと、社内で定めた保管のルールを先に確認しておく流れになります。

採用管理ツールと直接つなげますか

Connectorsで接続できるサービスなら、委任された権限の範囲で読み書きできます。接続対象にないツールは画面を操作する形になりますが、ログインや二要素認証が挟まると止まることがあります。まず1件だけで試し、安定して動くかを確かめてから定常運用に載せる進め方が現実的です。

面接の録音から議事録を作れますか

音声を文字にしたテキストがあれば、項目ごとの整理は頼めます。ただし面接の記録は応募者の情報そのものなので、録音や書き起こしを扱う前に、本人への説明と社内での取り扱いの取り決めが必要になります。記録の整理と評価は別の作業として分けておくと、成果物の性格が曖昧になりません。

求人票の文面をそのまま媒体に出せますか

下書きとして受け取り、条件面と表記を人が確認してから出す前提になります。特に賃金・就業時間・雇用形態の記述は、社内で確定した内容と一致しているかの照合が要ります。募集に関する表記には守るべき決まりがあるため、社内の確認手順を通す流れは変わりません。

求人媒体ごとに文面を作り分けられますか

同じ材料から、字数や項目の制約に合わせて複数のパターンを出す使い方はできます。媒体ごとの制約を材料に含めておけば、短縮した文面と詳しい文面を並べて受け取れます。ただし条件面の記述が媒体間でずれていないかの照合は人が持ちます。出し分けた本数が増えるほど、この照合の手間も増える点は見込んでおく形になります。

まとめ

Coworkを人事で使うときは、渡さない工程を先に決めます。評価と合否の判定、候補者の順位付け、応募書類からの属性の推測、そして過去の採用実績から基準を作らせること。この4つを外したうえで、求人票の下書き、応募データの整形、連絡文の下書き、入社手続きの点検を渡す形になります。

指示文で効くのは、材料にない情報を補わせないこと、判定を書かせないこと、埋められない箇所を「要確認」として残させることです。どれも短い1行ですが、返ってきた成果物が下書きのまま留まるかどうかを分けます。

渡すデータは、作業に必要な列だけに絞ります。氏名を応募番号に置き換え、住所や生年月日を落としてから渡す。手間に見えますが、一度決めれば毎回同じ手順で済みます。最初の一歩としては、1職種分の求人票を材料から分解して下書きさせ、そこで直した箇所を数えてみる形が現実的です。直しが要件の書き方に集中していれば、材料の作り方を先に整えるほうが早く効きます。