HTMLコンポーネントカタログ（Storybookビルド）を共有する方法

Storybookの静的ビルドは配布できる成果物になる

Storybookはbuild-storybookなどのコマンドで静的ファイルとして書き出せます。出力されるのはHTMLとJS、CSS、画像などのまとまりで、サーバーがなくてもブラウザで開けば各コンポーネントのストーリーを閲覧できます。

この静的ビルドをそのまま渡せば、開発環境を持たないデザイナーやプロダクトマネージャー、クライアントでも、実際に動くUIコンポーネントの一覧を確認できます。コードを動かさずに最新のUIをレビューしてもらえるのが利点です。

ビルド成果物は複数ファイルの集合なので、まとめて1つのURLで配信できると共有がスムーズになります。

コンポーネントカタログ共有で気をつけたい点

UIカタログには未公開のデザインや、開発中の機能が含まれることがあります。誰でもアクセスできるURLに置くと、リリース前の情報が外部に漏れるリスクがあります。閲覧範囲を制御できることが前提になります。

レビューは何度も往復するため、修正のたびに新しいURLを発行して送り直すのは煩雑です。同じURLのまま中身を差し替えられれば、レビュアーは常に最新のカタログを同じリンクで確認できます。

また、誰がいつ見たかが分かると、レビュー依頼が確認されたかの把握に役立ちます。

共有前チェックリスト

HTMLコンポーネントカタログ（Storybookビルド）を共有は、共有する中身によって確認観点が変わります。見た目、操作、個人情報、外部送信、スマホ表示のどれが重要かを先に決めてからURL化します。

チェックリスト化しておくと、毎回同じ品質で共有できます。手順が決まったら、HTML/ZIPをアップロードして共有URLを発行し、相手に確認してほしい観点と期限を添えて送ります。

• 見た目: PC/スマホ、余白、画像、フォント、折り返しを確認する
• 操作: ボタン、リンク、フォーム、遷移先を確認する
• 情報: 顧客名、社内URL、価格、未公開文言が残っていないか見る
• 共有: 認証、期限、差し替え、レビュー依頼文をセットで決める

Storybookビルドをチームへ共有する手順

具体的な共有の流れを、ギガサイト便を使う例で示します。Storybookの静的ビルドはCSS/JS/画像を含むため、出力ディレクトリをまとめてZIPにしてアップします。

1. Storybookをビルドして静的ファイル(通常はstorybook-staticなどの出力)を生成する
2. 出力ディレクトリ一式を1つのZIPにまとめる
3. トップページにZIPをドロップして共有URLを発行する
4. 閲覧範囲に応じて認証方式を選ぶ(社内なら会社ドメイン認証、限定共有ならパスワードやメール認証)
5. 発行されたサブドメインURLをチームに共有し、必要に応じてアクセスログで閲覧状況を確認する

社内・社外で認証方式を使い分ける

閲覧者が社内メンバーに限られるなら、会社ドメイン認証が便利です。その企業のメールアドレスを持つ人だけがアクセスできるため、URLの取り扱いに神経質にならずに済みます。社外のクライアントやパートナーに見せる場合は、パスワード認証やメール認証(ワンタイムコード)で相手を絞ります。

一時公開ページにはnoindexが付くため検索結果には出ませんが、noindexはアクセス制御ではありません。未公開のUIを守るには、必ず認証を併用してください。利用できる認証方式はURLのみ・パスワード・メール認証・会社ドメイン認証の4種類です。

アクセスログを使えば、レビュー依頼したメンバーがカタログを開いたかどうかを把握でき、フォローのタイミングを計れます。

レビューの往復を同じURLで回す

UIの修正とレビューは何度も往復します。Storybookを再ビルドするたびに新しいリンクを送るのではなく、同じURLのままファイルを差し替えれば、レビュアーは常に同じリンクで最新のカタログを確認できます。古いビルドを見てしまう行き違いも防げます。

カスタムスラッグでURL末尾を分かりやすい名前にしておけば、プロジェクトやブランチごとにカタログを整理しやすくなります。レビュー期間が決まっているなら公開期限を設定し、期間後は自動的に閲覧できなくする運用も有効です。

ギガサイト便は独自ドメインでの本番Webサイト運用ではなく、確認・レビュー・一時共有に向いた位置づけです。常設のコンポーネントカタログは別途ホスティングし、レビューやチーム内共有の段階で活用するのが適しています。