既存の取引先に頼むか、AI専門の会社を新たに探すか。乗り換えコストで比べる5点

AI を使った機能を作ろうという話になったとき、最初に浮かぶのはたいてい 1 社の名前である。基幹システムを 10 年見てもらっている会社、サイトを作り直してくれた会社、毎月の保守で顔を合わせている会社。

一方で、「AI は専門の会社に頼んだほうがいいのではないか」という声も社内から出る。どちらが正しいという話ではない。判断を分けるのは、技術力の差ではなく乗り換えにかかるコストの置き場所である。

まず、両者の持ち物が違うことを確認する

同じ案件を見ても、2 種類の会社は違うところから値付けを始める。

	既存の取引先	AI 専門の会社
すでに持っているもの	自社の業務・既存システム・担当者の事情	AI 案件の経験・評価の手順・モデルの選び方
ゼロから要る工数	AI 側の設計・評価の設計	現状把握・既存システムの読解・社内調整
見積書で厚くなりやすい行	調査・検証・PoC	現状調査・要件定義・連携開発
価格の妥当性	比較対象がないと分からない	他社と並べれば分かる
失敗したときの関係	取引が続く前提	仕切り直しになる

どちらにも「ゼロから要る工数」がある。 そこが見積書のどこに乗っているかを読むのが、この比較の本体である。

会社の規模による違い（大手 SIer と AI 専門会社）は大手SIerとAI専門会社。規模で何が変わるかで扱った。ここでは規模ではなく、自社との付き合いの有無で比べる。

判断点 1. 既存システムの読解に、何人日かかるか

既存の取引先がいちばん強いのはここである。テーブル定義を知っている、過去の例外対応を覚えている、誰に聞けばいいか分かっている。この「読み替えの要らない前提」は、見積書の金額には現れにくいが実工数で効く。

新しい会社に頼む場合、この分が**「現状調査」「現行分析」といった行**として乗る。

• その行がない見積書は、読解を見込んでいない（後から増える可能性がある）
• その行が厚い見積書は、正直に見込んでいる（総額は高く見えるが外れにくい）

つまり、安く見える見積書のほうが危ない場合がある。同じ案件で既存取引先と新規の両方から取ると、この差額がそのまま乗り換えコストとして見える。

既存システムを触る案件の分岐は既存システムにAIを後付けするか、作り直すか。費用と期間で分かれる5つの判断点で整理している。

判断点 2. AI の精度に、誰が責任を持てるか

ここは既存取引先が弱くなりやすい。従来の開発は「仕様どおりに動くか」で検収できる。AI は確率で動くため、「どの程度当たればよいか」を先に決める作業が要る。

確認するのは経歴ではなく、手順である。

本件の精度目標は、どの指標で、どのデータを使って、誰が測りますか。

この問いに具体的に答えられるかどうかで分かれる。「実績があります」ではなく、評価用データの作り方と判定基準の決め方が出てくるかどうかを見る。評価の主体をどこに置くかはAIの精度評価は誰がやるか。ベンダー・自社・第三者の3つの型を費用と独立性で比較で比較した。

なお、既存取引先が答えられないとしても除外する理由にはならない。評価だけを別に切り出すという手がある。判断点 4 で触れる。

判断点 3. 運用の窓口が、いくつになるか

AI 機能は単体で動かない。既存システムからデータを受け、既存の画面に結果を返す。障害が起きたとき、原因がどちら側かはすぐには分からない。

• 既存取引先に一括で出す: 窓口が 1 つ。切り分けの手間は相手の中で閉じる
• AI 部分だけ別会社に出す: 障害時に、まず「どちら側の問題か」を自社が切り分ける立場になる

後者を選ぶなら、連携の境界と、障害時の一次受けをどちらが持つかを契約で決めておく必要がある。決めていないと、運用が始まってから自社の担当者の時間が消える。

分離発注と一括発注の損得は分離発注と一括発注。AI開発でどちらを選ぶかで扱った。運用費の持ち方はAI運用費は定額保守か従量精算か。API実費を誰が持つかで分かれる3つの契約型にまとめている。

判断点 4. 価格の妥当性を、何で確認するか

既存取引先に単独で頼むと、提示額が妥当かどうかを確かめる材料がない。これは相手が不誠実という話ではない。比較対象がないだけである。

AI 案件は特に幅が出やすい。同じ要件で 3 社に出すと、総額が 2 倍以上開くことは珍しくない。幅が出る理由は、技術力の差というより前提の置き方の差である。

• 精度目標をどこに置いたか
• 学習データの整備をどこまで含めたか
• 運用時の API 実費を誰が持つ前提か

既存取引先を選ぶつもりでも、相見積もりに入ってもらう価値はここにある。「他社と比べられている」こと自体が、前提を明文化させる圧力になる。

単独指名が合理的になる条件もある。それは相見積もりを取るか1社に絞るか。AI開発で単独指名が有利になる4条件で整理した。社数をいくつにするかはAI開発の相見積もりは何社に頼むか。3社が基準になる理由と、増やすほど増える自社の工数を参考にしてほしい。

判断点 5. うまくいかなかったときに、どこへ戻るか

AI 案件は、PoC で止まることが普通にある。精度が業務に乗らない、データが足りない、費用対効果が合わない。止めること自体は失敗ではない。

ただし、止めたあとの状態が違う。

	止めたあと
既存取引先	保守の関係が続く。知見は相手の中に残る
新規の会社	関係が切れる。残るのは納品物だけ

だからこそ、新しい会社に頼む場合は何が残るかを契約で決めておくことが効く。学習データ、評価用データ、プロンプト、検証の記録。これらが納品物に入っていれば、次の会社に引き継げる。入っていなければ、もう一度ゼロからになる。

権利の分け方はAI開発でコードとプロンプトは誰のものか。契約で分ける5つの権利、PoC の進め方はPoCから始めるか、直接開発するか。判断の基準で扱った。

条件別の目安

5 つを踏まえると、おおむね次のように整理できる。

案件の条件	寄せやすいほう
既存システムとの連携が多い／データが社内に散っている	既存の取引先
既存システムには触らない（新規の単独機能・社内ツール）	AI 専門の会社
精度目標の設定が案件の中心にある	AI 専門の会社
24 時間の運用・既存の保守とまとめたい	既存の取引先
予算の根拠を社内で説明する必要がある	両方から取る
社内に AI 案件の知見を残したい	AI 専門の会社（引き継ぎを納品物に入れる）

ただし、この表で決めきらないほうがよい。 実際の案件は複数の条件を同時に満たす。

現実的には「両方に出す」が成立する

既存取引先に相見積もりへ入ってもらうのは、失礼にはならない。むしろ、同じ案件票を渡すほうが相手も見積もりやすい。口頭で曖昧に伝えられて、後から「そういう話だったのか」となるほうが負担をかける。

伝え方は 1 行で足りる。

社内の予算承認のため、同じ条件で複数社から見積もりをいただいています。前提を揃えた案件票をお送りします。

このとき決定的なのは、全社に同じ文書を渡すことである。既存取引先には口頭で、新規には書面で、という形になると比較が成立しない。前提の揃え方はAI開発の見積書の前提条件と有効期限の読み方。概算と確定の差を埋める8項目にまとめた。

無料で相見積もり・相談の案件票は、分野・フェーズ・規模・扱うデータ・連携先を選択式で揃えて作る。既存の取引先を指名して同じ案件票を渡すこともできる。同じ紙で並べば、乗り換えコストが金額として見える。

まとめ

• 比べるのは技術力ではなく、どちらにどれだけの「ゼロから要る工数」があるか
• 既存取引先の強みは既存システムの読解と運用窓口、AI 専門会社の強みは精度目標の設計
• 新規に出す場合、見積書の「現状調査」の行が厚いか薄いかを読む。薄すぎる見積書は後から増える
• 止めたときに何が残るか（データ・プロンプト・検証記録）を納品物に入れておく
• 予算の根拠が必要なら、既存取引先も含めて同じ案件票で並べる

決め手は相性ではない。同じ条件で並べたとき、差額に説明が付くかどうかである。