ある中規模事務所での仮想ケースを置いてみます。半年前に退職した職員 A について、所長が夜中にふと不安になります。Slack のアカウントは退職日に無効化しました、メールも止めました、給与計算ソフトの権限も外しました。しかし、A が個人で契約していた ChatGPT Plus に、顧問先 X 社の名前を含む相談履歴が残っていたかもしれません。共有ノートツールに保存していたプロンプト集に、顧問先 Y 社の決算データの一部が貼られていたかもしれません。クラウドストレージと連携させていた AI ツールのトークンが、まだ生きているかもしれない——。
退職時にメインの業務システム（給与計算、顧問先管理、メール）からアカウントを抜く運用は、多くの事務所で定着しています。一方で、AI ツールは「個人契約のまま使っていた」「無料アカウントで試しに入れた」「他のサービス経由で連携していた」というケースが混在しがちで、退職時の棚卸しから漏れる典型ポイントになります。本記事では、悪意の有無を問わずアクセス権が残っていること自体が点検価値の高い構造的論点である、という立場で整理していきます。
AI ツールの退職者リスクは「3 層」あります
退職者アカウントの問題は、「Slack を消す」「メールを消す」と一言で済むものではありません。AI ツールに関しては、少なくとも次の 3 層に分けて棚卸しする必要があります。
第 1 層：法人契約の SaaS 上の AI アカウント
事務所が法人契約しているサービス（大手プロバイダの法人向け AI アシスタント、AI 統合された業務スイートなど）上のアカウントです。SSO や管理者コンソールがあるため、原理的には一元管理しやすい層になります。ただし、管理者コンソールにログインして棚卸しする運用が定着していないと、有効なまま残り続けます。
第 2 層：個人契約・無料アカウントで業務利用していたもの
職員が「便利だから」と個人で契約していた汎用 AI チャットサービスなどのアカウントで、業務情報を入力していたケースです。事務所側に契約情報がないため、管理者がそもそも存在を把握していないことが多い層になります。退職後も本人のクレジットカードで継続課金され、過去の会話履歴（顧問先名・固有名詞を含む可能性あり）も本人の手元に残り続けます。
第 3 層：連携 API・OAuth トークン・サードパーティ連携
AI ツールからクラウドストレージ、共有ノート、チャット、会計ソフトなどへの読み取り権限が、退職した職員のアカウント名義で発行されたままになっているケースです。本人の SSO アカウントを無効化しても、過去に発行された API キーやアクセストークンが別経路で生きていることがあります。
| 層 | 対象例 | 失効手段 | 事務所側の制御可否 |
|---|---|---|---|
| 第 1 層：法人契約 SaaS | 法人向け AI アシスタント / AI 統合業務スイート | 管理コンソール・SSO 無効化 | 即時に可能 |
| 第 2 層：個人契約・無料 | 汎用 AI チャットの個人プラン | 本人による履歴削除・解約に依存 | 強制できない（書面合意で予防） |
| 第 3 層：連携 API・OAuth | クラウドストレージ / 共有ノート / チャット / 会計ソフトのトークン | 各 SaaS 管理画面でのトークン取消 | SaaS ごとに個別作業が必要 |
第 1 層は管理コンソールで即時無効化できるのに対し、第 2 層は本人の協力なしに履歴削除を強制できず、第 3 層は接続元の SaaS 側まで遡らないと取り消せない、と構造が異なる点が論点になります。
AI 時代に特に重要な 3 つの理由
「退職時のアカウント整理」自体は AI 以前から存在する論点です。それでも AI ツールについて改めて取り上げる理由は、3 点あります。
第一に、学習・履歴の問題です。個人情報保護委員会は生成 AI サービスの利用に関する注意喚起のなかで、個人情報取扱事業者が本人の同意を得ないまま生成 AI サービスに個人データを含むプロンプトを入力し、応答結果の出力以外の目的で取り扱われた場合に、個人情報保護法の規定に違反することとなる可能性があると指摘しています。提供事業者が個人データを機械学習に利用しないことなどを十分に確認するよう求められている点も、公式情報を確認しておきたいところです。退職者の個人アカウントに顧問先情報を含む会話履歴が残っている場合、事務所はその履歴を制御できません。AI 以前のメール削除よりも難度が一段上がります。
第二に、連携の問題です。AI ツールは単体で完結しなくなりました。クラウドストレージを読み込ませる、チャットツールに連携する、会計ソフトと API でつなぐ、といった構成が一般化しており、退職者のアカウントが連携元として登録されたままだと、退職後も AI 経由で情報にアクセスできる経路が残ります。
第三に、顧問先データの問題です。士業事務所のデータには、顧問先・依頼者の個人情報が含まれることが前提になります。退職者がアクセスできる状態を放置することは、悪意の有無を問わず、守秘義務上の論点として残り続けます。
漏れやすい 5 箇所
オフボーディングのチェック項目を作るときに、現場で実際に漏れやすい場所を 5 つ挙げます。
- 顧問先が契約している SaaS への招待状態: 顧問先の会計ソフト、勤怠管理 SaaS、契約管理ツールなどに、職員個人のアドレスでゲスト招待されているケースです。事務所の SSO 配下にないため、退職時の自動失効が効きません
- 共有ノート・社内 Wiki の閲覧権限: プロンプト集、業務ノウハウ、顧客対応マニュアルなどが置かれているケースで、ページ単位の権限が個人アカウントに紐づいています
- チャットの DM・プライベートチャンネルに残った機密情報: DM 内に貼られた顧問先資料、プロンプトのコピペ、API キーなどが該当します。本人のアカウントを無効化しても、メッセージは消えません（必要なら別途エクスポートと削除が要ります）
- 個人アカウントで作った汎用 AI チャットの会話履歴: 業務で使っていたかどうかを本人申告ベースで確認するしかなく、申告漏れがあると追跡不能になります
- 個人で発行した API キー・Personal Access Token: コード管理サービス、AI プロバイダ API、チャットアプリ、クラウドプラットフォームなどで職員個人が発行したトークンが、自動化スクリプトや個人 PC のローカル開発環境に残っているケースです
これらは、メイン業務システム（メール・給与・顧問先管理）を見るだけでは検知できません。「退職者から AI 関連の利用状況を一覧で聞き取る運用」を入れるか、そもそも「個人アカウントでの業務利用を禁止して法人プランに一本化する運用」を入れるか、いずれかの予防策が要ります。
オフボーディング 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 ツール利用ログを、退職後に参照可能な形でエクスポート・保管します。事後に「あの時何を入力したか」を確認できる体制があると、顧問先から問い合わせを受けたときに応答可能性が高まります。
チェックリスト
退職が確定したら、最終出社日までに次の項目を確認します。
- 退職者が業務で使っていた AI ツールの一覧（法人・個人・無料を含む）をヒアリング済み
- 法人契約サービスのアカウントを SSO/管理コンソール側で無効化する手順が確定している
- 退職者名義で発行された API キー・OAuth 連携・Personal Access Token を洗い出した
- 共有ドキュメント・チャットチャンネルの権限を引き継ぎ済み（または削除済み）
- 個人アカウントの業務利用履歴について、削除・取り扱いを書面で合意した
- 退職前 3 か月の AI 利用ログをエクスポート・保管した
- 顧問先側で職員個人のアドレスを招待していないか確認した
観測仮説
ここまでの整理から、現場で観察される現象について、いくつか仮説的な見立てを置いておきたいと思います。あくまで観測ベースの仮説であり、所の規模・扱う案件・既存システム構成によって当てはまり方は変わってくると考えられます。
- 第 2 層（個人契約）の漏れが最大の論点になっている事務所が多いと見ています。第 1 層は SSO で機械的に止められますが、第 2 層は本人の協力に依存します。入社時規程で個人アカウントの業務利用を禁止しておかないと、退職時に手詰まりになります
- 第 3 層（OAuth・連携トークン）の存在自体が把握されていない事務所が大半と見ています。連携を作った本人すら、どの SaaS にトークンを渡したか覚えていないケースが観察されます。SaaS 側の「接続済みアプリ」一覧を四半期に 1 回点検する運用が、現実的な対策になり得ます
- 「退職処理の手順書」に AI 項目が独立していない事務所が多いと考えられます。多くの手順書は「メール停止」「給与停止」「カードキー回収」の延長で書かれており、AI ツールは「その他」扱いになりがちです。AI ツールを独立項目として 3 層に分けて書くだけで、漏れが大きく減ると見ています
- 顧問先側で職員個人のアドレスを招待しているケースは、所が思っている以上に多いと考えられます。顧問先 SaaS への招待は、事務所の SSO 配下にないため、退職時の自動失効が効きません。退職時に顧問先に通知して招待を取り消してもらう運用を、退職フローに 1 行追加するだけで状況が改善する事例が観察されます
退職処理の手順書に「AI ツールの 3 層棚卸し」を 1 行追加するところから始めれば、シャドー AI の温度感が見えてくる、というのが現時点での見立てです。
参考
- 個人情報保護委員会「生成 AI サービスの利用に関する注意喚起等」（令和 5 年 6 月 2 日） https://www.ppc.go.jp/news/careful_information/230602_AI_utilize_alert/
- 経済産業省・総務省「AI 事業者ガイドライン」 https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/
- 大手プロバイダによる法人向け AI アシスタントの提供形態については、各社の公式情報を確認のこと