プロンプトビルダー
「何をしてほしいか」を構造に分解し、そのまま使えるプロンプトを生成します。構造化されたプロンプトは、一言の指示よりずっとよく効きます。
役割はどの知識を引き出すかを決め、タスクは目標を決め、背景は勝手な推測を減らし、出力形式は結果をそのまま使えるようにし、制約はよくある「正しいのに役に立たない言葉」を防ぎます。足りない項目は空欄のままで構いません。プロンプトビルダーが自動でスキップします。
使う場面
- 週報、コードレビュー、文章の書き換えなど同じ種類の作業を繰り返すので、役割・出力形式・制約を再利用できる型として固定したいとき。
- モデルが「正しいが役に立たない一般論」ばかり返すので、避けたいこと・必ず含めたいことを毎回口頭で足すのではなく、プロンプトに明記したいとき。
使わないほうがよい場面
- 作業自体がまだ固まっていないとき。何を成果物とするか、何が合格かを言えない段階では、型に入れても曖昧な依頼が立派に見えるだけです。
- few-shot の例、ツール呼び出しの schema、複数ターンの状態、検索した資料が必要なとき。これらは手で書くか、専用のオーケストレーション基盤で扱います。
ローカルでの組み立てのみで、送信もモデル呼び出しもありません。制限：テンプレートの連結だけで、妥当性の判断も効果の保証もしません。2 項目以上で生成、下書き保存なし、few-shot・ツール定義・複数ターン非対応。
よくある質問
入力した内容はアップロードされますか？
いいえ。ローカルでの文字列の組み立てだけで、通信もモデル API の呼び出しもなく、localStorage にも URL にも書きません。タブを閉じれば入力は消えるので、下書きも残りません。実際のリスクは次の段階で、完成したプロンプトを貼り付けたサービスのプライバシーポリシーと保存期間が適用されます。機密情報は先に伏せ字にしてから貼ってください。
構造化したプロンプトは本当に 1 文より良い？
成果物が明確な作業では、たいてい良いです。制約が推測ではなく明示的な条件になるからです。ただし構造が多ければよいわけではなく、「あなたは世界最高の専門家です」といった役割設定は現在のモデルでは効果が薄く、回答がぼやけることもあります。効くのは具体的な作業、実際の入力資料、明確な出力形式、そして材料が足りないときの指示です。最初の回答のあと 2〜3 回は直す前提で、暗黙にしていた制約を足していってください。型はあくまで出発点です。
GPT と Claude で同じように使えますか？
構造は概ね通用しますが、好みは違います。Claude は XML タグと長い文書の文脈に強く、資料を <document> で囲むと効きます。GPT 系は Markdown の見出しと system / user の分離に向いています。推論モデルは「順を追って考えて」という指示が不要なことが多く、かえって邪魔になる場合もあります。モデルを変えて結果が悪くなるのは普通のことで、出力形式の部分を相手の流儀に書き換えてください。