メニュー
IT企業・Web事業のM&A・会社売却・事業承継を、契約・技術資産・顧客移行・社員継続・アカウント権限・譲渡条件の整理から最適な相手先探しまで支援します。譲渡企業様の手数料0円。
IT M&A総合センター
  • はじめてのIT企業M&A|無料資料
  • IT M&Aとは|IT企業・Web事業のM&A売却で確認すべきポイント
  • M&A事例
  • コラム
  • IT M&A総合センターとは
☰メニュー
トップIT M&AとはセンターについてM&A事例コラム譲渡の無料相談買収ニーズを登録お問い合わせ運営会社プライバシーポリシー
IT M&A総合センター
  • はじめてのIT企業M&A|無料資料
  • IT M&Aとは|IT企業・Web事業のM&A売却で確認すべきポイント
  • M&A事例
  • コラム
  • IT M&A総合センターとは
  1. ホーム
  2. コラム
  3. IT事業 カーブアウト M&A|TSAとDay 1でクラウド・データ・契約・社員を切り離す実務

IT事業 カーブアウト M&A|TSAとDay 1でクラウド・データ・契約・社員を切り離す実務

2026 10/07
コラム
2026年8月22日2026年10月7日
IT事業の切り出しを伴うM&Aで、移行支援契約と取引完了初日の分離計画を確認する経営者とIT責任者

IT事業 カーブアウト M&Aの成否を分ける結論は、譲渡対象資産のリストだけでは事業を動かせない、という事実を早期に認めることです。対象プロダクトが親会社のメール、ID、クラウド契約、請求、監視、ヘルプデスク、人事、知財、顧客窓口へ依存していれば、法的に移すものとDay 1に運用上必要なものの間に隙間が生まれます。その隙間を見つけ、移行またはTSAで橋渡しし、終了証拠まで定義するのが分離設計です。

Day 1は全てを完全分離する日とは限りません。顧客サービス、入金、従業員の就業、脆弱性対応などを止めない最低条件を満たし、残りは期限・料金・サービスレベル・責任・Exitを定めた移行サービスで暫定運用する選択があります。ただしTSAを曖昧な「従来どおりの支援」にすると、提供範囲、追加作業、障害指揮、データ利用、費用、終了判定で対立します。

本稿では特定の会社分割、事業譲渡、株式譲渡を推奨せず、法的スキームは案件弁護士・税務専門家へ確認する前提で、売り手経営者が事実を整える方法を扱います。分離ペリメーターマップ、Day 1判定表、TSAサービスカタログ、顧客・ベンダーWave、Exit証明パックを使い、契約、データ、ID、クラウド、開発基盤、社員、料金を一つの計画へつなぎます。

目次

IT事業 カーブアウト M&Aの結論

  • 法的譲渡対象と運用依存を別々に列挙し、事業能力ごとにOwner・Buyer・Shared・Retireを決める。
  • Day 1必須、TSA、後続移行、廃止の四区分を停止影響・期限・代替・安全性から判定する。
  • 顧客契約、請求、データ、ID、クラウド、Git、鍵を同じ移行Waveと受入証拠へ結ぶ。
  • TSAはサービス範囲、対象外、時間帯、SLA、料金、変更、事故、監査、再委託、Exitを一行ずつ定義する。
  • TSA終了は予定日だけで決めず、受入試験、アクセス廃止、鍵更新、データ削除、請求停止を証明する。

目次

  1. カーブアウトの法的スキームとDay 1・TSA・最終分離の用語をそろえる
  2. 人・契約・データ・アプリ・インフラ・知財・財務を分離ペリメーターへ載せる
  3. Day 1必須・TSA・後続移行・廃止の四区分で優先順位を決める
  4. 顧客・ベンダー契約の移管Waveと売掛・前受・返金・請求切替を連動させる
  5. 個人データをDD開示・承継後利用・交渉不成立時削除まで管理する
  6. Microsoft 365・Google Workspace・IdP・SSOを業務停止なしで再発行する
  7. AWS・Azure・Google Cloudを組織・請求・ネットワーク・鍵・データから分離する
  8. Git・CI/CD・コンテナ・署名鍵・ドメイン・DNS・証明書を一体で切り替える
  9. 顧客向けSaaSの可用性・RTO/RPO・凍結窓・切戻しをDay 1へ組み込む
  10. TSAサービスカタログへ範囲・除外・SLA・料金・データ・Exitを記す
  11. TSAの変更要求・インシデント・監査・再委託・データ漏えいを統合管理する
  12. 週次分離管理で依存関係・決定・費用・リスク・証拠を一つにする
  13. 社員の説明・承諾とTSA Exit証明を最終分離の同じゲートへ置く
  14. クロージングのGo・条件付きGo・延期・切戻しを証拠で判定する
  15. 分離ペリメーター・Day 1・TSA・Exit統合管理表
  16. TSAサービスカタログとExit証明パックの必須フィールド
  17. 売却前180日から最終分離までの実行ロードマップ
  18. 売り手CEO・CIO・法務・人事・経理が答える12のDay 1質問
  19. 一次資料の読み方と更新管理
  20. 関連するIT M&A実務ガイド
  21. よくある質問
  22. 免責事項と専門家へ引き継ぐ境界

カーブアウトの法的スキームとDay 1・TSA・最終分離の用語をそろえる

カーブアウトは実務上の呼称であり、それ自体が会社法上の一つの手続を意味するわけではありません。株式譲渡、事業譲渡、会社分割、新会社化などで資産・契約・債務・労働関係の承継効果と必要手続が変わります。一方、運用担当が使うDay 1やTSAも法定の標準定義ではないため、案件内の定義が必要です。

カーブアウトを法定手続名として扱わない

誤認・失敗 実務上の修正
カーブアウトを法定手続名とする 実際に採用する取引スキームと承継効果を契約書・専門家見解で特定します。
Day 1を全分離完了と同義にする 最低運用、TSA利用、後続Wave、最終分離を別マイルストーンにします。
TSAを単なる善意の支援とする サービス記述、料金、責任、変更、終了を契約・運用へ落とします。

法的効力、最低運用、請求・データ切替、各TSA終了、最終分離の日時と完了条件を区別できますか。

まず法的スキームを弁護士・税務専門家と検討しつつ、事業継続に必要な機能を並行して洗い出します。Day 1を支配・譲渡効力と最低運用の開始日、TSA Exitを特定サービスの受入完了、最終分離を全共有依存の解消と定義するなど、用語・基準日・時刻・タイムゾーンを一枚にします。

法的スキームを決める前に事業継続条件を洗い出す

  1. 1. 候補スキームを比較する:対象会社株式、事業、会社分割、新設会社等について、承継対象、相手方手続、税務、期間を専門家と表にします。 運用設計が法的効果と矛盾しないようにするためです。
  2. 2. 重要日を分ける:契約締結、前提条件充足、クロージング、支配移転、システム切替、請求切替、TSA終了を別日として定義します。 一つのDay 1という言葉に複数の時点が混ざるのを防ぎます。
  3. 3. 運用最低条件を列挙する:受注、提供、認証、監視、請求、入金、給与、事故対応など、初日に止められない能力を決めます。 資産の移転だけでは事業継続を確認できないためです。
  4. 4. 専門判断の境界を残す:記事やプロジェクト表で法的結論を断定せず、質問、事実資料、担当専門家、回答日、未解決を記録します。 後から前提が変わったとき再検討できます。

スキーム比較表と依存関係図を突き合わせる

証拠・フィールド 確認できること 注意信号
スキーム比較表 承継効果、同意、承認、税務、期間の論点を確認する。 実務名称だけで法的手続が記載されていない。
重要日カレンダー 効力、切替、通知、支払、サービス終了を区別する。 タイムゾーンと業務開始時刻がない。
能力依存図 初日に必要な業務と人・システム・契約を示す。 資産一覧と業務責任者がつながらない。
専門家質問ログ 法務・税務・労務判断の前提と回答を残す。 口頭の結論だけで条文・契約・事実の参照がない。

架空例:クロージング日と請求切替日が異なったケース

架空のSaaS事業Aは月中に事業譲渡する計画でしたが、決済代行と請求システムの切替は翌月初までできませんでした。売り手はDay 1を一語で処理せず、法的効力日、顧客サービス責任の開始、売り手による暫定請求、入金精算、買い手請求開始を別イベントにしました。弁護士・税理士が契約と対価・税務を確認し、運用チームは例外顧客の照合証拠を残しました。

人・契約・データ・アプリ・インフラ・知財・財務を分離ペリメーターへ載せる

対象製品名だけで切出し範囲を定めると、共通社員、親契約、共有データベース、基盤アプリ、ネットワーク、商標・ドメイン、売掛金・前受金などが抜けます。反対に共有資産を全て譲渡対象へ入れると、残存事業が動かなくなる可能性があります。境界は事業能力から必要要素へ展開します。

契約一覧と構成管理台帳で境界を検証する

分離ペリメーターマップ
事業能力と七要素の状態を一枚で確認する。 注意信号はセルが空白のまま対象外と解釈される。
資産・構成管理台帳
実物ID、所有者、所在、利用部門を示す。 注意信号は同名システムの本番・検証・旧環境が混在する。
契約・知財一覧
利用根拠、譲渡・共有・終了条件を確認する。 注意信号は契約当事者とシステム利用者が違う。
財務残高照合
売掛、前受、未払、固定資産等を境界へ結ぶ。 注意信号は事業損益だけで貸借項目がない。

行を受注、提供、サポート、請求、開発、セキュリティ等の事業能力、列を人・契約・データ・アプリ・インフラ・知財・財務とし、各セルをOwner、Buyer、Shared、Retireへ分類します。SharedはTSA候補か複製・再構築の対象であり、放置状態ではありません。

  • 事業能力を分解する:顧客獲得から契約終了までの業務を、責任者、利用者、入力、出力、停止影響とともに並べます。 組織図だけでは実際の仕事の流れが見えないためです。
  • 七列の要素を当てる:各能力に必要な人、契約、データ、アプリ、基盤、知財、債権債務を具体IDで紐付けます。 機能と資産を双方向に確認できます。
  • 四状態を決める:売り手残置、買い手移管、期間共有、廃止を選び、共有には提供主体とExit案を付けます。 未決セルが隠れた依存として残ることを防ぎます。
  • 境界変更を統制する:新発見、交渉、同意拒否、システム制約による変更を版、理由、影響、承認者付きで更新します。 契約別紙と実行計画の範囲ずれを減らします。

資産名だけの切出しリストを作らない

  • 譲渡資産リストから始めて終える:顧客へ価値を届ける能力から逆算し、欠ける依存を発見します。
  • Sharedを永久状態にする:TSA、複製、代替、廃止のExit案と費用を必ず付けます。
  • 残存事業の影響を見ない:売り手側が引き続き使う共有機能と容量・権限・費用も評価します。

売上を生む主要能力の各行で七列全てに状態、責任者、移行方法、Exitが入っていますか。

Day 1必須・TSA・後続移行・廃止の四区分で優先順位を決める

全てをクロージング前に分ける計画は安全に見えますが、変更量が増えて障害・顧客混乱・証拠不足を招くことがあります。反対にTSAへ寄せ過ぎると、売り手の共有環境、担当者、費用へ長期間依存し、Exitが難しくなります。各能力を客観的な停止影響と代替可能性で振り分けます。

評価軸は顧客・売上停止、法令・契約期限、個人・機密データ、安全性、代替手段、移行所要、切戻し、売り手残存事業への影響です。点数は自動結論ではなく、Day 1必須、TSA、後続Wave、廃止を経営者が比較する共通言語として使います。

停止影響からDay 1・TSA・後続・廃止へ振り分ける

  1. 1. 停止シナリオを描く:各能力が1時間、1日、1週間止まった場合の顧客、契約、入金、データ、安全、従業員への影響を記します。 抽象的な重要度より優先順位が具体化します。
  2. 2. 代替と切戻しを確認する:手作業、旧環境継続、別ベンダー、読み取り専用、再試行などの代替と限界を試します。 移行失敗時の事業継続を判断できます。
  3. 3. 四区分へ振り分ける:初日必須、期限付きTSA、後続移行、廃止のどれかを選び、理由と承認者を残します。 未決をTSAへ無意識に押し込まないためです。
  4. 4. 依存関係で順序を補正する:後続機能でも前提となるID・ネットワーク・契約があれば先行Waveへ移します。 単体の点数だけでは実行順が決まらないためです。
証拠・フィールド 確認できること 注意信号
Day 1判定表 停止影響、期限、代替、安全、所要を比較する。 総合点だけで根拠コメントがない。
業務継続テスト 代替手段と最大継続時間を実測する。 手順書はあるが権限・データが不足する。
依存関係グラフ 前提サービスと後続作業の順序を示す。 循環依存がTSA契約後に判明する。
経営判断記録 区分、理由、残存リスク、承認日を固定する。 担当者が独自に優先度を変更する。

全項目をクロージング前移行に寄せない

  • 全システムをDay 1対象にする:停止影響と変更リスクを比較し、期限付きTSAや後続Waveを選びます。
  • 移行困難だからTSAを無期限にする:Exit案、費用増加、担当維持、最長日、代替策を開始前に決めます。
  • スコアだけで自動判定する:法務、顧客、セキュリティ、財務の定性的な拒否条件を経営者が確認します。

各区分について、止まった場合の影響、代替可能時間、前提依存、経営承認を説明できますか。

顧客・ベンダー契約の移管Waveと売掛・前受・返金・請求切替を連動させる

顧客契約、クラウド・SaaS・外注等の調達契約は、取引スキームや契約条項により通知・承諾・再契約・債権譲渡・精算が必要になることがあります。契約移管と請求口座変更を別チームが扱うと、サービス提供主体、請求者、入金先、返金責任、前受残高が不一致になります。

契約上の主体、サービス責任、請求者、入金先、前受・返金責任が顧客ごとに同じ基準日へそろっていますか。

契約原本と債権・前受残高を同じ顧客IDで照合する

証拠・フィールド 確認できること 注意信号
契約移管Wave表 相手方、要否、期限、依存、代替、証跡を示す。 営業上の重要度だけで法的期限がない。
契約原本索引 条項・別紙・変更履歴・現行版を確認する。 署名済み版とCRM要約が違う。
顧客別残高表 売掛・前受・返金等を基準日で照合する。 総勘定元帳合計と顧客明細が一致しない。
請求・入金試験 請求者、税、口座、消込、顧客受領を検証する。 テスト請求が本番顧客へ誤送信される。

顧客・ベンダーを重要度、同意要否、期限、技術版、請求サイクルでWave化します。法的な契約上の地位移転、金銭債権の取扱い、システム上の請求切替を区別し、契約原本と専門家確認に基づいて一件ごとの完了証拠を定めます。

顧客・ベンダーをWaveへ分けて請求切替まで追う

  • 文書階層を集める:基本契約、注文書、約款、SLA、変更合意、セキュリティ別紙、請求条件を顧客IDへ束ねます。 一つの契約だけでは譲渡・通知・請求条件を落とすためです。
  • 同意と通知を分類する:契約上の地位、債権、債務、再委託、支配変更、データ、窓口の論点を弁護士と区別します。 同意不要という一語を全処理へ一般化しないためです。
  • 財務残高を切替日へ割る:売掛、前受、契約負債、未払、返金、クレジット、税を顧客・期間・履行へ対応させます。 入金とサービス責任の二重・空白を防ぎます。
  • Wave完了を照合する:同意・通知、マスター更新、テスト請求、入金、会計仕訳、顧客受領を一つのチェックへします。 メール送付だけの完了判定を避けます。
誤認・失敗 実務上の修正
全顧客へ同じ文面を一斉送信する 契約、関係、データ、請求サイクルに応じ、弁護士・営業がWave別に承認します。
債権譲渡と契約移管を同一視する 法的対象と対抗要件・承諾等を専門家へ個別確認します。
入金口座変更を経理だけで行う 顧客周知、詐欺対策、認証、テスト、消込、例外処理を連動させます。

架空例:年払い前受のサービス責任と現金が分かれたケース

架空のD事業には譲渡前に受領した年払い顧客がいました。売り手と買い手は現金残高だけを移すのではなく、残存サービス期間、返金・クレジット責任、消費税、SLA、契約移管日を顧客単位で整理しました。税理士・弁護士が取扱いを確認し、買い手ERPへの前受残高、顧客通知、次回請求、仕訳の一致をWave完了証拠にしました。

個人データをDD開示・承継後利用・交渉不成立時削除まで管理する

顧客、利用者、従業員、応募者、問い合わせ、ログに含まれる個人データは、取引検討から事業承継、TSA、最終削除まで複数主体・環境を移動し得ます。事業承継に関する制度上の取扱いを、無制限なデータ提供や新目的利用の根拠として扱うことはできません。

事業承継を無制限なデータ利用の根拠にしない

  • 事業承継だから全データを移せると断定する:利用目的、必要性、安全管理、契約、最新ガイド・Q&Aを個別確認します。
  • 仮名化と匿名化を同一視する:採用する加工、復元可能性、照合情報、利用範囲を専門家と明示します。
  • 本番だけ削除する:スナップショット、ログ、検索索引、分析環境、端末、VDR、バックアップを含めます。

データ集合ごとに管理主体、利用目的、取得経緯、移転・複製の目的、開示先、保存期間、安全管理、返還・消去、承継後の利用を整理します。具体的な適法性と通知・同意等の要否は、最新の個人情報保護委員会資料と案件事実を弁護士・個人情報保護責任者へ示して確認します。

判断・作業 進め方 根拠資料 読み方
データ集合を分ける 本番顧客、マーケティング、従業員、採用、ログ、バックアップ、DDサンプルを目的・主体別に登録します。 データベース名だけでは個人の種類と利用目的が分からないためです。 データ処理記録 集合、目的、主体、場所、受領者、期間を示す。 注意信号は個人データを含むログとバックアップが対象外。
処理案を選ぶ 移転、複製、匿名・仮名化、限定閲覧、残置、返還、消去を集合・段階ごとに決めます。 全面コピーを標準にしないためです。 DD開示台帳 質問、必要性、最小化、閲覧、削除を確認する。 注意信号は候補ごとのコピー所在が分からない。
TSA中の責任を切る アクセス承認、問い合わせ、訂正、事故、委託先、削除、ログの実施主体と指揮を定めます。 設備提供者と利用判断者が違う場合の空白を防ぎます。 権限・操作ログ TSA期間のアクセスと異常を検証する。 注意信号は共有管理者IDで利用者を特定できない。
不成立・Exitを証明する 候補者のアクセス停止、コピー返還・消去、バックアップ失効、例外保管、証明書を期限付きで追跡します。 契約条項だけで実際の削除を確認しない誤りを避けます。 削除・返還証明 本体、派生物、バックアップ、例外を記録する。 注意信号は削除完了というメールだけで対象がない。

各データ集合について、誰が何の目的でどこに保持し、取引不成立・TSA Exit時に何をどう消すか説明できますか。

Microsoft 365・Google Workspace・IdP・SSOを業務停止なしで再発行する

メールと共同作業基盤はユーザー認証だけでなく、共有メール、カレンダー、チャット、ファイル、端末管理、SaaS SSO、監査ログ、サービスアカウント、復旧連絡先へ広がります。ドメイン移管やテナント分離の一回の切替として扱うと、隠れた認証依存が止まります。

人とサービスのIDを分けて二段階で再発行する

作業 実施内容 判断理由
ID母集団を作る 人、共有、管理、サービス、API、ゲスト、退職予定をHR・ディレクトリ・SaaSから照合します。 一つのユーザーCSVでは非対話型IDを落とすためです。
新旧IDを対応させる 旧UPN・メール・社員IDと新テナントIDを結び、所有者、MFA、端末、権限を再承認します。 権限コピーだけで本人性を失わないためです。
並行期間を設計する メール転送、共同編集、会議、SSO、復旧、監査の新旧経路と最長期間を決めます。 一括切替の失敗時に業務を戻せます。
旧信頼を廃止する 連携、トークン、セッション、転送、ゲスト、管理委任、復旧先をExit試験で無効化します。 見えるアカウント削除だけではアクセスが残るためです。

人のID、特権ID、サービスID、外部ゲストを分け、Day 1に必要な並行運用と最終的な信頼関係廃止を二段階で設計します。本人確認、MFA、端末、グループ、メールルーティング、SSO、監査、緊急アクセスを利用者ロールごとに受入試験します。

認証ログと緊急アクセス訓練で切替を確認する

ID対応台帳
新旧主体、ロール、所有者、状態を確認する。 注意信号は退職・休職・委託終了者が有効。
SSO依存一覧
各SaaSの認証方式、属性、緊急ログインを示す。 注意信号はIdP切替後にローカル管理者が不明。
認証・監査ログ
本人確認、MFA、特権操作、異常を検証する。 注意信号はログ保存が切替日に途切れる。
Exitアクセス試験
旧ID・トークン・連携で入れないことを確認する。 注意信号は画面上の無効表示だけで実試験がない。

「ユーザー数だけを移行分母にする」という進め方は採りません。サービスID、共有ID、ゲスト、特権、API認証を別母集団で追加します。 「旧メールを無期限転送する」と判断する前に、顧客・契約上の必要期間と機密リスクを比較し、終了日と例外を設けます。 「管理権限を丸ごと複製する」だけでは説明が足りません。新組織の職務、最小権限、二者承認、緊急手順に基づき再承認します。

人がログインできるだけでなく、監視・自動化・緊急復旧・監査が新IDで機能し、旧信頼を失効できますか。

架空例:人の移行は成功したが監視通知が届かなかったケース

架空のF事業は全社員の新メールを発行しましたが、監視サービスは旧共有メールと旧IdPのサービスアカウントを使っていました。サービスIDを人の台帳と分けて棚卸しし、新旧並行受信、API資格情報更新、緊急通知訓練を実施しました。旧トークンでアクセス不能なことまで確認してから転送を終了しました。

AWS・Azure・Google Cloudを組織・請求・ネットワーク・鍵・データから分離する

クラウドのアカウントやサブスクリプションを移せるかどうかだけでは、独立運用は決まりません。親組織の請求、割引、ID、ネットワーク、DNS、セキュリティ監視、鍵管理、バックアップ、サポート契約、IaC、ログ保管へ依存している場合、名義変更後も売り手環境と切れません。

本番アカウントをその場で手渡さない

誤認・失敗 実務上の修正
アカウントの所有者変更だけで完了にする ID・請求・鍵・ネットワーク・監視・サポートの独立性を個別に確認します。
本番を直接移して初めて試験する 匿名化または合成データの再構築、段階同期、切戻しを先に検証します。
親組織の鍵を共有し続ける 暗号化対象、再暗号化、鍵所有者、ローテーション、失効証拠を計画します。

買い手環境だけで認証、通信、復旧、監視、請求、サポートが成立し、売り手の鍵・DNS・契約を使わず運用できますか。

クラウド境界を組織・請求、ID、ネットワーク、データ、鍵、監視、バックアップ、サポートに分け、移管・再構築・TSAを選びます。プロバイダー固有の可否と手続は公式サポート・契約で確認し、記事から一律な移管可能性を断定しません。

クラウド境界を組織・請求・鍵・データから分解する

  1. 1. 資源グラフを取得する:アカウント、プロジェクト、VPC、接続、ストレージ、鍵、ログ、請求タグを製品IDへ結びます。 コンソールの一覧だけでは越境依存を見落とすためです。
  2. 2. 移管方式を選ぶ:現物移管、買い手環境への再構築、データ複製、期限付きTSAをサービス単位で比較します。 一方式へ全資源を押し込まないためです。
  3. 3. 新環境を独立検証する:権限、ネットワーク、暗号鍵、監視、バックアップ、復旧、請求、上限、サポートをテストします。 アプリ稼働だけでは運用能力を確認できません。
  4. 4. 旧環境を縮退する:アクセス廃止、ピアリング解除、鍵更新、データ削除、ログ保全、請求停止をExit証拠にします。 残置リソースと費用・侵入経路を残さないためです。

構成差分と復旧試験で新環境の独立性を示す

証拠・フィールド 確認できること 注意信号
クラウド資源グラフ 越境ネットワーク・ID・データ依存を示す。 手入力表が本番構成とずれる。
IaC・構成差分 新旧環境の設定・例外・手動変更を比較する。 secret値をVDRへ平文保存する。
復旧試験 新環境のバックアップから目標内に復元する。 バックアップ成功ログだけで復元未確認。
請求・容量試験 費用負担、上限、割引喪失、急増警報を確かめる。 親会社割引を買い手へ当然に引き継ぐ前提。

Git・CI/CD・コンテナ・署名鍵・ドメイン・DNS・証明書を一体で切り替える

リポジトリをコピーしても、ビルドランナー、パッケージレジストリ、コンテナ、秘密、署名、デプロイ権限、ドメイン、DNS、証明書、ストア登録が残れば製品を安全に更新できません。開発基盤はソースから顧客リリースまでの連鎖として扱います。

署名・デプロイ・ロールバックの実演で確認する

リリース依存図
全工程、主体、秘密、外部サービスを示す。 注意信号は手動作業が図にない。
移管リポジトリ照合
履歴、タグ、ブランチ、LFS、issue、権限を比較する。 注意信号は最新ソースだけで監査履歴が欠落。
署名・配布記録
新主体の鍵で顧客が検証できることを確認する。 注意信号は証明書名義とリリース主体がずれる。
旧経路否定試験
旧トークン・鍵・webhookで操作不能か確かめる。 注意信号は削除一覧だけで実アクセスを試さない。

Day 1の最低条件は、緊急修正を再現可能にビルドし、署名・配布し、監視し、失敗時に戻せることです。コード・履歴の完全性、第三者権利、資格情報の再発行、外部サービス契約を一つのリリース訓練で検証します。

  • リリース経路を図示する:Git、レビュー、CI、成果物、レジストリ、署名、配布、DNS、監視、ロールバックを順に並べます。 担当別リストでは隠れた受渡しを見落とします。
  • 秘密と所有権を分ける:コード・履歴を移し、鍵・トークン・証明書・bot資格情報は原則として買い手管理で再発行します。 売り手の秘密を複製して恒久共有しないためです。
  • 一つの修正版を通す:新環境で変更、レビュー、ビルド、SBOM、署名、検証、配布、監視、切戻しを実演します。 各ツールのログイン試験だけでは連鎖を確認できません。
  • 旧経路を閉じる:旧ランナー、webhook、deploy key、レジストリ、ストア、DNS権限、証明書自動更新を廃止します。 影のデプロイ経路を残さないためです。

コード移管だけで製品運用を譲渡したと考えない

  • Gitの移管を開発分離の完了とする:パイプラインから顧客更新・ロールバックまで実演します。
  • 秘密を一括エクスポートする:新所有者で再発行し、短期併存が必要なら期限・範囲・監視を限定します。
  • ドメイン移管を直前に始める:登録者、ロック、連絡先、DNSSEC、証明書、メール、TTL、代替を早期確認します。

買い手だけで緊急修正を作成・審査・署名・配布・監視・切戻しでき、旧経路からは変更できないことを実演しましたか。

顧客向けSaaSの可用性・RTO/RPO・凍結窓・切戻しをDay 1へ組み込む

SaaSの分離では、インフラ移行だけでなく認証、課金、通知、API接続、ログ、サポート、データ同期が同時に変わります。凍結期間を長くすれば安全とは限らず、脆弱性修正や顧客要望を止める別のリスクが生じます。契約上の可用性と実際の切替能力を合わせます。

RTO・RPOは希望値ではなく、切替・復旧訓練で測り、顧客区分と契約へ対応させます。変更凍結の開始・例外・解除、同期の整合、データ損失許容、切戻しの判断時刻と責任者をクロージング判定表へ入れます。

顧客影響から凍結窓と切戻し条件を決める

  1. 1. 顧客ジャーニーを試す:登録、ログイン、主要機能、API、通知、請求、サポート、解約を顧客ロール別に通します。 監視のHTTP成功だけでは価値提供を確認できません。
  2. 2. RTO・RPOを実測する:障害注入、同期停止、復旧、再送、整合確認に要する時間と損失範囲を記録します。 計画値と現実の差をクロージング前に把握できます。
  3. 3. 凍結と例外を定義する:対象変更、期間、緊急修正、承認、監視、解除条件を決めます。 必要な安全更新まで止めることを避けます。
  4. 4. 切戻しゲートを置く:エラー率、データ差、顧客影響、時間超過、セキュリティ事象の閾値と決定者を定めます。 失敗後も惰性で移行を続けないためです。
証拠・フィールド 確認できること 注意信号
顧客シナリオ試験 主要ロールのE2E動作と証跡を確認する。 管理者だけの試験で一般利用者が失敗。
可用性・復旧記録 RTO・RPO、データ整合、再送を実測する。 バックアップ時刻と業務トランザクションがずれる。
凍結例外ログ 緊急変更の理由、承認、試験、反映を示す。 口頭承認で追跡できない変更が入る。
切戻し判定票 閾値、時刻、責任者、顧客連絡を固定する。 技術復旧と顧客判断の指揮が分かれる。

計画停止を契約確認なしに設定しない

  • 計画停止ならSLAを確認しない:契約、通知、メンテナンス除外、顧客業務を法務・営業と確認します。
  • データ同期件数だけを比較する:金額・状態・参照整合・遅延・再送・削除まで業務意味で照合します。
  • 切戻しを技術チームだけで決める:顧客、安全、法務、経営の拒否条件と連絡権限を事前承認します。

顧客の主要業務、可用性、データ意味、請求、通知、復旧を一つの切替訓練で確認しましたか。

TSAサービスカタログへ範囲・除外・SLA・料金・データ・Exitを記す

共有ヘルプデスク、監視、セキュリティ、ネットワーク、クラウド、経理、人事、購買などをTSAで提供する場合、サービス名だけでは期待値が一致しません。利用者、受付時間、成果、処理量、対象外、依存先、優先度、データ、再委託、追加作業、料金、税、責任、終了をサービス単位で定義します。

第三者が各TSA行を読み、提供成果、利用条件、費用、障害時責任、終了証拠を同じ意味で理解できますか。

原価台帳と利用量ログでTSA料金を説明する

証拠・フィールド 確認できること 注意信号
TSAサービスカタログ 範囲、SLA、除外、データ、料金、Exitを示す。 従来どおり等の曖昧な記述。
原価・利用量台帳 工数、ライセンス、容量、第三者費を確認する。 配賦基準と実利用がかけ離れる。
SLA実績 受付、応答、復旧、除外、停止を測る。 時計開始・停止条件が定義されない。
追加作業注文 通常範囲外の変更、費用、納期、承認を残す。 口頭依頼が無償の恒常業務になる。

TSAは売り手の既存部門を無制限に使える契約ではなく、分離までの期限付きサービスです。料金は交渉事項ですが、直接費、担当工数、共通費配賦、第三者費用、容量、追加変更を説明できる基礎を持ち、Exitが遅れる場合の費用・能力制約も決めます。

共有サービスを成果・時間帯・除外まで記述する

  • サービスを成果で分ける:監視通知、一次受付、月次請求等を利用者が受け取る成果と時間帯で一行ずつ定義します。 組織名では提供内容と完了が分からないためです。
  • 対象外と依存を明示する:機能開発、重大変更、法務判断等の除外と、ベンダー・親基盤・人員への依存を記します。 追加依頼が通常サービスへ混ざるのを防ぎます。
  • 料金根拠を作る:固定、従量、実費、追加作業、超過、最低額の算定基礎と請求証拠を設計します。 後から恣意的な配賦と疑われないためです。
  • Exitをサービス別に定義する:受入試験、データ移行、アクセス廃止、請求停止、資産返却、残課題承認を完了条件にします。 全TSAを一つの日付で終えないためです。
誤認・失敗 実務上の修正
人員提供とだけ書く 成果、時間帯、処理量、優先度、除外、引継ぎをサービスとして定義します。
料金を一式の根拠なしに決める 交渉価格と原価・配賦・第三者費の説明資料を区別して保管します。
Exit支援を通常料金へ無制限に含める 移行支援の工数、成果、依存、追加費用、承認手続を別にします。

架空例:ヘルプデスクTSAの二次対応が範囲外だったケース

架空のJ事業は「ヘルプデスク提供」とだけ合意し、買い手は障害原因調査まで含むと理解していました。売り手は問い合わせ受付、本人確認、分類、一次回答、エスカレーション、二次調査、開発修正を分け、時間帯と優先度、件数上限、追加注文を定義しました。利用量ログに基づく月次請求と買い手側へのナレッジ移管をExitへ組み込みました。

TSAの変更要求・インシデント・監査・再委託・データ漏えいを統合管理する

分離期間は通常運用と移行変更が重なり、事故時に売り手・対象事業・買い手・ベンダーの誰が指揮するか曖昧になりやすい時期です。通常のサービス窓口だけでは、緊急変更、重大障害、個人データ事故、規制・顧客通知、監査要求、再委託先障害を処理できません。

通常窓口だけで緊急事態へ対応しない

  • 全てをTSA窓口へ集約して権限を与えない:事象別の決定権、代理、緊急連絡、費用限度を明文化します。
  • 事故責任を相手方へ一括転嫁する:検知・封じ込め・通知・証拠保全の実行責任を具体化し、契約救済は弁護士が検討します。
  • 買い手だから全情報を共有する:取引段階と競争法・秘密保持の助言に従い、必要最小限とクリーンチームを使います。

通常変更、標準依頼、緊急変更、インシデント、セキュリティ事象、個人データ事故を分類し、起票、承認、実施、連絡、費用、証拠、事後レビューの指揮系統を決めます。取引前の競争上機微情報は必要性・権限・クリーンチームを検討し、統合を先取りしません。

判断・作業 進め方 根拠資料 読み方
事象分類を合意する 通常変更、緊急変更、障害、安全事象、データ事故、監査を判定する入口と重複時の優先を決めます。 窓口ごとのたらい回しを避けます。 TSAガバナンス表 事象別の起票、判断、承認、連絡、費用を示す。 注意信号は平日担当だけで夜間代理がない。
RACIと代理者を置く 技術判断、顧客連絡、当局・本人対応、ベンダー指揮、費用承認の責任者と不在時代理を定めます。 一人のキーパーソンへ依存しません。 変更・決定ログ 要求、影響、採否、実施、切戻しを記録する。 注意信号は会議チャットだけで正式版が不明。
共同演習を行う 共有クラウドで障害と個人データ懸念が同時発生するシナリオを時系列で訓練します。 契約文言だけでは意思決定速度を確認できないためです。 インシデント演習記録 時間、判断、連絡、証拠、改善を測る。 注意信号は売り手と買い手が別々に演習する。
情報遮断を維持する 競争上機微な価格・顧客・戦略は、取引必要性、専門家、クリーンチーム、集計を使い段階管理します。 クロージング前の不適切な共同運営を避けます。 情報アクセス台帳 必要性、閲覧者、粒度、期限、削除を確認する。 注意信号は広い共有フォルダに競争上機微情報が残る。

夜間に共有環境で重大事象が起きた場合、最初の15分から顧客・当局判断まで誰が何をするか時系列で答えられますか。

週次分離管理で依存関係・決定・費用・リスク・証拠を一つにする

分離プロジェクトでは、法務、IT、人事、財務、営業がそれぞれの進捗表を持ち、同じ顧客・システム・社員について異なる状態を報告しがちです。完了タスク数が増えても、相手方同意、鍵更新、請求テストなど一つの前提が遅れれば、複数のWaveとTSA Exitが止まります。週次会議は報告会ではなく、部門横断の依存と経営判断を処理する場にします。

依存・決定・費用・リスクを週次の一枚へ集約する

作業 実施内容 判断理由
クリティカルパスを抽出する 同意、環境、データ、鍵、人員、テスト、通知の前後関係を結び、遅延余裕がない項目を明示します。 部門別の締切だけでは案件全体を止める依存が見えないためです。
意思決定を期限化する 選択肢、推奨案、反対案、追加情報、決定者、最終決定日、未決時の既定動作を記録します。 検討中という状態のまま実行日を迎えるのを防ぎます。
費用と範囲変更を結ぶ TSA延長、追加移行、ベンダー、並行運用、顧客例外の増減を承認済み予算と比較します。 技術判断が契約価格や残存事業の負担へ与える影響を示せます。
証拠でゲートを閉じる 完了報告ではなく、同意書、試験結果、ログ、照合、削除証明、買い手受入を課題へ添付します。 担当者の自己申告だけで次Waveへ進むことを避けます。

能力ID、移行Wave、TSAサービスIDを共通キーにして、前提、期限、責任者、費用、顧客影響、安全性、決定待ち、証拠、次のゲートを統合します。赤・黄・緑は印象で付けず、日程余裕、未達条件、代替可能性、影響範囲というルールで更新し、古い状態を上書きせず履歴へ残します。

課題台帳とクリティカルパスを相互参照する

統合課題台帳
能力・Wave・TSA・顧客を共通キーで管理する。 注意信号は同じ課題が部門表で異なる期限と状態になる。
依存関係・クリティカルパス
前提、後続、余裕、代替を確認する。 注意信号は重要な外部同意が通常タスクに埋もれる。
決定ログ
選択肢、根拠、権限、期限、影響を残す。 注意信号は会議後に決定内容と実行責任が食い違う。
費用・変更台帳
範囲変更と予算・TSA料金への影響を追う。 注意信号は追加作業が別紙・請求へ反映されない。

「完了率だけを経営KPIにする」という進め方は採りません。顧客停止リスク、クリティカルパス余裕、未決事項、費用予測、Exit受入率を併記します。 「赤信号を減らすため期限を延ばす」と判断する前に、元期限、変更理由、影響、追加費用、承認を保ち、色だけを変えません。 「会議資料へ証拠をコピーする」だけでは説明が足りません。原本システムへの参照、版、ハッシュ、閲覧権限を残し、多重正本を作りません。

今週の未決事項が、どのDay 1能力、顧客、Wave、TSA費用、Exit日を止めるか一枚で説明できますか。

社員の説明・承諾とTSA Exit証明を最終分離の同じゲートへ置く

事業譲渡等での労働契約の扱いはスキームと事実により異なり、個々の社員の説明や真意による承諾等が重要になる場面があります。人を単なる移行リソースとして扱うと、キーパーソン離職、知識喪失、不十分な同意、TSA延長につながります。また予定日だけでTSAを終了すると、旧アクセス、鍵、データ、請求、資産が残ります。

日付到来だけでTSAを自動終了させない

誤認・失敗 実務上の修正
社員を資産一覧の一項目とする 情報提供、個別事情、キャリア、処遇、質問、意思を適切に扱います。
知識移管会議の回数で完了にする 買い手だけの実行、例外対応、復旧、証拠作成を受入条件にします。
TSA日付到来で権限を切る 受入未完なら延長・代替・例外を契約手続で判断し、無断継続もしません。

社員の意思と処遇を尊重した手続に加え、買い手だけの実行成功と売り手側アクセス否定をサービスごとに証明しましたか。

労務手続は最新の厚生労働省資料と専門家助言に従い、対象者、役割、条件、情報提供、質問、承諾、拒否、個別事情を丁寧に扱います。TSA Exitは人の知識移管と受入能力、技術試験、アクセス廃止、データ削除、請求停止、資産返却、残課題の承認をサービスごとに証明します。

社員承諾・受入テスト・アクセス廃止をExitへ束ねる

  1. 1. 対象者と業務を対応する:雇用形態、所属だけでなく実作業、兼務、特権、顧客関係、代替、退職リスクを事業能力へ結びます。 組織図から抜ける共有担当を発見するためです。
  2. 2. 説明・承諾手順を設計する:スキームに応じた情報、時期、個別面談、質問窓口、記録、専門家確認を用意します。 一斉説明だけで個別の真意・条件を扱わないことを避けます。
  3. 3. 受入能力をテストする:買い手担当だけで月次処理、障害、復旧、請求、リリース等を実行し、売り手は観察役になります。 研修受講を自立運用と同一視しないためです。
  4. 4. Exit証明を承認する:アクセス、鍵、データ、契約、請求、資産、残課題をサービス所有者・法務・経理・安全責任者が確認します。 一つの日付で全依存を閉じないためです。

承諾記録とExit証明パックで最終分離を確認する

証拠・フィールド 確認できること 注意信号
人員・能力マップ 役割、兼務、知識、特権、代替を示す。 名簿はあるが業務能力へつながらない。
説明・承諾記録 対象、提供情報、質問、意思、条件、日付を確認する。 形式的な一括署名だけで個別説明がない。
受入テスト記録 買い手主体で運用を完走した証拠を示す。 売り手担当が裏で全操作を続ける。
Exit証明パック アクセス廃止、鍵更新、削除、請求停止、返却を束ねる。 TSA終了通知だけで技術・財務証拠がない。

架空例:担当者移籍後も旧管理権限が必要だったケース

架空のL事業では主要運用担当が買い手へ移りましたが、親会社の共有監視基盤には売り手社員しか変更権限がありませんでした。担当者の移籍を能力移管とみなさず、買い手監視の構築、アラート移行、障害演習、旧権限廃止を別のExit条件にしました。労務手続と技術権限の完了を混同せず、それぞれの証拠を最終分離会議で承認しました。

クロージングのGo・条件付きGo・延期・切戻しを証拠で判定する

カーブアウトの最終会議で「大部分が終わった」という進捗率だけを示しても、事業継続の可否は判断できません。顧客認証、請求、個人データ、緊急リリース、社員、相手方同意の一つが未達なら、完了タスクが多くても重大な停止が起こり得ます。反対に低重要度の後続移行が残っていても、期限付きTSAと責任者があればDay 1を迎えられる場合があります。

判定はGoとNo-Goの二択だけにせず、予定どおり実行、限定条件を付けて実行、特定Waveのみ延期、全体延期、切替後の切戻しを分けます。条件付きGoには、許容する残存リスク、暫定措置、失効時刻、監視、権限者、TSAまたは契約変更、顧客への影響を記します。条件が満たされなければ自動的に延期・切戻しへ移る境界も必要です。

ゲート資料は会議直前の自己申告ではなく、買い手主体の受入試験、同意・承諾原本、財務照合、アクセス否定試験、復旧実測、データ差分などを参照します。証拠の取得時刻と対象版を固定し、最終同期や鍵変更の後に陳腐化する項目は切替窓の中でも再確認します。役員は未達の影響と代替を比較し、技術担当だけに事業継続判断を委ねません。

切戻しは失敗の宣言ではなく、顧客・データ・安全を守る統制です。ただしデータ書込みや請求主体の切替後は、単純に旧環境へ戻すと二重処理が起こる場合があります。可逆な操作、片方向同期、書込み停止、再送、顧客連絡、法的効力を事前に区別し、どの時点まで何を戻せるかを時系列へ落とします。

経営会議で確認する10のクロージングゲート

ゲート 最低証拠 拒否条件 条件付きGoの例 切戻し・代替
顧客サービス 主要ロールのE2E試験 認証・中核機能・通知の重大失敗 限定顧客を旧経路でTSA継続 DNS・ルーティングを旧経路へ戻す
契約・同意 対象契約の原本と回答台帳 重要顧客の必要手続未了 同意済みWaveだけを実行 旧主体提供と精算を期限付き継続
請求・入金 テスト請求、税、口座、消込 二重請求または入金不能 特定サイクルのみ売り手代行 請求発行を停止し顧客へ訂正連絡
個人データ 処理記録、権限、差分、削除計画 目的・主体・安全管理の重大未確認 最小データのみ限定環境へ移す 同期停止と受領コピーの隔離
社員・当番 説明・承諾等の記録とシフト 必要な専門能力・緊急担当の空白 売り手専門家を限定TSAで提供 Wave延期と代理体制の継続
ID・特権 MFA、SSO、緊急ID、旧アクセス試験 管理不能または旧主体の過大権限 二者承認付きの短期併存 新信頼を停止し旧統制へ戻す
クラウド・復旧 構成差分、監視、復元実測 RTO超過または復元不能 読み取り系だけ新環境へ移す 書込みを止め旧環境へ経路変更
リリース能力 修正版のビルド・署名・配布訓練 緊急修正を出せない 旧署名を厳格な期限・監視下で利用 変更凍結と売り手緊急対応
TSA実行性 サービス担当、SLA、料金、事故演習 提供者・権限・依存先が不明 対象を縮小し代替ベンダー併用 クロージングまたは対象Waveを延期
財務・残高 売掛、前受、未払、資産の照合 重要差額または責任主体の不明 精算勘定と期限付き照合を設定 請求・残高移管だけ延期
  • 各ゲートに証拠の保存先、対象版、取得時刻、作成者、買い手受入者があるか。
  • Go判断後に変わる最終同期、鍵、DNS、社員状態を切替窓で再確認するか。
  • 条件付きGoの条件、失効時刻、監視、責任者、追加費用、契約根拠を承認したか。
  • 顧客・データ・安全に関する拒否条件を日程圧力だけで上書きできない権限設計か。
  • 切戻し可能時点をデータ書込み、請求発行、法的効力、顧客通知ごとに分けたか。
  • 売り手残存事業へ戻し操作が与える容量・安全・契約影響も確認したか。
  • 一部Wave延期時に同じ顧客・データを新旧双方で更新しない統制があるか。
  • 延期・切戻し後の再試験、再通知、追加TSA、経営再決裁の予定を決めたか。

判定票はクロージングを止めるための形式ではなく、何を満たせば安全に進め、何が崩れれば戻るかを取引当事者が事前に共有する道具です。最終的な実行可否は契約、法令、専門家助言、当事者権限に従って決めます。根拠が更新された場合は元の判定を消さず、新しい版と変更理由を決定ログへ追加します。

分離ペリメーター・Day 1・TSA・Exit統合管理表

このテンプレートは取引契約や法定手続の代替ではありません。事業能力を親キーとして、法的譲渡対象と運用依存、四区分、移行Wave、TSA、受入証拠を一行で参照する独自の分離索引です。Sharedを未決のまま残さず、必ずサービス提供者と終了方法を持たせます。

欄 記入内容 検証方法 更新契機
能力ID 受注、提供、認証、請求、開発、監視等の継続すべき業務能力。 顧客価値・契約・責任者へ戻れるか。 製品・組織・スキーム・顧客範囲変更時。
七要素境界 人、契約、データ、アプリ、インフラ、知財、財務のOwner・Buyer・Shared・Retire。 各セルに実物IDと根拠があるか。 依存発見、交渉、同意拒否、構成変更時。
法的対象・確認 譲渡・承継・利用許諾・残置等の予定と専門家確認状態。 契約・法令・決議・個別同意へ戻れるか。 スキーム、契約、法令、事実変更時。
Day 1区分 初日必須、TSA、後続Wave、廃止と判定理由。 停止影響、期限、代替、切戻しを説明できるか。 試験結果、顧客要請、遅延、事故時。
移行Wave 準備、複製、同期、凍結、切替、検証、切戻しの日時と主体。 前提依存と競合する変更がないか。 計画・容量・同意・環境変更時。
顧客・ベンダー手続 通知、承諾、再契約、請求、入金、受領、代替。 契約原本とCRM・ERP状態が一致するか。 回答、期限、相手方条件、Wave変更時。
データ処理 集合、目的、移転・複製・残置・削除、主体、安全管理。 処理記録、権限、ログ、削除証明へ戻れるか。 開示先、目的、保存場所、取引状態変更時。
TSAサービス 成果、時間帯、SLA、除外、依存、データ、再委託、責任。 利用者と提供者が同じ範囲を理解するか。 利用量、事故、変更要求、依存先更新時。
料金・税 固定・従量・実費・追加作業、配賦、請求、税務確認。 原価・利用量・契約式から再計算できるか。 容量、期間、ベンダー費、税務前提変更時。
受入・切戻し テストシナリオ、閾値、実測、例外、決定者、顧客連絡。 買い手主体で成功し失敗時に戻せるか。 試験、切替、障害、データ差異時。
Exit条件 受入、アクセス廃止、鍵更新、削除、請求停止、資産返却。 各条件に日付付き証拠と承認者があるか。 完了、延長、例外、残課題承認時。
未解決・決定 課題、影響、暫定措置、選択肢、担当、期限、経営判断。 無責任な空欄や期限超過がないか。 新発見、遅延、前提変更、会議決定時。

管理表の目的は全セルを緑に塗ることではありません。法的未確認、技術制約、同意待ち、推定費用をそれぞれ識別し、Day 1へ持ち込む残存リスクを経営者と買い手が同じ単位で判断することです。確定値と仮説を混ぜず、版と基準日時点を固定します。

TSAサービスカタログとExit証明パックの必須フィールド

サービス記述が曖昧だと、買い手は従来業務全体を期待し、売り手は限定支援と理解します。以下のフィールドで一行一サービスを作り、提供中の実績と終了時の否定証拠を同じIDへ結びます。

1. サービスID
名称変更に左右されないTSA単位の恒久IDです。 契約別紙、チケット、請求、SLA、Exitを結ぶ親キーにします。
2. 利用者・受益事業
誰が何の事業能力のために使うかです。 対象外利用と容量予測を管理します。
3. 提供成果
受付、処理、通知、データ、報告等の観測可能な結果です。 担当者提供ではなく完了を測れる単位にします。
4. 時間帯・優先度
受付時間、営業日、緊急区分、応答・復旧の時計です。 SLA開始・停止・除外を明確にします。
5. 対象外
通常料金へ含まれない機能、変更、責任、地域、容量です。 追加注文と拒否可能範囲を事前に示します。
6. 依存サービス
人、ベンダー、契約、システム、データ等の前提です。 依存先終了とTSA Exitの順序を管理します。
7. データ取扱い
目的、場所、主体、権限、ログ、保持、返還・消去です。 TSA期間の個人・機密データ責任へつなぎます。
8. 再委託
外部提供者、承認、契約、所在、事故連絡の条件です。 親契約の終了・変更リスクを管理します。
9. 料金式
固定、従量、実費、追加、超過、延長等の算定式です。 利用量・原価・請求書から再計算します。
10. 変更手続
要求、影響分析、費用、承認、実施、切戻しの流れです。 口頭依頼を無制限な範囲拡張にしません。
11. 事故指揮
検知、封じ込め、顧客・当局判断、証拠保全のRACIです。 夜間代理と複合事象の優先ルールを持ちます。
12. Exit受入
買い手主体のテスト、性能、復旧、例外、承認です。 研修完了ではなく自立運用を証明します。
13. 否定証拠
旧アクセス、鍵、連携、データ、請求、資産が残らない証拠です。 新環境の成功と旧環境の廃止を両方向で確認します。
14. 延長・例外
未達理由、暫定措置、費用、最長日、承認、再試験です。 無断継続や日付だけの強制終了を防ぎます。
15. 証拠ハッシュ・版
受入・削除・請求・返却資料の同一性と版です。 差替後もどの証拠で承認したか再現します。

サービスカタログは締結後も運用実績、変更、事故、利用量、Exit準備で更新します。ただし契約本文・別紙を管理表だけで上書きせず、変更契約・承認手続との対応を残します。個別の責任制限、救済、税務、個人データ条項は案件専門家が検討します。

売却前180日から最終分離までの実行ロードマップ

カーブアウトの所要期間はスキーム、契約、データ、クラウド、社員、相手方同意で大きく変わります。以下はクロージングを0日とした例であり、手続期限や規制審査を短縮する保証ではありません。未確定事項を早く可視化し、Day 1最低運用とExitを同時に設計します。

時期 実施事項 完了条件 経営者の判断
-180〜-151日 候補スキーム、事業能力、七要素の母集団、専門家、守秘・情報遮断を設定する。 ペリメーター初版と未確認リストが経営承認される。 取引検討範囲、法務・税務・労務の照会優先を決める。
-150〜-121日 契約、データ、ID、クラウド、開発基盤、社員、財務残高を実物IDへ結ぶ。 主要能力の七列にOwner・Buyer・Shared・Retireが入る。 共有依存をTSA候補・再構築・廃止へ仮配分する。
-120〜-91日 Day 1判定、契約Wave、データ処理、クラウド・ID移行方式を設計する。 停止影響、代替、同意、期限、切戻しが見える。 Day 1必須と許容する残存リスクを承認する。
-90〜-61日 TSAカタログ、SLA、料金基礎、変更・事故RACI、Exit条件を作る。 共有サービス全件に成果、除外、依存、料金、終了証拠がある。 TSA交渉レンジと提供能力・最長期間を決める。
-60〜-46日 新ID・クラウド・開発・請求環境を構築し、匿名・合成データで単体試験する。 認証、復旧、リリース、請求の基本経路が新環境で動く。 本番データ同期と顧客通知へ進むゲートを承認する。
-45〜-31日 顧客・ベンダーWave、社員説明、個人データ確認、並行運用を進める。 同意・通知・承諾の状態と代替案が一件ごとに見える。 未回答・拒否・個別事情の取引影響を判断する。
-30〜-15日 E2E、RTO/RPO、緊急リリース、事故指揮、請求・入金の共同訓練を行う。 実測値、失敗、修正、切戻し、再試験が記録される。 クロージング拒否条件と暫定TSAを更新する。
-14〜-2日 凍結、同期、鍵、DNS、窓口、権限、連絡、残高、VDR版を最終照合する。 Day 1チェックリストと時刻別指揮表が署名される。 Go・条件付きGo・延期の判断権限を確認する。
-1〜0日 最終差分、同意、社員、データ、監視、復旧、切戻し準備を確認し切替を実行する。 主要顧客シナリオと最低運用が閾値内で成功する。 切戻し閾値に基づき経営者が継続可否を決める。
+1〜+30日 安定化、例外顧客、残高消込、権限異常、TSA実績、事故・変更を日次・週次管理する。 高リスク例外に担当、期限、暫定措置がある。 各TSAのExit準備と必要な契約変更を承認する。
+31〜+90日 買い手主体の運用訓練、知識移管、データ・クラウド・請求の後続Waveを完了する。 主要サービスで売り手を操作主体にしない受入試験が成功する。 サービス別Exit、延長、代替を判定する。
+91日〜最終分離 旧アクセス・鍵・連携廃止、データ削除、請求停止、資産返却、残課題承認を束ねる。 全サービスにExit証明パックと最終承認がある。 TSA終了と残存責任・証拠保管を最終確認する。

予定日どおり進むことだけを成功としません。テストや同意で重大な未達が見つかった場合に、条件付きGo、TSA追加、Wave変更、延期、切戻しを証拠に基づき選べることが統制です。日程を守るために未解決を「問題なし」へ変更せず、費用・顧客・安全・法務への影響を経営判断へ上げます。

売り手CEO・CIO・法務・人事・経理が答える12のDay 1質問

買い手面談では担当領域だけを答えず、同じ能力ID・移行Wave・TSAサービスIDへ戻ります。日付、対象、根拠、未解決、代替、承認者を含め、専門家確認中の事項を確定済みと表現しません。

  1. この取引のカーブアウトはどの法的スキームで、何が当然に承継されますか?
    契約書、会社法等、個別契約、専門家助言に基づく対象と未確認を分けます。実務用語だけで承継効果を断定しません。
  2. Day 1と最終分離はそれぞれ何を意味しますか?
    法的効力、最低運用、TSA開始、請求・データ切替、各Exit、全共有依存解消の日時と完了条件を答えます。
  3. 対象事業の最大の共有依存は何ですか?
    能力ごとの人、契約、データ、アプリ、基盤、知財、財務から、停止影響とExit難易度が高いものを証拠付きで示します。
  4. 何をDay 1必須、TSA、後続、廃止にしましたか?
    停止時間、法令・契約期限、代替、安全、所要、切戻し、残存事業影響を使った判定と経営承認を示します。
  5. 顧客・ベンダーの同意や通知はどこまで完了していますか?
    分母、Wave、契約論点、回答、期限、拒否、代替、請求・入金・技術切替を一件ごとに答えます。
  6. 個人データをDD・承継・TSA・Exitでどう扱いますか?
    データ集合、目的、主体、最小化、移転・複製・残置・削除、安全管理、ログ、証明、専門家確認を示します。
  7. 買い手だけでメール・ID・クラウドを運用できますか?
    人・特権・サービスID、SSO、MFA、ネットワーク、鍵、監視、復旧、請求、旧アクセス否定の試験結果を示します。
  8. 緊急修正を買い手環境だけでリリースできますか?
    Git、CI、部品、レジストリ、署名、ストア、DNS、証明書、監視、ロールバックを通した実演と未達を答えます。
  9. SaaS切替が失敗した場合、いつ誰が切り戻しますか?
    顧客シナリオ、エラー・データ差・時間・安全の閾値、判断時刻、責任者、顧客連絡、戻した後の再送を時系列で示します。
  10. TSA料金は何を根拠に、どこまで含みますか?
    サービス成果、時間帯、容量、直接費、工数、共通費、第三者費、固定・従量・実費、追加作業、税務確認を区別します。
  11. 共有環境で事故が起きたら誰が顧客・当局対応を決めますか?
    検知、封じ込め、証拠、技術判断、顧客・本人・当局判断、ベンダー、費用のRACIと夜間代理、共同演習を示します。
  12. TSAは日付以外に何を満たせば終了しますか?
    買い手主体の受入、性能・復旧、旧アクセス廃止、鍵更新、データ削除、請求停止、資産返却、残課題承認をサービス別に答えます。

回答の不一致は、話法ではなくペリメーター版、基準日、能力ID、契約原本、試験証拠を直して解消します。売り手と買い手で意見が異なる事項は、確認済み事実、専門家見解、各当事者の判断、暫定措置、決定期限の順に表示します。

一次資料の読み方と更新管理

次の法令・行政ガイド・公式資料は2026年8月22日時点の確認先です。会社法、労働関係指針、個人情報保護委員会ガイド等には直近改正や施行前表示があり得るため、個別手続を進める際はリンク先の現行条文、施行日、Q&A版を専門家と確認します。

一次資料・公式標準 この記事で確認する論点 更新上の注意
e-Gov法令検索「会社法」 事業譲渡、会社分割、承認等の法的スキームの入口。 施行・未施行改正を区別し、基準日時点の条文を弁護士と確認する。
e-Gov法令検索「民法」 債権譲渡、債務、契約関係の基本的な法令確認。 契約上の地位・個別同意を記事だけで確定しない。
法務省「債権譲渡登記制度とは」 金銭債権譲渡の対抗要件等を確認する公式入口。 顧客契約そのものの移管と金銭債権の取扱いを混同しない。
厚生労働省「企業組織の再編に伴う労働契約の承継」 会社分割・事業譲渡等と労働者保護・説明・承諾の公式資料。 2026年1月20日改正情報を含む現行資料を確認し、スキーム別に読む。
個人情報保護委員会「個人情報保護法ガイドライン通則編」 事業承継、安全管理、利用目的等の公式ガイド。 2026年6月一部改正版と施行時点を公開前に確認する。
個人情報保護委員会「個人情報保護法Q&A」 DD段階の提供、交渉不成立時の返還・消去、承継後利用等。 質問番号・文言・更新日を最新版で照合する。
中小企業庁「中小M&Aガイドライン(第3版)」 M&A手法、契約、引継ぎ、支援機関・トラブル防止の公式資料。 参考サンプルを個別案件へそのまま転用しない。
中小企業庁「事業承継・M&A/中小PMIガイドライン」 PMIガイドと実践ツールへの公式入口。 会社全体の統合を部分事業の分離へ機械的に転用しない。
経済産業省「起業家主導型カーブアウト実践ガイドブック」 知財・人事・法務をまたぐカーブアウトの実践課題。 2026年4月17日公表。対象想定と本件スキームの違いを確認する。
経済産業省「対日M&A活用事例集」 子会社売却・事業譲渡を含むカーブアウト類型の事例。 クロスボーダー固有事情を国内案件へ一般化しない。
経済産業省「AI・データの利用に関する契約ガイドライン」 データ提供・創出・利用権限と契約設計の公的資料。 データ編の版と後続のモデル規約等を併読する。
経済産業省「システム管理基準 2023」 ITガバナンス、委託、変更、運用、ライフサイクル管理。 法定のTSA様式ではなく会社固有統制へ落とす。
IPA「中小企業の情報セキュリティ対策ガイドライン」 資産管理、クラウド、安全管理、事故対応の公式ガイド。 基準日現在の掲載版と付録版を公開前に確認する。
経済産業省「サイバーセキュリティ経営ガイドライン Ver.3.0」 経営責任、サプライチェーン、委託、インシデント対応。 TSA当事者の契約上の責任分界は別途定める。
公正取引委員会「企業結合審査に関する独占禁止法の運用指針」 事業譲受け等の企業結合審査枠組みと競争影響。 届出・情報共有・競争上の評価は専門弁護士へ確認する。
国税庁「営業の譲渡をした場合の対価の額」 課税・非課税資産を一括譲渡する場合の対価区分の照会例。 個別の対価配分・消費税・請求は税理士へ確認する。
文化庁「著作権の登録制度」 プログラム著作物を含む登録制度と手続の公式案内。 登録の有無だけで譲渡可能性・帰属・非侵害を断定しない。
特許庁「M&Aにおける知財デューデリジェンス調査研究報告書」 譲渡対象知財の棚卸し、調査、リスク整理。 2017年度資料のため現行法・契約・現在のIT実務で補完する。

カーブアウト、Day 1、TSAには全案件共通の法定テンプレートはありません。上表は論点の確認先であり、会社法上の手続、契約・債権、労働者、個人データ、競争法、税務、知財の結論を記事から自動決定できません。採用スキーム、契約原本、データ集合、社員状況、対価、基準日を専門家へ提示してください。

関連するIT M&A実務ガイド

本稿は会社全体を統合するPMIではなく、部分事業を売り手共有環境から分離してTSAを終了する逆向きの実務です。一般的なM&A手順、技術DD、契約条項、アカウント棚卸しは既存記事へ分けます。

  • IT M&Aとは:IT事業のM&A全体像と基本用語を確認する。
  • IT企業 M&A PMI 100日プラン:買い手側の会社統合と本稿の分離・Exitを読み分ける。
  • Web制作・SaaS・クラウド運用会社のアカウント権限整理:基本的なアカウント台帳と権限移管の入口にする。
  • IT企業M&Aのデューデリジェンス完全ガイド:分離着手前に契約・ソース・クラウドの調査範囲を照合する。
  • IT企業 M&A 最終契約:表明保証、補償、前提条件等の一般論は専用記事で確認する。
  • IT企業 M&A 売却価格:分離費用・TSA等を企業価値評価の全体像と読み合わせる。

既存記事のアカウント移管やPMIを参照するときも、部分事業では売り手残存事業を守る必要がある点を読み替えます。実際の譲渡対象、同意、労務、データ、TSA条項、料金、税務は案件専門家と確認してください。

よくある質問

カーブアウトは会社法上の一つの手続ですか?

カーブアウトは一般に事業の一部を切り出す実務上の呼称であり、それだけで法的スキームは決まりません。株式譲渡、事業譲渡、会社分割、新会社化等により承継効果、決議、債権・債務、契約、労働、税務が変わります。対象範囲と目的を示し、案件弁護士・税理士が具体的な手続を確認します。

Day 1までに全システムを完全分離する必要がありますか?

必ず全件を完了するとは限りません。顧客サービス、契約、データ、安全、入金、従業員を止めない最低条件を特定し、残りは期限付きTSAや後続Wave、廃止を選ぶ場合があります。ただし延期理由、提供範囲、料金、責任、最長日、Exit条件を明確にし、無期限の共有依存を作りません。

カーブアウトでは必ずTSAを締結しますか?

必ず必要とは限りません。取引前に独立環境を構築でき、共有サービスが残らなければTSAを使わない場合もあります。逆に親会社の請求、ID、クラウド、監視、人事等へ依存する場合は移行サービスが有用です。具体的な契約範囲・救済・料金は弁護士と当事者が案件ごとに定めます。

事業譲渡なら顧客契約も自動的に移りますか?

一律に自動移転すると断定できません。採用スキーム、契約条項、契約上の地位、債権・債務、相手方の同意・通知、法令を個別に確認します。基本契約、注文書、約款、SLA、セキュリティ別紙、変更合意を集め、弁護士の判断とシステム上の顧客・請求切替を別々に管理します。

対象事業の社員は全員そのまま買い手へ移りますか?

スキームと個別事実によって扱いが異なります。事業譲渡等では労働者への情報提供や真意による承諾等が重要になる場面があります。対象者を物のように扱わず、業務実態、兼務、処遇、勤務地、質問、個別事情、意思を丁寧に扱い、最新の厚生労働省資料と労務専門家の助言を確認します。

事業承継なら個人データを全て買い手へ渡せますか?

無制限に渡せるとはいえません。データ集合、利用目的、必要性、取得経緯、管理主体、承継後利用、安全管理、契約、DD段階、交渉不成立時の返還・消去を確認します。個人情報保護委員会の最新ガイド・Q&Aと案件事実を弁護士・個人情報保護責任者へ示し、移転・複製・限定閲覧・削除を設計します。

クラウドアカウントの名義を変えれば分離完了ですか?

名義変更だけでは不十分なことがあります。親組織の請求、割引、ID、ネットワーク、DNS、鍵、監視、バックアップ、サポート、IaCへの依存を確認します。買い手だけで復旧・監視・請求できるかを試し、旧アクセス、ピアリング、鍵、データ、請求を廃止した否定証拠までExitに含めます。

旧メールを無期限転送すれば顧客連絡は安全ですか?

無期限転送は機密、個人データ、誤送信、なりすまし、責任主体の混乱を招き得ます。契約・顧客関係上の必要期間、代替窓口、ドメイン、認証、監査ログを考慮し、開始・終了日、対象、例外、監視、旧転送の否定試験を定めます。具体的な周知は法務・営業と確認します。

TSA料金は実費だけにすべきですか?

一律の算定方法はありません。固定、従量、実費、直接工数、共通費、第三者費、追加作業、超過、延長等を当事者が交渉します。売り手は原価・利用量・配賦基準を説明できる資料を作り、契約価格と管理原価を区別します。消費税・移転価格等の個別論点は税理士へ確認します。

TSAは契約終了日が来れば自動的に止めてよいですか?

契約文言と個別状況によりますが、運用上は日付だけで停止すると事業が止まる可能性があります。買い手主体の受入、性能・復旧、旧アクセス廃止、鍵更新、データ削除、請求停止、資産返却をサービス別に確認します。未達なら契約上の延長・代替・例外手続を期限前に判断し、無断継続もしません。

買い手にはクロージング前から全顧客情報を共有できますか?

全面共有を前提にしません。守秘義務、個人データ、顧客契約、営業秘密、競争上機微情報、取引必要性を評価し、集計、匿名化、段階開示、クリーンチーム、限定閲覧、ログ、削除を選びます。競争法上の届出有無だけで情報共有の可否を決めず、専門弁護士へ確認します。

分離計画を整えれば譲渡価格は上がりますか?

価格上昇を保証しません。依存、移行費、TSA期間、同意、データ、安全、人員の不確実性を買い手が評価しやすくなり、条件を比較できる可能性はあります。一方、追加費用や遅延、補償、前提条件が必要と判明することもあります。目的は高く見せることではなく、Day 1の継続とExitの実現可能性を証拠化することです。

免責事項と専門家へ引き継ぐ境界

本記事はIT事業のカーブアウト、TSA、Day 1分離に関する一般的な情報提供であり、個別の会社法、契約、債権債務、労働、個人情報、競争法、知的財産、税務、会計、サイバーセキュリティ、投資、企業価値評価の専門助言ではありません。必要手続と承継効果は採用スキーム、契約、法域、当事者、基準日、事実により変わります。

実案件では、候補スキーム、ペリメーター、契約原本、財務残高、データ集合、クラウド・ID・開発構成、社員状況、TSA案、試験結果をそろえ、弁護士、税理士、公認会計士、社会保険労務士、情報セキュリティ専門家、FA等へ確認してください。記事内の架空例、180日計画、テンプレートは法定様式でも事業継続・成約・価格の保証でもありません。

IT事業 カーブアウト M&Aの事実確認日は2026年8月22日です。公開後に制度、法令、会計基準、標準仕様、行政ガイドラインが更新された場合は、IT事業 カーブアウト M&Aに関係するリンク先の最新版と施行日を確認し、この記事の更新履歴へ反映してください。

コラム
よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!
  • IT企業 M&A SBOM|OSSライセンス・脆弱性・ソース来歴を整えるデューデリジェンス
  • サイバーセキュリティ会社M&A事例|GMO×イエラエの50%子会社化を解説

この記事を書いた人

IT M&A総合センター編集部のアバター IT M&A総合センター編集部

IT企業・Web事業のM&A、会社売却、事業承継に関する実務情報を編集しています。

関連記事

  • IT M&Aによる技術と事業の承継を相談するオーナーと経営・技術チームのイメージ
    IT M&Aの売却・事業承継ガイド|6事例・業界動向・評価倍率
    2026年9月14日
  • 茨城のアグリテック・圃場データ活用SaaS会社M&Aをテーマに、圃場データのダッシュボードと農業経営の打ち合わせを表現したアイキャッチ画像
    茨城のアグリテック・圃場データ活用SaaS会社M&Aで評価されるポイント|センサー運用・販売計画・季節変動を整理する会社譲渡準備
    2026年8月24日
  • IT企業 M&A SBOMの完全性とOSSライセンスを確認するCTOと法務責任者
    IT企業 M&A SBOM|OSSライセンス・脆弱性・ソース来歴を整えるデューデリジェンス
    2026年8月22日
  • IT企業 M&A 開発費 資産計上とソフトウェア原価の確認を行う経営者と財務責任者
    IT企業 M&A 開発費 資産計上|ソフトウェア原価・EBITDA・正常収益力をつなぐ売却準備
    2026年8月22日
  • 東京のIT企業M&Aで評価される顧客基盤と人材承継|SaaS・受託開発・SES会社が会社売却前に整える実務
    2026年8月21日
  • セキュリティ会社のM&Aで評価される情報セキュリティの監視・運用代行運用と顧客信頼|脆弱性診断・監視契約・資格人材を整える会社売却準備
    2026年8月15日
  • Web制作会社のM&Aで評価される継続保守と顧客基盤|CMS・EC・広告解析アカウントを整える会社売却準備
    2026年8月14日
  • SES会社のM&Aで評価される稼働率・単価・商流|待機人材、契約形態、エンジニア定着を整える会社売却準備
    2026年8月13日

© IT M&A総合センター.

目次