配布資料の目次 › 構築年表
配布資料 29構築年表 総覧 — 9ヶ月で何がいつ起きたか
構築年表は5章に分かれています。ドキュメント、大規模変更、規律、実装、運用。 それぞれ独立して読めるように書いたので、章をまたぐと時間の流れが見えにくくなります。
そこでこのページに、5章ぶんの出来事を1本の時間軸に並べ直しました。 全体の流れを先に掴んでから、気になる章に降りていってください。
日付はすべて題材プロジェクトの git 履歴・イシュートラッカー・memory の実測です。
5章の地図
| 章 | 扱うもの | 主に出てくる時期 |
|---|---|---|
| 第1章 ドキュメント駆動の歩み | 文書がどう生まれ、腐り、仕組みで守られたか | 2025-10 〜 2026-07 |
| 第2章 大規模仕様変更の実像 | 事業転換・返金再設計・マルチテナント化ほか5件 | 2026-03 〜 2026-07 |
| 第3章 規律の共進化 | CLAUDE.md・rules・hooks の育ち方 | 2026-03 〜 2026-07 |
| 第4章 実装期のイテレーション | 開発フロー20ステップと検証規律の形成 | 2026-03 〜 2026-07 |
| 第5章 運用成熟期の自動化 | デプロイフロー4世代・監視・自己修復・DR | 2026-03 〜 2026-07 |
4つの局面
9ヶ月は、大きく4つの局面に分かれます。
序章（2025-10 〜 2025-12）。 別サービスを試作しながら「そもそも何を作るか」を探していた時期です。一度は全面作り直しをしています。ただし初回コミットの時点で計画文書9本が同梱されていて、コードより先に文書という姿勢は初日から一貫しています。
沈黙（2025-12 〜 2026-03）。 コミットが約2.4ヶ月まったく止まります。リポジトリの外で要件定義を書き切っていた期間です。グラフ上は完全な空白ですが、ここがその後の速度を買いました。
実装期（2026-03 〜 2026-05）。 9分間で要件57本が入り、3日後に実装が始まります。ここで開発フローの骨格と、検証の規律と、最初の hook が生まれます。事故もこの時期に集中しています。
成熟期（2026-05 〜 2026-07）。 大規模な仕様変更、全数監査、デプロイの無人化、災害復旧のリハーサル。規律が「作業の規律」から「人間と AI の権限関係の統治」へ移っていきます。
年表
序章 — 2025年10月〜12月
| 日付 | 出来事 | 章 |
|---|---|---|
| 2025-10-15 | 初回コミット。事業計画書・要件仕様書・システム設計書など計画文書9本を同梱 | 1 |
| 2025-12-23 | 序章の試作、最終コミット。ここからコミットが途絶える | 1 |
沈黙 — 2025年12月〜2026年3月
| 日付 | 出来事 | 章 |
|---|---|---|
| 〜2026-03-03 | 約2.4ヶ月、コミットがゼロ。 リポジトリ外で要件定義を執筆 | 1 |
実装期 — 2026年3月
| 日付 | 出来事 | 章 |
|---|---|---|
| 03-04 | 9分間の3コミットで約100文書を一括インポート（機能別要件57本・設計11本・画面設計9本・AI リサーチ2本） | 1 |
| 03-04 | CLAUDE.md 初追加（15行）。 事業転換コミットに同梱された散文メモ | 3 |
| 03-06 | 外部サービス文書9本。ワイヤーフレーム129枚（約29,000行）を一括追加してデザインの正本を確定 | 1 |
| 03-07 | 実装開始。 Phase 0 完了、以降3日で Phase 1〜12 | 1 |
| 03-10 | イシュートラッカー導入。 イシュー駆動運用が始まる | 1 |
| 03-10 | 初代デプロイ CI 誕生（staging / production ワークフロー） | 5 |
| 03-11 | テスト文書カテゴリが誕生（実装開始の直後） | 1 |
| 03-16 | 環境構築カテゴリが誕生（staging 構築期） | 1 |
| 3月中 | 検証の是正 第1段階「ふりの排除」。 実装開始2週間で同じ日に3件 | 4 |
| 03-30 | staging 実機を構築。 デプロイ G2（スクリプト化 + 完了マーカー）へ | 5 |
| 03-30 | Prometheus + Grafana を compose 同居で導入 | 5 |
| 3月末 | CLAUDE.md が477行に肥大（ピーク）。hooks はまだ0本 | 3 |
規律が生まれる — 2026年4月
| 日付 | 出来事 | 章 |
|---|---|---|
| 04-02 | CLAUDE.md 大凝縮（504行 → 47行）。 詳細を .claude/rules/ 7本へ分散 |
3 |
| 04-02 | 初代デプロイ CI を完全停止し workflows-disabled/ へ隔離（削除せず遺構として保存） |
5 |
| 04-05 | 開発フローに「まず dev、それから staging」の2段検証と、失敗時の即時修正イテレーションを追加 | 4 |
| 04-06 | 最初の hook が生まれる。 マージ事故で消えたコード468行を復元する、その PR の中で | 3 |
| 04-07 | スカッシュマージ禁止を明文化。開発フロー20ステップが確定 | 3, 4 |
| 04-16 | Done は staging ブラウザテスト完了後のみに限定 | 4 |
| 04-22 | 任意バッチデプロイを初導入（同一 epic・5タスク以内の厳格条件つき） | 4 |
| 04-29 | 「無限待機・非完了」事故を受けてデプロイ G3（非同期起動 + watchdog + 状態ポーリング）へ | 5 |
| 4月末 | hooks 7本（ブラウザテスト強制・マージ手順・テスト skip 検知・Done ガード） | 3 |
深さを強制する — 2026年5月
| 日付 | 出来事 | 章 |
|---|---|---|
| 5月第1週 | 並列エージェントの衝突と「全要件実装」の欠落。自己申告を信じない検収の型が確立 | 4 |
| 05-03 | バックアップのサイレント失敗（1回目）。 実行権限漏れで全期間失敗 → 同日に鮮度監視スクリプトを新設 | 5 |
| 5月中 | 検証の是正 第2段階「深さの強制」。「ステージングでブラウザテストした？」で3件差し戻し。価値到達点の定義が生まれる | 4 |
| 5月中 | E2E ランナーが「471 passed」と偽って正常終了。「このコマンドは実行しない」という結論へ | 4 |
| 05-09 | 法務カテゴリ誕生 | 1 |
| 05-14 | ホワイトラベルカテゴリ誕生。マルチテナント化の設計 exploration（確定事項20項目）を1日で作成 | 1, 2 |
| 05-15 | 返金カテゴリ誕生。返金設計で AI の案を8回却下し、絶対禁止事項リストを同日に rules 化 | 1, 2 |
| 05-21 | バックアップの19日間サイレント失敗が発覚。 鮮度監視スクリプト自体が本番未配備だった | 5 |
| 05-30 | リファクタリングカテゴリ誕生 | 1 |
| 5月末 | hooks 11本（言行一致・デプロイ監視・記憶インフラ） | 3 |
較正と全数監査 — 2026年6月
| 日付 | 出来事 | 章 |
|---|---|---|
| 6月中 | 検証の是正 第3段階「過剰の較正」。 規律を厳しくしすぎた副作用を緩める方向に直す | 4 |
| 06-02 | 体系外に散乱した7ディレクトリを正規体系へ吸収 | 1 |
| 6月中 | バグ1件から全数監査へ拡張。18クラスタ並列監査で173件を検出（inline style 7,868箇所を含む） | 2 |
| 06-27 | デプロイ CI 再誕（CI でビルドしてイメージを VPS へ直送する build-ship 方式） | 5 |
| 06-30 | 文書の棚卸しで3種類の劣化（散乱・重複衝突・陳腐化の同居）を実測 | 1 |
| 06-30 | レプリケーション監視・スタンバイ監視を追加。DR 構築とフェイルオーバーリハーサルを1日で完遂 | 5 |
| 6月末 | hooks 17本（出力書式の三層・ロール注入・テーマトークン・禁止 API） | 3 |
統治へ — 2026年7月
| 日付 | 出来事 | 章 |
|---|---|---|
| 07-01 | 文書の全面再編（20ディレクトリを日本語名に・重複解消・DR 正本の一本化） | 1 |
| 07-01 | デプロイ G4（CI ビルド先行 + ローカル一括ラッパー）へ | 5 |
| 07-02 | 再編の翌日に doc-ownership.tsv と hook 3本を導入。腐らせない仕組みまで作る | 1 |
| 07-02 | バッチデプロイがデフォルト運用へ。「In Review = デプロイ待ちキュー」の意味論が確定 | 4, 5 |
| 07-12 | CPU steal アラートを同日中にコードで実装 → staging で導通実証まで1セット | 5 |
| 07-14 | push 時の自動フルビルドを撤去（2週間で約80回、無料枠の主消費源だった） | 5 |
| 07-15 | CI 無料枠 2,000分/月が枯渇して全停止。 4時間レートリミット hook を機械化 | 5 |
| 07-16 | dev テストのバッチ化を公式化しつつ、per-PR 最低ゲートは必須と境界を固定 | 4, 5 |
| 07-16 | 営業資料カテゴリ誕生 | 1 |
| 07-17 | 現在地: 文書 274件・80,654行 / hooks 24本 / CLAUDE.md 179行 / 統治コード 約3,855行 | 1, 3 |
この年表から読み取れること
規律は事故のあとにしか生まれませんでした。
hooks の誕生日を追うと、その直前に必ず事故があります。4月6日の最初の1本はマージ事故の復元 PR の中で、7月15日の4時間ガードは無料枠の枯渇の翌日です。 「整備プロジェクト」を立てた日は、9ヶ月で一度もありません。
厚くなったのは検証だけでした。
開発フローは4月7日に20ステップで確定して以降、3ヶ月ほとんど変わっていません。 その間の改訂はすべて検証側の強化です。何を大事にしたのかが、この年表にそのまま出ています。
同じ失敗が形を変えて何度も出てきます。
バックアップのサイレント失敗は2回。SSH 切断の系統は4回。ツール呼び出しの書式ミスは27日かけて三層防御になりました。 一度で直ったものは、ほとんどありません。
数字が伸びたのは、規律を足したあとです。
コミット数は3月の585から6月の1,796へ。同じ期間に完了リードタイムの中央値は0.6時間から5.5時間へ伸びています。 遅くなったのではなく、「完了」の定義が重くなりました。それでも量は落ちていません。