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

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

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

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

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

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

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

エージェントが死ぬのは「ツール対スキル」みたいな小難しい哲学の問題じゃなくて、結局は退屈な本番環境のトラブルのせいだっていう指摘、まさにその通りだと思う。デモを卒業した後に待ってるのはいつものやつばかり。どれだけの数のエンドポイントを叩いたらグラフが解読不能になるか、ツールが進化してもコントラクトをどう安定させるか、そしてツール用のラッパーに適当にトークンをコピペしないように認証をどう集約するか。自分たちの現場でうまくいってるのは、ツールを普通のサービスとして扱うこと。厳格でバージョン管理されたインターフェース、一元管理されたRBAC（ロールベースアクセス制御）、そしてモデルの中じゃなくてAPI層でのオブザーバビリティの確保だね。裏側の配管については、API Gateway + KongやTykを経由させたり、DBのラッパーとしてPostgRESTやDreamFactoryみたいな自動生成API層を噛ませることで、これらの制約と早いうちに向き合わざるを得ない状況を作ってる。LLM抜きで考えた時に恥ずかしくなるようなアーキテクチャなら、最初から詰んでるっていう投稿者の指摘は本当にいいリマインダーになるよ。