AIにボイラープレートを量産させる｜定型コードの安全な使い方
「またこのパターンか」
CRUDの4つ組、リクエストとレスポンスのDTO、設定ファイルの雛形、テストの下ごしらえ。書いていることはほとんど同じなのに、対象が違うから一つずつ手で写す。退屈だし、集中も切れる。そして地味に厄介なのが、こういう定型ほどコピペのつなぎ目で一箇所だけ直し忘れることです。
AIは、こういう仕事がとても得意です。「これと同じ形で、こっちのモデルの分も作って」と頼めば、一瞬で似た構造を並べてくれます。手が空くし、退屈から解放される。
ただ、そのまま全部を信じて流し込むと、似ているけれど少しだけ違うコードが静かに紛れ込みます。ボイラープレートは「同じであること」に価値があるのに、AIは頼まれてもいない気を利かせて、1箇所だけ命名を変えたり、あるべき検証を1つ落としたりする。数が多いほど、目視で気づきにくくなります。
この記事は、AIにボイラープレート（定型コード）を安全に量産させる頼み方と、目で追うべき最小の確認をまとめたものです。長く見えますが、全部は要りません。まず効く所から拾えば回ります。
30–60秒のファストパス（最低ライン）
- 手本を1つ渡す：ゼロから頼まず、自分が納得している1件を「これと同じ形で」と見本にする（20秒）
- 差分だけ指定する：変わるのは何か（モデル名・項目・型）を箇条書きで明示し、それ以外は変えないと伝える（20秒）
- 1個を精読する：出てきたうちの代表1個だけを丁寧に読み、手本と構造がズレていないか確かめる（20秒）
※本物の秘密情報（接続文字列・APIキー）は雛形に含めない。プレースホルダにしておく。
結論：AIへのボイラープレート量産は、「ゼロから生成させる」のではなく「自分が認めた手本を、差分だけ変えて複製させる」もの。まず効くのは、①納得できる1件を手本として渡す → ②変わる部分（名前・項目・型）だけを箇条書きで指定し「それ以外は変えるな」と添える → ③まず代表1個を精読して手本と一致するか確認 → ④残りは「手本との差分」だけを目で追う（全文は読まない）。AIは退屈な複製を肩代わりする相棒であって、あなたの規約を保証する人ではありません。手本の質が、量産物の質を決めます。
AIに量産させるのは、手を抜くためではありません。 退屈な写経で消耗する時間を減らして、本当に頭を使うべき所に集中するためです。
なぜボイラープレートはAIと相性がよく・同時に危ういのか
ボイラープレートは、AIがいちばん力を発揮する仕事のひとつです。構造が決まっていて、変わるのは一部だけ。「パターンを真似て、少しずらす」——これはまさに言語モデルの得意分野です。手本さえ渡せば、驚くほど速く、それらしい形を並べてくれます。
危ういのは、ボイラープレートの価値が「揃っていること」そのものにある点です。10個のCRUDが全部同じ書き方だからこそ、後から読む人が迷わず、直すときも一括で直せる。ところがAIは、頼まれてもいないのに次のような「気を利かせた不揃い」を混ぜてきます。
- 命名がひとつだけブレる：
userIdで揃えたいのに、1箇所だけuser_idになる - あるべき処理が1件だけ抜ける：他は入力チェックがあるのに、1つのDTOだけ検証が無い
- エラー処理の書き方が混ざる：例外を投げる版と、握りつぶす版が混在する
- 微妙に新しい/古い書き方が混ざる：一部だけ非推奨の書き方になっている
一つひとつは小さなズレです。でも、揃っているはずという前提で流し読みするから、数が多いほど見逃す。ここがボイラープレートAI活用の落とし穴です。逆に言えば、「揃える」ことにさえ気をつければ、AIは最高の複製係になります。次から、その頼み方です。
手本を渡して「複製」させる頼み方
コツは、AIに発想させないことです。ボイラープレートに創意工夫は要りません。求めるのは「揃った複製」だけ。だから、手本を渡して、変える所だけを指定します。
手順1：自分が納得している1件を手本にする
まず、自分の目で確認して「これでいい」と言える1件を用意します。ゼロから「CRUDを作って」と頼むと、AIは自分の好みの書き方で作り、それが規約と合っているかは運任せになります。そうではなく、手本を先に固めます。
次のコードを手本にします。（自分が認めた1件を貼る）
これとまったく同じ構造・同じ命名規則・同じエラー処理の書き方で、別のモデル用に作ってください。
手本が良ければ量産物も良い。手本が雑なら量産物も雑になる。最初の1件に時間をかけるのが、結局いちばん速い道です。手本の品質は、必要なら一度レビューしておくと安心です（→AI生成コードのレビュー・検証チェックリスト）。
手順2：変わる部分だけを箇条書きで指定する
次に、手本から何が変わるのかを明示します。ここが曖昧だと、AIは変える必要のない所まで「良かれと思って」触ります。
変えるのは次だけです。それ以外は一切変えないでください。
- モデル名：Order（手本は User）
- 項目：orderId, amount, status
- amount は整数、status は文字列
「それ以外は変えるな」の一言が効きます。命名の揺れ、処理の追加・削除といった勝手なアレンジを封じるためです。渡す前提や制約の書き方に迷ったら、こちらも参考になります（→AIにコードを書かせる前に渡す前提と制約）。
手順3：一度に欲張らず、数個ずつ出させる
10個まとめて頼むと、後半ほど手本から離れやすく、確認も大変になります。3〜5個ずつに区切って出させると、揃い方を保ちやすく、ズレにも気づきやすくなります。会話が長引くと生成がブレてくるので、区切りは体感速度と品質の両面で効きます（→AIとの会話が長引いて生成がブレる）。
手順4：秘密情報はプレースホルダにする
設定ファイルや接続まわりの雛形をAIに作らせるときは、本物の接続文字列・APIキー・パスワードを渡さない。YOUR_API_KEY のようなプレースホルダにしておき、実値は自分で後から埋めます。雛形は構造さえ合っていれば十分です（→社内データをAIに渡す前の線引き）。
量産物を「差分」で確認する
量産物は、全文を頭から読み直さないのがコツです。数が多いと集中が持たず、かえって見落とします。見るのは「手本との違い」だけ。揃っているはずの所が揃っているか、を確かめます。
まず代表1個を精読する
最初の1個だけは、手本と丁寧に見比べます。構造・命名・エラー処理・検証の有無が、手本どおりか。ここで問題がなければ「AIはこのパターンを正しく複製できている」と分かり、残りの確認が軽くなります。逆にここでズレていたら、頼み方を直してやり直すサインです。
残りは「差分」だけを目で追う
2個目以降は、手本と量産物を並べて差分を見るのが確実です。エディタの差分表示やレビューの目線で、「変わるべき所（名前・項目）だけが変わり、変わってはいけない所が揃っているか」を追います。とくに次の“不揃い”に注意します。
- 命名の揺れ：
userIdとuser_idのような表記の混在が1箇所だけ紛れていないか - 抜け落ち：他にはある入力チェック・NULLガード・ログ出力が、1件だけ無くなっていないか
- 勝手な追加：頼んでいない便利処理・分岐が足されていないか
- 書き方の混在：エラーの投げ方・戻し方が、手本と違う流儀になっていないか
動くかどうかは別で確かめる
揃っていることと、動くことは別です。そのまま流し込まず、最低限の動作確認を一度は通します。とくに設定ファイルやマイグレーションのような「間違うと後で痛い」定型は、コピーの直し忘れが致命傷になりやすい所です（→AI生成コードの動作確認｜そのまま使わない最低限の型）。
そのまま使えるチェックリスト
- ゼロから生成させず、自分が納得した1件を手本として渡したか
- 変わる部分（名前・項目・型）を箇条書きで明示したか
- 「それ以外は一切変えるな」と添えたか
- 一度に欲張らず、3〜5個ずつに区切って出させたか
- 秘密情報（接続文字列・APIキー）はプレースホルダにしたか
- まず代表1個を精読して、手本と構造が一致するか確かめたか
- 残りは手本との差分だけを目で追ったか
- 命名の揺れ・処理の抜け・勝手な追加・書き方の混在がないか見たか
- そのまま流し込まず、最低限の動作確認を一度通したか
明日やること
いきなり全部の定型をAIに置き換えようとしなくて大丈夫です。 明日は、いま目の前にある「同じような雛形の繰り返し」を1種類だけ選んでください。そのうちの1件を自分の手で丁寧に仕上げて手本にし、「これと同じ形で、変えるのはここだけ」と頼んで2〜3個だけ複製させてみる。揃ったまま増える手応えと、確認が「差分だけ」で済む軽さを、まず小さく体感するのがおすすめです。
ボイラープレートは、頑張って手で書くほど偉い仕事ではありません。 揃った手本を用意して、複製はAIに任せ、自分は差分だけを見る。空いた時間を、本当に考えるべき設計や名前づけに回す。その切り替えができれば、退屈な繰り返しは、少しだけ肩の軽い作業に変わります。