機械学習エンジニアが Web 開発で戦うための選択
私は長年、機械学習を中心としたプロジェクトに取り組み、Python で書くのが日常だった。教育系の活動も多く、解説資料は Jupyter Notebook で作成し、Sphinx を使って HTML として公開する流れが当たり前だった。書籍もJupyter Notebook で執筆している(編集者や組版の方々の協力あってのことであり大変感謝している)。
Python を愛してきた理由は、そのデータサイエンスから Web まで圧倒的な汎用性の高さにある。Django や FastAPI を使えば、十分に Web 開発もできる。「1 つの言語で何でもできる」という点は、私のように様々な分野に足を踏み入れる者にとって、この上ない魅力だった。
しかし今、私はほとんど Python を使わなくなり、Next.js という JavaScript ベースの Web アプリケーションフレームワークをメインに使っている。自分でも驚くべき変化だが、これには明確な理由がある。
結論から言えば「餅は餅屋」の原則に立ち返ったからだ。ただし、この「餅は餅屋」は多くの人が考えるものとは少し異なる私なりの解釈がある。それは実装コストの観点から見た「餅は餅屋」の原則だ。
Python から離れる決断:技術の適材適所を考える
まず私の個人的な経験から明確にしておきたいのは、Python と Next.js を同列に並べて比較するのは誤りだという点だ。タイトルでは Next.js に詳しくない人でもわかりやすいように Python と Next.js の対比で書いたが実際には異なり、関係は次の通りである。
Python はプログラミング言語であり、Next.js は React を基盤としたWeb アプリケーションフレームワークだ。しかし、それぞれが私の具体的な業務においてどう機能するかを考えると、興味深い発見があった。
私の Python 愛:データサイエンスでの強み
私にとって Python の素晴らしさは次の点にあった。
- データサイエンス/機械学習での圧倒的な強さ:NumPy、Pandas、scikit-learn、TensorFlow、PyTorch など強力なライブラリが揃っている
- 可読性の高い構文:初学者にも理解しやすく、メンテナンス性が高い
- 汎用性:科学計算から Web 開発まで幅広く対応できる
Web 開発においても、Django や FastAPI を使ってきた私は、これ以上の選択肢は要らないとさえ思うほど汎用性の高い選択肢であった。
葛藤と決断:Next.js への転向
しかし約 5 年前、私は Next.js に出会い、徐々に惹かれていった。その魅力は次の点にあった。
- React ベースのコンポーネント指向 UI:再利用性と保守性の高い UI 構築
- 多様なレンダリング戦略:SSR、SSG などをページ単位で選択可能
- 開発者体験(DX)の素晴らしさ:ファイルベースのルーティング、画像最適化など
この移行は決して簡単ではなかった。Python 中心の私にとって、JavaScript/TypeScript と React の世界への没入は、アイデンティティの一部を捨てるような感覚だった。約 3 ヶ月もの間、苦しみながら学習した。今まで数時間でできていた実装が一向に進まず、「この決断は間違っているのではないか」と何度も自問自答した。
もしこの読みが外れていたら大損害だった。短期的な損失を出しながらも長期的な方向性も間違える—これは開発者として最も避けたいシナリオだ。だが、結果的にこの決断は正しかった。Next.js は今、Web アプリケーション開発における最も重要なフレームワークの 1 つになっている。私はただ、熟す前に賭けただけだ。
私が気づいた「餅は餅屋」の本質:実装コストの視点
私が「餅は餅屋」を再解釈したのは、実際のプロジェクト経験からだ。その本質は単に「各技術の得意分野を活用する」というだけではない。より重要なのは「実装コストが最も大きいものをメインに据える」という視点だ。
私が体験した実装コストの逆転現象
Python で様々な Web アプリケーションを作ってきたが、どうしてもフロントエンド開発の部分で JavaScript が必要になる。そこでReact などの JavaScript フレームワークを組み込むことになるのだが、ここで私は興味深い現象に気づいた。
実装作業が進むにつれて、圧倒的に時間を費やしていたのはフロントエンド側だった。Python の役割は単なるファイルやデータベースの読み書き、機械学習モデルの呼び出しといった部分に限定されていき、それに比べて JavaScript での実装コストが急速に膨らんでいく。そして気づいた。
結局 Python でも、Web を作り込むと JavaScript が必要になり、React などを組み込んでいくことになる。そうなると、Python の役割は意外と少なく、JavaScript での動的な操作などの実装コストが上がっていく。それなら、最も実装コストが大きいものをメインにした方が良くないか?
これが私の Next.js 転向の最大の理由だ。
実装コストの分布:私の経験から
私が経験した Web アプリケーションにおける実装コスト分布を図式化してみよう。
この図は私のプロジェクト経験に基づいているが、多くの Web アプリケーションではフロントエンドの実装に工数の大半が費やされていた。特にユーザー体験(UX)を重視する現代では、この傾向は一層強い。
このような状況では、最も実装コストが大きい部分をメインに据えた技術選択が合理的だと私は確信した。つまり、フロントエンドで多くの時間を費やすのであれば、フロントエンドに最適化されたフレームワークを中心に据え、それに合わせてバックエンドを統合するアプローチが効率的だ。
Next.js はまさにこの考え方に沿っている。フロントエンドだけでなく、API ルートを通じてバックエンド機能も提供し、1 つの統合されたフレームワークとして機能する1。これは私にとって大きな発見だった。
速度という決定打:ユーザー体験を最優先する
実装コストに加えて、私が Next.js を選んだ決定的な理由にパフォーマンスがある。やはりユーザーに提供する上で速いは正義だ。
Python の速度問題:実際のところ
「Python が遅い」と言われることがあるが、私の経験では文脈によって異なる。確かに純粋な計算処理では、Python は C++や Java などのコンパイル言語より遅いことがある2。
しかし、FastAPI のような最新の Python フレームワークは、非同期処理と ASGI サーバーにより優れたパフォーマンスを発揮する3。
体感速度の決定的な違い:Next.js が変えたもの
しかし、ユーザーが実際に体感するパフォーマンスという点で、Next.js には大きな優位性があることを私は実感した。これは主に SPA(Single Page Application)と MPA(Multi Page Application)のアーキテクチャの違いによるものだ。
Python のようにページ単位で描画しないNext.js では、ブラウザでの再描画方法が根本的に異なる。Django のような MPA フレームワークでは、各ページ遷移でサーバーから完全な HTML を再取得し、ブラウザを完全再読込する必要がある4。
対照的に、Next.js は SPA のような動作も可能で、クライアントサイドの JavaScript だけでページ遷移が処理される。必要なデータのみを API から取得し、DOM(Document Object Model)の一部だけを動的に更新する5。したがって、SPA(Next.js)だからページ遷移も速いのだ。
加えて、Next.js の最も素晴らしい点は、SSR(サーバーサイドレンダリング)と SSG(静的サイト生成)をページ単位で切り替えられる柔軟性だ6。
- トップページ(アクセスが多い):SSG で高速表示
- ダッシュボード(認証が必要):SSR で動的内容を提供
この柔軟性によって、サイト全体で最適なパフォーマンスを達成できる。このようなパフォーマンス向上が Next.js を使えば自動的に手に入る。Django で開発していたときと大きな違いはないが、Next.js ではこのパフォーマンスがデフォルトで得られる。これが私にとっての決定打であった。
AI 時代を見据えた技術選択:私の選んだ道
Next.js を選んだ未来を見据えた判断
Next.js の選択は 5 年前には勇気のいる決断だったが、今、その判断は正しかったと言える。Netflix、Uber、TikTok など大企業も採用しており7、React 自体もフロントエンドフレームワークとして不動の人気を誇っている8。
私の経験から言えば、いま Web アプリを作るなら Next.js が最有力候補だろう。もちろん、問題もある。特にVercel にロックインを許容できるかが大きい。他の環境でもデプロイできるが、Vercel が提供する最適化された環境からは離れることになり、いくつかの機能には制限がかかる。しかし、開発効率とパフォーマンスの向上を考えると、私はこのトレードオフを受け入れている。
AI 支援でメジャー技術が輝く理由
私が Next.js の選択を特に評価するのは、AI 時代においてのメリットである。
AI 時代にはメジャーであることはかなり大事だ。GitHub Copilot や ChatGPT、Claude といったコード生成 AI ツールは、GitHub などの公開リポジトリを学習データとして利用している9。そのため、広く使われている言語やフレームワークほど、AI は正確で詳細な情報を持っていることが多い。
私自身、AI に質問する際、Next.js については驚くほど正確で詳細な回答が得られるが、マイナーなフレームワークだと間違いや曖昧な回答が増える傾向にある。この差はプロジェクトの進行速度に直結する。
Tailwind CSS の選択:構造的な理由
フロントエンド開発においては、CSS は Tailwind CSS を使った方が良い。AI との Vibe Coding は絶対こっちが有利だ。1 ファイルの読み書きで完了するため、コストが低い。
機能とスタイリングを分けた方が良いというのは人間にとっての保守性であった。それが AI 前提だと機能もスタイリングも一緒でも良いからそれぞれが近くにある方が大切に思える。
AI は人間にとって...と言った文脈は関係ない。AI にとって良い選択は何か?とそろそろ整備し始めて良い頃だと思う。AI コードアシスタントとの相性は、今後の技術選択において無視できない要素になりつつある。
アンラーニングの壁を越える:私の経験から
私が Python から Next.js へのスイッチングで最も困難だったのは、既存スキルのアンラーニングの過程だった。
3 ヶ月の苦しみが教えてくれたこと
アンラーニングは難しい。もう 5 年ほど前になるが、いまのスキルをアンラーンするために3 ヶ月ほど学んでやっと最初のプロジェクトができた。Python で同じ概念を獲得している分、差分だけを学べば良かったはずだが、新しいことを学ぶのは最初は歯がゆい。
今までなら同じ時間でできていたものが全然できない。この短期的なデメリットを許容してグッと堪えられるかがポイントだ。将来のためと歯を食いしばる必要があった。
この経験から私が学んだのは、熟す前に賭けることの価値だ。技術が完全に成熟してから学び始めると、すでにその波に乗り遅れている。熟した頃に学び始めていたらずっと遅れてしまう。
Web 開発者への私からのアドバイス
ぜひ、Web アプリ開発をしたい人は思い切ってアンラーニングしてみてほしい。特に Python に精通している人には、Next.js への投資は長期的に大きなリターンをもたらすはずだ。ただし、これは容易な道ではない。最初は生産性が落ちることを覚悟して、長期的な視点で取り組む必要がある。
私は 5 年前の Next.js への投資で、いま大きなリターンを得ている。しかし、技術の世界は常に変化している。5 年前にスイッチングしたのが良かったのであって、またこれから変わる可能性がある。だから常に新しいトレンドにアンテナを張り、必要に応じて「熟す前に賭ける」勇気を持つことが重要だ。
結論:私が見出した「餅は餅屋」の新たな解釈
Python からの移行を経験して、私は「餅は餅屋」の原則を再解釈するに至った。それは単に「各技術の得意分野を活用する」という意味だけでなく、「実装コストが最も高い部分に焦点を当てる」という深い洞察を含んでいる。
Python はデータ解析には向いている。ただ、プロダクション環境にデプロイするときには、餅は餅屋だ。
Web アプリケーション開発において、フロントエンドの実装コストが最も高い場合が多い現実を考えると、Next.js のようなフロントエンドに最適化されたフレームワークを中心に据えることは理にかなっている。そして、そのフレームワークがバックエンド機能も統合していれば、開発効率はさらに高まる。
現在、私が Python を使うのは機械学習などどうしても必要な時だけだ。その場合は FastAPI で API 化して部分的に使っている。これは「餅は餅屋」の原則に則った、実用的なアプローチだと考えている。
技術選択は常にコンテキスト依存であり、プロジェクトの要件やチームのスキルセットによって最適解は異なる。しかし、実装コストの分布に基づいて判断するという視点は、多くの場面で役立つはずだ。
そして最後に、技術の世界での成功はトレンドを先読みする勇気とアンラーニングを恐れない姿勢にかかっている。「熟す前」に賭けることで、熟した時に最大限の恩恵を受けられる—これが私の Next.js 導入から学んだ最大の教訓だ。
参考文献
Footnotes
-
API Routes - Next.js. https://nextjs.org/docs/pages/building-your-application/routing/api-routes ↩
-
The Computer Language Benchmarks Game. https://benchmarksgame-team.pages.debian.net/benchmarksgame/ ↩
-
FastAPI Benchmarks. https://fastapi.tiangolo.com/benchmarks/ ↩
-
Django: The web framework for perfectionists with deadlines. https://www.djangoproject.com/ ↩
-
SPA vs MPA: Which Web Architecture is Right for You? https://www.ramotion.com/blog/spa-vs-mpa/ ↩
-
SSR vs. SSG in Next.js: Differences, Advantages, and Use Cases. https://strapi.io/blog/ssr-vs-ssg-in-nextjs-differences-advantages-and-use-cases ↩
-
Next.js Showcase. https://nextjs.org/showcase ↩
-
Stack Overflow Developer Survey 2023. https://survey.stackoverflow.co/2023/ ↩
-
GitHub Octoverse 2023. https://octoverse.github.com/2023/ ↩