😉

プロンプト共有サイトの「実用メモ」＋.md仕様の大型プロンプト大全（自分用・Claude/ChatGPT両対応）

に公開
AI
プロンプト
プロンプトエンジニアリング
zennfes2025free
zennfes2025infra
idea

1. プロンプトを楽にしてくれるサイトメモ（軽い例つき）

ここはざっと思い出す用の短文メモ。各サービスの“使いどころ”＋軽いサンプルを置く。深いのは後半。

1.1 FlowGPT（共有＆即試し系）

  • 向き：アイデア収集・雛形探索。
  • コツ：キーワードで“目的→手段”に落ちたテンプレを探して、そのまま使わず自分のRAG/データ/制約を足す。
  • 軽い例：
[目的] 3Cで競合比較の素案を5分で出したい
[雛形] 「あなたは市場アナリスト。対象= {市場名}。3C（Company, Customer, Competitor）で箇条書き。各項目は事実/仮説ラベルを付与し、最後に“裏取り用の質問”を3個出す。」

1.2 PromptBase（売買系）

  • 向き：特定タスクの再現性が高いテンプレを買って、運用に組み込む。
  • コツ：購入前に出力フォーマットの適合性を確認。自分用にエラーハンドリングを足して“プロンプトSaaS化”。
  • 軽い例：
[購入後の改造パッチ]
- 出力を常にJSON: { "title": "", "bullets": [], "risks": [] }
- JSON構文エラー時: 「RETRY_ONCE」フラグを出して自己修復

1.3 AIPRM（拡張・ChatGPTに直突っ込み）

  • 向き：反復タスク（アウトライン生成、骨子比較、FAQ化）。
  • コツ：テンプレは便利だが拡張依存。業務では自前プリセットを別途保存（Notion/単純テキスト）しておく。
  • 軽い例：
[骨子比較テンプレ]
対象A={URL_A}, 対象B={URL_B}
- 構成要素を見出し階層で抽出→対応関係を表に
- 差分のうち読者価値が高いものを★マーク
- A/Bの結論に整合するデータ欠落を指摘

1.4 PromptHero（画像系も含めた見本市）

  • 向き：画像/マルチモーダルの語彙を盗む。
  • 軽い例：
[画像語彙ブースト]
スタイル: {画家/写真家/レンズ/絞り/露出/照明}
構図: 三分割, 俯瞰, 望遠圧縮
質感: フィルム粒状, シネマティック, 逆光ボケ
→ 語彙を短冊でストックしてプロンプトに差し込む

1.5 教えてAI（GMO, 国内ポータル）

  • 向き：日本語UIでカテゴリ整理済みの実用テンプレを拾う。
  • 軽い例：
[ミニテンプレ改造]
「社内文書テンプレ」に“秘匿情報の置換ルール”と“監査ログ記録の擬似指示”を付けて使う。
例: ‘{個人名}→[P#]’ ‘{顧客ID}→[CID#]’

1.6 PromptDeck（個人開発/日本コミュニティ系）

  • 向き：軽量なタグ検索→自分の棚へ保存。
  • 軽い例：
[タグ: スクレイピング禁止対応]
「Web上の記述を要約する」系は、引用ポリシーに合わせて“直接要約せず概念レベルで抽象化する”オプションを付けて運用。

1.7 Chapro（生成AIプロンプト研究所）

  • 向き：用途別ブロックをコピペ。
  • 軽い例：
[ブロック合成]
- 役割定義ブロック（Role）
- 制約ブロック（Constraints）
- 出力形式ブロック（Schema/JSON）
→ 3ブロック固定→中身だけ差し替えて再利用

1.8 Awesome Prompt系（GitHubリスト）

  • 向き：体系的カバレッジを確認。漏れチェック。
  • 軽い例：
[漏れ補完メモ]
- 評価プロンプト（self-critique）
- 安全性ガード（forbidden topics, sanitized I/O）
- 反実仮想（counterfactual prompting）

2.0 即戦力パターン（骨格テンプレ）

ここは“骨”だけ。後半に肉厚の“重プロンプト”を置く前の土台。

役割–目的–制約–入出力–採点（ROCI-S）

[Role] あなたは{ドメイン}の{役割}。対象ユーザ={ペルソナ}。
[Objective] {成果物}を{評価基準}を満たす形で作る。
[Constraints] {禁止事項}/{情報不足時の問い合わせルール}/{コスト・時間制約}
[I/O Format] 入力={要素列} → 出力は{厳密JSONスキーマ}
[Scoring] 自己採点: 0–100。70未満なら自動で1回だけ改善。

RACI型（責任分担をプロンプト内で模倣）

[Roles]
- R(実務者): 草案を作る
- A(承認者): 仕様への適合確認
- C(相談相手): リスク指摘
- I(共有先): サマリを書く
→ 4人の“声”を順番に出し、最後に合意版を提示

反実仮想（Counterfactual Prompting）

[Task] 反対仮説も成立する条件を列挙→各条件を潰す追加調査案を出す
[Guard] バイアス告白を必ず含める

批判者チェーン（Red Team → Blue Team）

Step1(Blue): 解答案を出す
Step2(Red): 論理の穴/データ不足/危険な仮定を3点以上指摘
Step3(Blue): 指摘を踏まえて改稿

2. 運用方針（Anthropic流.md仕様の自分ルール）

  • 役割・目的・出力仕様・検証・失敗時挙動を1つの.mdに明文化して投げる。
  • 思考の可視化禁止を明記し、I/O固定、再現テスト、1回だけ自動改善を標準化。

骨格テンプレ（自分用）

[Role] {役割} / [Objective] {成果} / [Constraints] {制約}
[Inputs] {与件}
[Output] {JSON or Markdownの厳密仕様}
[Self-check] スコアと改善ルール
[Failure] 不足情報の問い合わせ出力

3. 実用“重め”プロンプト大全（大量・.md完全指定）

3.1 PRDドラフト.md（MVP/2スプリント/法務準拠）

# role
シニアPM。ビジネス要件を MVP（2スプリント）の PRD に落とす。思考過程は出力しない。

# objective
価値仮説→ユーザストーリー→FR/NFR→データ契約→リスク→KPI→法務チェックを一貫整形。

# inputs
PRODUCT={{PRODUCT}}
PERSONA={{PERSONA}}
VALUE_HYPOTHESIS={{VALUE_HYPOTHESIS}}
DEADLINE={{DATE}}, BUDGET={{BUDGET}}, COMPLIANCE={{規格/法令}}

# output_json
{
 "context": {"product":"","persona":"","problem":"","value_hypothesis":""},
 "user_stories":[{"id":"US1","as":"","i_want":"","so_that":"","acceptance":[""]}],
 "functional_requirements":[{"id":"FR1","desc":"","priority":"MUST|SHOULD|COULD"}],
 "non_functional":[{"type":"Security|Performance|Privacy|Reliability","criteria":""}],
 "data_contracts":[{"entity":"","schema":{"":""},"pii":true}],
 "risk_register":[{"risk":"","mitigation":"","owner":""}],
 "metrics":{"north_star":"","input_metrics":[""]},
 "legal_check":[{"topic":"","status":"OK|TBD","note":""}],
 "score":0
}

# self_check
JSON妥当性/US→FRの対応/NFR≥3/法務TBD最小化。score<70なら一度だけ自動改善し、"improved_from":"v1" を付記。

# failure_mode
不足情報は "ask_user": ["具体質問..."] を最上部に付ける。

3.2 API仕様.md（互換性/エラーモデル厳格）

# role
APIアーキ。HTTP/JSON APIを互換性保証付きで定義。内部思考は出さない。

# objective
ユースケース→最小エンドポイント集合、エラーモデル、バージョニング、Auth/RateLimit/監査を定義。

# inputs
USE_CASES={{箇条書き}}, ENTITIES={{主要エンティティ}}, COMPAT_POLICY={{SemVer/非破壊/廃止告知90日}}

# output_markdown
## Endpoints
- GET /v1/{{resource}}?q=
- POST /v1/{{resource}}
## RequestSchema(JSON)
{ "type":"object","properties":{...},"required":[...] }
## ResponseSchema(JSON)
{ "type":"object","properties":{...},"required":[...] }
## ErrorModel
code,http,message,retryable,client_action（表形式で列挙）
## Security
Auth={{Auth方式}}, Scopes=..., RateLimit=..., AuditLog=...
## Compatibility
Breaking時は並行提供→Deprecationヘッダ→移行ガイド→停止

## Samples
リクエスト例とレスポンス例を具体値で1本ずつ。

## score
0-100（<75なら一度だけ差分を明示して再出力）

3.3 コード改修計画.md（影響範囲/ロールバック/観測KPI）

# role
シニアSWE。安全に壊さず変更計画を作る。

# inputs
REPO={{構成/主要モジュールメモ}}, GOAL={{目的}}, DEADLINE={{期日}}

# output_json
{
 "impact_map":[{"module":"","dep_on":"","risk":"low|med|high","reason":""}],
 "change_steps":[{"step":1,"action":"","owner":"","rollback":""}],
 "tests":{"unit":[""],"integration":[""],"contract":[""]},
 "observability":{"metrics":[""],"alerts":[""],"logs":[""]},
 "signoff":{"criteria":[""],"owners":[""]},
 "score":0
}

# self_check
highリスクには必ずrollback案。観測KPIは実装可能な粒度。score<80で一度だけ改善。

3.4 E2Eテスト設計.md（US→自動化骨子）

# role
QAリード。ユーザストーリーからE2Eを設計。

# inputs
USER_STORIES={{US群}}, MASK_RULES={{データマスキング規則}}

# output_markdown
## シナリオ表
ID/目的/前提/手順/期待結果/自動化候補
## データ生成
マスキング規則の適用手順
## 自動化骨子
主要フロー1本の擬似コード（Cypress/Playwright想定）

## score
0-100（ハッピーパス/バッドパス網羅、外部APIモック方針があること）

3.5 競合差分抽出.md（重み×差分KPI）

# role
PM。A/B/Cの機能差分から短期で勝てる差分を出す。

# inputs
A={{A_NOTE}}, B={{B_NOTE}}, C={{C_NOTE}}, PERSONA={{対象}}, WEIGHTS_GUIDE={{重み付け基準}}

# output_markdown
## 機能対応表
機能 / A / B / C / 重み(1-5) / 注記
## 差分アクション（2スプリント以内）
- タスク / 実装案 / KPI / 効果仮説
## リスク&ブロッカー
法務/セキュリティ/依存
## score
0-100（KPIが計測可能表現であること）

3.6 ドキュ正規化.md（語調/用語統一/逸脱ログ）

# role
テクニカルエディタ。敬体/常体/用語を正規化。

# inputs
TEXT={{本文}}, STYLE={{敬体|常体}}, JIS_PREF={{有|無}}

# output_markdown
## 正規化本文
（本文）
## 用語表
原語 / 正規語 / 備考
## 逸脱ログ
箇所 / 修正理由 / 判断根拠
## score
0-100（体裁ルール逸脱が残っていない）

3.7 研究エージェント.md（収集→反証→確度）

# role
研究用エージェント。収集→反証→確度で構造化。思考は出さない。

# inputs
TOPIC={{テーマ}}, SOURCE_POLICY={{一次/二次/三次の区分方針}}

# output_markdown
## スコープ
含む/含まない
## トピック分解（MECE）
...
## 収集メモ（構造化）
主張 / 根拠 / 種別(一次/二次/三次) / 信頼度(0-1) / 要検証
## 反証・限界（Red Team）
最低3点
## 結論（確度ラベル）
高/中/低
## 参照
BibTeX または APA

## score
0-100（反証≥3）

3.8 要件→SQL→意思決定.md

# role
アナリティクス。定義→SQL→可視化→判断文。

# inputs
QUESTION={{問い}}, DWH={{BQ/RS/duckdb}}, SCHEMA_SNIPPET={{テーブル/カラム要約}}

# output_markdown
## 定義
指標/粒度/期間/除外
## SQL
（CTE中心で読みやすく）
## 可視化案
チャート種/軸/集約
## 読み取り
所見/反事例/限界
## 意思決定文
Do / Don’t / Need more（各1行）
## score
0-100（SQLが構文的に妥当）

3.9 LPコピー3型.md（王道/尖り/奇抜）

# role
コピーライタ。A/B/Cの3型を同時出力。

# inputs
PRODUCT={{商材}}, INSIGHT={{洞察}}, TONE={{トーン}}

# output_markdown
## A: 王道
見出し / 補足 / CTA
## B: 尖り
...
## C: 奇抜
...
## 先回りFAQ（買わない理由TOP5）
...
## score
0-100（3型の差が明確）

3.10 反論処理ライブラリ.md（意図→回答→逆質問）

# role
B2Bセールス。反論の意図→回答→検証を構造化。

# inputs
PRODUCT={{製品}}, RANGE={{価格帯}}, OBJECTIONS={{典型反論列挙}}

# output_json
{
 "objections":[
   {"id":"O1","intent":"","replies":[{"short":"","long":""}],"evidence":[""],"test_question":""}
 ],
 "bridge_to_next":["デモ","試用","ROI試算"],
 "score":0
}
# self_check
intent が心理の言い換えになっているか。score<80で一度だけ改善。

3.11 セキュリティレビュー.md（STRIDE→承認）

# role
セキュリティアーキ。変更に伴う脅威→対策→承認。

# inputs
CHANGE={{変更}}, DATA={{PII/保存/移送}}, REGULATIONS={{ISO/ISMS/個情法 等}}

# output_markdown
## データフロー（テキスト）
エンティティ/移送/保存
## 脅威モデリング（STRIDE）
要素 / 脅威 / 影響 / 対策 / 残余
## ログ/鍵/監査
...
## 承認フロー
オーナ/合意条件
## score
0-100（STRIDEの空欄なし）

3.12 翻訳＋用語固定.md（置換ログ/曖昧照会）

# role
技術翻訳。用語表固定＋置換ログ＋曖昧照会。

# inputs
EN_TEXT={{原文}}, GLOSSARY_JSON={{用語表JSON}}, STYLE=簡潔

# output_markdown
## 訳文
...
## 置換ログ
原語 / 訳語 / 根拠
## 曖昧箇所（要照会）
行/語/理由/候補
## score
0-100（用語表未適用なし）

3.13 SERP構造化.md（意図分岐→不足充填）

# role
SEOストラテジスト。意図分岐→情報構造→不足充填。

# inputs
KEYWORD={{KW}}, GOAL=欠損ゼロ/更新容易

# output_markdown
## 意図分岐
Do/Know/Navigate...
## 情報構造（H2/H3）
骨子＋必要データ
## 差別化
一次情報/実験/図表
## 運用
KPI/更新頻度/役割
## score
0-100（H2/H3重複なし）

3.14 要約→未回答抽出.md（再読候補）

# role
読書支援。要約→重要質問→未回答→再読。

# inputs
LONG_TEXT={{本文}}

# output_markdown
## 300字要約
...
## 重要質問Top10（答え有/無/位置）
...
## 再読候補
該当段落見当 / 何が足りないか
## score
0-100（“答え無”≥3）

3.15 プロンプトSaaS化.md（検証ケース/半減期）

# role
プロンプト作者。製品化（SaaS）を前提に仕様化。

# inputs
TASK={{タスク}}, MODELS={{対応モデル}}, UPDATE=週次|隔週

# output_markdown
## 実行I/O仕様
必須入力項目/型/例、出力JSONスキーマ
## 検証ケース（≥5）
ID/入力/期待出力/合否判定
## 半減期ポリシー
モデル更新時の再検証/互換維持
## 失敗時挙動
リトライ1回/縮退モード/エラー文
## score
0-100

3.16 RAG設計コンサル.md（与件→設計→評価）

# role
RAGコンサル。与件→設計→評価を明文化。

# inputs
DOC_TYPES={{コーパス種}}, CONSTRAINTS={{LATENCY/COST/PRIVACY}}

# output_markdown
## 要件
品質/K/RTT/コスト
## 設計
Chunk/Overlap/Embedding/Index/Retriever/Reader
## 防御
ガードレール/引用/信頼スコア
## 評価
ゴールドセット/Exact/Partial/Attribution
## 運用
再埋め込み/ドリフト検知
## score
0-100（各設定に根拠）

3.17 エージェント計画.md（ツール宣言→失敗時挙動）

# role
エージェント設計。ツール群/手順/失敗時挙動を定義。思考は出さない。

# inputs
GOAL={{目的}}, TOOLS={{関数/ブラウザ/DB等}}, LIMITS={{COST/TIME/PRIVACY}}

# output_markdown
## ツール宣言
tool名 / 入力 / 出力 / 失敗コード
## 手順（擬似フロー）
1) 入力検証 → 2) tool_a → 3) 失敗時バックオフ → 4) 収束判定
## ガード
PII処理/レート制限/監査ログ
## 結果形式(JSON)
{"status":"ok|fail","data":{...},"trace_id":""}
## score
0-100（失敗コードを全列挙）

Discussion