普段はOSSへのコントリビューションや競技プログラミング、AI関連の開発などに取り組んでいる。
この開発ログでは、日々の開発や研究で考えたこと、試したことなどを、不定期にまとめている。
今回は2026年10月下旬の記録。
本記事は、自分で書いた日誌をもとに、公開可能な内容に再構成・編集している。
VOICEVOXへのコントリビューション
トーク・ソング切り替えボタンの実装
VOICEVOXで、トークとソングを切り替えるボタンを追加するIssueに取り組んだ。比較的着手しやすそうで、実装すると便利になりそうだったのが理由だ。
最初はQToolbar内にBase UIのコンポーネントを使って実装した。しかし、レビューでは、既存のQuasarコンポーネントを使う方針に合わせるよう指摘を受けた。
確かに、既存の実装に合わせた方が保守性の面では良さそうだ。ただ、Quasarで試してみると、ダークモードでは選択状態が分かりにくく、ライトモードでも直感的とは言いにくい表示になった。
自分の実装に問題がある可能性もあるが、既存コンポーネントを使うことと、UXを改善することの両立は意外と難しい。単に動くコードを書くだけでなく、既存の設計方針や操作性まで考える必要があると感じた。
ルーラーの右クリック修正とコードレビュー
ソング機能のルーラー（目盛り表示）に関する不具合修正にも取り組んだ。
今回はAIに実装を任せ、生成されたコードを大まかに確認してPRを提出した。しかしレビューでは、表面的に不具合を抑えているだけで、根本的な解決にはなっていないという指摘を受けた。
ルーラーと周辺要素の構造や重なり方に課題があり、そこから見直す必要があるということだった。自分は、そもそも不具合が起きる構造を十分に理解できていなかった。
追加したE2Eテストについても、細かいデザインの変更に依存しすぎていると指摘された。テストは多ければ良いわけではない。適切な抽象度で書かなければ、UIを変更するたびにテストの修正が必要になってしまう。
指摘を受けてテストを削除するなどの修正を行ったが、特に考えさせられたのは、AIが生成したコードを自分がどこまで理解できているのかという点だ。
AIを使えば短時間で実装できるが、その修正が本質的に正しいのかを判断するには、対象コードや設計の理解が欠かせない。
コードをじっくり読むと時間がかかる。一方で、十分に読まなければ問題を見落としてしまう。このバランスは今後も考えていきたい。
空戦AIチャレンジの開発環境構築
空戦AIチャレンジに向けた開発環境も構築した。
コンテスト関連のコードはモノレポで管理したいと考えているが、プロジェクトごとに使用する言語やバージョン、依存関係が異なる。
Pythonの依存関係管理
Pythonのパッケージ管理にはuvを使っている。最初は共通のuv.lockで管理することも考えたが、各プロジェクトが共通のワークスペースに依存する構成は避けたかった。
そこで、プロジェクトごとにuv.lockを持つ方針にした。プロジェクトをまたぐときは少し面倒だが、依存関係を分離できる方が良いと判断した。
シミュレーターの管理
公式の配布シミュレーターをそのままGitにコミットすると、リポジトリが大きくなってしまう。
そこで、配布物との差分だけをGitで管理し、残りはSIGNATE CLIからダウンロード・展開するPythonスクリプトを用意した。
多少セットアップは複雑になったが、リポジトリを軽量に保ちながら、必要な配布物を取得して環境を再構築できるようになった。
今後はこの環境を使ってベースラインを改善していきたい。
振り返り
今回の開発で特に印象に残ったのは、コードレビューで、自分では気づけなかった設計上の問題を指摘してもらえたことだ。
AIを使えば実装は速くなるが、設計の妥当性や保守性、テストの適切さまで判断するのは簡単ではない。
今後はAIを活用しつつ、生成されたコードを自分でも理解し、修正方針を判断できるようになりたい。
また公開できそうな記録が溜まったらまとめようと思う。