バイブコーディングを外注に使う判断基準｜品質リスクと契約の変化

「AI（バイブコーディング）を活用するので、短納期・低コストで作れます」——外注先の開発会社やフリーランスから、こんな提案を受けたことはありませんか。あるいは、相場よりも極端に安い見積もりが届き、その理由を尋ねたら「AIにコードを生成させているから」だった、というケースもあるかもしれません。

コストとスピードが下がるのは、発注する側にとってありがたい話です。しかしその一方で、「AIが書いたコードの品質やセキュリティは本当に大丈夫なのか」「後で不具合が出たとき、誰が責任を取るのか」「納品されたシステムの権利は、ちゃんと自社のものになるのか」といった不安が頭をよぎるのも自然なことです。

難しいのは、こうした不安の多くが「技術の話」に見えて、実は「契約と判断の話」だという点です。プログラミングの中身までは分からなくても、発注者として確認すべきこと・契約で守るべきことを押さえれば、リスクは十分にコントロールできます。逆に、ここを曖昧にしたまま安さだけで発注してしまうと、後から保守不能なシステムや権利トラブルというツケを払うことになりかねません。

本記事では、バイブコーディングを使う外注に発注してよいかを判断するために、発注者が知っておくべき「品質リスクの所在」「見直すべき契約条項」「安い見積もりの読み方」を整理し、最後に外注先へ投げかける確認チェックリストにまとめて解説します。技術の専門家でなくても、自社を守りながらAI活用の恩恵を受けるための判断軸を持ち帰っていただける内容を目指します。

バイブコーディングを外注に使うとは？発注者が押さえる前提

まずは、本記事で扱う「バイブコーディングを使う外注」がどういう状況を指すのか、発注者の目線で要点だけ整理します。概念の詳しい解説は本記事の主題ではないため、判断に必要な範囲に絞って押さえていきましょう。

バイブコーディングが外注の現場に入ってきた背景

バイブコーディングとは、ざっくり言えば「自然言語（日本語や英語の指示文）でAIに指示を出し、コードを生成させながらソフトウェアを作る開発手法」です。従来はエンジニアが一行ずつ手で書いていたコードを、AIに「こういう機能を作って」と指示して生成させ、人がそれを取捨選択・調整していくスタイルを指します。概念そのものや、外注費・期間・品質への影響をもう少し体系的に押さえたい方は、バイブコーディングとは？発注者が今すぐ使える自社影響の3軸判断フレームもあわせてご覧ください。

この手法が外注の現場に入ってきた理由はシンプルで、開発のスピードが上がり、コストを抑えやすくなるからです。AIがコードの大部分を生成してくれれば、同じ機能をより短い時間で形にできます。その結果、外注先は「短納期・低コスト」を提案できるようになり、相場より大幅に安い見積もりが出てくることも増えてきました。発注者が「AIで作るなら外注も安くなるのでは」と考えるのも、こうした変化が背景にあります。

ここで大切なのは、「安く・速く作れる」こと自体は事実だという点です。問題はその安さ・速さが、何を前提にして成り立っているのか。そこを見極めないまま発注するかどうかに、判断の分かれ目があります。なお、外注に出すのではなく自社の業務に内製で取り入れる選択肢も含めて検討したい場合は、Vibe Codingの業務活用｜発注者・経営者の判断軸と始め方で内製と外注のバランスを整理しています。

従来の外注と何が変わるのか

人が一行ずつ書いていた時代の開発委託では、「エンジニアが書いたコードの品質は、そのエンジニアの責任で担保される」という前提が比較的はっきりしていました。書いた本人が中身を理解しており、不具合があれば直し、納品物の権利関係も「人が作ったもの」として整理しやすかったのです。

バイブコーディングを使う外注では、この前提が静かに変化します。具体的には、次の3つの「前提の変化」が起こります。

• 品質の前提: コードを「書いた」のがAIになることで、人が中身を完全には把握していない部分が生まれやすくなります。動いてはいるが、なぜ動くのかを誰も説明できないコードが残るリスクです。
• 権利の前提: AIが生成したコードには、学習元のコードやオープンソースの断片が混ざり込む可能性があり、「この納品物の権利は本当に自社のものか」が従来より曖昧になりやすくなります。
• 責任の前提: 指示を出した人、生成したAI、レビューした人、運用するオーナーの間で、「不具合が起きたとき誰が責任を負うのか」が分散しやすくなります。

つまり、バイブコーディングを使う外注は「速い・安い」というメリットと引き換えに、品質・権利・責任の前提が変わるという性質を持っています。発注者が見るべきは、まさにこの変化した前提への備えです。次の章から、品質・契約・見積もりの順に、具体的に何を確認すればよいかを掘り下げていきます。

バイブコーディングを使う外注の品質リスク——発注者が知るべき3つの落とし穴

ここでは、AI生成コードを使う外注で発注者が後から困りやすい品質リスクを、3つに整理します。技術的な詳細そのものよりも、「それが発注者にどう跳ね返ってくるのか」という観点でお伝えします。漠然とした「品質は大丈夫か」という不安を、確認できる項目に変えていきましょう。

セキュリティ脆弱性の混入

最初の落とし穴は、AIが生成したコードにセキュリティ上の弱点（脆弱性）が残りやすいという点です。

AIは大量のコードを学習して「それらしいコード」を生成しますが、生成されたコードがセキュリティ的に安全であることを保証してくれるわけではありません。むしろ、外部からの攻撃に弱い書き方や、機密情報の扱いが甘い実装が、人の目を通らないまま紛れ込むことがあります。セキュリティ専門のベンダーや調査機関からも、バイブコーディングで作られたコードに脆弱性が混入しやすいことへの注意喚起が相次いでいます（トレンドマイクロ「バイブコーディングの本当のリスク」、GMO Flatt Security「バイブコーディングのセキュリティリスク7選」）。

発注者にとって怖いのは、こうした脆弱性が「動作確認では分からない」ことです。画面が正しく表示され、機能が一通り動けば、見た目には問題なく完成しているように見えます。しかし内部にセキュリティの穴が残っていると、公開後に情報漏えいや不正アクセスといった重大なトラブルにつながりかねません。だからこそ、「AIが生成したコードを、人がセキュリティの観点でレビューしているか」「必要に応じてセキュリティ診断を行うか」が、確認すべき重要なポイントになります。

保守性・属人化の問題——「動くが中身を誰も理解していない」

2つ目の落とし穴は、「動いてはいるが、中身を誰も理解していない」コードが納品されてしまうリスクです。

バイブコーディングでは、AIが短時間で大量のコードを生成します。納期とコストを優先するあまり、生成されたコードを人が十分に理解・整理しないまま組み込んでいくと、後から見て構造が分からない「ブラックボックス」が出来上がります。一見すると完成しているので発注時点では気づきにくいのですが、問題は運用が始まってから表面化します。

たとえば、機能を追加したい、不具合を直したい、別の会社に保守を引き継ぎたい——こうした場面で、「中身を誰も理解していないコード」は大きな足かせになります。改修のたびに調査コストがかさみ、引き継ぎを受けた会社が「これは一から作り直したほうが早い」と判断するケースすらあります。実際に、AIで作られたコードの引き継ぎや後始末を専門に請け負う開発会社が現れているのは、この問題が現場で起きていることの裏返しです（参考: もばらぶん「バイブコーディングの後始末します」）。

発注者が確認すべきは、「設計やコードの意図がドキュメントとして残るか」「保守や引き継ぎを前提とした作りになっているか」です。初期費用の安さだけを見て、保守不能なシステムを抱え込んでしまわないよう注意が必要です。

責任所在の分散——不具合時に「誰が直すのか」

3つ目の落とし穴は、不具合が起きたときに「誰が責任を持って直すのか」が曖昧になりやすいことです。

従来の開発では、「コードを書いたエンジニア（とその所属する会社）」が品質に責任を負う、という構図が比較的明確でした。ところがバイブコーディングでは、登場人物が増えます。指示（プロンプト）を作った人、実際にコードを生成したAI、その出力をレビューした人、できあがったサービスを運用するオーナー——これらの間で、責任が分散してしまうのです（トレンドマイクロ「バイブコーディングの本当のリスク」、日経クロステック「AI駆動開発で増す人の責任」）。

「AIが生成したコードなので、当社の責任とは言い切れない」といった主張が外注先から出てくると、発注者は宙ぶらりんの状態に置かれます。不具合が出ても誰も直さない、直すなら追加費用がかかる、という事態になりかねません。

ここで重要なのは、この「責任所在の分散」が、技術の問題であると同時に契約の問題でもあるという点です。AIを使ったかどうかにかかわらず、「外注先が納品物の品質に責任を負う」という枠組みを契約で明確にしておけば、責任の所在が曖昧になるのを防げます。次の章では、まさにこの契約面で押さえるべき条項を整理していきます。

契約の変化——AI生成コードの外注で見直すべき条項

ここからは本記事の核心です。バイブコーディングを使う外注では、従来の開発委託契約のままだと発注者が十分に守られない論点がいくつかあります。品質・権利・責任の不安に、契約条項という具体的な形で答えていきましょう。

なお、以下で触れる契約の考え方は、経済産業省や特許庁といった公的機関が公開している資料でも整理されています。AI開発・利用に関する契約の論点は、経済産業省「AIの利用・開発に関する契約チェックリスト」（令和7年2月）や、特許庁 IP BASE「AI開発を受託する際の契約方式の選び方」が参考になります。実際の契約では、これらを踏まえて弁護士など専門家のチェックを受けることをおすすめします。

著作権の帰属——「作ってもらえば自社のもの」とは限らない

まず押さえたいのが、納品物の著作権の帰属です。

多くの発注者が「お金を払って作ってもらったのだから、当然その権利は自社のものになる」と考えがちです。しかし日本の著作権法では、特約（契約での取り決め）がない限り、開発したプログラムの著作権は原則として作った側（受託者）に残ります。発注者は「使う権利」を得られても、改変したり第三者に渡したりする権利まで自動的に得られるわけではないのです。

これはAIを使うかどうかにかかわらず重要な論点ですが、バイブコーディングを使う外注ではさらに注意が必要です。契約には次のような点を明記しておきましょう。

• 著作権の移転特約: 納品物の著作権を発注者に移転する旨を明記する
• 翻案権の扱い: 後から自社で改修・改変できるよう、翻案権（プログラムを改変する権利）も移転対象に含める
• 著作者人格権の不行使: 受託者が著作者人格権を行使しないことを取り決めておく（これがないと、改変時に異議を唱えられる余地が残ります）

「作ってもらったコードを、将来別の会社に引き継いで改修したい」という場面は珍しくありません。権利の整理が曖昧だと、その当たり前のことができなくなる恐れがあります。

OSSライセンス混入の表明保証——意図せぬ違反を防ぐ

2つ目は、オープンソースソフトウェア（OSS）のライセンス問題です。

AIは大量の既存コードを学習しているため、生成されたコードの中に、特定のライセンス条件が付いたOSSの断片が混ざり込む可能性があります。問題なのは、OSSの中には「これを使ったソフトウェアは、ソースコードを公開しなければならない」といった条件を課すものがあることです。気づかないうちにこうしたコードが混入していると、自社のシステムが意図せずライセンス違反の状態になったり、公開を望まないコードの開示を迫られたりするリスクが生じます。AI駆動開発では、ライセンス違反のコードが混入する懸念が以前から指摘されています（日経クロステック「AI駆動開発で増す人の責任、古いコード混入やライセンス違反の懸念」）。

発注者が自衛するには、契約に次のような条項を入れておくことが有効です。

• 表明保証: 納品物に第三者の権利を侵害するコードやライセンス違反となるOSSが含まれていないことを、受託者に保証してもらう
• 補償条項: 万一ライセンス違反などの問題が生じた場合に、受託者が損害を補償する旨を定める
• OSS利用の開示: どのOSSをどのライセンスで利用しているかを一覧（OSSリスト）として提出してもらう

これらは、AI生成コードを使う外注では特に重要度が増す条項です。

契約不適合責任と品質保証の範囲

3つ目は、納品物に欠陥（不具合）があった場合の責任、いわゆる契約不適合責任です。

請負型の契約では、納品物が契約で定めた品質を満たしていない場合、発注者は受託者に対して修補（直してもらうこと）や損害賠償などを求められます。これは発注者を守る大切な仕組みです。

注意したいのは、バイブコーディングを使う外注で「AIが生成したものなので品質は保証できない」といった理由で、品質保証の範囲を狭めようとする提案がないかという点です。AIを使ったかどうかは、外注先が品質に責任を負うべきかどうかとは本来切り離して考えるべきものです。発注者としては、次の点を確認しましょう。

• 品質保証の範囲: どの範囲の不具合まで保証されるのか、保証期間はどのくらいか
• AI活用を理由とした免責の有無: 「AI生成だから」という理由で責任が不当に縮小されていないか
• 検収基準: 何をもって「完成」とするかの基準が明確か

「AIで作ったから安い分、品質保証は薄い」という取引は、安さの裏にリスクを抱え込むことになります。安さと保証のバランスを見極めることが大切です。なお、受託開発会社が自社プロセスとして品質保証や検収基準をどう設計しているかという供給側の視点は、Vibe Codingで受託開発の品質を保つ実務と見積もり設計に整理されています。発注先がどこまで体制を整えているかを見極める参考になります。

請負型と準委任型の選び方

最後に、契約形態そのものの選び方です。開発委託の契約は、大きく「請負型」と「準委任型」に分かれます。

• 請負型: 受託者が「成果物の完成」を約束する契約。完成しなければ報酬を請求できず、契約不適合責任も負います。成果物の品質を求めるなら請負型が発注者に有利です。
• 準委任型: 受託者が「業務の遂行」を約束する契約。完成そのものは約束せず、善良な管理者としての注意義務を果たすことが求められます。要件が固まりきらない探索的な開発などに向きます。

どちらを選ぶかは案件の性質によりますが、特許庁 IP BASEでも整理されているとおり、成果物の完成責任を負わせたい場合は請負型が基本になります。

ここでバイブコーディング特有の注意点があります。AIを使った開発では「どこまでできれば完成なのか」の線引きが曖昧になりやすいということです。AIが生成したコードが一通り動いているように見えても、品質・保守性・セキュリティの観点で「完成」と言えるかは別問題です。請負型を選ぶ場合でも、検収基準（何を満たせば完成とするか）を契約書や仕様書で具体的に定めておくことが、後のトラブルを防ぐ鍵になります。

見積もりの読み方——「安い」をどう判断するか

ここまで品質と契約を見てきました。この章では、発注者が最も切実に悩む「この安い見積もり、得なのか、それとも後でツケが来るのか」という疑問に正面から向き合います。

かつて開発費は「人月（エンジニア1人が1ヶ月働く工数）×単価」で見積もるのが一般的でした。工数がそのままコストに直結していたのです。ところがバイブコーディングによってAIが工数の一部を肩代わりするようになり、「工数＝コスト」という前提が崩れ始めています。同じ機能でも見積もりに大きな差が出るようになり、発注者は「なぜこんなに安いのか」を読み解く力が求められるようになりました。

なぜ安くなるのか／その安さは何を削っているのか

安い見積もりに出会ったら、まず「その安さは妥当な効率化によるものか、それとも本来必要なものを削った結果か」を見分ける視点が必要です。

AI活用による正当な効率化であれば、コードを書く時間が短縮され、その分だけ安くなるのは納得できます。問題は、見えにくいところでコストを削っているケースです。具体的には、次のような工程が削られていないかに注意しましょう。

• テスト: 動作を確認するテストが十分に行われているか
• レビュー: AIが生成したコードを、人がセキュリティや品質の観点で確認しているか
• ドキュメント: 設計やコードの意図が文書として残されるか
• 保守設計: 後から改修・引き継ぎしやすい構造になっているか

これらは納品時点では「あってもなくても動く」ように見えるため、削っても発注者が気づきにくい部分です。しかし、削られた分のツケは運用フェーズで必ず回ってきます。安さの正体がこれらの省略にあるなら、それは「安い」のではなく「後払い」だと考えるべきです。

見積もりに含まれるべき項目をチェックする

安さに惑わされないためには、見積もりに「本来含まれているべき項目」が入っているかを確認するのが有効です。次の項目が見積もりに明示されているかをチェックしましょう。

• 品質保証: テスト・検証の工程と費用が含まれているか
• セキュリティレビュー: AI生成コードのセキュリティ確認が含まれているか
• 保守・引き継ぎ: ドキュメント整備や引き継ぎ資料の作成が含まれているか
• 権利処理: 著作権の移転やOSSライセンスの確認といった権利面の対応が含まれているか

これらが見積もりに見当たらない場合、「安いから含まれていない」のか「当然やるが書いていないだけ」なのかを、必ず外注先に確認してください。口頭で「やります」と言われても、見積もりや契約に明記されていなければ後で揉める原因になります。

「後始末コスト」を含めたトータルで判断する

最終的に発注の可否を判断する際は、初期費用の安さだけでなく、運用開始後まで含めた総コストで比較することが重要です。

前の章でも触れたとおり、保守不能なコードや権利が曖昧な納品物は、後から大きなコストを生みます。改修のたびに調査費用がかさむ、別の会社への引き継ぎが難航する、セキュリティ事故が起きて対応に追われる——こうした「後始末コスト」は、初期見積もりには現れません。

A社の見積もりが100万円、B社が60万円だったとしても、B社が品質保証・保守設計・権利処理を削っているなら、運用開始後に差額を超えるコストがかかる可能性があります。発注の判断は、「初期費用」ではなく「初期費用＋運用・改修・事故対応まで含めたトータルコスト」で行う——これが、AI時代の見積もりの読み方の基本です。

発注前の確認チェックリスト——外注先に聞くべきこと

ここまでの内容を、発注者が実際に外注先へ投げかけられる確認質問のチェックリストにまとめます。品質・権利・責任・体制の4つの観点で整理しました。発注を決める前に、これらを外注先に質問し、納得できる回答が得られるかを確認してください。

品質・セキュリティの確認

AIが生成したコードが、人の目を通して品質・安全性を担保されているかを確認します。

• AIが生成したコードは、人によるレビューを経ていますか。どのような体制でレビューしていますか。
• テストはどの範囲・どの程度行いますか。テスト工程は見積もりに含まれていますか。
• セキュリティの確認（脆弱性診断など）は行いますか。必要な場合、別途費用はかかりますか。

権利・ライセンスの確認

納品物の権利が確実に自社のものになり、ライセンス上のリスクがないかを確認します。

• 納品物の著作権は当社に移転されますか。翻案権や著作者人格権の取り扱いはどうなりますか。
• 利用しているOSSの一覧（ライセンス含む）を提出してもらえますか。
• 第三者の権利を侵害するコードやライセンス違反のOSSが含まれていないことを、契約で保証してもらえますか。

責任・保守の確認

不具合が起きたときの対応と、長期的な保守・引き継ぎの体制を確認します。

• 納品後に不具合が見つかった場合、誰がどの範囲まで対応しますか。保証期間はどのくらいですか。
• 「AIが生成したコードだから」という理由で、品質や責任の範囲が限定されることはありませんか。
• 設計やコードの意図を示すドキュメントは残りますか。将来、別の会社に保守を引き継ぐことは可能ですか。

体制・透明性の確認

どこまでをAIが担い、どこからを人が担うのかを、外注先が誠実に開示してくれるかを確認します。

• 開発のどの部分にAI（バイブコーディング）を使い、どの部分を人が担いますか。
• AI活用にあたって、品質・セキュリティ・権利の管理はどのように行っていますか。

これらの質問に対し、外注先が具体的かつ誠実に答えてくれるかどうか自体が、信頼できる相手かを見分ける手がかりになります。

バイブコーディングを使う外注先と、うまく付き合うために

ここまで品質リスク・契約・見積もりと、注意すべき点を整理してきました。最後にお伝えしたいのは、バイブコーディングを使う外注は「怖いから避けるべきもの」ではない、ということです。

適切に管理されたAI活用は、短納期・低コストという確かなメリットをもたらします。大切なのは、それを避けることではなく、正しく見極めて使うこと。判断軸を持って発注できれば、AI活用の恩恵を安全に受け取れます。

AI活用を管理できる外注先の見分け方

信頼できる外注先かどうかは、これまで挙げたリスクへの向き合い方に表れます。見分けるポイントは、こちらが細かく聞く前から、品質・権利・責任について自分から開示・提案してくれるかどうかです。

「AIを使うので、こういうリスクがあります。だから当社ではこうレビューし、契約ではこう保証します」と、リスクと対策をセットで説明してくれる相手は、AI活用を管理できている可能性が高いと言えます。逆に、安さばかりを強調し、品質・権利・責任の話を曖昧にする相手には注意が必要です。本記事のチェックリストを使えば、その違いははっきり見えてくるはずです。

発注者側が準備しておくべきこと

外注先を見極めるだけでなく、発注者側の準備も発注の成否を左右します。次の3点を整えておきましょう。

• 要件の言語化: 何を作りたいのかを具体的に言葉にしておく。要件が曖昧だと、AIを使うかどうかにかかわらず「完成」の判断が難しくなります。
• 契約条項の事前整理: 本記事で触れた著作権の移転・OSSライセンスの表明保証・契約不適合責任・契約形態（請負/準委任）を、契約前に整理しておく。専門家のチェックを受けられればより安心です。
• 検収基準の明確化: 何を満たせば「完成」とするかの基準を、発注前に自社で定めておく。これがあると、納品時の判断がぶれません。

AIによって開発のあり方が変わっても、発注者がやるべきことの本質は変わりません。「何を作りたいかを明確にし、品質・権利・責任を契約で守り、トータルコストで判断する」——この基本を押さえれば、バイブコーディングを使う外注を、コストとスピードの味方として活用できます。本記事のチェックリストを、ぜひ次の発注判断にお役立てください。