【ハンズオン前編】初心者がAmazon Q Devと1から進めるサーバレスApp開発(フロントエンド編)

記事タイトルとURLをコピーする

垣見です。
前後編ハンズオンのうちフロントエンド編(React×TypeScript)です。

アプリを作る」という言葉に、「何から始めたらいいのかわからない」「コードなんて書けない」と敷居が高く感じている人向けのブログです。

このブログでは、AWS上のサーバレス構成で動くWebアプリを、最初の始め方からバックエンドの作り方まで初心者向けに丁寧に解説します。

コードが分からなくても、AWSが分からなくても大丈夫です。一つずつ説明していきます。

後編(バックエンド編)公開しました blog.serverworks.co.jp

はじめに

AWSではANGEL Dojoという長期ハッカソンイベントがあります。

aws.amazon.com

これは3か月間という期間で新たなアプリケーションを開発するコンテストで、2025年は「ユーザー企業(事業会社)とAWSパートナー企業(事業会社相手にAWSについて技術支援を行っている企業、弊社も該当)でチームを組んで、ユーザー企業の課題を解決するようなソリューションを開発する」というテーマでした。

今年のコンセプトとして「ユーザー企業による内製化促進の重要性」について強く触れられており、チームによっては「ユーザー企業側にエンジニアが全くいない」ということもありました。
そのため、「開発と言われてもどこから始めればよいのだろう」という悩みはつきものだったかと思います。

たとえ知見のあるパートナー企業と組んでも、全体の見通しが立たない状態では今何をしているのかの理解も難しく、計画しつつ不安でいっぱいなのではないでしょうか?

かくいう私も、当初は「AWSの環境統制・セキュリティ関連のサービスには知見があるものの、アプリ開発の経験はほとんどない」という状態でした。ANGEL Dojoを通して色々なことを学んだので、次回参加者のためにも知見を残しておこうと思います。

当初の私と同じくANGEL Dojoで何もわからなくて困っている方や、AWSは多少わかるけどアプリをどう作るのか?と思っている方の助けに慣れれば幸いです。

今回作るもの

今回は、日々のちょっとした「できたこと」を記録して、自己肯定感を高めるためのWebアプリを作ってみましょう。 機能はとてもシンプルで、以下の2つです。

  1. 今日「できたこと」をテキストで入力し、登録できる
  2. これまで登録した「できたこと」の一覧を閲覧できる

「なんだ、それだけ?」と思うかもしれませんが、このシンプルな機能の中に、Webアプリの基本となるデータの登録(書き込み)データの取得(読み込み)、また、「AWS Lambdaを使ってAWSサービスを操作する方法」という非常に重要な要素が詰まっています。

ここをマスターすれば様々なアプリに応用が利くようになるので、是非気になるところから見てみてください。
また、このブログは汎用性を意識して書いています。皆さんは上記記載のアプリを一緒に作っても良いですし、オリジナリティのあるアプリを作るための参考としても大丈夫です。その場合は都度読み替えていただければと思います。

こんなものを作ります

構成図

ブログで説明すること・しないこと

このブログは、アプリ開発の概要をつかみ、最初の一歩を踏み出すことを目的としています。そのため、以下の内容は説明の対象外とします。

  • gitについて: ソースコードのバージョン管理ツールですが、今回は触れません。(ANGEL Dojoのチーム開発では間違いなく使うのですが、それを説明するとブログの文字数が2倍になってしまうので割愛します。余裕があればまたの機会に。)
  • VSCode以外の開発者向けツールを使った実施方法: 開発者がコーディングする際によく使われるツール(コードエディタ・IDE(統合開発環境)など)にはいくつかありますが、今回はVSCodeの利用を前提に説明を進めます。
  • 技術選定について: それぞれの技術スタック(Reactなどの言語, DynamoDBなど)について、概要はある程度説明します。しかし、なぜ他の選択肢と比較してこの技術スタックを選んだのか、についての詳細な比較検討は行いません。まずは代表的な構成で動くものを作ることを優先します。
  • コードの細かい意味: 構文やロジックについても細かい解説はしません。「Q Developerに指示を出して動くものを作る」という流れをメインで説明します。

全体の流れ

このブログでは、以下のステップでアプリを開発していきます。

【前編】

  1. Amazon Q Developerの準備: まずは、私たちの代わりにコードを書いてくれるAIアシスタントを使えるようにします。
  2. フロントエンド(見た目)の作成: ユーザーが実際に操作する画面を、Amazon Q Developerに作ってもらいます。
  3. S3静的ウェブサイトホスティング設定: ユーザーの作った画面をS3において、ウェブサイトとして見られるようにします。

【後編】

  1. バックエンド(裏側の仕組み)の作成:
    • DynamoDB (データベース) の用意: 記録した「できたこと」を保存しておくための箱を作ります。
    • Lambda (機能) の用意: データを保存したり、取り出したりする具体的な処理を担当するプログラムを作ります。
    • API Gateway (窓口) の用意: フロントエンドからの「このデータを保存して!」「データの一覧をちょうだい!」というお願いを受け付ける窓口を作ります。
  2. フロントエンドとバックエンドの接続: 作った見た目と裏側の仕組みを繋ぎこんで、アプリを完成させます。

専門用語が出てきましたが、それぞれのステップで詳しく解説するので安心してくださいね。

【座学】Amazon Q Developerについて

Amazon Q Developerとは・メリット

Amazon Q Developerは、AWSが提供するAI開発アシスタントです。
「やりたいことを日本語で伝えると、その通りのコードを書いたり、コードを読んでアドバイスをしたり」してくれます。

未経験者が開発に挑戦しにくい理由として、「そもそも何を書けばいいかわからない」「エラーが出たけど、どこをどう直せばいいかわからない」という点があると思います。 Amazon Q Developerは、そういった悩みを解決してくれます。夢のようですね。

機能をまとめるとこんな感じです。

  • コードの自動生成: 「こういう機能が欲しい」と伝えるだけで、プログラムを生成してくれます。
  • コードの説明: 既存のコードが何をしているのか、分かりやすく解説してくれます。
  • エラーの修正: エラーメッセージを貼り付けると、原因と解決策を教えてくれます。

これを使えば、コードを一行も書いたことがない人でも、アプリ、特にフロントエンド側の開発を進めることができると思います。本当です。

Amazon Q Developerを使えるようにする

VSCodeを使っている方のインストール方法は以下をお試しください。BuilderIDを使ったfree版でも、使用上限はありますがしばらくは問題なく使えます。   なお、現在は日本語に対応しているほか、UIもブログ記載時よりアップデートされております。実際の使い方は後述するので、まずはインストールとログインだけできればOKです。 blog.serverworks.co.jp

VSCodeではない場合やCLIでterminalやコード内でのやり取りをしたい場合、以下をご参照ください。(今回は扱いません) blog.serverworks.co.jp

【実践】開発準備をしよう

【実践】Qのruleファイルを作り、開発者間での齟齬や手戻りをなくす

まず、開発を始める前に /q-rules.md というファイルを作成し、プロジェクトのルールを定義しておくことをお勧めします。
なぜなら、最初にルールを決めておくことで、Amazon Qが生成するコードの品質やスタイルが統一され、後々の手戻りや修正作業を大幅に減らすことができるからです。

▼ルールは「.amazonq/rules」というディレクトリ配下にmd形式のファイルを作ること接敵できます。

docs.aws.amazon.com

これは一人で開発する場合でも有効です。例えば、何度も何度も同じように「日本語で返答して」「このサービスは~をするサービスです。」と指示をすることが減ります。

またその際に、「バックエンドはAWSのサーバレス構成(Lambda、S3、API Gateway、DynamoDB)で開発する」のように、Qがコードを見て一目で理解しないことで、コードの質や方向性に影響する情報も入れておくと良いです。 また、「○○(例:AWS、開発、IT)の初心者にもわかる用にコメントを充実させ、ドキュメントを作るようにしてください」のような指示もお勧めです。

コピペOKなおすすめルールの例:

# プロジェクトルール
## 言語設定
- 常に日本語で返答してください

## プロジェクト固有ルール
- このプロジェクトは「できたことログ」という製品を開発するプロジェクトです
- あなたはAWSと各種言語のベストプラクティスに則り、セキュリティと利便性を兼ね備えたアプリケーションを開発します。もしもユーザーの指示がベストプラクティスに対して適切でない場合は、必ず確認を取ります。

### プロダクトコンセプト
- このプロダクトは、20代〜30代の働く女性向けの、日々の達成感を記録し自己肯定感を高めるためのサービスです。パステルカラーを基調とした、優しく、ミニマルでモダンなデザインを心がけてください。
- ブランドカラーとしてはエメラルドグリーンとイエローを使用してください。

### 技術
- フロントエンド:ReactとTypeScript
- バックエンド:AWS。言語はPython
- AWSのサーバレス構成(S3フロントエンドホスティング、API Gateway、Lambda、DynamoDB)

### コーディングルール
- 複数人での開発を念頭に、コードには日本語のコメントを丁寧につけ、ドキュメントも充実させてください。それらは開発の初心者にもわかるような易しいものにしてください。 

イメージ

【座学】Reactとは?

ここで、今回フロントエンドで使用するReactについて少しだけ説明します。

react.dev

古典的なフロントエンドの言語、 皆さんはご存知でしょうか?

HTMLが文字情報、CSSが色や配置などのスタイル情報、そしてJavaScriptは「いいねボタンを押したらカウントが増える」「入力フォームをチェックする」「5秒経ったらA画面がB画面に遷移する」など、機能を付ける部分ですね。

Reactは、この「JavaScriptのライブラリ(便利な道具セット)」で、Webサイトの見た目(UI: ユーザーインターフェース)を効率的に作るために役立ちます。

基本的にはJavaScript(TypeScript)で記述していきますが、その書き方のルールをフレームワークとして定めることで、より簡単に・より軽量に・よく動く画面を作ることが出来ます。

具体的には以下のような特徴を持ちます…が、今は理解しなくてもOKです。
開発初心者の段階では、まずはQに作ってもらってからそのわからないところを聞いて理解したりしていく方が早いと思います。

  • 上からひとつひとつすべて記述するのではなく、「ヘッダーの部品」「投稿本体を表示する部品」「投稿へのコメントを表示する部品」のように、1つの画面でもあらかじめ分けて作った複数のパーツ(コンポーネント)を組み合わせて作ります。コードが見やすく、開発効率が良いです。
  • ひとつひとつ状態ごとの画面操作を都度記述するのではなく、変数の状態と「それがどんなスタイルを持つか」を紐づけ、状態が変わる操作のみ記述すればよいです。(「宣言的なUI」といいます。)変更時に画面全体の更新が不要なので軽いです。

今回はこのReactと、TypeScript(JavaScriptの型定義がしっかりしているバージョンで、バグに気付きやすい)を使って進めていきます。

興味がある人用の「宣言的」UIについて ①まず、以下のようにconstuseState(初期値)を使って、「変数」と「その変数を更新するための関数」をセットで設定しておきます。 以下はいろいろな例です。

// const [変数, 変数の更新方法] = useState(初期データ)
const [textColor, setTextColor] = useState('black');  //文字の色
const [count, setCount] = useState(0);  //カウンターの数値
const [inputValue, setInputValue] = useState('');  //フォームの入力内容
const [isOpen, setIsOpen] = useState(false);  //表示/非表示の状態

②次に、①で設定した変数を使って、htmlの要素にJavaScriptについてのルール定義をしておきます。 const [textColor, setTextColor] = useState('black');をしたと仮定して、ただのHTML+CSSの書き方にtextColorの状態が反映されるようにします。 この場合初期値はblackなので、画面に映る文字列。このテキストの色は「 textColor」の状態によって変わるという文字色は黒になります。

return (
  <p style={{ color: textColor }}>
    画面に映る文字列。このテキストの色は「 textColor」の状態によって変わる
  </p>
);

③最後に、①で設定した「変数を更新するための関数」を呼び出して変数を変更します。直接変数(ここではtextColor)に値を代入しないのがポイントです。 以下はHTMLの<button>タグにonClick={...}(クリック時の挙動を指定する書き方)を付け、その挙動として「setTextColorが'red'になる」と指定しています。

これにより、ボタンをクリックすると状態がsetTextColor関数がred状態になります。

<button onClick={() => setTextColor('red')}>
  色を赤にする
</button>

①~③により、実際に以下のような流れで動きます。

  1. ユーザーがボタンをクリックします。 (onClick)
  2. 関数setTextColor('red')が実行され、textColor変数の状態が'red'に更新されます。
  3. 状態が変わったことを検知したReactが、画面を再描画します。
  4. 再描画の際、<p>タグの中身は「textColorの値と同じ色になる」というルールに従い、文字色が赤に変わります。

全体を作り直すのではなく、「ある一部の再描画」という扱いになるので、Reactを使わない書き方よりも軽量になりやすいです。 また、「見た目の色が変わっていれば状態もそれに変わっている」という特性があるので、「見た目はオンなのに何も起こっていない」ようなバグも起きにくくシンプルになります。

【実践】フロントエンド開発の準備

ViteでReactプロジェクトの骨組みを作る

まず、開発を始めるための土台となるReactプロジェクトを作成します。今回は、現在主流となっているVite(ヴィート) という高速なツールを使います。

Ctrl + @でVSCodeのターミナルを開き、プロジェクトを作りたいディレクトリ(例: serverless-blog/project)に移動します。

cd project/

移動したら、以下のコマンドを実行してください。

# 「frontend」という名前で、React×TypeScriptのプロジェクトを作成します
npm create vite@latest frontend -- --template react-ts

※以下のように出てきたらNoのままエンターを押してください。(お試し版の機能のため)

Use rolldown-vite (Experimental)?:
│  ○ Yes
│  ● No

以下はYesを押してください。 (開発用のパッケージを自動でインストールし、開発サーバを起動していいか?と聞かれています。後述のnpm installnpm run devを実行する意味があります。Noでも後で実行すればいいので問題は起きません。)

Install with npm and start now?
│  ● Yes / ○ No

しばらくローディング画面が出た後、以下のような画面になっていれば成功です。

  VITE v7.1.10  ready in 911 ms

  ➜  Local:   http://localhost:5173/
  ➜  Network: use --host to expose
  ➜  press h + enter to show help

コマンド成功後、frontendというディレクトリが作成され、その中にReactアプリを動かすための最小限のファイル群が自動で生成されます。これがいわば、家の「土台と骨組み」です。

何もなかった/frontend配下に基礎の枠組みができています。.gitignoreファイルやREADME.mdファイルなども自動でできているのがわかります。

ターミナルに表示された1行目のLocal の後ろにあるURLを開く(Ctrl + クリック)すると、ローカルサーバー上でViteによるReact初期画面が出てきます。

中央のCount is ボタンをクリックするとカウントが増えます

ターミナルでCtrl + Cを押せばローカルサーバーは終了します。もう一度開きたいときはfrontend/配下に移動したのち、npm run devをターミナルで実行すればよいです。

Qにディレクトリ構造を整えてもらう

Viteが作ってくれた骨組みを、よりチーム開発しやすいように整えてもらいましょう。 今度は、作成されたfrontendディレクトリをVSCodeで開き、Amazon Qに以下のように指示を出します。

Qへの指示例↓(大規模な改変を伴う指示の前にはいったん計画書を出させるのがおすすめです)

`project/frontend` ディレクトリは、Viteで作成したReact×TypeScriptのプロジェクトです。
この構成をベースに、チーム開発のベストプラクティスに従って、より分かりやすいディレクトリ構造にリファクタリング(再構成)してください。
まずは、`project/docs`配下に案のマークダウンファイルを出力してください。

CSSの分け方などはベストプラクティスに従ってください。

お好みで以下のような文言もいいかもしれません。(実際の採用可否はチームで相談してください。)

チーム開発を行うので、コンフリクトが起きないように工夫した構造にしてください。

ディレクトリがない場合はmkdirコマンドを実行するか許可を求められます。問題ないことを確認し、runを押せば実行されます。

こんな感じで、mdファイルに出力できました。説明もきちんと書かれており、読むと勉強になります。

計画案を見て、気になるところは自然言語でQに質問してみてください。(※Qは便利ですが、全て完璧なコードを作ってくれる万能神ではないです。要件に合わない部分があったら直してもらいましょう。)

良さそうだったら実際にディレクトリ構造を作ってもらいます。 計画書は整形してREADMEや作業ログにしても良いと思います。

では、この計画書をもとにディレクトリ構造を作ってください。

右エディタを見ると、左の計画書の「現在の構成」と比べてきちんと更新されています。

ディレクトリ構造を整えることによってファイルがどこにあるのか分かりやすくなり、コンフリクト(複数人での作業時に起こるコードの衝突)が減ったり、他のメンバーが作ったコードを理解しやすくなったりします。

また、修正する場合にもこのファイルを手動で修正し、「このファイル(project/docs/filepath)に従って~~を実施して」と言えるのも強みだと思います。

ドキュメントを充実させるのも大事です。各ディレクトリがどんな役割を持つのか、README.mdファイルを作成して説明を書いてもらうと、より親切になります。

実際に今年のチームでは以下のような反省が出ていました。以下ブログはQ Developerを使ったチーム開発時にお勧めなので、本ブログを見た後改めて読むのがおすすめです!

blog.serverworks.co.jp

ちなみに上記プロンプトでは細かい指示をしなかったため、Qが「気を利かせて」viteのデフォルトページを削除し、シンプルな「Welcome to Our Blog」だけのページに変えてしまっています。
今回はどちらにしてもデフォルト値を削除する予定だったので問題ないですが、このように指示外のことをくみ取ってくれる便利機能のせいで想定外も起こります。プロンプトエンジニアリング、一緒に頑張りましょう。

※mdファイルにはディレクトリ構成の計画しか書いていませんでした

こうなった

質問すると答えてくれるが…

【座学】フロントエンド編

フロントエンドとは?(ユーザーが見る画面)

ここからは、いよいよフロントエンド、つまりユーザーがブラウザで直接見て、触る部分の開発に入ります。
Webサイトのレイアウトや色、ボタンやテキストなど、画面に表示されるものすべてがフロントエンドです。

重要な点として、この段階ではまだ裏側の仕組み(バックエンド)がありません。そのため、これから作るのは「静的な(Static)」なページです。
これは、いつ、誰が見ても、全く同じ内容が表示されるという意味です。
例えば「今日の記録」という文字をコードに書けば、Aさんが見てもBさんが見ても、全く同じ「今日の記録」という文字が表示されます。

では、バックエンドがまだ無い状況で、どうやって効率的に開発を進めるのでしょうか?

モックデータを使い、フロントエンド側だけのプロトタイプを作ってみよう

今回はモックデータを使ったプロトタイプを先に作ります。

表示するデータはフロントエンド側のコード内にファイル(モックデータ)として持たせ、見た目を作っていきます。 そして、後の工程でAWS上のバックエンドと接続し、そこから送られてくる「動的な(Dynamic)」データに差し替えることで、ユーザーごと、あるいは時間ごとに違う内容を表示するアプリへと進化させていきます。

いきなり全ての機能を作り始めるのは大変ですが、先に見た目だけを作ることで、以下のようなメリットがあります。

  • 完成イメージが具体的になる: どんなアプリになるのか視覚的にわかるので、モチベーションが上がります。
  • 手戻りが少なくなる: 先に見た目を確認することで、「やっぱりここのボタンは大きい方がいい」といった修正が早い段階でできます。
  • 役割分担がしやすくなる: チーム開発の場合、一人がフロントエンドを作っている間に、別の人が裏側の仕組み(バックエンド)を作り始めることができます。

なお、「モックアップ」、「プロトタイプ」、「モック(モックサーバー・モックデータ)」は違う意味ですのでご注意ください。

用語 概要 見た目 動き(操作感) 目的 主な作り手 / ツール
モックアップ
(Mockup)
見た目の「完成予想図」 静的なビジュアル 動かない デザインの合意形成、見た目の確認 デザイナー
(Figma, Sketch)
プロトタイプ
(Prototype)
操作できる「試作品」 動的なビジュアル 動く 操作感(UX)の確認、画面遷移の検証 フロントエンドエンジニア、デザイナー
(React, Figma)
モック
(Mock)
機能の「身代わり」 基本的に無い 機能として動く 未完成な機能(API等)の代替、並行開発の実現 フロントエンド / バックエンドエンジニア
(MSW, Postman)

【実践】フロントエンドの画面を作ろう

Qに指示を出して画面を作らせよう

それでは、早速Amazon Qに画面を作ってもらいましょう。VSCodeでAmazon Qのチャット画面を開き、以下のような指示(プロンプト)を送ってみます。

まずは計画書を出してもらいましょう。(お好みで、最初から作ってもらってもいいです。) 以下のようにお願いしてみます。

React(TypeScript)で、これから作る「できたことログ」アプリのトップページを作成したいです。まずは以下の指示を読んで、project/docsディレクトリ内に、どんなものを作るのかをまとめた定義用のmdファイルを作成してください。

このアプリは日々のちょっとした「できたこと」を記録して、自己肯定感を高めるためのWebアプリです。

機能は以下の2つです。

1.  今日「できたこと」をテキストで入力し、登録できる
2.  これまで登録した「できたこと」と「日付」の一覧を閲覧できる

要件は以下です。
- ヘッダーにはアプリのタイトル「できたことログ」を表示します。
- メインコンテンツ部分に、テキスト入力欄と「記録する」ボタンを設置してください。
- その下に、登録された「できたこと」が一覧で表示されるエリアを設けてください。
- バックエンドは、あとでAWS上のAPIとつなぎます。今はモックデータを適切なディレクトリ内に格納しておいてください。
- ディレクトリ構造は先ほど作成したものを利用し、もし新しいディレクトリが出来たらproject/docus/frontend-directory-structure.md を更新してください。
- デザインは、ルールファイルで定義したコンセプトに従ってください。

achievement-log-app-specification.mdファイルが出来ました。 レイアウトのイメージやデザインコンセプト、ターゲットユーザーなどをまとめてくれています。 こういったファイルを作っておくと、後々Qのセッションが切れたときに参照させたり、そのままgitのプルリクエストの参考にできたりするので便利です。

こんな感じ。

ちなみにそういったTipsは以下のブログが勉強になります。(先輩と同じ結論にたどり着いていて嬉しくなりました)

blog.serverworks.co.jp

ついでにモックデータやバックエンドの仕様まで書いてくれていますね。命令文を変えればこういった部分や実装手順、進捗までしっかり出してくれるようになるので最高です

次の指示です。

では、project/docus/achievement-log-app-specification.md に則り、実際にアプリを作成してください。

すると、Qがコードの生成を始めてくれます。

Qが実行した変更はチャットログから確認できます。

左が元のコード。色付きの行が変更or削除or追加された場所

取り消し(Undo)も可能です。意図しない変更があった場合、Qに自然言語で変更依頼を出すよりも、一旦Undoをしてからその旨を伝えて再生成させたほうがミスが減る印象です。

おっと、次のセクションでやりたいことをQが読み取ってやってくれていますね。では次の章です。

ローカル環境からアクセスする

生成されたコードが実際にどう見えるか、自分のPC上で確認してみましょう。 VSCodeのターミナルをCtrl + @で開き、現在のReactアプリがあるディレクトリ(今回の例だと/frontend)まで移動します。

cd project/frontend

以下のコマンドを実行します。
viteによるReact開始時にnpm installをしていない人はそちらを先に実行してください。

npm run dev

npm install は、Reactアプリを動かすのに必要な部品(ライブラリ)を集めてくるコマンドです。基本的に、プロジェクトの最初に1回だけ実行すればOKです。
プロジェクトのルートにあるpackage.jsonファイルを探し、その中の"dependencies"と"devDependencies"といういうリストで指定されたライブラリをインストールしてきます。

実行すると、node_modulesフォルダの中にダウンロードされたパッケージがおかれます。 最後に、「実際に何のどのバージョンのパッケージをダウンロードしたのか」という情報をpackage-lock.jsonファイルに記述されます。

npm run dev を実行すると、Viteによる高速な開発用サーバーが起動します。
これは、あなたの開発用パソコン(ローカル環境)だけで立ち上がっている環境です。他の人は見ることが出来ませんが、「実際にこのコードを実行するとこうなるよ」という画面を見せてくれています。

ターミナルに http://localhost:5173/ のようなアドレスが表示されたら、それをWebブラウザで開きます。そこに、Qが作ってくれた画面が表示されていれば成功です!

こんな感じ。追加したデータはブラウザ上の保持なので更新すると消えます。

基本画面
投稿も可能だが、追加したデータはブラウザ上の保持なので更新すると消える

もしエラーが起きたら

エラーが出ていたら、エラー文やエラーが起きた状況をQに教えて、どうすればよいか尋ねてみてください。

トラブルシューティングと修正を行ってくれるはずです。

エラー調査イメージ。ブラウザ開発者モードの使い方も教えてもらうと良いです。

Qにさらに指示を出して、画面を好きなように変えてみよう

見えた画面で、色やパーツの大きさ、エフェクトなどを自由に変えてみましょう。

例:

投稿したときに、cssアニメーションで弾けるエフェクトが飛ぶようにしてください。
「記録する」ボタンの中央から出るようにしてください。8方向に飛び散ってください。
「記録する」ボタンにカーソルを載せたとき、沈むようなアニメーションを付けてください。ボタンは押せるように影を付けてください。

ボタンの影、カーソルを当てたときの動き、押した時のエフェクトを追加

S3に置いてみる

ローカル環境で動いた見た目(モック)を、インターネット上に公開してみましょう。AWSのS3というサービスを使うと、Webサイトを簡単に公開できます。

大まかな流れは以下の通りです。

  1. ローカルのReactプロジェクトを、公開用に変換(ビルド)する。
  2. AWSの管理画面(マネジメントコンソール)でS3バケットを作成し、「静的ウェブサイトホスティング」を有効にする。
  3. ビルドして生成されたファイルを、S3バケットにアップロードする。

これで、世界中のどこからでもアクセスできるURLが手に入ります。まだ見た目だけですが、大きな一歩です。

※【注意】本番環境でのセキュリティについて

この方法(S3の静的ウェブサイトホスティングを直接公開する)は、Webサイト公開の仕組みを学ぶためのシンプルなファーストステップとしてご紹介しています。

しかし、実際の業務(本番環境)では、この方法だけではセキュリティ上の懸念があります。一番の理由は、通信が暗号化されないHTTPでの公開になってしまうことです。

現代のWebサイトでは、通信を暗号化するHTTPSでの公開が必須です。AWSでこれを実現するには、Amazon CloudFrontというサービスをS3の前に設置するのが一般的です。

構成のイメージ:

  1. S3バケット:Webサイトのファイル置き場。バケット自体は非公開に設定。
  2. CloudFront:ユーザーからのアクセスを受け付ける窓口。
    • 無料でHTTPS通信を提供。
    • 世界中の拠点にWebサイトのコピーを配置(キャッシュ)し、ユーザーに高速で表示。
    • S3バケットにはCloudFrontだけがアクセスできるように設定し、セキュリティを確保。

まずはS3だけで公開して「最低限の要素」を理解していただき、その後はCloudfront、さらにセキュリティを高めたければAWS WAF等をご検討いただければ幸いです。

ステップ1:ローカルのReactプロジェクトから本番環境用のファイルを生成する(ビルド)

まず、開発したReactアプリケーションをWebサーバーにデプロイできる形式に変換します。このプロセスを「ビルド」と呼びます。

ビルドを実行すると、ソースコード(TypeScript, JSXなど)がブラウザで解釈可能な静的なHTML、CSS、JavaScriptファイルに変換されます。同時に、コードの最適化(不要なスペースの削除、ファイル結合など)が行われ、アプリケーションの読み込み速度を向上させます。

プロジェクトのpackage.jsonがあるディレクトリ(今回はproject/frontend)に移動して、以下のコマンドを実行してください。

npm run build

npm run buildを実行すると、開発用に人間に読みやすく書かれたReactのソースコードが、本番環境(インターネット上)で高速に動くための、最適化された静的なファイル群(ひとつの大きなJavaScript形式)に変換されます。

コマンドが正常に完了すると、プロジェクト内にdistという名前のディレクトリが生成されます。このdistディレクトリ内に格納されているファイル群が、公開対象の成果物となります。

エラーについて ※ちなみに、このブログに記載の流れでやっていた場合、以下のようなエラーが出るかもしれません。

src/components/common/index.ts:3:24 - error TS2307: Cannot find module './Footer' or its corresponding type declarations.

3 export { Footer } from './Footer';

これは「src/components/common/index.ts」に記載がある./Footerパスが見つからないせいで起こります。最初は存在していたFooter.tsxというファイルが消されたからだと考えられます。

index.tsにある該当行を削除することでエラーが解消するので、もう一度npm run buildしてみてください。

// src/components/common/index.ts

export { Button } from './Button';
export { Footer } from './Footer'; // ← 削除
export { Header } from './Header';

ステップ2:Amazon S3で静的ウェブサイトホスティングを有効にする

次に、ビルドしたファイルをホスティングするための場所をAWS上に確保します。Amazon S3の静的ウェブサイトホスティング機能を利用します。

  1. AWSマネジメントコンソールにログインし、サービス一覧または検索窓から「S3」を選択します。
  2. 「バケットを作成」をクリックします。
  3. バケット名を入力します。この名前は全てのAWSユーザー間で一意である必要がありますので、プロジェクト名や日付、アカウントIDなどを利用して命名してください。
  4. 「パブリックアクセスをすべてブロック」のチェックを外します。Webサイトとしてコンテンツを一般公開するため、この設定が必要です。設定をオフにすることを確認するチェックボックスにチェックを入れます。
  5. その他の設定はデフォルトのまま、ページ下部の「バケットを作成」をクリックしてバケットを作成します。
  6. 作成したバケットを選択し、「プロパティ」タブを開きます。
  7. ページ下部にある「静的ウェブサイトホスティング」セクションの「編集」をクリックします。
  8. 「静的ウェブサイトホスティング」を「有効にする」に設定し、「インデックスドキュメント」にindex.htmlと入力します。
  9. 「変更の保存」をクリックします。保存後、このセクションに表示されるバケットウェブサイトエンドポイントのURLを控えておきます。これがWebサイトのアドレスになります。

ステップ3:ビルドしたファイルをS3バケットにアップロードし公開する

最後に、生成されたファイルをS3バケットにアップロードし、アクセス権を設定します。

  1. 作成したS3バケットの「オブジェクト」タブを開きます。
  2. ローカルPCのdistディレクトリをダウンロードし、その中に含まれる全てのファイルとフォルダを、ブラウザの「オブジェクト」画面にドラッグ&ドロップ、または「ファイルを追加/フォルダの追加」ボタンから選択します。(dictディレクトリ自体はアップロードしないでください。)
  3. アップロードするファイルを確認し、ページ下部の「アップロード」ボタンをクリックして実行します。
  4. アップロードが完了したら、次にバケット内のオブジェクトを公開するためのアクセス許可を設定します。「アクセス許可」タブを開き、「バケットポリシー」セクションの「編集」をクリックします。
  5. 以下のJSONをポリシーエディタに貼り付け、"YOUR_BUCKET_NAME"の部分を、ご自身が作成したバケット名に書き換えてください。

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Sid": "PublicReadGetObject",
                "Effect": "Allow",
                "Principal": "*",
                "Action": "s3:GetObject",
                "Resource": "arn:aws:s3:::YOUR_BUCKET_NAME/*"
            }
        ]
    }
    

もしここでブロックパブリックアクセスのエラーが出る場合、S3コンソール左ペイン「このアカウントのブロックパブリックアクセス設定」を確認し、オンになっていたらオフにする必要があります。

  1. 「変更の保存」をクリックします。

以上で完了です。

ステップ2で控えておいたバケットウェブサイトエンドポイントのURLにブラウザでアクセスし、アプリケーションが表示されることを確認してください。
このURLを使えば、誰でもあなたの作ったアプリにアクセスすることが出来ます。URLの公開にはお気を付けください。(私は削除します)

URLがLocalhostではなくなっています

(ただし本番環境ではCloudFront利用を推奨します。以下記事が参考になります。)

blog.serverworks.co.jp

後編

前編(フロントエンド編)は以上です。

後編(バックエンド編)も力作ですので是非お楽しみいただければ幸いです。

blog.serverworks.co.jp

おわりに

フロントエンド未経験からANGEL Dojoで「少し経験がある」状態になると、色々なものの見え方が変わって感動しました。 本当に生成AIの進化には頭が上がりませんね。

もちろん、実用に耐えうるプロダクトにするにはただAmazon Q Developerの提案を鵜呑みにするだけではなく、きちんとコードを理解したり、他のやり方が無いかを調べたり、セキュリティなどの多角的な概念を意識してレビューしたりと、自分のコードに責任を持つ姿勢が必要です。 (今回のブログでは、バグが出ないかどうか確認するテスト工程の実施も省いています。)

自分も、最初にチームのディレクトリ構造をめちゃくちゃにしてしまったり、コンポーネントの意味を理解できずコード分割をしなかったり、一歩一歩成長しました。結局のところ、Qだけではいきなり経験者と肩を並べられるわけではないと実感しました。

ですが何もわからない状態からの第一歩として、「選択肢の一つが分かる」「最低限の全体像が見える」というのはとても重要だと思います。

そんなわけで、このブログが少しでも皆様の参考になれば幸いです。後編もお楽しみください。

垣見(かきみ)(執筆記事の一覧)

2023年新卒入社 エンタープライズクラウド部所属 2025 Japan AWS Jr.Champions

図解するのが好き。「サバワク」のアイキャッチ作成も担当しています