ewderna/Beyond-KLE
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
5bba75d1e8662765cf07b1b92e2b952fbd33beac
Beyond-KLE/keyboard-making-workflow.md
T
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
2026-09-18 08:43:01 +09:00

4.8 KiB
Raw Blame History

自作キーボード制作ワークフロー分析

現在の一般的な制作手順

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 View Git Blame Copy Permalink