Pattern: Parallel

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

ここで扱う Parallel は、単なる“同時実行”ではありません。 PCE 2.0 では parallel とは、 複数の bounded continuation を意図的に開き、それぞれの local autonomy・scope・gate を保ったまま進め、明示的な join contract で再統合する進め方 を指します。

パターンの要約

Parallel pattern

Parallel pattern とは、ある parent process frame の内部で、一つの主要 goal に対する複数の branch、child frame、または bounded execution path を 同時または準同時に active にし、それぞれに goal slice、responsibility bundle、capability scope、context budget、return contract を与えたうえで、後段の join contract によって 統合・比較・縮約・routing を行う pattern である。

それは単なる並列計算ではなく、 branch set、shared constraints、isolation policy、failure propagation、join readiness rule、conflict resolution、cancellation / rollback semantics を持つ。

より短く言えば、Parallel pattern とは 「一つの親 goal を複数の bounded path に開き、それぞれを独立に前進させ、あとで governed に再統合する進め方」 である。

ここで重要なのは、parallel が CPU 的な同時実行 を意味しないことだ。現実には、

truly simultaneous execution
tool / agent による concurrent execution
human / AI の interleaved branch progression
session をまたぐ “準同時” branch progression

のすべてを含みうる。 PCE 2.0 が重視するのは、物理的 simultaneity ではなく 同時に複数の active continuation を持つ topology である。

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

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

1. 主要な subproblem が互いに比較的独立しているとき

例:

implementation
tests
rollback readiness
governance impact review

を同時に進められる場合。

2. 比較そのものが仕事の中心にあるとき

例:

option A / B / C を比較する
hypothesis 1 / 2 / 3 を並べる
multiple candidate patches を比べる
duplicated incident signatures を切り分ける

3. 早く不確実性を減らしたいとき

例:

bug triage で reproduction / spec check / blast radius を並行に見る
research loop で internal evidence / external scan / prototype / governance cost を並行に見る

4. role や capability が明確に分離できるとき

例:

read-only analysis branch
bounded write implementation branch
human review branch
memory candidate triage branch

5. 後段の decision が multi-source integration を必要とするとき

例:

adopt / defer / reject recommendation
incident / local bugfix / duplicate routing
approve / request changes / escalate review decision

6. waiting cost が大きいとき

互いに独立した判定や evidence gathering を strict sequence にすると、ただ latency が伸びるだけになることがある。そのような場合、parallel の方が自然である。

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

逆に、次のような場合は parallel を切ると過剰設計になりやすい。

1. one dominant continuation しかないとき

一つの stage を終えないと次に意味が出ないなら、 Pattern: Sequential の方が自然である。

2. 同じ mutable scope を複数 branch が強く共有するとき

同じ artifact、同じ file cluster、同じ decision surface を複数 branch が勝手に触るなら、 parallel より race / conflict / hidden merge の危険が大きい。

3. join contract を定義できないとき

branch は切れるが、「何が揃えば何を次に決められるのか」が言えないなら、 parallel は作らない方がよい。

4. branch のコストが branch の利益を上回るとき

parallel にすると、

handoff
selection / compaction
join
audit
stale invalidation

のコストも増える。そのコストを払うだけの independence がないなら、single path の方がよい。

5. branch の存在が uncertainty を減らさず増やすだけのとき

必要のない exploratory branches を増やすと、 integration owner が later に overload する。

Parallel は何ではないか

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

1. 単なる多人数作業ではない

複数人 / 複数 agent が参加していても、同じ一つの current continuation を順に進めているなら、それは parallel ではない。 parallel とは 複数 continuation が active な状態である。

2. 単なる task 分割ではない

ToDo を並べただけでは branch にならない。 PCE 2.0 では、各 branch に

goal slice
capability boundary
return contract
local failure policy

が必要である。

3. 単なる “速くする工夫” ではない

parallel の価値は speed だけではない。比較、独立検証、risk isolation、role separation のためにも使う。

4. 単なる無制限の fan-out ではない

branch を切れるだけ切る設計は危険である。 parallel は bounded branch count と joinability を前提にする。

5. 単なる branch-and-join と同義ではない

Branch and Join は概念・構造である。 Parallel pattern は、その構造を 実務でどう使うか に寄せた参照パターンである。

6. 単なる all-of completion ではない

parallel の join は

all-of
any-of
quorum
comparative
reducer
partial

など複数ありうる。 “全部終わるまで待つ” だけではない。

基本トポロジ

Parallel pattern の最も基本的な形は、次のように書ける。

parent frame
  -> define parallel region
  -> branch_1 active
  -> branch_2 active
  -> ...
  -> join readiness check
  -> integration / comparison
  -> next parent continuation

あるいは、もう少し実務的には次のようになる。

frame definition
  -> parallel region open
  -> child / branch returns
  -> join
  -> approval / routing / next stage
  -> close

ここで大事なのは、parallel region が often larger sequential frame の内部にある ということだ。つまり “全部が parallel” である必要はない。むしろ典型は、

sequential intro
  -> parallel middle
  -> sequential closure

である。

Parallel region という考え方

Parallel pattern を実務で使うなら、parallel region という考え方を持つと便利である。

Parallel region

parent frame の内部に開かれる、一時的な multi-branch sub-topology。 region の外では parent は single main continuation を持ち、 region の中でだけ複数 continuation が active になる。

この考え方を使うと、parallel を “全体構造” ではなく 局所的な pattern として使いやすくなる。

典型例

bug triage の中で reproduction / spec consistency / blast radius を parallel にする
research loop の中で internal evidence / external scan / prototype / governance cost を parallel にする
feature delivery の中で implementation / tests / rollback-readiness を一時的に parallel にする

つまり Parallel pattern は、 frame を全部 parallel にすること ではなく 必要な区間だけ multi-active にすること だと考えると使いやすい。

Branch set が pattern の中心単位である

Parallel pattern の実務上の中心単位は、branch set である。

Branch Set

同じ parent frame の同じ parallel decision から生まれ、共通の目的、shared constraints、retained authority、join contract を持つ child / branch の集合。

parallel を複数の独立 child の寄せ集めとしてではなく、 branch set として扱うと次が明確になる。

なぜ一緒に切られたのか
どれが required branch か
どれが optional branch か
conflict が起きたら誰が解くのか
partial completion を許すのか
all-of なのか comparative なのか

つまり Parallel pattern は、 “複数 branch があること” ではなく join contract を共有する sibling set に本質がある。

代表的な parallel の型

Parallel pattern は一つではない。実務では少なくとも次の型を区別すると扱いやすい。

1. Partitioned Parallel

親 goal の異なる局所断面を分ける。

例:

implementation
tests
docs
rollback note generation

比較的 classic な parallel である。各 branch は disjoint scope を持ちやすい。

2. Validation Parallel

mainline に対して複数の validation branch を走らせる。

例:

implementation branch
blast radius branch
rollback readiness branch
governance fit branch

bug triage や high-risk review に向く。

3. Comparative Parallel

複数の alternatives を並べて、later join で比較・選択する。

例:

design A / B / C
query strategy A / B
patch candidate A / B

research や architecture decision に向く。

4. Redundant Parallel

同じ問いを independent に見て、later consistency / quorum を取る。

例:

independent verification
dual review
separate model / human comparison

5. Incident Isolation Parallel

mainline と incident analysis を parallel に走らせる。

例:

hotfix preparation
blast radius investigation

ただし authority retention を強くしないと危険である。

6. Synthesis Support Parallel

最終 synthesis に必要な補助 branch を切る。

例:

internal evidence scan
external evidence scan
cost estimation
migration impact scan

research や strategy work に向く。

Parallel does not mean unlimited concurrency

PCE 2.0 では、parallel を “できるだけたくさん branch する” とは考えない。重要なのは、bounded concurrency である。

なぜ bounded であるべきか

branch が増えると、同時に増えるものがある。

handoff packages
active unresolved issues
stale invalidation risk
integration complexity
join conflict surface
human oversight burden
audit burden

つまり parallelism には無条件の善がない。

何で bounded にするか

少なくとも次で bounded にするとよい。

max concurrent branches
max active unresolved conflicts
branch-local context budget
integration owner budget
human review capacity
acceptable rollback horizon

もし required branch set が current budget を超えるなら、それは parallel をさらに増やすのではなく、

staged parallel
two-pass join
integration child frame
narrower question freeze

を考えるべきシグナルである。

Shared mutable scope をどう扱うか

Parallel pattern の最重要課題の一つは、 shared mutable scope をどう扱うかである。

良い parallel

branch ごとの write scope が disjoint
same mutable target に対しては proposal-only
parent or integrator が later merge / choose する
sibling branches は sandboxed される

危険な parallel

multiple branches directly mutate same target
same approval path is assumed to cover all branches
one branch silently overwrites another
shared state drift is only discovered at join time

原則

parallel では、same mutable scope を触るなら少なくとも次のどちらかにする方がよい。

proposal parallel 各 branch は direct mutation せず、proposal/delta を返す
strict partitioning 各 branch の write surface を scope で分ける

この原則を破ると、parallel は orchestration ではなく race に近づく。

Join contract が pattern の心臓部である

Parallel pattern では、branching より join の方が重要なことが多い。なぜなら、branch を切るだけでは process は収束しないからである。

join contract が持つべきもの

join kind
required branches
optional branches
readiness rule
required evidence
conflict resolution
integration owner
required eval / approval
failure / cancellation policy
stale return invalidation rule

join が弱いと何が起こるか

“結果が揃ったので何となく選ぶ”
strongest narrative だけが残る
failed branch の lesson が消える
one branch の assumption が current truth のように扱われる
later rollback が難しくなる

Parallel pattern が本当に governed であるためには、 join contract が branching より先に設計されている方がよい。

Parallel pattern の中心性質

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

1. Multiple active continuations

同時に複数の main-relevant continuation が active である。

2. Bounded local autonomy

各 branch は bounded goal、bundle、capability scope、budget を持つ。

3. Shared constraints + local specialization

全 branch は shared constraints を持つが、 active context と expected output は branch ごとに違う。

4. Join-governed re-entry

parallel region は later join によって parent continuation へ戻る。戻り方は contract によって governed される。

5. Explicit failure propagation

一つの branch の fail / block / incident が、他 branch や parent にどう波及するかが defined されている。

6. Controlled cancellation and supersession

losing branch、obsolete branch、invalidated branch を later にどう閉じるかが explicit である。

これがあると、parallel は単なる “同時にいろいろやる” ではなく、 bounded multi-path process になる。

Parallel pattern と governance

Parallel pattern では governance がより重要になる。理由は simple で、active surface が増えるからである。

特に重要な governance points

branch-local capability scope
sibling visibility boundary
join approval requirements
which branch outputs are advisory vs blocking
who can cancel a branch
who can declare one branch winner
which stale branch returns remain consumable

human oversight が必要になりやすい場所

comparative join winner selection
join conflict resolution
rollout / rollback decision after branch divergence
branch-created evidence が互いに強く矛盾する場合

つまり Parallel pattern では、 governance surface は often stage-gated sequential より広く、しかし細かくなる。

Parallel pattern と context design

parallel では Actor-local Compiled Context と Context Budget の重要性が上がる。

なぜか

branch ごとに local question が違う
sibling の full details を全部 active に持てない
join owner は summary + differences を見たい
same source から multiple different selections が必要になる
stale branch outputs を current と誤認しやすい

branch-local context の原則

各 branch context には少なくとも次が必要である。

local goal slice
branch-local scope boundary
shared constraints
expected return
stop / escalate conditions
branch-specific evidence floor

join context の原則

join owner 用 context には次が必要である。

branch comparison core
required branch returns
conflicts
counterevidence
integration criteria
what remains unresolved

つまり parallel がうまくいくかどうかは、 branching 自体より branch-local and join-local context design にかなり依存する。

Parallel pattern は partial join を許すことがある

parallel は “全部終わるまで待つ” だけではない。 partial join を許すと useful なことがある。

典型例

docs branch は遅れているが implementation + tests で review を始めてよい
external scan は incomplete でも internal evidence + prototype で question narrowing に進める
one optional validation branch が遅れていても core decision はできる

注意点

partial join を許すなら、明示的に次を持つべきである。

which branches are optional
what decision can be made without them
what remains provisional
what later may reopen the decision

そうでないと、partial join が hidden omission になりやすい。

Parallel pattern と cancellation / supersession

parallel では later に不要になる branch が出る。これを silent に放置してはいけない。

典型パターン

winner-takes-rest

comparative branches で one option が選ばれ、他は abandoned / superseded になる。

parent reframe

question が narrow になり、old branches が no longer relevant になる。

incident freeze

one branch の incident で branch set 全体が止まり、一部 branch が cancelled される。

必要なこと

branch cancellation policy
supersession trace
surviving branch returns の freshness recheck
later memory extraction if losing branches had useful lessons

parallel では、勝った branch だけでなく 負けた / obsolete になった branch の扱い も process quality に効く。

Parallel pattern は often sequential shell の中にある

実務では、parallel は最初から最後まで続くより、 sequential shell の中の一部分として現れる方が多い。

典型構造

frame definition
  -> question / scope freeze
  -> parallel region
  -> join / integration
  -> approval / routing / close

この構造が useful なのは、

branch を開く前に question を固定できる
join 後に again one main continuation に戻せる
approval / memory / close を parallel region の外に retain しやすい

からである。

つまり Parallel pattern は often Sequential pattern と競合するのではなく、その内部で使われる。

どこで branch を切るべきか

Parallel pattern を使うなら、branch を切る境界が重要である。目安は次のとおり。

branch を切るべき条件

subproblem が独立している
different capability scopes are needed
different evidence modalities are needed
comparison is essential
latency benefit outweighs integration cost
one branch can fail without immediate collapse of all others

branch を切らない方がよい条件

same actor, same scope, same output, same gate
shared mutable scope dominates
no explicit join contract
differences between paths are too small to justify separate lifecycle

短く言えば、 independence + explicit reintegration の両方があるときに parallel を切ると考えるとよい。

いつ parallel を closedown して sequential に戻すべきか

parallel region は永遠に開いているべきではない。次の条件があるなら sequential continuation に戻す方がよい。

1. enough discriminating evidence has arrived

比較や routing に必要な差が十分見えたとき。

2. one primary continuation is chosen

comparative branch で winner が決まったとき。

3. further branching only adds noise

uncertainty を減らさず integration cost だけ増やすとき。

4. governance burden exceeds benefit

human oversight、audit、stale invalidation のコストが高すぎるとき。

つまり parallel は often temporary regime である。

典型的な成功パターン

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

1. branch purpose が明確

各 branch が何を減らすためにあるか説明できる。

2. branch-local scope が bounded

same mutable scope collision が少ない。

3. join readiness が明確

何が揃えば次へ進めるかが分かる。

4. counterevidence が join に残る

winning narrative だけが残らない。

5. stale branch returns を later invalid にできる

new evidence や reframe が入ったあとも safe である。

6. branch failure が controlled

one branch fail が即 total chaos にならない。

典型的なアンチパターン

Parallel pattern は便利だが、壊し方も典型的である。

1. Fan-out without join

branch を切るが、どう収束させるか決めていない。

2. Hidden shared mutation

parallel と言いながら same state を黙って複数 branch が書き換える。

3. Winner chosen by rhetorical force

比較結果ではなく、最も convincing な narrative が勝つ。

4. Counterevidence evaporation

failed branch や conflicting branch の lesson が消える。

5. Branch zombie

obsolete になった branch が明示的に cancel / supersede されず残る。

6. Human overload join

branch はうまく切れているが、最後に human integration owner が全部読むことになり budget を超える。

7. Parallel as status theater

実際には single continuation なのに、無意味に branch 名だけが増える。

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

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

強く向く

部分的に向く

Feature Delivery の implementation / tests / rollback-readiness
Human-AI Handoff の diagnosis / patch / blast-radius split

あまり向かない（基本は sequential）

PR Review の core approval loop ただし pre-review signals や support checks では partial parallel を使える

つまり Parallel pattern は、 uncertainty reduction と evidence integration が中心の仕事 に特に向く。

参考スキーマ

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

parallel_pattern:
  pattern_id:
  parent_frame_ref:
  parallel_region_id:
  purpose:
  shared_constraints:
  retained_authorities:
  max_concurrent_branches:
  branch_contracts:
    - child_frame_ref:
      local_goal:
      actor_ref:
      bundle_ref:
      scope_boundary:
      capability_scope_ref:
      expected_return:
      stop_conditions:
      local_failure_policy:
      local_checkpoint_policy:
  isolation_policy:
    visibility_isolation:
    mutable_scope_policy:
    delegation_bounds:
  join_contract:
    join_kind:
    required_branches:
    optional_branches:
    readiness_rule:
    conflict_resolution:
    integration_owner:
    required_eval_refs:
    required_approval_refs:
    partial_join_policy:
  cancellation_policy:
  rollback_policy:
  escalation_path:
  recovery_strategy:

runtime snapshot を置くなら、次のようにも書ける。

parallel_region_snapshot:
  region_ref:
  parent_frame_ref:
  active_branches:
  completed_branches:
  blocked_branches:
  escalated_branches:
  cancelled_branches:
  stale_returns:
  join_state:
    waiting_for:
    conflicts:
    legal_next_transitions:
  last_integration_ref:

この schema で重要なのは、parallel を単なる “複数 child がいる状態” ではなく、

shared constraints
retained authority
isolation
join
cancellation
rollback

を持つ region として表現している点である。

小さな例

negative total の bug triage を parallel に処理する最小例を書く。

1. triage owner freezes current question
2. reproduction branch starts
3. spec consistency branch starts
4. blast radius branch starts
5. all three return bounded deltas
6. triage owner joins returns
7. if result is clear, route to bugfix or incident
8. if conflict remains, escalate to incident owner

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

Branch	主 actor	主要 output	Join での役割
Reproduction	reproduction agent	repro status, steps, environment	“現象は current か” を示す
Spec consistency	domain reviewer	intended / not intended, duplicate note	“仕様違反か” を示す
Blast radius	blast radius analyst	severity, rollout risk, rollback feasibility	“incident に近いか” を示す

ここで重要なのは、三 branch の output を “足し合わせる” のではなく、 join owner が 今どの path が legal か を決めることだ。

暫定的なまとめ

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

複数の path を同時に開くこと自体に価値があるのではない。価値があるのは、各 path を bounded な autonomy に保ち、shared constraints と retained authority を明示し、join contract によって比較・統合・routing を governed に行うことである。

PCE 2.0 において Parallel pattern は、単なる並列化テクニックではない。それは、複雑な仕事の不確実性を一つの線に押し込まず、しかし uncontrolled divergence にもせず、bounded な複数 continuation に開いてから再統合するための基本パターンである。

だから Parallel pattern は、単なる「同時にやる」ではない。それは、PCE 2.0 において 複数の active continuation を isolation と join contract のもとで進める multi-path process pattern である。