MongoDBとは？ドキュメント指向データベースの仕組み・利点・使い方入門【9.0対応】

MongoDBは、1件のデータを表の行ではなく「ドキュメント」として保存するドキュメント指向のNoSQLデータベースです。ドキュメントはJSONに似た形で表現でき、内部ではBSONというバイナリ形式で保存されます。本文のmongosh例では、JSONにはないObjectIdなどの型コンストラクターも使います。この記事では、ドキュメント指向データベースの考え方、MongoDBのドキュメントの構造とルール、利点とデメリット、向かない業務を整理したうえで、Dockerとmongoshで動かす最初の手順を示します。コード例は2026年10月27日にMongoDB 9.0.4のDocker公式イメージで検証しました。上限値は公式マニュアルの仕様を示し、実行結果とは区別しています。

まとめ：MongoDBとドキュメント指向データベースの要点

• MongoDBはドキュメント指向データベース。RDBのテーブル・行・列は、コレクション・ドキュメント・フィールドに対応する。
• ドキュメントはJSON形式で書き、BSONで保存される。日時・Decimal128・ObjectIdなどJSONに無い型を持てる。
• 通常のコレクションでは、各ドキュメントが一意で変更不可の_idを持つ（時系列コレクションは例外）。1件の上限は16MiBで、超えるファイルはGridFSで分割する。
• 利点はスキーマ変更なしで項目を足せること、シャーディングで水平に分割できること、関連データを1件にまとめてJOINなしで読めること。
• 複数データを厳密に同時更新する会計・決済や、多対多の結合と帳票集計が中心の基幹システムには向かない。ここはRDBを選ぶ。
• 2026年10月時点の現行版は9.0系。ライセンスはSSPLで、自社アプリのDBとしては無料で使えるが、OSIが承認したオープンソースではない。

MongoDBとは：ドキュメント単位でデータを持つNoSQLデータベース

MongoDBは2009年に公開されたデータベースで、開発元はMongoDB, Inc.（旧10gen）です。RDBが1件のデータを複数のテーブルに分けて持つのに対し、MongoDBは注文とその明細、ユーザーとそのプロフィールのような「1つのまとまり」を1件のドキュメントに収めます。データベースの種類全体の中での位置づけは、データベースの種類とRDB・NoSQLの選び方を解説した記事で整理しています。

RDBのテーブル・行・列とMongoDBの用語の対応

RDBの経験があれば、用語を対応付けると早く理解できます。

決定的な違いは、テーブルが全行で同じ列を持つのに対し、同じコレクションのドキュメントはフィールド構成が1件ごとに違ってよい点です。列追加のマイグレーションをせずに、新しいフィールドを持つドキュメントを書き込めます。

ドキュメント指向データベースとは：値の中身で検索できるNoSQL

NoSQLは、キーバリュー型（Redisなど）、ワイドカラム型（Cassandraなど）、グラフ型（Neo4jなど）、ドキュメント型に大別されます。ドキュメント指向データベースは、JSONのような入れ子構造を1件のデータとして保存し、その内部のフィールドや配列を対象に検索・インデックス・集計ができるデータベースです。基本的なキーバリュー操作はキーで値を取得します。ただし、RedisのようにJSONやハッシュのフィールドを索引化して検索できる製品もあります。ここがドキュメント型との分かれ目です。

MongoDBと互換サービス・ほかのドキュメントDBの違い

ドキュメントDBには、MongoDB本体のほかに、MongoDBの通信プロトコルやAPIに合わせた互換サービスと、独自のAPIを持つ製品があります。

互換サービスは、使える演算子や対応するMongoDBの版が本体と一致しないことがあります。移行や採用の前に、各サービスが公開している互換表で、自分のアプリが使う機能を確かめてください。AWS上の選択肢はAmazon DocumentDBの仕組みと採用判断を解説した記事、PostgreSQLの上で動くOSS版はDocumentDB（PostgreSQL実装）とAzure DocumentDBの違いを解説した記事で扱っています。

MongoDBのドキュメント（document）の構造とルール

MongoDBのドキュメントは、フィールド名と値の対を集めたものです。値には文字列や数値のほか、配列や別のドキュメントも入れられます。

{
  "_id": ObjectId("665f1a2b3c4d5e6f7a8b9c0d"),
  "name": "田中太郎",
  "age": 34,
  "tags": ["mongodb", "nosql"],
  "address": { "city": "東京", "zip": "100-0001" }
}

JSONで書いてBSONで保存する：Decimal128とDate型を選ぶ理由

見た目はJSONですが、保存形式はBSON（Binary JSON）です。JSONの文字列・数値・真偽値・配列・オブジェクト・nullに加えて、BSONはDate、ObjectId、64bit整数、Decimal128、バイナリなどの型を持ちます。型の選び方は計算結果に直接響きます。mongoshで集計すると、浮動小数点の0.1 + 0.2は0.30000000000000004になり、Decimal128同士なら0.3になりました。金額はDecimal128、日時は文字列でなくDateで持つと、誤差と範囲検索の問題を避けられます。

_idフィールドとObjectId：一意性・変更制限・使用可能な型

公式マニュアルのDocumentsによると、_idは主キーとして予約されたフィールドで、値はコレクション内で一意、かつ変更できません。型は配列・正規表現・BSONのundefinedを除くBSON型が使えます。挿入時に省略すると、ドライバが12バイトのObjectIdを自動で付けます。ObjectIdの先頭4バイトは秒単位の生成時刻なので、getTimestamp()でObjectIdの生成日時を取り出せます。DBへの挿入日時とは限りません。

9.0.4で試すと、_idを$setで書き換えようとした更新は「would modify the immutable field ‘_id’」のエラー（コード66）で拒否され、配列を_idにした挿入は「The ‘_id’ value cannot be of type array」で失敗しました。メールアドレスなど既存の一意な値を_idにする設計は可能ですが、後から変えられない点を前提にしてください。

フィールド名のルールとドット記法による入れ子・配列の指定

入れ子のフィールドや配列の要素は、"address.city"や"tags.0"のようにドットでつないで指定します（ドット記法）。BSONのフィールドは順序を持ち、{z: 1, a: 2, m: 3}と書いたドキュメントは取り出してもz・a・mの順のままでした。ただし_idは常に先頭へ移され、フィールド名を変える更新では順序が変わることがあります。

db.users.find({ "address.city": "東京", tags: "nosql" })

注意したいのは、フィールド名そのものに.や$を含めた場合です。公式マニュアルはこうした名前の保存を許していますが、ドット記法とぶつかります。{"price.jpy": 1200}を入れたコレクションでfind({"price.jpy": 1200})を実行すると、入れ子のpriceの中のjpyを探すため0件になり、$getFieldを使った式でようやく1件が返りました。公式マニュアルのドットとドル記号の注意点によると、こうした名前はインデックスやシャードキーにも使えません。外部APIのJSONをそのまま入れる場合は、キーにドットが含まれていないかを先に確かめるのが安全です。

db.rates.countDocuments({ $expr: { $eq: [{ $getField: "price.jpy" }, 1200] } })  // 1

埋め込みと参照を更新頻度と読み取り単位で使い分ける基準

RDBなら別テーブルに分けてJOINする関連データを、一緒に読むことが多いなら1件のドキュメントに埋め込むのがMongoDBの基本設計です。判断の目安は2つあります。親と同時に読み、親と同時にしか更新しないなら埋め込みます。単独で更新される、または多数の親から共有されるなら、別コレクションに置いて_idで参照します。同じ値を多数のドキュメントに埋め込むと、変更時に全件を書き換えることになります。正規化をどこで崩すかの考え方はデータベース正規化と非正規化の判断を解説した記事が参考になります。

1件16MiBの上限・ネスト100階層とドキュメントサイズの調べ方

公式のLimits and Thresholdsでは、BSONドキュメントの最大サイズは16MiB、入れ子は100階層までと定められています。16MiBちょうどの文字列を持つドキュメントを9.0.4に入れると、「object to insert too large. size in bytes: 16777246, max size: 16777216」（コード10334）で拒否されました。動画や大きなファイルは、GridFSで既定255KiBのチャンクに分けて保存します。

コメントやログのように件数が増え続ける配列を1件に持たせると、いずれ上限に届きます。現在のサイズは、mongoshのbsonsize()か、集計の$bsonSizeで確かめられます。大きい順に並べれば、上限に近いドキュメントを先に見つけられます。

db.users.aggregate([
  { $project: { name: 1, size: { $bsonSize: "$$ROOT" } } },
  { $sort: { size: -1 } },
  { $limit: 5 }
])

MongoDBの利点とデメリット：ドキュメントモデルで楽になる作業と増える作業

利点：項目追加・水平スケール・JOINなしの読み取り

最も効く利点は、仕様変更への強さです。スキーマを事前に固定しないため、任意フィールドの追加だけなら、既存ドキュメントを一括更新せずに導入できます。ただし、新しい必須項目や型制約を設ける場合は、既存データの補完・変換が必要になることがあります。カテゴリごとに属性が違う商品カタログ、投稿やコメント、IoTのセンサーログ、アプリの設定やプロフィールのように、1件がまとまりを持ち項目が一定でないデータで効果が出ます。

次が規模への強さです。シャーディングでデータを複数のサーバーへ水平に分割し、データ量と書き込みの増加にサーバーの追加で対応できます。性能はシャードキーの選び方で大きく変わるので、シャーディングの仕組みとシャードキー設計を解説した記事で先に設計の勘所を押さえてください。3つ目は読み取りの単純さで、関連データを1件に埋め込めば、1回の読み取りでそろいます。

デメリット：結合と複数ドキュメント更新のコスト、構造の乱れ

弱点は利点の裏返しです。データを分けて結合する設計にすると、$lookupはあってもドキュメントモデルの利点が薄れます。複数ドキュメントをまとめて確定させるトランザクションは4.0系（レプリカセット）と4.2系（シャードクラスタ）から使えますが、公式マニュアルのTransactionsは、単一ドキュメントの書き込みより性能コストが大きく、スキーマ設計の代わりにはならないとしています。

もう1つは、スキーマを強制しないことによる構造の乱れです。priceが数値の件と文字列の件が混ざる、userIdとuser_idが併存する、といった状態になると、集計が静かに狂います。これは後述の$jsonSchemaで型と必須項目を決めておけば防げます。可変な項目が一部だけなら、MongoDBを追加せずPostgreSQL JSONBの使い方と正規化列との設計境界を解説した記事のように、RDBのJSONB列で受ける方が運用するDBを1種類に保てます。

MongoDBを使ってはいけないケースと「データが消える」評判の真偽

「MongoDBは使ってはいけない」という声には、今も変わらない適性の問題と、既定値の変更で解消した古い評判が混ざっています。

RDBを選ぶべき業務：会計・決済・多対多の帳票集計

会計・在庫引当・決済のように、複数のデータを同時に確定させる処理が業務の大半を占めるなら、RDBを第一候補にします。トランザクションの本番運用の考慮事項では、トランザクションの実行時間は既定で60秒未満に制限され、期限切れになると定期的なクリーンアップ処理で中断されます。この上限は設定で変更できます。受注・出荷・請求・顧客が多対多で結びつき、横断の帳票が中心の基幹システムも、正規化したテーブルとSQLのJOINの方が保守しやすくなります。分離レベルとACIDの違いはトランザクションの分離レベルとACIDを解説した記事で確認できます。

既存のMongoDBが上の条件に当てはまる、あるいは新規開発でRDBとMongoDBのどちらにするか決めきれない場合は、データモデルと移行計画を同時に設計するのが近道です。一創のデータベース設計・移行支援では、要件からのDB選定、スキーマ設計、RDBとNoSQLの間の移行を支援しています。

「データが消える」「流出する」評判と現行の既定値

初期のドライバには書き込みの確認を待たずに処理を返す既定があり、障害時に「書いたはずのデータが無い」という報告が相次ぎました。現行の既定は異なります。公式マニュアルのWrite Concernでは、レプリカセットの既定の書き込み保証はmajorityです。9.0.4のレプリカセットでdb.adminCommand({ getDefaultRWConcern: 1 })を実行すると、w: 'majority'、設定元はimplicit（暗黙の既定）と返りました。例外はアービターを含み、データを持つ投票メンバー数が、全投票メンバー数から算出した過半数以下となる構成で、このときの暗黙の既定はw: 1になります。アプリ側でw: 1やw: 0を明示すれば保証は弱まるので、古いサンプルを写したコードは確認してください。

流出の評判は、2017年前後に認証なしで公開されたMongoDBが大量にデータを消され、身代金を要求された事件から来ています。公式のIP Bindingのとおり、パッケージで入れたmongodとmongosは、既定でlocalhostにしか待ち受けません。ただしDocker公式イメージは例外です。9.0.4のイメージは起動時に--bind_ip_allを付けてコンテナ内の全インターフェースで待ち受けるため、-p 27017:27017で公開して認証を設定しなければ、ホストの外から届きます。2025年12月には認証前にメモリ内容が漏れるCVE-2025-14847（MongoBleed）も公表されました。影響版と対策はMongoBleed（CVE-2025-14847）の影響バージョンと対策を解説した記事にまとめています。認証なしの公開を避けることに加え、サポート期間内の版でもセキュリティ修正を適用する必要があります。

MongoDB入門：Dockerで起動してmongoshでCRUDを試す手順

ここからは手元で動かします。Docker公式イメージには公式シェルのmongoshが同梱されているので、コンテナ1つで接続まで試せます。

Dockerによる9.0の起動：127.0.0.1への公開限定と認証設定

前の章の理由から、ポートは127.0.0.1に限定し、ルートユーザーを環境変数で作ります。MONGO_INITDB_ROOT_USERNAMEとMONGO_INITDB_ROOT_PASSWORDを両方渡すと、イメージが--authを付けて起動します。9.0.4で試すと、認証なしのlistDatabasesは「Unauthorized」（コード13）で拒否されました。

docker run -d --name mongo -p 127.0.0.1:27017:27017 \
  -e MONGO_INITDB_ROOT_USERNAME=admin \
  -e MONGO_INITDB_ROOT_PASSWORD=change-me \
  mongo:9.0.4

docker exec -it mongo mongosh -u admin -p change-me
use shop

useで選んだデータベースやコレクションは、最初のドキュメントを書き込んだ時点で作られます。事前の定義は要りません。

insertOne・find・updateOne・deleteOneによるCRUD操作

検索条件も更新内容も、すべてドキュメントで渡します。

db.users.insertOne({ name: "田中太郎", age: 34, tags: ["mongodb", "nosql"] })
db.users.find({ age: { $gte: 30 } }, { _id: 0, name: 1, age: 1 })
db.users.updateOne(
  { name: "田中太郎" },
  { $set: { age: 35 }, $push: { tags: "mongosh" } }
)
db.users.deleteOne({ name: "田中太郎" })

$gteは「以上」、$setは指定フィールドだけの書き換え、$pushは配列への追加です。findの2つ目の引数は返すフィールドの指定（射影）で、_id: 0で_idを省けます。updateOneの戻り値のmatchedCountとmodifiedCountは、どちらも1でした。

aggregateの$matchと$groupで集計する書き方

合計やグループ集計は、ステージの配列をaggregateに渡して書きます。次の例は注文を3件入れてから、支払い済みの注文をユーザーごとに合計し、多い順に並べます。amountをDecimal128で入れておくと、合計もDecimal128('2000')のように誤差なく返ります。

db.orders.insertMany([
  { userId: "u1", amount: NumberDecimal("1200"), status: "paid" },
  { userId: "u1", amount: NumberDecimal("800"), status: "paid" },
  { userId: "u2", amount: NumberDecimal("900"), status: "canceled" }
])

db.orders.aggregate([
  { $match: { status: "paid" } },
  { $group: { _id: "$userId", total: { $sum: "$amount" }, count: { $sum: 1 } } },
  { $sort: { total: -1 } }
])

createIndexと$jsonSchema：検索用インデックスと型制約

検索に使うフィールドにインデックスが無いと、コレクション全体を走査します。unique: trueを付ければ一意制約にもなります。複合インデックスの並び順と実行計画の読み方は、MongoDBのインデックス設計を9.0で実測した記事で扱っています。

db.users.createIndex({ email: 1 }, { unique: true })

db.createCollection("payments", {
  validator: {
    $jsonSchema: {
      bsonType: "object",
      required: ["userId", "amount", "createdAt"],
      properties: {
        userId: { bsonType: "string" },
        amount: { bsonType: "decimal" },
        createdAt: { bsonType: "date" },
        status: { enum: ["pending", "paid", "canceled"] }
      }
    }
  },
  validationLevel: "strict",
  validationAction: "error"
})

// amountが文字列なので拒否される（Document failed validation・コード121）
db.payments.insertOne({ userId: "u1", amount: "1200", createdAt: new Date() })

propertiesに無いフィールドは既定で自由に足せるので、型と必須項目だけを決めて柔軟さは残せます。既存のコレクションにはcollModで後から検証ルールを付けられます。公式マニュアルのSchema ValidationにあるとおりvalidationAction: "warn"なら拒否せずログに残すだけなので、まずwarnで挿入・更新時の違反を把握し、既存の違反データを洗い出して修正してからerrorへ切り替えます。warnは未更新の既存データを一括検査する機能ではありません。

在庫引当の実装：単一ドキュメント更新とトランザクションの使い分け

1件のドキュメントへの更新は常に原子的です。「在庫が1以上のときだけ1減らす」は、条件付きの更新1回で書けます。検証用の在庫を1件作り、更新を2回実行すると、1回目のmodifiedCountは1、2回目は0でした。

db.inventory.insertOne({ sku: "A-100", qty: 1 })

db.inventory.updateOne(
  { sku: "A-100", qty: { $gte: 1 } },
  { $inc: { qty: -1 } }
)

在庫の減算と注文の作成を同時に確定させるには、トランザクションを使います。トランザクションはレプリカセットかシャードクラスタでしか動きません。単体起動のコンテナで試すと「This MongoDB deployment does not support retryable writes」で失敗したので、レプリカセットとして別のコンテナを起動します。先ほどのmongoとは別のDBなので、在庫も入れ直します。このコンテナは認証なしの検証用なので、-pでホストにポートを公開しません。

docker run -d --name mongo-rs mongo:9.0.4 --replSet rs0
docker exec -it mongo-rs mongosh

rs.initiate()
db.hello().isWritablePrimary   // trueになるまで数秒待って再実行
use shop
db.inventory.insertOne({ sku: "A-100", qty: 1 })

準備ができたら、次のコードを同じmongoshに貼り付けます。

const session = db.getMongo().startSession()
const shop = session.getDatabase("shop")
session.startTransaction({ writeConcern: { w: "majority" } })
try {
  const r = shop.inventory.updateOne(
    { sku: "A-100", qty: { $gte: 1 } },
    { $inc: { qty: -1 } }
  )
  if (r.modifiedCount === 0) throw new Error("在庫不足")
  shop.orders.insertOne({ sku: "A-100", qty: 1, createdAt: new Date() })
  session.commitTransaction()
} catch (e) {
  session.abortTransaction()
  throw e
} finally {
  session.endSession()
}

updateOneは条件に一致しなくてもエラーにならないため、modifiedCountを見て明示的に中断しています。在庫1で2回続けて実行すると、2回目は「在庫不足」で中断され、注文は1件だけ残りました。この例は再試行処理を省いています。本番では、一時的なトランザクションエラー時の再試行と、コミット結果が不明な場合の確認・再試行を実装します。

MongoDBのバージョンとサポート期限：2026年10月時点の選び方

各系列のサポート終了日は、MongoDBのソフトウェアライフサイクル表で確認できます。

最新パッチ版は9.0のリリースノートなど各系列のページで確かめられます。新規構築はサポート期間の長い9.0系か8.0系を選び、7.0系で動いている既存システムは2027年8月末から逆算して移行を計画します。9.0系では、外部から同時に開けるマルチドキュメントトランザクションに既定10,000件の上限が付き、超えるとTooManyOpenTransactionsで拒否されます。単一クエリが使うメモリにも既定の上限（1GBとサーバーが使えるメモリの20%の大きい方）が入ったので、大きな集計を動かしている環境は上げる前に確認が要ります。Docker公式イメージではmongo:8が8.0系ではなく8.3系（8.3.13）を指すため、8.0系に固定したいときはmongo:8.0と系列まで書きます。

SSPLライセンスで無料で使える範囲とOSI非承認の意味

公式のSSPL FAQによると、2018年10月16日以降にリリースされたMongoDB Community Serverの版とパッチはSSPL（Server Side Public License）で提供されています。SSPLはGPL v3を土台にしたライセンスですが、FAQ自身がOSIの承認を受けていないと書いています。GPLとの実質的な違いは第13条で、MongoDBを第三者向けのサービスとして提供する場合に、そのサービスの提供に使うソフトウェアのソースコード公開を求めます。自社アプリのデータベースとして使う分には、この条件はかかりません。

Atlas・Compass・ドライバの選び方とRealm同期の終了

• MongoDB Atlas：AWS・Google Cloud・Azure上の公式マネージドサービス。無料のFreeクラスタ（旧M0）はストレージ0.5GBまでで、レプリカセット構成なのでトランザクションもすぐ試せる。料金と階層はMongoDB Atlasのクラスタ階層と料金を解説した記事を参照。
• MongoDB Compass：公式GUI。ドキュメントの閲覧・編集、クエリ、インデックス作成、実行計画の確認をコードなしで行える。
• ドライバとODM：Node.js公式ドライバ、PythonのPyMongoなどから接続する。Node.jsでスキーマ定義を持たせるならMongooseの使い方とv9の変更点を解説した記事のODMがよく使われる。

古い入門記事にある「Realmでモバイルとクラウドを自動同期できる」という説明は、今は当てはまりません。Atlas Device Syncは2025年9月30日に提供を終えました。端末側のローカルDBの現状はRealm（モバイルDB）とDevice Sync終了後の採用判断を解説した記事で扱っています。

よくある質問

MongoDBのドキュメントとは何ですか？

MongoDBでデータを保存する1件の単位です。フィールド名と値の対を集めた、JSONに似た形のデータで、内部ではBSONで保存されます。RDBの1行に当たりますが、配列や入れ子のドキュメントを持てるので、注文と明細のような関連データを1件にまとめられます。通常のコレクションでは各ドキュメントが一意で変更できない_idを持ち（時系列コレクションは例外）、1件の上限は16MiBです。

ドキュメント指向データベースとRDBの違いは何ですか？

RDBは全行が同じ列を持つテーブルにデータを分け、SQLのJOINで結合します。ドキュメント指向データベースは、項目が1件ごとに違ってよいドキュメントに関連データをまとめて持ち、その内部のフィールドで検索します。厳密な同時更新と結合・集計が中心ならRDB、項目が一定でない大量のデータを1件単位で読み書きするならドキュメント指向が向きます。

MongoDBを使ってはいけないのはどんな場合ですか？

複数のデータを厳密に同時更新する会計・在庫引当・決済が業務の中心にある場合と、多対多の結合や帳票集計が中心の基幹システムです。トランザクションはありますが、公式マニュアルはスキーマ設計の代わりにはならないとしており、既定で60秒の実行時間の上限もあります。表に収まる小規模なデータなら、MySQLやPostgreSQLで足ります。

MongoDBは無料で使えますか？オープンソースですか？

Community Serverは自社アプリのデータベースとして無料で使えます。ただしライセンスはSSPLで、MongoDB自身のFAQがOSIの承認を受けていないと明記しているため、OSIの定義でのオープンソースではありません。MongoDBそのものを第三者向けのサービスとして提供する場合は、ソースコード公開の条件がかかります。

MongoDBのドキュメントのサイズはどうやって確認しますか？

mongoshならbsonsize(db.users.findOne())で1件のバイト数が返ります。コレクション全体から大きいものを探すなら、集計で{ $project: { size: { $bsonSize: "$$ROOT" } } }を使い、サイズの降順に並べます。上限の16MiBに近いドキュメントは、配列を別コレクションに分けるか、ファイルならGridFSに移します。

関連記事

• MongoDBのインデックス設計：createIndexの書き方・ESRの並び順・explainの読み方【9.0で実測】
• MongoDB Atlasとは？クラスタ階層・料金・セキュリティ設定と採用判断を実装者目線で解説【2026年版】
• Mongooseとは？Node.js用MongoDB ODMの使い方とv9の変更点
• DocumentDBとは｜Microsoft発OSSのPostgreSQL実装とAzure DocumentDBの違い【2026年9月時点】
• MongoDBの脆弱性CVE-2025-14847（MongoBleed）とは？影響バージョン・確認手順とzlib無効化の対策【2026年10月時点】