AIブラウザの4つの形態と、それぞれが適する範囲

現在、「AIブラウザ」という言葉はかなり広い意味で使われています。ブラウザにチャットボックスを組み込んだものもAIブラウザと呼べますし、プログラムがスケジュール可能な環境リソースとして扱うブラウザも同じ名称で呼ばれます。

名前は同じでも、解決する問題は大きく違います。製品を一つずつ見るより、形態ごとに4種類に分け、それぞれが何をできて、どこで限界に達するのかを確認した方が分かりやすくなります。

サイドバー型アシスタント：ページを理解するが、ページ自体は操作しない

通常のブラウザの横に、常駐するサイドバーやパネルを追加する形です。長文記事や学術論文、数百ページに及ぶPDFを要約したり、現在見ているページを基に質問へ回答したり、メールや週報を書いたり、翻訳やリライトを行ったりできます。文体や長さを調整できるほか、画像をアップロードして視覚分析を行ったり、音声で直接会話できたりするものもあります。

本質的には、AIアシスタントをページのすぐ隣に置き、別のチャット画面へコピー＆ペーストする手間をなくす仕組みです。資料整理、テーマ調査、執筆支援といった用途なら、これだけで十分なことも多いでしょう。

一方、限界も明確です。内容は理解しますが、Webサイトを操作するわけではありません。大量の資料を整理することはできても、代わりにクリックし、入力し、送信することはできません。これは読み取りと処理のレイヤーであり、実行レイヤーではありません。

エージェント駆動型：自分で操作できるが、基本は一度に1タスク

このタイプはさらに一歩進みます。自然言語でタスクを指示すると、ページのスクロール、ボタンのクリック、フォーム入力、複数の開いているタブ間での情報比較など、複数ステップを自動で実行します。重要なのはページ理解能力です。事前に書かれたセレクタへ依存するのではなく、どれが入力欄で、どのボタンが送信に使われるのかを自分で認識する必要があります。そのため、ページ構造が変わってセレクタが効かなくなっても、処理を続けられる可能性があります。

主な制約は3つあります。決済、銀行、プライバシーに関わる操作では、通常処理が一時停止され、手動確認を求められます。これは欠陥ではなく、意図的な安全境界です。複雑なページやカスタムコンポーネントが多いサイトでは、依然としてミスが起きやすい点もあります。さらに見落とされがちなのは、単一ユーザーとの対話を前提に設計されており、高い並行処理を目的としていないことです。一度に1タスクというペースが通常です。

複雑ではあるものの、頻度が低いWeb作業を個人で行う場合に向いています。

クラウド分離型：ブラウザは遠隔で動き、使い勝手はローカルに近い

このタイプでは、ブラウザプロセスが手元の端末ではなく遠隔環境で動き、ローカル側は主に操作を担当します。そのため、同じ環境を複数の端末から開くことができ、セッションやログイン状態はクラウド側に残ります。端末ごとに設定をやり直す必要はありません。状態のスナップショットやロールバックもでき、問題が起きた環境を直前の利用可能な状態へ戻せます。ローカル端末にデータを残す必要もないため、使用端末が固定されていないチームや、業務データを各端末へ分散させたくないチームに実用的です。

代償もクラウド由来です。ネットワークの往復で遅延が増えるため、ローカルブラウザほど操作が即時には感じられません。環境数が増えれば、クラウドのリソースコストも継続的に増加します。ローカルファイル、ローカルハードウェア、社内ネットワーク上のシステムへのアクセスは、ローカルブラウザより制約があります。また、クラウド化は単にマシンの場所を変えるだけなので、複数環境でのネットワーク出口の割り当てや並行処理の制御は別途設計が必要です。

環境管理型ブラウザ：プログラムがオーケストレーションするためのレイヤー

このタイプは、人が直接使うブラウザというより、プログラムがスケジュールして利用する環境リソースとして位置付けられます。

互いに独立した環境を一括作成でき、各環境は独自のフィンガープリント、Cookie、ローカルストレージを持ちます。インターフェースを通じて環境の作成、照会、起動、停止、回収を行い、環境ごとに別のネットワーク出口を割り当てることもできます。主要な自動化フレームワークと連携してプログラム制御を受け付けることも可能です。つまり、ブラウザ環境をスケジュール可能で、分離され、管理できるインフラとして扱うための仕組みです。

これは前の3種類とはまったく異なる課題を解決します。タスクが1件から100件に増えると、それまでのやり方は一斉に限界へ達します。1ユーザー、1ウィンドウ、1回1タスクでは大量処理を支えられず、環境同士が影響し合い、タスクが互いに干渉し、アカウントが同じ一群として扱われる可能性があります。このレイヤーでPurpleMarkが提供するのは、ブラウザ環境の分離と集中管理であり、各タスクをそれぞれ独自の環境で実行できるようにします。

ただし、意思決定を代行するものではなく、各プラットフォームのルールを変えるものでもありません。タスクが規則に適合するかどうかは、あくまでそのタスク自体によって決まります。

どう選ぶか

判断の順序はシンプルで、自分の要件から逆算します。

• AIにWebページの理解だけを手伝ってもらえればよいなら、1つ目で十分です。不要な実行機能に追加コストを払う必要はありません。
• AIに一度だけ複雑な操作を代行してほしいなら、2つ目が適しています。
• データをローカルに残したくなく、複数端末をまたいで作業を継続したいなら、3つ目の方が合います。
• 自動化タスクを安定して大量に、互いに干渉させず実行したいなら、それ以前にどのAI機能を使っていても、追加で4つ目のレイヤーが必要です。

最後の点は特に重要です。何をするかを決めるのはAIですが、どのアイデンティティで実行するかを決めるのはブラウザ環境です。このアイデンティティ層が不安定だと、失敗はランダムに見えても、根本原因は環境にあることがあります。AIブラウザという概念にまず惹かれ、理解支援型のツールを購入した後で、本当に必要だったのは大量実行だと気付くチームも少なくありません。方向を間違えると、優れたツールでもそのギャップは埋められません。

まず必要なのがアシスタントなのか実行なのかを切り分け、その後で規模を考えます。大規模化する前に環境レイヤーを整え、少数のタスクでフローを通してから増やしていく方が、後になって相互に関連した多数のアカウントを整理するよりはるかに簡単です。