AIと9日で5万行。製品開発PJを1人でハックしたノウハウ

はじめに

WiseVineのアドベントカレンダーのエントリーです。しかも12/5金曜日分のフライング投稿です。

これはWise Vineのエンジニアである私の「趣味の話」で弊社の企業活動とは一切関係のないことでございます。
その上で、趣味とはいえ、今までの常識ではあり得ないプロダクト、プロジェクト開発をAIとともに個人でハックしたので、そのノウハウ・ナレッジをまとめたいと思います。

簡単に自己紹介

普段はSREエンジニアとして働いています。 基本的にはTerraformやCI/CDの構築、各種開発支援ツールの導入、そして最近では「AIを社内にどう浸透させるか」といった業務を行っています。

プライベートの趣味は音楽鑑賞とオーディオです。 プログラミングに関しては、インフラ周りのコードは書きますが、C++などのローレベルな言語は大学以来、20年近くは書いていません。

「CUDA？すごいよね。計算速度に隙がないよね。でも、俺、書けないよ」

そんな私が、今回AIとタッグを組んでGPUプログラミングに挑戦しました。

何を作ったか？

簡単に言うと、GPUを用いたデジタルサウンドプロセッサ=DSPです。

CUDAとC++をエンジンとし、Nvidia Jetsonを用いてデバイス化しました。ハイタップなオーバーサンプリング処理を行うDSPです。それを、zeroMQを使い、責務を限定し、Python(FastAPI)のWEBコントローラーをつける構成にしています。
詳細な仕様やオーディオ的なこだわりについては、以下のNoteに詳しくまとめていますので、興味のある方はぜひご覧ください。

開発規模：10日で5万行

このプロジェクトの特異な点は、その開発スピードとコード量にあります。約10日間という短期間で、以下の規模の実装を行いました。Markdownを除いても実働コードで約3.4万行(内C++,Python,Cuda関連で2.2万行)、主要部分のテストで約1万行。テスト比率が4割overという、個人が趣味でわずか10日でやったとは思えない量です。

尚、平日にディベロッパーズ・ハイになり睡眠時間でやや無理はしました。が、日常業務をこなしつつ、休日は鳥取砂丘やとっとり花回路に家族と行ったりもしました。決して書斎にだけこもっていたわけでもありません。

一昔前なら、2〜5人が半年以上かけて開発する規模の案件です。それに、いくらかテンプレートのあるWEBサービスとは違い、Cudaを用いたリアルタイム信号処理、複雑なメモリ管理と、ゼロベースでのコーディングで、かつ、スキルとしては超一級品を求められれます。出来るプログラマを日本で探すだけでも、本当に困難なレベルのものです。

プロジェクト全体（testsディレクトリ除外）

言語	ファイル数	コード行数
Markdown	55	9,359
C++	24	8,387
Python	48	8,354
JSON	33	6,813
CUDA	7	3,702
C/C++ Header	31	2,111
Shell	8	1,479
その他	19	3,389
合計	225	43,594

テストコード（testsディレクトリ内）

言語	ファイル数	コード行数
Python	29	5,885
C++	17	3,354
CUDA	2	1,402
合計	49	10,668

大枠のコンセプト

この開発における私のスタンスは「人はAIのマネジメントに集中する」というものです。
「AIにコードを書かせる」のではなく、「AIと共にプロジェクトを遂行する」という意識で、以下のようなフローを回しました。

1. AIとともに賢くなる: ドメイン知識をAIから学び、解像度を上げる。
2. 言語化の徹底: 賢くなった頭で「何を作るか」「どう作るか」をAIと議論し、AIに徹底的に言語化させる。
3. ISSUEの構造化: 言語化した内容をISSUEとしてAIに管理・ステータス化させる。
4. タスク割り振り: 優先順位を付け、適切なAIエージェントにISSUEを割り振る。
5. 実行計画の承認: AIが提示したPlan（実行計画）が妥当か判断する。
6. 検品（レビュー）: 出来上がったものを検査する。
7. 再設計: 不合格の場合、新たな課題として管理し、解決策を再度議論する。

具体的なノウハウ紹介

ここからは、実際にプロジェクトを回す中で確立した具体的なノウハウを紹介します。

1. 徹底的なAIとの対話と教師化、ドメイン知識の解像度を上げる

今回作ったのは高度なオーディオ機器ですが、はっきり言って私はこの分野のハードウェア/ソフトウェア実装については「ずぶの素人」でした。
だからこそ、AIを教師として徹底的に活用しました。

知らないことは「知らない」と言い、AIに解説を求める。そうすることで、自分の知識レベルが上がり、見えていなかった課題が浮き彫りになります。

具体的なセッション例

私：「DACの方式、ΔΣ（デルタシグマ）って何？」
AI：「ΔΣ型とは…（解説）…」
私：「なんでオーバーサンプリングが必要なの？ なんでオーバーサンプリングするとノイズシェーピングができるの？」
AI：「それは…（解説）…」
（…中略…）
私：「あー、結局オーバーサンプリングのところで物理的な問題があるんだね」
AI：「はい。ユーザー様の理解は正しいです。それを解決した商品としてChordのM Scalerというものがあり、FPGAで100万タップの…」
私：「なんでFPGAなの？ 所詮ステレオデータのリアルタイムデータの畳み込み積分でしょ？ GPUでも出来るじゃん」
AI：「確かにGPUでも出来ますが、非常に大きな問題があります。それは、リアルタイム処理で複雑なアルゴリズムを、それもメモリ管理を徹底して…」
私の心の声：『（あれ…その課題、AIに書かせたら解決できるんじゃね？）』

このように、AIに相談し、壁打ち相手になってもらうことで、プロダクトの核となるアイデアや技術的課題の解決策が見えてきます。

2. AIを「優秀な外部パートナー」と考える

〜徹底的なISSUE管理によるスクラム開発〜

AIの最大の弱点は「すぐに忘れる」ことです。
どんなに素晴らしい議論をしても、セッションメモリが圧縮されれば文脈は失われます。そのため、ウォーターフォール型の巨大な仕様書を渡して「これを作って」と投げてもうまくいきません。

まずは、小さなゴールを決めて、ソレに向けてAIに指示を出していきます。
例えば「イコライザ機能をすでにあるFFTアルゴリズムに乗せて実現したい」というのが、小さなゴールとなります。

次に、AIがメモリ圧縮を起こさないレベル（＝コンテキストを維持できるサイズ）まで事前にタスクを分解するのですが、そのISSUE分解すらもAI（主にClaudeのPlanモードなど）に行わせます。AIをプロジェクトコンサルとして使いました。

具体的なセッション例

私：「イコライザ機能を実装したいが、すでにあるアップサンプリングのFFTに合わせることは可能か？」

AI：「可能です。具体的には…」

私：「OK。ではそれを前提に『[EPIC]イコライザ機能』という親ISSUEを立てて、タスクを分解し、サブISSUEを立てる計画を作成せよ」

AI：「計画を立てました…（タスクリスト提示）」

私：「イコライザはパラメトリックEQでファイルを読み取る形。管理画面もテキスト入力があれば良くて、レバー操作できるUIはいらない。」

AI：「修正案を作成しました」

私：「AのISSUEとBのISSUEは、一緒に開発しないと複雑にならない？」

AI：「そんな事はありません。アーキテクチャで分離しているので、それぞれ別でPRを出したほうが良いと思います」

私：「ちゃんとオーバーサンプリングと同じ64kのFIRで実装しておいてほしいが、その指示もISSUEに書いておいて」

ポイントは「親ISSUE」の存在です。親ISSUEに目的や背景を集約しておくことで、AIが迷った時の判断基準（コンテキスト）を提供し続けることができます。

3. AIを「信じない」

〜徹底的なテスト駆動開発と丁寧なCI〜

AIは稀に既存機能を「壊す」し、平気で致命的なバグを仕込んできます。
これを防ぐために、徹底的にCIでコード規約を守らせ、テストの実装・実施を守らせます。

まずはCIの徹底です。Linterや静的コード解析で、コードがグチャグチャになるのを防ぎつつ、AIがコードレビューの際、テストが不足していたり書いていない場合は、私がストッパーとなり「テストを書け」と突き返します。このルールは CLAUDE.md や AGENTS.md といった指示書ファイルに明記しておくと効果的です。

具体的な対策

• Pre-commit-hookの活用:
  • pre-commit で静的コード解析、Linterを回す。
  • pre-push で上記に加え、自動テスト、mypyなどの重い型判定を実行する。
• 本来はGitHub Actionsの活用がベストですが、GPUテストなどはコストが嵩むため、ローカルで全て巻き取る構成にしました。
• たまに、--no-verifyとかやりだすので、ちゃんとAIのルールに書いておきます

--no-verify禁止: git push --no-verifyやgit commit --no-verifyは絶対に使用しないこと。pre-commitフックやpre-pushフックで失敗した場合は、たとえ自分の変更に起因しないエラーであっても、そのエラーを修正してからプッシュすること。テストの品質維持は全員の責任。

4. 大量の新人リソースの投入したスクラム開発

〜Git worktreeを使ったパラレル実装〜

ISSUEが細分化され、テストによって堅牢性が担保された状態であれば、開発速度を限界まで上げることができます。

ここで活躍するのが git worktree です。
ターミナルを複数立ち上げ、それぞれ別々の親ISSUEに紐づく機能を同時並行でAIに開発・レビューさせます。感覚としては、「大量の優秀な新人エンジニア」を一斉に指揮している状態です。

可能な限りお互いが干渉しないようISSUEを割り振るのが、人間の（マネージャーの）仕事です。

よく使った指示テンプレート

https://github.com/hogefoo/issues/123
このタスクを実施する計画を立てよ。作業はワークツリーを使って行うこと。
尚、親ISSUEは以下である。必ず確認し、作業が親ISSUEの趣旨に沿ったものかも考慮せよ。
https://github.com/hogefoo/issues/120

これだけの指示で、テストやCI/CDに守られた高品質なコードが次々と上がってきます。

5. Planモードを使って「目的との整合性」をひたすら確認

実装前に「実行計画を立てよ」という指示を徹底します（主にClaudeやCursor等のPlanモード活用）。
AIが最初に立てる計画は、往々にして目的からズレています。その場合、実装を許可せず、ISSUEの修正や指示の明確化に時間を割きます。

具体的なセッション例

私：「ISSUE-123のタスクを実施する計画を…」

AI：「計画は以下の通りです…」

私：「私が実現すべきマストな要件は2つある。『1.絶対にクリップノイズを発生させない』『2.音量がサンプリングレートやIR計画が変わっても揃っている』だ。今の計画でこれがなぜ担保されるのか回答せよ」

AI：「…申し訳ありません。ISSUEの指示ではクリッピング阻止しか書かれていないため、現状の計画だと音量はバラつきます」

私：「ISSUEに必須条件としてその2点を明記せよ。実装はそのあとだ」

ISSUEを修正し、AIのメモリをクリアしてから、再度計画を立てさせます。急がば回れです。

6. 適材適所のエージェント配置

AIモデルによって得意・不得意があります。私は以下のように使い分けました。

• 計画・ISSUE整備: Claude 4.5 Opus / Sonnet
  • 文脈理解が高く、わかりやすいISSUEをまとめてくれる。
• ライトな実装: Cursor Composer, Claude 4.5 Sonnet
  • 速度重視。多少荒くても良いのでプロトタイプを作る。
  • セルフレビューを3回くらい繰り返させると、自分でバグを見つけて直してくれる。
• 複雑な実装（コアエンジン）: ChatGPT-codex (5.1系など論理に強いモデル)
  • 速度は遅いが、完成度が非常に高い。
  • CUDAのような難解なコードでも、レビューでの指摘がほぼ無く、セルフレビューでもツッコミが入らないレベルのコードを出してくる。

「CUDAのコードの良し悪しなんて私には分からない」からこそ、最も優秀なエージェントに実装とレビューを任せます。

7. 人間は、より高度な判断と「違和感」の検知に集中する

とはいえ、完全にレビューをAI任せにするわけではありません。
人間には、「何かがおかしい」という違和感を嗅ぎ分ける能力があります。

私：「今回実装したイコライザ、ちゃんと640kタップのFIRで実装してるよね？」
AI：「いいえ。1000タップのIIRで実装しています。修正が必要でしょうか？」

この「違和感」に気づくために必要なのが、最初に述べた「ドメイン知識の習得（AIとの対話）」です。
人間は、AIが目的から逸脱していないか、矛盾した実装をしていないかを監視し、プロダクトの品質を最後の砦として守ります。

---

今後の課題

• 自動化の推進: レビュー指示やタスク振り分けの手動作業を減らしたい。ISSUEのURLを貼るだけの定型作業は自動化の余地がある。
• AIによる自律レビュー: post-push フックなどでAIが自動起動し、コードレビューをしてコメントを残す、さらにそのコメントを受けて修正する…といった完全自動フローを作りたい。

数ヶ月後には、人間は本当に「作りたいものを思い描く」「計画の確認」「検品」「優先順位付け」「最後の品質番人」のみを行うようになっているかもしれません。

まとめ

今回の開発体験は、「コロコロ入れ替わる優秀な業務委託コンサル・プログラマー集団」をどうマネジメントするか、という問題に非常に似ていました。

1. 大ゴール(プロダクトビジョン)、中ゴール(Epic ISSUE)、小ゴール（ISSUE）の明確化
2. 作業可能な粒度までタスクを分解
3. ドキュメント化し、完了したものはCloseし、進捗管理
4. 優秀なエージェントにはコア部分を、機動力のあるエージェントには雑務を
5. ロバストな設計とCI/CDで、誰が触っても壊れない堅牢性

改めて、これは「ゲームチェンジ」です。
今まで「コストが見合わない」と諦めていたものが、AIによって爆速の開発により、簡単に実現できる時代になりました。
「ハイエンドオーディオというニッチ市場向けの、GPUアップサンプラー兼イコライザ」なんて、通常なら開発費だけで莫大な金額になります。それが、素人の手によって、わずか10日で実用レベルの製品として形になりました。

これはWise Vineが活動の主とする行政というドメインでも同じことが言えるはずです。誰もがよくなって欲しいと願っても、原資が税金だったり、そもそもの市場規模の観点から、大事だけど一般企業がなかなか手を出せない領域でした。しかし、世の中は確実に動き出しています。

私のGPU/DSPに興味のある方・企業様へ

改めて、本プロジェクトで作成したプロダクトの詳細は、以下の記事をご覧ください。

※本件は私の趣味の話であり、Wise Vineは一切関係がありません。