FrigadeによるWebアプリのAgentツールへのリバースエンジニアリング
FrigadeによるWebアプリのAgentツールへのリバースエンジニアリング
Frigadeは、Webアプリケーションの内部APIコールをAIエージェント用のツールに自動的に変換する、ブラウザベースのエージェントを導入しました。このアプローチにより、AIアシスタントは、手動でのAPI統合やアプリケーションのソースコードへのアクセスを必要とせずに、Jira、Spotify、Hacker Newsなどの製品と深く統合することが可能になります。
自動化されたAPIからツールへの変換
Frigadeのシステムは、認証済みのWebアプリケーション内でブラウザエージェントを実行することで動作します。エージェントはアプリケーション独自のAPIコールを観察し、それらを「レシピ」へとリバースエンジニアリングします。これらのレシピは、自己更新型のModel Context Protocol (MCP) サーバーとして機能し、ホストアプリケーションのAPIが変更されてもAIエージェントが機能し続けることを保証します。
各ツールレシピは、以下のコンポーネントで構成されています：
- API Endpoint and Method: アクションに使用される特定のURLとHTTPメソッド。
- Authentication: エンドポイントを保護するために使用される方法（リフレッシュトークンやクッキーの取得方法に関する指示を含む）。
- Response Schema: APIコールのレスポンススキーマ。
- Input Schema: POSTまたはPUTリクエストに必要なデータ構造。
- Human-Readable Description: ツールの動作に関する明確な説明。これにより、LLMが特定のタスクに対して正しいツールを選択できるようになります。
従来のAgent統合の限界を解決する
この手法は、従来のAIエージェント統合に関連する3つの主要な課題に対処しています：
- API Complexity: 現代のソフトウェアは、AIエージェントがすぐに利用できるように設計されていない、複雑で混乱を招くAPIやサービスのネットワークを頻繁に利用しています。
- Security and Authentication: アプリケーションは、認証のために多様で、しばしば独自の標準（JWTとクッキーの組み合わせなど）を使用しており、標準化された統合を困難にしています。
- Brittleness of "Computer-Use" Agents: 人間のクリックをシミュレートする従来のブラウザエージェント（computer-use）は、しばしば低速で、トークン消費量が多く、UIが変更された際に失敗しやすいという性質があります。
UIレイヤーではなくAPIレイヤーをターゲットにすることで、Frigadeは、サードパーティを介さずに、ワークスペースへのチームメイトの招待といったユーザーに代わってアクションを実行するための、より安定した、効率的な方法をエージェントに提供します。
技術的な実装とエッジケース
システムは汎用的に設計されていますが、著者は、すべてのアプリケーションは本質的に異なると指摘しています。言及されている重要な技術的課題は、GraphQL APIの標準化であり、著者は標準化されたレシピを作成する際に「最も扱いにくいAPI」であると述べています。
ツールを追加するためのワークフロー
- Training: エージェントはアプリケーション上でトレーニングを行い、初期レシピを構築します。
- Enablement: アプリケーションの所有者は、ダッシュボードを介して検出されたツールを有効化します。
- Execution: エージェントは、認証済みのAPIエンドポイントを使用して、アプリケーション内で直接アクションを実行します。