はじめに
何気なく「赤いきつね」を食べていたときのこと。
ふと蓋をよく見たらQRコードを発見。読み込んでみたら、ブラウザで「赤いきつねだしキャッチ」というミニゲームが遊べました。
なんかあるんじゃないか？と思ってなんとなくURLを見たら……
「S3じゃん！！！」
最近個人的にアツいAWSがいたので、少し妄想を膨らませてみた話です。
発見したURL
開いたゲームのURLの構造は、以下のような形になっていました。
（※購入者特典のコンテンツのため、一部URLを伏せてます。）
https://client-app-data.s3.amazonaws.com/[キャンペーン名]/index.html
重要なのはここです。
ドメインの部分にしっかりと s3.amazonaws.com が含まれており、AWSのS3が使われていることが一発でわかりました。
AWSのS3とは？
Amazon S3（Simple Storage Service）は、AWSが提供するクラウド型のオブジェクトストレージサービスです。
S3では、データを保存する入れ物のことを「バケット」と呼び、その中にインターネット経由で画像や動画、テキストファイルなど様々なデータを安全に保存できます。
さらに、このバケットの中にHTMLやCSS、JavaScriptなどのファイルを配置して設定するだけで、サーバーを立てずにWebサイトを公開できる「静的ウェブサイトホスティング」が可能という非常に便利な機能も持っています。
技術的な考察
1. なぜサーバーではなくS3なのか？
このゲーム、ランキング機能などの動的な処理が一切ありませんでした。HTML/CSS/JavaScriptと、画像や音声などのアセットだけで動く完全な静的アプリケーションです。
これなら、EC2などのサーバーを常時立てておく必要が全くありません。
- 低コスト: サーバー代がかからず、ストレージと転送量だけの課金で済む
- スケーラブル: プロモーションによる突発的な大量アクセスがあっても、サーバー落ちの心配がほぼゼロ
S3単体で、期間限定のミニゲームを「低コストかつ安全・確実」に運用しているんだな、と納得しました。
2. なぜ独自ドメイン（専用のURL）じゃないの？
「なんで https://campaign-akaikitsune.jp みたいな綺麗なURLにしないんだろう？」と一瞬思いました。しかしよく考えるとこれは非常に合理的な最適解だとわかります。
- QRコード経由だから見栄えは気にしなくていい: ユーザーはパッケージのQRコードから直接アクセスします。検索エンジンにインデックスさせる必要も、ユーザーにURLを手入力してもらう必要もないため、URLの見た目が「生URL」のままで全く問題ないわけです。
- コストと手間の削減: 数ヶ月で終わるミニゲームのためにわざわざドメインを取り、DNSを紐付け、SSL証明書を発行・管理するのは、コストや運用の手間が見合いません。
3. バケット名から推測できる運用スタイル
もう一つ面白かったのが、URLの階層構造（S3のバケット名）です。
URLを分解すると、以下のような構造になっていました。
- バケット名（親）：
client-app-data - フォルダ名（子）：
[キャンペーン名（今回のゲーム名）]
バケット名にマルちゃん関連の名前が見当たらなかったので、もしかすると委託で制作されたゲームの可能性もありそうです。
client-app-data（クライアントのアプリデータ）という非常に汎用的な名前になっていることから、開発元の企業が「1つの共通バケットの中で、案件ごとにフォルダを分けて管理するマルチテナント運用」のように、各クライアントのデータをまとめているバケットなのかもしれません。
client-app-data (共有バケット)
├── [今回の赤いきつねゲームのフォルダ]/ <-- ここで動いてる
├── [A社のWebサイトのフォルダ]/
└── [B社のキャンペーンのフォルダ]/
案件ごとに毎回バケットを新しく作るのではなく、1つの汎用的なバケットを使いフォルダで区切る手法です。
権限管理(IAM)やデプロイの効率を考えると、実務的でかなり合理的な運用スタイルに見えます。
気になった方は是非赤いきつねを買って遊んでみてください！！
難易度高めでデザインも素敵なゲームでした！！
まとめ
- 赤いきつねのQRコードから遊べるミニゲームがあった
- URLを見ると、AWSのS3が使われていた
- 静的なミニゲームとS3の相性はかなり良さそう
- 独自ドメインを使わない構成も、QRコード経由なら合理的に見える
- 身近な商品にもAWSが使われていて面白い
赤いきつね美味しかった
みなさんも買って遊んでみてね！！
ごちそうさまでした！！
