AI自動化の実行パラダイムを分解する
AIによる業務自動化を「Browser UseかAPIか」だけで整理すると、本質的に異なる問題が一つの軸に潰れてしまう。少なくとも次の三つを分けて考える必要がある。
- 手順を誰が作るか — 人間がSOPを書くのか、AIが環境を探索して手順を発見するのか。
- 推論をいつ行うか — 実行のたびにLLMが判断するのか、構築・修復時だけLLMを使い通常時は固定されたプログラムを実行するのか。
- 何を通じて実行するか — GUI、DOM、WebMCP、MCP/API、CLIなど、対象システムとのインターフェースは何か。
この三軸は直交する。Playwrightプログラムはブラウザを操作するが、実行時にLLMがクリックを逐次判断するBrowser Agentとは異なる。反対に、APIを使っていても毎回LLMが計画を立てるなら、実行時推論型である。
このシリーズでは、次の論点を分けて扱う。
- 自然言語SOPを実行時プログラムとして使う — 自然言語SOPをLLMが毎回解釈する方式
- Browser Agentは「その場限りの手順」を生成している — Browser Agentを「その場限りの手順生成」と見る
- Agentの実行履歴から再利用可能なworkflowを抽出する — 実行履歴からworkflowを抽出して再利用する研究
- WebwrightはBrowser Agentの成果物を「セッション」から「コード」へ移した — 探索結果をコードとして固定するWebwright
- Programming by DemonstrationからAgent Workflowへ — RPA/PbDからLLM agentへの系譜
- GUI対APIは、Agent対Programとは別の軸である — GUI/API論争と実行パラダイムを分離する
- 長時間のComputer Useでは、クリックより状態管理と検証が難しくなる — 長時間タスクではクリック以外がボトルネックになる
- WebMCPとTyped Actionは、人間向けUIの上にAgent向け意味層を足す — 人間向けUIとagent向けsemantic actionの共存
- Agentic Automationが自分自身を固定workflowへ「コンパイル」する設計 — agentic executionを固定化していく設計仮説
重要なのは、「AIが仕事をする」という表現には少なくとも二つの意味があることだ。一つはAIを作業員として実行時ループに置くこと、もう一つはAIを自動化エンジニアとして探索・実装・修復に使うことである。両者は競合するだけでなく、前者から後者へ移行する構成も考えられる。