「アーキテクチャを設計する」とは、一体どういうことなのでしょうか。
従来、それは何らかの「図面」を描くことと同義でした。しかし、変化が加速し続ける現代において、その定義は揺らいでいるように感じます。正直なところ、私自身も「これからのアーキテクチャ設計」の正体が何なのか、わからなくなる瞬間があります。
「アーキテクチャのアーキテクチャ」とも呼べるような、メタ的な何か。
まだ生煮えではありますが、この「メタ・アーキテクチャ」という視点について、思考を進めてみたのが本記事です。
1. 時代背景：「不変」から「流動」への不可逆なシフト
なぜ今、改めて「アーキテクチャとは何か」を問い直す必要があるのでしょうか。それは、私たちが無意識のうちに前提としてきた「変化の速度」と「変化の単位」が、この十数年で劇的に、そして不可逆的に変わってしまったからです。
最初に、少し時間を巻き戻して、オンプレミス時代から現在までを振り返ってみましょう。技術的な変遷史としてではなく、「何が『制約』で、何が『正解』とされていたか」という価値観の変遷として眺めてみます。
オンプレミス時代：「予測可能性」への信仰と城塞の構築
かつて、サーバーの調達には数週間から数ヶ月を要しました。ネットワークケーブルを敷設し、ラックを組み、OS をインストールする—— 物理的な制約が、開発のスピードを規定していた時代 です。そんなに昔ではない2010年頃までです。
この環境下において、アーキテクチャ設計における最大の美徳は「予測可能性」でした。一度構築したハードウェア構成やネットワークトポロジーを変更することは、莫大なコストとリスクを伴う一大プロジェクトになります。したがって、設計者は「いかに将来の変化を事前に予測し、最初の一発で正解を当てるか」という不可能なゲームに挑まざるを得ませんでした。
ここでは、アーキテクチャは「城塞」の設計図のようなものです。堅牢で、揺るぎなく、一度建てたら数年はその姿を保つもの。変更コストが高いからこそ、事前の詳細な設計（Big Design Up Front、BDUF）が経済合理的であり、ウォーターフォール型のプロセスとも相性が良かったのです。
クラウド時代：「可処分性」の獲得と複雑性の爆発
クラウドコンピューティングと Infrastructure as Code (IaC) の普及は、この前提を根底から覆しました。私たちは「インフラをコードで管理する」力を手に入れ、サーバーは数分で立ち上がり、気に入らなければコマンド一つで破棄できるようになりました。
この時代の変化を象徴する言葉が、Randy Bias 氏による 「Pets vs Cattle（ペットと家畜）」 のアナロジーです。（現在ではより適切な表現も模索されていますが、管理スタイルの変化を表す原点となる言葉です）
日本的な感覚で言えば、これは 「盆栽」から「農作物」へのシフト に近いかもしれません。
かつてのサーバーは、固有の名前を持ち、枝ぶり（設定）を微調整しながら、長い時間をかけて維持管理される「盆栽」のような存在でした。対してクラウド時代は、広大な農地で一律に管理される「農作物」のアプローチをとります。個々の形状にこだわらず、不調な株があればすぐに植え替え、システム全体の収穫（パフォーマンス）を最大化することに集中するのです。
「とりあえず作って、ダメなら作り直す」というアジャイルなアプローチがインフラ層まで浸透したことで、アーキテクチャはより流動的になりました。マイクロサービスアーキテクチャが隆盛を極めたのも、変化の影響範囲を小さな「サービス」という単位に閉じ込め、それぞれを独立して進化させるためでした。
一方で、コンピューティングリソースが入れ替え可能になっても、容易に捨てられないものが残りました。「データ（状態）」 です。本稿では触れませんが、変えやすいアプリケーション（Stateless）と変えにくいデータ（Stateful）の関係をどう整理するかは、クラウド時代における設計の最重要テーマの一つです。
生成 AI 時代：「非連続な再構築」へのシフト
そして今、私たちは生成 AI の時代に足を踏み入れています。ここでの変化は、単なるコードの修正やリファクタリングの効率化にとどまりません。「仕様から実装へ」の変換コストが極限まで下がることで、開発のパラダイムそのものが 「非連続な再構築」 へと変わろうとしています。
これまでは、既存のシステムの「一部分」を慎重に修正するのが当たり前でした。しかし、人間と AI が対話しながらコーディングする世界では、あるコンポーネントを丸ごと別の言語で書き換えたり、非構造化データを扱うパイプラインを即座に生成したりすることが現実的になりつつあります。
「リファクタリング」よりも「リライト（書き直し）」の方が速くて正確かもしれない——そんな逆転現象すら起き始めています。
ここでは、変化のサイクルは「数年」から「数日・数時間」へと短縮され、変化の単位も「行・ファイル」から「コンポーネント・業務フロー」へと大きくなっています。もはや「この技術スタックで 3 年間安定稼働させる」という前提で設計すること自体が、技術的負債を生むリスクになりかねない時代かもしれません。
さらに言えば、「仕様駆動開発」という名の現代版・超高速ウォーターフォール が到来しつつあるのかもしれません。AI が実装（コーディング）を瞬時に完了させる世界では、「仕様（プロンプト）」を完璧に定義すれば、その後の工程は一瞬で終わります。これは見方を変えれば、前述した「Big Design Up Front」の究極形とも言えます。しかし、決定的な違いは「やり直しコスト（Re-work Cost）」がほぼゼロである点です。作っては壊し、壊しては作る。
そのサイクルが超高速で回るからこそ、アーキテクチャは「変化の衝撃」を吸収するクッションとして機能しなければならないのです。
2. アーキテクチャの再定義：静的な「図面」から動的な「反応」へ
このような激動の時代において、アーキテクチャを単なる「静的な構成図」として捉えることには限界があります。実際、アーキテクチャ論の関心領域は、この数十年で「静的な構造」から「時間の経過に伴う進化」や「運用時の振る舞い」へと広がってきました。理論もまた、変化を許容し、制御するための動的なものへとシフトしているのです。
そこで、これらの文脈を踏まえ、本稿ではアーキテクチャを次のように再定義してみたいと思います。
アーキテクチャとは、外部からの変化に対してシステムが「どこで」「どう」反応するかを規定する、「ストラクチャ」と「ルール」のセットである。
従来の定義を否定するものではありませんが、より「変化への反応（Reaction）」に重きを置いた解釈です。以下、従来の解釈にも軽く触れておきましょう。
ストラクチャ（Structure）：図面に描けるもの
これは従来通りのアーキテクチャのイメージです。コンポーネントの分割、データベースの配置、それらをつなぐインターフェース。
重要なのは、このストラクチャが「変化の防波堤」として機能しているかどうかです。あるビジネス要求の変更が来たとき、それは特定のコンポーネント内で完結するのか、それともシステム全体に波及してしまうのか。ストラクチャは、その衝撃の伝わり方を決定づけます。
ルール（Rules）：変化の作法
現代のアーキテクチャにおいてより重要なのが、この「ルール」です。
- 変更をどのような手順で適用するか（CI/CDパイプライン、GitOps）
- サービスの健全性をどう定義し、維持するか（SLO、エラーバジェット）
- チーム間の責任分界点をどこに置くか
これらは通常、アーキテクチャ図には描かれませんが、システムが長く健全に生き続けるためには不可欠な要素です。「良い図面」だけでは不十分で、「その図面を良い状態に保ち続けるためのルール」がセットになって初めて、機能するアーキテクチャと呼べるのではないでしょうか。
3. これからのアーキテクチャに求められる 3 つの性質
では、再定義した「ストラクチャ」と「ルール」を、現場で具体的にどう扱えばよいのでしょうか。
ここ数年の代表的なアーキテクチャに関する技術書や理論を総合すると、不確実な未来を生き抜くための羅針盤として、3 つの性質に収斂できるかもしれません。
見えにくいシステムの振る舞いを「観測」できるようにすること (1)、「ルール」を人の規律ではなく自動化された仕組みで守らせること (2)、そして「ストラクチャ」自体をいつでも捨てられる状態に保つこと (3) です。
(1) 「可観測性」でシステムの振る舞いを透視する
静的な図面（ストラクチャ）がどれほど美しくても、動いているシステム（ルール）がどう振る舞っているかが見えなければ、変化に対応することはできません。
そこで不可欠なのが 「可観測性（Observability）」 という性質です。
従来の「死活監視（Monitoring）」が「システムが生きているか死んでいるか」を知るためのものだとすれば、可観測性は「なぜシステムがそのような振る舞いをしているのか」を外部から理解できる能力を指します。
『SRE サイトリライアビリティエンジニアリング (Site Reliability Engineering)』 などが詳しく解説しているように、ログ、メトリクス、分散トレーシングといった仕組みをアーキテクチャの第一級市民として組み込むこと。
これにより、予期せぬ変化やパフォーマンスの劣化を即座に検知し、次のリアクション（修正やロールバック、あるいはスケーリング）を決定するための「目」を手に入れることができます。
見えないものは、判断できず、直せません。高い可観測性は、変化への反応速度を決定づける前提条件と言えるでしょう。
(2) メトリクスと適応度関数で「健全性」を回し続ける
「このアーキテクチャは変更に強いです」と口頭で説明するだけでは不十分です。私たちは、アーキテクチャの特性を定量的な指標で計測し、客観的に評価し続ける必要があります。
Neal Ford らの著書 『進化的アーキテクチャ (Building Evolutionary Architectures)』 では、適応度関数（フィットネス関数、Fitness Function） という概念が提唱されています。これは、遺伝的アルゴリズムに由来する言葉で若干馴染みがなかったのですが、ソフトウェアにおいては「システムが満たすべきアーキテクチャ上の目標（可用性、セキュリティ、応答性能など）をコード化し、自動的に計測・評価する関数」を指します。
例えば、「循環的複雑度が一定以下であること」「特定のレイヤー間の依存方向が守られていること」「レスポンスタイムが X ミリ秒以内であること」といったルールを、テストコードとして CI パイプラインに組み込みます。もし開発者がアーキテクチャ上の制約を破る変更を行えば、パイプラインが失敗し、即座にフィードバックが得られます。
また、『アジャイルとDevOpsの科学 (Accelerate)』 も、デプロイ頻度、変更リードタイム、変更失敗率、MTTR（平均復旧時間）といったメトリクスを通じて、開発プロセスとアーキテクチャの健全性を測ることを強く推奨しています。
人間の記憶や規律に頼るのではなく、メトリクスという「数値」を頼りに、アーキテクチャを継続的に進化（Evolve）させていく姿勢。これこそが、変化の激しい時代における確かな拠り所となるはずです。
(3) 「非連続な再構築」を前提とした可処分性 (Disposability)
最後に、生成 AI 時代特有の視点です。
前述の通り、開発のパラダイムが「非連続な再構築」へとシフトする中で、コードの「寿命」に関する考え方も変わります。これまでは「一度書いたコードをいかに長くメンテナンスするか」が重要でしたが、これからは「古くなったコードをいかに低コストで捨て、AI に書き直させるか」が重要になるかもしれません。
このとき鍵となるのが、システムの 「可処分性（Disposability）」 です。
『ソフトウェアアーキテクチャ・ハードパーツ (Software Architecture: The Hard Parts)』 では、サービスの粒度や結合度に関するトレードオフが詳細に議論されていますが、これからの時代は「将来的に AI で作り直す単位」としてのモジュール性がより重要になります。
必ずしも最初からマイクロサービスである必要はありません。「モジュラーモノリス」のように、デプロイ単位は大きくても、内部のモジュール境界が明確に保たれていれば十分です。重要なのは、ある日突然「このモジュール、Python で書き直して AI モデルを組み込みたい」となったときに、他の部分に影響を与えずにそこだけを切り離せる（Detachable）かどうかです。
「腐敗防止層（Anti-Corruption Layer）」パターンなどを活用し、変化の激しい部分と安定した部分の間にクッションを挟むこと。そして、いつでも部品を交換できるようにしておくこと。これが「非連続な再構築」の時代における現実的なアプローチの一つです。
これは、『Continuous Architecture』 が掲げる「決定を遅らせる（Delay design decisions）」や「変化のために設計する（Architect for change）」という原則とも通底しています。
4. 「メタ・アーキテクチャ」という視点への昇華
ここまで見てきた 3 つの性質——可観測性による透視、計測による進化、適切な境界設計による可処分性——を統合して俯瞰すると、ある一つの共通項が浮かび上がってきます。
それは、アーキテクトの仕事が「個別の技術選定や構成の決定」から、「アーキテクチャの変化そのものを管理する仕組みの構築」 へとシフトしているという潮流です。ここではその概念を、仮に 「メタ・アーキテクチャ」 と呼んでみたいと思います。
Sense / Judge / Act のサイクル
具体的には、第3章で述べた3つの性質を、有機的なフィードバックループとして統合する考え方です。
- 感知する（Sense）: システムの振る舞いを透視する 「可観測性」
- 判定する（Judge）: 変化の良し悪しを自動判定する 「適応度関数」
- 実行する（Act）: いつでも構造を書き直せる 「可処分性」
「どのような図面を描くか」よりも、「この Sense-Judge-Act のサイクルがいかに高速かつ安全に回るか」を設計すること。これをメタ・アーキテクチャの実体と捉えることができます。
この概念をより直感的に理解するために、少しソフトウェアから離れて、物理的な世界の例を見てみましょう。優れたシステムには、同様の構造が見て取れます。
-
都市計画におけるゾーニング
都市計画家は、個々の家の設計図を描くわけではありません。「ここは住宅地」「ここは商業地」といった「ルール（メタな構造）」を定めることで、個々の建物が自由に建て替えられても、都市全体の秩序と機能が維持されるようにします。 -
生物学における DNA
DNA は完成した身体の「青写真（静的な図面）」ではなく、タンパク質をどう合成するかという「プロセス（動的な手順）」の情報を持っています。環境との相互作用の中で、プロセスが実行された結果として身体が形成されます。 -
国家における憲法と司法
憲法は「国民が今日何を食べるか」は決めませんが、「紛争が起きたときにどう解決するか（司法）」や「新しい法律をどう作るか（立法）」というメタなルールを定めています。社会環境の変化に合わせて法律自体をアップデートする手続きが定義されており、国家というシステムは破綻せずに存続できます。
その他にも、参加者のインセンティブを設計する市場メカニズム、無限の表現を生成する言語の文法、あるいは環境との相互作用で多様性を維持する 生態系（エコシステム） など、優れたシステムには共通して「メタ・アーキテクチャ」が埋め込まれていそうです。
そして、これは現代のソフトウェアアーキテクチャにおいても、同じことが言えそうです。
これからのアーキテクトに求められるのは、完璧な静的図面を描く能力ではありません。「何を作るか」だけでなく、「どう作るか」「どう変えるか」「どう評価するか」という 変化のプロセスそのものをシステムの中に組み込み、自動化・省力化していく能力が求められているのではないでしょうか。
おわりに：「形」ではなく「流れ」をデザインする
もはや、静止画としての「ストラクチャ」に美しさは求められていません。重要なのは、動画として見たときの「ルール（振る舞い）」の滑らかさなのかもしれません。
障害が起きてもすぐに回復するしなやかさ、新しい技術を飲み込んで成長する流動性。アーキテクティングは、ホワイトボードの前で腕を組むことから、チームの中に飛び込み、日々の開発の「流れ」そのものを整えることへと変わりました。
冒頭で述べた通り、この思考自体まだ生煮えです。しかし、完成された「正解」がないことこそが、この変化の激しい時代の面白さでもあります。本記事が、皆さんの現場における「メタ・アーキテクチャ」の実践の一助となれば幸いです。
補足: 参考文献・関連リンク
- IEEE 1471 / ISO/IEC/IEEE 42010 (2000/2011)
- Continuous Architecture (2015)
- SRE サイトリライアビリティエンジニアリング (Site Reliability Engineering) (2016)
- 進化的アーキテクチャ (Building Evolutionary Architectures) (2017)
- アジャイルとDevOpsの科学 (Accelerate) (2018)
- ソフトウェアアーキテクチャ・ハードパーツ (Software Architecture: The Hard Parts) (2021)
補足: スライドの紹介
本記事はイベント「【6社共催】スケールするサービスにおけるアーキテクチャの工夫・苦労を語る会」の登壇内容と対応しています。スライドでも合わせてご覧ください。
Discussion