AIエージェントを本番運用して痛感した「抽象化の罠」— それはAIの魔法ではなく、泥臭いシステム開発だった

エージェントに関する議論の多くは、「スキルか、ツールか」といった抽象的な定義に終始しがちです。

ですが、実際に本番環境で耐えうるエージェントを開発した私の結論はもっとシンプル。抽象化の議論よりも「実行時の制約」の方が遥かに重要だということです。

モデルから見れば、渡されたものはすべて単なる「呼び出し可能な選択肢（callable option）」に過ぎません。しかし、デモの段階を過ぎた途端、システム開発者なら誰もが経験したことのある「お馴染みの問題」が牙を剥きます。

• APIサーフェスの爆発的な増加
• 脆すぎるインターフェース
• スケールしない認証モデル
• ローカルでは動くのに、実ユーザーが使うと崩壊するシステム

各種エージェントフレームワークがこれらにどう対処しているか、そしてなぜ多くの失敗が「モデルの推論能力」ではなく、古典的な分散システムやセキュリティの問題に起因するのか、その具体的な内訳をまとめました。

ここに投稿したのは、これらの課題が「AIの魔法」というよりは、むしろ「プロダクションエンジニアリング」そのものだと感じたからです。

The main point you’re hitting is that agents die from boring production problems, not from fancy “tool vs skill” philosophy, and that’s spot on.

Once you’re past the demo, it’s all the old stuff: how many endpoints can this thing call before nobody understands the graph, how do you keep contracts stable as tools evolve, and how do you centralize auth so you’re not copy‑pasting tokens into random tool wrappers. The trick that’s worked for us is treating tools like any other service: strict, versioned interfaces, RBAC in one place, and observability at the API layer, not inside the model.

On the plumbing side, wiring tools through things like API Gateway + Kong or Tyk, and occasionally a generated API layer (e.g., PostgREST or DreamFactory) to wrap databases, forces you to confront those constraints early. Your post is a good reminder: if you’d be embarrassed by the architecture without an LLM in it, you’re already in trouble.