🪄

IDE連携AIを活かすためのプロンプトテンプレート設計

に公開
IDE
Cursor
Claude
Gemini
Kiro
idea

導入

今の時代、AIを搭載したIDEを全く使っていないエンジニアはほとんどいないのではないでしょうか。
例えば Cursor や VSCode、最近では Amazon が発表した Kiro など、さまざまなツールがあります。エンジニアであれば、こうした AI 搭載 IDE を日常的に使っていると思います。
ただし「良いプロンプトさえあれば、誰でも良いアプリを作れる」という話を聞いたことがあると思います。しかし実際には、「良いプロンプト」とは何か？ と考えたことはないでしょうか。
例えば、同じ依頼をしているのに毎回出力結果が微妙に違うと感じることがあります。Cursorでコードのリファクタリングを頼んだときや、レポート生成を行ったときに「前はうまくいったのに今回は予想外の結果が出た」「なぜか動いていたコードが消された」といった経験をした方も多いでしょう。
その原因の多くは、プロンプト設計が行き当たりばったりになっていることにあります。
AIを安定して動かすには、様々な要素を意識した「プロンプトテンプレート」が欠かせません。
本記事では、AIを搭載したIDEを最大限に活かすためのプロンプトテンプレートの作り方と考え方を、私自身の経験を踏まえて解説します。もしさらに良い使い方をご存じであれば、ぜひご指摘いただけると嬉しいです。

プロンプト設計の重要性

プロンプトを設計せずにAIに依頼すると、出力が毎回安定せず、思わぬトラブルが発生することがあります。
具体的には次のようなケースです。

  • 出力が不安定
    同じ依頼をしているのに、結果が毎回違う
  • コーディング規約の崩れ
    例：元々snake_caseで関数を定義していたのに、突然PascalCaseに変更されてしまう。
  • 修正範囲の暴走
    「この1ファイルだけを修正してほしい」と依頼したのに、関連ファイルまで一斉にリファクタリングされてしまう。
  • 不要な削除
    本来残してほしいモックデータや既存のコードを勝手に削除してしまう。

こうした問題の多くは、AIの性能の限界ではなく、プロンプト設計が曖昧であることに原因があります。
AIは「指示が明確であれば正確に動く」一方で、指示が不十分だと余計な判断をしてしまうのです。
そのため、開発でAIを安定して活用するには、プロンプトを設計＝ルール化することが欠かせません。
役割・範囲・制約をきちんと与えることで、出力の再現性を高め、不要なトラブルを防ぐことができます。

プロンプト設計の基本構造

1. Role（役割）
2. Scope of Work（仕事範囲）
3. Operating Rules（操作ルール）
4. Project Structure Awareness（プロジェクト理解）
5. File Modification Restrictions（ファイル修正制限）
    5.1 Preserve Original Design（基本設計やロジックを保留）
    5.2 Respect Existing Mock Data（モックデータを保留）
6. Solution First, Then Code（考えからコーディング）
    6.1 Reason for proposing this solution（なぜこのプランを提示したのか？）
    6.2 Pros（いい点）
    6.3 Cons（影響点）
    6.4 Impacted modules or logic（影響されるモジュールやロジック）
    6.5 List of Files expected to be modified（影響されるファイル）
7. Dependency Management（パッケージ管理）
8. Testing & Validation（テストやバーリデーション）
9. Vesion Conflict Resolution（バージョンのコンフリクト解決）
10. Langugae Handling（言語制限、例：日本語入力→日本語出力）
11. Final Rule（最終ルール：絶対ルールを違反しないこと）

設計プロセス解説

1.Role（役割）

  • AIに専門性を与えることで、回答の方向性と安定性を確保する。
  • 例：「あなたはプロのフルスタックエンジニアです」と指定するだけで、回答がエンジニア視点に統一されやすくなる。

2.Scope of Work（仕事範囲）

  • AIに「どこまでやるか」を明示する。範囲を限定しないと、余計な修正や過剰なリファクタリングが発生する。
  • 例：この修正はsrc/app/page.tsxのみ対象とする。他のファイルは一切変更しないこと。

3.Operating Rules（操作ルール）

  • 出力の形式やルールを指定することで、扱いやすい成果物を得る。
  • 例：関数定義はsnake_caseに指定すること。新規ファイル作成はPascalCaseに指定すること

4.Project Structure Awareness（プロジェクト理解）

  • プロジェクトのディレクトリ構造や責務分割をAIに認識させること。提案する前に、全体的なプロジェクトを理解した上でまたアイディアを提示すること。これがないと「新しいファイルを勝手に追加」したり「責務混在」するリスクがある
  • 例：
    1.ユーザーの問題を回答する前にまずはプロジェクトのフォルダやファイルを理解してください.
2.もし理解ができないフォルダやファイルがあればまずはユーザーに確認してください.
3.勝手に仮説をしないこと.

5.File Modification Restrictions（ファイル修正制限）

  • 不要な修正や削除を防ぐ。元の設計思想やロジックは保持する
  • 例：
    禁止事項：
1.構造の切り替え（MVCからDDDに変更）
2.モジュールの切り替え
などなど

6.Solution First, Then Code（考えからコーディング）

  • いきなりコードを書かせず、意図を明確させること。
  • 例：
    まず以下を説明してください：
1. 改善理由
2. メリットとデメリット
3. 影響範囲（モジュールやロジック）
4. 修正対象ファイル一覧

7.Dependency Management（パッケージ管理）

  • 不要なライブラリーや互換性崩壊を防ぐ。
  • 例：「新規パッケージを導入する場合は必ず理由を説明し、既存の依存関係と互換性を確認すること」

8.Testing&Validation（テストやバリデーション）

  • 出力コードの正しさを担保する。
  • 例：「修正後のコードと、それを検証するためのユニットテストを提示してください」

9.Version Conflict Resolution（バージョンコンフリクト解決）

  • 複数の依存関係やバージョン違いによる不具合を避ける。
  • 例：「もし依存関係のバージョンに差異がある場合は、統一方法を提案してください」

10.Language Handling（言語制限）

  • 入出力言語を揃えて誤解を防ぐ。たまに、GeminiやClaudeなどのモデルが入力は日本語なのに、英語に出力されることもある。
  • 例：「入力が日本語であれば、必ず日本語で回答してください。」

11.Final Rule（最終ルール）

  • 必ず以上のルールを守ること。ユーザーの指示必ず従うこと。

実践例

  • 与えたプロンプト：Pythonで簡単なゲームを作りたいですけど、どうすればいいのか？

Before（設計なしのプロンプト）

  • 勝手にrequirements.txtに変更される。
  • いきなりコードを書くこと

After（設計ありのプロンプト）

  • いくつかの提案をすること
  • メリット、デメリット、影響範囲、修正する予定ファイル

わかりやすく見ると

項目 Before（設計なし） After（設計あり）
出力の安定性 バラバラ 再現性あり
修正範囲 勝手に修正 指定ファイルのみ
説明 なし 理由付きで提示

まとめ

  • 最後に、本記事では、AIを搭載したIDEでプロンプトを効果的に活用するための「設計」の考え方について解説しました。設計を行わないと、出力が安定せず、意図しない修正や命名規則の乱れなどのトラブルが発生します。一方で、Role・Scope・制約条件・Solution First などの要素を意識してプロンプトを設計すれば、再現性と安定性の高い結果を得ることができます。プロンプト設計は単なる命令ではなく、AIとの対話を設計する行為です。人に仕様書を渡すように、AIにもルールや範囲を明示することが成功の鍵になります。ぜひ、普段使っているプロンプトの一つをテンプレート化して試してみてください。小さな工夫の積み重ねが、AIを「ただの便利ツール」から「信頼できるチームメンバー」に変えてくれるはずです。

Discussion