From 486d53c41e4d3081f2d875a4d45e1027d0d2290a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E3=81=BF=E3=81=A6=E3=82=8B=E3=81=9E?= <miteruzo@naver.com>
Date: Mon, 23 Mar 2026 02:16:50 +0900
Subject: [PATCH]

---
 ...%9F%E8%A3%85%E8%AA%AC%E6%98%8E%E6%9B%B8.md | 368 +++++++++++++++++-
 1 file changed, 360 insertions(+), 8 deletions(-)

diff --git a/%E5%AE%9F%E8%A3%85%E8%AA%AC%E6%98%8E%E6%9B%B8.md b/%E5%AE%9F%E8%A3%85%E8%AA%AC%E6%98%8E%E6%9B%B8.md
index d11f2e8..93466a0 100644
--- a/%E5%AE%9F%E8%A3%85%E8%AA%AC%E6%98%8E%E6%9B%B8.md
+++ b/%E5%AE%9F%E8%A3%85%E8%AA%AC%E6%98%8E%E6%9B%B8.md
@@ -1,7 +1,7 @@
 ---
-title: 'BTRC Hub 現行仕様書'
-subtitle: '最新ソーススナップショット（btrc-hub-feature_297.zip）ベース'
-date: '2026-03-22'
+title: 'BTRC Hub 仕様書'
+subtitle: '現行仕様と計画仕様の統合版（2026-03-23）'
+date: '2026-03-23'
 lang: ja-JP
 toc: true
 toc-depth: 2
@@ -24,20 +24,42 @@ header-includes:
 
 # 本書の位置づけ
 
-本書は、**最新ソーススナップショット btrc-hub-feature_297.zip** を起点に、BTRC Hub の現行仕様を再構成したものである。主に参照したのは次の 4 系統である。
+本書は、**最新ソーススナップショット btrc-hub-feature_297.zip** を起点に、BTRC Hub の現行仕様を再構成したうえで、開発者ヒアリングによって得られた **未実装だが今後仕様書へ載せるべき内容** を統合したものである。
+
+本書の役割は 2 つある。
+
+1. **現行仕様の説明書**  
+   実際にコードへ存在する API・画面・永続データ・制約を整理する。
+
+2. **計画仕様の設計書**  
+   一般公開に向けて実装予定の機能、公開段階、運用方針、未確定論点を明文化する。
+
+参照元は次の 5 系統である。
 
 1. バックエンド実装（Rails 8 API）
 2. フロントエンド実装（React + Vite）
 3. db/schema.rb
-4. 既存仕様書 BTRC_Hub_現行仕様書_2026-03-08.md
+4. 既存仕様書 BTRC_Hub_現行仕様書_2026-03-22.md
+5. 2026-03-23 時点の開発者ヒアリング結果
 
 情報の優先順位は明確である。
 
 - **第 1 優先**: 現在のソースコードと db/schema.rb
 - **第 2 優先**: フロントエンドの画面実装とルーティング
-- **第 3 優先**: 既存仕様書の文脈整理
+- **第 3 優先**: 開発者が明示した計画仕様
+- **第 4 優先**: 既存仕様書の文脈整理
+
+したがって本書では、記述を次の 3 種に分ける。
+
+| 表記 | 意味 |
+| --- | --- |
+| 現行仕様 | 現在のコードとスキーマで確認できるもの |
+| 計画仕様（確定） | 実装は未了だが、方針として採用済のもの |
+| 計画仕様（未確定） | 方向性はあるが、具体形が今後詰まるもの |
+
+この区別を曖昧にすると、「実装済み」と「願望」が混ざって腐る。  
+本書はそこを分離し、**開発・公開判断・将来の実装順序づけ** に耐える文書とする。
 
-したがって本書は、「こうしたい」ではなく **現にコードがそうなっているか** を基準に書いている。過去の設計メモや backlog は、現行仕様の証拠には使っていない。
 
 # システム概要
 
@@ -956,7 +978,7 @@ wiki:migrate は Gollum 形式の旧 Wiki を DB 版管理へ移行するタス
 
 nico:sync は外部 DB からニコニコ動画情報を引き込み、投稿・ニコタグ・内部タグ連携を更新する中核バッチである。
 
-# 非機能要件と既知のギャップ
+# 非機能要件・既知のギャップ・計画への接続
 
 ## 整合性・監査性
 
@@ -1034,6 +1056,336 @@ BTRC Hub は、表面上は「タグ付きリンク集」だが、内部実装
 
 要するに現行 BTRC Hub の正体は、**リンク集 UI を持つタグ・Wiki・外部同期・共同視聴の複合基盤** である。
 
+
+# 計画仕様
+
+本章は、現行コードにはまだ全面反映されていないが、今後の BTRC Hub にとって重要な仕様をまとめる。  
+公開判断や実装優先度を考える際は、現行仕様だけでなく本章を合わせて参照する。
+
+## 公開方針
+
+### 公開段階
+
+BTRC Hub の公開は一気に完全一般公開へ進めるのではなく、段階的に引き上げる。
+
+| 段階 | 意味 | 想定時期 |
+| --- | --- | --- |
+| 第 3 段階 | 誰でも閲覧可、投稿・編集は申請制 | 初回一般公開 |
+| 第 4 段階 | 履歴管理・差し戻し・BAN 運用が整った後、閲覧中心以外の開放範囲を拡張 | 将来 |
+
+計画仕様（確定）として、**初回一般公開は第 3 段階** を前提とする。  
+いきなり広く編集を開けるのではなく、履歴管理と運用装備が整ってから第 4 段階へ進む。
+
+### 公開時の主役
+
+BTRC Hub が一般公開時に前面へ出す主役は **タグ整理基盤** である。  
+投稿・Wiki・ニコニコ連携・上映会はその周辺機能ではあるが、中心価値は「タグを軸にコンテンツと知識を整理し、再発見しやすくすること」に置く。
+
+### 公開前に必須とするもの
+
+開発者ヒアリング時点で、一般公開前に必要と認識されている主要項目は次である。
+
+- 利用規約
+- プライバシーポリシー
+- 御意見番
+- banned user / banned IP の強制適用
+- 管理画面
+- Wiki 本文検索
+- Wiki の事前整備
+- タグ別名管理 UI
+- タグ別名解除 UI
+- 履歴管理の表示・差し戻し
+- お遊び機能としてのアキネータ風機能
+
+このうち、利用規約・プライバシーポリシー・BAN・管理画面・履歴管理は、公開後の運用破綻を防ぐための最低装備である。
+
+## 運営・モデレーション計画
+
+### 御意見番
+
+計画仕様（確定）として、**御意見番** という意見送信機能を用意する。これは単なるお問い合わせフォームではなく、次を自動添付できることを目標とする。
+
+- 直前の操作ログ
+- 画面スクリーンショット
+- 必要に応じた環境情報
+
+狙いは、バグ報告・使い勝手の不満・誤操作報告を、再現に使える材料つきで受け取ることにある。  
+一般公開後の保守効率へ直結するため、通常の問い合わせ導線より重要度が高い。
+
+### BAN と差し戻し
+
+計画仕様（確定）として、次の管理系操作を整備する。
+
+- ユーザ BAN
+- IP BAN
+- 投稿削除
+- Wiki 等の差し戻し
+- 履歴表示からの復元導線
+
+guest の権限は初期公開時点では閲覧のみとするが、履歴管理と BAN 運用が十分に整った後は、限定的な編集権限を与える余地を残す。
+
+### 管理画面
+
+計画仕様（確定）として、少なくとも次を扱える管理画面を整備する。
+
+- BAN の付与と解除
+- 問題投稿・問題編集の確認
+- 履歴閲覧と差し戻し
+- タグ別名・サニタイズ規則の管理
+- 送信された御意見番の確認
+
+## 履歴管理・監査性の拡張
+
+現行実装でも post_tags と wiki_revisions を中心とした履歴基盤は存在する。  
+今後はこれを、内部保持だけでなく **公開サービスとして使える履歴機能** に引き上げる。
+
+### 対象
+
+計画仕様（確定）として、次の履歴を重視する。
+
+- タグ記載履歴
+- 投稿情報の変更履歴
+- 変更者の表示
+- 差分表示
+- 版ごとの復元
+
+Wiki については版管理が既に中核であるため、表示・差し戻し・競合検出が整って初めて一般公開に耐える。
+
+### 公開段階との関係
+
+第 4 段階へ移る条件の一つは、履歴が「保存されている」だけでなく、**閲覧・追跡・差し戻しが運用できる水準** に達することである。
+
+## Wiki 計画仕様
+
+### 位置づけ
+
+Wiki はタグへの説明を蓄積する知識基盤である。  
+「主要タグに説明が付いていること」がタグ整理基盤としての説得力を決める。
+
+### 主要ページ整備方針
+
+開発者ヒアリングでは、主要タグに対して **約 5000 ページ規模** の説明ページが最終的に必要とされている。  
+これは「公開前に必ず 5000 ページ作る」という意味ではなく、**主要タグ群をカバーするための目標規模** と位置づける。
+
+計画仕様（確定）として、
+
+- 主な対象は **タグへの説明ページ**
+- 主要タグが概ね 5000 程度存在する想定
+- 初期整備は手作業で行う
+- 1 ページの最小要件は **1 行説明でもよい**
+
+とする。
+
+したがって、量よりもまず「主要導線上のタグに最低限の説明がある」状態を目指す。
+
+### リダイレクトと別名の関係
+
+計画仕様（確定）として、Wiki のリダイレクトは **タグ別名機能をリダイレクトとして使う** 方向で整理する。履歴の主たる管理責任は `tag_names` 側に置く。
+
+この方針により、少なくとも次の整合が期待される。
+
+- タグ別名検索と Wiki 参照先の連動
+- 別名から正規名ページへの自然な到達
+- 履歴の責務を Wiki 側へ分散させないこと
+
+### Wiki の追加実装項目
+
+計画仕様（確定）として、次を重点実装対象とする。
+
+- 本文検索
+- 版の巻き戻し
+- 競合検出
+- 下書き保存
+- 画像埋め込み
+
+画像埋め込みは、単なるMarkdown拡張ではなく、説明ページの情報密度と可読性を上げるための要件である。
+
+## タグ機能の計画仕様
+
+### 別名管理
+
+計画仕様（確定）として、タグ別名について少なくとも次を実現する。
+
+- 別名の作成
+- 別名の解除
+- 別名を含む検索
+- Wiki 参照先の連動
+- 別名からの参照解決の連動
+
+ここでいう「Wiki 連動」は、単にタグ詳細にリンクを出すだけではなく、別名経由で参照しても正規の説明へ辿り着けることを意味する。
+
+### タグ詳細ページの位置づけ
+
+タグ詳細ページについては、現時点で **「そもそも詳細ページが必須か」自体が再検討事項** である。  
+現行には `/tags/:id` が存在するが、将来設計では次のどちらを主にするかは未確定である。
+
+- タグ詳細ページを知識・管理の中心に育てる
+- Wiki ページを実質的な詳細ページとして扱う
+
+よって、タグ詳細ページの最終的な責務は **計画仕様（未確定）** とする。
+
+### タグ名サニタイズ
+
+tag_name_sanitisation_rules は基本的に内部運用向け機能とする。  
+計画仕様（確定）として、サニタイズ規則の操作は **鯖缶専用** の管理経路で行う。
+
+想定用途は次である。
+
+- ルール変更時に一括適用する
+- 命名揺れの整理を管理側で行う
+- 一般ユーザへ細かいルールを露出しすぎない
+
+## 投稿・検索の計画仕様
+
+### 投稿詳細
+
+投稿詳細ページでは、今後も次を重視する。
+
+- 埋め込み
+- 関聯タグ
+- 履歴
+- ブックマーク
+
+特に履歴は、「投稿にどのタグがどのように付け替えられたか」を追えるようにする意味で重要である。
+
+### 検索
+
+開発者ヒアリング時点で、検索の最重要追加項目は **Wiki 本文検索** である。  
+他の検索拡張もありうるが、本仕様書では本文検索を最優先の計画仕様として扱う。
+
+### 閲覧済・マイリスト
+
+閲覧済フラグは将来的にも重要だが、そのまま独立機能として肥大化させるか、**マイリスト機能と統合するか** は未確定である。  
+したがって閲覧済管理の最終形は **計画仕様（未確定）** とする。
+
+## 上映会（Theatre）の計画仕様
+
+### 位置づけ
+
+一般公開時の上映会は **実験機能** と位置づける。  
+サイトの看板機能として押し出すのではなく、タグ整理基盤の周辺にある遊び・共同視聴機能として扱う。
+
+### 必要機能
+
+計画仕様（確定）として、次を将来的に整備する。
+
+- 会場一覧
+- 会場作成
+- 会場編集
+- 複数会場
+- チャット
+- 誰かが見ている通知
+
+「誰かが見ている通知」は上映会だけでなく、サイト全体の通知機能の一部として発展する余地がある。
+
+### マイリストとの関係
+
+上映会は、以前から構想されている **マイリストをみんなでリアルタイム視聴する機能** の延長線上にある。  
+したがって、今後の Theatre は単独の会場機能というより、マイリストと連動するウォッチパーティ基盤へ寄る可能性が高い。
+
+## 権限・公開範囲の計画仕様
+
+### ロール
+
+現行どおり `guest / member / admin` の 3 ロールを基本とする。  
+moderator 等の中間ロールは、現時点では採用済み方針ではない。
+
+### guest の扱い
+
+計画仕様（確定）として、初回一般公開時の guest は閲覧のみである。  
+ただし、履歴機能と BAN が十分に整った場合には、guest でも一部編集を認める余地を残す。
+
+## 法務・ポリシー文書
+
+### 利用規約
+
+計画仕様（確定）として、利用規約には少なくとも次を含める。
+
+- 禁止コンテンツ
+- 著作権侵害禁止
+- 外部リンク先の扱い
+- 埋め込みの扱い
+- ユーザ生成コンテンツの責任
+- アカウント停止条件
+- データ削除方針
+- 免責
+- 未成年配慮
+- 準拠法 / 管轄
+
+### プライバシーポリシー
+
+計画仕様（確定）として、プライバシーポリシーでは少なくとも次を収集情報として明示する。
+
+- IP アドレス
+- 引継ぎコード
+- Cookie / localStorage
+- 編集履歴
+- アクセスログ
+- 外部埋め込み先との通信
+- お問い合わせ内容
+
+## 外部連携の計画仕様
+
+### 優先する埋め込み先
+
+計画仕様（確定）として、今後の埋め込み対応優先順は次のとおりとする。
+
+1. ニコニコ
+2. YouTube
+3. Pixiv
+4. ニジカ投稿局
+5. Twitter
+6. Bluesky
+7. その他
+
+### preview API
+
+preview API は、**今の便利さを保ったまま安全化する** ことを目標とする。  
+したがって、単純な停止ではなく、利便性をできるだけ落とさない安全化が望まれる。
+
+## 設定機能の計画仕様
+
+計画仕様（確定）として、設定機能では次のようなユーザ別カスタマイズを扱う想定である。
+
+- テーマ
+- タグカテゴリごとの色設定
+- ミュートタグ
+- 非表示タグ
+- 埋め込み自動再生の可否
+
+タグカテゴリ色設定は、現状ハードコードされている色をユーザごとに調整できるようにする意図を持つ。
+
+## 通知機能
+
+通知機能の必要性自体は認識されているが、具体的に何をどの粒度で通知するかは **未定** である。  
+上映会の在席通知や「誰かが見ている」通知と結びつく可能性があるため、将来の横断基盤として検討する。
+
+## スマートフォン対応
+
+計画仕様（確定）として、スマートフォン環境でも **PC 同等の快適さ** を要求する。  
+単に閲覧できるだけでは足りず、主要な投稿・編集・検索操作が実用的である必要がある。
+
+## お遊び機能
+
+開発者ヒアリングでは、一般公開前の必須候補として **アキネータ風のお遊び機能** が挙げられている。  
+これは中核機能ではないが、公開時の導入体験や話題性に寄与する可能性がある。
+
+ただし、仕様詳細はまだ固まっていないため、現時点では **計画仕様（未確定）** とする。
+
+## 計画仕様の要約
+
+現行 BTRC Hub は「タグ付きリンク集 UI を持つ知識統合基盤」だが、計画仕様まで含めると、その目標像はもう少しはっきりする。
+
+- 主役はタグ整理基盤
+- Wiki は主要タグへ説明を付す知識基盤
+- 履歴管理は保存だけでなく表示・差し戻しまで含める
+- 公開は申請制から始め、履歴と運営装備の成熟に応じて広げる
+- 埋め込み、プレビュー、上映会、お遊び機能は基盤の上に乗る周辺価値である
+
+したがって、BTRC Hub の将来像は単なるリンク集ではない。  
+**タグ・Wiki・履歴・運営導線を中核に持つ、共同編集型の整理基盤** と捉えるのが最も正確である。
+
+
 # 付録 A: 現行 API 一覧
 
 ## 投稿系