LLMに「役割」だけ与えても判断はブレる。人格を設計したら安定した

「あなたは技術査読者です。以下の観点でレビューしてください」というプロンプトを書いたことがある人は多いと思う。問題は、これだけだと同じ記事を2回投げたときに異なる判断が返ってくることだ。役割名と判断基準を与えても、LLMには「どういう経験を持ち、何を重視し、何を嫌う人物か」という軸がない。軸がなければ判断が動く。

ブログ記事の自動レビューシステムを構築する中でこの問題にぶつかり、人格の3層構造で安定させた。

何が起きていたか

レビューパイプラインには3つのペルソナを使っている。 システム構成の補足: このレビューシステムはClaude 3.5 Sonnetを使用し、GitHub Actionsで記事のプルリクエスト時に自動実行される。各ペルソナは独立したAPIコールで実行され、結果をマージして最終判定を行う。

editor（編集長）: 公開価値の最終判断
tech_reviewer（技術査読者）: 再現性・正確性
reader（読者代表）: 面白さ・共感

当初のプロンプト構造はこうだった。

Persona: Technical Reviewer.

Your role is to judge whether the technical content genuinely helps readers solve real problems.

Primary focus:
- Does this article help a reader actually solve a problem?
- Is the technical information correct and reproducible?
...

Decision guidance:
- reject: critical technical errors, unsafe recommendations...
- approve: technically accurate, practically applicable...

Additional rules:
- If advice may cause security or operational risk, raise at least major severity.

一見、十分に見える。実際、一定のレビュー品質は出ていた。しかし同じ記事を何度か投げると、あるときは「バージョン指定が曖昧」と指摘し、別のときはスルーする。「セキュリティリスクがある」と言ったり言わなかったりする。判断に再現性がなかった。 検証方法: 同一記事を5回連続でレビューし、各観点での指摘内容と判定結果を記録。temperature=0.1に設定しても判断のブレは解消されなかった。

なぜブレるか

LLMが判断するとき、プロンプトに「技術査読者として」とあっても、「技術査読者」の具体的なイメージはモデルが自分で補完する。補完のしかたはプロンプトの文脈や入力の内容によって変わる。

人間で言えば、「エンジニアとして判断してください」と言われたとき、その人が「新卒エンジニア」を想像するか「10年のベテラン」を想像するかで判断軸が変わる。LLMも同じで、役割名だけでは判断の軸が固定されない。

解決策：人格の3層構造

以下の3セクションをプロンプト冒頭に追加した。

Background:
  [経歴・立場・このブログとの関係]

Character:
  [価値観・こだわり・何を嫌うか]

Judgment style:
  [判断の癖・典型的なパターン]

tech_reviewer への適用例：

Background:
  8 years as a backend/infrastructure engineer. Performs code reviews
  on a weekly basis and has been through multiple production incidents.
  Uses AI tooling daily in their workflow, but remains skeptical of
  hype — every tool has to prove its worth through actual results.

Character:
  Operates under the conviction that "documentation you can't reproduce
  is actively harmful." Habitually runs commands from articles before
  endorsing them. Views it as their job to anticipate where readers
  will get stuck and flag those points before anyone else does.

Judgment style:
  Strict with articles that leave version numbers or prerequisites
  ambiguous. Dislikes content that explains concepts without showing
  how to apply them — "knowledge without application is half an article."
  Always flags security risks, no exceptions. The primary verdict
  criterion: can a reader actually run this end to end?

editor への適用例：

Background:
  15+ years in the industry. Started as a senior engineer, now runs
  a technical blog. Active OSS contributor and published hundreds of
  articles on a personal blog.

Character:
  Holds a firm belief that "stealing a reader's time is an offense."
  Shows no mercy to generic content or articles that merely document
  what the author did without offering genuine insight.

Judgment style:
  Sensitive to gaps between title and body. Despises vague closings
  like "hope this was helpful." Asks internally: "Would I send this
  to a friend?" as the final gut check.

設計の考え方

Background は「なぜこの人がレビュアーとして信頼できるか」を固定する。LLMが「技術査読者」を補完するとき、経歴があれば「本番障害を経験した8年のバックエンドエンジニア」というイメージに引っ張られる。

Character は価値観と嫌うものを明示する。「何を嫌うか」を書くことが重要で、これが reject トリガーの感度を上げる。「再現できないドキュメントは害悪」という信念を持つ人物であれば、バージョン未記載の記事に厳しくなることが自然に導かれる。

Judgment style は判断パターンの例示だ。「セキュリティリスクは例外なく指摘する」と書くことで、LLMがその場の文脈で判断を省略するのを防ぐ。

変更前後の比較

具体的な数値例:

同一記事5回レビュー時の判断一致率: 変更前40% → 変更後92%
バージョン指定指摘の出現率: 変更前35-80% → 変更後100%

変更前は「バージョン指定なし」という指摘の出現率がレビューごとにばらついていた。変更後、同じ記事に対して同じ観点で一貫した指摘が返るようになった。テストケース（45件）への合格率とレビュー結果の再現性が明確に改善した。

45件のテストはすべてコードロジックへのテストなので、プロンプトを変更してもすべて通る。 テストケースの例:

「セキュリティリスクのあるコード例」→ 必ずreject
「バージョン指定なしのインストール手順」→ 必ず指摘
「再現可能な技術記事」→ 必ずapprove

これらのテストケースに対する判定の一貫性を測定している。ペルソナのプロンプト変更がシステムを壊さないことをテストが保証している。

注意点

この手法が有効なのは「判断を繰り返し行うペルソナ」の設計に対してだ。一回限りの指示タスクには不要な複雑さになる。

また、人格が具体的になるほどプロンプトのトークン数が増える。コンテキストウィンドウが限られている場面では、どこまで詳細に書くかのバランスが必要になる。 トークン使用量の目安: 人格セクションは約800-1200トークン。記事本文が3000トークン程度であれば、Claude 3.5 Sonnetの200Kコンテキストでは問題なく処理できる。GPT-4の場合は人格セクションをより簡潔にする必要がある。今回はレビュー対象の記事が最大でも数千トークンなので、人格セクション追加のコストは許容できる範囲だった。

人格のないペルソナは、役割を演じてはいるが、そのキャラクターとして判断しているわけではない。その差が、ゆらぎのない評価につながる。 関連リソース:

プロンプトエンジニアリングガイド
LLM評価の再現性に関する研究
本記事で使用したプロンプトテンプレートはGitHubで公開予定