バイブコーディングはボカロの夢を見るか？

「書けなくても大丈夫」の賞味期限

バイブコーディングが広がった結果、こういう言説が増えた。

「もうコードを書ける必要はない」
「AIに任せれば動くものが出てくる」
「プログラミングを学ぶ意味がなくなった」

半分は正しい。
Claude Codeに指示を出せば、30秒でFastAPIのエンドポイントが生えてくる。

でも、この構図、どこかで見たことがある。
私はそれをボカロの歴史に見つけた。
ボカロの歴史を正確に追うと、「書けなくても大丈夫」の賞味期限について、思っていたより解像度の高い予測ができる。

ボカロが辿った道

2007年、初音ミクが登場した。

それまで歌もの楽曲を作るには、歌える人間が必要だった。
歌い手を探し、スタジオを押さえ、ディレクションする。
楽曲制作の最終工程が、最大のボトルネックだった。

ボカロはそのボトルネックを吹き飛ばした。
歌える人間がいなくても、歌もの楽曲が完成する。

結果、何が起きたか。

ニコニコ動画にボカロ曲が溢れた。ピーク時、毎日数百曲が投稿されていた。
楽器が弾けない人も、音楽理論を知らない人も、ボカロPを名乗って曲を出した。

そこから一部がプロ化した。
米津玄師は「ハチ」名義で、Ayaseは独学の作曲者として、それぞれ現在のキャリアにつながる。

ただし、ここを単純化したくない。
wowakaさんは音楽理論を体系的に学んだというより、衝動でメロディを書いていたと本人が語っていた。
DECO*27さんも独自のルートで上り詰めた。
「音楽理論を深く学んでいた層が残った」と言い切るのは、正確ではない。

ボカロPのサバイバルを決めた要因は、メロディセンス、歌詞、動画演出、コミュニティとの相性、アルゴリズムへの乗り方を含む、相当に複合的なものだった。

線は引かれた。でも、線を引いた基準は単一ではなかった。
ここを正確に書かないと、バイブコーディングへの類推も曲がってしまう。

構造的相似：バイブコーディングとボカロ

ボカロ	バイブコーディング
ボーカル録音の自動化	コード実装の自動化
歌えなくても歌ものが作れる	コードが書けなくてもソフトが作れる
素人ボカロPの大量参入	非エンジニアのプロダクト開発参入
複合要因でサバイバル（うち理論の比重は未確定）	複合要因でサバイバル（うち読解力の比重は未確定）
「歌わせただけ」の淘汰	「書かせただけ」の淘汰（予測）

この表の最終行は、誠実に書くとこうなる。

最終工程が自動化されると、上流要素の価値が相対的に上がる。 ただし「どの上流要素が決定的か」は、後から振り返らないとわからない。

ボカロで残った要因は、音楽理論、メロディセンス、歌詞、世界観、運の複合だった。
バイブコーディングで残る要因も、同じように複合的になるはずだ。
「コードを読める人が残る」と単一要因で言い切るのは、たぶん雑だ。

では、読める力はどのくらい重要なのか。
ここで個人的な体験が効いてくる。

ハニング窓の話

予知保全プロダクトの開発中、FFT処理の前に「ハニング窓」をかけるコードがClaude Codeから出てきた。
私はハニング窓を知らなかった。
動いているからスルーした。

後日、別のデータで結果がおかしくなった。
原因は窓関数の選び方にあった。
自分のデータにはハミング窓のほうが適していた。

このエピソードを「コードを読めなかったから気づけなかった」という文脈で書こうとして、途中で手が止まった。
これは「コードを読む力」の話ではない。

scipy.signal.windows.hann(N) と書かれているのを読めても、
「このデータにはハミング窓のほうが適している」とは判断できない。
それを判断するには、窓関数のスペクトル特性を知っている必要がある。
つまり、信号処理のドメイン知識だ。

コードを100%読めていても、ドメイン知識がなければ同じ罠にハマっていた。

「コードを読む」と「ドメイン知識を持つ」は別物だ。
AI時代の希少性を語るとき、この違いは大きい。

鍛えるべきは「出力を疑える力」

ハニング窓事件から本当に学んだのはこれだ。

「自分の問題領域に対して、この出力は妥当か」と立ち止まる姿勢。

これは「コードを読む力」とも「ドメイン知識」とも違う、第三のスキルだ。
出力を鵜呑みにせず、自分の文脈に照らして疑う力。

そしてこの力を育てるには、皮肉なことに次の2つが必要になる。

• コードをある程度読めること（出力の構造を理解するため）
• 自分の問題領域の知識（妥当性を判断するため）

どちらかだけでは足りない。両方ないと、疑う対象を見誤る。
「読める力が最強」ではなく、「読める力と領域知識を組み合わせて、出力を疑える力」が強い。

最大の反論：「AIが自分でコードを読めるようになるのでは」

ここで、読者が当然抱く反論に答えておきたい。

今ここまでの議論は、暗黙のうちに「AIのコード読解・レビュー能力がこれ以上伸びない」という前提に立っている。
でも2026年時点ですでに、Claude Codeは自分の書いたコードをレビューし、テストを書き、修正を提案する。
2028〜2030年、AIが「このデータにはハミング窓が適している」まで指摘してくれるようになったら、上の議論はかなり弱まる。

それでもなお人間が読む必要がある理由を、能力の観点で2つ挙げる。

コンテキスト統合は人間に分がある

AIは与えられたコードベースの中では強い。
でも「うちの工場の過去の不良履歴」「先週の客先会議で出た要望」「3年前に退職した先輩が書いた設計メモ」のような、分散して偏在するコンテキストを統合して判断する力は、まだ人間に分がある。
バイブコーディングで書いたコードが「本当にこのプロジェクトに適しているか」の判断には、こうした暗黙知との接続が必要になる。

要件の妥当性判断は人間の仕事として残る

AIは「要件Aを満たすコード」を書く。
でも「要件Aが現場で本当に妥当か」までは判断しきれない。
要件そのものが間違っているケースは、現場では頻繁にある。
「要件を疑う」という層は、当面は人間に残る。

この2つを逆に言えば、AIが暗黙知を統合でき、要件の妥当性まで判断できるようになったとき、人間が読む必要はなくなる。
その未来は、来るかもしれない。
ただ、その未来が来る頃には、たぶん「読む」どころではない別の変化が起きている。

何を鍛えるか

不確実な未来に備えるなら、「複数の要因で効きそうなもの」に投資するのが合理的だ。
私の場合、「バイブコーディングで書かれたコードを8割説明できる」を目標にしている。
このスキルは、読む力・デバッグ・要件整合性の判断、どれにも関わる。

具体的にやっていることは4つ。

1. Claude Codeの出力を毎回読む

書かせて終わりにしない。
生成されたコードを1関数ずつ読んで、「ここで何をやっているか」を自分の言葉で説明する。

2. エラーが出たら、まず自分で仮説を立てる

「動かない、直して」と丸投げせず、「たぶんスコープの問題」のように仮説を立ててから聞く。
外れてもトレーニングになる。

3. 自分のドメインで「妥当か」を言語化する

ハニング窓事件の反省だ。
製造業なら、どの条件でどの分析手法が適切か。
自分の領域で妥当性の基準を自分の言葉で持っておく。
これはAIには代替されにくい。

4. 時代錯誤の写経を続ける

週に1時間、FastAPIのチュートリアルやPandasのドキュメントを手で写している。
AI時代にアナログに見える習慣だ。でも、これが一番コスパがいい基礎工事だと今のところ思っている。

理由はこうだ。
書いたことがあるコードは、読むときの解像度が違う。
指が覚えた構造があると、読んでいる時に「ここで変数が定義されているな」「ここでスコープが切れているな」が自然に見える。
Claude Codeの出力を読む速度と精度が、写経した範囲だけ一段上がる。

AIに書かせる前提だからこそ、読む側の身体性を仕込んでおく。
5年後にこの判断がどう評価されるかは、正直わからない。
ただ、他の多くのスキルと重なる投資なので、外れても損は小さいと踏んでいる。

まとめ

ボカロは「歌えなくても歌ものが作れる」世界を実現した。
バイブコーディングは「書けなくてもソフトが作れる」世界を実現した。

どちらも、最終工程の自動化が素人の参入を可能にし、その後に淘汰が起きた（起きる）。
ただし、淘汰を決めた要因は単一ではない。複合的だ。

「コードを読める人が残る」と単一要因で言い切るのは雑だ。
でも「読める力」がその複合要因の一つになる可能性は高い。
加えて、AIが進化しても人間が読む意味は、コンテキスト統合と要件の妥当性判断として残る。

「書けなくても大丈夫」は今は正しい。
5年後も正しいかは、誰にもわからない。
わからないからこそ、複数の要因に効く地味な投資に時間を使う。
それが、AI時代に非エンジニアとして生き延びるための、私なりの戦略だ。