バックエンドとは？サーバー・DB・APIの全体像をわかりやすく解説

バックエンドとは、Webアプリケーションの「裏側」で動くサーバー・データベース・APIの総称です。ブラウザから届いたリクエストを受け取り、データを保存・取得・加工して、レスポンスとして返すまでの処理を担当します。ユーザーの画面には映りませんが、ログイン・検索・購入といった「データが動く機能」はすべてバックエンドが実行しています。

この記事では、バックエンドの役割・構成要素・主要言語の選び方・セキュリティの基本までを一記事で解説します。加えて、Node.js + Express の最小APIサーバーをゼロから起動して動作確認するまでを通しで扱います。読み終えたときに「概念はわかったが手元では何も動いていない」状態にならないことを目標にしています。

掲載しているコードとコマンドは、Node.js v23.9.0 / npm 10.9.2 / Express 5.2.1 の環境で実際に実行し、レスポンスのステータスコードとContent-Typeまで確認したものです。

バックエンドとは何か

Webアプリケーションは「フロントエンド」と「バックエンド」の2層で構成されています。フロントエンドはユーザーが直接触れるUI（画面）の部分。バックエンドはその裏側で、データの保存・処理・配信を行う部分です。

たとえばECサイトで商品を検索すると、ブラウザがサーバーにリクエストを送り、サーバーがデータベースから商品データを取得し、JSONとしてブラウザに返します。この「リクエストを受けてからレスポンスを返すまで」がバックエンドの仕事です。

バックエンドが担当する5つの領域

「バックエンド」と一言でいっても、実際には次の5領域を指しています。求人票やスクールのカリキュラムに並ぶ用語も、ほぼこの5つのどれかに分類できます。

• サーバー処理 — リクエストの受信、URLごとの振り分け（ルーティング）、レスポンスの生成
• データベース — ユーザー情報・記事データ・注文履歴の保存と取得
• 認証・認可 — ログイン、セッション管理、「誰が何にアクセスしてよいか」の制御
• API設計 — フロントエンドやモバイルアプリとデータをやり取りする窓口の設計
• 外部サービス連携 — メール送信、決済処理、ファイルストレージなどの呼び出し

この5領域のうち、最初に手を動かすべきなのは1番目の「サーバー処理」です。リクエストを受けてレスポンスを返す最小の形さえ動けば、残りの4つはそこに機能を足していく作業になります。本記事の後半では、その最小の形を実際に起動します。

フロントエンドとバックエンドの違い

フロントエンドとバックエンドの境界は「HTTPリクエスト」です。ブラウザがサーバーにリクエストを送った瞬間、処理はフロントエンドからバックエンドに移ります。逆にレスポンスが返った瞬間、処理はフロントエンドに戻ります。

リクエストからレスポンスまでの5ステップ

ユーザー一覧を表示する画面を例に、処理がどこを通るかを順番に追います。「どの主体が」「何をして」「次に何を渡すか」の3点で見ると、責務の境界がはっきりします。

バックエンドが登場するのは2と4だけです。「サーバーサイドの処理」と言われると広大に感じますが、実体は受け取って、探して、整えて、返すの4動作に集約されます。

責務の比較

特に重要なのは「コードの秘匿性」の行です。フロントエンドのコードは開発者ツールで誰でも読めるため、APIキーや権限チェックをフロントに置くことはできません。これがセキュリティ責任がバックエンドに寄る理由です。

HTTPの基礎 — リクエストとレスポンス

バックエンドを理解するうえで避けて通れないのがHTTPです。Web上の通信は、クライアント（ブラウザやアプリ）がHTTPリクエストを送り、サーバーがHTTPレスポンスを返すことで成り立っています。HTTPの意味論（メソッドやステータスコードが何を表すか）は RFC 9110「HTTP Semantics」 で規定されています。

HTTPメソッド

メソッドは「そのリクエストで何をしたいか」を表します。各メソッドの定義は MDN「HTTP リクエストメソッド」 にまとまっています。

GETは何度実行しても結果が変わらない（安全・べき等）のに対し、POSTは実行するたびにデータが増えます。「リロードで二重登録される」不具合の多くは、この区別を無視した設計から生まれます。

ステータスコード

サーバーは処理結果を3桁のステータスコードで返します。開発中に頻繁に目にするものを押さえておきましょう。全コードの一覧と正式な意味は MDN「HTTP レスポンスステータスコード」 で確認できます。

401と403の混同は実務でも頻出です。401は「あなたが誰かわからない」、403は「あなたが誰かはわかるが、それは許可されていない」と覚えると取り違えません。この記事の後半では、実際にサーバーを起動して200・201・400・404の4つを自分の手で発生させます。

データベースの役割

バックエンドの中核にあるのがデータベースです。サーバーのプロセスは再起動すればメモリ上のデータを失いますが、データベースに書いたデータは残ります。この「永続化」がデータベースの存在理由です。

RDB（リレーショナルデータベース）

テーブル（表）形式でデータを管理し、SQLで操作します。列の型や制約をあらかじめ決めるためデータの整合性が高く、Webアプリで最も広く使われている方式です。

なお「MySQLがシェアNo.1」という説明を見かけることがありますが、公開されている指標で確認する限り断定はできません。DB-Engines Ranking（434製品が対象・2026年7月時点）の総合順位は1位 Oracle、2位 MySQL、3位 Microsoft SQL Server、4位 PostgreSQLで、MySQLは2位です。またこのランキングは求人数・検索頻度・技術系フォーラムでの言及数などから算出した「人気度スコア」であり、実際の稼働数やシェアそのものを測ったものではありません。DBを選ぶときは順位ではなく、後述の用途との相性で決めてください。

NoSQL

テーブル構造に縛られない柔軟なデータ格納方式です。大量データの高速処理や、スキーマが頻繁に変わるケースに向いています。

学習の順序としては、まずRDB（SQLiteまたはPostgreSQL）から始めるのが王道です。SQLの基本が身につけばNoSQLの理解もスムーズに進みます。PHPとMySQLで登録・取得・更新・削除を一通り書く手順は PHPでMySQLを操作する方法｜PDOでCRUDを実装する で、あいまい検索の実装は PHP×MySQLで検索機能を作る方法 で追えます。SQLiteをアプリに組み込む例は SQLiteで履歴を管理するElectron製クリップボードアプリ が参考になります。

バックエンド言語の選び方

バックエンド開発には複数の言語が使われています。「どれが最強か」ではなく、自分の目的と環境に合った言語を選ぶことが重要です。ルーティング・ミドルウェア・ORM・認証といった概念は言語をまたいで共通なので、1つを深く学べば移行のコストは小さくなります。

主要言語の比較と選ぶ理由

フロントエンド側のフレームワークとの関係を整理したい場合は React.js・Vue.js・Node.jsの違いとは？特徴・用途・選び方を徹底比較 も合わせて読むと、どこまでがフロントでどこからがバックエンドかの線引きがはっきりします。

最小構成のAPIサーバーを起動する（Node.js + Express）

ここからは実際に手を動かします。以下の手順をそのまま実行すれば、GET /api/users に応答するAPIサーバーが立ち上がります。必要なのは Node.js がインストール済みであることだけです。

手順1: プロジェクトを作り、Expressを入れる

mkdir my-api
cd my-api
npm init -y
npm install express
npm pkg set type=module

最後の npm pkg set type=module が省略できない一行です。npm init -y が生成する package.json には type フィールドが無く、その状態で import 構文を書いたファイルを実行すると、Node.js はそのファイルをCommonJSとして読もうとして次のエラーで停止します。

SyntaxError: Cannot use import statement outside a module

コマンドを実行すると package.json に次の行が加わります。手で書き足しても結果は同じです。type フィールドの詳細は Node.js公式ドキュメント「Modules: Packages」 にあります。

{
  "name": "my-api",
  "type": "module",
  "dependencies": {
    "express": "^5.2.1"
  }
}

手順2: server.js を作る

import express from 'express'

const app = express()
app.use(express.json())

let users = [
  { id: 1, name: '田中太郎', email: 'tanaka@example.com' },
  { id: 2, name: '佐藤花子', email: 'sato@example.com' },
]

// 一覧を返す
app.get('/api/users', (_req, res) => {
  res.json(users)
})

// 新規作成する
app.post('/api/users', (req, res) => {
  const { name, email } = req.body ?? {}
  if (!name || !email) {
    return res.status(400).json({ error: 'name と email は必須です' })
  }
  const created = { id: users.length + 1, name, email }
  users = [...users, created]
  res.status(201).json(created)
})

app.listen(3000, () => {
  console.log('Server running on http://localhost:3000')
})

手順3: 起動する

node server.js
# => Server running on http://localhost:3000

40行足らずで、一覧取得と新規作成の2つのエンドポイントを持つAPIサーバーが動きます。バックエンドの本質は、このように「リクエストを受けてデータを返す」処理の積み重ねです。起動できたら、この記事の後半にある検証セクションで動作を確認してください。「起動メッセージが出た＝正しく動いている」とは限らないためです。

なお 3000 番ポートを別のアプリ（Next.jsの開発サーバーなど）が使っていると、起動に失敗して Error: listen EADDRINUSE: address already in use :::3000 が出ます。その場合は app.listen(3001, ...) のように空いている番号へ変更してください。

API設計の基本 — RESTとは

バックエンドが提供するAPIの設計パターンとして最も広く使われているのがREST（Representational State Transfer）です。リソース（データ）をURLで表現し、HTTPメソッドで操作するという考え方で、URLが名詞、HTTPメソッドが動詞という対応が基本原則です。

REST APIの設計例

URLは同じ /api/users でも、GETなら一覧取得、POSTなら作成と処理が変わります。先ほど作った server.js はこの表の1行目と3行目を実装したものです。この規約に従うことで、APIの使い方が初見でも推測できるようになります。

REST以外のAPI設計パターン

まずはRESTを確実に理解し、必要になった段階でGraphQLやWebSocketへ広げるのが実務的な進め方です。RESTのAPIを実サービスに組み込んだ例としては FAQチャットウィジェットを自作する方法【Next.js×Cloudflare D1】 が、本記事の概念（ルーティング・DB・JSONレスポンス）がそのまま実装に落ちる様子を追える題材になっています。

セキュリティの基本

バックエンドはデータベースに直接アクセスできるため、セキュリティの責任が最も重い層です。クライアント側のバリデーションはUXのためのもので、セキュリティ対策にはなりません。ブラウザから送られてくる値はすべて改ざんされ得ると考え、検証はバックエンド側で必ず行います。

主要な脅威と対策

SQLインジェクション対策の具体的な書き方は OWASP「SQL Injection Prevention Cheat Sheet」 が言語別にまとまっていて実装時の参照先として便利です。PHPとセッションで実際にログイン機能を組む手順は PHPログイン機能の作り方｜セッションとpassword_hashで安全に実装する手順 にまとめています。

OWASP Top 10 で全体像を押さえる

個別の対策を覚える前に、まず「何が重大リスクとされているか」の全体像を押さえると学習効率が上がります。その標準的な指標が OWASP Top 10 です。最新版は2025年版で、上位は次のように整理されています。

注目したいのは、長年1位だったインジェクション系がA05に下がり、アクセス制御の不備（A01）が最上位になっている点です。「SQLを安全に書く」より「そのユーザーがそのデータを見てよいかを毎回サーバーで確かめる」ほうが、いま優先度の高い課題だということです。トークンをブラウザのどこに保存するかという判断も同じ文脈にあり、localStorageにJWTを保存すべきか で具体的なトレードオフを整理しています。

学習ロードマップ

バックエンドを体系的に学ぶための5ステップです。各ステップには、そのまま手を動かせる記事を対応させてあります。上から順に潰していけば、概念だけで終わらずに動くものが残ります。

Step 1: 全体像を理解する（この記事）

HTTP・サーバー・データベース・APIの関係を把握します。この記事の「リクエストからレスポンスまでの5ステップ」の表を、見ないで説明できれば合格です。到達の確認は後半の検証セクションで行います。

Step 2: 言語を選んでAPIサーバーを作る

本記事のExpress最小構成が出発点です。そこからサーバーサイドJavaScriptの基礎体力を付けるなら Node.js練習問題集【基礎API編】 で、fs・path・イベントループといったブラウザには無いAPIを解答付きの演習で埋められます。JavaScript自体の土台が不安なら JavaScript学習ガイド から入るほうが結果的に早く進みます。

Step 3: データベースと接続する

メモリ上の配列をデータベースに置き換え、再起動してもデータが消えない状態にします。登録・取得・更新・削除の4操作を実際に書く手順は PHPでMySQLを操作する方法｜PDOでCRUDを実装する が具体的です。PHPが対象ですが、プレースホルダで値を渡す考え方はどの言語でも共通で、そのまま応用できます。

Step 4: 認証を実装する

パスワードのハッシュ化とセッション管理で「ログイン」の裏側を理解します。PHPログイン機能の作り方 でセッション方式を一通り作り、トークン方式との違いは localStorageにJWTを保存すべきか で押さえる、という順序が理解しやすい流れです。

Step 5: デプロイして公開する

手元で動くものを、他人がアクセスできる場所に置きます。環境差をなくすコンテナの考え方は Dockerとは？初心者でもわかる仮想コンテナ技術の基礎と使い方 で、置き場所そのものの選び方は ポートフォリオ公開するためのレンタルサーバーの選び方 で判断できます。クラウド上に自分でサーバーを立てる手順を踏みたい場合は AWS LightsailでWordPressを構築する手順 が、SSH接続やファイアウォール設定まで含めた実地の練習になります。

よくある質問

Q. バックエンドの学習にどのくらい時間がかかる？

プログラミング経験があれば、本記事のような最小APIサーバーを動かすまでは数時間から1週間程度です。データベース接続と認証まで含めると1〜2ヶ月が目安になります。HTTPとJSONの概念を理解していればさらに短縮できます。

Q. 最初に学ぶ言語はどれがいい？

JavaScriptに慣れているならNode.js、AIやデータ分析にも興味があるならPython、WordPress案件を扱うならPHPが入口として素直です。ルーティング・ミドルウェア・ORM・認証といった概念は言語を超えて共通なので、1つを深く学べば他への移行は難しくありません。

Q. フルスタックエンジニアとは？

フロントエンドとバックエンドの両方を実装できるエンジニアのことです。「両方完璧」を求められるわけではなく、「一方が得意で、もう一方も対応できる」レベルが現実的なフルスタックです。職種ごとの役割の違いは Webデザイナー？エンジニア？ディレクター？職種と作れるものを徹底解説 で整理しています。

Q. フレームワークなしでもAPIサーバーは作れる？

作れます。Node.jsの http モジュール、Pythonの http.server、Goの net/http など、標準ライブラリだけでHTTPサーバーは構築できます。ただし実務では、ルーティングやミドルウェアの仕組みを提供するフレームワークを使うのが一般的です。

Q. RESTとGraphQLはどちらを先に学ぶべき？

RESTが先です。GraphQLもHTTPの上で動くため、メソッド・ステータスコード・認証ヘッダーといったRESTで学ぶ土台がそのまま必要になります。RESTで不便を感じた経験がないと、GraphQLが何を解決しているのかも理解しづらくなります。

Q. ローカルで動いたのに公開したら動かないのはなぜ？

多くはポート・環境変数・データベース接続先の3つのどれかが本番環境と食い違っているためです。ローカルの localhost:3000 はサーバー上には存在せず、接続情報もローカル用のままでは通りません。この差をなくす手段としてDockerによるコンテナ化が使われます。

Q. WordPress開発はバックエンド経験に含まれる？

含まれます。WordPress開発ではPHP・MySQL・REST API・セキュリティ対策など、バックエンドの要素を実務レベルで扱います。ただしWordPress固有の仕組み（フック、テンプレート階層など）と一般的なバックエンドの設計パターンは別物なので、両方の経験があると強みになります。

【検証】作ったAPIが本当に動いているかを確認する

ターミナルに「Server running on http://localhost:3000」と出ても、それはプロセスが起動したことしか意味しません。ルートが正しく定義されているか、期待した形式で返せているかは別問題です。ここでは3つの検証を行い、それぞれ観測できる合否ラインを置きます。サーバーは起動したまま、別のターミナルを開いて実行してください。

検証A: 起動してレスポンスを返せているか

次の2つのコマンドを実行します。1つ目はポートを掴んでいるプロセスの確認、2つ目はレスポンスのステータスとContent-Typeの確認です（Windowsの場合、1つ目は netstat -ano | findstr :3000 に読み替えてください）。

lsof -nP -iTCP:3000 -sTCP:LISTEN

curl -s -o /dev/null -w 'code=%{http_code} type=%{content_type}\n' \
  http://localhost:3000/api/users

curl -s http://localhost:3000/api/users

合否ラインは次の4つです。4つすべてがOKで初めて「動いている」と判断します。

A-3は見落としやすい項目です。ブラウザで開くと同じように文字列が表示されるため、Content-Typeが text/html のままでも気づけません。フロントエンド側で response.json() が失敗して初めて発覚する、という順序で問題化します。

検証B: 存在しないパスが404になるか

次はわざと失敗させます。定義していないパスを叩いてください。

curl -s -o /dev/null -w 'code=%{http_code}\n' \
  http://localhost:3000/api/unknown

curl -s http://localhost:3000/api/unknown
# => Cannot GET /api/unknown を含むHTMLが返る

この検証で体感してほしいのは、「サーバーが動いている」と「ルートが定義されている」は別の話だということです。404が返ったなら、サーバーは起動していてリクエストも受け取れており、単に該当するルートが無いだけです。一方で curl: (7) Failed to connect のような接続エラーが出た場合は、そもそもプロセスが立っていないかポート番号が違います。404はサーバー側の問題、接続エラーは起動側の問題——この切り分けができると、デバッグの初手を間違えなくなります。

検証C: ブラウザのDevToolsで自分で確認する

最後は、curlを使わずブラウザだけで同じことを読み取る練習です。実務では他人が作ったAPIの挙動を調べる場面が多く、この読み方がそのまま使えます。

1. ブラウザで開発者ツールを開く（Windowsは F12、macOSは Command + Option + I）
2. 「Network」タブを選び、開いた状態のまま http://localhost:3000/api/users にアクセスする
3. 一覧に現れた users の行をクリックし、「Headers」を開く

C-4は地味ですが有用です。X-Powered-By: Express が出ていれば、応答したのは間違いなく自分が起動したExpressです。別のアプリが同じポートを使っていた場合、ここに別の値が入るか、そもそも項目が現れません。「たしかに繋がっているのに、直したはずの変更が反映されない」というときは、まずこのヘッダーを見ると原因の切り分けが早くなります。

検証はここで止めます。A・B・Cが通っていれば「リクエストを受けてレスポンスを返す」という本記事の主題は手元で再現できています。この先の負荷試験や自動テストは、データベース接続（Step 3）まで進んでから取り組むほうが学習効率が高くなります。

まとめ

バックエンドは「サーバー・データベース・API」の3つで構成され、その役割を一言でいえばデータを安全に保存し、必要な形で提供することです。

• HTTPがフロントエンドとバックエンドの境界であり、共通の会話ルール
• データベースがアプリケーションのデータを永続化する
• REST APIは「URLが名詞、メソッドが動詞」で読み解ける
• セキュリティはバックエンドの責務。最新のOWASP Top 10ではアクセス制御の不備が最上位
• 概念は言語を超えて共通なので、1つ学べば応用が効く

読むだけで終わらせないために、この記事を閉じる前にExpress最小構成を起動して検証A・B・Cを通すところまでやってしまうことをおすすめします。所要時間は10分ほどで、そこまで進めば学習ロードマップのStep 2は半分終わっています。続きは Node.js練習問題集【基礎API編】 で、サーバーサイドJavaScript特有のAPIを演習形式で埋めていってください。