ブログ/記事一覧/AIが書いたコードが壊れたら誰のせいか
ai-code-warranty-void-cover

AIが書いたコードが壊れたら誰のせいか

AI生成コードに保証は誰がつけるのか。HNで話題の記事を起点に、仕様と実装の責任ギャップからEU製造物責任指令まで整理

ニュース
kkm-horikawa

kkm

Backend Engineer / AWS / Django

2026.03.205 min5 views
Share X B! Hatena LINE in LinkedIn RSS

1万4000ドルが仕様書の行間から消えた

ウィスコンシン州の酪農家Ethan Novakは、AIが生成した飼料最適化ツールを使っていました。ある日、別のツールが更新されて出力フォーマットが変わり、飼料コストの計算がずれました。牛乳の価格設定を間違え、損害は1万4000ドル。

コードにバグがあったわけではありません。仕様書に書かれていなかった「上流ツールの出力フォーマットが変わる可能性」が、静かに牙をむいたのです。

この事例が登場するのは、Hacker Newsで449ポイントを獲得した記事『Warranty Void If Regenerated（再生成したら保証は無効）』です。AI生成コードが当たり前になった世界で、「壊れたら誰のせいか」という問いを突きつけています。

『Warranty Void If Regenerated』は何を言っているのか

この記事は、ソフトウェアのコストが限りなくゼロに近づく未来を考察するSubstack「Near Zero」に、Scott Werner氏が発表したものです。

主人公はウィスコンシン州の「ソフトウェア修理工」Tom Hartmann。農家を回って、AI生成ツールの不具合を診断する仕事をしています。彼のもとには毎日、AIが作ったツールが原因不明の動作をするという相談が持ち込まれます。

記事が描くのは3つの事例です。

依頼者ツールの目的壊れた原因損害額
Margaret Brennan収穫タイミングの予測気象データの計算方法が
上流で変更された		2万5000ドル
Ethan Novak飼料コストの最適化別ツールの出力フォーマットが
再生成で変わった		1万4000ドル超
Carol Lindgren灌漑スケジュールの最適化30年分の土地固有の知識を
仕様書に書けなかった		手動切替で回避

3つに共通するのは、コード自体は正しく動いているということです。問題は仕様書が現実を完全に記述できなかったこと。AIは仕様書の通りに完璧なコードを生成しますが、仕様書に書かれていないことは知りようがありません。

AIが書いたコードはなぜ壊れるのか

記事から浮かび上がるのは、3つの典型パターンです。

1. 外部データの変更

仕様書は「入力Aを受け取り、出力Bを返す」と書かれています。しかし入力Aそのものが外部サービスから来ており、そのサービスが計算方法を変えると、仕様通りに動いているのに結果が狂います。Tom Hartmannによれば、依頼の約60%がこのパターンです。

2. 上流ツールの連鎖崩壊

Ethan Novakは40以上のAI生成ツールを連携させていました。1つのツールが再生成されて出力フォーマットが変わると、下流のツールが誤ったデータを受け取ります。人間が書いたコードなら変更履歴を追えますが、AI生成コードは「再生成」のたびに前のバージョンが消えます。

3. 言語化できない暗黙知

Carol Lindgrenは30年かけて、自分の土地の粘土層の排水パターンや微気候を体で覚えていました。この知識は仕様書に書けません。AIは一般的な灌漑の原則は理解できますが、「この区画の南東角は水はけが悪い」といった現場知識は持ちようがありません。

「AIは間違えることがあります」で済ませていいのか

ChatGPTを使ったことがある人なら、「AIは間違えることがあります。重要な情報は確認してください」という注意書きを見たことがあるはずです。

この一文が、現在のAI業界の責任構造を象徴しています。主要なAIプラットフォームの利用規約を見ると、ほぼすべてが「現状のまま提供、保証なし（as-is, no warranty）」を基本にしています。

出力が正確かどうか、他人の著作権を侵害していないかどうか、特定の用途に適しているかどうか。これらすべてについて、AI企業は責任を負わないと宣言しています。確認する責任は、すべて使う側にあります。

法律事務所MBHBの分析によれば、AIが生成したコードはそもそも著作権で保護されない可能性があります。米国著作権局は「著作権は人間の創造性によって作られた作品にのみ適用される」としており、AI単独の出力は保護の対象外です。

つまり、AIが書いたコードが壊れても保証はなく、そのコードを著作権で守ることもできない。AI出力の責任は最終的にそれを使った組織が負うというのが、現時点での法的な見解です。

MicrosoftとAnthropicだけが補償を約束している

「保証なし」が業界標準のなかで、例外的に補償を提供しているのがMicrosoftとAnthropicです。

MicrosoftのCopilot Copyright Commitmentは、Copilotの出力が第三者の著作権を侵害していると訴えられた場合、Microsoftが顧客を法的に防御し、損害賠償を肩代わりするという約束です。GitHub Copilot、Microsoft 365、Dynamics 365など、有料の法人向けサービスが対象になっています。

ただし条件があります。製品に組み込まれたフィルターやセーフティシステムを使っていることが前提です。フィルターを外して使った場合は対象外になります。

Anthropicもエンタープライズ向けに知的財産権の補償を提供しています。ただし、これらの補償は「著作権侵害の訴訟」に対するものであり、Near Zeroが描いたような「仕様と現実のギャップによる損害」は対象外です。

企業補償内容対象対象外
Microsoft著作権侵害の
法的防御＋損害賠償		Copilot有料法人プランフィルター無効化時、
出力の品質・正確性
AnthropicIP侵害の補償エンタープライズプラン出力の品質・正確性
OpenAI / Google / 他なし（as-is）—すべて

補償があるのは著作権の話だけ。「AIが書いたコードのせいで損害が出た」という場面では、どの企業も助けてくれません。

EUは「AIソフトも製造物」と決めた

この状況を変えようとしているのがEUです。

2024年12月に発効した新しいEU製造物責任指令（2024/2853）は、「製造物」の定義をソフトウェア、AIシステム、デジタルサービス、ソフトウェアアップデートにまで拡大しました。各加盟国は2026年12月までにこの指令を国内法に取り込む必要があります。

これが意味するのは、AIが生成したソフトウェアも物理的な製品と同じ製造物責任の対象になるということです。電子レンジが故障して火事になったらメーカーが責任を問われるのと同じ論理で、AIソフトウェアの欠陥による損害も製造者の責任になり得ます。

Baker Donelsonの2026年AI法務予測によれば、この指令は「as-is, no warranty」で済ませてきたAI企業のビジネスモデルに根本的な見直しを迫る可能性があります。

一方、米国では連邦レベルのAI規制は整備が遅れています。カリフォルニア州のAI透明性法が2026年1月に施行されるなど州レベルの動きはありますが、AI生成コードの保証義務を定めた法律はまだありません。

Near Zeroの記事に登場するTom Hartmannのような「ソフトウェア修理工」が必要になっている現実は、法律が追いつくまでの空白地帯を誰かが埋めなければならないことを示しています。AIが書いたコードは誰のものでもなく、壊れても誰も保証せず、でも損害は確実に発生する。この空白を埋めるのが法律なのか、新しい職業なのか、それとも保険なのかはまだ分かりません。

参照元