← 全てのメイキング
進行中 // Exocortex 2026-05-01 → 進行中

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

半年運用した個人 Vault + Claude Code が「動いた感」だけで止まり始めた話。Codex デスクトップを併用し始めた瞬間に設計が片輪になり、組み直すしかなくなった経緯と、共通基盤 + 起点違い + 一時交代モデルへの収束を実時間で記録します。

0/3 章 完了
project-exocortex type-making Claude Code Codex blueprint

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 の実施ログを章として残していく予定です。

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