Fluid - インフラのためのClaude Code

 (fluid.sh)
5 ポイント 投稿者 GN⁺ 2026-02-06 | 1件のコメント | WhatsAppで共有
  • AIエージェントが実際のインフラを安全に扱えるよう、サンドボックス複製環境を作るターミナルベースのツール
  • 複製されたVMやKubernetesクラスタでコマンド実行、ファイル修正、接続テストを行い、その結果をAnsible Playbook形式で自動生成
  • 単にLLMがコードを生成する方式とは異なり、実環境を複製して**テストと検証を経たIaC（Infra-as-Code）**を生成
  • エフェメラルSSH証明書を使って安全にコマンドを実行し、リソース不足のホストやインターネットアクセス時には人間の承認プロセスが必要
  • すべてのコマンドと変更内容が監査ログとして追跡され、開発者がローカル環境でインフラを実験し、再現可能な設定を作れるツール

Fluid概要

  • Fluidは本番インフラ（例: VM、K8sクラスタ）を複製したサンドボックスでAIが作業するターミナルエージェント
    • AIエージェントがコマンド実行、接続テスト、ファイル編集を実施
    • その後、結果をAnsible Playbook形式に変換して本番環境へ適用可能
  • この方式により、AIが実際のシステム構造を推測するのではなく、複製環境で直接実験できる

従来のLLMベースIaC生成との違い

  • LLMはTerraform、OpenTofu、Ansibleなどのコードをうまく生成できるが、実際の本番環境の動作を正確に把握できない
  • Fluidは複製インフラへのアクセスを通じてコマンド実行とテストを先に行い、その結果を基にIaCを作成
  • このアプローチにより、デプロイ前の検証と実験が可能になる

Claude Codeとの違いとセキュリティ設計

  • FluidはClaude Codeがローカルから本番サーバーへ直接SSH接続しないよう設計されている
  • すべての作業はサンドボックス内でのみ実行され、Fluidがそれを管理
  • エフェメラルSSH証明書を使い、コマンド実行結果をリアルタイムで表示
  • メモリやCPUが少ないホスト、インターネットアクセス、パッケージインストールなどは人間の承認プロセスを経る必要がある

主な機能

  • Sandbox Isolation: VMを即座に複製し、本番に影響を与えず変更をテスト
  • Context-Aware: ホストのOS、パッケージ、CLIツールを探索し、環境に合わせて動作
  • Full Audit Trail: すべてのコマンドと変更内容を記録し、監査とレビューが可能
  • Ansible Playbook自動生成: サンドボックスで行った作業を基に、再現可能なインフラコードを生成

使用例

  • Fluidはv create_sandboxコマンドでサンドボックスを作成し、IPと状態を表示
  • v run_commandでコマンドを実行し、例ではUbuntu 22.04環境でApache HTTP Serverのインストールと起動を実施
  • curl localhostでWebサーバーの動作を検証
  • その後、v create_playbookでhttpd-setupプレイブックを生成
    • 4つのタスクを含む: aptキャッシュ更新、Apacheインストール、index.html作成、Apacheサービスの起動と有効化
  • 生成されたプレイブックは他のUbuntuサーバーでも同じ設定を再現可能

インストールと実行

  • ローカルワークステーションにインストールするターミナルエージェント形式
  • インストール後はローカル環境からすぐにサンドボックス作成とテストが可能

要約

  • FluidはAIベースのインフラ自動化と安全な分離を組み合わせたツール
  • リアルタイムのコマンド実行、監査追跡、Ansibleコード生成機能により、安全で再現可能なインフラ管理を支援
  • Claude Codeのインフラ版として、開発者と運用担当者が本番環境を模倣して実験できる新しいアプローチを提供

関連記事

1件のコメント

 
GN⁺ 2026-02-06
Hacker Newsのコメント

  • 最近は何かを作るためのツールはあふれているのに、肝心の作る対象がないように感じる
    まるですべての製品が、別のビルドツールのためのピラミッド構造の一部みたいだ
    fluid.shへの不満ではなく、ただ自分も何を作るべきか悩んでいるだけ

    • 2007年のFacebookアプリブームのときにスタートアップで働いていたが、すべてのアプリ企業が他のアプリの広告を売る構造だった
      アプリのエコシステムは完全に循環経済のように回っていて、実際のユーザー価値や収益源はなかった。結局長続きしなかった
    • 問題は、多くの開発者がドメイン知識なしにソフトウェア技術だけを深掘りしていることにある
    • 自分も非テック業界で1年間働いているが、コーディング能力のおかげで同僚から魔法使い扱いされている
      実際の問題を解決していく中で、コードベースがだんだん再利用可能な機能へと発展している
      今はこの経験をもとにコンサルティングにも挑戦していて、いつか「製品」と呼べるものが見つかる気がしている
    • マクロ経済学的に見ると、技術があまりに速く進歩すると、かえって産出量が減少する局面がある
      今のAIツールブームも似た現象に見える。変化が速すぎて、みんながまた学び直している
      結局、私たちは動く砂の上に土台を築いているようなものだ
    • 自分も同じ悩みを抱えていたが、最近はこうしたツールをリバースエンジニアリングに使い始めた
      たとえば中国製ラベルプリンターのLinuxでの印刷品質が気に入らなかったので、BLEで直接出力するGoスクリプトを作った
      Androidアプリをデコンパイルする代わりにAgentic AIに任せ、今ではブラウザ版とESP32版まである
      関連記事は Making a label printer work under Linux using Agentic AI にまとめてある

  • 自分が curl -fsSL https://fluid.sh/install.sh | bash というコマンドを見て笑った理由は、
    本来はセキュリティ上SSHアクセスを防ぎたかったはずなのに、結果としてもっと危険なインストールスクリプトを実行させているという皮肉があるからだ
    関連ツイートは こちら で見られる

    • 今はインターネット上に悪意あるURLをLLMに推薦させるための毒をばらまく時代だ。本当にすごい時代だ

  • 私はCollinで、fluid.sh を作っている
    Claude Codeのインフラ版だと考えてもらえればいい。
    Fluidは、本番インフラ（VM、K8sなど）のサンドボックス複製を作り、AIエージェントがコマンド実行・ファイル修正・テストを行ったあと、
    Ansible PlaybookのようなIaCを生成する
    LLMが単にTerraformを生成するよりも、実際の環境を探索しながら文脈を理解できるようにするのが核心だ
    セキュリティ上の理由からClaude Codeが直接本番環境にSSH接続しないように設計しており、
    ephemeral SSH証明書でコマンド実行を追跡可能にしている
    リソースの少ないホストや外部ネットワークにアクセスする際には人間の承認を求める
    フィードバック歓迎！

    • こういう説明をなぜホームページに載せていないのか気になる。
      今のサイトには「Claude Code for infrastructure」程度しか書いてなくて、
      インフラエンジニアが bash 一発でインストールするには不親切すぎる
    • インフラの複製をいくつも立ち上げてエージェントを歩き回らせるのはコストの無駄に見える
      DevOpsをやる立場からすると非効率だ
    • リモートサンドボックスで手動設定をするのはInfrastructure as Codeの思想に合わない
      自分はPulumi、Tilt、Kubernetesの組み合わせで十分自動化できている
      Claudeもこの環境でうまく動く。わざわざSSHで直接触る必要はない
    • それなら既存のVMにClaude Codeをデプロイして動かすのと何が違うのかわからない
      すでにいろいろなサンドボックス化の方法がある。差別化ポイントが知りたい
    • Terraformerで既存インフラを複製することもできるし、
      こうした基本的なIaC自動化ができていないならDevOpsチームの問題だ
    • 「Claude Codeにkubectlコマンドを打たせてHelmチャートを直させる」みたいなことはすでにやっている
      普通のCLIでも十分うまく動く
      • 最近のLLMベースのツールのかなりの部分は、この種のプロンプトラッパー程度だ。本質的な差別化がない
      • 自分も似たように感じるが、このプロジェクトは大規模環境の安全性確保を目的にしている
        数百台規模のVMを運用する場合、単なる監視だけでは足りない
      • 自分も読み取り専用アカウントでClaudeを動かしているが、TerraformやAWS CLIとも問題なく連携できる
        わざわざ新しいツールは必要ない
      • 自分も読み取り専用のkubeconfigで制限をかけ、SKILL.mdだけしっかり書けば十分安全に動く
      • 読み取り専用で開放していても大きな問題はなかった。
        ただ、このプロジェクトは再現性と安全性をより重視するアプローチに見える
    • 本番環境の複製は簡単ではない。DB接続やスタック全体の複製は現実的に難しい
      むしろAIが本番構成を理解して直接変更するほうがよいと思う
      すでにモデルはIaCの記述にも十分習熟している
    • アイデアは面白い。最近は運用・オブザーバビリティ（Observability）の分野が盛り上がっている
      自分もKubernetes運用中にClaudeにGrafanaへのアクセス権を与えてデバッグを手伝わせているが、
      そのおかげで数十時間は節約できた。
      Ansible Playbookを自動生成するアプローチは      監査可能性      の面でも素晴らしい
      • ただ、こうした自動化が広がると、運用人材の不安定化が強まるかもしれない
        実際、熟練エンジニアが仕事を失う例も出てきている
      • Kubernetes対応の計画があるとのことで期待している。アイデアは気に入った
    • 正直、これはすでに解決済みの問題だと思う
      大半は最初からIaCでインフラを構築していて、必要なら逆向きに再構成できる
      Claudeをサンドボックス用アカウントでIAMロール付きで動かせば十分だ
    • 「LLMは本番システムをうまく推測できない」という主張には同意しない
      IaCはAPI経由でインフラに問い合わせられるし、再利用性とバージョン管理が利点だ
      • DevOps環境は会社ごとに異なり、一般化が難しいという点には同意する
        ほとんどのスタートアップはいまだにHCLやYAMLレベルで苦戦している
    • 「安全にするにはcurlスクリプトを実行してください」という文言が皮肉に感じられる
    • これってKVMをlibvirtで制御し、SSHキーを発行してLLMがVMにアクセスする構成なのだろうか？
      Ansible PlaybookはVM内部の変更をもとに生成されるのか、それともAnsibleだけで操作するのか気になる
      単にAnsibleを繰り返し実行するのと比べて、どんな差別化機能があるのか知りたい