AWSを「勉強」ではなく「毎日10秒の楽しみ」にした話（宝くじめくりサービス）
※この記事は「AWS を勉強しているけど、どう楽しんだら良いか分からない」方向けに、“好き”を起点に小さく作って学ぶ例をまとめたものです。
ギャンブル要素がある話題ですが、ここで伝えたいのは「宝くじのススメ」ではなく、学び方としての “趣味開発” のススメです。
当選ページを開く、あの一瞬を“体験”にしたい
宝くじって、当たるか外れるか以上に、結果を見る直前のドキドキが面白いと思っています。
でも、ナンバーズ4の当せん番号を確認する行為って、だいたいこうです。
- 当選ページを開く
- 4桁が一気に表示される
- はい終了
つまり、感情が動く前に終わる。
私はここに小さな違和感があって、こう思いました。
「当選ページを開く」という“作業”を、ほんの少しだけ“体験”にできないか？
IT用語で言うなら、これは UX（ユーザー体験） の話です。
「機能がある」だけではなくて、どう感じるかまで含めて設計する。
そして、そのヒントって意外と「遊び」の中にあります。
子どもの頃のガチャガチャ、カードをめくる瞬間、封を開けるときの手の感覚。
一気に見えないからこそ、期待が伸びる。
私はこの「遊びの原体験」こそが、体験づくりの材料だと思っています。
そして正直、こういう原体験は AIには代替できにくい とも感じています。
AIはそれっぽいアイデアや文章を生成できますが、
「自分がどこでワクワクしたか」「何でテンションが上がるか」みたいな感覚の芯は、結局その人の経験に紐づいているからです。
さらに、原体験ってデジタルよりもアナログなものが多い気がしています。
手触り、重さ、音、匂い、間（ま）。
そういう“物理の情報”が、記憶に残る体験を作っている。
だから私は、デジタルでUXを作るときほど、アナログの原体験を参照するとヒントが出ると思っています。
コンセプトはこれです。
宝くじの結果を確認する作業を、もう少しだけ、10秒だけドキドキする体験にする
先に結論：AWSは「作りながら」だと楽しくなる
AWSって、サービス数も多くて、正面から「勉強」しようとすると息切れしがちです。
私が最近やっているのは、こういうスタイルです。
- 好きなテーマを決める（宝くじ）
- 小さな“体験”を作る（めくる）
- まず動いたらOK（ここがゴール）
- その上で、気持ちが乗る日は 「毎日コードや設計を改善しよう」 という気持ちで触ってみる
- でも 改善は義務にしない
- やる気がない日は、別のことをする（仕事ではないので）
「毎日改善しなきゃ」と決めると、私の場合は趣味が“課題”になって続きません。
だから、基本は 動いたらOK。改善は やりたくなった時にやる。
それでも結果的にAWSは触るし、少しずつ分かることが増えていきます。
AWSが “資格勉強” ではなく、“作品づくりの道具” になってくる感覚がありました。
作ったもの：宝くじめくりサービス（ナンバーズ4を1桁ずつ開ける）
作ったのは、ナンバーズ4の当せん番号を 1桁ずつ表示（めくる） できるサービスです。
- 最新の当せん番号（4桁）を取得
- ただし、画面には「????」で隠す
- 好きな桁から “表示” ボタンで 1桁ずつめくれる
- たった 10秒だけ ドキドキが増える
ポイントは「情報を隠す」ことではなく、感情が動く“間”を作ることです。
一気に見せない。それだけで、当選ページを開く瞬間が少しだけ楽しくなります。
ナンバーズ4ってなに？（知らない人向け）
ナンバーズ4はざっくり言うと、
- 0000〜9999 の 4桁を選ぶ宝くじ
- 抽せん結果と一致すれば当せん
- 申込タイプ（ストレート/ボックス等）がある
- 月〜金に抽せんがある
…という仕組みです。
構成：シンプルに「フロント」「バック」「データ取得」
細かい話は置いて、考え方はこれだけです。
- 画面（フロントエンド）：ユーザーが「めくる」を押す場所
- 処理（バックエンド）：当せん番号を取りに行って、整形して返す
- データ元：当せん番号が分かる情報源
私はこの分割で、AWSのサービス を “道具箱みたいなもの” として触りました。
生成AIで開発してみて感じたこと（正直）
私はプロンプトでコードを生成しながら作りました。
やってみて思ったのはこれです。
- 生成AIで「とりあえず動くもの」は本当に早い
- でも “生成されたコードを理解して、直して、品質を守る” は別物
- だから私は、生成されたコードをそのまま信じるのではなく
「生成コードを読んで、分からないところがあれば調べる」 を意識しました
結果的に、楽しめました。
逆に、生成されたコードを責任を持ってレビューする力を付けるのは難しい（ここは今の課題）とも感じています。
AIに代替されない最後の砦は「責任を取ること」
特になぜその意思決定をしたのかを、関係者全員が納得できるように「説明する責任」
最近、参加した勉強会で強く刺さった言葉です。
AWSの理解が進んだ本（オンプレの知識と繋がった）
途中でかなり助けられたのがこの本です。
-
『Amazon Web Services 基礎からのネットワーク＆サーバー構築［改訂4版］』
https://www.amazon.co.jp/dp/4296202049
オンプレ（L2/L3、ルータ・スイッチ）を業務で軽く触ってた経験とAWSが、
「あ、同じことを別の形でやってるだけだ」と腹落ちしました。
昔やってたこと、ちゃんと役に立ちます。
スクレイピングの話：グレーなので、収益化するなら別ルートにする
このサービスは当初、当せん番号の取得に スクレイピング的な手法 が入っていました。
ここは誤解されやすいので、正直に書きます。
- 法律面・規約面は状況次第で変わるので、軽く扱うべきではない
- そして「やっていい」と断言できる話でもない（グレー）
一方で、私が確認した範囲では、利用規約本文に 「スクレイピング禁止」 が明確に書かれていないケースもありました。
ただし、書いてない＝OK ではなく、
- サイト全体の利用規約
- robots.txt
- サーバー負荷
- データの二次利用・転載
など別の観点でNGになり得ます。
なので私は、収益化＆一般リリースするならスクレイピングしない実装に切り替える方針です。
スクレイピングしない実装案：当選メールの内容から取得する（SES）
私が今検討している「スクレイピングしない方法」は、当選通知メール（当選メール）の本文から当選番号を取得するやり方です。
AWS だと、SES（Amazon Simple Email Service） を使うことで実現できます。
イメージとしてはこんな流れです。
- 当選メールを SESで受信（Inbound）
- 受信メールを S3 に保存（または Lambda に渡す）
- Lambdaで本文をパースして当選番号を抽出
- フロントに返す（またはDBに保存して参照）
この方法なら、Webページを取りに行くのではなく 自分が受け取ったメールを材料にするので、設計としても納得感が高いです。
※ただし、メールは個人情報や機微情報が入りやすいので、
- 保存期間
- 暗号化（S3/KMSなど）
- アクセス権限（最小権限）
- ログの取り扱い
はちゃんと設計する必要があります。
体験を作るってどういうこと？：UXの種は「遊びの原体験」にある
今回のサービスは「宝くじ×AWS」ですが、私が本当に作りたかったのは
“宝くじを見る体験” そのものです。
- 情報をどう見せるか
- どの順番で見せるか
- 触ったときにどう感じるか
これは全部、UXの領域です。
そして私は、UXのヒントは 遊びの原体験に隠れている気がしています。
- 一気に見えないから楽しい
- ちょっと手間があるから期待が伸びる
- 自分の操作で結果が“開く”感じがする
こういう感覚って、生成AIが「それっぽい案」を出すことはできても、
どれが自分に刺さるのかは、結局自分の原体験が決めると思います。
そして、その原体験はデジタルよりもアナログ寄りなことが多い。
だから私は、デジタルでUXを作るときほど、アナログの記憶を掘るのが効くと思っています。
原体験を掘ることは、AI時代にむしろ価値が上がる行為だと思っています。
「アイデアはパクられない？」への私の答え（むしろ応援して参画したい）
個人開発でアイデアの話をすると、たまに聞かれます。
「それ、パクられないの？」
私は、正直 パクられてもいい と思っています。
というか、もし誰かがこれをパクって本気で伸ばし始めたら、私はたぶんこうします。
- パクった人を全力で応援する
- できるなら そのプロジェクトにも参画する
これ、私の中ではわりと自然で、
「作る」って、別に一人で抱え続けることだけが創作ではなくて、
誰かが続きを作ってくれて、そこに乗ったり混ざったりしていくのも創作だと思っています。
もちろん、何でもかんでもOKという話ではなくて、
悪意のあるコピーや不誠実な振る舞いは別です。
ただ、ちゃんと良くしていく方向の“引用”や“発展”なら、私はむしろ嬉しい。
- 作る と 流行らせる は別の領域
- 継続的に使ってもらう も別の領域
もし誰かがそれをやり切って流行らせたなら、それはその人の実力。
そして私は、その熱量に乗って一緒に作れたら、それもまた面白いと思っています。
まとめ：AWSは「学ぶ」より「遊ぶ」から入るのが強い
AWSを楽しめないときって、だいたい
- 目的がない
- 手触りがない
- 成果が遠い
のどれかです。
だから私は、
- 趣味（好きなテーマ）を選んで
- 10秒でもいいから体験を作って
- 動いたらOKで終わってもいいし
- やる気が出た日に「毎日コードや設計を改善しよう」の気持ちで触ってみる
このやり方をおすすめしたいです。
もし「AWS、何から触ればいいか分からない…」という人がいたら、
まずは “小さな遊び” を AWS の上で動かす ところから始めてみませんか。
関連書籍（気になって読んでいる本）
- 宝くじの文化史：ギャンブルが変えた世界史 — くじ（宝くじ）が社会や歴史に与えた影響をたどる一冊。
- 玩具の系譜（玩具叢書 第2巻） — 玩具の歴史や文化的背景を整理して学べる研究書。