実在の政党名で議席を予測する機能を作って、選挙のじゃまにならないようにした話

公職選挙法は、選挙に関する人気投票の結果の公表を禁じている。
実在の政党名を使う機能を作るなら、この条文と正面から向き合う必要があった。

架空の政党で選挙戦を戦うモードとは別に、実在の政党名と世論調査の数字を使って「いま総選挙をしたら」議席がどう動くかを予測する機能を作った。
作り終えたところで、あらためて自分に聞いた。これは法律的に大丈夫なのか、と。

問題になるのは「人気投票」の公表

公職選挙法138条の3は、選挙に関し公職に就くべき者を予想する人気投票の経過又は結果の公表を禁じている。違反すると刑事罰もある。
この機能は、訪問者に投票させて集計する人気投票ではなく、公表済みの世論調査の数字をシミュレーションで議席に変換しているだけなので、報道機関がよくやる情勢調査に基づく議席予測に近いと考えている。ただしこの区別は判例で確定しているわけではなく、実務上の解釈にとどまる。自動シミュレーションという形態そのものについて、司法判断が出た例もまだ見当たらなかった。

条文自体には「選挙運動期間中に限る」とは書いていない。
だが実際の総選挙が公示されてから投票日までのあいだは、この機能が「公職に就くべき者を予想する」ものだといちばんまっすぐ読まれかねない期間になる。リスクを減らすには、この期間だけ機能そのものを止めるのが確実だと考えた。

フラグを立てるだけでは足りない

実装したのは、衆議院・参議院それぞれに独立したON/OFFフラグを持たせ、公示中はボタンを押せなくする仕組みだ。
ただ、このゲームは単一の静的HTMLファイルとして配布していて、実行中に外部のサーバーへ問い合わせることができない。フラグを書き換えても、ビルドして配置し直さない限り、公開中のページには反映されない。

そこでボタンを塞ぐだけでなく、予測を計算する関数自体にもフラグを見せて、フラグが立っていたら計算そのものを例外で止めるようにした。ボタンを消し忘れても、別の経路から呼ばれても、計算自体が動かない。二重の保険をかけた形になる。

この判断が正しいという確証はない。エンジニアリングでできるのはリスクを減らすことまでで、法的な確実性を保証することはできない。
それでも、何も考えずに機能だけ作って終わりにするより、条文を読んでから手を動かすほうが、自分にとっては筋が通っていた。

スタンプラリーに挑戦する 行った場所・気になる場所は、現地チェックインでスタンプに残せます。 みんなのコースを見てみる 会員が作ったスポット巡りのコースを都道府県から探せます。自分だけのコースも作れます。 運営者の個人noteも書いています AI活用やサイト運営で気づいたことを、もう少し個人の視点で掘り下げています。

※運営者が個人で書いているnoteです。

技術ブログ一覧へ戻る