AIが全部書くなら、技術スタック選びはもっと楽しくなる

「AIが全部コードを書いてくれるなら、技術のことは知らなくていいんじゃないですか？」

最近、この問いをよく見かけます。そして、たいてい「いや、知らないとダメだ」か「もう知らなくていい」の二択で語られます。

私は、どちらでもないと思っています。

知らなくても作れる。これは本当です。ただ、知っていると選べる。そして選べるようになると、開発は一気に楽しくなります。

「このフレームワークはこういう性格だから、こういう時に相性がいい」。それを知っているだけで、AIに何かを頼むときの景色が変わります。全部覚える必要も、書けるようになる必要もありません。性格と、得意な場面。この2つを知っているだけでいい。

今回は、Web開発でよく名前が挙がる技術を並べて、「どういう性格で、だからどういう時に相性がいいのか」を書いてみます。最後に、いま個人的に一番面白いと思っているRustの話をします。

なるべく専門用語は使わず、出てくるものには一言添えます。

---

Next.js — 「検索から人に来てほしいサイト」と相性がいい

まずはNext.jsから。公式が「The React Framework for the Web」と名乗っているとおり、Reactというフロントエンドの道具を土台にしたフレームワークです。

特徴①：検索エンジンに読まれやすい形でページを返せる

Webページには、大きく分けて2つの作り方があります。

ひとつは、ほぼ空っぽのHTMLをブラウザに送って、あとはブラウザ上のJavaScriptが中身を描くやり方。もうひとつは、サーバー側で中身の入ったHTMLまで組み立ててから送るやり方です。

素のReactは前者になりがちです。人が見るぶんには問題ないのですが、検索エンジンのクローラーやSNSのリンクプレビューは「送られてきたHTMLに何が書いてあるか」を見るので、空っぽのHTMLだと不利になることがあります。

Next.jsは後者ができます。あらかじめページを作り置きしておくやり方と、アクセスのたびにサーバーで組み立てるやり方の両方を持っていて、ページごとに使い分けられます。

しかもここが徹底していて、公式ドキュメントには「ボットやクローラーはUser Agentで判別して別扱いにする」と書いてあります。彼らには完成した文書が必要だから、途中まで送って残りを後から流し込むような小細工はせず、サーバー側で最後まで描き切ってから、完成したHTMLを送る——という挙動が仕様として明記されています。

さらに、検索結果やSNSカードに出る情報——ページのタイトル、説明文、サムネイル画像——を扱う仕組みが標準で入っています。sitemap.xmlやrobots.txt（検索エンジンに「このサイトにはこういうページがあって、ここは見ないでほしい」と伝えるファイル）も、公式の仕組みで生成できます。

「SEOに強い」と言われるのは、このあたりが最初から揃っているからです。念のため補足すると、使えば検索順位が上がるという話ではありません。公式が掲げているのも「SEOのための道具を用意している」までです。正確に言えば、SEOで不利になりにくい作りが標準になっている、ということだと思います。

特徴②：画面もサーバー処理も同じプロジェクトに書ける

Next.jsは「フルスタック」を自称しています。画面を作る部分だけでなく、サーバー側で動く処理も同じプロジェクトの中に書ける、という意味です。

たとえばフォームを送信して保存する、外部のサービスにデータを取りに行く、といった処理を、画面のすぐ隣に置けます。「フロントエンド用のリポジトリとバックエンド用のリポジトリを別々に用意して、その間をつなぐ」という作業が要りません。小さく始めるときの手数が、これでかなり減ります。

ただし、公式は同時にはっきり線を引いています。「Next.jsのバックエンド機能は、バックエンドの完全な代替ではない。APIの層として機能するものだ」。なんでもここに載せられるわけではなく、あくまで画面のすぐ裏側までを引き受ける、という位置づけです。ここを勘違いすると後で苦しくなるので、公式が自分から書いているのは親切だと思います。

ここは分けて考えたい：Next.js と Vercel

Next.jsの話をすると、必ずVercelの名前が一緒に出てきます。ただ、この2つは役割が違います。

Vercelは、Next.jsを開発している会社であり、同時にホスティングサービスの名前です。ホスティングというのは、作ったものを実際にインターネット上に置いて配信する場所のこと。GitHubにコードを送ると自動でビルドして公開してくれる、という部分はVercelの仕事であって、Next.jsというフレームワークの機能ではありません。

上に書いた「検索エンジンに読まれやすい形でページを返せる」「タイトルやOGP画像の仕組み」「sitemap.xml」「サーバー処理も同じプロジェクトに書ける」は、すべてNext.js自体の機能です。Vercelに置かなくても効きます。公式にセルフホスティングのドキュメントがあり、そこでも自前のNode.jsサーバーとDockerは「全機能対応」と明記されています。

一方、Vercel側の担当はこちらです。

• GitHubにコードを送ると自動でビルドして公開してくれる
• ブランチやプルリクエストごとに、確認用のURLが自動で発行される
• 世界中に配置されたCDN（利用者の近くにデータを置いて速く届ける仕組み）が最初から付いてくる

つまり「デプロイが簡単」は、フレームワークの話ではなくホスティングの話です。

ややこしいのは、この2つの境目が「使える／使えない」ではないことです。公式ドキュメントを読むかぎり、Vercelでしか動かないNext.jsの機能というものは存在しません。差が出るのは、ゼロ設定で済むか、自分で設定して運用するかのほう。たとえばページを一定時間ごとに作り直す仕組みは自前サーバーでも動きますが、サーバーを複数台に増やすと、キャッシュの持ち方を自分で書く必要が出てきます。

「使えるかどうか」ではなく「自分でどこまで面倒を見るか」の差。ここを分けて理解しておくと、Vercelを使う／使わないを、思い込みではなく条件で選べるようになります。

だから、こういう時に相性がいい

• 検索から人が来ることが売上や成果に直結するもの — メディアサイト、企業のコーポレートサイト、ブログ、製品紹介ページ、ECの商品ページ
• SNSでシェアされることを想定しているもの — リンクを貼ったときのプレビューが最初から整う
• 画面もサーバー処理も少人数でまとめて作りたいとき

逆に、ログインしてから使う社内ツールのように検索に載る必要がないものだと、いちばんの強みが効きません。その場合は別の選択肢のほうが素直なことがあります。

---

Ruby on Rails — 「AIに書かせる」時代に、規約の価値が上がった

次はRuby on Rails。もう20年以上使われているフレームワークですが、いま再評価されるべき理由があると思っています。

特徴：設定より規約

Railsが掲げている二大原則のひとつが「設定より規約（Convention over Configuration）」です。公式ガイドの言い方を借りると、「良いやり方について意見を持っていて、設定ファイルで延々と定義させる代わりに、それを既定にする」という考え方です。

決められた名前で、決められた場所にファイルを置く。そうすれば、つなぎ込みのコードを自分で書かなくても動きます。コマンドをひとつ叩けば、データの定義・処理・画面・URL・データベースの変更・テストが一式まとめて出てきます。

Railsには「The Rails Doctrine」という思想を書いた公式文書があって、その柱のひとつが「The menu is omakase」——メニューはおまかせ、です。料理人に任せれば、良い料理とは何かを自分が知る前から、たぶん良い食事にありつける。だから任せなさい、という話。

ここが本題：「誰が書いても同じようなコードになる」

この「決まっている」性質は、長いあいだ賛否が分かれるポイントでした。自由がない、レールから外れると途端に苦しい。そういう批判がずっとありました。

でも、AIにコードを書かせるようになって、この評価はかなり反転したと感じています。

理由は単純で、「ここはこう書くもの」が決まっているほど、AIの出力がブレないからです。

AIに「ログイン機能を作って」と頼んだとき、決まりのない環境では、書き方も置き場所も毎回わずかに違うものが出てきます。1回目と2回目で流儀が違う、という状態が普通に起きる。読む側は、そのたびに「今回はどういう方針で書かれているのか」から確認することになります。

Railsだと、そこが揃います。誰が書いても——人間でもAIでも——同じような形になる。だからレビューする側は「この実装が正しいか」を毎回ゼロから考えるかわりに、「規約から外れていないか」という見方ができます。読む負担が大きく下がります。

細部を指定せずAIに任せて作っていく、いわゆるバイブコーディングとの相性が良いのも同じ理由です。指定しなかった部分に「既定」があるから、任せても崩れにくい。指定しなかった部分が毎回ランダムに決まる環境で任せるのとは、出てくるものの安定感が違います。

面白いのは、フレームワーク側もこの流れを自覚していることです。Rails公式サイトのいちばん大きな見出しは、いま「Accelerate your agents with convention over configuration.」——規約で、あなたのエージェントを加速させろ、になっています。同じPHPのフレームワークであるLaravelも、公式ドキュメントに「An Agent Ready Framework」という節を設けて、意見を持った規約と明確な構造がAI支援の開発にとって理想的な条件になると説明しています。

長年「窮屈だ」と言われてきた側が、いちばん有利な場所に来ている。この逆転が、個人的にはとても面白いところです。

だから、こういう時に相性がいい

• データを登録して、一覧して、編集する——が中心の業務システム。社内の管理ツール、予約システム、在庫管理
• 早く形にしたいとき。決まっているぶん、ゼロから設計する時間が要らない
• AIに任せる比率を高くしたいとき。上に書いたとおり、出力が安定する

逆に、他とまったく違う独自の構造を作りたいときは、規約がそのまま邪魔になります。ここは正直なトレードオフです。

---

LaravelとDjango — 押さえておくと選択肢が増える2つ

主流をもう2つ、軽く。

Laravelは、PHPで最もよく使われているフレームワークです。公式ドキュメントが「表現力があってエレガントな文法」「素晴らしい開発者体験を提供することを目指す」と掲げているとおり、書き手の気持ちよさに重心があります。PHPが動く環境は世界中に大量にあるので、置き場所を選びにくいのも実務では効きます。思想としてはRailsに近く、規約と全部入りの方向です。

Djangoは、Pythonのフレームワークです。公式のキャッチコピーが「締め切りのある完璧主義者のためのWebフレームワーク」で、ほぼこの一文どおりの性格をしています。データの形を定義してやると、それを追加・編集・削除できる管理画面が自動で出てくるのが有名です。そして何より、Pythonなのでデータ分析や機械学習と地続きなのが強い。AIまわりのライブラリはPythonに集まっているので、AIを組み込んだサービスを作るならここが最短距離になることが多いです。

---

Rust — 「難しいから無理」が、選ばない理由ではなくなる

最後に、いま一番面白いと思っている話をします。

Rustという言語があります。開発者向けの大規模調査として有名なStack Overflowの年次調査で、2016年から2025年まで10年連続で「最も愛される言語」「最も称賛される言語」の1位を取り続けている言語です（途中で項目名が「Most Loved」から「Most Admired」に変わっていますが、Rustが1位なのはずっと変わっていません）。

つまり、使った人がほぼ全員「また使いたい」と言う言語です。それでいて、Web開発の現場で名前を聞く機会はそこまで多くない。この落差に、面白い事情があります。

何がすごいのか：速さと安全を両立している

プログラミング言語には、長いあいだ速さと安全のトレードオフがありました。機械に近いところまで直接触れる言語は速いけれど、間違えたときの事故が大きい。事故が起きにくい言語は、そのぶん裏で安全装置が働くので、動作が一瞬止まったりメモリを余分に使ったりする。どちらを取るか、という選択がずっと続いてきました。

Rustは、そのどちらでもない道を選んだ言語です。仕組みの説明は本題ではないので省きますが、公式が掲げている3本柱は「Performance」「Reliability」「Productivity」。速さと信頼性を同時に並べているのが、この言語の立ち位置です。

それが実際に効いた例として、Discordが自社ブログで公開している話があります。ある機能をGoで書いていたところ、数分おきに大きな遅延のスパイクが出る。原因を突き止めた結果、その部分をRustに書き換えた——という顛末が公開されています。速度が効く場所では、こういう乗り換えが現実に起きています。

ネックはずっと「難しさ」だった

ただ、Rustにはずっと大きなハードルがありました。習得が難しい。

他の言語なら普通に書けるコードが、Rustでは書いた時点で弾かれます。公式の解説書も「多くのプログラマにとって新しい概念なので、慣れるにはそれなりに時間がかかる」と正直に書いています。

そして、これが実際に採用の壁になっていることが、数字にも出ています。Rust公式が毎年実施している調査（2024年版）によると、Rustを使っていない人のうち約31%が、使わない理由として「難しそうだという印象」を挙げています。言語やエコシステム全体に圧倒された、Rustを導入するのは人的コストが高すぎた、という声も報告されています。

誤解しないでほしいのは、この厳しさは欠陥ではなく仕様だということです。他の言語なら「とりあえず動くけど、条件が揃うと壊れるコード」として通ってしまうものを、Rustは書いた時点で止めます。安全性は、この厳しさの対価として手に入っています。

とはいえ、現場で技術を選ぶときには、この難しさがそのまま障壁になっていました。「良い言語なのは分かるが、チームが書けるようになるまでの時間が読めない」。Rustが選ばれなかった理由の多くは、性能でも機能でもなく、ここだったわけです。

AIが書くなら、その障壁は誰の問題なのか

ここが本題です。

習得難易度というのは、突き詰めれば「人間が学習コストを払う必要がある」という話です。書くのがAIなら、そのコストの置き場所が変わります。「チームが書けるようになるまでの時間が読めない」という、いちばん大きかった不採用の理由が、そのままの形では成立しなくなる。

さらに面白いのは、Rustの厳しさが、AIとの相性ではむしろ有利に働きうることです。

AIは間違えます。生成されたコードが、見た目は正しいのに危ない、ということは普通に起こります。ゆるい言語だと、それはそのまま通ってしまい、動かしてみるまで——あるいは本番で事故が起きるまで——分かりません。

Rustは通しません。コンパイラが受け付けない。AIが間違えたときに、人間がレビューする前の段階で止まる安全網がある、という言い方ができます。

「厳しくて人間には辛いが、その厳しさがそのまま品質の担保になる」言語。書き手が人間からAIに移るなら、この特性の評価は上がるほうが自然だと思っています。

もちろん、コンパイルが通ることと、意図どおりに動くことは別です。厳しい言語ならAIの出力を検証しなくていい、という話ではありません。それでも、「難しいから採用しない」という判断だけは、明確に弱くなっていると思います。

すでに、けっこう使われている

「これから来るかも」という話に聞こえるかもしれませんが、Rustはすでに相当使われています。しかも、どれも公表しているのが本人たちです。

Linuxカーネルが受け入れています。公式ドキュメントにRust専用の章があり、開発者一覧でも正式にサポート対象として扱われています。OSの心臓部という、最も間違いが許されない場所です。

Androidの数字はかなり強烈です。Googleが自社のセキュリティブログで公開しているところによると、Androidのメモリ安全性に起因する脆弱性の割合は、2019年の76%から2024年に24%、2025年にはついに20%を切ったとのこと。同社は「Rustのコードにおけるメモリ安全性の脆弱性の密度は、C/C++と比べて1000分の1」とまで書いています。

しかも副産物として、Rustの変更は差し戻し率が4分の1で、コードレビューにかかる時間が25%短いというデータも出しています。「安全な道が、同時に速い道になった」という表現をしていて、これは書き手がAIかどうかに関係なく効いてくる話だと思います。

Cloudflareは、自社で使うHTTPプロキシをRustで書き直しました。公開されている数字では、1日1兆リクエストを処理して、CPUとメモリの消費は従来の3分の1。

そして、私たちが普段Webの開発で使うツール——ビルドツールやコード整形ツールのような裏方——も、次々とRustで書き直されています。Next.jsに組み込まれているビルドツールも、Pythonのパッケージ管理ツールとして急速に普及しているものも、公式に「Rust製」と書かれています。速度が体感で変わるので、使う側は言語を意識しないまま恩恵だけ受けている、という状態になりつつあります。

だから、こういう時に相性がいい

公式サイトが挙げている得意分野は4つ。コマンドラインツール、WebAssembly（ブラウザ上で高速に動かす仕組み）、ネットワークサービス、組み込み機器です。これを普段の言葉に置き換えると、

• 速度と安定性がそのまま価値になるもの — 大量のアクセスを捌くサーバー、常時動かし続ける基盤、他の人が使う開発ツール
• 止まってはいけないもの、事故のコストが大きいもの — メモリまわりのバグを構造的に潰せるのが効く。OSやセキュリティに近い領域
• 小さく速く動くものを配りたいとき — コマンドラインツールなど

逆に、作っては捨てる試作や、とにかく今日中に形にしたいものには、いまも重い選択です。厳しさは相変わらずそこにあります。RailsやDjangoが数分で用意してくれるものを、Rustはそう簡単には出してくれません。

それでも、「難しいから」という理由だけで最初から候補から外すのは、そろそろもったいない。そう思っています。

---

おわりに

知らなくても作れます。それは、これからもっとそうなっていくと思います。

でも、知っていると選べる。「これは検索から人に来てほしいものだからNext.js」「これは社内の管理ツールで、AIに任せる比率を高くしたいからRails」「これは速度が命だからRustを検討してもいいかも」。この判断が自分でできるようになると、AIへの頼み方が「指示」から「相談」に変わります。

そして、選べるようになると単純に楽しい。

この記事の内容も、覚える必要はまったくないと思っています。「Railsはおまかせの店らしい」「Rustは難しいけど、その難しさはもう自分の問題じゃないかもしれない」——それくらいの粒度で頭の片隅に残っていれば十分です。

そのうえで、実際のサービスがどう選んでいるかを眺めるのも楽しいです。以前、有名サービス8つの技術スタックを調べてまとめた記事を書きました。同じ規模のサービスでも判断が全然違って、読み物として面白いはずです。

👉 「このサービス、どの技術スタック？」有名サービス8つの技術スタックまとめ

AIが全部書いてくれる時代だからこそ、技術スタックは義務ではなく、選ぶ楽しみになる。私はそう思っています。

みなさんは、どれが好きですか。

---

本文中の数字の出どころ

具体的な数値を挙げた箇所は、すべてその組織自身が公開している一次情報を参照しています。

• Rustが10年連続1位 — Stack Overflow Developer Survey（2025年版。以前は「Most Loved」、現在は「Most Admired」）
• Rust非利用者の31%が「難しそう」を理由に挙げた — State of Rust Survey 2024（Rust公式ブログ）
• Androidのメモリ安全性脆弱性の推移とRustの効果 — Google Security Blog
• 1日1兆リクエストを捌くRust製プロキシ — The Cloudflare Blog「How we built Pingora」
• GoからRustへ切り替えた理由 — Discord Blog「Why Discord is switching from Go to Rust」

本記事の各技術に関する記述は、2026年9月時点の公式サイト・公式ドキュメントの内容に基づいています。キャッチコピーや既定の構成は変わることがあります。