Open Multi-Agentは目標から実行時DAGを組み立てるTypeScript基盤

グラフを書く代わりに目標を書く

Open Multi-AgentはNode.jsアプリへ追加できるTypeScriptのAIエージェント基盤です。READMEの中心的な説明は、コーディネーターが一つの目標から実行時にタスクDAGを作り、決定的なスケジューラーがチームを動かし、実行全体を検査、承認、再生できるデータとして残すというものです。固定のワークフロー定義を消す製品ではなく、動的計画を記録可能にする設計として読むのが正確です。

三つの実行入口を分ける

runTeam()は目標からチームを計画し、runAgent()は単一エージェントを動かし、runTasks()は明示したパイプラインを実行します。例ではresearcherとanalystをcreateTeamで定義し、sharedMemoryを有効にして比較結果を取得します。自動計画の自由度が不要な処理までrunTeamに入れると検証が難しくなるため、固定順序の処理はrunTasks、単発の専門処理はrunAgentと役割を合わせます。

APIキーなしで試せるデモ

Node.js 20以上が必要で、npm create oma-app@latest my-omaからスターターとランタイムを選び、依存関係を導入して決定的なローカルデモを起動できます。READMEはこのデモがAPIキーを要求せず、モデル呼び出しも行わず、スクリプト化された応答で実際のスケジューラーと結果集約を動かすと説明します。最初はここで実行順、DAGの読み戻し、オフラインRun Viewerを確認します。

プロバイダーと実行環境

既存バックエンドへはnpm install @open-multi-agent/coreで追加できます。サンプルはdefaultProviderにopenai、defaultModelにgpt-5.4を設定し、実際の実行にはOPENAI_API_KEYを使います。READMEはホスト型モデル、ローカルサーバー、OpenAI互換エンドポイント、AI SDKプロバイダーも案内していますが、各サービスの挙動や料金を保証する記述ではありません。

記録と承認を運用の中心に置く

READMEは各実行をinspect、approve、replayできる記録として扱い、結果にはagentResultsのような読み取り可能な情報を返します。採用時はプロンプト、計画されたタスク、依存関係、エージェント出力、トークン使用量、失敗と再試行がどこに保存されるかを確認します。共有メモリを有効にする場合は、エージェント間で何が見えるかをテストデータで限定します。

採用判断とライセンス

READMEには50以上の実行例、プロバイダーガイド、Core package guide、プロダクションチェックリストへのリンクがあります。これらは導入の入口であり、特定モデルの品質評価ではありません。CIでローカルデモを再実行し、同じ入力から同じDAGが得られるか、承認前に外部副作用が発生しないか、APIキーなしの経路が本当にネットワークを呼ばないかを確認してから実サービスへ進めます。

小さなPRレビューのスターターを使い、同じ目標を複数回実行してタスクDAGの順序と結果集約が安定するかを確認します。researcherの出力をanalystが参照する依存関係、sharedMemoryを無効にした場合の可視範囲、runTasksで明示した順序を個別に記録します。APIキーなしのデモではネットワーク要求を監視し、実プロバイダーへ切り替えた後はモデル名、プロンプト、トークン使用量、失敗時の戻り値を保存します。承認が必要なツール呼び出しを一つ用意し、承認前に外部ファイルやサービスへ副作用が出ないこと、再生時に同じ入力記録を参照できることを確認します。

OMAを業務処理へ入れる場合は、DAGが作られたことだけで成功と扱わない判断が必要です。入力目標が曖昧な場合にコーディネーターが作るタスク、依存関係の循環、エージェントが返さない場合の終了条件を確認します。結果集約に失敗した一部の出力が隠れず、どのエージェントの結果かを追跡できるかも調べます。プロバイダーの応答を記録したリプレイで外部モデルを呼ばずに同じ集約を再実行し、承認後だけファイル変更やAPI呼び出しを許可します。モデル変更時は同じテストを繰り返します。

実験結果には実行時のNode.js版、パッケージ版、モデル名、入力目標を記録します。これにより、DAGの変化がコード変更によるものか、プロバイダー応答によるものかを後から切り分けられます。

OMAの検証では、モデルの返答とスケジューラーの責任を分けて記録します。外部副作用を持つタスクには承認を置き、失敗したタスクと成功したタスクを集約結果から追跡できるようにします。

導入前には、対象版のリリースと実行環境を記録します。入力と出力を固定した小さな試験を作り、成功だけでなく失敗時の状態も保存します。設定ファイルの既定値を確認し、変更した値を一覧にします。権限は必要な範囲に絞り、管理者操作と通常利用を分けます。ログには時刻、版、対象、結果を残します。外部サービスを使う場合は通信先と認証の境界を確認します。更新時は同じ試験を再実行し、以前の結果との差を見ます。素材にない性能や安全性を数値として補いません。READMEの機能説明と実際の動作が異なる場合は、動作を優先して原因を調べます。

編集部の結論

複数のエージェントに調査やレビューを分担させ、その実行記録を読み返したいTypeScriptチームに適しています。モデルの出力だけを信頼して自動処理を丸投げする用途には注意が必要です。まずAPIキー不要の決定的ローカルデモでDAG、集約結果、Run Viewerの表示を確認し、その後に実プロバイダーを一つだけ接続して失敗時の記録と承認経路を検証します。

公式情報源

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