設計は固定するほど速くなる: CloudFormationとNext.jsが教える「変更の通路」を守る技術

Apr 28, 2026

1 min read

2 views

72%

変更を自由にするほど、なぜ運用は壊れるのか

システムを速く進化させたいなら、変更は自由なほうがいい。そう思いたくなります。ところが実際には、変更の自由度を上げるほど、後からの理解と更新は難しくなることが多いです。これはインフラでもフロントエンドでも同じで、いったん秩序を崩した場所は、次の変更で思いがけない代償を請求してきます。

一見すると、クラウドの管理と Web アプリの設計はまったく別の話に見えるかもしれません。ですが、両者の中心には同じ問いがあります。

いまの状態を、どこを通って、どのルールで変えていくべきか。

この問いに答えられないシステムは、動いているように見えても、内部では少しずつ崩れます。変更そのものが悪いのではありません。問題は、変更の通路が一本化されていないことです。

CloudFormation の世界ではそれをドリフトと呼びます。テンプレートが正史なのに、途中で手でいじった結果、定義と現実がずれていく。Next.js の設計思想にも、別の形で同じ緊張があります。フレームワークが提供する規律の外側で勝手に状態を増やしたり責務を散らしたりすると、開発速度は一瞬上がっても、全体の見通しは急速に悪くなる。つまり、両者が示しているのは「自由に変えられること」よりも、どのレイヤーに真実を置くかのほうが重要だという事実です。

ドリフトとは、設定のズレではなく「責任のズレ」である

CloudFormation の警告は単純です。スタックのリソースを CloudFormation 以外の方法で変更するな。なぜならテンプレートと実体が食い違い、更新や削除で問題が起きるからです。ここで起きている本質は、単なる設定差分ではありません。もっと深く言えば、誰がその状態に責任を持つのかが曖昧になることです。

たとえば、ECS の task definition をコンソールで少しだけ修正したとします。動作確認のために CPU や環境変数を一時的に変える、そんな軽い気持ちだったかもしれません。しかし次のデプロイでテンプレートが再適用されると、その場しのぎの変更は消えます。しかも困るのは、変更した本人が「確かに動いていたのに」と感じる一方で、テンプレート側はその変更を知らないことです。ここでは、真実が二重化しています。

このズレは、ソフトウェア開発における「設定ファイルと実行時の現実の乖離」と同じ構造です。コード上では A だが、実際は B。ログでは正常だが、実体は不安定。表面上は小さな手直しでも、責任の所在が分散すると、誰もシステム全体を正しく説明できなくなります。

ドリフトの怖さは、壊れることではない。壊れても、なぜ壊れたのかを説明できなくなることにある。

ここで重要なのは、ドリフトを単なる「禁止事項」として捉えないことです。むしろドリフトは、状態管理の思想が崩れたときに現れる症状です。テンプレートが唯一の真実なのか、実行時の状態が唯一の真実なのか、その境界が曖昧なままだと、変更は積み上がるのではなく、砂の上に痕跡を残すだけになります。

Next.js の本質は、機能の寄せ集めではなく「変更の秩序」を作ること

Next.js を単なる React の便利セットだと捉えると、その価値を見誤ります。Next.js の本当の強さは、ページルーティング、サーバーサイドレンダリング、静的生成、API、ビルド最適化といった機能の多さではなく、アプリケーションが変化していくときの秩序を提供する点にあります。

Web アプリは放っておくと、状態があちこちに散らばります。表示の都合でコンポーネントにロジックが入り、データ取得が各所に分散し、サーバーとクライアントの境界が曖昧になる。すると、見た目は動いていても、どこを直せば何が変わるのか分からないシステムになります。これが大規模化したときの一番の敵です。バグそのものよりも、変更の影響範囲を推測できないことが開発を遅くします。

Next.js が価値を持つのは、そうした混沌に対して「ここでデータを取り、ここで描画し、ここで最適化する」という通路を与えるからです。つまり、自由に何でもできるようにするのではなく、変えてよい場所と変えるべきでない場所を分ける。この境界設計が、長期運用では圧倒的に効きます。

たとえば、EC サイトのトップページを考えてみます。商品一覧、在庫、価格、レコメンド、検索、購入導線が絡む領域です。ここで各コンポーネントが好き勝手に API を叩き、ローカル状態を持ち、表示のたびに独自ルールで加工を始めると、初速は出てもすぐに破綻します。逆に、Next.js の構造に沿ってデータの取得と描画の責務を整理すると、ページ全体の再現性が上がる。再現できることは、修正できることです。

この視点で見ると、Next.js の思想は CloudFormation に驚くほど近いです。どちらも、開発者の自由を奪うための制約ではありません。むしろ、自由を長持ちさせるために、変更の正統な経路を定めています。ルールがあるから遅いのではなく、ルールがないから後で止まります。

速いチームは、変更を速くするのではなく「変更可能性を保存する」

ここで少し逆説的な結論に進みます。優れたチームは、変更回数が多いチームではありません。変更しても壊れない性質を守れるチームです。

その違いは、短期のスピードと長期の速度の差に表れます。短期のスピードは、手元で直接いじるほど上がりやすい。ですが長期の速度は、後から同じシステムを安全に理解し、再現し、更新できるかで決まります。つまり、運用を重ねるほど重要になるのは「いま何ができるか」ではなく、「次も確実に変えられるか」です。

このとき有効な考え方が、変更の単一通路モデルです。システムに対する変更は、必ず一つの正規ルートを通るように設計します。

宣言層: 何があるべきかを定義する。CloudFormation のテンプレートや、Next.js のフレーム設計に相当する。
適用層: 定義を反映する。コンソールでの手作業ではなく、決められたプロセスで変更を流す。
観測層: いま実際にどうなっているかを確認する。差分や挙動を可視化する。
例外処理層: どうしても外れ値が必要な場合の逃げ道を明文化する。例外を暗黙にしない。

このモデルの肝は、何かを禁止することではありません。むしろ、変更の履歴を一つの物語にすることです。どこで定義され、どこで適用され、どこで確認されるのかが一続きになっていれば、チームはシステムを説明できます。説明できるシステムは、改善できます。

CloudFormation で手動変更を避けるのも、Next.js で責務を整理するのも、この物語を壊さないためです。変更の履歴が途切れると、デバッグは推理ゲームになります。履歴がつながっていれば、デバッグは検証作業になります。この差は大きいです。

例外を許すかどうかではなく、例外をどう封じるか

現実には、完全な理想状態などありません。ときには緊急対応で直接修正したくなるし、仕様検討の途中で暫定的に触りたくもなる。問題は、例外を一切なくすことではなく、例外をそのまま常態化させないことです。

ここで役立つのが、次の問いです。

その変更は、どの正規ルートを通るべきか
その場しのぎの修正は、いつ正史に取り込まれるのか
例外が残ったとき、誰がその存在を説明できるのか

CloudFormation のドリフトは、例外がそのまま本体になった状態です。Next.js の設計でも、暫定の処理が component ごとに増殖すると、やがて「仮」が「本」になります。これは非常に危険です。なぜなら、仮のものは自分で正当化され続けるからです。最初は一時的な回避策だったとしても、次第に依存が生まれ、誰も外せなくなる。

だから必要なのは、例外をゼロにすることではなく、例外に期限と責任者を持たせることです。いつまでに正規ルートへ戻すのか。どのテンプレート、どのルート、どの設計に反映するのか。これを明確にしない限り、例外は改善ではなく債務になります。

システムを壊すのは、大きな失敗より、小さな例外が記録されないことだ。

この視点に立つと、設計とは美しい構造を作ることではなく、例外が増えても秩序を回復できる構造を作ることだと分かります。

Key Takeaways

変更の正規ルートを一本化する。手作業、分散した設定、暗黙の修正を減らし、何を変えるかを必ず一つの通路に流す。
真実の置き場所を決める。CloudFormation のテンプレートのように宣言を正史にするのか、Next.js の構造のように責務を明確にするのか、曖昧にしない。
例外を仮のまま放置しない。緊急修正には期限、記録、戻し先を必ず持たせる。
変更可能性を守る。短期的な便利さより、次の変更で再現できることを優先する。
ズレを見つけたら、原因を責任の分散として疑う。不具合は設定ミスではなく、状態管理の設計不全として捉える。

変更を速くする最短ルートは、変更を雑にしないこと

私たちはしばしば、速く進むためにルールを減らしたくなります。けれど実際には、スピードを失わせるのはルールではなく、ルールの欠如です。どこでも変えられる状態は、どこでも壊せる状態でもあります。

CloudFormation が教えるのは、状態は宣言に従って変えるべきだという原則です。Next.js が示すのは、アプリは境界と責務を整えることで長く速く保てるという感覚です。この二つを重ねると、ひとつの結論に行き着きます。優れたシステムは、変更をたくさん許すのではなく、変更の意味を失わないように作られているのです。

本当に速いチームは、目の前の修正を増やすチームではありません。修正が積み重なっても、なおシステムの正史が保たれている状態を作るチームです。そこでは、変更は混乱の原因ではなく、秩序の中を流れるエネルギーになります。

そしてそのとき初めて、私たちはこう言えるようになります。設計とは、変化を止めることではない。変化が迷子にならないように、通路を作ることだ。