――サイモン・ウィリソンが説く“動作を証明したコード”という責任🧪✅
生成AIコーディングは、いまや開発の標準ツールになりつつあります。実際、Microsoftでは社内リポジトリのコードの20〜30％がAIによって書かれているという発言もあり、開発者の多くが日常的にAIを使っています。📈🤖
ただし、その普及と同時に増えているのが **「AIに書かせたコードを、動作確認なしでレビューへ投げる」**という悪手です。
Datasetteの開発者として知られるソフトウェアエンジニア、サイモン・ウィリソン氏はこれを明確に批判します。
「あなたの仕事は“動作することを証明したコード”を届けること。単にコードを量産することではない」――この一言に本質が詰まっています。🔥
この記事では、ウィリソン氏の主張を軸に、なぜ“AI丸投げ”が職務怠慢になり得るのかを深掘りし、さらに最新の研究・セキュリティ・法務/コンプライアンス面も含めて、現場で使える対策まで落とし込みます。
そもそも「AI丸投げ」とは何か？🤔
ここで言う「AI丸投げ」は、AIを使うこと自体ではなく、次のような状態を指します。
- 🧩 AIが生成したパッチをほぼそのままPRに貼る
- 🧪 動作確認（手動・自動）を自分でしない
- 🧾 「レビューで見つけてください」前提の提出
- 🧨 仕様やエッジケースを把握せず、説明も薄い
これをやると、表面的には“進捗”が出ますが、実態は「負債の輸送」です。🚚💥
ダメな理由①：レビュー担当に“本来の開発作業”を押し付ける🧑⚖️⏳
ウィリソン氏が強く言うのはここです。
- コードを書くこと自体は、今やLLMが得意
- でも、正しく動くかを確かめ、証拠を添えて提出するのは人間の仕事
- それをしないと、負担がレビュー担当へ移転する
つまり、AI丸投げは「生産性」ではなく、他人の時間を燃やす設計になりがちです。🔥
レビューは本来「品質の二重化（保険）」であって、「動作確認代行」ではありません。
ダメな理由②：テストしないと“偶然動いた”が量産される🎲❌
AIは「もっともらしい」コードを出しますが、次の部分が弱いことが多いです。
- ⚠️ 例外系・境界値（null、空配列、桁あふれ）
- ⚠️ 実データの揺れ（フォーマット差・欠損）
- ⚠️ 既存仕様との整合（暗黙の前提、古い互換）
- ⚠️ 環境差（OS、Node/Python、DB差、タイムゾーン）
ここで重要なのは、**“動いた”ではなく“動くと証明できた”**です。
証明がないコードは、将来の自分やチームに対する時限爆弾になります。⏰💣
ダメな理由③：AIは「説明責任」を肩代わりできない🧾🙅♂️
現場では、バグが起きた瞬間に問われるのは
- 「誰が書いたか」ではなく
- 「なぜその変更を入れたか」「どの条件で正しいと言えるか」
です。
つまり、AIが書いても、責任はあなた（提出者）に残ります。
“AIがそう言った”は免罪符になりません。
ただし、ウィリソン氏はAIコーディングツールを完全に否定しているわけではありません。Claude CodeやCodex CLIなどのAIツールは作業中のコードを積極的に実行して動作確認し、問題があればさらに反復処理することに適していると言及。また、ツールの使い分けを推奨しており、「CLIツールを開発しているときは、Claude Codeにツールの実行方法を教え、単発テストを実行できるようにします。最終的な自動テストでは、ClickのCLIRunnerのようなシステムを使います」と語りました。他にも、「CSSの変更作業を行う際に、変更によって期待どおりの変化があるかを確認するために、コーディングエージェントにウェブサイトのスクリーンショットを撮るよう依頼する」など、用途に合った使い方を模索することを推奨しています。
ダメな理由④：セキュリティ面で“攻撃面”が増える🔐⚠️
AI丸投げは、セキュリティにも直撃します。
- 🧨 依存関係や設定の変更が紛れ込みやすい（サプライチェーン）
- 🧨 ちょっとした入力処理が脆弱性になる
- 🧨 “エージェント型AI”はIDEやツール実行権限を持つため、設計次第で危険が跳ね上がる
最近は、AI支援開発ツール（IDE/エージェント）に絡む脆弱性がまとめて指摘されるなど、便利さと引き換えに守るべき範囲が広がっています。
さらに、LLMアプリの代表的リスクとして プロンプトインジェクションが常に上位に挙げられ、「完全な根絶は難しい」という警告も出ています。🕳️
ダメな理由⑤：法務・コンプライアンスの地雷を踏みやすい⚖️🧯
AI利用そのものは一般化していますが、企業・サービス運用では次の論点が現実に効いてきます。
- 📌 ライセンス/著作権：AI生成コードとOSSライセンスの扱い（訴訟や議論が継続）
- 📌 監査性：「なぜこの実装なのか」「根拠は？」が説明できないと監査に弱い
- 📌 規制の潮流：EUではAI規制の枠組みが段階的に運用され、透明性やリスク管理が重視される方向
特に会社案件だと、AI丸投げは「納期」より先に「説明責任」で詰むことがあります。🧾💥
ウィリソン流：正しいAI活用の結論はシンプル✅
1) 手動テスト（自分で動くと確認する）🖱️
- 変更が“見える”なら、スクショや短い動画をPRに添付
- 「どこをどう操作したら、どう変わるか」を示す
- これができる人ほど強い（＝デバッグ能力が上がる）
2) 自動テスト（将来も壊れない仕組みにする）🧪
- 今回の変更が将来も動くことを保証する
- AIのおかげでテスト追加はむしろやりやすくなった
- ただし **「テストがあるから手動は省略」**はNG（確認の層が違う）
まとめ：AIは“加速装置”だが、ハンドルは人間が握る🚗💨
AIによってコードは速く書けます。
でも、**ソフトウェア開発のゴールは「コードを書くこと」ではなく「動作を証明した成果を届けること」**です。
- 🧪 自分で動作確認する（手動テスト）
- 🧷 将来も壊れないように固定する（自動テスト）
- 🧾 変更の根拠と証拠をPRに残す
この3点を守れば、AIは“丸投げ先”ではなく、最強の相棒になります。🤝🔥
参考・出典📚
- Simon Willison「Your job is to deliver code you have proven to work」（2025-12-18）
- TechCrunch「Microsoft CEO says up to 30% of the company’s code was written by AI」（2025-04-29）
- GitHub Blog（Wakefield Research調査）「Survey reveals AI’s impact on the developer experience」（2023-06-13）
- METR「Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity」（2025-07-10）
- Reuters「AI slows down some experienced software developers, study finds」（2025-07-10）
- OWASP「Top 10 for Large Language Model Applications（GenAI Security Project）」
- （補足）AI支援IDE/エージェントの脆弱性報道（いわゆる“IDEsaster”関連）
- GitHub Copilot関連訴訟の経過情報（公式ケースアップデート）
