Webアプリのフレームワーク選びで、発注者が「どれが一番優れているか」を判断する必要はありません。現在広く使われている主要なフレームワークは、どれも一般的な業務システムやWebサービスを作るのに十分な実力を持っています。発注者が見るべきなのは技術の優劣ではなく、「その技術で作ったシステムを、自社が何年も無理なく育てていけるか」です。具体的には、その技術を扱える人を採用・確保しやすいか、保守を続けやすいか、そして自社の事業の段階に合った開発速度が出せるか、の三つです。
フレームワークは、一度決めると簡単には変えられません。途中で変えるのは、ほぼ作り直しに近い作業になるからです。だからこそ、目先の開発費だけでなく、公開後の保守や、将来の内製化、開発会社の変更といった場面まで見据えて判断する必要があります。とはいえ、発注者がプログラミングを学ぶ必要はありません。開発会社の提案を聞き、いくつかの質問をすることで、十分に妥当性を判断できます。
この記事は、開発会社からNext.jsやRuby on Railsといった技術の提案を受けて、どう判断すればよいか迷っている事業責任者や担当者に向けて書いています。フレームワークの基本、発注者が見るべき観点、主要な選択肢の特徴、事業の段階に応じた考え方、提案を受けたときの確認手順を順に説明します。
フレームワークとは：発注者が知っておくべき範囲
フレームワークとは、Webアプリを作るときによく必要になる仕組み（画面の表示、データベースとのやり取り、ログイン、入力の検証など）をあらかじめ用意した「土台」のことです。土台を使えば、毎回一から作る必要がなく、開発を速く、一定の品質で進められます。家づくりにたとえると、工法や規格化された部材のようなものです。
発注者として押さえておきたいのは、次の三点です。
- フレームワークは言語とセットで選ばれる：Ruby on RailsはRubyという言語、LaravelはPHPという言語、Next.jsはJavaScript（多くの場合TypeScript）という言語の上で動きます。フレームワークを選ぶことは、そのシステムを扱える技術者の層を選ぶことでもあります。
- 画面側と処理側で分かれることがある：Webアプリには、利用者が見る画面の部分（フロントエンド）と、データの処理や保存を行う部分（バックエンド）があります。一つのフレームワークで両方を作ることもあれば、別々の技術を組み合わせることもあります。
- 決めると変えにくい：フレームワークは、システムのすべての部分に関わります。途中で変えるのは、ほぼ作り直しになります。
また、フレームワークの上には、ログインや決済、画像の加工などを担う「部品」（ライブラリ）が数多く組み合わされます。部品が豊富なフレームワークほど、一から作る部分が減り、開発が速くなります。一方で、使う部品が増えるほど、それぞれの更新を追いかける手間も増えます。部品の選び方と更新の方針も、保守のしやすさを左右する要素です。
つまり、フレームワーク選びは「技術の好み」の話ではなく、「誰がこのシステムを長く面倒を見られるか」という体制の話です。
発注者が見るべき3つの観点：採用・保守・開発速度
発注者がフレームワークを判断するときの観点を整理します。
| 観点 | 確認したいこと | なぜ重要か |
|---|---|---|
| 採用・人材の確保 | その技術を扱える技術者が多いか。自社で採用したり、別の開発会社に頼んだりしやすいか | 開発会社の変更や内製化のとき、引き継げる人がいないと困る |
| 保守のしやすさ | 長く使われていて、更新が続いているか。情報や部品が豊富か。書き方の決まりがはっきりしているか | 公開後の不具合修正、セキュリティの更新、機能追加を続けやすい |
| 開発速度 | 作りたいものに必要な機能が、土台や部品として揃っているか。開発会社が慣れているか | 最初の版を早く出せる。新規事業では特に重要 |
| 作りたいものとの相性 | 画面の操作性が重要か、データの処理や管理機能が中心か、スマートフォンアプリと共通化したいか | 相性が悪いと、無理な工夫が増えて費用と不具合が増える |
| 開発会社の経験 | その会社がその技術で同じ性格のものを作ったことがあるか | 経験の浅い技術での開発は、品質と期間のリスクになる |
この中で、発注者がもっとも軽視しがちで、後から効いてくるのが「採用・人材の確保」と「保守のしやすさ」です。開発会社が得意な珍しい技術で作ると、その会社に頼んでいる間は問題なくても、会社を変えたいとき、自社で人を採用して内製化したいときに、扱える人が見つからないという事態が起きます。
主なフレームワークの特徴と向いている場面
よく提案される主なフレームワークの特徴を、発注者の視点でまとめます。ここに挙げるのは一般的な傾向で、どれも幅広い用途に使えます。各フレームワークの細かな機能や最新の状況は変わるため、提案を受けた時点で開発会社に確認してください。
| フレームワーク | 言語 | 一般的な特徴 | 向いていることが多い場面 |
|---|---|---|---|
| Next.js | JavaScript / TypeScript | 画面の表現力と操作性に強い。画面側と処理側を同じ言語で書ける | 利用者が直接触る画面の使い心地が重要なサービス、表示速度や検索での見つけられやすさも重視したいもの |
| Ruby on Rails | Ruby | 決まりごとが多く、標準的な機能を短期間で作りやすい | データの登録・管理が中心のWebサービス、少人数で早く最初の版を出したい新規事業 |
| Laravel | PHP | 機能が揃っていて、PHPを扱える技術者の層が厚い | 業務システムや管理画面が中心のもの、既存のPHPのシステムがある場合 |
| Django | Python | 管理画面の仕組みが標準で用意されている。データ分析やAIの処理と組み合わせやすい | データ処理や機械学習・生成AIと組み合わせるサービス |
Next.js
Next.jsは、画面を作るための部品の仕組みであるReactをもとにしたフレームワークです。利用者が触る画面を滑らかに動かしたり、表示を速くしたりするのに向いています。画面側と処理側を同じ言語で書けるため、少人数の開発で全体を見渡しやすいという利点もあります。一方、複雑な業務処理や管理機能をすべてNext.jsだけで作るか、処理側に別の技術を組み合わせるかは、作るものによって判断が分かれます。
Ruby on Rails
Ruby on Railsは、「決まった書き方に従えば、少ないコードで多くの機能を作れる」という考え方のフレームワークです。データの登録・一覧・編集・削除といった標準的な機能を短期間で作りやすく、新規事業の最初の版でよく使われてきました。決まりごとが多いぶん、別の技術者が引き継いだときにもコードの構成を理解しやすいという面があります。
Laravel
Laravelは、PHPという言語のフレームワークです。PHPはWebの世界で長く使われてきた言語で、扱える技術者の層が厚いのが特徴です。業務システムや管理画面を中心としたシステムでよく使われ、既存のシステムがPHPで作られている場合には、技術をそろえやすいという利点もあります。
Django
Djangoは、Pythonという言語のフレームワークです。データの管理画面を作るための仕組みが標準で用意されていて、運営側の画面を短期間で整えやすいのが特徴です。Pythonはデータ分析や機械学習、生成AIの分野で広く使われている言語なので、Webアプリの中でデータの集計や予測、AIによる文章の処理などを行いたい場合に、同じ言語でまとめやすいという利点があります。
事業の段階・体制に応じた考え方
同じフレームワークでも、事業の段階や体制によって向き不向きが変わります。
新規事業の最初の版
まだ事業として成り立つか分からない段階では、開発速度が最優先です。開発会社が最も慣れていて、短期間で作れる技術を選ぶのが合理的です。ただし、検証がうまくいった後にそのまま育てていく可能性が高いなら、採用・保守の観点も最低限は確認しておきます。最初の版の技術の選び方はMVPの技術選定で詳しく解説しています。
長く使う業務システム
社内の業務を支えるシステムで、十年単位で使い続ける可能性があるなら、保守のしやすさと人材の確保を重視します。長く使われていて、更新が続き、扱える技術者が多い技術を選ぶと安心です。新しさよりも安定を優先する場面です。
将来、内製化したい場合
いずれ自社で開発チームを持ちたいなら、採用しやすい技術であることが重要になります。自社で採用したい技術者の層と、選ぶフレームワークの言語が合っているかを確認します。内製化の進め方は内製化か外注かで整理しています。
スマートフォンアプリも作る予定がある場合
将来スマートフォンアプリも作る予定があるなら、画面の部品や処理側の仕組みを共通化しやすい技術を選ぶと、後の開発が効率的になることがあります。ただし、共通化を優先しすぎて、今作るWebアプリに合わない技術を選ぶのは本末転倒です。
開発会社の提案を受けたときの確認手順
開発会社から技術の提案を受けたら、次の手順で確認します。
- 選んだ理由を聞く：「なぜこの技術を提案するのか」を、自社の作りたいものと結びつけて説明してもらいます。「得意だから」だけでなく、作るものとの相性の説明があるかを見ます。
- 同じ性格のものを作った経験を聞く：その技術で、似た規模・性格のシステムを作ったことがあるかを確認します。
- 他の選択肢と比べた理由を聞く：他の技術も検討したか、なぜそれを選ばなかったかを聞きます。比較の視点があるかどうかで、提案の確かさが分かります。
- 引き継ぎやすさを聞く：「将来、別の会社や自社の技術者に引き継ぐことになったら、引き継ぎやすいか」を率直に聞きます。
- 保守と更新の計画を聞く：フレームワークや部品の更新をどのくらいの頻度で、どう行うかを確認します。更新を放置すると、セキュリティの問題や、後でまとめて更新するときの大きな負担につながります。
- 画面側と処理側の構成を聞く：一つの技術で作るのか、複数の技術を組み合わせるのか。組み合わせる場合、それぞれを扱える人が必要になることを理解しておきます。
フレームワーク以外に確認したい技術の選択
技術の提案には、フレームワーク以外の選択も含まれています。発注者として、次の点も合わせて確認しておくと安心です。
- データベース：どの種類のデータベースを使うか。多くの業務システムでは、表の形でデータを管理するリレーショナルデータベースが使われます。特殊な選択をしている場合は理由を聞きます。
- 動かす場所（サーバー・クラウド）：どのクラウドやサービスの上で動かすか。毎月の利用料がどう変わるか、アカウントの名義を自社にできるかを確認します。
- ログインや決済などの外部サービス：認証や決済、メール配信などに外部のサービスを使う場合、そのサービスの料金と、将来ほかのサービスに乗り換えられるかを確認します。
これらも、一度決めると変えにくく、毎月の費用や引き継ぎやすさに影響します。フレームワークと同じく、「なぜそれを選ぶのか」を説明してもらいましょう。
これらの質問に、専門用語に頼らず分かりやすく答えてくれる会社であれば、技術の選択についても信頼しやすいと言えます。
具体例：架空の人材紹介会社の求人管理Webアプリ
架空の例として、人材紹介会社が、求職者と求人企業をつなぐ社内向けの管理Webアプリと、求職者向けの求人検索サイトを作る場面を考えます。
二社から提案があり、A社はNext.jsで画面側と処理側を一体で作る案、B社はRuby on Railsで管理機能を中心に作り、求職者向けの画面も同じ仕組みで作る案でした。担当者は「どちらが優れているか」で迷いましたが、確認手順に沿って質問すると、判断の軸が見えてきました。
- 求職者向けの検索サイトは、検索で見つけてもらうことと、スマートフォンでの使い心地が重要だった
- 社内向けの管理機能は、データの登録・検索・状態の管理が中心で、項目も多かった
- 将来的に、社内に数名の開発者を置いて改善を続けたいと考えていた
A社は、求職者向けの画面の表示速度と使い心地の面で優位を説明し、管理機能も同じ技術で作れると答えました。B社は、管理機能の多さから開発速度に優位があると説明し、求職者向けの画面も必要十分に作れると答えました。両社とも、それぞれの技術で同じ性格のシステムを作った経験がありました。
最終的にこの会社は、自社で採用したい技術者の層と、最も重視するのが求職者向けの集客であることを踏まえて、A社の案を選びました。決め手は技術の優劣ではなく、「自社が何を重視し、誰が長く面倒を見るか」でした。B社の案を選んでいても、十分に目的は達成できたはずです。
よくある失敗とその避け方
- 新しさや流行で選ぶ：話題の技術が自社に合うとは限りません。保守と人材の観点で、長く使えるかを確認します。
- 開発会社の得意分野だけで決まる：珍しい技術で作ると、その会社以外では引き継げない状態になりかねません。引き継ぎやすさを必ず確認します。
- 発注者が技術を指定しすぎる：「〇〇で作ってほしい」と根拠なく指定すると、開発会社の得意な技術で作れず、かえって品質と速度が落ちることがあります。指定するなら、理由（社内の技術者がいる、既存システムとそろえたいなど）を伝えます。
- 更新の計画がない：フレームワークや部品は、使い続けるなら定期的な更新が必要です。保守の契約に更新作業を含めるかを決めておきます。
- 画面側と処理側の構成を理解しないまま進める：複数の技術を組み合わせる構成では、それぞれの技術者が必要になります。引き継ぎや内製化のときに影響します。
技術の提案を判断するチェックリスト
- 提案された技術を選んだ理由が、自社の作りたいものと結びつけて説明されている
- 開発会社が、その技術で同じ性格のシステムを作った経験がある
- その技術を扱える技術者が多く、別の会社や自社の技術者に引き継ぎやすい
- フレームワークの更新が続いていて、今後も使われる見込みがある
- 更新作業の頻度と方法が、保守の計画に含まれている
- 画面側と処理側の構成と、それぞれに必要な技術者を理解した
- 将来の内製化やスマートフォンアプリの予定と矛盾しない
よくある質問
Q. 発注者がフレームワークを指定した方がよいですか？
明確な理由がなければ、開発会社の提案を基本にするのがよいでしょう。開発会社が慣れた技術で作る方が、品質も速度も安定します。ただし、社内に技術者がいて技術をそろえたい、既存のシステムと共通化したいなどの理由があれば、それを伝えたうえで相談してください。
Q. Next.jsとRuby on Rails、結局どちらが良いのですか？
どちらも幅広い用途に使える実績のある技術で、一方が絶対に優れているということはありません。利用者が触る画面の使い心地をどれだけ重視するか、管理機能がどれだけ多いか、誰が長く保守するか、開発会社がどちらに慣れているかで判断します。この記事の観点に沿って、自社の条件を整理してください。
Q. ノーコードツールとフレームワークを使った開発は、どう使い分けますか？
標準的な機能の範囲で収まり、利用者や業務のルールが単純なら、ノーコードツールは有力な選択肢です。独自の業務ルール、複雑な権限、外部システムとの連携、利用者の増加への対応が必要になると、フレームワークを使った開発の方が柔軟に対応できます。
Q. 今使っているシステムの技術が古いと言われました。すぐに作り直すべきですか？
すぐに作り直す必要があるとは限りません。セキュリティの更新が受けられるか、扱える技術者を確保できるか、今後の機能追加に支障があるかを確認し、作り直しの費用と比べて判断します。
Otsumuに相談できること
開発会社の提案に対して、この記事の確認手順で質問し、納得できる説明が得られたなら、その提案をもとに自社で判断して進めて問題ありません。技術の選択で迷う時間を、何を作るか、どう使ってもらうかの検討に回す方が、事業にとって効果的なことも多いです。
一方で、複数の開発会社から異なる技術の提案があり、どれも説得力があって決められない場合や、将来の内製化や事業の拡大まで見据えた判断に自信が持てない場合、すでに作られたシステムの技術が古く、保守を続けるか作り直すかを判断したい場合は、特定の技術に偏らない第三者の意見が役に立ちます。
Otsumuは、目的と事業の段階から逆算して、技術の選択も含めて提案しています。AIを活用した少人数・短期間の開発で、最初の版を早く形にしながら、公開後の保守や内製化への引き継ぎまで見据えた進め方を大切にしています。Webアプリの開発はWebアプリ開発、開発全般はシステム開発、新規事業の最初の版は新規事業の爆速MVPシステム開発をご覧ください。
お手元の提案書を見ながら、技術の選択が自社の条件に合っているかを一緒に確認することもできます。まずは30分の無料相談でお気軽にご相談ください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01