付録B 設計書 ​

3-1 設計書を作るで Claude Code が書き、3-2 構築するで確かめた結果を Claude Code 自身が書き足した設計書です。人の手を入れずに、そのまま載せています。 原本の Markdown は design-doc.md。

1. 前提と、MT の現状 ​

読み取りで確かめたこと（書き込みはしていない）。

前提として決めたこと

• 公開はスタティックパブリッシング（要件どおり）。動的な機能（検索・コメント・トラックバック）は使わない。
• 追加プラグインなし。使うのは標準のブロックエディタ・リッチテキストエディタ・Commercial.pack のカスタムフィールドだけ。
• 言語は日本語、serverOffset は 9（日本時間）。
• 構築先は手元の MT。 サイトの URL は http://localhost:8090/、公開パスは MT の既定の置き場 /data/file/static（§17）。公開用のドメインへは、あとで URL を変えて再構築する（§14.1）。以降の設計は「ウェブサイトの URL がサイトのルート / になる」前提で書く。
• 手元で http://localhost:8090/ が /data/file/static を配信しているか、MT がそこへ書き込めるかは構築の最初に確かめる（§14 の 0、§13 の H6）。【構築で確認】 MT と Web サーバ（nginx）は、作業をしている環境とは別のホストにあり、/data/file/static は作業環境のファイルシステムには存在しない。ファイルの有無は HTTP で確かめる。構築前はルートが 403 だったが、書き出した後は / ほか全ページが 200 で配信されたので、配信と書き込みは通っている（H6 は済み）。

2. 設計の要点（先に結論） ​

1. サイトは「ウェブサイト 1 つ + ブログ 3 つ」。 ウェブサイト（/）に固定的なもの、ブログに更新の多いもの（/news/ /press/ /magazine/）を置く。 担当ごとにブログ単位で権限を渡せるので、「広報はお知らせとプレスだけ、編集部はマガジンだけ」が組み込みのロールだけで実現できる。

2. 入れ物の割り当て

   要件	入れ物	根拠（「項目が 3 つ以上あり、毎回同じ形で入れたいか」）
   お知らせ	記事（news ブログ）	時系列に増える。項目はタイトル・日付・種類・本文だけで、カスタムフィールドは要らない
   プレスリリース	記事 + カスタムフィールド（press ブログ）	時系列。足す項目はサブタイトル・要点・写真の 3 系統で、記事の標準欄に足すだけで済む
   マガジン	記事 + カスタムフィールド + ブロックエディタ（magazine ブログ）	時系列。本文に引用・数字・Q&A などの見せ場があるが、カスタムブロックは作らず、標準のブロックと HTML ブロックに mockup と同じ HTML を入れる（§10）
   サービス（4）	コンテンツタイプ「サービス」	項目が 15 近くあり、4 件とも同じ形。一覧の並びも項目（順序）で決めたい
   物件（5）	コンテンツタイプ「物件」	項目が 14 あり同じ形。個別ページは持たず、トップとサービスに部品として出す
   メンバー（5）	コンテンツタイプ「メンバー」	項目 6 で同じ形。個別ページは持たない
   会社概要・お問い合わせ・プライバシー	ウェブページ	増えない。URL を固定したい
   サイトの設定（社名・統計・注意書き・プレスの会社概要…）	テンプレートモジュール	値は少なく、情報システムしか触らない。§7

3. 見た目は mockup の HTML をそのままテンプレートにする。 mockup/css/site.css（Tailwind 製）はそのまま使い、クラス名は変えない。

4. URL は mockup のとおり。 最後の段は原稿の slug。ディレクトリ形（末尾 /）。

5. プレスリリースの会社概要と問い合わせ先は、テンプレートが毎回自動で付ける。 広報は入力しない（付け忘れない／書き換えられない）。

6. デモの注意書きは、テンプレートの共通部品から出す。 場所は mockup と同じ。

3. サイト構成 ​

システム
└── ウェブサイト「Five United」   http://localhost:8090/       ← 情報システム（admin）が管理
    ├── ブログ「お知らせ」   /news/       ← 広報
    ├── ブログ「プレスリリース」 /press/     ← 広報
    └── ブログ「FIVE マガジン」 /magazine/  ← 編集部

ブログを分ける理由と、その代償 ​

• 理由： 権限が自然に切れる（§11）。カテゴリ（種類）がブログごとに独立し、/news/category/info/ /press/category/funding/ の形がそのまま作れる。フィードもブログ単位。
• 代償： トップページ・サイトマップ・「ほかの○○」のようにブログをまたぐ部分は、include_blogs を指定したテンプレートで組む（§9）。サイトを足すたびにトップが自動で拾うわけではない。
• 「記事 1 ブログ + カテゴリで news/press/magazine を分ける」案は採らない。URL の接頭辞がカテゴリに依存し、権限もカテゴリ単位では切れないため。

4. URL 設計（mockup のとおり） ​

アーカイブマッピングのパス（優先指定を付ける。同じ種類にマッピングを増やさない）

• 記事のベースネーム（basename）に原稿の slug を入れる。日本語タイトルからは自動生成されないので、必ず明示する。
• コンテンツデータのベースネームに原稿の slug を入れる。【構築で確認】API の項目名は identifier ではなく basename（identifier を送ると無視されて、40桁の英数字が自動で付く）。マッピングのパスはテンプレートタグ <$mt:ContentIdentifier$> で読める。スラッグ用のフィールドは要らなかった（R1 は解決）。
• 【構築で確認】 テンプレートタグの EntryPermalink ContentPermalink PagePermalink は、末尾の index.html を取って /news/office-move/ の形で返す（Data API が返す permalink は …/index.html のまま）。テンプレートの中ではこの差を気にしなくてよい。
• 月別・日別・著者別アーカイブは作らない（mockup に無い）。

5. 分類 ​

5.1 カテゴリ（記事用・ブログごと） ​

basename が URL。label が表示名。原稿の値と mockup の表示から決めた。

お知らせ（news） — 原稿の category は日本語の表示名で、URL 用の basename は mockup から補う。

プレスリリース（press） — 原稿の category が basename そのもの。

mockup/css/site.css に fu-cat-<basename> のバッジ色が入っているので、basename を変えない。

マガジン（magazine） — 原稿の category が basename そのもの。表示は英語名と日本語名の 2 段。

• 並びは上の順（mockup のカテゴリナビの順）。作成後に categories permutate で整える（list の出力を並べ替えて渡す）。
• 1 記事 = 1 カテゴリ（主カテゴリのみ）。

5.2 フォルダ・カテゴリセット ​

使わない。 ウェブページは 3 枚で、URL は /company/ のように 1 段。コンテンツタイプにもカテゴリ分類は無い。

5.3 タグ ​

マガジンだけ使う（原稿の tags）。記事の「#建築」表示用。タグ別のページは作らない（mockup に無い）。

6. 入れ物の定義 ​

6.1 記事：お知らせ（news ブログ） ​

カスタムフィールドは無し。 画像・サブタイトルも無い（mockup のお知らせ詳細に出ていない）。

6.2 記事：プレスリリース（press ブログ） ​

• 要点を「1 行 1 項目のテキストエリア」にしないのは、MT の標準モディファイアに行を分割するもの（split）が無いため。現在の原稿は全件が 3 項目で、mockup のレイアウトも 3 項目前提。
• 会社概要・問い合わせ先は記事の項目にしない。 §7 のモジュールから、記事テンプレートが毎回出す。
• メタの description はサブタイトル（mockup どおり）。

6.3 記事：マガジン（magazine ブログ） ​

• 「読了 約 N 分」は入力させず、テンプレートで本文の文字数から出す。max(3, ceil(文字数 / 500))。現在の原稿 5 本（593〜1,216 字）は全部 3 分になり、mockup の「約3分」と一致する。
• メタの description はサブタイトル。

6.4 カテゴリのカスタムフィールド（magazine のみ） ​

6.5 コンテンツタイプ「サービス」（ウェブサイトに作る） ​

• 「特長」を繰り返し構造にせず 3 組のフィールドにしたのは、原稿が全件 3 つ固定で mockup も 3 列固定のため。MT のコンテンツタイプには「小さな繰り返し」の部品が無く、別のコンテンツタイプにすると過剰になる。
• ボタンの文言（cta）は原稿にあるが、【構築で確認】mockup のどのページにも出ていない。フィールドは作り、値も入れたが、テンプレートでは出さない（R5 は解決）。
• 【構築で確認】 コンテンツフィールドの options に JSON の真偽値（"multiple": false など）を入れると、サーバが壊れた形で保存し、そのコンテンツタイプの取得・一覧・削除がすべて 500 になる。options には数値と文字列だけを入れる（required はフィールド直下なので真偽値でよい）。
• 【構築で確認】 画像フィールドは asset_image（options は min max）、「物件を見せる」は checkboxes、状態は radio_button、数値は number。画像のデータはアセット ID の配列。
• 【構築で変更】 「ほかのサービス」「物件の見出し」: FIVE STAY だけ物件の節の見出しが「泊まれる家」（ほかは「持てる家」）。フィールドを足さず、テンプレートでスラッグが stay のときだけ出し分けている。

6.6 コンテンツタイプ「物件」 ​

• 個別ページは作らない（原稿の注記どおり）。ct アーカイブテンプレートもマッピングも作らない。
• カードは「単位」「分配」の 2 つだけを出す（mockup）。分配は 想定分配率 年3.8% から接頭辞を除いて 年3.8%（想定） と出す。→ 原稿を割らず、テンプレートで replace する。うまくいかなければ、分配率を数値フィールドにして 年{n}%（想定） をテンプレートで組む（構築時に決める）。
• 建築家・竣工年・戸数は現行 mockup のどこにも出ていない。フィールドは原稿どおり作る（将来の個別ページ用）。

6.7 コンテンツタイプ「メンバー」 ​

6.8 ウェブページ（3 枚） ​

• 本文の表は、MT 標準の Markdown 変換では表にならない。書式は「リッチテキスト」にして HTML の表を入れる。
• 【構築で確認】 ページの本文の API 項目名は body（記事と同じ。text を送ると無視されて本文が空になる）。ページは 1 枚のテンプレート「ウェブページ」で出し、スラッグが company のときだけ会社概要の構成（写真・ミッション・メンバー・表・CTA）にする。お問い合わせでは注意書きの囲みを出す。
• 会社概要のページ内の「経営陣」はメンバー（§6.7）、ミッションとステートメントはサイトの設定（§7）から出す。ページ本文に重複して入れない。

6.9 カスタムフィールドを作るための権限 ​

カスタムフィールドの管理には「テンプレートの管理」権限が要る。構築は admin（システム管理者）で行うので問題ない。

7. サイトの設定値（content/site.yaml）の持ち方 ​

テンプレートモジュールで持つ。 ウェブサイトに「設定」で始まる名前のモジュールを作り、各ブログのテンプレートから mt:Include（blog_id 指定）で読む。

この形にした理由

• 設定は「情報システムがときどき触る」もの。広報・編集部の権限にテンプレートの管理は含めないので、触れない。
• 「整形済みテキスト」も検討したが、MT 9.3 の標準タグ一覧に取り出すタグが見当たらず、ブログをまたいで読めるかも不確かなので避けた。
• 構造のある値（統計の 4 つ・SNS）はモジュールの中の MTML で素直に書ける。

注意書きの出す場所（mockup から）

プレス詳細の「このリリースについてのお問い合わせ」は press_contact、「ファイブユナイテッド株式会社について」は boilerplate。

8. 画像と静的ファイル ​

画像の持ち方

• 画像フィールド（image）には 1600 幅のアセットを紐づける（content/images/*-1600.webp、原稿の image: press-funding → press-funding-1600.webp）。
• 一覧のカードで使う 800 幅、トップのヒーローで使う 2400 幅は、mockup/images/ に既にあるものを同じフォルダに上げ、テンプレートで URL の -1600 を -800 に置換して出す（replace モディファイア）。
• MT のサムネイル生成（AssetThumbnailURL）は使わない。WebP を生成できるかがサーバの画像ライブラリ次第で、確かめようがないため。
• content/images/*.webp と mockup/images/*-1600.webp が同一かは、構築時に確認する。違えば content/ を正とする（中身が正）。
• MT は画像を再保存する。 WebP が劣化しないか（サイズ・見た目）を最初の 1 枚で確かめる。劣化するなら、画像だけ人が FTP などで /images/ に置き、アセットは登録のみにする（§13）。【構築で確認】WebP は再保存されず、バイト単位で元と同一だった（cmp で確認。R3 は問題なし）。content/images/*-1600.webp と mockup/images/*-1600.webp も全 45 枚が同一。JPEG（ogp-default.jpg）は MT の仕様で再保存される。
• 【構築で確認】 アセットの URL・画像のカスタムフィールドの値は、ドメイン込みの絶対 URL（http://localhost:8090/images/…）で保存・出力される。テンプレートでは regex_replace="/^https?:\/\/[^\/]+/","" を付けて、ルートからの形（/images/…）にして出す。ドメインを変えたときに画像の参照が壊れない。
• 【構築で確認】 画像のカスタムフィールドは <$mt:PressImage$> のようにタグをそのまま使うと URL が出る（…ImageAsset ブロックは空になった）。コンテンツデータの画像フィールドは <mt:ContentField content_field="写真"><$mt:AssetURL$></mt:ContentField>。
• alt はアセットの説明に入れる（原稿の画像には alt が無いため、人物は氏名・物件は物件名、マガジンの図は本文中の説明文を使う。装飾の写真は空）。

9. テンプレート ​

9.1 作り方：テーマではなく、テンプレートを直接作る ​

• 理由：テーマの配布にはサーバへのファイル配置が要る（Data API からは入れられない）。今は配置手段が無い。
• テンプレートは mtb sites templates create/update で作り、mtb sites templates pull/push で手元のファイルと往復させる。ファイルは templates/ に置いて Git で持つ。
• テーマの適用はしない。適用するとテンプレートが全部 backup 型になり、マッピングも出力ファイル名も消えるため。
• 後から別環境に移したくなったら、mtb-migrate か export-theme で吸い出す。
• 【構築で変更】 新しいサイト（ウェブサイト・ブログ）には、eigerwand テーマの既定テンプレート（各 33 個）・サンプルのページ（「ウェブページの例」「このページについて」）・フォルダ about が自動で入り、styles.css atom.xml archives.html mt.js などを書き出す。テンプレートを作る前に、システム用のものを残して全部削除した（出力済みのファイルは MT が消さないので、先に本文を空にして公開してから削除。ファイルそのものの削除は人の作業。§13 H10）。
• 【構築で変更】 テンプレートは templates/（日本語名の .mtml）に置き、build/ のスクリプト（gen_*.py が mockup の HTML から生成、deploy.py が MT に作成・更新）で入れる。mockup と公開側を build/compare.py で突き合わせると、47 ページとも一致する（§15）。生成スクリプトを正とするので、テンプレートを直すときは gen_*.py を直して deploy.py を流す。

9.2 テンプレートモジュール（ウェブサイトに作り、ブログから読む） ​

• ブログから読むときは、ウェブサイトのモジュールを blog_id 付きで読む（子サイトからは親のモジュールが自動では見えない）。
• ナビの「現在地」（aria-current と下線）は、各テンプレートが変数（nav_current）を立ててからヘッダーを読んで切り替える。

9.3 ウェブサイト（/） ​

• ブログをまたいで最新を拾う部分（トップのプレス・お知らせ・マガジン）は、各ブログの ID を include_blogs に並べる。
• すべての一覧は件数を明示して全件にする（lastn を既定に頼らない。ブログの既定は 10 件で、すぐ欠ける）。ページ送りは作らない。

9.4 ブログ共通（news／press／magazine） ​

見た目の違い（mockup どおり）：

• 「ほかの○○」「次に読む」の選び方（同じ記事を除く新しい 3 件にするか、関連を見るか）は、mockup の並びから現在の記事を除いた新しい順の 3 件を既定にする。【構築で確認】 mockup の 5 ページ（プレス 2・マガジン 3）で確かめて、この規則で一致した。
• 【構築で確認】記事アーカイブの中で mt:Entries を使うと、既定では「その記事より古いもの」に絞られる。 関連一覧には ignore_archive_context="1" を付ける。
• 【構築で変更】 種類の絞り込みは、各ブログのテンプレートモジュール「部品：種類の絞り込み」に、カテゴリを並べた順で固定の HTML として書いた。<mt:Categories> の sort_by="user_custom"（管理画面の並び順）が効かず、ラベル順になってしまうため。カテゴリを足した・並べ替えたときは、build/gen_tpl4.py の CATS を直して deploy.py を流す（情報システムの作業。広報・編集部がカテゴリを足してもボタンには出ない。記事は種類のページに載る）。
• 【構築で変更】 マガジンの記事のタグ（#建築 など）は、MT が名前順に並べて出す（mt:EntryTags に並び順の指定が無い）。mockup は原稿の順なので、タグの並びだけが mockup と異なる（意図した差分。比較ツールは並びを無視する）。
• 【構築で確認】 ブログのテンプレートからウェブサイトのモジュールを <mt:Include module="…" blog_id="1"> で読め、モジュールの中で mt:SetVarBlock した変数は読み込み側で使える（設定のモジュールが成り立つ）。インクルードしたモジュール名が MT に存在しないと、公開が「403 Do not have permission to publish a template」で失敗する（権限の問題ではない）。

9.5 フィード ​

• フィードの記事は全件ではなく新しい 20 件とする（購読の用途のため。要件の「全件」は一覧ページの話）。
• 各一覧／詳細のヘッドに <link rel="alternate" type="application/atom+xml"> を付ける。

9.6 サイトマップ ​

/sitemap.xml（ウェブサイトの index）に、次のすべてを <url> で並べる。

• トップ、サービス一覧、サービス詳細 4、固定ページ 3
• お知らせ一覧・カテゴリ 4・記事 8
• プレス一覧・カテゴリ 6・記事 7
• マガジン一覧・カテゴリ 5・記事 5

ブログ側は include_blogs で束ねる。lastmod は記事の更新日。

9.7 <head> の中身 ​

mockup の各ページと 1 件ずつ突き合わせて確定する。

9.8 日付 ​

2026.10.14 の形：format="%Y.%m.%d"。<time datetime="2026-10-14"> の属性は %Y-%m-%d。

10. マガジンの本文（ブロックエディタ） ​

カスタムブロックは作らない。 見せ場は、ブロックエディタの標準のブロックと HTML ブロックに、mockup の本文と同じ HTML を入れて出す。 （理由：カスタムブロックは Data API で作れず、管理画面で 6 つ作る手間が大きい。HTML ブロックなら管理画面の作業が増えない。）

10.1 原稿の記法と、使うブロック ​

• 本文全体は <div class="fu-mag"> の中に出す（テンプレート側。編集部は書かない）。
• 画像の alt は説明と同じ文を入れる（mockup どおり）。人物紹介の写真は alt を氏名にし、800 幅を使う。
• 普通の写真の <figure> は、標準の画像ブロックが出す HTML が上と同じかを構築時に確かめる（違えば HTML ブロックで入れる。R2）。

10.2 取り込み（私が行う） ​

• 原稿の本文を、上の表の HTML に変換した文字列を記事の本文として入れる。::: … の囲みは HTML ブロックの 1 つに対応させ、ブロックエディタが読み戻せる形（ブロックを区切るコメントなど、MT の保存形式）で入れる。保存形式は、構築時に管理画面で 1 本作って書き出された本文を見て合わせる（R2）。
• 本文中の画像の URL は、サイトのルートからの形（/images/mag-materials-1600.webp）で書く。ドメインを変えても壊れない（§14.1）。
• 取り込んだあと、管理画面で開いてブロックが崩れていないことを確かめる（§15）。
• 【構築で確認】 5 本とも、書式 block_editor のまま、本文はブロックの区切りコメントなしの素の HTMLで保存した（API で保存・取得できる）。公開側は mockup と同じ HTML になった。管理画面のブロックエディタがこの本文をどう開くかは、こちらからは確かめられなかった（ブラウザが無い）。→ §13 H11 で人が確認する。崩れる場合は §16 R2 の代案（書式をリッチテキストにする）に切り替える。

10.3 編集部が新しく書くとき（手順） ​

道具は 3 つ。①標準のブロック（段落・見出し・画像）、②HTML ブロック、③下の見せ場の雛形（コピーして貼る）。クラス名（fu-mag-…）は変えない。変えると見た目が崩れる。

手順

1. 管理画面で FIVE マガジンを開き、[記事を作成] を押す。書式が ブロックエディタになっていることを確かめる。
2. タイトル・カテゴリ・タグ・サブタイトル・見出し写真・クレジットを埋める。URL の最後の段（ベースネーム）は、英小文字とハイフンで決める（例：new-house）。
3. 本文を書く。
   • 地の文は段落ブロック、小見出しは見出しブロック（レベル 2）。
   • 普通の写真は画像ブロックで、画像を選び、キャプションを入れる。
   • 見せ場はHTMLブロックを足し、雛形を貼って、かぎ括弧の中の文字だけ書き換える。
4. [プレビュー] で見た目を確かめる。
5. 状態を [公開] にして保存する。

見せ場の雛形（太字の部分だけ書き換える）

<!-- 質問（インタビューの聞き手） -->
<div class="fu-mag-qa"><p>【質問の文】</p></div>

<!-- 引用（大きく見せる一言） -->
<blockquote class="fu-mag-pullquote"><p>【引用の文】</p><p>【発言した人】</p></blockquote>

<!-- 数字（大きな数字と、その説明） -->
<div class="fu-mag-number"><p>【23,000人】</p><p>【数字の説明】</p></div>

<!-- 注記（記事の最後などの断り書き） -->
<div class="fu-mag-note"><p>【注記の文】</p></div>

<!-- ワイド画像（横いっぱいの写真） -->
<figure class="fu-mag-wide"><img src="【画像の URL】" alt="【説明】"><figcaption>【説明】</figcaption></figure>

<!-- 人物紹介（記事の最後） -->
<div class="fu-mag-profile"><img src="【顔写真の URL】" alt="【氏名】"><div><p>【氏名（よみ）】</p><p>【肩書きと経歴】</p></div></div>

画像の URL の取り方（ワイド画像・人物紹介）

1. 画像ブロックの画像選択と同じ操作で、画像をアップロードする（アセットとして登録される）。
2. アセットの一覧で画像を選び、[URL] をコピーする。
3. 雛形の【画像の URL】に貼る。http:// から / までのドメインの部分を消し、/ から始まる形にする（例：http://localhost:8090/magazine/assets/a.webp → /magazine/assets/a.webp）。ドメインを変えたときに壊れないため。

気をつけること

• HTML ブロックの中の文字は、< > & をそのまま書かない（< > & にする）。
• 見せ場の雛形は 1 ブロックに 1 つ。複数を 1 つの HTML ブロックにまとめない（並べ替えが難しくなる）。
• HTML ブロックを使うと、ブロックエディタ上では見た目ではなく HTML の文字が見える。見た目は [プレビュー] で確かめる。
• 雛形は、構築後に design-doc.md と別の「編集部向けの手順書」（§13 の H8）にも載せる。

10.4 【運用で確認】管理画面で確かめた結果（R2 の答え） ​

佐伯のアカウントで、実際の画面（Playwright）で確かめた。

【運用で確認】見つけて直した不具合：画像のカスタムフィールド（写真・見出し写真）の保存形式は2通りある。 API で入れた値（原稿の取り込み）は URL の文字列だが、管理画面で［画像を選択］から入れた値は <form mt:asset-id="…" class="mt-enclosure mt-enclosure-image">…</form> の HTML。構築時のテンプレートは前者だけを想定していて、管理画面から写真を入れた記事で、画像が壊れて HTML が漏れた。直し方：テンプレートモジュール「部品：画像URL（マガジン）／（プレス）／（ページ）」を作り、アセットのブロック（…ImageAsset）で取れればその URL、取れなければ生の値を、ドメインを除いて出す。マガジン・プレス・固定ページのテンプレートはこのモジュールを mt:Include で使う（replace でサイズも変えられる）。

11. ユーザーと権限 ​

11.1 ユーザー ​

• 表示名は「相沢」「佐伯」。
• 初期パスワードは構築のときに私が決め、最後にあなたにだけ伝える（会話で渡す）。ファイル（設計書・スクリプト・メモ・Git）には残さない。コマンドには環境変数経由で渡し、シェルの履歴に残らない形にする。
• 初回ログイン後にパスワードを変えてもらう（H1）。

11.2 ロール（組み込みの範囲で足りる） ​

• 広報と編集部は、担当以外のブログには何も与えない（ウェブサイト・他のブログにはロールを付けない）。サービス・物件・メンバー・固定ページ・テンプレート・サイト設定は触れない。
• Editor は「カテゴリの管理」を含み、カテゴリの追加・並び替え・削除ができる。これは許す（決定）。ただし URL に出るカテゴリの basename（info funding tech など）は、変えると URL とバッジの色が変わるので、変えないことを手順書に書く（H8）。独自ロールは作らない。
• 2 人にシステム権限 sign_in_cms を付ける（付けないと管理画面に入れない）。admin は不要。

11.3 Data API の関門について ​

Data API を使うのは構築する側（admin）だけ。広報・編集部は管理画面だけで使うので、Webサービスパスワードや Data API の許可は編集者のために用意しなくてよい。 ただし一般ユーザーの Data API を後で使う予定があれば、sign_in_data_api・Web サービスパスワード・サイトの Data API 許可が要る（新しいサイトは Data API が無効で始まる）。mtb-pro 拡張が無いのでこの 2 つは管理画面の作業（§13）。

12. 原稿の取り込み ​

12.1 件数と対応 ​

12.2 注意 ​

• ファイル名の日付（2026-10-14-series-b.md）は URL に使わない。URL は front matter の slug（series-b）。ファイル名の slug 部分と食い違う原稿があるので（例：2026-04-08-atlas-2.md の slug は atlas-2、2026-08-05-academic.md は isbc-2026）、必ず front matter を読む。
• 記事の status は Publish を明示する（省くと下書きになる）。
• 日付は時刻と時差（+09:00）まで付けて送る。日付だけだと日がずれることがある。
• FIVE マガジン の本文の画像参照（mag-materials など）は、アセット（mag-materials-1600.webp）のルートからの URL（/images/mag-materials-1600.webp）に置き換える。ドメインを入れない（§14.1）。
• 本文中のメールアドレス（.example）はそのまま出す。

13. 人が管理画面でする作業（mtb でできないこと） ​

14. 構築の順序（mtb） ​

テーマを使わないので順序は次のとおり。接続先を毎回口に出して確かめる（mtb profile show → mtb sites list）。

0.  確認      プロファイル、MT の状態、`http://localhost:8090/` の配信と
              `/data/file/static` への書き込み（H6）、画像の同一性、WebP の再保存
1.  サイト    ウェブサイト（url=http://localhost:8090/、sitePath=/data/file/static）
              → 3 ブログ（url/sitePath は親からの相対）
2.  分類      カテゴリ（news 4・press 6・magazine 5）と並び替え
3.  構造      カスタムフィールド（プレス・マガジン・カテゴリ・ページ）、
              コンテンツタイプ 3 つとそのフィールド
4.  人        ユーザー作成（aizawa・saeki。パスワードは §11.1）→ sign_in_cms
              → ロールの付与（コンテンツより先に）
5.  素材      アセット（画像・SVG）のアップロード
6.  コンテンツ サービス・物件・メンバー → ページ 3 → 記事（news 8 → press 7 → magazine 5）
7.  見た目    モジュール → テンプレート（ブログ共通・ウェブサイト）→ マッピング
8.  公開      index を publish、記事は変更を伴う更新で再構築、--verify-publish
9.  確認      §15
10. 引き渡し   初期パスワードを会話で伝える（ファイルに残さない）

• 分類より先にコンテンツを作らない（URL が変わる）。ユーザー・権限もコンテンツより先（所有者がずれるため）。
• ウェブページは作成時にフォルダを指定できないが、今回はフォルダを使わないので影響なし。
• 再公開に --entry '{}' は使わない（関連が外れて URL が変わることがある）。

14.1 公開用ドメインへの切り替え（あとで行う） ​

手元（http://localhost:8090/）で組んで確かめたあと、公開用のドメインに変える。変える前提で、次のように作っておく。

切り替えの手順

1. 4 つのサイト（ウェブサイトと 3 ブログ）の url を新しいドメインに更新する。ブログの url と sitePath は親からの相対なので、親だけ変えれば済むかを確かめる。公開パスを変えるなら、ウェブサイトの sitePath も更新する。
2. 本文に旧ドメイン（http://localhost:8090）が入っている記事・ページを探して置き換える。管理画面の画像ブロックで入れた画像は絶対 URL で保存されることがあるので、必ず探す。mtb sites entries list で本文を取り、置換して update する（本文が変わるので、その記事は再構築される）。
3. 全サイトを再構築する（mtb publish entries --wait ＋ index テンプレートの publish）。
4. 公開側に旧ドメインが残っていないか確かめる（curl した HTML に localhost:8090 が無いこと）。
5. Web サーバ側の設定（H9）は MT の外で行う。

15. 確認の項目（構築後） ​

16. 未確認・リスク ​

【構築で確認】結果（2026-11-06） — 下の表は設計時の内容。構築での結果は次のとおり。

17. 決まったこと（第1版の質問への回答） ​

まだ残っていること

• 「サービス詳細」のボタン文言（cta）が mockup のどこに出るか（R5）。構築前に mockup を読んで確かめるだけで、決めてもらうことはない。
• R2 の確認（HTML ブロックが使えるか）の結果次第で、§10 の方式を変える可能性がある。その場合は先に相談する。