生成AIコーディングは開発をどこまで変えるか｜過信が生む3つの落とし穴

生成AIにコードを書かせることは、すでに特別な取り組みではなくなりました。GitHub CopilotやAIエージェントを使い、機能のたたき台を短時間で組み上げる光景も、珍しいものではなくなっています。ところが実際には、実装が速くなったぶんだけプロジェクトが速く終わるわけではありません。本稿では、生成AIコーディングが開発の何を変えるのかを、コードの書き方ではなく開発マネジメントの視点から捉え直します。

システム開発を発注・管理する立場にあるPMやPMO、情報システム部門やDX推進部門の方々、そしてAIによるコード生成を日常的に使っているエンジニアの方々に読んでいただけると実り多い内容となっています。読み終えたとき、AI前提の開発で見落とされやすい3つの落とし穴と、過信に陥らないための4つの設計が、実務で使える形で手元に残るはずです。

INDEX

• 0. はじめに
• 1. 生成AIコーディングで、実際に速くなったのは何か
• 2. 見落とされやすい3つの落とし穴
• 3. 過信に陥らないための4つの設計
• 4. おわりに

0. はじめに

金曜の夕方に頼んだ機能のコーディングが、月曜の朝には完了している。生成AIにコードを書かせるようになって、開発の体感速度は確かに変わりました。しかし、プロジェクト全体の完了予定日を見ると、以前とさほど違いがない。現場でよく耳にするのは、「実装は速くなった。ただ、リリースまでの期間は思ったほど縮まらない」という声です。

GitHub CopilotやAIエージェントを使ったコード生成は、もはや一部の先進的な開発現場に限られた話ではありません。それでも、期待した効果と実際に得られた効果の間には、いくつものズレが残っています。そのズレを放置したまま「AIを入れたのだから速くなるはずだ」という前提で見積りを立てると、しわ寄せは必ず別の工程に及びます。

あらかじめお伝えしておくと、本稿は生成AIコーディングを否定する立場ではありません。使わない選択肢は、現実的ではないと考えています。問題となるのは、効果を過大に見積もったまま計画と体制を組んでしまうこと、つまり「過信」です。

そこで本稿では、AIによるコード生成が開発の何を変えるのかを、開発マネジメントの視点から整理します。なお、どの生成AIツールで何ができるのかという基礎については、過去の記事：「生成AI時代のプログラミング：バイブコーディングの活用と課題」がございますのでご一読ください。本稿が扱うのはその先、「AIに書かせる前提で、開発をどう管理するか」です。

1. 生成AIコーディングで、実際に速くなったのは何か

まず、AIによるコード生成が得意な領域を押さえます。効果が明確に出ているのは、次の3つです。

• ゼロから書き始める負荷：空のファイルを前にした「最初の1行」の重さが、ほぼ消えます。ベース・骨組みだけ作らせ、そこから作り始めていく進め方が定着しました。
• 定型的な記述：画面のひな形、データの入れ替え処理、テストコード、設定ファイルなど、書き方が決まっているものは、AIに任せることで作業時間が大きく縮みます。
• 調べながらコードを書く作業：使った経験のないライブラリやAPIでも、動く例を出させながら進められるため、調査と実装が同時に進みます。

いずれも、これまで人が手を動かしてきた工程です。生成AIによってこの部分が速くなること自体は、疑いようがありません。

一方で、開発というプロセスは手を動かす工程だけで成り立っているわけではありません。要件を定め、設計の方針を合わせ、コードの検証を行い、リリースの可否を判断する。開発全体は、この連なりで成り立っています。速くなったのが「書く」という一点だけであれば、全体がその比率で速くなることはありません。

開発全体の速度は、最も時間のかかる工程、つまりボトルネックによって決まります。

であれば、実装が速くなった次に見るべきは、そのボトルネックがどこへ移ったのかという点です。

2. 見落とされやすい3つの落とし穴

落とし穴①｜ボトルネックは「書く工程」から「レビュー工程」へ

実装が速くなると、作業が滞る場所は次の工程へ移ります。「コードレビュー」と「検証」工程です。具体的に何がボトルネックであるかを、3点に整理します。

• レビュー待ちが積み上がる：出てくる量が増えれば、点検する量も増えます。書き手が1人でも、AIが生成する量は数人分に達します。レビューに回せる人数が変わらなければ、そこで滞留します。
• 1件あたりの確認が重くなる：人が書いたコードには、書き手の癖や迷った跡が残ります。一方、AIの出力は書式が整い、しかも均質です。ひと目では問題がなさそうに見えるため、かえって「本当に意図どおりか」を確かめる手間がかかります。
• 指摘が次に活きにくい：人へのレビュー指摘は、その人の次回の品質を上げます。AIの出力への指摘は、指示や設定に反映しない限り、次も同じ形で戻ってきます。

つまり、実装が速くなるほどレビューに負荷が集まるという構造です。マネジメント側の帰結は明確です。レビューと検証の体制を先に設計しないまま生成AIを導入すると、上がったはずの速度は「レビュー待ちの成果物」という在庫に変わります。

この在庫は、進捗の上では「できている」ように見えます。だからこそ厄介です。実装の完了率は上がり、報告の数字も良くなる。それでもリリースは近づかない。冒頭の「実装は速くなったが、期間は縮まらない」という感覚の正体は、多くの場合ここにあります。

落とし穴②｜「動くコード」と「保守できるコード」は別物である

生成AIは、指示された機能が動く状態を最短距離で作ります。裏を返せば、指示していないことはそのまま抜け落ちます。とくに見落とされやすいのが、後々の保守で響いてくる次のような点です。

• 重複の排除：既にある処理を使い回し、同じ機能を二重に作らない。
• 依存関係の抑制：安易にライブラリを足さず、必要な範囲にとどめる。
• 命名と構造の整備：半年後の担当者が読んでも、全体像をたどれるようにする。

いずれも、動作テストは通ります。問題が表に出るのは、次に手を入れるときです。修正のたびに影響範囲が読めず、ひとつの変更に時間がかかる。いわゆる技術的負債です。AIによる開発では、短期生産性と引き換えに、この負債が積み上がりやすくなります。

ここで厄介なのは、この負債が指標に表れない点です。記録に残るのは「予定より早く仕上がった」という事実だけで、支払いは半年後に、別の担当者の工数として現れます。初期スピードだけで開発生産性を評価すると、負債の蓄積を成果として計上してしまいます。

ここは、内製化を進める組織ほど注意が必要な部分でもあります。外注であれば、保守性を契約や検収の条件として明文化できます。ところが内製では、その基準を自分たちで決めておかない限り、誰も確かめません。

落とし穴③｜「なぜこう作ったか」を説明できる人がいなくなる

3つ目は、品質の問題というより、組織にとって重い問題です。障害が起きたとき、監査を受けるとき、担当者が入れ替わるとき。必ず問われるのは「なぜこの作りになっているのか」です。 AIに書かせたコードは動きます。しかし、次の問いに答えられる人が社内に残っていないことがあります。

• なぜこの方式を選んだのか（ほかの選択肢と比べて何が良かったのか）
• コードの処理が前提にしている条件は何か
• ここを変えると、どこに影響が及ぶのか

コードそのものは生成できます。ところが、設計上の判断とその理由は生成できません。人が決めていない判断には、記録も根拠も残らないからです。

そして、この空白は責任の所在という論点に直結します。生成物に自分の名前で承認を与えた時点で、説明する責任は使い手の側へ移ります。「AIが生成したものなので」という言い訳は、社内でも社外でも通用しません。AIへの任せ方と責任の持ち方については、過去の記事：「AIの最大活用と部下育成の共通点とは？」にて、任せることと丸投げの違いとして整理しています。

3. 過信に陥らないための4つの設計

ここまでに紹介した「3つの落とし穴」は、いずれもコードの書き方だけでは避けられません。回避するには、開発の進め方そのもの、つまりマネジメント側の設計を見直す必要があります。実務で効く順に、4つの設計をご紹介します。

設計ポイント① 「完成」の定義を書き換える

従来の「動作すること」に、生成AIコーディングを前提とした条件を足します。たとえば「テストが用意されている」「追加した依存関係の理由が書かれている」「既存の処理と重複していない」などが挙げられます。完成の条件に入っていない項目は、誰も確認しません。まず完成の定義に手を入れるのが、いちばん費用対効果の高い一手となるのです。

設計ポイント② レビューを「読む」から「確かめる」に変える

出てくる量が増えた状況で、全行を読み切る前提はもう成り立ちません。読んで納得する方式から、確かめて担保する方式へ切り替えます。具体的には、先にテストを読む、入出力の境界と例外処理に的を絞る、実際に動かして挙動を見る。人の時間をどこに使うかを決める作業です。

設計ポイント③ 任せる範囲を、領域で線引きする

すべてを同じ基準で扱う必要はありません。目安として、次のように分けて考えます。

【積極的に任せてよい領域】

• プロトタイプ、社内向けの小さなツール、使い捨ての検証コード
• 定型的なテストコード、設定ファイル、データ処理
• 既存コードの読み解きや、改善案の洗い出し

【人が設計を握る領域】

• 認証・認可、決済、個人情報を扱う処理
• 他システムとの連携部分と、障害時の復旧に関わる処理
• 性能・セキュリティの要件が厳しい中核機能

前者は速度を優先する領域、後者は確実性を優先する領域です。この線引きをプロジェクトの開始時に決めておくと、レビューに割く時間の配分も自然に定まります。

設計ポイント④ 設計意図を、人の言葉で残す

最後は記録です。「なぜこの方式にしたか」を数行残すだけで、半年後の保守と引き継ぎのコストは大きく変わります。コードは生成できても、判断の理由は生成できない。ここだけは、人が引き受ける工程として残す必要があります。

なお、AI前提の開発では、進め方の選び方も変わってきます。ウォーターフォールとアジャイルのどちらを軸に据えるかという設計については、過去の記事：「AI時代のシステム開発の進め方とは？」にて整理されています。

4. おわりに

生成AIコーディングは、開発を確かに変えます。ただし変わるのは「書く速さ」であり、開発全体の速さが同じ比率で上がるわけではありません。過信の落とし穴は、この2つを同じものとして扱うところから生まれます。

本稿で述べた3つの落とし穴と過信に陥らないための4つの設計を、改めて整理します。

【３つの落とし穴】

1.  ボトルネックの移動：実装が速くなるほど、レビューと検証に負荷が集まる
2. 保守性の後回し：動くコードは手に入るが、保守できるコードは指示しなければ揃わない
3. 説明責任の空白：コードは生成できても、設計判断の理由は生成できない

【過信に陥らないための4つの設計】

1. 「完成」の定義を書き換える
2. レビューを「読む」から「確かめる」に変える
3. 任せる範囲を、領域で線引きする
4. 設計意図を、人の言葉で残す

打ち手は、いずれもコードの外側にあります。「完成」の定義を書き換え、レビューのやり方を「読む」から「確かめる」へ切り替え、任せる範囲を線引きし、判断の理由を人の言葉で残す。生成AIコーディングで問われているのは、エンジニアの技術力よりも、開発をどう管理するかという設計です。 AIは、コーディングの工程を圧倒的に速くしてくれます。ただ、その速さが成果になるかどうかは、受け取る側の準備で決まります。次にAIへ実装を任せるとき、「何ができたら完成と呼べるのか」を先に決めてみてください。その一手間があるかないかで、上がったスピードが成果として残るか、レビュー待ちの在庫として積み上がるかが分かれます。