<!-- Anthropic の Prompt Improver と同じ発想。 改善前に必ず『何が弱点か』を言語化させる。 書き換えだけ返すと書き手は理由を学べず、次の自作プロンプトに反映できない。 --> あなたはプロンプトエンジニアリングの専門家です。 次のユーザープロンプトを診断し、構造化された改善版を提示してください。 <original_prompt> {プロンプト原文} </original_prompt> <intent_if_known> このプロンプトの目的: {例：議事録から ToDo を抽出させたい} 想定モデル: {例：Claude / GPT / 他} 用途: {例：単発実行 / 業務システムに組み込み} </intent_if_known> <diagnostic_axes> 以下 8 軸で診断。各軸に『現状』『問題点』『改善方向』を書く。 1. 役割の明確さ: AI に与える役割が具体的か 2. タスク定義: 何を達成すべきかが一文で言えるか 3. 入力の構造化: 入力の境界（タグ / 区切り）があるか 4. 出力フォーマット: 構造 / 長さ / 言語が指定されているか 5. 制約と禁止事項: やってほしくないことが明示されているか 6. 例（few-shot）: 良い出力例 / 悪い例があるか 7. 推論誘導: CoT / Self-check が必要なら誘導があるか 8. 失敗時挙動: 不明 / 情報不足時に何をすべきか定義されているか </diagnostic_axes> <output> 1. 診断表（8 軸 × 現状 / 問題 / 方向） 2. 改善版プロンプト（v1: 最小修正） 3. 改善版プロンプト（v2: 構造化を強化） 4. v1 / v2 の使い分け指針 5. 改善で追加した要素一覧（理由付き） </output> <rules> - 元プロンプトの意図を変えない。スコープ拡張はしない - 改善で『なぜそう変えたか』を全要素に添える - 過剰に長くしない。最小編集で効果が出る案を v1 として提示 </rules> <output_format> ## 診断表 ## 改善版 v1（最小修正） ## 改善版 v2（構造化強化） ## 使い分け ## 学びの要約（次回自分で書くとき気をつけるべき 3 点） </output_format>

<!-- 曖昧なプロンプトの典型は『〜について教えて』。 誰向けに / どの粒度で / 何文字で / 何のために / どう使うか が抜けている。 メタプロンプトとして、AI に『不足情報を質問する』ではなく『勝手に妥当な前提を置いて具体化する』方を選べる柔軟性を持たせる。 --> あなたは曖昧なプロンプトを実用的なプロンプトに書き換える専門家です。 次の曖昧プロンプトを、5W1H と成功条件を補完して具体化してください。 <vague_prompt> {曖昧なプロンプト原文} </vague_prompt> <process> 1. 曖昧度の診断: どの 5W1H 要素が欠けているか箇条書き 2. 不足情報の補完: 各欠落要素に『最も妥当な仮置き』を 1 案、『代替案』を 1 案 3. 成功条件の言語化: この出力が良いと言える条件を 3 つ 4. 具体化版プロンプト v1: 仮置きをすべて採用した完全版 5. 具体化版プロンプト v2: ユーザーに最小限の追加情報を尋ねる形（埋めるべき変数を {} で残す） </process> <5w1h_template> - Who（誰向け / AI の役割） - What（何を出すか / 形式） - When（時制 / 期限 / 鮮度） - Where（使う場所 / 文脈） - Why（目的 / 成功条件） - How（粒度 / 長さ / 言語 / トーン） </5w1h_template> <rules> - 仮置きは『大半のユーザーがそうするであろう』妥当な値 - 元の意図を超えた機能追加はしない - v1 と v2 で何が違うかを 1 行で説明 </rules> <output_format> ## 曖昧度診断 ## 不足要素と補完案 ## 成功条件 3 つ ## 具体化版 v1（仮置き全採用） ## 具体化版 v2（変数化） </output_format>

<!-- プロンプトを変えていないのに品質が落ちる原因は主に: ①モデル更新による挙動変化 ②入力の長さ・性質変化 ③コンテキスト窓の汚れ ④プロンプトインジェクションの干渉 ⑤たまたまの確率的ブレ。 原因切り分けのチェックリストを順に試させる。 --> あなたは LLM 出力品質のデバッガーです。 以下の情報から、出力悪化の原因と対処を診断してください。 <prompt> {現在使っているプロンプト} </prompt> <sample_outputs> 良かったころの出力例: {例 1〜2 個} 最近の悪い出力例: {例 1〜2 個} </sample_outputs> <environment_changes> 気づいた変化: {例：モデルバージョンを 4 から 4.5 にした / 入力データを長くした / 別チームが同じプロンプトを使い始めた} </environment_changes> <diagnostic_checklist> 以下を順に検討し『該当 / 非該当 / 不明』『証拠』『対処』を書く。 1. モデル更新: 使用モデルが最近変わったか / プロバイダの挙動変更があったか 2. 入力長の増加: コンテキスト後半に重要情報が来ていないか（lost in the middle） 3. 入力性質の変化: 想定外のフォーマット・言語・長さの入力が増えた 4. プロンプトインジェクション: ユーザー入力に指示文が混ざって上書きされている 5. 出力フォーマット崩れ: 求めるフォーマットの記述が弱い 6. 確率的ブレ: temperature 設定 / 単発でのバラつき 7. システムプロンプト汚染: 履歴・前ターンの影響が残っている 8. 評価基準のずれ: 実は AI 出力ではなく評価側が変わった </diagnostic_checklist> <remediation> - 各仮説に対する『最小コストの再現実験』を 1 つずつ - 推奨対処（短期 / 中期） - 再発防止: 出力品質モニタリングの簡易仕組み 1 案 </remediation> <output_format> ## 診断表（8 仮説） ## 最有力の原因 ## 短期対処（24 時間以内） ## 中期対処（プロンプト改修案） ## モニタリング案 </output_format>

<!-- 同じ目的でも、CoT で誘導するか / few-shot で示すか / ロール定義を厚くするか で出力傾向が変わる。 本番投入前に複数案を作り、評価データで比較するのがプロの手順。 --> あなたはプロンプト A/B テストの設計者です。 次の目的に対し、設計思想の違う 3 案を作ってください。 <goal> 達成したいタスク: {例：顧客レビューを 5 段階感情分類する} 入力例: {1〜2 サンプル} 期待する出力例: {1〜2 サンプル} 本番想定: {例：1 日 1000 件、コスト重視} </goal> <three_variants> ### Variant A: シンプル指示型 - 短く明確な命令文 + 最小制約 - 出力フォーマットを 1 行で指定 - few-shot なし ### Variant B: Few-shot 例示型 - 役割定義 + 入出力例 3 組 - 例から暗黙にフォーマットを学ばせる - 制約は最小限 ### Variant C: 構造化 + CoT 型 - 役割 / タスク / 入力 / 推論手順 / 出力フォーマット を XML タグで構造化 - 中間思考を出力させる - 厳しい制約と禁止事項 </three_variants> <comparison> 3 案を以下の観点で比較表にする: - 出力品質の予想（高 / 中 / 低） - トークン使用量 - 入力バリエーションへのロバストさ - 保守のしやすさ（変更コスト） - 期待される失敗モード </comparison> <test_plan> - 評価データ 20 件で各 Variant を試す手順 - 評価指標 2〜3 個（精度 / 出力フォーマット遵守率 / コスト） - 勝者選定基準 </test_plan> <output_format> ## Variant A / B / C 全文 ## 比較表 ## テスト計画 ## 私の推奨と理由 </output_format>

<!-- プロダクションで使うプロンプトはコードと同じ。 バージョン番号 / 変更理由 / リスク / ロールバック手順を残さないと、後で『なぜこうなった』が分からない。 セマンティックバージョニング（major.minor.patch）を流用するのが現実的。 --> あなたはプロンプトのバージョン管理を担当する保守者です。 次の差分から changelog エントリを作ってください。 <previous_prompt> {旧プロンプト全文} バージョン: {例：v1.3.0} </previous_prompt> <new_prompt> {新プロンプト全文} </new_prompt> <change_context> 変更の動機: {例：誤分類が増えたため} 影響範囲: {例：本番の感情分類バッチ全件} 検証状況: {例：評価データ 50 件で精度 +6pt} </change_context> <changelog_entry> セマンティックバージョニング基準: - major: 入出力契約が変わる / 既存呼び出し側の改修必須 - minor: 機能追加 / 互換性維持 - patch: 文言修正 / バグ修正 / 性能調整 以下のフォーマットで出力: - バージョン番号と日付 - 種別（major / minor / patch） - 変更サマリ（1 行） - 詳細変更点（追加 / 変更 / 削除） - 動機 - リスク - ロールバック手順 - 評価結果（A/B 比較数値があれば） </changelog_entry> <rules> - 変更が複数あれば追加 / 変更 / 削除でグルーピング - リスクには『最悪何が起きるか』を 1 行 - ロールバックは『どのファイルのどの値を戻すか』レベルで具体的に </rules> <output_format> ## 提案バージョン番号と種別判定理由 ## CHANGELOG.md エントリ（コピペ可形式） ## ロールバック手順 ## 次バージョンで予定すべき改善 </output_format>

<!-- 動いているプロンプトはコメントなしの呪文になりがち。 新メンバーや 3 ヶ月後の自分が読むことを前提に、 『目的 / 入力 / 出力 / 注意 / 既知の失敗 / 改修履歴』を分けて書く。 --> あなたはプロンプトのテクニカルライターです。 次の運用プロンプトを社内ドキュメント形式に整理してください。 <prompt> {プロンプト本文} </prompt> <context> 用途: {例：問い合わせ自動分類} 呼び出し場所: {例：Slack の #cs チャネルから} 運用開始: {例：2026 年 2 月} 現バージョン: {例：v1.4.2} </context> <doc_sections> 1. プロンプトの目的（1 文 + 詳細 3 行） 2. 入力仕様（必須 / 任意フィールド、形式、長さ上限） 3. 出力仕様（フォーマット、フィールド説明） 4. 使用モデルと推奨パラメータ（temperature 等） 5. 動作の前提（どんな入力なら期待通りか） 6. 既知の失敗モード（こういう入力で壊れる、対処） 7. 直近の変更履歴（最新 3 件） 8. オーナー / 連絡先 9. 参考リンク（評価データ、関連ドキュメント） 10. 「初めてこのプロンプトを触る人へ」5 行メモ </doc_sections> <rules> - 5 分で全体像が掴めるよう、最初に TL;DR を置く - 内部用語は初出時に補足 - プロンプト全文は最後にまとめて掲載（読み手は仕様→詳細の順で見る） - 機密情報や具体的な顧客データは含めない </rules> <output_format> ## TL;DR（3 行） ## 各セクション本文 ## プロンプト全文（最後に転載） </output_format>

<!-- 『プロンプトを書くのが面倒』というのが最大の参入障壁。 Anthropic Console の Prompt Generator と同じ発想で、 達成したいゴールを口頭レベルで伝えるだけで、整った初版プロンプトを返す。 細かい設定は後から詰められるよう、変数化と注釈を残す。 --> あなたはプロンプトの初版作成を代行するアシスタントです。 ユーザーが下のように『やりたいこと』をラフに書きます。 そこから本番投入できる初版プロンプトを生成してください。 <user_goal> やりたいこと: {例：ミーティングの文字起こしから ToDo と決定事項を抽出したい} 誰が使うか: {例：自分だけ / チーム / 社外公開} 入力データの例: {例：1 時間の文字起こしテキスト} 望む出力イメージ: {例：ToDo は担当者と期限つきで箇条書き} 避けたいこと: {例：要約しすぎて細部が消える} </user_goal> <generation_process> 1. ゴールの再解釈（あなたが理解した 1 文） 2. 必要な要素の特定（役割 / タスク / 入力 / 出力 / 制約 / few-shot 要否） 3. 初版プロンプト生成（変数は {} で残す） 4. 注釈ブロック（HTML コメント）でなぜその構造にしたかを説明 5. 推奨モデル / パラメータ 6. 試運転入力例 1 つと、期待される出力 7. 改善余地（次に追加すると効くもの） </generation_process> <rules> - 質問は最大 3 つまで、『これがないと書けない』ものに絞る - 質問なしで書けるならそのまま生成（仮置きを明示） - 出力フォーマットを必ず指定する - 過剰に長いプロンプトを生成しない（実用最小） </rules> <output_format> ## 私が理解したゴール ## 追加で聞きたいこと（あれば最大 3 つ） ## 初版プロンプト（コピペ可） ## 注釈（設計判断） ## 推奨モデル / パラメータ ## 試運転入力 → 期待出力サンプル ## 次の改善候補 </output_format>

<!-- うまくいかない理由は『プロンプトが悪い』とは限らない。 タスク自体が LLM の苦手領域（厳密な計算 / 最新情報 / 多段ツール呼び出し）の場合、 どれだけ書き直しても解決しない。原因を分けて切り分けるのが先。 --> あなたはプロンプトと LLM 能力の両面に詳しい診断医です。 次のケースを 3 軸で切り分けて診断してください。 <case> プロンプト: {プロンプト本文} 入力例: {1〜2 件} 期待していた出力: {} 実際の出力: {} 試した変更: {あれば} </case> <three_axes> ### 軸 1: プロンプト品質 - 役割 / タスク / 入力 / 出力 / 制約 / 例示 のどこが弱いか - 改善余地: 高 / 中 / 低 ### 軸 2: タスク本質的難しさ - このタスクは LLM が原理的に苦手か？ - 苦手要素: 厳密計算 / 長文一貫性 / 最新情報 / 多段推論 / ツール必要 / 主観評価 など - LLM 単体で達成可能か: 可 / 厳しい / 不可 ### 軸 3: モデル / 環境 - 使用モデルがこのタスクに適しているか - コンテキスト長の制約に引っかかっているか - temperature や top-p の設定問題 - 別モデルへの切替が効くか </three_axes> <recommendations> 切り分け結果から推奨アクションを優先度付きで: - 軸 1 が主因なら: プロンプト改善案 v1 を提示 - 軸 2 が主因なら: タスクを分割するか、外部ツール連携 / RAG / コード実行など別アーキを提案 - 軸 3 が主因なら: モデル変更 / パラメータ調整の具体案 </recommendations> <rules> - 1 つの軸に決めつけず、複合要因の場合は寄与度（高 / 中 / 低）で示す - 『プロンプトが悪いです』で終わらせず、具体的に何が悪いかまで - 軸 2 が決定的なら『そもそもこのタスクを LLM だけで解くのを諦める』選択肢も提示 </rules> <output_format> ## 軸 1 診断（プロンプト品質） ## 軸 2 診断（タスク難度） ## 軸 3 診断（モデル / 環境） ## 主因の判定と寄与度 ## 推奨アクション（優先度順） ## それでもダメな時の代替アーキ </output_format>