AIプロンプト生成器

ChatGPT、Claude等のAIモデル用の効果的なプロンプトを作成

プロンプトが失敗する理由:仕様の問題

がっかりするAIの回答の大半は、モデルの失敗ではなく仕様の失敗です。言語モデルはリクエスト内のあらゆる曖昧さを、統計的に平均的な解釈で推測して埋めます。そして曖昧な依頼の平均的な解釈は、曖昧な答えです。「リモートワークについて書いて」には何千通りもの妥当な読み方があります。ブログ記事か、社内メモか、長所短所リストか。役員向けか新入社員向けか。200語か2,000語か。モデルはどれかを選ばねばならず、いちばん無難なものを選びます。 エンジニアリング上の洞察は、プロンプトとは仕様であり、仕様が改善されるのと同じやり方で改善される、ということです。重要な自由度を固定するのです。4本のピンでほとんどの仕事が片付きます。タスク:動詞と成果物(「オンボーディングについて書いて」ではなく「600語のオンボーディングメールを書いて」)。読者:誰が読み、何をすでに知っているか。制約:長さ、トーン、形式、除外事項。文脈:モデルには推測できない背景事実 — あなたの製品、状況、失敗した前回の試み。 具体性が報われる証拠は確かです。実務では、明示的な読者と長さの制約を加えるだけで出力の質が目に見えて変わります。妥当な答えの空間が潰れるからです。有用な習慣を1つ。プロンプトを書いたら「常識的な2人がこれを読んで、別々の成果物を期待し得るか?」と自問してください。イエスなら、モデルはどちらか一方を失望させます。そしてどちらを失望させるかを、あなたは選べません。
Before (vague — average answer guaranteed):
"Write about remote work."

After (specified — 4 pins):
"Write a 600-word article arguing that hybrid schedules
beat fully-remote for junior engineers.
Audience: engineering managers at startups (assume they
already know the standard remote-work pros/cons).
Tone: direct, conversational, no buzzwords.
Structure: hook, 3 arguments each with one concrete
example, one counterargument addressed, action-oriented
close. Do NOT discuss cost savings or real estate."

測定可能な効果がある技法:ロール、Few-shot、分解

プロンプトエンジニアリングには検証済みの本物の技法が蓄積されました。同時に民間伝承も蓄積されました。荷重を支えている部分だけを抜き出すとこうなります。 ロール付与(「あなたはこの書類の誤りをレビューするシニア税理士です」)が効くのは、モデルが税理士になるからではなく、出力分布がそのジャンルの語彙・慎重さ・構造の方向へ移動するからです。トーンと深さの調整には最も効き、事実の正確さには最も効きません。医師を演じるモデルは医学的に正確になるのではなく、口調が臨床的になるだけです。ロールは文体を決めるために使い、権威を捏造するために使わないでください。 Few-shot例示は、形式とスタイルに対して最もレバレッジの大きい技法です。入力と出力のペア2〜3組は、説明の段落数個に勝ります。言語化しようと思いつきもしないこと — ラベルの簡潔さ、エッジケースの形、「良い」が実際に何を意味するか — を指定してくれるからです。例は多様に保ってください。モデルは例のパターンを、その偏りごと強烈に複製します(例がすべてポジティブなら、出力もポジティブに偏ります)。 多段階の作業では、分解が単一の巨大プロンプトに勝ります。「この契約書を読み、リスク条項を見つけ、それについてのメールを起草して」は、品質基準の異なる3つのタスクの混合です。3つのプロンプトに分ければ、中間出力を検査し修正できます。同様に、書く前に計画を求める(「まずセクション一覧だけ出して待って」)ことで、構造の問題を1行の修正で済む段階で捕まえられます。 思考連鎖の指示(「ステップバイステップで考えて」)は算術・論理系の問題に効きますが、最近の推論特化モデルは内部でこれを行うことが多い。今日より大きな効果があるのは、確定前に「あなたの答えが私の明示した制約を満たすか検証せよ」と求めることです。
Few-shot format specification (2 examples do the work):

"Classify each support ticket. Respond in exactly this format.

Ticket: 'App crashes when I upload a photo over 10MB'
-> category: bug | severity: high | team: mobile

Ticket: 'Would love a dark mode option'
-> category: feature-request | severity: low | team: design

Ticket: 'I was charged twice this month'
->"

出力スキーマ:プログラムが読める答えを得る

AIの答えが下流の何か — スプレッドシート、スクリプト、別のプロンプト — に流れ込む瞬間、自由形式の散文は負債になります。解決策は出力スキーマの指定です。応答の正確な形を、交渉不可の条件として明示するのです。 3つの実践がスキーマを守らせます。第一に、スキーマは説明せず見せる。「title、risk_level(low/medium/highのいずれか)、reasons(文字列の配列)をキーに持つJSONで応答せよ」でも良いですが、値の入ったJSONの実例を貼るほうが優れています。実例は、説明が開けたままにする細部 — 引用符のスタイル、大文字小文字、空配列の可否 — を固定するからです。第二に、逃げ道を塞ぐ。モデルはJSONをマークダウンのフェンスで包み、「こちらがJSONです:」を前置きし、愛想の良い締めの一文を加えたがります。明示してください。「JSONオブジェクトのみを出力。コードフェンス禁止、前後の説明禁止」。第三に、失敗を設計に組み込む。スキーマの中で「できなかった」と言える手段(statusフィールド、null許容の回答)を用意してください。さもないとモデルは必須フィールドを空にする代わりに、もっともらしい創作で埋めます。それこそが検出不能な失敗です。 スキーマはプログラムと無関係な作業も改善します。「X・Y・Z列の表」や「それぞれ動詞で始まるちょうど5つの箇条書き」を要求すると、モデルは思考を整理せざるを得ず、欠けた部分が一目で見えます。構造化された誤答は見つけやすく、雄弁な誤答はそうではありません。それでも、機械がパースするものは必ず検証を。現代のモデルのスキーマ遵守率は高いものの、APIレベルの構造化出力機能を使わない限り保証はされません。
"Analyze the review below. Output ONLY this JSON —
no code fences, no text before or after:

{
  "sentiment": "positive",
  "confidence": 0.92,
  "topics": ["shipping", "packaging"],
  "actionable_complaint": true,
  "status": "ok"
}

If the text is not a product review, output:
{ "status": "not_a_review" }
and nothing else."

反復のループ:プロンプトをコードのように扱う

重要なタスクで最初の一発から良いプロンプトを書ける人はいません。安定して強い結果を出す人はループを回しています。下書き、テスト、診断、修正 — デバッグと同じループです。 診断こそが技術です。出力にがっかりしたら、プロンプトに触る前に失敗の名前を付けてください。形式が違う?スキーマか例を追加。深さが違う?読者の指定が欠けているか誤っています。内容が違う?モデルが持たない文脈を仮定したのだから、背景事実を追加します。指示が無視された?プロンプトの中間に埋もれているのかもしれません。モデルはプロンプトの冒頭と末尾を中間より重視するので、重要な制約を先頭に移し、最重要の1つを末尾で再度述べてください。自信満々の誤り?ハルシネーションを確実に直すプロンプトの言い回しは存在しません。ソース資料を与え、そこからのみ答えるよう指示する必要があります。 1回の反復で変えるのは1箇所だけ。5箇所を一度に書き換えて出力が改善しても、どこが効いたのかは何も学べません。プロンプトもコードと同じで、迷信が速く蓄積します(「このパラグラフはいつも入れる。理由は誰も覚えていない」)。 2つの習慣が、カジュアルなユーザーと熟練者を分けます。プロンプトのライブラリを維持すること。うまくいったプロンプトは、用途のメモと出力例1つを添えて保存してください。何か月も再利用することになります。そして、信頼する前に複数の入力でテストすること。1つの例に合わせて調整されたプロンプトは、1データ点で訓練されたモデルと同じように、その例へ静かに過学習しています。

プロンプトでは直せないもの

よく作られたプロンプトはモデルの出力の上限を引き上げますが、一部の限界はモデル自身のものであり、そうでないふりをしても時間を浪費するだけです。 どんなプロンプトも、訓練されていないことをモデルに知らせることはできません。昨日のあなたの会議、先週発表された論文、社内の価格情報。答えにその情報が必要なら、プロンプトの中になければなりません — あなたが入れるか、検索システムが入れるかです。関連して、プロンプトはリアルタイムデータへのアクセス権を与えません。「現在の価格」を尋ねられたモデルは、価格の形をした数字を生成します。 どんなプロンプトもハルシネーションを消せません。根拠資料は減らすだけです。ソースを与えても、モデルは時に、提供された事実と記憶にある事実を混ぜます。事実に関わる仕事のルールは変わりません。モデルが下書きし、あなたが検証する。提供テキストへの引用(段落番号が有効)を求め、抜き取り検査し、具体的で、都合が良く、検証不能なディテールを最も疑ってください。 どんなプロンプトも、モデルを自分の出力の信頼できる審判にはできません。「本当に?」は、あなたが望んでいそうな方向への丁寧な自己修正を引き出すだけのことがほとんどです。モデルには追従(sycophancy)の傾向があり、ユーザーの主張が誤っていても同意します。独立したチェック(新しい会話、別のモデル、あるいはあなた自身の専門知識)は、会話内のどんな安心材料よりも価値があります。 この境界を知ること自体がプロンプトの技術です。最良の実務家は、言葉遣いが効く場所 — 仕様、例示、スキーマ、分解 — に労力を注ぎ、効かない場所では別の道具に手を伸ばします。