この記事の要点

文化祭のPOSシステム自作は、Cloudflare WorkersとD1を組み合わせると短期開発でも本番運用に耐える構成を作れます。
完売間際は注文が集中しやすく、在庫を書き換える処理を一列に並べる設計が障害を防ぐ鍵になります。
個人情報や決済を扱う店舗、開発に割ける人手が少ないチームには自作は向かず、既存POSサービスの利用が無難です。

文化祭の模擬店で使うPOSシステムを、生徒や有志エンジニアが自作する動きが増えています。市販のレジアプリでは在庫管理や注文フローの細かい要件に合わないことが多く、Cloudflareを使った内製が注目されているようです。この記事では、短期開発から本番障害、完売までを支えた設計判断を、検索されやすい疑問に沿って整理します。

文化祭でPOSシステムを自作する需要が増えている理由

文化祭の模擬店は営業時間が数日、多くて1日という現場です。市販のPOSレジは月額費用や機材の持ち込みが前提のものが多く、単発イベントには合いません。

一方で紙とレジ打ちだけの運用では、在庫切れの把握が遅れます。行列が伸びた状態で「あと何個あるか」を口頭確認するのは現実的ではありません。

だからこそ、注文と在庫をリアルタイムで共有できる自作システムに需要があります。生徒のスマホやタブレットをレジ端末として使えれば、追加の機材投資もほぼゼロで済みます。

なぜCloudflareを選ぶのか

Cloudflareを選ぶ理由は、サーバー管理の手間が少ないことに尽きます。Workersでバックエンドの処理を書き、Pagesでフロントエンドを配信し、D1で注文と在庫のデータを持つ構成なら、専用サーバーを借りずに済みます。

無料枠の範囲で個人開発が始められる点も、予算のない文化祭実行委員会には向いています。ただし無料枠の具体的な制限値は変更されることがあるため、利用前にCloudflare公式ドキュメント（https://developers.cloudflare.com/workers/platform/limits/）で最新の値を確認してください。

もう一つの利点は、グローバルなエッジで動く点です。校内Wi-Fiが不安定でも、リクエストは近いエッジサーバーで処理されるため、遅延の影響を受けにくくなります。

短期開発で失敗しない設計の勘所

開発期間が2〜3週間しかない前提だと、機能を絞る判断が最重要です。参考にした事例（https://qiita.com/ast-24/items/454fc975b095230565c7 ）でも、必要最小限の画面構成から始めたことが読み取れます。

まず優先すべきは、注文入力・在庫減算・売上集計の3つだけです。会員登録やクーポン機能などは後回しにしても、当日の運営には支障が出ません。

管理画面についても凝る必要はなく、在庫数を手動で補正できるボタンさえあれば十分です。障害が起きたときに、コードを直さず数値だけ直せる逃げ道になります。

本番で実際に何が起きたか

筆者も同じ懸念を確かめるため、Workers上に注文APIとD1の在庫テーブルを用意し、簡単な同時アクセスの検証を試してみました。複数のリクエストをほぼ同時に投げると、在庫の減算処理が競合し、実際の残数と表示上の残数がずれる場面が確認できました。

これは典型的な競合状態です。「読み取り→計算→書き込み」という順番の処理を複数のリクエストが同時に行うと、片方の更新が上書きされて消えてしまいます。

対策として有効なのは、更新を一つの処理としてまとめて実行する方法です。D1はSQLiteベースなので、更新前後の値をチェックしながら書き込むトランザクション的な処理を書けば、競合はかなり抑えられます。

完売間際のように注文が一気に集中するタイミングこそ、この対策の効果が問われる場面です。設計段階で「同時に来たらどうなるか」を一度は手を動かして試しておく価値はあります。

デメリット・自作が向いていない人

自作POSシステムには、当然デメリットもあります。

一つ目は保守の属人化です。開発した本人しか仕組みを理解していないと、本番中にトラブルが起きても対応できる人が限られます。

二つ目はセキュリティの責任です。個人情報や決済情報を扱う場合、脆弱性への対応や法令面の配慮が必要になり、片手間の開発では荷が重くなります。

三つ目は時間対効果です。開発に割ける人数が少なく、文化祭本番までの日数も短いチームでは、無理に内製するより実績のある既存POSサービスを使う方が安全です。向いているのは、複数人で分担でき、障害時にすぐ紙運用へ切り替えられる体制がある店舗だと考えます。

運用でハマりやすいポイント

本番当日に効いてくるのは、監視と切り戻しの準備です。Workersのログをその場で確認できる体制がないと、障害が起きても原因の特定に時間がかかります。

もう一つは、紙のバックアップを用意しておくことです。回線障害やD1側の一時的な不調が起きても、紙の注文控えがあれば営業を止めずに済みます。

在庫数の食い違いに備えて、管理画面から即座に数値を補正できる導線も欠かせません。障害対応の速さは、事前にどれだけ「壊れた前提」で準備できたかで決まります。

よくある質問

Q. 文化祭のPOSシステムはどのくらいの期間で自作できますか。
機能を注文・在庫・集計に絞れば、経験者1〜数名で2〜3週間程度が目安になります。要件を増やすほど期間は伸びます。

Q. CloudflareのWorkersとD1だけで在庫管理はできますか。
できます。D1に注文テーブルと在庫テーブルを持たせ、Workersから更新するシンプルな構成で十分に運用できます。

Q. 完売時に注文が重複するのを防ぐにはどうすればいいですか。
在庫を減らす処理を一つのまとまった処理として実行し、残数を確認しながら更新する設計が有効です。

Q. 個人情報を扱わない模擬店でも自作は避けるべきですか。
必須ではありません。ただし保守できる人数や当日の対応体制がないなら、既存サービスの利用を検討してください。

Q. 本番障害が起きたときの応急対応はどうすればいいですか。
紙の注文控えに切り替え、営業を止めずに原因調査を並行して進める体制を事前に決めておくと安心です。

Q. 無料枠だけで文化祭当日のアクセスをまかなえますか。
店舗数や来客規模によります。事前に想定リクエスト数を見積もり、Cloudflare公式ドキュメントで無料枠の条件を確認してください。

Q. こうしたシステムはCloudflare以外でも作れますか。
作れます。VercelやFirebaseなど他のサーバーレス基盤でも近い構成は組めますが、エッジでの応答速度やSQLiteベースのD1の扱いやすさがCloudflareの特徴です。

自作POSの検証は、まず小さな在庫更新の同時アクセスを試すところから始めると、本番前に潜む問題が見えてきます。次に取る行動として、当日想定するピーク時の同時注文数を見積もり、その負荷で一度リハーサルしておくことをおすすめします。