(cache)AIによる手動QAの自動化：自動テストコーディングのAI化でテスト実行工数を52%削減

はじめに：AI4QA Phase1からPhase2への進化

こんにちは。食べログの品質管理部でAI4QAプロジェクトのプロジェクトリーダーを務める黎です。

食べログの品質管理部では、2025年7月に「AI4QA Phase1」として、生成AIを活用したテスト実装の効率化に取り組んできました。Phase1では、手動テストケースの実装をAIで支援し、直近の案件では手動実施399件中304件のテストケースをAIで実装することに成功しました。（前回記事: AIによる手動QAの自動化：食べログQAチームの挑戦、その第一歩）

しかし、実際の運用を通じて一つの重要な課題が浮き彫りになりました。テスト実装をAI化しても、工数削減のインパクトが限定的だったのです。

その理由は明確でした。手動テストプロセスでは、テスト実行の工数が全体の50%を占めており、テスト設計や実装だけをAI化しても、ボトルネックを解消できなかったのです。

そこで私たちは、Phase2でテスト実行工数をターゲットとすることにしました。

Phase2では、「自動テストコーディングをAI化し、テスト実行を自動化することで、テスト実行工数を78%削減する（2.3人月 → 0.5人月）」を目標としました。

この記事ではPhase2での具体的な取り組みと成果、そして学びをお伝えします。

AI4QA Phase1の成果と限界

簡単に前回の記事を振り返ると、まずPhase1の背景には、食べログが成長を続ける中で案件が増え続けており、現在のチーム規模で対応できる案件数を増やす必要がありました。また昨年度のテスト案件を分析した結果、既存機能改修プロジェクトはリグレッションテスト中心で過去のナレッジが再利用しやすいことが分かりました。そこで、既存機能改修プロジェクトのテスト実装をAIで効率化する取り組みを始めました。

その後、Phase1の成果物の運用を開始し、既存機能改修プロジェクトの案件数を重ねるごとに、少しずつAIで実装する規模や割合を増やすことができました。

直近の案件では、手動実施399件中304件をAIで実装することができました。手動実施ケースの約76%をAI化できたことで、テスト実装のAI化において一定の進展がありました。さらに、案件数を重ねる中でCursorでの実装を試すなど、継続的な改善も行っています。

しかし、工数の成果に目を向けると、直近のプロジェクト全体でもテスト実装のAI化では0.09人月の削減にとどまり、削減率はわずか2.4%という結果でした。

その理由は明確でした。テスト実行の工数が全体の56.3%を占めており、テスト実装の効率化だけでは全体への影響が小さかったのです。

そこで、Phase2では自動テストコーディングのAI化に焦点を当て、テスト実行工数そのものを削減することを目指しました。

表：直近の案件の工数内訳

工程	工数（人月）	比率	対応状況
テスト設計	0.80	21.4%	-
テスト実装	0.84	22.3%	Phase1でAI化
テスト実施	2.10	56.3%	Phase2のターゲット
合計	3.74	100%	-

Phase2への背景：「軽微な修正問題」という課題

Phase1の運用を通じて、テスト実行工数が全体の56.3%を占めていることが明確になりました。自動テストコーディングのAI化を進めるにあたり、実行を含むQAのテスト全体の工数について、改めてどれぐらいの工数を目指すか考えました。

開発とQAの工数比率アンバランスという現実

食べログの予約システムでは、小規模な機能改修案件において、開発工数に対してQA工数が大幅に大きくなるという状況が続いていました。戦略的な大規模プロジェクトでは1:1の比率に抑えられているにもかかわらず、です。この構造的な問題を解決するため、Phase2では自動テスト資産の継続的な構築により、テスト実行工数を根本的に削減し、開発とQAの工数比率を適正化することを目指しました。

テストケース分析から見えた「軽微な修正問題」

テストケースの内容を分析した結果、テストケース数が膨大になる理由が見えてきました。

具体例として、食べログで「予約可能な経路を1つ追加する」という、一見小さな機能追加があったとします。ソースコードの修正量は小規模で数ファイルの変更に留まりますが、影響範囲は予約管理、キャンセル処理、連絡なしキャンセル処理、キャンセル取り消し、返金処理、キャンセル料請求処理など、業務プロセス全体に波及します。その結果、影響の組み合わせをテストする必要があり、テストケース数が1,000件を超えるまで膨大化してしまいます。

つまり、プロジェクトのリスクやテストケース量が、ソースコードの修正量に比例しないという問題です。この問題により、小規模な機能改修でもテストケース数が膨大になり、結果としてテスト実行工数が大きくなってしまうのです。私たちは、この現象を「軽微な修正問題」と呼んでいます。

Phase2の戦略：自動テスト率向上による実行速度改善

この「軽微な修正問題」を解決するため、自動テスト率を向上させ、実行速度を改善することで、テスト実行工数を削減することを目指しました。

そのため、Phase1で構築したテストナレッジ基盤を活用し、自動テストコーディングのAI化に取り組むことにしました。

AI4QA Phase2：自動テストコーディングのAI化の全貌

「軽微な修正問題」を解決するため、私たちは単なるツール導入ではなく、QAプロセス全体を見直す戦略的なアプローチを採用しました。その核心が、Phase1で構築したテストナレッジ基盤を最大活用する「自動テストコーディングのAI化」です。

Phase1の資産を活かす戦略的設計

Phase1の取り組み（詳細はこちら）を通じて、私たちは重要な発見をしました。それは、テストケースを中央集約化することで、手動テストと自動テストを統合できるという可能性です。

従来のQAプロセスは人中心の設計となっており、手動テストと自動テストはそれぞれ異なるエンジニアがアサインされ、それぞれが独自にテストケースや自動テストコードを管理する体制となっており完全に分離されてました。しかし、私たちは「テストケースをテストナレッジベースとして集約し、そこからAIが全体のQAプロセスを制御できないか？」と考えました。そこで生まれたのがPhase2の戦略的設計です。

Phase2戦略設計図

Phase1で構築した基盤の重要な価値は、単なる自動化ツールではありませんでした。仕様書の解析ノウハウ、テスト観点の抽出技術、そして最も重要なテストナレッジの中央集約システム。これらがGitHubで一元管理され、チーム全体で共有できる状態になっていたのです。

Phase2では、この集約されたテストデータを起点として、AIが手動テストから自動テストまでのプロセスを自動化し、人間は戦略的判断に集中できるようになります。テストナレッジベースが中核となり、仕様書からテスト実行まで一気通貫でAIが処理できるようになります。これにより、手動テストと自動テストの境界が消失し、AI主導QAプロセスが実現されました。

戦略的技術選定：なぜこの構成なのか

Phase2の設計において私たちが最も重視したのは、手動テストナレッジ、既存自動テスト実行基盤、自動テストコーディングについての設計ナレッジなどの「テスト資産の最大活用」でした。数多くの選択肢を検討した結果、以下の技術スタックに辿り着きました。

システム構造図

この構成図は前述の戦略的設計を詳細化したものであり、上のものと同様に、左側のPhase1領域から右側のPhase2領域へ、データが自然に流れる設計になっています。この技術構成の詳細について、以下で説明していきます。

自動テストコーディングの登場人物

Phase2の自動テストコーディングには、以下の要素が関わります：

インプットデータ

テストケース: Phase1で生成された構造化データ
HTMLファイル群: UI要素の詳細情報を含む画面定義
操作レコーディング: ユーザー操作の実際の流れを記録したデータ

AI処理エンジン

Cursor + 自動テスト設計ガイド: コード生成の中核エンジン
自動検証システム: 生成されたコードの品質をチェック

アウトプット

Gherkin Feature file: BDD形式のテストシナリオ
Page Object: 画面操作の抽象化クラス
Step Definition: 実行可能なテストコード

各技術選定の戦略的根拠

自動テストコーディングを担当するAIエージェントとその実行環境について慎重に検討しました。最新のAIエージェントはブラウザを内包しているケースもあるため、テスト実行自体をAIエージェントに任せることも技術的には可能です。実際にBrowser UseとOllamaの組み合わせや Devinを検証しましたが、仕様に基づく期待結果との100%の一致を求められるソフトウェアテストにおいては、現時点での導入は困難との結論に至りました。

検証で明らかになった2つの課題

一つ目の課題は、Flakyテスト率の上昇です。AIエージェントに直接テストを実行させると、AIの思考時間が追加されるため、タイミング依存のFlakyテストを誘発します。検証では、場合によっては100%のFlakyテスト率が発生しました。

もう一つの課題は、テストケースの期待結果を満たさないのにテストをパスとしてしまう偽陽性（False Positive）の発生です。例えば、「7月1日に予約できるか」というテストにおいて、バグにより予約できず本来ならテスト失敗とすべき場合に、 AIが自律的に7月2日で予約を試行し、テスト成功と判定してしまうケースです。これは、AIの問題解決志向という特性に起因しますが、ソフトウェアテストでは「仕様通りに動作しない=失敗」と明確に判定する必要があります。

採用した戦略：AI生成 + 既存環境のハイブリッド

これらの検証結果を基に、テスト実行環境は既存のSelenium + Cucumber + CircleCIを維持し、そこで実行する自動テストのコーディング作業をCursorで実施する戦略を採用しました。

この判断により、以下のメリットを実現できます：
- 既存環境の活用によるFlakyテストと偽陽性のリスク抑制
- AIが生成したコードも従来と同じ品質基準で実行・検証可能
- 運用チームの学習コストゼロで即座の本格運用開始
- 将来的なAIエージェント技術への移行パスの保持

分断のないデータフロー設計

仕様書(Confluence) → テストケース(GitHub) → 自動テストコード(Cursor) → 実行結果(CircleCI)

この一気通貫のデータフローこそが、私たちのPhase2システムの重要な価値です。人間による初期準備（HTMLファイル、操作レコーディング等）は必要ですが、その後はAIが連続的にデータを処理し、高品質なコードを生成します。結果として、人間は戦略的なレビューと判断に集中でき、反復的なコーディング作業から大幅に解放されました。

AI化による品質向上の仕組み

AIが生成するコードの品質を安定させるには、単にAIを導入するだけでは不十分です。私たちはAIを中心に据えた業務フローを設計し、その中に3層の品質保証メカニズムを組み込むことで、コード品質の安定化を実現する仕組みを構築しました。

自動テスト設計ガイド：食べログの品質管理部の競争優位性

「自動テスト設計ガイド」こそが、私たちの重要な競争優位性です。これは単なるデータベースではなく、食べログのQAチームが長年培ってきた知見を体系化した「知的資産」です。

自動テスト設計ガイドには、最適なワークフロー、アーキテクチャ設計原則、成功事例から抽出したベストプラクティスなどが含まれています。これらの知見はCursorのプロンプトとして注入され、まるで経験豊富なエンジニアがコードを書いているかのような品質を実現しています。

他社が同じツールを使っても、この自動テスト設計ガイドなしには同等の結果は得られません。これが私たちの技術的な差別化要因となっています。

人間が書く場合に入りがちな「原則の省略」「見落とし」といった要因を、AIと自動化により排除することで、一貫して高品質なコードを生成できるようになりました。

Phase2の技術的詳細については、次章で具体的に解説します。

人間とAIの協働モデル設計

Phase2の設計において、私たちは「人間とAIの最適な役割分担」を戦略的に設計しました。単純にAIにタスクを置き換えるのではなく、それぞれの強みを活かす協働モデルを構築することが重要でした。

役割分担の設計原則

AIが担当する領域： - 反復的で正確性が求められる実装作業（Page Object、Step Definition生成） - パターン化可能なコード生成 - 機械的な品質チェック（12検証項目による自動検証）

人間が担当する領域： - 戦略的な判断とレビュー - テストアーキテクチャの設計 - 複雑なビジネスロジックの品質向上 - 自動テスト設計ガイドの改善

協働モデルの設計思想

この役割分担の背景には、明確な設計思想があります。AIは一貫性と正確性に優れ、人間は創造性と戦略的思考に優れています。この特性を活かし、AIには「実装の品質と速度」を、人間には「設計の品質と戦略性」を担わせることで、全体最適を図りました。

また、人間が本来持つ価値を最大化するため、単調な作業から解放し、より高次の業務に集中できる環境を意図的に設計しています。

Phase2では、この協働モデル設計により、手動テスト実装から自動テストコーディング、テスト実行までを一気通貫で繋げることに成功しました。次章では、この設計を支える具体的な技術実装と、97%超の高精度を実現する技術的メカニズムについて詳しく解説します。

技術的実装の詳細とノウハウ

前章で紹介したPhase2システムの概要を踏まえ、本章では「人間による修正の必要性を最小化」するための具体的な技術実装について詳しく解説します。

私たちは「AIが生成したコードをいかに人間が修正することなく、そのまま使えるレベルまで品質を高める」ことを目標としました。そのために作成したのが、自動テスト設計ガイドと自動テスト12検証項目です。これにより以下のような高い精度の自動テストを生成できるようになりました。

Page Object生成精度: 97.26%
Step Definition生成精度: 92.63%

2段階自動テストコーディングプロセス

自動テストコーディングDataFlow

Phase2では、上図に示す2段階のプロセスでコード生成を行います。

ステップ1：テストシナリオの構造化

手動テストケース + 補助ファイル（HTML + 画面操作録画）をインプット
Few-shotプロンプティングによるFeatureファイル生成
ビジネスロジックの正確な理解と構造化

ステップ2：高精度コード生成

Featureファイルを基にした実装コード生成
自動テスト設計ガイドによる品質担保
自動テスト12検証項目による自律的品質チェック

3層品質保証システム：AIコードが安定した品質を実現する仕組み

Phase2で注目すべき結果は、AIが生成したコードが一定の品質基準を安定して維持できるということでした。特に、人間が手動で実装する際に起こりがちな見落としや不整合を、システマティックに回避できています。これは偶然ではありません。私たちが構築した3層の品質保証システムにより実現された、計算された結果なのです。

第1層：自動テスト設計ガイドによる設計品質の担保

まず、コード生成の根本的な品質は自動テスト設計ガイドによって担保されます。自動テスト設計ガイドは、食べログQAチームが長年培ってきた暗黙知を体系化した「知的資産」で、以下の3つの要素から構成されています。

1. ワークフローナレッジ：最適な実装手順の自動選択

人間が実装する場合、「どの順番で作業するか」は経験に依存し、非効率な手順を選んでしまうことがあります。しかし、自動テスト設計ガイドには最も効率的な実装手順が体系化されており、AIは常にワークフローに基づいて最適なプランを選択できます。下記は、実際にAIが選択したプランの一例です。

## 実装順序の最適化
1. 既存Step Definition調査 → 重複回避
2. PageObject継承関係確認 → アーキテクチャ整合性
3. Component責任分離分析 → 適切な配置決定
4. パラメータ化設計 → 再利用性確保
5. 型安全性実装 → 品質担保

2. 設計ナレッジ：アーキテクチャ原則の適用

PageObjectモデル、Component責任分離、継承チェーン設計など、複雑なアーキテクチャ原則を人間が毎回完璧に適用するのは困難です。しかしAIは、これらの原則を例外なく適用し続けます。

PageObject設計原則: 画面操作の抽象化と責任分離
Component責任分離: Modal、Header、SideColumnの適切な役割分担
継承チェーン管理: 基底クラスとの重複回避と機能拡張

3. ベストプラクティス：成功事例の自動反映

過去の成功事例から抽出した実装パターンが蓄積されており、AIは常に「実証済みの最良の方法」を選択します。これにより、新人エンジニアでもベテランレベルの実装品質を実現できます。

第2層：自動テスト12検証項目による実装品質の保証

自動テスト設計ガイドによって生成されたコードは、次に自動テスト12検証項目によって自動チェックされます。これは、人間のレビューでは見落としがちな品質項目を機械的にチェックする仕組みです。

自動テスト12検証項目の詳細

TypeScriptコンパイルエラー検証: 型安全性の完全確保
セレクター存在確認: HTMLファイルとの整合性チェック
既存コード重複チェック: DRY原則の徹底
アーキテクチャ整合性検証: PageObjectモデルの原則遵守
Component責任分離確認: 適切な役割分担の検証
継承チェーン整合性: 基底クラスとの重複回避
パラメータ化適切性: 再利用性の確保
エラーハンドリング完備: 異常系の適切な処理
テストデータ整合性: SharedDataの適切な利用
Modal初期化処理: 動的要素の確実な処理
言語対応適切性: 多言語環境での動作保証
実行時安定性: Flakyテスト要因の排除

実際の検証プロセス

AIは生成したコードに対して、以下の自己検証ループを実行します：

## 🔍 自動検証プロセス

### Phase 1: 静的解析
- TypeScriptコンパイル実行
- セレクター存在確認（HTMLファイル参照）
- 既存コード重複検出（codebase_search活用）

### Phase 2: アーキテクチャ検証
- PageObject継承関係チェック
- Component責任分離確認
- 設計原則遵守検証

### Phase 3: 品質保証
- エラーハンドリング完備確認
- パラメータ化適切性検証
- 実行時安定性評価

### Phase 4: 自動修正
- 検証失敗項目の自動修正
- 再検証実行
- 全項目クリアまで反復

人間がレビューする場合、「このくらいなら大丈夫だろう」といった主観的判断が入りがちです。しかしAIは、感情や疲労に左右されることなく、常に同じ基準で厳密にチェックし続けます。

第3層：CircleCI統合による実行品質の保証

最後に、CircleCIでの実行フローにより、長年培われた品質基準を継承します：

AI化以前と同じ実行環境: 新しいリスクを導入せず、実証済みの安定性を維持
予約・キャンセル・課金等の重要機能: 既存の監視・アラート体制をそのまま活用
従来と同じ品質基準: AIが生成したコードも、人間が書いたコードと同等の基準で評価
運用チームの学習コストゼロ: 新しいツールの習得不要で、即座に本格運用が可能

この3層構造により、「AIが生成したコードでありながら、人間が書いたコードと同等の品質と信頼性」を実現しています。特に重要なのは、各層が独立して機能しながらも、相互に補完し合う設計になっていることです。

プロンプトエンジニアリングの実践：暗黙知の明文化

3層品質保証システムの基盤となるのが、プロンプトエンジニアリングです。私たちが直面した最大の課題は、「QAチームの暗黙知をどのようにAIに伝えるか」でした。

強制学習メカニズム：AIの「嘘をつく」問題の解決

AIの「嘘をつく」傾向を防ぐため、禁止事項をチェックリストとしてプロンプトを通してAIに渡すようにしました。私たちはこれを強制学習メカニズムと呼んでいます。

## ⚠️ AI実行前必須チェックリスト

### ✅ 絶対禁止事項の確認 - 100%遵守必須

- [ ] Step Definition内でseleniumAdapterを直接使用することは絶対禁止
- [ ] 既存コンポーネントを調査せずに重複作成することは禁止
- [ ] Component継承関係を無視した不適切な使用は絶対禁止

### 🚨 実行前最終確認

以下にすべて「はい」で答えられない場合は実装を開始しない：
- 既存の類似コンポーネントを`codebase_search`で調査済みか？ → **はい/いいえ**
- 12項目検証をすべて実行する具体的手順を理解したか？ → **はい/いいえ**

この仕組みにより、AIは作業開始前に必ず既存コードを調査し、重複実装を回避するようになりました。

Few-shotプロンプティングによる精度向上

テスト仕様からGherkin Feature ファイルを生成する際、私たちはFew-shotプロンプティングを活用しました。

入力例

テスト仕様JSON：

{
  "予約経路": "No6",
  "観点": "予約経路：インバウンド予約登録",
  "テスト目的": "メニュー・コースカレンダー：予約登録",
  "テスト手順": "1.テスト対象店舗のメディアTOP画面にて、「English」からインバウンド画面を表示する\n2. menuのタブを選択する\n3. コースの「Reserve」ボタンを押下する..."
}

これに加えて：
- HTMLファイル群（画面遷移の各ステップ）
- 操作のRecording JSON

AI生成出力

Feature: 予約経路：インバウンド予約登録

  @pc @reservation-route-inbound @russian-blue @reservation-route-test @mailpit
  Scenario Outline: No6-インバウンド予約確認-メニュー・コースカレンダー-予約登録
    Given "PC"店舗詳細"トップ"ページ'{ "店舗名": "<restaurant_name>" }'に移動する
    And restaurantシステムでデバイス"PC"と言語"<language>"を設定しインバウンド店舗詳細トップに移動する
    When restaurantシステムのPCインバウンド"店舗詳細トップ"ページで"Menu"をクリックする
    And restaurantシステムのPCインバウンド"店舗詳細コース"ページで"<course>"を予約する
    ...

    Examples:
      | language | countryCode | restaurant_name                        | course        | visitDate | childCount |
      | English  | 1           | 自動テスト52_ノート_インバウンドキャンポリ有 | テストコース2 | 2         | 1          |

生成されたTypeScriptコードの品質分析

実際にAIが生成したコードの一例を見てみましょう：

// Step Definition
When<CustomWorld>(
  "restaurantシステムのPCインバウンド{string}ページで{string}をクリックする",
  { timeout: CUCUMBER_TIMEOUT * 1000 },
  async function (pageType: string, buttonText: string) {
    const parsedPageType = z
      .union([z.literal("店舗詳細トップ")])
      .parse(pageType);

    if (parsedPageType === "店舗詳細トップ" && buttonText === "Menu") {
      const currentPage = this.scenarioContext.currentPage;
      
      if (currentPage?.displayName !== "PCインバウンド店舗詳細トップ") {
        throw new Error(`Expected PCインバウンド店舗詳細トップ, but got ${currentPage?.displayName}`);
      }

      const inboundTopPage = currentPage as InstanceType<(typeof pageList)["PCインバウンド店舗詳細トップ"]>;
      const coursePage = await inboundTopPage.clickMenuButton();
      this.scenarioContext.currentPage = coursePage;
    }
  },
);

// PageObject Component
export class InboundRestaurantDetailCoursePage<
  T extends RestaurantSystemHelper,
  U extends LanguageSelection,
> extends PCBasePage<T> {
  #languageMode: U;
  public inboundReservationModalCalendar: InboundReservationModalCalendar<typeof this> | null = null;

  public async reserveCourse(courseName: string): Promise<InboundReservationModalCalendar<typeof this>> {
    const courseReserveButtonSelector = {
      by: "xpath",
      arg: `//div[contains(@class, "rstdtl-course-info")]//h4[contains(text(), "${courseName}")]/parent::*//a[contains(@class, "js-booking") or contains(text(), "Reserve")]`,
    } as const;

    await seleniumAdapter.clickBy(courseReserveButtonSelector);

    this.inboundReservationModalCalendar = new InboundReservationModalCalendar(this, this.#languageMode);
    await this.inboundReservationModalCalendar.prepare();

    return this.inboundReservationModalCalendar;
  }
}

品質分析のポイント：

型安全性の徹底: zodスキーマによる実行時バリデーションと静的型推論
責任分離の適切な実装: Step Definitionはビジネスロジック、PageObjectは画面操作
エラーハンドリングの実装: 期待しないページ状態の検出（リトライ機構なども含む）
再利用性の確保: 言語モードなどのパラメータによる柔軟な対応
アーキテクチャ原則の遵守: 継承関係とComponent責任分離の適切な実装

人間が書いた場合によくある問題（型の不整合、エラーハンドリングの不備、責任分離の曖昧さ）を、AIが一定レベルで解決できています。ただし、アサーション関数の活用やより高度なエラーハンドリング（リトライ機構など）については、まだ改善の余地があります。

実プロジェクトでの検証へ

これらの技術実装により、自動テスト設計ガイドと12検証項目による高精度なコード生成システムが完成しました。しかし、この技術が実際のプロジェクトでどのような効果を発揮するのか、具体的な検証が必要でした。

次章では、メール取り込み機能の対象にOMAKASEを追加するプロジェクト（以下、OMAKASEプロジェクト）での実際の適用事例を通じて、97%超の生成精度がもたらした定量的効果と現場での体験について詳しく解説します。

97%の成果：OMAKASEプロジェクトで見えた新しい現実

今回私たちは、メール取り込み機能の対象にOMAKASEを追加するプロジェクトでPhase2を適用しました。このプロジェクトは、食べログノートのメール取り込み機能で「取り込み可能なサイトを1つ追加する」という小さな機能追加ですが、業務の影響範囲が大きいため、典型的な軽微な修正問題のプロジェクトでした。このプロジェクトでPhase2を適用し、AIが生成した自動テストコードをメンバーがレビューしたときのコメントがこちらです。

「これ、本当にAIが書いたの？」

生成されたコードを確認しながら、私たちは印象的な光景を目の当たりにしていました。

事例1: LanguageModeパラメータエラーの自動修正

// 修正前のエラー
TypeError: Cannot read properties of undefined (reading 'languageMode') エラーを修正しました。

🔧 修正内容

問題の原因:
• Step Definition で getPage() 呼び出し時に必要な languageMode パラメータが不足していた
• InboundRestaurantDetailTopPage のコンストラクタで pageParams.languageMode が undefined

修正したStep Definition (5個):
1. Step 3 - Menuボタンクリック
2. Step 4 - コース予約
3. Step 6 - 詳細情報入力
4. Step 7 - メール送信
5. Step 9 - メール認証URL（既存のlanguageSelection取得方法を統一化）

修正パターン:
// 修正前
const currentPage = await this.scenarioContext.restaurantSystemHelper.getPage(

// 修正後
const languageSelection = this.scenarioContext.inboundLanguage;
const currentPage = await this.scenarioContext.restaurantSystemHelper.getPage(
  languageMode: languageSelection,
});

🎯 技術的詳細
• 言語取得: this.scenarioContext.inboundLanguage で統一
• パラメータ: { languageMode: languageSelection } を全Step Definitionに追加
• 既存連携: Step 2 の言語設定（setInboundDeviceAndLanguage）と完全連携

事例2: 国際化対応のkeyByType修正

keyByTypeとは: PageObjectにおいて、ページの読み込み完了を検証するためのキー要素です。このセレクターが正常に取得できることで、ページが完全に表示され、次の操作に進める状態であることを保証します。

// InboundRestaurantDetailCoursePage の keyByType を国際化対応に修正いたしました。

🔧 修正内容

修正前の問題:
• 固定のXPath //*[contains(@class, "rstdtl-course-info")] でページ内要素が見つからない
• 国際化非対応（英語のみ）

修正後の改善:
protected get keyByType(): seleniumAdapter.ByType {
  const tabNameMapper = {
    English: "Menu",
    简体中文: "菜单",
    繁體中文: "菜單", 
    한국어: "메뉴",
  } as const;
  
  const tabName = tabNameMapper[this.#languageMode];
  return {
    by: "xpath",
    arg: `//*[contains(@class,"rstdtl-navi__list-item is-selected")]//*[text()="${tabName}"]`,
  };
}

事例3: XPath最適化による要素特定の改善

// 問題点
• 完全一致マッチング: @class="js-booking-modal-target" は、class属性の値が完全に一致する場合のみマッチ
• HTML構造の実情: 実際のHTML要素は複数のCSSクラスを持つことが一般的（例：class="c-overlay js-overlay js-booking-modal-target"）
• マッチング失敗: 他のクラスが併記されている場合、完全一致では要素を特定できない

✅ 修正内容

修正後（改善された配法）:
// xpath
//div[contains(@class, "js-booking-modal-target")]//p[@data-year='${year}' and @data-month='${month}']

改善点:
• 部分一致マッチング: contains(@class, "js-booking-modal-target") により、対象クラスが含まれていれば確実にマッチ
• 動的クラス対応: JavaScriptによる動的なクラス追加・削除にも柔軟に対応
• 堅牢性向上: HTML構造の微細な変更に対する耐性を獲得

🔧 追加の対策

Modal内操作の精密化のため、以下の要素についても同様の修正を実施：

1. 人数選択: //div[contains(@class, "js-booking-modal-target")]//select[contains(@class, "js-svps")]//option[@value="${count}"]

2. 時間選択: //div[contains(@class, "js-booking-modal-target")]//select[contains(@class, "js-svt")]//option[@value="${time}"]

3. 予約ボタン: //div[contains(@class, "js-booking-modal-target")]//*[contains(@class, "js-booking-form-open")]

📊 効果
• 要素特定成功率: 100%（従来の断続的な失敗から安定化）
• 実行時間短縮: タイムアウトエラー（100秒）の完全解消
• 保守性向上: HTML構造変更への対応力強化

以上は、OMAKASEプロジェクトでの実際のAI自己修正プロセスです。AIが生成したコードをテスト実行した際にエラーが発生しましたが、AIがエラーログを分析し、自動的に適切な修正を行いました。注目すべき点として、修正された内容はページのxpathレベルの微細な調整のみで、コードの根本的な構造には問題がありませんでした。

なお、私たちは最終的な品質確認として人間による戦略的レビューも実施していますが、この事例では人間の介入は不要でした。AIの12検証項目による自己チェックと、テスト実行時の自動修正により、高品質なコードが完成したのです。

「これ、本当にAIが書いたコードなの？」

チームメンバーから思わず漏れたこの言葉が、私たちの実感を端的に表していました。従来なら0から全て1行1行を手動入力していたコードが、今では自動的に生成され、しかもその品質は安定して高いレベルを維持していたのです。

体感できる大きな変化がありました。従来は1週間で15件のテストケース自動化が精一杯でしたが、現在では37件ものテストケースを自動化できるようになったのです。2.5倍という数字以上に、「毎日が違う」という実感がありました。

この数字以上に注目すべきは、「修正がほぼ不要」という現実でした。

数字が語る変化の実態

感情的な驚きを客観的な数字で検証してみましょう。OMAKASEプロジェクトは、既存のメール取り込み予約経路に新しい経路を追加する案件で、私たちの技術実装を本格投入した最初の実証実験でした。

測定可能な成果：

項目	従来	AI化後	改善効果
テスト実行工数	0.9人月	0.43人月	52%削減
自動化率	24%	64%（703件/1,102件）	40%増加
自動テストコーディング工数	1.7人月	0.7人月	58.8%削減

AI生成精度の実測値：

生成精度 = AIが生成し自己修正したコード行数 / (AIが生成し自己修正したコード行数 + 人間が修正したコード行数)

この計算式で測定した結果：
- Page Object：97.26%（人間による修正：2.74%）
- Step Definition：92.63%（人間による修正：7.37%）

重要なポイントは、分子には、AIの初回生成から自己検証・自動修正までの全プロセスが含まれていることです。つまり、AIが初回生成→自己検証→自動修正を経て、最終的にどうしても修正できなかった部分のみを人間が修正したということです。

AIの自己修正能力により、人間による修正は全体の3〜7%程度に抑えられました。この数字は、実際のプロジェクトで測定された、リアルな成果です。

では、なぜこれほど高い精度を実現できたのでしょうか？その要因は、私たちが開発した「自動テスト設計ガイド」と「12の検証項目」による多層的な品質保証システムにあります。

設計ガイドが生きた瞬間

3-4章で説明した技術が実際にどう機能したのか、具体的な事例で検証してみましょう。

自動テスト設計ガイドの実際の効果

PageObjectとComponentObjectの自動分離

あるPageObject内にModal、Frame等のコンポーネント要素が存在する場合、保守性を担保するため、これらの要素と操作はComponent Objectに分離すべきです。従来は人間が手動で責任分離を考慮する必要があり、経験不足により適切な分離ができないという課題がありました。

しかし、自動テスト設計ガイドにより、AIがPageObjectとComponentObjectの役割を適切に理解し、正しく分離して実装できるようになりました。実際に、複雑なModal構造を持つ予約画面でも、AIは適切な責任分離を行うことができました。

自動テスト12検証項目の威力

12の検証項目が実際にどのような効果を発揮したのか、具体的な事例で見てみましょう。

「既存Step重複チェックを必ず実行する」という項目では、既存の類似実装を自動検出し、重複を効果的に回避できました。DRY原則の徹底により、保守性が大幅に向上したのです。

また、「Modal Component条件初期化確認を必ず実行する」という項目では、動的に表示されるModalの初期化処理を確実に実装し、Flakyテストの原因となる要素を事前に排除できました。

さらに印象的だったのは、AIの自動修正能力です。テスト実行時にエラーが発生した際、AIはエラーログを分析し、即座に適切な修正を行いました。修正内容はxpathレベルの精密な調整で、コードの設計思想は最初から正確に実装されていました。

見えてきた新しい地平

OMAKASEプロジェクトを通じて、私たちは一定の成果を実現しました。テスト実行工数52%削減という明確な数値を達成し、品質を保ちながらの効率化を実現できたのです。

序盤で設定した2つの目標について、達成状況を確認してみましょう。

目標1：テスト実行工数を78%削減する（2.3人月 → 0.5人月）

OMAKASEプロジェクトでは52%の削減を達成できました。AIと自動テストにより0.5人月の手動工数を削減し、その削減した工数を使って自動テスト資産を構築できたことが重要でした。目標の78%削減に対して、現時点での進捗は67%となっています。この取り組みをモデルケースとして、今後もテスト実行と資産構築を両立し続けることで、自動テストの割合が向上し、テスト実行工数のさらなる削減が見込めます。目標は12月に達成見込みです。

目標2：自動テスト資産構築による開発QA工数比率の適正化

OMAKASEプロジェクトでは、64%の自動化率を達成し、自動テスト資産の蓄積が確実に進行していることを実証できました。今回の結果から、自動化率を90-95%まで向上させることで開発とQAの工数比率を1:1へと適正化できることが判明しました。この水準への到達は、あと4-5案件の継続的な資産構築により12月末までに達成可能な見込みです。このアプローチにより、軽微な修正問題という業界の構造的課題に対する根本的な解決策を確立できました。

手動QAエンジニアの変化と組織展開

プロジェクトリーダーとして認識した課題

AI4QA Phase2の技術的な成功の一方で、私はプロジェクトリーダーとして実装上の課題を認識していました。新しい技術導入時の自然な学習プロセスへの対応が必要だったのです。手動QAエンジニアの多くは開発経験が少なく、Cucumber + Seleniumフレームワークの理解に学習期間を要しました。また、画面HTMLファイルと操作Recordingの準備についても、技術的な習得プロセスが必要でした。技術的な解決策がいくら優れていても、メンバーのスキルレベルに応じた効果的な学習支援がなければ、真の成果は得られません。私たちリーダー陣は、技術導入と人材育成を両立させる必要がありました。

メンバーのスキルアップを支援した段階的アプローチ

この課題に対して、私たちは効果的な学習支援策を設計し、段階的なアプローチを採用しました。

まず、スモールスタート戦略による学習効率化です。メンバーの学習負荷を考慮し、いきなり複雑なテストケースから始めるのではなく、既存シナリオへのstep追加など、理解しやすい範囲からスタートする戦略を設計しました。成功体験を通じた自然なスキルアップを促進することができました。

次に、モブプログラミングによる知識伝播を行いました。経験豊富なメンバーとの協働による効率的な学習機会を創出し、HTMLファイルを使って既存featureファイルに新しいstepを追加する実践を通じて、チーム全体での知識共有文化を構築することができました。

さらに、学習負荷軽減の実証と共有も重要でした。画面操作Recording不要で進められるケースを検証し、学習ハードルを低減する方法を実証しました。「段階的に習得できる」という結果をメンバーに共有することで、AI活用における学習プロセスを最適化できたのです。

現在進行中・将来に向けた取り組みも並行して進めています。 Gherkinベース移行による学習効率向上では、現在、テストケースをGherkin形式に移行する取り組みを進めています。これにより、AIとの連携をより直感的にし、メンバーの理解度向上を図っています。

メンバーの成長を実感した瞬間：部の全体会議デモ

そして、私がプロジェクトリーダーとして最も手応えを感じた瞬間が訪れました。部の全体会議で、手動QAエンジニア出身のメンバーが自身の学習成果をデモしてくれたのです。数ヶ月前まで「AIなんて使えるのかな？」と不安そうにしていた彼が、今では堂々と成果を発表している。その姿を目の当たりにした時、適切な学習支援により技術的な課題を乗り越えられる手応えを感じました。

「6人日が0.6人日になりました」- 数字が語る成長

発表の冒頭、メンバーが報告した成果に会場がざわめきました。「AI（Cursor）を十分に使用できていなかった頃と比較して、Mergeするまでの実装工数がおおよそ5.4人日削減できました」と彼は説明しました。具体的な数字が示すインパクトは圧倒的でした。従来なら6人日以上かかっていた作業が、わずか0.625人日で完了したのです。約10倍の効率化という数字以上に、メンバー自身が自信を持ってこの成果を語る姿に、私は深い感動を覚えました。

学習の軌跡：不安から自信へ

続いて、メンバーは自分の学習プロセスを振り返りました。「最初は担当案件の複雑な業務ロジックの自動テストコーディングなんて、どこから手をつけていいかわからなかった」と正直に語ります。「でも、段階的にアプローチしていけば、予約詳細画面から社内管理画面まで、一つずつ理解できるようになりました。AIとの対話も、最初は何を聞けばいいかわからなかったけど、今では自然に相談できるようになっています」彼の説明を聞いていると、もはや「学習者」ではなく「実践者」として話していることがわかりました。

AIとの協働で見つけた新しい働き方

特に印象的だったのは、具体的なトラブル解決の体験談でした。「同じStepを共有している２つの異なる機能で重複エラーが発生して、最初はパニックになりました。でも、AIに状況を説明して一緒に分析していくうちに、適切な条件分岐で解決できることがわかったんです」と彼は振り返ります。「AIって、思っていたより話しやすくて、一緒に問題を解決してくれる感じなんです」という彼の言葉から、単なる「ツール使用」を超えた、AIとの効果的な協働関係が生まれていることがわかりました。

「よかったこと」に込められた成長の実感

発表の終盤、メンバーが振り返った「よかったこと」が印象的でした。「段階的なアプローチで進められたこと、HTMLファイルをうまく活用できたこと、AIの分析結果の間違いに気づけるようになったこと、そしてエラー分析から修正まで全部AIに任せられるようになったこと」彼が挙げたこれらのポイントは、単なる技術的な学習成果ではありません。問題解決能力、批判的思考力、そしてAIとの効果的な協働スキルの習得を示していました。

「コーディングが好きになりました」

質疑応答の時間で、参加者から「既存のローコードツールとAI4QA、どちらが好きですか？」という質問が出ました。彼の答えは即座でした。「自分はコーディングが好きになったので、AI4QAの方が好きです」数ヶ月前まで「プログラミングは難しそう」と言っていた彼が、今では「コーディングが好き」と言っている。この変化こそが、私たちの取り組みの重要な成果でした。単なるツール操作ではなく、実際のプログラミングを通じた学習に価値を感じ、自分自身の可能性を発見できたのです。

組織展開への確信と道筋

メンバーの成長を目の当たりにしたことで、私は組織全体への展開可能性を確信しました。効果的な学習支援プロセスが体系化できたことで、スケールアップの基盤が整ったのです。

10月以降、月平均4プロジェクトへの展開を計画し、AIネイティブ化レベル2の安定運用に向けた学習支援体制の構築を本格化させています。（カカクコム社のAIネイティブ化への道についての記事はこちら）

技術導入と人材育成を両輪で進めることの重要性を実感しました。メンバーの学習支援がプロジェクト成功の鍵であり、個人の成長が組織全体の変革につながる。これこそが、AI4QA Phase2の真の価値だったのです。

業界変革への実践的提言

実証された解決策

私たちが取り組んできた「軽微な修正問題」は、QA業界全体が直面している構造的な課題です。機能追加や改修のたびに発生する回帰テスト工数の増大、品質要求の高度化と人手不足の板挟み。従来の手作業による品質確保手法では、もはや持続可能性に限界が見えています。

しかし、AI4QA Phase2の成果は、この構造的課題に対する現実的な解決策を示しています。テスト実行工数52%削減と97%の自動コード生成精度は、単なる効率化以上の意味を持ちます。それは、テスト実行と資産構築を両立し続けることで、軽微な修正問題を解決できることを意味しているのです。また、QAエンジニアの時間を「テスト実行」から「品質戦略の立案」へと解放する可能性を実証しました。私たちが選択したAI4QAアプローチは、既存の自動化のアプローチである、1.エンジニアによる直接コーディング、2.ノーコードツールによる自動化に対する「第三の道」として位置づけられます。

私たちの成功要因は、他の組織でも再現可能な戦略的判断に基づいています。業界標準であるGherkinやPageObjectの活用、HTMLファイルや操作Recording による暗黙知の明示化、段階的導入による組織受容性の向上。これらの要因は、組織規模や技術スタックに関わらず適用可能であり、スキル格差問題の解決、属人化リスクの軽減、工数予測精度の向上を実現できます。

QAエンジニアの価値進化

我々のAI4QAのアプローチは、QAエンジニアの価値そのものを再定義し向上するものです。従来の「テストを実行する人」や「テスト実行手順をノーコードツールに教える人」から「品質戦略を設計する人」への転換が進んでいます。AIが得意なルーチンワークは任せ、人間は創造性を要する戦略的思考に集中する。この分業により、両者の価値が最大化されます。

「コーディングが好きになりました」というメンバーの言葉が象徴するように、AI協働による新しい働き方は個人の可能性を大きく拡張します。従来の品質保証スキルに加えて、AI活用スキルと戦略的思考力を両立できる人材が、今後のQA業界を牽引していくでしょう。技術スペシャリスト、品質戦略コンサルタント、AI活用エキスパートなど、多様なキャリアパスが見えてきました。

未来への行動

この変革を一社だけで進めることには限界があります。業界全体での取り組みが必要です。私たちは、ソフトウェア品質シンポジウムでの論文発表を計画しており、オープンな情報交換により業界全体の発展に貢献したいと考えています。AI活用QAのベストプラクティスを業界標準として確立し、同じ課題に取り組む組織同士が連携できる環境を作ることが重要です。

品質保証の未来は、私たち一人ひとりの手で創られます。新しい技術を恐れるのではなく、積極的に活用し、より良い働き方を模索していく。AIネイティブ化レベル3の実現により、品質保証の可能性はさらに拡張されるでしょう。食べログQAチームでは、この変革の最前線で働く仲間を募集しています。新しい働き方への挑戦意欲、チームでの学び合いを大切にする姿勢、そして業界の未来を一緒に創っていく意欲を持った方々と、AIを活用した品質保証の未来を共に創っていきましょう。