AI駆動開発の外注で確認する7項目【2026年版】品質管理・権利・機密情報と見積もりの読み方

「提案書に『AI駆動開発で工数を削減します』と書いてあるが、何を確認すればよいのか」——2026年に入ってから、こうしたご相談をよく受けます。1社だけ見積もりが明らかに安い、AIが書いたコードを納品されて後で困らないか、自社の仕様書がAIの学習に使われないか。判断材料がないまま稟議を通すのは、さすがに気が進まないものです。

結論から言うと、発注者が見るべきは「AIを使っているかどうか」ではなく、「AIの出力を誰がどの単位で検証しているか」です。AIによって実装の速度は確かに上がります。しかし、そのぶん要件定義・設計・レビュー・テスト・品質保証の比重が上がります。工数が機械的に減るのではなく、人の時間が実装から設計と検証へ移る——これが2026年時点の一般的な整理です。

この視点を持つと、確認すべきことが7項目に整理できます。AIの使用範囲の開示、レビュー体制、テスト、OSSライセンスの検出、機密情報の扱い、成果物の権利、保守のためのドキュメントと引き渡しです。そして見積もりは、実装工程だけが縮む前提で、工程別に分解して読むことになります。

本記事では、AI駆動開発を外注すると何が変わり何が変わらないのか、発注前に確認する7項目、見積もりと単価の読み方、当社のAI活用開発体制と向く案件・向かない案件、よくある質問の順に解説します。確認7項目は、提案依頼書や質問リストにそのまま転記できる形の表にしました。なお、ここで扱うのは「開発プロセスにAIを使うこと」であり、AIプロダクトそのものを作る話ではありません。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。当社自身も生成AIとAIコーディング支援を標準で使うAI活用開発体制に移行しており、そのうえでAIの出力は人が3つの関門で確認しています。この記事を読み終えるころには、目の前の提案書をどの順番で検証すればよいかが見えているはずです。

AI駆動開発を外注すると何が変わり、何が変わらないのか——実装は速くなり、要件定義とレビューの比重が上がる

AI駆動開発とは、生成AIやAIコーディング支援を開発プロセスに組み込み、コードの生成・修正・テストの一部をAIに任せる開発の進め方を指します。2026年に入って、コードを部分的に補完する段階から、指示を受けて複数ファイルを修正しテストまで走らせるエージェント型へと使われ方が広がりました。外注先がこの進め方を採用したとき、発注者の側では何が変わり、何が変わらないのか。ここを整理しないまま提案書を比べても、金額の差の意味が読み取れません。

まず用語を切り分ける——「AI駆動開発」は作り方、「AI開発」は作るもの

相談の場で最初に食い違うのが用語です。「AI駆動開発」は開発の進め方、つまり作り方の話です。対して「AI開発」は、チャットボットや需要予測のようにAIを組み込んだプロダクトを作る話で、作るものを指します。両者は独立していて、AIを使わない業務システムをAI駆動開発で作ることも、AIプロダクトを従来型の進め方で作ることもあります。

本記事は前者、つまり作り方に絞って整理します。AIプロダクトそのものを外注する場合の進め方や受け入れ基準については「AI開発 外注」の記事、エージェント型のシステムを作る場合は「AIエージェント 開発会社」の記事をご覧ください。この切り分けを社内で共有しておくと、提案書を読む際の混乱がひとつ減ります。

工程別の役割分担(表)——AIが担える作業、人が判断する作業、外注先に残る責任

AI駆動開発で何がどう変わるかは、工程ごとに見ると具体的になります。以下は、当社がAI活用開発体制で実際に運用している工程別の役割分担を整理したものです。

表のとおり、AIが入ることで手が速くなるのは主に実装とテストの作成です。一方、判断の欄はほとんど変わっていません。AIは指示された内容に驚くほど速く答えを出しますが、「その要件で本当に業務課題が解けるのか」「この設計が5年後の変化に耐えるか」というビジネス上の判断はできません。当社が案件を進めるうえでも、ここは人が担う前提で体制を組んでいます。

変わること3つ——実装の速度、試作の回転、ボトルネックが意思決定に移る

変わることは3つに集約できます。1つ目は実装の速度です。これまで数日かかった基本的な機能実装が数時間で終わることがあり、公開されているベトナムのオフショア開発の事例でも、作業効率25〜30%向上・開発工数20〜25%削減という数値が示されています(当社原稿「オフショア開発 AI」で確認済み)。

2つ目は試作の回転です。数か月待って完成品を見るのではなく、数日ごとに動く画面を見てフィードバックする進め方が現実的になります。3つ目が見落とされがちですが最も重要で、プロジェクトの最大のボトルネックが「エンジニアの実装力」から「発注者側の意思決定」へ移ります。昨日出した要望が今日動くプロトタイプになって戻ってくる状況で、「社内で持ち帰って2週間検討します」という速度のままだと、速くなったはずのサイクルが止まります。AI駆動開発の外注では、即断できる権限を持った担当者を置けるかどうかが成否を分ける、というのが実情です。

変わらないこと4つ——何を作るかの決定、設計、品質保証の責任、運用

一方、変わらないことも4つあります。第1に「何を作るか」の決定です。これは発注者の仕事で、AIにも開発会社にも代わりはできません。第2に設計の妥当性の判断で、既存システムとの整合や将来の拡張性は人が引き受けます。第3に品質保証の責任です。生成されたコードに脆弱性がないか、既存機能と競合しないかという検証には、依然として専門知識が要ります。第4に運用で、リリース後の監視・障害対応・改修は残ります。

むしろ比重が上がる領域があります。生成されるコードの量が増えるほど、レビューとテストにかかる負荷は相対的に増えます。要件定義も、AIに渡す前提が曖昧だと曖昧なものが速く大量に出てくるだけなので、精度への要求が上がります。「AIが書くので人は要らない」という理解のまま発注するのは、失敗のもとです。次章では、この構造を踏まえて、発注前に確認すべき7項目を整理します。

AI駆動開発を外注する前に確認する7項目——生成コードの品質管理から権利・機密情報まで

ここからが本記事の中心です。AI駆動開発を採用する会社に外注するとき、従来の受託開発の確認項目に加えて見るべきことが7つあります。品質を守るための2つ、権利を守るための2つ、情報と保守を守るための3つです。既存の提案依頼書やセキュリティチェックシートはAI利用を想定して作られていないことが多いので、この7項目を質問リストとして足してください。

確認7項目の一覧表(何を聞くか・望ましい答え・NGの兆候)

この7項目は、IT COMPASSが整理しているAI駆動開発の知財4論点(生成コードの著作権・学習データのライセンス・ベンダー側の権利主張・顧客との契約条項)と社内ポリシー6項目を、発注者の立場から並べ替えたものです。以下、系統ごとに補足します。

①〜②品質管理: レビュー体制とテスト——プルリクエスト単位で誰が見るか、テストをどこまで書くか

品質に関する質問は、「AIを使っていますか」ではなく「AIの出力を誰がどの単位で検証していますか」と聞いてください。この聞き方に変えるだけで、会社の差がはっきり出ます。プルリクエスト単位で人のレビューを必須にし、承認者が決まっている会社と、「動いたので大丈夫」で進む会社では、半年後の保守コストがまるで違います。

テストについては、2点を確認します。1つは、AIが生成したコードにも単体テストを書くルールがあるか。もう1つは、合格の基準を誰が決めるかです。テストカバレッジの数字は分かりやすい指標ですが、カバレッジが高いことと、業務上重要な条件が検証されていることは別です。数字だけを強調する会社には、「どの業務シナリオを、どのテストで担保していますか」と重ねて聞いてみてください。

もう一点、レビューの負荷が現実的かどうかも見ておく価値があります。生成量が増えれば、レビューする側の時間も増えます。実装だけが速くなり、レビューが追いつかずに滞留する——AI駆動開発でつまずく典型がこれです。体制の人数配分で、レビューを担う上位のエンジニアが確保されているかを確認してください。

③〜④権利: OSSライセンスの混入検出と、成果物の著作権・表明保証の現実的な範囲

権利は、従来の受託開発にはなかった論点です。大規模言語モデルの学習データにはOSSのコードが含まれる可能性があり、出力が既存コードに類似する場合があり得ます。混入したライセンスの種類によっては、派生物の扱いや帰属表示の義務が問題になります。そのため、コードの類似性検出やライセンス検査を、継続的な検査工程として組み込んでいるかを確認します。「生成AIの出力だから問題ない」と即答する会社は、この論点を検討していないと考えたほうがよいでしょう。

著作権については、2026年時点で「AIが書いたから自社のもの」とは言い切れない、という整理が一般的です。文化庁「AIと著作権に関する考え方について」(令和6年3月15日・文化審議会著作権分科会法制度小委員会)は、AI生成物が著作物に当たるかは著作権法第2条第1項第1号の「思想又は感情を創作的に表現したもの」という定義に該当するかで判断され、AIは法的人格を有しないため著作者にはならず、AIを利用して著作物を創作した人が著作者になるとしています。著作物性は個々の生成物ごとに、人間の創作的寄与がどの程度積み重なっているかを総合的に考慮して判断され、指示が表現に至らないアイデアにとどまる場合や、単に試行回数を重ねただけ・生成物を選んだだけの場合は創作的寄与とは評価されない一方、人間が創作的表現といえる加筆・修正を加えた部分には通常著作物性が認められる、と整理されています。実務としては、人間の関与を記録に残す運用と、契約で帰属と利用権を明確にする対応の二段構えになります。詳しくは「システム開発 知財 帰属」の記事で契約条項の考え方を整理していますので、あわせてご覧ください。

表明保証については、現実的な範囲で合意することが大切です。第三者の権利を一切侵害していないと完全に保証することは、AI利用の有無にかかわらず難しいのが実情です。「すべて保証します」と即答する会社よりも、侵害が判明した場合の対応手順と責任範囲を一緒に決めようとする会社のほうが、結果として安全です。なお、ここでの記述は一般的な整理であり、個別案件の判断は自社の法務部門や弁護士にご相談ください。

⑤〜⑦情報と保守: 学習に使われない設定、入力禁止データ、ドキュメントと引き渡し

機密情報は、多くの発注者が最も気にする点です。確認するのは3つ。使用しているサービスが、入力データを学習に使わない条件で契約されているか。法人向け・API利用のプランでは学習に使わない規約が一般的になっていますが、個人向けの無料プランは学習に使われ得る規約のことがあります。次に、入力してはいけないデータ(顧客の個人情報、他社から預かった資料、認証情報)が文書で定義され、開発者に周知されているか。最後に、誰がいつ何を生成したかの記録が残るか。オフショアで開発する場合の情報管理全般は「オフショア開発 セキュリティ」の記事で詳しく扱っています。

保守性は、短期では見えにくく後から効いてくる項目です。速く作れる分、設計意図が残らないまま量が増えると、1年後に誰も直せないコードになります。設計書・テスト・コード規約が整備されるか、契約終了時にソースコードとドキュメント一式を引き渡してもらえるかを、契約前に確認してください。ここを確認せずに「動くものができた」で満足すると、次の改修で余計な費用を払うことになります。

7項目の確認は、面談1回で終わる分量です。それをやらずに金額だけで比べるのは、要注意です。次章では、その金額——見積もりと単価をどう読むかに進みます。

見積もりと単価はどう読むか——人月の前提が崩れる場所と、崩れない場所

AI駆動開発の話で最も議論になるのが費用です。「AIで生産性が上がったなら、その分安くなるはずだ」という発注者側の期待と、「生産性を上げた側が損をするのはおかしい」という開発会社側の主張が、正面からぶつかります。どちらにも理があり、2026年時点では業界としての答えは出ていません。ここでは、発注者が見積もりを読むための材料を整理します。

生産性を単価に反映するか(表)——3つの考え方と、発注側にとっての損得

現在、開発会社の提案は大きく3つの考え方に分かれます。

単価を据え置いて工数を減らす会社もあれば、AIを使いこなす技術力に見合って単価を上げるかわりに工数を大きく減らす会社もあります。そのため、単価表だけを横並びにして安い会社を選ぶ比較は、AI駆動開発の時代には成立しにくくなります。比べるべきは、同じ範囲・同じ品質基準での総額と期間です。人月単価という単位そのものの考え方は「人月単価」の記事で整理していますので、社内説明の前にご一読ください。

崩れるのは実装工程だけ——見積もりを工程別に分解して聞く

もう一段、実務的な話をします。人月見積もりの前提が崩れるのは、主に実装工程です。要件定義、設計、テストの設計と実施、プロジェクト管理、リリース準備といった工程の工数は、AIによって多少は効率化されても、実装ほどは縮みません。むしろ前章で述べたとおり、レビューとテストの比重は上がります。

ですから、安い見積もりを受け取ったときの質問はひとつです。「どの工程が、従来と比べてどれだけ減っているのか」。私がこれまでに見てきた範囲では、安い見積もりは2種類に分かれます。実装工程だけが縮んでいて、要件定義・設計・レビュー・テストの工数は据え置きになっている見積もりと、全工程を一律に何割か削っている見積もりです。前者は根拠がありますが、後者はレビューやテストの工数まで削っている可能性が高く、リリース後に不具合対応という形で費用が戻ってきます。見積もりの内訳をどう読むかは「見積もり内訳」の記事で詳しく扱っています。

「AI駆動開発なら安くなる」という相場表の読み方——前提条件を揃えないと比較できない

各社が公開している相場表には、AI駆動開発なら従来型の開発より費用が抑えられる、とする整理が見られます。ただし、これらは各社が独自に集計した数値で、対応する公的な一次統計は存在しません。読むときに2つ注意が要ります。

1つは、比較されている「従来の開発」の範囲が明示されていないことです。要件定義やデザインが別途となっている場合、総額は変わってきます。もう1つは、保守・運用の前提です。速く作れても、ドキュメントが薄く保守しにくい成果物であれば、2年目以降の費用が膨らみます。相場表は「そういう提案をする会社が市場に存在する」という程度の参考にとどめ、自社の要件で相見積もりを取ったうえで、範囲と品質基準を揃えて比べてください。

新しい費目——AIツールのライセンス費用とトークン課金を誰が負担するか

見落とされやすいのが、AIツールの費用です。開発支援ツールの法人向けプランには開発者1人あたりの月額ライセンス費用がかかり、APIを直接使う場合は利用量に応じた従量課金になります。これを開発会社が自社の経費として単価に含めているのか、実費として請求するのかは会社によって分かれます。金額としては人件費に比べれば小さいのですが、「請求段階で初めて出てきた」という揉め方をしやすい費目です。見積もりを受け取ったら、AIツールの費用がどこに入っているかを一度確認しておいてはいかがでしょうか。

当社のAI活用開発体制と、AI駆動開発の外注が向く案件・向かない案件

ここまでの確認項目を、当社自身がどう満たしているかをお伝えします。あわせて、AI駆動開発を前提とした外注が向く案件と向かない案件も、正直に書きます。当社に合わない案件であれば、その旨をお伝えするのが結局は早いためです。

当社の体制——AI活用開発体制と、日本人PMの設計レビュー・Gitプルリクエスト・リリース前ダブルチェック

当社は生成AIとAIコーディング支援を標準で使うAI活用開発体制に移行しています。実装のたたき台、テスト観点の洗い出し、ドキュメントの生成にAIを使い、エンジニアの時間を設計とレビューに寄せる、という使い方です。そのうえで、AIの出力は必ず3つの関門を通します。日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、そしてリリース前のダブルチェックです。前章までの言い方をすれば、当社が示せるのは「AIを使っていること」ではなく「AIの出力を誰がどの単位で検証しているか」のほうです。

体制は2パターンから選べます。推奨のパターンAは日本人PMまたはブリッジSEをフロントに置き、ベトナム人エンジニアと組む形です。パターンBはエンジニアのみで、社内にPMがいる場合に選ばれます。人財は2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から直接アサインするため、協力会社や紹介を経由する仲介マージンが発生しません。クラウド構成と生成AIの組み込みを同じチームで設計できるよう、AWS認定11冠のクラウド・生成AIスペシャリストも在籍しています。

実績としては、介護記録SaaS「CareViewer」を日本語ブリッジSE1名とフルスタックエンジニア2名で、従来の半分以下のコストで継続開発しています。ほかに、LLMを組み込んだコンシューマー向けAIチャットボット(24時間対応)、決済代行APIを統合し二要素認証・ウォレット・取引履歴のPDF出力を備えた決済アプリの新規開発と保守などがあります。

公開単価と最小構成——実務3年1,500USD(約22.5万円)から、日本人PM+2〜3人月で月額約80万円〜

当社は単価を公開しています。実務3年目安のエンジニアが月額1,500USD(1USD=150円換算で約22.5万円)、5年目安が2,000USD、10年目安およびブリッジSEが3,000USDです。当社調べでは市場相場の約半分にあたります。最小構成は、日本人PMをフロントに置いてエンジニア2〜3人月を組む形で、月額約80万円からです。

契約の柔軟性も、AI駆動開発では効いてきます。1名から契約でき、開始は最短2週間、増員は約1週間、縮小と交代は1か月単位です。フローは打ち合わせ→アサイン(約1週間)→候補者面談(約1週間)→開始で、契約と支払いは日本国内法人・日本法準拠のため海外送金は不要です。試作の回転が速くなる分、体制も動かせるほうが噛み合います。ラボ型での進め方そのものは「ラボ型開発」の記事をご覧ください。

向く案件と向かない案件(表)——継続開発とリプレイスは向く、規制の厳しい領域と超小規模は向かない

向かない案件に無理にAI駆動開発の体制を当てても、速度は出ません。当社に相談をいただいた場合も、規制対応が重い案件や超小規模の単発では、その旨をお伝えしています。外注先を選ぶ基準は、結局のところ「速いか」ではなく「速さの後始末ができる体制か」に尽きます。

AI駆動開発の外注に関するよくある質問

AI駆動開発を取り入れた外注について、相談の場で繰り返し聞かれる質問を5つにまとめました。社内の稟議や、開発会社への質問リストにもお使いください。

Q1. AIを使っているなら、人月単価は下がるのですか?

必ずしも下がりません。単価を据え置いて工数を減らす会社、単価を上げて工数を大きく減らす会社、成果や期間で契約する会社に分かれ、2026年時点で業界の標準はありません。比べるべきは単価ではなく、同じ範囲・同じ品質基準での総額と期間です。当社は単価を公開しており、実務3年目安で1,500USD(約22.5万円)です。

Q2. AIが書いたコードで品質は落ちませんか?

生成そのものより、検証の体制で決まります。プルリクエスト単位で人がレビューしているか、生成コードにも単体テストを書くルールがあるか、受け入れ基準を発注者と合意しているかを確認してください。当社は日本人PMの設計レビュー、Gitプルリクエストによるコードレビュー、リリース前のダブルチェックの3つを標準にしています。

Q3. 自社の仕様書やソースコードがAIの学習に使われませんか?

法人向け・API利用のプランでは、入力データを学習に使わない規約が一般的になっています。確認すべきは、外注先がそうしたプランを業務で使っているか、入力してはいけないデータが文書で定義されているか、利用の記録が残るかの3点です。個人向けの無料プランを業務で使っている場合は要注意です。

Q4. AIが生成したコードの著作権は誰のものですか?

一律には決まりません。文化庁「AIと著作権に関する考え方について」(令和6年3月15日)では、AI生成物の著作物性は人間の創作的寄与の有無と程度により個別具体的に判断するとされ、AI自身は法的人格を持たないため著作者にはなりません。指示が表現に至らないアイデアにとどまる場合や、単に試行回数を重ねたり生成物を選んだだけの場合は創作的寄与とは評価されない一方、人間が創作的表現といえる加筆・修正を加えた部分には通常著作物性が認められます。実務としては、権利の帰属と利用権、侵害時の対応を契約条項で明記します。個別の判断は法務部門や弁護士にご確認ください。

Q5. 「AI駆動開発」と「AI開発」は同じものですか?

別のものです。AI駆動開発は開発の進め方、つまり作り方を指し、AI開発はAIを組み込んだプロダクトを作ることを指します。本記事が扱ったのは前者。

まとめ: 見るべきはAIを使うかどうかではなく、AIの出力を誰が検証するか——見積もりは工程別に読む

AI駆動開発を取り入れた会社に外注しても、変わるのは主に実装の速度と試作の回転です。「何を作るか」の決定、設計の妥当性の判断、品質保証の責任、運用は発注者と開発会社に残り、生成量が増えるぶん要件定義・レビュー・テストの比重はむしろ上がります。プロジェクトのボトルネックが実装力から発注者側の意思決定へ移ることも、あわせて押さえておいてください。これが2026年時点の一般的な整理です。

外注前に確認するのは7項目です。AIの使用範囲の開示、レビュー体制、テスト、OSSライセンスの混入検出、成果物の権利と表明保証の範囲、機密情報(学習に使われない条件・入力禁止データ・記録)、保守のためのドキュメントと引き渡し。質問の型をひとつ変えるだけで、会社の差は見えます。「AIを使っていますか」ではなく「AIの出力を誰がどの単位で検証していますか」と聞いてください。見積もりは、どの工程が従来と比べてどれだけ減っているのかを分解して確認します。実装だけが縮んでいるのか、レビューやテストまで削られているのかで、リリース後の負担がまるで違います。

当社は生成AIとAIコーディング支援を標準で使うAI活用開発体制に移行しつつ、AIの出力は日本人PMの設計レビュー、Gitプルリクエストによるコードレビュー、リリース前のダブルチェックで人が確認しています。単価は公開しており、実務3年目安で1,500USD(1USD=150円換算で約22.5万円)、最小構成は日本人PMフロント+2〜3人月の月額約80万円からです。単価という単位そのものの考え方は人月単価の相場、オフショアとAIの関係全体はオフショア開発とAIもあわせてご覧ください。現在の体制と要件をお聞かせいただければ、AI駆動開発を前提とした体制が合うかどうかの判断と概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。