内部通報窓口SaaSの利用規約：通報者を守る約束と、事業者の義務の線引き

結論：窓口SaaSは「通報を受け付ける道具」。法が事業者に課す体制整備を、提供者が代わりに引き受けるわけではない

内部通報の窓口を、クラウドのシステムとして提供するサービスがあります。通報フォームを用意し、通報の内容と、通報者とのやり取りを記録し、担当者に通知する仕組みです。人が受付や一次対応を行う外部の窓口サービスと組み合わせて提供されることもあります。こうしたサービスの利用規約は、通常のSaaSの規約と比べて、通報者を守る仕組みを、契約でどこまで約束するかが中心になります。通報者の氏名や、通報の内容が、通報の対象となった側に漏れれば、通報者は不利益を受けるだけでなく、窓口そのものが信頼を失うからです。

最初に押さえておきたいのは、公益通報者保護法が体制整備の義務を課している相手は、「事業者」であり、窓口のシステムを提供する者ではないという点です。窓口SaaSの提供者が担えるのは、事業者が義務を果たすための道具の部分です。この線引きを規約で曖昧にすると、事業者側は「システムを入れたから体制は整った」と考え、提供者側は「法的な責任は事業者にある」と考えて、通報が来たときにどちらも動けないという事態になり得ます。

このページでは、次の6点を順に説明します。

1. 事業者の体制整備の義務と、提供者が担う範囲・担わない範囲の書き分け。
2. 通報者を特定させる情報の秘匿と、提供者の従業員がアクセスできる場面の限定。
3. 匿名化・統計化した通報データを、提供者が自分の目的で使う場合の条件。
4. 通報の内容の真偽、不正な通報、大量の投稿、受付ができなくなる障害の扱い。
5. 契約終了や無料期間の終了のとき、通報データと窓口がどうなるか。
6. 約款として整える場合の位置づけ、優先順位、変更の定め。

委託先としての個人情報の一般的な定めは委託先・個人情報のページ、責任の上限の考え方は責任制限のページ、契約終了時のデータの扱いの一般論は返還・削除のページで扱っています。ここでは、通報窓口に固有の部分に絞ります。以下は一般的な情報で、条文は現行のものを基にしています。公益通報者保護法は、令和7年（2025年）6月11日に改正法が公布され、2026年12月1日に施行される予定です（e-Gov法令検索の改正履歴による）。本稿は現行（2026年10月時点で施行されている）条文によっており、改正後の内容は、条文と所管官庁（消費者庁）の資料で確認が必要です。

体制整備の義務は事業者のもの。提供者が担う範囲を書き分ける

公益通報者保護法11条は、事業者に次の二つを求めています。第一に、公益通報を受け、通報の対象となる事実の調査をし、その是正に必要な措置をとる業務（公益通報対応業務）に従事する者を定めること（1項）。第二に、公益通報者の保護を図るとともに、公益通報の内容の活用により法令の遵守を図るため、公益通報に応じ、適切に対応するために必要な体制の整備その他の必要な措置をとること（2項）です。ただし、常時使用する労働者の数が300人以下の事業者については、いずれも「定めるように努めなければならない」「とるように努めなければならない」と、努力義務になります（3項）。内閣総理大臣は、事業者がとるべき措置について、指針を定めることとされています（4項）。また、内閣総理大臣は、必要があると認めるときは、事業者に対して報告を求め、または助言、指導もしくは勧告をすることができ（15条）、勧告に従わなかった場合は、その旨を公表することができます（16条）。

これらの義務の主語は、すべて「事業者」です。窓口SaaSの契約者である事業者は、システムを導入しただけでは義務を果たしたことになりません。誰を従事者に定めるか、通報を受けてどう調査し、是正するか、通報者に不利益な取扱いをしないよう、どう周知し、徹底するか。これらは事業者が決めることです。指針や、その解説に書かれている具体的な措置の内容は、消費者庁の資料で確認が必要です。

表のとおり、提供者が引き受けるのは、機能と情報の保護です。規約には、事業者が公益通報者保護法その他の法令に基づく義務を、自らの責任で履行すること、提供者は通報の内容の真偽、調査の結果、事業者の対応の結果について責任を負わないこと、を明記します。これは提供者を守るための条項であると同時に、事業者に「体制整備は自分の仕事だ」と認識させる効果があります。

人が受付を行う外部窓口サービスについては、提供者側の担当者を、事業者が定める従事者として扱う必要があるのかなど、指針と、その解説に沿った整理が必要です。ここで、確認が必要な事項を挙げておきます。

• 外部の担当者が通報を受ける場合に、事業者の従事者として定める手続（誰が、どの形式で定めるか）。
• 通報者の氏名その他の通報者を特定させる情報を、事業者に伝えるかどうかの判断と、通報者の同意の取り方。
• 外部窓口の担当者に対する守秘義務の課し方と、退職後も続く義務。
• 是正のための調査を、外部窓口と事業者のどちらが行うか。

通報者を特定させる情報の秘匿：アクセスできる人を、契約で限る

公益通報者保護法12条は、公益通報対応業務従事者または従事者であった者が、正当な理由がなく、その公益通報対応業務に関して知り得た事項であって公益通報者を特定させるものを漏らしてはならない、と定めています。違反した場合には罰則があります（21条）。この義務を負うのは、事業者が従事者として定めた者です。窓口SaaSの提供者の従業員が、この従事者に当たるかどうかは、事業者がどのように定めるかによります。そのため、提供者の従業員に対する守秘は、法律上の義務に頼らず、契約で別に定めておく必要があります。

規約で定めるべきことは、次のとおりです。

1. 「通報者を特定させる情報」の定義。氏名や連絡先だけでなく、通報の内容から本人が推測される記述、添付ファイルの作成者情報、通信の記録（IPアドレス、端末の情報）も含めるかを決める。
2. 提供者の従業員のアクセスの原則禁止と、例外の限定。障害の調査や、契約者の依頼があった場合など、必要最小限の場面に限り、アクセスする場合の手順とログの記録を書く。
3. 従業員と委託先への守秘義務の課し方。退職後も続くこと、クラウド基盤などの委託先にも同等の義務を課すこと。
4. 匿名での通報の扱い。匿名の通報であっても、通信の記録から通報者が推測されることがあるため、記録を残さない設定や、記録の保存期間を書く。

契約者の側の設定も、規約に書く

通報者を特定させる情報が漏れる原因は、提供者の側だけにあるわけではありません。実際には、契約者の管理者の権限設計のほうが大きな問題になることがあります。たとえば、通報の対象者や、その上司が、窓口の管理者を兼ねていて、通報の内容を閲覧できる場合です。窓口の機能が正しく動いていても、事業者側の運用で通報者が特定されることになります。そこで、規約には、契約者の義務として、次のようなことを書いておく方法があります（アカウント・利用条件のページも参照）。

• 閲覧できる者を、従事者として定めた者に限り、通報の対象者となる可能性のある者に権限を与えないこと。
• 通報の対象が、窓口の担当者や管理者自身に及ぶ場合の、閲覧権限の外し方を契約者が整備しておくこと。
• 通報者を探索する行為、通報を理由として通報者に不利益な取扱いをする行為を行わないこと。
• アカウントの共有をしないこと、退職した担当者のアカウントを速やかに停止すること。

通報を理由とする不利益な取扱いは、公益通報者保護法が禁止しています。たとえば、労働者である公益通報者が、同法3条各号に定める公益通報をしたことを理由とする解雇は無効とされ（3条）、事業者は、その使用していた公益通報者に対して、降格、減給、退職金の不支給その他の不利益な取扱いをしてはなりません（5条1項）。契約書に同じ内容を書き写す必要はありませんが、契約者の義務として、窓口の利用が不利益な取扱いに使われないことを書いておくと、提供者が、不適切な利用を理由に利用を停止できる根拠になります。

通報者本人が、事業者に対して、自分に関する個人データの開示を求めることもあります（個人情報保護法33条）。開示を受ける側の事業者は、通報者以外の第三者の権利利益を害するおそれがある場合などは、その全部または一部を開示しないことができます（同条2項1号）。提供者が、本人から直接請求を受けたときの手順（契約者に通知して指示に従う）は、規約に書いておきます。

匿名化・統計化した通報データを、提供者が使う条件

窓口SaaSの規約には、「通報データを匿名化および統計化したうえで、サービスの改善、機能開発、広報などに利用できる」という条項が置かれることがあります。他のSaaSでは、統計利用は一般的な条項ですが、通報データについては、いくつかの理由から、慎重な設計が必要です。

1. 通報データには、通報者の個人情報のほかに、通報の対象とされた者、第三者の個人情報が含まれます。
2. 通報の内容は、事業者の不正に関する情報であり、事業者の機密でもあります。
3. 小規模な組織では、内容を伏せて集計しても、事業者や通報者が推測されることがあります。
4. 通報者は、自分の通報が提供者の目的に使われることを、ふつうは想定していません。

個人情報保護法の整理も、通常のSaaSより重くなります。通報者がフォームに入力した情報を取得するのは、事業者です。事業者は、取得したときに利用目的を通知または公表する必要があり（21条1項）、利用目的の達成に必要な範囲を超えて取り扱うには、本人の同意が要ります（18条1項）。提供者が自分の改善や広報のために通報データを使うのは、事業者の委託の範囲を超えるおそれがあり、その分は、提供者が自ら取得し利用するものとして、通報者に説明される必要が出てきます。通報者に見える画面（通報フォーム）に、利用目的として表示されているかどうかが、実務上の分かれ目になります。

「匿名化」「統計化」の語の整理も必要です。個人情報保護法の匿名加工情報は、特定の個人を識別できず、元の個人情報を復元できないようにしたものを指し（2条6項）、作成するときは、個人情報保護委員会規則の基準に従う必要があります（43条1項）。規約でいう「統計化した情報」は、個人に関する情報ではない集計値（件数、割合）を指しているのか、個人情報を加工したものを指しているのかを区別して書かないと、利用が許される範囲が読めません。

通報の内容の真偽、不正な通報、大量の投稿、受付の障害

窓口SaaSが直面するリスクは、通報者を守ることだけではありません。窓口を巡る典型的な争いは、次のようなものです。

公益通報者保護法は、「不正の利益を得る目的、他人に損害を加える目的その他の不正の目的でなく」行われる通報を公益通報と定義しています（2条1項）。通報の対象となる事実も、同法と別表に掲げる法律に規定する罪の犯罪行為の事実や、過料の理由とされている事実などに限られています（同条3項）。しかし、窓口SaaSの提供者が、受け付けた通報について、公益通報に当たるかどうかを判断する立場にはありません。規約では、提供者は通報の内容に基づく選別や削除を行わないことを前提に、通報の内容の真偽、適法性、公益通報に当たるかどうかの判断を、契約者の責任とします。

もう一つの論点は、通報の内容に違法なものが含まれる場合の扱いです。たとえば、特定の個人を誹謗するだけの内容や、第三者の秘密を大量に含む添付ファイルが投稿されたとき、提供者は何ができるのでしょうか。提供者が内容に基づく削除を行うと、窓口の中立性を損ないます。一方で、何もできないと、提供者自身が違法な情報の保管に関与することになります。規約では、提供者による内容に基づく削除は、法令に基づく要請があった場合など限られた場面のみとし、その場合も契約者に通知する、と書く設計があります。技術的な負荷対策（短時間の大量の投稿の制限など）は、内容に基づかないものとして、提供者が行えるように分けておきます。

受付ができなくなる障害は、窓口の本質に関わる

通常のSaaSでは、障害は業務の遅れを意味しますが、窓口SaaSでは、通報の受付がされない、受付の通知が届かないことが、事業者の体制整備の信頼性に直結します。通報が行われたのに、担当者が知らないまま放置されれば、通報者の不利益につながり得ます。そのため、稼働率の目標だけでなく、次のことを規約に書くことを検討します（SLAを約束しない場合の設計はSLAのページ）。

• 受付通知（メールなど）の不達に備え、管理画面で未確認の通報を一覧できる機能と、契約者が定期的に確認する義務。
• 障害が生じたときの、提供者から契約者への通知の方法と時期。
• 障害により受付ができなかった場合に、通報者へ別の連絡手段（電話など）を案内する責任は契約者にあること。
• 責任の上限（責任制限のページ）を置く場合でも、通報者を特定させる情報の漏えいについては、上限の設計を別に検討すること。

契約終了と無料期間の終了：通報データと窓口が、どうなるか

窓口SaaSの終了は、通常のSaaSの終了より影響が大きくなります。通報の調査が続いている最中に契約が終了したら、事業者は調査の記録を失い、通報者は連絡の手段を失います。次の点を、規約に書いておきます。

1. 削除の期限と、取得の機会。契約終了後の一定の日数は保管し、その間に契約者が通報データを取得できる。期間を過ぎたら、復元できない方法で削除する。
2. 例外の限定。法令に基づく保存、紛争の対応、公的機関からの要請に限る。バックアップの扱いは順次消去とし、その期間を書く。
3. 通報者を特定させる情報の優先的な削除。契約終了後に、通報者を特定させる情報だけを先に削除する運用が考えられる。
4. 進行中の案件の扱い。調査が続いている通報がある場合に、契約終了の前に契約者に通知する。窓口が閉鎖されることを、通報者に案内する方法も決める。

個人情報保護法22条は、個人データを利用する必要がなくなったときは、遅滞なく消去するよう努めなければならない、としています。事業者が通報データの保存期間を決める場合の考え方は、指針や、その解説で確認が必要です。提供者の規約は、事業者が決めた保存期間の範囲で契約が終了するまで保管し、終了後は事業者の指示に従う、という書き方が基本になります。削除と返還の一般論は返還・削除のページ、期間と解約の一般論は期間・解約のページにあります。

無料期間が当然に終了する設計の落とし穴

無料期間のあとに自動で有料へ移さず、合意がなければ契約を終える設計は、顧客に受け入れられやすい形としてPoC・トライアルのページで説明しています。窓口SaaSでこの設計をとるときに加わる論点は、無料期間の終了が、窓口の閉鎖を意味することです。契約が終われば、通報フォームが使えなくなり、通報データの取得の期間が始まります。契約者が気づかないまま無料期間が終わると、窓口が突然閉まり、通報者が通報できなくなります。事業者は、窓口を設けているつもりでいても、実際には窓口がない状態になります。

約款として整えるとき：位置づけ、優先順位、変更の定め

法人向けの窓口SaaSの規約を、「約款」として整えることがあります。定型約款に当たるかどうかは、名前ではなく中身で決まり（民法548条の2第1項）、申込書で個別の条件を合意する取引では、約款と呼んでいても当たらない場合があります。判定の一般論と、変更の要件（同法548条の4）は契約の組み立てのページと料金改定のページで説明しています。窓口SaaSでは、変更の周知を民法548条の4第2項が求める最低限にとどめず、とくに次の点を手当てします。

• 秘匿に関する条項は、関連規定の変更の対象から外す。通報者を特定させる情報の保護、アクセスの制限などの条項を、約款の本文に置き、ガイドラインなどの関連規定の改定で緩められないようにする。
• 変更の通知の期間を長めにする。契約者が内容を点検し、代わりの窓口を準備するのに足りる期間を置く。
• 変更に同意しない場合の解約の機会を置く。契約者は、変更後の規約に同意しないとき、違約金などを負わずに解約できる。
• 申込書の個別条件との優先順位を書く。申込書の個別条件を最優先とし、その優先は当該契約に限る、と置く。

契約前に確かめたいことと、起きがちなこと

個人情報を扱うSaaSの契約の全体は委託先・個人情報のページ、施設向けSaaSの本人の同意の考え方は介護施設・保育園・学校向けSaaSの利用者データのページで扱っています。

よくあるご質問

あわせて読みたいページ

本ページは一般的な情報提供です。個別の取引への当てはめは、サービスの仕組みや契約の経緯によって異なることがあります。事務所の改訂例・ご相談の事例として紹介している内容は、アトラス行政書士法人が作成・レビューしてきた法人向けのSaaS・クラウドサービスの利用規約、サービス提供契約書、申込書、実証実験（PoC）の覚書、販売代理店契約書、レビュー報告書、ヒヤリングシートなどを、個別の事業者が特定できない形に整理したものです。条文は e-Gov法令検索（法令API）で確認しています（最終確認日：2026年10月21日）。参考: e-Gov法令検索 / 個人情報保護委員会 / 経済産業省 / 国税庁