最終更新日：
マイクロサービスとモノリスの優劣を、サービス数やデプロイ形態だけで論じても、複雑性の本質は見えてこない。アーキテクチャとは複雑性を消去する技術ではなく、複雑性を分割・局所化し、別の場所へ移し、誰が引き受けるかを決める技術である。本稿では、ドメイン、コード構造、分散実行、データ、運用、組織、認知という「複雑性の台帳」を用い、マイクロサービスとモノリスを複数の設計軸へ分解する。
複雑性に抗ううえで重要なのは、局所的に推論し、変更を完結できる範囲を保つことである。そのために、一緒に変わるものを近づけ、独立して変わるものを分け、境界の強度を必要性に応じて選ぶ。価値ある複雑性はコア・ドメインで引き受け、周辺領域は標準化、購入、委譲、プラットフォーム化する。ただし、外部化は複雑性の消滅ではなく、統合や契約の複雑性への移送である。
人工知能（Artificial Intelligence、以下AI）は実装など一部の作業コストを変えるが、設計、検証、統合、責任の問題をなくさない。むしろ変更量が増えるほど境界と自動検証は重要になる。AIが直接減らすのはエンジニア総数というより、一つの価値提供単位を成立させる最小チーム規模かもしれない。最終的に問うべきは「マイクロサービスかモノリスか」ではなく、「人間が理解し、変更し、責任を持てる範囲へ、複雑性をどう閉じ込め続けるか」である。
ソフトウェアの構成をめぐる議論では、しばしば「マイクロサービスとモノリスのどちらを選ぶべきか」と問われる。マイクロサービスは俊敏で拡張しやすく、モノリスは単純だがやがて身動きが取れなくなる――。この対比は直感的で、経営層にも開発者にも説明しやすい。しかし、実際のシステムが抱える問題を理解するには、あまりに大ざっぱである。
そもそもマイクロサービスは、小さなプログラムを多数並べることだけを意味しない。LewisとFowlerによる整理では、ビジネス能力を中心としたサービス構成、サービスごとの独立したデプロイ、分散的なデータ管理、障害を前提とした設計など、複数の性質を束ねたアーキテクチャスタイルとして説明されている（Lewis & Fowler, 2014）。その狙いは、システムを細かく見せることではない。ある変更を、ほかの部分やほかのチームとの大がかりな調整なしに完結できるようにすることである。
一方、モノリスという言葉が直接表すのは、主として一つのまとまりとして配置される形態である。ところが実務では、単一のプロセス、単一のリポジトリ、単一のデータベース、一括リリース、さらには内部のモジュール境界がない状態まで、一つの言葉に押し込まれがちだ。これらは別々の設計判断であり、必ずしも同時に成立するものではない。単一のデプロイ単位であっても、内部が明確なモジュールに分かれ、変更影響を局所化できるシステムはある。反対に、サービスが多数あっても、変更のたびに一斉改修と一斉リリースを要するなら、実質的には一つの巨大なシステムとして振る舞う。
したがって、マイクロサービスとモノリスは厳密な対義語ではない。比較すべきなのは外から数えられるサービスの個数ではなく、変更、テスト、デプロイ、データ所有、意思決定をどこまで独立させる必要があり、実際に独立させられているかである。DORAが示す疎結合なチームの能力も、特定の方式の採用ではなく、他チームへの依存を抑えて設計変更やテスト、デプロイを進められることに焦点を当てている（DORA, 2025）。ネットワーク越しに分割したという事実だけでは、この能力は得られない。
ここで議論の焦点を、方式の優劣から複雑性の扱いへ移したい。複雑性は、コードの量やサービスの数だけから生まれるのではない。業務ルール、状態と時間、データの整合性、運用、組織間の調整、そして人間が一度に理解できる範囲からも生じる。ある場所を単純にする判断が、通信障害や契約管理といった別の難しさを生むこともある。アーキテクチャとは、複雑性を消去する魔法ではなく、それを分割し、局所化し、別の場所へ移し、最終的に誰が引き受けるかを決める営みなのである。
本稿ではまず、マイクロサービスとモノリスという二つの言葉に詰め込まれた設計判断を分解する。続いて、複雑性の発生源と移送先を、ドメイン、コード構造、分散実行、データ、運用、組織、認知という「複雑性の台帳」に整理する。そのうえで、境界と階層、コア・ドメインへの設計努力の集中、チーム構造、人工知能（Artificial Intelligence、以下AI）がもたらす変化を検討する。
問うべきは「マイクロサービスか、モノリスか」ではない。何を独立して変えたいのか、そのためにどの境界をどの強さで設けるのか、そして境界の代価を誰が負担するのかである。この問いから出発すれば、流行する方式を選ぶことではなく、人間が理解し、変更し、責任を持てるシステムをつくることへ議論を戻せる。
マイクロサービスを、コードを細かく切り分ける技法として理解すると、その価値も失敗も説明しにくい。重要なのは一つひとつのサービスの大きさではなく、何を独立させるために分けるのかである。LewisとFowlerによるマイクロサービスの整理では、ビジネス能力を中心とした構成、独立したデプロイ、分散的なデータ管理などが共通の特徴として挙げられている（Lewis & Fowler, 2014）。これらを束ねているのは、大規模なシステムと組織において、変更に伴う調整を一定の範囲へ閉じ込めたいという要求である。
一つの機能を変更するたびに、複数のチームが同じ会議へ集まり、共通の試験環境を予約し、全体のリリース日を合わせなければならないとする。この状況では、コードを書く時間が短くても、価値を届けるまでの時間は短くならない。サービスをビジネス能力に沿って分け、小規模なチームが実装、テスト、データ、運用までを担えれば、チームはほかのチームの予定を待たずに判断しやすくなる。マイクロサービスは、技術的な分割を通じて、意思決定と調整の範囲を局所化しようとしたのである（Lewis & Fowler, 2014; Newman, 2021）。
ここでいうビジネス能力とは、受注、請求、配送のように、事業が結果を出すために備える一まとまりの能力を指す。画面、業務処理、データベースといった技術層ごとにチームを分けると、一つの顧客価値を届けるために複数チームを横断しやすい。これに対し、ビジネス能力を中心にサービスと責任を揃えれば、変更理由が共通するコードとデータを近くに置ける。ただし、業務上の境界が曖昧なままサービスだけを切り出しても、依存関係は消えない。ネットワーク越しの呼び出しとして見えにくくなるだけである。
独立デプロイも、それ自体が最終目的ではない。あるサービスを単独で本番環境へ配置できても、その変更に先立って別チームの承認や別サービスの同時改修が必要なら、独立した変更は実現していない。独立デプロイは、設計、テスト、互換性、データ所有、運用責任が十分に分離されているかを確かめる指標と考える方がよい。単独で安全に変更できることが先にあり、単独で配置できることはその結果である。
DORAの「疎結合なチーム」も、チームが他チームにほとんど依存せず、設計変更、テスト、デプロイを完結できる能力に注目している（DORA, 2025）。ただし、こうした組織調査が示すのは、疎結合性や、変更を小さく継続的に本番へ届ける能力と良好な成果との関連である。「マイクロサービスを採用すれば生産性が上がる」という単純な因果を証明するものではない。優れた運用能力や明確な責任分担を持つ組織だからこそ、適切なサービス分割を扱えている可能性もある。
分割には、明確な代価もある。プロセスを越える通信には遅延と障害があり、呼び出しの再試行や重複、順序のずれを考慮しなければならない。サービスごとにデータを所有すれば、一つのデータベース内では容易だった整合性の保証も難しくなる。さらに、サービスの状態を横断して観測する仕組み、インターフェースの互換性管理、デプロイ基盤、障害時の運用能力が必要になる（Newman, 2021）。分割によって得たい独立性が曖昧なら、組織上の結合を残したまま、分散システムの費用だけを加えることになる。
したがって、マイクロサービスの成否をサービスの小ささや個数で測るべきではない。価値提供に必要な変更を、責任を持つチームが自律的に理解し、検証し、本番へ届けられるか。その独立性が分散システムの代価に見合うとき、マイクロサービスは有効な境界となる。
モノリスはしばしば、巨大で変更しにくいコードの塊を意味する言葉として使われる。しかし、本来の配置形態と内部の設計品質は分けて考える必要がある。一つの単位としてデプロイされることは、内部に境界がないことを意味しない。逆に、複数のサービスとしてデプロイされていることも、変更が分離されている保証にはならない。
議論を整理するため、本稿では「モノリス」という言葉に混在する性質を、少なくとも七つの軸へ分ける。すなわち、デプロイ単位、実行プロセス、ソースコードのリポジトリ、データベース、内部のモジュール構造、所有するチーム、リリース運用である。これは確立した分類法ではなく、何が本当に一体化しているのかを見極めるための本稿独自の分析枠組みである。
たとえば、一つのリポジトリにコードを置き、一つのプロセスとしてデプロイしながら、受注、在庫、請求を明確なモジュールに分けることはできる。各モジュールが公開したインターフェースを通じてのみ連携し、内部データへ直接触れないなら、変更影響をその内部へ閉じ込めやすい。反対に、リポジトリと実行プロセスが分かれていても、複数サービスが同じデータベースの表を直接更新し、変更のたびに同時リリースを要するなら、実質的な変更単位は分かれていない。
この違いを支える古典的な原則が情報隠蔽である。Parnasは、処理手順の段階ごとにモジュールを分けるのではなく、将来変更され得る設計判断を各モジュールの内部へ隠すことを提案した（Parnas, 1972）。データ表現や業務規則の実装方法が外部へ漏れなければ、それを変えるために理解すべき範囲は小さくなる。この原則に、プロセスが一つか複数かという条件はない。単一プロセスでも、情報を隠す境界が保たれていれば、論理的には十分にモジュール化できる。
そこで、外形の似たシステムを区別する言葉が役に立つ。モジュラーモノリスは、一つのデプロイ単位の内部に、責任と依存方向が明確なモジュールを持つ。これに対し、「巨大な泥団子」は、内部の依存が無秩序に絡み、ある変更がどこへ波及するか予測しにくい状態を指す。分散モノリスは、配置上は複数サービスでありながら、共同データベース、同期的な呼び出しの連鎖、一斉変更などによって、全体を一つとして扱わなければならない状態である。問題はモノリスという名前ではなく、境界が設計判断を隠せているかどうかにある。
もちろん、論理的な境界は規律だけでは破られることがある。同じプロセス内では、別モジュールの内部クラスやデータへ技術的にアクセスできてしまう場合が多い。プロセスやネットワークの境界を設ければ、公開された契約以外の利用を機械的に制限しやすい。しかし、その強制力と引き換えに、通信の遅延、部分障害、監視、データ整合性、契約の互換性といった費用が生じる（Newman, 2021）。強い境界は無料の品質保証ではない。
したがって、「まずモノリスで始める」ことも「早期にサービスへ分ける」ことも、それだけでは原則にならない。必要なのは、何が一緒に変わり、何を独立して変えたいかを見定め、必要な強さの境界を選ぶことである。よいモノリスとよいマイクロサービスに共通するのは、設計判断と変更影響を境界の内側へ隠蔽できることだ。配置形態は、その境界を守るための選択肢の一つにすぎない。
マイクロサービスとモノリスを比較する前に、何を複雑性と呼んでいるのかを分けて考えたい。コード行数やサービス数は数えやすいが、それだけでは変更の難しさを説明できない。小規模なコードベースでも、厳しい契約条件、並行する状態変更、多数の関係者を扱えば難しい。反対に、大きなコードベースでも、境界が明確で変更が局所化されていれば、日常の判断範囲は小さくできる。
第一の発生源は、ドメイン、すなわちソフトウェアが対象とする現実の問題領域である。料金計算の例外、契約、権限、法規制、状態遷移などは、事業が必要とする限りなくならない。Brooksは、ソフトウェア固有の難しさと、道具や表現方法に由来する付随的な難しさを区別した（Brooks, 1987）。この区別を借りれば、事業上必要な複雑性を、技術だけですべて消せると考えるべきではない。Evansが論じたドメイン設計も、重要な業務知識をモデルと言葉によって明示し、扱える形にすることを重視している（Evans, 2003）。
第二は、構造と変更の複雑性である。現在のコードを読むだけなら分かりやすくても、一つの要求を実現するために多くのモジュールやサービスを同時に直す必要があれば、変更は難しい。一緒に変わるものが離れ、独立して変わるものが密結合していると、開発者は広い範囲を理解し、多数の関係者と調整しなければならない。重要なのは静止した構造の美しさだけでなく、変更理由と境界が一致しているかである。
第三は、状態と時間の複雑性である。注文が「処理中」であるという現在値だけでなく、いつ、誰が、どの順序で更新したかが結果を左右する。並行処理では、再試行、重複、遅延、順序の入れ替わりも起こる。Lamportは、分散システムにおける事象の因果的な順序と、時計が与える時刻の順序を区別して扱う基礎を示した（Lamport, 1978）。複数の実行主体にまたがる出来事を、単一プロセス内と同じ一つの時間軸で考えることはできない。
第四は、境界をまたぐデータ整合性である。一つのデータベース内であれば、複数の更新をトランザクションとしてまとめ、すべて成功するか、すべて取り消すかを扱いやすい（Gray, 1981）。更新が複数プロセス、データ所有者、組織、外部サービスへ分かれると、通信が途切れ、一部だけが成功する事態を前提にしなければならない。GilbertとLynchが形式化した結果は、ネットワーク分断が起きる状況で、強い一貫性と、すべての要求へ応答する可用性を同時には保証できないことを示す（Gilbert & Lynch, 2002）。これは分散すべきでないという結論ではなく、境界を越える保証には選択が伴うということである。
第五は、人間の調整と認知の複雑性である。技術的な依存関係は、承認、優先順位、スケジュール、障害対応、リリース調整という組織上の依存関係へ変わる。一つの変更に必要な知識が個人やチームの理解範囲を超えれば、文書や会議を増やしても判断は遅くなりやすい。コンピューターが処理できる構造であることと、人間が安全に変更できる構造であることは同じではない。
最後に、複雑性には時間とともに増える側面がある。Lehmanは、現実世界で利用されるプログラムは継続的な変更を要し、複雑性を抑えるための作業をしなければ構造が劣化すると論じた（Lehman, 1980）。境界もモデルも、一度決めれば終わるものではない。事業、利用者、組織、技術が変われば、以前は自然だったまとまりが不自然になる。
本稿では以後、これらを、ドメイン、コード構造、分散実行、データ、運用、組織、認知という「複雑性の台帳」として扱う。この台帳は既存の標準ではなく、複数の研究と実務上の問題を一つの意思決定へつなぐための分析モデルである。ある設計によって何が減り、何が増え、誰が負担するのかを、種類ごとに記録する。複雑性は静的な欠陥ではなく、変化し続ける対象だからである。
複雑性については、ときに「保存される」と表現される。しかし、複雑性は長さや質量のように測定できる物理量ではない。優れたモデルや道具によって、理解や作業に必要な負担を実際に減らせる場合もある。本稿では保存則を主張するのではなく、一つの問題を解いた結果として別種の難しさが導入される交換関係を、「複雑性の移送」と呼ぶ。この比喩の目的は、消えたように見える費用を台帳から落とさないことにある。
モノリスからサービスを切り出す場合を考える。変更理由が異なる機能を分け、担当チームとデータ所有を揃えられれば、コード上の依存とリリース調整を減らせる。変更影響がサービス内へ収まり、チームは自分の予定で改善を届けやすくなる。ここでは、構造、認知、組織の複雑性が局所化される。
一方で、プロセス内の関数呼び出しはネットワーク通信へ変わる。通信には遅延と失敗があり、相手が処理を終えたのに応答だけが失われることもある。そのため、タイムアウト、再試行、重複排除、呼び出し順序、障害時の代替動作を設計しなければならない。アプリケーション・プログラミング・インターフェース（Application Programming Interface、以下API）の変更には互換性が必要となり、一つの処理を追跡するためのログ、測定指標、処理経路の記録もサービスを横断する。分離によって消えた内部結合の一部は、通信、契約、運用の複雑性へ姿を変えたのである（Newman, 2021）。
データについても同じことが起きる。一つのデータベースでは、関連する更新を一つのトランザクションにまとめやすい（Gray, 1981）。サービスごとにデータを所有すると、局所的な変更の自由は高まるが、複数サービスにまたがる一連のデータ更新は、途中状態や部分障害を含めて扱う必要がある。すべてを即時に一致させる代わりに、後から整合させるのか、補償処理で取り消すのか、利用者へ途中状態を見せるのか。技術的な分割は、業務上どの不整合を許容できるかという判断を表面化させる。
反対に、複数のサービスを一つのプロセスへ戻せば、通信障害と分散データの問題は減らせる。ローカルな呼び出しとトランザクションを利用でき、開発・試験環境も単純になるかもしれない。ただし、内部のモジュール境界や責任が曖昧なら、変更調整、一括リリース、広い理解範囲という負担が戻る。集約は複雑性の解消になることもあれば、分散実行の複雑性を組織と認知の複雑性へ戻すだけのこともある。
購入や委譲にも同じ台帳が必要である。認証や決済を外部サービスへ任せれば、暗号技術、法令対応、可用性確保などを自社で実装・運用する負担は小さくなる。しかし、提供者との契約、APIの変更、障害の切り分け、料金体系、データ移行、特定事業者への依存が生じる。パッケージを導入する場合も、内部実装を持たない代わりに、更新、脆弱性対応、設定、拡張点との整合を管理する。外部化は、所有する複雑性の種類と責任分担を変える意思決定である。
AIによる実装支援も例外ではない。コード生成や調査が速くなれば、実装待ちの負担は減る。一方、生成された変更の意図を確認し、既存設計と整合させ、テストし、競合を解消する作業は増え得る。生成能力だけを高めると、レビュー、検証、意思決定が新しいボトルネックになる。ここでも問うべきなのは、作業が消えたかではなく、どの負担がどこへ移り、全体として価値提供が改善したかである。
この見方に立てば、アーキテクチャは方式を選ぶ作業ではなく、複雑性の配分を設計する作業になる。ある境界が、何を局所化するのか。越えるたびにどの費用が生まれるのか。その費用を扱う能力を誰が持つのか。複雑性を完全に消せるという期待を手放して初めて、減らせる負担と、価値のために引き受ける負担を冷静に選べる。
複雑性に抗う基本は、すべてを単純にすることではなく、ある判断に不要な詳細を見なくて済むようにすることである。関数を使う側は、その内部の一行一行を知らなくても結果を利用できる。モジュールを変更する側は、公開された約束を守る限り、内部表現を変えられる。このように、詳細を隠し、理解と変更の範囲を限定する仕切りを、本稿では境界と呼ぶ。
境界には異なる強さと費用がある。代表的なものを並べると、次のようになる。
| 境界 | 主に隠すもの | 強制力 | 主な越境コスト |
|---|---|---|---|
| 関数・クラス | 処理手順、内部状態 | 低〜中 | 呼び出し規約、間接性 |
| モジュール・パッケージ | 設計判断、依存関係 | 中 | 公開インターフェース、ビルド規則 |
| プロセス・ネットワーク | 実装、実行、障害 | 高 | 通信、遅延、部分障害、互換性 |
| データ所有 | 表現、更新規則、整合性 | 高 | 問い合わせ、複製、同期、移行 |
| チーム責任 | 知識、意思決定、優先順位 | 組織次第 | 調整、依頼、承認、引き継ぎ |
強い境界ほどよいわけではない。ネットワーク境界は、相手の内部メモリーやデータへ直接触れられないため、情報隠蔽を機械的に強制しやすい。その代わり、呼び出しは失敗し、契約変更には互換性管理が要る。モジュール境界は安価で高速だが、規約や依存関係の検査が弱ければ、便利さを理由に内部へ侵入されやすい。必要な独立性を満たす範囲で、最も安価な境界を選ぶことが重要である。
Parnasの情報隠蔽は、その判断基準を与える。モジュールは単なる処理のまとまりではなく、変更され得る設計判断を外部から隠す単位である（Parnas, 1972）。たとえば、料金計算の規則を一つの境界内へ置き、外部には「料金を計算する」という約束だけを見せれば、規則の変更を利用側へ波及させにくい。反対に、内部のデータ形式や計算手順が多くの利用者に知られていれば、ファイルやサービスを分けても変更は局所化されない。
境界は階層として組み合わせられる。Simonは、複雑なシステムが、内部では密接に関係しながら、部分同士は比較的弱く結びつく準分解可能な階層として理解できることを論じた（Simon, 1962）。関数をモジュールへ、モジュールをアプリケーションへ、アプリケーションを事業能力へまとめれば、上位では下位の詳細ではなく、より少数の概念を扱える。本稿では、この働きを人間のための「認知的な圧縮」と解釈する。これはSimon自身の用語ではなく、局所的な推論が可能になる効果を表す比喩である。
ただし、階層を増やすだけでは圧縮にならない。上位の抽象が下位の都合を隠せず、変更のたびにすべての層を修正するなら、階層は間接性を増やしただけである。責任を画面層、業務層、データ層のチームへ分散すると、一つの価値変更が全層を横断し、調整も増える。抽象の名前が整っていても、利用者が内部実装を知って回避策を取らなければならないなら、境界は機能していない。
よい境界は、内側に高い凝集を、外側との間に低い結合をつくる。言い換えれば、一緒に変わるものを近くへ置き、異なる理由で変わるものを離す。そして、外部へ約束する面を小さく保つ。境界を評価するときは、図の美しさではなく、実際の変更を追うべきである。ある要求を実現するために何を理解し、誰と調整し、どの単位をテストし、どこまで一緒にリリースしたかを見れば、境界が複雑性を局所化できているかが分かる。
問うべきは階層数やサービス数ではない。変更を局所的に理解し、その範囲で完結できるかである。規律で守れるならモジュールを使い、独立した障害、データ、リリース、組織責任まで必要なら、より強い境界を検討する。境界の強度は思想ではなく、必要な独立性と越境コストの釣り合いから決める。
複雑性は少ないほどよい、と一律に考えると、事業の価値を生む難しさまで削りかねない。独自の価格決定、需要予測、審査、配送計画など、その企業らしさを支える業務は、現実に複雑である場合が多い。ここで必要なのは、複雑性を避けることではなく、どの複雑性を自ら理解し、設計し、育てる価値があるかを選ぶことである。
ドメイン駆動設計（Domain-Driven Design、以下DDD）は、ソフトウェアが対象とする業務領域を深く理解し、その知識をモデルへ反映する設計アプローチである。Evansは、競争優位や事業の成功にとって特に重要な領域をコア・ドメインと呼び、そこへ優れた人材と設計努力を集中させることを提唱した（Evans, 2003）。複雑な業務規則を条件分岐の寄せ集めとして隠すのではなく、業務の言葉と概念を使って明示的に表現し、事業の学習に合わせてモデルを更新する。
DDDでは、同じ言葉とモデルが一貫して通用する範囲を、境界づけられたコンテキスト（bounded context）として明示する（Evans, 2003）。たとえば「顧客」という言葉でも、販売では購買主体、配送では届け先、会計では請求先を意味し得る。全社で一つの巨大な顧客モデルへ統合すると、異なる目的の規則が絡み合う。文脈ごとにモデルを分け、その間の対応関係を明らかにすれば、それぞれの変更を局所化しやすい。境界は、現実を単純化して捨てるのではなく、扱う観点を限定する。
一方、すべての領域に独自の仕組みを作る必要はない。認証、メール配信、ログ収集、給与計算のように、多くの組織で共通し、自社の競争力になりにくい能力には、標準、既製品、外部サービス、共通プラットフォームを利用できる。実装を減らすだけでなく、必要な専門知識、法令対応、運用体制を外部や専門チームへ集約できるからである。その結果、自社の限られた設計能力をコア・ドメインへ振り向けられる。
本稿では、この設計能力の配分を「複雑性予算」と呼ぶ。これはDDDの正式な用語でも、複雑性を単一の数値で測れるという主張でもない。時間、専門知識、レビュー能力、運用能力といった限られた資源を、どこへ投じるか考えるための比喩である。すべてを独自開発する組織は予算を分散させる。反対に、コアまで外部製品の都合へ合わせれば、事業上の学習と差別化を制約する可能性がある。
外部化した領域を台帳から消してもいけない。外部サービスには、ベンダー固有の仕様、API変更、料金改定、可用性、障害時の切り分け、データ移行、特定事業者への依存がある。既製品に業務を合わせることで、現場へ回避手順が生まれることもある。内部プラットフォームも、利用チームにとって簡単でなければ、別チームへの依頼と待ち時間を増やすだけである。実装の複雑性を、契約、統合、運用、組織の複雑性へ移していないかを確認する必要がある。
意思決定では、「作るか買うか」という初期費用の比較だけでは足りない。まず、その能力が自社の価値と学習にどれほど直結するかを問う。次に、自社で所有する場合に必要な知識と長期運用、外部化する場合に生じる統合と退出の費用を比べる。そして、どちらを選んでも、品質、互換性、移行に誰が責任を持つかを明らかにする。
複雑性に抗うとは、難しいものをすべて外へ追い出すことではない。価値ある難しさをコア・ドメインで意図的に引き受け、丁寧なモデルへ変えることである。同時に、独自性の低い難しさは標準化、購入、委譲、プラットフォーム化し、移送先で生じる負担も管理する。何を所有するかという選択が、組織の設計能力をどこへ集中できるかを決める。
システムの境界を設計しても、日々の変更を担う人々の責任と権限がそこに揃っていなければ、複雑性は局所化されない。受注サービスを一チームが所有していても、データ変更は別のデータベースチーム、デプロイは運用チーム、優先順位は別部門の承認を必要とするなら、価値提供は組織を横断する。チーム構造は担当者一覧ではなく、人間の認知負荷と調整コストを配分するアーキテクチャである。
Conwayは、システムを設計する組織のコミュニケーション構造と、出来上がるシステムの構造との対応を指摘した（Conway, 1968）。これは、組織図を変更すれば望むアーキテクチャが自動的に得られるという法則ではない。しかし、頻繁に相談できる人々の間には密な接続が作られ、組織境界を越える箇所には形式的な接続が作られやすい。技術構造と組織構造を別々に設計できると考えることへの警告になる。
ソフトウェア上の依存関係は、必要な調整関係を生む。Cataldoらは、技術的な作業依存から求められる調整と、実際の組織的な調整がどれほど一致しているかを、社会技術的整合性として分析した（Cataldo et al., 2008）。同時に変更する必要がある部品を別チームが担当していれば、情報交換と予定調整が必要になる。その経路が組織に用意されていなければ手戻りが起き、用意されていても越境の回数が多ければ調整費用は積み上がる。
Team Topologiesは、こうした問題を扱う実務モデルである。事業上の価値の流れに沿って成果を届ける「ストリームアラインドチーム」、共通能力をセルフサービスで提供するプラットフォームチームなどの類型と、チームが理解・運用できる範囲を表す認知負荷を用いて、技術と組織の境界を継続的に整合させる（Skelton & Pais, 2019）。これは学術的な自然法則ではなく、組織設計を会話し、見直すための実務上の枠組みである。
局所的な価値提供を実現するには、少なくとも四つの単位を揃えたい。第一はコードを変更する単位、第二はテストしてデプロイする単位、第三はデータを所有する単位、第四は意思決定と結果責任の単位である。サービスだけを細かく分けても、共通データベースの変更を中央チームへ依頼し、全サービスを一括試験し、複数の責任者から承認を得るなら、変更単位は分かれていない。この四単位のずれが大きいほど、変更のたびに組織境界を越えることになる。
ただし、チームへ排他的な所有権を与えるだけでも不十分である。境界が強すぎれば、「それは別チームの仕事だ」という縄張り意識が生まれ、全体の利用者体験や障害が置き去りになる。境界が弱すぎれば、誰でも変更できる一方、品質や将来の更新に誰も責任を持たない。そこで、変更権限に加えて、長期にわたり品質、互換性、更新、廃止を世話するスチュワードシップ1を設計する必要がある。所有者は外部からの貢献を拒む門番ではなく、境界を健全に保つ責任者である。
自律した小チームを増やすには、すべてを各チームへ複製するのでも、すべてを中央組織へ申請するのでもない構造が要る。変更を頻繁に統合して自動検証する継続的インテグレーション（Continuous Integration、以下CI）、本番投入可能な状態を保つ継続的デリバリー（Continuous Delivery、以下CD）、実行基盤、監視、認証、セキュリティの基本機能を、セルフサービス型のプラットフォームとして提供すれば、各チームは共通の難しさを理解せずに安全な標準経路を利用できる。プラットフォームは内部製品であり、利用チームの待ち時間と認知負荷を減らせているかで評価する。新たな承認窓口になれば、複雑性を中央へ移しただけである。
価値判断は、顧客と問題に近いチームへ分散する。一方、各所で重複させる価値の低い技術能力は、使いやすい共通基盤へ集約する。この組み合わせによって初めて、チームは狭い技術部品ではなく、一つの価値を本番へ届け、その結果から学ぶ範囲を担える。サービスを分けることは出発点にすぎない。責任範囲と、それを完結するための権限、データ、基盤を一致させることが、組織上の境界を機能させる。
AIによるソフトウェア開発支援をめぐっては、「少ない人数で同じ量を作れる」という期待が先行しやすい。しかし、コードを書く速さだけから、必要なエンジニア総数や最適な組織形態を導くことはできない。要件の発見、設計、レビュー、検証、運用、顧客からの学習は残り、作れる量が増えれば統合と意思決定の負担が増えることもある。より慎重に言えば、AIが変える可能性があるのは、一つの価値提供単位を成立させるために必要な最小チーム規模である。
実証研究の結果も一様ではない。GitHub Copilotを用いた実験では、参加者が小規模な実装課題を完了する時間が55.8％短縮された（Peng et al., 2023）。Googleで行われた企業内の無作為化比較試験では、複雑な業務上の開発課題について約21％の時間短縮が推定された（Paradis et al., 2024）。一方、成熟したオープンソースのリポジトリで経験豊富な開発者を対象とした実験では、AIツールを使った場合に完了時間が19％長くなった（Becker et al., 2025）。
これらは対象課題、参加者、利用ツール、測定方法、品質条件が異なるため、数字を単純に比較して一般的な効果を決めることはできない。小さく独立した実装、広い文脈を要する既存システムの変更、正しさの確認が難しい業務では、AIが支援できる範囲も検証費用も違う。「AIは必ず実装コストを下げる」「チームは必ず少人数化する」という断定ではなく、どの条件で、どの工程の往復時間が変わるかを観測すべきである。
それでも、隣接する職能の作業を始めるための習得コストがAIによって下がる可能性は重要である。プロダクトマネージャーが動く試作品を作り、エンジニアが顧客調査の整理やデータ分析を行うなど、一人が隣接領域へ踏み込みやすくなる。専門性が不要になるのではない。最初の試行や共通言語の獲得が速くなり、専門家へ相談する前に仮説を具体化できるのである。その結果、少人数でも、問題の発見、実装、本番投入、観測、次の判断までを一つのチーム内で回せる場面は増え得る。
技術プログラムマネージャーやプロダクトマネージャーの機能が消えるわけでもない。チーム内で仕様を文書からコードへ中継するだけの作業は減るかもしれないが、顧客価値の選択、チーム間依存、投資配分、共通基盤、全社的なセキュリティや法的リスクの管理は残る。むしろ自律的なチームが増えれば、局所判断を妨げずに全体の方向を揃える仕事の重要性は高まる。
ここで最適化すべき対象は、生成したコード量ではない。「仮説を立ててから、本番で観測可能な結果を得て、次の意思決定をするまでの往復時間」である。コード生成が速くても、レビュー待ち、共通試験環境、承認会議、一括リリースで止まれば、学習は速くならない。個人の実行能力だけを高め、意思決定権を分けなければ、着手済みで未完了の仕掛かり作業（Work in Progress、以下WIP）が増え、変更同士が競合する。
したがって、AI時代の分割単位は、フロントエンド、データベース、テストといった技術部品ではなく、一つの仮説を端から端まで検証できる責任範囲であるべきだ。小さなチームが変更、テスト、デプロイ、データ、観測、次の判断を完結できれば、AIによる実行能力の増加を短い学習周期へ変えられる。そのためには、小さな変更単位、自動テスト、CIとCD、システムの状態を外部出力から把握できる可観測性、WIPの制限が欠かせない。速度を上げるほど、誤りを早く検出し、影響を限定して戻せる仕組みが必要になる。
組織全体では、顧客価値の判断と提供を担う組織単位が小さなプロダクトチームへ分化する一方、実行基盤、可観測性、セキュリティ、AIの実行環境などは、セルフサービス型の共通プラットフォームへ集約される形が考えられる。これは各チームがあらゆる専門家を抱えるという意味ではない。価値判断と学習は現場へ分散し、重複させる価値の低い技術能力は内部製品として共有する構造である。
Gartnerの2026年予測は、2029年までに小規模なソフトウェアエンジニアリングチームを採用する組織が増えるとの見通しを示した（Gartner, 2026）。ただし、これは将来予測であり、実証済みの事実ではない。総雇用人数は、AIだけでなく、景気、ソフトウェア需要、新たに作る価値の量にも左右される。観測すべきなのは人員削減の有無だけでなく、チーム当たり人数、チーム数、職能境界、意思決定単位がどう変わるかである。
AIが変えるのは、同じ組織で何人を不要にできるかではない。何人いれば一つの問題について自律的に考え、作り、試し、学べるかである。その可能性を成果へ変えるには、実装能力とともに意思決定権を局所化しなければならない。変更速度が上がるほど、明確な境界、自動検証、可観測性、そして長期的に結果へ責任を持つ仕組みが重要になる。
本稿の出発点は、「マイクロサービスとモノリスのどちらが優れているか」という問いへの違和感だった。ここまで見てきたように、両者は単純な対義語ではなく、サービス数や配置形態だけで設計の良しあしは決まらない。モジュール境界が機能するモノリスは変更を局所化できる一方、相互依存した多数のサービスは分散モノリスになり得る。重要なのは外形ではなく、価値を届けるための変更を、人とチームがどの範囲で理解し、完結できるかである。
この観点に立つと、アーキテクチャの役割も明確になる。アーキテクチャは複雑性を消すのではない。ドメイン、コード構造、分散実行、データ、運用、組織、認知という異なる種類の複雑性を分け、局所化し、ときに別の場所へ移す。プロセスを分ければ内部の結合を断ちやすくなるが、通信、障害、データ整合性の難しさが増える。外部サービスへ委ねれば実装と運用の負担は減るが、契約、統合、移行、ロックインを引き受けることになる。どの選択にも代価があるからこそ、「複雑性の台帳」を持ち、何を減らし、何を増やし、誰が負担するのかを見失わないことが大切である。
本稿の議論は、次の十原則にまとめられる。
これらの原則が示すのは、強い境界ほどよい、あるいは細かく分割するほどよいということではない。境界には、詳細を隠し、独立性を守る利益がある一方、越えるたびに費用が生じる。必要な独立性を満たす範囲で、最も安価な境界を選ぶべきである。小さな組織や変化の方向がまだ見えない事業では、明確にモジュール化された単一のデプロイ単位が合理的かもしれない。複数のチームが異なる速度で変更し、独立した運用責任を負う段階では、プロセスやデータ所有の分離がその代価に見合うかもしれない。方式は出発点ではなく、必要な独立性から導かれる結果である。
AIも、この原則を無効にはしない。実装や調査の一部が速くなり、一人が担える範囲が広がれば、少人数のチームが仮説形成から本番での観測までを完結できる可能性は高まる。しかし、生成された変更を検証し、既存の意図と統合し、結果に責任を持つ仕事は残る。むしろ変更量が増えるほど、曖昧な境界、遅い意思決定、手作業の検証は早く限界へ達する。AI時代に必要なのは、単に多くのコードを生み出す組織ではなく、小さな単位で判断し、試し、観測し、学べる組織である。
複雑性に抗うとは、システムを一度きれいに整理して終えることではない。現実の業務とソフトウェアが変わり続けるなかで、複雑性が人間の理解と責任の範囲からあふれないよう、閉じ込める場所を更新し続けることである。マイクロサービスもモノリスも、そのために使える手段の一つにすぎない。
最後に残る問いは、どちらを選ぶかではない。何を誰が理解し、どこまでを自ら変更し、その結果に責任を持つのか。その範囲を明確にし、守り、必要に応じて組み替え続けられるかである。複雑性に抗う力は、技術の名前ではなく、この地道な設計と運営の継続に宿る。
アクセス日は、特に断りのない限り2026年7月16日である。ウェブ記事の公開日・更新日は、公開ページで確認できる範囲を記す。