リーナー開発チームだより#5 〜ペルソナ付与がAIコーディングやレビュータスクに及ぼす影響など〜

リーナーAI見積査定チームのluluです！

本記事ではリーナーの開発チームで最近話題になっていることをお届けします。

AIモデルに「あなたは熟練プログラマーです」と伝えるとかえってプログラマーとしての能力が低下する

このタイトルの記事を見かけた時、レビューでペルソナを設定している私の実体験と乖離があったので気になりました。私はレビューでは複数の専門分野のペルソナを設定した担当者(セキュリティ担当・コード品質担当等)を用意しクロスレビューさせています。私の感覚としてはペルソナを付与することなくレビューさせるよりもペルソナを付与した場合の方が指摘事項が適切であると感じています。

そこで軽く元の論文等も調べてみました。

論文の該当部分への概要

専門家等のペルソナを付与されたモデルと付与されていないベースモデルとの比較
広範な知識を問う Massive Multitask Language Understanding (MMLU) ベンチマークや MT-Bench で比較
- ベースモデルのスコアに対して、ペルソナ付与されたモデルはコーディングのスコアが低下
- 特にコーディングや数学等の分野でその傾向が強かった
  - あくまで指示通りに動作するコードを生成する能力の指標
    - 事前学習した知識の正確な検索
    - 適切な論理構築によるゼロショットコード生成能力
ペルソナが付与されたことで、モデルはそのペルソナを演じる事に一定のリソースを割く事が原因と推定される
一方で以下のようなコードレビューで求められる能力は向上した
- 情報抽出(Extraction): 文脈から必要な情報や矛盾点を洗い出す能力
- STEM領域(MT-Bench側): 課題に対して専門知識を活かして筋道立てて考える能力

タスクカテゴリ	評価指標/ベンチマーク	ペルソナ付与時のスコア変化	主な発生メカニズムと影響
情報抽出 (Extraction)	MT-Bench	+0.65 (大幅向上)	専門的な枠組みの整理、フォーマットアライメントの強化
STEM領域 (STEM)	MT-Bench	+0.60 (向上)	トーンと専門用語の体系的な適合と構造化
推論 (Reasoning)	MT-Bench	+0.40 (向上)	思考プロセスに対する段階的なフレーミングの付与
人文学 (Humanities)	MT-Bench	-0.20 (低下)	事実知識の回収におけるペルソナノイズの干渉
数学 (Math)	MT-Bench	-0.10 (低下)	厳密な計算処理に対する過度な指示追従負荷
コーディング (Coding)	MT-Bench	-0.65 (著しく低下)	コード構文生成における論理破綻とコンテキスト過負荷
総合的知識 (Knowledge)	MMLU	71.6% から 68.0% へ低下	事前学習知識検索の妨害、もっともらしさの優先

タイトルだとコーディングに関するタスク全般かと思いましたが、ペルソナを設定する事で低下するのはあくまで単純なコード生成能力であり、レビュアーとしての振る舞いにはむしろプラスに働く部分もありそうですね。

またAWS の AI エージェントチームのガイドでも、定性的な評価ですが異なる視点を持った担当者による相互チェックは大きくプラスに働いたという結果も出ているようです。

The principal SDE and QA engineer checking the same code found different classes of problems. The security engineer flagged IAM issues the SDE had normalized.

builder.aws.com

この記事でも上記の論文を引用しており、エージェントチームに対して「◯◯の専門家」というラベリングを廃止し、QAエンジニア等の役割ベースの肩書付与に切り替えた結果、精度が向上した様です。一方でセキュリティエンジニア等安全性が重視される領域においては権限の枠組みを強化しゲートキーパーとしての責任を持たせることを推奨しています。

以上を踏まえ、最近はセキュリティ担当には安全性のために強く拒否する権限を持たせて運用してみています。

by リーナーAI見積査定チーム lulu (@lulu_lul2)

Why So Many Info Tips Are Bad (and How to Make Them Better)

アンチパターンをもとに Information Tip (ツールチップ) の適切な使い方を解説した記事です

www.nngroup.com

一般的にツールチップと呼ばれているような、補足的な内容をポップアップで表示するUIについて、いつ使うべきか、どのような内容を取り扱うべきかについてまとめている記事です。ツールチップについてコンテンツ的な観点でガイドラインを明文化したい時に役に立ちそうなまとめです。

by リーナー見積チーム okuparaさん (@okupara)

筆者所感

入力フォームなどで文字数制限などのバリデーション情報をツールチップ内に封じ込めているアンチパターンは今でもしばしば見かける気がします。情報を隠して画面をスッキリさせるためなど見栄えのためにUIコンポーネントを選択するのではなく、本来の目的を意識し取捨選択する事の必要性を改めて感じました。ツールチップがあるとユーザーはそこに追加の情報が有ることを期待し操作するので、ユーザーの情報を無駄にし期待を裏切ってしまうという観点はたしかに！と思いました。ユーザーが迷わず済むように過不足なく情報を提供することを常に意識していきたいですね。

Claude Code の Codex plugin を使っている話

3月末に OpenAI から Claude Code 用の Codex Plugin がリリースされました。

github.com

OpenAI 公式という安心感もありますし、丁度 OpenAI からクレジットが配布されたこともあり4月からCodex側をレビュー用に併用しています。 (リーナーでは Claude Code / Codex / Cursor 等契約中のAIコーディングエージェントから好きなものを選択して使用でき、併用も可能です。)

以下は2か月ほど使ってみての感想です。

片方だけなら見落としていた問題点への指摘が拾える
- 同じコーディングエージェント×モデルで反復レビューしても検知されづらい指摘が得られる
- 手戻りや人間が指摘する事項が減少し開発効率アップ
オプションでレビュー終了まで待たせたり( --wait )、実装を進めながらバックグラウンドでレビューさせたり ( --background ) と都合が良い方式を選べる
影響範囲の広い変更向けに adversarial-review モードも提供されている
Codex 側のレビュー結果の出力に対して、Claude Code 側で検証や対応の指示をシームレスに行える
- 「指摘が妥当か検証して」「妥当と判断した指摘に対応して」等
- コピペの手間や、トークンを消費するファイル書き出し経由の情報共有から解放された