複数の開発会社に相談したら、A社は「Next.jsで」、B社は「Laravelで」、C社は「Railsで」と、提案された技術がバラバラだった。専門用語が並ぶだけで、どれが自社に合うのか見当もつかない。見積もりの比較以前に、ここで手が止まってしまう発注者の方は少なくありません。
「開発会社によって使うフレームワークが違う。どれを選ぶのが良いのか、発注者が気にするべきなのか分からない」
先に結論をお伝えします。フレームワークの優劣を発注者が見極める必要はありません。ただし「選んだ理由を説明してもらうこと」と「将来の保守・引き継ぎに困らないか」の2点は、発注者が必ず確認したいところです。この記事では、フレームワーク（＝システムを作るときの土台になる部品の詰め合わせ）の違いを発注者の目線でどう見ればよいかを、5つの観点とそのまま使える質問例でお伝えします。
なお、特定のフレームワークをおすすめする記事ではありません。どれも広く使われている実績のある技術で、向き不向きは「何を作るか」「誰が保守するか」で決まります。
フレームワークが会社ごとに違うのは自然なこと
まず、提案がバラバラなのは異常なことではありません。開発会社は、自社のエンジニアが得意な言語と土台を中心に提案するのが普通です。得意な技術で作るほうが、品質が安定し、速く、費用も読みやすくなるからです。
「建築会社が、得意な工法で家を建てるのと似ています。木造が得意な会社に鉄骨を頼むより、得意な工法で提案してもらうほうが安心なことも多いんです」
代表的なものを、公式サイトの説明をもとに整理すると次のとおりです（2026年10月時点）。
| 名前 | 使われる言語 | 特徴の一言まとめ | 向いている例 |
|---|---|---|---|
| Next.js | JavaScript／TypeScript | 画面づくりに強いReactという部品をベースに、サイト全体を組み立てられる | 一般のお客様が使うWebサービス、予約サイト |
| Nuxt | JavaScript／TypeScript | Vueという画面部品をベースにした同種の土台 | 管理画面つきのWebサービス |
| Laravel | PHP | 認証や決済連携など定番機能が最初から揃っている | 業務システム、管理画面、会員サイト |
| Ruby on Rails | Ruby | 決まった作法に沿って素早く作るのが得意 | 新規サービスの立ち上げ、見積・請求などの業務システム |
| Django | Python | 管理画面が標準で付き、データ処理やAIとの相性もよい | データを扱う業務システム、AI機能を含むシステム |
「向いている例」はあくまで目安です。実際にはどの土台でも、ほとんどの業務システムやWebサービスは作れます。そのため「どれが正解か」を探すより、次の5つの観点で比べるほうが判断しやすくなります。
発注者が比べるべき5つの観点
観点1：その技術を選んだ「理由」が、あなたの案件に即して説明されているか
最も大切なのは、技術名そのものではなく選定理由です。「当社はいつもこれなので」だけでなく、「この案件は〇〇が重要なので、この土台が合う」と案件に引きつけて説明できる会社は、要件を理解している可能性が高いといえます。
一方で、「得意だから」という理由は決して悪いものではありません。得意なことは強みです。ただ、その場合でも「この案件で不利になる点はないか」を聞けば、誠実に答えてくれるかどうかが見えてきます。
観点2：公式のサポート期間が続いていて、更新の仕組みがあるか
フレームワークには、バグや脆弱性（＝悪用されうる弱点）を直してもらえる期間があります。この期間を過ぎた版を使い続けると、問題が見つかっても修正版が出なくなります。公式が公開している方針の例は次のとおりです。
📰 出典：Laravel 12.x Release Notes「Support Policy」
Laravelは、バグ修正を18か月、セキュリティ修正を2年間提供する方針で、年1回程度メジャーバージョン（＝大きな版）を出すと説明されています。
📰 出典：Ruby on Rails「Maintenance Policy」
Railsは、各版にバグ修正を1年、セキュリティ修正を2年提供する方針で、サポートが終わった版はそれ以降新しい修正版が出ないと説明されています。
Next.jsは、最新の版を中心に保守し、一つ前の版は重要な修正に絞って約2年間保守する方針と説明されています。
Djangoは、長期サポート版（LTS）を指定し、一般に3年間セキュリティ修正が提供される方針と説明されています。
どの土台にも共通するのは、「作った時点の版は、数年のうちにサポートが終わる」という点です。つまりフレームワークの種類より、「サポートが切れる前に誰が・いつ・いくらで版を上げるのか」を保守契約で決めておくことのほうが、発注者にとっては重要です。詳しくはフレームワークのバージョンが古いと言われた時の確認点をご覧ください。
観点3：他の開発会社でも保守を引き継げる技術か
将来、開発会社を変えたくなったときに、引き継げる会社が見つかるかどうかも大切です。広く使われている技術なら、引き継ぎ先の候補が多く、費用も読みやすくなります。逆に、一部の会社しか扱えない技術で作ると、その会社に依存しやすくなります。この点はマイナーな技術で作られ、他社に保守を断られた時の対処でも解説しています。
ただし「有名だから安心」とも言い切れません。採用実績の多さより、その会社が作るコードを他社が読み解ける形（設計書・テスト・手順書）で残してくれるかが、実質的な引き継ぎやすさを決めます。
観点4：AIコーディングツールを使った開発との相性
最近は、開発会社がAIコーディングツールを使って開発を進めるケースが増えています。この点でも、土台の違いは影響します。一般には、利用者が多く資料が豊富な技術ほど、AIが正確なコードを出しやすいと言われます。ただし、AIが書いたコードの品質を人が確認する体制のほうが、土台の種類よりずっと重要です。
発注者としては、「AIを使うか」よりも「AIが書いた部分を誰がレビュー（＝確認）し、テストで守っているか」を聞いておくと安心です。
観点5：運用するインフラ（動かす場所）との組み合わせ
土台によって、動かす場所の得意不得意があります。たとえば、画面の表示を速くする仕組みを活かすためにクラウドの専用サービスを使う提案もあれば、一般的なサーバーに載せる提案もあります。インフラの費用は毎月続くため、見積もりの初期費用だけでなく、運用費の内訳も比べましょう。
提案を比べるときのやりがちな失敗
- 技術名だけで優劣をつける：「新しいから良い」「古いからダメ」とは言い切れません。サポート期間内で、運用しやすいかが基準です。
- ネットの人気ランキングで決める：開発者向けの人気と、発注者にとっての「保守のしやすさ」は別物です。
- 選定理由を聞かずに、金額だけで比べる：土台が違えば、運用費やバージョンアップ費の考え方も変わります。
- 開発会社の得意技術を「押し付け」と決めつける：得意な技術で作ることは、品質と速度の面でメリットも大きいです。
発注者がやること チェックリスト
- ☐ 各社の提案書に、技術名（言語・フレームワーク・版）が書かれているか確認する
- ☐ 選定理由が、自社の案件の要件に即して説明されているか確認する
- ☐ 採用する版の公式サポート期間を、開発会社に確認する
- ☐ サポート切れ前の版上げが、保守契約に含まれるのか別料金なのかを確認する
- ☐ 設計書・テスト・手順書など、引き継ぎに必要な成果物が納品に含まれるか確認する
- ☐ ソースコードと環境の権利（アカウント・リポジトリ）が自社名義になるか確認する
- ☐ AIツールを使う場合、レビューとテストの体制を確認する
- ☐ 毎月かかる運用費（サーバー・ツール利用料）の内訳を比較する
開発会社への質問例
打ち合わせでそのまま使える質問を挙げます。
- 「今回の案件に、この技術を選んだ理由を教えてください。不利になりそうな点もあれば知りたいです」
- 「提案いただいた版の公式サポートはいつまでで、それまでに版上げを行う場合の目安の費用と時期を教えてください」
- 「万が一、別の会社に保守を移す場合、引き継ぎのために納品してもらえる資料やテストにはどんなものがありますか」
- 「AIコーディングツールを使う場合、AIが書いた部分はどのようにレビューし、テストで確認していますか」
- 「サーバーなどの毎月の運用費は、内訳でいくらになりますか。構成を変えるとどう変わりますか」
まとめ
- 提案される技術が会社ごとに違うのは自然で、得意な技術で作ることには品質・速度面の利点もあります。
- 発注者が見るべきは技術名の優劣ではなく、選定理由・サポート期間・引き継ぎやすさ・AI開発の体制・運用費の5点です。
- 「版上げをいつ・誰が・いくらで行うか」を契約の段階で決めておけば、技術の違いで大きく困ることは減らせます。
法律や契約に関する個別の判断が必要な場面では、弁護士などの専門家や公式窓口にご相談ください。提案書の技術選定について「この理由で妥当か」を客観的に整理したい場合は、お気軽にご相談ください。
あわせて読みたい関連記事
