Clawbotについての考察

Clawbotについての考察 この数日Clawbotを触ってみて、かなり多くの感想を持った。昨年9月のハッカソンで、Telegram/WhatsAppのインタラクションを使ってエージェントにプロアクティブに非同期タスクを実行させ、時にはグループチャットの内容でタスクがトリガーされるプロジェクトを作った。出発点は似ていたが、最終的な成果は全く比較にならなかった。主な違いは全体的なプロダクト/エンジニアリングのアプローチにあると思う。これは実際、ほとんどのハッカソンのトイプロジェクトに共通する問題だ。 Clawbotの第一印象は、実際にはエージェントを作っているのではないということだ（ここでエージェントとは、フィードバックメカニズムを持ち、目標が達成されるまで継続的にデータを読み取り関数を実行できるプログラムと定義する）。ドキュメントを見ると、従来のオペレーティングシステム/分散システムのランタイム/プラットフォーム設計に近い。 これはまさに、エージェントの主なボトルネックがもはやモデル性能にない—あるいは完全にはない—ことを示していると思う。Claude Codeといくつかのスキルでほとんどのコンピュータ操作を処理できるようになった今、本当に有用なタスクを完了できる完全自動エージェントに本当に欠けているのは、すべてのコンポーネントを調整・接続し、互いに干渉や衝突せず、タスクをできるだけ長く実行させることができる完全なシステムだ（これがパフォーマンスのためのシステム最適化の主な目標であるべきだ）。そしてこれはまさに従来のオペレーティングシステム設計が直面する問題だ。同時に、LLM呼び出しやツール呼び出し（その場でモデルが書いたコードさえある）のランダム性のため、プロセスとサブプロセス間のインタラクションの調整における不安定性は避けられない—これが多くの分散システム設計の概念が見られる理由だ（Clawbot自体、異なるノードで実行できる分散アーキテクチャとして設計されている）。 1. 最も基本的な抽象化は、まずすべてのプロセスを所有するデーモンと、それを外部に公開するゲートウェイから始まり、システム全体をコストが高く不安定なLLM呼び出しから分離することでリスクを隔離する。 2. Webhookベースのイベント駆動設計により、エージェントは環境の変化に効率的に反応できる。 3. オンボーディング時の様々なアクションに対するきめ細かい権限設定（既存のローカル認証の迅速な再利用）と、WhatsApp/TelegramのBluetoothペアリングのようなハンドシェイクメカニズムでセキュリティの問題を解決する。 4. 完全にローカルベースの性質により、システム全体がターミナルを通じて複数のプロセスに簡単にアクセスでき、ローカルソフトウェアやClaude Codeのようなツールを効果的に再利用でき、権限管理もManusのようなクラウドベースのソリューションよりはるかに簡単だ。 つまり、このような印象的な結果を出せない理由は、通常1つや2つの良いアイデアの欠如ではない—良いアイデアは実際にはますます安くなっている。より多くの場合、パフォーマンスの上限を十分に高く保ちながら、とっくに解決された古典的な問題にエンジニアリングの労力を無駄にしない、成熟した完全なシステム設計があるかどうかだ。 最後に、AIコーディングツールが全盛の今、コードを書くコストは下がっている一方で、競争力のあるシステムを構築するためのハードルは完全には下がっていないことも分かる。エージェントプロジェクトにとって、エンジニアリング能力の優位性は、新しいアイデアを思いついて先行者利益を得ることよりも重要かもしれない。偶然アイデアがユーザーに当たったり、偶然競合他社より良いエンジニアリングルートを選んだりするだけでは不十分だ。持続的な競争優位をもたらすのは、継続的に構築・反復するエンジニアリング能力、または変化するユーザーニーズを継続的に捉える能力だ。運良く（コスト構造/ネットワーク効果を通じて）自ら優位性を生み出すものを作らない限り、先制攻撃や狂ったような反復で競争優位を得ることを信じるのは非現実的だ。 Clawbotが代表するシステム化されたパラダイムが主流の方向になるかもしれないが、これは非常に専門化された分野以外では、この領域が非常に競争が激しくなることも意味する（システム設計は秘密ではない）。