AI DevEx Conference 2026 登壇レポート
「AIの進化によって、テストエンジニアは不要になるのか？」
開発現場で生成AIの活用が急速に進むなか、このような問いも浮上しています。
本記事では、2026年7月22日・23日に開催され、SHIFTがダイヤモンドスポンサーを務めたイベント「AI DevEx Conference 2026 – Future of Development Productivity -」より、人気ポッドキャスト『fukabori.fm』のホストを務める岩瀬 義昌氏と、SHIFTでプロダクトマネージャー／エンジニアリングマネージャーを務める森川 知雄の対談をお届けします。
SHIFTが決算発表で語った「『人手中心のテスト業務』は、将来的になくなる可能性がある」という予測に対し、テストエンジニアの役割を3つのレイヤーに分けて具体的に紐解きながら、AI駆動開発（AIDD）の現場で実際に多発している”新たな炎上”のリアル、そしてこれからの時代に「人間にしかできない品質保証」の核心とは何かを語り合いました。
-
「fukabori.fm」 ホスト 岩瀬 義昌 氏
大手通信事業者にて、大規模IP電話システムの開発、内製、アジャイル開発、人事などの業務に従事後、現在はGenerative AI ProjectのLeaderを務める。『エンジニアのためのドキュメントライティング』『エレガントパズル』『エンジニアリングマネジャー入門』『エンジニアリングリーダー』『エンジニアリング戦略の作り方』などを翻訳。エンジニアに人気のポッドキャスト『fukabori.fm』も運営。
-
プロダクトマネージャー／エンジニアリングマネージャー 森川 知雄
中堅SIerにて品質管理業務としてテスト戦略から人材育成までを担当。 テスト自動化技術Seleniumに出会い、E2Eツールをスクラッチ開発し、コストを最大40%削減。以後、テスト自動化～DevOpsに光を感じ、2019年に新しい挑戦のできる環境を求めて株式会社SHIFTへジョイン。ソフトウェアテスト管理ツール「CAT」開発チームのマネジメントを手がけながらAIテストエージェント「ネムラナイ」プロジェクトにも携わり、AIエージェントを前提とした新しい品質管理工程・データ活用のプラットフォームの実現を目指して日々奔走している。
目次
SHIFTが予見する、テスト業務がなくなる未来
岩瀬氏：本日はよろしくお願いします。今日のテーマは、「AI駆動開発（AIDD）の時代、テストエンジニアは不要になるのか？」。
気になるこのテーマについて、SHIFTさんだからこそわかるリアルなお話をお聞きしたいと思います。
SHIFTさんは、先の決算発表で「人手中心のテスト業務は、将来なくなる可能性がある」といい切りましたよね。現場としては、どう思われましたか？
森川：経営陣としては、AIの進化を見据えれば、いずれそうなるという見立てがあったんだと思います。
岩瀬氏：SHIFTさんといえば、独自のスクリーニング検定で未経験者を大量に採用・育成し、圧倒的な人の数と体制でテスト事業を拡大されてきた背景がありますよね。
まさに人手で成長を牽引してきたSHIFTさんが「なくなる」といい切ったのは、業界的にも非常に大きなインパクトがあります。
森川：おっしゃる通りです。実際、いまやSHIFT単体でも数千人がテスト業務に携わっています。
もはや、人手だけに頼るビジネスモデルのままではいられない。IRで宣言しただけではなく、内部構造も変えようとしています。
現在、AI活用を軸にした大規模なリスキリングがはじまっています。また、新規採用もAIに特化した人材へとシフトしています。
岩瀬氏：育成に携わる方も今日は会場にたくさんおられるようですが、リスキリングって超難題ですよね。具体的にどう進めているんですか？
森川：まずは、生成AIへの適性を見極めています。要するに、プロンプトを上手く扱えるか、生成AIを制御できるかという点ですね。そのうえで適切な配置や、成長を促すわけですが、正直まだ模索中ですね。
岩瀬氏：適性がある人とない人では、何が違うのでしょう？
森川：「人に指示を出すのが上手いかどうか」というマネージャー適性と非常に似ています。自分の業務の目的や背景をきちんと言語化して説明できない人や「背中を見て学んで」というタイプは、生成AIを使いこなせない傾向にありますね。
LLMと画像解析技術がもたらす、“AI打鍵”の圧倒的ポテンシャル
岩瀬氏：では、具体的にテストエンジニアの役割はどう変わっていくのでしょうか。「なくなる」といっても、業務は多岐にわたりますよね。
森川：そのとおりです。私たちはテストエンジニアをざっくり３つのレイヤーに分けて考えています。
結論からいうと、ドメインエキスパートの重要性は引き続き高いと考えています。真ん中のテスト設計者は、必要ですが役割が大きく変わります。そして一番下の打鍵者は……AIへの置き換えがもっとも進む領域だと考えています。
岩瀬氏：私は自動化オタクなので、「E2Eテストを組んで自動化すればいいのに」とつねづね思っていました。なぜこれまで、手動の打鍵テストがなくならなかったのでしょうか？
森川：コストと予算の壁があるからです。E2Eテストを組んで自動化するには、それなりの投資や運用コストがかかります。一方で、手動で打鍵してもらう方が、投じられるコストとしては安く済むケースが多かったんです。
岩瀬氏：それが、いよいよAIに置き換わるんですね。具体的にAIはどうやって打鍵するんですか？
森川：私たちは“AI打鍵”と呼んでいるのですが、単にコードを生成するだけではありません。
従来の自動テストはDOMに依存するため、例えばCSSが崩れてボタンが画面上から見えなくなっていても、DOMが存在していればテスト成功と誤認してしまいます。
しかし、AI打鍵は実際のスクリーンショットを高度な「コンピュータビジョン（画像解析）」で検証し、ユーザーが実際に見る画面状態そのものを合否判定することもできます。
特にエンタープライズ領域では、事故発生時の監査対応やクライアントへの証明材料として、実際に画面を触って確認した証跡が強く求められます。
AI打鍵は、そうしたニーズに応えつつ、従来の自動テストがむずかしかった画面崩れの検知などを実現できる可能性があります。
岩瀬氏：しかし、画像解析はトークン消費量が爆発的でコストが厳しくありませんか？
森川：おっしゃるとおり、現在はトークン費用などのランニングコストが最大の課題です。
また、SHIFTでは累計1.4億ケース以上にのぼる膨大なテストケースを効率よく、かつ安全にまわすため、将来的には自社GPUサーバーの導入も視野に入れ、検討を進めている段階です。
もちろん、エンタープライズ企業が求める監査や信頼性の証明をどう担保するかといった課題もあるため、多角的に模索をつづけています。
これからのテスト設計者は、“トリアージャー”に
岩瀬氏：打鍵者がAIに置き換わる一方で、テスト設計者の仕事はどう変化するのでしょうか？
森川：トリアージャーという新たな職種に変化すると考えています。AI駆動開発が進むと、仕様通りのテストはAIエージェントが自動でつくってくれます。
しかしAIは、あらゆる可能性を考慮するあまりエッジケース（極端な条件のテスト）を激増させてしまいます。
岩瀬氏：AIは放っておくと無限にテストコードを書きますからね（笑）。
森川：そこで必要になるのが、リリースされる新機能の性質やビジネスリスクを考慮して、「このケースは今回必須」「これはやらなくていい」と優先順位を決める（トリアージする）役割です。
開発現場の“痛み”を記憶する人間。AIにはないメタ認知能力
岩瀬氏：AIがテストの大半をこなすようになっても、「どうしても人間にしかできないこと」って残るのでしょうか？
森川：それは、“ビジネスリスク”への気づきです。例えば、プロダクトに変更が加わって重要な購入ボタンが画面の端に見切れてしまったとします。
人間なら、画面を見た瞬間に「これはダメだ」と気づきますよね。これは過去の失敗事例を覚えていたり、お客様目線を理解したりしているからです。
しかし、AIにまったく同じ判断をさせようとすると、コンテキスト全体を読み込みにいってしまい、かなりの時間がかかってしまいます。
もしルールベースで無理やり検知させようとすれば、今度はあらゆる小さなズレに対して「これもユーザーが減ります！」とアラートを上げつづけるでしょう。ここには、人間の圧倒的な優位性があります。
岩瀬氏：人間が1秒で気づける直感的な判断力や、いわゆるドメイン知識って、どうやって身につくものなんでしょうか？
森川：私の経験則ですが、結局のところチームで経験した過去の痛みに由来するのだと思います。
「あの時、このバグを見逃してビジネスに影響が波及した」「このボタンの配置を変えたら売上がガタ落ちした」という経験があるからこそ、人間は「これはやってはいけない」と判断できるんです。
AIを導入する前にやるべきこと。仕様が属人化している組織では、AIの効果を十分に発揮しづらい
岩瀬氏：SHIFTさんには、AI駆動開発を導入した企業からの相談も増えているとお聞きしました。
森川：「AI開発を導入したものの本番で障害が発生した。リカバリーをどうすればいいか」というご相談が急増しています。
しかし現場で、日々テストの相談を受けているマネージャーたちに聞くと、「外部ベンダーへの丸投げで炎上したプロジェクトと、まったく同じ匂いがする」と。相手が人間からAIに変わっただけで、起きている炎上の構造は同じなんです。
岩瀬氏：なぜオーナーシップの喪失が起きるのでしょう？
森川：開発のスピード感がはやすぎるというのもありますが、背景には、経営層やビジネスサイドからの「とにかくAIを使え！」という強いプレッシャーがあります。
特に、AI特有の障害として、次の3つのパターンが目立っています。
岩瀬氏：これらを防ぐためには、どうすればいいのでしょうか？私が経営層なら「ドメインエキスパートのもつ暗黙知を言語化して、AIに食わせろ」というと思うんですが。
森川：よくそういわれるのですが、実は少し違います。
そもそも、ドメインエキスパートは非常に少ないですよね。そこで私たちがいま構想しているのは、設計情報・ビジネス要件・CI/CD・オブザーバビリティ（o11y）といった情報をAIエージェントが束ねてコンテキスト化し、テスト設計者やトリアージャーが1日でも早くドメインエキスパートに成長できるよう「判断・通知でヒトを支援する仕組み」をつくることです。
しかし、いざ情報を集約しようとしても、重要な仕様が誰かの頭のなかにしかなかったり、仕様書が単なる「スクリーンショットの貼り付け」でAIがテキストとして読み込めなかったり、過去の障害対応の経緯がチャットツールの海のなかに沈んでしまっていたりするのです。
岩瀬氏：そもそも情報管理がずさんな状態では、いくら優秀なAIを導入しても、AIはどうしようもないと。
森川：まさにその通りです。「ネクストアクションが決まらず終わっている会議」はもってのほかで、まず自分たちの日々の業務や決定プロセスを、情報資産として整理して残すといった「AI Readyな状態」ができていないと、AI駆動開発を成功させることはできません。
岩瀬氏：組織習慣や言語化能力そのものが問われているわけですね。本日はありがとうございました！
（※本記事の内容および取材対象者の所属は、イベント開催当時のものです）
