LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム開発・保守を受託

内部通報システムとは、受付から是正までを秘匿性を保ちつつ管理する仕組み

内部通報システムとは、組織内の不正やハラスメント、コンプライアンス違反に関する通報を受け付け、受理・調査・是正・記録までを一元的に管理する仕組みです。単なる問い合わせ窓口とは性質が異なり、通報者を保護しながら事実確認を進める点に固有の難しさがあります。とりわけ通報者の秘密保持と匿名性の確保が、設計全体を貫く前提条件になります。

通報の受付経路は、Webフォームや専用アプリ、電話、書面など複数にわたります。受け付けた案件は通報者を特定させる情報を最小限の担当者だけが扱えるよう秘匿化され、そのうえで調査・是正へと進む流れです。調査を担う者が通報の対象者と利害関係にある場合、公正な確認が期待しにくくなるため、利益相反の排除も欠かせません。最後に対応の経緯を証跡として残し、経営層への統計報告につなげます。

こうした一連の流れをシステムで支えるには、通常の業務システムとは別のアクセス設計が求められます。誰が案件を閲覧でき、どの情報が誰まで届くのかを厳密に区切ることが、通報者保護の実効性を左右するためです。次章では、その前提となる法制度を整理します。

公益通報者保護法の改正で義務化されたこと——2022年6月施行の要点

内部通報システムの設計を考えるうえで、出発点になるのが公益通報者保護法です。同法を改正する法律は、2022年6月1日に施行されました^*1*2。この改正により、常時使用する労働者の数が301人以上の事業者には、内部公益通報に適切に対応するために必要な体制の整備が義務づけられています^*1*3。300人以下の事業者については、同じ体制整備が努力義務とされています^*3。

体制整備義務の中身は、大きく二つに分かれます。一つは、公益通報を受け、調査し、是正措置をとる業務を担う「公益通報対応業務従事者」を定めること^*3。もう一つは、通報を受け付ける窓口の設置や、通報者を保護するための措置など、内部公益通報対応体制そのものを整えることです^*3。従事者の指定は法第11条第1項に、体制整備は同条第2項に根拠があります^*4。

通報者保護の要となるのが、従事者に課される守秘義務です。従事者またはその職にあった者は、正当な理由がなく、公益通報者を特定させる事項を漏らしてはならないと定められています^*4。これに違反した場合、30万円以下の罰金が科されます^*1*4。事業者側の情報管理の甘さが、担当者個人の刑事責任に直結しうる構造だといえるでしょう。

さらに、公益通報をしたことを理由とする解雇は無効とされ、降格や減給などの不利益な取扱いも禁じられています^*1*4。この不利益取扱いの禁止は、体制整備が努力義務にとどまる中小規模の事業者を含め、すべての事業者に適用される点に留意が必要です^*1。義務化された体制整備の具体的な内容は、消費者庁が策定した指針とその解説に示されています^*3。

設計要件の核——匿名性・秘密保持・アクセス権限の分離

匿名性——通報者が名乗らずに通報でき、その後もやり取りできる

内部通報システムでまず問われるのが匿名性です。通報者が氏名を明かさずに通報できることに加え、匿名のまま調査担当者と追加のやり取りを続けられる仕組みが望まれます。匿名の受付だけを用意しても、その後の事実確認で連絡が取れなければ調査が滞るためです。匿名IDやメッセージ機能を介して、身元を伏せたまま双方向のやり取りを成立させる設計が、実務では有効に働きます。

秘密保持——通報者を特定させる情報を範囲外に共有しない

消費者庁の指針は、通報者を特定させる事項を、必要最小限の範囲を超えて共有すること（範囲外共有）を防止する措置を求めています^*3。あわせて、通報者は誰かを詮索する「通報者の探索」を防止することも要件に含まれます^*3。システム側では、通報内容と通報者の識別情報を分離して保持し、調査担当者には識別情報を伏せた形で内容だけを見せるといった制御が考えられます。

アクセス権限の分離——閲覧・編集・記録の権限を役割ごとに区切る

秘密保持を担保するには、誰がどのデータにアクセスできるかを役割単位で厳密に分けることが前提です。受付担当、調査担当、承認者、監査役といった役割ごとに、閲覧・編集・記録の権限を細かく設定します。とくに通報対象者が管理職や役員である場合、その人物や近しい部署のアカウントから案件が見えない設計にしておく必要があります。指針が求める利益相反の排除は、運用ルールだけでなく、権限設計として実装しておくと確実です^*3。

受付から是正まで——案件管理・対応記録・期限管理の要件

通報を受け付けた後、その案件をどう追跡するかも設計の重要な論点です。内部通報システムは、受付・受理・調査・是正・完了といったステータスを案件ごとに管理し、対応の抜け漏れを防ぐ役割を担います。誰がいつ何を行ったかを時系列で記録し、対応の経緯を後から検証できる状態にしておくことが求められます。

対応記録は、証跡としての性質を帯びるものです。通報を受けてからの調査内容、判断の根拠、是正措置の履歴を残すことで、事後の説明責任に応えられるようになります。ここで改ざん防止の観点が効いてきます。記録が後から書き換えられる余地があると、証跡としての信頼性が損なわれるためです。更新履歴を保持し、削除や上書きの痕跡が追える仕組みが望ましいでしょう。

期限管理も欠かせない機能です。通報を受け付けたまま長期間放置されると、通報者の不信を招くだけでなく、体制が機能していないと評価されかねません。受付からの経過日数を可視化し、一定期間を過ぎた案件を管理者へ通知するなど、対応の停滞を検知する仕組みも有効です。ハラスメントや会計不正といった通報の類型ごとに、想定される対応フローを分けて管理する設計も検討に値します。

これらの記録を集計すれば、通報件数や類型の傾向、対応状況を経営層へ報告する資料にもなります。個々の通報者を特定させない粒度で統計化し、コンプライアンス体制の実効性を経営が把握できるようにすることが、報告機能の目的です。

パッケージとスクラッチの判断軸——SaaS・社外窓口の使い分け

内部通報の仕組みを整える際、既製のパッケージ（内部通報SaaSや外部窓口サービス）を使うか、スクラッチで開発するかは悩みどころになります。両者は前提とする事情が異なるため、自社の状況に照らして見極めることが大切です。

導入の速さや法改正への追随を重視するなら、パッケージや社外窓口サービスが選びやすい選択肢になります。社外窓口を利用すると、受付を担うのが自社と利害を持たない第三者になるため、通報者が社内の目を気にせず通報しやすいという利点も見込めます。指針は、中立性・公正性に疑義が生じるおそれや利益相反のおそれがある場合の措置を求めており、社外窓口はこの観点でも一定の意味を持ちます^*3。

一方、既存の人事システムや監査ワークフローと深く連携させたい場合や、自社固有の通報類型・承認フローを組み込みたい場合は、スクラッチ開発に分があるでしょう。両者は排他的ではなく、社外窓口で受付だけを外部化し、案件管理は自社システムで行うといった組み合わせも実務では珍しくありません。自社の通報件数の見込み、既存システムとの接続要件、社内リソースを踏まえて切り分けることになります。

外注で確認すべき点——匿名性の担保・権限分離・改ざん防止

内部通報システムの構築を外部に委託する場合、通常の業務システム以上に確認すべき点が増えます。扱う情報が通報者の身元という機微なものであり、設計の甘さがそのまま法的リスクに転じるためです。委託先の選定にあたっては、次の三点を重点的にすり合わせることをおすすめします。

第一に、匿名性と秘密保持がどう技術的に担保されるかです。通報内容と通報者の識別情報が分離して管理されるか、範囲外共有を防ぐアクセス制御が実装されるかを、仕様レベルで確認します^*3。第二に、アクセス権限の分離です。役割ごとの権限設計に加え、通報対象者やその関係者を案件から遮断する利益相反排除の仕組みが盛り込まれているかを見極めます^*3。

第三に、証跡と改ざん防止です。対応記録の更新履歴が保持され、後からの書き換えが検知できる設計かどうかを確認します。加えて、システムの保守を担う委託先の技術者自身が、通報者を特定させる情報へ不用意にアクセスできない運用になっているかも論点です。開発・保守の過程で機微情報に触れる可能性がある以上、委託先との間で守秘の取り扱いや監査ログの整備を取り決めておくことが欠かせません。

委託先が公益通報者保護法の趣旨を理解し、指針が求める措置を設計へ落とし込めるかどうかが、選定の分かれ目になります。受付窓口の外部委託先が通報者を特定させる情報を扱う場合、その委託先が従事者として定められることもあり得ます^*3。契約の段階で、こうした役割と責任の範囲を明確にしておくと、後々のトラブルを抑えやすくなります。

まとめ：内部通報システムの設計で押さえる3つの要点

本稿では、内部通報システムの設計要件を、公益通報者保護法の体制整備義務に沿って整理しました。要点は三つに集約できます。第一に、2022年6月施行の改正法により、従業員301人以上の事業者には内部公益通報対応体制の整備が義務づけられ、従事者の守秘義務違反には30万円以下の罰金が定められています^*1*4。第二に、設計の核は通報者の匿名性・秘密保持・アクセス権限の分離であり、指針が求める範囲外共有の防止や利益相反の排除を、運用と実装の両面で担保する必要があります^*3。第三に、パッケージと社外窓口、スクラッチの切り分けは自社の要件しだいで、外注時は匿名性・権限分離・改ざん防止の担保を委託先と丁寧にすり合わせることが肝要です。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：消費者庁「公益通報者保護制度」（https://www.caa.go.jp/policies/policy/consumer_partnerships/whisleblower_protection_system/）
2. *2　出典：消費者庁「公益通報者保護法と制度の概要」（https://www.caa.go.jp/policies/policy/consumer_partnerships/whisleblower_protection_system/overview/）
3. *3　出典：消費者庁「公益通報者保護法に基づく指針（令和3年内閣府告示第118号）の解説」（令和3年10月）（https://www.caa.go.jp/policies/policy/consumer_partnerships/whisleblower_protection_system/overview/assets/overview_211013_0001.pdf）
4. *4　出典：e-Gov法令検索「公益通報者保護法（平成十六年法律第百二十二号）」（https://laws.e-gov.go.jp/law/416AC0000000122/）

Tweet