Proxyとリフレクションの内部メソッド（トラップとMOP）

すべてのオブジェクト操作は「内部メソッド」に集約される

JavaScript で obj.x、obj.x = 1、delete obj.x、'x' in obj と書くとき、エンジンの中ではいずれも 内部メソッド（internal methods） と呼ばれる仕様上の関数が呼ばれています。ECMAScript 仕様は、オブジェクトの振る舞いを [[Get]]、[[Set]] のように二重角括弧で囲んだ抽象操作の集合として定義します。構文（. や in）はその呼び出しの糖衣にすぎません。

この内部メソッド群が MOP（Meta-Object Protocol、メタオブジェクトプロトコル） です。Proxy はこの MOP の各メソッドを JS で書いたコードに差し替える仕組みであり、Reflect はその既定の実装を 関数として明示的に呼ぶための窓口です。三者は同じ内部メソッドを軸に綺麗に対応します。基礎は JavaScript を前提にします。

11個の必須内部メソッド

通常のオブジェクト（ordinary object）が備える内部メソッドは、引数の有無を問わず数えて以下の11個です。すべてのオブジェクトはこれらを実装しなければなりません（関数はさらに [[Call]]、コンストラクタは [[Construct]] を持つ）。

関数オブジェクトの [[Call]] には apply トラップ、[[Construct]] には construct トラップが対応し、合計13個のトラップが定義可能です。トラップを 定義しなかった内部メソッドは、自動的にターゲット（new Proxy(target, handler) の第1引数）の同名内部メソッドへそのまま転送されます。

トラップ・Reflect・内部メソッドの三位一体

Reflect オブジェクトのメソッドは、トラップと同じ名前・同じ引数を持つように設計されています。これは偶然ではなく、仕様が両者を同一の内部メソッドに紐付けているためです。

const handler = {
  get(target, key, receiver) {
    console.log('read:', key);
    // 既定の [[Get]] へ委譲。receiver を渡すのが正解
    return Reflect.get(target, key, receiver);
  },
  set(target, key, value, receiver) {
    return Reflect.set(target, key, value, receiver);
  },
};
const p = new Proxy({ a: 1 }, handler);
p.a;        // read: a → 1
p.a = 2;    // set 経由で 2 を書き込み

トラップ内で「既定動作をそのまま行いたい」場合、自前で target[key] と書くのは誤りになり得ます。理由は receiver（レシーバ）です。receiver は操作の起点となったオブジェクト（多くは Proxy 自身、あるいはそれを継承した子）で、アクセサ（getter/setter）の this をこの値に束ねるために使われます。Reflect.get(target, key, receiver) は receiver を正しく伝播しますが、target[key] は target を this にしてしまい、継承先での挙動がずれます。

不変条件（invariants）：トラップでも嘘はつけない

Proxy の最大の安全装置が 不変条件（invariants） です。トラップは任意の JS コードを書けますが、その戻り値が ターゲットの実際の状態と矛盾してはならない。矛盾すると、エンジンがトラップの結果を採用せず TypeError を投げます。これは言語の整合性（型システムやエンジン最適化が前提にする性質）を守るための仕掛けです。代表例を挙げます。

• 非設定可能（non-configurable）・非書き込み可能（non-writable）なデータプロパティを target が持つなら、get トラップはその実値と 同じ値を返さねばならない。違う値を返すと TypeError。
• target に存在する 非設定可能プロパティを、has トラップが「無い」と偽ったり、ownKeys が一覧から 省くことはできない。
• target が 拡張不可（non-extensible） なら、ownKeys は target の実際の自有キー集合と完全に一致させねばならず、新しいキーを でっち上げられない。
• getPrototypeOf トラップは、target が拡張不可なら target の実際のプロトタイプと 同じものを返さねばならない。

const target = {};
Object.defineProperty(target, 'id', {
  value: 42, writable: false, configurable: false,
});
const p = new Proxy(target, {
  get() { return 'fake'; },   // 実値 42 と矛盾する
});
p.id;
// → TypeError: 'get' on proxy: property 'id' is a read-only and
//   non-configurable data property on the proxy target but the
//   proxy did not return its actual value

なぜ不変条件が必要か

不変条件は単なる安全網ではなく、他のオブジェクトとの見分けがつかないことを保証するための要請です。Object.freeze で凍結したオブジェクトは「キーが増えない・値が変わらない」と他のコードが信頼できます。もし Proxy がこの保証を破れるなら、凍結という概念自体が当てになりません。不変条件は「Proxy であっても、通常のオブジェクトが守る規約からは逃げられない」ことを言語レベルで担保します。

この性質は、V8 のようなエンジンが行う形ベースの最適化とも整合します。エンジンはオブジェクトの「形」を観測してアクセスを高速化しますが、その前提となる不変条件を Proxy が破れないからこそ最適化の仮定が崩れません。形の最適化そのものは V8のオブジェクト表現と隠しクラス を参照してください。

取り消し可能 Proxy と実務での使いどころ

Proxy.revocable(target, handler) は { proxy, revoke } を返し、revoke() を呼ぶと以降あらゆる内部メソッドが TypeError になります。ターゲットへの参照を外部に渡しつつ、後から能力を失効（capability の取り消し）させたい場面で使います。

実務での主用途は、DOM 操作の監視・バリデーション・遅延ロード（プロパティ初回アクセス時に実体化）・API クライアントの動的ラッパなどです。一方で、すべてのアクセスにトラップ呼び出しのコストが乗るため、ホットパスでの濫用は避けます。get/set を多用する大量ループでは素のオブジェクトより明確に遅くなります。DOM をいじる場合の再計算コストは DOM と合わせて検討してください。

まとめ