SaaS解約と移行の実務｜更新通知の期限、データ持ち出し、並行稼働

こんにちは、株式会社TIMEWELLの濱本 隆太です。

SaaSを解約して自社で作り直す、と決めたあとに最初にぶつかるのは、技術の壁ではありません。日付です。年単位で契約するSaaSには、自動更新の条項が入っていることがよくあります。止めるには、更新日より前の決められた日までに通知が要ります。その期限を1日でも過ぎれば、使わないつもりのサービスにもう1年分の料金を払うことになります。

乗り換えに慣れている会社は、そう多くありません。公正取引委員会が2022年に公表した報告書では、売上高50億円以上の事業者のうちIaaSやPaaSを使う548社に聞いたところ、過去10年にクラウド事業者を切り替えた経験があるのは15.7%でした。利用中のサービスが5〜10%値上がりしても、他のサービスやオンプレミスへ切り替えると答えたのは、「分からない」を除いた回答の14.1%にとどまります¹。SaaSだけを対象にした数字ではありませんが、解約と移行の段取りを社内で経験している人は少ない、と考えてよさそうです。

この記事は、高額なSaaSの解約と内製化を扱う5本シリーズの4本目です。解約すべきかどうかの判断は1本目の判断基準で、作った場合と使い続けた場合の総額は3本目の5年総額の試算で書きました。ここでは、やると決めたあとの段取りを、通知の期限、データの持ち出し、データの移行、並行稼働、終了後の削除確認の順に書き、最後に更新日から逆算したスケジュール表を付けます。

先にお断りしておきます。この記事の契約条項や法令の話は一般論です。契約の中身は事業者ごと、契約ごとに違います。個別の契約は、必ず自社の契約書と法務で確認してください。

解約通知の期限は「更新日の30日前」で決まる

大手SaaSが公開している基本契約を一つ例に取ります²。そこには、注文書に別段の定めがない限りサブスクリプションは1年ごとに自動で更新され、どちらかが契約期間の終わる30日以上前に書面（電子メールでも可）で通知したときに限って更新されない、と書かれています。解約の実務上の締め切りは、更新日ではなく、その30日前です。更新日が4月1日なら、期限は3月の頭に来ます。

同じ契約には、見落とされやすい条項があと二つあります。一つは料金の条項です。料金は実際の利用量ではなく購入したサブスクリプションの数に基づき、支払った料金は返金されず、契約期間の途中では購入した数量を減らせない、とされています。使っていないアカウントがあっても、期間中は払い続けるしかありません。

もう一つは、更新の条項の後半です。更新前の期間より数量が減ったり契約期間が短くなったりした更新では、前の期間の単価にかかわらず、更新時に価格が再設定されます。キャンペーン価格や一度限りの価格で契約していた場合も、更新時はその時点の定価になります。

この二つを合わせると、「全部やめる前に、閲覧用に数ライセンスだけ残しておこう」という段階的な縮小案が、思ったほど安くならない理由が見えてきます。数量を減らした時点で、それまでの値引きが外れるかもしれないからです。縮小して残すのか、完全にやめるのか。更新時の見積もりを取ってから比べるべきでしょう。

期限と一緒に確かめたいのが、通知の方法と相手です。書面が要るのか、メールでよいのか、管理画面から手続きするのか。契約上の通知先はどこか。販売代理店を通して買っている場合は、通知の相手が代理店になることもあります。どの方法を取るにせよ、相手に届いたことを後から示せる形で残してください。

もう一点、手元の契約書が最新とは限りません。利用規約で契約しているSaaSでは、事業者が規約を改定していることがあります。民法548条の4は、定型約款（不特定多数を相手にする取引のために事業者が用意した画一的な条項）について、変更が相手方の一般の利益に合う場合や、変更の必要性と変更後の内容の相当性などに照らして合理的な場合には、個別の合意なしに契約の内容を変えられると定めています。その代わり、効力が生じる時期を決め、変更の内容とあわせてインターネットなどで周知しなければなりません³。企業向けSaaSの規約が定型約款に当たるかは個別の判断になりますが、どちらにしても、読むべきは数年前に署名した版ではなく、いま有効な版と改定の履歴です。

データの持ち出しは、解約を決める前に一度試す

期限の次に効いてくるのが、データの持ち出しです。IPA（情報処理推進機構）の「中小企業のためのクラウドサービス安全利用の手引き」（2026年6月）は、確認項目の13番目に「利用終了時のデータを確保する」を置いています。確かめる中身として挙げられているのは、全データの返却やパソコンへのダウンロード、データの互換性と移植性、残留データの完全消去、別の利用者が再利用できないことの保証です⁴。

先ほどの基本契約の例では、契約の終了日から30日以内に要求すれば、顧客データを書き出したりダウンロードしたりできるようにする、とあります。30日を過ぎれば事業者にデータを保持する義務はなくなり、その後は消去されます²。30日あれば足りるように見えます。けれども、終了後に初めて書き出してみて、添付ファイルが入っていない、変更の履歴が落ちている、と気づいても、そのときにはもう元のシステムで業務を回すことはできません。

ですから、書き出しは解約を決める前に一度、本番のデータ全件で試してください。私が最低限確かめたいのは、次の五つです。

確かめること	見落とすと起きること
書き出した件数が、画面上の件数と一致するか	一部だけが書き出されても、欠けたことに気づけません
添付ファイルが一緒に出るか	本文だけが移り、証憑や図面が元のシステムに取り残されます
変更の履歴、コメント、承認の記録が出るか	監査や問い合わせのときに、経緯をたどれなくなります
利用者、組織、権限の情報が出るか	誰が何を見られるかを、新しいシステムで一から作り直すことになります
文字コード、日付の形式、項目の意味がわかるか	取り込むときに、文字化けや日付のずれが起きます

この表は公的なガイドから写したものではなく、私が確かめるべきだと考えている項目です。

書き出しで苦労する話は、珍しくありません。公正取引委員会の報告書には、利用者側からの指摘として「グループウェアはデータの持ち出しが難しく、一度使い始めてしまうとサービスを変更することが容易ではなく、値上げに応じざるを得ない場合があった」という声が載っています。IaaSとPaaSの利用者へのアンケートでも、乗り換えを難しくする要因として、データを取り出す費用や、新旧のサービスでデータの形式が違って加工が必要になることを挙げる利用者がいました¹。

国の方針も、この点を入口で確かめるよう求めています。デジタル庁の標準ガイドラインDS-310は、データの移行性が担保され、合理的な価格体系が公開されているといった条件を満たすクラウドサービスを選ぶことで、ベンダーロックインを避けるよう定めています⁵。本来は契約する前に確かめておくことです。とはいえ、いま解約を考えている方にとっては、これから確かめるしかありません。

EUに拠点があり、そこでSaaSを契約している会社には、使える権利がもう一つあります。EUデータ法は2025年9月12日から適用されていて、PaaSとSaaSの提供者に、オープンなインターフェースを用意し、少なくとも一般的に使われる機械可読な形式でデータを書き出せるようにすることを求めています。2027年1月12日からは、データの転送料を含む乗り換えの費用を請求できなくなります⁶。法律事務所の解説によれば、顧客が最長2か月の予告で乗り換えを始められ、予告期間の終わりから最長30日以内に移行を終えるといった条項を契約に入れることも求められています⁷。ただし対象はEU域内の顧客に提供されるサービスで、日本の本社が結んだ契約にそのまま当てはまるとは限りません。適用の有無は法務で確かめてください。

移行するデータは絞り、終盤の手戻りを計画に入れる

書き出したデータを、新しいシステムにどう入れるか。ここではIPAの「システム再構築を成功に導くユーザガイド 第2版」が参考になります。SaaSからの移行を直接扱った資料ではありませんが、データ移行の計画について書かれていることは、そのまま当てはまります⁸。

ガイドはまず、データ移行の計画の検討が遅いと、プロジェクトの全体計画やコストにまで大きな影響が及ぶおそれがあると書いています。移行対象やレイアウトなど事前に確かめる観点が多く、データクレンジング（不正な値や重複を正す作業）も要るので、準備に時間がかかるからです。そのうえで、問題が起きやすい観点として、移行対象の整理、レイアウトの確認、データクレンジング、文字コードの対応づけ、移行方法の選定、移行結果の確認の六つを挙げています。

私がいちばん効くと思っているのは、最初の「移行対象の整理」です。ガイドは、全部を移行すると作業量が増えて時間とコストがかかるので対象は絞ったほうがよいとし、例として、稼働期間で3年以上前のデータやトランザクションデータは捨てる、といった移行範囲の方針をはっきりさせることを挙げています。SaaSを長く使っていると、何年分もの履歴が積み上がっています。そのすべてを新しいシステムで日々使うわけではありません。直近の数年分と、いまも動いている案件だけを移し、古いものは書き出したファイルのまま読み取り専用の保管場所に置いておきます。これだけで、変換の手間も照合の手間も大きく減ります。ただし、法令や社内規程で保存期間が決まっている記録については、保管場所に置いたものをいつでも探して取り出せるかを確かめておく必要があります。

もう一つ、ガイドは「データ移行による問題は開発の終盤で顕在化するため、解消期間も計画に盛り込むべき」と書いています。本物のデータを流して初めて、想定していなかった値や、画面からは見えなかった項目の使われ方が出てくるからです。移行のリハーサルは一度で済むと考えず、少なくとも二回は回す前提で日程を組んでください。

移行の難しさは、統計にも表れています。IPAの「DX動向2025」で、内製化を進めている日本企業334社に内製化の課題を尋ねたところ、「人材の確保や育成が難しい」が82.3%で突出し、「外部開発したシステムの内製化への移行が難しい」も19.5%ありました⁹。移行は、内製化の中でも人手と経験を食う工程です。社内だけで回すのが難しければ、この工程に限って外の手を借りるのは合理的な判断だと思います。

並行稼働は、払い終えた最後の契約期間の中で終える

新しいシステムが動いたら、しばらくは古いSaaSと両方で同じ業務を回し、結果を突き合わせます。並行稼働です。IPAの再構築ガイドは、リリース後のリスク対策の例として並行稼働を挙げ、「一定期間、現行システムと新システムの両方で同一オペレーションを実施し、故障を洗い出す」ものと説明しています。注意点として挙げられているのは二つ。利用部門の負担が増えるので、利用部門がどれだけ並行稼働を許容できるかを確かめること。そして、現行システムのEOL（提供終了）やEOS（サポート終了）の期限内に実施できるかを確かめることです⁸。

SaaSの場合、この「現行システムの期限」は契約の終了日そのものです。ここから、私が勧めている段取りが出てきます。並行稼働は、すでに払っている最後の契約期間の中で行い、解約の通知期限より前に結論を出す、というものです。例に挙げた契約のように、料金が利用量ではなく購入した数で決まり、返金もされないのなら、その間に古いSaaSを使い続けても追加の費用はかかりません。反対に、並行稼働の途中で通知期限が来てしまうと、新しいシステムの出来を見ないまま解約を通知するか、念のためにもう1年更新するかの二択になります。どちらも避けたい選択です。

どのくらいの期間やるべきかについて、公的な目安は見当たりませんでした。私の見立てでは、業務の周期を一回りさせるのが最低線です。月末の締めがある業務なら締めを一回、四半期の集計があるならその集計を一回、新旧の両方で通します。日々の入力は正しく動いているのに、締めの処理だけが違う結果を出す、ということが珍しくないからです。

期間より先に決めておきたいのが、やめる基準です。再構築ガイドは、テストの完了基準があいまいなままだと完了を判断できず、いつまでも終わらない事態に陥ることがあり、新旧の結果を比べるテストで特にそうなりやすいと指摘しています。だから、業務を続けられることを示す定量的な基準を決め、実施の前に関係者と合意しておくべきだ、としています⁸。たとえば「締めの金額が新旧で一致する」「同じ期間の件数が一致する」「差が出たときは原因を説明できる」といった基準を、並行稼働を始める前に書いておきます。利用部門にとっても、二重入力がいつ終わるのかが見えていることは、負担を引き受ける理由になります。

付録：更新日から逆算する解約・移行のスケジュール

ここまでの話を、更新日から逆算した日程にまとめます。通知期限を「更新日の30日前」とした場合の一例で、各工程の長さは業務の量や契約によって変わります。通知期限が違う契約なら、そのぶん表の日付をずらしてください。

時期（更新日を基準）	やること	主な担当
6か月前	契約書、注文書、いま有効な利用規約の収集。更新日、通知期限、通知の方法と相手、データ返却の条項の確認。データの棚卸しと、移すものと保管だけするものの仕分け	購買、法務、情シス
5か月前	本番データ全件での書き出しの試験と、件数、添付、履歴、権限の照合。移行先の試作の開始	情シス、開発
3か月前	1回目の移行リハーサルと不整合データの修正。並行稼働の完了基準の決定と、利用部門との合意	情シス、利用部門
75日前〜40日前	並行稼働（月末の締めなど業務の周期を一回り）。2回目のリハーサルで取り込み手順を確定	利用部門、情シス
40日前	完了基準による判定と、解約するかどうかの社内決定。縮小して更新する場合の見積もりとの比較	経営、情シス、購買
通知期限（30日前）の数日前まで	決められた方法での通知と、届いたことの記録	購買、法務
更新日の前日まで	最終の書き出しと取り込み、利用者の切り替え	情シス
終了後30日以内（例の契約の場合）	書き出し漏れの最終確認。この期間を過ぎたら取り直せない前提で動くこと	情シス
終了後	残留データの削除の確認。連携の停止、アカウントと認証設定の削除、請求停止の確認	情シス、経理

表を見て、次の更新日まで6か月もない、という方もいると思います。その場合、無理に今期で止めるより、次の更新日に狙いを定めて書き出しの試験から始めるほうが、結局は安くつくことが多いはずです。今期の期限に間に合わせようとして並行稼働を削れば、そのしわ寄せは切り替えたあとの利用部門に来ます。

表の最後の二行は、忘れられがちな仕事です。IPAの手引きが利用終了時の確認項目に残留データの完全消去と、別の利用者が再利用できないことの保証を入れているのは、解約すればデータが自然に消えるとは限らないからです⁴。例の契約のように、猶予期間のあとに消去すると定めている事業者もありますが、いつ消えたのかを利用者が確かめる方法は契約によって違います。削除の証明を出してもらえるのか、出せないならどう確かめるのか。通知を送る前に聞いておきたいところです。

情報セキュリティの規格も、この工程を見るようになりました。ISMS（情報セキュリティマネジメントシステム）の認証基準であるJIS Q 27001:2023（ISO/IEC 27001:2022）では、附属書Aの管理策に「8.10 情報の削除」が新しく加わっています¹⁰。ISMSを運用している会社にとって、SaaSの解約はこの管理策の記録を残す場面でもあります。あわせて、古いSaaSにつながっていたシングルサインオンの設定、APIの鍵、他のシステムからの自動連携も止めておきます。連携が残っていると、他のシステムが解約したはずのサービスへデータを送ろうとし続け、原因のわかりにくいエラーを生みます。

当社のFDEでできること

当社はFDE（Forward Deployed Engineer）のサービスを提供しています。FDEは、発注者の現場に入り、課題を動くソフトウェアにするエンジニアのことです。SaaSの解約と移行は、FDEの仕事の進め方がそのまま当てはまる工程だと考えています。

具体的には、上の表のうち、書き出しの試験から最終の取り込みまでの技術的な工程を一緒に進めます。解約するかどうかの判断と、事業者への通知は貴社が行います。本番データを全件書き出して件数や添付を照合する仕組みを作り、個人情報などを伏せたデータで移行先の試作を動かし、変換とクレンジングの処理を書き、並行稼働では新旧の結果を自動で突き合わせる仕組みを置きます。並行稼働の完了基準を利用部門と一緒に数字で決めるのも、この工程でのFDEの仕事です。期間は45日から90日を目安に最初に区切り、終わりの条件を決めてから始めます。

移行先のシステムをどこにどう置くかは、5本目の業務アプリを自社クラウドに置く設計で書いています。そもそもどの業務を内製の候補にするかは、2本目の見分け方が入口です。FDEの進め方の全体は、FDEのサービスページにまとめています。

受託開発との違い

移行を外に頼むとき、気をつけたいことがあります。SaaSをやめる目的の一つは、特定の事業者に頼らなくても業務が回る状態をつくることのはずです。それなのに、移行を請けた会社にしか直せない仕組みが残れば、頼る相手が入れ替わっただけになります。

当社がFDEを受託開発と分けて考えているのは、この点です。受託開発では工数が売上になるので、並行稼働が延びるほど、手戻りが増えるほど、請ける側の売上は増えます。当社は費用を工数の積み上げではなく期間で決め、延びるほど得をする契約にはしません。工数は、次の案件を速くするための投資だと考えています。書き出しの照合や新旧の突き合わせのように他の会社でも使える仕組みは、当社製品の部品として育てて次の案件で使い、貴社だけの手順は貴社の設定として残します。そして、終わり方を最初に決めます。移したシステムを貴社の担当者が自分で直し、データを自分で書き出せるようになったところで、当社の仕事は終わりです。

当社の実践と限界

正直に書きます。まず、契約の交渉と法的な判断は当社の役割ではありません。更新日や通知期限を契約書から拾って日程表にするところまでは手伝えますが、条項をどう読むか、事業者とどう交渉するかは、貴社の法務と、必要なら弁護士の仕事です。解約の通知を出すのも、契約の当事者である貴社です。

次に、取り出せないデータは当社にも取り出せません。SaaSの書き出し機能やAPIが対応していない情報は、画面から手で写すか、諦めるかを選ぶことになります。書き出しの試験を早くやるべき理由の一つは、この判断を早く下すためでもあります。

移行の作業で当社が個人データに触れる場合、当社は個人データの取扱いの委託先になります。個人情報保護法25条は、委託する側に、委託先を必要かつ適切に監督するよう求めています¹¹。当社はISO/IEC 27001の認証を取得していますが（登録範囲はAIテクノロジーを活用したSaaSプロダクトの企画・開発・提供）、それで貴社の監督の義務がなくなるわけではありません。委託の契約と、触れるデータの範囲は、作業の前に決めます。

すべてのSaaSを解約すべきだとも考えていません。会計や給与のように、法令や会計ルールの変更に追いつき続けなければならない業務は、SaaSやパッケージに任せたほうが合理的な場合が多いと考えています。この記事の手順も、公的なガイドと公開されている契約条項から組み立てたもので、特定の顧客の事例ではありません。最後に容量の話です。小さな会社なので、同時に入れる現場の数には限りがあります。

まとめ

SaaSの解約と移行は、更新日から逆算して組みます。押さえどころは四つです。

• 通知の期限は更新日そのものではなく、その前にあります。例の契約では30日前で、数量を減らした更新は単価が再設定されます
• データの書き出しは、解約を決める前に本番の全件で試します。終了後の猶予は、例の契約で30日しかありません
• 移すデータは絞り、終盤に問題が出る前提でリハーサルを二回組みます
• 並行稼働は、払い終えた最後の契約期間の中で、先に決めた基準で終えます

どれも地味な作業です。ただ、SaaSをやめて浮くはずのお金は、通知期限を一度逃しただけで1年先に延びます。まずは手元の契約書を開いて、更新日と通知期限をカレンダーに書き込むところから始めてみてください。

解約から移行、並行稼働までを一緒に進める相手を探している方は、FDEのサービスページをご覧いただくか、FDEの個別相談でお話ししましょう。そもそも解約すべきかを確かめ直したい方は、シリーズの1本目（判断基準）に戻ってください。

Footnotes

1. クラウドサービス分野の取引実態に関する報告書（公正取引委員会、2022年6月28日）。切替え経験と価格上昇時の対応は49〜50ページ（IaaS利用者419社とPaaS利用者129社のアンケート、2021年7〜8月実施）、切替えを困難にする要因は52ページ、グループウェアの値上げに関する利用者の指摘は92ページ。報道発表資料 ↩ ↩²

2. 大手SaaS事業者が公開している基本契約（英語版は2026年9月1日版、日本語版は2026年6月1日最終更新）の料金、契約期間、顧客データの返却に関する条項による。特定の事業者を評価する目的ではないため、事業者名とリンクは省略しています。契約条件は事業者と契約ごとに異なります ↩ ↩²

3. 民法（明治二十九年法律第八十九号）第548条の2（定型約款の合意）、第548条の4（定型約款の変更）。e-Gov法令検索 ↩

4. 中小企業のためのクラウドサービス安全利用の手引き（IPA、2026年6月）。確認項目「13. 利用終了時のデータを確保する」（27ページ） ↩ ↩²

5. DS-310 政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針（デジタル庁、2025年5月27日）。「3.3 ベンダーロックインについて」（12ページ） ↩

6. Data Act explained（European Commission）。適用開始日、PaaSとSaaSのデータ書き出し、乗り換え費用の廃止は同ページによる ↩

7. EU Data Act: Significant New Switching Requirements Due to Take Effect for Data Processing Services（Latham & Watkins、2025年8月19日）。予告期間と移行期間の上限は同解説による（条文番号は本稿では未確認） ↩

8. システム再構築を成功に導くユーザガイド 第2版（IPA、2018年2月）。テストの完了基準は114ページ、表3.9「リスク対策の例」（並行稼働）は115ページ、3.8「データ移行の計画」と表3.11は119〜121ページ ↩ ↩² ↩³

9. DX動向2025（IPA、2025年6月）。図表2-16「内製化を進めるにあたっての課題」（45ページ、2024年度調査、内製化を進めている日本企業 n=334） ↩

10. ISMSユーザーズガイド（JIPDEC、JIP-ISMS111-4.0、2025年3月31日）。表A-2「追加の管理策」（74ページ） ↩

11. 個人情報の保護に関する法律（平成十五年法律第五十七号）第25条（委託先の監督）。e-Gov法令検索 ↩