こんにちは！TypeScriptの世界へようこそ。
フルスタックチーフアーキテクトの私です。
日々の開発でTypeScriptを書いていると、「あれ、なんでこの組み合わせで型エラーになるんだろう？」と首を傾げたくなる瞬間に出会いませんか？
今回は、関数における「Rest Parameters（可変長引数）」と「Default Parameters（デフォルト引数）」を同じ関数の中で同時に使ったときに起こる、TypeScriptの型システムの「ちょっとした罠」と、それを美しく回避する設計指針についてお話ししていきますね。
ここをクリアできれば、あなたもTypeScriptの関数型定義の基本はバッチリマスターできますよ！それでは、一緒に紐解いていきましょう。
—
1. そもそも「Rest」と「Default」って何だっけ？
まずは基本のおさらいから。それぞれの特徴をサクッと確認しておきましょう。
- Default Parameters（デフォルト引数）: 引数が渡されなかったり、`undefined` が渡されたりしたときに、あらかじめ決めておいた初期値を代入してくれる機能です。
- Rest Parameters（レスト引数 / 可変長引数）: 渡された複数の引数を、ひとまとめにして「配列」として受け取る機能です（`…args` の形のアレです）。
この2つ、どちらも非常に便利で、JavaScript（ES6）の時代からよく一緒に使われてきました。では、これらをTypeScriptの関数で同時に使おうとすると、型システムの中で何が起きるのでしょうか？
—
2. 陥りやすい罠：コードで見る型推論の挙動
まずは、よくやりがちなコードを見てみましょう。ここでは、「プレフィックス（接頭辞）」を必ず1つ持ち、その後に任意の数のメッセージを受け取ってログに出力する関数を考えてみます。
// ⚠️ やりがちな実装例
function logMessages(prefix: string = “INFO”, …messages: string[]) {
console.log(`[${prefix}]`, …messages);
}
// 呼び出し側
logMessages(“ERROR”, “データベース接続に失敗しました”, “再試行します”);
logMessages(undefined, “システム起動中…”); // デフォルト値を使いたいので undefined を渡す
logMessages(); // 何も渡さずにデフォルト値を使いたい
一見すると、何の問題もなさそうな美しいコードに見えますよね。
しかし、TypeScriptのコンパイラ（型推論エンジン）の視点に立って、この関数の「パラメータの並び順」をじっくり眺めてみてください。
ここに、TypeScriptが厳格に守っている鉄のルールがあります。
> 「Restパラメータ（`…args`）は、必ずパラメータリストの『一番最後（末尾）』に置かなければならない」
あれ？ 上のコードをよく見てください。
`prefix`（Default）が先に来て、`messages`（Rest）が後に来ています。これなら「最後」だからセーフ……ではありません！
デフォルト引数が持つ「オプショナル化」の罠
実は、TypeScript（およびJavaScript）では、Restパラメータより前にあるパラメータにデフォルト値を設定すると、そのパラメータは自動的に「省略可能（Optional）」な扱いになります。
コンパイラは、関数の型を次のように解釈します。
1. 第1引数 `prefix` は、省略可能（`string | undefined`）。
2. 第2引数以降 `messages` は、Restパラメータ（`string[]`）。
ここで問題になるのが、「順番のジレンマ」です。
JavaScript / TypeScriptの仕様上、「必須の引数」を「省略可能な引数（またはデフォルト引数）」の後ろに置くことはできません。
もしあなたが、「デフォルト引数は使いたいけれど、Restパラメータのあとに特定の固定引数を置きたい」といった複雑な並び順を組もうものなら、コンパイラから以下のような冷たいエラーを突きつけられます。
> A rest parameter must be last in a parameter list.
> （Restパラメータは、パラメータリストの最後に配置されなければなりません）
—
3. なぜこの罠にハマるのか？（コンパイラの気持ち）
なぜTypeScriptはここまで厳しく順番にこだわるのでしょうか？
それは、呼び出し側で引数が渡されたとき、それがどのパラメータにマッピングされるのかが曖昧になってしまうからです。
例えば、もしデフォルト引数がRest引数の「後ろ」に置けたとしたらどうでしょう？
`logMessages(…messages, prefix = “INFO”)` のような書き方が許された場合、可変長の配列のあとに続く最後の値が、果たして `prefix` なのか、それとも `messages` の一部なのか、コンピュータには区別がつかなくなってしまいますよね。
そのため、TypeScriptの型システムは、「不確定な数の要素を取るRestパラメータは、常に一番ケツ（最後）に陣取らなければならない」というルールを絶対のものとして課しているのです。
—
4. 堅牢な設計のためのベストプラクティス
では、この制約を踏まえた上で、実務で安全かつエレガントにこの2つの機能を共存させるにはどうすればよいでしょうか？
答えはシンプルです。「引数の順番を正しく守る」こと、そして「複雑になりすぎる場合はオブジェクト引数に逃げる」ことです。
パターンA：正しい順序（Defaultを後ろ、またはRestを前…にはできないので工夫する）
原則として、Restパラメータは常に最後でなければなりません。そのため、デフォルト値を持たせたい引数がある場合は、構造を見直すのが定石です。
// ✅ 正しいアプローチ：
// デフォルト値を使いたい場合は、オーバーロード（Function Overloading）を使うか、
// 関数内部で明示的に undefined チェックを行うのが最も安全です。
function logMessages(…args: string[]) {
// 第1引数が渡されなかった場合のデフォルト値を関数内でハンドリングする
const prefix = args.length > 0 && args[0] !== undefined ? args[0] : “INFO”;
const messages = args.length > 0 ? args.slice(1) : [];
console.log(`[${prefix}]`, …messages);
}
パターンB：オブジェクトの分割代入（チーフアーキテクトイチオシの設計）
引数が多くなったり、デフォルト値と可変長の要素が混ざって複雑化したりする場合は、「引数を1つのオブジェクトにまとめてしまう」のが、最もモダンで拡張性の高いフロントエンドの設計手法です。
// 型定義
type LogOptions = {
prefix?: string; // デフォルト値を適用したいオプショナル引数
messages: string[]; // 可変長のメッセージ配列
};
// 実装
function logWithConfig({ prefix = “INFO”, messages }: LogOptions) {
console.log(`[${prefix}]`, …messages);
}
// 呼び出し側（圧倒的に読みやすく、順序を気にする必要がなくなる！）
logWithConfig({
prefix: “ERROR”,
messages: [“DB接続失敗”, “タイムアウト発生”]
});
logWithConfig({
messages: [“システム正常稼働中”] // prefixを省略すれば自動的に “INFO” になる！
});
このオブジェクト形式を採用するメリットは計り知れません。
- 引数の「順番」を気にする必要が一切なくなる。
- 将来的にオプション（例: `timestamp?: boolean` など）が増えても、関数のシグネチャを壊さずに拡張できる。
- 呼び出し側でキー名を指定するため、コードの可読性が劇的に向上する。
—
まとめ
今回は、関数型における「Rest Parameters」と「Default Parameters」の共存の罠と、その裏にあるTypeScriptの型評価のルールについて解説しました。
- Restパラメータは、必ずパラメータリストの「一番最後」に置く必要がある。
- 順番のルールを破ると、コンパイラがエラーを教えてくれる。
- 複雑な引数の組み合わせに悩んだときは、オブジェクトの分割代入（Optionsパターン）へリファクタリングすることで、型安全かつ拡張性の高い美しいコードになる。
TypeScriptの型システムは、一見すると厳しく私たちを縛るように思えるかもしれませんが、それはすべて「実行時エラーをコンパイル時に未然に防ぐため」の優しさです。
この仕組みの本質さえ掴んでしまえば、もう怖いものはありません。ぜひ今日の開発から試してみてくださいね。あなたのTypeScriptライフが、より一層快適なものになりますように！