最近は「人間用のブラウザ」の横で、AIエージェント専用の操作環境が一気に増えた。Vercel Labsのagent-browserに代表される流れのほか、PlaywrightにMCPが載る、CLIに統合される、OpenAIや他社のcomputer useに近い形で画面を扱う、といった具合だ。
ここで面白いのは、「生のHTMLを全部渡す」だけではない点だ。セマンティクスを読んで必要なUIだけにラベルを付けて返す、エージェント向けにMarkdownへ圧縮する、そもそも全DOMをコンテキストに流し込まない、といった設計が増えている。エージェント側のコストはコンテキストなので、圧縮は必然に近い。
ブラウザの役割が二つに割れるかもしれない
いまのWebは、エンジニアが人間向けUIを組み立て、ユーザーがそれを触る、という前提が強い。一方でエージェントが主役になると、そのUIは「人間の感覚」には合っていても「機械の実行」には不向きなことが多い。
そうなるとエンジニアが渡すものは、画面そのものより「できることの一覧」に寄っていく。MCPサーバーがやっているような、機能の列挙とスキーマ、という形だ。エージェント側がビジュアルを組み立てる、という未来もあり得る。乱暴に言えば、一覧はAPI、レイアウトはエージェント、という分業だ。
もちろん現実はそこまで単純ではない。検索したあとリストを更新する、パネル同士の依存関係を保つ、といった「UI間のルール」が抜けると人間の運用で穴埋めが発生する。ここを宣言的に書けるなら、自動組み立ての精度は上がる。逆に、ローディングを挟みながら裏で別リクエストを走らせる、といった演出は人間向けUXの核になりやすく、エージェント任せにするとリスクも大きい。読むだけ・単純な管理画面なら割と現実的だ。
CRUDと「削除」の扱い
エージェント前提で考えると、操作は狭く縛った方が安全だ。CreateやUpdateを横断的に開放しすぎない、変更できるのは特定エンティティの一部だけ、といった設計はあり得る。Deleteは特にUIと状態がズレやすいので、論理削除に寄せてUpdate一本にする、Deleteという概念自体を表に出さない、というのも現実的な落とし所だ。表示から消えてもデータは「削除済み」として整合し、以降の更新を拒否する、なら破綻は抑えやすい。
スキーマ駆動と「最初のひと押し」
結局やることは、OpenAPIのようにスキーマで「何ができて、どんなUIが向いているか」を提示することだと思う。自分で組み立てられる人には自由度を渡し、難しい人には既製のUIをファーストステップとして渡す。カスタマイズはユーザー側に任せる、という二段構えは自然だ。
Next.jsを使う自分の、いまの感覚
ここは個人的な温度感だ。Server Actionsは便利だ。ただ、サーバーコンポーネントで値を組み立て、クライアントでハイドレーションし、境界が細かく絡む実装は、長期的には追いづらさも感じる。NextやReactの設計が悪いという話ではなく、トレードオフの話だ。
エージェント時代にUIの自由度をクライアント側、ひいてはユーザー側に寄せたいなら、サーバーとクライアントはAPI境界で分けた方が筋が通る、という結論に自分は寄りがちだ。
結局、エンジニアがやることは変わらないかもしれない
サーバーから必要なデータを返す。RESTやGraphQLのようにスキーマで契約を固定する。ここはこれまでと同じだ。
変わるのは「フロントを誰が組むか」だ。これまではWebエンジニアが組んでいた。これからは、エージェントがAPIを叩いて十分なケースが増えるかもしれない。人間が見るときは、エージェントが取得したデータを読みやすい形に整形するだけで足りる局面もある。オーバーヘッドやコストは山ほどあるが、計算資源とモデルの進歩で相殺される楽観もある。
そんな世界線をぼんやり夢見ながら、新しいプロジェクトを立ち上げてみたい、というのがいまの気分だ。
コメント