AIサービスを乗り換える前に｜プロンプト・履歴・業務を引き継ぐ計画

AIサービスの乗り換えは、契約先を変えるだけでは終わりません。先に決めるべきなのは、何を旧環境から持ち出し、何を新環境で作り直し、どの業務が再開できたら旧環境を止めるかです。データをエクスポートできても、そのまま新サービスへ読み込めるとは限りません。

したがって、判断の単位を「サービス全体」から「業務×資産」へ細分化します。会話履歴は保存できるか、共通プロンプトは原本があるか、権限や外部連携は誰が再設定するか。これらを退出台帳で分け、重要業務の受入条件を満たしたものから切り替えます。残る難所は、エクスポートできたファイルを「引き継げた業務」と誤認しないことです。

AIサービスの乗り換えを決める退出台帳

旧サービス内にあるものを一括して「データ」と捉えると、作業の違いを見落とします。履歴のように持ち出せるものと、権限のように環境ごと作り直すものでは、担当者も確認方法も異なるからです。次の判断表は、各社が自社の退出計画へ当てはめるための実務提案です。

この表では、「持ち出す」と「そのまま使える」を別の状態として扱います。たとえば共通プロンプトの文面を保存できても、参照できる情報、システム指示、モデルの挙動が変われば同じ業務結果は保証されません。文面は資産として持ち出し、動作は新環境で受け入れ直します。

公式エクスポートで分かること、分からないこと

2026年9月21日時点の公式情報では、ChatGPTのデータエクスポートで取得するZIPに、チャット履歴とその他の関連アカウントデータが含まれます。一方、削除済みのチャットは復元できません。OpenAIは、個人ワークスペースを管理対象ワークスペースへ移動・統合する前に、エクスポートを要求し、ダウンロード後に内容を確認するよう案内しています（OpenAI「Exporting your ChatGPT history and data」）。

ただし、設定画面からのセルフサービス・エクスポートは対象プランに限られます。同日時点でBusiness、Enterprise、ChatGPT for Healthcareでは利用できず、組織管理データはワークスペース所有者への確認が必要です。Eduも役割、ワークスペース設定、データレジデンシーによって可否が変わります。つまり、退出台帳には対象データだけでなく「誰が取得できるか」「いつ確認したか」も必要です。

Claudeについても、2026年9月21日時点の公式情報では、個人向けエクスポートに会話データとアカウントのユーザーデータが含まれます。TeamまたはEnterpriseでは、組織のPrimary Ownerだけがエクスポートへアクセスできます。さらに、エクスポート済みデータを別の個人Claudeアカウントへインポートすることや、個人アカウント間の移行はサポートされていません（Anthropic「Export your Claude data」）。

ここから導くべき実務判断は明確です。公式仕様が示すのは、取得対象や実行権限などの範囲です。「別サービスで業務を再開できる」という保証ではありません。エクスポートファイルはまず保存用アーカイブとして扱い、その中から再利用するプロンプト、判断記録、参照資料を自社の管理単位に戻します。

旧環境を止める条件を業務ごとに決める

全社一斉の切替日だけを決めると、重要業務の一部が旧サービスの共有設定や連携に依存していても見えません。NISTのAI RMF Playbookは、AIシステムを安全に停止・廃止する際の検討対象として、業務中断と下流への悪影響を抑える標準手順、冗長系またはバックアップ、判断基準、記録、変更管理、代替手段を挙げています。第三者AIシステムには組織のリスク許容度を適用し、使用する技術・人員・資源を文書化し、ミッションクリティカルなシステムの代替手順を検証することも提案しています（2026年9月21日確認、NIST AI RMF Playbook「Manage」）。

この公式資料を自社の退出判断へ落とすなら、各業務に次の条件を持たせます。

• 旧環境への依存関係が台帳に記録されている
• 必要な履歴のエクスポートを実施し、対象会話の収録と閲覧権限を確認した
• 新環境の権限、連携、指示、評価条件を再設定した
• 新環境で業務責任者が受入確認を行い、記録を残した
• 障害時の代替手順と停止を判断する責任者が決まっている

一つでも欠けたら必ず全社切替を延期する、という意味ではありません。欠けた条件の重さを業務ごとに判断し、「対象外化」「一定期間の併用」「手作業への退避」のどれを採るか承認します。顧客対応など下流への影響がある業務と、個人の試行用途を同じ基準で止めないことが肝心です。

切替判定の具体例

たとえば、社内文書の下書き業務を移す場合を考えます。持ち出す資産は、承認済みプロンプトの原本、参照が必要な会話履歴、評価時の確認観点です。作り直す設定は、新環境の利用者権限、共有範囲、システム指示、参照先との連携です。

受入確認では「ログインできた」だけを合格にしません。入力してよい情報の範囲を守れること、必要な出力形式になること、承認者へ渡す流れが機能すること、問題時に手作業へ戻せることを業務責任者が確認します。会話履歴を直接インポートできなくても、保存用アーカイブへの参照方法が決まり、日常業務に必要な原本が別管理されていれば、切替可能と判断できます。

履歴ZIPを取得済みでも、共通プロンプトが個人の会話内にしかなく、外部連携の所有者も分からないなら、退出準備は未完了です。切替可否の境目は、ファイルの有無よりも、業務を新環境で再現でき、問題時には手作業へ戻せるかにあります。

削除・解約より先に実行する順序

退出作業は、棚卸し、取得、再構築、受入、停止の順で進めます。とりわけ削除は、エクスポート後に回します。削除済みデータを復元できない製品仕様があるためです。

1. 業務責任者が対象業務と許容できない影響を定める
2. 管理者が資産、設定、所有者、確認日を退出台帳へ記録する
3. 権限を持つ担当者が公式手順でエクスポートし、必要な対象が含まれるか確認する
4. 新環境で権限、連携、指示、評価条件を作り直す
5. 業務責任者が受入確認を行い、未達項目には代替策を割り当てる
6. 停止責任者が旧環境を止める範囲を承認する
7. 保存ルールに従って旧環境の削除・解約を判断する

この順序は、サービス選定の優劣を決めるものではありません。現在の業務資産を失わず、残る依存関係を承認可能な状態にするためのものです。社内の入力ルールや責任分界が曖昧なら、先に生成AIガイドラインの作り方と運用の要点を整理すると、持ち出す履歴と廃棄候補を判断しやすくなります。切替後の定着まで含めて担当と節目を置く場合は、AI導入を最初の90日で進める実行計画も確認できます。

乗り換えの結論は「業務を再開できるか」で出す

AIサービスを乗り換える実行条件は、エクスポートボタンの有無では決まりません。退出台帳で会話履歴などを「持ち出す資産」、権限・連携・指示・評価条件を「作り直す設定」に分け、保存用アーカイブと再利用する業務資産も区別します。そのうえで、重要業務ごとに代替手順、停止責任者、依存関係、保存記録、新環境での受入確認が揃ったかを判定します。

未達の業務は、対象外化、一時併用、手作業への退避のいずれかを明記します。旧環境の削除・解約は、権限を持つ担当者がエクスポート内容を確認した後です。これなら「データは取れたが業務が動かない」という取り違えを避け、経営者は残存リスクを、AI推進担当者は次の作業を同じ台帳で判断できます。