目次

動機：AI コーディングの常習病

こんなことはありませんか：

  • AI に新機能を依頼すると「できました」と返ってくる。しかし PRD はそのチャット履歴の中だけにある。ウィンドウを閉じれば消える。「あの設計、なぜそうしたっけ」を後日確認しようにも、git のコミットメッセージしか残っていない。
  • 実装後にテストを書かせると、通過率 100% の「テスト」を平気で作る。なぜなら実装済みのコードに合わせて書かれただけだから。設計を制約していない。
  • 設計ステップを飛ばして直接コードを書く。アーキテクチャの腐敗は静かに進行。3 か月後に新機能を追加しようとしたら、コードは当初の設計図とは別物になっている。
  • セッションをまたぐと記憶ゼロ。「機能 X、どこまで進んでた？」 — あなたの頭の中だけが頼り。

これらの本質は何か：AI アシスタントはエンジニアリングプロセスを「ソフトな約束事」として扱う — スキップ可能、忘却可能。

PDLC（Product Development Life Cycle）は Claude Code プラグインで、目的は一言で：そのソフトな約束をハードな契約に格上げする。PDLC のワークフローに入ると AI は PRD をスキップできない、テスト無しに実装できない、現在のステージを忘れられない。

実装：3 層構成 + Iron Law + 状態マシン

31 個のコマンド、3 層構成

層 数 役割
第 1 層 · エントリポイント 3 /pdlc-feature、/pdlc-fix、/pdlc-status — 一文のプロンプトでチェーン全体を駆動
第 2 層 · ステージ 11 /pdlc-prd、/pdlc-tdd、/pdlc-implement、/pdlc-review、/pdlc-ship 等 — 単一ステージの細かい制御
第 3 層 · ツール 17 UI 設計 / DB / アーキ / セキュリティ / 性能 / コード生成 / i18n / マイグレーションなどの専門ツール

日常では第 1 層が主役：

# Claude Code 内で
/pdlc-feature ログインに画像認証を追加

このコマンド一つで PDLC が PRD → 設計 → TDD レッドライト → 実装 → レビュー → リリースまでをつなぎます。すべてのステージは Iron Law を満たすことを強制されます。

Iron Law：5 つの不変条件

成果物を生成する第 1 層 / 第 2 層のすべてのステージは以下を満たす必要があります：

  1. 成果物がディスクに保存 — チャット出力だけではない、docs/ 配下に実ファイル
  2. 状態マシンが更新 — 完了したすべてのステージが docs/.pdlc-state/<feature-id>.json を書く
  3. テストファースト — 失敗するテストが無い限り実装はブロック（TDD レッドライト）
  4. セルフチェック — 各ステージはハンドオフ前に自己監査を実行
  5. 自動修復は 1 回のみ — 自動修復は最大 1 回、解決しない問題は人間にエスカレート

これらは推奨ではなく強制。第 1 層 / 第 2 層の成果物生成ステージはこれを飛ばせません — 飛ばせばセルフチェックが失敗する。

状態マシン：機能ごとに 1 つ

新機能ごと（/pdlc-feature ...）に PDLC は F20260515-01 のような ID を発行し、対応するファイルを作成：

docs/.pdlc-state/F20260515-01.json

中身はこんな感じ：

{
  "feature_id": "F20260515-01",
  "slug": "captcha-login",
  "current_stage": "implement",
  "history": [
    {"stage": "prd", "ts": "2026-05-15T10:30:00Z", "self_audit": "8/8 passed"},
    {"stage": "design", "ts": "2026-05-15T11:05:00Z", "self_audit": "6/6 passed"},
    {"stage": "tdd", "ts": "2026-05-15T11:40:00Z", "tests_written": 14, "all_failing": true}
  ],
  "next_step": "/pdlc-implement"
}

メリットは？機能ごとのセッション横断の継続性。明日 Claude Code を開き /pdlc-status を実行すれば「F20260515-01 は implement ステージ、次は review」と分かる。あなたの記憶にも、AI のコンテキストウィンドウにも依存しません。

ターゲットプロジェクトのディレクトリ

PDLC はプロジェクト内の以下を読み書きします：

docs/00_standards/coding/                          # コーディング規約（読み取り専用）
docs/01_requirements/prd/                          # PRD
docs/02_design/{api,database,architecture,ui-ux}/  # 技術設計
docs/03_development/                               # 開発者マニュアル
docs/04_testing/{unit-tests,e2e-tests,defects,...} # テスト & 欠陥
docs/05_deployment/                                # デプロイドキュメント
docs/06_tasks/                                     # ステージ内タスク追跡
docs/07_reviews/{doc,code,design,retro}/           # レビュー記録
docs/.pdlc-state/<feature-id>.json                 # 機能ごとの状態マシン

すべてがディスク上の実ファイル。1 週間前に AI が PRD ステージで何を書いたかを git diff で見られます。

応用：3 つの典型シナリオ

シナリオ 1：機能をエンドツーエンドで実装

# Claude Code 内で
/pdlc-feature ログインに電話番号認証を追加

PDLC が自動的にチェーン：

→ 機能 ID F20260515-01 を割当て（user-auth-phone）
→ ステージ 1：PRD 作成
   ✓ docs/01_requirements/prd/F20260515-01-user-auth-phone-prd.md
   ✓ セルフチェック 8/8 通過
→ ステージ 2：技術設計
   ✓ docs/02_design/api/F20260515-01-user-auth-phone-api.md
   ✓ docs/02_design/database/F20260515-01-user-auth-phone-db.md
→ ステージ 3：TDD レッドライト
   ✓ 14 個のテストを記述、全て期待通り失敗
→ ステージ 4：実装
   ✓ 14/14 テストがグリーンに
→ ステージ 5：コードレビュー + 自動修復
   ✓ lint 問題 3 件を自動修正
   ✓ docs/07_reviews/code/F20260515-01-user-auth-phone-review.md
→ ステージ 6：ハンドオフ
   📦 docs/.pdlc-state/F20260515-01.json 更新済み
   👉 次：/pdlc-ship

このフローの後、git ワーキングツリーには：1 つの PRD、2 つの設計ドキュメント、N 個のテストファイル、1 つのレビュー記録、1 つの状態マシン更新、加えて実際のコード変更。すべて実ファイル、チャットだけではありません。

シナリオ 2：監査可能なバグ修正

/pdlc-fix 空リストでのページネーションクラッシュ

PDLC は「ざっと見て 2 行変える」ではなく、こう進みます：

  1. 特定：コードを検索し原因の候補を絞る
  2. 再現：まず安定して再現するテストを書く（docs/04_testing/defects/ 配下）
  3. 修正：その後初めてコードを変更
  4. 検証：再現テストがグリーンに
  5. 記録：欠陥レポートをアーカイブ

半年後に類似のバグが出たら、過去の欠陥記録を grep して前回の修正法が分かります。

シナリオ 3：プロジェクト全体の進捗を一目で

/pdlc-status

おおよその出力：

Project PDLC status (read from docs/.pdlc-state/):

F20260512-01  user-auth-phone     ✓ shipped
F20260513-01  captcha-login       ⏵ in review
F20260514-01  password-reset      ⚠ stuck in TDD (3 tests failing)
F20260515-01  email-verify        ⏵ in PRD

AI を追いかけて「どこまで進んだ？」と聞かなくて済みます — 状態マシンを読むだけ。

効果：実際に得られるもの

1. エンジニアリングドキュメントがコードと一緒にディスクに残る

すべての PRD、設計、レビュー記録は git 履歴の中の実ファイル。1 年後に「なぜこの設計にしたか / どんな検討経て決めたか / レビューで何が指摘されたか」を正確に追跡できます。長期保守性の質的向上。

2. TDD が口先だけでなく実際に行われる

実装は失敗するテストにブロックされます。AI がスキップしたい？できません — ルールであるだけでなく、状態マシンによって強制されているから。

3. 自動修復の暴走リスクが封じ込められる

多くの AI ツールには静かな問題があります：修正 → 確認 → 直っていない → また修正 → 別の所が壊れる → また修正… トークンと時間を燃やす無限ループ。PDLC は「自動修復は最大 1 回」と強制し、AI が詰まったら止まって人間に委ねます。

4. セッション横断のエンジニアリング継続性

今日 implement ステージまで進んだ。明日 /pdlc-status で次のステップが分かる。会話のコンテキストウィンドウにも、あなたの記憶にも依存しません。

5. レガシープロジェクトも取り込める

新規プロジェクトはゼロから構造を立てるのが容易。レガシーは難しいケース。PDLC には /pdlc-adopt があり、既存コードベースを調査し、コードを書き換えずに、足りない標準 / 設計ドキュメント / ディレクトリ構造を補完して、プロジェクトを PDLC ステージに引き継げる地点まで持っていきます。

始めるには

完全なインストール手順、コマンド一覧、カスタマイズ方法、FAQ は PDLC 製品ページ とリポジトリにあります。

ワンライナー：

curl -fsSL https://raw.githubusercontent.com/kanfu-panda/pdlc-skills/main/install.sh \
  | bash -s -- --global

その後 Claude Code 内で：

/pdlc-feature <一文で要件を記述>

リポジトリ：github.com/kanfu-panda/pdlc-skills（MIT）

設計哲学を少し

PDLC は「AI アシスタントを足す」ものではなく、AI 以前のエンジニアリング思考の延長です：

ソフトウェアエンジニアリングが数十年にわたり積み上げた核心は「プロセス規律」です。AI が登場しても規律は消えるどころか、AI がすり抜けられないツールで強制されるべき。

「AI がコードを書き終えた = プロジェクト納品」が危険な単純化だと感じるなら、PDLC はおそらくあなたが探していたものです。

ぜひお試しください。質問は GitHub Discussions へ、または プロフィールページ からご連絡を。