AIエージェントの自動操作のイメージを掴むために、以下のインタラクティブデモをご覧ください。物流TMS（配送管理システム）の複雑な操作をAIエージェントが自動で行う様子を、チャット画面・エージェントのワークフロー・TMS画面の3画面同時に再現しています。エージェントがブラウザ経由でTMSのUIを操作し、配送データの変更・車両の再割当・ステータス更新を自律的に実行できます。
AIエージェントがWebブラウザを操作する方法は、大きく分けて3つあります。「スクリーンショット（視覚）ベース」「DOM／アクセシビリティツリーベース」「Playwright等の自動化フレームワーク経由」です。それぞれ原理が異なり、トークンコスト・速度・汎用性にも明確な違いがあります。
図1：ブラウザ制御の3つのアプローチとデータフロー
Anthropic社が2024年10月に発表したComputer Useは、この方式の代表例です。仕組みはシンプルで、まずスクリーンショットを撮影し、視覚言語モデル（VLM）が画像を解析してボタンやテキストフィールドの位置をピクセル座標として特定し、そこに対してマウスクリックやキーボード入力を実行します。「スクリーンショット→解析→アクション→スクリーンショット」というループを繰り返すことで、人間がマウスとキーボードで操作するのとほぼ同じことをAIが行います。
この方式の最大の利点は「汎用性」です。画面に表示されるものなら何でも操作対象になるため、ブラウザに限らず、デスクトップアプリやリモートデスクトップ越しのレガシーシステムすら操作可能です。一方で欠点も明確で、スクリーンショット画像の処理は大量のトークンを消費し、座標の推定精度にも限界があるため、動作が遅く、小さなボタンのクリックを外すこともあります。
Microsoftが2025年2月にリリースしたOmniParser V2は、この方式をさらに洗練させたものです。YOLOv8ベースの検出モジュールがUIのインタラクティブ要素（ボタン・アイコン・メニュー等）を特定し、Florence-2モデルが各要素に説明ラベルを付与します。このパイプラインをLLMの前段に挟むことで、モデル自身が画面全体を解析する負荷を軽減しつつ、座標精度を高めています。
スクリーンショット方式のトークンコスト問題を大幅に解決するのが、DOM（Document Object Model）やアクセシビリティツリーを利用する方法です。ブラウザは本来、スクリーンリーダーなどの支援技術のために、ページ上のすべての要素を構造化データとして提供しています。このアクセシビリティツリーには、各要素の種類（ボタン、入力欄、リンク等）、表示テキスト、状態（有効／無効）などが含まれており、AIエージェントが操作対象を理解するのに最適な情報源です。
たとえばClaude in Chromeは、Chrome拡張機能を通じてページのアクセシビリティツリーを取得し、各要素にref_1、ref_2のような参照IDを割り当てます。LLMはこの構造化テキストを読み取り、「ref_5のボタンをクリックする」といった形で操作を指示します。スクリーンショットが1ページあたり数万トークンを消費するのに対し、アクセシビリティツリーは約800〜2,000トークンで同じページを表現できます。つまりトークン効率が10〜50倍も高く、処理速度もレスポンスも格段に速くなります。
ただし、この方式はブラウザ内のWeb要素に限定されるため、画像内のテキストやCanvas描画のような非構造的要素は認識できません。そのため、実際のプロダクトではアクセシビリティツリーを主軸としつつ、必要に応じてスクリーンショットを補助的に使う「ハイブリッド方式」が主流になりつつあります。
Playwrightは、Microsoftが開発したブラウザ自動化フレームワークで、Chrome DevTools Protocol（CDP）を通じてブラウザをプログラム的に制御します。従来はE2Eテスト用途が中心でしたが、2025年3月にMicrosoft公式の「Playwright MCP」がリリースされたことで、AIエージェントとの統合が一気に進みました。
Playwright MCPは、ページのアクセシビリティツリーをMCPツールとして提供し、LLMがbrowser_clickやbrowser_typeといったアクションを呼び出せるようにします。OpenClawのようなフレームワークもPlaywrightをCDP制御エンジンとして内部的に利用しており、独立したChromiumインスタンスの起動、既存Chromeタブへの接続、リモートCDPサーバーへの接続という3つのモードを提供しています。
一方、Browser-Useのように、Playwrightの中間レイヤーを介さず直接CDPと通信するプロジェクトも登場しています。Playwrightは要素の可視性チェックのために多数のCDP呼び出しを行うため、それが不要な場合は直接CDP通信の方がレイテンシが低いというトレードオフがあります。
ブラウザの外に目を向けると、AIエージェントがExcel、Word、PowerPointなどのデスクトップアプリケーションを制御する方法も多岐にわたります。
最も安定していてAIエージェントと相性が良いのが、アプリケーション本体を起動せずにファイルを直接読み書きするアプローチです。Pythonエコシステムには、openpyxl（Excel）、python-pptx（PowerPoint）、python-docx（Word）という3大ライブラリがあり、これらを使えばOfficeアプリのインストールすら不要です。
この方式はサーバー環境やLinux上でも動作するため、AIエージェントのサンドボックス内で安全に実行できます。Claude Codeのスキルシステムがまさにこのアプローチを採用しており、ユーザーから「Excelで売上レポートを作って」と頼まれると、エージェントがPythonスクリプトを生成・実行して.xlsxファイルを生成します。アプリケーションのGUIを操作する不確実性がなく、確定的にファイルを生成できるのが最大の強みです。
Windows環境では、COM（Component Object Model）インターフェースを通じて起動中のアプリケーションを外部からプログラム的に操作できます。たとえばwin32comライブラリを使えば、PythonからExcelの特定のセルに値を入力したり、Outlookでメールを送信したりすることが可能です。COM経由の操作はアプリケーションのネイティブAPIを叩くため、GUIを操作するよりも遥かに信頼性が高く、高速です。
ただし、COMはWindows固有の技術であり、実行環境にアプリケーション本体がインストールされている必要があります。また、COMオブジェクトの管理にはメモリリークなど特有の落とし穴もあるため、エージェントが長時間にわたって大量のCOM操作を行う場合には注意が必要です。
ブラウザでアクセシビリティツリーが有効だったように、デスクトップアプリにもアクセシビリティAPIが存在します。WindowsのUI Automation（UIA）、macOSのNSAccessibility、LinuxのATK／AT-SPIがそれぞれのプラットフォームで提供されており、画面上のすべてのUI要素を構造化データとして取得し、操作することができます。
この技術はもともとスクリーンリーダー向けに設計されたものですが、AIエージェントにとっても非常に有用です。アプリケーションの内部APIを知らなくても、表示されているメニューやボタンを「見つけてクリックする」ことができるからです。クロスプラットフォーム対応のAppiumなどのツールは、これらのAPIを統一的に扱うフレームワークを提供しています。
AIエージェントにとって最も基礎的で強力なOS操作インターフェースは、シェル（bash/zsh等）とファイルシステムです。LLMは膨大なコードとCLIコマンドのデータで学習しているため、ディレクトリの移動、ファイルの検索、テキスト処理といったシェル操作を非常に高い精度で実行できます。
2025年にVercelのエンジニアが示した事例では、複雑なAPI統合をすべて排除し、ファイルシステムとbashだけでエージェントを構築したところ、タスクあたりのコストが75%削減され、出力品質も向上したと報告されています。これは「LLMはコードのためのファイル操作が得意なのだから、あらゆるタスクをファイル操作に帰着させれば良い」という発想の転換です。
セキュリティ面では、シェルコマンドの許可リスト／拒否リストにより、エージェントが実行可能なコマンドを細かく制御できます。たとえばrm -rf /のような破壊的コマンドを事前にブロックしたり、ネットワークアクセスを特定のドメインに限定したりすることが可能です。
macOS環境に特化した操作手段として、AppleScriptとJXA（JavaScript for Automation）があります。macOSのOpen Scripting Architecture（OSA）に基づくこれらの言語は、Finder、Safari、Mail、Pages、Keynoteなどほぼすべてのネイティブアプリを外部から制御できます。
2025年には、macos_automatorというMCPサーバーが登場し、AIエージェントがAppleScriptやJXAスクリプトを実行して200以上の事前定義された自動化シーケンスにアクセスできるようになりました。たとえば「Finderで特定フォルダのファイルを日付順に整理する」「Safariで開いているすべてのタブのURLをテキストファイルに保存する」といった操作を、自然言語の指示から自動的に変換して実行できます。
ただしJXAはAppleによる開発が事実上停止しており、ドキュメントも不完全なため、AIモデルが生成するスクリプトの品質にはばらつきがあります。実運用では、事前にテスト済みのスクリプトテンプレートとLLMによる動的パラメータ挿入を組み合わせるハイブリッド手法が推奨されます。
ここまで見てきたように、ブラウザはCDP、デスクトップアプリはCOMやアクセシビリティAPI、OSはシェルやAppleScriptと、操作対象ごとにまったく異なるプロトコルが使われています。この断片化を解決する統合レイヤーとして急速に普及したのが、Anthropicが2024年11月に公開したModel Context Protocol（MCP）です。
図2：MCPによる統一インターフェース
MCPは「AIのためのUSB-C」と呼ばれ、各MCPサーバーがCDP、COM、ファイルシステムAPI等の低レベルプロトコルを吸収し、LLMには統一的なツール定義（名前・パラメータ・説明）を提示します。2025年3月にOpenAIがChatGPTにMCPを統合、11月にはAnthropicがMCPをLinux Foundation傘下のAAIFに寄贈し、12月にはMicrosoftがWindows自体にMCPサポートを組み込みました。規格戦争としては圧勝と言えます。
MCPが解決する問題は、REST APIやGraphQLとは根本的に異なります。REST/GraphQLは「人間の開発者が設計した明示的なエンドポイント」にリクエストを送る構造です。開発者がURLとパラメータを知っていることが前提であり、APIの発見（どんなエンドポイントがあるか）はOpenAPIドキュメントで行います。一方MCPは、「LLMが自律的にツールを選択し、パラメータを推論して呼び出す」ことを前提に設計されています。ツール定義にはLLMが理解しやすい自然言語の説明が付与され、LLMはそれを読んで文脈に応じたツールを選ぶのです。
CDPやCOMのような低レベルプロトコルとの違いも明確です。CDPは「ブラウザの全機能にプログラム的にアクセスするためのプロトコル」で、メモリプロファイリングやネットワークインターセプトまで可能な極めて高機能なインターフェースです。MCPはこうした低レベル機能を直接提供するのではなく、それらを「ツール」として抽象化しLLMに提示する中間層に過ぎません。つまりMCPはCDPの代替ではなく、CDPの上に乗るラッパーです。
しかし2026年に入り、MCPの構造的な弱点が次々と表面化しています。最も深刻なのは「トークンオーバーヘッド」です。MCPではすべてのツール定義（名前、パラメータスキーマ、説明文）がLLMのコンテキストウィンドウに展開されます。ある開発チームの報告では、20万トークンのコンテキストのうち14.3万トークン（72%）がツール定義だけで消費され、実際のクエリ処理に使えるコンテキストがほとんど残らなかったという事例があります。MCPサーバーを多数接続するパワーユーザーでは、メタデータだけで2万トークン以上が消費されます。実務的には接続するMCPサーバーは10〜15個が限界とされており、「あらゆるツールを繋げる」というMCPの理想は現実には制約を受けています。
レイテンシの問題も看過できません。MCPはステートフルなSSE（Server-Sent Events）接続を前提としており、LLMがツール呼び出しを決定→MCPレイヤーがリクエストを構造化→サーバーが処理→結果を返却という多段階の処理が毎回発生します。ベンチマークによると、同等のタスクをCLI直接実行した場合と比べてトークン効率が33%低いという結果も出ています。またSSEのステートフル接続は水平スケーリングやロードバランサーとの相性が悪く、サーバーレスアーキテクチャとは本質的に非互換です。
mcp-remoteパッケージにはCVSS 9.6のOAuth脆弱性（CVE-2025-6514）が発見され、43.7万ダウンロードに影響しました。MCPのnpmパッケージにバックドアを仕込み、メール送信を傍受するサプライチェーン攻撃も確認されています。RSAカンファレンスにおけるMCP関連の投稿の96%以上がリスク・セキュリティに焦点を当てており、機会を強調するものは4%未満にとどまっています。
2026年に入り、MCPに対する業界の空気は明らかに変化しています。Y Combinator代表のGarry Tan氏はSNS上で率直に否定的な評価を表明し、PerplexityのCTOも初期の採用から距離を置きつつあると報じられています。開発者コミュニティでは「MCP Won. MCP Might Also Be Dead.」（MCPは勝った。だがMCPは死んだかもしれない）という記事が広く共有され、規格戦争に勝利した後の実用上の壁が議論されています。
批判の核心は「MCPは多くのユースケースで過剰な抽象化」という点に集約されます。LLMの能力向上により、OpenAPI仕様を直接読み取ってAPIを呼び出す方が、MCPの中間層を経由するよりもシンプルで効率的なケースが増えています。ある開発者は「開発者はOpenAPIを書き、MCPに乗り換え、LLMがOpenAPIを直接扱えるようになったので今度はMCPからOpenAPIの仕様を生成している——完全に一周した」と皮肉を述べています。エンタープライズ向けの本番運用は依然として少なく、構成の非ポータビリティ（クライアント間でMCP設定を共有できない）、標準的な監査ログの欠如、OAuthフローの未成熟など、本番環境で求められる要件が不足しています。
とはいえ、MCPがもたらした「AIモデルとツールの接続を標準化する」という概念自体の価値は否定しがたく、2025年11月の仕様改訂で多くの課題が改善されつつあります。MCPは完璧ではないものの、現時点で最も広く採用されたAIツール統合プロトコルであることは事実です。問題は、MCPのビジョンと現実のギャップがどこまで許容されるか、そしてそのギャップが埋まるスピードが実用化の要求に間に合うかどうかです。
ここまで紹介した技術が実際のAgent SDKでどう組み合わされているかを、主要なフレームワークで比較します。
| 観点 | OpenClaw | Claude Code | OpenAI Agents SDK | AutoGen / Magentic-One |
|---|---|---|---|---|
| ブラウザ制御 | Playwright/CDPベース。3モード（拡張機能リレー・管理済みChromium・リモートCDP） | Claude in Chrome拡張でアクセシビリティツリー取得。スクリーンショット補助。Playwright MCPも併用可 | ブラウザ制御は限定的。Web検索ツールが主。Computer Use機能は開発中 | WebSurferエージェントがChromiumを制御。アクセシビリティツリー＋Set-of-marks方式 |
| デスクトップ | スクリーンショット＋座標指定のComputer Use方式 | Pythonライブラリ（openpyxl等）でファイル直接生成。Computer Use APIも利用可 | Python/TypeScript関数ツールとして任意の操作をラップ | FileSurferでファイル閲覧、ComputerTerminalでシェル操作。フル画面操作は非対応 |
| OS操作 | シェル実行＋ファイルシステム。Docker隔離 | サンドボックスLinuxシェル。許可リスト制ネットワーク。macOSではAppleScript | Python関数経由でシステムコマンド実行可 | Coderエージェント＋ComputerTerminalでプログラム実行・ライブラリインストール |
| 拡張モデル | Skills/プラグイン＋MCP | MCP（6,150+サーバー）＋スキル＋フック | 関数ツール＋ガードレール＋ハンドオフ | マルチエージェント構成（専門エージェントのチーム編成） |
| 設計思想 | ローカルファースト汎用エージェント。メッセージアプリ連携重視 | 開発者向けコーディングエージェント。ファイル操作基盤 | 最小限の抽象化。軽量オーケストレーション | マルチエージェント分業。Orchestratorが動的計画修正 |
注目すべきは、各フレームワークが「同じ問題に対して根本的に異なるアプローチ」を採っていることです。OpenClawはハブ＆スポーク型でメッセージングプラットフォームから制御する設計思想。Claude Codeはファイル操作とコード実行を基盤にし、必要に応じてブラウザ機能を追加するモジュラー設計。OpenAI Agents SDKは最小限の抽象化で関数ツールとガードレールを組み合わせる軽量アプローチ。AutoGen/Magentic-Oneは、単一エージェントに全能力を持たせるのではなく、ブラウザ担当・ファイル担当・コード担当の専門エージェントをチームとして協調させるマルチエージェントアプローチです。
Google ADK（Agent Development Kit）やLangChain/LangGraphも重要なプレイヤーですが、これらはブラウザやOS操作自体よりも、エージェントのオーケストレーション層に注力しています。Google ADKはWorkflow Agentという「LLMの判断を介さない決定的なフロー制御」を提供し、LangGraphはグラフベースのランタイムでノード間のデータフローを精密に管理します。これらは「何を操作するか」ではなく「どう協調するか」に特化したフレームワークであり、上述のブラウザ/OS操作フレームワークと組み合わせて使われるケースが増えています。
私たちBlack AIは、本記事で紹介したブラウザ・ソフトウェア・OS横断のエージェント制御技術に全力で取り組んでいます。その成果がAI PC Workerです。従来のRPAはUI要素のセレクタ指定やフロー定義に膨大な開発工数がかかり、画面変更のたびにメンテナンスが必要でした。AI PC Workerは、LLMによる画面理解とDOM/Accessibility API操作を組み合わせることで、こうした制約を根本から解消し、従来のRPAと比較して大幅に高性能かつ柔軟なERP自動操作を実現します。
冒頭のデモのように、自然言語で指示するだけでTMSの配車最適化・一括更新・関係者通知まで一気通貫で完了する——そんな業務自動化に興味をお持ちでしたら、ぜひお気軽にご連絡ください。