contextual 文脈的型付け
最終更新：2026-10-22
contextual 文脈的型付け
文脈的型付け：関数リテラルが「型が既知の位置」（変数注釈、配列メソッドのコールバック、イベントハンドラ）に現れると、TS はそのパラメータ型を逆算します——注釈を手書きする必要はありません。map((o) => o.id) の o に型が付くのは、関数自体からの推論ではなく、配列の要素型という「文脈」から来ています。
| グループ | 関数とクラス |
|---|---|
| 種類 | 構文 |
| strict モード | 不要 |
ℹ️ 説明 エディタは TypeScript を JavaScript にトランスパイルして実行します（型チェックなし）。型チェック結果は各サンプルの出力を参照してください。
📝 構文
const orders: Order[] = [];
// コールバック引数 o は orders の要素型から文脈型 Order を得る
const summaries = orders.map((o) => `#${o.id}: ${o.total}`);
// 変数への注釈も文脈を提供する
type ClickHandler = (event: { x: number; y: number }) => void;
const onClick: ClickHandler = (event) => console.log(event.x, event.y);⚙️ パラメータ
| const x: T = ... | 文脈的推論が発動する場面：変数やパラメータの型注釈、配列の要素、関数の実引数（仮引数の型に対応）、return 式（宣言された戻り値型に対して） |
|---|---|
| (x) => ... | 注釈のないコールバックパラメータは文脈から型を受け取ります。明示的な注釈を書く場合は文脈と互換でなければエラーになります |
戻り値：return 式も同じく文脈の制約を受けます。宣言された戻り値型が各 return を逆方向から検査し、「分岐の return を1つ書き忘れた」ようなミスを早期に捕まえます。
▶ サンプル
下のコードを編集して「試す」を押すと、トランスパイル実行結果を確認できます：
出力：
#101: 250, #102: 90, #103: 480
2
click @ 12,34
（トランスパイル後の実行出力。コールバック内で o.pric（打ち間違えたプロパティ名）と書くと即座にコンパイルエラーになります——文脈の型が許さないためです）💡 ポイント
ℹ️ 説明 文脈的推論は「外から内へ」の型の流れで、通常の推論（式から変数へ）と方向が逆です。両者が同時に存在する場合、明示的な注釈を持つ側が勝ちます。
💡 ヒント コールバックパラメータに「暗黙の any」と赤線が出るのは、たいてい文脈が欠けている（配列に型が付いていない）せいです。コールバックに注釈を足すのではなく、外側の型を先に直しましょう。
⚠️ 注意 React の onChange={(e) => ...} のようなコールバックは文脈の型に依存します。useCallback で包むなどして別途切り出したら、型注釈は自分で補う必要があります。そうしないとパラメータは any に落ちます。
🏷️ 関連関数とクラス
💡 関連ケース
ケースは今後追加予定です。
❓ よくある質問
Q 文脈的型付けと型推論は同じものですか？
A 違います。通常の推論は「値から型へ」（const x = 5 → number）。文脈的型付けは「位置から値へ」——まず目標の型が分かっていて、関数リテラルのパラメータ型がそこから逆向きに流れます。コールバックパラメータの型はほぼすべて後者から来ます。
Q map のコールバックパラメータが any になるのはなぜですか？
A 配列自体に型がないためです（JSON.parse 由来や注釈漏れなど）。文脈から借りられる型がなく、コールバックパラメータは暗黙の any になります。配列に要素型を注釈すれば直ります。
Q 文脈的型付けはエラーを「見逃し」ますか？
A まったく逆です——文脈的型付けは検査の根拠です。文脈の型に存在しないプロパティにコールバック内でアクセスすると即座にエラーになります（余分なフィールドも同じ）。プロパティ名の打ち間違いを防げるのはまさにこのためです。
