社内でどのSaaSが使われているか、正確に答えられる人がいない。この状態では、費用の削減も、退職者のアカウント停止も、情報漏洩時の影響範囲の特定もできません。
多くの組織は、情報システム部門が導入を把握しているツールの一覧を持っています。しかし部門が経費で個別に契約したツールは、その一覧に載っていません。問題が起きるのは、ほぼ例外なくそちら側です。
本記事では、把握漏れを出さないSaaS管理台帳の作り方と、更新し続けるための運用を整理します。
台帳がないと、何ができないのか
台帳は管理のための書類ではなく、次の判断をするための前提です。
| やりたいこと | 台帳が無いと起きること |
|---|---|
| 費用を削減する | 何にいくら払っているか分からず、削れるものが見つからない |
| 退職者のアカウントを止める | どのツールにアカウントがあるか分からず、止め漏れる |
| 情報漏洩時に影響範囲を調べる | 顧客データがどこに置かれているか分からない |
| 契約を更新前に見直す | 更新日を知るのが更新後になる |
| 重複するツールを整理する | 同じ用途のツールが何個あるか分からない |
2番目が最も深刻です。退職者がログインできる状態のツールが残っていることは、費用の問題である前に情報管理の問題です。
洗い出しの手順
手順1:お金の流れから拾う
最も漏れが少ない方法です。SaaSは必ず支払いが発生するため、支払いの記録から逆算します。
| 拾う元 | 見つかるもの |
|---|---|
| 情報システム部門の契約書・請求書 | 全社で導入したツール |
| 経費精算の明細 | 部門や個人が立て替えて契約したツール |
| 法人カードの利用履歴 | カード払いで契約したツール |
| 会計ソフトの支払先一覧 | 請求書払いのツール |
経費精算と法人カードは、勘定科目が「通信費」「支払手数料」「消耗品費」などに分散していることが多いため、科目で絞らず、支払先の名称で拾ってください。海外のSaaSは英語の社名で記録されます。
手順2:認証の記録から拾う
お金の流れに出ない無料プランのツールは、ここで拾います。
- 会社のメールアドレスで登録されているサービス(「アカウント作成」「ようこそ」などの件名のメールを検索)
- シングルサインオン(SSO)を導入していれば、その連携先一覧
- Googleアカウントや Microsoft アカウントでログインしている外部サービスの一覧(管理画面で確認できる場合があります)
無料プランは管理機能が弱く、退職者のアカウントを会社側で停止できないことがあります。費用がかからないからといって後回しにしないでください。
手順3:部門に確認する
手順1と2で拾った一覧を部門に見せ、漏れがないか、既に使っていないものはどれかを確認します。
白紙の状態で「使っているツールを申告してください」と頼むと、漏れます。申告する側に、すべて書き出す動機がないためです。一覧を見せて確認してもらう形にすると、精度が上がります。
台帳に持たせるべき項目
項目は多すぎると更新されなくなります。次の15項目で足ります。
| 区分 | 項目 | 使い道 |
|---|---|---|
| 基本 | サービス名 | — |
| 用途(一文で) | 重複の確認 | |
| 利用部門 | 継続判断の担当を決める | |
| 社内の管理者 | 問い合わせ・アカウント管理の窓口 | |
| 契約 | 契約形態(月額/年額/無料) | 更新の管理 |
| 契約開始日・次回更新日 | 更新前の見直し | |
| 解約の通知期限(更新日の何日前か) | 自動更新の回避 | |
| 年額費用 | 費用の把握 | |
| ライセンス数 | 利用率の算出 | |
| 支払方法(請求書/カード/経費精算) | 次回の洗い出しで拾う元 | |
| データ | 扱うデータの種類(顧客/社員/取引/なし) | 情報漏洩時の影響範囲 |
| 他ツールとの連携の有無 | 乱立の把握 | |
| アカウント | 管理画面で最終ログインを確認できるか | 未使用ライセンスの検出 |
| SSO対応の有無 | 退職時の一括停止 | |
| 退職時の停止手順 | 入退社手続きへの組み込み |
「扱うデータの種類」は必ず入れてください。費用管理だけを目的に台帳を作ると、この項目が抜けます。そして情報漏洩が起きたときに、どのツールを調べればよいか分からなくなります。
更新し続けるための運用
台帳は、作った瞬間から古くなります。最も多い失敗は、作ったあと誰も更新しない状態です。
原因は、台帳の更新が独立した作業になっていることです。既存の業務の流れに組み込みます。
| 業務の流れ | 組み込む内容 |
|---|---|
| 新規契約の申請 | 申請書の項目を台帳の項目と一致させ、承認と同時に台帳へ追加 |
| 入社の手続き | 付与するアカウントを台帳から選ぶ |
| 退職の手続き | 台帳の「退職時の停止手順」に沿って全ツールを停止し、完了を記録 |
| 更新日の通知 | 台帳の更新日の3か月前に、利用部門へ継続要否の確認を送る |
| 四半期ごとの突合 | 経費精算とカード明細から新しい支払先を拾い、台帳にないものを確認 |
とくに退職の手続きへの組み込みは最優先です。台帳を見ないと退職手続きが完了できない状態にしておけば、台帳の「退職時の停止手順」が空欄のツールは、手続きの時点で必ず発覚します。
契約を禁止しない
台帳を整備すると、「今後は情報システム部門の承認なしに契約させない」という方針を出したくなります。
これは逆効果です。申請が面倒になると、部門は経費精算や個人のカードで契約し始め、台帳から漏れます。統制を強めた結果、把握できないツールが増えるという状態になります。
止めるべきは契約そのものではなく、把握されないまま社内のデータを置かれることです。申請はできるだけ軽くし、その代わり申請時に「扱うデータの種類」だけは必ず書かせる運用が現実的です。
まとめ
- 台帳は書類ではなく、費用削減・退職時の停止・漏洩時の影響範囲の特定の前提です
- 洗い出しは部門の申告に頼らず、経費精算の明細と法人カードの利用履歴から拾います
- 無料プランのツールも載せてください。退職者のアカウントを会社側で止められないことがあります
- 項目には必ず扱うデータの種類を入れます。費用管理だけを目的にすると抜けます
- 更新は独立した作業にせず、新規申請・入退社・更新通知の流れに組み込みます
- 契約を禁止すると、台帳から漏れる契約が増えます。申請を軽くし、扱うデータだけは書かせる運用にしてください
セキュリティ面での統制の考え方は、テレワークのセキュリティ課題を解決するシステム統制の最適解でも扱っています。



