OpenAIのWorkspace Agents、ChatGPT内の作業を外部システムから起動できるようにした
OpenAI Developersに追加されたWorkspace Agentsは、ChatGPTワークスペース内で公開されたエージェントを、外部のバックエンドシステムから非同期に起動するための仕組みです。ユーザーが毎回ChatGPTを開いてプロンプトを投げるのではなく、Zendeskのチケット、社内ダッシュボード、定期ジョブのようなイベントが、あらかじめ公開済みのワークスペースエージェントを呼び出します。ChatGPTは会話画面だけでなく、組織内の業務イベントから始まる作業面へ広がり始めました。
ChatGPTのエージェントを、社内イベントから起動する
OpenAIの説明では、Workspace Agentsはワークスペース管理者が設定し、組織内に公開できるChatGPTエージェントです。重要なのは、その実行開始点がChatGPTの入力欄に限られないことです。Trigger runsのドキュメントでは、外部バックエンドからAPIでエージェント実行を作成できると説明されています。
この形になると、エージェントは「ユーザーが思いついた時に話しかける相手」から、「業務システムの状態変化を受けて動く担当者」に近づきます。たとえばサポートチケット、CRMの更新、社内承認、日次レポートのような出来事が、公開済みのエージェントへ作業を渡す入口になります。
Interface Wire的に面白いのは、OpenAIがChatGPTのUIを消しているわけではない点です。実行は外部システムから始まりますが、結果や通知、運用の境界はChatGPTワークスペース側に残る。チャット画面と業務システムの間に、非同期の作業キューが置かれたような設計です。
入力はプロンプトではなく、構造化されたpayloadになる
Trigger runsのAPIは、`agent_id`に対して実行を作り、`input_payload`でエージェントに渡すデータを指定する形です。これは普通のチャット入力と違い、外部システムが持っているID、状態、ユーザー名、チケット本文、分類済みデータなどを、作業の材料として渡せる設計です。
ドキュメントでは、エージェント実行は非同期に扱われ、通知先メールアドレスを指定できる構成も示されています。つまり、ボタンを押したユーザーが画面の前で返答を待ち続ける前提ではありません。システムが実行を起こし、エージェントが作業し、必要な人へ結果や確認が戻る流れです。
この変化は地味ですが大きいところです。AIプロダクトのUIは、長い自由文をうまく書くことだけでなく、どのイベントで、どのデータを、どの公開済みエージェントへ渡すかという設計へ移ります。プロンプト欄の文章力より、業務システム側の接続点と入力設計が効いてきます。
アクセストークンが、便利さと境界を分ける
Authenticationのドキュメントでは、Workspace Agent access tokenを使って外部システムからエージェント実行を認証する導線が説明されています。ここで大事なのは、便利な自動起動がそのまま無制限なChatGPT操作になるわけではないことです。どのワークスペース、どのエージェント、どの実行権限を許すかを、トークン管理と公開設定で切る必要があります。
これはSecure MCP TunnelやCodex Remote connectionsと同じ流れにも見えます。OpenAIは、AIに社内の道具や作業環境を渡す機能を増やしていますが、そのたびに境界のUIも必要になります。今回のWorkspace Agentsでは、境界はネットワークトンネルではなく、公開済みエージェント、API実行、アクセストークン、通知先という形で表れます。
企業にとっての問いは、単に「ChatGPTで何ができるか」ではなくなります。どの社内イベントがAI作業を起動してよいのか。どのデータをpayloadに入れてよいのか。誰が結果を受け取り、誰が失敗を監視するのか。Workspace Agentsは、ChatGPTを会話アプリから組織内の自動作業面へ広げる一方で、その設計責任も運用側へ渡しています。
Workspace Agentsは派手なモデル発表ではありません。ただ、ChatGPTの使われ方を、ユーザーが入力欄へ来る流れから、社内システムのイベントが公開済みエージェントを呼び出す流れへ変える機能です。AIエージェントが本当に業務に入る時、重要になるのは賢い返答だけでなく、起動条件、入力payload、アクセストークン、通知、失敗時の監視をどう設計するかです。