最近、YMulator-SynthというYM2151（OPM）FM音源のシンセサイザープロジェクトをリリースしました。このプロジェクトの特徴は、私がコードを直接書いた回数がゼロ だということです。すべてClaude Codeというツールを使ったAIコーディングで実装しました。本記事ではそのAIコーディングの記録と考察を述べます。
はじめに：開発期間の劇的な短縮
通常なら数ヶ月以上かかるであろうAudio Unitプラグインの開発を、平日夜と週末だけの作業で2〜3週間で完成 させることができました。この経験から得られた知見を共有したいと思います。
具体的な開発速度の比較：
| 作業内容 | 従来の想定期間 | 実際の所要時間 |
|---|---|---|
| Phase 1（基盤構築） | 2ヶ月 | 2〜3日 |
| Phase 2（コア機能実装） | 1.5ヶ月 | 1週間 |
| Phase 3（UI強化） | 1ヶ月 | 1週間 |
| CI/CD環境構築 | 1週間 | 30分 |
実際のコミット履歴を見ると、かなりの速度で実装が進んでいることがわかります：
- プロジェクト規模: 完全なAudio Unitプラグイン（数千行規模のC++コード）
- 開発期間: 約2-3週間で初期リリースから本格的なリリース版まで到達
- 実作業時間: 土日の暇な時間（家族サービス時間外）と平日夜のみ
特に、以下のような複雑な機能も短時間で完了しました：
- プリセット管理: 1-2日
- MIDI CC完全対応（48パラメータ）: 半日
従来の手法では、Audio Unitプラグインの基本実装だけでも1-2週間、全機能の実装には1-2ヶ月かかることが一般的です。しかも、それはフルタイムで開発した場合の話です。副業や趣味として夜間・週末だけで開発する場合、通常なら半年から1年はかかるプロジェクトでしょう。
Claude Code？
Claude Codeは、Anthropic社が提供するターミナルベースのAIコーディングツールです。私は2025年4月頃から使い始めていましたが、5月1日にMaxプランにClaude Codeが含まれるようになってから本格的に活用するようになりました。
定額制のMaxプランにより、従量課金の心理的ハードルから解放されたことは大きかったです。 課金額を気にせず、思い切り使えるようになりました。
成功の鍵：事前準備の重要性
AIコーディングを成功させるには、事前準備が重要でした。特に以下の3つが効果的でした。
1. サンプルコードの準備
最初はヒントなしで実装を依頼してみたのですが、うまくいきませんでした。しかし、事前に作っておいたYMFMのサンプルコードを参照させたところ、どんどん実装を進めるようになりました。
そう、一つ手前のブログ記事がそのサンプルコードです。
この経験から学んだこと：AIは一般的な知識は豊富でも、特定のライブラリの使い方は知らない場合がある。動作するサンプルコードの準備が成功の鍵でした。
2. 設計ドキュメントの作成
設計ドキュメントの質が、AIコーディングの成否を大きく左右します。 しかし、これもゼロから書く必要はありません。
私の場合、以下のようなプロセスで設計ドキュメントを作成しました：
- ChatGPT/Claudeに概要を説明
- AIが設計書のテンプレートを提案
- 具体的な要件を追加
- AIが詳細化
つまり、「どういったものを書いておいた方が良いか」を知っていれば、実際の文書作成はAIに任せられます。
設計ドキュメントには、以下のような内容を含めました：
- システムアーキテクチャ
- 実装フェーズの分割（Phase 1〜4の詳細なタスク分解）
- 優先度の明確化
- 進捗状況の記録
3. CLAUDE.mdによる指示の標準化
プロジェクトのルートにCLAUDE.mdというファイルを作成し、Claude Codeへの指示を標準化しました。このファイル自体もClaude Codeに作成・更新してもらっています。
生成されたCLAUDE.mdには以下のような内容が含まれています：
重要ドキュメントへの参照指示：
## ⚠️ CRITICAL: ALWAYS READ RELEVANT DOCUMENTATION FIRST
これにより、Claude Codeは常に設計ドキュメントを参照してから実装を始めるようになりました。
コーディング規約の具体例：
// ❌ NEVER use magic numbers
// ✅ ALWAYS use named constants
具体的な良い例・悪い例を示すことで、一貫性のあるコードが生成されるようになりました。
必須の検証手順：
# MANDATORY for every commit:
auval -v aumu YMul Hrki > /dev/null 2>&1 && echo "auval PASSED"
Claude Codeは毎回Audio Unitの検証を実行し、品質を保証するようになりました。
このCLAUDE.mdのおかげで、「ビルドして」「テストして」といった基本的な指示を毎回出す必要がなくなり、より高度な実装に集中できるようになりました。
実際の開発プロセス
設計ドキュメントができたら、Claude Codeで実装を進めます。基本的な流れは：
- 設計ドキュメントの該当フェーズを参照させる
- 実装を依頼（例：「Phase 2.1のポリフォニック対応を実装して」）
- Claude Codeが自動的にタスクを分解して実装
- コミット（適切なメッセージも自動生成）
- 動作確認
- 開発ステータスドキュメントの更新を依頼
- 次のフェーズへ
特に効果的だったのは、開発ステータスドキュメントの自動更新です。「今完了したタスクのステータスを更新して」と依頼すると、Claude Codeが進捗状況を整理してくれました。
デバッグにおける工夫 – AIに状況を正確に伝える
開発中に特に意識したのが、デバッグログを多く出力させること でした。
うまく動かない時に「なんかおかしいんだけど」とか「音が鳴らない」とか抽象的にAIに伝えても、なかなかバグに辿り着けません。しかし、デバッグログを出力し、そのファイルを見ながら動作確認するように伝えると、Claude Codeは効率的にデバッグを進めてくれました。
とりわけ音楽系アプリケーションの場合、聴感上の正しさなどAIには判断できない要素が多いです。 そのため、以下のような工夫をしました：
- パラメータ値の変化をリアルタイムでログ出力
- 音声処理のバッファサイズや呼び出し頻度を記録
- MIDI入力のタイミングと内容を詳細にログ
- エラーだけでなく、正常系の処理フローも追跡可能に
このように、AIに状況を正確に伝えるための「翻訳」が必要 でした。人間なら「ノイズが混じってる」で通じることも、AIには具体的なデータで示す必要があります。これも新しい時代のスキルかもしれません。
効果的な指示の出し方
Claude Codeとのやり取りで気づいた重要なポイントがあります。
命令形より相談形が効果的
- 避けるべき：「〇〇してください」
- 推奨：「〇〇するのが良いと思うのだけど、それによる欠点はありますか？」
相談形で聞くことで、Claude Codeが潜在的な問題点を指摘してくれることがあります。 これにより、後で問題になりそうな実装を避けることができました。
CI/CDの自動設定
開発中、特に驚いたのがGitHub Actionsの設定まで自動で行ってくれたことです。
「Windows、Linux、macOSでそれぞれビルドして、成果物をアーカイブ化してリリースしてくれるワークフローを作って」と依頼したところ、約200行にも及ぶ本格的なワークフローを生成 してくれました。
- 3つのOS並列ビルド
- プラットフォーム別成果物の生成
- バージョンタグを打ったタイミングでの自動リリース
特に印象的だったのは、各プラットフォーム固有の知識が必要な部分も適切に処理していることです。これを自分でやろうとすると、各OSでのビルド環境の違いを理解し、適切なステップを組み合わせる必要があり、それだけで数日かかってしまいそうです。しかしClaude Codeは、試行錯誤を含めてもわずか30分程度で完全に動作するワークフローを生成 してくれました。
一人でOSSを作っていると、DevOpsの設定まで手が回らないことが多いのですが、「CI/CDの設定もできる？」と聞いてみることで、気の利いた開発環境を簡単に構築できました。
ドキュメント作成の効率化
地味に嬉しいのが、READMEとリリースドキュメントの作成です。構造化された文章をきちんと書く（それも英語で）というのは結構苦痛です。しかし、利用者との最初の接点はこのREADME。本来手を抜いてはいけないもの。分かってはいるものの、面倒で手が回らない罪悪感。
AIを使うと、プロジェクトの概要を的確に伝える導入文から、機能一覧、インストール手順、技術仕様まで、整理された形で作成してくれます。絵文字を使った視覚的にわかりやすい構成も、AIが提案してくれたものです。
リリースノートの更新も簡単
タグプッシュによる自動リリースは嬉しい一方で、リリース文が固定なのが玉に瑕でした。しかし、この問題も簡単に解決できました。
実際の例を見てみましょう：
リリースが完了した後に「リリースノートを更新して」とClaude Codeにお願いすると、ghコマンドを使って既存のリリースを更新してくれます。v0.0.6では以下のような充実した内容に更新されました：
- 🎵 Major New Features（主要な新機能）
- 🔧 Technical Improvements（技術的改善点）
- 🐛 Critical Bug Fixes（重要なバグ修正）
- 🎹 What’s Next（今後の展望）
コミット履歴から自動的に変更点を抽出し、カテゴリー分けして、技術的な詳細も含めた魅力的なリリースノートを作成してくれました。これにより、自動リリースの利便性と、詳細なリリースノートの両立が可能になりました。
必要とされるスキルの変化
AIコーディング時代に必要なスキルは、従来とは大きく異なります。
従来必要だったスキル：
- 実装の詳細を知っている
- コードを書ける
- デバッグができる
AIコーディング時代に必要なスキル：
- 何を作りたいか説明できる
- どんなドキュメントが必要か知っている
- うまくいっているか判断できる
- 適切な質問ができる
- AIに状況を正確に伝えられる（特にデバッグ時）
つまり、「実装方法を詳しく知っている」から「何を作りたいか、どんな技術で作るべきかを判断できる」へのシフト です。
具体例で言うと：
- 従来：「JUCEのAudioProcessorクラスを継承して、processBlockメソッドでバッファを処理して…」と実装の詳細を理解する必要があった
- 現在：技術選定（容易に実装でき、マルチプラットフォーム対応のJUCE）と要求仕様（エンベロープは視覚的にわかりやすく… など）の決定に注力
より手前の工程（設計・技術選定・アーキテクチャ）が重要になりました。 実装の詳細はAIに任せられる分、「そもそも何を作るか」「どの技術スタックを選ぶか」「どういう設計にするか」という上流の判断が成功を左右するはずです。
実際、YMulator-Synthでの技術選定では、AIが扱いやすいかどうかも重要な判断基準としました：
- JUCEを選んだ理由：容易に実装でき、マルチプラットフォーム対応、そして メジャーなソリューションなのでClaude Codeがアクセスできる情報が豊富
- ymfmを選んだ理由：正確なYM2151エミュレーション
- CMakeを選んだ理由：モダンで広く使われているビルドシステム
AIコーディング時代の新しい技術選定基準として「AIが知識を持っているメジャーな技術を選ぶ」ことは重要と思います。マイナーなライブラリやフレームワークだと、AIが適切なコードを生成できない可能性があるからです。
これは興味深い変化です。従来は：
- 個人開発：マイナーだが優れた技術を選んでも問題ない（自分が理解していれば良い）
- チーム開発：メジャーで情報が豊富な技術を選ぶ（チームメンバーが学習しやすい）
と思っていました。しかしAIコーディング時代では、個人開発でもAIを「チームメンバー」として考える必要がありそうです。つまり、個人プロジェクトでも、AIが理解できる技術スタックを選ぶという、チーム開発的な技術選定が少なくとも開発スピードの点では重要になります。
ある意味で、Claude Codeという「経験豊富だが、メジャーな技術しか知らない開発者」とペアプログラミングをしているようなものなのかもしれません。
その他の工夫
トークン消費量の管理
Maxプランでは定額制とはいえ、使用量には一定の制限があり、制限に達すると数時間待つ必要があります。そのため、トークン消費を抑える工夫は依然として必要と思います。
- ビルド時の出力を
--quietオプションで抑制（コマンドの戻り値が0でなくエラーとなった時には改めて出力を全てonにしてビルド） - 冗長な出力を生成するコマンドは事前に調整
- 必要最小限の情報だけを含むようにログを調整
ただし、キャッシュの影響もあるので、効果の程度は正確には測定できていません。
Gitによるバージョン管理の重要性
Claude Code自身が前の状態に正確に戻れるとは限らないため、こまめなコミットが必須でした。また、Gitのコミットログも読んで判断してくれるので、コンテクストを外部保存する意味でも重要です。
git log --onelineを見ると、Claude Codeが理解しやすいコミットメッセージを自動生成していることがわかります。例えば：
985aa46 LFO/Noiseセクション UI完全再編成実装
ee034ed 二色アクセントスキーム実装（視覚的整理）
c779ace エンベロープ表示の正確なYM2151動作実装
これらのコミットメッセージは、開発ステータスドキュメントと連動しており、どのPhaseのどのタスクが完了したかが一目でわかります。
他のAIツールとの併用
複数のAIツールを使い分けることで、効率を上げました：
- ChatGPT/Claude: 設計ドキュメントの作成、アーキテクチャの議論
- Claude Code: 実際の実装
JulesやCodexなども試しましたが、複数の人（AI）がコードをいじるよりも、方針などのドキュメントを別のAIに書いてもらい、その文書をClaude Codeに読み込ませてその妥当性を判断してもらい、必要に応じて実装、という流れが安定していました。
まとめ
Claude Codeを使った開発は楽しいです。写経や置換といった「実装のつまらないこと」から解放されることと、成果がすぐに見えて先に進める ことが大きな理由だと思います。
土日の限られた時間と平日夜だけで、通常なら半年以上かかるプロジェクトを2〜3週間でリリースまで持っていくことができました。「何を作りたいか」「どういう技術を使うべきか」「うまくいっているかを判断できるか」、この力があれば、一人プロジェクトでも相当いろいろできそう 、と感じました。
OSSエコシステムへの影響
サンプルコードを参照させるとどんどん実装を進めてしまう力を見ると、少し複雑な気持ちになります。OSSはAIへの養分としてしか見られなくなるのでは、という危惧もあります。
AIで大規模コードベースをマネージできるのであれば、企業は彼らのコードをわざわざオープンソース化したり、オープンソースプロジェクトに企業が参画するモチベーションはなくなりそう（少なくとも、減りそう）、とも思います…。
AIコーディングを始める際のアドバイス
AIコーディングを始める際のアドバイスとして：
- 小さなPoCから始める（今回もYMFMのサンプルコードという小さな成功体験から始めました）
- 設計ドキュメントはAIと一緒に作る（完璧な設計書を自分で書く必要はなし）
- CLAUDE.mdは都度更新（なんか毎回同じ指示出してるなぁと感じたら、更新してもらう）
- 失敗を恐れない（AIなら「実装し直し」のコストが低い）
特に強調したいのは、すべてを自分でできる必要はない ということです。設計ドキュメントもCLAUDE.mdも、AIに書いてもらえます。必要なのは「何が必要か」を知っていることだけ です。
YMulator-SynthのコードはGitHubで公開していますので、興味のある方はコミット履歴も含めてご覧ください。AIがどのように開発を進めたかがよくわかると思います。
プロジェクトは現在も開発を続けており、今後はYM2608（OPNA）サポートやS98エクスポート機能など、さらなる機能拡張を予定しています。Claude Codeと共に、どこまで一人プロジェクトを拡張できるか、楽しみながら挑戦を続けていきます。
AIコーディングツールは、まだ発展途上ですが、確実に開発の在り方を変えつつあります。現在の価格設定がいつまで続くかは分かりませんが、今のうちに使い倒して、新しい開発スタイルを確立したいと思います。
コメント