
🟢 はじめに
💻 Java 会員制タスク管理アプリ


▼ 完成したアプリはこちら
これまでサーバーヘルプデスクやテスターとしてITサポート「後方支援」を担ってきた経験を活かし、現在はJavaエンジニアへのキャリアチェンジを目指して日々学習に取り組んでいます。
今回は、ローカル環境での開発から一歩踏み出し、
🔸Nginxの配置
🔸HTTPS化
までを自力で完遂し、
を本番公開しました。
この記事では、そのデプロイ奮闘記をお届けしたいと思います。
📝 なぜこのアプリを作ったのか?(開発の背景)
現在、Java Silver資格取得に向けて問題集(紫本)を周回中なのですが、
と思ったのが開発のきっかけです。
は世の中にたくさんありますが、毎日開くものだからこそ、無機質な画面ではなく、
と考えました。
そこで、Webクリエイターとしてのデザインスキルも活かし、UI全体を
で統一しています。
🛠️ 実装した主な機能
という実務的な視点を大切にし、以下の基本機能を実装しました。
🔹クエスト(タスク)のCRUD機能: 新しい学習タスクの「追加(Create)」、一覧の「表示(Read)」、内容の「編集・更新(Update)」、完了したタスクの「削除(Delete)」というWebアプリの基本となるデータ操作を網羅しています。
💻 アーキテクチャと技術スタック
今回の開発・インフラ構築で使用した主な技術は以下の通りです。
ただ機能を作るだけでなく、
にこだわりました。
🔸バックエンド: Java 17, Spring Boot
🔸セキュリティ: Spring Security (BCryptによるパスワード暗号化、CSRF対策)
🔸データベース: MySQL
🔸インフラ・サーバー: AWS (EC2), Nginx (リバースプロキシ)
🔸その他: Let's Encrypt (SSL証明書/HTTPS化), Git/GitHub, Visual Studio Code
🟦 Spring Security
今回、最も高くそびえ立った壁の一つでした。
特にローカル環境では気づけなかった
には苦戦しましたが、
ことで突破しました。
セキュリティの奥深さを痛感しました。
🟨 AWS (EC2)
まっさらなクラウド上にサーバーを建て、
を設定しました。
ローカル開発では意識しなかった
を学ぶことができました。
⚙️ Nginx
URLから
を隠し、
として導入しました。
🗝️ Let's Encrypt
ポートフォリオとしての信頼性を高めるため、SSL証明書を発行しHTTPS化を実施しました。
導入直後に404エラーが出た際はヒヤッとしましたが、
とログを見ながら原因を切り分け、ルーティングを追加して解決しました。
🛡️ 苦闘録①:AWSネットワークの壁と「アジャイルな決断」
🏰 【理想】プロの設計「WebとDBの分離」を目指して
インフラ構築を始めるにあたり、当初からAWSのベストプラクティスである
を目指していました。
システムを建物に例えるなら、
であり、
です。
セキュリティや今後の負荷分散を考えると、店舗の奥に金庫をそのまま置くのではなく、
のが、本番環境における最も正しい設計だと考えていたからです。
🧩 【壁】AWSネットワークという難解なパズル
しかし、ここでAWSの巨大な壁にぶつかりました。
を作るためには、
を使って
を正確に設定する必要があります。
しかし、見えないネットワークの設定はパズルのように複雑で、通信エラーが解消できませんでした。
さらに、RDSの設定画面では無意識のうちに
になっており、
という、
にも苦戦しました。
🏃♂️ 【決断】完璧な設計よりも「まずは動くものを世に出す」こと
ネットワークのエラー画面と睨み合う中で、
のではなく、
という決断を下しました。
サーバーヘルプデスクとして現場のシステムに関わってきた経験上、
ことのリスクを考えると、今の自分にとって最優先すべきは、
だと判断しました。
として捉え、まずは今の構成で無事にリリースを完遂し、今後のスキルアップの課題として、
と考えています。
🚫 苦闘録②:Spring Securityが放つ「403 / 404」エラー
⚠️ 「ローカルでは動いたのに!」突然のWhitelabel Error Page
インフラ側の設定を終え、ブラウザからアクセスした私を待っていたのは、無情にも表示された真っ白な
でした。
自分のPC(ローカル環境)では完璧に動いていたログイン画面が、AWSに乗せた途端に動かなくなる絶望感。
を全身で浴びた瞬間でした。
ここで、「エラーログの解読」と「原因の切り分け」を行いました。
🛡️ 403 Forbidden:本番環境に潜む「CSRFの罠」
最初に立ちはだかったのは、
です。

ログを追跡した結果、
ことが判明しました。
原因は
でした。
ですが、本番環境では、正規のフォームからの通信であっても「合言葉(トークン)」がないと弾かれてしまいます。
そこで、HTML側のフォーム内に
を追加しました。
ことで、この強固な門番を突破しました。
🌐 404 Not Found:HTTPS化成功と「コンシェルジュの不在」
次なる試練は、NginxとLet's Encryptを用いて「HTTPS化(通信の暗号化)」を完遂した直後に訪れました。
ターミナルに「Congratulations!」の文字が表示されたことを確認し、鍵マーク🔒のついたURLへアクセスしましたが、
というエラー画面が表示されました。

一瞬ヒヤッとしましたが、冷静に状況を切り分けてみました。
つまり、AWSの玄関(443番ドア)から受付係(Nginx)を通り、裏側のJavaアプリまでは『通信のバケツリレー』が成功している証拠だ。
原因はインフラ側ではなく、
だと分かりました。
そこで、
を追加しました。
このコンシェルジュの配属により、ユーザーをエラー画面で迷わせることなく、ログイン画面へ誘導できるようになりました。
✍️ おわりに:インフラ構築を通して得た学びと次なる目標
🌍 システム全体の「解像度」が高まったインフラ構築
単にプログラミング言語を書くだけでなく、
ことで、
その「解像度」が劇的に高まりました。
特に印象深かったのは、
です。
ここで想定以上に時間がかかり、最終的に
は悔しい経験でした。
しかし、
など、
は大きな収穫です。
単なる操作ミスではなく、クラウドの複雑な仕様に触れたからこその学びでした。
⚖️ 「理想の理解」と「アジャイルな決断」
RDSの構築は見送りましたが、
というベストプラクティスの意図は明確に理解できました。
🔹面倒なバックアップや更新をAWS側が自動で行う「マネージドサービスの恩恵」
🔹「負荷分散」によるシステムダウンの回避
「プロが現場で使っている安全な形」を再認識できたからこそ、
今回は
という、実務で不可欠なアジャイル思考を実践することができました。
🏁 次なる冒険:私だけの「オリジナル設計図」を描く
次なるステップとして、前職のヘルプデスク経験を活かし、
に着手したいと考えています。
実務経験からくる「こういう機能が必要だ」という生きた視点は、どんな教科書にも載っていない私だけのオリジナル設計図になると思います。
具体的には以下の技術に挑戦したいと考えています。
🖼️ 画像アップロード機能: トラブル解決の鍵となる「エラー画面のスクショ」を添付できる仕組み(MultipartFileの活用と、将来的なAWS S3連携)。
🔍 ステータス絞り込み検索: 必要な情報を瞬時に引き出すための、複雑なSQL(WHERE句の組み合わせ)を駆使した検索機能。
無機質になりがちな業務システムですが、
を目指したいと思います。
まずは、
と、
から、次のアプリ開発の構想を練っていきたいと思います。
最後までお読みいただき、ありがとうございました🙇♂️