AIとの協働開発で失敗しないための「確認必須ルール」

はじめに：AIが犯した「常識的な」ミス

ページネーション機能を削除してしまった

人間のエンジニアなら「あ、これは必要だから残しておかないと」と自然に判断するところを、AIは「技術的に不要」と判断して削除してしまいました。

なぜこんなことが起きたのか

人間の思考プロセス

経験を積んだ開発者は、以下のような思考を自然に行います：

「このページネーション機能は何のためにあるんだろう？」
「記事が100件、1000件になったときのことを考えると...」
「ユーザー体験を考えると、これは必須機能だな」

AIの思考プロセス

一方、AIは以下のように考えました：

データ構造を効率化 → サーバーサイドレンダリングで最適化
古いコンポーネントは技術的に古い → 新しく作り直す
機能の意図や必要性を考慮せずに実装

問題の本質

AIには以下の特性があります：

文脈の継続性を理解しない

「常識」を持たない

実装を優先する性質

解決策：確認必須ルール

1. 確認が必要な5つの状況

markdown

1. **機能の削除**
   - 既存の機能、コンポーネント、ファイルを削除する場合

2. **大きな構造変更**
   - ディレクトリ構造の変更
   - データ構造の大幅な変更
   - アーキテクチャの変更

3. **矛盾や不明点の発見**
   - ドキュメントと実装の矛盾
   - 要件の曖昧さ
   - 複数の実装方法がある場合

4. **破壊的変更**
   - 後方互換性を失う変更
   - APIの仕様変更
   - 既存データに影響する変更

5. **セキュリティ関連**
   - 認証・認可の変更
   - データの公開範囲の変更

2. 確認プロセスの実装

markdown

⚠️ 確認が必要です：

**状況**: NewsGridコンポーネントのリファクタリング
**発見**: 既存のページネーション機能があります
**技術的判断**: サーバーサイドレンダリングでは不要
**懸念**: ユーザー体験への影響が不明

以下の選択肢があります：
1. ページネーション機能を維持して実装
2. ページネーション機能を削除して実装
3. 別の方法で実装

どれを選択しますか？理由も教えてください。

3. トリガーベースの思考

削除トリガー：
思考：「この機能は新しい実装では不要だ」
→ 停止：「なぜこの機能があるのか？削除して問題ないか？」
→ 確認：人間に削除の是非を確認

実装例：プロジェクトへの適用

CLAUDE.mdへの追記

markdown

## 🚨 AI開発における確認必須ルール

### 以下の状況では必ず人間に確認を求めること

1. **機能の削除**
   - 既存の機能、コンポーネント、ファイルを削除する場合
   - 例：「このページネーション機能は新しい実装では不要と判断しましたが、削除してよろしいですか？」

要件の明文化

markdown

#### 5. **ページネーション必須**
- **重要**: コンテンツ一覧ページには必ずページネーション機能を実装すること
- 1ページあたりの表示件数: 9-12件程度（モバイルでも見やすい数）
- ページネーションがないと、記事が増えた際にパフォーマンスとUXが著しく低下する
- リファクタリング時も**既存のページネーション機能は必ず維持する**

効果と期待される成果

重要な機能の保護

開発の安全性向上

知識の蓄積

まとめ

AIとの協働開発では、技術的な実装能力は高いものの、文脈理解や機能の意図把握には限界があります。

確認を求める文化

AIの「実装優先」の性質を適切に制御
人間の経験と判断を適切なタイミングで活用
より安全で品質の高い開発を実現

AIは強力なツールですが、人間の経験と判断を代替するものではありません。両者の強みを活かす仕組みづくりが、成功の鍵となります。

今後の展望

この確認ルールは、AI開発の成熟とともに進化していく必要があります。実際の運用を通じて得られた知見を継続的に反映し、より効果的なルールへと改善していきましょう。

人間とAIが真のパートナーとして協働できる未来に向けて、一歩ずつ前進していきます。