
2026年度のホームページファミリー代表のHです。
前回の記事では、2026年4月18日に行われたパートナー登録会で、会場を横断的に回ってもらうためにWebスタンプラリーを作ったことを紹介しました。
今回はその続きとして、このWebスタンプラリーをどのように考え、どのように作っていったのかを整理してみたいと思います。
特に、アプリケーションとしてどのような仕様にしたのか、QRコードを使ってどのようにスタンプを押す仕組みにしたのか、そしてAIに相談しながらどのように形にしていったのかに焦点を当てます。
専門的な技術解説というよりも、PTA活動の中で「こんなものがあったらいいな」を短期間で形にしていった記録として読んでいただければと思います。
バイブコーディングってなに?
前回の記事でも少し触れましたが、今回のWebスタンプラリー作りで自分の中で新しかったのは、AIに相談しながら作ったことです。
今回は、「こういう画面にしたい」「スタンプを押したらこう動かしたい」「スマホで見やすくしたい」といったアプリケーションの仕様をAIに指示して、プログラムを作成してもらいました。
最近は、こうした作り方を「バイブコーディング」と呼びます。バイブコーディングとは、AIに対して「こういう画面にしたい」「こう動いてほしい」といったイメージや意図を日本語などの自然言語で伝え、生成されたコードを動かしながら修正していく開発のやり方です。
AIが一回で完成形を作ってくれるわけではありません。出てきたたたき台を見て、「ここは少し違う」「この動きだと使いにくい」「もっと分かりやすくしたい」と判断し、自然言語で修正を指示しながら完成に近づけていきます。
バイブコーディングでは自然言語で指示を出せるため、技術的に細かい書き方が分からない部分でも、プログラムを動く形にしやすいと感じました。ゼロから全部を自分で組み立てるのではなく、まず動くものを出してもらい、それを見ながら直していくことで、短い期間でも形にすることができました。
なお、今回の作業では、プログラムを書くための画面としてVSCodeという開発用のソフト(エディタ)を使いました。その中で、入力中のプログラムをAIが提案してくれるGitHub Copilotをベースに、必要に応じて生成AIのChatGPTやGeminiも使いました。

最初に考えたこと
今回のWebスタンプラリーは、登録会までの時間が限られていたため、当日きちんと使えることを優先しました。最初から多くの機能を入れすぎず、まずは最低限必要な機能をシンプルに作ることを意識しました。
ここでは、開発を始める前に考えていたことをまとめます。
シンプルな画面構成にする

最初に考えたのは、できるだけ分かりやすい画面にすることです。
参加者の多くは、当日その場で初めてスタンプラリーを使います。そのため、説明を読まなくても、どの団体のスタンプが押されたのかが分かるように、すべてのスタンプを1画面で見えるようにし、スタンプ名や団体名も文字で表示することを考えました。
ブラウザだけで動くようにする
次に考えたのは、アプリをインストールせず、スマホのブラウザだけで動くようにすることです。
参加者に専用アプリを入れてもらうのは負担が大きいため、QRコードを読み込めばそのまま使える形にしたいと考えました。
また、当日のアクセス状況によって負荷がかかってもトラブルなく動くように、できるだけブラウザ側だけで動くシンプルな仕組みにすることを意識しました。
QRコードでスタンプを押す
スタンプを押す方法としては、各団体の場所にQRコードを置き、それをスマホで読み込む形を考えました。

紙のスタンプラリーに近い感覚で、実際にその場所へ行き、QRコードを読み込むことでスタンプが押される仕組みです。
スマホに最初から入っているQRコードリーダーやカメラアプリで読み取れるようにすることで、できるだけ簡単に使えるようにしたいと考えました。
各団体のページへ移動できるようにする
スタンプを集めるだけでなく、各団体の活動も知ってもらえるように、スタンプからホームページ内の各団体紹介ページへ移動できるようにしようと思いました。

スタンプラリーをきっかけに、参加者が「この団体はこんな活動をしているんだ」と知る導線にもしたかったためです。
不正防止は紙のスタンプラリーと同じくらいにする
不正防止については、厳密な制御までは行わない方針にしました。
本格的に制限しようとすると、ログイン機能や個人ごとの管理が必要になり、仕組みが複雑になります。
今回はPTA活動の中で使うスタンプラリーなので、そこまで厳密に管理するよりも、紙のスタンプラリーと同じくらいの考え方で十分だと判断しました。
ただし、現地に置かれたQRコードを読み込まないとスタンプが押せないようにすることで、最低限の不正防止はできるようにしたいと考えました。
全部集めたら景品がもらえる仕組みを考える
最初の段階では、すべてのスタンプを集めた人に景品を渡すことも考えていました。
そのため、全スタンプを集めたことが分かる表示や、景品を渡したあとにスタッフが「渡しました」と分かるようにする機能も検討していました。
開発中に変わったこと
最初は、できるだけシンプルに作ることを意識していましたが、実際に開発を進めていく中で、いくつか考え方が変わった部分もありました。
また、作りながら「そういえば、以前こういうことで困ったことがあった」と思い出し、途中で仕様を見直したところもあります。
景品は渡さなくなった
最初は、すべてのスタンプを集めた人に景品を渡すことを考えていたので、景品を渡したあとにスタッフが「渡しました」と分かるようにする機能も検討していました。
ただ、今回はスタンプラリーが初回だったため、不具合があったときの対応、スマホを持っていない人への配慮、オペレーションの複雑さなどを踏まえ、景品はなくすことになりました。
そのため、「全部集めたら景品を渡す」という仕組みは入れず、スタンプを集めること自体を楽しんでもらう形に変更しました。
最後まで楽しく回ってもらえるように演出を追加した
作っていく中で、景品を渡さなくなったこともあり、単にスタンプが押されるだけでは少し味気ないと感じるようになりました。
そこで、スタンプを押したときに紙吹雪が出る演出を追加しました。特に、すべてのスタンプを集めたときには紙吹雪を演出をいれて、達成感が出るようにしました。
また、スタンプを集めるごとにキャラクターが少しずつ成長していくような演出も入れました。最後まで訪れてもらうためには、「次も押してみたい」と思える小さな楽しさが必要だと感じたためです。

スクリーンショット対策として動きのある表示を入れた
Webスタンプラリーでは、画面のスクリーンショットを見せるだけでも、集めたように見えてしまう可能性があります。
もちろん、今回は厳密な本人確認や不正防止を目的にしたものではありませんが、紙のスタンプラリーと同じくらいの自然な確認はできるようにしたいと考えました。

そこで、止まった画像ではなく、実際に画面が動いていることが分かるようにするために、画面上部に文字が流れるマーキーを入れました。
サーバーの負荷を考えてGitHub Pagesを使うことにした
当日は、どのくらいのアクセスがあるか正確には分かりませんでした。
そこで今回は、HTMLやCSS、JavaScript、画像などで作られた静的なWebページを無料で公開できる、GitHub Pagesというサービスを使うことにしました。

GitHub Pagesは、多くの人がアクセスするWebページの配信にも使われているため、アクセスが集中したときの負荷に耐えやすいという特徴があります。
登録会当日に多くの人が同時にアクセスしても、できるだけ安定して表示できるようにしたかったため、このサービスを選びました。
画像をできるだけ軽くした
途中で思い出したのが、以前の翔鷗祭で、ページが重くてうまく見られない来場者がいたことです。
今回もスマホで使うことが前提ですし、当日の通信環境が必ずしも安定しているとは限りません。そのため、できるだけ画像を軽くする必要があると考えました。
そこで、画像形式をWebPにして、できるだけ容量を抑えるようにしました。
Webサイトでよく使われる画像形式には、PNG、JPG、WebPなどがあります。PNGはイラストや透過画像に向いていますが容量が大きくなりやすく、JPGは写真に向いていますが文字やイラストが少しにじむことがあります。
WebPは、画像の見た目に大きく影響しにくい部分をうまく圧縮できる形式です。PNGやJPGよりも効率よくデータを小さくできるため、今回はキャラクターやアイコンを軽く表示するためにWebP形式を使うことにしました。
余った空間を有効活用した
開発を進めていく中で、スタンプを並べたときに最後の2コマ分の空間ができました。最初は単なる余白でもよいかと思いましたが、せっかくなので有効に使うことにしました。

そこで、「パートナーズとは?」のページと、アンケートへのリンクを追加しました。スタンプラリーを楽しんでもらうだけでなく、パートナーズの活動を知ってもらったり、登録会後の声を集めたりする導線として活用できるようにしました。
作ってみて見えてきたこと
今回のWebスタンプラリーは、AIに相談しながら進めたことで、限られた期間でも形にしやすくなった部分がありました。
実際に作ってみて感じたのは、AIを使うことで「作る作業がなくなる」というよりも、「考えたことをすぐ形にして、確認しながら直していく」進め方がしやすくなるということです。
優先順位を決めることが大切だった
やりたいことは色々ありましたが、登録会までの時間は限られていました。
そのため、「どこまで作るか」「何を優先するか」を最初に考えることが大切でした。全部を入れようとすると時間が足りなくなってしまうため、まずは当日きちんと使えることを優先しました。
AIに相談しながら作る場合でも、何を作るかを決めるのは人間側です。今回は、必要な機能から順番に形にしていくことで、実際に使えるものに近づけることができました。
AIへの伝え方にも工夫が必要だった
「こういう動きにしたい」「こういう見た目にしたい」と日本語でAIに伝えられるのは、とても便利でした。
一方で、一度の指示で思ったとおりになるとは限りませんでした。言い方を変えたり、画面のイメージをもう少し具体的に伝えたりしながら、何度かやり取りを重ねることで、少しずつイメージに近づけていきました。
この経験から、AIにお願いする内容も、できるだけ小さく分けて伝える方が進めやすいと感じました。
AIの使用回数にも注意が必要だった
短期間で集中して作っていると、AIの使用回数の制限にかかることもありました。
AIに相談しながら進められるのはとても便利ですが、何度も試行錯誤していると、思った以上に利用回数を使ってしまいます。特に、画面の修正や動きの調整を何度も繰り返していると、「もう少し聞きたい」というタイミングで制限に引っかかることがありました。
そのため、思いついたことをその場で細かく何度も聞くのではなく、相談したい内容をある程度まとめてから聞くなど、使い方にも少し工夫が必要だと感じました。
AIを使えば何でもすぐに完成するわけではありませんが、考えたことを形にし、確認しながら直していくスピードを上げることはできます。今回の経験を通じて、短い期間で集中して作るときほど、AIをどこで使うか、何をまとめて相談するかも大切だと感じました。
まとめ
今回のWebスタンプラリーは、PTA活動の中で「会場を楽しく回ってもらうにはどうしたらよいか」を考えながら作ったものでした。
AIに相談しながら進めることで、画面のイメージや動きのたたき台を短い期間で形にすることができました。一方で、何を優先するかを決めたり、AIへの伝え方を工夫したりすることも大切だと感じました。
AIがすべてを自動で作ってくれるわけではありませんが、アイデアを試しながら形にしていく道具としては、とても心強い存在でした。今後も、PTA活動やホームページ運営の中で「少し便利にしたい」「少し楽しくしたい」と思う場面があれば、今回のような作り方を活かしていきたいと思います。

このブログを読んだ感想、一緒にHPFを盛り上げたい、こんな企画をしてほしい、などありましたら、ぜひ下記ホームページファミリーの問い合わせフォームからご連絡ください!

