360度評価の自由記述を要約するClaude Code手順 — 匿名性を守る置換前処理

360度評価の自由記述を要約するとき、いちばん守りたいのは「誰が書いたか分からない」状態です。コメントを丸ごと貼り付けると、同僚の実名、部署名、特定の会議の話がそのまま外部のAPIへ送られます。

この記事の手順は、送る前にローカルで固有名詞をトークンへ置き換え、置換後のテキストだけをClaude Codeの非対話モード(claude -p)に渡す構成です。要約は評価対象者ごと、観点別に出します。置換だけでは防げない特定のされ方も、最後に取り上げます。

全体の流れ — 置換表はClaudeに見せない

構成は4段です。Claudeが触るのは3番だけで、置換表(誰をどのトークンにしたか)は手元に残します。

標準入力で渡す理由は、Claudeにファイルを読ませないためです。公式の例にもあるとおり、非対話モードは標準入力を読み、cat build-error.txt | claude -p '…' のようにデータをパイプで受け取れます。元のCSVや置換表が置かれたディレクトリをClaudeの作業範囲に入れる必要がありません。

手順1: 置換スクリプトで回答者が特定される語を落とす

置換の対象は、コメントの書き手を絞り込める語です。評価対象者本人の名前だけでなく、書き手が属しそうな部署、共通のプロジェクト名、上司の呼称も含めます。

名簿から次の形の roster.csv を作ります。左が元の語、右が置換後のトークンです。

term,token
田中,[人物A]
佐藤部長,[上司]
営業企画部,[部署X]

置換は正規表現ではなく単純な文字列置換にします。意図しない一致が起きないよう、長い語から先に置き換えるのがコツです。「佐藤」を先に置換すると「佐藤部長」の後半が残ってしまうからです。

import csv, pathlib
from collections import defaultdict
 
pairs = [(r["term"], r["token"])
         for r in csv.DictReader(open("roster.csv", encoding="utf-8"))]
pairs.sort(key=lambda p: len(p[0]), reverse=True)  # 長い語を先に置換
 
by_subject = defaultdict(list)
for row in csv.DictReader(open("comments.csv", encoding="utf-8")):
    text = row["comment"]
    for term, token in pairs:
        text = text.replace(term, token)
    by_subject[row["subject"]].append(text)
 
out = pathlib.Path("masked")
out.mkdir(exist_ok=True)
for subject, texts in by_subject.items():
    if len(texts) < 3:      # 回答が少ない対象者は要約しない
        continue
    (out / f"{subject}.txt").write_text(
        "\n".join(f"- {t}" for t in texts), encoding="utf-8")

サンプルの2行(佐藤部長への報告が早く、営業企画部の田中さんとの連携も良い など)でこのスクリプトを動かすと、[上司]への報告が早く、[部署X]の[人物A]さんとの連携も良い という出力になります。

subject 列には「S01」のような仮IDを使います。評価対象者の氏名と仮IDの対応表も、置換表と同じくClaudeには渡しません。

回答が少ない対象者は要約から外す

スクリプトの len(texts) < 3 は、回答者数が少ない評価対象者を落とす条件です。3件という数字は一例で、運用に合わせて決めます。回答者が2人しかいない対象者の要約は、「観点別にまとめた」つもりでも実質的に個別コメントの言い換えになるからです。

手順2: Claude Codeに観点別の要約を出させる

置換後のファイルを対象者ごとに渡します。スクリプト内で使う構成は次のとおりです。

mkdir -p summary
for f in masked/*.txt; do
  id=$(basename "$f" .txt)
  claude --bare -p \
    "次は一人の評価対象者に寄せられた360度評価の自由記述です。\
強み・改善してほしい点・具体的な行動例に分けて要約してください。\
原文にない推測は書かないでください。" \
    --tools "" --no-session-persistence \
    --output-format json \
    --json-schema '{"type":"object","properties":{"strengths":{"type":"array","items":{"type":"string"}},"growth_areas":{"type":"array","items":{"type":"string"}},"examples":{"type":"array","items":{"type":"string"}},"possibly_identifying":{"type":"array","items":{"type":"string"}}},"required":["strengths","growth_areas","examples","possibly_identifying"]}' \
    < "$f" | jq '.structured_output' > "summary/$id.json"
done

各フラグが何をするかを、手順2の設計意図と合わせて見ます。

--bare は認証の点で注意が要ります。公式ドキュメントによると、bareモードはOAuthの認証情報やキーチェーンを読まないので、ANTHROPIC_API_KEY を環境変数に設定しておく必要があります。サブスクリプションのログインのまま使う場合は --bare を外します。その場合、非対話モードでもプロジェクトの .claude/settings.json にあるフックや .mcp.json のサーバーが動くため、評価データ専用の空のディレクトリで実行してください。

--tools "" と --bare の併用、そして --json-schema が日本語の長文でも安定して通るかは、本番データの前に架空のコメント数十件で試して確かめます。

スキーマに「特定されうる記述」の欄を入れる

スキーマの possibly_identifying は、要約の中にコメントの書き手や当事者を推測できる記述が残っていないかを、Claude自身に挙げさせる欄です。置換表にない語、たとえば「先月の〇〇案件の障害対応」といった出来事の言及を拾わせる使い方を想定しています。

この欄は人が確認するための手がかりです。空だからといって安全の保証にはならない点は、後の節で扱います。

公式の挙動で注意しておく2点

• 標準入力には10MBの上限があり、超えるとエラーで終了します。1人あたりのコメント量では通常届きませんが、全員分を1回で渡す構成は避けます
• 公式の説明では、--output-format json の応答にはコストの見積もり(total_cost_usd)も含まれます。対象者数が多い場合の見積もりに使えます

観点別にまとめる指示文の組み方

要約の質は指示文でほぼ決まります。360度評価の自由記述は、褒め言葉と指摘が1つのコメントに混在していることが多いので、観点を先に決めておくと散らばりにくくなります。

観点の例は次のようなものです。自社の評価項目に合わせて差し替えてください。

• 強み(継続してほしい行動)
• 改善してほしい点
• 具体的な行動例(いつ・どんな場面か)
• 評価者間で割れている点

「割れている点」は、同じ行動を肯定するコメントと否定するコメントが両方ある場合です。平均化して一つの結論にまとめてしまうと、面談で本人に伝えるときに最も大事な部分が消えます。指示文には「意見が分かれているときは、まとめずに両方を併記する」と書き添えます。

原文にない推測を禁じる一文も、プロンプトに入れておきます。部下への助言を勝手に足してしまうなど、要約の範囲を超えた出力を抑えるためです。

置換だけでは匿名にならない場面

ここまでの手順で防げるのは、「名前や部署名が文字として送られる」ことです。回答者が特定される経路は、それだけではありません。

置換表の作り込みに頼るより、要約の出力から具体的な引用を外す方が安全です。指示文に「原文の言い回しをそのまま引用しない」と入れておくと、書き癖が出力に残りにくくなります。

自由記述が個人情報に当たるかどうか、仮名化したデータをどう扱うかは、別の論点として整理済みです。仮名加工情報・匿名加工情報との違いは仮名加工情報と匿名加工情報を生成AIに渡す前の加工で扱っています。トークンに置換しても元の表を手元に持っている限り、法的な意味での匿名にはならないことに注意してください。

データがどこへ行くかを先に確認する

置換後のテキストでも、Claude Codeの実行時にはAnthropicのAPIへ送られます。公式のデータ利用の説明では、プランごとに扱いが分かれています。

• Free・Pro・Maxのアカウントは、モデル改善への利用設定がオンのとき学習に使われます。設定をオフにしている場合の保持期間は30日、オンの場合は5年です
• Team・Enterprise・APIなどの商用利用では、標準の保持期間が30日です。Claude Codeに送られたコードやプロンプトで生成モデルを学習しない方針が示されています
• Claude Codeは、セッションの記録をローカルの ~/.claude/projects/ に平文で30日間保存するのが既定です

--no-session-persistence は、このローカルの保存を止めるためのフラグです。評価データのように手元にも残したくない内容を扱うときに効きます。サーバー側の保持期間は別の話で、ゼロデータ保持は対象アカウントでのみ有効にできます。プラン別の詳しい違いはClaude Codeのデータは学習に使われるかにまとめています。

要約をその後の面談資料にする

出力されたJSONは、そのまま本人に渡す資料ではありません。人事担当や上司が一度目を通し、possibly_identifying の項目と、要約が原文のニュアンスを変えていないかを確認します。

JSONを面談用の文章に整える段階では、評価コメントの下書きに使える手順が参考になります。Claudeで目標設定と評価コメントを下書きする手順は、上司が書くコメントの下書きを扱う記事です。人事システムのLatticeを使っている場合は、LatticeとClaudeで人事評価ドラフトと1on1準備を進める方法も選択肢になります。

この記事の手順はそれらと違い、集めた匿名コメントの前処理と要約に絞っています。面談資料の文面にする段階では、要約JSONの examples を根拠として残し、本人に伝える言い回しだけを人が整えると、原文から離れにくくなります。

要約が原文からずれていないかの確かめ方

観点別のまとめは読みやすい反面、原文にない一般論が混ざることがあります。次の三つを、本番の前に架空データで試しておきます。

• 件数は、Claudeに数えさせずスクリプト側で出す。「強みとして挙げた人が5人中4人」のような数は、集計表から機械的に数える方が確実です
• 要約の各項目に対応する原文を、仮IDごとのファイルで目視照合する。examples に挙がった行動例が、実際にコメントのどこから来たかを確かめます
• 同じ入力を2回流して、観点の振り分けが大きく変わらないかを見る。変わる項目は、指示文の観点定義が曖昧です

照合の結果、原文に根拠がない項目があれば、指示文の「原文にない推測は書かない」を強めるより、観点の数を減らす方が効きます。

まとめ

匿名性を守る要の部分は、Claudeに渡す前のローカル置換と、置換表をClaudeの手の届かない場所に置くことです。非対話モードなら標準入力で渡せるので、ファイルを読ませる権限も不要になります。

そのうえで、少人数の対象者は要約しない、原文を引用させない、特定されうる記述を人が確認する、という三つを運用に組み込みます。置換が完璧でも、出来事の言及や書き癖から書き手が分かる可能性は残るためです。