2022年の秋、フォンターナで自動車部品の配送倉庫を経営する友人から、興奮した様子で電話があった。入荷ラインにAI画像検査を導入したばかりだという。インバウンドレーンの上に産業用カメラを設置し、部品の欠品、ラベルの貼り間違い、段ボールの破損を自動で検出する。手作業のチェックよりはるかに速い。私は彼を祝福したが、ひとつ気になることがあった。そのシステムの裏にいるのは、シリーズAの資金調達を終えたばかりのスタートアップだったのだ。
1年後、そのスタートアップは倒産した。クラウドサービスは停止し、モデルの更新は止まった。そして最悪だったのは、検査システムがベンダーのクラウドAPIに紐づいていたことだ。サービスが死んだとき、検査ライン全体が一夜にして止まった。友人は再入札と再導入に3か月以上を費やした。繁忙期は来て、去っていった。彼が失ったのは、後で本人が言うには、システムの費用ではなかった。繁忙期の3か月にわたる手作業のやり直しと、去っていった顧客だった。
それ以来、AIを検討するすべてのクライアントに、必須の質問をひとつ加えている。「もしベンダーが消えたら、どうなりますか？」これは悲観的な話ではない。AIを買うことは、設備を買うこととは違う。コンベアを買えば、それは自分のものだ。AIシステムの場合、モデルもデータもソースコードも、デフォルトではベンダーのものだ。ベンダーが生きている間は、すべてうまくいく。ベンダーが消えたら、システムを開くことさえできない。
出口条項のない契約は、契約ではない
AIベンダーの契約書の多くは、退出についてたった1行しか書いていない。「契約終了後30日以内にサービスは停止する。」そんなものは空白と同じだ。本当に必要なのは4つの項目だ。
第一に、ソースコードのエスクロー。ソースコード、モデルの重み、デプロイ文書を、中立的な第三者のエスクローエージェントに預け、解除トリガーを明記する。ベンダーの倒産、合意した日数を超えるメンテナンスの停滞、買収後の製品ライン廃止——いずれかが発生すれば、エスクローは顧客に解放される。これがなければ、ベンダーが倒産した日に、システムの中身を見ることさえできない。
第二に、データの返還。形式、期限、完全性を明記する。生データとラベル付きデータセットがどんな形式で戻ってくるのか（開けない独自形式は不可）、契約終了から何日以内か、そしてベンダーはその後、自社のコピーを削除しなければならない。この条項を省けば、あなたの業務データはただの贈り物になる。
第三に、モデルの重みの所有権。あなたのデータで学習したモデル——その重みは誰のものか？多くの契約はデフォルトでベンダーのものにし、「共同所有」のような曖昧な表現を使う。明確な文言を要求しよう。顧客のデータで学習したモデルと派生重みは、顧客に帰属する。ベンダーが応じない場合は、最低限、契約終了後も有効な永久的かつ取消不能なライセンスを確保する。
第四に、移行サポート。契約終了後、ベンダーは数か月間の読み取り専用の運用サポートを提供するか、セルフホスティングの権利を付与する。移行は一夜では終わらない。移行の猶予期間がなければ、旧システムは新システムが稼働する前に死に、間のギャップを誰も埋められない。
営業は契約の際にこう言うだろう。「うちは大企業だ」「資金調達したばかりだ」「倒産するはずがない」。信じてはいけない。過去数年で、資金の潤沢なAIスタートアップが数多く倒産し、買収後に製品ラインを廃止されたケースも数多くある。あなたにとっての結果は同じだ。あなたのシステムを保守する者がいなくなる。
本当にあなたのものは、データだけだ
一歩引いて考えよう。完璧な契約があっても、ベンダーが本当に消えたら、何が業務を回し続けるのか。データだ。モデルは置き換えられる。ベンダーも置き換えられる。置き換えられないのは、長年蓄積してきたラベル付きデータと業務ルールだ。
ラベル付きデータはあなたの中核資産だ。画像検査の不良サンプル、音声ピッキングの訂正ログ、需要予測に使う過去の受注データ——ベンダーはこれらをあなたのビジネスの上に築いたのだから、契約書であなたのものだと明記しなければならない。データが手元にあれば、新しいベンダーでの再学習は数か月で済む。データがなければ、ゼロからのスタートとなり、それには何年もかかる。繁忙期には、その差が生き残りとそうでないことの分かれ目になる。
業務ルールも同じくらい価値がある。AIシステムに組み込まれたしきい値、例外処理ロジック、プロセス固有のルール——たとえば、どの製品カテゴリにどの検査基準を適用するか——は、ベンダーのシステムに置いたままにせず、定期的にドキュメントとしてエクスポートすべきだ。私が見た最悪のケースは、失われたモデルではなかった。3年分の検査基準が、すべてベンダーの設定データベースの中にだけ存在していたのだ。ベンダーが去るとき、基準も一緒に去り、後継のベンダーはすべてを一から学び直さなければならなかった。
では、オープンソースのモデルで代替できるのか？私の見解は、用途による。画像検査やOCRのような成熟した領域には、オープンソースの選択肢が豊富にある。移行コストは主に再ラベリングと再統合で、社内のMLエンジニアが数人いれば対応できる。しかし、業務ロジックが倉庫システムと深く絡み合ったスケジューリング最適化や需要予測のような領域は、話が別だ。そこでベンダーを切り替えるとは、プロジェクトの半分を作り直すということだ。選定の際にこう問おう。「もしこのベンダーが消えたら、妥当なコストで引き継げますか？」答えがノーなら、導入しないか、退出コストを総所有コストに織り込むかだ。
毎年、出口訓練をやろう——本気で
条項を書き、データを確保し、あと一歩残っている。練習だ。火災訓練を縁起が悪いと思う人はいない。出口訓練も同じことだ。年に1回、シンプルな演習を行う。ベンダーが明日消えると想定し、数日かけて3つのことを確認する。データが完全にエクスポートできるか、モデルが自社環境で動くか、重要な業務プロセスにベンダーに依存しない手動の代替手段があるか。
初回の訓練は、ほぼ確実に失敗する。エクスポートしたデータにフィールドが欠けている、モデルがベンダーの独自ライブラリに依存している、重要なレポートがベンダーのポータルにしかない。失敗は朗報だ。計画に穴があるということで、ベンダーがまだいるうちに直せる。ベンダーが消えた後では、手遅れだ。
大がかりにする必要はない。ITリーダーが主導し、現場が参加し、年に1回、半日から1日かけて行う。安い保険であり、計画が絵に描いた餅ではないことの唯一の証明だ。もうひとつのメリット：訓練レポートは保管しておこう。次回の更新交渉では、交渉材料になる。ベンダーが「あなたは去れる」と知れば、値上げはかなり控えめになる。
さて、最初の質問に戻ろう。AIは導入する価値があるのか？答えはイエス——だが、出口がある場合に限る。ベンダー選定の際は、デモに感心するだけではいけない。もうひとつ質問しよう。「もし御社が来年なくなったら、私のシステムはどうなりますか？」その答えが、このベンダーが契約に値するかを教えてくれる。
明日からできること、3つある。第一に、交渉中のすべてのAI契約に、解除トリガー付きのソースコードエスクロー条項を加える。第二に、すでに稼働中のシステムについては、データのフルエクスポートを要求し、実際に使えることを確認する。第三に、年1回の出口訓練をカレンダーに入れ、初回は来月に行う。待ってはいけない。その日が来ても、誰も警告してはくれない。
英語版からの翻訳。内容に相違がある場合は英語版を優先します。
