公益通報の内部窓口でClaudeに通報内容を入力してよいか — 法12条と匿名化の設計

公益通報の内部窓口でClaudeに通報内容を入力してよいかは、何を入力するかで答えが変わります。公益通報者保護の法律12条(以下、法12条)が禁じているのは、通報者を特定させる事項を漏らすことです。通報内容そのものの取り扱いを禁じる条文ではありません。

一方で、通報の文面には通報者が誰かを絞り込める手がかりが混ざりやすく、入力先を選ぶ前に「何を入れないか」を決めておく必要があります。消費者庁の指針とその解説には、この設計に使える具体的な措置が並んでいます。

法12条が守っているのは通報者を特定させる事項

法12条は、通報を受けて調査や是正に当たる人に、正当な理由なく、その業務で知り得た事項のうち公益通報者を特定させるものを漏らしてはならないと定めています(条文の要旨)。

義務を負うのは、事業者が11条1項に基づいて定めた、通報の受付・調査・是正を担う従事者(以下、従事者)と、その経験者です。違反すると、現行法では21条により30万円以下の罰金です。2026年12月1日施行の改正法では、同じ内容が22条に移ります。

対象が広く見える点にも注意が要ります。消費者庁の解説は、受付の連絡先に直接届いた通報だけでなく、従事者の個人メール宛ての通報も、窓口で受け付けたものに含めています。窓口の担当者が自分のメールに届いた通報をそのままClaudeに貼れば、それも義務の射程に入ります。

従事者の定めは、300人超の事業者では義務で、300人以下では努力義務です。ただし努力義務でも、通報者の秘密を守る設計が不要になるわけではありません。

「通報者を特定させる事項」はどこまで含まれるか

解説の注は、この語を「公益通報をした人物が誰であるか認識できる事項」と説明しています。氏名や社員番号が典型例です。性別のような一般的な属性でも、他の事項と照合して排他的に特定の人物だと判断できるなら該当します。

つまり、氏名を消しただけでは足りません。次のような記述が通報文に残っていないかを確認します。

• 「夜勤の3人のうち、その日に在庫棚にいたのは自分だけ」のように、自分の立場や居合わせた状況を示す記述
• 通報者しか知り得ない事実(特定の会議の発言内容や、限られた者だけが見る資料の中身)
• メールの送信元アドレス、受信日時、添付ファイルの作成者情報
• 文体の癖や、過去の相談との重なり

特定の可否は、社内の他の情報との照合で決まります。文面だけを見て「匿名化できた」と判断できるとは限らない点が、この設計の難しさです。

Claudeへの入力は「漏らす」に当たるのか

取得した指針、解説、改正概要の3文書に、生成AIへの言及はありません。Claudeへの入力が12条の「漏らす」に当たるかどうかを直接答える公的な文書は、この範囲では見当たりませんでした。

そのため、断定はできず、設計で論点を避ける組み立てになります。通報者を特定させる事項をClaudeに入力しなければ、入力が「漏らす」に当たるかという問いにそもそも入りません。入力した場合の評価は、契約内容(次節)や社内規程、事案の性質で変わり得るので、法務部門か弁護士の判断を前提にします。

入力を3段階に分ける

実務では、通報の情報を次の3段階に分けると運用しやすくなります。この分類は消費者庁の指針にあるものではなく、指針の措置例を入力の場面に当てはめた整理です。

解説は、通報事案の記録や資料に載る関係者の固有名詞を、仮称表記やマスキングにする例を挙げています。同じ発想で、Claudeに渡す前に仮名へ置き換えます。仮名と実名の対応表は、Claudeに渡さず別の場所で人が管理します。

前処理を機械化して、貼り忘れを減らす

人が目で消すだけでは見落とします。入力前に固有名詞を機械的に置き換える前処理を挟むと、貼り忘れを減らせます。次は、事前に用意した対応表で仮称に置換する最小の例です。実際の通報文ではなく、架空のテキストで動作を確かめてください。

import json, sys
 
# mapping.json: {"実名": "仮称", ...} は人が管理し、Claudeには渡さない
mapping = json.load(open("mapping.json", encoding="utf-8"))
text = sys.stdin.read()
for real, alias in sorted(mapping.items(), key=lambda kv: -len(kv[0])):
    text = text.replace(real, alias)
print(text)

python mask.py < report.txt > report_masked.txt

置換は完全な保証になりません。表に無い表記ゆれ(略称、旧姓、あだ名)は通り抜けます。通報者を絞り込める状況の記述も、この方法では消えません。置換後のテキストを人が読み直す工程を残します。

Claude Codeにこのスクリプトを書かせる場合も、渡すのは架空のサンプルと仕様だけです。実際の通報文を貼って「動作確認して」と頼むと、その時点で入力になります。

閲覧範囲は「必要最小限」を仕組みで決める

指針の解説は、範囲外共有の防止策として、通報事案の記録や資料を閲覧・共有できる者を必要最小限に限定し、その範囲を明確に確認することを挙げています。電磁的に管理する場合は、閲覧できる者の限定と、操作・閲覧履歴の記録が例示されています。記録の保管では、人事異動に伴う適時の権限解除も含めてアクセスに制限をかけると書かれています。

これをClaudeに当てはめるなら、次の3点が設計の中身になります。

1. 通報専用のProjectを作り、非公開にする。TeamとEnterpriseのProjectは、「Only people invited」にすると、招待された人だけが中身を見られます。組織全体に公開する設定にすると、組織内の誰でも見つけて使えるため、通報用途では選びません
2. 招待するのは従事者に限る。従事者でない調査担当者は、通報者を特定させる事項が伝わらないよう、入力する情報と共有範囲を別に設計します
3. 異動・退任時に権限を外す手順を決める。指針の解説が挙げる「適時の権限解除」に当たります

なお、解説には次の注意もあります。調査のヒアリング対象者のように、通報の内容を伝えられただけの人は従事者には当たりません。ただし、その人にも内部規程に基づいて範囲外共有をしない義務があります。Claudeの共有範囲を広げる操作が、範囲外共有に当たらないかも確認します。

契約とプランで入力の前提が変わる

閲覧範囲の次に、入力先のデータの扱いを確認します。

• 商用サービスの利用規約は、AnthropicがCustomer Content(入力と出力)でモデルを学習させてはならないと定めています
• ゼロデータ保持(ZDR)は、無料・Pro・Maxの個人向けプランには適用されません。TeamとEnterpriseの製品画面も対象外です
• Claude Fable 5系(Fable 5.1、Fable 5、Mythos 5.1、Mythos 5)は、30日間のデータ保持が必要な対象モデルで、明示的な許可がない限りZDRでは使えません

通報内容を扱うなら、個人アカウントは避け、管理者が保持期間や削除の設定を握れる商用プランに限る、という選び方が現実的です。ZDRの適用範囲は、ZDR契約のスコープで、Enterpriseの保持期間の設定はカスタム保持期間の手順で扱っています。削除の挙動はTeamとEnterpriseのデータ削除にあります。

ここで大切なのは、契約が守るものと12条が守るものが別だという点です。学習に使われないことは、通報者を特定させる事項が第三者に見られないことと同じ意味ではありません。だから入力そのものを減らす設計が先になります。

Claudeに「通報者は誰か」を推定させない

2026年12月1日施行の改正法は、11条の3で事業者による通報者探索を禁じます。正当な理由なく、公益通報者である旨を明らかにするよう求めることや、公益通報者を特定することを目的とする行為が対象です。

指針は、通報者探索を防ぐ措置として、探索が懲戒処分などの対象になることを定めて周知する例を挙げています。指針の解説は、正当な理由に当たり得る場面として、匿名の通報で、通報者が具体的にどの局面で不正を認識したかを知らないと調査や是正ができない場合を挙げています。この場面でも、問うのは12条の守秘義務を負う従事者です。

Claudeの使い方に引き直すと、次の依頼は避ける対象になります。

• 通報文の文体や語彙から、書いた人を推定させる
• 通報の受信時間帯や、社内のシフトとの照合から候補者を絞らせる
• 過去の別の投書との類似度で、同一人物かを判定させる

どれも通報者を特定することを目的とした使い方で、探索禁止の趣旨に触れます。プロンプトのテンプレートや社内ルールに、この依頼を明示的に除外する一文を入れておきます。

調査依頼で、通報が契機だと伝えない工夫

解説は、調査を従事者以外に依頼するとき、調査の契機が公益通報だと伝えなければ、相手は通報があったことを確定的に認識できず、通報者が誰かを認識することも避けられると説明しています。抜き打ちの監査を装う、といった工夫が例です。

Claudeに調査計画や質問リストを作らせる場面にも同じ考え方を使えます。渡す情報を「通報があった」という前提から切り離し、「ある部署の在庫管理の点検計画」のように、通報を出典としない依頼の形にします。

社内規程に書いておく項目

指針は、内部規程で定めるべき事項を運用の前提にしています。Claudeの利用を扱う規程には、次の項目が入るとぶれが減ります。以下は書き方の例で、自社の事情に合わせた調整と、法務による確認を前提にします。

1. 利用してよいプランとアカウントは、従事者に付与した商用アカウントに限る
2. 入力してはいけない情報(通報者を特定させる事項)と、仮名化の手順
3. 専用Projectの共有範囲、招待できる者、異動時の権限解除の手順
4. 通報者の推定・特定を目的とする依頼の禁止
5. 違反した場合の扱い(懲戒処分などの対象になること)

従事者に対しては、通報者を特定させる事項の取り扱いを特に十分に教育する、と指針が求めています。Claudeの利用ルールも、この教育の項目に含めます。従事者の指定は、書面などで、従事者になること(守秘義務が課され、罰則の適用対象になり得ること)が本人に明らかになる方法で行います。

よくあるつまずき

通報内容の要約を頼んだら、通報者の状況描写まで要約に残った。要約は元の文面の手がかりを圧縮して残すことがあります。要約の依頼に、通報者の立場や状況に関する記述を出力に含めない、という条件を付けます。

仮名化した対応表を、同じProjectに保存してしまった。対応表がClaude側にあると、仮名化の意味が薄れます。対応表は別の場所で人が管理します。

専用Projectを組織全体に公開してしまった。作成時の既定を確認します。非公開への切り替えは、共有設定から行えます。

個人のClaudeアカウントで試しに入力した。個人向けプランはZDRの対象外です。試験でも、実際の通報文は使いません。

まとめ

12条が守るのは通報者を特定させる事項で、Claudeに通報内容の一般的な整理を任せること自体を禁じる条文ではありません。ただし、通報文には通報者が絞り込める手がかりが混ざります。入力を「入れない・仮名化して入れる・そのまま入れる」に分け、通報専用の非公開Projectと従事者だけの閲覧範囲で受け皿を絞るのが、指針の解説と整合する設計です。

生成AIへの入力について公的な明示はなく、判断が分かれる余地は残ります。自社の規程と契約を法務で確認したうえで、まず入力しない範囲を決めるところから始めると、迷いが減ります。弁護士の守秘義務との比較は、Claudeに相談内容を入力しても弁護士の守秘義務は保てるかにあります。相談窓口の記録を整える手順は、ハラスメント相談の一次対応記録の整理が近い題材です。管理者向けのデータ取得の仕組みは、Compliance APIの概要にまとめています。