なぜ pdlc-skills は三大エンジニアリングに自然と噛み合うのか

目次

三つの概念を切り分けたあとに来る、本当に面白い問いはこれです。三層が同時に揃っている実物はあるのか。この記事では、私自身が作っている pdlc-skills を一つずつ当てていきます。結論を先に言うと、噛み合っているのは偶然です。ただしその偶然には理由があり、その理由こそがこの記事の本題です。

前回は、混同されがちな三つの言葉を切り分けました。

• プロンプトエンジニアリングが扱うのは、この一回モデルにどう伝えるか；
• Loop エンジニアリングが扱うのは、同じことを何回繰り返し、どの条件で止めるか；
• Graph エンジニアリングが扱うのは、経路上のどの工程を飛ばしてはいけないか。

三者は同じ階層になく、三択でもなく、積み重ねられる三層でした。

そこで自然に出てくる問いがあります。三層とも理屈は通っているとして、三層が同時に揃っている実物はあるのか。

一つ当ててみます。私自身が作っている pdlc-skills です。

pdlc-skills とは何か

Claude Code のプラグインで、やっていることは一行で言えます。AI が書くコードを「会話の中のもの」から「ディスクに残るもの」に変える、それだけです。

入れると 38 個のスラッシュコマンドが増え、一つが工程の一段階に対応します。いちばん使うのは /pdlc-feature で、新しい機能はこれで始めます。あとは AI が PRD → 設計 → TDD → 実装 → レビュー → リリースの線に沿って進み、各段階で一度止まって引き継ぎます。

「この機能作っといて」と頼むのとの違いは三点です。

• 成果物は必ずディスクに落ちる。PRD も設計もレビュー記録も docs/ の下の実ファイルであって、チャット履歴の一節ではありません。
• 機能ごとに状態を持つ。どの段階まで来たか、前の段階は通ったか、すべてディスクに記録されます。別のセッションで再開しても、自分がどこにいるか分かります。
• テストは先に赤でなければならない。失敗するテストが無ければ実装に進めません。推奨ではなく、硬い関門です。

MIT ライセンス。Claude Code 上での対応が最も手厚く、同じ方法論はアダプタ経由で他の AI コーディングツールでも動きます。

出自はごく平凡です

この三層は私が設計したものではありません。作っていた当時、「Loop エンジニアリング」も「Graph エンジニアリング」という言葉も聞いたことがありませんでした。

ソフトウェア工学に元からある製品開発ライフサイクルを、そのままなぞっただけです。要件、設計、テスト、実装、レビュー、リリース——この流れは業界に何十年も転がっていて、新しいところは一つもありません。私がやったのは、それを AI 向けに翻訳することだけでした。各段階で何をやるのか、何を出すのか、どうなったら通過なのかを一つずつコマンドとして書き、AI が思いついた順ではなく流れに沿って進むようにしただけです。

そこに一つだけ規則を足しました。各段階は必ずディスクに何かを書く、というものです。

• PRD は docs/01_requirements/ へ
• 設計は docs/02_design/ へ
• レビュー記録は docs/07_reviews/ へ
• 機能ごとに状態ファイルも一つ

すべて普通のテキストです。いつでも開けますし、そのラウンドで AI が実際に何を触ったかを git diff で確認できます。

作り終えたあとに、この新しい言葉が流行り始めました。当てて確かめてみると、どこも噛み合っている——合わせて作ったからではなく、勝手にそう育っていたからです。

ではプロンプト、Loop、Graph の順に一層ずつ当てていきます。

🔵 プロンプト層：噛み合うのは「規約は一つだけ」

工程の中で対応するもの。 ソフトウェア工学には古い規則があります。規約書は一つだけ、あちらとこちらで別々に持たない。pdlc に当てはめると、すべてのコマンドが守るべき規則——成果物は必ず落とす、引き継ぎ前に必ず自己点検する、修復は一度だけ——を、各コマンドの中に別々に書いてはいけない、ということになります。

具体的にどうしたか。 共通規則を断片に切り出し、ビルド時に各 skill へ展開します。現在は 13 個の断片が、38 個の skill のうち 36 個にコンパイルされています（入っていない二つは pdlc-loop-next と pdlc-status。軽すぎて共有すべき規則がありません）。六つの不変条件——ファイルは必ずディスクに落とす、段階ごとに必ず記録する（history に追記する）、テストは先に赤である、自己点検は必須、修復は一度だけ、状態は必ず前進する（current_stage が実際に変わること。外側のループが古い状態のまま空回りするのを防ぐため）——は、そのうちの一つの断片に書かれています。一箇所直せば、全体に効きます。

どの層と噛み合ったか。 プロンプトエンジニアリングが扱うのは「今回モデルに何を見せるか」です。ここでやっていることはそれと変わりません。ただコードと同じやり方で管理しているだけ——共通部分を抜き出し、ビルド時に展開し、真実の源を一つにする。

新しい呼び名はプロンプトエンジニアリング、古い規則は単一の真実の源。同じことを二つの語彙で言っている——これが一つ目の偶然です。

🟢 Loop 層：噛み合うのは TDD の赤信号関門

工程の中で対応するもの。 TDD はソフトウェア工学では古株で、規則は一行です。まず失敗するテストを書き、それから実装を書き、テストが緑になるまで続ける。pdlc はこれをそのまま持ち込みました。実装の前に、赤いテストが必ず存在すること。

この規則が付随して連れてきたもの。 テストが実装より先にあるということは、「終わったのかどうか」にモデルと無関係な答えが出るということです。一度走らせて、終了コードが 0 なら通過、それ以外なら未通過。

この答えの値打ちは、モデルを経由しない点にあります。コードを書いたモデルに自分のコードを採点させると、体系的に甘くなります。騙そうとしているのではなく、本当に良く書けたと思っているからです。ですから pdlc では、モデルの自己点検結果は別枠で記録し、参考にとどめ、止まるべきかどうかの根拠には決してしません。

だからこの区間はループに渡せます。tdd → implement → review が自走し、レビューが通るまで回ります。その手前の PRD と設計は渡せません。この機能をやるべきか、いくつのモジュールに割るか、境界をどこに引くかは判断問題で、終了コードを返せるコマンドが存在しないからです。判断問題は人に残す。この線ははっきり引いてあります。

どの層と噛み合ったか。 Loop エンジニアリングには公理として使える一文があります。ループとはタスクに検証を一つ足したもの、検証のないタスクはただの願望である。TDD が与えるのは、まさにその検証です。

私が TDD をやっているのは、ソフトウェア工学が「テストを先に」と言うからであって、ループのために定規を用意したかったからではありません。それでも定規はそこに置いてあった——これが二つ目の偶然です。

ガードレール、上限、予算の決め方は第 5 回で扱います。

🟣 Graph 層：噛み合うのは段階分けとレビュー関門

工程の中で対応するもの。 ライフサイクルという言葉自体が順序を含んでいます。要件は設計の前、設計は実装の前、実装のあとにレビュー、レビューを通ってからリリース。ソフトウェア工学ではこの順序は推奨ではなく規律です。工程を飛ばした代償には、業界が何十年も授業料を払ってきました。

具体的にどうしたか。 各段階の終わりに状態をディスクへ書き、次の段階はまず状態を読み、前提条件を満たさなければ進ませない。テストを飛ばして実装しない、レビューなしでリリースしない。

縦の順序のほかに、横の層もあります。機能と機能の関係です。/pdlc-relate がそれを明示的に記録します。六種類の有向辺——拡張、依存、置換、解決、衝突、関連。そして impact <機能ID> を叩けば、変更の影響半径が一発で出ます。🔴 直接依存しているもの、🟡 一つ隔てたもの、🟢 すでに終わっていて気にしなくていいもの。

ここは正直に言っておきます。 縦のほうは厳密にはグラフではなく、関門をいくつか挟んだ線形のパイプラインです。条件分岐がなく、並列ノードもなく、任意の地点へ巻き戻すこともできません。グラフらしい性質をほぼ持っていない。本当に「グラフ」と呼べるのは横の依存関係図のほうです。向きがあり、辿れて、循環依存を検出でき、存在しない機能を指す参照も見つけられます。

どの層と噛み合ったか。 では縦はなぜ Graph 層と言えるのか。Graph 層の本質は「図に描くこと」ではなく、負の制約——どの経路を通ってはいけないかを宣言することだからです。前回の言い方をもう一度使うなら、線路は旅程を計画しません。ある方向を単に成立させなくするだけです。

段階の関門が縛るのは順序、依存図が縛るのは影響範囲。やっていることは同じです。そして「段階を追って進め、要所でレビューする」という規律は、ソフトウェア工学がとうの昔に工程へ書き込んでいました——これが三つ目の偶然です。

三度重なれば偶然ではない

一度なら偶然と言えます。三度とも噛み合うなら、理由を問うべきでしょう。

私の答えはこうです。この二つは、もともと同じ問題群を解いていた。

三大エンジニアリングは、この二年ほどの AI エージェント実践から抽出された新しい語彙です。一方ソフトウェア工学のあの流れは、何十年もかけて実プロジェクトに繰り返し叩き込まれてできたものです。そして人と AI がエンジニアリングで犯す失敗は、かなりの部分が重なっています。思いついた順に手をつける、規約を何通りも持つ、終わったと言うが検証していない、ここを直すとどこが壊れるか分からない。古い流れがこれらを治すために立てた規則は、AI に翻訳しても効きます。

つまり新しい語彙が語る制約は、古い流れが別の言葉ですでに書き残していたわけです。

三大エンジニアリングの言い方	ソフトウェア工学に元からある規則
プロンプト工学：文脈を統一せよ	規約は一つだけ、あちこちに写すな
Loop 工学：客観的な検証を持て	実装より先にテストを書け
Graph 工学：負の制約をかけよ	段階を追って進め、要所でレビューせよ

これが「自然に噛み合う」の意味です。私が三層を組み込んだのではなく、この古い流れが元から三層を備えていた。ただ今までこの三つの名前で呼ばれていなかっただけです。

もう一つ、古い流れには無く、実装の途中で自然に現れたものがあります。三層は最終的に同じもの——ディスク上の状態——を共有するようになりました。

グラフはそれを読んでどの段階にいるかを判断し、 ループはそれを読んでこのラウンドで前進したかを判断し、 プロンプトはそれを読んで今回見るべき文脈を得る。

ここから使える物差しが一つ手に入ります。あるツールの三層が本当に統合されているかは、同じ状態を共有しているかで判断できる。 共有していれば統合、それぞれが自前で持っているなら、三つの仕組みが同じリポジトリに同居しているだけです。

次回：それぞれはいつ効いてくるのか

この記事から一文だけ持ち帰るとしたら、これにしたいと思います。AI にエンジニアリングをさせたいなら、新しいフレームワークを発明するより、すでにある工程を持ち出すほうが早い。 その工程は新しくありませんが、それが治してきた病は、AI も同じようにかかります。

三層がどこに落ちているか分かったところで、次の問いはこうなります。一つの機能開発の中で、それぞれはいつ効いてくるのか。 次回は一つの機能を最初から最後まで追いかけ、三層の時間軸と、互いの引き継ぎ方を示します。

---

試してみる：

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

プロジェクトページ：kanfu-panda.github.io/pdlc ／ ソース：github.com/kanfu-panda/pdlc-skills

役に立ったら star をいただけると励みになります ⭐

---

三層がどう地に足を着くのか、具体的な像が持てたなら、いいねやフォローをいただけると嬉しいです。周りに「AI に工程を守らせたい」と考えている方がいれば、共有していただけると助かります。