AIコーディング時代に再評価したい、Angularという選択肢
はじめに
GitHub CopilotやClaude、ChatGPTといったAIツールを活用したコーディングが当たり前になってきました。僕自身も日常的にAIの力を借りながら開発を進めているのですが、ある時ふと気づいたんですよね。
「フレームワークによって、AIが生成するコードの品質が全然違う」
React/Next.jsで開発していたときは、AIに任せるとコンポーネント内にロジックが混在したり、hooksが肥大化したりと、後から整理が必要なコードが生まれがちでした。ところがAngularに切り替えてみると、AIが生成するコードが不思議と整っている。
この違いはどこから来るのか。考えてみると、Angularの設計思想そのものがAIコーディングと相性が良いのではないか、という仮説に至りました。
「自由」と「制約」のトレードオフ
フロントエンドフレームワークを選ぶとき、React系の「自由度の高さ」は大きな魅力です。コンポーネントの書き方、状態管理の方法、フォルダ構成など、開発者が自分の好みで決められる。それはつまり、ベストな選択を自分でできるということでもあります。
ただ、AIと協働するという観点で見ると、この自由度が仇になることがあるんですよね。
AIは過去の膨大なコードを学習しています。Reactの場合、その「膨大なコード」の中には様々なスタイルが混在している。クラスコンポーネントもあれば関数コンポーネントもある。状態管理はReduxかもしれないしContext APIかもしれない。hooksで完結させるかもしれない。
AIに「ユーザー一覧を表示するコンポーネントを作って」と頼むと、学習データに基づいて「ありそうな」コードを生成します。でもそれが今のプロジェクトの方針と合っているかは保証されない。結果として、同じプロジェクト内でスタイルがバラバラになっていく。
一方Angularは、フレームワークレベルで構造が決まっています。ComponentはUIを担当し、Serviceがビジネスロジックを持ち、Moduleで機能をまとめる。この「制約」があるからこそ、AIが生成するコードも自然とその枠組みに収まるんです。
TypeScriptとの一体感
Angularを語るうえで外せないのが、TypeScriptとの関係性です。
ReactでTypeScriptを使うことはもちろん可能ですし、今では多くのプロジェクトがそうしているでしょう。でも、ReactはもともとJavaScriptのライブラリとして生まれたもの。TypeScriptは後から「使える」ようになったものなんですよね。
対してAngularは、最初からTypeScriptで書かれることを前提に設計されています。デコレーターによるメタデータの付与、DIコンテナとの連携、テンプレート内の型チェックなど、TypeScriptの機能がフレームワークの根幹に組み込まれている。
この違いはAIコーディングにおいて結構大きくて、Angularの場合はAIが生成するコードの型が一貫しやすいんです。ComponentのInputやOutput、Serviceの戻り値など、「こう書くべき」という型のパターンが明確だから、AIもそれに従ったコードを出力する。
Reactのhooksは柔軟で便利ですが、その分だけ型定義のパターンも多様になります。useStateの初期値、useEffectの依存配列、カスタムhooksの返り値など、AIが「最適な型定義」を判断するのは難しい場面も多い。
依存性注入という設計パターン
AngularのDI（依存性注入）コンテナは、コードの構造化に大きく貢献しています。
Serviceを作成すると、自動的にシングルトンとしてアプリケーション全体で共有される。あるいはModuleやComponentレベルでスコープを制御することもできる。このDIの仕組みが、自然とコードの責務分離を促すんですよね。
Reactでも依存性注入の概念を取り入れることは可能です。Context APIを使ったり、外部ライブラリを導入したり。でも、それは「やろうと思えばできる」レベルであって、フレームワークが強制してくれるわけではない。
AIにコードを書かせるとき、「テストしやすいコードにして」と頼むことがあります。Angularの場合、DIが標準装備されているので、AIは自然とDIを活用したテスタブルなコードを生成してくれる。一方Reactでは、テスタビリティを確保するためのパターンがプロジェクトによって異なるので、AIの出力が期待と合わないことも少なくなかった。
CLIが生み出す一貫性
Angularには強力なCLIツールがあります。
ng generate componentでコンポーネントを作成すると、ファイル構成、命名規則、モジュールへの登録まで自動で行われる。ng generate serviceでサービスを作れば、適切なデコレーターが付与された状態でファイルが生成される。
このCLIの存在が、プロジェクト全体のコードスタイルを統一してくれるんです。
AIコーディングでこれが効いてくるのは、「既存のパターンに合わせた生成」をAIに期待するとき。CLIで作られた既存のコードがあると、AIはそのパターンを参考にして新しいコードを生成しようとする。プロジェクト内の一貫性が保たれている分だけ、AIの出力も安定するわけです。
Next.jsにもCLIはありますが、生成されるのはあくまで「箱」であって、中身の書き方まで規定してくれるわけではないですよね。
NgRx、Pipe、Guard、そしてライフサイクル
Angularのエコシステムには、状態管理のNgRx、データ変換のPipe、ルーティング制御のGuardなど、「こういうときはこう書く」というパターンが確立されたツールが揃っています。
NgRxのEffectを使えば、非同期処理の副作用を一箇所にまとめられる。Pipeを使えば、表示ロジックをコンポーネントから分離できる。Guardを使えば、認証状態に基づくルーティング制御がクリーンに書ける。
そしてライフサイクルフック。OnInit、OnDestroy、OnChangesといったインターフェースを実装することで、コンポーネントのライフサイクルに応じた処理を明確に定義できる。
これらの「パターン」が確立されていることで、AIに「認証ガードを追加して」「日付フォーマット用のパイプを作って」と頼むと、期待通りの構造でコードが生成されるんです。
学習コストは投資になる
正直に言うと、Angularの学習コストは決して低くありません。RxJSのオペレーター、DIの仕組み、デコレーターの意味、NgRxのStore/Action/Reducer/Effectパターンなど、理解すべきことは多い。
でも、AIコーディングという観点で考えると、この学習コストは「投資」として考えられるかもしれません。
フレームワークの仕組みを理解していれば、AIが生成したコードが正しいかどうかを判断できる。「なぜこのパターンで書くのか」がわかっていれば、AIへの指示もより具体的になる。結果として、AIとの協働がより効率的になる。
Reactの「すぐに始められる」という手軽さは魅力的ですが、AIコーディング時代においては、「深く理解していることで得られるメリット」の価値が相対的に上がっているように感じます。
得られた学びと今後の展望
この記事で伝えたかったのは、「Angularが最高でReactはダメ」ということではありません。それぞれのフレームワークに良さがあり、プロジェクトの性質によって最適解は変わります。
ただ、AIコーディングという新しい開発スタイルにおいて、Angularの「制約」が持つ価値を再評価してもいいのではないか、と思うんです。
これからもAIツールは進化していくでしょう。より賢く、より柔軟に、様々なスタイルのコードを生成できるようになるかもしれない。でも少なくとも今の段階では、「明確なパターン」を持つフレームワークとの相性が良いように感じています。
次のプロジェクトでフレームワークを選ぶとき、AIとの協働を意識した選択肢として、Angularを検討してみてはいかがでしょうか。
Discussion