PawWork_ZhuaZhua：選択範囲から編集可能なオフィスファイルを出すChromeエージェント
Paw Work - selection-first web agent for Chrome: select on the live page, describe the outcome, take away an editable office file. BYOK, sandboxed, no server.
ひと目でわかる
- これは何？
- ログイン済みのChromeタブを操作対象にするMV3拡張で、BYOKとサンドボックス実行を前提に、選択・指示・ファイル出力までをサイドパネル内で完結させる。ストア配布もホスト型モデルも持たない設計を、導入判断の観点から整理する。
- 誰に向いている？
- ログイン済みの画面から表や文書を取り出したいが、認証情報を外部サーバーに渡したくない個人や小規模チームに向く。逆に、社内配布や自動更新の仕組みを前提とする組織、モデル費用を一元管理したいチームには不向きで、アンパック拡張のまま各自がBYOKキーを持つ運用になる。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 6 日前です。
- 何の言語で書かれている？
- 主に JavaScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
選択した要素を起点に、タブを操作して成果物を返す
PawWork_ZhuaZhua（爪爪）が解くのは、ログイン済みの画面から情報を取り出して手元のファイルにするまでの往復が長いという問題だ。READMEはこの拡張を「already-logged-in Chrome as a programmable computer」と表現し、その上のagentだと位置づけている。対象は、社内ツールや会員サイトのようにスクレイピング用のAPIがなく、Cookieやセッションがないと中身が見えないページを日常的に扱う人。Tampermonkeyのユーザースクリプトで何とかしてきた層が、最初に比較対象として思い浮かべる位置にある。
出力先が表計算や文書として用意されている点が、単なる自動操作ツールとの違いになる。READMEのツール一覧には sheet、doc、web の3つが並び、それぞれUniverの表、Univerの文書、data-paw-kind=site のキャンバスに対応する。ページから抜き出した内容を、そのまま編集可能な形でセッション内に置ける。
サイドパネル、サービスワーカー、オフスクリーンの三段構成
処理の流れはREADMEの図式で明示されている。サイドパネルからサービスワーカーへ、そこからオフスクリーンの SessionWorkspaceService へ、そしてAI SDKの ToolLoopAgent に渡る。UIと実行主体が分離しているため、パネルを閉じてもセッションの作業領域が残る構造だと読める。
モデルに渡されるツールは action、run、sheet / doc / web、そして inspect / acquire / clarify の各群に分かれる。action は現在のタブに対する操作で、まず snapshot を取得し、その世代の ref と rev の組を使って変更をかける。要素を指す参照が世代に紐づくので、DOMが変われば古いrefは無効になる。run はサンドボックスのJavaScript実行で、ゲスト側の sys から tabs、eval、fetch、cdp、download、screenshot に触れる。
READMEが繰り返し述べるのは、sys はモデルのツールではないという点だ。ログイン、Cookie、CAPTCHAの扱いは run の中の sys.fetch({ as: "page" }) を通す。つまりページの身元でリクエストを投げる経路を、モデルが直接叩けるツールとして公開していない。認証まわりの操作を一段内側に隠す設計だと解釈できる。
アンパックで読み込むまでの手順
Chrome Web Storeの掲載はなく、配布はReleaseのzipかリポジトリのクローンという形になる。READMEのRun itは次の順序を示す。Releaseのzipを展開するかリポジトリをcloneして extension/ フォルダを使い、chrome://extensions で開発者モードを有効にしてLoad unpackedからそのフォルダを選ぶ。manifest.json がそのフォルダの直下にあることが条件だ。
読み込みが済むとサイドパネルに「爪爪 · 完全解放版」というエージェントが現れる。BYOKのキーは pagewand_providers に貼り付け、通常のhttp(s)ページでタスクを送る。読み込みフォルダ内のファイルを編集した後は、拡張機能カードの再読み込みを押す。READMEは「No daily npm」と書いており、ビルド手順を日常的に回す必要はない。
回帰確認用のコマンドも用意されている。node --test tests/runtime-regression.test.mjs を実行する形で、AGENTS.md にアーキテクチャとツール契約の詳細がある。同梱のプレイブックは page-restyle の1つだけで、ユーザースクリプトのカタログのようなものは存在しない。
Chrome 135以降、CDPの占有、そしてNEED_PAGE
制約は導入の可否を直接左右する。Chrome 135以上が必要で、sys.eval やページ内fetchを使う場合はChrome 138以降で拡張機能の詳細からAllow User Scriptsを有効にする。CDPを使う前にターゲットタブのF12を閉じておかないと CDP_BUSY が返る。chrome:// やWeb Storeといった制限ページは NEED_PAGE で拒否される。
ここで素直に読むべきは、この拡張がDevToolsのプロトコルを土台にしているという事実だ。開発者ツールを開いたまま同じタブを操作できないのは、競合ではなく仕様上の排他になる。デバッグしながらエージェントを走らせたい人は、タブを分けるか、動作確認の順序を分ける必要がある。
もう一点、READMEは自らをベンチマーク一覧でもストアでもないと断っている。ユースケースとして挙げられているのは、ページの整形、ログイン済みビューの取得、フォーム入力、ページの身元でのダウンロード、タブの一括処理とSPA遷移後の待機、読書補助のオーバーレイといった項目だ。動作する保証ではなく、試された範囲の提示として読むのが正確になる。
Tampermonkeyとの違いは、スクリプトの置き場所と指示の粒度
最も近い代替はTampermonkeyのユーザースクリプトだ。README自身が「Anything a Tampermonkey userscript could do is in scope」と範囲の広さを示しつつ、ユーザースクリプトストアは持たないと明言している。違いは実行の起点にある。ユーザースクリプトは対象サイトに固定されたコードを先に書き、条件に合致したときに走る。PawWork_ZhuaZhuaは、その場のタブに対して自然言語で結果を指示し、モデルがactionやrunを選んで実行する。
もう一つの違いが配布と権限の扱いだ。ユーザースクリプトはストアや配布サイトから入れて自動更新できるが、こちらはアンパック拡張なので更新は手動でフォルダを差し替える。逆に、モデルの鍵もデータの経路も利用者側に閉じる。READMEのLimitsの表は、CWSインストール、ホスト型モデル、Tampermonkeyのカタログをいずれも「No」として並べている。この3つのNoが、そのまま採用判断の分岐点になる。
更新コストはフォルダの差し替え、ライセンスはMIT
アンパック拡張である以上、更新はReleaseのzipを展開し直すか、cloneしたリポジトリをpullして再読み込みを押す作業になる。ストア経由の自動更新はない。READMEには日次のnpmは不要とあるが、依存を増やしたくなければnode --test tests/runtime-regression.test.mjs を手元で回す程度の運用が想定される。
ライセンスはMIT。拡張のコードを改変して再配布することも、社内でforkすることも、条項上は妨げられていない。ただし同梱のUniverやtldrawなど、依存するライブラリのライセンスは別に確認が必要で、リポジトリのLICENSEだけでは全体を覆えない。ここは法的助言ではなく、確認先の指摘として受け取ってほしい。
鍵の管理も運用コストに入る。pagewand_providers に貼ったBYOKキーは各利用者のChromeプロファイルに残る。組織で一元管理する仕組みは用意されていない。
導入を決める前に確かめる3つのこと
最初に確かめるのはChromeのバージョンだ。135未満では読み込めず、sys.eval やページ内fetchを使うなら138以降でAllow User Scriptsを有効にする必要がある。次に、対象タブでF12を閉じた状態でCDPが通るか。CDP_BUSYが返るなら、そのタブは他の用途で占有されている。最後に、chrome:// やWeb Storeを対象にしていないか。NEED_PAGEは回避できない。
向くのは、ログイン済みの画面から表や文書を作る作業を個人で回している場合だ。鍵もデータも手元に閉じ、サーバーを立てる必要がない。向かないのは、社内配布と自動更新を前提とする組織、モデル費用を一元管理したいチーム、そしてストア掲載が調達条件になっている現場になる。
判断が割れるのは、sys をモデルのツールとして公開していない設計をどう見るかだ。認証まわりの操作をrunの中に閉じ込めるこの選択は、安全性と引き換えに、モデルが自分でログインを完結させる柔軟さを捨てている。READMEの記述からは、そこが意図的な境界線だと読み取れる。
編集部の結論
ログイン済みの画面から表や文書を取り出したいが、認証情報を外部サーバーに渡したくない個人や小規模チームに向く。逆に、社内配布や自動更新の仕組みを前提とする組織、モデル費用を一元管理したいチームには不向きで、アンパック拡張のまま各自がBYOKキーを持つ運用になる。導入前に確認すべきは3点。Chromeのバージョンが135以上か、対象タブでF12を閉じてもCDPがCDP_BUSYを返さないか、そしてsys.evalやページ内fetchを使うなら拡張詳細のAllow User Scriptsが有効かどうか。この3つが揃わないと、最初のタスクはNEED_PAGEやCDP_BUSYで止まる。
コミュニティノート