私が実際のフロントエンド開発、アニメーション制作、およびフルスタック開発で使用しているフレームワークとライブラリ。
実践的なReact開発では、React単体だけでアプリケーション全体を構築するというよりも、機能や目的に応じてNext.js、Tailwind CSS、TypeScript、そして目的に合ったライブラリを組み合わせて使うことが多いです。 Next.jsは、ルーティング、サーバーサイドレンダリング、静的生成、API連携、サーバー側の処理などを扱いやすくし、Reactをより実用的なWebアプリケーション開発へ広げてくれる存在です。 Tailwind CSSはデザインの調整を素早く行えるため、UIの試作や細かなレスポンシブ対応にも向いています。TypeScriptは、データ構造やコンポーネント間の値の受け渡しを型によって明確にし、開発中のミスを減らしながら保守性を高めてくれます。 また、アニメーションにはFramer Motion、3D表現にはReact Three Fiber、フォームにはReact Hook Form、データ取得や状態管理にはTanStack Queryなど、目的に応じたライブラリを選ぶことで、React開発の表現力と開発効率は大きく広がります。 すべてを自分で一から作るのではなく、必要な部分に適切なツールを取り入れることで、開発スピードを保ちながら、品質の高いUIや機能を実装しやすくなります。特に実務や本格的な個人開発では、見た目の美しさだけでなく、パフォーマンス、保守性、拡張性、ユーザー体験まで考える必要があります。 そのため、フレームワーク、スタイリング、型安全性、UIライブラリを適切に組み合わせることは、単なる便利さのためではなく、長く運用できるWebアプリケーションを作るための重要な設計判断だと感じています。
Framer Motion、現在はMotionという名称でも展開されているこのライブラリは、ReactでUIアニメーションを実装する際に非常に便利です。単純なフェードインやスライドアニメーションだけでなく、要素の表示・非表示、ページ遷移、ホバー時の動き、レイアウト変更時の自然な補間など、ユーザー体験に関わる細かな動きを比較的シンプルに扱うことができます。 Reactでは、状態の変化に応じてUIが切り替わる場面が多くあります。その切り替わりをただ瞬間的に表示するのではなく、アニメーションによって自然につなぐことで、画面の変化がユーザーに伝わりやすくなります。たとえば、モーダルの開閉、カードの出現、ページ遷移時のローディング表現、リスト要素の並び替えなどは、Framer Motionが得意とする領域です。 一方で、React Three Fiberはブラウザ上で3D表現を扱うための強力な選択肢です。Three.jsを直接扱う場合、シーン、カメラ、ライト、メッシュ、マテリアル、アニメーションループなどを手続き的に管理する必要があります。React Three Fiberを使うことで、それらをReactコンポーネントとして整理しながら、3Dシーンを宣言的に構築できます。 ただし、React Three Fiberは通常のUIコンポーネントとは少し考え方が異なります。見た目はReactのJSXで書けますが、実際にはThree.jsのシーンやオブジェクトを制御しているため、useFrame、ref、ジオメトリ、マテリアル、カメラ制御、パフォーマンス最適化など、3D特有の知識も必要になります。そのため、Reactの延長としてだけでなく、Three.jsやリアルタイム描画の考え方も意識することが重要です。 また、フォーム開発ではZodとReact Hook Formの組み合わせが非常に実用的です。React Hook Formはフォームの入力状態やエラー管理を効率よく扱うためのライブラリで、Zodは入力データのルールをスキーマとして定義できます。 この2つを組み合わせることで、「この項目は必須」「メール形式である必要がある」「文字数は何文字以上」「複数項目の関係性をチェックする」といったバリデーションを、フォーム側の表示ロジックと分離して管理しやすくなります。さらにZodはTypeScriptとの相性が良く、スキーマから型を推論できる点も大きなメリットです。 フォームの入力値、バリデーションルール、送信データの型を近い場所で管理できるため、実装中のミスを減らしやすくなります。特にお問い合わせフォーム、ログインフォーム、投稿フォーム、管理画面の入力フォームなど、ユーザーからの入力を受け取る機能では、安全性と保守性の両方を高めるために有効です。 このように、Framer MotionはUIの動き、React Three Fiberは3D表現、ZodとReact Hook Formは安全なフォーム設計というように、それぞれ得意分野が異なります。React開発では、すべてをReact本体だけで解決しようとするのではなく、目的に応じて適切なライブラリを選び、責務を分けて設計することが重要です。適切なライブラリ選定は、開発効率を上げるだけでなく、UIの品質、コードの保守性、ユーザー体験の向上にもつながります。
フルスタックな機能を実装する場合でも、すべてを自前で作り込む必要はありません。実践的なReact / Next.js開発では、Supabase、Resend、Stripeのようなサービスを組み合わせることで、データベース、メール送信、決済といった重要なワークフローを、比較的シンプルなアーキテクチャで構築できます。 Supabaseは、PostgreSQLをベースにしたバックエンド基盤として扱いやすい選択肢です。データベース、認証、ストレージ、リアルタイム機能、Edge Functionsなどが用意されており、小規模な個人開発から本格的なWebアプリケーションまで対応しやすい構成になっています。 特にNext.jsと組み合わせる場合、ブログ記事、ユーザーデータ、問い合わせ履歴、商品情報、設定データなどをPostgreSQLで管理しながら、必要に応じてサーバー側で安全に処理できます。また、SupabaseではRow Level Security、つまりRLSを使って、データへのアクセス制御をデータベース側で設計できます。 たとえば、公開済みの記事だけを誰でも読めるようにし、下書きや管理用データは外部から触れないようにする、といった制御が可能です。これは、フロントエンド側の条件分岐だけに頼るのではなく、データベースそのものに安全性のルールを持たせる考え方です。そのため、公開サイトと管理画面を分けたい場合にも、比較的安全な構成を取りやすくなります。 Resendは、問い合わせフォーム、通知メール、登録確認メール、管理者向け通知などを実装する際に便利なメール送信サービスです。メール送信を自前のSMTPサーバーで運用しようとすると、到達率、スパム判定、ドメイン認証、送信制限、エラーハンドリングなど、意外と多くの問題を考える必要があります。 Resendを使うことで、Next.jsのServer ActionsやRoute Handlersからメール送信処理を呼び出し、必要なタイミングで安全に通知を送る構成を作りやすくなります。ただし、メール送信ではAPIキーをクライアント側に出さないことが重要です。ResendのAPIキーは必ずサーバー側で扱い、フォームから送信された内容もバリデーションしたうえで処理する必要があります。さらに、独自ドメインを使って送信する場合は、SPFやDKIMなどのDNS設定を行い、メールが正当な送信元から送られていることを確認できるようにする必要があります。 Stripeは、決済機能を導入する際に非常に強力なサービスです。クレジットカード決済、サブスクリプション、請求、領収書、返金、Webhookによる決済完了通知など、決済に関わる複雑な処理をまとめて扱うことができます。 決済機能を完全に自作しようとすると、セキュリティ、カード情報の取り扱い、法的・運用的なリスクが非常に大きくなります。そのため、決済部分はStripeのような専門サービスに任せ、アプリケーション側では「決済が完了したら、どのデータを更新するか」に集中する方が現実的です。 特に最初の実装では、Stripe Checkoutのようなホスト型または事前構築された決済UIを使うことで、独自の決済画面を作り込まずに決済フローを導入できます。より細かくUIを制御したい場合はPayment IntentsやElementsを使う選択肢もありますが、MVPや個人開発の段階では、まず安全でシンプルな構成を選ぶことが重要です。Stripeでは、PaymentIntentが支払いのライフサイクルを追跡する仕組みとして用意されており、必要に応じて認証や決済状態の管理を行えます。 このように、Supabaseはデータベースとバックエンド、Resendはメール送信、Stripeは決済というように、それぞれがフルスタック開発における重い責務を分担してくれます。 重要なのは、これらのサービスをただ導入することではなく、どの処理をクライアント側に置き、どの処理をサーバー側に置くべきかを考えることです。APIキー、決済処理、メール送信、管理用の書き込み処理などは、基本的にサーバー側で安全に扱う必要があります。 フルスタック開発では、機能を増やそうとするとアーキテクチャが複雑になりがちです。しかし、Supabase、Resend、Stripeのようなサービスを適切に組み合わせることで、データ保存、通知、決済といった実用的な機能を、必要以上に重い構成にせず実装できます。 個人開発やMVPでは、最初から大規模なバックエンドを作るよりも、信頼できる外部サービスを活用しながら、小さく作って安全に拡張していく設計が現実的だと感じています。
