00全体図

全体は3幕構成。①入口で案件をフル適用型／デザイン適用型に振り分け、②「つくる川」で初版を最速構築し、③公開後は「まわす川」の運用ループが回り続ける。色は 青緑＝AIがやる機械の仕事／暖色＝人が判断する仕事。

01構成要素と役割分担

「判断しない仕事は機械に、判断する仕事は人間に」で線を引くのがコツ。

実際は機械／人間の2分ではなく3層。「判断は要るが基準が機械的な仕事」（差分ゼロ検証・命名規則の確認など）が間にある。ここはAIが検証パスまで自走してよく、パスしてから人の承認に出す。この中間層を人間がやると遅く、AIが独断でやると事故る

021日/1週のリズム

人間が起きる前に機械が段取りを終えている、が理想形。サイト更新は毎日ではないので、実際は「依頼が来た日だけ動く」不定期リズム。

03つくる順番

新規案件でこのスキームを立ち上げるとき、この順で作ると各段階で「もう使える」状態を保てる。初版のデザインは「往来テンプレそのまま＋色とロゴだけ差し替え」で最速で形にして、そこから直すのが標準。ページ構成・セクション構成も往来準拠を守る（コンテンツ流し込みで構成を崩さない）。独自デザイン提案は初版ではしない（磨きは答え合わせ後の第二段）。

1. （リニューアルの場合）旧サイトを素材台帳に整理する

   旧サイトの全ページをクロール→素材台帳（ページ一覧表と、1ページ=1のMarkdown）に整理する。一覧表をもとに「実績紹介ページはWorks台帳に載せますか？」のように振り分けをオーナーが表1枚で答え合わせし、固定ページはこのMarkdown上で文言を改稿してから流し込む。以後このMarkdownがページ本文の正本になる

2. 台帳ファイルを2本つくる

   案件名を冠したJSONを新規作成。列は「no・title・client・date・tags・link」等、案件ごとにキー構成を決める。往来版の構造をコピーして流用するのが原則で、変えるなら先にCodex設計レビューを通す。ゼロから設計しない

3. 同期スクリプトを複製する

   雛形（ourai_sync.py）をコピーして [案件名]_sync.py を作り、SITEパス・台帳ファイル名・出力先HTMLファイル名を書き換える。命名・タグ・文字数ルールは案件ごとにオーナーが決める

4. 社内確認面を追加する

   台帳の中身を可視化する管制画面を追加。生成HTML・確認カード・台帳JSONをホスティングして、オーナーがWebで台帳を答え合わせできる状態に

5. サイト側に同期マーカーを仕込む

   対象サイトのHTML内に <!-- WORKS-SYNC:START/END --> のようなマーカーコメントを置く。同期スクリプトはその間だけを書き換え、マーカー外の手書きHTMLは触らない

6. ルールブックを整備する

   対象サイトのCLAUDE.md／change-controlスキルに「台帳が正本」「マーカー間の手編集禁止」「直push許可の範囲」「デプロイコマンド（案件ごとに違う。CIか手動かを決め打ちしない）」を明記

7. 動作確認

   テスト用の1件を台帳に追加してsyncを実行 → 差分ゼロ検証（現状のマーカー間HTMLと生成HTMLが正規化後で完全一致）を通す → 社内確認面URLをオーナーに提示 → 通常運用に移行

8. 管制室（console/）も同時に生成する（フル適用型のみ）

   運用手引きと確認面をまとめた管制室一式は、後から作るのではなく初稿の立ち上げと同時にテンプレ流用で生成する。サイト本体と管制室がそろって、はじめて初版の成果物になる

04ハマりどころ（実体験）

1号・2号案件の構築で実際に踏んだもの。すべて対策済みで、標準仕様（機能詳細ページ）に反映してある。

05標準装備

新規案件の初版に必ず組み込む3セット。詳細は機能詳細ページ末尾を参照。

導入パターンは2つある。フル適用型＝台帳・管制室込みでスキームごと構築して引き渡す（本ページの説明はこちらが基準）。デザイン適用型＝先方に既存のシステム（CMS・SSG等）と技術者がいる場合、システムは変えずデザインとCSSだけをPRで納品する（実例あり・2026年7月確立）。この型では台帳・同期スクリプト・管制室は作らず、運用は先方の既存の仕組みを継続する。注意: デザイン適用型は先方の既存システム次第のため、その精査（構成・運用規約・壊してはいけない資産の調査）から始まる。型として定型化しづらいぶん、フル適用型より工数がかかる。どちらにするかは最初の相談で技術構成をうかがって決める。

AIO対策が標準装備なのは、次のような「AIからの見られ方」の実例を踏んだため。

06必要なもの

台帳運用そのものの追加費用はゼロ。

07実物を見る

このスキームで実際に公開している面。台帳を更新すると、これらが同時に更新される。

• 実績一覧（サイト本体）
• works.md（AIO用実績一覧）
• llms.txt
• 活動記録・実績年表
• 代表プロフィール

AIO＝AI Optimization。SEOが検索エンジン向けの最適化なら、AIOはAI検索・AI回答向けの最適化。上記のAI向けファイルは台帳からの生成物のため、サイト更新と同時に自動更新される。

08品質の担保と、その先のデザイン

初版の速さと、案件ごとの顔をどちらも成立させるための2つの原則。

忠実再現の原則。テンプレを流用するとき、ブロック・ボタン・導線・カードなどの構成要素を勝手に間引かない。「この案件には要らなそう」という判断で要素を落とすのは、独自デザイン提案と同じ逸脱として扱う。初版で変えてよいのは、色・ロゴ／固有名詞やサービス名などの中身の文言（転記ベース）／案件の業態と明らかに矛盾する文言の最小限の置き換え、の3つだけ。要素を丸ごと落としたい・構成を変えたい場合は、実装前にオーナーへ確認する。

第二段デザインの体制。初版はテンプレの忠実再現で最速公開し、そこから先の「案件の顔づくり」はデザイナーがFigmaで磨き込み、AIが実装する二段構えにする。初版公開はゴールではなく、答え合わせをしながら育てていく前提のスタート地点として扱う。

09まとめ

AIはすでに、SaaSやCMSの役割をもっと柔軟にこなす——それがこの新時代のWeb運用である。CMSが不要な理由は、AIが自然言語を汲み取ってすべてを生成するからだ。構成・デザイン・実装・コピー・文章・演出——従来は管理画面と専門職の分業で回していた領域を、オーナーの言葉から直接つくる。だから「更新のための仕組み」を別に持つ必要がない。そして一度自社のAI（Claude推奨）にこのスキームを導入すれば、以後はクライアント自身が自然言語でサイトを更新できる。

推奨AI構成（2026年7月時点の実運用仕様）:司令塔にOpus 4.7（リーズニング中設定）、実装はSonnetのサブエージェントに委譲、設計と設計レビューにはCodexをサブエージェント的に併用する多モデル分担。1つのモデルに全部やらせず、判断・実装・検証を分けることで品質を担保している。

この構成の中心は、高機能なCMSではなくJSONファイル2枚である。正本を1箇所に決め、そこから全ての面を機械生成することで、「直す場所はどこか」「何が最新か」を迷わなくなる。

この資料は1号案件（往来）・2号案件（トーモ）の実運用をもとにしている。細部は案件ごとの言葉と運用に合わせて変える前提で、それができるのがこの作り方の利点である。