AIの開発会社を変えたい。データ・設定・運用を引き継ぐ準備

AI開発会社を変更する際は、契約条件の確認と資産の整理が最優先です。まずは現在のベンダーとの契約書を見直し、所有権やデータ削除義務を明確にしましょう。その上で、プロンプトや評価記録など引き継ぐべき情報を一覧化し、移行計画を立てることが安全な切り替えの鍵となります。

---

現行ベンダーとの契約内容を確認する

所有権はどこにあるか確認する

AIモデルや生成されたコンテンツの所有権が自社にあるか、ベンダー側に残るかは契約書に明記されています。所有権がベンダー側に残る場合、データの再利用や二次利用に制限が生じるため、担当者に「生成物の著作権はどこに帰属しますか？」と質問し、書面で確認してください。所有権が自社にあることが確認できれば、次のベンダーへスムーズに引き継げます。

所有権の有無は、ライセンス条項だけでなく、サブスクリプションの利用規約にも記載されていることがあります。契約書全体を俯瞰し、特に「知的財産権」や「成果物の利用範囲」の項目を重点的にチェックし、曖昧な表現があれば法務部と相談して補足条項を求めましょう。

データ削除義務と期間を把握する

ベンダーが保持している学習データやログについて、契約終了後に削除すべきかは契約書で確認してください。削除義務の有無や実施期間を明確にするため、担当者に「契約終了後、どのデータをいつまでに削除する予定ですか？」と具体的に質問し、書面での回答を求めることが重要です。削除が遅れると情報漏洩リスクが高まる可能性があります。

削除義務が明示されていない場合は、ベンダーに対して削除手順書の提供を依頼し、実際に削除が完了したことを証明できるレポートを取得してください。これにより、後続ベンダーに対して安全にデータを移行できる根拠が得られます。

違約金や解約手続きの条件は？

契約解約時に発生する違約金や手続きのハードルは、予算計画に直接影響します。担当者に「解約に伴う違約金は何円ですか？」や「解約手続きは何ステップ必要ですか？」と具体的に質問し、金額と期間を明確に把握してください。違約金が高額な場合は、交渉余地があるか法務部と検討します。

解約手続きに必要な書類や通知期間が契約書に記載されているかを確認し、社内のスケジュールと合わせて調整してください。解約条件を正確に把握すれば、次のベンダーへの移行計画を確実に立てることができます。

---

引き継ぐ資産を一覧化する

プロンプトとモデル設定の棚卸し

AIシステムで使用しているプロンプトやモデルのハイパーパラメータは、業務成果に直結する重要資産です。まずは、担当者に「現在利用中のプロンプトは何ですか？」と一覧化を依頼し、ExcelやGoogleスプレッドシートに項目（名称、目的、バージョン、更新日）を整理しましょう。プロンプトのバリエーションが多い場合は、カテゴリ別に分けると管理しやすくなります。

モデル設定（例：トークン上限、温度、トップP）も同様に記録します。設定値はベンダーごとに微妙に異なることがあるため、次のベンダーで同等の性能を確保できるか事前に検証が必要です。設定情報はテキストファイルで保存し、変更履歴をGitなどで管理すると、後からの追跡が容易です。

評価結果と評価指標の保存場所

AIの効果測定に使う評価結果や指標は、ベンダー変更後のパフォーマンス比較に不可欠です。担当者に「評価レポートはどこに保存していますか？」と尋ね、PDFやCSV形式で一元管理できる場所を確保してください。評価指標（例：BLEU、ROUGE、ユーザー満足度）とその算出方法も併せて記録します。

評価データは機密情報を含む場合があるため、アクセス権限を限定したフォルダに保存し、バックアップも別媒体に取っておくと安全です。新ベンダーへ移行する際は、同一指標で再評価できるようにデータ形式を統一しておくことが重要です。

連携APIと認証情報の管理

AIシステムは社内システムや外部サービスとAPIで連携しています。APIエンドポイント、認証キー、OAuthトークンなどは、セキュリティ上のリスクが高いため、担当者に「現在使用中のAPIキーは何ですか？」と具体的に聞き出し、一覧表にまとめます。キーの有効期限やローテーションポリシーも併記してください。

取得した情報は、パスワードマネージャーや暗号化されたスプレッドシートに保管し、アクセス権は最小限に限定します。新ベンダーへ移行する際は、同様の認証方式が利用できるか、もしくは新たに発行する必要があるかを事前に確認し、移行計画に組み込みます。

---

新ベンダーへの移行手順を設計する

データ移行のフォーマットを決める

移行対象となるプロンプトや評価データは、ベンダー間でフォーマットが異なることがあります。担当者に「CSV形式でエクスポートできますか？」と確認し、共通フォーマット（例：UTF-8 CSV）を決定します。フォーマットが統一されていれば、インポート時の変換作業が減り、ミスも防げます。

フォーマット決定後は、サンプルデータでテストインポートを行い、文字化けや項目欠損がないか検証してください。問題が見つかった場合は、変換スクリプト（PythonやShell）を作成し、再利用できるようにリポジトリで管理すると、今後のメンテナンスが楽になります。

テスト環境での動作確認手順

本番環境に移行する前に、テスト環境で全機能を検証することは必須です。担当者に「テスト用のサンドボックス環境はありますか？」と問い合わせ、以下の手順をチェックリスト化します：① データインポート、② プロンプト実行、③ 評価指標の算出、④ API連携の確認。各項目の期待結果と実測結果を比較し、差異があれば原因を特定します。

テスト結果はレポートにまとめ、関係者（開発・運用・経営）に共有します。問題が解消できない場合は、ベンダー側のサポート窓口に問い合わせ、修正対応のスケジュールを確定させてから本番移行に進みます。

移行スケジュールと担当者割り振り

移行は段階的に実施することでリスクを最小化できます。担当者に「移行作業は誰がいつ担当しますか？」と具体的に聞き、以下のフェーズを設定します：① 契約解約手続き、② 資産エクスポート、③ テスト環境導入、④ 本番切替、⑤ 旧ベンダーのデータ削除。各フェーズの開始日・完了日をガントチャートで可視化し、遅延リスクを早期に把握できるようにします。

また、緊急時のバックアウトプラン（例：旧ベンダーに一時的に戻す手順）も併せて策定し、担当者全員に周知しておくことが重要です。スケジュール通りに進められない場合は、原因を分析し、次フェーズの調整を迅速に行います。

---

移行後の運用体制とリスクを見直す

新ベンダーのセキュリティ基準を比較

新ベンダーを選定する際は、セキュリティ基準の比較を行います。担当者に取得している認証（例：ISO/IEC 27001、SOC 2 など）や内部監査の実施状況を資料で提示してもらい、確認してください。認証が取得されていない場合は、暗号化やアクセス制御といった代替のセキュリティ対策が実施されているかを評価します。

比較表を作成し、現行ベンダーと新ベンダーのリスク項目（データ漏洩、インシデント対応、バックアップ体制）を一覧化します。リスクが高い項目については、導入前に追加のセキュリティ措置をベンダーに要求し、契約書に明記することで、移行後のトラブルを防止できます。

運用マニュアルの更新ポイント

AIシステムの運用マニュアルは、ベンダー変更に伴い更新が必要です。担当者に「現在のマニュアルはどこに保管していますか？」と尋ね、以下の項目を新ベンダー向けに書き換えます：① インストール手順、② 設定変更手順、③ 障害時の連絡フロー、④ 定期的な評価実施方法。変更箇所は色分けしてわかりやすく示すと、運用担当者が混乱しません。

マニュアルは社内Wikiやドキュメント管理システムに掲載し、変更履歴を残すことで、将来のバージョン管理が容易になります。また、マニュアル更新後は、担当者全員にレビュー会議を実施し、理解度を確認することが推奨されます。

継続的な監査と改善の仕組み

ベンダー変更後も、AIシステムのリスクは継続的に管理する必要があります。担当者に「監査はどの頻度で実施しますか？」と聞き、四半期ごとの内部監査計画を策定します。監査項目は、データアクセスログの確認、評価指標のトレンド分析、セキュリティパッチ適用状況などです。

監査結果は改善提案として文書化し、経営層に報告します。改善策が実行されたかどうかをトラッキングできるよう、タスク管理ツールで進捗を可視化することで、継続的な品質向上が実現します。