※本記事は、Mark Thompson氏(Google Angularチーム DevRelリード)による動画「What's new in Angular」の内容を基に作成されています。動画の詳細情報は https://www.youtube.com/watch?v=MbkjTNg2rcg でご覧いただけます。本記事では、動画の内容を要約しております。なお、本記事の内容は原登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご覧いただくことをお勧めいたします。また、関連情報として、Angularコンテンツ一覧(https://goo.gle/4uVfw2c)、Angular公式情報(https://goo.gle/3P9CAuS)、Angular Skills(https://goo.gle/4tyHwHD)、Angular MCPの始め方(https://goo.gle/4foegjh)、Chrome DevTools for Agents(https://goo.gle/42yBgop)、Angular + AIについて(https://goo.gle/3P3iZfS)もあわせてご参照ください。
1. オープニング
1.1 登壇者紹介とセッション概要
このステージに立てることを、とても嬉しく思っています。皆さんと一緒にこの時間を過ごせることに、心から感謝しています。まず皆さんにお願いがあります。座席の両脇に手を置いて、しっかりつかまっていてください。なぜなら、これから「Angularの最新情報」というエキサイティングな旅に出発するからです。この先の発表を楽しみにしている方は、ぜひ歓声を上げてください。素晴らしい反応をありがとうございます。皆さんは本当に最高です。
改めて自己紹介させてください。私はMarkです。GoogleのAngularチームでDevRelリードを務めています。この会場にいる皆さん、そして自宅から視聴し、フォローしてくださっている皆さん全員に、感謝を申し上げます。
Angularがどのように取り組みを進めてきたかについて、興味深いお話をさせてください。私たちは、ウェブの「次に来るもの」を構築するための、確かな土台であり続けることを目指してポジションを築いてきました。そして今日皆さんと過ごす時間の中で、私は大きく2つの柱についてお話しします。1つ目は、AngularのAPIについてです。私たちがどのようにAPIサーフェスを変化させてきたかをお伝えします。2つ目は、皆さんの多くが期待されているであろうテーマです。特にI/Oにお越しの方はご存知の通り、AIに関する話題が数多く語られていますが、Angularにも非常に説得力のあるAIストーリーがあります。今日この時間が終わる頃には、AngularがどのようにそのAPIを改善しているかをご理解いただけるはずです。そして、私たちがAIストーリーをどのように拡張してきたかについても、しっかりと実感していただけると思います。
さらに、私自身も非常に興味深いと感じているテーマがあります。それは、Angularが従来の開発者体験を超えて、どのようにしてより多くのユーザーに届くようにしているか、という点です。それでは準備はよろしいでしょうか。皆さんから大きな「イエー」をお願いします。会場からは力強い「イエー」という声をいただきました。こんな仕事ができるなんて、私は本当に信じられません。これは最高の体験です。
2. テンプレートと型安全性の進化
2.1 switch文の多重ケースマッチングと網羅性チェック
それでは、APIのアップデートについてお話しします。Angularチームが誇りに思っていることの一つは、Angularを変化させ、進化させ続けてきたという実績と評判です。今日使われているAngularは、5年前のAngularとは違いますし、3年前のAngularとも違います。私たちはその信頼と評判を築くために、本当に懸命に取り組んできました。
そして、APIサーフェス全体にわたってアップデートを届けてきました。Signalsで実現したこと、SSRで実現したことを思い浮かべていただければ、そこには多くの仕事があったことがお分かりいただけると思います。ただ、私が特に気に入っているのは、テンプレートまわりの改善です。私たちは「let」構文をリリースし、defer構文、そして拡張・刷新した制御フローも導入してきました。しかし、そこで止まってはいません。Angularのテンプレートは非常に優れていますが、control flowの大きなアップデートとして、あまり話題にならないものについてもお話ししたいと思います。switch文についてです。
ここに、皆さんが今日書いているコードで見かけるような、標準的な例があります。order statusというプロパティを使い、それぞれのステータスに対して表示メッセージを出す、というものです。ただ、よく見ると、2つのケースが同じ表示内容になっています。皆さんが自分のキーボードの前で「これは何かがおかしい」と感じている声が、もう聞こえてくるようです。これは冗長に感じられますし、ボイラープレートのように見えます。「チームはもっと良い方法を用意できないのか」という声もあるでしょう。実は、できます。今回、switch文に複数ケースの同時マッチングを導入しました。同じ出力を返す複数の条件がある場合、コードをより簡潔に書けるようになります。
これだけでも十分良い改善ですが、さらに良くすることができました。テンプレートでユニオン型を使う場合について考えてみてください。今回の例では3つの型を使いましたが、もしこれがさらに多くの型を含んでいたらどうでしょうか。ここで、非常に小さいながらも厄介なバグが発生することがあります。ユニオン型を扱っていて、そのユニオン型が変更された場合、UIはどうなるでしょうか。同期が取れなくなってしまうのです。これは、実際にそのバグに噛まれるまで気づかないような類いの問題で、気づいた時にはデバッグに多くの時間を費やすことになりますし、あるいはエージェントを使ってデバッグさせているとすれば、トークンを無駄に消費してしまうことになります。
こうした問題に対して、私たちはより良い解決策を用意しました。switch文に対する網羅性チェック(exhaustive check)という機能です。default caseを追加し、そこで「never」というキーワードを使うことで、非常に優れた効果が得られます。コンパイル時のエラーとして検出できるようになるのです。このコンパイル時エラーによって、コードを書いている最中にこのバグを事前に発見できるようになり、時間とフラストレーションの両方を節約できます。
2.2 テンプレート内インライン矢印関数
さて、switch文について長く語ってきましたので、少し話を切り替えたいと思います。Angularのテンプレートを書く際に、開発者の皆さんがやりたいと思っていることの一つが、関数をインラインで書くことです。何らかのロジックを実装したい関数があるものの、そのためだけにTypeScriptのクラスに別の関数を作りたくはない、というケースです。「もっと簡単にインラインで書けるようにしてほしい」という声があると思いますが、今回、それが可能になりました。テンプレートの中にアロー関数をインラインで書けるようになったのです。
ただし、長く複雑な関数を書き始める前に、いくつかガイドラインをお伝えしておきます。これは小さく、短く、素早く実行できる関数のためのものです。長時間実行されるようなロジックは、TypeScriptのクラス側に置くべきです。しかし、今回のアップデートのように、ちょっとしたものであれば、テンプレート内に書いて構いません。
変更検知(change detection)への影響を心配されている方もいるかもしれませんが、心配は要りません。コミュニティの中には、テンプレートから関数を呼び出すべきではないという考え方と、それで問題ないという考え方の、2つの立場があることは承知しています。私はAngularチームの人間として、はっきりとお伝えしたいと思います。短い関数であれば、それで問題ありません。自宅で見ている皆さんも、この表情を見てください。本当に、問題ないのです。
3. エラーバウンダリ(Boundary)
3.1 Boundaryの仕組みと導入例
ここで少し、皆さんに気持ちを共有させてください。ここは安全な場所でしょうか。皆さんが「イエス」と答えてくださったので、安心して気持ちを話させていただきます。私が話したいのは、テンプレートエラーについてです。私はこれを非常に厄介なものだと感じています。厄介であるだけでなく、対処が非常に難しい場合があります。特に、変更検知(change detection)のサイクルがクラッシュしてしまったときです。何が起こるかというと、画面が真っ白になってしまいます。ユーザーにとっては最悪の体験ですし、Angularとしては、もっと良い解決策を用意すべきだと感じていました。皆さんはどう思いますか。皆さんが「イエス」と答えてくださいましたが、私にはまだ納得していただけていないように見えます。もう一度聞きます。皆さんはどう思いますか。会場全体から「イエス」という声をいただきました。まさに私が言いたかったことです。もっと良い解決策が必要ですよね。それなら、Boundaryをご紹介します。
この構文を見て、会場や自宅で視聴されている皆さんの中には、すでにお気づきの方もいらっしゃると思いますが、これはAngularのテンプレートにおけるエラーバウンダリのための機能です。まず、どのような問題があるのかをお見せしてから、実際にどう動作するのかをご説明します。皆さんのアプリケーションには、クラッシュしてしまうコンポーネントやディレクティブが含まれていることがあり、それが変更検知サイクル全体をクラッシュさせ、あの悪名高い画面の真っ白な状態につながってしまいます。そうなってしまうと、今のところ打つ手がありません。具体例を通して、この問題を詳しく見ていきましょう。
この例では、コードと、それがブラウザ上でレンダリングされた出力の両方をお見せします。ここには、送料無料を知らせるプロモーション用のウィジェットがあります。もし何らかのバグが混入してこのウィジェットがクラッシュしたとしても、本来であればチェックアウトフロー全体を止めてしまうべきではありません。しかし実際には、クラッシュした場合にこうなってしまう、という状態になり得ます。ここで問題になるのは何でしょうか。時間が経つにつれて、ユーザーを失ってしまう可能性があるということです。特に収益が関わっている部分で、アプリケーションの収益が突然減ってしまうというのは、誰も望まないことです。そこで今回、テンプレートにBoundaryを追加できるようになりました。これによって、そのコード部分でのエラーを分離する方法が得られ、コンポーネントの残りの部分は引き続き動作するようになります。
さらに、この機能はそれだけにとどまりません。フォールバックUI、つまりバックアップとなるUIを用意することもできます。そして、これが今後どのように発展していくかを考えると、非常にわくわくします。たとえば、コンポーネントがクラッシュした場合に、意図的なリトライロジックを組み込むといったことも考えられます。これは本当にエキサイティングなポイントです。
3.2 将来構想とリリース方針
この機能は、2026年第3四半期にdeveloper previewとしてリリースされる予定です。ご存知の通り、Angularチームとしては正確な日付をお約束しないという方針を取っています。私たちは、準備が整うまで作業を続けるというスタンスです。ただ、これまでこの機能に取り組んできましたし、チームはこの機能について非常に高い期待感を持っています。今後数週間のうちに、さらに詳しい情報をお伝えできるはずです。
4. Signal FormsとAngular Aria
4.1 Signal Formsの設計と使い方
拍手をありがとうございます。皆さんは私にどれだけ拍手を送っても足りないくらいです。本当にそう思っていただいて構いません。それでは、皆さんにきっと気に入っていただけるであろう、いくつかのAPIアップデートについてお話しします。Signal Formsは、Angularコミュニティで大きな反響を呼んでいます。これは私たちの新しい、堅牢なフォームソリューションです。というのも、私たちはReactive FormsとStrongly Typed Formsの良い部分を取り入れ、そこにTemplate-Driven Formsで皆さんが気に入っていた部分、さらにSignalsの良さを組み合わせて、Signal Formsを作り上げたからです。そして皆さんからは、これを気に入っているという声をたくさんいただいています。ここに実際の声を紹介します。冗談です、実際には誰もそう言っていません。私がそう言っただけです。ですが、それが真実でないわけではありません。Signal Formsについては、非常にポジティブなフィードバックをいただいており、Angularにおけるフォームの組み立て方を大きく変えつつあります。
developer previewの段階だったため、まだ触れたことがない方もいらっしゃると思いますので、簡単な例を通してご紹介します。まず、シグナルでモデルを定義します。次に、Form関数をインポートし、そのモデルをForm関数に渡します。これで、Signal Formが手に入ります。ここまでで、すでに動くフォームができていますが、さらにスキーマを追加することもできます。そのスキーマの中で、バリデーションのような処理を行うことができます。組み込みのバリデータも利用可能です。この例では、requiredバリデータを使って、スキーマ上のpayment typeが必須であることを指定しています。
ただ、開発者の皆さんが実際に扱うユースケースは、これよりもずっと複雑なはずです。そこで、カスタムバリデーションの例をお見せします。validate関数を使ってカスタムバリデーションを定義する例です。ここでは、websiteの値がHTTPSで始まっているかどうかをチェックしています。対象となるフィールドと、それに対する処理を行う関数を渡します。ロジック自体は普通のTypeScriptなので、理解しやすいはずです。値が一致しなかった場合に返すエラーの内容も、この中で定義しています。つまり、どのような種類のエラーにするか、ユーザーにどのようなメッセージを見せるかを、開発者側で自由に決められるということです。そして、値が正しければnullを返します。
Signal Formsについては、最初の発表以降、裏側でずっと開発を続けてきました。新しく追加された点をいくつか紹介します。まず、ドキュメントを一式整備しました。また、皆さんが実際に試して寄せてくださったフィードバックをもとに、多くのバグを修正してきました。そして、Angular AriaとAngular Materialへのフルサポートが実現しました。これは本当にエキサイティングなポイントで、Signal Formsは、Angular v22で安定版(stable)になる予定です。つまり、本番アプリケーションでも自信を持って使っていただけるようになります。私にとって、Signal FormsはAngularの明るい話題の一つですが、もう一つの明るい話題がAngular Ariaです。
4.2 Angular Ariaの概要とスタイリング
Angular Ariaは、完全にアクセシブルで、かつ完全にカスタマイズ可能なUIディレクティブとパターンの集合です。Angular Ariaという概念自体は、少し掴みにくいと感じられることがあるので、具体的な例を通してご説明するのが一番良いと思います。ここに、スタイルを一切適用していないAngular Ariaのツールバーがあります。これは、私たちが提供する素の状態、つまり基本的なHTMLそのものです。この状態でも、すでに完全にアクセシブルであり、ロジックを適用できる準備が整っています。ただ、もう少し見た目を工夫してみましょう。私の目標は、これをユーザー向けにネオンなSFテイストのテーマに仕上げることです。
コンポーネントのテンプレートでは、マークアップはこのようになります。少し省略していますが、ここではngToolbarとngToolbarWidgetという2つのディレクティブが使われている点に注目してください。Angular Ariaのツールバーコンポーネントで期待されるアクセシビリティ機能をすべて有効にするには、この両方が必要です。では、どうやって見た目を良くするのかというと、皆さんがすでに持っているスキルをそのまま適用するだけです。CSSのスキル、皆さんのスタイル、デザインシステムなど、普段お使いのものをそのまま適用していただければ結構です。この例では、gap、display、padding、border-radiusといったプロパティを適用して、目指す見た目を作っています。そして、こちらが実際の仕上がりです。ここまでの過程で、裏側で何か特別な魔法を使ったわけではありません。ここで使ったコードはすべて、angular.devなどで確認していただけます。Angular Ariaのコンポーネントを自分たちのニーズに合わせてスタイリングする方法について、豊富なコード例を用意しています。
最初にAngular Ariaを紹介した時点から、どのように改善してきたかをお話しします。まず、APIがより洗練され、コミュニティの皆さんから寄せられた多くの要望に対応してきました。Signal Formsへのフルサポートも実現しています。そして、これは大きなポイントですが、テストを行いたいという声にお応えして、Angular Ariaのコンポーネントおよびディレクティブ向けのテストハーネスが利用可能になりました。先ほどお見せしたのはツールバーの例でしたが、Angular Ariaのパターンは、現時点で少なくとも11種類が用意されており、さらに増える予定です。これらのパターンを組み合わせて、皆さんのユーザーのために必要なものを作り上げていただけます。皆さんがスタイルとビジネスロジックを担当し、私たちがアクセシビリティを担当することで、ウェブをどのように利用するユーザーであっても、しっかりとサービスを提供できるようになります。Angular Ariaも、Angular v22で安定版になる予定の機能の一つです。
私たちとしては、皆さんが自信を持って開発できるように、信頼できるAPIをできるだけ多くStableの状態にしたいと考えています。Signal FormsやAngular Ariaだけでなく、非同期のリアクティビティAPIであるresourceとhttpResourceについても、いよいよ本番運用へと移行します。すべてがStableへと進んでいくということです。ここでも、開発者として求めている自信を持って利用していただけます。これらのアップデートについての詳細は、Angular.devでご確認いただけます。
5. 安定化とAIストーリーの幕開け
5.1 API安定化とAI技術動向への所感
拍手をありがとうございます。本当に嬉しく思います。さて、いよいよ多くの皆さんがお待ちだったであろう瞬間です。AngularのAIストーリーは、今どうなっているのでしょうか。昨年、私はこの同じステージに立ち、誇らしい気持ちと喜びに満たされながら、angular.dev/aiという、Angularを使う開発者のためのAIのホームをご紹介しました。あれから、私たちはそのストーリーを大きく拡張してきました。今、開発者がどのようにAIを使って開発できるのかについてお話しします。
AIはこの半年ほどで、本当に大きく変化しました。半年前のことを振り返ってみてください。世界はそれ以来、非常に速いスピードで動いてきました。当時、私たちはMCPを素晴らしいものだと思っていました。その後、少しの間、「MCPは本当に必要なのだろうか」と感じる時期もありました。しかし今、MCPはかつてないほど強力になっていますし、さらにAgent Skillsという新しい要素も加わっています。使えるテクノロジーは本当にたくさんあり、素晴らしいアプリケーションを構築できるようになっています。そして、新しいアイデアの流れが止まることはありません。Angularチームとしては、皆さん開発者が、エージェントやAIツールを使い、それぞれの好きなやり方でアプリケーションを構築できるようにするには、どうすればよいのかを、できる限り思慮深く、意味のある形で考え続けています。
5.2 Angular MCPの概要とツール群
その最初の要素が、Angular MCPです。MCP、すなわちModel Context Protocolは、エージェント的な環境に対して、タスクを遂行するために必要なツールを与える仕組みです。Angular MCPには、あらかじめいくつかの特別なツールが備わっています。たとえばAI Tutorがあり、これはエージェントがより現代的なコードを書けるように、例やベストプラクティスを探し出すことができます。ほかにも数多くのツールがありますが、今回、皆さんにきっと気に入っていただけるであろう新しい機能を追加しました。
私自身、アプリケーションを書いていて特に難しいと感じてきたのは、サーバーのビルドをng buildに頼らざるを得ない点でした。使っているエージェント的なツールによっては、このワークフローがどこかちぐはぐに感じられることがあります。そこで今回、MCPツールを新たに追加しました。一つはdevserver.wait_for_buildです。これによって、エージェントがビルドを実行し、その出力を待ち、出力内容を確認したうえで、その結果をもとに次に何をするかを判断できるようになります。それに加えて、devserver.startも用意しました。エージェントがブラウザ上でアプリケーションを起動したい場合や、何らかの作業を行いたい場合に、MCPサーバー側からその制御を行えるようになります。また、devserver.stopもあり、エージェント側の視点からサーバーを停止できるようにしています。
これだけではありません。Angular MCP、AI Tutor、そして新しいdevserver系のコントロール群など、皆さんがウェブの次なるものを構築するために活用できるツールが数多く揃っています。ほかにも、Angularアプリケーションをモダナイズできる箇所を特定するのに役立つModernize toolや、Onpush Migrationといったツールもありますし、私たちは今も、他に何ができるかを常に考え続けています。Angular MCPを使い始めたい場合は、ng mcpを実行していただければ、エージェント的な環境に追加するための設定を取得できます。
6. MCPとAgent Skillsによるエージェント体験の深化
6.1 MCP連携デモ(Chrome DevTools for Agents)
ここから、もう少し踏み込んだお話をしたいと思います。私自身の開発経験の中で気づいたのは、複数のMCPサーバーやツールを組み合わせることで、本当に特別な、素晴らしい開発者体験を作り出せるということです。それでは、Angular MCPとChrome DevTools for Agentsを組み合わせると、何が起きるのかを見ていきましょう。私が実際に実行したプロンプトの例をご紹介します。私は、このアプリケーションのHomeページを更新して、映画館のような上映時間表示のようなパフォーマンスの表示を追加したいと考えました。ただ、それだけでなく、Homeページのスクリーンショットを撮って、変更が本当に反映されているかを確認したいとも思いました。なぜそうしたいのかというと、皆さんの中にも、エージェントに何かをお願いしたときに、「やりました」と言われたのに、実際には何もされていなかった、という経験がある方がいらっしゃるのではないでしょうか。そして、「お願いしたことをやってと言いましたよね」と伝えると、「おっしゃる通りです」と返ってくるものの、それでもまだ実行されていない、というループに陥ってしまうことがあります。そこで今回、私はさらに一歩踏み込んで、スクリーンショットを使って実際に作業が行われたことを検証してほしい、とお願いしました。
このワークフローがどのようなものになるかをお見せします。まず、Angular MCPを使ってアプリケーションをビルドします。次に、エージェントがstartコマンドを使ってアプリケーションを起動します。それから、Chrome DevTools for Agentsに制御を渡し、実際にブラウザへアクセスしてもらいます。ここからが、本当に面白くなってくるところです。そして、Chrome DevTools for Agentsにスクリーンショットを撮ってもらうよう依頼することもできます。ここまでは文章での説明でしたが、これだけではあまり実感が湧かないと思いますので、実際の動作を見てみましょう。この例では、まずCLIツールにプロンプトを入力しています。エージェントが考え始めると、どのツールを使うべきかを判断していく様子が見えます。コードを読み込み、コードの変更を加え始めました。その過程で、すでにwait_for_serverを使っている様子が確認できます。これによって、出力の一部を取得し、その内容をもとに次に何をするかを判断できるようになっているのです。そして、ブラウザ上で変更内容を確認するために開き、最後にスクリーンショットを実際に確認しました。これは小規模なアプリケーションでの例ですが、複数のMCPサーバーを組み合わせることで、こうした高度なエージェント的ワークフローをどれだけのことに応用できるか、ぜひ想像してみてください。今後もこうした変更が本当に実行されたかどうかを疑う必要がなくなっていきます。これは、今後の開発のあり方にとって、非常に大きな力になります。Angular MCPを使い始めたい方は、angular.dev/ai/mcpをご覧ください。また、Chrome DevTools for Agentsについては、github.com/ChromeDevTools/chrome-devtools-mcpをご確認ください。
6.2 Agent SkillsとAngular Skills
次にお話ししたいのは、Agent Skillsです。私自身、Agent Skillsというメンタルモデルをとても気に入っています。これは、トレーニングデータと新しいAPIとの間にあるギャップを埋めるために、エージェントをどのように強化すればよいかを理解するうえで役立つ考え方だからです。たとえば、先ほどもお話ししたように、Angularは常にAPIをアップデートし、サーフェスを拡張し続けています。しかし、トレーニングデータが作られるタイミングは、私たちがコントロールできるものではありません。そこでAgent Skillsを使うことで、Angular AriaやSignal Formsといった機能について、モダンなAngularアプリケーションを構築するために必要なスキルやツールを、エージェントに与えられるようになりました。
最初にご紹介したいのは、Angular開発者スキルです。このスキルは、モダンなAngularアプリケーションを構築するための基本要素をカバーしています。ただ、ここで素晴らしいのは、単にドキュメントをそのままスキルファイルに詰め込んだものではない、という点です。私たちはこれを140行未満のコードにまで最適化しました。そして、プログレッシブディスクロージャーという手法を使っているため、その時点で必要な部分のスキルだけが読み込まれるようになっています。さらに情報が必要になった場合には、必要に応じて読み込まれる参照ファイル一式も用意しています。これがAngular開発者スキルです。
ほかにも新しいAngular Skillsがあります。その一つがangular-new-appです。Angularについて多くのことを耳にしてきたものの、新しいエージェント的開発環境を使っていて、まだ何も環境構築ができていない、という場合には、angular-new-appスキルをAngular開発者スキルと組み合わせて使うことで、Angularを使うための環境設定を行うことができます。
それだけではありません。この会場や自宅で視聴されている皆さんの中には、Angularへのコントリビューターとして、プルリクエストを送りたいと考えている方もいらっしゃると思います。ただ、どこから始めればよいのかを把握するのは、実はとても難しいことの一つです。そこで、エージェント、そして人間にとっても、コントリビューターになるために必要なメンタルモデルを理解できるよう、コントリビューター向けスキル一式を用意しました。私自身もこれらに目を通してみて、実際に役立つと感じています。というのも、AngularのAPIサーフェスは非常に広範で、しっかりしたものであるため、すべてを把握するのは簡単ではないからです。ただ、これらのスキルがあることで、変更を加えたいときにどこから始めればよいかが分かりやすくなります。ぜひangular/angular/agentディレクトリにあるコントリビューター向けスキルを確認してみてください。
Angular Skillsは本日から利用可能です。皆さんが普段お使いのエージェント的な開発環境で、ぜひ活用していただき、感想をお聞かせください。何か問題が発生した場合や、フィードバックがある場合には、ぜひGitHub issueを立てて、私たちにお知らせください。どれだけ気に入っているか、どれだけ素晴らしいと感じているか、そして今後さらに増えることをどれだけ楽しみにしているか、といったお声も、ぜひお待ちしています。
7. Vibe Coding:開発者を超えた広がり
7.1 Gemini Canvasによるアプリ作成デモ
それでは、Vibe Codingについてお話しします。開発の世界では、自分自身を「ビルダー」と呼ぶ新しいコミュニティが大きく広がりを見せています。彼らは、自分のアイデアを形にしたいと考えている人たちですが、コードを書くスキルは持ち合わせていません。それでも、私はこう感じています。素晴らしいアプリを作りたいという気持ちがあるなら、私たちはその方々を歓迎します。コードが書けるかどうかにかかわらず、Angularを使って、次の素晴らしいアイデアを形にすることができます。
そのために、私たちが実現してきた方法の一つをご紹介します。私たちはGemini Canvasチームと密接に協力し、ウェブアプリ向けに、プロンプトの中で使いたい技術、この場合はAngularを指定するだけでアプリケーションを作成できる仕組みを実現しました。ここで少し個人的な話をさせてください。私の子どもはスポーツをやっていて、おやつを持ってくる当番を親同士で順番に回しているのですが、正直に言うと、当番をきちんと回してくれない親御さんもいます。私はもう、いつも自分ばかりおやつを持っていくことに疲れてしまいました。そこで、誰がおやつの当番かを管理してくれるアプリを作ることにしました。ここに、その一つのプロンプトから得られた結果をお見せします。そして、これはこのVibe Codingの体験でできることの、ほんの入り口にすぎません。このコードをそのまま使い、Geminiとチャットしながら、Angularのままさらに拡張していくこともできますし、コードをダウンロードして自分自身で変更を加えることもできます。どの環境で作業するかは、皆さん次第です。どのようなやり方で進めたいかに応じて、自由に選んでいただけます。
7.2 Google AI Studioによるアプリ作成デモと展望
Google AI Studioについてもお話しします。彼らは、Vibe Codingの体験において、新しい取り組みを数多くリリースしました。ここで、実際にできることの一つをご紹介します。まず、始めたい場合には、設定パネルの中で使いたい技術を選択でき、そこでAngularを選ぶことができます。ここでもう一つ、親として抱えている不満をお話しさせてください。皆さんが「ここは安全な場所だ」とおっしゃってくださったので、私はここで自分の気持ちをすべて吐き出させていただいています。私が算数、特に九九を覚えたときは、何度も何度も書いて覚えたものです。ところが、子どもの担任の先生からは、一日中、算数の暗記問題を出して確認するように言われています。つまり、「ねえ、5かける5は?」「4かける8は?」と、子どもに歩き回りながら聞き続けなければならないということです。誰もそんなことはしたくありません。私もしたくありません。ただ幸い、私には知恵があり、その知恵を後押ししてくれるツールがあります。そこで、こういうプロンプトを書きました。「三年生の息子が九九を練習できる、算数の練習アプリが欲しい。フラッシュカード形式にして、苦手な計算を記録・追跡できるようにしてほしい」というものです。そして、これが私のワンショットの結果です。これは、たった一度のプロンプトから得られたものであり、それ以上の編集は加えていません。ただ、このアプリはブラウザ上でさらに改良を加えることもできますし、Geminiとチャットしながら、Firebaseのようなツールを追加することもできます。ブラウザ上だけで、本当に多くのことができるのです。
ここで皆さんに考えていただきたいのは、Vibe Codingの力が、単に「誰がコードを書けるか、書けないか」という話にとどまらないということです。むしろ、皆さんが今まで時間を割けなかったことを形にできる機会だと捉えていただきたいのです。そして今、それを実現するためのツールが、皆さんの手元にあります。さらに、Google AI Studioでvibe codingしたものを、自分のIDEに持ち込んで作業を続けることもできます。皆さんはAngularのプロフェッショナルであり、必要なスキルをすでにお持ちですから、あらゆるツールを活用して、次の素晴らしいアプリケーションを作り上げていただければと思います。
8. クロージング
8.1 総括とAngular v22の展望
Angular開発者であることが、これほど素晴らしい時代はありません。私たちがどのようなことに取り組んできたか、皆さんにもお分かりいただけたと思います。新しいBoundaryが登場し、テンプレートを改善してきました。そして、これは開発者だけに恩恵をもたらすものではありません。エージェントにも、それぞれのコーディングの流儀があるため、私たちはそこにも手を加えてきました。「なるほど、それなら追加する意味がある」と考え、対応を進めてきたのです。おかげで、エージェント的なワークフローもよりスムーズになっています。私たちは、MCPツールと新しいAngular Skillsによって、AIストーリーを拡張してきました。ぜひ皆さんに試していただきたいと思っています。
そして、Gemini CanvasやAI Studioといったチームとの統合についても考えてみてください。開発者の皆さんが、ウェブ上で、Angularという、スケーラブルなウェブアプリケーションを構築するための強力なフレームワークを使って、アプリケーションを作れるようにするための取り組みです。今や、ウェブアプリを作ることができるのです。なんとも生きていて良かったと思える時代です。Angularは、ウェブの「次に来るもの」を構築するための、確かな、そして揺るぎない土台であり続けます。
そして、Angular v22では、このストーリーがさらに続いていきます。開発者の皆さんに向けて、さらに多くの新機能を発表する予定です。Angular v22は、2026年6月3日の週にリリースされます。ぜひ、その情報をチェックしてください。
今日お話ししてきた内容について、さらに詳しく知りたい方、そしてAngularの今後の情報をキャッチアップしていきたい方は、ぜひangular.devをご覧ください。
そして、今日ここに集まってくださったこと、本当にありがとうございました。皆さんは本当に素晴らしかったです。ぜひ、素晴らしいアプリケーションを作りに出かけてください。それでは、また。