[🤖] Graph EngineeringをCodexに試験適用してみた

✨ GPT-5.6 Solの要約

16時間のCodex作業がめちゃくちゃな結果に終わった後、Graph Engineeringが本当に解決策なのかを繰り返し批判的に検討し、最小限のGate Skillにして実際の権限契約へ試験適用した記録。

昨日、UI/UXを全面改編するためのページ別仕様を長時間の議論の末にまとめ、その仕様に基づいて開発するようCodex Goalを設定した。Goalは16時間動き続けた。

今日、期待しながら画面を開いたが、結果物はただのゴミだった。

二日前にも、私はAIのワンショット魔法という幻想から抜け出そうと書いた。今回は一行の指示で済ませなかった。役割別の業務とページ別仕様を作り、カレンダーとtable view、検索とfilter、失敗時の復旧までかなり具体的に決めた。失敗したprototypeを経験して、UI監査基準も別に作っていた。

それなのに、複数のworkerが一晩中コードを書き、testと監査に通ったと報告した結果は、私が見ても何を言っているのか理解しにくい古い管理画面だった。あれほど話したカレンダーとtable viewは、いったいどこへ消えたのか。

大量のtokenを使い、大量のコードを変更し、PASS報告も大量に積み上がった。それでも、私が本当に欲しかった結果はなかった。

謙虚になった。また。

そこで今回は、Graph EngineeringをCodexに試験適用してみることにした。最新の流行語を勉強して終わるのでも、巨大なframeworkから導入するのでもなく、今経験した失敗を実際に減らせる最小の形にしてみることにした。

Graph Engineeringを試す理由ができた

なぜこんなことになったのか、AIに分析させた。共通ルールにも問題があり、UI監査も文字サイズやbuttonの高さのような測りやすい項目に偏っていた。しかし最大の問題は別にあった。

Codexが中間結果を出すたびに、私が確認していたわけではない。実装sessionが自分で完了を宣言し、別のsessionがその結果を受け取って次のpageやbackendを作り続けた。最初に誤って定めた情報構造が、検証される前に複数の画面へ広がった。私が実際の画面を開いた時には、すでに16時間分の作業がその間違った方向の上に積み上がっていた。

必要なのは、AIをさらに長く動かす方法ではなかった。

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

この問題をAIと議論し続けるうちに、Graph Engineeringという言葉を知った。一つのAgentの長いloopにすべてを任せるのではなく、複数のAgent、検証器、人間の判断をnodeとedgeで結び、どの結果なら次の段階へ進めるのかを明示的に設計する考え方だった。まったく新しい技術というより、既存のworkflowやstate machineに最近付けられ始めた名前に近かった。¹

大事なのは最新のbuzzwordを一つ覚えることではなかった。今はCodex session一つがかなり長い作業全体を担当できる。ならば、そのsessionが作った結果自体をnodeにして、次のsessionへ移る条件を設計できる。

今回試すGraph Engineeringをこの作業に当てはめると、こうなる。

• node: ユーザーが独立して確認できる中間結果
• edge: 監査判定によって修正へ戻るか次の作業へ進むかを決める条件
• state: どの結果をどの基準で監査し、今どの行動が許されているかを残す記録
• cycle: 監査で欠陥が見つかった時、同じ結果だけを直して再確認する反復

Agentを何人も呼ぶこと自体がGraph Engineeringなのではない。未検証のnodeから後続edgeが開かないよう、topologyと状態遷移を先に設計することが、私の実験の核心だった。

最初に描いたgraphは作業sessionと監査sessionだけだった

この問題にGraph Engineeringを適用しようと話すと、AIはすぐに構造を大きくし始めた。Coordinator、Worker、Auditorを分け、ユーザーによる方向性承認、契約version、durable ledger、全体cold auditまで次々と付け加えた。

一つ一つは間違った話ではない。しかし私は不安だった。

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

16時間かけてtokenを使い切り成果がなかった問題を防ぐために、今度はAgentを何人も起動し、状態と報告書を積み上げるのなら、何が違うのか。Graph Engineeringを適用する作業自体が巨大な仕事になれば、また同じようにtokenだけを吸い込むかもしれない。

私が考えていたものは、ずっと単純だった。

作業sessionが確認可能な結果を一つ完成させる。
→ 監査sessionへ渡し、作業sessionは待機する。
→ 監査sessionがPASSまたは修正事項を返す。
→ その時だけ作業sessionが再開する。

私は、この流れを繰り返し使えるSkillにしてはどうかと尋ねた。しかしAIはsession構造や機械的強制の限界ばかり話して複雑にするので、別sessionの回答まで持ってきて再び問い詰めた。

「Skillにするのが非効率だって？ 本気？ 勝手なことを言っているだけじゃない？」

同時に、無条件に同意するのではなく批判するよう何度も要求した。自分の案が正しいという結論だけを聞きたかったのではない。本当に16時間の失敗を防げるのか、それとも見栄えのいい新しい玩具を作っているだけなのかを知りたかった。

反論を重ねながら実験範囲を減らした

何度も批判的検討を重ねるうちに、私の単純な案にも穴があることは認めざるを得なかった。

作業sessionが監査基準まで作れば、自分の結果に有利な基準を作れる。監査sessionに作業者のreasoningと自己評価をすべて渡せば、監査者は独立して見るのではなく、作業者の説明を読み直すだけになるかもしれない。監査中に次の作業を先に始めれば、PASS gateは無意味になる。Runtimeが変わったのに古い画面を見て通過させたり、会話のcompaction後に以前のPASSを誤って記憶したりする可能性もある。

一方で、AIの提案をすべて受け入れる必要もなかった。三つの長寿命session、別のgraph runtime、DB、dashboard、全pageへの監査、契約変更のたびの全件再監査は捨てた。それを全部作れば、製品より管理体系のほうが大きくなる。

最終的に残したのは次の原則だけだった。

• メインsessionが調整と作業を兼ねる。
• 本当にGateが必要な結果でだけ、別の監査sessionを開く。
• 監査sessionには以前の会話全体を渡さない。
• 監査対象を固定し、監査が終わるまでその結果と直接の後続作業を変更しない。
• 実装の欠陥と、方向性や契約自体の欠陥を区別する。
• 一度修正して再監査しても重大な問題が残れば、patchを続けず計画から開き直す。
• 契約が変われば、影響を受ける作業だけを再検査する。
• 監査のPASSは、私の製品方向承認や配布承認の代わりにはならない。

何よりも、すべての作業にこの構造をかぶせないことにした。誤字一つ、決定的なtest一つで終わるbug、候補すらない自由探索に監査sessionを付けるのは無駄だ。間違った結果が複数の後続作業を汚染し得る地点だけにGateを置く。

page一つを自動的にnode一つにすることもしなかった。listを検索し、詳細を開き、処理し、元のfilterへ戻る流れが一つのユーザー業務なら、そのjourney全体が確認単位になるべきだ。逆に、同じpatternを単純に繰り返す画面を毎回別に監査する理由はない。

ここまで削ると、私が望んだ単純なgraphはそのまま残り、なぜ止めるのか、何を監査するのかは明確になった。

最小graphをCodex Skillへ移した

最終的にCodexへ作らせたのは、custom-graph-engineering-gateという共通Skillだった。OpenAIには反復workflowをSkillとして保存し、メインAgentが別のsubagentを呼び出して結果を受け取る仕組みがすでにあった。²³ 別serviceを作らなくても、作業sessionと監査sessionの往復をCodexの中で構成できた。

実装を膨らませないようにも指示した。実行scriptも、別DBも、graph dashboardも作らなかった。Skill本体とCodex表示用の最小metadataだけを作った。

Skillが行うことは大きく三つだ。

第一に、今の作業が本当にGateを開くほど重要かを先に判断する。間違った中間結果が複数の後続結果を壊し得る時だけ使う。

第二に、監査する結果を一文で固定する。ユーザーが得る結果、成功と失敗を分ける基準、今監査する正確なcandidate、通常の検証経路、PASS後に開かれる直接の後続作業だけを記録する。変更file数やtest数はユーザーの結果を代替できない。

第三に、作業と監査の間の遷移を制限する。

PASS              → 直接の後続作業だけ進める
CHANGES_REQUESTED → 同じ結果を一度修正して再監査
REPLAN_REQUIRED   → 実装ではなく契約や作業分解から再検討
NOT_VERIFIABLE    → 証拠なしに通過させない

監査sessionには以前の会話contextを渡さない。私がなぜ怒っていたか、作業sessionがどれだけ努力したか、実装者がどこを良いと考えたかは監査証拠ではない。元の要求と現在の結果を直接見せる。

監査中にsourceやRuntimeが変われば、以前の判定は捨てる。中断やcompaction後に、どの結果がどの判定を受けたかを実際の証拠から復元できなければ、通過したと推測しない。

これは最初に私が話した構造と大きく違わない。“監査sessionを一つ置く”という考えを、次のsessionでも同じtopologyで実行できるよう、忘れやすい遷移条件だけをSkillに埋め込んだ。

作ったgraphを実際の契約に試験適用した

Skillを作ったという理由だけで良くできたと信じれば、今回の事故と何も変わらない。そこで新しいSkill自体も、以前の会話contextを引き継いでいない別reviewerへ渡した。

最初に、単純な文言修正にはこのSkillを適用しないことが正しいかを確認した。使わなくてよい仕事で使わないことが、token浪費を防ぐ最初の検証だった。

次に、複数機能が共通して依存する権限遷移契約を最初の実nodeにした。作業結果を固定して監査sessionへ渡すと、最初のverdictはPASSではなくCHANGES_REQUESTEDだった。権限をどの時点で評価するか、委任された権限がどこから来てどう失効が伝播するか、ユーザー・権限・対象会社が同じscopeへ本当に結び付いているかが不十分だった。

そのまま複数機能へ展開していたら、後で権限境界全体を作り直す問題だった。作業sessionが同じ範囲だけを一度修正し、同じ監査sessionが再確認した後にようやくPASSが出た。その間、後続実装と配布は開かなかった。

小さな試験だったが、私が望んだGraph Engineeringの効果は確認できた。作業者が「十分」と考えたnodeで後続edgeが閉じ、その結果が他の作業へ広がる前に直せた。修正された同じcandidateを同じ監査sessionが再び確認し、PASSを返した後にだけ次の段階を開けた。

最初の実験は通ったが、UI失敗を解決したとは言えない

最初の試験では意図したgraphが動いた。しかし、このSkillが実際に16時間のUI失敗を防いだとは言えない。比較的明確なsourceを持つ権限契約の監査と、人が見て感じるUI方向を途中で止めることは別の問題だ。大規模UI作業で総時間とtokenを減らせるかはまだ検証していない。監査sessionも同じmodelと同じWorking Treeを見るため、作業sessionと同じ誤った前提に陥り得る。Skillは指示であって、強制実行engineではない。

したがって、次の長期作業をPASS数で評価してはいけない。

• 最初の誤った方向を全体展開前に捕まえたか。
• 監査に使ったtokenより、防いだ再作業のほうが大きかったか。
• 私が最初の暫定結果を見る時点が遅くならなかったか。
• 作業sessionと監査sessionが同じ誤った契約に一緒に騙されなかったか。

効果がなければルールを増やすのではなく、Gateを減らすべきだ。同じ失敗が繰り返されたら、監査段階をもう一つ加えるのではなく、そもそも何を一つの結果として束ね、どの証拠をreviewerに見せたかから見直すべきだ。

Graph Engineeringという言葉を知ったからといって、急にAIを上手く使えるようになったわけではない。ただ今回は、流行語を聞いて巨大frameworkから導入しなかった。自分が経験した失敗に必要なgraphだけを残し、AIの過剰な提案にも反論し続け、次のsessionでも再び試せる小さなSkillにした。

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”. メインAgentが別subagentを作成し、その結果を回収する構造を説明している。 ↩