← retrospectives の一覧

個人開発の振り返り ｜ 2026.09.26 – 10.11

cc-sdd をどう拡張して、
「ことのは」を作ったか

子供のことばを記録する iPhone 向けアプリ（PWA）を、仕様駆動開発のツール cc-sdd を土台に作成。
cc-sdd の流れはそのまま活かし、書き手を 1 つに絞る・独立した見張りを置く・決めるのは人、の 3 点を定めた。
このページは、どこが cc-sdd のままで、どこに手を加えたのかを示す。

cc-sdd のまま使ったもの このプロジェクトで足したもの 人が決める・確かめる

数字で見る

16日開発期間最初のコミットから見た目の作り直しのマージまで
7spec完了した specインフラ土台から UI 作り直しまで。ほかに 1 つは見送り
333コミットタスクごとに、レビューを通してから 1 コミット
41回Codex のレビュー設計 15 回・実装 26 回。すべて記録に残した
26不変条件「評価を保存しない」など、レビューの最優先の観点
約2,400自動テスト画面 1,035・API 373・インフラ 985

4 者の役割 ―― 書くのは 1 つだけ

人が決める・確かめる人（開発者）判断と確認
  • 要件の未決定や、設計の選択肢を決める
  • レビューを続けるか打ち切るかを決める
  • /kiro-impl を自分で打ち、実機で確かめ、PRを承認する
拡張Claude（チャット）オーケストレータ
  • 出力を読み、判断の材料とおすすめを示す
  • Claude Code に渡す指示文を作る
  • リポジトリは読むだけ。書かない
cc-sddClaude Code唯一の書き手
  • 要件・設計・タスク・実装・修正をすべて担う
  • /kiro-impl でタスクごとに実装役・レビュー役を起こす
  • 指摘には 1 件ずつ「直した／直さない」で返す
拡張Codexレビュー専任
  • 読み取り専用。ファイルを変えない
  • 仕様と差分だけを見る。会話や推論は渡さない
  • 不変条件の違反を最優先で探す

人 と Claude が相談して決める 指示文を Claude Code に渡す Claude Code が書く Codex が読むだけでレビュー Claude Code が「直した／直さない」を返答 人が判断

1 つの spec が通る道

  1. 01ロードマップと brief
    spec の分け方と順番を決める
    cc-sdd
  2. 02要件
    EARS 形式の受け入れ基準。未決定は人に聞く
    cc-sdd人
  3. 03設計と自己確認
    design.md を作り、validate-design で自分で見直す
    cc-sdd
  4. 04ゲート A：設計レビュー
    Codex が読むだけで見る。必須・最大 2 往復
    拡張
  5. 05タスク
    実装の単位に分ける。人が承認する
    cc-sdd人
  6. 06実装ブランチ
    仕様は main、実装は spec 名のブランチ。設計の直しはブランチで
    拡張
  7. 07/kiro-impl
    タスクごとに実装役 → 独立レビュー役 → デバッグ役
    cc-sdd拡張
  8. 08ゲート B：実装レビュー
    タスクの範囲を渡して Codex が見る。数回に分けて回す
    拡張
  9. 09validate-impl
    全体のテストと、要件の網羅を確かめる
    cc-sdd
  10. 10実地確認
    spec ごとの手順書で、二人の iPhone で確かめる
    拡張人
  11. 11PR と最後のレビュー
    GitHub の Codex が自動で見る。merge commit で入れる
    拡張人
  12. 12記録を残す
    レビューと返答、判断の理由を tasks.md と docs/reviews/ に
    cc-sdd拡張

モデルの使い分け

拡張・最後に追加

開発中はすべて Opus で動かしていた。費用の大半は、コードを大量に読み書きする実装役。判断の重い段階と独立したレビューは Opus に残し、手を動かす役と、テストの要約だけを軽いモデルに回した。

役モデル理由
親（オーケストレーション）Opus流れ全体の判断
要件・設計・タスク・validateOpus量は少なく、判断が重い
実装役Sonnet費用の大半。仕様とテストが決まった中で手を動かす
レビュー役・デバッグ役Opus独立した目と原因の調べは質を保つ
test-runnerHaiku長いテストのログを読んで要約するだけ
外部レビューCodex別系統のモデルで、同じ癖の見落としを減らす

Codex レビューの仕組み

拡張
ゲート A　設計のあと必ず回す。最大 2 往復、残れば人が判断。誤りがタスクと実装に広がる前に止める、いちばん効く場所
ゲート B　実装のあと同期の中心・データの層・インフラに触れたら必ず回す。タスクの範囲を渡して、未着手の分を指摘させない
  • 独立性は、渡すもので保つ。Codex には仕様と差分だけを渡し、Claude の会話や推論は渡さない。ファイルも変えさせない（AGENTS.md）
  • 観点の最優先は 26 の不変条件。違反はどんなに小さく見えても blocker
  • 結果は書き換えず残す。docs/reviews/ に保存し、指摘ごとに「直した／直さない（理由）」を response.md に書く
  • 止めどころを決める。指摘が珍しい場面に移ったら打ち切る。壊れやすい道は継ぎはぎより単純化する
  • マージ前にもう一度。PR を開くと GitHub の Codex が自動でレビューする

cc-sdd のまま使ったもの

  • steering（product・tech・structure）で、前提をすべての会話に渡す
  • 要件 → 設計 → タスクの 3 段階と、段階ごとの人の承認（spec.json）
  • EARS 形式の受け入れ基準
  • validate-gap・validate-design・validate-impl による自己点検
  • /kiro-impl のタスクごとのサブエージェント（実装 → 独立レビュー → デバッグ）
  • Implementation Notes で、タスク間に学びを引き継ぐ
  • verify-completion：新しい証拠なしに「完了」と言わない
  • /kiro-impl はモデルからは起動せず、人が打つ

このプロジェクトで足したもの

  • invariants.md：26 の不変条件。全段階で読み込み、守れない設計は人に相談
  • AGENTS.md：Codex をレビュー専任にし、実装者の説明を根拠にさせない
  • ゲート A・B のスクリプト：設計と実装を Codex に見せ、結果を自動で保存
  • レビューの記録：結果は書き換えず、指摘ごとに「直した／直さない（理由）」
  • 止めどころ：2 往復で人が判断。珍しい場面に移ったら打ち切り、単純化を選ぶ
  • ブランチの決まり：仕様は main、実装はブランチ、merge commit で入れる
  • spec ごとの実地確認の手順書。実データは手順書にもリポジトリにも書かない
  • 設計メモは人のもの：変えるときは提案として示す
  • モデルの使い分けと、テストを要約する test-runner（Haiku）
  • チャットの Claude をオーケストレータに置き、判断と指示文を整理

仕組みが止めたもの（実例）

ゲート Ablocker
動画を付けただけで、相手が直した本文を古い本文で上書きする設計の段階で発見。本文が変わっていなければ発話を書かない、という決まりにして実装前に塞いだ
ゲート Bblocker
遅れて届いた古い応答が、外した添付を元に戻す継ぎはぎをやめ、行を書き換える道を 1 本に絞る形に単純化して解消
ゲート Bmajor
初回の登録が断られると、夫婦のどちらも子供の情報を直せなくなる子供の情報だけ送信の判定を分け、発話の守りは変えずに解消
人の判断打ち切り
数ミリ秒の間に保存を押したときだけ起きる指摘直さない理由を記録してレビューを終え、実機での確認に回した