フロントエンドとバックエンドの違い【2026年版】境界はAPI、発注時の体制と見積もりはこう分かれる

「見積書に『フロントエンド開発』と『バックエンド開発』が別々に並んでいるが、この2つは何が違うのか」——開発を発注する立場の方から、こうした相談をよく受けます。検索しても出てくるのはエンジニアを目指す人向けの記事ばかりで、年収の比較やどちらを勉強すべきかという話が続く。知りたいのはそこではなく、自社が払う金額と組む体制の話なのに、その視点で書かれた説明が見つからないままです。

結論から言うと、フロントエンドは利用者が見て操作する画面側、バックエンドは受け取ったデータを処理して保存し、求められたときに返すサーバー側です。どちらが上ということはなく、単なる分担です。そして両者の境界にはAPIという取り決めがあり、この線がどこに引かれているかが、担当の切れ目であり、見積もりの項目の切れ目であり、責任の切れ目になります。

この境界が見えると、発注実務の景色が変わります。見積書の2項目がなぜ別々に積まれているのかが説明でき、体制表に並ぶ職種の意味が分かり、「画面だけ別の会社に頼めないか」という問いにも自分で当たりをつけられるようになります。用語の暗記ではなく、判断の道具として使えるのがこの区分です。

本記事では、フロントエンドとバックエンドの定義と境界、それぞれが担う処理と代表的な言語・フレームワークの位置づけ、フルスタックエンジニアという言葉が指す範囲、発注者にとっての意味(見積もりが分かれる理由・体制の組み方・どちらの人材が不足しやすいか・片方だけ外注できるか)、当社の体制、よくある質問の順に解説します。技術そのものの詳しい説明はしません。非エンジニアの発注担当が、社内説明と発注判断に使える粒度でまとめました。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。その中で多いのが「画面だけ安いところに頼めないか」という質問です。答えは案件によって変わりますが、判断の軸は共通していて、それはやはり境界がどこにあるかという一点に尽きます。この記事を読み終えるころには、自社の見積書と体制表を、根拠を持って読めるようになっているはずです。

フロントエンドとバックエンドの違い——画面側とサーバー側。優劣ではなく分担

この2つの言葉は、Webサービスや業務システムを2つの側に分けて呼ぶための区分です。まずはそれぞれの定義を押さえ、比較表で違いを並べ、最後に両者の境界がどこにあるのかを確認します。境界の位置が分かると、以降の見積もりや体制の話がすべて同じ地図の上に乗ります。

フロントエンド: 利用者への表示と操作の受け付けを担う側

本記事では、フロントエンドを「ソフトウェアやシステムの構成要素のうち、画面表示や入力・操作の受け付けなど、利用者が直接触れる部分」という意味で使います。JIS・ISO や公的機関の資料にこの語の定義規定は置かれていないため、記事の中で意味を決めておきます。

Webサービスの場合は、利用者のパソコンやスマートフォンのブラウザの中で動く部分がこれにあたります。ボタン、入力欄、一覧表、グラフ、画面の切り替え。利用者が「使っている」と感じているものは、ほぼすべてフロントエンドです。

注意したいのは、フロントエンドは「見た目」そのものではないという点です。どんな配置・配色にするかを決めるのはデザインの仕事で、それを実際に動く画面として組み立て、押したときに正しく反応するようにするのがフロントエンドの仕事です。

バックエンド: 受け取ったデータを処理・保存し、求められたら返す側

バックエンドは、同じく本記事では「利用者や他のシステムから見えないところで、データの処理や保存を行う部分」という意味で使います。フロントエンド側からデータや指示を受け取り、計算や変換を行い、ストレージやデータベースへの保存と読み出しを担う部分、と言い換えてもかまいません。

Webサービスの場合は、開発会社やクラウド事業者が用意したサーバーの中で動く部分がこれにあたります。ログインの認証、金額の計算、在庫の引き当て、申込内容の保存、他社サービスとの連携。利用者は一切目にしませんが、ここが止まればサービスは成立しません。

利用者の端末ではなくサーバーで動くという点が決定的で、だからこそバックエンドには、同時に多くの人が使っても壊れないこと、データが消えないこと、権限のない人に見せないことといった要求が集まります。

役割の比較表——見える/見えない、動く場所、変更が起きる理由

両者の違いを、発注者が気にする観点で並べると次のようになります。

飲食店に例えると分かりやすくなります。フロントエンドはホールで、メニューを見せ、注文を聞き、料理を運ぶ役割です。バックエンドは厨房で、注文を受けて調理し、食材を管理します。客はホールしか見ませんが、味を決めているのは厨房です。どちらが偉いという話ではなく、両方そろって初めて店が回ります。

境界はどこにあるか——APIという取り決めが担当と責任の切れ目になる

では、ホールと厨房の間には何があるのか。注文伝票にあたるものが、システムではAPIと呼ばれる取り決めです。画面側が「この条件に合うデータをください」「この内容で登録してください」と決められた形式で頼み、サーバー側が決められた形式で返す。この受け渡しのルールがAPIです。

発注実務でこの線が重要なのは、APIが担当の切れ目であり、責任の切れ目であり、そして多くの場合は見積もりの項目の切れ目でもあるからです。「画面は出るのにデータが出ない」という不具合が起きたとき、どちらの担当が直すのかは、この線のどちら側で問題が起きているかで決まります。

逆に、この線が曖昧なまま作られたシステムは、後から担当を分けることも、片方だけ別会社に頼むこともできません。ここが本記事の後半で扱う判断の土台になります。

それぞれが担う処理と、代表的な言語・フレームワークの位置づけ

ここからは、両者が実際に何をしているのかを具体的に見ていきます。あわせて、見積書や体制表、エンジニアの経歴書に出てくる技術名が「どちら側の道具か」を対応表にまとめます。技術そのものの解説は行いません。名前と役割の対応が分かれば、非エンジニアの発注担当としては十分です。

フロントエンドが担う処理——描画、入力の受け付け、送信、端末ごとの見え方

フロントエンドの仕事は、大きく4つに分けられます。

• 描画: サーバーから受け取ったデータを、一覧・グラフ・詳細画面といった形に組み立てて表示します。同じデータでも、どう見せるかはここで決まります
• 入力の受け付けと検証: 入力欄への文字、選択、ファイルの添付を受け取り、明らかな誤り(必須項目の空欄、形式の誤り)をその場で指摘します
• 送信と結果の反映: 入力内容をAPI経由でサーバーへ送り、返ってきた結果を画面に反映します。読み込み中の表示やエラーの出し方もここの担当です
• 端末ごとの見え方: パソコン、スマートフォン、タブレットで画面幅が違うため、それぞれで崩れないように調整します。この作業を軽く見積もると、リリース直前に足りなくなります

発注者の立場で覚えておきたいのは、入力検証がフロントエンドだけで完結してはいけないという点です。画面側のチェックは利用者への親切であって、防御にはなりません。同じ検証はサーバー側でも必ず行います。「二重で無駄では」と削らせるのは失敗のもとです。

バックエンドが担う処理——業務ルールの実行、データの保存と取り出し、外部サービスとの連携

バックエンドの仕事も、大きく4つに分けられます。

• 業務ルールの実行: 料金の計算、割引の適用、承認の順序、在庫の引き当て。「その会社ならではの決まりごと」はここに書かれます
• データの保存と取り出し: データベースに情報を格納し、必要な条件で取り出します。どこに何をどう持つかという設計が、後の変更しやすさを左右します
• 権限とセキュリティ: 誰がどの情報を見てよいかを判定します。画面に表示しないことと、データを渡さないことは別で、後者がバックエンドの責任です
• 外部サービスとの連携: 決済、メール送信、会計ソフト、地図、生成AIなど、他社のサービスを呼び出して結果を組み込みます

データの持ち方は後から変えるのが最も重い作業です。すでに本番で数万件の情報が入っている状態で構造を変えるとなると、移し替えの手順と検証が必要になります。設計工程でここに時間をかける理由はここにあり、設計で何を決めるかは『基本設計とは』の記事で詳しく扱っています。

代表的な技術の対応表——名前がどちら側の道具かだけ押さえる

見積書や経歴書に並ぶ技術名を、どちら側の道具かで整理します。細かい優劣は開発会社の判断に任せて構いません。

当社が手がけてきた案件でも、決済アプリ、LLMを組み込んだAIチャットボット、求人プラットフォーム、ヘッドレスCMSのWebサイトと分野は幅がありますが、どれもこの表の組み合わせで説明がつきます。言語の名前で開発会社を選ぶ必要はありません。見るべきは、その会社がその組み合わせで作り、運用し続けた実績があるかどうかです。

よくある誤解3つ——デザインとの違い、インフラとの違い、どちらが難しいか

最後に、発注の場で繰り返し出てくる誤解を3つ整理します。

1. フロントエンド=デザイン、ではありません。 デザイナーが画面の配置・配色・遷移を設計し、フロントエンドがそれを動く画面として実装します。デザイナーがいない案件では、フロントエンド担当が兼ねることもありますが、別の技能です
2. バックエンド=インフラ、ではありません。 サーバーやネットワークそのものを用意し、監視し、障害に備えるのがインフラの役割で、その上で動くプログラムを書くのがバックエンドです。小規模な体制では兼務されますが、責任範囲は別です
3. どちらが難しいかという比較に意味はありません。 難易度は案件の内容で決まります。同時に数万人が使う画面はフロントエンドが難しく、複雑な料金計算を持つシステムはバックエンドが難しい。優劣の議論に時間を使うより、自社の案件がどちらに寄っているかを見極めるほうが有益です

では、両方を1人で担う「フルスタックエンジニア」はどう位置づければよいのでしょうか。

フルスタックエンジニアとは——両方を1人で担える人材と、期待してよい範囲

体制の相談をしていると、必ず出てくるのがこの言葉です。「フルスタックの人を1人入れれば足りますか」という質問は、当社への相談でも頻出します。結論から言うと、規模によっては足りますし、規模が出れば足りません。その境目をどう見るかを整理します。

定義: 分業される複数分野を1人で担える技術者

本記事では、フルスタックエンジニアを「通常はそれぞれに専門の技術者がいて分業されるような複数の技術分野について知識や技能を持ち、一人でシステム開発や運用を担える技術者」という意味で使います。2010年代に広まった呼び方で、資格や公式の定義があるわけではありません。

Webサービスの場合、画面側のプログラミングとサーバー側のプログラミングに加え、データベースの設計、サーバーの導入と設定までを1人でこなす人物像が想定されています。ただし求められる技能の組み合わせは対象分野によって異なり、資格や公式の定義があるわけではありません。名乗り方に幅がある言葉だという点は、発注側として押さえておく必要があります。

この呼び方には両面があります。資金や事業規模に乏しく、分野ごとに専門家を用意するのが難しいスタートアップでは確かに重宝します。一方で、どの分野も中途半端な「器用貧乏」に陥る危険もあります。当社が発注のご相談を受けるときも、この両面を分けて確認するようにしています。

立ち上げ期に強く、規模が出ると分業が要る——切り替えの目安

1人で両側を持つ構成の最大の利点は、受け渡しが発生しないことです。画面を作る人とサーバーを作る人が分かれていると、「APIができるまで画面が進まない」「画面の要望が来ないとAPIの形が決まらない」という待ち時間が必ず生まれます。1人なら、その待ち時間はゼロになります。

当社の持論として、職種を細かく割るほど受け渡しの待ち時間が増えます。人数を増やしたのに進みが速くならない案件の多くは、作業量ではなく待ち時間が原因です。だから小さい規模では通しで持たせ、規模が出てから分けるという順番を勧めています。最初から分業前提で組むのは失敗のもとです。

切り替えの目安は、人数ではなく「同時に走る機能の本数」で見ます。

介護記録SaaS「CareViewer」の開発では、日本語で会話できるブリッジSE1名とフルスタック2名という構成を取りました。機能ごとに1人が画面からサーバーまで通しで担当するため、週次で優先順位を組み替えても手戻りが起きにくく、結果として従来の半分以下のコストで継続開発が回っています。

発注者が誤解しやすい3点——「1人で足りる」「全部が同水準」「引き継ぎも不要」

フルスタックという言葉をめぐって、発注側が損をしやすい誤解が3つあります。

1. 「1人いれば体制として足りる」——立ち上げ期は成立します。ただし1人体制は、その人が休んだ日に開発が止まり、退職すれば何も分からなくなる構成でもあります。人数の問題ではなく、事業継続の問題として要注意です
2. 「全分野が同じ水準でできる」——実際には得意な側があります。画面寄りのフルスタックとサーバー寄りのフルスタックでは、任せられる範囲が違います。面談では「直近1年でどちら側の作業に時間を使ったか」を聞くのが確実です
3. 「1人で完結しているから引き継ぎ資料は要らない」——逆です。1人で完結しているほど、頭の中にしかない情報が増えます。API仕様書とデータ構造の資料は、体制の大小にかかわらず成果物として求めてください

1人に集約した体制は、速度と引き換えに依存を抱えます。速いうちに、引き継げる形に整えておくこと。これが、フルスタック体制で最も費用対効果の高い投資です。

発注者にとっての意味——見積もりが分かれる理由、体制の組み方、片方だけ外注できるか

ここが本記事の中心です。フロントエンドとバックエンドという区分は、発注実務では3つの場面に効いてきます。見積書の読み方、体制の組み方、そして外注範囲の切り方です。順に見ていきます。

見積もりが画面側とサーバー側で分かれる理由——担当が違い、工数の数え方が違う

見積書で「フロントエンド開発」と「バックエンド開発」が別の行に積まれているのは、単に項目を細かくしているのではなく、性質の違う作業だからです。理由は3つあります。

理由1: 担当する人が違う。 多くの開発会社では、画面側とサーバー側で担当者が分かれています。担当が違えば、割り当てる人数と期間が別々に計算されるため、行も分かれます。

理由2: 工数の数え方が違う。 画面側は「画面数」で数えることが多く、サーバー側は「機能数」または「APIの本数」で数えるのが一般的です。単位が違うので、同じ1行に混ぜると根拠が示せません。工数という単位そのものの数え方は『工数とは』の記事で扱っています。

理由3: 変更が起きる理由が違う。 画面側は「見せ方を変えたい」で動き、サーバー側は「業務ルールが変わった」で動きます。契約後の追加費用がどちらに乗るかも変わるため、最初から分けて積んだほうが、後の交渉が明確になります。

一方で、「システム開発一式」とまとめた見積書も珍しくありません。どちらが正しいということはありませんが、比較するときは必ず同じ粒度に揃えてください。まとめてある会社には「画面側とサーバー側の内訳」を、分けてある会社には「両方を合算した総額と期間」を求めるだけで、3社を同じ土俵に並べられます。見積書の項目そのものの読み方は『システム開発の見積もりの内訳』の記事にまとめています。

体制の組み方3パターン——通しで持たせる/分ける/つなぎ役を置く

体制は、画面側とサーバー側をどう分担させるかで3つに整理できます。

当社が勧めているのはパターンCの考え方です。エンジニアだけの構成でも開発は進みますが、発注側に判断できる人がいない場合、決まらない仕様を抱えたまま人が待つ状態が最も高くつきます。日本人PMやブリッジSEを置く構成は、この待ち時間を買い取るための投資だと考えてください。体制図として誰をどう並べ、どこに線を引くかについては『プロジェクト体制図の書き方』の記事で詳しく扱っています。

どちらの人材が不足しやすいか——採用難易度と、外部で補うときの順番

「どちらの人材が採りにくいか」は、体制を決めるうえで避けて通れない問いです。傾向として、次のように整理できます。

• 入り口の人数はフロントエンドのほうが多い。 HTML・CSSから学び始められるため参入者が多く、経験の浅い層の供給は厚い傾向があります
• 一方で、設計までできるフロントエンドは少ない。 画面を部品として設計し、状態の持ち方まで判断できる層は薄く、単価も上がります
• バックエンドは参入障壁が高く、経験者の母数が少ない。 データベース設計、権限、性能、セキュリティと求められる範囲が広く、育つまでに時間がかかります
• 最も採りにくいのは、両側の橋渡しができる人。 仕様を決め、API設計を主導し、両担当に指示を出せる人材です。ここが埋まらないまま人数だけ増やすと、待ち時間が増えます

外部で補う順番としては、まず橋渡しができる役、次に不足している側の実装担当、という順が失敗しにくいと考えています。実装担当だけを先に増やすと、指示を出す側が詰まって手が空く時間が生まれるためです。職種別・契約形態別の単価の目安は『エンジニア単価の相場』の記事にまとめています。

片方だけ外注できるか——できる条件3つと、切り出したときのリスク

当社への相談で多いのが「画面だけ安いところに頼めないか」という質問です。答えは案件によりますが、判断の軸は共通していて、既存システムの境界がAPIとして整理されているかどうかの一点に集約されます。

切り出せる条件は3つです。

1. APIが独立している。 画面側がAPI経由でのみデータをやり取りしており、サーバー側の処理が画面のコードに混ざっていないこと
2. API仕様書がある。 どのURLに何を送ると何が返るかが文書化されていること。口頭でしか分からない状態では、引き継ぎに費用と時間がかかります
3. 検証できる環境がある。 本番とは別に、新しい画面から既存のサーバーへつないで試せる環境が用意できること

この3つが揃っていれば、画面側だけを別の会社に発注することは現実的です。逆に、画面の中に業務ルールが書かれているような古い作りの場合、境界を作る作業そのものに費用がかかります。「難しい」と言われたときは、営業上の理由なのか技術的な理由なのかを、この3点に沿って確認してください。

切り出したときのリスクも押さえておきます。最大のものは責任分界です。不具合が起きたときに「画面の会社」と「サーバーの会社」が互いを指し、原因の切り分けだけで日数が過ぎることがあります。これを避けるには、発注者側で一次受けを決めるか、つなぎ役を1人立てるしかありません。開発会社を分けたり乗り換えたりする場合に何を引き継ぐかは『開発会社の乗り換えと引き継ぎの進め方』の記事で整理しています。

自社の見積書と体制表を、この3つの視点で読み直してみるとどうでしょうか。境界がどこにあるのかを1つ確認するだけで、判断できることは想像以上に増えるはずです。

当社の体制——職種別にアサインし、規模に応じて分ける。向く案件・向かない案件

最後に、当社がフロントエンドとバックエンドをどう配置しているかをお伝えします。自社の売り込みになりますので、ここだけは立場のある話として読んでください。合わない案件についても正直に書きます。

2,000名以上の人財データベースから職種別にアサイン——フロント専任・バック専任・フルスタックの使い分け

当社は、ベトナムの2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から、職種を指定して直接アサインします。協力会社や人材紹介を経由しないため、仲介マージンは発生しません。

配置の考え方は、前章のパターンA・B・Cと同じです。同時に走る機能が少ないうちは通しで持てる人財を入れ、機能が増えてから画面側とサーバー側に分けます。実際の構成例は次のとおりです。

体制はパターンA(日本人PM/ブリッジSE+エンジニア・推奨)とパターンB(エンジニアのみ)の2つを用意しています。品質面では、日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックの3点を標準としており、AI活用開発体制とAWS認定11冠の実績があります。

費用と立ち上げ——公開単価、最小構成、1名から1か月単位で増減

単価は公開しています。実務3年目安で1,500USD(1USD=150円換算目安で約22.5万円)、5年で2,000USD、10年目安およびブリッジSEで3,000USDです。当社調べで市場相場の約1/2にあたります。職種による単価差は設けておらず、経験年数で決まります。フロントエンドだから安い、バックエンドだから高いという設定はしていません。

最小構成は、日本人PMがフロントに立ち、2〜3人月の体制で月額約80万円からです。1名から契約でき、開始まで最短2週間、増員は約1週間、縮小や交代(リプレイスメント)は1か月単位で対応します。流れは、打ち合わせ→アサイン(約1週間)→候補者面談(約1週間)→開始です。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。

向く案件・向かない案件

向く案件は、継続的に機能を足していくWebサービスや業務システムです。画面とサーバーの両方に手が入り続ける案件では、通しで持てる人財を置く構成が効きます。決済アプリ、AIチャットボット、求人プラットフォーム、ヘッドレスCMSのWebサイトなど、当社が手がけてきたのはこの型の案件です。

向かないのは2つです。要件が完全に確定した単発の小規模開発は、通しで持つ体制の利点が出ないため、国内の請負契約のほうが向きます。組込みソフトウェアやハードウェア制御は、当社の主たる領域ではありません。

自社の案件は、通しで持たせる型でしょうか。それとも分けたほうが速い規模まで来ているでしょうか。

フロントエンドとバックエンドの違いに関するよくある質問

フロントエンドとバックエンドについて、発注の相談の場で繰り返し聞かれる質問を5つにまとめました。社内説明の補足にもお使いください。

Q1. フロントエンドとバックエンドでは、どちらが難しいのですか?

案件によります。同時に多くの人が使い、画面の作り込みが細かいサービスではフロントエンドが難しく、複雑な料金計算や大量のデータを扱うシステムではバックエンドが難しくなります。職種としての優劣ではなく、自社の案件がどちら側に重心があるかで人の配分を決めてください。

Q2. バックエンドエンジニアとインフラエンジニアは何が違いますか?

担当する層が違います。インフラエンジニアはサーバーやネットワークそのものを用意し、監視し、障害に備えます。バックエンドエンジニアはその上で動くプログラムを書きます。小規模な体制では1人が兼務することも多いのですが、責任範囲としては別のものです。体制表を見るときは、どちらの作業が誰に割り当てられているかを確認してください。

Q3. デザイナーとフロントエンドエンジニアの境界はどこですか?

画面の配置・配色・遷移を決めるのがデザイナー、それを動く画面として実装するのがフロントエンドエンジニアです。デザイナーが不在の案件では、フロントエンド担当が兼ねることもありますが、その場合は意匠の品質を期待しすぎないほうが無難です。意匠が価値の中心となる案件では、デザインを先に固めてから実装に入る進め方をお勧めします。

Q4. フルスタックエンジニア1人に任せれば、体制として足りますか?

同時に進む機能が1〜2本のうちは足ります。3本以上が並行し、利用者数やデータ量が増えてきた段階で、画面側とサーバー側を分ける検討時期です。ただし1人体制は、その人が離れたときに開発が止まる構成でもあります。人数の多寡にかかわらず、API仕様書とデータ構造の資料は成果物として必ず受け取ってください。

Q5. 画面側だけを、後から別の会社に頼めますか?

3つの条件が揃えば可能です。APIが独立していること、API仕様書があること、本番とは別に接続を試せる環境があること。この3つが揃っていない場合、境界を作る作業から始まるため、想定より費用がかかります。実行する場合は、不具合の原因の切り分けで揉めないよう、発注者側で一次受けを決めるか、つなぎ役を1人立てるのが前提条件。

まとめ: フロントエンドとバックエンドは優劣ではなく分担——境界を確認すれば、体制も見積もりも読める

フロントエンドは利用者が見て操作する画面側、バックエンドは受け取ったデータを処理して保存し、求められたときに返すサーバー側です。動く場所が端末とサーバーで分かれており、変更が起きる理由も違うため、担当が分かれます。両者の間にはAPIという受け渡しの取り決めがあり、この線が担当の切れ目であり、責任の切れ目であり、多くの場合は見積もりの項目の切れ目にもなります。

発注実務でこの区分が効くのは3つの場面です。見積書で画面側とサーバー側が別項目になる理由が分かれば、粒度の違う複数社の見積もりを同じ土俵に並べられます。体制は「通しで持たせる」「側で分ける」「つなぎ役を置く」の3パターンで整理でき、同時に走る機能が1〜2本のうちは通しで持たせ、3本以上になったら分けるのが目安です。そして片方だけの外注は、APIが独立していること、仕様書があること、接続を試せる環境があることの3条件が揃えば現実的で、揃っていなければ境界を作る作業から費用が発生します。フルスタックエンジニアは立ち上げ期に強い構成ですが、1人体制は事業継続のリスクを抱えます。速いうちに引き継げる形へ整えてください。

境界の位置が見えたら、次は体制と金額の各論です。誰をどこに置き、どこに線を引くかはプロジェクト体制図の書き方、見積書の項目をどう読み、どう比較するかはシステム開発の見積もりの内訳をあわせてご覧ください。開発体制をご検討中であれば、現在の体制と要件をお聞かせいただければ、通しで持たせる型か分ける型かの判断と、職種別の構成案・概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。要件が固まった単発の小規模開発であれば、国内の請負契約をお勧めします。