Agent Orchestrator（以下 AO）は、コーディングエージェントを「1タスク＝1エージェント＝1ワークスペース」で並べ、その上に計画だけを担当する常駐エージェントを1つ置くデスクトップアプリだ。Untrivial-ai/agent-orchestrator（★10,690・Apache-2.0）が実体で、中身はGo製のローカルdaemonとElectron/Reactのフロントエンドである。この種のツールは「何種類のエージェントに対応」「自律的にCIを直す」といった見出しで語られやすいが、同梱ビルドを起動すると数字が1つ合わない。実際に v0.12.9 の dmg を落として動かし、数えた。

v0.12.9同梱daemonでao agent lsを実行し、登録エージェントが27行返ることを示す実測ログ
実測。v0.12.9 の dmg に同梱された daemon を起動して `ao agent ls` を実行すると27行返る。READMEの見出しは「26 coding agents supported」で、差分は一覧表に載っていない omp（OMP）1件だった（macOS arm64・2026-08-31）

この記事のポイント（30秒でわかる）

・正体：コーディングエージェントを並列で走らせ、PR・CI・レビューの状態まで1枚のKanbanに集約するAgent IDE。Go daemon＋Electron
・他と違う点：worker（実装役）の上に project orchestrator（計画・分解・委譲だけを持つ常駐エージェント）を置く2階建て構造
・実測①：登録エージェントは 27種（READMEは26）。エージェントのCLI自体は同梱せず、利用者が入れた実体を起動する
・実測②：テレメトリは既定で外に出ない。2つの環境変数を両方onにしたときだけ PostHog へ6回接続した
・注意：ドキュメントが未実装と明記する機能がある（tracker連携は実行時に何もしない）

エージェント基盤の全体像から入りたい場合は、AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証 を先に読むと、AOがどの層の製品かを掴みやすい。

Agent Orchestratorとは——workerの上に「計画する層」を置くAgent IDE

AOの単位は worker だ。1つのworkerが1つのタスク、1つのコーディングエージェント、1つの隔離ワークスペースを持つ。Git管理下のリポジトリなら、workerごとに専用ブランチと git worktree が切られる。タスク・会話・ターミナル・変更ファイル・ブラウザプレビュー・PR・CI・レビュー状態が、そのworkerに最後まで紐づいたままになる。

AOのKanban画面。worker sessionがWorking / Needs you / In review / Ready to mergeのレーンに分かれて並んでいる
AOのKanban。カードの位置は人が動かすのではなく、セッション・PR・CI・レビューの事実からAOが導出する（公式README掲載のスクリーンショット、v0.12.9）

ここまでなら「worktreeでエージェントを並列化するツール」で、既に何本もある。AOが別物になるのはその上の層だ。

AOの4層構成。L4 project orchestrator、L3 worker、L2 coding agent 27種、L1 git worktreeとブランチ
AOの構造。L4に常駐の計画エージェントがいることが、単なる並列実行ツールとの構造的な差になる

project orchestrator はプロジェクト単位で1つ存在する常駐の計画エージェントで、個別タスクより一段上——製品の方向性、技術的な方針、優先順位、作業の順序——を扱う。会話がプロジェクトスコープで保持されるため、目標・決定・制約・過去の検討経緯が残る。そこにリポジトリの文脈と、現在動いているworker・PR・CI・レビューというライブの状態を合わせて計画する。計画が実行可能になったら、orchestratorがタスクへ分解し、workerを起こし、文脈を渡し、進捗を追う。

役割分担は明確に切られている。orchestratorは計画と委譲だけを持ち、実装・テスト・コミット・PRはworkerが持つ。この線引きがあるおかげで、「計画役が勝手にコードを書き始めて文脈が混ざる」という多エージェント運用でよくある崩れ方を構造的に避けている。

project orchestratorが複数のworkerを調整し、それぞれに絞った文脈を渡している画面
orchestratorがworkerへタスクと文脈を配る画面。計画履歴・リポジトリ文脈・AOのライブ状態を合わせて判断する（公式README掲載、v0.12.9）

Kanbanのレーンは人の主観でなく事実から決まる。Working（実装中または次の指示待ち）、Needs you（ブロック・入力待ち・CI失敗・変更要求・シグナル喪失）、In review（レビュー待ちのPR）、Ready to merge（承認済みまたはマージ可能）の4つで、SCM observer がPRごとにポーリングして得た事実がそのままレーンになる。

flowchart TD A["タスクを渡す
（人 or orchestrator）"] --> B["worker生成
専用ブランチ + worktree"] B --> C["コーディングエージェントが実装
Chat または native TUI"] C --> D["PR作成"] D --> E{"SCM observerが観測
CI・レビュー・コンフリクト"} E -->|"失敗・変更要求"| F["同じworkerへ差し戻し
（agent nudge）"] F --> C E -->|"通過"| G["Ready to merge"]

実測：同梱ビルドが登録するエージェントは27種、READMEは26種

READMEには「26 coding agents supported」とあり、アイコン付きの一覧表が続く。この表の項目を数えると確かに26だった。しかし配布物の側を数えると合わない。

v0.12.9 の agent-orchestrator-darwin-arm64.dmg（222MB）をマウントすると、Contents/Resources/daemon/ao にGo製のdaemonが入っている。これはCLIも兼ねているので、データディレクトリを隔離して起動し、カタログを直接引いた。

# v0.12.9 同梱daemonを隔離環境で起動して、登録エージェントを数える
export AO_DATA_DIR=/tmp/ao-data AO_TELEMETRY_EVENTS=off AO_TELEMETRY_REMOTE=off
"/Volumes/.../Agent Orchestrator.app/Contents/Resources/daemon/ao" daemon &
"/Volumes/.../Agent Orchestrator.app/Contents/Resources/daemon/ao" agent ls | tail -n +2 | wc -l
# => 27

結果は 27。起動ログにも登録簿がそのまま出るので、二重に確認できる。

・ao agent ls の行数（ヘッダを除く）＝ 27
・daemon起動ログの registered=[...] 配列の要素数＝ 27
・READMEの一覧表の項目数＝ 26

差分は omp（OMP） 1件だった。READMEのアイコン表には無いが、docs/STATUS.md には「OMP Chat は native omp acp を使い、OMP 15.0.0 以降が必要」と書かれている。つまり隠し機能ではなく、READMEの一覧表の更新が1件遅れているだけと読むのが妥当だ。とはいえ「26種対応」を判断材料にする人にとっては、実際に入るものが1つ多い。

ここで重要なのは、AOがエージェントのCLIを同梱しないことだ。STATUS.mdは「AOは各harnessの既存のバイナリ・認証・環境の解決をそのまま再利用し、providerのCLIを同梱しない」と明記している。実際、まっさらな環境で ao agent ls を叩くと27種すべてが needs install と出る。AOを入れただけでは1つも使えず、使いたいエージェントは自分で入れて認証しておく必要がある。

確認したこと 実測値 出典・方法
登録エージェント数 27 同梱daemonの ao agent ls（ヘッダ除く行数）
READMEの記載 26 README.md の Supported agents 見出し
差分 omp（OMP） 両者の突き合わせ。STATUS.mdには記載あり
初期状態の利用可否 27種すべて needs install 隔離した AO_DATA_DIR での初回実行
Chat対応（native driver） 9種 STATUS.md：Codex・Claude Code・Cursor・OpenCode・Droid・Kimchi・Kimi・Pi・OMP

なお、daemon側のラベルはREADMEより具体的だった。READMEが「Grok」「Muse」「Qwen」「Vibe」と書く4件は、実機では Grok Build・Muse Code・Qwen Code・Mistral Vibe と表示される。

Orca・ruflo・Claude Code Agent Teams との違いを層で分ける

「エージェントを並列で走らせるOSS」は既に何本もあり、AOだけを見ても位置づけが掴めない。どの層の問題を解いているかで並べると差がはっきりする。

  Agent Orchestrator Orca ruflo Claude Code Agent Teams
形態 デスクトップアプリ（Electron＋Go daemon） デスクトップアプリ（ADE） Claude Code/Codexのプラグイン Claude Code本体の実験的機能
隔離の単位 worker＝1タスク1worktree worktree並列 スウォーム内エージェント セッション
常駐する計画層 あり（project orchestrator） 無し（1プロンプトから扇形展開） 無し（スウォーム制御） 無し（mailbox＋task list）
PR・CI・レビューの観測 あり（レーンを事実から導出） 限定的 無し 無し
対応エージェント 27種（実測） 30種以上 Claude Code / Codex 中心 Claude Codeのみ
ライセンス Apache-2.0 MIT — —

同じ「並列エージェント」でも、Orcaは実行環境（1つの指示を複数のworktreeへ扇形に広げる）、rufloは既存エージェントに載せるスウォーム基盤、Agent Teamsは1つのCLI製品の中の機能である。AOはそこに、計画を保持し続けるプロセスを製品の中心に置いた点で層が1つ多い。詳しくは Orcaとは｜Claude Code・Codexを並列実行するAIエージェントIDE（ADE）の使い方 と ruflo｜Claude Code/Codexにネイティブ統合する100エージェント・スウォーム基盤 を並べて読むと、同じ問題への設計解の違いが見える。

ただし、リポジトリの説明文にある「CI修正・マージコンフリクト・コードレビューを自律的に処理する」という表現は、実装を読むと少し慎重に受け取ったほうがいい。STATUS.mdの「Shipped」側にある記述は、SCM observerがPRごとにポーリングして事実を取り、それをlifecycleへ流し込み、CI失敗・レビュー指摘・マージコンフリクトについてエージェントに nudge（差し戻し）を送る、というものだ。検知して担当エージェントへ投げ返すところまでが出荷済みの範囲で、修正そのものはエージェントが行う。人間が結果を見る必要が消えるわけではない。

workerのセッション画面にPR・CI・レビュー状態とエージェントレビューが並んで表示されている
PRとCI、レビュー状態をworkerの隣に置く画面。変更要求は同じ担当エージェントへ戻る（公式README掲載、v0.12.9）

もう1つ、READMEに書かれていないが同梱されている機能がある。GitLab対応だ。daemon起動ログには GitHub と並んで provider=gitlab のtracker初期化が出るし、バイナリにはマージリクエストのAPIパス（/projects/%s/merge_requests）や、自己管理GitLabホストの許可リスト（AO_GITLAB_ALLOWED_HOSTS）を扱うコードが含まれている。READMEとSTATUS.mdはGitHubのフローだけを説明しているので、GitLab運用の完成度は未検証だが、存在自体は同梱ビルドで確認できる。

インストールと、最初の1タスクまでの手順

配布はデスクトップアプリのみで、CLIを別途入れる必要はない（daemonはアプリが起動する）。macOS（Apple silicon / Intel）、Windows、Linux（AppImage / deb / rpm）向けのバイナリが Releases にある。v0.12.9 のmacOS arm64版で222MB、Windows版で130MBだった。

導入から最初のタスクまでは4段階になる。

・①アプリを入れる：Releasesから自分のプラットフォーム向けを落として開く。自動更新が有効になる
・②使いたいコーディングエージェントを入れて認証する：AOはCLIを同梱しないので、この手順を飛ばすと27種すべてが needs install のまま何も動かない
・③リポジトリを登録する：AOに管理させたいリポジトリを指すと、以後workerごとにブランチとworktreeが切られる
・④タスクを渡す：やることが明確なら New task で直接worker生成、曖昧なら orchestrator と相談して計画を作らせてから委譲する

エージェントの導入状況は、ao CLI から一覧できる。公式の docs/cli/README.md は「シェルから直接CLIを使うときは、先に ao start かデスクトップアプリで daemon を起動しておくこと」と書いており、ao agent ls のような製品コマンドは daemon が動いていないとエラーになる。

# 先に daemon を起動してから、対応エージェントと導入・認証状況を一覧する
ao start
ao agent ls
# ID / LABEL / INSTALL / AUTH の4列。INSTALLが needs install のものはAOからは起動できない

本記事の実測では ao を PATH からではなく、アプリバンドル内の実体（Agent Orchestrator.app/Contents/Resources/daemon/ao）を絶対パスで直接叩いている。 デスクトップアプリを正規にインストールしたとき ao が PATH に載るかどうかは未検証で、公式ドキュメントもソースチェックアウトから go build する例しか示していない。上のように短く書けなかった場合は、バンドル内の実体を絶対パスで呼べば同じ結果になる。

AO内でコーディングエージェントのネイティブなターミナルUIがそのまま動いている画面
AOは独自UIに寄せきらず、エージェント本来のターミナルUIをそのまま埋め込める。構造化Chatとの切り替えが可能（公式README掲載、v0.12.9）

インターフェースは 構造化Chat と エージェント本来のターミナルUI の2択で、AOはセッション1つにつき1つのインターフェースだけをdaemon側で確定させる。Claude Code と Codex については、同じネイティブ会話をAOのセッションやworktreeを変えずにTUIとChatの間で移送できる仕組みがある。ただしSTATUS.mdは、実行中のツール呼び出しやバックグラウンドプロセスを別のコントローラへ引き継ぐ標準的な手段は存在しないため、移送は「受理済みの作業を完了させるか、中断するか」に留まると明記している。

使い方でつまずきやすい3点

Agent Orchestrator の使い方で最初に引っかかるのは、いずれもAOの設計思想から素直に導かれるものだ。実際に触って気づいた点を挙げておく。

・「対応27種」は「すぐ使える27種」ではない：前述のとおりAOはCLIを同梱しない。ao agent ls の INSTALL 列が needs install の行は、AOからは起動できない。まず使いたいエージェントを1つ入れて認証を通し、その1つで最初のタスクを回すのが早い
・worktreeを切るのでリポジトリの前提条件がある：workerはブランチとworktreeを持つため、Git管理下でない、あるいはリモートも既定ブランチも解決できないディレクトリでは通常のworkerを作れない。その場合はブランチ無しの「Scratch worker」側になる
・daemonは1つしか立たない：AOは起動中のdaemonのバイナリパスを ~/.ao/running.json に記録しており、別の場所にあるAOから2つ目を起動しようとすると「別のAO daemonが既に動いている」と拒否される。開発版と製品版を同時に触るときに踏みやすい

なお、~/.ao/running.json には稼働中daemonのPID・ポート・起動時刻が入っている。AOが応答しないときは、まずこのファイルと ao status を突き合わせるのが早い。

テレメトリを3条件で実測した——既定では外に出ない

AOは匿名テレメトリを送る。そして公式ドキュメントは、その中に1つだけ匿名でない値があることを自分から書いている。プロジェクトのリモートのGitHubオーナー名（リポジトリ名・パス・URLは送らない）で、個人リポジトリではそれが本人のユーザー名になるため「この値だけは匿名ではない」と docs/telemetry.md が明言している。隠している話ではないので、こちらは実際に送信が起きるのはどの条件かを数えた。

方法はシンプルで、HTTPS_PROXY / HTTP_PROXY をローカルのログ用リスナに向け、daemon起動から ao agent ls 実行を挟んで40秒間、us.i.posthog.com:443 への CONNECT 行を数える。すべての接続はプロキシ側で502を返して遮断しているので、実際にPostHogへ届いたデータは無い。陽性対照（送信が確実に起きる条件）を用意したのがポイントで、これが無いと「0回だった」が「測れていないだけ」と区別できない。

3条件でのPostHogへの接続試行回数。既定0回、EVENTS=onのみ0回、EVENTS=onかつREMOTE=posthogで6回
実測。2つのゲートを両方通したときだけ送信が発生する。陽性対照があるので、上2行の0回は「測れていない」ではなく「起きていない」と言える
条件 AO_TELEMETRY_EVENTS AO_TELEMETRY_REMOTE CONNECT回数 install_id生成
既定（直接起動） 未設定（＝off） 未設定（＝off） 0 されない
ローカル捕捉のみ on 未設定（＝off） 0 されない
陽性対照 on posthog 6 される

読み取れることは3つある。

・ゲートは2段ある。config.go の既定値は AO_TELEMETRY_EVENTS も AO_TELEMETRY_REMOTE も off で、どちらか片方でもoffなら送信は0だった。片方だけ有効にしても外へは出ない
・直接起動したdaemonは既定で沈黙する。これは telemetry.md の「デスクトップアプリ無しでdaemonを動かす場合、イベント捕捉もリモート送信も既定でoff」という記述の通りで、実測で再現した
・インストール識別子は送信が有効になって初めて作られる。telemetry_install_id は条件3でのみ生成され、AO_DATA_DIR の指定に従った

陽性対照で実際に飛ぼうとしたイベントは ao.daemon.started・ao.cli.invoked・ao.app.active の3種で、宛先は POST https://us.i.posthog.com/capture/、失敗時は2回まで再送していた。ao.cli.invoked があることから分かるように、実行したサブコマンド名は送信対象に入る。ただしソースを読むと、送られるのは任意の文字列ではなく agent・daemon・doctor・import などの許可リストに載ったトークンだけで、引数そのものは送られない。telemetry.mdが「シェルコマンドの引数・コマンド履歴は送らない」と書いているのと矛盾しない。

ここは実測していない：本記事が測ったのはdaemonを単体起動した場合である。telemetry.md は「製品版のデスクトップ／モバイルではリモート送信が有効」「パッケージ版デスクトップは自分が起動するdaemonのテレメトリも有効にする」と明記しており、アプリから普通に使う場合の既定はONだ。停止するなら AO_TELEMETRY_RENDERER / AO_TELEMETRY_EVENTS / AO_TELEMETRY_REMOTE の3つをoffにして再起動する。macOSでFinderやDockから起動すると、シェル設定ファイルの環境変数は継承されない点も公式が注意喚起している。またモバイルアプリにはアプリ内のオプトアウトが無い。

送信先の整理もしておくと、製品テレメトリは PostHog（us.i.posthog.com）、エラー報告は Sentry で、後者はGo製daemonの依存関係（getsentry/sentry-go）として同梱されている。ドキュメントが停止手順として挙げる環境変数は3つだが、config.go にはこのほか AO_TELEMETRY_METRICS・AO_TELEMETRY_DISABLED_EVENTS・AO_TELEMETRY_POSTHOG_HOST・AO_SENTRY_DSN といったつまみも実装されている。

ネットワーク面はもう1点確認した。daemon稼働中の待受ソケットは 127.0.0.1:3001 の1つだけで、外部に開くポートは無い。config.go はバインドホストを設定不可（loopback-only by design）としており、実測と一致する。ただし AO_DATA_DIR を指定しても、~/.ao/ 配下には supervise.sock・browser.sock・running.json が作られた。データディレクトリの指定はDBやworktreeには効くが、実行時ソケットは移動しない。

STATUS.mdが引く「出荷済み」と「未実装」の線

AOの特徴として挙げておきたいのが、docs/STATUS.md の存在だ。「現在 main で何が出荷されていて、何が途中か」をベンダー自身が213行にわたって書いている。この種のファイルを持つOSSは多くない。導入判断の材料として実際に使えるので、未実装側の要点を挙げる。

・tracker連携は実行時に何もしない：GitHub trackerのアダプタは存在するが、daemonの観測ループもエージェントのライフサイクル→Issue反映も未実装で、STATUS.mdは「実行時には何もしない」と明記している
・生のPR/trackerイベントの露出は未完：SCM observerが事実を書き込みデスクトップは要約を消費するが、生の pr_* / tracker_* イベントをライブ購読者や ao session get へ出す部分は未着手
・実行中ツールの移送は不可：前述のとおり、実行中のツール呼び出しを別コントローラへ引き継ぐ手段は無い

逆に、STATUS.mdが保守的すぎる箇所もあった。ブラウザ自動化について同ファイルは「macOS/Linuxのパッケージングと手動のライフサイクル受け入れはリリース検証作業として残っている」と書いているが、v0.12.9のmacOS arm64ビルドには Resources/agent-browser/ に当該バイナリが実際に同梱されている。ドキュメントが実態より慎重な側に倒れている例で、READMEの「26」が実態より1つ少なかったのと合わせて、このリポジトリのドキュメントは実装より数日〜1リリース遅れて追随していると見ておくとよい。

同梱物を数えると、AOが「薄いランチャー」ではないことも分かる。

同梱物 中身 位置づけ
daemon/ao Go 1.25.7製・31MB。CLIとdaemonを兼ねる 本体
acp-runtime/ Node実行環境と claude-agent-acp 等のACPアダプタ Chatモードの土台
tmux/bin/tmux tmux本体 ターミナルセッションの永続化
agent-browser/ Vercel製 agent-browser（チェックサム固定） worker専用ブラウザ
コーディングエージェントのCLI 同梱しない 利用者の既存インストールを再利用

ドキュメント内のリンクが、404か「別プロジェクト」に着く

もう1つ、実際に踏むと困る点を見つけた。STATUS.mdは未実装項目の根拠としてIssueへのリンクを張っているが、そのリンク先が github.com/aoagents/agent-orchestrator/... になっている。実際に叩くと、Issue 6本はすべて404だった。

そして残る1本、マイルストーンへのリンクはさらに厄介だ。こちらは404にならず200で開くが、着地先は aoagents/ReverbCode のマイルストーン1——まったく別のプロジェクトのページである。エラーが出ないぶん、リンクが壊れていることに気づけない。

事情は追える。旧URL ComposioHQ/agent-orchestrator は現在 Untrivial-ai/agent-orchestrator へ301転送されており、リポジトリが移管されたことが分かる。同梱バイナリのGoモジュールパスも github.com/aoagents/agent-orchestrator/backend のままで、aoagents という別の名義がコードに化石として残っている。ところが aoagents org 側の agent-orchestrator は別のリポジトリ（aoagents/ReverbCode）へ改名済みで、Issueのパスまでは引き継がれない。

厄介なのは、org名を現行のものに読み替えても復旧しないことだ。たとえばSTATUS.mdが「tracker連携は未実装」の根拠として挙げる #112 を現行リポジトリで開くと、まったく無関係な fix: return ActivityDetection from getActivityState に着地する。番号の由来が別リポジトリの履歴なので、読者が自力で正しいIssueへ辿り着く手段が無い。未実装項目の進捗を追いたい場合は、Issue番号ではなくSTATUS.mdの本文そのものを定点観測するしかない。

Agent Orchestrator を試す前に確認したいこと

最後に、開発の勢いと注意点を数字で押さえておく。

・★10,690・fork 1,494（2026-08-31時点）。リポジトリ作成は2026-02-13で、半年ほどでこの規模
・最新リリースは v0.12.9（2026-08-27）。直近1週間で97コミット以上が入っており、更新は非常に速い
・オープンな課題は857件だが、内訳はIssue 435件・PR 422件。GitHub APIの open_issues_count はPRを含むので「Issue 857件」ではない
・ライセンスはApache-2.0。LICENSEファイルの実体でも確認した

リリース資産のダウンロード数からは、利用者層の偏りも読める。v0.12.9 の資産で最も引かれているのは自動更新用のマニフェスト latest-mac.yml で 24,804回、Windows向けの latest.yml が5,003回、Linux向けが1,048回だった。これらはインストール数ではなく、既に入っているAOが更新確認のために叩いた回数なので絶対数を人数として読むことはできない。ただし同じ性質の3ファイルを比べる限り、稼働中のインストールはmacOSに大きく偏っているとは言える。インストーラ本体の方も傾向は同じだった。ただしこのリリースは同じビルドを2通りの命名で二重に配布している（agent-orchestrator-win32-x64.exe と Agent.Orchestrator.Setup.0.12.9.exe はどちらも130.5MBで同一物）ため、片方だけ数えると platform ごとに落ちる量が変わる。両方の命名を含めて platform ごとに合計すると、macOS 1,327回・Windows 695回・Linux 358回だった。macOS以外で使う場合は、相対的に踏まれていない経路を通ることになる点は意識しておきたい。

つまり「小さく枯れたツール」ではなく、大きく速く動いている最中の製品である。READMEの数字が1つ遅れていたのも、STATUS.mdのリンクが移管に追随していないのも、この速度の裏返しと見るのが自然だ。

AOが向かない場面もはっきりしている。単一のエージェントで1タスクずつ順番に片付ける進め方なら、AOが用意する隔離・観測・計画の層はそのまま余分な複雑さになる。worktreeの管理もKanbanのレーンも、同時に複数の作業が走っていて初めて意味を持つ仕組みだからだ。また現時点ではIssueトラッカーとの連携が実行時に動かないため、「AIがIssueを拾って自動で片付ける」ところまでは製品側が用意していない。AOが埋めているのは、あくまでタスクを渡してからPRがマージ可能になるまでの区間である。

導入を検討するなら、判断は次の3点で分かれる。

・複数のコーディングエージェントを実際に併用しているか：AOの価値は27種を1枚の盤面に集約するところにあり、Claude Code1本で完結しているなら本体の機能で足りる可能性が高い
・PR・CI・レビューまで含めて追いたいか：worktree並列だけが目的ならより軽い選択肢がある。AOが独自なのはPR・CIの事実をレーンに変換する部分
・計画を持ち回る相手が欲しいか：project orchestratorは常駐で計画履歴を保持する。ここが要らなければ、AOの2階建て構造は過剰になる

テレメトリについては、既定でONになるのはデスクトップアプリ経由での利用時である点だけ押さえておけばよい。送信内容は公式が具体的に列挙しており、匿名でない値（GitHubオーナー名）も自己申告している。止めたい場合は環境変数3つで止まり、daemon単体起動なら最初から送信が発生しないことは本記事で確認した通りだ。

参照ソース

・Untrivial-ai/agent-orchestrator（公式リポジトリ・README） — 製品概要、対応エージェント一覧、インストール手順
・docs/STATUS.md（v0.12.9） — 出荷済み機能と未実装項目の切り分け
・docs/telemetry.md（v0.12.9） — 送信内容・PostHog利用・停止手順
・backend/internal/config/config.go（v0.12.9） — 環境変数の既定値、loopback-only の明記
・docs/cli/README.md（v0.12.9） — ao CLIの起動前提とコマンド→daemonルートの対応
・AO 公式ドキュメント（aoagents.dev） — インストールとエージェント設定