コードレビュー：その「凡庸な高階関数」が、チームの生産性を殺している
先日のプルリクエストで、次のようなコードを見かけた。
// 良くある汎用的なマップ関数（一見問題なさそうだが……）
function processItems
return items.map((item, index, array) => callback(item, index, array));
}
「配列の要素とインデックスを同時に扱えて便利だな」と思っていないか？
実務の現場において、この甘えが予期せぬバグの温床になる。例えば、JavaScriptの組み込みメソッドである `Array.prototype.map` や `Array.prototype.forEach` に渡すコールバック関数を、そのまま別の高階関数に流し込んだときだ。
const numbers = [‘1′, ’10’, ‘100’];
// parseInt(string, radix) なのに、map が (value, index, array) を渡してしまう！
const result = numbers.map(parseInt);
// 期待値: [1, 10, 100]
// 実際の挙動: [1, NaN, 2] （indexがradix（基数）として渡されてしまうため）
TypeScriptの型システムは強力だが、「関数を引数に取る関数（高階関数）」の設計を誤ると、意図しない余分な引数（スパゲッティな引数コンテキスト）がすり抜けてしまい、実行時エラーやサイレントバグを引き起こす。
今回は、引数に渡す「関数」の許容する引数の数を厳格に制限し、高階関数の汎用性と安全性を極限まで高めるためのTypeScript型パターンの実践知を伝授する。
—
なぜ「引数の数の制限（Arity Control）」が必要なのか？
TypeScriptにおける関数型は、構造的型付け（Structural Subtyping）のルールに従う。つまり、「受け取る側が要求する引数の数よりも、渡す側の引数の数が少ない（あるいは同じ）」であれば代入可能という性質を持つ。
type UnaryFunc = (arg: string) => void;
// 1引数の関数を要求する場所へ、0引数の関数を渡すのはOK（引数が捨てられるため）
const zeroArg: () => void = () => {};
const fn: UnaryFunc = zeroArg; // TypeScriptではエラーにならないケースがある
しかし、逆は違う。2つ以上の引数を受け取る関数が、1つしか引数を欲していないコンテキストに渡された場合、前述の `parseInt` のような悲劇が起きる。
「単一のデータに対して純粋な変換を行いたいだけなのに、インデックスや配列全体といった文脈（Context）に依存したコードが書けてしまう」という状態を型レベルでコンパイルエラーにすることこそ、チーフアーキテクトが目指すべき堅牢な設計だ。
—
実装パターン：引数の数を制限するユーティリティ型
それでは、特定の引数の数（Arity）を持つ関数のみを受け付ける型制約を実装しよう。
ここでは、「引数をちょうど1つだけ取る関数」を強制するパターンを構築する。
1. 厳密な引数数制限のプロダクションコード
以下のコードは、フロントエンドのデータフェッチや、複雑な状態管理のパイプライン処理でそのまま使える実用的な設計である。
/
- 厳密に N 個の引数を持つ関数型を定義するためのヘルパー型
- パラメータのタプル長（`length`）を制約する
/
type ExactParameters
Parameters
? P[‘length’] extends N
? F
: never
: never;
/
- 1つの引数のみを受け取る関数型
/
type UnaryFunction
/
- 高階関数の安全なラッパー
- @template T 入力データの型
- @template F コールバック関数の型（必ず1引数でなければコンパイルエラー）
/
function safeMap
items: T[],
// 2つ以上の引数を持つ関数（例: (item, index) => …）を渡すと、型エラーを起こす
callback: ExactParameters
): ReturnType
// 実行時には余計な引数が渡らないよう、安全に1引数のみで実行する
return items.map((item) => callback(item));
}
// ==========================================
// 使用例と型評価の検証
// ==========================================
const rawData = [‘apple’, ‘banana’, ‘cherry’];
// OK: 引数が1つのアロー関数
const res1 = safeMap(rawData, (fruit) => fruit.toUpperCase());
// OK: 1引数の既存関数
const capitalize = (s: string) => s.toUpperCase();
const res2 = safeMap(rawData, capitalize);
// ❌ NG: 引数が2つ（item, index）の関数を渡した場合
// コンパイルエラー: Type ‘…’ is not assignable to type ‘never’.
/
const res3 = safeMap(rawData, (fruit, index) => {
return `${index}: ${fruit}`;
});
/
// ❌ NG: 組み込みの parseInt をそのまま渡した場合（indexが混入するため防止できる）
// コンパイルエラーになるため、ラッパーを書く強制力が生まれる
/
const res4 = safeMap([‘1’, ‘2’, ‘3’], parseInt);
/
—
コードの解説：なぜこの型はコンパイル時に機能するのか？
1. `Parameters
関数 `F` の引数の型をタプル（配列型）として抽出する。
2. `P[‘length’] extends N` による条件分岐:
TypeScriptのタプル型は `.length` プロパティを持ち、その値は数値のリテラル型（例: `1`, `2`）として評価される。これを利用して、引数の数が厳密に `N` と一致するかを判定する。
3. `never` への収束:
条件に一致しない場合、型を `never` に落とし込むことで、TypeScriptの関数オーバーロードや型制約において「代入不可能な型」に変換し、コンパイルエラーを発生させる。
このアプローチにより、開発者がうっかり `index` や `array` を引数に取るコールバックを記述した瞬間、IDE上で即座に赤線（Type Error）が引かれるようになる。
—
パフォーマンス上の注意点とコンパイラ負荷
TypeScriptの高度な型操作（conditional typesやinfer、タプル操作）は、IDEの言語サーバー（tsserver）やビルド時のコンパイラに負荷をかける。
- 過剰な型メタプログラミングの弊害:
何層もの複雑なジェネリクスをネストさせると、型チェックの時間が数秒単位で伸び、開発体験（DX）が著しく悪化する。
- 実務でのトレードオフ:
今回紹介した `ExactParameters` のようなユーティリティ型は、「アプリケーションの根幹を支える共通ライブラリ」や「デザインシステムのプリミティブな関数」に限定して適用するのがベストプラクティスだ。すべてのコンポーネントの内部関数に適用するのは過剰設計（Over-engineering）おそれがある。
—
チーフアーキテクトからの提言
「動けばいい」というコードは、チームの人数が10人を超えた瞬間、あるいはコードベースが半年経過した瞬間に負債へと変わる。
特に高階関数は、呼び出し側と定義側の距離が離れがちであり、予期せぬ引数の伝播によるバグは見つけにくい。型システムを単なる「静的な型チェックツール」としてではなく、「チーム全体で守るべきアーキテクチャの制約（ガードレール）」として使いこなせ。
明日のコードレビューでは、チームメンバーが書いた高階関数の引数型を一度見直してみてほしい。不要な引数を受け入れる隙を与えていないか、その型は本当に安全を担保しているか――。
妥協のない型設計こそが、スケールするプロダクトを支える唯一の道である。