【実務・中級編】関数型における「Covariance（共変性）」と「Contravariance（反変性）」が引数に与える影響 – TypeScript コア・型システムの基礎解析バイブル

コードレビューをしていて、最もゾッとする瞬間の一つがこれだ。

// 一見、何の変哲もないイベントハンドラーの型定義だが……
type OldClickHandler = (event: MouseEvent) => void;
type StrictClickHandler = (event: Event) => void;

let handler: OldClickHandler = (e: MouseEvent) => console.log(e.clientX);
let safeHandler: StrictClickHandler = handler; // 💥 コンパイルエラーにならない！？なぜだ！？

「あれ？ `MouseEvent` を受け取る関数を、より広い `Event` を受け取る変数に代入しているのに、なぜTypeScriptはエラーを出さないんだ？」
もし君がここで首を傾げたなら、TypeScriptの型システムの心臓部である「関数の引数における反変性（Contravariance）」の理解が少し危ういかもしれない。

フロントエンドのコンポーネント設計、特に共通UIライブラリのコールバック定義や、複雑な非同期APIのミドルウェアチェーンを構築する際、この変性（Variance）の原理原則を理解していないと、「コンパイルは通るのに、実行時になると `TypeError: undefined is not a function` やプロパティの欠落でアプリがクラッシュする」という悪夢のようなバグを生み出すことになる。

今回は、TypeScriptの型システムがコンパイル時にどのように型を評価し、実行時の安全性を担保しているのか。その深淵へ案内しよう。

—

1. 型システムの基本原理：なぜ引数は「反変」なのか？

まず、TypeScriptの関数型における代入可能性（Assignability）のルールを定義する。
結論から言えば、TypeScriptの関数の引数は「反変（Contravariant）」、戻り値は「共変（Covariant）」である。

なぜ引数は反変なのか？直感とは反するように思えるこの挙動を、厳密な型理論と実務の文脈で解きほぐそう。

共変（Covariance）と反変（Contravariance）の直感的な定義

共変（Covariance）: 型の階層構造がそのまま保たれる方向の代入可能性。(`Sub` → `Super`)
反変（Contravariance）: 型の階層構造が逆転する方向の代入可能性。(`Super` → `Sub`)

戻り値は共変である。例えば、「動物（Animal）を返す関数」が求められている場所に、「犬（Dog）を返す関数」を渡すことは安全だ。なぜなら、呼び出し側は「動物」を期待して受け取るため、実際に返ってきたのが「犬」であっても何ら問題なく処理できるからだ（`Dog` は `Animal` の部分型）。

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

let getAnimal: () => Animal;
let getDog: () => Dog = () => ({ name: “Pochi”, bark: () => console.log(“Bow”) });

// OK: Dog を返す関数は、Animal を返す関数として扱える（戻り値は共変）
getAnimal = getDog;

では、引数はどうだろうか？

「犬（Dog）を受け取って何かをする関数」が求められている場面を想像してほしい。そこに「あらゆる動物（Animal）を受け取って処理できる関数」を渡すのは安全だろうか？
答えはYESだ。なぜなら、その関数は「犬」が渡されても問題なく処理できるからだ（犬は動物なのだから）。

しかし、逆はどうか？
「動物（Animal）を受け取って処理する関数」が求められている場所に、「犬（Dog）専用の関数」を渡したらどうなるか？呼び出し側が「猫（Cat）」を渡してきた瞬間、その関数は `Cat` を処理できずにクラッシュする。

したがって、「引数の型は、より広い（抽象的な）型を受け取れる関数ほど、より狭い（具体的な）型を要求する関数に代入できる」という、型の向きが逆転する現象が起きる。これが反変性だ。

—

2. 【危険な罠】`strictFunctionTypes` との闘い

ここで、TypeScriptの歴史とコンパイラオプションの話をしよう。
TypeScript 2.6 以前、関数の引数は実は共変として扱われていた（あるいは双変：Bivariant）。これは配列のメソッドなどでメソッド構文（`method(x: T): void`）が持つ利便性のために意図的に緩められていた仕様だが、これにより深刻な型安全性の穴が空いていた。

現代のTypeScriptでは、`tsconfig.json` の `strict: true`（あるいは個別の `strictFunctionTypes: true`）によって、メソッド以外の関数式やアロー関数において、引数が厳格に反変として評価される。

// tsconfig.json
{
“compilerOptions”: {
“strict”: true, // これにより strictFunctionTypes も true になる
}
}

もし、この設定を理解せずにレガシーなコードや安易な `any`・型アサーションを多用していると、次のような事故が起きる。

実務でありがちなバグ：イベントハンドラーの型汚染

フロントエンドのフォーム設計において、カスタムフックやUIコンポーネントに渡すイベントリスナーを定義している場面を考えてみよう。

type BaseEvent = { target: HTMLElement; timestamp: number };
type DetailedClickEvent = BaseEvent & { mouseX: number; mouseY: number };

// フォームコンポーネントが要求するハンドラー型
type FormHandler = (event: BaseEvent) => void;

// 開発者が実装した詳細なクリックハンドラー
const handleClick: (e: DetailedClickEvent) => void = (e) => {
console.log(e.mouseX); // 実行時にここが呼ばれる想定
};

// ❌ 待て！これがコンパイルエラーになる理由を説明できるか？
const registerFormHandler = (handler: FormHandler) => {
// 内部では一般的な BaseEvent を流し込む想定
const genericEvent: BaseEvent = { target: document.body, timestamp: Date.now() };
handler(genericEvent); // ここで BaseEvent が渡される！
};

// TypeScriptの型チェックにより、ここでエラー（または代入時の不整合）が発生する：
// FormHandler は BaseEvent を要求するが、handleClick は DetailedClickEvent しか処理できない。
// もし代入できてしまったら、genericEvent には mouseX が存在せず、実行時エラーになる。

反変性のルールがあるおかげで、TypeScriptはこの脆弱な代入をコンパイルエラーとして検出し、プロダクション環境でのクラッシュを未然に防いでいるのだ。

—

3. プロダクションコードで実践する：型安全なコールバック設計パターン

ここからが本題だ。この「共変・反変」の特性を完全に理解した上で、実際のモダンなフロントエンド開発（React、非同期API連携、イベント駆動アーキテクチャ）において、いかにして堅牢で拡張性の高い型を設計するかのベストプラクティスを提示する。

パターンA：多段階のAPIミドルウェアチェーン設計

例えば、APIリクエストの前後にフックを挟むミドルウェアを設計するとしよう。リクエストデータやレスポンスデータがジェネリックに変化する環境で、反変性を利用して「より汎用的なロガー」を「特定のAPIハンドラー」に差し込めるように設計する。

APIコンテキストの基本型

/
type ApiContext = {
readonly requestId: string;
readonly timestamp: number;
};

type AuthenticatedContext = ApiContext & {
readonly userId: string;
readonly token: string;
};

ミドルウェアの型定義
引数に関数（次へ送る処理）を取るような高階関数の場合、
引数の型が「反変」であるため、型のレイヤー構造に細心の注意が必要になる。

// 特定の認証済みコンテキストを処理するハンドラー
type AuthApiHandler = (ctx: AuthenticatedContext) => Promise;

// より汎用的なログ記録ミドルウェア（任意の ApiContext を処理できる）
type GenericLogMiddleware = (ctx: ApiContext, next: () => Promise) => Promise;

設計のキモ：
「AuthApiHandler（狭い型）」を要求する関数に対して、
「ApiContext（広い型）」を受け取れるミドルウェアを適用したい場合、
引数の反変性により、安全に統合することができる。

/
function createPipeline(
handler: AuthApiHandler
): (ctx: AuthenticatedContext) => Promise {
return async (ctx: AuthenticatedContext) => {
// ctx は AuthenticatedContext だが、
// GenericLogMiddleware は ApiContext を受け取れるため、ここに渡しても完全に安全。
const logger: GenericLogMiddleware = async (baseCtx, next) => {
console.log(`[LOG] Request ID: ${baseCtx.requestId} at ${baseCtx.timestamp}`);
return await next();
};

return await logger(ctx, () => handler(ctx));
};
}

パターンB：イベントリスナーのオーバーロードと共変・反変の調停

UIライブラリやカスタムEventEmitterを自製する場合、イベントのPayloadの型安全性を保つために、引数の反変性を逆手に取った「条件付き型（Conditional Types）」や「関数のオーバーロード」を活用する。

以下のコードは、リスナー登録において、引数の型安全性を極限まで高めたプロダクション品質のイベントバスの実装例だ。

// イベントマップの定義
type EventMap = {
‘user:login’: { userId: string; loginAt: Date };
‘user:logout’: { userId: string };
‘error’: { error: Error; code: number };
};

堅牢なType-Safe Event Emitter

/
class TypedEventEmitter> {
private listeners: {
[K in keyof TMap]?: Array<(payload: TMap[K]) => void>;
} = {};

リスナーの登録
引数の関数型 `(payload: TMap[K]) => void` において、
ユーザーが提供するハンドラーの引数が「共変・反変」の文脈で正しく推論されるよう配慮する。

/
public on(event: K, listener: (payload: TMap[K]) => void): void {
if (!this.listeners[event]) {
this.listeners[event] = [];
}
this.listeners[event]?.push(listener);
}

public emit(event: K, payload: TMap[K]): void {
this.listeners[event]?.forEach((listener) => {
// 実行時の型安全性が保証されているため、キャスト不要
listener(payload);
});
}
}

// — 使用例 —
const emitter = new TypedEventEmitter();

// OK: 正しいペイロード型を受け取るハンドラー
emitter.on(‘user:login’, (payload) => {
console.log(`User logged in: ${payload.userId} at ${payload.loginAt.toISOString()}`);
});

// ❌ コンパイルエラー: 存在しないプロパティや誤った型は弾かれる
// emitter.on(‘user:login’, (payload) => {
// console.log(payload.error); // Property ‘error’ does not exist on type…
// });

ここで重要なのは、`listener: (payload: TMap[K]) => void` という定義だ。もしここに `any` を使ってしまうと、反変性の恩恵はすべて失われ、型安全性の崩壊したレガシーコードに逆戻りする。TypeScriptの型推論器に正確な型の制約を渡すことで、コールバックの引数チェックが完璧に機能するようになる。

—

4. チーフアーキテクトからの提言：パフォーマンスとメンテナンスの心得

最後に、型システムを極める上で避けて通れない「コンパイルパフォーマンス」と「可読性」のトレードオフについて言及しておく。

1. 過剰なジェネリクスと変性の複雑化を避ける
高度な型メタプログラミング（`infer` や複雑な共変・反変の組み合わせ）は、時にTypeScriptの型チェッカー（TSServer）に甚大な負荷をかけ、IDEの補完速度（LSPの応答性）を著しく低下させる。関数型の引数設計においては、できる限り「明示的なインターフェース定義」または「シンプルなジェネリクス」にとどめ、型推論の迷子を防ぐこと。
2. メソッド構文とプロパティ構文の違いに注意する
TypeScriptにおいて、オブジェクトのプロパティとしての関数定義には歴史的経緯（Bivarianceの許容）がある。厳格な型安全性を求める領域（コアなライブラリやアーキテクチャ層）では、必ずアロー関数形式（`prop: (arg: T) => U`）を採用し、意図しない双変性によるバグの侵入を防ぐべし。

// ⚠️ メソッド構文（引数が双変として扱われる可能性があり、厳密な反変チェックをすり抜ける場合がある）
interface DangerousComponent {
handleClick(e: Event): void;
}

// ✨ プロパティ構文＋アロー関数（完全に厳格な反変性が適用される）
interface SafeComponent {
handleClick: (e: Event) => void;
}

TypeScriptの型システムは単なる「エラーチェックツール」ではない。それは、「実行時エラーをコンパイル時に完全に駆逐するための数学的証明システム」である。
引数の共変性と反変性のメカニズムをマスターした君のコードは、明日から一段と堅牢で、予測可能で、プロフェッショナルなものに生まれ変わるはずだ。

コードレビューで後輩が変性の罠にハマっていたら、この知識をドヤ顔で授けてやってほしい。