[Angular初心者🔰]Signalを使う上で気をつけること 〜Deep-mutationの落とし穴〜

はじめに

現場でAngularを触るため、キャッチアップをしなければならなくなったのですが、公式ドキュメントのSignalのページ内の一文の理解につまづきました。

IMPORTANT: The readonly signals do not have any built-in mechanism that would prevent deep-mutation of their value.(重要: 読み取り専用シグナルには、値の深部変異を防止する組み込みメカニズムがありません。)

「深部変異？」

しかし、Geminiと壁打ちしながら、「ああ、そういうことか」となるところまで辿り着くことができました。
実装時やコードレビュー時に非常に重要なポイントであることがわかったため、今回は公式で警告されている「Deep-mutation（深い階層の変更）」の落とし穴について、「Signal APIの仕組み」と「JavaScript (TypeScript) の性質」の両面から分かりやすく解説します。

1. そもそも Angular の Signal とは？

Signalは、Angular v16で開発者プレビューとして導入され、v17で安定版となった新しいリアクティブな状態管理の仕組みです。簡単に言うと「値の変化を追跡できる賢い箱」のようなものです。

const count = signal(0); // 箱に 0 を入れる
console.log(count()); // 箱の中身を見る -> 0

count.set(1); // 箱の中身を 1 に入れ替える（ここでUI等に変更が通知される）

最大の特徴は、.set() や .update() で値が更新されたタイミングで、そのSignalに依存しているテンプレート（HTML）や関数だけをピンポイントで再計算（再描画）できる点にあります。従来の仕組み（Zone.jsを用いた変化検知）よりも、はるかに軽量で予測しやすい動作になります。

2. Signal APIが保護している範囲

Signal（特に読み取り専用のSignal）は、.set() や .update() といったシグナルそのものの値を置き換えるメソッドを隠蔽してくれます。
これにより、意図しない場所からSignal自体の値が書き換えられることを防ぐことができます。

しかし、シグナルが「オブジェクト」や「配列」を保持している場合、そのプロパティを直接操作することは JavaScript (TypeScript) の言語仕様上可能です。

TypeScriptにおけるオブジェクト、配列については、以下を参照してください。

• オブジェクト
• 配列

3. Deep-mutation（深い階層の変更）とは何か

では、実際にこの「直接操作できてしまう」問題はどのような形で現れるのでしょうか？具体的なコード例を見てみましょう。

import { signal } from '@angular/core';

const user = signal({ name: 'Yamada', age: 30 });
const readonlyUser = user.asReadonly(); // 読み取り専用のSignal型

// ❌ これはコンパイルエラーになる（Signal APIが保護している）
// readonlyUser.set({ name: 'Taro', age: 31 }); 

// ⚠️ しかし、これは実行できてしまう（これが deep-mutation）
readonlyUser().name = 'Taro'; 

このとき、readonlyUser().name = 'Taro' という操作は、シグナルという「箱」を入れ替えているわけではなく、箱の中にあるオブジェクトのメモリ番地を辿って中身を書き換えている状態です。そのため、Angularの Signal 型（readonly）のままでは、この操作をデフォルトではコンパイルレベルで防ぐことができません。

4. なぜこれが危険なのか？ 〜変更が検知されない恐怖〜

この問題の最大の危険性は、Angular側で変更を検知できなくなるからです。

• 正常な動作: .set() や .update() を使うと、シグナルは「値が変わった！」と周囲（依存関係）に通知します。
• Deep-mutationの問題: オブジェクトのプロパティを直接書き換えても、シグナル側は「保持しているオブジェクト（参照先）自体は変わっていない」と判断します。そのため、変更通知が発生しません。

結果として、「データを書き換えたはずなのに画面が更新されない」「computed が再計算されない」「effect が発火しない」といった、追跡が難しいバグの原因になります。

具体的に、コンポーネントのUIが更新されなくなってしまう実際の失敗例を見てみましょう。

import { Component, signal } from '@angular/core';

@Component({
  selector: 'app-user-profile',
  template: `
    <div>
      <!-- 画面には常に "Yamada" と表示されたままになる -->
      <p>名前: {{ user().name }}</p>
      <button (click)="updateName()">名前を変更</button>
    </div>
  `,
  standalone: true
})
export class UserProfileComponent {
  user = signal({ name: 'Yamada', age: 30 });

  updateName() {
    // ⚠️ Deep-mutation: プロパティを直接書き換える
    this.user().name = 'Taro'; 

    // 変数の値自体は 'Taro' に書き換わっている（コンソールには Taro が出る）
    console.log(this.user().name); 

    // しかし、Signal自体の参照が変わっていないためAngularは変化を検知できず、
    // 画面上の {{ user().name }} はいっさい再描画されない！
  }
}

このように、「コンソールのログは変わっているのに、画面が切り替わらない」という非常に厄介な状態を引き起こします。

5. 回避・対策するためのベストプラクティス

この問題を避け、Signalのリアクティブな性質を安全に保つためには、以下の手法が推奨されます。

① イミュータブル（不変）な操作を徹底する

オブジェクトや配列の値を変更する際は、直接プロパティを書き換えるのではなく、常に「新しいオブジェクト」を作成して .set() または .update() で流し込みます。

// ❌ 悪い例（Deep-mutation）
// this.user().name = 'Taro';

// ⭕️ 良い例（イミュータブルな更新）
this.user.update(u => ({ ...u, name: 'Taro' }));

配列の場合も同様に、既存の配列を直接操作するのではなく、新しい配列を作成して置き換えます。

// ❌ 悪い例（Deep-mutation）
// this.items().push({ id: 4, label: 'New' });

// ⭕️ 良い例（イミュータブルな更新）
this.items.update(list => [...list, { id: 4, label: 'New' }]);

② TypeScriptの Readonly ユーティリティ型を指定する

シグナルの型定義自体に TypeScript の Readonly （または ReadonlyArray など）を指定し、プロパティへの代入をコンパイルエラーにしてしまう手法です。

// 型定義で「箱の中身」への書き換えを防ぐ
const user = signal<Readonly<{name: string, age: number}>>({ 
  name: 'Yamada', 
  age: 30 
});

// ❌ コンパイルエラーになるため、事前にミスに気づける
// user().name = 'Taro'; 

③ インターフェースの各プロパティを readonly にする

あらかじめ定義するインターフェースのプロパティそのものに readonly 修飾子を付与し、不注意な上書きを防ぐ手法です。

// インターフェース定義で各プロパティを読み取り専用にする
interface User {
  readonly name: string;
  readonly age: number;
}

const user = signal<User>({ name: 'Yamada', age: 30 });

// ❌ プロパティ自体が読み取り専用なので代入できない
// user().name = 'Taro'; 

💡 実務での推奨方針
実務においてはプロジェクトの規約にもよりますが、基本的には**「① イミュータブルな更新」を徹底しつつ、さらに安全性を担保したいモデルに対しては「③ インターフェースで readonly を付与する」**というアプローチを組み合わせるのが、最も安全でおすすめです。

6. 他のフレームワークでの扱いは？（Jetpack Compose, React）

実は、この「Deep-mutationが検知されない」という挙動は、AngularのSignal特有の欠陥ではなく、**多くの最新UIフレームワークで共通して採用されている設計思想（パフォーマンスと予測可能性の重視）**によるものです。

Jetpack Compose の MutableState

例えばAndroid開発で使われるJetpack Composeの MutableState（mutableStateOf）でも、基本的にはAngularのSignalと全く同じ問題が発生します。
MutableState に通常のミュータブルなオブジェクトを入れ、そのプロパティだけを直接書き換えても再コンポーズ（再描画）はトリガーされません。

// Composeの例（Angularと同じくDeep-mutationは検知されない）
val user = remember { mutableStateOf(User("Yamada", 30)) }

// ❌ オブジェクト内のプロパティを直接書き換えても再描画されない！
Button(onClick = { user.value.name = "Taro" }) { Text("Update") }

// ⭕️ data classの copy() を使って全く新しいインスタンスをセットする必要がある
Button(onClick = { user.value = user.value.copy(name = "Taro") }) { Text("Update") }

Composeでも「オブジェクトの内部プロパティにリアクティブ性を持たせたい場合は、プロパティ自体をそれぞれ個別の MutableState にする」か、「data class を使って常にイミュータブルな更新（copy()）を行う」ことがベストプラクティスとされています。

React の useState

Reactの useState も同様に、オブジェクトのプロパティを直接書き換えても（state.name = 'Taro'）、オブジェクト自体の参照（メモリ番地）が変わらないため再レンダリングされません。スプレッド構文などによる、新しいオブジェクトへの置き換えが必須です。

// Reactの例
const [user, setUser] = useState({ name: "Yamada", age: 30 });

// ❌ 参照が変わらないため再レンダリングされない
user.name = "Taro";
setUser(user);

// ⭕️ 新しいオブジェクトをセットする
setUser({ ...user, name: "Taro" });

7. ポインタ・メモリアドレスから理解するDeep-mutation（解説）

ここからは、社内のシニアエンジニアの方にレビューいただき、

「ポインタ」という観点で理解するとより深く理解できるのでは？

と指摘いただいた内容をもとに、自分がいかに上部だけの理解をしていたかに気づけたため、番外編として紹介させていただきます。

7-1. 「メモリアドレス」とは？

基本情報技術者などで学習されているとおり、コンピュータのメモリ（RAM）は、膨大な量のデータを格納するための箱がずらっと並んだ本棚のようなものであることがご理解いただいている通りです。
その上で、メモリアドレスとは、その本棚のそれぞれの棚に振られた「住所番号」にあたります。プログラムが扱うすべてのデータは、この住所のどこかに保管されています。

メモリ（本棚のイメージ）
┌──────────┬──────────┬──────────┬──────────┬───
│ 番地 0x01 │ 番地 0x02 │ 番地 0x03 │ 番地 0x04 │ ...
│  データA  │  データB  │  データC  │  データD  │
└──────────┴──────────┴──────────┴──────────┴───

7-2. 「ポインタ」とは？

C/C++やGoでは、ポインタという概念が明示的に登場します。
ポインタとは「データそのもの」ではなく、データが保管されている住所（メモリアドレス）を記録したメモのようなものです。

ポインタ変数 user         メモリ上の実データ
┌─────────────────┐      ┌─────────────────────────┐
│ 住所: 0x03 を指す │ ──→ │ 番地 0x03:               │
│                 │      │  { name:"Yamada", age:30 }│
└─────────────────┘      └─────────────────────────┘

JavaScript/TypeScriptでは「ポインタ」という用語は使いませんが、オブジェクトや配列を変数に代入したとき、変数が内部的に保持しているのはデータそのものではなく「メモリ上の住所（参照）」です。仕組みとしてはポインタと同じことが裏側で行われています。

7-3. (上記を踏まえて)Deep-mutationで何が起きているのか？

この仕組みを踏まえると、user().name = 'Taro' という操作が何をしているのか、図で見ると一目瞭然です。

❌ Deep-mutation（プロパティを直接書き換え）した場合：

  【操作前】
  Signal(user)               メモリ
  ┌─────────────────┐      ┌──────────────────────────┐
  │ 住所: 0x03 を指す │ ──→ │ 番地 0x03:                │
  │                 │      │  { name:"Yamada", age:30 } │
  └─────────────────┘      └──────────────────────────┘

  user().name = 'Taro' を実行すると...

  【操作後】
  Signal(user)               メモリ
  ┌─────────────────┐      ┌──────────────────────────┐
  │ 住所: 0x03 を指す │ ──→ │ 番地 0x03:                │
  │  （変わってない！）│      │  { name:"Taro", age:30 }  │ ← 中身だけ変わった
  └─────────────────┘      └──────────────────────────┘

  → 🔴 Signalが見ているのは「住所」だけ。住所 0x03 のままなので「変化なし」と判定

⭕️ .update() で新しいオブジェクトに置き換えた場合：

  【操作前】
  Signal(user)               メモリ
  ┌─────────────────┐      ┌──────────────────────────┐
  │ 住所: 0x03 を指す │ ──→ │ 番地 0x03:                │
  │                 │      │  { name:"Yamada", age:30 } │
  └─────────────────┘      └──────────────────────────┘

  user.update(u => ({ ...u, name: 'Taro' })) を実行すると...

  【操作後】
  Signal(user)               メモリ
  ┌─────────────────┐      ┌──────────────────────────┐
  │ 住所: 0x07 を指す │ ──→ │ 番地 0x07:                │
  │  （新しい住所！） │      │  { name:"Taro", age:30 }  │ ← 新しい場所に新しいデータ
  └─────────────────┘      └──────────────────────────┘
                            ┌──────────────────────────┐
                            │ 番地 0x03:（古いデータ）    │
                            │  { name:"Yamada", age:30 } │ ← もう参照されない
                            └──────────────────────────┘

  → 住所が 0x03 → 0x07 に変わった！Signalは「変化あり！」と検知 → 再描画される！

C/C++・Goでの表現

※ あくまで「ポインタの挙動としての類似性」を説明するための図解であり、各フレームワーク内において全く同じ処理がされているわけではありませんが、概念としては以下のように表現できます。

// C言語での例え
User *user = &original_user;  // ポインタが住所 0x03 を指している

// ❌ Deep-mutation（住所はそのまま、中身だけ書き換え）
user->name = "Taro";          // ポインタの指す先は 0x03 のまま → 変化を検知できない

// ⭕️ 新しいオブジェクトへの置き換え（住所自体が変わる）
User new_user = { .name = "Taro", .age = 30 };
user = &new_user;             // ポインタが新しい住所 0x07 を指す → 変化を検知できる

// Go言語での例え
user := &User{Name: "Yamada", Age: 30} // ポインタが住所 0x03 を指している

// ❌ Deep-mutation（住所はそのまま、中身だけ書き換え）
user.Name = "Taro"                     // ポインタは 0x03 のまま → 変化を検知できない

// ⭕️ 新しいオブジェクトへの置き換え（住所自体が変わる）
user = &User{Name: "Taro", Age: 30}    // ポインタが新しい住所 0x07 を指す → 変化を検知できる！

まとめると

フレームワークが監視しているのは「変数が指し示す住所（メモリアドレス）が変わったかどうか」だけで、住所の先にある「部屋の中身」がいくら変わっても、住所自体が同じなら「何も変わっていない」と判断されることが理由のようでした。

8. まとめ

いかがでしたでしょうか。

改めて、今回の要点をまとめると以下の通りです。

• Signal APIの保護範囲: シグナルの値そのものの「置き換え（セット）」のみ保護できる。
• Signalで防げないこと（Deep-mutation）: 保持しているオブジェクト内部のプロパティの直接的な書き換え。
• 他フレームワークとの共通点: ComposeやReactなど、多くの最新UI技術と共通の「参照変化を監視する」思想に基づいている。
• リスク: 直接書き換えるとAngularが変更を検知できず、UIの不整合やバグの温床になる。

複雑なオブジェクトをSignalで管理する場合は、イミュータブルなデータ操作と「適切な型定義（Readonly等）」を組み合わせることで、堅牢なフロントエンド開発が可能になることがお分かりいただけたかと思います。

今後もAngularのキャッチアップが円滑にできるような初心者向けコンテンツを記事化していきますので、楽しみにしていてください！

参考

• Angular - Signals

• React - useState

• Android Developers - API Reference - Jetpack Compose - MutableState

• C++ Pointers