ここ1〜2年、開発会社からの提案書に「AIを活用して短納期・低コストで構築します」という一文が入るようになりました。発注側としては歓迎したい話ですが、同時に判断が難しくなっています。提示された納期と金額が妥当なのか、比較する基準がないからです。

従来であれば、人月単価と工数の掛け算で見積もりの妥当性をある程度は検証できました。AIを使うと言われた瞬間、その検証の前提が崩れます。工数が半分になるのか、10分の1になるのか、それとも実は変わらないのか。ベンダーごとに主張が違い、根拠も示されないことが少なくありません。

本記事では、AIを使った受託開発（本記事では「AI受託構築」と呼びます）によって、発注側の実務が具体的に何から何へ変わるのかを7点に整理します。技術の解説ではなく、見積り・契約・検収という発注実務の話が中心です。

費用構造の全体像は「AIアプリ開発の進め方・費用・会社選び」、外注そのものの失敗構造は「システム開発の外注が失敗する7つの理由」で扱っています。

「AI受託構築」とは何を指しているのか？

発注側から見ると3つのパターンがある

この言葉は明確に定義されておらず、ベンダーによって指すものが異なります。提案を受けたら、まずどのパターンなのかを確認してください。費用や納期への影響が大きく異なります。

第一は、開発者がAIコーディング支援を使うパターンです。従来どおりエンジニアが設計し、コードを書く速度だけがAIで上がります。成果物も工程も従来と同じで、変わるのは生産性です。

第二は、AIアプリビルダーで構築するパターンです。自然言語からアプリを生成するツールを使い、画面やデータ構造を短時間で組み上げます。生成されるのは実際のコードで、リポジトリに同期できます。第一のパターンより工程そのものが変わります。

第三は、納品物にAI機能が含まれるパターンです。作り方ではなく、作るものの話です。チャットボットや文書要約など、AIを呼び出す機能を実装します。この場合は運用時にAPI利用料が継続的に発生するため、費用構造がまったく異なります。

提案書に「AI活用」とだけ書かれている場合、この3つのどれなのか、あるいは複数の組み合わせなのかを最初に確認してください。第三のパターンを見落とすと、稼働後に想定外の運用費が発生します。

変化①：見積りの根拠が「工数」から「要件の明確さ」に移る

従来の見積もりは、機能数と工数と人月単価の積み上げで説明されました。この構造では、機能を削れば費用が下がるという関係が明確でした。

AI受託構築では、実装にかかる時間の比重が下がります。相対的に大きくなるのが、要件を確定させる工程と、生成されたものを検証する工程です。結果として、費用を左右する最大の変数が「要件がどれだけ明確か」に移ります。

実務上の意味はこうです。曖昧な要件のまま発注すると、実装が速くなったぶん「違うものが速く出てくる」だけになります。手戻りの回数が増え、結局は従来と同じかそれ以上の期間がかかります。見積もりを比較する際は、金額の内訳で要件定義工程がどれだけ確保されているかを見てください。ここが極端に薄い見積もりは、後から膨らみます。

変化②：短納期の提案が増えるが、短いのは実装工程だけ

「従来3か月の案件を1か月で」という提案を受けることが増えました。この数字自体は誇張とは限りません。ただし短縮されているのは工程の一部です。

下の表は、AI活用によって短縮される工程とされない工程を整理したものです。短縮されない工程が全体の期間を決めるという点が、発注側にとって重要な示唆になります。

提案された納期が妥当かを確認するには、工程別の内訳を出してもらうのが最も確実です。全体で1か月という数字だけでは検証できません。要件定義に何週間、実装に何週間と分けて提示されていれば、自社の意思決定速度と照らして現実性を判断できます。

変化③：プロトタイプが「捨てるもの」から「本番の出発点」に変わる

従来、提案段階のモックアップやプロトタイプは、確認用に作られて捨てられるものでした。本番開発は改めてゼロから始まるため、プロトタイプに時間をかけることは無駄と見なされていました。

AIアプリビルダーで構築する場合、生成されるのは実際に動作するコードです。したがってプロトタイプをそのまま拡張して本番にできる可能性があります。発注側にとっての意味は、「作る前に動くものを見て判断できる」ことです。仕様書の読み合わせで認識を揃えるより、はるかに確実に齟齬を潰せます。

ただし前提があります。プロトタイプの段階で品質を落としていると、そのまま本番化した際に不具合の温床になります。「動くものを見せてもらう」ことと「それが本番品質である」ことは別です。提案段階のデモを見て判断する際は、それが本番のコードベースになるのか、それとも見せるためだけのものなのかを確認してください。

変化④：ソースコードの受け取り方が現実的な論点になる

従来もソースコードの著作権は契約の論点でしたが、実務では「もらっても読めない、動かせない」ため形式的な条項になりがちでした。

現在の主要なAIアプリビルダーは、生成したコードをGitHubなどのリポジトリに同期できます。つまり発注側がコードを保有し、別のベンダーや自社で継続開発できる可能性が現実的になりました。ベンダーロックインの度合いが下がるという意味で、発注側に有利な変化です。

この利点を確保するために、契約で確認すべき点があります。コードの著作権と利用範囲、リポジトリの所有者、開発中からアクセスできるか、そして使用しているツールのアカウントが誰の名義かです。ツールのアカウントがベンダー名義のままだと、契約終了時にプロジェクトごと引き上げられる可能性があります。ここは従来の受託開発にはなかった新しい論点です。

変化⑤：品質のばらつきが「人」ではなく「指示」に依存する

従来、成果物の品質はアサインされる技術者の経験に大きく左右されました。だからこそ発注側は体制図と要員の経歴を確認しました。

AI活用が進むと、この構図が変わります。生成されるコードの品質は、AIへの指示の粒度と、生成物をレビューする体制に依存するようになります。経験の浅い担当者でも一定水準のものが出てくる一方、レビューが甘いと問題のあるコードがそのまま納品されます。

とくに注意が必要なのが、権限設計とアクセス制御です。データベースのアクセス制御の設定漏れは、設定していなくてもアプリが正常に動作するため、通常のテストでは発見できません。発注側としては、「誰がどうレビューするのか」を体制の確認項目に加えてください。要員の経歴だけを見ていると、この観点が抜け落ちます。点検の具体的な手順はノーコード開発のセキュリティで扱っています。

変化⑥：AI利用の可否と著作権が契約の論点になる

従来の受託開発契約には存在しなかった論点です。ここは法務部門との連携が必要になります。

まず確認すべきは、自社が提供する情報がAIの学習に使われないかです。要件定義書、業務フロー、実データのサンプルなどをベンダーがAIツールに入力する場合、その入力内容の扱いがツールの契約条件に依存します。主要なツールは上位プランで学習除外に対応していますが、どのプランを使っているかはベンダー側の事情です。契約書に「入力情報を学習に使用しないこと」を明記するのが安全です。

次に、生成物の権利関係です。AIが生成したコードや画像の著作権については、文化庁が「AIと著作権について」として考え方を公表しており、令和6年7月にはチェックリスト＆ガイダンスも公開されています。経済産業省もコンテンツ制作のための生成AI利活用ガイドブックを公開しています。

本記事で法的な結論を述べることはしません。個別の事案によって判断が分かれる領域であり、実務としては上記の公的資料を踏まえたうえで、契約条項を法務部門または専門家に確認してもらうのが適切です。発注側として押さえるべきは、「この論点が存在すること」と「契約書に何も書かれていない状態は避けるべきこと」の2点です。

変化⑦：検収基準を発注側が定義する必要性が上がる

実装が速くなると、発注側が検証に使える時間は相対的に短くなります。3か月かけて作られたものを1か月で確認するのと、1か月で作られたものを1か月で確認するのとでは、負担がまったく違います。

加えて、生成されたコードは「一見すると正しく動く」状態に到達しやすいという特性があります。画面は表示され、ボタンは反応し、データも保存される。しかし例外的な入力で壊れる、他人のデータが見えてしまう、といった問題は表面的な操作では発見できません。

したがって検収基準を、動作確認より一段踏み込んだ形で定義する必要があります。以下は、AI受託構築の案件で明示しておくべき項目です。いずれも契約前に決めておかないと、後から追加を求めるのが難しくなります。

最後の行は、納品物ではありませんが検収時に確認すべき項目です。AI機能を含むシステムは利用が増えるほど費用が増える構造を持ちます。稼働後に想定を超えないよう、試算の前提を書面で受け取っておいてください。

結局、費用は安くなるのか？

発注側が最も知りたい点ですが、単純に安くなるとは言えません。安くなる部分と、変わらない部分と、新たに増える部分があるためです。

安くなるのは実装工程の費用です。一方、要件定義とテストの工数は大きく変わりません。そして新たに増えるのが、AI機能を含む場合の運用費と、生成物のレビュー工数です。総額としては、小規模で要件が明確な案件ほど下がりやすく、大規模で要件が固まっていない案件では効果が限定的になります。

したがって「AIを使うので安い」という提案を受けたときは、どの工程がどれだけ安くなるのかを内訳で確認してください。実装工数の削減だけを根拠にしている場合、運用費と統制コストは減りません。総額では変わらない、あるいは増えることもあります。

なお、要件が固まっていない案件を成果物の完成を約束する契約で発注すると、変更のたびに手続きが必要になり費用が膨らみます。IPAの「情報システム・モデル取引・契約書」でも工程の性質に応じた契約形態の使い分けが示されており、この点はAIの有無にかかわらず変わりません。

発注前にベンダーへ確認すべき質問

最後に、提案を受けた段階で確認しておくべき質問をまとめます。いずれも回答を求めること自体が難しくない内容ですが、明確に答えられるかどうかで、そのベンダーの実務経験の深さが判別できます。

とくに5番と6番は、従来の受託開発では存在しなかった質問です。ここに明確に答えられないベンダーは、契約終了時の引き継ぎを想定していない可能性があります。

よくある質問（FAQ）

Q1. 見積もりの妥当性はどう判断すればよいですか？

金額の内訳で要件定義工程がどれだけ確保されているかを見てください。AI活用では費用を左右する最大の変数が「要件の明確さ」に移るため、ここが極端に薄い見積もりは後から膨らみます。

Q2. 提供した情報がAIの学習に使われないか心配です。

主要なツールは上位プランで学習除外に対応していますが、どのプランを使うかはベンダー側の事情です。契約書に「入力情報を学習に使用しないこと」を明記するのが安全です。ベンダーに使用ツールとプランを確認してください。

Q3. AIが生成したコードの著作権はどうなりますか？

個別の事案によって判断が分かれる領域のため、本記事では法的な結論を述べません。文化庁が「AIと著作権について」として考え方を公表し、チェックリスト＆ガイダンスも公開しています。これらを踏まえたうえで、契約条項を法務部門または専門家に確認してください。重要なのは、契約書に何も書かれていない状態を避けることです。

Q4. ソースコードは必ず受け取れますか？

契約次第です。技術的には可能でも、契約で定めていなければ受け取れません。コードの著作権と利用範囲、リポジトリの所有者、開発中からのアクセス可否を契約前に確認してください。

Q5. ツールのアカウント名義はなぜ重要なのですか？

ベンダー名義のままだと、契約終了時にプロジェクトごと引き上げられる可能性があるためです。従来の受託開発にはなかった新しい論点で、明確に答えられないベンダーは引き継ぎを想定していない可能性があります。

Q6. プロトタイプを見て判断してよいですか？

有効な判断材料ですが、そのプロトタイプが本番のコードベースになるのか、見せるためだけのものなのかを確認してください。前者なら仕様書の読み合わせより確実に認識を揃えられますが、後者の場合は本番開発が別途必要になります。

Q7. 契約形態はどうすればよいですか？

AIの有無にかかわらず、要件が固まっていない案件を成果物の完成を約束する契約で発注すると費用が膨らみます。IPAの「情報システム・モデル取引・契約書」でも工程の性質に応じた使い分けが示されています。要件定義は準委任、構築は請負という二段構えが実務的です。

本記事で参照した公的資料は、文化庁「AIと著作権について」および同チェックリスト＆ガイダンス、経済産業省「コンテンツ制作のための生成AI利活用ガイドブック」、IPA「情報システム・モデル取引・契約書」です。本記事は発注実務の一般的な整理であり、著作権その他の法的判断を提供するものではありません。契約条項の検討にあたっては法務部門または専門家にご相談ください。