Angular v22 発表
(blog.angular.dev)- Angular v22 は、AI エージェントのフローを、Angular MCP の開発サーバー制御ツール、Angular Agent Skills、実験的な WebMCP、Google AI Studio・Gemini Canvas における Angular 生成ワークフローへと拡張
- 安定性と開発者体験の向上を目標に、Signal Forms、Angular Aria、
resource・httpResourceを実験 / プレビュー段階から本番対応の状態へ移行 - Signal Forms は、Reactive Forms・強い型付けフォーム・テンプレート駆動フォーム・signals のリアクティビティを組み合わせた宣言的フォーム API であり、ドキュメント強化・コミュニティフィードバック反映・Angular Material および Angular Aria サポートを完了
- API とテンプレート の改善には、Router の Navigation API 統合、ルートリソースのクリーンアップ制御、
@ServiceとinjectAsync、HTML 要素コメント・spread/rest・@switch検査・テンプレートのアロー関数サポートが含まれる - Angular v22 は、新規アプリでの OnPush デフォルト化、
ChangeDetectionStrategy.Eagerへの名称変更、2026 年第 3 四半期の@boundary開発者プレビュー、Webpack 系サポート終了予定と TSGo への注力により、将来基盤を強化
本番対応になった機能
- Signal Forms は、Reactive Forms の利点、強い型付けフォーム、テンプレート駆動フォームの好まれる要素、signals のリアクティビティを組み合わせた、リアクティブ・合成的・宣言的なフォーム API
- v21 のリリース以降、angular.dev フォームガイドを更新し、コミュニティフィードバックと issue を反映、Angular Material および Angular Aria との連携もサポート
- Angular Aria は、開発者がスタイルとビジネスロジックを担当し、UI ディレクティブとパターンがアクセシビリティを処理するよう設計されたアクセシビリティプリミティブで、v22 で本番利用可能に
- Angular Aria の 12 の UI パターンは一般的なアクセシビリティパターンを扱い、API 安定化、Signal Forms の完全サポート、テストハーネスを備える
- 非同期リアクティブ API は、
resourceにより非同期リソースを signal ライクな使い勝手で扱い、httpResourceにより HTTP データ取得をより宣言的なモデルで処理 resourceとhttpResourceは v22 で本番アプリに利用可能となり、使い方は 公式ガイドで確認可能
AI 開発とエージェントワークフロー
- Angular v22 は、AI-native アプリケーション向けのフローを、コード作成用エージェントツール、ブラウザーエージェントツール、AI 開発プラットフォームの 3 領域へ拡張
- Angular MCP の
devserver.wait_for_buildは、エージェントがアプリケーションをビルドして出力結果を確認し、次のステップを判断できるよう支援し、ビルドログのコードエラーをもとに自己修復ループを構築可能 devserver.startとdevserver.stopは開発サーバーの開始・停止を担い、これらのツールはテストおよび end-to-end ツールとともに v22 で stable に昇格- Angular MCP は、
ai_tutor、modernize、onpush_zoneless_migrationなど、モダンな Angular アプリ開発を支援するツール一覧を拡充中 - Angular Agent Skills の
angular-developerは、Angular Aria や Signal Forms などの最新機能を含むモダン Angular 開発ガイドラインをモデルへ提供し、ファイルは 140 行未満で、必要なタイミングでコードサンプルや参照ファイルを読み込む段階的開示方式を採用 angular-new-appは、エージェント環境で Angular を初めて探るユーザーがローカルの Angular コーディング環境を構成できるよう案内し、この skills は Antigravity のような AI 開発ツールやエージェントワークフロー環境で利用可能- Contributor Skills は、Angular codebase 内で機能を開発するために必要なメンタルモデルの理解を助け、初めて pull request を準備する人にも経験豊富なチームメンバーにも価値がある
- 実験的な WebMCP は、ブラウザー内でエージェントが使う構造化ツールを作成・公開できるようにし、DOM 相互作用の必要性を減らし、アプリ全体・routes・services のツール定義と dynamic Signal Forms ベースの自動ツール生成をサポート
- WebMCP 統合ドキュメントは angular.dev/ai/webmcp で確認可能
- Google AI Studio と Gemini Canvas は、従来のコーディング経験がない builders が Angular ベースのプロジェクトを開始できるよう支援し、Gemini Web アプリ内蔵のコーディングサンドボックスではブラウザー内で完全なアプリケーションを作成可能
- Gemini ワークフローでは、prompt に「Angular」を指定すると Angular アプリが生成され、生成後はブラウザーで手動編集したり、AI と対話を続けて仕上げたり、Firebase 統合を依頼したりできる
- Google AI Studio では、configuration panel で Angular を選んで prompt を開始する類似ワークフローを利用でき、生成後はチャットで機能追加からデプロイまで進められる
Router と依存性注入 API
- Navigation API 統合 は、Router をブラウザー標準の Navigation API に合わせ、より少ない boilerplate でアプリ遷移制御を提供
- Router は、
RouterLinkと標準 anchor tag を含むすべての navigation request を自動的に横取り可能 - native scroll behavior を活用して back/forward 移動時にユーザーが期待する位置へ到達できるようにし、custom scroll-management logic なしで bundle size への影響もない
- ブラウザー標準の navigation lifecycle に直接接続することで、page transition 中の global loading indicator や正確なアクセシビリティ announcement をより簡単に処理可能
- ルートのクリーンアップ制御 は、
withExperimentalAutoCleanupInjectorsとdestroyDetachedRouteHandleの 2 機能により、メモリー管理をより明示的に扱う withExperimentalAutoCleanupInjectorsは、もはや active でない route に紐づく dependency injector を自動的に destroy し、アイドル状態の route-level provider と resource をクリーンアップdestroyDetachedRouteHandleは、customRouteReuseStrategy利用時に detached route handle 内の component を適切に destroy するための公式 public API@Serviceデコレーター は、ほとんどの use case で@Injectable({ providedIn: 'root' })パターンを置き換え、より深い設定や constructor injection が必要な場合は引き続き@Injectableを使用可能injectAsyncは、service の非同期依存性注入をサポートし、code splitting と on-demand loading を可能にし、service は auto-provided 状態である必要があり、@Serviceがそれを処理injectAsyncの例では、ReportExporterservice は初回利用時まで load されず、prefetch: onIdleのような prefetch 設定も可能- 使い方は injectAsync 公式ドキュメントで確認可能
- その他の改善として、TypeScript 6 の完全互換性と template pipeline および runtime efficiency の性能改善が含まれる
テンプレート記述体験と変更検知
- HTML 要素内の property および binding レベルで comment を使用でき、template の可読性と明確さが向上し、VS Code の comment toggling もサポート
- Angular は、同じ element 上で複数回 match される host directive を自動的に de-duplicate
- directive が template と host directive の両方で match される場合は template match が優先され、host directive の input/output map は merge される
- input または output が複数名で公開されている場合、Angular は naming conflict を防ぐため error を発生
- template で spread/rest syntax を利用でき、object literal、array literal、function call に適用可能
@switchは複数の@caseが同じ output を共有できるため、code duplication を削減- union type を使う
@switchblock で@default never;を使うと、未処理の値がある場合に compile-time error を受け取れる - template 内の inline function はアロー関数形式で利用でき、短く単純な関数に適しており、複雑または実行時間の長い関数は template に置かないという条件が付く
- 新規アプリケーションでは
OnPushがデフォルトの change detection 戦略となり、zoneless のデフォルト化および performance by default の目標に沿う - これまでのデフォルトである
ChangeDetectionStrategy.DefaultはChangeDetectionStrategy.Eagerに名称変更され、change detection cycle における動作をより明確に示す
エラーバウンダリー、非推奨予定、今後の方向性
@boundaryは、Angular template 内で error boundary を実装する新 API で、囲まれた code block から上がる error を catch し、fallback content を指定できる- EC サイトの checkout のような high-stakes flow で、単一 component の failure がページ全体を壊す問題を減らすことが目的
@boundaryは 2026 年第 3 四半期に developer preview として提供予定- Webpack support、
@angular-devkit/build-angularbuilders、@ngtools/webpackなどは v22 で deprecated 状態に - Angular は application builder の TSGo support に注力しており、より詳しい deprecation 情報は Angular CHANGELOGで確認可能
1件のコメント
Hacker Newsの反応
Angular v21でかなり複雑なアプリを作っているが、コンポーネント・状態・データフローを作って扱う際の認知負荷が低く、とても良い体験だった
シグナルとシグナルストアのおかげでかなり簡単になり、AIコーディングツールなしですべて手書きした
最近のAngularは使っていて楽しいレベルだと認めざるを得ない
エコシステムが少し粗いのは残念だが、幸い標準で提供される機能が非常に多い
Angularが
tscに強く結び付いた独特なコンパイラを捨てて、どのTypeScriptコンパイラでも使える、よりプラガブルなアプローチに進んでほしいアプリと単体テストのコールドビルド時間はいまだにいまひとつだが、コーディングエージェントを使うとその負担は少し気にならなくなる
パッケージ探しで問題に遭ったことはなく、ほとんどのパッケージもシグナルフローにうまく追随している
それとも今ではAngularエコシステムにも正気が戻ってきたのか気になる
最近、かなり複雑なAngularプロジェクトをv14からv21へ上げた
ここ数年はAngular開発が遅くなった印象があったが、それらのバージョン間の変化をまとめて見ると、ほとんど完全に新しいフレームワークのように感じる
Angular Ariaは本当に良さそうだ
オートコンプリートのような複雑なシナリオまで文書がよく整っていて、以前は自作しなければならなかったスクリーンリーダー向けオートコンプリートの代わりになるのか、早く試してみたい
tab/shift+tabではなく矢印キーで移動するようになっていたしかもその例のすぐ上にあるドキュメント内のタブ自体は、フォーカス移動に
tab/shift+tabを使っているこの機能は本当に楽しみだ
実験的機能だった頃からsignal-formsとresourcesを使いたかったし、シグナルに乗ってからはもう戻れなかった
フォームのためにRxJSを使わなければならないのが大きな苦痛だった
Godotのようなゲームエンジンのシグナルパラダイムのように、深さに関係なくコンポーネントがシグナルを発し、別のコンポーネントが購読する方式に近いのか、それともまったく別物なのか気になる
React以前はAngularを楽しく使っていて、かなり良い時代だったが、正直今ではAngularが存在していたことすらほとんど忘れている
Reactを褒めたいわけでもなく、最近はむしろhtmx流のやり方が気に入っている
ただ、今や競争はどのフレームワークや言語をエージェントがよりうまく扱えるか、そして静的解析やコンパイラレベルのツールがミスをどれだけ拾えるかへ移ったように感じる
Angularは少しDjangoのような感じがして良い
必要なものが全部入っているので使いやすい
あるいはテンプレートとサーバーサイドレンダリングを備えたより高速なバックエンドを使い、そこにhtmxを組み合わせれば、実際には壊れているJSエコシステムの狂気なしでもシングルページアプリのような体験を得られる
Angularのおかげでプログラミングのキャリアは楽しく、まったく仕事のように感じなかった
好きな言語で働き、もっと学び、そのうえお金まで得られる以上に良いことはない
しばらくAngularを使っていない
Vue、React、Svelteのような他のJavaScriptフレームワークを使う立場から、自分が見落としているものは何なのか気になる
他の大きなフレームワークではなくAngularを選ぶ人たちの理由が知りたい
特にJavaScriptやWeb開発があまり好きではなく、バックエンドが主だと考えている場合によく合う
import {signal} from "@angular/core"やimport {form} from "@angular/forms/signals"のように、signalはcoreから来てformはforms/signalsから来る構造になっている自分には理解できていない用語上の理由があるようだ
それ以外は、10年ぶりにAngularをまた使ってみるのが楽しみで、かなり良さそうに見える
シグナルベースのフォームはFormsモジュールの一部なので、フォームを使わなければそのオーバーヘッドを持ち込まない
たぶん新しく出たシグナルベースのフォームを取り込むためのimportだと思う