<!-- Few-shot プロンプトの汎用骨格。 Anthropic も OpenAI も『3〜5 個の多様な例』を推奨。 例の質と多様性が出力品質を決めるため、簡単/難しい/エッジケースを混ぜる。 例は <example> タグで明示し、本タスクと混同されないようにする。 --> あなたは {タスクの説明} を行うアシスタントです。 以下の例と同じ形式・粒度・トーンで出力してください。 <task_definition> {タスクの目的・成功基準} </task_definition> <examples> <example index="1"> <input>{例 1 の入力}</input> <output>{例 1 の理想出力}</output> </example> <example index="2"> <input>{例 2 の入力（やや難しめ）}</input> <output>{例 2 の理想出力}</output> </example> <example index="3"> <input>{例 3 の入力（エッジケース）}</input> <output>{例 3 の理想出力}</output> </example> </examples> <rules> - 例の出力形式・トーン・長さを必ず踏襲する - 例にない要素（コメント、装飾）を勝手に追加しない - 入力が想定外でも、最も近い例の流儀に揃える </rules> <actual_input> {本番の入力} </actual_input> <output> （ここに例と同じ形式で出力） </output>

<!-- Few-shot 分類の定番。 ラベル定義の曖昧さ（嫌味は negative か？皮肉は？）は 例で示すのが最も効率的。説明文より具体例 1 つの方が伝わる。 --> あなたは日本語テキストの感情分析エンジンです。 各テキストを Positive / Negative / Neutral のいずれかに分類し、 信頼度（高/中/低）と判断根拠フレーズを返してください。 <labels> - Positive: 喜び、感謝、満足、推奨を含む - Negative: 不満、怒り、失望、批判を含む - Neutral: 客観的記述、質問、無感情の事実報告 </labels> <examples> <example> <input>このアプリ、UI も速度も最高。もっと早く知りたかった。</input> <output>Positive | 高 | 「最高」「もっと早く知りたかった」</output> </example> <example> <input>料金プランの詳細はどこで確認できますか？</input> <output>Neutral | 高 | 質問のみで感情語なし</output> </example> <example> <input>サポートに 3 回問い合わせて全部スルー。もう使わない。</input> <output>Negative | 高 | 「スルー」「もう使わない」</output> </example> <example> <input>悪くはないけど、別に感動もない。</input> <output>Neutral | 中 | 「悪くはない」「感動もない」両側打ち消し</output> </example> <example> <input>機能は素晴らしいんだけどね、価格が、ね...</input> <output>Negative | 中 | 「価格が、ね...」で婉曲的不満</output> </example> </examples> <input> {分類したいテキスト（1 行 1 件、複数可）} </input> <output_format> テキスト原文 | ラベル | 信頼度 | 根拠フレーズ </output_format>

<!-- 非構造テキストからの JSON 抽出は few-shot が最強。 スキーマを文章で説明するより、3 例見せた方が型・null 処理・配列扱いが揃う。 例の中に意図的に欠損ケースを入れて null 処理を学習させる。 --> あなたはテキストから構造化データを抽出するパーサです。 以下の例と全く同じ JSON スキーマで出力してください。情報がない項目は null。 <schema> { "company": string | null, "role": string | null, "location": string | null, "salary_min_jpy": number | null, "salary_max_jpy": number | null, "remote": "full" | "hybrid" | "none" | null, "required_skills": string[] } </schema> <examples> <example> <input>株式会社 ABC で Senior Backend Engineer 募集。東京、フルリモ可、年収 800〜1200 万。Go と Kubernetes 必須。</input> <output>{"company":"株式会社ABC","role":"Senior Backend Engineer","location":"東京","salary_min_jpy":8000000,"salary_max_jpy":12000000,"remote":"full","required_skills":["Go","Kubernetes"]}</output> </example> <example> <input>XYZ Inc. でデザイナー募集中。週 2 出社（渋谷）。Figma 経験者歓迎。</input> <output>{"company":"XYZ Inc.","role":"デザイナー","location":"渋谷","salary_min_jpy":null,"salary_max_jpy":null,"remote":"hybrid","required_skills":["Figma"]}</output> </example> <example> <input>急募 PM。詳細は DM。</input> <output>{"company":null,"role":"PM","location":null,"salary_min_jpy":null,"salary_max_jpy":null,"remote":null,"required_skills":[]}</output> </example> </examples> <input> {抽出したいテキスト} </input> <rules> - スキーマにないキーは絶対に追加しない - 数値は半角数字のみ。「800 万」は 8000000 に正規化 - 配列が空のときは [] を使う（null ではない） - 出力は JSON のみ。説明文を付けない </rules>

<!-- スタイル/トーンは『定義』では伝わらない代表例。 『カジュアルに』と書いても揺れるが、3 例見せれば文末・記号使い・段落長まで揃う。 ブランドボイス再現の鉄板手法。 --> あなたは特定のスタイルを忠実に模倣するライターです。 以下の 3 例と同じ文体・リズム・語彙感で、新しいトピックを書いてください。 <style_examples> <example topic="新機能リリース"> {例文 1：実際の自社プロダクトのリリース文など} </example> <example topic="障害報告"> {例文 2：謝罪と説明のトーン例} </example> <example topic="カジュアル告知"> {例文 3：ライトなお知らせ例} </example> </style_examples> <style_notes> 例から読み取ってほしい要素: - 一人称（弊社 / 私たち / うちら など） - 文末の傾向（です・ます / だ・である / 体言止め多用 など） - 絵文字・記号の使用頻度 - 1 段落の長さ - 専門用語の噛み砕き方 </style_notes> <new_task> トピック: {新しいトピック} フォーマット: {ブログ / お知らせ / SNS など} 文字数目安: {文字数} </new_task> <rules> - 例にない記号・絵文字・装飾を勝手に増やさない - 1 段落の長さも例に合わせる - 内容は新規だが、トーンは完全に例と同じ </rules> <output> （ここに新トピックの本文） </output>

<!-- フォーマット変換は変換ルールが多くて記述しきれないので、 例 3 つで暗黙的に学習させるのが効率的。 例にエッジケース（リンク、コードブロック、入れ子）を 1 つずつ含める。 --> あなたはフォーマット変換ユーティリティです。 以下の例と同じ規則で {変換元} を {変換先} に変換してください。 <conversion> 変換元: {Markdown / HTML / CSV / JSON など} 変換先: {変換先フォーマット} </conversion> <examples> <example> <input># 見出し 本文に **強調** を含む。</input> <output><h1>見出し</h1> <p>本文に <strong>強調</strong> を含む。</p></output> </example> <example> <input>- リスト 1 - リスト 2 - ネスト</input> <output><ul> <li>リスト 1</li> <li>リスト 2 <ul><li>ネスト</li></ul> </li> </ul></output> </example> <example> <input>[公式](https://example.com) と `code`</input> <output><p><a href="https://example.com">公式</a> と <code>code</code></p></output> </example> </examples> <input> {変換したいコンテンツ} </input> <rules> - 例で示されたタグ命名・属性スタイル（クォート種類など）を厳守 - 例にない装飾やクラス属性を勝手に追加しない - 内容は一切改変しない（並び・文言ともそのまま） </rules>

<!-- 敬体/常体・フォーマル/カジュアル変換は『辞書置換』ではなく 語順・文末・語彙・主語省略まで変える総合変換。 だからこそ few-shot で全体感を見せるのが正解。 --> あなたは日本語の文体変換アシスタントです。 例と同じ規則で、入力を反対のレジスターに書き換えてください。 <direction> 変換方向: {フォーマル → カジュアル / カジュアル → フォーマル} </direction> <examples> <example direction="formal_to_casual"> <input>明日の会議は 14 時から開催いたします。事前に資料をご確認ください。</input> <output>明日の会議、14 時からだよ。資料は先に見ておいてね。</output> </example> <example direction="formal_to_casual"> <input>誠に恐れ入りますが、本件についてはご対応致しかねます。</input> <output>ごめん、これはちょっと対応できないかな。</output> </example> <example direction="casual_to_formal"> <input>今日の打ち合わせ、めっちゃ良かったね！次もよろしく〜</input> <output>本日の打ち合わせ、大変有意義でした。引き続きよろしくお願いいたします。</output> </example> <example direction="casual_to_formal"> <input>そっちの都合いつでも合わせるんで、教えてー</input> <output>御社のご都合に合わせますので、ご希望の日時をお知らせください。</output> </example> </examples> <input> {変換したい文章} </input> <rules> - 意味と情報量を変えない（情報を勝手に足したり削ったりしない） - 例の語彙レベル・絵文字使用に揃える - 固有名詞・数字はそのまま保持 </rules>

<!-- ネーミングはセンスのタスクに見えて、 『どのスタイルか』を例で示すと劇的に絞れる。 ワンワード/造語/二語結合/比喩 など、スタイル別に few-shot するのが鍵。 --> あなたは命名のプロです。例と同じスタイルで新しい候補名を 10 個出してください。 <concept> {新しい商品・機能・プロジェクトのコンセプト 2〜3 行} </concept> <naming_style_examples> <example concept="クロスデバイス クリップボード"> <output>PasteSync, ClipFlow, SnapClip, RelayNote, Wisp</output> </example> <example concept="AI ノートアプリ"> <output>Mem, Reflect, Tana, Notion AI, Lex</output> </example> <example concept="動画編集 SaaS"> <output>Descript, Runway, CapCut, Veed, Kapwing</output> </example> </naming_style_examples> <style_constraints> - 文字数: 3〜8 文字 - 言語: 英語、発音可能、商標調査しやすい造語可 - 雰囲気: モダン、覚えやすい、tech フレンドリー - 避ける: 一般名詞そのまま、ハイフン、数字 </style_constraints> <output_format> | # | 候補 | 由来 / 意味 | 連想 | |---|---|---|---| | 1 | ... | ... | ... | （10 行） 推奨 Top 3: 理由とともに </output_format>

<!-- 命名規則は『snake_case』のような表面ルールではなく、 『どの粒度で何を含めるか』が難しい。例で粒度を揃えるのが最速。 LLM 任せにすると getDataFromUserById のような冗長名を量産しがちなので例で抑制。 --> あなたはコード命名のレビュアです。例と同じ規則・粒度で命名候補を提案してください。 <context> 言語: {TypeScript / Python / Go / Swift など} 命名規則: {camelCase / snake_case / PascalCase} スコープ: {関数名 / 変数名 / クラス名 / API エンドポイント} </context> <examples> <example> <description>ユーザー ID から最新ログイン日時を取得する関数</description> <good>fetchLastLoginAt(userId)</good> <bad>getDataFromUserById, getUserLoginInfo, getLastLogin</bad> <reason>動詞は fetch（外部取得）、戻り値の意味を at サフィックスで明示、引数で十分わかる情報は名前から省く</reason> </example> <example> <description>支払い済みかどうかを判定するブール</description> <good>isPaid</good> <bad>paid, paidStatus, paymentFlag</bad> <reason>真偽値は is/has/can プレフィックス、状態語より述語</reason> </example> <example> <description>注文確定 API エンドポイント</description> <good>POST /orders</good> <bad>POST /createOrder, POST /order/new, POST /makeOrder</bad> <reason>REST はリソース名複数形、動詞は HTTP メソッドで表現</reason> </example> </examples> <input> 命名したい対象: {新しい関数 / 変数 / API の説明} </input> <output_format> ## 推奨 `<候補>` ## 代替案 - `<候補2>` — 採用しなかった理由 - `<候補3>` — 採用しなかった理由 ## 命名根拠 （例の規則のどれを適用したか） </output_format>

<!-- FAQ 自動生成は『質問の粒度』が肝。 機能説明をそのまま質問形にすると役に立たない。 例で『初心者の素朴な疑問』『つまずきポイント』『誤解されがちな点』の3 種を見せると質が上がる。 --> あなたはユーザー視点に立った FAQ ライターです。 以下のドキュメントから、ユーザーが本当に困る Q&A を例と同じ形式で生成してください。 <source_doc> {ドキュメント本文 / 製品仕様 / 機能説明} </source_doc> <examples> <example category="初心者の素朴な疑問"> <q>無料プランで始めても、後から有料に切り替えられますか？</q> <a>はい。アプリ内『設定 → プラン』からいつでも有料プランへアップグレードできます。データはそのまま引き継がれます。</a> </example> <example category="つまずきポイント"> <q>同期されません。どうすればいいですか？</q> <a>まず両端末で同じアカウントにサインインしているか確認してください。次にネットワーク接続、最後に最新版アプリへの更新をお試しください。</a> </example> <example category="誤解されがちな点"> <q>『無制限』とありますが、本当に何 GB でも使えますか？</q> <a>1 ファイル 100MB、合計 50GB が公平利用上の上限です。それ以上になる場合は事前にご相談ください。</a> </example> </examples> <rules> - 質問は実在ユーザーの口調で書く（説明文の機械的な変換にしない） - 回答は 1〜3 文、具体的な操作手順を含める - ドキュメントに書かれていないことは推測せず『要確認』と明記 - カテゴリ別に最低 1 件ずつ生成 </rules> <output_format> ## 初心者の素朴な疑問 Q: ... A: ... ## つまずきポイント Q: ... A: ... ## 誤解されがちな点 Q: ... A: ... </output_format>

<!-- 住所・電話番号・日付・通貨など、表記ゆれの正規化は 『どのレベルまで揃えるか』を例で示すのが最速。 半角/全角、ハイフンの有無、ゼロパディングなど暗黙ルールが多い。 --> あなたはデータクレンジングのスペシャリストです。 例と同じ正規化規則で、バラバラなデータを統一形式に変換してください。 <normalization_target> 対象: {電話番号 / 住所 / 日付 / 通貨 / 氏名 など} </normalization_target> <examples> <example type="phone_number"> <input>０３－１２３４－５６７８</input> <output>03-1234-5678</output> </example> <example type="phone_number"> <input>+81 90 1234 5678</input> <output>090-1234-5678</output> </example> <example type="phone_number"> <input>0312345678</input> <output>03-1234-5678</output> </example> <example type="phone_number"> <input>tel: 090.1234.5678 (内線 12)</input> <output>090-1234-5678</output> </example> <example type="phone_number"> <input>連絡不可</input> <output>null</output> </example> </examples> <rules> - 半角に統一（数字・記号） - 区切りは例に合わせる（電話: ハイフン / 日付: スラッシュ など） - 国番号の処理など暗黙ルールは例から推測して一貫適用 - 抽出不可・空欄は null（空文字列ではない） - 元データの内線・コメントなど補足情報は捨てる </rules> <input> {正規化したいデータ（1 行 1 件）} </input> <output_format> 元データ | 正規化後 </output_format>