Exocortex v4。半年動かしてきた自分の「第二の脳」を解体して、Claude と Codex が同居できる形に組み直した記録

半年動かしてきた自分の作業環境を、いったん解体して組み直しています。まだ終わっていないので、決まったところと迷っているところが混ざったまま書きます。

先に、この記事に何度も出てくる言葉を説明しておきます。Exocortex は自分で作った第二の脳のことで、Markdown のメモを集めたフォルダと、そこを読み書きする AI エージェントを合わせたものを指します。メモを置くフォルダは Vault と呼びます（Obsidian というメモアプリでの言い方です）。思いついたことをまず放り込む場所が受信箱で、全部の案件を 1 箇所から見渡して指示を出す場所を、自分は管制塔と呼んでいます。案件ごとに Claude Code を起動する場所は CWD（作業ディレクトリ）と書きます。途中から登場する Codex は OpenAI 側のコーディング AI で、Claude Code と同じ役割の別ブランドだと思ってください。

v3 は半年動かしてきた構成、v4 はこれから組み直していく構成のことで、自分の中だけで使っている呼び名です。途中で迷ったところや、あとから間違いだったと分かった判断も、消さずに残してあります。

1. 「動いてはいるのに効いていない」で止まった場所

最初の半年、自分の Vault は順調に育っているように見えました。動いてはいる。この記事ではあとから、その状態を「動いた感」と呼びます。

自分で用意した /secretary（Vault の中で秘書役の AI を起動する自作コマンド）を叩けばその日のタスクが整い、思いついたことは受信箱に落ち、02_タスク/2026-04-XX.md が日ごとに積み上がっていく。CLAUDE.md（Claude Code が起動のたびに読み込む、自分用のルールを書いたファイル）には自分の役割と運用ルールがびっしり書いてあって、Skills（よく使う手順を 1 枚にまとめ、名前で呼び出せるようにした部品）も気がつけば 90 個。「外付け大脳皮質」ができつつある実感はありました。

自分で書いたルールを、自分で 3 日連続で踏み抜いた

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

「これ、何行になってるんだろう?」と思って数えたら 173 行 ありました。後から Anthropic の公式ドキュメントを読んだら「200 行を目指せ」と書かれていて、「あ、自分のルールはもう遠くなりすぎたんだ」と気づきました。CLAUDE.md は AI が毎回頭から読み直す紙なので、長くなるほど後ろのほうは目を通されても効かなくなります。

zenn の検証記事には「650 行を超えると約 70% のルールが無視される」という数字も出ていました。173 行はまだその手前ですが、向かっている先は同じです。書いた量と効いている量は最初から別勘定だったんだと思っています。

iCloud で mv がハングした朝

同じ週に、Vault のフォルダをターミナルから動かそうとしたら、ファイルを移動する mv コマンドが固まって返ってこなくなりました。原因は iCloud の evicted ファイルです。実体はクラウド側にあって手元には落ちていない状態のファイルで、動かそうとした瞬間にダウンロードが走り、そのまま時間切れになります。これも別に新しい問題じゃなくて、自分で書いた known-issues.md（過去に踏んだ不具合を書き溜めたメモ）にちゃんと載っている。載っていて、それでもまた踏みました。

iCloud が裏で使っている CloudKit のキャッシュも何十 GB か膨らんでいて、そっちも放置していました。Mac と iPhone しか使わないなら iCloud で足りる、と勝手に決め込んでいたんですが、自分の使い方ではとっくに限界でした。

受信箱に書くはずの言葉を、メモ帳に貼っていた

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

ある日その Antigravity が突然「restart to update」して、ターミナルのタブ配置が全部消えました。各 CWD のセッションを claude --continue（前回の会話の続きから Claude Code を立ち上げ直すコマンド）で復活させるとき、自分は 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 という決まりがあって（Codex が起動時に読むルールファイルで、Claude でいう CLAUDE.md にあたります）、それなのに自分の Vault には AGENTS.md がない。Codex に「いま何してる?」と聞いても、Claude のセッションで進めた内容は知りません。当然です、共有してないんだから。

部分的に直して粘るのは、ここでやめました。

v4 を始めることにした

2026-05-01、99_system/architecture/v4/ というフォルダを作って、設計の議論はそこだけでやると決めました。Vault 本体にも 14 個以上ある CWD にも手をつけず、v4 という別の場所で議論する。こういうルールにしたのは、自分が聖典と呼んでいる文書群（master/ に置いた、設計の正本＝これが正しいと決めた大もとの文書一式）で同じ失敗をしているからです。作り直しと日々の運用を同じ場所でやると、両方倒れます。

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

• 全プロジェクト共通の ~/.claude/CLAUDE.md は 78 行で、ここは問題なし
• Vault 用の CLAUDE.md は 173 行。目安の 200 行まで、残り 27 行しかない
• 進行中の作業をまとめた _active-work.md は 32 行で、まだ余裕がある
• セッションの引き継ぎメモ _context.md は 119 行。Stop hook（AI の応答が終わるたびに自動で走らせる処理）で毎回書き足していたので、太ってきている
• MEMORY.md（Claude Code が自動で覚えた内容の目次）は 57 行で、上限の 200 行まではまだ遠い
• MCP（AI から外部ツールを呼び出すための共通の口）の接続先が 24 個。内訳は claude.ai 経由が 9 個、プラグイン経由が 6 個、手元で動かしているものが 9 個
• Skills は 90 個。もともと 163 個あったのを 97 個まで、さらに 90 個まで減らしてきた残りです

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

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

• iCloud を使い続ける案は、自分の判断で完全にやめると決めました。iPhone との同期は別の手段でまかないます
• 役割を固定して分ける案（設計は Claude、実装は Codex）は、章 2 で書く理由で撤回しました
• iCloud からの脱却とフォルダ名の PARA 化を同時にやる案は、一度に壊れる範囲が広すぎるので、段階を分けました。PARA は Projects / Areas / Resources / Archives の 4 つにメモを振り分ける、よく知られた整理法です
• PARA に完全に合わせる案は見送りました。いま回っている GTD（気になることを全部いったん書き出してから捌いていく、よく知られた仕事術）由来の流れ（受信箱に放り込み、タスクにして、日報に書き、あとでレビューする）を失うのが惜しかった
• NotebookLM（資料を読み込ませて質問できる Google の道具）に Vault 全体を同期して中核に据える案は、コンテキスト（AI が一度に読み込める分量）の食いすぎという本題を解けないので、補助にとどめました
• Smart Connections や Obsidian Copilot（どちらも Obsidian に AI 機能を足す拡張）を常用する案は、Claude と Codex がすでにやっているファイル読みと検索に二重投資することになるのでやめました

設計の議論を Claude 単独でやるのも、ここで止めました。Codex のデスクトップ版で同じフォルダを開いて、両方の AI で議論する方式に切り替えます。これが章 2 で詳しく書く「共通基盤 + 起点違い + 一時交代」モデルの起点になりました。読んだままの意味で、土台（Vault と設定）は両方の AI で共有し、作業を始める側だけが Claude か Codex かで違い、得意な場面では途中で手綱を渡し合う、という形です。

振り返ると、この時点で効いたのは道具の入れ替えより、議論する場所を分けると決めたことでした。

2. 役割を「設計する側」と「作る側」に固定したら、自分には合わなかった

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

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

Planner が計画を立てる係、Executor が実際に手を動かして作る係、Reviewer が出来上がりを見直す係です。並んでいる /secretary や /brainstorming は、自分で用意した自作コマンドの名前です。

この案は、Anthropic 公式が勧める sub-agent isolation（親の AI が子の AI を別枠で走らせて、担当ごとに読む範囲を切り分けるやり方）と、Qiita で見かけた「計画係と実装係を分けたら生産性が 1.5〜2 倍になった」という事例をなぞった形です。提案としてはまっとうです。

自分も最初は「いいじゃん」と思いました。役割ははっきりしているし、受け渡しの手順も単純です。Claude が設計して、Codex が作る。絵にすると見た目はきれいでした。

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

何が壊れたか

iOS アプリを実装している最中に、ふと Notion のデータベース（案件やメモを表の形で貯めている場所）を見たくなる瞬間が来ます。ところが Codex からは Notion を触れません。「あ、Claude に渡そう」と思った瞬間に、手が止まります。Codex のセッションで積み上げてきた話の流れを Claude へ引き継ぐ手間のほうが、自分で 30 秒だけ Notion を開くより重いんです。

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

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

返ってきた答えは明快でした。

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

読んだ瞬間に、「あ、自分はそう望んでたんだ」と気づきました。役割の固定を欲しがっていたのは、設計を整理しやすくしたい側の自分です。実際に手を動かしたい自分は、もっと雑に行き来したかった。

Codex には長い記憶が残らない、と思い込んでいた

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

「Codex CLI には永続メモリがない、長期記憶は Vault の Markdown に寄せるべき」という記事をどこかで読んで、裏も取らずに信じ込んでいました。永続メモリというのは、セッションを閉じても消えずに残る記憶のことです。それが無いと思っていたから、役割分担のときに Codex を「使い捨ての作業役」に置いてしまった。

実際に Codex 本人へ ~/.codex/（Codex が設定と履歴を置いている隠しフォルダ）の中身を調べさせたら、こうでした。

• ~/.codex/state_5.sqlite に 会話のスレッドが保存されていて、記憶を残す設定 memory_mode も enabled（有効） になっていた。SQLite は 1 個のファイルで完結する小さなデータベースです
• ~/.codex/memories/ のほうは、確かに空だった
• ~/.codex/config.toml（設定ファイル）には、Notion と Figma へ ネット越しにつなぐ HTTP 方式の MCP の URL がちゃんと書かれていた

MCP は AI から外部ツールを呼び出すための共通の口です。つなぎ方には、同じパソコンの中でプログラムを直接起動する STDIO 方式と、ネット越しにサービスへつなぐ HTTP 方式があります。「Codex は STDIO しか使えない」とも自分の Vault には書いてあったんですが、これも誤りでした。Codex のデスクトップ版は HTTP でもつながります。

ここで前提が一つ崩れました。Codex は、Claude と同じことができるもう一つの 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
   起点として開始                 起点として開始
        │                            │
        └────  得意領域で一時交代  ────┘

図のいちばん上の箱が、Claude と Codex の両方が読む共通の土台です。AGENTS.md は Codex が起動時に読むルールファイルで、Claude 用の CLAUDE.md はそこを指す symlink（別のファイルを指す分身。実体は 1 つしかない）にしてあります。Vault に置く Markdown は 4 本で、handoff.md が引き継ぎ、progress.md が進捗、design-decisions.md が決めたことと理由、session-restore.md がセッションを失ったときの復元手順です。kepano/obsidian-skills は外部で公開されている skill（よく使う手順を 1 枚にまとめて、名前で呼び出せるようにした部品）の詰め合わせで、これも両方から使えるようにしました。STDIO 方式の MCP と、案件の状態を 1 画面に並べた kuritakazuki.com のダッシュボードも共通です。

そのうえで、Owner（いま手綱を持っている側）は同時に 1 人だけと決めました。handoff.md のいちばん上に「現在の Owner」を固定で表示します。交代するときは、いつ、誰から誰に、なぜ渡したのかを書き残します。Claude と Codex のどちらから始めても、この土台を読めば同じ作業環境に入れます。

得意分野の違いは残しました。Claude はネット越しにつなぐ MCP（Notion、Linear、HubSpot、Slack、Gmail）と、これまで貯めてきた作業手順の資産が強い。Codex は実装と書き直し、踏み込んだ設計判断、それに画面まわりの改善を途中から引き取るのが強い。ただし「これは Codex の仕事」と決め打ちはしません。

60 分、90 分、120 分で線を引く

並行して動かす時間にも上限を入れました。暴走しないように、先に引いておく線です。

• 60 分たったら、その時点の Owner が progress.md と handoff.md を更新します
• 90 分を過ぎたら、新しい sub-agent や並行作業をもう足しません。動いているものをまとめる方向へ寄せます
• 120 分に届いたら、handoff と session-restore を書いて、AI に「このまま続けるか、引き継ぐか」を聞きます

この線は AI 自身の自制では守れない、というのが Codex の見立てでした。実際、compaction（会話が長くなったとき、AI が過去のやりとりを要約して圧縮する処理）の前後で報告の指示ごと忘れる事故が、すでに自分のセッションで起きていました。そこで progress.md の更新時刻と、handoff.md の last_checkpoint_at という項目から経過時間を実測し、ダッシュボードのいま動いているものを並べる欄に「経過 75 分、次の判定は 90 分、そろそろ統合に寄せる」と出す設計にしました。

強制終了はしません。120 分で AI を問答無用に止めると、大事な作業を途中でぶった切る危険が大きすぎます。代わりに、赤い警告を出し、handoff の更新を必須にし、AI に続けてよいか問い直す。この 3 つを、いちばん強い止め方として組み込みました。

sub-agent は 3 体まで、多くても 5 体

X で流れてきた話に「AI 社員を 40 体作って、1 ヶ月で全部廃棄した」という事例があります。context rot（会話が長くなるほど前の指示が効かなくなる現象）が頻発し、compaction がうまくいかなくなって「3 人が消えて 2 人が重複する」ような事故まで起きた、というやつです。

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

普段は Claude と Codex の 2 体を基本にして、必要なときだけ専門役を 1 体足し、3 体までにしました。並行して実装するときで 4 体、上限は 5 体です。緩そうに見えますが、「読むだけで待機している AI も 1 体として数える」という細かい規則を足したら、意外と早く 5 体に届きます。ここは厳しめでちょうどいい。

固定の役割分担は、絵に描いたときだけきれいに見えるやり方だったと思っています。土台さえ共有できていれば、どっちから始めても困らない。

3. 議論をまとめて走らせて見えた、Claude と Codex のクセの違い

設計の議論は、最初「9 つの論点を 1 つずつ潰していく」つもりで始めました。論点というのは、v4 で決めないといけないことに 1 番から 9 番まで番号を振ったものです。ところが 6 番（役割分担のモデル）の合意が取れた時点で、残り 7 つを 1 個ずつ片づけると 1〜2 週間かかる計算になってしまった。

そこで、関係の近いものを束ねて 4 つのまとまり（バッチ）で一気に走り切るやり方に切り替えました。

• バッチ 1: 論点 1（AGENTS.md と CLAUDE.md の棚卸し）と論点 2（メモの仕様）
• バッチ 2: 論点 7（コンテキスト消費の可視化）と論点 3（MCP の構成）
• バッチ 3: 論点 8（いまの運用をどう保つか）と論点 4（Phase の順番の詳細）
• バッチ 4: 論点 5（フォルダ構造の段階的な移行）

並べる順は「Phase 0.5 と Phase 1 の実装で先に要るものから」で決めました。Phase 0.5 というのは、本格的に組み替える前に、いまの状態を測る仕込みだけをやる段階のことです。論点 1 は、AGENTS.md に残っている古い固定分業の記述（章 2 で撤回したあれです）を書き換えないと先へ進めないので最優先。論点 2 は、handoff.md（引き継ぎメモ）の項目立てを Phase 1 で実装するための前段でした。

走らせてみたら、合意の中身より先に、両者の手つきの違いのほうが目につきました。

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 ありはまだ少数派。

rg はファイルを高速に探すコマンド、find は macOS に最初から入っているファイル検索コマンドです。自分はそれまで「7 件」だと思い込んでいました。Claude が前に調べたときの数字を、そのまま信じていたからです。でも find で数え直したら 9 件ありました。rg のほうは .gitignore（git に無視させたいファイルを書いておく設定）か何かに引っかかって、2 件を落としていたらしい。

ついでに、4 つの CWD で AGENTS.md の中身が壊れているのも見つかりました。文中の「.claude/」を機械的に「.Codex/」へ置き換えただけになっている。実際のフォルダはずっと .claude/ のままなのに、AGENTS.md にはそう書かれていない。Codex が思ったとおりに動かない原因の一つがこれでした。

同じ棚卸しを Claude に頼んでいたら、たぶん「7 件」のまま通っていたと思います。Claude は自分のセッション履歴を土台に答えを組み立てがちで、ファイルの現物を数え直すのは後回しになる。Codex はそこが逆で、いまディスクにある状態を先に見に行きます。

Claude は、つじつまを合わせる側に回る

バッチ 1 で Codex が出してきた 5 本の文書（AGENTS / handoff / progress / session-restore / design-decisions）の項目立ては、そのままでも十分使える出来でした。項目立てというのは、どの欄に何を書くかという決まりごとのことです。

ただ、自分の運用に当てはめてみると、5 か所ほど足りない感じがしました。

• AGENTS.md に Project Status の欄がほしい。いまが planning（計画中）、implementation（実装中）、review（見直し中）、paused（止めている）のどれなのかを書いておけば、AI が古い前提のまま走り出す事故が減ります
• handoff.md には Last Handoff Decision と Last Owner Change を足したい。なぜ交代したのかが、次に手綱を持つ側へ伝わります
• session-restore.md には、開いているタブと裏で動かしている処理を手で書き込む欄を作りたい。章 1 に書いた「セッションを閉じるのが怖い」に直接効く欄です
• design-decisions.md には Open Questions（未解決の問い）の欄がほしい。まだ決まっていない判断を、進捗メモや引き継ぎメモに紛れ込ませず、判断の記録の側で追えます
• progress.md は planning-with-files と同じ項目立てにそろえたい。すでに使っている資産とぶつかりません

これを Claude が補強案として出したら、Codex が「すべて賛成」で返してきました。つじつま合わせは Claude のほうが得意でした。

合意点が 25 個まで積み上がった

バッチ 1 は、合意点 25 件、Codex から出てきた実装上の細かい決めごと 5 件、人間が決めるしかない判断 4 件、という内訳で着地しました。合意点というのは、同じ問いを Claude と Codex の両方に投げて、答えが一致した箇所のことです。食い違ったところは相違点として別に数えます。

人間判断の 4 件は最後まで保留していたんですが、両方の AI の推奨がぴたりと重なったので、そのとおりに決めて、そのまま実装へ入りました。

• 誤置換していた 4 件は、Phase 0.5 でまず現状を把握し、実際に直すのは Phase 1 に回します。すぐ直すと、日々動いている CWD へ副作用が出るのが怖かった
• v4/AGENTS.md に残っていた古い固定分業の記述は、バッチ 1 の合意が取れた節目でその場で書き換えます
• 雛形を各 CWD へ配るスクリプトは、spec（これが正しいと決めた 1 本の仕様書）を Claude が書き、実装は Codex がやります。「共通基盤 + 起点違い + 一時交代」の最初の実例です
• handoff.md や progress.md を git（変更の履歴を残す仕組み）で管理するかは YES。ただし _context.md だけは対象から外します。あれは AI の応答が終わるたびに自動で書き足される下書きなので

このとき実装した中身は、Phase 0.5 の実施ログの章で詳しく書きます。やったこと自体は単純で、AGENTS.md のほうを本物のファイルとして書き、CLAUDE.md はそこを指す symlink（別のファイルを指す分身。実体は 1 つだけ）にしただけです。これだけで、片方を直し忘れて中身がずれることが物理的に起きなくなりました。

バッチを走らせて、自分の書き方の偏りに気づいた

5 本の文書の項目立てをバッチ 1 で確定させたとき、ふと「これ、自分が書いた章 1 と章 2 の文体と違うな」と思いました。整理されていて、結論が先に出ていて、箇条書きが多い。読み物としては面白くない。

参考にしていた記事（@obsidianstudio9 さんの「『第 2 の脳』を腐らせない唯一の方法」）は、もっと経験談寄りでした。転機があって、失敗をそのまま書いていて、読み終わったあとに「この人も同じところで転んだのか」と思える。それに比べると、自分の章 1 と章 2 は議事録の要約でした。

それで章 1 と章 2 を書き直したのが、いま読んでもらっている文章です。書き直してみて、v4 の改修過程として本当に残すべきなのは、設計判断の整理だけじゃなく なぜそう判断したかの心の動き のほうだと感じています。

ここから先のバッチ 2 から 4 は、Phase 0.5 で観測の仕込みをして、Phase 1 でダッシュボードの最小版を作り、Phase 2 で iCloud から抜け、Phase 3 でフォルダ構造を変え、Phase 4 で公開する、という実装の段階に入っていきます。各 Phase の実施ログも、章として残していく予定です。

論点を 4 つに束ねたのは、時間を節約したかっただけの判断でした。ただ束ねてまとめて走らせたおかげで、両 AI の差がはっきり出た。1 問ずつ丁寧に進めていたら、たぶん気づかないまま終わっていたと思います。

4. 絵に描いてみて、やっと「何が変わるのか」が腹に落ちた

設計の議論を 4 つのまとまりに分けて進めている途中で、ふと手が止まりました。「これ、自分の 1 日はどう変わるんだろう」。

Claude と Codex の役割分担も、共通基盤 5 文書の schema（どの文書に何を必ず書くかを決めた型）も、Notion をどこまで削るかの判定基準も、文字の上ではひととおり整理できています。ただ、朝起きてから自分が何をして、どこで AI に渡して、どこで自分の手に戻ってくるのか。その順番だけが、いつまでも像を結びませんでした。

v3 を半年動かして破綻した話を振り返るときも同じでした。「3 つのツールを行き来するのに疲れた」とは言えるのに、その疲れがどこで生まれていたのかを言葉にできない。設計の議論ばかり続けていると、こういう生活の手ざわりが置いてけぼりになります。

だから絵にしました。NODE6174 で公開している Blueprint（運用の構成をまとめた設計図のページ）の v3（公開中）と v4（下書き）に合わせて、自分の 1 日の流れを 5 層に分けて並べます。改修の前と後を、自分の理解が合っているかどうかの確認として書き出したものです。

4-1. 半年動かしてきた v3 の構造

まずは v3、半年そのまま動かしていた形です。上から順に、思いつきが入ってくるところから、記録として残るところまでを 4 層で並べました。⚠️ が付いているのが、運用していてつらくなった場所です。

┌──────────────────────────────────────────────────────────┐
│ 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 編集が中心になっていたが想定外                   │
└──────────────────────────────────────────────────────────┘

2 段目に付けた ⚠️ の「mv ハング」は、前に書いた、実体がクラウド側にしかない iCloud のファイルを動かそうとして固まる例です。図の中の Inbox は受信箱、Triage は振り分け、Working は実作業、Memory は残す記録、と読み替えてください。

自分の触り方（v3）

• 朝は Notion を開いて、~/.secretary/_context.md（いま何をやっているかを書いたメモ）に目を通し、それから CWD のターミナルを 1 つずつ開いていきます
• 外出中は、スマホの Notion 受信箱に思いつきを落とします。Obsidian のモバイルアプリにも入れていましたが、そちらは結局見ませんでした
• デスクでの作業は ~/dev/{project}/ で Claude Code を起動して進めます。進捗はその CWD の中に置いたままで、Obsidian は基本的に触りません
• AI を引き継ぐときは、_context.md を Stop hook で自動更新し、_active-work.md は自分の手で書き換えます
• 夜は /secretary でその日のレポートを出して、Notion の全体ダッシュボードを眺めて終わりです

v3 で疲れていた場所

• 受信箱を Notion と Obsidian の 2 箇所に持っていたので、揃えておく手間が地味に重い
• 振り分けを iCloud 経由にしていたせいで、IDE（コードや原稿を書くための編集ソフト）のサイドバーから見えない瞬間がある
• 記録の層は「自分で編集する前提」で作ったのに、実際にはほとんど編集せず、AI が書く量のほうが増えていた
• Notion の人間用ダッシュボードに AI を書かせようとすると、API の制限に当たって苦しい
• Codex のデスクトップ版が共通基盤に入っていないので、AI が片輪走行になる

ツールの数がしんどさの元だと思っていましたが、書き出してみると違いました。自分の手の動きと AI の手の動きの境目が、決まらないまま半年動いていた。原因はそっちだったと思っています。

4-2. いま組み直している v4 の到達点

こちらは 5 層です。縦に並ぶ 4 層はそのままで、右に「Dashboard 層」が増えました。図に出てくる「Astro + CF Pages」は、静的な Web ページを組み立てる道具（Astro）と、それを置く無料の置き場（Cloudflare Pages）の組み合わせです。「JSON snapshot」は、その時点の状態を機械が読める形で書き出したファイルだと思ってください。

┌────────────────────────────────────────┐
│ 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 層で蓄積モデル             │
└────────────────────────────────────────┘

この図で肝心なのは、縦と横が交わらないところです。縦は貯める軸で、受信箱から振り分け、実作業、記録へと下に降りていきます。横は見る軸で、Dashboard 層がそれにあたります。AI は縦に書き、人間は横から見る。Dashboard 層に AI は書き込めません。各層が出した JSON snapshot を読んで並べるだけの画面です。

自分の触り方（v4）

• 朝は kuritakazuki.com の Now レーンを開きます。いま動いている 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 で書く使い捨ての下書き扱いにしました
• 夜の /secretary は v3 と変わりません。そのあとダッシュボードで引き継ぎ・進捗・健康度をまとめて見ます。Notion の全体ダッシュボードは、廃止するか読む専用に落とします

v4 で変わったこと

• 受信箱を Notion に一本化しました（共有と外部連携だけに絞る）
• 振り分けを手元に置いて Git で管理するようにしました（iCloud をやめ、.code-workspace で IDE に統合）
• 実作業のやり方は変えていません（共通基盤 5 文書を各 CWD の直下に置いただけ）
• 記録を AI 専用にしました（人間は手で編集しない。kepano/obsidian-skills が中核）
• Dashboard を新しく作りました（見るための軸。kuritakazuki.com、人間専用、AI は書き込まない）
• Claude と Codex が同じ基盤を共有し、起点だけを分けて、必要なときに一時的に交代する形にしました

4-3. 観点別 BEFORE / AFTER

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

4-5. 絵にして初めて気づいた、いちばん大きな変化

v3 から v4 でやっているのは、ツールの入れ替えではありませんでした。自分の手の動きをどこまで AI に渡すか。引き直しているのはその線です。

v3 では、自分が Notion と Obsidian とターミナルの 3 つを行き来していました。記録の層は手で編集する前提だったので、残す作業も自分の手の仕事だと信じていた。Notion の全体ダッシュボードを更新するのも自分です。

v4 では、記録の層を AI に渡しました。Dashboard 層は人間専用でも書き込みはできず読むだけなので、自分が手を動かす量はむしろ減ります。代わりに増えるのは目を動かすほう、Now レーンを眺める時間です。あとは決める仕事。担当の交代を承認する、下の層から上の層へ上げる候補を選ぶ、Notion のページを残すか移すか捨てるかを決める。

手は AI に渡して、目と判断は自分に残す。v3 のときはこの分け方を言葉にできていませんでした。v4 でやっと形になったと思っています。

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

絵にしたぶん、まだ決めきれていないところもはっきりしました。

• Notion のクライアント共有ページを、AI が読みに行っていいのかどうか。書き込みの禁止は決まっていますが、どこまで読ませるかは別に決める必要があります
• Codex のデスクトップ版から使う MCP（AI から外部ツールを呼び出すための共通の口）を、どこまで許すか。Claude を主、Codex を補助として並走させると、同じ Notion のデータベースを両方が触る瞬間が出てきます。その取り合いを twin registry でどこまで吸収できるかが読めていません
• kuritakazuki.com へ Notion の中身を書き出す頻度。1 日 1 回の定期実行にするか、セッションの終了に連動させるか、手で叩くか。最初の版は手動で始めますが、運用のペースは決まっていません
• 14 個を超える CWD に、どのくらいの速さで共通基盤 5 文書を配るか。一気に配るか、いま動いている数個から始めるか。コミットしていない変更が残ったままの作業場所が多いのがこわい
• handoff.md を使った担当の引き継ぎが、本当に守られるか。60 分・90 分・120 分というガードレール（暴走しないように先に決めておく制限）も含めて、実運用のテストはまだしていません。Phase 1 で様子を見ながら詰めます

どれもバッチ 3 と 4、それと Phase 0.5（本格的に組み替える前に、いまの状態を測る仕込みだけをやる段階）と Phase 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 件のどこでも対立しなかった。

でも、しばらくしてから手が止まりました。これ、本当にすごいのか？

「相違点 0」は、2 体の AI が独立に一致した証拠ではない

別の AI を 2 体使ったのは、片輪だけで走るのが怖かったのと、独立した第二の意見が欲しかったからです。Codex はその場で測った数字を返してきて、Claude はつじつまを合わせる側に回る。強みの違いは、たしかに見えました。

ただ、128 件が全部そろうのは、また別の話です。ここから読み取れるのは、こういうことでした。

• どちらの AI も、2026 年時点で公開されているソフトウェアや仕様書、コミュニティに溜まった知識を同じように持っている
• 前提が同じなら、別の AI でも近い結論に着地する
• 「独立した第二の意見」は、もとになる知識が同じである限り、本当の意味では成立しにくい

自分が欲しかった「独立した第二の意見」は、手に入っていなかったわけです。Claude と Codex は 中身の作りは別物でも、学習に使った資料のもとが近い。それぞれが独立に判断しても、近いところへ寄っていきます。本当に独立した意見が欲しければ、系統の違うもの（Gemini や Llama など）を混ぜる必要がありました。

そうは言っても、128 件を積み上げた議論が無駄だったわけではありません。片輪だけで走って破綻する危うさは消えました。Codex の補強からは、Claude が見落としていた観点も出ています。移行の途中で構造をいじれないように鍵をかける migration lock、先に試す CWD（作業ディレクトリ。Claude Code を起動する場所）を 5 つの型に分ける考え方、実行前に安全かどうかを機械的に確かめる preflight checker の 3 つです。「同じ系統の AI で角度を変えて詰める」と受け取り直せば、効果は十分あったと思っています。

これを最初から「独立した第二意見」だと思い込んだままだったら、合意 128 件を見て「もう議論する必要はない」と過信していたかもしれません。Gemini のような系統の違う AI を混ぜたら、まだ別の論点が出てくるはずです。

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

設計の議論が終わって、実装の最初の段階である Phase 0.5 に入った日のことです。Phase 0.5 は、本格的に組み替える前に、いまの状態を測る仕込みだけをやる段階を指します。ここで Day 1 から Day 5 までのタスクを、1 セッションで走り切りました。

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

• v4 の設計を進めているこのセッションが、観測の仕込みをする。決まったタイミングで自動的に走る処理（hook）のログ hooks.log を溜め始め、その hook をまとめて捌く dispatcher を配置し、セッションがどこまで長くなるかを計測する
• ダッシュボードの CWD では、自分が手で立ち上げた別セッションが画面本体を実装する。Astro 6（静的な Web ページを組み立てる道具）と Tailwind v4（クラス名を並べて見た目を決める道具）で、パネルを 5 枚作る
• 見直し役の Claude が、Playwright MCP（ブラウザを自動で操作してページの中身を測る道具を、AI から呼べるようにしたもの）で http://127.0.0.1:4322/ を開き、ページの構造と画面の写しを取って、Vault にレビューメモを残す

実装する側と設計する側と見直す側が、同時に動いた瞬間でした。章 2 で決めた「共通基盤 + 起点違い + 一時交代」のやり方を、初めて本番で回しています。

正直に書くと、見直し役のメモは ダッシュボード CWD の handoff.md（引き継ぎメモ）には書き込みませんでした。そのセッションが別のターミナルで動いていたので、書き込みがぶつかるのを避けて、Vault 側の 99_system/architecture/v4/work/dashboard-stage-a-review.md に残しています。安全側に倒した判断ではありますが、共通の土台が 2 つに割れたリスクは残ったままです。ダッシュボードのセッションが次に起動したとき Vault のレビューメモを見に来る習慣が付かないと、見直し役の指摘だけが宙に浮きます。

ここは Phase 1 で、ダッシュボード CWD と Vault のあいだの行き来を仕様として決めないといけません。バッチ 4 で出た補強案 P の「実際に動いている開発 CWD で 1 往復テストする」は、技術としては成立しました。ただ運用として 1 往復と言えるのは、ダッシュボード側が Vault のレビューメモを読みに来たときです。

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

健康度メーターは、自分の作業環境が壊れかけていないかを 5 つの数字で見る計器です。観測の仕込みが終わった時点（Day 2 完了）で、こうなっていました。

• 🟢 hook が起動するまでの時間は中央値 56ms（推奨は 200ms 未満）
• 🟢 同時に走らせている AI は 2 体（Claude 本体と、見直し役の Codex）
• 🔴 履歴が肥大化している。apps-dev-training-log が 295.8MB（推奨は 50MB 未満）
• 🔴 MCP（AI から外部ツールを呼び出すための共通の口）の接続失敗率が 20.8%。応答しないまま残っている hubspot と、Cloudflare 関係の 4 件が原因（推奨は 5% 未満）
• 🟢 やらかしを放り込む mistakes-inbox の滞留はゼロ（まだ運用を始める前なので当然）

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

迷った理由は、v3 のときに「CLAUDE.md が 173 行まで膨らんで 70% 無視される」ような、警告サインを見ないふりして走り続ける失敗をした記憶があったからです。同じ罠は踏みたくない。

でも考え直しました。健康度メーターは 警告灯であって、通行止めの標識ではない。赤 2 件を消すことと Phase 1 を進めることは、そもそも別の話です。

• 履歴の肥大化（apps-dev-training-log の 295.8MB）は Phase 3 の整理で片づく話で、Phase 0.5 と Phase 1 には関わらない
• MCP 接続失敗率 20.8% のほうは、手順書（runbook。hubspot-dev-mcp-diagnosis.md と cloudflare-auth.md）に沿って、個別に承認をもらってから直す。仕事を止めるほどの支障はありません（claude.ai 側の HubSpot は別に動いています）

「赤を見続けている状態」は、v3 の「警告が見えなくなっていた状態」のちょうど裏返しです。まず警告が見えるようにして、消すのは個別の手順書でやる。ダッシュボードを読む専用にした設計とも、ここは筋が通っています。

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

9 つの論点を走り切り、Phase 0.5 も終えた時点で、「これで実装フェーズに進める」と言いたくなりました。そのまま進んでも、たぶん 8 割方は問題なかった。

でも念のためと言い聞かせて抜け漏れチェックをかけたのが効きました。30 分の総点検で 6 件出てきます。

1. task_plan.md に、Phase 1 の節がまだ展開されていない
2. T2 と T11 で書いたスクリプトが /tmp（再起動で消える一時置き場）に置きっぱなしで、Vault に保存していない
3. 雛形を各 CWD へ配る distribute-templates.sh が未実装。spec（これが正しいと決めた 1 本の仕様書）すら無い
4. claude-backup の SSH 修復手順書を書いていない
5. 全体を見渡す _active-work.md の Exocortex の行が古いまま
6. NODE6174 の章 5 を書いていない

3 番目が特にまずかった。仕様書すら書いていないので、Codex に「実装しておいて」と投げる準備さえできていません。Phase 1 の 2 週目に入って 5 文書の配布を始める段になってから「あれ、配る手段は？」となり、そこで spec を書いて、Codex に投げて、待って、で 1 週間遅れていた可能性があります。

設計の詰めは、最後の 30 分に残っている。完成と宣言する前だから 30 分で潰せた 6 件で、走り出してから見つかっていたら、3 番だけで 1 週間持っていかれていました。

v3 のときは、完成と宣言してから走る途中で気づいて慌てて埋める、を繰り返していました。今回は順番を逆にして、宣言の前に 30 分使っています。

自分の盲点は「絵にできない領域」だった

章 4 で v3 と v4 の運用フローを絵にしたら腹落ちしました。走り切ったいま、まだ絵にできていないものが残っているのにも気づいています。

• Codex のデスクトップ版が内側でどう動いているか。セッションの記録が入った state_5.sqlite の中身は調べましたが、Codex がセッションをどう保持しているのかの実感はありません
• Claude の auto memory がいつ書かれるか。auto memory は、会話をまたいで覚えておきたい内容を Claude が自動で書き足す仕組みです。どういうときに feedback（気づきを残す）ファイルが増えるのか、何を基準に書くのかは、公式の説明にも書かれていません
• 実際の hooks.log がどれくらいの密度で溜まるか。起動の速さは中央値 56ms と測れましたが、1 日で何件積み上がるかは未測定です
• 5 文書を配ったあとの運用の手ざわり。handoff.md と progress.md を毎日触る生活が、どう回るのか
• 手綱を渡すときの負担。Claude と Codex を切り替えるたびに自分の頭がどれだけ疲れるのかは、測れていません

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

設計と実装のあいだには、絵にできない中間の領域がある。実装してみないと見えないのに、実装の前に全部を見ようとすると、いつまでも止まったままになる。9 論点を走り切り、128 件の合意点を積み、Phase 0.5 も走り切って、抜け漏れチェックまでやって、それでも残る「絵にできない領域」は、Phase 1 に進んで確かめるしかありません。

次の章は、Phase 1 で dispatcher を settings.json（Claude Code の設定ファイル）に反映させ、5 文書を先行 5 CWD に配り、dashboard.kuritakazuki.com を公開するところです。設計の話はここで打ち止めにして、実運用のログから書きます。

6. 実際に作り始めた瞬間、設計の死角が見えてくる

設計フェーズを終えて「これで進められる」と思った直後に、Phase 1 の 1 週目（社内で Week 1 と呼んでいる区切りで、設計を終えて実装に入った最初の週です）が始まりました。手を動かし始めて数日で、章 5 で「絵にできない中間の領域」と書いたところが、少しずつ絵になっていきます。

「全推奨で」と答えた瞬間、違和感が残った

ポータル層（作業の状況を 1 画面で見渡すためのダッシュボード。v4 の中では画面まわりのかたまりです）の設計を、7 つのステップに分けてレビューしました。名前をどう付けるか、ページをどう組むか、タスクをどう管理するか、データをどこから取るか、引き継ぎをどう回すか。区切りごとに 1 つずつ確認していって、最後に自分が返したのが 「全推奨で」 の 5 文字でした。

理屈の上ではいい結果です。Claude が出してきた推奨案 A が、7 回続けてそのまま通った。作る側は迷わず進められるし、見る側の手間も少ない。

でも、答え終わった直後に違和感が残りました。早すぎる。

章 5 で「合意点 128 件、相違点ゼロ」を見て「これ本当にすごいのか？」と立ち止まったときと同じ種類の違和感です。レビューは設計の死角を別の視点から潰すためにやっている。その推奨が全部そのまま通るということは、Claude が並べた選択肢の枠の中だけで議論が閉じていた可能性がある。

ここで判断が 2 つに割れました。

• 「全推奨で」を 設計の完成度が高い証拠 と読むなら、そのまま実装に進む
• 「全推奨で」を レビューの取りこぼし と読むなら、もう 1 周、別の視点を入れる

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

1. 章 5 で書いた 30 分の抜け漏れチェックを、ポータルの設計途中でも挟んでいました。spec（これが正しいと決めた仕様書）5 ファイルの末尾すべてに「ユーザー fb 候補」（自分に確認したいことを溜めておく欄）を置いてあって、後から見直す導線は作ってある
2. ポータルは v4 改修の土台そのものではなく、先に作れる一部分でしかありません。死角が見つかっても、仕様書を直してダッシュボードに反映する往復で吸収できる構造になっている

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

別のセッション同士で、フィードバックが行き来した

ポータルの設計が固まったあと、実装は別の CWD（作業ディレクトリ。Claude Code を起動する場所）である ~/dev/kuritakazuki-dashboard/ で、別のセッションに担当させることにしました。Exocortex の Vault（Obsidian でメモをまとめて置くフォルダ）で起動しているセッションは、仕様書を正しい状態に保つ役に専念します。ダッシュボード側のセッションは、Astro（静的な Web ページを組み立てる道具）と Tailwind（クラス名を並べて見た目を決める道具）を使った画面の実装に専念する。そういう分担です。

これは章 3 で書いた Claude と Codex のクセの違いとは別の話で、同じ Claude 同士でもセッションを分ける という判断でした。理由は単純で、仕様の議論と、実装コードのレビューとでは、頭に入れておくべき前提が違うからです。

実装に入って 2 日目のことです。ダッシュボード側のセッションが、手を動かしている最中に気づいた仕様書の改善点を、~/.secretary/01_受信箱/（思いついたことをまず放り込むフォルダ）に Markdown ファイルとして投げてきました。

受信箱メモ: portal-spec-feedback-from-dashboard.md
発信元: ダッシュボードの CWD（実装 2 段階目の 1〜2 日目）
内容:
  1. 仕様書 04 §2.2 の cwd-status.json の項目定義に、必須の項目を書き足してほしい
  2. 見本データをどこまで用意するかが仕様書に書かれていない
  3. projects.json に載せた CWD が cwd-status.json 側に無いと、リンク切れになる

これを Exocortex 側で拾って仕様書 3 ファイルに反映し、ダッシュボード側の handoff.md（引き継ぎメモ）の冒頭に変更のお知らせを残しました。ここまでで 15 分ほどです。

スマホから使うために設計した受信箱の流れが、AI のセッション同士の受け渡しにもそのまま使えていました。

ポータルを設計している段階では、スマホからだと pbcopy（Mac のコマンドから文字をコピーする仕組み）が効かないので、チャットの履歴を 01_受信箱/ に Markdown で落としておき、朝いちばんに走らせる自作コマンド morning-check で AI 秘書が吸い上げる、という流れを決めていました。人間とスマホの問題を解くための設計です。それが実装フェーズに入った途端、別々の CWD で動くセッション同士が、同じ道でフィードバックを投げ合っていた。

思っていなかった使い道でした。受信箱は「あとで処理するメッセージの置き場」として働いていて、書き込む側が人間でも別のセッションでも、扱いは同じです。

受信箱を AI 同士にも使うと、何がよかったか

別々のセッションが Markdown ファイル経由でやり取りすると、こんなことが起きます。

• 待ち合わせが要りません。ダッシュボード側が書いている間、Exocortex 側は止まらずに済みます。チャットを同期させる方式と違って、互いの手を止めない
• 履歴が勝手に残ります。受信箱にメモを作り、仕様書を直し、引き継ぎメモで知らせる。この一巡りが、Vault とダッシュボード側のファイルに痕跡として残る
• 人間が間に入らなくても回る手順があります。片方の AI が 01_受信箱/ に投げ、もう片方の AI が朝の整理で拾う
• 受信箱は誰のものでもない中間地帯です。置き場所としては Vault の中にありますが、中身の持ち主は、時間が経って振り分けられた時点で決まります

これは章 1 で書いた「動いた感だけで止まる」問題の、ちょうど裏側にある気がします。動いた感が生まれるのは、はっきりした通知が往復している瞬間であって、暗黙の同期に頼っているときではない。受信箱を通したやり取りは、暗黙の同期がないぶん、「動いた」という事実がファイルとして残ります。

5 件のうち 3 件は、何も壊さずに終えられた

Phase 1 の 1 週目に用意した Vault 側のタスクは 5 件。そのうち 3 件は、既存のファイルを 1 つも書き換えずに終えられました。番号は W1-T2 のように付けていて、W1 が 1 週目、T2 がその中の 2 番目のタスク、という意味です。

• W1-T2 では、消したデータを戻すコマンドの一覧を出すスクリプト（list-restore-commands.sh）に、「その CWD で最後に AI を動かした日」の列と、--notes オプション（macOS のメモアプリに自動でメモを作る）を足しました
• W1-T3 では、共通基盤 5 文書を各 CWD に配るスクリプト（distribute-templates.sh）の簡易版を Claude に書かせ、先行して試す 5 つの CWD に対して dry-run（実際には書き換えず、何が起きるかだけ表示する試し実行）をかけました。配布対象 14 件、ぶつかったファイル 0 件です
• W1-T1 の補助として、CWD の状態を JSON（機械が読める形でデータを書いた文字列）で吐くスクリプト（cwd-status-json.sh）を Python と bash で書き、仕様書 §2.2.1 の項目定義どおりか、先行 5 CWD で動かして確かめました

3 つとも Vault の 99_system/scripts/ にファイルを足しただけで、~/dev/* や ~/.claude/settings.json（Claude Code の設定ファイル）は 1 文字も書き換えていません。

設計の段階で「副作用ゼロで済む範囲」を線引きしておくと、実装は淡々と進みます。残る 2 件のうち、W1-T4 は dispatcher（決まったタイミングで走る処理をまとめて捌く仕掛け）の様子をただ観測するだけ、W1-T5 は settings.json を書き換えるので自分の承認が要ります。Claude が勝手に進めていい範囲は、実装が始まる前から線が引いてありました。

章 4 で v3 と v4 を絵にしたとき、Claude が自分の判断で走れるのは副作用ゼロの範囲だけ、と決めておいた（-c-c- モードと呼んでいるものです）のが、ここで効きました。設計のときに描いた絵が、実装中に走りすぎないための歯止めになっています。

「これが正しい」と決めた仕様書が、2 か所にできてしまう

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

ダッシュボード側のセッションは、2 日目の時点で cwd-status.json の見本データを独自に広げていました。仕様書の §2.2 には「全 38 CWD の git の状態、保存しきっていないファイルの数、引き継ぎメモの状態」とだけ書いてあって、どの項目が必須かは書いていない。そこでダッシュボード側が cwd_type / project / display_name / pinned / primary_link / status / dirty_count / dirty_age_days の 8 項目を、勝手に足していました。

判断としては妥当です。実装が走らないとデータの形は決まりません。ただ 「本当の項目定義」が、仕様書と実装の 2 か所に別々にある 状態でした。ダッシュボード側の見本のほうが正しくて、仕様書は記述が薄い。放っておくと、仕様書と実物が少しずつずれていく spec drift の原因になります。

解決は単純でした。ダッシュボードのセッションが受信箱経由でフィードバックをくれた、そのタイミングで、仕様書 04 の §2.2.1 に、TypeScript（JavaScript にデータの型の指定を足した書き方）で項目定義を書き起こしました。

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;
};

「これが正しい」と決めた仕様書は、実装が始まると侵食されます。書いた時点では十分なつもりでも、走り出せばデータの形は現実に合わせて広がっていく。受信箱に投げて、仕様書を直して、引き継ぎメモで知らせる。この道が通っているかどうかで、仕様書が生きたまま残るかが決まります。

これは v3 で起きていた「CLAUDE.md が 173 行まで膨らんで、7 割は無視される」のと似た構造です。仕様書が現実に追いつかないと、現場が仕様書を見なくなる。違うのは、今回は 追いつくための道が設計してある ことです。

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

章 5 の終わりに、実装してみないと見えない領域を 5 つ挙げました。Phase 1 に着手して数日で、そのうち何件かはもう見え始めています。

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

章 5 では「絵にできない領域は実装するしかない」と結論を出しましたが、実際に手を動かしてみると、絵は思ったより早く出てきました。「実装するしかない」と「実装すれば見える」は、同じことを別の角度から言っているだけだったと思っています。

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

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

• 章 1。v3 が「動いた感」だけで止まった理由は、設計と実装の境目が曖昧だったことでした
• 章 2。設計する側と作る側を AI の種類で固定するやり方は、自分には合いませんでした。起点を変えて、必要なときだけ一時的に交代するやり方に切り替えました
• 章 3。まとめて走らせたら、Claude と Codex のクセが見えました。つじつまを合わせにくる Claude と、その場で測った数字を返す Codex です
• 章 4。絵にしたら腹落ちしました。-c-c- モードまで含めて、自分の 1 日の解像度が上がっています
• 章 5。合意点 128 件で自分の盲点に気づきました。独立した第二の意見という幻想と、絵にできない領域の 2 つです
• 章 6。実装が走り出すと、設計の死角が見えます。仕様書と実物がずれ、別々のセッションがフィードバックを往復させ、副作用ゼロの範囲が効いてきました

並べてみると、設計フェーズで決めたことが、Phase 1 の 1 週目の数日で そのまま実装中の道具になっていました。共通基盤 5 文書、-c-c- モード、副作用ゼロの範囲、受信箱を通した引き継ぎ、健康度メーターの 5 指標。設計のときに使った言葉が、手を動かすときの道具に変わっていく感覚がありました。

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

次の章では、1 週目より先の実際の配布（共通基盤 5 文書を、先行して試す 5 つの CWD に、既存ファイルを上書きしない形で配ります）と、ダッシュボードを Cloudflare Pages（作ったサイトをそのまま公開できるサービス）に本番公開したところ、それから Notion を削って軽くする作業（社内で Phase 3-Y と呼んでいる段階）の運用ログを書きます。今度は「副作用がある実装」の章です。

[2026-05-13 実装 2 日目の終盤]
  ダッシュボードの CWD（実装 2 段階目）が、仕様書 04 の項目定義の薄さに気づく
    ↓
  受信箱メモを作成: ~/.secretary/01_受信箱/2026-05-13-portal-spec-feedback-from-dashboard.md
  中身: 1 必須項目の明示 / 2 見本データの範囲 / 3 整合性のルール
    ↓
[Exocortex 側のセッションが拾う。処理は約 15 分]
  仕様書 04 に §2.2.1 を新設（TypeScript の項目定義 12 項目 + 整合性ルール）
  仕様書 04 の確定 D と仕様書 05 の確定 A に、見本データの範囲の列を追加
  仕様書 02 の確定差分 URL マップの末尾に、整合性ルールを 1 行追加
    ↓
  ~/dev/kuritakazuki-dashboard/handoff.md の冒頭に変更通知（読むべき文書の一覧つき）
  ~/.secretary/99_system/architecture/v4/05-decisions-log.md に判断の記録を 1 件追加
  受信箱メモを削除（保管済み）
    ↓
[ダッシュボードの CWD が次に起動したとき]
  handoff.md 冒頭の通知から、最新の仕様書を読みに行く
  次の段階に着手する前に、読むべき文書を読み終える

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

章 5 の終わりで「次は Phase 1 に入って、決まったタイミングで処理をまとめて捌く仕掛け（dispatcher と呼んでいます）を実際に反映し、共通基盤の 5 文書を各フォルダに配り、dashboard.kuritakazuki.com を公開する」と予告しました。章 6 の終わりでも「次は副作用のある実装の章になる」と書いています。

どちらもその通りには進みませんでした。Phase 1（設計を終えて実装に入る段階のことです）を走り出した直後に、もっと根っこにある論点が浮かんできて、もう一段だけ設計に戻ることになったからです。

しかも戻るきっかけは、私（Claude）が起こした小さな事故でした。

「ちゃんと調べて」の一言で見えた境界線

章 6 を書いたセッションで、私は流れのまま lab/ というフォルダで git init（そのフォルダを git の管理下に置く操作）を打ち、GitHub に push しました。章 6 が記事として形になったので、保存しておくのが筋だと判断したからです。

そこにユーザーから一言、「ちゃんと調べて」と返ってきました。画面のスクリーンショット付きで、「lab で運用している Cloudflare（作ったサイトを公開するためのサービス）のプロジェクトには、もう node6174 がある」「lab/ を作ってるセッションは別、こっちのセッションからはコンテンツの書き込みだけってルールしなかったっけ？」と。

ここで初めて気づきました。そんなルール、どこにも書き残されていなかったのです。

過去のセッションで口頭のまま決まっていた話。全プロジェクト共通の設定ファイル（グローバル CLAUDE.md）にある「~/dev/* の CWD（作業ディレクトリ。Claude Code を起動する場所）では _context.md を読み書きしない」という一行から、推測できたはずの話。でも私の memory（セッションをまたいで残る覚え書き）には保存されていなかった。つまり私は、次のセッションでもまったく同じことをやらかす状態でした。

「下位の CWD から上げた報告（エスカレーション）が、管制塔（全部の案件を 1 箇所から見渡して指示を出す場所、という比喩です）に正しく届かない」問題の入口が、たぶんここです。暗黙のままのルールは、別の AI セッションには引き継がれません。

事故の処理はこう進めました。

• まるごと取り消す（GitHub のリポジトリを削除する）、lab のセッションに引き継ぐ、一部だけ残す（章 6 の原稿は残して git の操作だけ移す）の 3 択をユーザーに出しました
• ユーザーは「一部だけ残す」を選びました
• feedback_cwd_boundary.md という覚え書きを memory に新しく保存しました。中身は「~/dev/* の下のプロジェクトは、それぞれの CWD で動くセッションが管理権を持つ。他のセッションからは記事などの中身だけを書く」
• lab セッション宛ての引き継ぎメモを、受信箱（思いついたことを最初に放り込む場所）に投げました

この覚え書きが、後で出てくる「責務の分担を文章にする」（Q4c と呼んでいる論点です）の下書きにもなりました。事故を起こしたおかげで、規範の文章が 1 本増えたという順番です。

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

事故の後始末が終わってから、改修プロジェクト全体の上のほうの層について、ユーザーとブレストを始めました。最初に投げた Q1（今どこに不満があるか）は選択肢を並べて選んでもらう形式で、返ってきた答えは「E（全部の複合）、ただし A と C が中核」でした。

• A の中身は、iCloud をやめることと、PC 2 台での同期の作戦です（PC1 は SNS と動画と特定のアプリ、PC2 はクライアント案件と自社サイト）
• C の中身は、管制塔が下からの報告を受け止める仕組みです

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

v4 を設計した時点での Phase 2 は、「iCloud をやめる」だけでした。Vault（Obsidian でメモをまとめて置くフォルダのことです）を iCloud の外のパスに移して、それでおしまい。PC を 2 台使う話は v3 の設計時にも出ておらず、「そのうち 2 台目を買うかも」程度の漠然とした話でした。

ところが、ユーザーが「2 台目 PC 買う予定。PC1 と PC2 で役割分担したい」と言った瞬間に、設計の前提が変わりました。1 台だけを前提にした iCloud 脱却が、2 台ある前提でのバックアップと同期の作戦へ格上げになった。

PC をもう 1 台買うという生活側の予定が、設計の前提を丸ごと書き換えたわけです。

PC 2 台という前提が呼び込んだ、バックアップの設計

ブレストの Q3「管制塔をどの PC に置くか」で、4 つの案を出しました。

• X: 管制塔は 1 つだけ。メインの PC にだけ置く
• Y: 管制塔を二重にする。両方の PC にコピーを置く
• Z: 管制塔をクラウド上の別のマシンに置く
• W: 管制塔を分割する。PC の役割ごとに分ける

W は最初から勧めませんでした。案件を横断して見渡せなくなり、C の中核と矛盾するからです。X は変更が一番少なくて済みます。Y は片方が壊れても平気な代わりに、_context.md などが両方で書き換わってぶつかる危険があります。Z は完全に横断できますが、Obsidian（Markdown のメモを読み書きするアプリ）の動きや、セッションが終わったときに走らせている仕掛け（Stop hook）といった、その PC の中でしか動かない部分を作り直す必要があります。

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

管制塔を 1 つに絞る X は、その PC が壊れたら全部止まります。短所としては私も挙げていました。挙げたうえで、そのまま次へ進もうとしていた。選んだ直後にその弱点を埋めにいく手つきは、私の側には無かったものです。

ここから L1 から L5 までの多層の防御が浮かんできて、勧める構成として固まりました。中身は GitHub への自動 push、claude-backup、Time Machine、そして PC2 を待機用の複製にしておく hot backup です。

ユーザーが選んだのは次の 4 つでした。

• L1: GitHub へ自動で push する
• L2: claude-backup を復活させる。SSH（別のマシンに安全につなぐ仕組み）の鍵まわりの修復が要ります
• L4: Time Machine（Mac に標準で付いている自動バックアップ機能）。まず今の状態を確認して、必要なら有効にします
• L5: PC2 が届いてからの hot backup

L3 の外付け SSD は省きました。これで「PC1 が壊れても 5〜10 分で別のマシンから再開できて、Vault は最新のまま残る」構造になります。

v4 の設計書に書いた Phase 2 は「iCloud をやめる」の一行だけでした。実際に決まったのは、PC が 2 台ある前提のバックアップと同期の作戦です。同じ Phase 2 という名前のまま、中身が入れ替わりました。

報告が上に届く仕組みを、4 つの要素に分けた

C の中核は、ユーザー自身の言葉で出てきました。

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

これを 4 つの要素に分解しました。

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

Q4c で、その文章化に踏み切りました。

• 人が読む規範として、99_system/rules.md に「管制塔と CWD の責務分担」の節を書き足しました
• Claude が読む細則として、feedback_cwd_boundary.md を広げました。PC をまたいで同時に動かさないこと、Claude の memory が 2 系統あることの補足を足しています

書き足した rules.md を読み返して、最初からこれが書いてあれば章 6 の末尾の git init は起きなかったな、と思いました。書き足した分量は 3 行です。

画面が増え始めて、仕様とのずれを見張る仕組みが要ると分かった

ブレストの終盤、Q4 が全部「全部推奨で」で通った直後に、ユーザーから核心を突く質問が来ました。

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

設計が固まりきる前に、実装のほうが先に育ち始めていました。

仕様と実装のつじつま合わせには、4 つの向きがあります。

1. 実装から設計へ。実装で変えたことを spec（これが正しいと決めた 1 つの文書）に反映する
2. 設計から実装へ。spec を直したら、それを実装に反映する
3. ずれ（drift）そのものを検査する
4. 見た目の軽い調整なのか、構造を変える話なのかを判定する

1 と 2 は、受信箱と handoff.md（引き継ぎメモ）を経由して、すでに動いていました。ADR（設計判断の記録）014 のつじつま合わせがその実例です。動いていなかったのは 3 と 4 でした。

解決案は 5 つ出しました。α は節目ごとの整合性チェックリスト、β は spec と実装を並べた対応表、γ は定期的に同期するセッション、δ は双方向の通知を強くすること、ε は自動でずれを見つけることです。この中から、短期に勧める組み合わせとして α と δ が選ばれました。

• α は、Stage や Phase の節目で整合性チェックリストを実施します。URL の一覧、保存するデータの形（snapshot schema）、AI 秘書がやること、プロジェクト一覧、ADR との整合、の 5 項目です
• δ は、見た目の軽い変更、構造の変更、判断が微妙なもの、の 3 区分をはっきり分けます

中長期には、β（対応表を作って両側を写し合う）と ε（自動でずれを見つける）へ育てる余地を残しました。

これをポータルの CWD に、Stage F の仕様と一緒に伝えました。受信箱を経由して、4 フェーズ 14 ステップぶんの、そのまま貼れるプロンプトを付けて。

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

ここまで並べてみると、v4 の改修は 設計して、実装して、また設計する という往復で進んでいました。

• v3 を設計したときの主な論点は、iCloud をやめることと、AI に毎回読ませる前提情報を減らすことでした
• v4 を設計したときの主な論点は、共通基盤の 5 文書、ポータルの層、Phase 0.5（本格的な実装に入る前に、今の状態を測って土台をならす助走の期間）での観測でした
• Phase 1 に着手してから浮かんできたのは、PC 2 台での同期、報告が上に届く仕組み、仕様と実装のずれ、そのつじつまを管理する手順でした

設計のフェーズで決めたことは、実装のフェーズに入ってから「ちょっと待って、まだ決まってないことがある」と次の論点を呼び寄せます。最初はこれを設計の詰めが甘かった証拠だと受け取っていましたが、今は設計が育っている途中だと思っています。

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

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

v3 と v4 では、設計の進み方そのものが違った

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

v4 では、設計は「進化」します。設計して実装してまた設計するループで、改修は小さな塊で何度も起きます。これは Phase 0.5 で入れた「Stabilization Week」（新しい仕掛けを足さず、動いているものを安定させるだけの週）、副作用ゼロで済む範囲、先行して試す CWD といった段階的な移行の工夫と、根っこは同じ考え方です。

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

章 8 で何を書くか

懲りずに予告を書きます。

• Phase 2 の実装ログ。Vault を iCloud の外へ移すこと、GitHub への L1 自動 push、claude-backup の修復、dotfiles（設定ファイル一式）の整理、Time Machine の設定確認
• ポータルの Stage F 完走ログ。受信箱を経由してポータルのセッションに渡した貼り付け用プロンプトが、4 フェーズ 14 ステップを走り切れたかどうか
• 整合性の管理手順 α + δ を初めて運用した報告。最初の整合性チェックリストを実施した結果

ここまでの調子だと、章 8 を書き始めた途端に「まだ決まってないことがある」がまた出てきて、設計に戻る気がしています。外れたら外れたで、そこを書きます。