不動産投資ガイド /fudosan-toshi に5STEP構成のイントロを足し、9章すべてにパンクズを通した

開発mdx-playground

/fudosan-toshi（玉川メソッド4冊統合の不動産投資ガイド）を開いたとき、ハブから章へ飛んだあと「戻る導線」がなくて指が宙を彷徨った。同じ違和感を /tokibo で先に解消していたので、同じ作法を fudosan-toshi にも横展開した。ついでに、9章ある章一覧そのものが「何から読めばいいか」を示せていなかったので、tokibo の intro と同型の「全章の見取り図 + 章別サマリー」ページを差し込んだ。

このログは、午前のパンクズ統一から午後の intro 実装までを、一本の流れとして残しておく。

違和感: ハブから章に飛んだら戻れない

朝、http://localhost:3000/fudosan-toshi を開いてガイド章を読んだあと、画面上に戻りリンクが見当たらないことに気づいた。ホームや他のページにはパンクズが通っているのに、/fudosan-toshi 配下の13ページだけ抜けている。

最初は「13ページに同じ HTML を貼って回る」のがまっすぐな選択肢に見えたが、すぐに却下した。/tokibo でも同じ問題を解いたとき、各ページに同じスニペットを貼るのではなく、layout を1枚作って差し込む方式で片付けたのを思い出したからだ。

Claude Code に「tokibo と同じ層に fudosan-toshi レイアウトを切って、各ページは definePageMeta({ layout: 'fudosan-toshi' }) を1行足すだけにしてほしい」と指示した。

レイアウトに集約してパンクズを通す

レイアウト方式に決めたあと、Claude Code に次の作業を順に進めさせた。

  • apps/web/app/layouts/fudosan-toshi.vue を新規作成し、<Breadcrumb /> をヘッダー直下に置く
  • /fudosan-toshi 配下の13ページに definePageMeta({ layout: 'fudosan-toshi' }) を1行追加
  • apps/web/app/utils/breadcrumbs.ts に各 path のラベルを登録

実装が走り終わってから、ハブ・ガイド章（zentaikan / bukken / yushi 等）・Q&A 章の3パターンをそれぞれブラウザで開いて、パンクズが「ホーム > 不動産投資ガイド > 第N章」の形で並ぶことを確認した。フォントサイズも左マージンもホームと揃っていて、追加コードがレイアウトに閉じている分だけ、章ページ側の Vue は触らずに済んでいる。

breadcrumbs.ts を触ったので、ユニットテストも追加した。pnpm test:run で31テスト全部 pass。これで午前パートは閉じた。

違和感その2: 9章の地図がない

/fudosan-toshi のハブをもう一度開いたとき、今度は別の違和感に手が止まった。章カードが9枚ベタッと並んでいるだけで、「どれから読むのが自然か」「章同士がどう繋がるのか」が見えない。

これも /tokibo/intro で先に解いていた問題だった。tokibo は8章を4STEPでグルーピングした「全章の見取り図」を SVG で描いて、初見の読者がそこから入れるようにしてある。同じパターンを fudosan-toshi にも持ち込みたかった。

別セッションで計画書だけ先に書いて、memo/2026-06-14/fudosan-toshi-intro-plan.md に置いておいた。9章ある分、tokibo の4STEP より1STEP増やして5本立てにする方針も計画書側で決めた。

5STEP の配分: 9章を「読む順番」に組み替える

計画書で決めた配分はこうなった。

  • STEP 00 — 全体観をつかむ: 序章（玉川メソッドの4本柱）
  • STEP 01 — 何を買うかを決める: 第1章 収益とIRR / 第2章 物件選定
  • STEP 02 — 仕組みを整える: 第3章 銀行融資 / 第4章 税金
  • STEP 03 — 運営して出口へ: 第5章 賃貸運営 / 第6章 出口戦略
  • STEP 04 — 規模拡大とリスク: 第7章 資産管理と財務 / 第8章 シナリオ分析

最初は「収益指標」と「物件選定」を別 STEP にしようかと迷ったが、玉川メソッドの本筋が「IRRで測れる物件をIRRで選ぶ」と一本道だったので、同じ STEP に押し込んだ。「仕組みを整える」も同じで、融資と税金は別の話に見えて、レバレッジを掛けた瞬間に税の話が連動して走り出すので、ここも同居させた。

STEP 00 だけはカード1枚で全幅、STEP 01-04 は左右に2枚並ぶ。viewBox は当初 720 × 880 を見積もったが、実装中に STEP 04 のカードが収まらなくて 720 × 968 まで縦に伸ばす羽目になった。8の倍数で刻むベースライン規律は守った。

計画書を Codex に3回投げる

ExitPlanMode する前に、計画書を codex exec -m gpt-5.5 でレビューしてもらった。グローバルルールに「致命的な点だけ指摘して、瑣末なクソリプはしないで」と添えて投げる作法を仕込んである。

初回レビューで返ってきた致命的指摘は3点あった。fudosan-toshi の章 URL が /fudosan-toshi/guide/{slug} の形（途中に guide が入る）で tokibo のフラットな /tokibo/{slug} と違うこと、TOC の id プレフィックスが衝突しないように fudosan-intro-h-{i} に切り替える必要があること、ハブの .hub-card が tokibo と DOM 構造が違うのでスタイルを流用しきれないこと。どれも実装中にハマる地雷だったので、計画書側で先に明文化した。

codex exec resume --last で2回目を回したら、SVG ルール側の指摘が来た。塗りで分離するルール（<rect> の stroke 禁止、rx 禁止）と、サブタイトルに結論文を昇格させて図下にキーメッセージを別置きしないルール。これは午前のグリッド移行作業（後述）で固めた規律と同じなので、計画書本文に章ごとの SVG 設計（viewBox サイズと推奨レイアウト）を書き足した。

3回目で「致命的な指摘はない」と返ってきたので、計画書を確定して別セッションでの実装に渡した。

並列実装: 5フェーズを一気に走らせる

実装セッション側では、計画書の Phase 1 〜 Phase 5 を頭から順に Claude Code に流させた。

  1. breadcrumbs.ts に /fudosan-toshi/intro のラベルを追加
  2. FudosanIntroMap.vue を TokiboIntroMap.vue から派生して5STEP構成に組み替え
  3. FudosanIntroBody.vue を TokiboIntroBody.vue から派生して9セクション分のリードと SVG 図解を新規実装
  4. pages/fudosan-toshi/intro.vue を薄いページシェルとして作成
  5. FudosanHub.vue の章カード群の手前に「イントロダクション」カードを差し込み、hub-card--intro クラスでマゼンタ左ボーダーを当てる

Phase 2 の途中で「STEP 04 が抜けていました。viewBox を広げて第7-8章のカードを追加します」とログに残っていて、計画段階で STEP 04 を見落としかけたのが透けて見える。グリッドの縦幅を伸ばす方向で吸収してもらった。

Phase 6 のブラウザ検証では Chrome DevTools MCP を使ってナビゲートと CTA リンクの先を全部踏ませた。9セクションすべてに /fudosan-toshi/guide/{slug} が正しく刺さっていることを目視確認。SVG をクリックして拡大モーダルが開き、Esc で閉じる挙動も問題なし。

副産物: 9章の SVG をグリッドに揃え終えた

イントロ実装と並行して、午前から memo/2026-06-14/fudosan-toshi-grid-migration-plan.md 側の作業も走らせていた。これは /fudosan-toshi 配下の全 SVG（Guide 57 + QA 77 = 約128枚）を、Müller-Brockmann グリッドルール（viewBox 720×N、12カラム、塗りで分離、rx 禁止）に揃えるタスク。

Phase 1.1 で Zentaikan（1図）を片付けたあと、Phase 1.2 を Yushi / ShuekiIrr / Zaimu / Zeikin / Scenario / Unei / Deguchi の7章に分けて、サブエージェントを並列起動して書かせた。1章 = 1サブエージェント。Q&A 側13章も同じ要領で並列に処理して、午後の途中で全 128 枚のグリッド化が終わった。

並列で走らせる利点は、メインセッションのコンテキストが SVG 文字列で膨らまない点。1ファイル平均150行 × 128ファイル = 約 19,200 行をメインで読んでいたら、tool call malformed で落ちていた可能性が高い。

イントロページに埋め込んだ9枚の SVG 図解も、この同じグリッドルールに沿って描いた。Inter + Noto Sans JP、タイトル font-size 20 / サブタイトル font-size 15、#111315 ink と #ed1e79 マゼンタアクセント。tokibo の SVG と並べても、同じ言語で書かれた図に見える。

学び: レイアウト1枚で「13ページ分の編集」を1ヶ所に集約する

今日の作業を通して、改めて手応えがあったのは「同じ違和感を13回直しに行かない」設計判断のところ。

  • パンクズを13ページに貼って回るのではなく、layouts/fudosan-toshi.vue に集約する
  • 章URLのラベルを13箇所に分散させずに utils/breadcrumbs.ts に集約する
  • 章の見取り図を各章ページに書き散らさず、/fudosan-toshi/intro に集約する

tokibo で先に正解パターンを踏んでいたからこそ、fudosan-toshi 側で同じ判断が秒で出せた。1回目で迷って正解を引いた経験を、2回目で再利用するときの速度の差は大きい。

もうひとつ、計画書を ExitPlanMode する前に Codex に3回投げる作法も、今日効いた。1回目で章URL構造の差分、2回目で SVG ルール、3回目で「致命的指摘なし」と落ちる流れになっていて、計画段階で潰せた地雷が実装フェーズで顔を出さなかった。

残タスク

  • /fudosan-toshi トップと各 Guide / 各 QA 章のブラウザ目視確認（chrome-devtools MCP がハング気味なので、ユーザー手元の dev で巡回するのが早い）
  • 旧 Diagram の削除タイミングを別計画書に切り出す（比較期間中は新旧並列表示のまま）
  • 本番デプロイ後の _payload.json 検証（/fudosan-toshi/intro が SSG で正しく出るか、useAsyncData を使っていないので payload null 化リスクはないはずだが、デプロイ後に1回踏む）
#fudosan-toshi#イントロダクション#パンクズリスト #SVG #Nuxt