状態管理とクラウド請求は、どちらも『見えない増殖』を設計する仕事である

触るのは無料、増えるのは高くつく

フロントエンドの世界では、コードを書いている瞬間よりも、増え始めた瞬間に本当の難しさが現れます。状態は増えるほど追いにくくなり、インフラは伸びるほど請求が読めなくなる。どちらも最初は快適です。けれど、チームが成長し、機能が増え、利用が広がると、突然「なぜこんなに複雑なのか」「なぜこんなに高いのか」という問いに変わります。

この二つの悩みは、一見まったく別物に見えます。片方は UI のデータ設計、もう片方はクラウドの課金設計です。しかし根っこにある問題は驚くほど似ています。何かを簡単に始められることと、増えた後も安定して扱えることは別問題だということです。

ここに、現代のプロダクト開発の核心があります。私たちが本当に設計しているのは、機能そのものではなく、増殖の仕方なのです。

---

便利さはいつも、複雑さの先払いである

新しい状態管理ライブラリが受け入れられる理由は、しばしば「書きやすいから」です。部品のように状態を切り出せて、派生した値も自然に作れる。考え方はシンプルで、局所的に見れば非常に気持ちがいい。コードの見通しが良くなり、関心が小さな単位に分解されると、開発者は安心します。

一方で、Vercel のような強力なプラットフォームも、最初は同じ魅力で選ばれます。デプロイは簡単、体験は滑らか、スケールの立ち上がりも速い。つまり、どちらも摩擦を減らすことで支持されるのです。

しかし、摩擦が少ない設計は、必ずしも増殖に強い設計ではありません。ここに落とし穴があります。便利さはたいてい、将来の複雑さを今は見えない形で先送りしているだけです。状態管理であれば、依存関係が増えたときに何が誰を更新しているのかが曖昧になる。インフラであれば、使った分だけ課金される構造が、成長とともに予想外の請求へつながる。

便利なものは、しばしば「最初の一歩」を最適化している。だがプロダクトの難所は、最初の一歩ではなく、千回目の一歩にある。

この視点に立つと、状態管理とコスト管理は同じ問いに回収されます。増えたものをどう観測し、どう制御し、どこまで自動化するかです。

---

派生状態と従量課金は、どちらも「再計算の値段」を問う

ここで面白いのは、状態管理における派生状態の考え方が、クラウド課金の感覚と驚くほど重なることです。派生状態とは、元の状態から計算して得られる値です。たとえば、複数の入力から「合計金額」を出したり、一覧から「未完了件数」を算出したりする。これは便利ですが、どこで計算するか、どれだけ頻繁に再計算するかが重要になります。

Vercel のコストも、実は同じ発想で見られます。アクセスが来るたび、関数が動くたび、ビルドが走るたび、ネットワーク転送が発生するたびに、何らかの「再計算」が請求に変わる。つまりクラウド課金は、実行された抽象のコストです。抽象化したつもりの処理が、実際には何度も現実世界の計算資源を使っている。

この対応関係を意識すると、設計の問いが変わります。

• この値は本当に毎回計算する必要があるのか
• キャッシュできるのか
• 必要なときだけ作ればいいのか
• 増分だけ処理できるのか

状態管理でも同じです。全体を毎回更新するのか、それとも局所的な差分だけを反映するのか。Recoil から Jotai のようなより原子的なモデルへ関心が移る背景には、単なる流行以上に、再計算の粒度を小さくしたいという欲求があります。大きな塊として扱うより、最小単位で持っていた方が、更新範囲を狭められるからです。

この感覚は、クラウドでも同じです。大きな処理を一つの重い単位として置くのではなく、できるだけ小さく、再利用可能にし、無駄な実行を抑える。つまり、派生状態の設計はコードの話であると同時に、コストの設計思想でもあるのです。

価値のある最適化とは、速くすることではなく、再計算しなくて済む構造を作ることだ。

---

本当に必要なのは、状態を減らすことではなく、可変性の半径を縮めること

ここで多くの開発者が誤解しやすいのは、「状態が増えるのが悪い」と考えてしまうことです。実際には、状態があること自体が問題なのではありません。問題なのは、どこまでが一つの変更で動いてしまうかです。これを私は可変性の半径と呼びたいです。

たとえば、ある画面のフィルタ条件を変えたとき、一覧だけが再描画されるなら半径は小さい。だが、その変更がサマリー、グラフ、検索候補、ログ送信、サーバー再取得まで連鎖するなら半径は大きい。コードが見た目上は整理されていても、変更の波紋が広ければ、実質的には大きなモノリスです。

Vercel のコストも同じです。1 回のユーザー操作が、複数のサーバーレス関数、エッジ処理、外部 API 呼び出し、再ビルド、画像最適化を引き起こすなら、見えているのは機能の数ではなく、波紋の広さです。利用者は一度のクリックしかしませんが、裏側では複数の課金イベントが連鎖している。

この観点から優れた設計は、状態を「少なくする」ことではなく、次の二つを満たします。

1. 変更点を局所化する
2. 再計算や再実行の範囲を狭める

Jotai のような原子的な状態設計が魅力的なのは、まさにこの局所化にあります。ひとつの atom を変えても、必要な派生だけが動く。Vercel のコスト最適化が重要なのも、同じく局所化の問題です。ルート全体を毎回巻き込むのではなく、静的にできる部分は静的にする、キャッシュできる部分はキャッシュする、重い処理はアクセスのたびにやらない。

要するに、スケールに強い設計とは、変化が伝染しにくい設計です。

---

「早く動く」より「遅く壊れない」を選ぶ

プロダクト初期は、どうしても「とにかく動く」が正義です。状態管理もインフラも、まずは機能することが最優先です。だが成長フェーズに入ると、価値基準は静かに入れ替わります。求められるのは速度ではなく、予測可能性です。

予測可能性とは、単にバグが少ないことではありません。変更したときに何が起こるか、負荷が増えたときにどこが先に痛むか、請求が増えたときにどの操作が原因か、これらを事前に説明できることです。つまり、システムのふるまいが「偶然」ではなく「設計」で説明できること。

この意味で、状態管理とコスト管理はどちらも、未来の説明責任を果たすための技術です。チームが大きくなればなるほど、個人の勘や経験だけでは持ちません。誰か一人が「たぶん大丈夫」と感じるのではなく、構造として大丈夫である必要があります。

そのために必要なのは、次のような姿勢です。

• 状態は意味ごとに分ける
• 派生値はできるだけ宣言的に表現する
• 課金が発生する操作を可視化する
• 重い処理に上限やキャッシュ戦略を持たせる
• 変更が広がる経路を減らす

これらは別々のベストプラクティスに見えますが、根底では同じ原理です。見えない増殖を、見える構造に変えることです。

---

Key Takeaways

1. 便利さは最初の摩擦を減らすが、増殖のコストは別に発生する

   • 書きやすさだけで選ばず、100回目の変更に耐えるかを考える。

2. 派生状態の設計は、再計算コストの設計でもある

   • 毎回計算する必要があるか、キャッシュできるか、局所化できるかを確認する。

3. 状態を減らすより、可変性の半径を縮めることが重要

   • 1つの変更がどこまで波及するかを意識して、依存の連鎖を短くする。

4. コストは機能の後ろに隠れたシステム設計の成績表である

   • 請求の増え方を見れば、設計の無駄な再実行や過剰な連鎖が見えてくる。

5. 予測可能性は、チーム規模が大きいほど価値が増す

   • 「たぶん大丈夫」ではなく、構造的に大丈夫な状態を目指す。

---

設計の上手さは、増えたときに現れる

私たちはしばしば、良い設計を「分かりやすいこと」だと勘違いします。もちろん分かりやすさは重要です。しかし本当に優れた設計とは、分かりやすいだけでなく、増えたときに振る舞いが破綻しないことです。状態が増えても追える。トラフィックが増えても怖くない。変更のたびに関係ない部分まで揺れない。

ここに、Jotai のような原子的な状態設計と、Vercel のコストコントロールが共有する深い教訓があります。どちらも、単に小さく始めるための道具ではありません。むしろ、成長しても単純さを失わないための道具です。

そしてその単純さとは、何も「機能が少ない」という意味ではありません。必要な複雑さは受け入れつつ、不要な複雑さが勝手に増殖しないように抑えることです。言い換えれば、優れた設計とは複雑さをなくすことではなく、複雑さの発生源を管理することなのです。

次に状態を追加するとき、次にクラウド機能を有効にするとき、問いはこう変わるべきです。

これは便利か、ではなく。これは増えた後も、まだ制御できるか。

その問いを持てるチームだけが、成長の途中で速度を失わず、請求にも怯えず、コードにも溺れない。増殖を設計できる組織だけが、真にスケールできるのです。