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

TypeScriptにおいて、関数の引数はデフォルトで反変として評価される。なぜこのような「直感に反する」挙動が必要なのか。その答えは、関数が消費する「データの契約」にある。

—

2. なぜ引数は反変でなければならないのか？（Liskovの置換原則とメモリ安全性）

関数型 `(arg: T) => R` において、引数 `T` の型安全性を考えてみる。

ここに、次のようなオブジェクト階層が存在するとする。

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

// Dog は Animal の部分型 (Dog extends Animal)

ここで、「動物全般を受け取って処理する関数」があるとしよう。

function processAnimal(animal: Animal) {
console.log(animal.name);
}

この `processAnimal` は `Animal` 型を期待しているため、`Dog` を渡しても問題なく動作する（`Dog` は `Animal` のプロパティをすべて持っているため）。つまり、関数を受け取る側から見れば、より広範な型を受け取れる関数の方が安全である。

では、ここで引数の型の向きを逆に考えてみよう。もし関数の引数が共変（`Dog` を受け取る関数に、`Animal` を受け取る関数を代入できる）だと仮定すると、何が起きるか。

// Dog 専用の処理を行う関数
const handleDog: (dog: Dog) => void = (dog) => {
dog.bark(); // ここで絶対に bark が呼ばれる前提
};

// もし「引数が共変」であり、Animal を受け取る関数を handleDog の代わりに入れられたとする
let unsafeHandler: (dog: Dog) => void = processAnimal;
// processAnimal は animal: Animal を受け取るので、理論上は代入可能に見えるが…？

// 実行時
unsafeHandler({ name: “Chappy” });
// processAnimal({ name: “Chappy” }) が実行される。
// しかし、このオブジェクトには bark メソッドが存在しない！
// 結果：ランタイムで `dog.bark is not a function` の致命的例外が発生する。

この破綻を防ぐため、コンパイラは「により特化した（狭い）型を受け取る関数が必要な場所に、より汎用的な（広い）型を受け取る関数を代入することは許可するが、その逆は絶対に許可しない」という制約を課す。

これが反変性の数学的必然性である。
`Dog` が必要な場所に渡せるのは、`Dog` だけでなく `Animal` も、さらには `Jellyfish` すらも処理できるような、より抽象度の高い（広い）引数型を持つ関数でなければならない。

—

3. TypeScriptコンパイラにおける `–strictFunctionTypes` の挙動

TypeScript 2.6以前、メソッド以外の関数の引数はデフォルトで「双変（Bivariant）」として扱われていた。これは配列のコールバックなどで開発者に利便性をもたらすための妥協だったが、型安全性の観点からは穴（ホール）であった。

現在の厳格モード（`–strict` または `–strictFunctionTypes`）下では、関数記法における引数は厳密に反変として評価される。

以下のコンパイル挙動を観察してほしい。

interface EventBase {
timestamp: number;
}

interface ClickEvent extends EventBase {
x: number;
y: number;
}

interface KeyPressEvent extends EventBase {
key: string;
}

// イベントリスナーの型定義
type EventListener = (event: E) => void;

let handleAnyEvent: EventListener = (e) => {
console.log(e.timestamp);
};

let handleClickOnly: EventListener = (e) => {
console.log(e.x, e.y);
};

// 【重要】代入の方向性と型チェックの判定

// 1. ClickEvent を要求する場所に、EventBase を処理できる関数を入れるのは「安全」
handleClickOnly = handleAnyEvent; // コンパイル成功 (OK)
// 理由: handleAnyEvent はあらゆる EventBase（もちろん ClickEvent も含む）を処理できるため。

// 2. EventBase を要求する場所に、ClickEvent しか処理できない関数を入れるのは「危険」
// handleAnyEvent = handleClickOnly; // コンパイルエラー (NG)
// Error: Type ‘(event: ClickEvent) => void’ is not assignable to type ‘(event: EventBase) => void’.
// Types of parameters ‘event’ and ‘event’ are incompatible.
// Property ‘x’ is missing in type ‘EventBase’ but required in type ‘ClickEvent’.

コンパイラはこのエラーメッセージで、反変性の法則違反を正確に突いている。`EventBase` 全般を処理すべき関数スロットに、座標データ（`x`, `y`）を期待する偏った関数を突っ込むことが、システム全体のメモリ安全性や実行時整合性を破壊することをコンパイラは知っているのだ。

—

4. 高度な応用：コールバック地獄とジェネリクスにおける変性の制御

アーキテクチャの設計において、イベント駆動システムやプラグイン機構を構築する際、この反変性が壁になることがある。例えば、非同期のイベントエミッターを実装する場合だ。

class EventEmitter {
private listeners: ((event: TEvent) => void)[] = [];

// 登録時は、より広範なイベントを受け取れるリスナーも登録させたい場合がある
// （例: ClickEvent専用のエミッターに、EventBase全体を扱えるロガーを登録するなど）
public subscribe(listener: (event: TSub) => void) {
// ここで単純に代入しようとすると、配列の不変性・共変性の壁にぶつかる
}
}

ここで、あえて引数を共変的に扱わせたい（あるいは特定の制約をバイパスしたい）場合、TypeScriptではジェネリック関数の推論や条件付き型（Conditional Types）、あるいは関数オーバーロードを用いたテクニックが駆使される。

しかし、シニアアーキテクチャとして警告しておく。反変性を意図的にねじ曲げる設計は、ランタイムの型安全性を担保する防壁に穴を開ける行為に等しい。 特殊なフレームワーク層を構築する場合を除き、引数の反変性はそのまま受け入れ、設計側を型に適合させるべきである。

—

5. 結び：型システムはランタイムの現実を映す鏡

TypeScriptの型システムは、JavaScriptという動的言語のランタイム上で、静的な美しさと安全性を維持するための極限の抽象化レイヤである。

関数の引数における反変性は、単なる「めんどくさいコンパイルエラーの発生源」ではない。それは、「関数が依存する外部世界との契約を、より広い世界への適応性によって守る」という、オブジェクト指向および関数型プログラミングにおける不変の真理をコードに定着させるための防壁なのだ。

この変性のメカニズムを脳内へ完全にロードし、コンパイルエラーを敵ではなく「極めて優秀な数理論理学者からの助言」として捉えられるようになった時、あなたの書くTypeScriptコードは、一級品の堅牢性を手に入れることになる。