この記事は、IT初心者の私がコード生成系AI（以下AI）を使って小さめの機能開発を進めるときに「失敗しにくかったやり方」をまとめた学習記録です。特に テーブル定義書・機能要件・バリデーション設計をAIに渡す／タスクを分割する／手順を明確化してステップバイステップで進める／コーディング前に変更内容の提示と許可取り／レビュー→修正→次へ のループを重視しています。
前提とゴール
- 小さなCRUD機能や入力バリデーションの実装を想定
- 自分は要件を「読む」はできるが「コード化」に自信がない段階
- ゴールは「正しく動く最小の機能」を安全に積み上げること
1. 資料をAIに渡すときのコツ（テーブル定義・機能要件・バリデーション）
最初に構造化して渡すと精度が上がりました。私は以下の3点をセットで渡します。
- テーブル定義書：DDLまたは項目一覧（型・制約・索引）
- 機能要件：ユーザーストーリー＋完了条件（受け入れ基準）
- バリデーション設計：入力欄×制約×エラーメッセージ
例（抜粋）：
-- users テーブル
CREATE TABLE users (
id BIGINT PRIMARY KEY,
email VARCHAR(255) UNIQUE NOT NULL,
age INT CHECK (age BETWEEN 0 AND 150),
created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP
);
# バリデーション設計（抜粋）
users:
email:
- required: true
- format: email
- message: "メールアドレスの形式が正しくありません"
age:
- required: true
- type: integer
- min: 13
- message: "13歳以上のみ登録可能です"
ポイントは 用語の統一（例：会員=ユーザー） と 境界値の明記（min/max, 長さ, 文字種） です。
2. タスクを分割する（WBSミニ版）
いきなり「実装して」だと暴走しやすいので、まずAIにWBSミニ版を出させます。出力フォーマットを固定するとブレません。
# 出力フォーマット（例）
- タスク名:
- 目的:
- 前提/入力:
- 成果物(完了条件):
- 手順(番号付き):
- 観点チェック(境界値/例外/ログ/性能 など):
- 想定所要時間(目安):
3. 実行するタスクの詳細と作業手順を出してもらう
WBSから今やるタスクを1つ選び、AIに詳細化させます。
次のタスクを詳細化して。まだコードは書かない。
[タスク名] ユーザー登録APIの入力検証
- 目的/前提/成果物/手順/観点チェック を上のフォーマットで。
- 依存する資料: テーブル定義書, バリデーション設計
- 出力の最後に「実装前の確認質問」を3つ出して
ここでAIが出した手順と完了条件を人間の自分が確認します。齟齬があればこの段階で直すと後が楽でした。
4. ステップバイステップで進める（1手順ずつ）
実装は1ステップずつ。AIに「次へ進む許可待ち」をさせます。
これから Step 1 だけ実行してください。出力は:
- 変更予定ファイル/関数
- 擬似コード
- テスト観点（境界値/異常系）
最後に「Step 1 完了」と書いたら一旦停止。こちらのOKが出るまで次に進まないこと。
「止まってくれるか？」が重要で、ここを守らせるとコードの大幅巻き戻しが減りました。
5. コーディング前に「変更内容の提示と許可取り」
コード着手前に差分の宣言を必ずさせます。疑似パッチや影響範囲を出させるのがコツ。
コードを書く前に次を列挙:
1) 変更予定ファイルと理由
2) 追加/変更する関数のシグネチャ
3) 既存仕様との差分(何を/なぜ変える)
4) 影響範囲（DB/例外/ログ/パフォーマンス）
5) 擬似パッチ(unified diff 風)
私が「許可します」と言うまでコードは出力しないで
擬似パッチ例：
diff --git a/src/user_service.ts b/src/user_service.ts
- export function createUser(u: User) { ... }
+ export async function createUser(u: User) {
+ // バリデーション追加・メール重複チェック
+ }
6. AIのコード確認→修正→次へ（レビューの型）
提出されたコードは観点チェックでレビュー→修正指示→合格したら次の手順へ。
このコードを次の観点でレビュー:
- 仕様準拠(DDL/バリデーション表)
- 境界値(空文字/最大長/マルチバイト/年齢=13/14/150/151)
- 例外とメッセージ
- ログと戻り値/HTTPステータス
- テスト(正常/異常/性能の簡易計測)
不足があればパッチ形式で修正案のみ提示して
ユニットテスト雛形の生成も有効でした。
// Jest 例: users.service.spec.ts
describe("validateUser", () => {
it("メール形式NG", () => { /* ... */ });
it("年齢=13はOK", () => { /* ... */ });
it("年齢=151はNG", () => { /* ... */ });
});
7. つまずいたポイント（初心者視点）
- AIの早とちり：資料を全部読んだ前提で進めがち → 「引用で根拠を示して」と促すと改善
- 古い文法やライブラリ：念のためバージョン宣言を先にさせる（Node/フレームワーク/ORM）
- テスト軽視：最初に受け入れ基準と境界値表を出させ、テストケースに機械的に落とす
8. 向き不向き（使ってみた感想）
- 向いている：CRUD、入力チェック、DTO/スキーマ定義、単体テストの雛形、リファクタの提案
- 苦手：仕様が曖昧なままの設計、既存プロジェクトの巨大改修、一度に多変更を混ぜる作業
9. まとめ（私なりの運用ルール）
- 資料は構造化して渡す（DDL/要件/バリデーション）
- まずWBSミニ版→「今やる1タスク」に絞る
- 手順ごとに停止して合意を取る
- コーディング前に変更宣言と許可取り
- レビュー観点をチェックリスト化してループを回す
最後に、私が常用しているプロンプトのテンプレです。コピペしてカスタマイズすると安定しました。
# 目的
users の登録APIを安全に実装する
# 資料
- DDL: [貼り付け]
- バリデーション表: [貼り付け]
- 受け入れ基準: [貼り付け]
# 要求
1) まずWBSミニ版を上記フォーマットで
2) 今やるタスクを私が選ぶまで実装しない
3) コード着手前に変更内容/影響範囲/擬似パッチを出し、許可待ち
4) 各ステップの最後は「Step N 完了」で停止
この流れを守るだけで、初心者の私でも「少しずつ正しく作る」感覚を掴めました。焦らず、小さく進めて、必ず止める。これが一番の学びでした。