AIアプリケーションの世代：対話型、委任型、協調型

著者はAblyでAIトークンストリーミングに取り組んでいる。彼は、ほとんどの人のAIアプリケーションに対するメンタルモデルが2022年11月のままだと指摘する——チャットウィンドウ、往復の会話、LLMの賢そうな応答。そのモデルはすでに2世代遅れている。

第1世代：対話型 対話型AIアプリケーションが最初に登場した。2022年11月にChatGPTがリリースされ、2023年前半にはチャット製品カテゴリが進化した。2024年初頭にはGoogle Geminiが参戦、Claude 3ファミリーも登場した。これらはすべて対話型のAIアプリケーションだ。その中核的なインタラクションは画面下部のテキストボックスで、質問や指示を入力するとAIが同じウィンドウに散文で応答する。これはほとんどのAIコードライブラリのサンプルが採用する設計であり、HTTPリクエスト/レスポンスとSSEストリーミング応答を用いる。この設計は既存の技術やアーキテクチャに適合しやすく、インスタントメッセージングに近いため、最初に破壊された分野は既にチャットボックスを使っていたカスタマーサポートや検索だった。対話型AIでは、AIが何かをしてくれる感覚はなく、ユーザーがAIに相談し、AIが応答する。ワークフローは情報を会話にコピペすることが中心で、AIの応答がほぼ製品そのものだった。

第2世代：委任型 次の世代は委任型だ。ユーザーがタスクをAIに委任し、AIがそれを遂行するために行動を起こす。2024年夏、AIアプリケーションはツール呼び出し機能を獲得し、外部システムを操作することが当然となった。2023年にもGPT Actions、ChatGPTプラグイン、Devinなどで何度も反復が行われたが、2024年にはArtifacts（コードやドキュメント、図表をサイドパネルにレンダリング）、Tools（外部システムの操作）、MCP（AIと外部システムを接続するデファクトスタンダード）を構築できるようになった。これらの製品の進歩により、AIは対話型から委任型へと変わった。AIが実際に何かをしているように感じられ始め、MCPで外部システムからコンテキストを取得し、ダウンロード可能なドキュメントをレンダリングする（コピペだけではない）。2024年後半にはComputer Useもリリースされ、Claude Desktopが画面を操作してアクションを実行できるようになった。

委任型AIアプリケーションの大きな飛躍は2025年、人間と仕事の関係が変化したときに訪れた。AI製品は人間がタスクを委任するエージェントシステムになり始めた。Claude Codeが2025年初頭にリリースされ、Claude 4世代のモデルでは長期間のセッションでツール使用が一貫して信頼できるようになった。これが対話型から委任型への大きなシフトであり、極めて微妙な違いだ。対話型の時代、人間はモデルに相談して自身の作業を強化・改善していた。人間が実行者で、モデルはアシスタントだった。委任型の時代、人間はエージェントに仕事を委任する監督者になった。エージェントは人間が設定した指示や目標に基づいて行動する。仕事と価値の単位は、プロンプトと応答から、エージェントが遂行するタスクへと移行した。

しかし、委任型アプリケーションは当初のリクエスト-レスポンスアーキテクチャよりも構築がはるかに難しい。現在は長期実行プロセスがエージェントループを回し、ツール呼び出しを行い、複数のターンで複数のタスクを実行する。各ターンは高コストになる可能性があるため、エンジニアはエージェント実行を永続化する仕組みを模索する。Temporalなどの永続実行フレームワークが台頭し、エージェントループを永続化し、ステートフルな側面を簡素化し、自動リトライし、高コストな計算や参照をスナップショットする。

永続実行フレームワークは計算を助けるが、AI生成応答の転送は助けない。エージェントが非同期の長期実行プロセスになると、エージェントとリクエストを出したクライアントや人間との間の接続管理が悪夢になる。元のHTTPリクエスト-レスポンスモデルは長期実行非同期プロセスにうまくスケールしない。切断が発生すると再接続が本当に面倒になる。エンジニアはAI生成応答の断片をすべてデータベースに保存し、ソートキーや順序キーを追加し、それらの応答上に再開可能なSSEストリームを構築しようとする。これらはインフラストラクチャの問題であり、エンジニアが実際に構築しようとしているAIアプリケーションとは無関係であることが多い。

第3世代：協調型 私たちが見始めている次世代のAIアプリケーションは協調型だ。Claude Designがその最初の良い例である。2024年にAnthropicがArtifacts（サイドパネル内のドキュメント、図、コード）を、OpenAIがCanvas（同等品）をリリースしたとき、協調体験の種が蒔かれた。モデルの出力はスクロールするチャット履歴にとどまるべきではなく、対話型・委任型の体験が共同で作業できるものに昇格すべきだという考えだ。Claude Designは、協調体験が以前の世代と何が違うかを最も明確に示している。Claude Designを開き、望むものを説明すると、Claudeは直接編集可能なワークスペースにドラフトをレンダリングする。色、テキスト、サイズを変更でき、微調整によって異なるデザイン案を試せる。委任型・対話型のAIアプリケーションはほぼ完全にチャットインターフェースに基づいていたが、Claude Designのインターフェースはチャットを超えた多くの入力パラメーターを提供し、チャットボックスに変更を記述するのではなく、実際にデザイン要素を変更できる。

Claude Designの異なる入力と協調モード（テキスト、微調整、直接編集）は素晴らしいが、次の動きは相互作用する表面自体が動的になることだ。現在のClaude Designの協調例は依然として固定形状のワークスペースだが、チャットインターフェースを超えた協調コントロールの種を含んでいる。次に来るのは生成UIだ。協調を可能にするインターフェースやコントロールは、ユーザーが要求するまで存在しない。MCPアプリの埋め込みインタラクティブサーフェスでこれが見られ始めている。チャットボックスは作業が行われる場所ではなく、作業がリクエストされる場所になり、実際のインターフェースはタスクに応じてリアルタイムに組み立てられ、ユーザーとAIが協調する。

エンジニアリングの課題 これまで、各世代のAIアプリケーションが提示する課題をソフトウェアエンジニアがどう解決しようとしているかをほのめかしてきた。新しい生成UIは、従来のWebアーキテクチャの下では本当のエンジニアリングの悪夢である。委任型時代の長期実行エージェントアプリに存在した問題は、ツール使用と応答だけでなくUIそのものをストリーミングする必要があることでさらに悪化する。ステートフルなキャッシュやデータベースに接続されたステートレスサーバー上で、既存のHTTPロングポーリング、SSE、リクエスト-レスポンスモデルをスケールさせることが実際の問題になる。どのAIライブラリもこれに対する解決策にはほど遠い。

エンジニアリングチームは過去15年近く、低レイテンシのリクエスト-レスポンスとステートレス水平スケーリングのためにスタックを最適化してきた。新しいモードはその逆を要求する。永続的接続、サーバープッシュ状態、長期実行計算、そしてロードバランサーが特に回避するように作られたクライアント-サーバーセッションアフィニティだ。これをHTTPベースのREST API上に構築することは可能だが苦痛だ。ネイティブサポートを構築するには、コネクション層からアーキテクチャを再考する必要がある。

開発者のマインドシェアが実際にはより困難な問題だ。あまりにも多くのエンジニア、デザイナー、プロダクトマネージャー、エグゼクティブが、AIのメンタルモデルを2022年末のChatGPTに完全に固定している。彼らはインターフェースがチャットボックスであり、出力がLLM生成テキストだと考えている。業界のビルダーが追いつき、委任型・協調型AIアプリケーション構築の問題を実際に体験するには時間がかかっている。あまりに多くの人にとって、問題は直接遭遇しない限り存在しないか問題ではない。HNのコメントで「Xを使えばいいじゃないか」とか「Yはどうだ」と言うエンジニアが見られる。しかし、最良のエンジニアリングチームはすでにこれらのエンジニアリング課題に取り組んでいる。Ablyでも彼らと協力している。

私はAblyのAI Transport製品に取り組んでいる。これはもともと、トークンストリーミングのためのpub/sub代替として始まり、トークン圧縮、会話履歴、巻き戻しサポートを内蔵している。エンジニアリングチームが長期実行非同期エージェントを構築し始めていた委任型体験を解決するための製品として生まれた。従来のHTTPストリーミングはAIセッションを単一の脆弱な接続に縛り付けていた。AI Transportは、共有のリアルタイムで永続的なpub/subトランスポートをエージェントとクライアントの両方に提供することで、その接続と長期実行プロセスを切り離す。同じトランスポートは双方向メッセージングをサポートし、ユーザーがエージェントループを誘導しプロンプトを送れるようにする。

AI Transportの前に、私はLiveObjects製品に取り組んでいた。LiveObjectsはpub/subチャンネル上に構築されたリアルタイム協調状態製品であり、一連のCRDTデータ型を提供する。これにより、pub/subチャンネル上で状態を永続化し、複数のクライアントがその状態で協調できる。状態の変更はリアルタイムですべての参加者にファンアウトされる。

委任型AIアプリケーション、または生成UIを持つAIアプリケーションを構築する際の最も難しい2つの問題は、エージェントとクライアント間の永続的な接続/セッションと、エージェントと人間が協調できるライブ共有永続状態である。私はAblyでこれら両方の製品に直接取り組んできた。両方の製品は、新しい世代のAIアプリケーションを非常に簡単に構築できるようにする。AI Transportはエージェントとクライアント間の永続的な接続とセッションを提供し、切断やHTTP上にフランケンシュタイン解決策を構築する心配をなくす。LiveObjectsは一連のCRDTデータ型を提供し、エージェントと人間が協調できるライブ共有状態を構築できるようにする。協調的で生成的で動的なアプリケーションをステートレスなREST APIに無理やり押し込む必要はない。

次世代のAIアプリケーションが来ている。それらのアプリケーションをまったく機能しないシステム設計に無理やり押し込もうとしているエンジニアリングチームのことが心配だ。