PHY: スイッチの品種を持たず、部品グループのラベルだけ残す

フットプリントの選択はPCB設計ツール側の仕事で、Beyond KLEはその手前までを扱う。
前の決定で品種を持つ根拠にした「3pinの明示」はKiCadに渡す情報の話だったため、
端子配置とソケット方式を落とし、解釈しない部品グループのラベルと向きだけを残す。
キーごとの検出方式はELCが持つ(2端子前提ではHEの配線を組めないため)。

未知の端子配置の問い(P-9)は、品種を持たなくなったので消滅。

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

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RCUFZ7vmSqQyGAPUFNWoiz

PHYレイヤー.md

@@ -49,24 +49,24 @@ KLE JSONやPCB向けの出力は、階層を畳んで絶対座標に変換した
 ISO Enterのように長方形でないキーは、サイズに2つ目の矩形(x2, y2, w2, h2)を加えて表す。
 2つ目の矩形の位置は、キーのローカル原点からの相対値とする。
 
-### スイッチの端子配置
+### 部品グループとスイッチの向き
 
-キーは端子配置(terminal)・ソケット方式(socket)・スイッチの向き(orientation)を持つ。
+PHYはスイッチの品種(MX-3pin、Choc V1 など)もソケット方式も持たない。
-スイッチのブランドは持たない。同じボードに対して利用者が好きなスイッチを選べるため、ブランドはボード設計の情報ではない。
+どのフットプリントを使うかはPCB設計ツール側の選択であり、Beyond KLEはその手前までを扱う。
 
-- 端子配置は、穴・パッドの数・サイズ・位置が同一のスイッチを1つにまとめた識別子(MX-3pin、MX-5pin、Choc V1 など)。スイッチ側の足の配置を表す
+キーが持つのは次の2つ。
-- ソケット方式は直付けかホットスワップソケットか。端子配置とは独立した軸
-- スイッチの向きは0/90/180/270の4方向。キーのローカル座標系に対する値で、既定は0。90度と270度は別物として扱う
-- 3つの値はファイル単位の既定値を持ち、キーごとに上書きできる。一部のキーだけ別のスイッチを使うキーボードがあるため
 
-端子配置は階層を持たない平坦な識別子とする。低背かどうかのような分類は、端子配置の定義表に属性列として持つ。
+- 部品グループ(partGroup): 同じ部品を使うキーをまとめるラベル。省略可
+- スイッチの向き(orientation): 0/90/180/270の4方向。キーのローカル座標系に対する値で、既定は0。90度と270度は別物として扱う
 
-端子配置は電気的インターフェース(2端子接点 / アナログ / 光学)も決めるため、ELCレイヤーはスイッチ種別を別に持たない。
+部品グループの中身はBeyond KLEが解釈しない。穴・パッドの配置も、低背かどうかも持たない。
+グループごとの実フットプリントはPCB出力時に割り当てる。
+不均一な構成で「どのキーが同じ部品か」という設計者の意図だけを保存するために持つ。
 
-実際のPCBフットプリントは、端子配置・ソケット方式・向きの積として出力時に決まる。
+スイッチのブランドも持たない。同じボードに対して利用者が好きなスイッチを選べるため、ボード設計の情報ではない。
-端子配置の識別子から実フットプリントへの対応表はPHYではなくPCB出力の設定に置く。
+
-フットプリント名はライブラリ依存で、既知の端子配置でも出力時の対応づけが要るため。
+キーごとの検出方式(接点マトリクス / アナログ / 光学)はELCが持ち、PHYは持たない。
-未知の端子配置はユーザー定義の識別子として持ち、対応表が未登録なだけとして扱う。
+ホールセンサのように端子数も配線トポロジも接点スイッチと異なるものがあり、これは電気的な性質のため。
 
 ### デカールとゴースト
 
@@ -97,7 +97,7 @@ ISO Enterのように長方形でないキーは、サイズに2つ目の矩形(
 
 各ノードは親から見た変換を持つ。キーとクラスターを混在させた木構造として保持する。
 
-`phase1-json-schema.md` のPHYスキーマは、この節の Key 型(x2〜h2, decal, ghost, labels, switchOffset, terminal, socket, orientation)にまだ追従していない。
+`phase1-json-schema.md` のPHYスキーマは、この節の Key 型(x2〜h2, decal, ghost, labels, switchOffset, partGroup, orientation)にまだ追従していない。
 
 ```ts
 type Transform = {
@@ -121,9 +121,8 @@ type Key = {
     ghost?: boolean,
     labels?: string[], // 参考情報
     switchOffset?: { x: number, y: number }, // (w, h) 矩形の中心から。省略時は0
-    terminal?: string,            // 端子配置の識別子。省略時はファイル単位の既定値
+    partGroup?: string, // 同じ部品を使うキーをまとめるラベル。中身は解釈しない
-    socket?: 'solder' | 'socket', // 省略時はファイル単位の既定値
+    orientation?: 0 | 90 | 180 | 270 // スイッチの向き。キーのローカル座標系。省略時は0
-    orientation?: 0 | 90 | 180 | 270 // キーのローカル座標系。省略時は0
 }
 type Cluster = {
     transform: Transform,
@@ -183,7 +182,7 @@ const kleData = (ConfigObject | KeyLabel)[][]
 - 回転角度は正規化せずそのまま出力する。KLEのデータは任意の角度を受け付け、15度刻みはKLEのUI上の操作単位にすぎない
 - rx, ry はPHYに持たないので、出力時に選ぶ
 - ユニットサイズ(mm)、ビジュアルオフセット、クラスター構造はKLE JSONに出力されない
-- 端子配置・ソケット方式・スイッチの向きはKLE JSONに出力しない。sm, sb, st には取り込み時に保持した値をそのまま書き戻す
+- 部品グループ・スイッチの向きはKLE JSONに出力しない。sm, sb, st には取り込み時に保持した値をそのまま書き戻す
 - KLEの `p` はキーキャップのプロファイル名(SA、DCSなど)であり、PHYのプロファイルとは対応させない
 
 ### KLE JSONの取り込み
@@ -200,7 +199,7 @@ 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 はベンダー品番であり、穴・パッドの配置が決まらないため。
+Beyond KLEはスイッチの品種を持たないため、対応づける先がない。
 
 ## 検討済み・非採用
 
@@ -208,7 +207,7 @@ PHYの端子配置とは対応させない。st はベンダー品番であり
 - 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)
+- スイッチの品種・ソケット方式をPHYで持つ (journal/2026-09-20-switch-terminal-reversal.md)
 
 ## 未確認事項
 
@@ -243,14 +242,8 @@ PHYの端子配置とは対応させない。st はベンダー品番であり
 - 現状の認識: どのラベルがMAPに適用できるかは、おそらく機械的には判断できない。自動で適用してユーザーが不要なものを落とす方式も考えられる
 - 格上げ条件: 適用するか、する場合は自動適用とユーザーによる取捨の流れをユーザーが決める
 
-### P-9 未知の端子配置に対する編集画面の表示
-
-- 位置づけ: 本文「未知の端子配置はユーザー定義の識別子として持つ」の未解決部分
-- 現状の認識: 識別子だけでは穴・パッドの配置が分からないため、プレート切り欠きの描画やスイッチ位置の検証ができない。最低限の形状情報を持たせるかは未定
-- 格上げ条件: 編集画面でスイッチ形状を使う機能を洗い出し、未知の端子配置に何を持たせれば足りるかを決める
-
 ### P-10 LEDを独立したノードとして持つか
 
 - 位置づけ: 未解決の問い。LED用の穴をどう表すか
-- 現状の認識: 端子配置のオプションとして持つ案もあるが、LED専用ノードが要る可能性がある。詳細は未検討
+- 現状の認識: LEDの配置は設計者が決め、色や実装するかは利用者が選ぶ。位置と向き(表裏を含む)を持つ要素なのでPHYに入りそうだが、独立ノードにするかは未検討
 - 格上げ条件: LEDの配置がスイッチに従属するか独立するかをユーザーが決め、ノードにするかを決める

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

@@ -0,0 +1,52 @@
+# スイッチの品種をPHYで持たない (同日の 2026-09-20-switch-terminal を覆す)
+
+## 結論
+
+PHYはスイッチの品種(端子配置)もソケット方式も持たない。不透明な部品グループのラベルと、スイッチの向きだけを持つ。
+どのフットプリントを使うかはKiCadなどPCB設計ツール側の選択で、Beyond KLEはその手前までを扱う。
+キーごとの検出方式はELCが持つ。
+
+## 案の比較
+
+| 案 | 採否 |
+|---|---|
+| 端子配置(MX-3pin、Choc V1 など)とソケット方式をPHYで持つ | 不採用(同日の前の決定を覆した) |
+| 不透明な部品グループのラベルだけ持つ | 採用 |
+| 何も持たない(向きのみ) | 不採用 |
+| 検出方式をPHYの端子配置から導出する | 不採用 |
+| 検出方式をELCが持つ | 採用 |
+
+## 覆した理由
+
+前の決定は「3pinを明示的に使いたい制作者が多い」を根拠に、品種を設計データとして持つ((a)案)とした。
+この要望はKiCadに渡すフットプリント選択の話であって、Beyond KLEのデータに対するものではなかった(ユーザー確認済み)。
+根拠が消えたため、品種を持つ理由がなくなった。
+
+ソケット方式も同じ論理で落ちる。配置に一切影響せず、フットプリントの差でしかない。
+
+向きは残る。部品を知らなくても回転角として渡せるので、品種を落としても壊れない。
+
+## 部品グループを残した理由
+
+品種を落とすと、Chocのボードの一部だけMXにするような不均一な構成で「どのキーが同じ部品か」が表現できなくなり、
+PCB設計ツール側で手作業の割り当てが必要になる。設計者の意図だけを保存するために、解釈しないラベルとして残した。
+
+Beyond KLEはラベルの中身を解釈しない。穴・パッドの配置も低背かどうかも持たない。
+この結果、未知の端子配置をどう扱うか(旧P-9)という問題自体が消えた。全部が未知になるため。
+
+## 検出方式をELCに移した理由
+
+前の決定では「端子配置が電気的インターフェースを決めるので、ELCはスイッチ情報を持たない」としていた。
+これはHEで成り立たない。ホールセンサは電源・GND・アナログ出力の3端子で、ダイオードマトリクスには載らず、
+ADC/マルチプレクサに繋がる。「どのスイッチも2端子」という抽象化では配線を組めない。
+キーごとの検出方式が要り、これは電気的な性質なのでELCの持ち物とした。光学スイッチの端子構成は未確認。
+
+## 捨てた案: 部品カタログ
+
+ピン配置を「層ではなく、設計をまたいで共有される部品カタログ」として置き、PHYは割り当てだけを持つ案を検討した。
+Beyond KLEがフットプリントを選ばないなら、カタログを持つ理由自体がなくなるので採らなかった。
+
+## 残る影響
+
+- keyboard-design-layers.md のELCの役割は「マイコンのpinと各キーの対応」で、検出方式を含んでいない。ELCを詰めるときに追記が要る
+- 低背かどうかをPHYで知りたいという要望は、Profileのユニットサイズ(MX 19.05mm / Choc 18×17mm)が実質担っている