ジェンスパーク(Genspark)で構築したGemini QA Framework - AI品質保証

1. はじめに: AI品質保証の必要性

Webアプリの開発を進める中で、記事作成や仕様書作成において何度も修正を繰り返す状況が続いていました。エリック（上流工程担当AI）が生成した内容を、ユーザーである私が一つ一つチェックし、問題点を指摘して修正させる——このプロセスは非常に時間がかかり、効率的ではありませんでした。

記事53-46で明らかになったように、エリックの判断力には限界があり(記事51: エリックの判断力テスト)、ユーザーによる第三者チェックが不可欠でした。しかし、すべてを手動でチェックするのは現実的ではありません。

そこで構築したのがGemini QA Frameworkです。このフレームワークは、Gemini API（Googleの生成AIモデル）を活用して、記事や仕様書の品質を自動でチェックし、問題点を指摘・差し戻しを行います。本来私が行うべきチェック作業をGeminiが代替することで、開発工数を大幅に削減することができました。

2. 構築の背景: なぜGemini QA Frameworkが必要だったのか

2-1. 記事53-46で明らかになった課題

記事53-46のシリーズで、以下の問題が明らかになりました：

  • エリックの判断力の限界: 記事51の実験で、エリックの判断力は中学生レベルであることが判明しました。上流工程（設計・要求定義）を担当するAIとして、この判断力では不十分です。
  • ユーザーチェックの負担: エリックが生成した記事や仕様書を、私が一つ一つ確認し、修正指示を出していました。記事1本あたり4〜5回の修正が必要なこともありました。
  • 品質のばらつき: エリックの出力品質は安定せず、誤った情報や論理的な矛盾が含まれることがありました。

2-2. 記事52で実証されたGeminiの品質保証能力

記事52(AI開発における品質保証の重要性)で、Gemini APIを使った批判的評価が非常に有効であることが分かりました。Geminiは：

  • エリックの分析結果の論理的矛盾を指摘
  • 証拠不足や推定ベースの結論を発見
  • 実装前に問題点を洗い出し、手戻りを防止

この成功を受けて、Gemini APIをフレームワーク化し、開発のあらゆるフェーズで自動的に品質チェックを行う仕組みを構築することにしました。

3. Gemini QA Frameworkの概要

💡 Gemini QA Frameworkの目的
本フレームワークの最大の目的は、ユーザーの品質チェック工数を削減することです。本来ユーザーが何度もチェックして修正指示を出すべき作業を、Geminiが自動で実施します。これにより、ユーザーは開発の本質的な部分に集中できるようになります。

3-1. 主な機能

  • 自動品質チェック: 記事、仕様書、設計書などの成果物を自動評価
  • 批判的評価モード: Gemini APIのtemperature設定を0.3に設定し、慎重な評価を実施
  • 6つのフェーズ別品質基準: 要求定義、仕様書作成、問題分析、設計、テスト完了時、デプロイ前——それぞれのフェーズに応じた品質基準で評価
  • フェーズ自動判定: キーワードベースで現在のフェーズを自動判定し、適切な評価基準を適用
  • 会話履歴の自動取得（v2で実装）: 現在の会話セッション全体を自動取得し、文脈を考慮した評価を実施

3-2. 評価基準

Gemini QA Frameworkは、以下の観点で成果物を評価します：

  1. 会話履歴との整合性（最重要）: ユーザーの指示や過去の会話内容と矛盾していないか
  2. 論理的整合性: 記述内容に矛盾がないか、論理的に一貫しているか
  3. 専門用語の説明: 初出の専門用語が適切に説明されているか
  4. 読者視点: 初学者にも理解できる内容か、具体例が十分か
  5. SEO最適化: タイトルにキーワードが含まれているか（メタディスクリプションは評価対象外）

3-3. 出力形式

Geminiは以下のJSON形式で評価結果を出力します：

{ "overall_quality": "excellent|good|acceptable|needs_improvement|poor", "quality_score": 1-10, "approval_status": "approved|conditional_approval|rejected", "critical_issues": [...], "major_issues": [...], "minor_issues": [...], "summary": "総合評価のサマリー" }

approval_statusがrejectedの場合、修正が必要です。conditional_approvalの場合は条件付き承認、approvedで正式承認となります。

4. 実装の詳細

4-1. スクリプトの構成

Gemini QA Frameworkは、Bashスクリプトとして実装されています：

  • article_quality_check_critical_fixed.sh（初期版）: 手動で会話履歴ファイルを指定する方式
  • article_quality_check_auto_v2.sh（改良版）: 現在の会話セッション全体を自動取得する方式（推奨）

4-2. 会話履歴の自動取得（重要な改善点）

v2スクリプトでは、会話履歴の取り扱いを大幅に改善しました：

  • ユーザー発言は完全版で保持: ユーザーの指示や要求は一字一句そのまま保持
  • AIアシスタントの発言は要約: 長い応答や冗長な部分を要約し、Gemini APIへのトークン消費を削減
  • 前回セッションからの引き継ぎ: オプションで前回の会話履歴ファイルを指定可能

この仕組みにより、Geminiは記事作成の全体的な流れを理解し、ユーザーの最新の指示（例: 「エリック・ジョージの記述を削除してください」）を正確に反映した評価を行えるようになりました。

4-3. Gemini APIの活用

Gemini QA Frameworkは、Gemini 2.5 Flashを使用しています：

  • モデル: gemini-2.5-flash
  • Temperature: 0.3（慎重な評価のため低めに設定）
  • 出力形式: JSON

ジェンスパーク(Genspark)のサンドボックス環境でBashスクリプトを実行し、curlコマンドでGemini APIを呼び出しています。

4-4. フェーズ自動判定のロジック

スクリプトは、キーワードベースでフェーズを自動判定します：

判定例：
  • 「テスト」「test」→ testing
  • 「関数」「class」→ implementation
  • 「問題」「根本原因」→ analysis
  • 「仕様書」「API仕様」→ specification
  • 「設計」「アーキテクチャ」→ design
  • 「要求」「要件」→ requirements

フェーズが特定できない場合は、汎用的な品質基準で評価します。

5. 運用と効果: 具体的な差し戻し事例

5-1. 占い開発 v2.20の事例（テスト不足の事前発見）

Webアプリのv2.20「ブログ記事生成最適化」の開発では、Geminiが以下の問題を指摘しました：

Gemini QA結果:
  • Overall Quality: needs_improvement
  • Test Coverage Score: 4/10
  • Critical Issues: 3件
    1. パフォーマンス目標の達成度が不明確
    2. エラーケースのテストが未実施（安定運用に懸念）
    3. 記事数90→30への変更の意図が不明確
  • 未実施テスト: 6項目
    • 実際のCron実行でのCPU時間測定
    • 長期間（1週間）の安定運用確認
    • エラーケースのテスト
    • 負荷テスト
    • セキュリティテスト
    • 記事生成の品質評価

Geminiの指摘を受けて、修正計画書（v2.20_修正計画.md）を作成し、以下の改善を実施しました：

  • CPU時間の削減: 1500~3000ms → 500~800ms（約67%削減）
  • 成功率の改善: 50% → 90%以上
  • 変更理由の明確化: 1日3記事→1日1記事への変更がCloudflare Workers Free プランのCPU時間制限を回避するためであることを明記
ユーザー工数削減効果:
私が気づかなかったテスト不足や潜在的な問題をGeminiが事前に発見しました。これにより、実装後の手戻りや本番環境でのトラブルを防ぐことができました。

5-2. ERIC分析の品質保証レビュー（実装阻止）

ERICの初期分析では、Gemini APIの503エラーの原因を「一時的な障害」と判断していました。しかし、Gemini QA Frameworkが以下の問題を指摘：

  • 根本原因の特定が不十分（推定ベースの分析）
  • 証拠データの不足
  • 仕様書・ドキュメントの読み込み不足

Geminiの最終評価は「実装不可」（Overall Rating: ⭐ 未熟）。この指摘により、不具合のある状態での実装を防ぎ、さらなる調査と修正が必要であることが明らかになりました。

ユーザー工数削減効果:
実装前にGeminiが問題を発見したことで、実装後の手戻りコストを大幅に削減しました。

5-3. 記事作成での事例（このブログ記事の品質改善）

本ブログ「ジェンスパーク(Genspark)開発奮闘記」の記事作成においても、Gemini QA Frameworkが活躍しています。記事51「ジェンスパークとGemini APIの選択 - AI開発環境の実践」では、Geminiが合計4回の差し戻しを行い、品質を段階的に改善しました：

チェック回数 Quality Score Approval Status 指摘内容
第1回 4/10 rejected Critical Issues 2件（エリックの限界の強調不足、矛盾説明不足）
Major Issues 2件（専門用語説明不足、論理的整合性欠如）
第2回 4/10 rejected 削除指示に反して重要提言ボックスが残存、エリック・ジョージの記述削除が不完全
第3回 6/10 ⬆ conditional_approval Major Issue 1件（Jupyter Notebookとプロンプトエンジニアリングの説明不足）
第4回 7/10 ⬆ conditional_approval Major Issue 1件（Cloudflare Workersの説明不足）
第5回 8/10 ⬆ approved ✅ Minor Issues 2件のみ、承認
ユーザー工数削減効果:
本来、私が4回にわたって記事を読み込み、問題点を指摘し、修正指示を出す必要がありました。Geminiがこの作業を自動で実施したことで、私の工数は大幅に削減されました。

6. まとめ: Gemini QA Frameworkの意義

Gemini QA Frameworkは、AI開発における品質保証を自動化し、ユーザーの工数を大幅に削減する仕組みです。

  • 占い開発: テスト不足を事前発見、CPU時間67%削減、成功率50%→90%改善
  • ERIC分析: 実装前の問題発見により、手戻りコストを削減
  • 記事作成: 4回の差し戻しで品質スコア 4/10 → 8/10
  • ユーザー工数: 本来ユーザーが実施すべき品質チェック作業をGeminiが代替

このフレームワークは、ジェンスパーク(Genspark)のサンドボックス環境とGemini APIを組み合わせることで実現しました。記事51で紹介した開発環境の選択が、このフレームワークの構築を可能にしました。

今後は、さらに多くの開発フェーズでGemini QA Frameworkを活用し、AI開発の品質向上と効率化を進めていきます。

関連記事