Disposability

生成AI時代になると、捨てたい対象はプロセスやサーバではなく、エージェントが大量に書き換えるコードとデータそのものになる。Feature Flag、ドメインモデル、永続表現、イベント。これらを差分として安全に捨てられる構造にしておかないと、書く速度に対して捨てる速度が追いつかず、使われない分岐と旧モデルがコードベースに残り続ける。

Disposabilityの分類

プロセス・インスタンスのDisposability

アーキテクチャの Disposability

「全体を捨てる前提で作る」という設計戦略

機能のDisposability

最も粒度の細かい層。Feature Flag を入口に、ドメインモデル・永続表現・イベント・観測コードを差分として捨てられるように設計する。

共通する原則

呼称が違っても、これらの議論には粒度を超えて繰り返し現れる設計条件がある。

境界での再構築可能性

Phoenix / Immutable Server、Kubernetes Pod、Sacrificial Architecture、Branch by Abstraction はいずれも、中身を保持せず外から作り直せる単位を境界として切る、という同じことを別粒度で言っている。

状態の外部化

12-Factor の状態を持たないプロセス、Heroku の永続化されないファイルシステム、後段で扱う永続化境界での解釈の遅延、いずれも生き残らせたい状態を外に追い出す構造になっている。

起動と停止の対称性

12-Factor が要求する速い起動と片付けのある停止、Erlang プロセスの軽量さ、Lambda の cold start (起動時の遅延) が性能に直結すること、これらは入口と出口が対称に速くないと捨てるという選択そのものが採れない、という同じ要請を別の場所で受けている。

Candea & Fox の Crash-Only、Armstrong の Let it crash、Chaos Monkey による事前破壊が共通して採るのは、起動と回復を同じパスに重ねる単純化で、止め方と回復経路を別々に検証する必要をなくすための処方になっている。

書き戻しの非対称性

Event Sourcing の upcasting、後方互換 API、後段で扱う永続化境界のバージョン付き解釈は、いずれも読み込みでは過去互換を許容し、書き込みは現在形で行う、という入出力の非対称性を採る。

削除可能性

Parnas 1979 が縮小 (contraction) を拡張 (extension) と並べたように、削除を拡張と同じ重みで設計対象にする。使われなくなった flag の片付けの議論も、削除を後回しにすると設計が壊れることを別の角度から示している。

合成可能性

Branch by Abstraction、Parallel Change、Composable Domain Model、合成可能なデコーダーは、丸ごとコピーして並走させる代わりに、変化点だけを差し替え可能な部品として切り出す。捨てる単位を機能全体ではなく差分そのものに揃えるための条件で、これがないと「いずれ捨てる」と書かれた塊が捨てられないまま残る。

粒度ごとに支配的になる条件は違う。プロセスやサーバでは境界での再構築可能性と起動・停止の対称性が運用の成否を決める。機能差分の層では、合成可能性・状態の外部化・書き戻しの非対称性・削除可能性の四つが支配的になる。

機能のDisposabilityの設計

プロセスやサーバの Disposability は、コンテナランタイムやオーケストレータが大部分を引き受けてくれる。アプリ側で考えることは、SIGTERM を受けたら進行中の処理を片付けて止まる、ローカルファイルを当てにしない、起動を速くする、くらいに限られる。

機能のDisposabilityにはそういう肩代わりがない。Feature Flag を一つ足すと、ドメインモデルにも、入力や DB レコードの読み方にも、保存形式にも、イベントの形にも、メトリクスやログにも、複数の実装が並ぶことになる。Feature Flag の使い方や、使われなくなったフラグの削除は個別には語られているが、これらを「ひとまとまりの差分」として捨てやすい設計は、あまり語られていない。

定義

機能のDisposabilityを以下のように定義する。

機能のDisposabilityとは、ある機能差分を導入・検証・段階展開・固定・削除する過程で、不要になった実装部品、モデル部品、入出力解釈、永続表現、フラグ、メトリクスを安全に廃棄できること。

廃棄単位を「機能全体」と取ると粒度が粗すぎる。実際に捨てる対象はより細かい。

捨てる単位を細かく取ろうにも、実際には難しいことが多い。例として注文ドメインを取る。v1 の Order は、注文者と明細と、配送先住所と、請求書払いを前提とした請求情報からなる。v2 ではここに二つの変更が入る。配送先は単一住所ではなく、店頭受け取りや分割配送を含む受取計画として扱う。請求は請求書払いだけでなく、クレジットカードや口座振替を含む請求プロファイルとして扱う。注文の ID・注文者・明細・金額・数量といった残りの部分は v1 と v2 で同じである。

ドメインモデルがない実装では、Order が一枚岩のクラスとして定義され、配送先や請求情報は Order のフィールドとして直接定義される。v1 から v2 への変更は、Order に新しいフィールドを足し、boolean フラグや null 判定で v1/v2 の挙動を切り替える形で入る。

code: (java)

class Order {

OrderId id;

Buyer buyer;

List<OrderItem> items;

// v1: 配送先住所

String shippingPostalCode;

String shippingAddress;

// v2: 受取計画

boolean useFulfillmentPlan;

String fulfillmentKind; // "delivery" / "store_pickup" / "split"

List<DeliverySlot> slots;

// v1: 請求書払い

String invoiceCompanyName;

String invoiceTaxId;

// v2: 請求プロファイル

boolean useBillingProfile;

String paymentMethodKind; // "credit_card" / "bank_transfer" / "invoice"

String paymentMethodToken;

}

Orderをv1用とは別に、v2用を作ることも考えられる。

code: (java)

class Order {

String id;

String buyerId;

List<OrderItemRow> items;

String shippingPostalCode;

String shippingAddress;

String invoiceCompanyName;

String invoiceTaxId;

}

class OrderV2 {

String id;

String buyerId;

List<OrderItemRow> items;

String fulfillmentKind;

List<DeliverySlotRow> slots;

String paymentMethodKind;

String paymentMethodToken;

}

ここから先は、こうした丸ごとコピーをどう合成可能な形に組み替えるか、ドメインモデル・振る舞い・入出力境界・永続表現を順に見ていく。

Composable Domain Model

コピーではなく合成として書くには、その前に「v1でもv2でも同じでなければならないデータと振る舞い」と「変化する軸」を見分けておく必要がある。これを格納する場所がドメインモデルになる。コピーから始めるとこの分離が後回しになり、共通部品の差分が偶然のコピー差なのか本質的な差なのかを後から復元することは難しい。

注文ドメインで言えば、Order を「ID と注文者と明細と Fulfillment と Billing から組み立てたもの」として書き、Fulfillment や Billing をそれぞれ独立した型として扱う。すると結果として変化しない部分 (OrderId、Buyer、OrderItem、Money、Quantity) と、変化する部分 (Fulfillment、Billing) が分離して見えてくる。

code: (text)

変化しない部分:

OrderId, Buyer, OrderItem, Money, Quantity

変化する部分:

Fulfillment

- ShippingAddressFulfillment

- FulfillmentPlan (Delivery / StorePickup / SplitDelivery)

Billing

- LegacyBilling

- BillingProfile

この分離は事前に「ここは変わる、ここは変わらない」と決めて切り出すのではなく、合成として書くことで現れる。変化する部分は型パラメータや sealed interface として差し替え可能になる。

code: (java)

record Order<F extends Fulfillment, B extends Billing>(

OrderId id,

Buyer buyer,

List<OrderItem> items,

F fulfillment,

B billing

) {}

ただし、コピーを避けたいからといって、意味の違う概念を無理に共通の上位型に押し込んではならない。

table:table

状況 設計

一方の概念がもう一方の特殊ケース 共通の上位型にできる

不変条件が異なる 別のモデル部品として分ける

入力形式だけが違う 入力解釈の境界だけ分ける

ユースケースの流れが違う ユースケースを別部品に分ける

永続表現だけが違う DB との読み書きの境界だけ分ける

ここを誤ると「コピーしない」ことが目的化し、Optional と boolean フラグだらけのドメインモデルが生まれる。合成可能に分けること自体ではなく、変化点を意味的に切り出すことが本来の作業である。

code: (java)

// 共通: variant に依らない

public class CalculateTotal

implements Function<Order<? extends Fulfillment, ? extends Billing>, Result<Money>> {

public Result<Money> apply(Order<? extends Fulfillment, ? extends Billing> order) { ... }

}

public class CheckInventory<F extends Fulfillment, B extends Billing>

implements Function<Order<F, B>, Result<Order<F, B>>> {

public CheckInventory(InventoryGateway inventory) { ... }

public Result<Order<F, B>> apply(Order<F, B> order) { ... }

}

code: (java)

public class IssueFulfillmentInstruction

implements Function<FulfillmentPlan, Result<FulfillmentInstruction>> {

public Result<FulfillmentInstruction> apply(FulfillmentPlan plan) {

return switch (plan) {

case Delivery d -> Result.ok(new ShippingInstruction(...));

case StorePickup s -> Result.ok(new StorePickupInstruction(...));

case SplitDelivery s -> Result.ok(new SplitInstruction(...));

};

}

}

code: (java)

public Result<PlacedOrder> apply(Order<F, B> order) {

return checkInventory.apply(order).flatMap(checked ->

calculateTotal.apply(checked).flatMap(total ->

issueInstruction.apply(checked.fulfillment()).flatMap(instruction ->

charge.apply(checked.billing(), total).map(receipt ->

new PlacedOrder(checked.id(), instruction, receipt)))));

}

Composable Decoder と Compatibility Decoder

code: (text)

OrderDecoder =

orderIdDecoder

+ buyerDecoder

+ itemListDecoder

+ fulfillmentDecoder

+ billingDecoder

これを互換デコーダーと呼ぶ。

code: (java)

JsonDecoder<FulfillmentPlan> legacyShippingAddressAsFulfillmentPlan =

combine(

field("postal_code", string()),

field("address", string())

).map(LegacyShippingAddress::new)

.map(FulfillmentPlan::fromLegacyShippingAddress);

code: (java)

import static net.unit8.raoh.json.JsonDecoders.*;

JsonDecoder<Order<FulfillmentPlan, LegacyBilling>> orderV1Decoder =

combine(

field("id", orderIdDecoder),

field("buyer", buyerDecoder),

field("items", list(orderItemDecoder)),

field("fulfillment", legacyShippingAddressAsFulfillmentPlan),

field("billing", legacyBillingDecoder)

).map(Order::new);

JsonDecoder<Order<FulfillmentPlan, BillingProfile>> orderV2Decoder =

combine(

field("id", orderIdDecoder),

field("buyer", buyerDecoder),

field("items", list(orderItemDecoder)),

field("fulfillment", fulfillmentPlanDecoder),

field("billing", billingProfileDecoder)

).map(Order::new);

Versioned DB Decoder と Schema-on-Read 境界

ドメインモデルの変更はデコーダーだけでは閉じない。永続化されたデータも別の表現で残っている。通常はこうなる。

code: (text)

DB の行 ─ ORM/Mapper ─ 現在のドメインモデル

この直結だと、ドメインモデルが変わるたびに DB スキーマも現在形に揃えたくなり、既存データの一括 UPDATE が必要になる。これが Feature Flag による段階デプロイや切り戻しと衝突する。コードは新旧を切り替えられても、データを一度変換すると旧コードが読めなくなるからである。

代替は、DB の行を「バージョン付き永続表現」として扱うことだ。

code: (text)

DB の行 + representation_version

↓

バージョン別の DB decoder

↓

現在のドメインモデル

code: (sql)

ALTER TABLE orders

ADD COLUMN representation_version integer NOT NULL DEFAULT 1;

code: (java)

import org.jooq.Record;

import static net.unit8.raoh.decode.Decoders.discriminate;

import static net.unit8.raoh.decode.ObjectDecoders.int_;

import static net.unit8.raoh.jooq.JooqRecordDecoders.field;

Decoder<Record, Order<Fulfillment, Billing>> orderRowDecoder = discriminate(

"representation_version",

field("representation_version", int_()).map(String::valueOf),

Map.of(

"1", orderRowDecoderV1ToCurrent,

"2", orderRowDecoderV2ToCurrent,

"3", orderRowDecoderV3

));

書き込みはエンコーダー側を現在形に固定する。

code: (java)

import static net.unit8.raoh.encode.MapEncoders.*;

import static net.unit8.raoh.encode.ObjectEncoders.*;

Encoder<Order<? extends Fulfillment, ? extends Billing>, Map<String, Object>> orderRowEncoder = object(

property("representation_version", o -> 3, int_()),

property("id", Order::id, orderIdEncoder),

property("buyer", Order::buyer, buyerEncoder),

property("fulfillment", Order::fulfillment, fulfillmentPlanEncoder),

property("billing", Order::billing, billingProfileEncoder)

);

同型の設計はいくつかの文脈で別名で呼ばれている。RDB の行を対象にした正面からの呼び名は定着していないが、それぞれの層で同じ非対称性が再発見されている。

v1/v2 という名前は何を表しているか

v 番号は本来「まだ意味を切り出せていない暫定ラベル」であって、合成可能に分解できた瞬間にその役目を終える。

Event Upcasting / Message Schema Evolution

DB と同型の議論は Event Sourcing にも当てはまる。過去のイベントは不変なので書き換えられない。代わりに、読み出し時に upcaster が新しい形式へ変換する。

code: (text)

旧イベント ─ upcaster ─ 現在のイベント / 現在のドメインコマンド

イベント駆動の機能で Disposability を保つには、イベントのスキーマバージョン、イベントの読み出しと upcaster、読みモデルの構築、現在のドメインモデル、コンシューマ側との互換性、これらを分離する必要がある。upcaster は DB の decoder と同型で、「旧イベントが残ること」と「旧ドメインモデルが残ること」は同じではない。

DB の行、API の入力、イベントはいずれも「バージョン付き外部表現」として同じ枠組みで扱える。decoder と upcaster を境界に置くことで、外部表現の寿命とドメインモデルの寿命を分離する。

ここまでで、機能差分を構造的に捨てられる形に分解する話を扱った。残りは何を根拠にいつ捨てるかという判断側の話で、影実行 (Shadow Execution)、variant の型化、使われなくなった flag の片付けの順に見ていく。

Progressive Delivery と Shadow Execution

機能を捨てやすくするには、公開前に「捨てる判断」ができる必要がある。dark launch / shadow traffic は、本番のリクエストを新バージョンへコピーし、レスポンスをユーザーへ返さず正しさ・遅延・コストを観測する技法として知られている。

code: (text)

本番経路: リクエスト → v1 → レスポンス

影経路: リクエストの複製 → v2 → 差分 / メトリクス / ログ (返さない)

この構造により、v2 を本番負荷で検証し、結果が不味ければ v2 のドメイン部品を捨てられる。影実行は安全な段階展開のための技法であると同時に、廃棄判断のための観測技法でもある。捨てる根拠をデータとして集めるのが目的で、観測のためのコード自体も使い捨てに保つ必要がある (本番運用に影経路を残し続けると、それ自体が負債になる)。

Variant の型化

ここで boolean のまま渡さず、許される variant を sealed interface で型として表現する。

code: (java)

sealed interface CheckoutVariant

permits LegacyCheckout,

NewFulfillmentCheckout,

FullCheckoutV2 {}

variant 同士の制約も明示できる。

code: (text)

NewCoupon requires NewCheckout

LegacyInvoice excludes NewBilling

Disposability を壊すのは flag の数そのものではなく、意味づけされていない組合せである。flag を管理するのではなく、許される variant を設計する、という方向に持っていくことで、捨てる単位が「有効な variant の差分」として現れる。

使われなくなった flag を片付ける

code: (text)

flag: checkout_fulfillment_v2

所有するもの:

- 旧 shipping_address の読み出し

- 旧 ShippingAddress の decoder

- v1 永続表現の DB decoder

- 段階展開中の差分計測

- fulfillment_v1 のカラム

- v1 イベントの upcaster

削除条件:

- representation_version=1 の行が 0 件

- 旧入力形式での流入が 30 日間 0 件

- 影経路の差分が閾値以下

- すべてのコンシューマ側が v2 に対応済み

ここまでメタデータ化されて、flag が何を所有し、何が満たされたら削除してよいかが、ようやく flag 宣言と同じリポジトリに書ける状態になる。

Disposable と呼ばれているが捨てられないもの

捨てるための外形は整っているのに、実際には捨てられない設計の例を並べる。共通する原則の節で機能差分の層で支配的だと挙げた四条件 (合成可能性、状態の外部化、書き戻しの非対称性、削除可能性) のどれかが欠けていることが、捨てられない直接の原因になっている。

v1/v2 の丸ごと並走

欠けている前提: 合成可能性 (変化点が意味として切り出されていない)。

状態を持った「使い捨て Pod」

欠けている前提: 状態の外部化 (生き残らせたい状態を Pod の中に持っている)。

永続化された Feature Flag

Feature Flag は本来、機能差分を流動的に切り替えるための一時的な装置である。しかし実証研究の数値が示す通り、削除は追加に系統的に遅れる。Kubernetes で中央値 734 日、GitLab で 185 日という生存期間は、flag の半数以上が「短期に消す」予定通りには消えていないことを示す。flag を入れた瞬間に「この flag はいつ何が満たされたら削除する」という条件をセットでコード化しなければ、flag は恒久的な分岐に変質する。

欠けている前提: 削除可能性 (削除条件がメタデータ化されていない)。

データを一括変換しないと動かないマイグレーション

新コードがデプロイされた瞬間に旧データを全変換しなければ動かない設計は、切り戻しの経路を持たない。コードは使い捨てに切り替えられても、データは使い捨てではなくなる。途中失敗の整合性、ロックの長期保持、旧コードとの互換性喪失、いずれも「捨てる」ための前提を壊す。

欠けている前提: 書き戻しの非対称性 (読み込みは過去互換、書き込みは現在形、という分担を採っていない)。

Disposability の落とし穴

前節は Disposable と誤認される設計を扱った。ここでは、Disposability を正しく追求しているつもりでも踏みやすい落とし穴を3つ挙げる。合成可能性・バージョン付き解釈・削除条件のいずれも、入れた瞬間にコストが発生する。捨てるために入れた境界・メタデータ・観測コードがそのまま残ると、それ自体が新しい負債になる。

投機的な Disposability

退却可能性とのトレードオフ

Sacrificial の言い訳化

Fowler 自身が SacrificialArchitecture で警告した通り、「どうせ捨てるから」は内部品質を犠牲にする言い訳にはならない。捨てる経路を保つには、捨てるまでの間に共通部品の修正が両側に伝播しないこと、削除条件が満たされたかを観測できること、片付け作業が機械化されていることが要る。Composable Domain Model・representation_version・Piranha 的なメタデータ化は、すべて「捨てる前提だから雑に書いてよい」と両立しない。Disposable に作るというのは「いずれ捨てる」と言うこととは違って、捨てる経路を保ったまま現在の作業ができる状態を維持することを指す。