こんにちは、K.Platinum代表の沼田です。
2026年に入ってから、テストの世界で起きていることが一段おかしい。SHIFTが仕様書を起点に24時間365日自律稼働する「AIテストエージェント」を正式公表し、テスト実行期間を最大80%短縮すると打ち出してきた。同じころ食べログは、AIで手動QAのテスト実行工数を52%削減したと技術ブログで公開している。「テストを書く」じゃなくて「テストを"探索させる"」が、ようやく業界の主語になった年だと感じます。
ただ、僕らみたいな受託開発のITコンサルからすると、この話、丸ごと飲み込むと結構危ない。AIに任せれば工数が半分になるんでしょ？という顧客の期待値に対して、現場で「いやそうじゃないんですよ」と説明する側に回ることが、この半年でめちゃくちゃ増えました。
今日は、K.Platinum（17人のITコンサル会社、3期目）が受託案件のQAを"AI×シフトレフト"で再設計してみた、その実装ログを書きます。結論を先に言うと、AIを「テスト実行者」じゃなくて「上流の叩き台生成役」として配置すると、不具合の前倒し検知が一気に伸びました。
2026年、AIテストの主語が変わった
まず最近の動きを並べておきます。
- SHIFTの自律探索型AIテストエージェント — 2026年に正式公表。要件・UIから自律的にテストシナリオを組み立てて、探索的テストを回す
- 食べログの社内事例 — 自動テストコーディングのAI化で、テスト実行工数を52%削減（食べログ技術ブログ「AI4QA」）。AIを中心に3層の品質保証の仕組みを組み込んでいる
- 大手SIerのテスト自動化部門 — 「テストエンジニア」の肩書きを「品質設計エンジニア」にリブランドする動き
主語が「人間が書く」から「AIが探索する／人間がレビューする」に変わってる。
でも、これ、自社プロダクトを持っている会社の話なんですよね。食べログにしてもSHIFTにしても、品質保証する対象を自分で握っている。受託開発の現場では、まだほぼ降りてきていない。理由はシンプルで、受託案件はAIに任せる前提が崩れているケースが多いからです。
ここからが今日の本題。
受託でAI任せにすると壊れる3パターン
K.Platinumも2025年後半から、受託案件にAIテストツールを差し込む実験をしてきました。失敗を3パターンに整理します。
パターン①：仕様書欠落型
要件が口頭・Slack・議事録・PowerPointに散らばっている状態で、AIに「テストケース作って」と投げると、AIは"足りない仕様"を自分で補完しはじめる。
ある製造業の生産管理システム改修案件で、出庫処理のテストケースをAIに生成させたら、想定していない「在庫マイナス時の挙動」までテスト項目に入ってきた。確認したら、AIが「在庫マイナスは異常終了するのが普通」という業界一般のパターンを勝手に当てはめていた。実際の顧客運用は、マイナス在庫を許容して翌日朝バッチで補正する文化だった。
ハルシネーション仕様で走るテストは、テスト工数を増やすだけじゃなくて、顧客との信頼関係を削る。
パターン②：非機能要件抜け型
機能テスト自動化はAIが得意。だけど、性能・セキュリティ・運用観点はAIの守備範囲から綺麗に落ちます。
ある流通系の受発注Web案件で、AI生成したテストケースを全部通したのに、本番リリース直後にAPIが詰まった。原因は同時接続数の想定が甘かっただけ。AIに「性能テストも作って」と頼んでも、業務ピークの形は教えてくれていなかったので、汎用パターンしか出てこなかった。
非機能要件は、結局のところ「顧客の業務カレンダー」と「インフラの懐」を両方知っている人間が設計するしかない領域です。
パターン③：業務ドメイン推定の暴走
これが一番危ない。AIが「業界一般の慣習」を勝手に補完して、自動修正PRを出してくるケース。
製造業の図面承認フローを実装している案件で、AIが「承認後の図面差し戻しは履歴を残さない」というコードに自動修正PRを出してきた。一般的なドキュメント管理SaaSの作法としては正しい。だけど、その顧客は監査要件で「差し戻し履歴は永久保存」がマスト。マージしてたら監査落ちでした。
AIがドメインに踏み込んでくる時代は、「AIが何を知らないか」を人間が把握しておく側のコストが、結構効いてきます。
K.Platinumが17人で実装している"AI×シフトレフト"3レイヤー
じゃあどうするか。僕らは、AIを「テスト実行者」じゃなくて「上流の叩き台生成役」に配置する設計に振り直しました。"AI×シフトレフト"を3レイヤーで挿し込んでいます。
レイヤー①：要件定義レビューAI
要件定義書のドラフトが上がった段階で、AIに「曖昧表現・抜け・矛盾」を洗わせます。プロンプトには「顧客業界の専門用語は補完しないこと」「不明点は質問形式で出すこと」を毎回明示。
これだけで、要件レビューの差し戻しループが体感半分になりました。AIに"判断"はさせない。"気づき"だけを出してもらう、というルールが効いてます。
レイヤー②：設計同時テスト生成
基本設計レビューと同時に、テストケースの骨子（観点リスト＋境界値の候補）を生成します。設計レビューの場で「このテスト観点も入れた方がいい」と気づくと、設計そのものが洗練される。
設計と品質保証は、本来同じレイヤーの仕事なんですよね。AIがその同時並行を物理的に可能にしてくれた。
レイヤー③：本番探索AIエージェント（範囲限定）
UATと並走させる探索AIを置きます。ただし範囲は限定。本番稼働後の機能追加部分・改修部分のみ。既存スパゲッティ仕様の領域には絶対に放たない。
ここはSHIFTのツールも入れて検証中です。重要なのは「AIに本番探索を任せる」のではなく「AIが探索した結果を人間が短時間で確認する」というレビューの設計。人間のQAリーダーが、AIの出力に対して「採用／却下／要再検証」を1日30分で判断するワークフローに固めました。
こうした"AI×シフトレフト"の品質設計を、受託の現場で一緒に組み立てるエンジニア・QAをK.Platinumでは募集しています。気になった方は採用ページものぞいてみてください。
実際に効いた指標（中堅製造業・流通の受託で）
ここからは2026年4〜5月時点で見えてきた数字です。
- 不具合検知の前倒し率：単体テスト段階で30〜40%増。要件レビューAIが効いた効果
- QA工数：プロジェクトによっては約半分。ただし全件ではない
- 顧客レビュー回数：要件定義の「修正→再提出」ループ回数が約半減
正直に書くと、効きにくい案件もあります。
- 既存スパゲッティ仕様の改修：AIが要件を読み解けず、結局人間が全部書き直す
- ドキュメントが極端に少ない案件：そもそも入力がない
- 短納期で要件定義フェーズが圧縮されている案件：AIを通す時間そのものが取れない
なので、案件着手時に「この案件は3レイヤー全部入れるか、レイヤー②③だけにするか」を判断する基準を社内で持つようになりました。AIを入れない判断ができることが、AI時代の品質設計者のスキルだと思っています。
2027年、人間QAに残るものは何か
最後に、ちょっと先の話。
「探索」はAIに移った。じゃあ人間のQAエンジニアは何が残るか。僕らの中での暫定回答は2つです。
ひとつは設計判断。何をテストし、何をテストしないか。リリース判定の合議で「ここの観点は今回切ってOK」と言える根拠を持っている人。これはAIが代替しにくい。
もうひとつは顧客折衝。本番障害が起きたとき、顧客に「これは想定の範囲内です」「これは新たに見つかった想定外で、対応にこれだけ時間がかかります」と説明する役割。技術と顧客文化の両方を理解している人にしかできません。
肩書きとしての「QAエンジニア」は消えないと思います。ただ、業務は「テスト実行者」から「品質設計者」に移る。K.Platinumでは、QAバックグラウンドのある人を意識的に上流側（要件定義レビューや設計レビュー）に配置するようにしました。テストを書く人ではなく、AIの出力を疑える人を、品質保証の中心に置きたいんです。
受託開発の品質保証は、AIで自動化されるんじゃなくて、AIで"再設計"される。17人の小さな組織でも、3レイヤーを挿し込むだけで現場が変わりました。
もしこの記事を読んで、「AI×シフトレフトの実装、自社でもやってみたい」「受託の上流で品質設計の側に出たい」というQAエンジニアの方がいたら、ぜひ話を聞きに来てください。K.Platinumは2026年も、AIを単純な工数削減ツールにせず、品質の再設計に使い倒していきます。
最後まで読んでいただきありがとうございました。
株式会社K.Platinum 代表取締役 沼田海斗
高専卒 → トヨタ → スタートアップITコンサル → 24歳で起業。17人のITコンサル会社を経営中。製造業×AI／RAG／受託開発が得意領域。
K.Platinumでは一緒に働くエンジニアを募集しています。「実力で正当に評価される環境」に興味がある方は、ぜひ採用ページをご覧ください。