初期検討段階のドキュメントと運用ルールを取り込む

ルール策定前に書かれた設計ドキュメント7点を、以降の基準点として
そのままの状態で記録する。CLAUDE.md のルール1〜4は未適用。

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MdLT5x5ka5y6CaWLeE3EKb
This commit is contained in:
2026-09-18 08:43:01 +09:00
co-authored by Claude Opus 5
commit 55243f626d
12 changed files with 2395 additions and 0 deletions
+157
View File
@@ -0,0 +1,157 @@
# 自作キーボード制作ワークフロー分析
## 現在の一般的な制作手順
### 1. デザイン・設計段階
#### a) レイアウト設計
- **ツール**: KLE (Keyboard Layout Editor)
- **作業内容**:
- キーの物理配置を決定
- キーサイズ・間隔・角度を調整
- 視覚的な配置確認
- **出力**: KLE JSON ファイル
- **Beyond KLE対応**: **PHYレイヤー**
#### b) 回路設計・マトリックス設計
- **ツール**: 手動計算、KiCad等の回路図エディタ
- **作業内容**:
- キーマトリックスの行列構成を決定
- マイコンピンとの対応付け
- ダイオード配置の検討
- **出力**: 回路図、ピン配置表
- **現在の課題**: KLEからマトリックス情報への変換が手動
- **Beyond KLE対応**: **ELCレイヤー** + **IDXレイヤー**
### 2. PCB設計段階
#### a) フットプリント配置
- **ツール**: KiCad、Eagle、Fusion360等
- **作業内容**:
- KLE JSONから座標を抽出(手動またはスクリプト)
- スイッチフットプリントの配置
- マイコン・コネクタ等の部品配置
- **現在の課題**: KLEとPCBツール間の座標変換
- **Beyond KLE対応**: **PHYレイヤー** → PCBツール連携
#### b) 配線・ルーティング
- **ツール**: PCB CADソフト
- **作業内容**:
- マトリックス配線の実装
- 電源・信号線のルーティング
- **Beyond KLE対応**: **ELCレイヤー**情報の活用
### 3. ファームウェア設定段階
#### a) ファームウェア基本設定
- **ツール**: QMK、KMK、VIA等
- **作業内容**:
- マトリックス定義(ROW/COL)
- ピン配置設定
- 物理レイアウト定義
- **現在の課題**:
- KLEとファームウェア設定の手動変換
- VIAではlabelフィールドに"1,5"等を記入してmatrix座標を表現
- **Beyond KLE対応**: **IDXレイヤー** + **ELCレイヤー** → ファームウェア自動生成
#### b) キーマップ設定
- **ツール**: QMK Configurator、VIA、Remap等
- **作業内容**:
- 各キーへのキーコード割り当て
- レイヤー設計
- マクロ・特殊機能の設定
- **Beyond KLE対応**: **MAPレイヤー**
### 4. 製造・組み立て段階
#### a) PCB製造
- **出力**: Gerberファイル、BOM、Pick&Place
- **Beyond KLE対応**: PHY/ELCレイヤーからの自動生成
#### b) 部品調達・組み立て
- **作業内容**: はんだ付け、組み立て、動作確認
## 現在のワークフローの問題点
### 1. データの分断
- **問題**: KLE → PCB → ファームウェアで毎回手動変換
- **影響**: 一箇所変更時の全体への反映が困難
### 2. マトリックス情報の欠落
- **問題**: KLEは物理配置のみ、論理構造(マトリックス)は別管理
- **影響**: VIAでのhackyな対応(labelフィールド悪用)
### 3. 設計変更時のトレーサビリティ不足
- **問題**: どのレイヤーでの変更が他に影響するかが不明確
- **影響**: デバッグ・修正作業の複雑化
### 4. ツール間連携の脆弱性
- **問題**: 手動変換によるヒューマンエラー
- **影響**: 設計ミス、製造後の修正コスト
## Beyond KLEによる解決策
### 1. 統一データモデル
```
物理設計(PHY) → キー識別(IDX) → 電気設計(ELC) → キーマップ(MAP)
↓ ↓ ↓ ↓
PCBツール ファームウェア 回路図 VIA/Remap
```
### 2. レイヤー間の明確な責任分離
- **PHY**: 物理配置のみに集中
- **IDX**: 物理と論理の橋渡し(最重要レイヤー)
- **ELC**: 電気的接続の明確化
- **MAP**: キーマップロジックの分離
### 3. 双方向の依存関係管理
- 上流レイヤーの変更が下流に自動反映
- 下流での制約が上流設計にフィードバック
### 4. 既存ツールとの互換性維持
- KLE JSONの完全サポート
- VIA/QMK等への出力対応
- 段階的移行の実現
## Phase 1で策定すべきプロトコル
### 1. レイヤー間インターフェース仕様
- 各レイヤーの入出力JSON Schema
- 依存関係の明確化
- エラーハンドリング規則
### 2. 既存フォーマットとの変換仕様
- KLE JSON → PHY変換
- QMK設定 ← IDX+ELC+MAP変換
- VIA JSON ← 全レイヤー統合
### 3. 拡張性設計
- 非標準マトリックス(charlieplexing等)対応
- 3D配置への拡張可能性
- カスタムキーコードサポート
## 次のアクション
1. **JSON Schema策定**: 各レイヤーのデータ構造定義
2. **変換ロジック設計**: レイヤー間の変換アルゴリズム
3. **リファレンス実装**: TypeScript/Rust等でのプロトタイプ
4. **テストケース作成**: 代表的なキーボード設計での検証