ポエム：AIに音楽を作らせたくてAIにツールを作らせた
はじめに：AIに音楽を作らせたかった
LLMは文章も書けるし、コードも書ける。絵だって描ける。じゃあ音楽は？
「いい感じのメロディ作って」と頼めば、楽譜っぽいものは出してくれる。コード進行の提案もしてくれる。でも、音は出ない。当たり前だけど、LLMはスピーカーを持っていない。
じゃあどうするか。
AIが理解しやすく、かつ人間が演奏可能な形式で出力させればいい。そこで思い出したのが MML（Music Macro Language） だった。レトロゲームや昔のBASICで使われていた、テキストで音楽を記述する言語だ。
CDEFGAB>C
これで「ドレミファソラシド」になる。シンプル。AIにも人間にもわかりやすい。
問題は、今どきMMLを演奏する手頃なツールがないことだ。探してみたけど、2026年にサクッとCLIで動くものが見つからない。
「じゃあ作るか」
そう思った。思ったが、体が動かない。
転職したての頃なら勢いで書き始めたかもしれない。あの頃はとにかくポートフォリオを作るのに必死だった。でも今は、Rustで音声処理？MIDIプロトコル？エラーハンドリング？日々の業務で疲れた頭には、考えるだけで腰が重くなる。
「じゃあそれもAIに作らせよう」
これが、1週間の狂気の始まりだった。
成果物はこちら
MMLで音楽を再生するRust製CLIツール。私は1行もコードを書いていない。
1. 38行のメモから始まった狂気
「サインインハ」という誤字
Claude Codeに渡したのは、こんなメモだった。
## やりたい事
簡単なサイン波をMMLでコントロールしたいです。
まずは、コマンドライン上で動くCLIアプリケーションを作成したいです。
例えばコマンド引数にMMLを入力すると、その場でサインインハによる演奏が開始されるようなものです。
「サインインハ」。誤字である。正しくは「サイン波」だ。最近疲れが取れないせいかもしれない。
でも気にしなかった。意図は伝わるだろう、と。
メモは続く。
このアプリのモチベーションとしては、手軽に思いついたメロディやアイディアをすぐに出力させたいということがあります。
思いついたメロディについては履歴として保持したいです。
履歴はコマンドで選択できるようにしたいです。
欲しい機能を日本語で書いただけ。設計図なんてない。アーキテクチャの検討もしていない。業務なら「仕様を詰めろ」と詰められるレベルだ。
そしてこう付け加えた。
## テストコードの配置場所について
Rustを使う場合は、実装や定義と同じファイルにtestコードを書くのではなく、testsディレクトリを作成してそこにtestコードを配置したいです。
これは、トークン消費量を抑えるためです。
AIのトークン消費を気にしている。セコいと言われるかもしれないが、これが2026年のプログラミングだ。
この38行のメモを渡して、私は言った。
「これ作って」
10時間後の爆速リリース
その日のタイムライン：
| 時刻 | 出来事 |
|---|---|
| 12:35 | 最初のコミット（空のREADME.md） |
| 20:11 | MMLパーサー完成 |
| 21:02 | データベース（SQLite）実装完了 |
| 21:36 | シンセサイザー実装完了 |
| 21:53 | オーディオプレイヤー実装完了 |
| 22:25 | CLIコマンド実装完了 |
| 22:42 | v0.1.0 リリース |
10時間で、MMLを再生できるCLIツールが完成した。
私が書いたコードは何行か？
0行だ。
本当に、1行も書いていない。Rustの構文すらろくに知らない。でも動いた。
しかも「動いた」だけじゃない。ちゃんとした開発プロセスが回っていた。
- 要件定義書が自動生成された
- 基本設計書が作られた
- Issue が GitHub に登録された
- Pull Request が作られ、テストが走り、マージされた
v0.1.0の時点で、テストは40件以上あった。私が勉強しながら手動でやっていたら、環境構築とライブラリ選定だけで1週間終わっていただろう。
2. AIは眠らない
買い物中も、就寝中も
翌日から、開発はさらに加速した。
私がやったのは「こういう機能も欲しい」と伝えることだけ。ループ構文が欲しい。ファイルから読み込みたい。メトロノーム機能を付けて。
そして、私は買い物に出かけた。
2時間後、帰宅してPCを開くと、PRが3つ溜まっていた。
- issue #88: MMLファイル読み取りモジュール新規作成
- issue #90, #91, #92: 相対ボリューム指定機能の実装
- issue #93: パーサーのループネスト深度管理
私がスーパーで野菜を選んでいる間、AIは黙々とRustを書いていた。
就寝中も同じだった。
寝る前に「この機能追加して」と伝えて寝る。朝起きると、実装が終わっている。テストも通っている。PRもマージされている。深夜3時にコミットが打たれている。
もちろん完璧じゃない。たまにコンテキストウィンドウの上限に達して止まることがある。「続けて」と言えば再開する。その程度の手間だ。
人間の開発者に言ったら怒られるようなことを、AIは文句も言わずに続ける。
開発メンバーにこんな指示を出したら、翌日には退職届を出されていたかもしれない。
「普段の開発」をプロンプトにした
なぜAIがここまで自律的に動けたのか。
種明かしをすると、私は最初に「開発ワークフロー」をプロンプトとして定義していた。
私が普段の開発で当たり前にやっていること。要件を整理して、設計書を書いて、テストを先に書いて、実装して、レビューして、修正して、マージする。この流れをそのままAIに教えた。
要件定義 → 基本設計 → 詳細設計 → テスト作成 → 実装 → レビュー → 修正 → マージ
特別なことは何もない。どこの現場でもやっているような、普通の開発プロセスだ。スクールで習った通りの、教科書的なフローだ。
ただ、人間がやると疲れる。レビューで指摘されると凹む。修正が続くとモチベーションが下がる。金曜の夜にはやりたくない。
AIは、このループを無限に回せる。
疲れない。凹まない。金曜の深夜でも同じテンションで動く。
私がやったのは、どこにでもある開発スタイルをAIに「コピー」しただけだ。そしたらAIは、私より速く、私より正確に、私より長時間、そのスタイルを実行し続けた。
これが一番怖かったことかもしれない。「開発ワークフロー、自分よりもAIの方がうまく回せるじゃん」と気づいてしまった瞬間だ。
自律的な改善提案
ある日、AIからこんなドキュメントが上がってきた。
# 実装ワークフローの「統合漏れ」および「スタブ残存」防止策の導入
## Problem & Context (As-Is)
1. **CLI統合の忘却**: 個別の機能が完成しても、main.rs への登録が漏れており、
バイナリとして動作しない状態でIssueがクローズされた
2. **ゾンビ・オプションの残存**: CLI引数として定義されているが、
バックエンドのロジックに反映されていない機能が「完了」扱いとなっている
AIが自分で問題を見つけて、改善提案書を書いてきた。
しかも具体的な解決策付きで。
## Solution (To-Be)
1. CLI-Backend対応マトリクス (Capability Matrix) の作成
2. PRテンプレートへの「統合テスト項目」追加
3. E2E（エンドツーエンド）テストの導入
指示していない。勝手にやった。
開発中に「これ、設計おかしくない？」と気づいて、「こうすれば良くなる」と提案してくる。私は「いいね、やって」と言うだけ。
もはや「指示待ち」のAIではない。自律的に品質を上げようとする優秀な開発者がそこにいた。
ツールの話：Claude CodeとOpenCode
ちなみに、今回のプロジェクトでは主にClaude Code（Anthropic公式のCLIツール）を使った。
ただ、途中からOpenCodeというOSSのClaude Code代替も試してみた。Claude Codeと同じようにターミナルからAIと対話しながら開発できるツールだ。
正直、どちらも十分に使える。細かい違いはあるけど、「AIにコードを書かせる」という体験としては大差ない。
重要なのはツールじゃない。AIに何を作らせたいか、そしてどう伝えるかだ。
3. 物理世界への干渉
Donner Essential L1 が鳴った日
私には1つ、どうしても欲しい機能があった。
MIDIストリーミング。
手持ちのシンセサイザー、Donner Essential L1 にMMLを送って、実際に鍵盤を鳴らしたい。ソフトウェアシンセじゃなくて、物理的な楽器で。
「MIDI出力機能を追加して。外部のMIDIデバイスにリアルタイムで送信できるようにして」
AIはmidir（RustのMIDIライブラリ）を調査し、設計書を作り、実装し、テストを書いた。
そして、このコマンドが動くようになった。
sine-mml play "CDEFGAB>C" --midi-out 0
Donner Essential L1 のスピーカーから、ドレミファソラシドが流れた。
AIが作ったツールで、AIが作った曲を、物理的なシンセサイザーに演奏させる。
このとき、なんとも言えない感慨があった。自分で1行もコードを書いていないのに、目の前で楽器が鳴っている。
Chopin 2026 - AIが夢見たノクターン
AIに「サンプル曲を作って」と頼んだら、こんなファイルが生成された。
# Chopin 2026 - "Nocturne for the Digital Age"
# If Chopin were born in the modern era...
# Melancholic beauty meets electronic pulse
T88 L8 O5
# === Intro: Lonely Notification ===
# Like a phone buzzing at 3am
V6
E16 R16 E16 R8. R4 R2
「もしショパンが現代に生まれていたら」というコンセプト。イントロのコメントには「午前3時に鳴るスマホの通知のように」と書いてある。
アウトロはこうだ。
# === Outro: Fading into the Cloud ===
# Like closing an app... the melody lingers
T68 L4 O5
V10
E2 R G8 E8
V8
D2 R E8 D8
V6
C2 R D8 C8
「アプリを閉じるように…メロディは余韻を残す」
AIは音楽を「理解」しているわけではない。でも、音楽について語る言葉は知っている。その言葉を使って、人間の感情に訴える曲を構成してくる。
数字で見る1週間
最後に、この1週間の成果を数字で振り返る。
| 項目 | 数値 |
|---|---|
| 開発期間 | 7日間 |
| 私が書いたコード | 0行 |
| Rustソースコード | 6,274行 |
| テスト | 524件 |
| 設計ドキュメント | 51,853行（86ファイル） |
| GitHub Issue | 119件 |
| Pull Request | 83件 |
| リリース | v0.1.0 → v0.2.3（6回） |
6,274行のRustコードを、1行も書かずに作った。
51,853行のドキュメント。要件定義書、基本設計書、詳細設計書、テスト項目書。全部AIが書いた。
201のIssueが作られ、202のPRがマージされた。1週間で。
これが「バイブコーディング」の実力だ。
作りたいものの「バイブス」を伝えれば、AIが形にしてくれる。細かい実装は知らなくていい。意図だけ伝えればいい。
4. エンジニアの未来
職を失う覚悟（半分ガチで）
さて、ここからは少し真面目な話をしたい。
私はこの1週間で、エンジニアとしての自分の存在価値について、真剣に考えさせられた。
よく「AIと人間は共存する」と言われる。
AIが得意なことはAIに任せ、人間は人間にしかできないことをやる、と。
甘いと思う...
少なくとも「コードを書く」という作業に関しては、AIは人間を完全に置き換えられる段階に来ている。今回のプロジェクトがその証拠だ。
Rustを知らない私が、1週間で6,000行以上のRustアプリを作った。テストも524件書いた。設計書も5万行作った。全部AIがやった。
私のようなキャリア中途のエンジニアが一番危ない、と思っている。
ジュニアエンジニアは、AIと一緒に成長できる。AIをツールとして使いこなすスキルを、キャリアの最初から身につけられる。
シニアエンジニアは、設計判断やアーキテクチャの決定で生き残れる。大規模システムの全体像を把握し、トレードオフを判断する能力は、まだAIには難しい（たぶん）
でも中堅は？
30代から勉強して身につけたスキルだけでは、もう価値がない。
AIの方が速い。AIの方がバグが少ない。AIの方が疲れない。
最近、別業種への挑戦をガチで考えている
正直に告白すると...
私は最近、エンジニアを辞めて別の仕事に挑戦することをガチで考えている。
30代で異業種からプログラミングスクールを経て転職し、積み上げてきたキャリアだ。勉強して、技術書を読んで、ようやくエンジニアと呼ばれるようになった。
それが、1週間でAIに追い抜かれた気がした。
身につけたスキルが、もう差別化要因にならない。今回のプロジェクトで、それを身をもって体験してしまった。
だったら、エンジニアリング以外の道を探した方がいいのかもしれない。
そんなことを、最近ずっと考えている。
でも、悲観はしていない
でも不思議なことに、悲観はしていない。
なぜなら、プログラミングは手段であって目的じゃなかったから。
私がやりたかったのは「AIに音楽を作らせること」だった。
Rustを書くことじゃない。MIDIプロトコルを理解することでもない。
「これが欲しい」という意志。それを持っているのは、まだ人間だ。
38行のメモを書いたのは私だ。「MMLでメロディをメモしたい」「手持ちのシンセで鳴らしたい」という欲求は、私の中から出てきた。
AIはその欲求を形にしてくれた。でも欲求自体は作れない。
少なくとも今は...
おわりに：「サインインハ」でも伝わればいい
最初のメモには「サインインハ」と書いてあった。誤字だ。
でもAIはちゃんと「サイン波」だと理解して、サイン波を出力するコードを書いた。
完璧な仕様書なんていらなかった。
意図が伝われば、AIは行間を読んでくれる。曖昧な表現も、文脈から解釈してくれる。
むしろ、下手に細かく書くより、ざっくり伝えた方がうまくいくことも多い。
これが「新しいプログラミング」なのかもしれない。
コードを書くことではなく、AIに意図を伝えること。何を作りたいのか、なぜ作りたいのか、どんな体験を実現したいのか。
それを言語化できる人が、これからの「プログラマー」なのだと思う。
私は今日も、AIに話しかける。
「次はポリフォニック対応して、和音が鳴らせるようにしたい」
AIは「了解です」と言って、設計を始める。
私は、YouTubeの動画を見ている。
戻ってきたら、きっとPRが1つ増えている...
Discussion