お問い合わせ
2026 / 06 / 29 更新 2026 / 09 / 01 セキュリティ

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

Lead

士業事務所の退職者オフボーディングで漏れがちなAIツール連携を、法人SaaS・個人契約・OAuth連携の3層に分けて棚卸しする手順と、書面合意・ログ保全のチェック項目を整理します。

結論: 退職者オフボーディングでは、法人契約AI・個人契約AI・OAuth/API連携の3層に分けて棚卸しします。失効の挙動はサービスと認証方式によって異なるため、「SSOを止めればすべて残る」「すべて止まる」のどちらにも一律化しません。

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

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

退職時は、給与計算、顧問先管理、メールだけでなく、法人契約AI、個人契約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アカウントを無効化したときのトークン失効は、IDプロバイダ、トークンの発行元、種類、連携先の実装によって異なります。APIキー、外部アカウント、連携先に複製済みのデータは、SSOとは別に確認が必要です。

層対象例失効手段事務所側の制御可否
第1層：法人契約SaaS法人向けAIアシスタント / AI統合業務スイート管理コンソール・SSO無効化即時に可能
第2層：個人契約・無料汎用AIチャットの個人プラン本人による履歴削除・解約、必要に応じ契約・法的対応事務所の管理コンソールからは通常操作できない
第3層：連携API・OAuthクラウドストレージ / 共有ノート / チャット / 会計ソフトのトークン各SaaS管理画面でのトークン取消SaaSごとに個別作業が必要

第1層は事務所の管理権限で停止できる場合がある一方、第2層は事務所の管理コンソール外です。第3層の失効方法は発行元と認証方式で異なります。共有IDでは退職者個人の操作を切り分けにくいため、この3層分けとは別に共有資格情報の変更とアクセス記録を確認します（AI時代の共有IDが危険な理由）。

この3層は、「事務所の管理権限で操作できるか」「発行元で個別失効が必要か」「本人への確認や契約・法的対応が必要か」を分けるための設計例です。サービスごとの公式手順と契約関係を確認して使います。

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

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

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

第二に、連携の問題です。クラウドストレージ、チャット、会計ソフト等とAIを連携している場合、退職者名義の接続とトークンも棚卸しします。実際にアクセスが残るかは、発行元、権限、失効仕様によって異なります。

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

この3点は独立とは限りません。個人アカウント、外部連携、顧問先データが同じ経路で結び付く仮想シナリオも含めて、退職処理を設計します。

棚卸し対象にする5箇所

次の5箇所は、ShigyoAIが漏えい頻度を調査した結果ではなく、オフボーディングの棚卸し候補です。

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

これらは、メイン業務システム（メール・給与・顧問先管理）の管理画面だけでは確認できない場合があります。本人への聞き取り、端末・契約・SSO・接続済みアプリの記録を組み合わせます。個人アカウントの扱いは、雇用契約、利用規程、本人との合意、適用法令を確認して決めます。

これら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.監査ログの保全

契約、法令、社内規程で定めた保存期間に従い、必要なAIツール利用ログを退職後も参照できる形で保全します。「3か月」などの固定期間を根拠なく一律に採用せず、調査・監査・個人情報の最小化を含めて期間を決めます。

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

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

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

Google Workspaceでは、管理者ヘルプに「ユーザーを停止するとサインインCookieとOAuthトークンがリセットされる」と明記されています。したがって、「停止後もGoogle発行のリフレッシュトークンだけが必ず生き続ける」という説明は誤りです。一方で、ユーザーが許可していた第三者アプリ、外部サービス側に複製済みのデータ、Google以外が発行したAPIキーや別アカウントは、停止だけでは棚卸しできません。管理画面の名称は変更されるため、実施時はGoogle Workspaceの公式手順を確認し、対象ユーザーの接続アプリと監査ログを確認します。

Microsoft 365では、Microsoftの公式手順がアカウントの無効化とセッション・トークンの失効を別の操作として案内しています。対象ユーザーのアクセスを緊急に止める場合は、Microsoft Entraの最新手順に従い、アカウント無効化、セッション失効、必要に応じたアプリ同意・資格情報の確認を行います。画面名を本記事だけで固定せず、実施時点の公式手順を使います。

Google・Microsoft以外のSaaSでは、アカウント停止とAPIキー・OAuthトークンの失効が同じ操作か別操作かを公式手順で確認します。画面名や管理単位を一般化せず、「対象者が発行・許可した資格情報を発行元で確認したか」をチェック項目にします。

接続済みアプリの一覧は、退職時だけでなく在職中も点検します。点検周期は、連携の追加頻度、扱うデータ、監査要件に応じて決め、実施記録を残します。

退職者がAIツールやSaaSの管理者である場合は、無効化前に別の管理者が操作できること、契約者情報・請求先・復旧手段を確認します。複数管理者を登録できるか、緊急アクセス用アカウントを認めるかは製品仕様と自所の統制に応じて決めます。

管理画面で必要な失効操作ができない場合は、ベンダーの公式サポートへ失効方法を確認します。パスワード変更だけで既存トークンが失効するとは限りません。失効後は、許可された検証手段でアクセス不能になったことを確認し、実施記録を残します。守秘義務上の評価や通知要否は、事実関係と適用される法令・契約に基づいて専門家へ確認します。

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

士業別の棚卸し候補

以下は業種別の利用実態を調査した表ではなく、棚卸し時に確認するツールとデータの候補です。自所の契約一覧と実際の業務フローに置き換えて使います。

税理士事務所なら会計データへのAPI連携、法律事務所なら契約書・訴訟記録・相談メモの保存先、社労士事務所なら勤怠・給与・従業員情報を扱うSaaSとの連携が確認候補になります。これは各士業で常にそのツールが中心だという主張ではありません。

守秘義務の根拠、対象情報、必要な措置は士業と案件によって異なります。まずアクセス経路を洗い出し、その事実を基に法令・所属会規程・契約上の対応を確認します。

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

士業典型的に使われるAIツール・SaaSの傾向退職時に特に確認したい点
税理士事務所会計ソフトのAI仕訳提案機能、記帳代行の自動化ツール、税務相談チャットボット顧問先の会計データへのAPI連携権限、法人カード明細連携のトークン
法律事務所契約書レビューAI、判例検索AI、リーガルリサーチツール、議事録AI契約書ドラフトの保存先クラウドの権限、相談メモを含む共有ノートの閲覧権限
社労士事務所勤怠管理・給与計算SaaSのAI機能、就業規則作成支援ツール、労務相談チャットボット従業員の個人情報を扱うSaaSとの連携権限、退職者自身の給与データへのアクセス権

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

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

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

チェックリスト

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

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

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

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

ここまでの整理から、チェック候補を4点に絞ります。以下は発生頻度や対策効果を示す統計ではありません。

  • 第2層（個人契約）: 事務所の管理コンソール外なので、利用規程、本人への確認、契約・法的対応を分けます
  • 第3層（OAuth・連携トークン）: 発行元の一覧と監査ログで確認します。点検周期は追加頻度、扱うデータ、監査要件で決めます
  • 退職処理の手順書: AIを独立項目にするかは自所の利用状況で決め、少なくとも3層を確認できる形にします
  • 顧問先側の招待: 事務所のSSO外にある招待は、顧問先側の管理者へ失効を依頼し、完了を確認します

事務所の規模・扱う案件・既存システム構成に合わせ、退職処理の手順書へ「AIツールの3層棚卸し」を追加します。追加だけで未把握の利用がすべて見つかるという保証はありません。

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

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

ここまでの整理を踏まえ、想定質問をQ&A形式でまとめます。

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

事務所の管理コンソールからは通常、本人名義の個人アカウントを操作できません。削除・解約を求められるか、どのような措置が必要かは、利用規程、雇用・委任関係、本人との合意、適用法令により異なるため、断定せず専門家へ確認します。予防策として、個人アカウントの業務利用可否と退職時の取り扱いを事前に文書化します。

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

一律には答えられません。Google Workspaceはユーザー停止時にサインインCookieとOAuthトークンをリセットすると案内しています。一方、Microsoft Entraではアカウント無効化とセッション・トークン失効が別手順です。また、OAuthとは別に発行したAPIキー、外部アカウント、連携先へ保存済みのデータは残る可能性があります。利用中のIDプロバイダと各SaaSの公式手順を確認し、失効後に実アクセスできないことまで検証します。

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

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

退職者のAIツール利用状況は、何を確認すればよいですか。

本人への聞き取りに加え、許可された範囲で端末のアプリ一覧、事務所が管理する契約・支払記録、SSO一覧、各SaaSの接続済みアプリ一覧を突き合わせます。これでも漏れがないとは保証できないため、確認した範囲と確認できなかった事項を記録します。

参考

Author · 著者

中 翔

Tags · タグ
ブログ一覧
Related · 関連記事

この記事を読んだ方は、次の記事も読まれています