回答。

事の歴史

TypeScriptは、安全な開発を重視しており、明示的な型の過剰を避けるように設計されています。ほとんどの変数、パラメータ、戻り値の型は、コンパイラによって自動的に推論されます。型推論のシステムは、JavaScriptに近い形でコードを書くことを可能にしつつ、厳格な型付けを維持することで、開発速度を大幅に向上させ、エラーを減少させます。

問題

型推論は、開発者が期待する型を常に保証するわけではありません。場合によっては、型があまりにも広範（anyやunknown）になったり、逆に過度に厳格になったりすることがあります。これにより、余分な制約が生じたり、型チェックが行われなかったりすることがあり、どちらも安全ではありません。

解決策

TypeScriptは、型が明示的に指定されていない場合、代入や関数の戻り値に基づいて型を自動的に推論します。推論を制御するには、型を明示的に指定すること、型アサーション、ジェネリクス、特別なユーティリティ（ReturnType、Parametersなど）を使用することができます。複雑な構造を扱う場合は特に注意が必要です。型が複雑または不明瞭な場合は、明示的に指定することが望ましいです。

コードの例:

let a = 5; // number（自動的に推論される）

function sum(x = 4, y = 3) { // x: number, y: number
  return x + y; // return: number
}

// 型推論のエラー
function getData(flag) {
  if (flag) return 123;
  // 別の分岐にreturnがないため — return type: number | undefined
}

// 明示的にする方が良い:
function getData(flag: boolean): number | undefined {
  if (flag) return 123;
}

重要な特徴:

TypeScriptは、初期化や値に基づいて変数の型を推論します。
関数やオブジェクトの場合、明示的な指定がないと型があまりにも広くなることがあります。
ジェネリクスや複雑な構造では、常に明示的に型を指定することが推奨されます。

誤解を招く質問。

True/False: 型推論は常に開発者が期待する型を提供する

False。時には型が広すぎたり、狭すぎたりすることがあります。特に配列やオブジェクト、ユニオンされた戻り値（number | undefinedなど）で期待外れのことがよくあります。

オブジェクトで型を指定しない場合、TypeScriptは常に正確な構造を保持する

いいえ、as constを使用しない限り、構造は「広がる」可能性がありますが、as constを使用すると、リテラル型の読み取り専用となります。

const obj = { kind: "duck" };
// obj: { kind: string }
const obj2 = { kind: "duck" } as const;
// obj2: { readonly kind: "duck" }

配列に型を指定しない場合、TSは常にその内容を知っている

いいえ、デフォルトではTypeScriptは配列を最大限「広く」します。例えば、let arr = [1, 'a']は(string | number)[]になりますが、タプルではありません。

型のエラーとアンチパターン

関数のパラメータに型推論を依存する（特にAPIでは） — 型は変更時に変わる可能性があります。
関数の戻り値の型を不明のままにする — メンテナンスが難しくなります。
定数オブジェクトに対してas constや明示的な型を使用しない。

実例

ネガティブケース

バックエンドが応答オブジェクト{ data: [] }を提供し、型が明示的に指定されていない場合、TypeScriptはtype data: any[]を推論します。いつかdataが文字列の配列になると — エラーはプロダクションでのみ発生します。

利点:

簡単なケースに対して手動で型を記述する必要がない。

欠点:

複雑な構造での予期しないエラー。
自動推論が問題を「飲み込む」ことがあります。

ポジティブケース

プロジェクトでは、常に関数の戻り値や複雑な構造に型を明示的に指定し、定数にはas constを使用することが慣例です。構造の変更はコンパイラによって検証されます。