「あなたは世界的なソフトウェアエンジニアです。最高品質のコードを書いてください」 「あなたは金融のエキスパートです。この事象を分析してください」
私たちはこれまで、まるで呼吸をするかのように、こうした「ペルソナ（役割）指定」をプロンプトの冒頭に記述してきました。そうすればLLMが"本気"を出し、回答の質が魔法のように向上すると信じていたからです。
しかし、その常識は間違っているかもしれません。それどころか、あなたのその親切な「役割設定」が、実はAIの回答精度を下げているとしたら？
「役に立つアシスタント」は役に立たない
2024年10月に公開された論文『When “A Helpful Assistant” Is Not Really Helpful: Personas in System Prompts Do Not Improve Performances of Large Language Models』は、この界隈に冷水を浴びせました。
研究チームは、Llama-2やVicunaなどの主要なLLMに対し、162種類の様々なペルソナ（弁護士、教師、友人など）を設定して実験を行いました。その結果、事実に基づく質問（MMLUデータセット）において、以下の事実が明らかになったのです。
- ペルソナ設定は、回答精度を全体として向上させない。
- むしろ、ペルソナを設定しない（標準的な指示のみ）場合よりもスコアが低下するケースが散見された。
- 「どのペルソナが効くか」に一貫性はなく、結果はほぼランダムである。
つまり、「専門家になりきれ」という指示は、私たちが期待するような「知能の底上げ」には寄与せず、むしろモデルにとってのノイズになり得るということです。
なぜ「専門家」になりきると馬鹿になるのか？
なぜこのような直感に反する結果になるのでしょうか？ 理由はLLMの仕組みを考えれば明白であり、実に「当然」の話です。
-
知識量は変わらない プロンプトで何を言おうが、モデルが学習済みパラメータとして持っている知識の総量は1ミリも増えません。「アインシュタインになれ」と言っても、モデルが相対性理論を再発明できるわけではないのです。
-
スタイルへの過剰適合（Style over Substance） ペルソナ指定は、モデルに対して「出力の確率分布」を特定の方向に歪める指示として機能します。「専門家」と指定すれば、専門用語を多用し、断定的な口調で話すようになります。 問題は、モデルが 「正しさ」よりも「専門家っぽい振る舞い」を優先してしまう ことです。その結果、内容は間違っているのに自信満々な回答（ハルシネーション）が生成されたり、その役割特有のバイアス（偏見）がノイズとして混入し、論理的な推論の邪魔をしたりするのです。
私たちは、「専門用語で自信満々に語るAI」を見て「賢くなった」と錯覚していただけに過ぎません。
では、どうすれば本当に性能が上がるのでしょうか？
今のトレンドは、漠然とした役割を与えることではなく、以下の3つの学術的アプローチをプロンプトに組み込むことです。
-
Chain-of-Thought (CoT) による推論強化
「専門家として考えて」と頼むのではなく、「ステップバイステップで論理的に考えて」 と指示します。
根拠: Wei et al. (2022) の研究により、思考過程を明示させることで、数学や論理推論の能力が飛躍的に向上するとされています。 -
Principled Instructions による制約
「良い感じに書いて」ではなく、「以下のフォーマットで出力して」 と構造を縛ります。
根拠: Bsharat et al. (2023) は、抽象的な指示よりも、禁止事項や出力形式（JSON, Markdown等）を明示した方がモデルの従順性が高まることを示しています。 -
In-Context Learning による知識注入
「あなたは知識があるはずだ」と迫るのではなく、「以下の参考資料に基づいて」 とコンテキストを与えます。
根拠: Brown et al. (2020) 以降、モデルはパラメータ内の記憶よりも、プロンプトに含まれる文脈（Context）を優先して処理する能力が高いことが示されています。
つまり、改善後のプロンプトは以下のようになります。
× 旧来のペルソナ: 「あなたはセキュリティの専門家です。このコードの脆弱性を見つけて」
○ 科学的なアプローチ: 「以下のコードスニペット（Context）に対し、OWASP Top 10の基準に基づいて（Constraint）、脆弱性の有無をステップバイステップで検証し（CoT）、発見された場合は修正案をdiff形式で出力してください（Principled Instructions）。」
プロンプトから「ワークフロー」へ：Claude CodeとSubAgent
さらに視座を広げましょう。現在の開発現場、特にコーディング領域では、1つのプロンプトで全てを解決しようとする発想自体が古くなりつつあります。
「役割」とは、プロンプトの文言で定義するものではなく、アーキテクチャ（仕組み）で定義するものです。この最前線にあるのが、Claude Codeのエコシステムに見られるようなAgentic Workflowです。
"SubAgent" による真の役割分担
最新のエージェント開発手法では、以下のようにタスクを分解し、それぞれに特化した「SubAgent」を定義します。
PM Agent: ユーザーの要望を「要件定義書（Spec）」に落とし込む。
Dev Agent: Specに基づき、特定のファイルのみをコンテキストとして持ち、実装を行う。
Reviewer/QA Agent: 実装されたコードに対し、テストケースを実行し判定する。
これらは単なる「キャラ設定」ではありません。各エージェントは独立したコンテキスト（記憶領域）と専用のツールセット（Instruction） を持っています。
コンテキスト切れの防止: Dev Agentは開発に必要なファイルしか見ないため、余計なノイズが入らず、目的がぶれません。
品質の担保: QA Agentは「意地悪なテスター」としてのツール（テスト実行コマンド）しか持たないため、甘いチェックが構造的に排除されます。
現実世界へのインプリメント（Human-in-the-loop）
さらに現代のワークフローは、CLIの中で完結しません。
Slack連携: PM Agentが仕様を固めたら、Slackのプロジェクトチャンネルに通知し、人間の承認（Approve）を待つ。
タスク管理: 実装タスクは自動的にJiraやLinearのチケットとして発行される。
CI/CD: Reviewer Agentが通したコードは、自動的にPRとして作成される。
ここでは、「LLMにどう話しかけるか」という些末な問題ではなく、「LLMをどのシステムに接続し、どう自律的に動かすか」 という設計論が重要になります。
おまじないを卒業しよう
「あなたは専門家です」と唱えるのは、もう終わりにしましょう。それは、複雑な問題を解決した気にさせるだけのプラシーボ効果に過ぎません。
単発のタスクなら、CoTやIn-Context Learningに基づいた論理的な指示を書く。
複雑な開発なら、SubAgentとワークフローを定義し、システムとして解決する。
AIに「役」を演じさせるのではなく、AIに「仕事」のフローを設計して渡す。現時代に求められるスキルです。