Office 2.0

情報を「ファイルの置き場所」から解放し、意味・関係・根拠を持つ知識資産として育てるための、6つの専門ワークスペース。

01. 何を目指しているか

Office 2.0はMicrosoft Officeの代替でも、ノートアプリやチャットAIの複製でもありません。メモ、対話、関係、資料、タスクを孤立させず、あとから検証・再利用・実行できる知識としてつなぐことを目指しています。

設計原則: Single Source of Truth / Local First / Repository Pattern / Human in the Loop / Seat Separation

このページは公開リポジトリの現在の実装と設計文書を分けて記述しています。構想上の完成形と、現時点の実装を同一視しません。

正式なSeat番号は、アプリとフロントエンドの並び順に統一されています。

ⅠCapture

掴む。 メモ、クリップ、日記、添付を素早く残し、NexixへPromoteする入口。

ⅡNexix

結ぶ。 Object、Relation、Evidence、Confidenceを管理し、説明可能な知識へ整える。

ⅢElix

問う。 手元の知識を参照し、引用と監査可能性を残す対話ワークスペース。

ⅣViox

眺める。 確定した関係と仮説を区別しながら、グラフやタイムラインで可視化する。

ⅤLumex

伝える。 知識を文書やプレゼンテーション向けに整える投影レイヤー。

ⅥMovex

動かす。 知識をタスクと実行キューへ落とし込み、状態と履歴を管理する。

CURRENT IMPLEMENTATION

現在は、各Seatが独立したRust API、Reactフロントエンド、ローカルSQLiteを持ちます。物理的に1つの共有DBへ統合済み、という構成ではありません。

UI — React / TypeScript / Vite。各Seatは独立した画面と開発サーバーを持つ。

API — Rust / axum。Seat間連携は明示的なREST契約を通す。

Storage — 各SeatのSQLite。Nexixが確定知識の中心を担い、他Seatは自席データや再生成可能な派生データを持つ。

AnchorDB Core — 共通のAnchorObjectモデルとAnchorStore traitを段階的に導入中。現在の実装対象はCaptureとNexix。

DESIGN DIRECTION

「AnchorDB」は、単なる1つのSQLiteファイルではなく、Object / Relation / Evidence / Confidence / Historyを一貫して扱う知識表現レイヤーとして設計されています。全Seatの物理統合は将来の検討事項です。

AI Promote

CaptureからOpenAI互換エンドポイントを利用可能。提案・確認・適用・取消を人間の判断付きで処理。

Knowledge Model

NexixでRelation、Evidence、Confidence詳細、Explain、全文・ハイブリッド検索を実装。

Local Data

各Seatはlocalhostで動作し、SQLiteへ保存。DB移行は履歴・トランザクション・テストで保護。

Quality Gate

6 Seatのbackend/frontendを12ジョブで継続検証。Rustのfmt・build・testとFrontend buildを実行。

領域	現在
6 Seat	M0/M1を中心に実装済み。Seatごとに追加機能の成熟度は異なる。
AI	Captureは実LLM接続に対応。Elixなど一部はStubを残し、段階的に置換する。
Data Model	Capture/Nexixから共通traitを検証中。全Seat統合は未完了。
Product Policy	Capture / Capixの公開名称、無名の裏計算層、Seat間境界の一部は継続検討。

Office 2.0は活発に開発中です。公開ページでは、未実装の構想を完成済み機能として表示しません。

コード、仕様、契約、CIはGitHubで公開しています。設計変更はContract FirstとHuman Reviewを重視し、機能追加前に影響範囲・完了条件・ロールバック方針を整理します。