セルフレジ端末を手に入れたのでイベントのチェックインシステムを作った
こんにちは、まるとです。最近かなり暑くなってきましたね。
中の人は溶けそうです。
記事はクラスメソッドの有志による『夏休みの自由研究リレー』第3回のエントリです。
このブログリレーの企画は、普段からクラウドやAIを追いかけているメンバーによって、「やってみた」だけではなく「作ってみた」や「調査/研究してみた」もアウトプットしてみようという企画です。
新たな知見になることは勿論、アイデアを自社やコミュニティの発展に寄与できればと考えておりますので、お付き合い頂けますと幸いです。
今回は自由研究ということで、面白い端末を入手したので、活用しつつ簡易的なアプリの設計についてお話しできればと思います。
はじめに
本題に入る前にはじめましての方もいらっしゃると思うので簡単に自己紹介をさせてください。
2024年9月にAWSに関する仕事を本業にしたく入社したまるとです。
（当時のジョインブログ）
プライベート寄りの趣味だとガジェットなど珍しいモノが好きだったりします。
本題
本題です。今回、色々な機会があり、画像のようなAndroid端末を入手しました。
よくセルフレジや飲食店の券売機で見るような端末です。何に使うかは置いておいて、個人宅にあったら面白いかな位の気持ちで入手しました。
ちなみに、正式な製品の名前はSUNMI K2 MINIというものになります。
この端末の特徴として、以前ご紹介した端末のようにレシートプリンターやバーコード/QRコードリーダが内蔵されていることです。
せっかくの機会なので、普段あまり作り慣れていないAndroidアプリを開発してみます。
今回作るもの
普段、コミュニティを運営していることもあり、"セルフで何かできる端末"ということからイベントのセルフ受付システムを作ることにしました。
今日では生成AIの発達により気軽にアプリを作ることができますが、今後の運用・保守を考えて設計から考えていければと思います。
設計
生成AIを利用すると、プロンプトを入力するだけでアプリケーションの雛形を短時間で作成できます。特に今回のような小さめのアプリであれば、「イベント受付アプリを作って」と依頼するだけでも、それらしい画面や処理はすぐに生成できるなどプロトタイプの開発がかなり高速化されています。
一方で、実際にイベント当日に利用することや複数イベントでの利用など継続的な運用を考えると、単に画面が動くだけでは不十分です。
受付中にアプリが止まると困りますし、参加者情報の修正、受付済みかどうかの確認、二重受付の防止、端末側のスキャナやプリンタとの連携など、後から考えると意外と気にすることが多くあります。
そこで今回は、いきなり実装を始めるのではなく、まず簡単にシステムの役割を整理しました。
生成AIにすべてを任せるというより、どのような構成にするか、どこを分けておくと後から直しやすいかを考えたうえで、実装を進めることにしました。
生成AIで作るための整理
生成AIで開発を行うにあたり、いきなりアーキテクチャ設計を行うのではなく、作ったアプリを保守しやすくなるための設計を考えます。
今回のように特にシンプルなシステムでは、仕組みを作ること自体はそれほど難しくありません。参加者のQRコードを読み取り、該当する参加者を探し、受付済みにするだけであれば短時間で形にできます。
しかし、実際にイベントで使う場合いくつか考えておくべきことがあります。
例えば、QRコードを忘れた参加者をどう受付するのか、誤って受付済みにした場合に取り消せるのか、同じQRコードを連続で読み取った場合に二重受付にならないか、端末のプリンタやスキャナがうまく動かなかった場合に受付自体を止めないようにできるか、といった点です。
そこで今回は、まず以下のような方針を考えました。
- 受付オペレーション的な観点
- QRコードによる受付を主な動線にする
- QRコードが使えない場合に備えて、名前などによる検索受付も用意する
- 当日トラブルが起きても、受付処理自体はできるだけ止めない
- システム的な観点
- 参加者情報と受付履歴を分けて管理する
- 端末固有のスキャナやプリンタ処理は、受付処理そのものと分ける
- 受付済みかどうかだけでなく、いつ・どの方法で受付したかを残す
生成AIを使う開発の場合、最初のプロンプトで「イベント受付アプリを作って」とだけ伝えると、画面や処理は作ってくれます。
一方で、どの情報を履歴として残すのか、どの処理を共通化するのか、端末依存の処理をどこに閉じ込めるのか、といった判断は曖昧になりがちで要件がブレる可能性が高くなります。
そのため、生成AIに実装を依頼する前に、まずは困りそうなこと、後から変更が入りそうなことの2つを整理しました。
今回のアプリでは、完璧な設計を最初から目指すのではなく、受付当日に止まらないこと、後から機能追加しやすいこと、トラブル時に状況を確認しやすいことを重視しています。
受付の流れの整理
まずは、イベント当日の受付の流れを整理します。
基本の流れは、参加者がQRコードを提示し、端末側で読み取り、該当する参加者を受付済みにするというものです。
受付が完了したら、画面上に受付完了の表示を出し、必要に応じてレシートを印刷します。
一方で、すべての参加者がQRコードをすぐに提示できるとは限りません。
メールを探すのに時間がかかる人や、スマートフォンの画面が暗くて読み取れない人、そもそもQRコードを忘れてしまう人もいます。
そのため、QRコードによる受付だけでなく、名前やふりがななどで参加者を検索し、手動で受付できる導線も用意することにしました。
ここで重要なのは、QRコード受付と手動受付で別々の受付処理を作らないことです。入口はQRコードと検索で分かれていても、最終的に「参加者を受付済みにする」という処理は共通にします。
そうすることで、二重受付のチェックや受付履歴の記録、エラー時の扱いを一箇所にまとめやすくなります。
データ保存方法の検討
単純に作るのであれば、参加者情報に「受付済み」という情報を持たせるだけでも実現できます。
しかし、その形だと、いつ受付したのか、どの方法で受付したのか、誤って受付した場合にどう取り消すのかが分かりにくくなります。
そのため参加者情報と受付履歴を分けて管理する、と言う要件を設定します。
参加者情報には、氏名、所属、チケット種別、QRコードに含める識別子などを持たせます。一方、受付履歴には、受付時刻、受付方法、取り消しの有無などを持たせます。これにより受付状況を確認できるだけでなく、トラブルがあった場合にもいつ、どの方法で受付されたのかを後から確認できます。
生成AIでアプリを作る場合でも、このようなデータの持ち方は先に決めておいた方がよいと感じました。
データ構造が曖昧なまま画面やAPIを作り始めると、後から受付取消や履歴確認を追加したくなったときに、既存の実装を大きく直す必要が出てきます。
端末固有の処理について
今回利用する端末には、QRコードリーダやレシートプリンタが内蔵されています。せっかくなので、受付時にQRコードを読み取り、受付完了後にレシートを印刷するような動きも作りたいところです。
ただし、スキャナやプリンタは端末・ライブラリ固有の処理です。受付APIや参加者管理の処理と強く結びつけてしまうと、後から別の端末やWeb画面で受付したい場合に流用しづらくなります。
そのため、アプリの中では、受付処理そのものと端末固有の処理を分けて考えます。QRコードを読み取る処理は参加者を特定するための入力とし、プリンタで印刷する処理は受付完了後の出力として扱います。受付API側は、どの端末から呼ばれたかに関係なく、参加者を受付済みにする処理に集中させます。
分けておくことで、将来的にWebブラウザから受付したり、別の端末を追加したりする場合でも、受付処理の中心部分を大きく変えずに済みます。
実装
ある程度ここは決めたい、考慮したいというのを整理したら実装に進みます。
今回は細かくコードを自分で書くより、バイブコーディングに近い形で進めていきました。ただ、設計章でも述べたとおり、単純に受付アプリを作るだけを要求した場合、画面だけ動いたり、データや処理が適切に分割されていないなど、後から追加機能の実装や保守、運用がしにくいアプリができる可能性があります。
そのため、今まで整理した内容を元にどの処理を共通化したいか、どの情報を履歴として残したいか、どこを端末依存にしたくないかを伝えることで、生成AIが作るコードの方向性をある程度そろえられます。
今回は次の順序で開発を行っています。
- 要件から必要なデータ構造、API設計の要求
- 受付APIの実装
- 管理画面、受付画面の実装
- 端末側のQRコード読み取り処理の実装
- レシート印刷など端末固有機能の追加
- 動作確認しながらUIやエラー時の挙動を調整
最初からすべてを一度に作らせるのではなく、まずデータ構造やAPI設計を確認し、その後に画面や端末固有の処理を追加していく形にしました。特に、受付処理はアプリの中心になるため、QRコード受付、検索受付、手動受付のどれからでも同じ処理を利用できるようにすることを意識しています。
最初のデータ構造、API設計の要求では以下のように指示をしました。
要求事項
- イベントのセルフ受付システムを作成したい
- システム実装に向けてデータ構造とAPI設計を提案すること
概要
- 参加者がQRを提示し、受付端末（Androidアプリ）で読み取ることで受け付け
- QRが利用できない場合、名前で検索して手動受付できるように
設計方針
- QRコード受付と検索受付は、最終的に同じ受付処理を呼び出す
- 参加者情報、受付履歴は分けて管理
- 受付状況は、受付時刻は受付方法を記録
- 同一QRが読み込まれた場合、二重受付ならないようにする
- Web受付や別端末を追加できるよう、受付APIは共通化すること
- 端末固有（SUNMI K2 MINI）の機能でレシートプリンターやスキャナを利用する
- ただし、端末固有の要素が存在しない端末でも受付処理が行えるように、プリント処理やスキャン処理は受付処理と分けること
- また、端末固有のスキャナではなく、カメラによる入力も受け付けること
いくつか生成AIを使ってプロトタイプの開発を行いましたが「作ってください」と要求すると多くの場合、動く画面や処理を優先して提示することが経験上多数を占めていました。プロトタイプとしては十分ではありますが、実施に利用するアプリの場合、当日の運用に沿って例外などが起きた場合でもエラーで受付を止めないことも重要になります。
そのため、最初のプロンプトでは何を作りたいか、にフォーカスするのではなく、どのような処理を分けて、何を共通化したいのか、エラー時の振る舞いなどを考えて記載するようにしました。
また、APIの実装時には以下のように要求しています。
要求事項
- 設計を元に受付APIを実装
フロー
1. QR内のトークンより参加者の検索
2-1. 参加者が存在しない場合: 該当無しを通知
2-2. 受付済みの場合: 重複受付せず、受付済みであることを通知
2-3. 未受付の場合: 受付処理を行い、履歴を作成
3. レスポンスには、受付結果、参加者ID、受付時刻を含める
考慮事項
- 受付処理はQR、手動どちらも使えるように共通化
- エラー時のレスポンス形式も統一
APIの段階で挙動を整理しておくと、画面側や端末側の実装がシンプルになります。画面側はAPIの結果を表示することに集中でき、QRコードの読み取りや検索受付など入力方法が増えても、受付処理そのものを大きく変えずに済みます。
管理画面などは割愛しますが、端末固有の処理についても整理をしつつ、受付処理と混ざらないように分けるように指示をしました。
例
要求事項
- SUNMI K2 MINIで利用するQR読み取りとレシート印刷の実装
- 各種ライブラリ、ドキュメントへのURL: <URL>
- 端末固有の処理のため、受付APIとは分離すること
処理要件
- QR読み取りは、読み取り文字列を受付APIに渡す
- レシート印刷は、受付成功後の追加処理として扱う
- レシートの内容
- イベント名
- 受付完了した旨
- 名前
- 受付日時
- 予約セッションの一覧（時間、会場、セッション名）
- 受付QR
- 印刷にエラーが発生した場合でも、受付処理に影響はしないこと
- 印刷処理に失敗した場合、失敗の表示を行う（ただし、プリンタの初期化に成功している場合に限る）
- 他端末でも受付ができるよう、端末依存の処理はAPIなどと分離されていること
また、指示量が増えてくるとあるあるなのですが、実装を進めていく上で似た処理が複数箇所に出ることもあります。そのため適宜、コードの重複チェックや整理を要求するようにします。
今回できたもの
管理画面
（少し急ぎで作ったのもありまだまだ最適化余地はあります）
受付キオスク
生成AIを活用した環境において保守を考える
生成AIを利用すると、アプリケーションの実装速度は大きく上がります。画面、API、データ操作、エラー処理なども、自然言語で指示するだけである程度形にできます。実際、今回開発したシステムは1時間ちょっとで実際に使えるものになりました、
一方で、生成AIが作ったコードであっても、運用や保守が不要になるわけではありません。むしろ、短時間で多くのコードが生成されるからこそ、あとから読み返せる構成になっているか、変更しやすい責務分担になっているかを確認することが重要になります。
また、動くものを素早く作れる反面、途中で要件を追加していくうちに、似たような処理が複数箇所に増えたり、画面側に本来共通化すべきロジックが入り込んだりすることがあります。最初は問題なく動いていても、後から仕様変更や機能追加を行うときに、どこを直せばよいのか分かりにくくなる可能性があります。
そのため、生成AIに任せる範囲と、人間側で判断する範囲を分けることも重要だと感じました。コードの雛形や実装の候補を作ることは生成AIが得意ですが、どのデータを残すべきか、どの処理を共通化すべきか、エラー時にどこまで処理を継続するかといった判断は、アプリケーションの使われ方を考えながら決める必要があります。
また、最初から完璧な設計を作る必要はありませんが、動くものができた段階で終わりにせず、作りながら責務の分離、共通化、エラー時の扱い、テストやドキュメントの整備を見直すことで、後から変更しやすいアプリケーションに近づけられます。
今回の実装でも、生成AIに任せる部分と、人間が設計方針として決める部分を分けることで、バイブコーディングの速さを活かしつつ、保守しやすい形を目指しました。生成AIを利用した開発では、速く作ることはもちろんですが、後から直せる状態にしておくために整理することが大切だと感じました。
終わりに
今回は珍しい端末を手に入れたので、実際に活用するための仕組みを作ってみました。
仕組み作りにあたり、生成AIを利用することで短時間で動くところまで作ることができた一方で、実際に本番で運用するなど長期的な視点では、改修などのメンテナンスを考えなくてはいけません。
生成AIによって開発の速度は大きく上がりましたが、保守や運用を考えた設計の重要性は変わらないと感じました。むしろ、速く作れるようになったからこそ、どのように作るかを意識して整理を行う必要があります。
今回は夏休みの自由研究且つシステム作りがきっかけとなりましたが、今後も長期的な観点でうまくAIを使っていければと思います。
以上、『夏休みの自由研究リレー』の第3回のエントリ『セルフレジ端末を手に入れたのでイベントのチェックインシステムを作った』をまるとがお送りいたしました。
次回はすらぼさんの「Google Cloud 組織のIAMポリシー全部消してみた」の予定です。お楽しみに！！
