AI駆動開発の品質はどこで決まるか、リスク回避のために発注前に確認したい設計とレビュー
生成AIが実務に入ってきて、開発のスピードは大きく変わりました。以前なら数週間かかっていた初版のリリースが、驚くほど短い期間で「動くもの」として形になります。これは開発の現場にとっては明らかな進歩です。
そのうえで、一つ押さえておきたい区別があります。AIでコードを生成できることと、そのコードを顧客の本番環境に出してよいと判断できることは、別の能力です。前者は各種AIツールが担えるようになりました。後者は、いまも人の側に残っています。
この記事では、その区別がどこにあるのか、区別を意識しないまま進めた場合に何が起きるのかを整理します。あわせて、開発会社を選ぶときにAIの使い方をどう確認すればよいか、すでに動いているシステムに不安があるときにどこから手をつければよいかもまとめました。
システム開発をお考えなら、
私たちEnlytにご相談ください。お客様の業務構造・ご要望・目的を深く理解してご提案いたします。私たちがどんな仕事をしているか、実績やサービスをご覧ください。
目次
AIで実装が速くなっても、設計とレビューの責任は残る
ソフトウェアの品質は、これまで大きく2つの人の工程によって支えられてきました。
- 設計 何を、どういう構造で作るのかを決める工程
- レビュー 書かれたコードの意図と妥当性を、書いた本人以外が確認する工程
生成AIは、この2つに挟まれた実装を大きく速くしました。設計で決めたことをコードに落とす作業、既存のパターンをなぞる作業、定型的な処理を書く作業。これらの実装作業が確かに短縮されています。
実装だけでなく、設計とレビューにも、AIは使えます。設計の選択肢を洗い出す、抜けている観点を挙げさせる、コードの気になる点を指摘させる。こうした使い方で、この2つの工程も速くなります。
変わらないのは、最終的に判断する責任がどこにあるかです。この構造で将来の変更に耐えられるか。この実装を本番に出してよいか。AIの出力を採用するかしないか。これらは、事業の文脈と既存システムの事情を踏まえた判断であり、判断した結果に責任を負う人が要ります。
そしてこの判断には、前提として技術力が要ります。生成されたコードを読んで、意図どおりか、副作用はないか。生成されたコードを確認して気付けないと、AIの出力をそのまま採用することになり、判断の工程が形の上でしか存在しなくなります。
調査データが示す、AIの効果を左右する開発体制
ここまでの話は感覚論ではなく、公開されている調査からも読み取れます。
Googleが公開している2025年 DORAの「AI支援ソフトウェア開発の現状」調査では、AIの活用度が高い組織ほど、ソフトウェアデリバリーのスループットが上がると同時に、不安定さも上がるという関係が報告されています。ここで重要なのは、この調査がAIを増幅器として位置づけている点です。もともとテストや開発体制が整っている組織ではAIが成果につながり、整っていない組織では弱点の方が拡大される。速さと品質が必ず引き換えになるという話ではなく、土台の状態が結果を分ける、という整理です。
同じ調査では、生成されたコードをほとんど、あるいはまったく信頼していないと答えた開発者が3割ほどいた一方で、8割以上が生産性は上がったと感じている、という結果も出ています。生産性への評価が高い一方、生成コードへの信頼には課題が残っている状態です。
コードそのものについても調査があります。セキュリティ検査を手がけるVeracodeが2026年に公開したGenAI Code Security Reportでは、複数のAIモデルに、特定の脆弱性が入りやすいコード生成の課題を解かせて、対象とした脆弱性の検査に合格した割合を測っています。結果は56%で、前年の55%からほとんど変わっていません。脆弱性の種類によって成績には大きな差がありました。
この数字の読み方には注意が必要です。これは検査用の課題に対する合格率であって、実際の製品全体の安全性を示すものではありません。レポート自体も、検査ツールや人のレビューを組み込んだ実際の開発環境での検証ではないと明記しています。つまりこの数字が示しているのは「AIのコードは危ない」ということではなく、確認する仕組みを置かなかった場合に何が残りうるかです。裏返せば、AI活用の前後に技術力のある人と仕組みを置けるかどうかが、開発会社の差になります。
設計・レビュー不足の問題は、リリース後に表面化する
ここが今回の要点です。設計とレビューを省いても、初版のリリースまではたどり着けてしまいます。とりあえずは動くからです。
そして、初版のリリース時の動作確認では見つからず、機能追加や障害対応、担当者の交代をきっかけに表面化する問題があります。一箇所直すと想定していなかった場所に影響が広がる、調べようとしてもなぜそう書かれているのかがわからない、といった形です。
次のような違和感が出ていたら、確認してみる価値があります。
- 小さな修正を入れるたびに、関係のないはずの機能で不具合が出る
- 「ここは触らないでください」という箇所が、理由の説明なしに増えていく
- 担当していたエンジニアが変わると、誰も仕様を説明できなくなる
- 設計書や構成図がない、あるいはあっても現在の実装と合っていない
- 見積りを頼むと、規模のわりに調査の工数が大きく積まれる
これらはAIを使わない開発でも起こる問題で、症状だけでAIが原因とは判断できませんが、設計・検証・引き継ぎの状態を確認するきっかけにはなります。
最後の項目について補足します。あとから読み返すことを考えないままAIで大量のコードを書き、しかもその中身を読み解ける人がいない。この状態のシステムに手を入れるときは、まず「どこに何が書かれているのか」を調べるところから始めることになります。修正そのものは小さくても、その前の調査に時間がかかります。
開発会社の見積りには、この調査の時間が乗ります。機能を一つ足すだけなのに想定より高い金額が出てくる背景には、こうした事情がある場合もあります。安く早く作った分の負担が、あとから運用と改修の費用として戻ってくる、という形になります。
Enlyt（エンライト）でも、お客様から「周りで同じようなことが起きている」というお話を伺うことがありました。遠い世界の話ではなく、身近なところで起き始めている問題だと感じています。
なぜ、後になってから問題が出てくるのか
初版のリリースでは見えず、後から違和感が実際の問題となって出てくるのですが、この時間差には、大きく2つの理由があります。
コードは残っても、判断の理由は残らない
コードは「何をしているか」を示しますが、「なぜそうしたか」までは示しません。あとから修正する人は、理由がわかれば「ここは変えてよい」「ここは変えられない」と判断できますが、理由がなければ毎回コードから推測することになります。
そのため、設計で何を判断したかは、設計書や構成図、コミットの記録などに残しておく必要があります。AIでなく、人が判断していても、記録がなければ後から確認できませんのでAI特有というわけではありません。AIで一気に実装を進めた場合も、提案された構造やコードをなぜ採用したのかを記録しなければ、後から判断の根拠をたどれなくなります。システム全体の関係を一枚で示す資料も同じ役割を持ちます。構成図については「Webアプリケーション構成図とは？基礎から作成ポイント・作成ステップまで解説」で整理しています。
影響範囲がわからないまま手を入れることになる
ある処理を直したとき、どこに影響が出るのか。これは全体の構造を理解していないと判断できません。生成されたコードをつなぎ合わせて作った場合、似た処理があちこちに散らばっていたり、同じデータを別の場所で別の形で持っていたりすることがあります。片方だけ直すと、もう片方との整合が崩れます。
開発会社に、この質問をしてみてください
これから開発を依頼する場合、避けるべきなのは「AIを使っている会社」ではありません。AIを使っているかどうかだけでは品質は判断できませんし、使わないことが品質の保証になるわけでもありません。
確認したいのは、その会社がAIをどう位置づけているかです。次の質問が起点になります。
「開発のなかで、AIをどのように使っていますか」
この質問への答えは、大きく2つに分かれます。この質問で確かめたいのは、AIの提案を人が評価して採用しているのか、十分に確認せず任せているのか、という点です。この違いが、初版のリリース後の安定性を左右します。
使う工程と人が判断する工程を、理由とあわせて説明できる会社であれば、区別ができているとわかります。「全面的に活用しています」で説明が終わってしまう場合は、もう少し踏み込んで聞いてみてください。
もう少し具体的に確認したい場合は、次の4つの質問が役に立ちます。
- 生成されたコードは、書いた本人以外の誰かがレビューしますか
- 本番へのリリースは、誰が承認しますか
- 設計の内容は、どのような形で残りますか
- 担当者が変わっても引き継げる状態になりますか
正解を暗記しているかを試す質問ではありません。自社の進め方として言葉にできるかどうかを見るための質問です。説明に加えて、共有可能な範囲でレビュー記録や設計資料の例を見せてもらうと、実際の進め方を確認しやすくなります。
費用の比較だけで決めると、この部分は見えません。安く早く出せることと、出した後に安定して育てられることは、別の能力だからです。依頼先の選び方全般については「Webシステム開発とは？基礎知識から費用、依頼先の選び方まで解説」もあわせてご覧ください。
すでに動いているシステムに不安があるとき
いま動いているシステムのことが気になった方もいるかもしれません。その場合も、いきなり作り直す必要はありません。次の順番で進めます。
1 現状を把握する
構成、使っている外部サービス、データの持ち方、資料がどこまで残っているかを確認します。資料がない場合は、動いているものから読み解いて資料の側を作ります。この段階で、漠然とした不安が具体的な項目に変わります。
2 優先順位をつける
把握した内容を、放置できないもの、次の開発の前に直したいもの、当面はこのままでよいものに分けます。事業への影響と、直すのにかかる手間の両方で判断します。
3 段階的に直す
優先度の高いところから、動かしながら順に手を入れます。全面的な作り直しは、どうしても必要な場合の選択肢として最後に置きます。
Enlytでは、他のベンダーが開発したプロダクトの引き継ぎにも対応しています。現状の把握から運用の整理、改善の方向性の検討まで、資料が足りない場合の仕様の読み解きと資料化も含めて対応しています。詳しくはプロダクト・システム運用保守サービスのページにまとめています。
AIが原因の問題を扱った事例ではありませんが、他社から開発を引き継いだ例として「BtoBマッチングサービスの開発事例」があります。開発の途中で別のベンダーとのやりとりが進まなくなったバックエンドを引き取り、すでにできていたデザインの資産を活かす形で完成させました。手を入れる範囲を絞ることで、費用と期間の両方を抑えた進め方です。
Enlytでは、AIをどこに置いているか
Enlytも、実装にAIを使っています。国内のPMと海外の開発チームを組み合わせた体制にAI駆動開発を合わせることで、費用と期間を抑えることを提供価値の一つにしています。
そのうえで、AIによるスピードの恩恵を活かしながら、設計とレビューは人の目と経験で担保することを続けています。開発はアジャイルの手法で進め、定期的なレビューとフィードバックを挟みながら形にしていきます。ここでいうレビューには、お客様と成果物を確認する場と、技術者がコードの内容を確認する工程の2つがあり、役割が異なります。前者は作るものが合っているかを、後者は作り方が妥当かを確かめる工程です。
設計を先に置いているのは、実装が速くなったからこそ、その前段が結果を左右するからです。Enlytの進め方は受注前と受注後に分かれていて、受注前の段階で、やりたいことを機能と構成に落とし込む「要件まとめ」を作り、概算見積りと提案書をお出しします。何を作るかが曖昧なまま実装に入ると、AIで速く作れる分だけ、方向のずれも速く積み上がるためです。
誰がどこまで確認し、どこまでを資料として残すかは、システムの性質や運用の体制によって変わります。ご相談の際に、その案件での進め方としてご説明します。開発の考え方や費用の見方をまとめた資料はお役立ち資料から、これまでの案件は開発実績の一覧からご覧いただけます。
まとめ
生成AIによって、開発のスピードは確かに上がりました。設計やレビューについても、AIを補助に使えば速くなります。
変わっていないのは、生成されたものを評価して、本番に出してよいと判断する部分です。ここを担える人がいるかどうかが、初版の後の安定性を左右します。そして、その差が表に出るのはリリースの後、機能を足すときや障害に対応するときです。
これから発注される方は、「開発のなかで、AIをどのように使っていますか」という質問を加えてみてください。AIの提案を評価して採用しているのか、十分に確認せず任せているのか。その違いが、リリース後の改修や運用に影響します。
すでに動いているシステムで、修正のたびに別のところで問題が出るといった状態が続いているようでしたら、現状の把握から一緒に整理できます。お気軽にご相談ください。
システム開発のこと、私たちEnlytにご相談ください！
お客様の業務構造・ご要望・目的の本質を深く理解し、要件が固まる前の「曖昧な状態」から並走し、 ズレを生まないコミュニケーション設計で、プロジェクトを成功に導いています。事例やサービス内容をご覧のうえ、ご相談やお見積りもお気軽にどうぞ。
