制約を読まないエンジニアへ¶
チェック¶
- [ ] 本文を確認した
- [ ] 概要を確認した
- [ ] タグを確認した
- [ ]
inbox/直下へ移行した
概要¶
マイクロサービス、REST、AIエージェントのような流行の形だけを採用しても、その背後にある制約を理解していなければ設計にはならない、という記事。 アーキテクチャは部品の組み合わせではなく、何を許し、何を禁じるかという制約の設計である。 過去のマイクロサービス分割の失敗、Roy Fielding の REST 論文、責任が蒸発するフルリニューアルの問題を通して、エンジニアが「形」ではなく「制約」を読むべきだと論じている。
本文¶
記事は、メルカリのグローバルアーキテクチャ刷新の話を起点に、筆者の所属組織でも似た問題が起きていたという振り返りから始まる。 巨大なモノリスを分割し、複数のサービスに切り出し、疎結合化を目指す。 一見すると正しい方向に見えるが、サービス境界を切ることと、ドメイン境界を理解することは同じではない。
サービス境界とドメイン境界は違う¶
マイクロサービス化でありがちな失敗は、デプロイ単位やチーム単位をサービス境界として先に切ってしまい、業務上の概念や不変条件のまとまりを後から押し込めること。 この場合、サービスは分かれていても、ドメインの依存関係は分かれていない。
たとえば、ある業務概念が複数サービスにまたがって複製される。 同じようなコンテキストや状態が、別々のサービスに微妙に違う形で置かれる。 更新順序、整合性、責務の境界が曖昧になり、開発者は「どこを直せばいいのか」「どのサービスが正なのか」を毎回考えることになる。
記事では、サービス境界はあくまでデプロイや運用の境界であり、ドメイン境界はモデルの境界だと整理される。 サービスを分割しても、ドメイン理解が浅ければ、問題は消えずに分散する。 むしろ、モノリスの中にあった問題が、ネットワーク越しの分散した問題として見えにくくなる。
なぜマイクロサービスに惹かれたのか¶
筆者は、当時マイクロサービスが魅力的に見えた理由も否定しない。 巨大なコードベースでは、CI が遅い、デプロイが重い、複数チームの変更が衝突する、あるチームの都合で別チームのリリースが止まる、といった問題が起こる。
その状況で、サービスごとにデプロイできる、チームごとに独立できる、Go や Kubernetes や gRPC を使える、という選択肢は合理的に見える。 しかし、本当にマイクロサービスだけが解だったのか、という問いが残る。
別の選択肢としては、モジュラーモノリス、ビルドとテストの改善、モノレポ内のモジュール境界の強化、リリースプロセスの改善、チーム間の責務整理があり得る。 重要なのは、流行の形を採用することではなく、「その制約によって何を解決し、何を犠牲にするのか」を比較すること。
Design by Constraint¶
記事の中心概念は、Roy Fielding の REST 論文にある「アーキテクチャスタイルは制約の集まりである」という考え方。 アーキテクチャは、コンポーネントや通信形式の寄せ集めではない。 要素どうしの関係に制約をかけることで、望ましい性質を引き出す。
制約は自由の欠如ではなく、長期的な拡張性や保守性を守るための仕組みである。 局所最適を抑え、システム全体として守りたい性質を維持する。
型システムは、何でも代入できる自由を奪う代わりに、プログラムの誤りを早く見つける。 データベースの正規化は、好きな場所に同じデータを置く自由を奪う代わりに、更新の一貫性を守る。 UNIX の「一つのことをうまくやる」という設計思想も、部品の責務を絞る制約によって、組み合わせ可能性を高める。
マイクロサービスや REST も本来は制約の体系である。 どこに状態を置くのか、どの依存を許すのか、同期通信をどこまで許容するのか、サービス間のデータ整合性をどう扱うのか。 これらを読まずに「RESTっぽいAPI」「マイクロサービスっぽい構成」だけを真似ても、アーキテクチャにはならない。
Design by Buzzword¶
記事では、Fielding が警戒していた「Buzzword で設計してしまう」問題にも触れている。 よい設計者は、問題に合うアーキテクチャスタイルを選ぶ。 悪い設計者は、名前の通ったスタイルを採用したことで設計した気になる。
REST は URL と JSON のことではない。 マイクロサービスは、小さいサービスをたくさん作ることではない。 AI エージェントも、LLM を呼ぶタスクランナーを作ることではない。
背後の制約を理解せず、表面的な形だけを消費すると、かえって複雑性が増える。 導入時は新しい技術で前進しているように見えても、数年後には「なぜこう分けたのか」「誰が最後まで責任を持つのか」が分からなくなる。
フルリニューアルと責任の蒸発¶
記事は、フルリニューアルの問題も扱う。 大規模な作り直しは、初期には魅力的に見える。 古いコードを捨てられる、新しい技術を使える、負債を清算できる、設計をやり直せる。
しかし、後半になるほど現実の重さが出てくる。 既存データの移行、互換性、運用監視、業務フロー、障害対応、利用者への影響、リリース後の責任。 作り始めた人や意思決定した人が異動・退職していると、最後まで責任を持つ人が見えなくなる。
記事では、これは個人のやる気や美学の問題だけではなく、組織設計の問題として扱われる。 組織が「始めること」を評価し、「終わらせること」や「移行後に運用すること」を評価しないなら、責任は蒸発する。
AI時代にも同じことが起きる¶
筆者は、同じ問題が AI エージェントや業務自動化でも起きると見る。 流行の構成、流行のツール、流行の言葉を導入しても、どの制約を置くのかを設計しなければ、単に複雑なワークフローが増えるだけになる。
AI に何を任せるのか。 人間はどこで承認するのか。 誤りをどこで止めるのか。 実行ログや責任の所在をどう残すのか。 既存業務のどの部分を変え、どの部分を守るのか。
これらを考えずに「AIエージェントで自動化する」という形だけを採用すると、過去のマイクロサービス導入と同じように、制御できない複雑性が増える。
読み替え¶
この記事の実務的な価値は、技術選定時の問いを変えるところにある。
「この技術は流行っているか」ではなく、「この技術はどんな制約をシステムに導入するか」。 「この構成はかっこいいか」ではなく、「この構成によって何が簡単になり、何が難しくなるか」。 「他社がやっているか」ではなく、「自分たちの問題にその制約が合っているか」。
設計とは、自由に何でもできる状態から、意図的にできないことを増やす行為でもある。 その制約を読めるかどうかが、アーキテクチャを使う側と設計する側を分ける。
要点¶
- サービス境界は運用・デプロイの境界であり、ドメイン境界とは別物。
- マイクロサービス化は、ドメイン理解なしに行うと問題を分散させるだけになる。
- アーキテクチャスタイルは、部品の形ではなく制約の組み合わせである。
- REST、マイクロサービス、AIエージェントは、制約を読まずに使うと Buzzword 設計になる。
- 大規模リニューアルでは、移行、互換性、運用、責任の所在まで設計しないと責任が蒸発する。
- 技術選定では「何を可能にするか」と同時に「何を禁止するか」を見る。