AIコーディングの限界点：プロンプトだけでは拾えない「暗黙の要件」とレビュー観点
本記事は、AIコーディングツール（Claude Codeなど）を活用して業務を進める開発者が、AIが生成したコードをレビューする際の具体的な観点について詳細に解説しています。筆者は、AIが構文エラーや基本的なCRUD処理はベストプラクティスに基づいて高い精度でこなすものの、人間が持つ「暗黙の要件」や「設計上の配慮」が欠落している点を指摘しています。
特に重要なレビュー観点として、「削除方法の指定（論理削除か物理削除か）」「排他制御の方式（楽観ロックか悲観ロックか）」「数値や日付の取り扱いにおける境界値や丸め処理のルール」「IDの採番方式」など、プロンプトに明記しにくい前提条件の確認が挙げられています。また、コードの品質面では、命名規則や設計の一貫性の欠如、既存の共通処理の再発明（重複）、過剰な抽象化による設計の複雑化が問題視されています。
さらに、より高度なレビュー観点として、パフォーマンス面での「N+1問題」や、トランザクション境界の誤り（外部API呼び出しをトランザクション内に入れるなど）の指摘、そして「可逆性」の確認が求められています。設計方針の観点からは、ドメインロジックが適切な層に留まっているか（貧血ドメインモデルの回避）や、サービスクラスの肥大化を防ぐ責務の分離が重要です。結論として、AIコーディングの精度を向上させるためには、単に機能要件を渡すだけでなく、これらの「暗黙の前提」まで言語化し、プロンプトを極めて詳細に記述することが不可欠であると提言しています。
背景
近年、GitHub CopilotやClaude CodeといったAIコーディングアシスタントの普及により、開発プロセスは大きく変化しています。AIはコーディングの効率を飛躍的に向上させましたが、その生成コードが「業務上の暗黙のルール」や「大規模システム設計の複雑な制約」を理解できるかどうかが、開発現場の新たな課題となっています。
重要用語解説
- 論理削除: データを物理的に消さず、削除フラグ（is_deletedなど）を立てて「削除済み」として扱う方式。データ復旧が可能であり、履歴保持が必要なシステムで用いられます。
- 排他制御: 複数のユーザーが同時に同じデータ（レコード）を編集しようとした際に、データの一貫性を保つために、同時に書き込みを制限する仕組み。ロック方式（楽観/悲観）が用いられます。
- N+1問題: データベースのクエリ（問い合わせ）において、本来1回の処理で済むはずのデータ取得を、ループ処理の中で都度クエリを発行してしまうことで、処理回数がN+1回に増大するパフォーマンス上の問題点。
今後の影響
AIコーディングは開発速度を劇的に向上させますが、レビュー担当者（人間）の役割は「コードの書き方」から「要件の定義と設計の検証」へとシフトします。開発者は、AIが苦手とする「ビジネスルール」「例外処理」「アーキテクチャの整合性」をプロンプトとして言語化する能力（プロンプトエンジニアリング）が、今後の必須スキルとなります。