【ガイド 第4回】指示プロンプトとロールプロンプト：明確なタスクと適切なペルソナの与え方

Prompt Engineering ガイド 第4回（全10回）。この回は 第3回：プロンプトの構造：5 つの構成要素 の内容を前提にしています。初めての方は 第1回：プロンプトエンジニアリングとは何か、なぜ重要か からどうぞ。

AI の回答にがっかりする原因の多くは、モデルではなく指示にあります。読み手、長さ、形式、情報が足りないときの扱いがプロンプトに書かれていないため、モデルが推測で穴を埋めてしまうのです。その穴をふさぐのが指示プロンプト（instruction prompting）とロールプロンプト（role prompting）で、この 2 つで日常的なプロンプトの大半をカバーできます。

指示は「何をするか」を、ロールは「誰が、誰に向けて話すか」を伝えます。この記事では両方の書き方を、ChatGPT・Claude・Gemini にそのまま貼り付けて使える例文とともに解説します。また、多くの解説が触れない限界も扱います。ロールは回答の「口調」を変えますが、回答の「正しさ」を確実に高めるわけではありません。

指示プロンプトとは

指示プロンプトとは、タスクの例でモデルを学習させる代わりに、タスクを普通の言葉で説明する方法です。これが機能するのは、現在のチャットモデルが指示チューニング（instruction tuning）されているからです。Google の FLAN 論文（Wei ら、2021）は、指示の形で書かれた多数のタスクでモデルをファインチューニングすると、学習時に見たことのない種類のタスクでもゼロショット性能が上がることを示しました。OpenAI の InstructGPT（Ouyang ら、2022）はさらに人間のフィードバックを加え、評価者は 1.3B パラメータの InstructGPT の出力を 175B の GPT-3 より好みました。

実務上の意味はこうです。顧客リストの整形のように誰もモデルに教えていない作業でも、指示が正確であればこなせます。以下の 3 つの例文は、まさにそうした作業です。

例文 1：表記ゆれのあるデータを正規化する

データ整形は指示プロンプトの代表的な用途です。ルール 1〜3 に注目してください。推測する代わりに「わからない」と言える逃げ道をモデルに与えています。三重引用符の間に自分のデータを貼り付けてください。

以下の顧客レコードを、次の形式に正規化してください。1 件につき 1 行で出力します。
姓　名 | YYYY-MM-DD | 都道府県 市区町村

ルール：
1. 氏名：姓、名の順にし、間に全角スペースを 1 つ入れる。どちらが姓か判断できない場合は入力の順のまま残し、行末に「（要確認）」を付ける。
2. 日付：西暦の YYYY-MM-DD に変換する。和暦（昭和・平成・令和、略記の S・H・R を含む）も西暦に直す。年が 2 桁しかないなど年を特定できない場合は推測せず「????-??-??」と書き、「（要確認）」を付ける。
3. 住所：都道府県と市区町村だけを残す。都道府県が書かれていない場合は推測せず「？」と書く。

レコード：
"""
山田太郎 / H2.3.4生 / 大阪府大阪市北区梅田1-2-3
佐藤　花子、1988年1月15日、神奈川県横浜市
グエン・ヴァン・アン | 1992/11/30 | 東京都新宿区
鈴木 一郎, 85-12-25, 札幌市中央区
"""

山田　太郎 | 1990-03-04 | 大阪府 大阪市北区
佐藤　花子 | 1988-01-15 | 神奈川県 横浜市
グエン・ヴァン・アン | 1992-11-30 | 東京都 新宿区（要確認）
鈴木　一郎 | ????-??-?? | ？ 札幌市中央区（要確認）

平成 2 年は 1990 年に変換され、特定できない年と書かれていない都道府県は推測されずに「要確認」として残りました。こうしたルールがなければ、多くのモデルは黙ってどれかの解釈を選びます。

例文 2：個人情報をマスキングする

種類名と番号の付いたプレースホルダーを指定すると、マスキング後の文章も読みやすく保てます。最後に件数を出させれば、結果をすばやく確認できます。

以下の問い合わせ文に含まれる個人情報を、種類を表す角括弧付きのプレースホルダーに置き換えてください：[氏名]、[メール]、[電話番号]、[住所]、[契約番号]、[カード番号]。同じ種類が複数ある場合は [氏名_1]、[氏名_2] のように番号を付けます。
それ以外の部分は、誤字も含めて一字一句そのまま残してください。
問い合わせ文の後に、使ったプレースホルダーとそれぞれの出現回数を一覧にしてください。

問い合わせ文：
"""
お世話になっております。株式会社サンプルの高橋美咲です（[email protected]）。
同じ部署の中村健太もログインできません。契約番号は ACC-482913、請求先は東京都千代田区丸の内9-9-9です。
折り返しは 090-0000-1234 までお願いします。カード番号の下4桁は 4417 です。
"""

お世話になっております。株式会社サンプルの[氏名_1]です（[メール]）。
同じ部署の[氏名_2]もログインできません。契約番号は [契約番号]、請求先は[住所]です。
折り返しは [電話番号] までお願いします。カード番号の下4桁は [カード番号] です。

使用したプレースホルダー：
[氏名_1] 1回、[氏名_2] 1回、[メール] 1回、[契約番号] 1回、[住所] 1回、[電話番号] 1回、[カード番号] 1回

注意：LLM によるマスキングはあくまで一次処理です。文中に埋もれた ID や一般名詞と同じ名前など、珍しい形式は見落とされます。また、個人情報をそのまま外部のチャットボットに貼り付けること自体がデータの第三者提供にあたり、社内規程で禁止されている場合があります。本番の処理では Microsoft Presidio のような専用ツールと人によるチェックを組み合わせてください。

例文 3：評価基準（ルーブリック）で採点する

評価基準・採点の尺度・根拠の示し方をすべて指定すると、評価は安定します。「理由」の列を「点数」の列より前に置くと、モデルは点数を決める前に根拠を書くことになります。

あなたは、送信前のカスタマーサポートの返信文をレビューしています。
以下の各基準について 1（悪い）〜 5（非常に良い）で採点し、返信文を引用した一文の理由を添えてください。

基準：
- 正確さ：お客様の実際の質問に答えているか。
- 口調：丁寧で落ち着いており、お客様を責めていないか。
- 次の行動：お客様が次に何をすればよいか明確か。
- 長さ：200 字以内か。

「基準 | 理由 | 点数」の列を持つ表で出力し、最後に「判定：送信可・要修正・書き直し」のいずれかと短い理由を 1 行で書いてください。

お客様の質問：「3月分の請求が二重に引き落とされています。1件返金してもらえますか？」
返信の下書き：「お問い合わせありがとうございます！二重請求は、カード決済が再試行された場合によく発生します。仮売上（オーソリ）で後から消える場合もありますので、もう一度ご利用明細をご確認ください。ほかにご不明点があればお気軽にどうぞ！」

| 基準 | 理由 | 点数 |
|---|---|---|
| 正確さ | 原因の可能性は説明しているが、返金するかどうかに答えていない（「仮売上で後から消える場合もあります」）。 | 2 |
| 口調 | 「お問い合わせありがとうございます」と丁寧だが、「もう一度ご確認ください」はお客様を疑っているように読める。 | 4 |
| 次の行動 | 「ほかにご不明点があればお気軽にどうぞ」では、2件とも確定していた場合にどうすればよいかがわからない。 | 2 |
| 長さ | 約 110 字で、上限内に収まっている。 | 5 |

判定：要修正。2件目が仮売上かどうかを確認し、仮売上でない場合は返金の手順と時期を明記する。

伝わる指示の書き方：7 つのルール

Anthropic のプロンプトガイドは、モデルを「優秀だが、あなたの職場のやり方をまだ知らない新入社員」にたとえています。以下のルールは、その新入社員に伝えるべきことそのものです。同ガイドは、最近のモデルほど指示を文字どおりに受け取る傾向があるとも述べています。つまり、指示の抜けはそのまま出力の抜けになります。

ルール 4 は特に重要です。Anthropic のガイドでは「省略記号を絶対に使わないで」という指示を、「回答は音声合成エンジンで読み上げられ、省略記号を発音できないため」という理由つきに書き換えています。理由がわかると、モデルは読み上げで問題になるほかの表現も自ら避けるようになります。ルール 7 についてはプロンプトの構造：5 つの構成要素で詳しく解説しています。

指示を重ねる：タスク → 読み手 → 形式 → 制約

完璧な指示を一度で書けることはまれです。まず素のタスクから始め、要素を 1 つずつ足していきます。次の例文は、社内向けの変更履歴を顧客向けリリースノートに書き換えるために、その過程を経て完成した指示です。変更履歴の部分を自分のものに置き換えて使ってください。

以下の開発チーム向け変更履歴を、顧客向けのリリースノートに書き換えてください。

読み手：当社の人事ソフトを使う、技術に詳しくない管理者。
形式：タイトルの後に箇条書きを 3〜5 点。各項目は「利用者のメリット」から書き始め、続けて変更内容を書く。
制約：
- 全体で 250 字以内。
- チケット番号とリファクタリングは載せない。お客様には見えず、ノイズになるため。
- 管理者の操作が必要な変更は、その項目の最後に「要対応：」と手順を書く。

変更履歴：
"""
- PAY-2231 従業員の休暇残日数を CSV で一括インポートできるようにした
- 認証ミドルウェアのリファクタリング（ユーザー影響なし）
- fix: UTC+7 のユーザーでシフト時刻が 1 時間遅れて表示されるタイムゾーンのバグ
- PAY-2240 SSO：Okta の SCIM プロビジョニングに対応。管理者が［設定］>［セキュリティ］で有効化する必要あり
"""

今回のリリースの新機能

- 初期設定がより速く：全従業員の休暇残日数を CSV ファイルから一括でインポートできるようになりました。
- 正しいシフト時刻を表示：UTC+7 の利用者でシフト時刻が 1 時間遅れて表示される不具合を修正しました。
- ユーザー管理を自動化：Okta のユーザーを SCIM プロビジョニングで自動的に追加・削除できるようになりました。要対応：［設定］>［セキュリティ］で有効にしてください。

指示の各行が出力に反映されています。リファクタリングの項目は消え、各項目はメリットから始まり、管理者の操作が必要な変更にはその旨が明記されています。

補完形・質問形・指示形：プロンプトの「形」を選ぶ

同じ依頼でも、書き方には 3 つの形があり、それぞれ返ってくる答えの種類が違います。現在のチャットモデルはどの形にも対応しますが、出力をコントロールできる度合いは同じではありません。

SaaS 製品の返金ポリシーを一文で書いてください。
条件：購入から 14 日以内は全額返金、それ以降は返金不可。
口調：平易で親しみやすく。法律用語は使わない。

ご購入から 14 日以内であれば全額を返金いたしますが、それ以降の返金はお受けできませんので、あらかじめご了承ください。

ポイント：まだ方向性を探っている段階なら、まず質問形で聞き、良かったアイデアを指示形に書き直しましょう。

ロールプロンプトとは：何が変わり、何が変わらないか

ロールプロンプトとは、多くの場合「あなたは〜です」という形でモデルにペルソナ（人物像）を与える方法です。ロールが変えるのは文体の層です。語彙、口調、どこまで詳しく書くか、何に最初に注目するか、どう構成するか。Anthropic の現在のガイドも同様に、システムプロンプトでロールを設定すると「ユースケースに合わせて Claude の振る舞いと口調が絞り込まれる」と説明しています。

一方、ロールで確実には変わらないのが事実の正確さです。Zheng ら（Findings of EMNLP 2024）は、6 種類の人間関係と 8 つの専門分野にわたる 162 のペルソナを、4 系統のモデルと 2,410 問の事実質問で検証しました。その結果、システムプロンプトにペルソナを加えても、ペルソナなしの場合と比べて性能は向上せず、個々のペルソナの効果は「ほぼランダム」でした。「あなたは世界的な名医です」と伝えても、モデルが持っていない医学知識が増えるわけではありません。

つまり、ロールは「どう書くか」を制御するために使い、「正しいかどうか」は資料・例・検証で担保します。次の例文で確かめてみましょう。事実は固定し、ロールだけを変えます。{ロール}と{読み手}を、下の表の組み合わせに置き換えてください。

あなたは{ロール}です。
以下の障害について、{読み手}向けのメッセージを書いてください。200 字以内にまとめます。

事実（これ以外の情報は使わないこと）：
- 10 月 14 日 9:12〜10:03（UTC）に決済 API が停止（51 分間）。
- 原因：決済ゲートウェイの TLS 証明書の期限切れ。
- 決済の試行の約 3% が失敗。データの消失や二重請求はなし。
- 対応：証明書を更新し、期限切れを自動で通知するアラートを追加。

SRE リード／障害対応チャンネル：

障害：決済 API、10/14 9:12〜10:03 UTC（51 分）
根本原因：決済ゲートウェイの TLS 証明書の期限切れ。ハンドシェイクが失敗し、決済試行の約 3% がエラー。
影響：データ消失なし、二重請求なし。
対応：証明書を更新済み。期限切れの自動アラートを設定済み。

カスタマーサポート責任者／お客様へのメール：

件名：10 月 14 日の決済障害について（復旧済み）

このたびはご迷惑をおかけし、誠に申し訳ございません。10 月 14 日 9:12〜10:03（UTC）の間、一部のお支払いが完了できない状態となっておりました。お客様のデータは安全で、二重に請求されることはございません。お支払いが完了していない場合は、お手数ですが再度お試しください。原因はすでに解消し、再発防止の監視を追加いたしました。

オペレーション部門長／経営陣への報告：

10/14 に決済障害が 51 分間発生（9:12〜10:03 UTC）。原因はセキュリティ証明書の期限切れ。決済試行の約 3% が失敗したが、データ消失・二重請求はなし。同日午前中に復旧済み。証明書の期限は自動監視に切り替え、同種の障害は再発しない体制とした。

日本語のお客様向けメールでは、ロールを与えただけで冒頭にお詫びが入りました。ロールは読み手の文化に合った書き方まで引き出します。

効果的なロールプロンプトの書き方

「あなたは優秀なマーケターです」は弱いロールです。漠然とした口調が決まるだけで、ほかには何も伝わりません。役に立つロールは、誰が話すのか、誰に向けてか、何のためか、どんな制約の中で、という 4 つの問いに答えます。実際には、肩書きよりも読み手と制約のほうが大きく効きます。

次のロールは IT ヘルプデスク用のアシスタントを想定しています。システムプロンプト、または ChatGPT のカスタム指示（Custom instructions）、Claude のプロジェクトの指示、Gemini の Gem に貼り付けると、会話のすべてのメッセージに適用されます。

あなたは従業員 200 名の会社に勤めるシニア IT ヘルプデスクエンジニアです。
読み手：技術に詳しくなく、急いでいることが多い従業員。
目的：できるだけ少ない手順で、仕事に戻れるようにすること。
制約：
- 手順は番号付きで、1 手順につき 1 操作、最大 6 手順。
- 画面に表示されるボタン名・メニュー名をそのまま使う。
- 管理者権限が必要な手順は説明せず、「この手順は IT 担当に依頼してください」と書く。
- 使っている端末やアプリのバージョンがわからない場合は、最初に短い質問を 1 つだけする。

ユーザーが「今朝から Outlook が何度もパスワードを聞いてきます」と書き込むと：

まず 1 点だけ確認させてください。Outlook は Windows のパソコン、Mac、ブラウザーのどれでお使いですか？

ユーザーが「Windows です」と答えると：

1. Outlook を完全に終了します。
2. スタートメニューを開き、「資格情報マネージャー」と入力して開きます。
3. 「Windows 資格情報」をクリックします。
4. 「MicrosoftOffice」を含む項目をそれぞれクリックし、「削除」を選びます。
5. Outlook をもう一度開き、会社のメールアドレスとパスワードでサインインします。
6. それでも繰り返し聞かれる場合は、パスワードの期限が切れている可能性があります。この手順は IT 担当に依頼してください。

確認の質問は 1 つだけ、手順は 6 つ、Windows の表示名をそのまま使い、管理者作業は IT 担当に渡す。制約がすべて振る舞いに表れています。API 経由でモデルを呼ぶ場合、ロールは system パラメータに入れます。次の Python の例は Anthropic の SDK を使っていますが、システムプロンプトを持つチャットモデルなら同じ考え方で使えます。

# pip install anthropic   （環境変数 ANTHROPIC_API_KEY を設定しておく）
import anthropic

ROLE = """あなたは従業員 200 名の会社に勤めるシニア IT ヘルプデスクエンジニアです。
読み手：技術に詳しくなく、急いでいることが多い従業員。
目的：できるだけ少ない手順で、仕事に戻れるようにすること。
制約：
- 手順は番号付きで、1 手順につき 1 操作、最大 6 手順。
- 画面に表示されるボタン名・メニュー名をそのまま使う。
- 管理者権限が必要な手順は説明せず、「この手順は IT 担当に依頼してください」と書く。
- 使っている端末やアプリのバージョンがわからない場合は、最初に短い質問を 1 つだけする。"""

client = anthropic.Anthropic()
message = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=1024,
    system=ROLE,  # ロールは会話のすべてのターンに適用される
    messages=[
        {"role": "user", "content": "今朝から Outlook が何度もパスワードを聞いてきます。"}
    ],
)
# 新しいモデルは先に thinking ブロックを返すことがあるため、テキストだけを取り出す
print("".join(b.text for b in message.content if b.type == "text"))

ロールと指示を 1 つのプロンプトで組み合わせる

実際のプロンプトの多くは両方を使います。ロールが声を決め、指示がタスクと結果の形を決めます。次のテンプレートは両者をラベル付きのブロックに分けているので、片方を変えてももう片方は崩れません。{プレースホルダー}をすべて埋めてください。

# ロール
あなたは{話し手}で、{読み手}に向けて書きます。

# タスク
{目的}のために、{対象}を{動詞}してください。

# ルール
1. {測れる制約。例：「300 字以内」}
2. {「しないこと」ではなく「すること」}
3. {例外のケース}の場合は、推測せずに{代わりの対応}。

# 入力
"""
{テキスト・データ・コード}
"""

コードレビューの解説に当てはめた例です。ロールで指導する口調を決め、ルールで答えを 1 つの改善点に集中させています。

# ロール
あなたはジュニア開発者を指導するシニアバックエンドエンジニアです。

# タスク
開発者が修正方法だけでなく原理を学べるように、この MySQL 8 のクエリが何をしているか、そして性能を最も改善する変更を 1 つ説明してください。

# ルール
1. 400 字以内。
2. 書き換えたクエリの該当部分を示す。
3. 重要な変更が 2 つ以上ある場合、2 つ目は「次に学ぶこと：」の 1 行だけで触れる。

# 入力
"""
SELECT *
FROM orders
WHERE YEAR(created_at) = 2025
  AND status = 'paid'
ORDER BY created_at DESC;
"""

何をしているか：2025 年に作成された支払い済みの注文を、すべての列付きで新しい順に返しています。

改善点：日付の条件を範囲指定に書き換えます。

WHERE created_at >= '2025-01-01'
  AND created_at <  '2026-01-01'
  AND status = 'paid'

理由：created_at を YEAR() で包むと、MySQL は全行に対して関数を計算するため、created_at のインデックスを使えません。列そのものに範囲を指定すればインデックスを使い、2025 年の行だけを読めます。大きな注文テーブルでは、フルスキャンかインデックスの範囲スキャンかの差になることが多いです。

次に学ぶこと：SELECT * ではなく、必要な列だけを指定しましょう。

指示だけでは欲しい形式を説明しきれない場合は、言葉を増やすより例を見せるほうが効果的です。それがゼロショット・ワンショット・フューショットのテーマです。長い会話の中でロールとルールを維持する方法は技法の組み合わせ・プライミング・反復改善で扱います。

指示とロールでよくある失敗

よくある質問

指示プロンプトとロールプロンプトの違いは何ですか？

指示プロンプトは、タスク・形式・制約といった「何をするか」を伝えます。ロールプロンプトは「誰が、誰に向けて話すか」を伝え、主に口調・語彙・深さを変えます。良いプロンプトの多くは、短いロールと正確な指示を組み合わせています。

「あなたは専門家です」と書くと AI の回答は正確になりますか？

確実にはなりません。162 のペルソナを 2,410 問の事実質問で検証した研究では、ペルソナなしのプロンプトと比べて改善は見られませんでした。ロールは文体や焦点を整えるのに役立ちますが、正確さは良い資料・明確な指示・出力の確認によって得られます。

ロールはシステムプロンプトとユーザーメッセージのどちらに書くべきですか？

会話全体で維持したいロールは、システムプロンプト、またはチャットボットのカスタム指示やプロジェクト設定に書きます。タスクごとの指示はユーザーメッセージに書けば、ターンごとに変更できます。

指示はどのくらいの長さにすべきですか？

推測の余地がなくなるまで、ただしそれ以上は長くしない、が目安です。単純なタスクなら一行で十分で、繰り返し使うワークフローなら番号付きのルールが 10 個必要なこともあります。削っても出力が変わらないルールは削りましょう。

参考資料

• Learn Prompting: Instructions in Prompts
• Learn Prompting: Roles in Prompts
• Learn Prompting: Tips for Writing Better Prompts
• Wei ら（2021）Finetuned Language Models Are Zero-Shot Learners（FLAN）
• Ouyang ら（2022）Training language models to follow instructions with human feedback
• Zheng ら（2024）When “A Helpful Assistant” Is Not Really Helpful: Personas in System Prompts Do Not Improve Performances of Large Language Models
• Anthropic: Prompting best practices
• Microsoft Presidio：個人情報の検出・匿名化ツール

Prompt Engineering ガイド 全記事

← 前の回：第3回：プロンプトの構造：5 つの構成要素 · 次の回：第5回：ゼロショット・ワンショット・フューショット →

第1〜6回は前の回を前提にしているため、順番にお読みください。第7〜10回は基礎を押さえた後なら、どの順番でも読めます。

• 第1回：プロンプトエンジニアリングとは何か、なぜ重要か
• 第2回：LLM の仕組み：生成 AI の基礎
• 第3回：プロンプトの構造：5 つの構成要素
• 第4回：指示プロンプトとロールプロンプト（この記事）
• 第5回：ゼロショット・ワンショット・フューショット
• 第6回：技法の組み合わせ・プライミング・反復改善
• 第7回：要約・表・文書分析のプロンプト
• 第8回：メール・ブログ・マーケティングのプロンプト
• 第9回：コーディングアシスタントのプロンプト
• 第10回：ナレッジベース・チャットボット（RAG）の構築