タラバガニー設計局stalins.clubNOTE/notes/self-compiling-agentic-automation

Agentic Automationが自分自身を固定workflowへ「コンパイル」する設計

これは既に確立した固有方式の名称ではなく、複数の研究結果から導ける設計仮説である。

初回や未知状況ではLLM agentが環境を探索して仕事を行い、同種の処理が繰り返されるにつれて、その成功・失敗経験からreusable workflowやprogramを生成する。通常時はその固定されたautomationを実行し、変更や失敗が検出されたときだけagentを再び起動して探索・修復する。この構成を「self-compiling agentic automation」と考えることができる。

概念的には次の状態遷移になる。

  1. explore — Browser/Computer Use、API、CLIなどを使って未知のprocedureを発見する。
  2. verify — task completionだけでなく重要なpostconditionを確認する。
  3. generalize — 固有値をparameterへ抽象化し、conditionやfallbackを抽出する。
  4. compile/cache — workflow、script、typed toolなど再利用可能artifactとして保存する。
  5. execute — 同種taskでは固定artifactを優先して実行する。
  6. detect drift — precondition/postconditionの不一致やUI/API変更を検出する。
  7. repair — agentを再投入し、artifactを更新またはretireする。

この構成を直接裏付ける一つの完成システムがあるわけではないが、各部品に対応する研究は存在する。

Agent Workflow Memory(2024)は過去trajectoryから再利用可能なworkflowを誘導し、future generationへ注入する。AutoFlow(2024)はworkflowそのものを自動生成・最適化する。ReUseIt(2025)はagentのsuccessful/failed attemptsからcondition checkとfallbackを持つworkflowを合成し、反復taskの成功率を24.2%から70.1%へ上げた。Webwright(2026)はさらに、探索結果をparameterized CLI / Playwright codeとして保存・再利用できることを実証し、validated scriptをindexして将来呼び出す方向を明示的に議論している。

ここから「agentを常時workerとして動かすより、頻出procedureをartifactへ落として探索コストをamortizeする」という設計が自然に導ける。

ただし、固定化すれば必ず良いわけではない。Microsoft Research自身もWebwrightでscript libraryのmaintenance costを指摘している。古いscriptのsilent failureを検出し、update/retireする仕組みが必要であり、適切なscript granularityも未解決である。また長時間のComputer Useでは、クリックより状態管理と検証が難しくなるが示すように、業務ではaction列だけでなくstate、verification、confirmation、retry policyまで扱う必要がある。

したがって「trajectoryをそのままmacro化する」のでは足りない。固定artifactには少なくとも次の情報が必要になる可能性が高い。

  • taskの適用条件 / precondition
  • parameter schema
  • expected postcondition
  • actionのidempotencyとretry policy
  • human approval point
  • audit evidence
  • drift detection条件
  • fallback先のagent capability

また、WebMCPとTyped Actionは、人間向けUIの上にAgent向け意味層を足すのようなtyped actionが普及すれば、compile先はpixel操作scriptだけではなく、よりsemanticでstableなprogramになり得る。

この仮説におけるAIの役割は「毎回手を動かす作業員」から、「未知部分を探索し、自動化を生成し、壊れたときに修理するautomation engineer」へ移る。人間向けSOPも、操作方法を逐一列挙するものから、goal・constraint・approval rule・exception policyを記述するspecificationへ変わる可能性がある。

ただし最後の段落は現在の研究結果からの推論であり、一般的な業務システムでこのarchitectureが優位だと実証済みという意味ではない。頻度、変更率、failure cost、integration coverageによって、自然言語SOPを実行時プログラムとして使うのように毎回agentへ解釈させた方が安い領域も当然残る。

出典

▸ ノート一覧に戻る