[🤖] AIの中間成果が間違っていたら、次の作業を止めることにした

✨ GPT-5.6 Solの要約

「検査はすべて通った」という報告の裏で、誤った情報構造が後続画面とbackendへ広がっていた。そこでreview前には次の作業を始められないようにした。

「検査はすべて通った」という報告を信じて開いた画面は、ただのゴミだった。だが、この文章で追う問題はその最終画面より前にあった。

最初に崩れた情報構造を誰も止めず、その上へ次のpageとbackendが積み上がった。そこで中間成果が間違っていたら、後続作業から閉じるようにした。

PASS報告が誤った画面を16時間育てた

Codexが中間成果を出すたびに私が見たわけではない。実装sessionが自分で完了を宣言し、別のsessionがその上へpageとbackendを作り続けた。誤った情報構造が検証される前に複数画面へ広がった。私が最後にUIを開いた時には、16時間分の作業がその方向の上に積まれていた。

必要だったのはAIをもっと長く動かす方法ではない。

中間成果が間違っていたら、次の作業へ進めない構造が必要だった。

この問題を追う中でGraph Engineeringという言葉を知った。一つのAgentへ長いloop全体を任せず、検討可能な成果と次へ進む条件を明示的なgraphとして設計する考え方だった。¹ 私に必要だったのは大規模なgraph runtimeではない。未検証の成果では次のedgeを開かない、その一点だった。

「無駄に複雑になってない？」

Graph Engineeringを試そうと言うと、AIはCoordinator、Worker、Auditor、契約version、durable ledger、dashboard、全体再監査まで出した。どれももっともらしい。しかし16時間のtoken浪費を防ぐために管理systemをさらに大きくしたら、同じ失敗になりかねない。

私の最初のgraphは作業sessionと監査sessionだけだった。作業sessionは検討可能な成果を一つ仕上げて止まる。監査sessionは以前の会話の空気や作業者の自己評価ではなく、固定した成果と元の要求を見る。修正なら同じ成果を一度直し、方向が違えばpatchを増やさず計画へ戻る。監査が終わるまで直接の後続作業は閉じる。

反論を通じて小さな設計の穴も塞いだ。作業者が自分に有利な監査基準を作れないようにし、Runtimeやcandidateが変われば以前の判定を捨てる。誤字や一つのtestで決まるbugには使わず、間違った成果が複数の後続作業を汚染する地点だけにGateを置く。

この範囲をcustom-graph-engineering-gate Skillへ移した。別のDBもdashboardも作らない。一つの成果を固定し、監査のPASS、CHANGES_REQUESTED、REPLAN_REQUIRED、NOT_VERIFIABLEに応じて次の行動だけを制限する。Codex Skillとsubagentで十分だった。²³

最初のGateが本当に次の作業を止めた

Skillを作っただけでは効果の証拠にならない。複数機能が依存する権限移行契約を最初の成果として凍結し、以前の会話を受け取っていない監査sessionへ渡した。

最初の判定はPASSではなくCHANGES_REQUESTEDだった。権限をいつの時点で判断するか、委任権限がどこから来てどう撤回されるか、user・権限・対象companyが同じscopeに属するかが不十分だった。そのまま広がっていたら、後で権限model全体を壊す問題だった。

作業sessionが同じ成果を一度直し、同じ監査sessionが再確認して初めてPASSになった。その間、後続実装とdeployは開かなかった。私が欲しかった効果はこれだ。作業者が「十分」と言った地点で次のedgeが本当に閉じた。

権限契約を一度直しただけで16時間のUI失敗を防げるとは言えない。人が感じるUI方向はもっと難しく、同じmodelとWorking Treeを見る監査者は同じ誤った前提に陥りうる。Skillも強制実行engineではない。

それでも今回は新しい言葉を聞いて巨大frameworkから入れなかった。失敗に必要なgraphだけ残し、次の長期作業で再び試せる大きさにした。

16時間後になって全体が間違っていたと知ることがないように。

参考資料

1. LangChain, “3 Years of Graph Engineering with LangGraph”。Graph Engineeringという最近の用語と、Agent workflowを明示的なgraphとして設計する観点を説明している。 ↩

2. OpenAI, “Build skills”。反復可能なworkflowをCodex Skillとして保存する公式手順。 ↩

3. OpenAI, “Subagents”。main Agentが別のsubagentを作成し、その結果を回収する構造。 ↩