クラウド向けの開発は、ちょっとした確認のたびに遠い環境へつながり、認証情報を用意し、結果が返るまで待つ——この繰り返しが意外と重い。Flociは、その往復をローカルに持ち込もうとする新しい試みだ。AWS、Azure、GCP、OCIを自分のPC上で動かし、しかも起動はミリ秒単位だと打ち出している。特に、コードを書くAIエージェントが増えた今、「安全に試せるクラウド」があるかどうかは開発体験をかなり左右するはずだ。
Flociは、自分たちを “Local Cloud Emulators” と位置づけている。対象はAWS、Azure、GCP、OCIの4系統で、いずれもローカルで動くエミュレーターとして提供される。サイト上では「Any cloud. Locally.」と掲げ、開発者やAI coding agentsのために、無料で、認証情報なしで、すぐ使えるフィードバックループを作るのが狙いだと説明している。
各クラウドごとに独立したMITライセンスのバイナリが用意されていて、アカウント作成も認証トークンも必要ない。AWS向けの floci はLocalStackの置き換えをうたっており、同じポート4566で、119サービスをカバーする。起動は24 msだとしている。Azure向けの floci-az はBlob、Queue、Table、Functions、App Config、Key Vault、Event Hubs、Service Busなどを扱い、4577番ポートで、28サービス、アイドル時メモリは13 MiBとある。GCP向けの floci-gcp はGCS、Pub/Sub、Firestore、Cloud Run、Cloud SQL、GKEなど25サービスを4588番ポートで動かす。OCI向けの floci-oci はObject Storage、Identity、Queue、Streaming、KMS、Vault、Functionsを含む8サービスを4599番ポートで提供する。
記事は、AI支援開発に向けた使い方をかなり強く押し出している。エージェントはクラウドコードを書く速度が上がっている一方で、本物のクラウドアカウントに対して安全に実行するのは難しい。そこでFlociを向け先にして、ビルドし、実行し、検証する。資格情報の漏えいがなく、請求も発生せず、何か壊しても影響はローカルのコンテナに閉じる、という説明だ。サイトには export AWS_ENDPOINT_URL=http://localhost:4566 のようにCLIの接続先を向ける例や、pytest、Terraform/OpenTofu、CloudFormation、各種SDKとの連携を想定した記述がある。
また、FlociはCLIとGUIの両方を用意している。floci-cli ではひとつのコマンド体系でAWS、Azure、GCP、OCIのエミュレーターを開始・停止・確認でき、floci-ui ではサービスを横断してブラウズし、データやログを見られる。Quick Startでは、macOS/Linux向けのインストールスクリプトやWindows向けのPowerShell例、AWSやAzure、GCP、OCIそれぞれでのバケット作成・ファイルアップロード・ダウンロードのサンプルまで載せている。最後に、FlociはMITライセンスで公開され、スポンサーを募っている。開発費やインフラ維持に充てたいという説明だ。
まず面白いのは、Flociが単なるローカル開発ツールとしてではなく、AIエージェントのための安全な実験場として設計されていることだ。ここはかなり今っぽい。人間の開発者なら、多少面倒でも本番に近いテスト環境を守りながら使える。けれどAIエージェントは、試行回数が多いぶん雑に壊しやすい。だから「最悪、ローカルを再起動すればいい」という前提は、エージェントの反復速度と相性がいいと思う。
特に、認証情報を持たせたくないという発想は重要だ。AIにクラウドの鍵を渡すのは、便利さと引き換えにリスクを抱える行為だった。Flociはそこを「鍵を渡さずに、似た結果だけ返す」方向へ寄せている。これは単なるコスト削減よりも、運用上の心理的な安心を作る。開発者がAIをより広く任せられるようになるなら、道具としての価値はかなり大きいはずだ。
一方で、エミュレーターという性質上、気になるのは再現度だ。Flociは「real engines, not mocks」と言い、LambdaはDockerコンテナ、RDSはPostgreSQL/MySQL、ElastiCacheはRedisで動くと説明している。これはたしかに、単なるモックよりはずっと現実に近い。だが、クラウドの厄介さは個々のサービスの中身だけでなく、周辺の挙動や制約、認可まわり、障害時の癖にもある。そこまで全部を完全に再現するのは難しい。
だから、Flociは「開発の早い段階で使う道具」としては強いが、「ここで通ったから本番も安心」とまでは言い切れないと思う。むしろ、IaCの誤記や接続先のミス、簡単な統合テストを先に潰す用途に向いている。実際、記事でもTerraform/OpenTofuやCloudFormationのdry run、CIでの一時的な環境作成を強調している。本番の代替というより、本番に触る前の強力な関所として見るのが自然だ。
記事の中で印象的なのは、AWS版を「LocalStackのDrop-in replacement」とまで言っている点だ。しかも同じ4566番ポートで動かし、コード変更なしで切り替えられるという。ここにはかなり明確な対抗意識がある。さらに、LocalStackが2026年3月に認証トークンを求め始めた、とFloci側は書いている。これが事実なら、少なくともFlociは「無料で、トークン不要で、気軽に使える」ことを差別化の中心に置いていることになる。
この動きは、単に競合製品の穴を突く話ではないと思う。開発ツールは、一度チームに入ると習慣の力が大きい。そこに課金や認証が入ると、個人開発や小規模チーム、授業用途では一気に使いにくくなる。Flociはその摩擦を極限まで減らしている。MITライセンスで、トークンもいらず、しかもローカルで速い。思想としてはかなり「オープンであること」に振り切っている。その潔さは強いが、同時に事業として長く続けるにはスポンサー獲得がかなり重要になるだろう。
Flociが刺さるのは、クラウドを扱う人数が増えた現場だと思う。たとえば新しいメンバーのオンボーディング、教育機関での実習、CIでの一時的な検証、AIエージェントに繰り返し触らせる試験環境。どれも「本物のクラウドを使いたいが、毎回アカウントや請求や権限でつまずきたくない」という共通点がある。そこを一気に軽くできるのは大きい。
ただ、だからこそ普及の条件もはっきりしている。ドキュメントが親切で、CLIが扱いやすく、既存のSDKやTerraformと素直につながり、何よりチーム内で「これを使えばだいたい動く」という信頼が積み上がる必要がある。Flociはその入口としてかなりよくできているように見えるが、最終的には個別サービスの細部と運用の安心感で評価されるはずだ。ローカルで速いだけでは足りない。開発者が「ここなら任せられる」と思えるかどうかが、本当の勝負になる。
