• #eurekapu
  • #boki3
  • #リファクタリング
  • #Codexレビュー
  • #Vue
  • #計画書
開発eurekapu-nuxt4メモ

boki3（CF計算書3級編）の章順並び替えとexam削除を Codexレビュー付きで実施した記録

eurekapu の CF 計算書 3 級編（boki3）の章順を、別教材である steps（CF 計算書のライフサイクル別解説）と揃える作業をした。boki3 の章は以前ばらばらの順序で並んでおり、株主資本・借入金・運転資本といった主要トピックが steps 側の流れと噛み合っていなかった。読者が boki3 → steps へ進むときに章の位置がずれて見える違和感を、コードと設定ファイルだけで解消したい。Excel と Python スクリプトには触らない方針で、Web アプリ側の 8 ファイルを 1 コミットに集約した。

途中、計画書を一度上書きしてしまうハプニングが発生し、git staging から復元する寄り道を挟んだ。さらに Codex レビューで「Phase 間に中途半端な状態が残る」と指摘され、exam 削除を Phase 7 に集約し直す設計変更を入れた。最終的にはコミット e7462d7 として 1 コミットにまとめ、ブラウザで章順・ch4 の旧株主資本ページ・/boki3/exam の 404 化まで動作確認した。

今日やったこと

1. 章順をライフサイクル順に揃える方針

boki3 の章は、もともと簿記 3 級の試験範囲をなぞる形で並んでいた。一方 steps 側は「会社のお金の流れ（ライフサイクル）」を軸に並んでいる。

  • 株主資本（出資・配当）
  • 借入金（融資・返済）
  • 運転資本（売上・仕入・経費）
  • 設備投資
  • まとめ

boki3 の章タイトルだけ書き換えても、ファイル名とルーティングがずれて保守が難しくなる。逆にファイル名まで全部リネームすると差分が膨れて怖い。今回は「章番号の付け替え」と「ナビゲーションでの並び順入れ替え」だけで、ファイル名はそのまま残す方針にした。

2. 計画書作成 → Codex に上書きされるハプニング

memo/2026-04-24/cf-boki3-reorder-plan.md に計画書を書いた。途中で Codex に「この計画レビューして」と渡したら、Codex が 同じパスに自分の改稿版を書き戻してしまった。元の計画書がディスク上から消えた。

一瞬血の気が引いたが、計画書を書いた直後に git add していた記憶があった。staging には残っているはずだ。

# staging に残っているか確認
git diff --cached -- memo/2026-04-24/cf-boki3-reorder-plan.md

# staging から復元（HEAD ではなく index から取り出す）
git checkout -- memo/2026-04-24/cf-boki3-reorder-plan.md

git diff --cached で staging に元の内容が残っているのを確認し、git checkout -- で working tree に書き戻した。Codex が書いた改稿版は別ファイル（cf-boki3-reorder-plan-codex.md）として退避し、後で必要な指摘だけを元の計画書にマージする形にした。

学んだのは「Codex に計画書のパスを渡すときは、そのパスに書き戻される可能性を前提にする」ということ。次からは Codex 用に別パス（-review.md 接尾辞など）を渡す。

3. Codex レビューで指摘された Phase 間の中途半端状態

復元した計画書を Codex に再度レビューしてもらったところ、致命的な指摘が 1 つあった。

Phase 4 で章順を入れ替えた直後に、Phase 5 で exam リンクの一部だけ削除すると、その時点でデプロイすると「章順は新しいのに exam リンクは古いまま」という中途半端な状態が現れる。Phase をまたぐリファクタリングは、各 Phase の終端で必ずデプロイ可能な状態にする方が安全。

最初の計画では exam 削除を Phase 4・Phase 5・Phase 6 にまたがって少しずつ進める設計だった。途中で作業が止まったらサイトが壊れる。

これを Phase 7 に exam 削除を一括集約 する形に書き直した。Phase 0〜6 までは exam ページと exam リンクをまったく触らず、Phase 7 で「exam ページを 404 化」「全 exam リンクの一括削除」「steps への導線追加」を一気にやる。Phase 6 が終わった時点でも、Phase 7 が終わった時点でも、サイトは壊れない。

# 修正前（Codex 指摘前）
Phase 4: 章順入れ替え + 一部 exam リンク削除
Phase 5: 残り exam リンク削除
Phase 6: 章番号付け直し
Phase 7: 動作確認

# 修正後（Codex 指摘反映）
Phase 4: 章順入れ替えのみ
Phase 5: 章番号付け直し
Phase 6: 配当セクション削除
Phase 7: exam 一括削除（404 化 + 全リンク削除 + steps 導線追加）
Phase 8: 動作確認

4. 配当セクションを boki3 から削除

boki3 の旧 ch3 に「貸付金等の配当」セクションがあった。steps 側にも同じ内容があり、教材として重複している。boki3 は「教材 A」（試験範囲を最短でなぞる教材）として位置づけたいので、配当の詳細は steps（教材 B）に寄せ、boki3 からは丸ごと削除した。

該当 Vue ファイルからセクションを削除し、目次（contents.vue）から配当への内部リンクも削除。配当について深掘りしたい読者向けに、章末から /cf-steps/dividends への導線リンクを 1 行だけ残した。

5. exam ページの 404 化と steps 導線

/boki3/exam は元々、各章の練習問題をまとめた仕上げページだった。今回 boki3 を教材 A として軽量化する方針に合わせて、exam ページは丸ごと廃止する。

<!-- apps/web/app/pages/boki3/exam.vue -->
<script setup lang="ts">
// 教材 A 化に伴い exam ページは廃止。
// 既存リンクや検索流入は 404 で受ける。
throw createError({ statusCode: 404, statusMessage: "Not Found" })
</script>

throw createError で SSG ビルド時に 404 を返す形にし、ルーティング自体は残しつつコンテンツを消した。各章の末尾に置いていた「次の章へ」「exam へ進む」のうち、後者を「steps で実務的な流れを学ぶ」リンクに差し替えた。

6. Phase 0〜8 の実装と 1 コミット集約

計画書の Phase 0（バックアップ確認）から Phase 8（動作確認）までを、1 セッションで連続実行した。

  • Phase 0: 関連ファイルの git status 確認・dry-run
  • Phase 1: 章番号定数の整理（useBoki3Chapters composable）
  • Phase 2: ナビゲーション順序の入れ替え
  • Phase 3: 章タイトル・description の更新
  • Phase 4: 章間の「次の章へ」リンク差し替え
  • Phase 5: 章番号付け直し（ch1〜ch5）
  • Phase 6: 配当セクション削除
  • Phase 7: exam ページ 404 化 + 全 exam リンク削除 + steps 導線追加
  • Phase 8: ブラウザ動作確認

最終的に変更したのは Vue ページ 5 個と composable 1 個、ナビゲーション設定 1 個、ルーティング設定 1 個の 計 8 ファイル。これを「途中で git add -p しつつ動作確認 → 全部まとめて 1 コミット」の流れにし、コミット e7462d7 として確定した。

git add apps/web/app/pages/boki3/ \
        apps/web/app/composables/useBoki3Chapters.ts \
        apps/web/app/components/boki3/Nav.vue
git commit -m "refactor(boki3): chapter reorder to lifecycle order and exam removal"
# [master e7462d7] refactor(boki3): chapter reorder to lifecycle order and exam removal
#  8 files changed, 142 insertions(+), 217 deletions(-)

リファクタリング系のコミットは小さく分けたくなるが、今回のように「中途半端な状態でデプロイされると壊れる」場合は 1 コミットに集約した方が安全だと判断した。Codex の指摘がそのまま「コミットの粒度」にも効いた格好だ。

7. ブラウザでの動作確認

pnpm dev を立ち上げ、Chrome で 3 点を確認した。

  • 章順: /boki3 のトップで章リストがライフサイクル順（株主資本 → 借入金 → 運転資本 → 設備投資 → まとめ）に並んでいる
  • ch4 ページ: 旧「株主資本」だった ch4 の URL を踏むと、新しい章番号でリダイレクトされず、内容も新しい配置で表示される
  • /boki3/exam の 404 化: ブラウザで /boki3/exam を直接開くと 404 ページが返る

特に 3 点目は SSG ビルドだと dev では確認しきれない懸念があったので、pnpm generate && pnpm preview でビルド済み静的ファイルからも 404 を確認した。

今日学んだこと

計画書を Codex に渡すときは別パスを渡す

Codex に計画書のレビューを頼むと、Codex は親切のつもりで 同じパスに改稿版を書き戻す。今日はたまたま staging に残っていたので復旧できたが、staging に上げる前だったらディスクから消えていた。

次からは Codex に渡す前に cp plan.md plan.md.bak でバックアップを取るか、Codex 用に別パス（plan-for-codex-review.md）を渡す運用にする。staging に置いておくと「あれ、ここに置いたはずだけど消えた」と気づいたあと冷静に git checkout -- で復元できる。

Phase 間の中途半端状態を避ける

Codex の指摘で一番効いたのが「Phase の境目で必ずデプロイ可能な状態にしろ」というもの。最初の計画では exam 削除を 3 つの Phase にまたがって進めていたので、途中で作業が止まると章順だけ新しくて exam リンクだけ古い、というキメラ状態が発生する。

Phase ごとに「ここで止めてデプロイしても、ユーザーから見て壊れていないか？」を自問するクセをつけたい。今回は exam 削除を Phase 7 に一括集約することで、Phase 6 終わりまでは「旧仕様完全」、Phase 7 終わりからは「新仕様完全」と二状態に絞れた。

教材 A / 教材 B の方針が決まると削除がやりやすい

「boki3 を教材 A、steps を教材 B」と方針が言語化された瞬間、配当セクションを boki3 から削除する判断と、exam ページを丸ごと廃止する判断が連鎖的に決まった。方針なしで「このセクション要る？要らない？」を 1 個ずつ悩むと判断が揺れるが、教材 A/B の役割が決まっていれば「これは教材 B の責任範囲」と即決できる。

明日やること

  • steps 側の章末に「boki3 の対応章へ戻る」リンクを追加して、教材 A↔B の往復導線を完成させる
  • Codex 用の計画書バックアップ運用を、自分の Claude Code rules に書き足す（plan-codex-review.md の更新）
  • exam 廃止を README やサイトマップにも反映し、内部検索で /boki3/exam がヒットしないか最終確認する