【実務・中級編】 Requiredによる全プロパティの必須化 – TypeScript実践ガイド

お疲れ様！今日もフロントエンドの実装、お疲れ様です。

開発を進めていると、APIから返ってくるデータや、フォームの入力値なんかで「このプロパティ、最初はオプショナル（任意）だけど、この処理を通った後は絶対に全部揃っていてほしいんだよね」という場面に遭遇すること、よくありませんか？

例えば、ユーザーの設定画面。ユーザーが未設定の項目は `undefined` で送られてくるかもしれないけれど、アプリケーションの内部ロジックやUI描画のフェーズでは、デフォルト値とマージされて「すべて値が存在する状態」として扱いたい。

そんな時に大活躍するのが、TypeScriptの組み込みユーティリティ型 `Required` です。

今回は、なんとなく使われがちな `Required` の本質から、裏側でTypeScriptがどう動いているのか、そして実務の泥臭いコードをエレガントに解決する実践的なアプローチまで、チーフアーキテクトの視点から徹底的に解説します。

さあ、一歩進んだ型安全の世界へ踏み込んでみましょう！

—

1. `Required` とは何か？

一言で言えば、「型 `T` のすべてのオプショナルプロパティ（`?` がついたもの）から、オプショナルさを剥ぎ取って必須（Required）にする」 ユーティリティ型です。

もっとも馴染み深い `Partial`（すべてをオプショナルにする）のちょうど「真逆」の操作を行うものですね。

まずは、最もシンプルな挙動を見てみましょう。

interface UserProfile {
id: string;
nickname?: string; // オプショナル
avatarUrl?: string; // オプショナル
}

// すべてのプロパティが「必須」になった新しい型が生成される
type StrippedProfile = Required;

// コンパイラ視点では、以下のように解釈されています：
// interface StrippedProfile {
// id: string;
// nickname: string; // ? が消えた！
// avatarUrl: string; // ? が消えた！
// }

非常にシンプルですね。しかし、なぜこれが実務でそれほど重要なのでしょうか？

—

2. 仕組みを深掘りする：裏側で何が起きているのか？

TypeScriptコンパイラにおける `-?` の魔法

「なぜ `?` が消えるのか？」その秘密は、TypeScriptの組み込み定義にあります。
`Required` の型定義のソースコードを覗いてみましょう。

type Required = {
[P in keyof T]-?: T[P];
};

ここで注目してほしいのが、`-?` という見慣れない記号です。

これは 「マッピング・モディファイア（Mapping Modifiers）」 と呼ばれるTypeScriptの構文です。
`[P in keyof T]` というループ（Mapped Types）の中で、各プロパティに付いている `?`（オプショナルマーク）を 「マイナス（除去）する」 という意思表示なのです。

逆に、`Partial` の定義を見ると、`+?`（または単に `?`）が使われています。

type Partial = {
[P in keyof T]?: T[P]; // 正確には +? と同義
};

このように、TypeScriptの型システムは単なる静的なテキストの置き換えではなく、型に対する「演算」を行っています。コンパイラはビルド時にこの演算を高速に処理し、デベロッパーに強固な安全網を提供してくれているわけです。

ブラウザ（ランタイム）での処理はどうなっている？

ここで初心者に聞かれることが多いのが、「`Required` を使うと、JavaScriptにコンパイルされたときにブラウザの実行速度に影響しますか？」 という質問です。

結論から言うと、影響は完全に「ゼロ」 です。

TypeScriptの型システムは、ビルド（トランスパイル）の過程で完全に消去（Type Erasure）されます。生成されるJavaScriptには `Required` の痕跡すら残りません。
つまり、ブラウザの裏側では、ただのプレーンなオブジェクトとして扱われます。

ランタイムのオーバーヘッドを一切増やすことなく、開発時のバグを100%コンパイル時点で叩き潰せる。これこそが、私たちが型定義にこだわる最大の理由です。

—

3. 実務で直面する「オプショナルの罠」を `Required` で解決する

では、ここからは現場でよくある「泥臭い」ユースケースを、綺麗なコードに昇華させる方法を見ていきましょう。

ユースケース：デフォルト設定（Default Config）とのマージ

アプリケーションの設定（Config）オブジェクトを扱う際、ユーザーは必要な部分だけを上書き（オプショナル）し、内部的にはシステム全体のデフォルト値とマージして「完全な設定オブジェクト」として扱いたいケースが多々あります。

まずはダメな例（アンチパターン）と、`Required` を使った美しい解決策を比較してみましょう。

❌ 良くないアプローチ（型アサーションや non-null アサーションの乱用）

interface AppConfig {
apiEndpoint?: string;
timeout?: number;
retryCount?: number;
}

const defaultConfig = {
apiEndpoint: “https://api.example.com”,
timeout: 3000,
retryCount: 3,
};

function initializeApp(userConfig: AppConfig) {
// マージして一つのオブジェクトにする
const finalConfig = { …defaultConfig, …userConfig };

// 呼び出し側でいちいち `!`（non-null assertion）を使ったり、
// オプショナルチェイニング `?.` を強要される。
// なぜなら、TypeScriptは finalConfig が「すべて値を持っている」ことを関知できないから。
console.log(finalConfig.apiEndpoint.toUpperCase()); // エラー: Object is possibly ‘undefined’.
console.log(finalConfig.apiEndpoint!.toUpperCase()); // 危険！ `!` でコンパイラを黙らせるハメに…
}

⭕️ `Required` を使った堅牢なアプローチ

ここで `Required` の出番です。デフォルト値とユーザー設定を安全にマージし、それ以降の処理では「絶対に値が存在する」ことを型レベルで保証します。

interface AppConfig {
apiEndpoint?: string;
timeout?: number;
retryCount?: number;
}

// デフォルト値のオブジェクト。これ自体が「すべての値を持っている（Required）」状態。
const defaultConfig: Required = {
apiEndpoint: “https://api.example.com”,
timeout: 3000,
retryCount: 3,
};

/

• ユーザーの設定を受け取り、デフォルト値と安全にマージする関数
• 戻り値は「すべてのプロパティが確実に存在する型（Required）」になる

/
function initializeApp(userConfig: AppConfig): Required {
// スプレッド演算子でマージ。型を Required として確定させる
const finalConfig: Required = {
…defaultConfig,
…userConfig,
};

// ここからは安全！オプショナルチェイニングも、危険な `!` も一切不要
console.log(finalConfig.apiEndpoint.toUpperCase()); // 完全に安全にアクセス可能
console.log(`Timeout is: ${finalConfig.timeout}ms`);

return finalConfig;
}

// 呼び出し例
initializeApp({ timeout: 5000 }); // apiEndpoint と retryCount はデフォルト値が補完される

このパターンの美しいところは、「デフォルト値（`defaultConfig`）の定義時に、プロパティの足し忘れをコンパイラが検知してくれる」 点にあります。
もし、将来的に `AppConfig` に新しいオプショナルな設定項目が追加された場合、`defaultConfig` 側で定義を忘れると、コンパイルエラーとして親切に教えてくれます。

—

4. 【応用】ネストされたオブジェクトの罠と「DeepRequired」

実務で `Required` を使い始めると、すぐに一つの壁にぶつかります。それは、「ネストされたオブジェクト（2階層目以降）には効かない」 という仕様（シャローな挙動）です。

interface NestedConfig {
theme?: {
color?: string;
fontSize?: string;
};
}

// Requiredを適用してみるが…
type FlatRequired = Required;

const config: FlatRequired = {
theme: {
// 1階層目の `theme` 自体は必須になったが、
// 2階層目の `color` や `fontSize` は依然としてオプショナルのまま！
}
};

「うわ、これじゃ意味ないじゃん！」と思いますよね。
そこで、シニアエンジニアとしてチームに共有してほしいのが、再帰的にすべての階層を必須化する `DeepRequired` というカスタムユーティリティ型です。

コードベースの共有ユーティリティファイル（`types/utils.ts` など）に、以下の定義をコピペして使ってみてください。

/

• オブジェクトのすべての階層のオプショナルプロパティを再帰的に必須化（Required）する型

/
export type DeepRequired = {
// 1. プロパティが関数、配列、またはプリミティブオブジェクト以外の特殊なオブジェクトならそのまま
// 2. 通常のオブジェクトなら、再帰的に DeepRequired を適用する
[P in keyof T]-?: T[P] extends Function
? T[P]
: T[P] extends Array
? _DeepRequiredArray
: T[P] extends object
? DeepRequired
: T[P];
};