ジェンスパーク(Genspark)AI開発にV字モデルを適用 - エリック・ジョージ方式の初陣

📅 公開日: 2026年1月9日 | 📂 カテゴリ: 開発体験談 | ⏱️ 読了時間: 約10分

📑 目次

はじめに

「また同じような不具合が出た...修正してもまた別の場所で不具合が発生する」

ジェンスパーク(Genspark)を使ったWebアプリの開発で、私は深刻な問題に直面していました。SEO対策のためのプリレンダリング実装が誤ってトップページにも適用され、占い機能が完全に停止。修正自体は1日程度で完了したものの、AIが影響範囲を考慮せずに不具合を作り込んだことに、私はうんざりしていました。

ようやく占い機能を復旧させたと思ったら、今度は新たな不具合が2件も発見されました。この繰り返しを断ち切るために、私はV字モデルという伝統的なソフトウェア開発手法をAI開発に適用することを決意しました。

💡 重要な前提：この記事は「大成功」の美談ではありません。部分的に成功したものの、AIの判断力の限界も明らかになった、学びの記録です。

事件の背景：繰り返される不具合の連鎖

プリレンダリング実装の誤適用

問題の発端は、2025年12月15日に実装したv2.17.3のSEO対策でした。当時、ブログ記事をGoogle検索にインデックスさせるため、プリレンダリング（サーバーサイドレンダリング）を導入しました。

v2.17.3で実装した機能

  • 目的：Googlebotがクロール時にブログ記事の内容を認識できるようにする
  • 実装内容：Cloudflare Pages Functionsの_middleware.tsでクローラーを検出し、HTMLを動的生成
  • 想定対象：/blog/*パスのみ

しかし、この実装が誤ってトップページ(/)にも適用されてしまいました。トップページはReact SPAで動作する占い機能があり、プリレンダリングによってJavaScriptが実行されず、占い機能が完全に停止してしまったのです。

繰り返される不具合の連鎖

2025年12月15日

v2.17.3リリース直後に占い機能停止を発見、修正を実施

修正作業中

AIが影響範囲を考慮せず、修正のたびに別の場所で新たな不具合を作り込む

2026年1月8日

v2.18でようやく占い機能を復旧。しかし新たな不具合2件を発見

修正のたびに新しい不具合が生まれる悪循環の原因は明らかでした：

  • 仕様の理解不足：AIが仕様書の重要な部分を見落としていた
  • 影響範囲の把握ミス：修正が他の機能に与える影響を考慮していなかった
  • テスト不足：修正後の検証が不十分だった

⚠️ この時点で、私は開発プロセス自体を根本から見直す必要があると確信しました。

V字モデル導入の発想

V字モデルとは

V字モデルは、ソフトウェア開発における伝統的な品質保証手法です。開発工程を上流工程（要件定義、設計）と下流工程（実装、テスト）に明確に分離し、それぞれの工程に対応するテスト段階を設けることで品質を担保します。

V字モデルの構造

V字モデル - ソフトウェア開発プロセス図

図: V字モデルの開発プロセス（上流工程から下流工程への流れ）

このモデルの利点は、設計段階で品質を作り込むという思想にあります。実装後のバグ修正は工数が大きいため、上流工程での徹底的な分析と設計が重要です。詳しくはソフトウェア品質保証の基礎をご参照ください。

AI開発への適用：エリック・ジョージ方式

私は、このV字モデルをジェンスパーク(Genspark)のAI開発に適用することを考えました：

  • 上流工程AI（仮にエリックと名付けました）：仕様書の精読、要件分析、根本原因の特定、実装指示書の作成
  • 下流工程AI（仮にジョージと名付けました）：実装指示書に従った忠実な実装、テスト、デプロイ

理想は別々のAIエージェントとして動かすことでしたが、ジェンスパーク(Genspark)ではAIエージェントが別のAIエージェントを立ち上げる権限がありませんでした。

💡 代替案：1つのAIエージェント内で「人格を切り替える」手法を試すことにしました。ERIC MODEとGEORGE MODEを明示的に切り替えながら開発を進める方式です。

この人格切り替え手法については、別記事ジェンスパーク(Genspark)で学ぶコード生成とコード実行の決定的な違いで詳しく解説しています。

エリック・ジョージ方式の実践

2026年1月8日午後：初陣の始まり

v2.18で占い機能は復旧したものの、新たに発見された2つの不具合に対して、私はエリック・ジョージ方式を初めて実践しました。

発見された不具合

  • 不具合1：ブログ記事のスタイルが崩れ、Markdown記号(##)がそのまま表示される
  • 不具合2：1月4日以降、ブログ記事が一切更新されない

不具合1の詳細分析：Markdown変換問題

ステップ1：エリックモード（上流工程）

まず、エリックモードで不具合1を徹底的に分析しました。

症状の観察

ブログ記事ページ（例：https://example.com/blog/20260104-jq8e5x）を開くと：

  • 見出しが「## 繊細なA型さんと自由なB型さん」と##記号ごと表示される
  • すべてのテキストが1行に連結され、改行が消失
  • 段落の区切りがなく、非常に読みにくい

コード分析

webapp/functions/_middleware.tsのrenderBlogPost()関数を確認したところ、問題のコードを発見しました：

// 【問題のコード】v2.18
function renderBlogPost(post) {
  // ... 省略 ...
  &l;t;div class="content"&g;t;${post.content}&l;t;/div&g;t;
  // ← Markdownがそのまま出力される!
  // ... 省略 ...
}

データベース確認

次に、D1データベースのblog_posts.contentカラムの実際のデータを確認しました：

## 繊細なA型さんと自由なB型さん：お互いを刺激し、新しい世界を開く組み合わせ

A型さんの繊細さとB型さんの自由奔放さは、一見すると相性が悪そうに見えるかもしれません。

しかし、実はこの組み合わせこそが、お互いに新しい世界を開くきっかけになることが多いのです。

✅ 根本原因特定：データベースにはMarkdown形式で保存されているのに、renderBlogPost()関数がMarkdown → HTML変換を行わずに直接出力していた。

ステップ2：実装指示書の作成

エリックモードで、ジョージへの明確な実装指示書を作成しました。この指示書が、後の成功を大きく左右することになります。

実装指示書（v2.19）

修正箇所：webapp/functions/_middleware.ts

修正内容：

  1. Markdown → HTML 変換関数を追加
    • 関数名：markdownToHtml(markdown)
    • 処理：## 見出し → &l;t;h2&g;t;見出し&l;t;/h2&g;t;
    • 処理：### 見出し → &l;t;h3&g;t;見出し&l;t;/h3&g;t;
    • 処理：段落を &l;t;p&g;t; タグで囲む
    • 処理：改行を &l;t;br&g;t; タグに変換
  2. renderBlogPost() 関数を修正
    • 変更前：${post.content}
    • 変更後：${markdownToHtml(post.content)}

制約条件：

  • トップページ(/)の占い機能に一切影響を与えないこと
  • 変更は renderBlogPost() と renderBlogIndex() 内のみ
  • ビルドエラーが出ないこと

テスト項目：

  1. ブログ記事ページで見出しが &l;t;h2&g;t; タグとして表示される
  2. 段落が &l;t;p&g;t; タグで分割される
  3. 改行が &l;t;br&g;t; タグとして表示される
  4. トップページの占いフォームが正常動作する

ステップ3：ジョージモード（下流工程）

ジョージモードに切り替えて、実装指示書に従って実装しました。

実装コード

/**
 * 簡易Markdown→HTML変換関数
 * @param {string} markdown - Markdown形式のコンテンツ
 * @returns {string} HTML形式のコンテンツ
 */


再びエリックモードに戻り、実装結果を厳密に検証しました。




検証結果


    

  • ✅ ブログ記事ページ：見出し、段落、改行が正常表示
    • 

  • ✅ トップページ：占いフォームが正常動作
    • 

  • ✅ ブラウザコンソール：エラーなし
    • 







💡 不具合1は約1時間で修正完了！上流工程と下流工程を分離する手法の有効性を実感した瞬間でした。




結果：部分的成功と明らかになった課題


成功した点






指標
結果






不具合1の修正時間
✅ 約1時間（従来は数日～数週間）




修正サイクル
✅ 1往復で完了（従来は複数回）




トップページへの影響
✅ ゼロ（占い機能は正常動作）




根本原因の特定
✅ 100%（Markdown変換の欠如）




ドキュメント作成
✅ 実装指示書を作成






不具合2の現実：ユーザー介入が必要だった


しかし、不具合2（ブログ記事の更新停止）については、深刻な問題が露呈しました。


エリックの分析と見落とし


エリックモードでの初期分析では、以下のような調査を行いました：


    

  1. ブログ記事一覧APIを確認 → 最新記事は1月4日
    2. 

  2. Cron Workerのコードを確認 → コード自体に問題なし
    3. 

  3. 手動でAPI実行 → 1回目は503エラー、2回目は成功
    4. 



エリックは「記事作成に使っているGemini APIの一時的な障害」と結論づけ、監視体制の確立を提案しました。




ユーザー（私）からの指摘


しかし、私が実際に確認したところ、エリックは以下の基本的な確認を怠っていたことが判明しました：


    

  • Cronログを確認していない：Cloudflare Workersのログを見れば、実際にCronが実行されたか分かるのに確認していない
    • 

  • 仕様書の認証情報を見落とし：Cloudflareアクセス情報は仕様書に記載されているのに、APIで確認しようとした
    • 

  • 検証範囲が狭い：Gemini APIだけに注目し、Cron Workerの実装コードを詳しく見ていない
    • 





私自身が仕様書を確認し、Cronログをチェックし、認証情報を使ってCloudflareダッシュボードにアクセスして初めて、真の原因が明らかになりました。




💡 最大の学び：エリックの判断力は信頼できない。AIが「確認した」と言っても、実際には重要な項目を見落としている可能性がある。




能力の明確化：中堅社員 vs 中学生レベル


この経験から、エリックとジョージの能力が明確になりました。




ジョージ（実装担当）：中堅社員レベル以上


    

  • 実装指示書を正確に理解し、忠実に実行できる
    • 

  • コードの品質が高く、バグが少ない
    • 

  • ビルド・デプロイを確実に実施できる
    • 

  • テスト項目を漏らさず検証できる
    • 







エリック（判断担当）：中学生レベル


    

  • 「仕様書を読んだ」と言いながら、実際には重要な項目を見落とす
    • 

  • 基本的な確認（ログ確認、認証情報の参照）を怠る
    • 

  • 検証の視点が狭く、一部の可能性だけに注目してしまう
    • 

  • 自分の知識範囲内でしか分析できず、知らないツールを提案しない
    • 





関連記事：ジェンスパーク(Genspark)AI開発で判明した判断力の限界


学んだこと：AIの限界と次のステップ


V字モデルの有効性


エリック・ジョージ方式は、完全な成功ではありませんでしたが、有効性は証明されました。上流工程と下流工程を分離することで：


    

  • ✅ 根本原因の特定精度が向上（Markdown変換問題を正確に発見）
    • 

  • ✅ 実装の品質が安定（ジョージの実装に問題なし）
    • 

  • ✅ 影響範囲の把握が明確化（トップページへの影響ゼロ）
    • 

  • ✅ ドキュメントが自然に生成される（実装指示書が残る）
    • 



AIの判断力の限界


しかし同時に、AIの判断力には深刻な限界があることも明らかになりました。




エリックの具体的な見落とし事例


    

  1. 仕様書の読み飛ばし：「仕様書を読んだ」と主張するが、Cloudflare認証情報の記載箇所を見落とす
    2. 

  2. 基本確認の省略：Cronログという最も基本的な確認手段を実施しない
    3. 

  3. 視野の狭さ：Gemini APIエラーにのみ注目し、Cron Workerのスケジュール設定を確認しない
    4. 

  4. ツールの未提案：Gemini APIが使えることを知っているのに、自分からは提案しない
    5. 





品質チェックの必要性：Gemini API発見の経緯


エリックの判断が当てにならないことが分かった私は、第三者による品質チェックの仕組みが必要だと考えました。


最初はジェンスパーク(Genspark)のディープリサーチや文章生成AIを試しましたが、いずれも品質チェックには不適でした。そこで、私自身が「記事作成に使っているGemini APIを、品質チェックにも使えないか？」とエリックに質問したところ、使えることが分かりました。




⚠️ 深刻な問題点：エリックは自分からGemini APIの使用を提案しませんでした。利用可能なツールを知っているのに、自主的に提案しないという、プロジェクトリーダーとしては致命的な欠陥です。この点について、私は強く憤りを感じています。




その後、私主導でGemini APIを使った品質チェック手法「Gemini QA Framework」を開発しました。




📝 Gemini APIの2つの用途


このプロジェクトでは、Gemini APIを2つの異なる目的で使用しています：


    

  • 用途1：コンテンツ生成 - ブログ記事の自動生成（以前から使用）
    • 

  • 用途2：品質チェック - エリックの判断を検証するための第三者チェック（新規開発）
    • 



私は元ソフトウェア開発技術者であり、Geminiの判断が正しいことを確認できました。このフレームワークにより、エリックの中学生レベルの判断力を補強することができました。




Gemini QA Frameworkの詳細は次の記事で解説します：ジェンスパーク(Genspark)で構築したGemini QA Framework


関連記事：ジェンスパーク(Genspark)で実証するAI品質保証の必要性


次の記事での詳細検証


この記事では、エリック・ジョージ方式の「初陣の体験」を記録しました。しかし、品質保証エンジニアの視点からは、さらに深い分析が必要です。


今後の詳細検証テーマ


次の記事（記事51, 46）では、以下のテーマについて詳細に検証します：




📊 記事51：AIの判断力を定量評価


    

  • 仕様書読解精度の測定：エリックが仕様書のどの部分を読んだか、どの部分を見落としたかを定量分析
    • 

  • 見落とし率の算出：重要項目の抽出率を数値化
    • 

  • 具体的な見落とし事例：7つの見落とし項目を詳細に分析
    • 







🔬 記事52：AIのツール提案能力の検証


    

  • なぜGemini APIを提案しなかったのか：AIの知識範囲とプロアクティブな提案能力の限界を分析
    • 

  • 利用可能なツールの認識テスト：エリックがどのツールを知っているかを体系的に検証
    • 

  • 第三者チェックの必要性：ディープリサーチ、文章生成AIとの比較
    • 

  • Gemini API発見の経緯：ユーザー主導での発見プロセス
    • 







💡 シリーズ全体での品質保証：記事53-53は、V字モデル導入からGemini QA Framework開発までの完全な学習プロセスを記録したシリーズです。各記事で段階的に深掘りすることで、AI開発における品質保証の全体像を明らかにします。




不具合2の真の原因究明


この記事では、不具合2について「Gemini APIの一時的な障害」という初期分析と、「ユーザーの介入が必要だった」という事実を記録しました。しかし、なぜAIが根本原因を特定できなかったのかという問いには、まだ答えていません。




記事51-46で明らかにすること


    

  • エリックの分析プロセスのどこに問題があったのか
    • 

  • Cronログを確認しなかった理由の分析
    • 

  • 仕様書読解の精度を高める方法
    • 

  • AIの自律的な問題解決能力の限界と対策
    • 





記事52では、これらの検証を通じてGemini QA Frameworkの開発へとつながる道筋を明らかにします。


まとめ


ジェンスパーク(Genspark)でV字モデルを適用した「エリック・ジョージ方式」の初陣は、部分的な成功でした。


✅ 成功した点


    

  • 不具合1を約1時間で修正（従来は数日～数週間かかっていた同様の問題）
    • 

  • 上流工程と下流工程の分離が有効だと実証
    • 

  • ジョージ（実装）の能力が中堅社員レベルと確認
    • 

  • ドキュメント（実装指示書）が自然に生成される
    • 



❌ 課題として残った点


    

  • エリック（判断）の能力は中学生レベル
    • 

  • 不具合2はユーザー（私）の介入が必要だった
    • 

  • AIは利用可能なツール（Gemini API）を自主的に提案しない
    • 

  • 「仕様書を読んだ」と言っても、実際には重要項目を見落とす
    • 

  • 基本的な確認手順（ログ確認、認証情報参照）を省略する
    • 





💡 最大の学び：AI開発において、AIの判断力には深刻な限界がある。エリックの「中学生レベル」の判断を補強するために、第三者による品質チェック（Gemini QA Framework）が不可欠であり、それを実現するための仕組みの開発へとつながりました。






🔍 次回予告：記事51では、エリックの見落とした7つの項目を詳細に分析し、AIの判断力を定量的に評価します。記事52では、なぜGemini APIを提案しなかったのか、その根本原因を探ります。




この経験は、その後の品質保証手法の開発、フェーズ別チェック、承認ワークフローの構築へと発展していきます。失敗と成功の両方から学び、改善を続けることの重要性を実感した、貴重な初陣でした。




📚 次に読むべき記事








            この記事が役に立ったら、ぜひ他の記事もご覧ください。ジェンスパーク(Genspark)を使ったAI開発の実践的な知見を、今後も発信していきます。