本文へスキップ

AIサービスの終了・乗り換え計画|データ返却・削除・代替手段の確認項目

AIサービスの終了・乗り換え計画|データ返却・削除・代替手段の確認項目

生成AIやAIエージェントが、会議要約、社内検索、問い合わせ対応、文書作成、システム更新まで担うと、サービスを止める判断は単なる解約では済みません。会話履歴、アップロードファイル、プロンプト、ナレッジ、評価データ、監査ログ、API接続が分散したまま利用権限を失うと、必要な情報を取り戻せず、代替サービスへ移っても業務を再現できないおそれがあります。

出口計画は、契約終了を決めた後に作る文書ではありません。導入前から「何を持ち出せるか」「どの機能へ依存しているか」「誰が停止を承認するか」を決め、契約更新、価格改定、サービス停止、モデル廃止、重大なリスク発生のどこからでも実行できる状態を作ります。

出口は「解約日」ではなく「業務・データ・権限が安全に切り替わった日」で閉じます。 依存関係を棚卸しし、アクセスを失う前にデータと設定を取得し、代替環境で復元・品質確認を行います。その後に本番を切り替え、旧環境への書き込みを止め、APIキーやSSO連携を失効させ、契約終了とデータ削除の結果を証跡として残します。

AIサービスの依存関係確認、データ書き出し、復元テスト、代替環境の並行評価、切替と権限停止、削除確認をつなぐ出口計画の図
出口計画は、データを書き出した時点ではなく、代替環境での再利用、旧権限の停止、削除確認まで完了して閉じます。

本記事のポイント

  1. AIサービスの出口計画は解約手続きではなく、業務継続、データ移行、権限停止、削除確認を一つにつなぐ運用です。
  2. エクスポート可否はサービス名だけで判断せず、契約プラン、管理者権限、対象データ、形式、期限、再利用可能性まで実査します。
  3. モデルやAPIの廃止には、代替モデルの並行評価、切替条件、ロールバック、旧認証情報の失効を事前に用意します。

AIサービスの出口計画とは何か

AIサービスの出口計画とは、利用を縮小・停止するときに、業務を止めず、必要なデータと証跡を保全し、不要なアクセスとデータを旧環境へ残さないための手順です。対象はSaaSの契約解約だけではありません。ワークスペースの統廃合、組織からの離脱、APIやモデルの廃止、ベンダーの事業撤退、自社のリスク許容度超過も出口の起点になります。

NIST AI RMF PlaybookのGOVERN 1.7は、AIシステムの無計画な停止や削除が、法令対応、調査、上下流システム、事業継続へ新しいリスクを生む可能性を示し、体系的な廃止方針を持つよう勧めています。ここで重要なのは「消すか残すか」の二択ではなく、移行すべきもの、法令・契約上保全すべきもの、失効させる秘密情報、削除すべきデータを分けることです。

終了の単位代表的な起点主な確認対象
契約・ワークスペース解約、組織統合、プラン変更、アカウント停止会話、ファイル、共有資産、メンバー、請求、保持・削除条件
業務アプリ・エージェント用途廃止、リスク超過、代替サービスへの移行プロンプト、ナレッジ、接続先、ワークフロー、評価、監査ログ
モデル・API・SDKモデル廃止、endpoint終了、仕様変更、preview終了モデルID、入力出力形式、ツール呼び出し、品質、安全性、費用、遅延

この3単位は終了日が一致するとは限りません。契約は継続していても特定モデルだけが終了することがあり、サービスの利用画面は残っていてもメンバー削除で履歴へアクセスできなくなることもあります。台帳では、サービス名だけでなく、ワークスペース、アプリ、エージェント、モデル、API、接続先を別行で管理します。

導入時のリスク審査と出口は役割が違います。デジタル庁の生成AI調達・利活用ガイドライン第2.0版を企業向けに整理した記事は、調達、権限、ログ、変更管理を一続きで見る考え方を扱っています。本記事では、そのうち終了・移行時に何を実行し、どの証跡で閉じるかに絞ります。

契約前に確認する出口設計の項目

出口計画は、エクスポートボタンの有無だけでは評価できません。取得できる対象、実行できる役割、出力形式、取得にかかる時間、リンクや添付の実体、別環境での再利用可能性まで確認します。画面上で読めるデータと、機械可読形式で持ち出せるデータは同じではありません。

領域契約・導入前に確認すること実査方法
業務依存止めると影響する部署、顧客、締切、外部連携、手作業の代替実際の業務フローと接続一覧を1件ずつ照合する
データ返却会話、ファイル、ナレッジ、設定、ログ、評価、メタデータの対象と形式テスト用ワークスペースで出力し、件数と添付実体を確認する
再利用性出力したJSON・CSV・ファイルを別環境へ取り込めるか代表データを代替環境で復元し、検索・権限・引用を再現する
権限誰がexport、組織削除、APIキー失効、請求停止を実行できるか管理者ロールを二名以上で確認し、退職者依存をなくす
保持・削除削除対象、処理期間、バックアップ、法令・セキュリティ上の例外規約と契約を確認し、削除依頼から完了回答まで試す
モデル寿命廃止通知、shutdown日、代替モデル、previewの扱い公式deprecationページと通知先メールを定期確認する
費用・契約解約期限、最低利用期間、従量課金、保存・移行支援の追加費用更新日の90日前を起点に購買・法務・経理で確認する

製品名から持ち出し可否を推測してはいけません。OpenAIの公式ヘルプでは、個人向けChatGPTの一部プランは設定やPrivacy Portalからデータを取得できますが、ChatGPT Businessワークスペースではデータエクスポートを利用できないと案内しています。一方、Claudeの公式ヘルプでは個人利用者に加え、Team・Enterpriseでは組織のPrimary Ownerがデータエクスポートを扱うと説明しています。つまり、同じ「生成AIチャット」でも、プランと役割で出口が異なります。

さらに、exportできても移行できるとは限りません。Claudeの公式資料は、個人アカウントから取得したデータを別の個人アカウントへimport・migrateする機能は提供していないと明記しています。ファイルを受け取れることと、会話構造、共有設定、プロジェクト、エージェントを別環境で再現できることは分けて検証します。

契約条項の確認は、AIサービス契約前の確認ポイントと組み合わせると整理しやすくなります。学習利用、個人データ、国外移転、規約変更に加えて、終了時のexport範囲、実行権限、支援費用、削除回答、モデル廃止通知を質問票へ入れてください。

AIサービスを安全に乗り換える6ステップ

出口作業は、旧サービスへのアクセスを止める前に、新しい環境で業務が続くことを証明する順番で進めます。先に解約すると、export権限、監査ログ、請求履歴、サポート窓口まで失い、足りないデータに気づいても取り直せません。

  1. 終了の起点と責任者を確定する:契約満了、モデル廃止、リスク超過などの理由、最終利用日、移行責任者、法務・セキュリティ・業務部門の承認者を決めます。対象サービスの新規ユーザー追加、新規ワークフロー、本番データ投入をいつ止めるかも決めます。
  2. 依存関係と資産を固定する:利用者、グループ、SSO、SCIM、APIキー、service account、webhook、RAGデータ、プロンプト、エージェント、定期処理、顧客向け機能を台帳化します。サービス名だけでなく、誰がどの業務で使い、止まると何が起きるかを記録します。
  3. exportして完全性を検証する:データ種別ごとの件数、期間、所有者、添付ファイル、文字コード、タイムゾーン、親子関係、削除済みデータの扱いを確認します。出力ファイルのハッシュ値と取得日時を残し、必要なら再度取得できる期間を確保します。
  4. 代替環境で並行評価する:代表業務を新旧で同時に実行し、正答率だけでなく、引用、拒否、安全性、権限、ツール実行、費用、遅延、監査ログを比較します。顧客送信やシステム更新を伴う処理は、最初から自動切替せず、人の承認を挟みます。
  5. 切替と旧権限停止を分けて実行する:新規処理の行き先を代替環境へ変え、成功率と例外を監視します。安定を確認した後、旧APIキー、OAuth token、webhook、SSO、SCIM、サービスアカウント、共有リンク、ローカルキャッシュを順に失効させます。必要なロールバック期間を過ぎるまで、旧環境を読み取り専用にできるかも確認します。
  6. 削除と契約終了を証跡で閉じる:削除依頼の対象、依頼者、日時、ベンダー受付、完了回答、例外として残るデータ、保存期限を記録します。請求停止、ライセンス削除、契約満了、ドメイン・アプリ連携解除を照合し、残件のないことを責任者が承認します。
切替判定進めてよい状態止める条件
データ対象件数と添付実体が一致し、代表データを復元できた重要データがexport対象外、または再取得期限が不明
業務主要タスクと例外処理を代替環境で完了できた顧客対応、法務、経理など高影響業務の結果が不安定
権限新環境の最小権限と監査ログを確認できた管理者権限が個人に集中、書き込み操作を追跡できない
復旧切替失敗時の戻し方、判断者、期限が決まっている新旧へ二重書き込みが続き、正本を判定できない

サービス障害を理由に緊急移行する場合も、データ削除まで一気に進めない方が安全です。SaaS障害時の案内では、影響、代替策、次回更新、復旧判定を利用者へ伝え、緊急の業務継続と恒久的な契約終了を分けます。

モデルやAPIの終了に備える方法

APIを組み込んだ業務では、サービス契約が残っていてもモデルID、endpoint、SDKが先に終了します。代替モデル名へ文字列を置き換えるだけでは、出力形式、tool calling、コンテキスト長、安全制御、費用、遅延が変わり、同じ業務結果にならない可能性があります。

OpenAIの公式deprecation資料は、2026年7月16日時点で、一般提供モデルには原則6か月以上、一般提供モデルの特化版には3か月以上の事前通知を設ける一方、previewモデルは2週間ほどの短い通知で終了する可能性があると説明しています。また、previewモデルを短期移行できない重要業務へ使うことを推奨していません。これはOpenAIの現行方針であり、全ベンダー共通の保証ではありません。利用する各社の通知期間と例外条件を確認してください。

デジタル庁の生成AI調達・利活用ガイドライン第2.0版の調達チェックシートは、生成AIモデルを置き換えやすいコンポーネント設計と、メジャーアップデート・移行時の品質・安全性検証を対策例として示しています。自社実装でも、モデル固有部分を業務ロジックから分離すると、終了通知を受けた後の変更範囲を狭められます。

準備するもの役割更新するタイミング
モデル台帳model ID、用途、所有者、環境、終了日、代替候補を追う月次と公式通知受信時
評価セット代表入力、期待結果、禁止例、境界例を固定する業務変更、事故、モデル変更時
adapter層モデル固有のAPI、tool schema、再試行を業務ロジックから分けるAPI・SDK仕様変更時
切替フラグ対象部署や処理単位で段階的に新モデルへ移す検証開始から本番安定まで
ロールバック手順品質低下や障害時に処理を止める、または戻す本番切替前に訓練する

代替モデルは、終了通知が来てから探すのではなく、少なくとも重要業務ごとに一つ用意します。候補を選ぶ際は、品質だけでなく、提供地域、データ処理、監査、利用上限、移行期限も比較します。代替を自動で呼び出せる設計でも、顧客送信や外部システム更新は品質差を確認するまで自動継続しない方が安全です。

削除確認と終了証跡に残すもの

「解約しました」という請求画面だけでは、データ削除と権限停止を証明できません。削除依頼では、ワークスペース、会話、ファイル、ナレッジ、ログ、バックアップ、学習済み派生物、サポート添付など、対象範囲を分けます。ベンダーが削除証明書を発行しない場合でも、依頼内容、受付番号、完了回答、規約上の処理期間、例外を一つの記録へまとめます。

OpenAIのChatGPT向け保持方針では、削除したチャットやアカウントは画面から直ちに消え、原則30日以内の恒久削除予定とされますが、匿名化済みデータや法的・セキュリティ上の必要がある場合は例外があると説明されています。また、チャットを削除してもLibraryに保存されたファイルは別管理となる場合があります。この例が示すように、「画面から見えない」「契約が終わった」「ベンダーシステムから削除された」は同じ状態ではありません。

一方で、旧環境の情報を無条件にすべて消すのも適切とは限りません。契約書、リスク評価、承認記録、利用者通知、評価結果、重大な出力、インシデント記録は、法令、訴訟ホールド、監査、社内規程に基づいて必要期間を判断します。APIキーやpasswordそのものを保存するのではなく、アカウント・秘密情報の識別子、失効日時、実行者、確認結果を残します。本記事は運用設計の一般情報であり、個別の法的保存義務は法務担当者へ確認してください。

終了証跡最低限残す内容
移行記録対象、export日時、件数、検証結果、保管場所、移行責任者
切替記録切替日時、対象業務、新旧環境、承認者、ロールバック期限
権限停止利用者、グループ、APIキー、OAuth、SSO、SCIM、webhookの停止結果
削除記録依頼範囲、受付番号、完了回答、処理期間、残存例外と根拠
契約・請求解約日、最終請求、最低利用期間、追加費用、返金・精算の有無
利用者案内停止機能、代替手段、問い合わせ先、旧リンク・旧データの扱い

出口計画で起きやすい失敗

  • 管理者を削除してから、exportや監査ログ取得に所有者権限が必要だと気づく。
  • CSVの取得成功だけで完了とし、添付ファイル、共有設定、会話の親子関係を復元できない。
  • 代替モデルの回答精度だけを比較し、tool calling、権限、拒否、安全性、費用差を確認しない。
  • SSOを止めても、APIキー、OAuth token、webhook、共有リンクが旧環境で生き続ける。
  • 契約終了とデータ削除を同じ日付だと思い込み、処理期間や法的例外を記録しない。
  • 移行中に新旧へ二重入力し、どちらが正本か分からなくなる。

NIST AI RMF Playbookは、第三者AIサービスの変更管理が不完全でないかを監視し、重要な第三者システムについて contingency processを検証し、リスク許容度を超えた場合は廃止する考え方を示しています。出口計画を年1回の文書確認にせず、契約更新前のexportテスト、四半期の権限棚卸し、モデル廃止通知の監視へ分けると、実行可能性を保ちやすくなります。

確認に使える公的・公式資料

よくある質問

AIサービスの出口計画とは何ですか?

AIサービスを縮小・停止するときに、業務継続、データ返却、代替環境への移行、権限停止、契約終了、データ削除までを安全に完了させる手順です。解約申請だけでなく、移行後の業務再現と旧環境の残存リスク確認まで含みます。

出口計画はいつ作りますか?

導入・契約前に初版を作ります。少なくとも更新日の90日前、重要機能の追加、データ種別の変更、モデル・APIの廃止通知、重大事故、料金や規約の変更時に見直します。実際にexportと復元を試さない計画は、アクセス喪失後に機能しません。

契約前にどのエクスポート機能を確認しますか?

会話、ファイル、ナレッジ、プロンプト、エージェント設定、利用者、権限、監査ログ、評価結果、請求履歴を分けて確認します。対象プラン、実行できる管理者、出力形式、処理日数、取得期限、添付実体、別環境での再利用可否までテストしてください。

解約後のデータ削除をどう確認しますか?

削除依頼の対象、受付番号、完了回答、処理期間、バックアップや法的保持の例外を記録します。ベンダーが証明書を発行しない場合も、公式の保持方針、サポート回答、管理画面の完了状態を一つの終了記録へまとめます。画面から見えないことだけで削除完了とは判断しません。

モデルやAPIが終了した場合の代替手段をどう準備しますか?

重要業務ごとに代替モデルを決め、代表入力、期待結果、禁止例を含む評価セットで並行検証します。モデル固有のAPI処理をadapter層へ分離し、段階切替、監視、ロールバック、旧キー失効を手順化します。previewモデルは通知期間が短い場合があるため、重要業務では短期移行できる設計が必要です。

エクスポート機能がないサービスは使わない方がよいですか?

一律に不採用とは限りませんが、重要データの正本にはしない、別システムへ定期保存する、APIで取得できる範囲を確認する、ベンダーの移行支援を契約するなどの補完策が必要です。補完後も業務継続や監査に必要な情報を持ち出せない場合は、用途を限定するか代替サービスを選びます。

関連ページと関連記事

AIサービスの選定・移行・運用設計について相談する

まとめ

AIサービスの出口計画は、契約を止めるためだけの手順ではありません。業務依存を把握し、必要なデータと設定を持ち出し、代替環境で同じ業務を安全に実行できることを確認したうえで、旧環境の権限、接続、データ、請求を閉じるための運用です。

まず、契約・ワークスペース、業務アプリ・エージェント、モデル・APIの3単位で台帳を作ります。次に、実データを使わないテスト環境でexportと復元を試し、更新日の前に代替候補を評価します。終了時は切替、権限停止、削除、契約終了を別々に確認し、誰が何を完了したかを証跡として残してください。

メディア一覧へ戻る