LASSIC Media らしくメディア
AngularJSサポート終了、移行を4ステップで外注
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- AngularJSは2022年1月に公式サポートが終了しており、以降は新規のセキュリティ修正や機能追加が提供されていません。
- 現行Angularは、ngUpgrade（UpgradeModule）により両フレームワークを共存させながら段階的に移行できる公式の仕組みを用意しています。
- 移行の実行は「現状棚卸→ハイブリッド化→段階移行→撤去」の4ステップで整理でき、社内リソースの状況次第で内製と外注委託を使い分ける判断が必要になります。
目次
AngularJSとは？サポート終了（EOL）の公式情報を確認する
AngularJS（Angular 1.x）は、Googleが開発したJavaScriptのフロントエンドフレームワークです。2010年代に多くの企業システムやSPA（シングルページアプリケーション）で採用されましたが、AngularJS公式ドキュメントは「AngularJS support has officially ended as of January 2022.」と明記しており、2022年1月をもって公式サポートが終了しています*1。同ドキュメントのFAQページでも同じ内容が確認でき、現行の「actively supported Angular」（積極的にサポートされているAngular）へ移行するよう案内されています*2。
ここで言う「Angular」とは、AngularJSとは別のフレームワークとして2016年以降にゼロから再設計されたバージョン2以降の総称です。名称が似ているため混同されがちですが、内部アーキテクチャは大きく異なり、単純なマイナーアップデートでは移行できません。まず自社が使っているのがAngularJS（1.x系）なのか現行Angular（2以降）なのかを、package.jsonの依存関係やスクリプトタグの読み込み元から確認することが出発点になります。
サポート終了後もAngularJSを使い続けるリスク
公式サポートが終了したソフトウェアを使い続けるうえで見過ごせないリスクは、新たに発見された脆弱性が修正されないまま残り続ける点です。AngularJSは2022年1月以降、セキュリティパッチの提供対象から外れているため*1、社内システムやSPAをインターネットに公開している場合、既知・未知の脆弱性が放置される状態になります。情報システム部門としては、脆弱性対応の観点だけでも移行の優先度を上げて検討する材料になるでしょう。
もう一つのリスクは、ブラウザ側の仕様変更に対する非互換です。ブラウザベンダー各社は継続的に新しいAPIへ切り替えを進めており、古いフレームワークが前提とする挙動が将来のブラウザアップデートで動かなくなる可能性は否定できません。加えて、AngularJSに詳しいエンジニアの採用は年々難しくなっており、保守を担える人材の確保自体が経営リスクになりつつあります。放置期間が長くなるほど、移行時に洗い出す依存関係やカスタム実装が積み上がり、後から着手するほど作業量が膨らむ構造にも注意が必要です。
移行の全体像：ngUpgradeによる段階移行という公式アプローチ
1つのDOM要素は1つのフレームワークが担当するという考え方
Angular公式のUpgradeModule（ngUpgrade）ドキュメントは、AngularJSとAngularを同一アプリケーション内で共存させながら段階的に移行するための仕組みを提供しています*3。基本となる考え方（Mental Model）として「Each DOM element on the page is owned exactly by one framework」、つまりページ内の各DOM要素はどちらか一方のフレームワークだけが管理するという原則が示されています*3。
この原則により、AngularJSのコンポーネントをAngular側から呼び出す仕組みと、逆にAngularのコンポーネントをAngularJS側から呼び出す仕組みの両方が用意され、サービスやDIコンテナも相互に統合できます*3。一度に全部を書き換えるのではなく、ハイブリッドなアプリケーションとして起動しながら、機能単位で少しずつ置き換えていくアプローチです。
一気に書き換える方式との違い
移行の方式には、既存コードを段階的に置き換えるハイブリッド方式と、新規にゼロから作り直すリライト方式の2つの選択肢があります。ハイブリッド方式は公式のngUpgradeが前提とする進め方であり、機能を止めずに移行できる点が利点です*3。一方でリライト方式は、AngularJS特有の実装から完全に決別できる代わりに、既存機能の再現漏れが起きやすく、開発期間も長くなりがちです。アプリケーションの規模や運用体制に応じて、どちらの方式が現実的かを見極める判断が必要になります。
AngularJSからAngularへの移行を4ステップで進める
ngUpgradeが前提とするハイブリッド方式の移行は、おおむね次の4ステップに整理できます。
STEP1：現状棚卸と依存関係の可視化
まず、対象アプリケーションが使用しているAngularJSのバージョン、サードパーティ製ディレクティブ、外部ライブラリへの依存関係を洗い出します。画面数・コンポーネント数・APIとの結合度を一覧化しておくと、後続ステップでの見積もり精度が上がります。
STEP2：ngUpgradeによるハイブリッド化
UpgradeModuleを導入し、AngularJSとAngularを同一アプリ内で同時に起動できる状態を作ります*3。この時点ではまだ画面の大部分がAngularJSのままですが、両フレームワークが共存する基盤が整います。
STEP3：コンポーネントを1つずつ移行
優先度の高い画面・コンポーネントから順に、AngularJS実装をAngularのコンポーネントへ置き換えます。downgradeComponent・upgradeComponentといったAPIを使い、移行済み部分と未移行部分を橋渡ししながら進める工程です*3。
STEP4：AngularJS完全撤去
全コンポーネントの移行が完了したら、UpgradeModuleとAngularJS本体の読み込みを取り除きます。ここまで到達して初めて、サポート終了に伴うセキュリティリスクから完全に切り離された状態になります。
内製移行と外注委託のコスト構造比較
AngularJS移行を内製で進める場合と、外部パートナーへ委託する場合では、必要なスキルセットとリスク対応の重心が異なります。以下の表に主な違いを整理しました。
| 比較項目 | 内製移行 | 外注委託 |
|---|---|---|
| 必要な専門知識 | AngularJSとAngular双方の知識、ngUpgradeのAPI理解、既存コードの読解力が必要です*3 | 移行実績のあるパートナーが知見を持ち込むため、社内での新規習得は最小限で済みます |
| 既存業務との両立 | エンジニアが既存の保守・開発業務と兼務するため、移行が長期化しやすい傾向があります | 移行専任のチームを確保できれば、既存業務を止めずに並行して進めやすくなります |
| 移行方式の判断 | ハイブリッド方式かリライト方式かを自社の知見だけで判断する必要があります | 複数案件の経験に基づき、規模やリスクに応じた方式選定を相談できます |
| 移行後の保守体制 | 移行完了後もそのまま社内で保守を継続できます | 移行後の保守を含めて委託するか、内製に切り替えるかを事前に取り決めておく必要があります |
移行を外注する際の判断軸
移行を内製で進めるか外注するかは、主に3つの軸で判断できます。1つ目は社内にAngularJSとAngular双方を扱えるエンジニアが確保できているかどうかです。AngularJSの実務経験者は市場で減少傾向にあり、採用や育成に時間をかけるより、既に知見を持つ外部パートナーへ依頼したほうが早く着手できる場合があります。
2つ目は移行対象の規模です。画面数やコンポーネント数が多いシステムでは、STEP1の依存関係の棚卸しだけでも相応の工数がかかり、規模に見合った体制を組めるかどうかが成否を左右します。3つ目はセキュリティリスクへの許容度です。放置期間が長引くほど脆弱性が残る期間も延びるため、社内リソースの調整を待つより外部委託で移行期間を圧縮したほうが、リスク低減の観点で有利になるケースもあるでしょう。いずれの軸で判断する場合も、まずは自社システムの現状棚卸しから着手することが共通の出発点になります。
まとめ：AngularJS移行を進める3つの判断軸
本稿ではAngularJSのサポート終了状況と、現行Angularへの移行の進め方を公式ドキュメントに基づいて整理しました。要点は次の3つに集約されるでしょう。第一に、AngularJSは2022年1月に公式サポートが終了しており、以降はセキュリティ修正が提供されない状態が続いています*1。第二に、移行はngUpgrade（UpgradeModule）を使ったハイブリッド方式により、両フレームワークを共存させながら段階的に進められる公式の道筋が用意されています*3。第三に、「現状棚卸→ハイブリッド化→段階移行→撤去」という4ステップのどこを内製で担い、どこを外部委託するかは、社内のAngular知見と移行規模、許容できるリスク期間を踏まえて判断する必要があります。
よくある質問
AngularJSのサポート終了はいつですか。
AngularJS公式ドキュメントは「AngularJS support has officially ended as of January 2022.」と明記しており、2022年1月をもって公式サポートが終了しています*1。それ以降のセキュリティ修正・機能追加は提供されていません。
AngularJSとAngularは同じフレームワークですか。
いいえ、別のフレームワークです。AngularJS（1.x系）は2016年以降に登場した現行Angular（2以降）とは内部アーキテクチャが大きく異なり、単純なアップデートでは移行できません*1。
移行は一度に書き換える必要がありますか。
必須ではありません。公式のngUpgrade（UpgradeModule）を使えば、AngularJSとAngularを同一アプリ内で共存させながら、コンポーネント単位で段階的に移行できます*3。規模やリスク許容度によっては、ゼロから作り直すリライト方式を選ぶ判断もあり得ます。
移行にはどのくらいの期間がかかりますか。
対象システムの画面数・コンポーネント数・外部ライブラリへの依存度によって大きく変わるため、一律の期間は示せません。まずは現状棚卸しで依存関係を可視化し、規模に応じた見積もりを行うことが出発点になります。
内製と外注はどちらを選ぶべきですか。
社内にAngularJSとAngular双方を扱えるエンジニアがいるか、移行対象の規模、放置できるセキュリティリスク期間の3点で判断します。知見のある人材確保が難しい場合や、期間を圧縮したい場合は外部委託が選択肢になります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：AngularJS公式ドキュメント「Version support status」（https://docs.angularjs.org/misc/version-support-status）
- *2 出典：AngularJS公式ドキュメント「FAQ」（https://docs.angularjs.org/misc/faq）
- *3 出典：Angular公式ドキュメント「UpgradeModule」（https://angular.dev/api/upgrade/static/UpgradeModule）
