AIを職業のプロに変えるプロンプト8選

「AIに聞いても、当たり障りのない一般論しか返ってこない」。

そう感じるとき、足りていないのは質問の細かさではなく、AIに渡す肩書きのほうです。

役割を1行足すだけで返事の中身が変わる、というのを350本分そろえた場所があります。

なぜ職業を指定するだけでAIの回答が変わるのか

GitHubの ai-boost/awesome-prompts というリポジトリです。

8,600を超えるスターが付いていて、prompts フォルダには350本以上のプロンプトが並んでいます。

更新も今なお続いています。

GitHub - ai-boost/awesome-prompts: Curated list of chatgpt prompts from the top-rated GPTs in the GPTs Store. Prompt Engineering, prompt attack & prompt protect. Advanced Prompt Engineering papers.

Curated list of chatgpt prompts from the top-rated GPTs in the GPTs Store. Prompt Engineering, prompt attack & prompt protect. Advanced Prompt Engineering papers. - ai-boost/awesome-prompts

github.com

中身はSREやクラウド設計といった技術職から、プロダクトマネージャー、法務、学術論文、ゲーム設計、翻訳まで20以上のカテゴリに広がっています。

プロンプトエンジニアリングの論文やフレームワークも同じ場所にまとまっていて、職業別のプロンプトはその実践編にあたります。

面白いのは、どれも「〜の専門家として振る舞ってください」の1行で終わっていないことです。

その職業が普段使っている判断基準、チェック項目、報告の型まで全部書き込んであります。

たとえば「この資料をレビューして」とだけ頼むと、AIは何を見ればいいか決めかねて、褒めと軽い指摘が混ざった無難な返事をよこします。

ところが論文校正者のプロンプトを渡すと、根拠のない断定、本文と表の数字の食い違い、本文から一度も参照されていない図、といった観点が最初から立ち上がる。

同じモデルなのに、見ている場所が変わるんです。

ここからは、非エンジニアの会社員がそのまま業務に流用できる8本を紹介します。

元ファイルは英語でかなりの分量があるので、核だけを日本語に落としたものを載せます。

ChatGPTでもClaudeでも、会話の冒頭に貼るだけです。

トラブル対応や危機管理の判断力が欲しいとき

1. インシデント指揮官 トラブルの深刻度を4段階で仕分ける

incident_response_commander.md は、システム障害の現場を仕切る指揮官の役割です。

障害をSEV1からSEV4の4段階に分けて、それぞれ何分以内に反応し、何分おきに誰へ報告するかまで決めてあります。

SEV1は全面停止やデータ消失のおそれがある状態で、5分以内に動いて15分おきに更新。

SEV2は25%を超えるユーザーに影響が出ている状態で、15分以内に反応して30分おきに更新です。

トラブルのたびに「これ、上に報告すべきなんだろうか」で消耗している人には、この物差しがそのまま効きます。

あなたはインシデント対応の指揮官です。
私が報告する状況をSEV1からSEV4の4段階で分類し、次を出してください。
1. 深刻度とその判断根拠
2. 誰にいつ何を報告するか。更新の間隔も決める
3. 今すぐ確認すべきこと3点
4. 収束後に書く振り返り文書の見出し案
原因は個人のミスではなく、仕組みの穴として書いてください。

元のプロンプトは振り返り文書の型まで用意していて、原因を「なぜ」で5回掘り下げる形式と、犯人探しをしない書き方を明示しています。

障害報告書を書かされる立場なら、ここだけ切り出しても価値があります。

2. 信頼性エンジニア 感覚の議論を数字に引き戻す

sre.md の考え方は、非エンジニアの現場にこそ刺さります。

中心にあるのはエラーバジェットという発想で、失敗をゼロにするのではなく、許容できる失敗の量を先に決めて、使い切ったら改善に振るというものです。

「気をつけます」で終わる会議を止めたいとき、この役割を呼び出してください。

あなたは信頼性エンジニアです。
私が抱えている業務の問題について、次の順で答えてください。
1. この業務で守るべき水準を数値で定義する。例 月次の差し戻し率3%以内
2. その水準をどう測るか。今データがないなら何を記録し始めるか
3. 許容できる失敗の量を使い切ったとき、何を止めて改善に回すか
4. 人が繰り返している手作業のうち、自動化すべきものを優先度順に
根性論や「注意する」で終わる対策は書かないでください。

元ファイルは「測ってから最適化する」「手作業は自動化する。根性で乗り切らない」を原則に掲げています。

精神論に逃げない相談相手が1人増える感覚です。

会議や意思決定の質を上げたいとき

3. プロダクトマネージャー 作らないものを先に決める

product_manager.md は経験10年以上のPMという設定で、性格がはっきりしています。

持ち込まれた要望をそのまま受けず、まず「なぜ」を3回聞く。

要件書を書く前に、その企画のプレスリリースを1段落で書けるか試す。

そしてロードマップには必ず「今回やらないこと」を書く。

あなたは経験10年のプロダクトマネージャーです。
私が持ち込む企画に対して、いきなり手段の話をせず次を返してください。
1. 解こうとしている問題は何か。そう言える根拠
2. 今回やらないことを3つ
3. 成功をどの数字で測るか。現在値と目標値
4. 届く人数 影響度 確信度 工数 の4項目で優先度スコア
5. 8週間後にこれが失敗したとしたら、理由は何か

5番目は元プロンプトにある手法で、着手前に「8週間後、これは失敗した。なぜか」を全部出させます。

企画会議の前日に1人でやっておくと、当日いちばん鋭い指摘をする人になれます。

4. スクラムマスター 振り返りを愚痴で終わらせない

scrum_master.txt の本体は、振り返りの進行役です。

意見を出させるだけでなく、それを「チームで直せること」と「組織に上げること」に仕分けて、前者は48時間以内、後者は1週間以内という期限まで置いています。

あなたはスクラムマスターです。この振り返りを進行してください。
1. 形式は 続けること やめること 始めること の3分類で
2. 出た意見をチームで直せることと組織に上げることに仕分ける
3. チーム側は48時間以内、組織側は1週間以内の期限で、担当者名を必ず付ける
4. 誰かの努力不足を原因にする書き方はしない
最後に 状況 観察 提案 成功条件 期限 の5項目で要約してください。

元ファイルには「速度が安定しないなら、原因は努力量ではなく見積もりかスコープだ」という一文があります。

これ、開発現場に限らず刺さる指摘だと思うんですよね。

部下や顧客との対話に自信を持ちたいとき

5. 臨床アシスタント 相手の言い分と事実を分けて書く

clinical_assistant.txt は医師のカルテ作成を助けるプロンプトで、SOAPという記録形式を使います。

Sは患者が話したこと、Oは検査値や所見のような観測できる事実、Aはそこからの評価、Pは次にやることです。

この4分割、1on1やクレーム対応の記録にそのまま転用できます。

「言われたこと」と「確かめた事実」がごちゃ混ぜのメモが、あとでいちばん揉めるので。

これから話す内容をSOAP形式で整理してください。
S 相手が言ったこと。発言をそのまま。解釈を混ぜない
O 観測できた事実。日付 数値 提出物など確認できるものだけ
A そこから読み取れる評価。確信が持てない部分は明示する
P 次にやること。担当と期限つき
SとOを混ぜないでください。情報が足りない箇所は不明と書いてください。

元ファイル自体が「これは医療者を補助するもので、臨床判断を置き換えるものではない」と繰り返し断っています。

AIの出力を人が確認してから使う、という前提は業務でも変わりません。

6. カスタマーサポート 共感 事実 解決の順で返信する

customer_support_agent.txt の芯は、FEEL FACT FIXという返信の型です。

まず相手の状況を認め、次に何が起きたかの事実を書き、最後にこれからやることを書く。

順番を入れ替えると印象が崩れます。

あなたはカスタマーサポートの担当者です。
この問い合わせへの返信を FEEL FACT FIX の順で書いてください。
FEEL 相手の状況を認める一文。謝罪を並べない
FACT 何が起きていたかの事実
FIX これからやること。担当と期限を明示
相手の怒りにではなく、緊急度にトーンを合わせてください。
返金や非の認定など、私の権限を超える約束は書かないでください。
最後に 解決した内容の要約 他に困っていることの確認 お礼 の3つで締めてください。

「相手の怒りではなく緊急度に合わせる」は元プロンプトに書かれている指示です。

怒っている人につられて過剰に謝る返信を、AI側が止めてくれます。

資料や文章の完成度を上げたいとき

7. 論文校正者 提案だけさせて修正はあとから承認する

research_paper_proofreader.txt は作りがよくできていて、2段階に分かれています。

第1段階では一切直さず、問題点を全部並べるだけ。

こちらが承認して初めて、第2段階で修正に入ります。

指摘には深刻度が付きます。

出せないレベル、意味が変わるレベル、表記レベル、好みの範囲の4段階です。

この資料をレビューしてください。ただし今は修正せず、指摘だけ出してください。
各指摘に次を付けてください。
・深刻度 出せない 意味が変わる 表記 好みの範囲 の4段階
・該当箇所の引用
・なぜ問題か
特に次を見てください。
1. 根拠のない断定や言いすぎ
2. 本文の数字と表 図の数字が食い違っていないか
3. 本文から一度も参照されていない図表
私が深刻なものだけ直してと言ったら、そこだけ修正してください。

勝手に全部書き換えられて自分の文章じゃなくなる、というAI校正のいちばん嫌なところが、この2段階で消えます。

8. テクニカルライター 読み手のレベルを先に宣言させる

technical_writer.txt が最初にやらせるのは、書き直しではなく読み手の特定です。

初級、中級、上級のどれ向けかを宣言してから書き始める。

ここを飛ばすと、専門用語が中途半端に混ざった文章ができあがります。

あなたはテクニカルライターです。
この文章を書き直す前に、想定読者を 初級 中級 上級 のどれかで宣言してください。
そのうえで次のルールで書き直してください。
・受動態をやめて、誰が何をするかを主語にする
・「簡単に」「単に」といった埋め草を消す
・手順の一文は短く。説明の一文も長くしすぎない
・断定できないことは曖昧にせず、確認が必要と明示する
何を変えたかを先に列挙してから、書き直した本文を出してください。

「簡単に」「単に」を禁止語にしているのは元ファイルの指定です。

読み手が詰まったときにいちばん腹が立つ言葉だからで、社内マニュアルにもそのまま当てはまります。

8つを自分の業務用にカスタマイズするコツ

元のファイルは英語で、長いものだと1本で1万字を超えます。

全部コピーして貼る必要はありません。

効くのは核の部分だけです。

いじる場所は3つに絞ってください。

1. 数値の基準を自分の現場に合わせる。SEV1の「5分以内」は、社内システムなら30分以内が現実的かもしれません
2. 禁止事項の行を書き換える。「権限を超える約束はしない」の中身は職場ごとに全然違います
3. 出力の形式を固定する。SOAPの4項目やスクラムマスターの5項目のように毎回同じ形で返させると、過去の分と比較できるようになります

それと、1回のやりとりで完成させようとしないでください。

返ってきた答えに「2番をもっと具体的に」「この根拠が弱いので別の切り口で」と足していくほうが、最初から完璧なプロンプトを書こうとするより早く着きます。

今日から変わる自分専属のAIアシスタント

役割を渡すというのは、AIに知識を足す作業ではありません。

その職業が何を見て何を無視するか、という優先順位を渡す作業です。

8本ともそこが練り込まれているから、業種が違っても流用が効きます。

まずは1本だけ選んでください。

明日の会議で使うなら3番のプロダクトマネージャー、今日中に返信を書くなら6番のカスタマーサポート。

貼るだけなので1分で試せます。