なぜAIPexはdebugger（CDP）でブラウザ操作をしないのか

AIPexは最近、新しいバージョンをリリースしました。最も重要な能力のひとつは、 ユーザーの通常のワークフローを中断せずに、ブラウザタスクをバックグラウンドで実行できることです。

この能力は「小技」ではなく、明確な設計判断から生まれています： 私たちは、ブラウザ操作をdebugger（Chrome DevTools Protocol / CDP）に載せないことを意図的に選びました。

本記事では、なぜ多くの実装がdebuggerを選ぶのか、そしてAIPexが多くのエージェント／日常自動化シーンで別ルートを選ぶ理由を説明します。

なぜ多くのブラウザ操作実装はdebugger（CDP）を選ぶのか

「移行不要」のブラウザ自動化拡張やAgentの世界では、例えば以下のようなアプローチが一般的です：

Manus の Manus Browser Operator
Anthropic の Claude in Chrome
OSS の nano browser
Puppeteer / Playwright などの自動化ツールを拡張として使う形態

これらの多くは Chrome DevTools Protocol（CDP）、特にdebugger機能をベースにしています。理由はシンプルです。

1. 能力カバレッジが広い

CDPはブラウザ内部の主要機能をほぼ網羅します：

ページ遷移とライフサイクル制御
DOM と AXTree（Accessibility Tree）へのアクセス
イベント注入（マウス、キーボード、ホイール）
ネットワークの傍受と書き換え
スクリーンショット、録画、性能計測

複雑な自動化にとって、CDPは「箱から出してすぐ使える」フル機能インターフェースです。

2. Accessibility Tree（AXTree）が高い意味性を持つ

CDP経由でブラウザが構築する Accessibility Tree を直接取得できます：

各ノードが role / name / state を持つ
音声支援やAI理解に自然に適合する
ARIA実装が理想的なら、意味品質が高い

そのため、AXTreeは多くのAI Agentにとって主要なページ表現になっています。

3. エンジニアリングの生態系が成熟している

CDP周辺には成熟したツールチェーンがあります：

Puppeteer / Playwright などの基盤実装
充実したドキュメント、サンプル、コミュニティ知見
自動化エンジニアにとって学習・導入コストが明確

デスクトップ環境におけるdebugger（CDP）の現実的コスト

CDPは強力ですが、**「ユーザーと並行して動くデスクトップ」**の文脈では無視できない問題も生みます。

1. フォーカス奪取によるUX問題

CDPは「バックグラウンドで静かに動く」ことを目的に設計されていません。実際のデスクトップ環境では：

debugger attach が タブのアクティブ化／ウィンドウ前面化 を引き起こしやすい
入力や視覚フォーカスが強制的に奪われる可能性がある
headless等の回避策でも、OSやブラウザ差を超えて一貫動作を保証しにくい

結果として： ユーザーが他のアプリやタブで作業中に、自動化が割り込んでしまい、体験を悪化させます。

2. ブラウザ／実行環境との結合が強い

CDPを使うと、一般に：

デバッグポートの有効化が必要
Chrome / Chromium への強い依存
一部の埋め込みWebView、制限環境、非Chromiumブラウザへの対応が弱い

企業環境やマルチブラウザ前提の運用では、導入・保守コストが大きくなります。

3. セキュリティと権限の摩擦

デバッグポートやプロセス権限、証明書設定などは、管理環境で以下を招きがちです：

セキュリティポリシーによるブロック
コンプライアンス審査
IT運用側の抵抗

技術的に不可能というより、展開摩擦が高すぎることが問題です。

ブラウザ操作にdebuggerが必須とは限らない

AIPexの中核設計目標はこうです：

ブラウザタスクを「遠隔操作」のようにユーザーを中断させるのではなく、「背景思考」のように動かす。

そのため、debugger中心ではない道を選びました。

AIPexのアプローチ：DOMの意味スナップショット + 軽量インタラクション

ページ側では、AIPexは純粋なJavaScript / TypeScriptで以下を実現します：

意味化されたページスナップショット
安定したノードマッピング
軽量なイベントベースのインタラクション

CDPのAXTreeやデバッグチャネルに依存しません。

1. デバッグツリーではなく、意味スナップショット

AIPexは @aipexstudio/dom-snapshot をベースにしています：

DOM Treeを直接走査
アクセシビリティ関連の意味（role / name / state）を抽出
CDPのAccessibility Tree（AXTree）に依存しない

READMEでも明記されています： これは純DOMアプローチであり、CDPのラッパーではありません。

2. 安定して再利用できるノードID

ページ要素に安定した data-aipex-nodeid を自動生成します。

これにより：

「意味スナップショット上のノード」と「実DOM要素」のマッピングを長期間再利用できる
デバッグ依存で起きやすいセレクタのドリフトを回避できる
テキスト命中から操作対象要素へ正確に逆引きできる

3. 操作対象にフォーカスしたスナップショット戦略

意味スナップショットは優先的に：

ボタン、リンク、入力欄などの操作可能要素
対話／タスクに関係するUIサブセット

に注目し、次をフィルタします：

display: none
visibility: hidden
aria-hidden
inert

意味のない不可視ノードをAgentに渡さないようにします。

4. テキスト化表現と意味検索

スナップショットは読み上げ可能・検索可能なテキスト形式（TextSnapshot）に変換できます：

→uid=dom_abc123 RootWebArea "My Page" <body>
uid=dom_def456 button "送信" <button>
uid=dom_ghi789 textbox "メール" <input> desc="メールアドレスを入力"
StaticText "おかえりなさい"
*uid=dom_jkl012 link "詳細を見る" <a>

ここで：

* は現在フォーカス中の要素
→ はフォーカス祖先

を表します。TTS/音声読み上げにも向き、自然言語での検索にも使えます。

5. 意味検索の例

パイプ区切りやglob検索に対応します：

searchSnapshotText(formatted, "ログイン | Login | Sign In");
searchSnapshotText(formatted, "button* | *submit*", {
  useGlob: true,
  contextLevels: 2
});

命中したテキスト行は data-aipex-nodeid によりDOM要素へ正確にマッピングできます。

6. デバッグ注入ではなく、ページ側イベント

インタラクションはページ側イベント（click / focus / inputなど）で完結します：

コンテンツスクリプトや拡張のメッセージチャネルでトリガー
バックグラウンドのタスクスケジューラと連携
デバッグポート不要
前面ウィンドウ強制なし

Webの意味表現を、エンジニアリング視点で見る

ブラウザ自動化／AI Agent文脈で、ページ表現としてよく使われるのは主に2種類です：

DOM Tree

ソース：ブラウザのネイティブDOM（Document Object Model）

特徴：情報は完全だが冗長で、意味性が弱いそのまま使うとAIの理解と操作に不向きです。

Accessibility Tree（AXTree）

ソース：ARIA意味から派生

特徴：高い意味性制約：

サイトのARIA実装品質に依存
ノード情報が必ずしも完全ではない
リモート取得がCDPに依存しがち

実際、AXTreeに全面依存すると、Agentの「知覚」は対象サイトのアクセシビリティ成熟度に縛られます。現実のWebでは理想的ではありません。

AIPexの選択と境界

DOM Treeを意味化処理することで、AIPexはdebuggerに依存せずに以下を実現します：

バックグラウンド実行でユーザーを中断しない
より完全なページ情報表現

補足として：ネットワーク傍受、性能サンプリング、権限プロンプト、ファイルシステムアクセスなど「ブラウザ特権能力」が必要な場面では、CDPには依然として代替不能の価値があります。

AIPexはdebuggerを否定しているのではなく、日常自動化とエージェント用途では、よりUXに優しい解法を優先しているだけです。

参考・出典

@aipexstudio/dom-snapshot
ソース & ドキュメント: AIPexStudio/AIPex packages/dom-snapshot
README（raw）: dom-snapshot README