Puppeteerとは
Puppeteerとは、Googleが開発したNode.jsライブラリで
読み: パペティア
Googleが開発したNode.jsライブラリで、ChromeおよびChromiumブラウザをプログラムから操作できる。Chrome DevTools Protocolを直接利用するため、Seleniumよりも高速に動作し、スクリーンショットの撮影、PDF生成、E2Eテスト、Webスクレイピングなど幅広い用途に対応する。
かんたんに言うと
Chromeブラウザを裏側で操る糸のついた人形師のようなもので、画面を開かずにWebページの操作やデータ取得をプログラムで実行できる。名前の由来も「操り人形師」である。
SeleniumとPuppeteerを分けるChrome DevTools Protocolの直接制御
PuppeteerとSeleniumの根本的な違いはブラウザとの通信方式にある。SeleniumがWebDriverという仲介役を挟むのに対し、PuppeteerはChrome DevTools Protocolに直接接続する。開発者ツールのコンソールで実行できる操作を、そのままプログラムから呼び出せるイメージである。
この直接接続のおかげで、ネットワークリクエストの傍受、Cookieの操作、コンソールログの取得、パフォーマンスメトリクスの収集といった低レベルな操作が標準でサポートされている。
Headlessモードで起動すれば画面を表示せずにバックグラウンドで処理が走るため、サーバー上での自動実行に向いている。CI環境やDockerコンテナとの相性もいい。
Webスクレイピングとデータ収集
シングルページアプリケーションの普及で、ページの中身がJavaScriptで動的に描画されるサイトが増えた。HTTPリクエストを送ってHTMLを取得するだけでは、肝心のコンテンツが空の状態で返ってくる。
Puppeteerはブラウザを実際に動かしてページをレンダリングするため、JavaScriptが生成したコンテンツも含めて取得できる。スクロールして追加コンテンツを読み込む、ボタンを押してモーダルを開く、フォームに入力して検索結果を取得する。人間の操作をそのまま再現できる。
機械学習の学習データを収集する用途にも使われるが、サイトの利用規約やrobots.txtを無視したスクレイピングは法的リスクを伴う。
E2Eテストの実務と限界
PuppeteerでE2Eテストを書く場合の典型的な流れは、ページを開き、要素を待機し、操作し、結果を検証するというサイクルになる。waitForSelectorで要素の出現を待ち、clickで操作し、スクリーンショットを撮って目視確認するか、テキスト内容を取得してアサーションをかける。
Seleniumに比べてセットアップが簡単で、npm installだけでChromiumが付属してくる。環境構築でハマることが少ない。
ただし、PuppeteerはChromium系限定である。FirefoxやSafariでの動作確認が必要なプロジェクトには向かない。この制約を解消したのがMicrosoftのPlaywrightで、Chrome、Firefox、WebKitの3エンジンに対応しつつ、PuppeteerのAPIに近い使い勝手を実現している。新規プロジェクトではPlaywrightを選ぶ開発者が増えているが、Puppeteerのエコシステムとドキュメントの蓄積は依然として厚い。
AIエージェントとの連携
AIエージェントが「Webを調べてきて」と指示された場合、実際にブラウザを操作してページを閲覧する必要がある。ここでPuppeteerが裏方を務める。
Browserbaseのようなサービスは、LLMがPuppeteer経由でブラウザを操作し、検索結果を読み取ったりフォームに入力したりする仕組みを提供している。AnthropicのComputer Useはアプローチが異なり、スクリーンショットを撮影して画面上の座標をもとに操作する方式を採用しており、Puppeteerは使用していない。人間がブラウザで行う情報収集をAIが代行する構図である。
この分野は急速に発展しているが、ブラウザ操作の不安定さがボトルネックになりやすい。ページの読み込みタイミングのズレ、ポップアップの出現、CAPTCHAによるブロックなど、人間なら直感的に対処できる問題にAIはまだ弱い。完全な自動化と割り切るよりも、失敗したら人間にエスカレーションする設計のほうが現実的である。
当社の見解
当社はOpenAI APIを完全廃止し、EmbeddingもLLMも全てローカルで稼働させている（2026年4月時点）。これにより月額のAPI費用がゼロになっただけでなく、機密情報や顧客データを外部に送信せずにAI処理できるようになった。クライアントのログデータをマスキングなしでそのまま分析に回せるのは、ローカルLLMだからこそ実現できる。2026年4月にはOllama常駐実行（CPU 25%、GPU 30%を常時占有）を廃止し、FastEmbed（ONNX Runtime）による非常駐型推論に移行。処理が必要な瞬間だけプロセスを起動し、完了後に即座に終了する設計で、アイドル時のリソース消費をゼロにした。あえて一般的なデスクトップPC環境で複数のローカルLLMを実機検証した経験から言えることは、ベンチマークスコアと実務での使い勝手、そして常駐時のリソース消費は全て別の指標だということだ。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。