高階関数ツールを使ったAI Agent検証 - ブラウザ操作自動化タスクで3.4倍高速・コスト1/5を実現

スパイスコード CTO の櫻木です. 前回の記事では, スパイスコードでのAI Agent 開発におけるコンテキストエンジニアリングの考え方, 高階関数的なツール設計, 安全なコード実行, そして自己学習サイクルの重要性を紹介しました. 今回はその延長として, 実際のブラウザ操作タスクを題材に, その効果を検証したアウトプットイメージを共有したいと思います.

1. はじめに

前回の記事: tech-blog.localmet.com

前回の記事では, AI Agent開発における

  • コンテキストエンジニアリングの重要性
  • 高階関数的なツール設計とコード実行によるアプローチ
  • Artifact IDによる参照
  • 自己修復による継続的改善

を紹介しました. 今回はその設計思想を実際のブラウザ業務自動化タスクに適用し, ウォームアップ+90回の試行を通じて3つの実行方式を定量的に比較した実験結果を報告します.

実験のポイントは毎回LLMがUIを探索するのではなく, 初回に操作手順を学習し, 以降は決定的に実行する仕組みが, 実運用でどれだけ効果を発揮するかです.

1.1 実験の目的

  • ブラウザ操作タスクにおける 3 方式の性能比較
  • 成果物の回収精度 (欠損・重複なし) の検証
  • 操作ログを再利用したチェーン再生の有効性評価
  • tool chain toolの設計が, 実運用でどれだけ効くかの実証

1.2 概要

前回記事で紹介したコンテキストエンジニアリングの設計思想を, 実際のブラウザ業務自動化タスクに適用し, 3つの実行方式を比較しました.

比較した3方式:

  • Method A (Baseline): 毎回UIを探索する従来方式
  • Method B (Workflow): 操作ログから内製CDPツールのワークフローを生成し, 再生
  • Method C (Chain): 操作ログからplaywrightコードを生成し, 前回記事で紹介したtool chain toolで再生

実験結果 - Method Cが最も優れた性能を示しました

  • 速度: Method Aと比較して3.4倍高速（88.2秒 → 26.3秒）
  • コスト: Method Aと比較して約1/5.5（$1.034/回 → $0.188/回）
  • 安定性: 標準偏差4.0秒と最も小さく、変動係数15.3%で予測可能性が高い

主要な示唆:

  • 「探索」と「実行」の分離により、LLMの推論能力を判断に集中させ、実行は決定的な機構に任せることで高速・低コスト・安定を実現
  • 初回に操作手順を学習すれば、以降は機械的に実行可能（学習への投資として正当化）
  • 複雑なサイトほど連鎖的実行のメリットが大きい（Site B: 113秒 → 31.5秒）
  • 安定的なワークフロー実行とエージェントによる柔軟性の担保の良いとこどり

2. 実験の全体設計

2.1 対象タスク

  • 対象期間の発注書や証憑をブラウザ経由でダウンロードする業務を想定
  • 欠損や重複がない状態 (MECE) で成果物を取得することがゴール

2.2 比較する 3 方式

  • Method A (Baseline): 毎回UIを探索し操作を逐次実行する従来方式
  • Method B (Workflow): 操作ログから内製CDPツールのワークフローを生成し, 再生
  • Method C (Chain): 操作ログからplaywrightコードを生成し, 前回記事で紹介したtool chain toolを使って再生

※ 方式BとCは思想としては近く, 実装ランタイムの違いが主な差分です.

methods

2.3 試行条件

  • 各方式 × 3サイト × 10回の試行
  • 合計試行数: 90回（各方式30回ずつ）
  • 収集する指標: 実行時間, LLMコスト, 成功率, 実行の安定性（標準偏差）
  • 使用LLMモデル: anthropic.claude-sonnet-4-20250514-v1:0 (Claude Sonnet 4.5)

全ての試行は同一のタスク「指定月の発注書を全てダウンロード」を入力プロンプトとし,各サイトの特性（ページ構造,認証方式,ダウンロードフロー）が異なる環境で評価しています.

重要な前提条件:

  • Method A: 毎回ゼロからUI探索を実行（学習なし）
  • Method B・C: 事前に初回実行と自己修復によってワークフロー/チェーンが確立された状態での実行を評価

つまり,Method BとCの実験結果は「既に学習済みの手順を再生する性能」を測定したものです.初回実行や自己修復のコストは別途5.4節で補足データとして記載しています.

3. エージェントの設計思想

前回の記事で紹介した「コンテキストエンジニアリング」の考え方は, 今回の実験でも中心的な役割を果たします.

  • 入出力を最小化し, 大量データを LLM に流し込まない
  • 中間結果は外部成果物として保存し, 参照は ID のみ
  • エージェントが複雑な処理を直接抱え込まず, ツールの連鎖で解決する

この設計により, 長い UI 操作や大量の成果物処理でも, LLM の負荷と失敗率を抑制を期待します.

context_compression_avoidance

4. エージェントとツールの概要

4.1 共通ツール

  • デスクトップ共有ツール: waylandスタックで構成される仮想ディスプレイをnovncを利用することでエージェントが見る画面をユーザに共有する機能
  • Artifact系ツール: LLMに大量データを渡さず,IDのみで参照する機能の提供. コンテキスト圧縮ツール
  • ログイン情報取得ツール: ログイン用のid,passwordなどを安全に扱うためのツール
  • 2要素認証対応ツール: totpやメールでの２段階認証を解くためのツール

4.2 ３種の方式

4.2.1 MethodA

  • 役割: UIを毎回探索して操作を実行
  • 主要ツール:
    • Playwright MCPツール群（ブラウザ操作の基本）
  • 特徴: ReActパターンで毎回LLMが推論しながらツールを選択・実行

4.2.2 MethodB

  • 役割: ワークフロー(Blueprint)を管理・実行
  • 主要ツール:
    • 既存ワークフロー取得ツール
    • 内製CDPワークフロー実行ツール
    • 操作ログ解析ツール
    • ログからワークフロー生成・保存を行うツール
  • サブエージェント
    • 失敗時のフォールバック用エージェント（探索的再実行）
    • ワークフロー修復エージェント
  • 特徴: 決定的な操作シーケンスをJSON形式で保存・再生

4.2.3 MethodC

  • 役割: browser_run_codeを含む高階関数連鎖をtool chain toolを使い実行
  • 主要ツール:
    • tool chain tool（探索モードでの操作収集も兼ねる）
    • 操作ログ解析ツール
    • Chainの取得・保存などを行う管理ツール
    • Playwright MCPツール群（探索モード用）
  • サブエージェント
    • 解析された操作ログからtool chain toolへのinputを生成するエージェント
    • tool chain修復エージェント
  • 特徴: playwright-mcpの browser_run_code を呼び出す高階関数としてtool chain toolを利用. 探索モードではplaywright-mcpの通常ツールで操作収集を行う

Method CにおけるAgent-Tool連携の典型的なフロー：

  1. 初回実行（探索フェーズ）

    • BrowserChainAgent: Chain実行ツール呼び出し
    • 既存Chainなし → playwright-mcpで操作を実行・ログ収集
    • 操作ログを解析しサブエージェントへartifact_idを渡す
    • サブエージェントが browser_run_code呼び出しを含む高階関数連鎖を生成（Artifact化）
    • Chain保存: ArtifactをChainとして保存

  2. 2回目以降（実行フェーズ）

    • BrowserChainAgent: Chain実行ツール呼び出し
    • 既存Chain取得 → tool chain toolで直接実行
    • LLMの推論は最小限（「このChainを実行」のみ）

  3. 失敗時（自己修復フェーズ）

    • Chain実行失敗 → サブエージェントに修復依頼
    • 修復用のエージェントがステップバイステップで操作を実行し、エラーを元にchainの修復を実施
    • 新しいChainを生成・保存

ブラウザ操作タスクでは, 様々な外的要因により, 決定的な実行が毎回成功する保証はありません. その要因がサイト側のUI変更であるのか, 一時的な障害起因であるのか, はたまたネットワーク障害要因なのか, 自律的に検証・修復を実施できることでLLMの柔軟性と決定的な実行の高速性・安定性を両立しようという試みです.

4.3 特徴的なツール

4.3.1 高階関数的なツール

  • ワークフローJSONを引数に取り,CDP経由で実行するツール (MethodB)
  • playwright-mcpの browser_run_code: playwrightコードを引数に取り,Playwright操作を実行 (MethodC)
  • playwright-codeを含んだ「操作手順」を引数として受け取るメタツール (MethodC)

4.3.2 自己修復ツール

  • ワークフロー失敗時に差分修正するツール
  • ワークフローが使えない場合に探索的実行に切り替えるツール
  • UI変更への自動対応を実現

5. 実験結果

5.1 実行時間の比較

5.1.1 エージェント別の比較

全90回の試行から得られた実行時間の統計は以下の通りです.

方式 平均 中央値 最小 最大 標準偏差
A (Baseline) 88.2秒 78.8秒 54.9秒 172.6秒 25.9秒
B (Workflow) 40.2秒 37.2秒 33.8秒 54.5秒 5.4秒
C (Chain) 26.3秒 24.2秒 21.5秒 33.1秒 4.0秒

performance_summary

主要な結果:

  • Method Cは Method Aと比較して3.4倍高速（88.2秒 → 26.3秒）
  • Method Bは Method Aと比較して2.2倍高速（88.2秒 → 40.2秒）
  • Method Cは最も安定しており,標準偏差はMethod Aの約1/6（25.9秒 → 4.0秒）

5.1.2 サイト別の内訳

各サイトの特性により,実行時間には顕著な違いが見られました.

サイト Method A Method B Method C
Site A 78.4秒 37.6秒 23.3秒
Site B 112.8秒 47.0秒 31.5秒
Site C 73.4秒 36.1秒 24.1秒

site_breakdown

Site Bは全方式で実行時間が長い傾向にあり,これはページ構造の複雑さや待機時間の影響と考えられます.一方で,Method CはSite Bでも31.5秒と,Method AのSite A/C（最速サイト）よりも高速です.

5.1.3 個別試行のばらつき

各試行の実行時間とコストの関係を散布図で可視化しました.

scatter

Method Aは試行ごとのばらつきが大きく,特にSite Bでは54秒から173秒まで約3倍の差があります.これは,LLMが毎回UIを探索するため,推論経路が安定しないことが原因です.

一方,Method BとCは初回にワークフロー/チェーンを生成した後は決定的な実行が可能なため,ばらつきが小さく安定しています.

5.2 LLMコストの比較

5.2.1 エージェント別の比較

各方式のLLM利用コスト（USD）を比較しました.

方式 平均コスト/回 総コスト（30回） Aとの比率
A (Baseline) $1.034 $31.02 1.0x
B (Workflow) $0.262 $7.87 0.25x（1/4）
C (Chain) $0.188 $5.63 0.18x（1/5.5）

cost_comparison

Method Cは Method Aと比較してコストが約1/5.5と圧倒的に経済的です.これは,チェーン実行時にはLLMの推論が最小限で済むためです.

5.2.2 時間とコスト

time_cost_tradeoff

この散布図から,Method Cが「高速かつ低コスト」の理想的な領域に位置していることが分かります.Method Aは全ての試行が右上（遅くて高コスト）に分布しています.

5.3 成功率と安定性

成功率（全30回中の成功数）:

  • Method A: 96.7%（29/30）
  • Method B: 100%（30/30）
  • Method C: 100%（30/30）

Method BとCは全試行で成功しました.Method Aは1回の失敗があり,実行時間が54.9秒となり,早期に処理が終了しました.これは,毎回UIを探索する方式特有の不安定性を示しています.

一方,Method BとCは既に確立された手順を実行するため,より高い信頼性を示しました.

注意: 今回の実験は各方式30回の試行であり,統計的に十分な回数とは言えません.特にMethod BとCの100%成功率は,より多くの試行を重ねることで変動する可能性があります.本結果は3方式の傾向を示すものとして解釈してください.

実行時間の安定性（標準偏差）:

stability_comparison

方式 標準偏差 変動係数（CV）
A (Baseline) 25.9秒 29.4%
B (Workflow) 5.4秒 13.4%
C (Chain) 4.0秒 15.3%

Method Cは標準偏差が4.0秒と最も小さく,実行時間の予測可能性が高いことを示しています.変動係数（標準偏差/平均）で見ると,Method Aは約30%のばらつきがあるのに対し,Method BとCは約13-15%と安定しています.

5.4 初回実行と自己修復のコスト（ウォームアップ）

Method BとCには,初回実行時にワークフロー/チェーンを生成する「探索フェーズ」と, 生成されたものが失敗した場合に修復する「自己修復フェーズ」があります.これらのコストを参考値として記載します.
共に今回のウォームアップでは初回実行 -> ログからワークフロー/チェーンを生成 -> 失敗 -> 自己修復 -> 完了の流れを観測しました.

Method B (Workflow)

サイト 初回実行 自己修復
Site A $0.54, 58秒 $1.75, 428秒
Site B $0.94, 102秒 $0.65, 72秒
Site C $0.62, 64秒 $1.44, 167秒

Method C (Chain)

サイト 初回実行 自己修復
Site A $1.45, 129秒 $0.70, 68秒
Site B $1.74, 164秒 $0.30, 42秒
Site C $1.91, 155秒 $1.09, 107秒

考察:

  • 初回実行のコストは$0.54〜$1.91と幅があるが,一度チェーン/ワークフローを生成すれば,以降は$0.19〜$0.26の低コストで実行可能
  • 自己修復が必要な場合でも,多くのケースで初回よりも短時間・低コストで修復できている
  • これは,操作ログから学習する仕組みが有効に機能していることを示す

6. 解説

実験結果から,Method BとCがMethod Aを大きく上回る性能を示しました.以下,技術的な観点から各方式の差異をより詳しく解説します.

6.1 コンテキスト効率の違い

6.1.2 Method A（逐次探索型）の課題

Method Aは毎回LLMがUIを探索するため,以下のコンテキスト消費が発生します：

  1. ページ全体のスナップショット: 各ステップでDOMやスクリーンショットを解析
  2. 要素の探索と推論: どのボタンをクリックすべきか,どのフィールドに入力すべきかを毎回推論
  3. エラーリカバリー: UI要素が見つからない場合の再試行ループ

これらが積み重なり,1回の実行で平均35,000トークン程度を消費しました（実測値）.結果として：

  • 実行時間が長い: LLMの推論時間が支配的
  • コストが高い: トークン消費量に比例してコストが増大
  • 不安定: 推論経路が毎回異なるため,実行時間にばらつきが生じる

6.1.3 Method BとC（再生型）の優位性

一方,Method BとCは初回と失敗した場合のみ探索し,その結果を決定的な手順として保存します：

  1. 初回: UIを探索して操作ログを収集（コスト高・時間長）
  2. 連鎖生成: ログからワークフローJSON（Method B）またはbrowser_run_code呼び出しを含む高階関数連鎖（Method C）を生成
  3. 2回目以降: 生成された手順を機械的に実行（コスト低・時間短）

2回目以降は,LLMの推論がほぼ不要で,確立された手順を直接実行するため：

  • トークン消費は約5,000〜8,000程度（約1/5）
  • 実行時間は決定的な処理のみなので安定
  • コストは劇的に削減

speed_comp

6.2 標準偏差から見る安定性の本質

Method Aの標準偏差25.9秒（変動係数29.4%）という値は,業務自動化において致命的です.なぜなら：

  • スケジューリング困難: 実行時間が予測できないため,バッチ処理の計画が立てられない
  • SLA違反リスク: 最悪ケースで172秒かかる可能性があり,タイムアウトリスクが高い
  • リソース確保の困難: ピーク時のリソースに合わせる必要があり,コスト効率が悪化

Method CとBの標準偏差4.0秒・5.4秒（変動係数13-15%）は,安定した業務運用が可能なレベルです. なんらかの業務を柔軟性を担保したLLMを用いて自動化したいとき, 実際に人がやる場合と比べてどれぐらい安く済むのかは非常に重要になってきます.

6.3 初回コストの償却可能性

Method BとCの初回実行コストは$0.54〜$1.91と,Method Aの平均$1.03より高い場合もあります.しかし：

  • 2回目以降: $0.19〜$0.26で実行可能
  • 損益分岐点: 約2〜3回の実行で初回コストを回収
  • 月次運用: 毎月10回実行する場合,年間で約$100以上のコスト削減

業務の反復頻度を考えると,Method BとCの初回投資は十分に正当化されます.

6.4 なぜMethod CはMethod Bより速いのか

Method CとBの平均実行時間を比較すると,Cが約35%高速です（26.3秒 vs 40.2秒）.この差の要因は：

  • 実装ランタイムの違い
  • 実行の最適化度(タイムアウトなど)
  • 補助ツールの利用

により生まれており, 工夫次第で大差ないものになると考えています.

6.5 前回記事で紹介したコンテキストエンジニアリングとの関連

前回の記事で紹介した「高階関数的なツール設計」と「コンテキスト圧迫の回避」が,今回の実験結果で実証されました.

高階関数的なツール設計:

  • playwright-mcpの browser_run_code は「playwrightコードを引数に取り,ブラウザ操作を実行する」高階関数
  • 更にMethod Cの連鎖は,複数のbrowser_run_code呼び出しを含む高階関数として構成される
  • 中間結果はartifact IDとして保存され,LLMのコンテキストに載らない

コンテキスト圧迫の回避:

  • 操作ログ（数万トークン）→ Chain ID（数トークン）に圧縮
  • LLMは「このChainを実行する」という判断のみを処理
  • 実際の実行はLLMの外で,高階関数実行エンジンがbrowser_run_codeを順次呼び出す

これにより,Method CはLLMの能力を「判断」に集中させ,「実行」は決定的な機構に任せることで,高速・低コスト・安定を実現しています.

7. 今回の実験で得られた示唆

7.1 「探索」と「実行」の分離が鍵

今回の実験で最も重要な示唆は,探索フェーズと実行フェーズを分離することの有効性です.

従来のアプローチ（Method A）は,毎回「探索しながら実行する」ため,コストと時間がかかります.一方,Method BとCは：

  1. 初回: 探索に集中し,決定的な手順を抽出
  2. 2回目以降: 抽出した手順を機械的に再生

この分離により,LLMの「柔軟な推論能力」と「決定的な実行の高速性」を両立できます.

7.2 コード連鎖生成は「学習」の一形態

Method BとCの連鎖生成は,実質的にAI Agentが業務手順を学習していると言えます.

  • 人間が初めて業務を行う際も,最初は試行錯誤しながら手順を理解します
  • 2回目以降は,覚えた手順を素早く実行できます
  • AI Agentも同様に,初回の「学習コスト」を払えば,以降は効率的に実行できる

この視点で見ると,初回実行の$0.54〜$1.91というコストは「学習への投資」であり,十分にROIが見込めます.

7.3 エージェント連携の実証

前回の記事で紹介したtool chain toolが,実運用レベルで機能することが実証されました. 更にメインエージェントと各サブエージェントが明確な役割を持ち,成果物をIDで引き渡すことで,全体として複雑な業務を自動化できています.

7.4 自己修復の重要性

実験データから,自己修復フェーズのコストは初回実行より低い傾向が見られました（例: Site B Chain で$1.74 → $0.30）.

これは,Healer Agentが：

  • 失敗の原因を特定
  • 最小限の修正で対応
  • 全体を再生成せず,部分修正で済ませる

という賢い動作をしていることを示します.この自己修復能力により,UI変更などの環境変化にも柔軟に対応できます.

8. 今後の展開

今回の実験で得られた知見をもとに,以下の方向で開発を進めていきます.

8.1 自動メンテナンス

現在は初回実行と自己修復で手動的に連鎖を更新していますが,今後は：

  • UI変更の自動検知: 定期実行で失敗パターンを検知
  • 差分修復: 全体を再生成せず,変更箇所のみを更新するようにプロンプト
  • バージョン管理の有効活用: 保持している業務フローの履歴をエージェントが活用できるように

これにより,Webサイトの仕様変更にも自動で追従できる仕組みを目指します.

8.2 連鎖の横展開と再利用

類似した業務間で連鎖を再利用できれば,初回実行コストをさらに削減できます：

  • パターンライブラリ: 「ログイン→検索→ダウンロード」などの汎用パターンを抽出
  • テンプレート化: サイト固有の部分だけをパラメータ化
  • 転移学習的なアプローチ: Site Aで学習した連鎖をSite Bに適用

これにより,新しいサイトへの対応時間を大幅に短縮できます.

8.3 他の業務領域への展開

今回はブラウザ操作に焦点を当てましたが,同様のアプローチは他の領域にも適用可能です：

  • データ抽出・変換: 複雑なExcel処理やPDF解析の手順を連鎖として定式化
  • API連携: 複数サービス間のデータ連携フローを連鎖として定式化
  • レポート生成: データ収集→分析→可視化の一連の流れを連鎖として定式化

前回の記事で紹介した「コード実行」と組み合わせることで,より幅広い業務を自動化できます.

8.4 知識の蓄積と活用

実行ログと連鎖を蓄積することで,組織全体の「業務知識ベース」を構築できます：

  • ベストプラクティスの抽出: 成功率の高い連鎖パターンを分析
  • Knowledge化: 前回記事で紹介したElasticsearch索引を活用し,類似タスクに推薦
  • LLM as a Judgeによる評価: 連鎖の品質を自動評価し,改善提案

これにより,AIエージェントが「使うほど賢くなる」システムを実現します.

9. おわりに

今回の実験では,90回の試行を通じて,ブラウザ操作自動化タスクにおける3つのアプローチを定量的に比較しました.

主要な成果:

  • Method Cは Method Aと比較して3.4倍高速,コスト1/5.5を達成
  • 標準偏差4.0秒という高い安定性で,業務運用に耐える信頼性を実証
  • 初回の「学習コスト」を払えば,以降は決定的な実行が可能
  • 複雑なサイトほど連鎖的実行の効果が大きい

前回の記事で紹介した「コンテキストエンジニアリング」の考え方が,実験結果として明確に裏付けられました.特に：

  1. 高階関数的なツール設計: 連鎖をartifact IDで管理し,LLMのコンテキストを圧迫しない
  2. 探索と実行の分離: LLMの推論能力を「判断」に集中させ,「実行」は決定的な機構に任せる
  3. エージェント連携: 複数エージェントの協調により,複雑な業務を段階的に処理

これらの設計思想が組み合わさることで,AI Agentを実運用レベルに引き上げることができます.

実験を通じて:

  • AIは「毎回考える」必要はない.一度学習した手順は機械的に実行すべき
  • 複雑さは敵ではなく,むしろ連鎖的実行のメリットを最大化する要因
  • 初回コストは投資であり,反復業務では確実にROIが見込める

今後も,実験結果を蓄積しながら,より実用的なAI Agent開発のノウハウを発信していきます.

スパイスコードでは,このような AI を使ったチャレンジングな機能開発に取り組んでいます.興味を持った方は,ぜひお話ししましょう！

https://corp.spicescode.co.jp/

参考 (前回の記事)

tech-blog.localmet.com