自然言語SOPを実行時プログラムとして使う

LLM agentによる業務自動化には、既存のStandard Operating Procedure（SOP）をほぼそのまま実行時の制御情報として利用する方式がある。

典型的には、SOPに「顧客情報を確認する」「条件Aなら返金する」「不明ならユーザーに確認する」といった自然言語の手順を書き、agentは現在の状態と実行履歴を見ながら次のactionを選ぶ。2025年のAgent-Sはこの構成を明示的に研究しており、SOPをlogical block of textとして与え、execution memoryとAPI/UIなどのenvironmentを組み合わせて次のactionを決定する。つまり自然言語の手順そのものがruntimeでinterpretされる。

この方式の強みは、自動化の初期コストを下げやすいことにある。従来なら、人間向け手順書を読んで要件を抽出し、分岐や例外をプログラムへ翻訳する必要があった。LLM agentでは、手順書を直接解釈させられるため、その翻訳工程の一部を実行時へ移せる。

OpenAIのagent構築ガイドも、既存のoperating procedure、support script、policy documentなどをagent instructionsへ変換する考え方を示している。またtoolについてはAPIを基本としつつ、APIを持たないlegacy systemではcomputer-use modelで人間向けUIを操作する構成を挙げている。ここでも「SOPの解釈」と「GUIを使うかAPIを使うか」は別問題である。

一方、この方式は同じ処理を繰り返すたびにLLMへ判断を委ねる。これは柔軟性の源でもあるが、同じ手順に対して毎回推論コストと確率的な挙動が発生するという意味でもある。ReUseItの事前評価では、同じ高水準planや過去の成功traceを与えてもweb agentの反復実行は完全には安定しなかった。したがって「人間向けSOPがあるから、そのままagentに読ませれば自動化は完成する」とまでは言えない。

この方式は、特に頻度が低い、例外が多い、手順変更が多い、あるいは自動化対象のAPIが整備されていない仕事では魅力的である。一方、高頻度で安定した処理では、SOPの解釈結果をworkflowやcodeへ固定できないか、という次の問いが出てくる。これはAgentの実行履歴から再利用可能なworkflowを抽出するやWebwrightはBrowser Agentの成果物を「セッション」から「コード」へ移したにつながる。

出典

• Mandar Kulkarni, “Agent-S: LLM Agentic workflow to automate Standard Operating Procedures”, 2025: https://arxiv.org/abs/2503.15520
• OpenAI, “A practical guide to building agents”: https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf
• Yimeng Liu et al., “ReUseIt: Synthesizing Reusable AI Agent Workflows for Web Automation”, 2025: https://arxiv.org/abs/2510.14308