📚 スキルシートと市場価値 シリーズ ③：AIに盛らせない設計

はじめに

前回、スキルシートをAIに解析させたらPdMでDXコンサルだった話を書きました。自分の経歴書をAIに読ませたら、自己申告と違う判定が出た、という話です。

今回はその判定する側の話をします。

経歴の判定をAIにやらせると、そのままだと話を盛ります。「関わった」が「主導した」になり、「DBを作った」が「DBA」になる。読んだ本人は少し嬉しいので、その場では誰も文句を言いません。良い感じにかいてくれます。

でも問題はメッキは剥がれるということです。

盛った経歴書は、客先の面談で剥がれます。突っ込まれて答えられなかった瞬間に、技術者と営業と会社の信用が同時に落ちる。盛った文章は少しの喜びを生みますが高い代償をはらわされる。

なので、このシステムでは「盛らないこと」を機能要件として扱っています。この記事はその設計の話です。

1. なぜAIは盛るのか

理由は2つあります。

① 褒める方向に倒れるよう訓練されている

LLMは、同意する・肯定する応答が高く評価されるように学習されています。いわゆる迎合です。放っておくと、誰の経歴を読ませても「優秀なプロジェクトマネージャです」と返ってきます。

② 盛っても、その場では誰も困らない

痛い思いをするのはその後の面談です。フィードバックが遅すぎて、生成時点では何の制動もかかりません。

そして、ここからが本題です。

全員を高く評価する経歴書は信頼を失うだけ

「あなたはPMです」「あなたもPMです」「あなたもです」——このとき、AIは判定はしています。処理を怠けているわけではありません。

ただ、出した答えが全部上に張り付いている。全員を喜ばせようとして、結果的に盛ってしまう。AIの特徴だと割り切る必要があります。

困るのは、そこから誰が何に向いているかを読み取れなくなることです。全員が高評価なら、その評価は選ぶための材料になりません。経歴書としては不完全です。

盛らせないことは、優しさの話ではなく、判定を役に立たせるための最低条件だと思っています。

2. 「触った」と「主導した」は違う

具体的にどう書いているか。判定基準の中核はこれです。

【判定基準 — 過剰申告は厳禁】
- 「企画から」「構想立案」「戦略」「技術選定を主導」「アーキテクチャ設計を主導」
  「事業/経営判断」など、所有・主導・成果 の証拠が本人の記述にある場合のみ提案する。
- 「DBを構築した」「ツールを使った」「関わった」等の 作業・利用 では提案しない
  (例: DB構築した→DBA は誤り。DBAはDB設計/チューニング/信頼性を
   専門として所有する場合のみ)。

ポイントは反例を書いていることです。

プロンプトに「盛るな」だけでは効きません。どこまでが盛っているか線を具体例で示す必要があります。「DBを構築した人はDBAではない」と書いて初めて、モデルは線の位置を理解します。

もう1つ、証拠の引用を必須にしています。

- evidence には本人の記述から 根拠となる箇所を短く原文引用 すること(創作禁止)。
- 1案件あたり最大2役割。確信が持てなければ提案しない(空でよい)。

「確信が持てなければ空でよい」と明示的に許可するのが効きます。何か出さないといけない、という圧力を外すと、無理な提案が減ります。

3. プロンプトは、4層のうちの1層でしかない

ここが今回いちばん書きたいところです。

世の中の「プロンプト設計」の記事は、だいたいプロンプトの話だけで終わります。ですが実運用では、プロンプトは防御の1枚目にすぎません。

このシステムでは4層で止めています。

層1  候補の限定    そもそも提案できる役割を絞る
層2  プロンプト    判定基準と反例を書く
層3  機械検証     出力を疑ってフィルタする
層4  人間の承認    確定させるのは人間

層1：候補を絞る

今回作成したシステムでは提案できる役割を、上流・専門職だけに限定しています。SE・PG・テスターのような実行系は、そもそも候補に入れていません。

理由は、実行系の兼務は本人がヒアリングメールで番号を記入する領域だからです。本人が答えられることに、AIが横から口を出す必要はありません。

AIに任せる範囲を狭くすること自体が、防御になります。

層2：プロンプト

前章のとおりです。

層3：出力を疑う

コードのコメントに、こう書いてあります。

# 検証: 候補外role_id/実在しない案件No/タグ済み/1案件2個超 を落とす(LLMの出力を信用しない)

実際に落としている条件はこれです。

if d is None or rid not in by_id or not ev:
    continue                      # 実在しない案件No / 候補外の役割 / 証拠なし
if rid in (d.get("roles") or []):
    continue                      # 既にタグ済みは提案しない
if seen_per_no.get(no, 0) >= 2:
    continue                      # 1案件あたり最大2役割

プロンプトに「候補以外は提案禁止」と書いてあっても、モデルは候補外の役割を返してきます。「証拠を必ず付けろ」と書いても、空で返ってくることがあります。

だから書いたルールは、コード側でもう一度検査します。プロンプトは「お願い」で、コードは「保証」です。二段階でチェックすることによりLLMのぶれを防ぐことができます。

層4：人間が確定させる

そして最後に、AIの提案はそのままでは反映されません。

営業がチェック画面で確認して、承認したものだけが経歴書に載ります。AIが出すのは候補であって、決定ではない。

所詮文脈からだした答えであって真実は本人しかわからない。ただし本人が気づいていないこともあるのでそれを教えてあげる。これによって本人の気づきがおこります。

4. 引き算ルール：迷ったら下げる

もう1つ、経歴書の冒頭見出しを決める処理があります。「エグゼクティブ・サマリー」「テクニカル・サマリー」「職務要約」の3択です。

ここにはこう書いてあります。

★★引き算ルール: エグゼクティブ/テクニカルは「明確に該当する」時だけ付ける。
  少しでも迷ったら必ず下位の「職務要約」へ倒せ。
  一般的なSE/PG・中位の経験を上位見出しへ昇格させない = 上振れ防止が最優先。

迷ったら下げる。 判定に自信が持てない領域では、常に低い方を選ばせています。

ただし、ここには但し書きが付いています。

※この引き算が効くのは、上級・専門の修飾が無い標準職や、
  中位で判断がつかない曖昧なケースに限る。
  肩書に「上級/シニア/リード/アーキテクト」等が明示されていれば、
  それは曖昧ではないので落とさない。

上振れ防止と、正当な上級職の適正評価は両立します。

ここを分けずに「とにかく低く出せ」にすると、今度は本物の上級職が中位に潰される。それは別の種類の不正確さです。抑えるのは「曖昧なとき」だけで、明確なものは明確に扱う。ここは明確な文言でチェックできるのでブレがでない範疇となります。

5. そもそも、職種に序列を定義していない

上げる下げるの話をしてきましたが、上下が定義されているのは一部だけです。

管理系（PM・PL系）だけが階層を持ち、それ以外は全部フラットにしてあります。SE・PG・インフラエンジニアも、DXコンサル・PdM・ITアーキテクトも、互いの上下は定義していません。

意図的です。序列を定義すると、AIが「昇格ストーリー」を作りたがるからです。「PGだったが実はDXコンサルだった」という筋書きは、上下があるから成立します。

無ければ、兼務は昇格ではなく並列にタグを足すことになります。

マスタの構造そのものが、盛りを誘発することがある。 ここは日本とグローバルで前提が違う領域で、それだけで1本書けるので、別の記事にします。

6. 盛らないだけでは足りない — 床を作る

上を抑える設計を進めていくと、別の問題が出ました。

1〜2年目の若手が、どの職種にも当てはまらず「該当なし」に落ちる。

資料の修正や雑務が中心の人は、上流でも専門でもありません。厳しく判定するほど、行き場がなくなる。そして「該当なし」と書かれた紙を渡されるのは、かなり残酷です。

なので、正直な下限を作りました。入口の職位として「開発アシスタント」という職種を新設しています。

面白かったのは、呼称を変えると市場価値の推定が動いたことです。

このシステムでは市場価格を自動で調査し、人間によるbiasをかけることによってリアルな金額を表示する機能がついています。

「補佐」という語で市場を調べさせると、月額80万円（参考値） という数字が返ってきました。まったく別の職種——経営補佐のようなもの——の相場を拾ってしまっていた。

「開発アシスタント」に変えると、40万円台 に収まりました（参考値）。

同じ人を指しているのに、呼び方だけで倍以上動く。 ここは実装していて一番ひやりとした部分です。呼称は表示のための飾りではなく、市場を調べるときの検索語そのものでした。

そして、この2つは同じ思想の両面だと思っています。

盛らない   = 上を抑える
落とさない = 下を作る

上だけ抑えると、下が切り捨てられます。正確であろうとするなら、両側が要る。

7. この設計の弱点

正直に書いておきます。この4層でも、盛りは完全には消すことはできません。

いちばん弱いのは層4です。営業が確認画面で全部にチェックを入れて承認したら、上の3層は意味を失います。最後の砦が人間である以上、その人間が急いでいたら通ります。

層3も万能ではありません。「候補外の役割か」「証拠が空か」のような形式は機械で検査できますが、証拠の中身が妥当かは検査できていません。本人の記述から引用されてはいるが、その一文だけでは主導と言い切れない——というケースは、いまも通り抜けます。

そしてそもそも、元の経歴書が盛られていたら、どうにもなりません。このシステムが判定しているのは「書かれていること」であって、事実ではない。

盛りを完全に止める設計は、たぶん存在しません。 できるのは、通りにくくすることと、通ったときに気づける形にしておくことだけです。

まとめ

AIは放っておくと盛る。迎合の訓練と、フィードバックの遅さの両方が効いている
AIは判定をサボっているのではない。答えが全部上に張り付くので、選ぶ材料にならなくなる
「盛るな」だけでは効かない。反例で線の位置を示す（DB構築した人はDBAではない）
「確信が持てなければ空でよい」と明示的に許可すると、無理な提案が減る
プロンプトは防御の1層目にすぎない。候補の限定・出力の機械検証・人間の承認で挟む
プロンプトは「お願い」、コードは「保証」。書いたルールはコード側でもう一度検査する
迷ったら下げる。ただし明確な上級職は落とさない。上振れ防止と適正評価は両立する
上を抑えるだけでは足りない。落ちる人のために床を作る
そして、完全には止まらない。止まらないことを前提に設計する

最後に

盛った経歴書は、その場では誰も傷つけません。技術者は少し嬉しいし、営業は提案しやすいし、AIは褒められる。

メッキが剥がれるのは、面談の席です。 そして支払うのは、たいてい盛られた本人です。

届かない期待値の案件に入れられて、毎日それを埋めることになる。本人が望んでいない親切だと思っています。

だから、判定する側は退屈なほど厳しくていい。そう考えて作りました。

※この記事の設計は、実際に運用しているサービスのものです。動いているものを見たい方はこちら（無料で試せます）。
　→ https://dbv.co.jp/cnvskillsheetlp/?utm_source=qiita&utm_medium=article&utm_campaign=role_guard

📚 関連記事（スキルシートと市場価値）

PMだと思っていた自分が、スキルシートをAIに解析させたらPdMでDXコンサルだった話
VertexAIを利用しようとして速度改善（経歴書解析を280秒→24秒にした）結果、結局VertexAIを止める羽目になった話
AIに評価させると全員が優秀になる — 経歴判定で盛りを止めた設計 ← 本記事
ハルシネーションとは何か — 実在しない職種に60万円。ハルシネーションが起きづらい方法を使ってもLLMは嘘をつく。
LLMは魔法じゃない — 本番で構造化をやって踏んだ4つの穴（既存のテストでは拾えない）

また、同じプロダクトを別の角度から書いた連載もあります。

📚 経営目線のSaaS開発

コスト削減はどこまで妥当か — クラウド時代の安全との線引き（環境編）