内部通報の窓口に届いた通報を、事実・要望・対象者に分けて、通報者を伏せた調査担当向けの要約と初動の確認事項を作る

処理の起点を決める

台帳に受付番号が登録されたことを起点にします。 従事者が受付番号を振り、文面（電話のメモ、書面のスキャンの文字）を入れた時点で動きます。通報の受付そのものは人が行い、AIに渡す前に必ず従事者の手を通します。 通報者が自分で入力したフォームの文面がそのままAIに流れる経路は作りません。

定時のまとめ処理にはしません。 生命や身体に関わる通報が混ざることがあり、夜にまとめて処理すると、急ぎのシグナルに気づくのが翌朝になります。 受付のたびに1件ずつ動かします。

通報者から追加の情報が届いたときは、同じ受付番号に追記し、追記の時点で受付記録の案を作り直します。 作り直した案は前の案を上書きせず、版として残します。

入力データを集める

質を決めるのは、通報者の特定事項と組織図の2つです。 特定事項が台帳に項目として分かれていれば、AIに渡す前に機械的に置き換えられます。組織図が無いと、対象者が幹部かどうかをAIの推測に頼ることになります。幹部かどうかは組織図で決め、AIには決めさせません。

「書面による通報か」を属性として持つのは、指針の求めのためです。 指針は、書面により内部公益通報を受けた場合、是正に必要な措置をとったときや通報対象事実がないときは、その旨を通報者に速やかに通知することを求めています。通知が要る事案かどうかを、受付の時点で台帳に残します。

データの取得方法を決める

置き換えは、文字列の一致で機械的に行います。 氏名は姓だけ・名だけ・ふりがなの形でも探し、［通報者］ に替えます。社員番号、内線番号、メールアドレス、携帯電話の番号も同じです。置き換えた箇所の数を記録し、0件のときは「顕名なのに文面に氏名が無い」か「匿名」かを確かめます。

組織マスタは読み取りだけです。 AIが返した対象者の記述（「製造二課の課長」）から部署と役職を引き、役員・部長以上なら「幹部の関与」の印、調査を担当しうる部署の責任者なら「利益相反の候補」の印を規則で付けます。氏名で引かず、役職と部署で引きます。

AIへ渡す前に整形する

1. 文字の取り出し … 書面はスキャンして文字にします。読めない箇所は ［判読不能］ と書き、推測で埋めません
2. 特定事項の置き換え … 氏名・社員番号・連絡先を置き換え記号に替えます
3. 追記の並べ方 … 最初の通報と追記を受付日時の順に並べ、区切りに日時を入れます
4. 外部窓口の転送文の扱い … 法律事務所が書いた前書きと通報者の言葉を分け、通報者の言葉だけを「通報の文面」にします
5. 長さの確認 … 極端に長い文面は分割せず、そのまま渡します。分割すると、前半と後半で同じ人物が別人として扱われます

2番目は、置き換えで終わりではありません。 置き換えは名前や番号のように文字列で分かるものにしか効きません。「私だけが担当している取引先」のような記述は残ります。 それを拾うのが、次の小見出しのAIの仕事です。

AIに処理させる

させるのは、通報の文面を決まった欄に整理することと、通報者を特定させうる記述の候補と急ぎのシグナルを挙げることです。

1行目の「見たのか、聞いたのか、推測か」が、調査担当にとっていちばん大事な区別です。 「課長が水増しを指示したらしい」と「課長が水増しを指示するのを会議で聞いた」では、調査の進め方がまったく違います。区別を付けずにまとめると、伝聞が事実として調査担当に渡ります。

最後の行の「通報者を特定しようとする質問を入れない」は、法の求めです。 改正法は、正当な理由がなく公益通報者を特定することを目的とする行為を禁じています（第11条の3）。「あなたの所属を教えてください」のような質問を、AIが善意で作らないようにします。

4行目を明記しておかないと、AIは手がかりから人物を推測した文を書くことがあります。 「経理の夜勤は2名なので、通報者はそのどちらかと考えられます」という一文は、書いた瞬間に通報者探索の材料になります。

指示内容を固定する

あなたは内部通報の窓口で、受け付けた通報を調査に回す前に整理する補助をします。
渡された通報の文面に書かれていることだけをもとに整理してください。推測で埋めないでください。

【整理する欄】
1. facts：出来事を1つずつ。when／where／who（役職・部署）／what と、
   source（seen＝本人が見た／heard＝人から聞いた／inferred＝本人の推測）
2. requests：通報者が望んでいること
3. subjects：行為をしたとされる人の役職・部署
4. identifying_passages：通報者を絞り込めるかもしれない記述と、その理由
5. urgent_signals：生命・身体への危険、証拠の廃棄・改ざんのおそれ、継続中の行為が
   書かれている箇所
6. questions：調査に要るのに書かれていない点を、通報者に尋ねる質問

【厳守事項】
- 書かれていない欄は空にしてください。一般的な傾向から補わないでください。
- source は文面の言い方で決めてください。「らしい」「と聞いた」は heard、
  「と思う」「ではないか」は inferred です。迷ったら seen にしないでください。
- identifying_passages と urgent_signals の quote には、文面の文字列をそのまま写してください。
  言い換えや要約をしないでください。
- 通報者が誰かを推測しないでください。「通報者は○○と考えられる」のような文を
  どの欄にも書かないでください。
- 通報者の所属・氏名・立場を尋ねる質問を questions に入れないでください。
- 公益通報に当たるか、調査すべきか、事実かどうかを書かないでください。
- ［通報者］［対象者A］などの置き換え記号は、そのまま使ってください。元の名前を推測しないでください。
- 対象者の氏名が文面に残っていた場合は、［対象者A］［対象者B］に置き換えて書いてください。

【受付の属性】{intake_meta}
【通報の文面（追記を含む、受付日時の順）】{report_text}

「通報者が誰かを推測しない」を明記しないと、親切に推測します。 文面に「私のチームは3人」と書かれていれば、AIは整理の一環として「通報者は3人のうちの1人」と書きがちです。禁じるのは、推測を文にすることそのものです。

「迷ったら seen にしない」も同じ理由です。 伝聞と推測を見たこととして整理すると、要約の段階で通報の確からしさが上がって見えます。

出力形式を固定する

Claude API の構造化出力で、次の形のJSONを受け取ります。

{
  "facts": [
    { "when": "", "where": "", "who": "", "what": "",
      "source": "seen | heard | inferred", "quote": "" }
  ],
  "requests": [ "" ],
  "subjects": [ { "label": "［対象者A］", "role": "", "department": "" } ],
  "identifying_passages": [ { "quote": "", "reason": "" } ],
  "urgent_signals": [ { "type": "life_safety | evidence | ongoing", "quote": "" } ],
  "questions": [ "" ]
}

1つ目の理由は、quote を原文と照らせることです。 プログラムが quote の文字列が通報の文面にそのまま含まれるかを確かめ、含まれなければ「引用不一致」の印を付けて従事者に回します。 公式の説明では、構造化出力と Citations は併用できず、両方を指定すると 400 のエラーになるとされています。引用の正しさは、Citations ではなくプログラムの照合で担保します。

2つ目は、source で受付記録と要約の書き分けが機械的にできることです。 調査担当向けの要約では、heard と inferred の行に「（伝聞）」「（通報者の推測）」を自動で付けます。

3つ目は、subjects の role と department を組織マスタで引けることです。 幹部の関与と利益相反の印は、ここから規則で付けます。

調査担当向けの要約の案は、このJSONからプログラムが次の形に組み立てます。

【受付番号】2026-10-0123　【受付の入口】受付フォーム（匿名）
【事実】
・2026年9月ごろ、製造二課で、［対象者A］（課長）が検査記録の数値の書き換えを指示した（伝聞）
・同月、検査の記録用紙が通常と違う保管庫に移されていた（通報者が見た）
【対象者】［対象者A］製造二課・課長
【通報者の要望】調査と是正。匿名の維持
【初動の確認事項】証拠の所在の確認が要る可能性（記録用紙の保管場所の記述あり）
【伏せる候補】2か所（従事者が判断済みのものだけを残す）

伏せる候補の本文は、従事者が判断を終えるまで要約に入りません。 判断を終えた記述だけが、伏せた形か言い換えた形で要約に入ります。

公式の説明では、構造化出力のスキーマはキャッシュのため最長24時間保持されることがあるとされています。スキーマのプロパティ名や enum に、通報の内容や人名を入れません。 また、安全上の理由で応答が拒否されたときは stop_reason が refusal になりスキーマに沿わないことがあるとされているので、stop_reason を確かめ、end_turn 以外は案を置かずに従事者へ回します。

システムへ連携する

台帳から外へは、何も自動で送りません。 調査担当への要約の受け渡しも、責任者への報告も、従事者が行います。この構成が書き込むのは台帳の案の欄だけで、確定した受付記録は従事者が保存します。

初動の確認事項は、規則とAIの結果を並べて1枚にします。

幹部の関与の印が付いた事案は、指針の求める独立性の確保の経路（たとえば監査等委員会への報告の経路）に回すかを、責任者と決めます。 どの経路に回すかは内部規程によります。

人が確認する

全件を従事者が確認します。 この業務は、件数が少なく、1件の誤りが重い業務です。

1. 受付記録の案を原文と見比べる … source の区別が正しいか、抜けている出来事が無いか。「引用不一致」の印は最初に見ます
2. 特定させうる記述を1つずつ決める … 伏せる、言い換える、残す、のどれか。AIが挙げなかった記述も、職場の事情を知る目で探します
3. 初動の確認事項を責任者と見る … 幹部の関与、利益相反、急ぎの対応、書面による通報の通知
4. 聞き直しの質問を選ぶ … 通報者に送る質問を選び、言い方を直します。特定につながる質問が混ざっていないかを確かめます

2番目を省かないでください。 AIは文面だけを見ていて、その部署に何人いて、誰がその会議に出ていたかを知りません。 候補はあくまで見落としを減らすための補助です。

目標は、40件をならして1件30分です。 文面の整理と書き直しが案を直す作業に変わり、伏せる判断と初動の相談が残ります。

例外に対処する

1行目だけは、ほかと扱いが違います。 急ぎのシグナルは、案ができるのを待つ理由がありません。 シグナルが1つでもあれば、案の確認より先に人を動かします。

記録を残す

• 受付番号ごとの原文（追記を含む）と受付の属性
• 置き換えの記録（置き換えた箇所の数と種類。置き換え前の文字列は台帳の特定事項の欄にだけ残す）
• Claude API が返したJSONの全文と stop_reason、使ったモデル
• 引用の照合の結果と、規則で付けた印
• 従事者が直した記録 … どの欄をどう直したか、どの記述を伏せたか
• 調査担当に渡した要約の版と、渡した日時・相手

最後の行は、範囲外共有を防いだことを後から示すための記録です。 誰に、どの版を、いつ渡したかが残っていれば、通報者を特定させる事項が必要最小限の範囲にとどまっていたかを確かめられます。指針は記録の作成と適切な期間の保管を求めており、保管の期間は内部規程で決めます。

ログを見られるのも従事者だけです。 情報システム部門の運用の担当がログの置き場所を管理する場合も、中身を読めない形にしておきます。