エージェントの時代へ — 私たちが設計しているランタイムです。

ヘッドレスブラウザの中だけで動くエージェントは、Final Cutを開くことも、Finderからクリエイティブツールへビデオファイルをドラッグすることも、プレビューでPDFに署名することも、.dmgや.exeのインストーラーを実行することも、別のアプリに画面収録の権限を与えることも、システムのファイル選択ダイアログでファイルを選ぶことも、OSからの予期せぬモーダルダイアログを乗り越えることもできません。実際のワークフローの多くは、まさにこうした場面にあり、ヘッドレスブラウザのエージェントが静かに失敗するのもここです。

仮想化されたコンテナ（大手ラボの「エージェント用コンピューター」方式）は、そうした隙間の一部を埋めますが、別の問題を抱えています。イメージは通常、数個のアプリだけをあらかじめ入れた最小限のLinuxデスクトップで、その範囲の外にあるものには手が届きません。コンテナには、ユーザーの実際の作業との連続性もありません。インストール済みのアプリも、ログイン済みのアカウントも、保存したファイルも、許可の設定も引き継がれません。エージェントを実行するたびに、ユーザーのものではない、まっさらなマシンから始まります。

Remioの設計は、もう一方の道を選びます。私たちが作ろうとしているランタイムでつながるエージェントは、人がすでに今日使っているのと同じリモートデスクトップのセッションを通じて、ユーザーの本物のデスクトップ、つまりユーザーが普段作業している実際のMac、PC、Linuxマシンを使います。ユーザーがインストールしたすべてのアプリが、そこにあります。ログインしているすべてのアカウントが、そこにあります。すべてのファイルが、そこにあります。エージェントは作り物の環境の借り手ではなく、ユーザーが許す間だけ、それ以上は一瞬たりとも、ユーザー本人のワークステーションに招かれるゲストになります。

今日出荷されているのはライブストリームです。ホストの画面を継続的にキャプチャし、ハードウェアでエンコードし、人のクライアントがすでに使っているのと同じ暗号化されたチャネルで届けます。エージェントのランタイムは、静止画の取得（要求に応じた1フレーム、あるいはモデルがすでに見るべき場所を知っている領域だけ）にも同じパイプラインを再利用し、別のキャプチャ経路を新たに立ち上げることはしません。この再利用は私たちが決めた設計方針であり、今日すでに存在するものについての主張ではありません。

ピクセルよりテキストのほうが推論しやすいエージェントのために、設計にはトランスクリプトモードを描いています。画面上のテキストを、ビジョンモデルを介さず、プラットフォーム自身のOCR（macOSではVisionフレームワーク、WindowsではWindows OCR API）で生成して、バウンディングボックス付きで返します。これについては何も作られていません。リストに載せているのは、エージェントがモデルにフレームを一度も送らずに、テキストの一致を正確なクリックに変えられるからです。うまく作れれば、確かな効率の向上になります。

最も忠実な構造化アクセスとして、フォーカスされたウインドウのOSのアクセシビリティツリーの読み取りも描いています。スクリーンリーダーが辿るのと同じツリーで、ボタン、テキストフィールド、メニュー、役割のラベル付きの階層です。これもまだ存在しません。そして私たちが描いているどの版でも、入力パイプラインと同じ決まりが引き継がれます。エージェントのセッションが見られるのは、ホストの画面収録の権限がすでに人のセッションに許しているものとまったく同じで、それ以上ではありません。あるディスプレイでその権限がオフなら、エージェントはそのディスプレイから何も受け取れません。今日の人のクライアントと同じです。

Remioのすべてのセッションは、人かエージェントかを問わず、同じ方法で始まります。人がホストの画面に表示された6桁のコードを読み取り、クライアントに入力します。エージェントが自分でセッションを作る、黙って更新できるトークンを保持する、ペアリングした人が終了を決めた時点を過ぎてアクセスを延ばす、といった設計は検討していません。次のエージェントの実行では、人が再びペアリングする必要があります。毎回、人が関与する瞬間が、設計として入ります。

エージェントのセッションが有効な間、ホストとクライアントの両方に、常時表示される見間違えようのないインジケーターが出ます。そして、セッションを即座に終了させる停止ボタンは、開始した人だけでなく、ホストのキーボードの前にいる誰でも押せます。エージェントが行うすべての操作は、人が確認できる監査ログに記録されます。これらは今日の出荷済みコードにはまだありません。設計が越えなければならない基準です。

権限の境界も、上の入力と画面の節と同じ話です。エージェントのセッションは、人のセッションがすでに守っているホストのOSレベルの権限、つまり「画面収録」と「アクセシビリティ」をそのまま引き継ぎ、それ以上は持ちません。昇格した独自の許可は与えられず、人がRemioアプリのためにすでに設定した範囲を広げる経路もありません。私たちが設計している機能がその境界に収まらないなら、出荷しません。

私たちが行き着き続けている形は、意図的に小さなものです。入力のための2つほどの基本機能（クリックとキー）、視覚のための2つほど（静止フレームと領域）、構造化されたUIの読み取りのための1つ。これは仕様ではなくスケッチで、どれも出荷されておらず、正確なインターフェースもまだ決まっていません。今お約束しているのは、構文ではなく形です。

モデルに依存しないことは、あとで目指す理想ではなく、設計上の要件です。ワークフローを計画するモデルがClaudeでも、GPTでも、Geminiでも、自分で動かすものでも、提供するものは同じように動作します。特定のベンダーのツール呼び出し形式を軸には作りません。ランタイムを1つのモデルのインターフェースに縛った時点で、間違った種類の約束をしてしまうからです。

デスクトップのランタイムと、エージェント自身のランタイムは別のものであり、私たちはそのままにするつもりです。Remioは、エージェントの操作を本物のデスクトップに届けるもの。モデル、計画のループ、それをどこで動かすかは、エージェントを作る人に完全に委ねられます。私たちがモデルをホストしたり、従量課金したり、アクセスを制限したりする計画はありません。

Remioは、Webブラウザだけが必要なエージェント、つまりページのスクレイピング、フォームへの入力、ダッシュボードの読み取りには向いていません。リモートデスクトップのセッション全体は、ブラウザのタブが必要とする以上のものであり、Remioはその分野で競うつもりはありません。

Remioは、使い捨ての環境を何十個も必要とするエージェント、つまりタスクごとに1つ、毎回まっさらな状態、並列実行、にも向いていません。Remioは、人がペアリングした持続的なセッションを軸に作られており、それは正反対の形です。同時実行は少なく、連続性は高く、本物のユーザーのコンテキストがあります。

Agent Runtimeをこのページの説明どおりに作るなら、エージェントに本物のOSのデスクトップ、ネイティブアプリ、ユーザーが実際にインストールしたソフトウェア、ユーザーの本物のアカウントとファイル、そして人が関与するセッションの境界が必要なときの、正しい答えになります。障害のあるユーザーのためにデスクトップを操作するアクセシビリティエージェント。本物のOSアプリでのAI支援QA。ユーザーがすでに持っている特定のネイティブツールを使わなければならないエージェント型のワークフロー。「私が見ている間、中身ごと私の実機を使って」が自然な枠組みになるあらゆるタスク。そうした場合に、提供が始まれば、Remioがそのランタイムになります。