✅

LLM時代のQA再設計──自動化ツール群で考えた「品質保証の再定義」

に公開
CI
QA
品質管理
テスト自動化
sdet
tech

ポートフォリオ解説 – QA/SDET向け自動化ツールの全体像

LLM時代における「品質保証」を再設計する試み

GitHub:
RNA4219/portfolio

はじめに

このポートフォリオは、**「LLMが存在する時代にQAをどう再定義するか」**という問いから始まりました。
もともとはQA/SDETとして、仕様・実装・テストが分断された開発フローに課題を感じており、
そこに生成AIが加わったとき、品質保証の概念そのものが変わると感じたのが出発点です。

私は当時、以下のような問題意識を抱えていました。

  • 仕様書どおりに作っても、あるいは作るからこそ、実際の挙動が想定外になる
  • E2Eテストを人手で保守するのが非効率すぎる
  • CIでFlakyテストを検出しても、原因追跡が属人化する
  • LLMを導入しても「品質をどう測るか」が曖昧

このような課題を整理し、「QAを自動化・構造化するためのPoC群」として開発したのが以下の4つのツールです。
開発当時は純粋なQAツールとして構想していましたが、振り返ると**“LLM品質管理の原型”**になっていました。

1. Spec2Cases CLI – 仕様書からテストケースを生成

目的
仕様書から実装やテストケースが自動的に作られるべきフローを模索する中で、
「仕様破綻に気づくのが遅れる」「検収時に追加工数が発生する」といった問題がありました。
それなら仕様書を直接構造化データ化して、早期に破綻を検知できないかという実験です。

概要
Markdown／テキスト仕様から構造化テストケース(JSON)を生成するCLI。
LLMによるドラフト生成＋ルールベース整形・検証を前提としたパイプラインを想定しています。

主要コマンド

  • npm run spec:generate：仕様書(Markdown)→JSONケースに変換
  • npm run spec:validate：スキーマ検証
  • npm run spec:run：タグ/ID指定で擬似実行

特徴

  • scripts/spec2cases.mjs が入力ファイル拡張子を判定し、parseSpecText で仕様を構文解析。
  • Markdown見出しをID・タイトルに変換し、pre:, steps:, expected: などを自動抽出。
  • 欠落フィールドを検出して具体的に報告。

再現例

npm run spec:generate -- spec.sample.md
npm run spec:validate -- cases.generated.json
npm run spec:run -- cases.generated.json --tag smoke

開発背景
仕様が曖昧なまま実装に入る現場を見てきた中で、
「人間が読む仕様」と「機械が理解できる仕様」を繋ぐ装置が必要だと感じていました。
Spec2Casesはその“橋渡し”を形にした最初の試みです。

2. LLM → Playwright Pipeline – LLM補完からE2Eテスト生成

目的
バイブコーディングを実践していた頃、
「E2Eテストも自然言語で生成・実行できたら楽だろう」という発想から生まれました。
受け入れ基準をLLMが補完し、Playwright互換のテストコードを自動生成・実行・可視化するPoCです。

主要コマンド

  • npm run e2e:gen：ブループリントからPlaywrightテストコードを生成
  • npm test：スタブランナーで実行

特徴

  • scripts/blueprint_to_code.mjs がブループリントJSONから.spec.tsを生成
  • 各シナリオで重複ID検出・正規化を実施
  • waitForLoadState('networkidle')挿入などの安定化処理
  • url:, text:などのプレフィックスでアサーション種別を自動展開

再現例

npm install
npm run generate -- blueprint.sample.json
npx playwright test

開発背景
コードを書くと同時にテストが生成される「双方向性」を求めた結果、
このパイプラインは**「E2EテストをLLMが書く」**というコンセプトに進化しました。
当時は“実験”のつもりでしたが、今見ると自然言語駆動開発の原型です。

3. CI Flaky Analyzer – Flakyテストの検出とレポート生成

目的
継続的なテスト運用の中で、Flakyテスト（再現率が低い不安定なテスト）の監視は地味ながら重大な課題です。
この負担を自動化するため、JUnit形式のテスト結果を解析し、Flaky度をスコア化・可視化するCLIを実装しました。

主要コマンド

  • flaky parse：JUnit XMLをストリーム解析しJSONLへ追記
  • flaky analyze：履歴からスコア集計・HTMLレポート生成
  • flaky issue：閾値を超えたテストをMarkdownテンプレートに出力
  • flaky weekly：週次サマリを生成

特徴

  • ストリーミング解析によりメモリ消費を最小化
  • HTML/CSV/JSON出力をサポート（out/index.htmlをCI Artifact化可能）
  • Dry-runモードでIssueテンプレート確認が可能

再現例

flaky parse -- junit/results.xml
flaky analyze --config projects/03-ci-flaky/config/flaky.yml
flaky issue --top-n 10

開発背景
CIの品質向上を定量的に測る仕組みが乏しかった当時、
**「テスト結果を“点”ではなく“傾向”として見る」**という発想で設計しました。
Flaky Analyzerはそのまま週次レポートに繋げられるため、
QAチームのフィードバックループを短縮する実験基盤にもなっています。

4. LLM Adapter – 複数プロバイダの比較と計測

目的
複数のLLMプロバイダ（OpenAI, Gemini, Ollama, OpenRouterなど）を統一インタフェースで呼び出し、
応答品質・コスト・速度を比較しながらベンチマークを取るアダプタです。
本来は「LLMオーケストレーター」を作る予定でしたが、
開発の過程で“LLMの品質を計測するツール”へと変化しました。

主要コマンド

  • llm-adapter --provider [config] --prompt "..." --out out
  • python adapter/run_compare.py --prompts datasets/golden/tasks.jsonl
  • just report（Python/Node統合の簡易レポート生成）

特徴

  • adapter/core/metrics/update.py がRunMetricsを集計し、
    　トークン使用量・エラー・リトライ回数を記録
  • 並列/順次実行を選択でき、シャドウラン比較にも対応
  • 失敗リクエストもメトリクスに残すため、後続分析に有用

再現例

pip install -e .
llm-adapter --provider openai.yaml --prompt "日本語で1行、自己紹介して" --out out
python adapter/run_compare.py --prompts datasets/golden/tasks.jsonl

開発背景
複数LLMを併用する開発ではAPIコストが課題でした。
「開発時に呼び出さなくても比較できる仕組み」があれば
**テストと推論の“事前評価”**が可能になると考え、
実験的にメトリクスを記録する仕組みを作りました。
結果的に、今の自分が取り組んでいるLLM開発R&Dの土台になっています。

GitHub Pages & Weekly Summary

このリポジトリはGitHub Pagesによるドキュメントサイトも構築しています。
docs/en/index.md に各プロジェクトの概要を掲載し、
週次のQA活動を自動要約して公開するワークフローを実装しました。
単体でも使えるツールですが、**全体で「自動化されたQAライフサイクル」**を再現します。

総括 – 「LLMを品質管理する」という発想

これら4つのツール群を通して、私は次のことを確信しました。

QAとは「仕様と実装の整合性」を守る仕事ではなく、
**「生成過程そのものの品質を観測し、制御する仕事」**になる。

Spec2Casesは仕様整合の自動検出、
Playwright Pipelineは自然言語によるテスト生成、
Flaky Analyzerは運用品質の可視化、
LLM AdapterはAI出力の信頼性評価——
それぞれの要素が今、私のR&D開発思想の根底を成しています。

このポートフォリオはもはや現行の開発方針とは異なります。
しかし、**“自動化の限界線を押し広げようとした軌跡”**として、
いま振り返ってもひとつの重要な通過点でした。

おわりに

当時はQAの延長として作ったこれらのツールも、
いま思えば「LLMを品質保証の対象とする」最初の布石でした。
コード品質・応答安定性・人間との協調性をどう定義するか。
それを考え続けることが、いまの自分の開発軸に繋がっています。

関連リンク

Discussion