大人（になりきれない大人）の自由研究・第二弾② ReactもGitHubも初めて。それでもAIと約6時間でWebアプリを形にできた
React、Vite、Supabase、GitHub、Vercel。
よく「ICT、お得意なんでしょ？」と言われるけど、あくまでユーザーとしていろんなサービスを使い分けて使ってるにすぎない。もちろん、こんなサービス、GitHubは聞いたことあるけど、ぐらい。自分は誰が何と言おうと「素人！」（自信を持って言うw）
今回のデジタルスタンプシステムを作るために使ったものだ。名前くらいは聞いたことがあっても、この日までほとんど、あるいはまったく触ったことがなかった。
Node.jsを自分のパソコンに入れるのも初めてだった。
それでも、朝に考え始めた仕組みが、夕方にはブラウザで動くWebアプリになった。かかった時間は約6時間。自分でコードを書いた時間は、ほぼゼロだった。
ただし、「AIが全部やってくれた」という話でもない。
今回は、その一日を振り返ってみたい。
（第1回では、紙のスタンプカードが抱えていた問題と、Webアプリを作ることになった経緯を書いた。公開後、ここに第1回へのリンクを追加予定。）
午前——作る前に、AIと要件を削った
最初にしたのは、コードを書かせることではなかった。
紙の運用で何に困っているのか。教員はどのタイミングで何を入力するのか。生徒には何を見せ、何を見せないのか。学校の環境で使えないサービスは何か。
AIと対話しながら、必要な機能を整理した。
完成形は、かなり単純になった。
教員は欠席者を選ぶ
出席者には自動で4ポイント入る
必要な生徒にだけボーナスを加える
生徒は自分のポイントと履歴だけを見る
最初から機能を盛り込みすぎなかったのがよかったと思う。
AIは、頼めばいくらでも機能を提案してくれる。グラフ、通知、称号、ランキング、分析画面。しかし、機能が増えれば、作る手間だけでなく、教員と生徒が覚える操作も増える。
今回の目的は、立派なシステムを作ることではない。授業の最初と最後に発生している手間を減らすことだ。その目的から外れる機能は、いったん入れないことにした。
午後——まずは「見た目だけでも動くもの」を作った
要件が固まったところで、ClaudeにReactのコードを生成してもらった。
最初にできたのは、ブラウザの中だけで動く試作品だった。科目を作り、名簿を登録し、出欠を入力し、生徒用の画面でポイントを確認できる。
ただし、この段階では画面を再読み込みするとデータが消える。
それでも、見た目だけの試作品には大きな意味があった。
文章で「教員用画面」「生徒用画面」と考えているだけでは分からなかったことが、実際に触ると見えてくる。欠席者だけを選ぶほうが早い。名簿には氏名だけでなく、出席番号だけを使いたい場合もある。ボーナスの入力場所は、出欠と同じ画面にあるほうがよい。
動く画面があると、要望が具体的になる。
「何となく違う」ではなく、「このボタンはここ」「この入力は不要」とAIへ伝えられるようになった。
夕方——消えないデータと、公開する場所を用意した
次は、試作品を本物のWebアプリに近づける作業だった。
役割ごとに使ったサービスは次のとおり。
| 役割 → 使用したもの |
| 画面を作る → React + Vite |
| データを保存する → Supabase（PostgreSQL） |
| コードを保管する → GitHub |
| Web上に公開する → Vercel |
試作時点では、いずれも無料枠の範囲で始められた。
Supabaseを選んだのは、学校のネットワーク環境を考慮したことに加え、PostgreSQLという広く使われているデータベースを土台にしているからだ。将来、別の環境へ移すことになった場合にも、特定の仕組みに閉じすぎないほうがよいと考えた。
環境を用意し、AIが生成したコードを配置し、データベースとの接続を設定する。GitHub DesktopでコードをGitHubへ送り、Vercelから公開する。
文字にすると数行だが、初めての画面ばかりだった。
当然、エラーは出た
一番印象に残ったのは、初めてでもエラーが出なかったこと——ではない。
ちゃんと、いくつも出た。
データベースへ接続すると認証エラーになる。テーブルへアクセスしようとすると権限のエラーが出る。開発に必要なツールを入れようとすると、サーバーから取得できないと言われる。
これまでなら、英語のエラー画面を見た時点で「自分には無理だ」と止まっていたかもしれない。
今回は、エラーメッセージと、直前に何をしたかをAIへそのまま伝えた。すると、考えられる原因と確認する場所、次に試す一手が返ってくる。
うまくいかなければ、その結果をまた返す。コマンド操作で進めなかったところは、別の方法としてGitHub Desktopを使う案が出てきた。
エラーが「終了の合図」ではなく、次の質問を作る材料になった。
これは、今回いちばん大きかった変化かもしれない。
AIへの相談で意識した3つのこと
振り返ると、AIへは次の3点をできるだけセットで伝えていた。
1．いま何をしようとしているか
「Webアプリを作っています」だけでなく、「生徒用画面から保存済みのポイントを読み出そうとしている」のように、現在地を具体的にする。
2．直前に何をしたか
どの画面で、どの設定を変え、その後どうなったか。原因の候補を絞る材料になる。
3．画面に何と出ているか
エラーを自分の言葉で要約しすぎず、秘密情報を除いたうえで、表示された文面を正確に伝える。
「動きません。どうしたらいいですか」よりも、この3つがあるほうが答えは具体的になった。
コードを書かなくても、判断は必要だった
今回、コードの大部分はAIが生成した。
しかし、私は何もしていなかったわけではない。
何を作るかを決める。学校の制約を伝える。提案された方法の中から選ぶ。画面を触って修正点を見つける。エラーの状況を返す。どこまでを試作品とし、何を今後の課題に残すかを判断する。
AIがコードを書いても、目的までは決めてくれない。現場で本当に使えるかを判断できるのは、その現場にいる人間だ。
だから「プログラミングの知識がなくても誰でも簡単に作れる」とまでは言わない。初めて見る用語は多いし、設定を間違えれば動かない。学校で扱う以上、安全性や運用ルールの確認も欠かせない。
それでも、以前なら何日も検索して諦めていたかもしれない場所を、AIとの対話で一つずつ越えられた。
約6時間後、手元だけで動いていた試作品は、端末を問わずブラウザから開ける形になった。
では、そのアプリで実際に何ができるのか。そして、「完成した」と「学校で使える」の間には、何が残っているのか。
最終回は、できあがった仕組みと、作ったあとに見えてきた課題について書く。
※本記事は試作の記録です。サービスの提供条件や利用できる機能は変更される場合があります。実際の学校運用では、所属先の規定を確認してください。認証情報や具体的な設定値は掲載していません。
