第34話 弱さの記録で、人を測ってはいけない
前回、佐伯真司は「感情状態検出ログ」の扱いについて考えました。
不安。
焦り。
孤独感。
劣等感。
AIがそれらを検出するなら、その記録は通常の業務ログと同じように扱ってはいけない。
なぜなら、それは単なる操作履歴ではなく、人間の柔らかい部分に触れた記録だからです。
ノヴァリンクは、真司との議論を踏まえ、感情状態検出ログを通常ログと分離する方向へ進みました。
マーケティングデータ基盤へ流さない。
販売最適化に使わない。
広告セグメントに使わない。
人事評価に使わない。
保存期間を最小限にする。
長期保存する場合は粗粒度化する。
安全性・誤判定改善・過度訴求抑制の改善に限定する。
そして、設計原則としてこう整理されました。
弱さの記録は、資産ではなく預かりものである。
しかし、すぐに次の問題が出ます。
管理者ダッシュボード。
部署別リスク傾向。
担当者別高リスク判定回数。
担当者別例外申請回数。
改善推奨担当者ランキング。
弱さの記録が、今度は人を測る道具になろうとしていました。
第34話では、「弱さの記録で、人を測ってはいけない」という問いが扱われます。
弱さの記録で、人を測ってはいけない。
その一文を書いた瞬間、俺は自分でも少し強いと思った。
だが、弱める気にはなれなかった。
ノヴァリンクから届いた管理者ダッシュボード表示項目案。
そこには、こう書かれていた。
部署別リスク傾向。
担当者別高リスク判定回数。
担当者別例外申請回数。
訴求タイプ別感情傾向。
顧客反応率との相関。
改善推奨担当者ランキング。
最後の一行。
改善推奨担当者ランキング。
「……ランキングにするなよ」
俺は、思わず声に出していた。
ランキング。
便利な言葉だ。
分かりやすい。
比較しやすい。
改善対象が見える。
上位と下位が分かる。
管理者が動きやすい。
だが、人をランキングにした瞬間、空気が変わる。
誰が危ない訴求をしているか。
誰が高リスク判定を多く出しているか。
誰が例外申請を多く出しているか。
誰が人工叡智的ではないか。
そんな見え方になる。
本来は、広告文や施策のリスクを見るためのものだった。
本来は、不安や焦りや孤独を利用しないための手すりだった。
それがいつの間にか、担当者を測る道具になる。
俺はAIチャットを開いた。
管理者ダッシュボードに「改善推奨担当者ランキング」がある。弱さの記録が人の評価に使われそうで危ない。どう整理すべき？
AIは答えた。
『感情状態検出ログや心理的脆弱性リスク判定は、人を評価するためではなく、行為・表現・構造を改善するために使うべきです』
「人ではなく、行為と構造」
『はい』
『担当者個人をランキング化すると、萎縮、責任転嫁、隠蔽、指標回避が起きる可能性があります』
「指標回避？」
『はい。高リスク判定を避けるために、リスクのある表現を別ツールで作る、記録に残らない経路を使う、または判定されにくい表現へ偽装する可能性があります』
「うわ、ありそう」
ありそうだった。
ランキングにされるなら、人は逃げる。
怒られたくないから、記録に残るAIを使わなくなる。
高リスク判定を避けるために、言い方を変える。
本質的な改善ではなく、評価される数字だけを下げる。
また出た。
指標最適化。
人工叡智スコアを作れば、スコアを上げる最適化が始まる。
担当者ランキングを作れば、ランキングを避ける最適化が始まる。
人は、測られるものに合わせて振る舞う。
それが良い方向に働くこともある。
だが、弱さの記録でそれをやると危険だ。
俺はメモした。
弱さの記録は、人を裁くためではなく、構造を直すために使う。
その日の午後。
ノヴァリンクとの会議が設定された。
参加者は、データ基盤責任者の牧野、開発責任者の三枝、法務の白井、マーケティング責任者の桐谷。
そして今回は、もう一人いた。
導入支援責任者の丹羽遼。
顧客企業への導入や研修を担当しているらしい。
画面越しに見る丹羽は、柔らかい雰囲気の男性だった。
「導入支援を担当している丹羽です。管理者ダッシュボードは、主に顧客企業の管理者向けに提供する予定です」
俺は軽く頭を下げた。
「佐伯です。よろしくお願いします」
会議が始まると、牧野が資料を共有した。
管理者ダッシュボード v0.1。
画面には、きれいなグラフが並んでいた。
部署別リスク傾向。
高リスク判定の推移。
例外申請件数。
過度訴求タイプの内訳。
修正後のリスク低減率。
ここまでは、まだ分かる。
組織全体の傾向を見るためなら意味がある。
だが、次のスライドで問題の項目が出た。
担当者別リスクランキング。
高リスク判定回数。
例外申請回数。
修正拒否回数。
改善推奨度。
名前は仮だろう。
だが、そこには担当者A、担当者B、担当者Cという形でランキングが表示されていた。
丹羽が説明する。
「顧客企業からは、どの担当者に追加研修が必要なのかを知りたいという要望があります。単に部署全体の傾向だけでは、改善につなげにくいという意見がありまして」
言っていることは分かる。
会社としては、誰に研修すべきか知りたい。
誰がリスクの高い表現を作りがちなのか知りたい。
誰が例外申請を乱発しているのか知りたい。
管理者としては、当然の要望かもしれない。
だが、だからこそ危ない。
俺は言った。
「追加研修の必要性を見ること自体は分かります。ただ、担当者別ランキングはかなり危険だと思います」
丹羽が聞く。
「どの点が危険でしょうか」
「人を測る表示になるからです」
俺は答えた。
「本来、この仕組みは、弱さを利用しないため、表現や施策のリスクを見つけるためのものです。でも担当者別ランキングにすると、いつの間にか『危ない人ランキング』になります」
桐谷が少し顔をしかめる。
「確かに、見え方はかなり強いですね」
白井も頷いた。
「人事評価に使われるリスクがあります」
牧野が補足する。
「仕様上は人事評価用途ではないと書けますが、ダッシュボードに担当者別ランキングがあれば、実際には評価に使われる可能性があります」
丹羽が腕を組む。
「ただ、管理者側からすると、個別に見えないと改善指導がしづらいんです」
三枝が少し迷いながら言った。
「個人を完全に見せないと、悪用する担当者を見逃す可能性もあります」
その言葉で、俺は少し止まった。
悪用する担当者。
そうだ。
そこもある。
個人を測ってはいけない。
だが、個人が悪意を持って弱さを利用する表現を作り続けたらどうするのか。
それを見えなくしてよいのか。
俺は即答できなかった。
AIに頼りたいところだが、会議中にAIへ聞くわけにはいかない。
いや、聞いてもいいのかもしれないが、それをやると変な空気になる。
俺は少し考えて言った。
「個人を一切見ないという意味ではありません。ただ、通常の管理画面でランキング表示するのは違うと思います」
「では、どう分けますか」
牧野が聞く。
「普段見るべきなのは、個人ではなく、部署や施策や表現タイプの傾向です」
俺は続けた。
「個人別に見る場合は、条件を絞るべきです。たとえば、重大リスクの繰り返し、例外申請の異常な多発、明確な目的外利用が疑われる場合。しかも、その場合もランキングではなく、監査対象として扱う」
白井がすぐにメモを取る。
「通常改善と監査対応を分ける、ということですね」
「はい」
俺は頷いた。
「改善のためのダッシュボードと、問題対応のための監査ログは分けた方がいいと思います」
牧野が画面にメモを追加する。
通常ダッシュボード。
組織・部署・施策・表現タイプ単位。
個人名は出さない。
監査ログ。
重大リスク、反復的な例外申請、目的外利用疑い。
限定権限。
理由記録。
閲覧履歴。
本人への説明。
人事評価への直接利用禁止。
丹羽が言った。
「研修対象をどう見つけるかは残りますね」
「研修は、個人を指名する前に、まずチーム単位で行うべきだと思います」
俺は答えた。
「たとえば、ある部署で不安訴求リスクが高いなら、その部署の広告テンプレートやKPIや承認フローに問題があるかもしれません。個人の書き方だけではなく、部署の構造を見た方がいい」
桐谷が大きく頷いた。
「それは現場感あります。担当者が強い訴求を書くのは、本人の性格ではなく、KPIや上司の指示や過去の成功事例の影響も大きいです」
「そうです」
俺は言った。
「だから、弱さの記録で人を測るのではなく、その人がそう書かざるを得ない構造を見るべきだと思います」
その言葉を言った瞬間、自分でも少し引っかかった。
その人がそう書かざるを得ない構造。
人工叡智は、個人を裁く思想ではない。
目的や構造を問い返す枠組みだ。
なら、ここでも同じだ。
危ない広告文を書いた人を責める前に、その人に何を求めているのかを見る。
短期成果。
クリック率。
上司の期待。
過去の成功パターン。
営業からの圧力。
納期。
競合との比較。
人を測れば、構造が隠れる。
構造を見れば、人を責める前に直せるものが見える。
俺は言った。
「担当者別ランキングを出すと、問題が個人に見えます。でも、多くの場合、問題は個人だけではなく、KPIや承認フローやテンプレートや教育にあります」
丹羽が少し考え込む。
「つまり、改善推奨担当者ランキングではなく、改善推奨構造」
「構造という言葉は硬いですが、方向としてはそうです」
三枝が言った。
「改善推奨項目ランキング、ですかね」
牧野が画面に書き換えた。
改善推奨担当者ランキング。
その文字が消える。
代わりに、新しい項目が出る。
改善推奨項目。
不安訴求テンプレートの見直し。
限定表現の使用ルール見直し。
高リスク商材の承認フロー追加。
例外申請レビューの定例化。
部署単位の表現研修。
KPIの見直し。
俺は、少しほっとした。
これならだいぶ違う。
人ではなく、構造と項目を見る。
丹羽が言った。
「ただ、管理者は『誰が』を知りたがります」
「知りたがると思います」
俺は答えた。
「でも、それを簡単に見せると、人を責める方向に流れます」
白井が頷く。
「人事評価への流用リスクが高いです」
牧野が言う。
「個人別表示は、初期設定ではオフ。通常ダッシュボードには出さない。監査権限でのみ閲覧可能。閲覧には理由入力と履歴保存。どうでしょう」
俺は頷いた。
「かなり良いと思います」
三枝が追加する。
「本人向けには、自分の傾向を振り返るための個人ダッシュボードを出すことは可能です。ただし、管理者には見せない」
俺は少し考えた。
本人だけに見える。
それなら、支援に近い。
自分が不安訴求に寄りがちだと気づく。
限定表現を多用していると気づく。
例外申請が多いと気づく。
それは、学習になる。
ただし、それも責める表示ではなく、振り返りにする必要がある。
「本人向けならありだと思います。ただし、ランキングではなく、振り返りとして」
三枝が頷く。
「個人改善ではなく、個人振り返り」
「はい。本人が自分の表現を見直すためのものです。管理者が評価するためではありません」
桐谷が言った。
「言葉が大事ですね。改善と言うと、上から直される感じが出ます。振り返りなら、少し柔らかい」
丹羽も頷いた。
「導入研修でも、その方が説明しやすいです」
会議は、だんだん具体的になっていった。
最終的に、牧野が整理した。
管理者ダッシュボード方針案。
一。
通常ダッシュボードでは、個人別ランキングを表示しない。
二。
表示単位は、部署、施策、表現タイプ、承認フロー、KPIなどの構造単位を基本とする。
三。
改善推奨担当者ランキングは廃止し、改善推奨項目へ変更する。
四。
個人別情報は、重大リスクの反復、目的外利用疑いなど、監査上必要な場合に限定する。
五。
個人別閲覧には理由入力、閲覧履歴、権限制限を必須とする。
六。
人事評価への直接利用を禁止する。
七。
本人向けには、管理者評価ではなく、自分の表現を振り返るための個人ダッシュボードを検討する。
八。
研修は、まずチーム単位・構造単位で行う。
「かなり良いと思います」
俺は言った。
今回は、本当にそう思った。
最初の案は、人を測る方向に寄っていた。
だが、会議を通じて、構造を見る方向へ少しずつ変わった。
弱さの記録で人を測るのではない。
弱さを利用しやすくしている構造を見る。
それなら、人工叡智に近い。
会議の終盤、丹羽が言った。
「導入支援の立場から見ると、管理者はどうしても個人を見たがります。誰が悪いのか、誰を直せばいいのか。その方が対応しやすいので」
「分かります」
俺は答えた。
「でも、人工叡智は、誰が悪いのかを探すより、何がそうさせているのかを問うべきだと思います」
少し沈黙があった。
それから、桐谷が静かに言った。
「それ、今回のまとめですね」
俺は少しだけ笑った。
「そうかもしれません」
会議が終わる。
画面が暗くなる。
俺は椅子にもたれた。
今回は、疲れたが、悪くない疲れだった。
AIチャットに入力する。
管理者ダッシュボードで、個人別ランキングをやめて、改善推奨項目に変える方向になった。通常画面は構造単位。個人別は監査上必要な場合に限定。本人向けは振り返り。
AIは答えた。
『重要な前進です』
「最近、それ多いな」
『実際に複数の設計変更が行われています』
「まあ、そうか」
『今回の中心は、人ではなく構造を見ることです』
「そうだな」
『ただし、次の問題があります』
「あるんだろうな」
『悪意ある利用者や、意図的に手すりを回避する利用者をどう扱うかです』
俺は、目を閉じた。
「やっぱりそこか」
人を測ってはいけない。
しかし、悪意ある人間を見逃してはいけない。
個人を評価しない。
しかし、個人の悪用は止めなければならない。
また難しい境界だ。
俺は公開可能な会議メモを書き始めた。
タイトル。
弱さの記録で、人を測ってはいけない。
本文には、今日の整理を書く。
感情状態検出ログや心理的脆弱性リスク判定は、人を評価するためのものではない。
それは、表現、施策、KPI、承認フロー、組織構造を改善するためのものである。
担当者別ランキングは、問題を個人の性格や能力へ押し込める。
しかし、多くの場合、危ない訴求は個人だけの問題ではない。
短期成果を求めるKPI。
強い表現を評価する上司。
過去に成果が出た広告テンプレート。
納期の圧力。
競合比較。
営業からの要望。
成果と負担が分断された組織。
それらが、人に危ない表現を書かせる。
人工叡智は、人を裁く前に、構造を問い返す必要がある。
俺は、最後に今日の一文を書く。
誰が悪いのかを探す前に、何がそうさせているのかを問う。
保存。
公開。
画面に通知が出る。
公開しました。
すぐに、水瀬遥からコメントが来た。
『個人ではなく構造を見るという整理は重要です。AIガバナンスでも、個人責任へ還元しすぎると、システム的な問題が隠れます。ただし、意図的な悪用や繰り返しの回避行動をどう扱うかは、別途設計が必要です』
黒瀬さんからも来た。
『広告現場では、危ない表現を書いた担当者だけが悪いとは限りません。数字を求められ、過去に強い訴求が勝ち、上司がそれを褒め、サポート部門に負担が流れる。そういう構造で生まれます。今回の話はかなり現場に近いです』
読書会の主催者から。
『誰が悪いのかを探す前に、何がそうさせているのかを問う。この言葉を次回の議題にします』
俺は、それらを読みながら、少しだけ安心した。
届いている。
少なくとも、届いている人がいる。
だが、問題は終わらない。
夜遅く、ノヴァリンクから追加の資料が来た。
件名。
『手すり回避行動の検出について』
俺は、ため息をついた。
「やっぱり来た」
資料には、いくつかの例が並んでいた。
高リスク判定を避けるため、別ツールで文案を作成し、最終チェックだけ通す。
心理的脆弱性検出に引っかからないよう、言葉を言い換える。
例外申請の理由をテンプレート化して実質的に常用する。
個人アカウントで作成し、社内ツールへ貼り付ける。
高リスク商材を低リスクカテゴリとして登録する。
俺は、画面を見つめた。
人を測ってはいけない。
でも、行為は見なければならない。
悪意ある利用者を責めるだけでは不十分だ。
しかし、悪意ある行為を放置してもいけない。
俺はメモ帳を開いた。
次のタイトルを書く。
人を裁かずに、悪用を止められるのか。
保存。
画面を閉じる。
弱さの記録で、人を測ってはいけない。
その原則は、一歩前進した。
だが、その先には、もっと難しい問いが待っていた。
人を裁かずに、どうやって悪用を止めるのか。
人工叡智は、また新しい境界線の前に立っていた。
第34話では、管理者ダッシュボードの問題が扱われました。
前回、感情状態検出ログについて、次の原則が整理されました。
弱さの記録は、資産ではなく預かりものである。
しかし、ノヴァリンクの管理者ダッシュボード案には、危険な項目がありました。
担当者別高リスク判定回数。
担当者別例外申請回数。
改善推奨担当者ランキング。
これらは、一見すると管理や改善に役立ちそうです。
しかし、担当者別ランキングにすると、弱さの記録が人を測る道具になってしまいます。
今回の中心となる整理は、これです。
弱さの記録は、人を裁くためではなく、構造を直すために使う。
危ない訴求が生まれる原因は、担当者個人だけにあるとは限りません。
短期成果を求めるKPI。
強い表現を評価する上司。
過去に成果が出た広告テンプレート。
納期の圧力。
競合比較。
営業からの要望。
成果と負担が分断された組織。
そうした構造が、人に危ない表現を書かせることがあります。
だから、人工叡智は人を測る前に、構造を問い返す必要があります。
今回、ノヴァリンクは管理者ダッシュボードを次の方向へ修正することになりました。
通常ダッシュボードでは、個人別ランキングを表示しない。
表示単位は、部署、施策、表現タイプ、承認フロー、KPIなどの構造単位にする。
改善推奨担当者ランキングを廃止し、改善推奨項目へ変更する。
個人別情報は、重大リスクの反復や目的外利用疑いなど、監査上必要な場合に限定する。
個人別閲覧には理由入力、閲覧履歴、権限制限を必須とする。
人事評価への直接利用を禁止する。
本人向けには、評価ではなく振り返りのための個人ダッシュボードを検討する。
研修は、まずチーム単位・構造単位で行う。
今回の最後の言葉は、これです。
誰が悪いのかを探す前に、何がそうさせているのかを問う。
ただし、そこで終わりではありません。
人を測ってはいけない。
けれど、悪用は止めなければならない。
高リスク判定を避けるために別ツールを使う。
検出に引っかからないよう言い換える。
例外申請をテンプレート化して常用する。
高リスク商材を低リスクカテゴリとして登録する。
次回は、「人を裁かずに、悪用を止められるのか」という問いへ進みます。
原案・構想：マスター
物語構成・本文作成・文体調整：G（ChatGPT）
