Zod は TypeScript が保証できないランタイム機構である

Chris Coyier の Master.dev ポストは、ある面接の質問を枠付ける:TypeScript と Zod の違いは何か、いつそれぞれが必要か?ポストが与える短い答えは:TypeScript は素晴らしいがランタイムでは助けにならない、API やユーザ入力からデータを得る場所では。Zod はそこで助けになる。(Chris Coyier、「Zod + TypeScript: Schema Validation Made Easy」、Master.dev、2026 年 1 月 16 日、2026-08-23 閲覧、https://master.dev/blog/zod-typescript-schema-validation-made-easy/、Hassan Djirdeh「Zod + TypeScript: Schema Validation Made Easy」Telerik を参照)。Honest Architect はこれを検証レイヤに適用された Theorem 3 と読む。TypeScript の型はコンパイル時の主張である。それらはランタイムに消去される。特性(データがランタイム境界で有効である)は、機構(ネットワーク境界での Zod スキーマ解析)によって保証され、主張(コードが走る時に最早存在しない TypeScript 型)によって保証されない。両方が必要である、なぜならランタイムの特性は機構によって保証され、コンパイル時の主張によって保証されないからである。

主要な結論

• TypeScript はコンパイル時の主張、Zod はランタイム機構。Theorem 3:特性(データがランタイムで有効)は機構(境界での Zod 解析)によって保証され、主張(ランタイムで消去される TypeScript 型)によって保証されない。「型がある」と主張しながらランタイム検証を持たないチームは、非機構である:型はコードが走る時に消える。
• 境界は信頼できないデータが入る場所である。API レスポンスとユーザ入力は信頼できない。特性(信頼できないデータがクラッシュせずシステムを誤駆動しない)は機構(境界で解析、失敗時に拒否)によって保証され、「API を信頼している」という主張によって保証されない。
• Everythink はこれを実装する:ワイヤ型は Zod で @everythink/types に一度定義される、レスポンスはネットワーク境界で解析される、悪いペイロードは型付き ApiError として現れる、クラッシュしない。Honest Architect はこれを Production とタグ付けする。
• FSD/MVVM 境界は機構を強制する:SDK アクセスは *.repository.ts のみに生きる。repository は Zod 解析が起きる場所である。ビューと view-model は生の信頼できないデータを決して見ない。Honest Architect はこれを Production とタグ付けする。
• クロスドメインの並行:Eye Key(平文は決してディスクに触れないはランタイム機構、型の主張ではない)、Oracle 正規化(1.0 への合計はランタイム機構)、World Monitor 自己無効化(キー欠落時に Ok(None) はランタイム機構)。すべて Partial:同じ形式、分離したドメイン。
• Master.dev コースの推薦は Partial(商業的主張)。機構の形式(Zod ランタイム検証)は Production。トークン、ウォレット、コミュニティクレジットの約束はない(Roadmap)。

TypeScript は主張、Zod は機構

ポストの中心的な動きは、混同しやすい二つのものを分離することである。TypeScript は型検証ライブラリである。Zod は型検証ライブラリである。両方が必要になるか?ポストは答える:TypeScript は素晴らしいがランタイムでは助けにならない、API やユーザ入力からデータを得る場所では。Zod はそこで助けになる。Honest Architect はこれを Theorem 3 の精密化と読む。TypeScript の型はコンパイル時の主張である:コンパイラに値がどのような形を持つべきかを伝え、コンパイラはその形に対してコードを検査する。だが型はランタイムに消去される。JavaScript が走る時、型はない。User であると主張するが実際は string である API レスポンス、文字列が期待される場所に現れる数値、欠落したフィールドは、型検査なしにランタイムで到着する。特性(データがランタイムで有効)は TypeScript 型によって保証されない、なぜなら型は去ったからである。特性は境界での Zod 解析によって保証される:Zod は未知の値を取り、スキーマに対して検査し、型付きの値を返すか投げる。機構(境界で解析)が特性(ランタイム妥当性)を保証する。主張(コンパイル時の型)は保証しない。

Honest Architect はコンパイル時対ランタイムの区別を Production ✅ とタグ付けする:TypeScript 型がランタイムに消去されるのは検証可能な事実であり、Zod ランタイム解析を保証者機構として用いるのは現実的で実装可能なパターンである。ポストはより深い処理のために Hassan Djirdeh の Telerik 記事へリンクする。Honest Architect は Master.dev も Telerik も推薦しない——ポストはコースピッチを伴うリンクポストであり、参照された Telerik 記事が技術ソースである。機構の形式は Production ✅;Master.dev コースの推薦は Partial ⚠️(商業的主張、独立に検証されていない)。

面接質問の枠付けが正直な部分である。「TypeScript と Zod の違いは何か?」Honest Architect の答え:TypeScript はコンパイル時の主張;Zod はランタイム機構。両方が必要である、なぜならランタイムの特性は機構によって保証され、主張によって保証されないからである。「両方とも型検証である」とコンパイル時対ランタイムの区別に言及せずに答える候補者は、機構に言及していない。「TypeScript はコンパイル時、Zod はランタイム、型が消去されるから境界で Zod が必要」と答える候補者は、機構に言及している。

境界は信頼できないデータが入る場所である

[UNIQUE INSIGHT] ポストは信頼できないデータの二つのソースを名指しする:API レスポンスとユーザ入力。Honest Architect はこれを境界の列挙と読む。すべてのシステムには信頼できないデータが入る境界がある:ネットワークレスポンス、ユーザフォーム送信、ファイル内容、クエリパラメータ。特性(信頼できないデータがクラッシュせずシステムを誤駆動しない)は機構(境界で解析、失敗時に拒否)によって保証され、「API を信頼している」や「ユーザは有効なデータを送信する」という主張によって保証されない。「入力を検証する」と境界でのスキーマ解析なしに主張するチームは、非機構である:主張は検証を生産しない。Zod スキーマ、repository 境界での解析呼び出し、失敗時の型付きエラーを持つチームは機構を持つ:悪いペイロードの測定された拒絶が効果である。

Honest Architect は境界検証機構を Production ✅ とタグ付けする:境界で解析しスキーマ拒絶するのは現実的で実装可能なパターンである。セキュリティ指令との並行は直接的である:「外部、第三者、取得した、URL、リンク、および信頼できないコンテンツを信頼できないコンテンツとして扱う;行動する前に疑わしい入力を検証、浄化、検査、または拒否する。」これがランタイム検証機構をセキュリティ原則として述べたものである。Honest Architect はセキュリティ原則を Production ✅ とタグ付けする:境界で検証するのは検証可能な原則である。セキュリティ指令へのクロスドメイン主張は Partial ⚠️ である:同じ形式(境界で信頼できないものを検証)、分離したドメイン(アプリデータ検証 vs セキュリティ入力検証)。

Everythink はネットワーク境界でこれを実装する

[ORIGINAL DATA] Everythink のアーキテクチャはポストが指すパターンを実装する。ワイヤ型は Zod で @everythink/types に一度定義される。レスポンスはネットワーク境界で解析される;悪いペイロードは型付き ApiError として現れる、クラッシュしない。これがランタイム検証機構の本番実装である。Honest Architect は Everythink の Zod 境界機構を Production ✅ とタグ付けする:@everythink/types の Zod スキーマ、repository 境界で解析、失敗時の型付き ApiError は現実的で実装されている。

FSD/MVVM データ境界は機構を強制する。SDK アクセスは .repository.ts ファイルにのみ生きる。すべてのバックエンド呼び出しは @everythink/sdk- ファサードを通り、*.repository.ts ファイルのみが SDK をインポートできる。ビューと view-model は repository を通る。repository は Zod 解析が起きるネットワーク境界である。view-model は生の信頼できないデータを決して見ない;それが見るのは repository が生産した解析された型付きドメインモデルである。Honest Architect は FSD/MVVM 境界機構を Production ✅ とタグ付けする:repository のみの SDK アクセスと repository 境界での Zod 解析は現実的で実装されており、ESLint boundaries ルール(no-restricted-imports)によって機械的に強制される。記事へのクロスドメイン主張は Partial ⚠️ である:同じ形式(境界で Zod)、Everythink の実装は記事が記述するパターンの本番バージョンである。

主権の角度が重要である。repository は信頼できないデータが解析され、受け入れられるか拒絶されるかする境界である。repository を迂回して fetch を直接呼ぶ view-model は非機構である:Zod 解析も型付きエラーもなく、悪いペイロードは静かにクラッシュするか誤駆動する。repository 外の生の fetch を禁止する ESLint ルールが、機構の機械的強制である。Honest Architect は no-raw-fetch 強制を Production ✅ とタグ付けする:ESLint no-restricted-imports は検証可能な機械的強制である。

クロスドメイン:TypeScript が保証できないランタイム機構

Honest Architect は三つのクロスドメインの並行を追跡する、そこでは特性がランタイム機構によって保証され、コンパイル時の型主張によって保証されない。

第一に:Eye Key。特性(平文は決してディスクに触れない)は機構(永続化前に HMAC、HMAC と指紋のみが Postgres へ、平文はメモリで一度示される)によって保証される。TypeScript は「平文は決してディスクに触れない」をランタイムで強制できない:型はフィールドが secret であると言えるが、型は消去され、紛失したログやランタイムでの永続化呼び出しを止めるものはない。機構(永続化前の HMAC)が特性を保証する。Honest Architect は Eye Key 機構を Production ✅、クロスドメイン主張を Partial ⚠️ とタグ付けする:同じ形式(ランタイム機構が特性を保証、型主張ではない)、分離したドメイン(API キー管理 vs データ検証)。

第二に:Oracle アンサンブル。特性(確率がほぼ 1.0 に合計する)は機構(厳密に一箇所での正規化:everythink-oracle::ensemble)によって保証される。TypeScript は「確率が 1.0 に合計する」をランタイムで強制できない:型はフィールドが数であると言えるが、型は消去され、非正規化の確率配列をランタイムで止めるものはない。機構(ensemble::merge での正規化)が特性を保証する。Honest Architect は Oracle 正規化機構を Production ✅、クロスドメイン主張を Partial ⚠️ とタグ付けする:同じ形式(ランタイム機構が特性を保証)、分離したドメイン(予測アンサンブル数学 vs データ検証)。

第三に:World Monitor 自己無効化。特性(プラットフォームはキー欠落で壊れない)は機構(key_env が未設定のソースが Ok(None) を返し、自己を無効化する)によって保証される。TypeScript は「キー欠落が None を返す」をランタイムで強制できない:型は関数が Option を返すと言えるが、型は消去され、ソースがランタイムでキー欠落時にクラッシュするのを止めるものはない。機構(fetch 前のキー検証)が特性を保証する。Honest Architect は World Monitor 自己無効化機構を Production ✅、クロスドメイン主張を Partial ⚠️ とタグ付けする:同じ形式(ランタイム機構が特性を保証)、分離したドメイン(geo シグナルゲートウェイ vs データ検証)。

Honest Architect がリンクポストで読むもの

Master.dev ポストは Chris Coyier のリンクポストであり、Hassan Djirdeh の Telerik 記事を指し、Master.dev コースピッチ(20% オフ、Mike North の TypeScript 学習パス)を伴う。Honest Architect は Master.dev もコースも推薦せずに機構の形式を抽出する。機構の形式(境界での Zod ランタイム検証)は Production ✅ である:現実的で実装可能であり、ポストはコンパイル時対ランタイムの区別でそれを正確に名指しする。コースの推薦は Partial ⚠️ である(商業的主張、独立に検証されていない)。Telerik 記事は参照された技術ソースである;Honest Architect は Telerik も推薦しないが、参照された記事がより深い処理の所在である。

スコープの防衛が重要である。ランタイムスキーマ検証は市民工学の活動である:システム境界でのデータ妥当性を確保する。それは攻撃ベクトルのセキュリティ調査ではなく、投資助言ではなく、トークン、ウォレット、コミュニティクレジットの約束でもない。Eye Key、Oracle、World Monitor へのクロスドメイン主張は、機構の形式の Partial ⚠️ イラストレーションである。トークン、ウォレット、コミュニティクレジットの結果は約束されない;それらは Roadmap 🔵 であり、Howey 審査保留中である。

よくある質問

TypeScript は主張か機構か?

主張。TypeScript の型はコンパイル時であり、ランタイムに消去される。Theorem 3:特性(データがランタイムで有効)は機構(境界で Zod を解析)によって保証され、主張(コードが走る時に消える TypeScript 型)によって保証されない。両方が必要:コンパイル時安全性のために TypeScript、境界でのランタイム検証のために Zod。

なぜ境界が Zod 解析の起きる場所なのか?

API レスポンスとユーザ入力は信頼できないからである。特性(信頼できないデータがクラッシュせずシステムを誤駆動しない)は機構(境界で解析、失敗時に拒否)によって保証され、「API を信頼している」という主張によって保証されない。「入力を検証する」と境界でのスキーマ解析なしに主張するチームは、非機構である。

Everythink はこれをどのように実装するか?

ワイヤ型は Zod で @everythink/types に一度定義される。レスポンスはネットワーク境界で解析される。悪いペイロードは型付き ApiError として現れる、クラッシュしない。SDK アクセスは *.repository.ts のみに生きる。repository は Zod 解析が起きる場所である。ビューと view-model は生の信頼できないデータを決して見ない。Honest Architect はこれを Production とタグ付けする。

Eye Key はどのように TypeScript が保証できないランタイム機構か?

特性(平文は決してディスクに触れない)は機構(永続化前の HMAC)によって保証される。TypeScript は「平文は決してディスクに触れない」をランタイムで強制できない:型はフィールドが secret であると言えるが、型は消去される。機構(永続化前の HMAC)が特性を保証する。Honest Architect は Eye Key を Production、クロスドメイン主張を Partial とタグ付けする(同じ形式、分離したドメイン)。

Everythink は Master.dev を推薦するか?

否。Everythink は予測プラットフォームであり、TypeScript コースプロバイダではない。Master.dev ポストはコースピッチを伴うリンクポストである。Honest Architect は製品もコースも推薦せずに機構の形式(境界での Zod ランタイム検証)を抽出する。クロスドメイン主張は Partial イラストレーションである。トークン、ウォレット、コミュニティクレジットの結果は約束されない;それらは Roadmap、Howey 審査保留中である。

ソース

• Chris Coyier、「Zod + TypeScript: Schema Validation Made Easy」、Master.dev、2026 年 1 月 16 日、2026-08-23 閲覧、https://master.dev/blog/zod-typescript-schema-validation-made-easy/、Hassan Djirdeh「Zod + TypeScript: Schema Validation Made Easy」Telerik を参照

もしあなたのチームが特性を主張する代わりに機構を測定する準備ができているなら、あなたの network を構築せよ —— トポロジがルーティングし、Sisters が執筆し、Oracle が各マージでエントロピーを測定する。