ディスカッション (10件)
Hacker Newsの皆さん、こんにちは。Intuned (https://intunedhq.com) のFaisalとAhmadです。私たちは、ブラウザ自動化を構築、デプロイ、そしてメンテナンスするためのプラットフォームを開発しています。IntunedのAIエージェントは、主にAPIが公開されていないWebサイトの自動化に利用されています。よくあるユースケースとしては、データのスクレイピング、レポートの取得、フォーム送信などです。Webサイトのデザインが変更されても、私たちのエージェントが自動的に修正(セルフヒーリング)をサポートします。Intunedでは、ブラウザ自動化はAIエージェントによって作成され、「コード」として実行されます。インフラ側ですべての実行コンテキストをキャプチャするため、AIがコードのデバッグやメンテナンスを継続的に行い、自動化の安定性を維持します。これにより、コードベースの予測可能性、速度、低コストを維持しつつ、手動でコードを書き続ける苦痛を解消します。デモ動画はこちら:スクレイピング構築(https://youtu.be/ruZP73bK4FU) 、AIによるプロジェクト維持(https://youtu.be/e4R4hLdHBro) 。開発の背景:私たちはもともと別のアイデアでYCに採択されました。FaisalのUiPathでの経験から、Webサイト自動化によるAPIの代替ニーズを確信し、現在の「コードファースト」なアプローチにたどり着きました。仕組み:Intunedは、インフラとエージェントが密接に統合されたマネージド・ランタイムです。PlaywrightベースのTypeScriptやPythonプロジェクトをサポートしており、ブラウザコード実行に必要な認証、セッション管理、スケジューリング、並行処理などを一元管理します。特に強力なのは、実行時に失敗した際、パラメータやログを保持し、AIが調査・修正案を作成する「Fix with AI」機能や、障害を自動検知して修正を提案・適用する「セルフヒーリング」機能です。デモ:https://youtu.be/IVHIXw0lYMs 。また、Web Task APIとして機能を提供することも可能です:https://youtu.be/1olRn3l95vw 。ブラウザ自動化はもっと速く、安く、予測可能であるべきだと信じています。https://app.intuned.io/ から無料枠でぜひ試してみてください。フィードバックをお待ちしています!
「ホテル予約サイトに行って、6月に4人家族で2週間予約する」といったワークフローをどれくらいこなせるの?
初期のユーザー獲得はどこでうまくいった?他の選択肢と比べて、あなたのソリューションがユーザーにとって有用だった理由は何?
ローンチおめでとう!数年前にOpen Financeでまさに同じ問題に直面したことがあるよ。結局のところ、UiPathみたいな自動化エージェンシー的な立ち位置になるんじゃないかな。自分たちで構築するスキルやリソースがある企業は君たちのサービスを必要としないだろうけど、フルサービスを求める層には需要がありそうだね。応援してるよ。
スタートアップがどのようにして創業者の迷路を通り抜けていくのか、いつも純粋に興味があるよ。一夜にして成功したという神話を打ち砕く助けになるからね。YCのページを見ると、ここ数年でいくつかピボットしてるみたいだね。
- 4年前: Intuned - エンジニアリングリーダー向けデータアシスタント
- 2年前: Intuned - 開発者とプロダクトチーム向けブラウザ自動化プラットフォーム
- 1年前: Intuned Auth Sessions - 認証済みスクレイパーとRPAの構築
4年前のYC S22から今のローンチに至るまでの進化はどういったものだったの?また、極めてコモディティ化したこの分野でどう差別化を図ったのか教えてほしい。YC内だけでもFirecrawl、Reworkd、BrowserUse、NotteLabs、Browserbaseなど競合は多いよね。
あと、もう一つ。HNでよく報告されているように(自分も経験があるけど)、AIクローラーはウェブサイト所有者にとってコスト増やダウンタイムといったネガティブな影響をもたらすことがあるよね。Intunedはrobots.txtの指示を尊重してるかな?また、User-Agentヘッダーでクローラーの身元を明かしているのか教えて。
これって、「Computer Useモデルが今後さらに良くも安くもならない」ということに賭けているということ?
一番の疑問は、強力なアンチ自動化セキュリティを実装しているサイトをどうやって突破するのかってこと。既存のツールを使っても、その壁にぶち当たるとすぐに自動化できなくなっちゃうからね。
すごく面白いアイデアだね。ローンチおめでとう!
めちゃくちゃいいね!ブラウザでのボット検知に関するブログ記事を読んだけど、最初の層がブラウザのIPアドレスだという話だよね。スクレイピングをする上で解決したいユニークな課題があって、それはネットワークレイテンシを極限まで減らすことなんだ。サイトの利用において、ブラウザからのリクエストがウェブサーバーに対して可能な限り低いRTT(往復時間)を持つことが重要で、つまり同じクラウドプロバイダー内にいる必要がある。今は手動でサイトにアクセスして、ブラウザ拡張機能でタイミングよくクリックしてるんだけど、この手動操作をなくしたいんだよね。でも、拡張機能による単発のクリック以外でブラウザ自動化を組み込もうとすると、すぐにボット検知に引っかかってしまう。住宅用プロキシを挟むとRTTの最適化という目的が台無しになるし。修正されたブラウザを使えば、クラウドのIPアドレス自体がレッドフラッグにならないくらいボット検知のヒューリスティックを下げられるのかな?Camoufoxのことは知ってるからそのうち試してみるつもりだけど、他にブラウザを自動化しつつレイテンシを低く保つためにスコアを下げられる選択肢はあるかな?
最高じゃん。ブラウザ自動化のメンテナンスでついに正解を見つけたね。