AIサービスを契約する前に決める「乗り換え条件」

たとえば、社内文書の作成支援に使う生成AIサービスを選び、年間契約の稟議を回す場面を考えます。試用では十分な文章ができ、利用料金も予算内です。ところが「モデルが変わったら誰が検証するか」「契約終了時に何を持ち出せるか」は、提案書から読み取れません。

契約前に決めたいのは、現在の性能だけでなく、別のサービスへ移るための条件です。本稿では、業務で蓄積する指示や設定、評価用の入力例のうち、何を自社で管理するかを先に定めることを勧めます。そのうえで、小さな移行試験を発注条件に入れます。

利用を始める判断と、使い続ける判断を分ける

デジタル庁は生成AI利用環境「源内」を2025年5月から庁内で運用し、他府省庁への展開では2026年度の大規模導入実証と2027年度からの本格利用を区別しています。[1] この事例から読み取りたいのは、利用環境の提供と、継続利用の条件を固める作業を分ける視点です。民間企業でも、試用の承認と長期契約の承認は、別の判断として扱うのが妥当でしょう。

モデルを固定しておけば、変更への備えは不要でしょうか。Microsoftの公式文書では、Foundryのモデルには廃止段階があり、廃止済みモデルへの推論要求はエラーになります。また、後継のモデルが同じ地域で提供されるとは限らないと説明しています。[3] これは同社サービスの仕様であり、すべての生成AI製品に一律に当てはまる条件ではありません。

だからこそ、契約期間とモデルの提供期間を同一視せず、候補ごとに確認してください。終了通知の受信先、社内の判断担当、代替候補を試す時期まで決めておくべきです。

「持ち出せる」を、成果物ごとに定義する

最初に作るのは、製品の機能比較表よりも、移行時に受け渡す資産の一覧です。指示文、処理手順、参照する原本、業務用語の定義、出力形式、評価用の入力例と判定基準を並べ、それぞれの管理者と保存先を記入します。すべてを社外へ移す前提ではなく、移してよい範囲も同時に定めます。

デジタル庁の調達・利活用ガイドライン第2.0版は、調達チェックシートで、モデルの版情報の明示と、移行の容易性を踏まえた設計・実装を基本項目にしています。一方、チャット履歴や登録したプロンプトの書き出し機能は任意追加の加点項目です。[2] 本稿では、この行政向けの項目を民間の調達条件を考える参考として使います。

「データを出力可能」との回答だけでは、受け渡し条件として不十分です。何が、どの形式で、いつまで、誰の操作で取り出せるかを指定しましょう。添付の原本と参照先の対応、設定値の意味、履歴の日時まで残すかも、用途に応じて決めます。出力対象外の項目は空欄にせず、対象外とした理由を書いてもらいます。

たとえば、申請書を要約する仕組みなら、会話履歴だけを受け取っても、部署ごとに追加した指示や参照した資料の版が分からない状態では、移行先で同じ条件を再現できません。書き出すファイルの数より、業務を組み直すための情報がそろうかを確認する必要があります。

契約前に、別環境で一つの業務を組み直す

移行試験は、候補サービスの全機能を再現する競争にしないでください。対象業務を一つに絞り、受け取った資産から、別環境で処理を組み直します。ここでは、移行元の事業者にしか分からない設定がどこに残るかを見つけます。

Microsoftのモデル移行手順も、移行先を選ぶ前に代表的な入力、期待する出力、成功基準を用意し、比較中はそれらを固定するよう勧めています。[4] 同じ事業者内のモデル変更に向けた助言ですが、サービス間の移行試験にも使える考え方です。以下は、その考え方を調達に適用する本稿の提案です。

まず、通常の入力だけでなく、記入漏れや表記揺れのある例を利用部門が選びます。次に、開発側が移行元の設定を取り出し、移行先で使える形に直します。最後に、業務担当者が元の条件と照らして確認します。モデルごとに指示文を調整しても、採点する入力や合格条件は変えません。

判定は、文章が似ているかより、必要事項が保たれるかを重視します。たとえば申請内容の要約なら、金額、期限、未確定事項を落とさないことを条件にします。調整に要した作業と、移せなかった情報を記録し、その残作業を見積もってから契約範囲を確定する順序が適切です。

専用機能を使うかは、移行費用と並べて決める

選択肢は三つあります。一つは、特定製品の機能を深く使う方法です。必要な機能を早く組み合わせられると判断したなら、有力な選択になります。ただし、専用の設定を作り直す費用を、導入費とは別に見積もるべきです。

二つ目は、複数製品に共通する機能だけに制限する方法です。この方針なら仕様をそろえやすい反面、使いたい専用機能を諦める必要が出ます。乗り換えのために業務上の価値をどこまで犠牲にできるか、利用部門の判断が欠かせません。

三つ目として、本稿は、業務の指示や合格条件を自社管理にし、製品固有の接続・設定を分けて持つ方法を推奨します。完全な互換性を目指すのではなく、作り直す範囲を把握できる状態を目標にします。ただし、設定の二重管理には保守の負担が伴うため、単一製品に任せる案とも費用を比較してください。

比較表には、通常の利用料に加え、資産の書き出し、設定の変換、再検証、利用者への説明、移行期間の二重利用を入れます。乗り換えを発動する条件も、料金の許容上限、必要機能の提供終了、社内の利用条件との不一致などから選び、担当者を決めておきます。

過剰な備えを避け、責任の空白を埋める

短期の試用で、保存すべき業務資産がなく、終了後に成果物を引き継がないという場合には向きません。そのような利用に、複数製品へ対応する共通基盤まで作る必要はないでしょう。データの保存・削除条件を確かめ、試用の終わりを決める程度にとどめます。

継続利用する業務では、情報システム部門だけに移行責任を置かないでください。調達担当は受け渡し範囲と費用を、利用部門は業務上の合格条件を、開発・運用側は設定の変換と再構築を受け持つ分担が考えられます。契約を確認する担当も交え、どこまでが通常保守で、どこからが追加作業かを明文化します。

顧客と企画から試作、実装、定着まで進めるForward Deployed Engineering（FDE）の進め方を採るなら、試作中に分かった移行上の制約も、発注側に引き継ぐ成果物に含めるべきです。乗り換えを決めた時点で初めて見積もるのでは、採用時に比較した費用の範囲が狭すぎます。

実務への示唆

提言1：提案依頼に、資産の受け渡し一覧を添えてください。 書き出す対象、形式、対象外の情報、提供時期、担当者を回答項目にします。

提言2：契約前の確認に、小さな移行試験を入れてください。 一つの業務を別環境で組み直し、必要な情報の欠落と、調整作業を見積もります。

提言3：専用機能の採用理由と、離れる条件を一緒に残してください。 利便性を選んだ判断は尊重しつつ、変更通知を受ける人、移行予算を判断する人、業務を確認する人を具体的に決めます。

参考資料

1. デジタル庁「ガバメントAI「源内」」（公開・更新日不明、確認日：2026-09-21）
2. デジタル庁「行政の進化と革新のための生成AIの調達・利活用に係るガイドライン」（第2.0版、2026-06-12更新、確認日：2026-09-21）
3. Microsoft「Microsoft Foundry Models lifecycle and support policy」（2026-07-24更新、確認日：2026-09-21）
4. Microsoft「Model migration process」（2026-08-19更新、確認日：2026-09-21）

本記事はAIを活用して作成し、公開前に自動レビューを実施しています。情報の確認日：2026-09-21。