「コード生成」から「コード制御」へ——AIエージェントがブラウザ自動化ツールを操る「Steel」が示す、自動化設計の新パラダイム

業務自動化やWebスクレイピングを実装する際、最も高い壁となるのがブラウザ操作の自動化です。Puppeteer、Playwright、Seleniumといった優れたツールが存在するにもかかわらず、なぜ多くのプロジェクトが挫折するのか。その理由は「Webサイトの頻繁な変更」「要素セレクタの脆弱性」「エラーハンドリングの煩雑さ」といった、実装後の継続的メンテナンスにあります。2026年5月に注目を集める「Steel」は、この問題にAIエージェントという解決策を持ち込みます。重要なのは、AIが自動化コードを「生成」するのではなく、既存の自動化ツールを「制御」する点です。

ブラウザ自動化が抱える「メンテナンスコスト問題」

従来のブラウザ自動化は、開発者がDOM構造を分析し、CSSセレクタやXPathを駆使して要素を特定し、クリックや入力を記述していく作業でした。しかし、この手法には構造的な脆弱性があります。Webサイトがデザインを変更すれば、セレクタは無効化されます。動的に読み込まれるコンテンツは待機処理が必要で、その判定ロジックも複雑化します。結果として、自動化スクリプトの開発時間よりも、その後の保守にかかる時間の方が長くなるという逆転現象が起きているのです。

RPAツールはこの問題に「ノーコード」で対抗しましたが、柔軟性の欠如という新たな問題を生みました。複雑な条件分岐や例外処理が必要なケースでは、結局コーディングが必要になります。Steelが提示するのは、この両極端の中間地点です。

AIエージェントによる「制御層」の挿入がもたらす設計思想の転換

Steelの革新性は、PuppeteerやPlaywright、Seleniumといった既存ツールを「そのまま使いながら」AIエージェントに制御を委譲できる点にあります。開発者は自動化の大枠と目的を定義し、細部の調整や変化への対応をAIに任せるのです。これは、自動化アーキテクチャに新しいレイヤーを追加することを意味します。

具体的には、「ログインして最新の注文情報を取得する」という目的を与えると、AIエージェントがページ構造を解釈し、適切なセレクタを動的に選択し、予期しないポップアップやレイアウト変更にも対応します。従来は人間がハードコーディングしていた「要素が見つからない場合の代替手段」や「読み込み完了の判定」といったロジックを、AIが文脈理解に基づいて実行するのです。

さらにSteelは、これらの自動化をAPI化する機能も備えています。つまり、複雑なブラウザ操作を「HTTPリクエストを送るだけ」のシンプルなインターフェースに変換できるのです。マイクロサービス化が進む現代のシステム設計において、この「ブラウザ操作のAPI化」は大きな意味を持ちます。

「多少のコーディング力」が求められる理由——完全自動化への誤解

Steelは「多少のコーディング力を要求する」とされています。これは一見、参入障壁のように思えますが、実は自動化設計における本質的な要求です。なぜなら、AIエージェントに委譲できるのは「実装の詳細」であり、「何を自動化すべきか」という意図の定義は依然として人間の役割だからです。

完全ノーコードのRPAツールが直面した問題は、「抽象度の高い指示をどう解釈するか」でした。曖昧な指示は予測不能な動作を生み、結果の検証コストが上がります。Steelは、基本的なプログラミング概念（変数、条件分岐、ループ）を理解している人を対象にすることで、「意図の明確化」と「実装の柔軟性」のバランスを取っています。これは、AI時代における「人間とAIの協働モデル」の実践例と言えるでしょう。

ブラウザ自動化のAPI化が解放する「統合可能性」

Steelのもう一つの重要な機能が、自動化スクリプトのAPI化です。これにより、ブラウザ操作が必要な処理を「マイクロサービス」として他のシステムに組み込めます。例えば、SlackボットからWebサイトの情報を取得したり、定期的なデータ収集をクラウド関数でスケジューリングしたり、既存の業務システムにブラウザ操作機能を追加したりできます。

従来、このような統合には専用のサーバー構築やセッション管理、セキュリティ対策といった周辺実装が必要でした。Steelはこれらをパッケージ化し、「APIエンドポイントを呼ぶだけ」の世界を実現します。これは、ブラウザ自動化を「特殊な技術」から「汎用的なビルディングブロック」に変える試みです。

自動化の未来は「指示」ではなく「協働」にある

Steelが示唆するのは、自動化の進化は「人間の作業をすべてAIに置き換える」方向ではなく、「人間の意図とAIの適応力を組み合わせる」方向に進むということです。完全自律型のAIエージェントは魅力的に聞こえますが、現実のビジネスプロセスには無数の例外や判断基準が存在します。

Steelのようなツールが普及すれば、「自動化メンテナンスエンジニア」という役割は縮小し、代わりに「自動化アーキテクト」——AIエージェントに何をどこまで委譲するかを設計する役割——の重要性が高まるでしょう。これは、AI時代の労働市場における一つの方向性を示しています。コーディングスキルの価値は「実装速度」から「設計思想」へとシフトするのです。

ブラウザ自動化の障壁を下げるツールは数多く登場してきましたが、Steelの「既存ツール × AIエージェント制御」というアプローチは、技術的負債を最小化しながら実用性を高める賢明な戦略です。自動化の未来は、すべてをAIに任せる「完全自動」ではなく、人間が戦略を描き、AIが戦術を実行する「協働自動化」にあるのかもしれません。