往来Webサイト制作スキーム
実績もお知らせも「JSON台帳ひとつ」を正本に、AIが編集・同期・デプロイまで代行する。Web制作の一発納品でなく、直したいところをその日のうちに直せる状態を渡す構成。
00全体図
台帳→出力面→公開と「つくる川」を先に描き、最後にDiscordの依頼チャンネルが「運用の川」として合流する。四角は下の「構成要素」表と対応。
台帳（JSON 2枚）
実績台帳（works-ledger.json）とニュース台帳（news-ledger.json）。人間もAIもここだけを信じる。直接編集してよい唯一のファイル。列は案件ごとにキー構成を決める（no・title・client・date・tags・link等）。
出力面（4種を自動生成）
サイト本体HTML（実績一覧・ニュース一覧）／works.md（AIO用）／社内確認カード／ニュース最新3件のトップ埋め込み。マーカー間だけを機械が書き換え、マーカー外の手書きHTMLは触らない。
Cloudflare Pages（無料）
静的HTMLだから月額ゼロ、SSL自動、CDN込み。ドメインの向き先を切り替えるだけで、旧サーバーは触らず済む。
Discord「ウェブ修正チャンネル」
スタッフやオーナーが自然文で「◯◯の実績追加して」「ニュースに載せて」と書く。オーナーが「チャンネル見て」とAIに一言 → AIが要約して「反映するとこうなる」を提示 → OKで台帳に反映 → 同期・デプロイまでAIが代行。Discord自動監視botは作らない（数社までは手動で維持費が節約分を上回るため）。
01構成要素と役割分担
「判断しない仕事は機械に、判断する仕事は人間に」で線を引くのがコツ。
| 要素 | 実体 | やること |
|---|---|---|
| 台帳 | JSON 2枚 | 唯一の正本。人間もAIもここだけを信じる。直接編集してよい |
| 同期スクリプト | Python 1本 | 台帳→サイト面を機械生成。原子的書き込み（temp→replace）で途中で死んでも壊れない |
| 検証スクリプト | Python 1本 | 載せ替え時の差分ゼロ検証（既存サイトを壊していない証明）・アンカーID保持・冪等性テスト |
| サイト本体 | 静的HTML | Cloudflare Pagesで配信。マーカー間だけを機械が書き換え、マーカー外の手書きHTMLは同期の影響を受けない |
| 社内確認面 | 台帳ビュー・実績カード | 台帳の中身の答え合わせ。管制画面 |
| Discord | 依頼チャンネル | 修正依頼の受付口。Webhook等の自動連携は当面作らない |
| AI（Claude Code等） | 会話とコード | 依頼を要約→台帳編集→同期→デプロイまで代行 |
| 人間（オーナー1人） | 判断 | AIの提案に「これで」「もう少しこう」と返事するだけ |
021日/1週のリズム
人間が起きる前に機械が段取りを終えている、が理想形。サイト更新は毎日ではないので、実際は「依頼が来た日だけ動く」不定期リズム。
03つくる順番
新規案件でこのスキームを立ち上げるとき、この順で作ると各段階で「もう使える」状態を保てる。初版のデザインは「往来テンプレそのまま＋色とロゴだけ差し替え」で最速で形にして、そこから直すのが標準。ページ構成・セクション構成も往来準拠を守る（コンテンツ流し込みで構成を崩さない）。独自デザイン提案は初版ではしない（磨きは答え合わせ後の第二段）。
台帳ファイルを2本つくる
案件名を冠したJSONを新規作成。列は「no・title・client・date・tags・link」等、案件ごとにキー構成を決める。往来版の構造をコピーして流用するのが原則で、変えるなら先にCodex設計レビューを通す。ゼロから設計しない
同期スクリプトを複製する
雛形（ourai_sync.py）をコピーして [案件名]_sync.py を作り、SITEパス・台帳ファイル名・出力先HTMLファイル名を書き換える。命名・タグ・文字数ルールは案件ごとにオーナーが決める
社内確認面を追加する
台帳の中身を可視化する管制画面を追加。生成HTML・確認カード・台帳JSONをホスティングして、オーナーがWebで台帳を答え合わせできる状態に
サイト側に同期マーカーを仕込む
対象サイトのHTML内に
<!-- WORKS-SYNC:START/END -->のようなマーカーコメントを置く。同期スクリプトはその間だけを書き換え、マーカー外の手書きHTMLは触らないルールブックを整備する
対象サイトのCLAUDE.md／change-controlスキルに「台帳が正本」「マーカー間の手編集禁止」「直push許可の範囲」「デプロイコマンド（案件ごとに違う。CIか手動かを決め打ちしない）」を明記
動作確認
テスト用の1件を台帳に追加してsyncを実行 → 差分ゼロ検証（現状のマーカー間HTMLと生成HTMLが正規化後で完全一致）を通す → 社内確認面URLをオーナーに提示 → 通常運用に移行
04ハマりどころ（実体験）
1号・2号案件の構築で実際に踏んだもの。すべて対策済みで、標準仕様（機能詳細ページ）に反映してある。
「pushしたのに本番が変わらない」
デプロイ経路が案件ごとに違う。往来はgit push＝CI経由で即デプロイ、トーモはdeploy.shの手動実行が必要。さらに「本番ドメインが旧サーバーを向いたまま」という段階では、どこに何をデプロイしても実ドメインは変わらない。案件のCLAUDE.mdにデプロイ経路を明記し、決め打ちしないこと。
ナビ・共通部品の反映先が複数ある
生成ページはナビが自動反映されるが、手置きの静的ページはHTML直書きのため手動反映が必要になる。反映先の一覧を管理ドキュメント（known-issues）に持ち、ナビを変えたら全反映先を機械的に確認する。
生成物を直接編集して、次の同期で消える
works.mdやニュース一覧は台帳からの生成物であり、直接編集しても次のsyncで上書きされる。直したいときは必ず正本（台帳またはヘッダーファイル）を直す。この規約はサイト側CLAUDE.mdに明記する。
AIに実在の取引を「架空」と判定される
AI回答の検証を外部診断にかけたところ、実在の取引先やプロジェクトが「確認できない＝架空」と判定された。原因はAIに届く一次情報の不足。対策として実績一覧に網羅性宣言（「公式に公開している実績は本ページ掲載分がすべて」）を置き、llms.txt・構造化データを整備した。
同名の別人・別組織と混同される
同じ姓の人物や同名の他組織の情報がAI回答に混入する。公式サイト側で「〜とは無関係」「〜は別人」と明示的に書くことで防波堤になる。プロフィールページとllms.txtに混同防止の記述を置く。
05標準装備
新規案件の初版に必ず組み込む3セット。詳細は機能詳細ページ末尾を参照。
| セット | 内容 |
|---|---|
| デザイン標準 | 初版は往来テンプレをそのまま流用し、色とロゴだけ案件のものに差し替える（ページ構成も往来準拠）。独自デザイン提案は初版ではしない（磨きは答え合わせ後の第二段） |
| AIO対策 6点 | JSON-LD構造化／llms.txt／実績網羅性宣言／FAQ「よくある誤解」／代表プロフィール（本名・ハンドル併記）／AIO用md |
| SEO 5段階 | ①キーワード戦線の設計 ②title/description配置 ③canonical・sitemap・robots ④見出し・内部リンク・受け皿ページ ⑤月次計測 |
06必要なもの
台帳運用そのものの追加費用はゼロ。
| もの | 費用 | 用途 |
|---|---|---|
| Cloudflare Pages | 無料 | サイト配信（SSL・CDN込み） |
| GitHub | 無料 | 正本の保存・変更履歴 |
| Discord | 無料 | 修正依頼の受付チャンネル |
| Dropbox | 既存契約 | 画像素材の受け渡し（日付フォルダ制） |
| Claude Code等 | 各自の契約 | 台帳編集・同期・デプロイの実行 |
07実物を見る
このスキームで実際に公開している面。台帳を更新すると、これらが同時に更新される。
AIO＝AI Optimization。SEOが検索エンジン向けの最適化なら、AIOはAI検索・AI回答向けの最適化。上記のAI向けファイルは台帳からの生成物のため、サイト更新と同時に自動更新される。
08まとめ
この構成の中心は、高機能なCMSではなくJSONファイル2枚である。正本を1箇所に決め、そこから全ての面を機械生成することで、「直す場所はどこか」「何が最新か」を迷わなくなる。
この資料は1号案件（往来）・2号案件（トーモ）の実運用をもとにしている。細部は案件ごとの言葉と運用に合わせて変える前提で、それができるのがこの作り方の利点である。
© 2026.7.13 株式会社トーモ ／ 姉妹版：task-ops-scheme