はじめに

お久しぶりです．まともに記事を書いて投稿するのは久しい頃ですが，ちょっとした(インチキ)個人開発の話をしようと思います．

完成品

以下が完成品です．

GitHubリポジトリも掲載しておきます．無いとは願いますが自作発言，違法並びにそれに準ずる行為さえしなければ自由に使っていただいて結構です．見た目が変更になる可能性はありますが，データは保持されるのでご安心ください．

ついでにリリースノートも．

投票サイト？

今回は，私が通う高校のある教科担任に「授業内容の理解度が集計できる投票みたいなものを作ってほしい」と頼まれたことが発端の個人開発です．

理解度というのは，以下の4つの選択肢になります．

理解できた
大体理解できた
あまり理解できなかった
全く理解できなかった

この4段階の投票をサービスに組み込みます．その際，気を付ける点がいくつかあって，以下の通りです．

その前に理解しておいてほしいことは，今回のサービスは以下のようなブランチ構成になります．それを踏まえて読んでください．

voting/
├ index.html
├ master.html
├ slave.html
├ hiragana/
| ├ top-hiragana.html
| ├ master-hiragana.html
| └ slave-hiragana.html
└ en/
  ├ top.html
  ├ master.html
  └ join.html

のちのちのアップデートによってひらがな版と英語版のページはディレクトリに入れたのですが，当初から存在した標準日本語版はもう収めることができないくらい複雑な構成になってそれをする気が失せたのでそのまま放置です．

ということで，今回の開発で必要なことは，

Master/SlaveともにWeb上で操作できるか
TopにてMaster作成・Slave参加が可能か
Slave側のアクセスは容易か
Master側の操作は煩雑でないか
投票状況はリアルタイムで反映できるか

の大きく5項目です．

また今回は，重要な点としてGitHub Pagesで公開しています．リアルタイム，つまり動的Webサイトを静的Webサイト用のGitHub Pagesで公開するというのは少々暴挙のように見えるかもしれませんが，そのあたりを書き残せたらな，と思います．

類似のサービスとの比較・改良点

ここではパパパコメントを挙げます．パパパコメントは2009年からサービスを開始した，発表者のPC画面上にそれを聞いている人のコメントを流すサービスです．絵的にはニコニコ動画が近いと思います．

しかしこれには，今回求められているものとは圧倒的に異なる点があります．それは，発表者(Master)側にはPCソフトの導入が必要であることです．画面に対してオーバーレイで表示するためソフトが必要になります．

しかし，今回求められているのは画面上に表示すれば良いだけなのです．つまり，GitHub上ではないどこかにサーバーを置いたり，PHPで制御したりすれば良いのですが，前者は金銭的にもハードルが高く，後者はそもそも非対応です．

そこで，Google Firebaseを使うことにしました．Firebaseのリアルタイム保存料域をJavaScriptコードによって常に読み続けることで，HTMLで構築されたフロントエンドに数値を反映させ，実質的に動的Webサイトを実現します．

また，サーバー入室の方法も多少改良しました．パパパコメントでは「部屋の名前」と呼ばれるIDを入力することで入室できます．発表者が直接QRコードを表示する方法もありますが，ひと手間挟まるというのは避けたいものです．

そこで，私のものについては，標準でQRコード生成機能を装備しています．detailタグ内にQRコードの画像が入っているのでSummaryを押して開けば表示されます．しっかりリンクのコピー機能も実装しているので入室方法は十分と言えるでしょう．

多少比較をしながら，紹介しましたが，決してパパパコメントが悪いというのではなく，むしろ良いサービスだと思っています．Slave側の操作感は完全にパパパコメントを踏襲したものです．

サイトについて

例によってAIをガンガン使っています．ご了承ください．そもそも1時間半で作った突貫工事作品です．

まぁAIに問いかければ大体のことは分かるので，作り方は省きます．気になる方はソースコードを見ていただければ，と思います．

このサービスは，教育目的のため極限まで機能を削減しています．特にSlave側は顕著で，入室したら投票をし，投票の状況を確認する機能しか設けていません．

投票のお題や，(繰り返し投票の禁止，)投票打ち切り機能などは実装を考えていますが，Google Formにあるような高度な機能は実装しないつもりです．

これは最終的に私が調整した後のものをClaudeで評価してもらった際の一部です．おわかりいただけるように，そもそもサービスの方向性が違います．とにかく簡単さを求めたサービスのため，このような結果になっています．

実際，「純粋な投票サービス・システム」として評価してもらうと，結果はD+と悪い結果です．

しかし，これを教育用として評価してもらうとどうでしょうか．その瞬間に評価はA+までに変化します．これは教育用として極限まで機能を削った結果でしょう．容易なアクセス方法・操作が功を奏した評価結果です．

機能を絞ることはときに重要だということを実感できました．

少しずつ機能を追加する

リンクコピー機能

せっかく参加リンクを表示しているというのに，コピーが選択してからコピー…だと面倒ですよね．そこでまずリンクコピーボタンを追加します．

ボタンを押すと，リンクをクリップボードにコピーしてコピー成功のアラートを表示します．もちろん失敗したら失敗のアラートが表示されます．

QRコード表示機能

これはクラスで使ううえでは必須の機能です．先生がプロジェクターや電子黒板(私の学校では前者)に表示させて，QRを出せたら参加が楽になります．

どっかからライブラリを借りてきて，JavaScriptコード内でQR生成処理をします．そこで生成されたQRコードを<detail>タグ内で表示するように設定したら，折りたたみを開けばすぐにコードが表示される仕様の完成です．

サイトアイコンの設定

なんとも，雑ではありますが以下のアイコンをパッと作成して適用しました．

なんとも，上側に偏ってる感がすごいですね．よく見かけるBad Designer / Normal Designer / Great Designerの理論に基づいてここは後に修正することとします．

PWA化

PWA化，と言ってもアイコンを設定してもろもろを.jsonファイルにまとめるだけです．Google Firebase Realtime Databaseを使っている以上，オフラインでは動きようもないのでオフライン化はしません．

強いて言うならオフライン表示を追加するのは良いかもしれません．

UI改善

追加要素ではないですが大きな変化なので．

↑Top

↑Master

↑Slave

相当大きな変化を遂げました．多少使いやすくなったと思います．

ネットワーク警告

インターネット接続が途切れた場合に表示されます．

サービス使用中に途切れた場合は表示されます．

viewport設定

スマホに対応しました，以上．

言語を増やす

言語選択フッターから選択できます．

カスタムID機能

カスタムIDでサーバーが作成できます．ここに既存のIDを入力することで入室も可能です．

重複投票禁止機能

連打投票を禁止します．しかし，たまに機能していないこともあるようです．

デバイスフィンガープリントを用いてデバイス重複を検出していますが，Cookieにログも残しています．しかし、Firebase上に保存したフィンガープリント情報を優先しているためCookie認証は不要です．そのうち削除します．

ここには問題が多いようで、詳しくは実践投入の章をご覧ください．

投票リセット時の再読み込み機能

iPad上のPWAでは再読み込みがかけられないため，投票がリセットされると，PWAを起動し直して投票に入り直す必要があります．

Web版でももちろん機能するものですが，PWA版ではソースがキャッシュされているため再読み込みもなかなかスムーズに行えました．

これにてPWA完全対応になりました．

ここでの追加機能は，全てiPadを前提にしています．なぜなら学校の端末がiPadだからです．ですが，Windowsでも動作します．持っていないので正しくは分からないですが，おそらくChromebookでも予期したように動くと思います．というか横長画面なら割と普通に使えると思います．

スマートフォンに関しては友達にも試してもらったのですが軒並みボタンが小さくて使えたもんじゃなかったですね．これに関しては画面幅調節を付け加えれば解決するかな，と思います．

実戦投入

2025年10月3日、実際に高校の1科目(物理基礎)の授業に試験導入しました．理解度確認としての利用です．ここで発覚した問題・改善点は以下の通りです．

言語選択フッターが邪魔
- 投票状況の表示と被る
デバイスフィンガープリントがバグりやすい
- 1台だけ機能していないデバイスがあった
- 逆にロックが外れないデバイスもあった
- ロック情報が他デバイスと重複して投票できないことがあった
- そもそも解除後にリロード(F5)が必要
投票数がパーセント表示できると便利

デバイスフィンガープリントについてはまあまあ致命的ですね．Firebaseのみでの認証に変更して一部は解決しそうです．Cookieが悪さをしている可能性が高い動作をしていました．出席者の約35名のうち実際に投票をしたのは15名(自分含む)で，残り全員がバグのせいとは言いませんが，隣の人も後ろの人もフィンガープリント認証で失敗して投票をできない状況でした．

学校ということで皆が使っているデバイスが同じ(私の高校の場合iPad 第9世代)ということもあってフィンガープリント情報が重複しやすいようです．

にしてもやはり1人だけ重複投票禁止機能がはたらいていなかったのが気がかりですね．その問題はFirebaseとCookieの認証優先順位の変更でデバッグ済みの問題であったため，本当に原因不明です．もしかしたらその友達には以前テストで参加してもらっていたので重複防止を実装する前のバージョンのソースコードがキャッシュされていたのかもしれません．

また言語選択フッターと表示位置が被りそうな位置にある問題は，全画面表示バージョンを作成してねじ伏せようと思います．実際，放映用にあっても良いとは思いますしね．

せっかくなので少しデータを載っけておきましょう．まず，最大アクセス数です．Search Console上ではアクセス履歴がなかったため，おそらくアクセス者は先生とクラスメイトだけでしょう．

そこで，課金状況を見てみます(お願いだから最大アクセス100を越えないでくれ)．

接続数は40，私のクラスは42人学級でそこにプラス先生が1人の43人が最大なはずです．その時にクラスにいた人は全員アクセスしていて，差分の3人分は欠席者だと考えれば良いでしょう(正確な人数を覚えていない…)．生徒は39人だったとして考えていきます．

それに対して実際に投票をした人は15人，つまり実際の利用者は約38.5%しかいませんでした．残りの61.5%に関して，もちろん匿名でも「分からない人がいる」ことを知られるのが嫌で使わなかった人もいるだろうとは予想します．

しかし，やはりデバイスフィンガープリント認証の暴走による投票不可能状態が関係していそうです．この問題の回避にはやはりCookieの削除が必要かもしれません．そして生徒F/Bに最も多かったのが「なんか投票してないのに投票済みって出ちゃうわ」でした．学校で使うサービスであるため認証精度は限りなく100%でなければなりません．

Cookie機能の削除は不要かもしれません．削除するとページが読み込む情報量は少なくなりますが，下手に削除して動作しなくなるくらいなら放置しておこうと思います．

もっと根本的に，被ってしまう要素が存在しそうです．

仮に運営元がユーザーの多い大企業だったとしたらこのような問題は即記者会見行きです．なんとかして修繕しなければならないと思いつつ，デバイスクローンのリポジトリで弄って検証しています．

にしても，やはり開発段階では分からない本番環境だからこそ判明する問題は存在するんですね．良い勉強になりました．

今後も授業のたび，メモして，修復していこうと思います．

まとめ

まずこの場を借りて，授業での試験導入をしてくださったT先生に感謝を申し上げます. おかげさまで私も開発のノウハウを多少は手に入れることもできました．また改善点はあるものの良いと評価してくださっていて，なかなか嬉しいものです．

テスト期間なので薄めの記事でしたが，もし読者に教育関係者がいらっしゃいましたらぜひ試験導入をご検討ください．

声に出して「分からない」を言えない生徒が分からないことを発信できる，ということがコンセプトですから，1回でも使っていただけると嬉しく思います．

ちなみに私に作成を依頼した先生からの評価は良く，実際に次回の授業(投稿時点)から試験導入されることになりました．

まぁ，サービスを大型化していく前にまずはFirebaseへ課金した方が良さそうです．