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

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

Claude Coworkを採用・人事で使うときのフロー別の活用マップ、求人票ドラフトの指示文例、応募者データを渡すときの最小化、合否判断を人に残す線引きを扱います。

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

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

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

フェーズCoworkの効き方人に残るもの
募集要項の作成Coworkの効き方効きやすい人に残るもの要件と条件の確定
書類の確認Coworkの効き方条件次第人に残るもの選考の判断
日程調整・連絡Coworkの効き方効きやすい人に残るもの送信の可否
評価・合否Coworkの効き方渡さない人に残るもの判断そのもの
入社手続きCoworkの効き方効きやすい人に残るもの内容の確認と提出

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

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

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

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

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

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

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

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

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

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

クラウドとローカルで、応募者データの行き先が変わる

Coworkのセッションは、既定でクラウドで動きます。応募者の一覧を渡す前に、処理される場所の違いを押さえておくと、扱う範囲を決めやすくなります。

くらべる

Coworkの2つの実行場所

既定

クラウドセッション

  • エージェントの実行とコード実行は、Anthropicのサーバー上の一時サンドボックスで動く
  • セッションとファイルは、メンバーのClaudeアカウントに保存される
  • 端末のファイルをデスクトップアプリ経由で開いた場合も、処理はAnthropicのサーバー側になる
  • 端末に届くのは、接続したフォルダに限り、デスクトップアプリがオンラインの間だけ
既存のデスクトップ運用

ローカルセッション

  • エージェントは端末上で動き、コード実行は端末内の分離された仮想マシンで動く
  • 会話履歴は端末に残り、Anthropicの標準のデータ保持ポリシーの対象外
  • 管理者は会話履歴を一括で管理も削除もできない

クラウドセッションでは、コネクターの認可トークンがサンドボックスに入りません。コネクターの呼び出しはサーバー側で行われます。組織の管理者は、ローカルのデスクトップ運用を残したままクラウドセッションだけを止めることもできます。応募者データを端末の外に出したくない場合は、この設定が論点になります。

なお、クラウドセッションの「Run Cowork in the cloud」は、Teamでは既定でオン、Enterpriseでは既定でオフです。Enterpriseではオーナーが有効にし、ロールへ付与して初めて使えます。

ネットワークの送信先を絞る設定は、ウェブ取得・ウェブ検索のツールやMCP(Claude in Chromeを含む)には適用されません。ウェブ検索はオーナーがOrganization settingsのCapabilitiesでオフにできます。

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

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

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

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

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

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

Coworkには、実行前に確認を求める承認モードが3つあります。新しい画面では、このうちAutoとManualの2つが選択肢に並び、Manualが既定です。

くらべる

承認モードの違い

Manual

Manually approve

操作のたびに一時停止し、許可か拒否を選ぶ。コネクターの書き込み系ツールも、「Needs approval」にしてあれば毎回確認が入る。

Auto

Automatically approve

読み取り専用のツールは承認され、書き込みや削除はClaudeが判断する。実行前に安全性を審査し、危険と判断した操作は止める。

Skip

Skip all approvals

「Always allow」も「Needs approval」も承認され、どの操作も審査されない。「Blocked」にしたツールだけは拒否される。

注意したいのは、Manualでも、ツールごとに「Always allow」にしたコネクターは確認なしで通る点です。候補者へ送る系のツールは、「Needs approval」の側に置く構成になります。

Team・Enterpriseでは、書き込み系ツールの「すべてのタスクで許可」を選べるかを管理者が決めます。この設定は既定でオフです。オフの間は、保存済みの常時許可も効かず、タスクごとの承認になります。ファイルの完全削除だけは、どのモードでも確認が入ります。

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

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

面接案内の下書きから送信まで

  1. 1

    下書きを出力させる

    氏名は差し込み欄のまま、本文だけを受け取ります。下書きの段階で、個人を特定できる情報を持ち込みません。

  2. 2

    人が差し込む

    氏名と確定した日程を、送信前に人が入れます。

  3. 3

    承認の画面で文面を読む

    送信までCoworkに任せる場合は、承認の画面で内容を読んでから許可します。

採用管理ツールの画面を直接触らせる場合、クラウドセッションは端末のClaudeデスクトップアプリがオンラインの間だけ端末に届きます。まず1件だけ試して、どこまで到達できるかを確かめてから広げる進め方が安全です。

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

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

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

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

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

入社手続きの下ごしらえ

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

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

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

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

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

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

Scheduled Tasksは、Cowork上で /schedule と入力するか、左サイドバーの「Scheduled」から作ります。頻度は毎時・毎日・毎週・平日・手動から選べます。承認モード、モデル、作業フォルダ(任意)も指定できます。人事の業務でいえば、期限が近い手続きの洗い出しや、応募状況の集計が候補になります。

スケジュールされたタスクはクラウドで動くため、PCがスリープでもデスクトップアプリが閉じていても実行されます。実行ごとに独立したCoworkセッションになり、結果は「Scheduled」から見直せます。

ヘルプの同じページに、クラウド実行のタスクは「PC上のフォルダに紐づけられない」という説明と、作成画面の「作業フォルダ(任意)」の項目が並んでいます。端末のファイルやアプリが要るタスクは、ローカルでだけ実行されます。

2026年10月6日から、Pro・Maxでは新しいCoworkタスクがクラウドで動き、設定の「Only on your computer」は選べなくなります。すでに端末で始めたタスクは端末に残ります。応募者のファイルをフォルダごと定期処理に載せる設計は、この点で組みにくくなります。

作業定期実行の向き理由
期限が近い手続きの洗い出し定期実行の向き向く理由出力が通知で足りる
応募状況の週次集計定期実行の向き向く理由失敗しても再実行が容易
候補者への連絡文の下書き定期実行の向き条件次第理由送信の承認を挟む必要がある
選考結果の通知定期実行の向き向かない理由判断と責任が人の側にある

無人で動くタスクについては、安全面のガイドに、機密ファイルに触れる、代理でメッセージを送る、購入するなど取り消しにくい操作をスケジュールしないという注意があります。候補者へのメール送信や、外部の求人媒体への掲載更新は、この種類に入ります。

よくある質問

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

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

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

Connectorsで接続できるサービスなら、委任された権限の範囲で読み書きできます。接続対象にないツールは、Cowork内蔵のブラウザーで画面を操作する形になります。

内蔵ブラウザーは、手元のブラウザーやログイン、タブとは別のものです。一度サインインして全セッションで使うか、cookieを取り込んでログイン状態を引き継ぐ方法もあります。取り込めるのは、macOSではChrome・Edge・Firefox、WindowsとLinuxではFirefoxです。Safariからは取り込めません。Pro・Max・Teamプランのデスクトップアプリで使え、Enterpriseでは管理者が組織設定のCoworkで管理します。まず1件だけで試し、安定して動くかを確かめてから定常運用に載せる進め方が現実的です。

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

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

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

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

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

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

まとめ

人事でCoworkを使う判断の軸は2つです。評価・合否・順位付け・属性の推測・過去実績からの基準づくりは渡さず、渡すデータは作業に必要な列に絞ります。

最初の一歩としては、1職種分の求人票を材料から分解して下書きさせ、直した箇所を数える形が現実的です。直しが要件の書き方に集中していれば、材料の作り方を先に整えるほうが早く効きます。

この記事を共有:XはてブLinkedIn