競馬の自動投票アプリは違法か？─予想サービス事業者のための「刑事罰ライン」と適法設計フレーム

競馬の予想サービスや関連ツールを提供している事業者の方から、最近このようなご相談が増えています。

「自社の予想に従って、顧客のIPATから自動で馬券を購入するアプリを作りたい。これは規約に抵触するのか？」

一見すると「利用規約に触れるかどうか」の問題に見えます。しかし、この論点で本当に最初に確認すべきは、規約よりももっと手前にある刑事罰のラインです。ここを誤ると、規約違反どころか犯罪になりかねません。

そして事業者にとって本当に怖いのは、「グレーだから」と判断を保留したまま開発を進め、リリース直前やリリース後になって「この設計では出せない」と分かることです。作り直しのコスト、失った開発期間、最悪の場合は事業そのものの停止——判断を後回しにするほど、後戻りの代償は大きくなります。

この記事は、「自社のサービスは今どの位置にいて、どこを直せば事業として成立するのか」を、経営判断として自分で切り分けられるようになることをゴールにしています。法律論の解説にとどめず、投資判断・開発着手の可否をその場で下せる実務フレームとして整理しました。

まず結論：事業者が握るべき3つの判断軸

先に結論からお伝えします。細かい条文の前に、経営判断としてはこの3点だけ押さえてください。

1. 刑事罰のラインは「お金を預かるかどうか」。 顧客の資金を預かって代わりに馬券を買う形にした瞬間、規約違反ではなく犯罪（競馬法違反）になり得ます。ここは交渉や工夫の余地がない、絶対的な一線です。
2. 規約は、設計次第で「違反しない」と主張できる。 問題になる条項も、作り方を整えれば「利用者本人の投票」と構成する余地があります。つまり、設計は「違法/適法」の二択ではなく、事業者がコントロールできる変数です。
3. ただし「争える」＝「安全」ではない。 解釈で勝てても、JRAの裁量でアカウントを止められる余地は残ります。事業としての安定性には、構造的な不確実性がついて回ります。事業計画は、この不確実性を前提に組む必要があります。

言い換えれば、このビジネスの成否は「法律が許すか」ではなく、「事業者が設計と契約と広告をどう組み立てるか」で決まります。以下、その判断材料を順に提供します。

【60秒セルフ診断】あなたのサービスは今どのゾーンにいるか

具体論に入る前に、まず自社（構想中を含む）の立ち位置を把握してください。以下に一つでも「はい」があれば、そのままでは事業化できない可能性が高いサインです。

■ レッドゾーン判定（刑事罰リスク／一つでも該当したら要再設計） ☐ 顧客の資金を、いったん自社の口座やウォレットで預かる想定がある ☐ 「的中したら報酬」「配当の◯％」など、成功報酬型の課金を考えている ☐ 顧客のID・パスワード（暗証番号・P-ARS番号等）を自社で保管・代行入力する ☐ 「代わりに買っておきますよ」という代行サービスとして訴求しようとしている

■ イエローゾーン判定（規約リスク／該当したら設計の作り込みが必要） ☐ 自社サーバーから投票データをJRAへ送信する構成になっている ☐ 「予想が出たら自動で買う」という、事業者主導で投票が走る作りになっている ☐ レース情報・オッズをIPAT（投票サービス）経由で取得している ☐ エラーログやクラウド同期で、意図せずID情報が外部に出る可能性を検証していない

■ グリーン寄り（この形なら「本人の投票」と構成しやすい） ☑ 顧客自身の口座・資金で、顧客の端末内で完結して投票が走る ☑ 課金は月額定額のサブスクリプション ☑ 投票条件は顧客が事前に自分で設定する ☑ IDは端末内のみ・送信先はJRAサーバーに限定

レッドゾーンに一つでも該当する場合、それは「規約を読み込めば解決する」問題ではありません。ビジネスモデルそのものの再設計が必要です。この診断で自社の課題ゾーンが分かったら、次章以降でその理由と直し方を確認してください。

その前に：多くの事業者がつまずく2つの誤解

正しい判断の前提として、出発点でよく間違える2点を先に潰しておきます。ここを取り違えると、この後の議論がすべてずれます。

誤解①「見ている規約が違う」

ネットで規約を探すと、多くの場合「JRA-VAN利用規約」が見つかります。しかしこれは、レース情報を提供するデータサービスの規約であり、運営もJRAシステムサービス社です。馬券購入そのもののルールではありません。

自動投票の可否を決めるのは、利用者ひとりひとりがJRAと結んでいる「即PAT約定」（正式名称：日本中央競馬会インターネット投票に関する約定）です。しかも会員区分（即PAT／A-PAT）ごとに別文書になっています。まず、見るべき文書を間違えないことが出発点です。ここを外したまま社内で「大丈夫そうだ」と判断すると、根拠のない安心の上に事業を組むことになります。

誤解②「公式APIを使っているから大丈夫」

「JRAが投票用の公式APIを出している」と思われている方がいますが、そのようなものは存在しません。JRA-VAN側も、投票に関する機能は提供しておらず、サポートも行っていないと明言しています。市場に出回っている自動投票の仕組みは、ブラウザの自動操作か、第三者が独自に作った製品を使っているのが実態です。したがって「公式APIだから安心」という前提は、そもそも成り立ちません。

元IT企業経営者としての視点 私自身、弁護士になる前はIT企業を経営していました。開発現場では「技術的に動く」ことと「事業として出せる」ことがしばしば混同されます。自動投票は、まさにその典型です。ブラウザ操作で技術的には実装できてしまうがゆえに、法務チェックを通さずにMVPが出来上がり、投資や広告を打った後で問題に気づく——という順番になりがちです。技術検証と並行して、いや、できれば技術検証の前にこの記事の判断軸を通しておくことを、経営者の立場から強くおすすめします。

最重要：ここを越えたら「犯罪」です

自動投票を検討するうえで、何より先に知っておくべきなのが競馬法第31条第1号です。

業として勝馬投票券の購入の委託を受け、又は財産上の利益を図る目的をもつて不特定多数の者から勝馬投票券の購入の委託を受けた者

これに該当すると、3年以下の拘禁刑または300万円以下の罰金が科されます。いわゆる「馬券の購入代行」を処罰する規定です。

つまり、顧客からお金を預かって、代わりに馬券を買ってあげるというビジネスモデルは、規約違反という次元ではなく、刑事罰の対象になり得るということです。これは絶対に避けなければなりません。事業者にとってこれは「リスクが高い」という程度の話ではなく、選択肢から外すべき一線です。

判断の軸は、突き詰めると「お金の流れ」だけ

何がアウトで何がセーフか。経営判断としてシンプルに落とし込むと、見るべきは「お金の流れ」ひとつです。

避けるべき形（アウト・刑事罰リスク）	問題になりにくい形（セーフ寄り）
顧客の資金を預かって、代わりに馬券を買う	顧客自身の口座で、顧客自身の資金で買う
的中したら報酬をもらう（成功報酬型）	課金は月額定額制のサブスクリプション
配当の何％かを受け取る	予想の提供そのもの（これ自体は適法です）
顧客のID・パスワードを事業者が預かる	IDは顧客の端末内だけに置き、事業者は触れない

ここで強調しておきたいのは、競馬の予想を有料で提供すること自体は、まったく問題ないということです。法的に危うくなるのは、「お金を預かった瞬間」からです。「予想の販売」と「資金の預かり」の間に、太い線が引かれている——この一点を社内の共通認識にしてください。

【課金モデル別】リスク早見表

事業者にとって、どう課金するかは収益設計の根幹であり、同時にリスクの分かれ目でもあります。主な課金モデルを、刑事罰リスク・規約リスクの両面で整理しました。設計会議でそのまま使える早見表です。

課金モデル	刑事罰リスク（競馬法）	規約リスク（即PAT約定）	事業判断
月額定額（サブスク）	低（投票と収益が切り離される）	低〜中（第27条(7)を回避しやすい）	◎ 第一候補
予想の都度課金	低	低	◯ 予想販売として適法
成功報酬（的中時のみ課金）	高（委託・利益図りと見られやすい）	高（投票サービスからの収益と評価されやすい）	✕ 避けるべき
配当の◯％を受領	高（購入委託の典型）	高	✕ 避けるべき
資金預かり＋代行購入	極めて高（第31条第1号に直接該当し得る）	―	✕✕ 論外

ポイントは、「儲かりそうに見えるモデルほど、刑事罰と規約の両方のリスクが跳ね上がる」という構造です。成功報酬型は、顧客にとって魅力的で成約率も上がりそうに見えますが、法的には最も危険な領域に入ります。逆に、地味に見える月額定額制が、事業の安定性という観点では最も優れています。ここは短期の成約率ではなく、事業の継続可能性で選ぶべき論点です。

規約の話：問題になる3つの条項と、その分解

刑事罰のラインをクリアしたうえで、次に検討するのが即PAT約定です。自動投票で問題になりそうなのは、第27条にある次の3つです。

• 第27条(1) 加入者本人以外の者にインターネット投票の申込みをさせる行為
• 第27条(2) 他人からの委託によりインターネット投票の申込みをする行為
• 第27条(7) インターネット投票のサービスの全部又は一部を商業目的で利用する行為

「自動で投票する仕組みは、この3つに引っかかるのでは？」という不安が、多くの事業者の出発点かと思います。ここを一つずつ分解していきます。結論から言うと、3つのうち本当に向き合うべきは1つだけです。

大前提：このルールは「誰」に向けられているか

分解の前に、重要な確認があります。第27条は「加入者は、次に掲げる事項をしてはなりません」という書き出しになっています。つまり、これらはJRAと契約している利用者本人に向けたルールであって、アプリを提供する事業者に向けたルールではありません。事業者はそもそもこの約定の当事者ですらないのです。

この一点を押さえると、(2)と(7)はかなりの部分が整理できます。

第27条(2)・(7)は「当てはまらない」と考えられる

(2)「他人からの委託により投票する行為」は、「利用者が、他の人から頼まれて、自分の口座で他人の分を買う」という代理購入を禁じる規定です。各ユーザーが自分のために自分の口座で買っているのであれば、誰からも委託を受けていません。したがって当てはまらないと考えられます。

(7)「投票サービスを商業目的で利用する行為」は、自分のアカウントを使って他人に馬券を売る、サービス自体を転売するといった行為を想定した規定と考えられます。ユーザーが自分のお金で自分のために買う行為は、通常これに当たりません。

ただし注意点があります。課金を成功報酬型にすると、(7)の評価は一気に悪化します。投票サービスそのものから収益を得ていると見られやすくなるためです。月額定額制であれば、この懸念はほぼ解消できます（そして前述のとおり、成功報酬型は刑事罰リスクの面でも危険です）。ここでも、課金モデルの選択が規約評価を左右することがわかります。

第27条(1)が唯一の「主戦場」

残るのが(1)「本人以外の者に投票を申し込ませる行為」です。「ソフトが自動で投票するのだから、本人以外がやっているのでは？」という懸念は、まさにここに関わります。ここが、このビジネスの適法性を分ける本丸です。

しかし、考えるべきは「ソフトが人かどうか」ではありません。「投票を決めているのは誰か」です。

包丁で料理をしても、料理をしたのは包丁ではありません。同じように、ユーザーがあらかじめ自分で条件を設定し、その設定どおりにソフトが動いているのであれば、投票を決めているのはユーザー本人であり、ソフトはその「道具」にすぎない──このように構成することが可能です。

この考え方は、金融の世界ではすでに一般的です。FXの自動売買ツールは、利用者が自分のパソコンにツールを入れ、自分で条件を設定して動かす限り、本人の取引として扱われています。一方、業者側が裁量で顧客の口座を動かす場合は、登録が必要なまったく別の業務になります。この区別の考え方が、自動投票にもそのまま当てはまります。

「事業者が投票している」のではなく、「ユーザーが、自分で設定した条件に従い、自分の道具を使って投票している」。この構造にできれば、(1)には当たらないと主張できます。そして、この「構造」を作れるかどうかは、事業者の設計次第です。ここが、法律家に丸投げする話ではなく、経営と開発が主体的に握るべき論点である理由です。

【意思決定フロー】着手してよいか、その場で判定する

ここまでの論点を、開発着手の可否を判断するフローにまとめました。上から順に確認し、いずれかで「NG側」に該当したら、その時点でストップ、または再設計です。

#	確認する問い	NG側 → 対応	OK側（次へ進める）
Q1	顧客の資金を自社で預かるか？	預かる → ✕ 刑事罰リスク（競馬法31条）。中止・モデル変更が必須	預からない（顧客の口座・資金のみ）
Q2	課金は成功報酬型か？	成功報酬 → ✕ 刑事罰＋規約リスク。月額定額へ変更	月額定額 or 予想都度課金
Q3	IDを自社が受け取る／保管するか？	受け取る → ✕ 例外なき禁止。端末内保存の設計へ	端末内のみ・自社は非保持
Q4	投票の送信は顧客の端末内で完結するか？	自社サーバー送信 → △「事業者が投票」と評価の恐れ。設計変更を推奨	端末内で完結
Q5	投票条件は顧客自身が事前設定する作りか？	事業者主導で自動発注 → △「本人の投票」構成が弱まる。UIを見直し	顧客が事前設定
Q6	レース情報を正規のデータサービスから取得するか？	IPAT経由で取得 → △ 情報利用制限に抵触の恐れ。取得元を変更	正規ライセンスのデータサービス

すべて通過 → 「本人の投票」と構成できる設計 ただしJRA裁量条項による不確実性は残る（後述）。事業化に向けて、専門家と最終設計・規約整備・JRA打診を検討する段階です。

このフローで一度でも「NG側」に該当した項目が、あなたのサービスの具体的な直しどころです。逆に、すべて通過してGREENに到達したとしても、それは「法的にゼロリスク」を意味しません。最後のQ6の先にあるJRAの裁量条項という不確実性が残るためです。この点は後ほど詳しく説明します。

サービスの構造は、少しの実装差で結論が変わります。「自社のフローがどこで詰まっているか分からない」「GREENまで来たが最終確認をしたい」という段階に来たら、設計段階でのスポット相談が最も費用対効果の高いタイミングです。作ってしまった後の作り直しより、はるかに安く済みます。

【設計要件チェックリスト】「本人の投票」と言い切るための4条件

GREEN側に進むには、「本人の投票」という主張を支える設計要件を満たす必要があります。ここが崩れると、主張そのものが成り立ちません。開発仕様書に落とし込めるレベルで整理しました。

#	要件	なぜ必要か	実装のポイント／落とし穴
1	ソフトはユーザーの端末内で動かす	事業者のサーバーが投票を送信すると「投票しているのは事業者」と評価される	サーバー側で発注ロジックを持たない。クラウド実行型（VPS常駐等）は特に注意
2	ID・パスワード等を事業者が一切預からない	即PAT約定は第三者への漏示を例外なく禁止（後述）	端末内保存・送信先はJRAサーバーのみ。エラーログ／クラウド同期での意図せぬ漏洩を検証
3	投票条件はユーザー自身が設定する	「決めているのは本人」という構成の土台	「予想が出たら自動で買う」ではなく「どの予想をいくらで買うかを事前設定」。この事前設定UIを機能として実装
4	レース情報はIPATから取得しない	投票サービス経由で得た情報の利用は別途制限	レース・オッズは正規ライセンスのデータサービスから取得

この4条件は、「あったほうがよい」ではなく「一つでも欠けたら主張が崩れる」必須要件です。開発着手前に、この4行を仕様書の冒頭に固定要件として書き込んでおくことをおすすめします。後から差し込むと、アーキテクチャの作り直しになることが多いためです。

IDについては、例外がありません

特に注意が必要なのがID（加入者番号・暗証番号・P-ARS番号・INET-ID）の扱いです。即PAT約定は、これらを「絶対に第三者に漏らしてはなりません」と定めており、JRAの承諾による例外も認められていません。

つまり、「IDを預かって、JRAに承諾をもらう」というルートは存在しません。逆に言えば、IDをユーザーの端末内だけに置き、事業者が受け取らない設計にすれば、そもそも「漏らす」という行為が発生しないわけです。ここが唯一の安全な道になります。

実装上、意図せず「漏らして」しまう落とし穴もあります。事業者側に悪意がなくても、標準的な開発プラクティスがそのまま地雷になり得る点に、特に注意してください。

• エラーログ・クラッシュレポートの自動送信にIDが含まれてしまう
• 設定情報のクラウド同期・バックアップで外部に送られてしまう
• サポート窓口で「設定を代行します」とIDを預かってしまう

3つ目は、事業者が見落としがちなポイントです。カスタマーサポートの運用設計まで含めて「IDを触らない」を徹底しないと、良い設計をしても現場のオペレーションで穴が開きます。開発仕様だけでなく、サポートマニュアル・問い合わせ対応フローも同じ基準で設計してください。

それでも残るリスク：JRAの裁量条項という「構造的不確実性」

ここまで整えても、消せないリスクがあります。即PAT約定には、JRAの判断で利用を止められる規定が置かれているためです。たとえば「その他競馬会が不適切と認めた行為」を禁止する条項や、「必要と認めたとき」に利用停止・解約ができるとする条項です。

これらはJRAの裁量が非常に広い規定です。条文の解釈でいくら「違反していない」と主張できても、JRAが「好ましくない」と判断すれば、ユーザーのアカウントは停止され得ます。その場合、事業者側のサービスも同時に機能しなくなります。約定はJRAが一方的に変更できることとされており、実際に随時改正されています。

事業者にとって、これは事業計画の前提に組み込むべき重要なリスクです。法的に争えることと、事業として安定することは別問題であり、この構造的な不確実性は、設計を工夫しても残ります。具体的には、次のような形で事業判断に効いてきます。

• 単一依存リスク：売上がJRAの一存で止まり得る構造なので、この事業単体に過度に依存する計画は危うい。予想サービス本体など、投票連携が止まっても残る収益の柱を併せ持つ設計が望ましい。
• 資金調達・出口への影響：投資家やM&Aの相手方は、必ずこの不確実性をデューデリで指摘します。あらかじめリスクを開示し、緩和策を説明できる状態にしておくことが、評価を下げないための備えになります。
• 緩和策としてのJRAへの打診：事業化を本格的に進める前に、JRA側に連携について打診し、話を通しておくことが考えられます。事後に問題化するより、事前に姿勢を確認しておくほうが、事業リスクは小さくなります。

この不確実性を「だから諦める」と捉えるか、「前提として織り込んで設計する」と捉えるかで、事業の作り方は大きく変わります。ここは、法律論というより経営判断そのものです。

広告・表示にも注意：ここでの失敗は「参入前から」起きる

最後に、予想サービス全般に共通する注意点です。「必ず当たる」「絶対に儲かる」といった表現は、景品表示法や特定商取引法上の誇大広告として、行政指導や処分の対象になり得ます。

事業者にとって見落としやすいのは、この規制は自動投票の設計とは無関係に、予想サービスの広告・LPの段階から適用されるという点です。つまり、投票機能を実装する前、集客のためのランディングページやSNS広告の一言で、先に問題が起きることがあります。予想が外れる可能性があること、投票はあくまで利用者自身の判断と責任で行うものであることを、きちんと明記してください。

広告表現のチェックは、法務コストとしては比較的軽く、かつ効果が大きい領域です。LPや広告クリエイティブを出す前に、表現を一度点検しておくことをおすすめします。

まとめ：事業者が今すぐやるべきこと

競馬の予想・自動投票をめぐる法規制は、「規約に触れるか」という表面的な問題ではなく、刑事罰・契約・広告規制が複雑に絡み合う領域です。サービスの具体的な設計は、少しの違いで結論が変わります。最後に、事業判断としての要点を整理します。

• 刑事のライン……お金を預からない。成功報酬にしない。ここを越えたら犯罪です。交渉の余地はありません。
• 規約への対応……「事業者が投票する」のではなく「ユーザーが道具で投票する」構造にする。決め手は課金モデルと4つの設計要件です。
• 残るリスク……JRAの裁量条項。消せない前提として事業計画に織り込み、可能なら事前に話を通しておく。
• 今日できること……冒頭のセルフ診断で自社のゾーンを確認し、意思決定フローで「詰まっている箇所」を特定する。そこがそのまま、直すべき設計課題です。

このビジネスの成否は、法律が許すかどうかではなく、事業者が設計・契約・広告をどう組み立てるかで決まります。裏を返せば、正しく設計すれば「争える」土俵に自ら立てるということです。そしてその設計は、作り込んだ後より、着手前のほうが圧倒的に安く・確実に整えられます。