AIサービスの中でも最近利用者が増えているClaudeを使って、ピープルアナリティクスをやってみました。題材は従業員エンゲージメントの向上要因分析です。また、データは当サイトで公開しているHRトイデータを使いました。

この題材を使ったLLMの試行は定期的に行っていて、技術の進歩を定点観測する上で役に立っています。

また、ここで作成したデモ動画は、成城大学の「データサイエンス特殊講義III」の中でも取り上げています。講義では人事における意思決定支援の課題を整理した上で、ピープルアナリストがAIとどのように協働していくのかを考察しました。

Claudeによる人事データ分析の様子

まずはデモ動画をご覧ください。当サイトで公開しているHRトイデータに対する分析をClaude Opusで行いました。ざっくりとしたプロンプトでスイスイ分析してくれることがわかります。

途中経過を詳しく見てみると、以下のような流れで分析を進めていました。人が分析するときにたどる道とよく似ていますね。

  1. 分析テーマを理解する。
  2. データの外観を確認し分析アプローチを検討する。
  3. 基本集計や可視化を行って洞察した後、統計モデルで評価する。
  4. 評価結果を解釈した上で考察する。
  5. 分析レポートにまとめる。

ちょうど1年前にGeminiで分析した例を取り上げましたが、それと比べると格段に自律性が増しています。

プラットフォームは異なるものの、LLMおよびAIエージェントのレベルが上がっていることは間違いなく、進歩の速さを実感しました。

自問自答しながら自律的に進む

データの外観を確認して部単位で統制すべきということに気づき、仮説をもって重回帰を回す。そして、その結果を考察してレポートにまとめる流れになっていました。これは、データアナリストが実務でやることそのものではないでしょうか。

このような形でClaudeが分析していたわけですが、その様子を見ていて興味深かったのは、自問自答しながら進めていたことです。

例えば、分析レポートをまとめる直前では、以下のような思考プロセスが見えていました。

(思考プロセス)どの視覚化が最も効果的か検討中です。4つの別々のグラフで情報を詰め込みすぎるよりも、部署ごとのエンゲージメントの比較と、パフォーマンスの低いセクションのランキングを組み合わせた方が、最も説得力のあるアプローチになると思われます。

分析としての効果を言っているのか、それとも私への見せ方を言っているのか判断に迷いますが、あいまいなところも含め人間味があるようにも感じました。

注意すべきことも多い

その一方で、分析結果をそのまま受け取れない箇所もあり、ユーザーがアウトプットを丁寧に評価しなくてはならない状況は変わっておりません。

具体的には次の点が気になりました。

  • 記述的な分析結果を元に因果に踏み込んだ考察をしてレポートしている。
  • 回帰分析の結果報告のセクションでは報告内容が二つのモデルから導かれているが、それが明示的に示されていない。
  • プロンプトやデータからは読み取れない課題を想像的に報告している。
  • 集計、可視化、探索、回帰分析といった一連のプロセスそれぞれで個別にデータの読み込み・加工処理が走っている。
  • 提言内容に対して「因果ととらえてよいか」とソフトに指摘すると、提言内容がガラリと変わった。

逆説的ですが、LLMの力が上がるほどその恩恵をうけるユーザーに求められるスキルレベルが高くなるという状況だと感じました。今回のデモでいうと、評価者には以下の知見が求められます。

  • データ分析プロセスの一貫性の問題を確認できる。
  • 回帰分析における記述、予測、因果推論の違いを理解し指摘できる。
  • 問題設定、考察、提言のロジックの問題を見抜くことができる。

Claudeの分析プロセスを吟味する

上で取り上げた問題点は、Claudeの分析プロセスを詳しく見てみるとよくわかります。

以下、「プロンプト」は私が投入したプロンプト、「思考プロセス」はClaudeが作業中につぶやいたこと、「出力」は出力結果です。なお、英語でのつぶやきは翻訳サービスで翻訳したものです。

はじまり

まずは次のプロンプトから分析を始めました。データは、当サイトで公開しているHRトイデータを利用しました。

プロンプト: このデータは人事データのサンプルデータです。エンゲージメントの向上施策を検討するために、エンゲージメントスコアと時間外やそのほかの情報との関連性を調べることになりました。エンゲージメントの向上に寄与し、今後改善すべきポイントをデータ分析で明らかにしてください

初動・データ確認

ざっくりとしたプロンプトでしたが、Claudeは意図を読み取って分析を開始していきます。

(思考プロセス)ユーザーがHRデータセットをアップロードしたので、まずファイルを読み込んでデータ構造を確認する必要がある。エンゲージメントスコアに関連する要因を分析して改善点を特定するのが目標だ。ユーザーが日本語で書いているので、日本語で対応しよう。

ここで、Claudeはデータの外観の確認をしてからPythonのPandasに取り込みます。取り込む前にbashで確認するというのはとても堅実でいいですね。

ls -la /mnt/user-data/uploads/ && head -5 /mnt/user-data/uploads/hr-toydata-basic-600.csv
import pandas as pd
import numpy as np

df = pd.read_csv('hr-toydata-basic-600.csv')
print("=== 基本情報 ===")
print(f"行数: {len(df)}, 列数: {len(df.columns)}")
print(f"\n列名: {df.columns.tolist()}")
print(f"\n=== データ型 ===")
print(df.dtypes)
print(f"\n=== 欠損値 ===")
print(df.isnull().sum()[df.isnull().sum() > 0])
print(f"\n=== 年度分布 ===")
print(df['年度'].value_counts().sort_index())

ここで、print文を多用していますが、これはClaude自身が見るためにやっている行為です。もっとも、Pythonを使って分析する人の多くは、Jupyter notebookやJupyterLabを使って確認していることでしょう。

(思考プロセス)ここからはより詳細な分析に入ります。エンゲージメントスコアの分布状況を分析し、数値変数との相関関係を確認します。さらに、カテゴリ変数によるグループ分けが有意な差異を示すかどうかを検証した上で、実際のエンゲージメントを駆動する要因を特定するための回帰モデルを構築します。

回帰分析による探索

回帰分析への足掛かりを得たClaudeは回帰分析に突入します。

(思考プロセス)根本的な問題は構造的なもののようです。部署間の差異があまりにも大きいため、エンゲージメントの違いの大半は個人の特性ではなく、部署要因によるものと考えられます。これらの差異の真の要因を特定するためには、回帰分析を実施し、各部署ごとにパターンを個別に分析する必要があります。
(出力)データの構造が見えてきました。興味深いパターンがいくつも出ているので、可視化して整理していきます。
from sklearn.ensemble import RandomForestRegressor
from sklearn.linear_model import LinearRegression

df = pd.read_csv('hr-toydata-basic-600.csv')

データを再び読み込んでいることから、先ほどの処理との環境の連続性がないこともわかります。また、import文を見るとランダムフォレストと線形回帰を使おうとしていることがわかりますね。

ここで、線形回帰はsklearnのLinearRegressionであることに注目です。統計モデリングをするなら発展性や得られる情報の量から考えてstatsmodelsの方がよさそうですが…。

探索フェーズであるため、予測的な手法で相関の強い変数を探索したいのでしょうか。

回帰式は明示されていませんが、Pythonコードを確認すれば何をやっているのか分かります。早速見てみましょう。

ランダムフォレストの実行コード

Claudeによるランダムフォレストの実行コードは次の通り。

df2 = df.copy()
df2 = pd.get_dummies(df2, columns=['性別','採用種別','最終学歴','部','グレード','成績'], drop_first=True)
drop_cols = ['従業員ID','年度','年代','課','所属コード','所属','入社年度','エンゲージメント']
X = df2.drop(columns=drop_cols)
y = df2['エンゲージメント']
rf = RandomForestRegressor(n_estimators=500, random_state=42, max_depth=8)
rf.fit(X, y)
imp = pd.Series(rf.feature_importances_, index=X.columns).sort_values(ascending=False)
print(imp.head(20).round(4))
print(f"\nモデルR2(学習データ): {rf.score(X,y):.3f}")

このコードを見ると、ホールドアウトのデータ分割もしていないので、記述的分析の目的でモデリングしていることがわかります。カテゴリ変数をダミー化して、importancesを見るというシンプルな探索。

線形回帰の実行コード

続いて、線形回帰の実行コードがこちら。

from sklearn.preprocessing import StandardScaler
num_features = ['年齢','勤続年数','入社時年齢','採用時能力評価',
                'コンピテンシー_マネジメント','コンピテンシー_戦略構想力',
                'コンピテンシー_対人','コンピテンシー_創意工夫',
                'コンピテンシー_チームワーク','コンピテンシー_ストレス耐性',
                'コンピテンシー_専門力','時間外時間数_月平均','年休消化率']
Xn = df[num_features].copy()
sc = StandardScaler()
Xn_s = sc.fit_transform(Xn)
lr = LinearRegression()
lr.fit(Xn_s, y)
coef = pd.Series(lr.coef_, index=num_features).sort_values(key=abs, ascending=False)
print(coef.round(3))
print(f"R2: {lr.score(Xn_s, y):.3f}")

StandardScalerでデータを標準化した後、sklearnのLinearRegressionを使ってモデリングしています。こちらも説明的な分析に見えます。ランダムフォレストのモデルと説明変数が違うことに注意。

探索結果をまとめて作戦を練る

ここまでの分析結果を元に、結論を出すための作戦を練ったようです。

(思考プロセス)休暇日数と残業時間の間に見られる興味深い相関関係について分析しています。データによると、休暇を最小限に抑え、残業も最小限に留めた場合のエンゲージメントスコアは28.4と最も低くなりますが、興味深いことに、休暇を最小限に抑えつつ残業時間を多くした場合、スコアは52.2へと跳ね上がります。
(出力)データの構造が見えてきました。興味深いパターンがいくつも出ているので、可視化して整理していきます。

実はこの時点で、このデータでキーとなる「チームワーク」という点に言及しています。これは素晴らしいと感じました。しかし、セッションの最後にはこれと違う結論に至ることになります。

結論を出すための重回帰分析

ここから、分析レポートをまとめるために分析を加速させます。重回帰を使って仮説を確かめるのでしょう。以下は、説明変数を標準化しないまま投入していますが、その後標準化したモデルも推定しています。

# 部門ダミー入れて重回帰
df_reg = df.copy()
df_reg = pd.get_dummies(df_reg, columns=['部','採用種別','性別'], drop_first=True)
feat = ['勤続年数','採用時能力評価','コンピテンシー_チームワーク','コンピテンシー_対人',
        'コンピテンシー_マネジメント','時間外時間数_月平均','年休消化率',
        '部_開発部','部_研究部','部_経理部','部_総務部','採用種別_新卒','性別_男']
X = df_reg[feat].astype(float)
y = df_reg['エンゲージメント']
lr = LinearRegression()
lr.fit(X, y)

なお、レポート報告された決定係数R2=0.661は標準化しないモデルでの値となっていますが、偏回帰係数の報告は標準化したモデルでの値となっていました。このあたりは少し気になります。

分析レポート「エンゲージメント分析レポート(n=600、2021年度)

ここまでの分析結果をまとめ、きれいな報告書を作ってくれました。

レポートの外観

ぱっと見はとてもしっかりしています。プアなプロンプトとデータを元にノーヒントでここまでできるのは凄いですね。1年前にGeminiで試したときとはかなり様子が違います。

注意すべき点①相関と因果

一方、回帰分析の考察パートを注意深く見ると、記述的な分析結果を元に因果に踏み込んだ考察を導いているように見えました。これは注意が必要です。以下、「最大の改善レバー」という表現が因果を前提にした結論になります。

今回Claudeがとった分析アプローチは記述的な分析であり、因果推論に至るケアはされていません。したがって、言えたとしても相関関係までの考察となるはずで、結論の提示には慎重さが必要です。

注意すべき点②報告内容が入り組んでいる

重回帰結果の報告直後に、「残業時間×年休消化率の交互作用」という話がでてきます。こうしたマトリックスは大変わかりやすく、人事で好まれる傾向もあるためよいですね。

一方、「交互作用」という言葉を聞くと、重回帰で交互作用項を取り入れた分析なのかと感じてしまいました。レポートをよく見ると、この分析は先ほどの重回帰とは独立したもので、単純集計から導かれた結論です。

また、「最悪のパターンは」「静かな離脱」などとキャッチーな言葉が並び、なるほどと感じてしまうかもしれませんが、この分析の根拠はあまり強くありません。

なお、残業が少なく年休消化率が低い層については、本データの設計上は別の仕掛けのもとで生じているパターンです。(特定部署で発生している特異な事象があるのですが…)

注意すべき点③データだけで言えないこと

改善施策の提言内容をよく読んでみると、与えた情報(プロンプトとデータ)だけでは考察できない内容を含んでいることに気づきます。こうした結論を見た人事担当者はどう思うでしょうか。

例えば次の箇所。この考察は非常に厚みがあるように見えますが、組織の文脈に依存することでもあります。少なくともデータだけから読み取るのは難しいはずです。

(出力)優先度1:経理部の構造的テコ入れ(全社平均比-26点) 経理部5課すべてが17〜23点台と、部門全体でエンゲージメント危機の状態です。残業は多くなく年休消化率も81%と高いため、「時間」の問題ではなく業務設計・評価・キャリアパスの問題と考えられます。決算・支払・債権という定型業務の繰り返しが20年以上続く構造、グレードEの20名中20名が経理部所属という昇格停滞、成績D10名が全員経理部という評価の偏りが複合しています。ジョブローテーション、デジタル化による定型業務の再設計、キャリア面談の重点化を推奨します。

今回はプアなプロンプトから結論を出してと無理なお願いをしているので仕方がない側面もあります。しかし、実際のピープルアナリティクスのプロジェクトでは、より対話が進むようなコミュニケーションが求められるでしょう。

指摘によって結論が変わる

さて、上で見たように、一見出来のよさそうな分析レポートではありますが、細かく見ると気になることがでてきます。しかし、Claudeは現時点での結論は揺るがないことを前提に、体裁を整えたり詳細を見たりすることを進めています。

(出力)分析結果をレポート形式のファイル(Word文書など)にまとめる必要があればお知らせください。また、特定の部門や要因について、さらに深掘りした分析も可能です。

因果関係と言えるのか聞いてみる

そこで、問題の核心ともいえる「相関と因果の取り違え」の可能性を指摘してみました。

プロンプト:分析結果はとても興味深いですね。今回発見したデータの関係性は、因果関係と考えてよいでしょうか?

一般的に利用者自身が分析上の正解を知っているわけではないので、柔らかく静かなコメントを入れています。また、LLMは出力に対する問題を厳しく指摘されると固執する場合もあるという記事を読んだこともあり、表現を軽くしてみました。

そうすると、Claudeはここまでの分析の問題点に気づいた様子。

(思考プロセス)ユーザーからは、これらの関係に実際に因果関係があるのかどうかについて疑問の声が上がっていますが、それは正しい直感です。1年分の観察的な人事データだけでは、因果関係を立証することはできません。私はこのデータの限界について正直に認めなければなりません。無作為化も対照群もなく、逆の因果関係や交絡変数が、我々が観察している現象を説明する可能性は大いにあります。

ここから長考モードに入り数分間返ってきませんでした。その分、つぶやきも膨大なものとなり、英語ベースで1,300ワード、8,000字にもなりました。そのままワードに張り付けるとA4で3枚分。実に長い独り言です。とても長いので一部抜粋します。何やら迷っていますね。

(思考プロセス)実際に因果関係を検証するには、自然実験や一部のチームが実施した方針変更を探したり、介入策についてA/Bテストのパイロットを実施したり、理想的には複数年にわたるパネルデータを取得して、固定効果を用いて個人差を調整できるようにしたいところです。データが十分な期間にわたる場合は、グレンジャー因果性検定も役立つでしょう。

現在、分析を十分に理解している相手にこれをどう提示すべきか考えています。これらは相関関係であり、因果関係の主張ではないことを明確に伝え、各関係における主な交絡因子や代替説明を順を追って説明し、その後、実際に因果関係へと導くための証拠がどのようなものかを提示すべきでしょう。

その後、Claudeは先ほどの分析結果が誤りであることを認めます。しかし、そのトーンはやや教育的。ちょっともやもやしますね。

(出力)素晴らしい質問です。この点の認識はデータ活用の成否を分ける重要なところです。結論から申し上げると、今回の発見は相関関係であり、因果関係と断定することはできません。特に人事データでは、相関を因果と誤認して施策を打ち、期待した効果が出ないという失敗が非常に多く発生します。

ここから「なぜ因果関係と言えないのか」の説明を丁寧にしてくれます。非常にロジカルですが、ユーザーがどこまで認識しているかわからない状態にもかかわらず、フルスタックで説明しようとしている印象。もしユーザーが分かったうえで指摘をしたのなら、もっとシンプルに説明してほしいと感じるでしょう。

一方、そうでない場合は、いきなり教育モードになったことに戸惑いを覚えるかもしれません。

いずれにせよ、以下で述べられる制約というのは、初めのレポートの中で言及されるべきでした。というのも、レポートが因果関係に踏み込んだ考察と提言をしていたからです。

(出力)今回の分析には3つの根本的制約があります。
第一に、観察データであって実験データではないことです。誰が経理部に配属されるか、誰が年休を取るか、誰が長く勤続するかは、ランダムに決まっているのではなく、本人の特性・上司の方針・業務の事情によって選択されています。この「選ばれ方」の歪みが、見かけ上の関係を生み出します。
第二に、横断データ(2021年度のみ)であるため、「年休を取ってから」エンゲージメントが上がったのか「エンゲージメントが高いから」年休を取れたのか、時間的前後関係が判別できません。
第三に、観察される相関関係には、常に4種類の可能な説明が並立します。

逆に言えば、私からの指摘がなければ、この分析の問題点は明かされることはなかったでしょう。

提言の修正を依頼

ここまで来ると先ほどのレポートをリバイスしてくれると思いきや、そうではありませんでした。ちょっとしたコメントが添えられて完了。

(出力)今回の「データ分析の発見」はあくまで仮説の候補と位置づけ、次のステップとしてパネルデータ化か小規模パイロットで因果検証を行う設計を推奨します。どの施策候補についてパイロット設計を具体化するか、またはパネルデータ(複数年度)があれば追加分析も可能です。

これでは物足りないので、もう一押ししてみます。とはいえ、これもソフトに。

プロンプト:そうすると、先ほど出してくれた提言の内容が変わるということですね?

そうすると、ようやく提言の見直しをしてくれました。

(出力)はい、ご指摘の通りです。因果関係が識別できていない以上、「確信を持って施策を打つ」アプローチから、「仮説として検証する」アプローチへと軸を変える必要があります。
ただし重要な区別として、発見された"問題のシグナル"(経理部や営業部地方拠点の低エンゲージメントなど)自体は依然として有効です。変わるのは、その問題への「処方箋」の出し方です。直ちに大規模介入を打つのではなく、原因を診断してから検証可能な形で小さく試す、という順序に変わります。

そして、提言は以下のように修正されました。長いので一部抜粋します。

(出力)チームワーク・コンピテンシー育成(元・優先度5) は、最も懸念が大きい提言です。このコンピテンシー評価は上司がつけており、エンゲージメントが高い(前向きな)部下ほど「チームワークが良い」と評価されるハロー効果が強く疑われます。つまり、相関(r=+0.47)が「チームワーク→エンゲージ」ではなく「エンゲージ→チームワーク評価」を反映している可能性が高いです。この場合、チームビルディング研修をいくら実施しても、エンゲージメントは上がらないか、上司評価にしか変化が出ません。この提言は優先度を下げ、介入対象から除外することを推奨します。

この修正済み提言は学説も取り入れてもっともらしく聞こえます。しかし、実のところを言うと、「チームワーク」は今回使ったデータの分析上の肝でした。わかりやすい相関が出ないように工夫していますが、上司のコンピテンシーが鍵を握り、その中でチームワークのスコアが効いてきます。

これはデータ設計上の思想であり一般論ではありません。

感想戦に入るClaude

Claudeは提言を述べた後に、何やらリフレクションを始めます。将棋の感想戦のような雰囲気。

(出力)今回の分析で痛感したのは、1年度の横断データでは因果推論に根本的な限界があるという点です。そのため、次のような基盤整備を最優先事項として加えることを提言します。第一に、従業員IDで紐づく複数年度のパネルデータ化(今回は2021年度のみですが、今後は毎年同じ設計で蓄積)。第二に、退職者への離職理由調査の標準化とデータ化。第三に、人事施策の実施履歴のログ化(どの部署でいつ何を始めたか)。これらが揃えば、来年以降の分析では固定効果モデルや差分の差分法といった因果推論手法が使えるようになり、介入効果を確度高く評価できます。

このコメントは実にまっとうですが、入り方が何とも味があるというか、煙に巻かれている感があって「フハッ」と声が出てしまいました。

まとめ

この記事では。Claudeを使った従業員エンゲージメント分析の詳細を確認し、問題点を整理しました。

シンプルなプロンプトの内容をくみ取り、データから手早くレポートを作ってくれる点は素晴らしいと思います。

しかし、分析プロセスを丁寧に確認してみると、記述的分析と因果推論の取り違えや一貫性の欠如など、問題も見つかりました。

LLMが自律的になればなるほど、それを利用するユーザーの評価スキルが試されることになりそうです。

関連記事:

人事トイデータの公開
こちらのページでは、クニラボで作成した人事トイデータを公開しています。 トイデータとは? トイデータ(Toy Data)とは、演習用に使えるリアルでないデータのことをいいます。データ分析や機械学習のライブラリに附属する場合もあり、手元にデータがなくてもそのライブラリをすぐに試せるのが利点です。 人事データ分析の演習にご活用ください ピープルアナリティクスを学んでみたいが手元に良いデータがない、という方も多いのではないでしょうか。人事データは個人情報を含むため、ピープルアナリティクスプロジェクトの正式なメンバーでないと触ることができません。 そこで、演習用にデータを自作しGoogleドライブより公開しています。これまでも代表のnote記事の中でリンクを張っていたのですが、複数の記事で利用するためこのページを作りました。 * 2023/11/29追記 「HRトイデータ_人事情報_拡張版.csv 」を追加しました。 * 2024/3/23追記 「HRトイデータ_月別時間外.csv 」を追加しました。 * 2024/11/18追記 「HRトイデータ_エンゲージメントスコア
Geminiでピープルアナリティクスを試す
Geminiでデータ分析ができるようになったようですね。Googleスプレッドシートから直接分析できるのであれば結構便利かもしれません。 * 「Google スプレッドシート」でGeminiがデータ分析やグラフ生成を行えるように - 窓の杜 プログラミングの現場には様々な形で生成AIが入り込んできていますが、その流れがデータエンジニアリングやデータ分析の方にもやってくる可能性もあります。 ということで、早速ピープルアナリティクスを題材にGeminiで分析をやってみました。デモ的にざっと流した様子を動画にまとめたので、まずはこちらをご覧くださいませ。 ご覧の通り、Google WorkspaceのGoogleスプレッドシートから直接呼び出す形で実行しています。 自然言語ベースでの作業指示でここまでできるというのはすごいですね。 1年半前にChatGPTのCode Interpreterが登場したときも驚きましたが、そのときよりも洗練されています。 なお、こちらの動画は手早く見えるように編集しているので、実際はもう少し時間がかかっています。キャプチャした動画の元ファイルを確
Excel × Copilotで変わるピープルアナリティクス―内製化のはじめの一歩
Microsoft 365 Copilotを使えば、Excel上で自然言語によるデータ分析が可能になります。実際に試してみたのですが、内部でPythonコードが動いているようで、Excel単体では難しかった統計解析もサクッと実行できることが分かりました。使い慣れたExcelの延長線上で、これほどの分析ができるとは驚異的です! 今回は、ピープルアナリティクスを題材に、Excel × Copilotによる分析の様子をデモ動画にまとめました。まずはこちらをご覧くださいませ。 使用したデータは当サイトで公開中のHRトイデータです。コンピテンシー項目に着目し、主成分分析で次元削減を通して隠れたパターンを探索しています。 使い慣れたExcelを使いながら自然言語で高度な分析を指示できるのは魅力的で、ピープルアナリティクスの内製化の切り札になるのではないかと感じました。その理由は次の通りです。 1. 自然言語で指示ができ、分析に関するコーティングの手間を大幅に削減できる。 2. 多くの企業に普及しているMicrosoft 365上で動作するため、Pythonの実行環境の準備が不要になる。