テックリードのAです。日々のコードレビュー、お疲れ様です。
プルリクエストを眺めていて、以下のようなコードに遭遇したことはないだろうか？
// パターンA
function fetchUser(userId?: string) { … }
// パターンB
function fetchUser(userId: string = “guest-id”) { … }
「どちらも引数を省略できるのだから同じだろう」と思っていないか？
もしそうであれば、TypeScriptの型システムとランタイムの挙動の境界線について、少し解像度を上げる必要がある。
今回は、関数引数におけるオプショナル (`?`)とデフォルト値 (`=`)が、コンパイラによってどう型評価され、実務の現場でどのようなバグの温床になり得るのかを、コンパイラ内部の視点も交えながらロジカルに解説しよう。
—
1. 型評価の根本的な違い：`undefined` の侵入経路
まず、TypeScriptの型システムにおいて、この2つがどのように解釈されるのかを正確に把握する。
オプショナル引数 (`?`) の正体
引数に `?` を付与するということは、TypeScriptに対して「この引数は渡されなくてもよい。その場合、内部的には `undefined` が入り込む可能性がある」と宣言しているに等しい。
function logUser(id?: string) {
// id の型は 「string | undefined」 として評価される
console.log(id.toUpperCase());
// 🔴 怒られる: Object is possibly ‘undefined’.
}
コンパイラは厳格に `undefined` の可能性を追跡するため、ガード節（`if (!id)` など）を挟まないと、上記のようにコンパイルエラーを吐く。これは非常に健全な挙動だ。
デフォルト値 (` = “…”`) が持つ型推論の魔法
一方、デフォルト値を設定した場合はどうなるか。
function logUser(id: string = “guest-id”) {
// id の型は 「string」 として推論される（undefined は含まれない）
console.log(id.toUpperCase());
// 🟢 怒られない！
}
ここで重要なのは、デフォルト値を指定した時点で、そのパラメータの型から `undefined` が自動的に削ぎ落とされるという点だ（厳密には、明示的に `undefined` を渡さない限り、型は `string` に収束する）。
—
2. 実務で頻出する「やってはいけない」アンチパターン
非同期APIのラッパーや、UIコンポーネントのプロパティ設計で、この違いを理解していないがために生じる「保守性の低いコード」を見てみよう。
アンチパターン：オプショナルとデフォルト値の「二重フック」
type Options = {
timeout?: number;
}
// ❌ 冗長かつ危険な設計
function apiRequest(endpoint: string, options?: Options) {
const timeout = options?.timeout ?? 5000; // 毎回フォールバックを書いている
// options 自体が undefined の可能性を常にケアしなくてはならない
if (options && options.timeout) {
// …
}
}
このコードの問題点は、呼び出し元に「何も渡さない」「`{}` を渡す」「`{ timeout: undefined }` を渡す」といった多様な余地を与えてしまっている点だ。型定義が甘いと、コードベース全体に無駄なオプショナルチェイニング（`?.`）が蔓延し、認知負荷が跳ね上がる。
—
3. プロダクションコードで採用すべき「堅牢な設計パターン」
では、実務のフロントエンド開発やAPI連携において、どう設計するのがベストプラクティスなのか。
結論から言えば、「関数のエントリーポイントではデフォルト値やオブジェクトの destructuring（分割代入）によるデフォルト値活用で `undefined` を極力内部に入り込ませず、型を強固に保つ」のが鉄則だ。
以下に、実戦でそのまま使えるクリーンなコンポーネント・APIラッパーの設計例を示す。
/
- 堅牢なAPIリクエスト関数の実装例
/
type RequestConfig = {
retries?: number;
timeout?: number;
cache?: boolean;
};
// 設定のデフォルト値を定義
const DEFAULT_CONFIG: Required
retries: 3,
timeout: 5000,
cache: true,
};
async function executeQuery
url: string,
// 引数オブジェクト自体をオプショナルにしつつ、デフォルト空オブジェクトを割り当てる
{ retries, timeout, cache }: RequestConfig = {}
): Promise
// 分割代入時のデフォルト値で、undefined を完全にシャットアウトする
const resolvedRetries = retries ?? DEFAULT_CONFIG.retries;
const resolvedTimeout = timeout ?? DEFAULT_CONFIG.timeout;
const resolvedCache = cache ?? DEFAULT_CONFIG.cache;
console.log(`Executing request to ${url} with timeout: ${resolvedTimeout}ms`);
// 実装本体（型は完全に安全）
return {} as T;
}
// — 呼び出し側の世界 —
// 1. 引数を完全に省略しても型エラーにならない
await executeQuery(‘/api/users’);
// 2. 一部だけ指定しても、残りはデフォルト値（あるいは安全なフォールバック）に委譲される
await executeQuery(‘/api/users’, { timeout: 10000 });
この設計が優れている理由
1. 呼び出し元の自由度と安全性の一致: 呼び出し側は必要なオプションだけを渡せばよく、余計なボイラープレートを書かずに済む。
2. 内部ロジックの精神衛生: 関数内部に入ってきた時点で、各プロパティは「存在する（あるいは安全に解決された）」状態であることが保証されるため、無駄な `if (foo !== undefined)` のようなガードを書く必要がなくなる。
—
4. チーフアーキテクトからの提言
TypeScriptの型システムは、単なる「エラー検出ツール」ではない。「コードの意図をドキュメント化し、不正な状態の存在を型レベルでコンパイル不可能にするためのアーキテクチャ言語」である。
- 引数を省略させたいだけで、内部でフォールバックを持つなら、単なる `?` ではなくデフォルト値 (`=`) や 分割代入のデフォルト値の活用を検討せよ。
- `undefined` が関数内部の深部まで伝播しているコードを見かけたら、それは設計の見直しのサインだ。
今日のレビューから、チームのコードの「型に対する厳ドメーヌ性」を一段引き上げてほしい。君たちの書くコードが、プロダクションの信頼性を支えているのだから。