システム開発の現場において、古くから存在し、未だに解決されていない根深い問題があります。それは「ボイラープレート（定型コード）のコピペ」です。
新しい機能を追加する際、多くのエンジニアは似たような既存のファイルをコピーし、必要な部分だけを書き換えるという作業を行います。いわゆる「秘伝のタレ」の使い回しです。一見効率的に見えるこの行為ですが、実は重大なリスクを孕んでいます。
「コピー元のコード自体が古い規約で書かれていた」「不要な依存関係まで持ち込んでしまった」「修正すべき箇所を見落としてバグを生んだ」——開発チームにおいて、こうした課題は頻繁に発生します。
VSCodeなどのモダンなエディタには「スニペット」機能があり、定型文を登録しておくことができます。しかし、実情として多くのチームではスニペットのメンテナンスが追いつかず、結局は「近くにあるファイルをコピペして修正」というアナログな手法に戻ってしまっています。
今回は、この「コピペ開発」からの脱却をテーマに、AIプロンプトエンジニアリングを活用した新しいアプローチについて考えます。単にコードを書く時間を短縮するだけでなく、「チーム全員が、自然と正しい規約でコードを書ける状態」を作るにはどうすればよいのか。
この難題に対し、AI駆動開発やプロジェクトマネジメントの観点から、実践的な解決策を紐解いていきます。
自動化は単に作業を楽にするためではなく、品質を担保する文化を作るための手段です。AIの本質的な価値を「コンテキスト理解」に見出す視点は、多くのテックリードやエンジニアリングマネージャーにとって、プロジェクトのROI最大化に向けた重要なヒントとなるはずです。
Q1: 静的スニペットとAI生成の決定的な「思考の差」
質問： VSCodeには元々強力なスニペット機能があります。ユーザー定義スニペットを使えば、rafceと打つだけでReactのコンポーネント雛形が出せたりします。なぜこれだけでは不十分なのでしょうか？
回答： スニペット機能は確かに便利であり、多くの開発現場で活用されています。しかし、従来のスニペットとAIによる生成には、決定的な「思考の差」が存在します。
質問： 思考の差、ですか？
回答： はい。従来のスニペットは、あくまで「穴埋め問題」です。テンプレートがあり、カーソル位置が指定され、エンジニアがそこに文字を埋めていく。これは「静的」なアプローチと言えます。
一方で、AI、特にLLM（大規模言語モデル）を用いたボイラープレート生成は、「文脈（コンテキスト）の理解」に基づいています。これが最大の違いです。
質問： 具体的に、開発フローの中でどう効いてくるのでしょうか。
回答： 例えば、新しいAPIエンドポイントを追加するシーンを想定してください。静的スニペットの場合、雛形を展開した後に、メソッド名、パス、リクエストの型定義などを一つひとつ手入力する必要があります。
しかしAIを活用する場合、プロンプト（指示）に「ユーザー情報の更新APIを追加したい」と伝えるだけで、あるいはファイル名や周囲のディレクトリ構造から意図を汲み取って、以下のような処理を瞬時に行います。
- ファイル名からクラス名や関数名を推論する
- 既存のプロジェクト構造から、適切なDTO（データ転送オブジェクト）のインポートパスを特定する
- チームで採用しているエラーハンドリングの共通処理を自動で挿入する
質問： なるほど。「何を書くか」という素材さえ渡せば、あるいは状況さえ整えれば、AIが「どう書くべきか」という作法に合わせて整形してくれるわけですね。
回答： その通りです。エンジニアにとって最も認知コストが高いのは、ビジネスロジックそのものではなく、「このプロジェクトではエラーハンドリングをどう書く決まりだったか」「共通コンポーネントのパスはどこか」といった、付随的なコンテキストの確認作業です。
静的スニペットは文字入力を減らしてくれますが、この「確認作業」までは減らしてくれません。AIプロンプトによる自動化は、この認知負荷を劇的に下げることができます。
「埋める」作業から「意図を伝える」作業へ
質問： 非常に面白い視点です。スニペットが「手作業の効率化」だとすれば、AIは「判断の支援」まで踏み込んでいると言えますね。
回答： ええ。実務の現場では、「コードを書くのではなく、意図をデザインする」という意識のシフトチェンジが重要になります。VSCode上でAIを使う際も、単に「コードを生成させる」のではなく、「こういう意図の機能を、プロジェクトのルールに従って実装せよ」と指示を出すことが求められます。
質問： そこで重要になるのが、やはり「プロンプト」の質ということになりますね。
Q2: 失敗するプロンプト、成功するプロンプトの分かれ道
質問： 多くのエンジニアがGitHub CopilotやChatGPTを使い始めていますが、「思った通りのコードが出ない」という声もよく聞きます。ボイラープレート生成において、失敗するプロンプトと成功するプロンプトの分かれ道はどこにあるのでしょうか？
回答： 最大の失敗要因は、「暗黙知への依存」です。
例えば、「単体テストを書いて」というプロンプトは避けるべき典型例です。AIのモデルがいかに進化し、高度な推論能力を持ったとしても、チームがJestを使っているのかVitestなのか、AAA（Arrange-Act-Assert）パターンを強制しているのか、モックの命名規則はどうなっているのかといった、プロジェクト固有のルールまでは知り得ません。
質問： 確かに。「よしなにやって」はAIには通用しない、あるいは「世間一般のよしなに」が適用されてしまい、チームの規約とズレてしまうわけですね。
回答： その通りです。その結果、AIが書いたコードを人間が手直しする時間が発生し、「これなら自分で書いた方が早い」という結論に至ってしまいます。
成功するプロンプトには、必ず「明文化された制約（Constraints）」が含まれています。
コーディング規約をプロンプトに落とし込む技術
質問： 具体的に、どのような情報をプロンプトに含めるべきなのでしょうか？
回答： 効果的なのは、以下の3要素をセットにした「構造化プロンプト」です。
- Role (役割定義): 「あなたはシニアバックエンドエンジニアです」
- Context (文脈): 「Next.jsのApp Routerを使用しており、Server Actionsで実装します」
- Constraints (制約条件): ここが最も重要です。
- 「変数名はキャメルケース」
- 「エラー時は必ずカスタム例外クラス
AppErrorを送出すること」 - 「Zodスキーマによるバリデーションを必須とする」
- 「JSDoc形式のコメントを付与すること」
質問： これらを毎回入力するのは大変そうですが。
回答： そこで、最新のAIコーディングツールの機能を活用します。
例えば、GitHub Copilotであれば @workspace コマンドを使用することで、開いているファイルだけでなくプロジェクト全体の構造をAIに認識させることが可能です。また、Copilot Edits（エージェント機能）を使えば、複数のファイルにまたがる変更や、プロジェクト固有の文脈を考慮したコード生成がより高精度に行えます。
さらに、プロジェクトルートに .github/copilot-instructions.md を配置して、チーム共通の指示を自動的に読み込ませるテクニックも有効です。最近では、MCP（Model Context Protocol） のような仕組みを活用し、外部のドキュメントやデータベースをAIのコンテキストとして直接連携させる動きも活発化しています。
質問： なるほど。手動で全てを説明しなくても、ツール側の機能で「文脈」を自動的に渡せるようになっているのですね。
回答： その通りです。加えて、「プロンプト自体をコードとして管理する」ことも推奨されます。チーム内で「ボイラープレート生成用プロンプト集」をMarkdownで用意し、Gitで管理します。エンジニアはそこからプロンプトをコピーし、必要な部分だけ書き換えてAIに指示を出します。
質問： プロンプトを「再利用可能な資産」として扱うわけですね。それならチーム内で出力のブレもなくなります。
回答： そうです。これは「PromptOps（プロンプト運用）」の第一歩と言えます。規約が変わればプロンプトも更新し、PR（プルリクエスト）を出してレビューする。コードと同じ運用フローに乗せることが、プロジェクトマネジメントの観点からも重要です。
Q3: チーム導入の壁：「AIに書かせる」ことへの心理的抵抗
質問： 技術的な手法はクリアになったとして、次に立ちはだかるのが「組織・人」の壁です。特にベテランエンジニアの中には、「AIにコードを書かせるなんて」という抵抗感を持つ人もいるのではないでしょうか？
回答： 一般的な傾向として、「自分で書いた方が理解が深まる」「AIのコードは信用できない」という意見は根強く存在します。これに対する論理的なアプローチは、「教育とレビューの質が変わる」というメリットを提示することです。
「自分で書いた方が早い」シンドロームの打破
質問： ベテラン層をどう説得するのですか？
回答： 「貴重な時間を、ボイラープレート記述という単純作業に使わないでほしい」という点を強調します。そして、「その代わり、AIが生成したコードのレビューと設計に時間を使ってほしい」と伝えます。
AIに規約通りのボイラープレートを出力させれば、インデントのズレや命名規則の些細なミスといった「低レイヤーの指摘」がコードレビューから減少します。その分、アーキテクチャの妥当性やビジネスロジックの正確性といった「本質的な議論」に時間を使えるようになります。
質問： レビュー工数の削減と質の向上。これはマネージャー層にも響くポイントですね。
ジュニアエンジニアの教育ツールとしての側面
質問： 一方で、経験の浅いジュニアエンジニアについてはどうでしょう？ 最初からAIに頼ると実力がつかないのでは、という懸念もあります。
回答： むしろ逆の効果が期待できます。優れたプロンプトから生成されるコードは、いわば「理想的な教科書」として機能します。
適切に整備された「規約遵守プロンプト」を使えば、ジュニアエンジニアでも最初から「チームの正解コード」を出力できます。「このプロジェクトではこのように例外処理を書くのが正解である」と、出力結果から体系的に学ぶことができます。
質問： なるほど。コピペ元の古いコードを探し回って、間違った書き方を真似してしまうリスクを排除できるわけですね。
回答： そうです。AIは「作業を省くための道具」ではなく、「正しい型を身につけるためのメンター」になり得ます。ただし、そのためには「なぜそのコードが出力されたのか」を理解させる指導は不可欠です。生成されたコードを一行ずつ説明させるようなレビュー会を設けるのも、実践的なアプローチとして効果的です。
Q4: VSCode環境における「持続可能な」自動化エコシステム
質問： 最後に、これらを継続的に運用していくためのエコシステム作りについてアドバイスをお願いします。VSCodeには様々なAI拡張機能がありますが、どう選定し、どう運用すべきでしょうか。
回答： ツールは日進月歩であるため特定の製品に固執すべきではありませんが、重要なのは「特定のベンダーにロックインされないプロンプト設計」です。
Copilot Chat、Cursor、Amazon Q Developerなど選択肢は多いですが、基本となる「コンテキスト」と「制約」の伝え方は共通しています。先ほど触れたように、プロンプト自体をMarkdownなどで管理しておけば、ツールが変わっても資産は無駄になりません。
拡張機能の選定基準とセキュリティ
質問： セキュリティ面での懸念もよく聞かれます。
回答： エンタープライズ導入であれば、学習データに利用されない設定（ゼロデータリテンションなど）が可能かどうかは必須要件です。その上で重視すべきポイントは、「ローカルコンテキストへのアクセス性」です。
開いているファイルだけでなく、ワークスペース全体の定義や、@workspace のように特定のディレクトリを明示的に参照できる機能を持つツールが望ましいです。ボイラープレート作成には、プロジェクト全体の構造理解が不可欠だからです。
プロンプトのバージョン管理と共有戦略
質問： 運用フローとして、明日から始められる具体的なアクションはありますか？
回答： まずは、チームで最も頻繁に発生するタスクを一つ選定します。例えば「新規機能のAPI実装」などです。そのタスクを的確にこなす「ゴールデンプロンプト」を一つ作成し、チームのWikiやリポジトリの docs/prompts ディレクトリに配置します。
そして、PRテンプレートに「AI生成を使用した場合は、使用したプロンプトと修正箇所を記載すること」という項目を追加するのも、実践的な試みです。
質問： プロンプト自体をレビュー対象にするのですね。それは斬新です。
回答： そうすることで、「この指示を加えると精度が上がる」という知見がチームに蓄積されます。ボイラープレート自動化は、一度作って終わりではなく、チームで継続的に育てていくプロセスそのものなのです。
編集後記：AIは「サボるための道具」から「規律を守るパートナー」へ
今回は、VSCodeとAIプロンプトを活用した開発プロセスの革新について解説しました。
重要なのは、AI活用を個人の「時短テクニック」としてではなく、チーム全体の「品質標準化戦略」として捉える視点です。
静的スニペットが「手の動き」を最適化するものだとすれば、AIプロンプトは「脳の動き（判断）」を支援するものです。チーム固有のルールや文脈をAIに理解させることで、誰が書いても均質で高品質なコードが生成される状態を作ること。これこそが、プロジェクトマネージャーやエンジニアリングマネージャーが目指すべきゴールと言えます。
今回の解説からの学びの総括：
- 脱・穴埋め作業: AIには単なるコード生成ではなく、ファイル名や構造から文脈を推論させる。
- プロンプトは資産: 曖昧な指示を排除し、制約条件を明文化したプロンプトをGitで管理する。
- 教育への転用: AIが出力する「正解コード」をジュニアエンジニアの教材として活用する。
- PromptOps: プロンプト自体をレビューし、改善し続けるサイクルを回す。
開発現場において、まずは「たった一つの頻出パターン」から、プロンプトの標準化を始めてみてはいかがでしょうか。それは技術的負債との戦いにおける強力な武器となり、プロジェクトのROI最大化に大きく貢献するはずです。
コメント