時計の振子がゆらゆらと動くのが飽きた

二つの集団、一つのWhatsApp、明確な勝者なし

架空の話を創作する必要はありません。2026年にエンジニアリングチームを指揮する誰でもこのシーンを経験しています。一つのグループはモノリシックアーキテクチャを分割するのが彼らのキャリアで最高の決定であったと主張しています。もう一つのグループは同じチャットで、月額5桁のKubernetes請求書のスクリーンショットを送信しています。誰もが嘘をついています。実際に問題はそこにあります。ソフトウェアアーキテクチャは技術的な議論から部族的アイデンティティの議論に変わり、両側に実在するデータが反対の立場を支持しています。

どちらかの集団に加わる前に、Slackでの議論に参加してから1年半で初めて、数字をその起源まで追跡することにしました。見つけたものは勝者ではありません。それは誰が何をしているのか、理由は何なのか — そしてこれが興味深いことですが — 公的な議論と実際の行動の違いを示す地図です。

誰もが引用するデータだが、誰も指をさして示せない

この調査で最も不快な発見から始めます。それはソフトウェア産業でコンセンサスがどのように作られるかを最もよく説明しているからです。

2025年と2026年の数十の記事で、「42%の組織がマイクロサービスを採用してサービスをより大きな単位に統合している」という数字を検索しました。すべての記事は「CNCFの2025年の調査」に帰属しています。そのうちの1つの記事 — そのデータを引用しています — は、IAによって自動化されたパイプラインによって作成されたことを生産ノートで認めています。「CNCF x SlashData 2026のレポートに対して検証された」 (ManoIT / DEV Community, 2026) と書かれています。cncf.ioに直接アクセスし、2024年の年次調査レポート (CNCF, 2025) 、2025年11月のSlashDataとの研究発表 (CNCF, 2025) 、および基金によって公開された最新の調査レポートを確認しましたが、どのドキュメントでもその数字がそのまま出現しませんでした。ただし、一貫して出現するのは、46%のバックエンド開発者がマイクロサービスで作業し、コンテナとKubernetesの使用が続いて増加している (CNCF/SlashData, 2025) という事実です — この特定のデータは基金のオリジナルな発表文書に対して直接確認しました。

42%という数字が誤りであることを意味するのか？必ずしもそうではない。ウェビナーまたはサイドパネルで報告されるタイプの数字は、常に主なPDFと同じようにインデックスされないことがあり、少なくとも8つの独立した情報源で一貫した詳細レベルでほぼ同一の形で引用される（サービスメッシュの採用率の低下から18％から8％まで）（SoftwareSeni, 2026；ThirdEyeData, 2026；ByteIota, 2026）。しかし、すべてのデータを検証することを誇る記事の場合、正直に言う必要がある。42%は、2026年のアーキテクチャデバットで最も引用された数字であり、読みやすい一次情報に対して確認することができなかった。独立して検証されていない「広く繰り返されている」という扱いをしてください。技術における「コンセンサス」は、時々、AIによって生成されたコンテンツが自己参照で循環するだけであることを示す完璧な例です。

しかし、一次情報源が確認されているものがあります - これは、この記事の元の草稿の参考文献に欠けていたため、実際の投稿を探しに行きました：Amazon Prime Videoの移行。エンジニアリングチームは、自身のブログで、ビデオ品質モニタリングサービスを分散アーキテクチャからモノリシックアーキテクチャに統合し、インフラストラクチャのコストを90％削減した方法を文書化しました（Amazon Prime Video Engineering, 2023）。

マイクロサービスに対する最も引用されたケース

Amazon Prime Videoがビデオ監視サービスをモノリシックアーキテクチャに統合した後のインフラストラクチャコスト削減

90%

インフラストラクチャコスト削減（2023）

Ver los datos

マイクロサービスに対する最も引用されたケース

Indicador	Valor
インフラストラクチャコスト削減（2023）	90%

このケース - すでに3年前からのもの - は、ミクロサービスに反対するすべての人の必須の引用であり、それは理由がある：世界にミクロサービスを教えたのと同じ会社からのものだからです。

Shopify：「モノリシック」とは「小さい」とは同義ではないことを証明する

もしミクロサービスのための議論が「それらなしではスケールできない」というものだったとしたら、Shopifyは自身のエンジニアリングブログで具体的で検証可能な数字でそれを否定しています。プラットフォームは、自分たちで「壮麗なモノリシック」と呼んでいるものを操作している：単一のRuby on Railsアプリケーションで、内部的に厳格な境界を持つコンポーネントに組織化されており、Packwerkというツールによって開発されたものです（Shopify Engineering, s.f.）。ブラックフライデーのピーク時のトラフィック中、インフラストラクチャは1分間に数十テラバイトのデータを保持し、コードを独立したサービスに分割するのではなく、ショップID（shop_id）によってデータベースレイヤーをパーティション化しています（Kovyrin, en TechWorld with Milan, 2025）。

区別は重要です：Shopifyはモジュラー性を避けたのではなく、分散を避けたのです。コンポーネントはコードの境界（Domain-Driven Designの用語では、境界付きコンテキスト）によって分離されていますが、ネットワーク呼び出しがない同じプロセスで実行されます。これは、2025年から2026年までのほとんどの文献が、モノリシックアーキテクチャとミクロサービスの中間に位置する第三の道として識別する「モジュラーなモノリシックアーキテクチャ」の定義とまったく同じです（Al-Qora'n & Al-Said Ahmad, 2025）- このテーマに関する最初の体系的な文献レビューは、Future Internet誌に掲載され、2020年から2025年5月までに、わずか15のピアレビューされた一次研究しか見つからなかったことを発見しました。これは、業界の実践が正式な研究より数年先を行っていることを示唆しています。

レーダー1 - ソフトウェアの大手企業が実際に行っていること

レーダー1 — 大手ソフトウェア会社が実際に何をしているか

各企業について、本文で引用された発言に基づいて0-10の編集評価を割り当てる。正式なアンケートではない。各軸は、高い値が「より良い」となるように向けられている。

レガシーの独立性デプロイの迅速性運用のシンプルさネイティブAI/エージェント統合機能ごとのコスト効率ガバナンス境界の成熟度

• SAP（移行中のレガシーERP）
• Shopify（モジュラーなネイティブモノリシック）
• Oracle（ハイブリッドSOA）
• Anthropic / OpenAI（ネイティブAI）

Ver los datos

レーダー1 — 大手ソフトウェア会社が実際に何をしているか

Eje	SAP（移行中のレガシーERP）	Shopify（モジュラーなネイティブモノリシック）	Oracle（ハイブリッドSOA）	Anthropic / OpenAI（ネイティブAI）
レガシーの独立性	2	8	4	9
デプロイの迅速性	3	7	4	9
運用のシンプルさ	4	7	3	8
ネイティブAI/エージェント統合	3	5	3	10
機能ごとのコスト効率	3	8	4	7
ガバナンス境界の成熟度	6	9	5	8

これを踏まえて、質問の起源となった6社 - SAP、Oracle、Microsoft、Apple、Anthropic、OpenAI - と、2025年から2026年までの技術文献で繰り返し引用されている10社以上を調べてみましょう。

<strong>SAP</strong>は、たぶん最も誠実なケースです：自身の技術コミュニティは、S/4HANAのコアを「巨大なモジュラーなモノリシックアーキテクチャ」と説明し、クラウドネイティブアーキテクチャへの段階的な分解を経ており、完了予定日は約束されていません（SAP Community, 2025）。これはデジタル変革のマーケティングではありません：50年の歴史を持つ企業が、ERPのモノリシックアーキテクチャを分割するには10年以上かかると認めています。

<strong>Oracle</strong>は、2つの議論を平行して進行させています。Fusion Applicationsは2011年にクラシックなサービス指向アーキテクチャ（SOA）上に生まれました（Oracle, Wikipedia, s.f.）、そしてそれ以来、「プロジェクト・スペクトラ」はKubernetesを使用したコンテナ上のマイクロサービスへの機能を移動させてきました（OKEを使用）（Oracle Cloud Blog, 2023）- しかし、Oracle自身のブログは、このプロセスを「舞台裏で」発生するものとして説明しており、クライアントには認識されず、正確に、総賃金や数千の企業の財務諸表を処理するソフトウェアの完全な書き直しは実行可能ではないからです。

<strong>Microsoft</strong>には、このテーマについての統一された声明はないですが、その行動は第三者の技術文書から読み取ることができます。2025-2026年の企業向けの.NETにおける主なパターンは、業界のその他の部分と同じです。モノリシックなモジュラーから始めて、実際の必要性の証拠がある場合にのみマイクロサービスを抽出します (Murmu Software, 2026)。また、彼らの内部でのAIの実践（以下で説明する「分離されたサブエージェントを持つオーケストレーター」）も同様の哲学を確認しています。

<strong>Apple</strong>はバックエンドのアーキテクチャを公開していませんが、自社の開発者エコシステム内では、大規模なiOSアプリの主なパターンは、マイクロサービスではなく、「モノリシックモジュラー」です。Swift Package Managerを使用して、コンパイルとデプロイのプロセスを断片化せずに内部フレームワークに分割します (Tariq, 2025)。これは、Shopifyがバックエンドで使用しているのと同じパターンであり、クライアントに適用されています。

<strong>AnthropicとOpenAI</strong>は、このレーダーの最も興味深いケースです。彼らはERPまたは電子商取引で競合しているのではなく、AIエージェントのオーケストレーション方法で競合しています。そこでは、彼らのアーキテクチャが実際の製品です。Anthropicは、自社のエンジニアリングブログで、エージェントが単一のループとして実行され、ツールとサブエージェントが中央のオーケストレーターによって制限されていることを文書化しています。ピアツーピアのマイクロサービスの網ではなく (Anthropic Engineering)。OpenAIは、2024年の実験的なSwarmフレームワークを2025年のエージェントSDKに置き換えましたが、ミニマリストの設計原則を維持しました。複雑な中央コーディネーターも網状の通信もなく、エージェントが他のエージェントに制御を移譲するタイミングを決定する (OpenAI Swarm repo; Tao An, 2026)。私は、AIのセクションでこれに戻ります。なぜなら、これは私の全調査で最も洞察力のある発見だからです。

このレーダーに使用するために、私は調査によって最も洞察力のあるものとして特定された6つの軸を選択しました。つまり、<strong>レガシーのアーキテクチャ的独立性</strong>、<strong>デプロイの速度</strong>、<strong>操作の複雑さ</strong>、<strong>AI/エージェントのネイティブ統合</strong>、<strong>機能ごとのメンテナンスコスト</strong>、および<strong>境界のガバナンスの成熟度</strong>（Conway's Lawをどれだけ真剣に受け止めるか）です。私は、SAP（移行中のレガシーERP）、Shopify（ネイティブモノリシックモジュラー）、Oracle（ハイブリッドSOA）、およびAnthropic/OpenAI（ネイティブAI、オーケストレーター+サブエージェント）を含む4つの代表的なプロファイルを比較しました。24の企業を1つのレーダーにグラフィカル化しようとすると、読みにくくなります。残りの企業群（Microsoft、Apple、Amazon、Google、Meta、Netflix、IBM、Salesforce、Stripeなど）は、テキスト本体と方法論で議論されていますが、グラフィックの軸ではありません。

レーダー2 — 他のグループ: オープンソースを維持する人

レーダー2 — 反対側：オープンソースを維持するのは誰か

各プロジェクトについて、本文で引用された発言に基づいて0-10の編集評価を割り当てる。正式なアンケートではない。

モノリシックな哲学の宣言メンテナンスチームの削減ネットワークを伴わない内部モジュール性導入スケール財団からの独立性

• Linux（カーネル）
• PostgreSQL
• Kubernetes
• Proxmox

Ver los datos

レーダー2 — 反対側：オープンソースを維持するのは誰か

Eje	Linux（カーネル）	PostgreSQL	Kubernetes	Proxmox
モノリシックな哲学の宣言	10	8	1	9
メンテナンスチームの削減	3	5	1	9
ネットワークを伴わない内部モジュール性	8	7	2	7
導入スケール	10	8	9	5
財団からの独立性	6	7	2	9

ここで、この記事の起源となったユーザーの質問は正確でした。Linux Foundation、MySQL、MariaDB、PostgreSQL、Proxmox、その他の30の高影響プロジェクトを維持する人々は何をしていますか？簡単に言うと、オープンソースの世界は、「マイクロサービス」が企業の流行語になる前に、数十年前からこの議論を続けてきました。

基本的なケースは、<strong>Linuxカーネル</strong>です。1992年、Andrew TanenbaumはLinus Torvaldsに公開して手紙を書き、当時の時点でモノリシックカーネルを書くことは「70年代への大きな後退」であり、マイクロカーネルはすでに学術的な議論で勝利していたと述べました (Tanenbaum-Torvalds debate, Wikipedia, 1992)。Torvaldsは、特徴的な口調で応え、マイクロカーネルは「問題を通信の空間へ押し出し、それは解決しようとしている問題よりも大きな問題である」と述べました (Torvalds, sobre el debate micro vs. monolítico)。34年後、Linux — モノリシック — は地球上のほとんどのサーバーで実行されており、GNU Hurd — マイクロカーネル — はまだ学術的なプロジェクトのままです。アイロニーは明らかです。マイクロサービスを実行するためのインフラストラクチャ（コンテナ、Kubernetes、クラウド全体）は、モノリシックであることによって勝利したカーネル上に構築されています。

<strong>PostgreSQL、MySQL、MariaDB</strong>は、データ層で同じ論理を生きています。設計によってモノリシックなプロセス（またはほぼモノリシック）であり、コミュニティは、データベースをデータマイクロサービスに分解することは意味があるのか、それとも単にネットワークの複雑さを再導入するだけなのかについて、活発に議論しています (Reintech, 2026)。2025-2026年の支配的な回答は、データベースをモノリシックに維持し、内部ではなく周囲にアプリケーションのマイクロサービスを配置することです。

<strong>Proxmox</strong>は、オープンソースの「もう一つのスタイル」の最も典型的な例です。オーストリアの小さな企業で、CNCFのような財団や多ベンダーの政府からの支援がないにもかかわらず、Kubernetesのネイティブな代替であるKubeVirt (Kubermatic, 2026) に対して、故意にシンプルな全インワン（ハイパーバイザー + LXCコンテナ + ストレージ + ネットワーク）プラットフォームを維持しています。インフラストラクチャソフトウェアにおいて、これはAndré Staltzが何年も前に「モノリシックなオープンソースの学校」として説明した同じパターンです。WordPress、Django、Linux自身のような大きな問題を一つのまとまりのあるブロックとして解決するプロジェクトに対して、「モジュラーな学校」と呼ばれるものがあり、1パッケージにつき1つのユーティリティを公開します (Staltz, 2018)。11年後でも、これはオープンソースの動きの中でなぜGogs（1つのバイナリ、1人のメンテナー）とKubernetes（数百の調整されたピース）が反対の哲学を表すのかを説明するために、最も役立つフレームワークです (Laoutaris, 2025)。

このレーダーでは、5つの軸を使用しました：<strong>モノリシックな哲学の宣言</strong>、<strong>メンテナンスチームのサイズ</strong>、<strong>ネットワークなしの内部モジュラー性</strong>、<strong>採用のスケール</strong>、<strong>財団のガバナンスへの依存</strong>。Linux（カーネル）、PostgreSQL、Kubernetes、Proxmox — 提供した文献の中で最も頻繁に引用された4つの参照ポイントを比較しました。さらに20を超えるプロジェクト（MySQL、MariaDB、Caddy、SigNoz、Gogs、Nginx、Envoy、Terraform、Ansible、Jenkins、Prometheus、Grafana、Elasticsearch、Redis、Kafka、Django、WordPress、GitLab、Nextcloud、Home Assistantなど）を調査し、メソドロジーに記載しました。

レーダー3 — 政府：4つの哲学、1つのスケール問題

レーダー3 — 政府：4つの哲学、1つのスケール問題

各政府ブロックについて、本文で引用された発言に基づいて0-10の編集評価を割り当てる。正式なアンケートではない。

クラウドインフラストラクチャの成熟度モジュール性/相互運用性の宣言実証済みのトランザクションスケールプライベートプロバイダーへの主権内部システムの成熟度

• アメリカ合衆国
• 欧州連合
• 中国
• インド

Ver los datos

レーダー3 — 政府：4つの哲学、1つのスケール問題

Eje	アメリカ合衆国	欧州連合	中国	インド
クラウドインフラストラクチャの成熟度	5	7	8	7
モジュール性/相互運用性の宣言	3	10	4	8
実証済みのトランザクションスケール	6	5	7	10
プライベートプロバイダーへの主権	4	8	10	6
内部システムの成熟度	3	6	7	8

ここで、元の質問がより興味深いものになります。なぜなら、政府は市場の速度を争っておらず、主権、相互運用性、そして自分自身のスケールの下に崩壊しないことを争っているからです。

<strong>米国</strong>は、最悪の状況にあります。政府会計事務局（GAO）の数字によると、連邦政府は毎年1000億ドル以上を技術に費やしており、そのうち約80％が新しいものを構築するのではなく、レガシーシステムを動作させ続けるために使用されています (GAO, 2025)。これは、10年前のモノリットと同様の問題ですが、CTOが直面する問題です。技術的な負債は、建築上の優雅さではなく、予算で支払われます。

<strong>欧州連合</strong>は、明示的かつ文書化された形で反対の立場を取りました。ITU、エストニア、ドイツ、DIALによって設立されたGovStackイニシアチブは、EUのGlobal Gatewayの資金提供を受けています。公式のトレーニングセッションには、「モノリットを避ける：摩擦のないデジタル変革のためのマイクロサービスを統合する」というタイトルのセッションがあります (ITU Academy / GovStack, 2025)。技術仕様では、「ビルディングブロック」（デジタルID、データ交換、フローのオーケストレーション）をドメインのマイクロサービスで構成される相互運用可能なモジュールとして定義しています (GovStack Specification, s.f.)。これは、欧州のデジタル主権（EuroStack）の議論を推進する、モジュラーな側の議論に対する明示的な制度的賭けです (Bertelsmann Stiftung, 2026)。

<strong>インド</strong>は、公開の議論で「マイクロサービス」という言葉を使用することはありませんが、地球上で最大の層構造アーキテクチャの例を構築しました：インディアスタック。Aadhaar（バイオメトリックID、1.4億人登録）、UPI（インスタントペイメント、2026年4月に1ヶ月で223.5億の取引 — 地球規模でVisaが1日に処理するよりも多い）、DigiLockerは、単一のモノリティックな政府システムではなく、オープンAPIで接続された独立した層として動作します (Policy Circle, 2026；独立してcomunicado del gobierno de Indiaによって確認されています)。公的デジタルインフラストラクチャに関する学術研究は、これらのアーキテクチャが標準化されたAPIを使用したマイクロサービスを明示的に使用していることを確認しています (arXiv 2503.08725, 2025)。これは、デバットの「マイクロサービス」側の最大の実証ケースです — ただし、2018年にインドの最高裁判所は、プライバシーの理由でAadhaarの民間利用を制限しました。つまり、モジュラーなアーキテクチャは、技術的な問題に対するものだけでなく、法的な問題に対するものでもあったことを示しています。

<strong>中国</strong>は、県レベル以上の行政機関で100％のカバレージを持つ集中型の「政府クラウド（政務雲）」インフラストラクチャーに注力しており、これは「デジタル中国」戦略 (National Data Administration / Digital China Wins the Future, 2026) の一環である。欧州の相互運用可能なビルディングブロックのモデルとは異なり、ここでは集中化が明確な戦略目標となっている — 2026年までに政府デジタル市場は200億ユアンを超え、73％が政府クラウドインフラストラクチャー (IDC, vía Huawei Cloud, 2026) に割り当てられる予定である。これは、建築的に見ると、欧州のモデルとは正反対でありながら、内部の技術的実装パターンとしてマイクロサービスを共有している。

既存のものを維持するために技術予算の何パーセントが費やされるか

新しいものを構築するのではなく、既存のシステム/インフラストラクチャを維持するために費やされる技術支出の割合。

アメリカ合衆国 — 年間100億ドル以上のシステムヘリテージ維持に費やされる割合

80%

中国 — 国営クラウドインフラストラクチャに予算された約200億元の割合

73%

Ver los datos

既存のものを維持するために技術予算の何パーセントが費やされるか

Concepto	Valor (%)
アメリカ合衆国 — 年間100億ドル以上のシステムヘリテージ維持に費やされる割合	80%
中国 — 国営クラウドインフラストラクチャに予算された約200億元の割合	73%

4つの政府、4つのアーキテクチャ姿勢

各政府ブロックの姿勢と重要な指標の要約。

政府	アーキテクチャ姿勢	引用された重要な指標
アメリカ合衆国	断片化/ヘリテージ	年間100億ドル以上のシステムヘリテージ維持に費やされる約80%
欧州連合	明示的なマイクロサービス/ビルディングブロック	GovStack + EuroStack、デジタル主権
インド	レイヤー化アーキテクチャ（インディアスタック）	2026年4月のUPI取引22,350万件
中国	中央集権的な国営クラウド	100%のカバレッジ、約200億元の予算

Ver los datos

4つの政府、4つのアーキテクチャ姿勢

政府	アーキテクチャ姿勢	引用された重要な指標
アメリカ合衆国	断片化/ヘリテージ	年間100億ドル以上のシステムヘリテージ維持に費やされる約80%
欧州連合	明示的なマイクロサービス/ビルディングブロック	GovStack + EuroStack、デジタル主権
インド	レイヤー化アーキテクチャ（インディアスタック）	2026年4月のUPI取引22,350万件
中国	中央集権的な国営クラウド	100%のカバレッジ、約200億元の予算

日本と韓国には、調査した文献の中で、これら4つのブロックと同じように明確に文書化された、または独自のアーキテクチャ姿勢がない — 両国は一般に、OCDEの他の先進国が支配するクラウドへの段階的な近代化パターンに従っており、GovStackやIndia Stackのような同等のマニフェストを持っていない。

このレーダーの5つの軸: <strong>クラウドインフラストラクチャーの成熟度</strong>、<strong>モジュラー性/相互運用性の宣言</strong>、<strong>トランザクションのスケールの証明</strong>、<strong>国家の主権と民間ベンダーへの支配</strong>、および <strong>内部システムの複雑さと成熟度</strong> (特に優先することを求められた軸)。米国、欧州連合、中国、インドを均等な重みで比較した、範囲を定義したように。

大学が何を言っているか（そしてまだ何を知らないか）

米国、欧州連合、中国、インド、日本、韓国の大学での最近の学術研究を探したが、最も誠実な発見は次のとおりである: 学術界は業界の後を追っているのではなく、先を引いているのではない。2020年から2025年5月までの15のピアレビューされた初期研究を発見した、クラウドのモジュラーモノリスに関する最初の正式な体系的文献レビュー — 2025年10月に『Future Internet』誌に掲載された — は、明確な定義に関するコンセンサスが存在しないことを主な結論として示している (Al-Qora'n & Al-Said Ahmad, 2025)。2022年から2026年までの67の情報源を対象とした2026年の2次研究は、業界がすでに数百万ドルを費やしている決定に対する堅牢な経験的基盤の欠如について同様の結論に達している (ResearchGate, 2026)。

『Tsinghua Science and Technology』誌は2026年に、リアルタイム要件を備えた産業自動化のマイクロサービスアーキテクチャに関する研究を発表した (Martínez et al., 2026) — これは一般的な議論に対する中国の機関的姿勢ではなく、特定の技術的角度 (産業4.0) である。インド、欧州、米国の機関の文献では、パターンが繰り返される: モノリスからマイクロサービスへの移行方法に関する数十の論文 (AIを使用した自動境界識別、依存グラフ、機械学習)、しかし、実際に行うタイミングに関する研究は非常に少なく、企業レベルの実際のコストの厳密で再現可能な比較はほとんどない。2025年のarXivに掲載された論文「Microservices Are Dying」は、マイクロサービスの単位をモジュールの汎用インターフェイスに置き換えることを提案しており、分散に対する最も熱心な技術コミュニティ内でさえも、用語自体が不十分に感じられる兆候である (arXiv 2511.04548, 2025)。

誰も予見できなかった転換: IAがIAをオーケストレートするモノリスモジュラー

これは、私が研究を開始したときに自分に問いかけた質問に直接答える、私の研究の中で最も興味深い発見である: ジェネレーティブIAは、より多くの分散またはより多くの統合を促すのか?

2025年、IAエージェント業界は独自の二元的議論を持っていた: 中央コーディネーターなしで互いに通信する複数のエージェントを持つメッシュアーキテクチャと、ツールを持つ単一のエージェント。Devinの背後にある企業であるCognitionは、2025年6月に強い姿勢を発表した: 「マルチエージェントシステムを構築しないでください」 (Cognition, 2025, vía FlowHunt, 2026)。2026年までに、この二極化された議論は、Anthropic、OpenAI、Cognition自身が独立して採用した独自のパターンに崩壊した: 完全なコンテキストを保持し、各エージェントに独自の新しいコンテキストウィンドウを持たせ、相互にミュータブルな状態を共有せず、ポイントツーポイントのチャネルなしに、独立したタスクにエフェメラルサブエージェントを派遣するオーケストレータエージェント (FlowHunt, 2026)。

再び読んでみてください：<strong>ピアツーピアのチャネルはありません</strong>。これはマイクロサービスメッシュのアーキテクチャではありません — これは、ほぼ文字どおり、モジュラーモノリシックの定義です：中央のプロセスに完全な権限があり、需要に応じてモジュールが呼び出され、明確な境界があり、オーケストレーターの制御を離れることはない。Anthropic自身が、そのコードエージェントが正確にこのように動作することを文書化しています：幅広いツールを備えた単一のエージェントループ、独立したサービスメッシュではありません (Anthropic Engineering)。OpenAIは、Swarm（廃止）から現在のSDKまで、明示的なハンドオフを使用して同じ道を歩んできましたが、メッシュコーディネーターはありません。

2025年12月、エージェントツーエージェントプロトコル（A2A）は、Linux Foundationの新しい基金であるIAとエージェント財団（AAIF） (Linux Foundation, dic. 2025) のもと、MCPに参加しました — 座標のインフラストラクチャは標準化されていますが、標準化されるパターンは階層型であり、フラットメッシュではありません。質問は「IAはモノリシックに導かれるのか、またはマイクロサービスに導かれるのか？」です。答えは、IAを構築する人の実際の行動 — マーケティングの議論ではなく — によってもたらされます：モジュラーモノリシックの一形態、破棄可能なサブエージェントを備えたものであり、自律的なマイクロサービスの分散メッシュではありません。

モノリシックアーキテクチャにサブエージェントを組み込むまで

AIエージェントアーキテクチャに関する、この調査で引用された重要な出来事のタイムライン。

1. 1992タネンバウムはトーバルズに、モノリシックカーネルは後退であると伝える — トーバルズは、マイクロカーネルは問題を通信に移動させるだけであると応答する。
2. 2023Amazon Prime Videoがビデオ監視サービスをモノリシックアーキテクチャに統合し、90%のインフラストラクチャコスト削減を達成する。
3. 2025Cognition（Devin）が「マルチエージェントシステムを構築しないでください」と発表する。
4. 2025Linux Foundationの下でAAIFが設立され、MCPとAgent2Agentがアンカープロジェクトとなる。
5. 2026CNCFとSlashDataが、統合論争の最中にバックエンド開発者がマイクロサービスを使用する割合が46%であると報告する。

Ver los datos

モノリシックアーキテクチャにサブエージェントを組み込むまで

Año	Hecho
1992	タネンバウムはトーバルズに、モノリシックカーネルは後退であると伝える — トーバルズは、マイクロカーネルは問題を通信に移動させるだけであると応答する。
2023	Amazon Prime Videoがビデオ監視サービスをモノリシックアーキテクチャに統合し、90%のインフラストラクチャコスト削減を達成する。
2025	Cognition（Devin）が「マルチエージェントシステムを構築しないでください」と発表する。
2025	Linux Foundationの下でAAIFが設立され、MCPとAgent2Agentがアンカープロジェクトとなる。
2026	CNCFとSlashDataが、統合論争の最中にバックエンド開発者がマイクロサービスを使用する割合が46%であると報告する。

2026年にプロジェクトを開始する場合は、次のことを行います

ユニバーサルな答えはありませんが、Amazon Prime Videoのケースから学術的な文献レビューまで、調査したすべての信頼できる情報源に一貫したパターンがあります：

1. <strong>モジュラーモノリシックから始め、フラットモノリシックやマイクロサービスから始めない</strong>。ドメインドリブンデザインを使用して、最初のコミットから明確なドメイン境界を定義します。後で、明確に定義されたモジュールを独立したサービスに抽出することは安価ですが、不完全に定義されたマイクロサービスのメッシュを解消することは非常に高価です。

2. <strong>実際の証拠がある場合にのみサービスを抽出する</strong>、直感ではありません：実際の独立したスケーリングの必要性、物理的な隔離のための規制要件（例：PCIによる支払い）、または真正に互換性のないテクノロジースタック（機械学習のためのPython、コアのためのGo）。

3. <strong>チームのサイズは製品のサイズよりも重要です</strong>。2025-2026年の文献で繰り返されるしきい値 — 明確な組織的境界を持つ50人以上のエンジニア — は、マイクロサービスがその調整コストを正当化し始める地点です（逆に適用されたConwayの法則）。

4. <strong>あなたのアーキテクチャにIAエージェントを統合する場合</strong>、AnthropicとOpenAIが実際の生産で検証したパターン — 中央のオーケストレーターと efemeralで分離されたサブエージェント — は、現在、実際の証拠のある選択肢であり、2024年に議論されていたピアツーピアのエージェントメッシュではありません。

この調査の最終的な信号

本文の39の重要な引用の信頼性分布。

39の引用

• 緑 — プライマリまたは確認済み — 56%
• 黄色 — 一次情報源 — 41%
• 赤 — 検証不可、透明性のために表示 — 3%

Ver los datos

この調査の最終的な信号

Segmento	Valor
緑 — プライマリまたは確認済み	22
黄色 — 一次情報源	16
赤 — 検証不可、透明性のために表示	1

答えは、決定を人間が行わない場合に変わるでしょうか？

これは、私がこの調査を実施するきっかけになった私の実際の質問です：2〜3年以内に、IAエージェントがあなたの次のプロジェクトの初期アーキテクチャを提案するとき — すでにフォルダ構造とモジュール境界を示唆するツールを使用して — 「シンプルから始め、証拠がある場合のみ分散化せよ」ということを推奨し続けるでしょうか？それとも、IAが分散コードを生成して維持するのが容易であるという事実（より多くのサービス、より多くのYAML、より多くの構成）が、人間が疲れることなく維持できるため、複雑さのバランスを再び変えるでしょうか？

あなたは何を見ましたか：あなたのコードのコパイロットは、よりシンプルなものに導くでしょうか、またはより多くの可動部品に導くでしょうか？

Esteban Rey
X: @Kilowatto
LinkedIn: https://www.linkedin.com/in/kilowatto
Wikidata: https://www.wikidata.org/wiki/Q140672978