Google Meet越しに相手の環境へプロンプトを入力したい — 既存手段と自作リレーの設計メモ

Google Meetでデモをしていると、画面共有で映っている相手のcodexにこちらからプロンプトを打ち込みたくなる。声で読み上げて相手にタイプしてもらうのは伝言ゲームで、プロンプトが長いほど崩れる。自分の環境でデモをやり直す手もあるが、それでは相手のログイン状態・相手のブラウザ・相手のリポジトリで動く様子を見せられない。この「相手の環境に私の指が届かない」問題の解決策を整理した。

結論

• 開発ゼロで済ませるなら「Chrome Remote Desktopのリモートサポート」が最短。相手側にホストアプリが入っていれば、ワンタイムコードの発行と接続承認だけで相手のデスクトップ全体をこちらが操作できる
• 相手がVS Codeでcodex CLIを動かしているなら「Live Shareの共有ターミナル」。こちらから相手のターミナルへ直接タイプできる
• デモの頻度が上がるなら、プロンプト入力に特化したリレーアプリを自作する価値がある。こちらの音声入力付きWebページから送ったプロンプトを、相手のPCで動く小さな受信プログラムがWebSocketリレー経由で受け取り、入力先へ注入する

開発ゼロで今日から使える手段

Chrome Remote Desktopのリモートサポートは、相手が12桁のワンタイムコードを発行してMeetのチャットに貼り、こちらがそのコードで接続を申請し、相手が承認する方式だ。相手のログイン状態・ブラウザのまま入力したい、という要望のど真ん中に刺さる。ただし初回は相手側にホストコンポーネントのインストールが必要で、会社の管理端末では利用を禁止されていることもある。加えて画面全体を渡すことになるので、気軽に頼める相手は限られる。

VS Code Live Shareは共有ターミナルに書き込み権限を付けられる。共有ターミナルは初期設定では読み取り専用で、相手（ホスト）に書き込み可で共有し直してもらう一手間がある。そのかわり、相手のターミナルで動くcodex CLIにこちらのキーボードから直接プロンプトを打てる。渡すのはターミナルだけで済むから、デスクトップ全体を渡すより頼みやすい。なおLive Shareは現在メンテナンスモードで、新機能の追加は止まっている。

なお、Zoomにはリモート制御機能があるが、Google Meetにはない。会議ツールを変えられる関係なら、それが一番話が早い。

自作するなら: プロンプト・リレーの設計案

既存手段への不満は3つある。フル遠隔操作は重い。ターミナル共有は相手の環境を選ぶ。そして、どれも音声認識を内蔵しない（OSの音声入力を重ねる手はあるが、話してから確認して送る、という流れまでは作り込めない）。そこで、プロンプト入力だけに絞ったリレーを考える。

構成は3点で足りる。

• リレーサーバ: Cloudflare Worker + Durable ObjectのWebSocketルーム。Meetのチャットに貼った接続URLで合流する
• 送信側（自分）: Webページ。テキスト入力欄と、Web Speech APIの音声入力ボタンを置く。喋った内容がテキストになり、そのまま送れる。ChromeのSpeechRecognitionは音声を外部サーバーへ送って認識することがあるので、機密に触れる内容を喋るデモでは注意が要る
• 受信側（相手）: 届いたプロンプトを入力先に注入する常駐プログラム。注入先で2バリエーションに分かれる

受信側のバリエーションは注入先で選ぶ。

1. CLI版 — npx prompt-beam --room ABC123 のような1コマンドで常駐させる。node-ptyのラッパー経由でcodexやclaudeを起動してもらい、届いたプロンプトを、後述の承認を経てからstdinに流し込む。tmuxがある環境なら tmux send-keys でも足りる
2. Chrome拡張版 — 相手のブラウザに拡張を入れてもらい、届いたテキストを対象サイトの入力欄に挿入する。相手のログイン状態がそのまま使えるので、Codex webのようなログイン必須のWebサービスに強い。ただし任意のサイトに書き込めるわけではなく、対象ドメインへのホスト権限と、入力欄のDOM構造に合わせたサイトごとのアダプターが要る。Manifest V3では、WebSocketを維持するためのService Workerのkeepaliveも必要になる

安全設計は、デフォルトを承認モードにする。着信したプロンプトはcodexのstdinへ直行させず、まず受信プログラム側の画面に隔離して表示する。改行や制御文字を取り除いたうえで、相手が承認して初めて注入する。先にPTYへ流してしまうと、改行入りのペイロードがその場で実行されて承認の意味がなくなるからだ。リモートから任意の指示が流れ込む仕組みである以上、実行の最終判断は相手側に残し、信頼できる相手とのデモに限って自動実行へ切り替える。

参加の認証を6桁コードに頼らないことも決めておく。6桁は100万通りしかなく総当たりに耐えないので、接続URLには長いランダムトークンを埋め、短い有効期限と試行回数制限を付けて会議ごとに使い捨てる。画面で読み合わせる短いコードは「同じ部屋に入ったか」の確認用にとどめる。リレーサーバがプロンプト本文を読める設計にするか、送受信の間でエンドツーエンド暗号化するかも、作るなら先に決めておきたい点だ。

どの方式を選んでも、相手に何か1つ入れてもらう手間はゼロにできない。リモートから入力する以上これは避けられない。その手間を最も小さくできるのが、npxワンライナーかChrome拡張かの2択だ。

まとめ

• 次のデモはChrome Remote Desktopで乗り切れる。開発ゼロで、相手の手間は初回のホスト導入とコード共有・接続承認だけ
• 頻度が上がったらプロンプト・リレーを作る。入力先が相手のターミナル（codex CLI）ならCLI版、相手のブラウザ（ログイン済みWebサービス）ならChrome拡張版
• どちらの受信側を作るかは「相手の環境で何を見せたいか」で決まる。まず既存手段でデモを1回回し、不満の正体を確かめてから作っても遅くない