Intelligent UIはGenerative UIの改名なのか

2026/10/11

Intelligent UIの登場

2026年10月7日、OpenAIがGPT-6とあわせて「Intelligent UI」を発表し、Plus、Pro、Business、EnterpriseのChatタブで段階的な提供を始めました。Free、Goへの展開は翌8日からです。Enterpriseでの利用は管理者の設定にも依存します（公式発表）。

半年前、チャットUIの是非で止まっている場合ではないという記事で、Xの議論がチャットバーの是非にとどまり、Generative UIの話まで進んでいないと書きました。そのきっかけになった投稿の主であるRabi Shanker Guha（thesys CEO）が、今回はChatGPTの実装を解析した記事を出しています。

10月9日にはCopilotKitが、同じ体験を自分のプロダクトに入れるためのテンプレートとして「Open Intelligent UI」を公開しました。

これまでGenerative UIと呼んでいたものが、Intelligent UIという名前に変わっただけなのか。それとも別の観点で理解し直す必要があるのか。2つの発信と、僕が開発に関わる業務向けAIワークスペースの実装を並べて考えてみます。

ChatGPTの実装

解析記事の詳細版によると、ChatGPTの実装はモデル、サーバー、クライアントの3者で役割を分けています。

  • モデルはDILという言語で回答を書きます。文章はMarkdown、部品はJSX風のタグ、状態とロジックはJavaScriptです。
  • サーバーは途中までの出力を、JavaScriptのプログラムと、文章やデータを入れたJSONにコンパイルします。
  • クライアントでは、隠しiframeの中のWeb Workerがプログラムを実行し、UIの差分を操作の列として出します。
  • ChatGPTのページは、その操作を自社のネイティブ部品に当てはめて描画します。
  • モデルが使える部品とデザイントークンは、カタログとして定められています。

記事に載っている例では、スライダーで席数を変えると価格が再計算されます。このときモデルは呼ばれません。Worker内で状態を更新して再描画し、差分だけをページに返します。

フォームやボタンからモデルに続きを依頼するときは、GenUI.issueNewTurnで新しいユーザーメッセージを送ります。ローカルの状態更新と、会話を進めるための送信は別の処理です。

コンパイルの段階では、文法を補修し、カタログにない属性を落として診断として記録します。書きかけの出力も、最後に完結した部分で区切ってコンパイルします。ストリーミング中、サーバーは数百ミリ秒ごとに全文をコンパイルし直しています。状態にはキーが付いているので、ユーザーが触った値は再コンパイルの間も保たれます。

部品で表せないもの、たとえばWeb Audioで音を鳴らすドラムマシンは、AppBlockという仕組みでHTML、CSS、JavaScriptをiframeに入れて表示します。ただしこれは例外的な経路で、本流はカタログの部品です。

解析記事を読んでいて、MCP Appsに近いのはこのAppBlockのほうだという印象を受けました。どちらもHTMLを隔離したiframeに入れて表示します。一方、本流のDILでは、iframeはJavaScriptを実行するための入れ物で、描画はChatGPTのネイティブ部品が担います。iframeを使う点は同じでも、UIを書くのがモデルで、見た目をホストのカタログで揃える点で、MCP Appsとは別の系統だと感じています。

Xの解析記事は、Generative UIのAPIを提供するThesysの代表が公開したものです。詳細版はThesys Engineering Teamの署名で、内容は通信内容と公開されているJavaScriptに基づく観測や推定です。OpenAIの公式説明とは区別して読む必要があります。

Open Intelligent UIの中身

CopilotKitのリポジトリも読みました。名前は「Intelligent UI」ですが、構成はChatGPTとかなり違います。

  • 回答の形は、TypeSafe社のJevという外部のルーターが、ユーザーの発言ごとに13種類から選びます。ルーターの呼び出しに失敗すると、そのターン全体が失敗します。
  • 単純な表はA2UIで描画しますが、カスタムカタログに入っている部品はTable 1つだけです。
  • グラフ、図、計算機、地図は、モデルが書いたHTML、CSS、JavaScriptをiframeに流し込んで描画します。書きかけのHTMLは、差分を当てて画面のちらつきを抑えています。
  • 見た目はデザインシステムのCSSを注入し、プロンプトで「CSS変数を使い、色を直接書かないこと」と指示して揃えています。CSPには unsafe-eval が入っており、許可されたCDNからモジュールを読み込めます。

ChatGPTの構成に当てはめると、例外の経路だったAppBlockを主な描画手段にした形です。カタログで部品を検査する仕組みや、ネイティブ部品で状態を保ったまま差分を描画する仕組みは、ほとんど再現されていません。

名前だけの変更と言える部分

部品の多くは、以前からGenerative UIの名前で存在していました。カタログ方式はA2UIやjson-render、iframeで隔離するHTMLはMCP AppsやChatGPT Apps SDK、ストリーミング描画はAI SDKのRSC対応などです。ChatGPTが新しい原理を発明したわけではありません。解析記事も、OpenAIが一晩で分野の名前を変えたと書いています。

名前と一緒に変わったこと

それでも、ChatGPTの変化を名前だけの変更だとは考えていません。モデルが回答の形を選び、操作できる道具を作ることは、既存のGenerative UIでも可能でした。今回注目しているのは、その体験がChatGPTの通常の回答に組み込まれたことです。回答の形と振る舞いを設計するうえで、次の4点が参考になります。

回答の形を決める主体

ツールの呼び出しに決まった部品を対応させる実装では、開発者がツールと部品を配線します。ただし、モデルが回答の中でUIを構成する方式も以前からあります。json-renderの2026年2月時点のChat modeは、モデルにUIツリーを生成させ、必要がなければ文章だけを返すよう指示しています。

ChatGPTも、文章で返すか、部品を出すか、操作できる道具を作るかをモデルが回答の中で判断します。CopilotKitはこの判断を専用のルーターに任せています。形を選ぶこと自体の新規性より、その判断を通常の回答体験にどう組み込むかに注目しています。

生成できるロジックの範囲

A2UIやjson-renderでは、UIを宣言的なデータとして記述します。この方式でも、操作への反応をクライアントの中で完結させられます。A2UI v0.9の仕様にはローカル関数を呼ぶアクションがあり、json-renderには双方向のバインドやローカルの状態更新があります。UIの記述形式と、操作を処理する場所は別の軸です。

DILでは、モデルがJavaScriptで状態更新や計算ロジックまで記述できます。A2UIやjson-renderでは、ホストが提供する部品・関数・式の範囲で振る舞いを表現します。主な違いは、モデルにどこまでロジックの記述を許すかにあります。どちらの方式でも、回答をその場で使える小さな道具にできます。

回答の標準の形

Intelligent UIは、対応するChat体験で通常の回答に使える機能として段階展開されています。公式ヘルプによると、Work、Voice、Pro推論オプション（GPT-6 Astra）は対象外です。文章と部品が同じ回答の中に並ぶため、書きかけの状態でも描画できること、状態を保ったまま差分で更新すること、変化をアニメーションで見せることが、回答体験の要件になっています。

モデルとの契約になったデザインシステム

約70個の部品とデザイントークンからなるカタログが、モデルに使ってよい語彙として渡され、コンパイラがその語彙で出力を検査します。その結果、生成されたUIはWebとモバイルのどちらでもChatGPTの他の画面と同じ見た目になります。工夫のしどころは、プロンプトから、カタログと出力形式の設計、そしてサンドボックスの安全設計に移っています。

5つの比較軸

名前で分類するより、次の5つの軸で各実装の位置を見るほうが実務では役に立ちます。

軸一方の端もう一方の端
形の決定開発者が配線するモデルが毎回選ぶ
UIの実体決まった部品宣言的なJSON、状態を持つプログラム、任意のHTML
操作の処理毎回エージェントへ戻るクライアント内で完結する
見た目の統制iframeの中で自由に描くカタログとトークンで検査する
ストリーミング完成してから表示する書きかけでも差分で描画する

この軸で、ChatGPT、Open Intelligent UI、json-render、そして僕が関わるワークスペースの主な描画経路を並べると次のようになります。

軸ChatGPTOpen Intelligent UIjson-render業務向けワークスペース
形の決定モデルが文章と部品を混ぜて書く外部ルーターが毎回選ぶライブラリは関与しないモデルが判断する。ただし明示的に頼まれた場合だけ
UIの実体状態を持つプログラム表はA2UI、他はiframeのHTML状態や式を持てる宣言的なJSON値だけを持つJSON（約16部品）
操作の処理ローカル操作はクライアント内で完結。送信は新しいターンiframe内で完結し、送信は新しいターン組み込みの操作はクライアント内で完結フォーム入力の保持だけ。送信はエージェントへ戻る
見た目の統制カタログとトークンで検査CSSの注入とプロンプトの指示zodのカタログ。描画時の検査はホスト側サーバーとクライアントの両方で検査
ストリーミングキー付きの状態を保って差分描画書きかけのHTMLに差分を適用JSON Patchを1行ずつ適用部品ごとに段階描画し、フォームは完成まで隠す

json-renderは、ChatGPTとCopilotKitの中間に位置します。JSON Pointerで参照する状態、双方向のバインド、条件による表示切り替え、状態を書き換える組み込みの操作を、データだけで表現できます。モデルが生成した任意のJavaScriptを実行しないため、そのコードを隔離するサンドボックスは不要です。表現できる範囲は、カタログ、式の言語、ホストが登録した関数に限られます。

業務向けワークスペースの位置

僕が関わるワークスペースは、アプリが持つ部品カタログから組み立てたJSONを、表示専用のツールで受け取る方式です。モデルが書いたHTMLやコードは実行しません。以前はjson-renderを使っていましたが、移行の過程で状態のバインド、条件による表示、繰り返しをやめ、値だけを受け取る形にしています。いまの表示は、カタログを用意してモデルにJSONで設計図を書かせるだけで足りていて、これらの機能を使う場面がなかったためです。

5つの軸で見ると、見た目の統制はChatGPTと同じ側にあります。出力はサーバーとクライアントの両方でスキーマとグラフ構造を検査され、検証済みのUIは会話履歴に保存されて、再読み込み後も同じ形で復元されます。フォームの送信は承認フローにつながっています。

一方で、形の決定と操作の処理は、意図して控えめにしています。可視化はユーザーが明示的に頼んだときだけで、既定の回答は文章です。フォーム以外にクライアント側の状態はなく、計算機や絞り込みのような、その場で使える道具は作れません。図を修正するときも、前のUIへの差分ではなく、完全な文書をもう一度出力します。

業務で使うシステムでは、検証、保存、承認の仕組みがいちばん大事で、この部分はCopilotKitのテンプレートより厳格です。足りないのは、回答を道具にするための、クライアント内で完結するロジックです。

業務システムでの進め方

ChatGPTの方向に寄せるとしても、iframeに任意のJavaScriptを入れる方式から始める必要はないと考えています。json-render程度の宣言的な状態、つまり値のバインド、条件による表示、状態を書き換える組み込みの操作をカタログに戻せば、絞り込みや比較の切り替えを作れます。

計算機には、ホスト側の計算実装も必要です。たとえばjson-renderの$computedで登録済みの計算関数を呼ぶか、ホストが計算用の部品を用意します。モデルに任意のコードを実行させず、検証と保存の仕組みを保ったまま広げられるはずです。

状態のバインドや条件による表示は、いまの表示には不要だったのでやめた機能です。回答を道具にしたくなったら、そのときにどう戻すかを改めて考える必要があります。

おわりに

Intelligent UIは、Generative UIをChatGPTの通常の回答体験に統合した実装だと考えています。部品も、モデルが回答の形を選ぶ能力も、手元で動く道具を作る仕組みも以前からありました。今回注目しているのは、それらをChatGPTのデザインシステムやストリーミングと組み合わせ、対応するChat体験の標準機能として展開したことです。

半年前の記事では、Generative UIの難所は描画ではなく状態にあると書きました。ChatGPTのキー付きの状態は、そのうち生成途中の入力保持に答えを示しています。公式ヘルプによれば、再読み込み後の状態保持は部品によって異なり、会話間では保持されません。保存・共有・監査・承認の仕組みは、引き続き設計する必要があります。自分たちのプロダクトでどこまでやるかは、名前ではなく、5つの軸のどこに立つかで決めることになります。

前の記事チャットUIの是非で止まっている場合ではない