SaaSを1つ導入するのは簡単である。10個導入した後で、誰がどのアカウントを持っているかを把握するのは難しい。この難しさは、導入時には見えない。
デジタル庁は2026年8月13日、調達情報として**「公共SaaSコントロールプレーン設計・実装ガイド策定業務（令和8年度）」の一般競争入札**を公告した。
ここで注目したいのは、「コントロールプレーン」という言葉が業務名に入っていることである。
コントロールプレーンは、もともとネットワークやクラウド基盤の分野で使われる用語で、実際にデータが流れる部分（データプレーン）に対して、その動きを制御・管理する部分を指す。SaaSの文脈で言えば、利用者アカウントの管理、権限の付与、設定の管理、監査ログの取得、テナントの制御といった領域にあたる。
**ただし、本稿が一次で確認できたのは、公告の存在、正確な業務名、および以下の調達手続に関する事項までである。**ガイドに何が書かれるのか、どのような要求水準が想定されているのか、国がどういう方針を持っているのかは、公告からは読み取れず、本稿は推測しない。
デジタル庁の調達情報および政府電子調達（GEPS）で確認できるのは、次の事項である。
横にスクロールして確認できます
| 項目 | 内容 |
|---|---|
| 公告日 | 2026年8月13日 |
| 調達方式 | 一般競争入札 |
| 調達案件番号 | 0000000000000615360 |
| 履行期間 | 契約締結日〜2027年3月31日 |
| 技術等提案書の提出期限 | 2026年9月7日 |
| 入札書の提出期限 | 2026年9月17日 |
| 開札 | 2026年9月18日 |
**分かるのはここまでである。**ガイドそのものの内容、適用範囲、最終的な公開時期は、この公告からは読み取れない。
**本稿は、この公告そのものを解説するものではない。**入札公告の段階であり、公開されている情報は業務名と手続きに関するものに限られる。本稿が扱うのは、この着眼点を民間企業の実務に置き換えたときに何が見えるかである。
この記事を読むべき人
- SaaSを複数契約しており、正確な数を即答できない会社
- 部署ごとにクラウドサービスを契約している会社
- 従業員の退職時に、どのサービスのアカウントを止めるべきか一覧がない会社
- SaaS同士を連携させて業務を自動化している会社
- 情報システムの担当者が兼任で、SaaSの管理まで手が回っていない会社
FREE DOWNLOAD
中小企業のDX推進「失敗を防ぐ5ステップ」ガイドを無料でお送りします
多くの企業がつまずくポイントを着手順に整理した無料ガイド。相談する前に、自社の現在地と進め方を掴めます。
「何ができるか」で選び、「どう管理するか」で困る
SaaSの導入は、業務部門の判断で進むことが多い。**理由は、その手軽さにある。**サーバの調達も、社内への設置も要らず、月額の費用は稟議の閾値を下回ることも多い。
そして、選定の判断軸は「何ができるか」になる。当然である。導入の目的が業務の遂行だからだ。
問題が現れるのは、数が増えてからである。1つひとつは適切に選ばれているのに、全体としては管理できない状態になる。
具体的には、次の形で現れる。
現れ方1：アカウントの棚卸しができない。 サービスごとに管理画面が違い、それぞれにログインしないと利用者一覧が見られない。**10サービスあれば、10回ログインする必要がある。**四半期に一度の棚卸しですら、実施が難しくなる。
現れ方2：退職時の停止漏れが起きる。 人事から退職の連絡が来ても、**そもそも「その人がどのサービスを使っていたか」の一覧がない。**主要なサービスは止まるが、部署が独自に契約した小さなサービスが残る。
現れ方3：権限が積み上がる。 異動のたびに新しい権限が付与され、古い権限が外されない。数年勤めた従業員が、必要のない範囲まで見られる状態になる。
現れ方4：監査ログの所在がバラバラである。 「誰がいつそのデータを見たか」を調べる必要が生じたとき、**サービスごとにログの形式も保存期間も違う。**横断して追うことができない。
現れ方5：SaaS間の連携が把握されていない。 あるサービスから別のサービスへ、自動的にデータが流れる設定がされている。設定した人が異動した後、その連携の存在を知る人がいなくなる。
この5つは、どれか1つのSaaSの問題ではない。管理面の設計が存在しないことによる問題である。
管理面の設計とは、具体的に何を決めることか
「コントロールプレーンを設計する」を、中堅・中小企業の実務に翻訳すると、決めるべきことは次の5つになる。
決めること1：アカウントの発行と停止を、どこで一元化するか。 理想は、社内の認証基盤と各SaaSを連携させ、1か所で入退社を反映できる状態である。**ただし、これは費用と手間がかかる。その手前の現実解として、「全SaaSの一覧と、それぞれの管理者を書いた1枚の表」**を持つだけでも、停止漏れは大幅に減る。
決めること2：権限の型を決めておく。 職種や役割ごとに、標準的な権限のセットを定義する。**個別に付与していくと、誰がどの権限を持つべきかを外から確認できなくなる。**型があれば、異動時に「型を入れ替える」だけで済む。
決めること3：管理者アカウントを誰が持つかのルール。 各SaaSの最上位権限を、誰が保有するか。**「導入した人が管理者」という運用は、その人の異動で破綻する。**最低でも2名が管理者権限を持つ状態にしておきたい。1名だと、その人が不在のときに何もできない。
決めること4：ログの保存期間と、取得すべき対象。 すべてのログを長期保存する必要はない。**「個人情報を扱うサービス」「お金を扱うサービス」に絞って、保存期間を確認する。**契約プランによって保存期間が違うことがあるため、契約時の確認事項に入れておく。
決めること5：SaaS間の連携を記録する。 どのサービスからどのサービスへ、何のデータが流れているか。**この記録は、設定した本人しか作れない。**設定時に記録するルールにしておかないと、後から復元できない。
**この5つのうち、決めること1と決めること3は、費用をかけずに今週始められる。**残りの3つは、体制と契約の見直しを伴う。
「1枚の表」から始める
大がかりな仕組みの前に、次の項目を持つ1枚の表を作る。
- サービス名
- 契約者（どの部署が契約しているか）
- 費用と支払い方法（社費のカードか、部署の経費か）
- 管理者権限を持つ人（2名以上か）
- 利用者数
- 扱っているデータの種類（個人情報を含むか、財務データを含むか）
- 他のサービスと連携しているか
**7列である。**そして、この表を作る際の最も有効な手掛かりは、クレジットカードの明細と、経費精算の記録である。情報システム部門に聞いても出てこないサービスが、ここから出てくる。
なお、埋める順序としては、費用の大きいものからではなく、扱っているデータの重要度が高いものから着手したい。月額数千円のサービスが顧客の個人情報を保持している一方で、月額数万円のサービスが社外秘に当たらない情報しか扱っていない、という組み合わせは実際に起きる。費用の大小と、失われたときの影響の大小は一致しない。
**表が埋まった時点で、多くの会社は「思っていたより多い」という結果になる。**その事実自体が、管理面の設計を始める根拠になる。
管理を放置したまま進むと、どこで表面化するか
SaaSの管理面の不備は、日常業務では表面化しない。**動いているためである。**表面化するのは、外部からの要求が入った瞬間である。
表面化する場面1：取引先からのセキュリティ質問票。 一定規模以上の企業と取引を始める際、情報管理体制に関する質問票が送られてくることがある。**「利用しているクラウドサービスの一覧」「アクセス権限の管理方法」「退職者のアカウント停止の手順」といった設問が並ぶ。**一覧がなければ、回答の作成に数週間かかる。取引の開始が遅れる、あるいは条件面で不利になる。
表面化する場面2：監査・認証の取得。 ISMSやPマークなどの認証を取得する際、**利用しているサービスと権限管理の状態が確認対象になる。**準備の段階で棚卸しをやり直すことになり、想定していた工数を超える。
表面化する場面3：従業員の退職に伴うトラブル。 退職した従業員が、停止漏れのアカウントから情報にアクセスできる状態が残っていた場合、**事後に「いつからいつまでアクセス可能だったか」を説明する必要が生じる。**ログが取得できていなければ、説明ができない。
表面化する場面4：資本提携・事業承継の際のデューデリジェンス。 外部から企業の状態を精査される場面では、IT資産と契約の一覧が求められる。「把握できていない」という回答は、それ自体が評価の対象になる。
この4つに共通しているのは、いずれも「自社の都合では時期を選べない」という点である。そして、いずれの場面でも求められるのは、高度な仕組みではなく一覧と手順の存在である。
**逆に言えば、1枚の表を持っているだけで、これら4つの場面の負担は大きく変わる。**投資対効果という観点で、優先度を上げる根拠になる。
SaaSを減らすべきか
数の多さが問題だと分かると、「減らそう」という話になりやすい。ここは慎重に判断したい。
減らすことには効果がある。**管理対象が減り、費用も下がる。**一方で、現場が業務のために選んだツールを取り上げると、業務効率が落ちるか、報告されないまま別のツールが使われるようになる。
**判断の順序としては、まず「重複しているもの」から見る。**同じ用途のサービスを複数の部署が別々に契約しているケースは実際に多い。これは統合しても現場の不利益が小さい。
次に、**「利用者が1〜2名しかいないサービス」**を見る。必要性を確認したうえで、代替できるものがあれば整理する。
**逆に、多くの人が日常的に使っているサービスは、多少管理が面倒でも残すほうが合理的である。**管理の都合で業務を不便にするのは、順序が逆である。
情報システム担当がいない会社は、誰が持つべきか
専任の情報システム部門がない会社では、この管理を誰に持たせるかが最初の論点になる。技術に詳しい人に任せる、という発想は必ずしも正しくない。
管理面の実務の大半は、**技術ではなく事務である。**一覧を維持する、退職時に確認する、契約と費用を追う。これらは、経理や総務の業務と親和性が高い。
実際、SaaSの支払いは経理を通る。**費用の発生を最初に知る立場にあるのは経理である。**一覧の維持を経理側に置くと、新しいサービスの契約が自動的に把握される。
一方で、権限の設計や技術的な設定は、外部の支援を受けるほうが早いことが多い。
**現実的な分担は、「一覧と契約の管理は社内（経理・総務）、権限設計と技術的な設定は外部」である。**この分け方であれば、社内に技術者がいなくても回る。
**避けたいのは、「詳しい人が趣味的に管理している」状態である。**その人がいなくなった瞬間に、何も分からなくなる。属人化の解消は、仕組みの高度化ではなく、事務の側へ寄せることで達成できる場合が多い。
発注・契約の段階でできること
新たにSaaSを契約する際、契約前に確認しておくと後が楽になる項目がある。
**確認1：管理者を複数設定できるか。**プランによっては制限がある。
**確認2：監査ログが取得でき、保存期間はどれだけか。**上位プランでのみ提供される場合がある。
**確認3：社内の認証基盤と連携できるか。**将来の一元管理を考えると、この可否が分かれ目になる。
**確認4：契約終了時に、データをどう取り出せるか。**乗り換えの自由度に直結する。
**確認5：解約の手続きと、誰が解約できるか。**契約者が退職した後に解約できない、という事態を避ける。
**この5つは、導入時に聞けば数分で分かる。**後から確認しようとすると、プラン変更や再契約が必要になる場合がある。
よくある質問
Q. SaaSが何個あるか分からない。どう数えるか。 A. **経費の支払い記録から逆算するのが最も確実である。**クレジットカードの明細、経費精算の申請、口座振替の記録。情報システム部門の台帳より、経理の記録のほうが網羅性が高いことが多い。
Q. 部署が独自に契約するのを禁止すべきか。 A. 禁止すると、報告されないまま個人のカードで契約される場合がある。**「契約は自由だが、契約したら一覧に登録する」というルールのほうが実効性が高い。**把握できていない状態が最も避けたい。
Q. 認証基盤の導入は、中堅・中小企業でも必要か。 A. サービス数、従業員数、入退社の頻度、扱うデータの機微さによる。目安を挙げるとすれば、サービス数が数個程度であれば表による管理で回ることが多く、十数個を超えて入退社も頻繁であれば一元管理の仕組みを検討する価値が出てくる、という程度である。⚠️ **これはGXOが実務上の例として示す目安であり、根拠のある閾値ではない。**自社の環境とリスクに応じて調整してほしい。
Q. 退職者のアカウントが残っているか、どう確認するか。 A. 各サービスの利用者一覧と、現在の従業員名簿を突き合わせる。**この作業を定期的に行うと、停止漏れを見つけやすくなる。**頻度は入退社の多さに合わせて決めたい。一覧が取得できないサービスがあれば、それ自体が管理上の課題である。
Q. SaaS間の連携は、どこで確認できるか。 A. 多くのサービスでは、管理画面に外部アプリとの連携設定の一覧がある。**そこに、身に覚えのない連携が残っていることがある。**過去に試用したツールの接続が残っている例は珍しくない。
Q. 管理面の整備に、どれくらいの工数を見ればよいか。 A. 1枚の表を作る作業であれば、サービス数が10程度なら数時間から1日である。**認証基盤との連携まで進める場合は、規模に応じた設計と導入の工数が必要になる。**まず表を作り、その結果を見てから次を判断する順序が現実的である。
Q. 国のガイドは、民間企業にも参考になるか。 A. 公共分野向けの指針は、要求水準が民間の中堅・中小企業より高く設定されることが一般的である。**そのまま適用するというより、「どういう論点を設計対象とみなしているか」を参照する使い方が現実的である。**なお、本件は入札公告の段階であり、ガイドの内容はまだ公開されていない。
Q. SaaSの管理は、情報システム部門の仕事か。 A. 実務としてはそうなるが、**契約と費用の判断は事業部門にある。**この分離が管理を難しくしている。表の管理者欄に、事業部門側の担当者も書いておくと機能しやすい。
SaaSの管理設計と、システム全体の構成から相談したいとき
SaaSが増えること自体は、業務の必要から生じた自然な結果である。**問題は、増やす判断は分散して行われるのに、管理する責任は誰にも割り当てられないことにある。**この非対称が、数年かけて管理不能な状態を作る。
社内で実際に使われているサービスを洗い出し、権限付与と退職時の運用をどう設計するか。ここから相談したい場合は権限設計と退職時運用の整備で対応している。アカウントや権限の状態を技術的に確認したい場合は、アカウントと権限の状態を技術的に確認するが該当する。
システム全体の構成を見直し、どこを内製・外部サービス・個別開発で持つかを設計し直したい場合はシステム構成の再設計、データの持ち方から整理したい場合はデータの持ち方から整理するで扱っている。現在地の整理から始めたい段階であれば、現在地の整理から始める、個別の相談はSaaS管理の現状を相談するから受け付けている。
なお、BIツールのように接続情報が集中するサービスの管理はBI・データ基盤の露出と管理責任、把握されていないAI利用の統制はシャドーAIのガバナンスで扱っている。本稿は、SaaSの管理面の設計に絞っている。
参照した情報
- デジタル庁 お知らせ・調達情報: https://www.digital.go.jp/news
- 政府電子調達（GEPS）調達案件（案件番号 0000000000000615360）: https://www.p-portal.go.jp/pps-web-biz/UAA01/OAA0122?anken=0000000000000615360&cla=3&chankbn=0&chancnt=0&lan=1
- デジタル庁: https://www.digital.go.jp/
デジタル庁が2026年8月13日に「公共SaaSコントロールプレーン設計・実装ガイド策定業務（令和8年度）」の一般競争入札を公告した旨は、上記デジタル庁のお知らせ・調達情報の掲載に基づく。
**本件は入札公告の段階である。**デジタル庁の調達情報および政府電子調達（GEPS）で確認できるのは、公告日、調達方式、調達案件番号（0000000000000615360）、履行期間（契約締結日から令和9年3月31日まで）、技術等提案書の提出期限（2026年9月7日）、入札書の提出期限（2026年9月17日）、開札日（2026年9月18日）までである。本文の表はこれらによる（いずれも2026年8月14日に取得）。
**一方、ガイドそのものの内容、想定される要求水準、最終的な公開時期、適用範囲は、公告からは読み取れない。入札説明書の取得には所定の手続きが必要であり、本稿ではこれを行っていない。したがって本稿は、ガイドの中身や、国がどのような管理方針を整えようとしているかについて、一切の推測を行っていない。**参加資格などの調達手続きの詳細についても扱っていない。
「コントロールプレーン」という語の一般的な意味（制御・管理を担う領域を指すこと）は、ネットワークおよびクラウド基盤の分野で広く用いられている用法に基づく記述である。
**本稿の主たる内容であるSaaS管理の実務は、GXOが中堅・中小企業向けに整理したものであり、デジタル庁が示す指針とは無関係である。**管理面が散らばる5つの現れ方、決めるべき5項目、7列の一覧表、契約前の5つの確認事項は、いずれもGXOの整理であって、制度上の要件ではない。公共分野の調達に適用される要求水準を、民間企業がそのまま採用することを推奨するものでもない。
