FUNCTION SPEC A–D

機能詳細 A〜D

全体図の4ブロックそれぞれの詳しい仕様。全体図の記号から該当セクションに飛べます。

往来Webサイト制作スキーム／機能詳細ページ

A正本（台帳） B出力 C公開 D運用 Q品質の担保

台帳（正本）＝JSON 2枚＋コンテンツ台帳md

「唯一の正本」を人間もAIも共有する

コンテンツ台帳（md）: 実績・ニュース以外の固定ページ本文の正本。構築時の素材台帳から昇格し、公開後も文言を変えるときは必ずmdを先に直してからAIがHTMLへ反映する（2026年7月確立）
ファイル: [案件名]-works-ledger.json（実績）／[案件名]-news-ledger.json（ニュース）
置き場所: ~/inhouse-bot/ 配下に集約（案件横断で1箇所に）
実績台帳のキー: no・title・client・date・tags・link・agency 等（案件ごとに決める）
ニュース台帳のキー: no・date（YYYY.MM）・category（PRESS/TOPICS/WORKS/MEDIA固定）・text・link・show・work_no（実績への紐付け。WORKSカテゴリなら実績タイトルに自動追従）

noの規約：連番・再利用禁止。実績台帳は W001〜、ニュースは N001〜、Featured実績は F01〜 などプレフィックスで分ける

日付の書き方：ニュース台帳は YYYY.MM が基本で、YYYY（年のみ）や空文字（日付非表示）も許容。実績台帳のdateは「2023〜継続中」のような自由表記でよい

構造を変えるとき：ゼロから設計しない。往来版（ourai-works-ledger.json）をコピーして流用が原則。変える場合は先にCodex設計レビューを通す

出力面＝同期スクリプトが4種を自動生成

マーカー方式で「触っていい場所」と「触ってはいけない場所」を分離

サイト本体HTML — 実績一覧・ニュース一覧。 のマーカー間だけを機械が書き換える。マーカー外の手書きHTML（ヘッダー・フッター・デザイン）は同期の影響を受けない
works.md（AIO用）— 台帳全件を機械可読なMarkdownで並べる。AIクローラー向けの一次情報
社内確認面（カード・台帳ビュー） — 台帳の中身をブラウザで答え合わせできる管制画面。案件によっては台帳ビューもsync生成に含める
ニュース最新3件のトップ埋め込み — index.htmlの  に最新3件だけを配信

書き込みは原子的（atomic）：全ファイル分をtempに書き終わってから os.replace で一括差し替え。途中でエラーが起きても、公開ファイルは1本も壊れない

エスケープ方針：台帳由来の値は全てエスケープ。テキストは html.escape、属性値は quote=True 付き。台帳が内部データでもクォート混入でHTMLは壊せるので例外を作らない

冪等性：同じ台帳でsyncを2回実行しても出力は1バイトも変わらない。検証スクリプトが自動でチェック

※標準仕様は2号案件（トーモ版）以降のもの：1号案件（往来）のsyncには旧仕様が一部残っている（実績一覧ページの手動管理・順次書き込み・リポジトリ全ファイル配信）。新しい案件は本ページの標準仕様で作り、往来側は順次この標準に追いつかせる。

画像の扱い：旧サイトの画像はすべてローカル保存して引き継ぐ（外部参照のホットリンクはしない）。ストック素材や人物写真は権利・肖像を確認してから使い、画質が新デザインに足りないものは差し替え候補として扱う。

公開＝Cloudflare Pages（無料）

静的HTMLだから、月額ゼロ・SSL自動・CDN込み

案件ごとに Pagesプロジェクトを1つ作る（例: ourai-site）
デプロイ経路は案件ごとに違う（往来はCI経由＝git push即デプロイ、トーモはdeploy.sh手動）。決め打ちしない、案件のCLAUDE.mdに実態を書く
デプロイ対象はホワイトリスト方式（.claude/ や CLAUDE.md を本番に流さないため）
独自ドメインへの切り替えはDNSの向き先変更だけ。旧サーバーは触らず済む

Search Console／AI回答健康診断：公開後の効果測定は月次で。SEOはSearch Console、AIOはAI診断ツール（外部）で「AIが会社について何を間違えているか」を実測

運用＝Discordの依頼チャンネル

「見て」の一言で回る、自動化しない設計

チャンネル名例: 🚧ウェブ修正（1本だけ）
スタッフやオーナーが自然文で書く：「◯◯の実績追加して」「ニュースに載せて」
Webhook等の自動監視botは作らない（数社までは手動で維持費が節約分を上回るため）
オーナーがAIに「チャンネル見て」→ AIがChromeでDiscordを開いて依頼を読み、要約と「反映するとこうなる」を提示 → OKで台帳編集→同期→デプロイまでAIが代行
完成済みAsset画像は共有Dropboxの日付フォルダに置いてチャンネルに一言添える（Discord経由だと圧縮・ファイル名破損があるため）
オーナー本人の依頼は依頼＝承認なので確認省略
外出先・スマホ時はスクショ貼り付けでの持ち込みも可

受け口はDiscordに限らない：この運用スタイル（自然文で依頼→AIが要約→人が承認）は、クライアントの環境に合わせてSlackやメールでも同じように成立する。標準構成がDiscordなだけで、仕組み側の要件は「依頼が文字で残る場所」であること。

標準装備（初版に必ず組み込む）

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

デザイン標準ルール

初版は往来テンプレそのまま＋色とロゴだけ差し替えで最速で形にする。ページ構成・セクション構成も往来準拠を守る。独自デザイン提案は初版ではしない（磨きは答え合わせ後の第二段）

AIO対策 6点セット

JSON-LD構造化／llms.txt／実績網羅性宣言／FAQ「よくある誤解」／代表プロフィール（本名・ハンドル併記）／AIO用md

SEO 5段階

①キーワード戦線の設計 ②title/description配置 ③canonical・sitemap・robots ④見出し・内部リンク・受け皿ページ ⑤月次計測

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

忠実再現の原則

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

第二段デザインの体制

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

Markdownで見る／コピーする → /spec.html

← 全体図に戻る