生成AIを使えば、Shopifyのカスタムアプリを短時間で作れるようになった。だが「速く作れる」ことと「安心して使える」ことは別問題だ。非エンジニアのマーチャントが「AIが作ったアプリ」に対して抱く最大の不安は、動作の信頼性である。この不安をどう解消するかは、AIを使った開発サービスの品質保証をどう設計するかに直結する。当社では、テストをすべて自動化して無人で回すのでも、逆にすべてを人手で確認するのでもなく、「機械が全件テストし、人が最終確認する」ハイブリッド方式に行き着いた。この記事では、なぜこの組み合わせが合理的なのか、そして設計にあたって詰めるべき論点を整理する。AIを使った開発に関心のある技術者と、その品質を気にするEC事業者に向けた内容だ。
「未知のリスク」は技術で先回りするより、人がいる工程で吸収する
AIが生成したアプリの検証で最も脆いのは、ブラウザに依存する挙動だ。管理画面のUI操作、ブロックの配置、ログイン状態を保った操作など、画面の見た目や操作感に関わる部分は、機械的なテストで完全に押さえるのが難しい。しかも厄介なのは、こうしたブラウザ依存の問題が「どこで起きるか」を事前に想定しきれないことだ。既知の落とし穴には個別の技術対策を打てるが、それでは想定済みのものしか守れない。
ここで発想を変える。未知のリスクに技術で先回りしようとするのではなく、人が確認する工程にそのリスクを落とす。人による検証は、既知か未知かを問わず、目の前で起きた不具合をすべて吸収する。当社の実績を振り返っても、パイプラインの中でテスト工程が最も詰まりやすい部分だった。ならば、その最も脆い部分を初期リリースのクリティカルパスから外し、人が担う。こうするとサービス全体の実現可能性が大きく上がる。リスク処理として、未知を人に寄せるのは筋が良い。
それでも自動テストは廃止しない ― 保守と回帰検知は機械の仕事
「人が確認するなら自動テストは要らない」と考えたくなるが、これは誤りだ。人の検証で自動テストを置き換えてしまうと、後工程の設計と矛盾する。
たとえば、多数のアプリのAPIバージョンを一括で追従させる保守運用を考える。一括更新のあとに全アプリの回帰確認を人手でやるのは不可能だ。ここは自動の受入テストがなければ回らない。修正ループも同じで、修正のたびに全項目を再実行してデグレ（後退バグ）を検知する作業は、機械だからこそ毎周回せる。人手で毎回すべての項目を再確認するのは現実的でない。
つまり、自動化できる項目――API検証、Webhook、データ整合、ストアフロントの表示など――は従来どおり機械が全件回す。人が担うのは、機械では取りにくいブラウザ依存の証跡取得（管理画面のスクリーンショットやブロック配置の目視）と、自動テスト結果が妥当かどうかの確認、そして最終承認だ。役割を分けることで、機械の網羅性と人の判断力を両取りできる。
ハイブリッドは、実は「より誠実で強い訴求」になる
ここで見落とされがちなのが、ハイブリッド方式はマーケティング上もむしろ強い、という点だ。「動作確認は人間が行う」というメッセージは、AIが自動生成しただけのツールに対する明確な差別化になる。非エンジニアのマーチャントにとって、最後に人の目が入っているという事実は、そのまま安心材料になる。
さらに正確に言えば、「全件を機械でテストし、その上で人が最終確認する」という説明のほうが、「人が全部見ています」よりも誠実で、説得力がある。人間がすべてを目視するのは物理的に無理があり、そう謳えば実態と乖離する。機械が網羅し、人が要所を締める、と正直に伝えるほうが、かえって信頼される。当社では初期のうちは担当者自身が全案件を検証しているため、訴求と実態が完全に一致している。この「自分の手で全件を検証する」期間は、そのまま「何を自動化すべきか」の優先順位を実測する学習装置にもなる。手を動かして分かったことが、次の自動化の投資判断を支える。
品質保証を「収益」と「工程」に落とすときに詰める論点
人の検証を正式な工程に組み込むなら、いくつか設計しておくべき論点がある。
まず、検証にかかる人の手間をどう扱うか。修正が発生するたびに人が全項目を再検証していては、工数が修正回数に比例して膨らんでしまう。そこで当社では、初回はフルに検証し、二周目以降は差分とデグレ確認を中心にする、と役割を定義している。全項目の再テスト（デグレ検知）は機械に任せ、人はその周回で変わった部分に集中する。こうして人の工数が青天井にならないようにする。
次に、納期への影響を明示する。人の検証が入る以上、「即時納品」ではなくなる。検証にかかるリードタイムを、あらかじめ提示資料に書いておく。人が見る時間を隠して「すぐ出せます」と言うと、そこで信頼を損なう。
そして、検証内容と所要時間を標準フォーマットで記録すること。初期は人が全部やるとしても、毎回の検証を記録しておかないと、後から「どこを自動化すべきか」の判断材料が手に入らない。作業標準書として残すことが、将来の自動化への布石になる。人の検証は「今しのぐための手段」であると同時に、「次に何を機械化するか」を教えてくれるデータ源でもある。
まとめ
AIでアプリを量産できる時代でも、品質保証を丸ごと自動化するのは早計だし、逆に全部を人手でやるのも続かない。当社が採るのは、機械が全件テストして網羅性を担保し、人がブラウザ依存の確認と最終承認を担う、というハイブリッド方式だ。未知のリスクは人がいる工程で吸収し、保守や回帰検知のように反復する検証は機械に任せる。この組み合わせは「人が最後に見ている」という誠実な訴求にもなり、非エンジニアの不安に応える。さらに、人の検証を標準フォーマットで記録しておけば、それがそのまま次の自動化の優先順位を決めるデータになる。AI時代の品質保証は、機械と人のどちらかを選ぶ問題ではなく、両者の役割をどう分けるかの設計問題である。