Handoff

定義

Handoff

Handoff とは、ある process frame の進行中に、
ある actor または child frame が担っていた work continuity を、
別の actor、別の child frame、または親 frame へ
継続可能な形で移す遷移 である。

それは単なるメッセージ送信ではなく、
goal slice、responsibility transition、relevant evidence、pending gates、delta state、unresolved issues、expected next action、required output contract、authority / scope constraints を、
受け手が次の legal transition を取れる形で受け渡す。

より短く言えば、Handoff とは
「この仕事の続きは、次に誰が、どの責任で、どの根拠を使い、何を返すべきか」を失わずに移すこと
である。

PCE 2.0 において process は、単一 actor が一直線に進めるものではありません。
調査、実装、評価、承認、memory promotion、incident handling は、しばしば別 actor が担います。
Handoff は、この actor 間の切替を 責任・統治・継続性を壊さずに 成立させるための概念です。

この意味で Handoff は、
Transitions の中でも特に
Responsibility Bundle、Actor-local Compiled Context、Recovery Point を接続する中心遷移です。

なぜ Handoff が必要なのか

AI 時代の開発では、同じ frame の中でも actor が頻繁に入れ替わります。

analyst agent から coding agent へ
coding agent から reviewer へ
reviewer から memory writer へ
child frame から parent frame へ
同じ actor の別 session へ
runtime suspension から later resume へ
current owner から incident owner へ

この切替を「結果だけ渡す」形で済ませると、少なくとも次の問題が起きます。

1. Context loss

受け手が、前提・scope・未解決事項・根拠を再構築しなければならなくなります。

2. Responsibility vacuum

誰が何を引き継いだのか曖昧になり、
approval、evaluation、incident ownership の境界が崩れます。

3. Authority smuggling

source actor が持っていた権限や視界が、target に暗黙に持ち越される危険があります。

4. Gate loss

pending approval や pending eval が handoff 途中で消え、
本来止まるべき process が進んでしまいます。

5. Duplicate work

未解決事項や失敗知が十分に渡らず、同じ探索や同じ失敗を繰り返します。

6. Untraceable promotion

どの根拠で durable state を更新したのかが追えなくなります。

PCE 2.0 における Handoff は、これを防ぎます。
それは単なる情報共有ではなく、継続可能性の明示的な受け渡し です。

Handoff は何ではないか

輪郭をはっきりさせるために、まず何ではないかを書いておきます。

1. 単なるメッセージ転送ではない

メッセージ本文を送るだけでは、handoff は成立しません。
次の actor が legal に process を進められるだけの責任状態と gate 状態が必要です。

2. 単なる delegation ではない

delegation は responsibility bundle の一部を委ねることです。
handoff は、実際の active work continuity を別 actor 側へ移すことです。
delegation なしの handoff はありえますし、handoff なしの delegation もありえます。

3. 単なる child frame 作成ではない

decompose によって child frame を作ることは framing transition です。
handoff は、その child に goal slice・constraints・expected return を受け渡し、
実際に work を開始可能にする遷移です。

4. 単なる checkpoint ではない

checkpoint は保存です。
handoff は受け渡しです。
ただし handoff の前後に checkpoint を切ることはよくあります。

5. 単なる approval submission ではない

approval submission は handoff の特殊形になりえますが、
handoff 全体は approval より広く、execution、evaluation、memory writing、incident routing も含みます。

6. 単なる transcript 再利用ではない

source actor の local context を target にそのまま見せることは、通常は良い handoff ではありません。
target 用の局所視界は改めて compile されるべきです。

7. 単なる「担当交代」ではない

担当が変わるだけでは足りません。
何が変わり、何が残り、何が pending で、何が legal next transition なのかが必要です。

Handoff の本体は「継続性の移送」である

PCE 2.0 において handoff は、情報 transfer ではなく continuity transfer です。
ここで continuity とは少なくとも次を含みます。

1. Goal continuity

何の goal slice を継ぐのか。

2. Responsibility continuity

どの責任が移り、どの責任が source 側に残るのか。

3. Gate continuity

pending approval / eval / policy condition を失わないこと。

4. Delta continuity

既に emitted された Process Delta の状態を維持すること。

5. Evidence continuity

必要な根拠を target が再構築せず参照できること。

6. Governance continuity

visibility、capability、authority、merge admissibility の条件が崩れないこと。

7. Recovery continuity

途中で止まっても、handoff 以後の process が recover 可能であること。

つまり Handoff は、
仕事の続きを合法的・統治的に続けるための continuity package
を渡す遷移だと理解すべきです。

Handoff の基本型

PCE 2.0 では、少なくとも次の型の handoff を区別できます。

1. Intra-frame Actor-to-Actor Handoff

同じ frame の中で、active work を別 actor に渡す handoff です。

例:

coding agent → reviewer
reviewer → memory writer
analyst agent → coding agent

2. Parent-to-Child Handoff

親 frame が child frame に goal slice と constraints を渡す handoff です。
child はこれを受けて局所 work を開始します。

3. Child-to-Parent Return Handoff

child frame が親 frame に対して、

delta
evidence
unresolved issues
recommendation

を返す handoff です。
これは単なる return value より広く、親の次の遷移を可能にする返送です。

4. Approval Handoff

work product を approver に差し出し、
ratification を待つ handoff です。
review package、required evidence、approval subject が重要になります。

5. Evaluation Handoff

subject を evaluator set に渡し、
判定を受けるための handoff です。
とくに required evidence と eval contract binding が重要です。

6. Memory Promotion Handoff

memory candidate を memory writer や promotion gate に渡す handoff です。
artifact handoff とは criteria が違います。

7. Escalation Handoff

現 bundle で解決不能な問題を、
別 authority や incident owner に引き上げる handoff です。

8. Cross-session / Cross-system Handoff

同じ process を別 session や別 runtime で継続するための handoff です。
これはしばしば Recovery Point と結びつきます。

Handoff と Delegation の違い

この区別は非常に重要です。

Delegation

責任の一部を別 actor に委ねることです。
bundle の再配分が中心です。

Handoff

active な work cursor と次の期待行為を別 actor に移すことです。
continuity の移送が中心です。

例を挙げると、

parent が child に調査 responsibility を委ねる
→ delegation
child がその調査を開始できるように、goal slice・refs・return contract を受け取る
→ handoff
reviewer が code review responsibility を持っている
→ bundle
coding agent から reviewer に diff、tests、risk、pending issues が渡り、review が開始される
→ handoff

PCE 2.0 では、delegation と handoff はしばしば組み合わさりますが、同一ではありません。

Handoff と Escalation の違い

Handoff

同一の process continuity を別 actor に渡すこと。
通常、goal slice は継続しています。

Escalation

現在の bundle / authority では処理不能な問題を、
より上位または別系統の authority に引き上げること。
しばしば goal や decision topology も変わります。

したがって、

通常の work progression なら handoff
authority overflow、incident、ambiguity resolution なら escalation

が基本です。
ただし escalation は、多くの場合 escalation handoff を伴います。

Handoff と Checkpoint の関係

Handoff と Recovery Point は近いですが、役割が違います。

Handoff

次の actor が継続するための continuity transfer

Checkpoint / Recovery Point

途中で止まっても再開できるようにする保存構造

多くの場合、良い handoff は次のどちらかを伴います。

pre-handoff checkpoint
source 側の状態を安全に保存してから handoff する
handoff recovery package
handoff 自体を later recovery に耐える形で残す

特に cross-session handoff では、この結合が強くなります。

Handoff は「source context のコピー」ではない

PCE 2.0 では、source actor の Actor-local Compiled Context を
そのまま target に渡すことは原則として避けます。

理由ははっきりしています。

1. local context は source bundle に合わせて compile されている

target の責任に対しては、過剰または不足かもしれません。

2. source visibility が target に過剰である可能性がある

source に見えていたものが、target にとって legal とは限りません。

3. source action contract が target に不適切である

coding agent の expected output と reviewer の expected output は違います。

したがって handoff の基本形は、

source が handoff package を作る
runtime / compiler が target bundle に合わせて local context を再コンパイルする

です。

概念的には、次のようになります。

handoff_package =
  package(
    goal_slice,
    transferable_responsibility,
    required_evidence,
    unresolved_issues,
    pending_gates,
    delta_refs,
    expected_next_action,
    return_contract
  )

target_local_context =
  compile(
    process_frame,
    target_bundle,
    durable_project_state,
    runtime_state_after_handoff,
    handoff_package
  )

ここで重要なのは、
handoff package は target context の素材であって、target context そのものではない
という点です。

Handoff Package が持つべき構成要素

PCE 2.0 では、handoff package は少なくとも次を持つべきです。

1. Handoff Identity

handoff id
source frame
source actor / bundle
target actor / bundle or target frame
handoff kind

2. Purpose

なぜ handoff するのか。
review のためか、evaluation のためか、child work のためか、escalation のためか。

3. Goal Slice

target が引き継ぐべき局所 goal です。

4. Responsibility Transfer Map

何が target に移り、何が source または parent に残るのかを示します。

5. Relevant Evidence

target が判断・実行するために必要な refs や summaries です。

6. Pending Gates

まだ通っていない approval / eval / policy conditions です。

7. Delta State

どの delta item が対象で、今どの lifecycle にあるかです。

8. Unresolved Issues

source が解決できていない曖昧性や follow-up points です。

9. Expected Next Action

target に何をしてほしいのかを示します。

10. Expected Output / Return Contract

target が何を返すべきか、どの format で返すべきかを定めます。

11. Scope / Constraint Reminder

再度、何が in-scope / out-of-scope かを示します。

12. Authority / Gate Requirements

resume / approve / evaluate / promote に必要な authority です。

13. Freshness / Invalidation

この handoff package がいつ stale になるかを示します。

Handoff は acceptance を伴う

Handoff は source が送りつけた瞬間に完了するとは限りません。
受け手側の受理が必要なことがあります。

Handoff lifecycle の最小形

prepare
source が handoff package を準備する
validate
package completeness、gate continuity、authority consistency を確認する
accept
target が受理する、または runtime / governance が accept する
activate
target bundle と target local context が active になる
source quieting
source の active work が終了または suspended になる

accept が必要なのは、

target にまだ必要 evidence が足りない
target にその responsibility が割り当てられていない
required authority がない
package が stale / incomplete である

といった場合があるからです。

したがって Handoff は、多くの場合 compound transition と理解した方が正確です。

Handoff の compound transition 性

handoff は実装上、一つの atomic event に見えることもあります。
しかし概念上は、少なくとも次の部分遷移を含みます。

source-side package emission
optional checkpoint creation
target enrollment or bundle activation
context invalidation for source / others
target context compilation
acceptance / rejection
runtime state update

このため、PCE 2.0 では handoff を
単一 event というより compound transition family
として扱うのが自然です。

Handoff と Responsibility Bundle の関係

Handoff は常に Responsibility Bundle の観点から読むべきです。
とくに重要なのは、何が移るのか、何が残るのかです。

典型的に移るもの

execution responsibility
local analysis responsibility
review responsibility
evaluation task responsibility
memory candidate assessment responsibility

典型的に残るもの

goal ownership
incident ownership
final merge authority
parent frame responsibility
governance accountability

ここで重要なのは、handoff = 全責任移譲ではないことです。
多くの handoff は 部分 handoff です。

これを曖昧にすると、

approver が goal owner だと誤認される
coding agent が merge authority を持つかのように見える
child frame が親 authority を越えて動く

といった問題が起きます。

Handoff と Process Delta の関係

Handoff はしばしば Process Delta と密接に結びつきます。

1. Delta を運ぶ handoff

artifact delta、decision delta、memory candidate などを、
reviewer や evaluator や memory writer に渡す handoff です。

2. Handoff 自体が coordination delta を生む

handoff 完了、handoff rejected、handoff package created、return received などは、
status / coordination delta として表現されえます。

3. Child-to-parent return handoff は delta-centric である

子 frame はしばしば、message ではなく delta + evidence + unresolved issues を返します。

ここで重要なのは、handoff package や handoff summary は durable state そのものではなく、
多くの場合 delta の運搬・解釈を助ける coordination object だということです。

Handoff と Governance Surface の関係

良い Handoff は、必ず Governance Surface を通ります。
なぜなら handoff は、visibility と capability の再配分を伴うからです。

少なくとも次が govern されるべきです。

1. Visibility Surface

target に何を見せてよいか。
source が見ていたものを全部渡すとは限りません。

2. Capability Surface

target に何をしてよいか。
handoff によって target が source と同じ tool scope を得るとは限りません。

3. Approval Surface

handoff 自体に approval が必要なことがあります。
特に authority-sensitive な handoff ではそうです。

4. Evaluation Surface

handoff package が十分か、handoff completeness check が必要な場合があります。

5. Audit Surface

誰が何を誰に渡し、何が pending で、どの authority で accept されたかを追跡できなければなりません。

6. Escalation Surface

handoff 不成立時にどこへ引き上げるかが必要です。

つまり handoff は、単なる process efficiency の技法ではなく、
governed continuity transition です。

Handoff と Parent / Child Frame の関係

PCE 2.0 では handoff は frame をまたぐことがあります。
ここでは方向が重要です。

Parent → Child

親 frame が child frame に次を渡します。

goal slice
constraints
relevant refs
target output contract
parent に残る authority
return expectations

ここで子は、親の authority を暗黙に継承してはなりません。

Child → Parent

子 frame が親に次を返します。

process delta
key evidence
unresolved issues
recommendation
required next decision

ここで親は、子の raw local context ではなく、
返された delta をもとに次の遷移を決めます。

このように frame-crossing handoff は、
bundle の継承 ではなく goal slice と delta continuity の受け渡し が中心です。

Handoff と Recovery Point の関係

長時間 process では、handoff はしばしば Recovery Point と一緒に扱うべきです。

Before Handoff

source 側の状態を recovery point として保存しておくと、

target reject 時に戻れる
later audit ができる
handoff loss を検証できる

During Handoff

handoff package 自体が recovery-aware であるべきです。
つまり、

pending gates
delta refs
recompile requirement
legal next transitions

を持つべきです。

After Handoff

target が later session で resume する可能性があるなら、
handoff result から新しい recovery point を作る意味があります。

このため PCE 2.0 では、
handoff は recovery semantics を伴う continuity transfer
として扱うのが自然です。

Handoff と Approval Submission の違い

approval handoff は存在しますが、submission と handoff は同じではありません。

Approval Submission

ある subject を approver に差し出す行為。
対象は狭く、目的は ratification です。

Approval Handoff

approver が判断可能なように、

subject
evidence
pending issues
approval scope
expected verdict format

まで含めて continuity を渡す handoff です。

PCE 2.0 では、approval を良い process にするには、
submission より強い approval handoff が必要です。

Handoff Quality の観点

Handoff は「できた / できない」だけではなく、質の差があります。
PCE 2.0 では少なくとも次の観点で見られます。

1. Completeness

target が必要な work を再構築なしで始められるか。

2. Boundedness

不要な情報や権限を持ち込みすぎていないか。

3. Traceability

source、evidence、pending gates、next action が追えるか。

4. Legality

target が実際に次の legal transition を取れるか。

5. Freshness

handoff package が stale ではないか。

6. Recoverability

途中で止まっても handoff continuity を回復できるか。

この quality は、後に handoff loss のような process metric とも接続できます。

Handoff Package の最小スキーマ

PCE 2.0 における最小スキーマは、次のように置けます。

handoff_package:
  handoff_id:
  kind:
  source:
    frame_id:
    actor_ref:
    bundle_ref:
  target:
    frame_id:
    actor_ref:
    bundle_ref:
  purpose:
  goal_slice:
  responsibility_transfer:
    transferred:
    retained:
  relevant_evidence_refs:
  pending_gates:
  delta_refs:
  unresolved_issues:
  expected_next_action:
  expected_output:
  scope_constraints:
  required_authority:
  freshness:
  invalidation_conditions:
  recovery_ref:
  provenance:

もう少し runtime 指向に書くなら、次のようにも表せます。

handoff_package:
  handoff_id:
  handoff_kind:
    # actor_to_actor | parent_to_child | child_to_parent | approval | evaluation | promotion | escalation | cross_session
  source_ref:
    frame:
    actor:
    bundle:
  target_ref:
    frame:
    actor:
    bundle:
  reason:
  transferable_goal:
  transferable_work_state:
    current_phase:
    completed_work:
    pending_work:
  responsibility_transition:
    transferred:
    retained:
    suspended:
  evidence_refs:
  delta_state_refs:
  gate_state:
    pending_approvals:
    pending_evals:
    policy_constraints:
  unresolved_issues:
  next_transition_expectation:
  return_contract:
  visibility_constraints:
  capability_constraints:
  required_acceptance:
  recovery_binding:
  provenance:
  freshness:

このスキーマで重要なのは、次の点です。

source / target / kind がある
transferred と retained が分かれている
delta / gate / unresolved issue を持つ
next action と return contract がある
visibility / capability constraints を持つ
recovery binding を持てる

つまり Handoff Package は、
局所 continuity を安全に移送する契約付き package です。

小さな例

「checkout にクーポン併用制約を追加する」frame で、
coding agent から reviewer へ handoff するとします。

handoff_package:
  handoff_id: handoff.feature.checkout.coupon-combination.impl-to-review.v1
  handoff_kind: actor_to_actor
  source_ref:
    frame: feature.checkout.coupon-combination
    actor: coding_agent
    bundle: coding_agent_impl_bundle_v2
  target_ref:
    frame: feature.checkout.coupon-combination
    actor: reviewer
    bundle: reviewer_bundle_v1
  reason: implementation_completed_requires_review
  transferable_goal: >
    承認済み仕様に対して code change が適合しているか判断し、
    merge readiness を approve または reject する。
  transferable_work_state:
    current_phase: implementation_completed
    completed_work:
      - code_patch_created
      - related_tests_updated
      - local_tests_passed
    pending_work:
      - required_regression_suite_confirmation
      - review_verdict
  responsibility_transition:
    transferred:
      - review_execution
      - review_evaluation
    retained:
      - goal_ownership_by_product_owner
      - incident_ownership_by_product_owner
      - memory_write_authority_by_memory_writer
    suspended:
      - coding_agent_execution
  evidence_refs:
    - commit_ref: abc1234
    - approved_spec_summary
    - local_test_run_552
    - implementation_note_v1
    - rollback_note_v1
  delta_state_refs:
    - delta.feature.checkout.coupon-combination.v3
  gate_state:
    pending_approvals:
      - code_review_approval
    pending_evals:
      - required_regression_suite_confirmation
    policy_constraints:
      - no_payment_gateway_change
  unresolved_issues:
    - edge_case_for_stacked_discount_rounding
  next_transition_expectation:
    - approve
    - reject
    - escalate_if_spec_ambiguity
  return_contract:
    required_output:
      - approval_verdict
      - review_comments_if_any
      - accepted_rationale_or_rejection_reason
  visibility_constraints:
    allowed:
      - code_diff
      - test_results
      - approved_spec_summary
      - rollback_note
    disallowed:
      - production_credentials
      - unrelated_module_notes
  capability_constraints:
    allowed_actions:
      - approve
      - reject
      - request_changes
    prohibited_actions:
      - direct_code_edit
  required_acceptance:
    - reviewer_bundle_active
    - required_ci_report_available
  recovery_binding:
    recovery_ref: rp.feature.checkout.coupon-combination.after-impl.v1
  provenance:
    created_by: coding_agent
    source_transition: emit-delta.after_implementation
  freshness:
    valid_until:
      - code_diff_changes
      - approved_spec_version_changes

この例で重要なのは、handoff が単なる diff 送付ではなく、

なぜ渡すのか
何が終わっていて何が pending か
誰の責任が移り誰に残るか
何を返すべきか
何が stale 条件か

まで持っていることです。

Handoff の不変条件

PCE 2.0 では、少なくとも次の不変条件を置きます。

1. Every handoff belongs to a frame or frame relation

どの handoff も、特定 frame 内、または parent-child relation に属していなければなりません。

2. No handoff without explicit source and target

誰から誰へ渡るのか曖昧な handoff は不完全です。

3. No handoff without transferred / retained distinction

何が target に移り、何が source / parent に残るのかが必要です。

4. No handoff without next-action semantics

target が次に何をすべきか分からない handoff は continuity を渡していません。

5. No hidden authority transfer

handoff により authority が暗黙に持ち越されてはなりません。
authority transfer があるなら明示されるべきです。

6. No gate loss across handoff

pending approval / eval / policy block を handoff で失ってはなりません。

7. No blind reuse of source local context

source の local context は、target 用に再コンパイルされるべきです。

8. Cross-session handoff must be recovery-aware

later resume を伴う handoff は、Recovery Point または同等の recovery semantics を持つべきです。

9. Handoff material is not canonical truth by default

handoff summary や unresolved issue list は有用ですが、そのまま durable canonical state ではありません。

いつ Handoff を使うべきか

実務上は、handoff を切るべき局面を見極めることが重要です。
典型条件は次のとおりです。

1. Active executor / evaluator / approver が変わるとき

同じ frame の中で次の actor が work を引き継ぐときです。

2. Parent から child へ goal slice を渡すとき

child frame が work を開始できるようにする必要があります。

3. Child が親へ delta を返すとき

結果だけでなく未解決事項や recommendation も返す必要があります。

4. Approval / evaluation / promotion に subject を差し出すとき

単なる送付ではなく、judgment-ready な continuity package が必要です。

5. Cross-session continuation をする前

later resume のために continuity を package 化する必要があります。

6. Escalation をかけるとき

authority overflow や ambiguity を受け手が処理できる形にしなければなりません。

短く言えば、
active な process continuity の主担当が変わるなら handoff を明示する
のが基本です。

いつ child frame を切るべきで、いつ handoff で済むか

この判断は重要です。

Handoff で済む場合

goal slice は連続している
success criteria は大きく変わらない
frame identity を保ったまま actor が変わる
主に executor / approver / evaluator が切り替わるだけ

Child frame を切るべき場合

goal が別のまとまりになる
success criteria が独立する
eval contract が大きく変わる
capability boundary が大きく変わる
incident ownership / approval topology が変わる

短く言えば、
同じ仕事の担当交代なら handoff、
別の仕事単位なら child frame
です。

最低限の自己点検

ある process が handoff-aware かどうかは、次で点検できます。

actor 交代時に continuity package を定義しているか
source と target が明示されているか
goal slice と next action があるか
transferred / retained responsibilities を書けるか
pending gates を失っていないか
delta refs と evidence refs があるか
target 用 context を再コンパイルする前提があるか
authority transfer を暗黙にしていないか
cross-session なら recovery semantics を持つか
handoff summary を canonical truth と誤認していないか

このどれかが欠けるなら、その process はまだ handoff-aware ではありません。

暫定的なまとめ

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

process における担当交代は、単なるメッセージ転送では足りない。
次の actor が合法的かつ統治的に仕事を継続できるように、goal、責任、gate、delta、根拠、次の期待行為を continuity package として渡してはじめて handoff である。

PCE 2.0 において handoff は、効率化のための補助手段ではありません。
それは multi-actor process を壊さずに成立させるための中核遷移です。

だから Handoff は、単なる「引き継ぎメモ」ではありません。
それは、PCE 2.0 において 責任・文脈・統治・継続性を次の actor へ移送する continuity transition です。