プロンプトの基礎
プロンプトという言葉は便利な反面、意味が広すぎて議論がブレやすい用語です。OpenAI の Prompt engineering guide や Anthropic の Prompt engineering overview では、プロンプトを「タスクを実行するために LLM に渡すすべての入力」と定義し、指示・文脈・例示・出力指定の組み合わせとして扱います。
指示（何をしてほしいか）、文脈（判断に必要な背景）、例示（望ましい入出力）、出力指定（形式・長さ・禁則）。AI が思った通りに動かない時の多くは、4 つのうちどれかが欠けています。
01.まず結論：プロンプトは4要素で構成される
プロンプトは「依頼文」ではなく、AIに渡すすべての入力の総称です。チャット UI に書く 1 行も、API で渡す数千トークンも、システムプロンプト＋ユーザープロンプト＋過去の会話も、すべてプロンプトに含まれます。
| 要素 | 中身 | 抜けるとどうなるか |
|---|---|---|
| 指示 | 何をしてほしいか（タスク・役割・禁止事項） | 目的がぶれて関係ない情報が混じる |
| 文脈 | 判断に必要な背景・資料・前回までの会話 | 一般論で答えてしまい自社条件と合わない |
| 例示 | 望ましい入出力のペア（Few-shot） | 出力フォーマットが安定しない |
| 出力指定 | 形式、長さ、トーン、必須要素、禁則 | 後工程（社内システム・レビュー）で使いづらい |
02.プロンプトの構成要素
指示（Instruction）
AI に何をしてほしいかを書く部分です。タスクだけでなく、誰の立場で答えるか（役割）、何をしてはいけないか（禁止事項）も含みます。
| 指示の要素 | 良い例 | 悪い例 |
|---|---|---|
| タスク | 「以下の議事録から、合意事項と未決事項を分けて箇条書きにしてください」 | 「議事録を要約して」（出力が安定しない） |
| 役割 | 「BtoB プロダクトマネージャーの視点で」 | （指定なしだと一般的すぎる答えになる） |
| 禁止 | 「文中に存在しない数値を補わない」 | （指定なしだとハルシネーションが混じる） |
文脈（Context）
AI が判断するために必要な背景情報です。社内資料、過去の会話、検索結果、商品データなど、外部から取り込んだ情報を渡す場所。LLM の事前学習データには社内固有情報は含まれないため、ここで補います。
BtoB 実務では、この文脈を RAG で動的に組み立てることが多くなります。詳細は別記事の「RAG 実務入門」と「ファインチューニング・RAG・プロンプトの使い分け」で整理しています。
例示（Examples / Few-shot）
望ましい入出力のペアを 1〜数個並べる手法です。「こういう入力には、こういう形で答えてほしい」を見せると、出力が安定しやすくなります。Few-shot は事前学習からの行動を強く誘導するため、形式が決まっている業務（分類、抽出、フォーマット変換）で特に効きます。
推論モデル（Claude 4 系、GPT-5、Gemini 2.5）は few-shot を多く渡すと逆に推論経路がぶれることがあります。Anthropic / OpenAI のガイドでも「シンプルな指示＋必要なら 1〜2 例」を推奨しています。
出力指定（Output format）
形式（箇条書き / 表 / JSON / Markdown）、長さ、トーン、必須要素、禁則を指定します。BtoB の業務利用では、後工程（社内システム、検索、レビュー）で再利用するため、出力形式の指定が成果物の使いやすさを大きく左右します。
構造化出力（JSON Schema / Structured outputs）を使うと、フィールド名・型・必須項目を強制でき、業務システムとの連携で特に有効です。
03.システムプロンプトとユーザープロンプト
API 経由で LLM を使う場合、プロンプトは複数の役割に分かれます。最も基本は「システムプロンプト」と「ユーザープロンプト」の 2 種類です。
| 役割 | 中身 | 誰が決めるか |
|---|---|---|
| システムプロンプト | アシスタントの振る舞い、口調、禁止、出力規約 | アプリ提供者（運用側） |
| ユーザープロンプト | 具体的なタスクや質問 | エンドユーザー |
| アシスタント（過去出力） | 前ターンまでの応答 | AI（履歴として保持） |
| ツール結果 | 外部 API・検索・関数の戻り値 | システム（実行時に挿入） |
BtoB の業務エージェントを設計するとき、最も大事なのは「システムプロンプトに何を書くか」です。ここで業務ルール・禁止事項・出力規約を厳密に決めておけば、ユーザー入力が雑でも安定した出力が得られます。
04.なぜ同じ問いでも回答が変わるのか
同じ問いを 2 回投げて違う答えが返ってきた経験は、ほぼ全員にあります。これは AI の「気まぐれ」ではなく、LLM が確率的なトークン予測器だからです（詳しくは LLM の記事を参照）。具体的に効いているのは次の要素です。
| 要素 | 効き方 | BtoB での対処 |
|---|---|---|
| サンプリング温度（temperature） | 高いほど多様性、低いほど決定的 | 業務利用では temperature を下げる（0〜0.3） |
| シード（seed） | 乱数の起点。同じシードなら再現性が上がる | 再現が必要なら API 経由で seed を固定 |
| システム＋ユーザー＋履歴 | 文脈が違えば出力も違う | 前提を明示し、履歴を意図的に切る |
| モデル更新 | ベンダーが内部更新で挙動が変わることがある | 本番ではモデルバージョンを固定する |
05.現在主流のプロンプト設計：単発から構造化へ
2022〜2023 年のプロンプト設計は、ChatGPT のチャット欄に長い指示文を書く「単発プロンプト」が中心でした。プロンプトエンジニアリングと呼ばれて流行しましたが、業務での再現性は低めでした。
2024 年以降、プロンプトは「業務システムの一部」として扱われるようになります。具体的には、(1) システムプロンプトをテンプレート化、(2) 文脈を RAG で動的に組み立て、(3) 例示を構造化フォーマットで管理、(4) 出力を JSON Schema で固定、という構造化プロンプトが標準です。Anthropic の prompt caching や OpenAI の structured outputs のような機能も、構造化設計の支援です。
2023 年に流行した「魔法のプロンプト集」「コピペで使えるプロンプト 100 選」は、個人利用には便利でしたが、BtoB の業務再現性が低い設計です。組織で使うなら、テンプレート＋RAG＋構造化出力に置き換えるのが現実的です。
業務指示書としての 7 原則
§01 の 4 要素を実務で運用しやすく細分化すると、以下の 7 原則になります。新人や外注先に依頼を出す時と同じ構造で組み立てると、AI でも人でも安定した成果物が得られます。
| 原則 | 渡す内容 | 例 |
|---|---|---|
| 目的 | 何を達成したいか | 商談後メールの返信率を上げたい |
| 背景 | 相手・状況・前提 | 相手は BtoB SaaS のマーケ責任者 |
| 材料 | 使ってよい情報 | 議事録、提案資料、過去メール |
| 制約 | 避ける表現・条件 | 断定しない、価格は書かない |
| 出力形式 | 表、箇条書き、JSON など | 件名 3 案、本文 1 案、追伸 1 案 |
| 例示 | 良い例・悪い例 | 既存メールの文体を添える |
| 確認条件 | 自己点検の観点 | 事実未確認の箇所を最後に列挙 |
悪い依頼を直す実例
プロンプトは長ければよいわけではありません。長くても判断基準がないと、AI はもっともらしく補完します。「何を優先し、何を捨てるか」を伝えることが重要です。
| 悪い依頼 | 問題 | 直し方 |
|---|---|---|
| この資料をいい感じに要約して | 読み手と用途がない | 役員会で 3 分説明する前提で、意思決定事項だけを 5 点に要約 |
| SEO記事を書いて | 検索意図と根拠がない | 対象 KW、読者、競合との差分、使う一次ソースを指定 |
| 売れるメールを作って | 何を売るか不明 | 顧客課題、商談状況、避ける訴求、CTA を渡す |
社内テンプレート化の必須度
テンプレート化で品質を底上げできますが、空欄を埋めるだけになると逆に質が落ちます。テンプレートには、入力例だけでなく「空欄時のリスク」「AI に推測させてはいけない項目」も書きます。
| テンプレ項目 | 必須度 | 空欄時の扱い |
|---|---|---|
| 目的 | 必須 | 目的がなければ開始しない |
| 参照資料 | 必須 | 資料不足なら不足を質問させる |
| 出力形式 | 高 | なければ候補を 3 形式で出させる |
| 禁止事項 | 高 | 法務・ブランド表現に関わるため明記 |
06.よくある誤解
| 誤解 | 実際 | 現場での扱い方 |
|---|---|---|
| プロンプト ＝ チャット欄の依頼文 | システムプロンプト＋履歴＋ツール結果すべてがプロンプト | API 経由は要素を分けて設計する |
| プロンプトを長く書けばよい | Lost in the Middle で真ん中が読まれないことがある | 重要情報は冒頭か末尾、または RAG で抽出 |
| プロンプトは秘伝のノウハウ | 公式ガイド（OpenAI / Anthropic）に体系がある | 公式ガイドを読み、自社向けに調整する |
| 推論モデルなら少ない指示でよい | 目的・禁止・出力指定は依然必要 | 推論モデルでも 4 要素は省略しない |
07.よくある質問（FAQ）
プロンプトとプロンプトエンジニアリングは違いますか？
プロンプトは AI への入力そのもの（指示・文脈・例示・出力指定の組み合わせ）、プロンプトエンジニアリングはその設計手法の総称です。前者が対象、後者がプロセス、と覚えると整理しやすくなります。
プロンプトは長く書いた方が回答精度が上がりますか？
必ずしも上がりません。長すぎるプロンプトでは Lost in the Middle により真ん中の情報が読まれにくくなる現象が確認されています。重要情報は冒頭か末尾に置く、または RAG で関連範囲だけ渡す方が安定します。
システムプロンプトには何を書けばよいですか？
アシスタントの役割、口調、禁止事項、出力規約、業務ルールを書きます。エンドユーザーが触らない領域なので、組織ルールをここに集約しておくと、ユーザー入力が雑でも出力が安定します。BtoB の業務エージェント設計では、システムプロンプトの設計が成否を分けます。
推論モデル時代でもプロンプト設計は必要ですか？
必要です。推論モデル（Claude 4 系、GPT-5、Gemini 2.5）は内部推論で複雑なタスクを処理できますが、目的・禁止・出力指定が抜けると結果はやはりぶれます。むしろ自由度が増した分、システムプロンプトでルールを明示する重要性は上がっています。
プロンプトのテンプレート化は誰がやるべきですか？
業務知識を持つ事業部門と、AI 設計を担当する開発・AI 推進担当の共同で進めるのが現実的です。テンプレートは「業務ルール × AI 挙動」を文書化したもので、片側だけで作るとすぐ陳腐化します。レビューと更新の責任者を最初に決めておくと続きます。
08.まとめ
プロンプトは AI への「お願い文」ではなく、指示・文脈・例示・出力指定で組み立てる入力データです。AI が思った通りに動かない時は、ほぼ 4 要素のどれかが欠けています。
BtoB の業務利用では、チャット欄に長文を書く設計から、システムプロンプト＋RAG＋構造化出力の組み合わせに移行するのが現在の主流です。「呪文プロンプト」をコピペする運用は再現性が低く、過去の話と整理して、テンプレート設計に置き換えていくのが現実的です。
プロンプトの設計を業務に組み込みませんか
AI 活用や AI エージェント導入のご相談、PoC、伴走支援をご検討の方は、お気軽にお問い合わせください。
