従業員のメールをClaudeで分析する前に — 通信の秘密と社内モニタリング

従業員のメールやチャットをClaudeに読ませる前に押さえる点は3つです。電気通信事業法4条の「通信の秘密」が誰の通信を対象にしているか、個人情報保護法の利用目的の縛り、そしてモニタリングを社内ルールとして先に定めておくことです。この順に条文と公表資料で確かめ、最後にClaudeへ渡す範囲の決め方を扱います。

ハラスメントの申告や情報漏えいの疑いが出ると、調査担当者は大量のやりとりを読む羽目になります。要約や時系列の整理をClaudeに任せたくなる場面ですが、入力した時点で、会社は従業員の通信内容を取り扱うことになります。

電気通信事業法4条は誰の通信を守っているか

通信の秘密を定める電気通信事業法4条1項は、短い一文です。「電気通信事業者の取扱中に係る通信の秘密は、侵してはならない」。守られる対象は「電気通信事業者の取扱中に係る通信」と書かれています。

この「電気通信事業者」は、同法2条5号が定義しています。電気通信事業を営むことについて、9条の登録を受けた者と、16条1項の届出をした者です。電気通信事業そのものは、2条4号で「電気通信役務を他人の需要に応ずるために提供する事業」とされています。

つまり4条は、通信サービスを他人向けに提供する事業者を名宛人にした規定です。罰則は179条にあり、通信の秘密を侵した者は2年以下の拘禁刑または100万円以下の罰金です。電気通信事業に従事する者が行うと、3年以下の拘禁刑または200万円以下の罰金に重くなります。未遂も罰せられます。

もうひとつ見落としやすいのが164条です。1項は、専ら一の者に役務を提供する事業や、同一構内・同一建物内の設備による事業などを、法の適用から外します。ところが3項が、その事業を営む者の取扱中の通信にも3条(検閲の禁止)と4条は適用されると定めています。適用除外の事業だから4条も関係ない、という読み方は条文上できません。

では、自社のメールシステムはどうなるのでしょうか。従業員に業務用のメールを使わせるだけの会社が、2条4号の「他人の需要に応ずるために提供する事業」を営んでいるとは、条文の言葉からは直ちに読めません。一方で、メール基盤をクラウドサービスとして借りている場合、通信を取り扱う事業者は別に存在します。

どの構成のどの行為が4条の射程に入るかは、メール基盤の契約形態、管理者権限の範囲、エクスポートの方法で変わります。条文だけでは決まらない部分です。調査の前にメールの運用担当と法務が、誰がどの権限で何を取り出すのかを書面で確認する作業が先になります。

有線電気通信法と個人情報保護法も同時に見る

4条だけを見て「社内メールは対象外だから自由に読める」と結論する前に、重なる法令が2つあります。

有線電気通信法9条は、有線電気通信の秘密を侵してはならないと定めます。かっこ書きで、電気通信事業法4条1項または164条3項の通信にあたるものは除かれています。つまり4条が守る通信の外側にある有線電気通信を、受け止める位置づけです。14条は、秘密を侵した者を2年以下の拘禁刑または50万円以下の罰金とします。

個人情報保護法は、通信内容そのものではなく「個人情報の取扱い」に着目します。メールやチャットの本文には、氏名、所属、病歴の示唆、人間関係など、特定の個人に結びつく情報が含まれます。分析のためにClaudeへ入力する行為は、その情報の取扱いにあたります。

実務で先に動くのは、この表の下3行です。17条は利用目的をできる限り特定することを求め、18条は、あらかじめ本人の同意を得ないで、特定した利用目的の達成に必要な範囲を超えて個人情報を取り扱うことを禁じます。法令に基づく場合や、人の生命・身体・財産の保護に必要で同意を得ることが困難な場合など、18条3項に例外はありますが、範囲は限られています。

21条は、個人情報を取得した場合に、利用目的をあらかじめ公表している場合を除き、速やかに本人へ通知または公表することを求めています。社内規程で「業務メールを調査・監査の目的で確認することがある」と公表済みかどうかが、ここに効きます。

モニタリングの社内ルールを先に決める

従業員を対象にしたモニタリングについて、個人情報保護委員会のQ&A(Q5-7)が留意点を示しています。個人データを取り扱う従業者を対象に、ビデオやオンラインでモニタリングを実施する場合の記述です。

• モニタリングの目的をあらかじめ特定したうえで、社内規程等に定め、従業者に明示する
• 実施の責任者と、その権限を定める
• あらかじめ実施のルールを策定し、運用者に徹底する
• 定めたルールに従って適正に行われているかを確認する

加えて、個人情報の取扱いに関わる重要事項を定めるときは、あらかじめ労働組合等に通知し、必要に応じて協議を行うことが望ましいとされています。定めたときは従業者に周知することも望ましいとあります。

この記述は、個人データを取り扱う従業者の監督(24条)の一環としてのモニタリングを想定しています。ハラスメント調査のように、特定の申告を受けて過去のやりとりを読む場面にそのまま当てはまる文言ではありません。ただ、「目的を特定し、規程に書き、責任者を置き、運用を確認する」という骨格は、Claudeによる分析を調査手順に組み込むときにも同じ形で使えます。

ここで押さえたいのは、Claudeの導入が目的の追加を伴う点です。メールを調査担当者が読む運用が規程で明示されていても、「AIサービスに入力して要約させる」ことまで読み取れるかは別の話です。規程の文面に、外部のAIサービスを利用して分析する場合がある旨と、入力する情報の範囲を足しておくと、18条の目的の範囲と21条の公表の両方に対応しやすくなります。

入力する範囲は調査目的から逆算して決める

調査にClaudeを使うかどうかの前に、何を渡すかを目的ごとに決めます。判断の基準は、特定した目的の達成に必要な範囲に収まっているかどうかです。

一番下の行は、Claudeが長いテキストを一度に読めることが、かえって落とし穴になる例です。「全部渡して傾向を見てほしい」という依頼は、目的を特定しないまま取扱いの範囲だけを広げることになり、17条と18条の組み合わせに照らして説明がつきにくくなります。

漏えい調査の行は、メタデータから始める段階設計の例です。送信記録だけで絞り込み、疑いが具体化した件に限って本文を人が確認する流れにすると、Claudeに渡す範囲も、読む人の範囲も狭くなります。

メールやチャットには、体調不良、通院、労働組合の話題などが混ざることがあります。病歴や信条は要配慮個人情報にあたり、取得や第三者提供の扱いが一段厳しくなります。入力前の判断は要配慮個人情報をClaudeに入力してよいかで扱っています。

入力前に氏名と連絡先を落とす

目的に必要な範囲まで絞ったあと、氏名や連絡先を置き換えてから渡す方法があります。手元で実行できる例を示します。

python3 mask_mail.py raw/export.txt masked/export.txt

mask_mail.py は、メールアドレスと電話番号を定型の文字列に置き換え、社員名簿の氏名を連番のIDに変えます。名簿の対応表は別ファイルに出力します。以下は一例です。

import csv
import re
import sys
 
EMAIL = re.compile(r"[\w.+-]+@[\w-]+(\.[\w-]+)+")
PHONE = re.compile(r"0\d{1,4}-\d{1,4}-\d{4}")
 
 
def build_alias(names):
    return {n: f"社員{i:03d}" for i, n in enumerate(names, 1)}
 
 
def mask(text, alias):
    text = EMAIL.sub("[メールアドレス]", text)
    text = PHONE.sub("[電話番号]", text)
    for name, tag in alias.items():
        text = text.replace(name, tag)
    return text
 
 
if __name__ == "__main__":
    names = open("names.txt", encoding="utf-8").read().split()
    alias = build_alias(names)
    raw = open(sys.argv[1], encoding="utf-8").read()
    open(sys.argv[2], "w", encoding="utf-8").write(mask(raw, alias))
    with open("alias_table.csv", "w", encoding="utf-8", newline="") as f:
        csv.writer(f).writerows(alias.items())

この簡易な置換では、姓だけの呼びかけ、愛称、役職名による言及は取りこぼします。出力した masked/ の中身は、人が目で確認してからClaudeに渡す運用が前提です。

また、対応表を会社が保持している限り、置換後のテキストは容易に照合できる情報として個人情報のままです。加工して渡す場合の基準は仮名加工情報と匿名加工情報をClaudeに渡す前の加工にまとめています。

Claude Codeで作業させる場合は、生データと対応表を作業ディレクトリの外に置くのが確実です。同じディレクトリに置くなら、.claude/settings.json の permissions.deny で読み取りを止めます。

{
  "permissions": {
    "deny": ["Read(./raw/**)", "Read(./alias_table.csv)"]
  }
}

Readの拒否ルールは、組み込みのファイルツールに加え、Bashの cat head tail sed などのファイル読み取りコマンドにも適用されます。一方、grep -r のようにファイルを名指ししないコマンドや、PythonやNodeのスクリプトが自分でファイルを開く場合は対象外です。すべてのプロセスからのアクセスを止めたいときは、サンドボックスの有効化が必要になります。

CLAUDE.mdには、分析時の約束事を書いておきます。

## メール分析の約束事
- 入力は masked/ 配下のファイルだけを使う
- 人物は社員NNN のIDで呼び、実名の推測や復元をしない
- 要約・指摘の各項目に、根拠になった元メッセージのIDを併記する
- 申告内容に無関係な私的な話題は要約に含めず、件数だけ報告する

根拠のIDを併記させる約束は、出力を調査担当者が元メールに戻って確かめるための仕掛けです。Claudeの要約をそのまま判断材料にせず、元の記録と突き合わせる前提を手順に埋め込めます。

契約プランと保持期間を確認する

入力した内容がAnthropic側でどう扱われるかは、プランで変わります。Claude Codeのデータ利用ページでは、Team・Enterprise・APIなどの商用利用では、顧客がモデル改善への提供を選んだ場合を除き、Claude Codeに送ったコードやプロンプトで生成モデルを学習しないと説明されています。

保持期間も分かれます。Free・Pro・Maxの個人向けプランは、モデル改善にデータ利用を許可する場合は5年、許可しない場合は30日です。Team・Enterprise・APIの標準は30日で、対象を満たすEnterpriseアカウントには、組織ごとに有効化されるゼロデータ保持(ZDR)があります。標準のEnterpriseプランには含まれません。

また、Claude Codeはセッションの記録を ~/.claude/projects/ に平文で、既定では30日間ローカル保存します。期間は cleanupPeriodDays で調整できます。従業員の通信内容を入力した場合、その写しが調査担当者の端末に残る点も、閲覧者の限定(安全管理措置)と合わせて確認が要ります。

業務で従業員のデータを入力する場合は、個人向けプランと商用プランで学習利用と保持期間の扱いが違う点が、契約形態を選ぶ材料になります。個人向けプランの学習設定はClaudeを学習させない設定で確認できます。委託の枠に収まるかどうかは、個人情報保護法27条の第三者提供との関係で整理した個人情報を含むプロンプト入力は第三者提供にあたるかが参考になります。

個人情報保護法25条は、個人データの取扱いを委託する場合に、委託先への必要かつ適切な監督を求めています。Claudeを分析基盤に組み込むなら、委託先の安全管理を確認した記録を残す担当者を、モニタリングの責任者とは別に置いておくと、調査の最中に確認作業が詰まりません。

まとめ

電気通信事業法4条の通信の秘密は、電気通信事業者の取扱中に係る通信を対象にした規定です。自社のメール基盤がこの範囲に入るかは、契約形態と権限の確認が要る問いで、条文だけでは決まりません。4条の外側には有線電気通信法9条があり、さらに個人情報保護法の利用目的の縛りと安全管理が、日常の運用で先に効いてきます。

Claudeへの入力は、モニタリングの目的、責任者、ルールを規程に書いたあとの話です。渡す範囲は調査目的から逆算して絞り、氏名や連絡先を置き換え、生データと対応表をClaudeの手が届かない場所に置きます。商用プランの保持期間と、端末に残るセッション記録の期限まで確認しておけば、調査の途中で運用の穴が見つかる事態を減らせます。