Codexのエージェントと、完全無線分割キーボードを設計してみた話

こんにちは、tatsukiです！

普段はソフトウェアの開発を中心にいろいろ作っているのですが、「AIエージェントを使って、ハードウェアの設計から3Dモデル、組み立て手順書までまるごと作らせてみたらどこまでいけるんだろう？」というのが気になって、Codexのエージェントと一緒に完全無線分割キーボードの開発プロジェクトを回してみました。

結論から言うと、「ある程度はできるだろうと思っていたけれど、正直ここまでできるとは思ってなかった」というのが率直な感想です。

今回は、どんな設計にして、どうやってテストやシミュレーションを回し、どんなふうに形になっていったのかを、ゆるく振り返ってみたいと思います。

1. 作りたかったキーボードの仕様

今回のお題にしたのは、名機「Keyball39」のキー配置（39キー＋右手親指の34mmトラックボール）をベースにしつつ、自分好みの仕様を詰め込んだ超省電力・完全無線分割キーボード（wireless-keyball39）です。

ざっくりこんな要件からスタートしました。

• 39キー＋右34mmトラックボール：Keyball39のキー中心座標と角度をそのまま継承
• 完全ワイヤレス：左右間のケーブルもUSBケーブルもなし。右側をセントラルにしてMacへ直接BLE接続
• 単3乾電池1本ずつで駆動：リチウムイオンバッテリーの充電管理や発火リスクを避け、左右それぞれ単3アルカリ乾電池1本で動く超省電力設計
• ロープロファイル＆ホットスワップ：Kailh Choc v1スイッチ対応で、水平（0度）のフラットで薄いケース
• 余計な装飾はゼロ：省電力を最優先にして、OLED画面やRGBバックライト、装飾LEDはすべて非搭載

ただ、既存基板に無線マイコンを載せ替えるだけでは成立しません。単3乾電池1本（1.5V〜終止0.9V付近）から昇圧する電源回路も、省電力な光学センサー（PMW3610）の周辺回路も、スイッチプレートや乾電池を収めるケースも、全部ゼロから再設計する必要がありました。

2. いきなり作らせない。「まず設計して、テストを回す」仕組みづくり

今回のプロジェクトで一番意識したのが、「いきなり回路や3Dモデルを作らせない」ことでした。

最初に開発規約（AGENTS.md）とフェーズ承認ゲート（APPROVALS.md）を用意し、Phase 0〜Phase 4までの段階を定義しました。特にPhase 0では「製品の回路図、PCB、ファームウェア、3Dモデルを一切作成してはならない」というルールを設け、まずは徹底的な調査と設計・テスト計画の策定だけを行わせました。

さらに、エージェントが「ビルドが通った＝実機で動く」と勝手に拡大解釈しないよう、すべての検証にA〜Eのテスト区分を義務付けました。

区分	意味	具体例
A	実データ・実コードによる静的/幾何検証	KiCadのERC/DRC、実ターゲット向けビルド、実寸CADのB-rep干渉計算
B	一部を模擬（モック）した実行確認	実ファームウェアのロジック＋模擬GPIO/SPIによる単体テスト
C	データシートや理論式による推定	電力バジェット計算、電池寿命のシナリオ試算
D	未検証・未実施	現時点でまだ回せていないテスト
E	実機が必須の検証	実際の無線通信（RF）、光学センサーの追従性、スイッチの打鍵感、実測電流

「いま確認できたのはAとBの範囲で、ここはE（実機必須）として残る」と常に切り分けさせたことで、エージェントがハルシネーションで「完成しました！」と暴走するのを防ぎ、人間がレビューして承認してから次のフェーズへ進む流れがきれいに回りました。

3. 基板設計と、何度も作り直したレイアウト（Phase 1）

Phase 0の調査と技術選定（RaytacのnRF52840モジュール、TPS61299昇圧IC、PMW3610光学センサー＋レベル変換ICなど）を承認したあと、Phase 1でいよいよ回路図とプリント基板（PCB）、ファームウェアの実装に入りました。

面白いのが、一度基板が引けたあとのレイアウトの改善ループです。

最初はすべての回路を素直に配置した「Rev A」を作ってもらったのですが、キーの上側（奥側）に回路帯が並んでいたため、奥行きが約118mmと少し大きくなってしまいました。そこで「奥側の帯をなくして、内側の縦スペースに回路を集約できない？」と相談して出てきたのが Compact C1 です。

これだけで基板の奥行きが約20mm縮まり、基板面積は左で22.2%、右で26.0%もコンパクトになりました。

さらにそこから、

1. 「外周に飛び出しているネジ止めの耳を全部なくして、基板の内側で固定したい（Compact C2）」
2. 「配線の引きやすさよりも、タイピングしたときに基板がたわまないよう、外側上下・内側上下・中央の5点支持のバランスを最優先して再配線してほしい（Compact C3）」

とリクエストを重ねていきました。

普通なら「マウント穴の位置を動かしたら2層基板の引き回しを全部やり直し……」と心が折れそうな場面ですが、Codexのエージェントはミリ単位の座標変更からKiCadの2層配線引き直しまで粘り強くやり切ってくれました。

Phase 1で回したテストとシミュレーション

「本当にこの基板データとファームウェアで大丈夫なの？」というところも、徹底的にテストを回しています。

• KiCad 10 CLIによる全自動チェック：左主基板・右主基板・センサー子基板の3枚すべてで、ERC（電気ルールチェック）・DRC（設計ルールチェック）・未配線ネット・回路図とPCBの不一致（parity）がすべて 0件 になるまで検証。アンテナ周囲の全層銅箔禁止領域（RF keepout）に配線やベタ銅が1ミリも侵入していないか、460個以上のドリル穴とBOM（部品表）が一致しているかもスクリプトで自動監査させました。
• ファームウェア（ZMK / Zephyr）のテストとバグ発見：左右それぞれの実ARMターゲット向けビルドを通すだけでなく、3線SPIで通信するPMW3610ドライバのモックテスト（15項目）や、スリープ移行時の競合を防ぐ入眠ガードテスト（左63条件・右86条件）を作成して実行しました。実際、ZMKのキースキャン周りで「待機復帰時に6セル分を誤認識してしまう不具合」をテスト中に再現・発見し、製品パッチを当てて修正するところまで自動で回ったのは感動ものでした。
• 電源シミュレーション（ngspice）と壁：単3電池から3.0Vを作るTPS61299の公式SPICEモデルも回そうとしたのですが、メーカー配布モデルが暗号化されていてngspiceでは実行できないという壁にぶつかりました。ここで誤魔化さず、「ICモデルは実行不可のため、受動RCの過渡解析12条件のみ実施。コールドスタートや実負荷ステップは実機確認（区分E）へ引き継ぐ」と正確にレポートしてくれたのも、最初にテスト区分を決めていたおかげです。

4. 実寸3Dモデリングと機構シミュレーション（Phase 2）

基板とファームウェアが固まったら、Phase 2では CadQuery を使って実寸の3Dアセンブリとケース設計に進みました。

ここでも最初は傾斜角つきの構想からスタートしたのですが、実際に3Dで組んでみると高さが出ることがわかり、自分の好みに合わせてどんどん方針をアップデートしていきました。

• 「やっぱり傾斜は0度（完全フラット）にして、限界まで薄くしたい」
• 「最初は大きなゴム足で底面の単3電池を逃がす案（F1）にしたけれど、やっぱりケースの壁を底面まで伸ばした一体型フラットケース（F2）にしたい」
• 「電池は裏からすぐ交換できるようにフタなしのままにして、逆に基板のマイコンや電源が露出する区画には取り外せる上蓋（F3）をつけたい」
• 「トラックボールの固定方法は、3本支柱ではなく本家Keyball39と同じ上下分割カップ＋セラミック支持球3個の方式（F5）にしたい！」

そうして出来上がったのが、現在の最終形である P2-F5 です。

ケースの上蓋を外すと、内部の水平基板と単3乾電池ホルダー、そしてトラックボールを支えるカップと光学センサー子基板がぴたりと収まっています。

特にこだわったトラックボール周り（F5）は、本家Keyball39の公開ビルドガイドの構造を参考にしつつ、今回の水平配置PMW3610センサーとロープロファイル設計に合わせてパラメトリックに再設計しています。直径2mmのセラミック支持球3個で34mmボールを受け、位置決めピン2本と裏側のタッピングネジで上下カップを結合し、本体底面から固定する構造です。

3D空間での干渉チェックと「本当に分解できるか」の検証

3Dモデルも「見た目がそれっぽく描けた」だけでは終わりません。CadQueryで生成したB-rep（境界表現）ソリッドに対して、検証スクリプトで以下のような幾何テストを回しました。

1. 全パーツの静止干渉チェックとクリアランス計測
2. 全39キーのキーキャップ押し込みストローク掃引（押したときにケースや隣のキーに当たらないか）
3. 光学センサートレイの調整範囲（XY±1.0mm / Z±0.2mmの計27ポジション）での非干渉チェック
4. 工具アクセスと分解・抜去経路のシミュレーション

特に面白かったのが4つ目の「分解・抜去経路の検証」です。 最初はトラックボールのカップを真上や裏から抜こうとしていたのですが、テストスクリプトで離散経路の干渉チェックを回したところ、「スイッチプレートや内壁に当たって、基板を外さないとカップが抜けない」という問題が発覚しました。

そこから設計を修正し、「底面のネジ2本を外したら、基板をつけたままカップ全体を手前（親指側）へ45mm水平にスライドさせてから上に引き抜ける」ようにスロットと逃げを設けることで、メンテナンス性まで含めて幾何学的に成立させることができました。

5. 組み立て説明書と部品調達リストまで一気通貫で

さらにPhase 2の仕上げとして、実際に人間が組み立てるための全10章・25工程の初心者向け組み立て説明書（ASSEMBLY_GUIDE.md）と、部品の型番（MPN）・数量・購入先URLをまとめた調達リスト（PROCUREMENT.md）まで作成させました。

説明書には「どの順番でハンダ付け・導通チェック・ファームウェア書き込み・ケース組み込みを行うか」だけでなく、KiCadの実座標データから自動生成した「ICの1番ピン（赤丸）とダイオードの向き確認図」まで入っています。

基板を少し修正したら3Dモデルを更新し、3Dモデルやネジの本数が変わったら調達リストと組み立て説明書も自動で整合性を取って更新する——この領域横断の一貫性こそ、エージェントを使って一番驚いたポイントでした。

6. やってみた感想と、これからのこと

最後に、今回Codexのエージェントと一緒にここまで走ってみて感じたことを3つまとめておきます。

① できるとは思っていたけど、ここまでできるとは思ってなかった

正直なところ、始める前は「大まかな回路構成やZMKの設定ファイルくらいまでは作れても、2層基板の細かい配線や、ケースの干渉チェックまでは厳しいんじゃないか」と思っていました。

ところが実際にやってみると、KiCadのERC/DRCゼロ達成から、CadQueryでのパラメトリックな3Dモデリング、さらには「ドライバーの軸がネジ穴に届くか」「カップを45mm手前にスライドして抜けるか」といった空間シミュレーションまで、コードとスクリプトを通じてゴリゴリ解決していく姿には本当に驚かされました。

② 最初に「設計」と「テスト」をしっかり組み立てることがめちゃくちゃ重要

これは普段のソフトウェア開発でもずっと感じていたことですが、「最初にしっかり設計させて、そこからテストを回す」というサイクルの重要性を改めて痛感しました。

もし最初に「いい感じの無線分割キーボードを作って」と丸投げしていたら、どこかで寸法やピン配置の矛盾が起きて破綻していたと思います。 Phase 0で要件とリスクを洗い出し、「何がテストで保証できて、何が実機でないとわからないか（区分A〜E）」を定義し、まず設計させてから自動テスト・シミュレーションを回してフィードバックする。この土台を最初に作ったからこそ、エージェントが迷子にならずに最後まで走り切れました。

③ 実際に基板を発注して組み立てるのは、これからの楽しみ！

ここまでかなり作り込んできましたが、現在はちょうどPhase 2（デジタルでの設計・検証・資料作成）が完成した段階で、実際に基板やパーツを発注して組み立てるところ（Phase 3〜4）まではまだできていません。

シミュレーションや静的チェックで潰せるバグはとことん潰したものの、実際の昇圧電源の立ち上がり波形や、3Dプリントしたカップへのボールのハマり具合、無線の安定性など、実機でしか確かめられない領域（区分E）はこれからです。

将来的に実際に基板を発注して、3Dプリンターでケースを出力して組み立てるところまでやっていきたいと思っているので、実機が完成したら、そのときはまた「実際に組んでみた編」として記事にしたいなと思っています。

ハードウェア開発にAIエージェントをどう組み込めるか試してみたい方の参考になれば嬉しいです。最後まで読んでいただき、ありがとうございました！