生成AIを業務へ深く組み込むほど便利さは増します。
会議メモから提案書を作り、社内資料を検索し、顧客対応の下書きを整え、定型処理まで自動化できるようになるからです。
その一方で、会社の仕事の進め方がAIサービスの中に沈み込んでいきます。
優れたプロンプト、過去の修正履歴、社内用語、承認ルール、顧客ごとの注意点。
こうした知識が特定サービスでしか使えない状態になると、AIツールの価格改定や機能変更が起きた際に別の選択肢へ移りにくくなります。
AIベンダーロックインは契約を解約できない状態だけを指しません。
解約はできても、同じ品質で仕事を続けられない。
引き継ぎに数か月かかる。
何を移せばよいか分からない。
これらも実務上は依存です。
ここで必要なのはすべてを自社開発することでも、毎回複数のAIへ同じ作業をさせることでもありません。
会社の知識と判断基準を、特定サービスから切り離して管理する設計です。
従来のクラウドサービスでは、ロックインは主にデータ形式や契約条件の問題として語られてきました。
生成AIではそこへ「仕事の文脈」が加わります。
たとえば、あるチームがChatGPTのプロジェクト機能に資料を蓄積し、専用GPTへ指示文を登録し、担当者が会話を重ねながら出力品質を高めたとします。
表面上は文書ファイルをダウンロードできても、修正の癖や暗黙の判断基準までは簡単に持ち出せません。
依存はデータ、ナレッジ、権限、ログ、ワークフローの五層で起きます。
データでは形式変換や権限再設定、ナレッジでは品質基準の再現、権限ではID管理の再構築、ログでは監査証跡の連続性、ワークフローではコネクタやエージェントの作り直しが課題になります。
料金が上がったときだけ困るのではありません。
モデルの提供終了、管理機能の変更、コネクタ仕様の更新、データ保存地域の変更でも影響が出ます。
したがって、契約更新の時期だけ確認するのでは遅く、導入時から移行可能性を持たせる必要があります。
生成AIは完成品を保存する場所というより、仕事を一緒に進める場所です。
会話の途中で条件を追加し、出力を直し、参考資料を読み込ませます。
その過程に価値があるため、最終ファイルだけを持ち出しても再現性が残りません。
また、利用者が独自に使い方を工夫しやすい点も依存を見えにくくします。
情報システム部門が把握していない個人用プロンプト、ブラウザ拡張、外部コネクタが増えると、組織として何に依存しているかを一覧化できなくなります。
さらに、法人向けサービスのデータ保護は強化されていますが「学習に使わない」と「保存しない」は同じではありません。
障害対応、不正利用の監視、監査、法的義務などのために一定期間保持される場合があり、契約や機能によって条件が変わります。
公式情報を読む際はモデル改善への利用、サービス提供のための保存、管理者が設定できる保持期間、削除要求後の処理、バックアップからの消去、接続先アプリ側に残るデータを分けて確認してください。
「入力データは学習されない」という一文だけで判断すると、監査や解約時の論点が抜け落ちます。
原本がどこにあるかを決めます。
AIへアップロードした資料を正本にせず、社内ストレージや文書管理システムに原本を残すのが基本です。
AI側に複製されたデータについては、保存地域、暗号化、保持期間、削除手順、学習利用の有無を契約単位で確認します。
価値の高いプロンプトは会話画面に埋め込まず、目的、入力条件、出力形式、禁止事項、検収基準をテンプレートとして管理します。
社内用語集や顧客別ルールも特定AI専用の説明文ではなく、人が読んでも使える文書にしておくと移行が容易です。
AIが参照できる情報は利用者本人の権限を超えない設計が原則です。
Microsoft 365やGoogle Workspaceのように既存権限を利用する製品でも、共有設定が広すぎればAIはその広さを引き継ぎます。
AI導入前に共有ドライブやサイト、グループ権限を整理する必要があります。
企業利用では入力内容、参照したデータ、出力、承認者、実行結果をどこまで追跡できるかが重要です。
監査ログが管理者画面で閲覧できても、保持期間やエクスポート形式が十分とは限りません。
重要業務では、AIサービス外にも実行記録を残します。
料金だけでなく機能終了時の通知、データ返却、削除証明、サブプロセッサー、データ移転、損害責任、SLAを確認します。
契約終了後に何日間アクセスできるか管理者が一括エクスポートできるかは、移行計画へ直接影響します。
各社は法人データをモデル学習へ使わない方針を掲げていますが、管理機能、保存、連携の考え方は同一ではありません。
2026年7月時点での比較は、公開前に必ず公式ページで更新してください。
ChatGPT Business / Enterpriseは汎用性が高く、プロジェクトやカスタム機能を業務へ組み込みやすい一方、会話、プロジェクト、カスタム設定のエクスポート範囲、保持設定、外部コネクタを確認します。
Claude for Workは長文処理やプロジェクト文脈、コネクタを使った知識活用に強みがあります。
プロジェクト知識、Artifacts、コネクタ経由データ、契約別の保持期間を点検します。
Microsoft 365 CopilotはMicrosoft Graphと既存権限を基盤にOffice業務へ入りやすい製品です。
SharePointの権限設計、Purview監査・保持、Copilot Studioで作ったエージェントが移行範囲になります。
Gemini for Google WorkspaceはGmail、Drive、Docs、Meetとの統合が自然です。
Drive共有範囲、Vault・監査ログ、Geminiアプリの履歴設定、拡張機能を確認します。
製品の優劣ではなく、現在の業務基盤との距離で選ぶべきです。
統合が深いほど教育や管理は簡単になりますが、移行対象はAIだけでなく、文書共有、ID、監査、アプリ連携まで広がります。
最初に行うべきはマルチクラウド化ではなく棚卸しです。
使っているAI、契約プラン、管理者、入力データ、接続先、重要プロンプト、自動化の一覧を作ります。
個人利用の無料アカウントが混在している場合は、業務利用の範囲を法人管理へ移します。
次に、再利用したい知識をAIの外へ出します。
プロンプト集だけでは足りません。
良い出力の例、悪い出力の例、確認項目、承認が必要な条件まで残します。
これにより、別モデルへ移っても評価基準を引き継げます。
三つ目は、業務ごとに代替経路を一つ用意することです。
普段から二重運用する必要はありません。
障害や契約変更が起きたとき、手作業へ戻せるのか、別AIへ切り替えるのか、処理を停止するのかを決めます。
四つ目は、四半期ごとの移行テストです。
重要なテンプレートを別環境で一度実行し、必要なデータ、手順、品質差を確認します。
実際に試さなければ、エクスポート可能という説明だけでは移行時間を見積もれません。
データ：原本の保存先、学習利用、保持期間、保存地域、削除方法を確認したか。
ナレッジ：プロンプト、用語集、評価基準をAIの外でも読める形にしたか。
権限：AIが参照する共有範囲と管理者権限を点検したか。
ログ：重要な実行履歴と承認記録を外部へ残せるか。
契約：解約時の返却、削除、通知、SLA、サブプロセッサーを確認したか。
移行：別サービスまたは手作業へ戻す手順を試したか。
AIベンダーロックインをゼロにすることは現実的ではありません。
業務基盤を統一すれば、教育や管理は楽になり、品質も安定します。
問題は依存そのものではなく、依存の範囲を把握せず、抜け道を持たないまま深く組み込むことです。
会社が保持すべきなのは特定モデルの操作方法ではありません。
顧客へ何を約束し、どの情報を根拠にし、どこで人が判断し、何を良い成果物とするかという業務知識です。
そこが自社に残っていれば、AIサービスが変わっても仕事は再構築できます。
導入時に、保存、権限、ログ、契約、移行を確認する。重要なテンプレートと評価基準を外部管理する。
年に数回は代替経路を試す。この程度の備えでも、選択肢は大きく広がります。
.png){kind=logo}
