Mission ControlはAIエージェント運用の責任線を見える化する

エージェントの上に置く運用レイヤー

Mission ControlはAIエージェントそのものではなく、エージェントランタイムを運用するためのセルフホスト制御プレーンです。推論やツール実行のループを置き換えるのではなく、その周囲にある派遣、実行の観察、失敗のレビュー、費用の追跡を一つのローカルダッシュボードへ集めます。READMEはOpenClaw、Claude Code、Codexなどを接続対象として挙げつつ、どれか一つの製品に属するものではないと説明しています。

この位置づけから、Mission Controlを導入してもランタイム固有の設定や権限管理が消えるわけではありません。ダッシュボードが示す現在状態だけで完了と判断せず、実行者、ツール呼び出し、承認、結果、検証の証拠を記録する運用が必要です。READMEのフィールドノートも、ログは何が動いたかを示し、完了レシートや確認済みの成果物が何が終わったかを示すと区別しています。

タスク、品質ゲート、完了レシート

タスクボードは受信トレイ、割り当て、実行、レビュー、品質レビュー、完了という流れを持ちます。Aegisの品質レビューでは、タスクがdoneへ進む前に承認記録を要求します。単にエージェントが成功ステータスを返したかを見るのではなく、レビューの段階と承認の記録を運用上の境界として扱える構成です。

運用面にはアクティビティストリーム、スケジュール、アラート、Webhook、ログ、トークン使用量、コスト表示が含まれます。定期タスクのテンプレートからcronスケジュールで日付付きの作業を作ることもREADMEに記載されています。これらは作業の流れを追うための面であり、AIの出力が正しいことを自動で証明する機能ではありません。品質ゲートを置いても、レビュー基準と検証者の判断は別に設計する必要があります。

SQLiteとワークスペースの所有境界

制御プレーンのローカル状態はSQLiteに保存され、ランタイムはワークスペースを認識します。通常の共有ワークスペースではデプロイ単位のランタイム統合を利用できますが、strict workspaceでは基盤リソースにワークスペース所有権が付くまで統合を止めます。複数の利用場所を一つの管理面へ集めるとき、所有関係を曖昧にしないための境界です。

ゲートウェイはタスク、プロジェクト、エージェント、スケジューラー、Webhook、アラート、コストの作業では必須ではありません。一方、ライブセッションのメッセージには接続済みのランタイムゲートウェイが必要です。この差を見落とすと、RESTでタスクを作成できたことを、実行中のセッションを同じ経路で操作できることと取り違えます。READMEではデータの既定場所を.data/とし、スタンドアロン構成ではMISSION_CONTROL_DATA_DIRで絶対パスを指定できます。

導入はローカルとDockerから選ぶ

ソースから始める場合、READMEはNode.js 22以上とpnpmを要件に挙げています。リポジトリをcloneして bash install.sh --local を実行し、http://localhost:3000/setup で最初の管理者アカウントを作成します。ヘッドレスアクセスが必要ならSettingsに表示されたAPIキーを取得します。Nodeとpnpmを自分で管理している環境では、nvm use 22、pnpm install、pnpm devという手動経路もあります。Windows向けにはPowerShellの ./install.ps1 -Mode local が記載されています。

Dockerでは docker compose up が基本経路で、GHCRのマルチアーキテクチャイメージも利用できます。ネットワークから接続する構成では、READMEは docker-compose.hardened.yml を重ねる方法と、永続データ、TLS終端、ゲートウェイ接続、スタンドアロンビルドを扱うデプロイガイドを案内しています。アルファソフトウェアという警告があるため、導入方式だけでなく、更新時にスキーマや設定を確認できる手順も準備しておくべきです。

REST、CLI、MCPが分ける操作経路

ゲートウェイなしで最短の作業ループを組むならREST APIを使います。Settingsで得たMC_URLとMC_API_KEYを環境変数に設定し、/api/agents/register へPOSTしてエージェントを登録し、/api/tasks へPOSTしてタスクを作成します。エージェントは /api/tasks/queue?agent=scout を取得して自分のキューを確認できます。READMEはハートビート、タスク結果、キューの動作、CLI相当、MCP設定を最初のエージェント用クイックスタートに分けています。

CLIではエージェント一覧、タスクキュー、agentとtaskのイベント監視を扱えます。MCPサーバーはClaudeのMCP設定から追加でき、RESTの契約はopenapi.jsonに置かれます。実行中のインスタンスは /docs に対話型リファレンス、/api/docs にOpenAPI JSONを提供します。Web UIだけを使うのではなく、操作を自動化するか、監視するか、別のエージェントから呼ぶかによって入口を選べる点がこの構成の実用的な部分です。

ランタイムごとの対応深度を確認する

READMEが挙げる観測対象にはOpenClaw、Claude Code、Codex、CrewAI、LangGraph、AutoGen、Claude SDKのワークフローがあります。ただし、対応一覧がそのまま機能の同等性を意味するわけではありません。アダプターの深さはランタイムごとに異なると明記されているため、利用する実装についてagent setupとCLI integrationのガイドを個別に読む必要があります。

エージェント画面は登録状態、ハートビート、セッション、設定、ローカルランタイムの検出、ワークスペースファイルをまとめます。知識面ではメモリブラウザ、関係グラフ、スキルレジストリ、ローカルスキル同期を扱います。これだけの表示面があっても、ランタイムの権限、利用するモデル、ツールの副作用まで同じ品質で抽象化されるとは限りません。導入評価では、自分の主なランタイムで登録、実行、失敗、レビュー、証跡の各段階がどこまで通るかを一つの小さな作業で確認するのが妥当です。

認証とネットワーク公開の前提

READMEはネットワークへ公開する前にセキュリティガイダンスを読むよう警告しています。TLSリバースプロキシとMC_ALLOWED_HOSTSを設定しない状態では信頼できるネットワークに置き、広い範囲から接続する前に生成された認証情報を置き換えるか安全に保管します。本番相当のコンテナ構成には強化Composeオーバーレイを使い、エージェントメッセージ、スキルパッケージ、Webhook、MCPコンテンツは信頼できない入力として扱います。

アクセス面にはセッションCookie、APIキー、Googleサインイン、ロールチェックがあり、入力境界ではZodを使う構成がREADMEに示されています。SECURITY.mdを通じた脆弱性報告も案内されています。しかし、認証や監査の画面があることと、公開環境での安全性が立証されていることは同じではありません。プロジェクトはアルファ段階で、API、スキーマ、設定がリリース間で変わる可能性があります。MITライセンスも保証なしで提供する条件なので、変更を吸収できる更新計画と、管理画面へ到達できるネットワーク範囲の制御を用意すべきです。

編集部の結論

Mission Controlは、複数のエージェントやランタイムを扱い、誰がタスクを担当し何が実行されどの結果を承認したかを一つの画面で追いたいチームに向きます。単一エージェントをCLIだけで管理できる人、管理型のマルチテナントSaaSを求める人、アルファ版のAPI変更を受け入れられない運用には適しません。導入前にNode.js 22以上、pnpmまたはDocker、認証情報の保管、TLSと許可ホスト、接続するランタイムごとのアダプター範囲を確認してください。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes