AI開発を外注する前に決めること:依頼する範囲・進め方・見積の見方
AIの受託開発を成功させるには、AI開発会社へ相談する前に、何を解決したいのか、どの業務を対象にするのか、何をもって成功とするのかを社内で決めることが重要です。最初から完成形を一括で発注するのではなく、実現可能性を確認し、検証と開発を段階的に進めることで、目的と成果物のずれを抑えやすくなります。
本記事では、AIを使った仕組みの開発を外部へ依頼したい中小企業に向けて、発注前の整理、開発方法の選び方、契約の進め方、見積の確認項目を解説します。コンサルティング、研修、顧問などを含む外部支援全般の比較については、AI導入支援とは?4つの支援タイプと費用・会社の選び方をご覧ください。作るものがまだ決まっておらず、相談しながら小さく作り進めたい場合は、AIの伴走支援とは?支援の中身と、コンサル・研修・開発委託との違いで、継続して支援を受ける方法を紹介しています。
AIの受託開発とは
AIの受託開発とは、企業の課題や業務に合わせたAIの仕組みについて、設計や試作、システム開発などを外部の会社へ依頼することです。AIそのものだけでなく、利用画面、データの取り込み、既存システムとの連携、権限管理なども依頼範囲に含まれる場合があります。
AI導入支援のうち、コンサルティングは、業務の整理や活用方針の策定、導入計画の作成などが中心です。一方、受託開発では、要件に基づいて実際に動作する仕組みを作ることが主な目的になります。ただし、会社によっては、業務整理からPoC、開発、運用までをまとめて支援する場合もあるため、相談できる範囲を確認する必要があります。
内製は、自社の従業員が中心となって設計や開発を進める方法です。業務変更へ対応しやすく、知見を社内に蓄積しやすい一方、必要な人材や開発時間を確保しなければなりません。外注と内製のどちらか一方に限定せず、外部の会社に初期開発を依頼し、運用や改善を徐々に社内へ移す方法も考えられます。
外注で依頼できることの例
外注できる範囲は、課題の整理だけを支援してもらう場合から、運用を含めて依頼する場合までさまざまです。代表的な例には、次のようなものがあります。
- 社内文書を検索して答える仕組み:規程、手順書、製品資料などを参照し、従業員の質問に回答します。参照できる文書の範囲や、回答の根拠を表示する方法も検討します。
- 業務を進めるAIエージェント:情報の収集、内容の分類、回答案の作成、担当者への通知など、複数の作業を一定の流れで進めます。人による承認が必要な箇所を明確にすることが重要です。
- 既存システムへのAI機能の組み込み:現在利用している業務システムへ、文章の要約、入力内容の分類、検索、回答案の作成などの機能を追加します。
- 予測・分析:蓄積したデータを使って需要や傾向を予測したり、判断に必要な情報を整理したりします。利用できるデータの量だけでなく、内容や記録方法の確認が必要です。
同じ仕組みでも、助言を表示するだけなのか、後続の処理まで自動で実行するのかによって、必要な開発や安全対策が異なります。まずは対象業務と、人が確認すべき箇所を決めたうえで依頼範囲を検討します。
AI開発を外注する前に社内で決めておくこと
AI開発の外注を検討するとき、最初に「どのAIを使うか」を決める必要はありません。先に整理すべきなのは、業務上の課題と、開発後に実現したい状態です。少なくとも次の項目は、社内で言葉にしておきましょう。

目的と対象業務
まず、「AIを導入すること」ではなく、「どの問題を解決するか」を目的として定めます。たとえば、問い合わせ対応そのものを改善したいのか、回答案を作る作業を軽くしたいのかでは、必要な仕組みが異なります。
対象業務は、開始条件、入力する情報、作業手順、判断が必要な箇所、出力先まで分解します。担当者によって進め方が違う場合は、その違いも整理します。業務の境界が曖昧なまま依頼すると、開発会社が想定した範囲と、現場が期待する範囲にずれが生じます。
利用できるデータ
AIは、目的に合うデータや参照情報を利用できるかによって、実現方法が変わります。社内文書、問い合わせ履歴、商品情報、入力帳票など、利用候補となる情報を洗い出しましょう。そのうえで、保存場所、形式、更新方法、閲覧権限、社外への提供可否を確認します。
データが存在していても、記載方法が統一されていない、紙でしか残っていない、利用条件を確認できないといった場合があります。見積を依頼する際は、「データがある」とだけ伝えず、開発会社が内容と利用可能性を確認できる状態にすることが大切です。
成功の基準
成功の基準は、「便利になった」といった感想だけでなく、検証時に確認できる形にします。処理にかかる時間、担当者が修正する頻度、正しく処理できた件数、利用者が継続して使えるかなど、対象業務に合う観点を選びます。
AIの出力には確認や修正が必要な場合があります。そのため、完全な自動化だけを成功とせず、どこまでをAIに任せ、どこから人が判断するかも決めておくと、現実的な評価ができます。
社内の担当者
AI開発の業務委託では、発注後も社内の協力が必要です。業務の説明、データの確認、試作品の評価、利用部門との調整を担う担当者を決めます。最終判断をする責任者と、日常的に開発会社と連絡する窓口を分ける場合は、それぞれの役割も明確にしましょう。
現場を知らない担当者だけで進めると、実際の手順や例外処理が仕様に反映されにくくなります。対象業務を担当する人が、検証と受け入れ確認に参加できる体制が必要です。
相談に使う依頼書
社内で整理した内容は、開発会社へ渡す依頼書にまとめます。目的、対象業務の流れ、利用できるデータの例、成功の基準、想定する予算と時期を記載しましょう。現時点で決まっていることと、提案を受けて決めたいことを分けて書くと、開発会社が検討しやすくなります。
最初から詳細な仕様書を完成させる必要はありません。実際の帳票や文書の例、現在の作業手順、困っている場面を示すだけでも、前提のずれを減らせます。複数社へ見積を依頼する場合は、同じ依頼書を渡すことで、提案範囲を比較しやすくなります。
既製サービス、現在のツールの設定、個別開発の違い
AIを使いたいからといって、必ずしも個別の受託開発が必要とは限りません。既製サービスの導入、現在利用しているツールの設定や連携、個別開発のどれが適しているかを比較します。
| 方法 | 向いている状況 | 主な確認点 |
|---|---|---|
| 既製サービスの導入 | 一般的な業務で、既存機能に業務を合わせられる | 必要機能、データの扱い、権限、他ツールとの連携 |
| 現在のツールの設定・連携 | 既存環境を残しながら、転記や通知などの流れを改善したい | 利用中の契約で可能な設定、連携方法、運用担当 |
| 個別開発 | 独自の業務手順や判断、複数システムとの連携が必要 | 開発範囲、検証方法、保守、成果物の権利 |
判断の起点は、業務を既製サービスに合わせられるかです。合わせられるなら、個別開発をせずに目的を達成できる可能性があります。現在のツールに必要な機能があり、設定や連携で不足を補えるなら、そこから試す方法もあります。
既製サービスや現在のツールで、必要な機能、権限管理、データの扱い、運用方法を満たせる場合、受託開発は不要です。独自機能を作ること自体を目的にせず、設定変更や業務手順の見直しを含めて、より小さな方法で課題を解決できないか確認しましょう。
一方、自社独自の判断を組み込みたい、複数の情報源を横断したい、既存の業務システムへ出力したい場合は、個別開発が選択肢になります。AI開発会社には、希望する機能だけでなく、「既製機能や設定で代替できる部分も含めて提案してほしい」と伝えると、依頼範囲を検討しやすくなります。
AI開発を外注するメリット
専門知識と開発体制を利用できる
AIの仕組みを実際の業務で使うには、AI技術だけでなく、データの扱い、利用画面、既存システムとの連携、権限管理、運用設計など複数分野の知識が必要です。外注すれば、自社だけではそろえにくい知識や開発体制を、必要な段階で利用できます。
社内の人員を本業に充てやすい
設計や実装を外部へ依頼することで、社内担当者は業務要件の整理、試作品の評価、社内調整など、自社でなければ判断しにくい仕事へ集中できます。ただし、外注しても発注側の確認作業はなくならないため、担当者の時間はあらかじめ確保します。
開発期間を短くしやすい
必要な人材を社内で採用・育成してから着手する場合と比べ、経験のある会社へ依頼すれば、調査や試作を早く始められる場合があります。似た課題への対応経験や既存の開発方法を活用できることもあります。ただし、データ提供や社内承認が遅れると進行は止まるため、外注先と自社の双方で日程を管理することが必要です。
AI開発を外注するときの注意点
社内に知見が残りにくい場合がある
設計や設定を外部へ任せきると、仕組みの変更理由や運用方法を社内で説明できなくなる場合があります。担当者が交代したときや、別の会社へ保守を依頼するときに困らないよう、設計資料、設定情報、操作手順、変更履歴など、引き渡してもらう資料を決めておきましょう。
打ち合わせに社内担当者が参加し、判断の経緯を記録することも重要です。将来的に内製する予定がある場合は、社内への説明や引き継ぎを依頼範囲に含めます。
やり取りの手間を見込む必要がある
外注しても、業務説明やデータ提供、試作品の確認、社内調整は発注側が行います。確認が遅れると、開発日程にも影響する場合があります。窓口、承認者、回答期限を決め、定例会議や確認方法を開発会社と共有しましょう。
特に、文章で説明しにくい業務は、実際の画面や帳票を見せながら伝えると認識を合わせやすくなります。通常の流れだけでなく、例外や担当者ごとの差も伝えることが大切です。
機密情報の扱いを確認する
顧客情報、従業員情報、契約書、社内文書などを利用する場合は、提供範囲を必要最小限にします。保存場所、アクセスできる人、外部サービスへの送信、検証終了後の削除、記録の保持などを確認してください。
実データを使わずに検証できる段階では、内容を置き換えたデータを利用する方法もあります。実データが必要になった時点で、社内規程や契約条件に照らして提供可否を判断します。
AIの受託開発は段階を分けて進める
経済産業省が2018年に公表した「AI・データの利用に関する契約ガイドライン」では、AI開発について「探索的段階型」の進め方が推奨されています。開発を一度に確定するのではなく、次の段階ごとに目的と契約を分ける考え方です。
- アセスメント段階:対象業務、利用するデータ、実現したいことを確認します。この段階では秘密保持契約を結びます。
- PoC段階:限られた範囲で、技術的に実現できるか、業務で役立つ可能性があるかを検証します。導入検証契約を結びます。
- 開発段階:PoCの結果を踏まえ、実際に利用するソフトウェアを開発します。ソフトウェア開発契約を結びます。
- 追加学習段階:運用後のデータなどを利用し、必要に応じて追加学習を進めます。利用契約を結びます。

段階ごとに契約書を作ることで、その時点で確認できたことを次の契約へ反映できます。特にPoCでは、検証用の試作品と、実際に継続利用できる仕組みを区別する必要があります。PoCの成果物をそのまま本番運用できると決めつけず、開発段階へ移る条件をあらかじめ話し合いましょう。
また、すべての案件で追加学習が必要とは限りません。既存のAIサービスを利用する構成も考えられるため、何を開発し、どの部分に既存サービスを使うのかを確認します。契約内容は案件によって異なるため、不明点があれば専門家への確認も検討してください。
PoCの合格ラインと撤退基準を決める
PoCを始める前に、何がどこまでできれば本番開発へ進むのかを決めます。たとえば、指定した業務パターンを処理できること、担当者が許容できる修正量に収まること、必要なデータを継続して用意できることなど、技術面と業務面の両方から合格ラインを定めます。
同時に、期待する結果を得られない、必要なデータを確保できない、運用時の確認負担が削減効果に見合わないといった場合の撤退基準も決めます。結果を見てから基準を変えると判断が長引きやすいため、評価する人、使用データ、判断日とともに事前に合意しておきます。全面的に中止するだけでなく、対象業務を狭める、既製サービスへ切り替えるといった判断も選択肢です。
検収の基準を開発前に決める
段階を分ける際は、それぞれの段階で何をもって完了とするかも決めます。納品されたことだけを完了条件にせず、対象機能、確認に使うデータ、期待する動作、許容する例外を検収の基準として整理しましょう。
検収を行う人と期限も明確にします。業務担当者が実際の手順に沿って確認し、情報システムや管理部門が権限や運用面を確認するなど、役割を分ける方法があります。AIの出力には幅があるため、すべての出力が同じになることだけを条件にせず、成功の基準と人による確認方法を組み合わせて評価します。
見積で確認すること
見積は総額だけでなく、「何をどこまで行う金額か」を読みます。同じ名称のAI開発でも、業務整理、データ準備、画面作成、外部ツールとの連携、テストなど、含まれる作業は会社によって異なります。

費用の内訳
費用は、PoC、開発、運用・保守のどの段階にかかるものかを分けて確認します。PoCでは、業務やデータの調査、検証環境の準備、試作品の作成、評価に費用がかかる場合があります。開発では、要件定義、画面や連携機能の実装、データの整備、テスト、利用手順の作成などが主な内訳になります。
運用・保守では、稼働状況の監視、障害対応、問い合わせ対応、外部サービスの利用、データや設定の更新などが対象になり得ます。初期の開発費用だけでなく、稼働後に継続する費用と、機能追加の際に別途発生する作業を確認しましょう。
見積に「一式」と書かれている場合は、作業内容、成果物、回数、対象範囲を確認します。前提が変わった場合の追加費用や、PoCで期待した結果が得られなかった場合の扱いも、契約前に話し合っておくと判断しやすくなります。
含まれる作業と成果物
要件整理、データの確認・整形、試作品の作成、画面や連携部分の開発、テスト、利用手順の作成、社内向け説明などが、見積のどこに含まれるかを確認します。成果物についても、動作する仕組みだけなのか、設定情報や設計資料、操作手順まで引き渡されるのかを明確にします。
依頼側が準備する作業も重要です。データ提供、内容確認、利用者への聞き取り、テスト環境の用意など、社内対応が必要な項目と期限を確認しましょう。
検証の範囲
検証に使うデータ、対象とする業務パターン、結果の評価方法を確認します。通常の処理だけでなく、入力が不足している場合や、AIが適切な回答を出せない場合にどう扱うかも検討します。
「精度を確認する」という表現だけでは、評価する人や合格条件が分かりません。誰が、どのデータを使い、何を基準に次の段階へ進むかを、発注側と開発会社で共有します。
保守・運用
稼働後の監視、障害時の連絡、利用中の外部サービスが変更された場合の対応、機能変更の扱いを確認します。日常的な設定変更を自社で行えるのか、開発会社への依頼が必要なのかも運用負担に影響します。
AIの出力を誰が確認するか、誤った出力があったときに処理を止められるか、履歴を確認できるかといった運用設計も見積段階で相談しておきましょう。
作ったものの権利
プログラム、設定、画面、資料、入力データ、加工後のデータなどについて、利用できる範囲と権利の帰属を確認します。契約終了後も利用できるのか、別の会社へ保守を依頼できるのか、外部サービスの契約が別途必要なのかも確認事項です。
自社固有のデータや業務情報が、どの環境に保存され、開発や検証の終了後にどう扱われるかも書面で確かめます。
AI開発会社の選び方
開発会社のタイプが自社に合うか
AI開発会社は、得意とする支援の範囲によって、主に次のようなタイプに分けて考えられます。
- 幅広い業務に合わせて作る会社:業務整理から画面、連携、運用まで幅広く相談したい場合に向いています。
- 特定の業界に強い会社:業界固有の業務手順、用語、規制、商習慣への理解を重視する場合に候補となります。
- 特定の技術に強い会社:画像認識や生成AIなど、利用する技術と解決したい課題の関係が明確な場合に適しています。
- 開発と人材育成を合わせて支援する会社:仕組みを導入するだけでなく、将来の運用や改善を社内へ移したい場合に向いています。
タイプの名称だけで決めず、自社に不足しているものから選びます。課題自体が固まっていなければ業務整理を支援できる会社、要件が明確なら必要な技術と実装力を持つ会社、将来内製したいなら資料や研修まで提供できる会社が候補です。一社ですべてを担当するとは限らないため、担当範囲と引き継ぎ方法も確認します。
似た業務の実績があるか
業界名だけでなく、対象業務や利用データ、既存システムとの連携方法が自社の計画と近いかを確認します。実績を聞く際は、何を作ったかだけでなく、どの課題をどのように整理し、どの範囲を担当したかも確認しましょう。
必要な技術と開発体制があるか
AIに関する技術だけでなく、画面、データベース、外部システムとの連携、権限管理などを含めた体制を確認します。担当者の役割、連絡窓口、問題が起きた際の対応方法が明確かも判断材料になります。
PoCから運用まで支援できるか
PoCだけを得意とする会社と、本番開発や運用まで対応する会社では支援範囲が異なります。自社がどの段階まで依頼したいかを踏まえ、PoC後の開発、利用開始時の説明、稼働後の保守まで相談できるかを確認します。途中で担当会社が変わる場合は、成果物を引き継げるかも重要です。
提案力とやり取りのしやすさ
依頼内容をそのまま実装するだけでなく、既製サービスで代替できる部分、対象範囲を小さくできる部分、想定される運用上の課題を説明できる会社は、計画の見直しにも役立ちます。専門用語だけに頼らず、判断に必要な選択肢と違いを説明してくれるかを見ます。
打ち合わせ後の記録、質問への回答、変更事項の共有方法など、日常的なやり取りの進め方も確認します。提案内容が優れていても、意思決定に必要な情報が伝わりにくければ、開発中の負担が大きくなる場合があります。
見積と契約が分かりやすいか
作業範囲、成果物、発注側の役割、追加費用が発生する条件、検収方法が明確かを確認します。複数社を比較するときは総額だけで判断せず、含まれる工程と運用開始後の条件をそろえて見ます。説明が曖昧な項目は、契約前に書面で回答を求めましょう。
AI開発の外注でよくある質問
Q1. 要件が固まっていなくてもAI開発会社へ相談できますか?
相談はできますが、少なくとも目的、対象業務、利用できるデータ、成功の基準は仮置きしておくことをおすすめします。要件整理から依頼する場合は、その作業が見積に含まれるか、整理後に開発範囲と契約を見直せるかを確認しましょう。
Q2. PoCだけを依頼できますか?そのまま本番で使えますか?
PoCだけを依頼できる会社もあります。契約前に、検証終了時の成果物、評価報告、データや設定の引き渡し、本番開発を別の会社へ依頼できるかを確認してください。
PoCは実現可能性を確かめる段階であり、本番利用を前提とした開発とは目的が異なります。利用者の権限管理、監視、例外処理、既存システムとの連携など、本番運用に必要な作業が別に発生する場合があります。PoCの契約時に、成果物の用途と開発段階へ進む条件を確認してください。
Q3. AI開発の業務委託では、社内担当者は何をすればよいですか?
対象業務の説明、データの準備、試作品の確認、現場からの意見収集、意思決定を担います。外注先に任せきるのではなく、実際の業務を知る担当者が継続して確認することで、必要な例外処理や運用ルールを反映しやすくなります。
Q4. 開発にかかる期間はどのように考えればよいですか?
期間は、機能の数だけでなく、要件整理、データの確認、PoC、社内での評価、既存システムとの連携、検収に必要な時間を含めて考えます。開発会社の作業期間だけでなく、自社がデータを用意する期間や、利用部門が確認する期間も計画に入れましょう。未確定な点が多い場合は、全工程を一度に決めず、段階ごとに日程を見直す方法があります。
Q5. 自社にデータが少なくても相談できますか?
相談できます。必要なデータの量や内容は、実現したいことと開発方法によって異なります。社内文書を参照する仕組みや既存のAIサービスを利用する構成など、独自の学習用データを大量に用意しない方法も考えられます。まずは保有している文書や記録の例を示し、不足する情報、整備方法、検証できる範囲を開発会社と確認しましょう。
Q6. 作ったものの知的財産権はどうなりますか?
権利の帰属や利用できる範囲は、成果物の種類や契約によって異なります。プログラム、設定、設計資料、加工したデータなどを分け、誰に権利が帰属するか、自社が継続利用・変更できるか、別の会社へ保守を依頼できるかを確認しましょう。既存の部品や外部サービスを利用する場合は、その利用条件も別に確認し、契約書へ明記します。
まとめ
AIの受託開発を依頼する前に、目的、対象業務、利用できるデータ、成功の基準、社内担当者を整理します。そのうえで、既製サービス、現在のツールの設定・連携、個別開発を比較し、必要な部分だけを外注範囲にします。
開発はアセスメント、PoC、開発、追加学習の段階に分け、各段階の目的と契約を確認することが大切です。PoCの合格ラインと撤退基準を先に定め、見積では、含まれる作業、検証範囲、保守・運用、成果物の権利まで確認し、自社側の作業も含めて実行可能な計画にしましょう。
社内だけで整理と実装を進めるのが難しい場合は
ここまでの手順を、社内だけで進めるのが難しい場合もあります。担当者が通常業務と兼務している、ツールをつなぐ設定まで手が回らない、といった場合です。
LeapAIのAI顧問では、初期の業務棚卸しを90分で行い、自動化の候補を洗い出して12か月の計画を作ります。隔週の会議で「今月の1本」を決め、画面共有をしながら一緒に作成し、利用企業へ引き渡します。
Slack、Chatwork、Google Workspace、Microsoft 365、kintoneなど、現在利用しているツールに合わせて仕組みを作ります。作成した自動化は利用企業の名義で残ります。社外への送信を伴う処理は、人が確認してから実行する設計です。
稼働後は自動化を監視し、失敗時に通知します。自動化ごとの処理件数と削減時間を月次レポートで報告し、90日ごとに計画を見直します。最初に自動化する業務を決めきれない場合は、60分の無料相談で候補をご提案します。
出典・参考情報
- モノリス法律事務所「AIのソフトウェア開発契約は請負か委任か?契約の要注意ポイントを解説」
- 経済産業省「AI・データの利用に関する契約ガイドライン」(2018年)
- LeapAI「AI導入支援とは?4つの支援タイプと費用・会社の選び方」
この記事の監修者

新卒で株式会社リクルートに入社し、HR領域のマーケティング業務に従事。2024年9月に株式会社LeapAIを創業し、生成AIによる業務の自動化とAI動画制作で企業の事業成長を支援している。事業売却の経験を持ち、戦略の設計から実行までを一貫して担う。
※本記事は生成AIを活用して制作しています。内容はLeapAI編集部がファクトチェックおよび編集を行い、 図解・画像は生成AIで作成したもの、または実際のサービス画面を掲載しています。
AI顧問のサービス紹介資料を無料で受け取る
