AI開発会社の選び方｜発注前に自社で決める5項目とRFPの書き方

AI開発会社の選び方は、発注前に自社で決める5項目で決まる

選定とは、同じ前提に揃えて成果とリスクを見える形にする作業です。提案は前提が違えば金額も期間も精度もぶれます。目的、データ、運用体制、成功指標を先に揃えると、見積の差の理由が説明でき、社内の決裁も速くなります。

提案書が比べられないのは、前提が各社でばらばらなため

AIはソフトウェア開発と違い、学習データと評価指標で成果が変わります。PoC（概念実証）段階では「できそう」を示す提案が中心になり、運用までの追加コストが見えません。比べにくさの正体は、提案書の粒度が揃っていないことです。発注側が目的と制約を明文化すれば、各社が同じ条件で提案を書けます。

発注前に文章にする5項目。目的・データ・合格ライン・運用担当・セキュリティ

最低限、(1)業務課題とKPI、(2)対象データの種類と量、(3)精度の合格ライン、(4)利用者と運用頻度、(5)セキュリティ要件を揃えます。揃えば、開発会社は手法選定と工数見積の根拠を出せます。KPIは「見積作成の工数を20%削減」のように数字で言える指標にします。社内のAI利用ルールが未整備なら、社内AI利用のルールづくりから着手すると、(5)を自分の言葉で書けます。

AIコンサル会社とAI開発会社の違い。どちらに先に相談するか

同じ「AI導入の相談先」でも、売っているものが違います。コンサル会社が売るのは課題整理と優先順位づけ、開発会社が売るのは動くものです。どちらが先かは課題が言葉になっているかで決まります。

課題整理から頼むか、処理が決まってから頼むかで分かれる

「現場が忙しいので何かAIで」の段階なら、業務の棚卸しとAI化候補の洗い出しから入るコンサル型が合います。「過去の見積データから金額候補を出したい」まで言えているなら、開発会社へ直接RFPを出すほうが早く、中間マージンも乗りません。迷うときは、やりたい処理を一文で書いてみます。書けなければ上流支援が要ります。弊社ではPoCから全社展開までの伴走として、課題整理と開発を続けて引き受ける形も取っています。

コンサル寄り・受託開発寄り・プロダクト寄りの3タイプ

コンサル寄りは課題整理とロードマップが強く、意思決定の速い企業に向きます。受託開発寄りは要件に沿った実装が得意で、既存システム連携まで任せられます。プロダクト寄りは特定領域のSaaSが中心で、短期間で入る代わりに要件の自由度が下がります。どのタイプでも、標準の範囲と追加になる範囲を先に聞きます。

従来のシステム開発と違い、AIはデータと評価で品質が決まる

従来の開発は仕様が固まれば品質が安定しますが、AIの品質は、どんなデータを使い、どの指標で評価するかによって変わります。要件定義も機能要件より精度要件とデータ要件が中心になり、リリース後は保守に加えて再学習が要ります。体制もSE中心からデータサイエンティストとの混成に変わります。実装力だけでなく、データ整備支援、評価設計、運用改善の経験を見ます。MLOps（機械学習の運用基盤）を扱えるかで、本番後の改善速度が変わります。

発注前に書くRFP。要件定義より手前で自社がそろえる項目

RFP（提案依頼書）は要件定義書ではありません。要件を決めるのは契約後ですが、何に困っていて何を達成したいかは発注前に自社で書きます。ここが空いていると各社が違う前提を置き、提案が比べられなくなります。

要望・要求・要件の3段階を混ぜずに書く

「検査が大変」は要望、「不良の見逃しを減らしたい」は要求、「撮影画像を自動で一次判定する」が要件です。RFPに書くのは要望と要求までで、要件は提案を受けてから決めます。3段階を分けずに「AIで自動判定するシステムを作ってほしい」と書くと手段が先に固定され、もっと安い改善策を提案してもらえなくなります。

「効率化」「最適化」「可視化」を残したまま出さない

この3語は、納品時に達成したかどうかを確かめられません。曖昧なまま契約すると、受入検査で、達成できたかどうかについて開発会社と意見が食い違います。書き換えるときは、何と何のトレードオフを、どんな狙いで、どの数値で表すのかに答えます。「検査を効率化する」なら、「1ロットあたりの目視時間を12分から8分にする。見逃し率は現状維持」のように数値で書きます。

非機能要件は、開発会社から提案してもらう前提で枠だけ作る

応答速度、同時利用者数、稼働率、ログの保持期間、障害時の復旧目標。これらは発注側から出てこないのが普通です。RFPには「非機能要件はIPAの非機能要求グレードを参照して提案に含めること」と1行入れます。提案時点で非機能に触れるかどうかで、後から出る追加費用の額が変わります。

提案を並べる5つの軸。技術・業務理解・体制・契約・運用

軸を「技術」「業務理解」「体制」「契約」「運用」に分けると、抜け漏れが減ります。提案は技術の話に寄りがちですが、現場に定着するかは運用で決まります。提案依頼の段階で評価指標と責任分界を書いておくのが、いちばん効果の大きい対策です。

技術力は、精度が出なかったときの対応策で見る

データ前処理、特徴量設計、モデル選定、LLM活用の設計を説明できるかを見ます。精度が目標に届かなかったときの次の手を出せる会社は強いです。同条件のベンチマークと再現性のある評価手順が示されるかを確認し、中身の見えない提案を避けます。

業務理解は、例外処理とデータ欠損の理由まで聞けるかで見る

ヒアリングで業務フローの例外や、データが欠ける理由まで踏み込めるかを見ます。似た業務の改善を扱った経験と、KPI設計まで支援したかを聞きます。提案資料に業務フロー図が入っているかも手がかりになります。

体制は、PMとML責任者が同席するかで見る

窓口が営業だけだと、技術的な論点の確認に時間がかかります。PM（プロジェクトマネージャー）とML責任者が同席し、週次で進捗とリスクを共有できる体制が望ましいです。担当者の職能、稼働率、レビュー体制を確認します。引き継ぎ手順とデータ辞書を成果物に含める会社は、社内に残る資産が多くなります。

契約は、検収条件が納品物か精度かをはっきりさせる

AI開発は精度100%の保証が難しいため、成果物を分解して定義します。データ整備の範囲、学習コード、評価レポート、運用手順書、保守SLAを入れておくと、あとで意見が食い違いにくくなります。検収条件が「納品物」か「精度」かを明確にし、追加費用が出る条件を契約に書きます。

見積はTCOで並べる。PoCが安く本番が高い型に注意する

見積総額だけでなく、データ整備、クラウド費、保守、再学習を含むTCO（総保有コスト）で並べます。費用内訳を同じ区分に揃えると、高い理由が妥当かを判断できます。初回の成果提示までの期間も聞きます。PoCは4週から8週が目安です。

中小企業7社の導入例。業種・AIに任せた範囲・出た数字

中小企業では、データが既にある業務から始めると成功率が上がります。見るのは同規模の支援経験と、運用の手間を増やさない設計です。

事例1 製造業（品質保証）：外観検査の一次判定を任せ、検査工数35%削減

目視検査が属人化し、不良の見逃しが課題でした。ラインで撮影した画像を分類モデルが一次判定し、疑わしいものだけ人が確認する運用に変えました。選定では、現場の撮影環境に合わせた前処理を提案できるかを見ました。検査工数が35%減り、教育期間も短くなりました。

事例2 建設業（積算部門）：見積作成のリードタイムを月40時間短縮

図面と仕様書の読み込みに時間がかかり、繁忙期の残業が増えていました。文書解析（OCRと自然言語処理）で項目を抽出し、過去見積と照合して候補を出します。既存の見積システム連携と例外処理の設計力で選びました。リードタイムが月40時間短縮し、見落としも減りました。

事例3 小売（店舗運営）：需要予測で廃棄コストを18%削減

発注が経験頼みで、欠品と廃棄が同時に起きていました。売上・天候・販促のデータから需要予測モデルを作り、発注量の推奨値を出します。精度検証だけでなく、運用ルールと例外対応まで支援する会社を選びました。廃棄コストが18%減り、欠品も改善しました。

事例4 士業（バックオフィス）：契約書レビューを1件あたり45%短縮

レビューが担当者の経験に依存し、確認漏れがリスクでした。LLM（大規模言語モデル）で条文の抜けや不利条項の候補を抽出し、チェックリスト形式で出します。プロンプト設計より、機密保持とログ管理の実装経験を重く見ました。レビュー時間が1件あたり45%短縮し、教育にも使える資産が残りました。

事例5 医療・介護（事務）：一次対応の自己解決率が62%に

電話とメールの問い合わせが集中し、対応品質もばらついていました。FAQを整備してチャットボットを構築し、答えられない問い合わせは担当者に引き継ぎます。改善サイクルを回せる運用設計と管理画面の使いやすさで選びました。一次対応の自己解決率が62%まで上がり、受付工数が減りました。

事例6 物流（配車）：準最適ルートの自動生成で走行時間12%短縮

配車が熟練者頼みで、急な変更に弱い状況でした。時間帯・積載・優先度の制約を取り込み、準最適なルート案を自動生成します。現場の制約を数理モデルに落とし込める会社を選びました。走行時間が12%短縮し、配車担当の負担も軽くなりました。

事例7 EC（マーケ）：広告コピー案の制作工数を約30%削減

A/Bテスト用の案出しが追いつかず、勝ちパターンの発見が遅れていました。商品情報と過去実績から訴求軸を抽出し、コピー案を生成して審査フローへ流します。生成結果のガバナンスと炎上リスク対策の有無で選びました。制作工数が約30%減り、テスト回数が増えました。

7件に共通するのは、人の最終判断を残したこと

7件とも、AIに任せたのは一次判定と候補出しまでで、最終確認は人が持っています。この線を引くと精度要件を現実的な水準に置けるため、立ち上げが速く、誤判定時の影響も小さくなります。

検討から内製化までの5段階。各段階で候補を絞り直す

「検討、要件定義、試験導入、本格展開、内製化」の順に進め、各段階で評価を更新します。最初に1社へ決め打ちせず、軸を作ってから絞ります。要件定義で精度要件と運用要件を固めると手戻りが減ります。

費用は4パターンに当てはめて並べる

費用は「PoC」「本番開発」「運用」の三層に割ると並べやすくなります。見積はデータ整備と運用設計の有無で大きく動き、安さだけで選ぶと後から追加費用が出ます。

PoCのみ・PoC＋本番・SaaS活用・運用込み伴走の4型

まず典型パターンに当てはめます。見積では、データ整備、評価設計、UI、連携、保守がどこまで含まれるかを確認します。同じ成果物で並べないと判断を誤ります。以下は市場で見かける価格帯の目安で、弊社の見積もりではありません。

補助金は、あり・なし両方の資金計画を用意しておく

IT導入補助金や自治体のDX支援は、条件が合えば使えます。対象経費や申請手順、採択時期で計画は変わります。申請に要る見積と計画書の作成に協力できるかを確認します。補助金を前提にすると進行が遅れるため、あり・なし両方で資金計画を持ちます。

費用差の大半は、既存システム連携と権限管理から出る

AI単体の検証が安くても、現場で使うには既存システムとの連携と権限管理が要ります。ここが費用差の大半です。API連携、データ基盤、監査ログ、運用画面の有無を確認します。

止まった発注と、続いた発注の分かれ目

止まる原因の多くは「要件定義不足」「データの見込み違い」「責任分界の曖昧さ」です。結果を左右するのは技術の優劣よりプロジェクト設計の優劣です。先に型を知り、避ける仕組みを作ります。

前提をそろえずに相見積を取ると、安く見える範囲だけが提案される

前提が揃っていない相見積では、各社が安く見える範囲だけを切り出します。するとデータ整備と運用設計が見積に含まれず、後から追加費用になります。成果物と評価手順をRFPで固定し、同条件で提案を受けます。

「データはあるはず」で始めると、欠損とラベル不備が後から出る

「データはあるはず」で着手すると、欠損やラベル不備が途中で見つかります。選定の段階でデータアセスメント（データ健全性の診断）を提案する会社は信頼できます。着手前にサンプルを渡し、棚卸しに1〜2週間を取ると手戻りが減ります。

不具合か仕様変更かの裁き方を、契約前に文章にする

AIは精度を上げる追加施策が多く、境界を決めないと作業が膨らみます。開発会社と意見が分かれるのは、ほとんどが「これは不具合か、仕様変更か」の判定です。要件定義と基本設計で決めた内容に合っているかで裁く、と着手前に合意しておきます。あわせて、自社側の主責任者を1人に固定します。窓口が複数あると、各社への回答がずれます。

ベンダーロックインは、成果物の範囲で避ける

特定クラウドや独自基盤に依存すると、乗り換えコストが上がります。学習コード、特徴量、評価データ、運用手順を成果物に含め、第三者が再現できる状態にします。ソースコードの権利とモデルの持ち出し可否も契約前に確認します。

開発会社を乗り換えるとき、引き継げるものと引き継げないもの

引き継げるのは、ソースコード、学習済みモデル、前処理の手順、評価データ、インフラ構成です。引き継ぎにくいのは、その特徴量を選んだ判断の経緯と、運用して分かった例外対応です。乗り換えを考える段階になったら、現行の会社に評価レポートとデータ辞書の提供を求め、次の会社には「既存資産のアセスメント」を最初の作業として見積に入れてもらいます。ゼロから作り直す前提の提案しか出ない場合は、引き継げる資産を測っていません。基幹システムの外注先を替える場合の判断は、基幹システム開発の外注先比較（金額以外の基準）で整理しています。

よくある質問

京都でAIの開発・導入を依頼する会社をお探しの方は、京都のAI導入支援ページもあわせてご覧ください。