これはWise Vineのエンジニアである私の「趣味の話」で弊社の企業活動とは一切関係のないことでございます。
はじめに
本記事は、以下の記事の続きになります。
趣味でオーディオのデジタル音源処理をする機器のプログラミングを始めました。 私自身、組み込み開発やCUDA（GPU並列計算）に関してはほとんど経験がなかったのですが、わずか1ヶ月ほどの開発で、今では自作機器を経由した最高の音質で日々音楽を楽しめています。フルリモート勤務で、家で過ごす時間が長いからこそ、音質の向上は「エンジニア・ライフ・バリュー（ELV）」の爆上がり意味し、個人的には大変満足度が高いです。
今回は、この音響機器のプログラミングをする上で、AI（LLM）をフル活用して未知の領域を突破する中で得た、「AIに開発をリードさせるための実践的な知見」を共有したいと思います。
1. 雑なドキュメントは「毒」になる。終わったら即消す。大事な物だけ残す
AIに作業を依頼すると、「実行計画」や「途中経過のMarkdown」を残したがります。しかし、これこそが落とし穴です。
- 開発途中のドキュメントはメンテナンスされない: 開発が進むと、それらのファイルはすぐに古い情報になります。
- AIが過去に囚われる: AIはコンテキスト内にある情報を優先するため、リポジトリが古いドキュメントが残っていると、それを元に間違った計画を立てたり、古い仕様でサジェストをし始めたりします。
- 文章メンテナンスはコストが上がる: これらを定期的にメンテナンスするのが意外とコストになりました。見ない文章は「不要」とバッサリ消す、その勇気は結構大事です。
対策： 作業が終わったら一時的なメモは消す。情報はGitHubのISSUEに集約し、作業が終わったらCloseするようにしました。連続する作業は、1つの「EPIC ISSUE」を作成し、そこのコメントに作業履歴や重要な意思決定を残させるのが今のところ効率的な対策です。また、開発に共有するルールがあれば、その手のものはSkillsやAGENT.mdやCLAUDE.mdに記載していくと良いでしょう。
2. 「構造」の設計は人間のエンジニアが死守する
AIに任せきりにすると、機能実装を優先するあまり、コードが肥大化してスパゲッティ化します。
- ディレクトリとファイル分割の徹底: 最初から正しく構造化しないと、AIもコードの全体像を把握できなくなります。
- 抽象化によるパイプライン化: 処理を適切に抽象化し、パイプラインとして繋げられるように設計することが肝要です。
この「どう抽象化し、どう構造化するか」という指示や嗅覚も、AI時代のエンジニアに求められる重要な素養だと痛感しました。
3. レビューは「多角的」かつ「複数回」行う
AIは実装能力は高いですが、要件をポロッと漏らすことがよくあります。
- セルフレビューをさせる: 実装した直後に、「実装漏れや考慮漏れがないか」をチェックさせます。複数モデル使えると良いですが、使えるAIモデルが1つでも、必ずレビューはさせるようにしましょう。
- 視点を変える: 単に「レビューして」と言うのではなく、2回目には「ビジネス視点や保守性の観点も含めて」と条件を加えると、格段に精度が上がります。
- 適材適所: コードの細かいロジックのレビューには、やはりCodex系（2026年1月時点ではGPT-5.2等）の賢いモデルが非常に頼りになります。
4. 「ログ」はAIにとっての「目」である
AIに「動かない」と伝えても、超能力者ではないので解決できません。問題を正しく伝えるための「ログ」の仕込みが、デバッグの成否を分けます。
私の場合、音が飛び飛びになったり、プチプチノイズが出るといった問題が出ました。どこのバッファが溢れているかを丁寧にログで出力させるようにした結果、音飛びがほぼ出ない安定した動作になりました。
詳細なログがあれば、AIはそのログを読み取り、自分自身で原因を切り分けて修正案を出してくれます。「AIがデバッグしやすい環境を作ってあげる」のが、飼い主の務めです。
5. マクロな視点とリファクタリングをサボらない
目先の機能が動くと満足してしまいがちですが、あえてマクロな問いをAIに投げ続けます。
- 課題の洗い出し: 「現状、デバイスの抜き差しを繰り返した時に起こりうる問題は？」といった、境界条件や運用の課題を調査させます。
- 定期的なリファクタリング: 定期的にリファクタリングのISSUEを立てましょう。AIと議論しながら技術負債をISSUE化するのがお勧めです。
6. 後方互換を気にせずに「ビルド&スクラップ」する勇気
弊社のSaaS Build&Scrap…ではなくて、何か追加したい機能や「これ良いんじゃない？」と思ったものはとりあえず実装してみて試してみるのがオススメです。
結果、上手く行かなかったことは山程ありますが、その際は後方互換を気にせずに、「全部消せ」と指示して行くと、技術負債も積み上がらず、結果として上手く回ります。
AIはこういうスクラップする判断が苦手です。下手に残すと、その機能に引きずられるので、どんどん削除していくことがオススメです。
7. 「動けば正義」と割り切る勇気と、「知るべき情報」の選別
複雑な信号処理やCUDAの最適化ロジックを、人間が一行ずつ完璧に理解しようとするのは、もはやコストパフォーマンスに見合いません。
- テストが仕様書: 厳密なユニットテストを書かせ、それが通っているのであれば、中身のブラックボックス化を一定許容する勇気も必要です。
- 人間が知るべきことの選別: ロジックの詳細はAIに任せても、例えば「データ構造（データの持ち方）」は人間がしっかり把握しておくなど切り分けは必要です。ここがズレると、AIへの指示がすべて狂うからです。
8. ほしいと思ったら、AIに相談する
「こんな機能が欲しい」とふと相談してみると、AIは驚くような解決策を提示してくれます。
例えば、ヘッドホンをスピーカーで聴いているように錯覚させるアルゴリズムがあります。しかしこの周りは特許でガチガチだったりします。故に、「オープンソースで使える高品質なHRTF（頭部伝達関数）データはあるか？」と尋ねたところ、HUTUBSというデータベースを教えてくれました。実際にこれを取り入れたところ、自作機器の臨場感が劇的に向上し、より良いリスニング体験が得られました。
他にも「ラウドネスウォーで潰れた音源を復元する良い方法はあるか？」といったら、ニューラルネットで推論するオープンソースのDe-Limiterを紹介して、実際に組み込む事が出来ました。
要件定義は人間しか出来ません。しかし、AIと議論することで、知らない事を知れる、面白いアイデアと実践が繋がるみたいなことが結構ありました。
まとめ
今まではその筋の専門家や、経験豊富なエンジニアでないと出来なかった事を、AIと議論し、共に学び、新しい発想をぶつけ合うことで、一人では辿り着けなかった「音」に爆速で到達することは出来ました。しかし、当たり前ではあるものの、なんだかんだその過程は、割と泥臭い、人間と開発したときにもやるべき基本を、AIにも守ってもらう過程だと痛感しています。
また、AIも万能ではないので「守れ」と言わないと、約束事や実装意図を理解せずに実装してしまうことは日常茶飯事です。そのコミュニケーションロスを如何に減らすか、というのも、また人間と開発と同じだなと感じるところでした。
Discussion