PHY: スイッチを端子配置・ソケット方式・向きの3軸で持つ(P-7解消)

ブランドは持たない。同じボードに対して利用者がスイッチを選べるため、
ボード設計の情報ではない。KLEの sm, sb, st は端子配置と対応させず、
見た目の属性と同じく不透明なまま退避して書き戻す。

未知の端子配置の扱い(P-9)とLEDノード(P-10)を未確認事項に追加。

Journal: journal/2026-09-20-switch-terminal.md

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

PHYレイヤー.md

@@ -49,6 +49,25 @@ KLE JSONやPCB向けの出力は、階層を畳んで絶対座標に変換した
 ISO Enterのように長方形でないキーは、サイズに2つ目の矩形(x2, y2, w2, h2)を加えて表す。
 2つ目の矩形の位置は、キーのローカル原点からの相対値とする。
 
+### スイッチの端子配置
+
+キーは端子配置(terminal)・ソケット方式(socket)・スイッチの向き(orientation)を持つ。
+スイッチのブランドは持たない。同じボードに対して利用者が好きなスイッチを選べるため、ブランドはボード設計の情報ではない。
+
+- 端子配置は、穴・パッドの数・サイズ・位置が同一のスイッチを1つにまとめた識別子(MX-3pin、MX-5pin、Choc V1 など)。スイッチ側の足の配置を表す
+- ソケット方式は直付けかホットスワップソケットか。端子配置とは独立した軸
+- スイッチの向きは0/90/180/270の4方向。キーのローカル座標系に対する値で、既定は0。90度と270度は別物として扱う
+- 3つの値はファイル単位の既定値を持ち、キーごとに上書きできる。一部のキーだけ別のスイッチを使うキーボードがあるため
+
+端子配置は階層を持たない平坦な識別子とする。低背かどうかのような分類は、端子配置の定義表に属性列として持つ。
+
+端子配置は電気的インターフェース(2端子接点 / アナログ / 光学)も決めるため、ELCレイヤーはスイッチ種別を別に持たない。
+
+実際のPCBフットプリントは、端子配置・ソケット方式・向きの積として出力時に決まる。
+端子配置の識別子から実フットプリントへの対応表はPHYではなくPCB出力の設定に置く。
+フットプリント名はライブラリ依存で、既知の端子配置でも出力時の対応づけが要るため。
+未知の端子配置はユーザー定義の識別子として持ち、対応表が未登録なだけとして扱う。
+
 ### デカールとゴースト
 
 デカールとゴーストはキーとして扱い、フラグで区別する。KLEの d, g に対応する。
@@ -78,7 +97,7 @@ ISO Enterのように長方形でないキーは、サイズに2つ目の矩形(
 
 各ノードは親から見た変換を持つ。キーとクラスターを混在させた木構造として保持する。
 
-`phase1-json-schema.md` のPHYスキーマは、この節の Key 型(x2〜h2, decal, ghost, labels, switchOffset)にまだ追従していない。
+`phase1-json-schema.md` のPHYスキーマは、この節の Key 型(x2〜h2, decal, ghost, labels, switchOffset, terminal, socket, orientation)にまだ追従していない。
 
 ```ts
 type Transform = {
@@ -101,7 +120,10 @@ type Key = {
     decal?: boolean,
     ghost?: boolean,
     labels?: string[], // 参考情報
-    switchOffset?: { x: number, y: number } // (w, h) 矩形の中心から。省略時は0
+    switchOffset?: { x: number, y: number }, // (w, h) 矩形の中心から。省略時は0
+    terminal?: string,            // 端子配置の識別子。省略時はファイル単位の既定値
+    socket?: 'solder' | 'socket', // 省略時はファイル単位の既定値
+    orientation?: 0 | 90 | 180 | 270 // キーのローカル座標系。省略時は0
 }
 type Cluster = {
     transform: Transform,
@@ -161,6 +183,7 @@ const kleData = (ConfigObject | KeyLabel)[][]
 - 回転角度は正規化せずそのまま出力する。KLEのデータは任意の角度を受け付け、15度刻みはKLEのUI上の操作単位にすぎない
 - rx, ry はPHYに持たないので、出力時に選ぶ
 - ユニットサイズ(mm)、ビジュアルオフセット、クラスター構造はKLE JSONに出力されない
+- 端子配置・ソケット方式・スイッチの向きはKLE JSONに出力しない。sm, sb, st には取り込み時に保持した値をそのまま書き戻す
 - KLEの `p` はキーキャップのプロファイル名(SA、DCSなど)であり、PHYのプロファイルとは対応させない
 
 ### KLE JSONの取り込み
@@ -176,13 +199,16 @@ KLEの rx, ry, r はキーの絶対配置 (x, y, rotation) に変換して取り
 
 見た目の属性(c, t, p, a, f, f2, fa, l, n)は、KLE JSONへ書き戻せるように保持する。どの層で持つかは決まっていない。
 
+KLEの sm, sb, st(ファイル単位では switchMount, switchBrand, switchType)も同様に、不透明なまま保持して書き戻す。
+PHYの端子配置とは対応させない。st はベンダー品番であり、穴・パッドの配置が決まらないため。
+
 ## 検討済み・非採用
 
-- キーごとの絶対座標保持 (journal/2026-09-18-phy-coordinate-model.md)
-- 相対座標と絶対座標の併記 (journal/2026-09-18-phy-coordinate-model.md)
 - ノードごとの回転中心パラメータ (journal/2026-09-18-phy-coordinate-model.md)
 - KLE JSONへの識別・構造情報の埋め込み(labelのID、`_beyondkle` メタデータ、ゴーストキー) (journal/2026-09-18-kle-roundtrip.md)
 - KLEのデカール・ゴースト・見た目属性を取り込み時に捨てる (journal/2026-09-19-kle-key-attributes.md)
+- スイッチのブランドをPHYで持つ (journal/2026-09-20-switch-terminal.md)
+- 端子配置をPCBに開ける穴の配置として定義する (journal/2026-09-20-switch-terminal.md)
 
 ## 未確認事項
 
@@ -208,17 +234,23 @@ KLEの rx, ry, r はキーの絶対配置 (x, y, rotation) に変換して取り
 ### P-6 キーキャップの見た目情報を持つ層
 
 - 位置づけ: 本文「見た目の属性は保持する。どの層で持つかは決まっていない」の未解決部分
-- 現状の認識: c, t, p, a, f系に加え、l, n もキーキャップの見た目属性であり、PHYとは別の層が要りそう。そもそもキーキャップは設計時に決める必要が薄く、カスタムキーボードの文脈に属するため、Beyond KLEの扱う範囲かどうかも未定。ファイル単位の backcolor, radii, background, css も同じ問いに含まれる
+- 現状の認識: c, t, p, a, f系に加え、l, n もキーキャップの見た目属性であり、PHYとは別の層が要りそう。退避だけして書き戻す sm, sb, st も同じ置き場の問題を持つ。そもそもキーキャップは設計時に決める必要が薄く、カスタムキーボードの文脈に属するため、Beyond KLEの扱う範囲かどうかも未定。ファイル単位の backcolor, radii, background, css も同じ問いに含まれる
 - 格上げ条件: キーキャップの情報をBeyond KLEの範囲に含めるかをユーザーが決め、保持する層を決める
 
-### P-7 スイッチ種別の保持先
-
-- 位置づけ: 未解決の問い。KLEの sm, sb, st(ファイル単位では switchMount, switchBrand, switchType)の扱い
-- 現状の認識: PCB設計に使う情報なのでPHYで持つ候補。一部のキーだけ別のスイッチを使う前提のキーボードもあるため、キーごとの上書きが必要になりうる
-- 格上げ条件: PHYで持つかを決め、持つ場合はファイル単位の既定値とキーごとの上書きの形を決める
-
 ### P-8 ラベルをMAPに適用するか
 
 - 位置づけ: 未解決の問い。本文ではラベルを参考情報として持つことだけを決めている
 - 現状の認識: どのラベルがMAPに適用できるかは、おそらく機械的には判断できない。自動で適用してユーザーが不要なものを落とす方式も考えられる
 - 格上げ条件: 適用するか、する場合は自動適用とユーザーによる取捨の流れをユーザーが決める
+
+### P-9 未知の端子配置に対する編集画面の表示
+
+- 位置づけ: 本文「未知の端子配置はユーザー定義の識別子として持つ」の未解決部分
+- 現状の認識: 識別子だけでは穴・パッドの配置が分からないため、プレート切り欠きの描画やスイッチ位置の検証ができない。最低限の形状情報を持たせるかは未定
+- 格上げ条件: 編集画面でスイッチ形状を使う機能を洗い出し、未知の端子配置に何を持たせれば足りるかを決める
+
+### P-10 LEDを独立したノードとして持つか
+
+- 位置づけ: 未解決の問い。LED用の穴をどう表すか
+- 現状の認識: 端子配置のオプションとして持つ案もあるが、LED専用ノードが要る可能性がある。詳細は未検討
+- 格上げ条件: LEDの配置がスイッチに従属するか独立するかをユーザーが決め、ノードにするかを決める

journal/2026-09-20-switch-terminal.md

@@ -0,0 +1,46 @@
+# スイッチ種別の保持先 (旧 PHY P-7)
+
+## 結論
+
+PHYは端子配置(terminal) / ソケット方式(socket) / スイッチの向き(orientation)の3軸を持つ。ブランドは持たない。
+実際のPCBフットプリントは3軸の積として出力時に決まる。KLEの sm, sb, st はBeyond KLEの端子配置と対応させず、不透明なまま退避して書き戻す。
+
+## 案の比較
+
+| 論点 | 案 | 採否 |
+|---|---|---|
+| ブランド | KLEの sb 相当をPHYで持つ | 不採用 |
+| ブランド | 持たない | 採用 |
+| 種別の定義 | (a) スイッチ側の足の配置。MX-3pin と MX-5pin は別タイプ | 採用 |
+| 種別の定義 | (b) PCBに開ける穴の配置。MXは1タイプ、ボス穴・LED穴はオプション | 不採用 |
+| 分類 | 端子配置を階層化(MX系 > MX-3pin, MX-5pin) | 不採用 |
+| 分類 | 平坦な識別子 + 定義表の属性列 | 採用 |
+| 未知の種別 | 未知のときだけ出力時にフットプリントを指定させる | 不採用(既知も同じ仕組みで足りる) |
+| 未知の種別 | 識別子 → フットプリントの対応表を常に出力設定に置く | 採用 |
+| KLE sm/sb/st | Beyond KLEの端子配置に変換して取り込む | 不採用 |
+| KLE sm/sb/st | 不透明なまま退避して書き戻す | 採用 |
+
+## 根拠
+
+- ブランドは同じボードに対して利用者が選ぶもので、穴もパッドも配線対象も変えない。ボード設計の情報ではない
+- KLEの st は `MX1A-11Nx` のようなベンダー品番で、ブランド・種別・バリエーションが混ざった文字列。ここから穴形状を機械的に導けないため、
+  Beyond KLEの端子配置との対応づけは成立しない。名前も意味もKLEと別物なので、同名を避けて terminal とした
+- 端子配置は電気的インターフェース(2端子接点 / アナログ / 光学)も決める。PHYが持てばELCが別途スイッチ情報を持つ必要がない。
+  これがPHYに置く根拠になった
+- 向きは90度と270度で別物(LED穴・ボス穴の位置が変わる)なので4方向。キーの回転とは別の値で、キーのローカル座標系に対して持つ
+- 階層化を採らなかったのは、欲しいのが分類ラベルであって継承ではないため。低背かどうかも定義表の列で表せる
+- 未知の種別を特別扱いしなかったのは、KiCadのフットプリント名がライブラリ依存で、既知の種別でも出力時のマッピングが要るため。
+  未知は「マッピングが未登録」なだけになる
+
+## (b)案を捨てた経緯
+
+5pin穴のPCBには3pinスイッチも刺さるため、3pin/5pinの差は「スイッチの選択」ではなく「PCBの選択」だという整理ができる。
+これはブランドを落とした理屈と同じ形なので、(b) のほうが一貫するとして提案した。
+ユーザーの判断: 3pinを明示的に使いたい制作者が多く、設計データ上で3pinと5pinを区別したい。よって (a)。
+
+LED穴も (b) と同じ形の論点だが、LED専用ノードを立てる可能性が出たため、端子配置のオプションとしては扱わず別途詰める。
+
+## 捨てた仮説
+
+- 「マウント方式」をKLEの sm と同じ軸だと考えていた。KLEの sm は cherry / alps のような軸規格で、
+  プレートマウント/PCBマウントでもホットスワップ/直付けでもない。ユーザーの意図はソケット有無だったため socket に落ち着いた