「AIでテスト工数を削減します」と言われたら｜7工程で検収条件を決める

「AIを使うのでテスト工数を削減できます」という提案を受けたとき、確認すべきはAIの利用率ではありません。 各工程で、何が成果物として出てきて、誰が承認し、何をもって合格とするかです。

テクバンは2026年9月1日、ソフトウェア開発のテスト工程を支援する「STEMS AI」の提供を開始したと発表しました。特徴として、テスト計画から品質分析までを7つのフェーズに分け、AIが担う領域と人が判断・承認する領域をフェーズごとに明確化している 点を挙げています。

発表では、テストの要否判断、重要度の設定、リリース可否の判断といった責任を伴う意思決定は人が行い、AIは分析と成果物の作成を担当する としています。

この「切り分けの明示」こそが、発注側が確認すべき論点です。 製品の選定ではなく、自社の発注でも同じ切り分けができているかを問う記事です。

先に結論：AIの利用率は検収条件にならない

共通するのは、AIが何をするかではなく、人が何を引き受けるかが書かれていない点です。 検収できる契約にするには、工程ごとにこれを埋める必要があります。

7工程で確認する表

発表で示されている工程区分を手がかりに、発注側の確認表を作ります。AIの対応度合いは製品や案件で変わるため、ここでは「発注側が各工程で確認すべきこと」を整理します。

発表資料が「人が行う」としているのは、AIとの分担であって、発注側と受注側の分担ではありません。 そのうえで、太字にした4つのうちテストの要否判断、重要度の設定、リリース可否の判断には、業務への影響の理解が要ります。 誰が決めるかは運用形態と契約によりますが、決める人を契約で明示しないまま進めると、品質の責任の所在が曖昧になります。

なぜ「AI化」の提案は検収できない形で来るのか

提案側に悪意があるわけではありません。構造的な理由が3つあります。

発注側が何を求めているか分からないからです。 検収条件を提示しない発注では、提案側は「効率化します」という書き方をするしかありません。曖昧な提案が来るのは、曖昧な発注をしているからでもあります。

AIの成果が案件ごとに変わるからです。 仕様書が整っている案件と、口頭で伝えられた案件では、生成できる成果物の質がまったく違います。提案時点で確約できないため、幅のある表現になります。

削減率が売りになるからです。「工数半減」は分かりやすく、比較されやすい。一方「検収条件を明確にします」は伝わりにくい。競合が数字を出していれば、数字で応じることになります。

したがって、発注側が先に検収の枠組みを示すのが最も確実です。 「各工程で、成果物、承認者、合格条件を提示してください」と依頼書に書けば、提案の質がそろい、比較できるようになります。

テストの前提が整っていない場合

AIの導入以前に、次の状態だと効果は限定されます。自社が該当しないか確認してください。

要件定義書・仕様書・設計書のいずれも残っていない、または実態と合っていない。 発表資料は、この3つを起点とするとしています。このいずれも残っていない、あるいは実態と合っていない場合、何を根拠に観点を抽出するのかが問題になります。 現行のコードから復元する作業が先に要ります。

過去のテスト資産が残っていない。 前回どこまでテストしたかが分からないと、今回の範囲も決められません。

不具合の記録がない。 どこで問題が起きやすいかの傾向が分からず、重要度を付けられません。

環境が本番と違いすぎる。 テスト環境でしか再現しない問題と、本番でしか出ない問題が混ざります。

この4つのうち複数に該当するなら、AI導入より先にやることがあります。 そして、その「先にやること」を含めた見積もりを出せるかどうかが、開発会社を見極める材料になります。前提が整っていないのに「AIで解決します」と答える提案は、疑ってよいと考えます。

契約に書く3列

工程ごとに、次の3つを契約書または仕様書へ書いてください。

1. 成果物。 その工程が終わったときに何を受け取るか。「テスト設計書」だけでは足りません。何が書かれているか、どの粒度かまで決めます。

2. 承認者。 誰が承認するか。発注側の誰か、受注側の誰か。「双方協議のうえ」は承認者を決めたことになりません。

3. 合格条件。 何が満たされれば次の工程へ進むか。数値で書ける項目は数値で書きます。

この3列が埋まっていない工程は、検収できません。 検収できない工程は、後で「言った・言わない」になります。

AI生成物のレビューを「抜き取り」で設計する

テストケースがAIで生成される場合、全件を人がレビューするなら省力化になりません。かといって、まったく見ないわけにもいきません。抜き取りの設計が要ります。

決めるのは4つです。

• 抜き取る割合または件数。 全体の何％、あるいは何件を見るか。
• 抜き取り方。 無作為か、重要度の高い機能から優先か。両方を組み合わせるのが実務的です。
• 見る観点。 網羅性、期待結果の妥当性、前提条件の正しさ、実行可能性。
• 不合格時の扱い。 抜き取りで問題が見つかったとき、その分だけ直すのか、全件を見直すのか。ここを決めていないと、1件の欠陥で工程全体が止まります。

4番目に「同種の欠陥を全件で検索する」という選択肢を入れておくと現実的です。 1件で見つかった問題は、同じ原因で他にもある可能性が高いためです。

「テストしていないこと」を成果物にする

AIが生成したテストケースは、一見すると網羅的に見えます。ただし、そこに何が含まれるかは入力資料だけで決まるわけではありません。発表資料によれば、テスト分析ではテクバン独自の30のテスト観点に基づく観点抽出 が行われるとされています。つまり、資料に明記されていない観点が観点体系から提案されることもあれば、どこまで推論して補うかは公表されていないため、生成物が自社の観点を網羅している保証はありません。 発表資料は組み合わせテストについてAI以外の専用ロジックも用いるとしており、生成の仕組みは一様ではありません。

• 仕様書に書かれていない例外処理
• 現場の運用でだけ発生する使い方
• 過去に障害が起きた箇所
• 他システムとの連携で起きる組み合わせ
• 性能、同時実行、障害復旧といった非機能

したがって、受け取るべき成果物には「テストしていない範囲の一覧」を含めてください。 テストケースの一覧だけを見ると、そこに書かれていない領域が意識に上りません。「何をテストしたか」と同じ重みで「何をテストしていないか」を出させることが、発注側の防御になります。

そして、テストしていない範囲について、なぜ対象外としたのかの理由を1行ずつ書かせてください。「優先度が低い」「今回の変更範囲外」「別工程で確認」といった理由が並びます。この一覧が、リリース判断の材料そのものです。

「AIが担う」と「人が承認する」を混ぜない書き方

契約書や仕様書で、この2つが混ざった書き方をよく見ます。混ざると検収できません。

避けるべき書き方の例。 「AIを活用してテストケースを作成し、品質を担保する」。誰が担保するのかが書かれていません。AIは担保の主体になれません。責任を負う法人格がないからです。

望ましい書き方の例。 「受注者はテストケースを作成する（作成にAIを用いてよい）。発注者は重要度が高い機能について、生成されたケースの20%を抜き取りレビューし、5営業日以内に承認または差し戻す」。

違いは3つです。 ①主体が人と組織になっている ②レビューの範囲と割合が数値で書かれている ③期限が入っている。AIを使うこと自体は手段として括弧に入れる のが、契約文としては素直です。

同じ考え方を全工程に適用してください。「AIが分析する」ではなく「受注者が分析結果を提出し、発注者が妥当性を確認する」。AIは道具であって、契約の当事者ではありません。

リリース承認の責任者を契約で明記する

7工程のうち、最後の品質分析を受けた業務リリースの承認は、原則として発注側が持つことを勧めます。技術的な可否判断や運用上の承認を受注側が担う契約もあるため、実際の分担は契約で明記してください。重要なのは、AIや暗黙の「双方協議」に判断を委ねず、最終責任者を特定することです。理由は3つあります。

業務影響を知っているのは発注側だからです。 残存する不具合が業務にどれだけ響くかは、システムの外側の事情で決まります。繁忙期か、代替手段があるか、顧客への影響はどうか。これは技術指標では判断できません。

責任の所在が明確になるからです。 リリースを決めた人が誰かが分からない状態で問題が起きると、その後の対応が遅れます。

次回の改善につながるからです。 判断した人が結果を見ることで、次はどこを厚くすべきかが分かります。委ねていると、この学習が組織に残りません。

判断の材料としては、次の4つを揃えてもらってください。①残存する既知の不具合と、その影響 ②テストしていない範囲と、その理由 ③重大な不具合が出た場合の切り戻し手段 ④リリース後に監視する項目。この4つがそろっていれば、技術に詳しくなくても判断できます。

削減率の見積もりを鵜呑みにしない

今回の発表資料は、工程ごとに削減率の幅を示したうえで、それが想定値である旨を明記しています。

同資料はこれらについて「当社の想定値であり、実績値ではありません」とし、さらに「インプット資料の整備状況や対象システムの特性、自動化の適用範囲により変動します」と条件を付けています。

この書き方自体が、発注側にとっては読みやすい形です。 工程が特定され、想定値であることが明示され、変動要因が挙げられている。問題になるのは、これらの条件を落として「工数を半減できます」とだけ伝えられる場合です。

「テスト工数を◯割削減」という数字が提示されたとき、次を確認してください。

どの工程の工数か。 テスト実装だけが半分になっても、全体では大きく変わりません。工程別の内訳を求めてください。

削減の根拠は何か。 他社事例か、自社データに基づく試算か。他社事例なら、その会社の前提（仕様書の整備状況、テストの成熟度）が自社と近いかを確認します。

増える作業は引かれているか。 AI生成物のレビュー、指示の作成と調整、生成が失敗したときの手戻り。これらは新しく発生する作業です。

未達だった場合はどうなるか。 削減率が見積もりに届かなかったとき、費用は変わるのか。変わらないなら、その数字は約束ではなく期待値です。

提示された削減率が実績なのか想定なのかを、必ず区別してください。 想定であれば、契約上の意味は限定的です。

部分導入という選択

発表では、必要な工程のみの部分導入にも対応する 点を挙げています。これは発注側にとって重要な選択肢です。

全工程を一度に変えると、うまくいかなかったときに原因の切り分けができません。効果が出やすく、リスクの小さい工程から始めるのが現実的です。

最初に手を付けるなら、テスト分析が候補です。 仕様書の曖昧さや矛盾が早い段階で見つかれば、後工程の手戻りが減ります。そして、この工程で見つかった曖昧点は、AIを使わなくても価値のある成果物です。

GXOに相談すべきタイミング

• 「AIでテスト工数を削減」という提案を受けたが、妥当か判断できない
• テストの成果物として何を受け取るべきか分からない
• 過去に納品されたシステムで、リリース後に不具合が多発した
• 検収の基準が「動いていること」しかない

GXOのシステム発注前相談では、見積もりの前提、工程ごとの成果物と合格条件、検収の設計を第三者の立場で整理します。開発そのものの相談はDX・システム開発、AI機能を含む場合の可否判断はAI導入可否アセスメントが入口です。

要件を文章にする段階は要件定義書テンプレート＆サンプル記入例、発注前に見るべき設計の観点はセキュリティ・バイ・デザインと開発会社選び、保守を引き継げる形で受け取るための条件は保守先を変更する前に見る引き継ぎ条件にまとめています。

FAQ

発注側にテストの専門知識がありません。何を見ればよいですか

専門知識がなくても確認できる項目があります。①各工程の成果物が契約書に書かれているか ②承認者が個人または役職で特定されているか ③合格条件が数値または明確な状態で書かれているか ④「テストしていない範囲」の一覧が成果物に含まれているか。

この4つは、テスト技法を知らなくても確認できます。 そして、この4つが埋まっていない契約は、専門知識があっても検収できません。

AIが作ったテストケースの品質を、どう確かめますか

抜き取りレビューに加えて、既知の欠陥で試す 方法が有効です。過去に発生した不具合をいくつか選び、「そのケースが生成されたテストで検出できるか」を確認します。

検出できなければ、生成の元になった情報が足りないか、観点が不足しています。過去の障害は、自社にとって最も現実的なテストケースです。 これを使わない手はありません。

人が判断する工程を残すと、結局工数は減らないのでは

減る工程と減らない工程を分けて考えてください。発表資料が削減率を示しているのは、テスト分析からテスト実装、自動化済み範囲のテスト実行、品質分析レポート作成の3区分です。テストの要否判断、重要度の設定、リリース可否の判断といった意思決定は、削減の対象として挙げられていません。

ケースを1から書く時間は、発表資料の想定どおりであれば減ります。ただしそれは想定値であり、資料の整備状況や自動化の範囲によって変動するとされています。 そして、どこまでテストするかを決める時間、結果を見てリリースしてよいか判断する時間は、この想定に含まれていません。生成物が増えれば、それを確認する時間も別に必要になります。

したがって、期待すべき効果は「総工数の削減」よりも、「決めることに時間を使えるようになる」 という配分の変化です。この観点で効果を測ると、実態に合った評価ができます。

経営会議へ出す4行

3行目が「いいえ」なら、契約前です。 発注してから検収条件を決めることはできません。

既存の開発会社に、この確認をすると関係が悪くなりませんか

確認の仕方によります。「AIを使うのが不安だから」ではなく、「検収の基準をそろえたいから」と伝えてください。工程ごとの成果物と合格条件を明確にすることは、受注側にとっても有利です。 どこまでやれば完了かが決まるからです。

実際、この確認を嫌がる開発会社は多くありません。嫌がられるとすれば、それは基準を決めたくない理由がある場合です。その反応自体が、判断材料になります。

自動テストスクリプトを納品されました。何を確認すべきですか

3点あります。1つ目は、実行できるかです。 自社の環境で、自社の担当者が動かせるか。納品時に一度、発注側の環境で実行してもらってください。受注側の環境でしか動かないスクリプトは、納品後すぐに使われなくなります。

2つ目は、失敗したときに原因が分かるかです。 テストが赤くなったとき、何が期待値で何が実際の値だったかがログに残るか。分からなければ、担当者は原因調査を諦めて、そのテストを無効化します。

3つ目は、誰が保守するかです。 画面や仕様が変わればスクリプトも直す必要があります。この保守が契約に含まれていないと、画面や仕様が変わった時点で動かなくなります。 動かなくなった自動テストは、あるだけで安心してしまう分、無いより危険です。

小さく始めるなら、どの工程からですか

テスト分析を勧めます。理由は3つあります。①仕様書の曖昧点や矛盾が早期に見つかり、後工程の手戻りが減る ②成果物が文書なので、発注側でもレビューできる ③誤りがあってもレビューで止まり、本番に影響しない。

そして、この工程で得られる「仕様の曖昧点リスト」は、AIを使うかどうかに関係なく価値があります。 曖昧なまま開発に入った箇所は、後で認識のずれとして表面化するおそれがあります。

逆に、最初にテスト実行や品質分析へ手を付けるのは勧めません。判断の責任が重く、効果も測りにくいためです。

社内に品質保証の部署がありません。誰が承認すればよいですか

部署の有無ではなく、業務を最もよく知っている人 が承認者になります。技術的な妥当性は受注側が担保し、業務的な妥当性を発注側が見る、という分担にしてください。

具体的には、①その機能を毎日使う担当者に、テストケースの一覧を見せて「この使い方は入っているか」を確認してもらう ②業務責任者に、テストしていない範囲の一覧を見せて「これで出してよいか」を判断してもらう。技術の話をせずに承認できる形にすることが、承認者を確保する条件です。

公式情報と確認境界

• テクバン「テスト計画から品質分析までの全7フェーズをAIで支援する『STEMS AI』を提供開始」（一次、2026年9月1日付。7フェーズの区分、AIと人の役割分担、工程ごとの成果物、部分導入への対応。2026年9月2日確認）
• テクバン株式会社（一次、提供元企業。サービスの詳細と最新情報の確認先）

サービスの提供開始日、7フェーズの区分、AIが行うことと人が行うことの切り分け、工程ごとの成果物、部分導入への対応は2026年9月2日に発表資料で確認しました。価格は対象範囲・規模・期間に応じた個別見積もりとされています。工数削減率については、発表資料に「想定される工数削減率」として、テスト分析〜テスト実装で30〜50%、自動化済み範囲のテスト実行で40〜60%、品質分析レポート作成で50〜70%が示されています。ただし同資料は「当社の想定値であり、実績値ではありません」「削減率は、インプット資料の整備状況や対象システムの特性、自動化の適用範囲により変動します」と明記しており、実績値として扱うことはできません。 本記事は特定のサービスを推奨するものではなく、また特定の削減率を保証するものでもありません。「契約に書く3列」「抜き取りの設計」「テストしていない範囲の一覧」「部分導入の向き不向き」はテクバンの手法ではなく、GXOが発注側の視点で整理した判断の枠組みです。自社の検収条件は、開発の規模、体制、品質要求に応じて個別に設計してください。 抜き取りレビューの割合、承認の期限、部分導入の順序など、本記事が示した運用上の目安は、発注側の実務からGXOが置いた出発点です。発表資料が定めた基準ではありません。開発の規模と品質要求に応じて決め直してください。