AgentDock レビュー: ノード構成でエージェントの決定性を設計する
Build Anything with AI Agents
ひと目でわかる
- これは何？
- AgentDock Core は TypeScript 製のバックエンド向けエージェントフレームワークで、すべての機能をノードとして扱い、どこで LLM 推論を使いどこで固定の実行経路を通すかを開発者が選べる点を設計の中心に置いている。MIT ライセンスのベータ段階であり、Next.js のリファレンス実装が同梱されている。
- 誰に向いている？
- 採用を検討すべきなのは、TypeScript でバックエンドからエージェントを組み、実行経路のどこを LLM に任せどこを固定するかを自分で決めたいチームである。逆に、GUI のワークフロービルダーをすぐ使いたい場合や、特定ベンダーのマネージド実行環境に処理を寄せたい場合には向かない。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 64 日前です。
- 何の言語で書かれている？
- 主に MDX です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
決定性を設定項目として扱うという発想
エージェントフレームワークの多くは、LLM の出力が毎回変わることを前提に、プロンプトとツール呼び出しの連鎖をどう組むかに焦点を当てる。AgentDock が前面に出す configurable determinism は少し違う。README は AgentNode 自体が非決定的であることを認めたうえで、ワークフロー側は定義済みのツール実行パスによってより決定的にできると説明している。つまり、システム全体を決定的にするのではなく、LLM 推論に委ねる区間と固定の実行経路を通す区間を開発者が選ぶ、という整理である。
この立場は、業務システムにエージェントを組み込むときの実際の悩みに合っている。請求書の読み取りのように毎回同じ手順を踏ませたい処理と、調査のように探索の幅を残したい処理は、同じアプリの中に共存する。AgentDock はその境界をノードという単位で引かせる。README の Deterministic Workflows の節では、LLM 推論の有無にかかわらず、一般的なワークフロービルダーで馴染みのある予測可能な実行パスが使えると述べられている。決定性を保証する機能ではなく、設計時に配分を決めるための考え方だと考えたほうが正確である。
ノードがすべての単位になる
設計原則として README が挙げるのは、Simplicity First、Node-Based Architecture、Tools as Specialized Nodes、Configurable Determinism、Type Safety の五点である。このうち構造を決めているのは二番目と三番目で、能力はすべてノードとして実装され、ツールはそのノードシステムを拡張する特殊なノードとして位置づけられる。エージェントとツールを別の抽象として扱う設計も多いが、AgentDock は同じ土台に載せる。
この統一には実務上の帰結がある。ツール呼び出しの前後に検証や変換を挟みたいとき、ツール側だけ特別扱いする必要がなく、ノードの並びとして表現できる。反面、何でもノードになるということは、単純な関数呼び出しで済む処理にもノードの作法が要るということで、小さなスクリプトを移植するときは記述量が増える。README が Simplicity First を掲げているのは、この抽象の重さを意識してのことだと読める。Type Safety については、TypeScript の型が全体に通っていると説明されており、ノード間で受け渡すデータの形がコンパイル時に効く範囲では効く。
Core とクライアントの二層構成
AgentDock は二つの部品からなると README は説明する。一つ目が AgentDock Core で、エージェントを構築・配備するためのバックエンド優先のフレームワークであり、フレームワーク非依存かつプロバイダ非依存を狙うとされている。二つ目がオープンソースのクライアントで、Core の利用者かつリファレンス実装としての Next.js アプリケーションである。動作例は hub.agentdock.ai で公開されている。
この分離は採用判断のときに効く。Core だけを自前のバックエンドに組み込み、公式クライアントは読む対象として扱う、という使い方が想定しやすい。リファレンス実装が同じリポジトリにあるため、ノード定義やワークフローの組み方の実例をコードとして追える。ただし README から読み取れるのは構成の説明までで、Core とクライアントの間の具体的なインターフェースやバージョンの対応関係は示されていない。切り離して使う前提なら、その境界を自分でリポジトリのコードから確認する必要がある。
README に並ぶエージェント例の中身
デモとして四つのエージェントが紹介されている。Dr. Gregory House は search、deep_research、pubmed の三ツールを多段のワークフローで組み合わせる診断推論用のエージェントである。Cognitive Reasoner は search、think、reflect、compare、critique、brainstorm、debate の七つを設定可能なワークフローで並べ、問題を分解して解く。History Mentor はベクトル化した歴史知識に search を組み合わせ、Mermaid の図をその場で描画する。Calorie Vision は画像から栄養素の内訳を構造化データとして取り出す。
注目したいのは、これらが単一のプロンプトではなくツールの並びとして提示されている点である。Cognitive Reasoner の七ツールは、いずれも推論の一段階を明示的なノードに切り出したものだと読める。critique と reflect を別ノードに分ける設計は、モデルに自己批判を一度にまとめてやらせるより制御しやすい半面、呼び出し回数が増える。README にはレイテンシやコストの数値は一切示されていないので、多段構成が実運用でどの程度の待ち時間になるかは、この資料からは判断できない。
導入手順は README からは確定できない
ここは正直に書く。提供された README には、インストールコマンド、環境変数のキー、設定ファイルのパス、CLI のサブコマンドが一切載っていない。ドキュメントへのリンクは hub.agentdock.ai/docs に向いており、リポジトリの構成から読み取れるのは、agents/ 配下にエージェントごとのディレクトリがあり、Next.js クライアントが同梱され、ライセンスファイルが LICENSE にある、という程度である。
したがって「このコマンドを実行すれば動く」と書くことはできない。導入を検討するなら、まず hub.agentdock.ai/docs のセットアップ手順を読み、agents/dr-house のような既存エージェントのディレクトリを開いて、ノード定義と設定がどのファイルに置かれているかを確認するのが順序になる。環境変数やプロバイダの指定方法もそこで確定させる必要がある。この記事の時点で確認できたのは、MIT ライセンスであること、Beta 表記が README のバッジにあること、デフォルトブランチが main であることまでである。
向かない場面と、代わりに選ぶもの
AgentDock が向かないのは、ノーコードのワークフロービルダーを求める場合である。README は AgentDock Pro を近日提供と予告し、ビジュアルなワークフロービルダーや高度なオーケストレーションをその中に置くと説明している。つまり GUI での構築は現行のオープンソース部分の外にある。コードを書かずに組みたい読者にとって、このリポジトリは土台にはならない。
別の選択肢として、同じくノードとワークフローを中心に据える LangGraph 系のアプローチがある。違いは抽象の置き方である。LangGraph はグラフの状態遷移を前面に出し、ノードはグラフ上の頂点として定義される。AgentDock は能力そのものをノードとして扱い、ツールをその特殊形と位置づける。エージェントの能力一覧をノードの集合として眺めたいなら後者が読みやすく、状態機械としての制御を細かく書きたいなら前者の語彙のほうが素直である。どちらが優れているという話ではなく、設計の出発点を能力に置くか遷移に置くかの差である。
Beta と MIT をどう受け止めるか
README のバッジは Status: Beta を示している。最近のリリース情報は取得できておらず、バージョン番号や変更履歴から安定性を測ることはできない。ベータ段階のフレームワークに業務の中心を預けるなら、ノードの型定義やワークフローの記述方法が変わる前提で、アプリ側のコードを薄く保つ設計が要る。
ライセンスは MIT である。条文の解釈についてはここで助言しないが、MIT は一般的に緩い条件のライセンスとして知られ、派生物の公開義務を課す種類のものではない。ただし README には AgentDock Pro というクラウド製品が予告されており、オープンソース部分と商用部分の境界がどこに引かれるかは現時点の資料からは分からない。Core に依存を寄せるほど、この境界の変化が影響しうる。導入前に LICENSE ファイルとドキュメントの両方を確認しておく価値はある。
編集部の結論
採用を検討すべきなのは、TypeScript でバックエンドからエージェントを組み、実行経路のどこを LLM に任せどこを固定するかを自分で決めたいチームである。逆に、GUI のワークフロービルダーをすぐ使いたい場合や、特定ベンダーのマネージド実行環境に処理を寄せたい場合には向かない。着手前に確認すべきは、README が掲げる configurable determinism が実際のノード定義でどう表現されるか、そして Beta 表記のままで API が動く前提を置いてよいかである。リポジトリの agents/ 配下にある dr-house や cognitive-reasoner のノード構成を読み、自分のユースケースで固定したい経路をノード境界として切れるかを確かめてから依存を決めるのが現実的である。
コミュニティノート