コンテンツも、人も、反応も、同じデータの上で

中心にある考え方は、ページを完成した文章として持つのではなく、コンテンツや人の情報を項目の集合として持つことです。登録した情報は、Webページだけでなく、メール、API、分析、自動処理、AIなど別の用途にも使います。

このページでは個々の機能ではなく、それらがどのような構造でつながっているかを説明します。機能は入れ替わっても、この構造は変わりません。

1. コンテンツを「ページ」ではなく「データ」として持つ

writeWiredでは、コンテンツを項目の集合として保存します。テンプレートが入力項目を定義し、編集者はその項目を埋めてコンテンツを作ります。

製品情報や事例のように入力する項目が決まっているコンテンツは「フォーム入力（定型編集）」で作ります。記事やお知らせのようにページごとに構成が変わるものは、見出し、本文、画像などのブロックを積み上げる「ブロック入力」で作ります。この2つはページごとに使い分けられ、テンプレートが器と、編集者が触れる範囲を決めます。

根拠: フォーム入力（定型編集）／ブロック入力

事例でも、この構造が選定理由として語られています。Web制作会社キノトロープは、用途別ページの雛形である「テンプレート」と、見出し・本文・写真などのセットである「コンポーネント」を細かく設計できる点を評価し、約1,700ページのBtoBサイトに採用しました。カフェチェーンの事例では、制作会社が作ったデザインをそのままに、Webの知識がないブランド担当者が季節のメニューを更新しています。

根拠: 大手制作会社／カフェチェーン

2. 一度登録した情報を、別の場所・別の形で使う

コンテンツをデータとして持つため、同じ情報を用途ごとに作り直す必要はありません。

複数ページで共通して使う内容は「組み込みコンテンツ」として1か所に持ち、修正すると参照しているすべてのページに反映されます。どのコンテンツから使われているかも同じ画面で確認できます。ヘッダーやフッターなどサイト全体の固定部品は、ページとは分けてサイト単位で持ちます。共通化せず、挿入後にページごとに変更したい部品は「プリセット」として複製して使い、挿入時点でひな形から切り離されます。共通化と複製を、道具として分けています。

根拠: 組み込みコンテンツ／サイトフォーム入力／プリセットの一覧

コンテンツの出口も選べます。リクエストのたびにページを組み立てる動的出力、HTMLファイルとして書き出す静的出力、外部のシステムからJSONのAPIで取得するヘッドレス配信は、同じコンテンツ構造の上の出力方式の違いです。方式を変えても、コンテンツと編集画面の作りは変わりません。動的か静的かはサイト単位の設定で、1つのサイトの中で混在はできません。

根拠: 動的出力／静的出力／ヘッドレス配信（API）

同じ理由で、CSVの列と入力項目が対応します。コンテンツはCSVで一括登録・更新でき、本取込の前にテスト取込で結果を確かめられます。他のコンテンツから項目を選んでコピーすることもできます。

根拠: コンテンツのCSV取込／他のコンテンツからのコピー

実際の導入でも、この考え方はWebページの更新だけに使われていません。旅行メディアではWeb用に作った特集コンテンツをメルマガ用に出力を変えることで、HTML版・テキスト版の制作時間を短縮しました。旅行会社ではページの構成要素を文字と画像だけになるまで分けることで、支店の営業担当者が自ら更新できるようにしました。

根拠: 旅行メディア／旅行会社

3. Webの反応も、人の情報も、同じところにつながる

問い合わせのデータも会員のデータも、「フォーム」という単位で保存されます。フォームを追加すれば、受け付けるデータの種類や扱う会員の種類を増やせます。

1件の問い合わせには、入力された内容だけでなく、対応状況・対応履歴・送信したメール・届いた返信・サイト内の行動が紐づきます。1人の会員には、登録情報・フォーム入力履歴・送信メール・開封とクリック・受信メール・サイト内の行動が紐づきます。届いたメールはアドレスに紐づくため、同じアドレスの問い合わせと会員の両方に同じメールが表示されます。「誰が登録されているか」と「その人が何をしたか」が、別々の仕組みに分かれません。

根拠: 入力フォームの一覧／会員フォームの一覧／問い合わせの詳細と対応履歴／会員のフォーム入力履歴／会員の受信メール

一覧の見え方は、抽出条件を持つ「クエリー」と表示項目を持つ「リスト」を組み合わせた「ビュー」で作ります。画面を作り込むのではなく、データの定義で業務ごとの一覧を作ります。登録項目だけでなく、メールの開封・クリックやサイト内の行動を条件にして対象を絞り、絞り込んだ条件を保ったまま一括メール送信へ進めます。送信対象の一覧は送信前に確認できます。

根拠: ビューの設定／クエリーの設定／問い合わせデータの一覧と検索／会員の一覧と検索／会員への一括メール送信

会員になる前の行動も、ブラウザ（クッキー）単位で記録できます。行動を条件に訪問者の集合を作る「オーディエンスフィルター」は、集計の絞り込み、会員の検索、MAシナリオの対象に使えます。登録前にそのブラウザで記録された行動は、登録後に同じクッキーの組として会員に紐づき、遡って表示されます。URLに_wwcmpidパラメータを付けるだけでキャンペーンがアクセスログに記録され、計測スクリプトを置いた外部サイトのアクセスも同じ画面で集計できます。

根拠: オーディエンスフィルターの登録／会員のアクセスログ／キャンペーン計測／外部サイト計測

事例では、100以上の管理項目を持つ1万人超の構成員管理を会員サイトに移行した公益社団法人、複数の製品サイトに分散していた会員管理を一元化した製薬会社などがあります。

根拠: 公益社団法人／製薬会社

4. 集めた情報を、送る・自動化する・見る

つながったデータは、記録するだけではなく次の処理に使います。

メールは、送った後まで残る作りです。宛先ごとの開封日時とクリックされたURLをメール単位で確認でき、返信は同じ画面の受信ボックスに届きます。送信が終わったメールの内容は変更できません。配信に失敗したアドレスはAWS SQS構成時に自動でマークされ、以後の送信対象から外れます。メールの文面はコンテンツとして作れるため、CMSの履歴や承認の仕組みがそのまま効きます。

根拠: 送信メールの登録／バウンスメール対策／メールコンテンツ

MAは、条件と処理をステップ図で組み立て、合致した会員へのアクションを自動で実行します。処理はメール送信・属性変更・リコメンド指定の3種類で、タイミングは即時・間隔・日時から選びます。シナリオには狙い・打ち手・根拠を記録する欄があり、各ステップを通過した人数を一覧で確認できます。

根拠: MAシナリオの登録／シナリオのアクション／MAシナリオの一覧

分析ダッシュボードは、フォームのフィールドを分析軸として定義するところから始まります。表示方法・分析軸・期間・絞り込みの組み合わせをビューとして保存し、束ねたダッシュボードを決めた時刻や曜日にメールで配れます。

根拠: 分析軸マスタの登録／分析ビュー（アクセスログ）／ダッシュボードの登録

Webで情報を届けるところから、その反応を記録し、対象を選び、次の働きかけを行い、その結果を見るところまでが同じ基盤の中にあります。

5. 複数のサイトと組織を、ひとつの環境で分けて運用する

writeWiredは1つの環境で複数の組織と複数のサイトを扱います。組織とサイトの関係は多対多で、ユーザーは1つの組織に所属し、部署とロールを持ちます。

権限は二層です。まず組織に対して「このサイトで何を許すか」を決め、その範囲の中でユーザーごとの権限が効きます。権限の軸は、サイト管理・ディレクトリ管理・コンテンツ管理・テンプレート管理・問い合わせ管理・顧客管理・表示フォームの7つで、それぞれに許可・閲覧範囲・編集の型を独立に割り当てます。閲覧範囲は「自分のみ」「所属部署」「所属部署以下」「指定部署」「すべて」のように部署の階層で切れるため、地域や部門ごとに見える範囲を分けた運用がそのまま組めます。ユーザーと権限はCSVでも出力・取込でき、テストモードで確かめてから流せます。

根拠: 組織のサイト割り当て／組織の権限設定／コンテンツ管理権限／サイト管理権限／顧客管理権限／ユーザーのCSV入出力

サイトの中はディレクトリの階層で構成され、ディレクトリのURLとタイトルが配下のコンテンツのアドレスの土台になります。コンテンツはディレクトリの下に置かれ、ディレクトリ単位でコピー、移動、一括操作ができます。

根拠: ディレクトリの設定／ディレクトリ一覧／ディレクトリのコピー／チェックしたディレクトリの一括操作

管理画面を使うユーザーと、公開サイトの会員は別のモデルです。会員は3章の「フォーム」の側にいます。

6. 公開を止めずに、複数人で運用する

公開中のコンテンツは、そのまま書き換えずに作業用の複製を編集し、適用日時を指定して差し替えを予約できます。適用までの間、公開側は元の内容のまま表示され続けます。公開前の内容は、有効期限やパスワード付きの外部確認URLを発行して、管理画面に入れない人にも確認してもらえます。

コンテンツの状態（制作中・確認依頼・確認中・掲載可）の変遷は自動で履歴に残り、内容そのものはメモ付きの版として手動で残し、過去の版に戻せます。状態の変更を誰がいつ行ったかが残ることが基本で、多段階の承認ルートもロールを使って構成できます。

根拠: 公開中コンテンツの編集（作業用保管）／外部確認URL／ステータス変更履歴／コンテンツ変更履歴／承認フローの設定／ロールの設定

こうした仕組みは、コンテンツを作る機能とは別に、公開中のサイトを継続して運用するための層として存在します。

7. すでにあるシステムとつなぎ、必要な部分だけを足す

writeWiredの中だけですべてを完結させる必要はありません。

データの出入り口はCSVとAPIの二本立てです。コンテンツ、問い合わせ、会員のデータはCSVで入出力でき、出力するデータと期間・形式を設定として登録すれば日次バッチで自動実行され、複数の対象をzipに束ねられます。定義済みの対象にない抽出は、SQLを直接書いて出力できます。取込・出力の状態、成功と失敗の行数、誰が流したかは、バッチ一覧に残ります。

根拠: 問い合わせ・会員データのCSV入出力／データエクスポート設定の登録／カスタムSQLの出力設定／ヘッドレス配信（API）／バッチ一覧

導入事例では、標準機能に基幹システムとの連携やAddon開発を組み合わせた構成が繰り返し使われています。基幹データの定期取り込み、注文や申請の承認フロー、バーコード・PDFの自動生成、他システムとの認証連携など、既存の業務に合わせて必要な部分を追加しています。旧CMSからの移行は、移行プログラムで1万ページ超を人手を介さず移した例と、手入力やCSVインポートで移した例の両方があります。

根拠: 製薬会社（基幹連携・MA）／製薬会社（バーコード・PDF生成）／CAD開発メーカー（移行プログラム）／オフィスビル管理会社（承認フロー）

AIも同じ位置づけです。登録済みのコンテンツを学習コンテンツとして指定し、文章生成（Completion）、ベクトル化による意味での検索（Embedding）、サイト上の対話（Chat）に利用できます。AIのために別のコンテンツを作るのではなく、すでに管理しているコンテンツを使います。実行の結果は履歴に残ります。

根拠: 学習コンテンツの登録／Completion（文章生成）／Embedding（ベクトル化）／Chat（チャットボット）

8. 使われ方は、サイトの種類では決まらない

writeWiredは、製薬会社の医療従事者向け会員サイト、CAD開発メーカーの販売代理店向けダウンロードサイト、出版社の会員制ECサイト、公益法人の構成員管理、マンション居住者向け会員サイト、旅行会社のツアー販売サイト、Webマガジン、カフェチェーンの店舗別サイトなどで使われてきました。

サイトの種類は異なりますが、繰り返し現れるのは、コンテンツを構造化して管理すること、複数の担当者で運用すること、会員や問い合わせと行動をつなぐこと、既存システムとデータをやり取りすることです。writeWiredは、それぞれを別々の製品として持つのではなく、同じデータと運用の上に組み合わせます。

根拠: 導入事例一覧