Steel Browser レビュー: Chrome を API 化するセッション管理層の実像

Steel Browser が埋めるのはブラウザ運用の配管部分

AI エージェントに Web を操作させるとき、モデルやプロンプトの設計より先に詰まるのは Chrome の運用です。プロセスをどう起動し、Cookie と localStorage をリクエストをまたいでどう保ち、どの IP から出て、使い終わったプロセスをいつ殺すか。README はこの部分を「インフラを気にせず Web を自動化する」ためのブラウザサンドボックスと位置づけ、セッション、ページ、ブラウザプロセスの管理を Steel 側が引き受けると説明しています。対象読者は、Puppeteer や Playwright を直接叩いた経験があり、その上に自前のセッションプールを書き始めて保守に疲れた層です。ブラウザ自動化の入門者向けではありません。

Puppeteer と CDP を土台にしたセッション抽象

内部の制御は Puppeteer と CDP で、README は「Chrome インスタンスを完全に制御する」ためにこれらを使い、Puppeteer、Playwright、Selenium のいずれからでも接続できると述べています。つまり Steel は独自のブラウザ実装を持つわけではなく、Chrome の上に HTTP のセッション層を被せたものです。セッションはブラウザの状態、Cookie、localStorage をリクエスト間で維持し、プロキシチェーンは IP ローテーションのために組み込まれ、Chrome 拡張も読み込めます。デバッグ用にリクエストログとセッションを閲覧する UI が同梱され、Swagger UI は http://0.0.0.0:3000/documentation で参照できると README にあります。ページを Markdown、readability、スクリーンショット、PDF に変換する API も用意されているため、LLM に読ませる前処理を Steel 側で済ませる構成が取れます。

起動は Docker 1 行か npm run dev か

最短はビルド済みイメージです。docker run -p 3000:3000 -p 9223:9223 ghcr.io/steel-dev/steel-browser で、3000 が API と UI (http://localhost:3000/ui)、9223 がコンソールデバッガに割り当てられます。API と UI を分けて動かすなら docker compose up、Mac Silicon では DOCKER_DEFAULT_PLATFORM=linux/arm64 docker compose up を README が指定しています。ソースから動かす場合は npm install と npm run dev で、サーバーが 3000、UI が 5173 です。この経路では Chrome の実行ファイルが既知のパスに必要で、Linux は /usr/bin/google-chrome、macOS は /Applications/Google Chrome.app/Contents/MacOS/Google Chrome、Windows は Program Files 配下の chrome.exe が確認されます。別の場所に置いている場合は export CHROME_EXECUTABLE_PATH=/path/to/your/chrome を設定してから npm run dev を実行します。判定ロジックは api/src/utils/browser.ts にあると README が示しているので、パスが通らないときはここを読むのが早道です。

コントリビュータ向け compose ファイルが分かれている理由

開発時は docker-compose.yml ではなく docker-compose.dev.yml を使う、と README は明示しています。前者はビルド済みイメージを前提にし、後者は api と ui の各ディレクトリからイメージをビルドして、サーバーを 3000、UI を 5173 で動かします。ローカルの変更を反映させるには docker compose -f docker-compose.dev.yml up --build のように --build を毎回付ける必要があり、付け忘れると古いイメージのまま起動して変更が消えたように見えます。カスタムホストで動かす場合は .env を作成するか docker-compose.dev.yml の環境変数を書き換える、と README は案内し、変数の一覧は docs/DEVELOPMENT_SETUP.md にあるとしています。ここは README 内で唯一、環境変数の全体像が本文に列挙されていない箇所で、実際に何が設定できるかはリポジトリ内のファイルを読むまで確定できません。

stealth とフィンガープリントは主張であって保証ではない

README のハイライトには Anti-Detection として stealth プラグインとフィンガープリント管理が挙げられています。ただしプラグインの名称、適用範囲、どの検知手法に対して有効かは README からは読み取れません。ボット検知は対象サイト側の実装に依存するため、この項目を理由に採用を決めるのは順序が逆です。検証すべきは、自分の対象ドメインに対して実際にセッションが通るかどうかであり、それは Steel のドキュメントではなく対象サイトへのリクエストでしか分かりません。同様に、リソース管理として挙げられている自動クリーンアップも、アイドル判定の閾値やタイムアウト値が README には記載されていません。長時間動かすワークロードでは、プロセスがいつ回収されるかを実測するまで設計に組み込まないほうが安全です。

向かないケース: ブラウザを自分で握りたいとき

Steel は Chrome の起動とライフサイクルを自分で管理する代わりに、その制御を Steel に渡す契約です。したがって、起動フラグを細かく調整したい、CDP の生のセッションに直接コマンドを送りたい、あるいは Chrome のバージョンを特定のビルドに固定して再現性を取りたい用途では、抽象化の層が障害になります。比較対象として Puppeteer を単体で使う構成を挙げると、違いは状態の置き場所です。Puppeteer ではセッションの永続化、プロキシのローテーション、プロセスの回収をアプリケーション側が持ちます。Steel はそれを HTTP の背後に移し、複数の言語やプロセスから同じブラウザ状態に触れるようにします。裏を返せば、単一プロセスの単一スクリプトで完結する処理に Steel を挟むと、Docker イメージ、API サーバー、UI という 3 つの可動部分が増えるだけで、得るものがありません。

Apache-2.0 と beta 表記が意味する運用上の前提

ライセンスは Apache-2.0 で、改変と再配布、商用利用が許容される条項構成です。ただし特許条項や帰属表示の扱いは自社の法務が確認すべき領域で、ここで法的な判断はしません。運用コストとして読み取れるのはリリースの刻みで、v0.5.2-beta が 2026-03-15、v0.5.3-beta が 2026-04-24、v0.5.4-beta が 2026-08-25 と、およそ 1 か月から 4 か月間隔です。すべて beta 表記のままで、README 自身も「public beta であり毎日進化している」と書いています。API の破壊的変更を前提にバージョンを固定して追従する運用計画を立てる必要があり、追従を止めればセキュリティ修正から離れることになります。アップグレードのたびに docker compose -f docker-compose.dev.yml up --build でイメージを作り直し、セッションの挙動が変わっていないかを確認する手順が現実的です。

編集部の結論

採用を検討すべきなのは、AI エージェントや自動化ツールのために Chrome のプロセス管理、セッションの永続化、プロキシ経由の接続を自前で書くコストを避けたいチームです。逆に、ヘッドレス Chrome の起動オプションやフィンガープリントを 1 バイト単位で制御したい場合、あるいは 1 プロセスで数千の同時セッションを扱う設計を前提にしている場合は、Steel の抽象化が邪魔になります。導入前に確認すべきは 3 点で、第一に自分が対象とするサイトで stealth 系プラグインが実際に検知を回避できるか、第二に docker compose up で立ち上げた API の /documentation にあるエンドポイントが自分のユースケースを覆うか、第三に Apache-2.0 の範囲で自社の改変を閉じて運用できるかです。バージョンが v0.5.4-beta と beta 表記のままである点も、本番投入の判断材料として残ります。

公式情報源

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. steel-dev/steel-browser on GitHub