マイクロサービスとは?モノリスとの違い、サービスとデータベースの分け方、選ぶべきでないケースまで発注者目線で解説【2026年版】

「提案書に『マイクロサービスアーキテクチャを採用します』とあるのですが、これは当社に必要なものでしょうか」——システムの作り替えを検討している方から、こうした相談をよく受けます。役員会で「なぜ最新の方式を選ばないのか」と聞かれても、選ぶ理由も選ばない理由も説明できない。検索してみると、メリットが6つ、デメリットが4つ並んだ記事ばかりで、自社がどちらに当てはまるのかが分からない。そこで止まってしまいます。

結論から言うと、マイクロサービスとは、1つのアプリケーションを、独立してデプロイできる小さなサービスの集まりとして作る設計様式です。従来のように全体を1つの実行単位にまとめる作り方を、対比してモノリス(モノリシックアーキテクチャ)と呼びます。違いは「実行単位がいくつあるか」の一点で、優劣ではありません。

そしてここが大事なところですが、この方式を提唱した Martin Fowler 自身が「モノリスとして管理しきれないほど複雑なシステムでない限り、マイクロサービスを検討すべきではない」「大半のソフトウェアシステムは、単一のモノリシックアプリケーションとして作られるべきだ」と書いています。サービスを1つ増やせば、デプロイ経路が1本、監視の対象が1つ、障害時の当番が1人分増えます。分けた数だけ運用が増えるのが実情です。

本記事では、マイクロサービスの定義とモノリスとの違い、サービスをどう分けるか、データベースをどう分けるかと分散トランザクションの難しさ、サービス間通信とコンテナ・Kubernetes・可観測性という前提、そして選ぶべきでないケースとモジュラーモノリスという中間解の順に解説します。開発手法としてのアジャイル・スクラムの運用、スクラッチ開発の費用と分類、レガシーシステム刷新の進め方、開発会社の選び方は、本記事では扱わず、それぞれ既存の記事に譲ります。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。当社は開発会社ですから、分けて作るほうが人月は増えます。それでも、開発者が数名の組織にマイクロサービスをお勧めすることはありません。合わない案件にはその旨を率直にお伝えする、というのが当社の方針だからです。この記事を読み終えるころには、提案を受けたときに何を質問すればよいかが決められるはずです。

マイクロサービスとは——独立してデプロイできる小さなサービスの集まりとしてアプリケーションを作る設計様式

マイクロサービスとは、1つのアプリケーションを、それぞれ独立して動き、独立して更新できる小さなサービスの集まりとして作る設計の様式です。正式にはマイクロサービスアーキテクチャと呼びます。対になる考え方が、全体を1つの実行単位にまとめて作るモノリス(モノリシックアーキテクチャ)です。両者の違いは一点、実行単位がいくつあるかに尽きます。

定義——「小さなサービスの集まりとして1つのアプリケーションを作る」(Lewis & Fowler, 2014年)

この言葉を定義として最初に整理したのは、James Lewis と Martin Fowler が2014年3月に公開した記事「Microservices」です。そこでは、マイクロサービスアーキテクチャを「1つのアプリケーションを、それぞれが自分のプロセスで動き、HTTPのリソースAPIなど軽量な仕組みで通信する小さなサービス群として開発する手法」と説明しています。さらに、各サービスは業務上の機能を単位として作られ、完全に自動化された仕組みによって独立してデプロイでき、中央集権的な管理は最小限で、サービスごとに異なるプログラミング言語やデータ保存技術を使ってよい、と続きます。

同記事には「正確な定義は存在しない」とも書かれています。マイクロサービスは規格ではなく、共通する特徴の集まりとして語られている設計の傾向です。特徴として挙げられているのは、サービスによる部品化、業務機能を軸にした編成、プロジェクトではなくプロダクトとして持つこと、賢いエンドポイントと単純なパイプ、統制の分散、データ管理の分散、インフラの自動化、障害を前提とした設計、進化的な設計の9つです。

なお「マイクロ」という名前から大きさの議論になりがちですが、同記事は明確な基準を示していません。報告されている最大サイズの目安として、Amazonの「ツーピザチーム」(チーム全員がピザ2枚で足りる人数、つまり十数人まで)が紹介されている程度です。大きさではなく、独立して替えられるかどうかが判断の軸だと理解しておけば十分です。

モノリスとの違いは「実行単位がいくつあるか」——対比表

モノリスは、画面・業務ロジック・データベースへの読み書きが1つのプログラムの中で完結し、1つの実行単位として動きます。一部を直せば全体をビルドし直して入れ替えます。マイクロサービスは、同じ機能を複数のサービスに分け、それぞれを別々に入れ替えます。ここから先の違いは、すべてこの一点から派生します。

表の最終行が、この記事でいちばん伝えたい点です。上の9行は利点として語られやすい項目ですが、10行目は必ずセットでついてきます。Microsoft の Azure Architecture Center も「利点にはトレードオフがある」と書いたうえで、複雑さ、開発とテスト、統制の欠如、ネットワークの遅延、データの整合性、運用、バージョン管理、必要なスキルセットの8つを課題として挙げています。サービスを1つ増やすことは、機能を1つ増やすことではなく、運用を1セット増やすことです。

混同されやすい3語——SOA、SaaS、コンテナはマイクロサービスと同じではない

会議でよく混ざる語を3つ整理しておきます。

まずSOA(サービス指向アーキテクチャ)。Lewis と Fowler は、マイクロサービスはSOAの一形態だと考える人もいるが、SOAという言葉はあまりに多くのものを指してきたと述べています。実際に「SOA」として見かけるものの多くは、モノリシックなアプリケーション同士をESB(エンタープライズサービスバス)でつなぐ形で、マイクロサービスが目指す「賢いエンドポイントと単純なパイプ」とは逆向きです。似た発想の別物、と押さえてください。

次にSaaS。こちらはソフトウェアの提供形態(買い切りではなく、インターネット経由で利用する)を指す言葉で、内部構造の話ではありません。SaaSをモノリスで作ることもできますし、社内システムをマイクロサービスで作ることもできます。

最後にコンテナ。コンテナは、アプリケーションを動かすのに必要なものをひとまとめにして持ち運べるようにする技術です。マイクロサービスと相性がよく、ほぼ常にセットで語られますが、同じものではありません。コンテナを使えばマイクロサービスになるわけではなく、モノリスをコンテナで動かすことも普通にあります。

3語とも「マイクロサービスと同じ層の話ではない」という点が共通しています。では、分けると決めたとして、どこで切ればよいのでしょうか。ここからが実際の設計の話になります。

サービスをどう分けるか——技術レイヤーではなく業務機能で切る

分割は、マイクロサービスで最初にして最大の設計判断です。ここを外すと、以降のすべての作業が重くなります。境界の引き直しは、モノリスの中でクラスを移動させるのとはわけが違い、インターフェースの調整、互換性の維持、複数チームの合意が必要になるからです。Lewis と Fowler も「部品がきれいに分かれていなければ、複雑さがサービスの中からサービスの間へ移るだけだ」と書いています。

分割の基準は業務機能。画面・ロジック・データという層で切らない

大きなアプリケーションを分けるとき、多くの組織はまず技術の層で分けようとします。画面を作るチーム、サーバー側のロジックを作るチーム、データベースを見るチーム、という具合です。Lewis と Fowler は、この分け方をコンウェイの法則の表れとして批判しています。層で分けると、「注文画面に項目を1つ足す」という単純な変更でも3チームにまたがり、調整と承認のために時間と予算が要るようになります。

マイクロサービスの分け方はこれと逆です。業務上の機能を単位として、画面からデータの保存までを縦に串刺しにして1つのサービスにします。 受発注システムなら、「受注」「在庫」「出荷」「請求」といった単位です。各サービスのチームは、UI、データベース、プロジェクト管理までを含む横断的な構成になります。

この違いを、発注者の立場では「変更の見積もりが1社・1チームで閉じるかどうか」として見てください。閉じないなら、その分割は業務機能で切れていない可能性があります。

境界づけられたコンテキストとコンウェイの法則——組織の形が設計に出る

では業務機能の境界はどう見つけるのか。設計の世界で使われるのが、ドメイン駆動設計(DDD)の境界づけられたコンテキスト(Bounded Context)という考え方です。Microsoft の Azure Architecture Center は、マイクロサービスの設計にあたり、DDDで境界づけられたコンテキストを見つけ、そこからサービス境界を定義することを推奨しています。

境界づけられたコンテキストとは、同じ言葉が同じ意味で通じる範囲のことです。たとえば「顧客」という言葉は、営業から見た顧客と、サポートから見た顧客で、持っている属性も、そもそも対象に含まれるかどうかも違います。Lewis と Fowler も、営業側の顧客像とサポート側の顧客像は異なると同じ例を挙げています。言葉の意味が変わる場所が、境界の候補です。

もう1つ効いてくるのがコンウェイの法則です。1968年に Melvin Conway が述べた「システムを設計する組織は、その組織のコミュニケーション構造をそのまま写した設計を生み出す」という観察で、Lewis と Fowler も引用しています。裏を返せば、サービス境界とチーム境界が一致していないと、分けた形は維持されません。発注者の側でこれを確かめる方法はひとつです。「このサービスは、どこの誰が持ち続けるのか」を、サービスの数だけ答えられるか。 答えられない数のサービスは、作っても持ち主が決まらないまま残ります。

なお、この「小さなチームが自分の担当を持ち、短い周期で出していく」という進め方は、アジャイルやスクラムと相性がよいとされます。ただし開発手法そのもの、契約の組み方、スプリントの回し方は本記事の範囲外です。「アジャイル開発 外注」の記事と「スクラムとは」の記事に譲ります。

分けすぎると、複雑さが「サービスの中」から「サービスの間」へ移るだけ

分割でもう1つ多いのが、細かく分けすぎる失敗です。Microsoft の Azure Architecture Center は、ベストプラクティスの筆頭に「業務領域を軸にサービスを設計すること」を挙げたうえで、過度に細かいサービスを作ることを避けるよう明記しています。理由は、複雑さが増し、性能が落ちるからです。

細かく分けたときに何が起きるかを、具体的に並べます。

• サービス間のやり取りが増え、ネットワークの遅延が積み上がる。A が B を呼び、B が C を呼ぶ連鎖が長くなると、応答時間が読めなくなる
• 変更が複数サービスにまたがるようになる。一緒に変わるものが別のサービスに分かれていると、片方を直すたびにもう片方の更新が要る。これは密結合と低凝集の症状です
• 同期呼び出しが増えるほど、停止時間が掛け算で効いてくる。Lewis と Fowler はこれを「ダウンタイムの乗算効果」と呼び、同期呼び出しは有害だと注意しています

「サービスごとに好きな技術を選べる」という利点についても、同じ注意が要ります。Azure Architecture Center は、使う言語とフレームワークの数を制限して技術選択を標準化し、ログ・監視・デプロイについてはプラットフォーム全体の標準を決めるよう勧めています。自由は、統制のコストと引き換えです。言語が5つに増えた組織は、採用も、レビューも、脆弱性対応も5通り必要になります。

ここまでが「どこで切るか」の話でした。いま、自社のシステムについて、その境界を言葉にできるでしょうか。言えないうちは、分けるべきではありません。そして境界を引けたとしても、次に必ずぶつかる壁があります。データです。

データベースをどう分けるか——分散トランザクションという最大の難所

サービスを分けても、データベースを1つのまま共有すれば楽ではないか。多くの発注者が最初に思いつく発想で、そして実際にそうしてしまう現場も少なくありません。しかしここを共有した時点で、分けた意味の大半が失われます。一方で、分ければ今度は「全部成功か、全部取り消しか」という当たり前が成立しなくなります。この節が本記事でいちばんの難所です。

原則はサービスごとに1つ——データベースを共有した時点で分けた意味が薄れる

Lewis と Fowler は、モノリスが1つの論理データベースを好むのに対し、マイクロサービスは各サービスに自分のデータベースを持たせる、と書いています。同じ製品の別インスタンスでもよいし、まったく別の種類のデータベースでもよい。この考え方をポリグロット永続化と呼びます。Microsoft の Azure Architecture Center も「データストレージは、そのデータを所有するサービス専用にする」「コードやデータのスキーマを共有しない」をベストプラクティスとして挙げています。

なぜそこまで徹底するのか。データベースを共有すると、次の3つが起きるからです。

• スキーマを変えられなくなる。 テーブルの列を1つ変えるだけで、そのテーブルを読んでいる全サービスの確認が要る。独立してデプロイできるという前提が崩れます
• 境界が破られる。 本来はサービスA経由でしか触れないはずのデータに、サービスBが直接SQLで触りにいく。いったんこれを許すと、境界は書類の上だけのものになります
• 技術を選べなくなる。 共有スキーマは、固定の通信プロトコルと並んで、Azure Architecture Center が「結合の原因」として名指ししている項目です

逆に言えば、「データベースは1つのまま、アプリケーションだけ分ける」という提案を受けたときは、それがマイクロサービスなのかどうかを確かめる価値があります。分散の代償だけ払って、独立して替えられるという利点が手に入らない形になりがちだからです。

ACIDが効かなくなる——結果整合性とSagaパターン

データベースを分けると、最も厄介な問題が現れます。サービスをまたいだ「全部成功か、全部取り消しか」が保証できなくなることです。

1つのデータベースの中であれば、トランザクションという仕組みが、原子性・一貫性・分離性・持続性(頭文字をとってACID)を守ってくれます。注文を確定し、在庫を引き当て、決済を実行する——この3つが1つのデータベースで完結していれば、途中で失敗した場合は全部なかったことにできます。ところがこれが「注文サービス」「在庫サービス」「決済サービス」に分かれると、3つの別々のデータベースへの書き込みになり、データベースの保証はそれぞれの中にしか及びません。

Lewis と Fowler は、分散トランザクションは実装が非常に難しいことで知られていると述べ、マイクロサービスではトランザクションを使わない協調を重視し、整合性は結果整合性(eventual consistency)に留まると明示的に認め、問題は補償操作で扱うと書いています。Microsoft の Azure Architecture Center も、複数サービスにまたがる更新が ACID とみなせる可能性は低く、可能な限り結果整合性を優先するよう勧めています。

その実現方法として最もよく使われるのがSagaパターンです。Azure Architecture Center の説明に沿って要点をまとめると、こうなります。

• トランザクション全体を、サービスごとのローカルトランザクションの連なりに分解する
• 各サービスは自分のデータベースを更新し、イベントやメッセージで次の手順を起動する
• どこかで失敗したら、補償トランザクションを順に実行して、それまでの変更を打ち消す
• 打ち消せない地点(ピボットトランザクション)を越えたら、後戻りせず最後まで完了させる

進め方には2通りあります。

どちらを選んでも、Azure Architecture Center が挙げる考慮点は残ります。デバッグが難しくなること、各サービスは自分のデータベースへ確定済みなので単純には巻き戻せないこと、補償トランザクション自体が失敗しうること、そして更新の取りこぼし・未確定データの読み取り・読み取りのたびに値が変わるといったデータ異常が起きうることです。

発注者にとっての意味はひとつです。 「途中で失敗したらどうなりますか」という質問に、開発会社が業務の言葉で答えられるかどうか。「在庫は引き当て済みだが決済が失敗した場合、引き当てを自動で戻す。戻せなかった場合は運用担当に通知が飛ぶ」という粒度で答えが返ってくるなら、設計されています。「トランザクションで守ります」としか返ってこないなら、まだ設計されていません。

分けたあとに残る仕事——重複データ、横断の集計、業務側の運用

データを分けると、それまで意識しなくてよかった仕事が3つ出てきます。

1つ目はデータの重複です。在庫サービスが商品名を持ち、受注サービスも表示用に商品名を持つ、といった形です。これは避けるべき無駄に見えますが、Azure Architecture Center は「どんな代償を払ってでもデータの重複を避けようとするのはアンチパターン」であり、ローカルコピーを持つほうがサービスの自律性が高まると書いています。重複させるかどうかではなく、どちらが正で、いつ追いつくのかを決める問題になります。

2つ目は横断の集計です。「先月の受注のうち、出荷済みで未入金のものを一覧する」といった業務レポートは、1つのデータベースなら結合1回で済みます。分けた後は、どこかに集計用のデータを集める仕組みが別途要ります。刷新プロジェクトで見落とされやすいのがここで、既存システムでは当たり前だった帳票が、そのままでは作れなくなります。

3つ目は業務側に残る運用です。結果整合性を採るということは、「一時的にずれている時間帯がある」ことを業務として許容するという意味です。ずれたまま止まってしまったときに、誰がどう直すのか。画面から直せるのか、開発会社に依頼するのか。ここを決めないまま本番に入ると、最初の月末で困ります。決めていない運用当番は、障害の夜には決められないのが実情です。

整合性の崩れ方は、大きく3つです。更新が上書きされて消える。まだ確定していない値を別の処理が読んでしまう。同じ処理の中で、読むたびに値が変わる。どれも1つのデータベースでは起きなかったものです。分けるという判断は、この3つを引き受けるという判断でもあります。

サービス間通信と、動かし続けるための前提——REST・gRPC・メッセージング、コンテナ、可観測性

分けたサービスは、ネットワーク越しに会話しながら1つの機能を果たします。そして分けた瞬間から、プログラム内部の関数呼び出しでは起きなかったことが起きます。相手が応答しない、遅い、同じ依頼が二重に届く。この節では、通信方式の選び方と、分けた構成を動かし続けるために必要な土台を、発注者が判断できる粒度で整理します。

同期通信(REST・gRPC)と非同期通信(メッセージング)——比較表

Lewis と Fowler は、マイクロサービスで最もよく使われる通信方式として、HTTPのリクエスト・レスポンス(リソースAPI)と、軽量なメッセージングの2つを挙げています。そのうえで、複雑な仕組みを通信経路に持たせるのではなく、賢いエンドポイントと単純なパイプにすべきだとしています。

代表的な3方式を並べます。

gRPC は Google が公開している通信の仕組みで、公式ドキュメントによれば、クライアントが別のマシン上のサーバーのメソッドを、あたかも手元のオブジェクトのメソッドであるかのように直接呼び出せるようにするものです。既定では Protocol Buffers という形式でデータをやり取りし、.proto という定義ファイルから各言語のコードを生成します。Java で書いたサーバーに、Go・Python・Ruby のクライアントからつなぐ、といった組み合わせができます。

非同期通信については、Microsoft の Azure Architecture Center が、Apache Kafka や Azure Service Bus のようなメッセージング基盤が疎結合を促し、イベント駆動アーキテクチャの基盤になると説明しています。同時に、独自のメッセージング処理を自作せず、経路制御・再試行・永続化・ワークフローを扱うフレームワークを採用するよう勧めています。

もう1つ、クライアントとの間に置かれるのがAPIゲートウェイです。利用者側は個々のサービスを直接呼ばず、ゲートウェイに要求を送り、ゲートウェイが適切なサービスへ転送します。認証、ログ記録、負荷分散といった横断的な処理をここに集めます。Azure Architecture Center は、マイクロサービスを利用者に直接公開することをアンチパターンとして挙げ、同時にゲートウェイに業務ルールやドメイン知識を持たせないよう注意しています。入口は1つ、判断はサービス側、と覚えてください。

コンテナとKubernetes——マイクロサービスの前提であって、同義ではない

サービスが増えれば、それを配置し、動かし続ける仕組みが要ります。ここでコンテナと Kubernetes が出てきます。

Kubernetes の公式ドキュメントは、Kubernetes を「コンテナ化されたワークロードやサービスを管理するための、宣言的な構成管理と自動化を促進するプラットフォーム」と定義しています。提供する機能として、サービス検出と負荷分散、ストレージの自動マウント、ロールアウトとロールバックの自動化、自動ビンパッキング、自己修復、機密情報と構成の管理、水平スケーリングなどが挙げられています。Azure Architecture Center も、サービスをノード間に配置し、障害を検出し、需要に応じて自動で増減させる役割を、Kubernetes のようなコンテナオーケストレーションのプラットフォームが担うと説明しています。

CNCF(Cloud Native Computing Foundation)の Cloud Native Definition v1.1(2024年2月承認)は、クラウドネイティブの技術・アーキテクチャを「コンテナ、サービスメッシュ、マルチテナンシー、マイクロサービス、イミュータブルインフラストラクチャ、サーバーレス、宣言的APIなどの組み合わせ」と表現しています。マイクロサービスは、この並びの1要素です。

ここで念を押しておきたいのは、コンテナや Kubernetes を使っていることと、マイクロサービスであることは別だという点です。モノリスをコンテナで動かすことも、Kubernetes 上で動かすこともできます。提案書に Kubernetes と書いてあることは、構造の説明にはなりません。

なお、サービス間の通信を専門に扱う層を置くサービスメッシュという選択肢もありますが、これは運用が一段増える話なので、最初から必要と考えないでください。独立デプロイを支える自動化(CI/CD)については、本番反映の流れと合わせて「デプロイとは」の記事で扱っています。

可観測性——ログ・メトリクス・分散トレーシングがないと、障害の原因にたどり着けない

分けた構成で最初に困るのは、性能でも費用でもなく、障害の原因がどこにあるか分からないことです。利用者から「注文が完了しない」と連絡が来たとき、注文サービス、在庫サービス、決済サービス、その間のメッセージ基盤のどこで止まったのかを、ログを1つずつ見て回ることになります。

Azure Architecture Center は、有効な可観測性の戦略として、ログの一元化、OpenTelemetry などを使ったリアルタイム監視、そしてサービス境界を越えて1つの要求を追跡する分散トレーシングを挙げています。ベストプラクティスにも「一元的なログ記録、分散トレーシング、メトリクス収集を実装する」と明記されています。Lewis と Fowler も、マイクロサービスは実時間の監視に大きな比重を置くと述べ、アーキテクチャ上の指標(データベースが毎秒何件の要求を受けているか)と業務上の指標(毎分何件の注文が入っているか)の両方を見るべきだとしています。障害を前提に設計し、サーキットブレーカーやタイムアウトで連鎖を止める、という考え方もここに含まれます。

数えてみてください。サービスを1つ増やすと、コードのリポジトリが1つ、デプロイの経路が1本、監視の対象が1つ、アラートの当番が1人分、増えます。 10サービスなら10セットです。当社では品質管理として、日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックの3点を標準にしていますが、これも分けた数だけ回数が増えます。土台が揃っていない組織が先に分割だけ進めると、動かなくなったときに戻れなくなります。

マイクロサービスを選ぶべきでないケースと、モジュラーモノリスという中間解

ここまで読んで、思ったより大変だと感じた方は、正しく読めています。この節では、いつ選ぶべきでないのかを、提唱者自身の記述を根拠に整理します。そのうえで、モノリスかマイクロサービスかの二択ではない第三の道を示します。当社は開発会社ですから、分けて作るほうが人月は増えます。それでも、この節の結論は変わりません。

提唱者が書いていること——「モノリスで管理しきれないほど複雑でない限り、検討しない」

Martin Fowler は2015年5月の記事「Microservice Premium」で、次の趣旨を書いています。マイクロサービスは複雑なシステムを扱うための手法だが、そのために自分自身の複雑さを持ち込む。自動化されたデプロイ、監視、障害への対処、結果整合性など、分散システムが持ち込む課題に取り組まなければならない。これはプロジェクトの費用とリスクに上乗せされる割増料金であり、しばしばプロジェクトを深刻な事態に陥れる、と。

そして結論として、「モノリスとして管理しきれないほど複雑なシステムでない限り、マイクロサービスを検討すらすべきではない」「大半のソフトウェアシステムは、単一のモノリシックアプリケーションとして作られるべきだ」と述べています。そのうえで、モノリスの中の modularity(部品としての分かれ方)には注意を払え、ただし別々のサービスに切り離そうとするな、と続きます。

もう1つ、同年6月の「Monolith First」では、こう観察しています。成功したマイクロサービスの事例は、ほぼすべて大きくなりすぎたモノリスを分割したところから始まっている。一方、最初からマイクロサービスとして作られたシステムの話は、深刻な問題に陥った例ばかりだ、と。理由として、新しいアプリケーションが利用者の役に立つかどうかは作ってみないと分からないこと(YAGNI)、そしてサービス間の良い境界は経験豊富な設計者でも最初から引くのが難しく、モノリスで作ってみて初めて正しい境界が見えてくることを挙げています。

Microsoft の Azure Architecture Center も、課題の最後に「スキルセット」を挙げ、マイクロサービスは高度に分散したシステムであるから、チームに成功するためのスキルと経験があるかを慎重に評価するよう求めています。「新しいから」「拡張性が上がるから」は、採用の理由になりません。

選ぶべきでない5つのケース——判断表

一次情報の記述を、発注者が自社に当てはめられる形に翻訳すると、次の5つになります。ひとつでも当てはまるなら、いまは選ばないほうが安全です。

1と4が特に多い組み合わせです。「人は足りていないが、方式は最新にしたい」という要望は、順序を逆にしてしまっています。土台のないまま分けるのは失敗のもとです。

モジュラーモノリス——境界だけを手に入れる中間解(Shopifyの公開事例)

「モノリスは限界。でもマイクロサービスは重すぎる」という状況に対する答えが、モジュラーモノリスです。すべてのコードを1つのアプリケーションとして動かしたまま、業務領域ごとの境界を厳密に定義して守る作り方を指します。

Shopify は2019年2月、同社の技術ブログ「Deconstructing the Monolith」で、この選択を公開しています。同社は Ruby on Rails の巨大なコードベースを10年以上、1,000人を超える開発者で育ててきましたが、2016年ごろに限界の兆候が出ました。公開されている記述をまとめると、次のようなものです。

• 一見ささいな変更が、無関係に見えるテストを大量に落とすようになった。配送料の計算コードが税率の計算コードを呼んでいたため、税率側の変更が配送料側の結果に影響した
• 新しく入った開発者が、最初の機能を出すまでに必要な前提知識が膨大になった。配送チームに入った人が、注文の作られ方や決済の処理まで理解しないと着手できない状態だった

同社は、これらの原因が「境界がないこと」だと特定しました。そのうえでマイクロサービスを検討しましたが、テストとデプロイの経路を複数維持する負担、サービスごとのインフラの負担、ネットワークを越えることによる遅延と信頼性の低下、複数サービスにまたがるリファクタリングの手間を挙げ、デプロイ単位を増やさずにモジュール性だけを高める道としてモジュラーモノリスを選びました。ブログには「万能の最適解はなく、マイクロサービスはマイクロサービスなりの課題をもたらす」という趣旨も書かれています。

実際にやったことは、コードの並べ方を「モデル・ビュー・コントローラー」という技術の概念から、「注文・配送・在庫・請求」という現実の業務の概念へ並べ替えることでした。これは前の節で説明した「業務機能で切る」と同じ作業です。分割の設計だけ先に済ませ、デプロイは1つのままにしておく。 後から本当に分ける必要が出たときには、境界がすでにあるので移行しやすくなります。Fowler が「モノリスの modularity には注意を払え」と書いているのは、この作業のことです。

なお、既存の古いシステムを止めずに少しずつ置き換えていく進め方(段階移行)もあります。刷新のアプローチの分類や現状把握の手順は本記事の範囲外なので、「レガシーシステム 刷新 外注」の記事に譲ります。作るか、既製品を使うか、どこまで自前で作るかという分類は「スクラッチ開発とは」の記事にまとめてあります。

発注者としての判断——作り替えと新規開発で聞くべき3つの質問

提案を受けた側として確かめるのは、次の3点です。技術の知識は要りません。

1. 「サービスをいくつに分ける想定ですか。それぞれ、どこの誰が持ち続けますか」——数と持ち主が一致しないなら、運用が破綻します
2. 「途中で失敗したらどうなりますか」を業務の言葉で——「在庫の引き当てを自動で戻し、戻せない場合は担当者へ通知」のように答えが返るかどうか
3. 「モジュラーモノリスでは、この要件を満たせない理由は何ですか」——満たせない理由が具体的に出てくるなら、分ける根拠があります。出てこないなら、分ける必要はまだありません

当社にも「提案書にマイクロサービス化とあるが、社内で説明できない」という相談がよく届きます。多くの場合、3つ目の質問で結論が出ます。要注意なのは、理由が「将来のスケールに備えて」だけのときです。備えの費用は、将来ではなく毎月かかります。

マイクロサービス構成の開発・保守を外部チームで持つときの体制——当社のラボ型

ここまでの結論を踏まえたうえで、それでも分ける必要がある規模のシステムを、外部のチームと一緒に持つ場合の話をします。当社はベトナム・ホーチミンを拠点に、日本人PMをフロントに置いたラボ型の開発チームを提供しています。マイクロサービス構成に限った話ではありませんが、この構成は体制の持ち方がとりわけ効いてきます。

分けた構成は「終わらない開発」になる——請負よりも継続的な体制と噛み合う

サービスを分けると、開発はイベントではなく状態になります。サービスごとに改修が続き、依存しているライブラリの更新が続き、監視のしきい値の調整が続きます。Lewis と Fowler が「プロジェクトではなくプロダクトとして持つ」と書いているのは、この性質を指しています。

完成品を納めて終わる請負契約は、この形と噛み合いません。作り切った後に誰も持たないサービスが残り、脆弱性の通知が来ても誰も動かない、という状態になりやすいからです。準委任で継続的にチームを確保するラボ型のほうが、受け皿として素直です。契約形態そのものの比較は、「ラボ型開発とは」の記事に譲ります。

当社の体制——日本人PMの設計レビューと、プルリクエストによるコードレビュー

当社の体制は2パターンです。パターンAは日本人PMまたはブリッジSEをフロントに置き、その後ろにエンジニアを配置する形で、こちらを推奨しています。パターンBはエンジニアのみの構成です。1名から編成でき、最短2週間で開始、増員は約1週間、縮小や交代は1か月単位で対応します。

品質管理は3点を標準にしています。日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、そしてリリース前のダブルチェックです。サービス境界の設計は、この1点目で必ず見ます。分ける理由が業務の言葉で説明できない分割は、作る前に止めます。

エンジニアは、グループで保有する2,000名以上のIT人財データベース(日本勤務経験のあるN1〜N2相当の人財を含む)から直接アサインします。協力会社や紹介を経由しないため、仲介マージンは発生しません。公開している単価は、実務3年目安で1,500USD(約22.5万円 / 1USD=150円換算目安)、5年で2,000USD、10年クラスおよびブリッジSEで3,000USDです。最小構成は日本人PMフロント+2〜3人月で、月額約80万円からになります。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。

ベトナムと日本の時差は2時間で、日本の午前が現地の早朝にかからないため、日本時間の午前中に同期して作業できます。法定祝日は2026年で年12日(労働法112条の条文上は11日で、2026年からベトナム文化の日が加わります)、2026年のテト(旧正月)は2月14日から22日です。実績としては、介護記録SaaS「CareViewer」で日本語のできるブリッジSE1名とフルスタックエンジニア2名の体制を組み、週次で優先順位を判断しながら継続開発しています。決済アプリではStripe連携、二要素認証、ウォレット、PDF出力を新規に構築し、そのまま週次の保守へ移行しました。

向く案件・向かない案件と、これから開発を発注する方へ

正直に線を引きます。当社のラボ型が向くのは、継続的に手を動かす必要があり、機能の優先順位を毎週決めていける案件です。既存サービスの機能追加と保守、複数サービスに分かれた構成の継続開発、そして分ける前の段階で境界を設計しながら作っていく案件が該当します。

向かないのは、要件が確定していて一度きりで終わる案件、常時の障害当番(夜間のオンコール)を外部だけで完結させたい案件、そしてそもそも分ける必要がない規模なのに分割ありきで進めたい案件です。3つ目については、その旨を最初にお伝えしています。発注先を探す段階の判断基準は、「システム開発会社 選び方」の記事にまとめてあります。

これから開発を発注する方は、方式を決める前に、この記事の3つの質問(いくつに分けるか・誰が持つか / 途中で失敗したらどうなるか / モジュラーモノリスで足りない理由)を手元に置いてください。方式は手段であって、決めるべきは自社が何年、誰と、どう持ち続けるかです。

【FAQ】マイクロサービスに関するよくある質問

マイクロサービスについて、発注側の担当者からよく受ける質問を5つ挙げます。いずれも技術の正解ではなく、自社で判断するための材料としてお読みください。

Q1. マイクロサービスとモノリスは、どちらが優れているのですか

優劣はありません。Martin Fowler は、マイクロサービスは複雑なシステムを扱うための手法であり、それ自体が複雑さを持ち込むと書いています。システムが大きくなりすぎて変更もデプロイもできない状態になったときに初めて、分ける利点が代償を上回ります。それ以前の規模では、モノリスのほうが速く安く作れます。

Q2. 開発者が数名の小さな組織でも、マイクロサービスにすべきですか

お勧めしません。サービスを1つ増やすと、デプロイ経路・監視対象・障害時の当番が1セットずつ増えます。数名の組織では、機能を作る時間が運用に消えます。Fowler も「大半のソフトウェアシステムは単一のモノリシックアプリケーションとして作られるべきだ」と書いています。境界が必要なら、モジュラーモノリスで十分です。

Q3. マイクロサービスにすると、開発費用は安くなりますか

安くなりません。初期の設計工数が増え、稼働後も監視と運用の固定費が乗ります。費用が下がる可能性があるのは、負荷の高い一部のサービスだけを増やせるという点でのインフラ費用ですが、その効果が運用の増分を上回るのは、相当の規模に達してからです。見積もりを比べるときは、初期費用だけでなく、稼働後12か月分の保守費用を並べて比べてください。

Q4. コンテナやKubernetesを使えば、マイクロサービスになるのですか

なりません。コンテナはアプリケーションを持ち運べる形にまとめる技術、Kubernetes はコンテナ化されたワークロードを管理するプラットフォームです。モノリスをコンテナに入れて Kubernetes で動かすことも普通にあります。提案書に Kubernetes と書かれていても、それは構造の説明ではないので、「サービスをいくつに分ける想定か」を別途確認してください。

Q5. 既存のシステムを分けたい場合、最初に何をすべきですか

コードを触る前に、業務の棚卸しです。どの業務がどの業務と独立して動いているか、同じ言葉が違う意味で使われている場所はどこかを洗い出し、境界の候補を言葉にします。その境界を、まずは1つのアプリケーションの中のモジュールとして実装して運用してみる。Shopify が公開しているのも、この順序です。分けるかどうかの判断は、境界が安定してからで遅くありません。最初にやるのは分割ではなく、境界の言語化。

まとめ: マイクロサービスは複雑さへの対処法——分けた数だけ運用が増える

マイクロサービスとは、1つのアプリケーションを、独立してデプロイできる小さなサービスの集まりとして作る設計様式です。全体を1つの実行単位にまとめるモノリスとの違いは「実行単位がいくつあるか」の一点で、優劣ではありません。分ければ、変更の影響は狭くなり、混んでいるサービスだけを増やせるようになります。その代わり、デプロイ経路・監視対象・障害時の当番が、サービスの数だけ増えます。SOAもSaaSもコンテナも、マイクロサービスと同じ層の話ではありません。Kubernetesを使っていることは、構造の説明にはならないと覚えておいてください。

分けるときは、画面・ロジック・データという技術の層ではなく、業務機能で切ります。同じ言葉が違う意味で使われる場所が境界の候補で、その境界はチームの形と一致していなければ維持されません。そして最大の難所がデータです。データベースはサービスごとに持つのが原則で、共有した時点で独立して替えられるという利点が消えます。分けると「全部成功か、全部取り消しか」が保証できなくなり、結果整合性とSagaパターン(補償トランザクション)という別の設計が必要になります。「途中で失敗したらどうなりますか」に業務の言葉で答えが返るかどうかが、設計されているかの判定線です。

提唱者のMartin Fowlerは「モノリスとして管理しきれないほど複雑なシステムでない限り、マイクロサービスを検討すべきではない」と書いています。開発者が10名に満たない、要件がまだ動いている、分ける理由を業務の言葉で言えない、自動テストと監視の土台がない、業務が一時的なデータのずれを許容できない——このどれかに当てはまるなら、いまは選ばないでください。境界だけが欲しいなら、モジュラーモノリスという中間解があります。Shopifyが2019年に公開したのも、その選択でした。既存システムを段階的に置き換える進め方はレガシーシステム刷新の外注に、作る・作らないの分類はスクラッチ開発とはにまとめてあります。当社はホーチミンを拠点に、日本人PMをフロントに置いたラボ型の開発チームを提供しています。設計レビューの段階で、分ける理由が言えない分割は作る前に止めます。1名・最短2週間から、最小構成は月額約80万円です。現在の体制と要件をお聞かせいただければ、分けるべきかどうかの判断も含めて概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。