入退社でSaaSアカウントを取りこぼさない手順：オンボーディングとオフボーディングを台帳で回す(2026)

入社した人のアカウントが初日に揃わない。退職した人のアカウントが、ログインできる状態のまま残っている——使うSaaSの本数が増えるほど、どちらも起こりやすくなります。この記事は、入社・退職にひもづくSaaSアカウントの手順(オンボーディング／オフボーディング)を、取りこぼさない形で回す方法を解説します。対象は、情シス専任がいない、あるいは兼任で回している中小〜中堅企業の管理部門・情シス・人事の方です。

本記事は業務手順の一般的な解説です。法令の解釈を確定させるものではなく、個別の適法性の判断は自社の規程および弁護士等の専門家にご確認ください。各SaaSの仕様・保持期間は変更されるため、実施前に必ず各公式でご確認ください。

最終更新: 2026年9月1日／本文で参照した公式資料・ガイドラインは同日に原文で確認しています。データの削除・移行を伴う操作は取り返しがつかない場合があります。必ず検証してから本番で実施してください。

なぜ入退社のアカウント管理は漏れるのか

アカウントの取りこぼしは、能力や意欲の問題ではなく情報が一箇所に集まっていないことから起きます。典型的にはこうです。

• 人事はSaaSの一覧を持っていない: 退職の連絡は人事から総務へ回りますが、「この人がどのツールに、どの権限で入っているか」は人事の管理範囲外です。
• 管理者が製品ごとにバラバラ: チャットは情シス、デザインツールは制作部、会計ツールは経理——それぞれの管理者が「自分のところは大丈夫」と思っている状態は、全体では穴だらけです。
• 準備期間が短い: 民法第627条第1項は「当事者が雇用の期間を定めなかったときは、各当事者は、いつでも解約の申入れをすることができる。この場合において、雇用は、解約の申入れの日から二週間を経過することによって終了する」と定めています。制度上、申し出から2週間で雇用が終わりうるということです(就業規則でより長い予告期間を定めている会社もあります)。手順が文書化されていないと、その場の判断で処理され、抜けが出ます。

放置したときのリスクは、コストとセキュリティの両面に出ます。コスト側の試算(数値は例)としては、1席2,000円のツール4本に退職者3名分の席が残っていれば、2,000円×4本×3名×12か月=年28.8万円が何も生まないまま出ていきます。ただし本当の問題は金額ではありません。

セキュリティ側では、独立行政法人情報処理推進機構(IPA)が「組織における内部不正防止ガイドライン」第5版(2022年4月6日公開／最終更新2025年5月19日)の「(5)情報システムにおける利用者のアクセス管理」で、「②また、異動又は退職により不要となった利用者 ID 及びアクセス権は、ただちに削除しなければならない」と定めています。同ガイドラインは、削除されずに残ったIDについて「役職員及び元役職員によって不正に利用されて、重要情報にアクセスされる恐れがあります」と述べ、さらに「これらの管理ができていないと、不正を犯した役職員及び元役職員の責任を追及できないことがあります。また、企業や団体の管理責任を問われることもあります」としています。残ったアカウントは、退職者を疑う話である以前に、自社が説明責任を果たせなくなる状態を作ります。

土台：SaaS台帳を1枚作る

すでにSaaSの棚卸し表(契約・料金の一覧)を作っている場合は、そこに「人」の列を足すのが早道です。契約の一覧が無い状態なら、まずSaaSの棚卸しでムダな出費を減らす手順で契約側を洗い出してから、この記事の台帳に進んでください。

行は「人 × ツール」の組み合わせで1行にします(1人が5本使っていれば5行)。こうしておくと、在籍者名簿との突き合わせがそのままできます。契約や料金の一覧は別に1枚持ち、この台帳とツール名で紐づけてください。「データの持ち主になるか」以降の列が、単なる契約一覧との違いです。「その人が消えると何が壊れるか」「いつまでに何をしないと取り返しがつかないか」を先に把握するための列で、退職処理の事故を防ぎます。共同編集するならAirtableのようなデータベース型も便利です。

台帳を作る作業自体を重くしないでください。全ツールを一度に埋めようとせず、人が多く紐づく上位5〜10本から始めます。IPAのガイドラインも、対策のポイントとして「利用者 ID 及びアクセス権の登録・変更・削除の手続きに漏れがないように、人事異動に関連する人事手続き等と連携した運用とします」と述べており、狙うべきは網羅性より人事の手続きと連動していることです。

オンボーディング：役割で束ねて、初日に揃える

入社時の失敗は2種類あります。足りない(初日に仕事が始められない)と、多すぎる(前任者と同じ権限を丸ごとコピーして、必要のない情報まで見える)です。後者は目に見えないまま蓄積し、退職時のリスクになります。

解決策は役割(ロール)ベースの初期セットです。個人ごとに考えるのをやめ、役割名で束ねます。IPAのガイドラインも脚注で「個人ではなく、職務(役割)に対してアクセス権限を割り当てる『ロールベースアクセス制御』に対応したアクセス制御システムを導入することも考えられます」と述べています。仕組みとして導入しなくても、考え方だけ借りて表計算で運用することはできます。

最終行がポイントです。業務委託・派遣の方は「社員と同じ初期セット」にしないでください。契約期間が決まっているので、ツールがアカウントの有効期限設定に対応していれば、付与の時点で期限を入れておきます。ただし、標準プランでは有効期限を設定できない製品も少なくありません。設定できない場合を前提に、台帳の「契約終了日」列にその日付を書き、当日と1週間前にカレンダー通知を立てておくのが確実です。自動で切れることを当てにしないでください。

運用面では、次の3点を決めておくと安定します。まず付与の起点は必ず人事の入社連絡にすること。現場からの直接依頼で発行すると台帳に載りません。次に管理者権限は初期セットに入れないこと。必要になったら申請で足します。最後に付与した内容を台帳に反映してから完了とすること。反映を後回しにすると、台帳が実態と乖離していきます。

オフボーディング：急ぐのは削除でなく遮断

ここが本記事の核心です。「アカウントを削除する」と「アクセスを止める」は別の操作で、急いでやるべきは後者です。企業向けの主要サービスには、削除後にデータを取り戻せる期間が定められているものがあり、そこを過ぎると復元できません。下記のとおりMicrosoft 365とGoogle Workspaceはいずれも期間を公表していますが、期間の長さも、戻るデータの範囲も同じではありません。そして、猶予そのものが無い製品もあります。「どの製品でも数十日は戻せる」と考えて削除するのが、いちばん危険です。

実際の期間は製品によって異なります。公式ドキュメントに明記されている例を挙げます。

出典は本文末に記載した各社公式ドキュメント(2026年9月1日確認)。保持期間・条件は変更されることがあり、契約プランやテナント設定でも挙動が変わります。自社の環境で必ず公式ドキュメントを確認し、可能なら本番前に検証してください。

なお、退職時に何をすべきかの規範自体は明確です。IPAのガイドラインは「(24)雇用終了及び契約終了による情報資産等の返却」で、「役職員の雇用終了時及び請負等の契約先との契約終了時に、取り扱いを委託した情報資産の全てを返却又は完全消去させなければならない。また、雇用者や契約先に与えていた情報システムの利用者 ID や権限を削除しなければならない」と定めています。問題は「やるかどうか」ではなく「どの順でやるか」です。

この違いを踏まえた標準手順が、次の4ステップです。

1. サインインを止める(最終出社日当日): パスワードのリセット、サインインのブロック、本人が登録した認証方法(認証アプリ・電話番号など)の削除、そして全端末のサインインセッションの失効。削除ではなく遮断です。とくに最後のセッション失効を忘れないでください。パスワードを変えても、すでにログイン済みの端末やアプリはしばらく使えてしまうことがあります。Microsoftは退職者対応の手順を7ステップで示し、その第1ステップを「元従業員が組織のMicrosoft 365サービスにサインインできないようにする」としています。スマートフォンやタブレットに会社のデータが残る場合は、同じく第3ステップに挙げられているモバイル端末のワイプとブロック(会社データの削除)もあわせて検討します。
2. データを移す(数日〜2週間): メール・ファイル・カレンダー・案件の所有権を後任へ移管します。Google Workspaceの管理者ヘルプも、ユーザーを削除する前にメール・ドライブのファイル・カレンダーを他のユーザーへ移行するよう案内しています。移管先が決まっていない場合は、一時停止(サスペンド)やアーカイブの選択肢を検討します。
3. 権限を消す(移管完了後): 台帳に載っている全ツールのアカウント・権限を削除します。IPAのガイドラインは「(24)雇用終了及び契約終了による情報資産等の返却」の対策のポイントとして、「情報システムから元役職員の利用者 ID や権限が削除されたことを確認することが必要です。これには、テレワークを行うために元役職員に付与した権限も含みます。利用者 ID や権限の削除は、雇用終了直後に速やかに実施することが肝要です」と述べています。
4. 記録する: いつ、どのツールを、誰が処理したかを台帳に残します。これは事務作業ではなく、後から「管理できていた」と説明するための証跡です。

なお削除にあたっては、ログの保全に注意が必要です。IPAのガイドラインは、前述の「ただちに削除しなければならない」に脚注を付し、「利用者 ID を消去したときにアクセス記録などが消去されるような場合には、利用者 ID をロックしてアクセス出来ないような状態としてログを保全することが必要となります」としています。つまり「ただちに削除」は無条件ではなく、ログが消える設計の製品では”ロックして残す”が正解ということです。この一文を読み飛ばして機械的に削除すると、あとで調査ができなくなります。

手作業を減らす：ログインを1か所にまとめる

ここまでの手順は「各SaaSの管理画面を順に開いて止める」前提でした。本数が増えるほど、この作業は現実的でなくなります。そこで検討したいのがログインの入口をまとめる方法です。

すでにMicrosoft 365やGoogle Workspaceのアカウントを全社員に配っている会社であれば、この既存アカウントを各SaaSのログインにも使う構成(シングルサインオン、以下SSO)を取れる場合があります。対応する製品でこの構成にできれば、退職時は元のアカウントを止めるだけで、そこ経由でログインする各SaaSにも入れなくなります。遮断の工程が1本にまとまるわけです。

ただし、次の4点は必ず理解したうえで採用してください。SSOを入れても台帳が不要になるわけではありません。

• 対応可否とプラン条件が製品ごとに違う: SSOを上位プランでのみ提供する製品もあります。対応状況と必要なプランは製品ごとに異なるため、導入前に各SaaSの公式ページで必ず確認してください。
• すでにログイン済みのセッションは別途止める必要がある: 入口を閉じても、各SaaS側でログイン状態が続くことがあります。前章の「全端末のサインインセッションの失効」は、SSOにしても省けません。
• SSOを通らないアカウントが残ると迂回される: そのSaaSに直接パスワードで入れるアカウントが残っていれば、入口を閉じても素通りです。SSO化と同時に、個別パスワードのアカウントを整理する必要があります。
• データの所有権・外部共有・APIトークンは解決しない: SSOが解くのは「ログインできるかどうか」だけです。ファイルの所有者移管も、共有リンクの棚卸しも、連携の付け替えも、引き続き必要です。

それでも、この記事の冒頭で挙げた3つの原因のうち「管理者が製品ごとにバラバラ」「準備期間が短い」の2つには、直接効きます。台帳を作りながら、SSOに寄せられるツールがどれかを並行して確認しておくと、次の退職処理から負担が変わります。

取りこぼしが起きる5か所

台帳に載っているツールを処理しても、次の5か所は台帳の外側にあるため、意識して探さないと残ります。

• 個人名義で契約されたツール: 本人の個人カードやメールアドレスで契約され、経費精算だけが会社に上がっているケース。本人が退職すると、会社は解約も引き継ぎもできず、データにも触れられません。発見の手がかりは経費精算の履歴です。
• 期限なしの外部共有リンク: 本人のアカウントを消しても、その人が発行した「リンクを知っている全員が閲覧可」のURLは生き続けることがあります。アカウントを削除してもリンクが失効しない製品があるため、共有設定側での棚卸しが別途必要です(削除時に失効する製品もあるので、自社が使う製品の挙動を確認してください)。
• APIトークン・連携アプリ: 本人のアカウントで作った自動連携が動いている場合、削除すると業務が止まります。逆に、本人名義のトークンを残せば、退職後も動き続ける自動処理が残ります。どちらも危険なので、退職前に共用アカウントへ付け替えます。
• 業務委託・派遣・インターン: 人事の退職手続きに乗らないため、契約終了が総務に伝わりません。IPAのガイドラインは、アクセス管理の対策のポイントとして「特に、委託先の従業員等に権限を付与する場合は、(１７)で示す契約上の措置が必要です」と述べています。その(17)「業務委託時の確認(第三者が提供するサービス利用時を含む)」が定める対策の指針は「委託する業務内容と重要情報の重要度に応じて、セキュリティ対策を事前に確認・合意してから契約し、委託先が契約通りに情報セキュリティ対策を実施しているか定期的及び不定期に確認しなければならない」です。さらに脚注では、例示として「委託先の従業員の異動や退職によりアカウントの削除漏れ等が発生しないように、体制に変更が生じた場合は変更内容を委託元に報告する等が挙げられます」と述べています。つまり求められているのは契約上の措置で、報告の取り決めはその具体例の一つという関係です。契約書と発注管理から拾う導線を作ってください。
• 私物端末に残ったアクセス: 私物のスマートフォンにメールアプリやチャットが入ったままの状態。サーバー側でサインインを止めても、端末に保存済みのデータは残ります。会社が貸与した端末は返却させ、私物端末は保存済みデータを削除したことの確認を書面で取るのが、端末管理を入れていない会社の現実解です。Microsoftの手順の第3ステップにあるモバイル端末のワイプを私物端末に対して行う場合は、本人の同意やBYOD(私物端末の業務利用)に関する社内規程が前提になります。

1点目の個人名義契約は、退職時にもっとも打つ手が無くなるパターンです。予防策は、入社時のオンボーディングで「業務で使うツールは必ず会社名義・会社ドメインで契約する」と伝え、既存分は棚卸しで見つけて名義変更しておくことに尽きます。退職の連絡を受けてから探し始めると、間に合いません。

また、社内で生成AIによる文書検索を使い始めている場合は、権限の緩さがより見えやすい形で表面化します。これまで共有ドライブの奥に埋もれていた文書が、質問一つで要約されて返るようになるためです。この論点は社内の「あの資料どこ?」をAIで減らす手順で詳しく扱っています。アカウントの棚卸しと権限の棚卸しは、同じタイミングでやると効率的です。

仕組み化：手順書と定例点検に落とす

ここまでの手順を、担当者の頭の中ではなく3つの成果物に固定します。

1. 入社チェックリスト: 役割名を選ぶと初期セットが決まる形にする。承認者と付与担当を明記。
2. 退職チェックリスト: 前章の4ステップ＋取りこぼしやすい5か所を、そのまま項目にする。処理日と処理者の記入欄を付ける。
3. 四半期の突き合わせ: 各SaaSの利用者一覧を書き出し、人事の在籍者名簿と突き合わせる。差分が出たら、なぜ漏れたかを1行残す。

3点目の差分の記録を省かないでください。「Aツールだけ毎回漏れる」なら、そのツールが人事フローに載っていないということです。個別の消し忘れとして処理すると同じことが繰り返されますが、原因を1行残せば手順の穴として直せます。突き合わせ作業そのものの自動化は、中小企業のバックオフィス自動化で扱っている考え方が使えます。

次に取るべき行動

よくある質問(FAQ)

退職時、アカウントは削除と停止のどちらが正解ですか?

まず停止(サインインの遮断)、そのうえで移管が済んでから削除、が基本です。急ぐべきはアクセスを止めることで、削除を急ぐ理由はありません。むしろ削除を急ぐと、製品ごとの復元可能期間を過ぎてデータを失う恐れがあります。加えて、IPAの「組織における内部不正防止ガイドライン」は、利用者IDを消去するとアクセス記録なども消えてしまうような場合には、IDをロックしてアクセスできない状態にしログを保全することが必要だとしています。ログが消える設計のツールでは、削除せずロックが正解になります。自社の各ツールがどちらに当たるかを確認してください。

業務委託や派遣の方のアカウントも同じ手順でよいですか?

手順は同じですが、起点が違います。社員は人事の退職手続きが起点になりますが、業務委託・派遣は契約終了が人事フローに乗らないため、契約管理・発注管理から通知が来る導線を別に作る必要があります。アカウントの有効期限を設定できる製品なら、付与の時点で契約期間を入れておくのが確実です。ただし標準プランでは期限を設定できない製品も多いため、設定できない前提で台帳に契約終了日を記入し、その日付でカレンダー通知を立てるのが現実的です。IPAのガイドラインは、委託先の従業員等に権限を付与する場合には契約上の措置が必要だとしており、体制変更の報告を委託元に求めることを例として挙げています。委託契約そのものに書き込んでおくのが最も抜けにくい方法です。

退職した人が作った共有リンクや自動連携はどうなりますか?

アカウント削除では消えないことがあるため、別途の点検が必要です。「リンクを知っている全員が閲覧可」の共有URLは、発行者のアカウントが無くなっても有効なまま残る場合があります。ツール側の共有設定一覧から棚卸ししてください。自動連携やAPIトークンはさらに注意が必要で、本人名義のまま残せば退職後も処理が動き続け、削除すれば業務が止まります。退職が決まった時点で、本人名義の連携を洗い出し、共用アカウントや後任名義へ付け替えるのが安全です。

台帳を作る余裕がありません。最小限なら何から始めるべきですか?

退職チェックリスト1枚から始めてください。台帳が無くても、「顧客情報が入っているツール」「金銭を動かせるツール」「社外に共有できるツール」の3種類だけ列挙すれば、影響の大きい取りこぼしから手当てできます。次の退職者が出たときにそのリストで処理し、処理しながら「実はこれもあった」を書き足していけば、使える台帳に育ちます。最初から完璧な一覧を目指すと着手できないので、リスクの大きい順に育てるやり方が現実的です。

あわせて読みたい

出典・参考

• 独立行政法人情報処理推進機構(IPA)「組織における内部不正防止ガイドライン」第5版(2022年4月6日公開／最終更新2025年5月19日)より、「(5)情報システムにおける利用者のアクセス管理」の規範②・対策のポイント3および4・脚注38・脚注39・脚注40、「(17)業務委託時の確認(第三者が提供するサービス利用時を含む)」の規範、「(24)雇用終了及び契約終了による情報資産等の返却」の規範・対策のポイント3および5｜IPA(2026年9月1日にPDF原文で確認)
• 個人情報の保護に関する法律(平成15年法律第57号)第23条(安全管理措置)・第24条(従業者の監督)・第25条(委託先の監督)｜e-Gov法令検索(2026年9月1日にe-Gov法令APIで条文取得)
• 民法(明治29年法律第89号)第627条第1項(期間の定めのない雇用の解約の申入れ)｜e-Gov法令検索(2026年9月1日にe-Gov法令APIで条文取得)
• Microsoft「Remove a former employee – Overview」(ms.date 2026-06-15)｜Microsoft Learn(2026年9月1日確認)
• Google「Delete or remove a user from your organization」｜Google Workspace 管理者ヘルプ(2026年9月1日確認)
• 本記事は業務手順の一般的な解説であり、法令の解釈を確定させるものではありません。個別の適法性の判断は弁護士等の専門家にご確認ください。各製品の保持期間・仕様は変更されるため、実施前に各公式でご確認ください。

関連カテゴリ: SaaS活用 ／ SaaS

本記事に登場する製品名・ロゴは各社の商標または登録商標です。掲載の図解はjisalab編集部が作成したものです。英文の公式資料は編集部訳を併記しています。金額の例は説明用で、自社の実額に置き換えて判断してください。アカウントの削除・データ移行は取り返しがつかない場合があるため、必ず自社環境で確認のうえ実施してください。