GHC 9.14とは？初のLTS版の新機能・非互換な変更と移行判断【9.14.1／9.14.2 RC】

GHC 9.14は、Glasgow Haskell Compiler（GHC）で初めて長期サポート（LTS）に指定された系列です。正式版の9.14.1は2025年12月19日に公開され、2026年11月7日時点でも、不具合修正版の9.14.2はリリース候補（RC2、9月17日公開）のままで、予定の10月初めから1か月以上遅れています。本記事では、9.14で何が変わったか、9.12から上げるときにどこで壊れるか、そして今どの版を選ぶべきかを、GHCのリリースノートと公式告知、手元でのコンパイル結果をもとに整理します。

まとめ：GHC 9.14の要点と選び方

• 位置付け：GHC初のLTS系列。少なくとも2028年初めまで保守の予定（LTS方針は最低2年・目標3年）。LTSには新機能をバックポートしない
• 版の状況：9.14.1が2025年12月19日公開。9.14.2はRC2（2026年9月17日）のまま未公開（2026年11月7日時点）。並行する9.12.5は11月6日にRC4が出て、正式版は11月17日の週の予定。9.12系はこれが最後
• 主な新機能：SPECIALISEプラグマに式を書ける、データ構築子での可視forall、Explicit Level Imports、GHCiデバッガの:stepout、WebAssemblyバックエンドでのGHCiとTemplate Haskell
• 壊れやすい変更：-Wallに-Wincomplete-record-selectorsが入り、-Werrorのビルドが落ちる（回避は-Wno-error=incomplete-record-selectors。リリースノートの綴りは通らない）。DataKinds無しで昇格した型をカインドに使うとエラーになる
• 周辺ツール：GHCupの推奨は9.10.3（9.14.1はLatest扱い）。Stackageの最新LTS（lts-24.66）は9.10.3、nightlyは9.12.4。HLS 2.15.0.0は9.14.1に対応
• 選び方：新規の長期案件は9.14系を選び、本番投入は9.14.2を待つ。Stackage LTSに乗っている案件は、Stackageが9.14系のLTSを出すまで9.10.3のままでよい

GHC 9.14の位置付けとリリース状況

LTS（長期サポート）の中身とサポート期間

GHC開発チームは2025年7月7日のブログ「GHC LTS Releases」で、LTS系列を設ける方針と、その最初が9.14であることを公表しました。中身は次の3点です。

• LTS系列には少なくとも2年マイナーリリースを出し、実際には3年を目標にする
• LTS系列へは、初回リリース後に新機能をバックポートしない方針（ただし9.14.2にもGHCi・GHC API向けの小さな追加や、-jsemのプロトコル変更が含まれる）
• 次のLTS系列とは6か月サポート期間を重ねる。LTS以外の系列は従来どおり約6か月ごとに出し、サポート期間はやや短くする

これまでは、利用者が多い版の保守を開発チームが非公式に延ばす「後付けのLTS（post-hoc LTS）」状態でした。どの版が長く保守されるかが事前に分からず、外れた版を選んだ利用者は早めの更新か、保守終了後の不具合を抱えるかの二択になっていました。9.14以降は、長期案件なら最初からLTS系列を選べます。

ブログの想定日程は「2025年8月に9.14公開」でしたが、実際の9.14.1は2025年12月19日でした。具体的な期限については、GHC開発チームのAndreas Klebinger氏（LTS方針ブログの著者）が2026年6月9日のDiscourse投稿で「9.14は少なくとも2028年初めまで保守し、リソース次第でそれより長くしたい」と述べています。同じ投稿は、次の主要版10.0のサポート期間を「長くても1年」と見込み、9.12と9.10は次のリリースを最後にする計画も示しています。終了日は公式に確定していないため、GHC WikiのGHC versions: downloading and statusで状況を確認してください。

9.14系のリリース履歴と9.14.2の遅れ

9.14.2-rc1の告知は「8月13日の週に正式版」、RC2の告知は「10月1日の週」としていましたが、どちらも過ぎています。downloads.haskell.org/ghc/9.14.2/は2026年11月7日時点で404で、GitLabにもghc-9.14.2-releaseタグはありません。遅れの理由について、リリース担当のMangoIV氏は10月16日のDiscourse投稿で「不具合の報告が大量に寄せられ、9.14.2と9.12.5の両方に多くの修正を入れた。どちらもあと1件のパッチ待ち」と説明しています。RCでの退行は無かったとも書いています。

先行する9.12.5は、2026年11月6日にRC4が出ました。告知は「重大な退行が見つからなければ最後のRC」「2週間の試験期間を経て11月17日の週に正式版」としており、9.12.5は9.12系の最後のリリースです。9.14.2はその後に続く見込みですが、日付は告知されていません。9.14.1に同梱される主なライブラリは、base 4.22.0.0、Cabal 3.16.0.0、containers 0.8、bytestring 0.12.2.0です。

GHCup・Stackage・HLSでの扱い

GHC本体の公開と、周辺ツールが既定でその版を選ぶかは別の話です。2026年11月7日時点の状況は次のとおりです。

GHC Wikiは、Stackageが「通常はX.Y.2を待ってから主要版をLTSにする」と説明しています。このため、9.14.2の正式版が出るまでStackage LTSに9.14系は載らない見込みで、9.14.2の遅れはStackage LTSへの採用時期にも影響し得ますが、正式版の公開だけで採用時期が決まるわけではありません。GHCupで9.14系を入れるには、ghcup install ghc 9.14.1 のように版を明示します。

GHC 9.14の主な新機能

SPECIALISEプラグマの式・型適用への対応

GHC Proposal 493の実装により、SPECIALISEプラグマに任意の式を書けるようになりました。型適用（@Int）で型を固定するだけでなく、引数の値まで固定した特殊化を作れます。

power :: Num a => Bool -> Int -> a -> a
power neg n x = if neg then x else go n
  where go 0 = 1
        go k = x * go (k - 1)

-- 9.14から：型と引数の値を指定して特殊化
{-# SPECIALISE power @Int False #-}

一方で、1つのプラグマにカンマ区切りで複数の型シグネチャを並べる書き方（{-# SPECIALISE g :: Int -> Int, Float -> Float #-}）は非推奨になり、9.18で削除予定です。この警告は新設の-Wdeprecated-pragmasが担い、既定で有効です。手元の9.14.1でカンマ区切りの書き方をコンパイルすると、[GHC-73026] [-Wdeprecated-pragmas] の警告と「Split the SPECIALISE pragma into multiple pragmas, one for each type signature」という修正案が出ます。1シグネチャ1プラグマに分ければ消えます。

効果のない特殊化を知らせる-Wuseless-specialisationsも追加されました。なお、型変数を含む既知の辞書への呼び出しを特殊化する-fpolymorphic-specialisationは、利用者ガイドが「誤った実行結果を招きうる実験的機能」（#23469ほか）としており、9.14.1でも既定で無効です。9.14.1では関連する誤コード生成（#26329）が修正されましたが、既定で有効になるのはGHC 10.0からです（#23559）。9.14で付ける場合は、ガイドが自己責任としている点に注意してください。

RequiredTypeArgumentsの拡張とExplicit Level Imports

RequiredTypeArgumentsで、データ構築子の型にも可視なforall（forall a ->）を書けるようになりました（GHC Proposal 281の4.7節）。型を値と同じ位置で明示的に渡す書き方が、関数だけでなくGADTの構築子でも使えます。

{-# LANGUAGE RequiredTypeArguments #-}
data T a where
  Typed :: forall a -> a -> T a

ExplicitLevelImports拡張は、Template Haskellで使うimportに「どのレベルで使うか」を付ける機能です。import splice Mはスプライス内（コンパイル時に実行）用、import quote Mはクオート内用、修飾なしは通常のコード用になります。

{-# LANGUAGE TemplateHaskell, ExplicitLevelImports #-}
import splice Control.Lens.TH (makeLenses)
import OtherModule (someFunction)

従来は、スプライスがどのimportを使うか事前に分からないため、GHCはすべてのimport先をコンパイルしてから型検査を始める必要がありました。レベルを明示すれば、スプライスで使うモジュールだけをコンパイル時に用意すればよくなります。ただしExplicitLevelImportsはNoImplicitStagePersistenceを含意するため、スプライス内でPreludeの関数を使う場合もimport splice Prelude (map)のように明示が必要です（上の例は利用者ガイドの例で、lensパッケージを前提にしています）。

リリースノートにある小さな言語変更5つ

大きな機能のほかに、既存の拡張の挙動が変わる項目が9.14.1のリリースノートに並んでいます。どれも既存コードを壊す変更ではなく、書けることが増える方向の変更です。

MonadComprehensionsは、本来の設計どおりParallelListCompを含意するようになりました。9.14.1では次のコードがMonadComprehensionsの指定だけでコンパイルでき、実行すると[(1,'a'),(2,'b'),(3,'c')]が出力されました。

{-# LANGUAGE MonadComprehensions #-}
main :: IO ()
main = print [ (x, y) | x <- [1, 2, 3 :: Int] | y <- "abc" ]

LinearTypesでは、フィールドに%'Manyを付けると、そのフィールドだけ非線形になります。リリースノートの例data Record = Rec { x %'Many :: Int, y :: Char }では、構築子の型がRec :: Int %'Many -> Char %1 -> Recordになります。手元の9.14.1で、線形関数Record %1 -> …の中でxを2回使うコードはコンパイルが通り、%'Manyを付けていないyを2回使うと[GHC-18872] Couldn't match type ‘Many’ with ‘One’のエラーになりました。

coerceは、これまで「型変数が曖昧」と拒否していた呼び出しの一部を、Coercible制約から型が決まるものとして受け付けるようになりました。型注釈を足して回避していたコードは、9.14では注釈を外せる場合があります。

GHCiデバッガと複数ホームユニット

GHCiでは、複数のホームユニット（同時に開発中の複数パッケージ）を1つのセッションで読み込めるようになりました（#20889）。GHCiのエラーと警告にも固有のエラーコードが付くようになりました。デバッガは次のように変わっています。

• :steplocalの大幅な高速化（#25779）
• do式の各文がブレークポイントになり、:breakの止まる位置が予測しやすくなった
• 関数から抜けるまで進める:stepoutを追加（技術プレビュー扱い）

デバッガAPIの改良は、Debug Adapter Protocol（DAP）経由でエディタから使うための下地とされています。

コード生成・バックエンド・baseの変更

• x86ネイティブコード生成器のSIMD対応を拡張（128ビット整数演算）。shuffleFloatX4#とshuffleDoubleX2#に-mavxが不要になった
• LoongArch向けネイティブコード生成器の初期対応
• WebAssemblyバックエンドがインタプリタ評価に対応し、GHCiとTemplate Haskellが使えるようになった（ブラウザ内でforeign import javascriptも可）
• スタックトレース用に任意のデータを積むプリミティブannotateStack#を追加
• base 4.22ではMonadFailのfailにHasCallStackが付き、Data.Enum.enumerateが追加された。Unicodeデータは17.0.0に更新

HaskellをJavaScriptやWebAssemblyへ出力する経路の変遷は、GHCJSとは｜Haskell→JS変換の仕組みとGHC統合後の選び方【2026年版】で扱っています。

9.12から上げると壊れる変更と移行手順

9.14の変更のうち、既存のコードやビルド設定がそのままでは通らなくなるものを、影響の大きい順に並べます。手元のGHC 9.14.1（x86_64-apple-darwin版）で実際にコンパイルした結果を添えています。

-Wallへの-Wincomplete-record-selectorsの追加

GHC Proposal 516に従い、-Wincomplete-record-selectorsが-Wallに含まれるようになりました。一部の構築子にしか無いフィールドのセレクタを呼ぶと、実行時に例外になりうる箇所として警告が出ます。

module Rec where

data Shape
  = Circle { radius :: Double }
  | Rect   { width :: Double, height :: Double }

area :: Shape -> Double
area s = width s * height s

9.14.1でghc -c -Wallを実行すると、widthとheightのそれぞれに対して次の警告が出ます。

Rec.hs:8:10: warning: [GHC-17335] [-Wincomplete-record-selectors]
    Selecting the record field ‘width’ may fail for the following constructors:
      Circle

-Wall -Werrorなら同じ箇所がエラーになり、コンパイルは失敗します（終了コード1）。

リリースノートは当面の回避策として-Werror=no-incomplete-record-selectorsを挙げていますが、この綴りは9.14.1では受け付けられません。指定すると unrecognised warning flag: -Werror=no-incomplete-record-selectors となり、-Werror下ではそれ自体がエラーになります。警告を残したままエラー扱いだけ外すには、-Wno-error=incomplete-record-selectorsを-Werrorより後ろに書きます。手元で試すと、-Werror -Wall -Wno-error=incomplete-record-selectorsは通り、-Wall -Wno-error=incomplete-record-selectors -Werrorのように手前に書くと後の-Werrorで再びエラーになりました。根本対応は、パターンマッチで構築子ごとに分岐するか、フィールドを全構築子に持たせるか、型を分けることです。

DataKinds未指定時の昇格型使用のエラー化

DataKinds拡張を有効にしないまま、昇格したデータ型をカインドに書くコードは、9.10で警告（-Wdata-kinds-tc）になり、9.14でエラーになりました。-Wdata-kinds-tc自体は非推奨です。

import Data.Kind (Type)
import GHC.TypeNats (Nat)

data Vec :: Nat -> Type -> Type

9.14.1では error: [GHC-68567] Illegal kind: ‘GHC.Internal.Bignum.Natural.Natural’ となり、修正案として「Perhaps you intended to use the ‘DataKinds’ extension」が示されます。既定の言語エディションGHC2021にはDataKindsが含まれないため、何も指定しないとこのエラーになります。

対処は、該当モジュールかパッケージ単位でDataKindsを有効にすることです。後述のGHC2024にはDataKindsが含まれるため、言語エディションをGHC2024にすれば個別の指定は要りません。

型パターンにはTypeAbstractionsが必須

これまではScopedTypeVariablesとTypeApplicationsの組み合わせで、パターン中の型適用（Box @a x）が通っていました。9.14からは常にTypeAbstractionsが必要です。あわせて警告フラグ-Wdeprecated-type-abstractionsは削除されました。

{-# LANGUAGE ScopedTypeVariables, TypeApplications #-}
data Box where
  Box :: forall a. Show a => a -> Box

showBox :: Box -> String
showBox (Box @a x) = show (x :: a)

9.14.1では error: [GHC-78249] Illegal invisible type pattern: @a となります。{-# LANGUAGE TypeAbstractions #-}を加えるとコンパイルが通ります。

OverloadedRecordUpdateとTemplate HaskellのAPI変更

OverloadedRecordUpdateがsetFieldに渡す引数の順序が反転しました（GHC Proposal 583）。9.12まではr -> a -> r、9.14からはa -> r -> rです。RebindableSyntaxで独自のsetFieldを定義している場合は、引数順を入れ替える必要があります。

Template HaskellでSPECIALISEプラグマを生成しているコードは、SpecialisePが非推奨になりSpecialiseEPへ置き換わります。移行ガイドの書き換え例は、SpecialiseP nm ty mbInl phasesをSpecialiseEP Nothing [] (SigE (VarE nm) ty) mbInl phasesにするものです。GHC APIを使うツール（HLSのプラグインなど）は、HomePackageTableの操作がIOになるなどの変更も受けます。

9.12から9.14.2への移行手順6段階

1. 9.12系で-Wincomplete-record-selectorsを明示的に有効にし、既定で出ている-Wdata-kinds-tcの警告とあわせて先に潰す
2. cabalファイルのdefault-languageを明示する（未指定だと将来の既定変更の影響を受ける）
3. cabal-installを3.16.0.0以降に上げる（GHC 9.14はそれより古いcabal-installでは動かないとダウンロードページに明記）
4. 依存パッケージのbase上限が< 4.22で止まっていないか確認する
5. GHC 9.14.1でビルドし、9.14 migration guideの項目を照合する
6. 本番デプロイは9.14.2の正式版を待つ

9.14.1を本番に入れる前に確認すべき不具合（9.14.2で修正予定）

9.14.2のRC2告知には、9.14.1で実行結果が誤る・クラッシュする種類の修正が多く並んでいます。LTSだからといって9.14.1をそのまま長期運用するのは勧めません。特に次の環境は9.14.2を待つべきです。

• AArch64（Apple SiliconやGraviton）で並列GCを使う：並列GCのメモリバリア欠落で、クラッシュやヒープの破損が起こりうる（#27477）。AArch64のネイティブコード生成器でも、サブワード演算の誤った結果（#27430ほか）やMOVKによる値の破壊（#26980）が修正対象
• 最適化ビルドの性能や正しさに依存する：特殊化器とデマンド解析の誤コンパイル（#27626ほか）、9.14.1でオーバーロードされた関数（型クラス制約付きの関数）の特殊化が以前ほど効かなくなっていた性能退行（#26831）
• マルチスレッドのプログラム：ブラックホール処理の不具合によるデッドロックやクラッシュ（#26922、#26936）
• AVXやAVX-512のベクトル命令を使う：x86のスタック境界整列の不具合によるセグメンテーション違反（#26595、#26822）

9.14.2には非互換な変更も1つ入ります。-jsemのジョブサーバープロトコルがバージョン2になり、cabal-install 3.18以降が必要です（LinuxなどPOSIX環境が対象。古いcabal-installでは警告を出して逐次ビルドに戻る）。同じ変更は9.12.5にも入るため、9.12系に留まる場合もcabal-installは3.18系に上げておくのが安全です。また、ネストしたletで束縛した変数を参照するstatic式に非推奨警告が付き、GHC 10.0でエラーになります。

判断としては、新規案件は9.14系で始めてよく、本番環境への投入とStackage LTSへの切り替えは9.14.2の正式版を待つ、が妥当です。9.14.2が遅れていても、9.14.1を急いで本番に入れる理由にはなりません。9.14.2が出るまでは、9.10.3か9.12.4で運用を続ければ足ります。9.10.3や9.12.4で安定稼働し、更新頻度を抑えた長期保守を優先する案件では、移行先に9.14系を推奨します。開発チームは10.0の保守を長くても1年と見込み、9.12系は9.12.5で、9.10系も次のリリースで打ち切る計画だからです。上げる時期は9.14.2の正式版と、それを使うStackage LTSが出た後で十分です。

言語エディションGHC2021とGHC2024の扱い

GHC 9.14で、言語エディションを指定しなかったときに使われる既定はGHC2021です。GHC2021は9.2で導入されて既定になり、GHC2024は9.10で導入されました。9.14の利用者ガイドは、後方互換のためGHC2021を既定にしているとしたうえで、新しいコードにはGHC2024を推奨し、エディションを明示するよう勧めています。

GHC2024は、GHC2021に次の8つの拡張を加えたものです。

次の主要版GHC 10.0（2026年9月18日に10.0.1-alpha1公開）では、既定のエディションがGHC2024に変わります（GHC Proposal 632）。GHC2024はMonoLocalBindsを含むため、局所束縛の型推論が変わり、型注釈を足す必要が出るコードがあります。9.14のうちにdefault-language: GHC2024へ切り替えて差分を確認しておけば、10.0への移行時に既定の変更で慌てずに済みます。

GHC 10.0ではほかにも、-fpolymorphic-specialisationの既定有効化、TypeとConstraintの完全な区別、文字列リテラルをモジュール修飾できるQualifiedStrings拡張、Data.List.initとlastへの部分関数警告などが予定されています。GHC自体をソースからビルドするためのブートストラップGHCの最低版は9.10になり、Ubuntu 20.04向けなどのバイナリ配布は終了します。

Haskellをどんな分野で採用するかの判断材料は、Haskellの得意分野とは？何に使うか・将来性と仕事の実態【2026年】にまとめています。

よくある質問

GHC 9.14はいつリリースされましたか？

正式版の9.14.1は2025年12月19日に公開されました。最初のalphaの公式告知日は2025年8月19日です。不具合修正版の9.14.2は2026年9月17日にRC2が出たまま、2026年11月7日時点で正式版は未公開です。

GHCのLTSはどの版で、サポート期間はどれくらいですか？

最初のLTSはGHC 9.14です。公式ブログは、LTS系列に少なくとも2年、目標として3年マイナーリリースを出すとしています。9.14については、GHC開発チームが「少なくとも2028年初めまで」保守する計画を示しています。方針としては新機能をバックポートせず、不具合修正が中心です。ただし9.14.2には-fimport-loaded-targetsフラグなどGHCi・GHC API向けの追加や、-jsemのプロトコル変更も含まれます。

GHC 9.14の既定の言語エディションはGHC2021ですか？

はい。9.14では、指定がなければGHC2021が使われます。公式ガイドは新しいコードにGHC2024を推奨しており、GHC 10.0からは既定がGHC2024に変わります。

GHCupでGHC 9.14を入れるにはどうしますか？

ghcup install ghc 9.14.1 のように版を指定します。2026年11月7日時点でGHCupのRecommendedタグは9.10.3に付いているため、版を指定しないと9.14系は選ばれません。

GHC 9.14の最新パッチ版は何ですか？

2026年11月7日時点で正式に公開されているのは9.14.1だけです。9.14.2はRC2の段階で、AArch64の並列GCの不具合や特殊化器の誤コンパイルなどの修正を含みます。予定の10月初めを過ぎており、10月16日時点では、リリース担当が残りのパッチ1件を待っていると説明していました。最新の状況はGHC Wikiのstatusページで確認してください。

関連記事

• Haskellの得意分野とは？何に使うか・将来性と仕事の実態【2026年】
• GHCJSとは｜Haskell→JS変換の仕組みとGHC統合後の選び方【2026年版】
• エフェクトシステムとは？Algebraic Effectsの仕組みと言語別の実装状況【2026年9月】
• プロパティベーステストとは？性質の書き方と縮小・再現の仕組みを実装者向けに解説
• Gleamとは？Erlang VMとJavaScriptで動く型安全な関数型言語