はじめに
生成AIによって、ソフトウェア開発の速度は明らかに上がっています。
実装、調査、テストコードの生成、ドキュメント作成、リファクタリングなど、これまで人間が時間をかけていた作業の多くを、AIが支援、代替できるようになり、企業としても代替に動くのが2026年の中心的な動きになると思います。
「作ること」のコストは今後さらに下がっていくと思います。しかし、作るコストが下がったからといって、良いソフトウェアが増えるとは限りません。
むしろ、不要な機能、曖昧な仕様、保守しづらいコード、誰にも使われない画面も、これまで以上の速度で生まれていく可能性があります。
生成AIは、能力の増幅器です。
良い設計、良い問い、良い判断を増幅する一方で、曖昧な仕様、浅い理解、間違った判断も増幅します。
だからこそ、AI時代に重要になるのは、単に作る力ではありません。
何を作るべきか。
作ったものは期待を満たしているのか。
そもそも、その期待は正しいのか。
仕様、UX、実装、内部品質、運用、事業成果まで含めて、継続的に検証する力が重要になります。
この記事では、AI時代の開発組織において、なぜ「検証」がこれまで以上に重要になるのかを考えます。
AIが速くするのは主に「製造」である
生成AIが速くしているのは、主に製造の領域です。
コードを書く。既存コードを読む。テストコードを生成する。ドキュメントを書く。エラーの原因を調べる。
こういった作業は、AIによって確実に速くなっています。
実装方針が決まっていて、既存の設計やルールが整理されている場合、AIはかなり強力です。人間が細かい実装を一つずつ書くよりも、AIに実装させ、人間がレビューし、修正方針を伝える方が速い場面は増えています。
しかし、ここで勘違いしてはいけません。
AIが速くしているのは、あくまで「作ること」です。従来、ソフトウェアエンジニアはコードを書きながら、ドメインに対する理解を深め、よりブラッシュアップをしてきましたが、そのループそのものが失われつつあります。
その機能に価値があるのか。その仕様で本当にユーザーの課題が解決されるのか。その実装は中長期的に保守できるのか。その変更によって運用やサポートの負荷は増えないのか。その機能はそもそも作るべきなのか。
これらは、コードが速く書けるようになっただけでは解決しません。つまり価値や品質は自動では保証されません。
むしろ、製造能力だけが上がると、間違ったものを高速に作るリスクが増えます。
だからこそ、開発組織においては生成AIによる効率化から、今後はプロダクトの「検証能力」に重点が変わっていくと考えています。
そもそも品質とは何か
品質という言葉は、しばしば「バグが少ないこと」として扱われます。
少なくとも社内や周辺で品質に対する話が通じる人は1割もおらず、ソフトウェア品質に対する認識がまだまだ広まっていないと感じています。
もちろん、バグが少ないことは重要です。期待通りに動かないソフトウェアは、品質が高いとは言えません。
しかし、品質をバグの少なさだけで捉えると、AI時代の開発を見誤ります。
私が考えるに、品質とは「誰かにとっての価値を満たしている状態」だと思います。
ユーザーにとっては、課題を解決できることが品質です。運用者にとっては、問い合わせや障害対応が少なく、安定して運用できることが品質です。開発者にとっては、変更しやすく、理解しやすく、壊れにくいことが品質です。事業にとっては、売上や継続率、顧客満足度につながることが品質です。
つまり品質は、リリース前にテストケースを消化すれば保証できるようなものではありません。
市場、課題、仕様、UX、実装、内部品質、運用、事業成果まで含めて、期待との差分を見続ける必要があります。
この意味で、品質保証は単なるテスト実行ではありません。どちらかというと、私がテストを専門にしている人に期待するのは、「探索」です。
にもかかわらず、現場では品質保証が「リリース前の確認作業」に縮小されていることがあります。
これはかなり危険です。品質を最後に確認するものだと考えている限り、開発速度が上がれば上がるほどQAはボトルネックになります。
そして、AIによって開発速度が上がる時代には、その限界がより早く露呈すると思います。というより、2026年時点ですでに臨界点は超えてしまっており、こういった組織が残っているのは単に組織として遅れているからだと思っています。
現状のテストは「確認」に寄りすぎている
直近でこの記事のようなことを考え始め、ソフトウェアテストに関する書籍にいくつか目を通しましたが、体系的なテスト手法的な本はほとんどが理論的ではあるものの実際のソフトウェア開発から大きく乖離していて、leanやアジャイルといった現代主流の手法との相性が悪く、使い物にならない印象を受けています。
つまり現状のテストやQAの議論は、まだ「確認」に寄りすぎていると感じています。
仕様通りに動くか。画面に崩れがないか。テストケースを何件消化したか。リリース前にどれだけ確認したか。
こういったテストケースを消化しても、そもそもの仕様が間違っていれば意味がありません。画面の表示崩れを指摘しても、ユーザーに価値のない機能であれば意味がありません。リリース前に丁寧に確認しても、運用負荷が高すぎる設計であれば品質が高いとは言えず、そもそも利用者がほとんどいない画面を確認したとしても価値はないです。
本来、テストやQAは「仕様通りに動くか」を見るだけではなく、「その仕様でよいのか」「どこに品質リスクがあるのか」「何を検証すべきなのか」を考えるべきだと考えています
後工程で流れてきたものを確認するだけのQAはその職能の価値を自ら狭めていると思います。
ダブルチェック型QAは、すでに限界を迎えている
後工程で確認だけを担うQAは、すでに限界を迎えています。
開発者が実装し、QAがリリース前にまとめて確認する。
このダブルチェック型のQAは、開発速度が上がる前から多くの現場でボトルネックになっていました。
AIによって、その問題がより見えやすくなっただけです。
単純な画面確認、正常系の操作確認、入力チェック、主要導線のリグレッション確認。
こうした作業の多くは、すでにPlaywrightのようなE2Eテストツールで自動化できます。
さらにAIを使えば、テスト観点の洗い出し、テストケース作成、Playwrightのコード生成まで支援できます。
もちろん、AIやPlaywrightですべての品質を保証できるわけではありません。
しかし、「人間が画面を開いて、毎回同じ手順をなぞる」ような確認作業は、もう人間がやるべき中心業務ではありません。
問題は、人間がやらなくてよい確認作業を、人間にやらせ続けていることです。
そして、それを品質保証だと思い込んでいることです。
今やっているQA作業がAIによるテスト設計によってユニットテストとE2Eテストで十分なカバレッジがあり自動でテストが行われるようになっても残るかどうかを考えるべきです。
つまり、これからはQAはテストを実行する人ではなく、検証を設計する人になるべきで、具体的に求められるのは自動テストでは見つけにくい仕様の矛盾、UXの違和感、運用上の破綻、権限やデータ整合性のリスクを見る力です。
ダブルチェック型QAが担っていた多くの確認作業は、AIと自動化に置き換えます。だからこそ、人間のQA/QEは、置き換えられない領域に移らなければなりません。
仕様通りに動くかを見るだけではなく、そもそもその仕様でよいのかを問う。
テストケースを消化するだけではなく、どのリスクをどの手段で検証するのかを設計する。
ここまで踏み込めないQA組織は、AI時代には全て置き換えられます。大抵の組織では開発チームによって。
QAはプロダクトチームに埋め込まれるべきである
今後、QA/QEの役割はプロダクトチームにより深く埋め込まれていくべきだと思います。品質は最後に確認するものではなく最初から設計するものです。
そのためには、QA/QEが開発の後工程にいるのでは遅すぎます。
企画段階で、その機能が何を満たすべきかを見る。仕様策定の段階で、曖昧さやリスクを指摘する。設計段階で、テストしやすさや運用しやすさを見る。実装中に、検証観点を開発者とすり合わせる。リリース後に、実際の利用状況や問い合わせを分析する。
ここまで関わって初めて、品質に責任を持っている、品質を保証、管理できているといえる状態になります。
QAがプロダクトチームから離れた場所で、最後にまとめて確認するだけであれば、その組織はボトルネックになり、組織である価値はすでにないです。
開発者、PdM、デザイナー、QA/QEが一緒に品質を作る形に変わるべきです。
QAは最後の門番ではなく、ソフトウェアが作成される工程すべてを監視し、品質リスクを設計する人です。
AI時代には、不要なものも高速に作れてしまう
ここからは開発に対する懸念点ですが、作るコストが下がると、作る判断のハードルも下がります。
これはかなり危険です。
これまでは、実装に一定のコストがかかるため、「本当に作るべきか」を考える機会が自然にありました。
しかし、AIによって実装コストが下がると、とりあえず作る判断が増えます。
すぐ作れるなら作ってみよう。AIに投げれば一旦できそう。あとで直せばいい。
こういう判断が増えます。
もちろん、試作が速くなること自体は良いことです。プロトタイプを作り、仮説を検証し、学習速度を上げることには価値があります。
しかし、検証されないまま作られたものは、単なる負債です。
不要な機能。曖昧な仕様。誰も使わない管理画面。一度作ったものの消せないオプション。保守しづらいコード。運用者だけが苦労する例外処理。
これらも、AIによって高速に作れてしまいます。
だからこそ、QAやテストの役割は「作られたものを確認すること」だけでは足りません。
本当に作るべきなのか。作るなら何を満たすべきなのか。どこに失敗のリスクがあるのか。どうなれば価値があったと言えるのか。
そういった問いを立てる必要があります。私が今年重視したいのは、こういった「良い問い」を立てる活動とそのスケールです。
会社組織は中央値重視から、レバレッジ重視へ変わる
また、組織構造もここから数年で大きく変化させるべきだと思います。
日本の会社組織は、これまで中央値を上げることに強かったと思います。
一定の教育を行い、ルールを整備し、標準化し、多くの人を平均的な能力に近づけていく。
これは日本式の組織の強みでもありました。属人性を減らし、誰が担当しても一定の成果を出せる状態を作ることには価値があります。
しかし、AI時代には、この中央値重視の組織設計だけでは厳しくなります。
なぜなら、AIは平均的な人の能力を底上げするだけではなく、能力の高い人により大きなレバレッジをかけるからです。
つまり、報酬や制度としてもこのレバレッジを考慮して是正しない限り、ジュニアを育成する合理性が生まれなくなり、組織としてゆるやかに終わりに近づいていきます。
これはQAやテストの領域でも同じです。AIによってテストケースの生成や観点出しは速くなります。しかし、何を検証すべきかを判断する力がなければ、AIを使っても表面的なテストが増えるだけです。
レベルの高い人は、AIを使って品質リスクの洗い出し、テスト戦略の設計、仕様レビュー、リリース後分析まで広げていけます。
検証能力の高いQA/QEの価値をさらに高め、確認作業に閉じたQAの価値を相対的に下げます。
だからこそ、組織はQAチーム全体の人数や稼働率を見るのではなく、検証能力を持つ人にどうレバレッジをかけるかを考えるべきです。
開発者にも検証能力が求められる
検証能力は、QAだけに必要なものではありません。
AI時代には、開発者にもこれまで以上に検証能力が求められます。
AIが生成したコードを評価する。テスト観点を設計する。仕様の曖昧さに気づく。保守性や運用性を見る。セキュリティリスクを見抜く。作らない判断をする。
これらは、AIに実装を任せるほど重要になります。
AIが生成したコードは、一見それっぽく動きます。テストも通り、画面も動くかもしれません。
しかし、境界値が抜けていたり、ドメインルールを誤解していたり、既存の設計方針に合っていなかったりすることがあります。
だからこそ、人間側に検証能力が必要です。
QAが最後に見つけてくれるからよい、という考え方はもう通用しません。
AI時代の品質は、QAだけで守るものではありません。開発者自身も、品質に責任を持つ必要があります。
品質保証から価値検証へ
品質を「誰かにとっての価値」と捉えるなら、市場検証も品質の一部です。
どれだけバグが少なくても、誰にも使われない機能に価値はありません。きれいに実装されていても、ユーザーの課題を解決していなければ、良いソフトウェアとは言えません。
だから品質保証は、単に不具合を見つける活動から、価値を検証する活動へ広がっていく必要があります。
プロトタイプを作る。ユーザーに触ってもらう。A/Bテストを行う。ログや問い合わせを分析する。使われていない機能を消す。
これらも広い意味では、品質に関わる活動です。
AIによってプロトタイプ作成のコストは下がります。しかし重要なのは、作ることではなく、そこから何を学ぶかです。
何が分かれば次に進むのか。どの指標を見て判断するのか。どの結果ならやめるのか。
この設計がなければ、AIによって試作品が増えるだけです。
AI時代に必要なのは、作る速度ではなく、学習する速度です。そして学習するためには、検証が必要です。
2026年以降の開発組織がやるべきこと
2026年以降の開発組織は、まず品質を定義し直す必要があります。
品質を「バグが少ないこと」だけに閉じてはいけません。
ユーザー、運用者、開発者、事業にとっての期待を満たすこととして捉え直す必要があります。
そのうえで、QAの役割も見直すべきです。
- QAを最後の確認係として扱うのをやめる。
- QAを品質リスクの設計者として位置づける。
- QAをプロダクトチームに埋め込む。
- テストケースの消化数ではなく、どのリスクを下げたのかを見る。
- リリース前の指摘数ではなく、リリース後の学習や改善につなげる。
また、AI生成物の検証ルールも整備するべきです。
- AIが生成したコードをどうレビューするのか。
- どのテストを必須にするのか。
- どの領域では人間の確認を強めるのか。
- セキュリティや個人情報、権限まわりをどう扱うのか。
- AIに任せてはいけない判断は何か。
こうしたルールがないままAI活用だけが進むと、開発速度は上がっても品質リスクは増えます。
そして、作らない判断を評価することも重要です。
AI時代には、作ることはどんどん簡単になります。
だからこそ、作らない、消す、簡素化する、検証してやめる、といった判断に価値があります。
作った量だけを評価する組織は、AIによって負債を増やします。
これから評価すべきなのは、作った量ではなく、不要なものを作らずに済ませた判断です。
おわりに
AIによって、ソフトウェア開発の製造能力は上がります。
しかし、製造能力が上がるほど、検証能力の重要性も上がります。
- 何を作るべきか。
- その仕様でよいのか。
- どこに品質リスクがあるのか。
- 作ったものは期待を満たしているのか。
- 出した後に価値はあったのか。
これらを問い続けられない組織は、AIによって速くなるのではなく、速く壊れていくと思います。
QAやテストは不要になるわけではありません。
むしろ、重要になります。
ただし、それは最後に確認するQAではありません。テストケースを消化するだけのQAでもありません。
AI時代に必要なのは、品質リスクを見抜き、検証を設計し、開発全体にフィードバックできるQA/QEです。
そして、開発者自身も検証能力を持つ必要があります。
検証力を持てるかどうかが、これからの開発組織の差になると思います。
