RC Platform OS — 00_Inbox は Active Command Center、01_Projects は Source of Truth
Manabe-san の OneDrive (Akihiro - Siemens Healthineers) の中で実質的な仕事 OS は 000_RC/。中でも 00_Inbox は「もはや Inbox ではない、Active Command Center」、01_Projects は「Source of Truth、動かさない」。両者を Project Bridge / Report Bridge で繋ぐ。本 explainer は OneDrive ルートから Cross-Drive Guard まで 6 sections で全体像を示す。
TL;DR
- OneDrive root に 12+ folders、
000_RC= 仕事 OS、他は付帯領域 (会議/学会/出張/個人 等) - 00_Inbox = Active Command Center (5 spoke Platform + 3 Optional Skin)、01_Projects = 7 facilities × 31 projects の Source of Truth (動かさない)
- Bridges (_Platform/Project_Bridge + Report_Bridge) で物理を動かさず Platform 側に意味の橋、Cross-Drive Guard で OneDrive (work) ↔ GoogleDrive (private) 越境防止
01OneDrive RC root 全景 — 仕事 OS の位置づけ
Akihiro - Siemens Healthineers の中で 000_RC が中核、他は付帯。
Manabe-san の OneDrive (Akihiro - Siemens Healthineers) は 12+ の 1st level folder を持つ。中でも 000_RC/ が Research Collaboration 業務の主戦場、他は付帯領域 (会議/学会/出張/個人/前部署資料 等)。AI Agent はまず source_registry.yaml を読んで各領域の ai_policy を確認してから読み書きする。
| Folder | Role | AI Policy |
|---|---|---|
| 000_RC/ | Research Collaboration 業務の主戦場 (仕事 OS) | read_index_propose |
| _Admin/ | 個人 admin | internal_only |
| 100_Knowledge_Base/ | evergreen reference (会社資料) | read_extract |
| 200_PAS_OfficeWork/ | 前部署/前々部署資料 (Legacy) | explicit_only |
| 400_学会_研究会/ | 学会発表・研究会 | read_extract |
| 600_出張関連/ | 経費精算・旅程 | explicit_only |
| 700_Personal/ | 社内共有用 (危険な命名注意) | internal_only |
| 800_Temporary_Work/ | Scratch (TTL: 30 日) | ephemeral |
📚 用語解説 — source_registry: _System/00_Config/source_registry.yaml に各 source の path / role / ai_policy を一元定義。AI Agent はこれを最初に読む。
📚 用語解説 — ai_policy: read_write_proposal (read OK、書き込みは 99_Proposals 経由) / read_index_propose (read + index、書き込み proposal のみ) / explicit_only (明示要求時のみ) / internal_only (社外持ち出し禁止) の 4 段階。
🛠️ 運用方法: (1) AI Agent セッション冒頭に source_registry.yaml を読ませる (2) 新 source を追加する時は registry に entry 追加 (3) explicit_only / internal_only の領域はユーザー明示要求時のみアクセス (4) Cross-Drive Guard ルール (#06) を必ず併用
⚠️ アンチパターン: AI Agent に root 全体を自由巡回させる → 機密データ・個人情報の越境リスク、必ず source_registry 経由。700_Personal を「私的領域」と AI に誤認させる → 社内共有用、命名のリブランディング推奨。800_Temporary_Work を 30 日以上放置 → TTL 規律で月次掃除必須。
0200_Inbox = Active Command Center (NOT Inbox)
もはや「Inbox」ではない、5 spoke Platform + 3 Optional Skin の業務 OS 中核。
00_Inbox/ はもはや「未処理 Inbox」ではなく、Active Command Center。Wave 5-10 で 5 spoke (NOW/DRAFTS/PROJECTS/KNOWLEDGE/HANDOFF) + 3 Optional Skin (🎮 Engagement / 🧬 Knowledge OS / 🌉 Bridges) の構造に進化。AI Agent は必ず 00_PLATFORM.md から起動。
| Folder | Layer | Purpose |
|---|---|---|
| 00_PLATFORM.md | META (entry) | 唯一の入口、5 spoke + 3 Optional Skin 分岐 |
| _Platform/ | META | 5 Structure Notes (NOW/DRAFTS/PROJECTS/KNOWLEDGE/HANDOFF) + Engagement/ + Project_Bridge/ + Report_Bridge/ |
| 01_Input/ | HOT | メール・添付・メモ受付 (Outlook 連携) |
| 02_ToDo/ | WARM | Cockpit (実行ハブ) + Drafts |
| 03_Workspace/ | WARM | アクティブ作業 (施設別 sub-projects) |
| 04_Output/ | WARM | 分析・レポート・ツール (Draft + Render + Deploy) |
| 10_Knowledge/ | ZK | Zettelkasten + Wiki + 99_Proposals (4-Layer Architecture) |
| 90_Archive/ | COLD | 完了済み |
| _System/ | INFRA | AI 設定・スクリプト・source_registry |
📚 用語解説 — Active Command Center: 「Inbox = 未処理メール置き場」ではなく、Platform / ToDo / Workspace / Output / Knowledge / Handoff / AI Agent rules を全部持つ業務 OS。Wave 5-8 で 5 spoke + 3 Optional Skin 構造として明確化。
📚 用語解説 — 5 spoke: 01_NOW (今すぐ) / 02_DRAFTS (未送信) / 03_PROJECTS (施設別) / 04_KNOWLEDGE (ZK) / 05_HANDOFF (引き継ぎ)。各 spoke は _Platform/0X_*.md の Structure Note。
📚 用語解説 — Optional Skin: 5 spoke の 外側に重ねる補助レイヤー。99_Proposals (Support Layer) と同じ哲学、6th entry にしない。
🛠️ 運用方法: (1) 朝 1 番に 00_PLATFORM.md を Obsidian/エディタで開く (2) 目的に応じて 5 spoke のいずれかへ (3) 体調不良/疲労時は 🎮 Engagement Layer の Bastion Gate へ (4) 知識作業は 🧬 Knowledge Ops の 5 zk-verbs (5) 施設案件は 🌉 Project Bridge の Dossier 経由
⚠️ アンチパターン: 階層を辿って深い folder を直接探索する (00_PLATFORM 経由しない) → AI Agent が context を失う。「Inbox なんだから雑多に放り込む」と扱う → Active Command Center として規律ある分類が必要。Optional Skin を 6th entry にする → Support Layer の独立性が崩れる。
0301_Projects = Source of Truth (7 facilities × 31 projects)
施設×案件マトリクス、5 step プロジェクト構造。物理は動かさない。
01_Projects/ は Project Source of Truth。7 施設 × 31 projects の階層、各 project は 5 step folder (1_ContractProcess / 2_Provided / 3_Progress / 4_Reference / 5_Deliverable) + Multi-Project 訪問報告は施設レイヤー (0000_報告書/)。物理 = 動かさない、Platform 側に意味の橋を作る (#04)。
| Facility folder | Active Projects | 備考 |
|---|---|---|
| 1_三重大学 | 7 (BOOST / qPerfusion / 31P_MRS / T1_Rho / XD_GRASP / Inline_Strain / 31PMRS) | BOOST routine, 訪問頻度高 |
| 2_東北大学 | 6 (Adv_MRA / CS_4D_Flow / DualSequence / PC_Coronary 等) | qPerfusion + 4D Flow |
| 3_NCVC | 4 (BOOST 2024/2025 / DualSequence / WIP_BOOST_Paper) | Cardiac MRI 中心 |
| 4_京都大学 | 8 (Breast 入子 + Neuro 入子で IPA system) | IPA5 EPI ToF active (山本先生) |
| 7_名古屋大学 | 3 (CS4Dflow + Other) | — |
| 8_日本医科大学 | 1 (CS4DFlow) | — |
| 9_旭川医科大学 | 1 (CS4DFlow_AdvMRA) | — |
📚 用語解説 — 5 step プロジェクト構造: 1_ContractProcess (契約) → 2_Provided (本社/関係者からの提供資料) → 3_Progress (進捗・やり取り・訪問後メモ) → 4_Reference (Project 固有参考) → 5_Deliverable (半年/1 年大型成果物)。研究 collaboration ライフサイクルに合致。
📚 用語解説 — Facility Visit Report Layer (0000_報告書): 施設レイヤーに置く Multi-Project 訪問報告書。1 訪問 = 複数 Project なので Project 配下ではなく施設配下に置くのが自然。5_Deliverable と区別。
📚 用語解説 — IPA system (京大入子): 京大は Breast / Neuro でさらにサブカテゴリ化、IPA006 (DR-RESOLVE) / IPA5 (EPI_ToF) 等の Internal Project Agreement 番号で管理。
🛠️ 運用方法: (1) 新規 Project を扱う前に Project Bridge の project_registry.json を Read (2) 該当 project の absolute_dossier パスから 00_Project_Dossier.md を Read (3) 編集提案は 99_Proposals/proposed_edits/ に staging (4) 訪問報告は 0000_報告書 に最終配置、Project 大型成果物は 5_Deliverable に最終配置
⚠️ アンチパターン: 01_Projects/ の物理構造を勝手に変更する → Source of Truth 崩壊、AI Agent が迷子。訪問報告書を 5_Deliverable に置く → Multi-Project visit のとき不自然 + Project Deliverable と混在。Project Dossier を更新せず古いまま放置 → AI Agent が古い情報で動く。
04_Platform Bridges (Project Bridge + Report Bridge)
深い 01_Projects/ への AI 迷子を解消、Platform 側に意味の橋。
Wave 8 で確立した「物理を動かさず Platform 側に意味の橋を作る」原則の実装。_Platform/Project_Bridge/ に project_registry.json (31 projects, 3 種 path triplet) + facility_registry.json (7 facilities)、各 Project に 00_Project_Dossier.md (Codex Worker 生成)、各 Facility に 00_Facility_Index.md。
| Bridge | Path | 中身 | 用途 |
|---|---|---|---|
| Project Bridge | _Platform/Project_Bridge/ | registry x2 + 31 Dossier + 7 Index + context_packs/ + _templates/ | 施設×案件 Dossier 経由アクセス |
| Report Bridge | _Platform/Report_Bridge/ | visit_report_registry.json + 00_README | Multi-Project 訪問報告書 hub |
| Mission Control | _Platform/Engagement/rc_platform_mission_control.html | 5 タブ統合 view (Gate / Project / Report / Knowledge / Admin) | 1 画面で全俯瞰 |
📚 用語解説 — Project Dossier: 各 Project folder の入口 1 枚 md。AI Agent はこれを最初に読む (深い folder 直接探索しない)。frontmatter に facility / project_code / canonical_folder / status / report_layer / ai_policy 等。
📚 用語解説 — path triplet schema: project_registry.json の各 entry に folder (000_RC/ relative) + rc_root_relative_folder + absolute_folder の 3 種 path を持つ。AI Agent が混乱しない、どの環境からも組み立て可能。
📚 用語解説 — populated:false flag: Wave 9 critic 指摘の「31 empty Dossier 問題」対応。AI Agent はこの flag を見て「まだ enrich されてない、folder を直接探索」と判断可能。
🛠️ 運用方法: (1) _Platform/Project_Bridge/project_registry.json を session 冒頭で読む (2) 該当 project の absolute_dossier から Dossier 取得 (3) 必要なら context_packs/ も読む (4) 訪問予定があれば Report Bridge の visit_report_registry を確認 (5) Mission Control HTML で全俯瞰
⚠️ アンチパターン: registry を読まず deep folder を直接探索 → Bridge 設計が defeat。Dossier を更新せず古いまま放置 → 「scaffolding without content」(Wave 9 critic 指摘の Potemkin village)。populated:false flag を無視 → empty Dossier の content を信用してしまう。
0510_Knowledge ZK 構造 (4 Layer + 5 zk-verbs)
Karpathy LLM Wiki + Manabe Reflect 拡張、Knowledge OS 制度化。
10_Knowledge/ = Reusable Knowledge Source of Truth。Wave 4 で 13-folder blueprint (00_System / 10_Capture / 10_Zettel / 20_Wiki / 30_Research / 40_Entities / 50_Personal / 60_Operations / 70_Outputs / 80_Rendered / 90_Archive / 99_Proposals / _assets) に再構築。Wave 7 で 5 zk-verbs + LLM_WIKI_PROTOCOL (Knowledge OS 憲法) 制定。
| Layer | 場所 | 用途 |
|---|---|---|
| L1 Source | 00_System / 10_Capture / 10_Zettel / 20_Wiki / 30_Research / 40_Entities / 50_Personal / 60_Operations / 70_Outputs | md = source of truth |
| L2 Reader | 80_Rendered/html/ | HTML = generated only、源は md |
| L3 Backend | _assets/ + .obsidian/ | 画像・テンプレ・Obsidian 設定 |
| L4 Editor | 99_Proposals/ | AI 提案 staging (proposed_edits / proposed_new_notes / proposed_merges / proposed_syntheses 等)、main 直接書き込み禁止 |
📚 用語解説 — Karpathy LLM Wiki: OpenAI 共同創業者 Andrej Karpathy が提唱した「AI が wiki を育て続ける」設計パターン。RAG の発展形、新規 source を読む → 既存 note 更新 → 関連リンク増やすを反復。
📚 用語解説 — Reflect 動詞 (Manabe 拡張): AI Wiki から Manabe 自身の Zettelkasten 思考連鎖へ trigger。AI が代行できない、人間中心。Karpathy 原典にはない Manabe オリジナル。
📚 用語解説 — 99_Proposals (Support Layer): AI が main vault を直接編集しない安全弁。全提案は 99_Proposals/ に staging → human review → main へ merge。Wave 5-10 で「scaffolding without content」を即検出するための鍵。
🛠️ 運用方法: (1) 新規 source 取り込み → /zk-ingest (2) 既存 wiki から回答 → /zk-query (3) 健康診断 → /zk-lint (4) HTML 再生成 → /zk-render (5) AI Wiki を Manabe 思考に戻す → /zk-reflect。全操作後 wiki_activity_log.md に append 必須。Query 前は knowledge_index.md 必読。
⚠️ アンチパターン: AI が直接 Wiki/Permanent/Literature に書き込む → 99_Proposals 経由必須。HTML を source として扱う → md が source、HTML は生成物。Reflect を AI に代行させる → trigger のみ、本文は Manabe が書く。Operation の log skip → 全操作後 append 必須。
06Cross-Drive Guard (OneDrive ↔ GoogleDrive)
母艦 Windows のみ両方アクセス可能、自動 cross-copy 厳禁。
母艦 Windows PC は OneDrive (work) と GoogleDrive (private) の両方にアクセスできる唯一の統合ノード。だからこそ 機密データの越境リスクが最大。Wave 8 で Cross-Drive Guard 制度化、Context Pack には source_domain 必須、explicit_only ポリシー。
| Source | Path | ai_policy |
|---|---|---|
| onedrive_work | C:/MS/OneDrive - Siemens Healthineers/000_RC/ | read_index_propose |
| google_private | C:/GoogleDrive/ | explicit_only_no_cross_sync |
| google_mirror | C:/GoogleDrive/GD_Mirror/00_Inbox/ | read (Mac sync 用 mirror) |
| mixed | (Context Pack で混在の場合) | explicit_only + source_domain 必須 |
📚 用語解説 — Cross-Drive Guard: 母艦 Windows が OneDrive (会社 work) と GoogleDrive (個人 private) の両方にアクセスできる時、自動 cross-copy を禁止するルール。Context Pack 生成時には必ず source_domain (onedrive_work / google_private / mixed_explicit_only) を明記。
📚 用語解説 — GD_Mirror: 母艦 OneDrive の一部を Mac 用に GoogleDrive へ mirror した領域 (Sync-ToGDriveMirror.ps1)。Mac vault が GD_Mirror 経由で読み取り、編集は母艦に集約。
📚 用語解説 — explicit_only: ユーザーが明示的に「この source からこの target へ」と指示した時のみ AI Agent がアクセスする ai_policy。デフォルトは禁止。
🛠️ 運用方法: (1) _System/00_Config/source_registry.yaml + _System/00_System_Docs/260510_cross_drive_guard.md をセッション冒頭に読む (2) Context Pack を作る時は source_domain frontmatter 必須 (3) work データを private へ手動コピーする時は明示的に確認 + 監査ログ (4) Mac sync は GD_Mirror 経由 (Sync-ToGDriveMirror.ps1) のみ
⚠️ アンチパターン: AI Agent に「全部 GoogleDrive に backup して」と曖昧に指示 → work データの個人領域への越境。Context Pack に source_domain を書かない → 後から「これは work? private?」が判別不能。OneDrive ↔ GoogleDrive の自動 sync ツール (rclone 等) を仕事領域で使う → 機密漏洩リスク。
結論
- OneDrive root → 000_RC → 00_Inbox + 01_Projects の三層構造で仕事 OS を構築、AI Agent は source_registry 経由で安全にアクセス。
- 00_Inbox = Active Command Center / 01_Projects = Source of Truth (動かさない) / Bridges = 意味の橋 の役割分担で「物理を動かさず Platform 側に意味の橋を作る」を実現。
- Cross-Drive Guard で母艦 Windows の統合ノードリスクを制御、source_domain 明示 + explicit_only ポリシーで機密境界を守る。