フォーム営業の自動送信は違法か｜条文で線を引いて、自分で決める6つの上限

自動化そのものを禁じる条文は無い

フォーム営業の件数を増やそうとすると、必ず自動送信の話になります。1社ずつ手で入力するのは時間がかかるからです。

そこで「フォーム営業 自動化 違法」と調べると、危険を強調する記事と、問題ないとする記事が両方出てくる。どちらを信じればよいか分かりません。

条文から整理すると、こうなります。問い合わせフォームへの自動送信そのものを禁じる法律はありません。ただし、やり方によって別の条文に触れます。

関係する4つの層

1つ目についてはフォーム営業は違法なのかで条文まで整理しています。この記事では、自動化したときに新しく出てくる2つ目から4つ目を扱います。

不正アクセス禁止法には当たらない

自動送信の話でよく持ち出されるのが、不正アクセス禁止法です。ここは条文を読むと、当たらないことがはっきりします。

禁止されているのは何か

（不正アクセス行為の禁止）
第三条
何人も、不正アクセス行為をしてはならない。

不正アクセス行為の禁止等に関する法律 第3条。

では「不正アクセス行為」とは何か。第2条第4項に定義があります。3つの号すべてに共通するのは、アクセス制御機能による制限を免れる行為だという点です。

一 アクセス制御機能を有する特定電子計算機に
  電気通信回線を通じて当該アクセス制御機能に係る
  他人の識別符号を入力して当該特定電子計算機を
  作動させ、当該アクセス制御機能により
  制限されている特定利用をし得る状態にさせる行為

同法 第2条第4項第1号。読みやすさのため改行を入れています。

1号は他人のIDとパスワードを使う行為。2号と3号は、識別符号以外の情報や指令でアクセス制限を破る行為を指しています。

公開フォームには制限が無い

誰でも開けて、誰でも送信できる問い合わせフォームには、アクセス制御機能がありません。制限が無いので、制限を免れる行為も成立しません。

自動で送っているか、手で送っているかは、この判断に影響しません。条文が見ているのは制限を破ったかどうかであって、送信の手段ではないためです。

効いてくるのは業務妨害の条文

自動送信で現実的に問題になるのは、刑法の業務妨害です。関係する条文は2つあります。

（信用毀損及び業務妨害）
第二百三十三条
虚偽の風説を流布し、又は偽計を用いて、
人の信用を毀損し、
又はその業務を妨害した者は、
三年以下の拘禁刑又は五十万円以下の罰金に処する。

刑法 第233条。読みやすさのため改行を入れています。

（電子計算機損壊等業務妨害）
第二百三十四条の二
人の業務に使用する電子計算機若しくは
その用に供する電磁的記録を損壊し、
若しくは人の業務に使用する電子計算機に
虚偽の情報若しくは不正な指令を与え、
又はその他の方法により、
電子計算機に使用目的に沿うべき動作をさせず、
又は使用目的に反する動作をさせて、
人の業務を妨害した者は、
五年以下の拘禁刑又は百万円以下の罰金に処する。

刑法 第234条の2第1項。読みやすさのため改行を入れています。

条文から読み取れること

第233条の「偽計」は、人を欺いたり錯誤に陥れたりする手段を指します。身元を偽って送る、存在しない取引を装う、といった行為がここに近づきます。

第234条の2は、コンピュータに「使用目的に沿うべき動作をさせず」「使用目的に反する動作をさせて」妨害する場合です。フォームが本来の問い合わせを受け付けられなくなるほど送る、という形が想定されます。

どちらにも件数の基準は無い

重要なのはここです。条文に「何件まで」という基準は書かれていません。量だけでなく、手段、期間、相手の状況を含めて判断されます。

だから、安全な件数を法律に探しても見つかりません。自分で上限を決めるしかありません。その決め方を後半で書きます。

利用規約とrobots.txt

実務で最初に引っかかるのは、法律ではなく利用規約です。

自動化を禁止する条項の書かれ方

4つ目は自動化と無関係ですが、自動送信では規約を読まずに送ることになりがちなので、ここで初めて踏むことが多くなります。

自動化すると、規約を読まなくなる

これが自動送信の最大のリスクです。手で入力していれば、フォームの近くに書かれた注意書きが目に入ります。自動化すると、その機会が消えます。

だから規約の確認を、自動送信の前工程として組み込んでください。リストを作る段階で、営業お断りの記載と自動化禁止の記載を列で持ちます。

robots.txtの扱い

robots.txtは検索エンジンのクローラ向けの記述で、法的な拘束力を持つものではありません。フォーム送信を直接禁じるものでもありません。

ただしサイト側の意思表示として読むことはできます。すべてのクローラを拒否している状態で自動送信をかけるのは、後から説明しづらくなります。

自分で決める6つの上限

条文に基準が無い以上、こちらで決めます。決めておくと、問われたときに説明できます。

最後の項目が最も抜ける

エラー時に止まる条件が書かれていない実装をよく見ます。相手のサーバーが重くなってエラーを返しているときに、リトライを繰り返すのが最も迷惑な動き方です。

そしてこの動きは、第234条の2が想定する状況に近づいていきます。止まる条件は、件数の上限より先に書いてください。

上限の決め方に、根拠を持たせる

数字は自分で決めますが、なぜその数字にしたのかを1行で書けるようにしてください。問われたときに答えられるかどうかが、決めた意味を左右します。

たとえば送信間隔なら「人が手で入力した場合の最短時間を下回らないようにした」。1日の上限なら「担当者が1人で返信対応できる件数を超えない」。

根拠が「なんとなく」だと、増やしたくなったときに歯止めが効きません。根拠があると、増やすときにその根拠ごと見直すことになります。これが上限を機能させる仕組みです。

上限は、組織の誰が決めるか

現場の担当者に決めさせないでください。件数の目標を持っている人が上限も決めると、目標に合わせて上限が動きます。

決めるのは、件数の責任を持たない立場の人です。小さい組織なら経営者が決めて、文章で残す。上限を動かすときも同じ人が判断する形にしておきます。

上限を決めたら、記録と照合できるようにする

決めただけでは意味がありません。決めたとおりに動いたことを、後から示せる状態にします。

送信のログに、日時、送信先、間隔、エラーの有無を残します。これがあれば、問われたときに「こう決めて、こう動いていた」と説明できます。

逆にログが無いと、やっていないことの証明ができません。記録は相手のためではなく、自分のために残します。

認証を突破しようとしない

ここは明確に線を引いておきます。

画像認証や計算問題を自動で解かない

フォームに画像認証や簡単な計算問題が置かれている場合、それは自動送信を拒否するという意思表示そのものです。

技術的に突破できるかどうかは問題ではありません。突破する行為は、サイト側が設けた制限を回避する行為そのものです。

認証があるフォームは、手で送るか、送らない

自動送信の対象から外してください。どうしても送りたい相手なら、手で入力します。

認証の有無を、リストの列で持ってください。送信の直前に気づく設計だと、処理が止まります。リストを作る段階で確認しておきます。

送信ボタンの前にある確認画面

入力内容の確認画面を挟むフォームがあります。自動送信では、この画面を通過する処理が必要になります。

ここは技術的な話に見えますが、判断が要る場面です。確認画面は、送信者に内容を確かめさせるために置かれています。それを自動で通過するということは、確認の機会を飛ばしているということです。

そのぶん、送信前のテスト送信を丁寧にしてください。自社宛に1通送って、差し込みのズレや文字化けが無いことを確認してから本番に入ります。

確認画面を通過する処理を書いた時点で、人による確認が1回も入らない状態になります。その分を、事前のテストで埋めます。

入力項目を偽らない

自動送信では、必須項目を埋めるために架空の情報を入れたくなる場面があります。電話番号の欄、担当者名の欄、部署の欄。

偽らないでください。第233条の「偽計」に近づきますし、そもそも折り返しが来ても受けられません。

入れられない項目があるフォームは、自動送信の対象から外します。無理に埋めるより、外すほうが安全です。

ツールを選ぶときの確認項目

自動送信のツールを使うなら、選ぶ段階で確認する項目があります。

共有IPのリスク

5つ目は見落とされがちです。複数の利用者で送信元を共有しているツールだと、他の利用者の送り方が原因で、自社も遮断されることがあります。

遮断されると、そのサイトへは手作業でも届かなくなる。契約前に確認してください。

作るか、買うか

自分で送信の仕組みを作る選択もあります。判断の基準を挙げておきます。

自分で作ると、上限を自分の設計どおりにできます。エラー時に止まる条件も、記録の項目も、思ったとおりに書けます。反面、フォームの構造はサイトごとに違うので、対応の手間が続きます。

ツールを買うと、対応の手間は減ります。ただし上限の設定が、ツールの用意した範囲に縛られます。送信間隔を細かく決められないツールもあります。

判断の分かれ目は、送信先の数より、送信先の種類です。同じような構造のフォームが多いなら自作で足ります。業種も規模もばらばらなら、ツールのほうが速く回ります。

ツールの規約も確認する

ツール側の利用規約に、送信先の選び方や件数の制限が書かれていることがあります。ツールを使うこと自体が、別の契約を結ぶことです。

自社の運用ルールが、ツールの規約と矛盾していないかを確認してください。

記録と、止める条件

最後に、運用で決めることを2つ書きます。

記録する項目

5つ目が重要です。送ってよいと判断した根拠を残しておかないと、後から説明できません。

ログの保存期間

送信ログには、送信先の情報が含まれます。担当者名を入れている場合は、個人情報を含むことになります。

そのため、保存期間を決めてください。無期限に持つと、必要が無くなった個人データを保有し続けることになります。

期間の目安は、再送の判断に使う期間から逆算してください。1社への再送を最長で1年後までと決めているなら、ログもそこまで持てば足ります。

ただし「断られた」という記録だけは、期間を切らずに残してください。これは再送を防ぐために必要な情報で、消すと同じ相手に送ってしまいます。ログ全体と、除外リストを分けて持つのが実務的です。

止める条件を先に決める

次のどれかが起きたら、その日の送信を止めます。

• 連続で規定回数以上のエラーが出た。相手側か自社側に問題がある
• 送信先から抗議の連絡が来た。まず全体を止めて、原因を確認する
• 特定のサイトから遮断された。他のサイトでも同じことが起きている可能性がある

止める条件を決めていないと、担当者がその場で判断することになります。判断できないので、たいてい続行されます。

止めた後にやること

原因を特定するまで再開しないこと。そして止めた理由と再開の判断を、記録に残してください。

同じことが2回起きたら、それは運用の問題です。上限の設定か、リストの作り方を見直してください。

まとめ

• 問い合わせフォームへの自動送信そのものを禁じる条文は無い。問題になるのは、どれだけの量を、どういう手段で送るか
• 不正アクセス禁止法には当たらない。同法が禁じているのはアクセス制御による制限を免れる行為で、公開フォームには制限が無い
• 現実的に効いてくるのは刑法第233条の偽計業務妨害と、第234条の2の電子計算機損壊等業務妨害
• どちらにも件数の基準は書かれていない。安全な件数を法律に探しても見つからないので、自分で決める
• 実務で最初に引っかかるのは利用規約。自動化すると規約を読まなくなるのが最大のリスクなので、確認を前工程に組み込む
• 決める上限は6つ。1社への回数、再送の間隔、送信間隔、同時実行数、1日の上限、そしてエラー時に止まる条件
• 画像認証や計算問題を自動で解かない。それは自動送信を拒否するという意思表示そのもの
• 入力項目を偽らない。埋められない項目があるフォームは、対象から外す
• ツールは送信間隔の設定、エラー時の停止、送信ログ、送信元IPを確認して選ぶ
• 止める条件を先に決める。決めていないと、担当者が判断できず、たいてい続行される

自動化の可否を調べている時間より、上限を決めて記録を残す設計に時間を使うほうが、結果的に安全です。条文に基準が無いなら、自分の基準が唯一の説明材料になります。

よくある質問