SiteTuneの開発ストーリー

SiteTuneは「Webサイトを音楽に変換する」という、よく考えると奇妙なサービスです。なぜこれを作ろうと思ったのか、どんな試行錯誤を経て今の形に落ち着いたのか、開発の経緯を振り返ります。

きっかけ：「サイトの個性を視覚以外で感じたい」

普段、Webサイトの「個性」は視覚的な要素（色・レイアウト・フォント）で判断されます。でも本当はそれ以前に、HTMLの構造そのものに、サイト運営者の思想が反映されているはずです。

この「構造的な個性」を、視覚以外の方法で感じてみたい — それが原点でした。聴覚なら、ロジックの違いがそのまま「音色の違い」として伝わるのではないか。そんな仮説から始まりました。

最初のバージョンでは、SoundFont（SF2）ファイルからピアノ・ギター・ベースのサンプル音を読み込み、再生する設計でした。

このアプローチには次の問題がありました：

「Web上でWebサイトを音楽化する」という小さなツールにしては、装備が重すぎました。

悩んだ末、思い切ってリアル系楽器を捨て、デジタル系シンセサウンドだけに振り切ることを決めました。理由はシンプルです：

「ピアノでサイトを表現するのは、写真を油絵で模写するようなもの。元のメディアと表現手段がズレている」と気づいた瞬間、霧が晴れました。

v2.0では、すべての楽器をWebAudio APIのオシレータ + フィルタ + エンベロープで合成するようにしました。

結果、プラグインサイズは 20MB → 362KB（97%削減）。それでいて、ジャンルがデジタル系に振り切れたことで「サンプルなしの方が逆にマッチしている」という、嬉しい誤算がありました。

サイトの構造的特徴に応じて、4つのジャンルに自動振り分けする仕組みを実装しました。

同じURLからは必ず同じジャンルになるよう、URLハッシュを決定論的乱数源として使用しました。ジャンル判定の詳細はこちら

近年「音楽生成」はほぼAIの独擅場ですが、SiteTuneはあえてAIを使っていません。理由は3つあります。

「このHTMLが、こういう音にマッピングされた」というプロセスがすべてコードとして開示できます。AIだとブラックボックスになり、説明が難しくなります。

同じURLからは必ず同じ曲。これは、ユーザー体験として極めて重要だと考えました。「あの時聴いた曲が、今は違う」となるとサービスの軸がぶれます。

AIモデルは、軽量なものでも数十MB、しっかりしたものは数GB単位。SiteTuneは362KBで完結します。WordPressプラグインとして配布できる手軽さが、この方針の副産物として手に入りました。

当初はSPA（単独のWebアプリ）として作る想定でしたが、最終的にWordPressプラグイン形式にしました。理由は次のとおりです。

結果、SiteTuneは「sitetune.net」という公式サイトと、配布可能なプラグインの2つの形を持つことになりました。

v2.0系のシンセ基盤が固まったので、次は表現の幅を広げる方向に向かう予定です。

「Webサイトを音楽にする」という試みは、技術的にもアイデア的にも変わったものでした。完成してみて思うのは、「視覚 ⇔ 聴覚の橋渡し」自体が、実はあまりやられていない領域だったということです。

SiteTuneを使ってみて「自分のサイト、こんな音だったのか」と新たな発見があれば、開発した側としては嬉しい限りです。