はじめに：作成したアプリケーション概要
AWSのSAA資格を学習しており、その復習+定着のためにサーバーレスアプリケーションを合計6時間程かけて作成しました。
インフラの構成は以下の通りです。
現在の機能としては以下のシンプルなものです。
1. 朝と夕方の2パターンの体調や1日の予定を入力
2. 静的ウェブサイトとして、非同期通信を行いDBに入力結果を登録する
実際の動作はXのポストを御覧ください。
朝、夕方にそれぞれ入力できるように二パターンの入力をサポート
— Aizack (@ykokubo09) 2026年1月18日
それなりにちゃんと動いているのが嬉しい pic.twitter.com/QR9vrJD3z2
今回は上記アプリケーション作成背景と利用技術、その作成時の試行錯誤を振り返ります。
また、私同様AWSの学習している人に役立つアイデアや踏み抜いた失敗を糧にしていただけると幸いです。
開発の背景
毎朝の訓練報告が面倒
私が就業訓練を行っている事業所では、毎朝の開始前にSlackで体調と予定を以下のフォーマットで送付する決まりとなっています。
【確認事項】 ①体調: 絶好調/好調/普通/不調/絶不調 ③ルーティーン:できた/出来ていない ④面談が必要か？ ⑤通所/在宅 [学習予定内容]
はい。皆様が感じた通り「毎朝手打ちするのは非常に面倒」です。
そのため、入所すぐにGoogle FormとZaiperを利用してSlackにメッセージを送付する仕組みを構築していました。
訓練開始から約1年程改修をしながら稼働しています。
週3日から始まり、現在は週5日のためデータも溜まりはじめました。
また、朝だけでなく訓練終了時の体調も入力したいなどのアイデアを考えたときに現在の形では無理が出始めました。
分析や拡張性は検討せずに作成したので、作り直すという目的でAWSにアプリを載せようと検討し始めました。
AWSの学習の定着として
はじめに、でも記載したようにAWSの学習をしています。
昨年末からUdemyを中心にAWSの動画とハンズオンを行っており、特にかなざわ | Kei Kanazawa さんの「手を動かしながら2週間で学ぶ AWS 基本から応用まで」と「10日間で学ぶ サーバーレス on AWS」は大変お世話になりました。
それらの講座の中で「AWSを学ぶ上で良かったこと」として実際に何かを構築して運用すると仰っており、上記の検討タイミングと重なりました。
また、かなざわさんのブログの中でアーキテクチャパターンも紹介されていたため今回のアプリはそれを参考にしています。
AWS公式がだしているサーバーレスのアーキテクチャパターンも非常に参考になりました。
処理内容や目的別にアーキテクチャが複数紹介されていたので、サービス理解も進みます。
利用技術
今回の利用技術は以下の通りです。
- フロントエンド：HTMX
- ホスト先：S3
- CDN：CloudFront
- バックエンド：Python (Lambda)
- DB：DynamoDB
以下、技術選定の理由です。
1. HTMXという非同期通信ができるもの使ってみたい
2. DynamoDB使ってみたい
3. S3に静的ファイルを設置して、CloudFrontで配信するパターンはSAAの模試で見たのでやってみたい
以上です。
そして再度、構成図をはっておきます。
試行錯誤
はじめはS3の静的ホスティング機能を利用
HTMXのソースコードはGoogle Formの回答を集めたスプレッドシートからすぐにできました。
しかし、どうしても困ったのはDynamoDBの設計です。
なんせNoSQLの設計経験がないので、何もかもわかりません。一応、昨年夏にAzure DP-900を取得したので特徴は知っていますが、意味不明でした。
上記の状態から始まり、様々な資料やAWSの情報をもとに生成AIと喧々諤々と相談しながらテーブル設計を行いました。
「AWS完全に理解した」というヤツです。
なんとか3時間ほどで動く状態にはできたので嬉しいあまりXにポストしています。
記事はかけなかったけど、AWSDaCでシステム構成図は作成できた
— Aizack (@ykokubo09) 2026年1月16日
なんだか、それっぽいじゃないか https://t.co/jcBLfquZKr pic.twitter.com/4jbmkueNQ5
SSL化したいので、様々な検討
なんとか動く様になりましたが、一方で課題は山積です。人間の欲望に際限はありません。
- HTTP通信のままだと、なんかカッコ悪いしセキュアではない（SSL化したい）
- オリジナルドメインはかっこよいけど、自分用だからドメイン料金は払うつもりない
- 無料枠の範囲でAWSを学習したい
- 拡張を考えるとCognitoなどで認証して他のユーザーも使えるようにしたい
上記のような思いがムクムクと湧いてきます。
そこで無料枠内でSSL化する構成を検討し、SAA模試でよく聞かれる「S3にはパブリックアクセスさせたくないけど、CloudFrontで配信する」を採用しました。
利用する候補としてAmplifyも検討しましたが、今回はHTMLファイル1枚のフロントエンドかつ無料枠内ということで見送りです。
CloudFrontに設定したが、中々表示されない
ただ、CloudFrontに決めてからも紆余曲折ありました。人生そう甘くはありません。
うっかりや知識不足、様々な障害とぶつかりました。
- S3バケットをなぜか北米（オハイオ）に作成してしまっているため、バケットが見つからないAccess Deny
- クロスオリジン設定が抜けているためAccess Deny
- ビヘイビアに設定したLambdaにアクセスできないためAccess Deny
- CloudFrountのURLにアクセスするとAccess Deny
- /index.htmlにアクセスしないと表示されない（Default Root Object)
- 更新したのにキャッシュが残っていて動作が変わらない
散々です。「完全に理解した」とは到底言えない状態です。
もう何もわかりません。
それでも約3時間の格闘の後、冒頭のXの状態までたどり着きました。めでたしめでたし。
まとめ
今回の開発、アイデア出しから様々な部分で生成AI（Gemini）に相談しています。
そのためかなり開発時間は短縮、かつ学びの密度が高い時間になりました。
こういう新技術に挑戦する時の相棒、コーチとして生成AIはどんどん活用していけると楽しいですね。
本アプリケーションは今後API Gatewayを利用して複数のLambdaと連携、Cognitoを利用した認証、Slackへのメッセージ送信などを検討しつつ利用していこうと思っています。
AWS SAA模試が大変で逃げたくて開発したわけではないと言い逃れを残して最後の言葉にしたいと思います。
