じゃあ、これってVMにClaude Codeをデプロイして実行するのとどう違うの？すでにあるいろんな方法でサンドボックス化できるじゃん。何が違うの？

なんでこんな説明を実際のウェブサイトに載せないの？ ホームページは、これが実際に何をするのか全然説明してないじゃん。インフラエンジニアが、以下の情報だけでアプリをbashコマンドでインストールすることを本当に期待してるの？「インフラのためのClaude Code。Fluidがインフラで行うすべてをデバッグ、アクション、監査。VMからサンドボックスを作成し、調査、計画、実行、Ansibleプレイブックを生成し、すべてを監査。」

これはワクワクするね。でも、他の人もコメントしてたけど、理解するために全てを二回読まなきゃいけなかったよ。強いフィードバックループはAIエージェントにとって究極の解放で、双子を持つのが正しいアプローチだね。

「CCがローカルで実行されているプロダクションマシンにSSH接続するのは避けたかったんだ（これが本当の問題！）。実行できるツールをサンドボックスのみに制限しつつ、サンドボックスを作成する自律性を持たせて、他にはアクセスできないようにしたかった。これが今のインフラの運用方法だよ。シンプルなアプリを運用しているなら、VMを立ち上げる必要なんてあるの？」コンテナ運用プラットフォームなら、これがすごく簡単だよね。

それって、既存のインフラにTerraformerを向けて、別のアカウントで再構築するのとどう違うの？それは、あなたの会社が手動で複雑なインフラを立ち上げていると仮定した場合だけど、もしそうなら、あなたの「DevOps」チーム全員、あるいは責任者はクビにすべきだよ。

インフラのクローンにアクセスを与えることで、エージェントは探検したり、コマンドを実行したり、IaCを書く前にテストしたりできるから、より良いコンテキストが得られるし、アイデアや変更をデプロイする前にテストする場所ができるんだ。トークンを燃やすコストが高いと思ってた？それをさらに上げるために、クラウドインフラをたくさん立ち上げて、エージェントに手探りさせるってことだね。DevOpsは私の仕事だから、エージェントを広く使ってるけど、こんなことは絶対にしないよ。無駄すぎる。

リポジトリのルートからその.DS_Storeを削除して、グローバルなgit ignoreに.DS_Storeを追加した方がいいよ。

リモートサンドボックスで物事を動かすエージェントは、Infrastructure as Codeにはあまり合わないね。最近、AWS Organizationsで管理されている一時的なAWSアカウントにPulumiスタックをセットアップして、ローカルでTiltを使ってKubernetesクラスターをいじってるんだけど、今のところClaudeはその辺りがかなり良い感じ。Pulumiについてはかなりの知識があるし、Tiltの基本もわかってるし、Kubernetesについてもいい感じの知識がある。ただ、いくつかのことについては少し古い情報があって、RTFMを思い出させる必要があるけど、自分でかなりのことをやってくれるよ。もし本当に問題があれば、チートシート（ごめん、「スキル」ね）があれば大半の問題は解決できると思う。君が挙げた例は、リモートボックスにSSHで入って手動で設定するような感じだね。それは繰り返し可能なインフラを作りたい時にはあまり役に立たないよ。Terraformを生成することから自分を差別化しようとしてるけど、実際にはそれが価値あることだと思う。

それが、ソフトウェア開発者の問題だよね。ソフトウェアの専門知識はあるけど、CSの世界以外の深いドメイン知識がない。

初めての仕事を始めてから1年が経ったけど、問題が尽きることがないね。特に今のAIの時代、コードが書けるっていうのは、同僚を助けるための魔法のような力を持ってるって感じ。僕のコードベースは、実際のニーズに基づいて、徐々にまとまりのある、よく定義された再利用可能な機能に向かって進化してる。今は、ニッチな分野にコンサルティングを提案してみて、何がうまくいくか見てるところ。オフィスのダイナミクスが続くなら（助けていくうちに、能力が積み重なっていく）、最終的には「製品」と呼べるものが見つかると思う。

自分用のアドホックなツールやアプリを作るのに、LLMがすごく役立ってる。1日か1週間だけ必要なもので、完璧に動かなくても大丈夫（バグには対処できるし）。本当に解放感があるよ。「こんなアプリがあればいいのに」って言う代わりに、自分でアプリを作って使って、次に進むだけだから。

人と話すことが大事だよ。解決すべき問題は無限にあるからね。どれが解決する価値があるかを決めるのが難しいところ。

ちょっと遊び感覚でおもちゃアプリを作ってみるのもいいかも！妻と一緒にタイピング速度の話をして、お互いにタイピングコンペを挑戦したことがあるんだ。見つけた既存のものはあまり良くなくて、広告だらけだったから、クラウドに自分たち用のものを作ってもらったんだ。仕事以外で何をするのが好きか考えてみて、アプリやクラウドスキルを作ってみるのもいいかも。料理が好きなら、自分用のレシピ管理アプリを作ってみるとか。私はCooklang（マークダウンに似たもの）でレシピを保存するためのリポジトリを作って、クラウドスキルを使って新しいレシピを見つけたり作ったり評価したりしてるよ。おもちゃアプリを作ることで、もっと大きなアイデアが浮かぶかもしれないしね。

私の最初のプロのコーディングの仕事は2007年、Facebookが「Facebookアプリ」を初めて導入したときだった。スタートアップでFacebookアプリを作ってたんだけど、すべてのアプリ会社が同じマネタイズ戦略を持ってたんだ：他のFacebookアプリの広告を売ること。だから、アプリのライフサイクルはこんな感じだった。1) ゲームやクイズなどのアプリを作る。2) 成功したアプリにインストールごとに$X支払って、たくさんのアプリインストールを得る。3) 「友達を紹介するとゲーム内の特典がもらえる」みたいな詐欺的なことをして、バイラルになることを狙う。4) 広告を払わなくても人々が見つけてくれるほど大きくなることを願う。5) 他のFacebookアプリのスタートアップに広告を売って、インストールを生成する。完全に循環経済だったよ。ピラミッドの次の層以外に製品や収入源はなかった。長続きしなかったけどね。

完璧だね！これはAIですらない、プレAIだよ。みんなが他の人が依存できるものを作ろうとし続けてるけど、それをもっと速いペースでやってるだけ。子供の頃の自分が見たかったシミュレーションを書くのが楽しくて充実感があるんだ。

みんなインフラを構築したがってるよね。よく理解されている何かを自動化したいって感じ。誰かがそれを使って、エンドユーザーの問題を解決してくれることを期待してるけど、その問題は理解しづらくて、複雑で、しばしば文脈によって変わるもの。要するに、みんな自動化したいんだ。ほとんどの人は、退屈で大きな問題には触れたくないんだよね。

同じような状況だけど、最近これらのツールを使って逆エンジニアリングもできることに気づいたよ。例えば、中国からこのラベルプリンターを買ったんだけど、Linuxでの印刷品質に満足できなかったんだ。それで、BLE経由で印刷するためにGoスクリプトを「コーディング」したんだ。これをするために、プリンターに付属しているAndroidアプリを逆コンパイルして、何時間もかけて調べる代わりに、エージェントAIにやってもらったんだ。今では、ブラウザ内で完全に動作するバージョンやESP32バージョンまで作っちゃった。さらに、プリンターを分解してみたら、内蔵BLEが外部モジュールで、自分のカスタムPCBに置き換えることでプリンターと直接インターフェースできることがわかったよ。

ありがとう！ Kubernetesは次にサポートしたいインフラの基本的なものなんだけど、気に入ってもらえて嬉しいよ。質問やアイデアがあったら教えてね！

本当の問題は、従業員の不安定さだよね。取締役会やオーナーがダウンタイムを罰しない限り、アップタイムが「あればいいな」程度になっちゃうリスクがある。新しい大学卒の子とクラウドで専門知識を簡単に置き換えられるからね。だから、顧客に反応してもらう必要があるんだ。これは理論的な話じゃなくて、実際に人が仕事を失ってるし、今は本当に優秀な人が市場にいるからね。

そうだね。Claudeを読み取り専用のリードから解放したときも、私にはうまくいった（愚かなことをしないように厳しく警告して、目を光らせてたけど）。でも、これはこのプロジェクトが解決しようとしている問題とはちょっと違うのかも。私が見る限り、これはより安全で再現性のある方法を使っているし（K8sネイティブではないから、ちょっと異質に感じる）。

私も同じことをしてる。彼が悪いことをできないように、読み取り専用のkubeconfigを作ろうと思ってたけど、良いSKILL.mdがあれば完璧に機能するよ。

こういうLLMベースのツールがたくさんあるのに気づいたけど、基本的にはすでにできることの周りにちょっと具体的なプロンプトのラッパーがあるだけ。ほんとにダメだね。

笑、ちょっと怖い感じもするけど、うまくいくならそれでいいよね。主に、変更が本番環境に影響を与える可能性を防ぐためにこれを作ったんだ。これは、1台じゃなくて何百台ものVMを使うスケールで使うことを想定してる。安全の観点から、Claude Codeをただ見守るだけで運用するのは僕の環境では無理だから、こういうものを作ったんだ。

読み取り専用にして、gitopsで運用してるけど、すごく良いし、PRの修正をするのもかなり安全に感じるよ。権限チェックなしで動かしてる。

そうそう、AWS CLIを使ってインスタンスを立ち上げたり、設定したり、サーバーを起動したり、CWログを読んだりするように指示してるよ。

これやってるけど、必ず読み取り専用/非破壊アクセスだけにしてるよ。すごくうまくいくから、めっちゃクールだよ。

同じだね。リードオンリーのアカウントやトークンでいい結果が出てるし、エージェントに任せてるよ。TerraformやAWS CLIでもうまくいくし、これをやるために新しいツールは必要ないよ。エージェントの指示に含めればいいだけ。

人々は信じられるコピーを書こうとするけど、HNに来てみると現実はそうじゃないことが多いんだ。これは主に、すべてのDevOpsの状況がユニークで、人間は一般化するのが好きだからだよ。結局、みんなが同じ問題を抱えているわけじゃないってことがわかった。HCLやyaml以上のレベルで成功しているスタートアップは見たことがないな。