AIペアプログラミングを実務に落とし込む — 設計から PR まで

結論：3階層に分ける

• 完全に任せる：定型的な実装（CRUD、テスト、リファクタ）
• 対話で詰める：設計判断（API設計、エラーハンドリング戦略）
• 人間だけで決める：技術選定、セキュリティ要件、外部影響の大きい変更

1. 完全に任せる領域

Cursor の Composer や Claude Code に「このディレクトリ全体に Jest テストを追加」「この関数のエラーハンドリングを try/catch に統一」と投げる。差分を確認して PR を切るだけ。1時間の作業が10分になる。

2. 対話で詰める領域

API のレスポンス形式や、認証フローの実装方針など、複数の選択肢がある領域。AI に「3案出して、それぞれのトレードオフを説明」と投げ、人間が判断する。AI は「気付かなかった選択肢」を提示してくれる。

3. 人間だけで決める領域

• 技術スタック選定（Next.js vs Remix など）
• セキュリティ設計（認証方式、データ保管）
• DB スキーマの本質的な変更
• 外部 API への依存（コスト・SLA・乗り換えコスト）

4. PR レビューに AI を組み込む

GitHub Copilot Code Review や Claude のレビュー機能で、人間レビュー前に1段階チェックする。明らかなバグ・命名ミス・テスト不足を AI が拾い、人間は設計とビジネスロジックに集中できる。

Q. AI が書いたコードのバグ責任はどうなりますか？

A. コードを通した人間のもの。AI は「速く書ける道具」であって、責任の主体ではない。レビュー文化を一段引き締める必要がある。

まとめ

AI ペアプログラミングは「全自動」ではなく「3階層の使い分け」が現実解。任せる領域を増やし、判断する領域に時間と思考を集中する — それが今のエンジニアの最適化。