ウェブにエージェント導入へ ブラウザベースのポール・クライン氏

ブラウザベースの AI エージェントが実用化されない理由：モデル性能ではなく「ハネス」と「インフラ」に課題がある

AI エンジニアで Browserbase 創設者のポール・クライン氏は、ウェブ上で動作する AI エージェントの実用化が遅れている根本原因を、LLM の能力不足ではないと断言します。現在のモデルはすでに複雑なタスクを処理できる水準に達しており、真のボトルネックはそれを支える「ハネス（システム基盤）」や「インフラ」の不備にあるのです。

モデル能力への過信と「ハネス」の欠如

多くの開発者が AI エージェントの実用化が停滞している原因をモデルの性能不足に求めていますが、クライン氏はこれを誤りだと指摘します。過去 1 年間で LLM の長文コンテキスト処理や複雑なタスク遂行能力は劇的に向上しており、「モデルがダメだからできない」という言い訳はもはや通用しません。

「モデルの性能には過剰評価（capabilities overhang）がある。実際には、それを支えるハネスやツール設計の工学的課題が解決されていないのだ」

ここで言う「ハネス」とは、LLM の周囲に構築されたシステムやツールの総称です。コード生成分野で成功している例を見れば明らかです。同じモデルを使っても、Cursor や Factory といったツールが独自の「ドメイン特化型ハネス」を構築することで、ベースラインのモデル性能を超えた結果を出しています。

ブラウザ操作においても同様です。メモリやスキル（Skills）を付与したカスタムハネスを設計すれば、モデルの限界を超えるパフォーマンスが得られます。重要なのは、ラボで次世代モデルを待つのではなく、自社のドメインに合わせて最適化されたハネスを構築する工学的アプローチにあるのです。

多様なモデルとスキルの組み合わせによる最適化

信頼性の高いブラウザエージェントを実現するには、単一のモデルに依存しない「マルチモーダル」なアプローチが不可欠です。例えば、複雑なページには高性能なモデルを使い、単純なタスクには軽量なモデルを割り当てるなど、状況に応じて使い分けることが重要です。

また、クライン氏は「自動化＝画面のボタンをクリックすること」という考え方を捨て、ネットワークリクエストの傍受やコード生成による自動化も併用すべきだと提案します。これにより、コンテキスト効率を大幅に向上させ、コストを抑えながら安定した動作を実現できます。

さらに、WebMCP などの技術を活用して「スキル」を蓄積・活用する仕組みも重要です。エージェントが初めて訪問するサイトでも、過去の学習データや事前定義されたスキル（例：Playwright CLI の操作ノウハウ）を活用すれば、ゼロから学習する必要がなく、瞬時に最適な動作が可能になります。

一貫性のあるクラウドインフラの重要性

実用化における最大の障壁の一つが、不安定なインフラ環境です。多くの企業が Mac Mini を購入して自宅やオフィスでエージェントを動かそうとしますが、これはスケーラビリティとセキュリティの観点から現実的ではありません。

「SOC2 準拠の Mac Mini 環境を大規模に構築した例はまだ見たことがない」

プロダクション環境では、PC の個別設定に依存せず、レイアウトや動作に一貫性のあるクラウドベースのブラウザ環境が必須です。ある時はモバイル表示で、別の時はデスクトップ表示でページがレンダリングされるような不整合は、エージェントの信頼性を著しく損ないます。

Browserbase が提供する環境のように、SOC2 準拠でレイアウトや動作が一貫したクラウドインフラを整備することで、初めて数千規模のエージェントを安定的に運用できるのです。これはモデルの性能向上とは別に、確実に解決すべき工学的課題です。

ウェブ側からの改善と自己学習ループの構築

最後に、クライン氏は「ハネス」や「インフラ」だけでなく、ウェブ自体の改善も必要だと指摘します。アクセシビリティ対応の推進に加え、実行ログや画面記録をフィードバックループに組み込むことで、エージェントが継続的に自己改善する仕組みが必要です。

現在の AI エージェント開発は、「モデルの性能向上」から「システム統合とインフラ整備」へと焦点を移すべき局面にあります。企業にとっては、独自のエージェント構築コストを削減し、既存のウェブ資産を活用した自動化を進めるための具体的な指針となるでしょう。モデルが完璧になるのを待つのではなく、今日からハネスとインフラの設計に取りかかることが、実用化への近道なのです。