要約： AIが書いたコードに不具合が出た場合でも、責任を負うのは、契約を結んだ開発会社です。AIツールではありません。確認すべきなのは契約の中身です。請負か準委任か、検収の基準、レビューとテストの記録、ソースコードの権利、要件変更の手順の5点を整理します。
目次
- AIが書いたコードに不具合が出たとき、責任は誰にあるのか
- 請負と準委任では、不具合のときの扱いがどう違うのか
- 契約不適合責任とは何か、不具合が発注側の指示によるときはどうなるのか
- 開発会社がAIを使うとき、契約に加えたい条項は何か
- VAONは実際の案件で何を記録し、残しているのか
- 契約で解決できないことは何か
- よくあるご質問
1. AIが書いたコードに不具合が出たとき、責任は誰にあるのか
責任を負うのは、お客様と契約を結んだ開発会社です。AIツールは契約の当事者ではないため、Claude CodeやGitHub Copilotを指して「ツールの問題です」と言うことはできません。民法の契約不適合や債務不履行の規定も、そのコードを人が書いたか機械が書いたかを区別していません。問われるのは、納品物が契約の内容に合っているかどうかです。
先にお断りしておきます。本記事は一般的な情報であり、法的助言ではありません。実際の契約書は、弁護士にご確認ください。
では、AIを使うことで何が変わるのでしょうか。責任の所在は変わりません。変わるのは、お客様が確認できるようにしておくべき事柄です。そのコードを、リリース前に誰が読んだのか。テストの記録はあるのか。どのAIツールがお客様のデータに触れたのか。この3つは、口約束ではなく書面に残す必要があります。
2. 請負と準委任では、不具合のときの扱いがどう違うのか
請負は仕事の完成を約束する契約で、納品後の不具合について修補などを求められます。準委任は仕事の完成を約束せず、業務の遂行に対して対価を払う契約のため、不具合への請求の道筋が大きく変わります。
| 請負 | 準委任（履行割合型） | |
|---|---|---|
| 開発会社が約束すること | 仕事の完成（民法632条） | 善良な管理者の注意をもって業務を行うこと（644条、656条） |
| 納品後に不具合があったとき | 契約不適合責任：追完、報酬の減額、損害賠償、解除 | 完成の義務はない。注意義務の違反や契約違反があった場合に請求できるのが通常（415条） |
| 向いている場面 | 要件が固まっていて、範囲が決まっている | 要件が動く、短いサイクルで進める |
| 発注側のリスク | 要件があいまいだと、「完成」もあいまいになる | 作業分の対価を払っても、期待した成果物が得られるとは限らない |
もう一つ、成果完成型の準委任があります（648条の2）。成果に対して報酬を払う形です。この型に契約不適合責任をどう当てはめるかは、見解が分かれる部分ですので、弁護士に確認するのが確実です。また、契約書の表題だけで決まるわけではありません。実際に何を合意し、どう進めたかも見られます。
3. 契約不適合責任とは何か、不具合が発注側の指示によるときはどうなるのか
契約不適合責任とは、納品物が種類や品質について契約の内容に合っていないときに、開発会社が負う責任です。請負の場合、発注者は追完（修補など）、報酬の減額、損害賠償、解除を求められます（562条から564条。559条により有償契約に準用）。ただし、不適合を知った時から1年以内にその旨を通知する必要があります（637条）。引渡しの時に開発会社がその不適合を知っていた場合、または重大な過失で知らなかった場合は、この期間制限は適用されません。
あまり読まれていないのが636条です。不適合が、発注者が提供した材料の性質や、発注者が与えた指図によって生じたものである場合、発注者は上記の請求ができません。ただし、開発会社がその指図が不適当だと知りながら告げなかったときは別です。つまり、開発会社が指示どおりに作り、その指示そのものが間違っていた場合は、製品の不具合とは扱われません。
AIを使う開発では、この点が一層重要になります。AIは、与えられた記述に忠実に、とても速く作ります。記述が誤っていれば、誤ったものが速く届きます。契約には具体的な検収基準を入れ、要件に問題がありそうなときは開発会社が指摘する義務も定めておくと安心です。
4. 開発会社がAIを使うとき、契約に加えたい条項は何か
AIを使う開発会社との契約には、次の5つの条項を加えることをおすすめします。AI利用の開示、レビューとテストの記録、コードの権利、AIに入力するデータ、変更管理です。
| 条項 | 書いておくこと | 理由 |
|---|---|---|
| AI利用の開示 | AIツールの種類、使う工程（コード生成、テスト生成、コードの読み直し）、変更時の通知義務 | 成果物に誰が、何が関わるのかを知るため |
| レビューとテストの記録 | リリースごとに、別の人によるコードの確認、テストシナリオ、チェックリストがあること。記録を保管し、発注側が閲覧できること | 不具合が出たとき、どの工程をすり抜けたかが分かる |
| コードの権利 | 納品したコードの帰属。著作権法27条・28条の権利を明記した譲渡条項。外部のライセンスが付いたコードを使う場合の通知義務 | 下の説明を参照 |
| AIに入力するデータ | 書面での許可なく、お客様のコードやデータをAIツールに入力しないこと | データの管理権をお客様に残すため |
| 変更管理 | 範囲外の作業は変更依頼を出し、開発会社が費用と日程への影響を書面で示し、発注側が承認してから着手する | 「不具合なのか、新しい要件なのか」の争いを防ぐ |
コードの権利について補足します。文化審議会著作権分科会法制度小委員会が取りまとめ、文化庁が公表している「AIと著作権に関する考え方について」（令和6年3月15日）では、AI生成物が著作物にあたるかは、個別の事例ごとに、人間の創作的寄与の程度で判断されるとされています。指示の具体性や、人が加筆・修正した部分などが要素に挙がっています。したがって、AIが生成したコードに著作権が当然にあるとは考えず、譲渡条項はできるだけ具体的にしておくほうが、双方にとって安全です。また、著作権法61条2項は、著作権を譲渡する契約で27条・28条の権利が特掲されていないときは、これらの権利は譲渡した側に留保されたものと推定すると定めています。
どの条項が必要かは、案件によって異なります。小規模な紹介サイトに、社内の基幹システムと同じ細かさの条項は要りません。
5. VAONは実際の案件で何を記録し、残しているのか
VAONは、すべての案件でレビューとテストの記録を残し、お客様が閲覧できるようにしています。2026年にお客様から最も多くいただいた質問の一つが、「AIが書いたコードは誰が確認するのか」でした。そのため、一般的な約束ではなく、手順でお答えしています。
VAONのエンジニアは、Claude CodeとGitHub Copilotを日常的に使っています。変更ごとに、次の7つのステップを踏みます。計画、別の担当者による反論、承認、構築（AIが補助し、人が確認）、相互チェックとチームリーダーの承認、独立した環境でのテスト、リリースノートとタグを付けたリリースです。メインブランチは保護しており、レビューを経ないとマージできません。
データについては、お客様の許可なく、コードやデータをAIツールに入力しません。許可をいただいていない場合は、AIによる確認の工程は動かさず、自動のチェックと人の目だけで進めます。速度は少し落ちますが、これは受け入れている代償です。
要件は、構築の前に書面で確定します。作業は1〜2週間の短い区切りで進め、動くものをご確認いただきます。範囲外の作業は、前述の変更の手順に従います。ご承認いただいていない作業の請求書をお送りすることはありません。仕様書がない案件は、仕様確定フェーズから始めます。このフェーズのあとで、中止していただくこともできます。関連記事：追加費用が発生しない開発会社の見分け方
保証の条件や責任の上限は、案件ごとに個別にご相談しています。ここでお示しできる共通の数値はありません。
6. 契約で解決できないことは何か
契約は、品質の代わりにはなりません。どれだけ厳密に書いても、不具合が出れば、お客様の時間は失われます。
ほかに3つの限界があります。1つ目は、契約が要件のあいまいさを消してくれないことです。システムが何をすべきか誰も書いていなければ、検収は争いになりえます。2つ目は、レビューの記録は実際に存在してこそ意味があるという点です。「記録があります」という言葉ではなく、閲覧できる権利が必要です。3つ目は、本記事がe-Govで直接確認した条文に基づいており、判例や解釈は個別の事案で異なりうる点です。金額の大きい契約では、最終案を弁護士に見ていただくことをおすすめします。
向かない場面もあります。ごく小さく、期間が短く、リスクの低い案件です。5つの条項をすべて整えると、守れるものより手間のほうが大きくなる場合があります。
7. よくあるご質問
「AIが書いたから」という理由で、開発会社は責任を免れられますか。 民法には、そのような根拠はありません。人が書いたかAIが書いたかを区別していないためです。開発会社は、契約に基づく納品物について責任を負います。ただし、契約に責任制限の条項が入っていることはあります。署名の前に、その部分をよくお読みください。
AIを使う案件では、請負と準委任のどちらがよいですか。 要件の固まり具合によります。要件と範囲が決まっているなら、請負のほうが請求の道筋が明確です。要件が動くなら、短いサイクルの準委任が合います。AIを使うからといって、この選択は変わりません。変わるのは、レビューとテストの記録も必要になる点です。
契約書にAIツールの名前まで書く必要はありますか。 ツールは変化が速いため、バージョン名ではなく、ツールの種類、使う工程、変更時の通知義務を書くことをおすすめします。大事なのは、データがどこへ渡るのかを把握でき、異議を述べられることです。
AIが生成したコードの権利は、発注者のものになりますか。 AIが生成したコードに著作権があるかは、人間の創作的寄与に応じて、個別に判断されます。そのため、27条・28条の権利を明記した、明確な譲渡条項を契約に入れておくのが安全です。具体的には弁護士にご相談ください。
開発会社が本当にAI生成コードをレビューしているか、どう確かめればよいですか。 記録を見せてもらってください。承認者が記録されたプルリクエスト、テストシナリオ、リリースごとのチェックリストです。実際に行っている会社なら、すぐに出せます。VAONでは、すべての案件で保管し、お客様が閲覧できます。
現在の開発契約に、AIについての記載はありますか。 第4章の表で、契約に足りない行に印を付けて、VAONのCEOが同席する60分の無料相談にお持ちください。資料のご準備は不要で、お申し込みを前提とするものでもありません。無料相談（60分）
関連記事： AI駆動開発を外注する前に確認する12項目 ・ 発注前に確認したい、開発会社の技術的な限界 ・ AI事業者ガイドラインで開発会社をチェックする
参考資料
- 民法（e-Gov法令検索、2026年10月17日確認）：https://laws.e-gov.go.jp/law/129AC0000000089
- 著作権法61条（e-Gov法令検索、2026年10月17日確認）：https://laws.e-gov.go.jp/law/345AC0000000048
- 文化庁「AIと著作権に関する考え方について」（令和6年3月15日）：https://www.bunka.go.jp/seisaku/chosakuken/aiandcopyright.html
執筆者： ダン・ヴァン・ルアン（Đặng Văn Luân）、VAON 創業者・CEO。ハノイ工科大学HEDSPI課程卒業。FPT Software、東京のDigital Plus（5年、1,000万ユーザー規模のシステム）を経て、従業員120名のITO企業でCOOを8年務め、ISO 9001・ISO 27001に沿った管理体制を構築。業界歴15年。
