企業サイトの再構築は、外から見ると数ページを作り直す仕事に見える。実際には、どの技術を使うか、どこで配信するか、ドメインと各種アカウントを誰が管理するか、公開後に誰が保守するかという判断の連続である。画面設計はその一部にすぎず、長期的な費用と自由度を決めるのは前後の設計である。
本稿は、ウェブ制作の経験がない読者にも追えるように構成した。具体的な企業情報は出さず、再利用できる判断基準と移管手順に焦点を置く。
七つの工程
- 要件整理——対象、内容、言語、更新担当を確定する；
- 技術選定——静的か動的か、どこで動かすかを決める；
- 構造と内容——情報設計、文章、画像を整理する；
- 多言語化——本文だけでなくインターフェース全体を対応させる；
- 公開——検証済みの成果物を配信する；
- ドメインと届出——DNS を接続し、必要な手続きを行う；
- 引き渡し——管理権限とソースを企業側へ移す。
前半はサイトを作る工程であり、後半はそのサイトを誰が支配できるかを決める工程である。
1. 技術より先に要件を整理する
最初に四つの問いへ答える。
- 主な閲覧者は誰か。 中国大陸向けか、海外向けか、双方かによって配信経路と手続きが変わる。
- 更新頻度はどの程度か。 年に数回の更新と日々の編集では必要な仕組みが異なる。
- 何言語が必要か。 多言語化は URL、ナビゲーション、書体、画像、検索用情報まで影響する。
- 誰が保守するか。 技術担当者、外部制作会社、非技術部門では適切な編集方法が異なる。
この工程ではコードを書かない。しかし、後続するすべての技術判断の条件はここで決まる。要件を確定せずに技術を選ぶことは、推測で設計することに等しい。
2. 静的サイトと動的サイトを使い分ける
静的サイトは、事前に生成したページファイルをそのまま配信する。動的サイトは、アクセスのたびにサーバー側の処理とデータから画面を組み立てる。CMSは、その動的な仕組みに編集画面を加えたものと考えればよい。
会社概要、事業、製品、問い合わせ先を中心とする企業サイトでは、静的構成が合理的な場合が多い。
- 常時稼働するアプリケーションサーバーやデータベースを持たずに済む；
- 生成済みファイルを高速に配信できる；
- 攻撃対象となる機能が少ない；
- サイト一式を別の配信先へ移しやすい。
一方、非技術者が毎日更新する、利用者認証がある、取引を行う、複雑な権限管理が必要、といった条件では動的構成が費用に見合う。「高機能」であることと「適切」であることは同じではない。
まず更新頻度と更新者を確認する。変更が少なければ静的構成、日々の編集・アカウント・取引が必要なら CMS または専用バックエンドを検討する。
3. ページを飾る前に情報を設計する
技術構成が決まったら、次は編集作業である。
- 全ページと階層を列挙してからナビゲーションを作る；
- 重要な情報へ短い経路で到達できるようにする；
- 一つの区画に一つの役割を与える；
- 写真は公開前に適切な寸法と容量へ変換する；
- 色、書体、余白、ボタン、画像処理を共通規則として定義する。
カメラやスマートフォンの原寸画像をそのまま置くと、見た目が同じでも転送量だけが大きくなる。画像処理は仕上げではなく、性能設計の一部である。
4. 多言語化を製品構造として扱う
多言語化は初版から設計する。既定言語をルートへ置き、他言語を安定した接頭辞で分ける方法が一般的である。各ページには対応する翻訳先を持たせ、言語切替は単にトップへ戻すのではなく、現在のページに対応する版へ移動させる。
翻訳対象は本文に限らない。
- ナビゲーション、ボタン、注釈、入力エラー、検索用情報；
- 言語ごとの行長と書体；
- 文字を含む図版；
- ブラウザーと検索エンジン向けの言語情報；
- 未翻訳ページがある場合の明示的なフォールバック規則。
完成後に追加すると、URL、部品、ナビゲーションをすべて開き直すことになる。
5. 静的サイトの限界を隠さずに公開する
静的ホスティングでは、生成済みファイルを HTTPS で配信できる。CDN は各地にキャッシュを配置し、TLS 証明書は通信を暗号化する。企業案内の配信基盤としては、簡潔で扱いやすい。
ただし、HTML だけでは問い合わせを受信・保存・転送できない。静的サイトのフォームには、次のいずれかが必要である。
- 外部フォーム受信サービス——投稿を受け、指定先へ転送する；
- サーバーレス関数——送信時だけ動作する小さなバックエンドで検証と転送を行う；
- メールリンク——最も単純だが、利用者の操作負担は大きい。
送信ボタンから利用者のメールアプリを開くだけの「フォーム」は避ける。端末側にメールアプリが設定されていなければ何も起きず、サイトが受信したように見えて実際には届かない。
社外の端末から問い合わせを一件送り、最終受信先まで到達することを確認する。見た目が完成していても、メッセージが届かなければ機能としては未完成である。
6. ドメインと配信地域の境界を理解する
ドメインは人が読む住所、DNSはその住所を配信先へ向ける制御層である。レジストラはドメイン登録を管理し、ホスティング事業者はファイルを配信する。両者は別の役割であり、同じ会社である必要はない。
中国大陸のインフラから一般公開する場合、公開前に ICP 届出が必要になる。既存の届出情報は接入事業者とも関連しているため、別の大陸事業者へ移す場合は、通常、新しい事業者側で接入备案を行う。香港・マカオを含む大陸外のインフラでは大陸サーバー向けの ICP 接続手続きは使わないが、中国大陸からの通信品質は実測する必要がある。
選択基準は流行ではなく、対象読者、性能、運用費、必要な手続きである。ドメインを購入した場所と、サイトを配信する場所を混同してはならない。
届出規則、各省の必要資料、事業者の操作画面は変わる。本節は判断枠組みの記録であり、恒久的な法的助言ではない。実際の申請時には、工業情報化部の届出プラットフォームと、利用する接入事業者の最新案内を確認する。
サイト所有権を構成する四つの鍵
ページファイルを持っているだけでは、企業がサイトを管理しているとはいえない。管理権は四つの資産に分散している。
- ドメイン登録アカウント——更新、ロック解除、移管を行える；
- DNS 管理権——訪問者の接続先を変更できる；
- ホスティングアカウント——公開ファイルと設定が置かれている；
- ソースリポジトリ——再現可能な最新版を企業が保有する。
ソースは受け取れても、最初の三つが制作会社や個人のアカウントに残る例は多い。正しい引き渡しは「今後も対応する」という約束ではなく、企業所有のアカウントへ資産を移し、必要に応じて制作側へ限定権限を与えることである。
担当者や制作会社は変わる。所有者は企業アカウントのままとし、協力者をそこへ招待する。逆の構造にしない。
7. 引き渡しと移行順序
最終引き渡しには、少なくとも次を含める。
- 企業所有のレジストラアカウントとドメイン証明；
- DNS 管理権と現行レコードの控え；
- 企業所有のホスティングアカウントと請求責任者；
- 必要な場合は、企業側で照会・更新できる正確な届出情報；
- 最新ソース、ビルド手順、環境情報、素材ライセンス；
- 更新通知、セキュリティ通知、問い合わせの受信先。
配信先を移すときは、先に新環境を構築して検証する。旧環境を維持したまま DNS を切り替え、公開 URL とフォームを確認し、それから旧環境を停止する。新経路が実証されるまで、移行は戻せる状態に保つ。
よくある失敗
| 失敗 | 症状 | 改善策 |
|---|---|---|
| 最初から重い CMS を選ぶ | 費用と保守だけが増える | 更新頻度と権限から決める |
| 静的フォームに受信先がない | 送信したように見えて届かない | 受信サービスまたは関数を接続する |
| 原寸画像を置く | 初回表示が遅い | 公開前に縮小・圧縮する |
| HTTPS を設定しない | ブラウザーが警告する | 証明書を発行し HTTPS へ統一する |
| CDN が古い版を返す | 更新後も旧表示が残る | キャッシュ削除または資産版管理を行う |
| 多言語化を後付けする | URL と画面を広範囲に作り直す | 初版で言語とフォールバックを定義する |
| ドメインやホストを外部名義にする | 更新と移転を他者に依存する | 四つの鍵を企業アカウントへ移す |
| 届出資料が現況と一致しない | 接入手続きが差し戻される | 主体、ドメイン、連絡先、接入情報を照合する |
結論
企業サイトの後半工程は、画面制作よりも統治の問題である。制作ツールはページを速く作れ、配信基盤は公開を自動化できる。しかし、住所と復旧権限を誰が持つかは自動では決まらない。
最終的な受入基準は「サイトが開く」だけではない。企業だけでドメインを更新し、DNS を変更し、新しいビルドを公開し、すべてのアカウントを復旧できるか。 それが可能になって初めて、サイトは借り物の運用ではなく企業資産になる。