こんにちは😊
株式会社プロドウガの@YushiYamamotoです！
JapanLifeStartの開発・運営を担当しながら、React.js・Next.js専門のフリーランスエンジニアとしても活動しています❗️
最近、Cursor や GitHub Copilot のおかげで実装スピードが爆上がりしていますよね。
しかし、それと同時にこんな悩みも増えていませんか？
- 「一見動くけど、エッジケースで落ちるコードが生成された」
- 「レビューしたら、セキュリティ的にアウトな実装だった」
- 「AIに任せすぎて、仕様の把握が曖昧になった」
AI開発において、価値は**「速さ」から「事故らない品質管理」へシフトしています。
今回は、私が実務で使っている「AIによるやらかしを事前に防ぐチェックリスト30」**を公開します。
PRのテンプレートや、セルフレビューの指針としてご活用ください！
0. まず守る「AI開発の3原則」 🛡️
チェックリストの前に、この3つだけはチームの共通認識にしましょう。
- AIに“判断”させない
- 判断基準（要件・制約・OK/NGライン）は人間が先に言語化する。
- AIに“全文生成”させない
- 1ファイル丸ごとではなく、関数単位・パーツ単位で少しずつ積み上げる。
- AIに“秘密”を渡さない
- APIキー、顧客個人情報、社内限定URLは絶対に入力しない。
1. 事故らないチェックリスト30（保存版） ✅
PR作成前や、実装開始時にコピーして使ってください。
A. 要件・タスク分解（作業を始める前に）
- 目的を1文で固定したか（何を良くする？ 何を変えない？）
-
変更範囲を宣言したか（例：
/app/settings配下のみ、APIスキーマは触らない） - 受け入れ条件（AC）を箇条書きにしたか（UI挙動・エラー処理・レスポンシブ）
- “絶対に壊したくない挙動” を列挙したか（課金フロー、ログイン状態維持など）
- 既存コードの読み取りを先にやらせたか（実装前に「理解メモ」を出させて認識を合わせる）
- 「まず小さなPR」を前提にしたか（1PR 200行以内がAI活用の安全圏）
B. プロンプト設計（AIへの指示出し）
- 指示は「役割→制約→出力形式」の順で書いたか
- 出力形式を固定したか（1.変更方針 2.具体差分 3.影響範囲 4.テストプラン）
- “推測禁止”を明示したか（「不明点は勝手に補完せず質問して」と指示）
-
“参照元”を限定したか（
@Files等で余計なコンテキストを読ませない） - 「提案→実装」の二段階を踏んだか（いきなりコードを書かせない）
- 依存ライブラリ追加の可否を決めたか（勝手にnpm installさせない）
C. コード品質（TypeScript / React）
-
anyを増やしていないか（AIは型パズルを諦めてanyに逃げがち） - Props/戻り値の型を“境界”に置いたか（公開インターフェースは厳格に）
- 状態（State）は最小か（サーバー状態をコピーして持っていないか）
- 副作用（useEffect等）は集約されているか（散らばるとバグの温床）
- 例外系のUIを用意したか（ローディング・データ空・エラー表示）
- コピペコードを量産していないか（共通化するか、あえて分けたか意図があるか）
D. デザイン・アクセシビリティ
-
セマンティクスは正しいか（
divボタンになっていないか） - キーボード操作（Tab移動）ができるか
-
aria-*属性に根拠があるか（AIが雰囲気で付けた属性を鵜呑みにしない） - エラーメッセージの視認性は十分か（色だけでなく文字やアイコンで伝わるか）
E. テスト・デバッグ
- 最低1つは自動テストを追加したか（ロジックの単体テスト等）
- 手動テスト手順をPRに書いたか（URL・操作手順・期待値）
- デバッグログ（console.log）の削除忘れがないか
- リファクタ前後で「同じ入力→同じ出力」を確認したか
F. セキュリティ・運用
-
秘密情報がコミットに含まれていないか（
.env、ハードコードされたトークン） - 追加したライブラリのライセンス/脆弱性を確認したか
- 生成コードが既存OSSの丸写しになっていないか（著作権リスク低減）
- リリース後の監視ポイントを決めたか（どこを見れば成功/失敗がわかるか）
2. そのまま使えるプロンプトテンプレ集 🤖
AIに「どう指示すればいいか」迷った時はこれを使ってください。
テンプレ1：まず“理解”だけさせる（実装前）
いきなりコードを書かせると視野が狭くなります。まずは全体像を把握させます。
あなたはシニアフロントエンドエンジニアです。
【目的】
◯◯ページのデザイン崩れを修正する（機能ロジックは変えない）
【制約】
- 変更は /app/ui/dashboard 配下のみ
- 新規のnpmパッケージ追加は禁止
- 不明点は推測せず質問すること
【タスク】
関連コードを読み、現状の仕様とデータフローを箇条書きで説明してください。
【出力形式】
1) 現状の仕様理解
2) 修正による影響範囲の予測
3) 不明点・確認事項（あれば）
テンプレ2：差分を小さく切る（PR分割）
AIに「全部やって」と言うと失敗します。タスクを分割させましょう。
次の改善を行いたいです：
[ここにやりたいこと]
一度に実装するとPRが大きくなりすぎるため、作業を「3つの独立したプルリクエスト」に分割する計画を立ててください。
各PR計画には以下を含めてください：
- 変更対象ファイル
- 変更概要（100字以内）
- リスク・注意点
- テスト方法
テンプレ3：レビュー観点でセルフチェック
自分が書いた（AIに書かせた）コードを、AI自身に厳しくレビューさせます。
次の差分（Diff）に対して、シニアエンジニアの視点でコードレビューを行ってください。
指摘事項を重要度順（High/Medium/Low）で10個挙げてください。
特に以下の観点を重視してください：
- 型安全性（anyの排除）
- Reactのレンダリングパフォーマンス
- アクセシビリティ
- エラーハンドリングの漏れ
- 将来的な保守性
3. “AI導入”より効く、チーム運用の型 🤝
AIツールを導入するだけでは品質は上がりません。「運用」でカバーしましょう。
おすすめ：PRテンプレートへの組み込み
GitHub の Pull Request Template に以下のような項目を追加するのが効果的です。
## AI使用状況
- [ ] AI使用：あり / なし
- 使用箇所：（例：テストコード生成に使用、ロジックは手動）
- 人間が判断したポイント：（例：AIはA案を推したが、保守性を考慮してB案を採用した）
## 安全確認チェックリスト
- [ ] 要件外のファイル変更がないことを確認した
- [ ] 秘密情報が含まれていないことを確認した
- [ ] 自動テスト/手動テストがパスした
AIを使ったかどうかよりも、「どこをAIに任せ、どこを人間が責任を持って判断したか」 を記録に残すことが、将来の負債を防ぐカギになります。
4. 15分でできる“最低限の安全装置” 🔒
最後に、ツール側で防げるミスは自動化しておきましょう。
- Lint / Format の強制
- AIの出力はフォーマットが崩れがちです。保存時に
Prettierが走るようにし、コミット前にESLintで弾きましょう。
- 型エラー 0 の維持
-
tsconfig.jsonでnoImplicitAny: trueは必須です。AIがanyで逃げようとするのをコンパイラで阻止します。
- 小さなテストの追加
- AIにコードを書かせたら、セットで「そのコードの単体テスト」も書かせる癖をつけましょう。テストがあれば、将来のAI改修時にもデグレに気づけます。
5. まとめ
生成AIはエンジニアにとって最強の「加速装置」ですが、ハンドルを握っているのは私たち人間です。
事故（バグ・障害）を起こすのは、大抵の場合、要件定義の曖昧さ や 確認不足 といった人間側のミスです。
このチェックリストを活用して、「爆速なのに、めちゃくちゃ堅牢」 な開発スタイルを手に入れてください！
🚀 エンジニアの方へ：10万円もらえる特別キャンペーン
現在、フリーランスエージェントの 「クラウドワークステック」 が、紹介経由での登録＆稼働で「10万円（税込）」がもらえる 異例のキャンペーンを実施中です。
「自分の市場価値（単価）を知りたい」「週3日からの副業・リモート案件を探している」という方は、ぜひこの機会に登録してみてください。
※キャンペーンは予告なく終了する場合があります。
最後に：業務委託のご相談を承ります
私は業務委託エンジニアとして、Next.jsを用いたモダンなWeb開発や、開発チームへのAI導入・定着支援を行っています。
「AIを使って開発効率を上げたいが、品質担保が不安」「レガシーな現場にモダンな風を入れたい」といったご相談がありましたら、お気軽にご連絡ください。
👉 ポートフォリオ
📩 お問い合わせ: お気軽にご連絡ください