Skip to content

Patterns

このセクションは、PCE 2.0 の pattern catalog です。 Spec が「何が存在し、どういう原理で動くか」を定義するのに対して、 Patternsそれらを実務でどう組むと扱いやすいか を示します。

重要なのは、pattern が正規定義ではないということだ。 pattern は law や ontology を置き換えるものではなく、 実装・運用・説明のための再利用可能な topology を与える。

このセクションの目的は、大きく三つある。

1. topology を短く引けるようにする

Section titled “1. topology を短く引けるようにする”

実務では、

  • いまは一本道の stage-gated flow なのか
  • 一時的に multi-branch region を開くべきなのか
  • 一つの subject を iterative に改善する loop なのか

を早く言い分けたい。

Patterns は、その言い分けを短く引くための場所である。

PCE 2.0 の概念は単独でも読めるが、実務で効くのは組み合わせたときである。

たとえば、

が一緒にどう働くかは、pattern として見た方が早い。

3. 実務上の default topology を共有する

Section titled “3. 実務上の default topology を共有する”

すべての仕事を毎回ゼロから topology 設計する必要はない。 よく使う shape を共有しておくと、

  • 説明が速くなる
  • handoff が安定する
  • review 観点を揃えやすい
  • anti-pattern を早く見つけやすい

という利点がある。


仕事を 明示的な stage と gate の列 として進める基本パターン。 one primary active continuation を保ち、handoff、approval、rollback、reopen を stage 境界に沿って扱う。

向いている仕事:

  • feature delivery の主経路
  • PR review の core approval loop
  • bounded hotfix
  • merge / promotion 前の governed path

一つの親 goal を 複数の bounded branch / child frame に開き、join contract のもとで統合・比較・routing するパターン。 uncertainty reduction、independent validation、comparative analysis に強い。

向いている仕事:

  • bug triage の reproduction / spec / blast radius 分岐
  • research loop の hypothesis branch
  • implementation / tests / rollback-readiness の一時並行
  • comparative design evaluation

ある fixed subject を改善対象として束ね、 optimizer が candidate を出し、evaluator が contract に基づいて verdict と requested changes を返し、 その差分で bounded に改善していく反復パターン。

向いている仕事:

  • PR patch refinement
  • recommendation memo refinement
  • AI-assisted draft hardening
  • memory candidate refinement

Pattern主な topology何を固定するか主要な危険代表ケース
Sequentialone primary continuationstage order と gateimplicit approval、stale carry-overFeature Delivery, PR Review
Parallelmultiple active continuationsbranch set と join contracthidden shared mutation、join 崩壊Bug Triage, Research Loop
Evaluator-Optimizeriterative refinement loopsubject と eval contractcriteria drift、self-approval collapsePR Review, Human-AI Handoff

迷ったら Pattern: Sequential から読むのがよい。 理由は、PCE 2.0 の多くの仕事が最終的には one main continuation に戻るからである。

Pattern: Parallel を先に読む。 特に Branch and Join がなぜ first-class なのかを理解しやすい。

AI 改善ループや review loop を見たい

Section titled “AI 改善ループや review loop を見たい”

Pattern: Evaluator-Optimizer を先に読む。 evaluationapproval の分離、stale invalidation、stop rule の重要性がよく見える。


この三つは競合するものではなく、しばしば入れ子になる。

frame definition
-> parallel region
-> join
-> approval / close

代表例:

Sequential shell + Evaluator-Optimizer middle

Section titled “Sequential shell + Evaluator-Optimizer middle”
subject freeze
-> evaluator-optimizer loop
-> approval
-> promotion

代表例:

parallel candidate generation
-> comparative evaluation
-> one current candidate refinement

代表例:

  • comparative design work
  • multi-evaluator review
  • strategy recommendation hardening

つまり pattern を選ぶというより、 どこを one path にし、どこを multi-path にし、どこを iterative loop にするか を設計するのが実務に近い。


pattern は「こうでなければならない」ではなく、 こう組むと失敗モードを見えやすくできる という実務上の参照である。

2. 何が current continuation かを見る

Section titled “2. 何が current continuation かを見る”

どの pattern でも重要なのは、

  • いま何が main path か
  • 何が provisional か
  • 何が next legal transition を開くのか

である。

良い pattern は、前に進む条件だけでなく

  • stop
  • reopen
  • escalate
  • rollback
  • cancel

の条件が明示されている。

4. actor 数ではなく topology を見る

Section titled “4. actor 数ではなく topology を見る”

人間が多い、AI が多い、tool が多い、というだけでは pattern は決まらない。 見るべきなのは continuation structure である。



このセクションが言いたいことは、最終的には次の一文に集約できる。

PCE 2.0 の pattern は、概念を増やすための付録ではない。
仕事を one path / multi-path / iterative loop のどれとして設計し、どこで gate を置き、どこで join し、どこで stale invalidation や approval separation を効かせるかを、再利用可能な topology として引き直すための参照である。