AIエージェントの自動化コスト激減、Playwright CLI移行でトークン量70%削減の事例

AIエージェントによるブラウザ操作自動化において、実装方法をわずかに変えるだけで、生成AIの利用コストの大部分を占めるトークン消費量を70%以上も削減できる事例が報告された。これは、特に大規模な業務自動化（RPA）を運用する企業にとっては無視できない効率化だが、小規模なスクリプトや実験段階のプロトタイプでは、移行コストとメリットのバランスを考える必要がある。

MCPからCLIへの切り替えで劇的なトークン削減

X（旧Twitter）上で、ある開発者がバックオフィス業務の自動化について興味深い報告を行った。同氏によれば、Playwrightを用いたAIエージェントの自動化パイプラインを5つ運用しているが、ブラウザ操作の手段をMCP（Model Context Protocol）からCLI（Command Line Interface）へ切り替えた結果、AIへの指示に必要なトークン消費量が70%以上も削減されたという。さらに、ヘッドレスモードでのスナップショット取得とセッション管理の効率化も実現し、処理速度が「爆速になった」としている。

この報告は単独の事例に留まらない。技術情報サイトのQiitaや個人技術ブログによる独立した検証でも、同様の傾向が確認されている。例えば、Qiitaの記事によれば、PlaywrightをAIエージェントで使用する際の「MCP経由」と「CLI経由（agent-browser使用）」を比較したところ、後者の方がトークン効率で明らかに優位であったことが示されている。別の技術ブログの検証でも、CLI方式がコンテキスト長を節約し、結果としてトークン消費を大幅に削減できると結論付けている。

なぜCLIの方がトークン効率が良いのか？

MCPは、AIモデルと外部ツール（ブラウザ、ファイルシステム等）を接続するための標準化プロトコルとして注目を集めている。その利点は、統一されたインターフェースを通じて様々なツールを安全にAIに利用させられる点にある。しかし、この「汎用性」と「安全性」が、時にオーバーヘッドを生む。

ブラウザ操作に特化して考えると、MCPを経由する場合、AIモデルは「Playwrightというツールを使って、特定の操作をせよ」という抽象化された指示と、それに伴うブラウザの状態（DOM、スクリーンショットなど）を大量のコンテキストとして受け取る必要がある。この情報伝達の過程で、操作の本質とは関係のないメタデータや冗長な構造化データが含まれてしまい、結果としてトークン消費量が膨らむ傾向にある。

一方、CLIを直接叩く方式、具体的にはagent-browserのようなツールを用いる方法では、AIエージェントがより直接的に「次にクリックすべき要素のセレクタ」や「ナビゲーションのコマンド」を生成する。このアプローチは、ブラウザの状態をAIに伝える方法を最適化し、必要最小限の情報（例えば、簡潔なHTMLスニペットや構造化された要素情報）に絞り込むことが可能だ。これが、無駄なトークン消費を削ぎ落とし、70%以上という劇的な削減を実現する背景にある。

具体的な効率化のポイント：スナップショットとセッション

報告では、ヘッドレスモードでの「スナップショット」と「セッション管理」の効率化も速度向上の要因として挙げられている。MCPを経由する場合、ブラウザの状態をAIに伝えるための高解像度なスクリーンショットや完全なDOMツリーを頻繁に送信する必要が生じやすい。これが処理遅延とコンテキスト長の圧迫を招く。

CLIベースの最適化されたアプローチでは、必要に応じてページの特定領域のみの簡易スナップショットや、変更のあったDOM部分のみを差分で送信するといった工夫がしやすい。また、ブラウザセッションを効率的に維持・再利用することで、ログイン状態の保持やページ遷移のコストを下げ、全体の処理速度を向上させている。

誰がこの知見を活用すべきか？

この知見が最も価値を持つのは、すでにPlaywrightなどを用いたAIエージェントによる自動化を本番環境で運用し、月々のトークンコストが無視できない規模になっているチームだ。特に、以下のようなシーンでは、MCPからCLIベースの実装へのリファクタリングを検討する価値が高い。

• 定型データ収集パイプライン: 複数のWebサイトから定期的に価格、在庫、ニュース記事を収集するエージェント。
• バックオフィス業務自動化: 社内ポータルへのログイン、経費精算の入力、レポートのダウンロードと整理といった一連の作業。
• E2Eテストの補助: AIに複雑なテストシナリオを実行させ、その過程で動的に操作を判断させるような高度なテスト自動化。

逆に、学習目的や小規模なPoC（概念実証）レベルでの利用、あるいは扱うタスクが極めて単純でトークン消費量自体が少ない場合は、開発の容易さや将来性を考慮してMCPを継続する選択も合理的と言える。標準プロトコルであるMCPのエコシステムの発展は目覚ましく、将来的にはこの効率差が縮まる可能性もある。

実装を切り替える際の考慮点

MCPからCLIベースの実装に移行する場合、単なるツールの差し替えではなく、AIエージェントとブラウザの「会話」の仕組みそのものを設計し直す必要がある。具体的には、AIモデルが出力するアクションの形式（MCPのツール呼び出しJSONから、直接的なCLIコマンドやAPI呼び出しへ）や、ブラウザ状態の観測方法（どの情報を、どの粒度で、どの頻度でAIに提供するか）を一から見直す作業が伴う。

この移行には初期コストがかかるが、一度最適化されたパイプラインを構築できれば、継続的な運用コストの削減と処理速度の向上という形で投資対効果が得られる。現在、agent-browserをはじめとするオープンソースプロジェクトが、このCLIベースのアプローチを実装するための土台を提供しており、参考になる実装例も増えつつある。

代替ツールとの関係

この議論はPlaywrightに限ったものではない。SeleniumやPuppeteerなど、他のブラウザ自動化ツールをAIエージェントと連携させる際にも同様の原理が適用できる。核心は、「汎用プロトコル経由」と「最適化された専用インターフェース経由」のトレードオフを理解することだ。タスクの複雑さ、求められる堅牢性、コスト感度に応じて、適切な接続方法を選択する判断が開発者に求められる。

AIエージェントの実用化が進むにつれ、その「運行コスト」であるトークン消費の最適化は重要な開発テーマとなっている。今回のPlaywrightをめぐるMCPとCLIの比較は、AIにツールを使わせる際の設計判断が、パフォーマンスとコストにいかに直結するかを示す好例だ。大規模な自動化を手がけるエンジニアは、プロトコルの便利さだけに依存せず、タスクに最適な通信経路をあらためて見極める時期に来ている。