プロンプトの書き方｜エンジニア向けテンプレート20個と型の一覧

プロンプトの書き方の基本は、「役割・背景・入力・条件・出力形式・例示」の6要素を、区切りをはっきりさせて書くことです。 何を頼むかだけでなく、何のために・何をもとに・どんな形で返してほしいかまで渡すと、返ってくる内容が安定します。

この記事では、6要素を1つの型にまとめ、XMLタグ区切り版とMarkdown見出し版の両方をコピペできる形で載せました。そのうえで、実装・バグ調査・リファクタリング・SQL・正規表現・ログ解析・命名・ドキュメント作成など、開発作業別のテンプレート20個を用意しています。Anthropic・OpenAI・Google の公式ガイドが勧める書き方も、項目別の対応表にしました。

確認環境：公式ガイド3つ（Anthropic「Prompting best practices」、OpenAI「Prompt engineering」、Google「Prompt design strategies」）は 2026年10月5日に閲覧。テンプレートの個数と、XMLタグの開きと閉じの対応は Python 3.11 で確認しています。この記事はテンプレート集で、モデルの出力例は載せていません。

プロンプトの6要素の早見表

タグの名前に決まりはありません。中身を表す名前を付け、1つのプロンプトの中で同じ名前を使い続けることが大切です。

6要素をまとめた型（コピペ用）

{{ }} の部分を書き換えて使います。使わない要素は、タグや見出しごと消してかまいません。

XMLタグ区切り版

<role>
あなたは {{専門分野}} に詳しい {{職種}} です。
</role>

<context>
{{何のための作業か。対象のシステム、読み手、使っている言語やライブラリの版}}
</context>

<input>
{{コード、仕様、エラー文、ログなど。貼り付ける資料}}
</input>

<conditions>
- {{守ること。使ってよいもの、変えない範囲}}
- {{分からないときの動き。例：推測で埋めずに質問として挙げる}}
</conditions>

<output_format>
{{出力の形。例：1. 要約（3行） 2. コード（1つのコードブロック） 3. 確認方法}}
</output_format>

<examples>
<example>
入力：{{入力の例}}
出力：{{その入力に対する理想の出力}}
</example>
</examples>

上の input について、conditions を守り、output_format の形で {{してほしいこと}} を行ってください。

Markdown見出し版

# 役割
あなたは {{専門分野}} に詳しい {{職種}} です。

# 背景
{{何のための作業か。対象のシステム、読み手、使っている言語やライブラリの版}}

# 入力
```
{{コード、仕様、エラー文、ログなど。貼り付ける資料}}
```

# 条件
- {{守ること。使ってよいもの、変えない範囲}}
- {{分からないときの動き。例：推測で埋めずに質問として挙げる}}

# 出力形式
{{出力の形。例：1. 要約（3行） 2. コード（1つのコードブロック） 3. 確認方法}}

# 例
入力：{{入力の例}}
出力：{{その入力に対する理想の出力}}

# 依頼
上の「入力」について、「条件」を守り、「出力形式」の形で {{してほしいこと}} を行ってください。

どちらの版を選ぶか

Google の公式ガイドは、XML形式のタグと Markdown の見出しのどちらも有効としたうえで、1つのプロンプトの中では形式を1つに決めて使い続けることを勧めています。迷ったら、資料を貼る量が多いときは XML、そうでなければ Markdown と決めておくと楽です。

型に当てはめた例

備品予約システムに関数を追加する依頼を、XMLタグ区切り版で書いた例です。

<role>
あなたは Python 3.11 に詳しいソフトウェアエンジニアです。
</role>

<context>
社内の備品予約システムに、予約時間の重なりを判定する関数を追加します。
外部ライブラリは使わず、標準ライブラリだけで書きます。
</context>

<input>
予約は (開始, 終了) の datetime の組で表す。
新しい予約1件と、既存の予約のリストを受け取り、重なる予約があれば True を返す。
終了時刻と次の開始時刻が同じ場合は、重なりとみなさない。
</input>

<conditions>
- 関数名は has_overlap、型ヒントを付ける
- 開始が終了より後の予約が渡されたら ValueError を送出する
- 仕様に書かれていない点は、推測で埋めずに質問として挙げる
</conditions>

<output_format>
1. 質問（無ければ「なし」）
2. 関数のコード（1つのコードブロック）
3. 呼び出し例と期待する戻り値（3つ）
</output_format>

<examples>
<example>
入力：新規 10:00〜11:00、既存 [11:00〜12:00]
出力：False
</example>
<example>
入力：新規 10:00〜11:00、既存 [10:30〜11:30]
出力：True
</example>
</examples>

上の input の仕様で、conditions を守り、output_format の形で関数を書いてください。

曖昧な指示を具体的な指示に直す比較表

「うまく伝わらない」と感じたときは、足りない要素を1つずつ足していきます。

最後から3つめの行は、Anthropic の公式ガイドにある考え方です。「〜しないで」と書くより、「〜の形で書いて」と、してほしいことを書くほうが伝わりやすいとされています。

公式ガイドが勧める書き方の対応表

3社の公式ガイドに書かれている内容を、項目別に並べました。表現は違っても、勧めていることはよく似ています。

「―」は、今回開いたページにその項目の記載が見当たらなかったことを表します。

OpenAI のガイドは、developer メッセージを Identity（役割）・Instructions（指示）・Examples（例）・Context（背景情報） の順に書く構成を紹介しています。この記事の6要素とは、次のように対応します。

開発作業別テンプレート20個

すべて XMLタグ区切り版で書いています。{{ }} を書き換え、末尾に「上の内容で、〜してください」と依頼の1文を足して使います。Markdown見出し版にしたいときは、タグを見出しに置き換えるだけです。

コードレビューを頼むプロンプトは、観点ごとに分けて書くと扱いやすいため、ここには含めていません。

1. 実装：仕様から新しい関数を書く

<role>
あなたは {{言語とバージョン}} に詳しいソフトウェアエンジニアです。
</role>

<context>
{{システム名。例：社内の備品予約システム}} に、{{追加したい機能}} を追加します。
使用ライブラリ：{{ライブラリと版}}
</context>

<spec>
{{関数の仕様：入力、出力、エラー時の動き}}
</spec>

<conditions>
- 標準ライブラリと、context に書いたライブラリだけを使う
- 入力が空・上限超え・型違いのときの動きを仕様どおりに実装する
- 仕様に書かれていない点は、推測で埋めずに質問として挙げる
</conditions>

<output_format>
1. 質問（あれば。無ければ「なし」）
2. 関数のコード（1つのコードブロック）
3. 使い方の例（呼び出しと期待する戻り値を3つ）
</output_format>

2. 実装：既存コードに機能を追加する

<role>
あなたはこのリポジトリの開発メンバーです。既存の書き方に合わせて変更します。
</role>

<context>
追加したい機能：{{機能}}
変更してよい範囲：{{ファイルやディレクトリ}}
</context>

<existing_code>
{{関係する既存コード}}
</existing_code>

<conventions>
{{命名・エラー処理・ログの規約}}
</conventions>

<conditions>
- 既存の関数の引数と戻り値は変えない
- conventions の規約と、既存コードの書き方に合わせる
- 変更は機能追加に必要な最小限にする
</conditions>

<output_format>
1. 変更の方針（3行以内）
2. 変更後のコード（ファイルごとにコードブロック）
3. 既存の動きに影響する可能性がある点（箇条書き）
</output_format>

3. バグ調査：エラー文から原因の候補を出す

<role>
あなたは {{言語・フレームワーク}} の不具合調査に慣れたエンジニアです。
</role>

<context>
{{いつから・どの操作で}} エラーが出ます。直前の変更：{{変更内容。無ければ「なし」}}
</context>

<error>
{{エラー文とスタックトレース全文}}
</error>

<code>
{{エラーが出た箇所の前後のコード}}
</code>

<conditions>
- 原因は確度の高い順に最大3つ挙げる
- それぞれ、error と code のどの部分が根拠かを引用する
- 確かめるための手順（コマンドやログ出力）を付ける
</conditions>

<output_format>
| 順位 | 原因の候補 | 根拠（引用） | 確かめ方 | 直し方 |
の表で出力する。
</output_format>

4. バグ調査：再現条件を切り分ける

<role>
あなたは不具合の切り分けを進めるエンジニアです。
</role>

<context>
{{現象}} が、起きるときと起きないときがあります。
</context>

<works>
{{正常に動く条件（入力・環境・手順）}}
</works>

<breaks>
{{現象が起きる条件（入力・環境・手順）}}
</breaks>

<conditions>
- works と breaks の差分を列挙する
- 差分ごとに、原因かどうかを1回で判定できる実験を提案する
- 実験は手間の小さい順に並べる
</conditions>

<output_format>
1. 差分の一覧（表：項目 / 正常時 / 現象が起きる時）
2. 実験の一覧（番号つき。期待する結果も書く）
</output_format>

5. リファクタリング：動きを変えずに整理する

<role>
あなたは保守しやすいコードを書くエンジニアです。
</role>

<context>
目的：{{読みやすくする／重複をなくす／関数を分ける など}}
テストの有無：{{あり・なし}}
</context>

<code>
{{対象のコード}}
</code>

<conditions>
- 外から見た動き（引数、戻り値、例外、ログ）は変えない
- 1回の提案で扱う変更は1種類にする
- 言語のバージョンは {{バージョン}} で使える書き方に限る
</conditions>

<output_format>
1. 変更点の要約（箇条書き）
2. 変更後のコード
3. 動きが変わっていないことを確かめるテストの例
</output_format>

6. コード読解：処理の流れを説明させる

<role>
あなたは新しく参加したメンバーにコードを説明する先輩エンジニアです。
</role>

<context>
読み手：{{言語の経験。例：Java は書けるが、このフレームワークは初めて}}
</context>

<code>
{{説明してほしいコード}}
</code>

<conditions>
- コードに書かれていることだけを説明し、書かれていない仕様は推測と明記する
- 専門用語は初出で1行の説明を付ける
</conditions>

<output_format>
1. 全体の役割（2〜3文）
2. 処理の流れ（番号つき、各ステップに行番号）
3. 読むときに気をつける点（最大3つ）
</output_format>

7. テスト：単体テストのコードを書く

<role>
あなたは {{テストフレームワークと版}} でテストを書くエンジニアです。
</role>

<context>
対象：{{関数やクラスの名前}}。外部への通信やDBは {{モックにする／実物を使う}}。
</context>

<code>
{{テスト対象のコード}}
</code>

<test_example>
{{既存のテストの書き方の例}}
</test_example>

<conditions>
- test_example の命名と構成に合わせる
- 正常系、境界値、エラー系を分けて書く
- 1つのテストで確かめることは1つにする
</conditions>

<output_format>
1. テストケースの一覧（表：ケース名 / 入力 / 期待する結果）
2. テストコード（1つのコードブロック）
</output_format>

8. テスト：テストケースを洗い出す

<role>
あなたはテスト設計を担当するエンジニアです。
</role>

<context>
対象の機能：{{機能。例：図書貸出システムの貸出延長}}
</context>

<spec>
{{仕様（入力項目、上限・下限、状態の種類）}}
</spec>

<conditions>
- 同値分割と境界値分析で洗い出す
- 仕様から読み取れない期待結果は「要確認」と書く
- 優先度（高・中・低）を付ける
</conditions>

<output_format>
| No | 観点 | 入力・前提 | 期待する結果 | 優先度 |
の表で出力する。
</output_format>

9. SQL：やりたい集計からクエリを書く

<role>
あなたは {{DB製品とバージョン。例：PostgreSQL 16}} に詳しいエンジニアです。
</role>

<context>
{{知りたいこと。例：部署ごとの今月の予約件数を、多い順に}}
</context>

<schema>
{{CREATE TABLE 文。主キー・外部キー・インデックスも含める}}
</schema>

<sample_rows>
{{各テーブルのデータ例を数行}}
</sample_rows>

<conditions>
- schema にあるテーブルと列だけを使う
- NULL と重複の扱いを明示する
- {{DB製品}} で動く構文に限る
</conditions>

<output_format>
1. SQL（1つのコードブロック）
2. sample_rows に対して返る結果の表
3. 前提にしたこと（箇条書き）
</output_format>

10. SQL：時間のかかるクエリを見直す

<role>
あなたは {{DB製品とバージョン}} のクエリを見直すエンジニアです。
</role>

<context>
このクエリは {{件数}} 件のテーブルで {{秒数}} 秒かかります。目標は {{秒数}} 秒です。
</context>

<query>
{{対象のSQL}}
</query>

<plan>
{{実行計画（EXPLAIN の出力）}}
</plan>

<schema>
{{テーブル定義とインデックス}}
</schema>

<conditions>
- plan のどの行が時間を使っているかを引用して示す
- 結果が変わらない書き換えだけを提案する
- インデックスを追加する案は、書き込みへの影響も書く
</conditions>

<output_format>
| 案 | 変更内容 | 根拠（plan の引用） | 期待できる効果 | 注意点 |
の表のあとに、書き換えたSQLを出力する。
</output_format>

11. 正規表現：条件から式を作る

<role>
あなたは正規表現に詳しいエンジニアです。
</role>

<context>
使う場所：{{言語やツール。例：Python 3.11 の re}}
</context>

<match>
{{一致させたい文字列の例（1行に1つ）}}
</match>

<no_match>
{{一致させたくない文字列の例（1行に1つ）}}
</no_match>

<conditions>
- match はすべて一致し、no_match はすべて一致しない式にする
- {{言語やツール}} で使える記法に限る
- 全角・半角、大文字・小文字の扱いを明示する
</conditions>

<output_format>
1. 正規表現（1行）
2. 式の読み方（部分ごとの表）
3. match と no_match の各行の判定結果の表
</output_format>

12. ログ解析：大量のログから要点を拾う

<role>
あなたはアプリケーションの運用を担当するエンジニアです。
</role>

<context>
{{時刻}} ごろに {{現象}} が起きました。原因の手がかりを探しています。
</context>

<log>
{{ログ。時刻つき}}
</log>

<conditions>
- エラー・警告を種類ごとにまとめ、件数と最初の時刻を出す
- 現象の直前に初めて現れた行を挙げる
- ログに無いことは書かない。判断できない点は「ログからは不明」と書く
</conditions>

<output_format>
1. 時系列のまとめ（表：時刻 / 出来事 / 該当行の引用）
2. 種類ごとの件数（表）
3. 次に見るとよいログや設定（最大3つ）
</output_format>

13. 命名：変数・関数・クラスの名前を考える

<role>
あなたは読みやすい名前を付けることを大切にするエンジニアです。
</role>

<context>
言語：{{言語}}。命名規約：{{例：関数は camelCase、定数は UPPER_SNAKE_CASE}}
</context>

<target>
{{名前を付けたいものの説明。役割、引数、戻り値}}
</target>

<conditions>
- 候補は5つ出す
- 既存の名前（{{既存の名前の例}}）と語の選び方をそろえる
- 省略語は一般的なものだけにする
</conditions>

<output_format>
| 候補 | 意味 | 向いている場合 |
の表のあとに、おすすめを1つと理由を1文で書く。
</output_format>

<example>
入力：予約の開始時刻が今より前かどうかを返す関数
出力の1行：| isStartTimePassed | 開始時刻を過ぎたか | 真偽値を返す関数 |
</example>

14. コメント：関数の説明コメントを書く

<role>
あなたは {{言語}} のドキュメントコメント（{{形式。例：Javadoc、docstring、JSDoc}}）を書くエンジニアです。
</role>

<context>
読み手：この関数を呼び出す側の開発者
</context>

<code>
{{対象の関数}}
</code>

<conditions>
- コードから読み取れる事実だけを書く
- 「何をしているか」の言い換えではなく、引数の条件・戻り値・例外・副作用を書く
- コード本体は変更しない
</conditions>

<output_format>
コメントを付けたコード全体を、1つのコードブロックで出力する。
</output_format>

15. ドキュメント：READMEを書く

<role>
あなたは開発者向けのドキュメントを書くテクニカルライターです。
</role>

<context>
読み手：{{このリポジトリを初めて触る開発者}}
</context>

<repo_info>
{{ディレクトリ構成、セットアップのコマンド、起動方法、テストのコマンド}}
</repo_info>

<conditions>
- repo_info に書かれた情報だけを使う。足りない項目は「TODO：」として残す
- コマンドはコピーできるコードブロックにする
- 1文を短くする
</conditions>

<output_format>
Markdown で、次の見出しの順に出力する。
# プロジェクト名 / ## 概要 / ## 必要なもの / ## セットアップ / ## 起動 / ## テスト / ## ディレクトリ構成
</output_format>

16. ドキュメント：コミットメッセージとPRの説明を書く

<role>
あなたは変更内容をレビュアーに伝える開発者です。
</role>

<context>
コミットメッセージの規約：{{例：1行目は50字以内、種別: 要約 の形}}
</context>

<diff>
{{git diff の出力}}
</diff>

<background>
{{変更の理由。関連するチケット番号}}
</background>

<conditions>
- diff に含まれる変更だけを書く
- 「何を」より「なぜ」を先に書く
- レビュアーに特に見てほしい点を挙げる
</conditions>

<output_format>
1. コミットメッセージ（コードブロック）
2. PRの説明（Markdown：## 背景 / ## 変更内容 / ## 確認方法 / ## 見てほしい点）
</output_format>

17. 設計：複数の案を比べる

<role>
あなたはソフトウェア設計の相談相手です。
</role>

<context>
決めたいこと：{{例：予約の重複チェックを、アプリ側とDB側のどちらで行うか}}
前提：{{利用者数、データ量、チームの経験}}
</context>

<requirements>
{{機能の要件と、性能・運用の要件}}
</requirements>

<conditions>
- 案は3つまで。それぞれの長所と注意点を同じ観点で比べる
- おすすめを1つ選び、選んだ理由と、選ばなかった案が向く条件を書く
- 前提が足りない場合は、先に質問を挙げる
</conditions>

<output_format>
1. 質問（あれば）
2. 比較表（観点：実装の手間 / 性能 / 運用 / 変更のしやすさ）
3. おすすめと理由
</output_format>

18. 設計：APIのエンドポイント案を作る

<role>
あなたは REST API を設計するエンジニアです。
</role>

<context>
対象：{{機能。例：勤怠入力の打刻の登録・修正・一覧}}
既存の規約：{{パスの命名、エラー形式、認証方式}}
</context>

<use_cases>
{{利用者ができること（箇条書き）}}
</use_cases>

<conditions>
- 既存の規約に合わせる
- use_cases の各項目が、どのエンドポイントで満たされるかを対応させる
- エラー時のステータスコードとレスポンスも決める
</conditions>

<output_format>
1. 一覧表（メソッド / パス / 概要 / 対応する use_case）
2. 各エンドポイントのリクエストとレスポンスの JSON 例
</output_format>

19. 移行：別の言語・バージョンに書き換える

<role>
あなたは {{移行元}} と {{移行先}} の両方に詳しいエンジニアです。
</role>

<context>
{{移行元の言語・版}} のコードを {{移行先の言語・版}} に書き換えます。
</context>

<code>
{{移行元のコード}}
</code>

<conditions>
- 動きは変えない
- 移行先の標準的な書き方に合わせる（移行元の書き方をそのまま写さない）
- 同じ動きにならない箇所（数値の丸め、文字コード、日付、例外）は必ず挙げる
</conditions>

<output_format>
1. 書き換えたコード
2. 対応表（移行元の書き方 / 移行先の書き方 / 動きの違い）
3. 動作を確かめるための入力と期待する出力
</output_format>

20. コマンド：シェルスクリプトやワンライナーを書く

<role>
あなたは {{シェルとOS。例：Ubuntu 24.04 の bash}} に詳しいエンジニアです。
</role>

<context>
やりたいこと：{{例：logs ディレクトリの30日より前の .log を圧縮する}}
</context>

<environment>
{{使えるコマンド、対象のディレクトリ構成の例}}
</environment>

<conditions>
- environment に書いたコマンドだけを使う
- ファイルを消す・上書きする処理には、先に対象を一覧表示する確認用のコマンドを付ける
- スペースを含むファイル名でも動くようにする
</conditions>

<output_format>
1. 確認用のコマンド（変更を行わない）
2. 本番用のコマンドまたはスクリプト
3. 各オプションの意味（表）
</output_format>

テンプレートを自分用に育てるコツ

よくある質問

Q. 6要素は毎回すべて書く必要がありますか？ A. いいえ。短い質問なら、入力と出力形式だけで十分なこともあります。期待と違う答えが返ってきたときに、足りない要素を足していく使い方がおすすめです。

Q. XMLタグの名前は決まっていますか？ A. 決まった名前はありません。Anthropic の公式ガイドは、中身を表す名前を付けて一貫して使うこと、階層があるものは入れ子にすることを勧めています。この記事のタグ名も、そのまま使っても、自分の言葉に変えてもかまいません。

Q. 役割（あなたは〜です）は本当に必要ですか？ A. 必須ではありませんが、短い1文でも応答の視点や口調がそろいやすくなります。API で使う場合は、Anthropic はシステムプロンプト、OpenAI は developer メッセージ、Google はシステム指示に書く方法を案内しています。

Q. 例はいくつ入れるとよいですか？ A. Anthropic のガイドは3〜5個を目安にしています。Google のガイドは、数個の例でパターンをつかめることが多いとしつつ、数は試して調整することを勧めています。まず2〜3個から始め、出力のばらつきを見て増やすとよいでしょう。

まとめ

• プロンプトは「役割・背景・入力・条件・出力形式・例示」の6要素で組み立てる
• 区切りは XMLタグか Markdown見出し。資料を多く貼るなら XML、短い依頼なら Markdown。1つのプロンプトの中では片方に統一する
• 曖昧な指示は、足りない要素を1つずつ足して直す。「〜しないで」は「〜の形で」に書き換える
• 長い資料は上、依頼は最後に置く。Anthropic と Google の公式ガイドが共通して勧めている
• 例示は2つ以上、型の違うものを。書式は例どうしでそろえる
• 開発作業別のテンプレート20個は、背景と入力を差し替えるだけで使える
• 分からない点は推測で埋めず質問させる条件を入れておくと、確認の手戻りが減る

参考・出典

• Anthropic「Prompting best practices」 https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
• OpenAI「Prompt engineering」 https://developers.openai.com/api/docs/guides/prompt-engineering
• Google「Prompt design strategies」 https://ai.google.dev/gemini-api/docs/prompting-strategies

株式会社RJC ― SI事業・SES事業・AI駆動開発。RJCは一緒に成長を楽しめる会社です。