フォーム営業の内部統制設計｜監査ログ要件と証跡7項目

「営業ツールの操作ログと承認記録を提出してください」。内部監査室や情報システム部門からこの一文を受け取った瞬間に、フォーム営業の運用担当者の手は止まります。送信履歴はツールの画面には残っている。送信先リストはスプレッドシートにある。けれども「誰が、いつ、どの基準で、どの企業に、何を送ったのか」を一続きの証跡として説明しようとすると、途端に材料が足りないことに気づきます。

困るのは、参考にできる前例が社内にも社外にもほとんど見当たらないことです。社内には会計システムや基幹システム向けの内部統制文書が整備されていても、営業ツール向けの雛形は存在しません。外部の記事を検索しても出てくるのは、ファイルサーバやアカウント管理を前提としたアクセスログの話ばかりで、「社外の企業に対して能動的に送信する行為」をどう記録すればよいのかには誰も答えていません。結果として、提出物の一次案すら書き出せないまま期限だけが近づいてきます。

しかし、フォーム営業の内部統制は決して特殊な世界の話ではありません。問われていることを一言に圧縮すると「送信の意思決定を、後からもう一度たどれるか」に尽きます。そして、これを満たすために必要な部品は、記録（何が起きたか）・承認（事前に誰が認めたか）・分離（誰が単独で完結できないか）という3つに整理できます。この3つを軸に置くと、残すべきログ項目も、保存期間の決め方も、ツールに確認すべきことも、順番に埋められる作業になります。

本記事では、フォーム営業が内部統制の対象として問われ始める3つのきっかけを整理したうえで、監査ログとして残すべき証跡7項目、保存期間を決める3つの起点、権限管理と承認フローの設計、ツール選定・更新時に確認する8項目、営業代行に委託している場合の統制設計、そして自社規模に合わせた最小構成までを順に解説します。読み終えたときに、A4 一枚の内部統制設計メモを書き始められる状態を目指します。

フォーム営業が内部統制の対象として問われ始める3つのきっかけ

フォーム営業は、導入した当初は「営業手法のひとつ」として扱われ、統制の対象として意識されないまま運用が始まることがほとんどです。それがある日を境に「統制の対象」に格上げされます。格上げのきっかけは大きく3つに分かれ、どのきっかけで問われているかによって、求められる水準も提出物の粒度も変わります。まずは自分がどのパターンに当てはまるかを見極めてください。

上場準備・内部監査からのIT統制ヒアリング

もっとも要求水準が高いのがこのパターンです。上場準備の過程で内部監査室が立ち上がると、業務で使用しているシステムの棚卸しが行われ、営業部門が独自に契約している SaaS も対象に含まれます。ヒアリングでは「アクセス権限は誰が付与・削除しているか」「操作ログは取得しているか」「承認を経ずに実行できる操作はあるか」といった質問が並びます。

ここで問われているのは、フォーム営業の成果ではなく「業務プロセスが特定の個人に依存せず、事後に検証可能な形で運用されているか」です。回答が「担当者が判断して送っています」で止まると、統制上の不備として記録されます。このパターンでは、記録・承認・分離の3要素すべてについて、文書化されたルールと、そのルールが守られている証跡の両方が求められます。

情報システム部門によるツール稟議の差し戻し

2つ目は、ツールの新規導入・契約更新の稟議が情報システム部門で止まるパターンです。差し戻しコメントは「ログの保管仕様とアクセス権限の設計を書いて出し直してください」といった形で届きます。情シスの関心は、そのツールが自社のセキュリティポリシー・ログ管理基準に適合しているかどうかにあります。

このパターンで必要なのは、統制の全体設計というよりも「このツールで何がどこまで記録され、誰がアクセスでき、いつまで保管されるか」を第三者に説明できる資料です。ツール側の仕様を確認して埋める作業が中心になるため、後半で扱うツール確認項目のチェックリストがそのまま使えます。

受信企業からの苦情・削除要請に対する説明責任

3つ目は、送信先の企業から「なぜ弊社に営業メールが届いたのか」「送信元の情報をどこから入手したのか」「今後送らないでほしい」といった連絡が入るパターンです。相手が問い合わせフォームの運用ポリシーで営業目的の送信を断っていた場合や、過去に停止を依頼済みだった場合は、話が一段厳しくなります。

このとき求められるのは、当該企業1社についての具体的な事実です。いつ、誰が、どのリストから、どういう基準で送信対象に含めたのか。停止要請を受けた後、いつ、どのリストから除外したのか。これらを即答できないと、対応そのものが不誠実だと受け取られます。上場準備をしていない企業でも、このきっかけだけは規模を問わず発生します。フォーム営業を運用しているのであれば、最低限このパターンに耐えられる記録は用意しておくべきです。

フォーム営業の内部統制が問うのは「送信の意思決定を再現できるか」

きっかけを把握したら、次は「そもそも何を証明すればよいのか」を定義します。ここを取り違えたまま提出物を作ると、ほぼ確実に差し戻されます。フォーム営業の統制設計でもっとも重要な出発点は、一般的な IT 統制のログ管理とは問いの向きが違う、という一点を理解することです。

一般的なIT統制のログ管理とフォーム営業の証跡の違い

内部統制の文脈で語られるログ管理は、伝統的に「守り」の発想で組み立てられています。誰が機密データにアクセスしたか、誰が権限外の操作を試みたか、不正なアクセスの痕跡はないか。つまり、外部または内部の不正な行為を事後に検知するための記録です。IPO 準備企業向けの解説でも、対象として想定されているのはサーバやアカウント管理といった領域です（内部統制におけるログ管理の重要性とは｜IPOサポートメディア）。

フォーム営業のログ管理は、この構図がちょうど裏返しになります。統制の対象は、外部から侵入してくる行為ではなく、自社から社外に向けて能動的に出ていく行為です。送信そのものは正規の業務であり、不正でも例外でもありません。それにもかかわらず統制が必要になるのは、送信が自社の名前で行われる対外的な行為であり、相手企業に対する説明責任を伴うからです。

この違いは、記録すべき項目に直接効いてきます。守りのログ管理では「誰が何にアクセスしたか」が主役ですが、フォーム営業では「誰が何を送ったか」に加えて「なぜその相手を選んだか」という判断の記録が必要になります。判断の記録は、アクセスログをいくら集めても出てきません。

記録・承認・分離という3つの統制要素

IT 全般統制の解説では、アクセス管理・変更管理・開発導入管理・運用管理という4つの領域に分けて整理されるのが一般的です。職務分掌（職務分離）はこの4領域と並ぶ別枠ではなく、アクセス管理の中で「職務に応じた最小限の権限のみを付与する」原則として位置づけられています（IT全般統制(J-SOX)対応で押さえる要点）。これをフォーム営業に翻訳すると、実務上は次の3要素に集約できます。

3つのうちどれか1つが欠けると統制としては成立しません。記録だけがあって承認がなければ「担当者が勝手に送った履歴」にしかならず、承認だけがあって記録がなければ「承認したことになっている状態」を検証できません。分離がなければ、記録も承認も同じ人物が自由に作り替えられます。提出物を作るときは、この3つを縦軸に置いて情報を埋めていくと構造が崩れません。

送信履歴のエクスポートだけでは統制と呼べない理由

もっとも多い失敗が、ツールの送信履歴を CSV でエクスポートして「これが監査ログです」と提出してしまうケースです。送信履歴は確かに記録の一部ですが、統制の証跡としては次の3点が足りていません。

1つ目は、判断の記録がないことです。送信履歴には「送った」という結果しか残らず、「なぜその企業を対象に選んだのか」「送信可否をどう判定したのか」は残りません。苦情対応や監査で最初に問われるのはこの部分です。

2つ目は、事前承認の記録がないことです。使用した文面が誰の承認を経たものか、そのリストは誰が承認したのかが送信履歴からは追えません。承認プロセスが存在していても、証跡として結びついていなければ「運用されていた」とは判定されません。

3つ目は、改ざん耐性がないことです。エクスポートした CSV は編集可能なファイルにすぎず、それ自体は原本性を持ちません。ツール側でログが削除・編集できる設計になっている場合、その操作自体が記録されるかどうかも確認対象になります。

送信履歴のエクスポートは「材料のひとつ」であって「提出物そのもの」ではない。この認識に立ったうえで、次の章の証跡項目を埋めていきます。

フォーム営業の監査ログに残すべき証跡7項目

ここからが本記事の中核です。フォーム営業の送信プロセスを時系列に分解し、各段階で残すべき証跡を7項目に整理します。それぞれについて「誰の質問に答えるための記録か」「最低限どの粒度が必要か」「どこから取得するか」を押さえてください。この7項目がそのまま、提出物のログ項目定義になります。

送信の実行に関する記録（送信主体・日時・送信先）

最初の2項目は、送信という行為そのものを特定するための記録です。フォーム営業の送信履歴管理として、多くのツールが標準で保持している領域でもあります。

項目1: 送信主体（実行者アカウント・実行日時）

どのユーザーアカウントが、いつ送信を実行したかの記録です。ここで注意したいのは、スケジュール送信や自動送信を使っている場合、実行者が「システム」として記録されてしまい、人の責任が追えなくなることです。自動実行であっても「その送信ジョブを設定・承認したのは誰か」を紐づけて残す必要があります。監査で問われるのは操作した人ではなく、責任を負う人だからです。

項目2: 送信先の特定情報（企業名・ドメイン・フォームURL）

送信先を一意に特定できる情報です。企業名だけでは同名企業や子会社との区別がつかないため、ドメインを主キーに据えるのが実務的です。加えて、送信に使用したフォームの URL を残しておくと、苦情対応の際に「どの窓口に送ったのか」を即答できます。同一企業が採用問い合わせ・一般問い合わせ・IR など複数のフォームを持つケースは珍しくなく、どのフォームに送ったかで相手の受け止め方も変わります。

送信の判断に関する記録（リスト取得根拠・送信可否判定の根拠）

続く2項目は、外部の記事ではほとんど扱われていない領域です。しかし監査・苦情対応の双方で最初に問われるのはここであり、実質的にもっとも重要な証跡になります。

項目3: 送信先リストの取得元と取得根拠

そのリストをどこから、いつ、どのような条件で取得したかの記録です。自社の企業マスタから業種・所在地で絞り込んだのか、外部の企業データベースから購入したのか、展示会で交換した名刺を起点にしたのか。取得元によって、その後に守るべき制約が変わります。

とくに外部から購入・提供を受けたリストに担当者名やメールアドレスといった個人データが含まれる場合、個人情報保護法上の第三者提供に該当し、提供元の氏名や取得の経緯を確認して記録する義務が生じます（個人情報の保護に関する法律についてのガイドライン（第三者提供時の確認・記録義務編）｜個人情報保護委員会）。法人の代表電話や問い合わせフォーム URL のみで構成されたリストであれば個人データに当たらない場合もありますが、どちらに該当するかを自社で判断した記録自体を残しておくことが、後の説明を容易にします。法的な線引きそのものについてはフォーム営業の法的リスクで扱っているため、判断の前提を確認したい場合はあわせて参照してください。

項目4: 送信可否判定の結果と判定根拠

送信対象に含めるかどうかを、どの基準で判定したかの記録です。除外リストとの突合結果、問い合わせフォームに営業目的の送信を断る旨の記載があったかどうか、過去に停止要請を受けていないか。これらの判定結果を、判定した時点のスナップショットとして残します。

「判定基準が文書化されている」だけでは不十分で、「その基準を各件に適用した結果」が個別に残っている必要があります。基準は途中で変わりますし、除外リストも日々更新されます。半年後に「なぜこの企業に送ったのか」と問われたとき、当時の基準と当時の判定結果が残っていなければ答えられません。判定そのものの設計論点についてはフォーム営業の送信可否判定ロジックで詳しく扱っています。本記事は判断そのものではなく、その判断を後から再現できる形で記録する側を扱います。

送信の内容と結果に関する記録（文面バージョン・送信結果・エラー）

項目5: 使用した文面のバージョンと承認者

送信に使用した文面の内容と、そのバージョン、承認した人物の記録です。文面はテンプレートとして管理されることが多く、運用の中で細かく改訂されていきます。ところが送信履歴には「テンプレートA を使用」としか残らない設計になっていると、当時どの文面が送られたのかを再現できません。

対策はシンプルで、テンプレートにバージョン番号を振り、送信ログにはバージョン番号まで記録することです。加えて、各バージョンが誰の承認を経たものかをテンプレート台帳側に残します。苦情対応で「どういう文面を送ったのか見せてほしい」と言われたとき、当時の文面をそのまま提示できる状態が理想です。

項目6: 送信結果とエラー内容

送信が成功したのか、失敗したのか、失敗したならその理由は何かの記録です。統制の観点では「失敗したのに成功として集計されている」状態がもっとも危険で、実態と報告の乖離につながります。送信失敗の理由（フォーム構造の変化、必須項目の不足、送信ブロックなど）まで残しておくと、リスト品質の改善にも使えます。

停止・削除要請への対応記録

項目7: 停止・削除要請の受付と反映結果

受信企業から「今後送らないでほしい」「登録情報を削除してほしい」という連絡を受けた場合の、受付日時・要請内容・対応者・反映日時・反映先リストの記録です。7項目のなかで、実務上もっとも取りこぼされやすいのがここです。

要請はメールで届いたり、電話で伝えられたり、送信先フォームからの返信として届いたりと、入口が分散します。入口が分散すると、受け付けたこと自体がどこにも記録されず、数か月後に同じ企業へ再送してしまう事故が起こります。再送は単なるミスでは済まず、「一度断ったのに無視された」という強い不信につながります。

設計上のポイントは2つです。ひとつは、要請の受付窓口を1本化し、受付台帳を作ること。もうひとつは、台帳への登録と除外リストへの反映を別々の記録として残し、両者の時間差を可視化することです。「受け付けたが反映していなかった」という空白期間の有無が、そのまま統制の実効性を示します。

証跡7項目の一覧表と取得元の棚卸し

7項目を一覧にすると次のようになります。提出物にはこの表をベースに、自社の取得元を埋めた形で記載してください。

この表を埋める作業で、多くの企業は「3・5・7 がどこにも存在しない」ことに気づきます。1・2・4・6 はツール側で取得できる可能性が高い一方、3・5・7 は業務側で台帳を作らないと生まれない記録だからです。逆に言えば、この3つの台帳を用意するだけで統制の骨格は大きく前進します。

監査ログの保存期間を決める3つの起点

証跡の項目が決まったら、次は「いつまで保管するか」です。ここで多くの担当者が止まります。検索すると「1年」「5年」「7年」といった数字が並びますが、どれを採用してよいのか判断する根拠が示されていないためです。

結論から言うと、監査ログの保存期間に業種横断の単一の正解はありません。決め方は、法令起点・苦情対応起点・自社ポリシー起点という3つの軸から候補となる期間を出し、そのうち最長のものを採用する、という手順になります。稟議書には、この3軸を並べたうえで採用理由を書けば十分な説明になります。

法令起点｜個人情報保護法の記録義務から逆算する

まず、法令が明示的に保存期間を定めている部分がないかを確認します。フォーム営業に関係しうる代表例が、個人データの第三者提供に関する確認・記録義務です。個人情報保護委員会のガイドラインでは、この記録の保存期間について原則3年とし、本人に対する物品等の提供に関連して本人の同意のもとで提供した場合は1年とする、といった区分が示されています（個人情報の保護に関する法律についてのガイドライン（第三者提供時の確認・記録義務編）｜個人情報保護委員会）。

ここで重要なのは、この義務が「フォーム営業の送信ログ全般」にかかるものではないという点です。対象は個人データの授受に関する記録であり、外部から購入したリストに個人データが含まれる場合の取得記録などが該当します。自社が送信した履歴そのものが直接この義務の対象になるとは限りません。

したがって、法令起点で導かれるのは「リストの取得根拠に関する記録（証跡項目3）は3年を下限とする」という形の、部分的な下限値です。それでも、根拠を明示できる数字がひとつあるだけで、社内の合意形成は格段に楽になります。

苦情・削除要請対応起点｜「説明できる期間」から逆算する

2つ目の軸は、実務上もっとも現実的な起点です。受信企業から苦情や削除要請が来たとき、どこまで遡って説明できる必要があるかから逆算します。

判断材料になるのは、自社の送信サイクルです。同一企業への再アプローチを年1回のペースで行っているなら、前回の送信記録が最低でも1年以上残っていないと「なぜ再送したのか」を説明できません。半年に1回のサイクルなら、より短い期間でも足りる計算になります。あわせて、苦情が送信の何か月後に届く傾向があるかを、過去の受付台帳から確認します。

この軸で導かれる期間は、多くの場合1年から2年のレンジに収まります。加えて、停止要請の受付記録（証跡項目7）だけは性質が異なる点に注意してください。停止要請は「永続的に守るべき約束」であり、期間を区切って削除してしまうと、削除後に同じ企業へ再送する事故が起きます。停止要請の記録は、原則として保存期間を設けずに保持し続ける設計にすべきです。

自社ポリシー起点｜J-SOX 対応・監査サイクルから逆算する

3つ目は、自社が属する枠組みから逆算する軸です。参考になるのは、既存の外部基準が「どういう用途を想定して期間を定めているか」という考え方の部分です。

たとえばカード情報を扱う事業者に適用される PCI DSS では、要件 10.5.1 が「監査ログの履歴を少なくとも12ヶ月間保持し、少なくとも直近の3ヶ月間は分析のために直ちに利用できるようにすること」を求めています（AWS環境でPCI DSS v4.0へ対応するためのコツ｜NRIセキュア）。注目すべきは数字そのものよりも、「調査のために保持しておく期間」と「即座に取り出せる状態にしておく期間」を分けている点です。この二層構造は、フォーム営業のログ設計にもそのまま応用できます。ツール側で直近数か月分だけが画面から参照でき、それ以前はエクスポートしたアーカイブに退避している、という設計は珍しくないからです。

上場企業・上場準備企業の場合は、開示制度側の年限も参考になります。金融商品取引法第25条第1項第六号では、内部統制報告書およびその添付書類・訂正報告書について「5年」の公衆縦覧期間が定められています（金融商品取引法 第25条｜法令集）。社内のログ管理基準がこの年限に揃えて設計されている企業も少なくないため、自社基準を確認する際の手がかりになります。

もっとも、これらはいずれも「フォーム営業の送信ログを何年保管せよ」と定めたものではありません。実務的な決め方は、外部基準の数字を借りてくることではなく、その記録で何を説明したいのかという用途から逆算することです（監査ログの保管期間はどう決める？実務設計ガイド）。フォーム営業であれば、苦情対応と内部監査という2つの用途が起点になります。

なお、上場企業・上場準備企業であれば、既存の社内ログ管理基準に「業務システムのログは○年保管」という規定がすでにあるはずです。その場合、フォーム営業ツールだけ独自の期間を設定する理由はありません。既存基準に合わせるのがもっとも説明コストの低い選択です。

そして、2024年4月1日以後に開始する事業年度から適用されている内部統制報告制度の改訂では、外部委託に係る統制の重要性やサイバーリスクへの対応が追記されています（内部統制報告制度の改訂概要｜EY Japan）。営業ツールを外部の SaaS で運用し、送信業務の一部を外部に委託している構成は、まさにこの論点に該当します。上場準備中であれば、保存期間の議論は情シスだけでなく監査法人側の見解も確認しておくと手戻りを防げます。

ログ種別ごとに保存期間を分ける設計例

3軸で候補期間を出したら、すべてのログを最長期間で揃える必要はありません。ログ種別ごとに期間を分けたほうが、保管コストと説明可能性のバランスが取れます。設計例を示します。

この表はあくまで例であり、業種・上場ステータス・既存の社内基準によって適切な値は変わります。重要なのは数字そのものではなく、「なぜその期間にしたのか」を1行で説明できる状態にしておくことです。稟議で問われるのは値ではなく根拠だからです。

権限管理と職務分掌｜「誰が送信できるか」の統制設計

記録と保存期間が決まったら、残る2要素は承認と分離です。ここは記録と違って「仕組みを作る」作業になります。フォーム営業の権限管理でつまずくのは、多くの現場が「担当者1名が全工程を持っている」状態から出発するためです。

フォーム営業の職務分掌｜4つの役割と分離すべき組み合わせ

フォーム営業の職務分掌は、次の4つの役割に分解すると整理しやすくなります。

このうち、分離が特に重要なのは「文面承認者」と「送信実行者」の組み合わせです。この2つが同一人物だと、承認プロセスが形式的に存在するだけになり、実質的には無承認送信と変わりません。次に重要なのが「送信実行者」と「ログ確認者」の分離で、実行者自身が自分の実行記録を確認・修正できる状態は、記録の信頼性を根本から損ないます。

一方で、「リスト作成者」と「送信実行者」の兼務は、規模によっては許容されます。この2つを分離するとリードタイムが伸びやすく、少人数チームでは運用が回らなくなるためです。分離すべき組み合わせと、兼務してよい組み合わせを明示的に書き分けておくと、監査での説明がスムーズになります。

なお、体制図やロール定義そのものの作り方は本記事の範囲を超えるため、フォーム営業の運用体制設計で扱っている RACI 権限マトリクスを土台にすると、本記事の職務分掌表と接続しやすくなります。本記事はあくまで「その体制が機能していることを証跡で示す」側に絞ります。

ツールの権限ロール設計とアカウント棚卸し

職務分掌を紙の上で定義しても、ツールの権限設定がそれを反映していなければ意味がありません。ここでよく起きるのが、全員が管理者権限を持っているケースです。導入初期に「とりあえず全員 admin」で始めたまま、誰も見直していない状態は珍しくありません。

確認すべきポイントは3つです。1つ目は、ツールの権限ロールが職務分掌の4役に対応する粒度を持っているか。「管理者」と「一般ユーザー」の2段階しかないツールでは、ログ参照専用のロールを作れず、分離が実現できません。

2つ目は、管理者権限の保有者数です。管理者はログの削除や権限の付与ができるため、統制上もっとも重要な権限になります。保有者を最小限に絞り、誰が保有しているかを一覧で説明できる状態にしてください。

3つ目は、アカウントの棚卸しです。異動・退職した担当者のアカウントが有効なまま残っていると、その一点だけで統制不備と判定されます。棚卸しの頻度（四半期ごと・半期ごと）と実施記録を残す運用をルール化し、実施した証跡そのものを提出物に含めます。棚卸しは「やっている」と口頭で説明しても認められず、実施日と確認者が記録された一覧が求められます。

承認フローの3つの粒度（文面単位・リスト単位・キャンペーン単位）

フォーム営業の承認フローを設計するとき、何を承認の単位にするかで運用負荷が大きく変わります。実務で選択肢になるのは次の3粒度です。

多くの中規模チームでは、キャンペーン単位を基本にしつつ、文面の新規作成時のみ文面単位の承認を追加する二段構えが現実的です。重要なのは、粒度を選んだ理由を説明できることと、選んだ粒度に対して例外運用（緊急時の事後承認など）のルールを明記しておくことです。例外ルールがないと、緊急対応のたびに無承認送信が発生し、統制が形骸化します。

承認の記録をどこに残すか

承認フローを設計しても、記録が残らなければ証跡になりません。承認記録の置き場所は、大きく3つのパターンがあります。

ひとつ目は、社内のワークフローシステム（稟議システム・申請システム）を使う方法です。承認者・承認日時・承認内容が自動で記録され、改ざんも難しいため、証跡としての品質はもっとも高くなります。上場準備中の企業では、既存のワークフローに営業施策の申請フォームを追加するのが最短ルートです。

ふたつ目は、フォーム営業ツール側に承認機能がある場合にそれを使う方法です。送信ログと承認記録が同一システム内で紐づくため、参照が容易になります。ただし、ツールによって承認機能の有無・粒度は大きく異なるため、後述の確認項目で仕様を押さえておく必要があります。

みっつ目は、チャットツールやメールでの承認を台帳に転記する方法です。導入コストは最小ですが、転記が手作業になるため漏れが起きやすく、事後の改変も可能です。当面の運用としては許容されますが、監査対応の場面では「なぜワークフローを使わないのか」を問われる前提で臨んでください。

いずれの方法を選ぶ場合も、承認記録と送信ログを後から突き合わせられるキー（キャンペーンID・テンプレートバージョン番号など）を必ず持たせてください。この紐づけがないと、承認と実行が別々に存在するだけで「承認された内容が実行された」ことを証明できません。

フォーム営業ツールを内部統制の観点で確認する8項目

ここまでの設計を実現できるかは、使用するツールの仕様に大きく依存します。ツールの新規導入・契約更新の稟議では、以下の8項目を質問文の形で提供事業者に確認し、回答をそのまま資料に添付するのが効率的です。各項目に「回答が曖昧なときに何が起こるか」を添えているので、確認の優先順位づけにも使ってください。

ログの取得・保全に関する確認項目

確認1: ログのエクスポート形式と粒度を教えてください

CSV / API のどちらで取得できるか、1件単位まで出力されるか、集計値のみか。回答が曖昧なまま導入すると、監査で「件単位のログを出してほしい」と言われた際に画面のスクリーンショットしか提出できず、証跡として認められません。

確認2: ログの改ざん・削除は可能ですか。可能な場合、その操作は記録されますか

管理者がログを削除できるかどうか、削除した場合に「誰がいつ削除したか」が残るかどうかを確認します。ログが自由に消せて、消したことも残らない設計では、そのログは証跡としての価値を持ちません。

確認3: ログの保存期間はどのくらいですか。設定を変更できますか

サービス側で保持される期間と、その期間を延長・短縮できるかを確認します。自社が決めた保存期間よりツール側の保持期間が短い場合、定期的にエクスポートして自社側で保管する運用を設計する必要があり、その手順自体が提出物の一部になります。

確認4: 契約終了時のデータはどう扱われますか

解約後にログが即時削除されるのか、一定期間ダウンロード可能なのかを確認します。ツールを乗り換えた瞬間に過去の証跡がすべて消えると、乗り換え前の期間について説明できなくなります。

権限・データ分離に関する確認項目

確認5: 権限ロールの粒度を教えてください

管理者・一般ユーザーの2段階か、送信実行・ログ参照・リスト編集などを個別に制御できるか。粒度が粗いツールでは職務分掌をシステム側で担保できず、運用ルールでの補完が必要になります。その場合、補完策も含めて情シスに説明する必要があります。

確認6: 組織・クライアント単位のデータ分離はどう実現されていますか

複数事業部で使う場合や、営業代行として複数クライアントの案件を扱う場合、送信先リスト・送信履歴・文面が組織単位で分離されているかを確認します。分離されていないと、他部門・他クライアントのデータに意図せずアクセスできる状態になり、それ自体がアクセス管理上の不備になります。

判断根拠と停止対応の記録に関する確認項目

確認7: 送信可否の判定根拠は記録として残りますか

除外リストとの突合結果や、送信をスキップした理由が件単位で記録されるかどうかです。ここが残らないツールでは、証跡項目4を自社の台帳で手作業で補う必要があり、運用負荷が跳ね上がります。稟議段階で必ず確認すべき項目です。

確認8: 停止要請の登録と、その反映が追跡できますか

停止要請を受けた企業をシステムに登録でき、その登録が以降の送信に反映されたことを確認できるか。登録機能はあるが反映の証跡が残らない、というケースもあるため、「登録できるか」ではなく「反映を確認できるか」まで踏み込んで聞いてください。

なお、秋霜堂株式会社が提供する Form Pilot は、送信履歴と失敗診断を画面上で確認できる設計、短縮 URL による開封・クリックの可視化、そしてマルチテナントによる組織単位のデータ分離を備えています。送信対象の絞り込みについては、他社（取引先・別チャネル）が接触済みの企業ドメイン一覧を外部 API から取得して送信リストと突合し、該当する企業への送信を自動で回避する仕組みを持ち、「判断できないなら送らない」という安全側に倒す設計（fail-closed）を基本としています。比較検討の際は、こうした機能の有無を上記8項目の軸に当てはめて各ツールを並べると、稟議資料としての体裁が整います。

ツールの実行方式によって証跡の残り方が変わる点

見落とされがちですが、ツールの送信方式によって残る証跡の性質は変わります。

完全自動送信型のツールは、送信の全工程がシステム内で完結するため、送信ログの網羅性はもっとも高くなります。一方で、実行者が「システム」として記録されるため、人の責任の紐づけを別途設計する必要があります。

入力までを自動化し、送信ボタンは人が押す方式（セミオート送信）では、最終的な送信操作を行った人が明確に特定できます。Form Pilot は、CAPTCHA を突破する処理は行わず、CAPTCHA 等で完全な自動送信ができないフォームについては Chrome 拡張機能が入力までを自動化し、送信ボタンは人が押す方式を採っています。CAPTCHA は受信側が「機械的な送信を受けたくない」と示す意思表示であり、それを迂回する行為は送信元である利用企業の名前で行われる、という判断に基づく設計です。統制の観点では、送信の意思決定に人が介在する記録が残る点が特徴になります。

人手による代行の場合、送信操作は委託先の環境で行われるため、自社側にはシステムログが一切残りません。この構造的な問題については次の章で扱います。

営業代行に委託している場合の統制設計

フォーム営業の一部または全部を営業代行に委託している場合、統制設計はもう一段複雑になります。外部の解説記事でもほとんど扱われていない領域ですが、多くの企業が現実に直面する論点です。

委託すると証跡が自社に残らない構造

委託の何が問題かというと、送信という行為が委託先の環境・委託先のアカウントで実行されるため、自社のシステムには一切の記録が生まれないことです。自社に届くのは、月次の報告書に記載された送信件数と反応件数の集計値だけ、というケースが典型です。

この状態で内部監査から「送信先の選定基準を示してください」と言われても、答えられるのは「委託先が選定しています」までです。苦情が入ったときも同様で、当該企業を送信対象に含めた判断根拠は委託先しか持っていません。にもかかわらず、受信企業から見れば送信元は自社であり、説明責任は自社が負います。統制の観点では、これは「業務プロセスの一部が評価範囲の外に出ている」状態にあたります。

前述のとおり、2024年4月1日以後に開始する事業年度から適用されている内部統制報告制度の改訂では、外部委託に係る統制の重要性が明示的に追記されています（内部統制報告制度の改訂概要｜EY Japan）。上場準備中の企業であれば、委託部分をブラックボックスのまま残す選択は取りづらくなっています。

委託契約と報告フォーマットで担保する3つの記録

委託先の内部プロセスを自社が直接管理することはできません。営業代行の委託先管理で現実的に取れる手段は、契約と報告フォーマットによって必要な記録を自社に還流させる設計です。最低限、次の3つは確保してください。

記録A: 送信先の明細（件単位）

集計値ではなく、いつ・どの企業（ドメイン単位）に送信したかの明細です。これがないと、苦情が入ったときに「そもそも当社が送ったのか」すら確認できません。報告フォーマットに明細を含めることを契約時に合意し、月次または週次で受領します。

記録B: 送信先の選定基準と除外条件

どのような条件で対象企業を抽出し、どのような条件で除外したかの記載です。選定基準は施策ごとに変わりうるため、施策単位で書面化してもらいます。あわせて、自社が指定した除外リストが確実に適用されたことの確認方法も定めます。

記録C: 使用した文面

送信に使用された文面そのものです。文面の承認プロセスを自社側に置き、承認済みの文面以外を使用しないことを契約で明記します。委託先が独自に文面を調整している場合、自社が把握していない表現で自社の名前が使われることになります。

これら3つを受領する際は、フォーマットを自社側で指定するのが実務上のコツです。委託先ごとにフォーマットが異なると、集約と保管の作業が破綻します。加えて、受領した記録は自社側でも保管し、委託契約が終了した後も参照できる状態にしておいてください。委託先のシステムにしか記録がない状態は、契約終了と同時に証跡を失うことを意味します。

内製・委託の切り分けと統制コストの比較

委託を続けるか、ツールを使って内製に切り替えるかの判断には、統制コストの観点を含めるべきです。純粋な運用コストだけで比較すると、委託が有利に見えるケースは少なくありません。しかし統制の観点を加えると、比較軸は次のように変わります。

委託が悪いという話ではありません。要求される統制水準がまだ低い段階であれば、委託のほうが総合的に合理的なこともあります。判断すべきは「今後1〜2年で求められる統制水準に対して、委託の枠組みで必要な記録を還流させられるか」です。上場準備が視野に入っているなら、早い段階で内製への切り替えか、契約の見直しかを検討しておくと、後の手戻りが小さくなります。

自社の規模に合わせた最小構成の内部統制

ここまで読んで「自社にはここまで必要なのか」と感じた方も多いはずです。実際、すべてを一度に整備する必要はありません。非上場・中規模の企業が過剰投資を避けるために、統制レベルを段階に分けて考えます。

統制レベルの4フェーズ

フェーズ1は、どの規模の企業であっても実施すべき最小構成です。とくに「文面の事前承認」は、コストがほぼゼロでありながら、自社の名前で意図しない表現が送られる事故を防ぐ効果が大きい施策です。

フェーズ2の4点を揃えると、苦情対応で問われる内容にはほぼ答えられるようになります。上場準備をしていない企業であれば、当面はここで十分なケースが大半です。

きっかけ別・到達すべきフェーズの対応表

冒頭で整理した3つのきっかけと、フェーズの対応関係は次のようになります。

自分がどのきっかけで検索したかを確認し、その行に書かれた項目から着手してください。すべてを同時に進めようとすると、どれも中途半端なまま期限を迎えます。

先にやると失敗しやすい順序

最後に、順序を誤りやすい点を2つ挙げます。

ひとつは、統制設計より先にツール導入を決めてしまうことです。ツールを決めた後に「判定根拠のログが残らない」と分かると、自社側の台帳で手作業で補うしかなくなり、運用が破綻します。ツール選定と統制設計は並行して進め、確認8項目への回答を選定の判断材料に含めてください。

もうひとつは、記録の整備より先に承認フローだけを作ってしまうことです。承認フローは作りやすく、着手した実感も得やすいのですが、承認記録と送信ログを突き合わせるキーが設計されていないと、承認と実行が別々に存在するだけで統制としては成立しません。証跡7項目の定義を先に固め、そこに承認記録を接続する順序で進めると手戻りが減ります。

まとめ｜内部統制設計メモを1枚にまとめる4ステップ

フォーム営業の内部統制は、専門的な知識を新たに身につけなければ着手できない領域ではありません。「送信の意思決定を、後からもう一度たどれるか」という一点に立ち返れば、必要な作業は順序立てて進められます。最後に、A4 一枚の内部統制設計メモを書き出すための4ステップを示します。

ステップ1: 送信プロセスを時系列で書き出す

リスト作成 → 送信可否の判定 → 文面の選定 → 送信の実行 → 結果の確認 → 停止要請への対応、という流れを自社の実態に合わせて書き出します。この時点では理想形ではなく、現在の運用をそのまま書いてください。

ステップ2: 各段階の証跡項目と取得元を埋める

本記事の証跡7項目の一覧表をベースに、自社の取得元（ツール／台帳／人手）を埋めます。空欄になった項目が、そのまま今後の整備対象です。多くの場合、リスト取得台帳・テンプレート台帳・停止要請受付台帳の3つが不足しています。

ステップ3: 保存期間を3起点で決める

法令起点・苦情対応起点・自社ポリシー起点の3軸で候補期間を出し、ログ種別ごとに保存期間を決定します。数字の横に「なぜその期間か」を1行ずつ添えてください。稟議で問われるのは値ではなく根拠です。

ステップ4: 権限分離と承認粒度を確定する

リスト作成者・文面承認者・送信実行者・ログ確認者の4役を自社の担当者に割り当て、分離すべき組み合わせが兼務になっていないかを確認します。あわせて承認粒度（文面単位／リスト単位／キャンペーン単位）を選び、承認記録の置き場所と、送信ログと突き合わせるキーを決めます。

この4ステップを埋めたメモに、ツール確認8項目への回答を添付すれば、情報システム部門と内部監査室に提出できる一次案が完成します。完璧な統制をいきなり作る必要はありません。現状を正しく書き出し、空欄を可視化し、優先順位をつけて埋めていく。その過程そのものが、統制が機能していることの証跡になります。

関連情報

送信履歴と失敗診断の可視化、組織単位のデータ分離、接触済み企業の自動除外といった統制観点の設計を確認したい方は、Form Pilot のサービスページをご覧ください。送信量の最大化ではなく「送ってよい相手にだけ送る」ことを設計の中心に据えた、AI フォーム営業自動化 SaaS です。

本記事と関連する内容は以下の記事でも扱っています。

• フォーム営業の送信可否判定ロジック — 送信可否をどの基準で判定するか、判定レイヤーの設計と評価指標
• フォーム営業の法的リスク — 個人情報保護法・特定電子メール法・利用規約の観点からの論点整理
• フォーム営業の運用体制設計 — 4ロールの定義と RACI 権限マトリクス、引き継ぎ設計