マイクロサービスとは？モノリス（モノリシック）との違いを原典の定義と比較表で解説

マイクロサービスとは、1つのアプリケーションを小さなサービスの集まりとして作り、各サービスを独立したプロセス・独立したデプロイ単位で動かす設計です。対になるのがモノリス（モノリシック）で、全機能を1つのかたまりとしてビルドし、まとめてデプロイします。この記事では、言葉を広めた2014年の原典の定義と9つの特徴、モノリスの意味と語源、両者の違いを比較表で整理し、どちらを選ぶかの目安と中間解のモジュラモノリスまでを扱います。

まとめ：マイクロサービスとモノリスの違いの要点

• マイクロサービスの定義：Lewis＆Fowlerの記事（2014年3月10日〜25日に分載）は「小さなサービスの集まりとして1つのアプリを作る手法」とし、各サービスは独自のプロセスで動き、HTTPなどの軽量な仕組みで通信し、業務の機能単位で作られ、自動化された仕組みで個別にデプロイされると説明しています。
• モノリスの意味：単一の単位として作られたアプリケーション。英語 monolith（一枚岩）が語源で、形容詞が monolithic（モノリシック）です。
• 違いの核心：デプロイとスケールの単位。モノリスは一部の変更でも全体を作り直して配備し直し、マイクロサービスはサービスごとに配備できます。
• 「マイクロ」は小ささの基準ではない：原典は大きさの議論に寄ることを「不幸な」焦点と書き、最大でも12人以下のチームが担う規模を挙げています。
• 選び方の目安：Fowlerは「モノリスでは管理しきれないほど複雑なシステムでなければ検討しない」を第一の指針とし、多くのシステムは単一のモノリスで作るべきだとしています。
• 中間解：単一デプロイのまま内部の境界を固めるモジュラモノリスから始め、必要な機能だけをストラングラーフィグで切り出すのが手戻りの少ない順序です。

以下、原典の定義から順に根拠を示します。

マイクロサービスの原典：Lewis＆Fowlerの2014年の記事

「マイクロサービス」という言葉を広めたのは、ThoughtworksのJames LewisとMartin Fowlerが2014年3月10日から分載し、3月25日に完結した記事「Microservices」です。本記事では、この原典の定義と特徴を軸に説明します。

マイクロサービスの定義：独立プロセス・通信・業務機能・配備

原典の定義文は「a single application as a suite of small services」で始まり、各サービスについて次の4点を挙げています。

• 独自のプロセスで動く（own process）
• 軽量な仕組みで通信する。多くはHTTPのリソースAPI
• 業務の機能（business capabilities）を単位に作る
• 完全に自動化されたデプロイの仕組みで、個別にデプロイできる（independently deployable）

続けて、集中管理は最小限で、サービスごとに別の言語や別のデータストアを使ってもよいと書いています。定義の芯は「独立して動かし、独立して配備できること」で、APIでつなぐこと自体ではありません。共有DBを各サービスが直接読み書きすると、スキーマ変更や実行時の依存が生じ、独立した配備を妨げやすくなります。ただし、DBを共有しているという理由だけで、独立した配備が不可能になるわけではありません。

原典以外の定義もほぼ同じ線にあります。MicrosoftのAzure Architecture Centerは「small, autonomous services（小さく自律したサービス）の集まり」と定義し、Sam Newmanは『Building Microservices』第2版（2021年8月）で「業務ドメインに沿ってモデル化された、独立してリリースできるサービス」としています。どの定義にも「独立して出せること」が入っています。

マイクロサービスの9つの特徴：組織・データ・運用の設計

原典は「正式な定義はない」と断ったうえで、共通する特徴を9つの見出しで説明しています。

このうち「Smart endpoints and dumb pipes」は、ESBに処理を寄せたSOAとの違いを示す特徴です。SOA・ESBとの比較はマイクロサービスの向き不向き｜判断チェックリストと失敗事例、SOA・ESBとの違いで詳しく扱っています。

マイクロサービスの粒度：行数ではなく変更・配備の独立性

原典の囲み記事「How big is a microservice?」は、名前のせいでサービスの大きさに焦点が当たるのは「不幸」だと書いています。実例の幅は、大きい側でAmazonの「Two Pizza Team」（ピザ2枚で足りる人数＝12人以下）が担う規模、小さい側で6人ほどのチームが6つほどのサービスを支える構成でした。何行以下ならマイクロ、という基準はありません。1チームが単独で変更・配備できるかで考えるのが原典に沿った見方です。

名称の由来：2011年のワークショップ

原典の脚注によると、「microservice」という語は2011年5月にヴェネツィア近郊で開かれたソフトウェアアーキテクトのワークショップで、参加者が試していた共通の設計様式を表す言葉として話題になり、2012年5月に同じグループが「microservices」を名称に決めました。

モノリス（モノリシック）とは：意味と語源

モノリスは、マイクロサービスの対義語として使われるIT用語です。辞書的な意味とIT用語での意味がずれるので、分けて押さえます。

語源：monolith＝一枚岩

英語の monolith は「1つの大きな石（一枚岩）」を指します。Merriam-Websterは語源をギリシャ語の monolithos（1つの石でできた）までたどり、mon-（1つの）と lithos（石）に分けています。形容詞が monolithic で、カタカナでは「モノリシック」と書きます。IT以外では、巨石の記念碑や、映画『2001年宇宙の旅』に登場する黒い石板もモノリスと呼ばれます。電子部品の「モノリシックIC」は、1枚の半導体基板の上に回路をまとめて作り込んだ集積回路のことで、ソフトウェアのモノリスとは別の用語です。

IT用語のモノリス：単一の単位で作るアプリ

原典はモノリスを「a monolithic application built as a single unit」と説明し、典型例として、ブラウザで動く画面・共通のリレーショナルDB・サーバー側アプリの3部構成を挙げています。リクエスト処理のロジックはサーバー側の1つの実行単位に入り、内部がクラスやモジュールに分かれていても、ビルドとデプロイは1つです。

原典はモノリスが失敗だとは書いていません。「モノリシックなアプリケーションは成功しうる」としたうえで、規模が大きくなったときの不満として、変更の周期が全体で結び付くこと、良いモジュール構造を保ちにくいこと、一部でなく全体をスケールするしかないことを挙げています。モノリスは「古い悪い設計」ではなく、ここで挙げた弱点が表に出るまでは合理的な選択肢です。

モノリスとマイクロサービスの違い：4つの観点

冒頭の比較表の各行について、なぜ差が出るのかを補います。

デプロイとスケールの単位

モノリスでは、原典が書くとおり「アプリの小さな部分の変更でも、モノリス全体を作り直して配備する」ことになります。スケールも、ロードバランサーの後ろに全体の複製を並べる形です。マイクロサービスはサービスごとに配備でき、検索や決済のように負荷が集中する部分だけを増やせます。その代わり、配備の対象がサービスの数だけ増えるため、デプロイの自動化が前提になります。

データの持ち方と整合性

原典は、モノリスは永続データに単一の論理DBを好み、マイクロサービスは各サービスに自分のDBを管理させることを好む、と対比しています。データを分けると、複数サービスにまたがる更新を各DBのローカルトランザクションだけでは一括して確定できません。分散トランザクションも選択肢ですが、対応するデータストアや可用性に制約があります。注文と在庫の更新で一時的な不整合を許容できる場合は、ローカルトランザクションを連携させ、失敗時に補償処理を行うSagaパターンとは？補償トランザクション設計と実装方式の選び方を解説【2026年版】のような設計を検討します。単一DB内のトランザクションで更新を完結できるモノリスでは、このサービス間の整合性管理を避けられます。

部品間の通信と障害の範囲

モノリスの部品は同じプロセス内の関数呼び出しでつながり、通信の失敗を考える必要がありません。マイクロサービスはネットワーク越しの呼び出しなので、遅延・タイムアウト・相手の停止が日常的に起こります。原典が「Design for failure」を特徴に挙げるのはこのためで、呼び出し先の障害が連鎖しないようcircuit breakerの実装：Java・C#・Go・Node.jsの設定コードと閾値の決め方のような防御を入れます。うまく作れば障害を1サービスに閉じ込められますが、何もしなければ障害の連鎖はモノリスより追いにくくなります。

チームの構造とコンウェイの法則

Melvin Conwayは1968年4月のDatamation誌の論文「How Do Committees Invent?」で、システムを設計する組織は、その組織のコミュニケーション構造を写した設計を生み出すよう制約される、と結論づけました。これがコンウェイの法則です。原典はこれを引き、画面・サーバー・DBの技術層でチームを分けると、層をまたぐ変更のたびにチーム間の調整が要ると指摘しています。マイクロサービスは業務機能ごとにサービスとチームを揃える設計です。システムだけ分けても、チーム間の承認やリリース調整が残れば、独立して配備できる利点を十分に生かせません。結合の度合いの考え方は疎結合とは？密結合との違い・メリットとデメリットを結合度の段階とコード例で解説で扱っています。

マイクロサービスのメリットと代償

メリットは、比較表の右列そのものです。サービス単位で配備できるのでリリースの待ち合わせが減り、負荷の高い部分だけをスケールでき、サービスごとに言語やDBを選べます。複数チームが互いのリリースを待たずに並行して開発できる点が、組織が大きいほど効きます。

代償は運用です。Fowlerは2015年5月13日の「Microservice Premium」で、分散システムが持ち込む自動デプロイ・監視・障害対応・結果整合性への手間を「割増料金（premium）」と呼びました。2014年8月28日の「Microservice Prerequisites」では、数時間で新しいサーバーを立ち上げられること、基本的な監視、迅速なデプロイの3つを、無ければ採用を検討すべきでない前提として挙げています。デメリットの詳細、向かないケース、Segmentが140を超えるサービスを1つに統合した事例やPrime Videoが監視サービスを1つのプロセスにまとめ直した事例はマイクロサービスの向き不向き｜判断チェックリストと失敗事例、SOA・ESBとの違いにまとめました。

国内での普及度は、日本情報システム・ユーザー協会（JUAS）の企業IT動向調査報告書2026が参考になります。図表8-1-1で「マイクロサービス・API連携」を導入済みと答えた企業は21.8%（n=952）、未検討が49.7%でした。この項目は「マイクロサービス・API連携」をまとめて尋ねているため、マイクロサービス単独の普及率や、日本企業全体の採用状況を直接示すものではありません。

モノリスとマイクロサービスの選び方

業務の境界がまだ定まらない新規開発では、モノリスから始めることを本記事では推奨します。Fowlerは2015年6月3日の「MonolithFirst」で、聞いた範囲ではマイクロサービスの成功事例のほとんどが大きくなりすぎたモノリスの分割から始まり、最初からマイクロサービスで作ったシステムはほとんどが深刻な問題に陥っていた、と書いています。理由は境界の引き直しの難しさです。サービス間の機能の付け替えはモノリス内より格段に難しく、経験のある設計者でも最初から正しい境界を引くのは困難だとしています。

マイクロサービスを検討してよいのは、次の兆候が実際に出てからです。

• 複数チームのリリースが同じモノリスの配備で衝突し、待ち合わせが常態化している
• 特定の機能だけが桁違いの負荷を受け、全体の複製ではコストが合わない
• 数時間でのサーバー構築・監視・自動デプロイが既に回っている

3つ目が欠けているうちは、1つ目と2つ目があっても分割は早いと判断します。運用の土台を先に作る場合、クラウド上の基盤づくりはインフラ構築（AWS・Google Cloud・Azure）の支援のように外部と組む方法もあります。たとえば、業務の境界が未確定な小規模チームが「将来に備えて」最初から多数のサービスに分けるのは、MonolithFirstが指摘する「最初から正しい境界は引けない」問題をそのまま抱え込む選び方です。

中間解のモジュラモノリスと段階的な移行

「いまは1つで動かしたいが、将来は分けるかもしれない」場合の答えが、モジュラモノリスと段階移行の組み合わせです。

モジュラモノリス：単一デプロイとモジュール境界の両立

モジュラモノリスは、デプロイは1つのまま、内部を業務機能ごとのモジュールに分け、モジュール間の依存を規約とツールで縛る設計です。モジュール間のネットワーク通信を増やさずに、業務機能の境界や依存関係を検証できます。ただし、サービスとして切り出す際には、通信方式やデータ所有の再設計が必要になる場合があります。原典も、大きなモノリスも業務機能ごとにモジュール化できる（ただし一般的ではない）と書いています。実例として、Shopifyは2019年2月21日の「Deconstructing the Monolith」（Kirsten Westeinde）で、10年以上・1,000人を超える開発者が手を入れてきた最大級のRuby on Railsのコードベースを、マイクロサービスに分けずにモジュラモノリスへ移したと説明しています。理由は「マイクロサービスには別の課題がある」ためで、デプロイ単位を増やさずにモジュール性を上げる道を選びました。2020年9月16日の続報「Under Deconstruction: The State of Shopify’s Monolith」では、基幹モノリスは280万行を超えるRubyコードと50万コミットを抱えていると報告しています。実装の手順はモジュラモノリスとは？モジュール境界の設計とDB分割・依存検証の実装で解説しています。

ストラングラーフィグによる機能単位の段階移行

モノリスからの移行は、全体を一度に作り替えず、機能を1つずつ外へ切り出します。名前はFowlerの「Strangler Fig Application」に由来します。2001年にオーストラリアのクイーンズランドの熱帯雨林で見た絞め殺しの木（ストラングラーフィグ）は、宿主の木に取り付いて育ち、宿主が枯れたあとも形だけを残して自立します。Fowlerはこれを、古いシステムを少しずつ置き換える進め方のたとえにしました（初出は2004年6月29日、現在の記事は2024年8月22日の改稿版です）。手順は次の順です。

1. モノリスの内部をモジュールに分け、切り出す境界を決める
2. 負荷や変更頻度が高く、他への依存が少ない機能を選ぶ
3. その機能を新しいサービスとして外に作り、前段のルーティングで呼び出しを少しずつ振り替える
4. 旧機能への呼び出しがなくなったら、モノリス側のコードを消す

移行中の呼び出し先はルーティング設定で切り替えます。ただし、旧経路へ戻すには、旧コードの維持に加え、新側で更新したデータを旧側でも扱える同期・互換性の確保と、切り戻し可能な期限の設定が必要です。切り戻しの設計を含む実装手順はストラングラーフィグパターンとは？レガシー移行の実装手順と切り戻し設計を解説にあります。

マイクロサービスを支える技術要素

サービスの数が増えると、配置・通信・監視を人手で回せなくなります。主な技術要素と役割は次のとおりです。

土台はコンテナとは？仮想マシンとの違いからDocker・企業の導入判断まで解説とコンテナオーケストレーションとは？Kubernetesの役割と自社に必要かの判断を解説、入口の設計はBFFとは？API Gatewayとの違い・採用判断とアンチパターンを実装視点で解説、監視はOpenTelemetryとは｜LinuxでCollectorを動かしテレメトリを集める手順とPrometheusとの違い、非同期の連携はイベント駆動アーキテクチャとは？仕組み・実装パターンと採用判断を実装者目線で解説で扱っています。サービスメッシュは個数だけで採否を決めず、通信制御・相互認証・可観測性を共通化する必要性と、追加される運用負担を比較して導入を判断します。

よくある質問

マイクロサービスとは簡単に言うと何ですか？

1つのアプリを、別々に作り直して配備できる小さなサービスの集まりとして作る設計です。通販サイトなら、商品検索・カート・決済・会員管理を別のサービスにして、それぞれを担当チームが自分のペースで更新します。

モノリスとは何ですか？

IT用語では、全機能を1つの単位としてビルド・デプロイするアプリケーションの構成を指します。語源は英語の monolith（一枚岩）で、形容詞の monolithic を「モノリシック」と書きます。

モノリスとマイクロサービスの違いは何ですか？

デプロイとスケールの単位です。モノリスは小さな変更でも全体を配備し直し、スケールも全体を複製します。マイクロサービスはサービスごとに配備・スケールでき、その代わり通信の失敗やデータの整合を設計で引き受けます。

マイクロサービスの例にはどのようなものがありますか？

原典は、英国の比較サイト comparethemarket.com が製品ごとのチームで開発・運用し、各製品をメッセージバスでつながる複数のサービスに分けている例を挙げています。逆に、Segmentは140を超えるサービスを1つのサービスへ統合し直しました（詳細は向き不向きの記事）。

モジュラモノリスとマイクロサービスの違いは何ですか？

モジュラモノリスはデプロイ単位が1つのまま、内部のモジュール境界だけを厳格にした構成です。ネットワーク通信と分散データの複雑さを持ち込まないため、マイクロサービスに進む前の段階として使えます。

関連記事

• マイクロサービスの向き不向き｜判断チェックリストと失敗事例、SOA・ESBとの違い
• モジュラモノリスとは？モジュール境界の設計とDB分割・依存検証の実装
• ストラングラーフィグパターンとは？レガシー移行の実装手順と切り戻し設計を解説
• システムアーキテクチャとは？意味と代表5方式の違い・選び方をわかりやすく解説
• シタデルアーキテクチャ（Citadel Architecture）とは？DHHの定義とアウトポストを切り出す判断基準