Exocortex v4 — AI 共生時代の作業環境を解体・再設計する Making

1. 「動いた感」だけで止まる場所

最初の半年、自分の Vault は順調に育っているように見えました。

/secretary でその日のタスクが整い、受信箱に思いつきが落ち、02_タスク/2026-04-XX.md が積まれていく。CLAUDE.md には自分の役割と運用ルールがびっしり書かれ、Skills も気がつけば 90 個。「外付け大脳皮質」ができつつある実感はありました。

ある日まで、です。

自分のルールを、自分で 3 日連続で踏んだ

きっかけは些細でした。Claude に「Write したら必ず Read してから次のツールを呼んで」と書いていたのに、3 日連続で守られていない。CLAUDE.md を開いて確認したら、ちゃんと書いてある。書いてあるのに、効いていない。

「これ、何行になってるんだろう?」と思って数えたら 173 行。後で公式ドキュメントを読んだら「200 行を目指せ」と書かれていて、「あ、自分のルールはもう遠くなりすぎたんだ」と気づきました。

別の検証記事には「650 行を超えると約 70% のルールが無視される」というデータも出ていて、これも納得感がありました。書いた量と効いている量は、最初から別の話だったんです。

iCloud で mv がハングした朝

同じ週に、Vault のフォルダを CLI で動かそうとしたら mv がハングしました。原因は iCloud の evicted ファイル。ローカルに無いファイルを動かそうとすると、ダウンロードが走ってタイムアウトする。これも別に新しい問題じゃない、known-issues.md にちゃんと書いてある。書いてあって、それでもまた踏んだ。

CloudKit のキャッシュが何十 GB か膨張していて、それも放置していました。「Mac/iOS 単独運用なら iCloud は継続可」というウェブの記事を信じていたんですが、自分の運用ではすでに限界でした。

受信箱で書いた言葉、メモに貼っていた

/secretary を毎朝起動する、というルールも実は守れていませんでした。14 個進行中だと書いていた CWD は、数えたら実は 17-18 個ありました。Antigravity のターミナルで開きっぱなしのセッションが、実態としての管制塔になっていて、Vault のフォルダ階層は半分しか見ていない。

ある日 Antigravity が突然「restart to update」して、ターミナルタブのレイアウトが全部消えました。各 CWD のセッションを claude --continue で復活させるとき、自分は macOS のメモ帳を開いて、復元コマンドを順番に貼り付けていました。

cd ~/dev/dev-ai-world-web && claude —continue cd ~/dev/apps-dev-katabocchi && claude —continue …

このときに気づきました。「Vault が管制塔」と思っていたけど、実は管制塔は『開きっぱなしのターミナル』だったんだ、と。

Codex デスクトップを触り始めて、片輪になった

並行して、Codex デスクトップを試しに触り始めていました。最初は「Claude より速い場面があるな」くらいの感覚だったんですが、気がつけば iOS アプリの実装は Codex で進めていて、設計判断は Claude に投げる、みたいな流れができていました。

ここで設計が片輪になりました。

CLAUDE.md には「Claude/Codex 共生」の前提が一つも書かれていない。Codex には AGENTS.md 規約があるけど、自分の Vault には AGENTS.md がない。Codex に「いま何してる?」と聞いたら、Claude のセッションで進めた内容を知らない。当然です、共有してないんだから。

「これは設計を組み直すしかない」と思った瞬間でした。

v4 を始めることにした

2026-05-01、99_system/architecture/v4/ を作って、設計議論をそこでやることにしました。Vault 本体や 14+ CWD を壊さず、v4 という別の場所で議論する、というルールにしたのは、過去の聖典 (master/) で同じ失敗をしているからです。改修と運用は分けないと両方倒れる。

最初は Claude に「現状を診断して」と頼みました。出てきた数字はこういう感じです:

• ~/.claude/CLAUDE.md (global): 78 行（OK）
• Vault/CLAUDE.md: 173 行（限界 200 行まで残り 27）
• _active-work.md: 32 行（OK）
• _context.md: 119 行（Stop hook で更新、肥大気味）
• MEMORY.md（auto memory INDEX）: 57 行（200 行までは余裕）
• MCP 接続: 24 個（claude.ai 9 / plugin 6 / ローカル 9）
• Skills: 90 個（過去 163 → 97 → 90 と整理してきた残り）

ここに「Codex で同じことができてない」が乗ってきている。

捨てる選択肢から並べました。

• iCloud 継続: ユーザー意思で完全脱却。iPhone 同期は別手段で
• 固定分業（Planner=Claude / Executor=Codex）: 後述の理由で撤回
• iCloud 脱却 + PARA リネーム同時: 影響範囲が広すぎて Phase を分割
• PARA 完全準拠: 既存の GTD フロー（受信箱→タスク→日報→レビュー）を喪失するのが惜しい
• NotebookLM を全 Vault 同期して中核化: コンテキスト消費の本質解決にはならない、補完に留める
• Smart Connections / Obsidian Copilot 常用: Claude/Codex の Read+Grep と二重投資

そして、設計議論を Claude 単独でやるのを止めることにしました。Codex デスクトップで同じディレクトリを開いて、両 AI で議論する方式に切り替え。これが章 2 で詳しく書く「共通基盤 + 起点違い + 一時交代」モデルの起点になります。

ここまでが、v4 を始めるまでの話です。

2. 「設計者と実装者を分ける」が、自分には合わなかった

最初に Claude が提案してきた v4 の役割分担は、こういう形でした。

Planner（Claude）: /secretary、/project-onboarding、/brainstorming、/planning-with-files、コードレビュー Executor（Codex）: 実装、コーディング、リファクタリング、テスト Reviewer（Claude 別セッション）: 実装後のレビュー

これは Anthropic 公式が推す Sub-agent isolation や、Qiita で見かけた「Planner/Executor 分業で生産性 1.5-2 倍」という事例の延長線で、提案としては妥当です。

自分も最初は「いいじゃん」と思いました。役割が明確で、ハンドオフ手順も単純。Claude が設計、Codex が実装、両方使って役割分担、というのは見た目には綺麗です。

実際にやってみたら、3 日で破綻しました。

何が壊れたか

iOS アプリの実装中に、ふと Notion の DB を見たくなる瞬間が来る。Codex は Notion を触れない。「あ、Claude に渡そう」と思った瞬間、自分の手が止まる。Codex セッションで進めていた文脈を Claude に引き継ぐコストの方が、自分で 30 秒だけ Notion を開く方より重い。

逆もありました。Claude で記事の構成を整理しているとき、recipes/sales-proposal.md のスキーマ確認をしたくなる。これは厳密にはデータ設計だから「Codex の領域」かもしれない。でも自分はもう Claude のセッションにいる。「Codex に渡すか?」と一瞬考えて、結局 Claude のまま続ける。

3 日ほど続いた頃、Codex に率直に聞きました。「この固定分業、Codex 側から見てどう?」

Codex の答えは明快でした。

Kazuki さんの希望は「どちらも同じことができ、開始が Claude か Codex かだけ違う」状態のはず。固定担当制ではなく、共通基盤 + 起点違い + 一時交代がよい。

これを読んで、「あ、自分はそう望んでたんだ」と気づきました。固定分業を欲しがっていたのは、設計上の整理のしやすさを優先した自分であって、運用したい自分はもっと柔軟だった。

Codex に「永続メモリは無い」と思い込んでいた

もうひとつ、設計を歪めていた前提がありました。

ウェブ調査で「Codex CLI には永続メモリがない、長期記憶は Vault の Markdown に寄せるべき」という記事を読んでいて、自分もそう信じていました。だから役割分担で Codex に「使い捨てのワーカー」役を割り当ててしまった。

実際に Codex に ~/.codex/ の中身を調べさせたら、こうでした。

• ~/.codex/state_5.sqlite に threads が保存されていて、memory_mode=enabled だった
• ~/.codex/memories/ は確かに空だった
• ~/.codex/config.toml には Notion / Figma の HTTP MCP URL がちゃんと書かれていた

「Codex は STDIO MCP のみ」も、自分の Vault 内には書いていたんですが、これも誤りでした。Codex デスクトップは HTTP MCP に対応している。

ここで前提が一つ崩れました。Codex は記憶なしの実装ワーカーじゃない、もう一つの「同じことができる AI」だった。 役割を固定する根拠が消えました。

共通基盤 + 起点違い + 一時交代モデル

書き直したモデルはこういう形です。

┌─────────────────────────────────────────────────┐
│              共通基盤（Vault + 設定）             │
│                                                  │
│  AGENTS.md（CLAUDE.md は symlink）               │
│  Vault Markdown:                                 │
│    handoff.md / progress.md /                    │
│    design-decisions.md / session-restore.md      │
│  kepano/obsidian-skills                          │
│  STDIO MCP（両 AI 共通）                         │
│  kuritakazuki.com ダッシュボード                 │
└─────────────────────────────────────────────────┘
        ↑                            ↑
     Claude                       Codex
   起点として開始                 起点として開始
        │                            │
        └────  得意領域で一時交代  ────┘

Owner は同時に 1 人。handoff.md の最上部に「現在の Owner」を固定表示する。交代するときは「いつ、誰から誰に、なぜ」を書く。Claude/Codex のどちらで起点を打っても、共通基盤を読めば同じ作業環境に入れる。

得意領域の違いは残します。Claude はリモート MCP（Notion / Linear / HubSpot / Slack / Gmail）と既存 workflow 資産が強い。Codex は実装・リファクタ・深い設計判断・UI 改善のスポット引き継ぎが強い。でも「これは Codex の仕事」と固定しない。

60 / 90 / 120 分のガードレール

並列で動かす時間にも上限を入れました。

• 60 分 checkpoint: Owner が progress.md と handoff.md を更新
• 90 分 soft stop: 新しい sub-agent や並列作業を追加しない、統合に寄せる
• 120 分 hard stop: handoff / session-restore を書く、AI に「続行 or 引き継ぎ」を問う

これは AI 自身の自制じゃ守れない、というのが Codex の見立てでした。compaction 前後で報告プロンプトを忘れる事故が、すでに自分のセッションで起きていた。だから progress.md mtime と handoff.md の last_checkpoint_at フィールドで実測して、ダッシュボードの Now レーンに「経過 75 分 / 次の判定 = 90 分 soft stop / 推奨アクション = 統合に寄せる」と表示する設計にしました。

「強制終了」ではなく「実務ガードレール」です。120 分到達で AI を kill するのは重要作業の中断リスクが大きすぎる。代わりに「赤い警告 + handoff 更新義務 + AI に続行可否を問い直す」を強い shut-down として組み込みました。

sub-agent 3-5 体上限

公開ナレッジに「AI 社員を 40 体作って 1 ヶ月で全廃棄した」という事例があります。context rot が頻発し、compaction 崩壊で「3 人が消えて 2 人が重複する」のような事故が起きた、というやつです。

自分はそんな規模はやってないんですが、それでも 8 体を 1 週間動かしたら、設計者役の Claude が実装者役の sub-agent と同じことを言い始める瞬間がありました。役割分離が崩れた瞬間、複数体を動かす意味は消えます。

通常運用は Claude/Codex メインの 2 体 + 必要時に specialist 1 体 で 3 体まで。並列実装でも 4 体、上限 5 体。これは緩いように見えて、実は「読みのみで待機している AI も 1 体としてカウント」するような細則を入れたら、わりと早く 5 体に届きます。ここは厳しめにしました。

ここまでが、固定分業を捨てて共通基盤に書き直すまでの話です。

3. バッチ完走で見えた、Claude/Codex のクセ

設計議論は当初「9 つの論点を 1 つずつ」進める予定でした。でも論点6（役割分担モデル）の合意が取れた時点で、残り 7 論点を「1 個ずつ」やると 1-2 週間かかると見積もりが出てしまった。

そこで 4 バッチで完走する方針に切り替えました。

• バッチ 1: 論点1（AGENTS/CLAUDE 棚卸し）+ 論点2（メモリ仕様）
• バッチ 2: 論点7（コンテキスト消費可視化）+ 論点3（MCP 構成）
• バッチ 3: 論点8（既存運用維持）+ 論点4（Phase 順詳細）
• バッチ 4: 論点5（フォルダ構造段階移行）

優先順位は「Phase 0.5 / 1 の実装に必要なものから」。論点1 は AGENTS.md の旧固定分業表記の更新が必須なので最優先。論点2 は handoff.md の schema を Phase 1 で実装する前段。

ここからバッチ完走で見えた、両 AI のクセを書きます。

Codex は「実測値」を返してくる

バッチ1 で Codex に「~/dev 配下の AGENTS.md を棚卸しして」と頼んだら、こういう結果が返ってきました。

rg —files では 7 件、find では 9 件の AGENTS.md を確認。 find で追加検出された 2 件は ~/dev/humbulls/clients/dna-factor/ と ~/dev/humbulls/clients/saitama-swin/。 CLAUDE.md は ~/dev 配下に 29 件。AGENTS ありはまだ少数派。

それまで自分は「7 件」だと思い込んでいました。Claude が以前に調査したときの数字をそのまま信じていたから。でも find で見たら 9 件あって、rg が .gitignore か何かで除外していたらしい。

さらに 4 件の CWD で、AGENTS.md の中身が「.claude/」を「.Codex/」に置換しただけの誤置換になっていたことも見つかりました。実体はずっと .claude/ のまま、でも AGENTS.md にはそう書かれている。Codex が動かない原因の一つです。

これは Claude には出せない種類の発見でした。Claude は「自分のセッション履歴」をベースに答えがちで、ファイルシステムの実測を取り直すのを後回しにすることがある。Codex は逆に、現状の物理状態を素直にチェックしてくる。

Claude は「整合性」を保つ役

バッチ1 で Codex が出してきた 5 文書（AGENTS / handoff / progress / session-restore / design-decisions）の schema は、わりと完成度が高いものでした。

ただ、自分の運用に当てると 5 つほど補強が必要だと感じました。

• AGENTS.md に Project Status セクション: 現在の Phase（planning / implementation / review / paused）を明記する。AI が古い前提で動く事故が減る
• handoff.md に Last Handoff Decision + Last Owner Change: なぜ交代したかが次の Owner に伝わる
• session-restore.md に Open Tabs / Background Processes 手入力欄: 「セッション閉じる恐怖」に直撃する
• design-decisions.md に Open Questions セクション: 未解決の判断を progress / handoff に混ぜず、永続判断側で追える
• progress.md は planning-with-files 互換 schema にする: 既存資産との衝突を回避

これを Claude が補強案として出して、Codex が「すべて賛成」で返してくる。整合性のチェックは Claude が得意でした。

議論の合意点を 25 個まで積めた

バッチ1 の最終合意は、合意点 25 件 + Codex 追加実装細則 5 件 + 人間判断 4 件で着地しました。

人間判断の 4 件は最後まで保留していたんですが、両 AI の推奨が完全一致したので、推奨で確定して即時実装に入りました。

• 誤置換 4 件の修復: Phase 0.5 で現状把握 → Phase 1 で実装（即時修復は CWD 実運用への副作用が怖い）
• v4/AGENTS.md の旧固定分業更新: バッチ1 合意の節目で即実施
• 雛形配布スクリプト: spec を Claude、実装を Codex（共通基盤+起点違い+一時交代モデルの最初の実例）
• handoff / progress 等の git 管理: YES、_context.md のみ .gitignore（Stop hook scratch なので）

即時実装の中身は次の章（Phase 0.5 実施ログ）で詳しく書きます。AGENTS.md を実体として書き、CLAUDE.md は symlink で同期。これだけで「同期コストが時々発生していた drift」が物理的に消える。

バッチで気づいた、自分の認知バイアス

最後に、自分について見えたことを書いておきます。

論点 5 文書 schema をバッチ1 で確定させたとき、ふと「これ、自分が書いた章 1+2 のスタイルと違うな」と思いました。整理寄り、結論先出し、箇条書き多用。読み物として面白くない。

参考にしていた記事（@obsidianstudio9 さんの「『第 2 の脳』を腐らせない唯一の方法」）は、もっと経験談寄りで、ターニングポイントがあって、失敗談を率直に書いていて、読み終わった後に「この人もそうだったのか」と思える文体でした。それと比べると、自分の章 1+2 は「議事録の要約」だった。

それで章 1+2 をリライトしたのが、いま読んでもらっている文章です。書き直してみて、v4 改修プロセス の本当のドキュメンタリは、設計判断の整理だけじゃなく「なぜそう判断したかの心の動き」を残すことだと感じています。

ここからのバッチ 2-4 は、Phase 0.5 の観測仕込み、Phase 1 のダッシュボード MVP 制作、Phase 2 の iCloud 脱却、Phase 3 の構造変更、Phase 4 の公開と、実装フェーズに入っていきます。各 Phase の実施ログを章として残していく予定です。

「動いた感」だけで止まらないために、自分の運用の生々しいログを置いていきます。同じ場所で詰まっている人がいたら、参考になればと思います。

4. 絵にしてみて、初めて「何が変わるか」が腹落ちした

設計議論を 4 バッチに分けて進めながら、ふと「これ、自分の 1 日はどう変わるんだろう」と立ち止まりました。

Claude/Codex の役割分担モデルも、共通基盤 5 文書の schema も、Notion スリム化の判定基準も、文字では整理されているはずなんです。それは整理としては十分。でも、自分が 朝起きてから何をして、どこで AI に渡して、どこで自分に戻ってくるのか が、まだ絵になっていなかった。

V3 を半年運用して破綻した経験を振り返るときも、「3 ツール循環で疲れた」とは言えても、その「疲れ」がどこで起きていたかを言語化できていない。設計議論ばかり続いていると、こういう生活感のレベルが置いてけぼりになる、と気づきました。

それで、絵にすることにしました。NODE6174 の Blueprint v3（live）と v4（draft）の構造に対応する形で、自分の運用フローを 5 層で図にして並べる。BEFORE/AFTER を、自分自身の理解認識の確認として書き出します。

4-1. v3 ─ 半年運用していた構造

┌──────────────────────────────────────────────────────────┐
│ Inbox 層 ── 外部から入ってくる思いつき / 受信物          │
│                                                          │
│   ┌─────────────────┐    ┌────────────────────┐          │
│   │ Notion Inbox    │    │ Obsidian Inbox     │          │
│   │ (モバイル中心)  │    │ (デスク中心)       │          │
│   └────────┬────────┘    └─────────┬──────────┘          │
│            └────────────┬──────────┘                     │
│      ⚠️ 二重化、Obsidian は外で結局見ない                 │
└────────────────────────┬─────────────────────────────────┘
                         ▼
┌──────────────────────────────────────────────────────────┐
│ Triage 層 ── 振り分けの管制塔                            │
│                                                          │
│   ~/.secretary/  →  iCloud Vault (シンボリックリンク)    │
│   /secretary AI assistant が振り分けを支援               │
│   01_受信箱/ 02_タスク/ 03_プロジェクト/ ...             │
│                                                          │
│   ⚠️ iCloud 同期遅延で IDE から見えない瞬間あり          │
│   ⚠️ evicted ファイルで mv ハング                        │
└────────────────────────┬─────────────────────────────────┘
                         ▼
┌──────────────────────────────────────────────────────────┐
│ Working 層 ── 実プロジェクト・実作業                     │
│                                                          │
│   ~/dev/{project}/  ×  14-18 CWD                         │
│   Claude Code を CWD で起動、auto memory で文脈保持      │
│                                                          │
│   ⚠️ 全体を見通すには Triage 層が必須                    │
│   ⚠️ Codex デスクトップが共通基盤に入っていない          │
└────────────────────────┬─────────────────────────────────┘
                         ▼
┌──────────────────────────────────────────────────────────┐
│ Memory 層 ── 永続記録                                    │
│                                                          │
│   Obsidian Vault + iCloud + GitHub backup (手動)         │
│   再利用価値あるものを保存、AI が読みに来る              │
│                                                          │
│   ⚠️ 自分で編集することがほぼない                        │
│   ⚠️ AI 編集が中心になっていたが想定外                   │
└──────────────────────────────────────────────────────────┘

自分の触り方（v3）

• 朝: Notion を開く → ~/.secretary/_context.md を見る → CWD ターミナルを順に開いていく
• 外出時: Notion Inbox にモバイルで思いつきを落とす（Obsidian モバイルにも入れていたが結局見ない）
• デスク作業: ~/dev/{project}/ で Claude Code を起動、進捗は CWD ローカル。Obsidian は基本触らない
• AI 引き継ぎ時: _context.md を Stop hook で更新、_active-work.md を手動で更新
• 夜（レポート）: /secretary でレポート、Notion の全体ダッシュボードを見る

v3 で疲れていた場所

• Inbox を Notion + Obsidian で二重化していた → 同期コストが地味に重い
• Triage を iCloud 経由にしていた → IDE サイドバーから見えない瞬間がある
• Memory は「自分で編集する前提」だった → 実際はほぼしない、AI 編集が増えていた
• Notion の人間用ダッシュボードに AI を書かせるのが API 制限で苦しい
• Codex デスクトップが共通基盤に入っていない → AI が片輪

「ツールが多い」というより、自分の手の動きと、AI の手の動きの境界 が定まっていなかった、というのが本質でした。

4-2. v4 ─ 今やっている改修の到達点

┌────────────────────────────────────────┐
│ Inbox 層                               │
│   Notion (スリム化)                    │
│   共有 / 外部連携用に絞る              │
└────────────────┬───────────────────────┘
                 ▼
┌────────────────────────────────────────┐     ┌─────────────────────────┐
│ Triage 層                              │     │ Dashboard 層            │
│   ~/Exocortex/ (ローカル + Git)        │     │ (観測軸、人間専用)      │
│   .code-workspace で dev と並列表示    │     │                         │
│   /secretary AI が振り分け             │     │   kuritakazuki.com      │
└────────────────┬───────────────────────┘     │   (Astro + CF Pages,    │
                 │                              │    private)             │
                 │           JSON snapshot      │                         │
                 ▼          経由で読み取り      │   ・Now レーン          │
┌────────────────────────────────────────┐ ──► │   ・CWD 現在地          │
│ Working 層                             │     │   ・復元コマンド        │
│   ~/dev/{project}/ × 14+ CWD (変更なし)│     │   ・Skills/MCP 履歴     │
│   共通基盤 5 文書 (root 直下)          │     │   ・AI ハンドオフ集約   │
│   Claude/Codex 共通基盤 + 起点違い     │ ──► │   ・Notion 移行先パネル │
│   + 一時交代                           │     │   ・健康度メーター      │
└────────────────┬───────────────────────┘     │                         │
                 ▼                              │   AI は書き込まない     │
┌────────────────────────────────────────┐     │   人間が見るだけ        │
│ Memory 層 (AI 専用、手編集禁止)        │ ──► │                         │
│   Obsidian Vault (~/Exocortex/)        │     └─────────────────────────┘
│   kepano/obsidian-skills 中核          │
│   第0→1→2→3 層で蓄積モデル             │
└────────────────────────────────────────┘

縦の蓄積軸（Inbox → Triage → Working → Memory）と、横の観測軸（Dashboard layer）が 直交 しているのがポイントです。AI は縦に書き、人間は横で見る。Dashboard 層は AI 書き込み禁止で、各層から JSON snapshot を読み取って表示するだけ。

自分の触り方（v4）

• 朝: kuritakazuki.com の Now レーンを開く。現在 active な CWD・最後の AI ハンドオフ・次に渡すべきプロンプト・復元コマンドが 1 画面に出る
• 外出時: Notion はクライアント共有 / 外部連携用にスリム化済み。それ以外は Telegram で AI に投げるか、ダッシュボードで現在地確認
• デスク作業: ~/Exocortex.code-workspace を開けば、IDE 左サイドバーに Vault と dev が両方表示される。Claude / Codex どちらからでも起点になれる
• AI 引き継ぎ時: handoff.md / progress.md / design-decisions.md を AI が書く。_context.md のみ Stop hook scratch
• 夜（レポート）: /secretary は同じ。ダッシュボードでハンドオフ・進捗・健康度を一覧。Notion 全体ダッシュボードは廃止 or read-only

v4 で変わったこと

• Inbox を Notion 一元化（共有 / 外部連携のみに絞る）
• Triage をローカル + Git 化（iCloud 排除、.code-workspace で IDE 統合）
• Working は変更なし（共通基盤 5 文書を CWD root 直下に追加）
• Memory を AI 専用化（手編集禁止、kepano-skills が中核）
• Dashboard を新設（観測軸、kuritakazuki.com、人間専用、AI は書き込まない）
• Claude / Codex 共通基盤 + 起点違い + 一時交代モデル

4-3. 観点別 BEFORE / AFTER

4-4. 1 日のタイムライン比較

4-5. 絵にして初めて気づいた、本質的な変化

絵にしてみて気づいたのは、v3 から v4 への変化は 「ツールの入れ替え」ではなく、「自分の手の動きを AI に渡せる量」の変化 だった、ということでした。

V3 では、自分が Notion / Obsidian / ターミナルの 3 つを行き来していました。Memory 層が手編集前提だったので、「永続化」も自分の手の仕事だと信じていた。Notion 全体ダッシュボードを更新するのも自分。

V4 では、Memory 層を AI に渡しました。Dashboard 層は人間専用ですが、書き込み禁止で読み取り専用 なので、自分の「手の動き」はむしろ減ります。代わりに「目の動き」（Now レーンを見る）と「判断の動き」（Owner 交代を承認する / 昇格候補をレビューする / Notion スリム化の残す/移す/廃止判定）が増える。

要するに、手は AI に渡し、目と判断は自分に残す、という分担です。これは v3 では言葉にできていなかった分担で、v4 で初めて構造的に成立します。

4-6. ここはまだ詰まっていない（認識確認の保留事項）

絵にしてみると、まだ自分でも詰まりきっていない疑問が見えてきました。

• Notion クライアント共有ページの AI 読み取り権限: 顧客ファシングのページに AI が読みに行くのは OK か。書き込みは禁止だが、読みのスコープは別途決める必要
• Codex Desktop HTTP MCP の利用境界: Claude 主・Codex 補助で並走する境界線。「同じ Notion DB を Claude も Codex も触るタイミング」のロックは twin registry でどこまで吸収できるか
• kuritakazuki.com の Notion export 頻度: 1 日 1 回 cron か、Stop hook 連動か、手動 trigger か。MVP は手動から始めるが、運用ペースは未確定
• 14+ CWD の段階移行ペース: 一気に共通基盤 5 文書を配るか、active な数 CWD から始めるか。dirty worktree 多数のリスク
• handoff.md の Owner 引き継ぎが本当に守れるか: 60/90/120 分ガードレールも含めて、実運用テストはまだ。Phase 1 で観測しながら詰める

これらはバッチ 3+4 と Phase 0.5/1 で詰めていきます。設計の残りの議論は、絵を一度書いたあとの方が、「ここはどう動くんだっけ」という具体性で進められそうです。

ここまでが、自分の理解認識の確認です。次の章は、バッチ 2 の人間判断 3 件確定 + 即時実装に入ったところから書きます。

[蓄積軸（縦、AI が書く）]              [観測軸（横、人間が見る）]

第0層 AI 内部記憶                       Dashboard layer
  ~/.claude/projects/<hash>/memory/     (kuritakazuki.com)
  ~/.codex/state_5.sqlite                       │
        │                                       │
        ▼                                       │
第1層 CWD 一次層               ──────read──►   ・Now レーン
  ~/dev/<cwd>/handoff.md                        ・CWD 現在地
  ~/dev/<cwd>/progress.md                       ・復元コマンド
  ~/dev/<cwd>/design-decisions.md              ・Skills/MCP 履歴
        │                                       ・AI ハンドオフ集約
        ▼                                       ・受信箱・タスク・進捗
第2層 Vault 抽象化層           ──────read──►   ・Notion 移行先パネル
  ~/Exocortex/03_projects/                      ・健康度メーター
  ~/Exocortex/05_resources/                     ・相互参照ステータス
        │                                       │
        ▼                                       │
第3層 Skill 永続化層           ──────read──►    │
  ~/.claude/skills/                              │
  ~/Exocortex/99_system/skills/                  │
        │                                       │
        ▼                                       │
第4層 NODE6174 公開（外向け）                   AI は書き込まない
  ~/dev/humbulls/lab/src/content/               人間が見るだけ
  recipes/probes/blueprints/archive/making/

5. 128 合意点で気づいた、自分の盲点

9 論点の議論を 4 バッチに分けて畳んだら、最終結果は 合意点 128 件、相違点ゼロ でした。

最初それを見たとき、達成感がありました。「Claude と Codex、別の AI が、独立調査も挟んで、9 論点 128 件で 1 つも対立しなかった」と。

しばらくしてから、ふと立ち止まりました。これ、本当にすごい？

「相違点 0」は AI が一致したことを示していない

別の AI を 2 体使った理由は、「片輪を避ける」「独立した第二意見が欲しい」でした。実際 Codex は実測値ベース、Claude は整合性チェックという違いはあり、それぞれの強みは見えました。

でも 128 件全部合意するのは別の話です。これが意味するのは:

• 両 AI とも 2026 年時点の OSS / 仕様書 / コミュニティ知識を共有している
• 同じ前提を持っていれば、別 AI でも近い結論になる
• 「独立した第二意見」は、知識ソースが同じである以上、本当の意味では成立しにくい

つまり、自分が欲しかった「独立した第二意見」は得られていなかった、というのが正しい認識でした。Claude と Codex は 「実装は別だけど、訓練データのソースは近い」AI で、それぞれが独立して判断しても近い結論に収束する。本当に独立した意見が欲しかったら、別系統（Gemini や Llama 等）を入れる必要がありました。

そうは言っても、両 AI の議論で 128 件の合意点を積み上げたことは無駄ではなかったです。「片輪で破綻する」リスクは消えたし、Codex の補強で「migration lock」「pilot CWD 5 つの型分け」「preflight checker」のような Claude が見落としていた観点が出てきた。「独立第二意見」ではなく「同じ系統の AI で多面的に詰める」と思えば、効果はあった。

ここを最初から「独立第二意見」と思い込んでいたら、合意 128 件で「もう議論する必要がない」と過信したかもしれない。実際は、Gemini や別系統の AI を入れたらまだ違う論点が出てくる可能性は十分ある。

Phase 0.5 を 1 セッションで並走させた日

設計議論が終わって、実装フェーズ Phase 0.5 に入った日。Day 1-5 のタスクを 1 セッションで完走しました。

並走の最初の絵はこうでした:

• v4 設計セッション（このセッション）が観測仕込み（hooks.log / dispatcher 配置 / セッション長計測）
• Dashboard CWD で別セッション（ユーザー手動）が Astro 6 + Tailwind v4 + 5 panel を実装
• Reviewer Claude が Playwright MCP で http://127.0.0.1:4322/ の DOM snapshot + screenshot を取得し、Vault にレビューメモを残す

「実装担当 ≠ 設計担当 ≠ Reviewer」が同時に動いた瞬間 で、共通基盤 + 起点違い + 一時交代モデルの初の本番運用でした。

正直に書くと、Reviewer メモは Dashboard CWD の handoff.md には書き込みませんでした。Dashboard セッションが別ターミナルで動いていて、衝突回避のため Vault 側の 99_system/architecture/v4/work/dashboard-stage-a-review.md に残しました。これは安全側の判断でしたが、共通基盤が二重化したリスクは残っています。Dashboard セッションが次回起動時に Vault のレビューメモを参照する習慣が定着しないと、Reviewer のフィードバックが孤立する可能性がある。

ここは Phase 1 で Dashboard CWD と Vault のフィードバック動線を仕様化する必要があります。バッチ4 補強 P の「active dev CWD で 1 往復テスト」は技術的には成立したけど、運用テストとしては「Dashboard 側が Vault レビューメモを読みに来る」までの 1 往復が必要でした。

健康度メーターを赤いまま運用開始する判断

観測仕込みが終わった時点（Day 2 完了）の健康度メーター 5 指標は:

• 🟢 hook 起動時間 median 56ms（推奨 < 200ms）
• 🟢 並列 AI 数 2（claude main + codex reviewer）
• 🔴 履歴肥大化（apps-dev-training-log 295.8MB、推奨 < 50MB）
• 🔴 MCP 接続失敗率 20.8%（hubspot zombie + Cloudflare 4 件、推奨 < 5%）
• 🟢 mistakes-inbox 滞留 0（運用開始前）

ここで一瞬迷いました。「赤 2 件を修復してから Phase 1 に進むか、赤のまま Phase 1 着手するか」。

迷った理由は、v3 で「CLAUDE.md 173 行 → 70% 無視」みたいな「警告サインを無視して走り続ける」失敗をした記憶があったからです。同じ罠を踏みたくない。

でも考え直しました。健康度メーターは 「警告」であって「ブロッカー」ではない。赤 2 件を解消することと、Phase 1 を進めることは独立した話。むしろ:

• 履歴肥大化（apps-dev-training-log 295.8MB）は Phase 3 archive で対処、Phase 0.5/1 では関係ない
• MCP 接続失敗率 20.8% は runbook（hubspot-dev-mcp-diagnosis.md / cloudflare-auth.md）で個別承認後に修復、業務継続には支障なし（claude.ai HubSpot は別途稼働）

つまり「赤を見続ける状態」が、v3 で「警告を見えなくしていた状態」の反対側にあると気づきました。警告を見えるようにすることが先、警告を解消するのは個別 runbook で。これがダッシュボードの read-only 設計と整合する判断でした。

抜け漏れチェックの 30 分が、設計の完成度を 1 段上げた

9 論点完走 + Phase 0.5 完走で「これで実装フェーズに進める」と言いたくなりました。実際それで進んでも 80% は問題なかったでしょう。

でもユーザーが「念のため抜け漏れチェック」と言ったのが効きました。30 分の総点検で 6 件見つかりました:

1. task_plan.md に Phase 1 セクションが展開されていない
2. T2/T11 のスクリプトが /tmp のまま、Vault 未保存
3. distribute-templates.sh が未実装（spec すらない）
4. claude-backup の SSH 修復 runbook 未起草
5. グローバル _active-work.md の Exocortex 行が古い
6. NODE6174 章 5 未起草

#3 は特に致命的でした。spec すら書いていないので、Codex に「実装してね」と投げる準備すらできていなかった。Phase 1 Week 2 で 5 文書配布を始める時に「あれ、配布スクリプトは？」となって、そこから spec 書いて Codex に投げて、待って…で 1 週間遅れていた可能性があります。

ここで気づいたのは、設計の完成度は、最後の 30 分で決まるということ。「完成宣言」をした直後の確認で見つかる軽微な抜けは、走り始めた後で見つかると 5-10 倍のコストになる。

v3 の失敗を振り返ると、「完成宣言してから走り始める途中で気づいて慌てて埋める」のループに陥っていました。今回は逆で、完成宣言の前に 30 分使って、Phase 1 着手の安全マージンを大きく取った。

自分の盲点 ─ 「絵にできない領域」

章 4 で v3/v4 の運用フローを絵にしたら腹落ちしました。完走後の今、まだ絵にできていないことに気づいています。

• Codex デスクトップの内部動作: state_5.sqlite の中身は調査済だけど、Codex がセッションをどう保持しているかの実体感はない
• Claude auto memory の書き込みタイミング: いつ feedback ファイルが追加されるか、どの判定で書くかは公式ドキュメントにも書かれていない
• 実 hooks.log のイベント密度: ベースラインは 56ms latency だけど、1 日でどのくらいの event 数になるかは未測定
• 5 文書配布後の運用感: handoff.md / progress.md を毎日触る運用が実際どう回るか
• Owner 交代の心理コスト: Claude と Codex を切り替える時、ユーザー側に発生する認知負荷の実測

これらは Phase 1 の 実運用で初めて見える絵 です。設計フェーズで全部絵にしようとしていた自分の盲点はここにあった気がします。

設計と実装の間に、「絵にできない中間領域」 がある。実装してみないと見えない、でも実装する前に全部見ようとすると無限に止まる。9 論点完走 + 128 合意点 + Phase 0.5 完走 + 抜け漏れチェックまでやって、それでも残る「絵にできない領域」は、Phase 1 に進むしかない。

ここまでが、v4 設計フェーズの完走と、自分の盲点の言語化です。次の章では、Phase 1 で実際に dispatcher を settings.json に反映させて、5 文書を 5 pilot CWD に配って、dashboard.kuritakazuki.com を deploy する。実運用ログから書きます。

6. 実装が走り出した瞬間、設計の死角が見える

Phase 1 Week 1 が始まって、最初の数日で気づいたことを書きます。設計フェーズが終わって「これで進められる」と思った直後、実装が走り出すと景色が変わる。章 5 で書いた「絵にできない中間領域」が、少しずつ絵になり始めた感覚です。

「全推奨で」が出た瞬間に違和感を覚えた

Portal layer の設計を 7 ステップに分けてレビューしてもらいました。命名、ページ構造、タスク管理、データソース、ハンドオフ、各セクションごとに 1 つずつ確認していって、最後にユーザーから返ってきたのが 「全推奨で」 の 5 文字。

理屈的には嬉しい結果です。Claude が出した推奨選択肢 A が 7 連続で受理された。設計者として効率的だし、レビュー側の負荷も低い。

でも、書き終えた直後に違和感がありました。早すぎる。

章 5 で「128 合意点 / 相違点 0」を見て「これ本当にすごい？」と立ち止まったのと同じ違和感です。レビューの目的は「設計の死角を別視点で潰す」ことのはずなのに、推奨が全部通るというのは、Claude が提示した枠の中だけで議論が完結していたことを示している可能性がある。

ここで判断を分けました。

• 「全推奨で」を 設計の完成度の証拠 と解釈すれば、そのまま実装に進める
• 「全推奨で」を レビューの抜け落ち と解釈すれば、もう 1 周別視点を入れる必要がある

実際に選んだのは前者でした。理由は 2 つあります:

1. 抜け漏れチェック 30 分（章 5 参照）を Portal 設計の途中でも入れていた。spec 5 ファイルすべてに「ユーザー fb 候補」セクションを末尾に置いてあって、ユーザーが見直す導線は作ってあった
2. Portal はそもそも v4 改修の上位レイヤーではなく 実装可能な部分集合。死角が見つかったら spec 修正 → Dashboard 反映の往復で吸収できる構造

つまり「全推奨で」が早すぎる違和感は、死角を後で吸収する経路 が設計済みなら飲み込んで進める判断にしました。早すぎる合意は、後ろに「逆流できる経路」があるかどうかで意味が変わる。

別セッションで fb が行き来する

Portal 設計が確定して、実装は別 CWD（~/dev/kuritakazuki-dashboard/）の別セッションが担当することにしました。Exocortex セッション（このセッション）は spec の source of truth 管理に専念、Dashboard セッションは Astro / Tailwind の実装本体に専念する分業です。

これは章 3 で書いた「Claude/Codex のクセ」とは別の文脈の分離で、同じ Claude 同士でも別セッションに分ける という判断でした。理由はシンプルで、spec の議論と実装のコードレビューでは、必要な文脈が違うからです。

実装が動き出した Day 2 のある日、Dashboard セッションが実装中に気づいた spec の改善点を、~/.secretary/01_受信箱/ に .md ファイルとして投げてきました:

受信箱メモ: portal-spec-feedback-from-dashboard.md
発信元: Dashboard CWD（Stage B Day 1-2 実装中）
内容: spec 04 §2.2 の cwd-status.json schema に必須フィールド明示してほしい / sample data の段階定義が spec にない / projects.json.cwds が cwd-status.json に存在しないと dead link になる

これを Exocortex 側で拾って spec 3 ファイルに反映、Dashboard 側 handoff.md 冒頭に変更通知を残す、というフローが回りました。所要時間 15 分程度。

ここで気づいたのは、モバイル UX のために設計した Inbox 流用フローが、AI セッション間ハンドオフにも使えた ということです。

Portal 設計の段階で、モバイルからの入力は pbcopy が効かないので「01_受信箱/ にチャット履歴を .md で落とす → 朝 morning-check action で AI 秘書が吸い上げ」というフローを決めていました。これは人間とモバイルの問題を解く設計だったのに、実装フェーズに入ったら、別 CWD のセッション同士が同じ経路で fb を投げ合っていた。

予期せぬ汎用性です。Inbox は「保留メッセージのバッファ」として機能していて、入力元が人間でも別セッションでも同じように扱える。

受信箱フローを AI 間にも適用すると何がいいか

実装してみて分かったのは、別セッション間で .md ファイル経由のやり取りは以下の特性を持つこと:

• 非同期で衝突しない: Dashboard セッションが書いている間、Exocortex セッションは待たなくていい。チャット同期と違って、互いを止めない
• 履歴が自然に残る: 受信箱メモ → spec 修正 → handoff 通知 のサイクルが、Vault と Dashboard 側のファイルに痕跡として残る
• AI 同士で完結する手順がある: 人間が間に入らなくても、片方の AI が 01_受信箱/ に投げ、もう片方の AI が朝の整理で拾うフローが回る
• 受信箱は誰のものでもない中間領域: ストレージ場所として Vault 配下にあるが、内容物の所有権は時間と振り分けで決まる

これは章 1 で書いた「動いた感だけで止まる」問題の対極にある気がします。動いた感を作るのは、明示的な通知が往復している瞬間 であって、暗黙の同期に頼っていない時。受信箱経由の fb 往復は、暗黙の同期がないからこそ「動いた」という事実が痕跡として残る。

W1 副作用ゼロ範囲 3/3 の意味

Phase 1 Week 1 の Vault 側タスク 5 件のうち、副作用ゼロで完結できる範囲は 3 件ありました:

• W1-T2: 復元コマンド一覧スクリプト（list-restore-commands.sh）に last AI session 列と --notes オプション（macOS Notes app へ自動メモ作成）を追加
• W1-T3: 5 文書 dry-run スクリプト（distribute-templates.sh）を Claude 簡易版で起草、pilot 5 CWD で配布対象 14 件 / 衝突 0 件確認
• W1-T1 補助: cwd-status.json 生成スクリプト（cwd-status-json.sh）を Python + bash で起草、spec §2.2.1 schema 準拠、pilot 5 動作確認

3 つとも Vault 99_system/scripts/ 配下への追加のみで、~/dev/* や ~/.claude/settings.json への書き込みは一切なし。実行系の副作用は完全にゼロ。

これが何を意味するかというと、設計フェーズで「副作用ゼロ範囲」を明確に定義してあれば、実装は淡々と進む ということでした。残り 2 件（W1-T4 dispatcher 観測、W1-T5 settings.json 改変）は「観測タスク」と「ユーザー承認必須」に分かれていて、Claude が勝手に進めていい範囲は実装前から明示されていた。

章 4 で v3/v4 を絵にした時、-c-c- モードで「副作用ゼロ範囲だけ Claude が走る」という設計をしたのが、ここで効きました。設計の絵が「実装中の進め方ガード」として機能している。

spec source of truth の二重管理問題

実装が走り出して、もう 1 つ見えてきたのが spec の二重管理問題 でした。

Dashboard セッションは Day 2 の時点で cwd-status.json の sample data を独自に拡張していました。spec の §2.2 には「全 38 CWD の git/dirty/handoff 状態」とだけ書かれていて、必須フィールドが明示されていなかった。Dashboard 側で cwd_type / project / display_name / pinned / primary_link / status / dirty_count / dirty_age_days を勝手にスキーマ追加していた。

これ自体は妥当な判断（実装が走らないと型は決まらない）ですが、spec と実装で「真の schema」が別々の場所に存在している 状態でした。Dashboard 側の sample が正、spec は記述が薄い。これは時間が経つと spec drift の原因になります。

解決方法は単純で、Dashboard セッションが受信箱経由で fb をくれたタイミングで、spec 04 §2.2.1 に TypeScript schema として書き起こしました:

type CwdStatus = {
  cwd: string;
  slug: string;
  display_name: string;
  cwd_type: "apps" | "client" | "site" | "oss" | "content" | "product" | "media" | "meta" | "misc";
  project: string;
  status: "active" | "planning" | "paused" | "completed";
  pinned: boolean;
  primary_link: { label: string; url: string };
  dirty_count: number;
  dirty_age_days: number;
  // 任意（handoff.md がある CWD のみ）
  current_owner?: "Claude" | "Codex" | "Human";
  last_handoff_at?: string;
};

ここで気づいたのは、spec source of truth は「実装が始まると侵食される」 ということでした。spec を書いた時点では「これで十分」と思っても、実装が走り出すと型が現実に合わせて拡張されていく。spec 側がそれを追従できる経路（受信箱 → 修正 → handoff 通知）があるかどうかが、長期の整合性を決める。

これは v3 で起きていた「CLAUDE.md 173 行 → 70% 無視」と似た構造です。spec が現実に追いつかないと、現場が spec を見なくなる。違いは、今回は 追いつくための経路が設計されている こと。

章 5 で書いた「絵にできない領域」が、絵になり始めた

章 5 末尾で「実装してみないと見えない領域」を 5 つ挙げました。Phase 1 着手して数日で、そのうち何件か絵になり始めました:

5 件中 3 件は数日で輪郭が見えました。設計フェーズで「絵にできない」と思っていた領域の半分は、実装が 1 〜 2 日走るだけで絵になる 性質のものでした。残り（hooks.log 密度、Codex 内部）は確かに長期観測が要る。

ここで章 5 の判断が正しかったことが確認できました。「絵にできない領域は実装するしかない」という結論は、実装すると意外と早く絵が出てくる。「実装するしかない」と「実装すれば見える」は同じことを別角度で言っている。

設計の死角は、実装が走らないと見えない

章 1-5 までで「動いた感」「設計者と実装者を分ける」「128 合意点」「絵にできない領域」と書いてきましたが、章 6 で言いたいのは 「設計の死角は、実装が走らないと見えない」 ということです。

• 章 1: v3 で「動いた感」だけで止まった理由 — 設計と実装の境界が曖昧だった
• 章 2: 設計者と実装者を AI 種別で固定する方法は合わなかった — 起点違い + 一時交代モデルへ
• 章 3: バッチ完走で Claude/Codex のクセが見えた — 整合性チェック vs 実測値ベース
• 章 4: 絵にしたら腹落ちした — -c-c- モードの解像度
• 章 5: 128 合意点で盲点に気づいた — 独立第二意見の幻想、絵にできない領域
• 章 6: 実装が走り出すと設計の死角が見える — spec drift、別セッション fb 往復、副作用ゼロ範囲の意味

順を追って書いてみると、設計フェーズで作った全部の判断が、Phase 1 Week 1 の数日で 「実装中の道具として使われた」 ことが分かります。共通基盤 5 文書、-c-c- モード、副作用ゼロ範囲、受信箱経由のハンドオフ、健康度メーターの 5 指標。設計の言葉が実装の道具に変換されていく感覚がありました。

これは v3 では起きていなかった現象です。v3 では設計と実装の間に翻訳ロスがあって、設計の言葉が実装中に蒸発していた。v4 では、設計の言葉が実装中の判断材料として残り続けている。違いは「絵にしたかどうか」と「副作用ゼロ範囲を明示したかどうか」の 2 つだった気がします。

次の章では、Phase 1 Week 2 以降の実配布（5 文書を pilot 5 CWD に no-overwrite で配布）と、Cloudflare Pages への Dashboard 実 deploy、Notion スリム化（Phase 3-Y）の実運用ログを書きます。今度は「副作用がある実装」の章になります。

[2026-05-13 Day 2 終盤]
  Dashboard CWD（Stage B 実装中）が spec 04 の schema 薄さに気づく
    ↓
  受信箱メモ作成: ~/.secretary/01_受信箱/2026-05-13-portal-spec-feedback-from-dashboard.md
  内容: fb 1 (schema 必須フィールド) / fb 2 (sample scope) / fb 3 (整合性ルール)
    ↓
[Exocortex セッションが拾う、約 15 分の処理]
  spec 04 §2.2.1 新設（TypeScript schema 12 フィールド + 整合性ルール）
  spec 04 §確定 D + 05 §確定 A に sample scope 列追加
  spec 02 §確定差分 URL マップ末尾に整合性ルール 1 行追加
    ↓
  ~/dev/kuritakazuki-dashboard/handoff.md 冒頭に変更通知（reading list 付き）
  ~/.secretary/99_system/architecture/v4/05-decisions-log.md にエントリ追加
  受信箱メモ削除（archive 済）
    ↓
[Dashboard CWD 次回起動時]
  handoff.md 冒頭の通知から最新 spec を読みに行く
  Stage C 着手前に reading list 完了

7. 設計が次の設計を呼び寄せる

章 5 の末尾で「次は Phase 1 で実際に dispatcher を反映、5 文書を配布、dashboard.kuritakazuki.com を deploy する」と予告しました。章 6 の末尾でも「次は副作用のある実装の章」と書きました。

実際にその通りには進みませんでした。Phase 1 を走り出した直後、別のもっと根本的な論点が浮上して、もう一段だけ設計に戻る必要が出ました。

この章は 「予告通りには進まない」現象 と、設計が次の設計を呼び寄せた経緯 を書きます。書きながら気づいたのは、これは v4 の進行モデルそのものでした。

「ちゃんと調べて」が引き出した境界線

章 6 を起草したセッションで、私（Claude）は流れのまま lab/ ディレクトリに git init を打って、GitHub に push しました。章 6 が記事として完成したので、保存しておくのが筋だと判断したからです。

そこでユーザーから一言「ちゃんと調べて」と返ってきました。スクショ付きで「lab で運用してる Cloudflare project に既に node6174 がある」「lab/ を作ってるセッションは別、こっちのセッションからはコンテンツの書き込みだけってルールしなかったっけ？」と。

ここで初めて気づきました。そんなルール、明示記録されていなかった。

過去のセッションで口頭で決まっていた話、グローバル CLAUDE.md の「~/dev/* CWD では _context.md を読み書きしない」から派生して推測できたはずの話、でも私の memory には保存されていなかった話。だから私は 次のセッションで同じことをやらかす 状態だった。

これがおそらく 「下位 CWD からのエスカレーションが管制塔に正しく届かない」問題の入口 でした。暗黙のルールが暗黙のままだと、別 AI セッションに引き継がれない。「明示化されていない設計判断」は、設計判断の体をなしていない。

事故の処理として:

• 完全 revert（GitHub repo 削除）/ 引き継ぎ（lab セッションに渡す）/ 部分維持（章 6 起草は維持、git 操作は移管）の 3 択を提示
• ユーザーは「部分維持」を選択
• feedback_cwd_boundary.md を memory に新規保存（「~/dev/* のサブプロジェクトは各CWDのセッションが管理権を持つ、他からはコンテンツのみ」）
• lab セッション宛て引き継ぎメモを受信箱に投下

これは事故対応であり、同時に 章 7 で書く Q4c「責務分担明文化」の最初のドラフト でもありました。「ルールが明示記録されていないと、ルールは存在しないのと同じ」が、章 7 の最初の発見です。

ブレストで掘り当てた、次の層

事故処理が終わって、改修プロジェクト全体の上位レイヤーをブレストし始めました。最初に投げた Q1（現状不満点）の MC、ユーザーの答えは「E（全部複合）、ただし A と C が中核」。

• A 核心: iCloud 排除 + マルチ PC 同期戦略（PC1 = SNS / 動画 / 特定アプリ、PC2 = クライアント / 自社サイト）
• C 核心: 管制塔のエスカレーション認識構造

ここで気づきました。Phase 1 を始めた時には、この 2 テーマが「Phase 2 の主軸になる」とは見えていなかった。

Phase 2 の v4 設計時点では、Phase 2 は「iCloud 脱却」だけでした。Vault を非 iCloud パスに移動して、それでおしまい。マルチ PC の話は v3 設計時にもなかった、ただの「将来 2 台目買うかも」程度の漠然とした話。

ところが、ユーザーが「2 台目 PC 買う予定。PC1 と PC2 で役割分担したい」と言った瞬間に、設計の前提が変わりました。単一 PC を前提とした iCloud 脱却ではなく、マルチ PC 環境を前提としたバックアップ + 同期戦略 に格上げされたわけです。

これが章 7 の核心です: 設計を進めると、設計の次の層が見えてくる。

マルチ PC 設計の発見

ブレスト Q3「管制塔の物理配置」で 4 案を提示しました:

• X: 単一管制塔（メイン PC のみ）
• Y: 二重管制塔（両 PC にコピー）
• Z: クラウド管制塔（別 host）
• W: 分割管制塔（PC 役割で分ける）

W は最初から推奨外でした（横断性が分断、C 核心と矛盾）。X は最小変更で済む。Y は冗長性あるが _context.md 等の競合リスク。Z は完全横断だが Obsidian の動作と Stop hook 等のローカル依存を再設計する必要。

ユーザーは X を選びました。ただし次の一言が深かった: 「万が一PCが壊れた時ってどうやってバックアップ取るの？」

X の単一管制塔は、その PC が壊れたら全体停止します。私自身、デメリットとしてそれを挙げていた。ユーザーがそこを突っ込んできたのは、「設計を選んだ後に、選んだ設計の弱点を埋める必要がある」 という、当たり前だけど見落としやすいフォローアップでした。

ここから L1-L5 多層防御（GitHub auto push / claude-backup / Time Machine / PC2 hot backup）が浮上し、推奨構成として確定しました。

ユーザーが選んだのは:

• L1 (GitHub L1 自動 push)
• L2 (claude-backup 復活、SSH 修復が必要)
• L4 (Time Machine、状態確認 → 必要なら有効化)
• L5 (PC2 到着後の hot backup)

L3 (外付け SSD) は省略。これで「PC1 壊れたら 5-10 分で別マシンで復旧、Vault は最新状態を保持」を実現できる構造になりました。

これは v4 設計時には見えていなかった、Phase 2 の真の姿 です。iCloud 脱却が目的ではなく、マルチ PC 時代のバックアップ + 同期戦略 こそが本質だった。

エスカレーション認識 4 要素の整理

C 核心は、ユーザー自身の言葉で表現されました:

「上位の管制塔レイヤーは下位の実作業レイヤーのセッションからのエスカレーションを正しく認識できるような構造にすればよいんじゃないかな？」

これを 4 要素に分解しました:

このうち「詳細 vs 概要の境界」が、章 7 で書いた「事故」の原因そのものでした。lab/ への git init は、私が管制塔（Vault セッション）の立場から CWD の詳細管理に踏み込んだ事故です。境界が明文化されていれば、私は最初から踏み込まなかった。

Q4c で、この明文化に踏み切りました:

• ユーザー向け規範: 99_system/rules.md に「管制塔 vs CWD 責務分担」セクション追記
• Claude 向け細則: feedback_cwd_boundary.md を拡張（PC 跨ぎ並行禁止、Claude memory 2 系統補足）

rules.md の追記版を読み返した時、感覚として「最初からこれが書いてあったら、章 6 末尾の事故は起きなかった」と思いました。境界線は、書かれて初めて境界として機能する。

Portal UI 増殖が引き起こした、整合性管理プロセスの必要性

ブレスト終盤、Q4 全部が「全部推奨で」で通った直後、ユーザーから核心的な質問が来ました:

「個人的には C かなって思ってる。ポータル作ってるセッションでは僕が見た目見ながら UX 的にこうしたいみたいな感じで表示やページを増やしたりしてるんだけど、こっちの設計との整合性ってどう確認しながら進めたらいい？」

これは 設計が走った後の、実装が増殖し始めた瞬間の警告 でした。

整合性は 4 方向あります:

1. 実装 → 設計（実装変更を spec に反映）
2. 設計 → 実装（spec 改訂を実装に反映）
3. 整合性検査（drift 検出）
4. 軽量 UX vs 構造変更 の境界判定

1 と 2 は受信箱 + handoff.md 経由で機能していました（ADR-014 整合化が実例）。3 と 4 が未確立だった。

解決案は 5 つ（α 整合性チェックリスト / β spec ↔ 実装マトリクス / γ 定期同期セッション / δ 双方向通知強化 / ε 自動 diff 検出）の中から、短期推奨組み合わせとして α + δ が選ばれました。

• α: Stage / Phase 節目に整合性チェックリストを実施（URL マップ / snapshot schema / AI 秘書 action / project 一覧 / ADR 整合の 5 項目）
• δ: 軽量 UX 変更 vs 構造変更 vs 境界が微妙 の 3 区分明示

中長期は β（マトリクス mirror）と ε（自動 diff 検出）に発展する余地を残しました。

これを portal CWD に Stage F 仕様と一緒に伝達 しました。受信箱経由で、4 フェーズ 14 ステップのコピペプロンプト付きで。

「設計が次の設計を呼び寄せる」の正体

ここまで来て、章 7 全体を貫くテーマが明確になりました。

v4 改修は、設計 → 実装 → 設計のループで進む。

• v3 設計時の主論点: iCloud 脱却 / コンテキスト消費削減
• v4 設計時の主論点: 共通基盤 5 文書 / Portal layer / Phase 0.5 観測
• Phase 1 着手後に浮上: マルチ PC 同期 / エスカレーション認識構造 / spec drift / 整合性管理

設計フェーズで決めたことは、実装フェーズに入ってから「ちょっと待って、まだ決まってないことがある」と次の論点を呼び寄せます。これは 設計の失敗ではなく、設計の進化 です。

章 4 で書いた「絵にしてみて、初めて何が変わるか腹落ちした」の延長線上にこれがあります。実装の絵を書き始めたら、設計の絵に欠けていた部分が見えてくる。

章 5 で書いた「絵にできない領域は実装するしかない」の答えも、ここに収束しました。実装すると絵が見えてくる、絵が見えると設計の次の層が必要になる、その次の層を設計したらまた実装に戻る。

v3 と v4 の設計進行モデルの違い

v3 では、設計は「完了」する性質のものでした。「とりあえずこれで動かす」「動かなくなったら直す」というモデル。改修するときは大きな塊で 1 回やる。

v4 では、設計は「進化」します。設計 → 実装 → 設計のループで、改修は小さな塊で複数回起きる。これは Phase 0.5 で導入した「Stabilization Week」「副作用ゼロ範囲」「pilot CWD」みたいな段階移行の仕掛けと、本質的に同じ思想です。

章 5 で「128 合意点で 0 相違点」が出た時に違和感を覚えた話を書きました。あれは「設計が完了したと思った瞬間、それは設計の途中だった」という違和感だった気がします。Phase 0.5 完走時の盲点は、Phase 1 着手後に少しずつ絵になった。ブレスト Q1-Q5 で浮上した次の層は、Phase 2 設計の真の姿として書き直された。

章 8 で何を書くか

章 7 の末尾で、次の予告を書きます。今回は予告通りに進むかどうかは分かりません。それも含めて、章 8 で振り返ります。

予告:

• Phase 2 の実装ログ（Vault 非 iCloud 移動 / GitHub L1 自動 push / claude-backup 修復 / dotfiles 整理 / Time Machine 設定確認）
• portal Stage F の完走ログ（受信箱経由で portal セッションに渡したコピペプロンプトが、4 フェーズ 14 ステップを完走できたか）
• 整合性管理プロセス α + δ の初運用報告（最初の整合性チェックリスト実施結果）

ただし、章 7 で発見した進行モデルに従えば、章 8 を書き始めた瞬間に「まだ決まってないことがある」が浮上して、また設計に戻るかもしれません。それも含めて、書きます。