Claude CodeでAIが自らコードを修正しブラウザ操作する時代、エンジニアが次に備えるべき設計術

AIが「操作」を捨てて「プログラミング」を始めた日

AIエージェントの進化がエンジニアの領域に踏み込んでいる。

これまでのAIはブラウザ画面を見てクリック指示を出す存在だった。

その時代は終わった。

最新の研究では、AIが自らPlaywrightのコードを書き、ターミナルからブラウザを制御し、エラーが出ればその場でデバッグして修正する。

AIが自分自身の改善ロジックすら書き換えるフェーズに突入した。

既存モデルをどう動かすかというアーキテクチャの勝利だ。

開発者はAIが自律的に動ける環境を設計する立場に変わる。

3つのニュースを統合して解き明かす。

ターミナル駆動と標準化プロトコルが変えるAIエージェントの正体

AIエージェントの世界でWebwrightというフレームワークが発表された。

AIにブラウザ操作画面ではなくターミナルを渡した点が特徴だ。

従来のエージェントはスクリーンショットやDOM構造を解析し、クリック箇所を予測していた。

この方式はモデルの推論能力に依存し、画面変化で壊れやすい。

WebwrightはAIにPlaywrightのスクリプトを書かせる。

AIはターミナル上でbashコマンドを叩き、ブラウザを制御するコードを生成する。

実行結果のログを見てAIは自らコードを修正する。

このシフトにより、タスクの成功率は33.5%から60.1%へ向上した。

システム構成はシンプルだ。

実行を担うランナーは150行、モデルとのインターフェースは550行、環境構築は300行程度である。

単一のループの中で思考、コード生成、実行、修正を完結させている。

AIが外部データにアクセスするための道も整備されている。

あるプラットフォームがMCP（Model Context Protocol）に対応したサーバーを公開した。

MCPはAIモデルと外部ツールを繋ぐ共通規格だ。

これまでAIにデータを読み込ませるには、開発者が個別にAPI連携コードを書き認証処理を実装する必要があった。

このプラットフォームが公式にMCPサーバーを提供したことで、ユーザーは自分のアカウント権限を使ってAIツールから直接データを読み込める。

このツールは読み取り専用に設計されている。

AIの自律性を高める一方で、プラットフォーム側が暴走を防ぐガードレールを敷いている。

AIの自己改善についても進展がある。

Hyperagentsと呼ばれる新しいフレームワークが登場し、AIが自分自身のコードを書き換える能力が強化された。

これまでの自己改善システムは人間が設計したルールに従うだけだった。

Hyperagentsはルール自体をAIが書き換えられるようにした。

タスクを解くAIとAIを改善するAIを一つのプログラムとして統合し、メタレベルでの自己修正を可能にしている。

しんたろー：
Webwrightの「ターミナルさえあればいい」という思想が気になる。
GUIを操作させるよりコードで制御させたほうが速く確実だ。
Claude Codeで開発していると、AIがテストコードを書いて実行し、エラーが出れば直す様子を見て、もう人間いらねーなと思った。
150行のランナーで世界が変わるという発想が面白い。

開発者目線で読み解く「指示」から「環境設計」への転換

AI開発の主戦場がプロンプトエンジニアリングからシステムアーキテクチャ設計に移行した。

AIに正しい指示を出すことには限界がある。

AIが動く環境が整っていなければ、複雑なタスクは完結しない。

Webwrightが証明したのは、AIにプログラミングという武器を持たせる強さだ。

AIに「このボタンを押して」ではなく、「このボタンを押すための堅牢なスクリプトを書いて実行して」と命じる。

この抽象化がエージェントの信頼性を引き上げている。

開発者がやるべきことは、AIが使いやすいライブラリや関数を用意しておくことだ。

Playwrightのような標準的なツールをAIが自由に使えるように権限を与え、失敗した時のログを詳細に返す。

AIが失敗理由を理解できる環境を作ることが今のエンジニアのスキルだ。

MCPの普及がもたらす影響を考える。

巨大プラットフォームがMCPを採用したことは、今後あらゆるSaaSがMCPサーバーを公開する流れの決定打になる。

これはAIにとってのUSB規格だ。

外部APIとの連携は常に頭の痛い問題だった。

各サービスがMCPを提供すれば、AIはどのAPIをどう叩くかを悩む必要がなくなる。

共通プロトコルを通じて、安全かつ迅速にデータを取り込めるようになる。

プラットフォーム側が書き込み権限を制限している点が面白い。

AIが勝手にスパムを投稿したり、データを破壊したりするのを防ぐための最後の砦だ。

AIに全権を与えるのではなく、読み取りは自由だが書き込みは人間が承認するハイブリッドな設計が重要になる。

Hyperagentsが示す自己改変の未来がある。

AIが自分のロジックを書き換えるのは開発効率を極限まで高める可能性を秘めている。

開発中のSaaSのパフォーマンスが落ちたとき、AIが自らプロファイリングを行い、ボトルネックを見つけ、最適化されたコードに書き換える。

システムが勝手に進化していく。

これにはサンドボックス環境での厳格なテストが不可欠だ。

AIが生成したコードが既存のシステムを壊さないか、セキュリティホールを作らないか監視する番人としてのシステムの設計が今後のコア技術になる。

しんたろー：
MCPでXのデータが読みやすくなったのは地味にデカい。
書き込み不可という制限がついているのが、今のAIへの期待と不安を表していると感じた。
APIの制限は敵ではなく、AIの暴走を防ぐ防波堤に見えてきた。
自由すぎると壊れ、不自由すぎると使えない、その塩梅をコードで書くのが僕らの仕事だと思った。

僕らの開発ワークフローをどうアップデートすべきか

エンジニアは「AIが実行可能なコードベース」を意識して設計を始める。

ブラウザ操作や外部連携を伴う機能を実装する場合、最初からPlaywrightやPuppeteerなどの自動化ツールを前提にしたコード構造にする。

AIがそのコードを読み、理解し、拡張できるように、命名規則やモジュール分割を徹底する。

AIが読みやすいコードは、結果として人間にとってもメンテナンスしやすいコードになる。

ローカル環境でAIが自由にbashコマンドを実行できるClaude Codeのようなツールを使い倒し、AIにどこまで任せられるかの境界線を自分の中で引き直す必要がある。

自社サービスやツールを作る際は、MCPサーバーとしてのインターフェースを持つことを検討する。

作ったツールが他のAIエージェントからコンテキストとして参照されるようになれば、その価値は高まる。

APIを公開するだけでなく、AIが理解しやすい形式でデータを定義し、共通プロトコルに乗せる。

これが次世代のプラットフォーム戦略の基本だ。

最も重要なのが、「Human-in-the-loop（人間が介入する仕組み）」の再定義だ。

HyperagentsのようにAIが自己改変を始める時代、人間が全てのコードをレビューするのは不可能になる。

代わりに、AIが生成したコードの振る舞いをテストする自動化された検閲システムを構築する。

AIがコードを書き換えたら、即座にユニットテストと統合テストが走り、セキュリティスキャンが行われ、合格したものだけがステージング環境にデプロイされる。

開発者はコードを1行ずつ見るのではなく、その検証プロセス自体を設計・管理する役割にシフトする。

具体的なアクションアイテムを整理する。

1. Playwrightの基本をマスターし、ブラウザ操作をコードで表現する癖をつける。
2. MCPの仕様を確認し、自分の開発ツールにどう組み込めるかプロトタイプを作る。
3. AIにコードを書かせる際、必ずテストコードもセットで生成させ、実行結果をフィードバックするループを定着させる。
4. 権限管理（IAM）を厳格にし、AIエージェントに渡すトークンの権限を最小限に絞る。

AIは単なるチャット相手ではない。

ターミナルを操り、ネットワークを駆け巡り、自らをアップデートし続ける「デジタル・エンジニア」だ。

この新しい同僚とどう共生するか、その答えは僕らの設計思想の中にある。

しんたろー：
エンジニアの仕事は抽象度の高いパズルになっていく。
昔は1行のコードを書くのに必死だったが、今はAIが正しく動くためのレールをどう敷くかに頭を使っている。
コードを書く楽しみが奪われる寂しさはあるが、AIが勝手にバグを直してくれた時の万能感は異常だ。
この波に乗らない手はない。

AIエージェントの進化に関するFAQ

Q1: Webwrightは既存のブラウザ自動化ツールと何が違うのか？

Webwrightの最大の特徴は、AIが操作ではなくプログラミングを行う点にある。

従来のツールはAIが画面上の要素を認識してクリックなどの低レベルなアクションを一つずつ予測していたが、WebwrightはPlaywrightのコードを丸ごと生成して実行する。

これにより、ループ処理や条件分岐、複雑な待機ロジックをAI自身がプログラムとして記述でき、ネットワークの遅延や画面の動的な変化に対しても堅牢な動作が可能になる。

ターミナル経由で実行ログを直接確認し、エラーがあれば即座にコードを修正する自己修復サイクルを持っている点も特徴だ。

Q2: MCPサーバーを使うと何が便利になるのか？

MCP（Model Context Protocol）は、AIモデルと外部データを繋ぐための共通の言語（プロトコル）である。

これまでは、例えばAIにSlackやNotionのデータを読み込ませたい場合、開発者がそれぞれのAPI仕様を理解し、個別に連携コードを書く必要があった。

MCPに対応したサーバーが提供されると、AIツールにそのサーバーを登録するだけで、即座に安全なデータ連携が可能になる。

開発者はインフラや認証の構築に時間を取られることなく、AIを活用した本質的な機能開発に集中できる。

Q3: AIが自身のコードを書き換える「Hyperagents」は危険ではないか？

自己改変能力は、無限ループや予期せぬ挙動、セキュリティ上のリスクを伴う。

Hyperagentsの研究では、AIの実行環境と改善ロジックを分離し、厳格な管理下で動作させる手法が取られている。

実務においては、AIが提案した改善案をいきなり本番環境に適用するのではなく、隔離されたサンドボックス環境でテストを行い、最終的なデプロイ判断に人間が介在する設計（Human-in-the-loop）を組み合わせる。

AIの自律性を活かしつつ、人間がポリシーと検証を制御することが安全な活用の鍵だ。

まとめ

AIエージェントは大きな転換点を迎えている。

Webwrightによるコード駆動のブラウザ操作、MCPによる外部連携の標準化、そしてHyperagentsによる自己改変。

これら3つの要素が組み合わさることで、AIは単なるツールから、自らツールを作り改善するエンジニアへと進化する。

開発者に求められるのは、彼らが存分に力を発揮できる「安全で高機能な土壌」を設計することだ。

コードを書く技術は、AIを制御し、その出力を検証するための技術へと昇華される。

面倒な定型業務をAIに丸投げし、僕らはもっとクリエイティブな設計に没頭する。

AIエージェントが自らコードを書き換える時代、あなたの開発ワークフローをThreadPostで次世代へアップデートする。

👉 ThreadPostでSNS運用を自動化する