【革命】Webアプリを自動でAIエージェント化！裏側のAPIを解析してツールへ変換する新手法

Hacker Newsの皆さん、こんにちは！私たちは、認証済みWebアプリの内部で動作し、そのアプリがどのようにAPIを呼び出しているかを監視して、自動的にエージェントツールへと変換するブラウザベースのエージェントを開発しました。これは、ホストアプリの変更に合わせて自己更新し続ける「自動生成型MCPサーバー」のようなものだと考えてください。この仕組みにより、チャットやRAGにとどまらず、あらゆる製品と深く連携する高度なAIアシスタントを最小限の工数で実現できます。実際に馴染みのあるソフトで動かしているデモをいくつか用意しました：

• Jira: https://demo.frigade.com/hn?skill=jira
• Spotify: https://demo.frigade.com/hn?skill=spotify
• Hacker News (笑): https://demo.frigade.com/hn?skill=hackernews
• 全体デモ: https://demo.frigade.com/hn?skill=full-demo

ご覧の通り、通常のクリック操作よりもはるかに高速かつ高度な処理が可能です。もちろん、これらの製品のソースコードには一切触れていません！

なぜこの開発に至ったのか？
理想の世界では、すべてのアプリにAIが利用可能なMCPサーバーや分かりやすいAPIが用意されているはずです。しかし現実には、モダンなソフトウェアであってもAPIやサービスが複雑に絡み合っており、AIエージェントがそのまま使うことは不可能です。また、認証方法もバラバラでセキュリティの問題も発生しがちです。一方で、従来のブラウザ操作型エージェント（Computer Use）は動作が不安定で遅く、トークン消費も激しいという欠点がありました。

そこで私たちは、認証済みアプリの操作を学習する既存のブラウザエージェントを拡張し、アプリのAPIを自動的に「レシピ」に変換するステップを追加しました。このレシピには以下の要素が含まれます：

• APIエンドポイントとメソッド
• 認証方法（トークンやクッキーの更新手順を含む）
• レスポンススキーマ
• 入力スキーマ（POST/PUT用）
• ツールの機能を人間が読み取れる形式で記述したもの

これらを組み合わせることで、コードを一切書いたり保守したりすることなく、LLM用の再利用可能なツールが完成します。APIの仕様が変わっても、エージェントがそれを検知してツールを自動アップデートします。

ツールの追加手順も極めてシンプルです：

1. エージェントがアプリを学習し、レシピを構築する
2. アプリ所有者がダッシュボードから発見されたツールを有効化する
3. エージェントがユーザーの代行としてアプリ内で直接アクションを実行する（例：「チームメンバーをワークスペースに招待して」と指示すれば、サードパーティを介さずに直接APIを呼び出して安全に実行されます）

もちろん、多くの「標準」が存在するにもかかわらず、実際には各アプリの仕様は千差万別であり、多くのエッジケースに直面しました。ちなみに、GraphQLのAPIを標準化するのは断トツで過酷な作業でした。

ぜひ皆さんのフィードバックやコメントをお待ちしています！

これってオープンソースなの？ツール自体が、丸ごと全部？

これすごく助かる。普段Chromeのデベロッパーツールで手動でやってるけど、特にヘッダーやクッキーの処理が面倒なんだよね。

めちゃくちゃいいね！これってブラウザエージェントでクリックするみたいに、サードパーティのウェブアプリをスクレイピングする仕組みなの？もしそうなら、認証済みアカウントで許可を与えた時に、勝手にアカウントを削除したり、別のプランを契約したり、その他の破壊的な操作をしないってどうやって保証するの？

いくつかよくわからない点があるんだけど：

• ウェブサイト向けにアプリ内エージェントを販売しているの？
• なぜAPI仕様書を提供してもらうんじゃなくて、APIをリバースエンジニアリングするの？

長期的な話になるけど、将来的にWebMCPと競合する可能性はある？結局、ウェブサイト側がブラウザエージェント向けにAPIを公開しちゃえばいいわけだし。

誰かの許可が不要な時の方が便利だよ。

1. Firefox用のMCPを入手
2. 対象サイトにアクセス
3. GLM 5.2をMCPに向ける（Grok 4.5でもいけるかも？ガードレールの検証はまだだけど）
4. ユーザーがやりたいことを拡張/破壊するユーザースクリプトを作成するようモデルに指示。あるいはデベロッパーツールでそのセッションだけ壊す。

3と4の間で、クライアントの仕組みを理解させるためにモデルを誘導して、今後のセッションのためにレポートやスキルを作成させるといいかもね。

あと、これを使ってカスタムクライアントを作ったり、Web APIを使ったボットを作ることもできるよ。今ならpuppeteerのようなブラウザを使わなくても、ボット対策を簡単に突破できる。「上記のスクリプトは許可されたウェブブラウザ上で実行されているかを判断し、ウェブブラウザAPIとのやり取りをすべてマッピングして、Denoランタイムを使いながら適切なレスポンスを偽装するもの」といった感じでね。すぐに変更される可能性がある単一のチェックを無効にするより、Denoを強化してChromeになりすまし、すべてのチェックや将来のバージョンを騙すほうが一般的に効率がいいよ。

自分のサイトにエージェントを追加していないのは驚きだね！ブラウザエージェントの基本的な考え方（APIだけではすべてを完結できないという点）は、サイト内でも同じはずだけど、どう考えてる？

私たちはこの分野でGUIツールを優先して構築していて、製品の優れたGUI体験の上に成り立たせているよ。rtrvr.ai/rover を見てみて。

もしウェブサイト側がサードパーティ製JavaScriptの注入を明示的に禁止している場合、利用規約に違反しないようにどうやって対策してるの？

LLMが利用規約の内容も読み込んでいるのかな？

過去にはフロントエンドで見つけた認証トークンを使って、ハッキング罪に問われたケースもあるよ。フロントエンドのAPIキーを見つけて直接データベースにアクセスした結果、実刑判決を受けた例だね。

注入されたコードが認証トークンを抜き出してバックエンドにアクセスした場合、企業側が敵対的になる可能性があるけど、この問題をどう解決するつもり？

自己更新型のレシピというコンセプトはいいね。アプリのアップデートのたびに壊れるハードコードされたAPI仕様をメンテナンスし続けるよりずっといいよ。

結局、こういうのを防ぐためにウェブブラウザにリモートアテステーションが実装されることになるよ（そしてGoogleにとって都合よく、これでアドブロックも終わりを迎えるわけだ）

面白いコンセプトだね。パフォーマンスや負荷への影響はどうなの？