こんにちは。
Digitectの西川です。
今回は、「AI任せの開発で、品質は守れるのか？」というテーマで、2026年3月時点の私の考えを整理してみます。
私はこれまで、大手SIerにて品質についてこだわりを持って開発を行ってきました。
開発工程の節目ごとに、定性・定量の両面で品質を点検し、必要な打ち手を講じることで品質を守る、という進め方です。
皆さんもご承知の通り、昨今の生成AIの実用化に伴い、システム開発の進め方が大きく変わってきています。
客観的な指標として、GitHubが2025年末に公開した「Octoverse Report（世界中の開発者のアクティビティを基にしたトレンドを分析）」においても、生成AIがシステム開発において「標準的なもの」になりつつあること、LLM SDK を使う公開リポジトリが大きく増えていること、さらに新規開発者の多くが早い段階で Copilot を利用していることを示しています。The GitHub Blog)
生成AIの利用は、もはや一部の先進的な開発者だけのものではなく、開発の裾野全体に広がっています。
重要なのは、普及そのものよりも、普及した結果として現場の論点が変わったことです。
一昔前までは「AIを使うべきかどうか」が議論の中心でした。
しかし、一定以上普及した今、問われているのは、
どの工程にAIを入れるのか
どこまでAIに委ねるのか
どのルールで人間が承認するのか
という、導入後の統制設計です。
本記事では、従来の品質管理手法については詳述しない予定です。
その代わりに、AIによって開発プロセスがどう変わったのか、そして その変化によってどんな課題が顕在化したのか を整理します。
後編では、それを踏まえて、AI任せの開発でも品質を守るには「何を再設計すべきか」を考えます。
AIで速くなったのは、プログラミングだけではない
少し前までは、システム開発における生成AIと言えば 「コードを自動生成できる」「プログラミングの知識がなくても作れる（いわゆるバイブコーディング）」 といった文脈で語られることが多かったと思います。
もちろんそれは今も変わりませんが、現在のシステム開発の現場で起きている変化はプログラミング工程にとどまりません。
現場ではAIで要件定義書の作成、設計方針の整理（選択肢のメリデメ比較）、テストケースの洗い出し、UIテスト、各種成果物のレビュー、とほぼ全ての工程がAIにより自動化され始めています。
私自身、要件定義や外部仕様の設計工程については、AIボイスレコーダーを用いたお客様へのヒアリング内容（音声ファイル）をAIにインプットし、要件定義書等のたたき台を自動生成する等して、上流工程から大きく生産性が上がるのを実感しております。
※音声利用時にはお客様の許諾を得た上で、適宜音声ファイルをトリミングして利用します。
また、上流設計時点で「生成AIで作成したプロトタイプ」を共有しながら外部仕様を詰められるので、要件定義・仕様の調整精度も従来より向上したように思います。
開発工程についてはClaude CodeやCursor、Codexで自動生成している方も多いのではないでしょうか。今や非エンジニアの方でも活用するくらいに浸透しております。
さらにコードレビューについては、AI同士で相互レビューさせる事で、単一のAIエージェントでは見落とされがちな不備も拾う事ができ、ソース単体の品質を向上させる事も可能です。人間は特定のチェックポイントにて、AIが誤った判断をしていない事を確認・適宜方向修正する役割に比重が移りました。
GitHub Copilot のコードレビュー機能もすでに一般提供されており、基本的なレビューの一部をエージェントに委ねる使い方も一般的になっています。GitHubは、コードレビューを速め品質向上を助ける手段として位置づけつつ、あくまで人間レビューの補助として使うべきだと明言しています。 (The GitHub Blog)
つまり、AIは「コーディング作業を一部代替する道具」から、開発工程の各所で人間の下準備・確認作業を代替する存在 へと役割を広げています。
ここで重要なのは、「作業が速くなった」という事だけではありません。
システムを開発する専門家として本当に見るべきなのは、品質を担保できるのか です。
従来であれば、人が設計方針を考え、文書を起こし、レビュー・承認し、修正し、その都度ある程度の判断痕跡が残っていました。
ところがAIを使うと、その途中工程のかなりの割合をスキップして、自然言語の指示から試行錯誤の痕跡を残さずに"それらしい成果物"が短時間で出てきます。
これにより生産性は向上しますが、同時に、人間の判断が表に出る回数が減る ということでもあります。
ここが単なる効率化では済まないポイントになり得ます。
「AIを使った開発」は一種類ではない
ここで「AIを使った開発」と一括りにすると、課題の本質に向き合うのが難しくなります。
システム開発の現場によって、AIの使い方にはかなり差があるかと思います。
少なくともざっくりと次の3つに分けて考えた方がよいと思っています。
1. AI支援型
従来の要件・設計・実装・テストの流れ・成果物は維持したまま、成果物の作成をAIで速める型です。
コード補完、設計書の叩き台、テストケース案、レビュー補助などがここに入ります。
2. AI圧縮型
人間が確認する設計書や仕様書を一定程度省略し、自然言語の指示や会話ベースで開発を進める型です。
明示仕様の厚みを減らし、その代わりにAIとの対話や短い指示で開発を進めます。
3. AI委任型
設計、実装、修正提案、場合によってはPR作成まで、かなり広い範囲をAIに委ねる型です。
人間は逐一手を動かすより、方向付けや承認に比重を移します。
この分類が大事なのは、「AIを利用したか」ではなく、「AIへの委任度」と、「中間成果物の省略度合い」によって、品質管理上の難しさが変わる からです。
GitHubが2025年に spec-driven development を前面に出しているのも、この問題意識が念頭にあると考えられます。GitHubは、いわゆるバイブコーディングがプロトタイプには向いていても、既存コードベースの改修やミッションクリティカルな開発では信頼しにくいと言及しており、仕様を「後から書くドキュメント」ではなく、実装・検証の基準になる共通のソースとして扱うべきだと整理しています。
余談になりますが、ウォーターフォールを長年経験してきた方にとっては、「仕様駆動開発」というワードに大きな違和感を覚えるのではないでしょうか。「仕様を書かない開発なんてあり得るのか？」と思うはずです。恐らくAIの文脈においては、「AI向けに最適化したドキュメント形態や、そのドキュメントを整備するためのツールを中心に据えた開発」だと認識しています。
APIであればOpenAPIで外部仕様と実装を連動させたり、インフラであればTerraformの記述と実環境を連動させるようなものかと思っています。
外部への振る舞いを固定して、中身はAIにある程度自由に開発させよう、というレベル感でしょうか。
類型が違えば、表に出る課題も変わる
AI活用で何が問題になるかは、先ほどの3類型でかなり変わると思います。
AI支援型で起きる課題
AI支援型では、従来の開発プロセスはまだかなり残っています。
要件定義も設計もレビューゲートも、従来通り存在します。
3類型の中ではもっとも導入しやすく、品質管理も従来の延長で回しやすい類型です。
そのため一見すると安全に見えますが、品質責任を負うマネージャーはレビューの進め方をよく考えるべきです。
この進め方でまず起こりがちなのが、成果物の生成速度（スループット）に対して、管理の速度が追いつかなくなり、結果としてレビュー密度が薄くなる ことです。
AIにより設計の叩き台も、テスト観点も、コード差分も、以前よりはるかに速く大量に出せます。
設計書らしきものはあるし、テストケース案もある、レビューコメントも付いている。
しかし、それらが短時間で一気に量産されるため、成果物間の整合性を深く追う余裕がなくなります。
結果として起きているのは、レビュー密度の低下 です。
沢山のそれらしい成果物が量産されると、管理者やリーダーの認知能力がボトルネックになりがちです。
こういった人間の認知能力の限界については、大規模プロジェクト運営においてはきちんと対策されるかと思いますが、AI開発においても同様に、プロジェクト計画段階でよく課題の見極め、対策を練っておくべきです。
GitHub Copilot のコードレビュー機能も、人間レビューを置き換えるものではなく補助であると明示されていますし、複雑で大きな変更では見落としや誤検知の可能性があることもドキュメントに書かれています。つまり、AI支援型は「安全」なのではなく、人間が最終確認を担い続ける前提でのみ成立する型 です。 (GitHub Docs)
そのため、AI支援型で特に重要になるのは、変更を人間が追える単位に保つことです。
AIは短時間で大量の差分を生成できますが、レビューと受入れは依然として人間の認知能力に制約されます。
したがって、
1回の変更で何を変えるのかを絞る
レビュー可能な大きさに差分を分割する
ロールバックしやすい単位でマージする
といった、従来からある基本原則が、AI時代にはむしろ重要になります。
AI圧縮型で起きる課題
AI圧縮型になると、課題が本質的に変わります。
この開発手法では、設計書や詳細仕様書を厚く作らず、自然言語の指示や対話でコンテキストを埋めて、実装を進めます。
結果として実装工程そのものは非常に速く進みます。
一方で、何が確定仕様で、何がその場の補完なのかが曖昧になりやすい です。
この型で起きやすいのは、後から見たときに、
- なぜその設計になったのか
- 何を制約条件としていたのか
- どこまでが人間の意思決定だったのか
- 何をもって受け入れるべきなのか
が見えにくくなることです。
GitHubが spec-driven development を打ち出した背景にも、この難しさがあります。AIにコードを書かせること自体はできる。しかし、曖昧な指示のまま進めると、意図の取り違えやアーキテクチャ上の不整合が起きやすい。だからこそ、仕様を共通の基準として前に置く必要がある、という整理です。 (The GitHub Blog)
AI委任型の開発において、「中身を書けるかどうか」より「何を制約として書かせるか」が重要になっていることを示しています。 (The GitHub Blog)
いずれにしても「どれだけAIを利用しているか」という事実は本質的ではありません。
我々が見るべきは、どこまでAIに任せ、何を人間が承認したか です。
AI圧縮型で問題になるのは、AI支援型の様な人間がボトルネックになる事ではありません。
承認の根拠が分からなくなる ことです。
設計書が省略されること自体が問題なのではなく、設計判断の条件までが曖昧になることが問題です。
この型では、「システムが動くか」ではなく、「それを合格としてよいと言えるのか」の判断が難しくなります。
たとえば、
- この機能は何を満たせば完了なのか
- 非機能要件はどこまで保証対象なのか
- 例外系はどこまで考慮済みなのか
- 仕様変更と実装都合の線引きはどこか
こうした判断基準が曖昧なまま開発が進むと、
動くものはできても、後から保守・障害対応・追加改修の局面で説明出来ないシステムとなります。
AI委任型で起きる課題
AI委任型まで進むと、さらに課題の質が変わります。
この開発手法においては、AIは単なる補助役ではなく、かなり広い範囲でAIが主体的に変更を行う存在になります。
設計、実装、テスト、修正、プルリクエスト作成までをAIが担い、人間は最終的に出来上がったシステムの稼働確認や受入れのみを担います。
この型で難しいのは、個々の成果物の品質だけではありません。
そもそも何をAIに任せてよいのか、誰がどこまで責任を持つのかが曖昧になりやすい ことです。
最近の研究でも、AIエージェントが生成したPRは人間起点のPRより受け入れられにくい傾向があること、AIによるPRに特有の却下要因が観測されることが報告されています。また、レビュー関連の特徴が人間PRと AI PR で異なる影響を持つことも示されています。つまり、AI委任型では「差分があるからレビューすればよい」という発想だけでは不十分で、レビューそのものの設計が変わる と見るべきです。 (arXiv)
AI委任型の難しさは、AIの精度だけでは説明できません。
本質は、委任範囲と責任境界を設計しないまま運用すると、成果物レビューだけでは統制不能になる ことです。
それでも共通して難しくなるものがある
ここまで、3類型ごとに課題を見てきました。
支援型・圧縮型・委任型で、確かに表に出る問題は違います。
ただ、それでも最後は似たところに収束します。
それは、人間の承認責任は残るのに、その設計根拠が残りにくい ということです。
AI支援型では、量が増えることでレビューが浅くなる。
AI圧縮型では、仕様や設計判断が希薄になり承認根拠が弱くなる。
AI委任型では、委任範囲と責任境界が曖昧なまま、大量の変更を人間が追うことになる。
AIの関与度合いは違っても、共通しているのは、
「何を根拠に、この成果物を通してよいと言うのか」が難しくなる ことです。
一昔前の「AIはハルシネーションするから危ない」という議論とは異なる段階に移行しています。
ただ、その論点が消えたわけではないですし、実際 GitHub のドキュメントでも、AIレビューには見落としや誤検知、誤った提案の可能性があると明示されています。AWS も 2025年8月に、生成AIの出力を業務ルールや知識に照らして検証する Automated Reasoning checks を一般提供し、ハルシネーションや曖昧性を単なる“注意喚起”ではなく検証対象として扱う方向を打ち出しました。つまり、精度問題は依然として存在する状況です。 (GitHub Docs)
ただ、2026年の実務感覚としては、そこだけを主題にしても足りません。
いま顕在化しているのは、AIが間違うかどうか ではなく、もっともらしい成果物が高速・大量に出てくる世界で、人間がどう管理し、どう承認するか です。
AI時代に、従来以上に重要になる「変え方」の設計
AI時代の品質管理では、「何を作るか」と同じくらい、「どう変えるか」が重要になります。
AIは、実装量を増やすこと自体は得意です。
しかし、変更量が増えるほど、レビュー、受入れ、ロールバック、影響範囲の把握といった統制側の負荷も増えます。
そのため、AI活用が進んだ現場ほど、
- 変更を小さく保つ
- 意図と制約を先に明示する
- 高リスク変更は人間レビューを厚くする
- 何を根拠に承認したかを残す
という、ある意味では地味な運用設計が、結果として品質を左右します。
AI時代の品質管理とは、派手な自動化の話というより、高速化した開発を統制可能にする設計の話 だと私は考えています。
品質を守るために何を再設計すべきか(後編へ)
前編では、AIによって開発プロセスそのものが変わり、しかもその変わり方は一様ではないことを整理しました。
- AI支援型では、管理が追いつかなくなる
- AI圧縮型では、承認の根拠が曖昧になる
- AI委任型では、委任範囲と責任境界の設計が必要になる
そして、それでも最後には、
人間が何を根拠に承認するのか
という問題に行き着きます。
後編では、この問題に対して、実務として何を再設計すべきかを考えます。
焦点は次の3点を予定しています。
- 委任範囲
- 証跡
- 承認
加えて、それらを現場で実際に機能させるための具体策として、
AIを制約・検証・承認の枠組みの中で動かす「ハーネス」
についても扱う予定です。
AI任せでも品質は守れるのか、
私は 守れる と思っています。
それはAIが賢いからではなく、
人間が、委任・証跡・承認の構造を設計し直し、それを現場で機能させる仕組みまで整えるからです。
コンサルタントとの30分無料相談のご案内
AIを活用した開発は、要件整理・設計・実装・レビューの速度を大きく高めます。
一方で、開発が速くなるほど、どこまでAIに任せるのか、何を人間が確認するのか、どの証跡を残すのかを明確にしておかなければ、品質管理が属人的・場当たり的になりやすくなります。
もし現在、
- AIを開発工程に取り入れたいが、進め方や管理方法に不安がある
- 要件定義・設計・実装・レビューのどこにAIを使うべきか整理したい
- AIで開発スピードは上がったが、品質やレビューの統制に課題を感じている
- 委任範囲・証跡・承認ルールをどう設計すべきか相談したい
という場合は、まずは専門家と30分ほど壁打ちし、現状の課題と次に決めるべき論点を整理するのが有効です。
弊社では、AI時代のシステム開発・品質管理に関する30分の無料相談を承っています。
現状の開発体制や課題感をお伺いした上で、AI活用の進め方、品質管理上のリスク、整備すべきルールやプロセスについて、実務目線で整理します。
AIを活用した開発体制や品質管理の進め方に不安がある方は、お気軽にご相談ください。
