AI Instructions as Transition Contracts

このページで分かること

この Issue を実装して がなぜ粗い指示なのか
AI への指示を Transition Contract（状態遷移契約）に変える方法
allowed / forbidden / stop condition をどう書くか
契約が AI を縛るためではなく、生成を解放するためにあること

具体例から見たい場合は、先に One Issue through PCE を読んでください。

Core Idea

AI 駆動開発では、AI への指示を単なる作業依頼として渡すと、AI の能力をうまく使い切れません。

この Issue を実装して という指示には、仕様解釈、設計判断、変更範囲の拡大、フォールバックの追加、未確定事項の事実化まで混ざります。そのため、AI は良い候補を複数出せるのに、最初に思いついた実装へ直行しやすくなります。そして依頼側は、返ってきた成果のどこに依拠してよいか分かりません。

PCE 3.0 では、AI への指示を Transition Contract（状態遷移契約） として扱います。

つまり、AI に伝える中心は次です。

どの現在状態から、どの望ましい状態へ移すのか。
どの遷移を許可するのか。
どの候補を作り、何を比較するのか。
何を許可操作として認めるか。
何を禁止操作として止めるか。
どの不変条件を保存するか。
どの進行根拠を満たす必要があるか。
何を投影として返すか。
不明点をどう扱い、どこで停止するか。

契約は依拠の基盤である

契約の第一の受益者は、AI ではなく依頼側です。

契約があるから、依頼側は「Domain 層は変わらない」「API 仕様は保存される」と 依拠したまま、実行を委ねられます。この依拠が成立しない委譲は、返ってきた成果の全体を再検証するしかなく、検証地平をすぐに越えます。

同時に、契約は AI の生成を解放します。境界が信頼できるなら、境界の内側では候補を何個出しても、どれだけ大胆に比較しても安全だからです。契約は AI を小さく使うための形式ではなく、AI の能力を候補生成、比較、実行、証拠生成に集中させるための形式です。

Responsible Continuation との関係

Transition Contract は、AI の作業を Responsible Continuation（責任ある継続）の一部にするための形式です。

State
  -> Transition
  -> Contract
  -> Warrant
  -> Projection
  -> State

AI はこの循環のすべてを勝手に担当してはいけません。どの段階を担当するのかを固定します。

Process Stages

Stage	AI の役割	許可する出力	禁止する出力
Context Binding	Context Binder	関連仕様、関連コード、過去判断、未確定事項	設計案、実装案、コード変更
Contract Formation	Contract Writer	現在状態、望ましい状態、許可操作、禁止操作、不変条件	実装方針の決定
Transition Candidate Generation	Transition Designer	複数候補、保存される構造、失われる構造、リスク、証跡	コード変更
Candidate Selection	Decision Support	候補比較、採用理由、不採用理由、トレードオフ	契約外の新候補の混入
Transition Execution	Executor	採用済み候補の適用、差分、証跡	仕様補完、範囲拡大、勝手なリファクタリング
Observation / Evidence	Observer	変更ファイル、テスト結果、影響範囲、残った Obstruction	完了の断定
Review / Evaluation	Evaluator	契約違反、禁止遷移、不変条件違反、証跡不足	改善案の先出し

重要なのは、AI に複数の役割を同時に持たせすぎないことです。

なお、Contract Formation を AI に任せる場合、その契約もまた候補です。契約の採用は依頼側の判断であり、この連鎖は最終的に Accountability Anchor（最終引受点）で底を打ちます。詳しくは最終引受点を参照してください。

Minimal Instruction Shape

transition_contract:
  process_stage: Transition Execution
  role: Executor
  current_state:
  desired_state:
  allowed_operations:
    - 表示方針の候補を 2 つ出して比較する
    - Presentation 層の表示文言を変更する
    - 関連する Widget test を追加する
  forbidden_operations:
    - Domain 層を変更する
    - AuthError の型定義を変更する
    - API 仕様を変更する
    - フォールバックを追加する
  invariants:
    - 既存の AuthError 分類を保存する
    - Domain 層に UI 文言を入れない
  warrant_required:
    - 採用した表示方針が他候補より適している理由を示すこと
    - 変更範囲が Presentation 層に閉じていること
    - Widget test が表示分岐を観測していること
  projection_required:
    - 採用候補と不採用候補
    - 採用理由
    - 変更ファイル
    - テスト結果
    - Transition Contract との対応
  uncertainty_handling:
    if_affects_implementation: stop_as_obstruction
    otherwise: return_as_completion_candidate
  stop_conditions:
    - 禁止操作が必要になった
    - 不変条件を保存できない
    - 必要な投影を生成できない

この形なら、AI の出力を評価できます。

不明点の扱い

AI に「推測するな」と言っても、実際には推測に近い補完が起こります。

重要なのは、推測そのものを完全に止めることではありません。推測を候補として扱い、比較や検証なしに正規状態へ進めないことです。推測してよい、しかし推測に依拠させてはいけない。

実装判断に影響する不明点は Obstruction として止める。
後続判断で扱える仮説は Completion Candidate として返す。
契約外の変更は、たとえ良さそうでも実装しない。

不明点は段階ごとに見つかる

不明点は、実装前にすべて見つかるとは限りません。PCE では、不明点の発見を一度きりの計画作業ではなく、遷移全体にまたがる観測として扱います。

実装前

実装前には、Blind Spot Pass（盲点確認）やプロトタイプが有効です。ここでは、まだ設計や実装を確定せず、状態と投影の差分を探します。

何を知らないか。
何を見れば判断できるか。
どの答えが設計を変えるか。
どの参照実装や過去判断を見るべきか。

この段階の出力は、実装方針ではなく、契約を作るための材料です。

実装中

実装中には、計画に含まれていない制約が見つかります。ここで AI が勝手に仕様を補完すると、未確認の推測が正規状態に混ざります。

PCE では、実装中の不明点を次のように扱います。

契約内で保守的に処理できるなら、その判断と理由を投影する。
契約の変更が必要なら、Obstruction（阻害要因）として止める。
後続判断に渡せる仮説なら、Completion Candidate（完了候補）として残す。
実装計画から逸脱した場合は、実装ノートに理由を残す。

実装後

実装後にも不明点は残ります。差分を読んだだけでは、既存経路への影響や暗黙の前提が分からないことがあります。

そのため、説明、証跡、レビュー観点、確認用の質問を投影として残します。完了とは、AI が作業を終えたことではなく、後続アクターが何に依拠してよく、何をまだ疑うべきかを判断できる状態です。

PCE Concepts との対応

契約フィールド	Core Model
current state / desired state（現在状態 / 望ましい状態）	State
allowed / forbidden operations（許可操作 / 禁止操作）	Contract
invariants（不変条件）	Contract
warrant required（必要な進行根拠）	Warrant
projection required（必要な投影）	Projection
stop conditions（停止条件）	Contract / Obstruction
role（役割）	Actor assignment（アクター割当）

つまり、PCE 3.0 は AI に作業をさせるだけの仕組みではありません。AI、人間、ツールのあいだで、依拠してよいものを揃えながら Responsible Continuation（責任ある継続）を成立させる仕組みです。