SaaS台帳管理とは？利用中SaaS・委託先・データ転送経路を可視化する実務

SaaS台帳管理が必要な理由

SaaS台帳は購入リストでも契約台帳でもありません

SaaS台帳が必要になる場面では、すでに購買部門や法務部門が契約一覧を持っていることが少なくありません。しかし契約一覧だけでは、今も現場で使われているか、どの部門が管理責任を持つか、どのデータがどこへ流れているかが分からないことがよくあります。無料プランの試用、部門単位の導入、外部委託先が裏側で使っているサービス、連携だけ残っている古いサービスは、契約台帳から抜けやすいからです。

そのため SaaS台帳は、購買や契約の記録を再利用しつつも、主役を利用中サービスの現状確認へ置き換える必要があります。どのサービスが、どの業務で、誰の責任で、どのデータを扱い、どこへつながっているかまで追えないと、事故や障害のときに調査範囲と判断責任が曖昧になります。

さらに SaaS は導入の入口が多いのも難しい点です。購買を通した正式導入だけでなく、部門の業務改善、委託先提案、無償プランの試用、既存サービスの追加機能など、さまざまな入り口で増えていきます。だから台帳の目的は「正式契約だけを並べる」ことではなく、現場で実際に使われている依存先を漏らさず戻すことにあります。

主役は『利用中 SaaS』『管理責任者』『データ転送経路』です

SaaS台帳管理を実務に落とすうえで重要なのは、SaaS を「契約済みの箱」として見るのではなく、今も使われている業務の一部として扱うことです。社内の誰が管理責任者か、どの業務が依存しているか、個人情報や営業情報、ログやファイルがどこへ保管・転送されるか、何と連携しているかまで見えるようにすると、初めて棚卸しの価値が出ます。

ここで似た記事との役割を分けておきます。SaaS ベンダーリスクの記事は、契約、監査、通知、継続評価を主役にした管理記事です。一方で本記事は、利用中 SaaS をどう台帳へ戻し、どこまで可視化するかを主役にします。また 外部公開資産台帳の記事 は外から見える資産の棚卸しが主役であり、こちらは業務利用中の SaaS と委託先、データ転送経路へ絞ります。

実務では、無償ツール、部門判断の試験導入、委託先が裏で使っている補助サービスが最も抜けやすくなります。ところが事故や契約見直しの場面で問われるのは、正式契約の有無ではなく「今どの業務が何に依存しているか」です。SaaS 台帳は、影響を受ける可能性のある利用実態を先に集める資料と考えた方がうまく回ります。

SaaS台帳に最低限入れる項目

とくに抜けやすいのは、保持データと転送先、そして外部接点です。たとえば「SaaS そのものは把握しているが、どの API 連携が残っているか分からない」「サポート窓口や公開ドキュメント用ホストが今も生きているかは別管理」という状態は珍しくありません。ここが曖昧だと、何を止めるべきか、誰へ確認すべきかが決まりません。

逆に、全部を最初から細かく書こうとすると台帳は続きにくくなります。まずは「利用中サービス」「管理責任者」「用途」「保持データ」「主な連携先」「外部接点」「更新日」をそろえ、そこから 契約や監査の詳細 を別トラックで深める方が現実的です。

また、台帳へ書く項目は「誰に聞けば埋まるか」が分かる形にしておく必要があります。管理責任者の欄が空欄になりやすいなら、利用部門の申請経路と結び付ける、外部接点の欄が埋まらないなら公開資産台帳と相互参照する、といった運用設計まで含めないと、必要項目があるだけで更新できない台帳になってしまいます。

ここで効果があるのは、台帳を一度に完成させようとせず、「最初の棚卸し」「変更時の追記」「年次見直し」の三段階で埋める前提にすることです。そうすると現場は最低限の記録から始めやすく、中央管理側も抜けやすい項目を後から補いやすくなります。SaaS 台帳は、完成度より更新し続けられる設計の方が重要です。

保持データとデータ転送経路をどこまで可視化するか

データ転送経路の可視化というと、すべての通信やネットワーク詳細図まで描かないといけないと思われがちです。しかし SaaS 台帳の段階で必要なのは、通信解析の完全再現ではなく、どのサービスがどのデータを受け取り、どこへ渡し、どの連携が業務停止に直結するかを判断できる粒度です。まずは重要業務と重要データに絞って、関係する SaaS、委託先、連携先、外部接点を段階的に可視化する方が運用へ乗ります。

重要データから描き始めると、台帳が空回りしにくくなります

すべてのサービスを同じ深さで可視化しようとすると、台帳はすぐ更新できなくなります。現実的には、個人情報、決済、営業案件、顧客対応、権限管理のような止まると困る業務と重要データから描き始める方が続きます。そうすると、どの委託先、どの連携先、どの担当部門を先に見るべきかが自然に決まります。

データ経路の可視化は監査向けの図作りではありません。事故時に「この SaaS はどのデータを持つか」「どの連携先へ流しているか」「停止するとどの業務が止まるか」を早く説明できるようにするためのものです。

連携停止時の影響まで書くと、台帳が判断資料へ変わります

連携先を書くだけでは台帳は判断資料になりません。大切なのは「その連携が止まると何が起きるか」を一緒に持つことです。通知が止まるのか、同期が遅れるのか、申請が詰まるのか、問い合わせが途切れるのかが分かれば、事故時の優先順位と代替運用を決めやすくなります。

この視点は 物流停止の事業継続計画 や 委託先アカウント管理 にもつながります。SaaS 台帳は一覧表ではなく、止まった時の判断材料として持つ方が価値が出ます。

さらに見落としやすいのは、委託先から再委託先へ流れる経路です。自社から見えるのは一社でも、実際にはログ保管、通知送信、帳票生成、分析などが別の事業者へ渡っていることがあります。ここが見えていないと、事故時にどこまで影響調査を広げるべきかを決められません。

また、転送経路は「どこへ送るか」だけでなく「どの条件で送るか」も見ておくと実務で役立ちます。常時同期なのか、手動出力なのか、定期連携なのかで、停止時の影響も復旧時の戻し方も変わるからです。SaaS 台帳に連携方式まで簡潔に残しておくと、障害時の切り分けと再開判断がやりやすくなります。

加えて、委託先が「どのデータを受け取るか」だけでなく、「どの場面で一時保存し、どこで削除し、誰が確認できるか」まで把握しておくと、事故時の説明が早くなります。SaaS 台帳は通信経路の完全図ではなくてもよいですが、重要データの置き場所と流れの節目を言葉で説明できる状態までは作っておく必要があります。

公開資産台帳と SaaS台帳をどうつなぐか

内部利用と外部接点を別管理にしない方が事故時に強くなります

事故や障害のときに困るのは、社内で使っている SaaS 一覧と、外から見える接点の一覧が別管理になっている状態です。SaaS の管理画面は閉じていても、公開ドキュメント、通知受信用 URL、障害告知ページ、サポート窓口、古いホスト名が残っていると、そこから現場や顧客への案内や調査が始まります。逆に外から見える接点を見つけても、それがどの業務のどの SaaS と結び付くかを説明できないと、調査の優先順位が付きません。

そのため SaaS 台帳では、外部接点を別ファイルへ切り離し過ぎず、少なくとも「どの SaaS にひも付く接点か」「どの部門と管理責任者が担当か」が追えるようにしておく方が安全です。この点で 公開資産台帳 と シャドーAPIの棚卸し は、SaaS 台帳とつながる補助線になります。

公開資産台帳と SaaS台帳は役割が違います

ここは混同しやすい点です。公開資産台帳は、外から見えるホスト、URL、証明書、DNS、公開面の管理が主役です。一方、SaaS 台帳は、業務で利用中のサービス、委託先、管理責任者、保持データ、転送経路、連携先が主役です。つまり見る対象が違うのですが、API、サポート導線、公開ドキュメント、通知受信用 URL のような接点では互いに重なります。

本記事では、SaaS 台帳を「内側の利用実態」と「外から見える接点」をつなぐ運用台帳として扱います。外部公開面の詳細な棚卸し手順は 外部公開資産台帳の記事 に譲り、こちらではそれを利用中 SaaS の責任とデータ経路へどう戻すかを重視します。

実際の事故では、公開ドキュメント、通知受信用 URL、サポート窓口が先に見つかり、後から「これはどの SaaS にひも付くのか」を探すことが少なくありません。だから外部観点で見つかった接点を SaaS 台帳へ戻す導線があると、外から見える現実と社内の利用実態を同じ資料で照合しやすくなります。

変更時レビューと見直しサイクルをどう回すか

NIST SP 800-161 Rev.1 は、一覧化して終わりではなく継続評価を前提にしています

NIST SP 800-161 Rev.1↗は、供給網リスクを継続的に特定し、評価し、低減していく考え方を示しています。SaaS 台帳へ引き直すと、これは「導入時の質問票で終わらせず、利用中サービス、依存業務、保持データ、連携先、管理責任者を継続的に更新する」という意味に近づきます。つまり一覧化の価値は台帳を作る瞬間ではなく、変更が起きた時に戻れることにあります。

また NIST の供給網リスク管理解説でも、委託先がもたらすサイバーリスクを継続的に把握し、対応する考え方が前に出ています。SaaS 台帳はその入口として、どの委託先とサービスが現場へ影響するかを最初に説明できる形にしておくべきです。

CISA は実行手順として始めることを重視しています

CISA の供給網リスク管理入門↗は、責任者と実務担当者が供給網リスク管理を始めるための実行手順を示しています。ここから読み取れるのは、完璧な情報が集まるまで待つのではなく、まず利用中サービスと依存関係を見える化し、見直しの単位を決めることが重要だという点です。

さらに CISA の委託先供給網リスク管理テンプレートは、ベンダー、依存関係、業務影響、連絡体制、復旧観点を記録する実務の型を示しています。SaaS 台帳を監査向けの一覧で終わらせず、変更時レビューの材料にするには、このような実務テンプレートが役立ちます。

ここで重要なのは、購買、法務、情報システム、利用部門が別々に情報を持つ前提で設計することです。NIST や CISA の資料は、評価結果を一つの部門だけで抱え込まず、意思決定へ返すことを重視しています。SaaS 台帳も同じで、複数部門が違う入口から更新できる仕組みにした方が継続しやすくなります。

変更イベントを決めると、台帳が古くなりにくくなります

実務で効くのは、年1回の棚卸しよりも「どのイベントで台帳へ戻るか」を決めることです。たとえば、新規導入、統合認証追加、API 連携追加、保持データの変更、委託先変更、事故、契約終了、無料枠から本契約への移行などは、台帳更新の自然な引き金です。こうしたイベントを決めておくと、現場の変化が台帳へ戻りやすくなります。

SaaS台帳は監査資料だけではなく、障害時の案内、セキュリティレビュー、委託先見直し、レポート作成にもつながります。セキュリティ報告書の雛形 や SaaS ベンダーリスクの管理記事 と接続しておくと、一覧化した情報を判断材料へ戻しやすくなります。

事故・監査・契約見直しのときに台帳をどう使うか

事故時には『誰に確認するか』を最短で決める材料になります

事故のとき、最初に困るのは「どのサービスがどの業務を支えていたか」より、「誰に確認するか」が曖昧なことです。SaaS 台帳に管理責任者、利用部門、委託先窓口、保持データ、主要連携が入っていれば、調査対象、連絡対象、停止対象を短時間で切り分けやすくなります。逆にこの情報がないと、契約書、チャット履歴、部門の記憶を行き来するだけで時間を失います。

とくに SaaS 障害や委託先事故では、業務影響と情報影響が同時に立ち上がります。だから台帳は、名称の一覧ではなく、影響範囲を説明する地図であるべきです。

監査や契約更新では『現場で本当に使われているか』を確認する起点になります

監査や契約更新では、質問票や契約条項の確認だけでなく、今も現場でどの連携が使われ、どのデータが流れ、どの外部接点が残っているかを見直す必要があります。ここで SaaS 台帳があれば、契約、利用実態、外部接点を同じ土台で突き合わせることができます。

たとえば契約上は停止済みでも、通知受信用 URL や API 接続が残っていれば、台帳更新と接続停止が連動していないことが分かります。台帳の役割は、そのズレを発見して是正へ返すことです。

契約終了時にも同じです。管理画面の削除、連携停止、公開ドキュメント閉鎖、担当者の権限剥奪、過去データの保管方針を一緒に確認しないと、見た目上は契約終了でも外部接点だけが残り続けます。SaaS 台帳は、導入よりも終了時の整理に効く資料と考えると役割が見えやすくなります。

そのため、監査や契約更新の場面では「契約条項が足りているか」だけでなく、「現場でどの運用が続いているか」「外部接点が残っていないか」まで必ず照合した方が安全です。SaaS 台帳があると、契約見直しを利用実態と切り離さずに進めやすくなります。

結果として、契約更新の議論も「価格」や「条項」だけでなく、現場運用と外部接点の整理まで含めた判断へ広げやすくなります。

その意味で SaaS 台帳は、契約更改のたびに使い回せる実務の共通土台でもあります。

SaaSや委託先の外部接点を整理するならASM診断 PRO

ASM診断 PRO は、SaaS 台帳や委託先台帳そのものを置き換える製品ではありません。ただし、年次見直しや事後レビューのときに、外から見える公開ドキュメント、通知受信用 URL、サポート窓口、放置されたホスト名、API 接点を洗う入口としては使いやすい構成です。契約や監査の代替ではなく、台帳に戻すべき外部接点の現状確認を補助する位置づけです。

とくに「契約上は把握しているが、今もどこが公開されているか分からない」「委託先や利用中 SaaS にひも付く公開面を外から洗いたい」という場面では、利用中 SaaS の台帳と外部観点の棚卸しをつなぐ導線があると会話しやすくなります。SaaS 台帳を運用資料として生かすには、内側の管理情報だけでなく、外から見える接点の現状確認も合わせた方が現実的です。

既存の 公開資産台帳のテンプレート や セキュリティ報告書の雛形 と合わせると、SaaS 台帳を「一覧のまま放置する資料」ではなく、「変化が起きた時に戻る運用台帳」として扱いやすくなります。外部接点の現状確認までつながると、契約、現場利用、外部公開面の三つが別管理になりにくくなります。

事故が起きてから接点を探し始めると、サポート窓口、通知経路、古いホスト名の確認に時間がかかります。先に外部観点で洗い出しておくと、SaaS 台帳の更新漏れも見つけやすくなり、平時の棚卸しと事後対応を同じ流れで回しやすくなります。

よくある質問（FAQ）

契約台帳があれば SaaS台帳は不要ですか

不要ではありません。契約台帳は調達や法務の管理に有効ですが、今も使われているか、どの部門が管理責任者か、どのデータがどこへ流れているかまでは抜けやすいです。SaaS台帳は利用実態と依存関係を補うために必要です。

無料プランや部門導入のサービスも載せるべきですか

はい。正式契約の有無より、現場で利用中かどうかが重要です。無料プランや試験導入でも、ファイル共有、フォーム受付、通知、自動連携に使われていれば、障害や情報流出の影響は現実に発生します。

データ転送経路はどこまで細かく書けばよいですか

最初から通信レベルで完全再現する必要はありません。まずは、どの SaaS がどのデータを保持し、どの委託先や連携先へ渡し、どの外部接点が残っているかを説明できる粒度で十分です。重要業務と重要データから優先的に深める方が実務に合います。

公開資産台帳と SaaS台帳は同じファイルにすべきですか

同じである必要はありませんが、少なくとも相互にたどれるようにした方が安全です。公開ドキュメント、API 接点、通知受信用 URL、サポート窓口のような重なり部分では、別管理だと事故時の調査が遅れやすくなります。

SaaS台帳の更新は誰が持つべきですか

セキュリティ部門だけに寄せず、管理責任者を持つ利用部門と中央管理側が分担するのが現実的です。利用部門が用途と依存関係を更新し、中央側が変更イベントや年次見直しで抜け漏れを点検する形が続きやすいです。

まとめ

SaaS台帳管理の主役は、契約済みサービスの列挙ではありません。今も利用中の SaaS、委託先、管理責任者、重要業務、保持データ、連携先、外部接点を同じ判断資料へ戻せることが重要です。ここが見えていれば、障害、事故、契約更新、委託先見直しのどれが来ても、誰が何を確認すべきかを早く決められます。

また、公開資産台帳と SaaS台帳は役割が違いますが、API、サポート導線、公開ドキュメント、通知受信用 URL のような接点ではつなげて持つ方が実務で強くなります。まずは利用中サービスと管理責任者をそろえ、次に保持データ、転送経路、外部接点、変更イベントを足してください。そうすると台帳が単なる一覧ではなく、運用と判断の基盤へ変わります。

さらに、NIST や CISA が示すように、供給網リスク管理は一覧を作って終わりではありません。新規導入、連携追加、委託先変更、事故、契約終了のたびに台帳へ戻り、現場で使われている実態と外から見える接点を更新し続ける必要があります。SaaS 台帳を本当に役立つ資料にしたいなら、契約、利用実態、外部接点をつなぐ見直しサイクルとして回してください。

その結果、SaaS 台帳は監査向けの添付資料ではなく、障害、事故、契約見直し、委託先変更のたびに参照する実務資料になります。どのデータがどこへ流れ、どの接点が外から見え、誰が判断を持つのかを常に説明できる状態を目指すことが、SaaS 台帳管理の本質です。