1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

フロント初心者の元インフラ屋がNext.js×AI開発に挑戦

1
Posted at

【実践編】フロント初心者の元インフラ屋がNext.js×AI開発に挑戦

「TypeScriptって何?」「Next.jsって何が凄いの?」
前回の記事では、複雑なWeb開発の用語を「家づくり」に例えて図解しました。まだ全体像が掴めていない方は、ぜひこちらからご覧ください!

👉 【保存版】Web開発の用語が多すぎて混乱している人へ:TS・Node・React・Nextの関係性を完全図解

今回はその後編です。
実は私、これまでインフラ領域が中心で、フロントエンドはほぼ未経験でした。

しかし、AIエージェント(CursorやClaudeなど)の台頭をきっかけに思い切って触ってみたところ、現代の「Next.js × TypeScript」という構成は、インフラ屋の視点から見ても、AIに開発を任せる上で非常に理にかなったアーキテクチャだと気づきました。

今回は、フロント初心者の元インフラ屋が実際に触って率直に感じたその理由を、背伸びせず等身大で解説します。


1. 横文字の羅列は、インフラの「OSI参照モデル」で理解できた

前回の記事で紹介した「〜JS」たちの役割。最初は種類が多すぎて混乱しましたが、インフラエンジニアに馴染み深い「レイヤー構造(OSI参照モデルなどの依存関係)」に当てはめるとスッキリ理解できました。

下の層(基盤)がしっかりしていないと、上の層(応用)は動かない。
これをインフラ目線で変換すると、こうなります。

レイヤー 技術名 前編での「家づくり」 インフラ屋の脳内変換
第4層(総括) Next.js 家全体の建築システム Webサーバー + フレームワーク
第3層(部品) React / Vue 家具の組み立てユニット 画面のUIパーツ
第2層(規律) TypeScript 規格が決まった建材 (強いて言えばJavaのような厳密な型)
第1層(基盤) Node.js 電動工具や重機(基礎) Apache / Tomcat / CentOS

この強固な地層(レイヤー)があるからこそ、次にお話しする「AIとの相性の良さ」が生まれます。


2. APIの壁がない:TypeScriptの「型」がAIの暴走を止める

インフラ側から見ると、フロントとバックエンドの間には「API仕様書」という壁があり、ここの認識ズレがトラブルの元になるイメージがありました。

しかし今は、BFF(Backend For Frontend)という仕組みにより、画面側からサーバーの処理を「直接」呼び出せるようになっています。ここで一番驚いたのが、TypeScriptの「型」がフロントからバックエンドまで貫通しているという点です。

なぜこれが「AI時代に強い」のか?

AIに開発を丸投げすると、どうしても前後の文脈を忘れてしまい、設計がチグハグになることがあります。
しかし、データ構造を「型」としてフロントからバックまで共有しておけば、これが絶対的なルール(SSOT:単一の信頼できる情報源)になります。

  • 「API定義書の更新漏れ」ではなく、「型が合わないから動かない(=AI自身が即座にエラーに気づいて修正できる)」という構造。

これが、AIに意図しない動作をさせないための物理的なガードレールとして機能するため、手戻りが少なくスムーズに開発が進むのです。


3. SSRとSPAの仕組みは、究極のリソース最適化だった

「サーバーサイドでHTMLを作る(SSR)」と聞くと、毎回サーバーに負荷がかかるのでは?と思っていました。しかし、クラウドインフラ(維持費や負荷)の観点で見ると、非常に無駄のない仕組みでした。

  • SSR(初回の読み込み): ページを開いた瞬間だけ、AWS Lambdaなどの環境が一瞬だけ起動し、HTMLを作ってすぐ終了する。
  • SPA(その後の画面移動): 一度画面が表示された後は、ブラウザ(ユーザーのPCやスマホ)の処理だけで画面が切り替わる。

つまり、「誰もアクセスしていないのに常時起動して待機するサーバー(EC2など)」は不要になります。必要な瞬間だけリソースを消費する、インフラ目線でも非常にエコで合理的な構成です。


まとめ

  • OSI参照モデル: 複雑なフロントエンド技術も、インフラのレイヤー構造に当てはめると理解しやすい。
  • TypeScriptの型: AIの暴走や手戻りを防ぐ「物理的なガードレール(SSOT)」になる。
  • SSR/SPA: サーバーの常時待機をなくす、合理的なリソース最適化。

フロントエンドはほぼ未経験からのスタートでしたが、裏側で何が起きているか(Lambdaの起動やDBの負荷など)というインフラの基礎知識は、そのまま強力な武器になると実感しています。

「フロントの横文字はちょっと…」と敬遠しているインフラエンジニアの方こそ、AIエージェントと一緒に新しいWeb開発の世界へ飛び込んでみると、意外なほどスムーズに理解できるはずです!


💡 補足アドバイス

私も最初は「とりあえず動けばいい」とAIに任せきりにして、設計が歪んで手戻りする失敗をしました。まずは「TypeScriptで型(SSOT)をしっかり決める」ことだけ意識すると、AIの出力が一気に安定するのでおすすめです!

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?