タラバガニー設計局stalins.clubNOTE/notes/gui-versus-programmatic-interface-is-an-orthogonal-axis
AIgui-versus-programmatic-interface-is-an-orthogonal-axis

GUI対APIは、Agent対Programとは別の軸である

AI自動化の議論では「Computer Use / Browser Use」と「API / programmatic automation」が対立概念として扱われやすい。しかし、これは二つの異なる選択を混ぜている。

一つは実行インターフェースの選択である。GUI、DOM、CLI、API、MCP、WebMCPなど、対象システムへどうactionを伝えるか。

もう一つは実行時に誰がprocedureを決めるかである。LLMが毎回状態を見て次のactionを決めるのか、それとも事前に構築されたprogram/workflowが実行されるのか。

Playwright scriptはbrowserを操作するのでGUI/web automation側に見えるが、通常の実行時にはLLMを必要としない。逆に、API toolしか使わないagentでも、毎stepでLLMが次のtool callを選ぶならruntime reasoning型である。この二軸は直交する。

2026年の「GUI vs. CLI: Execution Bottlenecks in Screen-Only and Skill-Mediated Computer-Use Agents」は、この区別を考えるうえで興味深い。440 desktop taskを同じgoal・state・verifierで比較したところ、最強GUI agentは59.1%、original-skill CLI agentは48.2%だった。しかしverifier-guided skill augmentationでCLI側のtool coverageを補うと69.3%まで上がった。著者らはGUI側の主なbottleneckをlong-horizonでのreliable grounded interaction、CLI側をskill coverageと整理している。

これは「GUIは本質的に弱い」ことを意味しない。むしろGUIには、人間が操作可能なsoftwareなら特別なintegrationなしでも使えるという非常に大きなcoverage advantageがある。programmatic interfaceは速く安定していても、必要なcapabilityがtoolとして露出していなければ実行できない。

Microsoft ResearchのWebwrightも同じ結論に近い。codeをaction spaceにするとrobustness・efficiency・reuseが得られる一方、low-level click/type/scrollは人間が操作できる環境なら広く利用できるため、high-level abstractionが使えないときのfallbackとして価値があるとしている。

したがって、設計判断は次のように分けるべきである。

  • procedure acquisition: SOP、人間のdemonstration、agent explorationのどれで手順を得るか
  • procedure persistence: 毎回再推論するか、workflow memoryにするか、programへ固定するか
  • execution interface: GUI、DOM、typed tool、API、CLIのどれを使うか

この整理をすると「Browser Useを使うならprogramは不要」「APIがあるならagentは不要」という二択が消える。agentがBrowser Useで未知systemを探索し、そこからPlaywright programを作ることもできるし、固定workflowの一部だけをComputer Use fallbackへ落とすこともできる。

このinterface側の進化としてWebMCPとTyped Actionは、人間向けUIの上にAgent向け意味層を足すがあり、procedure persistence側の進化としてAgentの実行履歴から再利用可能なworkflowを抽出するとWebwrightはBrowser Agentの成果物を「セッション」から「コード」へ移したがある。

出典

🔗 リンクされているノート

▸ ノート一覧に戻る