# 「確定レビュー・キュー」―未確定ノードを一括検証して確定する作業場

- 起案: 管理人 (2026-07-19 22:40:55)
- タグ: #ワークフロー #使用者体験 #信頼 #検証状態 #融合
- 出典: https://fusion.upper.jp/ideaforum/ideas/1

## 使用者としての困りごと
憲法第四条の思想に惚れて openManidoc を使っています。AI（頭の良い友人）がMCP経由でツリーを自律的に育ててくれるのはとても快適です。でもいざ自分が使う側に回ると、「どのノードがまだ未確定で、自分の名において引き受けるべきか」が一目で分かりません。

検証状態（draft / 未確定 / 確定）や出典ポインタは思想として掲げられていますが、「確定という行為」を日々回すための専用UIがまだ見当たりません。マインドマップや検索でノードを探して、一つずつ開いて確定して…というのは手間です。

## アイディアの内容：「確定レビュー・キュー」
未確定・AIが書き換えたノードだけを集めた専用の一覧ビューを追加します。使用者はここを上から順に見ていくだけで、「友の差し出したものを自分の名において引き受ける」作業を一括で回せます。

- **レビュー待ちキュー**: draft / 未確定のノードをワークスペース横断で一覧化。前回確定以降にAIが書き換えたノードも拾う。
- **左に本文・右に一次ソース**: 出典ポインタの元ファイルを並べて表示し、根拠を見ながら判断できる。
- **一操作確定と差し戻し**: キーボード（例: Enterで確定、Escでスキップ）で次々と処理。未確定のまま保留も可。
- **確定履歴**: いつ・どのノードを自分が確定したかを記録し、責任の所在を残す。

## 思想との一貫性
これは監視の道具ではなく、「信頼を確かめ合う道具」（第四条）を実務に落とすものです。賢い友人が最後の一票を持ち主に残す―その「最後の一票」を押す行為を、摩擦なく連続で行えるようにします。

## 期待できる効果
- 未確定の放置を防ぎ、ツリー全体の「確からしさ」が常に可視化される
- AIに自律構築を任せるほど、人間側の確定作業がボトルネックにならない
- 「推論は構築時に一度だけ、結果をデータとして固定」という第三条のサイクルが回りやすくなる

## 管理人 (2026-07-19 23:10:11)

# Claude Code 指示書：「確定レビュー・キュー」機能の実装

openManidoc に、未確定ノードを一括で検証・確定するためのビュー「確定レビュー・キュー」を実装する。憲法第四条「信頼を確かめ合う道具」を実務に落とすことが目的で、監視ではなく確定作業の摩擦を減らすことを狙う。

## 実装の前提（先に確定させる方針）

- ローカル完結・MCPはローカルLLM専用という思想を崩さない範囲で実装する。ノード本文や検証状態がクラウドLLMへ送信される経路は作らない。
- 既存のワークスペース形式（{projectId}.json + {projectId}/images/、旧Manidoc互換）を壊さない。新機能はこの構造の上に追加する。

## 事前調査（実装前に必ず確認）

- 検証状態（draft / 未確定 / 確定）を全ノードがデータとして実際に保持できているかを確認する。保持していない場合はデータモデルへフィールドを追加し、既存ノードへの後方互換な移行（未設定は未確定扱いなど）を設計する。
- 出典ポインタ（元ファイルへの参照）が各ノードにどの形で入っているかを確認する。

## 機能要件

1. レビュー待ちキュー: draft / 未確定のノードをワークスペース横断で一覧化する。前回確定以降に AI が書き換えたノードも拾う。検知方式は「更新日時の比較」または「確定時に本文ハッシュを保存し差分を見る」等を比較検討し、確実な方を採用する。
2. 左に本文・右に一次ソース: 出典ポインタの元ファイルを並べて表示し、根拠を見ながら確定判断できるようにする。対応形式（Markdown / HTML / 画像 / PDF 等）の範囲は要検討。まずは Markdown を確実に対応し、他形式は段階的に。
3. 一操作確定と差し戻し: キーボードで次々に処理できるようにする（例：Enter で確定、Esc でスキップ）。既存ショートカットとの衝突を回避すること。未確定のまま保留も可能にする。
4. 確定履歴: いつ・どのノードを誰が確定したかを記録し、責任の所在を残す。保存場所は {projectId}.json 内か別ファイルかを既存データ構造との整合性を見て決める。

## パフォーマンス

- ワークスペース横断でレビュー待ちを集める処理は、大量ノード時でも一覧化・検索が実用的な速度で動くこと。必要ならインデックスやキャッシュを検討する。

## 発展案（初期スコープ外だが設計時に考慮）

- レビューキューを「差分ハイライト表示」にし、AI が変更した箇所を色分けで見せる。
- 確定率をダッシュボード化し、ツリー全体の「確からしさ」を可視化する。

## 今回は扱わない（保留）

- 複数人でのロック競合・権限（第二条 統治主権）まわりは初期スコープから外す。単一使用者での確定フローを先に完成させる。

## 受け入れ基準

- 未確定 / AI 書き換えノードだけを集めたキュー画面から、マウスとキーボードだけで確定・保留・差し戻しが連続して行えること。
- 確定操作が履歴として理由とともに残ること。
- 既存ワークスペース・データ構造・ローカル完結の思想が保たれていること。

## 付箋ボード

```mermaid
graph TD
    N1["【課題】検証状態(draft/未確定/確定)を全ノードがデータとして実際に保持できているか。データモデルの確認・移行が必…"]
    N2["【課題】前回確定以降にAIが書き換えたノードをどう検知するか(更新日時・確定時ハッシュ保存などの方式検討)"]
    N3["【課題】ワークスペース横断でレビュー待ちノードを集める際のパフォーマンス(大量ノード時の検索・一覧化速度)"]
    N4["【要検討】出典ポインタの元ファイルを右ペインに表示する際の対応形式(Markdown/HTML/画像/PDF等)の範囲"]
    N5["【要検討】キーボード操作(Enter確定・Escスキップ)と既存ショートカットの衝突回避"]
    N6["【要検討】確定履歴をどこに保存するか( projectId .json内か、別ファイルか)。既存データ構造との整合性"]
    N7["【決定】ローカル完結・MCPはローカルLLM専用という思想を崩さない範囲で実装する(クラウド送信なし)"]
    N8["【アイデア】レビューキューを「差分ハイライト表示」にし、AIが変更した箇所を色分けで見せる"]
    N9["【アイデア】確定率をダッシュボード化し、ツリー全体の「確からしさ」を可視化する"]
    N10["【保留】複数人でのロック競合・権限(第二条統治主権)まわりは初期スコープから外す論点"]
```