AI受託開発の発注ガイド｜見積もりの読み方と失敗5つ

「AIで業務を楽にしたいので、開発会社に頼みたい。でも、いくらかかるのか、何をどこまで決めてから相談すればいいのかが分からない」——AI受託開発を検討する中小企業の経営者・情報システム担当の方から、最も多くいただく相談です。

AI受託開発は、普通のシステム開発と同じつもりで発注すると高い確率でつまずきます。理由ははっきりしていて、「完成」の定義が言葉で書けないこと、そして成果を左右するデータの多くを発注側が持っていることの2つです。つまり、うまくいくかどうかは受託会社の腕前だけでは決まりません。発注側の準備で決まる部分が非常に大きいのがAI受託開発です。

本記事では、中小企業のAI導入を支援するAi-Raku（アイラク）の視点で、発注する側が知っておくべきことだけを整理します。相場の断定は行いません。公的な出典が確認できない金額を書くことは、発注判断をかえって誤らせるためです。代わりに「見積もりが何で動くか」の構造と、そのまま使える発注前チェック表をお渡しします。AI導入全体の進め方は中小企業のAI導入は何から始める？もあわせてご覧ください。

結論｜AI受託は発注側で決まる

結論から書きます。AI受託開発の成否の大半は、契約書に署名するより前、発注側が自社で決めておくべきことを決めたかどうかで決まります。優秀な受託会社を探す努力より、自社の準備に時間を使ったほうが、結果は良くなります。

発注側が握る3つの変数

AI受託開発において、受託会社の努力ではどうにもならない変数が3つあります。この3つはすべて発注側が握っています。

受託会社は、業務の中身も、データの所在も、社内の合格ラインも知りません。ここを空欄のまま渡すと、受託会社は「まず調査させてください」と答えるしかなくなります。その調査費用を払うのは発注側です。逆に、この3つを埋めてから相談すると、見積もりの精度が上がり、話が一気に前に進みます。

受託会社を選ぶ前にやること

ベンダー比較サイトを開く前に、次の順で手を動かしてください。所要はおおむね2〜3週間、担当者1名の片手間で足ります。

1. 困っている業務を紙に書き出す（月に何時間かかっているかもあわせて書く）
2. その業務で扱っている書類・データの現物を集める
3. 市販の生成AIサービスに、その書類を1件だけ手作業で貼って試す
4. 「そこそこできる」「まったくできない」を仕分ける
5. できたものだけを、開発の対象候補にする

ここまでを社内でやっておくと、そもそも開発が不要だった業務が必ず何件か見つかります。実際、既存のAIサービスの設定と使い方の整備だけで解決する業務は少なくありません。開発を頼む前に開発の必要量を減らすのが、最も効く費用対策です。要件の固め方は中小企業のAI導入の考え方と共通します。

この記事の使い方

本記事は、上から順に読めば発注の準備が終わる構成にしています。急ぐ方は、「発注前に決める6項目」のRFPリストと、「ベンダーの選び方」の10の質問だけを印刷して商談に持ち込んでも機能します。契約条項そのものの読み方は準委任と請負の違い｜AI開発を外注する前にで詳しく扱っているため、本記事では要点にとどめます。

AI受託開発とは何を頼むか

「AI受託開発」という言葉は、実務では幅の広い意味で使われています。発注側が最初に整理すべきは、自社が頼もうとしているのは4つのうちどれかという点です。ここが曖昧なまま相見積もりを取ると、各社の見積もりが比較不能な状態で並びます。

受託開発と受託研究の違い

まず押さえておきたいのが、「作ればできると分かっているもの」を作る仕事と、「できるかどうかを調べる仕事」はまったく別物だという点です。前者は従来のシステム開発に近く、後者は研究に近い性質を持ちます。

生成AIを使った業務支援ツールの多くは前者に寄っています。一方、独自データで予測モデルを作る、画像から不良品を判定する、といったテーマは後者の性質が強くなります。後者を「開発」として一括で発注すると、必ず揉めます。できるかどうか分からないものに完成の約束はできないからです。この場合は、調べる工程と作る工程を契約ごと分けるのが正解です。

頼める仕事の4分類

AI受託開発で発注できる仕事は、実務上おおむね次の4つに分かれます。見積もり依頼のときは、この分類名を使って話すと通じやすくなります。

費用が読みにくいのは②と④です。②は「何回試すか」で工数が変わり、④は「どこまで面倒を見るか」で金額が変わります。①と③だけを見積もりに入れ、②と④を空欄にした提案書は、後から必ず金額が増えます。4分類すべてについて、含む・含まないをはっきりさせてください。

社内文書を使う開発の中身

中小企業からの依頼で最も多いのが、「社内のマニュアルや過去資料をAIに読ませて、質問に答えさせたい」というテーマです。この形はRAG（検索拡張生成）と呼ばれ、AIに社内文書を検索させてから回答させる仕組みを指します。仕組みの詳細はRAGとは｜社内文書をAIに使わせる仕組みで解説しています。

発注側が知っておくべきなのは、この種の開発では作業量の大半が「文書の整理」に費やされるという事実です。紙のまま保管されている、同じ規程の版が5つある、部署ごとに用語が違う——こうした状態のまま渡すと、受託会社は整理作業に時間を使います。その時間はもちろん見積もりに乗ります。

逆に言えば、文書整理は発注側が自前でやれば費用を下げられる数少ない工程です。最新版だけをフォルダにまとめる、PDFにテキストが入っているかを確認する、この2つを社内でやるだけで話が変わります。

開発せずに済ませる選択肢

正直に書きます。中小企業の相談のうち、相当数は開発を伴わずに解決します。既存の生成AIサービスの業務ごとの設定、指示文（プロンプト）の定型化、社内ルールの整備、この3つで済む業務が多いためです。

開発が必要になるのは、おおむね次の場合です。基幹システムのデータと連携する必要がある、毎日決まった時刻に自動で動かす必要がある、社外に出せないデータを扱う、複数人の承認フローに組み込む。ここに当てはまらないなら、まず設定と運用整備から試すほうが早く、費用も抑えられます。どの業務が対象になりやすいかは業務別ソリューション一覧で整理しています。

普通のシステム開発との違い

AI受託開発が難しいのは、技術が新しいからではありません。従来の受発注の作法がそのままでは通用しないからです。違いは4つあります。

完成の定義があいまいになる

販売管理システムなら「請求書を発行できること」が完成です。動くか動かないかで判定できます。ところがAIの場合、「だいたい合っている」という中間状態が存在します。要約は出る、しかし3件に1件は表現が惜しい。この状態を完成と呼ぶかどうかは、契約書ではなく業務の側の事情で決まります。

したがって発注側は、完成ではなく「合格ライン」を自分で決める必要があります。「人が読んで直す前提で、直しが5分以内に収まれば合格」といった、業務に即した基準です。この基準は受託会社には作れません。業務を知らないからです。

データの質が成果を決める

AIの出来はデータで決まります。ここで発注側が知っておくべき条文があります。民法第636条は、請負人が引き渡した仕事の目的物が契約内容に適合しない場合でも、その不適合が「注文者の供した材料の性質又は注文者の与えた指図」によって生じたものであるときは、注文者は追完請求・報酬減額・損害賠償・解除ができないと定めています（出典：e-Gov法令検索「民法」／ただし請負人がその材料や指図が不適当と知りながら告げなかった場合を除く）。

AI開発に置き換えると、発注側が渡したデータが原因で精度が出なかった場合、その責任を受託会社に押しつけるのは難しいということです。データを渡す側の責任は、法的にも軽くありません。これは知っておく価値のある条文です。

精度100%は保証できない

AIは確率で答えを出す仕組みであるため、誤りが原理的にゼロにはなりません。「100%の精度を保証します」と言う会社があれば、その時点で警戒してください。保証できるのは精度そのものではなく、誤りが出たときに気づける仕組みと、直す手順のほうです。

この性質は、AIをどこまで業務に組み込むかの設計に直結します。誤りが出ても人が気づける工程に置くのか、誤りが即座に社外に出てしまう工程に置くのかで、必要な作り込みの量がまるで違います。金額差が出るのはここです。

作ったあとに劣化する

従来のシステムは、放置しても同じ動きを続けます。AIを使った仕組みは違います。元になるAIモデルの世代交代、業務手順の変更、扱う書類の様式変更のたびに、出力の質が変わります。つまり「納品して終わり」が成立しません。

そのため、運用フェーズの設計は発注段階で決めておく必要があります。誰が月次で出力を確認するのか、おかしくなったときに誰に連絡するのか、止める判断は誰がするのか。この設計の考え方はAIエージェント導入の管理｜台帳12項目と止める基準にまとめています。

相場と見積もりの読み方

先に立場を明確にしておきます。本記事ではAI受託開発の相場金額を提示しません。公的機関が継続的に集計しているAI開発の単価データが存在せず、出典のない金額を書くことは発注判断を誤らせるためです。代わりに、見積もりが何によって動くかを構造で示します。

公的な相場データの現在地

システム開発の工数について、日本で最も広く参照されてきた公的データはIPA（情報処理推進機構）の「ソフトウェア開発分析データ集」です。同資料は2005年からエンタプライズ分野の開発データを収集し、累計5,546プロジェクトの定量データを分析対象としています（出典：IPA「ソフトウェア開発分析データ集」）。

ただし発注側として重要なのは、同ページに「事業終了に伴い今後の発行予定はございません」と明記されている点です。つまり、最新のAI開発案件を反映した公的な工数データは、現時点で更新が止まっています。相場を語る記事の多くが根拠を示せないのは、そもそも根拠になる公開データが乏しいためです。

AI導入そのものの広がりについては公的な調査があります。IPAが国内企業1,799社を対象に実施した調査では、AI導入は大企業を中心に広がる一方、その活用は業務効率化・迅速化が中心で、期待どおり・期待以上の効果を得た割合は限定的と報告されています（出典：IPA「DX動向2026調査のポイント」2026年7月16日、詳細版はIPA「DX動向2026」）。導入すれば効果が出るわけではない、という前提で発注に臨むのが現実的です。

見積もりを動かす6つの変数

相場を探すより、目の前の見積もりが何によって膨らんでいるかを読むほうが実用的です。AI受託開発の見積もりを動かす変数は6つに集約できます。

5つ目の非機能要件は、発注側が最も見落とす項目です。IPAは「非機能要求グレード」として、非機能要求項目を可用性・性能／拡張性・運用／保守性・移行性・セキュリティ・システム環境／エコロジーの6つの大項目に分類し、要求レベルを段階的に示す資料を公開しています（出典：IPA「非機能要求グレード」）。「24時間365日止まらないこと」を何気なく要望に入れると、金額は跳ね上がります。社内の業務時間だけ動けばよいなら、そう書いてください。

見積書で分解を求める欄

「AIシステム開発一式」という1行の見積書を受け取ったら、必ず分解を依頼してください。分解を求めるべき欄は次のとおりです。

特に忘れられがちなのが外部サービス費です。AIの利用料は使った分だけ課金される形が主流で、利用量が増えれば月額も増えます。開発費とは別に、毎月発生する費用として誰が負担するのかを最初に決めてください。

安い見積もりが危ない理由

相見積もりで極端に安い1社が出てきたときは、金額を喜ぶ前に理由を確認してください。安さの理由はたいてい次のどれかです。

• 検証工程が入っていない……いきなり実装から始める前提。精度が出なければ作り直しになる
• データ整備を発注側の作業として除外している……見積もりには出ないが、社内工数として確実に発生する
• 運用保守が別料金……納品後に月額が上乗せされ、年間では逆転する
• テストとドキュメントが省かれている……担当者が変わった瞬間に誰も直せなくなる
• 汎用テンプレートの流用……自社業務に合わず、結局使われない

安いこと自体は問題ではありません。問題は、何が抜けているかを発注側が把握していないことです。除外事項を1行ずつ書かせれば、金額差の理由はほぼ説明がつきます。

契約は準委任が基本になる

AI受託開発の契約は、請負より準委任が選ばれる場面が多くなります。理由は感覚論ではなく、条文と公的なモデル契約から説明できます。なお契約類型そのものの比較は準委任と請負の違い｜AI開発を外注する前にで7つの観点から詳しく扱っているため、ここでは発注判断に必要な要点だけを押さえます。

民法の条文で確認する

民法第632条は請負について「当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約する」と定めています。一方、委任は第643条、法律行為でない事務の委託（＝準委任）は第656条で規定され、完成の約束は要件になっていません（出典：e-Gov法令検索「民法」）。

ここが分岐点です。前述のとおり、AI開発では「完成」を言葉で定義しにくい場面が多く、完成を約束する請負とは相性が悪くなります。なお2020年施行の改正民法では第648条の2が新設され、成果に対して報酬を支払う型の準委任も明文化されました。「成果物に対して払いたいが、完成の保証までは求めない」という中間の設計が可能になっています。

もう1つ、発注側に有利な条文として第641条があります。請負人が仕事を完成しない間は、注文者はいつでも損害を賠償して契約を解除できるという規定です。プロジェクトを止める判断が必要になったときの逃げ道として、覚えておく価値があります。

IPAのモデル契約が示す前提

公的なひな形も確認しておきましょう。IPAは「情報システム・モデル取引・契約書」を公開しており、ウォーターフォール型を想定した第二版と、アジャイル開発版があります。

後者には明確な記述があります。「あらかじめ特定した成果物の完成に対して対価を支払う請負契約ではなく、ベンダ企業が専門家として業務を遂行すること自体に対価を支払う準委任契約を前提としています」——これが公的機関の示す前提です（出典：IPA「情報システム・モデル取引・契約書（アジャイル開発版）」）。

同資料はさらに「契約前チェックリスト」を提供しており、プロジェクトの目的・ゴールが明確か、ステークホルダーの範囲が明確か、開発対象が反復型開発に適しているか、初期計画や体制が十分かを、契約締結前に双方で確認するよう促しています。発注側が使える無料の道具です。商談の前に一度目を通しておいてください。

偽装請負と言われないために

準委任で進める場合、発注側が注意すべき論点が1つあります。受託会社の担当者に、自社の社員へ指示するのと同じ感覚で直接指示を出すと、偽装請負を指摘されるおそれがあります。

この点についてはIPAのアジャイル開発版モデル契約も注意を促しており、厚生労働省が公開する「37号告示に関する疑義応答集」（労働者派遣事業と請負により行われる事業との区分に関する基準）を参照するよう案内しています。第3集では、発注者と受託者の担当者が日常的に打ち合わせを行う形態について整理されています。

実務上の目安は単純です。「何を作ってほしいか」は発注側が言ってよい。「誰がいつ何時間作業するか」は受託会社が決める。この線を越えないようにしてください。同席しての打ち合わせや、成果物に対する要望の伝達自体が禁じられているわけではありません。

下請法は名称が変わった

見落とされがちな制度変更を1つ。かつて「下請法」と呼ばれていた法律は、現在は「製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律」という題名になり、略称は「中小受託取引適正化法」（取適法）とされています（出典：e-Gov法令検索・昭和三十一年法律第百二十号）。

AIシステムの開発委託は情報成果物作成委託に当たり得るため、自社が資本金要件を満たす場合、発注側が規制を受ける側になります。書面の交付、支払期日の設定、代金の減額禁止などの義務が生じます。自社より小規模な開発会社に発注する中堅企業は、一度確認しておいてください。

発注前に決める6項目

ここからが本記事の中心です。相談に行く前に、次の6項目を自社で決めてください。すべて埋める必要はありませんが、埋まった数だけ見積もりの精度が上がり、後の揉め事が減ります。

目的と成功の定義を数値に

「業務を効率化したい」は目的ではありません。目的は「誰の、どの作業を、月何時間減らしたいか」まで下ろして初めて機能します。

書き方の例を挙げます。「営業事務2名が、月120時間かけている見積書の作成を、月60時間にしたい」。ここまで書けば、受託会社は何を作るべきかを考えられます。さらに合格ラインを添えます。「AIが作った下書きを人が確認し、1件あたり5分以内の修正で提出できれば合格」。

この合格ラインを言語化できるのは発注側だけです。ここを空欄にしたまま発注すると、納品時に「これで合格なのか判断できない」という最悪の状態になります。

データの所在と整備責任

次に、対象業務で使うデータについて次の4点を書き出します。

1. どこにあるか……基幹システム内、共有フォルダ、紙、個人のパソコン、担当者の頭の中
2. どんな形式か……Excel、PDF（テキストあり／画像のみ）、紙、システムからの出力
3. どれだけあるか……件数と期間（過去何年分か）
4. 誰が整備するか……発注側の社内作業か、受託会社に委託するか

4点目が最重要です。前述の民法第636条のとおり、発注側が提供したデータに起因する不具合は、受託会社に責任を求めにくくなります。だからこそ、整備責任がどちらにあるのかを最初に文書で決めてください。「発注側が用意する」と書いたなら、その工数を社内の予定に組み込む必要があります。

あわせて、社外のAIサービスに社内データを渡す際の取り扱いも確認します。個人情報を含む場合は、個人情報保護委員会が公開する生成AIサービスの利用に関する注意喚起を確認し、入力してよい情報の範囲を社内で決めておいてください。

PoCの範囲と打ち切り基準

検証（PoC）は、AI受託開発で最も費用が膨らみやすい工程です。理由は簡単で、「もう少し試せば精度が上がるかもしれない」に終わりがないからです。

したがって、始める前に次の3つを決めてください。

• 回数の上限……試行は何回まで、期間は何週間まで
• 合格の数値……何をもって次の工程に進むか
• 打ち切りの数値……この水準に届かなければ中止する、という線

打ち切り基準を書いておくと、やめる判断が感情論にならず、社内の説明も簡単になります。「ここまでやって届かなかったので中止します」と数字で言えるためです。この1行があるかないかで、費用の総額が大きく変わります。

RFPに書く13項目

ここまでの内容を、相談時にそのまま渡せる形にまとめます。以下の13項目を1〜2枚の文書にすれば、立派な提案依頼書（RFP）になります。難しく考える必要はありません。箇条書きで構いません。

1. 自社の概要（業種、従業員数、拠点）
2. 困っている業務と、その業務にかかっている月間時間
3. その業務に関わる人数と役職
4. 目指す状態（月何時間にしたいか）
5. 合格ライン（どうなれば「使える」と判断するか）
6. 対象データの所在・形式・件数
7. データ整備を誰が行うか
8. 既存システムとの連携の要否（システム名も書く）
9. 利用する時間帯と、止まったときの許容時間
10. 社外に出せない情報の有無
11. 希望する開始時期と、いつまでに使い始めたいか
12. 社内の担当者と、その担当者が割ける週あたりの時間
13. 今回の予算枠（上限だけでも書く）

13項目のうち、9〜10番目は非機能要件、12番目は体制、13番目は予算に当たります。とくに12番目を書ける会社は多くありません。AI受託開発は発注側の関与が前提のため、社内担当者が週に何時間割けるかは、実は納期を左右する最重要項目です。

ベンダーの選び方

準備ができたら、いよいよ相手選びです。ここでも判断軸を先に決めておきます。ホームページの実績数や技術スタックの列挙は、選定の役に立ちません。見るべきは別のところにあります。

実績より「進め方」を見る

「AI開発実績100社」と書かれていても、その100社が自社と同じ規模・同じ業種とは限りません。中小企業の発注で本当に効くのは、相手が「進め方」を説明できるかどうかです。

良い会社は、初回の商談で次のような話をします。「まず対象業務を2つに絞りましょう」「データを見せていただかないと精度は分かりません」「最初の1か月は検証に使い、進むかどうかを一緒に判断しましょう」。できないことを最初に言う会社は、信頼できます。

逆に、初回から「できます」「AIなら可能です」しか言わない相手は要注意です。AIには苦手な処理が確実に存在します。それを説明しない相手は、知らないか、言わないかのどちらかです。

商談で聞く10の質問

次の10問を、そのまま商談で使ってください。答えの内容よりも、答えられるかどうか、はぐらかさないかどうかを見ます。

1. この業務でAIが苦手なのは、どの部分ですか
2. 精度が出なかった場合、どの時点で判断しますか
3. 検証にはどんなデータが、何件必要ですか
4. データの整備は御社と当社のどちらが行いますか
5. 検収は何をもって合格としますか
6. 納品後、月々かかる費用の内訳を教えてください
7. AIサービスの利用料は誰が契約し、誰が払いますか
8. 当社のデータは、御社の他案件や学習に使われますか
9. 担当者が交代しても引き継げる形で残りますか
10. 過去に途中で中止になった案件はありますか。その理由は何でしたか

10問目は特に有効です。中止の経験を率直に語れる会社は、危険な兆候を早期に伝えてくれます。「一度もありません」という回答は、経験が浅いか、正直でないかのどちらかを疑ってよいでしょう。8問目は情報管理の要点で、IPAが毎年公表する情報セキュリティ10大脅威でも委託先経由のリスクは繰り返し取り上げられています。

相見積もりの正しい取り方

相見積もりは有効ですが、渡す情報が各社でバラバラだと比較になりません。前述のRFP13項目を全社に同じ内容で渡してください。そのうえで、次の条件を揃えます。

• 見積もりの対象工程を明示する（例：検証工程のみ、または検証＋実装）
• 納期の希望を同じにする
• 提出してほしい書式を指定する（工程別・工数内訳・除外事項を必ず記載）
• 質問は各社に同じタイミングで回答を返す

また、3社以上に声をかけるのは、社内の稟議のためだけならおすすめしません。提案作成には相手の工数もかかり、雑に扱えば良い会社ほど離れていきます。2〜3社に絞り、その代わり真剣に検討するほうが結果は良くなります。

避けたほうがよい兆候

次の兆候が2つ以上重なったら、いったん立ち止まってください。

よくある失敗5つ

ここからは、AI受託開発でつまずきやすい5つのパターンと、その防ぎ方をセットで示します。いずれも発注側の準備で相当程度は避けられます。

失敗1｜PoCが終わらない

症状。検証を始めて半年経っても、実装に進むかどうかの判断が出ない。試行を重ねるたびに費用が積み上がる。

原因。合格の数値と打ち切りの数値が決まっていないため、「もう少しで届きそう」という状態が延々と続く。

対策。検証の契約に、期間の上限・試行回数の上限・打ち切り基準の3つを必ず書く。「8週間、3回の試行で、対象100件の判定一致率が◯%に届かなければ中止」といった形で、数字と期限で縛る。届かなかった場合の精算方法も先に決めておく。

失敗2｜データが揃わない

症状。契約後、受託会社から「データをください」と言われたが、社内で集めるのに3か月かかり、その間プロジェクトが停止する。

原因。データの所在確認を発注前に行っていない。紙、画像PDF、部署ごとの独自様式が混在していることに、発注してから気づく。

対策。相談前に、対象データを実際に10件だけ集めてみる。10件集めるのに苦労するなら、1万件は集まりません。この段階で難しいと分かれば、まずデータを電子化・統一する工程を独立した作業として計画できる。

失敗3｜検収基準が言葉だけ

症状。納品されたが、「これで合格なのか」を社内で判断できない。支払いも運用開始も止まる。

原因。契約書に「検収」という語はあるが、何をどう測って合格とするかが書かれていない。

対策。検収には、①測るためのテストデータの件数と用意する人、②判定の手順と判定者、③合格の数値、④検収期間、の4つを書く。とくに「◯日以内に異議がなければ検収完了とみなす」という条項の日数は、自社が現実に確認できる長さかを必ず確認してください。契約条項ごとの読み方は準委任と請負の違いに整理しています。

失敗4｜運用の担当者が不在

症状。納品直後は使われていたが、3か月後には誰も使っていない。おかしな出力が出たときに直せる人がいない。

原因。作ることが目的化し、運用の担当者と役割を決めていない。導入を推進した担当者が異動して終わる例も多い。

対策。発注段階で、運用担当者を名前で決める。そのうえで、月次で確認する項目、おかしいと判断する基準、止める権限を持つ人を書き出す。管理の枠組みはAIエージェント導入の管理の台帳形式が使えます。

失敗5｜社内が使わず終わる

症状。できあがったものは要件どおりだが、現場が従来のやり方を続けており、誰も使っていない。

原因。現場の担当者が設計に関与しておらず、実際の業務手順と合っていない。「使ってみたが、結局手でやり直すほうが早い」という状態。

対策。検証の段階で、実際にその業務をしている担当者に必ず触ってもらう。経営層や情報システム担当だけで評価しない。加えて、新しいやり方に切り替える日を決め、旧手順を止める。並行運用を長く続けると、必ず旧手順に戻ります。

内製と外注の分かれ目

ここまで外注を前提に書いてきましたが、すべてを外注する必要はありません。むしろ中小企業では、内製と外注を組み合わせるのが最も現実的です。分かれ目を整理します。

内製が向く3つの条件

次の3つが揃うなら、まず社内で試すほうが速く、安く済みます。

• 対象業務が1部署で完結する……他部署や基幹システムとの調整が不要
• 既存のAIサービスの設定で足りる……新規のプログラム開発を伴わない
• 触れる担当者が社内にいる……Excelの関数を組める程度の人が1人いれば十分な場合が多い

近年は、業務手順をAIに実行させる仕組みを、プログラムを書かずに組み立てられる環境が増えています。作り方の手順はAIエージェントの作り方｜業務で使う手順と限界で解説していますので、内製を検討する場合は先にこちらをご覧ください。この記事を読んで「できそう」と思えるなら、その業務は外注しないほうがよい可能性が高いです。

外注が向く3つの条件

反対に、次に当てはまる場合は外注を検討する価値があります。

• 基幹システムや外部サービスとデータ連携する……接続の設計と保守に専門知識が要る
• 止まると業務が回らない……監視・復旧の体制が必要になる
• 社外に出せないデータを扱う……環境の分離やアクセス管理の設計が要る

要するに、失敗したときの影響が社内の一部署にとどまらないものは外注に向きます。逆に、失敗しても誰も困らない範囲から内製で始めるのが、最も学習効率の高い進め方です。

AIに任せる範囲と人が決める範囲

内製・外注のどちらを選ぶ場合でも、「AIに任せる作業」と「人が決める判断」の線引きは、発注側が自分で引く必要があります。受託会社は技術的に可能かどうかは答えられますが、自社にとって許容できるかどうかは答えられません。ここは外注できない部分です。

線引きの原則は1つです。取り返しがつく作業はAIに任せてよい。取り返しがつかない判断は人が行う。「取り返しがつく」とは、間違いに後から気づいて直せる、社外に出る前に人の目を通る、という意味です。

とくに検収の合否判定は、絶対に人が行ってください。AIに評価させると、AIが作ったものをAIが採点する構造になり、業務に合うかどうかという最も重要な観点が抜け落ちます。契約の解釈で迷う箇所は、弁護士など専門家に渡す線引きも決めておいてください。AIの回答は下調べには使えますが、最終判断の根拠にはできません。

併用が一番現実的

実務では、「内製で試して、伸びそうなものだけ外注する」という順番が最も無駄がありません。社内で1〜2か月試すと、その業務にAIが効くかどうかがだいたい分かります。効くと分かってから外注すれば、検証工程を短縮でき、発注時の説明も具体的になります。

費用面では、公的な支援制度も選択肢に入ります。中小企業向けにはIT導入補助金などの制度があり、対象や要件は年度ごとに変わります。申請できるかどうかは、発注先が支援事業者として登録されているかにも左右されるため、商談時に確認してください。

モデルケース｜40名の製造業

ここまでの内容を、1つの具体例にまとめます。以下はモデルケース（試算）であり、実在の企業ではありません。中小企業でよくある状況をもとに、発注の流れと効果の見込みを組み立てたものです。

※金額は「時給換算2,500円・月20営業日」を前提とした試算です。実際の効果は業務内容・データの状態・運用方法により変動します。

E社の前提と困りごと

E社は従業員40名の金属加工業。受注生産が中心で、営業事務2名と製造管理1名が事務作業を担っています。社長がAI導入を検討し始めたきっかけは、営業事務の残業が慢性化していたことでした。

洗い出した困りごとは4つです。①顧客から届く仕様の問い合わせメールへの回答に時間がかかる、②見積書の作成に過去案件を探す時間が必要、③作業日報の転記が手作業、④加工条件の質問が特定のベテランに集中している。

この段階でE社は、いきなり開発会社に相談せず、まず市販の生成AIサービスで4業務を1件ずつ試しました。結果、①と④はそのままでもある程度使えることが分かり、②と③は既存データとの連携が必要で手作業では回らないと判断しました。

依頼の分け方と進め方

E社は業務を2つに分けて進めました。この分け方が費用を抑える鍵になっています。

外注する②③については、RFP13項目を1枚にまとめて2社に提示し、検証6週間・打ち切り基準つきの準委任契約でスタートしました。「6週間で過去100件の見積もり項目の抽出一致率が8割に届かなければ中止」と書いたことで、社内の承認も通りやすくなったといいます。

試算｜削減時間の内訳

4業務を合わせた月間の削減時間の試算です。効果は時間で見てください。

合計で月68時間の作業が減る計算になります。営業事務2名の残業がほぼ解消し、ベテラン社員が加工条件の質問に取られていた時間を現場に戻せた点が、E社にとっては大きな変化でした。

費用面では、内製部分（①④）は既存サービスの利用料のみで、開発費は発生していません。外注した②③についても、先に内製で試して「効く業務」を絞り込んだため、検証にかける工数を小さくできました。

つまずいた点と直し方

順調な話だけでは参考になりませんので、E社がつまずいた点も書きます。

1つ目は、過去の見積もりデータの様式が3世代に分かれていたこと。検証の初週に発覚し、統一作業に2週間を要しました。発注前に10件だけ現物を確認していれば、事前に気づけた問題です。

2つ目は、日報の転記でベテラン社員が独自の略語を使っていたこと。AIが略語を解釈できず、最初は精度が出ませんでした。対処として、略語と正式名称の対応表を作って読み込ませたところ改善しています。この対応表は社内の新人教育にも転用でき、副産物として役に立ったそうです。

3つ目は、運用開始後1か月で使用率が落ちたこと。原因は「AIの下書きを直すより自分で書くほうが早い」と感じた担当者がいたことでした。E社は月1回15分の振り返りを設け、どの部分が使いにくいかを聞き取って指示文を調整する運用に切り替えています。作って終わりにせず、聞き取りの場を定例化したことが定着の分かれ目になりました。

よくある質問（FAQ）

Q. AI受託開発の相場はいくらですか

A. 出典を示せる公的な相場データは、現時点で存在しないと考えてください。IPAの「ソフトウェア開発分析データ集」は発行が終了しており、AI開発案件の単価を継続的に集計した公的統計もありません。相場を探すより、本記事の「見積もりを動かす6つの変数」で目の前の見積もりを分解するほうが実用的です。

Q. 見積もりが会社ごとに大きく違うのはなぜですか

A. 含まれている工程が違うためです。検証工程の有無、データ整備を誰がやるか、運用保守が含まれるか、この3つで金額は大きく動きます。各社に同じRFPを渡し、除外事項を1行ずつ書かせると理由が見えます。

Q. 何も決まっていない状態で相談してよいですか

A. 相談自体は可能ですが、その場合は最初に「何を作るかを決める作業」が有償の工程として発生します。困っている業務を紙に書き出し、月間何時間かかっているかを添えるだけでも、話の精度が変わります。

Q. 契約は請負と準委任のどちらを選ぶべきですか

A. AI開発では準委任を中心に組む場面が多くなります。IPAのアジャイル開発版モデル契約も準委任を前提としています。ただし要件が固まっており完成を定義できる部分は請負でも構いません。判断基準の詳細は準委任と請負の違いをご覧ください。

Q. 途中でやめることはできますか

A. 民法第641条により、請負では仕事が完成しない間、注文者は損害を賠償して契約を解除できます。準委任の場合も解除に関する規定があります。ただし実務上は、契約書に中止時の精算方法を明記しておくほうがはるかに円滑です。

Q. 作ったものの権利は自社のものになりますか

A. 自動的にはなりません。契約で定める必要があります。受託会社が新たに書いた部分、従来から持つ汎用部品、オープンソースの利用部分で扱いが分かれます。譲渡を受ける場合は著作権法第27条・第28条の権利を含める旨の記載が実務上必要です。

Q. 自社のデータが学習に使われないか心配です

A. 契約書に、提供データの利用目的を本件業務に限定すること、契約終了後の消去義務、受託会社が利用する外部AIサービス名の開示を書き込んでください。個人情報を含む場合は個人情報保護委員会の注意喚起もあわせて確認してください。

Q. PoCだけを頼むことはできますか

A. できます。むしろ推奨される進め方です。期間の上限、試行回数、打ち切り基準を明記した準委任契約で実施し、結果を見てから実装を発注するのが、費用を抑える最も確実な方法です。

Q. 精度は何%あればよいのでしょうか

A. 一般的な正解はありません。人が確認して直す前提の業務なら7〜8割でも十分に役立ちますし、社外に直接出る文書なら人の確認工程を必ず挟む設計にします。必要な精度は業務の性質から逆算して決めてください。

Q. 発注側の社内工数はどれくらい必要ですか

A. 業務にもよりますが、検証期間中は担当者1名が週に数時間は関与する想定でいてください。データの提供、出力の確認、現場への確認が発生します。ここを見込んでいないと、プロジェクトが受託会社側の待ち状態になります。

Q. 補助金は使えますか

A. 中小企業向けにはIT導入補助金などの制度があります。対象経費や要件は年度ごとに変わり、発注先が支援事業者として登録されている必要がある枠もあります。商談時に必ず確認してください。

Q. 開発会社の担当者に直接指示を出してよいですか

A. 「何を作ってほしいか」の要望は伝えて構いませんが、「誰がいつ何時間作業するか」の指揮命令は受託会社が行います。判断に迷う場合は厚生労働省の37号告示に関する疑義応答集を確認してください。

Q. 発注してからどれくらいで使い始められますか

A. 対象業務の規模とデータの状態で大きく変わります。データが電子で整っていれば検証に数週間、そうでなければ整備だけで数か月かかることもあります。納期を左右する最大の要因はデータの状態だと考えてください。

まとめ

• AI受託開発の成否は、業務の絞り込み・データ・合格基準という発注側が握る3変数で決まる
• 頼める仕事は「調査／検証／実装／運用」の4分類。含む・含まないを必ず明示させる
• 公的な相場データは存在しない。金額は6つの変数で読み解き、除外事項を1行ずつ確認する
• 契約は準委任が中心。IPAのアジャイル開発版モデル契約も準委任を前提としている
• 発注前に6項目を決め、RFP13項目にまとめてから相談すると見積もりの精度が上がる
• 失敗の多くは「打ち切り基準がない」「データが揃わない」「検収基準が言葉だけ」で起きる
• まず内製で試し、効くと分かった業務だけを外注するのが最も無駄が少ない

AI受託開発は、発注書を書くところから勝負が始まっています。「どこを外注し、どこを社内で持つか」を仕分けるだけで、費用も期間も大きく変わります。

Ai-Rakuでは、初期費用0円・月額5万円〜で、業務の洗い出しから発注書づくり、導入後の定着支援までを伴走しています。「開発が必要かどうかから相談したい」という段階でも構いません。まずは無料相談をご利用ください。対象業務の選び方は業務別ソリューション一覧、導入全体の進め方は中小企業のAI導入、社内で作る場合はAIエージェントの作り方もあわせてご覧ください。