ベンダーロックインを避けるAI導入とは｜納品物ではなく自社で更新できる状態を納めさせる契約の要件
「このツール、作った会社にしか直せないんですよね」。導入から1年経った業務システムについて、担当者がそう言う場面があります。仕様を変えたいたびに見積もりが出て、数十万円と数週間が乗る。使い続けるほど動かしにくくなっていきます。
生成AIを業務に組み込む案件でも、同じことが起こり始めています。しかもAIの場合は、ロックインの発生が従来のシステム開発より早い。業務ルールが頻繁に変わるため、修正の依頼がすぐ発生するからです。
この記事では、AI導入でベンダーロックインがどこから生まれるのかを3つに分けて説明し、発注の段階で何を要件に書けば避けられるのかを示します。
読み終えると、AI活用の外部委託を検討するときに、見積もりの金額以外で比較すべき項目が分かります。記事の最後には、契約前に確認する8項目のチェックリストも載せました。
ベンダーロックインとは特定の事業者なしに運用を継続できない状態
言葉の定義をそろえます。ベンダーロックインとは、導入したシステムやツールの保守・改修を、開発した事業者以外が実行できなくなること。技術的に不可能な場合と、契約上できない場合の両方を含みます。
AI導入で問題になるのは、技術的なロックインより、運用のロックインです。システム自体は標準的な部品で作られていても、業務ルールの中身を事業者しか把握していなければ、直せるのはその事業者だけです。
総務省の令和8年版 情報通信白書でも、日本企業は生成AIを学ぶ環境の整備が先行し、業務データを扱える環境の構築が後回しになっている傾向が示されています。学んだ後に自社で作れるところまで進んでいないと、外部に依存する構造が残ります。
AI導入でロックインが起きる3つの原因
原因は、納品物の形・判断ロジックの置き場所・運用体制の3つに分かれます。
原因1 動くものだけが納品され中身の説明が残らない
1つ目は納品物の形。委託した結果として受け取るのが「動くツール」だけだと、なぜその判定になるのかが社内に残りません。
AIを使った仕組みの場合、ここが従来より深刻になります。従来のシステムは処理の手順がコードに書かれているため、読める人がいれば追えました。
AIを使うと、判断の根拠が指示文（プロンプト）と参照させるデータの組み合わせに移る。この2つの設計意図が文書になっていないと、動いていること以外は分かりません。
原因2 業務ルールと判定の仕組みが一体になっている
2つ目が構造。業務ルールと、それを処理する仕組みが1つのファイルに混ざっていると、ルールを1行変えるだけでも事業者に依頼することになります。
業務ルールは変わり続けます。制度改定、手当の新設、対象者の範囲変更。人事や経理の業務なら、年に何度も発生します。そのたびに見積もりが出る構造だと、使うほど費用がかさむ。
原因3 担当者が交代すると運用が止まる
3つ目は体制。導入時の担当者1人だけが仕組みを理解しているなら、それは社内版のロックインです。異動や退職で、外部委託と同じところへ戻ります。
この3つ目は見落とされやすいところです。事業者からの独立ばかりを見ていると、社内で特定の個人に依存していることを見逃します。
回避の要件は納品物ではなく更新できる状態を納めさせること
3つの原因に共通する対処は1つ。受け取るものを「動くツール」から「自社で更新できる形」に変える。発注の段階で要件に書けば実現できます。
リデザインワークのAX支援で、ある大手デザイン会社の給与チームと進めた案件が、この形でした。担当者が交代しても運用が止まらないことを、構築時の要件に置いたのです。
具体的にやったことは3つあります。
- 判定の仕組みと、業務ルールの一覧を別々のファイルに分けた。ルールを変えるときは一覧の側だけを直せばよく、仕組みには触らない
- 一覧の書き換えを、クライアント自身がAIエージェントを使ってできる状態にした。プログラムを書ける人でなくても、日本語で修正の意図を伝えれば反映できる
- 修正の依頼を、都度ではなく業務カテゴリー別にまとめて一括で反映する運用に変えた。入社・退職・手当といった区分でまとめることで、抜け漏れの確認もしやすくなる
この3つで、原因1から原因3までが同時に外れます。ルールが文書として社内にあり、変更は自社でできる。担当者が交代しても一覧を読めば引き継げます。
発注前に確認する8項目
委託先を比べるとき、見積もりの金額だけでは差が見えません。次の8項目を聞くと、更新できる形で納品されるかが分かります。
納品物について
- 業務ルールの一覧は、独立したファイルとして納品されるか
- AIへの指示文は、社内で読める形で納品されるか
- 判定の根拠を説明した文書が付くか
変更について
- 業務ルールを1件追加するとき、自社だけで完結できるか
- 完結できない場合、1件あたりの費用と所要日数はいくらか
- 年間で何件までの変更が保守の範囲に含まれるか
引き継ぎについて
- 担当者が交代したとき、引き継ぎに使える手順書が付くか
- 契約を終了した後も、納品物を自社で使い続けられるか
4番と8番で答えが濁る場合は、ロックインが前提の契約です。4番は「軽微な変更であれば」といった条件付きの回答が返ってくることがあります。その場合は、軽微の定義を文書で確認してください。
内製化とロックイン回避は別のもの
ここで混同されやすい点を整理します。ベンダーロックインを避けることと、すべてを内製化することは同じではありません。
| 目指すところ | 外部の使い方 | |
|---|---|---|
| 完全な内製化 | 設計から運用まで自社だけで回す | 使わない |
| ロックイン回避 | 変更と引き継ぎを自社でできる | 設計と初期構築は委託してよい |
完全な内製化は、人材の確保と育成に時間がかかる。AI活用の経験がない状態から始めるなら、初期の設計は経験のある外部に任せ、変更できる状態を受け取るほうが早い。内製化そのものの進め方は生成AI活用の内製化で詳しく説明しています。
区別の実益は、委託先の選び方に現れます。ロックイン回避を要件にすると、「作ってあげる」型ではなく「作れるようにする」型の事業者が候補に残る。
既に導入済みの場合に確認すること
すでに入れてしまった仕組みについても、抜け出す道はあります。次の順で確認します。
- 業務ルールが、どのファイルのどこに書かれているかを特定する。分からない場合は、事業者に「ルールの一覧を出してほしい」と依頼する
- 出てきた一覧を、自社で読める形に整理する。この時点で、社内にルールが残る
- 次の変更依頼のときに、一覧を分離する改修を含めてもらう。新規開発より安く済む
契約の更新時期が、条件を変える機会。保守費用の内訳を、変更の件数ベースで開示してもらうところから始めるのが現実的です。
AI導入で何をどこまで外部に任せ、何を社内に残すかの線引きを含めて整理したのが、資料『AX業務設計フレームワーク』です。業務を分解して任せる範囲を決める手順をまとめています。
AIを入れて作業は速くなったのに、月末の残業は減らない。切り出した業務の前後に、AIを使うための新しい仕事が生まれているからです。AX推進責任者が着手前に必ず押さえるべき、手戻りを生まない業務の切り分け方を解説します。
すでに導入した仕組みが自社で変更できない状態になっている場合も、契約更新のタイミングで条件を変えられます。
現在の契約内容と業務ルールの置かれ方をお聞きして、どこから分離できるかまで一緒に決めます。
ベンダーロックインは、技術の問題ではなく契約と納品物の形の問題です。動くものを受け取る契約にすれば、変更のたびに依頼が発生する。更新できる状態を受け取る契約にすれば、変更は自社で終わります。
発注前に確認できるのは、先の8項目のうち4番と8番の2つだけでも十分です。業務ルールを1件追加するとき、自社だけで完結できるか。この問いへの答えで、導入後の数年の費用が決まります。
AI導入で現場が止まる理由については、AIに仕事を奪われるという不安への向き合い方でも扱っています。
