退職者アカウントとAIツール連携の見落とし

結論: 退職者オフボーディングでは、法人契約AI・個人契約AI・OAuth連携の3層に分けて棚卸しし、特に本人の協力なしに削除を強制できない個人契約層は、入社時の書面合意で予防するのが現実解です。

ある中規模事務所での仮想ケースを置いてみます。半年前に退職した職員Aについて、所長が夜中にふと不安になります。Slackのアカウントは退職日に無効化しました、メールも止めました、給与計算ソフトの権限も外しました。しかし、Aが個人で契約していたChatGPT Plusに、顧問先X社の名前を含む相談履歴が残っていたかもしれません。共有ノートツールに保存していたプロンプト集に、顧問先Y社の決算データの一部が貼られていたかもしれません。クラウドストレージと連携させていたAIツールのトークンが、まだ生きているかもしれない——。

これは仮想ケースですが、退職者が情報漏えいの起点になりやすいこと自体は、統計として裏付けられています。IPA（独立行政法人情報処理推進機構）が2020年に2,175社を対象に実施した調査では、営業秘密の漏えい経路のうち「中途退職者（正規社員・役員）」によるものが36.3%と最多でした（出典）。特定の企業や個人を指す話ではなく、退職という切れ目そのものが構造的にリスクの起点になりやすい、という統計です。

退職時にメインの業務システム（給与計算、顧問先管理、メール）からアカウントを抜く運用は、多くの事務所で定着しています。一方で、AIツールは「個人契約のまま使っていた」「無料アカウントで試しに入れた」「他のサービス経由で連携していた」というケースが混在しがちで、退職時の棚卸しから漏れる典型ポイントになります。株式会社SmartHRが2025年6月に実施した調査（ID管理システム未導入企業の情報システム担当者108名対象）では、63.9%が「退職者や異動後のSaaSアカウントを適切に管理できていない」と回答しており、58.0%が「退職者アカウントの不正利用」を懸念しています（出典）。AIツールに限らず、SaaS全般で退職者アカウントの棚卸しは、多くの事務所にとって既に構造的な課題です。本記事では、悪意の有無を問わず退職者にアクセス権が残っている状態そのものが守秘義務上のリスクである、という立場で整理していきます。

以下では、退職者アカウントの整理を「3層」という切り口で捉え直したうえで、具体的な操作手順・業種別の違い・チェックリストの順に見ていきます。

AIツールの退職者リスクは「3層」あります

退職者アカウントの問題は、「Slackを消す」「メールを消す」と一言で済むものではありません。AIツールに関しては、少なくとも次の3層に分けて棚卸しする必要があります。

第1層：法人契約のSaaS上のAIアカウント

事務所が法人契約しているサービス（大手プロバイダの法人向けAIアシスタント、AI統合された業務スイートなど）上のアカウントです。SSOや管理者コンソールがあるため、原理的には一元管理しやすい層になります。ただし、管理者コンソールにログインして棚卸しする運用が定着していないと、有効なまま残り続けます。

第2層：個人契約・無料アカウントで業務利用していたもの

職員が「便利だから」と個人で契約していた汎用AIチャットサービスなどのアカウントで、業務情報を入力していたケースです。事務所側に契約情報がないため、管理者がそもそも存在を把握していないことが多い層になります。退職後も本人のクレジットカードで継続課金され、過去の会話履歴（顧問先名・固有名詞を含む可能性あり）も本人の手元に残り続けます。

第3層：連携API・OAuthトークン・サードパーティ連携

AIツールからクラウドストレージ、共有ノート、チャット、会計ソフトなどへの読み取り権限が、退職した職員のアカウント名義で発行されたままになっているケースです。本人のSSOアカウントを無効化しても、過去に発行されたAPIキーやアクセストークンが別経路で生きていることがあります。

第1層は管理コンソールで即時無効化できるのに対し、第2層は本人の協力なしに履歴削除を強制できず、第3層は接続元のSaaS側まで遡らないと取り消せない、と構造が異なる点が論点になります。共有IDで運用している場合、退職者個人を切り分けること自体が難しくなるため、この3層分けの前提が崩れます(共有IDが抱える構造的な問題はAI時代の共有IDが危険な理由で扱っています)。

この3層構成は、退職処理の担当者が「どこまで自分たちで止められるか」を判断する軸としても機能します。第1層は事務所の権限だけで完結し、第3層はSaaS側の管理画面まで手を伸ばす必要があり、第2層は最終的に本人の協力なしには完結しません。退職処理のチェック項目をただ並列に並べるのではなく、制御可能性が異なる3つの経路として扱うほうが、担当者が現場で迷わず動けます。

AI時代に特に重要な3つの理由

「退職時のアカウント整理」自体はAI以前から存在する論点です。それでもAIツールについて改めて取り上げる理由は、3点あります。

第一に、学習・履歴の問題です。個人情報保護委員会は生成AIサービスの利用に関する注意喚起のなかで、個人情報取扱事業者が本人の同意を得ないまま生成AIサービスに個人データを含むプロンプトを入力し、応答結果の出力以外の目的で取り扱われた場合に、個人情報保護法の規定に違反することとなる可能性があると指摘しています。提供事業者が個人データを機械学習に利用しないことなどを十分に確認するよう求められている点も、公式情報を確認しておきたいところです。退職者の個人アカウントに顧問先情報を含む会話履歴が残っている場合、事務所はその履歴を制御できません。AI以前のメール削除よりも難度が一段上がります。

第二に、連携の問題です。AIツールは単体で完結しなくなりました。クラウドストレージを読み込ませる、チャットツールに連携する、会計ソフトとAPIでつなぐ、といった構成が一般化しており、退職者のアカウントが連携元として登録されたままだと、退職後もAI経由で情報にアクセスできる経路が残ります。

第三に、顧問先データの問題です。士業事務所のデータには、顧問先・依頼者の個人情報が含まれることが前提になります。退職者がアクセスできる状態を放置することは、悪意の有無を問わず、守秘義務上の論点として残り続けます。

この3点は独立した問題ではなく、連鎖して起こることが多いという点も付け加えておきます。学習・履歴の問題が残っている個人アカウントに、連携の問題を通じて顧問先データがさらに流れ込み、結果として顧問先データの問題が拡大する、という順序で表面化するケースが目立つため、退職処理を設計するときはこの連鎖を意識しておきたいところです。

漏れやすい5箇所

オフボーディングのチェック項目を作るときに、現場で実際に漏れやすい場所を5つ挙げます。

• 顧問先が契約しているSaaSへの招待状態: 顧問先の会計ソフト、勤怠管理SaaS、契約管理ツールなどに、職員個人のアドレスでゲスト招待されているケースです。事務所のSSO配下にないため、退職時の自動失効が効きません
• 共有ノート・社内Wikiの閲覧権限: プロンプト集、業務ノウハウ、顧客対応マニュアルなどが置かれているケースで、ページ単位の権限が個人アカウントに紐づいています
• チャットのDM・プライベートチャンネルに残った機密情報: DM内に貼られた顧問先資料、プロンプトのコピペ、APIキーなどが該当します。本人のアカウントを無効化しても、メッセージは消えません（必要なら別途エクスポートと削除が要ります）
• 個人アカウントで作った汎用AIチャットの会話履歴: 業務で使っていたかどうかを本人申告ベースで確認するしかなく、申告漏れがあると追跡不能になります
• 個人で発行したAPIキー・Personal Access Token: コード管理サービス、AIプロバイダAPI、チャットアプリ、クラウドプラットフォームなどで職員個人が発行したトークンが、自動化スクリプトや個人PCのローカル開発環境に残っているケースです

これらは、メイン業務システム（メール・給与・顧問先管理）を見るだけでは検知できません。「退職者からAI関連の利用状況を一覧で聞き取る運用」を入れるか、そもそも「個人アカウントでの業務利用を禁止して法人プランに一本化する運用」を入れるか、いずれかの予防策が要ります。事務所側には、退職者本人が個人契約していたAIサービスの解約状況を確認する手立てが用意されていないことが多く、把握できないまま残りやすいです。

これら5箇所の共通点は、いずれも「メインの業務システムの外側」で起きているという点です。退職処理のチェックリストが業務システム中心に作られていると、この外側の領域は担当者の記憶とヒアリングだけが頼りになり、担当者が変わるたびに精度が落ちていきます。対策として有効なのは、退職が決まった時点で本人に、使っていたAIツール・SaaS連携の一覧を書面で提出してもらう運用を、退職手続きの正式な書類の一つに組み込んでしまうことです。口頭のヒアリングだけに頼ると、本人の記憶違いや申告漏れが、そのまま検知漏れにつながります。

オフボーディング6ステップ

退職が決まってから最終出社日までに踏むべき手順を、AIツールに限定して整理します。

1.利用棚卸しのヒアリング

退職予定者本人に、業務で使っていたAIツールの一覧（法人契約・個人契約・無料を問わず）を出してもらいます。「思い出せる範囲で」ではなく、ブラウザのブックマーク、PCのアプリ一覧、クレジットカード明細をベースに洗い出してもらうのが現実的です。

2.法人契約サービスのアカウント無効化（最終出社日当日）

SSO連携している場合は、IDプロバイダ側でアカウントを無効化することで、配下のサービスを一括失効させる運用が望ましいです。大手プロバイダの法人プランでは、既存のIDプロバイダ経由でサインインし、管理者がアクセスとオフボーディングを一元管理する運用を前提とした設計を提供しているケースが多いので、公式情報を確認のうえ自所の構成に合わせてください。

3.連携API・OAuthトークンの取り消し

各SaaSの管理者コンソールで、退職者のアカウントが発行したAPIキー・OAuth連携・Personal Access Tokenを取り消します。これはSSO無効化とは別作業になることが多い点に留意したいところです。

4.共有ドキュメント・チャンネルの権限再確認

共有ノート、クラウドストレージ、チャットのプライベートチャンネル、DM履歴などで、退職者が単独で持っていた権限を別の職員に引き継ぐか、削除します。

5.個人アカウントの会話履歴の取り扱い合意

個人契約のAIサービスで業務情報を入力していた履歴について、退職時の取り扱いを書面で合意します。退職者本人の個人アカウントの履歴を事務所側で強制削除することはできないため、入社時の利用規程・退職時の確認書類に「個人アカウントでの業務利用は禁止」「業務情報の入力履歴は退職前に削除する」と明文化しておく予防策が現実解になります。この合意は退職者本人の協力を前提にしており、円満退職でないケースや、本人が非協力的なケースでは実効性が下がる点は認識しておく必要があります。そうしたケースへの対応は、書面合意という予防策の範囲を超え、顧問弁護士等への相談を要する場面になります。

6.監査ログの保全

退職前3か月程度のAIツール利用ログを、退職後に参照可能な形でエクスポート・保管します。事後に「あの時何を入力したか」を確認できる体制があると、顧問先から問い合わせを受けたときに応答可能性が高まります。

ここまでの6ステップは運用の骨格ですが、特に3.の連携API・OAuthトークンの取り消しは、実際の管理画面でどこを操作すればよいかが分かりにくい場面が多い工程です。次のセクションでは、その具体的な操作を掘り下げます。

退職者のAIアカウントは本当に削除できているか

SSOで法人アカウントを無効化した後も、「本当に接続が切れているか」を確認する作業が別途必要です。ここでは、Google WorkspaceとMicrosoft 365を例に、退職者が発行したOAuthトークン・APIキーを実際にどう失効させるかを、管理画面の操作単位で見ていきます。画面名・メニュー名は各社の仕様変更で変わることがあるため、実施時は必ず公式のヘルプページで最新の手順を確認してください。

Google Workspaceを法人契約している場合、管理コンソール（admin.google.com）にログインし、「ディレクトリ」から対象ユーザーを開いて「サインインを無効にする」を実行するのが最初の一手です。ここまでは多くの事務所が既にオフボーディング手順に組み込んでいます。見落としやすいのはその先で、同じユーザーの詳細画面にある「セキュリティ」タブを開くと、そのユーザーが許可した第三者アプリの一覧が表示されます。議事録の自動要約サービスやAIチャットの拡張機能など、便利さから個人の判断で許可していたアプリがここに残っていることがあり、行ごとに「アクセスを取り消す」を実行しないと、アカウントを無効化した後もリフレッシュトークンだけが生き続けることがあります。加えて、管理コンソールの「レポート」から「監査と調査」を開き、対象ユーザーのトークン発行イベントを検索すると、いつ・どのアプリに・どの範囲の権限を渡していたかを事後的に洗い出せます。

Microsoft 365を使っている場合は、管理センター（admin.microsoft.com）側でユーザーのサインインをブロックするだけでは不十分です。Entra ID（旧Azure AD）の管理画面にある「エンタープライズアプリケーション」を開き、「ユーザーが同意したアプリ」の一覧を確認する作業が別途必要になります。標準機能に加えて、業務効率化のために職員個人の判断で連携を許可したサードパーティアプリがここに含まれていることがあり、管理者がアプリごとにアクセス許可を取り消さない限り、連携は生きたままになります。既存のセッションを即座に切るには、同じ管理画面から対象ユーザーのサインインを取り消し、発行済みのリフレッシュトークンを無効化する操作も合わせて実施します。

Google・Microsoft以外の個別SaaS（クラウドストレージ、議事録ツール、チャットツールなど）についても、共通する注意点が一つあります。「ログインを止める」操作と「そのユーザーが発行したAPIキー・OAuthトークンを取り消す」操作が、管理画面上で別のメニューに分かれていることが多い、という点です。多くのSaaSでは管理者向け設定画面の中に「連携アプリ」「Connected Apps」「APIキー管理」といった名称のメニューが独立して存在し、ユーザー単位ではなくキー単位・トークン単位で一覧が表示されます。オフボーディングのチェック項目には「ログイン無効化」の1行だけでなく、この人が発行したトークン・キーを発行元の管理画面で個別に確認し取り消したか、という項目を独立して置く必要があります。

接続済みアプリの一覧は、退職処理のタイミングだけでなく、在職中から定期的に点検しておくと、退職時の作業量そのものが減ります。四半期に1回、管理コンソール側で「連携アプリ」「接続済みアプリ」の一覧を確認し、使われていない連携を随時整理しておく運用が、退職時の棚卸しの負担を軽くする現実的な予防策になります。

退職者自身がAIツールやSaaSの管理者権限を持っていた場合は、通常の利用者アカウントの無効化だけでは不十分です。管理者権限を持つアカウントを無効化する前に、他の職員を管理者として登録しておくか、既存の別の管理者が単独で操作できる状態を確認しておかないと、退職処理の途中で誰も管理コンソールを操作できなくなる事態が起こり得ます。退職者が新しいAIツールを最初に導入した張本人だった場合は、この点のリスクがさらに一段上がります。契約者情報・請求先・管理者権限のすべてがその人物に紐づいていることがあり、退職が決まってから初めて、このツールの管理者が他に誰もいないと判明するケースがあるためです。新しいAIツールを導入する際に、契約時点で複数人を管理者として登録しておく運用が、退職リスクへの根本的な予防策になります。

管理画面が細かい単位でのトークン管理に対応していないSaaSも一定数存在します。その場合の次善の策は、対象アカウントのパスワードを強制変更したうえでログアウトさせる、あるいはベンダーのサポート窓口に退職者名義のアカウントの強制解除を依頼する、という代替ルートです。これを退職処理の手順書にあらかじめ明記しておくと、細かい管理画面が用意されていないSaaSに当たったときも、担当者が現場で立ち往生せずに済みます。この作業を怠ると起きるのは、退職者本人に悪意がなくても、退職後も生きているトークンを通じて第三者が顧問先データに触れられる状態が放置される、という結果です。事務所の守秘義務は、悪意の有無ではなく、アクセスできる状態そのものを基準に問われる場面が多いため、トークンの生死を機械的に確認する運用として位置づけておく必要があります。

Slack・Notion・ChatWorkのような日常的なコラボレーションツールも、AI要約・AI検索機能を組み込んだプランでは、退職者のアカウントに紐づく形でAI機能へのアクセス権が発行されていることがあります。「AIツールかどうか」という区分ではなく、「AI機能を持つSaaS全般」という広い枠で洗い出す視点を持っておくと、見落としが減ります。

士業別に見るAIツールの使われ方の違い

ここまでの3層・6ステップは、士業事務所全般に共通する枠組みです。ただし、実際にどのAIツールが職員の手元で使われているかは、税理士・弁護士・社労士のあいだでかなり違いがあります。業種ごとの典型的な利用実態を踏まえてチェック項目を作ると、棚卸しの漏れが減ります。

税理士事務所では、会計ソフトに組み込まれたAI仕訳提案機能や、記帳代行を自動化するツールが業務の中心に近い位置にあります。退職者が顧問先の会計データに直接アクセスできるAPI連携を個人名義で設定していないか、法人カードの明細取り込みと連携するサービスのトークンが残っていないかが、確認すべき論点になります。法律事務所では、契約書レビューAIや判例検索AI、リーガルリサーチ用のツールが中心です。契約書ドラフトの保存先クラウドストレージへの権限や、訴訟記録・相談メモを含む共有ノートの閲覧権限が、退職者個人のアカウントに紐づいたまま残っていないかを見ます。社労士事務所では、勤怠管理・給与計算SaaSに組み込まれたAI機能や、就業規則の作成を支援するツールが中心になります。従業員のマイナンバーや給与情報を扱うSaaSとの連携権限、退職者自身の給与データへのアクセス権が、退職処理と同時に外れているかの確認が要ります。

税理士法・弁護士法・社会保険労務士法は、それぞれ守秘義務の根拠となる条文の位置づけが異なりますが、退職者にアクセス権が残っている状態そのものがリスクになるという結論は共通しています。業種ごとの法的根拠の違いに立ち入るよりも、まず実務上どのツールにどう触れていたかを洗い出すことを優先したほうが、退職処理としては現実的です。

業種別の違いは、主に第2層・第3層で顕著に現れます。第1層の法人契約サービスは業種を問わず管理コンソールでの一元管理が効きますが、第2層・第3層は業種ごとの業務ツールの使われ方に強く依存するため、業種別のチェック観点を持たないと、そもそも何を確認すべきかが担当者ごとにばらつきます。複数の資格を兼業している事務所（税理士と社労士を兼ねる、行政書士登録も持つ、等）の場合は、下表の複数行を組み合わせてチェックする必要があります。兼業事務所ほど扱うAIツールの種類が広がりやすく、退職者一人が複数のカテゴリのツールに同時に触れていたケースも珍しくありません。

いずれの業種でも、共通する落とし穴は同じです。メインの業務システムだけを見て安心してしまい、その周辺で職員が個人の判断で連携させていたAIツールが、業種特有の対象データ（会計データ・訴訟記録・従業員の個人情報）にどこまで触れていたかを確認しないまま退職処理を終えてしまう、という落とし穴です。業種別の典型パターンを事前にリスト化しておくだけで、ヒアリング時に聞くべき質問の精度が上がります。

上表は静的な一覧ではなく、事務所が新しいAIツールを導入するたびに更新していくものとして扱うのが実務的です。導入済みツールの棚卸しと合わせて表を見直す機会を定期的に設けておくと、退職時のヒアリングの精度が保てます。この表を退職時のヒアリングシートに組み込む場合は、担当者が「業務でAIツールを使っていますか」という一般的な質問だけで終わらせず、上表に挙げた具体的なツール名・カテゴリを提示しながら聞き取ると、本人の記憶を引き出しやすくなります。

ここまでの3層・6ステップ・業種別の違いを踏まえたうえで、実際の退職処理で使うチェックリストの形に落とし込みます。

チェックリスト

退職が確定したら、最終出社日までに次の項目を確認します。

抜け漏れが起きやすいのは、法人契約サービスよりも本人の申告に依存する項目です。上から順に確認するのではなく、特に後半の項目を先に潰しておくと、最終出社日直前の慌ただしさに紛れて見落とすリスクを減らせます。

• 退職者が業務で使っていたAIツールの一覧（法人・個人・無料を含む）をヒアリング済み
• 法人契約サービスのアカウントをSSO/管理コンソール側で無効化する手順が確定している
• 退職者名義で発行されたAPIキー・OAuth連携・Personal Access Tokenを洗い出した
• 共有ドキュメント・チャットチャンネルの権限を引き継ぎ済み（または削除済み）
• 個人アカウントの業務利用履歴について、削除・取り扱いを書面で合意した
• 退職前3か月のAI利用ログをエクスポート・保管した
• 顧問先側で職員個人のアドレスを招待していないか確認した

退職者アカウント整理で見落としがちな4つのポイント

ここまでの整理から、規模を問わず詰まりやすいポイントを4点に絞ります。以下はいずれも一般化された傾向であり、断定的な統計調査に基づくものではない点を踏まえたうえで、優先順位づけの参考にしてください。

• 最大の論点になりやすいのは第2層（個人契約）の漏れです。第1層はSSOで機械的に止められますが、第2層は本人の協力に依存します。入社時規程で個人アカウントの業務利用を禁止しておかないと、退職時に手詰まりになりやすい構造です
• 第3層（OAuth・連携トークン）は存在自体が把握されていないケースが目立ちます。連携を作った本人すら、どのSaaSにトークンを渡したか覚えていないことがあります。SaaS側の「接続済みアプリ」一覧を四半期に1回点検する運用が、現実的な対策になります
• 「退職処理の手順書」にAI項目が独立していないケースも少なくありません。多くの手順書は「メール停止」「給与停止」「カードキー回収」の延長で書かれており、AIツールは「その他」扱いになりがちです。AIツールを独立項目として3層に分けて書くだけで、漏れは大きく減らせます
• 顧問先側で職員個人のアドレスを招待しているケースも見落とされやすい論点です。顧問先SaaSへの招待は、事務所のSSO配下にないため、退職時の自動失効が効きません。退職時に顧問先へ通知して招待を取り消してもらう運用を、退職フローに1行追加するだけで状況が改善します

所の規模・扱う案件・既存システム構成によって当てはまり方は変わりますが、退職処理の手順書に「AIツールの3層棚卸し」を1行追加するところから始めれば、把握できていなかったシャドー AIの実態が見えてきます。

退職者に悪意がないことを前提にしても、アクセスできる状態が残っている限りリスクの大きさは変わりません。退職処理の設計は、本人の善意に期待する前提ではなく、アクセス経路そのものを機械的に断つ前提で組み立てておくと、担当者ごとの判断のブレが減ります。

押さえておきたいポイント

ここまでの整理を踏まえ、退職時に事務所からよく寄せられる質問をQ&A形式でまとめます。

退職者が個人契約していたChatGPTのアカウントは、事務所側で強制的に解約・削除できますか。

できません。個人契約のアカウントは本人名義・本人のクレジットカードで契約されているため、事務所側に削除や解約を強制する権限はありません。現実的な対処は、入社時の利用規程や退職時の確認書類に「個人アカウントでの業務利用は禁止」「業務情報の入力履歴は退職前に削除する」と明文化し、書面合意として予防しておくことです。

退職者のOAuth連携やAPIキーは、SSOのアカウントを無効化すれば自動的に止まりますか。

自動的には止まらないことがあります。SSO無効化は本人のログイン自体を止めますが、過去に発行されたAPIキーやOAuthトークンは連携先のSaaS側に個別に登録されており、SSOとは別の経路で有効なまま残るケースがあります。各SaaSの管理者コンソールで「接続済みアプリ」「発行済みトークン」を個別に確認し、取り消す作業が必要です。

顧問先のSaaSに職員個人のアドレスで招待されている場合、退職時にどう対応すればよいですか。

事務所のSSO配下にない招待は、退職処理の自動失効の対象になりません。退職が決まった時点で、退職者が顧問先のシステムに個人アドレスで招待されていないかを本人にヒアリングし、該当があれば顧問先側に連絡して招待の取り消しを依頼する運用を、退職フローに組み込んでおく必要があります。

退職者のAIツール利用状況は、何を確認すれば漏れなく棚卸しできますか。

メインの業務システム（メール・給与・顧問先管理）の確認だけでは、AIツールの利用実態は把握できません。本人への聞き取りに加えて、ブラウザのブックマーク、PCのアプリ一覧、クレジットカード明細をベースに洗い出してもらうこと、法人契約サービスのSSO一覧、各SaaSの連携済みアプリ一覧を突き合わせることで、漏れを減らせます。

参考

• 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等」（令和5年6月2日） https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/
• 総務省・経済産業省「AI事業者ガイドライン」(公表版／本記事公開日時点の最新版は公式ページで確認してください)
  https://www.soumu.go.jp/main_sosiki/kenkyu/ai_network/02ryutsu20_04000019.html
• 大手プロバイダによる法人向けAIアシスタントの提供形態については、各社の公式情報を確認のこと
• 株式会社SmartHR「SaaSアカウント管理に関する実態調査」（2025-06-09公表、ID管理システム未導入企業の情報システム担当者108名対象） https://prtimes.jp/main/html/rd/p/000000376.000015987.html
• IPA（独立行政法人情報処理推進機構）「企業における営業秘密管理に関する実態調査2020」報告書（2,175社対象、中途退職者による漏えいが36.3%で最多） https://www.ipa.go.jp/archive/security/reports/2020/ts-kanri.html