なぜ Commander か

Commander は、マルチエージェントをブラックボックスにしたくないエンジニアのためにあります。

グラフビルダーなし。YAML なし。「うまく動いたはず」なし。
API キー 1 つ → タスク分類 → トポロジ選択 → すべての決定をストリーム → すべての出力を検証。

一目で

観点	Commander	典型的なエージェントフレームワーク
始め方	自然言語タスク + API キー 1 つ	グラフ構築、YAML/JSON ワークフロー
トポロジ	5 正規トポロジを自動選択（SINGLE · CHAIN · DISPATCH · ORCHESTRATOR · REVIEW）	エッジを自分で配線
可視性	ライブ SSE：思考・ツール・品質ゲート	事後ログ、または不透明な実行
品質	5 層ゲート（幻覚・一貫性・完全性・正確性・安全）	任意 / 自前実装
プロバイダー	25、自動検出 + フェイルオーバー	多くの場合 1–2 を第一級サポート
本番	サーキットブレーカー、DLQ、saga、WAL チェックポイント、マルチテナント	デモ優先、運用は後付け
埋め込み	CLI、TypeScript SDK、HTTP API、Python クライアント	通常は 1 面
テスト	6700+	ばらつき大

いつ Commander を選ぶか

次に当てはまるなら Commander を選んでください。

• 実行中のエージェントの動きを 見たい
• トポロジとエージェント数を毎回手で調整したくない
• 本番での フェイルオーバー、チェックポイント、監査可能性を重視する
• 視覚的グラフビルダーより CLI / SDK を好む
• セキュリティ敏感、またはマルチテナント負荷を扱う

別の手段を検討してください。

• ツール付きの単発チャット完了だけで足りる
• セルフホストなしのフルマネージド SaaS だけ欲しい（クラウドは ロードマップ）
• Node ランタイムなしの純粋 Python インプロセス枠組みを好む

よくあるアプローチとの比較

「単一エージェント + ツール」のコーディングアシスタント

コーディングアシスタントは 1 モデル・1 スレッドに最適化されます。Commander は エージェントのチーム、自動スケール（1–20）、検証済みの多段作業に最適化されます。素早い編集はアシスタント、並列調査・レビュー・編成が必要なら Commander。

グラフ型オーケストレーター（LangGraph 系など）

すべてのエッジを 自分で設計したい とき、グラフ枠組みは強力です。Commander がトレードするのは：

1. タスク種別と複雑度からトポロジを選ぶ審議（deliberation）
2. デフォルトのストリーミング可観測性
3. 別プラットフォーム層なしのブレーカー・DLQ・補償などの運用プリミティブ

必要ならトポロジとエージェント数を強制できます。

マルチエージェント「crew」系ライブラリ

役割プロンプトと協調パターンでは crew 系が強いです。Commander が足すもの：

• 意思決定ツリー付きの正規トポロジ
• 25 バックエンド横断のプロバイダーフェイルオーバー
• 品質ゲートと本番リカバリ経路
• スクリプトだけでなく運用向け Web コンソール + HTTP API

根拠（正直に）

主張	場所
25 プロバイダー	プロバイダー, providerRegistry.ts
5 トポロジ	トポロジ決定木
18 組み込みツール	ツール
6700+ テスト	CI / ベンチマーク
ストリーミング	エージェントランタイム, run --stream / watch モード
セキュリティ姿勢	セキュリティ

ベンチマークはモノレポ内の再現可能なスクリプトであり、マーケ用スクリーンショットではありません。実行方法は ベンチマーク を参照してください。

60 秒で触る

git clone https://github.com/PStarH/Commander.git
cd Commander && pnpm install
export OPENAI_API_KEY=sk-...
npx tsx packages/core/src/cliEntry.ts run "explain this repository architecture" --stream

成功の見え方：審議の分類 → トポロジ選択 → エージェント手順 → ストリーム上の品質ゲート。

次へ

• クイックスタート — 5 分チェックリスト
• クックブック — エンドツーエンドのレシピ
• アーキテクチャ概要 — エンジンの仕組み