今の AI Agent の最大のボトルネックは、モデルが十分に賢くないことではない。手が短すぎるのだ。
コードは書ける、データは分析できる、レポートも生成できる。しかし「ユーザー A の注文状況を確認して」とか「CRM の API で連絡先を更新して」と言うと——ごめん、手が届かない。
Executor はこの問題を解決したい。README は率直だ：「The missing integration layer for AI agents.」
何が解決されるか
Agent が外部サービスを呼び出す必要があるとき、現在のやり方はバラバラ：プロンプトにハードコードするもの、MCP（Model Context Protocol）を使うもの、カスタムの tool calling を作るもの。それぞれに制限があり、互いに非互換だ。
Executor のやり方：統一された統合レイヤーを作る。既存の API——OpenAPI 仕様の REST エンドポイントでも、GraphQL エンドポイントでも、MCP サーバーでも、カスタム JS 関数でも——Executor に登録すれば、Agent が統一プロトコルで呼び出せる。
主な機能：
- セキュアサンドボックス：Agent の呼び出しは隔離環境で実行され、内部システムが直接露出しない
- マルチプロトコル対応：OpenAPI、MCP、GraphQL、カスタム JS
- changeset バージョン管理：changesets でリリース管理を行っているのは、バージョン互換性を真剣に考えている証拠
- デスクトップアプリ：最近デスクトップ版のリリースフローを更新（fix: publish as draft until desktop assets upload）
アクティビティ
1,998 回のコミット、6 時間前も更新あり。最近 Version Packages のリリースを行っており、プロジェクトが安定化に向かっていることを示唆。Issues はわずか 8 件、Pull requests 14 件——1.7K star のプロジェクトとしては issue 数が少ないが、まだ比較的新しくユーザーが様子見している可能性がある。
著者 RhysSullivan は AI Agent 分野で継続的な貢献記録があり、トレンドを追いかけただけのリポジトリではない。
MCP との関係
重要な明確化：Executor は MCP の代替品ではなく、MCP の上位レイヤーだ。MCP は Agent とツールの間の通信プロトコルを定義する。Executor はその上で一つのことを行う——接入をより簡単にすること。
既存の OpenAPI サービスがある場合、MCP サーバーを書き直す必要はない——Executor に登録するだけでいい。プロトコル変換は Executor がやってくれる。
実際のシナリオ
こういう場面を想像してほしい：内部のユーザー管理システム（REST API）、データ分析サービス（GraphQL）、カスタムデータクリーニングスクリプト（JS）がある。Claude や GPT に「ユーザー A の注文を照会し、消費パターンを分析し、結果をデータベースに書き込んで」と頼みたい。
Executor なし：3 つの tool 定義をそれぞれ書き、認証、エラーリトライ、データフォーマット変換を処理する……
Executor あり：サービスの記述ファイルを放り込むだけで、Agent が直接呼び出せる。
もちろん、これは理想論。実際の効果は Executor のプロトコル変換品質とエラー処理メカニズムに依存する。コードを見ると、入力スキーマ境界の制御が厳しい（最近のコミット："Tighten input schema boundaries"）——これは良いこと。セキュリティは利便性に優先する。
追う価値があるか
プロジェクトはまだ比較的前期段階。1.7K star は一定の注目を示しているが、爆発点にはまだ達していない。Agent システムを構築中で、複数の外部サービスを統合する必要があるなら、Executor は試用する価値がある。Agent が 1〜2 の API を呼ぶだけでいいなら、この中間層を導入する必要がある段階ではない。
主要ソース：