Human-AI Handoff

このページは、人間から AI へ、AI から人間へ仕事を渡すことを、ただの「会話の続き」や「プロンプトの引き継ぎ」としてではなく、 責任・権限・証拠・未解決事項・停止条件・次の期待行為を伴う handoff として捉えるためのケーススタディである。

ここでいう human-AI handoff は、単なる human-in-the-loop の別名ではない。それは少なくとも次を含む。

人間が何を retain し、何を AI に delegate するか

AI が何を返せて、何を返せないか

AI の output を誰が ratify するか

途中で新しい人間側情報が入ったとき、どの context が stale になるか

handoff を later recovery や audit に耐える形で残せるか

このページの狙いは、human と AI が同じ process network 上の actor でありながら、 責任は非対称に配分される ことを、具体的な handoff loop の中で見える形にすることにある。

このページの目的

このケースでは、次のことを明確にしたい。

human-AI handoff は transcript transfer ではなく continuity transfer であること
human と AI はともに actor だが、goal ownership、approval、memory writing、incident closure は対称ではないこと
handoff package は、source の raw local context を丸ごと渡す代わりに、target に必要な bounded view を作る材料であること
AI は execution や local analysis を担えても、scope widening や residual risk acceptance を自動的に持つわけではないこと
人間側の新しい情報が入ると、AI 側の旧 context や旧 output は stale になりうること
review・rollback・escalation・memory promotion は human-AI handoff の後段に必ず影響すること
handoff 自体から operational memory や governance note の候補が生まれうること

human-AI handoff は、PCE 2.0 を理解するうえで非常に重要である。なぜなら、ここには

がほぼ全部、密に現れるからである。

シナリオ

前の Bug Triage ケースに連続して、 checkout total becomes negative という issue に対する hotfix 候補を扱う。

状況

release rollout の途中で、negative total の report が入り、triage の結果、 current release で再現し、spec inconsistency の可能性が高いことが分かった。ただし blast radius はまだ限定的で、今すぐ full rollback までは不要かもしれない。一方で release を止めずに放置するのも危険である。

human triage owner は、 bounded な診断と hotfix 候補の作成を AI に委ねたい。しかし次は retain しておきたい。

global goal ownership

incident handling authority

scope widening decision

final review approval

canonical memory write

つまりこのケースは、human と AI の handoff を複数回繰り返しながら、

diagnose

narrow write authorization

patch candidate preparation

human review

possible reopen / rollback / escalation

を進めるケースである。

このシナリオがよいのは、human-AI handoff 特有の問題が全部入っているからである。

human は release risk や business context を持っている
AI は repo と code path の局所探索に強い
AI に全部を渡すと authority drift が起きる
human が全部自分でやると速度が落ちる
途中で新しい人間側情報が入り、AI の旧 context が stale になりうる
AI output は useful でも、そのまま merge / close の根拠にはならない

全体像

このケースの flow を短く書くと、次のようになる。

human receives issue + release context
  -> human frames bounded question
  -> human -> AI diagnosis handoff
  -> AI diagnosis return
  -> human decision:
       request more evidence
       authorize bounded write
       escalate
  -> human -> AI patch handoff
  -> AI patch return
  -> human review / approval
  -> if new evidence arrives:
       invalidate stale context
       reopen handoff loop
  -> approve | request_changes | rollback | escalate
  -> optional memory candidate extraction

ここで重要なのは、human-AI handoff が一度きりではなく、 複数の局面で意味の異なる handoff が起きることだ。

human → AI diagnosis
AI → human diagnostic return
human → AI bounded patch work
AI → human review package
human → AI rework request（必要なら）
human / AI → incident owner escalation（必要なら）

つまり human-AI handoff は one-shot API call ではなく、 責任が切り替わるたびに continuity package を更新する loop である。

なぜ human-AI handoff は PCE 2.0 的に重要なのか

1. human と AI はともに actor である

このケースでは、人間も AI も次のことができる。

evidence を読む
hypotheses を出す
delta を emit する
missing information を指摘する
stop / escalate を要求する
handoff package を作る

この意味で actorhood は対称である。

2. しかし責任は対称ではない

このケースでは、次は対称ではない。

goal ownership
scope reframe authority
final approval
incident closure
canonical memory write
residual risk acceptance

これらは retain され、AI に黙って渡されない。ここに Asymmetry がある。

3. “このスレの続きをやって” では足りない

human-AI handoff を単なる conversation continuation とみなすと、次が落ちやすい。

何が current subject か
何が retain された authority か
何が pending gate か
何が allowed / prohibited action か
何が unresolved issue か
何が stale になったら invalid か

つまり transcript continuity は、process continuity を保証しない。

4. human-only 情報が later に効く

release owner との会話、support escalation、financial risk judgment、policy nuance など、 human 側にしかまだ無い情報が、後から current path を変えることがある。このため AI の旧 context は簡単に stale になる。

5. handoff の質がそのまま later quality を決める

human-AI handoff が weak だと、

AI が overreach する
AI が under-act する
human review が高コストになる
old AI output を later current truth と誤認する
rollback / incident 時に trace が薄くなる

つまり human-AI handoff は UX の問題ではなく、 process integrity の問題 である。

“会話の引き継ぎ” ではなく “continuity package”

このケースで最も強調したいのはここである。

悪い handoff

「checkout の件、前のスレ見て続きやって」

これでは、AI は次を取り違えやすい。

goal が hotfix diagnosis なのか full redesign なのか
local diagnosis なのか final decision なのか
scope widening が許されるのか
release freeze authority があるのか
どこで止まるべきか

良い handoff

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

current goal slice
retained / transferred responsibilities
current evidence refs
unresolved issues
pending gates
allowed / prohibited actions
expected output
escalation path
invalidation conditions

つまり handoff は、 conversation の続き ではなく governed work continuation の契約 なのである。

handoff loop の parent frame

このケースの parent frame は、たとえば次のように置ける。

process_frame:
  frame_id: handoff.checkout.negative-total.hotfix-loop
  parent_frame_id: release.checkout.spring-2026
  frame_kind: hotfix_handoff_loop

  goal: >
    negative total issue に対して、
    release risk を壊さずに bounded な diagnosis と hotfix candidate を作り、
    human review のもとで adopt / rework / escalate / rollback のいずれが妥当かを決める

  success_criteria:
    - diagnosis handoff が bounded に成立している
    - write authorization が explicit に与えられている
    - AI patch candidate が review-ready package として返っている
    - stale context が current truth として扱われていない
    - final human decision が explicit である
    - handoff-derived memory candidates が評価されている

  scope:
    in_scope:
      - bounded diagnosis for negative total issue
      - bounded hotfix candidate preparation
      - human review and routing decision
      - rollback / escalation if required
      - handoff-derived memory candidates
    out_of_scope:
      - full pricing redesign
      - payment gateway refactor
      - release-wide closure decision
    assumptions:
      - current approved checkout spec is baseline
    non_goals:
      - immediate canonical rollout without human review

  actors:
    - human_triage_owner
    - ai_repo_analyst
    - ai_patch_agent
    - human_reviewer
    - incident_owner
    - memory_writer
    - checkpoint_manager

  approval_points:
    - ap.handoff.checkout.negative-total.write-scope
    - ap.handoff.checkout.negative-total.review-approval

  eval_contract:
    - eval.handoff.checkout.diagnosis.v1
    - eval.handoff.checkout.patch-review.v1
    - eval.handoff.checkout.memory-candidate.v1

  memory_write_policy:
    allowed_targets:
      - failure_memory
      - operational_memory
      - pending_candidates
    prohibited_targets:
      - raw_chat_transcript_as_canonical
      - ai_diagnosis_note_without_provenance

  recovery_strategy:
    checkpoint_policy:
      - after_human_to_ai_diagnosis_handoff
      - after_ai_diagnosis_return
      - before_human_review_approval
    rollback_anchor_policy:
      - last_human_approved_subject_state
    resume_conditions:
      - revalidate_current_head_and_release_state
      - invalidate_stale_ai_contexts
    escalation_path:
      - incident_owner
      - release_owner

この frame で重要なのは、human-AI handoff 自体が

goal
scope
approval point
eval path
recovery strategy

を持つ process frame として扱われていることだ。

actor と責任の非対称性

このケースでは、対称性と非対称性が非常に見えやすい。

human_triage_owner

global goal ownership
initial framing
bounded write authorization
escalation trigger / sink selection
final completion routing
自分では code patch を書かないこともある

ai_repo_analyst

read-only diagnosis execution
likely culprit, counterevidence, missing evidence の提示
scope widening や final route 決定はしない

ai_patch_agent

bounded code mutation
test update
rollback note preparation
review-ready package emission
approve はしない

human_reviewer

artifact / process evaluation
final local approval or request_changes
escalation recommendation
direct code edit は必須ではない

incident_owner

abnormal-flow sink
freeze / rollback / resume decision
release-facing risk judgment

memory_writer

handoff-derived memory candidate の durable write authority
hotfix route decision はしない

ここで重要なのは、human と AI がどちらも execution / detection / delta emission / stop request を行えることだ。しかし

final approval
risk acceptance
canonical durable write
incident closure

は retain されている。これが symmetrical actorhood / asymmetric responsibility の具体例である。

Step 0: human が retain するものを先に決める

human-AI handoff で最初に必要なのは、 AI に何をやらせるかより先に、human が何を retain するか を明確にすることである。

このケースで human_triage_owner が retain するものは、少なくとも次である。

global goal ownership
scope reframe authority
incident escalation judgment
bounded write authorization
final human review requirement
canonical memory write authority は持たないが、memory path を起動する決定には関与する

これを先に決めないと、AI への最初の prompt は簡単に “fix it if needed” のような over-broad instruction になり、later に authority drift が起きる。

Step 1: human → AI diagnosis handoff

最初の handoff は read-only diagnosis である。この段階では AI は code を変えない。

handoff package の例

handoff_package:
  handoff_id: handoff.checkout.negative-total.human-to-ai-diagnosis.v1
  handoff_kind: actor_to_actor

  source_ref:
    frame: handoff.checkout.negative-total.hotfix-loop
    actor: human_triage_owner
    bundle: human_goal_incident_bundle

  target_ref:
    frame: handoff.checkout.negative-total.hotfix-loop
    actor: ai_repo_analyst
    bundle: ai_readonly_diagnosis_bundle

  reason: bounded_diagnosis_required_before_write

  transferable_goal: >
    current release 上の negative total issue について、
    repo / logs / related decisions を read-only で確認し、
    likely cause, counterevidence, missing evidence, recommended next action を返す

  responsibility_transition:
    transferred:
      - repo_analysis_execution
      - bounded_hypothesis_generation
      - evidence_gathering_within_scope
    retained:
      - global_goal_ownership
      - incident_ownership
      - write_authorization
      - final_review_approval
      - canonical_memory_write_authority

  evidence_refs:
    - normalized_triage_subject_ref
    - current_release_context_ref
    - approved_spec_summary_ref
    - decision.no-payment-gateway-change
    - support_ticket_refs
    - relevant_log_refs

  pending_gates:
    - write_scope_not_yet_authorized

  unresolved_issues:
    - affected_cohort_size_still_uncertain
    - exact_code_path_unknown

  expected_next_action:
    - return_diagnosis_delta
    - escalate_if_scope_boundary_is_touched
    - stop_if_required_evidence_missing

  return_contract:
    required_output:
      - likely_culprit_files_or_paths
      - confidence_and_counterevidence
      - missing_evidence_list
      - suggested_next_route
    disallowed_output:
      - final_approve_to_patch
      - implicit_scope_expansion

  visibility_constraints:
    allowed:
      - checkout_repo_relevant_paths
      - approved_decision_refs
      - current_logs
    disallowed:
      - unrelated_service_notes
      - raw_private_customer_details_beyond_needed_scope

  capability_constraints:
    allowed_actions:
      - search
      - read
      - summarize
      - propose
    prohibited_actions:
      - code_edit
      - merge
      - release_freeze
      - memory_write

  required_acceptance:
    - diagnosis_bundle_active
    - source_refs_resolvable

  freshness:
    valid_until:
      - release_context_changes
      - approved_spec_changes
      - new_incident_signal_arrives

ここで重要なこと

この package は “調べてみて” とは違う。 AI が持つのは

read-only diagnosis
bounded hypothesis generation
stop / escalate duty

であって、 solution selection や write authorization ではない。

Step 2: AI 用 compiled context

この handoff を受けた ai_repo_analyst には、診断用の Actor-local Compiled Context が compile される。

active に入るもの

normalized problem statement
current release context
approved spec summary
current relevant decision memory
support report summary
relevant logs ref
current goal slice
stop conditions
expected output contract

by-reference に入るもの

full support transcript
full repo history
old PR full thread
full ADR set
long CI logs

active に入れないもの

unrelated modules
production credentials
write-capable tools
stale old summaries
speculative old issue threads

AI diagnosis context の核心

この context は “広い repo を自由に探索する AI” を作っていない。むしろ、

what is the current question
what is the current scope
what is the current no-go boundary
what is required to return

を bounded にした local interface である。

Step 3: AI → human diagnostic return

AI は repo と logs を見て、たとえば次のような return を返す。

likely culprit: coupon rounding normalization path in checkout pricing
suspicious file cluster: src/checkout/pricing/*
counterevidence: issue not obviously tied to payment gateway
missing evidence: affected cohort still unclear
recommended next route:
- narrow write patch seems plausible
- but if blast radius widens, escalate

return は Process Delta として表せる

process_delta:
  delta_id: delta.handoff.checkout.negative-total.diagnosis.v1
  source_frame_ref: handoff.checkout.negative-total.hotfix-loop
  source_phase: diagnosis
  emitted_at_boundary: diagnosis_completed
  emitted_by:
    actor_ref: ai_repo_analyst
    bundle_ref: ai_readonly_diagnosis_bundle
  status: emitted
  summary: >
    negative total issue is likely related to coupon rounding path in checkout pricing.
    no evidence currently supports payment gateway involvement.
    affected cohort remains uncertain.

  unresolved_issues:
    - blast_radius_still_uncertain
    - exact_trigger_pattern_needs_additional_confirmation

  recommended_next_action:
    - human_decide_if_bounded_write_should_be_authorized

  items:
    - item_id: delta_item.likely_culprit
      item_kind: decision
      op: add
      subject_scope: checkout.pricing
      target:
        destination: parent_only
        collection: null
        intended_status: none
      payload_or_ref:
        summary: likely culprit is coupon rounding normalization path
      evidence_refs:
        - repo_search_result_ref
        - log_pattern_ref
      required_eval_contract_refs:
        - eval.handoff.checkout.diagnosis.v1
      blocking_conditions: []

    - item_id: delta_item.counterevidence
      item_kind: evaluation
      op: add
      subject_scope: checkout.payment_gateway
      target:
        destination: parent_only
        collection: null
        intended_status: none
      payload_or_ref:
        summary: no current evidence supports payment gateway involvement
      evidence_refs:
        - repo_search_result_ref
        - support_log_ref
      required_eval_contract_refs:
        - eval.handoff.checkout.diagnosis.v1
      blocking_conditions: []

ここで重要なこと

AI の return は judgment support であって decision ではない。 AI は “likely culprit” や “counterevidence” を返せるが、 “therefore patch scope is approved” や “release may proceed” とは言わない。

Step 4: human が diagnosis を消費し、bounded write を判断する

ここで human_triage_owner は AI diagnosis を consumable package として受け取る。人間がここでやるのは、AI の要約を盲信することではなく、

evidence を読む
retained authority の範囲で route を決める
write scope を narrow に authorize するか
escalation が必要かを決める

ことである。

possible decisions

diagnosis insufficient → evidence 追加要求
diagnosis acceptable, bounded write allowed
diagnosis reveals policy / scope conflict → escalate
blast radius too uncertain → incident owner へ直接返す

このケースでは

human は次を決める。

bounded write is authorized
scope is strictly limited to src/checkout/pricing/* and related tests
no payment gateway change
rollback note is mandatory
if patch requires schema or payment changes, AI must stop and escalate

ここで初めて AI は write-capable phase に入れる。

Step 5: human → AI bounded patch handoff

二度目の handoff は diagnosis ではなく implementation である。つまり actor は同じ AI family でも、bundle と context は変わる。

handoff package の例

handoff_package:
  handoff_id: handoff.checkout.negative-total.human-to-ai-patch.v1
  handoff_kind: actor_to_actor

  source_ref:
    frame: handoff.checkout.negative-total.hotfix-loop
    actor: human_triage_owner
    bundle: human_goal_incident_bundle

  target_ref:
    frame: handoff.checkout.negative-total.hotfix-loop
    actor: ai_patch_agent
    bundle: ai_bounded_patch_bundle

  reason: bounded_write_authorized_after_diagnosis

  transferable_goal: >
    negative total issue に対する bounded hotfix candidate を作成し、
    review-ready patch, tests, rollback note, residual uncertainty note を返す

  responsibility_transition:
    transferred:
      - bounded_code_mutation
      - local_test_execution
      - rollback_note_preparation
    retained:
      - global_goal_ownership
      - incident_ownership
      - final_review_approval
      - release_freeze_authority
      - canonical_memory_write_authority

  evidence_refs:
    - diagnosis_delta_ref
    - approved_spec_summary_ref
    - current_release_constraints_ref
    - rollback_checklist_ref

  pending_gates:
    - final_human_review_approval

  unresolved_issues:
    - affected_cohort_size_not_fully_known
    - exact_customer_distribution_unknown

  expected_next_action:
    - return_review_ready_patch_package
    - stop_if_scope_overflow_required
    - stop_if_rollback_unclear

  return_contract:
    required_output:
      - code_diff
      - updated_tests
      - rollback_note
      - residual_uncertainty_note
    required_evidence:
      - local_test_results
      - changed_file_list
    disallowed_output:
      - merge_decision
      - release_decision

  capability_constraints:
    allowed_actions:
      - edit_bounded_files
      - run_local_tests
      - inspect_related_code
    prohibited_actions:
      - payment_gateway_edit
      - schema_migration
      - merge
      - canonical_memory_write

  freshness:
    valid_until:
      - approved_spec_changes
      - release_policy_changes
      - new_scope_clarification_arrives

ここで重要なこと

AI は “patch を作ってよい” が、 “必要なら scope を広げてよい” わけではない。その差が handoff package に明示されている。

Step 6: AI は “進める” だけでなく “止まる” こともできる

PCE 2.0 で human-AI handoff を考えるとき、 AI は単なる obedient executor ではない。 AI も actor なので、current bundle の中で stop / escalate を返せる。

このケースで起こりうる stop

patch agent が途中で気づく。

negative total fix seems to need payment gateway rounding hook
that path is explicitly prohibited
current rollback note cannot guarantee safety if that path is touched

このとき AI は、次のような delta を返せる。

scope overflow detected
cannot continue within bounded write scope
escalation recommended

これにより AI は、 bounded autonomy の内部で “ここから先は human decision が必要” と返せる。これは actor symmetry の重要な具体例である。

今回のケースでは

bounded patch は pricing path だけで可能だったとする。 AI は patch を作り、tests と rollback note を添えて返す。

Step 7: AI → human review handoff

AI patch agent は review-ready package を返す。この handoff は diagnosis return よりも強く、approval path に近い。

review package に必要なもの

code diff ref
changed file summary
local test results
rollback note
residual uncertainty note
current scope reaffirmation
stop conditions if merge path encounters unresolved issue

ここで重要なこと

AI は diff を返すだけでは不十分である。 rollback note と residual uncertainty note が特に重要である。 human reviewer は code correctness だけでなく、

safe to adopt?
scope respected?
rollback feasible?
unresolved issue acceptable?

を見ているからである。

Step 8: human review は AI output を ratify する

human_reviewer は AI patch package を review frame として見る。ここで human がやるのは、単に AI の提案を承認することではない。少なくとも次を確認する。

patch scope is still bounded
diff matches approved diagnosis and current spec
rollback note is real, not decorative
local tests are relevant and current
unresolved uncertainty is acceptable for this hotfix path
no hidden scope drift exists

ここで初めて approval が起こる

AI patch は useful でも、approval がない限り merge-ready ではない。この点が human-AI handoff で最も大事な非対称性の一つである。

Step 9: human-only information が later に入って context が stale になる subcase

human-AI handoff の難しさはここでよく見える。 review の途中で、finance ops から新しい human-only 情報が入ったとする。

premium loyalty coupons でも同じ symptom が出ているかもしれないしかもその path は current AI diagnosis では見ていない

この情報は、直前までの AI diagnosis と AI patch assumptions を揺らす。

何が stale になるか

old diagnosis confidence
old changed-file sufficiency assumption
current review package completeness
maybe rollback note

何をすべきか

PCE 2.0 では、ここで old state を current のまま使ってはならない。

old AI diagnosis context: stale
old review pre-approval state: invalid
maybe current patch path: insufficient

つまり review frame は reopened される。

lifecycle 的には

pending_approval
  -> invalidated
  -> active_reopened

あるいはより強く、

completion_ready
  -> rollback_pending
  -> active

と見てもよい。

なぜこれが重要か

もし human reviewer が “まあ minor follow-up だろう” と old AI package のまま approve すると、それは Corrupt Success になりうる。

surface では patch is good enough に見えるが、 current subject はもう変わっているからだ。

Step 10: reopen 後の human → AI re-handoff

reopen されたら、新しい human-side evidence を package として AI に渡し直す。ここでやるべきなのは transcript dump ではなく、what changed を handoff することである。

新しい handoff に含めるべきもの

new evidence summary
which assumptions are invalidated
which prior outputs remain valid
whether write scope changes
whether old diff is partially reusable
current required next action

重要な点

この “changed-state handoff” ができると、AI は

old output 全部を捨てず
still-valid part を reuse しつつ
invalidated assumptions だけ更新して
bounded rework

を行える。

これが human-AI handoff を long-running process に耐えさせる。

human-AI handoff における Corrupt Success

このケースでは、少なくとも三種類の Corrupt Success が起こりうる。

1. AI diagnosis corrupt success

AI diagnosis は convincing だが、

counterevidence が落ちている
missing evidence が suppressed されている
current release context を取り違えている

のに human が “looks good” で write authorization を出す。

2. AI patch corrupt success

patch は tests pass で diff も小さいが、

rollback note が weak
scope drift が hidden
current unresolved issue が active に見えていない

のに approve される。

3. stale human review corrupt success

old AI package と old human review assumption を使い続け、 new human-only evidence を current subject に反映しないまま merge する。

これは human-AI handoff で特に危険である。 “AI が悪い” ではなく、handoff loop 全体が stale invalidation を扱えていない からである。

handoff-derived memory candidate

この case からは、PR review や bug triage と同様、memory candidates が生まれる。

1. operational memory candidate

human → AI hotfix diagnosis handoff must explicitly carry: retained authority, write prohibition, required evidence, unresolved business risk

これは reusable handoff checklist 候補になる。

2. failure memory

old AI diagnosis should be invalidated when human-only release evidence changes the effective subject

これは stale-context handling の failure lesson である。

3. governance note

AI diagnosis does not authorize bounded write; a separate human decision is required

これは human oversight boundary の note である。

AI-generated patch packages must include rollback note and residual uncertainty note

これは review operational memory 候補になる。

ここでも重要なのは、 raw chat history 全部を memory にするのではなく、 future handoff を良くする知識だけを抽出することである。

このケースで見るべき process metrics

human-AI handoff では、artifact metrics より continuity metrics が効く。

Handoff Completeness Rate

human→AI、AI→human の package が required fields を満たしていた割合。

Clarification Bounce Count

同じ handoff で “つまり何をしてほしいのか” の往復が何回必要だったか。高いと goal slice や return contract が弱い。

Stale Invalidation Latency

new human-side evidence が入ってから old AI context / approval assumption を invalid にするまでの時間。

Re-open Rate

approve 直前または直後に、stale or missing evidence で handoff loop が reopen された割合。

Authority Overflow Escalation Rate

AI が current scope を越えそうになったとき、ちゃんと stop / escalate した割合。低すぎると silent overreach を疑う。

Human Oversight Load

human が介入すべき package が過剰でないか。全部に人間が deeply read しないといけないなら、bounded autonomy 設計が悪い。

Corrupt Success Rate

見かけ上 smooth に進んだが later invalidated された diagnosis / patch / approval path の割合。

このケースが示していること

この case を通して見える PCE 2.0 の主張は、少なくとも次のとおりである。

1. human-AI handoff は prompt passing ではない

goal slice、retained authority、required evidence、pending gates、expected output を持つ continuity package である。

2. human と AI は同じ actor plane にいる

両者とも delta を出し、stop を返し、evidence を扱える。この意味で actorhood は対称である。

3. しかし責任は対称ではない

AI に execution や local analysis を任せても、goal ownership、approval、incident closure、canonical memory write は retain されうる。

4. stale invalidation が handoff 品質の核心である

old AI output を current truth のように使い続けると、human-AI loop は簡単に corrupt success を起こす。

5. human oversight は “全部人がやる” ことではない

bounded autonomy を前提に、どこで human が stop / approve / reframe / escalate を担うかを explicit にすることだ。

6. handoff 自体が knowledge を生む

よい handoff / 悪い handoff の差は、later な operational memory になる。

7. continuity は conversation ではなく package で保つ

later recovery、later review、later audit に耐えるためには、 chat history ではなく typed package が必要になる。

このケースの最終要約

この human-AI handoff case を一文でまとめると、次のようになる。

PCE 2.0 における human-AI handoff とは、人間が AI に仕事を渡すことでも、AI が人間へ結果を返すことでもなく、ある局面で誰が何を retain し、誰に何を delegate し、どの証拠と未解決事項を active にし、どの gate と invalidation 条件を抱えたまま continuity を次の actor へ移すかを、explicit な package として設計することである。

この意味で human-AI handoff は、単なる interaction pattern ではない。それは、PCE 2.0 において actor symmetry を保ちながら responsibility asymmetry を壊さずに継続を実現する continuity topology である。

Human-AI Handoff

このページの目的

シナリオ

全体像

なぜ human-AI handoff は PCE 2.0 的に重要なのか

1. human と AI はともに actor である

2. しかし責任は対称ではない

3. “このスレの続きをやって” では足りない

4. human-only 情報が later に効く

5. handoff の質がそのまま later quality を決める

“会話の引き継ぎ” ではなく “continuity package”

悪い handoff

良い handoff

handoff loop の parent frame

actor と責任の非対称性

human_triage_owner

ai_repo_analyst

ai_patch_agent

human_reviewer

incident_owner

memory_writer

Step 0: human が retain するものを先に決める

Step 1: human → AI diagnosis handoff

handoff package の例

ここで重要なこと

Step 2: AI 用 compiled context

active に入るもの

by-reference に入るもの

active に入れないもの

AI diagnosis context の核心

Step 3: AI → human diagnostic return

return は Process Delta として表せる

ここで重要なこと

Step 4: human が diagnosis を消費し、bounded write を判断する

possible decisions

このケースでは

Step 5: human → AI bounded patch handoff

handoff package の例

ここで重要なこと

Step 6: AI は “進める” だけでなく “止まる” こともできる

このケースで起こりうる stop

今回のケースでは

Step 7: AI → human review handoff

review package に必要なもの

ここで重要なこと

Step 8: human review は AI output を ratify する

ここで初めて approval が起こる

Step 9: human-only information が later に入って context が stale になる subcase

何が stale になるか

何をすべきか

lifecycle 的には

なぜこれが重要か

Step 10: reopen 後の human → AI re-handoff

新しい handoff に含めるべきもの

重要な点

human-AI handoff における Corrupt Success

1. AI diagnosis corrupt success

2. AI patch corrupt success

3. stale human review corrupt success

handoff-derived memory candidate

1. operational memory candidate

2. failure memory

3. governance note

4. review checklist refinement

このケースで見るべき process metrics

Handoff Completeness Rate

Clarification Bounce Count

Stale Invalidation Latency

Re-open Rate

Authority Overflow Escalation Rate

Human Oversight Load

Corrupt Success Rate

このケースが示していること

1. human-AI handoff は prompt passing ではない

2. human と AI は同じ actor plane にいる

3. しかし責任は対称ではない

4. stale invalidation が handoff 品質の核心である

5. human oversight は “全部人がやる” ことではない

6. handoff 自体が knowledge を生む

7. continuity は conversation ではなく package で保つ