【テクニカル・上級編】 strictFunctionTypesによる関数型の厳格化 – TypeScript実践ガイド

なぜ TypeScript の `strictFunctionTypes` は「甘え」を許さないのか？

フロントエンドの戦場において、我々が最も恐れるべきは「動くけれど壊れているコード」です。特に、大規模なステート管理や複雑な非同期パイプラインを扱う際、関数型のシグネチャが曖昧だと、ランタイムでの型安全性は砂上の楼閣と化します。

`tsconfig.json` の `strictFunctionTypes`。このオプションを「なんとなくオンにしている」というレベルで止めていませんか？実はこれこそが、TypeScript が「単なる型チェッカー」から「堅牢なエンジン」へと昇華する境界線なのです。

反変性（Contravariance）という数学的障壁

まず、本質的な話をしましょう。なぜ TypeScript のデフォルトは長らく関数の引数を「共変（Covariant）」に扱っていたのか。それは、JavaScript の動的な性質との妥協でした。しかし、`strictFunctionTypes: true` を有効にすると、TypeScript は本来あるべき数学的な厳密さ、すなわち「引数の反変性（Contravariance）」を強制します。

簡単に言えば、「より広い型を受け入れる関数は、より狭い型を受け入れる関数の代わりにはなれない」ということです。

interface Animal { name: string; }
interface Dog extends Animal { bark: () => void; }

// 犬を処理する関数
type DogHandler = (dog: Dog) => void;

// 動物なら何でも処理できる関数
const animalHandler: (animal: Animal) => void = (animal) => {
console.log(animal.name);
};

// strictFunctionTypes: true だと、これはコンパイルエラーになる
// なぜなら、DogHandler を期待している場所で animalHandler を呼ぶと、
// Dog にしかない bark メソッドを期待するロジックが実行され、クラッシュするからだ。
const handleDog: DogHandler = animalHandler;

この設定がない場合、TypeScript はこの代入を許可してしまいます。結果として、ランタイムで「`undefined is not a function`」というお馴染みの悪夢が起きるわけです。

非同期処理とアーキテクチャの健全性

現場でこの設定が真価を発揮するのは、高階関数や非同期処理の競合が発生する境界線です。例えば、カスタムフックや `React.memo` の比較関数、あるいは複雑な reducer の中で、引数の型が緩いと、意図しないプロパティの欠落が隠蔽されます。

特に、非同期で取得したデータが複数のコンポーネントを跨ぐ際、`strictFunctionTypes` が効いていれば、「型が一致しない」というアラートが早い段階で開発者の IDE を赤く染めます。これは単なる煩わしさではなく、「コンパイル時にバグを撲滅する」という極めて高い生産性への投資です。

実践：極限の型安全性を維持するためのコード構成

以下は、`strictFunctionTypes` の恩恵を最大限に受けるための、少し高度なパターンです。

// メモリ効率と安全性を考慮した高階関数の設計
type Processor = (input: T) => void;

// ジェネリクスを駆使して反変性を制御する
function createProcessor(handler: Processor): Processor {
return (input: T) => {
// ここで複雑な非同期タスクやレンダリングの最適化を行う
// strictFunctionTypes が有効であれば、T が不適切な型へ
// 暗黙的にキャストされることを確実に防げる
handler(input);
};
}

const handleString: Processor = (s) => console.log(s.length);

// 厳格なチェックにより、以下のような不整合な代入は即座に弾かれる
// const handleObject: Processor