notte: ローカル実行とホスト型セッションを同じAPIで切り替えるWebエージェント基盤

notteが埋めるのは「ブラウザ操作の決定性とAIの柔軟性の間」

Web自動化の現場では、セレクタで固定したスクリプトは壊れにくい代わりにサイト変更へ弱く、LLMに全部任せるとコストと再現性の両方が読めなくなる。notteはこの中間を狙っていて、READMEでは「script deterministic parts and use AI only when needed」と説明され、決定的な部分はスクリプト、判断が必要な部分だけAIに寄せる形を想定している。対象読者は、AIコーディングエージェントに外部サイトを操作させたい開発者と、既存のPlaywright資産を活かしつつ自然言語タスクを足したい自動化担当者になる。

Agent・Session・Vault・Personaという4つの登場人物

中心になるのはSessionとAgentで、READMEのローカル例ではnotte.Session(headless=False)をwithで開き、その中でnotte.Agent(session=session, reasoning_model='gemini/gemini-2.5-flash', max_steps=30)を作ってagent.run(task=...)を呼ぶ。推論モデルはreasoning_modelという文字列で指定し、試行回数の上限はmax_stepsで切る。この2つが骨格で、VaultとPersonaはAgentに付随するツールとして渡す形になっている。Vaultはadd_credentials(url=..., username=..., password=...)で資格情報を預け、READMEによればエージェントが必要な場面で自動的に使う。Personaはcreate_phone_number=Falseのような引数を持ち、固有のメールアドレスや電話番号、2FA処理をまとめたデジタル身元として説明されている。

ローカルとホスト型を同じ形で書ける理由と、その境界

READMEが繰り返し述べる設計上の売りは、ローカルで試したコードのimportを差し替え、notteオブジェクトにcliの接頭辞を付けるだけでホスト型セッションに移行できるという点だ。ローカル側は自分のLLM APIキーが必要で、ホスト側はconsole.notte.ccで発行するNOTTE_API_KEYを使い、NotteClient(api_key=os.getenv("NOTTE_API_KEY"))からclient.Session(open_viewer=True)を開く。ただし両者は等価ではない。CAPTCHA解決、プロキシ、検知回避、Vault、PersonaはREADME上でAPI service側の機能として並んでおり、ローカルモードで同じ挙動が得られるとは書かれていない。ここは移行コストを読み違えやすい箇所で、ローカルで通ったタスクがホスト側の機能なしで本番に耐えるかは別問題になる。

構造化出力はPydanticモデルをそのまま渡す

スクレイピング結果を後段の処理に流すなら、文字列ではなく型が欲しい。notteはagent.runのresponse_formatにPydanticモデルを渡す仕組みを用意している。READMEの例ではHackerNewsPostとTopPostsという2段のモデルを定義し、taskに「トップ5件のタイトル、URL、ポイント、投稿者、コメント数を抽出せよ」と書いてresponse_format=TopPostsを渡し、結果をresponse.answerで受け取る。抽出対象のフィールドをモデル側で固定できるため、LLMの出力ゆれをスキーマで吸収できる。もっとも、サイト側の表記がモデルの型と合わない場合の挙動やリトライの詳細はREADMEには書かれておらず、この点は実測しないと分からない。

ベンチマーク表は自社リポジトリの数字として読む

READMEにはNotte、Browser-Use、Convergenceを並べた比較表があり、NotteがAgent自己申告86.2%、LLM評価79.0%、タスクあたり47秒、信頼度96.6%と記載されている。出典としてnottelabs/open-operator-evalsが示され、評価ハーネス自体が別リポジトリで公開されている点は、数字を鵜呑みにせず追試できるという意味で評価できる。ただしこれは提供元自身が公開する評価であり、第三者の独立検証ではない。タスクあたり47秒という値も、どのサイト群・どのモデル設定での計測かはこの表だけでは判断できない。導入検討では、自分の対象サイトで同じタスクを走らせて時間と成功率を測るほうが早い。

向かない場面と、代替となる選択肢

向かないのは、単一サイトへの定型的なフォーム送信やデータ取得を安定して回したいだけのケースだ。セレクタが固定できるなら素のPlaywrightで足り、LLMの推論コストとmax_stepsの調整を持ち込む理由が薄い。もう一つの障壁はライセンスで、READMEのバッジはSSPL-1.0を示している。リポジトリのメタデータ上はNOASSERTION扱いなので、実際に適用される条件は配布物のLICENSE表記を確認する必要がある。代替としてはPlaywrightそのものが最も素直な比較対象になる。違いは意思決定の所在で、Playwrightはセレクタと待機条件を人間が書き切るのに対し、notteはreasoning_modelに判断を委ね、max_stepsで打ち切る。サイト構造が頻繁に変わるならnotte側の利点が出るが、構造が安定しているならPlaywrightのほうが実行時間も費用も読みやすい。

導入前に確認すべき配布とライセンスの論点

パッケージはPyPIのnotteとして配布され、Python 3.11以上が要求される。ブラウザ側はpatchright install --with-deps chromiumという別コマンドで導入する構成で、Playwright互換のプリミティブを使うとREADMEは説明している。つまり依存はPythonパッケージだけでは完結しない。ライセンス面ではSSPL-1.0が示されており、これはサービスとして提供する形態に条件が及ぶ種類のライセンスだが、具体的な義務の範囲は法的判断であり、ここで断定はしない。リポジトリのメタデータがNOASSERTIONである以上、採用前にLICENSEファイルと配布物の表記を突き合わせておくべきで、これは技術選定ではなく契約と法務の作業になる。

更新頻度から見る追従コスト

直近のリリースはv1.8.41、v1.8.40、v1.8.39が2026年9月7日から9日にかけて並んでおり、日次に近い間隔でパッチ版が上がっている。活発である一方、マイナー番号が同じまま細かく版が進むため、固定したバージョンで挙動を確認してから上げる運用のほうが安全だろう。エージェントの出力は推論モデル側の更新にも影響されるので、notteの版とreasoning_modelの指定をセットで記録しておかないと、失敗の原因がどちらにあるか切り分けられなくなる。

編集部の結論

自前のLLM APIキーとPlaywright系ブラウザを用意できるチームが、まずローカルモードでAgentとSessionの挙動を確かめる用途に向く。CAPTCHA突破やプロキシ、Vault、Personaといったホスト側の機能に依存する設計を最初から前提にするなら、NotteClientとNOTTE_API_KEYの契約条件を確認したうえで判断すべきで、SSPL-1.0の下で自社サービスに組み込む形態が許容されるかは法務判断が要る。検証の第一歩はpip install notteとpatchright install --with-deps chromiumを実行し、同じタスクをnotte.Agentとclient.Agentの両方で走らせて差分を取ることになる。

公式情報源

1. Issues
2. nottelabs/notte on GitHub
3. Project website
4. README
5. Releases