AI時代の開発スピードと品質のバランス術 — AI Coding Meetup

🗣 一言サマリ：AIで“楽”になった時間を、モデル設計と品質担保に“再配分”したチームだけが、アウトプット→アウトカムに変換できる。
💡 響いたメッセージ：レビューはコードより先に“モデル意図”から始める。

[toc]

1. 背景と問題意識

AIコーディングにより、実装は確実に“楽”になった。スキャフォールドやUI微調整は一気に進む。しかし、レビュー／QA／本番運用で詰まると、全体スループット（事業のアウトカム）は上がらない。
本記事では、イベントの学びに自分の所感と運用ノウハウを足し、今日から導入できる実務テンプレに落とす。

2. カンファレンスの要点（要約）

• “速くなった”ではなく“楽になった”フェーズ
  個人生産性は上がるが、後工程のボトルネックで全体は伸びにくい。
• 領域分割が鍵
  UI/スタイルはAI寄せの“割り切り領域”。
  料金・整合性・監査などの中核ドメインは“守る領域”で人間が責任を持つ。
• レビューの主役はモデリング
  どのドメイン概念をどう変えたのか――モデル差分の説明可能性が最優先。
• AIテストの落とし穴
  生成は容易だが冗長・重複が増えがち。フォーマットと制約が不可欠。
• 社会的シフト
  “誰でも作れる”裾野が広がる一方、プロダクトの品質基準は上がる。プロは**「難しいところを壊さず速く」**が要請される。

3. 所感のまとめ

• **生産性向上＝速度向上ではなく“楽になった”**段階。QOLは上がるが、事業速度に直結しない場面が多い。
• UIは“vibe coding”的な微調整がしやすい。一定のコード品質低下は割り切っても良い。
• 金銭やデータ整合性は落とせない。この領域はモデル理解と人の責任が必須。
• AIは複雑ドメインが苦手で、アウトカムに結びつけにくい課題が残る。
• 空いた時間を何に再投資するか。本質的課題へ向かうか、QOL向上で終わるかで差が出る。
• AIの効果測定はまだ早い。昔はてブを1週間で出せたが、今3か月かかるのは要求品質が上がったため。
• レビューで見るべきは“AIコードの良し悪し”より“モデルの妥当性”。ブラックボックスを増やさない。
• AI生成テストは量が過剰になりがち。フォーマット/制約で引き算すること。
• モデル理解の補助としてAIは有効だが誤答も多い。議論→メンタルモデルの共有が肝。
• AIは足し算、人間は引き算。要件定義で引き算できないと無駄や漏れが増える。
• 現状は“幻滅期”で“生産性2倍”は起きないが、修復期に向けて活用ポイントが見えてくる段階。

4. 実務に落とす：役割分担とガードレール

4.1 割り切る領域（AI寄せ）

• UI生成／スタイル調整／文言／単純CRUD
• ローカルツール・スクリプトの叩き台

4.2 守る領域（人間が責任）

• 料金・課金、在庫・予約、会計整合性、監査・コンプラ
• データモデル変更、スキーマ移行、イベント契約（API/I/O）

原則：PRで**「今回は割り切る領域 or 守る領域」**を明記 → レビュー深度とテスト強度を事前合意。

5. PRテンプレ＆レビュー運用（あくまで例）

5.1 PR テンプレート

## 目的 / ユーザーストーリー
（誰の、どの課題を、どう改善するか）

## 対象領域（※どちらか必須）
- [ ] 割り切る領域（UI/生成/CRUD）
- [ ] 守る領域（料金/整合性/監査/データモデル）

## 変更の層
- [ ] UI
- [ ] アプリ（サービス/クライアント）
- [ ] ドメイン（※モデル変更の有無を次項に）
- [ ] データ（スキーマ/移行/整合性）

## モデル変更（ある場合は必須）
- 変更意図：どの概念を、なぜ、どう再定義/追加/分割したか
- 差分の影響：読みモデル / 書きモデル / API / UI / データ移行

## リスクとロールバック
- 失敗検知条件 / フィーチャーフラグ / 切戻し手順

## テスト観点
- ユニット（重要ドメインは必須）
- 統合（境界I/O）
- E2E（クリティカルパスのみ）

5.2 レビュー観点（例）

1. モデル意図：何を、なぜ、どう変えた？（説明可能性）
2. 境界影響：API／イベント／データI/Oに破壊的変更なし？
3. テスト妥当性：壊れやすい箇所を刺せている？冗長ではない？
4. PR粒度：巨大PRは分割（目安：＋400行超は切る）

6. AI生成テストのガイドライン（引き算の作法）

• 重要ドメインはユニット必須（料金・決済・整合性）
• 統合テスト重視：モックしすぎない。境界I/Oは実体験に寄せる
• E2Eは絞る：クリティカルパスのみ（過多＝脆い＆遅い）
• 冗長抑制：同値類／境界値に寄せ、重複ケースを排除
• 生成プロンプトに制約を書く：
  • 「ケース数上限：8、重複NG、境界値を優先、無意味なモック禁止」
  • 「観点ごとに理由を併記（レビューで削除可）」

7. 指標設計：アウトプットからアウトカムへ

速度系

• リードタイム（Issue → 本番）
• PRサイズ中央値、レビュー滞留時間
• 変更失敗率（Change Failure Rate）

品質系

• リリース後7日以内のHotfix率／ロールバック率
• 重要ドメインのバグ密度
• ユーザー影響（問い合わせ割合／NPS悪化要因）

運用

• 週次で「Hotfix率・ロールバック率・レビュー滞留」を3点監査
• 改善タスクはスプリントに定常枠で積む（速度と信頼性の両立）

8. モデル議論の現実解（ドキュメント万能主義を避ける）

• AIで60点の叩き台を速く出し、人間の“引き算”議論で削る。
• すべてを完全ドキュメント化するのは非現実。
  • Presenter（例・ケース・計算結果）に具体を蓄積し、メンタルモデルを同期
  • 変更ごとに 「モデル差分の要約」 をPR本文へ
  • 永続化はWiki／ADRで要点のみ（過剰な“更新負債”を作らない）

9. 失敗あるある（アンチパターン）

• AI生成フルPRをそのまま投げる → レビューが“中身”より“表面”に終始、後で爆発
• UIの割り切りをコアにも適用 → 料金・整合性の事故
• E2E過多 → flaky化・CI遅延・保守コスト増
• メトリクスがアウトプット寄り → リリース件数だけ増え、Hotfix率が悪化

10. ステップ別ロードマップ（幻滅期 → 修復期 → 拡張期）

幻滅期：とりあえず使う → 「楽」だけ増える

✅ PRテンプレ導入／レビュー観点の順序化／CI前段10分ルール

修復期：使い所と守る所が判る

✅ 割り切る vs 守るの明文化／AIテストの制約プロンプト
✅ 3点監査の週次ループ（Hotfix／ロールバック／滞留）

拡張期：モデル差分管理と自動生成の品質が安定

✅ モデル差分 → 実装の自動連携
✅ 設計ドキュメント → コードの一部自動化