インフラストラクチャのためのClaudeコード

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