TypeScript以外の3つの型システム

TypeScriptはJavaScriptに型を付ける標準的な手段ですが、唯一の選択肢ではありません。少数の型アノテーションを得るためだけに小規模プロジェクトにビルドステップを追加したり、tscが大規模なコードベースを延々と処理するのを眺めたりした経験があるなら、型安全性をより軽量に実現する方法があるのではないかと疑問に思ったことがあるでしょう。実際にあります。しかも一つだけではありません。

2026年時点でTypeScript以外のJavaScript向け型システムとして最も信頼性が高いのは、JSDocと// @ts-check、ReScript、そしてFlowの3つです。それぞれ、ビルドステップなしで型チェックを実現するもの、TypeScriptより強い保証を提供するもの、既存コードのメンテナンス目的でのみ採用するレガシーチェッカーという位置付けです。「TypeScriptの代替」特集でよく挙げられるその他の選択肢（Deno、Dart、Kotlin/JS）は、JavaScriptに重ねる型システムではなく、ランタイムまたはクロスプラットフォーム言語です。

本記事は、すでにTypeScriptを知っている開発者向けの比較調査です。言語かチェッカーか、ビルドステップの有無、TypeScriptの意図的な不健全なモデルに対する健全性、そして現時点でのエコシステムの状況といったトレードオフを率直に解説します。

2026年における3つの真のTypeScript代替

「JavaScriptの型システム」として真に機能するものは、JavaScriptソースの型をチェックする（チェッカーまたはアノテーション層）か、型付き言語をJavaScriptにコンパイルするかのいずれかです。この定義に該当するのは、JSDoc+@ts-check、ReScript、そしてFlowです。Deno（TypeScriptを実行できるランタイム）、DartおよびKotlin/JS（複数のバックエンドのひとつとしてJavaScriptをターゲットにする独立した言語）は除外されます。これらは知っておく価値はありますが、別の問いに答えるものです。

基準となる文脈として：2026年半ば時点で、TypeScript 7.0が現在の安定版リリースです。2026年7月8日にリリースされたこのバージョンは、コンパイラのネイティブGoポートであり、Microsoftによればフルビルドでは通常TypeScript 6.0比8〜12倍高速です。TypeScript 6.0は旧JavaScriptコードベースで構築された最後のリリースであり、7.0はその型チェックの動作を継承しています。一点注意すべきギャップがあります：7.0は安定したプログラマティックAPIなしでリリースされたため、Vue、Svelte、Angularのテンプレート型チェック用ツールはTypeScript 7.1（2026年10月頃リリース予定）を待つ必要があります。これは以下で説明するJSDocへの影響にも関わるため、念頭に置いておいてください。

JSDoc + @ts-check：ビルドステップなしのTypeScript型システム

概要： JSDocベースの型付けを使うと、プレーンな.jsファイルに構造化されたコメントでアノテーションを付け、TypeScriptとまったく同じエンジン——TypeScript言語サービス——を使って型チェックを行えます。これはドキュメント生成ツールとしてのJSDocとは異なります。ここではアノテーションが型チェックを駆動します。TypeScriptハンドブックの--checkJsは、TypeScript 2.3以降で利用可能な、.jsファイルのエラーを報告するフラグとして文書化されています。

採用方法： ファイルの先頭にコメントを1行追加するか、プロジェクト全体に対してtsconfigの2つのフラグを切り替えます。VS CodeのJavaScriptドキュメントでは、// @ts-checkをプロジェクト全体で有効化せずに一部のファイルだけチェックする方法として紹介しています。

// @ts-check

/**
 * @typedef {{ id: number, name: string }} User
 */

/**
 * @param {User} user
 * @returns {string}
 */
function greet(user) {
  return `Hi, ${user.name}`;
}

プロジェクト全体に適用する場合は、ファイルごとのコメントは不要です：

{
  "compilerOptions": {
    "allowJs": true,
    "checkJs": true
  }
}

JSDocの型は消去可能なコメントであるため、ファイルはコンパイルステップなしで任意のブラウザやランタイム上で標準的なJavaScriptとして動作します。これが1ファイルずつ段階的に採用できる理由でもあります。トレードオフとして、TypeScriptのモデル（意図的な不健全性を含む）をそのまま引き継ぎ、アノテーション構文が.tsより冗長になります。7.0時代における注意点として：MicrosoftはTypeScript 7.0に向けてJavaScriptの型チェックをゼロから書き直し、一部のあまり使われていないタグを削除しました。そのため、TypeScript 7.0は@enumおよび@constructorタグを認識しません。

採用すべき場面： 既存のJavaScriptコードベースまたはプレーンJSを配布するライブラリに対して、ビルドステップなしでインクリメンタルに型安全性を導入したい場合。

ReScript：健全で公称型、完全推論の型システム

概要： ReScriptは、アノテーション層ではなく、OCamlから継承した型システムを持つ独立したJavaScriptコンパイル言語です。TypeScriptの型システムは意図的に不健全です——JavaScriptのランタイムセマンティクスとの互換性を保つために、一部の誤ったプログラムを受け入れます。ReScriptはまさにそのギャップを埋めます：完全に推論され、プロジェクトの言葉を借りればanyなし、マジック型なし、予期しないundefinedなしです。TypeScriptの構造的型付け（適切な形状を持つオブジェクトであれば型を満たす）とは異なり、ReScriptのレコードとバリアントは公称型であるため、構造的に同一の2つの型は明示的に宣言しない限り互換性がありません。

採用方法： コンパイラをインストールし、rescript.jsonを設定します。これはReScriptプロジェクトに必要な唯一の必須ビルドファイルです（ReScript 11より前のバージョンではbsconfig.jsonでした）。2025年11月25日にリリースされたReScript 12ではbsconfig.jsonのサポートが完全に削除され、モジュール出力のデフォルトがESモジュールになりました。

{
  "name": "my-app",
  "sources": { "dir": "src", "subdirs": true },
  "package-specs": { "module": "esmodule", "in-source": true },
  "suffix": ".res.js"
}

生成されるJSファイルのサフィックスは自由に選択できます。チームは.res.jsまたは.res.mjsを推奨しており、公式のcreate-rescript-appテンプレートでもこれが使用されています。最小限のモジュール例：

let add = (a: int, b: int): int => a + b
let result = add(1, 2)
Console.log(result)

コストは現実的なものです：独自の構文を持つ別言語であり、JavaScriptライブラリを使用するためのインターオペラビリティバインディングを記述する必要があり、エコシステムはTypeScriptよりはるかに小規模です。ただし、ReScriptは段階的な採用を念頭に設計されています——プレーンなJavaScriptに戻したくなった場合は、ソースファイルを削除してクリーンなJavaScript出力をそのまま使い続けられます。

採用すべき場面： 可能な限り強力な型保証を求め、単なるアノテーションではなく言語そのものにコミットする意思があるグリーンフィールドプロジェクト。

Flow：現役だが、ほぼ時代遅れ

概要： FlowはJavaScript向けのオープンソース静的型チェッカーで、Facebook/MetaによってOCamlで構築されました。FlowもReScriptもOCamlに由来しますが、現在の採用状況は対照的です。Flowはチェッカーであり言語ではありません——.jsファイルにアノテーションを付け、// @flowでマークし、ビルド時にBabelで型を除去します。

// @flow
function add(a: number, b: number): number {
  return a + b;
}

2026年における採用の実態： Flowは数百万ファイルのJavaScriptおよびReactコードを持つMeta社内では本番環境で現役ですが、外部エコシステムは大幅に縮小しています——ライブラリ定義、チュートリアル、ツールのいずれもTypeScriptより乏しい状況です。Meta関連の主要プロジェクトのFlowからTypeScriptへの移行はコミュニティで議論されていますが、具体的な計画を確認できる一次情報はありません。「Flowには明るい未来がある」という古い比較記事は時代遅れと見なしてください——勢いはすでに数年前にTypeScriptへ移っています。

採用すべき場面： 現実的には、既存のFlowコードベースをメンテナンスする場合のみです。新規プロジェクトには他の2つの選択肢の方が適しています。

結論：状況に合ったツールを選ぶ

ビルドツールなしでインクリメンタルな型付けを行い、プレーンなJavaScriptとの完全な互換性を維持したい場合は、**JSDocと@ts-check**を選んでください。最も活用されておらず、かつ最も実用的な選択肢です——TypeScript自身のチェッカーを.jsファイルに向けるだけです。新規プロジェクトで最大限の型健全性を求め、独立した言語とインターオペラビリティバインディングというコストを受け入れられるなら、ReScriptを選んでください。Flowは、すでにFlowで書かれたコードのメンテナンス目的のみに留めてください。今すぐJavaScriptを離れずに型安全性を得たいなら、1つのファイルに// @ts-checkを追加して、エラーが浮かび上がるのを確認してみてください。

よくある質問

TypeScriptを依存関係としてインストールせずにJSDoc型チェックを使用できますか？

VS CodeのようなエディタにはTypeScript言語サービスが組み込まれているため、.jsファイルに// @ts-checkを追加するだけで、npm installなしで型チェックが利用できます。コマンドラインやCIで同じチェックを実行するには、typescriptパッケージをインストールし、allowJsとcheckJsを有効にしてtscを実行します。型はJSDocコメントに記述されるため、どちらの場合も配布するJavaScriptには何も追加されません。

TypeScriptの構造的型付けとReScriptの公称型付けの違いは何ですか？

TypeScriptが採用する構造的型付けでは、適切な形状を持つオブジェクトであれば型を満たすと見なされるため、フィールドが同一の無関係な2つの型は互換性があります。ReScriptのレコードとバリアントは公称型であり、構造的に同一であっても、明示的に関係を宣言しない限り別の型として扱われます。公称型付けは見た目が似た型の誤った代入を防ぎます。これがReScriptの型システムが健全で、TypeScriptが意図的に不健全である理由の一つです。

なぜDenoはこの比較でTypeScriptの代替として扱われないのですか？

DenoはJavaScriptとTypeScriptのランタイムであり、JavaScriptに重ねる型システムではありません。TypeScriptコンパイラをバンドルすることでTypeScriptを直接実行するため、TypeScriptに依存しており、TypeScriptを置き換えるものではありません。真の代替は、JavaScriptソースの型をチェックするか、型付き言語をJavaScriptにコンパイルする必要があります。同じ理由で、複数のコンパイルバックエンドのひとつとしてJavaScriptをターゲットにする独立した言語であるDartとKotlin/JSも除外されます。

TypeScript 7.0への移行で既存のJSDoc型付きJavaScriptプロジェクトは壊れますか？

ほとんどの場合は問題ありませんが、GoベースのTypeScript 7.0はJavaScriptの型チェックをゼロから書き直し、一部のあまり使われていないJSDocタグ——具体的には7.0で認識されなくなった@enumと@constructor——を削除しました。これらのタグに依存しているプロジェクトはサポートされているパターンへの移行が必要です。@param、@returns、@typedef、@templateなどの一般的なタグは引き続き動作するため、ほとんどのJSDoc型付きコードベースはそのまま移行できます。TypeScript 7.0は2026年7月から安定版としてリリースされているため、プロジェクトを実際に動かして差分を確認してください。