AI 実験

Romergo に AI エージェントを招待しました。でも、これは何と呼べばいいのでしょう？

アプリケーションにおけるほとんどの AI 統合は、予測可能な方法で設計されています。この製品はスパーク ボタンを追加し、独自のモデルにリクエストを送信し、サイドバーに応答を表示します。

もう 1 つの一般的なオプションがあります。アプリケーションは MCP サーバーを提供し、ユーザーは ChatGPT、Claude、または別のエージェントを開き、アプリケーション データを操作するように依頼します。これによりエージェントには優れたツールが提供されますが、会話は別の場所で行われます。エディターを終了し、現在開いている内容を説明し、戻って結果を確認する必要があります。

チャットとエディターを切り替えるのにうんざりしていたとき、あるアイデアが思いつきました。それを完全に回避できたらどうなるでしょうか?

AI パネルをエディターに直接追加しましたが、Romergo がホストするモデルには接続しませんでした。代わりに、ユーザーは自分の個人 AI エージェントをオープン セッションに招待します。

エージェントは、ChatGPT、Claude、Codex、または別の MCP 互換クライアント内に既に存在する場所に残ります。モデル、サブスクリプション、メモリ、設定、および利用可能なツールが保持されます。 Romergo は、ワークスペース、現在のコンテキスト、およびプロジェクトを編集するための専用ツールのみを提供します。

接続後、ユーザーは Builder からエージェントに直接書き込むことができます。

回答、質問、中間ステータスは同じパネルに返されます。パネルにはテキストだけでなく、タスク サイクル全体 (コマンドの受信、エージェントへの割り当て、ツールの実行中、確認が必要、ジョブの完了、またはエラーの発生) も表示されます。エディターを離れる必要はなくなりました。

それは実験として始まりました

新しいプロトコルを発明したり、新しい製品カテゴリーを考え出したりするつもりはありませんでした。私は 1 つの単純なアイデアをテストしたかったのです。パーソナル ユーザー エージェントは、MCP を介して外部から Romergo を制御するだけでなく、エディター内のライブ セッションに一時的に参加できるでしょうか。

最初のバージョンは実験でした。驚いたことに、私自身も使い始めるほどうまく機能しました。

最も短い図は次のように描画できます。

Personal AI agent  <->  MCP  <->  Romergo Builder

ただし、両方向の標識は重要です。

一般的な MCP 呼び出しはエージェントで開始されます。エージェントはアプリケーションに接続することを決定し、そのツールを呼び出します。私の実験では、Romergo も作業を開始できます。ユーザーは Builder にコマンドを書き込み、Romergo がそれを安全なチャネルに配置し、すでに接続されているエージェントが MCP 経由でコマンドを受信します。

次に、エージェントは通常の Romergo ツールを使用してプロジェクトを読み取りまたは変更し、同じチャネルを通じて結果を Builder に返します。

これにより、閉ループが作成されます。

1. User -> Builder panel: "Replace the music in this chapter"
2. Builder -> authenticated channel: command + current page + selection
3. Personal agent -> MCP: wait for the next Builder command
4. Agent -> Romergo MCP tools: inspect and edit the project
5. Agent -> MCP channel: status, question, result, or error
6. Builder panel -> User: live response from the personal agent

Romergo は、これらのどのステップでもモデルを実行しません。

同時に、MCP自体は変更せず、それに実サーバープッシュを追加しませんでした。プロトコルの観点から見ると、すべての通話は依然としてエージェントによって開始されます。逆方向は安全なメールボックスとして実装されます。Builder がコマンドをチャネルに書き込み、エージェントは通常のロングポーリング MCP ツールを通じてコマンドを待ちます。次に、エージェントは同じ通常のツール呼び出しを使用してイベントを送り返します。

双方向の動作は、新しい MCP トランスポートを通じてではなく、アプリケーション セッション レベルで発生します。この区別は重要です。現在の実装は、標準の MCP 呼び出しの上に構築された小規模なセッション コントラクトとして最もよく理解されています。

エージェントがセッションに入る方法

Builder は一時的なチャネル コードを作成します。ユーザーは、次のような短い開始プロンプトを AI チャットにコピーします。

私のRomergo Builderチャンネルに参加してください。新しいコマンドを 1 回ずつ実行し、結果または質問を Builder に送り返し、私が明示的に停止を求めるまで待ち続けます。

次に、エージェントは MCP ツール romergo_join_builder_channel を呼び出し、コードを渡します。これはハンドシェイクです。Romergo は、OAuth セッション、チャネルの所有者、およびその有効期限をチェックし、会話の状態と最後のコマンド カーソルを返します。

次に、エージェントは romergo_wait_for_builder_command を呼び出します。これは、エディターからの次のコマンドを待つロングポーリングです。何も到着しない場合、エージェントはカーソルを保存し、再び待機を開始します。コマンドが存在する場合、次の内容が含まれます。

添付されたすべてのコンテキストは、信頼できないアプリケーション コンテンツとしてマークされます。これは作業用のデータであり、エージェントの制御命令の続きではありません。

エージェントは、既存の Romergo MCP ツールを使用してタスクを実行します。たとえば、プロジェクトとチャプターを読み取り、アセットを検索し、シーンを変更し、保存された結果を確認できます。

動作中に、エージェントは romergo_report_builder_event を呼び出してパネルを送信できます。

応答は commandId にバインドされ、次のコマンドは最後に処理されたシーケンスから読み取られます。最初に発行されると、API はコマンドを client_id OAuth クライアントにアトミックに割り当てます。接続されている別のエージェントは、同時に同じタスクを取得することはできません。カーソルはタイムアウトまたは再接続後の続行に役立ち、特定のツール呼び出しの 1 回限りの確認は引数のフィンガープリントによって保護され、別のアクションに再利用することはできません。

権利はプロンプトではなくルームにあります

接続する前に、ユーザーはチャネル設定を確認し、エージェントに許可される操作 (プロジェクトの読み取り、コンテンツの編集、メディアとオーディオの操作、データの公開または削除) を選択します。これらの設定は、パネル ヘッダーの歯車からいつでも開くことができます。

デフォルトでは、メディアの読み取り、編集、操作が可能であり、ユーザーからの直接リクエストはすでにこれらのアクションを適用する権限とみなされます。公開と削除は個別に無効化および有効化されます。必要に応じて、ユーザーはより厳密なモードを有効にしてすべての変更を再度確認することも、公開と削除の場合のみ確認を要求することもできます。

これは開始プロンプト内の単なるテキストではありません。共通サーバー ラッパーは、MCP 変更ツールを呼び出す前にスコープをチェックします。追加の確認が有効になっている場合、Builder は「一度許可」ボタンと「拒否」ボタンを使用して正確なアクションを表示しますが、元の通話は決定を待ち続けます。権限はコマンド、ツール、引数のフィンガープリントにバインドされており、一度実行されると無効になります。

各修正ツールの開始、完了、エラー、ブロックは自動的にパネルに返されます。各最終回答には、ステータスと結果の具体的な説明を含む構造化された概要が含まれている必要があります。変更後、エージェントは変更されたエンティティ、実行されたチェック、および結果へのリンクもリストします。 Builder は、この概要を応答テキストのすぐ下に表示します。チャンネルは設定から​​明示的に終了できます。古いコードはすぐに機能しなくなります。

Romergo の内容とユーザーに残るもの

私はこのアーキテクチャを関心の分離として考えるのが好きです。

Romergo は以下を提供します:

ユーザー エージェントは以下をもたらします。

インテリジェンスはアプリケーションに属しません。アプリは、このインテリジェンスが安全に動作できる場所を作成します。

通常の組み込み副操縦士を作ってみてはいかがでしょうか

組み込みの AI の方が説明が簡単で、有効化も簡単です。ユーザーがボタンを押すと、アプリケーションが選択したモデルを呼び出し、すべてが機能します。

ただし、その場合、Romergo は AI インフラストラクチャのオペレーターになる必要もあります。

パーソナルエージェントを使用する場合、これらすべてはユーザー側にすでに存在します。 Romergo は別の ChatGPT を構築しようとしていません。 ChatGPT、Claude、または他のエージェントに特化したワークスペースと明確なツールを提供します。

これはクリエイティブな編集者にとって特に興味深いものです。同じエージェントは、ユーザーが対話をどのように書くか、どのような口調を好むか、どの参考資料がすでに議論されているか、どの外部ツールを使用しているかを知ることができます。 Romergo は、1 つの背景を置き換えたり、シーンを再配置したりするためだけに、このシステム全体をコピーする必要はありません。

最も奇妙な点: エージェントは外部と内部の両方にいます

エージェントは物理的に Romergo に移動しません。そのモデルとエージェント ループは、元の AI クライアントで引き続き実行されます。

しかし、ユーザーの観点から見ると、エージェントはエディター内に存在します。

したがって、ここでは「アプリケーション内部の AI」と「MCP 経由で外部の AI」という表現は両方とも完全に正確ではありません。これはむしろ、アプリケーション セッションにおける外部エージェントの一時的な存在です。

この方向に進んだのは私が最初ではない

実験が成功した後、私は同様のアプローチを探し始めました。

エージェント クライアント プロトコル を使用すると、Zed や JetBrains などのエディターが外部コーディング エージェントに接続できるようになります。 Tidewave は、Claude Code、Codex、およびその他の ACP エージェントを実行中の Web アプリケーションの隣に配置し、それらにブラウザとランタイム コンテキストを渡します。 Obsidian Agent Client は、ノートのすぐ隣にクロード コード、コーデックス、ジェミニを表示し、アクティブなドキュメントと選択範囲を自動的に添付します。 marimo は、共有ワークスペースとしてライブ ノートブックを外部エージェントに提供します。

より一般的な実験もあります。 AG-UI は、ユーザー インターフェイスとエージェント バックエンド間の双方向通信を標準化します。 WebMCP は、Web ページが接続されたブラウザまたはデスクトップ エージェントで利用できるツールを登録することを提案しています。 エージェント アプリケーション プロトコル では、アプリケーションが UI およびドメイン ツールを所有し、外部エージェントが推論、履歴、および汎用ツールを所有するモデルについて説明します。

つまり、基本的なアイデアはすでにいくつかの形で存在しています。しかし、ほとんどの実装は、IDE、ローカル コーディング エージェント、または企業自体が展開するエージェントに重点を置いています。

Romergo の実験は、少し異なる質問のため、私にとって興味深いものでした。それは、パーソナル ユーザー エージェントが通常のクリエイティブ アプリケーションに入ることができたらどうなるでしょうか?

新しいモデルではありません。モデルの API キーではありません。組み込みのコパイロット アプリケーションではありません。すでに毎日使用しているエージェント。

便利さは問題の半分に過ぎない

外部エージェントがアプリケーション コマンドをリッスンしてプロジェクトを変更できるようになると、セキュリティはオプション機能ではなくなります。

1 つの OAuth 画面では答えられない質問が生じます。

現在のバージョンでは、ユーザーと時間によってチャネルを制限し、OAuth、サーバー スコープ、ワンタイム確認、アトミック コマンド クレーム、および明示的なライフサイクルを使用します。これはまだ実験段階ですが、重要な境界はエージェントの単なるガイドラインではなく、実行の一部になりました。

それを何と呼ぶか

まだ最終的なタイトルは決まっていないんです。

Bring Your Own AI は通常、独自の API キーまたはモデルの選択を意味します。ユーザーはモデルだけでなく、メモリ、ツール、エージェント ループも持ち込むため、Bring Your Own Agent がより身近になります。ただし、BYOA では、実験の重要な部分について説明していません。アプリケーションはエージェントに接続して、エージェントとのライブ セッションを維持することもできます。

おそらくこれは次のとおりです。

名前だけで新しい基準を考え出すつもりはありません。まず、そのようなモデルが Romergo の外でも有用かどうか、そしてそれが信頼されるためにはどのような境界が必要かを理解することが私にとってより重要です。

アプリケーションにはネイティブ AI が必要ない場合があります

現在、ほぼすべての製品が独自のアシスタントを組み込もうとしています。その結果、ユーザーは多くの個別の AI を所有することになります。1 つはエディターに、もう 1 つはメールに、3 番目はタスク システムにあります。それぞれに独自の短いメモリ、独自の制限、および独自の価格があります。

別のモデルも考えられます。

このアプリは、ワークスペース、ライブ コンテキスト、および特殊なツールを提供します。ユーザーはすでに信頼しているエージェントを連れてきます。エージェントは作業中にアプリケーションに参加し、タスクの完了を支援し、ユーザーと一緒に去ります。

これが独立した建築カテゴリーになるかどうかはまだわかりません。しかし今では、そのようなサイクルを組み立てることができ、実際に使用できることがわかりました。

しかし、実験することはとても楽しいことだと私は知っています。

開発ブログに戻る