初期検討段階のドキュメントと運用ルールを取り込む
ルール策定前に書かれた設計ドキュメント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:
@@ -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. **テストケース作成**: 代表的なキーボード設計での検証
|
||||
Reference in New Issue
Block a user