Angular 22.1とは？v22系の変更点とリリース体制の転換を実装目線で解説

Angular 22.1は、2026年7月29日に公開されたv22系2本目のマイナーリリースです。linkedSignalにカスタムのsetオプションが加わり、AIエージェント向けのMCPツールが実験的な扱いから安定版へ上がりました。ただし、この版で実務に効く変更はAPIの追加そのものではありません。v22から始まったリリース体制の転換——メジャーが年1回になり、サポート期間が18か月から2年へ延びたこと——が、既存アプリのアップグレード計画と保守契約の見積りを根本から変えます。この記事では22.1の差分、v22.0で入った前提となる変更、そして移行時期をどう決めるかまでを順に整理します。

まとめ：Angular 22系へ上げる条件と見送る場面

先に結論を書きます。v22系へ上げるべきなのは、次の三つのうち二つ以上が当てはまるときでしょう。第一に、実行環境をNode v22以上・TypeScript v6以上へ動かせること。第二に、Signal Formsやresource系のAPIを前提に新機能を作る計画があること。第三に、現行がv21で、2027年6月のLTS終了までに一度は棚卸しの工数を確保できる見込みが立っていること。

逆に、見送りを検討すべき場面もはっきりしています。実行基盤のNodeバージョンが他システムとの兼ね合いで固定されている、あるいはTypeScript v5系に依存したビルド資産が大量に残っているなら、環境側の解決が先です。Zone.jsに依存したテストコードが厚い場合も、OnPushが既定になった影響でテストの落ち方が変わり、検証工数が読みにくくなります。JSONPを使った外部連携が残っている場合は、非推奨の告知が出た今のうちに置き換え先を決めておく必要があるでしょう。

そして最も見落とされやすいのが、待つという選択の期限が変わった点です。年1回になった今、v22を見送るとv23は2027年6月まで来ません。その間にv21はLTS期限を迎えるため、待つ判断はそのまま「サポート切れの期間を持つ」判断に変わります。v21の変更点そのものを確認したい場合はAngular v21 の概要と主な変更点 — 開発者体験の革新ポイントを先に読むと、この記事の位置づけがつかみやすくなるはずです。

Angular 22.1とは？v22系の位置づけと2026年7月の公開内容

Angular 22.1.0は2026年7月29日に公開されました。v22系の起点であるv22.0.0が2026年6月3日の公開なので、メジャーからおよそ2か月後のマイナー更新にあたります。次のv22.2は2026年9月が予定されており、以降も2か月おきの間隔で刻まれていく見通しです（いずれも2026年7月時点の公開情報）。

ここで押さえておきたいのは、マイナーの位置づけが以前と変わったことでしょう。公式のリリース方針では、1つのメジャーに対してマイナーは4〜6回とされています。従来は1〜3回だったので、単純に倍前後の頻度になった計算です。メジャーの間隔が延びた分を、マイナーが埋める設計に切り替わったと読めます。

実務上は、バージョン追随の運用が「年2回の大きな山」から「年1回の山と、その間の小刻みな更新」へ形を変えたと捉えてください。マイナーの追随を怠ると、次のメジャーで差分をまとめて吸収する羽目になります。

リリース体制の転換：年1回のメジャーと2年サポートが意味すること

v22でのいちばん大きな変更は、フレームワークのAPIではなくリリース体制のほうです。公式のリリース方針によれば、メジャーリリースは12か月ごと、つまり毎年6月に一度だけ公開される形へ移りました。次のメジャーであるv23は2027年6月です。そして各メジャーのサポートは合計24か月へ延び、内訳は定期的な更新が行われるActive期間が12か月、重大な修正とセキュリティ修正のみを受け取るLTS期間が12か月という構成になっています。

この変更を数字で並べると、計画の立て方がどう変わるかが見えてきます。

表から読み取れるのは、v21のLTS終了とv23の公開が2027年6月で重なるという事実です。v22を飛ばしてv23を待つ計画を立てると、サポートのある版に乗り続けるためには、v23の公開直後にv21から2世代ぶんの移行を完了させなければなりません。メジャー1回ぶんの移行を分割せずに一気に踏む形になるので、破壊的変更の吸収量は増えます。年1回化はアップグレードの回数を減らしますが、1回あたりの重さは増える——この非対称性が計画に効いてきます。

保守契約の側でも見積りの前提が動きます。18か月サポートの時代は、契約期間中に必ず2回はメジャー移行の予算を取る想定が要りました。24か月になったことで、年次の保守契約なら「2年に1回のメジャー移行」を織り込む形へ整理できます。ただしマイナーが年4〜6回に増えたぶん、小規模な追随作業の頻度は上がります。年間の総工数が減るとは限りません。既存システムの移行計画そのものを外部と組み立てたい場合は、システムマイグレーション・リプレイスでご相談を承ります。

v22.0で入った主要な変更点とアップグレードの前提となる環境

22.1へ上げるということは、v22.0の変更をすべて引き受けるということです。v22.0には破壊的変更が複数含まれるため、22.1の差分だけを見て判断すると見積りを外します。実装に影響が大きいものを整理しておきましょう。

環境要件から見ていきます。v22ではNode v20のサポートが終了し、Node v22以上とTypeScript v6以上が必須になりました。ここは自動移行では吸収できない部分なので、コンテナイメージやCIランナーの更新を先に済ませておく必要があります。TypeScript v6への移行が別プロジェクトになるようなら、その完了時期がAngular側の移行時期を規定すると考えてください。

変更検知の既定がOnPushへ移った件は、影響範囲が読みにくい変更です。CLIで新規生成するコンポーネントの既定が変わるだけでなく、既存コンポーネントに対しても自動移行のスキマティックが用意されています。シグナル以外の経路で状態を書き換えている箇所があると、画面が更新されない不具合として現れます。シグナルの依存追跡そのものの挙動についてはuntrackedとcomputedシグナルの違い｜Angular・SolidJS・Preactで依存追跡を外す使い方で扱った内容が前提知識になるでしょう。

HTTPまわりでは、HttpClientの通信基盤がFetchへ切り替わりました。XMLHttpRequestの挙動に依存している処理——進捗イベントの扱いや一部のインターセプタ実装——がある場合は、withXhr()プロバイダで従来の挙動へ戻せます。あわせてwithFetch()は既定化に伴い非推奨となり、reportProgressもreportUploadProgressとreportDownloadProgressへ分割されました。ルーターではcanMatch関数に第3引数のcurrentSnapshotが必須となり、paramsInheritanceStrategyの既定がalwaysへ変わっています。後者はパラメータの継承範囲が広がる変更なので、子ルートでパラメータを読んでいる箇所の挙動確認が要ります。

テンプレート式のオプショナルチェーンの意味も変わりました。対象がnullまたはundefinedのとき、従来はnullを返していたところがundefinedを返すようになり、TypeScriptの仕様と揃った形です。テンプレート内でnullと厳密比較している箇所は結果が反転しかねません。ここも自動移行の対象なので、ng updateの結果を見てから手作業の範囲を決めてください。

22.1の差分：linkedSignalの拡張とMCPツールの安定版化

ここから22.1で加わった内容に入ります。フレームワーク本体で目立つのはlinkedSignalの拡張です。カスタムのsetオプションを渡せるようになり、値を書き込んだときに元のシグナルへどう反映するかを自前で決められます。派生値を持つUIで、表示用の値と保持する値の変換規則が単純でないケース——単位変換を挟むフォーム項目や、丸め処理を伴う数値入力など——で書き方が素直になります。

もう一つ、HTTPインターセプタがeffect内で自動的に非追跡の扱いになりました。インターセプタの中でシグナルを読んだ場合、その読み取りがeffectの依存関係として登録されてしまう問題への対処です。認証トークンをシグナルで保持し、インターセプタから読んでヘッダに付ける実装は珍しくありません。これまでは意図しない再実行が起きる余地がありましたが、22.1以降はフレームワーク側で防がれます。

AIエージェント向けの機能では、MCPツールが実験的な位置づけから安定版へ移りました。安定版になったのはrun_target、devserver.start、devserver.stop、devserver.wait_for_buildの4つです。run_targetはワークスペースに定義されたビルドやテストのターゲットをエージェント側から実行できるもので、コーディングエージェントに変更を書かせたあと、その場でテストまで回して結果を読ませる流れが公式の仕組みとして成立します。devserver系の3つは開発サーバーの起動・停止・ビルド完了待ちを担い、画面の描画結果を確認させる用途に対応します。

実装者の視点で言えば、これは「エージェントに書かせて人が確認する」から「エージェントが自分で検証してから提出する」への移行を、フレームワーク側が受け入れたということです。安定版になった以上、社内のレビュー手順の側でも、エージェントが実行してよいターゲットの範囲を決めておくべきでしょう。CIで走らせる本番相当のジョブとは分けて定義するのが無難な設計になります。

細かい修正も入っています。コンパイラではCSS変数の名前空間化と制御フローブロック内での外部コンポーネント対応、ルーターではRouterLinkActiveがnullやundefinedの入力を受けたときの挙動、HTTPでは資格情報付きリクエストのキャッシュ指定です。CLI側にはInjectableからServiceへの移行スキマティックが加わり、v22.0で入ったServiceデコレータへの書き換えを機械的に済ませられます。

非推奨となったJSONPとHTTPまわりで先に手を打つべき箇所

22.1で明確な期限が見えた変更が、JSONPの非推奨化です。HttpClient.jsonp、HttpClientJsonpModule、withJsonpSupport()をはじめとするJSONP関連のAPIがまとめて非推奨となり、開発モードではJSONPのバックエンドが生成された時点で警告が出るようになりました。

非推奨の理由は仕組みそのものにあります。JSONPはページにscriptタグを差し込み、返ってきた内容をグローバルスコープでJavaScriptとして実行する手法です。応答した側のコードが自分のページの権限で動くため、クロスサイトスクリプティングの経路になりやすく、コンテンツセキュリティポリシーによる制御も回避してしまいます。CORSが広く使えるようになった今、残しておく理由が乏しくなったという整理でしょう。

対応の進め方は、利用箇所の性質で分かれます。自社で制御できるAPIを叩いているなら、サーバー側にCORSヘッダを設定して通常のHTTPリクエストへ置き換えるのが本筋です。外部サービスがJSONPしか提供していない場合は、自社のバックエンドに中継用のエンドポイントを立て、ブラウザからはそこへ通常のリクエストを送る形へ寄せます。中継を挟めば呼び出し元の制限や認証情報の管理を自分側で持てます。

非推奨はまだ削除ではありません。ただしメジャーが年1回になった今、削除の告知から実際の削除までの猶予は「次の6月」という粒度で訪れます。警告が出ている状態を放置すると、v23への移行時にビルドが通らない箇所として一気に噴き出します。開発モードの警告をCIで検出して、残数をゼロへ近づける運用に切り替えるのが確実な進め方でしょう。

ビルドと開発体験の変化：Rolldown既定化とDevToolsの改善

ビルド側では、Rolldownがチャンク分割の既定として安定版になりました。何らかの理由でRollupへ戻したい場合は、環境変数NG_BUILD_CHUNKS_ROLLDOWNにfalseを指定します。あわせてサーバービルドでもチャンク分割が有効化され、サーバーサイドレンダリングを使う構成では出力の形が変わります。ビルド成果物のサイズやファイル名を前提にした配信設定——CDNのキャッシュ規則やアセットのプリロード指定など——を持っている場合は、上げた直後に出力を確認しておいたほうがよいでしょう。

もう一つ、ビルドキャッシュがgitのworktree間で共有されるようになりました。複数のブランチを並行して触る開発では、worktreeを切り替えるたびにキャッシュが効かず初回ビルドが伸びる問題がありました。この改善はビルド時間の短縮としてそのまま効きます。レビュー用のworktreeを常設している現場ほど体感は大きいはずです。

DevToolsでは、シグナルグラフを名前と型で検索できるようになりました。type:computedのような書き方で種類を絞り込めるため、シグナルの数が増えたアプリで目的のノードへ辿り着きやすくなります。転送状態のパネルも既定で表示される形に変わり、サーバーサイドレンダリングでクライアントへ渡すデータの中身を追加操作なしで確認できます。

開発体験の変化はテストにも及びます。v22.0の時点で、KarmaのテストをVitestへ移すスキマティックが用意され、Zone.jsを使うテストユーティリティのVitest対応も入りました。テスト基盤の移行は影響範囲が広いため、フレームワークの移行を先に済ませて動作を確定させてから、別スプリントで扱う分け方が安全でしょう。構成自体を見直す段階にあるなら、Angular 14で導入されたスタンドアロンコンポーネントの新しいコンセプトとはで扱ったモジュール構成の整理も同じタイミングで検討する価値があります。

v21のまま待つか22へ上げるか：移行の時期を決める四つの軸

ここからは判断の話です。バージョン移行の時期は、機能の魅力ではなく制約から逆算して決めたほうが精度が上がります。四つの軸で見ていきましょう。

一つ目は、実行環境の可動域です。Node v22以上とTypeScript v6以上へ動かせるかが最初の関門になります。ここが動かせないなら、Angular側の議論より先に環境の更新計画が要るでしょう。共通基盤を他システムと共有していて単独では動かせないなら、移行時期は基盤側の更新時期に従属します。この従属関係を確認せずにスケジュールを引くと、着手の直前で止まります。

二つ目は、サポート期限からの逆算です。現行がv21なら、LTS終了は2027年6月です。v22へ上げれば2028年6月まで伸びます。ここで注意したいのは、v22を見送った場合の代替がv23（2027年6月公開）しかない点でしょう。公開直後に本番へ載せる判断は普通は取りません。慣らし期間を3か月置くなら、v21のサポート切れとv23の投入が重なり、無サポート期間が発生します。年1回化によって「一つ飛ばし」の難度が上がったと理解しておくべきです。

三つ目は、破壊的変更の吸収量です。前述のOnPush既定化、Fetch既定化、canMatchの署名変更、オプショナルチェーンの意味変更が主な対象になります。自動移行のスキマティックが用意されている項目が多いため、機械的に処理できる範囲は広いのですが、動作確認の工数は別途要ります。テストのカバレッジが薄い画面が多いプロジェクトほど、ここが見積りの支配項になるでしょう。国際化対応を入れている場合はi18n（国際化）とは何か？Angularアプリでの必要性と基本的な仕組み【ローカライズとの違いも解説】で扱った翻訳ファイルの取り回しも、確認対象に含めておいてください。

四つ目は、新機能を使う予定があるかどうかです。Signal Formsとresource系のAPIが安定版になったことで、フォームと非同期取得の書き方に公式の推奨が定まりました。今後1年以内に新しい画面を作る計画があるなら、その実装をv21の旧来の書き方で作り、翌年に書き直す形は無駄が大きくなります。逆に、機能追加の予定がなく保守だけを続けるアプリなら、サポート期限の軸だけで判断すれば足ります。

この四つを掛け合わせると、実務的な結論は次のようになります。環境を動かせて新規開発の予定があるなら、v22.1系が出て初期の不具合が落ち着いた今が着手の頃合いです。環境が動かせないなら、まず環境側の計画を立て、2027年前半までにv22へ乗ることを期限として設定します。保守のみで環境も固定なら、v21のLTS期限である2027年6月を締切として逆算し、それより前にv22へ上げる予算を確保しておく——という形に落ち着くでしょう。なお、版を追う設計思想は他の選択肢と比べておくと判断が立体的になります。Next.js 16とは？ReactベースのWeb開発フレームワーク最新版の概要や主要機能を詳しく紹介で扱った版の上がり方と比べると、Angularの年1回・2年サポートという体制がどれだけ計画を立てやすい部類なのかが見えてきます。

よくある質問

Angular 22.1へは22.0から直接上げられますか？

同一メジャー内のマイナー更新なので、破壊的変更なしで上げられます。作業自体はng updateでパッケージの版を進めるだけで済みます。注意が要るのはRolldownがチャンク分割の既定になった点でしょう。ビルド出力の形が変わるため、配信側の設定が出力ファイル名に依存しているなら、上げた直後に本番相当の環境でビルド結果を確認してください。

v21のままでいつまでサポートを受けられますか？

v21.0.0は2025年11月19日公開で、Active期間はv22公開日の2026年6月3日に終了しており、現在はLTS期間に入っています。LTSの終了は2027年6月です。この期間中は重大な修正とセキュリティ修正のみが提供され、機能追加は行われません。2027年6月を過ぎるとセキュリティ修正も止まるため、それを締切として移行計画を組んでください。

JSONPはいつ削除されますか？

22.1の時点では非推奨の告知であり、削除の版は明示されていません。Angularの慣行では非推奨から削除まで最低でも1つのメジャーを挟むため、実際の削除はv23（2027年6月公開）以降になる見込みでしょう。ただし年1回のメジャーでまとめて削除される形になるので、猶予があるうちに置き換え先を決めておいたほうが安全です。

OnPushが既定になると既存の画面は壊れますか？

既存コンポーネントの既定が自動で書き換わるわけではなく、移行スキマティックを通したときに明示的な指定が入る形です。壊れやすいのは、シグナルやAsyncPipeを経由せずに状態を書き換えている画面になります。setTimeoutの中でプロパティを直接書き換えているような実装は、画面が更新されなくなる可能性があります。移行前に、非同期処理から状態を変えている箇所を洗い出しておくとよいでしょう。

MCPツールの安定版化は開発体制に何を求めますか？

run_targetでエージェントがビルドやテストを実行できるため、どのターゲットを開放するかを組織として決める必要があります。本番デプロイに繋がるターゲットや、外部サービスへ書き込むテストを無条件に開放すると事故の経路になるでしょう。エージェント用のターゲットを別途定義してそこだけを対象にし、開発サーバーの起動を伴う点から実行環境の分離もあわせて検討してください。

関連記事

• Angular v21 の概要と主な変更点 — 開発者体験の革新ポイント
• untrackedとcomputedシグナルの違い｜Angular・SolidJS・Preactで依存追跡を外す使い方
• Angular 14で導入されたスタンドアロンコンポーネントの新しいコンセプトとは
• i18n（国際化）とは何か？Angularアプリでの必要性と基本的な仕組み【ローカライズとの違いも解説】
• Next.js 16とは？ReactベースのWeb開発フレームワーク最新版の概要や主要機能を詳しく紹介