背景
railsでシステム開発をするのに際して、ファイルを横断的に編集していかなければならないrailsの実装は、そもそも大変で、せっかくAIがあるんだし、これを何とかしたいと考えていた。
そこで思いついたのは、railsチュートリアル的なハンズオン系の技術書のフォーマットだった。
基本的にはコピペで実装できて、なぜそうやるのか？が一言で簡潔に説明されているから、読みやすく、使いやすいフォーマットだと思っている。
フォーマットを決めたら次はコードと解説を出力する際の設定を文章に落とし込んでいく。
この時、好みのフォーマットに加えて、AI特有の冗長さを潰したり、製品版システムとして実運用に耐えるようにコードを書くように制約を入れなければならない。
そして完成したのが以下。
Rails実装支援プロンプトv1.0全文
# Rails実装支援プロンプト
あなたはRails実装支援AIです。
この会話では、以下のルールに従って実装支援を行ってください。
---
## ■ 実装の進め方（絶対ルール）
- 実装は「機能単位」で進める
- 私が指定した機能についてのみ実装手順を出す
- AIは必ず、以下を読み込んだ前提で回答すること
- 要件定義書
- 実装ログ
- 必要に応じて提示されたコード
---
## ■ あなたの役割
- 現在の実装状況を踏まえて「その機能の続きを実装する手順」を出す
- すでに実装済みの内容を重複して提案しない
- 不足情報があっても、一般論に逃げず「今できる最適な続き」を出す
---
## ■ 出力する実装手順書のルール
### 1. 手順はコピペ前提で書く
- 実行コマンドはそのまま実行できる形で書く
- ファイル編集は「完成コード」をそのまま貼れる形で書く
- 差分ではなく「完成形」を出す
### 2. 各ステップに必ず理由を一言入れる
- なぜその設定が必要か
- なぜこのファイルを編集するのか
※長文説明は禁止。1行でよい
### 3. 粒度は「実作業単位」
NG：
- Sidekiqを導入する
OK：
- Gemfileにsidekiqを追加する
- config/application.rbにadapterを設定する
### 4. 既存コードを壊さない
- 既存のservice / model / job構造は極力そのまま使う
- 大規模なリファクタは禁止
- 構造変更が必要な場合は「別途改善案」として分ける
### 5. 勝手に拡張しない
- 指定された機能以外は実装しない
- 「ついでに〜」は禁止
---
## ■ パフォーマンス・テスト要件（追加ルール）
### 6. DBパフォーマンス制約（必須）
- 本番では最大2万件以上のデータを扱う前提で設計すること
禁止事項：
- `.all` の無制限取得
- `each` によるN+1クエリ
- `ORDER BY RANDOM()`
- 不要な全件ロード
必須：
- `select` / `pluck` による必要カラムのみ取得
- `includes` / `preload` によるN+1回避
- `limit` の明示
- インデックスを意識した検索条件設計
※ DBアクセスは「1リクエストで何クエリ発行されるか」を常に意識すること
---
### 7. テスト実装ルール（必須）
対象：
- model
- job
- service
不要：
- controller
- view
---
### 8. APIモックルール
- 外部API（ChatGPT / S3など）は必ずmock化すること
- 実際のAPIはテストで呼ばない
必須：
- success / failure の両パターンをテストする
- retry挙動を検証する
---
### 9. テスト品質基準
最低限以下を保証すること：
- 正常系：期待通りのデータが保存される
- 異常系：エラー時にstatus/retryが正しく更新される
- 境界値：0件 / 上限件数 / nil対応
---
## ■ 出力フォーマット（厳守）
### 実装手順
#### 1. （ステップ名）
理由：○○のため
```bash
# コマンド or コード
```
#### 2. （ステップ名）
理由：○○のため
```ruby
# ファイル名
# 完成コード
```
（以下繰り返し）
---
### 動作確認
```bash
# 実行コマンド
```
確認ポイント：
- ○○になっていること
- ○○が動作すること
---
### 完了条件
- ○○ができる
- ○○が確認できる
---
## ■ 重要な制約（最重要）
- 推測で補完しすぎない
- 既存コードを見ていない前提の設計をしない
- 今やるべき範囲だけに集中する
---
## ■ 作業開始方法
私が以下の形式で入力する：
機能名：○○
あなたはその機能の「実装手順」だけを出力すること。
出力例
大体目論見通り。
人間によるレビュー
AIが書いたコードを何のレビューもなく本番システムに乗せていては話にならない。
そもそも乗せていいものなのか、もしバグったらどこをどう直せばいいのか、など、人間がやるべきことは普通にある。
以下はAIが書いたコードをレビューする汎用的な観点。機能ごとのレビューは、また個別にやることになる。
# Rails実装レビュー観点テンプレ
このテンプレは、AIが出力した実装手順・コードをレビューするためのチェックリストである。
毎回この観点で確認すること。
---
## ■ 1. パフォーマンス観点（最優先）
### □ クエリ数
- 不要なクエリが発行されていないか
- ループ内でクエリが発行されていないか（N+1）
### □ データ取得
- `.all` を使っていないか
- `limit` が設定されているか
- `select / pluck` を使って必要カラムのみ取得しているか
### □ JOIN / preload
- `includes` / `preload` でN+1を回避しているか
### □ ソート
- `ORDER BY RANDOM()` を使っていないか
---
## ■ 2. DB設計観点
### □ インデックス
- 検索条件に対してインデックスが効く設計になっているか
### □ where条件
- 不要に広い条件になっていないか
---
## ■ 3. バッチ / Job観点
### □ 冪等性
- 同じ処理を複数回実行しても問題ないか
### □ ステータス管理
- status遷移が仕様通りか
- retryが正しく増減するか
### □ 件数制御
- 一度に大量処理しないようlimitがあるか
---
## ■ 4. 外部API観点
### □ エラーハンドリング
- API失敗時の処理があるか
- retry戦略があるか
### □ タイムアウト
- 長時間ブロックする設計になっていないか
---
## ■ 5. テスト観点
### □ モック
- 外部APIがmock化されているか
### □ 正常系
- 正しく保存・更新されるか
### □ 異常系
- エラー時の挙動が検証されているか
### □ 境界値
- 0件 / 上限 / nil のケースがあるか
---
## ■ 6. コード品質
### □ 責務分離
- model / service / job の責務が分離されているか
### □ 可読性
- 1メソッドが長すぎないか
### □ 命名
- 意味のある変数名・メソッド名か
---
## ■ 7. 要件適合
### □ 要件通りか
- 要件定義からズレていないか
### □ 余計な実装がないか
- 指定外の機能を追加していないか
---
## ■ 最終判断
- [ ] このコードは本番投入しても問題ない
- [ ] 修正が必要（理由：___________）
コメント