プロンプト 2026年5月4日 6分

「あなたは優秀な〇〇です」は本当に意味があるのか？AIに仕事を頼むときのプロンプト設計

「あなたは優秀な〇〇です」型のプロンプトは本当に効くのか。役割指定が機能する条件と、肩書きより重要な「目的・観点・出力形式・判断基準」をAI開発の現場目線で整理します。

この記事は誰のためのものか

前の記事「「コピペで使える最強プロンプト」を探す前に：AIに仕事を任せる前の整え方」では、AIに渡す前に文脈を整える話を書きました。今回はその続きとして、「プロンプトの中身そのもの」をどう書くかに踏み込みます。

対象にしているのは、これからAI開発やAI活用を仕事に取り入れたいけれど、最初のとっかかりに迷っている人です。プロンプト集を眺めていると、ほとんどの記事の冒頭に「あなたは優秀な〇〇です」と書かれています。マーケター、PM、エンジニア、編集者、コンサルタント。役割さえ指定すればAIが化けるかのような書き方が並びます。

これを見るたびに、「本当にこれで効くのか？」と引っかかっていた方に向けて、現場の実務目線で答えを書いておきます。

結論：役作りだけでは弱いが、無意味でもない

先に結論から書きます。

「あなたは優秀な〇〇です」と書くだけでは、出力の質はほとんど安定しない
ただし、役割指定が無意味なわけではない。条件付きで効く
大事なのは「何者として振る舞うか」より、「何を、どの観点で、どんな形式に、どんな制約で出すか」

プロンプト設計の重心は、肩書きではなく目的・観点・出力形式・判断基準のほうにあります。役割指定はその補助線として使うものです。

「あなたは優秀な〇〇です」だけが効かない理由

たとえば次のようなプロンプトを考えてみてください。

あなたは優秀なPMです。以下の議事録をいい感じにまとめてください。
（議事録が貼り付けてある）

これで返ってくるのは、たいてい「それっぽい要約」です。読みやすい体裁ではあるものの、実際に次のアクションに使えるかというと心もとない。なぜかというと、AIが何を重視して、何を捨て、誰に向けて、どの粒度で書けばいいのかが指示されていないからです。

「優秀なPM」と書かれても、AIは世の中にあるPMっぽい文章のパターンを薄く混ぜて返すだけです。優秀さの定義はプロンプトの中に書かれていません。書かれていないものをAIは読み取れません。

「いい感じに」も同じです。誰にとっての「いい感じ」かが指定されていなければ、AIは平均的な体裁を選びます。平均は無難ですが、現場では往々にして役に立ちません。

役割指定が効くのはどういうときか

ここまで書くと「じゃあ役割指定はいらないのか」と思われそうですが、そうではありません。役割指定は、次の4つを併せて書くと急に効き始めます。

読ませる観点：レビュー観点、評価軸、注目してほしいポイント
判断基準：何をもって良し悪しを決めるか
読者：誰に向けた出力なのか
出力責任：何を返せば責任を果たしたことになるのか

たとえば「あなたはセキュリティレビュー担当のシニアエンジニアです」と書いたうえで、「OWASP Top 10の観点で、認証・認可・入力検証・ログ出力に絞って指摘してください。指摘は重大度（Critical / High / Medium / Low）と該当箇所のfile:line付きで返してください」と続けると、出力の安定度は明らかに変わります。

肩書きそのものが効いているというより、肩書きに紐づく観点と判断基準を後ろに並べたから効いているわけです。逆に言うと、観点と基準を書けるなら、肩書きは省いてもそれほど困りません。

悪い例と良い例

具体例で並べてみます。

悪い例：

あなたは優秀なPMです。以下の議事録をいい感じにまとめてください。

良い例：

以下の議事録を、来週のステアリングコミッティ向けに要約してください。

## 読者
- 経営層3名（うち2名はプロダクト非専任）
- 細かい技術論ではなく、意思決定が必要な論点と現状リスクを知りたい

## 出力フォーマット
- 「決まったこと」「未決事項」「次回までの宿題」の3セクション
- 各項目は1文。背景は必要な場合のみ括弧書きで添える

## 判断基準
- 意思決定に関係しない雑談や感想は落とす
- 金額・期日・担当者が出ている箇所は必ず拾う
- 推測で補った箇所は「（推測）」と明記する

## 未決事項の扱い
- 決まりきっていないものを「決定」として書かない
- 議事録の中で意見が割れている箇所は、両論を1行ずつ残す

## 入力
（議事録）

役割指定はあえて外しました。それでも出力は前者よりはるかに安定します。AIにとって必要なのは「あなたは何者か」ではなく、「何を、どの観点で、どんな形式に、どんな制約で出してほしいか」だからです。

プロンプト設計で本当に効くのは4つ

実務でAIに仕事を任せ続けていると、効くプロンプトと効かないプロンプトの差が、だいたい次の4要素に集約されることが見えてきます。

目的：何のためにその出力が必要か。次に何に使うのか。
制約：技術、納期、予算、社内ルール、扱える情報の範囲、推測の扱い。
出力形式：見出し構造、長さ、粒度、トーン、Markdown / JSON / 表など。
判断基準：何を残し、何を捨てるか。良し悪しをどう決めるか。

この4つが書かれていれば、肩書きは飾りに過ぎません。逆にこの4つが抜けていると、どれだけ凝った役割指定をしても出力は安定しません。

AI開発の現場では「仕様」のほうが効く

Claude Code、Codex、Cursorなどでコードを書かせる場面では、この傾向はさらに顕著になります。

「あなたは優秀なエンジニアです」と書いても、現場では何も変わりません。実際に効くのは、

何を実装したいか（機能の意図、ユースケース）
どこを触ってよくて、どこは触ってはいけないか
既存コードの規約、フレームワーク、テスト方針
どこまで満たせば完了とみなすか（受け入れ条件）
パフォーマンス、互換性、セキュリティに関する制約

のような仕様・前提・受け入れ条件です。役割指定よりも、コードベースの実情にひもづいたコンテキストのほうが圧倒的に効きます。

経験のあるエンジニアが新人に作業を頼むときも同じです。「あなたは優秀なエンジニアとして」とは言いません。「このリポジトリのこの層は他チームが触っているので変えないで」「テストはここに追加してね」「ここは既存パターンに合わせて」という具体的な前提を渡すから、新人の出力が安定します。AIに対しても本質は変わりません。

議事録をAIに渡すときも同じ構造

役割指定の話から少し広げると、会議後のログをAIに渡す場面でも同じ構造が効きます。

会議の議事録をそのままAIに貼って「まとめて」と頼むと、出てくるのはだいたい「議事録っぽい要約」です。粒度がちぐはぐで、決定と意見が混ざり、誰に向けた文書なのかも分からない。

ここで必要なのは「優秀な議事録要約担当」という役を演じさせることではなく、議事録そのものをAIが判断できる入力に変換しておくことです。前回の記事で紹介したプロンプトが担っているのも、まさにこの変換の部分でした。

入力が整えば、肩書きを盛らなくてもAIは仕事をします。入力が整っていなければ、どれだけ役を盛ってもAIは仕事をしません。

まとめ

「あなたは優秀な〇〇です」だけでは、出力は安定しない
役割指定が効くのは、観点・判断基準・読者・出力責任を併せて書ける場合
本当に効くのは「目的」「制約」「出力形式」「判断基準」の4つ
AI開発の文脈では、肩書きより仕様・前提・受け入れ条件のほうが強い
議事録のような曖昧な入力は、AIが判断できる形にあらかじめ整えておく

派手なテクニックよりも、地味な4要素を毎回ちゃんと書くほうが、長期的な出力品質には効いてきます。

おわりに：入力を整えると、役割指定はいらなくなる

前の記事では、AIに渡す前に文脈を整える話を書きました。今回はその上のレイヤーで、プロンプトそのものをどう設計するかを書いてきました。

両方を続けて読むと、共通する話に行き着きます。AIに仕事を任せるときに効くのは、AIに「役」を与えることではなく、AIが判断するための入力と基準を渡すことです。

v2pは、その「入力を整える」部分を日常の業務フローに組み込むために作っています。会議や手元のメモから、AIや開発者がそのまま受け取れる形式へ変換する作業を、毎回手動でやらなくて済むようにしていく、という方向です。プロンプトを盛る代わりに、入力のほうを整える。地味ですが、こちらのほうが長く効きます。