従業員分析：ユーザー単位の AI 利用状況

経営者が知りたいことはシンプルです。どの従業員が AI を使い、何のために使い、どれだけコストがかかっているのか。DuDuClaw はすでに収集している token 使用量テレメトリを使ってこれに答えます。今ではエンドユーザーごと、チャネルごとに帰属させられるようになりました。

プライバシーの境界線（まずここを読んでください）

この機能が可視化するのは会社の AI リソース利用状況であり、企業がすでに社内メールや VPN アクセスのログを監査しているのと同じ種類の情報です。監視にならないよう、二つのルールがあります。

まず集計を見る。 デフォルトの画面はユーザーごとの合計値（リクエスト数、token 数、コスト）です。個々のメッセージ内容が利用レポートに出ることはありません。
詳細を見るには operator 権限が要る。 特定の人物が何を尋ねたかを掘り下げることは operator 権限の操作であり、その操作自体も監査対象です。

個人をスコアリングしたりフラグ付けしたりする下流機能（質問の質のコーチング、私的利用の検知）はすべて opt-in であり、デフォルトでは無効で、「あくまで注意喚起のためであり、懲戒の根拠には決してしない」と文書に明記されています。

ユーザー単位のコスト帰属

現在ではすべての channel reply が、agent と token 数に加えてエンドユーザー id とチャネルも記録します。token_usage テーブルは冪等な migration によって二つの追加カラム（user_id、channel）を得ました。既存の行はそのまま動作し続け、単に未帰属として読み出されるだけです。

問い合わせ方法：

> cost_users            # MCP ツール、admin スコープ
{ "hours": 24 }

コストの高い順にユーザーが返ってきます：

[
  { "user_id": "u-alice", "total_requests": 42, "total_input_tokens": 130000,
    "total_output_tokens": 8000, "total_cost_millicents": 5400 },
  { "user_id": "(system)", "total_requests": 12, ... }
]

(system) は、エンドユーザーが存在しない非人間トラフィック（sub-agent dispatch、evolution、utility 呼び出し）をまとめて受け止める区分です。

現時点で帰属している範囲

channel-reply の経路（大半のチャネルが共有する入口）はユーザーとチャネルを帰属させます。人間のユーザーが存在しない経路（sub-agent dispatch、cron、evolution）は、設計上すべて (system) として記録されます。各チャネルに残るメディア／ツール系の子経路を同じ帰属機構へつなぎ込む作業は、現在も進行中の洗い出し作業です。まだつながっていない経路でも、支出は引き続きその agent に計上されます。特定のユーザーに帰属していないだけです。

ロードマップ（opt-in、デフォルト無効）

質問の質のコーチング。 定期バッチが、安価なモデルを使って各ユーザーのメッセージの一部をサンプリングし評価（明確さ、実行可能な目標があるか）した上で、「研修を勧める」リストを提示します。集計スコアのみで、メッセージ本文はリストに含まれません。
利用異常フラグ。 既存の burn-rate 異常検知の計算式を使い、自分自身のベースラインから N シグマ乖離した支出をしているユーザーにフラグを立てます。意味的な判断は一切行わないため、誤った疑いをかけるリスクはありません。
私的利用の検知（意味解析ベース）。 誤検知を防ぐガードはすでに実装済みです（workforce_private.rs）。operator が定義した業務範囲のベースラインがなければ実行を拒否し（fail-closed）、確信度の高い「私的利用の疑いあり」のみをフラグし（「判定不能」を出すことは決してない）、除外リストを尊重し、未確認のフラグは 30 日で自動失効します。フラグはあくまで助言的なもの（原文表記は「建議關注」＝要注意の目安）であり、従業員本人には見えず、懲戒の根拠にしないことも明記されています。Haiku による分類バッチと operator 専用のレビュー UI は、これらのガードの上に構築されています。