UNITARES

エージェントの作業は、それを開始したプロセスの終了後も続きます。コーディングセッションが再起動したり、 調査エージェントがコンテキストを失ったり、タスクが別のランタイムに移ったりします。ログには 各実行の内容は残りますが、実行間のつながりは残りません。そのつながりがなければ、次のエージェントは 行き詰まった方法を繰り返したり、すでに修正された主張に基づいて行動したり、以前の判断の根拠となった 証拠を失ったりする可能性があります。

UNITARES は、そのつながりを保つために運用するサーバーです。MCP または HTTP を話すエージェントやモデルなら、どれでも接続でき（Claude Code、Codex、Hermes Agent とのすぐに使える連携を用意しています）、調査結果、レビュー、成果を運用者が所有する1つの記録に書き込めます。後から別のエージェントやあなた自身が記録を読み返し、それぞれの情報がどこから来たのかを確認できます。

記録からわかること

質問	仕組み
誰が発言したのか？	ID と系譜：記録への書き込みはすべて、それを行ったプロセスに紐付けられ、後継プロセスはどのプロセスを引き継ぐのかを宣言できます。
何が根拠なのか？	主張と証拠：調査結果は、特定のコンテキストウィンドウの外に、その情報源や訂正内容を保持します。新しい調査結果が古いものに取って代わると、古い調査結果から新しい調査結果へリンクされます。
誰が異議を唱えたのか？	ガバナンスに基づくレビュー：異議、条件、およびその解決状況は、それらが関係する作業に紐付いて保持されます。レビューを依頼することと、レビューに合格することは同じではありません。
何が起きたのか？	結果の根拠付け：テスト、ビルド、タスクの結果は、それらを予測したチェックインに紐付けて記録されます。
後継プロセスは何を復元できるのか？	再構築：新しいプロセスは、行動を起こす前に、過去の調査結果、未解決のレビュー条件、結果を検索またはエクスポートできます。

さらに2つの要素が記録を支えます。ランタイムポリシー：各チェックインは、理由とともに proceed、guide、pause のいずれかを返します。pause の場合、レビューまたは復旧によって解除されるか期限切れになるまで、そのプロセスのチェックインと新しい調査結果は拒否されます。セカンドオピニオン：設定すると、consult は別の接続済みモデル（ローカルの Ollama、vLLM、LM Studio、llama.cpp、またはオーケストレーター経由の Claude、Codex、Antigravity）に問い合わせ、その回答をタスクとともに保持します。

動作を見る

エージェント A（Codex）がバグを見つけ、記録して終了します。後にエージェント B（Claude Code）が 本当の原因を見つけ、A の調査結果に取って代わる調査結果を記録します。エージェント C（Hermes Agent）は再起動後に A のタスクを引き継ぎ、コードに手を加える前に（読み取りには ID は不要です） 記録を確認します。検索結果には、置き換え済みと示された A の調査結果と、B の調査結果へのリンクが 表示されます。その後、C は A のタスクを引き継ぐことを宣言します。

# Agent A (Codex)
start_session  {"force_new": true}                                     -> agent A's id
store_finding  {"summary": "upload retry test is flaky", ...}           -> finding a
record_result  {"outcome_type": "test_failed", ...}

# Agent B (Claude Code), in its own session, later
start_session  {"force_new": true}                                     -> agent B's id
store_finding  {"summary": "upload retry fails on clock skew", ...}     -> finding b
use_tool       {"tool_name": "knowledge", "arguments": {"action": "supersede", "discovery_id": "<b>", "supersedes_id": "<a>"}, ...}

# Agent C (Hermes Agent), after A's restart
search_shared_memory {"query": "upload retry test"}   -> finding a (superseded, points to b), finding b
start_session  {"force_new": true, "parent_agent_id": "<A's id>", "spawn_reason": "explicit"}

エージェントが記録を読むことを強制するものはありません。Claude Code と Codex のプラグインは、 セッション開始時に記録を参照します。よりシンプルな引き継ぎを、呼び出しごとに確認できます： 2つのプロセスを記録したウォークスルー。

インストール

Homebrew プレビュー（Apple Silicon 搭載デスクトップ Mac におすすめ）：cirwel/unitares tapを使うと、サービスをネイティブにインストールできます。インストールと初回セットアップの手順に従ってください。 パッケージ版の unitares update は、書き込み処理の停止、検証済みバックアップ、マイグレーション、以前の状態への復元、書き込み処理の再開後の詳細なヘルスチェック（停止したままの場合はスキーマ検証）を調整します。この機能が導入される前の keg では、tap の一度限りの手動移行を使用してください。 tap がソースからビルドし、Apple Silicon 搭載 macOS のみをサポートしている間は、プレビューの表記が残ります。

Docker Compose（すべてのプラットフォームに対応）：Git、curl、Docker Compose をインストールした状態で、次のコマンドを実行すると、ローカルスタックの最新の公開リリース（サーバー、AGE と pgvector を備えた PostgreSQL、Redis、調整プレーン）が起動します。ローカルのセマンティック検索とハイブリッドランキングを利用するにはdocker-compose.full.ymlを追加するか、コアプロファイルを使って最初の 2 つだけを実行してください。

v=$(curl -fsSL https://raw.githubusercontent.com/cirwel/unitares/master/PUBLISHED_VERSION) && git clone --branch "v$v" --depth 1 https://github.com/cirwel/unitares.git && cd unitares && docker compose up -d --wait

• エンドポイントと更新： MCP クライアントを http://localhost:8767/mcp/ に接続するか、http://localhost:8767/dashboard でダッシュボードを開いてください（Docker のクイックスタート）。Docker では、./scripts/unitares update がデータベースをバックアップし、マイグレーションを適用して、詳細なヘルスチェックを検証します（更新）。
• 1 台につき 1 つのスタック： Docker と Homebrew は別々のデータを保持します（インストール方法の選択）。コンテナー名は固定されているため、別のチェックアウトを起動する前に、以前のチェックアウトで docker compose down（-v なし）を実行してください（stop では不十分です。停止したコンテナーも固定の container_name 値を保持し、restart: unless-stopped により、停止していないコンテナーは Docker デーモンの再起動時に復帰するためです）。または、所有者を最初に確認する管理ランチャー（scripts/install/launch.sh）を使用してください。

エージェントとモデルを接続する（エージェントの統合）：

• Claude Code と Codex： unitares-governance-pluginが MCP、ライフサイクルフック、スキル、ファイル単位の編集リースを連携します（スタックのリースプレーンを介するため、同じチェックアウトで並行作業しても、別のエージェントのファイルを上書きしません）。
• Hermes Agent と OpenAI 互換クライアント： ホストアダプター。
• その他のエージェント、モデル、ホスト型コネクター： Streamable HTTP MCP（stdio のみ対応するクライアントには npx mcp-remote、Claude.ai や ChatGPT などのホスト型コネクターには専用のパブリックリスナーで Bearer / OAuth を利用）、Python SDK（pip install unitares-sdk）、または常駐エージェントランタイム。
• オプションのサーバー側モデル（モデルを選択）： デフォルトではモデル接続は設定されておらず、コアレコードは API キーなしでモデルを使わずに実行できます。./scripts/unitares model を実行して、consult とプロセス内レビュー用にローカルの OpenAI 互換サーバー（Ollama、vLLM、LM Studio、llama.cpp）を接続するか、異なるファミリー間で CLI レビューを行うためにエージェントオーケストレーターを追加してください。

対象ユーザー

複数の長時間稼働する AI エージェントを、ベンダーをまたいで、自ら管理するインフラ上で運用しており、エージェント間で共有する作業記録を再起動や引き継ぎ後も保持する必要がある運用者向けです。

エージェントがすべて1つのリポジトリ内で作業するなら、git とイシュートラッカーで十分な場合があります。UNITARES は、複数のランタイムにまたがり、単一のリポジトリやセッションを超えて続く作業を対象としています。

サンドボックスでも、出力バリデーターでも、ホスト型エージェントプラットフォームでもありません。評価やガードレールと並行して動作し、それらに取って代わるものではありません。エージェントのループは実行しません。プラグインのフックと編集リースがエージェントの作業を調整し、一時停止すると、そのプロセスからのチェックインと新たな知見の登録のみを拒否します。

全体の仕組み

UNITARES は、複数の AI エージェントを運用するための、セルフホスト可能な説明責任インフラストラクチャです。単一オペレーター向けのフェデレーションカーネルが、独立したランタイムを MCP または HTTP 経由でオペレーターが管理する単一のサーバーに接続します。そこでランタイムは、モデル、ツール、ランタイム自体をそれぞれ維持したまま、永続的な記録を共有します。ランタイム同士は、独自のトランスポートまたは A2A を介して連携します。UNITARES はその背後にある記録であり、ランタイム間のトランスポートではありません。これにより、コーディング、研究、バックグラウンド、常駐型エージェント向けの、オペレーター所有の説明責任レイヤーが実現します。アクティビティログに追加されるのは、来歴と置き換えの記録です。主張と証拠、レビュー、結果は、それを記録したプロセスに紐づいたまま保持され、置き換えられた主張には後継の主張が記録されるため、レビューや後日の再構成に役立ちます。

ストレージには PostgreSQL と Redis を使用し、外部のモデル API は必須ではありません。クイックスタートでは AGE バックエンドを起動し、知見間のリンクを保存します。プレーンな postgres バックエンドには置き換えリンクがなく、全文検索のみが利用できます。チェックインに対するポリシーアクションは、行動状態の推定値から決定されます。これはランタイムの固有受容の一形態です。

各主張について、何が測定され、何が未測定なのかは、証拠と限界およびレビュアーガイドをご覧ください。

まずはこちら

目的	ガイド
試してみる	インストール → 2プロセスのウォークスルー
エージェントまたはアプリケーションを接続する	MCP 統合 · Python SDK
デプロイを運用する	運用者マニュアル
製品とアーキテクチャを理解する	製品定義 · アーキテクチャ
関連する研究を読む	証拠と限界 · 論文 · 公開データセット
貢献する	貢献ガイド · 開発ガイド
その他すべて	ドキュメント一覧

引用とライセンス

Kenny Wang（ORCID 0009-0006-7544-2374）、 CIRWEL Systems。バージョン付きの引用情報は CITATION.cff をご覧ください。

@misc{wang2026unitares,
  author = {Wang, Kenny},
  title  = {{UNITARES}: Information-Theoretic Governance of Heterogeneous Agent Fleets},
  year   = {2026},
  doi    = {10.5281/zenodo.19647159}
}

Apache License 2.0。LICENSE と NOTICE をご覧ください。