AIに設定画面の実装を任せるとき、見た目が整うだけでは業務で使える画面にはなりません。キーボードで項目を移動できるか、選択を解除した後にフォーカスが適切な場所へ戻るか、支援技術に必要な情報が伝わるか。画面の品質は、こうした細かな操作の積み重ねで決まります。

Vercel Labsが公開したオープンソースのベータ版「UI SDK」は、この操作の仕組みをAIコーディングエージェントへ渡すライブラリです。中心となるのは、完成済みの見た目を持つ部品ではなく、フォーカス管理、選択、ポップアップ、ドラッグ＆ドロップなどの「振る舞い」です。エージェントはそれらを組み合わせ、用途に合うコンポーネントを構築します。



仕組みを理解するには、選択欄を考えると分かりやすいでしょう。完成したSelect部品をそのまま渡す代わりに、ポップアップ、選択状態の管理、文字入力による候補への移動を提供します。同じ要素の組み合わせから、入力候補を提示するオートコンプリートや、入力と選択を兼ねるコンボボックスにも展開できます。

この設計で注目したいのは、AIが画面を自由に作ることと、操作の基本を毎回作り直すことを切り離している点です。業務に合わせて画面構成を変えながら、共通する操作にはライブラリの仕組みを使えます。ただし、部品を採用すれば画面全体の使いやすさまで自動的に保証されるわけではありません。組み合わせた結果が実際の利用者に適しているかは、実装後の確認が必要です。

UI SDKは、表示スタイルを主目的にしない「ヘッドレス」なライブラリです。振る舞いを担う中心部分は@ui-sdk/coreに集約され、各フレームワーク向けの薄いアダプターが画面への描画を受け持ちます。公開情報では50種類以上の振る舞いと、リポジトリー内の51のコンポーネントモジュールが紹介されています。

実装の出発点になるのは、definePrimitiveで定義する基本単位です。ここに状態、外部から操作するためのAPI、画面内の各部分に対応するスロットを宣言します。スロットにはDOM要素の属性、イベント、振る舞いを関連付けます。DOMはブラウザーが画面を構成する要素の仕組みで、スロットは操作の定義を実際の入力欄やボタンへ結び付ける役割を担います。



各フレームワークではcreatePartsを使って、この定義を描画します。READMEによると、パーツの扱いは5種類のアダプターで共通しており、一つの振る舞いの定義をReactアプリとSvelteアプリの双方で利用できます。画面の表示方法と操作ロジックを分けることで、操作の定義を共有しやすくする設計です。既存画面を無条件で別のフレームワークへ移せる、という意味ではありません。

対応先はReact、Vue、Svelte、Solid、Web Componentsです。公開時の要件はReact 19以降、Vue 3.5以降、Svelte 5.33以降、Solid 2.0.0-rc.14以降とされているため、既存システムへの導入ではバージョンの照合が欠かせません。動作にはモダンブラウザーを使い、GPUは不要です。任意のweb.cssを読み込めば標準的な外観も付けられますが、企業独自のデザインへの適合は別途検討する必要があります。

UI SDKが提供する振る舞いには、マウスで試すだけでは見落としやすい操作が含まれます。例えばcreateRovingFocusは、リスト全体へのTabキーによる移動先を一つにまとめ、リスト内では矢印キーで項目を移動させます。createTypeaheadは、数文字を入力すると該当する項目へ移る機能です。項目数が多いメニューや選択欄では、クリック以外の操作経路が使い勝手を左右します。

createPopupは起点となるボタンなどの近くで開き、画面内に収まるようにするための仕組みです。createSelectionは単一選択と複数選択を扱い、ShiftキーやCtrlキーを使う操作も含みます。このほか、並べ替え、サイズ変更、表示領域、仮想化を扱う振る舞いも紹介されています。仮想化は、大量の項目を扱う際に、表示に必要な範囲を中心に描画するための考え方です。



アクセシビリティに関しては、ARIAに必要な情報も扱います。ARIAは、画面上の部品の役割や状態などを支援技術へ伝えるための仕組みです。視覚的には同じ選択欄でも、開閉状態や選択状態が適切に伝わらなければ、利用者によって操作の理解しやすさに差が生まれます。見た目と内部状態を結び付ける作業は、UI開発の実務で省きにくい部分です。

ただし、ライブラリが個別の振る舞いを提供することと、完成画面のアクセシビリティが検証済みであることは区別すべきでしょう。ラベルの付け方、画面全体の移動順、エラーの伝え方は、組み合わせる側の設計にも依存します。日本企業で試す場合は、普段のマウス操作に加え、キーボードだけで目的の処理を終えられるかを確認すると、導入効果と残る課題を具体的に把握できます。

UI SDKの特徴は、画面を作るための支援だけにとどまりません。実行中の画面をエージェントが操作するためのブリッジも用意しています。画面描画の前にcreateAgent()で接続を作ると、agent.snapshot()からコンポーネントの一覧、現在の状態、利用できる操作を取得できます。agent.act()は、その操作を実行するためのAPIです。

例えば、プロジェクト名を変更する場合には、setValueのような操作を使えます。スクリーンショットから入力欄の位置を読み取る手順だけに頼らず、画面が公開する状態と操作を利用する考え方です。人が使う画面の背後に、エージェントも理解できる操作の窓口を設ける、と捉えるとイメージしやすいでしょう。



アプリケーション側には操作を制御する仕組みもあります。allowコールバックで操作を許可または拒否でき、変更通知にはsource: "agent"が渡されます。これによりエージェント由来の変更を識別し、変更を取り消すことも可能です。対応ブラウザーでは、WebMCPを通じてツールを登録する方法も説明されています。

企業の業務画面では、この制御点をどこに置くかが検討事項になります。入力内容の変更と、保存による確定処理を同じ扱いにする必要はありません。既存の権限や業務ルールと照らし合わせ、どの操作を受け付けるかを設計することが求められます。ブリッジの採用だけで業務上の権限制御が完結するとは考えないほうがよいでしょう。

開発時の学習経路も整備されています。セットアップ用プロンプトでパッケージを導入し、エージェント向けの作業指示ファイルであるAGENTS.mdに案内を追加します。そこから専用スキルや、パッケージ内の文書案内であるllms.txtへ誘導します。開発時に使い方を伝える経路と、実行時に画面を操作する経路の両方を用意している点が、この設計の軸になっています。

Vercelは、UI SDKのブリッジとブラウザーツールを比較した検証結果を公開しています。対象は一つのプロジェクト設定タスクで、プロジェクト名、メンバー、通知設定を変更して保存する内容です。両条件ともClaude Code上でSonnetを使い、タスクとシステムプロンプトをそろえています。数値はそれぞれ3回実行した中央値です。

| 指標 | ブラウザーツール | UI SDKとブリッジ | 削減率 |
| --- | --- | --- | --- |
| ツール呼び出し回数 | 16回 | 5回 | 69％ |
| 読み取ったテキスト量 | 約39,800文字 | 約6,800文字 | 83％ |
| 所要時間 | 41秒 | 16秒 | 61％ |
| コスト | 0.073米ドル | 0.032米ドル | 56％ |



この結果は、構造化された状態と操作を渡すことで、エージェントの情報取得や操作の往復を減らせる可能性を示しています。画面から必要な情報を探し、対象を特定し、操作するまでの手順が短くなれば、時間や読み取るテキスト量も減ると考えられます。ただし、どの要因が削減にどれだけ寄与したかまで、この比較だけで判断することはできません。

条件にも注意が必要です。対象は一つのタスクに限られ、試行回数は3回です。ブラウザーツール側では異なるコンポーネントライブラリを使っており、Sonnetの具体的なバージョンも示されていません。開発元による自己報告であることも踏まえると、「導入すればどの業務でも61％速くなる」と読むには根拠が足りません。

自社で検証するなら、現在の画面で繰り返し発生する設定変更を選び、同じ完了条件で比較するとよいでしょう。時間とコストに加えて、保存まで正しく終えられた割合や、誤った項目を変更した回数も確認対象になります。正常終了時の速さだけでなく、入力ミスや操作拒否が発生した場面から復帰できるかを見ることで、日常業務に適した仕組みかを判断しやすくなります。

UIの振る舞いと見た目を分ける発想そのものは、UI SDKだけのものではありません。React Ariaのフックや、Ark UIの基盤であるZag.jsの状態機械も、操作の仕組みとマークアップを分離しています。状態機械は、現在の状態と操作に応じて次の状態を定める設計方法です。既存のライブラリを評価せずに、振る舞いの分離だけを理由として乗り換える必要はないでしょう。

UI SDKを比較する際の焦点は、エージェント向けスキル、同梱されたllms.txt、実行時のブリッジをどう活用できるかです。Radix PrimitivesやBase UIなどのスタイルを持たないコンポーネントと比べる場合も、画面の柔軟性だけでなく、AIが実装方法を学び、完成後の画面を操作するまでの流れを含めて評価する必要があります。他製品に同種の機能がないと断定することは避けるべきです。



提供段階にも留意したいところです。公開情報によると、6種類のパッケージは2026年11月12日にnpmへ0.1.0-beta.1として公開され、ライセンスはApache-2.0です。npmはJavaScript向けのパッケージ配布基盤です。Reactでは@ui-sdk/reactと@ui-sdk/coreを導入する形が案内されていますが、ベータ版のためAPIが変更される可能性があります。既存システムへ組み込む際は、対応バージョンと更新時の影響を確認することになります。

実務上の出発点としては、設定画面を一つ選び、人による操作とエージェントによる操作を同じ画面で検証する方法が考えられます。選択欄やポップアップを含む画面なら、振る舞いの再利用とブリッジの両方を確認しやすいでしょう。日本語入力を含む操作、キーボードでの移動、変更を拒否した際の挙動まで確かめれば、検討材料が具体的になります。

導入判断の前に決めたいのは、AIに任せる業務の範囲と、正しく完了したとみなす条件です。「指定した通知設定だけを変更し、保存結果を確認できる」といった小さな完了条件を置き、現在の方法と比べてください。その一画面で得られる手間、誤操作、保守負担の差が、適用範囲を広げるかどうかの判断につながります。