AgentField: エージェントをAPIとして扱うGo製コントロールプレーン

エージェントの呼び出しをAPIの粒度に揃えるという発想

AgentFieldが解こうとしているのは、エージェント間の呼び出しをアプリケーションコードの中に散らかさないことだ。READMEは「Build agents like APIs. Run ten thousand of them like microservices.」と述べ、エージェントをフロントエンド、バックエンド、他のエージェント、cronジョブから通常のAPIと同じように呼べる存在として位置づける。対象読者は、単発のプロトタイプではなく、複数のエージェントが連鎖する処理を本番に置きたい開発者である。エージェントのロジック自体はPython、Go、TypeScriptのいずれかで書き、ルーティング、調整、メモリ、非同期実行、可観測性はコントロールプレーン側が受け持つ。ここで重要なのは、フレームワークがエージェントの思考そのものを規定するのではなく、呼び出しの配送と再試行という分散システム寄りの責務を引き受けるという切り分けだ。

reasonerデコレータがRESTエンドポイントになるまで

READMEのPython例では、Agentオブジェクトをnode_idとversion、ai_configを指定して生成し、@app.reasoner(tags=[...])を付けたasync関数を定義する。app.run()を呼ぶと、この関数がPOST /api/v1/execute/researcher.researchとして公開される。関数内部ではapp.ai()でLLMを呼び、app.call(f"{app.node_id}.research", ...)で自分自身を含むエージェントを名前で呼び出す。例ではasyncio.gatherで複数のサブ質問を並列に投げ、その結果を再度app.ai()で統合する。READMEのコメントは、この1リクエストが数千のエージェントにファンアウトし、コントロールプレーンが各分岐のキュー投入、リトライ、トレースを行うと説明している。ブローカーやキューのセットアップ、タイムアウト設定は不要と明記されている。つまりデータフローは、呼び出し側から見るとHTTPリクエスト1本だが、内部ではコントロールプレーンを経由した再帰的な呼び出しグラフになる。例にあるdepth >= 3の打ち切りは、この再帰が無制限に広がらないようにするための、アプリケーション側の責務として書かれている点に注意したい。

導入はinstall.shとaforge、そしてmacOSの常駐挙動

導入手順はREADMEに明示されている。curl -fsSL https://agentfield.ai/install.sh | bashを実行すると、afコマンドに加えてコーディングハーネスのaforgeが~/.agentfield/binに配置される。ハーネスが不要な場合は--no-aforgeで省略できる。macOSではインストーラがコントロールプレーンのログイン時起動をlaunchdに登録し、メニューバーアイコンも追加する。この常駐は--no-trayを付けることで回避できる。停止方法としてREADMEが挙げているのはaf service stopかメニューバーアイコンで、素のkillはクラッシュと見なされて再起動されると説明されている。af service statusはヘルス状態と処理中の作業を表示する。エージェントの生成は、Claude Code、Codex、Gemini CLI、OpenCode、Aider、Windsurf、Cursorといったコーディングエージェント内で/agentfieldに続けて仕様を貼り付ける形をとる。READMEの例では、クレーム処理、リスクスコアリング、パターン検出、低信頼度判断への人手承認を含む仕様を渡すと、エージェント、コントロールプレーン、REST APIエンドポイントが接続済みのDocker Composeスタックが得られるとされている。

バージョン指定がデプロイ戦略に直結する設計

Agentのコンストラクタに渡すversionは単なるメタデータではなく、READMEのコメントでカナリアデプロイ、A/Bテスト、ブルーグリーンロールアウトに使えると説明されている。エージェントの呼び出しが名前ベースである以上、同じnode_idの複数バージョンが併存し、呼び出し側がどの版に当たるかをコントロールプレーンが決めるという構造だと読み取れる。これは、エージェントの振る舞いを変更するたびに呼び出し側のコードを書き換える運用を避ける方向の設計だ。ただしREADMEにはバージョンの解決規則や重み付けの指定方法までは示されていない。カナリア比率をどこで設定するのか、特定バージョンを固定して呼ぶ手段があるのかは、採用前にドキュメントで確認する必要がある。

マルチエージェント基盤として見たときの限界

最初に明確にしておくべき制約は、提供されているリリースがv0.1.138-rc.16、rc.15、rc.14といずれもプレリリースであり、バージョン番号が0.1系である点だ。APIの互換性が保証された段階ではないと考えるのが妥当で、本番採用ならバージョン固定とアップグレード検証のコストを織り込む必要がある。次に、コントロールプレーン自体が単一障害点になり得る。ローカルではlaunchdの常駐プロセスとして動き、macOSでは素のkillが再起動扱いになるという挙動は、停止と再起動の意味をオペレーターが理解していないと事故になる。さらに、READMEの例が示す通り、ファンアウトの上限はアプリケーション側のdepthチェックに依存している。コントロールプレーンがキューとリトライを引き受けるとしても、再帰の設計そのものは書き手の責任だ。エージェントが1つか2つで、呼び出しが同期の関数呼び出しで足りる用途にこれを入れると、Docker Composeスタックと常駐プロセスという運用対象が増えるだけで見返りが薄い。

LangGraphや独自のジョブキューとの違い

比較対象として分かりやすいのはLangGraphのようなグラフ記述型のフレームワークだ。あちらはノードとエッジで処理の流れを明示的に定義し、状態遷移をグラフとして管理する。AgentFieldはREADMEで「No DSL, no YAML, no graph wiring」と述べており、通常の関数とデコレータだけで済ませ、呼び出しの配送と再試行をコントロールプレーンに寄せる。グラフを事前に確定できない、あるいは再帰的に呼び出しが広がる処理では後者のほうが記述量は少なくなる。逆に、処理の流れを静的に検証したい、実行前にグラフをレビューしたいという要件ではLangGraphのほうが向く。もう一つの比較軸は、Celeryや独自のジョブキューにエージェント実行を載せる構成だ。その場合はキュー、ワーカー、再試行、トレースを自分で組み合わせる必要がある。AgentFieldはそこを一つのコントロールプレーンにまとめている代わりに、そのコントロールプレーンの運用とバージョン追従を受け入れることになる。

ライセンスとメンテナンスの見取り図

ライセンスはApache-2.0で、リポジトリのLICENSEに従う。特許許諾条項を含む寛容なライセンスだが、実際の利用条件の解釈は法務の確認事項であり、ここで法的助言はできない。メンテナンス面では、デフォルトブランチがmainで、最終pushが2026-09-09、同日にrcリリースが複数出ている。活発に動いている一方、リリースがプレリリースに集中している期間であり、破壊的変更が入る前提でバージョンを固定して追従するのが現実的だ。READMEにはcoverageバッジとlast commitバッジへの参照があるが、この記事ではそれらを品質の根拠としては扱わない。アップグレードコストを見積もる際は、afのバージョンだけでなく、生成されたDocker Composeスタックとエージェント側SDKのバージョンを揃えて更新する必要がある点を考慮したい。ハーネス連携を使っている場合はaforgeも同じ更新サイクルに入る。

編集部の結論

多数のエージェント呼び出しをまたぐ再試行やトレースを自前で書きたくないチーム、特にPythonでエージェントを書きつつデプロイはコンテナで行いたいチームに向く。単一プロセスで完結する小規模な用途や、コントロールプレーンを自前で持ちたいチームには過剰である。導入前に確認すべきは、v0.1.138-rc系がプレリリースである点、macOSではlaunchd登録とメニューバー常駐が既定で入る点、そしてaf service stopを使わない停止がクラッシュ扱いで再起動される点の3つ。

公式情報源

1. Agent-Field/agentfield on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases