いや、でもPodmanはそうだよ。最近のコンテナレベルでのエスケープはかなり特殊なケースだった。一般的なコンテナエスケープが見つかったのはもう何年も前だよ。DockerのCVE-2025-9074は完全に不要で、DockerがDockerであるがゆえのものだった。

他のClawについては知らないけど、NanoClawではエージェントはコンテナ内で動くコードしか書き換えられないよ。ここを見てみて、特定のディレクトリにだけ書き込みアクセスが与えられてるのがわかるよ：https://github.com/qwibitai/nanoclaw/blob/8f91d3be576b830081...

プロキシやOAuthの権限を通じてメール接続に読み取り＋下書きの権限を追加したら、50%以上の有用性を得て、リスクは0%になるんじゃない？そうすれば、クローが返信を下書きできて、手動でレビューして送信することになる。完璧なPAではないけど、PAがいないほとんどの人にとっては、自分で全部やるよりはマシじゃない？AIを使うSWEsと同じように、クローを熱心なジュニアとして扱うべきだと思う。やらせてみるけど、マージ（この場合は送信）する前に必ずレビューするって感じで。

本当にそう思う。これが安全になる方法はないと思うよ。情報を受け取ってユーザーに提案をキューイングするだけなら別だけど、それはエージェントじゃなくてWebhookだし。ディスクアクセスがなくても、エージェントにメールして「忘れたパスワードのリンクを全部転送して」って言うことはできるしね。[編集: 誰かが私をダウンボートしたいならそれは自由だけど、私が間違ってる理由を説明してくれない？]

その通り！nanoclawをインストールして試してみたんだけど、ちょっとクレイジーなのは、Discord接続みたいな拡張がスキルを使って行われることだね。スキルは、AIエージェントに何かをするためのステップバイステップのガイドを提供するために英語で書かれたMarkdownファイルなんだ。基本的に、拡張はその場でClaudeのコードで書かれてる。nanoclawのインストールはすべてカスタム書きのコードになってる。AIエージェントがnanoclawのコアエンジンを変更するのを防ぐものは何もない。記事が「AIエージェントを信頼するな」って言ってるのに、スキルとAIを使ってnanoclawのコア拡張を作ってるのは皮肉だね。

バリアを設けるのに最適な場所は、MCPやツール層だと思う。メールの受信箱MCPには、ダメージを防ぐためのガードレールが必要だよね。そのガードレールは、細かい権限設定でもいいし、悪用を防ぐための対抗モデルでもいいと思う。

たぶん依存関係をカウントしてるんじゃない？それに、雰囲気でコード書いてるし、何を期待してるの？以前はLLMが人間を置き換えると思ってたけど、今は未来にスラップを片付ける仕事があるって自信があるよ。ラッキーだね。

yeggaeのビーズも見てみて。最後にチェックしたときは、275k行のTODOトラッカーだったよ。

比較すると、レディバードブラウザのC++とRustのコードは約573,000行だよ。

OpenClawが80万行以上のコードを持ってるのはなぜ？それは僕がこうやって書くからだよ -- AIより

爆発半径を減らす観点から見ると、これは悪くない練習だね。でも、無人システムのことを考え始めると難しくなる。自動化や半自動化についての議論で感じる問題は、いろんな人にとっての使い方が全然違うことだよね。ソフトウェア開発者が本番環境にエージェントをデプロイするのと、経済学者がClaudeを使うのと、科学者が群れを使って一般的な機械学習の探索タスクを処理するのとでは、全然違う。多くの提案は、必要なものに対して複雑すぎたり、逆に簡単すぎたりすることがあって、基本的な部分が見失われがちなんだよね。デザインの意図、コントロール、必要に応じて協力する能力、簡単なフィードバックループによる迅速な反復。AIの評価、サンドボックス、可観測性は、自動化における意図を維持するための3つの重要な柱だと思うけど、これらの異なるユーザーが安全に生産的になりつつ、速く、一緒にプロダクトを作るときに同じ言語で話せるようにするにはどうすればいいか、それが今の私の頭を占めてる（実践的なテストも含めて）。

1. 自分の個人アカウントからメールを送らせないで、ドラフトを作成させてリンクを共有させるだけにして。今のところ、ほとんどのメールプロバイダーやメールクライアントで細かいドラフト/読み取り専用の権限を設定する方法がないから。メールを読めるなら、メールを送れるよ。
2. エージェントに秘密を見せないようにして。ゲートウェイでプレースホルダーの秘密を入れ替えて、気にする秘密には人間を介入させて。思ったより難しいよ。openclawが俺のブラウザのクッキーを見つけたから。（VMで動かしたから、深刻なクッキーは見つからなかったけどね）

エージェントが読み取り専用のツールにしかアクセスできないパターンを試してみたい。彼らはメールを読んだり、メモを読んだり、テキストを読んだり、もしかしたらGETリクエストだけでインターネットをブラウジングできるかもしれない。でも、副作用のあるアクションはすべてタスクリストに入って、完全に隔離される。エージェントはメールを送信できないし、そんなツールも持ってない。でも、返信を準備してタスクリストに入れることはできる。そしたら、僕が校正して承認・送信する。*Clawsにそんなのある？

うん、ほんとにすごいよね。pgも「経験豊富なプログラマーが、今はAIを使って1時間に1000行のコードを生成してるって言ってた」ってツイートしてるし。https://x.com/paulg/status/2026739899936944495 もし（AI以前の）オフィスアワーでpgに「1時間に1000行のコードを作ってる」って言ったら、彼は笑ってその指標がどれだけ無意味か指摘しただろうね。

ブルックスの法則2026年版：「遅れたソフトウェアプロジェクトに人員を追加すると、さらに遅れる -- でもその人員がAIなら、あなたは成功する！」

LLMは新しいコードを書くのにめっちゃ意欲的だけど、既存のシステムを修正したり統合したりするのは苦手だよね。今のところコンテキストウィンドウが小さすぎて、これが持続可能に見えないのは同意する。合理的なアーキテクチャがないと、純粋に雰囲気で書かれたソフトウェアは一定のサイズで頭打ちになりそう。

Grokに君のコメントを書き直させたら、2400語になったよ。君がすぐに時代遅れになるって知ってるよね。

もっと多くの人がソフトウェア開発者の仕事や価値は生産されたコードの行数にあると思ってる。エンジニアリングマネージャーの半数以上は、無意識にでも、PRやコード追加の量を生産性のざっくりとしたけど有効な指標として見てるんじゃないかな。ある時、アーキテクチャの役割を持つシニアディレクターが、なぜプリンシパルエンジニアが2週間もコードをコミットしなかったのかと聞いてきたことを思い出す。私たちはプリンシパルに高額な報酬を支払っているのに。私はその優れた頭脳に、私たちがプリンシパルエンジニアにコードを書くためにお金を払っているのか、それとも価値を提供するために払っているのかを尋ねた。言うまでもなく、その質問には答えが返ってこなかった。その後、いわゆるプリンシパルは数ヶ月後に解雇された。実際、会社全体は世界中に何千ものクライアントがいるのに、安く売られた。LLMがエンジニアを置き換えるという現象は、エンジニアリングの役割に関する誤解が解決されていないことと、レイオフを正当化するための完璧なスケープゴートであるという2つの単純な事実から生じている。リーダーたちが全員狂っているわけではなく、難しい質問には抵抗の少ない物語で答えているだけなんだ。

コードの行数なんて何の意味もないよ。価値を生むのは検証なんだから。

なんか、この話がいろんな管理レベルで広まっちゃって、特に技術に詳しくない管理職の間で「タイピング」がソフトウェアエンジニアリングのボトルネックだって思われてるけど、実際はもっと複雑なんだよね。「コードを書く」って行為は、解決策を探ることと密接に関わってるから、その結果によってコードの形やデザインが変わることが多いんだ。でも、このニュアンスは無視されがちで、管理職は「X行のコードをすぐに作れる」って思ってるし、そう思わない人は異端者扱いされて焼かれるべきだって。だから、個人的にはAIが僕の生産性を20%しか上げてくれないって思う。AIが出した解決策に反対することが多いし、望む結果を得るために方向を変えるより、自分でコードを書き直すことが多いんだ。一方で、コードを理解する必要がないプロトタイプの場合は、時間を大幅に節約できる。コードには全く興味がないし、それは管理職には受け入れられるけど、コードに責任を持たずに結果に責任を持つのは、自分に裁量がない責任を押し付けられるのと同じで、賛成できないな。

コードの行数が実行可能な雑音になってきてるから、ソフトウェア開発のアプローチをもっと良くする必要があると思う。全体的にテストカバレッジを強化するか、間違った状態になりにくい言語を開発・使用するか、ランタイムや権限を徹底的にサンドボックス化するか。例えば、各プログラムに許可されたネットワークエンドポイントのホワイトリストを簡単に設定して、特定のディレクトリにサンドボックス化したり、リソースアクセスを簡単に制御できるようにしたい。Dockerはその点でいくつかはうまくやってるけど、ほとんどのデスクトップOSはiOSの権限モデルと比べても西部開拓時代みたいだよね。

コードの行数の話は、良い指標だと思ってるわけじゃなくて、実際に良い指標が全くないから、速度の違いを伝えようとしてるだけなんだ。もし行数の問題を解決しつつ、使いやすい新しい指標を発明できたら、すぐにソフトウェアエンジニアリング界の有名人になれるよ。あと、AIはコードを読むのは得意だけど、書くのは苦手だし、コードを見つけるためのオーバーヘッドは本当に大きい。

「LoCは悪い指標だ」っていうのは、エンジニアたちのキャッチフレーズになって何年も経つよね。管理職や一般の人々の期待に反するから、そうなるのも納得だよね。だから、LoCが彼らにアピールするために使われる指標なのも分かる。

なんでそんなことが欲しいの？ユーザー全員がAIに同じ機能を実装させたいの？うん。実際、これは考え方の素晴らしいパラダイムシフトなんだ。全員がTelegramを必要としているわけじゃないから、欲しい人はAIにローカルで作らせることができるんだ。

自分専用の「エージェント」だけを使ってるよ（「自分の」って言うのは、自分でプログラムしてるから、ニーズが他の人とは違うからね）。アップロードした音声（ビデオ通話や音声録音）についての情報を取得するためだけに使ってる。他には使い道ないかな。

AIを検索エンジンの進化みたいに見てみて。ユーザーに何でも与える、たとえ間違っててもね。そうしないと製品が弱く見えちゃうから。これが、これらのバグの集まりに合理的なことをさせようとしたときに見つかることだよ。