TypeScriptの「デフォルト引数」と「オプショナル引数」の境界線：型安全性を極める設計論
TypeScriptを書いていると、つい「とりあえず動くから」で済ませがちなのが関数引数の定義だ。`?`（オプショナル）と `=`（デフォルト値）。この二つは、単なる構文のバリエーションではない。コンパイラが型を推論する際、「その変数が未定義（undefined）を取りうるか否か」という境界線を決定づける極めて重要な設計判断だ。
今日は、フロントエンドのコンポーネント設計や、堅牢なAPIクライアントを書く際に避けては通れない、この二つの共存と型推論の深淵に触れていく。
—
1. なぜ「オプショナル」と「デフォルト」を混同してはいけないのか
多くのエンジニアが犯す過ちは、`a?: string` と `a: string = ‘default’` を同じものとして扱うことだ。コンパイラAPIの内部挙動を知る者からすれば、これらは「関数の呼び出し側に見えるシグネチャ」と「関数内部のスコープ」において、まったく異なる解釈をされる。
オプショナル引数（?）
- 意味論: 「引数は渡されないかもしれない」。
- 型評価: 引数は `T | undefined` となる。内部で必ず `if (arg === undefined)` によるガードが必要になる。
デフォルト引数（=）
- 意味論: 「引数は省略できる。省略された場合はこの値を使う」。
- 型評価: 内部スコープでは `T`（undefinedを含まない）として扱われる。
これらを踏まえ、実務で頻出する「API連携のオプション設定」を例に、ベストプラクティスを見ていこう。
—
2. 実践的コード：堅牢な設定関数を構築する
単に「便利だから」で使うのではなく、TypeScriptの型推論を最大限に活かし、呼び出し側をミスさせない設計例を示す。
type FetchOptions = {
timeout: number;
retries: number;
cache: boolean;
};
/
- プロダクション環境で推奨される関数設計
- デフォルト値を持つ引数は、呼び出し側の型定義をクリーンに保つ
/
async function fetchWithConfig(
url: string,
// デフォルト値により、内部では必ず値が存在することが保証される
options: FetchOptions = { timeout: 5000, retries: 3, cache: true }
): Promise
// ここで options.timeout は number 型として確定している
// undefined チェックというノイズを排除できる
console.log(`Connecting to ${url} with timeout: ${options.timeout}`);
return fetch(url, { signal: AbortSignal.timeout(options.timeout) });
}
// 呼び出し側
// 引数を省略しても型安全が守られる
fetchWithConfig(‘/api/data’);
なぜこれが「美しい」のか
1. ガード節の排除: `options?.timeout ?? 5000` のような多重チェックを排除できる。
2. 型推論の収束: 関数の内部実装において、`options` を `undefined` かどうか気にせず扱えるため、ロジックの複雑性が激減する。
3. DXの向上: 呼び出し側に対して「何を渡せばいいのか」という期待値をデフォルト値で明示できる。
—
3. 注意すべき「アンチパターン」：推論の罠
一方で、以下のような記述は避けるべきだ。
// NG例：デフォルト値とオプショナルを混ぜる
function processData(data?: string = ‘default’) { … }
多くの環境でこれはエラーになるが、もし許容されたとしても言語仕様上の負債だ。`data` はオプショナルなのにデフォルト値があるという「二重の未確定状態」を生む。これは、「明示的に `undefined` を渡す」という行為が「デフォルト値を使う」ことと同義なのか、それとも「エラー」なのかを曖昧にする。
型システムにおいて、「曖昧さ」はバグの温床だ。
—
4. コンパイラが読み取る「型推論の重み」
TypeScriptのコンパイラは、デフォルト引数がある場合、その引数を「呼び出しシグネチャにおいてはオプショナル」として扱う。
つまり、`function fn(a: number = 10)` と書けば、`fn()` も `fn(20)` も許可される。重要なのは、デフォルト値の型が、関数の引数の型定義を「部分的に拘束する」という点だ。
もし複雑なリテラルをデフォルト値に置く場合、型注釈を明示的に書くことを強く推奨する。
// 型注釈がないと、推論が広くなりすぎて将来的なリファクタリングを阻害する
const DEFAULT_CONFIG: FetchOptions = { timeout: 5000, retries: 3, cache: true };
function advancedFetch(url: string, options = DEFAULT_CONFIG) {
// ここでの options は推論によって FetchOptions 型に固定される
// 外部定数として切り出すことで、型定義の一貫性が担保される
}
—
結論：エンジニアが守るべき原則
1. 省略可能にしたいならデフォルト値を置け: `undefined` との戦いをコードから追い出せ。
2. オプショナル `?` は「本当に値が欠落している可能性」がある場合のみ使う: APIのレスポンスや、ユーザーからの入力など、制御不可能なデータに対してのみ使用する。
3. デフォルト値は定数化せよ: ロジックの中にマジックナンバーならぬ「マジックオブジェクト」を埋め込まないこと。
TypeScriptの型システムは、あなたのコードを「縛る」ものではなく、「正しくあるべき姿へ導く」ための強力なツールだ。デフォルト引数という一つの機能を正しく使いこなすだけで、あなたの書く関数の信頼性は一回り向上する。
さあ、今日のコミットから「意味のない `undefined` チェック」を削除し、より洗練されたコードベースへと磨き上げよう。それが、伝説のアーキテクトに近づくための第一歩だ。