メンバー個人の魅力を拡張するサブドメイン活用ガイド：藤田昂平・tatsu・AtsuyuK!のポートフォリオサイト構築術

バンドの集合体と個人の独立性を両立させるウェブ戦略とは？

最初に決めるべきなのはデザインではなく、誰がどの情報に責任を持つかだ。私は公開ページを作る前に、「バンド公式」「藤田昂平」「tatsu」「AtsuyuK!」の4列を持つ一覧を作る。各ページをどこに置き、どのURLを正本とするか、そこで一件ずつ決めていく。

ライブ日程、ディスコグラフィー、物販、バンドへの問い合わせはメインドメインへ集約する。これらは.(dot)any全体として正確さを担保したい情報であり、複数の個人サイトへ複製すると更新漏れが起きやすい。ライブの開場時刻がメインサイトとメンバーページで違って見える事態は、ファンの行動をその場で止めてしまう。

4系統のURLに編集責任を刻む

URLは「バンド名のメインドメイン」「kohei.メインドメイン」「tatsu.メインドメイン」「atsuyuk.メインドメイン」の4系統に整理する。メインドメインは公式情報の中心、各サブドメインは個人の継続的な制作記録という分担だ。

• 藤田昂平：作詞作曲実績、作品クレジット、関連作品へのリンク
• tatsu：ベースプレイ動画、使用ベース、チューニング、収録記録
• AtsuyuK!：ドラムセッティング、シンバルやスネア、使用公演の資料
• メインサイト：ニュース、ライブ、ディスコグラフィー、プロフィール、グッズ

この切り分けなら、藤田昂平のページでは言葉を読む余白を広く取り、tatsuのページでは演奏動画へ素早く触れられる。AtsuyuK!のページでは配置図の判読性を優先できる。配色、タイポグラフィー、更新頻度まで揃える必要はない。それでも各フッターに運営主体、問い合わせ先、メインサイトへのリンクを置けば、公式な関係は明瞭に保てる。

要点: 同じプロフィールや出演情報を複数箇所で更新しない。情報ごとに正本URLを指定し、個人サイトからはそのURLを参照する。

サブドメインがもたらす「独立したアーティスト空間」の技術的優位性

/member形式は、バンドサイト内のプロフィール階層として扱うには分かりやすい。一方、3人がそれぞれ異なるCMS、テーマ、キャッシュ方針を使う構想では、ホスト名単位の分離が効いてくる。

サブドメインなら、仮想ホスト、TLS証明書、アクセスログ、CMSをメンバーごとに設定できる。tatsuの動画ページへキャッシュ設定を追加しても、藤田昂平の作品データベースへ直接影響しにくい。AtsuyuK!の配置図向けにテーマを更新する際も、他の2サイトを同時に止めずに検証できる。

検索上の関係はリンクと正規URLで伝える

検索エンジンが、サブドメインという形式だけを理由にページを高く評価することはない。検索可視性にはコンテンツの蓄積とクロール状況も関わるため、ドメイン構造だけで結果を断定できない。メインサイトから文脈のあるリンクを張り、各ページ固有のタイトル、正規URL、XMLサイトマップを明示する方が堅実だ。

検索管理とXMLサイトマップはホスト名ごとに分ける。サイトマップ1ファイルの一般的な上限である5万URLまたは非圧縮50MBを超える場合は、インデックスファイルで束ねる。3人の小規模なポートフォリオであれば、各サブドメインに1ファイルずつ置く構成が追跡しやすい。

証明書と保守量を先に見積もる

ワイルドカード証明書の適用範囲には注意したい。たとえば*.example.jpはkohei.example.jpを保護できるが、通常はルートのexample.jpや、さらに下のmedia.kohei.example.jpまで含まない。証明書を発行する前に、実際に使うホスト名を一覧化する。

注意: 3人分のCMS、証明書、バックアップ、更新権限を別々に保守できない場合、脆弱性対応の遅れが表現上の利点を上回る。担当と更新手順を確保できない段階では、単一CMSのマルチサイト構成も比較対象にする。

藤田昂平・tatsu・AtsuyuK!の個性を支えるサーバーディレクトリ設計

サブドメインを作っただけでは、環境は分離されない。サーバー上で同じ公開ディレクトリや実行権限を共有していれば、ひとつの誤操作が全サイトへ届く。境界はファイルシステムから作る。

基本形として、各ホスト名に専用のドキュメントルートを割り当てる。

• /srv/www/band/public
• /srv/www/kohei/public
• /srv/www/tatsu/public
• /srv/www/atsuyuk/public

バックアップとログは公開ディレクトリの外側へ置き、仮想ホスト設定でホスト名と公開先を一対一に対応させる。ブラウザーからログやバックアップへ直接到達できない構造にしておくと、運用時の判断も単純になる。

DNSからHTTPSまで順番に通す

AレコードはIPv4アドレス、AAAAレコードはIPv6アドレス、CNAMEは別のホスト名を参照する。同じサーバーへ集約するなら、各サブドメインのAまたはAAAAレコードを共通IPへ向けられる。配信基盤を分けるなら、CNAMEで個別のホスト名へ接続する方法がある。

CNAMEを設定した名前には、原則として他種のDNSレコードを併置しない。DNSの概念と階層構造を確認する際は、ドメインネームシステムの概念と構造に関する技術仕様が基礎資料になる。

1. 現在のTTLを確認する。
2. TTLが3600秒なら、切り替えの少なくとも3600秒以上前に300秒へ変更する。
3. 権威DNSの応答を確認する。
4. 外部回線から名前解決を試す。
5. HTTPからHTTPSへの転送を確認する。
6. 証明書のホスト名がアクセス先と一致するか調べる。

ライブ直後の負荷を時間軸で見る

アクセス監視は終演30分前から終演後90分前後までをひとつの窓とする。5xx応答、オリジンサーバーのCPUとメモリー、画像転送量、応答時間を同じ時刻軸へ記録すれば、どこが詰まったかを追いやすい。

とくに動画本体と静的画像は、CMSのアプリケーション処理から切り離したい。動画を自動再生させず、最初は静止画を表示し、閲覧者の操作後に読み込む。終演直後の集中時にも、プロフィールと動画一覧の入口を先に届けられる。

音楽的ルーツを視覚化するポートフォリオサイトの構築プロセス

器が分かれたら、次は中身の構造を決める。ここで3サイトを同じCMSの色違いにすると、分離した意味が薄れる。藤田昂平の作品クレジット、tatsuのベース動画、AtsuyuK!のドラム配置図を、3つのホスト名と3つのデータ構造へ落とし込む。

見た目より先にコンテンツ型を作る

藤田昂平側の実績レコードには、作品名、担当、公開日、クレジット、関連リンクを持たせる。長い紹介文だけに情報を埋め込まず、担当や公開日を独立項目にすると、ディスコグラフィーとの照合や並べ替えがしやすい。

tatsu側の演奏動画レコードでは、楽曲名、使用ベース、チューニング、動画URL、収録日を管理する。映像を見た人が「どのベースを使ったのか」という興味から、同条件の演奏へ移れる設計が合う。

AtsuyuK!側には、キット構成、シンバル、スネア、配置図、使用公演を持つセッティングレコードを用意する。配置図を単独画像として置くだけでは、後から公演との関係を探しにくい。使用公演をデータとして結べば、ライブの記憶と機材の選択が同じページでつながる。

CMSの境界を秘密情報まで分ける

1. 3つの環境へCMSを個別に配置する。
2. データベース名、実行ユーザー、秘密情報を分離する。
3. アップロード領域を各サイト専用にする。
4. 本番、検証、バックアップの3領域を区別する。
5. 本番の設定ファイルとアップロードディレクトリは、ウェブサーバーの実行ユーザーだけが書き込める権限に絞る。

バックアップでは、データベースとアップロードファイルを同じ復元単位として扱う。取得の節目は公開直前、CMS更新直前、テーマ変更直前だ。保存しただけで終えず、別ディレクトリへ展開し、URLと画像参照が戻るところまで確かめる。

公開前に壊れやすい画面を踏む

DNS公開前は、仮ホスト名またはローカルのhosts設定を使い、トップ、個別作品、404、問い合わせ、OG画像、スマートフォン表示を確認する。hostsの設定行は試験後に削除し、実際のDNS応答でも再試験する。

コツ: 共通ヘッダーでは「.(dot)any」の表記を小さく保ち、個人サイトの主題を奪わない。ページ末尾にはメインサイトのライブ日程へ戻る導線を固定する。

公開判定では、3つのサブドメインについてA、AAAA、CNAMEのどれを使ったかを記録する。ドキュメントルート、証明書、CMSの管理者、バックアップ先も同じ表へ残す。障害時に「誰のサイトが、どこへ向いているか」を探す時間が減る。

ライブハウスの熱狂から個人の世界へ繋がる瞬間

ホスティング設計の成果は、管理画面の中では完結しない。終演後のアクセス窓を境に、薄暗い物販卓のQRから個人サブドメインへ入り、ライブ日程へ戻る導線までを一続きの体験として扱う。

短いURLと一度だけの転送

物販卓のカードや会場掲示には、短いサブドメインとQRコードを併記する。印刷物のリンク先には後から変更できる短い転送URLを使い、転送は1回に抑える。最終到達先はHTTPSの正規URLだ。

会場での確認にはWi-Fiではなく4Gまたは5G回線を使う。QRの読み取り、DNS解決、TLS接続、ファーストビューの表示、動画再生ボタンまでを、開場前と終演直後に各1回試す。ファーストビューにはメンバー名、担当、代表コンテンツへの入口を置く。観客にサイト構造を推理させない。

たとえば、演奏中にtatsuの低音へ耳を奪われた観客がいる。物販卓のカードを読み取ると、数段階のプロフィールを経由せず、ベース動画一覧が開く。静止画の下には使用ベースとチューニングが見え、再生ボタンを押せば、数分前までステージで鳴っていた音の輪郭をもう一度たどれる。

そのページの末尾には、次回ライブと.(dot)anyのディスコグラフィーへの入口がある。個人への関心がバンド全体へ戻り、バンドのニュースから再び別のメンバーへ渡っていく。

客席照明がまだ落ちたままのフロアで、ひとりの観客がスマートフォンを胸元に寄せる。画面にはtatsuの演奏動画、手元には物販卓でもらった小さなカード。次回ライブの日付を保存すると、ステージの残響と個人のポートフォリオが、同じ一夜の記憶としてつながる。