Vibe Codingチーム協業完全ガイド：CI/CD構築、コード品質、衝突なし貢献戦略

AIベースのVibe Codingは個人の生産性を大幅に向上させますが、チーム環境では新たな課題が生まれます。AIが生成したコードがチームメンバーのコードと衝突したり、一貫性のないスタイルが混在したり、CI/CDパイプラインがAI生成コードのスピードに追いつかないことがあります。このガイドでは、Vibe Codingチームが効率的に協業するためのGit戦略、CI/CDパイプライン、コード品質管理、Skillsファイルの活用法を包括的に解説します。

1. Gitブランチ戦略：Trunk-Based Development vs GitFlow

1.1 GitFlowがVibe Codingチームに合わない理由

GitFlowはrelease、develop、feature、hotfixなど複雑なブランチ構造を使います。AI支援開発ではこの構造が非効率になります。

GitFlowの問題点（Vibe Coding環境）：

AIが速くコードを生成するほどfeatureブランチの寿命が伸びてマージ地獄が発生
develop → mainのマージ時に衝突解消でAIコンテキストが失われる
releaseブランチ管理のオーバーヘッドが大きい

1.2 Trunk-Based Development (TBD)

TBDはすべての開発者がmainブランチに短いサイクル（最低1日1回）でコミットする戦略です。Vibe Codingチームに理想的です。

TBDコア原則：

ブランチ寿命：最大2日（フィーチャーフラグ使用時はmainに直接マージ）
頻繁な統合：1日2〜3回mainにプッシュ
完全な自動化：すべてのマージにCI通過が必須
小さなPR：400行以下を推奨

TBDブランチ戦略：

main （常にリリース可能）
├── feature/us-123-recommendation-api （寿命: 1-2日）
├── feature/us-124-websocket-updates （寿命: 1-2日）
└── fix/recommendation-null-check （寿命: 4時間）

フィーチャーフラグで未完成コードを隠す：

// src/config/feature-flags.ts
export const FEATURE_FLAGS = {
  RECOMMENDATION_V2: process.env.FEATURE_RECOMMENDATION_V2 === 'true',
  WEBSOCKET_REAL_TIME: process.env.FEATURE_WEBSOCKET === 'true',
} as const;

// コンポーネントでの使用
function HomePage() {
  return (
    <div>
      {FEATURE_FLAGS.RECOMMENDATION_V2 && <RecommendationSection />}
      <ProductList />
    </div>
  );
}

1.3 Vibe CodingチームのためのGitルール

# 推奨ワークフロー
git checkout -b feature/us-123-recommendation-api
# Claudeと一緒に開発（複数の小さなコミット）
git commit -m "feat(recommendation): add purchase history query"
git commit -m "test(recommendation): add unit tests for recommendation service"
git commit -m "feat(recommendation): add recommendation API endpoint"
# PR作成 → CI通過 → コードレビュー → マージ

2. Conventional Commits + 自動Changelog

2.1 Conventional Commits仕様

Conventional Commitsはコミットメッセージに構造的な意味を与える仕様です。AI支援開発では特に重要です。

形式：

type(scope): description

[optional body]

[optional footer(s)]

タイプ一覧：

タイプ	意味	バージョン影響
feat	新機能	Minorバージョン増加
fix	バグ修正	Patchバージョン増加
docs	ドキュメントのみ変更	なし
style	フォーマット、セミコロン等	なし
refactor	リファクタリング	なし
test	テスト追加/修正	なし
chore	ビルド設定、パッケージ	なし
perf	パフォーマンス改善	Patchバージョン増加
BREAKING CHANGE	後方互換性の破壊	Majorバージョン増加

例：

feat(recommendation): add purchase history based product recommendations

- Implement collaborative filtering algorithm
- Add RecommendationService with top-10 product selection
- Exclude already purchased products from recommendations

Closes #123

2.2 自動Changelog生成

# conventional-changelogのインストール
npm install --save-dev @commitlint/cli @commitlint/config-conventional
npm install --save-dev conventional-changelog-cli

# .commitlintrc.json
{
  "extends": ["@commitlint/config-conventional"]
}

# package.json scripts
{
  "scripts": {
    "changelog": "conventional-changelog -p angular -i CHANGELOG.md -s",
    "release": "standard-version"
  }
}

自動生成されたCHANGELOG例：

# Changelog

## [1.3.0] - 2026-03-17

### Features

- **recommendation:** add purchase history based product recommendations

### Bug Fixes

- **cart:** fix quantity update when adding duplicate items

### Performance

- **recommendation:** add Redis caching for recommendation results

3. PR戦略：小さなPR、AI支援コードレビュー、ブランチ保護

3.1 小さなPRの原則

Vibe Coding環境でAIが素早くコードを生成すると、大きなPRを作りたい誘惑があります。これに抵抗しなければなりません。

PRサイズガイドライン：

理想：200行以下
最大：400行（例外的）
絶対NG：1000行以上のPR

大きなPRを分割する方法：

縦分割： レイヤー別に分離（DBレイヤーPR → サービスレイヤーPR → API PR）
横分割： フィーチャーフラグ活用、テストと実装を分離
リファクタリング + 機能分離： リファクタリングは別PR

3.2 AI支援コードレビューの自動化

GitHub ActionsでClaudeによる自動レビュー：

# .github/workflows/ai-code-review.yml
name: AI Code Review

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  ai-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: Get PR diff
        id: diff
        run: |
          git diff origin/main...HEAD > pr_diff.txt
          echo "diff_size=$(wc -l < pr_diff.txt)" >> $GITHUB_OUTPUT

      - name: AI Review with Claude API
        if: steps.diff.outputs.diff_size < 1000
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          node scripts/ai-review.js

3.3 ブランチ保護ルール

GitHub Branch Protection Rulesの設定：

# GitHub CLIで設定
gh api repos/OWNER/REPO/branches/main/protection \
--method PUT \
--field required_status_checks='{"strict":true,"contexts":["ci/build","ci/test","ci/lint"]}' \
--field enforce_admins=true \
--field required_pull_request_reviews='{"required_approving_review_count":1,"dismiss_stale_reviews":true}' \
--field restrictions=null

必須ステータスチェック：

ci/build: ビルド成功
ci/test: テスト通過（カバレッジ80%以上）
ci/lint: ESLint、Prettier通過
ci/security: セキュリティ脆弱性スキャン

CODEOWNERSの設定：

# .github/CODEOWNERS
# コアアーキテクチャファイル
/src/core/ @senior-dev @tech-lead
/src/domain/ @domain-expert

# セキュリティ関連
/src/auth/ @security-team
*.env* @security-team

# CI/CD設定
/.github/ @devops-team
/docker/ @devops-team

4. GitHub Actions CI/CDパイプライン

4.1 完全なCI/CDパイプライン例

# .github/workflows/ci-cd.yml
name: CI/CD Pipeline

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

env:
  NODE_VERSION: '20'
  REGISTRY: ghcr.io
  IMAGE_NAME: ${{ github.repository }}

jobs:
  # ─── CIステージ ──────────────────────────────────────

  lint:
    name: Lint & Format Check
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'npm'
      - run: npm ci
      - run: npm run lint
      - run: npm run format:check

  type-check:
    name: TypeScript Type Check
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'npm'
      - run: npm ci
      - run: npm run type-check

  test-unit:
    name: Unit Tests
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'npm'
      - run: npm ci
      - run: npm run test:unit -- --coverage
      - name: Upload coverage
        uses: codecov/codecov-action@v3
        with:
          flags: unit

  test-integration:
    name: Integration Tests
    runs-on: ubuntu-latest
    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_PASSWORD: testpassword
          POSTGRES_DB: testdb
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5
        ports:
          - 5432:5432
      redis:
        image: redis:7
        ports:
          - 6379:6379
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'npm'
      - run: npm ci
      - run: npm run test:integration
        env:
          DATABASE_URL: postgresql://postgres:testpassword@localhost:5432/testdb
          REDIS_URL: redis://localhost:6379

  security-scan:
    name: Security Scan
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run Trivy vulnerability scanner
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'fs'
          scan-ref: '.'
          format: 'sarif'
          output: 'trivy-results.sarif'
      - name: Upload Trivy scan results
        uses: github/codeql-action/upload-sarif@v2
        with:
          sarif_file: 'trivy-results.sarif'
      - name: npm audit
        run: npm audit --audit-level=high

  mutation-test:
    name: Mutation Testing
    runs-on: ubuntu-latest
    if: github.event_name == 'pull_request'
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ env.NODE_VERSION }}
          cache: 'npm'
      - run: npm ci
      - run: npx stryker run
      - name: Comment mutation score on PR
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const report = JSON.parse(fs.readFileSync('reports/mutation/mutation.json'));
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: `Mutation Score: ${report.metrics.mutationScore.toFixed(1)}%`
            });

  # ─── CDステージ（mainブランチのみ）───────────────────

  build-image:
    name: Build & Push Docker Image
    runs-on: ubuntu-latest
    needs: [lint, type-check, test-unit, test-integration, security-scan]
    if: github.ref == 'refs/heads/main'
    outputs:
      image-digest: ${{ steps.build.outputs.digest }}
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v4
      - name: Log in to Container Registry
        uses: docker/login-action@v3
        with:
          registry: ${{ env.REGISTRY }}
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - name: Build and push
        id: build
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest

  deploy-staging:
    name: Deploy to Staging
    runs-on: ubuntu-latest
    needs: [build-image]
    environment: staging
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to Kubernetes Staging
        run: |
          kubectl set image deployment/app \
            app=${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}@${{ needs.build-image.outputs.image-digest }} \
            --namespace=staging
          kubectl rollout status deployment/app --namespace=staging

  deploy-production:
    name: Deploy to Production
    runs-on: ubuntu-latest
    needs: [deploy-staging]
    environment:
      name: production
      url: https://myapp.com
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to Production
        run: |
          kubectl set image deployment/app \
            app=${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}@${{ needs.build-image.outputs.image-digest }} \
            --namespace=production
          kubectl rollout status deployment/app --namespace=production

5. Skillsファイル：チーム共有AIワークフロー

5.1 Skillsファイルとは？

Skillsファイル（.claude/commands/ディレクトリ）はチームが共有する再利用可能なAIワークフローです。スラッシュコマンド（/commit、/pr-descriptionなど）で実行します。

ディレクトリ構造：

.claude/
  commands/
    commit.md
    pr-description.md
    test.md
    review.md
    docs.md
    refactor.md
    security-check.md
    changelog.md

5.2 主要Skillsファイル例

/commit — コミットメッセージ自動生成：

# commit

ステージングされた変更を分析し、Conventional Commits仕様のコミットメッセージを生成します。

## ルール

- feat/fix/docs/style/refactor/test/chore/perfタイプを使用
- scopeは影響を受けるモジュール/コンポーネント（省略可）
- 件名：50文字以下、現在形、小文字始まり
- 本文：何を、なぜ変更したかを説明
- BREAKING CHANGEがあればfooterに記載

## 出力形式

type(scope): description

変更点1
変更点2

Closes #issue番号（該当する場合）

/pr-description — PR説明の自動生成：

# pr-description

現在のブランチの変更を分析してPR説明を生成します。

## 出力形式

### 変更概要

[1〜3行のまとめ]

### 作業内容

- [ ] 実装項目1
- [ ] 実装項目2

### テスト方法

1. ステップごとのテスト手順

### スクリーンショット（UI変更がある場合）

[ここにスクリーンショットを追加]

### 関連Issue

Closes #issue番号

### チェックリスト

- [ ] 単体テスト作成完了
- [ ] 統合テスト通過
- [ ] CLAUDE.mdルール準拠
- [ ] ドキュメント更新（必要な場合）

/test — テストケース自動生成：

# test

選択したファイルまたは関数に対する包括的なテストを生成します。

## 含まれる内容

1. 単体テスト（Jest/Vitest）
   - 正常系ケース
   - エッジケース（境界値、null、undefined）
   - エラーケース
2. モック設定
3. プロパティベーステスト（複雑なビジネスロジック）

## ルール

- CLAUDE.mdのテストカバレッジ目標を遵守
- AAAパターン（Arrange/Act/Assert）を使用
- 非同期テストにはasync/awaitを使用

/review — コードレビューの実施：

# review

現在の変更または指定したファイルに対する詳細なコードレビューを実施します。

## レビューチェックリスト

### コード品質

- [ ] SOLID原則の遵守
- [ ] DRY原則（重複コードなし）
- [ ] 関数/クラスの単一責任
- [ ] 命名規則（CLAUDE.md基準）

### セキュリティ

- [ ] SQLインジェクションリスク
- [ ] XSS脆弱性
- [ ] 機密情報の露出（シークレット、PII）
- [ ] 認証/認可の検証

### パフォーマンス

- [ ] N+1クエリ問題
- [ ] 不要な再レンダリング
- [ ] メモリリークリスク

### テスト

- [ ] テストカバレッジが十分
- [ ] エッジケースのカバー

## 出力形式

各問題：[Critical/Major/Minor] 説明 + 改善コード例

/refactor — リファクタリング提案：

# refactor

選択したコードのリファクタリング提案を生成します。

## 分析基準

1. Extract Method: 長い関数を意味ある関数に分割
2. Extract Class: 単一責任原則に違反するクラスを分離
3. Replace Conditional with Polymorphism: if/elseチェーンを除去
4. Introduce Parameter Object: 3つ以上のパラメータを持つ関数
5. Remove Duplicate Code: 重複ロジックを共通化

## 出力形式

- 元のコードの問題点の説明
- リファクタリングされたコード
- 変更の理由
- 追加の考慮事項

/docs — ドキュメントの自動生成：

# docs

選択したコードのドキュメントを生成します。

## 生成項目

1. JSDoc/TSDocコメント
2. README.md（モジュールまたは関数の説明）
3. APIドキュメント（OpenAPI/Swagger形式）

## ルール

- コード例を含める
- パラメータの型と意味を説明
- 戻り値を説明
- 例外的な状況をドキュメント化

6. 静的解析：ESLint、Prettier、SonarQube

6.1 ESLint設定

// eslint.config.js (ESLint v9 flat config)
import js from '@eslint/js'
import typescript from '@typescript-eslint/eslint-plugin'
import tsParser from '@typescript-eslint/parser'
import prettier from 'eslint-config-prettier'
import importPlugin from 'eslint-plugin-import'
import sonarjs from 'eslint-plugin-sonarjs'

export default [
  js.configs.recommended,
  {
    files: ['**/*.ts', '**/*.tsx'],
    languageOptions: {
      parser: tsParser,
      parserOptions: {
        project: './tsconfig.json',
      },
    },
    plugins: {
      '@typescript-eslint': typescript,
      import: importPlugin,
      sonarjs: sonarjs,
    },
    rules: {
      // TypeScriptルール
      '@typescript-eslint/no-explicit-any': 'error',
      '@typescript-eslint/strict-null-checks': 'error',
      '@typescript-eslint/no-unused-vars': 'error',
      '@typescript-eslint/explicit-function-return-type': 'warn',

      // 複雑度制限
      complexity: ['error', 10],
      'max-lines-per-function': ['warn', 30],
      'max-depth': ['error', 3],

      // SonarJSコード品質
      'sonarjs/no-duplicate-string': 'warn',
      'sonarjs/cognitive-complexity': ['error', 15],
      'sonarjs/no-identical-functions': 'error',

      // インポート順序
      'import/order': [
        'error',
        {
          groups: ['builtin', 'external', 'internal', 'parent', 'sibling'],
          'newlines-between': 'always',
        },
      ],
    },
  },
  prettier,
]

6.2 Prettier設定

{
  "semi": true,
  "trailingComma": "es5",
  "singleQuote": true,
  "printWidth": 100,
  "tabWidth": 2,
  "useTabs": false,
  "bracketSpacing": true,
  "arrowParens": "avoid",
  "endOfLine": "lf"
}

6.3 SonarQube統合

# .github/workflows/sonarqube.yml
name: SonarQube Analysis

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  sonar:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm run test:unit -- --coverage
      - name: SonarQube Scan
        uses: sonarsource/sonarqube-scan-action@master
        env:
          SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
          SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}
        with:
          args: >
            -Dsonar.projectKey=my-project
            -Dsonar.javascript.lcov.reportPaths=coverage/lcov.info
            -Dsonar.qualitygate.wait=true

7. 衝突防止戦略

7.1 フィーチャーフラグで衝突を最小化

フィーチャーフラグは未完成のコードをmainブランチに安全にマージするための強力なツールです。

// src/config/feature-flags.ts
import { z } from 'zod'

const featureFlagSchema = z.object({
  RECOMMENDATION_V2: z.boolean().default(false),
  WEBSOCKET_REAL_TIME: z.boolean().default(false),
  NEW_CHECKOUT_FLOW: z.boolean().default(false),
  AI_SEARCH: z.boolean().default(false),
})

function loadFeatureFlags() {
  return featureFlagSchema.parse({
    RECOMMENDATION_V2: process.env.FEATURE_RECOMMENDATION_V2 === 'true',
    WEBSOCKET_REAL_TIME: process.env.FEATURE_WEBSOCKET === 'true',
    NEW_CHECKOUT_FLOW: process.env.FEATURE_NEW_CHECKOUT === 'true',
    AI_SEARCH: process.env.FEATURE_AI_SEARCH === 'true',
  })
}

export const FEATURES = loadFeatureFlags()

7.2 モジュラーアーキテクチャで衝突を最小化

チームメンバーが異なるモジュールを担当するよう明確に境界を分けると、マージ衝突を大幅に減らせます。

src/
  modules/
    user/          # チームメンバーA担当
      domain/
      application/
      infrastructure/
      presentation/
    product/       # チームメンバーB担当
    order/         # チームメンバーC担当
    recommendation/ # チームメンバーD担当
  shared/          # 共有コード（変更を最小化）
    utils/
    types/
    errors/

7.3 衝突発生時のAI活用

マージ衝突が発生しました。両方の変更を分析して正しいマージ方法を提案してください：

<<<<<<< HEAD （自分の変更）
[コードを貼り付け]
=======
[相手のコードを貼り付け]
>>>>>>> feature/recommendation

両方の変更の意図を把握し、両方を保持するマージ結果を生成してください。

8. AIを活用した技術的負債の管理

8.1 AI生成コードの技術的負債パターン

Vibe Codingで素早く開発すると技術的負債が蓄積する可能性があります。

AI生成コードによくある技術的負債：

過度な抽象化（不要なインターフェース/レイヤー）
不必要な依存関係の追加
テストしにくい結合度の高いコード
コンテキストなしで生成された一貫性のないエラー処理
重複ロジック（AIが他のファイルのロジックを知らずに再生成）

8.2 定期的な技術的負債レビュー

# 技術的負債レビュープロンプト（Sprint終了時）

以下のコードベースを分析して技術的負債を特定してください：
[変更されたファイルリスト]

分析項目：

1. 重複コード（DRY違反）
2. 過度な複雑度（循環的複雑度10以上）
3. 不要な抽象化レイヤー
4. 一貫性のないエラー処理
5. テストカバレッジが低い領域

各項目について：

- 場所（ファイル、行）
- 深刻度（Critical/Major/Minor）
- リファクタリング見積もり時間
- 推奨アプローチ

8.3 Tech Debt Sprintの割り当て

# 技術的負債管理のためのSprintへの割り当て
# 毎Sprintの20%は技術的負債解決に充てる

# GitHub Issuesラベル戦略
labels:
  - name: tech-debt
    color: '#e4e669'
    description: 技術的負債イシュー
  - name: ai-generated
    color: '#7c3aed'
    description: AI生成コードのレビューが必要
  - name: needs-refactor
    color: '#f97316'
    description: リファクタリングが必要

クイズで学ぶ

Q1: Trunk-Based Development (TBD) がVibe CodingチームにGitFlowより有利な理由は？

答え： TBDはブランチ寿命が短く（最大2日）、AI生成コードが素早く統合され、マージ衝突が最小化され、継続的インテグレーションが可能です。

解説： GitFlowではfeatureブランチが数日〜数週間続くことがありますが、AIが素早くコードを生成すると、ブランチの寿命がさらに長くなりマージ衝突が頻発します。TBDは1日1〜2回mainにマージするため、AI生成コードが素早く統合され、チーム全体が最新のコードを維持できます。フィーチャーフラグを使えば未完成の機能も安全にマージできます。

Q2: Conventional CommitsでBREAKING CHANGEはどう表現し、バージョンにどんな影響を与えますか？

答え： コミットメッセージのfooterにBREAKING CHANGE: 説明を追加するか、タイプの後に感嘆符（!）を付けます。Semantic VersioningではMajorバージョンが増加します。

解説： 例：feat!: remove legacy API endpointまたはfooterにBREAKING CHANGE: /api/v1/usersエンドポイント削除、/api/v2/usersを使用。Semantic Versioning (SemVer)では後方互換性を破壊する変更はMajorバージョン（1.0.0 → 2.0.0）を増加させます。自動Changelogツール（standard-version、release-please）がこれを検出して自動的にバージョンを更新します。

Q3: Skillsファイル（/commit、/reviewなど）の主な利点3つは？

答え： チーム全体のAIワークフローの一貫性を維持、再利用可能なプロンプトで繰り返し作業を自動化、チームのルール（コーディング規約、品質基準）がAIに自動的に適用されます。

解説： Skillsファイルがないと、チームメンバーごとに異なるプロンプトを使うためAI出力の品質とスタイルが一貫しません。Skillsファイルをバージョン管理（Git）することで、チームのAIワークフローもコードと同様に管理できます。例えば/commitコマンドは常にConventional Commits形式でメッセージを生成し、/reviewはチームのセキュリティチェックリストを自動的に適用します。

Q4: SonarQube Quality Gateのコア指標4つは？

答え： 新しいコードのカバレッジ（80%以上）、重複コード率（3%以下）、Blockerイシュー（0件）、Criticalイシュー（0件）です。

解説： SonarQube Quality GateはPRマージ前にコード品質基準を自動的に検査します。新しいコードのカバレッジは追加されたコードのテスト率です。重複コードはDRY原則の違反を検出します。Blocker/Criticalイシューはセキュリティ脆弱性やバグを発見します。SonarQubeをCI/CDパイプラインに統合すると、品質基準を下回るPRは自動的にマージがブロックされます。

Q5: フィーチャーフラグ（Feature Flag）を使う主な理由3つは？

答え： 未完成のコードをメインブランチに安全に統合（TBDサポート）、特定のユーザー/環境への段階的なデプロイ、A/Bテストと素早いロールバックが可能です。

解説： フィーチャーフラグなしでTBDを使うと、未完成の機能がプロダクションに公開されます。フィーチャーフラグを環境変数で管理することで、同じコードベースから開発、ステージング、プロダクションで異なる機能セットを実行できます。Vibe Coding環境ではAIが素早く機能を追加するため、フィーチャーフラグで完成した機能のみを段階的に有効化する戦略が重要です。

Q6: AI生成コードでよく発生する技術的負債パターン3つは？

答え： 不要な抽象化（過度なインターフェース/レイヤー）、重複ロジック（他のファイルのコンテキストを知らない）、一貫性のないエラー処理です。

解説： AIはコンテキストウィンドウ内の情報しか知らないため、他のファイルに既に存在するユーティリティ関数を再生成することが多いです。また異なるAIセッションで異なるエラー処理パターンが使われ、コードの一貫性が低下します。CLAUDE.mdに禁止パターンを明記し、定期的な技術的負債レビューSprintを通じてAI生成コードの品質を管理する必要があります。

まとめ

Vibe Codingチーム協業の成功は3つの核心的な軸にかかっています：

1. Git戦略： Trunk-Based Developmentで短命のブランチと頻繁な統合を維持します。フィーチャーフラグで未完成コードを安全に管理し、Conventional Commitsで自動化されたリリースを実現します。

2. CI/CD自動化： GitHub Actionsでlint、型チェック、単体/統合テスト、セキュリティスキャン、Dockerビルド、デプロイを完全自動化します。すべてのPRはCIを通過しなければマージできません。

3. コード品質： ESLint + Prettier + SonarQubeでコード品質基準を強制し、SkillsファイルでチームのAIワークフローを標準化します。定期的な技術的負債レビューでAI生成コードの品質を維持します。

この3つの軸がしっかり構築されたチームは、AIのスピードをチーム全体の生産性に変換できます。