AIシステム開発の要件定義｜外部チームへの発注で通常開発と変わる5つの勘所

「AIで業務を効率化できないか検討してほしい」——経営層からそう言われ、外注を前提に進めようとした矢先に、「AIは普通のシステム開発と進め方が違うらしい」という話を耳にして手が止まった。そんな発注担当者の方は少なくないはずです。受発注システムや在庫管理システムの外注は何度も経験しているのに、AI案件となると、同じ感覚で要件定義書を渡して大丈夫なのか確信が持てない。

不安の正体は、おそらく「やってみないと分からない」という、AIに特有のあいまいさです。通常のシステム開発であれば「この画面でこの処理をする」と仕様を固めきってから発注し、仕様どおり動くかどうかで検収できます。ところがAIは、十分なデータをそろえても狙った精度が出るとは限らず、完成の形を発注前に確定できません。この性質の違いが、「精度が出なかったら誰の責任か」「仕様が変わる前提でどう契約すればいいか」「検収で揉めないか」といった、外注の根幹に関わる不安につながっています。

結論から言えば、AIシステム開発の外注で通常と決定的に変わるのは、たった5つの勘所です。要件の固め方・契約形態・検収基準・知財の線引き・体制の組み方。この5点さえ押さえれば、これまでの外注経験はそのまま活きますし、外部チームへのAI発注も十分にマネジメントできます。

本記事では、AIシステム開発の要件定義を外部チーム（フリーランス・受託ベンダー）に発注する際、通常のシステム開発の外注と何がどう変わるのかを、発注者の言葉で整理します。なお、要件定義書そのものに「何を書くか」（精度要件・学習データ要件・ハルシネーション対策の明文化）は別記事のAI開発の要件定義の書き方で詳しく解説しているため、本記事は「外部チームへの発注プロセスの違い」に絞って解説します。

AIシステム開発の要件定義が通常のシステム開発と根本的に違う理由

なぜ、通常の外注と「同じ進め方」が通用しないのでしょうか。理由はひとつ、AIシステムが「確率的でデータに依存する」性質を持っているからです。

従来の業務システムは、ルールベースで動きます。「この条件ならこの処理」という仕様を決めれば、その通りに動き、結果も予測できます。だからこそ仕様を100%固めてから発注し、仕様どおりかどうかで完成を判断できました。一方でAIは、学習データから統計的にパターンを学ぶため、同じ仕様を渡しても出てくる成果（精度）が事前に読めません。経済産業省のAI・データの利用に関する契約ガイドラインも、「求められる精度の学習済みモデルができあがるか事前に予測することが困難」とAI開発の特性を整理しています。

従来システムとAIシステムの違い

両者の違いを、発注者の関心軸で並べると次のようになります。

違いが外注プロセス全体に波及する理由

重要なのは、この「成果が読めない」という1点が、外注のあらゆる工程に波及することです。仕様を固めきれないから要件の渡し方が変わり、完成を約束できないから契約形態の選び方が変わり、精度を保証できないから検収基準の決め方が変わります。さらに、データを預けるから知財の線引きが複雑になり、探索的に進めるから連携の仕方にまで影響が及びます。

裏を返せば、波及する先は「要件・契約・検収・知財・体制」の5つに整理できるということです。次の章から、この5つの違いを順に見ていきます。

違い①｜要件は「固める」より「探索しながら絞る」前提で渡す

最初の違いは、要件の渡し方です。通常開発では要件を固めて一括で発注しますが、AIでは「実現できるかをまず確かめてから、本開発に進む」という二段構えが基本になります。

PoCと本開発を分けて発注する

AI開発では、いきなり本開発に入らず、PoC（概念実証）と呼ばれる検証フェーズを先に置くのが定石です。PoCとは、「手元のデータで、狙った精度のモデルが本当に作れそうか」を小さく試す工程を指します。特許庁・経済産業省が公開するオープンイノベーションモデル契約書（AI編）も、AI開発を「秘密保持 → PoC → 本開発」の段階に分け、「やってみないと分からない」というAI開発の性質に合わせて設計されています。

発注者として大事なのは、PoCを「無駄な追加コスト」と捉えないことです。実現可能性が不透明なまま本開発を一括発注すると、精度が出なかったときに費用がまるごと無駄になります。PoCはむしろ、本開発に進むかどうかを安く見極めるためのリスク低減策です。

発注者が最初に渡すべきもの

では、仕様が固まらないなかで、発注者は何を渡せばよいのでしょうか。完璧な仕様書ではありません。次の3点をできる範囲で言語化することが、外部チームにとって最も役立ちます。

• 解きたい業務課題: 「何を効率化したいのか」「どの判断を支援したいのか」を業務の言葉で示す
• 成功の定義: 「どうなれば導入する価値があるか」を、ざっくりでもよいので合意の土台として示す
• 使えるデータの当て: 「どんなデータが、どのくらいの量・品質で手元にあるか」を共有する

これらは技術的な記述ではなく、業務を一番よく知る発注者にしか書けない情報です。仕様を固めきれない自分を準備不足だと引け目に感じる必要はありません。AIでは、探索を前提に課題とデータを共有することがむしろ正しい準備の仕方です。

要件の中身の書き方は別記事で

なお、PoCを経て本開発に進む段階では、精度要件・学習データ要件・ハルシネーション対策などを要件定義書に落とし込む作業が発生します。この「要件定義書に何をどう書くか」についてはAI開発の要件定義の書き方で詳しく解説しているため、本記事では割愛し、外注プロセスの違いに話を進めます。

違い②｜契約は「請負」か「準委任」かを工程ごとに見極める

2つ目の違いは契約形態です。通常開発では「請負契約」が一般的ですが、AI開発、とくにPoCの段階では「準委任契約」のほうが親和的です。ここを理解しておかないと、ベンダー側が受けられなかったり、見積もりが不必要に高くなったりします。

請負と準委任の違い

両者の違いは、ひとことで言えば「完成を約束するかどうか」です。

• 請負契約: 受託者が成果物の完成を約束する契約。完成しなければ報酬は発生せず、契約不適合（いわゆる瑕疵）があれば修補などの責任を負う
• 準委任契約: 一定の業務を誠実に遂行することを約束する契約。特定の成果物の完成までは約束しないが、専門家として注意を尽くす義務（善管注意義務）を負う

AI開発で準委任が選ばれる理由

AIは、前述のとおり「狙った精度のモデルができるか事前に保証できない」性質があります。にもかかわらず請負契約で「完成」を約束させようとすると、ベンダーは保証できないリスクを抱え込むことになり、受注を断るか、リスク分を上乗せした高額な見積もりを出すしかありません。経済産業省のガイドラインや特許庁のAIモデル契約書が、検証段階に準委任型を想定しているのはこのためです。

準委任には、業務時間に応じて報酬を支払う「履行割合型」と、成果物の提出を要件とする「成果完成型」があります。検証段階では履行割合型、本開発で一定の成果物（学習済みモデルや報告書）を求める段階では成果完成型、といった使い分けが現実的です。「完成保証＝安心」という思い込みを手放すことが、むしろ良い発注につながります。

PoCと本開発で契約を分ける

実務上は、PoCと本開発で契約を分けるのが安全です。PoCは準委任（実現可能性の検証）、本開発はその結果を踏まえて準委任（成果完成型）または請負を選ぶ、という流れです。PoCの結果が芳しくなければ本開発に進まない判断もでき、発注者にとってのリスクコントロールになります。

違い③｜「精度○%保証」を求めない——検収基準を事前に合意する

3つ目は検収です。通常開発では「仕様どおり動くか」で検収できますが、AIでは「精度○%を保証してください」と契約に書くのは現実的ではありません。検収で揉めないためには、発注前に検収基準を合意しておくことが何より重要です。

なぜ「精度○%保証」は書けないのか

AIの精度は、入力されるデータの質や、運用時に出会う未知のデータによって変動します。テスト時に95%だった精度が、本番の現実データでは下がることも珍しくありません。そのため「常に○%以上」という絶対値を保証することは技術的に困難で、無理に保証を求めると、違い②で述べたとおりベンダーが受けられない・高額化するという問題に跳ね返ります。

評価データ・評価指標・許容水準を発注前に合意する

「精度を保証できない」のであれば、何をもって検収するのか。鍵は、次の3点を発注前に合意しておくことです。

• 評価データ: どのデータセットで性能を測るか（本番に近い、合意済みのデータを使う）
• 評価指標: 何を「良し」とするか（正解率・適合率・再現率など、業務目的に合った指標を選ぶ）
• 許容水準: そのデータ・指標で「どの水準なら合格とするか」

この3点を事前に紙に落とし、両者で署名できる状態にしておけば、検収段階で「思っていたのと違う」という水掛け論を避けられます。AI開発の検収は「完成したか」ではなく「合意した評価条件を満たしたか」で判断する、と捉えると整理しやすくなります。

生成AIの場合は「許容範囲」で整理する

文章生成や要約のような生成AIの活用では、「正解率」という単一の数値がそもそもなじまないことがあります。この場合は、「明らかに誤った出力をどの程度まで許容するか」「不適切な出力をどうフィルタするか」といった、許容範囲と運用ルールの形で検収条件を整理します。完璧な出力を100%求めるのではなく、人によるチェックや修正を前提に、どこまでをシステムに任せるかを発注前に握っておくことがポイントです。

違い④｜学習データと成果物の権利・知財の線引きを最初に決める

4つ目は知財です。通常開発では、ソースコードという成果物の帰属を決めれば済みました。ところがAIでは、関わる権利の対象が一気に多層になります。

AI開発で権利が多層になる理由

AI開発では、少なくとも次のような要素が登場し、それぞれ「誰のものか」を決める必要があります。

• 発注者が提供するデータ（業務データ・顧客データなど）
• 学習済みモデル（提供データを使って訓練した結果のモデル）
• ベンダーが汎用的に持つ基盤モデルやノウハウ（他案件でも使う共通技術）
• 開発の過程で得られた改善知見（派生的に生まれるノウハウ）

経済産業省のガイドラインや特許庁のモデル契約は、これらについて「権利の帰属」と「利用条件」を分けて整理することを推奨しています（AI・データの利用に関する契約ガイドライン）。帰属論争で交渉が止まるより、「誰が、どの範囲で使えるか」という利用条件で実利を確保するほうが、現実的だからです。

発注者が渡すデータの扱い

発注者として特に注意したいのが、自社から渡すデータの扱いです。最低限、次の3点を契約で確認しておきます。

• 著作権・利用範囲: 渡したデータを、本案件以外の目的（ベンダーの他案件の学習など）に使われないか
• 個人情報: 個人情報を含む場合、利用目的・委託の範囲が適切か。匿名加工やマスキングが必要か
• 開発後のデータ削除・返却: 開発が終わったあと、提供データをどう削除・返却するか

これらを口頭の合意で済ませると、後から「他案件にも使われていた」といったトラブルになりかねません。データを渡す前に書面で握ることが、社内データを安心して提供する前提になります。

「全部帰属」を求めない——現実的な線引き

発注者としては「お金を払うのだから、できたものは全部こちらに帰属させたい」と考えがちです。しかし、ベンダーが汎用的に持つ基盤モデルやノウハウまで「全部こちらに帰属」と要求すると、ベンダーは事業を続けられなくなるため受けられません。結果として受注先が見つからない、あるいは高額化します。

現実的な落としどころは、「発注者が提供したデータと、それを使って作った学習済みモデルは発注者側」「ベンダーが汎用的に持つ技術・基盤はベンダー側」「派生ノウハウは利用条件で調整」という線引きです。所有にこだわるより、自社が使いたい範囲を確実に使える利用条件を確保するほうが、発注者の実利にかないます。

違い⑤｜外部チームと「密に連携」しすぎると偽装請負になる

最後の違いは体制です。AI開発は探索的に進むため、発注者と外部チームのやりとりが頻繁になりがちです。ところが、フリーランスや外部チームに発注者が直接「今日はこの作業をして」と指示すると、偽装請負（実態は労働者派遣とみなされる状態）のリスクが生じます。これは外部人材を活用するうえで、見落とされやすい落とし穴です。

なぜAI開発の外注で偽装請負リスクが上がるのか

業務委託・請負では、「受託者が自ら自分の労働者を指揮命令する」ことが適法性の前提です。発注者が外部の個人に直接、作業内容や進め方を指示すると、対等な委託関係ではなく実質的な指揮命令関係とみなされ、違法な労働者供給と評価されるおそれがあります。

AI開発は仕様を固めきれず探索的に進むため、発注者が「もっとこうして」「次はこの方向で」と細かく口を出したくなる場面が増えます。アジャイル型・探索型ほどこの傾向が強いため、厚生労働省は2021年に37号告示に関する疑義応答集（第3集）【アジャイル型開発と契約方式】でアジャイル開発の論点を整理しています。AI開発でも同じ注意が必要です。

発注者がやってよい関与・避けるべき関与の線引き

では、どこまでが許容され、どこからが危ういのでしょうか。基本は「成果・期限は伝えてよいが、達成方法と個人への作業指示は受託者に委ねる」です。

この線引きの実務的な詳細は、業務委託で適法な指揮命令の範囲とは？で具体的なOK/NGパターンとともに整理しているので、あわせて参照してください。

窓口・体制の組み方

リスクを避けつつ密に連携するコツは、「受注者側の責任者を窓口にする」ことです。発注者が個々のメンバーに直接指示するのではなく、受注者側のリーダーやプロジェクト責任者に要望を伝え、メンバーへの作業配分はその責任者が行う、という体制にします。Workee などで個人やフリーランスに発注する場合も、誰が窓口で、誰が作業判断の責任を持つのかを最初に明確にしておくことで、探索的なやりとりと法的な安全性を両立できます。

AIシステム開発を外部チームに発注する前のチェックリスト

ここまでの5つの違いを、発注前の確認項目としてまとめます。通常開発のチェックリストに「追加・変更すべき項目」だけを挙げているので、これまでの外注経験と組み合わせて使ってください。

要件・契約・検収のチェック項目（通常開発からの差分）

• いきなり本開発でなく、まずPoC（検証）から始める計画になっているか
• 発注者として「業務課題・成功の定義・使えるデータの当て」を言語化できているか
• 契約形態を工程ごとに見極めたか（PoC＝準委任、本開発＝準委任/請負）
• 「精度○%保証」を求めていないか。代わりに評価データ・評価指標・許容水準を事前合意したか
• 生成AIの場合、「許容範囲」と運用ルールで検収条件を整理したか

知財・体制のチェック項目

• 渡すデータの利用範囲・個人情報の扱い・開発後の削除返却を書面で確認したか
• 「全部帰属」を求めず、自社が使いたい範囲の利用条件を確保したか
• 発注者が個人に直接作業指示しない体制（受注者側の責任者を窓口）になっているか

最初の打ち合わせで聞くべき質問

外部チームとの初回打ち合わせでは、次のような質問が、相手の力量を見極めつつトラブルを予防する材料になります。

• 「この課題は、まずPoCで実現可能性を確かめる進め方で問題ないですか」
• 「PoCと本開発で、契約形態はどう分けるのが妥当だと思いますか」
• 「検収では、どの評価データ・指標・水準で合格を判断するのがよいでしょうか」
• 「弊社が提供するデータと、できあがるモデルの権利・利用条件はどう整理しますか」
• 「日々の連携は、どなたを窓口にしてどう進めるのがよいですか」

まとめ｜「違いは5点」と分かれば外部発注は怖くない

AIシステム開発の要件定義を外部チームに発注するとき、通常のシステム開発の外注と変わるのは、次の5つの勘所でした。

1. 要件の渡し方: 固めきるより、PoCで探索しながら絞る前提で渡す
2. 契約形態: 完成を約束する請負より、工程ごとに準委任を見極める
3. 検収基準: 「精度○%保証」ではなく、評価データ・指標・許容水準を事前合意する
4. 知財の線引き: 「全部帰属」を求めず、データ・モデル・ノウハウの利用条件を整理する
5. 体制: 個人への直接指示を避け、受注者側の責任者を窓口に密な連携を両立する

いずれも、難しい技術知識を要するものではなく、発注前の合意で予防できることばかりです。そして共通しているのは、AIが「やってみないと分からない」性質を持つことから生まれている違いだという点です。この前提さえ腹に落ちれば、5つの違いは自然に理解できます。

通常のシステム開発で培った外注の経験は、AI案件でも決して無駄になりません。むしろ土台として活きます。変えるべきは、ここで挙げた5点の差分だけです。発注前にこの5つを確認し、最初の打ち合わせで的確な質問ができれば、外部チームへのAI発注は十分にコントロールできる範囲に収まります。「同じ感覚で大丈夫か」という最初の不安は、「違いは5点、すべて発注前に予防できる」という見通しに置き換えていただけるはずです。