Pattern: Sequential

このページは 参照パターン です。 ontology や principles のページが「PCE 2.0 で何が存在し、どういう原理で動くか」を定義するのに対して、 pattern pages は「それらをどういう topology で組むと実務上わかりやすいか」を示します。

ここで扱う Sequential は、もっとも基本的な process pattern です。ただし、単なる「順番にやる」という意味ではありません。 PCE 2.0 では sequential とは、明示的な stage boundary、entry/exit 条件、gate、handoff、reopen、rollback を持つ線形進行 を指します。

パターンの要約

Sequential pattern

Sequential pattern とは、ある process frame を、 一度に一つの主要 continuation だけが active になるような stage の列 として進める pattern である。

各 stage は、

goal slice

responsibility bundle

capability scope

context budget

entry conditions

expected output

exit conditions

を持ち、 stage の完了または gate 解消によってのみ、次の stage が legal になる。

より短く言えば、Sequential pattern とは 「仕事を明示的な段階に分け、前段の条件が整うまで次段を開かず、各段階の handoff と gate を strict に保つ進め方」 である。

ここで重要なのは、sequential が single actor を意味しないことだ。複数 actor が関与していても、

いま主導権を持つ continuation は一つ
次の stage は前の stage の明示的終了でしか開かない

なら、それは sequential pattern と見なせる。

どんなときに向いているか

Sequential pattern が向いているのは、次のような場面である。

1. 主要な問いが一つにまとまっているとき

例:

一つの feature を出す
一つの hotfix を準備する
一つの PR を review する
一つの triage result を routing する

2. 後段が前段の結果に強く依存するとき

例:

spec が固まらないと implementation に入れない
required eval が通らないと approval に入れない
rollback note がないと merge-ready にできない

3. governance を強くしたいとき

stage gate を explicit に持てるため、

approval bypass を防ぎやすい
stale state を invalid にしやすい
audit trail を作りやすい
rollback anchor を置きやすい

4. parallelism より explainability を優先したいとき

branch が少ない方が、

current lifecycle
current subject
current gate
current responsible actor

を説明しやすい。

5. low〜medium uncertainty の仕事

問いが大きく揺れない仕事では、sequential のほうが over-branching より扱いやすい。

どんなときに向いていないか

逆に、次のような場合は sequential だけで押し切らない方がよい。

1. 独立した subproblem が複数あるとき

この場合は Branch and Join の方が自然である。

2. alternative の比較が本質なとき

一つずつ順番に見ていくと、比較のための証拠が歪みやすい。 research、設計比較、選択肢比較では branch が必要になりやすい。

3. 問い自体が unstable なとき

research の初期段階のように、question freeze が弱いなら、 sequential に並べる前に reframe や bounded child frame が必要なことが多い。

4. latency が支配的なとき

複数の independent check を strict sequence にすると、 total latency だけが増えることがある。

5. 一つの stage が actor-local budget を超えるとき

その場合は compaction で押し込むより、

child frame に切る
stage を分割する
branch を切る

方が自然である。

Sequential は何ではないか

誤解を避けるために、先に輪郭をはっきりさせておく。

1. 単なる ToDo の順番ではない

調査 -> 実装 -> テスト -> レビュー と並んでいるだけでは足りない。 PCE 2.0 では、各段階に

entry condition
exit condition
gate
handoff contract
stale invalidation

が必要である。

2. 単なる single-threaded execution ではない

背景で support actor や tools が動いていてもよい。重要なのは、主要 continuation が一つ であることだ。

3. 単なる waterfall ではない

Sequential pattern は rework や reopen を含みうる。一方向にしか進まないことを意味しない。

4. 単なる phase list ではない

phase は内容上の区分だが、pattern はそれをどう governance するかまで含む。同じ review phase でも、

active review
pending approval
request changes
reopened review

は別状態である。

5. 単なる “並列を使わない設計” ではない

必要なところでは branch を使い、その結果を again sequential path に戻すこともある。 Sequential pattern は、parallelism の不在ではなく primary topology の性格 である。

基本トポロジ

もっとも基本的な形は、次のように書ける。

instantiate
  -> stage_1
  -> gate_1
  -> stage_2
  -> gate_2
  -> stage_3
  -> close

実務では、たとえば次のように現れる。

frame definition
  -> analysis
  -> spec approval
  -> implementation
  -> evaluation
  -> review approval
  -> promotion / merge
  -> completion acceptance

ここで各矢印は、単なる時間順ではなく legal next transition を意味する。

実務的な最小形

多くの実務では、Sequential pattern は次の six-part shape にすると扱いやすい。

1. Frame / Goal stage

何を達成する frame かを明確にする。

2. Working stage

局所 execution を行う。

3. Evaluation stage

required evidence と criteria を通す。

4. Approval stage

authority による ratification を通す。

5. Promotion / Merge stage

durable state path に乗せる。

6. Closure stage

completed / abandoned / superseded のどれかとして閉じる。

もちろん、すべての sequence が六段階必要なわけではない。だが PCE 2.0 では、少なくとも

work
judgment
ratification
state mutation
closure

を区別して考える方が安全である。

Sequential pattern の中心性質

Sequential pattern を PCE 2.0 的に特徴づけると、少なくとも次の五つがある。

1. One primary active continuation

同時に複数の主要 continuation が competing しない。主要 path は一つであり、stage boundary をまたぎながら進む。

2. Explicit stage gates

前段の completion / evaluation / approval を通るまで、次段が legal にならない。

3. Stage-local bundles and contexts

各 stage で active になる actor / bundle / compiled context が違う。

4. Reopenability

request changes、stale invalidation、new evidence により earlier stage が reopen されうる。

5. Rollbackability

later stage で問題が見つかれば、earlier acceptable state へ戻せる。

この五つがあると、Sequential pattern は単なる順番ではなく、 governed linear process になる。

Sequential does not mean single actor

Sequential pattern を誤って single actor pattern と理解しない方がよい。

たとえば、次は十分に sequential である。

analyst -> reviewer -> approver -> memory writer

各 stage で actor は変わる。しかし

primary continuation は一つ
stage order は explicit
handoff が strict
next stage は前段の exit でしか開かない

ので、これは sequential である。

つまり sequentiality は actor count ではなく continuation structure の性質である。

典型的な stage 境界

Sequential pattern では、stage boundary を雑に作ると later quality が下がる。 PCE 2.0 では少なくとも次の境界が有効である。

1. Meaning boundary

仕事の意味が変わる場所。

例:

diagnosis -> patch preparation
implementation -> review
synthesis -> recommendation

2. Authority boundary

次の actor / bundle が別 authority を持つ場所。

例:

executor -> reviewer
evaluator -> approver
proposer -> memory writer

3. Risk boundary

次へ進むと rollback cost や blast radius が上がる場所。

例:

merge-ready 直前
external effect 直前
release freeze decision 直前

4. Continuity boundary

later resume や handoff に備えて切るべき場所。

例:

session 終了前
approval 待ち前
recovery point 作成前

この boundary design が弱いと、sequential pattern はすぐに “だらだら続く一本線” になる。

Stage contract が必要である

PCE 2.0 の sequential pattern では、各 stage に contract が必要である。最低限、次を持つとよい。

entry condition

何が揃えばこの stage に入れるか

active actor / bundle

誰がいま責任を持つか

goal slice

この stage が何を達成するためのものか

expected output

何を返せば stage 完了とみなせるか

stop conditions

何が起きたら local continuation を止めるべきか

next on success / fail / escalate

終了後の routing

これがない sequence は、見た目が線形でも実質的には ungoverned である。

Stage boundary では context を畳み直す

Sequential pattern の実務上の利点は、 stage 境界ごとに Actor-local Compiled Context を作り直せることにある。

analysis stage で見せるもの

broad question
evidence gathering scope
exploratory hypotheses

implementation stage で見せるもの

approved spec slice
target files
write scope
rollback note requirement

review stage で見せるもの

current diff
required evidence
pending approval gate
scope constraints

memory writing stage で見せるもの

memory candidate
provenance
target collection semantics
duplication context

このように、same frame でも stage が変わると active context は変わる。 Sequential pattern は、この畳み替えをしやすい。

Sequential pattern と governance

Sequential pattern は governance と相性がよい。理由は、どの gate がどこにあるかを置きやすいからである。

置きやすいもの

approval points
required evals
write authorization
rollback anchors
escalation sink
completion acceptance

特に重要なこと

Sequential pattern では、「次へ進む条件」を明示しないと見た目だけ順番になって、実質は implicit approval になりやすい。

たとえば、

CI pass したのでそのまま次へ
review comments が少ないのでそのまま次へ
summary がそれっぽいので recommendation accepted

のような流れは、Sequential pattern の悪い崩れ方である。

Sequential pattern は reopen を含む

Sequential pattern は、one-way pipeline ではない。 PCE 2.0 では、むしろ reopen できること が重要である。

典型的な reopen

review 中に new commit が入る
new evidence が来る
approval 前提が stale になる
branchless sequence の earlier assumption が崩れる
memory candidate に duplication issue が見つかる

このとき sequence は、たとえば次のように戻る。

stage_4 (approval)
  -> invalidate
  -> stage_3 (evaluation)

あるいは、

stage_3 (review)
  -> request_changes
  -> stage_2 (execution)

つまり Sequential pattern は、 forward-only ではなく, controlled backward edges を持つ linear topology として理解するとよい。

Sequential pattern と rollback

sequential pattern は rollback とも相性がよい。なぜなら anchor が stage boundary と結びつきやすいからである。

典型 anchor

after question freeze
after spec approval
after implementation completed
before merge
before recommendation acceptance

rollback の利点

どの段階まで戻せばよいか説明しやすい
later phase の approvals / evals / contexts を invalid にしやすい
one primary path なので rollback horizon を定めやすい

ただし注意点もある。 sequence を long flat chain にしすぎると、rollback horizon が大きくなりすぎる。その場合は stage split や child frame 化を考えるべきである。

Sequential pattern と child frame chain

Sequential pattern は、単一 frame 内の phase だけでなく、 child frame の chain として実装することもできる。

variant A: single-frame staged sequence

一つの frame の lifecycle と stage definitions の中で進める。

向いている場面:

scope が狭い
handoff costが低い
strong parent-child separation が不要

variant B: chained child frames

親 frame の下に

analysis child
implementation child
review child
promotion child

のような chain を切る。

向いている場面:

actor / capability が大きく変わる
child-specific recovery が必要
audit を強くしたい
each stage の return contract を explicit にしたい

つまり Sequential pattern は、平坦にも階層的にも実装できる。

Human-AI stage-gated sequential

AI を組み込むと、Sequential pattern は次のような形をとりやすい。

human framing
  -> AI execution
  -> AI return
  -> human review / approval
  -> AI rework (if needed)
  -> human final decision

この pattern の重要点は、

human が goal / approval / incident を retain しやすい
AI が bounded execution を担いやすい
stage 境界で stale invalidation を入れやすい
handoff package を explicit にしやすい

ことである。

詳しくは Human-AI Handoff を参照。

どこで sequence を split すべきか

Sequential pattern が向いていても、stage が大きすぎると壊れやすい。 split の目安は次のとおり。

split した方がよい条件

actor が変わる
capability scope が変わる
required evidence floor が変わる
approval or eval gate が入る
rollback cost が跳ね上がる
context budget が急に変わる
human oversight の必要性が変わる

split しなくてもよい条件

same actor
same bundle
same capability scope
same expected output
same admissibility path

短く言えば、 責任、権限、gate、budget のどれかが意味的に変わるなら、stage を切るべき である。

いつ sequential をやめて branch すべきか

Sequential pattern を保つべきか、branch を切るべきかは重要な判断である。

sequential のままでよいとき

one dominant subject
one dominant continuation
later stage depends strongly on earlier stage
alternative comparison is not the core task

branch すべきとき

independent checks are waiting on each other unnecessarily
alternative hypotheses must be compared
blast radius / governance / prototype need separate bounded work
one stage’s budget or complexity is too high

つまり Sequential pattern は default として強いが、 everything must be sequential ではない。

典型的な成功パターン

Sequential pattern がうまく機能しているときは、次のような特徴がある。

1. current stage が明確

今どの stage か、誰が active か、何が pending かが説明できる。

2. next legal transition が明確

approve、request changes、escalate、rollback、close のどれが legal か分かる。

3. old outputs の stale 化が explicit

new evidence や new commit で old context / old approval を invalid にできる。

4. handoff package が軽くなる

next actor に必要なものだけを渡しやすい。

5. rollback anchor が取りやすい

later correction や recovery がやりやすい。

典型的なアンチパターン

Sequential pattern は単純に見える分、壊れ方も定型的である。

1. Giant undifferentiated sequence

全部を一つの長い In Progress に入れている。 entry / exit / gate がなく、later reopen や rollback が難しい。

2. Stage labels without semantics

analysis / review / done と書いてあるが、

何をもってその stage に入るか
何をもって抜けるか
何が pending か

がない。

3. Approval-by-drift

前段の “だいたいよさそう” が、そのまま次段の事実上の approval になる。

4. Context carry-over without recompilation

analysis の full context を implementation にそのまま持ち込み、 implementation の full trace を review にそのまま渡す。

5. No reopen semantics

new evidence や new commit が入っても、old stage result を current のまま使い続ける。

6. Sequence used where comparison is needed

alternative を比較すべき仕事を sequential に並べ、 later に weak join しかできなくなる。

このパターンに向くケース

PCE 2.0 の case pages の中では、次が特に Sequential pattern に向いている。

強く向く

PR Review
Human-AI Handoff の bounded patch loop
Feature Delivery の stage-gated version

部分的に向く

Bug Triage の intake -> routing 部分
Research Loop の second loop 以降の narrowed question 部分

つまり Sequential pattern は、 問いがある程度 bounded になったあとの前進 に向いている。

参考スキーマ

実装や docs 化に使いやすい最小 pattern schema を置いておく。

sequential_pattern:
  pattern_id:
  frame_ref:
  primary_goal:
  stages:
    - stage_id:
      purpose:
      actor_ref:
      bundle_ref:
      entry_conditions:
      goal_slice:
      required_context_floor:
      expected_outputs:
      stop_conditions:
      next_on_success:
      next_on_fail:
      next_on_escalate:
      handoff_target:
      rollback_anchor:
  stage_gates:
    - gate_id:
      between:
        from_stage:
        to_stage:
      required_eval_refs:
      required_approval_refs:
  close_rule:
  escalation_path:
  recovery_strategy:

これをもっと current docs に寄せて書くなら、次のようにも置ける。

sequential_stage_contract:
  frame_ref:
  current_stage:
  actor_ref:
  bundle_ref:
  goal_slice:
  entry_conditions:
  active_subjects:
  required_evidence_refs:
  allowed_actions:
  prohibited_actions:
  expected_output:
  stop_conditions:
  legal_next_transitions:
  handoff_contract:
  invalidated_by:
  rollback_anchor_ref:

この schema で重要なのは、stage が単なる label ではなく entry / execution / handoff / exit の contract を持つことだ。

小さな例

negative total hotfix を sequential に処理する最小例を書く。

1. human triage owner freezes bounded hotfix question
2. AI diagnosis actor performs read-only analysis
3. human decides whether bounded write is authorized
4. AI patch actor prepares hotfix candidate
5. human reviewer evaluates and approves / requests changes
6. if approved, merge-ready path opens
7. if new evidence arrives, review stage reopens

これを stage table で書くと次のようになる。

Stage	主 actor	主要 output	Gate
Framing	human triage owner	bounded hotfix goal	write not yet allowed
Diagnosis	AI read-only actor	diagnosis delta	human decision required
Write authorization	human triage owner	narrow write grant or escalate	final review still pending
Patch preparation	AI patch actor	patch + tests + rollback note	review gate opens
Review	human reviewer	approve / request changes / escalate	merge path gated
Close / handoff	human owner	merge-ready or reopen	final path decided

ここで重要なのは、

AI が二回出てくる
しかし human が framing / authorization / approval を retain している
sequence の途中で reopen がありうる

ことだ。

暫定的なまとめ

Sequential pattern が言っていることは、最終的には次の一文に集約できる。

仕事を線形に進めること自体には価値がない。価値があるのは、どの段階で何を達成し、誰が何を持ち、何が pending で、何が次の legal transition を開き、どんな条件で前段へ戻るのかを explicit にしたうえで、一つの主要 continuation を bounded に前進させることである。

PCE 2.0 において Sequential pattern は、単なる簡単な workflow ではない。それは、もっとも基本的で、もっとも誤魔化しが効きにくい process topology である。

だから Sequential pattern は、単なる「順番にやる」ではない。それは、PCE 2.0 において stage・gate・handoff・rollback を明示したうえで一つの主要 path を governed に進める基本パターン である。