master
みてるぞ 1 month ago
parent
commit
486d53c41e
1 changed files with 360 additions and 8 deletions
  1. +360
    -8
      %E5%AE%9F%E8%A3%85%E8%AA%AC%E6%98%8E%E6%9B%B8.md

+ 360
- 8
%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 lang: ja-JP
toc: true toc: true
toc-depth: 2 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) 1. バックエンド実装(Rails 8 API)
2. フロントエンド実装(React + Vite) 2. フロントエンド実装(React + Vite)
3. db/schema.rb 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 - **第 1 優先**: 現在のソースコードと db/schema.rb
- **第 2 優先**: フロントエンドの画面実装とルーティング - **第 2 優先**: フロントエンドの画面実装とルーティング
- **第 3 優先**: 既存仕様書の文脈整理
- **第 3 優先**: 開発者が明示した計画仕様
- **第 4 優先**: 既存仕様書の文脈整理
したがって本書では、記述を次の 3 種に分ける。
| 表記 | 意味 |
| --- | --- |
| 現行仕様 | 現在のコードとスキーマで確認できるもの |
| 計画仕様(確定) | 実装は未了だが、方針として採用済のもの |
| 計画仕様(未確定) | 方向性はあるが、具体形が今後詰まるもの |
この区別を曖昧にすると、「実装済み」と「願望」が混ざって腐る。
本書はそこを分離し、**開発・公開判断・将来の実装順序づけ** に耐える文書とする。
したがって本書は、「こうしたい」ではなく **現にコードがそうなっているか** を基準に書いている。過去の設計メモや backlog は、現行仕様の証拠には使っていない。
# システム概要 # システム概要
@@ -956,7 +978,7 @@ wiki:migrate は Gollum 形式の旧 Wiki を DB 版管理へ移行するタス
nico:sync は外部 DB からニコニコ動画情報を引き込み、投稿・ニコタグ・内部タグ連携を更新する中核バッチである。 nico:sync は外部 DB からニコニコ動画情報を引き込み、投稿・ニコタグ・内部タグ連携を更新する中核バッチである。
# 非機能要件と既知のギャップ
# 非機能要件・既知のギャップ・計画への接続
## 整合性・監査性 ## 整合性・監査性
@@ -1034,6 +1056,336 @@ BTRC Hub は、表面上は「タグ付きリンク集」だが、内部実装
要するに現行 BTRC Hub の正体は、**リンク集 UI を持つタグ・Wiki・外部同期・共同視聴の複合基盤** である。 要するに現行 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 一覧 # 付録 A: 現行 API 一覧
## 投稿系 ## 投稿系


Loading…
Cancel
Save