退職者が出た採用記事の対応方法：削除せずに運用を続ける設計

採用サイトに掲載した社員インタビュー記事。掲載後にその社員が退職してしまい、「記事を削げるべきか」と悩んでいませんか。

多くの企業では、退職者の記事を非公開にするルールがあります。しかし、記事を削除すると、その記事経由で流入していた求職者を失い、検索順位も下がります。

この記事では、退職者が出ても記事を削除せずに運用を続けるための設計と、ChatGPTを使った対応手順を解説します。

なぜ退職者の記事を削除するのか

退職者の記事を削除する理由は、主に以下の3つです。

1. 求職者に誤解を与える恐れ

「この人と働けると思って応募したのに、既に辞めていた」という求職者からのクレームを避けるため。

2. 退職者本人からの削除依頼

退職後、本人が「前職の情報をネット上に残したくない」と削除を求めるケース。

3. 会社の方針

「在籍していない社員の情報は掲載しない」という社内ルールがあるため。

しかし、これらは記事の設計を変えることで回避できる問題です。退職を前提とした記事設計にすれば、削除する必要はなくなります。

退職を前提とした記事設計の原則

退職者が出ても記事を残せるようにするには、以下の3つの原則を守って記事を設計します。

原則1: 個人に依存する情報を最小化する

記事の価値を「その人の存在」ではなく「その体験の内容」に置きます。

避けるべき表現：

• 「田中さんは現在、◯◯プロジェクトを担当しています」
• 「田中さんに相談すれば解決できます」
• 「田中さんのようなエンジニアを募集しています」

推奨する表現：

• 「入社3年目のエンジニアは、◯◯プロジェクトを経験します」
• 「困ったときは、チーム内で相談できる仕組みがあります」
• 「このような経験を積みたいエンジニアを募集しています」

原則2: 「当時の状況」であることを明示する

記事が「現在進行形の情報」ではなく「過去のある時点の記録」であることを示します。

• タイトルに年月を入れる: 「2024年入社・エンジニアの1年目」
• 記事冒頭に掲載日を明記する: 「この記事は2024年4月時点の情報です」
• 本文は過去形で統一する: 「担当していた」「感じた」「考えていた」

原則3: 退職後の対応手順を事前に決めておく

退職が発生する前に、記事をどう扱うかのルールを明文化します。

ChatGPTで退職対応の手順を作る

以下の手順で、退職者が出たときの対応プロセスを作成します。

ステップ1: 現在の記事の退職リスクを診断する

既存の記事が「個人依存」になっていないかをチェックします。

以下の採用インタビュー記事を読んで、退職リスクを診断してください。

【記事本文】
<既存記事のテキストをコピー>

【診断項目】
1. 「現在」「現職」など現在進行形の表現がどこにあるか
2. 「この人がいる」ことを前提にした表現がどこにあるか
3. 個人名が何回出現するか
4. 削除せずに残すために修正が必要な箇所

【出力形式】
- 退職リスク: 高/中/低
- 修正が必要な箇所: <リスト>
- 修正案: <具体的な書き換え案>

ステップ2: 記事を「退職前提」に書き換える

診断結果をもとに、記事を修正します。

以下の採用インタビュー記事を、退職者が出ても削除せずに残せる形に書き換えてください。

【元の記事】
<既存記事のテキスト>

【修正方針】
- 現在進行形を過去形に変更
- 個人に依存する表現を「職種・役職」の一般表現に変更
- 記事冒頭に「この記事は<掲載日>時点の情報です」を追加
- 個人名の出現回数を減らす（見出しや繰り返しを削る）

修正後の記事全文を出力してください。

ステップ3: 退職時の注釈を作成する

退職者が出たときに記事冒頭に追加する注釈文を作成します。

以下の採用インタビュー記事について、掲載された社員が退職した際に記事冒頭に追加する注釈を作成してください。

【記事情報】
- タイトル: <記事タイトル>
- 掲載日: <掲載日>
- 退職日: <退職日>

【注釈に含める要素】
- この記事は過去の記録であること
- 掲載された社員は退職していること
- 記事の内容（当時の働き方や制度）は参考になること
- 現在の状況は別ページで確認できること（リンク先も提示）

200字程度で、求職者が誤解せず、かつ会社への悪印象を与えない文章にしてください。

ステップ4: 社内ルールを文書化する

退職時の対応手順を社内ドキュメントにまとめます。

以下の情報をもとに、「採用サイト記事の退職対応マニュアル」を作成してください。

【現在の運用】
- 掲載記事数: <数>
- 更新頻度: <頻度>
- 退職が発生した回数: <回数/年>

【マニュアルに含める項目】
1. 退職が発生した際の初動（誰に報告するか、いつまでに対応するか）
2. 記事の修正手順（注釈の追加、本文の変更）
3. 退職者本人から削除依頼があった場合の対応
4. 記事削除が必要なケース（誹謗中傷、機密情報の記載など）

各項目について、具体的な手順と判断基準を含めてください。

ステップ5: 新規記事のテンプレートを作る

今後作成する記事が最初から「退職前提」になるよう、テンプレートを用意します。

採用サイトの社員インタビュー記事のテンプレートを作成してください。このテンプレートを使えば、掲載後に退職者が出ても記事を削除する必要がない設計にしてください。

【テンプレートに含める要素】
- 記事冒頭の注釈（掲載日と「当時の情報」であることの明示）
- 見出し構成（個人名を使わない設計）
- 本文の時制（過去形で統一）
- 記事末尾のリンク（最新の採用情報へ誘導）

Markdown形式で出力してください。

ChatGPTでできないこと

ChatGPTは記事の修正案までしかできません。以下は人間が判断する必要があります。

1. 退職者本人への確認

記事を残すことについて、退職者本人の同意が必要です。退職面談や退職後の連絡で、記事の扱いを確認する必要があります。

2. 法的リスクの判断

記事内容が退職者のプライバシーや名誉を侵害していないか、法務部門や弁護士への確認が必要な場合があります。

3. 記事削除が必要なケースの見極め

退職理由がトラブルや懲戒処分の場合、記事を残すことが適切かどうかの判断は、人事と経営層が協議する必要があります。

sonataで退職リスクを最小化する

sonataは、記事作成時に退職リスクを考慮した設計を自動で適用します。

• 過去形での記事生成: デフォルトで「当時の状況」として記述
• 個人名の最小化: 見出しや繰り返しで個人名を使わない設計
• 退職時の注釈テンプレート: 退職発生時に追加する注釈を自動生成
• 記事アーカイブ機能: 退職者の記事を「過去の記録」として分類

採用記事は一度作ったら終わりではなく、継続的に運用する資産です。sonataは記事の作成から運用まで、長期的な価値を保つ仕組みを提供します。

sonataを試してみる