Vibeコーディングで Angular アップグレードを回避

背景と概要

2026年10月、開発者コミュニティの dev.to に「Vibe Coding My Way Out of Angular Upgrades」と題した実践記事が掲載されました。多くのフロントエンドチームが抱える悩みを扱っています。プロジェクトが使う Angular のバージョンが古くなり、追いつくには一つずつ順番に上げるしかありません。そのたびに破壊的変更への対応、依存関係の衝突の解消、回帰テストのやり直しが必要になります。

筆者はこの道を選びませんでした。代わりに Vibe コーディングを使いました。これは、開発者が自然言語で意図を伝え、コードの大半を AI が生成する進め方です。筆者は新しい Angular のバージョン上で、AI にアプリを書き直させ、構成も整理させました。中心にある主張は明快です。古いコードを少しずつ新しいバージョンへ運ぶのではなく、古いアプリを「振る舞いの仕様」とみなして、新しいバージョン上に作り直すという考え方です。

なお、元記事についてはプロジェクトの規模、所要時間、途中でつまずいた点といった検証可能なデータが、手元の資料にはありません。以下の分析は、Angular エコシステムに関する公開情報を土台にしており、元記事の数字には頼っていません。

深掘り分析

Angular のアップグレードは、なぜこれほど面倒なのでしょうか。Angular はおよそ半年ごとにメジャーリリースを出し、公式サポートの期間も限られています。そのためチームは歩調を合わせる必要があります。公式には ng update コマンドと移行用スキーマティクス（schematics）があり、よくある書き方の多くを自動で書き換えてくれます。ただし、自動化が及ぶのはルールが明確な部分だけです。 本当に時間を食うのは、ルールの外側です。サードパーティのコンポーネントライブラリが新しい版に追随しない。TypeScript やビルドツールの要件が同時に変わる。RxJS の使い方を調整する必要が出る。さらに Angular 自体のプログラミングモデルも変わってきました。スタンドアロンコンポーネントが NgModule に取って代わりつつあり、シグナル（signals）が新しいリアクティブな書き方をもたらし、テンプレートの新しい制御フロー構文が従来の構造ディレクティブを置き換えています。数バージョン遅れたプロジェクトは、これらの変化を順番にまたがなければなりません。各段階で回帰が入り込みやすく、途中の状態は長く保守されないことが普通です。

Vibe コーディングは、この問題の見方を変えます。新しい Angular の書き方は、AI が大量に生成しやすい対象です。画面、操作、業務ルールを説明すれば、AI は新しい書き方で直接コードを出せます。途中のバージョンはすべて飛ばせます。 この手法には三つの前提があります。第一に、信頼できる「振る舞いの基準」が必要です。エンドツーエンドテスト、API 契約、比較用のスクリーンショットなどがなければ、書き直したアプリが元と同等かどうか判断できません。第二に、AI の学習データには遅れがあります。廃止済みの API を出力することがあるため、公式ドキュメントとコンパイラの警告で縛る必要があります。第三に、書き直しは、古いコードが長年の修正で積み上げた境界条件の処理を捨ててしまいます。この暗黙知は、テストや人によるレビューで補わなければなりません。

業界への影響

まず変わるのは、アップグレード費用の計算方法です。従来、フレームワークの更新費用はバージョン差に応じて、直線以上の速さで膨らみました。そのため多くの企業は、セキュリティ上のリスクや人材の流出に迫られるまで、社内システムを古い版のまま放置してきました。もし小中規模のアプリで AI による書き直しが実用になれば、新しい選択肢が生まれます。差が開きすぎて段階的な移行が割に合わないとき、作り直すという道です。 技術選定にも影響します。Angular は、完結した標準機能と明確なアップグレード経路を長く売りにしてきました。React や Vue のプロジェクトでは、各チームが自分で構成を組み、更新の負担が複数のライブラリに分散します。AI が作り直しの費用を下げるなら、フレームワーク間の競争は、ドキュメントの質、規約の一貫性、そして AI が規約どおりのコードを安定して出せるかに寄っていくでしょう。規約が強く、パターンがそろったフレームワークは、AI 生成との相性が良いといえます。

手作業の移行を売りにする外注先やコンサルティングのチームは、圧力を受けます。価値は、コードを直接直すことから、受け入れ基準を決め、テストを設計し、リスクを管理することへ移ります。AI コーディングツールの提供側にとっては、Angular のアップグレードは分かりやすい適用場面です。目標が明確で、既存コードが仕様の代わりになり、結果をテストで確かめられるため、ゼロからの新規開発より効果を測りやすいからです。 ただし、過大評価は禁物です。大規模なアプリには、複雑な状態管理、権限モデル、過去データとの互換性要件があります。AI に一度で全面的に書き直させるのは危険です。現実的なのは、モジュール単位、あるいはルート単位で順に置き換えていく進め方でしょう。

今後の展望

注目すべき点がいくつかあります。一つ目は、Angular チームが AI を使った移行を公式ツールに取り込むかどうかです。モデル向けのドキュメント、標準化された移行プロンプト、エディタ内エージェントとの連携などが考えられます。そうなれば、アップグレードは確定的なスクリプトと AI による補完の組み合わせで行われるようになります。 二つ目は、検証可能な事例が出てくるかどうかです。アプリの規模、書き直しの所要時間、書き直し後の不具合率に加え、従来のバージョンごとの更新との比較があれば参考になります。現状は個人の経験談が中心で、比べるためのデータが足りません。 三つ目は、テストの質が分かれ目になることです。テストの網羅性が高いチームは、安心して AI に書き直しを任せられます。低いチームは、先にテストを整備する必要があります。AI はエンジニアリングの規律をなくすのではなく、その重心を「書くこと」から「受け入れること」へ移すだけだ、ということです。

四つ目はガバナンスです。AI が生成したコードは、新しい依存関係を持ち込み、既知の脆弱性も一緒に運んでくる可能性があります。コードの帰属やコンプライアンスの確認も追いつく必要があり、依存関係のスキャンは継続的に回すべきです。 古い Angular に悩むチームには、慎重な進め方が向いています。境界の明確な小さなアプリを一つ選びます。先に振る舞いのテストを書きます。AI に最新の Angular 上で作り直させます。そして比較結果を見て、大きなシステムへ広げるかどうかを決めます。