Claude Media
Coworkで退職者オフボーディングをチェックリスト化する

Coworkで退職者オフボーディングをチェックリスト化する

Coworkでアカウント無効化申請・貸与品回収・引き継ぎ資料作成の3工程を、Freshserviceとファイル横断で運用する手順をまとめます。

退職者のオフボーディングは、アカウント無効化申請・貸与品回収・引き継ぎ資料作成という定型の3工程に、担当部署をまたいだ確認作業が重なる業務です。Coworkは、この3工程のうちチケット起票と現状把握をFreshserviceとの接続で自動化し、複数フォルダに散らばった引き継ぎ材料の洗い出しをファイル横断で受け持てます。ただし退職者のアカウント権限に触れる操作は取り消しにくいため、承認モードとツール権限で人の確認を挟む設計が前提になります。

始める前に確認しておくこと

Freshserviceコネクタは、サインインが必要な種類のコネクタです。Freshworks製で、コネクタ一覧への追加は2026年6月です。CoworkのConnectors設定で有効化し、Freshserviceにサインインして接続します。

Team・Enterpriseプランでは、組織設定の「Allow "Always allow" for connector tools」(Organization settings > CoworkのPermissions)が既定でオフです。オフのあいだ、書き込み系のコネクタツールは承認ダイアログの「Allow for all tasks」がグレーアウトし、保存済みの常時許可も効きません。つまりcreateOffboardingRequestのような書き込みツールは、タスクごとに承認する運用が既定になります。

オフボーディングの3工程とCoworkの役割分担

退職者対応の一般的な3点セットは、①アカウント無効化申請②貸与品回収③引き継ぎ資料作成です。Coworkが得意なのは、この3工程それぞれの起票・洗い出し・下書きであり、実際の承認や無効化の実行そのものではありません。

工程Coworkが担う範囲人に残る判断
アカウント無効化申請Coworkが担う範囲Freshserviceへのオフボーディングリクエスト起票人に残る判断申請内容の承認と実行
貸与品回収Coworkが担う範囲資産台帳と本人の貸与記録の突き合わせ人に残る判断回収の実施と受領確認
引き継ぎ資料作成Coworkが担う範囲関連ファイルの洗い出しと下書き作成人に残る判断内容の正確性の確認

3工程とも、Coworkの出力は最終成果物ではなく下書きです。退職者本人のアカウント情報や社内システムへのアクセス権限に関わる操作は、後戻りしにくい性質を持つため、承認モードとツール権限の設計次第で自動化の範囲が変わります。承認ゲートを業務の性質で分類する4つの判断軸はCowork Approval Gatesを部門ごとに設計する考え方にまとめています。

アカウント無効化申請をFreshserviceで起票する

CoworkのFreshserviceコネクタには、createOffboardingRequest(オフボーディングリクエストの作成)とfetchOffboardingRequests(既存リクエストの取得)という専用ツールが用意されています。これは一般的なチケット作成ツールとは別に、オフボーディングという業務そのものを対象にしたツールです。同じコネクタには対になるcreateOnboardingRequest・fetchOnboardingRequestFormもあり、入社と退職の両方をFreshservice側の業務フローとして扱える設計になっています。

指示文の例
{taishoku_meibo.csv}(退職者一覧: 氏名, 社員番号, 最終出社日,
所属部署, 貸与PC番号)から、{taishoku_taisho} さんの
オフボーディングリクエストをFreshserviceに起票してください。
 
- リクエストには最終出社日とアカウント無効化の希望日を含める
- 所属部署のシステム管理者を承認者に指定する
- 起票前に内容を提示し、私が確認してから実行する
- 起票後、リクエストIDを報告する

最後の「起票前に内容を提示し、私が確認してから実行する」という一文が要です。ただし、この一文だけで確認が必ず入るわけではありません。Freshserviceへの書き込みが確認なしで通るかどうかは、承認モードとコネクタのツール権限の組み合わせで決まります。次の表は、公式のGet started with Claude Coworkにある3×3の対応です。

モードAlways allowNeeds approvalBlocked
ManualAlways allow承認済み扱いNeeds approval毎回確認Blocked拒否
AutoAlways allow読み取りは承認、書き込み・削除はClaudeが判断Needs approvalClaudeが判断Blocked拒否
SkipAlways allow承認済み扱いNeeds approval承認済み扱いBlocked拒否

Manualモードでも、ツール権限が「Always allow」なら確認は入りません。退職者のアカウントに関わるcreateOffboardingRequestは、ツール権限を「Needs approval」にしたうえでManualで使うと、人が必ず画面で止められます。Autoの「Needs approval」はClaudeが判断する欄なので、起票を人の確認に残したいなら選べません。

使わせたくないツールは「Blocked」にすれば、どのモードでも拒否されます。たとえば、貸与品回収の作業ではupdateTicketを使わせないために、Blockedにしておく構成が取れます。なお、新しいClaudeの体験ではモードの選択肢がAutoとManual(既定)の2つになり、Skipは表示されません。公式の安全ガイドは、新しいツールを初めて使う場面と、間違いを元に戻しにくい場面でManualへ切り替えるよう求めています。

貸与品回収は台帳と本人記録の突き合わせで洗い出す

貸与品回収は、何を回収すべきかの一覧を作る作業と、実際の回収そのものを分けて考えると扱いやすくなります。Coworkが受け持てるのは前者です。資産台帳と退職者の貸与記録を突き合わせ、回収対象を漏れなくリスト化する作業は、繰り返しに強い定型作業にあたります。

指示文の例
{asset_master.csv}(資産台帳: 資産番号, 種別, 貸与者社員番号,
貸与日)から、社員番号 {emp_id} に紐づく貸与品を
すべて抽出してください。
 
- 出力: 資産番号・種別・貸与日を回収予定日順に並べた表
- 台帳に記載のない口頭貸与の資産は対象に含められないため、
  「台帳外の可能性」として注記を残す
- 資産番号が重複している行は「要確認」に分類する

FreshserviceのfetchAssets・fetchAgentのようなツールを使えば、台帳データそのものをFreshservice側から直接取得することもできます。ただし社内の資産管理が別システム(Excel台帳やGoogleスプレッドシート)に残っているケースも多く、その場合はCoworkのファイル横断でCSVやスプレッドシートを直接読ませる形になります。台帳が2系統に分かれている組織では、どちらを正とするかを先に決めておかないと、突き合わせの結果が食い違う原因になります。

FreshserviceのコネクタにはcreateTicket・fetchTicket・fetchTickets・updateTicketという汎用のチケット操作ツールも含まれます。Freshservice以外のSaaS(社内Wiki、開発ツール、社外向けSaaSなど)の権限剥奪は、たとえばこれらで個別に起票する組み方もあります。件名にオフボーディングリクエストのIDを入れておくと、後からfetchTicketsで引くときの手がかりになります。

3工程のどこをManual承認に固定するか

3工程のうち、アカウント無効化申請の起票と貸与品回収リストの作成は、実行結果を後から取り消しやすい作業です。誤ったリクエストを起票しても、キャンセルして起票し直せます。一方で、実際にアカウントを無効化する操作そのものや、引き継ぎ資料に機微な情報を含めて共有してしまう操作は、取り消しにくい部類に入ります。

操作取り消しやすさ推奨する承認
オフボーディングリクエストの起票取り消しやすさ起票し直せる推奨する承認Manual + Needs approval(内容確認後に実行)
貸与品回収リストの作成取り消しやすさ何度でも作り直せる推奨する承認読み取り中心のためAutoでも運用可
アカウントの実際の無効化取り消しやすさ元に戻すのに時間がかかる推奨する承認Manual、実行は管理者権限で
引き継ぎ資料の外部共有取り消しやすさ共有後の回収は困難推奨する承認Manual、共有前に内容を確認

振り分けの基準は取り消しにくさです。この判定の視点そのものはCoworkの取り消せない操作をどう見極めるかで扱っているので、オフボーディング以外の業務にも応用できます。

引き継ぎ資料はファイル横断で候補を洗い出してから絞る

引き継ぎ資料作成は、退職者が関わったファイルを一から探す作業が最も時間を取られる部分です。Coworkは接続済みのフォルダやコネクタを横断して、退職者が過去に編集・作成したファイルの候補を洗い出せます。ここでの役割は「候補の洗い出し」までで、実際に何を引き継ぎ資料に残すかの取捨選択は後任や上長が行います。

指示文の例
Google DriveとNotionの中から、{taisho_name} さんが過去6か月に
編集または作成したファイル・ページを洗い出してください。
 
- 出力: ファイル名、最終編集日、格納場所のリンクを一覧化した表
- 進行中の案件に関わるものと、完了済み案件のものを分けて表示する
- 個人用の下書きフォルダは対象から除外する
- 洗い出した一覧そのものであり、引き継ぎ資料の本文は作成しない

「洗い出した一覧そのものであり、引き継ぎ資料の本文は作成しない」という指定を入れているのは、候補一覧と引き継ぎ資料を混同しないためです。洗い出した候補の中から後任が実際に必要な情報を選び、その内容の草稿作成を別途Coworkに依頼する、という2段階に分けたほうが、成果物の性格がぶれません。退職者本人が関わっていた機微な情報(人事評価、給与関連のやり取りなど)が候補に混ざる場合は、洗い出しの時点で除外条件に含めておく必要があります。データの扱い方の全体像はCoworkセキュリティにまとめています。

Claude側の退職者データは削除前に引き継ぐ

Team・Enterpriseでは、Claude自体のメンバー削除にも引き継ぎが要ります。公式の「What happens to a user's data when they are removed」によると、削除後に他のメンバーから見える範囲は次のとおりです。

くらべる

メンバー削除後の見え方

削除前に動く

見えなくなる

非公開(private)のプロジェクトは、他のメンバーからアクセスできません。引き継ぐなら、本人が権限を「組織の全員が編集可」にするか、特定のユーザーへ「Can edit」で招待しておきます。組織内共有のチャットのURLも、「Conversation not found」と表示されて開けなくなります。

そのまま使える

残る

組織全体に共有したプロジェクトは「Team」タブに残ります。特定ユーザーにだけ共有したものは、そのユーザーの「Shared with me」に出ます。本人がアップロードして共有しなかったスキルは本人のアカウント側に残り、同じメールアドレスで再追加されれば「Customize > Skills」に戻ります。

同じメールアドレスで組織に戻した場合は、以前のチャット・プロジェクト・スキルが復元されます。削除したメンバーのデータは、Primary Ownerが実行するデータエクスポートにも含まれます。Enterpriseでは、設定済みのデータ保持ルールも引き続き適用されます。したがって、引き継ぎ資料の洗い出しにはGoogle DriveやNotionだけでなく、本人のClaudeプロジェクトの共有範囲を入れておく必要があります。

退職予定者の一覧を定期的に洗い出す

複数人が同時期に退職するタイミングでは、誰の処理がどこまで進んでいるかを見失いやすくなります。Scheduled Tasksで「毎週月曜に、最終出社日が2週間以内の退職予定者と、その人のオフボーディングリクエストの進捗を一覧化する」タスクを組んでおくと、対応漏れに早く気づけます。

指示文の例
{taishoku_meibo.csv} と Freshserviceの
オフボーディングリクエスト一覧を突き合わせてください。
 
- 出力: 退職者ごとに、最終出社日・リクエスト起票の有無・
  ステータスを一覧化した表
- 最終出社日まで2週間を切っているのにリクエスト未起票の人を
  最上段に表示する
- 実行結果は要約せず、表をそのまま出力する

公式の安全ガイドは、Scheduled Tasksで機微なファイルへのアクセスや、取り消しにくい操作を組まないよう求めています。退職者名簿CSVは個人データそのものなので、この注意はそのまま当てはまります。読ませる列は氏名・最終出社日・リクエスト状況に絞り、実行のたびに出力を見ます。

手元のCSVを読ませる点では、公式ヘルプの2か所の記述がずれています。スケジュールタスクの説明では、タスクは「コネクタとClaudeアカウントに保存したファイルで動き、パソコン上のフォルダには紐づけられない」とあります。一方、手動設定の画面にはフォルダの項目が任意で並び、「ローカルのファイルやアプリが必要なタスクはローカルでしか動かない」という注記も付いています。

さらに、ProとMaxでは2026年10月6日から新しいCoworkタスクがクラウドで動き、「Only on your computer」の設定は消えます。すでにパソコン上で始めたタスクはそのまま残ります。どちらの経路でも成立させるなら、名簿はGoogle DriveやNotionのコネクタ経由で読ませる構成にしておくのが無難です。実行が失敗した場合の気づき方や復旧の手順はCoworkでタスク失敗をリカバリするにまとめています。

処理完了の確認はリクエストのチケット状態で締める

オフボーディングリクエストを起票した時点で作業が終わったと見なすと、システムごとの権限剥奪が漏れたまま放置される事故につながります。FreshserviceのfetchOffboardingRequestTicketsは、オフボーディングリクエストのチケットを取得するツールです。リクエストに紐づくチケットの状態を、この確認に使います。

指示文の例
リクエストID {request_id} のオフボーディングリクエストの
チケットの状態を一覧化してください。
 
- 出力: チケット名・担当システム・現在のステータスの表
- 未クローズのチケットを最上段に表示する
- すべてクローズ済みなら「完了確認済み」と明記する

この確認を退職日の1〜2週間後にもう一度実行すると、未クローズのまま残ったチケットに気づけます。

よくあるつまずき

退職者本人のアカウントで接続したコネクタが切れる

Freshserviceのコネクタは、サインインが必要な種類です。退職者本人のFreshserviceアカウントで接続したままだと、そのアカウントを無効化した後に起票や取得が通らなくなるおそれがあります。オフボーディング関連の接続は、システム管理者など在籍が続くアカウントで組んでおくと安全です。

貸与品台帳とFreshserviceの資産情報が食い違う

台帳更新が手作業のまま放置されている組織では、Freshservice側の資産情報と実際の貸与記録がずれていることがあります。突き合わせの結果に大きな抜けや重複が出た場合は、自動化の設計より先に台帳の運用そのものを見直す必要があります。

引き継ぎ資料の洗い出しが個人用フォルダまで広げてしまう

指示文で除外条件を明示しないと、退職者の個人用下書きフォルダや、業務に無関係な個人的なメモまで候補に含まれることがあります。除外条件は毎回書くより、繰り返し使う指示にまとめておくと、依頼のたびに書き直す手間が省けます。設定の階層ごとの使い分けはClaude Coworkカスタマイズにまとめています。

退職日前後の進め方

退職日を軸に並べると、Cowork側で人が判断する場所が見えます。

手順

退職日前後の順序

  1. 1

    退職の2週間前まで

    名簿とFreshserviceのリクエスト一覧を突き合わせ、未起票の人を洗い出す。リクエストの起票は、内容を人が見てから実行する。

  2. 2

    退職日の前

    本人に、自分の「Scheduled」ページのタスクを止めてもらう。Claudeのプロジェクトの共有範囲を直し、引き継ぎ資料の候補一覧を後任に渡す。

  3. 3

    退職日

    アカウントの無効化とClaudeのメンバー削除を、管理者権限で実行する。Coworkには実行させない。

  4. 4

    退職日の1〜2週間後

    fetchOffboardingRequestTicketsで未クローズのチケットを確認する。

よくある質問

退職者本人がCoworkのScheduled Tasksを設定していた場合はどうなるか

「Scheduled」ページに出るのは、そのユーザーが自分で作成したタスクです。Scheduledのヘルプには、管理者が他メンバーのタスクを一覧する画面の説明がないため、本人がログインしているうちに一覧を見てもらいます。スケジュールタスクは、パソコンがスリープ中でもデスクトップアプリを閉じていても、リモートで動きます。そのため、不要なタスクは本人に一時停止か削除をしてもらうのが確実です。必要なタスクは、後任が自分のアカウントで同じ内容を作り直します。

まとめ

Coworkに任せるのは起票・洗い出し・下書きまでです。アカウント無効化とメンバー削除は、管理者が内容を見て実行します。ツール権限を「Always allow」にしていないか、本人名義のScheduledタスクが残っていないかの2点が、見落としやすい確認項目です。採用から入社手続きまでの前工程はCowork人事の実務で扱っています。

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