Microsoftが徹底比較：AIエージェントの未来を左右するAPI型 vs GUI型 – あなたの業務に最適なのは？

大規模言語モデル（LLM）は、もはや単なるテキスト生成ツールではない。私たちの命令を理解し、ソフトウェア上で具体的なタスクを実行する「エージェント」へと進化を遂げようとしている。この新たな潮流の中で、Microsoftの研究者たちが、AIエージェントの二つの主要なアプローチ、「APIベース」と「GUIベース」について、その根本的な違い、それぞれの長所と短所、そして融合の可能性までを深く掘り下げた包括的な比較研究を発表している。

LLMエージェントの夜明け：二つの潮流が拓く自動化の新時代

LLMは近年、目覚ましい進化を遂げ、自然言語理解と生成能力において驚異的な性能を示している。しかし、そのポテンシャルはテキスト処理に留まらない。研究者たちはLLMを「思考するエンジン」として活用し、デジタル環境で具体的なアクションを実行できるソフトウェアエージェントの開発へと舵を切った。これらのエージェントは、ユーザーの自然言語による指示に基づき、様々なソフトウェアシステムと対話し、コマンドを実行することで、私たちの業務効率を飛躍的に向上させる可能性を秘めている。

このLLM駆動型タスク自動化の分野において、現在、大きく分けて二つの異なるパラダイムが注目されている。一つは、プログラムによって明確に定義されたインターフェースを通じて外部ツールやサービスと連携する「API（Application Programming Interface）ベースのエージェント」。もう一つは、人間が操作するのと同じように、グラフィカルユーザーインターフェース（GUI）を「見て」操作する「GUIベースのエージェント」である。両者はタスク自動化という共通の目標を持ちながらも、そのアーキテクチャの複雑性、開発ワークフロー、そしてユーザーとのインタラクションモデルにおいて、顕著な違いを見せている。

APIエージェント：ソフトウェアの「裏口」を知る効率的な仕事人

APIベースのLLMエージェントは、ソフトウェアやサービスが外部連携のために提供しているAPIを利用してタスクを実行する。APIとは、いわばソフトウェア間の「約束事」であり、特定の機能を呼び出すための手順やデータの形式が明確に定義されている。

例えば、MicrosoftのCopilotのような製品は、APIベースのエージェントがどのように実用化されているかを示す好例だ。これらのエージェントは、マイクロサービスを連携させたり、検索エンジンに問い合わせたり、あるいはサードパーティアプリケーションをAPI経由で制御したりといったタスクを、自動的かつ効率的に実行できる。学術界および産業界双方におけるAPIベースエージェントへの関心の高さは、堅牢なスケーラビリティと相互運用性を維持しつつ、自動化を通じてタスクを合理化する能力を明確に示していると言えるだろう。

研究論文で示された図（Figure 1）を例に取れば、「3月8日午後4時にGoogleカレンダーにLLMエージェントに関する1時間の会議をスケジュールする」というタスクをAPIベースのエージェントに依頼した場合、適切なエンドポイントと認証情報があれば、単一のAPIコールを発行するだけで、即座にイベントを作成できる。これは、APIが提供する直接的かつ効率的な連携の賜物だ。

APIエージェントの能力は、あらかじめ定義されたツール、プラグイン、または関数呼び出し（これらを総称して「API」と呼ぶ）のセットによって規定される（Figure 2参照）。

この制約された関数セットは、信頼性と安全性を確保するだけでなく、エージェントの意思決定空間を単純化する。エージェントは完全なプログラムコードを生成するのではなく、各ステップでどのAPIを呼び出すかを特定し、ユーザーの意図に基づいて必要なパラメータを設定する。

GUIエージェント：人間のように画面を「見て」操作する実直なアシスタント

一方、GUIベースのLLMエージェントは、APIのようなプログラム的な接点ではなく、ソフトウェアのグラフィカルユーザーインターフェースを直接操作することでタスクを実行する。これは、人間がマウスやキーボードを使ってアプリケーションを操作するのと非常によく似たアプローチだ。

マルチモーダルLLM研究の進展に伴い、このGUIベースのエージェントという新しいクラスが登場してきた。これらのエージェントは、APIを通じて対話するだけでなく、デスクトップ、モバイル、ウェブアプリケーションなど、ソフトウェアのGUIを「観察」し、操作することによってもタスクを実行する。UFOやCogAgent、OpenAI Operatorといったプロジェクトは、GUIベースエージェントが、よりリッチなユーザーエクスペリエンス、向上したアクセシビリティ、そしてより汎用的なソフトウェアの自動制御をどのようにもたらしうるかを示している。視覚的または画面ベースの理解とテキストベースの推論を統合することにより、これらのエージェントはヒューマンコンピュータインタラクションの境界を押し広げ、AIが直感的で視覚的なワークフローとシームレスに融合する方法を提示している。

先のGoogleカレンダーの例で言えば、GUIベースのエージェントは、まずWebブラウザでGoogleカレンダーを開き、カレンダー画面を視覚的に認識し、目的の日時を探し、イベント作成ボタンをクリックし、表示されたフォームに関連情報を入力し、最後に保存ボタンをクリックする、といった一連の操作を人間のように行うだろう。

GUIベースのエージェントは主に、アプリケーションのスクリーンショットやアクセシビリティツリー（UI要素の階層構造データ）、メタデータといった視覚的またはマルチモーダルな入力に依存する。APIエンドポイントを呼び出す代わりに、マウスのクリックやキーボード入力といった人間のインタラクションに類似したアクションを使用して、画面上の要素をナビゲートし、操作する（Figure 2参照）。この「人間らしい」操作フローは、エージェントが視覚的なレイアウトを解釈し、関連するコントロールを特定し、タスクを達成するためにクリック、ドラッグ、またはキー入力のシーケンスを実行する必要があることを意味する。

徹底比較：APIエージェント vs GUIエージェント – Microsoftが示す9つの視点

これら二つのパラダイムは、タスク自動化という共通の目標を持ちながらも、その特性において大きく異なる。Microsoftの研究者たちは、両者を9つの重要な側面から比較し、その違いとそれぞれの強み、弱みを明らかにした。

観点	APIエージェント	GUIエージェント
モダリティ（入力形式）	テキストベースのAPI呼び出しに依存	スクリーンショットやアクセシビリティツリーに依存
信頼性	定義済みのエンドポイントにより一般に高い信頼性を持つ	視覚解析やレイアウト変更により信頼性が低下しやすい
効率性	単一の呼び出しで複雑なタスクを実行可能	ユーザーの操作を模倣した複数のステップが必要
利用可能性	公開済みまたは事前定義されたAPIに限定される	画面上のあらゆるUI要素に対して動作可能
柔軟性	既存のAPIに制限される	未公開機能にも対応可能な高い柔軟性を持つ
セキュリティ	エンドポイントごとの細かな制御が可能	広範なUIアクセスによりリスクが増大
保守性	APIがバージョン管理されていれば安定的	UIの変更により動作が破損しやすい
透明性	バックエンド主導で不可視になりがち	逐次的かつ視覚的に追跡可能
人間らしい操作性	完全にプログラム的	画面上でユーザー操作を模倣

これらの比較から、APIエージェントは効率性、信頼性、セキュリティに優れる一方、利用可能なAPIに機能が限定されるという側面があり、GUIエージェントは広範なアプリケーションへの適用可能性とユーザーライクな操作性を持つものの、UI変更への脆弱性や効率性の課題を抱えていることがわかる。ソフトウェアエコシステムの複雑性が増す中で、これらの異なる特性を理解することは、最適なアプローチを選択したり、両者の長所を組み合わせたハイブリッドソリューションを設計したりする上で不可欠だ。

単独ではない未来図：APIとGUIの融合 – ハイブリッドアプローチの夜明け

APIベースとGUIベースのエージェントは伝統的に別々のパラダイムとして研究されてきたが、その概念的基盤は相互に排他的なものではない。実際には、これらのアプローチが交差したり補完し合ったりするシナリオは数多く存在し、それが「ハイブリッド」モデルの登場を促している。APIとGUI双方の強みを活かすことで、このハイブリッドアプローチは、より広範なユースケースへの対応、より高い効率性、そしてより人間らしいインタラクションスタイルを実現できる可能性がある。まだ初期段階にあるものの、これらの融合型ソリューションがエージェントの動作方法を再構築する可能性はますます明らかになっている。

Microsoftの研究では、この融合に向けた具体的な戦略として、以下の3つのアプローチが提示されている。

GUIワークフロー上のAPIラッパー（API Wrappers Over GUI Workflow）:
一部のベンダーは、GUIベースのアプリケーションに「ヘッドレスモード」や関数呼び出しを受け付けるスクリプティングインターフェースを導入することで、擬似的なAPIサービスへと転換している。これにより、元来人間による操作を前提としていたアプリケーションを、よりプログラム的かつスケーラブルな方法で自動化できるようになる。例えば、会計アプリケーションが従来、複数のダイアログボックスやメニュー操作を必要としていた財務レポート作成機能を、GenerateReport(startDate, endDate)のような関数として公開するケースだ（Figure 3参照）。
内部的にはGUI操作に依存しているものの、開発者にはAPIのようなインターフェースを提供することで、より広範な自動化パイプラインへの統合を簡素化する。これは、GUI自動化と構造化されたAPIライクなインターフェースを橋渡しする、微妙だが影響力のある融合形態と言えるだろう。

統合オーケストレーションツール（Unified Orchestration Tools）:
エンタープライズグレードの自動化フレームワークやプロセスオーケストレーションツールは、開発者やオペレーターが基盤となるエージェントのメカニズムを深く理解することなく、高レベルのワークフローを構築できる単一の統合環境を提供するようになっている。例えば、金融機関が融資承認プロセスを自動化するケースを考えてみよう。オーケストレーションツール内で、ユーザーはまず安全なAPIエンドポイントを使用して顧客の信用スコアを確認し、次に信用スコアが特定の閾値を満たせば顧客関係管理（CRM）システムを更新する、というフローチャートを設計できる。もしCRMシステムを更新するための適切なAPIが存在しない場合、プラットフォームはシームレスにGUIベースのエージェントに切り替わり、CRMのウェブインターフェースを人間のように操作してタスクを完了する（Figure 4参照）。Microsoftの実験的なツールであるUFO（Zhang et al., 2024b）は、この設計を具現化しており、各アプリケーションが専用APIを統合できるインターフェースを提供し、可能な限りAPIの使用を優先する。しかし、適切なAPIが存在しない場合は、システムはシームレスにGUIベースのインタラクションにフォールバックする。

ローコード／ノーコードソリューション（Low-Code / No-Code Solutions）:
ローコード／ノーコードプラットフォームは、多くの技術的詳細を視覚的なインターフェースの背後に抽象化し、「市民開発者」とも呼ばれる非専門家がドラッグアンドドロップコンポーネントを通じてアプリケーションや自動化を構築できるようにする。例えば、注文処理ワークフローでは、ユーザーは「支払いゲートウェイ」ブロックをデザイナーにドラッグして取引を処理し、視覚的に設定する。その裏では、APIエージェントが自動的に支払いエンドポイントへの呼び出しを構築・送信する。次に、それを「配送サービス」ブロックに接続してフルフィルメントを行う（Figure 5参照）。プラットフォームは通常、支払いと配送サービスへのAPIコールを発行し、ユーザーは低レベルのプロトコルではなくワークフローの論理シーケンスに集中できる。逆に、特定のステップでGUIベースの検証（例えば、レガシーシステムの特定のUI要素の確認）が必要な場合、プラットフォームはシームレスにGUIエージェントを挿入し、ソフトウェアとの人間のインタラクションをシミュレートできる。

これらの戦略は、かつては明確だったAPIベースとGUIベースのエージェント間の境界が徐々に曖昧になっていることを示している。ハイブリッドアプローチは、GUI駆動インターフェースの柔軟性と普遍性を、ダイレクトなAPIコールの信頼性とパフォーマンスと共に活用する。この融合により、迅速なデータ処理から複雑なユーザーインターフェース検証まで、多様なシナリオに対応する、より包括的な自動化が可能になる。

実践的な選択：あなたの業務に最適なエージェントは？ – Microsoftが示す指針

アーキテクチャ、信頼性、効率性、そして融合の可能性といった側面からAPIベースとGUIベースのLLMエージェントを比較してきたが、多くの実務的な導入においては、「実際の状況下でどちらのパラダイムを採用すべきか？」という、より根本的な問いが重要となる。Microsoftの研究は、この問いに答えるための具体的な指針も示している。

APIエージェントを優先すべきシナリオ:

安定し、十分に文書化されたAPIが存在する場合: 公式で安定したAPIは通常、厳格なドキュメンテーションとバージョニングが伴い、強力なエラーハンドリングと一貫したパフォーマンスを可能にする。このような環境では、APIコールの固有の速度と信頼性を活用してタスクを効率的に実行し、システムオーバーヘッドとレイテンシを最小限に抑えることができる。
パフォーマンスが重要なオペレーション: バックエンド統合やミッションクリティカルなワークフローのように、エンタープライズレベルの信頼性が最優先される場合に特に推奨される。ダイレクトな関数呼び出しにより、レイテンシとオーバーヘッドを削減できる。
アプリケーションへのアクセス制御が求められる場合: 安全性とセキュリティが最優先されるエージェントベースのシステムにおいて、これは重要な考慮事項だ。APIエージェントは、そのアクションが制約された操作セットに限定されるため、予測可能で安全なインタラクションを保証するのに理想的だ。

GUIエージェントを優先すべきシナリオ:

利用可能なAPIが存在しない、または不完全な場合: 特にモバイルアプリケーションでは、各アプリが隔離された環境として動作し、外部APIアクセスを制限していることが多いため、この状況が顕著だ。また、モバイルデバイスでのシステムレベルの操作はルートアクセスを必要とすることが多く、APIのユーザビリティをさらに制限し、GUIベースの自動化を実用的な代替手段として必要とさせる。
視覚的な検証やUIテストが必要な場合: 画面上のテキスト、UI要素の位置、またはインターフェースの一貫性をアクション実行前に確認する必要があるワークフローでは不可欠だ。人間のようにソフトウェアと対話するGUIエージェントは、APIベースのアプローチよりも明確な利点を提供する。
レガシーシステムやプロプライエタリソフトウェアの操作: 拡張可能なバックエンドサービスを欠くこれらのシステムは、GUI駆動の自動化を活用することで、基盤となるコードベースの変更や新しいAPIの開発を必要とせずに既存のインターフェースを操作できる。
インタラクティブまたはグラフィカルな操作が中心のアプリケーション: アニメーションの作成、Photoshopでの描画、複雑なデザインツールの操作といったタスクは、APIコマンドよりも直接的な視覚的インタラクションを通じて実行するのが最適だ。

ハイブリッドアプローチを検討すべきシナリオ:

APIが部分的にしかタスクをカバーしていない場合: タスクのある側面は既存のAPIにうまくマッピングできるが、他のコンポーネントはグラフィカルインターフェースを通じてのみアクセス可能である場合に特に有利だ。データ集約的またはプログラム的に合理化された操作にはAPIベースのエージェントを使用し、専門的なフロントエンドインタラクションや視覚的検証はGUIエージェントが処理することでパフォーマンスを維持する。
将来のシステム進化に備える場合: ハイブリッドソリューションを採用することで、将来のシステム進化に対する柔軟性が得られる。新しいAPIが利用可能になるにつれて、当初GUI経由で管理されていたタスクをシームレスにAPIコールに移行でき、大規模な再設計を回避できる。

結論として、APIベースとGUIベースのエージェントの戦略的な導入は、対象となるソフトウェアの性質、必要な統合や検証のレベル、そして長期的な持続可能性の懸念に依存する。安定し、文書化されたエンドポイントが存在する場合にはAPIエージェントが優れており、信頼性が高く高性能な自動化モードを提供する。インターフェースが唯一のアクセス手段であるか、視覚的確認が不可欠なコンテキストでは、GUIエージェントが有利だ。そして最後に、ハイブリッドアプローチはこれらの強みの間でバランスを取り、組織がソフトウェアエコシステムの進化に合わせて適応できるようにする。これらの要因を考慮することで、意思決定者は特定の要件に最も合致するエージェントパラダイム（API、GUI、またはその両方）を選択できる。

AIエージェントが切り拓く未来

コンピュータにおける自動化は長い歴史を持つが、LLMベースエージェントの出現は、その進化における大きな飛躍を意味する。これらのエージェントは、明確に定義されたプログラムインターフェースを中心とするAPIエージェントと、グラフィカルインターフェースとの人間らしいインタラクションに根ざしたGUIエージェントという、二つのコアパラダイムを体現している。設計上、これらのパラダイムは動作原理が異なり、アーキテクチャの選択、パフォーマンスプロファイル、そして実世界での適用可能性において分岐をもたらす。しかし、それらは補完的な強みも示している。APIエージェントは速度、セキュリティ、信頼性に優れ、GUIエージェントは柔軟性、広範な適用可能性、透明性を提供する。この特性が、両者をハイブリッド化と融合の未来へと向かわせているのだ。

今後の展望として、LLM技術の継続的な成熟は、エージェント開発の両方の流れを強化する可能性が高い。 一方で、ますます高性能化するコーディングアシスタントは、APIの作成と保守を簡素化し、それによってAPIエージェントのスケーラビリティを向上させることが期待される。他方で、強力なマルチモーダルモデルの台頭は、GUIベースエージェントの範囲を拡大し、より堅牢な視覚的理解と洗練されたGUI操作を可能にするだろう。これらのトレンドは、API中心とGUI中心のアプローチがますます織り交ぜられていく進化するエコシステムを示唆している。

将来的には、これらのエージェントタイプのシームレスな統合により、全く新しい形態のソフトウェア、つまり効率的なバックエンド操作のためにAPIを自動的に生成または改良し、透明なフロントエンドインタラクションのためにユーザーインターフェース要素を動的に調整するツールが登場するかもしれない。このパラダイムの合流は、ヒューマンコンピュータインタラクションを変革し、コードによって生成されるものと視覚的インターフェースを通じて経験されるものの間の境界を曖昧にする可能性を秘めている。長期的には、それは私たちがソフトウェア開発、ユーザーエクスペリエンス、そしてデジタルエコシステムを支える広範なワークフローをどのように構想するかを再構築するかもしれない。

今回のMicrosoftの研究は、単に技術的な比較に留まらず、AIエージェントが私たちの働き方やソフトウェアとの関わり方をどう変革しうるかという、より大きな問いを投げかけている。その答えは一つではなく、APIとGUI、そしてそれらを組み合わせたハイブリッドなアプローチの中に、多様な形で存在していくのだろう。

論文

arXiv: API Agents vs. GUI Agents: Divergence and Convergence