退職したのに消えないアカウント——SaaS乱立時代の経営リスクとAIの解答

こんにちは、ひでです。

スタートアップを経営しながら、リサーチや資料作成、データ分析をAIに委譲して、自分は「判断」に集中する。そういう働き方をしています。

今日は、経営者がつい後回しにしがちな「SaaS ID管理」と「退職者アカウント」の話をします。

あなたも、こんな経験ありませんか。

自社で使っているSaaS、いくつあるか即答できますか?

そして、半年前に辞めたメンバーのアカウント、本当に全部消えていますか?

このふたつに「うっ」となった経営者は、たぶん多いはずです。僕も最初はそうでした。

でもこれ、情シスに任せておく裏方の話ではなく、れっきとした経営の話なんですよ。

この記事では、SaaS乱立がなぜ経営リスクになるのか、退職者アカウントの放置が何を引き起こすのか、そして2026年5月にSmartHRが出した新機能「ブラウザ自動操作」がなぜその突破口になりうるのかを、経営判断の目線で整理します。

読み終わったとき、自社で今日打てる最初の一手まで見えるようにします。

SaaS乱立が仕掛けるID管理の穴——経営ガバナンスへのトラップ

「自社のSaaS、何個ありますか?」に即答できる経営者は少ない

まず数字から。

SmartHRが情報システム部門を対象に実施した「SaaSアカウント管理」の実態調査（2025年6月公表）によると、従業員500名以上の企業が管理しているSaaSは平均16.8個でした。

16.8個。多いと思いますか、少ないと思いますか。

僕の感覚だと、現場で実際に使われているツールはもっと多い気がします。

会計、勤怠、チャット、タスク管理、デザイン、CRM、分析ツール。部署ごとに「これ便利だから使おう」と契約していくと、経営者が把握しないまま数だけ増えていきます。

問題は数そのものじゃありません。

ツールが増えるほど「誰が・どのサービスに・どんなアカウントを持っているか」が見えなくなる、という構造です。

便利だから増やす。増やすから見えなくなる。見えなくなるから、誰も全体像を答えられない。これがSaaS乱立の正体です。

いわば、蛇口を次々と増やしているのに、水道管の全体図は誰も持っていない状態です。

63%が退職者・異動者アカウントを管理しきれていない現実

ここからが本題です。

同じSmartHRの調査では、63.9%の情シス担当者が「退職者や異動後のSaaSアカウントを適切に管理できていない」と回答しています。

さらに60.2%が「現在利用しているSaaSに未使用アカウントがある」とも答えています。

つまり、6割を超える企業で、使われていないアカウント、消されるべきアカウントが、消えないまま残っているわけです。

「あるある」で片付けたくなる気持ち、わかります。

でも経営者の目で見ると、これは「ツールを増やすスピードに、管理する仕組みが追いついていない」という、かなり不健全な状態なんですよ。

差分がずっと放置されている。それが今の多くの組織の現実です。

これは「情シスの問題」ではなく「経営者の不作為リスク」

ここで多くの経営者が、無意識にこう考えます。「アカウント管理は情シスの仕事だよね」と。

気持ちはわかります。長いあいだ、ID管理は情シス部門の裏方業務とされてきました。経営会議の議題にはまず上がりません。

でも、SaaS時代にはこの前提が崩れています。

管理されないアカウントは、そのまま経営ガバナンスの穴になるからです。

考えてみてください。情報漏洩が起きたとき、不正アクセスで顧客データが流出したとき、最終的に頭を下げて責任を問われるのは誰か。情シスの担当者ではありません。会社の代表です。

「知らなかった」「現場に任せていた」は、経営の世界では免罪符になりません。むしろ「把握する仕組みを作らなかった不作為」として問われます。

だからこれは情シスの問題ではなく、経営者が旗を立てるべき問題なんです。

次のセクションで、「放置するとどうなるか」をコスト視点で見ておきましょう。

退職者アカウント残存が招く情報漏洩——「業務の抜け漏れ」ではなく経営リスクの本質

ゴーストアカウントが生む3つのリスク

退職者のアカウントが残ったままになっている状態。いわゆる「ゴーストアカウント」「幽霊アカウント」と呼ばれるやつです。

「ちょっとした業務の抜け漏れ」と捉えているうちは、リスクの本質が見えていません。

経営者として認識すべきリスクは、大きく3つあります。

• 不正アクセスのリスク: 退職者のIDとパスワードが生きていれば、本人はもちろん、その認証情報が漏れた第三者も、社内のSaaSにアクセスできてしまいます。顧客リスト、売上データ、未公開の事業情報。アクセス権が消えていないだけで、これらが外から見える状態になります。
• 内部不正のリスク: 円満な退職ばかりではありません。アクセス権を持ったまま辞めた人が、後から情報を持ち出すケースは現実に起こりえます。残っているアカウントは、内部不正の入り口になります。
• 監査対応のリスク: 内部統制の監査や、取引先からのセキュリティチェックで「退職者のアカウントが残っています」という指摘が入ると、それだけで管理体制への信頼が揺らぎます。資金調達やエンタープライズ取引の場面では、ここが見られます。

経営者の目で「いくらの損害になりうるか」を考える

僕はAI導入でも何でも、判断するときは必ず数字に直して考えます。リスクも同じです。

退職者アカウント1つの消し忘れを、コストに換算してみてください。

情報漏洩が起きれば、調査費用、顧客対応、場合によっては損害賠償。それ以上に痛いのは、信用の毀損です。

一度「あの会社は管理がずさんだ」と思われると、失注や取引停止につながります。スタートアップにとって、信用は時価総額に直結します。

退職者がアクセス権を持ったまま情報を持ち出す事案は、実際に報じられています。これは特別な大企業だけの話ではありません。アカウントを消す仕組みがない組織なら、規模を問わず起こりうることです。

「アカウントを1つ消し忘れた」が、「会社の信用と、代表者としての責任に跳ね返る」。この距離感を、経営者は短く見積もるべきです。

地味な作業に見えて、これは立派なリスク管理なんですよ。

では、なぜこれがずっと解決されなかったのか。構造的な理由があります。ここが面白いところで、突破口も見えてきます。

「APIの壁」という見えない障壁——なぜアカウント管理の自動化が進まなかったのか

自動化したくてもできない——API非対応サービスという構造的な壁

ここまで読んで、こう思った人もいるはずです。「だったら、人事システムと連携させて、退職したら自動でアカウントを消せばいいじゃないか」と。

正しい発想です。実際、API連携に対応しているSaaSなら、人事データと接続して、入社・退職に合わせてアカウントを自動で作成・削除する仕組みが作れます。

問題は、すべてのサービスがAPIに対応しているわけではない、という点です。

世の中には、API連携の口を持たないサービスがまだたくさんあります。古くから使っている業務システム、自社で開発した社内ツール、オンプレミスで動いているシステム。これらは「画面はあるけど、外部から自動で操作する入り口がない」状態です。

すると何が起きるか。

API対応サービスは自動化できる。でも、API非対応のサービスだけは、連携の輪から取り残される。ここだけ手作業が残り続ける、という構造的な壁ができます。

いわば、高速道路でつながった幹線網なのに、最後の1kmだけ砂利道が残っている感じです。そこだけ人が歩くしかない。

CSV手作業と月次棚卸しが生む「更新タイムラグ」

API非対応のサービスを管理する現場は、どうしているか。

多くは、各サービスからアカウント一覧をCSVでエクスポートして、手作業で突き合わせて、月に一度くらいの頻度でまとめて棚卸しする、という運用です。

SmartHRの調査でも、SaaSアカウント管理の課題として「各SaaSごとに個別管理が必要で手間がかかる」が47.2%で最多に挙がっていました。

この運用には、ふたつの弱点があります。

ひとつは、情シスの工数を食うこと。サービスの数だけCSVを開いて、目で確認して、という作業が積み上がります。

もうひとつ、もっと深刻なのが「更新タイムラグ」です。

月次でしか棚卸ししないということは、月初に辞めた人のアカウントが、最悪、翌月末まで生き続けるということです。退職してから削除まで、数週間の空白が生まれます。

その数週間、リスクは開きっぱなしです。

ここがずっと放置されてきた領域なんですよ。そして、ここに手が届くようになったのが、次の話です。いよいよ本題です。

AIがブラウザを「読んで操作する」——SmartHRの新機能が示す転換点

SmartHR「ブラウザ自動操作」とは何か——3つの特長

2026年5月11日、SmartHRが「ブラウザ自動操作」という機能の提供を開始しました。

ざっくり言うと、API非対応のWebサービスから、AIがブラウザ経由でアカウント情報を自動取得して、SmartHRの「ID管理」機能に反映する、というものです。

さっき話した「APIの壁」に、正面から手を伸ばした機能です。

特長は大きく3つあります。

• 幅広いサービスに対応: ブラウザ上でアカウント一覧画面を表示できるWebサービスであれば、SaaSでも、オンプレミスでも、自社開発システムでも対象になります。「APIがあるかどうか」ではなく「画面が表示できるかどうか」が条件になった、という点が大きい。
• AIによる初期設定の自動化: AIがアカウント一覧画面の構造（HTMLやDOM）を自動で解析して、必要な項目を自動で特定・提案します。従来は、管理者が「この列が氏名、この列がメールアドレス」と一つずつ指定する必要がありました。その初期設定の手間を、AIが肩代わりします。
• 従業員データとの自動照合: 取得したアカウント情報を、SmartHR上の従業員データベースと自動で照合します。その結果、「作成が必要なアカウント」「削除が必要なアカウント」が可視化されます。差分が、目で見える状態になります。

つまり、「どのSaaSに誰が残っているか」が、手を動かさなくても常に見える状態になる、ということです。これが今まで不可能だったことを、改めて考えてほしいんですよ。

RPAとの本質的な違い——「手順のプログラム」から「画面の意味理解」へ

ここがこの記事のいちばん面白いところなので、少し丁寧に話します。

「ブラウザを自動で操作する」と聞くと、RPAを思い浮かべる人が多いと思います。たしかに、画面を操作するという点では似ています。

でも、中身は本質的に違います。

RPAは、いわば「手順のプログラム化」です。人間が「この画面のここをクリックして、次にここを開いて」と手順を全部教え込む。とくに従来型のRPAは、画面のレイアウトが少し変わっただけで動かなくなる。再設定が必要になる。融通が利かないんですよ。

一方、AIによるブラウザ操作は「画面の意味理解」です。

AIが画面を見て、「これはアカウント一覧の画面だな」「この列は氏名っぽいな」と、構造そのものを解釈する。手順を丸暗記しているのではなく、画面の中身を理解している。

料理に例えるなら、RPAは「レシピを一字一句そのまま再現する人」、AIブラウザ操作は「冷蔵庫を開けて中身を見て、何が作れるか判断できる人」。後者のほうが、状況の変化に強い。

これ、経営者にとってけっこう大事な気づきだと思っていて。

「AIとは何か」を抽象論で理解しようとすると難しいんですが、この機能は「AIは画面の意味を理解できる」という性質を、いちばん身近な業務で体感させてくれます。AI活用の解像度を上げる、いい教材なんですよ。

最大90%削減の実績と、現時点での機能の射程

実績の話もしておきます。

飲食店を展開する「かぶらやグループ」がこの機能を導入したところ、1サービスあたりの作業時間が、従来の最大10分から最短1分に短縮されたそうです。

SmartHRは「最大90%の業務効率化に成功」と発表しています。

更新の頻度を上げられるようになったことで、退職者アカウントの削除漏れを防ぐ効果もあった、とされています。

ただ、ここはAI万能論にしたくないので、機能の射程も正直に書きます。

現時点で「ブラウザ自動操作」が得意なのは、アカウント情報の「取得」と「可視化」です。「作成」や「削除」そのものを自動で行うには、まだAPI連携が必要です。

SmartHRは、今後API非対応サービスでの「作成・削除」の自動化も視野に入れて検討中、とアナウンスしていますが、今あるのは「見えるようにする」機能だと理解しておくのが正確です。

それでも、僕は十分に価値があると思います。

さっき話した「更新タイムラグ」の最大の原因は、現状把握に手間がかかりすぎることでした。そこが自動化されるだけで、棚卸しの頻度を上げられる。差分が見える状態を常時キープできる。リスクが開いている時間を短くできるんです。

もうひとつ、経営者として必ず押さえておくべき注意点があります。

この機能は外部サービスの画面にアクセスして情報を取得します。そのため、取得元の外部サービスが「自動取得を許可しているか」は、利用前に自社で確認する必要があります。SmartHR自身も、外部サービスの利用ルールを顧客側で事前確認するよう案内しています。便利だからと即導入するのではなく、ここは一段、慎重に進めてください。

機能の詳細は、SmartHRの公式発表を確認するのが確実です。

SmartHR、AIを活用しAPI非対応サービスのアカウント情報を取得・可視化する「ブラウザ自動操作」機能を提供｜SmartHR｜シェアNo.1のクラウド人事労務ソフト

　株式会社SmartHRは、クラウド人事労務ソフト「SmartHR」の「ID管理」機能において、AIが初期設定を支援し、API連携に対応していないWebサービスのアカウント情報をブラウザ上から自動で取得・反映できる「ブラウザ自動操作」機能を、5月11日より提供開始しました。

smarthr.jp

では、具体的にどう動けばいいか。経営者がすぐ着手できる3ステップで整理します。

経営者として何をすべきか——AI活用でアカウント管理の自動化に踏み出す3ステップ

ここまでで、SaaS乱立とSaaS ID管理が経営リスクであること、そしてAIがその突破口になりうることを共有してきました。

で、意思決定は? という話です。

何から動けばいいのか、3ステップで整理します。スタートアップでも、明日から着手できる粒度にしてあります。

ステップ1——まず「自社のSaaS棚卸し」から始める

いきなりツールを導入しようとしないでください。順番が逆です。

最初にやるべきは現状把握。自社で「何個のSaaSを、どの部署が、何のために使っているか」をリストにすることです。

ツール選定や自動化の話は、その後でいい。現状が見えていないのに仕組みを入れても、何を自動化すべきかが定義できません。経営判断は、いつも前提を整えるところから始まります。

これは情シスに依頼すれば、数日でたたき台が出てくるはずです。完璧なリストでなくていい。まず「見える化」する。それがステップ1です。

「情シスに一声かけるだけ」で動き出せます。今日、メッセージを送ることがステップ1の全てです。

ステップ2——人事・組織データとの連携基盤を整える

次に考えるのは、「人事データを起点にする」という発想です。

入社・異動・退職という人事イベントが、アカウントの作成・削除の正しいトリガーです。逆に言うと、人事データとアカウント管理がつながっていない限り、アカウント管理の自動化は成立しません。

ここで、SmartHRのような人事データベースとID管理がつながるサービスは、ひとつの選択肢になります。

正となる人事データを起点に、各サービスのアカウント状態を照合していく。その基盤があると、自動化の土台ができます。

特定のツールに今すぐ決める必要はありません。ただ「人事データを起点に組む」という設計思想は、頭に入れておいてください。

ステップ3——「APIの壁」を越えるAI活用を経営判断として承認する

そして最後、ここが経営者の出番です。

API非対応のサービスが残っている。だから手作業が消えない。この壁を越えるためのAI活用、たとえば「ブラウザ自動操作」のような仕組みの導入を、経営判断として承認し、推進する。これはコスト削減ではなく、投資です。

投資判断なので、ROIで考えましょう。考え方はシンプルです。

削減できる工数を時間で出して、担当者の時間単価をかける。ここまでは普通の効率化の計算です。

そこに、もうひとつ足してください。リスクが開いている時間を短くできることの価値、つまり「情報漏洩や不正アクセスが起きる確率を下げられること」の価値です。これは金額にしづらいですが、経営者ならその重みはわかるはずです。

工数削減のリターンと、リスク低減のリターン。このふたつを乗せて判断すれば、多くの組織でこの投資は十分に回収できると思います。

そして、いちばん大事なこと。これを情シスに丸投げしないでください。

「アカウント管理は経営インフラだ」と経営者が旗を立てる。それだけで、現場の優先順位が変わります。

で、意思決定は? と聞かれたら、まずはステップ1、自社のSaaS棚卸しを情シスに頼むところから。それでいいんですよ。最初の一歩のハードルは、低くて構いません。

まとめ——SaaS ID管理を「裏方業務」から「経営インフラ」へ

SaaSの増殖は、たぶん今後も止まりません。便利なツールは増え続けます。

その裏で、管理されないアカウントは静かに溜まっていく。退職者アカウントの放置は、不正アクセスと情報漏洩への直通路であり、最終的に代表者の責任に跳ね返る経営リスクです。

長いあいだ、この領域は「APIの壁」に阻まれて、手作業のまま放置されてきました。でも、AIが画面の意味を理解してブラウザを操作できるようになった今、その壁に手が届き始めています。SmartHRの「ブラウザ自動操作」は、その象徴的な一歩です。

今こそ、SaaSの内部統制とセキュリティの観点からも、ID管理を情シスの裏方業務から、経営者が承認・推進する「経営インフラ」へと格上げするタイミングだと思います。

美しい資料を1枚作る時間があるなら、足元のガバナンスの穴を1つ塞ぐ判断をする。そのほうが、よっぽど経営者の仕事です。

最後にもう一度だけ。

自社で使っているSaaSが何個あるか、今日、数えてみませんか。経営判断は、いつもそこから始まります。