← ADR 一覧へ残タスク一覧へ関連RQ:RQ-097 へ 最終更新: 2026/06/22 20:19
commonid: adr-0128type: adrstatus: accepted
pagemode: Standardkruchten: Existence/Propertyscope: platformimplementation_status: Not Startedproposed_at: 2026-06-08 18:37approved_at: 2026-06-08 20:51（審査 46/50 PASS → PRdeciders: [email protected] (単独)business: meta
型付き辺: 出 6 / 入 0
置換する: ADR-0079 細分化する: ADR-0114 関連: ADR-0055 ADR-0117 ADR-0123 ADR-0126全体は INDEX →

ADR-0128: コーポレート社内サイトの入口（landing）IA と概要ページ Tier 規約を定義する

  • Status: Accepted
  • Mode: Standard
  • Kruchten Type: Existence/Property
  • Scope: platform
  • Implementation Status: Not Started
  • 起案者: [email protected]
  • 起案日時 (JST): 2026-06-08 18:37
  • 承認日時 (JST): 2026-06-08 20:51（審査 46/50 PASS → PR #1574 merge により受理）
  • Deciders: [email protected] (単独)

コンテキスト

§1.1 背景

docs サイトは「管理会計ERP 単体ドキュメント」から「BizLinkPartners コーポレート社内サイト（事業軸 Corp / MAS / DRP）」へ再ポジショニングされた。トップ landing docs/SUMMARY.md を 865 行 → 59 行に薄化し、ERP 製品ドキュメント本文を docs/architecture/ 配下へ退避。サイドバーに事業軸フィルタ Corp/MAS/DRP を導入した。

§1.2 現状 (As-Is)

  • 各軸の概要/入口ページが非対称: MAS は architecture/product_overview.md（Tier A だが H1「bizlp-gas-accounting 完成形プロダクト全体像」に MAS の明示がなく、状態 Development）、DRP は _internal/03_decisions/decision_pipeline/README.md（Tier A・Production・模範例）。一方 Corp（全社）には入口・概要ページが存在しない（空白）。3 軸のうち area landing が揃うのは 2/3。
  • SUMMARY.md は ADR-0114 で明示的に Tier C（ファクトボックス適用外）と列挙されているが、再ポジショニング後は「全社の顔 = landing」の役割を担い始めた。
  • 先行決定 ADR-0079「docs を engineering/corporate に分割し Cloudflare Pages サイトを分離」は Status: Proposed / Implementation: Not Started のまま未実装で、実際に採られた方向（単一サイト + Corp/MAS/DRP 軸フィルタ）と矛盾したまま残置している。

§1.3 課題

  • Corp 軸に入口・概要ページが存在せず（空白）、新規読者が全社像を把握できない。
  • ADR-0114 の Tier A 判定基準は「単一システム/製品全体 landing かつ対応コードあり」で、コードを持たないコーポレートポータルは現基準で Tier A 不適格。Tier A 必須ファクトボックス（状態/コード/基盤決定/変更履歴）はすべてシステム前提であり、ポータルでは形骸化する。

§1.4 制約・要件

  • ADR-0114 の核心（§1§2 形式・Tier A 必須 7 ページ・Tier B 禁止条項・上限 10 ページ）は温存する。
  • scripts/tier-a-header-lint.mjs の TIER_A 配列・必須 4 項目（REQUIRED_LABELS）は変更しない（既存 Tier A 7 ページの検査回帰を防ぐ）。
  • 事業軸の各 doc への割当方式（現状は nav グループ名 prefix 派生）、および顧客向けプロダクト（電帳法/証憑管理 SaaS = JTBD-012）の扱いは本 ADR の射程外（RQ-097 の粒度基準で別 spike / 別 ADR）。

§1.5 目標 (To-Be)

サイトの入口を 2 階層の landing 構造（L0 全社ポータル → L1 各軸入口） として規約化し、ADR-0114 を Refine（Supersede しない）する。Non-Goals: 事業軸の各 doc への割当方式変更、顧客向けプロダクトドキュメントの軸/別サイト化判断、Corp L1 入口の本文執筆そのもの。

決定

コーポレート社内サイトの入口を 2 階層の landing 構造（L0 全社ポータル → L1 各軸入口） として規約化し、新類型「Tier P（ポータル landing）」を新設する。L0 = 全社ポータル（SUMMARY.md・Tier P）、L1 = 各軸入口でコードを持つ軸（MAS / DRP）は Tier A、持たない軸（Corp）は Tier P。MAS は product_overview.md を MAS 明示に retitle、DRP は現状維持、Corp は Tier P 入口を新設する決定のみ本 ADR の射程とし、本文執筆は DOC-OPS バックログの別タスクへ分離。ADR-0114 を Refine、ADR-0079 を Supersede する。

判断基準 (Decision Drivers)

3.1 評価軸

#軸重要度 (係数)案件特有の解釈
1#usable[Must] (×2.0)新規読者が L0（全社）→ L1（各軸）の入口だけで全体像と現在地を把握できるか。Corp 空白の解消度。
2#suitable[Must] (×2.0)コードを持たない landing にシステム前提のファクトボックスを無理に当てない設計か。
3#operable[High] (×1.0)tier-a-header-lint の必須 4 項目アサート（システム前提）を破綻させず新類型を扱えるか。CI が誤 FAIL しないか。
4#maintainable[High] (×1.0)規約改訂の同期コスト。writing-guide / tier-a-header-lint の二重管理を増やさないか。ADR-0114 の「核心 vs 実施細則」2 層を壊さないか。
5#flexible[Medium] (×0.5)4 つ目の事業軸（例: 顧客向けプロダクト）が増えたとき、L1 を 1 つ足すだけで規約が追従するか。

K.O. criterion: Must 軸（#usable / #suitable）の score < 3 は不採用。

3.2 評価軸 × 案スコア表

軸係数採択案 (Tier P 新設 + L0/L1)案 A (Tier C 維持)案 C (Tier A 拡張)案 (一律 Tier A)
#usable [Must]×2.05244
#suitable [Must]×2.05321
#operable [High]×1.05522
#maintainable [High]×1.04533
#flexible [Medium]×0.55233
加重和 (正規化)0.9570.6430.5860.529
K.O. 通過 (Must ≥3)✓❌ (#usable=2)❌ (#suitable=2)❌ (#suitable=1)

検討した代替案 (Alternatives Considered)

  • 案 A（論点 1: トップ landing の Tier）Tier C 維持: ポータル/TOC は fact-box 不要と割り切り現状追認。改訂ゼロだが「全社の顔」が裸の TOC のままで再ポジショニングの趣旨を満たさず #usable 不足のため不採用。
  • 案 C（論点 1）Tier A 判定基準を拡張して SUMMARY を Tier A に取り込む: 判定基準 (b)「対応コードあり」を緩和する必要があり、tier-a-header-lint の必須 4 項目が SUMMARY に対し確実に誤 FAIL するため lint 改修が必須でコスト高（#operable 不可）。不採用。
  • 案（論点 2: Corp 入口）landing 不要なグラブバッグと割り切り L0 から各 doc へ直リンク: Corp 軸の入口を作らない。空白が残り #usable 不足のため不採用。
  • 案（論点 2: L1 の Tier 振り分け）landing は一律 Tier A: コードの有無で分けず全 L1 に fact-box を必須化。Corp のようなコード無し軸で fact-box が形骸化し #suitable 不可のため不採用。

影響 (Consequences)

§5.1 正の影響 (Good)

  • Corp 空白の解消。
  • SUMMARY の役割と規約の不一致を解消。
  • Tier P 新設でコードを持たない landing にファクトボックスを誤適用する将来リスクを構造的に排除。
  • 軸が増えても L1 を 1 つ足すだけで対応できる拡張性を担保。

§5.2 負の影響 (Bad)

  • writing-guide.md §7 への小節追加（Tier P 定義・landing 階層・判定基準分岐）の規約改訂コスト。
  • Corp L1 ページ本文の執筆は別タスクで遅延しうる（ADR-0079 と同じ「決定だけあって実装なし」の再現リスク。Confirmation §6.5 で URL 200 を KPI 化して回避）。
  • MAS retitle で product_overview.md の H1 表示が変化（実害小）。frontmatter title 不整合の見逃しリスク（Confirmation で frontmatter も検査対象に含める）。

§5.3 中立・トレードオフ (Neutral / Trade-offs)

  • Tier 類型が A/B/C に P が加わり 4 分類になる（複雑性は微増だが判定は「コード有無」で機械的に分岐可能）。
  • lint 影響の明示: scripts/tier-a-header-lint.mjs の TIER_A 配列・必須 4 項目（REQUIRED_LABELS）は変更しない。Tier P は本 lint の検査対象外とするため、Tier P 専用 lint（または条件分岐拡張）を別途新設しなければ形骸化リスクあり（Confirmation で CI 組み込みを完了条件化）。
  • 「コードを持つ」の境界: リポジトリ上に実行可能な成果物（スクリプト / アプリ / Worker）が存在し CI でアサート可能な軸を「コードを持つ」とする。同定義と Tier P → Tier A 格上げトリガー条件を writing-guide.md §7 に転記する。
  • 軸フィルタ実装方式（確定）: 軸フィルタは scripts/docs-build.mjs の detectBusiness() がビルド時に nav グループ名から data-business 属性を静的生成し、templates/page.html のクライアントサイド JS で表示切替する方式。Workers Runtime の動的フィルタリングは行わないため subrequest / CPU time 上限は非該当。
  • ADR-0079 未実装の根拠保持: ADR-0079 は Proposed / Not Started のまま実装されず、より単純な単一サイト + 軸フィルタ（PR #1544）が実際に採られた。別サイト分割を再評価すべきトリガーは「軸数 5 以上」または「顧客向けプロダクトの外部公開 docs が必要になった場合」とし、Cloudflare 無料枠改定等の環境変化時に本トリガーで再評価する。

撤退条件 (Rollback Plan)

  • writing-guide.md §7 の追記分を削除し、SUMMARY.md / product_overview.md を git revert する 1 PR で 0.5 人日以内に復元できる（tier-a-header-lint は無改修のため revert 対象なし）。
  • 規約導入後 3 ヶ月時点で、(a) Corp L1 landing が新設されず空白のまま、または (b) Tier P 規約起因のレビュー差し戻しが月 3 件を超える場合、Tier P を「必須」から「推奨」へ降格、または Tier C 維持（案 A）へ revert する。
  • 撤退条件 (a) の発動判定は Review After の棚卸しを待たず、採択から 8 週後の sprint review で自動確認する。発動時の判断主体・revert 承認フローは起案者（[email protected]・単独 Decider）が担当する。
  • Tier 4 分類（A/B/C/P）の判定で例外が 5 件を超えたら分類設計を見直す。
  • Review After: 2026-12-01（ADR-0114 の半年棚卸しに同期）。

コスト試算

  • writing-guide.md §7 改訂（Tier P 定義 + L0/L1 landing 階層 + 判定基準の軸分岐 + 「コードを持つ」境界定義 + Tier 判定フローチャート 1 図）: 約 0.5 日
  • SUMMARY.md を Tier P 軽量ヘッダー + ピッチへ改訂: 約 0.25 日
  • product_overview.md の H1 retitle（MAS 明示）+ frontmatter title 同期: 約 0.1 時間
  • ADR-0114 への Refine 注記 + ADR-0079 の Superseded 化（未実装放置の理由・再評価トリガー条件を 3 行追記）: 約 0.25 時間
  • Corp L1 入口ページの新設タスクを DOC-OPS バックログへ起票（担当者・期限・優先度を必須フィールド化、本文執筆は別タスク・本 ADR 対象外）: 約 0.1 時間
  • Tier P ページ用 lint（tier-a-header-lint.mjs の条件分岐拡張で実装し重複スクリプトを避ける）: 約 0.25 日
  • 合計: 約 1.15 日（Standard 想定。Tier P lint 込み）
  • 運用コスト: 新規 landing 追加時の Tier 判定は PR レビューで 1 件あたり 5 分以内（フローチャート参照前提）。

Confirmation

  • 検証手段: writing-guide.md §7 に「Tier P（ポータル landing）定義・L0/L1 landing 階層・判定基準の軸分岐・『コードを持つ』境界定義・Tier 判定フローチャート」セクションが存在する / 実行頻度: 導入時 1 回 + CI 毎の存在チェック / 違反時対応: PR ブロック。KPI: 存在 1 / 0。
  • 検証手段: product_overview.md の H1 と frontmatter title の両方に「MAS」が明示されている（grep アサート） / 実行頻度: CI 毎 / 違反時対応: PR ブロック。KPI: 検出 1 / 0。
  • 検証手段: scripts/tier-a-header-lint.mjs が改修なしで pass を継続する（既存 Tier A 7 ページの検査回帰確認） / 実行頻度: CI 毎 / 違反時対応: PR ブロック。KPI: FAIL 0 件。
  • 検証手段: Tier P 専用 lint（または tier-a-header-lint.mjs の条件分岐拡張）が CI パイプラインに組み込まれ、Tier P 軽量ヘッダー必須項目（運営/対象/更新ポリシー/索引リンク）を検査する / 実行頻度: CI 毎 / 違反時対応: PR ブロック。KPI: 組み込み 1 / 0、FAIL 0 件。
  • 検証手段: SUMMARY.md が Tier P 軽量ヘッダー（運営/対象/更新ポリシー/索引）+ ピッチを持つ / 実行頻度: 手動 QA・導入時 1 回 + Tier P lint 経由で CI 毎 / 違反時対応: 起案者が再改訂。KPI: 保有 1 / 0。
  • 検証手段: Corp L1 landing の新設タスクが DOC-OPS バックログに担当者・完了期限・レビュー責任者付きで起票されている / 実行頻度: 採択時 1 回 / 違反時対応: 起案者が起票補完。KPI: 起票 1 / 0。
  • 検証手段: Corp L1 landing が URL として HTTP 200 で閲覧可能であること（ADR 採択から 8 週以内） / 実行頻度: 採択 +8 週 sprint review + 以降 CI 毎の URL ヘルスチェック / 違反時対応: 撤退条件 (a) を発動し Tier P 「推奨」降格または案 A へ revert を検討。KPI: 200 応答 1 / 0。
  • 検証手段: 軸フィルタが docs-build.mjs のビルド時静的生成（data-business 属性）+ クライアントサイド JS 方式であり、Workers Runtime を使用しないことを確認する（subrequest / CPU 上限は非該当） / 実行頻度: 導入時 1 回 / 違反時対応: Workers Runtime 化が将来必要になった場合は subrequest 実測 KPI を追加。KPI: Workers runtime 不使用 = true。

参照 (References)

  • 関連 ADR:
    • ADR-0114（概要ページ冒頭規約 = Tier）: Refine。Tier P・L0/L1 landing 階層・判定基準の軸分岐を追加し、SUMMARY を Tier C → Tier P へ移す。既存 Tier A 7 ページの拘束は不変。Refine 注記から本 ADR への参照リンクを双方向で張る。
    • ADR-0079（docs を engineering/corporate に分割・サイト分離・Proposed 未実装）: Supersede。ADR-0079 は Proposed / Not Started のまま実装されず、より単純な単一サイト + Corp/MAS/DRP 軸フィルタ（PR #1544）が実際に採られたため、本 ADR が置換する。別サイト分割を再評価すべきトリガー: 軸数 5 以上、または顧客向けプロダクトの外部公開 docs が必要になった場合。
    • ADR-0055（nav prefix 親フォルダ番号ベース）: 並立。L1 入口は既存 nav prefix 体系の上に乗るため Conflict なし。
    • ADR-0123（frontmatter 3 層）/ ADR-0117（DRP 層別）/ ADR-0126（法的正本）: 並立・Conflict なし。
  • 関連 PR/Issue: PR #1574（本 ADR の起案 PR）。Corp L1 入口の DOC-OPS バックログ Issue は採択後に起票する。
  • 外部資料:
    • RQ-097（ADR 粒度基準）
    • Stripe Engineering Blog (2022) — Tier 判定条件の例外蓄積事例
    • Cloudflare Workers limits documentation（subrequest 上限・CPU time）

Review After: 2026-12-01