業務で効くプロンプト設計15フレームワーク集｜役割×文脈×形式の設計術

導入：なぜプロンプトは「書く」のではなく「設計する」必要があるのか

業務でAIを使い始めた頃、自分は「文章で頼めば返ってくる」とだけ思っていた。実際それでも返事は来る。ただ、半年ほど業務に組み込んで分かったのは、自然文でその場任せに頼んだ場合と、構造を意識して設計した場合とでは、同じモデル・同じ依頼内容でも返ってくるものの精度・再現性・後段工程との接続のしやすさが大きく異なる傾向がある、ということだった。

ここで言う「設計」とは、要するにプロンプトを「役割」「文脈」「形式」の3軸に分解して、それぞれを意識的に組み立てる行為のことだ。

• 役割：誰として答えてほしいか（経理視点の監査担当か、顧客視点のクレーム対応窓口か、技術視点のレビュアーか）

• 文脈：どんな前提情報のもとで答えてほしいか（業界・自社状況・直前の経緯・制約条件）

• 形式：どんな見た目で返してほしいか（箇条書きか、表か、YAMLか、Markdown見出し付きか）

この3軸が揃っていないプロンプトは、たいてい「もっと丁寧に書いてくれた方がよかった」「うちの事情を踏まえてくれていない」「コピペしづらい形で返ってきた」のいずれかで詰まる傾向がある。自分の体感としても、業務に組み込んで失敗するパターンの大半は、文章力ではなくこの3軸の欠落から来ていることが多かった。

逆に、3軸を埋める意識さえあれば、文章力は二の次でも実用に耐える出力に近づきやすい。プロンプトを「うまく書く」競技ではなく「漏れなく設計する」作業として捉え直すと、業務適用のハードルはかなり下がる印象がある。

本記事では、この3軸を補強する形で実務に効きやすい15のプロンプト設計フレームワークを紹介する。各フレームには「①用途 ②プロンプト例文 ③使用シーン ④落とし穴」を付した。網羅性より実装可能性を優先したので、明日の業務からそのまま使える叩き台として活用いただきたい。

なお本記事の内容は一般的な設計の整理であり、最適解は業務内容・モデル・組織の慣行により変動する。最終的な調整はご自身の環境に合わせて行っていただくことをあらかじめお断りしておく。