TypeScriptの型システムにおける虚無の解剖学：`void`と`undefined`の深層とランタイムの真実
TypeScriptの型システムを表面的な「構文チェッカー」としてのみ捉えているうちは、真に堅牢なアーキテクチャに到達することはできない。型は単なる開発支援ツールではなく、コンパイル時におけるコードの振る舞いを規定する契約であり、ランタイムの最適化を見据えた静的証明の結晶である。
今回は、関数型における`void`と`undefined`という、一見して類似した、しかし型システムとランタイムの双方において全く異なる意味を持つ2つの「虚無」の差異にメスを入れる。
特に、「コールバック関数の戻り値が `void` の場合、なぜ値を返しても型エラーにならないのか」という、多くのシニアエンジニアすら誤解しがちなTypeScriptの仕様の裏側を、コンパイラの型評価プロセス、V8エンジン等のランタイムメモリモデル、そしてイベントループの文脈から徹底的に剥ぎ取っていく。
—
1. 概念の根底：`void` は「値の不在」ではなく「無視の契約」である
まず、TypeScript（およびJavaScript）における `undefined` と `void` の本質的な違いを定義する。
- `undefined`: 実際に存在するプリミティブな値であり、メモリ上にスロット（あるいはレジスタ上の表現）を占有しうる。型としては「`undefined` という値しか取り得ない単一の型（Unit Type）」である。
- `void`: 型システム上のメタ概念であり、「この関数の戻り値は呼び出し元によって意図的に無視される」という契約（Contract）を示す。
ランタイムにおいて、JavaScriptの関数は何も返さない場合、自動的に `undefined` を返す。しかし、TypeScriptの型定義における `void` は、単に `undefined` の別名ではない。ここにTypeScript特有の柔軟性と、コールバック設計におけるパラダイムの妙がある。
—
2. なぜ `void` なのに値を返せるのか？——型安全性の意図的な緩和
次のコードを見てほしい。直感的にはエラーになりそうだが、TypeScriptのコンパイラはこのコードを完全に合法として通過させる。
type LoggerCallback = (message: string) => void;
// 戻り値として string を返しているが、型エラーにならない
const logAndReturn: LoggerCallback = (msg) => {
console.log(msg);
return `Logged: ${msg}`; // ⚠️ string を返しているにもかかわらずコンパイル通る
};
なぜこの「型矛盾」が許容されるのか。これはバグではなく、TypeScriptチームが設計した意図的なサブタイピングのルールによるものである。
コールバックの代入性（Assignability）と変性の罠
JavaScript/TypeScriptエコシステムにおいて、既存の関数やライブラリのコールバックとして、`Array.prototype.forEach` のような「戻り値を期待しない関数」に、`Array.prototype.push` のような「意図せず戻り値（この場合は数値の配列長）を返す関数」を渡すケースは極めて多い。
const items: number[] = [1, 2, 3];
const results: number[] = [];
// forEach が期待するコールバックは (value: number, index: number, array: number[]) => void
// しかし push は (item: number) => number (配列の新しいlengthを返す)
items.forEach((item) => results.push(item 2));
もしTypeScriptが「戻り値の型が `void` の場所には、厳密に `void`（あるいは `undefined`）を返す関数しか代入できない」という制約を課した場合、上記の一般的なイディオムはすべてコンパイルエラーになる。
そのため、TypeScriptの型システムでは、「戻り値の型が `void` である関数型（ターゲット）に対して、任意の戻り値を持つ関数（ソース）を代入できる」という特別なバイパス規則が存在する。
> コンパイラの挙動:
> 戻り値の型位置（Covariantの位置）において、ソース関数の戻り値は `void` に対して割り当て可能（Assignable）とみなされる。これにより、ソース関数が何を返そうとも、呼び出し元がその戻り値を捨てることが保証されていれば、型安全性の破壊とは判定されない。
—
3. 「落とし穴」：コンテキストによる振る舞いの変化
ただし、この「`void` にはどんな値でも返せる」というルールの適用範囲には厳密な境界線がある。関数定義の直接の書き方（Contextual Typing）と、型注釈（Type Annotation）の有無によってコンパイラのチェックレベルが変わるのだ。
ケースA：型注釈が明示された変数への代入（前述のケース）
先ほどの例の通り、戻り値の型が `void` と明示された型定義にアロー関数を代入する場合、値を返すことは許容される。
ケースB：オブジェクトリテラルや高階関数の直接引数（厳密チェック）
一方で、次のように直接コールバックを渡す場合や、メソッド定義においては挙動が異なる場合がある。
function executeTask(task: () => void) {
task();
}
// これは許容される（コールバックの戻り値の無視）
executeTask(() => {
return “Task completed”;
});
しかし、もし関数側が `undefined` を明示的に要求している場合はどうなるか。
function executeStrictTask(task: () => undefined) {
task();
}
// ❌ コンパイルエラー: Type ‘string’ is not assignable to type ‘undefined’.
executeStrictTask(() => {
return “Task completed”;
});
ここで `void` と `undefined` の決定的な断絶が露わになる。
- `() => void`: 「何を返してもいい（ただし呼び出し元は受け取って利用してはならない）」
- `() => undefined`: 「厳密に `undefined` しか返してはならない」
—
4. 低レイヤ・ランタイムへの影響：V8エンジンとイベントループの視点
「戻り値を捨ててもいい」というTypeScriptの型システム上の都合は、実行時（JavaScriptエンジン）においてどのような意味を持つのか。
1. 隠しクラス（Hidden Classes / Shapes）とインラインキャッシュ（IC）
V8などのモダンJSエンジンは、関数の戻り値の型が静的に予測できない場合、インラインキャッシュの最適化をダウングレードさせることがある。しかし、TypeScriptの `void` はあくまで静的な型アサーションに過ぎず、コンパイル後のJavaScriptコードには型情報は一切残らない。
つまり、TypeScript上で `void` を返す関数内で値を返していたとしても、JavaScriptのランタイムとしては普通にその値をスタック/レジスタに載せてリターンしている。
// コンパイル後のJavaScript
var logAndReturn = function (msg) {
console.log(msg);
return “Logged: ” + msg; // ランタイムでは実際に値が返されている
};
呼び出し元がその戻り値を変数に代入していなければ、JITコンパイラの死体コード削除（Dead Code Elimination）や最適化パスによって、返された値は適切に破棄される。メモリリークの懸念はないが、「不要な値の生成と破棄のオーバーヘッド」がミリ秒単位の極限領域で発生しうる。
2. 非同期イベントループとプロミスチェーンにおける潜在的バグ
セキュリティや高スループットが要求されるバックエンド（Node.js / Bun）のアーキテクチャにおいて、この「`void` の寛容さ」は致命的なバグの温床となる。
次の非同期コールバックのインターフェース設計を見てほしい。
type AsyncActionHandler = () => Promise
// 意図せず Promise
const maliciousOrBuggyHandler: AsyncActionHandler = async () => {
const token = await fetchSecureToken();
return token; // Promise
};
もし、このハンドラーを呼び出す側が以下のように実装されていたらどうなるか？
async function processQueue(handler: AsyncActionHandler) {
// 呼び出し元は void を期待しているため、返り値をawaitしない
handler();
console.log(“Queue processed”);
}
もし `handler` が内部で非同期エラー（未処理の例外）をスローした場合、`Promise
TypeScriptの型システムが「戻り値の差異」を寛容に許した結果、非同期文脈におけるエラーバウンダリの契約が破られ、システムの堅牢性が損なわれる典型例である。
—
5. アーキテクトが実践すべき「型防壁」の構築
こうした言語仕様の「甘さ」からコードベースを守り、真の型安全性を担保するために、チーフアーキテクトとして以下の設計指針を徹底すべきである。
指針1: コールバックの戻り値には `void` を避け、厳密な制約が必要な場合は `undefined` を使う
もしコールバックの呼び出し元が「戻り値を一切利用しないこと」を強制したい、あるいは非同期処理の完了を完全に制御したい場合は、曖昧な `void` ではなく、明示的な `undefined` や具体的な型を指定する。
// 厳格な設計: 戻り値を返すことを一切許さない
type StrictCallback = () => undefined;
指針2: `noImplicitReturns` および `strictNullChecks` の極限活用
`tsconfig.json` において、以下のフラグは妥協なく有効化されていなければならない。
{
“compilerOptions”: {
“strict”: true,
“strictNullChecks”: true,
“noImplicitReturns”: true,
“noUncheckedIndexedAccess”: true
}
}
これにより、意図しない値の混入や、コードパスの抜け落ちをコンパイル時に完全に封鎖する。
—
結論：型は「道徳」ではなく「物理法則」であれ
TypeScriptの `void` が持つ「値を返してもよい」という仕様は、JavaScriptの歴史的遺産と開発者の利便性を繋ぐための「寛大な橋渡し」である。しかし、アーキテクチャの高度化、セキュリティの厳格化が求められる最前線においては、この橋渡しが時として脆弱性の隙間となり得る。
言語の仕様の裏側にあるコンパイルの意図とランタイムの現実を完全に掌握し、記述したコードがCPUとメモリ上でどう解釈されるかまでを透視すること。それこそが、真にコードを支配するエンジニアの境地である。