ewdernaandClaude Opus 5
55243f626d
ルール策定前に書かれた設計ドキュメント7点を、以降の基準点として そのままの状態で記録する。CLAUDE.md のルール1〜4は未適用。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MdLT5x5ka5y6CaWLeE3EKb
158 lines
4.8 KiB
Markdown
158 lines
4.8 KiB
Markdown
# 自作キーボード制作ワークフロー分析
|
||
|
||
## 現在の一般的な制作手順
|
||
|
||
### 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. **テストケース作成**: 代表的なキーボード設計での検証
|