NoSQLとリレーショナルDB（RDB）の基本的な違い
リレーショナルDB（RDB、Relational Database）は、データを行と列から成る表（テーブル）形式で表すデータベースのモデルです。1970年代にIBMのエドガー・コッドが提唱したリレーショナルモデルを基盤とし、SQLという標準問い合わせ言語で操作します。MySQL・PostgreSQL・Oracle Databaseが代表的な製品として知られています。
NoSQLは「Not Only SQL」（SQLに限らない）と説明されることが多いですが、これは後付けの解釈で、現代の試験対策としてはこの説明で覚えるのが一般的です。リレーショナルDBのテーブル構造に縛られない多様なデータモデルを持つデータベースの総称で、2000年代後半、インターネットサービスの急成長に伴う大規模データ処理の必要性から普及しました。「SQLを一切使わない」という意味ではありません。
下表で主要な違いを整理します。
| 比較項目 | リレーショナルDB（RDB） | NoSQL |
|---|---|---|
| データ構造 | 行と列のテーブル（固定スキーマ） | 多様（キーバリュー・ドキュメント・グラフ等） |
| スキーマ | 事前定義が必須 | スキーマレス（後から変更可能） |
| 問い合わせ言語 | SQL（標準化されている） | 製品ごとに異なる（一部SQLライク） |
| トランザクション | ACID特性を厳密に保証 | 製品による（BASE原則が多い） |
| スケール方式 | 垂直スケールが基本（スケールアップ） | 水平スケールに強い（スケールアウト） |
| 得意な処理 | 複雑なJOIN・集計クエリ | 大量データの高速読み書き |
| 代表製品 | MySQL・PostgreSQL・Oracle Database | Redis・MongoDB・Cassandra・Neo4j |
試験対策ポイント: ITパスポート試験では「データを行と列から成る表形式で表すデータベースのモデル」という問い文がそのままリレーショナルDBの定義として出題されます。この表現を見たらリレーショナルモデル（RDB）と即答できるようにしておきましょう。
リレーショナルDBの特徴と代表製品
リレーショナルDBの最大の強みはACID特性（Atomicity・Consistency・Isolation・Durability）による高い整合性の保証です。複数のテーブルをJOINで結合する複雑な問い合わせが得意で、財務・会計・在庫管理といった「データの正確さが最優先」の業務に適しています。
ACID特性とは
ACID特性はトランザクション処理の信頼性を保証する4つの性質です。Atomicity（原子性）はトランザクション全体が成功するかすべて失敗するかという「全か無か」の保証、Consistency（一貫性）はデータが常に矛盾のない状態を保つこと、Isolation（独立性）は複数のトランザクションが互いに干渉しないこと、Durability（耐久性）はコミット済みデータが障害後も失われないことを指します。
銀行振込を例にすると、「A口座から1万円引く」と「B口座に1万円足す」の2操作はセットで成功するか、どちらも実行されないかの二択でなければなりません。この一貫性の保証がACID特性です。
リレーショナルDBの代表製品
- MySQL: オープンソースで世界最多利用。Webアプリの定番。現在はOracle社が管理
- PostgreSQL: 高機能・拡張性の高いオープンソースRDB。JSONなど非構造化データも一部サポート
- Oracle Database: エンタープライズ向けの有償製品。金融・公共機関での採用が多い
- Microsoft SQL Server: Windows環境・Microsoft製品との親和性が高いエンタープライズRDB
- SQLite: サーバー不要の軽量RDB。モバイルアプリや組み込みシステムで使用
NoSQLの4つの分類と特徴
NoSQLは「NoSQL」という単一の技術ではなく、データモデルによって大きく4種類に分類されます。試験でも実務でも、この4分類を「どのデータモデルか」「どのユースケースに向くか」とセットで覚えることが重要です。
1. キーバリュー型（Key-Value Store）
構造: データを「キー」と「値（バリュー）」のペアで管理します。辞書や連想配列に近い概念です。
強み: 構造が極めてシンプルなため、キーを指定して値を取得する操作が超高速です。データベースの中で最も低レイテンシーを実現できる方式の一つです。
弱み: キーを指定しないと値を取得できません。値の内部構造を問い合わせる（「値の中のフィールドAが○○のデータを探す」）ことが苦手です。
主な用途: Webセッション情報の管理、ログインユーザーのキャッシュ、ゲームのスコアランキング、ショッピングカートの一時保存
代表製品: Redis（レディス）、Amazon DynamoDB（シンプルなキーバリュー利用時）、Memcached
2. ドキュメント型（Document Store）
構造: データをJSON・XML・BSONなどの「ドキュメント」単位で格納します。1件のドキュメントが1つのデータ（例：1人のユーザー情報）に対応します。
強み: スキーマが固定されていないため、ドキュメントごとに異なるフィールドを持てます。ドキュメント内のフィールドを指定した問い合わせや絞り込みも可能です。
弱み: 複数のドキュメントをまたぐJOINが苦手です。リレーショナルDBのように複数テーブルの結合が必要な設計は向きません。
主な用途: ECサイトの商品カタログ（商品ごとに属性が異なる）、SNSのユーザープロフィール、ブログCMSのコンテンツ管理
代表製品: MongoDB（モンゴDB）、Amazon DocumentDB、Couchbase
3. カラム指向型（Wide-Column Store）
構造: データを列（カラム）単位で格納します。リレーショナルDBは行単位でデータを格納しますが、カラム指向型は列単位で格納することで、特定の列を大量に読み込む集計処理を高速化します。
強み: 大量の時系列データや分析クエリに強く、データの書き込みスループットも高いです。数百台のサーバーへの水平スケールアウトが容易です。
弱み: 複雑なクエリ（トランザクションを伴う複数行の更新等）は苦手です。スキーマ設計がアクセスパターンに依存するため、設計が難しい面があります。
主な用途: IoTデバイスのセンサーログ、ユーザー行動ログ・アクセスログの大量蓄積と分析、時系列データの保存
代表製品: Apache Cassandra（カサンドラ）、Google Bigtable、HBase
4. グラフ型（Graph Database）
構造: データを「ノード（点）」と「エッジ（ノード間をつなぐ線）」で表現します。人・物・場所といったエンティティがノード、「友人である」「購入した」「所属する」といった関係性がエッジです。
強み: データ同士の複雑な関係性（グラフ）を高速に探索できます。リレーショナルDBでは深い階層のJOINが必要になる処理を、ノードを辿るだけで実現できます。
弱み: 関係性を必要としないシンプルなデータ管理には向きません。リレーショナルDBやキーバリュー型に比べて普及度・エンジニアの習熟度が低い傾向があります。
主な用途: SNSの友人関係ネットワーク・フォロー関係、商品レコメンデーション（「この商品を買った人はこれも買っています」）、不正取引の検知
代表製品: Neo4j（ネオフォージェイ）、Amazon Neptune
NoSQLの4分類まとめ表
4分類の特徴・ユースケース・代表製品を横断比較します。
| 種類 | データ構造 | 強み | 主なユースケース | 代表製品 |
|---|---|---|---|---|
| キーバリュー型 | キーと値のペア | 超高速な読み書き | セッション管理・キャッシュ・ランキング | Redis、Amazon DynamoDB（シンプル利用時） |
| ドキュメント型 | JSON/XMLなどのドキュメント単位 | スキーマ柔軟・フィールド検索可能 | 商品カタログ・SNSプロフィール・CMS | MongoDB、Amazon DocumentDB |
| カラム指向型 | 列（カラム）単位でデータを格納 | 大量データの集計分析が高速 | IoTログ・時系列データ・分析基盤 | Apache Cassandra、Google Bigtable |
| グラフ型 | ノード（点）とエッジ（線） | 複雑な関係性・繋がりの探索 | SNS友人関係・レコメンド・不正検知 | Neo4j、Amazon Neptune |
実務でのデータベース選定基準
「NoSQLとリレーショナルDBのどちらを選ぶか」という問いに対して、現場のエンジニアは以下の観点で判断します。一方が他方を完全に代替するものではなく、1つのシステム内でリレーショナルDBとNoSQLを両方使うアーキテクチャ（ポリグロット・パーシステンス）も一般的です。
| ユースケース | 推奨 | 理由 |
|---|---|---|
| 財務・経理・在庫管理システム | リレーショナルDB | ACID特性による高い整合性と、複雑な集計・JOIN処理が必須 |
| ECサイトのセッション・カート情報 | NoSQL（キーバリュー型） | 数百万ユーザーの同時アクセスでも高速応答が必要 |
| 商品カタログ・属性が商品ごとに異なるデータ | NoSQL（ドキュメント型） | スキーマが固定できない・商品ごとに属性数が違う |
| IoTセンサーのログ・時系列データ | NoSQL（カラム指向型） | 大量の書き込みと時系列での集計分析に特化 |
| SNSの友人関係・レコメンドエンジン | NoSQL（グラフ型） | 複雑な関係性のトラバース（探索）が高速 |
| 社内の業務アプリ（汎用） | リレーショナルDB | 運用実績が豊富・エンジニアの学習コストが低い |
選定時の実践的チェックリスト
データベースを選定する際は、以下の問いに答えることで方向性が定まります。
- データの整合性はどこまで必要か？ 金融トランザクションなど厳密さが求められる場合はリレーショナルDB
- スキーマは固定できるか？ スキーマが流動的または製品ごとに異なる場合はNoSQLのドキュメント型
- データ量は将来どこまで増えるか？ 数十億件規模が見込まれる場合はNoSQLのスケールアウト特性が有利
- 読み書きのパターンは単純か複雑か？ シンプルな高速読み書きはNoSQL向き、複雑なJOINが必要な場合はリレーショナルDB向き
- チームのスキルセットは？ SQLの習熟度が高いチームではリレーショナルDBが生産性を維持しやすい
ITパスポート・データマネジメント試験（仮称）の頻出ポイント
ITパスポート試験での出題パターン
ITパスポート試験のテクノロジ系では、NoSQLとリレーショナルDBに関する問題が定期的に出題されます。主な出題パターンは以下の3種類です。
パターン1: NoSQLの定義を選ぶ問題
問題例: NoSQL（Not Only SQL）の説明として最も適切なものはどれか。
正解の方向性:「テーブル構造に縛られない柔軟なデータ構造で大量データを扱えるデータベースの総称」
誤答の罠:「SQLを一切使用しないデータベース」という誤解を誘う選択肢が定番です。NoSQLは「Not Only SQL」であり、SQLを否定するものではありません。
パターン2: ユースケースに合ったNoSQL種類を選ぶ問題
問題例: SNSの友人関係や商品のレコメンデーションシステムのように、データ同士の複雑なつながりを表現するのに最も適したNoSQLのデータモデルはどれか。
正解: グラフ型
対応表（暗記必須）: キーバリュー型→キャッシュ・セッション、ドキュメント型→カタログ・プロフィール、カラム指向型→ログ・時系列、グラフ型→関係性・推薦
パターン3: リレーショナルDBとNoSQLの使い分けを問う問題
問題例: 銀行の振込処理システムに最も適切なデータベースはどれか。
正解の方向性: リレーショナルDB（ACID特性による整合性が必須のため）
判断基準:「整合性・正確さが最優先」はリレーショナルDB、「大量データ・スピード・柔軟なスキーマ」が優先されるWebサービスはNoSQLが候補に上がります。
データマネジメント試験（仮称・2027年新設予定）での出題予測
IPAが2027年度に新設予定のデータマネジメント試験（仮称）では、DMBOK2（データマネジメント知識体系）に基づく「データアーキテクチャ」「データストレージとオペレーション」の領域でNoSQLとリレーショナルDBの使い分けが問われると予測されます。ITパスポートのような概念問題に加え、「特定の要件を満たす最適なデータストアを設計・選定する」という応用的な設問も想定されます。
データマネジメント試験の詳細はデータマネジメント試験とは？概要と対策をご覧ください。
よくある誤解とFAQ
Q. NoSQLの読み方は？
NoSQLは「ノーエスキューエル」と読みます。英語でも "No SQL" と発音します。略称の由来は "Not Only SQL"（ノット・オンリー・エスキューエル）で、「SQLに限らない」という意味合いを持ちます。
Q. NoSQL＝「SQLを使わない」ではないのですか？
誤解です。NoSQLは「Not Only SQL」の略で、「SQLに限らない」という意味です。一部のNoSQL製品（Amazon DynamoDB・Apache Cassandraなど）はSQL構文に似た独自クエリ言語をサポートしています。試験では「SQLを一切使わない」という選択肢は誤りです。
Q. キーバリュー型とドキュメント型はどこが違うのですか？
最大の違いは「値の内部を検索できるか」です。キーバリュー型はキーを指定すれば対応する値をそのまま返すシンプルな構造で、値の内部フィールドを条件にした問い合わせはできません。ドキュメント型はJSON等のドキュメント内フィールドを条件指定して絞り込み検索ができます。「高速・シンプル」がキーバリュー型、「柔軟な問い合わせ」がドキュメント型と覚えましょう。
Q. カラム指向型とリレーショナルDBのカラムは違いますか？
概念は似ていますが、格納方式が根本的に異なります。リレーショナルDBは1行（レコード）をまとめてディスクに格納します。カラム指向型は1つの列（カラム）のデータをまとめてディスクに格納します。「売上金額の列だけを読み込んで集計する」という処理では、カラム指向型がリレーショナルDBよりもはるかに高速になります。
Q. グラフ型とネットワーク型データベースは同じですか？
異なります。ネットワーク型データベースは1960〜70年代に使われたデータモデルで、階層型データベースを拡張したものです。現代のグラフ型データベースはNoSQLの一種で、グラフ理論に基づいてノードとエッジで関係性を柔軟に表現します。試験で「グラフ型」が選択肢に出た場合は「データ同士の関係性・繋がりを扱う」がキーワードです。
Q. リレーショナルDBとNoSQLを同時に使ってもいいのですか？
むしろ実務では両方を組み合わせることが一般的です。この考え方をポリグロット・パーシステンス（Polyglot Persistence）といいます。ECサイトを例にすると、注文・在庫データはリレーショナルDB（整合性重視）、セッション・カートはキーバリュー型NoSQL（高速アクセス）、商品カタログはドキュメント型NoSQL（スキーマ柔軟性）という組み合わせが典型的です。
まとめ
本記事のポイントを整理します。
- リレーショナルDBは行と列のテーブル形式・ACID特性・SQL。整合性と複雑な問い合わせが必要な業務向け
- NoSQLは「Not Only SQL」の略。テーブル構造に縛られない柔軟なデータモデルの総称
- キーバリュー型（Redis等）: キーと値のペア・超高速・セッション/キャッシュ向き
- ドキュメント型（MongoDB等）: JSON単位・スキーマ柔軟・カタログ/プロフィール向き
- カラム指向型（Cassandra等）: 列単位格納・集計高速・ログ/時系列向き
- グラフ型（Neo4j等）: ノードとエッジ・関係性探索・SNS/推薦向き
- 使い分け: 整合性最優先はリレーショナルDB、大量・高速・柔軟が必要はNoSQL。組み合わせも一般的
- 試験対策: 「4分類のユースケース対応表」と「NoSQL＝Not Only SQL（SQLを否定しない）」を確実に押さえる
関連記事
- ITパスポート 効率的な勉強法ガイド【独学・勉強時間の目安】
- ITパスポート 難しい分野はどこ？【3分野の問題特性】
- ITパスポート シラバス最新変更点まとめ【2026年版】
- データマネジメント試験とは？2027年新設の概要・難易度・対象者を解説
- データマネジメントとは？企業のデータ活用を支える基盤をわかりやすく解説
ITパスポート 無料模擬試験で実力確認
PassDojoのITパスポート模擬試験で、NoSQL・データベース分野の理解度を試してみましょう。本番形式の問題で弱点を把握できます。