なぜ「あなたはプロのXXです」という書き方はほとんど役に立たないのか、Claudeはこの役割の意味を理解しているはずではないのか？
Claudeは確かに「マーケティングコンサルタント」「コピーエディター」といった言葉の一般的な意味を理解しており、まさにそれが問題である。Claudeがすでに知っているからこそ、肩書きをもう一度述べても新しい情報は何も加わらない。System Promptの本当の価値は、Claudeが自分で推測しようがない部分を補うことにある。あなたのこの具体的な状況における判断基準は何か、あなたはどの細部を気にするのか、出力フォーマットはどうあるべきか。肩書きそのものは非常に幅広いカテゴリーであり、同じ肩書きの下でも無数の異なる実際のやり方が存在しうる。
肩書きを「そのフォルダの名前」、具体的な判断基準を「フォルダの中に実際に入っているファイル」だとイメージするとよい。フォルダの名前だけを書いても、Claudeはそのカテゴリーに対する一般的な理解に基づいて中身を推測するしかない。実際の判断ルールを書き込んで初めて、本当にコンテンツを提供していることになる。
コピーの審査以外に、この「具体的な判断基準を書き出す」というアプローチは、どんな一般的な日常タスクに使えるのか？
この考え方は、Claudeが何らかの基準に沿って判断やふるい分けを行う必要があるあらゆるタスクに適用できる。例えば会議録を整理する際、「重点をまとめて要約してください」と書く代わりに、「決議事項、対応タスク（担当者と期限を含む）、さらなる議論が必要な論点、という3つのカテゴリーに分けて整理し、明確な担当者がいない対応タスクは特にフラグを立ててください」と書くことができる。カスタマーサポートのメールに返信する際も、「親しみやすいトーンで返信してください」と書く代わりに、「まず顧客の問題を言い換えて理解が正しいことを確認し、次に具体的な解決策を示し、その解決策に顧客からさらなる情報が必要な場合は、最後の段落に必要な項目を明確に列挙してください」と書くことができる。
共通するパターンは、「漠然とした形容詞や肩書き」を「いくつかの具体的で、1つずつチェックできるルール」に分解することである。この分解のプロセス自体が、Claudeがもともと推測できなかった部分の情報を補っているのである。
判断基準はどれくらい細かく書くべきか？細部を書きすぎると、Claudeの手足を縛って柔軟性を失わせてしまわないか？
これは実際のトレードオフであり、判断基準はタスクそのものの性質によって決まる。タスクに明確で誤りが許されない標準的な手順がある場合（固定フォーマットのデータ検証や、特定の順序で実行しなければならないステップなど）は、基準を非常に具体的に、時には「どの単語を使うか、どの順序で行うか」というレベルまで書く価値がある。しかしタスク自体が状況に応じた柔軟な判断を必要とする場合（コピーのトーンを軽快にすべきかどうかが、今回誰に向けて書くかによって変わる場合など）、すべての細部を固定してしまうと、かえってClaudeが文脈に基づいてより良い判断を下せなくなってしまう。
実務上は、判断基準をスペクトラムとしてイメージするとよい。一方の端は「開けた野原」で、タスク自体の許容度が高く、複数のやり方が成功とみなされる場合であり、この場合は大まかな方向性だけを示し、細部はClaudeの判断に任せる。もう一方の端は「崖沿いの狭い橋」で、タスクの許容度が低く、正しいやり方が1つしかない場合であり、この場合は各ステップを明確に書き、曖昧さを残さない。自分のタスクがこのスペクトラムのどこに位置するかを判断してから、基準をどれだけ細かく書くかを決める方が、常に「詳細であればあるほど良い」を目指すよりも効率的である。
もしすでに漠然としたSystem Promptを持っている場合、全体を書き直すのではなく、段階的に具体的なバージョンへと改善していくにはどうすればよいか？
全体を書き直す必要はない。より効率的な方法は、まず現在のPromptが出している結果のうち、「自分が求めているものとちょっと違う」と感じる部分を見つけ、そのギャップから逆算して「Claudeにどんな判断根拠が欠けていたから、この選択をしたのか」を考えることである。例えば、Claudeがコピーを審査した際に誇張表現を見逃してフラグを立てなかったことに気づいたなら、それはもとのPromptに「誇張表現をチェックする」ことが全く触れられていなかったことを意味するので、そのルールだけを追加すればよく、全体を書き直す必要はない。
実務上これは段階的に積み重ねていくプロセスである。出力結果が期待と異なるたびに、「Claudeにどんな具体的な判断基準が欠けていたためにこうなったのか」を問い直し、その答えをPromptに追加していく。何度かこれを繰り返すうちに、もともと漠然としていた役割説明は、自然と1つひとつの具体的なルールに置き換わっていく。この方法は、最初から完璧なバージョンを書こうとするよりも現実的である。なぜなら、追加すべき多くの細部は、実際に何度か使ってみて具体的なギャップを目にして初めて浮かび上がってくるものだからである。
ほとんどの人が初めてSystem Promptを書くと、「あなたはプロのマーケティングコンサルタントです。マーケティングに関する質問に答えてください」といった文章になりがちである。この文自体は間違ってはいないが、Claudeがもともと知らなかった情報をほとんど提供していない——Claudeはマーケティングコンサルタントが大体何をするか、もともと把握しており、この一文があってもClaudeの回答がより正確になったり、あなたが実際に求める形に近づいたりするわけではない。
本当に役立つ役割設定は、「肩書き」ではなく「その役割が具体的な状況でどう判断するか」に依拠している。以下、実際の例を使って、漠然とした役割説明を、実際に出力の品質に影響を与えるSystem Promptへと書き直す方法を示す。
例えば、Claudeに商品コピーのレビューを手伝ってもらう必要があるとする。漠然としたバージョンはこう書かれるかもしれない。「あなたはベテランのコピーエディターです。以下のコピーをレビューしてください」。この文はClaudeにとって実質的な助けが限られている。なぜなら「ベテランのコピーエディター」がどんな審査基準を持つかは、会社、商品、対象読者によって全く異なりうるからである。
より効果的な書き方は、「この役割が実際にどう判断するか」を明確にすることである。
System Promptの例：
「あなたはECサイトの商品コピーを審査する担当です。審査の際は次の3点を順番にチェックしてください。第一に、コピー内の各機能説明が具体的な数字に裏付けられているか（例えば『バッテリー持続時間が向上』は『バッテリー持続時間が40%向上』のような検証可能な表現に直すこと）。第二に、『最も』『No.1』のような追加の裏付けを必要とする絶対的な表現が使われていないか、あればフラグを立てること。第三に、コピーの結びが次のアクション（購入、カートに追加、詳細を見る）を明確に伝えているか。各項目について、まず原文のどこに問題があるかを指摘し、次に具体的な修正版を示すこと。抽象的な助言だけで済ませないこと。」
このバージョンは役割そのものを「すごそうな」形容詞で描写していないが、3つの具体的なチェック項目、それぞれで探すべき問題のタイプ、そして出力形式の要件（まず問題を指摘し、次に修正版を示す。抽象的な助言だけにしない）を明確に定義している。これこそが、Claudeがもともと知らず、あなたが提供する必要のあった情報である。
役割設定を書き終えたら、次の問いで自分自身をテストできる。「この一文を取り除いたら、Claudeの回答は本当に変わるだろうか？」答えが「大して変わらない」であれば、その一文はおそらく単に肩書きを説明しているだけで、実際の判断根拠を提供していない可能性が高い。答えが「変わる、なぜならこの一文がなければClaudeはどんな基準で審査すればよいか分からなくなるから」であれば、その一文は本当に役割を果たしている。
次にSystem Promptを書くときは、「この役割がどれだけすごそうに聞こえるべきか」を考えるのではなく、まず自分にこう問いかけてみるとよい。「この分野について全く知識はないが論理的思考力の高い人にこのタスクを説明するとしたら、どのような具体的な判断ルールを伝える必要があるか」。そのルールをSystem Promptに書き込むことは、形容詞を積み重ねるよりも、通常はるかに早く望む結果にたどり着ける。この原則はコピーの審査に限らず、「特定の基準に沿って判断する」ことが必要なあらゆるタスク——コードレビュー、データ分析、カスタマーサポートの返信——にも同じ考え方が当てはまる。具体的な判断基準は、常に漠然とした肩書きの説明よりも役に立つ。