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巻） — 玩具の歴史や文化的背景を整理して学べる研究書。