Webブラウザで音楽を再生する。
それ自体は今さら珍しいことではありません。HTMLのaudio要素を使えば、簡単な音楽プレイヤーならすぐに実装できます。
では、その音楽をリアルタイムで解析して、3Dオブジェクトを動かしたらどうなるのか。
今回は、Three.jsとWeb Audio APIを組み合わせたオーディオビジュアライザーを作ってみました。
といっても、最初から細かく仕様を決めて設計したわけではありません。
最初のサンプル制作はCodexにほぼ丸投げ。
そこから実際の動きを確認しながら、気になる部分に軽く調整を加えた程度です。
本格的なデザイン制作というより、AIを使った技術検証とプロトタイピングに近い取り組みです。
Three.jsで音楽を「見る」
Three.jsは、Webブラウザ上で3Dグラフィックスを描画するためのJavaScriptライブラリです。
WebGLを直接扱わなくても、3Dオブジェクトの生成やアニメーション、ライティング、カメラ操作などを実装できます。
今回はそこにWeb Audio APIを組み合わせています。
音楽を再生しながら周波数成分を取得し、その値を3Dオブジェクトの動きに反映させる仕組みです。
完成した試作品では、画面中央に発光する球体、その周囲に96本のスペクトラムゲージを配置。
さらに、回転するリングや粒子、奥行き方向へ流れる光のラインを重ねています。
音楽が再生されると、中央のオブジェクトが膨張し、表面が波打ち、周囲のゲージが伸縮する。
低音の強い部分では衝撃波のようなリングが広がり、背景の光も音のエネルギーに合わせて動きます。
一般的なイコライザーのように周波数を棒グラフで表示するのではなく、音楽そのものが3D空間に干渉しているような表現を目指した構成です。
音の解析にはWeb Audio APIを使用
今回の実装では、HTMLAudioElementでMP3を再生し、Web Audio APIのAnalyserNodeで音声を解析しています。
FFT（高速フーリエ変換）のサイズは2048。
取得した1024個の周波数ビンを、次の8つの音域に分類しています。
| 音域 | 周波数範囲 |
|---|---|
| SUB | 20〜60Hz |
| BASS | 60〜120Hz |
| LOW | 120〜250Hz |
| MID | 250〜500Hz |
| PRES | 500〜2,000Hz |
| HIGH | 2,000〜4,000Hz |
| TREB | 4,000〜8,000Hz |
| AIR | 8,000〜16,000Hz |
それぞれの音域には異なる色を割り当てています。
外周に配置した96本のゲージは、8音域に12本ずつ振り分け、Three.jsのInstancedMeshで描画しています。
また、解析した数値をそのまま長さに変換しているわけではありません。
非線形変換や急激な音量変化の強調、伸びるときと縮むときで異なる応答速度を設定することで、音の動きを視覚的に強調しています。
このあたりは、単に正確な数値を表示することと、視覚的に気持ちよく動かすことの違いが表れる部分です。
キックに反応する3Dオブジェクト
今回、特に面白いと感じたのが低音への反応です。
中央には、発光する内側のコアと、ワイヤーフレームで構成した外側のコアを配置しています。
低域のエネルギーに応じて全体が膨張し、中域の成分によって外側のメッシュ表面が変形します。
さらに45〜130Hzの周波数帯から急激なエネルギーの立ち上がりを検出し、キックドラムのような音に反応する仕組みも加えています。
ただし、これはAIによる楽器認識ではありません。
低域の変化をもとに判定する簡易的な処理なので、ベースなどの音にも反応する場合があります。
検出したタイミングでは、コアの膨張や発光の強調に加えて、衝撃波リングが広がります。
さらに少し遅れて弱い二拍目を加えることで、単純な拡大縮小ではなく、鼓動のような動きを表現しています。
音楽を解析しているというよりも、音楽によってオブジェクトが生き物のように反応している感覚に近いかもしれません。
背景も音楽に連動させる
中央のスペクトラムだけではなく、背景にも音声解析の結果を反映しています。
PC表示では720本の光のライン、14本のトンネルリング、900個のパーティクルを使用しています。
光のラインは奥から手前へ移動し、音のエネルギーに応じて速度や長さ、不透明度が変化します。
中央のオブジェクトだけが動くのではなく、背景を含めた空間全体が音楽に反応する構成です。
一方、音楽を停止しても背景は完全には静止しません。
ゆっくりと動き続けることで、再生前後もひとつのビジュアルとして成立するようになっています。
スマートフォンへの対応も実装
3D表現をWebコンテンツとして扱う場合、気になるのが描画負荷です。
今回の試作品では、PCとスマートフォンで描画品質を切り替える処理も実装されています。
スマートフォンでは光のラインやパーティクルの数を減らし、ピクセル比にも上限を設けています。
さらに、約2.5秒ごとにFPSを計測し、42FPSを下回った場合には描画負荷を追加で軽減します。
もちろん、まだ改善の余地はあります。
一度下げた描画品質を自動的に回復させる処理はありませんし、ページが非表示になった際に描画を停止する仕組みも未実装です。
現時点では、あくまでプロトタイプ。
そのまま商用コンテンツに組み込むのであれば、パフォーマンスやアクセシビリティ、端末ごとの動作確認など、追加の検証が必要になります。
Codexに任せることで変わる制作の順序
今回、個人的に興味深かったのは、Three.jsそのものよりも制作の進め方でした。
通常であれば、最初に表現したいイメージを考え、必要な技術を調べ、構造を設計し、実装して、動作を確認する。
ところが今回は、その順序が少し違います。
まずCodexにサンプルを作らせる。
実際に動くものを見てから、表現を調整する。
いわば、完成形を想像してから作るのではなく、動くものを起点に完成形を探していくという進め方です。
これはAIを使った制作の面白いところだと思います。
もちろん、何も考えずにAIへ任せれば、必ず良いものができるわけではありません。
生成されたコードが何をしているのか、どのような処理が負荷になっているのか、実際のブラウザでどう動くのか。
最終的には人間が確認し、判断する必要があります。
ただ、アイデアを検証する段階で、最初からすべてのコードを書く必要がなくなったことは大きな変化です。
特に、今回のような視覚表現は、文章や静止画だけでは完成形を判断しにくいものです。
まず動かしてみる。
その結果を見て、次の方向を決める。
この試行錯誤の速度は、AIによって確実に変わってきています。
Webサイトとは別の、Web体験という可能性
Webサイトの主な役割は、情報を整理して、必要な人へ適切に届けることだと考えています。
企業サイトやサービスサイトでは、分かりやすさや使いやすさ、情報へのアクセスのしやすさが重要です。
だからといって、Webブラウザでできることが情報の表示だけに限られるわけではありません。
音楽を聴くための空間。
操作によって表情が変わる3Dオブジェクト。
映像や音に反応するインタラクティブなコンテンツ。
こうした体験は、通常のWebサイトとは別のレイヤーで考えてもよいのではないでしょうか。
今回のオーディオビジュアライザーも、その可能性を探る小さな実験のひとつです。
まとめ：まず作ってみる、という選択肢
今回の試作品は、デザインを突き詰めた完成作品ではありません。
音源も現時点では1曲固定ですし、プレイリストや外部音楽サービスとの連携もありません。
BPM解析や楽器ごとの分離なども実装していません。
それでも、Web Audio APIで取得した音声データをThree.jsの3D表現に反映させることで、音楽を視覚的に楽しむコンテンツとして、一定の形にすることができました。
そして、その出発点はCodexへのほぼ丸投げです。
以前であれば、こうした技術検証にも相応の準備や実装時間が必要でした。
今は、まず動くものを作ってから、その可能性を考えることができます。
AIが制作のすべてを解決してくれるわけではありません。でも、何かを試してみるためのハードルは、確実に下がっています。
完成度を追い込むのは、その先の話。
まずは作って、動かして、面白がってみる。
そんな制作の入り口が、以前よりずっと身近になったと感じた実験でした。
使用技術
- Three.js 0.170系
- Web Audio API
- JavaScript（ES Modules）
- HTML / CSS / SVG
- Node.js（ローカル配信用）
- OpenAI Codex（実装支援）
※本記事は試作時点の実装をもとにしています。掲載した機能や仕様は、今後の調整によって変更される場合があります。
