移行の判断更新日
#今後、ノーコードツールやSaaSを選ぶときに何を確認すべきですか？（エクスポートの可否、データの保存期間、2FA、事故時の通知条項など）
契約前に確かめたいのは、データを持ち出せるか、データがどこにどれだけ残るか、誰がログインできるか、事故が起きたときに誰がいつ知らせてくれるかの4点です。Studioの事案では、サイトの見た目とは関係のないフォーム回答や外部連携の設定まで影響が及びました。平時の使い勝手だけで選んでしまうと、運用の見直しやトラブル対応の段階で手詰まりになりかねません。
| 確認すること | 見る場所 | 見落とすと困ること |
|---|
| エクスポートの可否と範囲 | ヘルプの書き出し機能、料金表 | 乗り換えのときに一から作り直す |
|---|
| 保存と削除の扱い | ヘルプの削除手順、プライバシーポリシー | 不要な回答がサーバーに残り続ける |
|---|
| 2段階認証とアクセス権 | セキュリティ設定、料金表 | 退職者や使い回しのパスワードから入られる |
|---|
| 事故時の通知 | 利用規約、データ処理の付属文書 | 被害を知るのが遅れる |
|---|
アクセス権は見落とされがちです。個人データを扱う仕組みでは、触れる担当者とデータの範囲を絞る必要があります。microCMSのようにAPIキーの権限を必要最低限の取得（GET）に絞る設定ができるかなど、被害を局所化できる仕組みがあるかを見極めます。ただ、それだけで安全になるわけではありません。
ちなみに、画面に表示される件数と、実際に保存されている件数が違うこともあります。Studioのフォーム機能では、閲覧制限を超えた回答も1日5,000件の保存上限内なら蓄積されます。管理画面で閲覧できない状態であっても、データ自体が消えたわけではありません。
あわせて、個人データの漏えいなどが起きたとき、委託先から何日以内に知らせが来るのかも、契約前に確かめておきましょう。通知基準が規約でどう定義されているかも重要な確認事項ですね。
#なぜエクスポートできるかを最初に確認すべきなのですか？
「もし使っているサービスに不都合が出たら、データを書き出して別の基盤へ移せばよいのではないか」と考える人は多いでしょう。ところが、出せないとわかった時点で、作り直すか使い続けるかしか選べなくなります。
Studioでは、デザインやページ情報、CMSのデータをどれも書き出せません。他のサービスへ移るときは、移行先で改めて作ります。例外はフォームの回答で、フォームダッシュボードからCSVでダウンロードできます。
もっとも、エクスポート機能を備えているツールでも、プランによる制限や出力仕様の条件を細かく見る必要があります。microCMSは管理画面からCSVエクスポートができますが、使えるのはTeam・Business・Enterpriseプランで、Hobbyプランでは使えません。さらに出力対象となるデータも、そのとき画面のビューで設定している検索や絞り込みの条件に基づきます。全件を出したつもりでも、一部しか出ていないことがあります。
またWebflowもCMSコレクションをCSVで書き出せます。Wixは、全件を出すか、絞り込んだ結果だけにするか、項目名だけにするかを選べます。
ツールを比べるときは、何を、どの範囲で、どんな形式で出せるかまで見ておきたいですね。画像の元データは手元にも残しておきましょう。
#データの保存期間と暗号化について、何を確認すればよいですか？
フォームで受け取った回答は、どれくらいの期間残るのでしょうか。消した回答は、本当に消えているのでしょうか。
個人情報保護法では一律の保存期間を定めていませんが、利用が終わった個人データは遅滞なく消去する努力義務があります。業務に必要な期間を自社で決め、その期間を過ぎたら消す運用にしておくのが現実的でしょう。
暗号化も、されていれば安心とは言えません。今回は暗号化されていた回答も、同じ不正アクセスで復号の鍵を読み出され、内容を知られた可能性があります。個人情報保護委員会のQ&Aでは、高度な暗号化で報告の対象から外れるには、復号する手段を適切に管理していることが要件とされ、その方法の一つに、データと鍵を分けて鍵そのものの漏えいを防ぐことが挙げられています。サービスを選ぶときは、データと鍵を分けて管理しているか、鍵そのものを守る対策があるかまで聞いておきたいところです。
#二次被害を防ぐための対応チェックリストはありますか？
「利用中のサービスで不正アクセスが起きたとき、被害の広がりを抑えるために何から手をつければよいのか分からない」と戸惑う声は少なくありません。お知らせで案内されている対応を、手を付けやすい順に並べました。
- Studioのパスワードを変え、同じパスワードを使っている他のサービスも変更する。パスワードを設定していなければ、変更しようとするとエラーが出るが追加の対応は不要。設定したか分からなければ、ログイン画面の『パスワードをお忘れですか？』から再設定する
- APIキーは、新しいキーの発行、利用側の設定の更新、古いキーの失効の順に切り替える。古いキーを先に止めると連携が止まることがある
- Webhookの通知先は、新しいURLの発行、設定の更新とテスト送信、古いURLの無効化の順に進める
- Googleスプレッドシート連携は、Studioで解除してから、Google側でStudioのアクセス権を削除する。必要なら新しいシートで再連携する。同じGoogleアカウントで連携している他のプロジェクトでも、シートへの追加が止まるので、そちらも連携し直す
- 発行済みのライブプレビューURLを削除し、共有を続けるものだけ再発行する
- パスワード保護ページのパスワードを変え、閲覧者に新しいパスワードを伝える
- APIの利用状況や請求額を見張る。Google Cloudには、想定外の支出を知らせる異常検知の通知がある
- フォーム利用者への本人通知が必要か判断する
8番は自社で動く必要があります。Studioとの連名の報告に、サイト利用者本人への通知は含まれません（Studioの事案ページ）。漏えいしたデータの性質に応じて個人情報保護委員会への報告や、影響を受けるフォーム利用者への通知が必要かどうかを速やかに判断します。判断に迷うときは、法令を確かめたうえで専門家に相談してください。
なお、Studioは、本件で送るメールにパスワードや認証情報の入力を求めるリンクは入れないとしています。入力を促すメールが届いたら、偽物を疑って開かないでください。
こんな聞き方も
- 今後、ノーコードツールや SaaS を選ぶときに何を確認すべきですか？（エクスポートの可否、データの保存期間、2FA、事故時の通知条項など）
- 二次被害を防ぐための対応チェックリストはありますか？
- StudioからmicroCMSへの移行で確認すべき項目のチェックリストはありますか？
- saas 選定 セキュリティ チェックリスト
- ノーコードツール 選び方 セキュリティ
- saas 選ぶ 注意点 エクスポート
- cms 選定 2段階認証 確認
あわせて知りたい（関連する疑問）
QStudioからmicroCMSへ移行する時に確認すべき項目は？
デザイン作成からWebサーバーの配信まで画面上で完結するStudioと、記事や画像のデータ管理に専念するヘッドレスCMSのmicroCMSとでは、サイトを支える仕組みが対照的です。この違いを理解せずに移行を進めると、思わぬ開発工数や仕様の不一致に直面します。
まず、microCMSはコンテンツをAPIで配信する裏側の仕組みであるため、HTMLやCSSを表示する画面部分と、それを配信するWebサーバーを別途用意しなければなりません。CMS用のサーバーは不要でも、表示側の作り込みと置き場所は自分で決めることになります。
データの移し方も先に見ておきたいところです。microCMSにはCSVインポートがありますが、Studio側からCMSのデータをCSVで書き出す機能はありません。出せるのはフォーム回答だけです。記事は手で入力し直すか、公開中のページを見ながら自分でCSVを作ることになります。
インポートできる件数はプランで違います。microCMSの料金表では、CSVインポートの上限はHobbyが1,000件、Teamが2,000件、Businessが5,000件、Enterpriseが10,000件です。蓄積されたコンテンツ量とプランの上限を照らし合わせなければなりません。
問い合わせフォームは、外部のフォームサービスを使う方法と、microCMSのPOST APIで作る方法があります。外部サービスが必須というわけではありません。ただしPOST APIによる実装は問い合わせデータの細かな追跡管理に特化していないため、問い合わせ件数が多い業務では外部サービスの併用を前提に考えるのが無難です。
QmicroCMSで2段階認証を強制できるのはどのプランですか？
社内や外部ライターのアカウント全員に2要素認証を必須にできるのは、現行プランではEnterpriseプランだけです（2要素認証の必須化）。Hobby、Team、Businessでは使えません。
とはいえ、microCMSの2要素認証そのものは、利用しているプランを問わず全アカウントが無料で個別に有効化できます。ただし個人の判断に委ねられるため、設定を怠るメンバーが紛れ込む隙が残ってしまいますね。
必須化すると、2要素認証を設定していないメンバーはそのサービスの管理画面に入れなくなります。設定は「サービス設定」から「セキュリティ」を開いて行います。制限されるのは管理画面で、公開サイトの閲覧には関係ありません。
もうひとつ、アクセス元を絞るIPアドレス制限もあります。使えるプランは下の表のとおりです。
| 機能 | Hobby | Team | Business | Enterprise |
|---|
| 2要素認証の個人設定 | ○ | ○ | ○ | ○ |
|---|
| 2要素認証の必須化 | × | × | × | ○ |
|---|
| IP制限（管理画面・API） | × | × | ○ | ○ |
|---|
Enterpriseまで上げられない場合は、メンバー全員に2要素認証を設定してもらうよう社内ルールで決めておきます。IP制限はBusinessプランから使えます。
Q利用規約の「事故時の通知条項」はどこを読めばよいですか？
「利用しているクラウドサービスで障害や情報漏えいが起きた際、運営会社からいつまでに連絡が入るのか規約のどこを読めば分かるのか」と疑問を持つ人は多いはずです。サービス選定の段階で通知条件を把握しておかないと、万が一の初動対応で後手に回ってしまいます。
しかし、一般的なサービスの基本規約を眺めるだけでは、事故時の通知条件が見つからない場面が目立ちます。例としてStudioの利用規約を確認すると、第28条に連絡方法、第27条にサービスの中断や終了、第24条に損害賠償の規定が置かれていました。ただ、第28条の一般的な連絡方法の決まりからは、事故が見つかってから何日以内に知らせるのかは読み取れません。
こうした事故時の具体的な報告義務や期日を確かめる際は、基本規約とは別に交わされる「データ処理補足条項（DPA）」やセキュリティ関連の合意文書を確認するのが基本です。Google CloudやCloudflareのように、データ処理に関する契約文書の中にインシデント時の通知を定めた節を設けている事業者もあるので、利用するサービスの該当箇所を探して、通知の期限がどう書かれているかを読んでください。同じ文書には、契約終了時にデータを返すか消すかの決まりも置かれていることがあります。法令で保存が必要な場合などの例外もあるので、解約したらすぐ消えるとは考えないでください。
そこで、期限を知りたいときは、サポートに直接聞くのが早いですね。Studioの問い合わせ窓口はチャットで、担当者が対応するのは有料プランのプロジェクトです。回答は登録メールに届きます。回答のメールは消さずに残しておいてください。独自のセキュリティチェックシートへの記入は、有料のオプションとして受け付けています（Studioのセキュリティ対策）。
QSaaSを使うと、個人情報の取扱いを委託したことになりますか？
クラウドサービス上に顧客や取引先の個人データを保管した場合、法律上はすべて「個人データの取扱いを委託した」ことになるのでしょうか。実は、外部のサーバーへデータを預けたからといって、無条件に委託とみなされるわけではありません。
法令上の判断基準となるのは、保存されたデータの中に個人情報が含まれているかどうかではなく、サービスを提供する事業者がその個人データを取り扱うことになっているか否かです。個人情報保護委員会のFAQでも示されている通り、契約条項によって事業者がサーバー内の個人データを取り扱わない旨が明確に定められており、適切なアクセス制御によって事業者側から中身を閲覧できない仕組みになっている場合は、個人データの提供や委託には該当しません。
この場合、サービス提供者を委託先として監督する場面には当たらないと考えられるので、自社のケースがどちらに当たるかは同じFAQで確かめてください。ただし委託に当たらないとしても、サービスを利用する自社自身が果たすべき安全管理措置の一環として、アクセス権や設定を適切に管理する義務は引き続き残ります。
一方で、問い合わせ対応を外部へ委ねるなど事業者がデータそのものを操作・管理する前提のサービスであれば、明確に委託と評価されます。その際は委託先の選定段階で安全対策が実施されているかを事前確認し、契約後も取扱状況を把握するなどの適切な監督を行わなければなりません。契約には、双方が合意した安全管理措置と、委託先での取扱状況を委託元が把握できる仕組みを盛り込むのが望ましいとされています。フォーム回答のように事業者のサーバーで個人データを扱うサービスは、どちらに当たるかを契約書で確かめてください。
Q自前でサイトを持てば、チェックリストは不要になりますか？
不要にはなりません。確認する相手が、サービス事業者から自分と契約しているサーバー会社に変わるだけです。
自己ホスト型の運用では、CMSの管理画面だけでなくサーバー基盤そのものの安全対策を自前で担わなければなりません。WordPressのセキュリティ強化策に記載されている通り、WordPress本体の更新はもちろん、導入しているテーマやプラグインの更新を継続して行う必要があります。プラグインの脆弱性を放置すれば、不正アクセスや改ざんの標的になりかねません。PHPの更新も欠かせません。PHPのバージョンはサーバー会社が設定しているので、管理画面で自分で切り替えるか、サーバー会社に頼んで更新します。
さらに、万が一の障害や攻撃に備えた定期バックアップの取得や、問題発生時にサイトを正常な状態へ復旧させる手順の用意も利用者の責任範囲です。サーバーを任せているホスティング事業者がどのような安全対策を講じているか、自社の側から問い合わせて確認する姿勢が欠かせません。
Studioのようなサービスでは、こうした作業の多くを事業者が受け持っています。Studioは、利用しているプラットフォームやミドルウェア、ライブラリに脆弱性が見つかった場合に更新する方針を公開しているので、最新の内容は公式の案内で確かめてください。ただし、これは方針の説明で、個々の事案での対応や安全を保証するものではありません。自前運用へ切り替えることは、その保守管理の負担をすべて社内に引き戻す選択にほかなりません。チェックリストの項目は減らず、更新とバックアップが新たに加わります。
この内容をChatGPTで相談
