こんにちは、ともしゅうです。CloudNativeで情シスの運用支援をしています。
みなさんは、SaaSで行った設定内容を記録していますか？
管理者は誰か、外部共有を許可しているか、どのポリシーが有効か。設定を確認したいとき、まず台帳を開く人は多いはずです。ところが、台帳がいつ更新されたものか分からなかったり、変更が反映されていなかったりすると、結局は管理画面を見に行くことになります。記録があるのに、現在の設定をもう一度確認する。そんな経験は少なくないのではないでしょうか。
表計算ソフトやドキュメントに一覧を作っても、日々の設定変更を反映し続けるのは大変です。障害対応で急いで変更した設定や、別の部門の管理者が変更した設定までは、なかなか追い切れません。
この記事の3行まとめ
- 台帳を更新し続けるには、更新手順を通らない変更も拾う必要があります。
- 4つの管理方式は、正本の所在と記録の更新方法で整理できます。
- 設定値を自動で記録しても、誰がなぜ決めたかは人が残します。
この記事では、設計と実機のずれをどう直すかではなく、変更後の設定と判断理由を記録に残し続ける方法に絞って考えます。
4つの方式は、正本の所在が違う
SaaS設定の管理方式は、正本の所在と記録を更新する方向で整理できます。
設定を確認するときに基準として扱う情報源を、ここでは正本（source of truth）と呼びます。
コード管理では、コードを先に変えて実機へ適用します。専用製品と人の台帳では、実機を確認して一覧を更新し、その一覧を設定確認の基準にします。観測型では実機を基準にし、台帳には同期で得た写しを置きます。
| 方式 | 正本の所在 | 仕組みでできること | 人が担うこと |
|---|---|---|---|
| コード管理 | コード。記録を先に変え、実機を追従させる | コードを通らずに行われた変更を確認し、変更を適用する | コードの更新・レビュー、変更理由の記録 |
| 専用製品 | 製品が継続的に読み取った一覧 | 対応する設定を読み取り、一覧を更新する | 推奨を採用するかの判断、例外の管理 |
| 人が更新する台帳 | 人が実機を確認して書いた表 | 設定値と判断の理由を同じ表で管理できる | 設定の確認、台帳の更新、判断・修正 |
| 観測型 | 実機そのもの。台帳は同期で得た写し | APIで取得できる設定値を定期的に更新する | 記録を見て判断し、必要なら設定を変える |
専用製品と観測型は、どちらも実機を読み取ります。ここでは、製品の一覧を正本にする運用と、実機を正本にして一覧は確認用の写しとする運用を区別しています。
1つのSaaSでも、コードで管理できる設定と、別の方法で扱う設定は分かれます。専用製品による評価と、現状の記録を組み合わせることもできます。
台帳に残したいのは、設定値と判断した理由
たとえば「外部共有を許可」という値だけでは、その設定を変えてよいか判断できません。業務上必要で許可したのか、一時的な例外なのか、以前からそのままなのか。現在の値と一緒に、決めた人や理由をたどれる必要があります。
残したい情報は、大きく2つです。
- 現在の設定値（観測値）：実際にどう設定されているか。いつ確認した値か。
- 判断の記録：管理の責任者、決定者、採用した理由。例外を認めた場合は、その理由と見直し期限。
この2つがあれば、設定を変える前の影響確認や、担当者への引き継ぎに使えます。インシデントが起きたときも、「誰が、いつ、なぜ決めた設定か」を調べる手がかりになります。
監査や規格対応にも、一覧を維持する考え方があります。たとえば、NIST CSF 2.0のID.AM-02は、組織が管理するソフトウェア・サービス・システムの一覧の維持を挙げています。CIS Controls v8.1の15.1は、サービス提供者の一覧と組織内の連絡担当者を定めることを示しています。ISO/IEC 27002:2022の管理策5.9も、資産目録と所有者を扱っています（ISO/IEC JTC 1/SC 27の解説資料）。
ただし、これらの資産・サービス一覧と、個々の設定項目を記録する台帳は同じものではありません。ここで扱う設定台帳は、日々の運用に必要な設定値や判断の理由まで記録するためのものです。
台帳が古くなるのは、更新手順を通らない変更があるから
入退社や契約更新のように手順が決まっている業務なら、その中に台帳の更新を組み込めます。漏れやすいのは、手順の外で起きる変更です。
- 障害や問い合わせへの対応で、管理画面から直接変更した。
- 台帳に項目のない設定を変更した。
- 別の部門の管理者が変更し、台帳の担当者には伝わらなかった。
IDや端末はコーポレートIT、業務SaaSは利用部門、というように管理者が分かれていると、更新手順の共有も必要です。1つの部門が台帳を持っていても、他部門の変更を知る仕組みがなければ反映できません。部門ごとに台帳を持つ場合は、全体を確認するたびに突き合わせる手間がかかります。
監査や引き継ぎの前に棚卸しをすれば、その時点では実際の設定にそろえられます。ただ、その後の変更を取り込む仕組みがなければ、またずれていきます。たとえばGoogle Workspaceの設定を具体的に棚卸しするときは、Google Workspaceセキュリティ設定見直しガイドで管理コンソールの確認項目を紹介しています。棚卸しと、日々の変更への追従は別に考える必要があります。
設定値は変更のたびに追いかけなければなりません。判断の理由は、その経緯を知る人にしか書けません。手動の台帳では、この両方を更新担当者が引き受けます。「忘れずに更新する」を徹底するだけでは、続かない場面が出てきます。
それぞれの方式で、どこまで管理できるか
1. 設定をコードで管理する
Terraformなどを使い、コードに書いた設定をSaaSへ適用する方式です。コードが正本になります。設計変更の工程がコードを通る前提で、記録であるコードを先に変え、そのあと実機を追従させます。ほかの方式が実機を読んで記録を更新するのに対し、方向が逆です。
HashiCorpの公式チュートリアルでは、手動変更によって状態ファイルと実機がずれること（原文ではdrift）について、terraform planやterraform applyで実際の状態を読み取って差分を確認する流れを説明しています。ここでのterraform planは、記録であるコードを通らずに行われた変更を検出する道具です。差分を確認したうえで、通常のplan／applyでコードに定義した状態へ戻すか、実機で行った変更を採用する場合は、terraform apply -refresh-onlyで状態ファイル（state）へ反映します。コードは自動では変わらないため、採用した変更に合わせて別途修正します。ただし、常時監視されるわけではなく、差分が分かるのは実行した時点です。
コードが台帳を兼ねる利点は、変更の記録が運用に組み込まれることです。PRに理由、承認者、関連チケットを書く運用があれば、後から「なぜ変えたか」をたどりやすくなります。Gitに残るのはあくまで変更履歴なので、理由や例外の見直し期限は、書く項目として決めておく必要があります。
実例として、GitLabはOktaをTerraformとGitOpsで管理する運用を公開しています。弊社の条件付きアクセスのベストプラクティスをTerraform化した記事も、ID領域の設定をコード化した例です。
プロバイダーの有無と、管理できる設定を確認する
SaaSごとのAPIをTerraformから扱うためのプログラムが、プロバイダーです。ここはサービスによって整備状況が違います。
| SaaS | 確認できたプロバイダー | 公開・保守の状況 |
|---|---|---|
| Okta | okta/okta | Oktaが保守するpartnerプロバイダー |
| Google Workspace | hashicorp/googleworkspace | リポジトリはアーカイブ済み。新しいリリースを公開しない旨をREADMEに記載 |
| Slack | gfnogueira/slackなど | コミュニティ製 |
| Notion | delize/notionなど | コミュニティ製 |
2026年9月11日時点で確認した例です。コミュニティ製を網羅した一覧ではありません。
Registryの区分では、officialはHashiCorp、partnerはサービス提供企業、communityは個人やコミュニティによる公開を表します。Oktaは同社ドキュメントでも、Terraformによるグループやポリシーの管理を案内しています。一方、Google Workspaceのプロバイダーは、新しいリリースを公開しない旨をREADMEに記載しています。
プロバイダーがあることと、管理したい設定をコード化できることは別です。 たとえばNotion向けの掲載例は、ページやデータベースなどの管理を扱っています。組織全体のセキュリティ設定も扱えるとは限りません。保守状況とあわせて、必要な設定項目に対応しているかを確認してください。
もう1つの条件は、運用を担う人です。既存の設定をコードに取り込み、Gitで変更し、レビューして適用する。この流れをSaaS管理者の仕事として続けられる必要があります。変更できる人が1人だけなら、引き継ぎも課題になります。コード化した後に管理画面での変更ばかりが続けば、コードも古い台帳と同じように実態から離れてしまいます。
2. 専用製品で設定を読み取り、評価する
SaaSのセキュリティ設定を継続的に確認する製品は、SSPM（SaaS Security Posture Management）と呼ばれます。たとえばMicrosoftのSSPMの解説では、SaaSアプリのセキュリティ状態の可視化や構成評価を扱い、Microsoftのベンチマークに基づく推奨事項を示しています。
この記事の主題に関係するのは、製品が対象のSaaSと設定項目を継続的に読み取り、一覧を持つことです。推奨基準、つまりベンチマークとの比較評価は、製品の付加機能として分けて考えます。
対応するSaaSと設定項目であれば、管理者が値を一つずつ転記する手間を減らせます。製品が実機を読み取り、記録を更新するので、正本は製品が持つ一覧になります。修正まで行えるかは製品によります。
ただし、推奨設定をそのまま採用できるとは限りません。業務上の理由で外部共有を許可する、といった判断は組織側に残ります。製品内で例外を登録できる場合も、誰が認めたか、なぜ必要か、いつ見直すかは記録する必要があります。
ベンチマークは、組織の方針を決めるための判断材料です。製品が持つ一覧は実際の設定に近づきますが、製品の推奨がそのまま承認済み設定になるわけではありません。
ここで製品の一覧を正本と呼ぶのは、日常の確認や評価で基準にするという意味です。同期の遅延や取得失敗が疑われる場合は、実機で確認します。
導入を考えるなら、まずは利用中のSaaSだけでなく、確認したい設定項目まで対応しているかを見てください。対応範囲、例外を管理する機能、費用が合えば、有力な選択肢です。対象外の設定は、別の方法で管理します。
3. 人が台帳を更新する
手動の台帳が合う場面もあります。年に数回しか変わらない設定や、少数の担当者で管理している小規模なSaaSなら、表にまとめる方法で十分なことがあります。
設定値と一緒に、担当者や採用した理由を書けるのがこの方式のよさです。変更した人が台帳も更新するなら、理由を別の場所へ移す仕組みも要りません。
続けやすいのは、次の条件がそろう場合です。
- 変更頻度が低い。
- 更新する人が決まっている。
- 台帳の更新手順を通らない変更が起きにくい。
変更が日常的に起き、複数の管理者がそれぞれ操作するようになると、人の確認だけで追いかける負担が増えます。台帳をやめるかどうかより、手で追い切れる範囲を見極めることが先です。
4. 実際の設定を自動で記録する
SaaSの設定をAPIで読み取り、一覧へ定期的に反映する方式です。この記事では、この運用を観測型と呼びます。
観測型では、実機そのものを正本として扱い、台帳には最後に同期した時点の設定を記録します。同期後に設定が変わっても、次の同期までは台帳に反映されません。最新の状態を確かめたいときは、実機を確認します。
たとえば、変更の手順は決まっていても、台帳への反映が追いついていない場合に使えます。Terraformで扱えない設定でも、読み取り用のAPIがあれば記録できます。業務上の例外がある設定についても、その理由と実際の値を並べて確認できます。なお、例外の内容が決まっていてコードで表現できるなら、コード管理の対象にすることもできます。
設定値は同期で更新し、変更理由は人が書きます。同期によって理由まで上書きされないよう、保存する欄を分けます。
ただし、記録はAPIで取得できる範囲に限られます。同期の失敗を検知する仕組みと、設定情報を誰に見せるかの制御も必要です。
Notionなら、同期する値と人が書く理由を分けられる
この方式の価値は、取得方法を特定の製品に固定することではありません。APIで取得した現在値を後から参照しやすい場所に集め、判断の理由や手順書と結び付けて残せることにあります。記録先をNotionのようなワークスペースにすると、設定値と人が書く情報を同じ場所で参照できます。
APIから取得して定期的に記録する仕組みは、Workersに限りません。Notion Workersの同期機能（Syncs）は、その実装方法の一例です。公式ドキュメントによると、同期先は新規作成するデータベースでも、既存のデータベースを指定するattached方式でも構成できます。同期のスキーマで定義したプロパティは読み取り専用になり、スキーマに含めていないプロパティは同期されず、人が編集できます。
つまり、同期が所有する設定値を保護しながら、人が判断の理由を書く欄を用意できます。 データベース全体が編集禁止になるわけではありません。
ただし、行の追加・削除は同期だけが管理します。replaceモードでは、その同期サイクルで見なかった行が自動的に削除されます。長く残したい判断の記録は別のデータベースで管理し、設定の記録と関連付ける設計も考えられます。
Workersの機能はNotion AIマスターコースで、料金の前提はNotion Workersの料金と更新を整理した記事で紹介しています。
手元のSaaSを、設定の領域ごとに仕分ける
方式を選ぶときは、SaaSを丸ごと1つの方法にそろえようとせず、管理したい設定の領域ごとに考えます。
| 方式 | 向いている条件 | 選ぶ前に確かめること |
|---|---|---|
| コード管理 | コードを変更し、レビューしてから適用する運用を続けられる | 必要な設定への対応、プロバイダーの保守、運用・引き継ぎの体制 |
| 専用製品 | 設定の確認とリスク評価を製品に任せたい | 対象SaaSと設定項目、例外の管理方法、費用 |
| 人が更新する台帳 | 変更が少なく、更新担当者と手順が決まっている | 手順を通らない変更を把握できるか |
| 観測型 | まず現状を把握したい、設定値の転記を自動化したい | APIの取得範囲、同期の監視、記録を見て対応する担当者 |
まず、導入済みの専用製品やコード管理で扱えている範囲を確認します。次に、残った設定のうち、必要なプロバイダーがあり、コードの変更・レビュー・適用を続けられるものはコード管理を検討します。専用製品の新規導入は、対象範囲と費用が合うかで判断します。
それでも残る設定は、変更の頻度と担当者を見ます。手で追い切れるものは台帳で管理し、現在の値を追う作業が負担なら観測型を検討する。APIで読めない設定は、人が確認する必要があります。
仕分け表は、次の6項目から始めるとよいと思います。
- SaaS名
- 設定の領域
- 管理の責任者
- 正本の所在（コード・製品の一覧・人の台帳・実機）
- 変更頻度
- 判断の記録場所（決定者・理由・見直し期限をたどれる場所）
観測型を選ぶ場合は、正本の所在の欄に「実機（台帳は同期で得た写し）」と書きます。意図して選んだ方式と、まだ決まっていない設定を区別するためです。責任者が空欄なら担当を決め、判断の記録場所が空欄なら、変更理由をどこに残すかを決めます。
おわりに
コードで管理できる設定はコードへ。製品で確認できる設定は製品へ。人が無理なく更新できる範囲は台帳に残し、現状の収集を自動化したいところには観測型を使う。手元のSaaSについて、設定の管理方法と責任者を1枚に書き出すところから始めてみてください。
この記事は、前回のNotion Workersの料金と更新を整理した記事で持ち越した、設定管理の運用についての続きです。次回は、観測型を実際に構成した結果を書く予定です。
SaaSの設定管理や台帳の更新で同じ課題を感じている方の参考になれば嬉しいです。相談したいことがあればお気軽にお声がけください。
製品仕様とプロバイダーの公開情報は2026年9月11日時点で確認しています。導入・実装時は、リンク先で最新の対応範囲と保守状況を確認してください。
