SaaSの棚卸しは、たいてい「まず全SaaSの一覧を作ろう」から始まります。それ自体は間違いではありません。問題は、完璧な一覧を作り終えてから棚卸しを始めようとすると、一覧作成の段階で止まることです。

この記事では、複数の事業会社で見てきた実態をもとに、一覧を「作ってから」ではなく「育てながら」回すやり方を書きます。鍵になるのは、退職処理です。

棚卸しをしようと決めた朝に、何が起きているか

まず、管理台帳がスプレッドシートです。手作業で更新されていて、更新が止まった日付が、そのまま最終更新日として残っています。

その台帳を開いて退職者の行を追うと、半年前、1年以上前に退職した人のアカウントが、複数のSaaSに残っていることが分かります。1つではありません。複数です。

社内で使われているSaaSは50を超えています。そしてそれぞれの管理者がバラバラです。営業部門が契約したもの、開発チームが入れたもの、管理部門が入れたもの。誰が管理者かを調べるだけで午前が終わります。

さらに、そもそも把握できていないSaaSがあります。個人カードで契約して経費精算されているもの、無料プランのまま使われているもの。台帳に載っていないので、棚卸しの対象にすらなりません。

退職者アカウントの中には、まだ使われているものがあります。権限移譲がうまくいかず、「あのアカウントでないと管理画面に入れない」という理由で、退職者のIDでログインし続けている。認証情報も変えていません。誰のものでもない共通アカウントも残っています。

そして、アクセスログを保管していません。「そのアカウントが最近使われたか」を確認する手段がないのです。

なぜ消えないのか

担当者が怠慢だからではありません。消えない構造になっているからです。

1. ルールはあるが、仕組みになっていない。 退職時にアカウントを停止するルールは存在します。問題は、実行が人の記憶に載っていることです。担当者が思い出したSaaSから停止し、思い出さなかったSaaSは残る。そして「思い出さなかった」という事実は、どこにも記録されません。

2. 権限移譲が終わっていない。 退職者のアカウントが唯一の管理者権限を持っている場合、消すとそのSaaSに入れなくなります。だから消せない。後回しになった瞬間、そのアカウントは「使い続けるアカウント」に変わります。

3. 共通アカウントには所有者がいない。 誰のものでもないので、退職者が抜けても棚卸しの対象になりません。パスワードを変えると誰かの業務が止まるかもしれない。だから触れないまま残ります。

3つとも、個人の注意力では解けません。仕組みの問題なので、仕組みで解きます。

実務の再設計：「完璧な一覧」をゴールにしない

やることは2つだけです。(A) 粗い一覧を短時間で作る。(B) その一覧を、退職処理のたびに育てる。

A. 粗い一覧は、4つの情報源から1日で作る

完璧を目指さないでください。今ある情報から機械的に作ります。

IdP / SSOの連携アプリ一覧——SSOを一部でも導入していれば、連携済みアプリが並んでいます。ここに出るのは「管理されている側」のSaaSです
請求情報・法人カードの継続課金——毎月同じ金額が同じ相手に落ちていれば、それはSaaSです。契約が生きている証拠として、記憶より正確です
経費精算データ——個人カード契約のSaaSはここにしか現れません。摘要欄をサービス名で横断検索します
請求書・領収書メールの検索——経理の共有メールボックスで「ご請求」「お支払い」を検索すると、上の3つで漏れたものが出てきます

この時点の一覧は穴だらけで構いません。「穴があることが分かっている一覧」は、「作りかけで止まった完璧な一覧」より役に立ちます。

B. 退職処理を、一覧の「穴検知」の仕組みに変える

ここが本題です。退職者が出るたびに、次の手順を回します。退職処理そのものが、一覧の穴を1つずつ塞ぐ計測点になります。

手順1：その人の足跡を逆引きする。 退職者のメールアドレスは必ず分かります。メールボックスで招待メール・請求メール・パスワードリセットのメールを検索すると、その人がアカウントを持っていたSaaSが出てきます。一覧に無いSaaSがここで見つかったら、それが「穴」です。一覧に足します。（退職者のメールボックスを一定期間保持する運用が、この手順の前提条件です）

手順2：消す前に、入れなくする。 削除から始めないでください。先にやるのは認証を止めることです——IdP側で無効化（SSO連携済みは一斉に止まる）→メールアドレスの無効化（リセット経由の復活を塞ぐ）→SSO未対応のSaaSは個別にパスワード変更。削除を先にすると「そのアカウントで何をしていたか」が後から確認できなくなります。無効化なら残ります。

手順3：権限を移してから、削除する。 そのアカウントが唯一の管理者になっていないかを確認し、なっていれば先に別の管理者を追加する。この順序を守ると、「消せないから残す」がなくなります。

手順4：共通アカウントは、所有者を決める。 退職者が使っていた共通アカウントが見つかったら、消すより先に「所有者を1人決める」。所有者が決まれば、次の退職時に誰がパスワードを変えるかが決まります。

手順5：1行だけ記録する。 誰が・いつ・どのSaaSで・何をしたか。台帳を作り込む必要はありません。作り込んだ台帳は更新されなくなりますが、1行なら続きます。

手順6：ログの保管設定を、ついでに入れる。 手順2〜3でSaaSの管理画面を開いています。多くのSaaSは監査ログの保管期間を設定できます。管理画面を開いている今が、その設定に触る一番良いタイミングです。

この設計のいいところ

一覧作成が「終わらない大仕事」から「1日の初期作業＋退職のたびの差分更新」に変わります。退職者1人の逆引きはその人の足跡しか照らしませんが、退職のたびに繰り返すことで、部署もロールも違う足跡が積み重なり、一覧の穴が多方向から塞がっていきます。棚卸しは年1回のイベントではなく、退職処理に埋め込まれた日常の運用になります。

「IDaaSはまた面倒なものが増える」という受け止めについて

ここまで読むと、SSO未対応のSaaSへの個別対応が一番重い工程だと分かると思います。

統合ID管理（IDaaS・SSO）の話をすると、「また管理するものが増える」という反応が返ってくることが多いです。気持ちは分かります。導入プロジェクトが立ち、設定作業が発生し、社内説明が必要になる。増えるように見えます。

ただ、実際に入った後の現場を見ると、認識が変わっていることが多いです。入口が1つになるので、退職処理の手順2がSSO連携済みのSaaSについては1操作で終わります。入社時も同じです。利用者側は覚えるパスワードが減り、リセット依頼が減り、多要素認証を入口で一律にかけられます。

増えるのは管理対象ではなく、管理の「まとまり」のほうです。分散していたものを畳む話だと捉え直すと、見え方が変わります。もちろん全SaaSがSSO対応ではないので、未対応分は上の手順で個別に回すしかありません。ただ、個別対応が必要な範囲が確定するだけでも、見通しは大きく変わります。

まとめ

一覧は「作ってから」ではなく「育てながら」。 粗い一覧を4つの情報源から1日で作る
退職処理を、一覧の穴検知の仕組みに変える。 逆引き→無効化→権限移譲→所有者決め→1行記録→ログ設定
消す前に入れなくする。 削除を先にすると履歴も消える
記録は1行でいい。 作り込んだ台帳は更新されなくなる

私はいま、こうしたIT統制の現在地をNIST CSF 2.0 / ITGCの観点で数値化するサービス（SecuROI）を作っています。今どこまでできていて、次にどこから手を付けるか——順序が決まっていれば動き出せる、という考え方でやっています。