VoteWise AIで見るNext.jsとGemini 2.5 Flashの選挙ガイドAI

DEV Communityに、VoteWise AIという選挙ガイドAIの実装記事が出ていた。
原題は「How I Built VoteWise AI: Gamifying Democracy with Next.js & Gemini 2.5 Flash」。公開時刻は2026年5月2日 10:36:48 UTC。

内容は、選挙制度の説明を政府PDFや長いFAQから、モバイル向けのAIチャットとストーリーモードに移す話だ。
VoteWise AIは13か国、16言語、音声入出力、選挙カレンダー、子どもにも分かる比喩生成を備える。実装はNext.js 15 App Router、React、Tailwind CSS、Framer Motion、Zustand、Firebase Anonymous Auth、Firestore、Gemini API、Cloud Run。

この手の civic tech は「便利なAIチャットを付けた」だけだと薄い。
面白いのは、選挙制度という政治的に繊細で、かつユーザーの不安が強い領域に、低遅延モデル・音声・ゲーム的な説明をまとめて入れているところにある。

静的な説明ページから会話型の案内へ寄せる

VoteWise AIが狙っている課題は、候補者推薦ではなく「制度が分からないから参加しにくい」という入口の摩擦だ。
投票方法、登録、選挙制度、用語、国ごとの差分を、ユーザーが質問できる形にする。

ここで変わるのは、情報量ではなく到達経路だ。
従来の選挙情報サイトは、ユーザーが正しいページ名や制度名を知っている前提になりがちだった。チャットUIにすると、「Electoral Collegeって何」「自分は次に何を確認すればいい」という雑な質問から入れる。

ただし、VoteWise AIは投票そのものを扱う投票システムではない。
以前書いた投票システムの本質は「投票権」の設計にあるでは、誰に何回投票させるか、認証やシリアルコードをどう扱うかを整理した。今回のVoteWise AIはその前段で、投票権の発行や集計ではなく、制度理解と参加前の不安を下げるレイヤーにいる。

もしこのアプリに模擬投票や学内投票のような機能を足すなら、そこから先は別問題になる。
AIチャットの品質より、認証、二重投票防止、ログ、異常検知、レートリミットの設計が主役になる。

Gemini 2.5 Flashを選挙文脈で使うときのねじれ

Gemini 2.5 Flashは、公式モデル一覧では価格性能と低遅延・高スループット寄りのモデルとして位置づけられている。
入力はテキスト、画像、動画、音声に対応し、出力はテキスト。入力上限は1,048,576トークン、出力上限は65,536トークンで、構造化出力、関数呼び出し、検索グラウンディング、URL context、thinkingを使える。

VoteWise AIのような用途では、この「速くて十分賢い」性格は合う。
選挙用語の説明、ストーリー化、多言語応答、カレンダーに紐づく案内は、巨大な推論モデルで毎回じっくり考えさせるより、安定して短時間で返すほうが体験に直結する。

一方で、選挙はGemini APIの安全フィルタ上でも特別扱いされる。
公式ドキュメントの安全性設定には HARM_CATEGORY_CIVIC_INTEGRITY があり、説明は election-related queries、つまり選挙関連クエリだ。調整可能なカテゴリには嫌がらせ、ヘイト、性的、危険、市民の完全性が並ぶ。

このカテゴリがあること自体は妥当だが、アプリ設計には効いてくる。
ユーザーが「誰に投票すべきか」と聞くのか、「比例代表とは何か」と聞くのか、「この国で登録には何が必要か」と聞くのかで、許容すべき応答が変わるからだ。

graph TD
    A[ユーザーの質問] --> B[国と言語を判定]
    B --> C[制度説明か推薦要求か分類]
    C --> D[制度説明なら根拠付きで回答]
    C --> E[候補者推薦なら中立な案内へ戻す]
    D --> F[音声と画面で提示]
    E --> F

以前のLLMの安全フィルタの記事でも触れたが、クラウドLLMのブロックはモデル本体だけで決まらない。入力フィルタ、システムプロンプト、学習済みの拒否傾向、出力フィルタが重なる。
選挙ガイドAIでは、どの質問を拒否し、どの質問を説明に変換するかをアプリ側で先に設計しておくほうがいい。

Story Modeは制度用語の翻訳レイヤー

原典でいちばんアプリらしい機能はStory Modeだと思う。
Electoral CollegeやParliamentary Democracyのような概念を、子どもにも分かる比喩とAIイラストで説明する。

見た目はゲーミフィケーションだが、やっていることは制度用語を生活感のある言葉へ落とす翻訳だ。
たとえば「選挙人団」をそのまま説明しても、制度を知らない人には最初の単語で止まる。ピザのトッピングやクラス代表の比喩にすると、正確さは少し削れるが、最初の理解には届きやすい。

問題は、比喩が強すぎると制度の違いを潰してしまうことだ。
国ごとの選挙制度は、比例代表、小選挙区、二回投票制、選挙人団、議院内閣制、大統領制で前提が違う。Story Modeを本気で運用するなら、比喩の後に「現実の制度ではここが違う」という短い補正を必ず入れたい。

層	役割	失敗しやすい点
チャット	質問の入口を広げる	推薦や誘導に寄りすぎる
ストーリー	難しい制度を比喩にする	比喩が制度差を消す
音声	読む負担を下げる	長文回答だと聞き疲れる
カレンダー	次の行動へつなぐ	期限や地域差の誤りが致命的
Firestore	状態や履歴を持つ	ルールが甘いと個人情報リスクになる

API RouteとCloud Runまわりは堅実

原典で具体的だったのは、Gemini APIキーをクライアントに出さず、Next.js API Routeの /api/chat を中継にした点だ。
さらに、入力のサニタイズ、プロンプトインジェクション対策、IPベースで1分20リクエストのインメモリ制限を入れている。

この構成自体は妥当。
ただ、Cloud Runで複数インスタンスにスケールするなら、インメモリのレートリミットはインスタンスごとに分かれる。ハッカソンや小規模デモなら十分でも、本番で悪用コストを下げたくないなら、Redis、Firestore、Cloud Armorなど外部に寄せる判断になる。

Cloud Run向けには、Next.jsの output: 'standalone' を使ったと書かれている。
Google CloudのNext.js on Cloud Runクイックスタートでも、Cloud RunへNext.jsをデプロイする道筋は用意されている。Secret ManagerはCloud Buildからも使えるので、Firebaseの公開設定とGemini APIキーのような秘匿値を分ける設計は自然だ。

graph TD
    A[Next.js UI] --> B[API Route]
    B --> C[入力分類とレート制限]
    C --> D[Gemini API]
    B --> E[Firestore]
    B --> F[Secret Manager]
    A --> G[Web Speech API / TTS]

音声まわりは、過去にAIと喋れる環境を作る音声API調査で見た領域と重なる。
VoteWise AIはリアルタイム音声会話モデルを直接使うというより、画面上のチャット体験に音声認識と読み上げを足す方向に見える。低コストで多言語対応を広げるなら、そっちのほうが実装しやすい。

まだ検証されていないところ

原典は3分で読めるビルドログなので、検証記事ではない。
ライブデモはHTTP 200で返っており、GitHubリポジトリも公開されている。
ただ、モデルの回答精度、国別データの更新手順、選挙情報の根拠提示、負荷試験、悪用テストまでは示されていない。

選挙ガイドAIとして見るなら、次のあたりが詰めどころになる。

回答に制度情報の出典を必ず出せるか
国・地域・言語ごとの更新日をユーザーに見せられるか
候補者推薦、政党比較、投票誘導をどう扱うか
説明と個人情報収集の境界をどこに置くか
音声入力の誤認識が政治的に危ない回答へつながらないか

AIで民主主義をゲーム化する、という言い方は派手だ。
ただ、実装としては「制度説明を会話・音声・比喩に分解する」話で、そこは普通に使い道がある。候補者推薦に踏み込まず、参加前の迷子を減らす道具として切るなら、Gemini 2.5 FlashとNext.jsの組み合わせはかなり現実的だ。

日本の選挙制度を例にすると

VoteWise AIは13か国をカバーすると書かれているが、日本が含まれるかは不明だ。
ただ、日本の選挙制度は「制度説明を比喩で伝える」難易度が高い好例なので、このブログの海外読者向けに整理しておく。

日本の国政選挙は二院制で、衆議院（House of Representatives）と参議院（House of Councillors）がある。
それぞれ選挙の仕組みが違う。

衆議院の小選挙区比例代表並立制

衆議院の定数は465議席。選び方は2つが並行して走る。

小選挙区（Single-Member Districts）が289議席。
全国を289の区に分け、各区から1人を選ぶ。得票1位だけが当選する単純小選挙区制だ。

比例代表（Proportional Representation）が176議席。
全国を11ブロックに分け、各政党の得票率に応じて議席を配分する。名簿順位は政党が事前に決める拘束名簿式。

この2つが独立して計算されるのが日本の「並立制」（Parallel System）の特徴だ。
ドイツやニュージーランドの「併用制」（Mixed-Member Proportional, MMP）では、比例の議席が小選挙区の結果を補正するように配分される。日本の並立制にはこの補正がない。小選挙区で大勝した政党が、比例でも相応の議席を取れる。

さらに、衆議院には重複立候補（Dual Candidacy）がある。
候補者は小選挙区と比例代表の両方に同時に立候補できる。小選挙区で落選しても、比例名簿での順位と「惜敗率」次第で復活当選する。

惜敗率（Sekihairitsu / Close-Loss Ratio）は「自分の得票数 ÷ 小選挙区の当選者の得票数」で計算される。
比例名簿で同じ順位に並んだ候補者のうち、惜敗率が高い人から順に議席を得る仕組みだ。

参議院の選挙区と全国比例

参議院の定数は248議席で、3年ごとに半数の124議席を改選する。

選挙区（Constituency）が148議席（改選74）。都道府県単位で、定数は1〜6と幅がある。
比例代表が100議席（改選50）。全国単位の非拘束名簿式で、有権者は政党名でも候補者個人名でも投票できる。個人名の得票が多い候補から当選する。

2019年からは「特定枠」（Priority Allocation Slots）が導入された。
政党が指定した特定枠の候補者は、個人名得票に関係なく名簿上位に固定される。比例代表なのに実質的に政党が議席を指名できる仕組みで、導入時にはかなり議論になった。

ドント式で議席を割り振る仕組み

比例代表の「得票率に応じて議席を配分する」と書いたが、実際の配分アルゴリズムはドント式（D’Hondt method）だ。
日本の衆議院比例代表も参議院比例代表も、ドント式で各政党の議席数を決める。

やっていることは単純で、各政党の総得票数を1、2、3、4…と整数で割っていき、商が大きい順に議席を渡す。
定数5の架空のブロックで、A党が1200票、B党が720票、C党が300票を得た場合を見る。

除数	A党（1200票）	B党（720票）	C党（300票）
÷1	1200 ①	720 ②	300
÷2	600 ③	360 ⑤	150
÷3	400 ④	240	100
÷4	300	180	75

商を大きい順に並べると 1200、720、600、400、360… で、5議席目までを取るとA党3、B党2、C党0になる。
得票率でいえばA党54%、B党32%、C党14%だから、定数5に対してA党2.7、B党1.6、C党0.7が「厳密な比例配分」だが、ドント式は大政党がやや有利に出る。

この「やや有利」が積み重なると、小政党が議席を1つも取れないブロックが出てくる。
日本の衆議院比例代表は11ブロックに分かれていて、最小の四国ブロックは定数6しかない。定数が少ないほどドント式の大政党バイアスが効くので、小政党は近畿や南関東のような大ブロックでしか議席を取りにくい。

ちなみにドント式以外にもサン＝ラグ式（除数が1、3、5、7…と奇数）やヘア＝ニーマイヤー式（最大剰余法）がある。
サン＝ラグ式は中小政党に有利に働き、北欧諸国が採用している。ヘア＝ニーマイヤー式はドイツの連邦議会で使われていた時期がある。日本はドント式一本で、大政党有利の構造が制度に組み込まれている。

VoteWise AIのStory Modeでドント式を伝えようとすると、「ピザを分ける」程度の比喩では足りない。
除算テーブルを順番に埋めていく手続きなので、比喩よりもインタラクティブなシミュレーションのほうが向いている。票数を入れたら配分が動くUIを見せれば、言葉で説明するより早い。

Story Modeで日本の制度を伝える難しさ

この制度をVoteWise AIのStory Modeで伝えようとすると、難所が見えてくる。

小選挙区と比例代表の「並立」は、ピザの比喩では無理だ。
「同じ選挙で2種類の投票用紙をもらう」という事実自体が、多くの国の有権者には馴染みがない。重複立候補と惜敗率に至っては、制度を知っている日本人でも正確に説明できる人は少ない。

制度要素	難易度	Story Modeでの課題
二院制	低	多くの国にあるので比喩しやすい
小選挙区	低	英米の仕組みと似ている
比例代表	中	拘束と非拘束の違いを潰さない比喩が要る
ドント式	高	除算テーブルの手続きで、比喩よりシミュレーション向き
並立制	高	併用制との違いを正確に伝える必要がある
重複立候補	高	他国にほぼない仕組み
惜敗率	非常に高	計算ロジックを比喩にすると誤解を生む
特定枠	高	非拘束名簿の例外で、制度の中の制度

VoteWise AIが日本をサポートするなら、Story Modeの比喩だけでは足りない。
比喩の後に「実際の制度ではこう動く」を必ず見せるか、チャットで段階的に質問させて理解度に合わせて説明の粒度を変えるほうが現実的だ。

ただ、読み返すと「で、これ結局誰が使うの」がまだ引っかかる。
選挙制度の基本的な質問は汎用LLMに直接聞いても十分な回答が返ってくるし、13か国ぶんの制度データを個人が管理し続けるモチベーションも、回答精度を担保する仕組みも、原典からは見えなかった。
「ゲーミフィケーション」も看板の割にはStory Modeだけで、ゲーム的なインセンティブ設計があるわけではない。

civic techで実績のあるVote.orgやBallotpediaは、検証済みの構造化データを自前で持っている。
LLMの出力ではなく、正確なデータが信用の根拠だ。
VoteWise AIにはそのデータ層がなく、Geminiの一般知識に頼ることになる。だったら専用アプリを挟まず直接聞けばいい、という話に戻る。

ポートフォリオとしてはまとまっている。
ただ「選挙ガイドAI」を名乗るなら、LLMラッパーの上にどんなデータ基盤と検証プロセスを載せるかが見えないと、看板だけが先に走っている。

もう少し考えると、選挙制度の一般的な説明は汎用LLMが普通にこなせる領域だ。
VoteWise AIが刺さるとしたら、汎用LLMの学習データに入っていないような、特定イベントやアプリに閉じた投票フローの案内かもしれない。

たとえば劇場版ヒプノシスマイクは、上映中に観客がリアルタイム投票するシステムだった。
専用アプリでの投票操作、投票タイミング、結果のWeb確認、全部が並行して走るので初見だとかなり忙しい。
ああいう「このイベント固有の投票の仕方」を、アプリ内AIが即答してくれるなら用途は見える。

ただ、それもチュートリアルUIを丁寧に作れば済む話ではある。
「制度が複雑だからAIに聞ける形にする」と「UIで段階的に案内する」の間に、AIじゃないと埋まらない溝があるかと言われると、正直まだ分からない。