レッスン2：プロンプトの基本骨格——役割・指示・文脈・例・出力形式

このレッスンで学ぶこと

システムプロンプトとユーザープロンプトの区別を理解する
5 要素のフレームワーク（役割・指示・文脈・例・出力形式）を使いこなす
persona 設定の効用と過信のリスクを把握する
指示の明示化と禁止事項の併用を学ぶ
プロンプトを「依頼書」として書く発想を身につける

前回のレッスンでは、プロンプトエンジニアリングを「評価とイテレーションを伴う設計の運用」として位置づけ、2026 年 6 月時点の主要モデルと reasoning モデルの違いを概観しました。今回はその実装基盤となる「プロンプトの基本骨格」に入ります。すべての高度な技法は、この骨格の上に乗ります。

システムプロンプトとユーザープロンプト

主要な LLM API では、プロンプトを「システムプロンプト」と「ユーザープロンプト」の 2 種類に分けて扱います。

システムプロンプト

LLM の振る舞い・役割・出力形式・制約などを定義する、一段上のレイヤーのプロンプトです。アプリケーション側で設定し、エンドユーザーには見えないことが多くあります。一般に、ユーザープロンプトより優先度が高く扱われる設計です。

ユーザープロンプト

エンドユーザーが入力する、その都度の質問・指示・データです。同じシステムプロンプトの上で、複数のユーザープロンプトをやり取りすることが多くあります。

レイヤー	設定者	例
システムプロンプト	アプリ開発者・社内担当者	「あなたは社内 IT のヘルプデスクです。社内ルールに反する質問は丁寧に断ってください」
ユーザープロンプト	エンドユーザー	「Wi-Fi に接続できません。どうすればよいですか？」

💡 ポイント ChatGPT の Web 画面のように、エンドユーザーが直接 LLM とやり取りする場合、システムプロンプトが見えないこともあります。一方、API 経由で社内システムに組み込む場合は、システムプロンプトの設計が運用の質を決めます。本コースは後者を主に想定します。

プロンプトの 5 要素

プロンプトの基本骨格を、本コースでは次の 5 要素に整理します。これは多くのプロンプトエンジニアリング指南書で共通して紹介される「黄金のフレームワーク」です。

①役割（Role）

LLM に「どんな立場・専門性で答えてほしいか」を設定します。「あなたはベテランの IT サポート担当者です」「あなたは法務の専門家です」のような形です。

②指示（Instruction）

「何をしてほしいか」を具体的に書きます。動詞を明確に：「要約してください」「3 つのオプションを挙げてください」「JSON で返してください」など。

③文脈（Context）

タスクを理解するために必要な背景情報・データ・参照資料を与えます。「以下の会議議事録について」「次の顧客の問い合わせ内容に対して」のように。

④例（Examples）

期待する入出力の対を 1 つ以上示します。レッスン 3 で扱う Few-shot プロンプティングが、この要素の発展形です。

⑤出力形式（Output Format）

出力の形式・長さ・構造を明示します。「JSON 形式で」「3 段落で」「箇条書きで 5 個」など。レッスン 4 で詳しく扱います。

要素	問い
役割	どんな立場で答えてほしいか？
指示	何をしてほしいか？
文脈	タスク理解に必要な情報は？
例	期待する入出力のサンプルは？
出力形式	どんな形・長さで返してほしいか？

5 要素の組み合わせ例

社内ヘルプデスクのプロンプトを 5 要素で組み立ててみます。

役割：あなたは IT ヘルプデスクの専門家です。指示：以下の問い合わせに対して、原因の可能性と対処手順を回答してください。文脈：弊社は Windows 11 とイントラネット環境で運用しています。Wi-Fi は社内 SSID「ABC-corp」で接続します。例：問い合わせ：「メールが届かない」／回答：「考えられる原因は ①迷惑メールフォルダ、②受信フィルタの設定、③相手側送信エラーです。1. 迷惑メールフォルダを確認してください。2. ……」 出力形式：原因 3 つ・対処手順を番号付き箇条書きで。日本語、簡潔に。

📝 補足 5 要素すべてを毎回書く必要はありません。タスクによっては、例や文脈が不要なものもあります。「どの要素が抜けているか」「抜けていることで何が曖昧になるか」を点検するためのチェックリストとして使うのが、運用上のコツです。

persona 設定の効用と過信のリスク

「あなたは○○の専門家です」のような persona 設定は、プロンプトエンジニアリングで広く使われる技法ですが、効用と過信のリスクの両面を理解しておく必要があります。

効用

専門用語・文体・回答スタイルが、その役割らしくなる傾向
「初心者向けに」「医師として」など、抽象的なスタイル指示がコンパクトに伝わる
文章の一貫性が上がる

過信のリスク

persona を設定したからといって、LLM が本当にその専門知識を「持つ」わけではない
「あなたは弁護士です」と書いても、実在の弁護士が答える法的見解と同じ精度になるとは限らない
「100% 正確に答えてください」のような指示は、誤りの確率を下げる効果はあっても、ハルシネーションを根絶しない
persona に「自信を持って」「絶対に間違えずに」のような指示を入れると、間違いを隠す方向に作用する場合がある

⚠️ 注意 persona 設定は文体や語彙の制御には有効ですが、「専門家の判断」を保証するものではありません。重要な意思決定（法律・医療・税務など）に LLM の出力をそのまま使うのは、persona を設定しても危険です。「専門家のアドバイスを得る前の整理に使う」程度の位置づけが安全です。

指示の明示化——曖昧さを潰す

LLM はプロンプトの曖昧さに弱いです。「うまく」「適切に」「いい感じに」のような抽象語は、出力のブレを生みます。指示を明示化するコツを 4 つ整理します。

①数値・基準で具体化する

悪い：「短く要約してください」
良い：「200 文字以内で要約してください」

②動作の動詞を選ぶ

悪い：「この会議について教えてください」
良い：「この会議議事録から、決定事項を箇条書きで 5 個抽出してください」

③肯定形で書く

悪い：「不適切な表現を使わないでください」
良い：「丁寧で中立的な表現を使ってください。攻撃的・差別的な言葉は避けてください」

④評価基準を内蔵する

悪い：「読みやすく書いてください」
良い：「中学生でも理解できる語彙で、1 文を 50 文字以内に保ってください」

💡 ポイント 「自分が新人社員にこのタスクを依頼するとしたら、何を伝えれば誤解なく動けるか」を想像すると、必要な明示化のレベルが見えてきます。LLM は「察する」のは得意ではありません。新人社員以上に、丁寧な指示が必要だと思って書くのがコツです。

禁止事項の併用

肯定形の指示が基本ですが、明示的に「やってほしくないこと」も書いておくと、出力の安定性が増します。

効く禁止事項

「事実が確認できない場合は『情報が不足しています』と回答してください。推測で答えないでください」
「個人情報（氏名・住所・電話番号）が含まれている場合は、その部分を [削除] と置き換えてください」
「JSON 以外の文字（前置き、後置き）は一切出力しないでください」

効きにくい禁止事項

「絶対に間違えないでください」（測定不能）
「ハルシネーションを起こさないでください」（モデル側で完全制御できない）
「最高の品質で答えてください」（基準不明）

📝 補足 効く禁止事項は、「出力を見れば違反かどうか判定できる」もの。効きにくい禁止事項は、「違反かどうか判定できない」抽象的な命令です。指示も禁止も、判定可能な形に落とすのが大切です。

プロンプトを「依頼書」として書く

5 要素・明示化・禁止事項を組み合わせるときの全体的な発想として、本コースは「プロンプトを依頼書として書く」スタンスを推奨します。

優秀な部下や外注先に仕事を依頼するときの、依頼書の基本構造は、

誰に（あなたは○○の専門家です）
何を（このタスクをこういう手順で）
どんな材料で（添付の資料を参照）
どんな成果物として（このフォーマットで）
何を避けて（この点には注意）

を明示することです。プロンプトもまったく同じ発想で書きます。

💡 ポイント 「LLM に話しかける」のではなく「LLM に依頼書を渡す」と発想を変えると、書き方が自然に明示的になります。Slack のチャットのように「お願い、これやって」と書くと、結果は不安定になります。Word の依頼書のように、構造的に書くのが運用に耐えるプロンプトの第一歩です。

講師の現場メモ：「気を利かせてやって」の罠

私（西脇）が独立後にコンサルティングを担当した、ある中堅メーカーの経営企画の話です。彼らは社内文書の要約に Claude を使い始めたばかりで、「うまくいかない、ハルシネーションが多い」と相談を持ってきました。

実際に使われていたプロンプトを見せてもらいました。

「以下の文書を、気を利かせていい感じに要約してください。」

これだけでした。

私は経営企画の担当者に、「『気を利かせていい感じに』を、新人社員に説明するつもりで具体化してみてください」と提案しました。担当者は数分考えて、こう書き直してくれました。

役割：あなたは社内ナレッジ管理の担当者です。指示：以下の文書を 300 文字以内で要約してください。要約には、①目的、②主要な決定事項、③次のアクション、を必ず含めてください。文脈：弊社は精密機器メーカーで、社内文書は技術用語と専門用語が多めです。 出力形式：上記の 3 項目を見出しに分けた箇条書きで。 避けること：原文にない情報を推測で補わない。事実が文書から読み取れない項目は「文書に記載なし」と書く。

書き直したプロンプトで同じ文書を要約させたところ、出力の精度は劇的に上がりました。300 文字制限が効いて簡潔になり、3 項目の構造化で抜けが減り、「文書に記載なし」の指示で過剰な推測が消えました。

「LLM に『察してもらう』ことを期待した」のが最初の失敗で、「LLM に明示的な依頼書を渡した」のが改善の本質でした。

このときに改めて感じたのが、プロンプトエンジニアリングの基本骨格を押さえるだけで、多くの「LLM がうまく動かない」問題は解決するということです。本コースは、高度な技法に入る前に、この基本骨格をしっかり扱います。

まとめ

このレッスンでは、以下のことを学びました。

システムプロンプト（振る舞い・制約の定義、開発者が設定）とユーザープロンプト（その都度の質問・指示）は別レイヤー
プロンプトの 5 要素：役割／指示／文脈／例／出力形式。すべて使う必要はなく、チェックリストとして点検
persona 設定の効用（文体・スタイル制御）と過信のリスク（専門知識を持つわけではない、ハルシネーション根絶しない）
指示の明示化：数値・基準で具体化／動作の動詞／肯定形／評価基準の内蔵
禁止事項の併用：「判定可能な形」に落とす（効く禁止）／抽象的な命令（効かない）
プロンプトを「依頼書」として書く——LLM に話しかけるのではなく、依頼書を渡す発想

次のレッスンでは、5 要素の中の「例」を深く掘り下げ、Zero-shot／Few-shot プロンプティング、そして古典的かつ今でも基本となる Chain-of-Thought を扱います。reasoning モデル時代の使い分けにも触れます。

確認クイズ

このレッスンの理解度をチェックしましょう。