2026 年 4 月 18 日、Browser Use の共同創業者 Gregor Zunic がこう投稿した。

Introducing: Browser Harness. A self-healing harness that can complete virtually any browser task. We got tired of browser frameworks restricting the LLM. So we removed the framework.

フレームワークなし。直接 CDP。Chrome への 1 本の WebSocket。エージェントがその場で編集する helpers.py。Claude Code と Codex にドロップインできる。ツイートはここ。

これは単なるブラウザ自動化ツールではない。2026 年に AI ツーリングを静かに席巻しつつあるパターンの、これまででもっとも明快な表明だ ―― ハーネスである。

ハーネスとは何か

ハーネスとは、LLM が有用な仕事をこなせるようにするための、LLM まわりの最小限のラッパーだ。ツール面 ―― 通常はファイルシステム、シェル、ときに HTTP ―― を露出させ、あとは邪魔をしない。

2 つの形を比べてみよう。

フレームワーク	ハーネス
ワークフロー・ステップ・DAG を定義	ワークフローなし。決めるのは LLM。
基盤ツールを抽象化して隠す	生のツール（shell, CDP, fs）を露出
エージェントが何を「すべき」かを規定	エージェントが何を「できる」かを規定
タスクがテンプレに合わないと壊れる	テンプレがないので、しなやかに曲がる
バカなモデル向けに最適化	賢いモデル向けに最適化

2023 年にはフレームワークが理にかなっていた。モデルが生の能力を任せるほど信頼できなかったから、レールを敷いていた。LangChain、AutoGPT、CrewAI ―― どれも「この LLM の手を引いてパイプラインを通してやる」のバリエーションだ。

モデルは賢くなった。レールは節約する以上のコストを食い始めた。

Claude Code が最初の本物のハーネスだった

Claude Code は 2025 年初頭、過激なデザインで出てきた ―― オーケストレーションなし、プランナー・モジュールなし、メモリ・グラフなし。ただ Bash、Read、Edit、Write、Grep と数個の Web ツールを持つ LLM。それだけ。

賭けは、ファイルシステムへのアクセスとシェルを与えれば、十分に賢いモデルは自分でオーケストレーションできる、というものだった。そしてできた。Karpathy はそれを「実際に毎日使っている唯一の AI ツール」と呼んだ。

数か月後、Codex も同じ形に着地した。モデルは違うが哲学は同じ ―― LLM にはサンドボックスとツールを与えよ、フレームワークではなく。

Browser Harness は、このパターンがブラウザ自動化に到来したものだ。Selenium 風のステップ定義や、エージェント用スキャフォルディングに包まれた Playwright 風 API の代わりに、生の Chrome DevTools Protocol 接続と、壊れたときにエージェントが書き直す helpers ファイルを得る。

それが「self-healing」の部分だ。リトライのロジックもフォールバック戦略もエラー状態のパーサもない。LLM がエラーを読み、helper を編集し、やり直す。コードベース自体が記憶である。

なぜハーネスが勝つのか

3 つのことが並行してずれた。

ツール利用が信頼できるようになった。 Claude 4 と GPT-5 は、壊れた呼び出しを拾うバリデータ層が不要なほど、ツール・スキーマに一貫して従う。
コンテキスト・ウィンドウが希少ではなくなった。 100 万トークンのコンテキストは、コードベース全体、DOM 全体、ドキュメント全体を丸ごと積めるということ ―― 事前チャンクせず、モデルに読み返させられる。
モデルが復旧を覚えた。 呼び出しが失敗したとき、現代の LLM はツールを編集し、新しい helper を書き、あるいはアプローチを変える。フレームワークの作者はその復旧ロジックを手で書いていた。モデルのほうがうまい。

この 3 つが真になった瞬間から、LLM と生のツールのあいだにある抽象化の層はすべて負債だ。あなたがメンテし、モデルが回避しなければならず、タスクがパターンから少し外れた瞬間に壊れるコードだ。

Greg の一文が物語る ――「機能しないタスクを見つけてみろ、と挑戦する」。フレームワークには既知の故障モードがある。ハーネスにはない ―― あるいは、その故障モードは LLM 自身であり、それはずっとうまくなり続けている。

2026 年のハーネス・スタック

目を細めれば、スタックが形をなしつつあるのが見える。

コーディング・ハーネス: Claude Code、Codex、Cursor のエージェント・モード
ブラウザ・ハーネス: Browser Harness（Browser Use）
リサーチ・ハーネス: Karpathy の autoresearch ―― program.md + Claude Code
データ・ハーネス: 発生中 ―― DB への直接アクセス + シェル

共通の形: LLM + 生のツール + 永続的な作業ディレクトリ。作業ディレクトリは、コンテキストが積み上がる場所、helper が書かれる場所、ターンをまたいでモデルの記憶が生きる場所だ。

ハーネスはコンテキストの上で動く

これらのツールで何かを作っているなら重要なのはここだ ―― ハーネスの良し悪しは、渡すコンテキストの良し悪しに比例する。

CLAUDE.md のない Claude Code は汎用のコーディング・アシスタントだ。よく手入れされた CLAUDE.md と、参照ドキュメントのライブラリと、grep できる知識フォルダを備えた Claude Code ―― それが Karpathy が使っているものだ。10x 版はそれ。

Browser Harness も同じ。その場で編集される helpers.py はどこかから始まる。そのどこかに、パターン、認証フロー、あなたが文書化したサイト固有の癖を蒔けば ―― ハーネスはレバレッジを得る。空のファイルを渡せば、すべてを再発見しなければならない。

仕事をするのはハーネスだ。あなたのアドバンテージは、コンテキスト・ライブラリに宿る。

Save はどこにはまるのか

これまで話したハーネスはどれもディスクから Markdown を読む。CLAUDE.md、AGENTS.md、参照ドキュメント、保存したドキュメントページ、API のメモ ―― すべて Markdown、すべてエージェントから見えるフォルダにある。

Save は、任意の Web ページをワンクリックできれいな Markdown に変換するツールだ。ドキュメントページ、ブログ記事、Stack Overflow の回答、GitHub の README、API リファレンス ―― 次に走らせるハーネスが読む必要のあるものは何でも。

2026 年に Claude Code と Browser Harness から最大の成果を引き出している人たちは、フレームワークをさらに作り込んではいない。より良いライブラリをキュレートしている。ハーネスはタダだ。コンテキストこそが堀だ。

Save は、あなたの AI ハーネスが読める Markdown に、任意の Web ページを変える ―― 拡張機能をインストールして、エージェントを賢くするライブラリを育て始めよう。