マイクロサービスが自社に向くかどうかは、システムの大きさより「機能ごとに独立して変えたい理由があるか」と「分散システムを運用できる体制があるか」で決まります。条件がそろわないまま分割すると、運用の負担が分割の利点を上回ります。実際にSegmentは、送信先ごとに分けた140を超えるサービスの維持に追われ、その部分を1つのサービスへ統合しました。本記事では、向くシステムと向かないシステムの条件、撤退事例から読める失敗の型、採用前に確かめるチェックリスト、そしてよく比べられるSOA・ESBとの違いを、一次情報をもとに整理します。
まとめ：マイクロサービスの向き不向きの結論
- 向いているのは、機能ごとに変更頻度や負荷が大きく違い、複数のチームがそれぞれのサービスを並行して担当する大規模なシステムです。
- 向いていないのは、新規立ち上げのプロダクト、数名で全体を把握できる規模のシステム、ドメインの境界がまだ動いている段階です。Martin Fowlerは、自身が聞いた事例では、最初からマイクロサービスで作ったシステムのほとんどが深刻な問題に陥ったと書いています。
- 採用前の最低条件は、サーバーを数時間で用意できること、本番の異常を監視で捉えられること、サービスを素早くデプロイ・ロールバックできることの3つです。
- 典型的な失敗の一つは、共有ライブラリや共有データでサービス同士が結びついたまま分割する「分散モノリス」です。独立して変更できないのに、ネットワーク越しの複雑さだけが増えます。
- SOA・ESBとの違いは、通信路に知能を置くかどうかです。ESBは中央でルーティングや変換を担い、マイクロサービスは処理をサービス側に置いて通信路は単純に保ちます。
- 迷ったら、単一デプロイのまま内部をモジュールで分けるモジュラモノリスから始め、切り出す理由がはっきりした部分だけをサービスにします。
マイクロサービスが向いているシステムの条件
マイクロサービスは、分割による利点が運用コストの増加を上回るときにだけ効きます。James LewisとMartin Fowlerが2014年3月に公開した「Microservices」は、この様式の特徴として、ビジネス機能単位の組織化、サービスごとのデータ管理、インフラの自動化などを挙げています。裏返せば、これらを必要とする事情がある組織に向く設計です。
採用状況の参考として、日本情報システム・ユーザー協会（JUAS）の企業IT動向調査報告書2026（2025年度調査）の図表8-1-1では、「マイクロサービス・API連携」を導入済みの企業は21.8%、未検討は49.7%でした（当該項目の回答952社。API連携を含む項目なので、マイクロサービスだけの導入率ではありません）。業種グループ別の「導入済み」の割合（図表8-1-7）では金融・保険がこの項目で1位でした。これは採用の状況を示す数字で、向き不向きを測ったものではない点に注意してください。
機能ごとに変更頻度と負荷が違うシステム
LewisとFowlerは、サービスに分ける利点として、各サービスを独立してデプロイでき、スケールさせたい部分だけを増やせる点を挙げています。たとえば仮に、あるECサイトで商品検索はセール時に負荷が跳ね上がり、決済は変更のたびに厳しい検証が要り、会員管理の変更はまれだとします。このように機能ごとにリリースの頻度とスケールの要件が違うと、サービスに分けた方が「検索だけを増強する」「決済だけを慎重にリリースする」といった運用ができます。全機能が同じペースで変わり、負荷も均一なシステムでは、この利点はほとんど生まれません。
複数チームが並行して開発する組織
Melvin Conwayは1968年の論文「How Do Committees Invent?」で、システムを設計する組織は自らのコミュニケーション構造を写した設計しか作れない、と述べました（コンウェイの法則）。マイクロサービスはこの関係を逆手に取り、1チームが1サービスに責任を持つ形にして、他チームのリリースを待たずに開発を進めます。逆に言えば、サービスごとに担当チームを置けない組織では、分割しても調整の待ち時間は減りません。
採用前に必要な3つの運用能力
Fowlerは2014年8月の「Microservice Prerequisites」で、次の基礎能力が無いならマイクロサービスを検討すべきではないとしています。
- 素早いプロビジョニング：新しいサーバーを数時間で立ち上げられる
- 基本的な監視：テスト環境では見つからない本番の異常を、技術指標と業務指標（受注数の急減など）の両方で検知できる
- 素早いアプリケーションデプロイ：多数のサービスをテスト環境・本番環境へすぐにデプロイでき、問題が出たらロールバックできる
同じ記事は、これらが開発と運用の密な協働（DevOps文化）という組織の変化を伴うとも書いています。監視の設計はREDメソッドとは？マイクロサービス監視の3指標（流量・失敗・所要時間）と実装手順を解説で、サービス間の障害連鎖を止める仕組みはサーキットブレーカーとは？マイクロサービスの障害連鎖を止める仕組みと実装・導入判断を解説で扱っています。クラウド上でこうした基盤を整えるところから相談したい場合は、インフラ構築（AWS・Google Cloud・Azure）の支援も用意しています。
マイクロサービスが向かないケースとデメリット
向かない条件は、デメリットがそのまま表に出る条件でもあります。Fowlerは2015年5月の「Microservice Premium」で、マイクロサービスはそれ自体が複雑さを持ち込み、プロジェクトのコストとリスクに上乗せ（プレミアム）を課すと表現しました。この上乗せを払う価値があるのは、システムが十分に複雑になってからです。
新規立ち上げ・小規模なシステム
Fowlerは2015年6月の「MonolithFirst」で、自身が聞いた事例では、最初からマイクロサービスとして作ったシステムのほとんどが深刻な問題に陥り、成功例のほとんどはモノリスが大きくなりすぎてから分割したものだったと書いています。ただし同じ記事で、証拠はまだ少なく助言は暫定的なものだとも断っています。立ち上げ期は事業の方向が変わりやすく、正しいサービス境界がまだ分かりません。境界を間違えたまま分割すると、サービスをまたぐ機能の移動はモノリス内のリファクタリングよりはるかに高くつきます。開発者が数名で全体を把握できる規模なら、モノリスの方が速く作れ、障害の調査も1か所で済みます。
『Building Microservices』の著者Sam Newmanも、2020年2月11日の寄稿「Should I use microservices?」で、安定したサービス境界を定めることが重要である以上、マイクロサービスはまったく新しいプロダクトやスタートアップにはしばしば悪い選択だと書いています。「成功したらスケールが必要になる」という理由で最初から分けても、成功したときに届けているものが当初の構想と大きく違っていることが多いからです。
運用と通信のコスト増
分割すると、関数呼び出しだったものがネットワーク越しの呼び出しに変わります。遅延と失敗の可能性が増え、1つのリクエストを複数サービスにまたがって追跡する仕組み、サービスごとのデプロイパイプライン、サービス間のデータ整合性の設計が必要になります。サービスが増えるほど、この運用の負担は積み上がります。なおFowlerは「Microservice Premium」で、60人で20サービスを持つ組織から4人で200サービスを抱える組織まで見てきたと書きつつ、サービスの大きさが上乗せの大きさにどこまで影響するかは明らかでないとしています。
分散モノリスという失敗パターン
マイクロサービス化の典型的な失敗パターンの一つが「分散モノリス」です。サービスを分けたものの、共有ライブラリや共有データベースで互いに強く依存し、1つの機能追加のたびに複数サービスを同時に修正・デプロイしなければならない状態を指します。独立して変更できるというマイクロサービス最大の利点が失われ、残るのはネットワーク越しの複雑さだけです。共有ライブラリを持つこと自体が悪いのではなく、その更新が全サービスの同時リリースを強いる設計になっているかどうかが分かれ目です。
撤退事例から読む失敗の条件
マイクロサービスからモノリスへ戻した事例は、何が条件を満たしていなかったのかを具体的に示しています。2社の公開記事から、撤退の理由を整理します。
Segment：140超のサービスを1つに統合
顧客データ基盤のSegmentは、2018年7月10日の「Goodbye Microservices」で、送信先（デスティネーション）ごとに分けた140超のサービスを1つのサービスへ統合した経緯を公開しています。送信先は月に平均3つずつ増え、そのたびにリポジトリ・キュー・サービスが増えました。共通処理を共有ライブラリにまとめたものの、数十のサービスをテスト・デプロイし直す手間を避けて一部のサービスだけに新版を入れるうちに、ライブラリの版がサービスごとにばらばらになりました。最終的にはフルタイムのエンジニア3人が、システムを動かし続けることにほぼ時間を取られる状態になっています。
共有ライブラリの改善件数は、マイクロサービス構成だったときの32件に対し、統合の1年後には46件になり、1人のエンジニアが数分でデプロイできるようになりました。一方で、1つの送信先のバグがサービス全体を落とすようになり、障害の隔離は難しくなったと同じ記事が明記しています。
Prime Video：監視サービスをモノリスに戻しコストを90%以上削減
Amazon Prime Videoは2023年3月22日の技術ブログ記事（現在はInternet Archiveの保存版で読めます）で、映像・音声の品質監視サービスをAWS Step FunctionsとAWS Lambdaによる分散構成から、単一プロセスの構成へ移したと公表しました。分散構成では想定負荷のおよそ5%で拡張の限界に達し、コストはStep Functionsによるオーケストレーションと、構成要素間のデータ受け渡し（画像をAmazon S3に一時保存し、各検出器が取り出す処理）に集中していました。単一プロセスにまとめてデータをメモリ内で渡すようにした結果、インフラコストは90%以上下がり、数千本のストリームを監視できるようになったとしています。
この事例は「マイクロサービスは失敗だった」という話ではありません。対象はPrime Videoの中の1つのサービスで、記事自身も、マイクロサービスやサーバーレスは大規模でも機能する道具であり、モノリスとどちらを選ぶかはケースごとに判断すべきだと結んでいます。
2つの事例に共通する撤退の条件
2社に共通するのは、分割で得た独立性より、分割が生んだ運用と通信の負担の方が大きくなった点です。Segmentでは共有ライブラリを1つ直すたびに数十のサービスをテスト・デプロイし直す必要があり、その手間を避けた結果、版がばらばらになりました。Prime Videoでは構成要素の間でデータを受け渡すための呼び出しとオーケストレーションそのものが、コストと拡張の限界を生んでいました。分割を検討するときは「この境界の両側は別々に変わるか、別々にスケールするか」と「境界をまたぐ受け渡しのコストはいくらか」を先に確かめてください。
向き不向きを判断するチェックリスト
ここまでの条件を、採用前に確かめる項目にまとめます。まず、独立した変更やスケールなど、分割で解決したい課題があるかを確かめます（表の「目的」）。どちらも当てはまらないなら、マイクロサービスを選ぶ理由がありません。そのうえで、担当体制・境界の安定性・監視・デプロイの前提を確認します（表の「前提」）。満たせない前提があるなら、目的があっても時期尚早です。
| 確認項目 | 種類 | 当てはまらないとき |
|---|---|---|
| 機能ごとに変更頻度が大きく違う | 目的 | 独立デプロイの利点が出ない |
| 特定機能だけ負荷が跳ねる | 目的 | 全体のスケールで足りる |
| サービスごとに担当チームを置ける | 前提（組織） | 調整待ちが減らない |
| ドメインの境界が当面動かない | 前提（設計） | 境界の付け替えが高くつく |
| サーバーを数時間で用意できる | 前提（運用） | サービス追加が遅れる |
| 本番の異常を監視で検知できる | 前提（運用） | 障害箇所を特定できない |
| サービスごとに自動デプロイできる | 前提（運用） | リリースが手作業で詰まる |
| 他サービスと同時リリースせずに変更できる | 前提（設計） | 分散モノリスになる |
判断の結果は記録に残しておくと、数年後に「なぜ分けたのか／分けなかったのか」を検証できます。書き方はADR（Architecture Decision Record）とは｜書き方・Markdownテンプレート・design docとの違いを参考にしてください。
SOA・ESBとマイクロサービスの違い
マイクロサービスは、サービス指向アーキテクチャ（SOA）と「機能をサービスに分けて疎結合にする」という発想を共有しています。違いは、何を分けるのかと、サービス同士をどうつなぐのかにあります。
サービス指向アーキテクチャ（SOA）の目的
IBMのESBの解説によれば、SOAは1990年代後半に登場したソフトウェア・アーキテクチャで、ソフトウェア部品をサービス・インターフェイス経由で再利用できるようにする方法を定めたものです。各サービスは「顧客の与信照会」のような業務機能を丸ごと提供し、部門ごとに作られた既存システムを作り直さずに連携させる統合基盤として使われてきました。1つのアプリケーションの内部を分けるマイクロサービスに対し、SOAは企業内の複数システムをつなぐことに重心があります。
ESBとsmart endpoints and dumb pipesの違い
SOAで通信を仲介するのがESB（エンタープライズ・サービス・バス）です。IBMは、ESBを一元化されたソフトウェア・コンポーネントがアプリケーション間の統合を実行するアーキテクチャー・パターンと定義し、データモデルの変換、接続、メッセージのルーティング、プロトコルの変換を担うとしています。同じ解説は、多くの組織でESBがボトルネックになったとも書いています。1つの統合を変えると同じ統合を使う他の部分が不安定になりうるため、更新のたびに大がかりなテストが必要になり、アプリケーションチームは統合の順番待ちをするようになりました。
LewisとFowlerは、ESBのように通信の仕組み自体へルーティング・変換・業務ルールなどの知能を詰め込む方式に対し、マイクロサービスは「smart endpoints and dumb pipes」、つまり処理はサービス側に置き、通信路は単純なHTTPや軽量なメッセージングに保つと説明しています。同記事の「Microservices and SOA」の欄では、SOAという語が指すものが広すぎ、多くはモノリシックなアプリケーションをESBで統合する形だったため、マイクロサービスとは別物として扱う人もいれば、「正しく実践したSOA」と見る人もいると整理しています。
| 観点 | SOA（ESB型） | マイクロサービス |
|---|---|---|
| 分ける対象 | 企業内の複数システム | 1つのアプリケーション |
| サービスの単位 | 業務機能を丸ごと | 小さなビジネス機能 |
| 通信の知能 | ESBに集中 | 各サービス側 |
| データ | 共有されることが多い | サービスごとに持つ |
| 統治 | 中央で標準化 | チームごとに分散 |
ESBからの移行判断とアジャイル統合
既存のESBが変更の順番待ちを生んでいるなら、全面的にマイクロサービスへ作り替える前に、統合の単位を小さく分けて各チームが自分の連携を持つ形（IBMは「アジャイル統合」と呼んでいます）やAPI基盤への置き換えを検討する余地があります。金融機関の連携基盤を例にした判断は金融のシステム連携基盤｜EAI・ESBからAPI基盤へ移す判断と選定基準で解説しています。
向かないと判断したときの選択肢
チェックリストで「まだ早い」と出ても、モノリスのまま何もしなくてよいわけではありません。将来の分割に備えて、境界を先に整えておくことができます。
モジュラモノリスによる境界設計
Shopifyは2019年2月21日の「Deconstructing the Monolith」で、1,000人を超える開発者が10年以上手を入れてきたRuby on Railsのコードベースを、マイクロサービスではなくモジュラモノリスへ進化させると決めた理由を説明しています。コードは1つのコードベースに保ったまま、コンポーネント間の境界を定義して守らせる方式です。マイクロサービスにはマイクロサービスの課題があり、どの構成が合うかはアプリケーションの成長段階で変わる、というのが同社の判断でした。設計の詳細はモジュラモノリスとは？モジュール境界の設計とDB分割・依存検証の実装で解説しています。
ストラングラーフィグパターンによる段階移行
分割すると決めた場合も、一度に全体を作り替える必要はありません。負荷やリリース頻度の違いがはっきりした機能から1つずつ切り出し、旧システムへの経路を徐々に新サービスへ移すストラングラーフィグパターンが定石です。手順と切り戻しの設計はストラングラーフィグパターンとは？レガシー移行の実装手順と切り戻し設計を解説を参照してください。マイクロサービスそのものの定義やモノリスとの構造的な違いを整理したい場合はマイクロサービスとは？モノリスとの違い・メリット・デメリットと選び方、モジュラモノリスまで整理が入口になります。
よくある質問
マイクロサービスのデメリットは何ですか？
主なデメリットは、ネットワーク越しの呼び出しによる遅延と失敗の増加、複数サービスにまたがる障害調査の難しさ、サービス間のデータ整合性の設計、サービスごとのデプロイと監視の手間です。小規模なシステムでは、これらの負担が分割の利点を上回ります。
マイクロサービスが失敗する主な原因は何ですか？
多いのは、境界が固まらないうちに分割すること、共有ライブラリや共有データで結びついたまま分けて分散モノリスになること、監視と自動デプロイの基盤が無いまま始めることです。Segmentでは送信先ごとのサービスで共有ライブラリの版がばらばらになり、140超のサービスを1つのサービスへ統合しました。
ESBとマイクロサービスの違いは何ですか？
ESBは中央のコンポーネントがルーティングやデータ変換を担う統合方式で、マイクロサービスは処理をサービス側に置き、通信路を単純に保つ方式です。ESBは企業内の複数システムをつなぐSOAの構成要素で、マイクロサービスは1つのアプリケーションを分割する設計です。
サービス指向アーキテクチャ（SOA）とは何ですか？
ソフトウェア部品を標準的なサービス・インターフェイス経由で再利用できるようにする設計で、1990年代後半に登場しました。部門ごとに作られた既存システムを作り直さずに連携させる目的で使われ、多くはESBを通信の仲介役に置きます。
小規模なシステムでもマイクロサービスにすべきですか？
多くの場合は勧めません。Fowlerは新しいアプリケーションをまずモノリスで作る戦略を勧め、チームにマイクロサービスの構築経験が無いなら最初から分けるべきではないとしています（境界が見えやすい既存システムの置き換えは例外になりうるとも書いています）。少人数で全体を把握でき、独立してスケールさせたい機能も無いなら、モジュラモノリスで内部の境界を整えておき、分割の理由が出てから切り出す方が安全です。
