Ver2.3.0ブランチ統合 — 3ブランチ統合と設計書乖離解消64タスクの舞台裏
Mark4並走する3ブランチを1つに — Git統合と設計書乖離解消の全工程
3つのブランチが存在していた背景
2026年3月中旬、wagahiアプリのGitリポジトリには3つの主要ブランチが並走していました。
- feature/Ver2_02: 自社広告プラットフォーム、トークン関連機能の開発ブランチ
- feature/demo_04: AdSense再審査対応、ブログCMS基盤、SEO最適化の開発ブランチ
- feature/Ver2_03: 次期バージョンの統合先ブランチ
これは計画的な並走でした。Ver2_02で機能開発を進めつつ、demo_04でAdSense審査対応を急ぐ必要があったため、一時的にブランチを分離していたのです。しかし、ブランチが分離している期間が長くなるほど、統合時のコンフリクトリスクは高まります。
統合の決断と正式バージョニング
Ver2_02の主要機能が完了し、demo_04のAdSense対応も一段落したタイミングで、3ブランチの統合を決断しました。同時に、これまでfeature/Ver2_XXという暫定的な名前だったバージョニングを見直し、ver2.3.0という正式なセマンティックバージョニングを導入しました。
なぜver2.3.0か
- メジャーバージョン2: wagahiアプリの第2世代（位置情報・広告統合版）
- マイナーバージョン3: Ver2_01, Ver2_02, Ver2_03の3回目のイテレーション
- パッチバージョン0: 統合直後の初期リリース
ブランチ統合の技術的課題
コンフリクトの解決
demo_04とVer2_02は、同じファイルの異なる部分を変更していることが多くありました。特に、フロントエンドのコンポーネントファイルやバックエンドの設定ファイルでコンフリクトが発生しました。
Git操作自体はClaude Codeが自動で実行しましたが、コンフリクトの解決方針（どちらの変更を優先するか）は人間が判断しました。これは「AIに委ねてはいけない判断」の典型例です。
フロントエンドテスト負債202件の修正
ブランチ統合後にフロントエンドのテストを実行したところ、202件のテスト失敗が検出されました。
これは「テスト負債」と呼ぶべき状態です。各ブランチで個別にテストを通過させていたものの、統合後の環境ではコンポーネントの依存関係やRedux状態の変更が影響し、多数のテストが失敗したのです。
202件のテスト修正は大きな作業でしたが、Claude Codeの支援により、テスト失敗の原因分析から修正コードの生成まで効率的に完了しました。
設計書乖離解消64タスク
ブランチ統合後、最も重要な作業が設計書乖離の解消でした。
3つのブランチで個別に進めていた開発により、設計書と実装コードの間に多くの乖離が蓄積していました。機能ドメイン別に分割された設計書ファイルをすべて確認し、実装との不整合を洗い出した結果、64件のタスクが必要でした。
乖離の内訳
- API仕様の不整合: 15件 — エンドポイントの追加・変更が設計書に未反映
- DB設計の差分: 8件 — テーブル定義やカラム変更の設計書未反映
- フロントエンド仕様の差分: 18件 — コンポーネント構成やRedux状態の変更が未反映
- 内部設計の差分: 12件 — 処理フローや例外処理の変更が未反映
- 外部設計の差分: 11件 — 画面遷移や操作仕様の変更が未反映
解消プロセス
設計書乖離の解消は、以下の手順で実施しました。
- 自動スキャン: 実装コードと設計書の照合をClaude Codeで自動実行
- 差分リスト作成: 64件の乖離をタスクとしてリスト化
- 優先度付け: API仕様→DB設計→FE仕様→内部→外部の順で修正
- 設計書更新: 各タスクの設計書を実装に合わせて更新
- 整合性検証: 更新後の設計書と実装の整合性を再確認
64タスクすべてを100%完了し、ver2.3.0の時点で設計書と実装が完全に同期した状態を確立しました。
SEO最適化とAdSense再審査対応
demo_04ブランチで進めていたAdSense再審査対応も、統合に含まれています。
- ブログCMS基盤: 記事投稿・管理機能の実装
- 記事15件: AdSense審査基準を満たすコンテンツの準備
- 全静的ページ統一ヘッダー: サイト全体のナビゲーション統一
- SEO最適化: メタタグ、構造化データ、サイトマップの整備
まとめ
3ブランチ統合は、wagahiアプリの開発史上最も大規模な統合作業でした。コンフリクト解決、テスト負債202件の修正、設計書乖離64タスクの解消。いずれも地味な作業ですが、プロダクトの品質を維持するために不可欠です。
ブランチを分けるのは簡単だが、統合するのは難しい。今回の経験から、ブランチの並走期間はできるだけ短く保つべきだという教訓を得ました。
本記事は2026年2月時点の開発状況に基づいています。
著者: 株式会社シーテン — インフラ系から宇宙関連システムまで20年以上の開発経験を持つ技術者集団。2025年より生成AI・AIエージェントを活用したAI駆動開発に本格参入し、自社プロダクト「wagahi」の開発を通じて実践知見を蓄積中。
関連記事:
投稿者プロフィール
