Clawsは今やLLMエージェントの上に追加された新しいレイヤー

 (twitter.com/karpathy)
14 ポイント 投稿者 GN⁺ 2026-02-22 | 2件のコメント | WhatsAppで共有
  • LLMの上にエージェントが追加された後、そのさらに上でオーケストレーション・スケジューリング・コンテキスト管理・ツール呼び出し・永続性を担うClawsレイヤーが登場
  • エージェントの実行構造を1段階抽象化し、より高いレベルの自動化と構成可能性を確保
  • OpenClawは約40万行規模のコードベースで構成されており、個人データやキーを委任する構造に対する懸念がある
  • 露出したインスタンスの報告、RCE脆弱性、サプライチェーン汚染、レジストリ内の悪意あるまたは破損したskillsの事例など、多数のセキュリティリスクが現れている
  • 現在のエコシステムは「ワイルド・ウェスト」に近く、セキュリティ悪夢に近い環境である
  • NanoClawは約4,000行のコアエンジンで、比較的小規模な構成
    • コード全体を把握できる規模であり、管理・監査・柔軟性の面で有利
  • 基本的にすべての実行をコンテナ環境で実施
  • 設定ファイルの代わりにskillsによる構成方式を採用
    • /add-telegramコマンドがエージェントに実際のコード修正方法を指示
    • 複雑な設定ファイルや条件分岐構造を減らす新しいAIベースのアプローチ
  • できるだけフォークしやすいリポジトリを作り、skillsがそれをさまざまな構成に変形するメタ戦略が優れている
  • nanobot、zeroclaw、ironclaw、picoclawなど複数の派生プロジェクトが登場
  • クラウドホスティングの代替案も存在するが、ローカル環境の方が実験と拡張に有利
    • ローカルネットワークベースのホームオートメーション機器との接続もしやすい
  • 物理デバイス上で動作する個人向けデジタルエージェントという概念的魅力
  • ClawsはAIスタックの新しいレイヤーとして位置づけられ、エージェント以降の段階の構造を定義
  • 私の具体的な最終構成はまだ確定していないが、実験的で拡張可能な構造として大きな期待を寄せている

関連記事

2件のコメント

 
xguru 2026-02-22

NanoClaw – Appleコンテナ分離環境で動作する500行のTypeScriptベースClaudeアシスタント

公開時点では500行だったのに、今では4000行になったようです ??
 
GN⁺ 2026-02-22
Hacker Newsのコメント

  • 複数のコメントで個人攻撃が見つかり、削除された
    HNでは意見が違っていても個人攻撃は絶対に禁止されている。サイトの目的を損なうためだ
    最近ガイドラインを読んでいないなら、ぜひもう一度確認してほしい

    • 個人攻撃はなく、ただ同じ機能を何度もリブランディングすることへの不満だった。真の革新がないから人々は腹を立てているのだ。REST APIの初期にこうしたことが起きていたなら、その時も同じように怒っていただろう

  • セキュリティの観点では、Clawを置くのは人間の秘書やコンサルタントを置くのに近い
    個人メールや銀行口座へのアクセス権を渡さないのと同じで、別のメールアドレスと制限付きの法人カードを与えるように設定すべきだ

    • しかし政治家や役員は、秘書がメールやSNSを管理していることがよくある
      銀行口座は渡さなくても、会計士や財務アドバイザーにアクセス権を与える場合もある

  • 私がCLIベースのエージェントツールを作ったときに入れた安全装置がある
    危険な行動（例: 大量メール送信）を行うには**ワンタイムパスワード（OTP）**を要求するようにした
    ツールがエージェントに対してユーザーにOTPを求めるよう指示し、入力がなければ進めない
    まだClawは使っていないが、こうした人間介入の仕組みは必須だと思う
    だから私はすべてのエージェント用CLIを自分で作って、制御性を高めている

    • 最近のコンピューティングはまるでSim Cityのように、ぼんやりした計画だけ立てて、あとはシステムがうまく回ってくれることを期待する形に変わってきた。予測可能なルールの美しさが失われた気がする
    • もう一つのアプローチは、企業的な承認手続きを模倣することだ。重要な作業には**承認者（approver）**を別に置き、エージェントがその人にメッセージを送り承認を得る構造だ。OTPの代わりに承認チャネルを信頼する方式である
    • ただし、「あまりに多くの人にメールを送ってはいけない」という基準をどう強制するのかという疑問はある
    • 私はfly.ioで自分のClawを直接動かしている。メールやSlackメッセージなど人間の介入が必要な作業は**「activity」**として分離され、リンクが生成されて、私が承認して初めて実行される
    • 私は内部LLMと外部の権限オーケストレーションレイヤーを置いた版を作った。OTPは不要だと考えている。外部レイヤーがSignalで私に通知を送り、そのたびに承認するかどうかを決める

  • Clawが昔から存在していたら、インターネットは違っていた気がする
    単純なGopherプロトコルベースのメニュー型構造のほうがLLMには適していたかもしれない
    今後、ユーザー側エージェント中心の相互作用が増えれば、この方向へ進化していくのかもしれない

    • こういう未来は自分たちで作るべきだ。すべてのサービスがAPIの形でのみ存在し、私のエージェントがそれを組み合わせてくれる世界だ
      YouTube、Gmail、HN、銀行、電力会社まで全部APIなら、ユーザーは望む形でインターフェースを構成できる
      企業は独占が崩れるので反対するだろうが、技術は収益性が下がっても、より価値あるものになるだろう
    • 1992年ごろ、IMGタグ以前の時代に、私は foo-www、foo-http のようなDNSペアを作って実験していた
      CGIの提案が出たとき、「こんなの誰も使わないだろう」と思ったが、結局みんなその仕様を実装した。あの頃の初期の柔軟性を逃したのが惜しい
    • MCPはすでにその方向へ進んでいる。LLMがテキストベースでサービスにアクセスする構造だ
      私はTelegramで自分のMac上のOpenClawインスタンスと会話している。すでにアプリUIの代わりに新しいインターフェースを使っているわけだ
      人間が見るウィンドウの代わりにエージェント中心インターフェースを作り、検証用インターフェースだけを残すほうが合理的だ
    • 技術的にはすべてのWebサイトがAPIを提供できるが、インセンティブの問題のため、大半はそれを望まない。Google Search APIの事例のように
    • Clawが昔から存在できたとは思えない。LLMの学習データはWWWの普及のおかげで生まれたもので、そのインフラがなければ大規模学習そのものが不可能だったはずだ

  • Clawの本当の核心はユーザー中心エージェントである点だ
    人々が嫌うAIは企業が統制するAIだ。Clawはユーザーが所有し、名前まで付ける存在だ
    R2D2のような相棒と、私に物を売りつけようとするロボットのレプリカントとの違いに等しい

    • 同意する。OSベンダーのような既存の強者は、このユーザー中心モデルがある程度混乱を経験した後でようやく自社製品に統合しようとするだろう
    • ただし、「ユーザー」が誰かによって話は変わる。エージェントを起動した人なのか、それともその人と相互作用する相手なのか。後者は被害者になる可能性もある

  • 「Claw」が正確に何なのか気になった
    メールなどの個人データにアクセスするAIなのか?
    コンテナ内でローカルLLMとして動かせば安全なのか?

    • 私の見るところ、個人向けデジタル秘書の新しい形だ
      • 個人が直接使う
      • コード実行可能なターミナルアクセス
      • チャットアプリ統合
      • 定期実行機能
      • メール・カレンダー・ファイルなど機微データへのアクセス
        コンシューマーハードウェアでもVPSでも動かせる。新しい市場が開きつつある
    • 私にとっては定期的に動作し、受信トレイを確認して自動で作業を処理するcron-for-agentsのような概念だ
      非同期に私の認証情報を使って処理する。単純だが興味深い
    • しかしコンテナで動かしたからといって根本的なリスクが消えるわけではない
    • ある人はClawを、単に「AIブームに乗り遅れたくなくて無謀に自分をさらけ出す心理状態」だと皮肉っていた
    • 技術的に見るとClawは「キューの中のエージェント」だ。つまりLLMとツールがループを成し、そのループ同士がキューで接続された構造である

  • 私の要約: OpenClawはセキュリティリスク 5/5レベルだ
    完全に監査されたNanoClawでも4/5程度だろう
    人間の介入があればましだが、効用は急激に下がる
    LLMは言語仕様やテストベースのガードレール生成には向いているが、私は安定性のほうが重要だと思う

  • 「Claw」という名称は、OpenClaw系の個人向けAIエージェントを指す言葉として定着しそうだ

    • 用語のバイラルな拡散を見るのは興味深い。あとで商標の問題になって弁護士が頭を抱えるかもしれない。WordPressエコシステムの「press」のように

  • 最近のエージェントワークフロー流行は、セキュリティ境界の欠如という根本問題を無視している
    LLMが無制限のシェルアクセスを持つ状態で信頼できないデータを読み込めば、間接プロンプトインジェクションは避けられない
    さらに巨大なシステムプロンプトやツールスキーマをコンテキストに詰め込むと、モデル本来の推論能力が落ち、脆弱性が高まる

    • 実際、こうしたリスクはみんな分かっているが、利便性が大きすぎるので受け入れて使っているのだ
    • Information Flow Controlは理想的だが、統合チャネル全体のプロトコルが変わらない限り実現不可能だ
    • 関連研究を共有してもらえないだろうか

  • GTA VIより先にストアブランドClawが出てきた
    自分で作ってみたら、50行のコードで十分だった
    Telegramライブラリ数行と claude -p prooompt があれば足りる
    ULTRONのサンプルコードを参考にできる
    もちろんエージェントは外部に委譲するが、Bash 50行でもほぼ完璧な結果が出せる

    • ただし本当のClawとして使うにはcronの追加が必要だ