10月12日、Mark Seemann（ブログ名：ploeh）が「Releasing AI-generated software」と題した記事を公開した。LLMが生成したコードを誰も読まずにリリースする時代における、ソフトウェアエンジニアリングの認識論と法的責任の所在について論じた内容だ。
「コードを読まない」という戦略
発端は、Clean Code の著者として知られるRobert C. Martinのツイートだ。
「私の現在の戦略は、エージェントが書いたコードを一切読まないことだ。それが生産性を最大限に活かす唯一の方法だ。代わりに、エージェントをあらゆる制約で包囲する。ユニットテスト、Gherkinテスト、QA手順、品質メトリクス、ミューテーションテスト、カバレッジ計測、その他多数。最終的には、それらすべての制約とテストをくぐり抜けたコードに対して、非常に高い信頼感を持てる。」
なお、Martin自身はその後この手法について修正ツイートを出しているが、著者はその立場の変化よりも、発言が引き起こした問い——「コードを読まずにソフトウェアエンジニアリングは成立するか」——を記事の主題として取り上げる。
コードレビューは元々、完全ではなかった
著者の第一反応は「コードを見ないなら、正しいとどうやって確認するのか」という疑問だった。だが、すぐにそれが思い込みだと気づいたという。
Code Complete 第2版 第21章などの研究によれば、コードレビューはバグ発見の手法として有効とされている。しかし完全ではない。オフバイワンエラー、nullポインタ例外、見落としたステート変更——これらは熟練エンジニアが慎重にレビューしても抜けることがある。
つまり「人間がコードを読む」というプロセス自体、元から完全な品質保証ではなかった。この前提を崩すと、「コードを読まないことがなぜ問題なのか」という問い自体が変質してくる。
テストと検証だけで成立するエンジニアリングへ
Dave Farleyの著書 Modern Software Engineering が提示する視点では、ソフトウェアエンジニアリングの本質は「反証可能な予測への迅速なフィードバック」だ。コードを書き・読むという行為は手段にすぎない。
LLMエージェントを複数組み合わせる「チーム型」の手法——テストを書くエージェント、コードレビューを行うエージェントを分けるアプローチ——は、著者自身が以前は懐疑的だったが、実際に良好な結果を報告するユーザーがいると認めている。
著者は「LLMに完璧さを求めるのは、人間にも課してこなかった基準を課すことだ」と指摘する。自動運転の議論と同じ論理——人間より安全であればよい——が、LLM駆動のソフトウェアエンジニアリングにも適用できる可能性がある。
最も重い問い：誰が責任を取るのか
記事のコアはここだ。
仮にLLMが生成したコードを誰もレビューせず、それでも人間による工程と同等かそれ以上の品質を達成できたとする。それでもバグはゼロにはならない。
軽微なもの——ボタンの配置ずれ、言語表示の誤り——は許容範囲かもしれない。しかし深刻なケースもある：
- 火星探査機 Mars Climate Orbiterの喪失（3億2760万ドルの損失）
- Therac-25の放射線過剰照射事故（レースコンディションによる死亡事故）
- トヨタの意図しない加速問題
このような事案では法的責任が生じる。Dieselgateでは個人の開発者が実際に刑事責任を問われた。ソフトウェアの欠陥を「機械のせい」と主張しても、法廷ではリリースを承認した人間が問われるという構図は、すでに現実のものとなっている。
著者が提示する仮想の法廷シーンは端的だ：
「—でも裁判官、バグを書いたのはLLMです。」
「そうかもしれないが、君がリリースを承認したんだろう？」
「はい…」
「LLMを刑務所に送ることはできないが、君には刑を科せる。」
現時点では、ソフトウェア開発者個人の刑事責任を直接規定する法律は多くの国で整備途上にある。しかしDieselgateの前例や製造物責任法の類推適用を考えれば、AI生成コードに起因する重大事故が起きた際に「誰も責任を取らない」という結末は、法的にも社会的にも受け入れられないだろう。
自動運転との類比
2026年6月、デンマークの交通当局がTeslaのFSD（Full Self-Driving）を条件付きで承認した。条件は「運転者が最終責任を持つ」こと。
著者の予測はシンプルだ。システムの精度が上がるほど、ドライバーは注意を払わなくなる。大半の場合は問題ない。だが事故が起きたとき、法的責任はドライバーに残る。ソフトウェアエラーが原因であっても。
LLMによるソフトウェア開発でも同じことが起きると著者は見る。コスト削減と生産性向上というインセンティブがあまりにも強力なため、組織はリスクを過小評価して全面移行を進める。そして問題が起きたとき、「LLMが書いた」という言い訳は法廷では通用しない。
エンジニアとCTOへの問いかけ
記事は問いで終わる。「誰もコードを書かなかったとき、誰が責任を負うのか」。
著者は別記事「Are you ready to go to prison for an AI」でも同テーマを掘り下げている。AI生成コードのリリースを検討する組織は、技術的品質保証の設計と同時に、法的リスクの引き受け方を今から整理しておく必要がある。「AIが書いたコードを誰も読まずにリリース」することが現実的な選択肢として浮上しつつある今、その問いを先送りにすることのコストは、日々大きくなっている。
詳細はReleasing AI-generated softwareを参照していただきたい。
