「退職者のアカウントは退職日に無効化しています」——多くの組織がそう答えますが、実際に聞いていくと「アカウント」の定義が組織ごとにバラバラだったりします。メインのSSOアカウントは止めても、共有アカウント・API連携キー・ファイルサーバーの個別共有設定は棚卸しの対象から漏れがちです。そして内部不正は、この「棚卸しの対象から漏れた権限」を通じて起きることが少なくありません。
この記事では、退職者・異動者のアクセス権限をどう管理するかを、事件に依存しない汎用フレームワークとして整理します。題材として、株式会社リクルートが2025年8月と2026年3月に公表した、性質の異なる2件の「元従業員による情報の持ち出し」事案（公式リリース2件）を使います。
この記事でわかること
- アカウント・権限について、標準・公的ガイドライン（NIST SP800-53のPS-4/AC-2と、IPAの内部不正防止ガイドライン）が求めていること
- 退職者・異動者のアクセスを止める際に見落としやすい「権限の種類」を体系的に洗い出す観点
- 退職・異動のタイムラインに存在する「3つの日付のズレ」というリスク構造
- リクルート社の公式リリース2件（2025/8、2026/3）から読み取れる「わかっていること」と「わかっていないこと」の境界
- 内部不正が外部からの通報で顕在化しやすい理由と、その前提に立った検知設計
- コピペで使えるオフボーディング（退職時アクセス遮断）チェックリスト
- 退職者アカウントの棚卸しを今日から始める具体的手順（PowerShellコマンド付き）
この記事で扱わないこと
- 元従業員が情報を持ち出した具体的な手口・技術的経路（両リリースとも非公表であり、現時点で誰にも書けません）
- 進行中の刑事手続の見通し・詳細（「進行中」と公表されているのみです）
- 特定ベンダーのIDaaS・DLP製品の比較・推奨
なお、本記事は個人の学習・技術的展開を目的としたものです。事実はすべて末尾の出典（公式リリース・公的機関・報道を区別）に基づき、考察には「※考察」ラベルを付けています。
1. なぜ「退職者アクセス管理」が技術者のスキルなのか
退職・異動は日常的に発生するイベントであり、内部不正のような「例外的な事件」ではありません。だからこそ、対応が定型化されず、担当者の記憶と善意に依存しがちです。そして退職者アクセス管理が甘い組織は、次の2つの意味でリスクを抱えます。
- 技術的リスク: 退職後もアクセス可能な権限が残り、悪用の余地が生まれる
- 説明責任のリスク: インシデントが起きた際、「いつ・どの権限を・誰が止めたか」を後から説明できない
また、統計的にも警察庁が公表した「不正アクセス行為の発生状況」（令和8年3月公表・対象は令和7年）によると、不正アクセス行為の認知件数は7,190件（前年比約34.2％増）、検挙件数は431件。検挙件数の9割以上が「識別符号窃用型」ーーーつまり他人のID・パスワードの悪用です。[5]
一方で、「退職者アカウントを止める」という言葉が指す範囲は組織によって驚くほど違います。人事システムのアカウントだけを指す組織もあれば、共有アカウント・API連携・物理入退室まで含める組織もあります。この「範囲の曖昧さ」を潰すための観点を、以下に4つ整理します。
2. フレームワーク：退職者・異動者アクセスを管理する4つの観点
観点1：3つの日付のズレを確認する
退職・異動には、性質の異なる3つの日付が存在します。
| 日付 | 意味 |
|---|---|
| 最終出社日 | 物理的に出社しなくなる日 |
| 退職日（雇用契約終了日） | 雇用契約上の終了日 |
| アクセス失効日 | 実際にシステムへのアクセスができなくなった日 |
この3つが同一であれば問題は起きにくいのですが、実務では「有給消化中は最終出社日後もアカウントが生きている」「退職日にIT部門への連絡が漏れて失効が翌営業日になる」といったズレが発生します。このズレの期間が、退職者による持ち出しの「機会の窓」になります。
観点2：権限の網羅性（「アカウント」以外も数える）
退職時に止めるべき対象は、メインのログインアカウントだけではありません。次のようなチェック漏れが典型的です。
- 共有アカウント（部署共有のメールボックス、共通ログインの業務システム等）
- API・連携トークン、個人発行のアクセスキー
- クラウドストレージ上の個人フォルダ・個別共有設定
- 社外SaaSの個別契約（IT部門が把握していないシャドーIT）
- 物理的な入退室権限、貸与端末
「アカウントを止めた」という報告が、実際にはこのうちの一部しかカバーしていないケースは珍しくありません。
観点3：検知は「性善説」に頼らない
退職者による情報持ち出しは、多くの場合、リアルタイムでは検知されません。正当な業務アクセスと悪用の境界が技術的に判別しづらいためです（「大量ダウンロード」は繁忙期の正当な業務でも起こり得ます）。結果として、内部不正は「外部からの通報」や「取引先からの指摘」で事後的に顕在化するケースが多くなります。この前提に立つと、技術的な監視ツールの整備と同じくらい、「外部からの情報提供を迅速に受け止め、調査に着手できる窓口・体制」も内部不正対策の一部だと言えます。
観点4：対策の実効性を検証する（PDCA）
退職者アクセス管理の見直しは、一度実施して終わりではありません。組織変更・システム更改のたびに新しい抜け道が生まれます。対策を「発表」したことと、それが「機能」していることは別問題であり、定期的な監査でこの差を埋める必要があります。
2-1. 標準・ガイドラインは何を求めているか
枠組みはすでに公的文書に揃っています。
NIST-SP800-53 Rev.5 （米国政府系システムのセキュリティ管理策カタログ） [6]
・PS-4 （ Personnel Termination/雇用終了）：雇用終了時に、(a)定められた期限内のシステムアクセス無効化。(b)本人に紐づく認証子（クレデンシャル）の失効、(c)セキュリティ事項を含む退職面談、(d)組織資産（トークン・バッジ・機器）の回収、(e)元従業員が管理していた情報・システムへの組織側アクセスの確保ーを要求
・AC-2（Account Management/アカウント管理）：アカウントの作成・有効化・変更・無効化・削除というライフサイクル全体の管理、不要アカウントの定期レビュー、そして人事プロセス（退職・異動）との連動を要求
IPA「組織における内部不正防止ガイドライン」第５版（2022年4月公開）[7]：「基本方針」「資産管理」「技術・運用管理」「人的管理」等の10観点・33の対策項目で構成され、利用者のアクセス管理、システム管理者の権限管理、共用IDの扱い、雇用終了時の人事手続きと情報資産の返却、といった退職者管理に直結する項目が置かれています。第五版は雇用や人材の流動化の加速など環境変化を踏まえて改訂されており、特に「退職者関連対策」が挙げられています。
2-2.このテーマの本質
ここまで読むと「退職者のアカウントを期限内に無効化せよ」が中心に見えます。
しかし、事故は本人のアカウントの外側で起きていることが結構あります。
テーマの本質は、消すべきは「アカウント」ではなく、『アクセス経路』です。
・退職者が知っている他人・共有・特権アカウントの認証情報
・退職者が発行したAPIキー・アクセストークン
・退職者が設定した共有リンク・外部連携
など、これらは退職者のアカウントを停止したとしても無効化されない代表格です。
（すこし余談）
ちょっとだけ余談を挟みます。筆者が最初に務めたIT会社を退職した後（数日後）に、当時の上司から電話がかかってきました。何か引き継ぎ忘れたことでもあったかな？と思い電話に出てみると「お前、サーバのデータを消したりしてないよな？」という電話でした。
筆者の退職前ではなく、退職後にサーバのデータが突如消えた（消された？は推測）というのです。
もちろん、筆者には身に覚えもないですし、そもそもそのサーバに権限があったかすらわかっていませんでした。その後のことは当時の上司と話しているわけではないのでわかりません。しかし、なぜ上司が疑ったのかは思いあたる節がありました。
筆者が在職時に誤って検証機のデータベースをごっそり消してしまった（コマンド一つで全部消せるのも問題ですがw）ことがありました。
検証用の環境であり実害もなく、バックアップもあったので即日復活することができたのですが、上司から叱責を受けたことがあります。
上司はおそらくそのことが頭にあって、筆者の顔が浮かんだのかなとふと思いました。
これはただの笑い話ですが（当時の会社にとっては笑えなかったでしょうけどw）、人間ですから、ちょっとしたすれ違いや、意思の疎通がうまくいかないことで、何らかの恨みや、復讐、金儲けをしようと考える方もいるでしょう。
もちろん悪意を持ってやっている人の罪は重いです。ただ、悪意がないことで重大なことが起きてしまうこともあります。これは人間の問題ではなく、仕組みの問題だと考えます。
3. 適用例：リクルート社の2事案を4観点で読む
3-0. 事案の概要（公式発表ベース・最小限）
株式会社リクルートは、性質の異なる2件の「元従業員による情報の持ち出し」を公式に公表しています。
| 日付 | 出来事 | 出典 |
|---|---|---|
| 2024/3末 | 元従業員（旅行事業担当）が退職 | [1] |
| 2025/4 | 外部から情報提供 | [1] |
| 2025/6 | 社内調査で持ち出しを確認 | [1] |
| 2025/8/1 | 公式発表（事案①）。再発防止策を表明 | [1] |
| 2025/12 | 外部から情報提供（事案②） | [2] |
| 2026/2 | 社内調査で持ち出しの可能性が判明 | [2] |
| 2026/3/30 | 公式発表（事案②） | [2] |
事案①は、旅行事業に在籍していた元従業員が、取引先である宿泊施設担当者481名分と自社従業員55名分、計536名分の個人情報（名刺情報等）を持ち出していたとされる事案です[1]。事案②は、元従業員が役員32名分・役員秘書24名分・全従業員約19,000名分（2023年4月時点）・部活動関係者1,194名分等を含む社内資料を持ち出し、社外の人物へ渡していた可能性がある事案で、刑事手続が進行中と説明されています[2]。両事案とも、公式リリースの見出しは「情報の持ち出し」で統一されており、「内部不正」という語はリクルート自身の公表文には登場しません。
3-1. 観点1の適用：3つの日付は特定できるか
事案①は退職日（2024年3月末）が公表されていますが、持ち出しが具体的にいつ行われたかは「在職中」とのみ記載され、日付までは特定されていません[1]。事案②は、元従業員の退職日・持ち出しの時期のいずれも公表されていません[2]。
読み取れることは、両リリースとも「アクセス失効日」と「持ち出し行為が行われた日」の関係が特定できる形では書かれていない、という点です。「在職中」という語だけでは、権限が正当だった期間内の行為なのか、退職手続きの隙間（観点1でいう日付のズレ）を突いた行為だったのかを、公開情報からは区別できません。これは次の観点2とも重なる「非公表項目」の一つです。
3-2. 観点2の適用：持ち出された情報の性質から権限を推測する
事案①で持ち出されたのは、取引先担当者の名刺情報等481名分と自社従業員55名分です[1]。これは、営業活動を通じて個人が業務上自然に収集し得る情報という性質を持ちます。一方、事案②で対象となった情報は、役員・役員秘書・全従業員約19,000名分・部活動関係者1,194名分など、個人の営業活動の範囲を超えた、組織が集中管理する社内資料です[2]。
2つの事案を並べると、「情報の性質」が大きく異なることが分かります。事案①は個人の業務範囲内で自然に蓄積された情報、事案②はより広範な社内資料へのアクセスを前提とした情報です。ただし、事案②の元従業員がどのような権限・立場でこれらの情報にアクセスできたのか（人事システムへの正規アクセス権を持つ部署だったのか、共有ファイルサーバーの権限設定の不備だったのか等）は、公式には一切説明されていません[2]。
3-3. 観点3の適用：発覚の端緒はいずれも外部からの情報提供
事案①・事案②ともに、発覚のきっかけは外部からの情報提供でした。事案①は2025年4月、事案②は2025年12月です[1][2]。リクルート自身の内部監視によって能動的に検知されたという記載は、いずれのリリースにもありません。
これは観点3で述べた「内部不正は外部通報で顕在化しやすい」という一般論と整合する実例です。2件とも、技術的な監視の仕組みだけでは発覚しなかった（あるいは発覚したという記載がない）可能性があります。
3-4. 観点4の適用：対策発表と次の事案の関係（※断定を避けて読む）
事案①の公表（2025年8月1日）では、退職・異動時の情報管理プロセスの見直しやモニタリング強化が再発防止策として掲げられていました[1]。事案②の発端となる外部からの情報提供は2025年12月であり、事案①の公表から約4か月後にあたります[2]。
ここで注意が必要です。事案②における持ち出し行為そのものがいつ行われたかは非公表のため、「事案①の対策が事案②を防げなかった」と断定することはできません。持ち出し行為自体が事案①の対策発表より前に行われていた可能性もあります。確実に言えるのは、「事案②の発端となる外部からの情報提供のタイミングが、事案①の対策発表から約4か月後だった」という事実のみです。両者の因果関係は公式には示されていません。
4. 退職者アクセス管理から見えること（※ここからは考察）
以下は公開情報に基づく一般論としての考察であり、本件の確定情報ではありません。
4-1. 「情報の性質」は権限設計のヒントになる
事案①・事案②で持ち出された情報の性質が異なる（個人が自然に蓄積する情報 vs 組織が集中管理する情報）ことは、権限設計を見直す際のヒントになります。前者（名刺情報等）は営業活動という業務の性質上、完全にゼロにすることは難しく、退職時の削除確認・誓約書といった運用面での対応が主軸になります。後者（全社員名簿等の集中管理データ）は、そもそも「誰が」「なぜ」全社規模のデータにアクセスできる権限を持っていたのかという、権限設計自体の見直しが有効な対象です。持ち出された情報の粒度・範囲は、対策すべきレイヤーを教えてくれます。
4-2. 「対策発表」と「対策の実効性」は別レイヤーの問題
観点4で見たとおり、事案①の対策発表から事案②の発端まで約4か月というタイミングの近さは、因果関係こそ断定できないものの、「対策を発表すること」と「対策が機能し続けること」を混同してはいけないという教訓を強く示唆します。退職者アクセス管理は、一度ポリシーを整備して終わりではなく、組織変更・システム更改・人員の入れ替わりのたびに、新しい抜け道が生まれる前提で、定期的な監査サイクルに組み込む必要があります。
4-3. 「非公表」の範囲そのものが情報になる
両リリースとも、持ち出しの具体的な時期・手口・権限の詳細を明かしていません。これは多くの内部不正事案に共通する傾向で、一般論として、捜査上の制約や、手口の詳細を公開すること自体が模倣を誘発するリスクを避けるためと考えられます（※考察）。技術者としては、「非公表」を「なかったこと」と読み替えず、自組織で同種のリスクを検討する際は、悲観的なケース（正規の権限を悪用した、集中管理データへのアクセスだった等）を想定して備える方が安全側に倒れます。
5. コピペで使える：退職者アクセス・オフボーディングチェックリスト
観点1〜4を踏まえたチェックリストです。人事・IT部門で共有し、退職者が出るたびに使ってください。
## 退職者アクセス・オフボーディングチェックリスト
対象者: __________／退職日: __________／最終出社日: __________
### A. 日付の確定（観点1）
- [ ] 最終出社日・退職日・アクセス失効予定日を人事・IT部門で共有した
- [ ] 3つの日付が異なる場合、その期間中のアクセス制限方針（一部制限/監視強化等）を決めた
- [ ] アクセス失効の実施担当者・実施予定時刻を明確にした
### B. 権限の棚卸し（観点2）
- [ ] メインのログインアカウント（SSO/AD/メール/IdP等）を無効化した
- [ ] 共有アカウント（部署共有メール・メーリングリスト・共通ログイン業務システム等）のリスト・パスワードを変更した
- [ ] API・連携トークン、個人発行のアクセスキーを失効させた
- [ ] クラウドストレージの個人フォルダ・個別共有設定を確認し、権限を移管または削除した
- [ ] 本人が契約・利用していたSaaS（シャドーIT含む）の有無を確認した
- [ ] 物理入退室権限・貸与端末を回収した
### C. 事後対応（観点3・4）
- [ ] 退職前後（例：直近30日間）のアクセスログ・ダウンロード履歴を保存した
- [ ] 異常な大量アクセス・大量ダウンロードがなかったか一次確認した
- [ ] 情報の持ち出し・機密保持に関する誓約書へのサインを確認した
- [ ] 外部から情報提供・通報があった場合の一次対応窓口・エスカレーション先を明確にした
### D. 定期監査（観点4）
- [ ] 直近半年〜1年以内に退職した従業員のアカウントが、実際にすべて無効化されているか棚卸しした（野良アカウントがないかも確認）
- [ ] 過去に公表した再発防止策が現在も運用されているか確認した
6. おまけの実務編：退職者アカウントの棚卸しを今日から始める
本件の権限管理の詳細は非公表です。ここからは本件を離れた一般論として、Active Directory環境を例に、退職済みのはずなのに有効なままのアカウントを洗い出す手順を載せておきます。
実行にあたっての注意: 以下のコマンドは、自組織が管理者権限を持つActive Directory環境に対してのみ実行してください。退職者情報は人事情報を含むため、実行前に人事・法務・情報システム部門の承認を得た上で、実施記録が残る形（承認申請・実行ログの保存）で行うことを推奨します。
手順1：長期間ログインのない有効アカウントを洗い出す
# 90日以上ログインがない「有効」なADアカウントを一覧化する
# （自組織が管理するADドメインに対してのみ実行。実行には管理者権限が必要）
Get-ADUser -Filter {Enabled -eq $true} -Properties LastLogonDate, PasswordLastSet |
Where-Object { $_.LastLogonDate -lt (Get-Date).AddDays(-90) -or $_.LastLogonDate -eq $null } |
Select-Object Name, SamAccountName, LastLogonDate, PasswordLastSet
出力結果を人事側の退職者リストと突合し、「退職済みのはずなのに有効」なアカウントがないかを確認します。LastLogonDate はドメインコントローラーによってレプリケーションの遅延があるため、複数のドメインコントローラーで確認するか、余裕を持った閾値（例：90日）で運用するのが安全です。
手順2：特権グループに所属する有効アカウントを棚卸しする
# 特権グループ（例：Domain Admins）に所属する有効アカウントを確認する
Get-ADGroupMember -Identity "Domain Admins" |
Get-ADUser -Properties Enabled, LastLogonDate |
Where-Object { $_.Enabled -eq $true } |
Select-Object Name, SamAccountName, LastLogonDate
観点2で述べた「集中管理データへのアクセス権限」は、多くの場合こうした特権グループの所属状況に表れます。退職者・異動者が特権グループに残ったままになっていないかは、四半期に1回など定期的に確認する価値があります。
手順3：共有アカウント・API連携キーの台帳を作る
特定製品には触れませんが、確認項目は共通です。
| 確認項目 | チェック内容 |
|---|---|
| 共有アカウントの一覧 | 部署共有メール・共通ログイン業務システムを台帳化しているか |
| API・連携キーの発行元 | 誰が・いつ・何の目的で発行したか記録があるか |
| 有効期限 | 無期限のキーが放置されていないか |
| 最終利用日 | 長期間使われていないキー・アカウントが残っていないか |
いずれも標準機能と無料の運用ルールだけで実施でき、観点2（権限の網羅性）を直接つぶしにいく作業です。
7. まとめ
- 退職者・異動者アクセス管理は、「3つの日付のズレ」「権限の網羅性」「検知の構造」「対策の実効性検証」の4観点で構造化できる
- リクルート社は2025年8月・2026年3月に、性質の異なる2件の「元従業員による情報の持ち出し」を公表しているが、持ち出しの具体的な時期・手口・権限の詳細はいずれも非公表
- 両事案とも発覚の端緒は外部からの情報提供であり、自社の内部監視による能動的な検知ではなかった
- 事案②の発端となる外部からの情報提供は事案①の対策発表から約4か月後だが、両者の因果関係は公式には示されておらず、断定はできない
- 退職者アカウントの棚卸しは、無料のAD標準コマンドと運用ルールの見直しだけで今日から着手できる
事案②は刑事手続が進行中と公表されており、続報が出た場合には、観点1（日付の特定）・観点2（権限の詳細）が明らかになる可能性があります。その際は改めて4観点で読み直すのがこのフレームワークの使い方です。
姉妹記事（対象読者が異なります）
本件について、経営層・ビジネスパーソン向けに1分で把握できる図解3枚版と、中小企業向けの低予算対策チェックリスト版などを、対象読者が異なるためnoteで公開しています。よろしければご覧ください。
→ https://note.com/cikano/
参考文献
公式
- [1] 株式会社リクルート「当社元従業員による情報の持ち出しに関するご報告とお詫び」2025/8/1 — https://www.recruit.co.jp/newsroom/pressrelease/2025/0801_143146.html
- [2] 株式会社リクルート「当社元従業員による情報の持ち出しに関するご報告とお詫び」2026/3/30 — https://www.recruit.co.jp/newsroom/pressrelease/2026/0330_147488.html
公的機関
- [3] IPA（情報処理推進機構）「組織における内部不正防止ガイドライン」 — https://www.ipa.go.jp/security/guide/insider.html
- [5] 国家公安委員会・総務大臣・経済産業大臣「不正アクセス行為の発生状況及びアクセス制限機能に関する技術の研究開発の状況」令和8年3月12日ーhttps://www.npsc.go.jp/policy/list/260313.pdf
- [6] NIST SP800-53 Rev.5 PS-4- https://csf.tools/reference/nist-sp-800-53/r5/ps/ps-4/
- [7] IPA「組織における内部不正防止ガイドライン」-https://www.ipa.go.jp/security/guide/insider.html
報道
- [4] 事案①に関する報道各社の記事（要出典・公開前に確認：本記事執筆時点でURLを確実に確認できたもののみを掲載する方針のため、報道記事の具体的なURLは公開前に改めて一次検索の上ご確認ください）
Qiitaでは、現場感のあるホワイトハッカーとしてセキュリティニュースや事故を題材に、技術者・エンジニアの方の参考になる情報を発信していきたいと思います。よかったら❤️＆フォローをお願いできたらと思います。読んでいただいてありがとうございます！