AI生成コードを保守するために、開発を「水彩」と「油絵」で分ける
こんにちは。Algomatic でソフトウェアエンジニアをしている Go（@53able）です。
AI でコードを書くようになると、実装そのものよりも、その後の扱い方で悩む場面が増えます。
小さな修正や既存パターンに沿った実装なら、AI はかなり頼りになります。テストの雛形作成、似た処理の横展開、単純な UI 変更は、手で書くより早く終わることも多いはずです。
ただ、速く出たコードほど、あとから困ることがあります。差分が大きすぎてレビューしにくい。なぜその設計にしたのか分からない。動いてはいるけれど、採用してよいか判断しにくい。
この記事では、この問題を「戻り方」の問題として考えます。その補助線として使うのが、水彩と油絵の違いです。
油絵は、最初から主役だったわけではない
油絵（Oil Painting）は、ある日突然ほかの絵画技法を置き換えたわけではありません。中世からルネサンス期のヨーロッパでは、テンペラやフレスコも重要な技法でした。油を媒材にした絵具は以前から使われていましたが、乾きが遅く、重ねやすく、修正しやすい性質が活かされるにつれて、表現の中心に寄っていきます。
出典：National Gallery / Italian Renaissance Learning Resources
www.italianrenaissanceresources.com
ここで大事なのは、技法の勝ち負けではありません。制作の前提が変わったことです。一度で決めるより、下に置き、直し、重ねながら完成に近づける。その性質が、より複雑な表現に向いていました。
AI 支援開発（AI-assisted development）でも、似たことが起きています。コードを書く速度が上がったことで、「速く作る」だけでは足りなくなりました。どの単位で試し、どこで検証し、どこまで戻れるようにするか。そこを設計しないと、速さはそのまま手戻りの大きさになります。
この記事で判断できるようになること
想定読者は、AI によるコード生成を開発フローに入れ始めた開発者、テックリード、エンジニアリングマネージャーです。
「水彩」と「油絵」は、美術史を厳密に説明するためではなく、開発の進め方を考えるための比喩として使います。
水彩的開発（Watercolor-style development）は、軽く、速く、戻りにくい。
油絵的開発（Oil painting-style development）は、薄く置き、直し、重ねながら育てる。
AI 時代の開発では、速く出す力だけでなく、あとから検証し直せる設計が必要になる。
手元のチームで測った実測値までは扱いません。その代わり、後半で AI 支援開発に関する研究を補助線として使います。実際にチームへ入れるなら、レビュー時間、手戻り件数、AI 生成コードの修正率、CI 失敗率などを、自分たちの環境で測るのが次の段階です。
AI 支援開発では、設計メモから実装を起こす、テストを生成する、リファクタ案を出す、といった作業が以前より短い時間で進みます。
そのぶん、開発者の仕事は少し変わります。手でコードを書く時間は減り、「何を作るべきか」「どこまで AI に任せるか」「どう検証するか」を決める時間が増えていきます。
ここで問題になるのは、開発の前提です。
- 最初に要件を固めれば十分なのか
- 生成されたコードを、どの単位で受け入れるのか
- いつユーザーや運用の現実に当てるのか
- 間違いに気づいたとき、どれだけ小さく戻れるのか
この記事では、水彩を「軽く、速く、戻りにくい制作」、油絵を「重ねながら直せる制作」の比喩として使います。
出典：National Gallery
開発でも似たことが起きます。速く書けることは強みです。ただ、検証の単位が粗いままだと、その速さは手戻りの大きさに変わります。
図解：一気に出す開発と、検証しながら重ねる開発
image水彩的開発と油絵的開発
この図で言いたいのは、どちらが常に優れているかではありません。作業の不確実性が高いほど、油絵的に「戻れる形」で進めたほうが安全だということです。
水彩的開発でよいのは、戻しやすい小さな作業
水彩的な開発は、悪い進め方ではありません。
要件が明確で、実装範囲が小さく、失敗してもすぐ戻せるなら、一気に描き切るほうがよい場面があります。そこに重い設計やレビューを持ち込むと、かえって作業が遅くなります。
たとえば、次のような作業です。
- 小さな UI 文言修正
- 既知のバグの局所修正
- 既存パターンに沿った CRUD 追加
- 破棄前提の検証スクリプト
- 一度限りの社内ツール
この場合は、AI で素早く実装し、人間が軽く確認して終えるほうが自然です。全部を大げさなプロセスに乗せる必要はありません。
ただし、水彩的開発には弱点があります。
- 最初の判断が外れると、大きく戻りにくい
- 後から意図を説明しにくい
- 変更差分が大きくなるとレビューが追いつかない
- 「動いた」ことと「採用してよい」ことが混ざりやすい
つまり、水彩的開発は、低リスクで不確実性が低い作業に向いています。
油絵的開発が必要なのは、要件が揺れる作業
油絵的な開発は、一度で完成させる進め方ではありません。段階を分けて育てる進め方です。
最初に薄く置く。動かしてみる。違和感を見つける。直す。必要な部分を重ねる。最後に仕上げる。
この進め方は、リーン開発の「小さく作って学ぶ」という考え方に近いです。
imageリーン開発の学習ループ
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
ソフトウェア開発でも、似た問題が起きます。
- 要件は変わる
- ユーザーは実物を触るまで本音を言えない
- 作って初めて技術的な難所が見える
- 大きく作るほど、間違いに気づいたときの損失が大きい
- 未完成機能や長い待ち行列は、製造業でいう在庫に近い
だからリーン開発は、計画を捨てる思想ではありません。大きく賭ける前に、小さく作って学ぶ思想です。
水彩的開発は、短い距離を一気に進みます。油絵的開発は、学習できる単位で重ねます。
AI 時代に重要なのは、どちらか一方を正解にすることではありません。作業の性質によって切り替えることです。
AI 導入後に壊れるのは、差分を大きくしすぎる進め方
AI 支援開発で起きる摩擦は、AI がコードを書けるかどうかだけではありません。コードが速く出るほど、受け入れ方の粗さも見えやすくなります。
たとえば、次のような状態です。
- PR の差分が大きくなり、レビューが追いつかない
- 生成コードの意図が説明されず、後から保守しづらい
- テストはあるが、受け入れ基準とつながっていない
- 仕様変更に対して、どこまで戻ればよいか分からない
- 「動いた」ことと「採用してよい」ことが混ざる
これは、油絵で進めるべき対象を、水彩のように一気に描き切ってしまう状態です。
imageAI 時代の失敗パターン
問題は、AI そのものではありません。戻れない単位で速く作ってしまうことです。
必要なのは、AIを禁止することではありません。AIで速く作れる前提で、ワークフローを小さく切ることです。
そのための実務例として、Ponytailがあります。
Ponytailは、AIに「必要な最小限の実装」を選ばせるためのルールセットです。不要なら作らない。標準ライブラリやブラウザ標準で足りるなら、それを使う。新しい依存を増やす前に、既存の手段を見る。この順序で、AIの過剰実装を抑えます。
ただし、「短ければよい」という話ではありません。入力検証、データ損失を防ぐエラーハンドリング、セキュリティ、アクセシビリティは削らない。この記事の言葉で言えば、AIに一気に描かせる前に、そもそも描く量を減らすための道具です。
Ponytail自体の考え方や使い方は、別記事で詳しく書いています。
リーン開発の言葉で言えば、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
Paradis et al. の Google 社内 RCT（ランダム化比較試験）も、同じ方向の結果を示しています。Google のソフトウェアエンジニア 96 人を対象とした複雑な enterprise-grade task（企業グレードのタスク）において、AI の支援は作業時間を短縮しました。著者らの推定値は約 21% です。ただし、信頼区間は広く、論文自身も「この効果が他のツール、他の時期、他の開発環境にそのまま当てはまるとは限らない」と注意しています。
出典：Paradis et al., 2024, arXiv:2410.12944
品質についても、速度だけでは見えません。GitHub が公開した 2024 年の controlled trial（統制実験）記事では、Copilot 利用群のコードは unit test（単体テスト）通過やレビュー評価でよい結果を示しました。記事によれば、Copilot 利用者は全 10 の unit tests を通過する可能性が 53.2% 高く、読みやすさ、信頼性、保守性、簡潔さの評価も 1 から 4% 程度の範囲で、統計的に有意に高かったとされています。
出典：GitHub Blog, 2024, updated 2025
ただし、この結果も「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
原文を表示
こんにちは。AlgomaticでソフトウェアエンジニアをしているGo（@53able）です。
AIでコードを書くようになると、実装そのものよりも、その後の扱い方で悩む場面が増えます。
小さな修正や既存パターンに沿った実装なら、AIはかなり頼りになります。テストの雛形作成、似た処理の横展開、単純なUI変更は、手で書くより早く終わることも多いはずです。
ただ、速く出たコードほど、あとから困ることがあります。差分が大きすぎてレビューしにくい。なぜその設計にしたのか分からない。動いてはいるけれど、採用してよいか判断しにくい。
この記事では、この問題を「戻り方」の問題として考えます。その補助線として使うのが、水彩と油絵の違いです。
油絵は、最初から主役だったわけではない
油絵は、ある日突然ほかの絵画技法を置き換えたわけではありません。中世からルネサンス期のヨーロッパでは、テンペラやフレスコも重要な技法でした。油を媒材にした絵具は以前から使われていましたが、乾きが遅く、重ねやすく、修正しやすい性質が活かされるにつれて、表現の中心に寄っていきます。
出典: National Gallery / Italian Renaissance Learning Resources
www.italianrenaissanceresources.com
ここで大事なのは、技法の勝ち負けではありません。制作の前提が変わったことです。一度で決めるより、下に置き、直し、重ねながら完成に近づける。その性質が、より複雑な表現に向いていました。
AI支援開発でも、似たことが起きています。コードを書く速度が上がったことで、「速く作る」だけでは足りなくなりました。どの単位で試し、どこで検証し、どこまで戻れるようにするか。そこを設計しないと、速さはそのまま手戻りの大きさになります。
この記事で判断できるようになること
想定読者は、AIによるコード生成を開発フローに入れ始めた開発者、テックリード、エンジニアリングマネージャーです。
「水彩」と「油絵」は、美術史を厳密に説明するためではなく、開発の進め方を考えるための比喩として使います。
水彩的開発は、軽く、速く、戻りにくい。
油絵的開発は、薄く置き、直し、重ねながら育てる。
AI時代の開発では、速く出す力だけでなく、あとから検証し直せる設計が必要になる。
手元のチームで測った実測値までは扱いません。その代わり、後半でAI支援開発に関する研究を補助線として使います。実際にチームへ入れるなら、レビュー時間、手戻り件数、AI生成コードの修正率、CI失敗率などを、自分たちの環境で測るのが次の段階です。
AI支援開発では、設計メモから実装を起こす、テストを生成する、リファクタ案を出す、といった作業が以前より短い時間で進みます。
そのぶん、開発者の仕事は少し変わります。手でコードを書く時間は減り、「何を作るべきか」「どこまでAIに任せるか」「どう検証するか」を決める時間が増えていきます。
ここで問題になるのは、開発の前提です。
- 最初に要件を固めれば十分なのか
- 生成されたコードを、どの単位で受け入れるのか
- いつユーザーや運用の現実に当てるのか
- 間違いに気づいたとき、どれだけ小さく戻れるのか
この記事では、水彩を「軽く、速く、戻りにくい制作」、油絵を「重ねながら直せる制作」の比喩として使います。
出典: National Gallery
開発でも似たことが起きます。速く書けることは強みです。ただ、検証の単位が粗いままだと、その速さは手戻りの大きさに変わります。
図解：一気に出す開発と、検証しながら重ねる開発
この図で言いたいのは、どちらが常に優れているかではありません。作業の不確実性が高いほど、油絵的に「戻れる形」で進めたほうが安全だということです。
水彩的開発でよいのは、戻しやすい小さな作業
水彩的な開発は、悪い進め方ではありません。
要件が明確で、実装範囲が小さく、失敗してもすぐ戻せるなら、一気に描き切るほうがよい場面があります。そこに重い設計やレビューを持ち込むと、かえって作業が遅くなります。
たとえば、次のような作業です。
- 小さなUI文言修正
- 既知のバグの局所修正
- 既存パターンに沿ったCRUD追加
- 破棄前提の検証スクリプト
- 一度限りの社内ツール
この場合は、AIで素早く実装し、人間が軽く確認して終えるほうが自然です。全部を大げさなプロセスに乗せる必要はありません。
ただし、水彩的開発には弱点があります。
- 最初の判断が外れると、大きく戻りにくい
- 後から意図を説明しにくい
- 変更差分が大きくなるとレビューが追いつかない
- 「動いた」ことと「採用してよい」ことが混ざりやすい
つまり、水彩的開発は、低リスクで不確実性が低い作業に向いています。
油絵的開発が必要なのは、要件が揺れる作業
油絵的な開発は、一度で完成させる進め方ではありません。段階を分けて育てる進め方です。
最初に薄く置く。動かしてみる。違和感を見つける。直す。必要な部分を重ねる。最後に仕上げる。
この進め方は、リーン開発の「小さく作って学ぶ」という考え方に近いです。
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
ソフトウェア開発でも、似た問題が起きます。
- 要件は変わる
- ユーザーは実物を触るまで本音を言えない
- 作って初めて技術的な難所が見える
- 大きく作るほど、間違いに気づいたときの損失が大きい
- 未完成機能や長い待ち行列は、製造業でいう在庫に近い
だからリーン開発は、計画を捨てる思想ではありません。大きく賭ける前に、小さく作って学ぶ思想です。
水彩的開発は、短い距離を一気に進みます。油絵的開発は、学習できる単位で重ねます。
AI時代に重要なのは、どちらか一方を正解にすることではありません。作業の性質によって切り替えることです。
AI導入後に壊れるのは、差分を大きくしすぎる進め方
AI支援開発で起きる摩擦は、AIがコードを書けるかどうかだけではありません。コードが速く出るほど、受け入れ方の粗さも見えやすくなります。
たとえば、次のような状態です。
- PRの差分が大きくなり、レビューが追いつかない
- 生成コードの意図が説明されず、後から保守しづらい
- テストはあるが、受け入れ基準とつながっていない
- 仕様変更に対して、どこまで戻ればよいか分からない
- 「動いた」ことと「採用してよい」ことが混ざる
これは、油絵で進めるべき対象を、水彩のように一気に描き切ってしまう状態です。
問題は、AIそのものではありません。戻れない単位で速く作ってしまうことです。
必要なのは、AIを禁止することではありません。AIで速く作れる前提で、ワークフローを小さく切ることです。
そのための実務例として、Ponytailがあります。
Ponytailは、AIに「必要な最小限の実装」を選ばせるためのルールセットです。不要なら作らない。標準ライブラリやブラウザ標準で足りるなら、それを使う。新しい依存を増やす前に、既存の手段を見る。この順序で、AIの過剰実装を抑えます。
ただし、「短ければよい」という話ではありません。入力検証、データ損失を防ぐエラーハンドリング、セキュリティ、アクセシビリティは削らない。この記事の言葉で言えば、AIに一気に描かせる前に、そもそも描く量を減らすための道具です。
Ponytail自体の考え方や使い方は、別記事で詳しく書いています。
リーン開発の言葉で言えば、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
Paradis et al. のGoogle社内RCTも、同じ方向の結果を出しています。96人のGoogle software engineerを対象にした複雑な enterprise-grade task で、AI支援は作業時間を短縮しました。著者らの推定値は約21%です。ただし、信頼区間は広く、論文自身も「この効果が他のツール、他の時期、他の開発環境にそのまま当てはまるとは限らない」と注意しています。
出典: Paradis et al., 2024, arXiv:2410.12944
品質についても、速度だけでは見えません。GitHubが公開した2024年の controlled trial 記事では、Copilot利用群のコードは unit test 通過やレビュー評価でよい結果を示しました。記事によれば、Copilot利用者は全10 unit testsを通過する可能性が53.2%高く、読みやすさ、信頼性、保守性、簡潔さの評価も1から4%程度の範囲で、統計的に有意に高かったとされています。
出典: GitHub Blog, 2024, updated 2025
ただし、この結果も「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
関連記事
Algomatic がノーコード環境「LeLab」で模倣学習を開始
Algomatic のエンジニアである Yusuke 氏が、低コストロボットアーム SO-101 を用いたシミュレーションと実機実験を通じて、同社が提供するノーコードプラットフォーム「LeLab」での模倣学習の取り組みを紹介している。
Claude Code / Codex Hooks と nvim --server で作る terminal-native IDE
gogとCodexでGoogleスライドを作る
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み