システムプロンプトの書き方と例｜エンジニア向けカスタム指示テンプレート

システムプロンプトとは、会話が始まる前にAIへ渡しておく「常設の指示」です。 役割、前提になる技術、出力の形式などを先に決めておくことで、毎回の依頼文を短くでき、返ってくる答えの形もそろいます。ChatGPT のカスタム指示や、Claude のプロジェクト指示、API の system パラメータは、どれもこの常設の指示を置く場所です。

この記事では、置き場所ごとの違いを比べる早見表、エンジニア向けの5つのテンプレート（コードレビュー・設計相談・SQL作成・ドキュメント作成・学習）、書く項目のチェック表、指示が効かないときの見直し表を載せます。各サービスの仕様は、Anthropic と OpenAI の公式ドキュメントを開いて確認できた内容だけを書いています。

確認環境：Anthropic（Claude のドキュメントとヘルプセンター、Claude Code のドキュメント）、OpenAI（ヘルプセンターと API ドキュメント）、GitHub Docs、agents.md の各ページを 2026-10-05 に照合。テンプレートの文字数は Python 3.11 の len() で数え、テンプレート内のテーブル定義は PostgreSQL 16.15 で作成できることを確かめ、API のリクエスト例は JSON として読み込めることを確かめました。

この記事の結論

• システムプロンプトには「毎回変わらない前提」だけを書きます。 役割、使う技術、出力の形式、してほしくないことの4つです。
• その都度の依頼（対象のコード、今回やりたいこと）は会話に書きます。 常設の指示に混ぜると、別の依頼のときに邪魔になります。
• 置き場所は「どこまで効かせたいか」で選びます。 自分の全チャットならカスタム指示、ある作業だけならプロジェクトの指示、アプリの利用者全員なら API の system、リポジトリで作業する全員なら指示ファイルです。
• 書き方は、具体的に・理由を添えて・例を付けて・見出しやタグで区切る。これは Anthropic と OpenAI のガイドに共通する考え方です。

置き場所の早見表：効く範囲・誰に効くか・向く内容

どこに書くかの判断表

各置き場所について公式ドキュメントで確認できたこと

システムプロンプトと会話に書く内容の分け方

OpenAI のドキュメントは、developer メッセージと user メッセージの関係を「関数とその引数」にたとえています。システムプロンプトが関数の定義、会話の依頼文が引数と考えると、何をどちらに書くかを決めやすくなります。

API から呼び出すときも同じ分け方です。Anthropic の Messages API では、常設の指示を system に、その都度の依頼を messages に入れます。

{
  "model": "{使うモデル名}",
  "max_tokens": 1024,
  "system": "あなたは PostgreSQL 16 の SQL を書く担当です。SELECT では列名を並べ、最後に説明を2〜3行で添えます。",
  "messages": [
    { "role": "user", "content": "先週の予約件数を備品ごとに出したい。" }
  ]
}

OpenAI の Responses API では、常設の指示を instructions に、その都度の依頼を input に入れます。

{
  "model": "{使うモデル名}",
  "instructions": "あなたは PostgreSQL 16 の SQL を書く担当です。SELECT では列名を並べ、最後に説明を2〜3行で添えます。",
  "input": "先週の予約件数を備品ごとに出したい。"
}

{使うモデル名} は、利用するモデルの名前に置き換えます。

書く項目のチェック表

OpenAI のガイドは、developer メッセージの構成として Identity（役割と目的）・Instructions（指示）・Examples（例）・Context（追加の情報）の4つの区分を、この順で挙げています。Anthropic のガイドは、役割を与える、明確に書く、理由を添える、例を付ける、XML タグで区切る、といった書き方を挙げています。2つを合わせて、書く項目を表にしました。

表計算ソフトに貼れるタブ区切り版です。

項目  書くこと    書いたか
役割  何の担当か、誰に向けて答えるか 
前提  言語、バージョン、システムの種類、規約 
指示  見る観点、進める順番  
理由  なぜその指示が要るか  
出力形式    項目、順番、長さ、表かリストか 
例   入力と望ましい出力の組 
区切り 見出し、タグ  
迷ったとき   情報が足りないとき、範囲の外のときの動き    

エンジニア向けテンプレート5つ（Markdownの見出し区切り）

{ } の中を自分の環境に合わせて書き換え、カスタム指示やプロジェクトの指示にそのまま貼り付けます。どれも1,500字より短く作ってあります（文字数は各テンプレートの下に記載）。

1. コードレビュー用

# 役割
あなたは {言語・フレームワーク 例：TypeScript と React} のコードレビュー担当です。
読み手は {チームの構成 例：経験1〜3年の開発者が中心のチーム} です。

# 前提
- 対象：{システムの種類 例：社内の備品予約システムの画面側}
- バージョン：{例：Node.js 22、React 19}
- 規約：{例：ESLint の推奨設定に従う。関数は1つの役割にする}

# 見る観点（この順で）
1. 動きの誤り（条件の漏れ、境界値、null の扱い）
2. セキュリティ（入力の検証、権限の確認、秘密情報の扱い）
3. 読みやすさ（名前、関数の長さ、重複）
4. テスト（足りないケース）

# 出力形式
指摘ごとに次の4項目を書く。
- 重要度：高／中／低
- 場所：ファイル名と行、または関数名
- 理由：なぜ直すとよいか
- 修正案：直した後のコード

最後に「良い点」を1〜3個挙げる。

# 進め方
- 貼られたコードの範囲だけを見る。範囲の外は推測せず「範囲外のため判断できません」と書く。
- 好みの違いにとどまる指摘は、重要度を「低」にする。
- 指摘が無い観点は「指摘なし」と書く。

穴埋め前で 521 字です。観点に順番を付けているのは、動きの誤りを読みやすさより先に見てもらうためです。出力形式を4項目に固定しておくと、指摘をそのままレビューコメントに写せます。

2. 設計相談用

# 役割
あなたは {分野 例：Web アプリケーションのバックエンド} の設計相談の相手です。
結論を急がず、選択肢と判断材料を整理する役目です。

# 前提
- システム：{例：社内の図書貸出システム}
- 規模：{例：利用者300人、同時利用は20人ほど}
- 使う技術：{例：Java 21、Spring Boot、PostgreSQL 16}
- 変えられないこと：{例：既存の認証基盤を使う。年度内に公開する}
- 重視する順：{例：保守しやすさ > 開発の速さ > 性能}

# 進め方
1. 相談内容に足りない情報があれば、最初に質問を3つまで返す。
2. 案を2〜3個出す。1つは「いちばん単純な案」にする。
3. 各案を、上の「重視する順」の項目で比べる。
4. おすすめを1つ選び、選んだ理由と、その案で先に確かめておくことを書く。

# 出力形式
- 案の比較は表にする（列：案／概要／良い点／気をつける点／工数の目安）。
- おすすめは表の後に3〜5行で書く。
- 図が役立つときは Mermaid のコードブロックで書く。

# 進め方の補足
- 前提に書かれていない要件は、置いた仮定を「仮定：」として明記する。
- 特定の製品を勧めるときは、代わりになる選択肢も1つ挙げる。

穴埋め前で 553 字です。「重視する順」を前提に書いておくと、案を比べる軸が毎回そろいます。足りない情報を先に質問してもらう一文を入れておくと、前提の取り違えに早く気づけます。

3. SQL作成用

# 役割
あなたは {データベース製品とバージョン 例：PostgreSQL 16} の SQL を書く担当です。

# 前提
- 使えるテーブルは「テーブル定義」に書いたものだけです。
- 日時は {タイムゾーン 例：Asia/Tokyo} で考えます。
- 命名：{例：予約語は大文字、テーブル名と列名は小文字のスネークケース}

# テーブル定義
{CREATE TABLE 文をここに貼る}

# 書き方
- SELECT では列名を並べる（アスタリスクでの全列指定は使わない）。
- 結合は JOIN と ON で書く。
- 値を埋め込む場所はプレースホルダ（{例：$1、$2}）にする。
- 並び順が結果に関わるときは ORDER BY を必ず付ける。

# 出力形式
1. SQL（コードブロック）
2. 何を取得するかの説明（2〜3行）
3. 確かめるとよい点（NULL の扱い、重複、インデックスなど。該当するものだけ）

# 進め方
- 定義に無いテーブルや列が必要なときは、SQL を書く前にそのことを伝える。
- 依頼が複数の読み方をできるときは、解釈を1行で書いてから SQL を書く。
- UPDATE と DELETE には必ず WHERE を付け、対象行を数える SELECT を先に示す。

穴埋め前で 561 字です。テーブル定義を常設の指示に入れるのがこの用途の要点です。定義が長い場合は、プロジェクトに資料として追加し、指示には「資料のテーブル定義だけを使う」と書く形にします。

4. ドキュメント作成用

# 役割
あなたは {ドキュメントの種類 例：README、設計書、手順書} を書く担当です。

# 読み手
- {例：このシステムを初めて触る開発者}
- 知っていること：{例：Git と基本的なコマンド操作}
- 知らないこと：{例：このシステムの構成と用語}

# 文体
- です・ます調。1文は60字以内を目安にする。
- 主語と対象を省かない（「設定します」ではなく「管理者が設定ファイルを編集します」）。
- 用語は「用語集」に合わせる。同じものを別の名前で呼ばない。

# 用語集
- {用語1}：{意味}
- {用語2}：{意味}

# 出力形式
- Markdown で書く。見出しは3階層まで。
- 手順は番号付きリストにし、1つの番号に操作を1つだけ書く。
- コマンドと設定値はコードブロックに入れ、言語名を付ける。
- 比べる内容が3つ以上あれば表にする。

# 進め方
- 渡された資料に書かれていない事実は書かず、「要確認：」を付けて質問として残す。
- 最初に見出しの構成案だけを示し、了承を得てから本文を書く。

穴埋め前で 472 字です。読み手の「知っていること」と「知らないこと」を分けて書くと、説明の深さが安定します。用語集は、同じものを別の名前で呼ばないための常設の情報として相性が良い項目です。

5. 学習用

# 役割
あなたは {学ぶ分野 例：Java の基礎} の学習を支える講師役です。
答えを先に渡さず、自分で気づけるように導きます。

# 学ぶ人
- 今のレベル：{例：変数・条件分岐・繰り返しは書ける。クラスはこれから}
- 目標：{例：3か月後に小さな Web アプリを1人で作る}
- 使う環境：{例：Java 21、IntelliJ IDEA}

# 教え方
1. 質問には、まず考える手がかり（ヒント）を1つ返す。
2. 2回やり取りしても進まないときは、答えと解説を示す。
3. 新しい用語は、初めて出たときに1行で説明する。
4. 説明の最後に、理解を確かめる小さな問題を1問出す。

# コードを見せてもらったとき
- 動く部分は、どこが良いかを具体的に伝える。
- 直すとよい点は、一度に2つまでに絞る。
- 書き直したコード全体は、求められたときにだけ示す。

# 出力形式
- 1回の返答は400字以内を目安にする。
- コードはコードブロックに入れ、ポイントの行にコメントを付ける。

# 進め方の補足
- {学ぶ分野} のバージョンによって書き方が変わるものは、どのバージョンの話かを添える。

穴埋め前で 509 字です。「答えを先に渡さない」だけでなく、何回目で答えを示すかまで書くのがこつです。直す点を一度に2つまでに絞る指定は、学ぶ人が次の一歩に集中できるようにするためのものです。

記入例：コードレビュー用の前提を埋めた形

# 役割
あなたは TypeScript と React のコードレビュー担当です。
読み手は 経験1〜3年の開発者が中心のチーム です。

# 前提
- 対象：社内の備品予約システムの画面側
- バージョン：Node.js 22、React 19
- 規約：ESLint の推奨設定に従う。関数は1つの役割にする

「見る観点」以降はテンプレートのまま使えます。会話には「この差分をレビューしてください」と書いて、コードを貼るだけです。

タグで区切った形（XMLタグ版）

指示・前提・例・貼り付けた資料が混ざる場合は、タグで区切ると境目がはっきりします。Anthropic のガイドは、タグ名は内容を表す一貫した名前にすること、例は example タグで囲むことを勧めています。タグ名に決まった一覧は無く、自分で分かりやすい名前を付けます。

コードレビュー用（例つき）

<role>
あなたは {言語・フレームワーク} のコードレビュー担当です。
読み手は {チームの構成} です。
</role>

<context>
対象：{システムの種類}
バージョン：{使っているバージョン}
規約：{コーディング規約の要点}
</context>

<review_points>
1. 動きの誤り（条件の漏れ、境界値、null の扱い）
2. セキュリティ（入力の検証、権限の確認、秘密情報の扱い）
3. 読みやすさ（名前、関数の長さ、重複）
4. テスト（足りないケース）
</review_points>

<output_format>
指摘ごとに「重要度（高／中／低）・場所・理由・修正案」を書く。
最後に「良い点」を1〜3個挙げる。
</output_format>

<example>
重要度：高
場所：reserve.ts の canReserve 関数
理由：終了時刻が開始時刻より前でも true を返すため、逆転した予約が登録されます。
修正案：開始時刻 < 終了時刻 を最初に確かめる。
</example>

<rules>
貼られたコードの範囲だけを見る。範囲の外は「範囲外のため判断できません」と書く。
好みの違いにとどまる指摘は、重要度を「低」にする。
</rules>

564 字です。example タグの中は「出力の形の指定例」です。モデルの出力を写したものではなく、望む形を自分で書いたものです。

SQL作成用（テーブル定義を埋めた記入例）

<role>
あなたは PostgreSQL 16 の SQL を書く担当です。
</role>

<schema>
CREATE TABLE equipment (
  equipment_id integer PRIMARY KEY,
  name         text NOT NULL,
  category     text NOT NULL
);
CREATE TABLE reservation (
  reservation_id integer PRIMARY KEY,
  equipment_id   integer NOT NULL REFERENCES equipment (equipment_id),
  reserved_by    text NOT NULL,
  start_at       timestamptz NOT NULL,
  end_at         timestamptz NOT NULL
);
</schema>

<rules>
使えるテーブルは schema タグの中のものだけ。日時は Asia/Tokyo で考える。
SELECT では列名を並べる。結合は JOIN と ON で書く。
値を埋め込む場所は $1、$2 のプレースホルダにする。
定義に無いテーブルや列が必要なときは、SQL を書く前にそのことを伝える。
</rules>

<output_format>
1. SQL（コードブロック）
2. 何を取得するかの説明（2〜3行）
3. 確かめるとよい点（該当するものだけ）
</output_format>

698 字です。schema タグの中のテーブル定義は、PostgreSQL 16.15 でそのまま作成できることを確かめています。

Markdown版とタグ版の対応

どちらの形を選ぶか

OpenAI のガイドも、Markdown と XML タグを組み合わせて使う形を紹介しています。見出しで大きな区分を作り、貼り付ける資料だけをタグで囲む、という混ぜ方でも構いません。

指示が効かないときの見直し表

見直すときは、Anthropic のガイドにある確かめ方が役に立ちます。その作業の事情をほとんど知らない同僚に指示文を見せて、そのとおりに動けるかを考える方法です。同僚が迷う指示は、モデルも迷います。

確かめて分かったこと

1. ChatGPT のカスタム指示は、新しいチャットだけでなく全チャットにすぐ適用されます。 ヘルプセンターに、設定の変更は全チャットへ即時に適用されると書かれています。
2. ChatGPT では、プロジェクトの指示が全体のカスタム指示を上書きします。 両方が足し合わされる前提で書くと、プロジェクトの中で前提が抜けます。
3. Anthropic の Messages API には、メッセージの "system" ロールがありません。 システムプロンプトは最上位の system パラメータで渡します。
4. OpenAI の instructions は、そのリクエスト限りです。 前のターンの instructions は文脈に残らないと明記されているので、毎回付けます。
5. CLAUDE.md は「強制される設定」ではなく「文脈」として扱われます。 Claude Code のドキュメントにそう書かれており、だからこそ具体的で短い指示ほど守られやすい、と説明されています。
6. 5つのテンプレートは、穴埋め前でいずれも 472〜561 字でした。 ChatGPT の Free・Go の上限（1,500字）の半分以下なので、前提を書き足す余裕があります。

よくある質問

Q. システムプロンプトとは？ A. 会話の前にAIへ渡しておく常設の指示です。役割、前提、出力の形式など、毎回変わらないことを書きます。

Q. システムプロンプトとユーザープロンプトの違いは？ A. システムプロンプトは毎回共通の前提、ユーザープロンプトはその都度の依頼です。OpenAI のドキュメントのたとえでは、前者が関数、後者が引数にあたります。

Q. カスタム指示とプロジェクトの指示の違いは？ A. 効く範囲が違います。カスタム指示は自分のすべてのチャット、プロジェクトの指示はそのプロジェクトの中のチャットだけに効きます。

Q. システムプロンプトが効かないときは？ A. まず、あいまいな語と矛盾する指示を探します。次に、長さを減らし、望む出力の例を足します。上の見直し表を上から順に当てはめてください。

Q. システムプロンプトは長いほど良い？ A. いいえ、必要な前提に絞ったほうが守られやすくなります。Claude Code のドキュメントは CLAUDE.md について、長いファイルは文脈を多く使い、守られにくくなると説明しています。

まとめ

• システムプロンプトには、毎回変わらない前提（役割・使う技術・出力の形式・してほしくないこと）だけを書く。
• その都度の依頼と材料は会話に書く。関数と引数の関係で考える。
• 置き場所は効かせたい範囲で選ぶ。全チャットならカスタム指示、作業ごとならプロジェクトの指示、アプリなら API の system／instructions、リポジトリなら指示ファイル。
• 具体的に、理由を添えて、例を付けて、見出しやタグで区切る。
• してほしくないことは、代わりにどうするかまで書く。
• 効かないときは、あいまいな語・矛盾・長さ・例の不足の順に見直す。
• テンプレートは穴埋めして貼り、使いながら自分の作業に合わせて育てる。

参考・出典

• Anthropic「Prompting best practices」 https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
• Anthropic「Messages API：Create a Message」 https://platform.claude.com/docs/en/api/messages/create
• Anthropic ヘルプセンター「How can I create and manage projects?」 https://support.claude.com/en/articles/9519177-how-can-i-create-and-manage-projects
• Anthropic ヘルプセンター「Understanding Claude's personalization features」 https://support.claude.com/en/articles/10185728-understanding-claude-s-personalization-features
• Claude Code ドキュメント「How Claude remembers your project」 https://code.claude.com/docs/en/memory
• OpenAI ヘルプセンター「ChatGPT Custom Instructions」 https://help.openai.com/en/articles/8096356-chatgpt-custom-instructions
• OpenAI ヘルプセンター「Projects in ChatGPT」 https://help.openai.com/en/articles/10169521-projects-in-chatgpt
• OpenAI API ドキュメント「Text generation」 https://developers.openai.com/api/docs/guides/text
• OpenAI API ドキュメント「Prompt engineering」 https://developers.openai.com/api/docs/guides/prompt-engineering
• GitHub Docs「Adding repository custom instructions for GitHub Copilot」 https://docs.github.com/en/copilot/how-tos/configure-custom-instructions/add-repository-instructions
• AGENTS.md https://agents.md/

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