Grab、500超のエージェントをLLM-Kitに統合

Grabの投稿の核心は、見落とされがちな切り分けにある。AIが推論しツールを呼び出して答える中核ロジックである推論ループ自体は、半日で書けた。その周囲の本番用の殻、つまり認証情報の置き場所、ログとトレースの配線、サービスディスカバリへの登録、評価は2週間かかった。Grabの一手は、これらの要素を各チームが個別に決めるのをやめたことだ。フォームから生成されるGitLabリポジトリには、シークレット管理とサービスディスカバリが最初から配線され、最初のコミット時点で評価エンドポイントも付く。注目すべきは、Grabが新しい抽象化層や専用言語を発明しなかった点で、既存インフラの周囲に足場を一度だけ構築した。

中央に移ったのは呼び出しインターフェースだ。モデル呼び出しは5社のプロバイダーを束ね認証情報を挿入する単一のOpenAI互換ゲートウェイを通るため、アプリ側コードはプロバイダー名をハードコードしない。ツールは事前に同梱されず、AIがツールを使うための共通接続標準である50超のMCPサーバーから実行時に取得する。新しいモデルやツールの追加は再デプロイ不要で、登録か設定変更だけで済む。しかしその上の層はチームに残った。500のサービスが同じ足場を共有しても、プロンプトの品質や何を改善と見なすかの基準はチームごとに存在し続ける。

記事は明言された緊張関係にも触れる。Grabはチームの囲い込みを避けるためプラットフォームではなくフレームワークを選んだとし、後に500サービス規模では問題がフレームワークからプラットフォームへ移ったと記した。記事はこの流れを意図的と読む。フレームワークと呼ぶことで500サービスを乗せ、その規模が共有部分の集約を正当化したというわけだ。記事はまた、エージェントの囲い込みはAPIの囲い込みより解くのが難しいという別のアナリストの警告を引く。4層で同時に蓄積するためだ。同じものを構築すべきか検討する企業に対し、記事は最初の一手は単一のモデル呼び出しインターフェースだと論じる。それだけでコスト可視化、プロバイダー切り替え、認証情報の集約をカバーし、MCPレジストリと評価基盤は十分なサービスが共有するまで待てるからだ。