目指すのは、4つのAIエージェントの状況を人が別々のログや状態表から読み解くのではなく、Opusの総合チャットを開けば全体像と「人の判断待ち」が分かる仕組みです。

そのための軸は、VPS上に総合窓口を置き、IDEとスマートフォンを同じ作業環境への入口として使うこと。Roo Codeとの連携やClineのTUI（ターミナル上で使う対話型画面）は候補になりますが、既存機能だけで要件を満たすと決めつけず、実際に試す範囲を切り分ける必要があります。

総合チャットを「画面」に、記録を「復旧の仕組み」にする

全体の進捗は総合チャットで確認できるようにし、過去のログを人が掘り起こさない設計を目指します。作業画面は、次の3つを中心に構成できます。

• 固定の状態表示：4つの担当枠の稼働状況、直近の重要イベント、進行中のタスク、人の判断待ち件数を表示します。状態はプログラムが更新し、Opusに毎回説明文を作らせない設計が適しています。
• Opusの総合チャット：全体の進捗を説明し、調査・実装・レビューを調整して、人の判断が必要な点を示します。
• 判断の操作欄：特定の変更を承認する、却下する、追加の根拠を求める、またはana-architectで分析する、といった操作をまとめます。

総合チャットは既存のOpus枠を使い、ana-architectは必要なときに起動する分析フローとします。常駐する担当を5つに増やす案ではありません。

ここでいう「持続するやり取りの記録」は、別の進捗表を人に読ませるものではありません。再接続時に未処理の判断事項を復元し、承認を対象の依頼・案の版・実行範囲に結び付け、同じ承認が重複実行されるのを防ぐための記録です。計画上のタスクリストの代わりでも、実装担当の会話に総合チャットの全履歴を引き継ぐ仕組みでもありません。

Roo CodeのMCP連携で分かること、まだ分からないこと

Roo Codeの公式ドキュメントでは、MCP（Model Context Protocol）を使って外部のツールやサービスに接続できると説明されています。13 この仕組みを使えば、たとえば以下のような連携を設計できます。

• 全体の状態や、人の判断待ち項目を問い合わせる
• 指定したレビュー結果や分析結果を読む
• 対象の依頼・版にひも付いた判断を送信する

一方、MCPでツールに接続できることは、バックグラウンドのイベントがRooのチャットに自動で届くことや、専用の承認ボタンを追加できることの証明ではありません。そうした機能は、今回確認できた情報だけでは判断できません。

「リアルタイムの表示」「固定の状態欄」「承認操作」を一画面にそろえることが必須なら、Rooの会話欄に頻繁な状態通知を詰め込むより、小さなIDEパネルを別に設ける案も検討できます。ただし、パネルとVPSで別々の実行キューを持たせず、状態と判断の同じ仕組みを参照することが前提です。

また、承認は人の明確な操作で行う必要があります。Opusの提案や、ツールの自動承認を、作業方針の変更に対する人の許可とみなしてはいけません。

まず試す候補はCline公式TUI

Clineの公式TUIは、ターミナル上の対話、計画の確認、操作の承認に対応しています。6 CLIも対話型の利用と、無人実行を含むワークフローを提供しています。2 また、公式のAgent Teams機能はSDK・CLI・Kanbanで利用できますが、現時点ではVS CodeやJetBrainsの拡張機能には適用されません。1

このため、Cline公式TUIは総合窓口の候補として試す価値があります。ただし、次の機能がすでにそろっていると考えるのではなく、接続や表示を個別に確かめる必要があります。

• 外部のPi担当4枠の状態や稼働状況をまとめて表示する
• 独自の判断用資料を提示する
• 再接続後に、業務上の承認待ちを復元する
• ファイルツリーや差分表示が必要な水準を満たす

ClineCoreのSDKには、セッションの永続化、メッセージ履歴、ツール承認のコールバックなどが用意されています。これは薄い連携を作る際の土台になり得ますが、今回想定する業務上の判断ルールがすでに実装されていることを意味するものではありません。4

安全面にも注意が必要です。公式CLIのリファレンスでは、プロンプトを直接渡した場合、デフォルトで実行モードになり、自動承認が有効になると説明されています。3 本番の作業環境でいきなり試すのではなく、隔離した環境、ツールの権限、承認の設定を先に確認する必要があります。

今回確認できた資料からは、必要な要件を満たすRoo TUIの改造版や、特定のcline-termuxプロジェクトの存在を確認できませんでした。根拠のないプロジェクト名やインストール手順を挙げるのは避けます。

スマホとIDEは、同じVPS上の作業環境につなぐ

まずはスマートフォンに別のAIエージェントを入れるのではなく、SSHクライアントやTermuxからVPS上の同じtmuxウィンドウに接続する経路を試す方法があります。

• IDEからリモート端末で同じ作業環境に入る方法は、IDE内で使えますが、Roo Code本来のチャット画面ではありません。
• スマートフォンからも同じ総合窓口に接続し、状態を確認して判断待ちに対応できます。
• 画面が切断されてもタスクを再起動せず、人の判断が必要な作業は本人が不在の間は待機させます。
• 人がIDEで自由に編集することは妨げず、同じ箇所への並行変更が起きた場合は競合を検知して、人の編集内容を保護する方針にします。

いずれも現時点で実装済みと確認された機能ではなく、構成案です。接続の安定性や競合時の挙動は、実環境で確かめる必要があります。

まずは「人の判断がつながる最小ループ」から

いきなり全体を移行するのではなく、現行計画と同じADRに、総合窓口の最小構成を小さな成果物として追加する案が考えられます。現在の計画と関連するADRが対象です。

1. 総合画面で4枠の状態、全体の進捗、人の判断待ちを確認できる。
2. Solのレビューでゲートへの懸念が出たら、関連タスクを止めて判断依頼を作る。
3. 人が探索に使うモデルを選び、ana-architectに分析させる。分析結果には、ゲートを維持・緩和・置き換える場合の影響を含める。
4. 人が特定の版の変更を承認し、バックグラウンドでは許可された範囲だけを続行する。
5. 画面を閉じて再接続しても、依頼と処理結果を確認でき、同じ承認が二重に実行されない。

選定の順序としては、まずCline公式TUIを試し、既存の対話機能を活かせるなら薄い連携を追加する。足りない場合に限って軽量な総合画面を用意し、Roo Codeのチャット連携は任意の入口として残すのが無理のない進め方です。バックエンドの作業をRooのチャット接続に依存させないことも重要です。

なお、今回確認できたのは公開ドキュメントであり、ソフトウェアのインストール、ファイル変更、テスト実行、バックグラウンドタスクの起動は行っていません。4枠の連携やスマートフォンからのアクセスも、まだ実機で検証されていません。

目指すのは、4つのAIエージェントの状況を人が別々のログや状態表から読み解くのではなく、Opusの総合チャットを開けば全体像と「人の判断待ち」が分かる仕組みです。

そのための軸は、VPS上に総合窓口を置き、IDEとスマートフォンを同じ作業環境への入口として使うこと。Roo Codeとの連携やClineのTUI（ターミナル上で使う対話型画面）は候補になりますが、既存機能だけで要件を満たすと決めつけず、実際に試す範囲を切り分ける必要があります。

総合チャットを「画面」に、記録を「復旧の仕組み」にする

全体の進捗は総合チャットで確認できるようにし、過去のログを人が掘り起こさない設計を目指します。作業画面は、次の3つを中心に構成できます。

• 固定の状態表示：4つの担当枠の稼働状況、直近の重要イベント、進行中のタスク、人の判断待ち件数を表示します。状態はプログラムが更新し、Opusに毎回説明文を作らせない設計が適しています。
• Opusの総合チャット：全体の進捗を説明し、調査・実装・レビューを調整して、人の判断が必要な点を示します。
• 判断の操作欄：特定の変更を承認する、却下する、追加の根拠を求める、またはana-architectで分析する、といった操作をまとめます。

総合チャットは既存のOpus枠を使い、ana-architectは必要なときに起動する分析フローとします。常駐する担当を5つに増やす案ではありません。

ここでいう「持続するやり取りの記録」は、別の進捗表を人に読ませるものではありません。再接続時に未処理の判断事項を復元し、承認を対象の依頼・案の版・実行範囲に結び付け、同じ承認が重複実行されるのを防ぐための記録です。計画上のタスクリストの代わりでも、実装担当の会話に総合チャットの全履歴を引き継ぐ仕組みでもありません。

Roo CodeのMCP連携で分かること、まだ分からないこと

Roo Codeの公式ドキュメントでは、MCP（Model Context Protocol）を使って外部のツールやサービスに接続できると説明されています。13 この仕組みを使えば、たとえば以下のような連携を設計できます。

• 全体の状態や、人の判断待ち項目を問い合わせる
• 指定したレビュー結果や分析結果を読む
• 対象の依頼・版にひも付いた判断を送信する

一方、MCPでツールに接続できることは、バックグラウンドのイベントがRooのチャットに自動で届くことや、専用の承認ボタンを追加できることの証明ではありません。そうした機能は、今回確認できた情報だけでは判断できません。

「リアルタイムの表示」「固定の状態欄」「承認操作」を一画面にそろえることが必須なら、Rooの会話欄に頻繁な状態通知を詰め込むより、小さなIDEパネルを別に設ける案も検討できます。ただし、パネルとVPSで別々の実行キューを持たせず、状態と判断の同じ仕組みを参照することが前提です。

また、承認は人の明確な操作で行う必要があります。Opusの提案や、ツールの自動承認を、作業方針の変更に対する人の許可とみなしてはいけません。

まず試す候補はCline公式TUI

Clineの公式TUIは、ターミナル上の対話、計画の確認、操作の承認に対応しています。6 CLIも対話型の利用と、無人実行を含むワークフローを提供しています。2 また、公式のAgent Teams機能はSDK・CLI・Kanbanで利用できますが、現時点ではVS CodeやJetBrainsの拡張機能には適用されません。1

このため、Cline公式TUIは総合窓口の候補として試す価値があります。ただし、次の機能がすでにそろっていると考えるのではなく、接続や表示を個別に確かめる必要があります。

• 外部のPi担当4枠の状態や稼働状況をまとめて表示する
• 独自の判断用資料を提示する
• 再接続後に、業務上の承認待ちを復元する
• ファイルツリーや差分表示が必要な水準を満たす

ClineCoreのSDKには、セッションの永続化、メッセージ履歴、ツール承認のコールバックなどが用意されています。これは薄い連携を作る際の土台になり得ますが、今回想定する業務上の判断ルールがすでに実装されていることを意味するものではありません。4

安全面にも注意が必要です。公式CLIのリファレンスでは、プロンプトを直接渡した場合、デフォルトで実行モードになり、自動承認が有効になると説明されています。3 本番の作業環境でいきなり試すのではなく、隔離した環境、ツールの権限、承認の設定を先に確認する必要があります。

今回確認できた資料からは、必要な要件を満たすRoo TUIの改造版や、特定のcline-termuxプロジェクトの存在を確認できませんでした。根拠のないプロジェクト名やインストール手順を挙げるのは避けます。

スマホとIDEは、同じVPS上の作業環境につなぐ

まずはスマートフォンに別のAIエージェントを入れるのではなく、SSHクライアントやTermuxからVPS上の同じtmuxウィンドウに接続する経路を試す方法があります。

• IDEからリモート端末で同じ作業環境に入る方法は、IDE内で使えますが、Roo Code本来のチャット画面ではありません。
• スマートフォンからも同じ総合窓口に接続し、状態を確認して判断待ちに対応できます。
• 画面が切断されてもタスクを再起動せず、人の判断が必要な作業は本人が不在の間は待機させます。
• 人がIDEで自由に編集することは妨げず、同じ箇所への並行変更が起きた場合は競合を検知して、人の編集内容を保護する方針にします。

いずれも現時点で実装済みと確認された機能ではなく、構成案です。接続の安定性や競合時の挙動は、実環境で確かめる必要があります。

まずは「人の判断がつながる最小ループ」から

いきなり全体を移行するのではなく、現行計画と同じADRに、総合窓口の最小構成を小さな成果物として追加する案が考えられます。現在の計画と関連するADRが対象です。

1. 総合画面で4枠の状態、全体の進捗、人の判断待ちを確認できる。
2. Solのレビューでゲートへの懸念が出たら、関連タスクを止めて判断依頼を作る。
3. 人が探索に使うモデルを選び、ana-architectに分析させる。分析結果には、ゲートを維持・緩和・置き換える場合の影響を含める。
4. 人が特定の版の変更を承認し、バックグラウンドでは許可された範囲だけを続行する。
5. 画面を閉じて再接続しても、依頼と処理結果を確認でき、同じ承認が二重に実行されない。

選定の順序としては、まずCline公式TUIを試し、既存の対話機能を活かせるなら薄い連携を追加する。足りない場合に限って軽量な総合画面を用意し、Roo Codeのチャット連携は任意の入口として残すのが無理のない進め方です。バックエンドの作業をRooのチャット接続に依存させないことも重要です。

なお、今回確認できたのは公開ドキュメントであり、ソフトウェアのインストール、ファイル変更、テスト実行、バックグラウンドタスクの起動は行っていません。4枠の連携やスマートフォンからのアクセスも、まだ実機で検証されていません。