DJBとセキュリティ・バイ・コンストラクション：qmailからCurve25519へ

専門用語抜きに言う「セキュリティ・バイ・コンストラクション」

セキュリティ・バイ・コンストラクションは、よくあるミスを犯しにくくし、不可避なミスが起きても被害を限定するようにシステムを構築することを意味します。長いチェックリスト（「Xを検証、Yをサニタイズ、Zを設定…」）に頼るのではなく、安全な道筋が最も簡単な道筋になるようにソフトウェアを設計します。

子供用の安全包装を考えてみてください。すべての人が完璧に注意深いとは想定せず、疲れていたり多忙であったり時に間違う人間を前提に設計します。良い設計は開発者、運用者、利用者に求める「完璧さ」を減らします。

なぜシンプルさがリスクを下げるのか

セキュリティの問題はしばしば複雑さの中に隠れています：機能が多すぎる、オプションが多すぎる、コンポーネント間の相互作用が多すぎる。余計なノブは新たな故障モードを生み出します — システムが壊れたり誤用されたりする予期しない経路です。

シンプルさは次の2つの実利をもたらします：

• 監査対象のコードが少ない：分岐が少ない、特別対応が少ない、隠れた振る舞いが少ない。
• 誤設定の余地が少ない：10個の「柔軟」選択肢の代わりに一つの安全なデフォルトがあれば、偶発的な不安全性の余地が減る。

これは単なるミニマリズムではありません。振る舞いの集合を理解、テスト、問題発生時の推論が可能なほど小さく保つことです。

本稿が扱うもの（扱わないもの）

本稿は Daniel J. Bernstein の仕事を、セキュリティ・バイ・コンストラクションの具体例として使います：qmail がどのように故障モードを減らしたか、定数時間の考え方がどう見えない情報漏えいを防ぐか、Curve25519/X25519 と NaCl が誤用しにくい暗号にどう寄与するかを示します。

扱わないこと：暗号史の全体、アルゴリズムの正当性証明、すべてのケースで「最高の」ライブラリの提示。良いプリミティブがすべてを解決するわけではなく、現実のシステムは鍵の取り扱い、統合ミス、運用上の穴で失敗することを否定しません。

目標は単純です：暗号専門家でなくても、安全な結果が出やすい設計パターンを示すことです。

Daniel J. Bernstein（DJB）とは誰で、なぜ引用されるか

Daniel J. Bernstein（しばしば「DJB」）は数学者であり計算機科学者で、実務的なセキュリティ工学界隈で繰り返し参照される仕事を残しています：メールシステム（qmail）、暗号プリミティブやプロトコル（特に Curve25519/X25519）、実用向けに暗号をまとめたライブラリ（NaCl）などです。

人々が DJB を引用するのは、彼が唯一の「正しい」やり方を書いたからではなく、彼のプロジェクト群が一貫したエンジニアリング的直感を共有しており、それが「問題が起きる経路の数」を減らすからです。

エンジニアが DJB 流から借りるもの

再現するテーマは より小さく、より厳しいインターフェース です。システムが少ない入口点と少ない設定を公開すれば、レビューしやすく、テストしやすく、誤用しにくくなります。

もう一つは 明示的な想定 です。セキュリティの失敗はしばしばランダム性やタイミング挙動、エラーハンドリング、鍵の保管方法などについての暗黙の期待から生じます。DJB の文章や実装は脅威モデルを具体化する傾向があり：「何を守るのか、誰から、どんな条件で」を明確にします。

最後に、安全なデフォルト と 退屈な正しさ（boring correctness） への志向があります。曖昧なパラメータ、オプションモード、情報を漏らす性能最適化といった“鋭い角”を排する設計が多いのも特徴です。

伝記ではなく工学的視点としての読み物

本稿は人物の伝記や人格論争ではなく工学的な読み物です：qmail、定数時間の考え方、Curve25519/X25519、NaCl に見られるパターンと、それらがどのように検証しやすく本番で脆弱になりにくいシステムに結びつくかを示します。

qmail：故障モードを減らす実践例

qmail はとても地味な問題を解くために作られました：メールを確実に配達しつつ、メールサーバを高価値な標的として扱うこと。メールシステムはインターネット上にあり、日中ずっと敵対的な入力を受け、機密データ（メッセージ、認証情報、ルーティング規則）を扱います。歴史的に単一のモノリシックなメールデーモンのバグ一つでシステム全体が乗っ取られたり、誰も気付かないままメッセージが静かに失われたりしました。

仕事を分割して被害範囲を縮める

qmail の決定的なアイデアは「メール配信」を小さなプログラムに分けることでした：受信、キューイング、ローカル配信、リモート配信など。各部分は狭いインターフェースと限定された責務を持ちます。

この分離が重要なのは、故障が局所化されるからです：

• あるコンポーネントがクラッシュしても、キューが自動的に破損したりシステム全体が落ちたりしにくい。
• あるコンポーネントにセキュリティバグがあっても、攻撃者が即座に他の全ての権限を得るわけではない。
• 単体でコンポーネントを推論できれば、テストや監査がより効果的に行える。

これは実践的なセキュリティ・バイ・コンストラクションです：「1つのミス」が「全滅」になりにくいように設計すること。

真似する価値のある設計習慣

qmail はメール以外でも役立つ習慣を示しています：

• 明確な境界：コンポーネントが受け入れる入力と生成する出力を正確に定義する。小さく明示的な契約は強制しやすい。
• 厳格な入力処理：ネットワーク由来のすべてを潜在的に悪意あるものとして扱う。早期に検証し、異常を拒否し、「親切な」推測を避ける。
• 最小権限のデフォルト：コンポーネントは必要な権限だけで動かす。バグがあっても全権限取得に直結しないようにする。

教訓は「qmail を使え」ということではありません。コードを書いたりノブを増やす前に、故障モードを減らすように再設計することで大きなセキュリティ向上が得られる、ということです。

タイトなインターフェースで攻撃面を減らす

「攻撃面（attack surface）」は、システムが突かれたりだましたりして誤動作する可能性のあるすべての箇所の総和です。家の比喩で言えば、ドア、窓、ガレージの開閉、予備の鍵、配達口などがすべて侵入点になります。より良い鍵をつけることもできますが、侵入点をそもそも少なくする方が安全です。

ソフトウェアも同様です。開けるポート、受け入れるファイル形式、公開管理エンドポイント、追加する設定ノブ、サポートするプラグインフックはすべて失敗の余地を増やします。

タイトなインターフェース：小さい API、少ない故障モード

「タイトなインターフェース」はやることが少なく、受け入れる変動が少なく、不明瞭な入力を拒否する API です。制約が厳しく感じられることもありますが、監査すべきコードパスが少なく、驚きのある相互作用が減るため安全にしやすいです。

二つの設計を比較してみましょう：

• ワイドなインターフェース："任意のファイルタイプをアップロード、フォーマットを検出します、任意圧縮、任意暗号化、任意メタデータ、複数の認証方式"。
• タイトなインターフェース："バイトをアップロード、コンテンツタイプは小さなホワイトリストから宣言、最大サイズ固定、暗号化は内部で処理、認証方式は一つ"。

後者は攻撃者が操作できる要素を減らしますし、チームが誤設定する余地も減ります。

なぜ選択肢が少ない方が安全か

選択肢はテストを増やします。10個のトグルをサポートするなら、10個の振る舞いではなく組み合わせが生まれます。多くのセキュリティバグはその「継ぎ目」に潜みます：「このフラグでチェックが無効になる」「このモードで検証がスキップされる」「古い設定がレート制限を回避する」など。タイトなインターフェースは「選択肢だらけのセキュリティ」ではなく一つの明るい道を作ります。

チェックリスト：複雑さが潜む場所

攻撃面が静かに増えていないか見つけるポイント：

• 多様な入力タイプ：複数ファイル形式、エンコーディング、"自動検出"の解析。
• 入り口が多すぎる：追加のネットワークポート、管理パネル、デバッグエンドポイント、Webhook。
• セキュリティロジックを変える機能フラグ：検証、認証、暗号の挙動を変えるトグル。
• プラグイン性：実行時に評価されるスクリプト、テンプレート、プラグイン、カスタム式。
• 後方互換モード：レガシープロトコル、古い暗号、廃止された API バージョン。
• 暗黙のデフォルト：環境変数や設定漏れで振る舞いが変わる。

インターフェースを縮められないときは、厳格にしてください：早期に検証し、不明フィールドは拒否し、「強力な機能」は別の明確にスコープされた経路に置きます。

定数時間の思考：見えない漏えいを防ぐ

「定数時間」の挙動とは、秘密値（秘密鍵やノンス、途中のビットなど）に依存せず計算時間が（概ね）同じになることを目指すことです。目的は速さではなく「退屈さ」です：攻撃者が実行時間と秘密を相関できなければ、観測による秘密抽出がはるかに難しくなります。

タイミング漏えいは重要です。攻撃者が同じ操作を何度も実行できたり、共有ハードウェア上で実行を観察できたりすると、マイクロ秒、ナノ秒、あるいはキャッシュ効果のような微小な差が蓄積して鍵回復につながることがあります。

タイミング変化が忍び込む場所

普通のコードでもデータによって挙動が変わり得ます：

• 秘密データに基づく分岐：if (secret_bit) { ... } のような制御フローがランタイムを変える。
• 秘密でインデックスされるテーブル参照：秘密依存のインデックスが異なるキャッシュラインを引く古典的な例。
• キャッシュやメモリ効果：秘密に依存するメモリアクセスパターンが CPU キャッシュ、ページフォールト、プリフェッチで漏れる。
• 可変時間命令：大数演算の一部、除算、早期終了するループなどは入力によって時間が変わることがある。

タイミングリスクを監査する高レベルな方法

アセンブリを読む必要はありません。監査で有効な手順：

1. 秘密の影響を追う：どの変数が秘密か（秘密鍵、共有秘密、認証タグ）を列挙し、それらがどこに流れているかを追跡する。
2. 赤旗を探す：秘密依存の if、配列インデックス、秘密で終了するループ、"高速経路/遅延経路" ロジック。
3. 依存関係を脅威モデルに含める：利用する暗号ライブラリが該当操作について定数時間を明言しているか確認する。
4. 分散をテストする：異なる秘密で多数回動作を実行し、時間分布を測る。大きく一貫した差があるなら警告。

定数時間の思考はヒーロー的な作業ではなく規律です：秘密がタイミングを左右できないようにコードを設計します。

Curve25519 と X25519：誤用しにくさを目指した暗号

楕円曲線鍵交換は、二者がネットワーク上で「公開」値だけをやり取りしても同じ共有秘密を作れる仕組みです。各側は秘密値（秘密）と対応する公開値（送って良いもの）を生成します。公開値を交換した後、双方が自分の秘密値と相手の公開値を組み合わせて同一の共有秘密に到達します。盗聴者は公開値を見るだけで共有秘密を復元できないため、双方はそこから暗号鍵を導出して秘密裏に通信できます。

Curve25519/X25519 が普及した理由

Curve25519 は基盤となる曲線で、X25519 はその上で「これをこうやる」と標準化された鍵交換関数です。魅力は主にセキュリティ・バイ・コンストラクションにあります：踏み外しに繋がる選択肢が少ない、パラメータ選択が少ない、誤った設定をしてしまう余地が少ない。

また広いハードウェアで高速であり、サーバで多数接続をさばく場合やバッテリを節約したい携帯端末で重要です。さらに実装が定数時間にしやすい設計を促すため（タイミング攻撃への抵抗が高まり）、微小な性能差によって秘密が抜かれるリスクを減らせます。

X25519 が提供するものと提供しないもの

X25519 は 鍵合意（key agreement） を与えます：二者が共有秘密を導出するのに役立ちます。

それは単体では認証を提供しません。X25519 を認証なしで使うと（例：証明書や署名、事前共有鍵無しで）誤った相手と安全に通信してしまう可能性があります。言い換えれば：X25519 は盗聴を防ぐのに役立ちますが、単独ではなりすましを止められません。

NaCl の大きな考え方：選択肢を減らしてミスを減らす

NaCl（Networking and Cryptography library）は、アプリケーション開発者が誤って不安全な暗号を組み立ててしまうのを難しくすることを目的に作られました。アルゴリズムやモード、パディングルール、設定ノブのビュッフェを提供する代わりに、安全に組み合わさった少数の高レベル操作へ誘導します。

box と secretbox：安全な構成要素として

NaCl の API は「どのプリミティブを繋ぐか」ではなく「何をしたいか」で名付けられています。

• crypto_box（box）：公開鍵認証付き暗号化。自分の秘密鍵、受信者の公開鍵、ノンス、メッセージを渡すと、（a）メッセージが隠され、（b）正しい鍵を知る者から来たことを示す暗号文が得られます。
• crypto_secretbox（secretbox）：共有鍵による認証付き暗号化。同じ考え方ですが、単一の共有秘密鍵を使います。

主な利点は、暗号化モードや MAC アルゴリズムを個別に選んで正しく組み合わせたかを期待する必要がない点です。NaCl のデフォルトは現代的で誤用に強い組み合わせ（encrypt-then-authenticate 等）を強制するため、完全性チェックを忘れるような一般的な失敗を大幅に減らせます。

トレードオフ：選択肢の少なさ vs 柔軟性

NaCl の厳格さは、レガシープロトコルや特殊なフォーマット、規制で指定されたアルゴリズムとの互換性が必要な場合には制約に感じることがあります。すべてのパラメータを調整できる自由を「暗号専門家でなくても安全に出荷できる」ことと交換するわけです。

多くの製品ではこれがポイントです：設計空間を制約し、バグの数をそもそも減らす。もし本当にカスタマイズが必要なら、低レベルのプリミティブに降りることはできますが、それは鋭い角（危険）に自分で戻ることを意味します。

安全なデフォルトとノブが多すぎるコスト

「安全なデフォルト」とは、何もしない状態で最も妥当で安全な選択肢が選ばれることを意味します。開発者がライブラリをインストールし、クイックサンプルをコピペし、フレームワークのデフォルトで動かす場合、その結果が誤用しにくく弱体化しにくいものであるべきです。

デフォルトは重要です。現実の大多数のシステムはデフォルトで動きます。チームは急ぎ、ドキュメントは斜め読みされ、設定は有機的に増えます。デフォルトが「柔軟」だと、それはしばしば「誤設定しやすい」ことに繋がります。

デフォルトが静かにリスクを生む方法

暗号の失敗は必ずしも「数学が間違っていた」から起きるわけではありません。危険な設定を選んでしまったことが原因であることが多いです。

一般的なデフォルトの罠：

• 弱いまたは予測可能な乱数：非暗号学的 PRNG の使用、シード再利用、コンテナ／VM 内で低エントロピソースにフォールバック。鍵生成が不十分な乱数に依存すると、それに基づくすべてが弱くなる。
• 互換性のために残した古いアルゴリズム：SHA-1, MD5, 古い RSA サイズを「念のため」有効にしておくと、本番で交渉されて使われてしまうことがある。
• カスタムや珍しいモード・パラメータ：ブロック暗号モード、パディング、ノンス取り扱い、自作スキームに多くのノブを与える。選択肢が増えるほど「見た目は暗号化されているが安全でない」プロトコルを偶然作る可能性が増える。

実践的ルール：選択肢を減らして安全に

安全な道筋を最も簡単にするスタックを好みます：精査されたプリミティブ、保守的なパラメータ、脆弱な決定をユーザに委ねない API。ライブラリが 10 のアルゴリズム、5 のモード、複数のエンコーディングの中から選ばせるようなら、それは設定でセキュリティ設計をやらせているのと同じです。

可能なときは：

• 現代的で広くレビューされたアルゴリズムをデフォルトにする
• 廃止されたオプションは「詳細設定」に隠すのではなく削除する
• 危険な操作を不可能にするか、少なくとも明確に痛みを伴う手順にする

セキュリティ・バイ・コンストラクションは、すべての決定をドロップダウンにしないことでもあります。

実際のコードで「シンプルで検証可能」とはどう見えるか

「検証可能（verifiable）」は多くのプロダクトチームで「形式的に証明済み」を意味しません。素早く、繰り返し、自信を構築でき、コードの振る舞いを誤解しにくいことを意味します。

実務上の「検証可能」であることの定義

コードベースが検証可能になりやすい条件：

• 可読性が高い：小さな関数、明確な命名、最小限の「魔法」。新しいエンジニアがフローをホワイトボードなしで説明できる。
• 既知の正しいテストベクタがある：入力が与えられれば出力が決まっている（暗号では特に重要）。これにより偶発的な変更が見つけやすくなる。
• ビルドが再現可能：同じソースから同じバイナリが得られるので、レビューしたものと実行中のものが一致することを確認できる。
• 監査が実行可能：安価ではないが境界がある—監査人が重要経路をオーバーヘッドなくカバーできる。

なぜシンプルなコードパスはレビューしやすいか

分岐やモード、オプション機能はレビューすべき状態を指数的に増やします。単純なインターフェースは可能な状態数を狭めるため、レビュー品質を2つの方法で改善します：

1. レビュー担当者はセキュリティに重要な少数のフローに集中できる。
2. 予期しない振る舞い（危険な割り当て、リスキーなパース、タイミングに敏感な比較）を発見しやすくなる。

採用できる軽量な検証ワークフロー

面倒を減らして繰り返し可能に：

• テスト：ユニットテストに加え、使うプリミティブごとに既知解（known-answer）テストを追加し、すべての変更で CI にかける。
• レビュー：鍵、乱数、シリアライゼーション、比較に触れる変更にはセキュリティチェックリストを必須にする。
• 監視：失敗理由は高レベルでログ（秘密は出さない）、復号／検証失敗のスパイクにアラート、依存関係のバージョン追跡で暗号コードの変化を把握する。

これらは専門家レビューの代替ではありませんが、下限を引き上げます：驚きが少なく、検出が早く、推論可能なコードになります。

良いプリミティブを選んでもまだ壊れる場所

X25519 のような評価されたプリミティブや NaCl 型のミニマル API を選んでも、統合、エンコーディング、運用の雑多な部分でシステムは壊れます。実際の事例の多くは「数学が間違っていた」よりも「数学を使い間違えた」ことに由来します。

統合での落とし穴（よくある要因）

鍵取り扱いのミス：長期鍵を一時鍵として使ってしまう、鍵をソース管理に入れる、公開鍵と秘密鍵のバイト列を混同する（どちらもただの配列に見える）など。

ノンスの誤用 は再発する問題です。多くの認証付き暗号は鍵ごとにユニークなノンスを要求します。ノンスを重複させると（カウンタリセット、マルチプロセス競合、「十分ランダム」前提の失敗で）機密性や完全性を失う可能性があります。

エンコーディングとパース の問題は静かな失敗を生みます：base64 と hex の混同、先頭ゼロの消失、エンディアンの不一致、複数エンコーディングを受け入れて違う比較結果になる等。これらは「署名が検証された」が「別の何かが検証された」に変わる。

エラーハンドリング も両方向で危険です：攻撃者に役立つ詳細なエラーを返す、あるいは検証失敗を無視して続行してしまう。

運用上の落とし穴が良い暗号を台無しにする

秘密はログ、クラッシュレポート、アナリティクス、デバッグエンドポイントから漏れます。鍵はバックアップ、VM イメージ、広く共有された環境変数に残りがちです。一方、依存関係の更新管理（または未更新）は、設計が堅牢でも脆弱な実装に取り残されるリスクになります。

非暗号専門家向けの緩和チェックリスト

• ノンスを設計要件として扱う：一意性ルールを文書化し、再利用を検出するテストを追加する。
• 鍵／メッセージの正準エンコーディングを定義し、それ以外は拒否する。
• クローズドに失敗する：検証が失敗したら停止し、一般的なエラーを表出する。
• ログに秘密を残さない：自動ログ赤色化テストを追加する。
• 鍵は専用のシークレットマネージャに保管し、アクセスをスコープし回転する。
• 暗号依存をピン留めしてレビュー、アップデートと監査のスケジュールを設ける。

製品向けの暗号エンジニアリング方針の選び方

良いプリミティブを選べば製品が自動的に安全になるわけではありません。公開する選択肢が多いほど（モード、パディング、エンコーディング、カスタム調整）、チームが誤ってもろいものを作る経路が増えます。セキュリティ・バイ・コンストラクションのアプローチは、まず意思決定点を減らすエンジニアリング方針を選ぶことから始まります。

実用的な意思決定フレームワーク

高レベルライブラリ（ワンショット API：「このメッセージをあの受信者向けに暗号化」）を使うべき場面：

• チームが暗号専任ではない。
• ノンス管理、認証、鍵フォーマットなどの安全なデフォルトが必要。
• 組み合わせ用の「グルーコード」を減らしたい。

低レベルのプリミティブ（AEAD、ハッシュ、鍵交換）を組み合わせるのは次の場合：

• 明確なプロトコル仕様と相互運用要件がある。
• レビュー、テストベクタ、長期メンテナンスの所有権を割り当てられる。
• 既存のプロトコルを再発明していないことを証明できる。

ひとつの実用的なルール：設計書に「モードは後で決める」「ノンスは気をつける」と書かれているなら、既にノブが多すぎます。

ベンダーや社内チームに問うべきこと

具体的な回答を求めてください、マーケティング的表現ではなく：

• API 設計：API は不安全な状態を表現しにくくしているか？ノンスサイズや鍵サイズ、アルゴリズム選択は制約されているか？
• デフォルト：開発者が鍵と平文だけ渡したらどうなるか？常に認証付き暗号（AEAD）か、それとも誤って「暗号化のみ」に陥ることがあるか？
• サイドチャネル姿勢：どの操作が定数時間を想定しているか？タイミング、キャッシュ、分岐漏えいの脅威モデルは明確か？
• 鍵管理：鍵はどう生成・保管・回転・ゼロ化されるか？鍵フォーマットは明示されバージョン管理されているか？
• 監査と保守：最後の独立監査はいつか？脆弱性はどう扱われるか？セキュリティに関わる変更のチェンジログはあるか？

効果のあるエンジニアリング衛生習慣

暗号コードは安全臨界コードとして扱ってください：API を小さく保つ、バージョンを固定する、既知解テストを入れる、パーサ／シリアライザに対してファズを回す。サポートしないもの（アルゴリズム、レガシーフォーマット）を明記しておき、互換性のためのスイッチを残しておかないで移行を設計する。

実行可能な持ち帰り：今週からできるセキュリティ・バイ・コンストラクション

セキュリティ・バイ・コンストラクションは買うツールではなく、カテゴリごとのバグが生まれにくくする習慣の集合です。DJB 流のエンジニアリングに共通するのは：理解可能なほどにシンプルに保つ、誤用を制約するタイトなインターフェースを作る、攻撃下でも同じ振る舞いをするコードを書く、失敗時に安全に動くデフォルトを選ぶことです。

ホワイトボードに書いておくべき要点

• シンプルさはセキュリティ機能である。 小さいコンポーネント、少ない状態、少ない設定分岐は驚く振る舞いの発生箇所を減らす。
• タイトなインターフェースは「創造的な」誤用を防ぐ。 多数の「ほぼ正しい」入力を受け入れる API より、一つの正しい形式を受け入れる API を好む。
• 定数時間の思考は見えない漏えいを減らす。 良いプリミティブを選んでも、周辺コードでタイミングや分岐、メモリアクセスパターンにより秘密が漏れることがある。
• 安全なデフォルトは無限のオプションに勝る。 ノブが増えるほどテストする組み合わせが増え、多くの場合誤設定の余地が増える。

チーム向けの1週間アクションリスト

1. インベントリ：暗号を使っている箇所を洗い出す（TLS 設定、パスワードハッシュ、トークン署名、鍵交換、乱数生成）。利用ライブラリと設定を正確に記録する。
2. リスクのあるパターンを置き換える：自作暗号、巧妙なエンコーディング／デコーディング、誤用しやすい機能豊富な API を排除する。意見の強い少数のプリミティブに標準化する。
3. インターフェースを制約する：暗号呼び出しを狭い内部モジュールでラップし、最小限の公開面（少ないパラメータ、強い型、明確な入力検証）にする。
4. 回帰を捕まえるテストを追加する：プリミティブごとの既知解テスト、パーサに対するファズテスト、ホットパスの「秘密依存分岐なし」チェックを入れる。
5. デフォルトを固定する：安全なベースラインをコード内（Wiki ではなく）に設定し、逸脱には明示的なレビューを要するようにする。

構造化されたチェックリストが欲しければ、社内セキュリティ文書の横に「暗号のインベントリ」ページ（例：/security）を追加することを検討してください。

高速なアプリ提供における「セキュリティ・バイ・コンストラクション」についての一言

これらの考え方は暗号ライブラリに限りません。アプリケーションの作り方とデプロイの仕方にも当てはまります。vibe‑coding ワークフロー（例：Koder.ai のようにチャットで Web/サーバ/モバイル アプリを作る）を使う場合でも、同じ原則は プロダクト制約 として現れます：サポートするスタックを少数に絞る（Web は React、バックエンドは Go + PostgreSQL、モバイルは Flutter 等）、変更を生成する前に計画させる、ロールバックを安価にすることを重視する。

実務では、計画モード、スナップショットとロールバック、ソースコードのエクスポート といった機能がミスの被害範囲を減らします：変更を適用する前に意図をレビューでき、問題発生時にすぐ戻せて、生成物がレビューしたものと一致することを検証できます。これは qmail の分割化という発想を現代のデリバリーパイプラインに適用したものです。