AI生成コードを保守するために、開発を「水彩」と「油絵」で分ける

![image](https://cdn-ak.f.st-hatena.com/images/fotolife/c/catshun/20260622/20260622171106.png) こんにちは。Algomatic でソフトウェアエンジニアをしている Go（[@53able](https://zenn.dev/53able)）です。 AI でコードを書くようになると、実装そのものよりも、その後の扱い方で悩む場面が増えます。 小さな修正や既存パターンに沿った実装なら、AI はかなり頼りになります。テストの雛形作成、似た処理の横展開、単純な UI 変更は、手で書くより早く終わることも多いはずです。 ただ、速く出たコードほど、あとから困ることがあります。差分が大きすぎてレビューしにくい。なぜその設計にしたのか分からない。動いてはいるけれど、採用してよいか判断しにくい。 この記事では、この問題を「戻り方」の問題として考えます。その補助線として使うのが、水彩と油絵の違いです。 ![image](https://cdn-ak.f.st-hatena.com/images/fotolife/g/gotadano/20260619/20260619153215.png) ## 油絵は、最初から主役だったわけではない 油絵（Oil Painting）は、ある日突然ほかの絵画技法を置き換えたわけではありません。中世からルネサンス期のヨーロッパでは、テンペラやフレスコも重要な技法でした。油を媒材にした絵具は以前から使われていましたが、乾きが遅く、重ねやすく、修正しやすい性質が活かされるにつれて、表現の中心に寄っていきます。 出典：National Gallery / Italian Renaissance Learning Resources [www.nationalgallery.org.uk](https://www.nationalgallery.org.uk/paintings/glossary/oil) [www.italianrenaissanceresources.com](https://www.italianrenaissanceresources.com/glossary/oil-painting/) ここで大事なのは、技法の勝ち負けではありません。制作の前提が変わったことです。一度で決めるより、下に置き、直し、重ねながら完成に近づける。その性質が、より複雑な表現に向いていました。 AI 支援開発（AI-assisted development）でも、似たことが起きています。コードを書く速度が上がったことで、「速く作る」だけでは足りなくなりました。どの単位で試し、どこで検証し、どこまで戻れるようにするか。そこを設計しないと、速さはそのまま手戻りの大きさになります。 ## この記事で判断できるようになること 想定読者は、AI によるコード生成を開発フローに入れ始めた開発者、テックリード、エンジニアリングマネージャーです。 「水彩」と「油絵」は、美術史を厳密に説明するためではなく、開発の進め方を考えるための比喩として使います。 水彩的開発（Watercolor-style development）は、軽く、速く、戻りにくい。 油絵的開発（Oil painting-style development）は、薄く置き、直し、重ねながら育てる。 AI 時代の開発では、速く出す力だけでなく、あとから検証し直せる設計が必要になる。 手元のチームで測った実測値までは扱いません。その代わり、後半で AI 支援開発に関する研究を補助線として使います。実際にチームへ入れるなら、レビュー時間、手戻り件数、AI 生成コードの修正率、CI 失敗率などを、自分たちの環境で測るのが次の段階です。 AI 支援開発では、設計メモから実装を起こす、テストを生成する、リファクタ案を出す、といった作業が以前より短い時間で進みます。 そのぶん、開発者の仕事は少し変わります。手でコードを書く時間は減り、「何を作るべきか」「どこまで AI に任せるか」「どう検証するか」を決める時間が増えていきます。 ここで問題になるのは、開発の前提です。 - 最初に要件を固めれば十分なのか - 生成されたコードを、どの単位で受け入れるのか - いつユーザーや運用の現実に当てるのか - 間違いに気づいたとき、どれだけ小さく戻れるのか この記事では、水彩を「軽く、速く、戻りにくい制作」、油絵を「重ねながら直せる制作」の比喩として使います。 出典：National Gallery [www.nationalgallery.org.uk](https://www.nationalgallery.org.uk/paintings/glossary/oil) 開発でも似たことが起きます。速く書けることは強みです。ただ、検証の単位が粗いままだと、その速さは手戻りの大きさに変わります。 ## 図解：一気に出す開発と、検証しながら重ねる開発 ![image](https://cdn-ak.f.st-hatena.com/images/fotolife/g/gotadano/20260619/20260619144037.png)水彩的開発と油絵的開発 この図で言いたいのは、どちらが常に優れているかではありません。作業の不確実性が高いほど、油絵的に「戻れる形」で進めたほうが安全だということです。 ## 水彩的開発でよいのは、戻しやすい小さな作業 水彩的な開発は、悪い進め方ではありません。 要件が明確で、実装範囲が小さく、失敗してもすぐ戻せるなら、一気に描き切るほうがよい場面があります。そこに重い設計やレビューを持ち込むと、かえって作業が遅くなります。 たとえば、次のような作業です。 - 小さな UI 文言修正 - 既知のバグの局所修正 - 既存パターンに沿った CRUD 追加 - 破棄前提の検証スクリプト - 一度限りの社内ツール この場合は、AI で素早く実装し、人間が軽く確認して終えるほうが自然です。全部を大げさなプロセスに乗せる必要はありません。 ただし、水彩的開発には弱点があります。 - 最初の判断が外れると、大きく戻りにくい - 後から意図を説明しにくい - 変更差分が大きくなるとレビューが追いつかない - 「動いた」ことと「採用してよい」ことが混ざりやすい つまり、水彩的開発は、低リスクで不確実性が低い作業に向いています。 ## 油絵的開発が必要なのは、要件が揺れる作業 油絵的な開発は、一度で完成させる進め方ではありません。段階を分けて育てる進め方です。 最初に薄く置く。動かしてみる。違和感を見つける。直す。必要な部分を重ねる。最後に仕上げる。 この進め方は、リーン開発の「小さく作って学ぶ」という考え方に近いです。 ![image](https://cdn-ak.f.st-hatena.com/images/fotolife/g/gotadano/20260619/20260619144102.png)リーン開発の学習ループ AI 支援開発では、油絵的な進め方の価値が上がります。AI が実装速度を上げるほど、何を受け入れるか、どこで止めるか、どう戻すかを人間が設計する必要があるからです。 油絵的開発が向くのは、たとえば次のような場面です。 - 要件がまだ揺れている機能 - ユーザー体験の正解が見えていない画面 - 既存設計への影響が大きい変更 - セキュリティや権限が絡む実装 - AI 生成コードを長く保守する前提の開発 ここでは、AI に一気に作らせるより、戻れる単位に分けることが重要になります。 ## リーン開発は、速さより学習の単位を設計する リーン開発は、単に「速く作る」ための方法ではありません。 リーン開発は、トヨタ生産方式を含むリーン製造やリーン製品開発の考え方を、ソフトウェア開発に移したものです。大きく先に作る発想では、予測が外れたときに在庫や手戻りが膨らみます。 出典：Mary and Tom Poppendieck, Lean Software Development: An Agile Toolkit, 2003 sample, [https://ptgmedia.pearsoncmg.com/images/9780321150783/samplepages/0321150783.pdf](https://ptgmedia.pearsoncmg.com/images/9780321150783/samplepages/0321150783.pdf) ソフトウェア開発でも、似た問題が起きます。 - 要件は変わる - ユーザーは実物を触るまで本音を言えない - 作って初めて技術的な難所が見える - 大きく作るほど、間違いに気づいたときの損失が大きい - 未完成機能や長い待ち行列は、製造業でいう在庫に近い だからリーン開発は、計画を捨てる思想ではありません。大きく賭ける前に、小さく作って学ぶ思想です。 水彩的開発は、短い距離を一気に進みます。油絵的開発は、学習できる単位で重ねます。 AI 時代に重要なのは、どちらか一方を正解にすることではありません。作業の性質によって切り替えることです。 ## AI 導入後に壊れるのは、差分を大きくしすぎる進め方 AI 支援開発で起きる摩擦は、AI がコードを書けるかどうかだけではありません。コードが速く出るほど、受け入れ方の粗さも見えやすくなります。 たとえば、次のような状態です。 - PR の差分が大きくなり、レビューが追いつかない - 生成コードの意図が説明されず、後から保守しづらい - テストはあるが、受け入れ基準とつながっていない - 仕様変更に対して、どこまで戻ればよいか分からない - 「動いた」ことと「採用してよい」ことが混ざる これは、油絵で進めるべき対象を、水彩のように一気に描き切ってしまう状態です。 ![image](https://cdn-ak.f.st-hatena.com/images/fotolife/g/gotadano/20260619/20260619144144.png)AI 時代の失敗パターン 問題は、AI そのものではありません。戻れない単位で速く作ってしまうことです。 必要なのは、AIを禁止することではありません。AIで速く作れる前提で、ワークフローを小さく切ることです。 そのための実務例として、[Ponytail](https://github.com/DietrichGebert/ponytail)があります。 [github.com](https://github.com/DietrichGebert/ponytail) Ponytailは、AIに「必要な最小限の実装」を選ばせるためのルールセットです。不要なら作らない。標準ライブラリやブラウザ標準で足りるなら、それを使う。新しい依存を増やす前に、既存の手段を見る。この順序で、AIの過剰実装を抑えます。 ただし、「短ければよい」という話ではありません。入力検証、データ損失を防ぐエラーハンドリング、セキュリティ、アクセシビリティは削らない。この記事の言葉で言えば、AIに一気に描かせる前に、そもそも描く量を減らすための道具です。 Ponytail自体の考え方や使い方は、別記事で詳しく書いています。 [zenn.dev](https://zenn.dev/53able/articles/66616005d7aaf4) リーン開発の言葉で言えば、AI生成コードも「在庫」になりえます。レビューされず、検証されず、ユーザー価値に接続されないコードは、速く作られても価値ではありません。 ## 実務では、不確実性と影響範囲で進め方を分ける すべてを油絵的に扱うと、プロセスが重くなります。まず、作業を分けます。 判断軸 水彩的に進める 油絵的に進める 要件 明確 揺れている 影響範囲 小さい 広い 失敗時の戻しやすさ すぐ戻せる 戻すコストが高い レビュー 軽い確認で足りる 意図、設計、検証が必要 AIの使い方 一気に生成して確認 小さく生成して検証を重ねる 油絵的に進める作業では、細かい工程表を作るより、次の4点を決めておけば十分です。 - 最初に何を薄く作るか。プロトタイプ、設計スパイク、薄い実装のどれか。 - 何を見て正しいと判断するか。受け入れ基準、テスト、ログ、手動確認のどれか。 - どの単位ならレビューできるか。PRを大きくしすぎない。 - 外れたとき、どこまで戻るか。仕様、設計、実装のどの段階に戻るかを先に決める。 この判断は、特定のAIツールに依存しません。CopilotでもCursorでもClaude Codeでも使えますし、別のチームでも再利用できます。速く作れるほど、先に進め方を選ぶ必要があります。 ## 研究は、AIの速度向上と検証設計を分けて見る材料になる ここまでの「水彩」と「油絵」は比喩です。ただ、AI支援開発では「速く作れる」と「よく作れる」と「あとから保守できる」を分けて考えたほうがよい。この点は研究からも読み取れます。 まず、AIは開発速度を上げる可能性があります。Peng et al. の対照実験では、GitHub Copilotを使った開発者は、JavaScriptでHTTP serverを実装する課題を対照群より55.8%速く完了しました。ただし、これは特定の課題での結果です。大規模な既存コードベースや、曖昧な要件を含む開発全体にそのまま広げるのは危険です。 出典：Peng et al., 2023, arXiv:2302.06590 [arxiv.org](https://arxiv.org/abs/2302.06590) Paradis et al. の Google 社内 RCT（ランダム化比較試験）も、同じ方向の結果を示しています。Google のソフトウェアエンジニア 96 人を対象とした複雑な enterprise-grade task（企業グレードのタスク）において、AI の支援は作業時間を短縮しました。著者らの推定値は約 21% です。ただし、信頼区間は広く、論文自身も「この効果が他のツール、他の時期、他の開発環境にそのまま当てはまるとは限らない」と注意しています。 出典：Paradis et al., 2024, arXiv:2410.12944 [arxiv.org](https://arxiv.org/abs/2410.12944) 品質についても、速度だけでは見えません。GitHub が公開した 2024 年の controlled trial（統制実験）記事では、Copilot 利用群のコードは unit test（単体テスト）通過やレビュー評価でよい結果を示しました。記事によれば、Copilot 利用者は全 10 の unit tests を通過する可能性が 53.2% 高く、読みやすさ、信頼性、保守性、簡潔さの評価も 1 から 4% 程度の範囲で、統計的に有意に高かったとされています。 出典：GitHub Blog, 2024, updated 2025 [github.blog](https://github.blog/news-insights/research/does-github-copilot-improve-code-quality-heres-what-the-data-says/) ただし、この結果も「AI なら常に品質が上がる」という意味ではありません。GitHub の記事は、品質向上の理由として、機能を満たすまでの時間が短くなり、開発者が品質の調整に時間を使えた可能性を挙げています。AI だけで品質が生まれたというより、反復して直す余地があったことが効いている可能性があります。 この記事の比喩に戻すと、研究が示しているのはこうです。 - AI は、筆を速く動かす力になりうる - 速く描けても、何を完成とみなすかは別に決める必要がある - 品質は、生成そのものより、レビュー、テスト、修正の余地に左右される - だから、不確実性が高い作業では、油絵的に小さく重ねる設計が必要になる このくらいの言い方が、今の証拠には合っています。AI 支援開発の効果は実際に観測されています。ただし、その効果は課題、開発者、ツール、レビュー体制によって変わります。だからこの記事では、AI を使うかどうかではなく、作業ごとに「水彩的に進めるか、油絵的に進めるか」を先に決める、という実務判断に落とします。 ## AI 時代の開発者は、コードより先に進め方を選ぶ 水彩的な開発にも価値があります。軽く、速く、明快に終えられる作業はあります。 油絵的な開発にも価値があります。重ね、直し、検証しながら育てるべき作業もあります。 問題は、どちらが正しいかではありません。不確実性が高い仕事まで、水彩のように一気に描き切ってしまうことです。 AI 支援開発では、実装速度が上がります。だからこそ、開発者やチームは、どの作業を速く描き切り、どの作業を重ねながら育てるかを判断しなければなりません。 コードを書く仕事から、描き方を選び、戻れる単位で作り、検証し、採用判断を残す仕事へ。 AI 時代の開発者に求められるのは、速く書く力だけではなく、戻れる形で進める設計力です。 ## Sources - National Gallery, "Oil" https://www.nationalgallery.org.uk/paintings/glossary/oil - Italian Renaissance Learning Resources, "Oil painting" https://www.italianrenaissanceresources.com/glossary/oil-painting/ - Mary and Tom Poppendieck, Lean Software Development: An Agile Toolkit, 2003 sample https://ptgmedia.pearsoncmg.com/images/9780321150783/samplepages/0321150783.pdf - Sida Peng, Eirini Kalliamvakou, Peter Cihon, Mert Demirer, "The Impact of AI on Developer Productivity: Evidence from GitHub Copilot", 2023, arXiv:2302.06590 https://arxiv.org/abs/2302.06590 - Elise Paradis et al., "How much does AI impact development speed? An enterprise-based randomized controlled trial", 2024, arXiv:2410.12944 https://arxiv.org/abs/2410.12944 - GitHub Blog, "Does GitHub Copilot improve code quality? Here's what the data says", 2024, updated 2025 https://github.blog/news-insights/research/does-github-copilot-improve-code-quality-heres-what-the-data-says/ - Dietrich Gebert, "Ponytail" https://github.com/DietrichGebert/ponytail - Go, "Ponytail で AI エージェントに「怠惰なシニアエンジニア」の判断を入れる" https://zenn.dev/53able/articles/66616005d7aaf4

AI生成コードを保守するために、開発を「水彩」と「油絵」で分ける

背景や根拠まで確認しますか？

このニュースを、実務の判断につなげる

関連記事

調べる

選ぶ

サイト