千葉工大 AI活用推進助成プログラムに採択されました — AIとの対話そのものが応募書類だった話
概要
在学している千葉工業大学が学内で実施している、学習・研究における AI 活用を後押しする助成プログラムです。助成内容は Claude Enterprise のプレミアムシート の付与で、プロジェクト期間は 2026年7月28日から 2027年5月1日までです。
提案タイトルは 「ReLow60 L-HE: AI協働によるホールエフェクト式キーボードの改良・新製品開発」、結果は 採択 です。
応募方法が変わっていた
このプログラムでいちばん面白かったのは応募方法です。フォームに志望動機を書いて提出する形式ではなく、AI（Evaluator）との対話そのものが評価対象 でした。テーマを対話を通して深掘りしていく過程が、そのまま提出物になります。
制限時間はなく、提出は一度きり。どれだけこちらの話を理解してくれるんだろう、と思いながら始めたのですが、想像よりずっと突っ込んだ質問が飛んできました。ここからは、実際の対話で聞かれたことと答えたことを整理します。
対話で聞かれたこと・答えたこと
これまでどうAIを使ってきたか
いちばん比重が大きいのは レビューと検証 です。回路基板の設計では、どのような配置にするとノイズが少ないかを、根拠となるソースを同時に提示してもらいながら詰めました。ファームウェアや設定ツールでは、たたき台の生成や実装方針の相談に使っています。
ただし、何を採用するかの判断と、実機での動作確認は自分でやります。 出てきたものをそのまま製品に載せることはありません。打鍵感や設定のしやすさのような「実際に押してみないと分からない部分」は、AI が代われないところだと考えています。
設計のあとのマーケティングやコンテスト応募のような、プロジェクトを俯瞰して見る必要がある場面でも、自分以外のもう一人の視点として役立てています。
最も価値を感じた瞬間は？
回路設計で 配線ミスを指摘してもらえたこと です。重大なミスでしたが、回路図ファイルを読んで指摘してもらったおかげで、発注前に気づくことができました。基板を作り直していたら、時間もお金も大きく失っていたところです。
次点は、作った基板の性能を計測するときに、どのような条件で計測して、どのような基準で評価すればいいのかを教えてもらったことです。プロダクトのテストに関する知識が自分になく、困っていたので助かりました。ここは「答えを出してもらった」というより「評価の物差しを教えてもらった」感覚に近いです。
次に何をするのか
現行版はテスト版として限定販売中で、そこからのフィードバックを受けて本格的な完成版を作る段階です。優先順位をつけて答えました。
優先度1：ソフトウェア／ファームウェア（共通基盤）
- 高度なマクロ機能の実装（時間差、条件分岐、変数など）
- ReConf の UI 改善。機能が多すぎて初めての人が迷うという声があるので、初心者モードと上級者モードの分離、主要機能の強調
- ファームウェアと ReConf の連携最適化、メモリ使用量の削減
優先度2：ハードウェア改善版
- ケースまわりの構造の見直し（次のリビジョンでの改善点）
- 改善版の設計・発注・テスト
優先度3：新製品開発
- 75%、オーソリニア配列、左右分割など。入力機器の選択肢の幅を広げるという目的も兼ねています
- 既存ソフトウェアの新製品対応
優先度4：独自ブートシステム（後回し可）
現在は DFU モードでブラウザからファームウェアを書き込んでいますが、Windows 環境では WebHID で DFU モードをつかめないことがあります（Linux / Mac では発生しません）。独自のブートシステムを作れば解決しますが、必須の改善ではなく工数がかなり重いので、優先度は下げました。
ソフトウェアを最優先にしたのは、今後の新製品でも同じソフトウェアを使い回したい からです。ここの完成度を上げておくと、後続の製品すべてに効いてきます。
ハードウェア設計にAIをどう使うのか
前回の設計では、ハードウェア面であまり AI を活用できていませんでした。理由は単純で、CADファイルをそのまま渡すことができない からです。
今後は、具体的な数値を伝えたり、使う人間側が言語化したうえで AI を通して設計することで、設計ミスを潰していきたいと考えています。嵌合深さや荷重の力学的な相談、ネジ穴配置と強度の構造検証といったやり取りです。
AI活用のスタンス
すべてを AI に任せると自分の成長がないので、まずは自分の仮説を AI にぶつけてみる ことを意識しています。そうすれば自分の認識の間違いに気づけますし、時には AI 側のハルシネーションにも気づけるからです。
並列開発について
一人で開発している以上、同時に進められる本数には限りがあります。そこで、ユーザーからの声・自分の要望・AI の意見を合わせて仕様書を作り、内容を確認したうえで実装のたたき台を進めてもらい、その間に自分は次の仕様書を書く、という進め方をしています。
複数を並行させると噛み合わなくなるので、進行状況を記録するファイルを共有させたり、あとから統合しやすい形に土台を寄せておいたりといった工夫をしています。
Web の知識が乏しかった自分でも、AI に助けてもらいながら ReConf と製品サイトを形にできたのは大きかったです。一方でうまくいかなかったのが ReConf の UI でした。自分が納得できる状態になるまで何度も対話を重ね、最終的には自分で細かく詰め直しています。「AI に任せれば早い」が成り立たなかった部分 です。
対話を通じて気づいたこと
最後に「今回の会話を通じて、何か新しい気づきはありましたか」と聞かれました。
スケジュールの現実性 です。細かいタスクに分解することは得意なのですが、長期的なプランを立てるのは自分の苦手とするところでした。この対話で、具体的なタスクと長期的なプランをぶつける方法と、その大切さを学べました。
途中、9月のイベントまで2ヶ月しかない状況で「ソフト改善・ハード改善版・新製品」をすべて並行するという計画に対して、「正直に聞きます。これは本当に2ヶ月で達成可能だと思いますか？」 と突っ込まれる場面もありました。基板の製造リードタイムを考えると再発注の余地がほぼない、という指摘です。
そこで自分でも整理し直して、9月は絶対のデッドラインではなく一つのマイルストーンであること、自作キーボード系のイベントは3ヶ月に一回あること、テスト版と改善版でソフトウェアがほぼ共通なのでハードの生産待ち期間も開発を継続できることを確認できました。詰められて初めて言語化できた 部分です。
「もしもう一度やり直すとしたら？」という問いには、「QWS Challenge の応募文と設計理念を先に話す」 と答えました。技術的な特徴から入るより、その背景にある問いから共有したほうが、話が早く核心に届いたはずだからです。
採択後の条件（概要）
採択にあたって、いくつかお願いされている事項があります。詳細は割愛しますが、おおむね次のような内容です。
- 成果物（ソースコード、設定ファイル、ドキュメント等）は可能な範囲で Git リポジトリで管理する
- 進捗確認のため、リポジトリを担当の先生方と共有する。ただし 公開（Public）にする必要はなく、非公開のまま共有だけでも問題ない
- 能動的な監視は行われず、Git 履歴と利用状況による受動的な確認のみ
- 初日からすべての作業を Git 管理下に置き、試行錯誤も含めてこまめにコミットする
- API キーは既定では発行されず、十分な進捗と必要性が示された段階で相談する形
期間中にどの提案に取り組むかは応募者に任されていて、研究の進展に伴う目標の変更やピボットも歓迎、とのことでした。
これから
2027年5月まで、まずはソフトウェアとファームウェアの改善から着手します。ここが固まれば、その後の新製品すべてに効いてきます。
TiB・AI活用助成・DigiKey・QWS の4件まとめ
ReLowシリーズ キーボードコンフィギュレータ