AI開発の現場は転換点を迎えています。モデルの推論能力だけでなく、生成結果をUIとして実装する質がプロダクトを左右します。
テキストとUIの境界を消す「インライン生成UI」が進化しています。Pollo Agentのワークフロー自動化とReactコンポーネントの埋め込みを組み合わせます。
この記事ではUIのインライン化と、Claude Codeを用いた次世代のAI開発について掘り下げます。設計に直結する開発者目線の知見を共有します。
SNS運用を自動化しませんか?
ThreadPostなら、投稿作成・画像生成・スケジュール管理までAIがサポート。
生成AIのUI進化とワークフロー自動化の現状
AI開発は「モデル単体の性能」から「アプリケーションへの統合」へ舵を切っています。動画生成プラットフォーム「Pollo AI」がPollo Agentを発表しました。
同社は2,600万人のユーザーを抱えています。今回のアップデートではGPT-5.6とGPT-6 Astraを組み合わせたワークフロー自動化を実装しました。
Pollo Agentは意図を解釈し、ストーリーラインやスクリプトを生成して動画制作まで導きます。推論の深さとコストを考慮したモデルのルーティング機能を搭載しました。
単純なタスクにはGPT-5.6、物語構成にはGPT-6 Astraを使い分けます。ユーザー体験の安定化とコスト効率の最適化を両立させました。
しんたろー:
Pollo Agentのモデルルーティングが気になります。全部最高スペックのモデルで叩くのはコストと速度の面で課題があるため、こういう「適材適所」の設計をAPI層でいかに隠蔽できるかが開発者の腕の見せ所だと感じます。
技術的なアプローチとして「インライン生成UI」が注目されています。従来はiframeを用いた別コンテキストでの表示が主流でした。これにはテキストストリームとの統合が難しいという制約があります。
JSONLパッチをテキストストリーム内に混在させ、クライアント側でReactコンポーネントとして直接描画する手法が登場しました。サーバー側のパイプラインでテキストとUIコンポーネントの分離を自動化します。
AIの回答という「流れ」の中に、動的なUIが差し込まれます。没入感のあるユーザー体験を実現するための実装が多くの開発者の間で試行錯誤されています。
※この記事は、Claude Codeで1人SaaS開発しているしんたろーが、海外AI最新情報を開発者目線で解説する「AI活用Tips」です。
AI開発における「UIとコンテキストの統合」という新潮流
AIの推論能力を競う段階から、AIの出力をユーザーの作業環境へ自然に溶け込ませるインターフェース設計の競争へ移行しています。
AIが生成したワークフローを提示する設計思想が分断されています。標準化を重視するiframeベースと、文脈の一体感を追求するインライン生成UIです。
iframeはセキュリティと汎用性で強力です。しかし、サンドボックスの壁がテキストとUIの境界を分断します。会話の途中で別ウィンドウが開く感覚は、AIとの対話をドキュメント閲覧から切り離します。
json-renderのようにテキストストリーム内にJSONを混在させる手法は、UIを「文脈の一部」として扱います。これは僕が普段Claude Codeでコードを生成する際、ターミナル上で直接ファイルが書き換わる感覚に近いです。
しんたろー:
iframe方式の制約に課題を感じていた身としては、インライン描画の設計思想に可能性を感じます。セキュリティと柔軟性のトレードオフをどこで取るかが死活問題です。自分のSaaSで何を優先するかで実装は変わります。
開発者の問いは「モデルの性能をどう引き出すか」から「モデルの出力をどのコンテキストで、どんなUIとしてレンダリングするか」へシフトしています。AI SDKのストリーミング基盤の上に、独自のレンダリングロジックを構築します。
Pollo AIの事例が示すように、モデルの「使い分け」も自動化の対象です。推論の深さとコスト、速度のバランスをAPI層で抽象化し、タスクごとに最適なモデルへルーティングします。
僕たちがやるべきは、AIという「知的なエンジン」を、既存のWebアプリケーションという「容器」に違和感なく流し込むインターフェースの最適化です。本質的な価値は「ユーザーがAIを意識せずに目的を達成できるUI」の中にあります。
今のAI開発はチャットボットを作る段階を過ぎました。テキストとUIの境界を消し去り、AIとの対話を「一つのアプリケーション体験」として完結させます。僕もThreadPost開発でこのインラインUIの知見を活かすべく、アーキテクチャを眺めながら試行錯誤しています。
ここまで読んだあなたに
今なら無料で全機能をお試しいただけます。設定後はAIが投稿案を毎日生成。確認して選ぶだけ。
実務への影響:UIの「動的生成」が開発の標準になる
明日からの開発では、AIの出力を「テキスト」として受け取る設計から、「コンポーネントのカタログ」を介した「インラインUI」の生成へシフトします。
iframeによる別窓表示ではテキストの文脈とUIが分断されます。LLMがテキストストリームの中にJSONL形式のパッチを混ぜ込み、フロントエンドで直接Reactコンポーネントとしてレンダリングする設計が標準的な選択肢になります。
具体的には、以下の3点のアクションが必要です。
- コンポーネントカタログの整備
AIが生成すべきUIのパターン(チャート、ボタン、カード等)を、Zod等で定義したスキーマとしてカタログ化します。モデルに対して「どのコンポーネントを使うべきか」を明示的に指示できる状態を作ります。
- ストリーム処理のパイプライン化
AIからの回答をそのまま受け取るのではなく、サーバー側でテキストとUIパーツを分離する変換処理を挟み込みます。AI SDK等のストリーム基盤を活用し、特定のデータパーツをフィルタリングしてクライアントに送るパイプラインを構築します。
- プロンプトの「資産化」を前提とした機能設計
ユーザー側で便利なプロンプトを保存・再利用する機能が標準化されつつあります。自社サービスにおいても、ユーザーが頻繁に使う操作を「スキル」として保存できるよう、プロンプトのテンプレート化を意識したAPI設計を推奨します。
しんたろー:
UIをどこまで「AIの制御下」に渡すかが勝負の分かれ目だと感じます。自分で全部DOMを作る時代は終わりつつあります。AIが「今はグラフを出すべき」と判断して、その場で描画する。この柔軟性がないと、これからのSaaSはただのチャットボットと見なされます。
これらの技術は、ユーザーがAIとの対話中に、別の画面へ遷移したり、コピー&ペーストでデータを移し替えたりする手間をゼロにします。
Claude Codeのような自律型エージェントを活用している開発者なら、生成されたコードやUIが「今、作業している文脈」の中にシームレスに溶け込んでいるかを確認します。もし、AIとの対話画面で「UIとテキストが分離していて読みづらい」と感じるなら、それはアーキテクチャの改善ポイントです。
AI開発はモデルの推論能力を競うフェーズから、「ユーザーの作業環境の一部として溶け込ませる」インターフェースの戦いに移行しています。まずは手元のプロダクトで、一番頻繁に発生する「データの可視化」や「アクションの実行」を、チャットのインラインで完結させる実装から着手します。
よくある質問
MCP Appsとjson-render、どちらを採用すべきですか?
汎用性と標準化を重視するならMCP Appsですが、iframeの制約によりテキストとのインライン配置は不可能です。一方、json-renderはテキストの文脈の中にUIを直接埋め込めるため、チャット体験の没入感を高めたい場合に適しています。現状、AI SDKとの統合のしやすさや、UIの柔軟な配置を優先するならjson-renderが選択肢に入ります。
複数のモデルを使い分けるエージェントを構築する際のコツは?
Pollo AIの事例のように、推論の深さとコスト・速度のバランスでモデルをルーティングするのが基本です。単純なタスクには軽量モデル、複雑な推論や物語構成には高性能モデルを割り当てる設計を、API層で抽象化して実装します。これにより、ユーザーはモデルの切り替えを意識せず、常に最適な品質の出力を得られます。
Chromeの「Skills」機能は開発者にとってどう影響しますか?
ユーザーがAIプロンプトを「資産」として保存し始めることで、Webアプリ側にも「AIが実行しやすいプロンプトの構造化」が求められるようになります。自社サービスが提供する機能を、ユーザーがGeminiのSkillsとして保存・再利用しやすいよう、プロンプトのテンプレート化や、APIの呼び出しを明示的にガイドする設計が重要になります。
まとめ
AIは単なる「問いかけ」の対象から、ワークフローそのものを実行し、結果を動的なUIで提示する存在へ進化しました。モデルの性能競争を追うだけでなく、テキストとUIの境界を消し去る「インライン生成UI」のような設計思想がプロダクトの価値を左右します。
AIをただのチャットボットで終わらせない。開発者として、この文脈をいかにユーザーの作業環境へ溶け込ませるか。それが、次の開発の鍵になります。

この記事が参考になったら、ThreadPostを試してみませんか?
投稿作成・画像生成・スケジュール管理まで、AIがサポートします。
ThreadPostをもっと知る